From xen-devel-bounces@lists.xenproject.org Thu May 01 00:13:17 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 00:13:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.973961.1361964 (Exim 4.92) (envelope-from ) id 1uAHXy-0005tY-Ml; Thu, 01 May 2025 00:13:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 973961.1361964; Thu, 01 May 2025 00:13: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 1uAHXy-0005tR-Ip; Thu, 01 May 2025 00:13:02 +0000 Received: by outflank-mailman (input) for mailman id 973961; Thu, 01 May 2025 00:13:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAHXw-0005t2-JK for xen-devel@lists.xenproject.org; Thu, 01 May 2025 00:13:00 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 08b480a6-2621-11f0-9eb4-5ba50f476ded; Thu, 01 May 2025 02:12:58 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 07A264AEEF; Thu, 1 May 2025 00:12:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D316BC4CEE7; Thu, 1 May 2025 00:12: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" X-Inumbo-ID: 08b480a6-2621-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746058376; bh=qAh1F7E/uG4Z4fl1EhRuCTzv/ukLfE8zGutjIKfRzWo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bKmdc7Cv6iYM8sVyRVKZ52NeLFZ5UQte3vGFNKNqijyZZDW10/1g+wsr4wv+6DdQO p4XgL+ECdlmrZgzInsfXJi8EVpOML+Mm3XeK/8zo9VOgzurC3SjhkYVc6IZU8Dc2V/ VBPFpK/RARfGuL9akKjeNmAFBqQT7cCocfBmXjhNKcj12v6wXZuLElyPJ7qvgHEERT uaTkyMGjuJtJDiSANR9yUUYxE8Ga32cFzayMmyI8/ko3s1hkWVWHwOp0Thcm//wvZ5 ubzJOTxo3j09UhG+K8ANHjyduWcdC+BRvexvrhxPWb+4RDSMeKAlYZV1Dbsl17D+xA 3MI25sOoK9sRQ== Date: Wed, 30 Apr 2025 17:12:53 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Andrew Cooper cc: Jan Beulich , "xen-devel@lists.xenproject.org" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Anthony PERARD Subject: Re: [PATCH] {hyper,multi}call: further limit arguments to just 5 In-Reply-To: <8d4451ee-7de7-4fc1-a231-b51871d145db@citrix.com> Message-ID: References: <5020c491-2037-4955-99ce-e6ba02b44aef@suse.com> <8d4451ee-7de7-4fc1-a231-b51871d145db@citrix.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Tue, 28 Apr 2025, Andrew Cooper wrote: > On 29/04/2025 9:16 am, Jan Beulich wrote: > > Multicall compat translation and hypercall continuation handling can > > also be shrunk to the processing of just (up to) 5 arguments. > > > > Take the opportunity to > > - make exceeding the limit noisy in hypercall_create_continuation(), > > - use speculation-safe array access in hypercall_create_continuation(), > > - avoid a Misra C:2012 Rule 19.1 violation in xlat_multicall_entry(), > > - further tidy xlat_multicall_entry() and __trace_multicall_call() > > style-wise. > > > > Amends: 2f531c122e95 ("x86: limit number of hypercall parameters to 5") > > Signed-off-by: Jan Beulich > > Acked-by: Andrew Cooper Arm side: Acked-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Thu May 01 00:19:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 00:19:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.973973.1361972 (Exim 4.92) (envelope-from ) id 1uAHe1-0006UK-95; Thu, 01 May 2025 00:19:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 973973.1361972; Thu, 01 May 2025 00:19: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 1uAHe1-0006UD-6R; Thu, 01 May 2025 00:19:17 +0000 Received: by outflank-mailman (input) for mailman id 973973; Thu, 01 May 2025 00:19:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAHe0-0006U7-Hi for xen-devel@lists.xenproject.org; Thu, 01 May 2025 00:19:16 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e909f96e-2621-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 02:19:14 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 34BE2435AA; Thu, 1 May 2025 00:19:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48A0BC4CEE7; Thu, 1 May 2025 00:19: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" X-Inumbo-ID: e909f96e-2621-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746058752; bh=yWmu8O5Zf51smc8pIPQ+qfFl6Ivec1iyV2WZf/mQ8KY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DTFATBY7irq4BT1STNIsVHIqXGx2Z7vIhAKegOgxrDpaPrR89xBFnQ40XftnWfu+J hc2/EZRkMORem6ldQ/oxKu02xBB8srzU8wvQzsEoF1Da/Odwow8ADWMegHv1vcOROq ucHwUtVlw11Wx6Pf9c6LsiM/UFcZ7vZOhRGI5rIdqlG83EZlUPbTh+EMrCF2o9ESy8 NfTQNymUC9RnMt8qJjSbR418Tq5nwlcDfit7tif7klh8TWbP93X6O0lD19zn5XXPff GAF6lv4ZaSKB7WmpGFUiGug+JTjmTA6G9KSnJpAf+Xi5gtBsm3gq31D6H48adqnhDs 9zJD3l/9y+n2A== Date: Wed, 30 Apr 2025 17:19:10 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= cc: Jan Beulich , Stefano Stabellini , "Ragiadakou, Xenia" , Andrew Cooper , jason.andryuk@amd.com, agarciav@amd.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange In-Reply-To: Message-ID: References: <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com> <06b66971-d8db-456f-8e83-a20ff7df8f5e@suse.com> <59bfc389-66c8-4d0f-92e3-c0079a807374@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1953259969-1746058752=:3879245" 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-1953259969-1746058752=:3879245 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Wed, 30 Apr 2025, Roger Pau Monné wrote: > On Wed, Apr 30, 2025 at 08:27:55AM +0200, Jan Beulich wrote: > > On 29.04.2025 23:52, Stefano Stabellini wrote: > > > On Tue, 29 Apr 2025, Jan Beulich wrote: > > >> On 28.04.2025 22:00, Stefano Stabellini wrote: > > >>> On Mon, 28 Apr 2025, Jan Beulich wrote: > > >>>> On 25.04.2025 22:19, Stefano Stabellini wrote: > > >>>>> --- a/xen/arch/x86/mm.c > > >>>>> +++ b/xen/arch/x86/mm.c > > >>>>> @@ -4401,7 +4401,7 @@ int steal_page( > > >>>>> const struct domain *owner; > > >>>>> int rc; > > >>>>> > > >>>>> - if ( paging_mode_external(d) ) > > >>>>> + if ( paging_mode_external(d) && !is_hardware_domain(d) ) > > >>>>> return -EOPNOTSUPP; > > >>>>> > > >>>>> /* Grab a reference to make sure the page doesn't change under our feet */ > > >>>> > > >>>> Is this (in particular the code following below here) a safe thing to do > > >>>> when we don't properly refcount page references from the P2M, yet? It's > > >>>> Dom0, yes, but even there I might see potential security implications (as > > >>>> top violating privacy of a guest). > > >>> > > >>> I don't think I am following, could you please elaborate more? The > > >>> change I am proposing is to allow Dom0 to share its own pages to the > > >>> co-processor. DomUs are not in the picture. I would be happy to add > > >>> further restriction to that effect. Is there something else you have in > > >>> mind? > > >> > > >> Once "shared" with the PSP, how would Xen know that this sharing has stopped? > > >> Without knowing, how could it safely give the same page to a DomU later on? > > >> ("Safely" in both directions: Without compromising privacy of the DomU and > > >> without compromising host safety / security.) > > > > > > Why would Xen later assign the same page to a DomU? The page comes > > > from the hardware domain, which, as of today, cannot be destroyed. BTW I > > > realize it is a bit different, but we have been doing the same thing > > > with Dom0 1:1 mapped on ARM since the start of the project. > > > > The life cycle of the page within Dom0 may be such that a need arises to > > move it elsewhere (balloon out, grant-transfer, and what not). > > I think it's up to dom0 to make sure the page is handled > appropriately, in order for it to keep it's special contiguity > properties. > > If the PSP is not using the IOMMU page-tables for DMA accesses, and > the hardware domain can freely interact with it, there's no protection > from such device accessing any random MFN on the system, and hence no > refcounts or similar will protect from that. Yes, exactly! > The only protection would be Xen owning the device, and the hardware > domain using an emulated/mediated interface to communicate with it. I > have no idea how complicated the PSP interface is, and whether it > would be feasible to trap and emulate/mediate accesses in Xen. There will be always the possibility of devices or co-processors or firmware not behind the IOMMU and we won't be able to handle them all in Xen. > > >>>>> --- a/xen/common/memory.c > > >>>>> +++ b/xen/common/memory.c > > >>>>> @@ -794,7 +794,7 @@ static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg) > > >>>>> rc = guest_physmap_add_page(d, _gfn(gpfn), mfn, > > >>>>> exch.out.extent_order) ?: rc; > > >>>>> > > >>>>> - if ( !paging_mode_translate(d) && > > >>>>> + if ( (!paging_mode_translate(d) || is_hardware_domain(d)) && > > >>>>> __copy_mfn_to_guest_offset(exch.out.extent_start, > > >>>>> (i << out_chunk_order) + j, > > >>>>> mfn) ) > > >>>> > > >>>> Wait, no: A PVH domain (Dom0 or not) can't very well make use of MFNs, can > > >>>> it? > > >>> > > >>> One way or another Dom0 PVH needs to know the MFN to pass it to the > > >>> co-processor. > > >> > > >> I see. That's pretty odd, though. I'm then further concerned of the order of > > >> the chunks. At present we're rather lax, in permitting PVH and PV Dom0 the > > >> same upper bound. With both CPU and I/O side translation there is, in > > >> principle, no reason to permit any kind of contiguity. Of course there's a > > >> performance aspect, but that hardly matters in the specific case here. Yet at > > >> the same time, once we expose MFNs, contiguity will start mattering as soon > > >> as any piece of memory needs to be larger than PAGE_SIZE. Which means it will > > >> make tightening of the presently lax handling prone to regressions in this > > >> new behavior you're introducing. What chunk size does the PSP driver require? > > > > > > I don't know. The memory returned by XENMEM_exchange is contiguous, > > > right? Are you worried that Xen cannot allocate the requested amount of > > > memory contiguously? > > > > That would be Dom0's problem then. But really for a translated guest the > > exchanged chunks being contiguous shouldn't matter, correctness-wise. That is, > > within Xen, rather than failing a request, we could choose to retry using > > discontiguous chunks (contiguous only in GFN space). Such an (afaict) > > otherwise correct change would break your use case, as it would invalidate the > > MFN information passed back. (This fallback approach would similarly apply to > > other related mem-ops. It's just that during domain creation the tool stack > > has its own fallback, so it may not be of much use right now.) > > I think the description in the public header needs to be expanded to > specify what the XENMEM_exchange does for translated guests, and > clearly write down that the underlying MFNs for the exchanged region > will be contiguous. Possibly a new XENMEMF_ flag needs to be added to > request contiguous physical memory for the new range. > > Sadly this also has the side effect of quite likely shattering > superpages for dom0 EPT/NPT, which will result in decreased dom0 > performance. > > We have so far avoided exposing MFNs to HVM/PVH, but I don't see much > way to avoid this if there's no option to use IOMMU or NPT page-tables > with the PSP and we don't want to intercept PSP accesses in Xen and > translate requests on the fly. Yeah, I think the same way too. --8323329-1953259969-1746058752=:3879245-- From xen-devel-bounces@lists.xenproject.org Thu May 01 00:20:59 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 00:20:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.973988.1361983 (Exim 4.92) (envelope-from ) id 1uAHfd-0008FO-Mz; Thu, 01 May 2025 00:20:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 973988.1361983; Thu, 01 May 2025 00: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 1uAHfd-0008FH-KF; Thu, 01 May 2025 00:20:57 +0000 Received: by outflank-mailman (input) for mailman id 973988; Thu, 01 May 2025 00:20:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAHfc-0008F9-3M for xen-devel@lists.xenproject.org; Thu, 01 May 2025 00:20:56 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 24033049-2622-11f0-9eb4-5ba50f476ded; Thu, 01 May 2025 02:20:53 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 237D1A4A5A7; Thu, 1 May 2025 00:15:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2AC6EC4CEE7; Thu, 1 May 2025 00:20: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" X-Inumbo-ID: 24033049-2622-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746058851; bh=6Ia57A4I5wiXQw9ar830r0742ycof8w5szTvIvQ5wzE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=LgJdiFXUrnvhXsShz3L7tzc8vYV+odiAefXZV0ejwLmScj4FmzOAvIs7LHLOHQe5l i/ShHOYv9yV3lkiRmPC0DtEjyWBuX8XpdurlHdbOD8vgkeAiGqQyRCnTSFUpUjdOfp KakDe7iuuIjsjGakj8fK+EjEZINe2q2rnYTPjVaiYyLR+mkbG50VRUToJz5peQS94m g4Gfl3AhDuEQjBY0qmLcsMGW0ZsjSan5Zsn4xLOTFg1TWc1rnyZIL3qVTlU2e6JDZ4 NzOhgDKvt+q1wgVch6Aa07UuPiJeE60YJMFY3MpfwaCmQJn1lvwDXjKZ5UX8rtRWbc DJyXTDjsKBFcg== Date: Wed, 30 Apr 2025 17:20:48 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , victorm.lira@amd.com, Nicola Vetrini , Federico Serafini , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , xen-devel@lists.xenproject.org Subject: Re: [PATCH v1 1/3] x86: x86_emulate: address violations of MISRA C Rule 19.1 In-Reply-To: <2be0b5a8-50ee-4c3c-9299-0f065ac5aa05@suse.com> Message-ID: References: <914e3157-736a-4890-9c91-e93fcc260bb0@suse.com> <350d447e-7316-4d54-8468-68f78675cc8d@suse.com> <2be0b5a8-50ee-4c3c-9299-0f065ac5aa05@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 30 Apr 2025, Jan Beulich wrote: > On 30.04.2025 00:54, Stefano Stabellini wrote: > > On Tue, 29 Apr 2025, Jan Beulich wrote: > >> On 29.04.2025 03:27, Stefano Stabellini wrote: > >>> On Mon, 28 Apr 2025, Jan Beulich wrote: > >>>> On 26.04.2025 01:42, victorm.lira@amd.com wrote: > >>>>> From: Nicola Vetrini > >>>>> > >>>>> Rule 19.1 states: "An object shall not be assigned or copied > >>>>> to an overlapping object". Since the "call" and "compat_call" are > >>>> > >>>> Was this taken from patch 2 without editing? > >>>> > >>>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c > >>>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > >>>>> @@ -526,9 +526,19 @@ static inline void put_loop_count( > >>>>> */ \ > >>>>> if ( !amd_like(ctxt) && mode_64bit() && ad_bytes == 4 ) \ > >>>>> { \ > >>>>> + uint64_t tmp; \ > >>>>> + \ > >>>>> _regs.r(cx) = 0; \ > >>>>> - if ( extend_si ) _regs.r(si) = _regs.esi; \ > >>>>> - if ( extend_di ) _regs.r(di) = _regs.edi; \ > >>>>> + if ( extend_si ) \ > >>>>> + { \ > >>>>> + tmp = _regs.esi; \ > >>>>> + _regs.r(si) = tmp; \ > >>>>> + } \ > >>>>> + if ( extend_di ) \ > >>>>> + { \ > >>>>> + tmp = _regs.edi; \ > >>>>> + _regs.r(di) = tmp; \ > >>>>> + } \ > >>>> > >>>> See commit 7225f13aef03 for how we chose to address similar issues elsewhere > >>>> in the emulator. I think we want to be consistent there. This will then also > >>>> eliminate ... > >>>> > >>>>> @@ -2029,7 +2039,12 @@ x86_emulate( > >>>>> switch ( op_bytes ) > >>>>> { > >>>>> case 2: _regs.ax = (int8_t)_regs.ax; break; /* cbw */ > >>>>> - case 4: _regs.r(ax) = (uint32_t)(int16_t)_regs.ax; break; /* cwde */ > >>>>> + case 4: > >>>>> + { > >>>>> + uint32_t tmp = (uint32_t)(int16_t)_regs.ax; > >>>>> + _regs.r(ax) = tmp; > >>>>> + break; /* cwde */ > >>>>> + } > >>>> > >>>> ... the odd brace placement here, as well as the inconsistency in the types > >>>> you used for the temporary variables (both really could have been unsigned > >>>> int; no need for a fixed-width type). > >>> > >>> Is this what you have in mind? > >> > >> No, and that's also not what the referenced commit did in a similar situation. > >> > >>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c > >>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > >>> @@ -527,8 +527,8 @@ static inline void put_loop_count( > >>> if ( !amd_like(ctxt) && mode_64bit() && ad_bytes == 4 ) \ > >>> { \ > >>> _regs.r(cx) = 0; \ > >>> - if ( extend_si ) _regs.r(si) = _regs.esi; \ > >>> - if ( extend_di ) _regs.r(di) = _regs.edi; \ > >>> + if ( extend_si ) _regs.r(si) = (uint64_t)_regs.esi; \ > >>> + if ( extend_di ) _regs.r(di) = (uint64_t)_regs.edi; \ > >> > >> if ( extend_si ) _regs.r(si) = (uint32_t)_regs.r(si); \ > >> if ( extend_di ) _regs.r(di) = (uint32_t)_regs.r(di); \ > >> > >> After all what the rule requires is that we use _the same_ field on both sides. > > > > I see, thanks Jan. Yes I did try this version and worked as expected. > > Except that ... > > > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > > @@ -527,8 +527,8 @@ static inline void put_loop_count( > > if ( !amd_like(ctxt) && mode_64bit() && ad_bytes == 4 ) \ > > { \ > > _regs.r(cx) = 0; \ > > - if ( extend_si ) _regs.r(si) = _regs.esi; \ > > - if ( extend_di ) _regs.r(di) = _regs.edi; \ > > + if ( extend_si ) _regs.r(si) = (uint32_t)_regs.r(si); \ > > + if ( extend_di ) _regs.r(di) = (uint32_t)_regs.r(di); \ > > } \ > > goto complete_insn; \ > > } \ > > @@ -2029,7 +2029,7 @@ x86_emulate( > > switch ( op_bytes ) > > { > > case 2: _regs.ax = (int8_t)_regs.ax; break; /* cbw */ > > - case 4: _regs.r(ax) = (uint32_t)(int16_t)_regs.ax; break; /* cwde */ > > + case 4: _regs.r(ax) = (int16_t)_regs.r(ax); break; /* cwde */ > > ... the change in casts here renders this wrong now, afaict. We'd sign- > extend from 16 to 64 bits, rather than sign-extending to 32 bits and > then zero-extending to 64. Thanks Jan, this should be: diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c index bee0332bdf..d678855238 100644 --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -2029,7 +2029,7 @@ x86_emulate( switch ( op_bytes ) { case 2: _regs.ax = (int8_t)_regs.ax; break; /* cbw */ - case 4: _regs.r(ax) = (uint32_t)(int16_t)_regs.ax; break; /* cwde */ + case 4: _regs.r(ax) = (uint32_t)(int16_t)_regs.r(ax); break; /* cwde */ case 8: _regs.r(ax) = (int32_t)_regs.r(ax); break; /* cdqe */ } break; I tested this too and passes MISRA From xen-devel-bounces@lists.xenproject.org Thu May 01 00:55:25 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 00:55:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974002.1361992 (Exim 4.92) (envelope-from ) id 1uAICu-0004Rf-5J; Thu, 01 May 2025 00:55:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974002.1361992; Thu, 01 May 2025 00: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 1uAICu-0004RY-2j; Thu, 01 May 2025 00:55:20 +0000 Received: by outflank-mailman (input) for mailman id 974002; Thu, 01 May 2025 00:55:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAICs-0004RS-NS for xen-devel@lists.xenproject.org; Thu, 01 May 2025 00:55:18 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ec44c2b1-2626-11f0-9eb4-5ba50f476ded; Thu, 01 May 2025 02:55:07 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 520BD4A10E; Thu, 1 May 2025 00:55:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 239F4C4CEE7; Thu, 1 May 2025 00:55: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" X-Inumbo-ID: ec44c2b1-2626-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746060905; bh=0iSut6SScykJykpwZeueBQXI4fW87kdwDUpgetlYg+c=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Y5Rv1kpjzeUNvEHPhznO1l5SJ64/5S2g0DGv5mMWEusM5vTYzNF8ncOcxi4ekYktB LlMD55SlWA3/PQP+iXs0Si7DDB22Ta6db+x2BUWNI6+MEVST1BebLCQTyZ+Vz6OaoU OYHMavlEgPGaFhxMfqbjAiAcjY53lYTq6LUWjcIIDTOenm3sIg0sydwbjHT15wmR1R 5gNK9ewo2nIl2ZwccNJ5OaJVVXqJKkF/1+dHuvC2dVZ6d8oXoLJJ6ygMuKlV4K4JOv k9ZKa0Noq6Hsgs3xrZXBIQ4oV23+HW52A03BRWcT0XogmPZ+3HIjXOeBA8pyl2eh3t cDIqfUv0O1u7Q== Date: Wed, 30 Apr 2025 17:55:02 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Kurochko cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v2 0/8] Move parts of Arm's Dom0less to common code In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII The patch series needs to be rebased. Actually, I couldn't find a baseline where to apply patch #2 successfully On Mon, 14 Apr 2025, Oleksii Kurochko wrote: > Some parts of Arm's Dom0less solution could be moved to common code as they are > not truly Arm-specific. > > Most of the code is moved as is, with only minor changes introduced to provide > abstractions that hide Arm-specific details, while maintaining functional > equivalence with original Arm's code. > > There are several open questions: > 1. Probably, the introduced headers currently placed in asm-generic should > instead reside in the xen/include folder. > 2. Perhaps the introduced *.c files should always be placed elsewhere. They > have been put in device-tree common as they somewhat depend on device tree > functionality. > 3. The u64 and u32 types are widely used in the code where device tree > functionality is implemented because these types are used in device tree > function arguments. > Should this be reworked to use uint32_t and uint64_t instead? If so, will it > also be necessary to change the type of variables passed to dt-related > functions, or should the argument types of device tree functions be updated > too? For example: > ``` > u64 mem; > ... > rc = dt_property_read_u64(node, "memory", &mem); > ``` > where dt_property_read_u64 is declared as: > bool dt_property_read_u64(... , u64 *out_value); > 4. Instead of providing init_intc_phandle() (see the patch: [1]), perhaps it > would be better to add a for loop in domain_handle_dtb_bootmodule()? > Something like: > ``` > bool is_intc_phandle_inited = false; > for ( unsigned int i = 0; i < ARRAY_SIZE(intc_names_array); i++ ) > { > if ( dt_node_cmp(name, intc_names_array[i]) == 0 ) > { > uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); > > if ( phandle_intc != 0 ) > kinfo->phandle_intc = phandle_intc; > > is_intc_phandle_inited = true; > break; > } > } > > if ( is_intc_phandle_inited ) continue; > ``` > > [1]] [PATCH v1 9/9] xen/common: dom0less: introduce common dom0less-build.c > > --- > Changes in v2: > - Update cover letter message. > - Rebase on top of the current staging. > - Drop patches: > - asm-generic: move Arm's static-memory.h to asm-generic > - asm-generic: move Arm's static-shmem.h to asm-generic > as in the nearest future there is no real users of STATIC_MEMORY and > STATIC_SHMEM. > - Add new cleanup patch: > [PATCH v2 1/8] xen/arm: drop declaration of handle_device_interrupts() > - All other changes are patch specific. Please check them seprately for each > patch > --- > > Oleksii Kurochko (8): > xen/arm: drop declaration of handle_device_interrupts() > xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common > asm-generic: move parts of Arm's asm/kernel.h to common code > arm/static-shmem.h: drop inclusion of asm/setup.h > asm-generic: move some parts of Arm's domain_build.h to common > xen/common: dom0less: introduce common kernel.c > xen/common: dom0less: introduce common domain-build.c > xen/common: dom0less: introduce common dom0less-build.c > > xen/arch/arm/Kconfig | 10 +- > xen/arch/arm/acpi/domain_build.c | 4 +- > xen/arch/arm/dom0less-build.c | 997 +++------------------- > xen/arch/arm/domain_build.c | 411 +-------- > xen/arch/arm/include/asm/Makefile | 1 + > xen/arch/arm/include/asm/dom0less-build.h | 32 - > xen/arch/arm/include/asm/domain_build.h | 31 +- > xen/arch/arm/include/asm/kernel.h | 126 +-- > xen/arch/arm/include/asm/static-memory.h | 2 +- > xen/arch/arm/include/asm/static-shmem.h | 2 +- > xen/arch/arm/kernel.c | 234 +---- > xen/arch/arm/static-memory.c | 1 + > xen/arch/arm/static-shmem.c | 3 +- > xen/common/Kconfig | 19 + > xen/common/device-tree/Makefile | 3 + > xen/common/device-tree/dom0less-build.c | 891 +++++++++++++++++++ > xen/common/device-tree/domain-build.c | 404 +++++++++ > xen/common/device-tree/dt-overlay.c | 4 +- > xen/common/device-tree/kernel.c | 242 ++++++ > xen/include/asm-generic/dom0less-build.h | 82 ++ > xen/include/xen/fdt-domain-build.h | 77 ++ > xen/include/xen/fdt-kernel.h | 146 ++++ > 22 files changed, 2013 insertions(+), 1709 deletions(-) > delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h > create mode 100644 xen/common/device-tree/dom0less-build.c > create mode 100644 xen/common/device-tree/domain-build.c > create mode 100644 xen/common/device-tree/kernel.c > create mode 100644 xen/include/asm-generic/dom0less-build.h > create mode 100644 xen/include/xen/fdt-domain-build.h > create mode 100644 xen/include/xen/fdt-kernel.h > > -- > 2.49.0 > From xen-devel-bounces@lists.xenproject.org Thu May 01 05:44:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 05:44:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974014.1362003 (Exim 4.92) (envelope-from ) id 1uAMi2-0005lO-Qt; Thu, 01 May 2025 05:43:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974014.1362003; Thu, 01 May 2025 05:43:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAMi2-0005lG-Lb; Thu, 01 May 2025 05:43:46 +0000 Received: by outflank-mailman (input) for mailman id 974014; Thu, 01 May 2025 05:43:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAMi0-0005l9-Gp for xen-devel@lists.xenproject.org; Thu, 01 May 2025 05:43:44 +0000 Received: from mail.zytor.com (unknown [2607:7c80:54:3::138]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 38d8fa67-264f-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 07:43:36 +0200 (CEST) Received: from terminus.zytor.com (terminus.zytor.com [IPv6:2607:7c80:54:3:0:0:0:136]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 5415gf9Y1245658 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 30 Apr 2025 22:42:45 -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" X-Inumbo-ID: 38d8fa67-264f-11f0-9ffb-bf95429c2676 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 5415gf9Y1245658 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025042001; t=1746078168; bh=ID53P6glTV3Qvu7uT3RgHnhRE2lpb6o+W8jMZwlWtkw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IUJUV+MdHEwURcEnpH/eI0iuI0Lc+eYenYN6HTufTcOgmCYV40c0bS/BaQfmv8I3Z cnCCZbRUMK1HMYPuzJ8QBZxInRpB+LASWB0yIGR3JgoEJgKY2s1Oq/oSpEI2pUutJY /RYrJiNUuYYzcyFiOyu9aNm+elgZjSqK6GYBgrpK5IDUh/2dS0IbKw+Hr//qegqnbw kN2mi/oUibngc99YJMU7zb8jwDTBAdzIrnZap3kzvAyK9+vBW5OuweoUHA0Q3dJvdF HifkwUpM4AHO8Z8u3cprxY4hRBEfs+1jps12fYrNFjJ79yngYTDJxOOUyUSTxvEAGE QdXOqpu1JUFvw== From: "Xin Li (Intel)" To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-pm@vger.kernel.org, linux-edac@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, netdev@vger.kernel.org, platform-driver-x86@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, acme@kernel.org, jgross@suse.com, andrew.cooper3@citrix.com, peterz@infradead.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, wei.liu@kernel.org, ajay.kaher@broadcom.com, bcm-kernel-feedback-list@broadcom.com, tony.luck@intel.com, pbonzini@redhat.com, vkuznets@redhat.com, seanjc@google.com, luto@kernel.org, boris.ostrovsky@oracle.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, dapeng1.mi@linux.intel.com, ilpo.jarvinen@linux.intel.com Subject: [PATCH v4A 01/15] x86/msr: Add missing includes of Date: Wed, 30 Apr 2025 22:42:41 -0700 Message-ID: <20250501054241.1245648-1-xin@zytor.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit For some reason, there are some TSC-related functions in the MSR header even though there is a tsc.h header. To facilitate the relocation of rdtsc{,_ordered}() from to and to eventually eliminate the inclusion of in , add to the source files that reference definitions from . Signed-off-by: Xin Li (Intel) Acked-by: Dave Hansen Acked-by: Peter Zijlstra (Intel) Acked-by: Ilpo Järvinen --- Change in v4A: *) Use "git grep -l -e $PATTERN | grep -v -f <(git grep -l -e 'asm/msr\.h')" to ensure ALL required *direct* inclusion of (Ilpo Järvinen). Change in v4: *) Add missing includes in a different patch (Ilpo Järvinen). *) Add all necessary direct inclusions for msr.h (Ilpo Järvinen). Change in v3: * Add a problem statement to the changelog (Dave Hansen). --- arch/x86/coco/sev/core.c | 1 + arch/x86/events/amd/core.c | 1 + arch/x86/events/amd/ibs.c | 1 + arch/x86/events/amd/iommu.c | 2 ++ arch/x86/events/amd/lbr.c | 1 + arch/x86/events/amd/power.c | 1 + arch/x86/events/core.c | 1 + arch/x86/events/intel/bts.c | 1 + arch/x86/events/intel/core.c | 1 + arch/x86/events/intel/cstate.c | 1 + arch/x86/events/intel/ds.c | 1 + arch/x86/events/intel/knc.c | 1 + arch/x86/events/intel/p4.c | 1 + arch/x86/events/intel/p6.c | 1 + arch/x86/events/intel/pt.c | 1 + arch/x86/events/intel/uncore.c | 1 + arch/x86/events/intel/uncore_discovery.c | 1 + arch/x86/events/intel/uncore_nhmex.c | 1 + arch/x86/events/intel/uncore_snb.c | 1 + arch/x86/events/intel/uncore_snbep.c | 1 + arch/x86/events/msr.c | 2 ++ arch/x86/events/perf_event.h | 1 + arch/x86/events/probe.c | 2 ++ arch/x86/events/rapl.c | 1 + arch/x86/events/utils.c | 1 + arch/x86/events/zhaoxin/core.c | 1 + arch/x86/hyperv/hv_apic.c | 1 + arch/x86/hyperv/hv_init.c | 1 + arch/x86/hyperv/hv_spinlock.c | 1 + arch/x86/hyperv/hv_vtl.c | 1 + arch/x86/hyperv/ivm.c | 1 + arch/x86/include/asm/fred.h | 1 + arch/x86/include/asm/kvm_host.h | 1 + arch/x86/include/asm/microcode.h | 2 ++ arch/x86/include/asm/mshyperv.h | 1 + arch/x86/include/asm/msr.h | 1 + arch/x86/include/asm/resctrl.h | 2 ++ arch/x86/include/asm/suspend_32.h | 1 + arch/x86/include/asm/suspend_64.h | 1 + arch/x86/include/asm/switch_to.h | 2 ++ arch/x86/kernel/acpi/sleep.c | 1 + arch/x86/kernel/amd_nb.c | 1 + arch/x86/kernel/apic/apic.c | 1 + arch/x86/kernel/apic/apic_numachip.c | 1 + arch/x86/kernel/cet.c | 1 + arch/x86/kernel/cpu/amd.c | 1 + arch/x86/kernel/cpu/aperfmperf.c | 1 + arch/x86/kernel/cpu/bus_lock.c | 1 + arch/x86/kernel/cpu/feat_ctl.c | 1 + arch/x86/kernel/cpu/hygon.c | 1 + arch/x86/kernel/cpu/mce/inject.c | 1 + arch/x86/kernel/cpu/microcode/core.c | 1 + arch/x86/kernel/cpu/mshyperv.c | 1 + arch/x86/kernel/cpu/resctrl/core.c | 1 + arch/x86/kernel/cpu/resctrl/monitor.c | 1 + arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 1 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 1 + arch/x86/kernel/cpu/sgx/main.c | 1 + arch/x86/kernel/cpu/topology.c | 1 + arch/x86/kernel/cpu/topology_amd.c | 1 + arch/x86/kernel/cpu/tsx.c | 1 + arch/x86/kernel/cpu/zhaoxin.c | 1 + arch/x86/kernel/fpu/core.c | 1 + arch/x86/kernel/fpu/xstate.c | 1 + arch/x86/kernel/fpu/xstate.h | 1 + arch/x86/kernel/fred.c | 1 + arch/x86/kernel/hpet.c | 1 + arch/x86/kernel/kvm.c | 1 + arch/x86/kernel/paravirt.c | 1 + arch/x86/kernel/process.c | 1 + arch/x86/kernel/process_64.c | 1 + arch/x86/kernel/trace_clock.c | 2 +- arch/x86/kernel/traps.c | 1 + arch/x86/kernel/tsc.c | 1 + arch/x86/kernel/tsc_sync.c | 1 + arch/x86/kvm/svm/avic.c | 1 + arch/x86/kvm/svm/sev.c | 1 + arch/x86/kvm/svm/svm.c | 1 + arch/x86/kvm/vmx/nested.c | 1 + arch/x86/kvm/vmx/pmu_intel.c | 1 + arch/x86/kvm/vmx/sgx.c | 1 + arch/x86/kvm/vmx/vmx.c | 1 + arch/x86/lib/insn-eval.c | 1 + arch/x86/lib/kaslr.c | 2 +- arch/x86/mm/mem_encrypt_identity.c | 1 + arch/x86/mm/tlb.c | 1 + arch/x86/pci/amd_bus.c | 1 + arch/x86/pci/mmconfig-shared.c | 3 ++- arch/x86/power/cpu.c | 1 + arch/x86/realmode/init.c | 1 + arch/x86/virt/svm/sev.c | 1 + arch/x86/xen/enlighten_pv.c | 1 + arch/x86/xen/pmu.c | 1 + arch/x86/xen/suspend.c | 1 + drivers/accel/habanalabs/common/habanalabs_ioctl.c | 2 -- drivers/acpi/acpi_extlog.c | 1 + drivers/acpi/processor_perflib.c | 1 + drivers/acpi/processor_throttling.c | 6 +++++- drivers/char/agp/nvidia-agp.c | 1 + drivers/cpufreq/amd-pstate-ut.c | 2 ++ drivers/cpufreq/elanfreq.c | 1 - drivers/cpufreq/sc520_freq.c | 1 - drivers/crypto/ccp/sev-dev.c | 1 + drivers/edac/amd64_edac.c | 1 + drivers/edac/ie31200_edac.c | 1 + drivers/edac/mce_amd.c | 1 + drivers/hwmon/hwmon-vid.c | 4 ++++ drivers/idle/intel_idle.c | 1 + drivers/misc/cs5535-mfgpt.c | 1 + drivers/net/vmxnet3/vmxnet3_drv.c | 4 ++++ drivers/platform/x86/intel/ifs/core.c | 1 + drivers/platform/x86/intel/ifs/load.c | 1 + drivers/platform/x86/intel/ifs/runtest.c | 1 + drivers/platform/x86/intel/pmc/cnp.c | 1 + drivers/platform/x86/intel/speed_select_if/isst_if_common.c | 1 + .../platform/x86/intel/speed_select_if/isst_if_mbox_msr.c | 1 + drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c | 1 + drivers/platform/x86/intel/turbo_max_3.c | 1 + .../platform/x86/intel/uncore-frequency/uncore-frequency.c | 1 + drivers/powercap/intel_rapl_common.c | 1 + drivers/powercap/intel_rapl_msr.c | 1 + .../intel/int340x_thermal/processor_thermal_device.c | 1 + drivers/thermal/intel/intel_tcc_cooling.c | 1 + drivers/thermal/intel/x86_pkg_temp_thermal.c | 1 + drivers/video/fbdev/geode/display_gx.c | 1 + drivers/video/fbdev/geode/gxfb_core.c | 1 + drivers/video/fbdev/geode/lxfb_ops.c | 1 + 127 files changed, 142 insertions(+), 8 deletions(-) diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c index b18a33fe8dd3..85b16a0ee417 100644 --- a/arch/x86/coco/sev/core.c +++ b/arch/x86/coco/sev/core.c @@ -43,6 +43,7 @@ #include #include #include +#include #define DR7_RESET_VALUE 0x400 diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c index cb62b6d12691..79e8453dd051 100644 --- a/arch/x86/events/amd/core.c +++ b/arch/x86/events/amd/core.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include "../perf_event.h" diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c index 82fa755d1b12..20877927b021 100644 --- a/arch/x86/events/amd/ibs.c +++ b/arch/x86/events/amd/ibs.c @@ -15,6 +15,7 @@ #include #include +#include #include "../perf_event.h" diff --git a/arch/x86/events/amd/iommu.c b/arch/x86/events/amd/iommu.c index f8228d8243f7..a721da9987dd 100644 --- a/arch/x86/events/amd/iommu.c +++ b/arch/x86/events/amd/iommu.c @@ -16,6 +16,8 @@ #include #include +#include + #include "../perf_event.h" #include "iommu.h" diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c index 198851985bb7..d24da377df77 100644 --- a/arch/x86/events/amd/lbr.c +++ b/arch/x86/events/amd/lbr.c @@ -1,5 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 #include +#include #include #include "../perf_event.h" diff --git a/arch/x86/events/amd/power.c b/arch/x86/events/amd/power.c index 598a727d823a..dad42790cf7d 100644 --- a/arch/x86/events/amd/power.c +++ b/arch/x86/events/amd/power.c @@ -11,6 +11,7 @@ #include #include #include +#include #include "../perf_event.h" /* Event code: LSB 8 bits, passed in attr->config any other bit is reserved. */ diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 85b55c1dc162..32ff97a6a4ac 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -32,6 +32,7 @@ #include #include +#include #include #include #include diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c index a95e6c91c4d7..ca9f57437d8b 100644 --- a/arch/x86/events/intel/bts.c +++ b/arch/x86/events/intel/bts.c @@ -17,6 +17,7 @@ #include #include +#include #include "../perf_event.h" diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 394fa83b537b..52d7fb5b0329 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -23,6 +23,7 @@ #include #include #include +#include #include "../perf_event.h" diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c index 56b1c391ccc7..ec753e39b007 100644 --- a/arch/x86/events/intel/cstate.c +++ b/arch/x86/events/intel/cstate.c @@ -111,6 +111,7 @@ #include #include #include +#include #include "../perf_event.h" #include "../probe.h" diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 410a8975d1b9..7ba945d3eacc 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include "../perf_event.h" diff --git a/arch/x86/events/intel/knc.c b/arch/x86/events/intel/knc.c index 425f6e6eed89..38904a558128 100644 --- a/arch/x86/events/intel/knc.c +++ b/arch/x86/events/intel/knc.c @@ -5,6 +5,7 @@ #include #include +#include #include "../perf_event.h" diff --git a/arch/x86/events/intel/p4.c b/arch/x86/events/intel/p4.c index 24d811a9608a..aa5202126752 100644 --- a/arch/x86/events/intel/p4.c +++ b/arch/x86/events/intel/p4.c @@ -13,6 +13,7 @@ #include #include #include +#include #include "../perf_event.h" diff --git a/arch/x86/events/intel/p6.c b/arch/x86/events/intel/p6.c index 35917a776bec..6e41de355bd8 100644 --- a/arch/x86/events/intel/p6.c +++ b/arch/x86/events/intel/p6.c @@ -3,6 +3,7 @@ #include #include +#include #include "../perf_event.h" diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c index d579f1092357..f37cce231266 100644 --- a/arch/x86/events/intel/pt.c +++ b/arch/x86/events/intel/pt.c @@ -24,6 +24,7 @@ #include #include #include +#include #include "../perf_event.h" #include "pt.h" diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c index d6070529c58e..c24d21932c91 100644 --- a/arch/x86/events/intel/uncore.c +++ b/arch/x86/events/intel/uncore.c @@ -3,6 +3,7 @@ #include #include +#include #include "uncore.h" #include "uncore_discovery.h" diff --git a/arch/x86/events/intel/uncore_discovery.c b/arch/x86/events/intel/uncore_discovery.c index 4fc3eec325f6..18a3022f26a0 100644 --- a/arch/x86/events/intel/uncore_discovery.c +++ b/arch/x86/events/intel/uncore_discovery.c @@ -5,6 +5,7 @@ */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt +#include #include "uncore.h" #include "uncore_discovery.h" diff --git a/arch/x86/events/intel/uncore_nhmex.c b/arch/x86/events/intel/uncore_nhmex.c index bef9c782c781..8962e7cb21e3 100644 --- a/arch/x86/events/intel/uncore_nhmex.c +++ b/arch/x86/events/intel/uncore_nhmex.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 /* Nehalem-EX/Westmere-EX uncore support */ #include +#include #include "uncore.h" /* NHM-EX event control */ diff --git a/arch/x86/events/intel/uncore_snb.c b/arch/x86/events/intel/uncore_snb.c index afc8ef02a7a9..a1a96833e30e 100644 --- a/arch/x86/events/intel/uncore_snb.c +++ b/arch/x86/events/intel/uncore_snb.c @@ -1,5 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* Nehalem/SandBridge/Haswell/Broadwell/Skylake uncore support */ +#include #include "uncore.h" #include "uncore_discovery.h" diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c index dd53dd87cdec..500913ead670 100644 --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 /* SandyBridge-EP/IvyTown uncore support */ #include +#include #include "uncore.h" #include "uncore_discovery.h" diff --git a/arch/x86/events/msr.c b/arch/x86/events/msr.c index 8970ecef87c5..7f5007a4752a 100644 --- a/arch/x86/events/msr.c +++ b/arch/x86/events/msr.c @@ -3,6 +3,8 @@ #include #include #include +#include + #include "probe.h" enum perf_msr_id { diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h index a5166fa9339b..a8d4e82e3589 100644 --- a/arch/x86/events/perf_event.h +++ b/arch/x86/events/perf_event.h @@ -17,6 +17,7 @@ #include #include #include +#include /* To enable MSR tracing please use the generic trace points. */ diff --git a/arch/x86/events/probe.c b/arch/x86/events/probe.c index fda35cf25528..bb719d0d3f0b 100644 --- a/arch/x86/events/probe.c +++ b/arch/x86/events/probe.c @@ -2,6 +2,8 @@ #include #include #include + +#include #include "probe.h" static umode_t diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c index 7ff52c23d7a1..defd86137f12 100644 --- a/arch/x86/events/rapl.c +++ b/arch/x86/events/rapl.c @@ -65,6 +65,7 @@ #include #include #include +#include #include "perf_event.h" #include "probe.h" diff --git a/arch/x86/events/utils.c b/arch/x86/events/utils.c index dab4ed199227..77fd00b3305e 100644 --- a/arch/x86/events/utils.c +++ b/arch/x86/events/utils.c @@ -2,6 +2,7 @@ #include #include +#include #include "perf_event.h" static int decode_branch_type(struct insn *insn) diff --git a/arch/x86/events/zhaoxin/core.c b/arch/x86/events/zhaoxin/core.c index e299364eb889..91443aba4c7d 100644 --- a/arch/x86/events/zhaoxin/core.c +++ b/arch/x86/events/zhaoxin/core.c @@ -15,6 +15,7 @@ #include #include #include +#include #include "../perf_event.h" diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c index c450e67cb0a4..a079a1427091 100644 --- a/arch/x86/hyperv/hv_apic.c +++ b/arch/x86/hyperv/hv_apic.c @@ -28,6 +28,7 @@ #include #include #include +#include #include diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index ed89867b6fd0..5d27194a2efa 100644 --- a/arch/x86/hyperv/hv_init.c +++ b/arch/x86/hyperv/hv_init.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c index 626f6d4d6253..81b006601370 100644 --- a/arch/x86/hyperv/hv_spinlock.c +++ b/arch/x86/hyperv/hv_spinlock.c @@ -15,6 +15,7 @@ #include #include #include +#include static bool hv_pvspin __initdata = true; diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c index 13242ed8ff16..079b276e5f30 100644 --- a/arch/x86/hyperv/hv_vtl.c +++ b/arch/x86/hyperv/hv_vtl.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include <../kernel/smpboot.h> diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c index 1b8a2415183b..8209de792388 100644 --- a/arch/x86/hyperv/ivm.c +++ b/arch/x86/hyperv/ivm.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #ifdef CONFIG_AMD_MEM_ENCRYPT diff --git a/arch/x86/include/asm/fred.h b/arch/x86/include/asm/fred.h index 2a29e5216881..12b34d5b2953 100644 --- a/arch/x86/include/asm/fred.h +++ b/arch/x86/include/asm/fred.h @@ -9,6 +9,7 @@ #include #include +#include #include /* diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 9af20b3c0f1d..f1b5f7eceda0 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -34,6 +34,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h index 263ea3dd0001..107a1aaa211b 100644 --- a/arch/x86/include/asm/microcode.h +++ b/arch/x86/include/asm/microcode.h @@ -2,6 +2,8 @@ #ifndef _ASM_X86_MICROCODE_H #define _ASM_X86_MICROCODE_H +#include + struct cpu_signature { unsigned int sig; unsigned int pf; diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h index bab5ccfc60a7..15d00dace70f 100644 --- a/arch/x86/include/asm/mshyperv.h +++ b/arch/x86/include/asm/mshyperv.h @@ -8,6 +8,7 @@ #include #include #include +#include #include /* diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h index 2ccc78ebc3d7..72a9ebc99078 100644 --- a/arch/x86/include/asm/msr.h +++ b/arch/x86/include/asm/msr.h @@ -12,6 +12,7 @@ #include #include +#include #include struct msr_info { diff --git a/arch/x86/include/asm/resctrl.h b/arch/x86/include/asm/resctrl.h index 011bf67a1866..bd6afe805cf6 100644 --- a/arch/x86/include/asm/resctrl.h +++ b/arch/x86/include/asm/resctrl.h @@ -9,6 +9,8 @@ #include #include +#include + /* * This value can never be a valid CLOSID, and is used when mapping a * (closid, rmid) pair to an index and back. On x86 only the RMID is diff --git a/arch/x86/include/asm/suspend_32.h b/arch/x86/include/asm/suspend_32.h index d8416b3bf832..e8e5aab06255 100644 --- a/arch/x86/include/asm/suspend_32.h +++ b/arch/x86/include/asm/suspend_32.h @@ -9,6 +9,7 @@ #include #include +#include /* image of the saved processor state */ struct saved_context { diff --git a/arch/x86/include/asm/suspend_64.h b/arch/x86/include/asm/suspend_64.h index 54df06687d83..b512f9665f78 100644 --- a/arch/x86/include/asm/suspend_64.h +++ b/arch/x86/include/asm/suspend_64.h @@ -9,6 +9,7 @@ #include #include +#include /* * Image of the saved processor state, used by the low level ACPI suspend to diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h index 75248546403d..4f21df7af715 100644 --- a/arch/x86/include/asm/switch_to.h +++ b/arch/x86/include/asm/switch_to.h @@ -52,6 +52,8 @@ do { \ } while (0) #ifdef CONFIG_X86_32 +#include + static inline void refresh_sysenter_cs(struct thread_struct *thread) { /* Only happens when SEP is enabled, no need to test "SEP"arately: */ diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c index 6dfecb27b846..91fa262f0e30 100644 --- a/arch/x86/kernel/acpi/sleep.c +++ b/arch/x86/kernel/acpi/sleep.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c index dc389ca052b7..4973a10d74f5 100644 --- a/arch/x86/kernel/amd_nb.c +++ b/arch/x86/kernel/amd_nb.c @@ -14,6 +14,7 @@ #include #include #include +#include static u32 *flush_words; diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index a05871c85183..d73ba5a7b623 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -59,6 +59,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/x86/kernel/apic/apic_numachip.c b/arch/x86/kernel/apic/apic_numachip.c index fcfef701c17a..e272bc7fdc8e 100644 --- a/arch/x86/kernel/apic/apic_numachip.c +++ b/arch/x86/kernel/apic/apic_numachip.c @@ -14,6 +14,7 @@ #include #include +#include #include #include diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c index d897aadd1d44..99444409c026 100644 --- a/arch/x86/kernel/cet.c +++ b/arch/x86/kernel/cet.c @@ -2,6 +2,7 @@ #include #include +#include #include enum cp_error_code { diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 0bbe79862aa6..3bca79feb23f 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #ifdef CONFIG_X86_64 diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c index e99892aad628..a315b0627dfb 100644 --- a/arch/x86/kernel/cpu/aperfmperf.c +++ b/arch/x86/kernel/cpu/aperfmperf.c @@ -20,6 +20,7 @@ #include #include #include +#include #include "cpu.h" diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c index a18d0f2ea832..981f8b1f0792 100644 --- a/arch/x86/kernel/cpu/bus_lock.c +++ b/arch/x86/kernel/cpu/bus_lock.c @@ -10,6 +10,7 @@ #include #include #include +#include enum split_lock_detect_state { sld_off = 0, diff --git a/arch/x86/kernel/cpu/feat_ctl.c b/arch/x86/kernel/cpu/feat_ctl.c index 441174844e01..d69757246bde 100644 --- a/arch/x86/kernel/cpu/feat_ctl.c +++ b/arch/x86/kernel/cpu/feat_ctl.c @@ -4,6 +4,7 @@ #include #include #include +#include #include #include diff --git a/arch/x86/kernel/cpu/hygon.c b/arch/x86/kernel/cpu/hygon.c index 21541e310c2c..2154f12766fb 100644 --- a/arch/x86/kernel/cpu/hygon.c +++ b/arch/x86/kernel/cpu/hygon.c @@ -15,6 +15,7 @@ #include #include #include +#include #include "cpu.h" diff --git a/arch/x86/kernel/cpu/mce/inject.c b/arch/x86/kernel/cpu/mce/inject.c index 338aeee95bd2..e13f533e31e6 100644 --- a/arch/x86/kernel/cpu/mce/inject.c +++ b/arch/x86/kernel/cpu/mce/inject.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c index b3658d11e7b6..793e2927d0fa 100644 --- a/arch/x86/kernel/cpu/microcode/core.c +++ b/arch/x86/kernel/cpu/microcode/core.c @@ -37,6 +37,7 @@ #include #include #include +#include #include #include "internal.h" diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c index b924befe8d6e..c78f860419d6 100644 --- a/arch/x86/kernel/cpu/mshyperv.c +++ b/arch/x86/kernel/cpu/mshyperv.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c index 280d6900726b..d987b11c168c 100644 --- a/arch/x86/kernel/cpu/resctrl/core.c +++ b/arch/x86/kernel/cpu/resctrl/core.c @@ -22,6 +22,7 @@ #include #include +#include #include #include "internal.h" diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c index f73a74945ffa..591b0b44d260 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -23,6 +23,7 @@ #include #include +#include #include #include "internal.h" diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c index 2a82eb6a0376..26c354bdea07 100644 --- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c +++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c @@ -25,6 +25,7 @@ #include #include #include +#include #include "../../events/perf_event.h" /* For X86_CONFIG() */ #include "internal.h" diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c index 26f4d820ee6e..9acd7f320ce3 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -28,6 +28,7 @@ #include +#include #include #include "internal.h" diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c index 40967d8f995a..6722b2fc82cf 100644 --- a/arch/x86/kernel/cpu/sgx/main.c +++ b/arch/x86/kernel/cpu/sgx/main.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include "driver.h" #include "encl.h" diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index 6e1885dece0f..e35ccdc84910 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include "cpu.h" diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c index 535dcf511096..f78d38510027 100644 --- a/arch/x86/kernel/cpu/topology_amd.c +++ b/arch/x86/kernel/cpu/topology_amd.c @@ -3,6 +3,7 @@ #include #include +#include #include #include "cpu.h" diff --git a/arch/x86/kernel/cpu/tsx.c b/arch/x86/kernel/cpu/tsx.c index b0a9c9e9d029..49782724a943 100644 --- a/arch/x86/kernel/cpu/tsx.c +++ b/arch/x86/kernel/cpu/tsx.c @@ -12,6 +12,7 @@ #include #include +#include #include "cpu.h" diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c index 90eba7eb5335..89b1c8a70fe8 100644 --- a/arch/x86/kernel/cpu/zhaoxin.c +++ b/arch/x86/kernel/cpu/zhaoxin.c @@ -4,6 +4,7 @@ #include #include +#include #include "cpu.h" diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index 985dfffe28c1..e92d27324d9a 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 2bd87b788630..86d690afb63c 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -21,6 +21,7 @@ #include #include +#include #include #include #include diff --git a/arch/x86/kernel/fpu/xstate.h b/arch/x86/kernel/fpu/xstate.h index 5e5d35027f13..f705bd355ea2 100644 --- a/arch/x86/kernel/fpu/xstate.h +++ b/arch/x86/kernel/fpu/xstate.h @@ -5,6 +5,7 @@ #include #include #include +#include #ifdef CONFIG_X86_64 DECLARE_PER_CPU(u64, xfd_state); diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c index 10b0169f3fc1..816187da3a47 100644 --- a/arch/x86/kernel/fred.c +++ b/arch/x86/kernel/fred.c @@ -3,6 +3,7 @@ #include #include +#include #include #include diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index cc5d12232216..c9982a7c9536 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -12,6 +12,7 @@ #include #include #include +#include #undef pr_fmt #define pr_fmt(fmt) "hpet: " fmt diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 44a45df7200a..27f7192e1c61 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index 1ccd05d8999f..015bf298434f 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -33,6 +33,7 @@ #include #include #include +#include /* stub always returning 0. */ DEFINE_ASM_FUNC(paravirt_ret0, "xor %eax,%eax", .entry.text); diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index c168f99b5f0b..bd50249cff50 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -52,6 +52,7 @@ #include #include #include +#include #include #include "process.h" diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 24e1ccf22912..cfa9c031de91 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -57,6 +57,7 @@ #include #include #include +#include #ifdef CONFIG_IA32_EMULATION /* Not included via unistd.h */ #include diff --git a/arch/x86/kernel/trace_clock.c b/arch/x86/kernel/trace_clock.c index b8e7abe00b06..708d61743d15 100644 --- a/arch/x86/kernel/trace_clock.c +++ b/arch/x86/kernel/trace_clock.c @@ -4,7 +4,7 @@ */ #include #include -#include +#include /* * trace_clock_x86_tsc(): A clock that is just the cycle counter. diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 823410aaf429..ca43eb5a02a3 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -68,6 +68,7 @@ #include #include #include +#include #ifdef CONFIG_X86_64 #include diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index 160fef71b9a3..5d3a764ba77c 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/x86/kernel/tsc_sync.c b/arch/x86/kernel/tsc_sync.c index f1c7a86dbf49..ec3aa340d351 100644 --- a/arch/x86/kernel/tsc_sync.c +++ b/arch/x86/kernel/tsc_sync.c @@ -21,6 +21,7 @@ #include #include #include +#include #include struct tsc_adjust { diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 51842100f6d2..5f99762fb2f7 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -20,6 +20,7 @@ #include #include +#include #include "trace.h" #include "lapic.h" diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index a4aabd666665..4b607cc377c9 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include "mmu.h" diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 67657b3a36ce..c23f620989ed 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -31,6 +31,7 @@ #include #include +#include #include #include #include diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index a7fea622e204..d268224227f0 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -6,6 +6,7 @@ #include #include +#include #include "x86.h" #include "cpuid.h" diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c index 5e0bb821c7bc..231a9633359c 100644 --- a/arch/x86/kvm/vmx/pmu_intel.c +++ b/arch/x86/kvm/vmx/pmu_intel.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include "x86.h" #include "cpuid.h" diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c index 949864259ee6..df1d0cf76947 100644 --- a/arch/x86/kvm/vmx/sgx.c +++ b/arch/x86/kvm/vmx/sgx.c @@ -2,6 +2,7 @@ /* Copyright(c) 2021 Intel Corporation. */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt +#include #include #include "x86.h" diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index cd0d6c1fcf9c..d8412cfdb18e 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -46,6 +46,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c index da5af3cc25b1..dbe0fbf0037f 100644 --- a/arch/x86/lib/insn-eval.c +++ b/arch/x86/lib/insn-eval.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #undef pr_fmt diff --git a/arch/x86/lib/kaslr.c b/arch/x86/lib/kaslr.c index a58f451a7dd3..b5893928d55c 100644 --- a/arch/x86/lib/kaslr.c +++ b/arch/x86/lib/kaslr.c @@ -8,7 +8,7 @@ */ #include #include -#include +#include #include #include #include diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c index 5eecdd92da10..afda349db35b 100644 --- a/arch/x86/mm/mem_encrypt_identity.c +++ b/arch/x86/mm/mem_encrypt_identity.c @@ -44,6 +44,7 @@ #include #include #include +#include #include "mm_internal.h" diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index b1d521201e0b..6a9befef9fb8 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c index 6158f652a7cd..5154915bf50f 100644 --- a/arch/x86/pci/amd_bus.c +++ b/arch/x86/pci/amd_bus.c @@ -6,6 +6,7 @@ #include #include +#include #include #include diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c index 39255f0eb14d..1f4522325920 100644 --- a/arch/x86/pci/mmconfig-shared.c +++ b/arch/x86/pci/mmconfig-shared.c @@ -22,9 +22,10 @@ #include #include #include +#include #include +#include #include -#include /* Indicate if the ECAM resources have been placed into the resource table */ static bool pci_mmcfg_running_state; diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c index d5a7b3bc2453..916441f5e85c 100644 --- a/arch/x86/power/cpu.c +++ b/arch/x86/power/cpu.c @@ -27,6 +27,7 @@ #include #include #include +#include #include #ifdef CONFIG_X86_32 diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c index 263787b4800c..ed5c63c0b4e5 100644 --- a/arch/x86/realmode/init.c +++ b/arch/x86/realmode/init.c @@ -9,6 +9,7 @@ #include #include #include +#include #include struct real_mode_header *real_mode_header; diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c index 334177c89df0..76926f75e9bf 100644 --- a/arch/x86/virt/svm/sev.c +++ b/arch/x86/virt/svm/sev.c @@ -30,6 +30,7 @@ #include #include #include +#include /* * The RMP entry information as returned by the RMPREAD instruction. diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 846b5737d320..8ddd9e535f99 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -61,6 +61,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c index f06987b0efc3..3cb566d4aaad 100644 --- a/arch/x86/xen/pmu.c +++ b/arch/x86/xen/pmu.c @@ -2,6 +2,7 @@ #include #include +#include #include #include #include diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c index 7bb3ac2d5ac8..ba2f17e64321 100644 --- a/arch/x86/xen/suspend.c +++ b/arch/x86/xen/suspend.c @@ -13,6 +13,7 @@ #include #include #include +#include #include "xen-ops.h" diff --git a/drivers/accel/habanalabs/common/habanalabs_ioctl.c b/drivers/accel/habanalabs/common/habanalabs_ioctl.c index 8729a0c57d78..dc80ca921d90 100644 --- a/drivers/accel/habanalabs/common/habanalabs_ioctl.c +++ b/drivers/accel/habanalabs/common/habanalabs_ioctl.c @@ -17,8 +17,6 @@ #include #include -#include - /* make sure there is space for all the signed info */ static_assert(sizeof(struct cpucp_info) <= SEC_DEV_INFO_BUF_SZ); diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c index 8465822b6672..f6b9562779de 100644 --- a/drivers/acpi/acpi_extlog.c +++ b/drivers/acpi/acpi_extlog.c @@ -15,6 +15,7 @@ #include #include #include +#include #include "apei/apei-internal.h" #include diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c index 53996f1a2d80..64b8d1e19594 100644 --- a/drivers/acpi/processor_perflib.c +++ b/drivers/acpi/processor_perflib.c @@ -20,6 +20,7 @@ #include #ifdef CONFIG_X86 #include +#include #endif #define ACPI_PROCESSOR_FILE_PERFORMANCE "performance" diff --git a/drivers/acpi/processor_throttling.c b/drivers/acpi/processor_throttling.c index 00d045e5f524..ecd7fe256153 100644 --- a/drivers/acpi/processor_throttling.c +++ b/drivers/acpi/processor_throttling.c @@ -18,9 +18,13 @@ #include #include #include +#include #include #include -#include +#include +#ifdef CONFIG_X86 +#include +#endif /* ignore_tpc: * 0 -> acpi processor driver doesn't ignore _TPC values diff --git a/drivers/char/agp/nvidia-agp.c b/drivers/char/agp/nvidia-agp.c index e424360fb4a1..4787391bb6b4 100644 --- a/drivers/char/agp/nvidia-agp.c +++ b/drivers/char/agp/nvidia-agp.c @@ -11,6 +11,7 @@ #include #include #include +#include #include "agp.h" /* NVIDIA registers */ diff --git a/drivers/cpufreq/amd-pstate-ut.c b/drivers/cpufreq/amd-pstate-ut.c index 707fa81c749f..c8d031b297d2 100644 --- a/drivers/cpufreq/amd-pstate-ut.c +++ b/drivers/cpufreq/amd-pstate-ut.c @@ -31,6 +31,8 @@ #include +#include + #include "amd-pstate.h" diff --git a/drivers/cpufreq/elanfreq.c b/drivers/cpufreq/elanfreq.c index 36494b855e41..fc5a58088b35 100644 --- a/drivers/cpufreq/elanfreq.c +++ b/drivers/cpufreq/elanfreq.c @@ -21,7 +21,6 @@ #include #include -#include #include #include diff --git a/drivers/cpufreq/sc520_freq.c b/drivers/cpufreq/sc520_freq.c index 103d2519dff7..b360f03a116f 100644 --- a/drivers/cpufreq/sc520_freq.c +++ b/drivers/cpufreq/sc520_freq.c @@ -21,7 +21,6 @@ #include #include -#include #define MMCR_BASE 0xfffef000 /* The default base address */ #define OFFS_CPUCTL 0x2 /* CPU Control Register */ diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index bb8a25ef5b43..ec8b37a7f40c 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "psp-dev.h" #include "sev-dev.h" diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c index db758aa900b0..622385218735 100644 --- a/drivers/edac/amd64_edac.c +++ b/drivers/edac/amd64_edac.c @@ -4,6 +4,7 @@ #include "amd64_edac.h" #include #include +#include static struct edac_pci_ctl_info *pci_ctl; diff --git a/drivers/edac/ie31200_edac.c b/drivers/edac/ie31200_edac.c index 204834149579..5ddd83dc94ba 100644 --- a/drivers/edac/ie31200_edac.c +++ b/drivers/edac/ie31200_edac.c @@ -52,6 +52,7 @@ #include #include +#include #include "edac_module.h" #define EDAC_MOD_STR "ie31200_edac" diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c index 50d74d3bf0f5..af3c12284a1e 100644 --- a/drivers/edac/mce_amd.c +++ b/drivers/edac/mce_amd.c @@ -3,6 +3,7 @@ #include #include +#include #include "mce_amd.h" diff --git a/drivers/hwmon/hwmon-vid.c b/drivers/hwmon/hwmon-vid.c index 6d1175a51832..2df4956296ed 100644 --- a/drivers/hwmon/hwmon-vid.c +++ b/drivers/hwmon/hwmon-vid.c @@ -15,6 +15,10 @@ #include #include +#ifdef CONFIG_X86 +#include +#endif + /* * Common code for decoding VID pins. * diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index 517b28a85560..6a1712b50c7f 100644 --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@ -56,6 +56,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/misc/cs5535-mfgpt.c b/drivers/misc/cs5535-mfgpt.c index 18fc1aaa5cdd..2b6778d8d166 100644 --- a/drivers/misc/cs5535-mfgpt.c +++ b/drivers/misc/cs5535-mfgpt.c @@ -16,6 +16,7 @@ #include #include #include +#include #define DRV_NAME "cs5535-mfgpt" diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c index 3df6aabc7e33..7edd0b5e0e77 100644 --- a/drivers/net/vmxnet3/vmxnet3_drv.c +++ b/drivers/net/vmxnet3/vmxnet3_drv.c @@ -27,6 +27,10 @@ #include #include +#ifdef CONFIG_X86 +#include +#endif + #include "vmxnet3_int.h" #include "vmxnet3_xdp.h" diff --git a/drivers/platform/x86/intel/ifs/core.c b/drivers/platform/x86/intel/ifs/core.c index c4328a7ae083..b73e582128c9 100644 --- a/drivers/platform/x86/intel/ifs/core.c +++ b/drivers/platform/x86/intel/ifs/core.c @@ -8,6 +8,7 @@ #include #include +#include #include "ifs.h" diff --git a/drivers/platform/x86/intel/ifs/load.c b/drivers/platform/x86/intel/ifs/load.c index 0289391eccde..50f1fdf7dfed 100644 --- a/drivers/platform/x86/intel/ifs/load.c +++ b/drivers/platform/x86/intel/ifs/load.c @@ -5,6 +5,7 @@ #include #include #include +#include #include "ifs.h" diff --git a/drivers/platform/x86/intel/ifs/runtest.c b/drivers/platform/x86/intel/ifs/runtest.c index 6b6ed7be461a..dfc119d7354d 100644 --- a/drivers/platform/x86/intel/ifs/runtest.c +++ b/drivers/platform/x86/intel/ifs/runtest.c @@ -7,6 +7,7 @@ #include #include #include +#include #include "ifs.h" diff --git a/drivers/platform/x86/intel/pmc/cnp.c b/drivers/platform/x86/intel/pmc/cnp.c index 547bdf1ab02d..efea4e1ba52b 100644 --- a/drivers/platform/x86/intel/pmc/cnp.c +++ b/drivers/platform/x86/intel/pmc/cnp.c @@ -10,6 +10,7 @@ #include #include +#include #include "core.h" /* Cannon Lake: PGD PFET Enable Ack Status Register(s) bitmap */ diff --git a/drivers/platform/x86/intel/speed_select_if/isst_if_common.c b/drivers/platform/x86/intel/speed_select_if/isst_if_common.c index 44dcd165b4c0..8a5713593811 100644 --- a/drivers/platform/x86/intel/speed_select_if/isst_if_common.c +++ b/drivers/platform/x86/intel/speed_select_if/isst_if_common.c @@ -21,6 +21,7 @@ #include #include +#include #include "isst_if_common.h" 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 78989f649aea..22745b217c6f 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 @@ -18,6 +18,7 @@ #include #include #include +#include #include "isst_if_common.h" 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 0b8ef0cfaf80..4d30d5360c8f 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 @@ -27,6 +27,7 @@ #include #include #include +#include #include #include "isst_tpmi_core.h" diff --git a/drivers/platform/x86/intel/turbo_max_3.c b/drivers/platform/x86/intel/turbo_max_3.c index 7e538bbd5b50..b5af3e91ba04 100644 --- a/drivers/platform/x86/intel/turbo_max_3.c +++ b/drivers/platform/x86/intel/turbo_max_3.c @@ -17,6 +17,7 @@ #include #include +#include #define MSR_OC_MAILBOX 0x150 #define MSR_OC_MAILBOX_CMD_OFFSET 32 diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c index 6f873765d2d1..96f854c21bb5 100644 --- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c +++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c @@ -21,6 +21,7 @@ #include #include #include +#include #include "uncore-frequency-common.h" diff --git a/drivers/powercap/intel_rapl_common.c b/drivers/powercap/intel_rapl_common.c index 5ab3feb29686..e3be40adc0d7 100644 --- a/drivers/powercap/intel_rapl_common.c +++ b/drivers/powercap/intel_rapl_common.c @@ -28,6 +28,7 @@ #include #include #include +#include /* bitmasks for RAPL MSRs, used by primitive access functions */ #define ENERGY_STATUS_MASK 0xffffffff diff --git a/drivers/powercap/intel_rapl_msr.c b/drivers/powercap/intel_rapl_msr.c index 6d5853db17ad..8ad2115d65f6 100644 --- a/drivers/powercap/intel_rapl_msr.c +++ b/drivers/powercap/intel_rapl_msr.c @@ -24,6 +24,7 @@ #include #include +#include /* Local defines */ #define MSR_PLATFORM_POWER_LIMIT 0x0000065C diff --git a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c index b0249468b844..57cf46f69669 100644 --- a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c +++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c @@ -9,6 +9,7 @@ #include #include #include +#include #include "int340x_thermal_zone.h" #include "processor_thermal_device.h" #include "../intel_soc_dts_iosf.h" diff --git a/drivers/thermal/intel/intel_tcc_cooling.c b/drivers/thermal/intel/intel_tcc_cooling.c index 0394897e83cf..f352ecafbedf 100644 --- a/drivers/thermal/intel/intel_tcc_cooling.c +++ b/drivers/thermal/intel/intel_tcc_cooling.c @@ -11,6 +11,7 @@ #include #include #include +#include #define TCC_PROGRAMMABLE BIT(30) #define TCC_LOCKED BIT(31) diff --git a/drivers/thermal/intel/x86_pkg_temp_thermal.c b/drivers/thermal/intel/x86_pkg_temp_thermal.c index 496abf8e55e0..4894a26b1e4e 100644 --- a/drivers/thermal/intel/x86_pkg_temp_thermal.c +++ b/drivers/thermal/intel/x86_pkg_temp_thermal.c @@ -20,6 +20,7 @@ #include #include +#include #include "thermal_interrupt.h" diff --git a/drivers/video/fbdev/geode/display_gx.c b/drivers/video/fbdev/geode/display_gx.c index b5f25dffd274..099322cefce0 100644 --- a/drivers/video/fbdev/geode/display_gx.c +++ b/drivers/video/fbdev/geode/display_gx.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include "gxfb.h" diff --git a/drivers/video/fbdev/geode/gxfb_core.c b/drivers/video/fbdev/geode/gxfb_core.c index 2b27d6540805..8d69be7c9d31 100644 --- a/drivers/video/fbdev/geode/gxfb_core.c +++ b/drivers/video/fbdev/geode/gxfb_core.c @@ -29,6 +29,7 @@ #include #include +#include #include #include "gxfb.h" diff --git a/drivers/video/fbdev/geode/lxfb_ops.c b/drivers/video/fbdev/geode/lxfb_ops.c index a27531b5de11..2e33da9849b0 100644 --- a/drivers/video/fbdev/geode/lxfb_ops.c +++ b/drivers/video/fbdev/geode/lxfb_ops.c @@ -11,6 +11,7 @@ #include #include +#include #include "lxfb.h" /* TODO -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Thu May 01 11:02:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 11:02:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974057.1362013 (Exim 4.92) (envelope-from ) id 1uARgV-00043a-Vb; Thu, 01 May 2025 11:02:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974057.1362013; Thu, 01 May 2025 11:02: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 1uARgV-00043T-RM; Thu, 01 May 2025 11:02:31 +0000 Received: by outflank-mailman (input) for mailman id 974057; Thu, 01 May 2025 10:49:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uARU2-0001h1-Lx for xen-devel@lists.xenproject.org; Thu, 01 May 2025 10:49:38 +0000 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [2a00:1450:4864:20::52d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f9916abb-2679-11f0-9eb4-5ba50f476ded; Thu, 01 May 2025 12:49:37 +0200 (CEST) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5edc07c777eso1092443a12.3 for ; Thu, 01 May 2025 03:49:37 -0700 (PDT) Received: from eddie5.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad0da55b3d4sm22400566b.153.2025.05.01.03.49.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 May 2025 03:49: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" X-Inumbo-ID: f9916abb-2679-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1746096576; x=1746701376; 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; bh=Iicefiwaxi+sdxCzITJJy6lYLk+i0arTwggOQzyC0hY=; b=c0fp9NZM3vD1SC6fNvdKbnDhfRO2ocaU+UXepgTDeiiCREHCR7nFXLsMCLDToM9mc6 ye+pOKv/7Zuvs+9QTwlBXc6U8QhAtbBVSivaLOOvPRj7i4BnxWSnoA0DVyZIRjecJKHm yoENqxtCTD5FQNVwAL0rag/1Xthtzwz67PsG0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746096576; x=1746701376; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Iicefiwaxi+sdxCzITJJy6lYLk+i0arTwggOQzyC0hY=; b=P8vInEUObGQ08cbWzrEoRMFBakvGJ8Y6AMFJQ3vu5dSQDEoyr6GuEdkrwZdv5NfKtm nF4MsVj4je26A6vRYoa0nogAdeh8orHgwa3pQpYpDtDeL2WquK9LhXL792yzs/LCZ3Ds FO2FVfXflyVn7ylngBhP+SrESh0ML/KKXN7+Q/CCRzAe7BpEgDQ11yxPr7J8USeLd5aw /RlaKpnYD2fl7yxsvu8ki+Cnlc8CAMfrJH1YFTowVaEv83KTpp+PpnMHr6ItSuM58Klz 6HM8euJ3fQ4r4K6ogaog8Z/kKgvMS1f5iTpx69ei76t6EGkpKrGqlKauKGCFNgToR5LZ 4NPQ== X-Gm-Message-State: AOJu0YwOfDanS1iEM09ihXo6e++0s1lDuD1ozmVy80FhQrCupDr2FMS4 MZd4SF0SNHpcNCcOe2H+oEvSjgDLMuS34r9Nq98HHcEtd7cu7u74/3kSW6zn404xiKJ6eNoonsJ YVQeXkA== X-Gm-Gg: ASbGncvIOm8jQu/cdgoKPe/qmGd797CWBPZePkSLIataAVsBdoO7bvsTB6x5rbQ8XQN b0v151fW4k1JMfbkBNUcyQBL1jS1fWwfntukrlOliNkjQeCGoBtrj0WprNIpXCjJ4ejU6/O4F+Y t4jy46qYaqAysYw1H5zcyjb+44fzIl9NVRu9FazzGSnEk5LsVAPu/zgCqxGCD0VTx86E//Gr2fL K7AoJculwTl7U9IL8TM4NMsAN5A8AqCDxDwBPEO3HI6pFNec8D467HUaM4U8DfiLnqhR2NaEy+q P7b5NjLpsmttIDckIryt0/Xbojoqo8yBRYlwHjhCzOqGQXXsKIkR1rQGJ8AONm2S X-Google-Smtp-Source: AGHT+IGGoug9Jx7TD9+t+RTEh2Le1hOkmF0XmVFVSlgfL/fu8Uno4oAzSCoT3j1lOoKTC/LV0umoXg== X-Received: by 2002:a17:907:6e93:b0:ac7:150b:57b2 with SMTP id a640c23a62f3a-acedc70a042mr544267866b.41.1746096576117; Thu, 01 May 2025 03:49:36 -0700 (PDT) From: Gerald Elder-Vass To: xen-devel@lists.xenproject.org Cc: Gerald Elder-Vass , Frediano Ziglio , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [XEN PATCH] sbat: Add SBAT section to the xen binary Date: Thu, 1 May 2025 10:49:25 +0000 Message-ID: <20250501104925.228351-1-gerald.elder-vass@cloud.com> X-Mailer: git-send-email 2.47.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The SBAT section provides a way for the binary to declare a generation id for its upstream source and any vendor changes applied. A compatible loader can then revoke vulnerable binaries by generation, using the binary's declared generation id(s) to determine if it is safe to load. More information about SBAT is available here: https://github.com/rhboot/shim/blob/main/SBAT.md Vendors should append a custom line onto sbat.csv(.in) with their vendor specific sbat data. Populate the SBAT section in the Xen binary by using the information in xen/arch/x86/sbat.csv.in Signed-off-by: Gerald Elder-Vass Signed-off-by: Frediano Ziglio Tested-by: Gerald Elder-Vass diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index d902fb7accd9..6db7475c2c23 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -74,6 +74,7 @@ obj-$(CONFIG_TBOOT) += tboot.o obj-y += hpet.o obj-y += vm_event.o obj-y += xstate.o +obj-y += sbat_data.o ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y) obj-y += domctl.o @@ -277,6 +278,12 @@ $(obj)/efi.lds: AFLAGS-y += -DEFI $(obj)/xen.lds $(obj)/efi.lds: $(src)/xen.lds.S FORCE $(call if_changed_dep,cpp_lds_S) +$(obj)/sbat.csv: $(src)/sbat.csv.in + sed "s/@@VERSION@@/${XEN_FULLVERSION}/" $< > $@ + +$(obj)/sbat_data.o: $(obj)/sbat.csv + $(OBJCOPY) -I binary -O elf64-x86-64 --rename-section .data=.sbat,readonly,data,contents $< $@ + clean-files := \ include/asm/asm-macros.* \ $(objtree)/.xen-syms.[0-9]* \ diff --git a/xen/arch/x86/sbat.csv.in b/xen/arch/x86/sbat.csv.in new file mode 100644 index 000000000000..7cdc33dbd998 --- /dev/null +++ b/xen/arch/x86/sbat.csv.in @@ -0,0 +1,2 @@ +sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md +xen,1,Linux Foundation,xen,@@VERSION@@,https://xenproject.org/ diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S index 9a1dfe1b340a..e6405941e1b7 100644 --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -343,6 +343,8 @@ SECTIONS *(.reloc) __base_relocs_end = .; } + + .sbat (NOLOAD) : { *(.sbat) } #elif defined(XEN_BUILD_EFI) /* * Due to the way EFI support is currently implemented, these two symbols diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h index a17810bb286f..756f97d48183 100644 --- a/xen/include/xen/xen.lds.h +++ b/xen/include/xen/xen.lds.h @@ -92,7 +92,8 @@ *(.comment.*) \ *(.note.*) #else -#define DISCARD_EFI_SECTIONS +#define DISCARD_EFI_SECTIONS \ + *(.sbat) #endif /* Sections to be discarded. */ From xen-devel-bounces@lists.xenproject.org Thu May 01 11:03:24 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 11:03:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974067.1362023 (Exim 4.92) (envelope-from ) id 1uARhM-0004Wo-6X; Thu, 01 May 2025 11:03:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974067.1362023; Thu, 01 May 2025 11:03:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uARhM-0004Wh-3f; Thu, 01 May 2025 11:03:24 +0000 Received: by outflank-mailman (input) for mailman id 974067; Thu, 01 May 2025 11:03:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uARhK-0004WU-4l for xen-devel@lists.xenproject.org; Thu, 01 May 2025 11:03:22 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1uARhJ-000xQl-1F; Thu, 01 May 2025 11:03:21 +0000 Received: from [15.248.2.31] (helo=[10.24.66.15]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uARhJ-00G80t-0E; Thu, 01 May 2025 11:03: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=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=2bfAWTc3WSg1t/aQgSpvC/keNzvKcxaROH18zymswN0=; b=eDv/qbMY0UOLQMmPoGVwjJ/oqr CtE41BjxJGyZp1r+8/qclMxufwDEa/hQ+9JhnX0uSU/ldOm3r9DwnOs0Kwz9A69s0+h6uA7CaR0QF fNhxTSG0qPR/bgLZTYmJwIQXGzHG8POx2wkUNj/RjIYbhK3V+SHCHpIncBFJldJr8I38=; Message-ID: <1ab8612c-b47c-4b61-b9cf-d90b2363b19b@xen.org> Date: Thu, 1 May 2025 12:03:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: move paddr_to_pdx() To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Anthony PERARD , Oleksii Kurochko , Shawn Anastasio References: <262b9929-5cbd-4bb1-ac2a-35916273cba5@suse.com> Content-Language: en-GB From: Julien Grall In-Reply-To: <262b9929-5cbd-4bb1-ac2a-35916273cba5@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 30/04/2025 16:56, Jan Beulich wrote: > There's nothing arch-specific about it. > > While there, on x86 visually separate the vmap_to_*() macros from those > covered by the earlier comment. > > Signed-off-by: Jan Beulich Acked-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu May 01 11:15:03 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 11:15:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974081.1362034 (Exim 4.92) (envelope-from ) id 1uARsZ-0006OD-7d; Thu, 01 May 2025 11:14:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974081.1362034; Thu, 01 May 2025 11: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 1uARsZ-0006O6-3G; Thu, 01 May 2025 11:14:59 +0000 Received: by outflank-mailman (input) for mailman id 974081; Thu, 01 May 2025 11:14:57 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uARsX-0006O0-HO for xen-devel@lists.xenproject.org; Thu, 01 May 2025 11:14:57 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1uARsU-000xk5-1V; Thu, 01 May 2025 11:14:54 +0000 Received: from [15.248.2.31] (helo=[10.24.66.15]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uARsU-00G9MA-0t; Thu, 01 May 2025 11:14: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=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=4NV3oT3IbExqMadVEZ7mL9H7hwtfCZag5BBPfIyCjVQ=; b=epm+MGbOaLGllaYaTQfRCkhkys LerE3bl/oTygdTw8N+GjITPYVLHWaFydsEwjYlBCPGv71K8KIHWKSg/IQsLVYy11dtSmDs3rUjVVB ZV1NF24CbVaLMKmMJGXiFyCd4cqUFST3PbkaxSdhC3vTKqtKUuBpJfvhlWl5fc3AJyjw=; Message-ID: Date: Thu, 1 May 2025 12:14:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/4] Physical address hypercall ABI ("HVMv2") Content-Language: en-GB To: Jan Beulich , Teddy Astie Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , xen-devel@lists.xenproject.org References: From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 22/04/2025 08:45, Jan Beulich wrote: > On 18.04.2025 16:18, Teddy Astie wrote: >> In current HVM mode, when a hypercall references a structure in guest memory, >> it is passed to the hypervisor as its "linear address" (e.g virtual address for >> the x86 long mode). >> One of the caveats is that this linear address (GVA) is generally not directly >> usable by the Xen and needs to be translated from GVA to GPA then HPA. This >> implies a complex and potentially expensive lookup of the pagetables inside the >> guest. This can be significant, especially if the P2M cannot use efficiently >> superpages (or with e.g XSA-304). >> >> This proposal introduce a new mode where all addresses used for hypercalls are >> GPADDR instead of GVADDR, therefore, looking up the HPA related to this GPA >> only needs a P2M lookup and not looking through the inside-guest pagetables. >> >> This mode is opt-in and must be enabled explicitely by the toolstack. > > Which I view as a severe downside (leaving aside the PVH Dom0 aspect): This way > a guest needs to be converted all in one go. While doable, it'll be increasingly > risky with the size of the guest kernel code base. +1. It is not only the guest kernel, but also the firmware (UEFI, U-boot). Furthermore, I don't think this can be easily adopted in public cloud where the admin for Xen and the guest will be different. So any indication of the ABI would have to come from the guest itself rather than the configuration. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu May 01 11:34:24 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 11:34:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974093.1362042 (Exim 4.92) (envelope-from ) id 1uASBG-00014z-MZ; Thu, 01 May 2025 11:34:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974093.1362042; Thu, 01 May 2025 11:34:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uASBG-00014s-Jw; Thu, 01 May 2025 11:34:18 +0000 Received: by outflank-mailman (input) for mailman id 974093; Thu, 01 May 2025 11:34:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uASBG-00014m-4M for xen-devel@lists.xenproject.org; Thu, 01 May 2025 11:34:18 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 361fb746-2680-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 13:34:15 +0200 (CEST) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-43cfecdd8b2so4354265e9.2 for ; Thu, 01 May 2025 04:34:15 -0700 (PDT) Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-441b89ee593sm9265045e9.24.2025.05.01.04.34.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 May 2025 04:34: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" X-Inumbo-ID: 361fb746-2680-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1746099255; x=1746704055; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=CEdQ3ByOwkoF4QKCQHEC3B2txafqBdWMtqsoaB/Ux+w=; b=Q2Kia0TboOIShKBYu2hDif2CdoB6iKCNJlVGKsKp/C7LjCoqTe+UshDAISRMz+l3oM JbB0FRIPZJaklki+VzUPstVh87P74guyUkki7YmBFHITNdSjgOwGfxdM/LU80/fKuMfx Vk86dy5jTmbm1p32bZgJEWma7/Fn1TxiNnq1s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746099255; x=1746704055; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CEdQ3ByOwkoF4QKCQHEC3B2txafqBdWMtqsoaB/Ux+w=; b=jSYNVIBvn6zihtZrawRRWRZtEVmg7tJa0aWyGn2i7BYJ6JKJASuLhSqcrkDtqr/NKr 8RMYYhu22GwcIV8TNRDDdYH/MNzz0KdA0tAkL7rxdy+8V+EsGqDOCliqf2Q1HWnGXJHz FWgJbSF5Z5sworrXiI1xUDWGefJx9Ir+Ozh1x6erRH8AeUqXfPOGW8sKY1+hthT/648E zRXa4f/6oxZnI1eKaRtSwjmg3DlWsuijQH8Y1spoXE12KNjzKVKTUezR5sYlkz6pzIvY UCnk8lnsvezHPHugrhtfjMQX8zUTkCNEUW5uBFkyIGBBDLDw6OHkIQPrDKbo+atXu6eu RyKQ== X-Forwarded-Encrypted: i=1; AJvYcCWJCVeuARjhGmOk9XwoeikzU4Hu38zzTaHcuqkMgqB/fZmUkot+2Xcpgo6wnJSLzlbuQxegX5gq6W0=@lists.xenproject.org X-Gm-Message-State: AOJu0YzCPPVlIPRrBy5Giuj7wTUA0kIQg8oRKu0N90ohu/zgbmQXytzc GGle5uagavJKRZbO9hcydiniiscLCOYYx+8BiY/djketLQdSBLTNQvqU2VyqgOA= X-Gm-Gg: ASbGnctaXC7ykgchddkjWwWh8Hlg4ad5KV3JtUNfbKkcTflO2GY1brDnPaUyhjS8UTd NofW4pfHlC/Z7J+UUkr1f1QPII6LstoFBHU6eiVmQuDferkAY/awZwvzFaIj00BoAdSn6cxFzxz xB9b735qxe7nAiaaycWf9VrIhj/StMNcgfLzZcGooA0eF+SxaEhtWvy/G94Ngid4XexrkudhYQN PryZLk2QmOG/wiR5+2tIf2jLtcaCFNSAq0LEHKqQEJz81x5e2aZeO1HQsr1k9tLL0McH9cDi6la wkhFXyg1s0t80YZ9AFQ6f9kake/ZV2HCvYyXzogaVVZt+xl5djlKfNESOZCrtfFqNBEFzMZ/hTm N1ScArA== X-Google-Smtp-Source: AGHT+IE+M5d3ClIg349LNn1yOx6YyRb/FYe/hKGasqqv1fM9MmMgvF3z6N83BNJDtw5tTnvQutC87Q== X-Received: by 2002:a05:600c:1e87:b0:43d:47b7:b32d with SMTP id 5b1f17b1804b1-441b7044ec7mr15670265e9.25.1746099254941; Thu, 01 May 2025 04:34:14 -0700 (PDT) Message-ID: Date: Thu, 1 May 2025 12:34:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] sbat: Add SBAT section to the xen binary To: Gerald Elder-Vass , xen-devel@lists.xenproject.org Cc: Frediano Ziglio , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini References: <20250501104925.228351-1-gerald.elder-vass@cloud.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: <20250501104925.228351-1-gerald.elder-vass@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/05/2025 11:49 am, Gerald Elder-Vass wrote: > The SBAT section provides a way for the binary to declare a generation > id for its upstream source and any vendor changes applied. A compatible > loader can then revoke vulnerable binaries by generation, using the > binary's declared generation id(s) to determine if it is safe to load. > > More information about SBAT is available here: > https://github.com/rhboot/shim/blob/main/SBAT.md > > Vendors should append a custom line onto sbat.csv(.in) with their vendor > specific sbat data. > > Populate the SBAT section in the Xen binary by using the information > in xen/arch/x86/sbat.csv.in > > Signed-off-by: Gerald Elder-Vass > Signed-off-by: Frediano Ziglio > Tested-by: Gerald Elder-Vass Thankyou for starting to post these patches. The commit message needs that SBAT is a revocation scheme for UEFI SecureBoot, and mandatory now if you want to get signed by Microsoft.  This wants to be the first sentence, IMO. That in turn also explains why it's in the EFI binary only, and discarded from the ELF binary. > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile > index d902fb7accd9..6db7475c2c23 100644 > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -74,6 +74,7 @@ obj-$(CONFIG_TBOOT) += tboot.o > obj-y += hpet.o > obj-y += vm_event.o > obj-y += xstate.o > +obj-y += sbat_data.o These should be sorted by file name (although hpet.o is clearly out of order here). Where possible, please use dash rather than underscore in filenames, although in this case I'd shorten it to just sbat.o and bypass that problem. > > ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y) > obj-y += domctl.o > @@ -277,6 +278,12 @@ $(obj)/efi.lds: AFLAGS-y += -DEFI > $(obj)/xen.lds $(obj)/efi.lds: $(src)/xen.lds.S FORCE > $(call if_changed_dep,cpp_lds_S) > > +$(obj)/sbat.csv: $(src)/sbat.csv.in > + sed "s/@@VERSION@@/${XEN_FULLVERSION}/" $< > $@ > + > +$(obj)/sbat_data.o: $(obj)/sbat.csv > + $(OBJCOPY) -I binary -O elf64-x86-64 --rename-section .data=.sbat,readonly,data,contents $< $@ > + > clean-files := \ > include/asm/asm-macros.* \ > $(objtree)/.xen-syms.[0-9]* \ > diff --git a/xen/arch/x86/sbat.csv.in b/xen/arch/x86/sbat.csv.in > new file mode 100644 > index 000000000000..7cdc33dbd998 > --- /dev/null > +++ b/xen/arch/x86/sbat.csv.in > @@ -0,0 +1,2 @@ > +sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md > +xen,1,Linux Foundation,xen,@@VERSION@@,https://xenproject.org/ I know this is what the SBAT spec says to do, but it's unworkable. Upstream Xen cannot state or maintain a global generation ID on behalf of it's downstreams.  This is true in general, not just for Xen. For us (XenServer), this needs to be a line starting xen.xenserver, because we (and only we) know how our Xen is built and configured.  Every other downstream will need to do the same. So, either we want just the SBAT line an nothing else, or we want some kind of "to be filled in by the OSV" info, to make it clear that people need to alter it. When UEFI SecureBoot becomes security supported, the security team probably wants to note in XSAs whether the issue constitutes a breach of UEFI-SB, and remind downstreams to bump their generation IDs. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu May 01 12:23:50 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 12:23:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974109.1362053 (Exim 4.92) (envelope-from ) id 1uASx2-0008Gg-AI; Thu, 01 May 2025 12:23:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974109.1362053; Thu, 01 May 2025 12: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 1uASx2-0008GZ-6L; Thu, 01 May 2025 12:23:40 +0000 Received: by outflank-mailman (input) for mailman id 974109; Thu, 01 May 2025 12:23:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uASx0-0008GT-Mq for xen-devel@lists.xenproject.org; Thu, 01 May 2025 12:23:38 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1bd24329-2687-11f0-9eb4-5ba50f476ded; Thu, 01 May 2025 14:23:38 +0200 (CEST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-ac25520a289so145579866b.3 for ; Thu, 01 May 2025 05:23:38 -0700 (PDT) Received: from eddie5.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad0da51681asm33401366b.105.2025.05.01.05.23.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 May 2025 05:23:36 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1bd24329-2687-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1746102217; x=1746707017; 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; bh=a/PqX/nwwI08euGI8uJVy+/V+w3ULiNbLKDIxnxdS24=; b=WDILSqImnr4j7gmJTZ89wQGxekU/L5Z3JasKdKX8lrp3QdZOu18QYiagrYmohndB9v ztxGOTZgsBkacEEaSi0TsT1X4lWoD/mWU7WD6plt2DxtBMjqdj/+o7nlZ0GaszKr8Ngj Y/fPxTBjGNHROfsueTxwGnYvjBlt7QnPqGwQ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746102217; x=1746707017; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=a/PqX/nwwI08euGI8uJVy+/V+w3ULiNbLKDIxnxdS24=; b=ewQvuMpZ+NfrEflB8cy4CvwpExpw2hMLWNcdX2XQqMP+ZHWzkqqgeg19x6cQ3/Fhd8 ybb0yacK5KOqK684n1Ad981W1sdG4Qmaleap9+L5Xqf3PCd3wbk5ca5RoKhZuuqtN3Ap cuYK6xznl/uFZYV4MOHa7YpbDMPXr4z9t+jficiOa7tnmQ7jZi9OzDDzJt1ACHfPHHWG 77gLXNmjePn/nrHETogqINSZBnMifYQ2Da0kO5TNvXxmzle3nJHTmW2hBKFJoCqH7Y5B vMZmffoz4JRKOxkaFAUZCK/EjJm3HlqB1lThjjnxr8YPS1FWK/4G17lb29kHYIe0Lbow 6DXA== X-Gm-Message-State: AOJu0YzKFj8KR2qOd3rGBGTxCaRiNZ8sr3lSChj+6oB6Gix/9uF6D+sH AO+d0iy7x5+CIKD5u7djFs3BSBCzt3itDJbGlpktsRD/ATY9PYQ5uEf47OWn1SkjJo4+6A0bpwO YwzI= X-Gm-Gg: ASbGncu8zXYKSykaft5ZPLQn3yPj6JGIqe3CKndfsW25O2guQ+cLsZVW6WzKaBt7Fq9 W8yRgBlDj3MxhqH4aMmObHbhjgew5bIj7fRenAwK7TAmgf5Mupo+iXX5zHjgbh/vm/rvsRoDRo6 qYC0xyd0eR50+RkP7+oUtnaGz6Ew1BMFGItmkDZz/9xuMLHIsGKwHJYGZami8Bpz8KjxBFFl9At eg30dJ+K7OZbeSg/8e+1XB/wAxVZBaYDZG6kvQ3Orfojs5OBxrNj1DGvpOzMDgyKa0MOxGg0/cd PNk3KPoSO1EeFP36+6r5JBnOt+1saBDIH/o6zQbIRlJLTeNWEGi+YB+DhfcwP45p X-Google-Smtp-Source: AGHT+IGt1lh2PjmnZHhjKw7j3jKh8mY0cZW9WiCl6UNuO+iXLXk/ZRrjx0QUdHGwzSkNHQXupvsHgA== X-Received: by 2002:a17:907:2da4:b0:ac7:1350:e878 with SMTP id a640c23a62f3a-acefbfe3165mr226433566b.46.1746102217040; Thu, 01 May 2025 05:23:37 -0700 (PDT) From: Gerald Elder-Vass To: xen-devel@lists.xenproject.org Cc: Gerald Elder-Vass , Frediano Ziglio , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julien Grall , Stefano Stabellini Subject: [XEN PATCH v2] sbat: Add SBAT section to the Xen EFI binary Date: Thu, 1 May 2025 12:23:22 +0000 Message-ID: <20250501122322.230599-1-gerald.elder-vass@cloud.com> X-Mailer: git-send-email 2.47.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit SBAT is a revocation scheme for UEFI SecureBoot, and is mandated by Microsoft for signing. The SBAT section provides a way for the binary to declare a generation id for its upstream source and any vendor changes applied. A compatible loader can then revoke vulnerable binaries by generation, using the binary's declared generation id(s) to determine if it is safe to load. More information about SBAT is available here: https://github.com/rhboot/shim/blob/main/SBAT.md Vendors should append a custom line onto sbat.csv(.in) with their vendor specific sbat data. Populate the SBAT section in the Xen binary by using the information in xen/arch/x86/sbat.csv Signed-off-by: Gerald Elder-Vass Signed-off-by: Frediano Ziglio Tested-by: Gerald Elder-Vass --- Changed since v1: * Updated commit message to explain why SBAT is needed * Renamed sbat_data.o rule to sbat.o * Moved sbat.o rule into alphabetical order * Removed xen specific entry from sbat.csv (and rule for auto filling version) - The alternative of adding a "customise me" line would result in more overhead for anyone else building Xen, regardless of UEFI SecureBoot usage diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index d902fb7accd9..8fc5c69111d5 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -58,6 +58,7 @@ obj-y += percpu.o obj-y += physdev.o obj-$(CONFIG_COMPAT) += x86_64/physdev.o obj-y += psr.o +obj-y += sbat.o obj-y += setup.o obj-y += shutdown.o obj-y += smp.o @@ -277,6 +278,9 @@ $(obj)/efi.lds: AFLAGS-y += -DEFI $(obj)/xen.lds $(obj)/efi.lds: $(src)/xen.lds.S FORCE $(call if_changed_dep,cpp_lds_S) +$(obj)/sbat.o: $(src)/sbat.csv + $(OBJCOPY) -I binary -O elf64-x86-64 --rename-section .data=.sbat,readonly,data,contents $< $@ + clean-files := \ include/asm/asm-macros.* \ $(objtree)/.xen-syms.[0-9]* \ diff --git a/xen/arch/x86/sbat.csv b/xen/arch/x86/sbat.csv new file mode 100644 index 000000000000..1f262b5f038b --- /dev/null +++ b/xen/arch/x86/sbat.csv @@ -0,0 +1 @@ +sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S index 9a1dfe1b340a..e6405941e1b7 100644 --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -343,6 +343,8 @@ SECTIONS *(.reloc) __base_relocs_end = .; } + + .sbat (NOLOAD) : { *(.sbat) } #elif defined(XEN_BUILD_EFI) /* * Due to the way EFI support is currently implemented, these two symbols diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h index a17810bb286f..756f97d48183 100644 --- a/xen/include/xen/xen.lds.h +++ b/xen/include/xen/xen.lds.h @@ -92,7 +92,8 @@ *(.comment.*) \ *(.note.*) #else -#define DISCARD_EFI_SECTIONS +#define DISCARD_EFI_SECTIONS \ + *(.sbat) #endif /* Sections to be discarded. */ From xen-devel-bounces@lists.xenproject.org Thu May 01 12:36:58 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 12:36:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974121.1362064 (Exim 4.92) (envelope-from ) id 1uAT9p-0001dW-DZ; Thu, 01 May 2025 12:36:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974121.1362064; Thu, 01 May 2025 12:36: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 1uAT9p-0001dP-8B; Thu, 01 May 2025 12:36:53 +0000 Received: by outflank-mailman (input) for mailman id 974121; Thu, 01 May 2025 12:36:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAT9n-0001dJ-Hf for xen-devel@lists.xenproject.org; Thu, 01 May 2025 12:36:51 +0000 Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [2607:f8b0:4864:20::22d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f3faf523-2688-11f0-9eb4-5ba50f476ded; Thu, 01 May 2025 14:36:50 +0200 (CEST) Received: by mail-oi1-x22d.google.com with SMTP id 5614622812f47-4032f863d20so271870b6e.0 for ; Thu, 01 May 2025 05:36: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" X-Inumbo-ID: f3faf523-2688-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1746103009; x=1746707809; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Az6DuxwS+cbj2aShXS/BiWxsPfOevyrOe04Mv86jzsk=; b=QUevDI10i8dzeoAJJLPE45nWya2y4O6WNIdD47L29LWaBlyqDG4GiZoUo2R1Bpm6Li bcOcQfMIlvuYZsJEMsc5o+s0G46wuM7GcfwWtfjlBUJXApNi1E89I3mTHjExONpRvGa3 moRsf28CYQiP5MX2RI7XFL/aXlX5VvLYW84s4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746103009; x=1746707809; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Az6DuxwS+cbj2aShXS/BiWxsPfOevyrOe04Mv86jzsk=; b=Mxm5EB+PhkAD9EP8NromphBA7ylUd4DCHlumH/8ICzW94fmXTBVBpHOesR7QARdS8v 26XeJ+6XEPHSbAUWj2OA4NtWVAUTa/dYYmS6pY0iS9ddDPuMkc0XWwGfV/IyQJr5CXN/ S0MLxKkNar3vrbl018qKmUHbszp+nqfrmnKok3IfZMiz4FKVLTIuVlStL646B6YV14DQ YT7g+hzAx+XIGFDfS0zUwIHmMrinIhwMLn6IU75ZfatTQC1qgBA6zlMlkJHKAxh+oWs6 RvV9rZQvXAQL8nRk12GjT+lUvh/pWwDbo2LN2qTsVlCAvfSWHldjMcxJQiEHzacvKQRu kZTA== X-Forwarded-Encrypted: i=1; AJvYcCUPiIpxAjCoIxXBf+NH5VrB3hSNLTy62NsTHJm9N+KG9QUPzuYmX3Apv82bWC1LtPhcT6EVAWtGtHM=@lists.xenproject.org X-Gm-Message-State: AOJu0YzHifjm6D69vP/i1outhsA4cm9yXzDZqoDQRnM99dbFMqlpvCRg xt58DyrGMeshhQdicVjcwEdnF9zI5LHmUJG5uLdM/fIsdybSm7O4mGyb2cYGw26//RNb5h0aDDr 28TwJ7aLhlgA725IvPiMgaB/dLgsXUTf2ZrNufg== X-Gm-Gg: ASbGncvCebduy+e9N+gvoUaUypDYAypOldxWyu5atCjhmT+apw64uKs1g6GdVxDyk9Y VI3H6dT7waSQiNVaZGrhEgGd0vv1An9uYAfGnj5e299H/p4AFsYiexawhkrqbOIXWiaha0yZGG+ bPupE+8wAAsIBverv1EQgiWg== X-Google-Smtp-Source: AGHT+IFiuTYGMm+Zm0WGD2RaB3xbHZ5k2yiaN1eU+R5Y2ogO31PPRkAaa8iM8PIjZc5F1Jc79YH6ulblB4dOrNUM0oA= X-Received: by 2002:a05:6808:164a:b0:400:a250:9819 with SMTP id 5614622812f47-403343c9da9mr1819994b6e.12.1746103009353; Thu, 01 May 2025 05:36:49 -0700 (PDT) MIME-Version: 1.0 References: <20250501104925.228351-1-gerald.elder-vass@cloud.com> In-Reply-To: From: Frediano Ziglio Date: Thu, 1 May 2025 13:36:38 +0100 X-Gm-Features: ATxdqUHto0FEUA41Nk5XwDfqqyKXwcsd_cmH4msV8t2a6N8Mi6ISMIhKgZ6BMYQ Message-ID: Subject: Re: [XEN PATCH] sbat: Add SBAT section to the xen binary To: Andrew Cooper Cc: Gerald Elder-Vass , xen-devel@lists.xenproject.org, Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 1, 2025 at 12:34=E2=80=AFPM Andrew Cooper wrote: > > On 01/05/2025 11:49 am, Gerald Elder-Vass wrote: > > The SBAT section provides a way for the binary to declare a generation > > id for its upstream source and any vendor changes applied. A compatible > > loader can then revoke vulnerable binaries by generation, using the > > binary's declared generation id(s) to determine if it is safe to load. > > > > More information about SBAT is available here: > > https://github.com/rhboot/shim/blob/main/SBAT.md > > > > Vendors should append a custom line onto sbat.csv(.in) with their vendo= r > > specific sbat data. > > > > Populate the SBAT section in the Xen binary by using the information > > in xen/arch/x86/sbat.csv.in > > > > Signed-off-by: Gerald Elder-Vass > > Signed-off-by: Frediano Ziglio > > Tested-by: Gerald Elder-Vass > > Thankyou for starting to post these patches. > > The commit message needs that SBAT is a revocation scheme for UEFI > SecureBoot, and mandatory now if you want to get signed by Microsoft. > This wants to be the first sentence, IMO. > > That in turn also explains why it's in the EFI binary only, and > discarded from the ELF binary. > > > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile > > index d902fb7accd9..6db7475c2c23 100644 > > --- a/xen/arch/x86/Makefile > > +++ b/xen/arch/x86/Makefile > > @@ -74,6 +74,7 @@ obj-$(CONFIG_TBOOT) +=3D tboot.o > > obj-y +=3D hpet.o > > obj-y +=3D vm_event.o > > obj-y +=3D xstate.o > > +obj-y +=3D sbat_data.o > > These should be sorted by file name (although hpet.o is clearly out of > order here). > > Where possible, please use dash rather than underscore in filenames, > although in this case I'd shorten it to just sbat.o and bypass that probl= em. > > > > > ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y) > > obj-y +=3D domctl.o > > @@ -277,6 +278,12 @@ $(obj)/efi.lds: AFLAGS-y +=3D -DEFI > > $(obj)/xen.lds $(obj)/efi.lds: $(src)/xen.lds.S FORCE > > $(call if_changed_dep,cpp_lds_S) > > > > +$(obj)/sbat.csv: $(src)/sbat.csv.in > > + sed "s/@@VERSION@@/${XEN_FULLVERSION}/" $< > $@ > > + > > +$(obj)/sbat_data.o: $(obj)/sbat.csv > > + $(OBJCOPY) -I binary -O elf64-x86-64 --rename-section .data=3D.sb= at,readonly,data,contents $< $@ > > + > > clean-files :=3D \ > > include/asm/asm-macros.* \ > > $(objtree)/.xen-syms.[0-9]* \ > > diff --git a/xen/arch/x86/sbat.csv.in b/xen/arch/x86/sbat.csv.in > > new file mode 100644 > > index 000000000000..7cdc33dbd998 > > --- /dev/null > > +++ b/xen/arch/x86/sbat.csv.in > > @@ -0,0 +1,2 @@ > > +sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SB= AT.md > > +xen,1,Linux Foundation,xen,@@VERSION@@,https://xenproject.org/ > > I know this is what the SBAT spec says to do, but it's unworkable. > > Upstream Xen cannot state or maintain a global generation ID on behalf > of it's downstreams. This is true in general, not just for Xen. > > For us (XenServer), this needs to be a line starting xen.xenserver, > because we (and only we) know how our Xen is built and configured. > Every other downstream will need to do the same. > > So, either we want just the SBAT line an nothing else, or we want some > kind of "to be filled in by the OSV" info, to make it clear that people > need to alter it. > At this point why not make the inclusion of this section conditional? If the binary is not going to be signed this section won't be used. For instance I would define a dummy variable at the beginning of xen/Makefile like XEN_SBAT_NAME. If it's not provided (people can use external xen-version file) do not include that section. > When UEFI SecureBoot becomes security supported, the security team > probably wants to note in XSAs whether the issue constitutes a breach of > UEFI-SB, and remind downstreams to bump their generation IDs. > > ~Andrew Frediano From xen-devel-bounces@lists.xenproject.org Thu May 01 13:07:49 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 13:07:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974133.1362072 (Exim 4.92) (envelope-from ) id 1uATde-0006AL-HF; Thu, 01 May 2025 13:07:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974133.1362072; Thu, 01 May 2025 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 1uATde-0006AE-EY; Thu, 01 May 2025 13:07:42 +0000 Received: by outflank-mailman (input) for mailman id 974133; Thu, 01 May 2025 13:07:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uATdd-0006A8-0H for xen-devel@lists.xenproject.org; Thu, 01 May 2025 13:07:41 +0000 Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [2607:f8b0:4864:20::22a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3cb2c26e-268d-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 15:07:30 +0200 (CEST) Received: by mail-oi1-x22a.google.com with SMTP id 5614622812f47-4032f863d20so280570b6e.0 for ; Thu, 01 May 2025 06:07: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" X-Inumbo-ID: 3cb2c26e-268d-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1746104849; x=1746709649; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hMVaJbvW1c/t9ObxweHk7a2muzcHmtppOv1iFZiigw8=; b=ILHigeOPti3CJSSQxcAZoQIb5o0jdwUWUT51hAZtAKDZhDPlTsqbK2+MUSmzx9/hdb +o6DRBRwEzT/25VPoFOJhlL9tuY00ftC8Yu3ZAw2PzP6TYIyJGdP/u1JFxlygB/q3Zxj YYrmqSEc29MT8VoC+PV7aEpm/5k4ngLNEVA6s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746104849; x=1746709649; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hMVaJbvW1c/t9ObxweHk7a2muzcHmtppOv1iFZiigw8=; b=WReenF62vgxMXNxhgoNPn7ukBItP+IhD28iI+Blzop8Wtcg92vsvWEQYe61udzMMux GIqZuxU0MbcZZpj4LtIlmg3AS7lPu+AyDME3b478GokfXy17FvIW15fWuMZFGVH8Czkz UjkRzqW7pS20/T4zjwxlGQZtkpuYZjuZF8DSXGmlUu+iMMh+TCZ5SqKIrcKFh16h9HjX z+wH/jjYnweR9ldrnWiR/+0FzsopWclH0gfjU8wGShFvGAe461hNFIhM+whsXglNBtZR 2vmqL+KxIHY5tXrdempn5fwCol4JpenQzfGknryJA6pCIwLR39iq/en9H5sh3I9yafYC TC0A== X-Gm-Message-State: AOJu0Yx2b/HmY3ptJLJmhKBct05AHKWifLM2tmCo0BAFd2aAVf0vEWdZ nCXv0mJ34rWIYdj9k+a5YwNZLhAvYHHEXWJtL1W9mfGvNkv8xvgvBQrdVlnKa8MjyS2Q6iEmMma KfuxE5j3V/Yq/fAbdGRnT9m+e/OVcV6urglRp4A== X-Gm-Gg: ASbGncvKJ8tJuLh/arV9cWIPvqLZrDqU2/SDU703Rvn2VeJgQctT5PBbZsmStVhDgkX jLcclSHAw3FdoBdshla0+OOBu+F49Z2N24uujHmkKP/CpdAFdYxr+c2IyhaXhnRPiZfXU9K4dFL GawVk3QEbZr2DTJHyVbWW8EfFPgCJF4WOl X-Google-Smtp-Source: AGHT+IE8FIUPP7YYZDSn3NECWR/FaVZOJhjWlTuvuBrS8+UpYxMO8Z+akDahkdJ7SJxG/k/j5deWCPpj/V4Jd+oqIGM= X-Received: by 2002:a05:6808:2f14:b0:403:3814:7547 with SMTP id 5614622812f47-40338147576mr921715b6e.11.1746104849156; Thu, 01 May 2025 06:07:29 -0700 (PDT) MIME-Version: 1.0 References: <20250501122322.230599-1-gerald.elder-vass@cloud.com> In-Reply-To: <20250501122322.230599-1-gerald.elder-vass@cloud.com> From: Frediano Ziglio Date: Thu, 1 May 2025 14:07:18 +0100 X-Gm-Features: ATxdqUFcUwyQP1hTK9OK9GVUJTpU_oNAF_3MPp3GpZjkb03yeOjKh8kFoDdJDZg Message-ID: Subject: Re: [XEN PATCH v2] sbat: Add SBAT section to the Xen EFI binary To: Gerald Elder-Vass Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Stefano Stabellini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 1, 2025 at 1:23=E2=80=AFPM Gerald Elder-Vass wrote: > > SBAT is a revocation scheme for UEFI SecureBoot, and is mandated by Micro= soft > for signing. > > The SBAT section provides a way for the binary to declare a generation > id for its upstream source and any vendor changes applied. A compatible > loader can then revoke vulnerable binaries by generation, using the > binary's declared generation id(s) to determine if it is safe to load. > > More information about SBAT is available here: > https://github.com/rhboot/shim/blob/main/SBAT.md > > Vendors should append a custom line onto sbat.csv(.in) with their vendor > specific sbat data. > > Populate the SBAT section in the Xen binary by using the information > in xen/arch/x86/sbat.csv > > Signed-off-by: Gerald Elder-Vass > Signed-off-by: Frediano Ziglio > Tested-by: Gerald Elder-Vass > --- > Changed since v1: > * Updated commit message to explain why SBAT is needed > * Renamed sbat_data.o rule to sbat.o > * Moved sbat.o rule into alphabetical order > * Removed xen specific entry from sbat.csv (and rule for auto filling ve= rsion) > - The alternative of adding a "customise me" line would result in more > overhead for anyone else building Xen, regardless of UEFI SecureBoot= usage > > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile > index d902fb7accd9..8fc5c69111d5 100644 > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -58,6 +58,7 @@ obj-y +=3D percpu.o > obj-y +=3D physdev.o > obj-$(CONFIG_COMPAT) +=3D x86_64/physdev.o > obj-y +=3D psr.o > +obj-y +=3D sbat.o > obj-y +=3D setup.o > obj-y +=3D shutdown.o > obj-y +=3D smp.o > @@ -277,6 +278,9 @@ $(obj)/efi.lds: AFLAGS-y +=3D -DEFI > $(obj)/xen.lds $(obj)/efi.lds: $(src)/xen.lds.S FORCE > $(call if_changed_dep,cpp_lds_S) > > +$(obj)/sbat.o: $(src)/sbat.csv > + $(OBJCOPY) -I binary -O elf64-x86-64 --rename-section .data=3D.sb= at,readonly,data,contents $< $@ > + > clean-files :=3D \ > include/asm/asm-macros.* \ > $(objtree)/.xen-syms.[0-9]* \ > diff --git a/xen/arch/x86/sbat.csv b/xen/arch/x86/sbat.csv > new file mode 100644 > index 000000000000..1f262b5f038b > --- /dev/null > +++ b/xen/arch/x86/sbat.csv > @@ -0,0 +1 @@ > +sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT= .md > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S > index 9a1dfe1b340a..e6405941e1b7 100644 > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -343,6 +343,8 @@ SECTIONS > *(.reloc) > __base_relocs_end =3D .; > } > + > + .sbat (NOLOAD) : { *(.sbat) } > #elif defined(XEN_BUILD_EFI) > /* > * Due to the way EFI support is currently implemented, these two symb= ols > diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h > index a17810bb286f..756f97d48183 100644 > --- a/xen/include/xen/xen.lds.h > +++ b/xen/include/xen/xen.lds.h > @@ -92,7 +92,8 @@ > *(.comment.*) \ > *(.note.*) > #else > -#define DISCARD_EFI_SECTIONS > +#define DISCARD_EFI_SECTIONS \ > + *(.sbat) > #endif > > /* Sections to be discarded. */ Reviewed-by: Frediano Ziglio Frediano From xen-devel-bounces@lists.xenproject.org Thu May 01 13:44:41 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 13:44:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974146.1362082 (Exim 4.92) (envelope-from ) id 1uAUDD-0003MY-Sf; Thu, 01 May 2025 13:44:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974146.1362082; Thu, 01 May 2025 13:44:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAUDD-0003MR-Q2; Thu, 01 May 2025 13:44:27 +0000 Received: by outflank-mailman (input) for mailman id 974146; Thu, 01 May 2025 13:44:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAUDB-0003ML-Nm for xen-devel@lists.xenproject.org; Thu, 01 May 2025 13:44:25 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2060b.outbound.protection.outlook.com [2a01:111:f403:2412::60b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 639f5697-2692-11f0-9eb4-5ba50f476ded; Thu, 01 May 2025 15:44:24 +0200 (CEST) Received: from MW4PR03CA0217.namprd03.prod.outlook.com (2603:10b6:303:b9::12) by MW3PR12MB4411.namprd12.prod.outlook.com (2603:10b6:303:5e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.19; Thu, 1 May 2025 13:44:19 +0000 Received: from SJ1PEPF000023D9.namprd21.prod.outlook.com (2603:10b6:303:b9:cafe::a4) by MW4PR03CA0217.outlook.office365.com (2603:10b6:303:b9::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8655.36 via Frontend Transport; Thu, 1 May 2025 13:44:18 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SJ1PEPF000023D9.mail.protection.outlook.com (10.167.244.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8722.2 via Frontend Transport; Thu, 1 May 2025 13:44:18 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 1 May 2025 08:44:17 -0500 Received: from [172.25.248.240] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Thu, 1 May 2025 08:44:17 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 639f5697-2692-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h0AAttwvV6nPvEk44QKpb5uaLp/jRehAcHzVtsqEEzp3aZjDaH1Ctpz8tEtoMIpuR0ifbM/Fh4nyLxVrNCEW4a7YqcknEqRhPHwKqZ/Ns2rMfBZzFGESSPH27tzx8cctwkYZ3Zja3Q5LWugpDSUl2vax6mfz0Jb9i1uI8KXw4uuauPvtNbi7R0K+Dz9FhiJInznmWb5ySFA4DmlD3l397/yL2OlPCjuIpioqnW9zHGQzsNZr0KXnGbO+trDKtJR+/O2V4m3Veeq5XbGl4ob7SJFqLu8WWDP406EF/yT46qQ/Aj1Yi+/cWjQ0KNPxCZiDc/24VairvcSZTxKgYgOp1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BvxN1QaZ8FeuqiatsTUso/7s43/8NUTjJy/bZlCuti0=; b=mYfPBoSdAeSHePQ3GNKemK8oy0R0fPZY2tKnFr7RAIoT8QpW7jDSU8tfe35KLs/0xM+WsoGNeo3wN4YWnFjf7TKi8YCHXwXE9FHmEgEhPclNEJ08gS8Zlre3tcaJosRJwiipLOYj6OQpYiReCns6GEj/waffZLcY0gZTxUC94SrM/TEwj+fD0KIZxGmzwNKqv51KE9C017FDCrs0W/30ykob6qsh5TWeBStWt65UL/QdHnmy/x2GOmrfuQuyBeWjPIEAPCcJ3W2r2IE8pQVAQ4UXX7MhPAuZ8K5SaLseE7EfZtKqRWYo4XxvCTjBp1W6ZPROZi5PfgkRFST91LCHaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BvxN1QaZ8FeuqiatsTUso/7s43/8NUTjJy/bZlCuti0=; b=oMMA4pWhez6H6oFoH/i6k+kOP31O5qg2VluIHID/v8fHPLEgcQI1uH5rgyOciyDzJYoNu41c0eZwQ2hbSYlT4DLKynKz6AOD2uSbcGQwMq20DDhA5nzuY/cMF+Q5j+J0VXvN1rHu5RFaoRD7/sKJZSTIXOhTLFT6bkCY5ANzAMI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Message-ID: <3e7b4b20-0127-4db2-806d-f142547f275a@amd.com> Date: Thu, 1 May 2025 09:44:19 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange To: Stefano Stabellini , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= CC: Jan Beulich , "Ragiadakou, Xenia" , Andrew Cooper , , References: <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com> <06b66971-d8db-456f-8e83-a20ff7df8f5e@suse.com> <59bfc389-66c8-4d0f-92e3-c0079a807374@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000023D9:EE_|MW3PR12MB4411:EE_ X-MS-Office365-Filtering-Correlation-Id: 5cb52cd3-f11c-40bb-5d60-08dd88b64587 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UXVOSDRLWGI2OXZhM2VzemFoZE9JTkpHbm0xaVNjTTVuQldZcWZ4MG5xQ3pS?= =?utf-8?B?cjZ3MTVjMlltY2JlMElwQTRGbGhvTTl4R20xcXhHNVFZbHhxd2s4SXVQbE0v?= =?utf-8?B?VXRZeUp6bjBWVlk4YXFBRFBFMzdNU0FCSGNaK3FZQ3ZsaEhNdU5LTDEzenM5?= =?utf-8?B?WVU3UXdHTlpPbUxPY3hQVEF3dS92ZXF4Y2ZpOE9IbWtpUkZ0d0JJcjBnWXEx?= =?utf-8?B?L042Z1BYQ3VVSCtkelNkV1VscFg5WlpncGl0akwzWGlaa2VHSmlmSFJvaHJD?= =?utf-8?B?blIxNm1XcDlZNS9ZVzhSYWM1NEYvUHJzN1ZqSnFHZWtVNUxDU0hVVDNPVTAr?= =?utf-8?B?MzZjYkZSS2RpeFVURG9yYWgySnIxakcwMC9rTFVhdGx3aDNoQWVmeHJWMW81?= =?utf-8?B?QUU3MUd1Z2hoM1dHS1lqUlYra0ZMd2c2a3ZBenJEN1gwTjlTb0hlR00ya2dh?= =?utf-8?B?NVQ2OG4xOUF1TVBOMUZoT0Jtemdld3hhR1VUU0I1K3pTMjFMVVpIQzV4UzUw?= =?utf-8?B?VU1zVzF3Zzl1TUQxQkRlUmxqS2xGblFSNWc4WGR6NEpGSnIwNXU2Q1FnL25Z?= =?utf-8?B?aDYxbFNON2F0dFZCRFNFQXEyS2k2NisxR2xIQWM0OTVtY2NjbjBFUHBYK1FC?= =?utf-8?B?NFlVU3U1ejFTYmFZMFYzZXQyYVkrc1lST1VweW5ENVlLYjFZMHhtK2F6VmlF?= =?utf-8?B?cXJIc3JDbm0zQ25FZ2dyY0huZDhwWStkY3FaNDZ0V1o2SXFuNXV3VXhhU3hu?= =?utf-8?B?Vkc1SEQreWk2SE5HUmIvTzVHRjRrWVhXRnhhRmk1WFpUYXpUZGJQT1orQkdu?= =?utf-8?B?V1ZLRmxoWGg3Tk05ekJOZ250cEZrOG41bnVOUGcvaEFjdEJ6NWdRZTVycG1t?= =?utf-8?B?NGZlM3poeDNVczBOZkNtZ1hzaStMOURwU3J4M1REWjExNTZOVVEyN2wzMXJJ?= =?utf-8?B?b1dzMlNON0dPR0JQZlluZXhOWkxFbVZyVFFESVhUaE9wcUg2UXpvUmcrNUhE?= =?utf-8?B?QzFPZk84Wk1QN3JBM3UvQ1pDeXk1N2R3ZzFlK0ZGZ3pDT2RVdWJ4Y2hDTktB?= =?utf-8?B?emtSSTUxZi9GNzdRVnNzaTRpcnAwM2JlL0d4L1lGMlFVTDNoN2pGMWZUenRC?= =?utf-8?B?dk1ZTlpLY1MyeVpDT1gwZ2RLSlIxVXdIcHJaQTRQdjJWYzMvQWljcGxyZEJp?= =?utf-8?B?SWhFQzNBcXpPalJ2aDVWa1ptZjkxUlh0OVVxdVBUVzlrWGN1YU1CSDNyVWtl?= =?utf-8?B?N2VFUjQ2aGg3cWRXN3h4enYzV25rZDZaUFNoRktJZEJKK1FrWnJiQkR1WWNU?= =?utf-8?B?MjJTM29UYlBlWTU0S2NTaGZhSG5oa0ZhUlNlWUpSR2tJWmpNV0Nvc1JjTmZU?= =?utf-8?B?d2NCU2tIZklMaVl5bUNiY0dpRW9sVmlWbCsyVHJ1SHVDajlRWDE1V3EzWFZB?= =?utf-8?B?T3NsT0VUZnBXSXowejNCNk02OG8xSnBEU01UM0VvN1J0ZTl5REJIVkdsY3Iy?= =?utf-8?B?RmpVaEVTWFVWUWZONHkrRW41OFBaWHhSS281R0NwNmNESHhsdFZ0aE1KUnIy?= =?utf-8?B?ZndRcHJhTWdiQXkrZ010K3RSUjRNaVZ5R3YwOWlnb0gzeFo0SlUzTDRLTko1?= =?utf-8?B?YjJEWW1tZ3UwazFuNzhlYmtNM1JIbWVDYW1KNWJuN094OERLR1oyMVlackFS?= =?utf-8?B?MzhkN1VRemJIVFNoNldQa1F1clVicWdxbktQYWszUEhvdktNSStpdzhTenUr?= =?utf-8?B?Z0pYWEdMaW5MMWE4cTMxd2cyenk1cFFWNHdrWXg0ZG1TeUJMVlBtMGRwQk5S?= =?utf-8?B?c2RKWGJscHZQRFFZa0RxTThwRHNhSGE1dzN1c2VES0Q3L3E4Q1REZ1ZzYWhC?= =?utf-8?B?bFhHeGRRYTdBZlpVZE5YVWJvb29kb0hHVkd1cjd3Vjd3bWJIaG1LK1hINXlu?= =?utf-8?B?M3ZSVElveERubUJBNGIwNHBSZGxYVk5jZWFNSUlpRmhkbEtIRDhzYU1mSjRS?= =?utf-8?B?WnJqNWUrMkNxWmZFZDBBOFhTZzdpZ3dRdUYzUStBRTNLc3hITm8wN1ZYVUhs?= =?utf-8?Q?O+F2YO?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2025 13:44:18.7084 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5cb52cd3-f11c-40bb-5d60-08dd88b64587 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000023D9.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4411 On 2025-04-30 20:19, Stefano Stabellini wrote: > On Wed, 30 Apr 2025, Roger Pau Monné wrote: >> On Wed, Apr 30, 2025 at 08:27:55AM +0200, Jan Beulich wrote: >>> On 29.04.2025 23:52, Stefano Stabellini wrote: >>>> On Tue, 29 Apr 2025, Jan Beulich wrote: >>>>> On 28.04.2025 22:00, Stefano Stabellini wrote: >>>>>> On Mon, 28 Apr 2025, Jan Beulich wrote: >>>>>>> On 25.04.2025 22:19, Stefano Stabellini wrote: >>>>>>>> --- a/xen/common/memory.c >>>>>>>> +++ b/xen/common/memory.c >>>>>>>> @@ -794,7 +794,7 @@ static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg) >>>>>>>> rc = guest_physmap_add_page(d, _gfn(gpfn), mfn, >>>>>>>> exch.out.extent_order) ?: rc; >>>>>>>> >>>>>>>> - if ( !paging_mode_translate(d) && >>>>>>>> + if ( (!paging_mode_translate(d) || is_hardware_domain(d)) && >>>>>>>> __copy_mfn_to_guest_offset(exch.out.extent_start, >>>>>>>> (i << out_chunk_order) + j, >>>>>>>> mfn) ) >>>>>>> >>>>>>> Wait, no: A PVH domain (Dom0 or not) can't very well make use of MFNs, can >>>>>>> it? >>>>>> >>>>>> One way or another Dom0 PVH needs to know the MFN to pass it to the >>>>>> co-processor. >>>>> >>>>> I see. That's pretty odd, though. I'm then further concerned of the order of >>>>> the chunks. At present we're rather lax, in permitting PVH and PV Dom0 the >>>>> same upper bound. With both CPU and I/O side translation there is, in >>>>> principle, no reason to permit any kind of contiguity. Of course there's a >>>>> performance aspect, but that hardly matters in the specific case here. Yet at >>>>> the same time, once we expose MFNs, contiguity will start mattering as soon >>>>> as any piece of memory needs to be larger than PAGE_SIZE. Which means it will >>>>> make tightening of the presently lax handling prone to regressions in this >>>>> new behavior you're introducing. What chunk size does the PSP driver require? >>>> >>>> I don't know. The memory returned by XENMEM_exchange is contiguous, >>>> right? Are you worried that Xen cannot allocate the requested amount of >>>> memory contiguously? In the case I looked at, it is 8 pages. The driver defines a ring of 32 * 1k entries. I'm not sure if there are other paths or device versions where it might differ. >>> That would be Dom0's problem then. But really for a translated guest the >>> exchanged chunks being contiguous shouldn't matter, correctness-wise. That is, >>> within Xen, rather than failing a request, we could choose to retry using >>> discontiguous chunks (contiguous only in GFN space). Such an (afaict) >>> otherwise correct change would break your use case, as it would invalidate the >>> MFN information passed back. (This fallback approach would similarly apply to >>> other related mem-ops. It's just that during domain creation the tool stack >>> has its own fallback, so it may not be of much use right now.) >> >> I think the description in the public header needs to be expanded to >> specify what the XENMEM_exchange does for translated guests, and >> clearly write down that the underlying MFNs for the exchanged region >> will be contiguous. Possibly a new XENMEMF_ flag needs to be added to >> request contiguous physical memory for the new range. >> >> Sadly this also has the side effect of quite likely shattering >> superpages for dom0 EPT/NPT, which will result in decreased dom0 >> performance. Yes, this appears to happen as memory_exchange seems to always replace the pages. I tested returning the existing MFNs if they are already contiguous since that was sufficient for this driver. It worked, but it was messy. A big loop to copy in the GFN array and check contiguity which duplicated much of the real loop. >> We have so far avoided exposing MFNs to HVM/PVH, but I don't see much >> way to avoid this if there's no option to use IOMMU or NPT page-tables >> with the PSP and we don't want to intercept PSP accesses in Xen and >> translate requests on the fly. > > Yeah, I think the same way too. Regards, Jason From xen-devel-bounces@lists.xenproject.org Thu May 01 14:20:58 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 14:20:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974162.1362093 (Exim 4.92) (envelope-from ) id 1uAUmQ-0000aU-P8; Thu, 01 May 2025 14:20:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974162.1362093; Thu, 01 May 2025 14:20: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 1uAUmQ-0000aN-M7; Thu, 01 May 2025 14:20:50 +0000 Received: by outflank-mailman (input) for mailman id 974162; Thu, 01 May 2025 14:19:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAUlX-0007ss-4m for xen-devel@lists.xenproject.org; Thu, 01 May 2025 14:19:55 +0000 Received: from mail-wm1-x349.google.com (mail-wm1-x349.google.com [2a00:1450:4864:20::349]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 57719e8d-2697-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 16:19:50 +0200 (CEST) Received: by mail-wm1-x349.google.com with SMTP id 5b1f17b1804b1-43d00017e9dso4366235e9.0 for ; Thu, 01 May 2025 07:19: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" X-Inumbo-ID: 57719e8d-2697-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746109189; x=1746713989; darn=lists.xenproject.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=TmEF1yP8U0niebBh9hfc5iyUEhI2jhPWqahRuFkaIQM=; b=p97jVs5M78NaXH/fKcYp1hHsNMMwzdQb+FmeejZH1I5gLAqho0p8VOM46kaPyiQhrC cTUT59aHIKES1kOp7QB92AtbP76CBQ7FsTxoaox5fv8+/S9DHcjTBqhfWpjo36Ibte/t XQuYiyw3Y2CFwj79rJO056sFUvLpBxdWtmc6kF0CDPXMSE08GRuHEHbNQE3j46Ju/4wh +V9ZleFGJcy7Y8BMHcWroMozxk+2mPuH1tVYu8memDqrIcquIe1pvhnUSA4W1S7uG1LZ wRDQ1LkpHkAPnKRPh8yPGo8hMqNqc2azGqMIUXSz7Jvv3ZB8Zwg9i84qsmQMm3ua2CN/ V8VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746109189; x=1746713989; h=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; bh=TmEF1yP8U0niebBh9hfc5iyUEhI2jhPWqahRuFkaIQM=; b=F1KZ3fpqvP45utk9HmtJN46h4yHexvbm+U1CmnoqdbK277+i9WIjsNag6WiU2mqGdK PtEERFA+2iFopeO+icPWSNZaMwPeT2co/8eDXnsxpegIKHU6LZGCNPKGKl3vnyVsRy1D WADxXmg3E2Rz8pL3GwljjRiMhfC2gwKzGhrHpkGPYP4q2agYTXCdLmwlELWkPGOv/IhT yYz8rIkUPtbu396YYluuRrPlzweTchCVS4esrI/DT7dWHIispvil2+O2kY/B9s2+bstF po0PcUsE1nH6WR7u1yO7iVsyyfDqV7yi6tEPCqyKoOOc8wmFOerDgrSpjL/VohV0t54U 0h2w== X-Forwarded-Encrypted: i=1; AJvYcCWdzpIsMjbGCFkUZv6EICiOvfJU3i0SN+viTSuSduzGwlKCr/Ro+GGcoBDHocHn/8ax/SlZeKYoJG4=@lists.xenproject.org X-Gm-Message-State: AOJu0YynIpWPaB1FPXF6/sbky1wey8vbJVHw9JoWI8zpsbMA8qQjfKTo m/V88AGt/Q6EPvzWfK0bHU6uTvNgAbryiOXr8lyb9OneNritdZxq4mMXeqkwRqpVlY/kZ7WVGZm Ac+jk+djOKg== X-Google-Smtp-Source: AGHT+IE4OWD5XxcERH4cgRX5gY9PM+u+mzYGVEd/YlTx4e+t3SrV5tDi5azUj0xMuNVR7NdRXpnF4uWQLtuxPQ== X-Received: from wmbhe15.prod.google.com ([2002:a05:600c:540f:b0:441:b79a:76cf]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:35d6:b0:43c:f8fc:f686 with SMTP id 5b1f17b1804b1-441b64ed9d8mr27510245e9.3.1746109189194; Thu, 01 May 2025 07:19:49 -0700 (PDT) Date: Thu, 01 May 2025 14:19:47 +0000 In-Reply-To: <20250429123504.GA13093@lst.de> Mime-Version: 1.0 References: <20250429-noautoinline-v3-0-4c49f28ea5b5@uniontech.com> <20250429123504.GA13093@lst.de> X-Mailer: aerc 0.20.0 Message-ID: Subject: Re: [PATCH RFC v3 0/8] kernel-hacking: introduce CONFIG_NO_AUTO_INLINE From: Brendan Jackman To: Christoph Hellwig , Cc: Keith Busch , Jens Axboe , Sagi Grimberg , Andrew Morton , Yishai Hadas , Jason Gunthorpe , Shameer Kolothum , Kevin Tian , Alex Williamson , Peter Huewe , Jarkko Sakkinen , Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Nick Desaulniers , Bill Wendling , Justin Stitt , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Zi Yan , Mathieu Desnoyers , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Dmitry Vyukov , Andrey Konovalov , Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H. Peter Anvin" , , , , , , , , , Winston Wen , , , Changbin Du , Linus Torvalds Content-Type: text/plain; charset="UTF-8" On Tue Apr 29, 2025 at 12:35 PM UTC, Christoph Hellwig wrote: > On Tue, Apr 29, 2025 at 12:06:04PM +0800, Chen Linxuan via B4 Relay wrote: >> This series introduces a new kernel configuration option NO_AUTO_INLINE, >> which can be used to disable the automatic inlining of functions. >> >> This will allow the function tracer to trace more functions >> because it only traces functions that the compiler has not inlined. > > This still feels like a bad idea because it is extremely fragile. Can you elaborate on that - does it introduce new fragility? From xen-devel-bounces@lists.xenproject.org Thu May 01 14:22:28 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 14:22:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974173.1362102 (Exim 4.92) (envelope-from ) id 1uAUnz-00017g-26; Thu, 01 May 2025 14:22:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974173.1362102; Thu, 01 May 2025 14:22: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 1uAUny-00017Z-V9; Thu, 01 May 2025 14:22:26 +0000 Received: by outflank-mailman (input) for mailman id 974173; Thu, 01 May 2025 14:22:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAUnx-00017R-PY for xen-devel@lists.xenproject.org; Thu, 01 May 2025 14:22:25 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b33d78bf-2697-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 16:22:23 +0200 (CEST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-ac2a81e41e3so169740066b.1 for ; Thu, 01 May 2025 07:22:23 -0700 (PDT) Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad0c70f0972sm47478966b.67.2025.05.01.07.22.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 May 2025 07:22: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" X-Inumbo-ID: b33d78bf-2697-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746109343; x=1746714143; darn=lists.xenproject.org; h=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; bh=wcWkAx97F8Z0cL8jd65I5dp4bYaWPn+MnAx5RymJTZs=; b=DifhO5BYS2iT2qehjsfr9hXbPOxp6/aB0nRs2ulKtjFUv8JOxMb3UtelpQ+6ULWKxk qbWmJtdT6Q9vmgtZYrIV5+PBdpC9QIrr1vwQ+O4hMOkViDHY99a7dCLHmFdyHpCxo/g3 aykLVLPcU20XGIuY+6ccHO1YVhZwbnk6ozi/iN8mg1O3fxD45FhTiXza65Yg9a0wlYSf J3LtaKY/MirBYmkSM7rAOX5WoflLM6j4dflS4uI3xTWYz4EndQZpXoJKX/zFtdRxOK9d pyoAWBSRCxRMCVqDXZc/pZEl6wihaRvldFXlzMsX7YXU6Vf9qzPuSUWAhxvxb2XZ4HJ4 amrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746109343; x=1746714143; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=wcWkAx97F8Z0cL8jd65I5dp4bYaWPn+MnAx5RymJTZs=; b=nilXhgowfks3zDAIM5JIZFfsES9emKiAn7bbapTZEVqjkJ0BTOYxfUS242byG9ZhTS EH56uCROu5P72d8qXCeMUF3/T2Ak5WwasoWcED7QCOSMHLt3tbXJgSOw7LjN4Lh8TUvK 73g3qwciwnPXMqIFo8KhfIIl/Ut0bDptpES9EYyPmyVHM6pdc1BEgu9LnqkRFj0UvlD1 VX4i3bNuI+6mgNRDanh3ENiUSmA5FwqLXxRmUP1RSFy1rE7BS2VAEJAZM+tBa/NCiw/D D7PFEd2+I5+dAC8oW1N8vA4MXt4hPBIiPqS/E5t82UaMw5nGrGRrkZQRPbGFjnKlTAxC igFw== X-Forwarded-Encrypted: i=1; AJvYcCWChJ2f8D2XQ23Qj5m239fhmL8lttd8+KL0nmLZm+xKU3zGNZt9fBS4+n7MqICpLYdEj6q09wkV8XE=@lists.xenproject.org X-Gm-Message-State: AOJu0YxR70fJ/dCMX7973qbxCzQKDOkqeAD4SM0qIbXLD9RXyW6bR9Hg /1iNjuUEY1A+mYaLS5m8dOYGgvHA165L7BybRpRuXgSDsIkRNbHpjuM9pg== X-Gm-Gg: ASbGncuqfsjj47Bypv63v1dt8H99ptDrOQ8os7V4YVYkbOxZihdH/onlkP8SEP2WAcH mD1oakUdxzXBWC6ebm8pv08AKoXUJrjfkgq72hpyy97rfpLP1gRHaruVUOHntZYBCS21vTBAtNj Bn6m9E+t5l6MZceMV7jtUZqIM5KKog1FCho8QE2W93xGz6ONqAdxlr1N2YdUJ/YAOvTdhD/Wzxf rooUmqvLs5D4hc4azaMD12AGsqLg9xAHxvw/mhYJR6thGmgNowLRtrR7tdsGQoSiKaDbMS2x6Gn Hf9IDTnnO/tTSoh6wwM/O40gc706LCZH3AdefkOWdtXdQ3lcgZwi/j3hqyTiIl/k7Ar2qPk7tVu hsooDLuLriD0LDVju X-Google-Smtp-Source: AGHT+IHSD75/z72ccQbKP/AvG9/c0GBkbRJZA0jl0y2xGp1/CjoKpEdTJy/JuEfBErKqrym6wWGj2Q== X-Received: by 2002:a17:907:980d:b0:ac7:18c9:2975 with SMTP id a640c23a62f3a-acef4bc6d35mr284958066b.48.1746109343006; Thu, 01 May 2025 07:22:23 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------Vx5DhOCTs6yFoRmsUPGQ1AFS" Message-ID: <9105a64f-e2e0-4a94-9cfa-3d9250c2714e@gmail.com> Date: Thu, 1 May 2025 16:22:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: move paddr_to_pdx() To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Anthony PERARD , Shawn Anastasio References: <262b9929-5cbd-4bb1-ac2a-35916273cba5@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <262b9929-5cbd-4bb1-ac2a-35916273cba5@suse.com> This is a multi-part message in MIME format. --------------Vx5DhOCTs6yFoRmsUPGQ1AFS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/30/25 5:56 PM, Jan Beulich wrote: > There's nothing arch-specific about it. > > While there, on x86 visually separate the vmap_to_*() macros from those > covered by the earlier comment. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/arm/include/asm/mm.h > +++ b/xen/arch/arm/include/asm/mm.h > @@ -237,7 +237,6 @@ static inline void __iomem *ioremap_wc(p > /* Convert between frame number and address formats. */ > #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT) > #define paddr_to_pfn(pa) ((unsigned long)((pa) >> PAGE_SHIFT)) > -#define paddr_to_pdx(pa) mfn_to_pdx(maddr_to_mfn(pa)) > #define gfn_to_gaddr(gfn) pfn_to_paddr(gfn_x(gfn)) > #define gaddr_to_gfn(ga) _gfn(paddr_to_pfn(ga)) > #define mfn_to_maddr(mfn) pfn_to_paddr(mfn_x(mfn)) > --- a/xen/arch/ppc/include/asm/mm.h > +++ b/xen/arch/ppc/include/asm/mm.h > @@ -13,7 +13,6 @@ void setup_initial_pagetables(void); > > #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT) > #define paddr_to_pfn(pa) ((unsigned long)((pa) >> PAGE_SHIFT)) > -#define paddr_to_pdx(pa) mfn_to_pdx(maddr_to_mfn(pa)) > #define gfn_to_gaddr(gfn) pfn_to_paddr(gfn_x(gfn)) > #define gaddr_to_gfn(ga) _gfn(paddr_to_pfn(ga)) > #define mfn_to_maddr(mfn) pfn_to_paddr(mfn_x(mfn)) > --- a/xen/arch/riscv/include/asm/mm.h > +++ b/xen/arch/riscv/include/asm/mm.h Reveiwed-by: Oleksii Kurochko ~ Oleksii > @@ -19,7 +19,6 @@ extern vaddr_t directmap_virt_start; > #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT) > #define paddr_to_pfn(pa) ((unsigned long)((pa) >> PAGE_SHIFT)) > > -#define paddr_to_pdx(pa) mfn_to_pdx(maddr_to_mfn(pa)) > #define gfn_to_gaddr(gfn) pfn_to_paddr(gfn_x(gfn)) > #define gaddr_to_gfn(ga) _gfn(paddr_to_pfn(ga)) > #define mfn_to_maddr(mfn) pfn_to_paddr(mfn_x(mfn)) > --- a/xen/arch/x86/include/asm/page.h > +++ b/xen/arch/x86/include/asm/page.h > @@ -258,7 +258,8 @@ void scrub_page_cold(void *); > #define mfn_to_virt(mfn) __mfn_to_virt(mfn) > #define pfn_to_paddr(pfn) __pfn_to_paddr(pfn) > #define paddr_to_pfn(pa) __paddr_to_pfn(pa) > -#define paddr_to_pdx(pa) pfn_to_pdx(paddr_to_pfn(pa)) > + > +/* Specialized forms acting on vmap() addresses. */ > #define vmap_to_mfn(va) xen_map_to_mfn((unsigned long)(va)) > #define vmap_to_page(va) mfn_to_page(vmap_to_mfn(va)) > > --- a/xen/include/xen/pdx.h > +++ b/xen/include/xen/pdx.h > @@ -98,6 +98,8 @@ bool __mfn_valid(unsigned long mfn); > #define mfn_to_pdx(mfn) pfn_to_pdx(mfn_x(mfn)) > #define pdx_to_mfn(pdx) _mfn(pdx_to_pfn(pdx)) > > +#define paddr_to_pdx(pa) pfn_to_pdx(paddr_to_pfn(pa)) > + > #ifdef CONFIG_PDX_COMPRESSION > > extern unsigned long pfn_pdx_bottom_mask, ma_va_bottom_mask; --------------Vx5DhOCTs6yFoRmsUPGQ1AFS Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 4/30/25 5:56 PM, Jan Beulich wrote:
There's nothing arch-specific about it.

While there, on x86 visually separate the vmap_to_*() macros from those
covered by the earlier comment.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -237,7 +237,6 @@ static inline void __iomem *ioremap_wc(p
 /* Convert between frame number and address formats.  */
 #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
 #define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
-#define paddr_to_pdx(pa)    mfn_to_pdx(maddr_to_mfn(pa))
 #define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
 #define gaddr_to_gfn(ga)    _gfn(paddr_to_pfn(ga))
 #define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
--- a/xen/arch/ppc/include/asm/mm.h
+++ b/xen/arch/ppc/include/asm/mm.h
@@ -13,7 +13,6 @@ void setup_initial_pagetables(void);
 
 #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
 #define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
-#define paddr_to_pdx(pa)  mfn_to_pdx(maddr_to_mfn(pa))
 #define gfn_to_gaddr(gfn) pfn_to_paddr(gfn_x(gfn))
 #define gaddr_to_gfn(ga)  _gfn(paddr_to_pfn(ga))
 #define mfn_to_maddr(mfn) pfn_to_paddr(mfn_x(mfn))
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
Reveiwed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
~ Oleksii

@@ -19,7 +19,6 @@ extern vaddr_t directmap_virt_start;
 #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
 #define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
 
-#define paddr_to_pdx(pa)    mfn_to_pdx(maddr_to_mfn(pa))
 #define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
 #define gaddr_to_gfn(ga)    _gfn(paddr_to_pfn(ga))
 #define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
--- a/xen/arch/x86/include/asm/page.h
+++ b/xen/arch/x86/include/asm/page.h
@@ -258,7 +258,8 @@ void scrub_page_cold(void *);
 #define mfn_to_virt(mfn)    __mfn_to_virt(mfn)
 #define pfn_to_paddr(pfn)   __pfn_to_paddr(pfn)
 #define paddr_to_pfn(pa)    __paddr_to_pfn(pa)
-#define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
+
+/* Specialized forms acting on vmap() addresses. */
 #define vmap_to_mfn(va)     xen_map_to_mfn((unsigned long)(va))
 #define vmap_to_page(va)    mfn_to_page(vmap_to_mfn(va))
 
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -98,6 +98,8 @@ bool __mfn_valid(unsigned long mfn);
 #define mfn_to_pdx(mfn) pfn_to_pdx(mfn_x(mfn))
 #define pdx_to_mfn(pdx) _mfn(pdx_to_pfn(pdx))
 
+#define paddr_to_pdx(pa) pfn_to_pdx(paddr_to_pfn(pa))
+
 #ifdef CONFIG_PDX_COMPRESSION
 
 extern unsigned long pfn_pdx_bottom_mask, ma_va_bottom_mask;
--------------Vx5DhOCTs6yFoRmsUPGQ1AFS-- From xen-devel-bounces@lists.xenproject.org Thu May 01 14:24:06 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 14:24:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974185.1362113 (Exim 4.92) (envelope-from ) id 1uAUpZ-0001ea-CJ; Thu, 01 May 2025 14:24:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974185.1362113; Thu, 01 May 2025 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 1uAUpZ-0001eT-8m; Thu, 01 May 2025 14:24:05 +0000 Received: by outflank-mailman (input) for mailman id 974185; Thu, 01 May 2025 14:24:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAUpY-0001eM-7N for xen-devel@lists.xenproject.org; Thu, 01 May 2025 14:24:04 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id edd0a8ee-2697-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 16:24:02 +0200 (CEST) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-ac3b12e8518so157212966b.0 for ; Thu, 01 May 2025 07:24:02 -0700 (PDT) Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad0da55afb7sm46083266b.124.2025.05.01.07.24.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 May 2025 07:24: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" X-Inumbo-ID: edd0a8ee-2697-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746109441; x=1746714241; darn=lists.xenproject.org; h=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; bh=oGx58QBo8s1Fm4SWVeSISV6z+REsDGmk2YbjJ4CAd/c=; b=YTIpOaWGP8wazyG8Z8CfGILnww/cXFGFzzqkjnNAijXrtNXq2+5YeSICqWxf2cnX4d 3kpZv+5I90cjGaQp8nV/rxemrIM+MmJo/ZZOz/2liJ6dWHADYKfo4qSPWu20+ouGJTIC 3XLg8qKKm0HsGfxVpFxHGv3MbFrXu/OIMqZiJAAGBjkisDpSoCUCfGXhxBjsYQg1vVHH n/PM/lpmriCeD9lumdPv/uGbM6FdNgazgj6wKpvfyzSryMOjjM6KZMTvYbLeV/bCfMKQ qqrKjQdeXZMIotLZzCgOVWIHbqk6hjP1GTxGw+6bE7jeY3lY0pOafRTczC4UZEmG4WXk NsnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746109441; x=1746714241; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=oGx58QBo8s1Fm4SWVeSISV6z+REsDGmk2YbjJ4CAd/c=; b=XUa1K+7U3gYhUtegTl28pRW4K0aabgQwHneQ7dUBpuz4DzQxKDHhfLv8gYEvFhgcdQ 0av869AQRhgCKuG/HbAu82uiy2NHruleKwK9EB8tjl29QihQyykGiSxn2hmvzTSfZdMQ iPsmbqXnD5z/wKHPs3OWO+yQ4Qec5030bSOajzQbeq/QYl+/9GZs/IdQ1i+1I2EeMaG/ yo5jKdVz/scqNJ+Dp//Gn/0a+Zul1uZgNNhrlPrhaq2EhQB/B0drNA3rvEhJNhhrzeAn /hLzQhGcTJtRf2idVGOcg8gp42sKOAC4yI4yY1cZzTUmVnbwLnL+IbLTPm90YjiAd7sy hdFQ== X-Gm-Message-State: AOJu0YxjBEdSIgtQ8nQRG1DVTKYMTgzoQRdlVBH/Bb0uNJ+GJXzSV8Pf EI0S3M3UJCSmoEuJAeFGTdYYtFczWyrKpIMmaq+a558o8akcLtQI X-Gm-Gg: ASbGnctvik07q9Owy6X0D3PP8yESjradUXuDfu8H1VgRGG9Z2BlmPiP9vk5RTJlUHHY oqqUkByoRcqnjSXbQBsOxjCyEGN+fTAPS6O2JThyzlie6vSIGcwxh/xgpX8UcgBjR9dGNVTS6c/ /ef9nikBYNn0TicbKkTIW+yBB1MM8Sg9b0ci6aqUGk8hpWbRaYqXBUIgO3eRpRGOR3s1Dglu9Zq ZUY/SQ/SXbIHpO/UPV2vHXLAlK7Rngb35kf7uPIPnQ9jgXxHRvG+q+w8jHutKW9FaBo5txOVO5A Bq7Tp0Z+IZXEFYGbIbTF5+11CNR/3w48cMpyKNAVC0VQLUzLVPwALXok6JnILcJKXXYqyasV1X4 oymUg2InzdIlBiUV+h4EuTq5asdo= X-Google-Smtp-Source: AGHT+IEL1Z+iJJecqWLBb5nQ+i/4kdtVVAMuM+85WpXwI7XMq+p/41XGSchCdAl7L1sypMsHrXyGlw== X-Received: by 2002:a17:907:86a4:b0:ac3:5c8e:d3f5 with SMTP id a640c23a62f3a-acef4299d67mr334387566b.27.1746109441258; Thu, 01 May 2025 07:24:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------aIh7CeGGeBPDjMz6Dzo6sC7q" Message-ID: Date: Thu, 1 May 2025 16:23:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/8] Move parts of Arm's Dom0less to common code To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: This is a multi-part message in MIME format. --------------aIh7CeGGeBPDjMz6Dzo6sC7q Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/1/25 2:55 AM, Stefano Stabellini wrote: > The patch series needs to be rebased. Actually, I couldn't find a > baseline where to apply patch #2 successfully The baseline is:   b0e54c0719 CI: write whole etc/issue for domU initrd But I will prepare and send new version of the patch series soon, and, of course, it will be rebased on top of current staging. ~ Oleksii > > On Mon, 14 Apr 2025, Oleksii Kurochko wrote: >> Some parts of Arm's Dom0less solution could be moved to common code as they are >> not truly Arm-specific. >> >> Most of the code is moved as is, with only minor changes introduced to provide >> abstractions that hide Arm-specific details, while maintaining functional >> equivalence with original Arm's code. >> >> There are several open questions: >> 1. Probably, the introduced headers currently placed in asm-generic should >> instead reside in the xen/include folder. >> 2. Perhaps the introduced *.c files should always be placed elsewhere. They >> have been put in device-tree common as they somewhat depend on device tree >> functionality. >> 3. The u64 and u32 types are widely used in the code where device tree >> functionality is implemented because these types are used in device tree >> function arguments. >> Should this be reworked to use uint32_t and uint64_t instead? If so, will it >> also be necessary to change the type of variables passed to dt-related >> functions, or should the argument types of device tree functions be updated >> too? For example: >> ``` >> u64 mem; >> ... >> rc = dt_property_read_u64(node, "memory", &mem); >> ``` >> where dt_property_read_u64 is declared as: >> bool dt_property_read_u64(... , u64 *out_value); >> 4. Instead of providing init_intc_phandle() (see the patch: [1]), perhaps it >> would be better to add a for loop in domain_handle_dtb_bootmodule()? >> Something like: >> ``` >> bool is_intc_phandle_inited = false; >> for ( unsigned int i = 0; i < ARRAY_SIZE(intc_names_array); i++ ) >> { >> if ( dt_node_cmp(name, intc_names_array[i]) == 0 ) >> { >> uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); >> >> if ( phandle_intc != 0 ) >> kinfo->phandle_intc = phandle_intc; >> >> is_intc_phandle_inited = true; >> break; >> } >> } >> >> if ( is_intc_phandle_inited ) continue; >> ``` >> >> [1]] [PATCH v1 9/9] xen/common: dom0less: introduce common dom0less-build.c >> >> --- >> Changes in v2: >> - Update cover letter message. >> - Rebase on top of the current staging. >> - Drop patches: >> - asm-generic: move Arm's static-memory.h to asm-generic >> - asm-generic: move Arm's static-shmem.h to asm-generic >> as in the nearest future there is no real users of STATIC_MEMORY and >> STATIC_SHMEM. >> - Add new cleanup patch: >> [PATCH v2 1/8] xen/arm: drop declaration of handle_device_interrupts() >> - All other changes are patch specific. Please check them seprately for each >> patch >> --- >> >> Oleksii Kurochko (8): >> xen/arm: drop declaration of handle_device_interrupts() >> xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common >> asm-generic: move parts of Arm's asm/kernel.h to common code >> arm/static-shmem.h: drop inclusion of asm/setup.h >> asm-generic: move some parts of Arm's domain_build.h to common >> xen/common: dom0less: introduce common kernel.c >> xen/common: dom0less: introduce common domain-build.c >> xen/common: dom0less: introduce common dom0less-build.c >> >> xen/arch/arm/Kconfig | 10 +- >> xen/arch/arm/acpi/domain_build.c | 4 +- >> xen/arch/arm/dom0less-build.c | 997 +++------------------- >> xen/arch/arm/domain_build.c | 411 +-------- >> xen/arch/arm/include/asm/Makefile | 1 + >> xen/arch/arm/include/asm/dom0less-build.h | 32 - >> xen/arch/arm/include/asm/domain_build.h | 31 +- >> xen/arch/arm/include/asm/kernel.h | 126 +-- >> xen/arch/arm/include/asm/static-memory.h | 2 +- >> xen/arch/arm/include/asm/static-shmem.h | 2 +- >> xen/arch/arm/kernel.c | 234 +---- >> xen/arch/arm/static-memory.c | 1 + >> xen/arch/arm/static-shmem.c | 3 +- >> xen/common/Kconfig | 19 + >> xen/common/device-tree/Makefile | 3 + >> xen/common/device-tree/dom0less-build.c | 891 +++++++++++++++++++ >> xen/common/device-tree/domain-build.c | 404 +++++++++ >> xen/common/device-tree/dt-overlay.c | 4 +- >> xen/common/device-tree/kernel.c | 242 ++++++ >> xen/include/asm-generic/dom0less-build.h | 82 ++ >> xen/include/xen/fdt-domain-build.h | 77 ++ >> xen/include/xen/fdt-kernel.h | 146 ++++ >> 22 files changed, 2013 insertions(+), 1709 deletions(-) >> delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h >> create mode 100644 xen/common/device-tree/dom0less-build.c >> create mode 100644 xen/common/device-tree/domain-build.c >> create mode 100644 xen/common/device-tree/kernel.c >> create mode 100644 xen/include/asm-generic/dom0less-build.h >> create mode 100644 xen/include/xen/fdt-domain-build.h >> create mode 100644 xen/include/xen/fdt-kernel.h >> >> -- >> 2.49.0 >> --------------aIh7CeGGeBPDjMz6Dzo6sC7q Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 5/1/25 2:55 AM, Stefano Stabellini wrote:
The patch series needs to be rebased. Actually, I couldn't find a
baseline where to apply patch #2 successfully
The baseline is:

  b0e54c0719 CI: write whole etc/issue for domU initrd

But I will prepare and send new version of the patch series soon, and, of course, it will be
rebased on top of current staging.

~ Oleksii


On Mon, 14 Apr 2025, Oleksii Kurochko wrote:

Some parts of Arm's Dom0less solution could be moved to common code as they are
not truly Arm-specific.

Most of the code is moved as is, with only minor changes introduced to provide
abstractions that hide Arm-specific details, while maintaining functional
equivalence with original Arm's code.

There are several open questions:
1. Probably, the introduced headers currently placed in asm-generic should
   instead reside in the xen/include folder.
2. Perhaps the introduced *.c files should always be placed elsewhere. They
   have been put in device-tree common as they somewhat depend on device tree
   functionality.
3. The u64 and u32 types are widely used in the code where device tree
   functionality is implemented because these types are used in device tree
   function arguments.
   Should this be reworked to use uint32_t and uint64_t instead? If so, will it
   also be necessary to change the type of variables passed to dt-related
   functions, or should the argument types of device tree functions be updated
   too? For example:
   ```
    u64 mem;
    ...
    rc = dt_property_read_u64(node, "memory", &mem);
   ```
   where dt_property_read_u64 is declared as:
     bool dt_property_read_u64(... , u64 *out_value);
4. Instead of providing init_intc_phandle() (see the patch: [1]), perhaps it
   would be better to add a for loop in domain_handle_dtb_bootmodule()?
   Something like:
   ```
    bool is_intc_phandle_inited = false;
    for ( unsigned int i = 0; i < ARRAY_SIZE(intc_names_array); i++ )
    {
        if ( dt_node_cmp(name, intc_names_array[i]) == 0 )
        {
            uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);

            if ( phandle_intc != 0 )
                kinfo->phandle_intc = phandle_intc;

            is_intc_phandle_inited = true;
            break;
        }
    }

    if ( is_intc_phandle_inited ) continue;
  ```

[1]] [PATCH v1 9/9] xen/common: dom0less: introduce common dom0less-build.c

---
Changes in v2:
- Update cover letter message.
- Rebase on top of the current staging.
- Drop patches:
   - asm-generic: move Arm's static-memory.h to asm-generic
   - asm-generic: move Arm's static-shmem.h to asm-generic
  as in the nearest future there is no real users of STATIC_MEMORY and
  STATIC_SHMEM.
- Add new cleanup patch:
  [PATCH v2 1/8] xen/arm: drop declaration of handle_device_interrupts()
- All other changes are patch specific. Please check them seprately for each
  patch
---

Oleksii Kurochko (8):
  xen/arm: drop declaration of handle_device_interrupts()
  xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common
  asm-generic: move parts of Arm's asm/kernel.h to common code
  arm/static-shmem.h: drop inclusion of asm/setup.h
  asm-generic: move some parts of Arm's domain_build.h to common
  xen/common: dom0less: introduce common kernel.c
  xen/common: dom0less: introduce common domain-build.c
  xen/common: dom0less: introduce common dom0less-build.c

 xen/arch/arm/Kconfig                      |  10 +-
 xen/arch/arm/acpi/domain_build.c          |   4 +-
 xen/arch/arm/dom0less-build.c             | 997 +++-------------------
 xen/arch/arm/domain_build.c               | 411 +--------
 xen/arch/arm/include/asm/Makefile         |   1 +
 xen/arch/arm/include/asm/dom0less-build.h |  32 -
 xen/arch/arm/include/asm/domain_build.h   |  31 +-
 xen/arch/arm/include/asm/kernel.h         | 126 +--
 xen/arch/arm/include/asm/static-memory.h  |   2 +-
 xen/arch/arm/include/asm/static-shmem.h   |   2 +-
 xen/arch/arm/kernel.c                     | 234 +----
 xen/arch/arm/static-memory.c              |   1 +
 xen/arch/arm/static-shmem.c               |   3 +-
 xen/common/Kconfig                        |  19 +
 xen/common/device-tree/Makefile           |   3 +
 xen/common/device-tree/dom0less-build.c   | 891 +++++++++++++++++++
 xen/common/device-tree/domain-build.c     | 404 +++++++++
 xen/common/device-tree/dt-overlay.c       |   4 +-
 xen/common/device-tree/kernel.c           | 242 ++++++
 xen/include/asm-generic/dom0less-build.h  |  82 ++
 xen/include/xen/fdt-domain-build.h        |  77 ++
 xen/include/xen/fdt-kernel.h              | 146 ++++
 22 files changed, 2013 insertions(+), 1709 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h
 create mode 100644 xen/common/device-tree/dom0less-build.c
 create mode 100644 xen/common/device-tree/domain-build.c
 create mode 100644 xen/common/device-tree/kernel.c
 create mode 100644 xen/include/asm-generic/dom0less-build.h
 create mode 100644 xen/include/xen/fdt-domain-build.h
 create mode 100644 xen/include/xen/fdt-kernel.h

-- 
2.49.0
--------------aIh7CeGGeBPDjMz6Dzo6sC7q-- From xen-devel-bounces@lists.xenproject.org Thu May 01 15:03:38 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 15:03:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974202.1362123 (Exim 4.92) (envelope-from ) id 1uAVRb-0007rK-32; Thu, 01 May 2025 15:03:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974202.1362123; Thu, 01 May 2025 15: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 1uAVRb-0007rD-01; Thu, 01 May 2025 15:03:23 +0000 Received: by outflank-mailman (input) for mailman id 974202; Thu, 01 May 2025 15:03:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAVRY-0007r7-3T for xen-devel@lists.xenproject.org; Thu, 01 May 2025 15:03:21 +0000 Received: from casper.infradead.org (casper.infradead.org [2001:8b0:10b:1236::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6403bcca-269d-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 17:03:13 +0200 (CEST) Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1uAVQk-00000000oH8-33tB; Thu, 01 May 2025 15:02:30 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 1B7DC30072F; Thu, 1 May 2025 17:02: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" X-Inumbo-ID: 6403bcca-269d-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=SknNweDJMYv6Cc7JXUCuginAJHi4T0ZKllMpOn1Yf9A=; b=QE9K7S0FqJXdRMiI2MUQfyFVKN zJkaOZZAvX0UK9xBOJnD6xr1oo4dLko0vESRIIkP4sjHHPxZkleb2D8Zai321exEYA2JJr82ElX7s y72vsCa48dbNhj3sR2u6AvvpDc6GUftTpqrd7fLDiVr8l4ZJcPOvCc/B4Kso/X5VwtY001koeorb7 w0lpR1LpdbzQwtNNGzQXqNnli6Sbl3pH+QAdCVePhkf3FUFd/ngVNiv41q8dPOdm8t1mbTM/UmJ5P NuryBBTCcNBBOjT/+JRWnUfQQL+DhMwA+igl0308JTBNEPRBnnqN+OImNHFtw2Imib6YH9ERSKUcP cmUpe09A==; Date: Thu, 1 May 2025 17:02:29 +0200 From: Peter Zijlstra To: Brendan Jackman Cc: Christoph Hellwig , chenlinxuan@uniontech.com, Keith Busch , Jens Axboe , Sagi Grimberg , Andrew Morton , Yishai Hadas , Jason Gunthorpe , Shameer Kolothum , Kevin Tian , Alex Williamson , Peter Huewe , Jarkko Sakkinen , Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Nick Desaulniers , Bill Wendling , Justin Stitt , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Zi Yan , Mathieu Desnoyers , "Paul E. McKenney" , Boqun Feng , Dmitry Vyukov , Andrey Konovalov , Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-integrity@vger.kernel.org, linux-kbuild@vger.kernel.org, llvm@lists.linux.dev, Winston Wen , kasan-dev@googlegroups.com, xen-devel@lists.xenproject.org, Changbin Du , Linus Torvalds Subject: Re: [PATCH RFC v3 0/8] kernel-hacking: introduce CONFIG_NO_AUTO_INLINE Message-ID: <20250501150229.GU4439@noisy.programming.kicks-ass.net> References: <20250429-noautoinline-v3-0-4c49f28ea5b5@uniontech.com> <20250429123504.GA13093@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, May 01, 2025 at 02:19:47PM +0000, Brendan Jackman wrote: > On Tue Apr 29, 2025 at 12:35 PM UTC, Christoph Hellwig wrote: > > On Tue, Apr 29, 2025 at 12:06:04PM +0800, Chen Linxuan via B4 Relay wrote: > >> This series introduces a new kernel configuration option NO_AUTO_INLINE, > >> which can be used to disable the automatic inlining of functions. > >> > >> This will allow the function tracer to trace more functions > >> because it only traces functions that the compiler has not inlined. > > > > This still feels like a bad idea because it is extremely fragile. > > Can you elaborate on that - does it introduce new fragility? given it needs to sprinkle __always_inline around where it wasn't needed before, yeah. Also, why would you want this? function tracer is already too much output. Why would you want even more? From xen-devel-bounces@lists.xenproject.org Thu May 01 15:23:05 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 15:23:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974214.1362133 (Exim 4.92) (envelope-from ) id 1uAVka-0002az-Eh; Thu, 01 May 2025 15:23:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974214.1362133; Thu, 01 May 2025 15:23: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 1uAVka-0002as-Bm; Thu, 01 May 2025 15:23:00 +0000 Received: by outflank-mailman (input) for mailman id 974214; Thu, 01 May 2025 15:22:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAVkZ-0002aj-7l for xen-devel@lists.xenproject.org; Thu, 01 May 2025 15:22:59 +0000 Received: from mail-wm1-x349.google.com (mail-wm1-x349.google.com [2a00:1450:4864:20::349]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2919b1ea-26a0-11f0-9eb4-5ba50f476ded; Thu, 01 May 2025 17:22:57 +0200 (CEST) Received: by mail-wm1-x349.google.com with SMTP id 5b1f17b1804b1-43d734da1a3so4127795e9.0 for ; Thu, 01 May 2025 08:22: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" X-Inumbo-ID: 2919b1ea-26a0-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746112977; x=1746717777; darn=lists.xenproject.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=wm8HDKzWcPs/ZOJ7u1MGp3oUtkY4RQR0TPLRQCBj5DQ=; b=yrI6apzXc9Erfcp4hcfv8/Z7jIep8cZyydUuhap1r/uiQIgb1WVfoM1wb83jj/7qSY 7wZIWjdXpjX03PnjDghzaNdtnI+3yslVJtsjkfeSjg1hVz9Jf7aWN7nyiW99c5cCYDlq zsP+ex1KKXZErr03M4BOoCGJePWMjphAPdm5i/XnFtZe+SSxWTWeJEeB935YBshkt572 +TLDd1X5nokx+zRXuLc9PlSQqgP7CSXm+lKFRNcdxfxT7P3f9XIHShSULnY8TQiucSO4 S85TktLcoBNkHmsSx6x0DbWTYuJI5NtYDPR2H2DJTuCK+cHqYeJOIwT1+iewH1ErkwPb DLXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746112977; x=1746717777; h=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; bh=wm8HDKzWcPs/ZOJ7u1MGp3oUtkY4RQR0TPLRQCBj5DQ=; b=VFL5MdUHvXmEOUzcirdmCFeN8gO7tb9iWKRPAM3I9DbSeUvy41j2okQdCVTtqtvvyK 0v+XUWJ5yA1AmQ4BcVRhOMu2YHmwRjR/3FgNHlYK6neit8VnjOMqOK86ANh3m+oa/Sir ZTg6Vi4A8Ez9RaRVrBQw0NpF7/jyZrGhap0MpFmmleTIaosV4uIEbajMXZRNDYK2tJnc 8Xx0OWmEXgx+6+pwAlYg7yTkXIGjxRW7SvWjkdZQ3xVHtQHzN7owmBAs/XJfEBJijH+I GlSrQbTDroJCuTOzc95Qnuvi8wv/2cHREaI/v5YRE2iBVmZZWmHxKM50x/AK9E5oNj0+ KMmw== X-Forwarded-Encrypted: i=1; AJvYcCWQELrQSTC4tngtMg1y7oyZurNe+Jt1QUfObZbxu7ur7nq1yHJW/8KjodpSvcMzggLqJ2NOSpvEJBo=@lists.xenproject.org X-Gm-Message-State: AOJu0YyzhLGPLdysGzyJ+vJTfejq8KP2L1mCdBVJ/E4Q781nCfhynHS+ +jacDOFLwHIBDzYgLTkEQ6v2f0mobrine5dAX6B/uTt16CDbzbiGxzP+ZwqiIN4luIH+esrBin/ SmHZ+xw6nmA== X-Google-Smtp-Source: AGHT+IG1H8EWFmTdy9mXUfcCJxQBprr6abVa1X9treBvRrD020Cub+yFF9voa0K8UUVl5WCrL4gH+SDc7+SKLQ== X-Received: from wmbel14.prod.google.com ([2002:a05:600c:3e0e:b0:440:5f8a:667c]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:4ec6:b0:43d:a90:9f1 with SMTP id 5b1f17b1804b1-441b2635482mr61130455e9.6.1746112976936; Thu, 01 May 2025 08:22:56 -0700 (PDT) Date: Thu, 01 May 2025 15:22:55 +0000 In-Reply-To: <20250501150229.GU4439@noisy.programming.kicks-ass.net> Mime-Version: 1.0 References: <20250429-noautoinline-v3-0-4c49f28ea5b5@uniontech.com> <20250429123504.GA13093@lst.de> <20250501150229.GU4439@noisy.programming.kicks-ass.net> X-Mailer: aerc 0.20.0 Message-ID: Subject: Re: [PATCH RFC v3 0/8] kernel-hacking: introduce CONFIG_NO_AUTO_INLINE From: Brendan Jackman To: Peter Zijlstra Cc: Christoph Hellwig , , Keith Busch , Jens Axboe , Sagi Grimberg , Andrew Morton , Yishai Hadas , Jason Gunthorpe , Shameer Kolothum , Kevin Tian , Alex Williamson , Peter Huewe , Jarkko Sakkinen , Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Nick Desaulniers , Bill Wendling , Justin Stitt , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Zi Yan , Mathieu Desnoyers , "Paul E. McKenney" , Boqun Feng , Dmitry Vyukov , Andrey Konovalov , Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H. Peter Anvin" , , , , , , , , , Winston Wen , , , Changbin Du , Linus Torvalds Content-Type: text/plain; charset="UTF-8" On Thu May 1, 2025 at 3:02 PM UTC, Peter Zijlstra wrote: > On Thu, May 01, 2025 at 02:19:47PM +0000, Brendan Jackman wrote: >> On Tue Apr 29, 2025 at 12:35 PM UTC, Christoph Hellwig wrote: >> > On Tue, Apr 29, 2025 at 12:06:04PM +0800, Chen Linxuan via B4 Relay wrote: >> >> This series introduces a new kernel configuration option NO_AUTO_INLINE, >> >> which can be used to disable the automatic inlining of functions. >> >> >> >> This will allow the function tracer to trace more functions >> >> because it only traces functions that the compiler has not inlined. >> > >> > This still feels like a bad idea because it is extremely fragile. >> >> Can you elaborate on that - does it introduce new fragility? > > given it needs to sprinkle __always_inline around where it wasn't needed > before, yeah. Right, I guess I just wouldn't have associated that with the word "fragility", but that's a reasonable complaint! > Also, why would you want this? function tracer is already too much > output. Why would you want even more? Yes, tracing every function is already too noisy, this would make it even more too-noisy, not sure "too noisy" -> "way too noisy" is a particularly meaningful degradation. Whereas enlarging the pool of functions that you can _optionally target_ for tracing, or nice reliable breakpoints in GDB, and disasm that's easier to mentally map back to C, seems like a helpful improvement for test builds. Personally I sometimes spam a bunch of `noinline` into code I'm debugging so this seems like a way to just slap that same thing on the whole tree without dirtying the code, right? Not that I have a strong opinion on the cost/benefit here, but the benefit seems nonzero to me. From xen-devel-bounces@lists.xenproject.org Thu May 01 15:51:15 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 15:51:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974229.1362142 (Exim 4.92) (envelope-from ) id 1uAWBo-0007H8-GF; Thu, 01 May 2025 15:51:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974229.1362142; Thu, 01 May 2025 15: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 1uAWBo-0007H1-DC; Thu, 01 May 2025 15:51:08 +0000 Received: by outflank-mailman (input) for mailman id 974229; Thu, 01 May 2025 15:51:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAWBn-0007Fd-Ib for xen-devel@lists.xenproject.org; Thu, 01 May 2025 15:51:07 +0000 Received: from casper.infradead.org (casper.infradead.org [2001:8b0:10b:1236::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 164c51e8-26a4-11f0-9eb4-5ba50f476ded; Thu, 01 May 2025 17:51:05 +0200 (CEST) Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1uAWBP-00000000vWm-1k5y; Thu, 01 May 2025 15:50:43 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 04927300642; Thu, 1 May 2025 17:50: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" X-Inumbo-ID: 164c51e8-26a4-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=P3VRTKEBNLquqRhFZYT5aVzDoqfQbBS2lj2/Gfm1dd8=; b=Vvw1f1nb4tZTNYWo7mO6z9pHzV MDmnoqAqu2hmb0i0BZCMhG/WDMQlC58Cw73kwpES9YsUR9uVYBATrwEJOHRNIo/+tiKLtb+lnOGfX 3RQDTcQJHo8yw/zOwlj2RzWNFYXhC2VQIUF/gJjLBZWYPMdo4SndGy1x8v2X1nLPEmzP9XY04eDER 6wiFSA1LKBYitCkX2q34LCGcLleraMkw5CpiczInfDqlRcnA1DkoaezY3MLQ7ZnDpb3tBsrvLAH0S h83K01vh+L05Z2s0lZBeMEnAZ2cFAgQ3S5nprdKJg8w8nz2cckeve7tiH0FBgOln3Yo1AMJl2OmyX jjUfpXpQ==; Date: Thu, 1 May 2025 17:50:42 +0200 From: Peter Zijlstra To: Brendan Jackman Cc: Christoph Hellwig , chenlinxuan@uniontech.com, Keith Busch , Jens Axboe , Sagi Grimberg , Andrew Morton , Yishai Hadas , Jason Gunthorpe , Shameer Kolothum , Kevin Tian , Alex Williamson , Peter Huewe , Jarkko Sakkinen , Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Nick Desaulniers , Bill Wendling , Justin Stitt , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Zi Yan , Mathieu Desnoyers , "Paul E. McKenney" , Boqun Feng , Dmitry Vyukov , Andrey Konovalov , Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-integrity@vger.kernel.org, linux-kbuild@vger.kernel.org, llvm@lists.linux.dev, Winston Wen , kasan-dev@googlegroups.com, xen-devel@lists.xenproject.org, Changbin Du , Linus Torvalds Subject: Re: [PATCH RFC v3 0/8] kernel-hacking: introduce CONFIG_NO_AUTO_INLINE Message-ID: <20250501155042.GR4198@noisy.programming.kicks-ass.net> References: <20250429-noautoinline-v3-0-4c49f28ea5b5@uniontech.com> <20250429123504.GA13093@lst.de> <20250501150229.GU4439@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, May 01, 2025 at 03:22:55PM +0000, Brendan Jackman wrote: > Whereas enlarging the pool of functions that you can _optionally target_ > for tracing, or nice reliable breakpoints in GDB, and disasm that's > easier to mentally map back to C, seems like a helpful improvement for > test builds. Personally I sometimes spam a bunch of `noinline` into code > I'm debugging so this seems like a way to just slap that same thing on > the whole tree without dirtying the code, right? Dunno, I'm more of the printk school of debugging. Very rarely do I bother with GDB (so rare in fact that I have to look up how to even do this). From xen-devel-bounces@lists.xenproject.org Thu May 01 18:17:19 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 18:17:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974248.1362153 (Exim 4.92) (envelope-from ) id 1uAYT4-0001fB-6u; Thu, 01 May 2025 18:17:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974248.1362153; Thu, 01 May 2025 18:17: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 1uAYT4-0001f4-42; Thu, 01 May 2025 18:17:06 +0000 Received: by outflank-mailman (input) for mailman id 974248; Thu, 01 May 2025 18:17:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAYT2-0001ey-PC for xen-devel@lists.xenproject.org; Thu, 01 May 2025 18:17:04 +0000 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [2a00:1450:4864:20::432]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 78c7c6b2-26b8-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 20:16:59 +0200 (CEST) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-39ac9aea656so1242705f8f.3 for ; Thu, 01 May 2025 11:16:59 -0700 (PDT) Received: from localhost.localdomain (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a095a4bd22sm1409067f8f.46.2025.05.01.11.16.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 May 2025 11:16:58 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 78c7c6b2-26b8-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1746123418; x=1746728218; 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; bh=fAH9Te2E+GDORnDRSzkoVXYr91QG3/tdbA/aoY+A3k0=; b=SIrN/fv2Fhlcp4grK7DtnBgRFYMIeQhvsiIO9aCszUmym0grzHOw7dSs/LqhUpuRx7 +2os6aSBKPlVkUT42FcO28iuf7GzRfrANwww4qCtCzE7CneoLcMVsIpYfsT1l+e9Ises Qnm9gkMHWSn2W8Vxxsz7jhGvlpUeivTHnogcc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746123418; x=1746728218; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fAH9Te2E+GDORnDRSzkoVXYr91QG3/tdbA/aoY+A3k0=; b=kgPjpBAtRL3fFqD8JXxH1KyNRwCgh9niZtdL9qscyHjWucO1CesZ3dnmR8EbOoxrBl Kad7lf7T2S46yi3X0wXIO1zvXOwG3LqEsZJBeisk6scLOPRQiOLVQpqBg4iJnqNTAoOM 5+zFwLtnzDQJkhAIwBaFlUruq0HYgXmA4Mu8LHDJ4HOCXDoJyggI4l4YYrx34EPg1RL5 njurGHdP3/8uxzF2SI+Ghg2ul5CnMNH+f4TD7qZglFqNBau1oUZMx3cVqjvd0Fc20xSV 27VRJiPri8uqTbX+/VbvUErYEWNC2CaYOy8/avCivqGDCZWjkw3mY0cZfHHnPN6vBQuT 84Vw== X-Gm-Message-State: AOJu0YwiTDlbRxmys411jbq48bapklUgTjH/u5gjixHZqqNhfn/pHiS8 0lrn3ABEhKTz+metoPdS+2279kiM7VD3++hRCeWlgJbt5XMP+8W8NbMw1FSoVZO6adNfA8OjulR C X-Gm-Gg: ASbGnctOINsSA7/p7z2OwWXg9jjHslwY8AzDxFgCa7plQHveiSO8fn7rWVfn3DvMlVu wPNQptep1i1MeZx+OQBbxw5MdIbJDz2LNfJEzwn5HUosFQnE6jWiuP9tBrF7O3udHX1TRynXwFh 2tk1eGk52Sk2es5BBE2qFxKeqK1FQedndZUnGtNrDaG+Vn2KBRH1dQpKd9X8B3HN5EYJd97LR2p ntIPF+yhAQgR6JC/P6hLHooPbHpwZTAkW9CqT3Y8cw+ohFtVdFJ6iUR3u0pJVZM9sJYvwBhshg0 pnMU8Bvzl2VCZz1dtOjXYLNdt150Zc0G3dvucPsyqcG8vu1UYSTQne9jL9e/IHlMMLURDfrjnMN O9lDH0DvHeonneQ== X-Google-Smtp-Source: AGHT+IFBrpGwTBy2z3nZpqTX2sJdVAbckmwTeBLux71uYOSkM7ZT6rxn+PrIyyrLOQKr6WfEdIsjVQ== X-Received: by 2002:adf:e34a:0:b0:39e:f9e8:d07d with SMTP id ffacd0b85a97d-3a09404c668mr2113589f8f.20.1746123418443; Thu, 01 May 2025 11:16:58 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86/thunk: Don't opencode TSX instructions in clear_bhb_tsx() Date: Thu, 1 May 2025 19:16:55 +0100 Message-Id: <20250501181655.711704-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 The new toolchain baseline understands the RTM instructions. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné --- xen/arch/x86/bhb-thunk.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/bhb-thunk.S b/xen/arch/x86/bhb-thunk.S index 678c00c5d06f..f5ac41834bbd 100644 --- a/xen/arch/x86/bhb-thunk.S +++ b/xen/arch/x86/bhb-thunk.S @@ -19,8 +19,8 @@ * disabled for e.g. TAA mitigation reasons. */ FUNC(clear_bhb_tsx) - .byte 0xc7, 0xf8; .long 1f - 0f /* xbegin 1f */ -0: .byte 0xc6, 0xf8, 0 /* xabort $0 */ + xbegin 1f + xabort $0 int3 1: ret -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Thu May 01 19:24:54 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 19:24:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974265.1362163 (Exim 4.92) (envelope-from ) id 1uAZWS-0002RS-0s; Thu, 01 May 2025 19:24:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974265.1362163; Thu, 01 May 2025 19: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 1uAZWR-0002RL-Tr; Thu, 01 May 2025 19:24:39 +0000 Received: by outflank-mailman (input) for mailman id 974265; Thu, 01 May 2025 19:24:38 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAZWQ-0002RF-5i for xen-devel@lists.xenproject.org; Thu, 01 May 2025 19:24:38 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2061c.outbound.protection.outlook.com [2a01:111:f403:2413::61c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e82e7f78-26c1-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 21:24:32 +0200 (CEST) Received: from SJ2PR07CA0016.namprd07.prod.outlook.com (2603:10b6:a03:505::16) by DS5PPF5E0E7945E.namprd12.prod.outlook.com (2603:10b6:f:fc00::650) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.27; Thu, 1 May 2025 19:24:29 +0000 Received: from SJ1PEPF000023D6.namprd21.prod.outlook.com (2603:10b6:a03:505:cafe::72) by SJ2PR07CA0016.outlook.office365.com (2603:10b6:a03:505::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8655.42 via Frontend Transport; Thu, 1 May 2025 19:24:29 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ1PEPF000023D6.mail.protection.outlook.com (10.167.244.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8722.2 via Frontend Transport; Thu, 1 May 2025 19:24:28 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 1 May 2025 14:24:27 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 1 May 2025 14:24:27 -0500 Received: from ubuntu-linux-20-04-desktop.tail503a2a.ts.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Thu, 1 May 2025 14:24: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" X-Inumbo-ID: e82e7f78-26c1-11f0-9ffb-bf95429c2676 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FyFzfuNWvW8dMt1OiJluOSd1znOerC+pmns6m8HOArnq8HkPGkEaYyF4G3v/5WptQf0zhd63Kh6YDZ8JROF8xVyF/YpPes7mWAgDY/qdPvJb4T+AFTtKFb1ddu42s/5fxY4uRdHHJvdEWP/o7sRQmNx+jyUE59GEmhLnY2GszpVSrFgyeeA+JlFlbCl9o4fdDFhqDh9/QJOsGaSiVFoREMh6zzSh5QvL38JBU1dRG88tobepygL6LKX+CV4aB5u49NnOVMUWg37X+7JtL/jTg39o/ZssV/Vlc8lehWZKox3zl0vnEKwIlVoAuauPSNyt4zLXuoZOowMFobxk52HPOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WWFyBkGcolLP6ZBoxo2upVGUXUcmgDq+Pw6vE898w6o=; b=l+YfmmyhEK73xh4WvpJex34VZycsiNbsW4fRm82NL8lrT+L7GLVhNtZaP2KwValnu+X71hbPeDOfteGnj1muYjngqseUQIq5fJQLuZku6+hE/JsR20KOvGfpmfafg9gO67SpFQrjoVMvvC9/L/DYxd4ZYaQR2ptaaiQykYFpQKztAw7AFkl2dtzxpF0f1yOCHLg1e1sRxOLP7uRgSCm36K9qRl6cSSnD+cayNvzhQRPEE8hAL95niX+a8GKqOetbaM7MVGUmXxqUq05KlTmVdaGMoc1n6PuLc3Q0MEzSfkSeHwGn3PGp47gKqLPBMPPu6J8RbSUFq1PVGmfNJMTjUw== 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=WWFyBkGcolLP6ZBoxo2upVGUXUcmgDq+Pw6vE898w6o=; b=GZxWC5AN+fKgeXswHrvjLAMGSqcoibMgRjPIWht/nQYGWqycUR0tVsgqCT8jrCIHXk0bHgPcpPbRQwd0GDlWJJYYthsbjSzGBewDbMq07CaevWcHNmuLkmLSdqndRMkExm02xfyA3mKDpMt+N0VMXn6jWJH4xT6HEd8k17fsGeA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Stefano Stabellini To: CC: , , , , , , , , Stefano Stabellini Subject: [PATCH] misra: update list of GCC extensions used by Xen Date: Thu, 1 May 2025 12:24:24 -0700 Message-ID: <20250501192424.197012-1-stefano.stabellini@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: SJ1PEPF000023D6:EE_|DS5PPF5E0E7945E:EE_ X-MS-Office365-Filtering-Correlation-Id: 544175a4-4f19-454a-7655-08dd88e5cad9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?6wKNAZydmQVlQjL9Ju3Rpz48XHcFyP9j3uyB89a9f6EhNP5trIVOFCqH7124?= =?us-ascii?Q?1d2CAk4WejA9bWZSAynNBkKn1HOirLu5AyuNI6Oh5BGN3OiJJlkua8bwaadm?= =?us-ascii?Q?kjZ8e7LPH0/PXaM4cGK+An4PoGxUzlZVuJt9RNWcsYw0tWfBLw350mmAOABE?= =?us-ascii?Q?p9Ho5yZLnOdjPa51m+9rGXUO4nCCFCA/nPMrc7osT47OOi9ZtyraGyyEX3QN?= =?us-ascii?Q?8ZTDStTyXyKmzft7xD+bawgcUQTPw8oeQU7qzAw7pQacTk+79HXnHPi5TrU1?= =?us-ascii?Q?CIL/39jJji0qBQieGGt6uIP4/rLQ7R5fLBIPn/G2HYbI2R9ExGawRXS2Azux?= =?us-ascii?Q?NIJNKNLcvI4vjEoWLgknCxZEgcMPwkoxZUCEnXNgvwOcAPaTauoZEqoahA0G?= =?us-ascii?Q?auzvCJTlrmGNVK/6gdRs5YWkL6kkmBlVlLwJfRYdIagZ2b2Q6npAYWdUPgeD?= =?us-ascii?Q?QF9ZMpDhk3hmyw+r5I39/4OF+sp/uuZrKVvoXMHQMAjZcjpR26r+KObyIuH9?= =?us-ascii?Q?nsZL4ZTv49DtMnHl8HVoaJDjXFS1YcPvUgi4cgf7sQcyetIWJLC9n5INknRf?= =?us-ascii?Q?RCfQrtD6CiEnB6eb6O1nn9hHbL92mvLoQDDoTHx4jn54nxX0CRbWwCHNiIcs?= =?us-ascii?Q?WRPY8cc4N5KHmslZ62TMEoee6wKVPx//0bnkbroBdOaY610Rw1rXRemGlfOU?= =?us-ascii?Q?xIPRe/q+GrTyzHKgvft20bqjBe97zFqdV/slbM6yXsRSFqx8zVT/w3VANwz5?= =?us-ascii?Q?5uQnDijn0hAncToSrIXpPfVQcw+A9fv28c45npva9eGrNYVg6oP3EpeDz8OW?= =?us-ascii?Q?tnqFjIJdr+3gHsn8YYNDjbAO0I63r+VORj+FZvckzQa1njSmrcZZ7/r9K/pv?= =?us-ascii?Q?B2j4xizZ5ztQYNcBfsl+rhJ1mShiZrHaNAHeWO07SGL2iB7RAUm40Ly0iLJm?= =?us-ascii?Q?1NL2HRi6i8A9qOdFd/2uIMPKXVfBDJ8uhknoGVFuKR43sQy/snm3yIcF5ryP?= =?us-ascii?Q?1MlTksV+TMwoOHbXHvIB6IHOlhAKqieNGZ89etx8naGyLB/Z0bFNSP8jQhcA?= =?us-ascii?Q?wCB3C86E7zyACWCCH/p4FmCjZX1IkcQpfLOYogLNC/+t6+s3a6U2ozXPpcgE?= =?us-ascii?Q?aj8Jj5CeSIfxn6CFInZ3dxDOs4Bj0oqy5Et5+TOcOgDYzdp5N/Oi3N/El1wD?= =?us-ascii?Q?O1kTS/YONWbGSsFH5/az//P+xJ9KnJeRBZjBj7BNS2Z35aQbg9k7cWKcrEWf?= =?us-ascii?Q?bFU37YpM5dSDKF9r0h/RkOJP2gQ4Y84T6Jz22l2jMe+0P2ySvhX+1Tmq5hP6?= =?us-ascii?Q?0vSJG9IMH0razt9IDntDkL0cxXhk/IbjMeDEIp0zVkKDcYOw1+XVXEPyUhDc?= =?us-ascii?Q?tlLiBVDpu5OuTVbCdOQgz5nrdec6PtuQn7MZklsqaZz7C/sAq9UX6Oojr79a?= =?us-ascii?Q?XE3Jz4PXzf00Iy8h1UcNUi0yAnL/5hIAfShfS/xah4SWqhP3r5SSAy7mTYwU?= =?us-ascii?Q?nS+hMN4dK0CaDmWMgAl6EkcrJ+OkKouHH9tL?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2025 19:24:28.7187 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 544175a4-4f19-454a-7655-08dd88e5cad9 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000023D6.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPF5E0E7945E From: Nicola Vetrini __inline and __inline__ are already handled by ECLAIR but C-language-toolchain.rst doesn't reflect that. Update the doc. No functional change. Signed-off-by: Nicola Vetrini Signed-off-by: Stefano Stabellini --- docs/misra/C-language-toolchain.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/misra/C-language-toolchain.rst b/docs/misra/C-language-toolchain.rst index 5ddfe7bdbe..3a1ce651d7 100644 --- a/docs/misra/C-language-toolchain.rst +++ b/docs/misra/C-language-toolchain.rst @@ -86,6 +86,8 @@ The table columns are as follows: see Sections "6.48 Alternate Keywords" and "6.47.2.1 Volatile" of GCC_MANUAL. __const__: see Section "6.48 Alternate Keywords" of GCC_MANUAL. + __inline, __inline__: + see Section "6.48 Alternate Keywords" of GCC_MANUAL. typeof, __typeof__: see Section "6.7 Referring to a Type with typeof" of GCC_MANUAL. __alignof__, __alignof: -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu May 01 19:27:58 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 19:27:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974280.1362172 (Exim 4.92) (envelope-from ) id 1uAZZd-00033l-HZ; Thu, 01 May 2025 19:27:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974280.1362172; Thu, 01 May 2025 19: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 1uAZZd-00033e-Ez; Thu, 01 May 2025 19:27:57 +0000 Received: by outflank-mailman (input) for mailman id 974280; Thu, 01 May 2025 19:27:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAZZc-00033Y-JN for xen-devel@lists.xenproject.org; Thu, 01 May 2025 19:27:56 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5f11c30d-26c2-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 21:27:51 +0200 (CEST) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-43edecbfb46so6284505e9.0 for ; Thu, 01 May 2025 12:27:51 -0700 (PDT) Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-441b8a3156asm21079815e9.38.2025.05.01.12.27.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 May 2025 12:27: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" X-Inumbo-ID: 5f11c30d-26c2-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1746127670; x=1746732470; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=k/K5CHS4PFRvrbulwFYhzRcaFPzKuSUn1ebv5iLnyZE=; b=dALH6LH0gYT3AGlKKj8eYDjFM9sTwZYpWQY503eJnbu5P2naOchc/mV7/Dcs3uWYzT CJuP6SHj32E1/oZxOBHoAYT2ZZmGmX84akwdTYP5dmB4XimxX2dj5gh/SRf6yT4b3Lzg xzvNPsZjoxtLBjmdIoLW3MNTfOPc4ajSz+ZTM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746127670; x=1746732470; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=k/K5CHS4PFRvrbulwFYhzRcaFPzKuSUn1ebv5iLnyZE=; b=rDBj2h7XVCH1OX5oHF5/RvEgk6FEEW+Z0hQSNiMgzERKr9kd9yMw1zJsbuU6Qo6c5A 0tMEAkDvDRlMDQdLIDV0XfOZCI99d8tfXbScgHXxnwrbf3/OMSiDwqvwQ84JoHB2lI25 aQ/5CcYDG+/Xjw7z/YyM49vfHiKCIbxlSEOs6zuIN1rFBeTyjdFOTF7rshiARwyPP8N6 kj3JRapvk+JLRikrFEuU0ZddCwV4f0kuvw2kFFTwFuh4CtFiywfhRRo7ek0c1uyX6j0x KysGTgiWadZ5sP/DbKcd70hp7uiQptTo9TYn6qzveuU2TKzCpcuE3Zlp+atPwKVIZPm9 iiCA== X-Forwarded-Encrypted: i=1; AJvYcCUq5FS8B7uB1la+d1jswc7P2RlotLfBgMXY1xZiMN6sbyppAkdxWblASfL/IC0qm5AvcMZr1Lv1llk=@lists.xenproject.org X-Gm-Message-State: AOJu0YxHZvIu8O5y61/+/zkuhXqg02hP6oSEaD/xofYnWnnaAYz21OcJ gTxa/uCz1y1cZTEWo7xhNK9DkniLLQu2xJWheKio0bdn76pQq/XFYJ+D4g6Wgxw= X-Gm-Gg: ASbGncu2nE65bhBFbZs/YmfIryTYvJXhOtiTKrZTG8wgg0y8jBYR1WB9XuPSymFMIEk 2AWjNwIxuSN2SCpNxdkdtfElkLL8WxDOO4yAZnyFD6ZyEj4196u4YDWI/X5ihLOh5brU/O92Fxn V8Oq+4jCOBj4e0wWrAZ8hBFI3IRGSkXGijoOTiYEVQndGn1DaHWRIuNMzVyGlwaGWEPiJJXCkC5 mODFVV8p+aRns3v1X8732C76/euNzVS60DCJceN+deel3WiOV7Wyw+Auzu2yvXLHH4lTVobHXZh bjsLUtOCBX+BkDlBbzC8rqHj2sgAKboTK9NKlFkVBdZLcYzRRv4E79787o1u3Kkt1ww4k1tJ8L2 n5oAv0w== X-Google-Smtp-Source: AGHT+IGHAKP3nQ76sM2ePPPgnjkPnkWWdBgaSJ+PafHGuFma8BBMr3jMXTdMNsCvB/23K5uDOcJpTw== X-Received: by 2002:a05:600c:8289:b0:43c:f629:66f4 with SMTP id 5b1f17b1804b1-441bbe2677amr1034415e9.0.1746127670514; Thu, 01 May 2025 12:27:50 -0700 (PDT) Message-ID: <49485e48-827b-450c-9d19-2615d012a576@citrix.com> Date: Thu, 1 May 2025 20:27:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] misra: update list of GCC extensions used by Xen To: Stefano Stabellini , xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, nicola.vetrini@bugseng.com, michal.orzel@amd.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com References: <20250501192424.197012-1-stefano.stabellini@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: <20250501192424.197012-1-stefano.stabellini@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01/05/2025 8:24 pm, Stefano Stabellini wrote: > From: Nicola Vetrini > > __inline and __inline__ are already handled by ECLAIR but > C-language-toolchain.rst doesn't reflect that. Update the doc. > > No functional change. > > Signed-off-by: Nicola Vetrini > Signed-off-by: Stefano Stabellini Acked-by: Andrew Cooper Thanks, I do think this is the better way around to do things. From xen-devel-bounces@lists.xenproject.org Thu May 01 19:31:15 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 19:31:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974292.1362183 (Exim 4.92) (envelope-from ) id 1uAZcl-0004o6-0g; Thu, 01 May 2025 19:31:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974292.1362183; Thu, 01 May 2025 19:31:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAZck-0004nz-SV; Thu, 01 May 2025 19:31:10 +0000 Received: by outflank-mailman (input) for mailman id 974292; Thu, 01 May 2025 19:31:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAZcj-0004nt-V8 for xen-devel@lists.xenproject.org; Thu, 01 May 2025 19:31:10 +0000 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [2607:f8b0:4864:20::b29]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d4ac9f2c-26c2-11f0-9eb4-5ba50f476ded; Thu, 01 May 2025 21:31:08 +0200 (CEST) Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e733e25bfc7so1201575276.3 for ; Thu, 01 May 2025 12:31:08 -0700 (PDT) Received: from [10.138.7.94] ([45.134.140.51]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e755e7d93dfsm280107276.48.2025.05.01.12.31.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 May 2025 12:31:06 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d4ac9f2c-26c2-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746127867; x=1746732667; darn=lists.xenproject.org; h=in-reply-to:autocrypt:from:content-language:references:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=Po2xjJ8plZ+RKKgAdAkXLkKvvkvYSi96/s/0QmmMp8o=; b=AEkZFpm1wM6ha9jkwaCAa3Mh0fZV/KpzFZeWrpUEu5OytAdnEckkHn0i/omX/1NOx7 2zlcjiTnbYZCsWT/4lM4aDBSDvxwez9yFKHgqTmg863S5XTFY7IRkV0VUg5hmuAXhzEt f+97/mVFw+y0bddoya0gPI/kYqYZ7at1oOrNHP1kfSKIkkNxSkbPg7v7MljlxvM/NCgo BA4c7WlYxIIewEVe9m4oJjVP6wRPIbiEq/CaupI1SS9TPKUimZDUntHlQ6I1BRpounyp sAg7bR+aqm539dBEPTjLHWR7q71hhYHTHyobJ3WgnYquEYX4maAq85zFuZ+dUzMZmcdB hRNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746127867; x=1746732667; h=in-reply-to:autocrypt:from:content-language:references:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Po2xjJ8plZ+RKKgAdAkXLkKvvkvYSi96/s/0QmmMp8o=; b=WstYTxuamJQWz5nXvVlWNxnOyJR515PpZLX9vRh2yJffGa3eQDjIFuhpuDEIhFsw1L rKD9nWPY6y6ieM3vwohjseUsLtMgOLVpArR+4W5+ks2+JzE4x1ImcRWwg0IR7duPfT3G cqKESPyjrysiCWP15o7qAJt4lfT1QUCgNEGLZn4umg8u9/3bnerUl4LpFzG0ihkgrNce t0Xupw+eTHvgiYkDdxLALYiH0cO7lUkc7lRgeWfXvhdpCBoPx3QajUKxCgt24twzBEXD p8NR5JCi5ANuEVTKK3PrMIU7URvILWyGU1wz/6+iGD35Koj7gbE3HtM3F5Ta+bZJvsnk msBw== X-Gm-Message-State: AOJu0Yy6DD11d/pTJIxcHawyWhrte9jpBmLWHaFf1Ad2sXm6s3inGPbW Ges1pajxMYLPSCJtbNDkkGvPpY9S82byMfLXlmYI7e5fPqrsWIf1MRxEiw== X-Gm-Gg: ASbGncuWEXmiHV6HBH1BZugcnFugbj8DtppwS1N6MTw0x/OM9ER/8mjM4SAD6Vq17/V 2A0H5KxHWpLPVmM4Dg44Bx4972jyNYoERaj3FuGGxPlrbXDXuQKR+7wv4GskMWXFyUX4KN1mucT Ql66qnDaELAZNhBFqH6RQPg77zyOjNZp8aCAyBxTofVdDknvwxmtDBYVz6GPGeZbTDcKH9NyFGt bLdlFGa7B0Wfe+jjnCtF4ef7I+8rQuH0Ram/GIab5gNBVEsK/aOzdyF2LG+RhFbafHAfrXbUM0B Cn5rOshVZWOB7dQESdoNNkqLrUwydnfLFTOqiL6Ja+BZ X-Google-Smtp-Source: AGHT+IGsUGi+ZpF0BXlksBfQa9OVdkQCdgVeRp/RTe71calKQ5DBxFSXe8pKBQN1H+xUe4bfeN2K9Q== X-Received: by 2002:a05:6902:84a:b0:e72:bb4d:7cf9 with SMTP id 3f1490d57ef6-e7565627262mr380481276.34.1746127867398; Thu, 01 May 2025 12:31:07 -0700 (PDT) Message-ID: <0e69cc75-67af-4905-b736-8b58f2ac996c@gmail.com> Date: Thu, 1 May 2025 15:31:36 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] sbat: Add SBAT section to the xen binary To: xen-devel@lists.xenproject.org References: <20250501104925.228351-1-gerald.elder-vass@cloud.com> Content-Language: en-US From: Demi Marie Obenour Autocrypt: addr=demiobenour@gmail.com; keydata= xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+ VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/ 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E +MYSfkEjBz0E8CLOcAw7JIwAaeBT In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------DrtLaz9jZhw2ig09C5y18fS2" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------DrtLaz9jZhw2ig09C5y18fS2 Content-Type: multipart/mixed; boundary="------------8CjajPHZmPBVrJ8n8XpMBqGB"; protected-headers="v1" From: Demi Marie Obenour To: xen-devel@lists.xenproject.org Message-ID: <0e69cc75-67af-4905-b736-8b58f2ac996c@gmail.com> Subject: Re: [XEN PATCH] sbat: Add SBAT section to the xen binary References: <20250501104925.228351-1-gerald.elder-vass@cloud.com> In-Reply-To: --------------8CjajPHZmPBVrJ8n8XpMBqGB Content-Type: multipart/mixed; boundary="------------7dIpI0it2SLb9ZlA7EZ4l7JA" --------------7dIpI0it2SLb9ZlA7EZ4l7JA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/1/25 7:34 AM, Andrew Cooper wrote: > On 01/05/2025 11:49 am, Gerald Elder-Vass wrote: >> The SBAT section provides a way for the binary to declare a generation= >> id for its upstream source and any vendor changes applied. A compatibl= e >> loader can then revoke vulnerable binaries by generation, using the >> binary's declared generation id(s) to determine if it is safe to load.= >> >> More information about SBAT is available here: >> https://github.com/rhboot/shim/blob/main/SBAT.md >> >> Vendors should append a custom line onto sbat.csv(.in) with their vend= or >> specific sbat data. >> >> Populate the SBAT section in the Xen binary by using the information >> in xen/arch/x86/sbat.csv.in >> >> Signed-off-by: Gerald Elder-Vass >> Signed-off-by: Frediano Ziglio >> Tested-by: Gerald Elder-Vass >=20 > Thankyou for starting to post these patches. >=20 > The commit message needs that SBAT is a revocation scheme for UEFI > SecureBoot, and mandatory now if you want to get signed by Microsoft.=C2= =A0 > This wants to be the first sentence, IMO. >=20 > That in turn also explains why it's in the EFI binary only, and > discarded from the ELF binary. >=20 >> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile >> index d902fb7accd9..6db7475c2c23 100644 >> --- a/xen/arch/x86/Makefile >> +++ b/xen/arch/x86/Makefile >> @@ -74,6 +74,7 @@ obj-$(CONFIG_TBOOT) +=3D tboot.o >> obj-y +=3D hpet.o >> obj-y +=3D vm_event.o >> obj-y +=3D xstate.o >> +obj-y +=3D sbat_data.o >=20 > These should be sorted by file name (although hpet.o is clearly out of > order here). >=20 > Where possible, please use dash rather than underscore in filenames, > although in this case I'd shorten it to just sbat.o and bypass that pro= blem. >=20 >> =20 >> ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y) >> obj-y +=3D domctl.o >> @@ -277,6 +278,12 @@ $(obj)/efi.lds: AFLAGS-y +=3D -DEFI >> $(obj)/xen.lds $(obj)/efi.lds: $(src)/xen.lds.S FORCE >> $(call if_changed_dep,cpp_lds_S) >> =20 >> +$(obj)/sbat.csv: $(src)/sbat.csv.in >> + sed "s/@@VERSION@@/${XEN_FULLVERSION}/" $< > $@ >> + >> +$(obj)/sbat_data.o: $(obj)/sbat.csv >> + $(OBJCOPY) -I binary -O elf64-x86-64 --rename-section .data=3D.sbat,= readonly,data,contents $< $@ >> + >> clean-files :=3D \ >> include/asm/asm-macros.* \ >> $(objtree)/.xen-syms.[0-9]* \ >> diff --git a/xen/arch/x86/sbat.csv.in b/xen/arch/x86/sbat.csv.in >> new file mode 100644 >> index 000000000000..7cdc33dbd998 >> --- /dev/null >> +++ b/xen/arch/x86/sbat.csv.in >> @@ -0,0 +1,2 @@ >> +sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/S= BAT.md >> +xen,1,Linux Foundation,xen,@@VERSION@@,https://xenproject.org/ >=20 > I know this is what the SBAT spec says to do, but it's unworkable. >=20 > Upstream Xen cannot state or maintain a global generation ID on behalf > of it's downstreams.=C2=A0 This is true in general, not just for Xen. >=20 > For us (XenServer), this needs to be a line starting xen.xenserver, > because we (and only we) know how our Xen is built and configured.=C2=A0= > Every other downstream will need to do the same. >=20 > So, either we want just the SBAT line an nothing else, or we want some > kind of "to be filled in by the OSV" info, to make it clear that people= > need to alter it. >=20 > When UEFI SecureBoot becomes security supported, the security team > probably wants to note in XSAs whether the issue constitutes a breach o= f > UEFI-SB, and remind downstreams to bump their generation IDs. What about having both? One of the goals of SBAT is to keep the size of revocations under control= =2E That requires as many downstreams as possible to share an SBAT section en= try so that a single revocation can be used for all of them. If everyone use= s a different SBAT entry, does SBAT provide any functionality beyond meetin= g Microsoft requirements? --=20 Sincerely, Demi Marie Obenour (she/her/hers) --------------7dIpI0it2SLb9ZlA7EZ4l7JA Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/ UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r 6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc /9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4 BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf /5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R /4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ 7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+ AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ 5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41 ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd 8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk /Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH 0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog 2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0 Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9 uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj 6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK 9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64 GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3 J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb 49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6 +3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6 synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8 N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb /Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r 8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D =3Dx94R -----END PGP PUBLIC KEY BLOCK----- --------------7dIpI0it2SLb9ZlA7EZ4l7JA-- --------------8CjajPHZmPBVrJ8n8XpMBqGB-- --------------DrtLaz9jZhw2ig09C5y18fS2 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgTzCIACgkQszaHOrMp 8lM9KA//RHBpTqN0TfmpM9VXcA36TgzCjDsN5eCjZ1uUeRJ9Xs1FZdjH78hfR4TD U5WxV50X2BMPQhyffkJPjZdqo336HD8HOFRHSBMdGmpb7nvOVQS7p0huqRUDOHfp K5FisVANdGIAEycdcEr2Dykj/Hy/E8HTdHiaEzuxfgtC8GPEKZi7+4OXlVul4Hr0 kqDCPW44GbAke8IICEXGOwLaIOPqD5D64F48nHhygHtM9qgqEEycOAWlhb4I/qYi adY8vA9rEelpSl7In+x6UniamSmICNbXRxL9nkq67yEtdlgzawa6l6fFlzrTxqV7 eTVgmqj+XEz1vrYrXggaOd8t/IIb943IHIi3R7vFaoM0vXdtz57IsQW88mC0k+C4 r2q6kEfQ3W9pMqJ+85XnU8Ft2ctumoHvT7LMnjyRUKyhiShVTmW+2akseB5PadRT bxTl5VRn584uVkCMM2fkSsazc5EoGBvbHBaZ8CAaBMnrdiRxcThSsi5oLJAwm8FT x5UYWUE3+KSeDy9ycdUVf2IVfr10QY7tKqQN1tTR0uAVlBSpae5fWpcu9dGg+7EU 8AqxPpSHw+QAJlG5ZCySyKlPOBXzHLKYXSfEdJYGU03mqih6FSYxv7UUpx8725fU Rcn7kw7psHUH4h0Pib5NQMdZv3NEwjBvs8xyxsuBs9hPRyZ5Iak= =kYvv -----END PGP SIGNATURE----- --------------DrtLaz9jZhw2ig09C5y18fS2-- From xen-devel-bounces@lists.xenproject.org Thu May 01 19:42:26 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 19:42:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974306.1362197 (Exim 4.92) (envelope-from ) id 1uAZnX-0006mF-Ve; Thu, 01 May 2025 19:42:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974306.1362197; Thu, 01 May 2025 19: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 1uAZnX-0006m8-SX; Thu, 01 May 2025 19:42:19 +0000 Received: by outflank-mailman (input) for mailman id 974306; Thu, 01 May 2025 19:42:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAZnW-0006m2-4S for xen-devel@lists.xenproject.org; Thu, 01 May 2025 19:42:18 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [2604:1380:45d1:ec00::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5e88e3b9-26c4-11f0-9ffb-bf95429c2676; Thu, 01 May 2025 21:42:10 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id C9AB7A4BDB8; Thu, 1 May 2025 19:36:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E837AC4CEE3; Thu, 1 May 2025 19:42: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" X-Inumbo-ID: 5e88e3b9-26c4-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746128528; bh=r+0nLVwiqjY7ZeI8RO7111m8zQPYbIfbRqC5qozYZPc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=FqoNy5zo6HYnIHJdfMU7bISgTj+xWVFfYsx82Z4lxHFXePnHtHzHt3O8uQi8Qvgw/ iDARlAceV7d6UP8wvAztsPeKmjiwIj3nPvCC9A9nrFs+9dzThT4y3mAT/gatPx33BQ IbCJTUksKtrjXZea8/+O+cPIPrqN0nUHT82EzearwIctZNUjFnouFiPWa8oKmiFZJD i7l1BpgUNn4QGFmod8hnMRMVObVmGuGn2p6K8MJwcg+CCTlOgrRZC3RbIwwS0k4dbi t0xuRjj3SzzGGhh6Wg1Tvn8FrQDGvTZlEpVIQNFQMje+D19qc9szmGarSYUaX+KmDv iQGGhWzIl0qdA== Date: Thu, 1 May 2025 12:42:05 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Andrew Cooper cc: Xen-devel , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Shawn Anastasio Subject: Re: [PATCH v5 1/3] xen/mm: Introduce mm-types.h In-Reply-To: <20250425112415.245585-2-andrew.cooper3@citrix.com> Message-ID: References: <20250425112415.245585-1-andrew.cooper3@citrix.com> <20250425112415.245585-2-andrew.cooper3@citrix.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-338710888-1746128528=:3879245" 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-338710888-1746128528=:3879245 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Fri, 25 Apr 2025, Andrew Cooper wrote: > The type used for pagetable attributes/permissions is currently unsigned int, > but needs to become architecture dependent as PPC needs unsigned long. > > Introduce mm-types.h to house pte_attr_t. > > Given the new toolchain baseline, we can use __has_include() now to remove the > need for boilerplate on most architectures. > > Signed-off-by: Andrew Cooper Reviewed-by: Stefano Stabellini > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Oleksii Kurochko > CC: Shawn Anastasio > > __has_include() was one of the justifications for the new toolchain baseline, > and is included in https://gitlab.com/xen-project/xen/-/issues/201 > --- > xen/include/xen/mm-types.h | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > create mode 100644 xen/include/xen/mm-types.h > > diff --git a/xen/include/xen/mm-types.h b/xen/include/xen/mm-types.h > new file mode 100644 > index 000000000000..19f692e9aaa4 > --- /dev/null > +++ b/xen/include/xen/mm-types.h > @@ -0,0 +1,19 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#ifndef XEN_MM_TYPES_H > +#define XEN_MM_TYPES_H > + > +/* > + * Types used to abstract away architecture-specific details in the memory > + * management code. > + * > + * Architectures need only provide their own asm/mm-types.h if they want to > + * override the defaults given here. > + */ > +#if __has_include() > +# include > +#else /* !__has_include() */ > + > +typedef unsigned int pte_attr_t; > + > +#endif /* !__has_include() */ > +#endif /* XEN_MM_TYPES_H */ > -- > 2.39.5 > --8323329-338710888-1746128528=:3879245-- From xen-devel-bounces@lists.xenproject.org Thu May 01 19:43:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 19:43:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974320.1362207 (Exim 4.92) (envelope-from ) id 1uAZoE-0007JV-9K; Thu, 01 May 2025 19:43:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974320.1362207; Thu, 01 May 2025 19: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 1uAZoE-0007JO-6R; Thu, 01 May 2025 19:43:02 +0000 Received: by outflank-mailman (input) for mailman id 974320; Thu, 01 May 2025 19:43:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAZoC-00074N-OX for xen-devel@lists.xenproject.org; Thu, 01 May 2025 19:43:00 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7c0ae1e6-26c4-11f0-9eb4-5ba50f476ded; Thu, 01 May 2025 21:42:59 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 5AF475C490A; Thu, 1 May 2025 19:40:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5CAAC4CEE3; Thu, 1 May 2025 19:42: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" X-Inumbo-ID: 7c0ae1e6-26c4-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746128577; bh=8568cvhRutRjyDbgpnZKxEmTiYe4k4dnc66E6qBl1V8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ZUND00Kf7gJdZASDlG66UKU+/IJBFo2Vra34dDbGgfXPs6mL82pxr2BZ8yl3pHePs NN8N5Xwv+rDhC7lNq4r53Y5y56a+g88vG7ZPzmshhvB4EASmwSR7UKpFmf62DEJoHS ALrza2GW6Ztfr2ge8nAPCXIQIKE/toBW7qy3zELJ0RvWNhB5D+H6TK6pmSOfTmayNV lUPIdPuczjYqF6763oBNNF1Jr/sZNjpyyzXdHvsJJzw1rcQMTF1G3RGvizejdFxz/P D30uODFbc3IziXcRafAVPUuwR5PZ/SIO1TDUqN5XXrzwuUnq0ny0mDvLgQG9xyV//J czh73vIGlpj1A== Date: Thu, 1 May 2025 12:42:54 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Andrew Cooper cc: Xen-devel , Shawn Anastasio , Oleksii Kurochko , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v5 2/3] xen/mm: Switch some APIs over to pte_attr_t In-Reply-To: <20250425112415.245585-3-andrew.cooper3@citrix.com> Message-ID: References: <20250425112415.245585-1-andrew.cooper3@citrix.com> <20250425112415.245585-3-andrew.cooper3@citrix.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1450196449-1746128577=:3879245" 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-1450196449-1746128577=:3879245 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Fri, 25 Apr 2025, Andrew Cooper wrote: > From: Shawn Anastasio > > Several APIs take an architecture-dependent set of flags in an unsigned int, > but this needs to be a wider type to support PPC. > > The new type pte_attr_t has been introduced for this purpose, so switch to it > in map_pages_to_xen(), __vmap() and modify_xen_mappings{,_lite}(). > > No functional change. > > Suggested-by: Andrew Cooper > Signed-off-by: Shawn Anastasio > Signed-off-by: Andrew Cooper > Reviewed-by: Oleksii Kurochko Reviewed-by: Stefano Stabellini > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Oleksii Kurochko > CC: Shawn Anastasio > --- > xen/arch/arm/mmu/pt.c | 4 ++-- > xen/arch/ppc/mm-radix.c | 2 +- > xen/arch/riscv/pt.c | 2 +- > xen/arch/x86/mm.c | 6 +++--- > xen/common/efi/boot.c | 4 ++-- > xen/common/vmap.c | 2 +- > xen/include/xen/mm.h | 7 ++++--- > xen/include/xen/vmap.h | 3 ++- > 8 files changed, 16 insertions(+), 14 deletions(-) > > diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c > index 11cb1c66dac8..4726e713efd3 100644 > --- a/xen/arch/arm/mmu/pt.c > +++ b/xen/arch/arm/mmu/pt.c > @@ -696,7 +696,7 @@ static int xen_pt_update(unsigned long virt, > int map_pages_to_xen(unsigned long virt, > mfn_t mfn, > unsigned long nr_mfns, > - unsigned int flags) > + pte_attr_t flags) > { > return xen_pt_update(virt, mfn, nr_mfns, flags); > } > @@ -714,7 +714,7 @@ int destroy_xen_mappings(unsigned long s, unsigned long e) > return xen_pt_update(s, INVALID_MFN, (e - s) >> PAGE_SHIFT, 0); > } > > -int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf) > +int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) > { > ASSERT(IS_ALIGNED(s, PAGE_SIZE)); > ASSERT(IS_ALIGNED(e, PAGE_SIZE)); > diff --git a/xen/arch/ppc/mm-radix.c b/xen/arch/ppc/mm-radix.c > index 9a00ae416af0..d5385ec9dd4b 100644 > --- a/xen/arch/ppc/mm-radix.c > +++ b/xen/arch/ppc/mm-radix.c > @@ -265,7 +265,7 @@ int destroy_xen_mappings(unsigned long s, unsigned long e) > int map_pages_to_xen(unsigned long virt, > mfn_t mfn, > unsigned long nr_mfns, > - unsigned int flags) > + pte_attr_t flags) > { > BUG_ON("unimplemented"); > } > diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c > index 857619d48df1..918b1b91abde 100644 > --- a/xen/arch/riscv/pt.c > +++ b/xen/arch/riscv/pt.c > @@ -504,7 +504,7 @@ static int pt_update(vaddr_t virt, mfn_t mfn, > int map_pages_to_xen(unsigned long virt, > mfn_t mfn, > unsigned long nr_mfns, > - unsigned int flags) > + pte_attr_t flags) > { > /* > * Ensure that flags has PTE_VALID bit as map_pages_to_xen() is supposed > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index 1cf236516789..0e6c766be4aa 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -5442,7 +5442,7 @@ int map_pages_to_xen( > unsigned long virt, > mfn_t mfn, > unsigned long nr_mfns, > - unsigned int flags) > + pte_attr_t flags) > { > bool locking = system_state > SYS_STATE_boot; > l3_pgentry_t *pl3e = NULL, ol3e; > @@ -5860,7 +5860,7 @@ 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. > */ > -int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf) > +int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf) > { > bool locking = system_state > SYS_STATE_boot; > l3_pgentry_t *pl3e = NULL; > @@ -6156,7 +6156,7 @@ int destroy_xen_mappings(unsigned long s, unsigned long e) > * the non-inclusive boundary will be updated. > */ > void init_or_livepatch modify_xen_mappings_lite( > - unsigned long s, unsigned long e, unsigned int nf) > + unsigned long s, unsigned long e, pte_attr_t nf) > { > unsigned long v = s, fm, flags; > > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c > index 143b5681ba92..e39fbc3529c4 100644 > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -1676,7 +1676,7 @@ void __init efi_init_memory(void) > struct rt_extra { > struct rt_extra *next; > unsigned long smfn, emfn; > - unsigned int prot; > + pte_attr_t prot; > } *extra, *extra_head = NULL; > > free_ebmalloc_unused_mem(); > @@ -1691,7 +1691,7 @@ void __init efi_init_memory(void) > EFI_MEMORY_DESCRIPTOR *desc = efi_memmap + i; > u64 len = desc->NumberOfPages << EFI_PAGE_SHIFT; > unsigned long smfn, emfn; > - unsigned int prot = PAGE_HYPERVISOR_RWX; > + pte_attr_t prot = PAGE_HYPERVISOR_RWX; > paddr_t mem_base; > unsigned long mem_npages; > > diff --git a/xen/common/vmap.c b/xen/common/vmap.c > index 47225fecc067..d6991421f3f7 100644 > --- a/xen/common/vmap.c > +++ b/xen/common/vmap.c > @@ -222,7 +222,7 @@ static void vm_free(const void *va) > } > > void *__vmap(const mfn_t *mfn, unsigned int granularity, > - unsigned int nr, unsigned int align, unsigned int flags, > + unsigned int nr, unsigned int align, pte_attr_t flags, > enum vmap_region type) > { > void *va = vm_alloc(nr * granularity, align, type); > diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h > index ae1c48a61545..e89942b87d1e 100644 > --- a/xen/include/xen/mm.h > +++ b/xen/include/xen/mm.h > @@ -64,6 +64,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -113,11 +114,11 @@ int map_pages_to_xen( > unsigned long virt, > mfn_t mfn, > unsigned long nr_mfns, > - unsigned int flags); > + pte_attr_t flags); > /* Alter the permissions of a range of Xen virtual address space. */ > -int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf); > +int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf); > void modify_xen_mappings_lite(unsigned long s, unsigned long e, > - unsigned int nf); > + pte_attr_t nf); > int destroy_xen_mappings(unsigned long s, unsigned long e); > /* Retrieve the MFN mapped by VA in Xen virtual address space. */ > mfn_t xen_map_to_mfn(unsigned long va); > diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h > index 26c831757a11..327a2597826d 100644 > --- a/xen/include/xen/vmap.h > +++ b/xen/include/xen/vmap.h > @@ -9,6 +9,7 @@ > #define __XEN_VMAP_H__ > > #include > +#include > #include > > /* Identifiers for the linear ranges tracked by vmap */ > @@ -57,7 +58,7 @@ void vm_init_type(enum vmap_region type, void *start, void *end); > * @return Pointer to the mapped area on success; NULL otherwise. > */ > void *__vmap(const mfn_t *mfn, unsigned int granularity, unsigned int nr, > - unsigned int align, unsigned int flags, enum vmap_region type); > + unsigned int align, pte_attr_t flags, enum vmap_region type); > > /* > * Map an array of pages contiguously into the VMAP_DEFAULT vmap region > -- > 2.39.5 > --8323329-1450196449-1746128577=:3879245-- From xen-devel-bounces@lists.xenproject.org Thu May 01 23:08:54 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 23:08:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974344.1362221 (Exim 4.92) (envelope-from ) id 1uAd1J-0007Wa-8Q; Thu, 01 May 2025 23:08:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974344.1362221; Thu, 01 May 2025 23:08: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 1uAd1J-0007WT-4n; Thu, 01 May 2025 23:08:45 +0000 Received: by outflank-mailman (input) for mailman id 974344; Thu, 01 May 2025 23:08:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAd1I-0007WN-0q for xen-devel@lists.xenproject.org; Thu, 01 May 2025 23:08:44 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3691a278-26e1-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 01:08:37 +0200 (CEST) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4394a0c65fcso12914065e9.1 for ; Thu, 01 May 2025 16:08:37 -0700 (PDT) Received: from localhost.localdomain (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a099ae0c48sm466533f8f.8.2025.05.01.16.08.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 May 2025 16:08: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" X-Inumbo-ID: 3691a278-26e1-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1746140917; x=1746745717; 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; bh=IYljfMec41LNWU/JXV9Ofiirp0ccf7wpqklR3jPBOzQ=; b=Q4J/qg4gQTuIsA3Jm6tGrnsFpKokJI9Za8N8rtWh/T/AwDjolz8t0BfmvuYrVQQI4j jckCsMbfK1xHL6rr+dsVosVPAgVJ9fZy6l+FPo5cj4xV30Dshv16DXmRqod1/1rKScZ3 35fcLygza0xQCl1hDUsmBKnNP+Kz/W+PQqMSE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746140917; x=1746745717; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IYljfMec41LNWU/JXV9Ofiirp0ccf7wpqklR3jPBOzQ=; b=Qnqg6bLoa8SvRaX3Ky4MGIj4/8wUZLFgAN1ZwhQvU3Gn0XEUlZzGOMZVhGC0VTrptS 6YMTL8mbf1Nd6IbN21FAW1HRcDcq+6ug1oH12VLBCkXVNFHcCSysv+pwa0KKgCE8itIX hIvlr3e6vGj/AAjwy179zFTXOT9bGJAYIh+nuOXH4ZDgOP2UekCK4M+wi9dK+brHIY5k 8+pUuuQWmjBf1965D/tkxcDCSbstgVo17ReTcAWk/INk49jn4Yx6mQDfh6jrxQfiTLCd TP8s3OwFmyX4kKA/Vgnvjw/XUhckWEtNlm3B8zpULJHLvm486t11O3eRgkkohYsWRtdk P0EA== X-Gm-Message-State: AOJu0YxYK/tRcjv1V8x0HZHiEUv8bhtNSft0R1rAc11szZUhkaEZ2SWd gsW8qs4Qdathintv18u3EqM1dQ88FLSbceqn6vpDS3ZuTEMJb3zBr5PN4WBTl1J+7SvjzHvrAxl 0 X-Gm-Gg: ASbGnct18qBkHjxBqv9K7aXyQ/9gfZJC5isdjolPQSBhgMhFAmGAQszzjs8obNuSMyJ qtrbNjYAn1Nh8O95CCbneMu1AKHmpOTpZwQBeE2hM24pzBnOcgS4FGNgd/19pyEi4Ptpz+rsbz1 6+yRpjDMXKseDb/nhVdtEgp9fX89FXFoMiZ9VJripc8xTAa+kX5ddf4fjvYuasUe0M30O3L4olk EaARZbkwDzChTqv5zKioiXfx0UCBt3TRdpKRJ+MAr1JtYGqXVriLrLdASHMcCvDd/Xss4T0M+t4 hFnk6IaDov7ZXeXlrLpEf0L8ziZu2a1LlchOQSrBh0H4S1Fg1NIGWOJY5PDWi+WBC0rfv4jPlu6 3FmmNFRE8tadXsGenJFefDTea X-Google-Smtp-Source: AGHT+IG4miP4zSEd/AgAlb+nlwHm50Ty6QBb8XlvcUjFs92KdQrc7M2BbKNTGQoBn4jjwpx8IR8hZQ== X-Received: by 2002:a05:6000:400b:b0:3a0:8098:b6c with SMTP id ffacd0b85a97d-3a099ad7c13mr400038f8f.14.1746140916722; Thu, 01 May 2025 16:08:36 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86/vmx: Fix label name in vmwrite_safe() Date: Fri, 2 May 2025 00:08:34 +0100 Message-Id: <20250501230834.759523-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 This condition is called VMFail(valid) in the SDM. No functional change. Fixes: fc3db01db6fb ("x86/vmx: Rework VMX wrappers using `asm goto()`") Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné --- xen/arch/x86/include/asm/hvm/vmx/vmx.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h index cc8c53fab149..d85b52b9d522 100644 --- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h @@ -382,17 +382,17 @@ static inline enum vmx_insn_errno vmwrite_safe(unsigned long field, { asm goto ( "vmwrite %[value], %[field]\n\t" "jc %l[vmfail_invalid]\n\t" - "jz %l[vmfail_error]" + "jz %l[vmfail_valid]" : : [field] "r" (field), [value] "rm" (value) : - : vmfail_invalid, vmfail_error ); + : vmfail_invalid, vmfail_valid ); return VMX_INSN_SUCCEED; vmfail_invalid: return VMX_INSN_FAIL_INVALID; - vmfail_error: + vmfail_valid: return vmread(VM_INSTRUCTION_ERROR); } -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Thu May 01 23:30:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 May 2025 23:30:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974361.1362243 (Exim 4.92) (envelope-from ) id 1uAdMe-0003Dv-St; Thu, 01 May 2025 23:30:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974361.1362243; Thu, 01 May 2025 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 1uAdMe-0003Do-Pz; Thu, 01 May 2025 23:30:48 +0000 Received: by outflank-mailman (input) for mailman id 974361; Thu, 01 May 2025 23:30:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAdMd-00038L-7W for xen-devel@lists.xenproject.org; Thu, 01 May 2025 23:30:47 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4e36fd24-26e4-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 01:30:45 +0200 (CEST) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-3a064a3e143so599614f8f.3 for ; Thu, 01 May 2025 16:30:45 -0700 (PDT) Received: from localhost.localdomain (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a099ae3ccdsm505413f8f.38.2025.05.01.16.30.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 May 2025 16:30: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" X-Inumbo-ID: 4e36fd24-26e4-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1746142245; x=1746747045; 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; bh=c5OfGc/3T6HMOKWy88hLd0X6Kk9xY2Jd/gy57FPy4eI=; b=uwEbrnUy5DTNz8wOOdH0VTzKRG3F47GDH1/7aqeJpQ0Qd+oBlwEHhAXhUhuJfHvE8D Z0Vm5bIrQZDYhSb9yzDOUiKoAdlSLPoFrvjM+LJbYXvjGgUl2j0jidhw9xrV/6MC8mfx /iz2gxH1h6u4EiVXvHOB+Etu0qCyOHB8HsTpI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746142245; x=1746747045; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=c5OfGc/3T6HMOKWy88hLd0X6Kk9xY2Jd/gy57FPy4eI=; b=ij23kG9vlxyUlnV0wTcbVtSvmF3KUHxdL1EOaGztIoAe8mPOKl11j6vI9R7q148t4U Rfdb6VsxqnKxcJgz1be2rXDgsncBX3FIhFOA6apL3A44mksKxUzyBSw7E+MRgzaTtD1O JHcDtsH3Gvc9E/AyIv+OtQdfyTIm20x7nIk9Ao8j/nOWxs08cfdcqvccniXekAnVuz9Z Nc2FdVVMt8lCzTDMO6pLzLGcoHHQ6XGA2XeunYj2qBJ2ONx2NxWDLL0ID+/Ce2Lu6hiF QuLIfNOldDktx4gnA+OojPRf7mtEVzlqQ1HPP/bxknlZYBz0Nup7Iw1vupk3FS6l3AID leVA== X-Gm-Message-State: AOJu0Yysyc4CyvFTGjGdLTMFPQm6GlhAEdb/M7qtvM2Ody7RAK3Drogl KgUoxQMa3MGUewo8TsW/ulYFIupwrOvR+mKra80VwRQmvmdFOLCdtYzsIQcBk7tjst+QQdwMrbr E X-Gm-Gg: ASbGncvXEEJT40G65NVYZo1G/8xyhMcY+gWCsxFdv6tCv+2O4O4F43WqrOMV/flZKWx F3sYM4Ng4G3V6BfpNn7mEJ090ifw3NDU+E1VW2yETtMU2FwpQhzaU8wyIozyEyXcLmMaWAM3CwG wNYPKdk2TSw4bbNS+QivPlzVl+Sk99fqY+/7Dnp7C5M1rMMODo+3NPKOd+/QRl8GazNS36OZIYL ZlJovOU1FuExxiYrC0UyJp9Vx2JChZ8JIqIxBuYrs/zeVktksw8EFJe7oAbBK6jEHXrJ3Kbn/H6 Ap2nW/sPi7iKT3HS8snsv1tU+YHMPpBWL+O+F5S59n/g4mqZlG7nF0kcUmy4rxrXb8R6lURJceL H7Tjv9ThS3TJHgg== X-Google-Smtp-Source: AGHT+IHytsle15Rak7SjV3gyww/yzXX/7gR5jta2uqa0zVgSkuiFPrWarcr3D0HTqX5yyJdxJ6jMGg== X-Received: by 2002:a5d:64e6:0:b0:3a0:8c68:19b7 with SMTP id ffacd0b85a97d-3a099ad26a3mr424094f8f.3.1746142244697; Thu, 01 May 2025 16:30:44 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86/vpic: Improve bitops usage Date: Fri, 2 May 2025 00:30:42 +0100 Message-Id: <20250501233042.762295-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 * For vpic_get_priority(), introduce a common ror8() helper in plain C. One thing that I can't persuade the compiler to realise is that a non-zero value rotated is still non-zero, so use __builtin_clz() to help the optimiser out. * vpic_ioport_write() can be simplified to just for_each_set_bit(), which avoids spilling pending to the stack each loop iteration. Changing pending from unsigned int to uint8_t isn't even strictly necessary given the underlying types of vpic->isr and vpic->irr, but done so clarity. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné More detailed analysis: add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-53 (-53) Function old new delta vpic_get_highest_priority_irq 134 124 -10 vpic_intercept_pic_io 1525 1482 -43 One thing I can't seem to avoid is GCC zero extending the result of ror8() before passing it to BSF/TZCNT. Then again, that's very specific to uint8_t, and x86's preserving behaviour on byte writes. The space saving in vpic_get_highest_priority_irq(), which has vpic_get_priority() inlined twice, seems to come from better return-value handling. GCC is happy instruction scheduling over __builtin_ctz(), and I presume it also benefits from range analysis of the result. --- xen/arch/x86/hvm/vpic.c | 21 +++++++-------------- xen/include/xen/bitops.h | 6 ++++++ 2 files changed, 13 insertions(+), 14 deletions(-) diff --git a/xen/arch/x86/hvm/vpic.c b/xen/arch/x86/hvm/vpic.c index 22020322fbba..30ce367c082d 100644 --- a/xen/arch/x86/hvm/vpic.c +++ b/xen/arch/x86/hvm/vpic.c @@ -47,17 +47,16 @@ #define VPIC_PRIO_NONE 8 static int vpic_get_priority(struct hvm_hw_vpic *vpic, uint8_t mask) { - int prio; - ASSERT(vpic_is_locked(vpic)); if ( mask == 0 ) return VPIC_PRIO_NONE; - /* prio = ffs(mask ROR vpic->priority_add); */ - asm ( "ror %%cl,%b1 ; rep; bsf %1,%0" - : "=r" (prio) : "q" ((uint32_t)mask), "c" (vpic->priority_add) ); - return prio; + /* + * We use __builtin_ctz() rather than ffs() because the compiler can't + * reason that a nonzero mask rotated is still nonzero. + */ + return __builtin_ctz(ror8(mask, vpic->priority_add)); } /* Return the PIC's highest priority pending interrupt. Return -1 if none. */ @@ -196,7 +195,7 @@ static void vpic_ioport_write( { if ( val & 0x10 ) { - unsigned int pending = vpic->isr | (vpic->irr & ~vpic->elcr); + uint8_t pending = vpic->isr | (vpic->irr & ~vpic->elcr); /* ICW1 */ /* Clear edge-sensing logic. */ @@ -229,15 +228,9 @@ static void vpic_ioport_write( * been cleared from IRR or ISR, or else the dpci logic will get * out of sync with the state of the interrupt controller. */ - while ( pending ) - { - unsigned int pin = __scanbit(pending, 8); - - ASSERT(pin < 8); + for_each_set_bit ( pin, pending ) hvm_dpci_eoi(current->domain, hvm_isa_irq_to_gsi((addr >> 7) ? (pin | 8) : pin)); - __clear_bit(pin, &pending); - } return; } else if ( val & 0x08 ) diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h index 448b2d3e0937..a4d31ec02a7c 100644 --- a/xen/include/xen/bitops.h +++ b/xen/include/xen/bitops.h @@ -418,6 +418,12 @@ static inline uint32_t rol32(uint32_t word, unsigned int shift) return (word << shift) | (word >> (32 - shift)); } +/* ror8 - rotate an 8-bit value right */ +static inline uint8_t ror8(uint8_t value, unsigned int shift) +{ + return (value >> shift) | (value << (8 - shift)); +} + /* * ror32 - rotate a 32-bit value right * -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri May 02 00:01:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 00:01:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974377.1362265 (Exim 4.92) (envelope-from ) id 1uAdqL-0008R6-4W; Fri, 02 May 2025 00:01:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974377.1362265; Fri, 02 May 2025 00: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 1uAdqL-0008Qz-1S; Fri, 02 May 2025 00:01:29 +0000 Received: by outflank-mailman (input) for mailman id 974377; Fri, 02 May 2025 00:01:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAdqJ-0008Qt-2f for xen-devel@lists.xenproject.org; Fri, 02 May 2025 00:01:27 +0000 Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 955ccef9-26e8-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 02:01:24 +0200 (CEST) Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id 55EBA1380858; Thu, 1 May 2025 20:01:22 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Thu, 01 May 2025 20:01:22 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 1 May 2025 20:01:21 -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" X-Inumbo-ID: 955ccef9-26e8-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1746144082; x=1746230482; bh=Sryq4Gx8hf4xx/wbwXSC6RxO3c4ZAsYR6NIt+JLwuCU=; b= mb+g/ycFfsDat5z6tjYx9NBsNJIYpKL8nXTkd91ha968bzdGpC5N1ozrB+kNDDOg MUKGg+Aw/u5HnFO/woKhpx34EpBQUXHWftcyBp0lFoUFLTZIGAGOOCDgnAj7iqZk f1O0FSWub9QokxS98FHyTPIuWyqHfXwvAYPWmttK+71byKtdlgEJo15ztcMCHLuu F21C2htTFm999JCIavwUmd/RE+3K8XBXCWAqpk5kOTPC7YTzeblQu57H7Nbqc+mQ UWW25dvHQAG1FkCZOjtbjr2xjxAtzdYP0zQ4OBTuYFJGxdyuXqlWH66ptsznJHK2 k8fECMke8YpzMrPoaZwHHg== 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=fm3; t= 1746144082; x=1746230482; bh=Sryq4Gx8hf4xx/wbwXSC6RxO3c4ZAsYR6NI t+JLwuCU=; b=JcEl6etDL5eB60YdXKCFvxVw15BXIGYwVLMmrsdEHDTAvOh2My3 Cfk4LTpS33d9cy6VgpymXmf0JMl/4Z4YFvPCbbPz+tJlnW983DhUXktop8DcnrNC GQJjKChZPglEd0vo438Hqle80KNDabwbSBCp1KUaId00Og2YFN9IZIWcIO5ULNmJ erjICYL3/3V6Rov+IOZyTy3cej3SgSD10uEBzR00oXW2BNUVQXvYTdswKfLcg9hR 5fb4fF5UUCTofIctvH00F3DtuRrktYLE6MExKcQ5QxiPsrXzBaVtf90zVlOSWuej yZFwm4/tbh5hqSXvkAD0Dn2hOkOtcQJD3NA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvjedtleeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu ggftrfgrthhtvghrnhephfettdejhfehjeekgfdvudfhtdejlefghfehieeuteegveeitd dvgfetveekiefhnecuffhomhgrihhnpehophgvnhhsuhhsvgdrohhrghdpqhhusggvshdq ohhsrdhorhhgpdhgihhthhhusgdrtghomhdpkhgvrhhnvghlrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgrnhgurhihuhhksehgmhgrihhlrdgt ohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtohepgigvnh dquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohep jhhgrhhoshhssehsuhhsvgdrtghomh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Fri, 2 May 2025 02:01:18 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jason Andryuk Cc: Julien Grall , xen-devel , Juergen Gross Subject: Re: NULL pointer dereference in xenbus_thread->... Message-ID: References: <0f8c0e27-e60d-4e64-bc8a-6cb407c67ab2@xen.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="al3d5CqgWeK2TatU" Content-Disposition: inline In-Reply-To: --al3d5CqgWeK2TatU Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Fri, 2 May 2025 02:01:18 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jason Andryuk Cc: Julien Grall , xen-devel , Juergen Gross Subject: Re: NULL pointer dereference in xenbus_thread->... On Tue, Apr 29, 2025 at 08:59:45PM -0400, Jason Andryuk wrote: > Hi Marek, >=20 > On Wed, Apr 23, 2025 at 8:42=E2=80=AFAM Marek Marczykowski-G=C3=B3recki > wrote: > > > > On Sat, Jun 01, 2024 at 12:48:33AM +0200, Marek Marczykowski-G=C3=B3rec= ki wrote: > > > On Tue, Mar 26, 2024 at 11:00:50AM +0000, Julien Grall wrote: > > > > Hi Marek, > > > > > > > > +Juergen for visibility > > > > > > > > When sending a bug report, I would suggest to CC relevant people as > > > > otherwise it can get lost (not may people monitors Xen devel if the= y are not > > > > CCed). > > > > > > > > Cheers, > > > > > > > > On 25/03/2024 16:17, Marek Marczykowski-G=C3=B3recki wrote: > > > > > On Sun, Oct 22, 2023 at 04:14:30PM +0200, Marek Marczykowski-G=C3= =B3recki wrote: > > > > > > On Mon, Aug 28, 2023 at 11:50:36PM +0200, Marek Marczykowski-G= =C3=B3recki wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I've noticed in Qubes's CI failure like this: > > > > > > > > > > > > > > [ 871.271292] BUG: kernel NULL pointer dereference, address:= 0000000000000000 > > > > > > > [ 871.275290] #PF: supervisor read access in kernel mode > > > > > > > [ 871.277282] #PF: error_code(0x0000) - not-present page > > > > > > > [ 871.279182] PGD 106fdb067 P4D 106fdb067 PUD 106fdc067 PMD 0 > > > > > > > [ 871.281071] Oops: 0000 [#1] PREEMPT SMP NOPTI > > > > > > > [ 871.282698] CPU: 1 PID: 28 Comm: xenbus Not tainted 6.1.43= -1.qubes.fc37.x86_64 #1 > > > > > > > [ 871.285222] Hardware name: QEMU Standard PC (i440FX + PIIX= , 1996), BIOS rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014 > > > > > > > [ 871.288883] RIP: e030:__wake_up_common+0x4c/0x180 > > > > > > > [ 871.292838] Code: 24 0c 89 4c 24 08 4d 85 c9 74 0a 41 f6 0= 1 04 0f 85 a3 00 00 00 48 8b 43 08 4c 8d 40 e8 48 83 c3 08 49 8d 40 18 48 3= 9 c3 74 5b <49> 8b 40 18 31 ed 4c 8d 70 e8 45 8b 28 41 f6 c5 04 75 5f 49 8b= 40 > > > > > > > [ 871.299776] RSP: e02b:ffffc900400f7e10 EFLAGS: 00010082 > > > > > > > [ 871.301656] RAX: 0000000000000000 RBX: ffff88810541ce98 RC= X: 0000000000000000 > > > > > > > [ 871.304255] RDX: 0000000000000001 RSI: 0000000000000003 RD= I: ffff88810541ce90 > > > > > > > [ 871.306714] RBP: ffffc900400f0280 R08: ffffffffffffffe8 R0= 9: ffffc900400f7e68 > > > > > > > [ 871.309937] R10: 0000000000007ff0 R11: ffff888100ad3000 R1= 2: ffffc900400f7e68 > > > > > > > [ 871.312326] R13: 0000000000000000 R14: 0000000000000000 R1= 5: 0000000000000000 > > > > > > > [ 871.314647] FS: 0000000000000000(0000) GS:ffff88813ff0000= 0(0000) knlGS:0000000000000000 > > > > > > > [ 871.317677] CS: 10000e030 DS: 0000 ES: 0000 CR0: 00000000= 80050033 > > > > > > > [ 871.319644] CR2: 0000000000000000 CR3: 00000001067fe000 CR= 4: 0000000000040660 > > > > > > > [ 871.321973] Call Trace: > > > > > > > [ 871.322782] > > > > > > > [ 871.323494] ? show_trace_log_lvl+0x1d3/0x2ef > > > > > > > [ 871.324901] ? show_trace_log_lvl+0x1d3/0x2ef > > > > > > > [ 871.326310] ? show_trace_log_lvl+0x1d3/0x2ef > > > > > > > [ 871.327721] ? __wake_up_common_lock+0x82/0xd0 > > > > > > > [ 871.329147] ? __die_body.cold+0x8/0xd > > > > > > > [ 871.330378] ? page_fault_oops+0x163/0x1a0 > > > > > > > [ 871.331691] ? exc_page_fault+0x70/0x170 > > > > > > > [ 871.332946] ? asm_exc_page_fault+0x22/0x30 > > > > > > > [ 871.334454] ? __wake_up_common+0x4c/0x180 > > > > > > > [ 871.335777] __wake_up_common_lock+0x82/0xd0 > > > > > > > [ 871.337183] ? process_writes+0x240/0x240 > > > > > > > [ 871.338461] process_msg+0x18e/0x2f0 > > > > > > > [ 871.339627] xenbus_thread+0x165/0x1c0 > > > > > > > [ 871.340830] ? cpuusage_read+0x10/0x10 > > > > > > > [ 871.342032] kthread+0xe9/0x110 > > > > > > > [ 871.343317] ? kthread_complete_and_exit+0x20/0x20 > > > > > > > [ 871.345020] ret_from_fork+0x22/0x30 > > > > > > > [ 871.346239] > > > > > > > [ 871.347060] Modules linked in: snd_hda_codec_generic ledtr= ig_audio snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec sn= d_hda_core snd_hwdep snd_seq snd_seq_device joydev snd_pcm intel_rapl_msr p= pdev intel_rapl_common snd_timer pcspkr e1000e snd soundcore i2c_piix4 parp= ort_pc parport loop fuse xenfs dm_crypt crct10dif_pclmul crc32_pclmul crc32= c_intel polyval_clmulni polyval_generic floppy ghash_clmulni_intel sha512_s= sse3 serio_raw virtio_scsi virtio_console bochs xhci_pci xhci_pci_renesas x= hci_hcd qemu_fw_cfg drm_vram_helper drm_ttm_helper ttm ata_generic pata_acp= i xen_privcmd xen_pciback xen_blkback xen_gntalloc xen_gntdev xen_evtchn sc= si_dh_rdac scsi_dh_emc scsi_dh_alua uinput dm_multipath > > > > > > > [ 871.368892] CR2: 0000000000000000 > > > > > > > [ 871.370160] ---[ end trace 0000000000000000 ]--- > > > > > > > [ 871.371719] RIP: e030:__wake_up_common+0x4c/0x180 > > > > > > > [ 871.373273] Code: 24 0c 89 4c 24 08 4d 85 c9 74 0a 41 f6 0= 1 04 0f 85 a3 00 00 00 48 8b 43 08 4c 8d 40 e8 48 83 c3 08 49 8d 40 18 48 3= 9 c3 74 5b <49> 8b 40 18 31 ed 4c 8d 70 e8 45 8b 28 41 f6 c5 04 75 5f 49 8b= 40 > > > > > > > [ 871.379866] RSP: e02b:ffffc900400f7e10 EFLAGS: 00010082 > > > > > > > [ 871.381689] RAX: 0000000000000000 RBX: ffff88810541ce98 RC= X: 0000000000000000 > > > > > > > [ 871.383971] RDX: 0000000000000001 RSI: 0000000000000003 RD= I: ffff88810541ce90 > > > > > > > [ 871.386235] RBP: ffffc900400f0280 R08: ffffffffffffffe8 R0= 9: ffffc900400f7e68 > > > > > > > [ 871.388521] R10: 0000000000007ff0 R11: ffff888100ad3000 R1= 2: ffffc900400f7e68 > > > > > > > [ 871.390789] R13: 0000000000000000 R14: 0000000000000000 R1= 5: 0000000000000000 > > > > > > > [ 871.393101] FS: 0000000000000000(0000) GS:ffff88813ff0000= 0(0000) knlGS:0000000000000000 > > > > > > > [ 871.395671] CS: 10000e030 DS: 0000 ES: 0000 CR0: 00000000= 80050033 > > > > > > > [ 871.397863] CR2: 0000000000000000 CR3: 00000001067fe000 CR= 4: 0000000000040660 > > > > > > > [ 871.400441] Kernel panic - not syncing: Fatal exception > > > > > > > [ 871.402171] Kernel Offset: disabled > > > > > > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. > > > > > > > > > > > > > > It isn't the first time I see similar crash, but I can't real= ly > > > > > > > reproduce it reliably. Restarted test usually passes. > > > > > > > Note this is Xen nested in KVM, so it could very well be some= oddity > > > > > > > about nested virt, although looking at the stack trace, it's = unlikely > > > > > > > and more likely some race condition hit only on slower system. > > > > > > > > > > > > Recently I've got the same crash on a real system in domU too. = And also > > > > > > on nested on newer kernel 6.1.57 (here it happened in dom0). So= , this is > > > > > > still an issue and affects not only nested case :/ > > > > > > > > > > > > > Unfortunately I don't have symbols for this kernel handy, but= there is a > > > > > > > single wake_up() call in process_writes(), so it shouldn't be= an issue. > > > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > Full log at https://openqa.qubes-os.org/tests/80779/logfile?f= ilename=3Dserial0.txt > > > > > > > > > > > > More links at https://github.com/QubesOS/qubes-issues/issues/86= 38, > > > > > > including more recent stack trace. > > > > > > > > > > Happens on 6.1.75 too (new stack trace I've added to the issue ab= ove, > > > > > but it's pretty similar). > > > > > > Recently I've got a report from another user about similar issue, on > > > 6.6.29 this time. I also still encounter this issue once a month or s= o, > > > but the user claims they get it much more often: > > > https://github.com/QubesOS/qubes-issues/issues/8638#issuecomment-2135= 419896 > > > The extra conditions reported by the user are: > > > - old AMD system (KGPE-D16 with Opteron 6282 SE) requiring > > > `spec-ctrl=3Dibpb-entry=3Dno-pv` to remain usable > > > - Whonix domU, which has a bunch of sysctl parameters changed, listed > > > at: > > > - https://github.com/Kicksecure/security-misc > > > - https://github.com/Kicksecure/security-misc/blob/master/usr/lib/s= ysctl.d/990-security-misc.conf > > > (unsure which are relevant, maybe `vm.swappiness=3D1`?) > > > > I've got some more report confirming it's still happening on Linux > > 6.12.18. Is there anything I can do to help fixing this? Maybe ask users > > to enable some extra logging? >=20 > Have you been able to capture a crash with debug symbols and run it > through scripts/decode_stacktrace.sh? This worked: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__wake_up_common (kernel/sched/wait.c:85)=20 Code: 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 89 fb 48 83 c3 08= 48 83 ec 08 48 8b 47 08 89 54 24 04 48 39 c3 74 55 4d 89 c7 <4c> 8b 00 41 = 89 f5 41 89 ce 48 8d 78 e8 4d 8d 60 e8 eb 27 74 0c 83 All code =3D=3D=3D=3D=3D=3D=3D=3D 0: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 5: 41 57 push %r15 7: 41 56 push %r14 9: 41 55 push %r13 b: 41 54 push %r12 d: 55 push %rbp e: 53 push %rbx f: 48 89 fb mov %rdi,%rbx 12: 48 83 c3 08 add $0x8,%rbx 16: 48 83 ec 08 sub $0x8,%rsp 1a: 48 8b 47 08 mov 0x8(%rdi),%rax 1e: 89 54 24 04 mov %edx,0x4(%rsp) 22: 48 39 c3 cmp %rax,%rbx 25: 74 55 je 0x7c 27: 4d 89 c7 mov %r8,%r15 2a:* 4c 8b 00 mov (%rax),%r8 <-- trapping instruction 2d: 41 89 f5 mov %esi,%r13d 30: 41 89 ce mov %ecx,%r14d 33: 48 8d 78 e8 lea -0x18(%rax),%rdi 37: 4d 8d 60 e8 lea -0x18(%r8),%r12 3b: eb 27 jmp 0x64 3d: 74 0c je 0x4b 3f: 83 .byte 0x83 Code starting with the faulting instruction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0: 4c 8b 00 mov (%rax),%r8 3: 41 89 f5 mov %esi,%r13d 6: 41 89 ce mov %ecx,%r14d 9: 48 8d 78 e8 lea -0x18(%rax),%rdi d: 4d 8d 60 e8 lea -0x18(%r8),%r12 11: eb 27 jmp 0x3a 13: 74 0c je 0x21 15: 83 .byte 0x83 RSP: 0018:ffffc900009f7e40 EFLAGS: 00010082 RAX: 0000000000000000 RBX: ffff8880109c0798 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8880109c0790 RBP: ffff8880109c0790 R08: 0000000000000000 R09: 0000000000000003 R10: ffffc900009f7eb0 R11: ffffc9000003d000 R12: 0000000000000003 R13: 0000000000000246 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff888018500000(0000) knlGS:00000000000= 00000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000432a0000 CR4: 00000000000406f0 Call Trace: ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:43= 4)=20 ? page_fault_oops (arch/x86/mm/fault.c:715)=20 ? exc_page_fault (arch/x86/include/asm/paravirt.h:693 arch/x86/mm/fault= =2Ec:1489 arch/x86/mm/fault.c:1539)=20 ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:623)=20 ? __wake_up_common (kernel/sched/wait.c:85)=20 ? __pfx_xenbus_thread (drivers/xen/xenbus/xenbus_comms.c:411)=20 __wake_up (include/linux/spinlock.h:406 kernel/sched/wait.c:108 kernel/= sched/wait.c:127)=20 process_msg (drivers/xen/xenbus/xenbus_comms.c:311)=20 xenbus_thread (drivers/xen/xenbus/xenbus_comms.c:418)=20 ? __pfx_autoremove_wake_function (kernel/sched/wait.c:383)=20 kthread (kernel/kthread.c:389)=20 ? __pfx_kthread (kernel/kthread.c:342)=20 ret_from_fork (arch/x86/kernel/process.c:153)=20 ? __pfx_kthread (kernel/kthread.c:342)=20 ret_from_fork_asm (arch/x86/entry/entry_64.S:257)=20 Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd= _timer snd soundcore xenfs nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nf= t_reject nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetl= ink binfmt_misc crct10dif_pclmul crc32_pclmul crc32c_intel polyval_clmulni = polyval_generic ghash_clmulni_intel sha512_ssse3 sha256_ssse3 xen_netfront = sha1_ssse3 xen_privcmd xen_gntdev xen_gntalloc xen_blkback xen_evtchn loop = fuse ip_tables overlay xen_blkfront CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- > I'm curious what process_msg+0x18e/0x2f0 is. process_writes() has a > direct call to wake_up(), but process_msg() calling req->cb(req) may > be xs_wake_up() which is a thin wrapper over wake_up(). So, it's req->cb(req). > They make me wonder if req has been free()ed and at least partially > zero-ed, but it still has wake_up() called. The call stack here is > reminiscent of the one here > https://lore.kernel.org/xen-devel/Z_lJTyVipJJEpWg2@mail-itl/ and the > unexpected value there is 0. >=20 > I haven't actually figured out a scenario where req would be kfree()ed > early. But the handling of kfree(req) being split between > process_msg/writes() and xs_wait_for_reply() makes me a little uneasy. >=20 > Regards, > Jason --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --al3d5CqgWeK2TatU Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgUC08ACgkQ24/THMrX 1ywsggf7BCywUk6bpFTW5Y8Mq6sqOekKP9fm5Wg56MT+nqY08zpJWAj2nufOEqok HrCQgOHhLtgGKshhXYnw0cI12EaHZlod5L/8nC+dZvwJ9/3zXhWLNBLk3CnEm7j1 JF17Ajsf+iOW1EnjUBroGNuhv9yFwGSIQYQ0fjv4HvHRJXC2I3pE8YOKDLWwP0Mw QdSKPDtJYdOfaekvBB8jbiYgPSkzuSePtJrfspSToIyDlfMKtjnTPGOfQlp7E/Wp b8Q+G0KhmbF1rwWbE+wmkzVTco6pexr8x/CoGx0j/bRNB3T8F1eYsvc2xTdnhOSQ EI61XcwyRJiuGcixYvomDBg9fO85FA== =Dw1a -----END PGP SIGNATURE----- --al3d5CqgWeK2TatU-- From xen-devel-bounces@lists.xenproject.org Fri May 02 07:01:25 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 07:01:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974412.1362275 (Exim 4.92) (envelope-from ) id 1uAkOT-0003fD-GV; Fri, 02 May 2025 07:01:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974412.1362275; Fri, 02 May 2025 07: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 1uAkOT-0003f6-DS; Fri, 02 May 2025 07:01:09 +0000 Received: by outflank-mailman (input) for mailman id 974412; Fri, 02 May 2025 07:01:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAkOS-0003f0-9C for xen-devel@lists.xenproject.org; Fri, 02 May 2025 07:01:08 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 359bc21c-2723-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 09:01:02 +0200 (CEST) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-ac289147833so295745366b.2 for ; Fri, 02 May 2025 00:01: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 a640c23a62f3a-ad1891478fasm3433066b.26.2025.05.02.00.01.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 May 2025 00:01: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" X-Inumbo-ID: 359bc21c-2723-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1746169262; x=1746774062; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=fD+eqqXFcd8Femsme1dRMBRh8s1RquYYCBYeuPeNev4=; b=CB3CCNRmCIzXQi2vm54yKaXExdX1tzM7LwsZhtORR8X9CBjBPAIA3HNOFSOypwPRuv 8EkvGs4+/ag7TqpOgyqapJUWRJsL+skGiplmI/jacwl0hxeU+1YKkCFeSEUkmfjQM3Xm Km6k1QlrrjLZvc5qP3logpd898xboyMCaQrlY+EnQjSQzftHlouk8yXcKLybOm8nlCBA xhOx5sAQpkY1zeVpbKmvF8sbOlOyGNT7jCtRAGrmpuLEIzrUXmoZco20xUwOUTTmcpow TWGExBx3N0tsUJcW+m9QKZqNiKto1uVRmOQz5i4u4mVeX6L6pW205WbEMxTIPKHo/Nwi YG9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746169262; x=1746774062; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fD+eqqXFcd8Femsme1dRMBRh8s1RquYYCBYeuPeNev4=; b=XyDgzGBY9d6i8nunH1RHRuAiuKOEyvgD3Jd9W3B7BiuJn6xN0HbLojBg+8/6tBuFqZ 9CJkSFKvnAIqqQVDvSv1VAa0hvkqw4AwiWFCReVHei5J5tKdcGNbHTyllETnVgqDo81H a15sKocQMylYbQLwcka0CgsCSn7/3Gr0A5ItBUYlB0yLYnWTC5Y6jJSjinNAAGPk4EM3 n/wAs4F1SEbgsCiI+GUtbyVo1rowqj7fhPd7bI8cthq3avcemvAbe2ZSDId3POTI0j9s dY4tZV2i3q2J5WT1gsJs15KXQgWVsv1nwjBGLmK43+oo/wXZHvbtp97DQB42qerk2eWi J+jA== X-Forwarded-Encrypted: i=1; AJvYcCUZMZ2pxT2V4ASFSMYTSdzvsPREetvmtqc/VTyDpJ/c3vRLdZo45+cvGwcGa21cjx+XGrH5jpy6ZmQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxYgRP7ZHDULsZb1+oHsFPM8zWnNvrUqgsJMdsaY1Ccs0dtXkp7 XRXxON8MKc1ZC98gXiFR5LLt8SEovZRIkz9H3oLwKGprhAEnUe6m/IBU11OHpg== X-Gm-Gg: ASbGncuXORiYFbG64pRT1q8er+5bgstzTp8UE5/Kh2VzT2LSczosXwuxv00SYV9WSEX FzXbN5Q/40yRPB3c+5PPwShvXzlY5bCu+mZ4wtydbaLbulOqynzx78m2PJroUEdny5b5XQk9uTs P1CjEnUN+ztzUghL6iedFK65w5EhdETWrgyVy/3oci2YfAzog8VbVVPdp2VCzahZWzo3wK/Lzs2 +fpuAuTZEN81NimgBdWCVxXW5PWCI0wIuxLZTYUseXG5iBbG7myQ1sO4FS40iUbSAANTCndfaJI wloZSeQflQzw47/7su0qm2RJg7vEEJikZmrHGoStetuDXt8DohMcBXpXcXFPkbIkH2ktNUIlX4a TbWaF3xkBfPiNr0KfjY5nNMQang== X-Google-Smtp-Source: AGHT+IGq4Y5tLHW3S1pWvjbWxoD7t/BudmkBGcj0rS5oHu9h2E/rpzaSTjQ87f2Hu+52WcQpyZSyZg== X-Received: by 2002:a17:906:4fd0:b0:ac6:d0f6:c85c with SMTP id a640c23a62f3a-ad17ad463c9mr189103566b.20.1746169262243; Fri, 02 May 2025 00:01:02 -0700 (PDT) Message-ID: <7fa7780d-4dfb-4e87-b65c-c9ce86ad7e67@suse.com> Date: Fri, 2 May 2025 09:01:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v2] sbat: Add SBAT section to the Xen EFI binary To: Gerald Elder-Vass Cc: Frediano Ziglio , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20250501122322.230599-1-gerald.elder-vass@cloud.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: <20250501122322.230599-1-gerald.elder-vass@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.05.2025 14:23, Gerald Elder-Vass wrote: > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -58,6 +58,7 @@ obj-y += percpu.o > obj-y += physdev.o > obj-$(CONFIG_COMPAT) += x86_64/physdev.o > obj-y += psr.o > +obj-y += sbat.o > obj-y += setup.o > obj-y += shutdown.o > obj-y += smp.o This being x86-specific here without there really being anything x86-specific about it - what about Arm? It being EFI-specific, why put it here rather than in x86/efi/ (and/or, as per above, in common/efi/, at least for the source file)? > @@ -277,6 +278,9 @@ $(obj)/efi.lds: AFLAGS-y += -DEFI > $(obj)/xen.lds $(obj)/efi.lds: $(src)/xen.lds.S FORCE > $(call if_changed_dep,cpp_lds_S) > > +$(obj)/sbat.o: $(src)/sbat.csv > + $(OBJCOPY) -I binary -O elf64-x86-64 --rename-section .data=.sbat,readonly,data,contents $< $@ While it may seem unlikely now, both rule and dependencies may change going forward. So perhaps better to use the if_changed_deps model right away? Which of course will raise a source file naming question: We can't really assume a .csv -> .o rule to be generically applicable. Therefore maybe the source file extension would better be something less generic, like .sbat. Jan From xen-devel-bounces@lists.xenproject.org Fri May 02 07:19:31 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 07:19:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974425.1362285 (Exim 4.92) (envelope-from ) id 1uAkg6-0005ed-OD; Fri, 02 May 2025 07:19:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974425.1362285; Fri, 02 May 2025 07:19:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAkg6-0005eW-LR; Fri, 02 May 2025 07:19:22 +0000 Received: by outflank-mailman (input) for mailman id 974425; Fri, 02 May 2025 07:19:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAkg5-0005eO-FL for xen-devel@lists.xenproject.org; Fri, 02 May 2025 07:19:21 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c3238681-2725-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 09:19:20 +0200 (CEST) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-ac3fcf5ab0dso267907166b.3 for ; Fri, 02 May 2025 00:19: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 a640c23a62f3a-ad189540ea1sm3551066b.184.2025.05.02.00.19.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 May 2025 00:19: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" X-Inumbo-ID: c3238681-2725-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1746170358; x=1746775158; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=tf5mdlGtyXkbc4vDEpyoTxqOafm62qytitptj6rk6JQ=; b=AzgIuXLA5M5KjDqOlyI9NVT+VXw0c7DUcG6gZvM46fLwLiQQfK5rzUb3p1NSm/DW63 VmBfkoQaS87/hDeMA6y2D/5wM7VRS/DhPUGKI+/zLThG6WwPm1pvzlGkbp/sg7ffxxJY 9aUspuKip6lqMYAFyNTv6Qt83lqWL2LaLiox2MHLA+BlEQ55vDvDRJWXJmrde+KdluKp boX9Uae72Aq2aHDvszl8vEIi1uO2V5N2ycM62xHVrleTc94tvHwgofm4P75uy7h44yOg qZ21DPjhl2Vejx9IsOwrkfhxIsfTpB7UwKFLrXAUbrZwxyIA0bg4omjAf6RopiKioK6I TWUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746170358; x=1746775158; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tf5mdlGtyXkbc4vDEpyoTxqOafm62qytitptj6rk6JQ=; b=pwTR+KjshWREECUhZ5kfCIm+YnK/AivtwDWuRZwnfHxtIxnDDzsI1ZyyfIDFeX9nFN p2APAPmTqvf5I0JgchI3bsTwVfmJhAGXq7lnVlrvq9JKHHwJnco6tGsbmf8l7RCA2eF4 JT/iV2dAtd5GS1dvQxw1fN9fnwkTcOhFtR/ra3mcpC0LhFXeXjY3Vsv8b2dfLihZTfPc PQDvmFYx+oevjNKbqstWEVBFAzVMXQslV8PrbGoTVx3DGQX9SRg32YMVvQxO2KZbQhbL aZejsVNsYvGQIRZwNRAZX/jSX49bD8FLEHlA14cqtSzb+5NR5IC512ExJicOBAfvTRWJ 06tQ== X-Forwarded-Encrypted: i=1; AJvYcCXDMycROJNJPnA13Vh0ebFLtu/bt3smiJGpYyvWKEvD4tTNbPMi62pwiEm2259j+eulYkFYiJcphzs=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx/jts/RY/xmiY/nEtOAT73jBmHfblhgZm4YTjm08Ltg2B+dbSU xKmT0C9kUbwGhOdHtwma2p28eqkQQT/YoA3KSX/HkIksqzYfE0CmKNMUwlIR1Q== X-Gm-Gg: ASbGncu9kZU/TdSmBSZ7cmbEdzq3XW6ofZQQw/ut76DWewPQCayW5y/ny5TzVZge2FJ DPC9TicLUnj3D10vlao1KOf6KCg88H+vVZrA4L+rFjgrS7YIspFfTvQJOF7MEstTDNyPuChaQNn vv/JWNWEUNoRlNKdTSSAmg+SDmrCuQUs69megs/PFV28djsC5Pq7J5Mx/JLXlqNvdmWkLclVk8N dE1mLidTJVD2h0g9EQfMgvXEdHSr/dgvcTPZmYfq+uzS5W85ySeEnQuU25OERbKwkQx5Fx61MZR +Cflg84MWHolOYYIMohrjmA+s/ClY62YUWc2YgXGJtL53HYKHW4XXOOwD531H398cG2xktYcIPH O5hY3TavlKhUiY5RJdOzq4wAN5A== X-Google-Smtp-Source: AGHT+IF0e6O1e4MFUzkW0vJEt/3rNkvlktx8HNISHXg7TDsdHACothWnyOfoTl4tJjGiefClG89dWA== X-Received: by 2002:a17:907:c28f:b0:acb:5583:6fe4 with SMTP id a640c23a62f3a-ad17ad3b23dmr183640166b.6.1746170358486; Fri, 02 May 2025 00:19:18 -0700 (PDT) Message-ID: <773170d1-d8ba-4ba7-90b0-df0d160d8ba8@suse.com> Date: Fri, 2 May 2025 09:19:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange To: Jason Andryuk , Stefano Stabellini Cc: "Ragiadakou, Xenia" , Andrew Cooper , agarciav@amd.com, xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com> <06b66971-d8db-456f-8e83-a20ff7df8f5e@suse.com> <59bfc389-66c8-4d0f-92e3-c0079a807374@suse.com> <3e7b4b20-0127-4db2-806d-f142547f275a@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: <3e7b4b20-0127-4db2-806d-f142547f275a@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01.05.2025 15:44, Jason Andryuk wrote: > On 2025-04-30 20:19, Stefano Stabellini wrote: >> On Wed, 30 Apr 2025, Roger Pau Monné wrote: >>> On Wed, Apr 30, 2025 at 08:27:55AM +0200, Jan Beulich wrote: >>>> On 29.04.2025 23:52, Stefano Stabellini wrote: >>>>> On Tue, 29 Apr 2025, Jan Beulich wrote: >>>>>> On 28.04.2025 22:00, Stefano Stabellini wrote: >>>>>>> On Mon, 28 Apr 2025, Jan Beulich wrote: >>>>>>>> On 25.04.2025 22:19, Stefano Stabellini wrote: > >>>>>>>>> --- a/xen/common/memory.c >>>>>>>>> +++ b/xen/common/memory.c >>>>>>>>> @@ -794,7 +794,7 @@ static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg) >>>>>>>>> rc = guest_physmap_add_page(d, _gfn(gpfn), mfn, >>>>>>>>> exch.out.extent_order) ?: rc; >>>>>>>>> >>>>>>>>> - if ( !paging_mode_translate(d) && >>>>>>>>> + if ( (!paging_mode_translate(d) || is_hardware_domain(d)) && >>>>>>>>> __copy_mfn_to_guest_offset(exch.out.extent_start, >>>>>>>>> (i << out_chunk_order) + j, >>>>>>>>> mfn) ) >>>>>>>> >>>>>>>> Wait, no: A PVH domain (Dom0 or not) can't very well make use of MFNs, can >>>>>>>> it? >>>>>>> >>>>>>> One way or another Dom0 PVH needs to know the MFN to pass it to the >>>>>>> co-processor. >>>>>> >>>>>> I see. That's pretty odd, though. I'm then further concerned of the order of >>>>>> the chunks. At present we're rather lax, in permitting PVH and PV Dom0 the >>>>>> same upper bound. With both CPU and I/O side translation there is, in >>>>>> principle, no reason to permit any kind of contiguity. Of course there's a >>>>>> performance aspect, but that hardly matters in the specific case here. Yet at >>>>>> the same time, once we expose MFNs, contiguity will start mattering as soon >>>>>> as any piece of memory needs to be larger than PAGE_SIZE. Which means it will >>>>>> make tightening of the presently lax handling prone to regressions in this >>>>>> new behavior you're introducing. What chunk size does the PSP driver require? >>>>> >>>>> I don't know. The memory returned by XENMEM_exchange is contiguous, >>>>> right? Are you worried that Xen cannot allocate the requested amount of >>>>> memory contiguously? > > In the case I looked at, it is 8 pages. The driver defines a ring of 32 > * 1k entries. I'm not sure if there are other paths or device versions > where it might differ. As per this ... >>>> That would be Dom0's problem then. But really for a translated guest the >>>> exchanged chunks being contiguous shouldn't matter, correctness-wise. That is, >>>> within Xen, rather than failing a request, we could choose to retry using >>>> discontiguous chunks (contiguous only in GFN space). Such an (afaict) >>>> otherwise correct change would break your use case, as it would invalidate the >>>> MFN information passed back. (This fallback approach would similarly apply to >>>> other related mem-ops. It's just that during domain creation the tool stack >>>> has its own fallback, so it may not be of much use right now.) >>> >>> I think the description in the public header needs to be expanded to >>> specify what the XENMEM_exchange does for translated guests, and >>> clearly write down that the underlying MFNs for the exchanged region >>> will be contiguous. Possibly a new XENMEMF_ flag needs to be added to >>> request contiguous physical memory for the new range. >>> >>> Sadly this also has the side effect of quite likely shattering >>> superpages for dom0 EPT/NPT, which will result in decreased dom0 >>> performance. > > Yes, this appears to happen as memory_exchange seems to always replace > the pages. I tested returning the existing MFNs if they are already > contiguous since that was sufficient for this driver. It worked, but it > was messy. A big loop to copy in the GFN array and check contiguity > which duplicated much of the real loop. ... there may not be a need for the output range to be contiguous? In which case - wouldn't a simple "give me the MFN for this GFN" hypercall do? I seem to vaguely recall that we even had one, long ago; it was purged because of it violating the "no MFNs exposed" principle (and because it not having had any use [anymore]). XENMEM_translate_gpfn_list looks like is what I mean; see commit 2d2f7977a052. Jan From xen-devel-bounces@lists.xenproject.org Fri May 02 07:21:41 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 07:21:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974437.1362296 (Exim 4.92) (envelope-from ) id 1uAkiK-0007OQ-4o; Fri, 02 May 2025 07:21:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974437.1362296; Fri, 02 May 2025 07: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 1uAkiK-0007OJ-0Z; Fri, 02 May 2025 07:21:40 +0000 Received: by outflank-mailman (input) for mailman id 974437; Fri, 02 May 2025 07:21:38 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAkiI-0007OC-Lm for xen-devel@lists.xenproject.org; Fri, 02 May 2025 07:21:38 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 10612ce7-2726-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 09:21:28 +0200 (CEST) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-acb415dd8faso249884466b.2 for ; Fri, 02 May 2025 00:21: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 a640c23a62f3a-ad1895400fesm3833366b.167.2025.05.02.00.21.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 May 2025 00:21: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" X-Inumbo-ID: 10612ce7-2726-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1746170488; x=1746775288; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=8ddhgbdH7PhByfv0jkjtKTYrv55l3Yg3DVqXpazV2ss=; b=A+lguSy8rU5YIs2DxNFyftxuzEEaA5ip3jfOC5+ULZC0RR7MSd37W2uL5WktW/mNwT qIH6YALGJpvdMOUUWtvMrj8SarUYiqh0dZZSDJr58cqYcH23fOaBiRV2I21Yt0KdE0pK ToTZYbKEEPephs0sPsUjjPeKMl85pTl5wQhPeFUdu0Gde+AiByp13hw/oNNNw0th/AH5 nHD4g+qGNsNR5sHCUcWb/I2OL8GTHKfyQlKvbkvIr6+JICrChUuZYvnCqSTbE1HsEdrI XvhnUaFMLy6LuzWp3F6ltBueZQgDYCoRkoJgXgyCXGmh4nC0OyQgSZtwpBztg86+Gdod A53Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746170488; x=1746775288; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8ddhgbdH7PhByfv0jkjtKTYrv55l3Yg3DVqXpazV2ss=; b=izDkyboAKfKn2V065WfJIdpwR1rSwYQ3OD7rtrGRcLQZ1+psoNIpkTg76dkbeUjupA D2dZhThT27p0/rCtHsJx4FzPt7+KXFMYrLvionAcJJlaocxyNhVjU07u4RzDHsZFRJaz jfMJxqSCN5zHCXV5mn9as1FHZIHQS7xPG2EDXNLLWQXPxbnUSd4zmawQl9ffboWIBih1 gP8Q9i6fhslY36TyNnHo5hCrprJl0LF1on0SwgW1A/et/7Rlj+HLL8TlOr6gqucK6oFa Ym5omqLfy0R5ncJrSsE5TytWkBTn4GRnk8Vcw6WZiHKTeZ1HCQw1lTvSac2LtXU42sNm Oihg== X-Forwarded-Encrypted: i=1; AJvYcCVfkKWr1URIW7fj16jcPsS7qmnGCz3GjaaQG4ojC+JuKEZogGYkyqhg1pSyNtTh+CvO9pTrhyjRhoI=@lists.xenproject.org X-Gm-Message-State: AOJu0YwyidkbnUrFKCLrM40mGl56VHQH2iO2imetyRl0CFJcH7wUpmht yAOEzpeIMX6psPyCTwIitb/HxsrcrceZTjVL3+aYZFORsz6sZZLkVjwFHiDtlA== X-Gm-Gg: ASbGncsd3e4rFkbtDecuTy7qdN6CrQ0x5r2lcyhmM8RbNxqgC/3pC7JQ7JBla3gSkCX 4XrTj6M3prGXqL9DzNYWg0icm4Er2y4nOTiPyKFnM4NCiIGFBUu9vWPW9ClAGHAFHvK2PRpEt/G K+iGrtqr3ZfZU8ozOlJvsQ1CkZBOBjfCjGvZC+82F0J9BF+usFpiKr6x8QU0bzTBcywroJBUj3Y pxbD8NngBoSXvTnxN7qWrheD6k1XdiL0TQJplW68r337ZXxv0cbtEOSfDeJcGw0p9IZIRfSI5PL EQmbsWST16yZP8jYn9F+ZqCxQKfmkKNtRqmKPsL61HxUa/7cO8XsxcGZws8Hdv5Ik49KGNUZa9+ 3D+6h1YncDT+7wQql1o/bkWsJhg== X-Google-Smtp-Source: AGHT+IEdzG2gsLM6DuRotLnZp1m52/kvUyL/XIBdplW3NbLCs35Eo/93R1VDAmQa3sYkIYfeVDoUXA== X-Received: by 2002:a17:906:d551:b0:aca:e2d9:41f with SMTP id a640c23a62f3a-ad17af8326cmr146243466b.60.1746170488130; Fri, 02 May 2025 00:21:28 -0700 (PDT) Message-ID: <29a55d44-c26e-4834-b93b-47cbd98f885e@suse.com> Date: Fri, 2 May 2025 09:21:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 02/12] common/hyperlaunch: introduce the domain builder To: "Daniel P. Smith" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Jason Andryuk , Denis Mukhin , Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20250429123629.20839-1-agarciav@amd.com> <20250429123629.20839-3-agarciav@amd.com> <9021c878-9605-4d6e-95b8-ab97da186542@apertussolutions.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: <9021c878-9605-4d6e-95b8-ab97da186542@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.04.2025 20:56, Daniel P. Smith wrote: > On 4/29/25 08:36, Alejandro Vallejo wrote: >> --- a/xen/common/Makefile >> +++ b/xen/common/Makefile >> @@ -11,6 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o >> obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/ >> obj-$(CONFIG_IOREQ_SERVER) += dm.o >> obj-y += domain.o >> +obj-$(CONFIG_DOMAIN_BUILDER) += domain-builder/ > > Please don't do this, use IF_ENABLED in core.c and then hide the > unnecessary units in domain-builder/Makefile as I originally had it. > This allows for a much easier time incrementally converting the dom0 > construction path into a generalized domain construction path. That is, are you viewing this as a transitional thing only? If the end goal is to have it as Alejandro has it above, that may be acceptable (even if not nice). Jan From xen-devel-bounces@lists.xenproject.org Fri May 02 07:50:04 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 07:50:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974453.1362305 (Exim 4.92) (envelope-from ) id 1uAl9k-0002Rz-7B; Fri, 02 May 2025 07:50:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974453.1362305; Fri, 02 May 2025 07:50:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAl9k-0002Rs-4H; Fri, 02 May 2025 07:50:00 +0000 Received: by outflank-mailman (input) for mailman id 974453; Fri, 02 May 2025 07:49:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAl9i-0002Rm-Ul for xen-devel@lists.xenproject.org; Fri, 02 May 2025 07:49:58 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0b036cf7-272a-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 09:49:57 +0200 (CEST) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5efe8d9eb12so2679822a12.1 for ; Fri, 02 May 2025 00:49: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 4fb4d7f45d1cf-5fa76f3b9e6sm853190a12.0.2025.05.02.00.49.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 May 2025 00:49:56 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0b036cf7-272a-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1746172197; x=1746776997; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=nVp9OgJINH32GLcw38xnfkr6nqklHhiDmMM9ojEBDJs=; b=bH6nluPtx6ZGqt5S6HXt9qzgbEOSyvdRu6/Vu/n9RmuyehVu85u8v9SMBoN60tmHdX kj6WHNK17bJpDc5eoMI5liz2P6+WcA4adUjbg2Z/NVfxIKC7/IlMdqmcoy0W1Pi1ch1F v1Ch/0wfBTygEjqjO+JzKw9H2XWGUJRTE35tCFaKi5kAANj1tGEe3GH1tdL1QkgQkCH8 gMyVTFHRGuB7K0+bZsmT8cwzKzOGhyW41c7dLWwtJtwZ5MVQaSfQOtodKsZlTWZ/2kTG ZB7KMarCYWRuMf48vU0QMrSFd2zv3aUEYcMDS+gDSjMDhpxamxvmWs1GgMxaS+QjYRJ5 beUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746172197; x=1746776997; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nVp9OgJINH32GLcw38xnfkr6nqklHhiDmMM9ojEBDJs=; b=Rq9lUD3dYVuTk7LwI5oHiIL8zKkrw1JiAyo/zYZS4geAfsjim5K8SwedTgukbFPfoo oc1mT3FPbGrxOg5GSxemnd9rfrOWA8kLYVZ/NLuCVUCMiFLRkd5XHfxzSITDMQXXSXZ7 bHsfQaLGZluDyYXkvsX0FedozJwSey+pSHOQJF0KIrGK5RsiwdR+9UhQIYqGNtTaCKPn RvpPE6qEyDwAn/QDC7YjpmW3WtPRACR4sRWN0meLTzDHC0CYD4bH6SLG3QwChEqNTsAa BIzF7dMpd2+B04P1ILzAQ3wGPmE8uypISiXh5msG5gWhnWtUojtLOmDTuS2PoDDmoPh8 McGw== X-Forwarded-Encrypted: i=1; AJvYcCWvn2HbX7+955m3Jf+Vw+1fu4Ue7RnmarH4N2+SBb/CpnqmUmON13ZmtYcXYPPjZ2M+9tB928Vp/Aw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw4Yji1vuxH3yofv0gG6Fs9LGN9yySsiJX/Z7tlD11uFRw+NUWZ migYCQlaa2fT156dVnNaBcvQCNjI4PNPjRLAyTKdHktpmRJwEwZBBpj6+yQsaQ== X-Gm-Gg: ASbGncvFVy1HNrb+En2vV56iuX/zsPCjW1RPstDoNs52/oNtzl4t//RDnOp7uZzzpoJ zE+KKnv41ZxPzUL+YHm2oAjl/2AJ4aKfBcb39Fis2z3dDYCOAmazuq67uvNnj8hAHv3w2Hu3WPq fVnPReKigvLVKSZyh1TT7QROcJ45SxvV+Xe8EeApuOHOulae7+ypCyYCopN9rYcYTPC69f3ZwPL fgHSuWDYM4ZeNEbcGBwaEkmEBBWLeBP46jFXipyOKmzpruxaO+pNlftrluXmUmr0NikCg3R4dxn V4985NBqJuDbgBzqUIFx85KL6SXQO0SyU3b7Ng61fyzTJKukvqJoADkgmocVKbr8OMKecs9b2/m spA//01UGF1k4hKHepZSfibUVCQ== X-Google-Smtp-Source: AGHT+IHuhog1hPuJBIOfPWOpBYi8z84Qif/TB8q9HsyPM861/M9qCURNAWhm2K2lULZokhZsmd9V4A== X-Received: by 2002:a05:6402:2685:b0:5f8:d4bf:e663 with SMTP id 4fb4d7f45d1cf-5fa77fdc49amr1276416a12.2.1746172197144; Fri, 02 May 2025 00:49:57 -0700 (PDT) Message-ID: Date: Fri, 2 May 2025 09:49:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/vmx: Fix label name in vmwrite_safe() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250501230834.759523-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: <20250501230834.759523-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.05.2025 01:08, Andrew Cooper wrote: > This condition is called VMFail(valid) in the SDM. > > No functional change. > > Fixes: fc3db01db6fb ("x86/vmx: Rework VMX wrappers using `asm goto()`") > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Fri May 02 07:51:30 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 07:51:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974468.1362316 (Exim 4.92) (envelope-from ) id 1uAlBB-0004KS-Nc; Fri, 02 May 2025 07:51:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974468.1362316; Fri, 02 May 2025 07:51: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 1uAlBB-0004KL-Iz; Fri, 02 May 2025 07:51:29 +0000 Received: by outflank-mailman (input) for mailman id 974468; Fri, 02 May 2025 07:51:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAlBA-0004Ji-BE for xen-devel@lists.xenproject.org; Fri, 02 May 2025 07:51:28 +0000 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [2a00:1450:4864:20::534]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 400dc7c2-272a-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 09:51:26 +0200 (CEST) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5f4ca707e31so2676985a12.2 for ; Fri, 02 May 2025 00:51: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 a640c23a62f3a-ad1891a1e60sm9697366b.47.2025.05.02.00.51.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 May 2025 00:51: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" X-Inumbo-ID: 400dc7c2-272a-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1746172286; x=1746777086; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=yEJP/3Pi6fsvkA0BQbpjsUSe/tiiQFJ8vRw9VfEK1lM=; b=D7nYQDjaae+gWARMFZXNt/7ed1MU3e2EhxCzGO+wQMvrVN0pMTtDNCB0zpF7eiv5je RWjFoaHsQWFhFj+f77vc8fTBuUe4n1q+JHucLhMXZRP6IlT6iyjySM5o7odlxHBveLxf ufsG8QF0nhrbaNZESgrqMLWebj6c5pCnTm7sQZa8pHgghq4Ut4OGAb+QWKljfXlZ7sTy tOQyjUI3knoNuofbgo5l1zt9nDRPKUPc1dF9dTygec2H8qt5QYlJkvJlN1dEAWow8LVc 1eAqXIAgg7kqCzetmX2jEKrsn46h6bYFvMkpnbmEsB7iLjaS8VRB7uCsy/qWVbkQj+7A ZOAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746172286; x=1746777086; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yEJP/3Pi6fsvkA0BQbpjsUSe/tiiQFJ8vRw9VfEK1lM=; b=EdJrSRxZdIshqjyT5qlKZzda8HEUmYhvIiFs4fYpK57YmDNb5AcaodOdzdtUN1QYBH 9NnMhdFlJCZbD2FMaasH4I1CNZIjFm4u3yN0frEi0orvPCReE9fvkxLgt2wZ0EMcR24P 6JJAu59qySsWB5L0qwkcMexbUr7u2OoUF4Vu5E2eVDibqFH670iBPSBOC5Ap2u/C252j 1pJRn54uOkSUYdMbx1XHomWt7/Z9WRo7oYE+qvgan1tH9YLIh8oeXkyt8rHYoA0RN09E wV4S5aaMSGOuUpX087Gn2utstB+Poq79iqM8X99+zy0X3t94b5WK1OAEy/QUQ/UamSWa u3oQ== X-Forwarded-Encrypted: i=1; AJvYcCVN6kJNdiaFbXRS2YerIjpXBNjBBWqXSl2xKeyi9C5eHsSWcsLL38xWuT6G32IgiXCg4iHheM8Fr7E=@lists.xenproject.org X-Gm-Message-State: AOJu0YyozK3asWWudW/cXs4uMXcOChIqpes9wes2IJDG/Q0aJIBkpiQh SOszYQ9kWwiOBKR5U7r5IHcvPaUBNIY+xuUTcLYcJ3VMj4crArh/VZqie+t+3VWNe1adoxhf/DE = X-Gm-Gg: ASbGncukZJQn8vw+vUDxwg7sTyJLqiiNR2LEklOtlxwy1NPwT/5EbTADnnTTFozD6kk xmVtQjdoquUC5LvmoRpPMzUMLs6GczTNOsC6GIFicSfTtqIrIhKyJr4HjLgLsVJ5Vqb8C/YyMMk oS+W+uE0wY0+Sz+x5JF/HowjrOtVTFzl7wD5aWclPxmq5f9TEyLYAuHPPCGMsCARMbvujiGQTKn mjNXJY47TepH2wHZsowEqg2HfSXSQ5582yCGJXOjiapYgmAa/F3KfMvbMblvHCt4mNoIE3B4s6p XgAn7F1ks1Tj5mDcVVqBZtO+UHxzC55Y9xizpl5aqPIKlYyD51EA/ScE9tzZGWgWvwuBxy0yAoh OgjVwuZIfj+YNYtPuWjr67HFQxw== X-Google-Smtp-Source: AGHT+IGmtpwygMA7VlA/AWgHncpo9LfoAd01s28p88tuKvs0g124S/1i9Ru4X/CM+yOFZ2/lv+wtMQ== X-Received: by 2002:a17:907:3991:b0:ac8:1126:ac15 with SMTP id a640c23a62f3a-ad17af8f27amr183370466b.41.1746172286103; Fri, 02 May 2025 00:51:26 -0700 (PDT) Message-ID: Date: Fri, 2 May 2025 09:51:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/thunk: Don't opencode TSX instructions in clear_bhb_tsx() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250501181655.711704-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: <20250501181655.711704-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.05.2025 20:16, Andrew Cooper wrote: > The new toolchain baseline understands the RTM instructions. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Fri May 02 08:02:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 08:02:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974487.1362337 (Exim 4.92) (envelope-from ) id 1uAlM5-00070X-Or; Fri, 02 May 2025 08:02:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974487.1362337; Fri, 02 May 2025 08:02: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 1uAlM5-00070Q-Ly; Fri, 02 May 2025 08:02:45 +0000 Received: by outflank-mailman (input) for mailman id 974487; Fri, 02 May 2025 08:02:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAlM4-00070K-TR for xen-devel@lists.xenproject.org; Fri, 02 May 2025 08:02:45 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cfd1ada1-272b-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 10:02:37 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id EE973A4B9D8; Fri, 2 May 2025 07:57:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE92BC4CEE4; Fri, 2 May 2025 08:02: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" X-Inumbo-ID: cfd1ada1-272b-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746172956; bh=VrP6FYMiM8APrbbiFFr3vwipUq0BMzeGXIdgg8yPKw0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=o40ruDpdxuzYi5SlPXBVO3KE83CyehxDNrNO/541PgVjFTDFgkp9ttfsSywwoC2Xi deyF+fk2wjQxxc5XQRBVm8Bmt2O6KE/EWUyWPBtkP4DjmRVUsgvwR4qUU7TcNGYno2 LrsDSCZuBZAWl/LYiTehIFOfFP/Ile60POceUApHmDdzreBk3ZrpTs99IMSeErgzEI qcVRENdvjn60dt64quynSDl7VztBTPTl/yjYLXHI6ByaM4mPy/wh1yniu8zkGauz6l KWZFS4mxzAp7qh9gzlauN/px1lSmL30l6NU2jcy73WKeezA7wFlGHek2h34pt4xuBA QpbqWIpAjreaA== Date: Fri, 2 May 2025 10:02:26 +0200 From: Ingo Molnar To: "Xin Li (Intel)" Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-pm@vger.kernel.org, linux-edac@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, netdev@vger.kernel.org, platform-driver-x86@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, acme@kernel.org, jgross@suse.com, andrew.cooper3@citrix.com, peterz@infradead.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, wei.liu@kernel.org, ajay.kaher@broadcom.com, bcm-kernel-feedback-list@broadcom.com, tony.luck@intel.com, pbonzini@redhat.com, vkuznets@redhat.com, seanjc@google.com, luto@kernel.org, boris.ostrovsky@oracle.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, dapeng1.mi@linux.intel.com, ilpo.jarvinen@linux.intel.com Subject: Re: [PATCH v4 02/15] x86/msr: Move rdtsc{,_ordered}() to Message-ID: References: <20250427092027.1598740-1-xin@zytor.com> <20250427092027.1598740-3-xin@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250427092027.1598740-3-xin@zytor.com> * Xin Li (Intel) wrote: > index 94408a784c8e..13335a130edf 100644 > --- a/arch/x86/include/asm/tsc.h > +++ b/arch/x86/include/asm/tsc.h > @@ -7,7 +7,81 @@ > > #include > #include > -#include > + > +/* > + * both i386 and x86_64 returns 64-bit value in edx:eax, but gcc's "A" > + * constraint has different meanings. For i386, "A" means exactly > + * edx:eax, while for x86_64 it doesn't mean rdx:rax or edx:eax. Instead, > + * it means rax *or* rdx. > + */ > +#ifdef CONFIG_X86_64 > +/* Using 64-bit values saves one instruction clearing the high half of low */ > +#define DECLARE_ARGS(val, low, high) unsigned long low, high > +#define EAX_EDX_VAL(val, low, high) ((low) | (high) << 32) > +#define EAX_EDX_RET(val, low, high) "=a" (low), "=d" (high) > +#else > +#define DECLARE_ARGS(val, low, high) u64 val > +#define EAX_EDX_VAL(val, low, high) (val) > +#define EAX_EDX_RET(val, low, high) "=A" (val) > +#endif Meh, this patch creates a duplicate copy of DECLARE_ARGS() et al in now: arch/x86/include/asm/msr.h:#define DECLARE_ARGS(val, low, high) unsigned long low, high arch/x86/include/asm/msr.h:#define DECLARE_ARGS(val, low, high) u64 val arch/x86/include/asm/msr.h: DECLARE_ARGS(val, low, high); arch/x86/include/asm/msr.h: DECLARE_ARGS(val, low, high); arch/x86/include/asm/msr.h: DECLARE_ARGS(val, low, high); arch/x86/include/asm/tsc.h:#define DECLARE_ARGS(val, low, high) unsigned long low, high arch/x86/include/asm/tsc.h:#define DECLARE_ARGS(val, low, high) u64 val arch/x86/include/asm/tsc.h: DECLARE_ARGS(val, low, high); arch/x86/include/asm/tsc.h: DECLARE_ARGS(val, low, high); arch/x86/include/asm/tsc.h:#undef DECLARE_ARGS Which was both an undeclared change, bloats the code, causes various problems, and is totally unnecessary to boot. Please don't do that ... Thanks, Ingo From xen-devel-bounces@lists.xenproject.org Fri May 02 08:04:14 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 08:04:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974498.1362347 (Exim 4.92) (envelope-from ) id 1uAlNW-0007Vb-1k; Fri, 02 May 2025 08:04:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974498.1362347; Fri, 02 May 2025 08:04: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 1uAlNV-0007VU-VQ; Fri, 02 May 2025 08:04:13 +0000 Received: by outflank-mailman (input) for mailman id 974498; Fri, 02 May 2025 08:04:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAlNV-0007VM-0Y for xen-devel@lists.xenproject.org; Fri, 02 May 2025 08:04:13 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 07afb2e8-272c-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 10:04:11 +0200 (CEST) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-ac339f53df9so370571866b.1 for ; Fri, 02 May 2025 01:04: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 a640c23a62f3a-ad189149fc4sm11377966b.36.2025.05.02.01.04.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 May 2025 01:04: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" X-Inumbo-ID: 07afb2e8-272c-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1746173050; x=1746777850; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=6vHvO/Ki8AASIXA/ZkTOmnjaGU42zPy2OR3n8qVU1I8=; b=Xe0psTJSsGdaaKcT2Y1fqos1ywUayOzanPAgGvORwViOrBZxoVVTu8gVRrAUZjnJ+9 tWlJeOXWGRa//K/c8p4/qR2zpXvrp6HmLxKtc0Jf8CgQms7ba21WTzIB6MVcOwAf6akm fj99fA2+3K+Obnslq+2lKyY7u27ILIT2g1rE+5FGMlPBt+5vTTCwyEyEFGn9nUwH1YaS vah15Y7f6TJ2V41wpFkFM2LfWhgOaHTIYKpMhPFJ2mBKhMnYVqz8k0FjBcR/FJPOROvG vSApy5uR/HZulTCSqw+lJHJPWP5YkYtLqc+4EJOMGlPkLh2QMzmQLKNuO/Xzo9rHh6uG vcIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746173050; x=1746777850; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6vHvO/Ki8AASIXA/ZkTOmnjaGU42zPy2OR3n8qVU1I8=; b=j60l84ONMfBHPj+iyUIMOVoHKs4ejgiwXDOJ6TJwd4M4Z/SXBTVTroEep1ZXGACMbY y0zGLnxFP9K2OT+372AjaVd2VrgSVsRlWZcqfkCsYKUUl9CoyZduqxd6Az95LwJ34zv8 2+s9K0P+74NRWRMa/NIK2DoSViY93jjP3+BWSnNy7ZETsufexxCPtruHuCYM8pgOStEr L/0C2vtq7dNu+XzIBzoinZGVMJKfnH+ryfSPuIlnDhosA88c8IcF6u8ru8717PMDkCLB uplfJ/TO13i6b7Ru17Qd8B+suDHduo0cXjBdAYWTOgsafiTB6jwlV6nNrx7xsT9upGNU Xoyg== X-Forwarded-Encrypted: i=1; AJvYcCXdvpAHRhNa2IKWMNHFDVYa44sD4DWz1qSh+poYBNLTt42D15Qg20n8Zdzckk/V5X8IM8brYaU7OJY=@lists.xenproject.org X-Gm-Message-State: AOJu0YxQK9jhVcq/7et1UC6JyXcO9QYVcEToIu9H6hgR3Fdoj5xPh5y6 FgToed0BmLHOYn9qL9VcMggWqNb0LRuR7snr6slrUoaQDi5DHOwKOBeIUaSeXA== X-Gm-Gg: ASbGncvih6/TIQ78PY6+cCJBP3q1vrfBLi56YFN7sPXQcyjFm8KA6I+fSzm5OUA71P/ RgWCn5uZRrfw8xsHg86f7VOJoRdJsuJfJLdmzAW0ghgd9ia8a13UHcklFhXlR94dBucyD9Zjl31 lWmWoOhO9wde3cp0RHwuEOnYD0rzBXVPK5ggomLLJ7rbUPfhBK6PDPtdOvbVaF4dX86eUQE3AmT Zk5KpFeEu7aAu9du6M/Sq2NeIiQKp51/tHNdfAIdRLezL9S6s6ur4oVQiOKc+Qdp/jYSWXPT2FB o+cwDthqiU9wIxNDAeKqnxBOW2O4mVOW3NKLQZuiLHxg1MNPqQlBC3bNTRd3dfEL6ZyB9JMcV3h iI3ZjaPRJ1YsvxdcwbPqd+T42Qw== X-Google-Smtp-Source: AGHT+IFC+vLnT43pAXz4ktb2paUpCH2HYb7YhmMQjAI4SDgeHglfr1O91GBVMG3busT/K9o5wzjYzw== X-Received: by 2002:a17:907:7b87:b0:ac3:b613:a651 with SMTP id a640c23a62f3a-ad17ad87102mr204990566b.17.1746173050484; Fri, 02 May 2025 01:04:10 -0700 (PDT) Message-ID: Date: Fri, 2 May 2025 10:04:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/vpic: Improve bitops usage To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250501233042.762295-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: <20250501233042.762295-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.05.2025 01:30, Andrew Cooper wrote: > * For vpic_get_priority(), introduce a common ror8() helper in plain C. One > thing that I can't persuade the compiler to realise is that a non-zero > value rotated is still non-zero, so use __builtin_clz() to help the > optimiser out. > > * vpic_ioport_write() can be simplified to just for_each_set_bit(), which > avoids spilling pending to the stack each loop iteration. Changing pending > from unsigned int to uint8_t isn't even strictly necessary given the > underlying types of vpic->isr and vpic->irr, but done so clarity. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich > One thing I can't seem to avoid is GCC zero extending the result of ror8() > before passing it to BSF/TZCNT. Then again, that's very specific to uint8_t, > and x86's preserving behaviour on byte writes. It can't know that the upper bits are "don't care" here, related to the aspect above (it not inferring non-zero of the result of the rotate when the input is non-zero). And I expect it would be too much of a special case to warrant getting all of this accounted for, just to remove the zero-ext. For this specific case we might be able to cheat, but I'm unsure that's worth it either (and I also haven't tried whether it actually has the intended effect): val8 = ror8(mask, vpic->priority_add); asm ( "" : "=r" (val32) : "0" (val8) ); return __builtin_ctz(val32); Jan From xen-devel-bounces@lists.xenproject.org Fri May 02 08:18:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 08:18:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974513.1362357 (Exim 4.92) (envelope-from ) id 1uAlbe-00015R-6s; Fri, 02 May 2025 08:18:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974513.1362357; Fri, 02 May 2025 08:18: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 1uAlbe-00015K-4E; Fri, 02 May 2025 08:18:50 +0000 Received: by outflank-mailman (input) for mailman id 974513; Fri, 02 May 2025 08:18:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAlbc-00015E-Av for xen-devel@lists.xenproject.org; Fri, 02 May 2025 08:18:48 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [2600:3c0a:e001:78e:0:1991:8:25]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0edadf5f-272e-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 10:18:43 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id DC8B3434E4; Fri, 2 May 2025 08:18:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3FCDC4CEE9; Fri, 2 May 2025 08:18: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" X-Inumbo-ID: 0edadf5f-272e-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746173921; bh=cceIUw9EX6CJ615GNdppXNrElVMTPwJztPtsbm/5hy8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U/TX4Mf5qkn+d5eWIgqv7vIk75zfM6yrIPmHLSfaOvilB1TMJCOwX6UxaLi3/4ntF CTdvcW24sQjGFvj/AXsOJGncvakw6Z4p8ZclsEDe2hknFU+ckPt2/qHvdPIyk59xbo rV1pq8QWA/qTkpUObp899r1foJ9LRWGoqI6CTS1V0Cu+JCa9JAJtB9a+QLyuX858V2 70a22IBVEVB0MRp2wD32EPcEnvbH3GYXu7Ra0oeU+V0Ro/eudlwhxrpwk5f5KAdfqv vheM2b3e+KJz5ez4AHrUsoRTaS6WvSOsjRrAmUB93Bp+mNMmxeQYuTcRVRzY5U5RIz AD+AuPXxVZ3PA== Date: Fri, 2 May 2025 10:18:30 +0200 From: Ingo Molnar To: "Xin Li (Intel)" Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-pm@vger.kernel.org, linux-edac@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, netdev@vger.kernel.org, platform-driver-x86@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, acme@kernel.org, jgross@suse.com, andrew.cooper3@citrix.com, peterz@infradead.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, wei.liu@kernel.org, ajay.kaher@broadcom.com, bcm-kernel-feedback-list@broadcom.com, tony.luck@intel.com, pbonzini@redhat.com, vkuznets@redhat.com, seanjc@google.com, luto@kernel.org, boris.ostrovsky@oracle.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, dapeng1.mi@linux.intel.com, ilpo.jarvinen@linux.intel.com Subject: Re: [PATCH v4 02/15] x86/msr: Move rdtsc{,_ordered}() to Message-ID: References: <20250427092027.1598740-1-xin@zytor.com> <20250427092027.1598740-3-xin@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250427092027.1598740-3-xin@zytor.com> * Xin Li (Intel) wrote: > For some reason, there are some TSC-related functions in the MSR ^^^^^^^^^^^^^^^ > header even though there is a tsc.h header. The real reason is that the rdtsc{,_ordered}() methods use the EAX_EDX_*() macros to optimize their EDX/EAX assembly accessors, which is why these methods were in . Your followup patch tacitly acknowledges this by silently creating duplicate copies of these facilities in both headers ... I've cleaned it all up in tip:x86/msr via these preparatory patches: x86/msr: Improve the comments of the DECLARE_ARGS()/EAX_EDX_VAL()/EAX_EDX_RET() facility x86/msr: Rename DECLARE_ARGS() to EAX_EDX_DECLARE_ARGS x86/msr: Move the EAX_EDX_*() methods from to Thanks, Ingo From xen-devel-bounces@lists.xenproject.org Fri May 02 08:30:31 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 08:30:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974527.1362368 (Exim 4.92) (envelope-from ) id 1uAlms-00043t-7A; Fri, 02 May 2025 08:30:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974527.1362368; Fri, 02 May 2025 08: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 1uAlms-00043m-3T; Fri, 02 May 2025 08:30:26 +0000 Received: by outflank-mailman (input) for mailman id 974527; Fri, 02 May 2025 08:30:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAlmq-00043e-Ij for xen-devel@lists.xenproject.org; Fri, 02 May 2025 08:30:24 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b07759f8-272f-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 10:30:23 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 2A018A4BB43; Fri, 2 May 2025 08:24:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88BD6C4CEEE; Fri, 2 May 2025 08:30: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" X-Inumbo-ID: b07759f8-272f-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746174621; bh=XJ/fOLSZPcDhzbn7SBomjY3ra1ercNwGTwdTApCpr4M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CsCcumy8yvL+I8c/Q+4FCgid3SiZumzGsXHXwXMdYu5Pb//5a+dPYvjCYyRD0S7xR 8OsobySDrVsqsSztegV67tmw+EzZy4UOm+uiwwLSOqz/aq7BngmEF9jCSpd5akyoGf jMaLyfr2RqTyi2jyDa2H7KelSZY5d/1QPDkg1pXrmQa9gQSSLPwb/gIIrSfO435Of0 0gqTeWxKfMi1jh6+Z8xUkVFzHKvRcUa/gyVx5VK12AAAxHeKAUA7qDytqmewnPFkw4 90zUASti8CLXJfv7JW3XsRHfW5jf8FmECPis1Q3MnBN6EE6TFStJAALK1mkZJmFN08 ftBTm+oNzkoJA== Date: Fri, 2 May 2025 10:30:11 +0200 From: Ingo Molnar To: "Xin Li (Intel)" Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-pm@vger.kernel.org, linux-edac@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, netdev@vger.kernel.org, platform-driver-x86@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, acme@kernel.org, jgross@suse.com, andrew.cooper3@citrix.com, peterz@infradead.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, wei.liu@kernel.org, ajay.kaher@broadcom.com, bcm-kernel-feedback-list@broadcom.com, tony.luck@intel.com, pbonzini@redhat.com, vkuznets@redhat.com, seanjc@google.com, luto@kernel.org, boris.ostrovsky@oracle.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, dapeng1.mi@linux.intel.com, ilpo.jarvinen@linux.intel.com Subject: Re: [PATCH v4 10/15] x86/xen/msr: Remove calling native_{read,write}_msr{,_safe}() in pmu_msr_{read,write}() Message-ID: References: <20250427092027.1598740-1-xin@zytor.com> <20250427092027.1598740-11-xin@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250427092027.1598740-11-xin@zytor.com> * Xin Li (Intel) wrote: > hpa found that pmu_msr_write() is actually a completely pointless > function [1]: all it does is shuffle some arguments, then calls > pmu_msr_chk_emulated() and if it returns true AND the emulated flag > is clear then does *exactly the same thing* that the calling code > would have done if pmu_msr_write() itself had returned true. And > pmu_msr_read() does the equivalent stupidity. > > Remove the calls to native_{read,write}_msr{,_safe}() within > pmu_msr_{read,write}(). Instead reuse the existing calling code > that decides whether to call native_{read,write}_msr{,_safe}() based > on the return value from pmu_msr_{read,write}(). Consequently, > eliminate the need to pass an error pointer to pmu_msr_{read,write}(). > > While at it, refactor pmu_msr_write() to take the MSR value as a u64 > argument, replacing the current dual u32 arguments, because the dual > u32 arguments were only used to call native_write_msr{,_safe}(), which > has now been removed. > > [1]: https://lore.kernel.org/lkml/0ec48b84-d158-47c6-b14c-3563fd14bcc4@zytor.com/ > > Suggested-by: H. Peter Anvin (Intel) > Sign-off-by: Xin Li (Intel) 'Sign-off-by' is not a proper SOB tag, I've changed it to Signed-off-by. Thanks, Ingo From xen-devel-bounces@lists.xenproject.org Fri May 02 08:52:54 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 08:52:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974540.1362377 (Exim 4.92) (envelope-from ) id 1uAm8U-0007nm-Se; Fri, 02 May 2025 08:52:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974540.1362377; Fri, 02 May 2025 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 1uAm8U-0007nf-Pw; Fri, 02 May 2025 08:52:46 +0000 Received: by outflank-mailman (input) for mailman id 974540; Fri, 02 May 2025 08:52:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAm8T-0007nZ-0d for xen-devel@lists.xenproject.org; Fri, 02 May 2025 08:52:45 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c7af8759-2732-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 10:52:31 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D97EF5C1C03; Fri, 2 May 2025 08:50:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CD4BC4CEE4; Fri, 2 May 2025 08:52: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" X-Inumbo-ID: c7af8759-2732-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746175956; bh=SxBjkp/J5NNckAueMrQukPtaJ3IgnM76Ll+NdIUNXIk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CJ1UtPGazPk6ZEG0HwcxHRuFOiH/JR3XBtmKJLiHP/jshRcy9Arm4mvyGtimOvgTy OmBKdXEFyjZ8BZMwd8D5Yrhyf1bz+OVbfKouNV2DcQM8RRSV+d8/qkqc9y00t15W+1 79vLoiUJcrIIg1H9/yghIFiGnP5DFIedHMd4MJHdsNaPcS8RGk10pBZFuSDnIKldZI i66CAPb8L+3qEo576w8fnUHJl5uZTEiJZdpOmBXZziTwORlH5NpUwvvKUbp9Waeu+E Y/YctucrsKzRC6TBuMOLWKYkj+excCXHWTN55BMKpApl0iGcZF2wL5SK+lxFB1I13T UP3Jz5dY9bM3g== Date: Fri, 2 May 2025 10:52:26 +0200 From: Ingo Molnar To: "Xin Li (Intel)" Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-pm@vger.kernel.org, linux-edac@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, netdev@vger.kernel.org, platform-driver-x86@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, acme@kernel.org, jgross@suse.com, andrew.cooper3@citrix.com, peterz@infradead.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, wei.liu@kernel.org, ajay.kaher@broadcom.com, bcm-kernel-feedback-list@broadcom.com, tony.luck@intel.com, pbonzini@redhat.com, vkuznets@redhat.com, seanjc@google.com, luto@kernel.org, boris.ostrovsky@oracle.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, dapeng1.mi@linux.intel.com, ilpo.jarvinen@linux.intel.com Subject: Re: [PATCH v4 02/15] x86/msr: Move rdtsc{,_ordered}() to Message-ID: References: <20250427092027.1598740-1-xin@zytor.com> <20250427092027.1598740-3-xin@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250427092027.1598740-3-xin@zytor.com> * Xin Li (Intel) wrote: > For some reason, there are some TSC-related functions in the MSR > header even though there is a tsc.h header. > > Relocate rdtsc{,_ordered}() from to , and > subsequently remove the inclusion of in . > > Signed-off-by: Xin Li (Intel) > Acked-by: Dave Hansen > Acked-by: Peter Zijlstra (Intel) > --- a/arch/x86/include/asm/tsc.h > +++ b/arch/x86/include/asm/tsc.h > @@ -7,7 +7,81 @@ > > #include > #include > -#include Note that in the tip:x86/msr commit I've applied today I've intentionally delayed the removal of this header dependency, to reduce the probability of breaking -next today or in the near future. We can remove that now superfluous header dependency in a future patch. Thanks, Ingo From xen-devel-bounces@lists.xenproject.org Fri May 02 11:41:13 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 11:41:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974588.1362404 (Exim 4.92) (envelope-from ) id 1uAolH-0004Gu-L3; Fri, 02 May 2025 11:40:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974588.1362404; Fri, 02 May 2025 11:40: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 1uAolH-0004G9-Fd; Fri, 02 May 2025 11:40:59 +0000 Received: by outflank-mailman (input) for mailman id 974588; Fri, 02 May 2025 11:40:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAolG-0004Db-K0 for xen-devel@lists.xenproject.org; Fri, 02 May 2025 11:40:58 +0000 Received: from mail.actia.se (mail.actia.se [212.181.117.226]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4ff52dca-274a-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 13:40:57 +0200 (CEST) Received: from S036ANL.actianordic.se (10.12.31.117) by S035ANL.actianordic.se (10.12.31.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 2 May 2025 13:40:56 +0200 Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%3]) with mapi id 15.01.2507.039; Fri, 2 May 2025 13:40:56 +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" X-Inumbo-ID: 4ff52dca-274a-11f0-9eb4-5ba50f476ded From: John Ernberg To: Juergen Gross , Stefano Stabellini CC: Oleksandr Tyshchenko , Catalin Marinas , Andrew Morton , "xen-devel@lists.xenproject.org" , "iommu@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "imx@lists.linux.dev" , John Ernberg , "stable@kernel.org" Subject: [PATCH 1/2] xen: swiotlb: Use swiotlb bouncing if kmalloc allocation demands it Thread-Topic: [PATCH 1/2] xen: swiotlb: Use swiotlb bouncing if kmalloc allocation demands it Thread-Index: AQHbu1cQNcuPrbmRHEK42QDjG7hf6w== Date: Fri, 2 May 2025 11:40:55 +0000 Message-ID: <20250502114043.1968976-2-john.ernberg@actia.se> References: <20250502114043.1968976-1-john.ernberg@actia.se> In-Reply-To: <20250502114043.1968976-1-john.ernberg@actia.se> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: git-send-email 2.49.0 x-originating-ip: [10.12.12.35] x-esetresult: clean, is OK x-esetid: 37303A2956B14453667460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Xen swiotlb support was missed when the patch set starting with 4ab5f8ec7d71 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN") was merged. When running Xen on iMX8QXP, a SoC without IOMMU, the effect was that USB transfers ended up corrupted when there was more than one URB inflight at the same time. Add a call to dma_kmalloc_needs_bounce() to make sure that allocations too small for DMA get bounced via swiotlb. Closes: https://lore.kernel.org/linux-usb/ab2776f0-b838-4cf6-a12a-c208eb6aa= d59@actia.se/ Fixes: 4ab5f8ec7d71 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA= _MINALIGN") Cc: stable@kernel.org # v6.5+ Signed-off-by: John Ernberg --- It's impossible to pick an exact fixes tag since this driver was missed in the flagged patch set. I picked one I felt gave a decent enough picture for someone coming across this later. --- drivers/xen/swiotlb-xen.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 1f65795cf5d7..ef56a2500ed6 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -217,6 +217,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *d= ev, struct page *page, * buffering it. */ if (dma_capable(dev, dev_addr, size, true) && + !dma_kmalloc_needs_bounce(dev, size, dir) && !range_straddles_page_boundary(phys, size) && !xen_arch_need_swiotlb(dev, phys, dev_addr) && !is_swiotlb_force_bounce(dev)) --=20 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 11:41:13 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 11:41:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974587.1362399 (Exim 4.92) (envelope-from ) id 1uAolH-0004Dt-D0; Fri, 02 May 2025 11:40:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974587.1362399; Fri, 02 May 2025 11:40: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 1uAolH-0004Dm-9B; Fri, 02 May 2025 11:40:59 +0000 Received: by outflank-mailman (input) for mailman id 974587; Fri, 02 May 2025 11:40:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAolG-0004Db-Co for xen-devel@lists.xenproject.org; Fri, 02 May 2025 11:40:58 +0000 Received: from mail.actia.se (mail.actia.se [212.181.117.226]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4f9583e3-274a-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 13:40:56 +0200 (CEST) Received: from S036ANL.actianordic.se (10.12.31.117) by S035ANL.actianordic.se (10.12.31.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 2 May 2025 13:40:55 +0200 Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%3]) with mapi id 15.01.2507.039; Fri, 2 May 2025 13:40:55 +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" X-Inumbo-ID: 4f9583e3-274a-11f0-9eb4-5ba50f476ded From: John Ernberg To: Juergen Gross , Stefano Stabellini CC: Oleksandr Tyshchenko , Catalin Marinas , Andrew Morton , "xen-devel@lists.xenproject.org" , "iommu@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "imx@lists.linux.dev" , John Ernberg Subject: [PATCH 0/2] xen: swiotlb: 2 fixes SoCs w/o IOMMU (e.g. iMX8QXP) Thread-Topic: [PATCH 0/2] xen: swiotlb: 2 fixes SoCs w/o IOMMU (e.g. iMX8QXP) Thread-Index: AQHbu1cQRZF4GUbfuk+26xI8NrrtUw== Date: Fri, 2 May 2025 11:40:55 +0000 Message-ID: <20250502114043.1968976-1-john.ernberg@actia.se> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: git-send-email 2.49.0 x-originating-ip: [10.12.12.35] x-esetresult: clean, is OK x-esetid: 37303A2956B14453667460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 There's 2 problems with DMA today when running Xen on the iMX8QXP SoC. The first identifies as a USB corruption, but is actually a memory corruption risk with any small DMA transfer, and just manifests itself in USB transfers. This is a regression fix tracing back to Linux 6.5 when the blamed commit (patch series) landed. The second one causes any attempt to use DMA via the iMX8QXP eDMA v3 block to fail with DMA_MAPPING_ERROR when running under Xen because this DMA controller wants to do DMA in MMIO space. I'm a little bit more on the fence with the second one, as that never worked, but is still fixing an issue. There is no Fixes or Cc stable on this one because of this. John Ernberg (2): xen: swiotlb: Use swiotlb bouncing if kmalloc allocation demands it xen: swiotlb: Implement map_resource callback drivers/xen/swiotlb-xen.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --=20 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 11:41:13 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 11:41:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974589.1362419 (Exim 4.92) (envelope-from ) id 1uAolK-0004gC-QR; Fri, 02 May 2025 11:41:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974589.1362419; Fri, 02 May 2025 11:41: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 1uAolK-0004g5-N2; Fri, 02 May 2025 11:41:02 +0000 Received: by outflank-mailman (input) for mailman id 974589; Fri, 02 May 2025 11:41:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAolJ-0004fV-OM for xen-devel@lists.xenproject.org; Fri, 02 May 2025 11:41:01 +0000 Received: from mail.actia.se (mail.actia.se [212.181.117.226]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4fb32e48-274a-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 13:40:56 +0200 (CEST) Received: from S036ANL.actianordic.se (10.12.31.117) by S036ANL.actianordic.se (10.12.31.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 2 May 2025 13:40:56 +0200 Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%3]) with mapi id 15.01.2507.039; Fri, 2 May 2025 13:40:56 +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" X-Inumbo-ID: 4fb32e48-274a-11f0-9ffb-bf95429c2676 From: John Ernberg To: Juergen Gross , Stefano Stabellini CC: Oleksandr Tyshchenko , Catalin Marinas , Andrew Morton , "xen-devel@lists.xenproject.org" , "iommu@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "imx@lists.linux.dev" , John Ernberg Subject: [PATCH 2/2] xen: swiotlb: Implement map_resource callback Thread-Topic: [PATCH 2/2] xen: swiotlb: Implement map_resource callback Thread-Index: AQHbu1cR+sKkXAZoXEOAUfrcrER15w== Date: Fri, 2 May 2025 11:40:56 +0000 Message-ID: <20250502114043.1968976-3-john.ernberg@actia.se> References: <20250502114043.1968976-1-john.ernberg@actia.se> In-Reply-To: <20250502114043.1968976-1-john.ernberg@actia.se> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: git-send-email 2.49.0 x-originating-ip: [10.12.12.35] x-esetresult: clean, is OK x-esetid: 37303A2955B14453667460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Needed by the eDMA v3 DMA engine found in iommu-less SoCs such as iMX8QXP to be able to perform DMA operations as a Xen Hardware Domain, which needs to be able to do DMA in MMIO space. The callback implementation is basically the same as the one for direct mapping of resources, except this also takes into account Xen page mappings. There is nothing to do for unmap, just like with direct, so the unmap callback is not needed. Signed-off-by: John Ernberg --- I originally exported dma_direct_map_resource() and used that which appeared to work, but it felt like not checking Xen page mappings wasn't fully correct and I went with this. But if dma_direct_map_resource() is the correct approach here then I can submit that isntead. --- drivers/xen/swiotlb-xen.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index ef56a2500ed6..0f02fdd9128d 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -285,6 +285,20 @@ static void xen_swiotlb_unmap_page(struct device *hwde= v, dma_addr_t dev_addr, attrs, pool); } =20 +static dma_addr_t xen_swiotlb_map_resource(struct device *dev, phys_addr_t= phys, + size_t size, enum dma_data_direction dir, + unsigned long attrs) +{ + dma_addr_t dev_addr =3D xen_phys_to_dma(dev, phys); + + BUG_ON(dir =3D=3D DMA_NONE); + + if (!dma_capable(dev, dev_addr, size, false)) + return DMA_MAPPING_ERROR; + + return dev_addr; +} + static void xen_swiotlb_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr, size_t size, enum dma_data_direction dir) @@ -426,4 +440,5 @@ const struct dma_map_ops xen_swiotlb_dma_ops =3D { .alloc_pages_op =3D dma_common_alloc_pages, .free_pages =3D dma_common_free_pages, .max_mapping_size =3D swiotlb_max_mapping_size, + .map_resource =3D xen_swiotlb_map_resource, }; --=20 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 11:55:44 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 11:55:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974625.1362429 (Exim 4.92) (envelope-from ) id 1uAozU-000721-1f; Fri, 02 May 2025 11:55:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974625.1362429; Fri, 02 May 2025 11:55:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAozT-00071u-UX; Fri, 02 May 2025 11:55:39 +0000 Received: by outflank-mailman (input) for mailman id 974625; Fri, 02 May 2025 11:55:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAozS-00071o-Hd for xen-devel@lists.xenproject.org; Fri, 02 May 2025 11:55:38 +0000 Received: from mail137-14.atl71.mandrillapp.com (mail137-14.atl71.mandrillapp.com [198.2.137.14]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5bf26161-274c-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 13:55:37 +0200 (CEST) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-14.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4Zpq9z3pB5z705wWq for ; Fri, 2 May 2025 11:55:35 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 759278f8d84e481c831ca3237c1bca05; Fri, 02 May 2025 11:55: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" X-Inumbo-ID: 5bf26161-274c-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1746186935; x=1746456935; bh=8iJrYoI1OSS0dbzs4y01tnMky/wZNEidoo1t7rn/Q/E=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=riO8jYVXqG3nF4j9oFHmL/fZhYjWYvdMjZJEPjzpzZE3KaOHH6Idvo6cCJP/aiyfj td2zW9BvtCOvI4DGxB4uab4eNcbS88+fWFkvAEYMzWrEIGIMfd/x3Ra4jAXFjUk3pV I0D9R+QAsACyR/sNKdnN0pmed6icWWduY4iFMtTEjLbpVZcEoGyPGBpRUbxJJoRaOD L/QD6bCxb5IUYQ5pmFOn1pDIZCVSo35S78svUxfBolbOS5Nd/ETZ+hcxJqE3bE4xEB n5d3Bvmd3dCP/fkTnUaqywnVb7DMzwG2wtiQuQpBnXch4DzRVe952wmzCvmJBpPytO MmuktRNeZeL2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1746186935; x=1746447435; i=teddy.astie@vates.tech; bh=8iJrYoI1OSS0dbzs4y01tnMky/wZNEidoo1t7rn/Q/E=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=0UozmFr3FOWoqWbMzayyfmiEN2a/dtqdPdW8EM91pZTFJXRvt78uuuDS7aIcChdb5 uZKnQDY5ePoaWRey0zZnNm2oe5sirXAb41L0f7/pw7K03yIT5rSMbEcWdSTWFwGkdd nQ123T3KK1wXTyKe3pFnDQ1sORoiAy/qCdMQ3SNvHOyAbRN8lBFh6MW5/Q5bx/w/CI 2N/3A0pY8oTr/XTu0Fe/cTJnkDntL57jwqrCRN0XhWhqs5ObjxiOeh9lv0EWdC4iVa r1j6ObJfxebIqKoWM4TrI7dvOB54QHCecSoJBFm6w526dyMmIBMM4Dfndomx2SrMDp kKbZe2mHwGO+g== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[RFC=20PATCH=201/4]=20xen:=20Introduce=20physaddr=5Fabi=20CDF=20flag?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1746186934215 Message-Id: To: "Jan Beulich" Cc: "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , xen-devel@lists.xenproject.org References: <238c657e-a53c-4eaa-84aa-1d3310b65723@suse.com> In-Reply-To: <238c657e-a53c-4eaa-84aa-1d3310b65723@suse.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.759278f8d84e481c831ca3237c1bca05?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20250502:md Date: Fri, 02 May 2025 11:55:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 30/04/2025 =C3=A0 17:59, Jan Beulich a =C3=A9crit=C2=A0: > On 18.04.2025 16:18, Teddy Astie wrote: >> @@ -745,6 +747,12 @@ static int sanitise_domain_config(struct xen_domctl= _createdomain *config) >> return -EINVAL; >> } >> >> + if ( physaddr_abi && !hvm ) >> + { >> + dprintk(XENLOG_INFO, "Physical address ABI requested for non-HV= M guest"); >> + return -EINVAL; >> + } > > Why this restriction? > physaddr_abi changes how copy_from/to_guest works to make it use GPA instead of GVA. As non-HVM probably means PV guest, it would mean something like PV guest hypercalls uses physical addresses (derived from MFN?) instead of virtual addresses, which would not really be practical for both the guest and the hypervisor. > Jan > Teddy Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Fri May 02 12:02:19 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 12:02:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974642.1362439 (Exim 4.92) (envelope-from ) id 1uAp5p-0000TX-Ql; Fri, 02 May 2025 12:02:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974642.1362439; Fri, 02 May 2025 12: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 1uAp5p-0000TQ-Nt; Fri, 02 May 2025 12:02:13 +0000 Received: by outflank-mailman (input) for mailman id 974642; Fri, 02 May 2025 12:02:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAp5p-0000TK-8J for xen-devel@lists.xenproject.org; Fri, 02 May 2025 12:02:13 +0000 Received: from mail137-14.atl71.mandrillapp.com (mail137-14.atl71.mandrillapp.com [198.2.137.14]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 450daade-274d-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 14:02:08 +0200 (CEST) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-14.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4ZpqKV4m5Jz705qmr for ; Fri, 2 May 2025 12:02:06 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id b7fac139afee4c4bacce4987f340402b; Fri, 02 May 2025 12:02: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" X-Inumbo-ID: 450daade-274d-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1746187326; x=1746457326; bh=OSmJFUI9n/ffWaWhE807TX6P7hyPIRTfSRc9JDcYOJU=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=fFHfqeZnVtllm6Cw2pQ3oSyTNLvkEHvOfA6c4VX0Ip6c/bQ728QoCPX9J8DM36cPS YAU36EDJTTAz2wbU8OJkg3fPvrktOKLgfPDYud2cL3VJ6GlMOnQeA4yn4LicVdWAsJ lfOOJyCV1ZSDTmGxQmasfnltp5IMWrQPeY41nZpycIAprwB1VEQSvpO4hOgcoDJwMI Ds3fsIvHmEq5hJIdsUzX6iydqu7krOw8Db6tUpl6lMN3KQLBqX+MKqxCc5StXzHS4h LvGDQB4G59Nw7N4WIbn4MQY4mcPy5t5daoPHuaMgEaoBxrimOIXz13pkXaDOj+X95H 9G+JsNIKQyjiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1746187326; x=1746447826; i=teddy.astie@vates.tech; bh=OSmJFUI9n/ffWaWhE807TX6P7hyPIRTfSRc9JDcYOJU=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=XLwIwO4INX/zbpFkumapJCexd8Um1FoZRhLaHEw4GAcmX+Gw6VYFa510KZeOv1xKW OMTdTB4EYiIcGsU52opY6enw8Sm4Gx5xscaqoz5wIfucvuEBnLZcmndoW+w6iadHOH thLGQhqO2J+orE3NdVLtyLOwxOeESGZVNrTmQvbGA8CQjoPsQqSKwsdy/IQfi5xuIQ RxkkhrvIub1OvKbqTRGsrJDECiMqZVdXsHc4XxGNcfQIheIiwpu2UsU0djVgwhQE5T 2ljUD57Yf8zErdIoiZd2Lggpc+bJNV4idXVO+DHSTAxGF8MeKwEX/LvyUVwe3cRpEw osbb8CPjpC4Pw== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[RFC=20PATCH=200/4]=20Physical=20address=20hypercall=20ABI=20("HVMv2")?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1746187325373 Message-Id: <84af0f46-752a-4a4f-8a77-6a4b0b7620a0@vates.tech> To: "Julien Grall" , "Jan Beulich" Cc: "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Juergen Gross" , xen-devel@lists.xenproject.org References: In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.b7fac139afee4c4bacce4987f340402b?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20250502:md Date: Fri, 02 May 2025 12:02:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 01/05/2025 =C3=A0 13:14, Julien Grall a =C3=A9crit=C2=A0: > Hi, > > On 22/04/2025 08:45, Jan Beulich wrote: >> On 18.04.2025 16:18, Teddy Astie wrote: >>> In current HVM mode, when a hypercall references a structure in guest >>> memory, >>> it is passed to the hypervisor as its "linear address" (e.g virtual >>> address for >>> the x86 long mode). >>> One of the caveats is that this linear address (GVA) is generally not >>> directly >>> usable by the Xen and needs to be translated from GVA to GPA then >>> HPA. This >>> implies a complex and potentially expensive lookup of the pagetables >>> inside the >>> guest. This can be significant, especially if the P2M cannot use >>> efficiently >>> superpages (or with e.g XSA-304). >>> >>> This proposal introduce a new mode where all addresses used for >>> hypercalls are >>> GPADDR instead of GVADDR, therefore, looking up the HPA related to >>> this GPA >>> only needs a P2M lookup and not looking through the inside-guest >>> pagetables. >>> >>> This mode is opt-in and must be enabled explicitely by the toolstack. >> >> Which I view as a severe downside (leaving aside the PVH Dom0 aspect): >> This way >> a guest needs to be converted all in one go. While doable, it'll be >> increasingly >> risky with the size of the guest kernel code base. > > +1. It is not only the guest kernel, but also the firmware (UEFI, U-boot)= . > > Furthermore, I don't think this can be easily adopted in public cloud > where the admin for Xen and the guest will be different. So any > indication of the ABI would have to come from the guest itself rather > than the configuration. > Makes sense, I am experimenting with a alternative design which requires setting the 30th bit (31th is already used for viridian) of the eax register to indicate the use of this new ABI. Also keeping a CPUID to indicate that the feature is supported by the hypervisor (thus no need to enable it in advance for a guest). > Cheers, > Teddy Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Fri May 02 12:24:53 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 12:24:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974656.1362449 (Exim 4.92) (envelope-from ) id 1uApRf-0003bj-Hs; Fri, 02 May 2025 12:24:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974656.1362449; Fri, 02 May 2025 12: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 1uApRf-0003bc-Ez; Fri, 02 May 2025 12:24:47 +0000 Received: by outflank-mailman (input) for mailman id 974656; Fri, 02 May 2025 12:24:46 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uApRe-0003bW-7i for xen-devel@lists.xenproject.org; Fri, 02 May 2025 12:24:46 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6ad75cc8-2750-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 14:24:39 +0200 (CEST) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-39d83782ef6so2038817f8f.0 for ; Fri, 02 May 2025 05:24:39 -0700 (PDT) Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a099b0ff8esm2027366f8f.79.2025.05.02.05.24.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 May 2025 05:24: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" X-Inumbo-ID: 6ad75cc8-2750-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1746188679; x=1746793479; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=58mBo+tgccnPMmtKhvfl3xIuF/MtwOIQVl3jnF9O/YM=; b=saI90l39YVyhyPgBYr0kQ0zHSLhB/mvz1rbTm0y4dtqHcNR5lnEj/lHg4kwFMppBWi 63N+kfLX2IChr5uyBMaP6aRLkZ9l/fhf1aGrK0mCN3Q9UEPMY7x29YaKn2rIhWDmFoN0 WDY4eb3pWXDcW6VC6GTvYkdwhh/crGOBgx8Fo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746188679; x=1746793479; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=58mBo+tgccnPMmtKhvfl3xIuF/MtwOIQVl3jnF9O/YM=; b=TYJyYwqYxz/4kZ8M/8aEk+ae09iq2FwwqGOKi9f0fxQLfqQZ5VIOgtAIZIViGpZPEC mHfZl12I+2SBnoYf51GqRWwS4DPRe3dnDZTqW1omshb6Z/DSdZHx04GE215Zx+XBakwN sCQ0FEfgDoFa8UeOHd6nHnRGG+2OKWrROvAOXBr7lm7FBQ796kc5Ou8fU+MNw8wWnoM3 jzfjzdQ7f4pHkKpYLTwjle6EpDmUsryNn6ahT9p2AGy018vzatwyuYD+eVMZXAcczeQ5 7NjsXBaCjj+LcNu+UPzE2LftgTDwo8q9oGS6Mx8Bu7ta1GOJBx5IGAfd0mtfwIgxMs4W cyWQ== X-Forwarded-Encrypted: i=1; AJvYcCXguuDkgWlr6qUheqS366XOvjQhoN6AQ2UaVzJVEudhtExk1LlXp9F5bDxEhYBtfuf8+HB6RmNo4W4=@lists.xenproject.org X-Gm-Message-State: AOJu0YzuJZNfO5ukTJq7SiL5e74WNMvid57dP5H9Xhkyy9pLY/doHmKJ K6Zq9m5Q9/uJokgNRdnx+i0ZwdnAh+dCVgajRQangObJunpFD2/puIsihddjfxU= X-Gm-Gg: ASbGncswJtMYXbo6EQmUTAmZQr+vKzLZAXyoplWX2ahYtKR5aKQpAnorFx6Bddw8KTQ fHpyWo0/FW3clAyH+Fvldx0aZXLmDlT7pMqwl/dySrXXYCsv8NDXIKV451LQZXgrXT/Ubr4vFQ+ PT4LkAcxjJECZoaRf5mcn9tfcRAXyXqSdtUHZdNovzNhIHhaOXoKkRPBeKyfbbQ1byxMnrwl19z g0CIrDcnGIwa3orvOvklmTCe+ijhGa1Ty5xqeeFyaEzAVnmlVJ6SY88gDDQjFsCQb4VMEYxBGJh W34whCPTXZ4v2DRCuRu768oPmUCDcLr0H4qA0IgP0yEaXmQO5MOEtH+KvtgbICGJnl+pzvZg9nf l4Iel6A== X-Google-Smtp-Source: AGHT+IHBEH9VvRM6uc4kTAjJIqWeGWcegsfx/Lgxob5vRWvQyMSNiifsMySmu6b9hCifSMaC/zFemA== X-Received: by 2002:a05:6000:4592:b0:391:386d:5971 with SMTP id ffacd0b85a97d-3a094038f0dmr4295851f8f.14.1746188678776; Fri, 02 May 2025 05:24:38 -0700 (PDT) Message-ID: Date: Fri, 2 May 2025 13:24:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/vpic: Improve bitops usage To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250501233042.762295-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 On 02/05/2025 9:04 am, Jan Beulich wrote: > On 02.05.2025 01:30, Andrew Cooper wrote: >> * For vpic_get_priority(), introduce a common ror8() helper in plain C. One >> thing that I can't persuade the compiler to realise is that a non-zero >> value rotated is still non-zero, so use __builtin_clz() to help the >> optimiser out. >> >> * vpic_ioport_write() can be simplified to just for_each_set_bit(), which >> avoids spilling pending to the stack each loop iteration. Changing pending >> from unsigned int to uint8_t isn't even strictly necessary given the >> underlying types of vpic->isr and vpic->irr, but done so clarity. >> >> No functional change. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich Thanks. > >> One thing I can't seem to avoid is GCC zero extending the result of ror8() >> before passing it to BSF/TZCNT. Then again, that's very specific to uint8_t, >> and x86's preserving behaviour on byte writes. > It can't know that the upper bits are "don't care" here, related to the aspect > above (it not inferring non-zero of the result of the rotate when the input is > non-zero). Hmm, I suppose so. > And I expect it would be too much of a special case to warrant > getting all of this accounted for, just to remove the zero-ext. > > For this specific case we might be able to cheat, but I'm unsure that's worth > it either (and I also haven't tried whether it actually has the intended > effect): > > val8 = ror8(mask, vpic->priority_add); > asm ( "" : "=r" (val32) : "0" (val8) ); > return __builtin_ctz(val32); It's one zero-extend.  I was only curious because I was looking in detail at the code generation, but it's not something I'm losing sleep over. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri May 02 12:48:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 12:48:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974670.1362460 (Exim 4.92) (envelope-from ) id 1uApoc-0006lg-C3; Fri, 02 May 2025 12:48:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974670.1362460; Fri, 02 May 2025 12:48:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uApoc-0006lZ-87; Fri, 02 May 2025 12:48:30 +0000 Received: by outflank-mailman (input) for mailman id 974670; Fri, 02 May 2025 12:48:29 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uApob-0006lT-CF for xen-devel@lists.xenproject.org; Fri, 02 May 2025 12:48:29 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bc074605-2753-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 14:48:24 +0200 (CEST) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5efe8d9eb1eso3251392a12.0 for ; Fri, 02 May 2025 05:48: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 4fb4d7f45d1cf-5fa777c8b70sm1200519a12.29.2025.05.02.05.48.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 May 2025 05:48: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" X-Inumbo-ID: bc074605-2753-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1746190103; x=1746794903; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=kfROYIzqlybIUGbRuA6q37zGqiTVAb0hovsYhAl8wuA=; b=RlZB6PP5f3nLw65XJi9JJ8V+BAkXj2cO5pA/6cjMu+4IaMMCwSrWzjVT4wlRyUEjpa QoXq0mFhY531SciK1mVfJ8q4jpRX9mWjcRNcZfnbMcZ7bF0BTKwbsZrW/kCGD8oPgy0Q 6lxA9iiIuu2ektj4aUpNTbYo19JEsQEhtT0OYMDMEiAWZC9mTkNVHwWgJyBby+QLir4x ulK/IPQYEerc6Az1fJo7UjuIXqxdNN7S5VkrDvk3i6mScc3P37BvZ+MlU4Mz96ji3okT albRiyEW4D/Q7ZCUuVXsSVQNrIqE5WHGTjI6z88fv3dsTilHBUm6UpUE0nMyOiKGd7xx jE2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746190103; x=1746794903; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=kfROYIzqlybIUGbRuA6q37zGqiTVAb0hovsYhAl8wuA=; b=aAayDs+MAoq3Vu3S3eOTGGoanFtQay/A5tZv5Oh+UDD1hVfseoUlWY4kAuytYB4NwS PKDOLUleglDkKuYNVANGapfEir5hjNH87kYhqW6OzwwQps/l2X8RP9qPb61JI20KUKFY N028aQkeWxfihI71txl4hUabwvKxOvUpjns3Bx6wLiJ6SHvZ9BAcOLgHwVRJVcAK/Q/S rd9ozcB7UxlfxEGjz6QwGwL+R4wCQcJHCN9zbUleM09YO9OJyFnN226iFZgRz3AkzH/v 5wGliCz+4dXE7u6/rx3321rNB8v1r4O2vxczOJ6Xu0VitdBCqMO59UBtYUGzk3rMILHF 1RbA== X-Forwarded-Encrypted: i=1; AJvYcCUSHL5cTDpbB13roBEEYTQcZnyXxGaTRAj0UxrK2qpiGkt+THJkXWhcvOK3E+HKhcJ9CO1Is1scsyQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YyKCC1CAkSEr5tBY6fhGIcbRSKdTiP9ntqP4HWvuWgNMwbmKvOV fImPHPQA1HM2O8i4MjIKIMNqmR2E+1lFgfQihpu7QNI34ebMMJU2XV7sIO7VaXRhm1aMdx8ScV0 = X-Gm-Gg: ASbGncubSEhyciDk6I9vp+JmW5PXbRPE0oSZnAn+XTceEoorfFeExDdHugIzyCQtiPu 55sN8n/QQtoM3Ptr8iXLUPSakuFZvod/50C12NqdLGgSYhYYP1u0pROEdipE1cArCanE2Fn8cHe mGjD7QdFyQYjefLbvQqh1jT9/zTcNBUklzWZB4ZnMcpVEHwh6o1Z4+XQKpRkIK9AZM8GANigo4u 0C4tmxI29MPxbeow3BNiegH5aEkEeQ3eRIlxhUeeShb07A+kNYsKj4MPDiXcO5dKo33NWSdokx0 v36UdoElQ4+3CFAD95m3eFsVIX600acf5MaK4DiUMdAJj0y20qih37PA2+pPe1SvO/cMo7FhIY+ vwNZ9ggDx7oYNcXF1BPm1M2NCcQ== X-Google-Smtp-Source: AGHT+IGA6jRzWNhQw7ZbGZdHsyw6MwEtvPi4Ixp9YTzWHwVJXptNOfDLpxxmbI0JVLuZobITuwrXbw== X-Received: by 2002:a05:6402:5216:b0:5f6:22ca:8aae with SMTP id 4fb4d7f45d1cf-5f919836912mr5313383a12.2.1746190103472; Fri, 02 May 2025 05:48:23 -0700 (PDT) Message-ID: <677b6100-a53d-4ac1-aa88-9ed988f7b84b@suse.com> Date: Fri, 2 May 2025 14:48:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/4] xen: Introduce physaddr_abi CDF flag 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: <238c657e-a53c-4eaa-84aa-1d3310b65723@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 On 02.05.2025 13:55, Teddy Astie wrote: > Le 30/04/2025 à 17:59, Jan Beulich a écrit : >> On 18.04.2025 16:18, Teddy Astie wrote: >>> @@ -745,6 +747,12 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config) >>> return -EINVAL; >>> } >>> >>> + if ( physaddr_abi && !hvm ) >>> + { >>> + dprintk(XENLOG_INFO, "Physical address ABI requested for non-HVM guest"); >>> + return -EINVAL; >>> + } > >> >> Why this restriction? >> > > physaddr_abi changes how copy_from/to_guest works to make it use GPA > instead of GVA. As non-HVM probably means PV guest, it would mean > something like PV guest hypercalls uses physical addresses (derived from > MFN?) Machine addresses, yes (hence MFN). If it was PFNs / (pseudo-)physical addresses, ... > instead of virtual addresses, which would not really be practical > for both the guest and the hypervisor. ... I'd maybe agree here. Jan From xen-devel-bounces@lists.xenproject.org Fri May 02 13:13:39 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 13:13:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974687.1362478 (Exim 4.92) (envelope-from ) id 1uAqCv-0002sx-Fz; Fri, 02 May 2025 13:13:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974687.1362478; Fri, 02 May 2025 13:13: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 1uAqCv-0002sq-DA; Fri, 02 May 2025 13:13:37 +0000 Received: by outflank-mailman (input) for mailman id 974687; Fri, 02 May 2025 13:13:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAqCt-0002sH-Uf for xen-devel@lists.xenproject.org; Fri, 02 May 2025 13:13:35 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 40945ed9-2757-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 15:13:34 +0200 (CEST) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-39ee5ac4321so2088675f8f.1 for ; Fri, 02 May 2025 06:13:34 -0700 (PDT) Received: from localhost.localdomain (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-441b8a31576sm43819915e9.37.2025.05.02.06.13.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 06:13: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" X-Inumbo-ID: 40945ed9-2757-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1746191614; x=1746796414; 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; bh=qoZI407B5Po4OSQsJUN8qnspeE+Spjgmrm6XxhEYtzs=; b=E1qJh5xW3OdeZLnDQyAg1GV9rHMIY12ZHPwoItRrv6OoEkjEfYCL872KmtRF1cpbyF AWG60mFI6xB8Oi8bFt8Qtu2psKip1AhImaj01O+N4XoeXmQX9S7z7IjVZaOz5wQimKGI vRUZdsXeLkzAWRo2UBcjLQa8jgl1ZbUnRJkIA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746191614; x=1746796414; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qoZI407B5Po4OSQsJUN8qnspeE+Spjgmrm6XxhEYtzs=; b=A4+H7eFTaDUWzeMOOguXKP+fppXPDQJfmJRDW0EGzT3caCnWXInw9FDIYRYtEH3o1O h5lqgBNH2+Pyzty4HNiThuc/4lq9Tz099EmeWtWowUpOPYdGgXXEeGHIEC48kn7f0Nnd 4l1TdWRa6EXPZmcPNuqEL9v0McYVOWOYSBbrK+e7cTObK+O/KLlRHTyQ+fgNfi+Qnmfq pfHKv4xCX7M6FWghimjnraNLqHqkxZVimzxdnw/HdxU2qjblwH92g+71lNz0sQqyj991 T0yweIA/is2rfP1svs3zBWJh3ZZ74X2rrA23HifYjNmmqIURxt99/Ce2SYzxtFR4O327 eF4g== X-Gm-Message-State: AOJu0Yx27fIZEAmpU9feDjoHGO6cwVkXKOCmCtO2bOWNKzcuri1YvAHN 2VMFqxI2HS2qqxpSmgPJtl19qA9qAkVX2yXMJpOeEQVEl4Vr00o8XR9iG6UEdGit2XCoNDn4e93 6 X-Gm-Gg: ASbGncsrYEg7znsKW2GK+Kci2Me+2r0Aj7w8qHvEcjI5dBaurABskcjC4zGQYXW8f24 Q34YqbvYuGVyqs2dBjcBFjTp5RpjJ12rpJhs9Ms/JL5iXIjuRxS3qVc9wZjjkq3JGl210uazg6A SfUlARUcgwprBv8Py60Fkil3SaB6ITQREsmTIFX5ts5FuRqGufaE13K0ts2qN3N+MEpgbZRWW1a shaEAxVQU+KugMun0b4sNjAvIFkwVw5nSETozz37iMUuN6sgZ49ozsLOWgU08uaI3cldfaiBlTJ IHKj9v7k/BX/1/JJ7bNTuIqafJvpJKx5dowgO7EhzoO4g+Amo/u+cMKcgLZtA2qnr5e9wiFY3yP Zxue5IhYRsXu00g== X-Google-Smtp-Source: AGHT+IFgaP9xpJnef20Ys3/kvKj36XXf6xnVxR4I709P3qotG9L4L7lyXxltQ321U0NjrtSuBQEA/Q== X-Received: by 2002:a5d:598b:0:b0:3a0:8495:d66f with SMTP id ffacd0b85a97d-3a099ad9a6cmr1801873f8f.23.1746191614098; Fri, 02 May 2025 06:13:34 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86/mm: Improve bitops in vcpumask_to_pcpumask() Date: Fri, 2 May 2025 14:13:31 +0100 Message-Id: <20250502131331.813701-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 This loop is for_each_set_bit() in disguise. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné More detailed analysis: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-46 (-46) Function old new delta vcpumask_to_pcpumask 519 473 -46 Re-shifting 1 just to clear it is horrible code generation. While the ffsl() is abtracted away, it doesn't logically move in terms of the loop position. All that is happening is a (more efficient) clearing is moved to the post condition, and 3/4 of a cacheline of logic disappears. --- xen/arch/x86/mm.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 0b787ba55312..66c15a3c864f 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -3411,7 +3411,7 @@ int new_guest_cr3(mfn_t mfn) static int vcpumask_to_pcpumask( struct domain *d, XEN_GUEST_HANDLE_PARAM(const_void) bmap, cpumask_t *pmask) { - unsigned int vcpu_id, vcpu_bias, offs; + unsigned int vcpu_bias, offs; unsigned long vmask; struct vcpu *v; bool is_native = !is_pv_32bit_domain(d); @@ -3432,12 +3432,10 @@ static int vcpumask_to_pcpumask( return -EFAULT; } - while ( vmask ) + for_each_set_bit ( vcpu_id, vmask ) { unsigned int cpu; - vcpu_id = ffsl(vmask) - 1; - vmask &= ~(1UL << vcpu_id); vcpu_id += vcpu_bias; if ( (vcpu_id >= d->max_vcpus) ) return 0; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri May 02 13:13:39 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 13:13:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974686.1362469 (Exim 4.92) (envelope-from ) id 1uAqCs-0002ed-5s; Fri, 02 May 2025 13:13:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974686.1362469; Fri, 02 May 2025 13: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 1uAqCs-0002eW-39; Fri, 02 May 2025 13:13:34 +0000 Received: by outflank-mailman (input) for mailman id 974686; Fri, 02 May 2025 13:13:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAqCq-0002eQ-3P for xen-devel@lists.xenproject.org; Fri, 02 May 2025 13:13:32 +0000 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3a676de7-2757-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 15:13:26 +0200 (CEST) Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 May 2025 06:13:23 -0700 Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.135]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 May 2025 06:13:07 -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" X-Inumbo-ID: 3a676de7-2757-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1746191606; x=1777727606; h=from:date:to:cc:subject:in-reply-to:message-id: references:mime-version:content-id; bh=8rjzfX3W2W2Ua3bnqMyXei5mk/ntSXdZx8V9rkAjM0A=; b=BTvvpj3DezlwCHQC1KFttZmojAwaNu1IkWPEKX0tReVpjjMdMMG9sNSU UMNr9jo9DUeRJUDOhKaWz0KIXzENalaDnanW5wdmxa9+8RK50s53KYViK F8o+IRLhx7x4eKmNrKwru6sVwMRoBfg9QMLlkdC9bEjbVDfX5gtVoSj4n khOR9brSiJk0kqxr/vPD3Td8FMlTq++vdCPUNeBW3TThWq5TNqy3nkX4X jcuhIfiKo6BDxkIPGv3kJLSfoMcMVGKhGDyaoUKcRkbQwrQObPNRY4gcf mzVnw8dgCGN4up1ZrXwI3LMrPowdYknFuwtg30dyD5erv81s+iw2WgSlL Q==; X-CSE-ConnectionGUID: XFg2xvHqTpiS5ZnSYg4w9g== X-CSE-MsgGUID: 4RDNRcO8RjGdveZPB2p+/w== X-IronPort-AV: E=McAfee;i="6700,10204,11421"; a="59233289" X-IronPort-AV: E=Sophos;i="6.15,256,1739865600"; d="scan'208";a="59233289" X-CSE-ConnectionGUID: uqJeJQZ9QjyJ9pDg+lbEpA== X-CSE-MsgGUID: eaKgRDz1TzO6Du8usPzXEw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,256,1739865600"; d="scan'208";a="135599266" From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Date: Fri, 2 May 2025 16:13:03 +0300 (EEST) To: "Xin Li (Intel)" , mingo@redhat.com cc: LKML , kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-pm@vger.kernel.org, linux-edac@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, Netdev , platform-driver-x86@vger.kernel.org, tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, acme@kernel.org, jgross@suse.com, andrew.cooper3@citrix.com, peterz@infradead.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, wei.liu@kernel.org, ajay.kaher@broadcom.com, bcm-kernel-feedback-list@broadcom.com, tony.luck@intel.com, pbonzini@redhat.com, vkuznets@redhat.com, seanjc@google.com, luto@kernel.org, boris.ostrovsky@oracle.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, dapeng1.mi@linux.intel.com Subject: Re: [PATCH v4A 01/15] x86/msr: Add missing includes of In-Reply-To: <20250501054241.1245648-1-xin@zytor.com> Message-ID: References: <20250501054241.1245648-1-xin@zytor.com> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323328-2124274657-1746191047=:958" Content-ID: <69d4ead6-fa09-8594-add2-0d027d3e7e6c@linux.intel.com> This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-2124274657-1746191047=:958 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <914dd26d-9889-125a-917d-3b9acfbc7938@linux.intel.com> On Wed, 30 Apr 2025, Xin Li (Intel) wrote: > For some reason, there are some TSC-related functions in the MSR > header even though there is a tsc.h header. >=20 > To facilitate the relocation of rdtsc{,_ordered}() from > to and to eventually eliminate the inclusion of > in , add to the source files that > reference definitions from . >=20 > Signed-off-by: Xin Li (Intel) > Acked-by: Dave Hansen > Acked-by: Peter Zijlstra (Intel) > Acked-by: Ilpo J=E4rvinen > --- >=20 > Change in v4A: > *) Use "git grep -l -e $PATTERN | grep -v -f <(git grep -l -e 'asm/msr\.h= ')" > to ensure ALL required *direct* inclusion of (Ilpo J=E4rvi= nen). >=20 > Change in v4: > *) Add missing includes in a different patch (Ilpo J=E4rvinen). > *) Add all necessary direct inclusions for msr.h (Ilpo J=E4rvinen). >=20 > Change in v3: > * Add a problem statement to the changelog (Dave Hansen). > --- > arch/x86/coco/sev/core.c | 1 + > arch/x86/events/amd/core.c | 1 + > arch/x86/events/amd/ibs.c | 1 + > arch/x86/events/amd/iommu.c | 2 ++ > arch/x86/events/amd/lbr.c | 1 + > arch/x86/events/amd/power.c | 1 + > arch/x86/events/core.c | 1 + > arch/x86/events/intel/bts.c | 1 + > arch/x86/events/intel/core.c | 1 + > arch/x86/events/intel/cstate.c | 1 + > arch/x86/events/intel/ds.c | 1 + > arch/x86/events/intel/knc.c | 1 + > arch/x86/events/intel/p4.c | 1 + > arch/x86/events/intel/p6.c | 1 + > arch/x86/events/intel/pt.c | 1 + > arch/x86/events/intel/uncore.c | 1 + > arch/x86/events/intel/uncore_discovery.c | 1 + > arch/x86/events/intel/uncore_nhmex.c | 1 + > arch/x86/events/intel/uncore_snb.c | 1 + > arch/x86/events/intel/uncore_snbep.c | 1 + > arch/x86/events/msr.c | 2 ++ > arch/x86/events/perf_event.h | 1 + > arch/x86/events/probe.c | 2 ++ > arch/x86/events/rapl.c | 1 + > arch/x86/events/utils.c | 1 + > arch/x86/events/zhaoxin/core.c | 1 + > arch/x86/hyperv/hv_apic.c | 1 + > arch/x86/hyperv/hv_init.c | 1 + > arch/x86/hyperv/hv_spinlock.c | 1 + > arch/x86/hyperv/hv_vtl.c | 1 + > arch/x86/hyperv/ivm.c | 1 + > arch/x86/include/asm/fred.h | 1 + > arch/x86/include/asm/kvm_host.h | 1 + > arch/x86/include/asm/microcode.h | 2 ++ > arch/x86/include/asm/mshyperv.h | 1 + > arch/x86/include/asm/msr.h | 1 + > arch/x86/include/asm/resctrl.h | 2 ++ > arch/x86/include/asm/suspend_32.h | 1 + > arch/x86/include/asm/suspend_64.h | 1 + > arch/x86/include/asm/switch_to.h | 2 ++ > arch/x86/kernel/acpi/sleep.c | 1 + > arch/x86/kernel/amd_nb.c | 1 + > arch/x86/kernel/apic/apic.c | 1 + > arch/x86/kernel/apic/apic_numachip.c | 1 + > arch/x86/kernel/cet.c | 1 + > arch/x86/kernel/cpu/amd.c | 1 + > arch/x86/kernel/cpu/aperfmperf.c | 1 + > arch/x86/kernel/cpu/bus_lock.c | 1 + > arch/x86/kernel/cpu/feat_ctl.c | 1 + > arch/x86/kernel/cpu/hygon.c | 1 + > arch/x86/kernel/cpu/mce/inject.c | 1 + > arch/x86/kernel/cpu/microcode/core.c | 1 + > arch/x86/kernel/cpu/mshyperv.c | 1 + > arch/x86/kernel/cpu/resctrl/core.c | 1 + > arch/x86/kernel/cpu/resctrl/monitor.c | 1 + > arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 1 + > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 1 + > arch/x86/kernel/cpu/sgx/main.c | 1 + > arch/x86/kernel/cpu/topology.c | 1 + > arch/x86/kernel/cpu/topology_amd.c | 1 + > arch/x86/kernel/cpu/tsx.c | 1 + > arch/x86/kernel/cpu/zhaoxin.c | 1 + > arch/x86/kernel/fpu/core.c | 1 + > arch/x86/kernel/fpu/xstate.c | 1 + > arch/x86/kernel/fpu/xstate.h | 1 + > arch/x86/kernel/fred.c | 1 + > arch/x86/kernel/hpet.c | 1 + > arch/x86/kernel/kvm.c | 1 + > arch/x86/kernel/paravirt.c | 1 + > arch/x86/kernel/process.c | 1 + > arch/x86/kernel/process_64.c | 1 + > arch/x86/kernel/trace_clock.c | 2 +- > arch/x86/kernel/traps.c | 1 + > arch/x86/kernel/tsc.c | 1 + > arch/x86/kernel/tsc_sync.c | 1 + > arch/x86/kvm/svm/avic.c | 1 + > arch/x86/kvm/svm/sev.c | 1 + > arch/x86/kvm/svm/svm.c | 1 + > arch/x86/kvm/vmx/nested.c | 1 + > arch/x86/kvm/vmx/pmu_intel.c | 1 + > arch/x86/kvm/vmx/sgx.c | 1 + > arch/x86/kvm/vmx/vmx.c | 1 + > arch/x86/lib/insn-eval.c | 1 + > arch/x86/lib/kaslr.c | 2 +- > arch/x86/mm/mem_encrypt_identity.c | 1 + > arch/x86/mm/tlb.c | 1 + > arch/x86/pci/amd_bus.c | 1 + > arch/x86/pci/mmconfig-shared.c | 3 ++- > arch/x86/power/cpu.c | 1 + > arch/x86/realmode/init.c | 1 + > arch/x86/virt/svm/sev.c | 1 + > arch/x86/xen/enlighten_pv.c | 1 + > arch/x86/xen/pmu.c | 1 + > arch/x86/xen/suspend.c | 1 + > drivers/accel/habanalabs/common/habanalabs_ioctl.c | 2 -- > drivers/acpi/acpi_extlog.c | 1 + > drivers/acpi/processor_perflib.c | 1 + > drivers/acpi/processor_throttling.c | 6 +++++- > drivers/char/agp/nvidia-agp.c | 1 + > drivers/cpufreq/amd-pstate-ut.c | 2 ++ > drivers/cpufreq/elanfreq.c | 1 - > drivers/cpufreq/sc520_freq.c | 1 - > drivers/crypto/ccp/sev-dev.c | 1 + > drivers/edac/amd64_edac.c | 1 + > drivers/edac/ie31200_edac.c | 1 + > drivers/edac/mce_amd.c | 1 + > drivers/hwmon/hwmon-vid.c | 4 ++++ > drivers/idle/intel_idle.c | 1 + > drivers/misc/cs5535-mfgpt.c | 1 + > drivers/net/vmxnet3/vmxnet3_drv.c | 4 ++++ > drivers/platform/x86/intel/ifs/core.c | 1 + > drivers/platform/x86/intel/ifs/load.c | 1 + > drivers/platform/x86/intel/ifs/runtest.c | 1 + > drivers/platform/x86/intel/pmc/cnp.c | 1 + > drivers/platform/x86/intel/speed_select_if/isst_if_common.c | 1 + > .../platform/x86/intel/speed_select_if/isst_if_mbox_msr.c | 1 + > drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c | 1 + > drivers/platform/x86/intel/turbo_max_3.c | 1 + > .../platform/x86/intel/uncore-frequency/uncore-frequency.c | 1 + > drivers/powercap/intel_rapl_common.c | 1 + > drivers/powercap/intel_rapl_msr.c | 1 + > .../intel/int340x_thermal/processor_thermal_device.c | 1 + > drivers/thermal/intel/intel_tcc_cooling.c | 1 + > drivers/thermal/intel/x86_pkg_temp_thermal.c | 1 + > drivers/video/fbdev/geode/display_gx.c | 1 + > drivers/video/fbdev/geode/gxfb_core.c | 1 + > drivers/video/fbdev/geode/lxfb_ops.c | 1 + > 127 files changed, 142 insertions(+), 8 deletions(-) >=20 > diff --git a/arch/x86/kernel/trace_clock.c b/arch/x86/kernel/trace_clock.= c > index b8e7abe00b06..708d61743d15 100644 > --- a/arch/x86/kernel/trace_clock.c > +++ b/arch/x86/kernel/trace_clock.c > @@ -4,7 +4,7 @@ > */ > #include > #include > -#include > +#include Does this change belong to this patch? It might even cause a build failure until the second patch which moves=20 the tsc related things to the other file (unless there's indirect include= =20 path to asm/msr.h). > diff --git a/arch/x86/lib/kaslr.c b/arch/x86/lib/kaslr.c > index a58f451a7dd3..b5893928d55c 100644 > --- a/arch/x86/lib/kaslr.c > +++ b/arch/x86/lib/kaslr.c > @@ -8,7 +8,7 @@ > */ > #include > #include > -#include > +#include Same thing here. > #include > #include > #include > diff --git a/drivers/accel/habanalabs/common/habanalabs_ioctl.c b/drivers= /accel/habanalabs/common/habanalabs_ioctl.c > index 8729a0c57d78..dc80ca921d90 100644 > --- a/drivers/accel/habanalabs/common/habanalabs_ioctl.c > +++ b/drivers/accel/habanalabs/common/habanalabs_ioctl.c > @@ -17,8 +17,6 @@ > #include > #include > =20 > -#include > - I suggested making a separate patch out of these removals. Currently you=20 do them without any clear warning in the changelog which only talks about= =20 adding asm/msr.h. > diff --git a/drivers/acpi/processor_throttling.c b/drivers/acpi/processor= _throttling.c > index 00d045e5f524..ecd7fe256153 100644 > --- a/drivers/acpi/processor_throttling.c > +++ b/drivers/acpi/processor_throttling.c > @@ -18,9 +18,13 @@ > #include > #include > #include > +#include > #include > #include > -#include > +#include ??? > +#ifdef CONFIG_X86 > +#include > +#endif I really appreciate you took the effort to do this change the correct way! :-) -- i. --8323328-2124274657-1746191047=:958-- From xen-devel-bounces@lists.xenproject.org Fri May 02 14:02:20 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 14:02:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974717.1362489 (Exim 4.92) (envelope-from ) id 1uAqxs-0001s8-0H; Fri, 02 May 2025 14:02:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974717.1362489; Fri, 02 May 2025 14:02: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 1uAqxr-0001s1-Td; Fri, 02 May 2025 14:02:07 +0000 Received: by outflank-mailman (input) for mailman id 974717; Fri, 02 May 2025 14:02:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAqxq-0001rv-PN for xen-devel@lists.xenproject.org; Fri, 02 May 2025 14:02:06 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0756664d-275e-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 16:02:05 +0200 (CEST) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-acbb85ce788so476211466b.3 for ; Fri, 02 May 2025 07:02: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 a640c23a62f3a-ad1891a3cf1sm55416466b.68.2025.05.02.07.02.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 May 2025 07: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" X-Inumbo-ID: 0756664d-275e-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1746194525; x=1746799325; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=YO5zmwpmbepxwvUEifQhQ9pOCIdLe74vn5s/qdroAmE=; b=WFfU6N4p6tlffuxdi1cpmN3GIZVjfGm+tlDPWPrhRcPbK5uLvnTXpYRRfetyeESp5j TE1SYe5L91rVULVUzYjukLME9Bx/GSjs0yvP+lIKIlByQFNJakMkOIRE/k724Nh5tYY0 3G61wyLQyW0/6Cd8dp6Qdifp/c5x6pAifjew3tVBxynVHZyEGaoP8iq/YRMvF+A4aFwi heETvFvfiRn+FeOHrGEOT32wHTTn0beSUrW+FZNCcFqZpWOY+8+eo3poUiVA5EDkVLe8 x7RljGDRoU8FLuHXWCucj5tVTmpb17rhp0saQXCWVqA9jDHz33QuBon0+hWwsHxumh5z GTfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746194525; x=1746799325; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YO5zmwpmbepxwvUEifQhQ9pOCIdLe74vn5s/qdroAmE=; b=RqeBKwJWS28keCMKLLCEALibGNViN7+VnCIq9RQGYtkUIU9q+uDZdWiwgOGf0GWuKD qbAraPLl0ZfCXvZSbZqT5zihQtPCJDhIhueoFNrcamAQmJVu2KiUTvsQKOnUBoGlWO9c 8xxWJKYhu8oi3VAca5Lnt6r2AHPZgiWX4CihescjlyE+IOpcJwbfQe59VJA1MDElDYtw 4QLKOYjOKOkH2DzXrwWiGdMuLYI9/GUSYCMEbow2W7LSDVSRl3tDboWJmBMPhlkSGAcw jAkQBrSf5V0X1uMJk8fZzyY1s7K3iKsFp9AZKPZrxQcYhO0SaPVo3Jd0mHFeyWSzFi7q g3ng== X-Forwarded-Encrypted: i=1; AJvYcCXyJrI5TSG7GCDauFab/LhpSenuBTvtZ+TKm7acFOGirkfXJd4LL3O36Tffvnn5OH4phwCwh4UXWz4=@lists.xenproject.org X-Gm-Message-State: AOJu0YxxsIBbz/YYJGu7L7Lrv6Oj4p9Iw1d4ouSpCp5msP9fOQGm49T5 ORD3DZ4ouHVVMOg1rVnKZkIk1fHirsBUTGGhinLRTGAio/QEeImogQJkLGcZvw== X-Gm-Gg: ASbGncsPt8jLqNazj0HmU7b4uKT73K0XJYCVPc2Ofr6L+PYrjrjheuXzYHQP9EA71mY FrxlX/NHgIa/tNiqMvHmvcAjK/BgZu02gyDPmkQYuTMd1FVuXELHhg9mKAwaA9A3JHnLxS0j460 K6eySlYN3h0GAUBjbmL8Yq9/JQ8LLMD+RIonCdg2Gd+6sJcWp3o4lC9V9hRW0bvD6JOCjkHqzun m9bbKQ77bnZLoYlVPCmZya4iJ2PRRq8nzxsPFQzV1Ge8Kx8s9y/HCWzSJOqsc+1GaQkS2YyRpfK 5U3CbJVSEEoRhEKeLJ7YhXygf1Hs3kx01CmBC1EKgCZv1dXx1Xne7zk4BLYJ92H9e4H0kaW5YI8 tj+ACUjagIPHCXbZ2ggqn2+z/7Q== X-Google-Smtp-Source: AGHT+IHKAlEURCmptFJ+byoO6avNaqN9eGZ3CwX5LSoEA/jRUAids5zcsoeA0shdXCXU4+a6ISVRMQ== X-Received: by 2002:a17:907:d503:b0:ace:52f6:8500 with SMTP id a640c23a62f3a-ad17aeee406mr304549466b.45.1746194524726; Fri, 02 May 2025 07:02:04 -0700 (PDT) Message-ID: <4f37480c-fed3-48dd-956e-b8d6b29a1ea3@suse.com> Date: Fri, 2 May 2025 16:02:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mm: Improve bitops in vcpumask_to_pcpumask() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20250502131331.813701-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: <20250502131331.813701-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.05.2025 15:13, Andrew Cooper wrote: > This loop is for_each_set_bit() in disguise. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Fri May 02 14:14:05 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 14:14:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974728.1362498 (Exim 4.92) (envelope-from ) id 1uAr9L-0003iO-VO; Fri, 02 May 2025 14:13:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974728.1362498; Fri, 02 May 2025 14:13: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 1uAr9L-0003iH-S9; Fri, 02 May 2025 14:13:59 +0000 Received: by outflank-mailman (input) for mailman id 974728; Fri, 02 May 2025 14:13:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAr9K-0003iB-D7 for xen-devel@lists.xenproject.org; Fri, 02 May 2025 14:13:58 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11olkn20830.outbound.protection.outlook.com [2a01:111:f403:2c16::830]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id aeb660ac-275f-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 16:13:57 +0200 (CEST) Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23) by IA1PR02MB9158.namprd02.prod.outlook.com (2603:10b6:208:42d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Fri, 2 May 2025 14:13:49 +0000 Received: from SN6PR02MB4157.namprd02.prod.outlook.com ([fe80::cedd:1e64:8f61:b9df]) by SN6PR02MB4157.namprd02.prod.outlook.com ([fe80::cedd:1e64:8f61:b9df%3]) with mapi id 15.20.8699.022; Fri, 2 May 2025 14:13: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" X-Inumbo-ID: aeb660ac-275f-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MxcRbFILndfXwII9UXMBr1c+xXfsvRXh584O1ucvmg6EHyeOZ9/CDCSHgQHBrJT4qHMqDitX1ZBrlW55vO9OEo7ftszcQw/Z20kKAi1FuwG70NtBAbkw85qMYEVHz2Im96kG3trjzjp+NZZYUY9v+eN5F2cHlbS7Bnvcvg8Ai4wugByqHRiX6G3lfCZsV/jBX3fET1ca/qXr30VzyODTkHtrX7k7FBAiPCf5Fc6alN/jnhNEjlJCK1PBEBvfQy6d5m/xn7xhuFDfiSKpM8lL4lDP24mVV5r5fCDxQkOUoaU+1G2NB8g/gosTVyWm/h2r2oTWHinWuP1eptj6AjWazg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SXX+mnG2WHo9t8x/IA8X75MEMzdHA2eYKWnGflsfPGc=; b=VVclVsNHgYSeKuehzEifcPzdiZQuHVUvDer1btQo+WEoJQGmW+EU0jvbPOJ9U60MpQhSvg3DMsr6MPu89tgeVKuR+vNQR9W6S9gnhFtJBRp5wAPBI9ocadvmwcMulAa+l7BesRW8etXiMNCWjPwYoHQpBw504FMHUvS+9zpL0czYDdKgKUjdtdtmTFG/UU3OypoJT6U9Wcb6KU/A0U8LNmeAf98Ko9QzadpQazyPEZvqz6l0DiMjJ4j72+d3MTsf3nG2xXAqlFXl8a1Wpd/Z8OvFRyny1RCZD8q7B4ERsQJ8baDF4o+rryzzy7KFv8bYi7IVictjAgMdDnl8aozIeA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SXX+mnG2WHo9t8x/IA8X75MEMzdHA2eYKWnGflsfPGc=; b=Ks6KMk1FkgYJMLPJx410idSYwcPSt597Z/J8Gq7kOnOAKprr/dfUNl2HxkCPt+L2wvqmPqR+HMSSbOreeQnuthI5M+rwhw6c8Rug9rjsaqmzlBNGL0sANt+fqeSCCA1NabbkJ0vpEr4mBTcpm7vMAZ8Na1x7FRA54MOh5R4EBBuh/u9yumrz8UOJePtCQRKqpcftkxXxQnFrUdXFCH79srYestSvsuQ0MyL92onzX81eLyDbObGZI3uu6eIzs9HeZU/SD5JoZCFO3ZcOBesOQHV1EW4W5KeYxeT6yLm7JiWnlnrslHdhA6vd/ejRrIfNDLDnMpkPzOTILTsEKpYCWQ== From: Michael Kelley To: "Xin Li (Intel)" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "linux-perf-users@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "virtualization@lists.linux.dev" , "linux-pm@vger.kernel.org" , "linux-edac@vger.kernel.org" , "xen-devel@lists.xenproject.org" , "linux-acpi@vger.kernel.org" , "linux-hwmon@vger.kernel.org" , "netdev@vger.kernel.org" , "platform-driver-x86@vger.kernel.org" CC: "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "acme@kernel.org" , "jgross@suse.com" , "andrew.cooper3@citrix.com" , "peterz@infradead.org" , "namhyung@kernel.org" , "mark.rutland@arm.com" , "alexander.shishkin@linux.intel.com" , "jolsa@kernel.org" , "irogers@google.com" , "adrian.hunter@intel.com" , "kan.liang@linux.intel.com" , "wei.liu@kernel.org" , "ajay.kaher@broadcom.com" , "bcm-kernel-feedback-list@broadcom.com" , "tony.luck@intel.com" , "pbonzini@redhat.com" , "vkuznets@redhat.com" , "seanjc@google.com" , "luto@kernel.org" , "boris.ostrovsky@oracle.com" , "kys@microsoft.com" , "haiyangz@microsoft.com" , "decui@microsoft.com" , "dapeng1.mi@linux.intel.com" , "ilpo.jarvinen@linux.intel.com" Subject: RE: [PATCH v4 00/15] MSR code cleanup part one Thread-Topic: [PATCH v4 00/15] MSR code cleanup part one Thread-Index: AQHbt1Z92Fo/8zkiv0KdjUYDp5u46rO/aE4w Date: Fri, 2 May 2025 14:13:49 +0000 Message-ID: References: <20250427092027.1598740-1-xin@zytor.com> In-Reply-To: <20250427092027.1598740-1-xin@zytor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|IA1PR02MB9158:EE_ x-ms-office365-filtering-correlation-id: 3cbee300-ee01-41f7-303a-08dd89838f34 x-ms-exchange-slblob-mailprops: a+H6FLLcF3qJxlamga53fEWW0rZ5v6J0GJXP+PrHq6TbYR/PNxWQz8Npub/gV3qr+knoDxujy/GsTsGaOt+RDdN+aOx0mxpGGeHjSqIBdEqvu9cO//Sd04ETGN8XX7EG/QjTZdG54SgS7DLF+gLy1w6YE9fXQtoaWG9N0be13CcK53D/vhpX21C8bN8N9IAnML6gmDH/gCU/lTf/tVJf6lgoSmtxe2lQA2p5PAdr09R0z+oXB+/v+0/iWQpv0AjudzDVJ62Z6Fwzoj3raWZ2nAEtXnirfNBqfZotb4NIyJBxUB4CgK/l3lUagQA4NMUz8XMJjopKk0/ua7NctNUSUhex97XMI8j44+qcR8Jk5pHY26/2ZqiL64R/fUt0kyMwgM5AXZV/et5X55VqAKnEtKwjFrtH7u/VaLT6v7AQBGiEHbm5QgN1GDLLUrIHlBcKYkb+bQQ3Ek9qczDo+HcakAf/J+mSb0OUFzB1a3MGjKBc8o0PtvAs31Q/qHSClGc/N15RgMDj7tr2ApETiHZIVxQZmXSxl9yVxVmUh8zkHCvPIW8+sl6XkVzbT6f7B0Qa/vIh/CgNsuiQbcBp4Mf8lx9TylVHWxjVgW0DSWXnfhBWd2xuKuZL5XxFa9XALLY9YrqZ3vSAHhWv26QZEDjqlz8YDla/mN0qbIeKYIlbd0CKMipHKKbYaiSw/82uOMMUDatpQh4pUspxOjgUb8a/dmvEWMn7yAhj4h0dHxFYaBPIYYBTO2RcNw4E60poa/8z1tYxDHLg1HWJiqZvfVJhUicfs3LeDMK4OFK3sQXJw1ox7Q58453UCYkaE5q5IUbN x-microsoft-antispam: BCL:0;ARA:14566002|8062599003|15080799006|8060799006|19110799003|461199028|102099032|1602099012|10035399004|4302099013|440099028|3412199025|41001999003|19111999003; x-microsoft-antispam-message-info: =?iso-8859-1?Q?5DACIFfVfInExwWvPhGZVFFHufnFUPIPl+lfb3KCfKLiM46EjtNXjkBuA0?= =?iso-8859-1?Q?i5MiB4+Cwds48YTLUPVxOjdxyLbqCrpRtxPSbScDUvGQ1QXm7r0SkPW73L?= =?iso-8859-1?Q?OIyROJHuAZMjoIAvKuyiV0Afpwg9JSzaOX2DDl40Mqbqub0xLyEnQcFIiy?= =?iso-8859-1?Q?H7cMt8j3WhV50YrRBYPvbVjs6b5iFX/14WKbJwxRCVHQEo5/Cc1lTWwOL0?= =?iso-8859-1?Q?LH8oCExSnCh2/U4f0R+Cl+kGYj6Md1Khla9O5Fygrx13IayTnbO5+XkZjA?= =?iso-8859-1?Q?pWQRjFquwbwKdbjU2eTu12JFYiEyDgF+AzN3tXlXN9FH+II306PTTi9Yr7?= =?iso-8859-1?Q?rFYQ9EzlcDF+nlrg6HTpe9NiuETA6EGU+1V2knkCARliS5NZXtUrp5RO58?= =?iso-8859-1?Q?DOGox/Ra8lrGlE9wdgsyBPJv6oDjzDbzIqQCZivHozzlYS1ru6HGAdQ5Qo?= =?iso-8859-1?Q?bh1Hr5PWBTF8qVI6S02oDSUatxEbjQWOYc581iWTHCkIIqPxvbw0Hact3V?= =?iso-8859-1?Q?Hgb9ei1j14HkdlWlZjIAj+4N1FNQ+zqY+tJQuA0GYMY9QJlMdbWL+U0mGB?= =?iso-8859-1?Q?4SCNVExftJO+0PM3gEp5fsAiD3OgtugsMNlwVJCAOiS0AcXcxAbqZ98kXN?= =?iso-8859-1?Q?TKmy5KSIa6uEVm6n2aq3EqRF6M8vvMfvqSHucl+ZzJn99pPYLc5NVlsEJu?= =?iso-8859-1?Q?DyKGUaHRhrqVvYTC/Vp166hbHBMvQXzClnGvvy3DQjPHfT7L64jBNWmRrv?= =?iso-8859-1?Q?OrdDOhty3SvtGjg5mct9aeSTslEgHF32l17S1IXbhyNrejWqQ0RPr4yeLs?= =?iso-8859-1?Q?wYy1rkwsKm4+tyiNekXPUKp/rsbQGLa/R/m8gEViLDK7o0LiM0aAphJAuA?= =?iso-8859-1?Q?+o2RKLVLUmrGL8f9NoMegP6PKhMcUES0m9LLzmxXfEbkTjSQKpZNFWx72w?= =?iso-8859-1?Q?YyqEceXMZOFqpXkywOG6p5CYMRROBRYiL8WmR7v3yoaH7HxFD2TwmGTa5d?= =?iso-8859-1?Q?rkTHZ5dHSpBrl9np6NUYlTRBjCkauPI5GAPiPVo7z+Plko/WNMQxJSHWsa?= =?iso-8859-1?Q?4PZj7xWEQZgHdsemqOWEMMYnqFV3dXg6QU0o7DOF2qUNUk+k9z4995/LJJ?= =?iso-8859-1?Q?2DiDlzOQXWxSCZnXWRGtyUg0WHlizRUfzSErsKAI79QbAE526oglsNcFGF?= =?iso-8859-1?Q?KAoqEysYC3jMhhWBzMr144DmzkXIkK/x3nyl/WBygNHcYxNQBTsiR+QpoN?= =?iso-8859-1?Q?UiFfp1sqvONXcUFJ7SIB76/jAK8W1tLVeke4C2BNafLLTQde8UE/H39spX?= =?iso-8859-1?Q?otjIkXkNysed68pjUcGNXXlaqyjP88Ifr5qaMuT5COE2lCYkWylmtfWgk6?= =?iso-8859-1?Q?GqolUhrFmY?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?KYlKITl/e96EgPF0jSFlU7K0zZcxHgH9+VQ3/DPucLcZfb4651FTbXZ5ux?= =?iso-8859-1?Q?dFPWVuFpAp7jVC6M/B66j21+DENs1c/bmGqw0PBudha6yqQ8xhMWKy7T2s?= =?iso-8859-1?Q?MSbYGrJEP2pSpjS6h1YituiMaQxOp9rSL9sLeFNW+Xp1weKTBb74sM5NLC?= =?iso-8859-1?Q?ynMet8Z9NXYGhBsubv2ViEWs9051C71l7j8JPzA7/1nsSMOv3URPKHnK2b?= =?iso-8859-1?Q?a6jOu3sMEowhrRUpDNEhjQg4eoeufukENJBeji04EAysiMN2/LuyYjFdul?= =?iso-8859-1?Q?DsumJI8KbVO1K/zJXDoK6vrsHcdc4C/OaHyhrraBxw9h/T1GXSJr3AC2J+?= =?iso-8859-1?Q?8k68aFh+7+NZeYiuquSitRniFu26YYG17K0E1BZowNZyQHViQXTtl1ydX8?= =?iso-8859-1?Q?iQQeWe6h+URxDXn8U5Dkkc9hHmCyPhMOp2B+zEuqaVn6n421gP9d9mWEal?= =?iso-8859-1?Q?fA/2h692XeYhfO33POp35q/v2JqgOlI3wBBjap8EOjZT7AQWlA7V7dbRkq?= =?iso-8859-1?Q?5ba3U9QnoUCg2b05QfTG+WfUyM0wiqfJUq++N3aXXzq733jTzYRmssZTs9?= =?iso-8859-1?Q?nBcP+27uNzZpctHpbSmv0g3hCNpdczhDvK9nV4Px+VAPXg9qd89F+kxS/b?= =?iso-8859-1?Q?7k8t6v6k3EQj47iLcStVqIl/iF8y43E0L0evOn1xMi2k+yfI+ZFn6ZHCE6?= =?iso-8859-1?Q?tV+adzkhDc5lHt8f5hbI3xSXsR1rJlJnDZ2L8ZWH9V68JmFAMGIjSKIXZV?= =?iso-8859-1?Q?abm1E+F1a4ou9pHOhUY+nI+yy32Ok/4ok9YkSQjHNqd7IkBU6dZbD2WGqF?= =?iso-8859-1?Q?02jMTlIYlStvjHzo3sav1yjgZcOVsDiXJyg8v/MK/fwgux7Kx8zBIEsqgn?= =?iso-8859-1?Q?nVU5PEZ1UTorfi4vlvnK2Yoxg7MdQWaEneoX7WGcs2BZZl4gc0O0JDlLHu?= =?iso-8859-1?Q?HDsRPhc9Opa+yPJqdxap/aXFUqqxMB2COdgtYAjPMgKkij6Y/OJfS6+UFv?= =?iso-8859-1?Q?rZNnNpbuTmaiiV39jpJrKRIjjPvg4jhJ/Gd0KE2cr/OZnvfdMl8kqIC/Gg?= =?iso-8859-1?Q?qEjeTju3pEF8jY+vKbOe5VNN6R8YNheeZtyH+K+G1F7jEmzZKEx0IO78Kr?= =?iso-8859-1?Q?B6x/6DrDMML9dXnmuG/usrwV9n0rbO5y+MGwGF6GAhXzHoVNLtkklpcTly?= =?iso-8859-1?Q?2OvBkCafFjOquWOqchHGrT4ycDBaa1RbhL+bSvWhcSCB6TfhRKuA8rzJCE?= =?iso-8859-1?Q?26rAdgteG1rpp74tRPcE8TS3JeNJrKW7yGSIioA7g=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 3cbee300-ee01-41f7-303a-08dd89838f34 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2025 14:13:49.2725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR02MB9158 From: Xin Li (Intel) Sent: Sunday, April 27, 2025 2:20 AM >=20 > This patch set is the first part of the patch set: >=20 > MSR refactor with new MSR instructions support >=20 > @ https://lore.kernel.org/lkml/20250422082216.1954310-1-xin@zytor.com/=20 >=20 > It's getting *WAY* too big, and whether to zap the pv_ops MSR APIs is > still under argument. Dave Hansen suggested to focus on rename stuff > first, most of which he acked. >=20 > J=FCrgen Gro=DF also gave his RBs to the Xen MSR cleanup patches. >=20 > So here comes the first MSR cleanup patch set with version 4. >=20 >=20 > Changes in v4: > 1) Add missing includes in a different patch (Ilpo J=E4rvinen). > 2) Add all necessary direct inclusions for msr.h (Ilpo J=E4rvinen). > 3) Remove two "else" that no longer make sense (Juergen Gross). > 4) Collect RBs from J=FCrgen Gro=DF and ABs from Peter Zijlstra. >=20 >=20 > Link to the previous v3 patch set: > https://lore.kernel.org/lkml/20250425083442.2390017-1-xin@zytor.com/=20 >=20 >=20 > This patch series is based on: >=20 > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/msr Tested this patch set (plus the v4A version of Patch 1) in VMs on Hyper-V. Tested a normal VM, a TDX VM (with paravisor) and a SEV-SNP VM (with paravisor). No issues found. Since this patch set is just a rename, the risk should be low. But I wanted to make sure there's nothing unexpected happening with Hyper-V and the synthetic MSRs that it presents to guest VMs, as well as with the paravisor configurations. Tested-by: Michael Kelley >=20 >=20 > Xin Li (Intel) (15): > x86/msr: Add missing includes of > x86/msr: Move rdtsc{,_ordered}() to > x86/msr: Remove rdpmc() > x86/msr: Rename rdpmcl() to rdpmc() > x86/msr: Convert the rdpmc() macro into an always inline function > x86/xen/msr: Return u64 consistently in Xen PMC read functions > x86/msr: Convert __wrmsr() uses to native_wrmsr{,q}() uses > x86/msr: Add the native_rdmsrq() helper > x86/msr: Convert __rdmsr() uses to native_rdmsrq() uses > x86/xen/msr: Remove calling native_{read,write}_msr{,_safe}() in > pmu_msr_{read,write}() > x86/xen/msr: Remove pmu_msr_{read,write}() > x86/xen/msr: Remove the error pointer argument from set_seg() > x86/pvops/msr: refactor pv_cpu_ops.write_msr{,_safe}() > x86/msr: Replace wrmsr(msr, low, 0) with wrmsrq(msr, low) > x86/msr: Change the function type of native_read_msr_safe() >=20 > arch/x86/coco/sev/core.c | 2 +- > arch/x86/events/amd/brs.c | 4 +- > arch/x86/events/amd/uncore.c | 2 +- > arch/x86/events/core.c | 2 +- > arch/x86/events/intel/core.c | 4 +- > arch/x86/events/intel/ds.c | 2 +- > arch/x86/events/msr.c | 3 + > arch/x86/events/perf_event.h | 1 + > arch/x86/events/probe.c | 2 + > arch/x86/hyperv/hv_apic.c | 6 +- > arch/x86/hyperv/hv_vtl.c | 4 +- > arch/x86/hyperv/ivm.c | 3 +- > arch/x86/include/asm/apic.h | 4 +- > arch/x86/include/asm/fred.h | 1 + > arch/x86/include/asm/microcode.h | 2 + > arch/x86/include/asm/mshyperv.h | 3 +- > arch/x86/include/asm/msr.h | 130 +++++------------- > arch/x86/include/asm/paravirt.h | 57 ++++---- > arch/x86/include/asm/paravirt_types.h | 10 +- > arch/x86/include/asm/suspend_32.h | 1 + > arch/x86/include/asm/suspend_64.h | 1 + > arch/x86/include/asm/switch_to.h | 4 +- > arch/x86/include/asm/tsc.h | 76 +++++++++- > arch/x86/kernel/cpu/amd.c | 2 +- > arch/x86/kernel/cpu/common.c | 10 +- > arch/x86/kernel/cpu/mce/core.c | 6 +- > arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 25 ++-- > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 2 +- > arch/x86/kernel/cpu/umwait.c | 4 +- > arch/x86/kernel/fpu/xstate.h | 1 + > arch/x86/kernel/hpet.c | 1 + > arch/x86/kernel/kvm.c | 2 +- > arch/x86/kernel/kvmclock.c | 2 +- > arch/x86/kernel/process_64.c | 1 + > arch/x86/kernel/trace_clock.c | 2 +- > arch/x86/kernel/tsc_sync.c | 1 + > arch/x86/kvm/svm/svm.c | 34 ++--- > arch/x86/kvm/vmx/vmx.c | 4 +- > arch/x86/lib/kaslr.c | 2 +- > arch/x86/mm/mem_encrypt_identity.c | 5 +- > arch/x86/realmode/init.c | 1 + > arch/x86/xen/enlighten_pv.c | 58 ++++---- > arch/x86/xen/pmu.c | 72 +++------- > arch/x86/xen/xen-ops.h | 5 +- > drivers/acpi/acpi_extlog.c | 1 + > drivers/acpi/processor_perflib.c | 1 + > drivers/acpi/processor_throttling.c | 3 +- > drivers/char/agp/nvidia-agp.c | 1 + > drivers/cpufreq/amd-pstate-ut.c | 2 + > drivers/crypto/ccp/sev-dev.c | 1 + > drivers/edac/amd64_edac.c | 1 + > drivers/edac/ie31200_edac.c | 1 + > drivers/edac/mce_amd.c | 1 + > drivers/hwmon/hwmon-vid.c | 4 + > drivers/idle/intel_idle.c | 1 + > drivers/misc/cs5535-mfgpt.c | 1 + > drivers/net/vmxnet3/vmxnet3_drv.c | 4 + > drivers/platform/x86/intel/ifs/core.c | 1 + > drivers/platform/x86/intel/ifs/load.c | 1 + > drivers/platform/x86/intel/ifs/runtest.c | 1 + > drivers/platform/x86/intel/pmc/cnp.c | 1 + > .../intel/speed_select_if/isst_if_common.c | 1 + > .../intel/speed_select_if/isst_if_mbox_msr.c | 1 + > .../intel/speed_select_if/isst_tpmi_core.c | 1 + > drivers/platform/x86/intel/turbo_max_3.c | 1 + > .../intel/uncore-frequency/uncore-frequency.c | 1 + > drivers/powercap/intel_rapl_common.c | 1 + > drivers/powercap/intel_rapl_msr.c | 1 + > .../processor_thermal_device.c | 1 + > drivers/thermal/intel/intel_tcc_cooling.c | 1 + > drivers/thermal/intel/x86_pkg_temp_thermal.c | 1 + > drivers/video/fbdev/geode/display_gx.c | 1 + > drivers/video/fbdev/geode/gxfb_core.c | 1 + > drivers/video/fbdev/geode/lxfb_ops.c | 1 + > 74 files changed, 308 insertions(+), 295 deletions(-) >=20 >=20 > base-commit: a5447e92e169dafaf02fd653500105c7186d7128 > -- > 2.49.0 >=20 From xen-devel-bounces@lists.xenproject.org Fri May 02 15:17:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 15:17:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974746.1362508 (Exim 4.92) (envelope-from ) id 1uAs8f-0003rS-7F; Fri, 02 May 2025 15:17:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974746.1362508; Fri, 02 May 2025 15: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 1uAs8f-0003rL-4m; Fri, 02 May 2025 15:17:21 +0000 Received: by outflank-mailman (input) for mailman id 974746; Fri, 02 May 2025 15:17:19 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAs8d-0003rB-HJ for xen-devel@lists.xenproject.org; Fri, 02 May 2025 15:17:19 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 889b2e30-2768-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 17:17:17 +0200 (CEST) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-ace98258d4dso294954566b.2 for ; Fri, 02 May 2025 08:17:17 -0700 (PDT) Received: from fedora.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad1891473a1sm63218766b.4.2025.05.02.08.17.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 08:17: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" X-Inumbo-ID: 889b2e30-2768-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1746199036; x=1746803836; 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; bh=ggLUTb5elhqYRAVQYFSnXR1nma6iNQ6dGhAZ9EvxB2Y=; b=P0BN/ni1neC4Ad3twKK3tKt8JX/agXHnGlTM3ftzeogdo7mEgCJClWrYGGgyA6lnSH Az6GS1dZOZ4W4c4zPmmb//QLyB9IuWKbsOtWrRHXZHDDHCCB57mKIZRZf43N7SgXYTr2 MiDy7c5QLiVJp4cIQunoDPAOqvxsyLlhmnbJc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746199036; x=1746803836; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ggLUTb5elhqYRAVQYFSnXR1nma6iNQ6dGhAZ9EvxB2Y=; b=ITc/4ZS+HbYugGRC/KHBawWICSGNC6Fx01agt2sGvdUrluV+Q336+AbaVwLX0L6LLB RWHV4WwITBHJAyZc8XxUC7VsmTqaKDm20Rm8soxkv1s6EvH1AVLPfH6pmM1QABkROBom M4h8AMWWq0oPsjyvVN9pbbB8tYRrRcNXzV7ow3Y82hZ1/Pl9NOGLVD60De7dqBUFX8XL E476mSSnJqUVJrACxvn8DQzVJl4G3JrvrIay0X1rAHukLEG/YGX1zHjq8MzxzTDhICv5 DsNBNmvHBnauGMUkY/FLwXjkJqiMCWqHMSD4iLciGi7vjV3DPS32owNqWFVVkEQrwgo7 6agg== X-Gm-Message-State: AOJu0Yx9DDt9WhRdbmhmo/sARyNehhBok5wvnEB4lLfzs8/xwbd3j31t 1lwNX1l2hiaq3G6Mn4wCRVO9rlOCIzJqmPndOiVK9IOXr1ydegOGEX/S6O76hd4UpA8VsKdMIdH b40A= X-Gm-Gg: ASbGncv9PJAu/gxxgtuBFNt+cw0qeb0kDhRahgaS/kIHQ03istU2Aa9aEiV2v5rBipL XePCcsKoXF5K5xMMxeJ7pdZ666zDJtkC2JoKPn9+ZWsAshp0g582dlueLZyb0ZEnN7fuq9CznqX EMBDF/7dEMXq+DujeUkfcXzccYhhNX3Yk2iq5RUM+1JiEmkI8hyxEDHyvFG6fO7LHIVqqezs06h ifuzf5TluJQj/5kyyhix0KLjTPfW05dheyidB87na7KdhRc92Mqj//36R2hK5C0MLOTlhJjX2Qo SAU0wAY7jyxKxUR6TW8dCdIE9vOmD8Id5D25/Z3ROqmT6dD3DVqSMNghNg== X-Google-Smtp-Source: AGHT+IE7KwsITq4I4hp4EY9MD0v/RmkkA3yvCyD6W7GeQE39G7UKPfZwYgkms6n1sXy5j4qC/8cRJw== X-Received: by 2002:a17:907:2d28:b0:ace:dd27:7c68 with SMTP id a640c23a62f3a-ad17aef2846mr370530666b.46.1746199035820; Fri, 02 May 2025 08:17:15 -0700 (PDT) From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: Kevin Lampis Subject: [PATCH] x86/cpufeatures: cpuid features for Sierra Forest Date: Fri, 2 May 2025 16:17:09 +0100 Message-ID: <20250502151709.1542875-1-kevin.lampis@cloud.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add new cpuid features for Sierra Forest. Signed-off-by: Kevin Lampis --- xen/include/public/arch-x86/cpufeatureset.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index cc6e984a88..c0587be972 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -304,13 +304,18 @@ XEN_CPUFEATURE(SM3, 10*32+ 1) /*A SM3 Instructions */ XEN_CPUFEATURE(SM4, 10*32+ 2) /*A SM4 Instructions */ XEN_CPUFEATURE(AVX_VNNI, 10*32+ 4) /*A AVX-VNNI Instructions */ XEN_CPUFEATURE(AVX512_BF16, 10*32+ 5) /*A AVX512 BFloat16 Instructions */ +XEN_CPUFEATURE(LASS, 10*32+ 6) /* Linear Address Space Separation */ XEN_CPUFEATURE(CMPCCXADD, 10*32+ 7) /*a CMPccXADD Instructions */ +XEN_CPUFEATURE(ARCH_PERF_MON, 10*32+ 8) /* ArchPerfMonExt */ XEN_CPUFEATURE(FZRM, 10*32+10) /*A Fast Zero-length REP MOVSB */ XEN_CPUFEATURE(FSRS, 10*32+11) /*A Fast Short REP STOSB */ XEN_CPUFEATURE(FSRCS, 10*32+12) /*A Fast Short REP CMPSB/SCASB */ XEN_CPUFEATURE(WRMSRNS, 10*32+19) /*S WRMSR Non-Serialising */ XEN_CPUFEATURE(AMX_FP16, 10*32+21) /* AMX FP16 instruction */ XEN_CPUFEATURE(AVX_IFMA, 10*32+23) /*A AVX-IFMA Instructions */ +XEN_CPUFEATURE(LAM, 10*32+26) /* Linear Address Masking */ +XEN_CPUFEATURE(MSRLIST, 10*32+27) /* RDMSRLIST/WRMSRLIST/WRMSRNS */ +XEN_CPUFEATURE(INVD_DISABLE, 10*32+30) /* INVD_DISABLE_POST_BIOS_DONE */ /* AMD-defined CPU features, CPUID level 0x80000021.eax, word 11 */ XEN_CPUFEATURE(NO_NEST_BP, 11*32+ 0) /*A No Nested Data Breakpoints */ @@ -340,6 +345,7 @@ XEN_CPUFEATURE(RRSBA_CTRL, 13*32+ 2) /*S MSR_SPEC_CTRL.RRSBA_DIS_* */ XEN_CPUFEATURE(DDP_CTRL, 13*32+ 3) /* MSR_SPEC_CTRL.DDP_DIS_U */ XEN_CPUFEATURE(BHI_CTRL, 13*32+ 4) /*S MSR_SPEC_CTRL.BHI_DIS_S */ XEN_CPUFEATURE(MCDT_NO, 13*32+ 5) /*A MCDT_NO */ +XEN_CPUFEATURE(UC_LOCK_DISABLE, 13*32+ 6) /* UC-lock disable */ /* Intel-defined CPU features, CPUID level 0x00000007:1.ecx, word 14 */ @@ -349,7 +355,9 @@ XEN_CPUFEATURE(AVX_NE_CONVERT, 15*32+ 5) /*A AVX-NE-CONVERT Instructions */ XEN_CPUFEATURE(AMX_COMPLEX, 15*32+ 8) /* AMX Complex Instructions */ XEN_CPUFEATURE(AVX_VNNI_INT16, 15*32+10) /*A AVX-VNNI-INT16 Instructions */ XEN_CPUFEATURE(PREFETCHI, 15*32+14) /*A PREFETCHIT{0,1} Instructions */ +XEN_CPUFEATURE(UIRET_UIF, 15*32+17) /* UIRET_UIF */ XEN_CPUFEATURE(CET_SSS, 15*32+18) /* CET Supervisor Shadow Stacks safe to use */ +XEN_CPUFEATURE(SLSM, 15*32+24) /* Static Lockstep Mode */ /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.eax, word 16 */ XEN_CPUFEATURE(RDCL_NO, 16*32+ 0) /*A No Rogue Data Cache Load (Meltdown) */ @@ -368,6 +376,7 @@ XEN_CPUFEATURE(DOITM, 16*32+12) /* Data Operand Invariant Timing XEN_CPUFEATURE(SBDR_SSDP_NO, 16*32+13) /*A No Shared Buffer Data Read or Sideband Stale Data Propagation */ XEN_CPUFEATURE(FBSDP_NO, 16*32+14) /*A No Fill Buffer Stale Data Propagation */ XEN_CPUFEATURE(PSDP_NO, 16*32+15) /*A No Primary Stale Data Propagation */ +XEN_CPUFEATURE(MCU_ENUMERATION, 16*32+16) /* MCU_ENUMERATION */ XEN_CPUFEATURE(FB_CLEAR, 16*32+17) /*!A| Fill Buffers cleared by VERW */ XEN_CPUFEATURE(FB_CLEAR_CTRL, 16*32+18) /* MSR_OPT_CPU_CTRL.FB_CLEAR_DIS */ XEN_CPUFEATURE(RRSBA, 16*32+19) /*! Restricted RSB Alternative */ @@ -379,6 +388,7 @@ XEN_CPUFEATURE(GDS_CTRL, 16*32+25) /* MCU_OPT_CTRL.GDS_MIT_{DIS,LOCK XEN_CPUFEATURE(GDS_NO, 16*32+26) /*A No Gather Data Sampling */ XEN_CPUFEATURE(RFDS_NO, 16*32+27) /*A No Register File Data Sampling */ XEN_CPUFEATURE(RFDS_CLEAR, 16*32+28) /*!A| Register File(s) cleared by VERW */ +XEN_CPUFEATURE(IGN_UMONITOR, 16*32+29) /* IGN_UMONITOR_SUPPORT */ /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.edx, word 17 */ -- 2.42.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 15:55:12 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 15:55:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974764.1362519 (Exim 4.92) (envelope-from ) id 1uAsjB-0000vZ-UH; Fri, 02 May 2025 15:55:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974764.1362519; Fri, 02 May 2025 15:55: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 1uAsjB-0000vS-RX; Fri, 02 May 2025 15:55:05 +0000 Received: by outflank-mailman (input) for mailman id 974764; Fri, 02 May 2025 15:55:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAsjB-0000vJ-1s for xen-devel@lists.xenproject.org; Fri, 02 May 2025 15:55:05 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cd2c8887-276d-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 17:54:59 +0200 (CEST) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-43edb40f357so10746185e9.0 for ; Fri, 02 May 2025 08:54:59 -0700 (PDT) Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-441b89ee39esm48052015e9.21.2025.05.02.08.54.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 May 2025 08:54:58 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cd2c8887-276d-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1746201299; x=1746806099; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=Oi72cNcyfy2TI1qmArEUF3+MXRZBe79I7OYwovHbUS4=; b=M0kJ4JbeEu5ErxLXY/c60EsORuumGkIhNrM5Inu5/nqkVcrAVqJVhOWnEHO7SQI5ln r1Q+T53MMzdto4oQCRXkWZEAh7MwmQZZ+76dFzPeFXenMftWxo/eLvErhby+F2joC7Uf ZSopmsvEwlvKSeKgogCbz6SNOX8AF9Fzbatic= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746201299; x=1746806099; h=content-transfer-encoding:in-reply-to:autocrypt:from:cc :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Oi72cNcyfy2TI1qmArEUF3+MXRZBe79I7OYwovHbUS4=; b=ecW/30oPkDKZMrQ19s6wbgQOvC9XaL89LWVGkOVnoVSsnbpgJMvfp048EmLpmyU4sI v2/QEz1waKaIpECvIlf0uUzT2l121YkAwTMwj1KlarPxbq1Tu9hKcRx5BLOGEqqtXdbN FTu1usfDizGw5QwNFMWRVE4v7LjRm/FlcejiBycr+9biQb+WXYdS/2b+VCpYpe8yCLRp ZwyKuHD1Tid95ENaYdSG476Bhe+GTGqkL/cbzSjNMFPjKBV6c8qtx4uBc+HUyfMD+FJY 0DRr7nkZHRxANXnfNXIKByfBR7qYrvJVjsUOds7beaOjkK44ZI7QsYgdTAAZ/TaBRQko Um/g== X-Forwarded-Encrypted: i=1; AJvYcCVW372gosSmNKpkcIcKR+2i6XPv/MOKKPoRT8E2Pr8r1UlYFS/1WLEypxqER3duaGGvd7XbxfczUwU=@lists.xenproject.org X-Gm-Message-State: AOJu0YwrUmrQ3xDdY4SyyjWkKPZpnN1nGLfsF2x1A8aPUaG9DRM/wnyg q/VqD1HOCdGz+ehJs+S0kZIIj7sumnf19hBKd2wb31T23Jrs+SQbtnYt+Pb6ngA= X-Gm-Gg: ASbGncvvn3fzuHodf91ULGDrxo/97GKuw2wjo5FSuZUyaod84/Yp2DIVIy66RxbrOXD YZqa4gOOnUmoDfTb0oIThNAB9Bq+7kStnlwKVn2lTPY4SMnGIR3m2MoPHa/znFNLYBwhvpyczcb FTb8RIHmqyo69hsWvwhvtzC6xiTdxsPpoEAGn8Z9Vetbf2gnNaFJaAThWfMMx+RRbSeBMd6OyQL NP4S/NOzyh5i16LbM9GM5sSiCVPiu3Ki57ZKQE6wm1sDFNlzdx9See/bfkBcp75eR/sAg7TEeLu gmr/h8C3rpHravxSrJASBdbmL7xRHE5LKeFyRkyy3OLabkoWfg3GUZ0uOrFhNPwP2fSB7sK/8u8 TE9qQOg== X-Google-Smtp-Source: AGHT+IGiaofBegO2iXj0ONfsdk9hjfE6Ph0PojUUhX66HXglCBNzz/PS0aB3QEGzRSqBsQr48sEhAw== X-Received: by 2002:a05:600c:4f87:b0:43c:fe15:41d4 with SMTP id 5b1f17b1804b1-441bbec6a6dmr30137315e9.18.1746201299080; Fri, 02 May 2025 08:54:59 -0700 (PDT) Message-ID: <5cb6ef01-290f-4891-a90a-9998a7e60ba1@citrix.com> Date: Fri, 2 May 2025 16:54:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/cpufeatures: cpuid features for Sierra Forest To: Kevin Lampis , xen-devel@lists.xenproject.org References: <20250502151709.1542875-1-kevin.lampis@cloud.com> Content-Language: en-GB Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 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: <20250502151709.1542875-1-kevin.lampis@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02/05/2025 4:17 pm, Kevin Lampis wrote: > Add new cpuid features for Sierra Forest. > > Signed-off-by: Kevin Lampis One minor thing, you should have CC'd the x86 maintainers on this patch, which I've done. > --- > xen/include/public/arch-x86/cpufeatureset.h | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h > index cc6e984a88..c0587be972 100644 > --- a/xen/include/public/arch-x86/cpufeatureset.h > +++ b/xen/include/public/arch-x86/cpufeatureset.h > @@ -304,13 +304,18 @@ XEN_CPUFEATURE(SM3, 10*32+ 1) /*A SM3 Instructions */ > XEN_CPUFEATURE(SM4, 10*32+ 2) /*A SM4 Instructions */ > XEN_CPUFEATURE(AVX_VNNI, 10*32+ 4) /*A AVX-VNNI Instructions */ > XEN_CPUFEATURE(AVX512_BF16, 10*32+ 5) /*A AVX512 BFloat16 Instructions */ > +XEN_CPUFEATURE(LASS, 10*32+ 6) /* Linear Address Space Separation */ > XEN_CPUFEATURE(CMPCCXADD, 10*32+ 7) /*a CMPccXADD Instructions */ > +XEN_CPUFEATURE(ARCH_PERF_MON, 10*32+ 8) /* ArchPerfMonExt */ This is a corner case, but I typically take out the space before the 10 to keep the latter part aligned. (Although this is going to suck for ARCH_PERF_MON2 which is coming soon too.) > XEN_CPUFEATURE(FZRM, 10*32+10) /*A Fast Zero-length REP MOVSB */ > XEN_CPUFEATURE(FSRS, 10*32+11) /*A Fast Short REP STOSB */ > XEN_CPUFEATURE(FSRCS, 10*32+12) /*A Fast Short REP CMPSB/SCASB */ > XEN_CPUFEATURE(WRMSRNS, 10*32+19) /*S WRMSR Non-Serialising */ > XEN_CPUFEATURE(AMX_FP16, 10*32+21) /* AMX FP16 instruction */ > XEN_CPUFEATURE(AVX_IFMA, 10*32+23) /*A AVX-IFMA Instructions */ > +XEN_CPUFEATURE(LAM, 10*32+26) /* Linear Address Masking */ > +XEN_CPUFEATURE(MSRLIST, 10*32+27) /* RDMSRLIST/WRMSRLIST/WRMSRNS */ > +XEN_CPUFEATURE(INVD_DISABLE, 10*32+30) /* INVD_DISABLE_POST_BIOS_DONE */ I see this is the name Intel gave it, but "NO_INVD" is shorter and the semantic is only relevant to very early firmware. Also, 36 years late, but at least the fix has gotten out eventually...  AMD fixed this decades ago by treating INVD as WBINVD. > > /* AMD-defined CPU features, CPUID level 0x80000021.eax, word 11 */ > XEN_CPUFEATURE(NO_NEST_BP, 11*32+ 0) /*A No Nested Data Breakpoints */ > @@ -340,6 +345,7 @@ XEN_CPUFEATURE(RRSBA_CTRL, 13*32+ 2) /*S MSR_SPEC_CTRL.RRSBA_DIS_* */ > XEN_CPUFEATURE(DDP_CTRL, 13*32+ 3) /* MSR_SPEC_CTRL.DDP_DIS_U */ > XEN_CPUFEATURE(BHI_CTRL, 13*32+ 4) /*S MSR_SPEC_CTRL.BHI_DIS_S */ > XEN_CPUFEATURE(MCDT_NO, 13*32+ 5) /*A MCDT_NO */ > +XEN_CPUFEATURE(UC_LOCK_DISABLE, 13*32+ 6) /* UC-lock disable */ We tend to abbreviate to DIS.  (Intel is inconsistent on whether they do or not.) > > /* Intel-defined CPU features, CPUID level 0x00000007:1.ecx, word 14 */ > > @@ -349,7 +355,9 @@ XEN_CPUFEATURE(AVX_NE_CONVERT, 15*32+ 5) /*A AVX-NE-CONVERT Instructions */ > XEN_CPUFEATURE(AMX_COMPLEX, 15*32+ 8) /* AMX Complex Instructions */ > XEN_CPUFEATURE(AVX_VNNI_INT16, 15*32+10) /*A AVX-VNNI-INT16 Instructions */ > XEN_CPUFEATURE(PREFETCHI, 15*32+14) /*A PREFETCHIT{0,1} Instructions */ > +XEN_CPUFEATURE(UIRET_UIF, 15*32+17) /* UIRET_UIF */ For the comment, "UIRET updates UIF" which is a bit better than simply restating the name.  (Although Intel's "flexible update of ..." when they mean "oops we didn't design it right to start with" can stay in the Intel manual). > XEN_CPUFEATURE(CET_SSS, 15*32+18) /* CET Supervisor Shadow Stacks safe to use */ > +XEN_CPUFEATURE(SLSM, 15*32+24) /* Static Lockstep Mode */ > > /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.eax, word 16 */ > XEN_CPUFEATURE(RDCL_NO, 16*32+ 0) /*A No Rogue Data Cache Load (Meltdown) */ > @@ -368,6 +376,7 @@ XEN_CPUFEATURE(DOITM, 16*32+12) /* Data Operand Invariant Timing > XEN_CPUFEATURE(SBDR_SSDP_NO, 16*32+13) /*A No Shared Buffer Data Read or Sideband Stale Data Propagation */ > XEN_CPUFEATURE(FBSDP_NO, 16*32+14) /*A No Fill Buffer Stale Data Propagation */ > XEN_CPUFEATURE(PSDP_NO, 16*32+15) /*A No Primary Stale Data Propagation */ > +XEN_CPUFEATURE(MCU_ENUMERATION, 16*32+16) /* MCU_ENUMERATION */ I don't have a better suggestion, but I'm not thrilled by the name MCU_ENUMERATION. It's a whole bunch of different microcode loading changes. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri May 02 16:22:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 16:22:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974785.1362561 (Exim 4.92) (envelope-from ) id 1uAt9z-00069b-NH; Fri, 02 May 2025 16:22:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974785.1362561; Fri, 02 May 2025 16:22: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 1uAt9z-000692-Hn; Fri, 02 May 2025 16:22:47 +0000 Received: by outflank-mailman (input) for mailman id 974785; Fri, 02 May 2025 16:22:46 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAt9y-0005rY-Ey for xen-devel@lists.xenproject.org; Fri, 02 May 2025 16:22:46 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ad7f56c8-2771-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 18:22:44 +0200 (CEST) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-ac2a81e41e3so394102966b.1 for ; Fri, 02 May 2025 09:22:44 -0700 (PDT) Received: from fedora.. (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad1894c01f2sm68158766b.119.2025.05.02.09.22.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 09:22: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" X-Inumbo-ID: ad7f56c8-2771-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746202964; x=1746807764; 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; bh=u8nlrE1xOfFR3x/zATZSfmk84RnKUZVsA7gy/a2VH80=; b=mdLPNWCI2Xn9lyjJT5bGSTkcJ7PDAHcVRWtHmRs6EJgHyd8NwqJm23C0nB/pku4OAM umF/2BqHhUIhl6Q20sr5jCfQ0NgyG3porEwm/GMgLxXcY0bbBaL4z7en143rEyuio+bL o04KMC14I5EsLf5KGvAWYjkx1O9iTIYiemJikdeeI9BJWkgHvu1rcs+hFZ/204B2okIL WDITby62BtBqaGbqw5ta6HpbGXp5MmXvfDCwuGHxfg7v3yN24ggxKA3ZDgXnI359W1uS c7BxHvLgNDbsUCEButyLLD1/JgAXdhvAB6U+VZ5mTxyfz1KlXMTcv1YsF+KqtiOV9+xJ G4AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746202964; x=1746807764; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=u8nlrE1xOfFR3x/zATZSfmk84RnKUZVsA7gy/a2VH80=; b=OGkqIkBkh0V6BQ0z4z1x2Ip6SYFssPQ7BlUsoZmUh+VwUMTXnEZAL+D+pEzsWdNNL0 gUfWjsMjj9XdiTVrzDynK/wWcnHlOqBhN8ZWGZBINQAdWcPvw7ZDwfawdD7hliuVWoHC KdjacLHVHjP01SrMIdLgCT2WLblC2uVJ27BYBqJSglk//uA03OkYzK6JEu4OnMiJcHbr jXOtz931tg9KqYVT11iH+QTYzrN/fKUQkJiaUlt6fguwAx0aZg91eGgVG6iGJ/JK16FF VjzLdo2tGlpSxOhLauzbLeXp8ETeCgPtZ8JyVtouXB7Y1liv2tcAltRfoZHKcfQdDTAH dDsA== X-Gm-Message-State: AOJu0YzZk/VbX31Okv7NqbK0Z1VLVSRWc1kbt9GVrKK4HHATnxHWE78S 2vtMkrIdNTQAzYSkZ8KsELVvFzh1Agzjs3BFd07Y66f+RYlZU/DaE9mTXw== X-Gm-Gg: ASbGncsljhXWem6a2bWV/8YtzBO4liiWslSWtZhEHSkFLJzblUkstXYqvRLVeziT/Hy MvriqvknlshfB4mQxMKZvbSKsVJeEKoPfcOYwPUSmby3uRP0Fcx2EPYLwDv+t1cbP+vDhtcBqFT 6IW0of67lt8apkO2DbOdhxw1XAPYNkHhI7pO4svMQMZE8UUPCGlhJXP4B7lwwfXTM2BcCaB86eW 1vLvJMTSx+To8KBo6GYOE6SfucYvRwbZTEAfxi+7hFWqDBo8GC7RrhVfKpYmIYZZnh5QkgMe3mc RSTHPeNOgH1En55CsggODtTfJX+OHfQJW7jpTONIsIuLXMNLFNOu6JHfe8xdeyI63gMIt0sNmYN 4xyKtibkYLw== X-Google-Smtp-Source: AGHT+IEJ7hvV5q+nkxkUGh611s55rUyl6E9LU57qUyEPjnLtQ4i6XHxWf1qoYOBdtkLf1bqZLmib7g== X-Received: by 2002:a17:907:97d6:b0:ace:9d90:c49c with SMTP id a640c23a62f3a-ad17ad1a4famr335823766b.8.1746202963300; Fri, 02 May 2025 09:22:43 -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 v3 2/8] xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common Date: Fri, 2 May 2025 18:22:32 +0200 Message-ID: <82f0c1d4fe25b4a52d76f3c8004e107b183af56c.1746199009.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Move some parts of Arm's Dom0Less code to be reused by other architectures. At the moment, RISC-V is going to reuse these parts. Move dom0less-build.h from the Arm-specific directory to asm-generic as these header is expected to be the same across acrhictectures with some updates: add the following declaration of construct_domU(), and arch_create_domUs() as there are some parts which are still architecture-specific. Introduce HAS_DOM0LESS to provide ability to enable generic Dom0less code for an architecture. Relocate the CONFIG_DOM0LESS configuration to the common with adding "depends on HAS_DOM0LESS" to not break builds for architectures which don't support CONFIG_DOM0LESS config, especically it would be useful to not provide stubs for construct_domU(), arch_create_domUs() in case of *-randconfig which may set CONFIG_DOM0LESS=y. Move is_dom0less_mode() function to the common code, as it depends on boot modules that are already part of the common code. Move create_domUs() function to the common code with some updates: - Add arch_create_domUs() to cover parsing of arch-specific features, for example, SVE (Scalar Vector Extension ) exists only in Arm. Signed-off-by: Oleksii Kurochko --- It was suggested to change dom0less to predefined domus or similar (https://lore.kernel.org/xen-devel/cd2a3644-c9c6-4e77-9491-2988703906c0@gmail.com/T/#m1d5e81e5f1faca98a3c51efe4f35af25010edbf0): I decided to go with dom0less name for now as it will require a lot of places to change, including CI's test, and IMO we could do in a separate patch. If it is necessry to do now, I'll be happy to do that in next version of the current patch series. --- Changes in v3: - Move changes connected to the patch "xen/arm: dom0less delay xenstore initialization" to common. Also, some necessary parts for the mentioned patches were moved to common (such as alloc_xenstore_evtchn(), ... ). Not all changes are moved, changes connected to alloc_xenstore_params() and construct_domu() will be moved in the following patches of this patch series. - Move parsing of capabilities property to common code. - Align parsing of "passthrough", "multiboot,device-tree" properties with staging. - Drop arch_xen_domctl_createdomain(). - Add 'select HAS_DEVICE_TREE' for config HAS_DOM0LESS. - Add empty lines after license in the top of newly added files. - s/arch_create_domus/arch_create_domUs. - Add footer below commit message regarding the naming of dom0less. --- Changes in v2: - Convert 'depends on Arm' to 'depends on HAS_DOM0LESS' for CONFIG_DOM0LESS_BOOT. - Change 'default Arm' to 'default y' for CONFIG_DOM0LESS_BOOT as there is dependency on HAS_DOM0LESS. - Introduce HAS_DOM0LESS and enable it for Arm. - Update the commit message. --- xen/arch/arm/Kconfig | 9 +- xen/arch/arm/dom0less-build.c | 371 ++++------------------ xen/arch/arm/include/asm/Makefile | 1 + xen/arch/arm/include/asm/dom0less-build.h | 34 -- xen/common/Kconfig | 13 + xen/common/device-tree/Makefile | 1 + xen/common/device-tree/dom0less-build.c | 283 +++++++++++++++++ xen/include/asm-generic/dom0less-build.h | 49 +++ 8 files changed, 404 insertions(+), 357 deletions(-) delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h create mode 100644 xen/common/device-tree/dom0less-build.c create mode 100644 xen/include/asm-generic/dom0less-build.h diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index da8a406f5a..d0e0a7753c 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -15,6 +15,7 @@ config ARM select GENERIC_UART_INIT select HAS_ALTERNATIVE if HAS_VMAP select HAS_DEVICE_TREE + select HAS_DOM0LESS select HAS_STACK_PROTECTOR select HAS_UBSAN @@ -120,14 +121,6 @@ config GICV2 Driver for the ARM Generic Interrupt Controller v2. If unsure, say Y -config DOM0LESS_BOOT - bool "Dom0less boot support" if EXPERT - default y - help - Dom0less boot support enables Xen to create and start domU guests during - Xen boot without the need of a control domain (Dom0), which could be - present anyway. - config GICV3 bool "GICv3 driver" depends on !NEW_VGIC diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index a356fc94fc..ef49495d4f 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -22,48 +22,7 @@ #include #include -#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX - -static domid_t __initdata xs_domid = DOMID_INVALID; -static bool __initdata need_xenstore; - -void __init set_xs_domain(struct domain *d) -{ - xs_domid = d->domain_id; - set_global_virq_handler(d, VIRQ_DOM_EXC); -} - -bool __init is_dom0less_mode(void) -{ - struct bootmodules *mods = &bootinfo.modules; - struct bootmodule *mod; - unsigned int i; - bool dom0found = false; - bool domUfound = false; - - /* Look into the bootmodules */ - for ( i = 0 ; i < mods->nr_mods ; i++ ) - { - mod = &mods->module[i]; - /* Find if dom0 and domU kernels are present */ - if ( mod->kind == BOOTMOD_KERNEL ) - { - if ( mod->domU == false ) - { - dom0found = true; - break; - } - else - domUfound = true; - } - } - - /* - * If there is no dom0 kernel but at least one domU, then we are in - * dom0less mode - */ - return ( !dom0found && domUfound ); -} +bool __initdata need_xenstore; #ifdef CONFIG_VGICV2 static int __init make_gicv2_domU_node(struct kernel_info *kinfo) @@ -686,25 +645,6 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) return -EINVAL; } -static int __init alloc_xenstore_evtchn(struct domain *d) -{ - evtchn_alloc_unbound_t alloc; - int rc; - - alloc.dom = d->domain_id; - alloc.remote_dom = xs_domid; - rc = evtchn_alloc_unbound(&alloc, 0); - if ( rc ) - { - printk("Failed allocating event channel for domain\n"); - return rc; - } - - d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port; - - return 0; -} - #define XENSTORE_PFN_OFFSET 1 static int __init alloc_xenstore_page(struct domain *d) { @@ -771,36 +711,6 @@ static int __init alloc_xenstore_params(struct kernel_info *kinfo) return rc; } -static void __init initialize_domU_xenstore(void) -{ - struct domain *d; - - if ( xs_domid == DOMID_INVALID ) - return; - - for_each_domain( d ) - { - uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN]; - int rc; - - if ( gfn == 0 ) - continue; - - if ( is_xenstore_domain(d) ) - continue; - - rc = alloc_xenstore_evtchn(d); - if ( rc < 0 ) - panic("%pd: Failed to allocate xenstore_evtchn\n", d); - - if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) ) - { - ASSERT(gfn < UINT32_MAX); - gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn); - } - } -} - static void __init domain_vcpu_affinity(struct domain *d, const struct dt_device_node *node) { @@ -906,8 +816,8 @@ static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem, } #endif /* CONFIG_ARCH_PAGING_MEMPOOL */ -static int __init construct_domU(struct domain *d, - const struct dt_device_node *node) +int __init construct_domU(struct domain *d, + const struct dt_device_node *node) { struct kernel_info kinfo = KERNEL_INFO_INIT; const char *dom0less_enhanced; @@ -1009,246 +919,77 @@ static int __init construct_domU(struct domain *d, return alloc_xenstore_params(&kinfo); } -void __init create_domUs(void) +void __init arch_create_domUs(struct dt_device_node *node, + struct xen_domctl_createdomain *d_cfg, + unsigned int flags) { - struct dt_device_node *node; - const char *dom0less_iommu; - bool iommu = false; - const struct dt_device_node *cpupool_node, - *chosen = dt_find_node_by_path("/chosen"); - const char *llc_colors_str = NULL; - - BUG_ON(chosen == NULL); - dt_for_each_child_node(chosen, node) - { - struct domain *d; - struct xen_domctl_createdomain d_cfg = { - .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE, - .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap, - /* - * The default of 1023 should be sufficient for guests because - * on ARM we don't bind physical interrupts to event channels. - * The only use of the evtchn port is inter-domain communications. - * 1023 is also the default value used in libxl. - */ - .max_evtchn_port = 1023, - .max_grant_frames = -1, - .max_maptrack_frames = -1, - .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version), - }; - unsigned int flags = 0U; - bool has_dtb = false; - uint32_t val; - int rc; - - if ( !dt_device_is_compatible(node, "xen,domain") ) - continue; - - if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED ) - panic("No more domain IDs available\n"); + uint32_t val; - if ( dt_property_read_u32(node, "capabilities", &val) ) - { - if ( val & ~DOMAIN_CAPS_MASK ) - panic("Invalid capabilities (%"PRIx32")\n", val); - - if ( val & DOMAIN_CAPS_CONTROL ) - flags |= CDF_privileged; - - if ( val & DOMAIN_CAPS_HARDWARE ) - { - if ( hardware_domain ) - panic("Only 1 hardware domain can be specified! (%pd)\n", - hardware_domain); - - d_cfg.max_grant_frames = gnttab_dom0_frames(); - d_cfg.max_evtchn_port = -1; - flags |= CDF_hardware; - iommu = true; - } - - if ( val & DOMAIN_CAPS_XENSTORE ) - { - if ( xs_domid != DOMID_INVALID ) - panic("Only 1 xenstore domain can be specified! (%u)\n", - xs_domid); + d_cfg->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; + d_cfg->flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap; - d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain; - d_cfg.max_evtchn_port = -1; - } - } - - if ( dt_find_property(node, "xen,static-mem", NULL) ) - { - if ( llc_coloring_enabled ) - panic("LLC coloring and static memory are incompatible\n"); - - flags |= CDF_staticmem; - } - - if ( dt_property_read_bool(node, "direct-map") ) - { - if ( !(flags & CDF_staticmem) ) - panic("direct-map is not valid for domain %s without static allocation.\n", - dt_node_name(node)); - - flags |= CDF_directmap; - } - - if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) ) - panic("Missing property 'cpus' for domain %s\n", - dt_node_name(node)); - - if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) ) - { - if ( flags & CDF_hardware ) - panic("Don't specify passthrough for hardware domain\n"); - - if ( !strcmp(dom0less_iommu, "enabled") ) - iommu = true; - } - - if ( (flags & CDF_hardware) && !(flags & CDF_directmap) && - !iommu_enabled ) - panic("non-direct mapped hardware domain requires iommu\n"); - - if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") ) - { - if ( flags & CDF_hardware ) - panic("\"multiboot,device-tree\" incompatible with hardware domain\n"); - - has_dtb = true; - } - - if ( iommu_enabled && (iommu || has_dtb) ) - d_cfg.flags |= XEN_DOMCTL_CDF_iommu; - - if ( !dt_property_read_u32(node, "nr_spis", &d_cfg.arch.nr_spis) ) - { - int vpl011_virq = GUEST_VPL011_SPI; - - d_cfg.arch.nr_spis = VGIC_DEF_NR_SPIS; - - /* - * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is - * set, in which case it'll match the hardware. - * - * Since the domain is not yet created, we can't use - * d->arch.vpl011.irq. So the logic to find the vIRQ has to - * be hardcoded. - * The logic here shall be consistent with the one in - * domain_vpl011_init(). - */ - if ( flags & CDF_directmap ) - { - vpl011_virq = serial_irq(SERHND_DTUART); - if ( vpl011_virq < 0 ) - panic("Error getting IRQ number for this serial port %d\n", - SERHND_DTUART); - } + if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) ) + { + int vpl011_virq = GUEST_VPL011_SPI; - /* - * vpl011 uses one emulated SPI. If vpl011 is requested, make - * sure that we allocate enough SPIs for it. - */ - if ( dt_property_read_bool(node, "vpl011") ) - d_cfg.arch.nr_spis = MAX(d_cfg.arch.nr_spis, - vpl011_virq - 32 + 1); - } - else if ( flags & CDF_hardware ) - panic("nr_spis cannot be specified for hardware domain\n"); + d_cfg->arch.nr_spis = VGIC_DEF_NR_SPIS; - /* Get the optional property domain-cpupool */ - cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0); - if ( cpupool_node ) + /* + * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is + * set, in which case it'll match the hardware. + * + * Since the domain is not yet created, we can't use + * d->arch.vpl011.irq. So the logic to find the vIRQ has to + * be hardcoded. + * The logic here shall be consistent with the one in + * domain_vpl011_init(). + */ + if ( flags & CDF_directmap ) { - int pool_id = btcpupools_get_domain_pool_id(cpupool_node); - if ( pool_id < 0 ) - panic("Error getting cpupool id from domain-cpupool (%d)\n", - pool_id); - d_cfg.cpupool_id = pool_id; + vpl011_virq = serial_irq(SERHND_DTUART); + if ( vpl011_virq < 0 ) + panic("Error getting IRQ number for this serial port %d\n", + SERHND_DTUART); } - if ( dt_property_read_u32(node, "max_grant_version", &val) ) - d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val); + /* + * vpl011 uses one emulated SPI. If vpl011 is requested, make + * sure that we allocate enough SPIs for it. + */ + if ( dt_property_read_bool(node, "vpl011") ) + d_cfg->arch.nr_spis = MAX(d_cfg->arch.nr_spis, + vpl011_virq - 32 + 1); + } + else if ( flags & CDF_hardware ) + panic("nr_spis cannot be specified for hardware domain\n"); - if ( dt_property_read_u32(node, "max_grant_frames", &val) ) - { - if ( val > INT32_MAX ) - panic("max_grant_frames (%"PRIu32") overflow\n", val); - d_cfg.max_grant_frames = val; - } + if ( dt_get_property(node, "sve", &val) ) + { +#ifdef CONFIG_ARM64_SVE + unsigned int sve_vl_bits; + bool ret = false; - if ( dt_property_read_u32(node, "max_maptrack_frames", &val) ) + if ( !val ) { - if ( val > INT32_MAX ) - panic("max_maptrack_frames (%"PRIu32") overflow\n", val); - d_cfg.max_maptrack_frames = val; + /* Property found with no value, means max HW VL supported */ + ret = sve_domctl_vl_param(-1, &sve_vl_bits); } - - if ( dt_get_property(node, "sve", &val) ) + else { -#ifdef CONFIG_ARM64_SVE - unsigned int sve_vl_bits; - bool ret = false; - - if ( !val ) - { - /* Property found with no value, means max HW VL supported */ - ret = sve_domctl_vl_param(-1, &sve_vl_bits); - } + if ( dt_property_read_u32(node, "sve", &val) ) + ret = sve_domctl_vl_param(val, &sve_vl_bits); else - { - if ( dt_property_read_u32(node, "sve", &val) ) - ret = sve_domctl_vl_param(val, &sve_vl_bits); - else - panic("Error reading 'sve' property\n"); - } + panic("Error reading 'sve' property\n"); + } - if ( ret ) - d_cfg.arch.sve_vl = sve_encode_vl(sve_vl_bits); - else - panic("SVE vector length error\n"); + if ( ret ) + d_cfg->arch.sve_vl = sve_encode_vl(sve_vl_bits); + else + panic("SVE vector length error\n"); #else - panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n"); + panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n"); #endif - } - - dt_property_read_string(node, "llc-colors", &llc_colors_str); - if ( !llc_coloring_enabled && llc_colors_str ) - panic("'llc-colors' found, but LLC coloring is disabled\n"); - - /* - * The variable max_init_domid is initialized with zero, so here it's - * very important to use the pre-increment operator to call - * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0) - */ - d = domain_create(++max_init_domid, &d_cfg, flags); - if ( IS_ERR(d) ) - panic("Error creating domain %s (rc = %ld)\n", - dt_node_name(node), PTR_ERR(d)); - - if ( llc_coloring_enabled && - (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) ) - panic("Error initializing LLC coloring for domain %s (rc = %d)\n", - dt_node_name(node), rc); - - d->is_console = true; - dt_device_set_used_by(node, d->domain_id); - - rc = construct_domU(d, node); - if ( rc ) - panic("Could not set up domain %s (rc = %d)\n", - dt_node_name(node), rc); - - if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain ) - set_xs_domain(d); } - - if ( need_xenstore && xs_domid == DOMID_INVALID ) - panic("xenstore requested, but xenstore domain not present\n"); - - initialize_domU_xenstore(); } /* diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile index 4a4036c951..831c914cce 100644 --- a/xen/arch/arm/include/asm/Makefile +++ b/xen/arch/arm/include/asm/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only generic-y += altp2m.h generic-y += device.h +generic-y += dom0less-build.h generic-y += hardirq.h generic-y += iocap.h generic-y += paging.h diff --git a/xen/arch/arm/include/asm/dom0less-build.h b/xen/arch/arm/include/asm/dom0less-build.h deleted file mode 100644 index b0e41a1954..0000000000 --- a/xen/arch/arm/include/asm/dom0less-build.h +++ /dev/null @@ -1,34 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ - -#ifndef __ASM_DOM0LESS_BUILD_H_ -#define __ASM_DOM0LESS_BUILD_H_ - -#include - -#ifdef CONFIG_DOM0LESS_BOOT - -void create_domUs(void); -bool is_dom0less_mode(void); -void set_xs_domain(struct domain *d); - -#else /* !CONFIG_DOM0LESS_BOOT */ - -static inline void create_domUs(void) {} -static inline bool is_dom0less_mode(void) -{ - return false; -} -static inline void set_xs_domain(struct domain *d) {} - -#endif /* CONFIG_DOM0LESS_BOOT */ - -#endif /* __ASM_DOM0LESS_BUILD_H_ */ - -/* - * Local variables: - * mode: C - * c-file-style: "BSD" - * c-basic-offset: 4 - * indent-tabs-mode: nil - * End: - */ diff --git a/xen/common/Kconfig b/xen/common/Kconfig index be28060716..be38abf9e1 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -12,6 +12,15 @@ config CORE_PARKING bool depends on NR_CPUS > 1 +config DOM0LESS_BOOT + bool "Dom0less boot support" if EXPERT + depends on HAS_DOM0LESS + default y + help + Dom0less boot support enables Xen to create and start domU guests during + Xen boot without the need of a control domain (Dom0), which could be + present anyway. + config GRANT_TABLE bool "Grant table support" if EXPERT default y @@ -74,6 +83,10 @@ config HAS_DEVICE_TREE bool select LIBFDT +config HAS_DOM0LESS + bool + select HAS_DEVICE_TREE + config HAS_DIT # Data Independent Timing bool diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile index 7c549be38a..f3dafc9b81 100644 --- a/xen/common/device-tree/Makefile +++ b/xen/common/device-tree/Makefile @@ -1,5 +1,6 @@ obj-y += bootfdt.init.o obj-y += bootinfo.init.o obj-y += device-tree.o +obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o obj-y += intc.o diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c new file mode 100644 index 0000000000..a01a8b6b1a --- /dev/null +++ b/xen/common/device-tree/dom0less-build.c @@ -0,0 +1,283 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include + +static domid_t __initdata xs_domid = DOMID_INVALID; + +void __init set_xs_domain(struct domain *d) +{ + xs_domid = d->domain_id; + set_global_virq_handler(d, VIRQ_DOM_EXC); +} + +bool __init is_dom0less_mode(void) +{ + struct bootmodules *mods = &bootinfo.modules; + struct bootmodule *mod; + unsigned int i; + bool dom0found = false; + bool domUfound = false; + + /* Look into the bootmodules */ + for ( i = 0 ; i < mods->nr_mods ; i++ ) + { + mod = &mods->module[i]; + /* Find if dom0 and domU kernels are present */ + if ( mod->kind == BOOTMOD_KERNEL ) + { + if ( mod->domU == false ) + { + dom0found = true; + break; + } + else + domUfound = true; + } + } + + /* + * If there is no dom0 kernel but at least one domU, then we are in + * dom0less mode + */ + return ( !dom0found && domUfound ); +} + +static int __init alloc_xenstore_evtchn(struct domain *d) +{ + evtchn_alloc_unbound_t alloc; + int rc; + + alloc.dom = d->domain_id; + alloc.remote_dom = xs_domid; + rc = evtchn_alloc_unbound(&alloc, 0); + if ( rc ) + { + printk("Failed allocating event channel for domain\n"); + return rc; + } + + d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port; + + return 0; +} + +static void __init initialize_domU_xenstore(void) +{ + struct domain *d; + + if ( xs_domid == DOMID_INVALID ) + return; + + for_each_domain( d ) + { + uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN]; + int rc; + + if ( gfn == 0 ) + continue; + + if ( is_xenstore_domain(d) ) + continue; + + rc = alloc_xenstore_evtchn(d); + if ( rc < 0 ) + panic("%pd: Failed to allocate xenstore_evtchn\n", d); + + if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) ) + { + ASSERT(gfn < UINT32_MAX); + gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn); + } + } +} + +void __init create_domUs(void) +{ + struct dt_device_node *node; + const char *dom0less_iommu; + bool iommu = false; + const struct dt_device_node *cpupool_node, + *chosen = dt_find_node_by_path("/chosen"); + const char *llc_colors_str = NULL; + + BUG_ON(chosen == NULL); + dt_for_each_child_node(chosen, node) + { + struct domain *d; + struct xen_domctl_createdomain d_cfg = {0}; + unsigned int flags = 0U; + bool has_dtb = false; + uint32_t val; + int rc; + + if ( !dt_device_is_compatible(node, "xen,domain") ) + continue; + + if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED ) + panic("No more domain IDs available\n"); + + d_cfg.max_evtchn_port = 1023; + d_cfg.max_grant_frames = -1; + d_cfg.max_maptrack_frames = -1; + d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version); + + if ( dt_property_read_u32(node, "capabilities", &val) ) + { + if ( val & ~DOMAIN_CAPS_MASK ) + panic("Invalid capabilities (%"PRIx32")\n", val); + + if ( val & DOMAIN_CAPS_CONTROL ) + flags |= CDF_privileged; + + if ( val & DOMAIN_CAPS_HARDWARE ) + { + if ( hardware_domain ) + panic("Only 1 hardware domain can be specified! (%pd)\n", + hardware_domain); + + d_cfg.max_grant_frames = gnttab_dom0_frames(); + d_cfg.max_evtchn_port = -1; + flags |= CDF_hardware; + iommu = true; + } + + if ( val & DOMAIN_CAPS_XENSTORE ) + { + if ( xs_domid != DOMID_INVALID ) + panic("Only 1 xenstore domain can be specified! (%u)\n", + xs_domid); + + d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain; + d_cfg.max_evtchn_port = -1; + } + } + + if ( dt_find_property(node, "xen,static-mem", NULL) ) + { + if ( llc_coloring_enabled ) + panic("LLC coloring and static memory are incompatible\n"); + + flags |= CDF_staticmem; + } + + if ( dt_property_read_bool(node, "direct-map") ) + { + if ( !(flags & CDF_staticmem) ) + panic("direct-map is not valid for domain %s without static allocation.\n", + dt_node_name(node)); + + flags |= CDF_directmap; + } + + if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) ) + panic("Missing property 'cpus' for domain %s\n", + dt_node_name(node)); + + if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) ) + { + if ( flags & CDF_hardware ) + panic("Don't specify passthrough for hardware domain\n"); + + if ( !strcmp(dom0less_iommu, "enabled") ) + iommu = true; + } + + if ( (flags & CDF_hardware) && !(flags & CDF_directmap) && + !iommu_enabled ) + panic("non-direct mapped hardware domain requires iommu\n"); + + if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") ) + { + if ( flags & CDF_hardware ) + panic("\"multiboot,device-tree\" incompatible with hardware domain\n"); + + has_dtb = true; + } + + if ( iommu_enabled && (iommu || has_dtb) ) + d_cfg.flags |= XEN_DOMCTL_CDF_iommu; + + /* Get the optional property domain-cpupool */ + cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0); + if ( cpupool_node ) + { + int pool_id = btcpupools_get_domain_pool_id(cpupool_node); + if ( pool_id < 0 ) + panic("Error getting cpupool id from domain-cpupool (%d)\n", + pool_id); + d_cfg.cpupool_id = pool_id; + } + + if ( dt_property_read_u32(node, "max_grant_version", &val) ) + d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val); + + if ( dt_property_read_u32(node, "max_grant_frames", &val) ) + { + if ( val > INT32_MAX ) + panic("max_grant_frames (%"PRIu32") overflow\n", val); + d_cfg.max_grant_frames = val; + } + + if ( dt_property_read_u32(node, "max_maptrack_frames", &val) ) + { + if ( val > INT32_MAX ) + panic("max_maptrack_frames (%"PRIu32") overflow\n", val); + d_cfg.max_maptrack_frames = val; + } + + dt_property_read_string(node, "llc-colors", &llc_colors_str); + if ( !llc_coloring_enabled && llc_colors_str ) + panic("'llc-colors' found, but LLC coloring is disabled\n"); + + arch_create_domUs(node, &d_cfg, flags); + + /* + * The variable max_init_domid is initialized with zero, so here it's + * very important to use the pre-increment operator to call + * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0) + */ + d = domain_create(++max_init_domid, &d_cfg, flags); + if ( IS_ERR(d) ) + panic("Error creating domain %s (rc = %ld)\n", + dt_node_name(node), PTR_ERR(d)); + + if ( llc_coloring_enabled && + (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) ) + panic("Error initializing LLC coloring for domain %s (rc = %d)\n", + dt_node_name(node), rc); + + d->is_console = true; + dt_device_set_used_by(node, d->domain_id); + + rc = construct_domU(d, node); + if ( rc ) + panic("Could not set up domain %s (rc = %d)\n", + dt_node_name(node), rc); + + if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain ) + set_xs_domain(d); + } + + if ( need_xenstore && xs_domid == DOMID_INVALID ) + panic("xenstore requested, but xenstore domain not present\n"); + + initialize_domU_xenstore(); +} diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h new file mode 100644 index 0000000000..5655571a66 --- /dev/null +++ b/xen/include/asm-generic/dom0less-build.h @@ -0,0 +1,49 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef __ASM_GENERIC_DOM0LESS_BUILD_H__ +#define __ASM_GENERIC_DOM0LESS_BUILD_H__ + +#include + +#ifdef CONFIG_DOM0LESS_BOOT + +#include + +struct domain; +struct dt_device_node; + +/* TODO: remove both when construct_domU() will be moved to common. */ +#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX +extern bool need_xenstore; + +void create_domUs(void); +bool is_dom0less_mode(void); +void set_xs_domain(struct domain *d); + +int construct_domU(struct domain *d, const struct dt_device_node *node); + +void arch_create_domUs(struct dt_device_node *node, + struct xen_domctl_createdomain *d_cfg, + unsigned int flags); + +#else /* !CONFIG_DOM0LESS_BOOT */ + +static inline void create_domUs(void) {} +static inline bool is_dom0less_mode(void) +{ + return false; +} +static inline void set_xs_domain(struct domain *d) {} + +#endif /* CONFIG_DOM0LESS_BOOT */ + +#endif /* __ASM_GENERIC_DOM0LESS_BUILD_H__ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 16:22:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 16:22:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974788.1362590 (Exim 4.92) (envelope-from ) id 1uAtA1-0006pn-Qk; Fri, 02 May 2025 16:22:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974788.1362590; Fri, 02 May 2025 16:22: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 1uAtA1-0006oX-KB; Fri, 02 May 2025 16:22:49 +0000 Received: by outflank-mailman (input) for mailman id 974788; Fri, 02 May 2025 16:22:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAt9z-0005rZ-Lx for xen-devel@lists.xenproject.org; Fri, 02 May 2025 16:22:47 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id aefd9725-2771-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 18:22:47 +0200 (CEST) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-ac2dfdf3c38so403589066b.3 for ; Fri, 02 May 2025 09:22:47 -0700 (PDT) Received: from fedora.. (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad1894c01f2sm68158766b.119.2025.05.02.09.22.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 09:22:45 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aefd9725-2771-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746202966; x=1746807766; 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; bh=+JrfvyxSkM64biX/am1b6/5d/FYxpOpOjwig6QZTZeo=; b=Z/P/C2+vOld7vSi0p4IgWn/3sXZWR/82a+xIVcBzNyw24qA9v5INVpoX7m2hqvYYJh TTScRbNwk60qKwUF5PqRSrG4sYwJ+1mBQjFM6i+/gR0rx2MKss5dPx+0P6UJgdh3hHFd +Ubt4xqE8o4c8u7WOPJeQ/6eJebFQlAtDIwkddYdzbIyNP52Y9ivaqn6ElhfFgfTHGNG ZLnuSEbWP3OzLIpAmUxYJBO7LYicPzUq8lDG3kl+ZOsDpNXhbtZPm89oA+pYuNqO2l3Z ldZFJLHjCEbQO67Vx05qN7bEAAUM/q2DQ9lcu0hQdcJL22gXn5QggJsuNk2APTAE7n1t U1FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746202966; x=1746807766; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+JrfvyxSkM64biX/am1b6/5d/FYxpOpOjwig6QZTZeo=; b=nPBEQuNQbw+7WtU5os6OV69QeIvY+keOk5Rq4lkzCX6U6KQZplgEhJFXiXEde+tWf9 4Uxf/Jp+N1Rq14tvaoo1lnj7WV2xERW9D3Mz1VXNIC6aCV5VZfmlNDYnmhZvptVWPL+Q Uf3JyQbqXbAsokslDAFT/8KNDVDtuL03CXOizeOG4iA45Vw4ar0tg84mRA9aXkw40/Wp jjXmTNAdxFufYDTnvipOFxTXHJ7GLGzoMgfjBWLoBzkxbUZL64+W4LTmhGB4HL5TBQPU hxhBvTkjvP5pDZJvztRHdcDhJpZGIfX9fahUGZHVb+BFEHibRP0R4KeQRXudSoEH65cu tgCw== X-Gm-Message-State: AOJu0YzBni+OxOywrwdoUL3BJm7EbYHhD/4SbYkC4ki3g6voEGD4C8bl CBQ5JUvjAlrG43B41oP9WgdzJleplIkAjh516YVDaxko+sMoHcyz/W5Svw== X-Gm-Gg: ASbGncuXHdMSreGfk0/SSn2q4S4lddgvtVDl4A8r3mYUdv/xgkwOmVoN/rBX0ZGQMbx 2tMRoNK4yCu4m+WpX29p6I8ijX2TI3tUZ5oJKsBY8LOJQRZL7XSNnEbm+uicv8CPQaOY46AU/y0 fA/MDuDfM8eDJYJcEqzgw7kVOQzpc5OHbPm8S+z13h30DJgLkEcu55KedoS9HIPUeqkEfmx4DZa BRkI2XDNGEuyS5Hm+SFotUSQjg20o7M/i8Ojrsw8Av4iGQSWEBm8SmcQbQLo39l+3LreLOSxwRF BApaIai8qHyrFZ0Ky9o/8dmexTJ69o78cpIP0esY7yL4Ye2juNCFPa6AXJwvh6+E+mOrsLiuBIY IfMDAGi7g2A== X-Google-Smtp-Source: AGHT+IGpvTrTs4R9+cvgRyOaBz28ykGN+IVQHA9MrRTcQ2GDeRdCTzBEXuHwDhoQTH1aibTwzjquoA== X-Received: by 2002:a17:906:9c8c:b0:ac2:d0e6:2b99 with SMTP id a640c23a62f3a-ad17adc78d2mr327424366b.36.1746202966176; Fri, 02 May 2025 09:22:46 -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 v3 5/8] asm-generic: move some parts of Arm's domain_build.h to common Date: Fri, 2 May 2025 18:22:35 +0200 Message-ID: X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Nothing changed. Only some functions declaration are moved to xen/include/ headers as they are expected to be used by common code of domain builing or dom0less. Signed-off-by: Oleksii Kurochko --- Chnages in v3: - Drop inclusion of from xen/fdt-domain-build.h. - Add empty line after license tag in xen/fdt-domain-build.h. --- Chnages in v2: - Add missed declaration of construct_hwdom(). - Drop unnessary blank line. - Introduce xen/fdt-domain-build.h and move parts of Arm's domain_build.h to it. - Update the commit message. --- xen/arch/arm/acpi/domain_build.c | 1 + xen/arch/arm/dom0less-build.c | 1 + xen/arch/arm/domain_build.c | 1 + xen/arch/arm/include/asm/domain_build.h | 21 ++---------- xen/arch/arm/kernel.c | 1 + xen/arch/arm/static-shmem.c | 1 + xen/include/xen/fdt-domain-build.h | 43 +++++++++++++++++++++++++ 7 files changed, 51 insertions(+), 18 deletions(-) create mode 100644 xen/include/xen/fdt-domain-build.h diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c index f9ca8b47e5..1c3555d814 100644 --- a/xen/arch/arm/acpi/domain_build.c +++ b/xen/arch/arm/acpi/domain_build.c @@ -10,6 +10,7 @@ */ #include +#include #include #include #include diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 7eecd06d44..0310579863 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -1,6 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ #include #include +#include #include #include #include diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 8c7a054718..9d649b06b3 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1,6 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ #include #include +#include #include #include #include diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h index df1c0fe301..397e408a1f 100644 --- a/xen/arch/arm/include/asm/domain_build.h +++ b/xen/arch/arm/include/asm/domain_build.h @@ -5,28 +5,13 @@ #include typedef __be32 gic_interrupt_t[3]; -typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg, - unsigned int order, void *extra); -bool allocate_domheap_memory(struct domain *d, paddr_t tot_size, - alloc_domheap_mem_cb cb, void *extra); -bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, - paddr_t tot_size); -void allocate_memory(struct domain *d, struct kernel_info *kinfo); -int construct_domain(struct domain *d, struct kernel_info *kinfo); -int construct_hwdom(struct kernel_info *kinfo, - const struct dt_device_node *node); + int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit); -int make_chosen_node(const struct kernel_info *kinfo); -int make_cpus_node(const struct domain *d, void *fdt); -int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo, - int addrcells, int sizecells); -int make_memory_node(const struct kernel_info *kinfo, int addrcells, - int sizecells, const struct membanks *mem); int make_psci_node(void *fdt); -int make_timer_node(const struct kernel_info *kinfo); void evtchn_allocate(struct domain *d); -unsigned int get_allocation_size(paddr_t size); +int construct_hwdom(struct kernel_info *kinfo, + const struct dt_device_node *node); /* * Helper to write an interrupts with the GIC format diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c index f00fc388db..5759a3470a 100644 --- a/xen/arch/arm/kernel.c +++ b/xen/arch/arm/kernel.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c index 14ae48fb1e..1f8441d920 100644 --- a/xen/arch/arm/static-shmem.c +++ b/xen/arch/arm/static-shmem.c @@ -1,6 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ #include +#include #include #include #include diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h new file mode 100644 index 0000000000..b79e9fabfe --- /dev/null +++ b/xen/include/xen/fdt-domain-build.h @@ -0,0 +1,43 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef __XEN_FDT_DOMAIN_BUILD_H__ +#define __XEN_FDT_DOMAIN_BUILD_H__ + +#include +#include +#include +#include + +struct domain; +struct page_info; +struct membanks; + +typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg, + unsigned int order, void *extra); +bool allocate_domheap_memory(struct domain *d, paddr_t tot_size, + alloc_domheap_mem_cb cb, void *extra); + +bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, + paddr_t tot_size); +void allocate_memory(struct domain *d, struct kernel_info *kinfo); +int construct_domain(struct domain *d, struct kernel_info *kinfo); +int make_chosen_node(const struct kernel_info *kinfo); +int make_cpus_node(const struct domain *d, void *fdt); +int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo, + int addrcells, int sizecells); +int make_memory_node(const struct kernel_info *kinfo, int addrcells, + int sizecells, const struct membanks *mem); +int make_timer_node(const struct kernel_info *kinfo); + +unsigned int get_allocation_size(paddr_t size); + +#endif /* __XEN_FDT_DOMAIN_BUILD_H__ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 16:22:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 16:22:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974783.1362544 (Exim 4.92) (envelope-from ) id 1uAt9y-0005rm-3e; Fri, 02 May 2025 16:22:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974783.1362544; Fri, 02 May 2025 16:22:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAt9y-0005rf-13; Fri, 02 May 2025 16:22:46 +0000 Received: by outflank-mailman (input) for mailman id 974783; Fri, 02 May 2025 16:22:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAt9x-0005rZ-0p for xen-devel@lists.xenproject.org; Fri, 02 May 2025 16:22:45 +0000 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [2a00:1450:4864:20::62b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ac7837b7-2771-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 18:22:42 +0200 (CEST) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-aca99fc253bso347466866b.0 for ; Fri, 02 May 2025 09:22:42 -0700 (PDT) Received: from fedora.. (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad1894c01f2sm68158766b.119.2025.05.02.09.22.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 09:22:41 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ac7837b7-2771-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746202962; x=1746807762; 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; bh=n/XI4d+aGEAu3W8N5OXyAiG/e9D9J/dXw/QpLzSeH60=; b=d2bPKH9joldNLChSA0Ien9N4z0aFxamZa4C14nbrfVfJdjPRRQcNyvwwKLn6mnliE3 xUemhwBapCxUMutZhobflthzmjWw6HY+9hQiluv7QGuE+Yol44wzUl9h1hocXjhgR13B 99zSVcmzOo+YUd7smVbiuLsyKgn82JdO3jGsim3mb/+Dp9RVqwWPaiiI16pHVw2JisX9 5c3HSRna5TFTyHXHtymU7etmSG4FoHkUy9ZiAL9pPX+k5IwJvsB58THk/gm6ksey9R12 SyFV90ZGN8d1TlKeFx0iMDvSQTNnNovGE93Im4yqajNjndVxKVeEWSKPwHd5/4LEUcoz cqsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746202962; x=1746807762; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=n/XI4d+aGEAu3W8N5OXyAiG/e9D9J/dXw/QpLzSeH60=; b=lAV8iTQAsOQM+qcLuOZ9nsLxqoPsLV9LdSFHkXTo0W1usZBpgTK7YYauXaFgdOcRhg u+he+kcNx//6MuTzDHTOJE1jLSvWg0VGf8XWBHv6raOvtz9cuijQTe1xrOIaDZAr9L7h Af/y0WmffiI4pjzeX3xXZho76sHZ2oXzUw79pDo/XWbqlHTEjDCzihNHdBjx6rk39syI 4fNd0S3BfnxcU3npwXBvAx0Wys5llM7SCj1VwZJ4gWiHNSqSfe4YGOU0xBA/Ogq/eOwX YHaSeSfEPDW12Tz3W8Lpmu/2ulVlOZXyguVNZN601bKMOrmyGl1TjuZZxUQ0LoV+h/A5 +9AQ== X-Gm-Message-State: AOJu0Yw33NViZx9jTagSvheMpzjePsFNyfD7UXAgCc3IOAvC7s7weS10 i16ztoxZy8otPqo2IjNVt+NIoRY0uLIAuTF6xhFScbC6ebwoVtpO6XZ/IA== X-Gm-Gg: ASbGncv4+qJKpcC1K+DMimSGXdwMpETPiUkzJ6AOsmwo/J4fDZh873AzI1XmRcvZ5gd 3yXcURedxS0wK0DD8/2bztAQTbjOFswrqC56SdxAO34D8igmp39m/431xlFG5VZgdmy1BJNexLD kd9azmDsWFHYmWh1pCKDx0t2zFA+iudAAf2DdD/DQNLGXGh+m2AQMxFIUFnPFjDG1vaaCuylnZE zq8jR3Y0GrQ0p/rbrVinAJ3WGFdRiF3U3WBD1xU6/8xjK9BAlVD7x3CkONm/pPa+vTX2Rs+9vr9 AlX2Jc44a/xaysG2djXeQdrn/yGumxFbwBONp8SN7Y8QSuGZQbJV6y3ZMG9Yol3RQcQSmQL91X9 Rg4kS188Xyu+q2PIJoMu+ X-Google-Smtp-Source: AGHT+IHcEdh3kTSRS+zA/pHD951bZuVy/SgDsrgVZMtcEdqrJOEeMR8KgJ1YDXIUD8XLa13yuN4+xQ== X-Received: by 2002:a17:907:60cf:b0:acb:b5a4:ba35 with SMTP id a640c23a62f3a-ad17ad397d6mr372957566b.2.1746202961835; Fri, 02 May 2025 09:22:41 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v3 1/8] xen/arm: drop declaration of handle_device_interrupts() Date: Fri, 2 May 2025 18:22:31 +0200 Message-ID: <790c29f1e564190909e74433fee5a694a1d22551.1746199009.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit There is no definition of handle_device_interrupts() thereby it could be dropped. Signed-off-by: Oleksii Kurochko Reviewed-by: Michal Orzel --- Change in v3: - Update commit message - Add Reviewed-by: Michal Orzel . --- xen/arch/arm/include/asm/domain_build.h | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h index 17619c875d..378c10cc98 100644 --- a/xen/arch/arm/include/asm/domain_build.h +++ b/xen/arch/arm/include/asm/domain_build.h @@ -28,17 +28,6 @@ void evtchn_allocate(struct domain *d); unsigned int get_allocation_size(paddr_t size); -/* - * handle_device_interrupts retrieves the interrupts configuration from - * a device tree node and maps those interrupts to the target domain. - * - * Returns: - * < 0 error - * 0 success - */ -int handle_device_interrupts(struct domain *d, struct dt_device_node *dev, - bool need_mapping); - /* * Helper to write an interrupts with the GIC format * This code is assuming the irq is an PPI. -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 16:22:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 16:22:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974784.1362555 (Exim 4.92) (envelope-from ) id 1uAt9z-00065Z-Ah; Fri, 02 May 2025 16:22:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974784.1362555; Fri, 02 May 2025 16:22: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 1uAt9z-00065S-7E; Fri, 02 May 2025 16:22:47 +0000 Received: by outflank-mailman (input) for mailman id 974784; Fri, 02 May 2025 16:22:46 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAt9y-0005rY-2a for xen-devel@lists.xenproject.org; Fri, 02 May 2025 16:22:46 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ac2a5baf-2771-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 18:22:42 +0200 (CEST) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-ac3eb3fdd2eso410898466b.0 for ; Fri, 02 May 2025 09:22:42 -0700 (PDT) Received: from fedora.. (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad1894c01f2sm68158766b.119.2025.05.02.09.22.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 09:22: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" X-Inumbo-ID: ac2a5baf-2771-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746202961; x=1746807761; 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; bh=cBkqvfa83/w8FH/oYkNwhPdcb80eMsIuC1GvNe/PNEQ=; b=lgDnUksk5AnC/CtkyfcKVQDrvC9+2m+waqOUN1s5NTLJ3r6MaaviO4cTk96X0rmWF5 noJSP5JkXtjzqLXu2Pk94ug6+utWczvNhvktp3aCm2Yegy/d4bFt/LknwKPtEnMevpaU fwTtcTgKMsz4uqbD4kVmSnmZ21Dx4GFmG6q80SMQhqwHpe1GeYrkITu/VLdxJJl9MpTE KQtDMBSyq3JAi8Kk3WC1hXQplsok04aoPFEN0EWVFedMIKTDgnXiwz+MtrSVMtVPdS9c /5EMHRFFytuJvKBAr6LXSRv2a8/pSwuvqevRdnTQEz1lCOQCh3l1PtfxmXBSUyAJOE1K 7PTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746202961; x=1746807761; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cBkqvfa83/w8FH/oYkNwhPdcb80eMsIuC1GvNe/PNEQ=; b=tX2ANk1qEqStzzt49SuYBGGHLru0PPgAhPYlZKg4QsrNAulf+KHab0M0zseGMJDgji JszfR8iTNg+7mJADM9swiFwr+KsFWeAUzUqKdsRJMAAvKCvTOIdTnypJPjKxsiZPODI8 OqFfWyyOPoqLuWp+nWRC0+3GaTIsvz2T+yScWPwECk8PgfVX3ZFl3sRy4BAtcnbWK8XY CB1zJ3ppQzbyPrp41/ynqCj2ETk064iT8saIhMJZvthCecu7Nu5Tl47OWs755hR/GYkt 1HcVKNBlT9Uk9zVj+5ZagztjOB0yd4S+ibdlLLJQQd71rkl2+y1PG8EV2FrgEYsfIk6g J1Kw== X-Gm-Message-State: AOJu0Yw9zKigBavVphf6mrLVtbB26QuZlWv3pjP+Bm1nE6jR6f1Dt0kj vi7LkTsAtoyQTUJ+9Tsm1CZRN8loL2PMjbnfooWN1ov9wzBSUoVVkaM9Zw== X-Gm-Gg: ASbGncvDAZxxpzu3qQdfue+kRmxz0KItB60AWMAqkdLdQ6j0gtzHPNs7Wu3vnoLWw90 MoVvDkuURRnvRtBo2kp6flNpxEjMeeLmIYg2w9JRR8n9pwmxJAVU4Jv8eJ/WXUrsG9xFAmu5WZs zk0TMM3QsMUBYLgQ4kt95cA/E5WVi/n04W04LIk+RJG+ykVnlu21MrftDkLPvYTpfDra5jpuQR8 jQnGJyfkvOV31AHkpwt6+fjEi9ElCiXWlh14FKscn/RkPpLcwULxong9CPIhZr1VtEylgvZpXjj FufZQdVw5Jo0SHSPdiUldll3rxRfT+xUK487h0gIISa9jUHva92ldX3zSzmX29dvL/teiJe8k1A sDOOge8rbALTnbq+jCYx0 X-Google-Smtp-Source: AGHT+IFMnuxtxTtdpt9uQVt9/t3i9XRV8naC2tluiSjJp/uyxLs8qEl4wiZEeXqCP1uUQfIm26YpGw== X-Received: by 2002:a17:907:2ce4:b0:ac6:e33e:9ef8 with SMTP id a640c23a62f3a-ad17b471928mr341697566b.2.1746202961169; Fri, 02 May 2025 09:22:41 -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 v3 0/8] Move parts of Arm's Dom0less to common code Date: Fri, 2 May 2025 18:22:30 +0200 Message-ID: X-Mailer: git-send-email 2.49.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Some parts of Arm's Dom0less solution could be moved to common code as they are not truly Arm-specific. Most of the code is moved as is, with only minor changes introduced to provide abstractions that hide Arm-specific details, while maintaining functional equivalence with original Arm's code. There are several open questions: 1. The u64 and u32 types are widely used in the code where device tree functionality is implemented because these types are used in device tree function arguments. Should this be reworked to use uint32_t and uint64_t instead? If so, will it also be necessary to change the type of variables passed to dt-related functions, or should the argument types of device tree functions be updated too? For example: ``` u64 mem; ... rc = dt_property_read_u64(node, "memory", &mem); ``` where dt_property_read_u64 is declared as: bool dt_property_read_u64(... , u64 *out_value); 2. Instead of providing init_intc_phandle() (see the patch: [1]), perhaps it would be better to add a for loop in domain_handle_dtb_bootmodule()? Something like: ``` bool is_intc_phandle_inited = false; for ( unsigned int i = 0; i < ARRAY_SIZE(intc_names_array); i++ ) { if ( dt_node_cmp(name, intc_names_array[i]) == 0 ) { uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); if ( phandle_intc != 0 ) kinfo->phandle_intc = phandle_intc; is_intc_phandle_inited = true; break; } } if ( is_intc_phandle_inited ) continue; ``` 3. Should I rename everything connected to dom0less to predefined domains now? Or could it be a separate patch series? CI's test for the current patch series: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1797667269 --- Changes in v3: - Rebase on top of current staging and fixing merge conflicts. - Ingrate changes done in the commit: "xen/arm: dom0less delay xenstore initialization" - All other changes please look in the specific patch. - Update cover letter message. --- Changes in v2: - Update cover letter message. - Rebase on top of the current staging. - Drop patches: - asm-generic: move Arm's static-memory.h to asm-generic - asm-generic: move Arm's static-shmem.h to asm-generic as in the nearest future there is no real users of STATIC_MEMORY and STATIC_SHMEM. - Add new cleanup patch: [PATCH v2 1/8] xen/arm: drop declaration of handle_device_interrupts() - All other changes are patch specific. Please check them seprately for each patch --- Oleksii Kurochko (8): xen/arm: drop declaration of handle_device_interrupts() xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common asm-generic: move parts of Arm's asm/kernel.h to common code arm/static-shmem.h: drop inclusion of asm/setup.h asm-generic: move some parts of Arm's domain_build.h to common xen/common: dom0less: introduce common kernel.c xen/common: dom0less: introduce common domain-build.c xen/common: dom0less: introduce common dom0less-build.c xen/arch/arm/Kconfig | 10 +- xen/arch/arm/acpi/domain_build.c | 3 +- xen/arch/arm/dom0less-build.c | 1078 ++------------------- xen/arch/arm/domain_build.c | 410 +------- xen/arch/arm/include/asm/Makefile | 1 + xen/arch/arm/include/asm/dom0less-build.h | 34 - xen/arch/arm/include/asm/domain_build.h | 34 +- xen/arch/arm/include/asm/kernel.h | 126 +-- xen/arch/arm/include/asm/static-memory.h | 2 +- xen/arch/arm/include/asm/static-shmem.h | 2 +- xen/arch/arm/kernel.c | 234 +---- xen/arch/arm/static-memory.c | 1 + xen/arch/arm/static-shmem.c | 2 + xen/common/Kconfig | 20 + xen/common/device-tree/Makefile | 3 + xen/common/device-tree/dom0less-build.c | 982 +++++++++++++++++++ xen/common/device-tree/domain-build.c | 404 ++++++++ xen/common/device-tree/dt-overlay.c | 4 +- xen/common/device-tree/kernel.c | 242 +++++ xen/include/asm-generic/dom0less-build.h | 83 ++ xen/include/asm-generic/kernel.h | 141 +++ xen/include/xen/fdt-domain-build.h | 74 ++ xen/include/xen/fdt-kernel.h | 146 +++ 23 files changed, 2231 insertions(+), 1805 deletions(-) delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h create mode 100644 xen/common/device-tree/dom0less-build.c create mode 100644 xen/common/device-tree/domain-build.c create mode 100644 xen/common/device-tree/kernel.c create mode 100644 xen/include/asm-generic/dom0less-build.h create mode 100644 xen/include/asm-generic/kernel.h create mode 100644 xen/include/xen/fdt-domain-build.h create mode 100644 xen/include/xen/fdt-kernel.h -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 16:22:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 16:22:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974787.1362584 (Exim 4.92) (envelope-from ) id 1uAtA1-0006lP-FM; Fri, 02 May 2025 16:22:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974787.1362584; Fri, 02 May 2025 16:22: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 1uAtA1-0006kl-Ap; Fri, 02 May 2025 16:22:49 +0000 Received: by outflank-mailman (input) for mailman id 974787; Fri, 02 May 2025 16:22:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAt9z-0005rY-Lg for xen-devel@lists.xenproject.org; Fri, 02 May 2025 16:22:47 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ae782e10-2771-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 18:22:46 +0200 (CEST) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-ace3b03c043so324833566b.2 for ; Fri, 02 May 2025 09:22:46 -0700 (PDT) Received: from fedora.. (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad1894c01f2sm68158766b.119.2025.05.02.09.22.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 09:22:45 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ae782e10-2771-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746202965; x=1746807765; 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; bh=GUnfT2l87qKF2diopszkoUIkPb5NuR2WPUZYnC7hfok=; b=UqivhO8hk9oL+PFMO3RH8AC5oPzvK4i6e94TB8Bs4u94VVuJhQiFREHSlbekRYTteS 8qDKAvG6aaFzpmChPvcLWaeEkU9TC6IZbSDPtxQdojpRhQcXVpD9bQ3rIjrpKy/hpjx+ h0oLBeSmswgWx8NrkXlH7ZneVSzpucNpVsCSa/BP4EA4Xzkx75EthcIznD2+iP7H/TVH ce5SrHFK/rJGLp8q3sC28e4cxU7833F51xWiOneGWy6y3jl52AuQGy8qUt+bnjc9fk0a +7h6SnG5ZMy0TZNb/Zxfz2fElUvXHRxhNNRThiGCGTZihQTARS80Nv6MBS6bCG2PBark tq0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746202965; x=1746807765; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GUnfT2l87qKF2diopszkoUIkPb5NuR2WPUZYnC7hfok=; b=Bu6WLeICisOBxdF+li+fUpZJHkxqW1ddmL6QZya0JSwvHByOoOcEtC5+K7o61C/1Ht f097k8thUI8VH5D9fzktmp/GjgkSvyJ+uLDuHzxbEv1TH/VmRJ3OSH4jlfUA6gkS0UBt JbSB64DpcOA5qq1ZMkrEsce+OcmeJb9OZuKq4XlDYjRg9+OXDKtciJNsoKIBIyBylQkh Bczj9ZeM9WVA/b0v+2MFdT3QPK22jYP6DIPShZ2ke4BATdjfjNaR3sJRr9GVz7nfDE8G JJFGUENtuqI9c5j3CIU/5RxcAshpRM5wWe6xsT32c9Rjw1eqIhP9r+K8YgYwGCtPr/+y 8ncg== X-Gm-Message-State: AOJu0YzYWTyxYa2xPAqLktu33/hgusSDXeo04SIUHJYfKvls0CnsvYn3 cI2+7PqjZBrIZH/Q38NUR5hGY5vJ4+poguePFnlf1DBXlv0l3Z4kOZVC1w== X-Gm-Gg: ASbGncvaXF1fm+BUEKSDGhqy1DJzWMhy4cNarPy6h10O+g+LN6yE699N3kBdxXls4FB LjFwp+zndSh6mAuMjrsdGpK+JdkLIJ4R3V1zsxtklYFFsEo5nLICR77TsIzxuzFqLzRN6+prwHC j6DUNQ8JHsAMXkKKnGiZ2zJoTXtdQFE6LWKg14IqFfk3p+hK8GbxtjSN+XWaKctWHTbwQEMHPcw UGjPTm17Cc9xm8XJXEOVgULBa5axHFasWpAGmkhHcBz9eIR+4OitDQoA88Qgw6+bfqbylVb7Y7a 8+sk1A5v1Wh9nxBJyGzedHl+33kk09D6UUFnHEVP4HFz450yTNze+P3zI+qx8dA1gZkEWZTbGXS TheAcsM0Plg== X-Google-Smtp-Source: AGHT+IGtFzwT6D6y10u4kO1tm8gVNtyNHsF29taj/ekvV8Ee/bnhSAIr3w8QQ8ZXv7tca3xsqBx1mw== X-Received: by 2002:a17:907:60cf:b0:ac3:446d:142 with SMTP id a640c23a62f3a-ad17ad39ff9mr376934066b.2.1746202965316; Fri, 02 May 2025 09:22:45 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v3 4/8] arm/static-shmem.h: drop inclusion of asm/setup.h Date: Fri, 2 May 2025 18:22:34 +0200 Message-ID: <5e02dc75f4f396d054e9b9206b9305889cadb1a5.1746199009.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Nothing is dependent from asm/setup.h in asm/static-shmem.h so inclusion of asm/setup.h is droped. After this drop the following compilation error related to impicit declaration of the following functions device_tree_get_reg and map_device_irqs_to_domain, device_tree_get_u32 occur during compilation of dom0less-build.c ( as they are declared in asm/setup.h ). Add inclusion of in dt-overlay.c as it is using handle_device() declared in . Signed-off-by: Oleksii Kurochko --- Changes in V2-3: - Nothing changed. Only rebase. --- xen/arch/arm/dom0less-build.c | 1 + xen/common/device-tree/dt-overlay.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index c0634dd61e..7eecd06d44 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include diff --git a/xen/common/device-tree/dt-overlay.c b/xen/common/device-tree/dt-overlay.c index 81107cb48d..d184186c01 100644 --- a/xen/common/device-tree/dt-overlay.c +++ b/xen/common/device-tree/dt-overlay.c @@ -13,6 +13,8 @@ #include #include +#include + #define DT_OVERLAY_MAX_SIZE KB(500) static LIST_HEAD(overlay_tracker); -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 16:22:55 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 16:22:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974786.1362567 (Exim 4.92) (envelope-from ) id 1uAtA0-0006Ep-2i; Fri, 02 May 2025 16:22:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974786.1362567; Fri, 02 May 2025 16:22:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAt9z-0006Cs-Rc; Fri, 02 May 2025 16:22:47 +0000 Received: by outflank-mailman (input) for mailman id 974786; Fri, 02 May 2025 16:22:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAt9y-0005rZ-ET for xen-devel@lists.xenproject.org; Fri, 02 May 2025 16:22:46 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id adf38485-2771-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 18:22:45 +0200 (CEST) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-acb5ec407b1so350766266b.1 for ; Fri, 02 May 2025 09:22:45 -0700 (PDT) Received: from fedora.. (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad1894c01f2sm68158766b.119.2025.05.02.09.22.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 09:22: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" X-Inumbo-ID: adf38485-2771-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746202964; x=1746807764; 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; bh=EFAs5QpEMZiGVQnaEa+bU01BSHSsYQBC71P0gj1yZJI=; b=IVqd0Cb5NtPyuEXPh+Sv4UQZCA+naZDqWajGaAeDxfplL2fNIAIWf+aeuv5wSIi9bK wXRBQ6zuqnXJYt6TD41mijoNcrw6kJWPeNgyMSBafeXkqbP7y1mc2WKit9kCiTlYOrIm 2fpuER+Eu7Ynl8XE6m4SRZrRsIVWi/oNwbiZ3iRXgv+Lc81XTRX4O4GL7apai1vV4Js3 WbIWq7UFR/SXnxg7My9TuDM4LFBzWiTf6MKv84L5dG3ezcS1c2r+J7vVfdE6PACjETdg e35uVeQqz04nyiBk1xVYdDL4LB98JdYTcx2Vr6Q3zL9IwwNwEq6ymeyuiooQZdzbQa9v sTpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746202964; x=1746807764; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EFAs5QpEMZiGVQnaEa+bU01BSHSsYQBC71P0gj1yZJI=; b=PxqxpJeQf0X1eAFvG98aJuSWCWEYPXtNZRL3zkCUHWI3A3vxtzx9tSaG1qbMRZRpJc wYXs2iUxfPbAnYeZhOO7suJH2gwKHM5MofWKSjALramI2McNN1nOESDjlIIWiLnikB2w Hp+69kP8+HG071JPQxHy6IXE5Z89Ojp11pjeuL6+FFiKq4A444ooYQOo23fkaZIMSv7g 5qLiEXfnpIvcN3dtDsYisVok4WuU6QoAN2D8WiacDLWquY/Md9TGElFOw4tRLqteKlF5 mwbm4oai5NoAxn8BWuAVNKMSzOneMRFVxL6h9dxYsxVxUXCpiBh/gRm4LGtCz2bUYxAl hflA== X-Gm-Message-State: AOJu0Yy6TLcUD+kcn8ihxT10YHsADUU/ivL0WOoddFOHu6k4evl1ZVEF HfP/pTiv4sj7b6NkBvGey18YeMz10CchNuVUehjmSUhIaX0yJXI8pCzNXg== X-Gm-Gg: ASbGncvK+LaaH8LWuUCySPtYr1TZorLfz1BcmIRY4qh/7FhMzpHf1qpCoxaRg5fhnkw GKKXMy9eakRqy8AowrZXQcZYyTRJo1wGYZ8BUlDZwDMGjy5PDG0q2Vt/EtOnqyLSKf5QW02Cl0K +DuQ/c8HBQgorhXfBAXb4EsH7XhXJZ9p527EwFnskoCLhmaGJcyqqoJ/EilRZCqVWnwQoVVWmgF Uwo7/bn/do9YFtf0BDJ5jgiR7LSTOJhCrnb3uBsZNa/cesQGWoy0mrgJNvfQ5ev/0bkiAADxSJB APkHMxK2XoDx1lLLE7T6PNuo6Me1tcy/QUyRUe0OHnhqyWTgMZrzXzV+cElegybikrJiq/bQkzw J3RmnK6gHRg== X-Google-Smtp-Source: AGHT+IG41K40YYS4kZTEzP/j/FNULhrVewtRhe65Dr55/B8N+pjqrBt0RnFpsySUUXw8H+l8zwZLPw== X-Received: by 2002:a17:907:94d0:b0:ac7:95ae:747f with SMTP id a640c23a62f3a-ad17af8f52cmr311730866b.45.1746202964218; Fri, 02 May 2025 09:22:44 -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 v3 3/8] asm-generic: move parts of Arm's asm/kernel.h to common code Date: Fri, 2 May 2025 18:22:33 +0200 Message-ID: <0c16f8fb2702db5fd6751c7da347a97caa431002.1746199009.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Move the following parts to common with the following changes: - struct kernel_info: - Create arch_kernel_info for arch specific kernel information. At the moment, it contains domain_type for Arm. - Rename vpl011 to vuart to have more generic name suitable for other archs. - s/phandle_gic/phandle_intc to have more generic name suitable for other archs. - Make text_offset of zimage structure available for RISCV_64. - Wrap by `#ifdef KERNEL_INFO_SHM_MEM_INIT` definition of KERNEL_SHM_MEM_INIT and wrap by `#ifndef KERNEL_INFO_INIT` definition of KERNEL_INFO_INIT to have ability to override KERNEL_INFO_SHM_MEM_INIT for arch in case it doesn't want to use generic one. - Move DOM0LESS_* macros to dom0less-build.h. - Move all others parts of Arm's kernel.h to xen/fdt-kernel.h. Because of the changes in struct kernel_info the correspondent parts of Arm's code are updated. As part of this patch the following clean up happens: - Drop asm/setup.h from asm/kernel.h as nothing depends from it. Add inclusion of asm/setup.h for a code which uses device_tree_get_reg() to avoid compilation issues for CONFIG_STATIC_MEMORY and CONFIG_STATIC_SHM. - Drop inclusion of asm/kernel.h everywhere except xen/fdt-kernel.h. Signed-off-by: Oleksii Kurochko --- Changes in v3: - Only resolving of merge conflicts. --- Changes in v2: - Introduce xen/fdt-kernel.h. - Move DOM0LESS_* macros to dom0less-build.h. - Move the rest in asm-generic/kernel.h to xen/fdt-kernel.h. - Drop inclusion of asm/kernel.h everywhere except xen/fdt-kernel.h. - Wrap by #if __has_include(....) the member of kernel_info structure: struct arch_kernel_info arch. - Update the commit message. --- xen/arch/arm/acpi/domain_build.c | 2 +- xen/arch/arm/dom0less-build.c | 31 +++--- xen/arch/arm/domain_build.c | 12 +- xen/arch/arm/include/asm/domain_build.h | 2 +- xen/arch/arm/include/asm/kernel.h | 126 +-------------------- xen/arch/arm/include/asm/static-memory.h | 2 +- xen/arch/arm/include/asm/static-shmem.h | 2 +- xen/arch/arm/kernel.c | 12 +- xen/arch/arm/static-memory.c | 1 + xen/arch/arm/static-shmem.c | 1 + xen/common/device-tree/dt-overlay.c | 2 +- xen/include/asm-generic/dom0less-build.h | 28 +++++ xen/include/xen/fdt-kernel.h | 133 +++++++++++++++++++++++ 13 files changed, 199 insertions(+), 155 deletions(-) create mode 100644 xen/include/xen/fdt-kernel.h diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c index 2ce75543d0..f9ca8b47e5 100644 --- a/xen/arch/arm/acpi/domain_build.c +++ b/xen/arch/arm/acpi/domain_build.c @@ -10,6 +10,7 @@ */ #include +#include #include #include #include @@ -18,7 +19,6 @@ #include #include #include -#include #include /* Override macros from asm/page.h to make them work with mfn_t */ diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index ef49495d4f..c0634dd61e 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -1,6 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ #include #include +#include #include #include #include @@ -64,11 +65,11 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo) if (res) return res; - res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic); + res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc); if (res) return res; - res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic); + res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc); if (res) return res; @@ -135,11 +136,11 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo) if (res) return res; - res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic); + res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc); if (res) return res; - res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic); + res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc); if (res) return res; @@ -200,7 +201,7 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo) return res; res = fdt_property_cell(fdt, "interrupt-parent", - kinfo->phandle_gic); + kinfo->phandle_intc); if ( res ) return res; @@ -486,10 +487,10 @@ static int __init domain_handle_dtb_bootmodule(struct domain *d, */ if ( dt_node_cmp(name, "gic") == 0 ) { - uint32_t phandle_gic = fdt_get_phandle(pfdt, node_next); + uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); - if ( phandle_gic != 0 ) - kinfo->phandle_gic = phandle_gic; + if ( phandle_intc != 0 ) + kinfo->phandle_intc = phandle_intc; continue; } @@ -532,7 +533,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) int addrcells, sizecells; int ret, fdt_size = DOMU_DTB_SIZE; - kinfo->phandle_gic = GUEST_PHANDLE_GIC; + kinfo->phandle_intc = GUEST_PHANDLE_GIC; kinfo->gnttab_start = GUEST_GNTTAB_BASE; kinfo->gnttab_size = GUEST_GNTTAB_SIZE; @@ -594,7 +595,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) /* * domain_handle_dtb_bootmodule has to be called before the rest of * the device tree is generated because it depends on the value of - * the field phandle_gic. + * the field phandle_intc. */ if ( kinfo->dtb_bootmodule ) { @@ -611,7 +612,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) if ( ret ) goto err; - if ( kinfo->vpl011 ) + if ( kinfo->vuart ) { ret = -EINVAL; #ifdef CONFIG_SBSA_VUART_CONSOLE @@ -839,8 +840,8 @@ int __init construct_domU(struct domain *d, printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n", d->max_vcpus, mem); - kinfo.vpl011 = dt_property_read_bool(node, "vpl011"); - if ( kinfo.vpl011 && is_hardware_domain(d) ) + kinfo.vuart = dt_property_read_bool(node, "vpl011"); + if ( kinfo.vuart && is_hardware_domain(d) ) panic("hardware domain cannot specify vpl011\n"); rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced); @@ -872,7 +873,7 @@ int __init construct_domU(struct domain *d, #ifdef CONFIG_ARM_64 /* type must be set before allocate memory */ - d->arch.type = kinfo.type; + d->arch.type = kinfo.arch.type; #endif if ( is_hardware_domain(d) ) { @@ -898,7 +899,7 @@ int __init construct_domU(struct domain *d, * tree node in prepare_dtb_domU, so initialization on related variables * shall be done first. */ - if ( kinfo.vpl011 ) + if ( kinfo.vuart ) { rc = domain_vpl011_init(d, NULL); if ( rc < 0 ) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 270a6b97e4..8c7a054718 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1,6 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ #include #include +#include #include #include #include @@ -20,7 +21,6 @@ #include #include #include -#include #include #include #include @@ -747,7 +747,7 @@ static int __init fdt_property_interrupts(const struct kernel_info *kinfo, return res; res = fdt_property_cell(kinfo->fdt, "interrupt-parent", - kinfo->phandle_gic); + kinfo->phandle_intc); return res; } @@ -2026,7 +2026,7 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo) ASSERT(dt_host && (dt_host->sibling == NULL)); - kinfo->phandle_gic = dt_interrupt_controller->phandle; + kinfo->phandle_intc = dt_interrupt_controller->phandle; fdt = device_tree_flattened; new_size = fdt_totalsize(fdt) + DOM0_FDT_EXTRA_SIZE; @@ -2196,13 +2196,13 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo) #ifdef CONFIG_ARM_64 /* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */ - if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT ) + if ( !(cpu_has_el1_32) && kinfo->arch.type == DOMAIN_32BIT ) { printk("Platform does not support 32-bit domain\n"); return -EINVAL; } - if ( is_sve_domain(d) && (kinfo->type == DOMAIN_32BIT) ) + if ( is_sve_domain(d) && (kinfo->arch.type == DOMAIN_32BIT) ) { printk("SVE is not available for 32-bit domain\n"); return -EINVAL; @@ -2318,7 +2318,7 @@ int __init construct_hwdom(struct kernel_info *kinfo, #ifdef CONFIG_ARM_64 /* type must be set before allocate_memory */ - d->arch.type = kinfo->type; + d->arch.type = kinfo->arch.type; #endif find_gnttab_region(d, kinfo); if ( is_domain_direct_mapped(d) ) diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h index 378c10cc98..df1c0fe301 100644 --- a/xen/arch/arm/include/asm/domain_build.h +++ b/xen/arch/arm/include/asm/domain_build.h @@ -1,8 +1,8 @@ #ifndef __ASM_DOMAIN_BUILD_H__ #define __ASM_DOMAIN_BUILD_H__ +#include #include -#include typedef __be32 gic_interrupt_t[3]; typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg, diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h index bdc96f4c18..cfeab792c7 100644 --- a/xen/arch/arm/include/asm/kernel.h +++ b/xen/arch/arm/include/asm/kernel.h @@ -6,137 +6,15 @@ #ifndef __ARCH_ARM_KERNEL_H__ #define __ARCH_ARM_KERNEL_H__ -#include #include -#include -/* - * List of possible features for dom0less domUs - * - * DOM0LESS_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All the - * default features (excluding Xenstore) will be - * available. Note that an OS *must* not rely on the - * availability of Xen features if this is not set. - * DOM0LESS_XENSTORE: Xenstore will be enabled for the VM. The - * xenstore page allocation is done by Xen at - * domain creation. This feature can't be - * enabled without the DOM0LESS_ENHANCED_NO_XS. - * DOM0LESS_XS_LEGACY Xenstore will be enabled for the VM, the - * xenstore page allocation will happen in - * init-dom0less. This feature can't be enabled - * without the DOM0LESS_ENHANCED_NO_XS. - * DOM0LESS_ENHANCED: Notify the OS it is running on top of Xen. All the - * default features (including Xenstore) will be - * available. Note that an OS *must* not rely on the - * availability of Xen features if this is not set. - * DOM0LESS_ENHANCED_LEGACY: Same as before, but using DOM0LESS_XS_LEGACY. - */ -#define DOM0LESS_ENHANCED_NO_XS BIT(0, U) -#define DOM0LESS_XENSTORE BIT(1, U) -#define DOM0LESS_XS_LEGACY BIT(2, U) -#define DOM0LESS_ENHANCED_LEGACY (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XS_LEGACY) -#define DOM0LESS_ENHANCED (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE) - -struct kernel_info { +struct arch_kernel_info +{ #ifdef CONFIG_ARM_64 enum domain_type type; #endif - - struct domain *d; - - void *fdt; /* flat device tree */ - paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */ - struct meminfo mem; -#ifdef CONFIG_STATIC_SHM - struct shared_meminfo shm_mem; -#endif - - /* kernel entry point */ - paddr_t entry; - - /* grant table region */ - paddr_t gnttab_start; - paddr_t gnttab_size; - - /* boot blob load addresses */ - const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule; - const char* cmdline; - paddr_t dtb_paddr; - paddr_t initrd_paddr; - - /* Enable pl011 emulation */ - bool vpl011; - - /* Enable/Disable PV drivers interfaces */ - uint16_t dom0less_feature; - - /* GIC phandle */ - uint32_t phandle_gic; - - /* loader to use for this kernel */ - void (*load)(struct kernel_info *info); - /* loader specific state */ - union { - struct { - paddr_t kernel_addr; - paddr_t len; -#ifdef CONFIG_ARM_64 - paddr_t text_offset; /* 64-bit Image only */ -#endif - paddr_t start; /* Must be 0 for 64-bit Image */ - } zimage; - }; }; -static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo) -{ - return container_of(&kinfo->mem.common, struct membanks, common); -} - -static inline const struct membanks * -kernel_info_get_mem_const(const struct kernel_info *kinfo) -{ - return container_of(&kinfo->mem.common, const struct membanks, common); -} - -#ifdef CONFIG_STATIC_SHM -#define KERNEL_INFO_SHM_MEM_INIT \ - .shm_mem.common.max_banks = NR_SHMEM_BANKS, \ - .shm_mem.common.type = STATIC_SHARED_MEMORY, -#else -#define KERNEL_INFO_SHM_MEM_INIT -#endif - -#define KERNEL_INFO_INIT \ -{ \ - .mem.common.max_banks = NR_MEM_BANKS, \ - .mem.common.type = MEMORY, \ - KERNEL_INFO_SHM_MEM_INIT \ -} - -/* - * Probe the kernel to detemine its type and select a loader. - * - * Sets in info: - * ->type - * ->load hook, and sets loader specific variables ->zimage - */ -int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain); - -/* - * Loads the kernel into guest RAM. - * - * Expects to be set in info when called: - * ->mem - * ->fdt - * - * Sets in info: - * ->entry - * ->dtb_paddr - * ->initrd_paddr - */ -void kernel_load(struct kernel_info *info); - #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */ /* diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/arch/arm/include/asm/static-memory.h index 804166e541..a32a3c6553 100644 --- a/xen/arch/arm/include/asm/static-memory.h +++ b/xen/arch/arm/include/asm/static-memory.h @@ -3,8 +3,8 @@ #ifndef __ASM_STATIC_MEMORY_H_ #define __ASM_STATIC_MEMORY_H_ +#include #include -#include #ifdef CONFIG_STATIC_MEMORY diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h index 94eaa9d500..a4f853805a 100644 --- a/xen/arch/arm/include/asm/static-shmem.h +++ b/xen/arch/arm/include/asm/static-shmem.h @@ -3,8 +3,8 @@ #ifndef __ASM_STATIC_SHMEM_H_ #define __ASM_STATIC_SHMEM_H_ +#include #include -#include #include #ifdef CONFIG_STATIC_SHM diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c index 2647812e8e..f00fc388db 100644 --- a/xen/arch/arm/kernel.c +++ b/xen/arch/arm/kernel.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -16,6 +17,7 @@ #include #include +#include #include #include @@ -101,7 +103,7 @@ static paddr_t __init kernel_zimage_place(struct kernel_info *info) paddr_t load_addr; #ifdef CONFIG_ARM_64 - if ( (info->type == DOMAIN_64BIT) && (info->zimage.start == 0) ) + if ( (info->arch.type == DOMAIN_64BIT) && (info->zimage.start == 0) ) return mem->bank[0].start + info->zimage.text_offset; #endif @@ -371,10 +373,10 @@ static int __init kernel_uimage_probe(struct kernel_info *info, switch ( uimage.arch ) { case IH_ARCH_ARM: - info->type = DOMAIN_32BIT; + info->arch.type = DOMAIN_32BIT; break; case IH_ARCH_ARM64: - info->type = DOMAIN_64BIT; + info->arch.type = DOMAIN_64BIT; break; default: printk(XENLOG_ERR "Unsupported uImage arch type %d\n", uimage.arch); @@ -444,7 +446,7 @@ static int __init kernel_zimage64_probe(struct kernel_info *info, info->load = kernel_zimage_load; - info->type = DOMAIN_64BIT; + info->arch.type = DOMAIN_64BIT; return 0; } @@ -496,7 +498,7 @@ static int __init kernel_zimage32_probe(struct kernel_info *info, info->load = kernel_zimage_load; #ifdef CONFIG_ARM_64 - info->type = DOMAIN_32BIT; + info->arch.type = DOMAIN_32BIT; #endif return 0; diff --git a/xen/arch/arm/static-memory.c b/xen/arch/arm/static-memory.c index d4585c5a06..e0f76afcd8 100644 --- a/xen/arch/arm/static-memory.c +++ b/xen/arch/arm/static-memory.c @@ -2,6 +2,7 @@ #include +#include #include static bool __init append_static_memory_to_bank(struct domain *d, diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c index e8d4ca3ba3..14ae48fb1e 100644 --- a/xen/arch/arm/static-shmem.c +++ b/xen/arch/arm/static-shmem.c @@ -6,6 +6,7 @@ #include #include +#include #include #include diff --git a/xen/common/device-tree/dt-overlay.c b/xen/common/device-tree/dt-overlay.c index 97fb99eaaa..81107cb48d 100644 --- a/xen/common/device-tree/dt-overlay.c +++ b/xen/common/device-tree/dt-overlay.c @@ -6,8 +6,8 @@ * Written by Vikram Garhwal * */ -#include #include +#include #include #include #include diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h index 5655571a66..f095135caa 100644 --- a/xen/include/asm-generic/dom0less-build.h +++ b/xen/include/asm-generic/dom0less-build.h @@ -16,6 +16,34 @@ struct dt_device_node; #define XENSTORE_PFN_LATE_ALLOC UINT64_MAX extern bool need_xenstore; +/* + * List of possible features for dom0less domUs + * + * DOM0LESS_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All the + * default features (excluding Xenstore) will be + * available. Note that an OS *must* not rely on the + * availability of Xen features if this is not set. + * DOM0LESS_XENSTORE: Xenstore will be enabled for the VM. The + * xenstore page allocation is done by Xen at + * domain creation. This feature can't be + * enabled without the DOM0LESS_ENHANCED_NO_XS. + * DOM0LESS_XS_LEGACY Xenstore will be enabled for the VM, the + * xenstore page allocation will happen in + * init-dom0less. This feature can't be enabled + * without the DOM0LESS_ENHANCED_NO_XS. + * DOM0LESS_ENHANCED: Notify the OS it is running on top of Xen. All the + * default features (including Xenstore) will be + * available. Note that an OS *must* not rely on the + * availability of Xen features if this is not set. + * DOM0LESS_ENHANCED_LEGACY: Same as before, but using DOM0LESS_XS_LEGACY. + + */ +#define DOM0LESS_ENHANCED_NO_XS BIT(0, U) +#define DOM0LESS_XENSTORE BIT(1, U) +#define DOM0LESS_XS_LEGACY BIT(2, U) +#define DOM0LESS_ENHANCED_LEGACY (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XS_LEGACY) +#define DOM0LESS_ENHANCED (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE) + void create_domUs(void); bool is_dom0less_mode(void); void set_xs_domain(struct domain *d); diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h new file mode 100644 index 0000000000..c81e759423 --- /dev/null +++ b/xen/include/xen/fdt-kernel.h @@ -0,0 +1,133 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * For Kernel image loading. + * + * Copyright (C) 2011 Citrix Systems, Inc. + */ +#ifndef __XEN_FDT_KERNEL_H__ +#define __XEN_FDT_KERNEL_H__ + +#include +#include +#include + +#if __has_include() +# include +#endif + +struct kernel_info { + struct domain *d; + + void *fdt; /* flat device tree */ + paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */ + struct meminfo mem; +#ifdef CONFIG_STATIC_SHM + struct shared_meminfo shm_mem; +#endif + + /* kernel entry point */ + paddr_t entry; + + /* grant table region */ + paddr_t gnttab_start; + paddr_t gnttab_size; + + /* boot blob load addresses */ + const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule; + const char* cmdline; + paddr_t dtb_paddr; + paddr_t initrd_paddr; + + /* Enable uart emulation */ + bool vuart; + + /* Enable/Disable PV drivers interfaces */ + uint16_t dom0less_feature; + + /* Interrupt controller phandle */ + uint32_t phandle_intc; + + /* loader to use for this kernel */ + void (*load)(struct kernel_info *info); + + /* loader specific state */ + union { + struct { + paddr_t kernel_addr; + paddr_t len; +#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64) + paddr_t text_offset; /* 64-bit Image only */ +#endif + paddr_t start; /* Must be 0 for 64-bit Image */ + } zimage; + }; + +#if __has_include() + struct arch_kernel_info arch; +#endif +}; + +static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo) +{ + return container_of(&kinfo->mem.common, struct membanks, common); +} + +static inline const struct membanks * +kernel_info_get_mem_const(const struct kernel_info *kinfo) +{ + return container_of(&kinfo->mem.common, const struct membanks, common); +} + +#ifndef KERNEL_INFO_SHM_MEM_INIT + +#ifdef CONFIG_STATIC_SHM +#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS, +#else +#define KERNEL_INFO_SHM_MEM_INIT +#endif + +#endif /* KERNEL_INFO_SHM_MEM_INIT */ + +#ifndef KERNEL_INFO_INIT + +#define KERNEL_INFO_INIT \ +{ \ + .mem.common.max_banks = NR_MEM_BANKS, \ + KERNEL_INFO_SHM_MEM_INIT \ +} + +#endif /* KERNEL_INFO_INIT */ + +/* + * Probe the kernel to detemine its type and select a loader. + * + * Sets in info: + * ->type + * ->load hook, and sets loader specific variables ->zimage + */ +int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain); + +/* + * Loads the kernel into guest RAM. + * + * Expects to be set in info when called: + * ->mem + * ->fdt + * + * Sets in info: + * ->entry + * ->dtb_paddr + * ->initrd_paddr + */ +void kernel_load(struct kernel_info *info); + +#endif /* __XEN_FDT_KERNEL_H__ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 16:22:56 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 16:22:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974790.1362605 (Exim 4.92) (envelope-from ) id 1uAtA8-0007Qu-7L; Fri, 02 May 2025 16:22:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974790.1362605; Fri, 02 May 2025 16:22: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 1uAtA8-0007Qk-2z; Fri, 02 May 2025 16:22:56 +0000 Received: by outflank-mailman (input) for mailman id 974790; Fri, 02 May 2025 16:22:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAtA6-0005rZ-QZ for xen-devel@lists.xenproject.org; Fri, 02 May 2025 16:22:54 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b24c8439-2771-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 18:22:52 +0200 (CEST) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-ace333d5f7bso395823866b.3 for ; Fri, 02 May 2025 09:22:52 -0700 (PDT) Received: from fedora.. (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad1894c01f2sm68158766b.119.2025.05.02.09.22.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 09:22: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" X-Inumbo-ID: b24c8439-2771-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746202972; x=1746807772; 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; bh=tEw+WJZfn43Csy9BpwvLETZuuvhLgTLz5jLGN2Akw+k=; b=nPk68OEStxSeyJDyjxTN+BC629pLYpLUJsz9Bc1qmFTllwNwgUz2Hw1cxC6AnqYIA9 Wjw2h+C+W82ULEMf0VmQdfTk/lQ8jsQxcTu5RzN8ai6ydHuAYYz/sNnTOnzi2lZxApNd KPnrwY9Jtl3BgiGHy0VBG16Rqzlas69MaB0uGt2R3bRCMW0K44HGey9XRv4KqcwniGgg GgiXzh9uYVfUPafoDI5rz+ZXMC/RklkvBLMUvVPBANouyD50+VvJUViAG9K6kAzARM2I WUMWfTcbyV3HNSKgetd76I5M6+WKIxn9mwI1MdKeUhFY2K5be6pq9DQ6TAXVQMIgflKb RzPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746202972; x=1746807772; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tEw+WJZfn43Csy9BpwvLETZuuvhLgTLz5jLGN2Akw+k=; b=P2Ru9VSrBiCuLkbVmgLI2H6I6+KlcWKrOL9YSwkasxL7giDhYLt8p2fiFXW8SpP3c6 b9kuYitMJGwS+n8Neb99oODiZvFcyqYa+ywEycd/6x7rArcESRvh+LpabYKyBM8yMf3W ddEg/sL9Q42reipe5GLYD0++Af7CVWtVvEyCIsfm0HemY4hWXD6rR8zY94ahlXvnJpdQ 8wrsaA4khRjTnrzUPZ4glA369prAQiJ1/l43KeR4SWeUhO+62AwHNzD2dGXRmGMNy55H 0rgrj7Fwbxr8oQY2iv9AdytKG0XTTcNfLWtQYhDdMqBib6WpTsGDffl06qsIjV1M2gDt nZYw== X-Gm-Message-State: AOJu0YzpJsZ+/2ITkNL26A+clB7JKLMsdZgVGP3Y6B67lj8YNtkEJlMP UqknpPQCI5rs96/2KdBCDj3lyCn50rZOqvLoiNxonSi3XVXZkoUFYY3iWA== X-Gm-Gg: ASbGncu3wAe1H2cznYk8KQdOTysJH7P2dAMBmyC5RY4XyYZGPbXEG6kFvcDe3K9LygY /5F/adyO2F0Kq3DBScIfwtOonuhwpF+E8g+sWk3yz5Kkl6/xh3NZJ2z381Ahe7USqCwzZXs7ZH4 Kp6RUMPk366i/ifiC4DYTOHvDzO554AnO8W2XVzn+d9Tm+ARGET4U7uSTCg7g+j5snn3CzKrzNO Tf9vICrV77E2ddGYPZBZ9i7eE7DYiB1KEMmqFUt8LqgIEfljcEJzz8ejd6tqQxovUnHVnWzOj52 /GIV4c+b3A44USPC+zEpmZQAQNuXpY9jETuZKUNuD+JwLPXRt48U7v0mMpFdvR6HWlU5Ku+gEYd L5dmfVdO0zw== X-Google-Smtp-Source: AGHT+IGJqeBBZEnnt2UBWN3+GsBE3xoUmV3md9Kfm2+aZUnIUtn30Itw7ZkCZoVpVY/HJr94Kio83Q== X-Received: by 2002:a17:907:72d6:b0:aca:a1c9:d155 with SMTP id a640c23a62f3a-ad17ad3b336mr305439966b.11.1746202971582; Fri, 02 May 2025 09:22:51 -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 v3 6/8] xen/common: dom0less: introduce common kernel.c Date: Fri, 2 May 2025 18:22:36 +0200 Message-ID: <4f178bd0e46adf3d4c7a91d6cdd4a0910dbef490.1746199009.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The following functions don't have arch specific things so it is moved to common: - kernel_prboe() - kernel_load() - output_length() Functions necessary for dom0less are only moved. The following changes are done: - Swap __init and return type of kernel_decompress() function to be consistent with defintions of functions in other files. The same for output_length(). - Wrap by "ifdef CONFIG_ARM" the call of kernel_uimage_probe() in kernel_probe() as uImage isn't really used nowadays thereby leave kernel_uimage_probe() call here just for compatability with Arm code. - Introduce kernel_zimage_probe() to cover the case that arch can have different zimage header. - Add ASSERT() for kernel_load() to check that it argument isn't NULL. - Make kernel_uimage_probe() non-static in Arm's code as it is used in common/kernel.c. Introduce CONFIG_DOMAIN_BUILD_HELPERS to not provide stubs for archs which don't provide enough functionality to enable it. Select CONFIG_DOMAIN_BUILD_HELPERS for CONFIG_ARM as only Arm supports it, at the moment. Signed-off-by: Oleksii Kurochko --- Change in v3: - Empty line after license tag for newly introduced files. --- Change in v2: - Drop inclusion of asm/kernel.h in kernel.c as everything necessary has been moved to xen/fdt-kernel.h. --- xen/arch/arm/Kconfig | 1 + xen/arch/arm/kernel.c | 221 +--------------------------- xen/common/Kconfig | 9 +- xen/common/device-tree/Makefile | 1 + xen/common/device-tree/kernel.c | 242 +++++++++++++++++++++++++++++++ xen/include/asm-generic/kernel.h | 141 ++++++++++++++++++ xen/include/xen/fdt-kernel.h | 13 ++ 7 files changed, 412 insertions(+), 216 deletions(-) create mode 100644 xen/common/device-tree/kernel.c create mode 100644 xen/include/asm-generic/kernel.h diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index d0e0a7753c..3321d89068 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -11,6 +11,7 @@ config ARM_64 config ARM def_bool y + select DOMAIN_BUILD_HELPERS select FUNCTION_ALIGNMENT_4B select GENERIC_UART_INIT select HAS_ALTERNATIVE if HAS_VMAP diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c index 5759a3470a..1168c21e97 100644 --- a/xen/arch/arm/kernel.c +++ b/xen/arch/arm/kernel.c @@ -163,105 +163,6 @@ static void __init kernel_zimage_load(struct kernel_info *info) iounmap(kernel); } -static __init uint32_t output_length(char *image, unsigned long image_len) -{ - return *(uint32_t *)&image[image_len - 4]; -} - -static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset) -{ - char *output, *input; - char magic[2]; - int rc; - unsigned int kernel_order_out; - paddr_t output_size; - struct page_info *pages; - mfn_t mfn; - int i; - paddr_t addr = mod->start; - paddr_t size = mod->size; - - if ( size < offset ) - return -EINVAL; - - /* - * It might be that gzip header does not appear at the start address - * (e.g. in case of compressed uImage) so take into account offset to - * gzip header. - */ - addr += offset; - size -= offset; - - if ( size < 2 ) - return -EINVAL; - - copy_from_paddr(magic, addr, sizeof(magic)); - - /* only gzip is supported */ - if ( !gzip_check(magic, size) ) - return -EINVAL; - - input = ioremap_cache(addr, size); - if ( input == NULL ) - return -EFAULT; - - output_size = output_length(input, size); - kernel_order_out = get_order_from_bytes(output_size); - pages = alloc_domheap_pages(NULL, kernel_order_out, 0); - if ( pages == NULL ) - { - iounmap(input); - return -ENOMEM; - } - mfn = page_to_mfn(pages); - output = vmap_contig(mfn, 1 << kernel_order_out); - - rc = perform_gunzip(output, input, size); - clean_dcache_va_range(output, output_size); - iounmap(input); - vunmap(output); - - if ( rc ) - { - free_domheap_pages(pages, kernel_order_out); - return rc; - } - - mod->start = page_to_maddr(pages); - mod->size = output_size; - - /* - * Need to free pages after output_size here because they won't be - * freed by discard_initial_modules - */ - i = PFN_UP(output_size); - for ( ; i < (1 << kernel_order_out); i++ ) - free_domheap_page(pages + i); - - /* - * When using static heap feature, don't give bootmodules memory back to - * the heap allocator - */ - if ( using_static_heap ) - return 0; - - /* - * When freeing the kernel, we need to pass the module start address and - * size as they were before taking an offset to gzip header into account, - * so that the entire region will be freed. - */ - addr -= offset; - size += offset; - - /* - * Free the original kernel, update the pointers to the - * decompressed kernel - */ - fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0); - - return 0; -} - /* * Uimage CPU Architecture Codes */ @@ -274,8 +175,8 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset) /* * Check if the image is a uImage and setup kernel_info */ -static int __init kernel_uimage_probe(struct kernel_info *info, - struct bootmodule *mod) +int __init kernel_uimage_probe(struct kernel_info *info, + struct bootmodule *mod) { struct { __be32 magic; /* Image Header Magic Number */ @@ -505,130 +406,20 @@ static int __init kernel_zimage32_probe(struct kernel_info *info, return 0; } -int __init kernel_probe(struct kernel_info *info, - const struct dt_device_node *domain) +int __init kernel_zimage_probe(struct kernel_info *info, paddr_t addr, + paddr_t size) { - struct bootmodule *mod = NULL; - struct bootcmdline *cmd = NULL; - struct dt_device_node *node; - u64 kernel_addr, initrd_addr, dtb_addr, size; int rc; - /* - * We need to initialize start to 0. This field may be populated during - * kernel_xxx_probe() if the image has a fixed entry point (for e.g. - * uimage.ep). - * We will use this to determine if the image has a fixed entry point or - * the load address should be used as the start address. - */ - info->entry = 0; - - /* domain is NULL only for the hardware domain */ - if ( domain == NULL ) - { - ASSERT(is_hardware_domain(info->d)); - - mod = boot_module_find_by_kind(BOOTMOD_KERNEL); - - info->kernel_bootmodule = mod; - info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK); - - cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL); - if ( cmd ) - info->cmdline = &cmd->cmdline[0]; - } - else - { - const char *name = NULL; - - dt_for_each_child_node(domain, node) - { - if ( dt_device_is_compatible(node, "multiboot,kernel") ) - { - u32 len; - const __be32 *val; - - val = dt_get_property(node, "reg", &len); - dt_get_range(&val, node, &kernel_addr, &size); - mod = boot_module_find_by_addr_and_kind( - BOOTMOD_KERNEL, kernel_addr); - info->kernel_bootmodule = mod; - } - else if ( dt_device_is_compatible(node, "multiboot,ramdisk") ) - { - u32 len; - const __be32 *val; - - val = dt_get_property(node, "reg", &len); - dt_get_range(&val, node, &initrd_addr, &size); - info->initrd_bootmodule = boot_module_find_by_addr_and_kind( - BOOTMOD_RAMDISK, initrd_addr); - } - else if ( dt_device_is_compatible(node, "multiboot,device-tree") ) - { - uint32_t len; - const __be32 *val; - - val = dt_get_property(node, "reg", &len); - if ( val == NULL ) - continue; - dt_get_range(&val, node, &dtb_addr, &size); - info->dtb_bootmodule = boot_module_find_by_addr_and_kind( - BOOTMOD_GUEST_DTB, dtb_addr); - } - else - continue; - } - name = dt_node_name(domain); - cmd = boot_cmdline_find_by_name(name); - if ( cmd ) - info->cmdline = &cmd->cmdline[0]; - } - if ( !mod || !mod->size ) - { - printk(XENLOG_ERR "Missing kernel boot module?\n"); - return -ENOENT; - } - - printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n", - info->d, info->kernel_bootmodule->start); - if ( info->initrd_bootmodule ) - printk("Loading ramdisk from boot module @ %"PRIpaddr"\n", - info->initrd_bootmodule->start); - - /* - * uImage header always appears at the top of the image (even compressed), - * so it needs to be probed first. Note that in case of compressed uImage, - * kernel_decompress is called from kernel_uimage_probe making the function - * self-containing (i.e. fall through only in case of a header not found). - */ - rc = kernel_uimage_probe(info, mod); - if ( rc != -ENOENT ) - return rc; - - /* - * If it is a gzip'ed image, 32bit or 64bit, uncompress it. - * At this point, gzip header appears (if at all) at the top of the image, - * so pass 0 as an offset. - */ - rc = kernel_decompress(mod, 0); - if ( rc && rc != -EINVAL ) - return rc; - #ifdef CONFIG_ARM_64 - rc = kernel_zimage64_probe(info, mod->start, mod->size); + rc = kernel_zimage64_probe(info, addr, size); if (rc < 0) #endif - rc = kernel_zimage32_probe(info, mod->start, mod->size); + rc = kernel_zimage32_probe(info, addr, size); return rc; } -void __init kernel_load(struct kernel_info *info) -{ - info->load(info); -} - /* * Local variables: * mode: C diff --git a/xen/common/Kconfig b/xen/common/Kconfig index be38abf9e1..38981f1d11 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -14,13 +14,20 @@ config CORE_PARKING config DOM0LESS_BOOT bool "Dom0less boot support" if EXPERT - depends on HAS_DOM0LESS + depends on HAS_DOM0LESS && DOMAIN_BUILD_HELPERS default y help Dom0less boot support enables Xen to create and start domU guests during Xen boot without the need of a control domain (Dom0), which could be present anyway. +config DOMAIN_BUILD_HELPERS + bool + help + Introduce functions necessary for working with domain creation, kernel, + etc. As an examples, these type of functions are going to be used by + CONFIG_DOM0LESS_BOOT. + config GRANT_TABLE bool "Grant table support" if EXPERT default y diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile index f3dafc9b81..e88a4d5799 100644 --- a/xen/common/device-tree/Makefile +++ b/xen/common/device-tree/Makefile @@ -4,3 +4,4 @@ obj-y += device-tree.o obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o obj-y += intc.o +obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c new file mode 100644 index 0000000000..1bf3bbf64e --- /dev/null +++ b/xen/common/device-tree/kernel.c @@ -0,0 +1,242 @@ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +static uint32_t __init output_length(char *image, unsigned long image_len) +{ + return *(uint32_t *)&image[image_len - 4]; +} + +int __init kernel_decompress(struct bootmodule *mod, uint32_t offset) +{ + char *output, *input; + char magic[2]; + int rc; + unsigned int kernel_order_out; + paddr_t output_size; + struct page_info *pages; + mfn_t mfn; + int i; + paddr_t addr = mod->start; + paddr_t size = mod->size; + + if ( size < offset ) + return -EINVAL; + + /* + * It might be that gzip header does not appear at the start address + * (e.g. in case of compressed uImage) so take into account offset to + * gzip header. + */ + addr += offset; + size -= offset; + + if ( size < 2 ) + return -EINVAL; + + copy_from_paddr(magic, addr, sizeof(magic)); + + /* only gzip is supported */ + if ( !gzip_check(magic, size) ) + return -EINVAL; + + input = ioremap_cache(addr, size); + if ( input == NULL ) + return -EFAULT; + + output_size = output_length(input, size); + kernel_order_out = get_order_from_bytes(output_size); + pages = alloc_domheap_pages(NULL, kernel_order_out, 0); + if ( pages == NULL ) + { + iounmap(input); + return -ENOMEM; + } + mfn = page_to_mfn(pages); + output = vmap_contig(mfn, 1 << kernel_order_out); + + rc = perform_gunzip(output, input, size); + clean_dcache_va_range(output, output_size); + iounmap(input); + vunmap(output); + + if ( rc ) + { + free_domheap_pages(pages, kernel_order_out); + return rc; + } + + mod->start = page_to_maddr(pages); + mod->size = output_size; + + /* + * Need to free pages after output_size here because they won't be + * freed by discard_initial_modules + */ + i = PFN_UP(output_size); + for ( ; i < (1 << kernel_order_out); i++ ) + free_domheap_page(pages + i); + + /* + * When using static heap feature, don't give bootmodules memory back to + * the heap allocator + */ + if ( using_static_heap ) + return 0; + + /* + * When freeing the kernel, we need to pass the module start address and + * size as they were before taking an offset to gzip header into account, + * so that the entire region will be freed. + */ + addr -= offset; + size += offset; + + /* + * Free the original kernel, update the pointers to the + * decompressed kernel + */ + fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0); + + return 0; +} + +int __init kernel_probe(struct kernel_info *info, + const struct dt_device_node *domain) +{ + struct bootmodule *mod = NULL; + struct bootcmdline *cmd = NULL; + struct dt_device_node *node; + u64 kernel_addr, initrd_addr, dtb_addr, size; + int rc; + + /* + * We need to initialize start to 0. This field may be populated during + * kernel_xxx_probe() if the image has a fixed entry point (for e.g. + * uimage.ep). + * We will use this to determine if the image has a fixed entry point or + * the load address should be used as the start address. + */ + info->entry = 0; + + /* domain is NULL only for the hardware domain */ + if ( domain == NULL ) + { + ASSERT(is_hardware_domain(info->d)); + + mod = boot_module_find_by_kind(BOOTMOD_KERNEL); + + info->kernel_bootmodule = mod; + info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK); + + cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL); + if ( cmd ) + info->cmdline = &cmd->cmdline[0]; + } + else + { + const char *name = NULL; + + dt_for_each_child_node(domain, node) + { + if ( dt_device_is_compatible(node, "multiboot,kernel") ) + { + u32 len; + const __be32 *val; + + val = dt_get_property(node, "reg", &len); + dt_get_range(&val, node, &kernel_addr, &size); + mod = boot_module_find_by_addr_and_kind( + BOOTMOD_KERNEL, kernel_addr); + info->kernel_bootmodule = mod; + } + else if ( dt_device_is_compatible(node, "multiboot,ramdisk") ) + { + u32 len; + const __be32 *val; + + val = dt_get_property(node, "reg", &len); + dt_get_range(&val, node, &initrd_addr, &size); + info->initrd_bootmodule = boot_module_find_by_addr_and_kind( + BOOTMOD_RAMDISK, initrd_addr); + } + else if ( dt_device_is_compatible(node, "multiboot,device-tree") ) + { + uint32_t len; + const __be32 *val; + + val = dt_get_property(node, "reg", &len); + if ( val == NULL ) + continue; + dt_get_range(&val, node, &dtb_addr, &size); + info->dtb_bootmodule = boot_module_find_by_addr_and_kind( + BOOTMOD_GUEST_DTB, dtb_addr); + } + else + continue; + } + name = dt_node_name(domain); + cmd = boot_cmdline_find_by_name(name); + if ( cmd ) + info->cmdline = &cmd->cmdline[0]; + } + if ( !mod || !mod->size ) + { + printk(XENLOG_ERR "Missing kernel boot module?\n"); + return -ENOENT; + } + + printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n", + info->d, info->kernel_bootmodule->start); + if ( info->initrd_bootmodule ) + printk("Loading ramdisk from boot module @ %"PRIpaddr"\n", + info->initrd_bootmodule->start); + + /* + * uImage isn't really used nowadays thereby leave kernel_uimage_probe() + * call here just for compatability with Arm code. + */ +#ifdef CONFIG_ARM + /* + * uImage header always appears at the top of the image (even compressed), + * so it needs to be probed first. Note that in case of compressed uImage, + * kernel_decompress is called from kernel_uimage_probe making the function + * self-containing (i.e. fall through only in case of a header not found). + */ + rc = kernel_uimage_probe(info, mod); + if ( rc != -ENOENT ) + return rc; +#endif + + /* + * If it is a gzip'ed image, 32bit or 64bit, uncompress it. + * At this point, gzip header appears (if at all) at the top of the image, + * so pass 0 as an offset. + */ + rc = kernel_decompress(mod, 0); + if ( rc && rc != -EINVAL ) + return rc; + + rc = kernel_zimage_probe(info, mod->start, mod->size); + + return rc; +} + +void __init kernel_load(struct kernel_info *info) +{ + ASSERT(info && info->load); + + info->load(info); +} diff --git a/xen/include/asm-generic/kernel.h b/xen/include/asm-generic/kernel.h new file mode 100644 index 0000000000..6857fabb34 --- /dev/null +++ b/xen/include/asm-generic/kernel.h @@ -0,0 +1,141 @@ +/* + * Kernel image loading. + * + * Copyright (C) 2011 Citrix Systems, Inc. + */ + +#ifndef __ASM_GENERIC_KERNEL_H__ +#define __ASM_GENERIC_KERNEL_H__ + +#include +#include +#include +#include + +struct kernel_info { + struct domain *d; + + void *fdt; /* flat device tree */ + paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */ + struct meminfo mem; +#ifdef CONFIG_STATIC_SHM + struct shared_meminfo shm_mem; +#endif + + /* kernel entry point */ + paddr_t entry; + + /* grant table region */ + paddr_t gnttab_start; + paddr_t gnttab_size; + + /* boot blob load addresses */ + const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule; + const char* cmdline; + paddr_t dtb_paddr; + paddr_t initrd_paddr; + + /* Enable uart emulation */ + bool vuart; + + /* Enable/Disable PV drivers interfaces */ + uint16_t dom0less_feature; + + /* Interrupt controller phandle */ + uint32_t phandle_intc; + + /* loader to use for this kernel */ + void (*load)(struct kernel_info *info); + + /* loader specific state */ + union { + struct { + paddr_t kernel_addr; + paddr_t len; +#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64) + paddr_t text_offset; /* 64-bit Image only */ +#endif + paddr_t start; /* Must be 0 for 64-bit Image */ + } zimage; + }; + + struct arch_kernel_info arch; +}; + +static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo) +{ + return container_of(&kinfo->mem.common, struct membanks, common); +} + +static inline const struct membanks * +kernel_info_get_mem_const(const struct kernel_info *kinfo) +{ + return container_of(&kinfo->mem.common, const struct membanks, common); +} + +#ifndef KERNEL_INFO_SHM_MEM_INIT + +#ifdef CONFIG_STATIC_SHM +#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS, +#else +#define KERNEL_INFO_SHM_MEM_INIT +#endif + +#endif /* KERNEL_INFO_SHM_MEM_INIT */ + +#ifndef KERNEL_INFO_INIT + +#define KERNEL_INFO_INIT \ +{ \ + .mem.common.max_banks = NR_MEM_BANKS, \ + KERNEL_INFO_SHM_MEM_INIT \ +} + +#endif /* KERNEL_INFO_INIT */ + +/* + * Probe the kernel to detemine its type and select a loader. + * + * Sets in info: + * ->type + * ->load hook, and sets loader specific variables ->zimage + */ +int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain); + +/* + * Loads the kernel into guest RAM. + * + * Expects to be set in info when called: + * ->mem + * ->fdt + * + * Sets in info: + * ->entry + * ->dtb_paddr + * ->initrd_paddr + */ +void kernel_load(struct kernel_info *info); + +int kernel_decompress(struct bootmodule *mod, uint32_t offset); + +int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size); + +/* + * uImage isn't really used nowadays thereby leave kernel_uimage_probe() + * call here just for compatability with Arm code. + */ +#ifdef CONFIG_ARM +struct bootmodule; +int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod); +#endif + +#endif /*__ASM_GENERIC_KERNEL_H__ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h index c81e759423..d85324c867 100644 --- a/xen/include/xen/fdt-kernel.h +++ b/xen/include/xen/fdt-kernel.h @@ -121,6 +121,19 @@ int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain); */ void kernel_load(struct kernel_info *info); +int kernel_decompress(struct bootmodule *mod, uint32_t offset); + +int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size); + +/* + * uImage isn't really used nowadays thereby leave kernel_uimage_probe() + * call here just for compatability with Arm code. + */ +#ifdef CONFIG_ARM +struct bootmodule; +int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod); +#endif + #endif /* __XEN_FDT_KERNEL_H__ */ /* -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 16:22:59 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 16:22:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974793.1362615 (Exim 4.92) (envelope-from ) id 1uAtAB-0007nf-LI; Fri, 02 May 2025 16:22:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974793.1362615; Fri, 02 May 2025 16: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 1uAtAB-0007nU-G0; Fri, 02 May 2025 16:22:59 +0000 Received: by outflank-mailman (input) for mailman id 974793; Fri, 02 May 2025 16:22:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAtA9-0005rZ-RP for xen-devel@lists.xenproject.org; Fri, 02 May 2025 16:22:58 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b38da72a-2771-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 18:22:54 +0200 (CEST) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-ac2aeada833so415876566b.0 for ; Fri, 02 May 2025 09:22:54 -0700 (PDT) Received: from fedora.. (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad1894c01f2sm68158766b.119.2025.05.02.09.22.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 09:22: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" X-Inumbo-ID: b38da72a-2771-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746202974; x=1746807774; 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; bh=eDnnQd3pRZQgurScUoDNUVkdcI4ZQ5arFshUy2UUTRU=; b=Zypa2FZzZDidiLnPDtvtMw4N91QQAQSnLtD3axm0xxSc4ElMvlp8MY1BodAEkatPS9 cd6gmCmJ2xkc5dSyZpFu3/gMqVav9w4koDoN6BIfpjeeLRIMBOEmSFZzNarfTlhfLt2K VOvrtRpvVQMretEF2BzyMffysqi1uq/jlKJcaVzKPArKzYRPV3I1kTuZbiZOrcOqEgXW fGjoge6gzdHsffXz2V4dwM2pFLg7FcHOb86ZYmEoG+x50EtHQbtrXa+0h+5suiRlwZ3O 4FBTIexgQVfcorK9PMuVpUDVupsWvp997p39Spt1N33uNZwRvBvrAqzrrfOx7Rhkw6Lz YJxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746202974; x=1746807774; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eDnnQd3pRZQgurScUoDNUVkdcI4ZQ5arFshUy2UUTRU=; b=Z0sdiGE2aMATgloH5QZ0bCQZJyzl6Yrdz0tb0KaiMSiceWiRSeMRC6qvTRh70rNbpS KddbqSJSAvy2xMEySC9IN14DIEg9bFwirfjamEy6V/BnRWKmfnqk0dAWFweUIWFoUnWx 6tWlwcqq7fzl/kzoG67iJQg2EKDHqen832JmEhMfQ+IpLNrnDanPJ+1H+toa/1otJwmN hVrzQMjRM9a6A8G/VLKWVv/sqwdtpUcRWFFdy+cYDHe0cIBv+lOxtIDCloaPF74/DeB8 p56a2Y/mmWJhALng0gQe8GyfLrK232/1WQ2CgSaRaYxbp4macxylPhtPHtybBu6p8vHc 3WYQ== X-Gm-Message-State: AOJu0YzuKKMwVfHDVfs679fXmXxr3FESnZCfBjjhXbzhkLjhlH/J9L1Z 8I171wrHzoHvl7XbNln8Y4bB2EY+oraRws80kD8y0NF+D2z8EjDY/uNadw== X-Gm-Gg: ASbGncuHnulU9NK3v1+XRdBM4HW8zPbBOuM7T3fJryAqTqZ9EuKG1AiYRxl4fHb1mpI PX3TJMoGcIfmUlBloKq4LVJwuWH2FGKxYCQbSh+7Mcf5QZ2HdstI6iNQ/xWPtMMAMKE2r09/UXa u2+/WUb1jn3eltXaglV3/qjqAh2lbG33Grs/b1J0/VCz5KBbg+MiWo4rJW1miF1+k5zegoVuNr6 /3XFya/As9SH8b/1wyQ+uPb/SGXOt0yL0OfUM247erXvCAMJvHmn3Do7lIvaZhYcQsyCtfHwNZW DEn975UBd6OPoaBj5m9RzVc2KMLYdVlqsrU/P28NrQkevq55yNylOS8+bj5dihWFKK9erZ5ZZPb PzZGv7BeqHg== X-Google-Smtp-Source: AGHT+IFBYL8oC9QOxSaUJ6n0vLedCin6HK3FBCgmKEnu+ODVVJLploJQO8xtnwLidt8Tl3h+xoGWAQ== X-Received: by 2002:a17:907:869e:b0:ac7:3929:25f9 with SMTP id a640c23a62f3a-aceff04b0f4mr665444966b.29.1746202973551; Fri, 02 May 2025 09:22:53 -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 v3 7/8] xen/common: dom0less: introduce common domain-build.c Date: Fri, 2 May 2025 18:22:37 +0200 Message-ID: <291544ec45d69a3f0ff79eb6770266a0aa04e77d.1746199009.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Some functions of Arm's domain_build.c could be reused by dom0less or other features connected to domain construction/build. The following functions are moved to common: - get_allocation_size(). - allocate_domheap_memory(). - guest_map_pages(). - allocate_bank_memory(). - add_hwdom_free_regions(). - find_unallocated_memory(). - allocate_memory(). - dtb_load(). - initrd_load(). Prototype of dtb_load() and initrd_load() is updated to recieve a pointer to copy_to_guest_phys() as some archs require copy_to_guest_phys_fluch_dcache(). Update arm/include/asm/Makefile to generate domain-build.h for Arm as it is used by domain-build.c. Signed-off-by: Oleksii Kurochko --- Change in v3: - Nothing changed. Only rebase. --- Change in v2: - Use xen/fdt-domain-build.h instead of asm/domain_build.h. --- xen/arch/arm/domain_build.c | 397 +------------------------ xen/common/device-tree/Makefile | 1 + xen/common/device-tree/domain-build.c | 404 ++++++++++++++++++++++++++ xen/include/xen/fdt-domain-build.h | 33 ++- 4 files changed, 439 insertions(+), 396 deletions(-) create mode 100644 xen/common/device-tree/domain-build.c diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 9d649b06b3..df29619c40 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -120,18 +120,6 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0) return vcpu_create(dom0, 0); } -unsigned int __init get_allocation_size(paddr_t size) -{ - /* - * get_order_from_bytes returns the order greater than or equal to - * the given size, but we need less than or equal. Adding one to - * the size pushes an evenly aligned size into the next order, so - * we can then unconditionally subtract 1 from the order which is - * returned. - */ - return get_order_from_bytes(size + 1) - 1; -} - /* * Insert the given pages into a memory bank, banks are ordered by address. * @@ -418,98 +406,6 @@ static void __init allocate_memory_11(struct domain *d, } } -bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size, - alloc_domheap_mem_cb cb, void *extra) -{ - unsigned int max_order = UINT_MAX; - - while ( tot_size > 0 ) - { - unsigned int order = get_allocation_size(tot_size); - struct page_info *pg; - - order = min(max_order, order); - - pg = alloc_domheap_pages(d, order, 0); - if ( !pg ) - { - /* - * If we can't allocate one page, then it is unlikely to - * succeed in the next iteration. So bail out. - */ - if ( !order ) - return false; - - /* - * If we can't allocate memory with order, then it is - * unlikely to succeed in the next iteration. - * Record the order - 1 to avoid re-trying. - */ - max_order = order - 1; - continue; - } - - if ( !cb(d, pg, order, extra) ) - return false; - - tot_size -= (1ULL << (PAGE_SHIFT + order)); - } - - return true; -} - -static bool __init guest_map_pages(struct domain *d, struct page_info *pg, - unsigned int order, void *extra) -{ - gfn_t *sgfn = (gfn_t *)extra; - int res; - - BUG_ON(!sgfn); - res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order); - if ( res ) - { - dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res); - return false; - } - - *sgfn = gfn_add(*sgfn, 1UL << order); - - return true; -} - -bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, - paddr_t tot_size) -{ - struct membanks *mem = kernel_info_get_mem(kinfo); - struct domain *d = kinfo->d; - struct membank *bank; - - /* - * allocate_bank_memory can be called with a tot_size of zero for - * the second memory bank. It is not an error and we can safely - * avoid creating a zero-size memory bank. - */ - if ( tot_size == 0 ) - return true; - - bank = &mem->bank[mem->nr_banks]; - bank->start = gfn_to_gaddr(sgfn); - bank->size = tot_size; - - /* - * Allocate pages from the heap until tot_size is zero and map them to the - * guest using guest_map_pages, passing the starting gfn as extra parameter - * for the map operation. - */ - if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) ) - return false; - - mem->nr_banks++; - kinfo->unassigned_mem -= bank->size; - - return true; -} - /* * When PCI passthrough is available we want to keep the * "linux,pci-domain" in sync for every host bridge. @@ -900,226 +796,6 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, return 0; } -static int __init add_hwdom_free_regions(unsigned long s_gfn, - unsigned long e_gfn, void *data) -{ - struct membanks *free_regions = data; - paddr_t start, size; - paddr_t s = pfn_to_paddr(s_gfn); - paddr_t e = pfn_to_paddr(e_gfn); - unsigned int i, j; - - if ( free_regions->nr_banks >= free_regions->max_banks ) - return 0; - - /* - * Both start and size of the free region should be 2MB aligned to - * potentially allow superpage mapping. - */ - start = (s + SZ_2M - 1) & ~(SZ_2M - 1); - if ( start > e ) - return 0; - - /* - * e is actually "end-1" because it is called by rangeset functions - * which are inclusive of the last address. - */ - e += 1; - size = (e - start) & ~(SZ_2M - 1); - - /* Find the insert position (descending order). */ - for ( i = 0; i < free_regions->nr_banks ; i++ ) - if ( size > free_regions->bank[i].size ) - break; - - /* Move the other banks to make space. */ - for ( j = free_regions->nr_banks; j > i ; j-- ) - { - free_regions->bank[j].start = free_regions->bank[j - 1].start; - free_regions->bank[j].size = free_regions->bank[j - 1].size; - } - - free_regions->bank[i].start = start; - free_regions->bank[i].size = size; - free_regions->nr_banks++; - - return 0; -} - -/* - * Find unused regions of Host address space which can be exposed to domain - * using the host memory layout. In order to calculate regions we exclude every - * region passed in mem_banks from the Host RAM. - */ -static int __init find_unallocated_memory(const struct kernel_info *kinfo, - const struct membanks *mem_banks[], - unsigned int nr_mem_banks, - struct membanks *free_regions, - int (*cb)(unsigned long s_gfn, - unsigned long e_gfn, - void *data)) -{ - const struct membanks *mem = bootinfo_get_mem(); - struct rangeset *unalloc_mem; - paddr_t start, end; - unsigned int i, j; - int res; - - ASSERT(domain_use_host_layout(kinfo->d)); - - unalloc_mem = rangeset_new(NULL, NULL, 0); - if ( !unalloc_mem ) - return -ENOMEM; - - /* Start with all available RAM */ - for ( i = 0; i < mem->nr_banks; i++ ) - { - start = mem->bank[i].start; - end = mem->bank[i].start + mem->bank[i].size; - res = rangeset_add_range(unalloc_mem, PFN_DOWN(start), - PFN_DOWN(end - 1)); - if ( res ) - { - printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n", - start, end); - goto out; - } - } - - /* Remove all regions listed in mem_banks */ - for ( i = 0; i < nr_mem_banks; i++ ) - for ( j = 0; j < mem_banks[i]->nr_banks; j++ ) - { - start = mem_banks[i]->bank[j].start; - - /* Shared memory banks can contain INVALID_PADDR as start */ - if ( INVALID_PADDR == start ) - continue; - - end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size; - res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), - PFN_DOWN(end - 1)); - if ( res ) - { - printk(XENLOG_ERR - "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n", - start, end, res); - goto out; - } - } - - start = 0; - end = (1ULL << p2m_ipa_bits) - 1; - res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end), - cb, free_regions); - if ( res ) - free_regions->nr_banks = 0; - else if ( !free_regions->nr_banks ) - res = -ENOENT; - -out: - rangeset_destroy(unalloc_mem); - - return res; -} - -void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) -{ - struct membanks *mem = kernel_info_get_mem(kinfo); - unsigned int i, nr_banks = GUEST_RAM_BANKS; - struct membanks *hwdom_free_mem = NULL; - - printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", - /* Don't want format this as PRIpaddr (16 digit hex) */ - (unsigned long)(kinfo->unassigned_mem >> 20), d); - - mem->nr_banks = 0; - /* - * Use host memory layout for hwdom. Only case for this is when LLC coloring - * is enabled. - */ - if ( is_hardware_domain(d) ) - { - struct membanks *gnttab = membanks_xzalloc(1, MEMORY); - /* - * Exclude the following regions: - * 1) Remove reserved memory - * 2) Grant table assigned to hwdom - */ - const struct membanks *mem_banks[] = { - bootinfo_get_reserved_mem(), - gnttab, - }; - - if ( !gnttab ) - goto fail; - - gnttab->nr_banks = 1; - gnttab->bank[0].start = kinfo->gnttab_start; - gnttab->bank[0].size = kinfo->gnttab_size; - - hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY); - if ( !hwdom_free_mem ) - goto fail; - - if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks), - hwdom_free_mem, add_hwdom_free_regions) ) - goto fail; - - nr_banks = hwdom_free_mem->nr_banks; - xfree(gnttab); - } - - for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- ) - { - paddr_t bank_start, bank_size; - - if ( is_hardware_domain(d) ) - { - bank_start = hwdom_free_mem->bank[i].start; - bank_size = hwdom_free_mem->bank[i].size; - } - else - { - const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; - const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; - - if ( i >= GUEST_RAM_BANKS ) - goto fail; - - bank_start = bankbase[i]; - bank_size = banksize[i]; - } - - bank_size = MIN(bank_size, kinfo->unassigned_mem); - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) ) - goto fail; - } - - if ( kinfo->unassigned_mem ) - goto fail; - - for( i = 0; i < mem->nr_banks; i++ ) - { - printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", - d, - i, - mem->bank[i].start, - mem->bank[i].start + mem->bank[i].size, - /* Don't want format this as PRIpaddr (16 digit hex) */ - (unsigned long)(mem->bank[i].size >> 20)); - } - - xfree(hwdom_free_mem); - return; - - fail: - panic("Failed to allocate requested domain memory." - /* Don't want format this as PRIpaddr (16 digit hex) */ - " %ldKB unallocated. Fix the VMs configurations.\n", - (unsigned long)kinfo->unassigned_mem >> 10); -} - static int __init handle_pci_range(const struct dt_device_node *dev, uint64_t addr, uint64_t len, void *data) { @@ -2059,75 +1735,6 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo) return -EINVAL; } -static void __init dtb_load(struct kernel_info *kinfo) -{ - unsigned long left; - - printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", - kinfo->d, kinfo->dtb_paddr, - kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt)); - - left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr, - kinfo->fdt, - fdt_totalsize(kinfo->fdt)); - - if ( left != 0 ) - panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n", - kinfo->d, left); - xfree(kinfo->fdt); -} - -static void __init initrd_load(struct kernel_info *kinfo) -{ - const struct bootmodule *mod = kinfo->initrd_bootmodule; - paddr_t load_addr = kinfo->initrd_paddr; - paddr_t paddr, len; - int node; - int res; - __be32 val[2]; - __be32 *cellp; - void __iomem *initrd; - - if ( !mod || !mod->size ) - return; - - paddr = mod->start; - len = mod->size; - - printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", - kinfo->d, paddr, load_addr, load_addr + len); - - /* Fix up linux,initrd-start and linux,initrd-end in /chosen */ - node = fdt_path_offset(kinfo->fdt, "/chosen"); - if ( node < 0 ) - panic("Cannot find the /chosen node\n"); - - cellp = (__be32 *)val; - dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr); - res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start", - val, sizeof(val)); - if ( res ) - panic("Cannot fix up \"linux,initrd-start\" property\n"); - - cellp = (__be32 *)val; - dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len); - res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end", - val, sizeof(val)); - if ( res ) - panic("Cannot fix up \"linux,initrd-end\" property\n"); - - initrd = ioremap_wc(paddr, len); - if ( !initrd ) - panic("Unable to map the %pd initrd\n", kinfo->d); - - res = copy_to_guest_phys_flush_dcache(kinfo->d, load_addr, - initrd, len); - if ( res != 0 ) - panic("Unable to copy the initrd in the %pd memory\n", kinfo->d); - - iounmap(initrd); -} - /* * Allocate the event channel PPIs and setup the HVM_PARAM_CALLBACK_IRQ. * The allocated IRQ will be found in d->arch.evtchn_irq. @@ -2220,8 +1827,8 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo) */ kernel_load(kinfo); /* initrd_load will fix up the fdt, so call it before dtb_load */ - initrd_load(kinfo); - dtb_load(kinfo); + initrd_load(kinfo, copy_to_guest_phys_flush_dcache); + dtb_load(kinfo, copy_to_guest_phys_flush_dcache); memset(regs, 0, sizeof(*regs)); diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile index e88a4d5799..831b91399b 100644 --- a/xen/common/device-tree/Makefile +++ b/xen/common/device-tree/Makefile @@ -1,6 +1,7 @@ obj-y += bootfdt.init.o obj-y += bootinfo.init.o obj-y += device-tree.o +obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.o obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o obj-y += intc.o diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c new file mode 100644 index 0000000000..69257a15ba --- /dev/null +++ b/xen/common/device-tree/domain-build.c @@ -0,0 +1,404 @@ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size, + alloc_domheap_mem_cb cb, void *extra) +{ + unsigned int max_order = UINT_MAX; + + while ( tot_size > 0 ) + { + unsigned int order = get_allocation_size(tot_size); + struct page_info *pg; + + order = min(max_order, order); + + pg = alloc_domheap_pages(d, order, 0); + if ( !pg ) + { + /* + * If we can't allocate one page, then it is unlikely to + * succeed in the next iteration. So bail out. + */ + if ( !order ) + return false; + + /* + * If we can't allocate memory with order, then it is + * unlikely to succeed in the next iteration. + * Record the order - 1 to avoid re-trying. + */ + max_order = order - 1; + continue; + } + + if ( !cb(d, pg, order, extra) ) + return false; + + tot_size -= (1ULL << (PAGE_SHIFT + order)); + } + + return true; +} + +static bool __init guest_map_pages(struct domain *d, struct page_info *pg, + unsigned int order, void *extra) +{ + gfn_t *sgfn = (gfn_t *)extra; + int res; + + BUG_ON(!sgfn); + res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order); + if ( res ) + { + dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res); + return false; + } + + *sgfn = gfn_add(*sgfn, 1UL << order); + + return true; +} + +bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, + paddr_t tot_size) +{ + struct membanks *mem = kernel_info_get_mem(kinfo); + struct domain *d = kinfo->d; + struct membank *bank; + + /* + * allocate_bank_memory can be called with a tot_size of zero for + * the second memory bank. It is not an error and we can safely + * avoid creating a zero-size memory bank. + */ + if ( tot_size == 0 ) + return true; + + bank = &mem->bank[mem->nr_banks]; + bank->start = gfn_to_gaddr(sgfn); + bank->size = tot_size; + + /* + * Allocate pages from the heap until tot_size is zero and map them to the + * guest using guest_map_pages, passing the starting gfn as extra parameter + * for the map operation. + */ + if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) ) + return false; + + mem->nr_banks++; + kinfo->unassigned_mem -= bank->size; + + return true; +} + +static int __init add_hwdom_free_regions(unsigned long s_gfn, + unsigned long e_gfn, void *data) +{ + struct membanks *free_regions = data; + paddr_t start, size; + paddr_t s = pfn_to_paddr(s_gfn); + paddr_t e = pfn_to_paddr(e_gfn); + unsigned int i, j; + + if ( free_regions->nr_banks >= free_regions->max_banks ) + return 0; + + /* + * Both start and size of the free region should be 2MB aligned to + * potentially allow superpage mapping. + */ + start = (s + SZ_2M - 1) & ~(SZ_2M - 1); + if ( start > e ) + return 0; + + /* + * e is actually "end-1" because it is called by rangeset functions + * which are inclusive of the last address. + */ + e += 1; + size = (e - start) & ~(SZ_2M - 1); + + /* Find the insert position (descending order). */ + for ( i = 0; i < free_regions->nr_banks ; i++ ) + if ( size > free_regions->bank[i].size ) + break; + + /* Move the other banks to make space. */ + for ( j = free_regions->nr_banks; j > i ; j-- ) + { + free_regions->bank[j].start = free_regions->bank[j - 1].start; + free_regions->bank[j].size = free_regions->bank[j - 1].size; + } + + free_regions->bank[i].start = start; + free_regions->bank[i].size = size; + free_regions->nr_banks++; + + return 0; +} + +/* + * Find unused regions of Host address space which can be exposed to domain + * using the host memory layout. In order to calculate regions we exclude every + * region passed in mem_banks from the Host RAM. + */ +int __init find_unallocated_memory(const struct kernel_info *kinfo, + const struct membanks *mem_banks[], + unsigned int nr_mem_banks, + struct membanks *free_regions, + int (*cb)(unsigned long s_gfn, + unsigned long e_gfn, + void *data)) +{ + const struct membanks *mem = bootinfo_get_mem(); + struct rangeset *unalloc_mem; + paddr_t start, end; + unsigned int i, j; + int res; + + ASSERT(domain_use_host_layout(kinfo->d)); + + unalloc_mem = rangeset_new(NULL, NULL, 0); + if ( !unalloc_mem ) + return -ENOMEM; + + /* Start with all available RAM */ + for ( i = 0; i < mem->nr_banks; i++ ) + { + start = mem->bank[i].start; + end = mem->bank[i].start + mem->bank[i].size; + res = rangeset_add_range(unalloc_mem, PFN_DOWN(start), + PFN_DOWN(end - 1)); + if ( res ) + { + printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n", + start, end); + goto out; + } + } + + /* Remove all regions listed in mem_banks */ + for ( i = 0; i < nr_mem_banks; i++ ) + for ( j = 0; j < mem_banks[i]->nr_banks; j++ ) + { + start = mem_banks[i]->bank[j].start; + + /* Shared memory banks can contain INVALID_PADDR as start */ + if ( INVALID_PADDR == start ) + continue; + + end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size; + res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), + PFN_DOWN(end - 1)); + if ( res ) + { + printk(XENLOG_ERR + "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n", + start, end, res); + goto out; + } + } + + start = 0; + end = (1ULL << p2m_ipa_bits) - 1; + res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end), + cb, free_regions); + if ( res ) + free_regions->nr_banks = 0; + else if ( !free_regions->nr_banks ) + res = -ENOENT; + +out: + rangeset_destroy(unalloc_mem); + + return res; +} + +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) +{ + struct membanks *mem = kernel_info_get_mem(kinfo); + unsigned int i, nr_banks = GUEST_RAM_BANKS; + struct membanks *hwdom_free_mem = NULL; + + printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", + /* Don't want format this as PRIpaddr (16 digit hex) */ + (unsigned long)(kinfo->unassigned_mem >> 20), d); + + mem->nr_banks = 0; + /* + * Use host memory layout for hwdom. Only case for this is when LLC coloring + * is enabled. + */ + if ( is_hardware_domain(d) ) + { + struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1); + /* + * Exclude the following regions: + * 1) Remove reserved memory + * 2) Grant table assigned to hwdom + */ + const struct membanks *mem_banks[] = { + bootinfo_get_reserved_mem(), + gnttab, + }; + + if ( !gnttab ) + goto fail; + + gnttab->nr_banks = 1; + gnttab->bank[0].start = kinfo->gnttab_start; + gnttab->bank[0].size = kinfo->gnttab_size; + + hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank, + NR_MEM_BANKS); + if ( !hwdom_free_mem ) + goto fail; + + hwdom_free_mem->max_banks = NR_MEM_BANKS; + + if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks), + hwdom_free_mem, add_hwdom_free_regions) ) + goto fail; + + nr_banks = hwdom_free_mem->nr_banks; + xfree(gnttab); + } + + for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- ) + { + paddr_t bank_start, bank_size; + + if ( is_hardware_domain(d) ) + { + bank_start = hwdom_free_mem->bank[i].start; + bank_size = hwdom_free_mem->bank[i].size; + } + else + { + const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; + const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; + + if ( i >= GUEST_RAM_BANKS ) + goto fail; + + bank_start = bankbase[i]; + bank_size = banksize[i]; + } + + bank_size = MIN(bank_size, kinfo->unassigned_mem); + if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) ) + goto fail; + } + + if ( kinfo->unassigned_mem ) + goto fail; + + for( i = 0; i < mem->nr_banks; i++ ) + { + printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", + d, + i, + mem->bank[i].start, + mem->bank[i].start + mem->bank[i].size, + /* Don't want format this as PRIpaddr (16 digit hex) */ + (unsigned long)(mem->bank[i].size >> 20)); + } + + xfree(hwdom_free_mem); + return; + + fail: + panic("Failed to allocate requested domain memory." + /* Don't want format this as PRIpaddr (16 digit hex) */ + " %ldKB unallocated. Fix the VMs configurations.\n", + (unsigned long)kinfo->unassigned_mem >> 10); +} + +/* Copy data to guest physical address, then clean the region. */ +typedef unsigned long (*copy_to_guest_phys_cb)(struct domain *d, + paddr_t gpa, + void *buf, + unsigned int len); + +void __init dtb_load(struct kernel_info *kinfo, + copy_to_guest_phys_cb copy_to_guest) +{ + unsigned long left; + + printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", + kinfo->d, kinfo->dtb_paddr, + kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt)); + + left = copy_to_guest(kinfo->d, kinfo->dtb_paddr, + kinfo->fdt, + fdt_totalsize(kinfo->fdt)); + + if ( left != 0 ) + panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n", + kinfo->d, left); + xfree(kinfo->fdt); +} + +void __init initrd_load(struct kernel_info *kinfo, + copy_to_guest_phys_cb copy_to_guest) +{ + const struct bootmodule *mod = kinfo->initrd_bootmodule; + paddr_t load_addr = kinfo->initrd_paddr; + paddr_t paddr, len; + int node; + int res; + __be32 val[2]; + __be32 *cellp; + void __iomem *initrd; + + if ( !mod || !mod->size ) + return; + + paddr = mod->start; + len = mod->size; + + printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", + kinfo->d, paddr, load_addr, load_addr + len); + + /* Fix up linux,initrd-start and linux,initrd-end in /chosen */ + node = fdt_path_offset(kinfo->fdt, "/chosen"); + if ( node < 0 ) + panic("Cannot find the /chosen node\n"); + + cellp = (__be32 *)val; + dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr); + res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start", + val, sizeof(val)); + if ( res ) + panic("Cannot fix up \"linux,initrd-start\" property\n"); + + cellp = (__be32 *)val; + dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len); + res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end", + val, sizeof(val)); + if ( res ) + panic("Cannot fix up \"linux,initrd-end\" property\n"); + + initrd = ioremap_wc(paddr, len); + if ( !initrd ) + panic("Unable to map the hwdom initrd\n"); + + res = copy_to_guest(kinfo->d, load_addr, + initrd, len); + if ( res != 0 ) + panic("Unable to copy the initrd in the hwdom memory\n"); + + iounmap(initrd); +} diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h index b79e9fabfe..4a0052b2e8 100644 --- a/xen/include/xen/fdt-domain-build.h +++ b/xen/include/xen/fdt-domain-build.h @@ -6,6 +6,7 @@ #include #include #include +#include #include struct domain; @@ -29,7 +30,37 @@ int make_memory_node(const struct kernel_info *kinfo, int addrcells, int sizecells, const struct membanks *mem); int make_timer_node(const struct kernel_info *kinfo); -unsigned int get_allocation_size(paddr_t size); + +static inline int get_allocation_size(paddr_t size) +{ + /* + * get_order_from_bytes returns the order greater than or equal to + * the given size, but we need less than or equal. Adding one to + * the size pushes an evenly aligned size into the next order, so + * we can then unconditionally subtract 1 from the order which is + * returned. + */ + return get_order_from_bytes(size + 1) - 1; +} + +typedef unsigned long (*copy_to_guest_phys_cb)(struct domain *d, + paddr_t gpa, + void *buf, + unsigned int len); + +void initrd_load(struct kernel_info *kinfo, + copy_to_guest_phys_cb copy_to_guest); + +void dtb_load(struct kernel_info *kinfo, + copy_to_guest_phys_cb copy_to_guest); + +int find_unallocated_memory(const struct kernel_info *kinfo, + const struct membanks *mem_banks[], + unsigned int nr_mem_banks, + struct membanks *free_regions, + int (*cb)(unsigned long s_gfn, + unsigned long e_gfn, + void *data)); #endif /* __XEN_FDT_DOMAIN_BUILD_H__ */ -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 16:31:18 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 16:31:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974868.1362625 (Exim 4.92) (envelope-from ) id 1uAtI9-00031w-Jl; Fri, 02 May 2025 16:31:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974868.1362625; Fri, 02 May 2025 16:31:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAtI9-00031p-Gg; Fri, 02 May 2025 16:31:13 +0000 Received: by outflank-mailman (input) for mailman id 974868; Fri, 02 May 2025 16:31:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAtAC-0005rZ-S4 for xen-devel@lists.xenproject.org; Fri, 02 May 2025 16:23:01 +0000 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [2a00:1450:4864:20::634]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b447a7c1-2771-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 18:22:55 +0200 (CEST) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-ac2a81e41e3so394156766b.1 for ; Fri, 02 May 2025 09:22:55 -0700 (PDT) Received: from fedora.. (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad1894c01f2sm68158766b.119.2025.05.02.09.22.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 09:22: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" X-Inumbo-ID: b447a7c1-2771-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746202975; x=1746807775; 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; bh=+jFw3h4Q9XYaNyP0ZWtKpY/WJbt8g8MpajB8UOqpIWc=; b=aQmdyfD+mrQOFFCF0Pwy57zgYla5ex1Q38J4dJKEUq9bGNZS1crBikATkFFG7tMY0v 6C8LcoUO7YNeDPRKaTOnYFq+qpt6oNBPrb0PTw0fmi+EP5/3wNzJHj16BbiJ2UDEntA3 BPKbLPEcdnliqJbEk7ZqZUt/IwuAkE0Y+jvNoLPfW7j5eGAuJ42eplAicz/gDuQgpLOb FL9x+99tF3wpKhEXe/YPVrPSj8PRHRhziQjl3goauyaqDHulzKQjfbuOhnQvNT7tOItr LU/PkB3K7TjTl3PEKT4RuGGxXfifH6Mlt+MyDkXdB4a+C3vrkcz5JViWEM+J250iMIWD XN4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746202975; x=1746807775; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+jFw3h4Q9XYaNyP0ZWtKpY/WJbt8g8MpajB8UOqpIWc=; b=uM1uEyWt1PRg4gdIDce2cgtVQL0vuPCHD6Qr04Phtfuz724/RoDqEMAQPTjM+3IQ6r xbrI1vwY2jgR/uwQHLu9Sp1NogQVouu6RzbN90Zj5DNVfmoOkieCJKH8+AnGAnOxtYBX MA59TLKbV2S5dB1s6X6bIyUcUhZ/fr8CH2UuyiUQxgWIaK6Ox1cO5VZPgaoXxe3Hk3j7 okwKdXMk1uQNmyoi0iBUKOE62wcCAWZA4L4/wjAJCIwDvQpgYF2nwMovMXoN1mFMON1B k3Lsp7ptfMvu4u59sxbJVqL4oS7R3gdMD//gxcT0PCKQsQeh5n0Hh8g5J86louJ/4GkV 4GkA== X-Gm-Message-State: AOJu0YziSWofqvAoTxgo468uTnhL/CUqD8ib7PqpXEKUTr2+4EDvg/U8 z/d7FNY/a6Wgq749LsDjkAIQdnep+tVdlpvLbnhMF7p+ceZFk4rTzHUuFw== X-Gm-Gg: ASbGncsyJwhmdit6FJaqTzZOm23Th4cFSJYekkp/uyYX5jvzdGhUwA9Be9/LUJW0nvj DpQknMt/agcoHwVU4ckAaz1C8aslSEXRY4O+4Wxu55rbmW4UQcy+iyBZEEcz9GLdwmPY6RJ6wgq SfN4SoKrXq0miaTdi07MHBRpaX6JTbFSPI7O5QHFYSJ0VfHvp+KGlOXvHPKgb2HbYn3/PMeD3S/ e1TkMeoBgsVqWweIGg+XhqQtzhMhmFiBS9aca0Dk2m0eWXkTI2QWLbnNvM9y/qMNsEcUtWZuZNM BmlmapsaRPf7mxItX/UcDC1BWMMa38FlhB7HoEkuagv2qNjg52VYbICW8nRMyJf9P2I5vUxryk+ L/uOHaGYfcFmdDgpCWGOb X-Google-Smtp-Source: AGHT+IGrsgFMj3uuhYBpdoLcgRI+pbhUn22HD0W7o+9g2/s2oqcTWR5L5u0N/xcBOWeFbbfR//gqyQ== X-Received: by 2002:a17:907:1688:b0:ac4:493:403 with SMTP id a640c23a62f3a-ad17aef2851mr305912266b.37.1746202974817; Fri, 02 May 2025 09:22:54 -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 v3 8/8] xen/common: dom0less: introduce common dom0less-build.c Date: Fri, 2 May 2025 18:22:38 +0200 Message-ID: <76390ef52f108b580e1c397ed178ceadf1ae53c4.1746199009.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Part of Arm's dom0less-build.c could be common between architectures which are using device tree files to create guest domains. Thereby move some parts of Arm's dom0less-build.c to common code with minor changes. As a part of theses changes the following changes are introduced: - Introduce make_arch_nodes() to cover arch-specific nodes. For example, in case of Arm, it is PSCI and vpl011 nodes. - Introduce set_domain_type() to abstract a way how setting of domain type happens. For example, RISC-V won't have this member of arch_domain structure as vCPUs will always have the same bitness as hypervisor. In case of Arm, it is possible that Arm64 could create 32-bit and 64-bit domains. - Introduce init_vuart() to cover details of virtual uart initialization. - Introduce init_intc_phandle() to cover some details of interrupt controller phandle initialization. As an example, RISC-V could have different name for interrupt controller node ( APLIC, PLIC, IMSIC, etc ) but the code in domain_handle_dtb_bootmodule() could handle only one interrupt controller node name. - s/make_gic_domU_node/make_intc_domU_node as GIC is Arm specific naming and add prototype of make_intc_domU_node() to dom0less-build.h The following functions are moved to xen/common/device-tree: - Functions which are moved as is: - domain_p2m_pages(). - handle_passthrough_prop(). - handle_prop_pfdt(). - scan_pfdt_node(). - check_partial_fdt(). - Functions which are moved with some minor changes: - alloc_xenstore_evtchn(): - ifdef-ing by CONFIG_HVM accesses to hvm.params. - prepare_dtb_domU(): - ifdef-ing access to gnttab_{start,size} by CONFIG_GRANT_TABLE. - s/make_gic_domU_node/make_intc_domU_node. - Add call of make_arch_nodes(). - domain_handle_dtb_bootmodule(): - hide details of interrupt controller phandle initialization by calling init_intc_phandle(). - Update the comment above init_intc_phandle(): s/gic/interrupt controller. - construct_domU(): - ifdef-ing by CONFIG_HVM accesses to hvm.params. - Call init_vuart() to hide Arm's vpl011_init() details there. - Add call of set_domain_type() instead of setting kinfo->arch.type explicitly. Some parts of dom0less-build.c are wraped by #ifdef CONFIG_STATIC_{SHMEM,MEMORY} as not all archs support these configs. Signed-off-by: Oleksii Kurochko --- Change in v3: - Align construct_domU() with the current staging. - Align alloc_xenstore_params() with the current staging. - Move defintion of XENSTORE_PFN_LATE_ALLOC to common and declaration of need_xenstore to common. --- Change in v2: - Wrap by #ifdef CONFIG_STATIC_* inclusions of and . Wrap also the code which uses something from the mentioned headers. - Add handling of legacy case in construct_domU(). - Use xen/fdt-kernel.h and xen/fdt-domain-build.h instead of asm/*. - Update the commit message. --- xen/arch/arm/dom0less-build.c | 714 ++--------------------- xen/common/device-tree/dom0less-build.c | 699 ++++++++++++++++++++++ xen/include/asm-generic/dom0less-build.h | 18 +- 3 files changed, 751 insertions(+), 680 deletions(-) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 0310579863..627c212b3b 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -25,8 +25,6 @@ #include #include -bool __initdata need_xenstore; - #ifdef CONFIG_VGICV2 static int __init make_gicv2_domU_node(struct kernel_info *kinfo) { @@ -152,7 +150,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo) } #endif -static int __init make_gic_domU_node(struct kernel_info *kinfo) +int __init make_intc_domU_node(struct kernel_info *kinfo) { switch ( kinfo->d->arch.vgic.version ) { @@ -218,708 +216,60 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo) } #endif -/* - * Scan device tree properties for passthrough specific information. - * Returns < 0 on error - * 0 on success - */ -static int __init handle_passthrough_prop(struct kernel_info *kinfo, - const struct fdt_property *xen_reg, - const struct fdt_property *xen_path, - bool xen_force, - uint32_t address_cells, - uint32_t size_cells) -{ - const __be32 *cell; - unsigned int i, len; - struct dt_device_node *node; - int res; - paddr_t mstart, size, gstart; - - /* xen,reg specifies where to map the MMIO region */ - cell = (const __be32 *)xen_reg->data; - len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) * - sizeof(uint32_t)); - - for ( i = 0; i < len; i++ ) - { - device_tree_get_reg(&cell, address_cells, size_cells, - &mstart, &size); - gstart = dt_next_cell(address_cells, &cell); - - if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK ) - { - printk(XENLOG_ERR - "DomU passthrough config has not page aligned addresses/sizes\n"); - return -EINVAL; - } - - res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart), - paddr_to_pfn(PAGE_ALIGN(mstart + size - 1))); - if ( res ) - { - printk(XENLOG_ERR "Unable to permit to dom%d access to" - " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n", - kinfo->d->domain_id, - mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1); - return res; - } - - res = map_regions_p2mt(kinfo->d, - gaddr_to_gfn(gstart), - PFN_DOWN(size), - maddr_to_mfn(mstart), - p2m_mmio_direct_dev); - if ( res < 0 ) - { - printk(XENLOG_ERR - "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n", - mstart, gstart); - return -EFAULT; - } - } - - /* - * If xen_force, we let the user assign a MMIO region with no - * associated path. - */ - if ( xen_path == NULL ) - return xen_force ? 0 : -EINVAL; - - /* - * xen,path specifies the corresponding node in the host DT. - * Both interrupt mappings and IOMMU settings are based on it, - * as they are done based on the corresponding host DT node. - */ - node = dt_find_node_by_path(xen_path->data); - if ( node == NULL ) - { - printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n", - xen_path->data); - return -EINVAL; - } - - res = map_device_irqs_to_domain(kinfo->d, node, true, NULL); - if ( res < 0 ) - return res; - - res = iommu_add_dt_device(node); - if ( res < 0 ) - return res; - - /* If xen_force, we allow assignment of devices without IOMMU protection. */ - if ( xen_force && !dt_device_is_protected(node) ) - return 0; - - return iommu_assign_dt_device(kinfo->d, node); -} - -static int __init handle_prop_pfdt(struct kernel_info *kinfo, - const void *pfdt, int nodeoff, - uint32_t address_cells, uint32_t size_cells, - bool scan_passthrough_prop) -{ - void *fdt = kinfo->fdt; - int propoff, nameoff, res; - const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL; - const char *name; - bool found, xen_force = false; - - for ( propoff = fdt_first_property_offset(pfdt, nodeoff); - propoff >= 0; - propoff = fdt_next_property_offset(pfdt, propoff) ) - { - if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) ) - return -FDT_ERR_INTERNAL; - - found = false; - nameoff = fdt32_to_cpu(prop->nameoff); - name = fdt_string(pfdt, nameoff); - - if ( scan_passthrough_prop ) - { - if ( dt_prop_cmp("xen,reg", name) == 0 ) - { - xen_reg = prop; - found = true; - } - else if ( dt_prop_cmp("xen,path", name) == 0 ) - { - xen_path = prop; - found = true; - } - else if ( dt_prop_cmp("xen,force-assign-without-iommu", - name) == 0 ) - { - xen_force = true; - found = true; - } - } - - /* - * Copy properties other than the ones above: xen,reg, xen,path, - * and xen,force-assign-without-iommu. - */ - if ( !found ) - { - res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len)); - if ( res ) - return res; - } - } - - /* - * Only handle passthrough properties if both xen,reg and xen,path - * are present, or if xen,force-assign-without-iommu is specified. - */ - if ( xen_reg != NULL && (xen_path != NULL || xen_force) ) - { - res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force, - address_cells, size_cells); - if ( res < 0 ) - { - printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d); - return res; - } - } - else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) ) - { - printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n", - kinfo->d); - return -EINVAL; - } - - /* FDT_ERR_NOTFOUND => There is no more properties for this node */ - return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0; -} - -static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, - int nodeoff, - uint32_t address_cells, uint32_t size_cells, - bool scan_passthrough_prop) -{ - int rc = 0; - void *fdt = kinfo->fdt; - int node_next; - - rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL)); - if ( rc ) - return rc; - - rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells, - scan_passthrough_prop); - if ( rc ) - return rc; - - address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells", - DT_ROOT_NODE_ADDR_CELLS_DEFAULT); - size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells", - DT_ROOT_NODE_SIZE_CELLS_DEFAULT); - - node_next = fdt_first_subnode(pfdt, nodeoff); - while ( node_next > 0 ) - { - rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells, - scan_passthrough_prop); - if ( rc ) - return rc; - - node_next = fdt_next_subnode(pfdt, node_next); - } - - return fdt_end_node(fdt); -} - -static int __init check_partial_fdt(void *pfdt, size_t size) +int __init make_arch_nodes(struct kernel_info *kinfo) { - int res; - - if ( fdt_magic(pfdt) != FDT_MAGIC ) - { - dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree"); - return -EINVAL; - } - - res = fdt_check_header(pfdt); - if ( res ) - { - dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res); - return -EINVAL; - } - - if ( fdt_totalsize(pfdt) > size ) - { - dprintk(XENLOG_ERR, "Partial FDT totalsize is too big"); - return -EINVAL; - } - - return 0; -} - -static int __init domain_handle_dtb_bootmodule(struct domain *d, - struct kernel_info *kinfo) -{ - void *pfdt; - int res, node_next; - - pfdt = ioremap_cache(kinfo->dtb_bootmodule->start, - kinfo->dtb_bootmodule->size); - if ( pfdt == NULL ) - return -EFAULT; - - res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size); - if ( res < 0 ) - goto out; - - for ( node_next = fdt_first_subnode(pfdt, 0); - node_next > 0; - node_next = fdt_next_subnode(pfdt, node_next) ) - { - const char *name = fdt_get_name(pfdt, node_next, NULL); - - if ( name == NULL ) - continue; - - /* - * Only scan /gic /aliases /passthrough, ignore the rest. - * They don't have to be parsed in order. - * - * Take the GIC phandle value from the special /gic node in the - * DTB fragment. - */ - if ( dt_node_cmp(name, "gic") == 0 ) - { - uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); - - if ( phandle_intc != 0 ) - kinfo->phandle_intc = phandle_intc; - continue; - } - - if ( dt_node_cmp(name, "aliases") == 0 ) - { - res = scan_pfdt_node(kinfo, pfdt, node_next, - DT_ROOT_NODE_ADDR_CELLS_DEFAULT, - DT_ROOT_NODE_SIZE_CELLS_DEFAULT, - false); - if ( res ) - goto out; - continue; - } - if ( dt_node_cmp(name, "passthrough") == 0 ) - { - res = scan_pfdt_node(kinfo, pfdt, node_next, - DT_ROOT_NODE_ADDR_CELLS_DEFAULT, - DT_ROOT_NODE_SIZE_CELLS_DEFAULT, - true); - if ( res ) - goto out; - continue; - } - } - - out: - iounmap(pfdt); - - return res; -} - -/* - * The max size for DT is 2MB. However, the generated DT is small (not including - * domU passthrough DT nodes whose size we account separately), 4KB are enough - * for now, but we might have to increase it in the future. - */ -#define DOMU_DTB_SIZE 4096 -static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) -{ - int addrcells, sizecells; - int ret, fdt_size = DOMU_DTB_SIZE; - - kinfo->phandle_intc = GUEST_PHANDLE_GIC; - kinfo->gnttab_start = GUEST_GNTTAB_BASE; - kinfo->gnttab_size = GUEST_GNTTAB_SIZE; - - addrcells = GUEST_ROOT_ADDRESS_CELLS; - sizecells = GUEST_ROOT_SIZE_CELLS; - - /* Account for domU passthrough DT size */ - if ( kinfo->dtb_bootmodule ) - fdt_size += kinfo->dtb_bootmodule->size; - - /* Cap to max DT size if needed */ - fdt_size = min(fdt_size, SZ_2M); - - kinfo->fdt = xmalloc_bytes(fdt_size); - if ( kinfo->fdt == NULL ) - return -ENOMEM; - - ret = fdt_create(kinfo->fdt, fdt_size); - if ( ret < 0 ) - goto err; - - ret = fdt_finish_reservemap(kinfo->fdt); - if ( ret < 0 ) - goto err; - - ret = fdt_begin_node(kinfo->fdt, ""); - if ( ret < 0 ) - goto err; - - ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells); - if ( ret ) - goto err; - - ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells); - if ( ret ) - goto err; - - ret = make_chosen_node(kinfo); - if ( ret ) - goto err; + int ret; ret = make_psci_node(kinfo->fdt); if ( ret ) - goto err; - - ret = make_cpus_node(d, kinfo->fdt); - if ( ret ) - goto err; - - ret = make_memory_node(kinfo, addrcells, sizecells, - kernel_info_get_mem(kinfo)); - if ( ret ) - goto err; - - ret = make_resv_memory_node(kinfo, addrcells, sizecells); - if ( ret ) - goto err; - - /* - * domain_handle_dtb_bootmodule has to be called before the rest of - * the device tree is generated because it depends on the value of - * the field phandle_intc. - */ - if ( kinfo->dtb_bootmodule ) - { - ret = domain_handle_dtb_bootmodule(d, kinfo); - if ( ret ) - goto err; - } - - ret = make_gic_domU_node(kinfo); - if ( ret ) - goto err; - - ret = make_timer_node(kinfo); - if ( ret ) - goto err; + return -EINVAL; if ( kinfo->vuart ) { - ret = -EINVAL; #ifdef CONFIG_SBSA_VUART_CONSOLE ret = make_vpl011_uart_node(kinfo); #endif if ( ret ) - goto err; - } - - if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS ) - { - ret = make_hypervisor_node(d, kinfo, addrcells, sizecells); - if ( ret ) - goto err; + return -EINVAL; } - ret = fdt_end_node(kinfo->fdt); - if ( ret < 0 ) - goto err; - - ret = fdt_finish(kinfo->fdt); - if ( ret < 0 ) - goto err; - return 0; - - err: - printk("Device tree generation failed (%d).\n", ret); - xfree(kinfo->fdt); - - return -EINVAL; } -#define XENSTORE_PFN_OFFSET 1 -static int __init alloc_xenstore_page(struct domain *d) +/* TODO: make arch.type generic ? */ +#ifdef CONFIG_ARM_64 +void __init set_domain_type(struct domain *d, struct kernel_info *kinfo) { - struct page_info *xenstore_pg; - struct xenstore_domain_interface *interface; - mfn_t mfn; - gfn_t gfn; - int rc; - - if ( (UINT_MAX - d->max_pages) < 1 ) - { - printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n", - d); - return -EINVAL; - } - - d->max_pages += 1; - xenstore_pg = alloc_domheap_page(d, MEMF_bits(32)); - if ( xenstore_pg == NULL && is_64bit_domain(d) ) - xenstore_pg = alloc_domheap_page(d, 0); - if ( xenstore_pg == NULL ) - return -ENOMEM; - - mfn = page_to_mfn(xenstore_pg); - if ( !mfn_x(mfn) ) - return -ENOMEM; - - if ( !is_domain_direct_mapped(d) ) - gfn = gaddr_to_gfn(GUEST_MAGIC_BASE + - (XENSTORE_PFN_OFFSET << PAGE_SHIFT)); - else - gfn = gaddr_to_gfn(mfn_to_maddr(mfn)); - - rc = guest_physmap_add_page(d, gfn, mfn, 0); - if ( rc ) - { - free_domheap_page(xenstore_pg); - return rc; - } - - d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn); - interface = map_domain_page(mfn); - interface->connection = XENSTORE_RECONNECT; - unmap_domain_page(interface); - - return 0; + /* type must be set before allocate memory */ + d->arch.type = kinfo->arch.type; } - -static int __init alloc_xenstore_params(struct kernel_info *kinfo) +#else +void __init set_domain_type(struct domain *d, struct kernel_info *kinfo) { - struct domain *d = kinfo->d; - int rc = 0; - - if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY)) - == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) ) - d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC; - else if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE ) - { - rc = alloc_xenstore_page(d); - if ( rc < 0 ) - return rc; - } - - return rc; + /* Nothing to do */ } +#endif -static void __init domain_vcpu_affinity(struct domain *d, - const struct dt_device_node *node) +int __init init_vuart(struct domain *d, struct kernel_info *kinfo, + const struct dt_device_node *node) { - struct dt_device_node *np; - - dt_for_each_child_node(node, np) - { - const char *hard_affinity_str = NULL; - uint32_t val; - int rc; - struct vcpu *v; - cpumask_t affinity; - - if ( !dt_device_is_compatible(np, "xen,vcpu") ) - continue; - - if ( !dt_property_read_u32(np, "id", &val) ) - panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node)); - - if ( val >= d->max_vcpus ) - panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val, - dt_node_name(node), d->max_vcpus); - - v = d->vcpu[val]; - rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str); - if ( rc < 0 ) - continue; - - cpumask_clear(&affinity); - while ( *hard_affinity_str != '\0' ) - { - unsigned int start, end; - - start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); - - if ( *hard_affinity_str == '-' ) /* Range */ - { - hard_affinity_str++; - end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); - } - else /* Single value */ - end = start; - - if ( end >= nr_cpu_ids ) - panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node)); - - for ( ; start <= end; start++ ) - cpumask_set_cpu(start, &affinity); - - if ( *hard_affinity_str == ',' ) - hard_affinity_str++; - else if ( *hard_affinity_str != '\0' ) - break; - } + int rc = 0; - rc = vcpu_set_hard_affinity(v, &affinity); - if ( rc ) - panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n", - v->vcpu_id, rc, dt_node_name(node)); - } -} + kinfo->vuart = dt_property_read_bool(node, "vpl011"); -#ifdef CONFIG_ARCH_PAGING_MEMPOOL -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. + * Base address and irq number are needed when creating vpl011 device + * tree node in prepare_dtb_domU, so initialization on related variables + * shall be done first. */ - unsigned long memkb = 4 * (256 * smp_cpus + (maxmem_kb / 1024) + 128); - - BUILD_BUG_ON(PAGE_SIZE != SZ_4K); - - return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT); -} - -static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem, - const struct dt_device_node *node) -{ - unsigned long p2m_pages; - uint32_t p2m_mem_mb; - int rc; - - rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb); - /* If xen,domain-p2m-mem-mb is not specified, use the default value. */ - p2m_pages = rc ? - p2m_mem_mb << (20 - PAGE_SHIFT) : - domain_p2m_pages(mem, d->max_vcpus); - - spin_lock(&d->arch.paging.lock); - rc = p2m_set_allocation(d, p2m_pages, NULL); - spin_unlock(&d->arch.paging.lock); - - return rc; -} -#else /* !CONFIG_ARCH_PAGING_MEMPOOL */ -static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem, - const struct dt_device_node *node) -{ - return 0; -} -#endif /* CONFIG_ARCH_PAGING_MEMPOOL */ - -int __init construct_domU(struct domain *d, - const struct dt_device_node *node) -{ - struct kernel_info kinfo = KERNEL_INFO_INIT; - const char *dom0less_enhanced; - int rc; - u64 mem; - - rc = dt_property_read_u64(node, "memory", &mem); - if ( !rc ) - { - printk("Error building DomU: cannot read \"memory\" property\n"); - return -EINVAL; - } - kinfo.unassigned_mem = (paddr_t)mem * SZ_1K; - - rc = domain_p2m_set_allocation(d, mem, node); - if ( rc != 0 ) - return rc; - - printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n", - d->max_vcpus, mem); - - kinfo.vuart = dt_property_read_bool(node, "vpl011"); - if ( kinfo.vuart && is_hardware_domain(d) ) - panic("hardware domain cannot specify vpl011\n"); - - rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced); - if ( rc == -EILSEQ || - rc == -ENODATA || - (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) ) - { - need_xenstore = true; - kinfo.dom0less_feature = DOM0LESS_ENHANCED; - } - else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") ) - { - need_xenstore = true; - kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY; - } - else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) - kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS; - - if ( vcpu_create(d, 0) == NULL ) - return -ENOMEM; - - d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; - - kinfo.d = d; - - rc = kernel_probe(&kinfo, node); - if ( rc < 0 ) - return rc; - -#ifdef CONFIG_ARM_64 - /* type must be set before allocate memory */ - d->arch.type = kinfo.arch.type; -#endif - if ( is_hardware_domain(d) ) - { - rc = construct_hwdom(&kinfo, node); - if ( rc < 0 ) - return rc; - } - else + if ( kinfo->vuart ) { - if ( !dt_find_property(node, "xen,static-mem", NULL) ) - allocate_memory(d, &kinfo); - else if ( !is_domain_direct_mapped(d) ) - allocate_static_memory(d, &kinfo, node); - else - assign_static_memory_11(d, &kinfo, node); - - rc = process_shm(d, &kinfo, node); - if ( rc < 0 ) - return rc; - - /* - * Base address and irq number are needed when creating vpl011 device - * tree node in prepare_dtb_domU, so initialization on related variables - * shall be done first. - */ - if ( kinfo.vuart ) - { - rc = domain_vpl011_init(d, NULL); - if ( rc < 0 ) - return rc; - } - - rc = prepare_dtb_domU(d, &kinfo); - if ( rc < 0 ) - return rc; - - rc = construct_domain(d, &kinfo); + rc = domain_vpl011_init(d, NULL); if ( rc < 0 ) return rc; } - domain_vcpu_affinity(d, node); - - return alloc_xenstore_params(&kinfo); + return rc; } void __init arch_create_domUs(struct dt_device_node *node, @@ -995,6 +345,22 @@ void __init arch_create_domUs(struct dt_device_node *node, } } +int __init init_intc_phandle(struct kernel_info *kinfo, const char *name, + const int node_next, const void *pfdt) +{ + if ( dt_node_cmp(name, "gic") == 0 ) + { + uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); + + if ( phandle_intc != 0 ) + kinfo->phandle_intc = phandle_intc; + + return 0; + } + + return 1; +} + /* * Local variables: * mode: C diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c index a01a8b6b1a..c3face5b90 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -3,24 +3,43 @@ #include #include #include +#include #include #include +#include +#include #include #include +#include #include +#include #include +#include #include #include #include +#include #include #include #include +#include #include #include +#ifdef CONFIG_STATIC_MEMORY +#include +#endif + +#ifdef CONFIG_STATIC_SHM +#include +#endif + +#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX + static domid_t __initdata xs_domid = DOMID_INVALID; +static bool __initdata need_xenstore; void __init set_xs_domain(struct domain *d) { @@ -109,6 +128,686 @@ static void __init initialize_domU_xenstore(void) } } +/* + * Scan device tree properties for passthrough specific information. + * Returns < 0 on error + * 0 on success + */ +static int __init handle_passthrough_prop(struct kernel_info *kinfo, + const struct fdt_property *xen_reg, + const struct fdt_property *xen_path, + bool xen_force, + uint32_t address_cells, + uint32_t size_cells) +{ + const __be32 *cell; + unsigned int i, len; + struct dt_device_node *node; + int res; + paddr_t mstart, size, gstart; + + /* xen,reg specifies where to map the MMIO region */ + cell = (const __be32 *)xen_reg->data; + len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) * + sizeof(uint32_t)); + + for ( i = 0; i < len; i++ ) + { + device_tree_get_reg(&cell, address_cells, size_cells, + &mstart, &size); + gstart = dt_next_cell(address_cells, &cell); + + if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK ) + { + printk(XENLOG_ERR + "DomU passthrough config has not page aligned addresses/sizes\n"); + return -EINVAL; + } + + res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart), + paddr_to_pfn(PAGE_ALIGN(mstart + size - 1))); + if ( res ) + { + printk(XENLOG_ERR "Unable to permit to dom%d access to" + " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n", + kinfo->d->domain_id, + mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1); + return res; + } + + res = map_regions_p2mt(kinfo->d, + gaddr_to_gfn(gstart), + PFN_DOWN(size), + maddr_to_mfn(mstart), + p2m_mmio_direct_dev); + if ( res < 0 ) + { + printk(XENLOG_ERR + "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n", + mstart, gstart); + return -EFAULT; + } + } + + /* + * If xen_force, we let the user assign a MMIO region with no + * associated path. + */ + if ( xen_path == NULL ) + return xen_force ? 0 : -EINVAL; + + /* + * xen,path specifies the corresponding node in the host DT. + * Both interrupt mappings and IOMMU settings are based on it, + * as they are done based on the corresponding host DT node. + */ + node = dt_find_node_by_path(xen_path->data); + if ( node == NULL ) + { + printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n", + xen_path->data); + return -EINVAL; + } + + res = map_device_irqs_to_domain(kinfo->d, node, true, NULL); + if ( res < 0 ) + return res; + + res = iommu_add_dt_device(node); + if ( res < 0 ) + return res; + + /* If xen_force, we allow assignment of devices without IOMMU protection. */ + if ( xen_force && !dt_device_is_protected(node) ) + return 0; + + return iommu_assign_dt_device(kinfo->d, node); +} + +static int __init handle_prop_pfdt(struct kernel_info *kinfo, + const void *pfdt, int nodeoff, + uint32_t address_cells, uint32_t size_cells, + bool scan_passthrough_prop) +{ + void *fdt = kinfo->fdt; + int propoff, nameoff, res; + const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL; + const char *name; + bool found, xen_force = false; + + for ( propoff = fdt_first_property_offset(pfdt, nodeoff); + propoff >= 0; + propoff = fdt_next_property_offset(pfdt, propoff) ) + { + if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) ) + return -FDT_ERR_INTERNAL; + + found = false; + nameoff = fdt32_to_cpu(prop->nameoff); + name = fdt_string(pfdt, nameoff); + + if ( scan_passthrough_prop ) + { + if ( dt_prop_cmp("xen,reg", name) == 0 ) + { + xen_reg = prop; + found = true; + } + else if ( dt_prop_cmp("xen,path", name) == 0 ) + { + xen_path = prop; + found = true; + } + else if ( dt_prop_cmp("xen,force-assign-without-iommu", + name) == 0 ) + { + xen_force = true; + found = true; + } + } + + /* + * Copy properties other than the ones above: xen,reg, xen,path, + * and xen,force-assign-without-iommu. + */ + if ( !found ) + { + res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len)); + if ( res ) + return res; + } + } + + /* + * Only handle passthrough properties if both xen,reg and xen,path + * are present, or if xen,force-assign-without-iommu is specified. + */ + if ( xen_reg != NULL && (xen_path != NULL || xen_force) ) + { + res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force, + address_cells, size_cells); + if ( res < 0 ) + { + printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d); + return res; + } + } + else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) ) + { + printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n", + kinfo->d); + return -EINVAL; + } + + /* FDT_ERR_NOTFOUND => There is no more properties for this node */ + return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0; +} + +static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, + int nodeoff, + uint32_t address_cells, uint32_t size_cells, + bool scan_passthrough_prop) +{ + int rc = 0; + void *fdt = kinfo->fdt; + int node_next; + + rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL)); + if ( rc ) + return rc; + + rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells, + scan_passthrough_prop); + if ( rc ) + return rc; + + address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells", + DT_ROOT_NODE_ADDR_CELLS_DEFAULT); + size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells", + DT_ROOT_NODE_SIZE_CELLS_DEFAULT); + + node_next = fdt_first_subnode(pfdt, nodeoff); + while ( node_next > 0 ) + { + rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells, + scan_passthrough_prop); + if ( rc ) + return rc; + + node_next = fdt_next_subnode(pfdt, node_next); + } + + return fdt_end_node(fdt); +} + +static int __init check_partial_fdt(void *pfdt, size_t size) +{ + int res; + + if ( fdt_magic(pfdt) != FDT_MAGIC ) + { + dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree"); + return -EINVAL; + } + + res = fdt_check_header(pfdt); + if ( res ) + { + dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res); + return -EINVAL; + } + + if ( fdt_totalsize(pfdt) > size ) + { + dprintk(XENLOG_ERR, "Partial FDT totalsize is too big"); + return -EINVAL; + } + + return 0; +} + +static int __init domain_handle_dtb_bootmodule(struct domain *d, + struct kernel_info *kinfo) +{ + void *pfdt; + int res, node_next; + + pfdt = ioremap_cache(kinfo->dtb_bootmodule->start, + kinfo->dtb_bootmodule->size); + if ( pfdt == NULL ) + return -EFAULT; + + res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size); + if ( res < 0 ) + goto out; + + for ( node_next = fdt_first_subnode(pfdt, 0); + node_next > 0; + node_next = fdt_next_subnode(pfdt, node_next) ) + { + const char *name = fdt_get_name(pfdt, node_next, NULL); + + if ( name == NULL ) + continue; + + /* + * Only scan /$(interrupt_controller) /aliases /passthrough, + * ignore the rest. + * They don't have to be parsed in order. + * + * Take the interrupt controller phandle value from the special + * interrupt controller node in the DTB fragment. + */ + if ( init_intc_phandle(kinfo, name, node_next, pfdt) == 0 ) + continue; + + if ( dt_node_cmp(name, "aliases") == 0 ) + { + res = scan_pfdt_node(kinfo, pfdt, node_next, + DT_ROOT_NODE_ADDR_CELLS_DEFAULT, + DT_ROOT_NODE_SIZE_CELLS_DEFAULT, + false); + if ( res ) + goto out; + continue; + } + if ( dt_node_cmp(name, "passthrough") == 0 ) + { + res = scan_pfdt_node(kinfo, pfdt, node_next, + DT_ROOT_NODE_ADDR_CELLS_DEFAULT, + DT_ROOT_NODE_SIZE_CELLS_DEFAULT, + true); + if ( res ) + goto out; + continue; + } + } + + out: + iounmap(pfdt); + + return res; +} + +/* + * The max size for DT is 2MB. However, the generated DT is small (not including + * domU passthrough DT nodes whose size we account separately), 4KB are enough + * for now, but we might have to increase it in the future. + */ +#define DOMU_DTB_SIZE 4096 +static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) +{ + int addrcells, sizecells; + int ret, fdt_size = DOMU_DTB_SIZE; + + kinfo->phandle_intc = GUEST_PHANDLE_GIC; + +#ifdef CONFIG_GRANT_TABLE + kinfo->gnttab_start = GUEST_GNTTAB_BASE; + kinfo->gnttab_size = GUEST_GNTTAB_SIZE; +#endif + + addrcells = GUEST_ROOT_ADDRESS_CELLS; + sizecells = GUEST_ROOT_SIZE_CELLS; + + /* Account for domU passthrough DT size */ + if ( kinfo->dtb_bootmodule ) + fdt_size += kinfo->dtb_bootmodule->size; + + /* Cap to max DT size if needed */ + fdt_size = min(fdt_size, SZ_2M); + + kinfo->fdt = xmalloc_bytes(fdt_size); + if ( kinfo->fdt == NULL ) + return -ENOMEM; + + ret = fdt_create(kinfo->fdt, fdt_size); + if ( ret < 0 ) + goto err; + + ret = fdt_finish_reservemap(kinfo->fdt); + if ( ret < 0 ) + goto err; + + ret = fdt_begin_node(kinfo->fdt, ""); + if ( ret < 0 ) + goto err; + + ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells); + if ( ret ) + goto err; + + ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells); + if ( ret ) + goto err; + + ret = make_chosen_node(kinfo); + if ( ret ) + goto err; + + ret = make_cpus_node(d, kinfo->fdt); + if ( ret ) + goto err; + + ret = make_memory_node(kinfo, addrcells, sizecells, + kernel_info_get_mem(kinfo)); + if ( ret ) + goto err; + +#ifdef CONFIG_STATIC_SHM + ret = make_resv_memory_node(kinfo, addrcells, sizecells); + if ( ret ) + goto err; +#endif + + /* + * domain_handle_dtb_bootmodule has to be called before the rest of + * the device tree is generated because it depends on the value of + * the field phandle_intc. + */ + if ( kinfo->dtb_bootmodule ) + { + ret = domain_handle_dtb_bootmodule(d, kinfo); + if ( ret ) + goto err; + } + + ret = make_intc_domU_node(kinfo); + if ( ret ) + goto err; + + ret = make_timer_node(kinfo); + if ( ret ) + goto err; + + if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS ) + { + ret = make_hypervisor_node(d, kinfo, addrcells, sizecells); + if ( ret ) + goto err; + } + + ret = make_arch_nodes(kinfo); + if ( ret ) + goto err; + + ret = fdt_end_node(kinfo->fdt); + if ( ret < 0 ) + goto err; + + ret = fdt_finish(kinfo->fdt); + if ( ret < 0 ) + goto err; + + return 0; + + err: + printk("Device tree generation failed (%d).\n", ret); + xfree(kinfo->fdt); + + return -EINVAL; +} + +#define XENSTORE_PFN_OFFSET 1 +static int __init alloc_xenstore_page(struct domain *d) +{ + struct page_info *xenstore_pg; + struct xenstore_domain_interface *interface; + mfn_t mfn; + gfn_t gfn; + int rc; + + if ( (UINT_MAX - d->max_pages) < 1 ) + { + printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n", + d); + return -EINVAL; + } + + d->max_pages += 1; + xenstore_pg = alloc_domheap_page(d, MEMF_bits(32)); + if ( xenstore_pg == NULL && is_64bit_domain(d) ) + xenstore_pg = alloc_domheap_page(d, 0); + if ( xenstore_pg == NULL ) + return -ENOMEM; + + mfn = page_to_mfn(xenstore_pg); + if ( !mfn_x(mfn) ) + return -ENOMEM; + + if ( !is_domain_direct_mapped(d) ) + gfn = gaddr_to_gfn(GUEST_MAGIC_BASE + + (XENSTORE_PFN_OFFSET << PAGE_SHIFT)); + else + gfn = gaddr_to_gfn(mfn_to_maddr(mfn)); + + rc = guest_physmap_add_page(d, gfn, mfn, 0); + if ( rc ) + { + free_domheap_page(xenstore_pg); + return rc; + } + +#ifdef CONFIG_HVM + d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn); +#endif + interface = map_domain_page(mfn); + interface->connection = XENSTORE_RECONNECT; + unmap_domain_page(interface); + + return 0; +} + +static int __init alloc_xenstore_params(struct kernel_info *kinfo) +{ + struct domain *d = kinfo->d; + int rc = 0; + +#ifdef CONFIG_HVM + if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY)) + == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) ) + d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC; + else +#endif + if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE ) + { + rc = alloc_xenstore_page(d); + if ( rc < 0 ) + return rc; + } + + return rc; +} + +static void __init domain_vcpu_affinity(struct domain *d, + const struct dt_device_node *node) +{ + struct dt_device_node *np; + + dt_for_each_child_node(node, np) + { + const char *hard_affinity_str = NULL; + uint32_t val; + int rc; + struct vcpu *v; + cpumask_t affinity; + + if ( !dt_device_is_compatible(np, "xen,vcpu") ) + continue; + + if ( !dt_property_read_u32(np, "id", &val) ) + panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node)); + + if ( val >= d->max_vcpus ) + panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val, + dt_node_name(node), d->max_vcpus); + + v = d->vcpu[val]; + rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str); + if ( rc < 0 ) + continue; + + cpumask_clear(&affinity); + while ( *hard_affinity_str != '\0' ) + { + unsigned int start, end; + + start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); + + if ( *hard_affinity_str == '-' ) /* Range */ + { + hard_affinity_str++; + end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); + } + else /* Single value */ + end = start; + + if ( end >= nr_cpu_ids ) + panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node)); + + for ( ; start <= end; start++ ) + cpumask_set_cpu(start, &affinity); + + if ( *hard_affinity_str == ',' ) + hard_affinity_str++; + else if ( *hard_affinity_str != '\0' ) + break; + } + + rc = vcpu_set_hard_affinity(v, &affinity); + if ( rc ) + panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n", + v->vcpu_id, rc, dt_node_name(node)); + } +} + +#ifdef CONFIG_ARCH_PAGING_MEMPOOL +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); + + BUILD_BUG_ON(PAGE_SIZE != SZ_4K); + + return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT); +} + +static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem, + const struct dt_device_node *node) +{ + unsigned long p2m_pages; + uint32_t p2m_mem_mb; + int rc; + + rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb); + /* If xen,domain-p2m-mem-mb is not specified, use the default value. */ + p2m_pages = rc ? + p2m_mem_mb << (20 - PAGE_SHIFT) : + domain_p2m_pages(mem, d->max_vcpus); + + spin_lock(&d->arch.paging.lock); + rc = p2m_set_allocation(d, p2m_pages, NULL); + spin_unlock(&d->arch.paging.lock); + + return rc; +} +#else /* !CONFIG_ARCH_PAGING_MEMPOOL */ +static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem, + const struct dt_device_node *node) +{ + return 0; +} +#endif /* CONFIG_ARCH_PAGING_MEMPOOL */ + +static int __init construct_domU(struct domain *d, + const struct dt_device_node *node) +{ + struct kernel_info kinfo = KERNEL_INFO_INIT; + const char *dom0less_enhanced; + int rc; + u64 mem; + + rc = dt_property_read_u64(node, "memory", &mem); + if ( !rc ) + { + printk("Error building DomU: cannot read \"memory\" property\n"); + return -EINVAL; + } + kinfo.unassigned_mem = (paddr_t)mem * SZ_1K; + + rc = domain_p2m_set_allocation(d, mem, node); + if ( rc != 0 ) + return rc; + + printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n", + d->max_vcpus, mem); + + rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced); + if ( rc == -EILSEQ || + rc == -ENODATA || + (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) ) + { + need_xenstore = true; + kinfo.dom0less_feature = DOM0LESS_ENHANCED; + } + else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") ) + { + need_xenstore = true; + kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY; + } + else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) + kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS; + + if ( vcpu_create(d, 0) == NULL ) + return -ENOMEM; + + d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; + + kinfo.d = d; + + rc = kernel_probe(&kinfo, node); + if ( rc < 0 ) + return rc; + + set_domain_type(d, &kinfo); + + if ( !dt_find_property(node, "xen,static-mem", NULL) ) + allocate_memory(d, &kinfo); +#ifdef CONFIG_STATIC_MEMORY + else if ( !is_domain_direct_mapped(d) ) + allocate_static_memory(d, &kinfo, node); + else + assign_static_memory_11(d, &kinfo, node); +#endif + +#ifdef CONFIG_STATIC_SHM + rc = process_shm(d, &kinfo, node); + if ( rc < 0 ) + return rc; +#endif + + rc = init_vuart(d, &kinfo, node); + if ( rc < 0 ) + return rc; + + rc = prepare_dtb_domU(d, &kinfo); + if ( rc < 0 ) + return rc; + + rc = construct_domain(d, &kinfo); + if ( rc < 0 ) + return rc; + + domain_vcpu_affinity(d, node); + + return alloc_xenstore_params(&kinfo); +} + void __init create_domUs(void) { struct dt_device_node *node; diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h index f095135caa..c00bb853d6 100644 --- a/xen/include/asm-generic/dom0less-build.h +++ b/xen/include/asm-generic/dom0less-build.h @@ -11,10 +11,7 @@ struct domain; struct dt_device_node; - -/* TODO: remove both when construct_domU() will be moved to common. */ -#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX -extern bool need_xenstore; +struct kernel_info; /* * List of possible features for dom0less domUs @@ -48,12 +45,21 @@ void create_domUs(void); bool is_dom0less_mode(void); void set_xs_domain(struct domain *d); -int construct_domU(struct domain *d, const struct dt_device_node *node); - void arch_create_domUs(struct dt_device_node *node, struct xen_domctl_createdomain *d_cfg, unsigned int flags); +int init_vuart(struct domain *d, struct kernel_info *kinfo, + const struct dt_device_node *node); + +int make_intc_domU_node(struct kernel_info *kinfo); +int make_arch_nodes(struct kernel_info *kinfo); + +void set_domain_type(struct domain *d, struct kernel_info *kinfo); + +int init_intc_phandle(struct kernel_info *kinfo, const char *name, + const int node_next, const void *pfdt); + #else /* !CONFIG_DOM0LESS_BOOT */ static inline void create_domUs(void) {} -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Fri May 02 16:49:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 16:49:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974916.1362634 (Exim 4.92) (envelope-from ) id 1uAtZx-0005lB-59; Fri, 02 May 2025 16:49:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974916.1362634; Fri, 02 May 2025 16:49: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 1uAtZx-0005l4-1r; Fri, 02 May 2025 16:49:37 +0000 Received: by outflank-mailman (input) for mailman id 974916; Fri, 02 May 2025 16:49:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAtZw-0005ky-6k for xen-devel@lists.xenproject.org; Fri, 02 May 2025 16:49:36 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6cb7235f-2775-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 18:49:34 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 754C4A4BDF0; Fri, 2 May 2025 16:44:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC4FBC4CEE4; Fri, 2 May 2025 16: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" X-Inumbo-ID: 6cb7235f-2775-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746204572; bh=WpuArh3K37LWZSj0UEq6/EWnz+FJnfy9DuvaKoNMZkM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=LRREwy8BAOgR0ndNk5hIbWQ9Kbtzlwd9pbLFBX41WxYkSaKonXWD7AFpBql2W3+mL 7mZpxLcK4uMy73UgG4mS4/JooQa+hTB+4LcKNlLGFWiRAJUQhIyopkqYo9JK6JWBCC dF+HFgYrBQyOiOy74ibYsM4doKevuud4n3h0Ufm95hJ2Apye0egKNeBPHePPuChsZ1 E+nrbtoD7kCAX3YKwm8hJ5QJjB/4otR3Y7I9AzWFwC2bjkix/mC1UScwOXNcZgRRRu g9UfTgq6D2G2m6e5E5JiMf1uun11jRVpijdJQ3MzaCqOVnRc757oPnfdmZDotd7n5O 0fbhIu6a7mPqQ== Date: Fri, 2 May 2025 09:49:30 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Jason Andryuk , Stefano Stabellini , "Ragiadakou, Xenia" , Andrew Cooper , agarciav@amd.com, xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange In-Reply-To: <773170d1-d8ba-4ba7-90b0-df0d160d8ba8@suse.com> Message-ID: References: <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com> <06b66971-d8db-456f-8e83-a20ff7df8f5e@suse.com> <59bfc389-66c8-4d0f-92e3-c0079a807374@suse.com> <3e7b4b20-0127-4db2-806d-f142547f275a@amd.com> <773170d1-d8ba-4ba7-90b0-df0d160d8ba8@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1940203065-1746204572=:3879245" 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-1940203065-1746204572=:3879245 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Fri, 2 May 2025, Jan Beulich wrote: > On 01.05.2025 15:44, Jason Andryuk wrote: > > On 2025-04-30 20:19, Stefano Stabellini wrote: > >> On Wed, 30 Apr 2025, Roger Pau Monné wrote: > >>> On Wed, Apr 30, 2025 at 08:27:55AM +0200, Jan Beulich wrote: > >>>> On 29.04.2025 23:52, Stefano Stabellini wrote: > >>>>> On Tue, 29 Apr 2025, Jan Beulich wrote: > >>>>>> On 28.04.2025 22:00, Stefano Stabellini wrote: > >>>>>>> On Mon, 28 Apr 2025, Jan Beulich wrote: > >>>>>>>> On 25.04.2025 22:19, Stefano Stabellini wrote: > > > >>>>>>>>> --- a/xen/common/memory.c > >>>>>>>>> +++ b/xen/common/memory.c > >>>>>>>>> @@ -794,7 +794,7 @@ static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg) > >>>>>>>>> rc = guest_physmap_add_page(d, _gfn(gpfn), mfn, > >>>>>>>>> exch.out.extent_order) ?: rc; > >>>>>>>>> > >>>>>>>>> - if ( !paging_mode_translate(d) && > >>>>>>>>> + if ( (!paging_mode_translate(d) || is_hardware_domain(d)) && > >>>>>>>>> __copy_mfn_to_guest_offset(exch.out.extent_start, > >>>>>>>>> (i << out_chunk_order) + j, > >>>>>>>>> mfn) ) > >>>>>>>> > >>>>>>>> Wait, no: A PVH domain (Dom0 or not) can't very well make use of MFNs, can > >>>>>>>> it? > >>>>>>> > >>>>>>> One way or another Dom0 PVH needs to know the MFN to pass it to the > >>>>>>> co-processor. > >>>>>> > >>>>>> I see. That's pretty odd, though. I'm then further concerned of the order of > >>>>>> the chunks. At present we're rather lax, in permitting PVH and PV Dom0 the > >>>>>> same upper bound. With both CPU and I/O side translation there is, in > >>>>>> principle, no reason to permit any kind of contiguity. Of course there's a > >>>>>> performance aspect, but that hardly matters in the specific case here. Yet at > >>>>>> the same time, once we expose MFNs, contiguity will start mattering as soon > >>>>>> as any piece of memory needs to be larger than PAGE_SIZE. Which means it will > >>>>>> make tightening of the presently lax handling prone to regressions in this > >>>>>> new behavior you're introducing. What chunk size does the PSP driver require? > >>>>> > >>>>> I don't know. The memory returned by XENMEM_exchange is contiguous, > >>>>> right? Are you worried that Xen cannot allocate the requested amount of > >>>>> memory contiguously? > > > > In the case I looked at, it is 8 pages. The driver defines a ring of 32 > > * 1k entries. I'm not sure if there are other paths or device versions > > where it might differ. > > As per this ... > > >>>> That would be Dom0's problem then. But really for a translated guest the > >>>> exchanged chunks being contiguous shouldn't matter, correctness-wise. That is, > >>>> within Xen, rather than failing a request, we could choose to retry using > >>>> discontiguous chunks (contiguous only in GFN space). Such an (afaict) > >>>> otherwise correct change would break your use case, as it would invalidate the > >>>> MFN information passed back. (This fallback approach would similarly apply to > >>>> other related mem-ops. It's just that during domain creation the tool stack > >>>> has its own fallback, so it may not be of much use right now.) > >>> > >>> I think the description in the public header needs to be expanded to > >>> specify what the XENMEM_exchange does for translated guests, and > >>> clearly write down that the underlying MFNs for the exchanged region > >>> will be contiguous. Possibly a new XENMEMF_ flag needs to be added to > >>> request contiguous physical memory for the new range. > >>> > >>> Sadly this also has the side effect of quite likely shattering > >>> superpages for dom0 EPT/NPT, which will result in decreased dom0 > >>> performance. > > > > Yes, this appears to happen as memory_exchange seems to always replace > > the pages. I tested returning the existing MFNs if they are already > > contiguous since that was sufficient for this driver. It worked, but it > > was messy. A big loop to copy in the GFN array and check contiguity > > which duplicated much of the real loop. > > ... there may not be a need for the output range to be contiguous? In which > case - wouldn't a simple "give me the MFN for this GFN" hypercall do? I seem > to vaguely recall that we even had one, long ago; it was purged because of > it violating the "no MFNs exposed" principle (and because it not having had > any use [anymore]). XENMEM_translate_gpfn_list looks like is what I mean; > see commit 2d2f7977a052. Unfortunately I don't think that would work because I am pretty sure that the PSP needs a consecutive range. In other words, I think the output needs to be contiguous. --8323329-1940203065-1746204572=:3879245-- From xen-devel-bounces@lists.xenproject.org Fri May 02 17:07:50 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 17:07:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974933.1362660 (Exim 4.92) (envelope-from ) id 1uAtrU-00019D-OL; Fri, 02 May 2025 17:07:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974933.1362660; Fri, 02 May 2025 17:07:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAtrU-000196-Li; Fri, 02 May 2025 17:07:44 +0000 Received: by outflank-mailman (input) for mailman id 974933; Fri, 02 May 2025 17:07:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAtrT-000190-ET for xen-devel@lists.xenproject.org; Fri, 02 May 2025 17:07:43 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f4ab17da-2777-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 19:07:42 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7797C5C5C61; Fri, 2 May 2025 17:05:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DCFCC4CEF1; Fri, 2 May 2025 17:07: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" X-Inumbo-ID: f4ab17da-2777-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746205659; bh=MXrACGyqOXVDhEpixyz+BKgn/54QO0zKMHCOhJK/g/w=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=J253chSfz1Zth/9KTy40/Pi1vYhW0Rzzbthbcj+GVZ18ko3rOCUZLGTyhhxwFgx0r W2Ho1najoPyOqqBHByYN1KulAmWUNVyKHoQJtusev5e9I3XUKS4eHmSfJY2U7zM+it 4jaVUpVQ1hkUGs3e5Og32KvWDsKFyOC8EQTJkDGzlwc4eaM9PfMnxie1wr6MvSqI4H yCwpAD1kTF65nqbFtIFxxqmN9L5M1KeNBG3fDW3fnoDEU6F3kbh2lvMHWYv9oyyK2m AhBD0dLSaOPzHXCf7qmm7SStTCcGe9xMIKrAm+pWoKqGTq9qQAbbEXsojEqabNRHut z32AYz4whVdzA== Date: Fri, 2 May 2025 10:07:36 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: John Ernberg cc: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Catalin Marinas , Andrew Morton , "xen-devel@lists.xenproject.org" , "iommu@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "imx@lists.linux.dev" , "stable@kernel.org" Subject: Re: [PATCH 1/2] xen: swiotlb: Use swiotlb bouncing if kmalloc allocation demands it In-Reply-To: <20250502114043.1968976-2-john.ernberg@actia.se> Message-ID: References: <20250502114043.1968976-1-john.ernberg@actia.se> <20250502114043.1968976-2-john.ernberg@actia.se> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 2 May 2025, John Ernberg wrote: > Xen swiotlb support was missed when the patch set starting with > 4ab5f8ec7d71 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from > ARCH_DMA_MINALIGN") was merged. > > When running Xen on iMX8QXP, a SoC without IOMMU, the effect was that USB > transfers ended up corrupted when there was more than one URB inflight at > the same time. > > Add a call to dma_kmalloc_needs_bounce() to make sure that allocations too > small for DMA get bounced via swiotlb. > > Closes: https://lore.kernel.org/linux-usb/ab2776f0-b838-4cf6-a12a-c208eb6aad59@actia.se/ > Fixes: 4ab5f8ec7d71 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN") > Cc: stable@kernel.org # v6.5+ > Signed-off-by: John Ernberg Reviewed-by: Stefano Stabellini > --- > > It's impossible to pick an exact fixes tag since this driver was missed > in the flagged patch set. I picked one I felt gave a decent enough picture > for someone coming across this later. > --- > drivers/xen/swiotlb-xen.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c > index 1f65795cf5d7..ef56a2500ed6 100644 > --- a/drivers/xen/swiotlb-xen.c > +++ b/drivers/xen/swiotlb-xen.c > @@ -217,6 +217,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page, > * buffering it. > */ > if (dma_capable(dev, dev_addr, size, true) && > + !dma_kmalloc_needs_bounce(dev, size, dir) && > !range_straddles_page_boundary(phys, size) && > !xen_arch_need_swiotlb(dev, phys, dev_addr) && > !is_swiotlb_force_bounce(dev)) > -- > 2.49.0 > From xen-devel-bounces@lists.xenproject.org Fri May 02 17:20:33 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 17:20:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974945.1362671 (Exim 4.92) (envelope-from ) id 1uAu3o-000425-Lc; Fri, 02 May 2025 17:20:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974945.1362671; Fri, 02 May 2025 17: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 1uAu3o-00041y-Ir; Fri, 02 May 2025 17:20:28 +0000 Received: by outflank-mailman (input) for mailman id 974945; Fri, 02 May 2025 17:20:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAu3m-00041c-KR for xen-devel@lists.xenproject.org; Fri, 02 May 2025 17:20:26 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bbb9edb0-2779-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 19:20:25 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 31D02434E4; Fri, 2 May 2025 17:20:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16A99C4CEE4; Fri, 2 May 2025 17:20: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" X-Inumbo-ID: bbb9edb0-2779-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746206423; bh=FzvJMEVywUV1H+jpiVirWxvGVxglVU9u9H1JW19xvuE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=B3kmrDRxZRHtH/oLMWmCnAtpbx4Bc+gIdkj+KwlnvFzdXhFHvd2eY5tA47FG/q+V+ q6kWEkJuMFXpTB4MIkzNqQR2m8mHhOJWJSVQgHYXlfkGcD2qzXLm2SzhUHW1u7q6KC bBoxGiuslOqmWxCKnbCN1ib37DliZQhM/FFx7RE4gMmTYsEIvQRNjaN/eiR8UlZq+Y hyDu/Q77OGhDLBscBmyU+IrOW8kRIreKkrVGzcK3x/hr/MyoWL9Sf10+zEqbgXpciD /GrF0ZpdsjWpw/EDHLVd2GWBgG/fJxVO+THrRGvDFSZehODCgfCQ+NLVqAxc/S43de 9lPQ4ZC2wGtnA== Date: Fri, 2 May 2025 10:20:20 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: John Ernberg cc: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Catalin Marinas , Andrew Morton , "xen-devel@lists.xenproject.org" , "iommu@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "imx@lists.linux.dev" , Christoph Hellwig Subject: Re: [PATCH 2/2] xen: swiotlb: Implement map_resource callback In-Reply-To: <20250502114043.1968976-3-john.ernberg@actia.se> Message-ID: References: <20250502114043.1968976-1-john.ernberg@actia.se> <20250502114043.1968976-3-john.ernberg@actia.se> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII +Christoph On Fri, 2 May 2025, John Ernberg wrote: > Needed by the eDMA v3 DMA engine found in iommu-less SoCs such as iMX8QXP > to be able to perform DMA operations as a Xen Hardware Domain, which needs > to be able to do DMA in MMIO space. > > The callback implementation is basically the same as the one for direct > mapping of resources, except this also takes into account Xen page > mappings. > > There is nothing to do for unmap, just like with direct, so the unmap > callback is not needed. > > Signed-off-by: John Ernberg > > --- > > I originally exported dma_direct_map_resource() and used that which > appeared to work, but it felt like not checking Xen page mappings wasn't > fully correct and I went with this. But if dma_direct_map_resource() is > the correct approach here then I can submit that isntead. > --- > drivers/xen/swiotlb-xen.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c > index ef56a2500ed6..0f02fdd9128d 100644 > --- a/drivers/xen/swiotlb-xen.c > +++ b/drivers/xen/swiotlb-xen.c > @@ -285,6 +285,20 @@ static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr, > attrs, pool); > } > > +static dma_addr_t xen_swiotlb_map_resource(struct device *dev, phys_addr_t phys, > + size_t size, enum dma_data_direction dir, > + unsigned long attrs) > +{ > + dma_addr_t dev_addr = xen_phys_to_dma(dev, phys); Yes, we need the xen_phys_to_dma call here. This is one of the reasons I don't think we can use dma_direct_map_resource() to implement map_resource > + BUG_ON(dir == DMA_NONE); > + > + if (!dma_capable(dev, dev_addr, size, false)) > + return DMA_MAPPING_ERROR; But here you also need to check that phys+size doesn't cross a page boundary. You need to call range_straddles_page_boundary, like we do at the beginning of xen_swiotlb_map_page. If it is possible to cross a page boundary, then we need to basically to do the same thing here as we do in xen_swiotlb_map_page where we check for: if (dma_capable(dev, dev_addr, size, true) && !range_straddles_page_boundary(phys, size) && !xen_arch_need_swiotlb(dev, phys, dev_addr) && !is_swiotlb_force_bounce(dev)) goto done; if all is well, we go with the native path, otherwise we bounce on swiotlb-xen. > + return dev_addr; > +} > + > static void > xen_swiotlb_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr, > size_t size, enum dma_data_direction dir) > @@ -426,4 +440,5 @@ const struct dma_map_ops xen_swiotlb_dma_ops = { > .alloc_pages_op = dma_common_alloc_pages, > .free_pages = dma_common_free_pages, > .max_mapping_size = swiotlb_max_mapping_size, > + .map_resource = xen_swiotlb_map_resource, > }; > -- > 2.49.0 > From xen-devel-bounces@lists.xenproject.org Fri May 02 17:51:11 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 17:51:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974957.1362681 (Exim 4.92) (envelope-from ) id 1uAuXG-0000iR-SG; Fri, 02 May 2025 17:50:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974957.1362681; Fri, 02 May 2025 17:50: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 1uAuXG-0000iK-PO; Fri, 02 May 2025 17:50:54 +0000 Received: by outflank-mailman (input) for mailman id 974957; Fri, 02 May 2025 17:50:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAuXG-0000iE-6G for xen-devel@lists.xenproject.org; Fri, 02 May 2025 17:50:54 +0000 Received: from mail.zytor.com (unknown [2607:7c80:54:3::138]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fb94231a-277d-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 19:50:51 +0200 (CEST) Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 542Ho3nX2101973 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 2 May 2025 10:50:03 -0700 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fb94231a-277d-11f0-9eb4-5ba50f476ded DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 542Ho3nX2101973 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025042001; t=1746208207; bh=LzR4L+NzvxhTrQ0qnGzytLxrMo2x9HNW2SUoBs+4hnk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=f2DvQ9MW8Z0JHknIhUmlaIPnE6PHfIIPe0rpr7QJUvAXpKBCT+qAa2LT23C9nwyHn /1a1mWwt981CwHC7LEhukO1K0m1bgC3vouAUx32YzUdMpcsCtQbd/jw/0r9+oZFhHH zWNmyzJlWsf15/gfOAQCHW/PstZJwBaw5PzyA2AIZsvRshoRiosxrgxL3BGNy8GnvI j1N92z82OgALfPhLkgXq737LFNKZtz9B4b6V3qkfZIO+IB2Ra6RgpyueZDDglkuTjG iaLXdZxYtCOMzwCegp0RoTN30GI8VbyzguvhXK2x0MgYmhv6FrtA1j3wSshxLcp5ca a3YLWxbyYWbZw== Message-ID: Date: Fri, 2 May 2025 10:50:02 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4A 01/15] x86/msr: Add missing includes of To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , mingo@redhat.com Cc: LKML , kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-pm@vger.kernel.org, linux-edac@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, Netdev , platform-driver-x86@vger.kernel.org, tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, acme@kernel.org, jgross@suse.com, andrew.cooper3@citrix.com, peterz@infradead.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, wei.liu@kernel.org, ajay.kaher@broadcom.com, bcm-kernel-feedback-list@broadcom.com, tony.luck@intel.com, pbonzini@redhat.com, vkuznets@redhat.com, seanjc@google.com, luto@kernel.org, boris.ostrovsky@oracle.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, dapeng1.mi@linux.intel.com References: <20250501054241.1245648-1-xin@zytor.com> Content-Language: en-US From: Xin Li Autocrypt: addr=xin@zytor.com; keydata= xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+ QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4 l75w1xInsg== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/2/2025 6:13 AM, Ilpo Järvinen wrote: >> diff --git a/arch/x86/kernel/trace_clock.c b/arch/x86/kernel/trace_clock.c >> index b8e7abe00b06..708d61743d15 100644 >> --- a/arch/x86/kernel/trace_clock.c >> +++ b/arch/x86/kernel/trace_clock.c >> @@ -4,7 +4,7 @@ >> */ >> #include >> #include >> -#include >> +#include > Does this change belong to this patch? > > It might even cause a build failure until the second patch which moves > the tsc related things to the other file (unless there's indirect include > path to asm/msr.h). Ah, you're right as I have separated the relocation of rdtsc_ordered() into a following patch. > >> diff --git a/arch/x86/lib/kaslr.c b/arch/x86/lib/kaslr.c >> index a58f451a7dd3..b5893928d55c 100644 >> --- a/arch/x86/lib/kaslr.c >> +++ b/arch/x86/lib/kaslr.c >> @@ -8,7 +8,7 @@ >> */ >> #include >> #include >> -#include >> +#include > Same thing here. > >> #include >> #include >> #include >> diff --git a/drivers/accel/habanalabs/common/habanalabs_ioctl.c b/drivers/accel/habanalabs/common/habanalabs_ioctl.c >> index 8729a0c57d78..dc80ca921d90 100644 >> --- a/drivers/accel/habanalabs/common/habanalabs_ioctl.c >> +++ b/drivers/accel/habanalabs/common/habanalabs_ioctl.c >> @@ -17,8 +17,6 @@ >> #include >> #include >> >> -#include >> - > I suggested making a separate patch out of these removals. Currently you > do them without any clear warning in the changelog which only talks about > adding asm/msr.h. > I didn't want to add an extra patch to the v4 series, but I really should have mentioned the removal at least. >> diff --git a/drivers/acpi/processor_throttling.c b/drivers/acpi/processor_throttling.c >> index 00d045e5f524..ecd7fe256153 100644 >> --- a/drivers/acpi/processor_throttling.c >> +++ b/drivers/acpi/processor_throttling.c >> @@ -18,9 +18,13 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> -#include >> +#include > ??? Damn me! Not to find an excuse but I guess I got somewhat tired when doing it. > >> +#ifdef CONFIG_X86 >> +#include >> +#endif > > I really appreciate you took the effort to do this change the correct > way! 🙂 Same here for pushing it the right direction! Hi Ingo, Since you *wisely* didn't remove msr.h from tsc.h, maybe you could just zap this patch and I will send an afterwards patch set to replace this patch? Apology for the noise. Thanks! Xin From xen-devel-bounces@lists.xenproject.org Fri May 02 17:55:59 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 17:55:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974971.1362690 (Exim 4.92) (envelope-from ) id 1uAucA-0001MG-Cz; Fri, 02 May 2025 17:55:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974971.1362690; Fri, 02 May 2025 17:55:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAucA-0001M9-AI; Fri, 02 May 2025 17:55:58 +0000 Received: by outflank-mailman (input) for mailman id 974971; Fri, 02 May 2025 17:55:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAuc8-0001M3-ME for xen-devel@lists.xenproject.org; Fri, 02 May 2025 17:55:56 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b10f6240-277e-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 19:55:54 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 2A8D56844F; Fri, 2 May 2025 17:55:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13C1CC4CEE4; Fri, 2 May 2025 17:55: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" X-Inumbo-ID: b10f6240-277e-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746208552; bh=5yJ+7ntwOMi2M65yhZ0bCvAfLhcIgG3vIrOsulOAD1g=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XnQdckOJ4jFohpW5PzEj10CkbrIolzjb7FbrZm5NWGdaJ7rCTOwvNdKaQg/gW57no kDWvBihaGUmZnLkYa+KvnfpozHFV2YRdQQkh4a1oeiegN4QOhoJAtzlOODz6cYSJ9c W+gUDYQ0ZVQ/IHLONDvHraJLIyKvQyMOVe/6H2T6EOJkHTFsMZSClU+WCdkLzJgG/Q mZPFEPGvZDXp1jAbVMtIUvxrVBJSu18aUPhHK95WSnMDfzwSKbZrrKrN9ArXDRM+js 9UcjBXayVHq2M4COc2dllQxw8cSOo/bnJzhJP86PXFRCxBYBe6zuZHhqAw5bGCYzdO 0lvhoV3a2AJ0w== Date: Fri, 2 May 2025 10:55:49 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Kurochko cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v3 2/8] xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common In-Reply-To: <82f0c1d4fe25b4a52d76f3c8004e107b183af56c.1746199009.git.oleksii.kurochko@gmail.com> Message-ID: References: <82f0c1d4fe25b4a52d76f3c8004e107b183af56c.1746199009.git.oleksii.kurochko@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 2 May 2025, Oleksii Kurochko wrote: > Move some parts of Arm's Dom0Less code to be reused by other architectures. > At the moment, RISC-V is going to reuse these parts. > > Move dom0less-build.h from the Arm-specific directory to asm-generic > as these header is expected to be the same across acrhictectures with > some updates: add the following declaration of construct_domU(), > and arch_create_domUs() as there are some parts which are still > architecture-specific. > > Introduce HAS_DOM0LESS to provide ability to enable generic Dom0less > code for an architecture. > > Relocate the CONFIG_DOM0LESS configuration to the common with adding > "depends on HAS_DOM0LESS" to not break builds for architectures which > don't support CONFIG_DOM0LESS config, especically it would be useful > to not provide stubs for construct_domU(), arch_create_domUs() > in case of *-randconfig which may set CONFIG_DOM0LESS=y. > > Move is_dom0less_mode() function to the common code, as it depends on > boot modules that are already part of the common code. > > Move create_domUs() function to the common code with some updates: > - Add arch_create_domUs() to cover parsing of arch-specific features, > for example, SVE (Scalar Vector Extension ) exists only in Arm. > > Signed-off-by: Oleksii Kurochko > --- > It was suggested to change dom0less to predefined domus or similar > (https://lore.kernel.org/xen-devel/cd2a3644-c9c6-4e77-9491-2988703906c0@gmail.com/T/#m1d5e81e5f1faca98a3c51efe4f35af25010edbf0): > > I decided to go with dom0less name for now as it will require a lot of places to change, > including CI's test, and IMO we could do in a separate patch. > If it is necessry to do now, I'll be happy to do that in next version of the current > patch series. I think it is fine to use dom0less for now, it will make the code easier to review and it is not necessary to change the name at this point. The patch looks good to me, except for a couple of minor suggestions I have below. I could make them on commit. With those: Reviewed-by: Stefano Stabellini > --- > Changes in v3: > - Move changes connected to the patch "xen/arm: dom0less delay xenstore initialization" > to common. > Also, some necessary parts for the mentioned patches were moved > to common (such as alloc_xenstore_evtchn(), ... ). > Not all changes are moved, changes connected to alloc_xenstore_params() and > construct_domu() will be moved in the following patches of this patch series. > - Move parsing of capabilities property to common code. > - Align parsing of "passthrough", "multiboot,device-tree" properties with staging. > - Drop arch_xen_domctl_createdomain(). > - Add 'select HAS_DEVICE_TREE' for config HAS_DOM0LESS. > - Add empty lines after license in the top of newly added files. > - s/arch_create_domus/arch_create_domUs. > - Add footer below commit message regarding the naming of dom0less. > --- > Changes in v2: > - Convert 'depends on Arm' to 'depends on HAS_DOM0LESS' for > CONFIG_DOM0LESS_BOOT. > - Change 'default Arm' to 'default y' for CONFIG_DOM0LESS_BOOT as there is > dependency on HAS_DOM0LESS. > - Introduce HAS_DOM0LESS and enable it for Arm. > - Update the commit message. > --- > xen/arch/arm/Kconfig | 9 +- > xen/arch/arm/dom0less-build.c | 371 ++++------------------ > xen/arch/arm/include/asm/Makefile | 1 + > xen/arch/arm/include/asm/dom0less-build.h | 34 -- > xen/common/Kconfig | 13 + > xen/common/device-tree/Makefile | 1 + > xen/common/device-tree/dom0less-build.c | 283 +++++++++++++++++ > xen/include/asm-generic/dom0less-build.h | 49 +++ > 8 files changed, 404 insertions(+), 357 deletions(-) > delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h > create mode 100644 xen/common/device-tree/dom0less-build.c > create mode 100644 xen/include/asm-generic/dom0less-build.h > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index da8a406f5a..d0e0a7753c 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -15,6 +15,7 @@ config ARM > select GENERIC_UART_INIT > select HAS_ALTERNATIVE if HAS_VMAP > select HAS_DEVICE_TREE > + select HAS_DOM0LESS > select HAS_STACK_PROTECTOR > select HAS_UBSAN > > @@ -120,14 +121,6 @@ config GICV2 > Driver for the ARM Generic Interrupt Controller v2. > If unsure, say Y > > -config DOM0LESS_BOOT > - bool "Dom0less boot support" if EXPERT > - default y > - help > - Dom0less boot support enables Xen to create and start domU guests during > - Xen boot without the need of a control domain (Dom0), which could be > - present anyway. > - > config GICV3 > bool "GICv3 driver" > depends on !NEW_VGIC > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index a356fc94fc..ef49495d4f 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -22,48 +22,7 @@ > #include > #include > > -#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX > - > -static domid_t __initdata xs_domid = DOMID_INVALID; > -static bool __initdata need_xenstore; > - > -void __init set_xs_domain(struct domain *d) > -{ > - xs_domid = d->domain_id; > - set_global_virq_handler(d, VIRQ_DOM_EXC); > -} > - > -bool __init is_dom0less_mode(void) > -{ > - struct bootmodules *mods = &bootinfo.modules; > - struct bootmodule *mod; > - unsigned int i; > - bool dom0found = false; > - bool domUfound = false; > - > - /* Look into the bootmodules */ > - for ( i = 0 ; i < mods->nr_mods ; i++ ) > - { > - mod = &mods->module[i]; > - /* Find if dom0 and domU kernels are present */ > - if ( mod->kind == BOOTMOD_KERNEL ) > - { > - if ( mod->domU == false ) > - { > - dom0found = true; > - break; > - } > - else > - domUfound = true; > - } > - } > - > - /* > - * If there is no dom0 kernel but at least one domU, then we are in > - * dom0less mode > - */ > - return ( !dom0found && domUfound ); > -} > +bool __initdata need_xenstore; > > #ifdef CONFIG_VGICV2 > static int __init make_gicv2_domU_node(struct kernel_info *kinfo) > @@ -686,25 +645,6 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > return -EINVAL; > } > > -static int __init alloc_xenstore_evtchn(struct domain *d) > -{ > - evtchn_alloc_unbound_t alloc; > - int rc; > - > - alloc.dom = d->domain_id; > - alloc.remote_dom = xs_domid; > - rc = evtchn_alloc_unbound(&alloc, 0); > - if ( rc ) > - { > - printk("Failed allocating event channel for domain\n"); > - return rc; > - } > - > - d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port; > - > - return 0; > -} > - > #define XENSTORE_PFN_OFFSET 1 > static int __init alloc_xenstore_page(struct domain *d) > { > @@ -771,36 +711,6 @@ static int __init alloc_xenstore_params(struct kernel_info *kinfo) > return rc; > } > > -static void __init initialize_domU_xenstore(void) > -{ > - struct domain *d; > - > - if ( xs_domid == DOMID_INVALID ) > - return; > - > - for_each_domain( d ) > - { > - uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN]; > - int rc; > - > - if ( gfn == 0 ) > - continue; > - > - if ( is_xenstore_domain(d) ) > - continue; > - > - rc = alloc_xenstore_evtchn(d); > - if ( rc < 0 ) > - panic("%pd: Failed to allocate xenstore_evtchn\n", d); > - > - if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) ) > - { > - ASSERT(gfn < UINT32_MAX); > - gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn); > - } > - } > -} > - > static void __init domain_vcpu_affinity(struct domain *d, > const struct dt_device_node *node) > { > @@ -906,8 +816,8 @@ static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem, > } > #endif /* CONFIG_ARCH_PAGING_MEMPOOL */ > > -static int __init construct_domU(struct domain *d, > - const struct dt_device_node *node) > +int __init construct_domU(struct domain *d, > + const struct dt_device_node *node) > { > struct kernel_info kinfo = KERNEL_INFO_INIT; > const char *dom0less_enhanced; > @@ -1009,246 +919,77 @@ static int __init construct_domU(struct domain *d, > return alloc_xenstore_params(&kinfo); > } > > -void __init create_domUs(void) > +void __init arch_create_domUs(struct dt_device_node *node, > + struct xen_domctl_createdomain *d_cfg, > + unsigned int flags) > { > - struct dt_device_node *node; > - const char *dom0less_iommu; > - bool iommu = false; > - const struct dt_device_node *cpupool_node, > - *chosen = dt_find_node_by_path("/chosen"); > - const char *llc_colors_str = NULL; > - > - BUG_ON(chosen == NULL); > - dt_for_each_child_node(chosen, node) > - { > - struct domain *d; > - struct xen_domctl_createdomain d_cfg = { > - .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE, > - .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap, > - /* > - * The default of 1023 should be sufficient for guests because > - * on ARM we don't bind physical interrupts to event channels. > - * The only use of the evtchn port is inter-domain communications. > - * 1023 is also the default value used in libxl. > - */ > - .max_evtchn_port = 1023, > - .max_grant_frames = -1, > - .max_maptrack_frames = -1, > - .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version), > - }; > - unsigned int flags = 0U; > - bool has_dtb = false; > - uint32_t val; > - int rc; > - > - if ( !dt_device_is_compatible(node, "xen,domain") ) > - continue; > - > - if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED ) > - panic("No more domain IDs available\n"); > + uint32_t val; > > - if ( dt_property_read_u32(node, "capabilities", &val) ) > - { > - if ( val & ~DOMAIN_CAPS_MASK ) > - panic("Invalid capabilities (%"PRIx32")\n", val); > - > - if ( val & DOMAIN_CAPS_CONTROL ) > - flags |= CDF_privileged; > - > - if ( val & DOMAIN_CAPS_HARDWARE ) > - { > - if ( hardware_domain ) > - panic("Only 1 hardware domain can be specified! (%pd)\n", > - hardware_domain); > - > - d_cfg.max_grant_frames = gnttab_dom0_frames(); > - d_cfg.max_evtchn_port = -1; > - flags |= CDF_hardware; > - iommu = true; > - } > - > - if ( val & DOMAIN_CAPS_XENSTORE ) > - { > - if ( xs_domid != DOMID_INVALID ) > - panic("Only 1 xenstore domain can be specified! (%u)\n", > - xs_domid); > + d_cfg->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; > + d_cfg->flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap; > > - d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain; > - d_cfg.max_evtchn_port = -1; > - } > - } > - > - if ( dt_find_property(node, "xen,static-mem", NULL) ) > - { > - if ( llc_coloring_enabled ) > - panic("LLC coloring and static memory are incompatible\n"); > - > - flags |= CDF_staticmem; > - } > - > - if ( dt_property_read_bool(node, "direct-map") ) > - { > - if ( !(flags & CDF_staticmem) ) > - panic("direct-map is not valid for domain %s without static allocation.\n", > - dt_node_name(node)); > - > - flags |= CDF_directmap; > - } > - > - if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) ) > - panic("Missing property 'cpus' for domain %s\n", > - dt_node_name(node)); > - > - if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) ) > - { > - if ( flags & CDF_hardware ) > - panic("Don't specify passthrough for hardware domain\n"); > - > - if ( !strcmp(dom0less_iommu, "enabled") ) > - iommu = true; > - } > - > - if ( (flags & CDF_hardware) && !(flags & CDF_directmap) && > - !iommu_enabled ) > - panic("non-direct mapped hardware domain requires iommu\n"); > - > - if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") ) > - { > - if ( flags & CDF_hardware ) > - panic("\"multiboot,device-tree\" incompatible with hardware domain\n"); > - > - has_dtb = true; > - } > - > - if ( iommu_enabled && (iommu || has_dtb) ) > - d_cfg.flags |= XEN_DOMCTL_CDF_iommu; > - > - if ( !dt_property_read_u32(node, "nr_spis", &d_cfg.arch.nr_spis) ) > - { > - int vpl011_virq = GUEST_VPL011_SPI; > - > - d_cfg.arch.nr_spis = VGIC_DEF_NR_SPIS; > - > - /* > - * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is > - * set, in which case it'll match the hardware. > - * > - * Since the domain is not yet created, we can't use > - * d->arch.vpl011.irq. So the logic to find the vIRQ has to > - * be hardcoded. > - * The logic here shall be consistent with the one in > - * domain_vpl011_init(). > - */ > - if ( flags & CDF_directmap ) > - { > - vpl011_virq = serial_irq(SERHND_DTUART); > - if ( vpl011_virq < 0 ) > - panic("Error getting IRQ number for this serial port %d\n", > - SERHND_DTUART); > - } > + if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) ) > + { > + int vpl011_virq = GUEST_VPL011_SPI; > > - /* > - * vpl011 uses one emulated SPI. If vpl011 is requested, make > - * sure that we allocate enough SPIs for it. > - */ > - if ( dt_property_read_bool(node, "vpl011") ) > - d_cfg.arch.nr_spis = MAX(d_cfg.arch.nr_spis, > - vpl011_virq - 32 + 1); > - } > - else if ( flags & CDF_hardware ) > - panic("nr_spis cannot be specified for hardware domain\n"); > + d_cfg->arch.nr_spis = VGIC_DEF_NR_SPIS; > > - /* Get the optional property domain-cpupool */ > - cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0); > - if ( cpupool_node ) > + /* > + * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is > + * set, in which case it'll match the hardware. > + * > + * Since the domain is not yet created, we can't use > + * d->arch.vpl011.irq. So the logic to find the vIRQ has to > + * be hardcoded. > + * The logic here shall be consistent with the one in > + * domain_vpl011_init(). > + */ > + if ( flags & CDF_directmap ) > { > - int pool_id = btcpupools_get_domain_pool_id(cpupool_node); > - if ( pool_id < 0 ) > - panic("Error getting cpupool id from domain-cpupool (%d)\n", > - pool_id); > - d_cfg.cpupool_id = pool_id; > + vpl011_virq = serial_irq(SERHND_DTUART); > + if ( vpl011_virq < 0 ) > + panic("Error getting IRQ number for this serial port %d\n", > + SERHND_DTUART); > } > > - if ( dt_property_read_u32(node, "max_grant_version", &val) ) > - d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val); > + /* > + * vpl011 uses one emulated SPI. If vpl011 is requested, make > + * sure that we allocate enough SPIs for it. > + */ > + if ( dt_property_read_bool(node, "vpl011") ) > + d_cfg->arch.nr_spis = MAX(d_cfg->arch.nr_spis, > + vpl011_virq - 32 + 1); > + } > + else if ( flags & CDF_hardware ) > + panic("nr_spis cannot be specified for hardware domain\n"); > > - if ( dt_property_read_u32(node, "max_grant_frames", &val) ) > - { > - if ( val > INT32_MAX ) > - panic("max_grant_frames (%"PRIu32") overflow\n", val); > - d_cfg.max_grant_frames = val; > - } > + if ( dt_get_property(node, "sve", &val) ) > + { > +#ifdef CONFIG_ARM64_SVE > + unsigned int sve_vl_bits; > + bool ret = false; > > - if ( dt_property_read_u32(node, "max_maptrack_frames", &val) ) > + if ( !val ) > { > - if ( val > INT32_MAX ) > - panic("max_maptrack_frames (%"PRIu32") overflow\n", val); > - d_cfg.max_maptrack_frames = val; > + /* Property found with no value, means max HW VL supported */ > + ret = sve_domctl_vl_param(-1, &sve_vl_bits); > } > - > - if ( dt_get_property(node, "sve", &val) ) > + else > { > -#ifdef CONFIG_ARM64_SVE > - unsigned int sve_vl_bits; > - bool ret = false; > - > - if ( !val ) > - { > - /* Property found with no value, means max HW VL supported */ > - ret = sve_domctl_vl_param(-1, &sve_vl_bits); > - } > + if ( dt_property_read_u32(node, "sve", &val) ) > + ret = sve_domctl_vl_param(val, &sve_vl_bits); > else > - { > - if ( dt_property_read_u32(node, "sve", &val) ) > - ret = sve_domctl_vl_param(val, &sve_vl_bits); > - else > - panic("Error reading 'sve' property\n"); > - } > + panic("Error reading 'sve' property\n"); > + } > > - if ( ret ) > - d_cfg.arch.sve_vl = sve_encode_vl(sve_vl_bits); > - else > - panic("SVE vector length error\n"); > + if ( ret ) > + d_cfg->arch.sve_vl = sve_encode_vl(sve_vl_bits); > + else > + panic("SVE vector length error\n"); > #else > - panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n"); > + panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n"); > #endif > - } > - > - dt_property_read_string(node, "llc-colors", &llc_colors_str); > - if ( !llc_coloring_enabled && llc_colors_str ) > - panic("'llc-colors' found, but LLC coloring is disabled\n"); > - > - /* > - * The variable max_init_domid is initialized with zero, so here it's > - * very important to use the pre-increment operator to call > - * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0) > - */ > - d = domain_create(++max_init_domid, &d_cfg, flags); > - if ( IS_ERR(d) ) > - panic("Error creating domain %s (rc = %ld)\n", > - dt_node_name(node), PTR_ERR(d)); > - > - if ( llc_coloring_enabled && > - (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) ) > - panic("Error initializing LLC coloring for domain %s (rc = %d)\n", > - dt_node_name(node), rc); > - > - d->is_console = true; > - dt_device_set_used_by(node, d->domain_id); > - > - rc = construct_domU(d, node); > - if ( rc ) > - panic("Could not set up domain %s (rc = %d)\n", > - dt_node_name(node), rc); > - > - if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain ) > - set_xs_domain(d); > } > - > - if ( need_xenstore && xs_domid == DOMID_INVALID ) > - panic("xenstore requested, but xenstore domain not present\n"); > - > - initialize_domU_xenstore(); > } > > /* > diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile > index 4a4036c951..831c914cce 100644 > --- a/xen/arch/arm/include/asm/Makefile > +++ b/xen/arch/arm/include/asm/Makefile > @@ -1,6 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0-only > generic-y += altp2m.h > generic-y += device.h > +generic-y += dom0less-build.h > generic-y += hardirq.h > generic-y += iocap.h > generic-y += paging.h > diff --git a/xen/arch/arm/include/asm/dom0less-build.h b/xen/arch/arm/include/asm/dom0less-build.h > deleted file mode 100644 > index b0e41a1954..0000000000 > --- a/xen/arch/arm/include/asm/dom0less-build.h > +++ /dev/null > @@ -1,34 +0,0 @@ > -/* SPDX-License-Identifier: GPL-2.0-only */ > - > -#ifndef __ASM_DOM0LESS_BUILD_H_ > -#define __ASM_DOM0LESS_BUILD_H_ > - > -#include > - > -#ifdef CONFIG_DOM0LESS_BOOT > - > -void create_domUs(void); > -bool is_dom0less_mode(void); > -void set_xs_domain(struct domain *d); > - > -#else /* !CONFIG_DOM0LESS_BOOT */ > - > -static inline void create_domUs(void) {} > -static inline bool is_dom0less_mode(void) > -{ > - return false; > -} > -static inline void set_xs_domain(struct domain *d) {} > - > -#endif /* CONFIG_DOM0LESS_BOOT */ > - > -#endif /* __ASM_DOM0LESS_BUILD_H_ */ > - > -/* > - * Local variables: > - * mode: C > - * c-file-style: "BSD" > - * c-basic-offset: 4 > - * indent-tabs-mode: nil > - * End: > - */ > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index be28060716..be38abf9e1 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -12,6 +12,15 @@ config CORE_PARKING > bool > depends on NR_CPUS > 1 > > +config DOM0LESS_BOOT > + bool "Dom0less boot support" if EXPERT > + depends on HAS_DOM0LESS I think it is better to also add here: depends on HAS_DEVICE_TREE and ... > + default y > + help > + Dom0less boot support enables Xen to create and start domU guests during > + Xen boot without the need of a control domain (Dom0), which could be > + present anyway. > + > config GRANT_TABLE > bool "Grant table support" if EXPERT > default y > @@ -74,6 +83,10 @@ config HAS_DEVICE_TREE > bool > select LIBFDT > > +config HAS_DOM0LESS > + bool > + select HAS_DEVICE_TREE ... remove select HAS_DEVICE_TREE from here. To reduce the dependencies complexity. > config HAS_DIT # Data Independent Timing > bool > > diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile > index 7c549be38a..f3dafc9b81 100644 > --- a/xen/common/device-tree/Makefile > +++ b/xen/common/device-tree/Makefile > @@ -1,5 +1,6 @@ > obj-y += bootfdt.init.o > obj-y += bootinfo.init.o > obj-y += device-tree.o > +obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o > obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o > obj-y += intc.o > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c > new file mode 100644 > index 0000000000..a01a8b6b1a > --- /dev/null > +++ b/xen/common/device-tree/dom0less-build.c > @@ -0,0 +1,283 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#include > +#include > + > +static domid_t __initdata xs_domid = DOMID_INVALID; > + > +void __init set_xs_domain(struct domain *d) > +{ > + xs_domid = d->domain_id; > + set_global_virq_handler(d, VIRQ_DOM_EXC); > +} > + > +bool __init is_dom0less_mode(void) > +{ > + struct bootmodules *mods = &bootinfo.modules; > + struct bootmodule *mod; > + unsigned int i; > + bool dom0found = false; > + bool domUfound = false; > + > + /* Look into the bootmodules */ > + for ( i = 0 ; i < mods->nr_mods ; i++ ) > + { > + mod = &mods->module[i]; > + /* Find if dom0 and domU kernels are present */ > + if ( mod->kind == BOOTMOD_KERNEL ) > + { > + if ( mod->domU == false ) > + { > + dom0found = true; > + break; > + } > + else > + domUfound = true; > + } > + } > + > + /* > + * If there is no dom0 kernel but at least one domU, then we are in > + * dom0less mode > + */ > + return ( !dom0found && domUfound ); > +} > + > +static int __init alloc_xenstore_evtchn(struct domain *d) > +{ > + evtchn_alloc_unbound_t alloc; > + int rc; > + > + alloc.dom = d->domain_id; > + alloc.remote_dom = xs_domid; > + rc = evtchn_alloc_unbound(&alloc, 0); > + if ( rc ) > + { > + printk("Failed allocating event channel for domain\n"); > + return rc; > + } > + > + d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port; > + > + return 0; > +} > + > +static void __init initialize_domU_xenstore(void) > +{ > + struct domain *d; > + > + if ( xs_domid == DOMID_INVALID ) > + return; > + > + for_each_domain( d ) > + { > + uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN]; > + int rc; > + > + if ( gfn == 0 ) > + continue; > + > + if ( is_xenstore_domain(d) ) > + continue; > + > + rc = alloc_xenstore_evtchn(d); > + if ( rc < 0 ) > + panic("%pd: Failed to allocate xenstore_evtchn\n", d); > + > + if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) ) > + { > + ASSERT(gfn < UINT32_MAX); > + gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn); > + } > + } > +} > + > +void __init create_domUs(void) > +{ > + struct dt_device_node *node; > + const char *dom0less_iommu; > + bool iommu = false; > + const struct dt_device_node *cpupool_node, > + *chosen = dt_find_node_by_path("/chosen"); > + const char *llc_colors_str = NULL; > + > + BUG_ON(chosen == NULL); > + dt_for_each_child_node(chosen, node) > + { > + struct domain *d; > + struct xen_domctl_createdomain d_cfg = {0}; > + unsigned int flags = 0U; > + bool has_dtb = false; > + uint32_t val; > + int rc; > + > + if ( !dt_device_is_compatible(node, "xen,domain") ) > + continue; > + > + if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED ) > + panic("No more domain IDs available\n"); > + > + d_cfg.max_evtchn_port = 1023; > + d_cfg.max_grant_frames = -1; > + d_cfg.max_maptrack_frames = -1; > + d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version); > + > + if ( dt_property_read_u32(node, "capabilities", &val) ) > + { > + if ( val & ~DOMAIN_CAPS_MASK ) > + panic("Invalid capabilities (%"PRIx32")\n", val); > + > + if ( val & DOMAIN_CAPS_CONTROL ) > + flags |= CDF_privileged; > + > + if ( val & DOMAIN_CAPS_HARDWARE ) > + { > + if ( hardware_domain ) > + panic("Only 1 hardware domain can be specified! (%pd)\n", > + hardware_domain); > + > + d_cfg.max_grant_frames = gnttab_dom0_frames(); > + d_cfg.max_evtchn_port = -1; > + flags |= CDF_hardware; > + iommu = true; > + } > + > + if ( val & DOMAIN_CAPS_XENSTORE ) > + { > + if ( xs_domid != DOMID_INVALID ) > + panic("Only 1 xenstore domain can be specified! (%u)\n", > + xs_domid); > + > + d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain; > + d_cfg.max_evtchn_port = -1; > + } > + } > + > + if ( dt_find_property(node, "xen,static-mem", NULL) ) > + { > + if ( llc_coloring_enabled ) > + panic("LLC coloring and static memory are incompatible\n"); > + > + flags |= CDF_staticmem; > + } > + > + if ( dt_property_read_bool(node, "direct-map") ) > + { > + if ( !(flags & CDF_staticmem) ) > + panic("direct-map is not valid for domain %s without static allocation.\n", > + dt_node_name(node)); > + > + flags |= CDF_directmap; > + } > + > + if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) ) > + panic("Missing property 'cpus' for domain %s\n", > + dt_node_name(node)); > + > + if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) ) > + { > + if ( flags & CDF_hardware ) > + panic("Don't specify passthrough for hardware domain\n"); > + > + if ( !strcmp(dom0less_iommu, "enabled") ) > + iommu = true; > + } > + > + if ( (flags & CDF_hardware) && !(flags & CDF_directmap) && > + !iommu_enabled ) > + panic("non-direct mapped hardware domain requires iommu\n"); > + > + if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") ) > + { > + if ( flags & CDF_hardware ) > + panic("\"multiboot,device-tree\" incompatible with hardware domain\n"); > + > + has_dtb = true; > + } > + > + if ( iommu_enabled && (iommu || has_dtb) ) > + d_cfg.flags |= XEN_DOMCTL_CDF_iommu; > + > + /* Get the optional property domain-cpupool */ > + cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0); > + if ( cpupool_node ) > + { > + int pool_id = btcpupools_get_domain_pool_id(cpupool_node); > + if ( pool_id < 0 ) > + panic("Error getting cpupool id from domain-cpupool (%d)\n", > + pool_id); > + d_cfg.cpupool_id = pool_id; > + } > + > + if ( dt_property_read_u32(node, "max_grant_version", &val) ) > + d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val); > + > + if ( dt_property_read_u32(node, "max_grant_frames", &val) ) > + { > + if ( val > INT32_MAX ) > + panic("max_grant_frames (%"PRIu32") overflow\n", val); > + d_cfg.max_grant_frames = val; > + } > + > + if ( dt_property_read_u32(node, "max_maptrack_frames", &val) ) > + { > + if ( val > INT32_MAX ) > + panic("max_maptrack_frames (%"PRIu32") overflow\n", val); > + d_cfg.max_maptrack_frames = val; > + } > + > + dt_property_read_string(node, "llc-colors", &llc_colors_str); > + if ( !llc_coloring_enabled && llc_colors_str ) > + panic("'llc-colors' found, but LLC coloring is disabled\n"); > + > + arch_create_domUs(node, &d_cfg, flags); > + > + /* > + * The variable max_init_domid is initialized with zero, so here it's > + * very important to use the pre-increment operator to call > + * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0) > + */ > + d = domain_create(++max_init_domid, &d_cfg, flags); > + if ( IS_ERR(d) ) > + panic("Error creating domain %s (rc = %ld)\n", > + dt_node_name(node), PTR_ERR(d)); > + > + if ( llc_coloring_enabled && > + (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) ) > + panic("Error initializing LLC coloring for domain %s (rc = %d)\n", > + dt_node_name(node), rc); > + > + d->is_console = true; > + dt_device_set_used_by(node, d->domain_id); > + > + rc = construct_domU(d, node); > + if ( rc ) > + panic("Could not set up domain %s (rc = %d)\n", > + dt_node_name(node), rc); > + > + if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain ) > + set_xs_domain(d); > + } > + > + if ( need_xenstore && xs_domid == DOMID_INVALID ) > + panic("xenstore requested, but xenstore domain not present\n"); > + > + initialize_domU_xenstore(); > +} > diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h > new file mode 100644 > index 0000000000..5655571a66 > --- /dev/null > +++ b/xen/include/asm-generic/dom0less-build.h > @@ -0,0 +1,49 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#ifndef __ASM_GENERIC_DOM0LESS_BUILD_H__ > +#define __ASM_GENERIC_DOM0LESS_BUILD_H__ > + > +#include > + > +#ifdef CONFIG_DOM0LESS_BOOT > + > +#include > + > +struct domain; This declaration needs to be out of the #ifdef CONFIG_DOM0LESS_BOOT because... > +struct dt_device_node; > + > +/* TODO: remove both when construct_domU() will be moved to common. */ > +#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX > +extern bool need_xenstore; > + > +void create_domUs(void); > +bool is_dom0less_mode(void); > +void set_xs_domain(struct domain *d); > + > +int construct_domU(struct domain *d, const struct dt_device_node *node); > + > +void arch_create_domUs(struct dt_device_node *node, > + struct xen_domctl_createdomain *d_cfg, > + unsigned int flags); > + > +#else /* !CONFIG_DOM0LESS_BOOT */ > + > +static inline void create_domUs(void) {} > +static inline bool is_dom0less_mode(void) > +{ > + return false; > +} > +static inline void set_xs_domain(struct domain *d) {} ... of this usage of struct domain *d. > +#endif /* CONFIG_DOM0LESS_BOOT */ > + > +#endif /* __ASM_GENERIC_DOM0LESS_BUILD_H__ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > -- > 2.49.0 > From xen-devel-bounces@lists.xenproject.org Fri May 02 18:01:36 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 18:01:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974987.1362700 (Exim 4.92) (envelope-from ) id 1uAuhX-0003P7-3a; Fri, 02 May 2025 18:01:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974987.1362700; Fri, 02 May 2025 18: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 1uAuhX-0003P0-0o; Fri, 02 May 2025 18:01:31 +0000 Received: by outflank-mailman (input) for mailman id 974987; Fri, 02 May 2025 18:01:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAuhV-0003NZ-UL for xen-devel@lists.xenproject.org; Fri, 02 May 2025 18:01:29 +0000 Received: from mail.zytor.com (unknown [2607:7c80:54:3::138]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 779fda5f-277f-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 20:01:28 +0200 (CEST) Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 542I0lLB2105252 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 2 May 2025 11:00:48 -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" X-Inumbo-ID: 779fda5f-277f-11f0-9eb4-5ba50f476ded DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 542I0lLB2105252 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025042001; t=1746208851; bh=hT0wLy4M/v5r4X1GaFGl658jjbwFpHKBOET/YkmHGHo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=CAJaBviDhg9dcDsmvqA7VZfyDyiseEFTi17BVGAsmrhSXWlwiI3sYKkn5aE2mwhbP bgZAZCKk7pLOdVIAGKVBRNa+jDTPSLoC/S4MqW+rGSD/V4WtV8+NS0S15CsAopcW/D 17kzdds9fMZzZC5qWrbmIdApNBkD8vV6qwWs5V7taNjREQAvzbGbXtMwRqqeGWDmv1 xWQCz/zWDImzXOdooMewYA4YdpZtEtQmtoEmaUnapfwXICzNPcQLl4pKTBi4Mr75n/ VvCXK2e99oq/VMAeMrTNHzml4+e9V0yqLoSG6KEbpqN8YhN5gnNNj/Afn1DJ5XrLTD OXrUGFJVQ0RAQ== Message-ID: <4b896294-66a3-4f4b-84f2-ec67dbaa9a6e@zytor.com> Date: Fri, 2 May 2025 11:00:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 02/15] x86/msr: Move rdtsc{,_ordered}() to To: Ingo Molnar Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-pm@vger.kernel.org, linux-edac@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, netdev@vger.kernel.org, platform-driver-x86@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, acme@kernel.org, jgross@suse.com, andrew.cooper3@citrix.com, peterz@infradead.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, wei.liu@kernel.org, ajay.kaher@broadcom.com, bcm-kernel-feedback-list@broadcom.com, tony.luck@intel.com, pbonzini@redhat.com, vkuznets@redhat.com, seanjc@google.com, luto@kernel.org, boris.ostrovsky@oracle.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, dapeng1.mi@linux.intel.com, ilpo.jarvinen@linux.intel.com References: <20250427092027.1598740-1-xin@zytor.com> <20250427092027.1598740-3-xin@zytor.com> Content-Language: en-US From: Xin Li Autocrypt: addr=xin@zytor.com; keydata= xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+ QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4 l75w1xInsg== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/2/2025 1:52 AM, Ingo Molnar wrote: > > * Xin Li (Intel) wrote: > >> For some reason, there are some TSC-related functions in the MSR >> header even though there is a tsc.h header. >> >> Relocate rdtsc{,_ordered}() from to , and >> subsequently remove the inclusion of in . >> >> Signed-off-by: Xin Li (Intel) >> Acked-by: Dave Hansen >> Acked-by: Peter Zijlstra (Intel) > >> --- a/arch/x86/include/asm/tsc.h >> +++ b/arch/x86/include/asm/tsc.h >> @@ -7,7 +7,81 @@ >> >> #include >> #include >> -#include > > Note that in the tip:x86/msr commit I've applied today I've > intentionally delayed the removal of this header dependency, to reduce > the probability of breaking -next today or in the near future. > > We can remove that now superfluous header dependency in a future patch. > This is truly a brilliant decision! Especially regarding the issues Ilpo identified. Thanks! Xin From xen-devel-bounces@lists.xenproject.org Fri May 02 18:02:29 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 18:02:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.974997.1362711 (Exim 4.92) (envelope-from ) id 1uAuiT-0003vb-CV; Fri, 02 May 2025 18:02:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 974997.1362711; Fri, 02 May 2025 18: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 1uAuiT-0003vU-9m; Fri, 02 May 2025 18:02:29 +0000 Received: by outflank-mailman (input) for mailman id 974997; Fri, 02 May 2025 18:02:27 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAuiR-0003fw-FG for xen-devel@lists.xenproject.org; Fri, 02 May 2025 18:02:27 +0000 Received: from mail.zytor.com (unknown [2607:7c80:54:3::138]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 97b1b693-277f-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 20:02:22 +0200 (CEST) Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 542I1mpa2105495 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 2 May 2025 11:01:48 -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" X-Inumbo-ID: 97b1b693-277f-11f0-9ffb-bf95429c2676 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 542I1mpa2105495 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025042001; t=1746208911; bh=YB94RPwo0LiI+lMqmkXijW8cqAbUGVDkYACiu4rhJOk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VOCJ0eCCKEI1R2ioFr5ehcvkLYBzIHaFZ7pM8wyOLShTf+o7l9PFmGhWDbsdpLxQW rcoCbdc89fjuUFgfp7bB1gHXoCLu9YHYUOC9OAcpCU56iXWZ2OKCrPGpjrEMLxkE2d n/S+MTkFrGLR3Rf9GG0B/ASRUKucjVEKTIdvAyOPgijN7QnsACq5Y2axwtq96cdTCl 5+6d46fXskfc2RwEpwu2heXdygLklUe6dzhmSFhZ15wH2HmKiCsM+42OPweeJlvkgL waa4XMFGYhcr5mQd3ciW2VlgRbYtUdo8/6h8/XYwibFp0MRNe2QxHohkamu9kpC1+h ynCS6u6OzyyAw== Message-ID: <3a88480e-c705-4914-ac18-9764b799a36c@zytor.com> Date: Fri, 2 May 2025 11:01:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 02/15] x86/msr: Move rdtsc{,_ordered}() to To: Ingo Molnar Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-pm@vger.kernel.org, linux-edac@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, netdev@vger.kernel.org, platform-driver-x86@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, acme@kernel.org, jgross@suse.com, andrew.cooper3@citrix.com, peterz@infradead.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, wei.liu@kernel.org, ajay.kaher@broadcom.com, bcm-kernel-feedback-list@broadcom.com, tony.luck@intel.com, pbonzini@redhat.com, vkuznets@redhat.com, seanjc@google.com, luto@kernel.org, boris.ostrovsky@oracle.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, dapeng1.mi@linux.intel.com, ilpo.jarvinen@linux.intel.com References: <20250427092027.1598740-1-xin@zytor.com> <20250427092027.1598740-3-xin@zytor.com> Content-Language: en-US From: Xin Li Autocrypt: addr=xin@zytor.com; keydata= xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+ QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4 l75w1xInsg== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/2/2025 1:18 AM, Ingo Molnar wrote: > > * Xin Li (Intel) wrote: > >> For some reason, there are some TSC-related functions in the MSR > ^^^^^^^^^^^^^^^ >> header even though there is a tsc.h header. > > The real reason is that the rdtsc{,_ordered}() methods use the > EAX_EDX_*() macros to optimize their EDX/EAX assembly accessors, which > is why these methods were in . > > Your followup patch tacitly acknowledges this by silently creating > duplicate copies of these facilities in both headers ... > > I've cleaned it all up in tip:x86/msr via these preparatory patches: > > x86/msr: Improve the comments of the DECLARE_ARGS()/EAX_EDX_VAL()/EAX_EDX_RET() facility > x86/msr: Rename DECLARE_ARGS() to EAX_EDX_DECLARE_ARGS > x86/msr: Move the EAX_EDX_*() methods from to > Brilliant! From xen-devel-bounces@lists.xenproject.org Fri May 02 18:10:18 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 18:10:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975009.1362721 (Exim 4.92) (envelope-from ) id 1uAupx-0005Tz-37; Fri, 02 May 2025 18:10:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975009.1362721; Fri, 02 May 2025 18:10: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 1uAupx-0005Ts-0A; Fri, 02 May 2025 18:10:13 +0000 Received: by outflank-mailman (input) for mailman id 975009; Fri, 02 May 2025 18:10:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAupv-0005Tk-Lv for xen-devel@lists.xenproject.org; Fri, 02 May 2025 18:10:11 +0000 Received: from mail.zytor.com (unknown [2607:7c80:54:3::138]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ae7b07fa-2780-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 20:10:09 +0200 (CEST) Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 542I9URm2109765 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 2 May 2025 11:09:30 -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" X-Inumbo-ID: ae7b07fa-2780-11f0-9ffb-bf95429c2676 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 542I9URm2109765 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025042001; t=1746209374; bh=vq/A29GwC24q+yBRNQofOThRodhc2pHOhalxWP8yF44=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Ik1PM2pUOLDwsjM0pqh49zNwLFsJWsVvCOj193iIxEYzWbmWmPkLOpNjbPdzrjX3v 011IuXpNubhbptoPBokYY/dElyxPQHBCRBjU3Lulkb2yxO4epZ6XSk5+/VuLkmyTKm 0Ud2Zan/4XorBw9nLxr1az3pZ8UdL1JipoDA4C6q89BQQ1lor7RIvGuJ3g6OnfiFiz CnEXvlTclGzLsYNkl8D2WwBsbJipZUTOsHbneDfOJuaejckEKDSBWeybOIBPjijOO0 KGDNLUtdX+eqbIB7ygYhUbhkhUiAb06+5ytRj+5jyUF4CBn/8fUyg6Mi66qsYtwZ4H VoszEMjA20uGw== Message-ID: <2cbb468c-188e-4e6b-9b17-b60a66208c7a@zytor.com> Date: Fri, 2 May 2025 11:09:29 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 02/15] x86/msr: Move rdtsc{,_ordered}() to To: Ingo Molnar Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-pm@vger.kernel.org, linux-edac@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, netdev@vger.kernel.org, platform-driver-x86@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, acme@kernel.org, jgross@suse.com, andrew.cooper3@citrix.com, peterz@infradead.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, wei.liu@kernel.org, ajay.kaher@broadcom.com, bcm-kernel-feedback-list@broadcom.com, tony.luck@intel.com, pbonzini@redhat.com, vkuznets@redhat.com, seanjc@google.com, luto@kernel.org, boris.ostrovsky@oracle.com, kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com, dapeng1.mi@linux.intel.com, ilpo.jarvinen@linux.intel.com References: <20250427092027.1598740-1-xin@zytor.com> <20250427092027.1598740-3-xin@zytor.com> Content-Language: en-US From: Xin Li Autocrypt: addr=xin@zytor.com; keydata= xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+ QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4 l75w1xInsg== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/2/2025 1:02 AM, Ingo Molnar wrote: > > * Xin Li (Intel) wrote: > >> index 94408a784c8e..13335a130edf 100644 >> --- a/arch/x86/include/asm/tsc.h >> +++ b/arch/x86/include/asm/tsc.h >> @@ -7,7 +7,81 @@ >> >> #include >> #include >> -#include >> + >> +/* >> + * both i386 and x86_64 returns 64-bit value in edx:eax, but gcc's "A" >> + * constraint has different meanings. For i386, "A" means exactly >> + * edx:eax, while for x86_64 it doesn't mean rdx:rax or edx:eax. Instead, >> + * it means rax *or* rdx. >> + */ >> +#ifdef CONFIG_X86_64 >> +/* Using 64-bit values saves one instruction clearing the high half of low */ >> +#define DECLARE_ARGS(val, low, high) unsigned long low, high >> +#define EAX_EDX_VAL(val, low, high) ((low) | (high) << 32) >> +#define EAX_EDX_RET(val, low, high) "=a" (low), "=d" (high) >> +#else >> +#define DECLARE_ARGS(val, low, high) u64 val >> +#define EAX_EDX_VAL(val, low, high) (val) >> +#define EAX_EDX_RET(val, low, high) "=A" (val) >> +#endif > > Meh, this patch creates a duplicate copy of DECLARE_ARGS() et al in > now: > > arch/x86/include/asm/msr.h:#define DECLARE_ARGS(val, low, high) unsigned long low, high > arch/x86/include/asm/msr.h:#define DECLARE_ARGS(val, low, high) u64 val > arch/x86/include/asm/msr.h: DECLARE_ARGS(val, low, high); > arch/x86/include/asm/msr.h: DECLARE_ARGS(val, low, high); > arch/x86/include/asm/msr.h: DECLARE_ARGS(val, low, high); > arch/x86/include/asm/tsc.h:#define DECLARE_ARGS(val, low, high) unsigned long low, high > arch/x86/include/asm/tsc.h:#define DECLARE_ARGS(val, low, high) u64 val > arch/x86/include/asm/tsc.h: DECLARE_ARGS(val, low, high); > arch/x86/include/asm/tsc.h: DECLARE_ARGS(val, low, high); > arch/x86/include/asm/tsc.h:#undef DECLARE_ARGS > > Which was both an undeclared change, bloats the code, causes various > problems, and is totally unnecessary to boot. > > Please don't do that ... Learned! Especially that every change needs to explicitly called out. From xen-devel-bounces@lists.xenproject.org Fri May 02 18:13:38 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 18:13:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975022.1362730 (Exim 4.92) (envelope-from ) id 1uAutC-0006ZV-E6; Fri, 02 May 2025 18:13:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975022.1362730; Fri, 02 May 2025 18: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 1uAutC-0006ZO-Ay; Fri, 02 May 2025 18:13:34 +0000 Received: by outflank-mailman (input) for mailman id 975022; Fri, 02 May 2025 18:13:32 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAutA-0006ZF-P5 for xen-devel@lists.xenproject.org; Fri, 02 May 2025 18:13:32 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [2600:3c04:e001:324:0:1991:8:25]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 268eda9b-2781-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 20:13:30 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 7304660010; Fri, 2 May 2025 18:13:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 778CBC4CEE9; Fri, 2 May 2025 18:13: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" X-Inumbo-ID: 268eda9b-2781-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746209608; bh=LwJxa40HPDCVnZ/05DntVV8TRZmNP8yD0Unnpj7zVaM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lVKWvi8UioitMliheJ7qUnAslmDD9e/U81eyHZ5KLpYWgtVznI5GaMBkkTHIqpzx2 w2rmTAi1bb332zErvsCTqoiY3+KptK74pB/d16zgjKg1KKnuWs8ipyZwqFaL1lScpA XhaUAz+TrZ3FTf5QpECPp2UYC8hf486ycUXxQ5bI3ecYrZRBnAtTOvsd5M1lfvi8sd t5V/bhi6tz8otxEapEhy7bgTTjORDeBM7KByHVlWVknpXsXQQboirMYaLhs8CoQprT 2+P0BaCzyUUNzDLwqQU0bxlTnuGIio3Q6ZR+MdeYx+pf9mF54tNc+N9pB9NNP16phK tIXqE+0z84QQw== Date: Fri, 2 May 2025 11:13:25 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Kurochko cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v3 3/8] asm-generic: move parts of Arm's asm/kernel.h to common code In-Reply-To: <0c16f8fb2702db5fd6751c7da347a97caa431002.1746199009.git.oleksii.kurochko@gmail.com> Message-ID: References: <0c16f8fb2702db5fd6751c7da347a97caa431002.1746199009.git.oleksii.kurochko@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 2 May 2025, Oleksii Kurochko wrote: > Move the following parts to common with the following changes: > - struct kernel_info: > - Create arch_kernel_info for arch specific kernel information. > At the moment, it contains domain_type for Arm. > - Rename vpl011 to vuart to have more generic name suitable for other archs. > - s/phandle_gic/phandle_intc to have more generic name suitable for other > archs. > - Make text_offset of zimage structure available for RISCV_64. > - Wrap by `#ifdef KERNEL_INFO_SHM_MEM_INIT` definition of KERNEL_SHM_MEM_INIT > and wrap by `#ifndef KERNEL_INFO_INIT` definition of KERNEL_INFO_INIT to have > ability to override KERNEL_INFO_SHM_MEM_INIT for arch in case it doesn't > want to use generic one. > - Move DOM0LESS_* macros to dom0less-build.h. > - Move all others parts of Arm's kernel.h to xen/fdt-kernel.h. > > Because of the changes in struct kernel_info the correspondent parts of Arm's > code are updated. > > As part of this patch the following clean up happens: > - Drop asm/setup.h from asm/kernel.h as nothing depends from it. > Add inclusion of asm/setup.h for a code which uses device_tree_get_reg() to > avoid compilation issues for CONFIG_STATIC_MEMORY and CONFIG_STATIC_SHM. > - Drop inclusion of asm/kernel.h everywhere except xen/fdt-kernel.h. > > Signed-off-by: Oleksii Kurochko Everything looks good except for one question below. This patch looks like a lot of work, thanks Oleksii! > --- > Changes in v3: > - Only resolving of merge conflicts. > --- > Changes in v2: > - Introduce xen/fdt-kernel.h. > - Move DOM0LESS_* macros to dom0less-build.h. > - Move the rest in asm-generic/kernel.h to xen/fdt-kernel.h. > - Drop inclusion of asm/kernel.h everywhere except xen/fdt-kernel.h. > - Wrap by #if __has_include(....) the member of kernel_info structure: > struct arch_kernel_info arch. > - Update the commit message. > --- > xen/arch/arm/acpi/domain_build.c | 2 +- > xen/arch/arm/dom0less-build.c | 31 +++--- > xen/arch/arm/domain_build.c | 12 +- > xen/arch/arm/include/asm/domain_build.h | 2 +- > xen/arch/arm/include/asm/kernel.h | 126 +-------------------- > xen/arch/arm/include/asm/static-memory.h | 2 +- > xen/arch/arm/include/asm/static-shmem.h | 2 +- > xen/arch/arm/kernel.c | 12 +- > xen/arch/arm/static-memory.c | 1 + > xen/arch/arm/static-shmem.c | 1 + > xen/common/device-tree/dt-overlay.c | 2 +- > xen/include/asm-generic/dom0less-build.h | 28 +++++ > xen/include/xen/fdt-kernel.h | 133 +++++++++++++++++++++++ > 13 files changed, 199 insertions(+), 155 deletions(-) > create mode 100644 xen/include/xen/fdt-kernel.h > > diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c > index 2ce75543d0..f9ca8b47e5 100644 > --- a/xen/arch/arm/acpi/domain_build.c > +++ b/xen/arch/arm/acpi/domain_build.c > @@ -10,6 +10,7 @@ > */ > > #include > +#include > #include > #include > #include > @@ -18,7 +19,6 @@ > #include > #include > #include > -#include > #include > > /* Override macros from asm/page.h to make them work with mfn_t */ > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index ef49495d4f..c0634dd61e 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -1,6 +1,7 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > #include > #include > +#include > #include > #include > #include > @@ -64,11 +65,11 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo) > if (res) > return res; > > - res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic); > + res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc); > if (res) > return res; > > - res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic); > + res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc); > if (res) > return res; > > @@ -135,11 +136,11 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo) > if (res) > return res; > > - res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic); > + res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc); > if (res) > return res; > > - res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic); > + res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc); > if (res) > return res; > > @@ -200,7 +201,7 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo) > return res; > > res = fdt_property_cell(fdt, "interrupt-parent", > - kinfo->phandle_gic); > + kinfo->phandle_intc); > if ( res ) > return res; > > @@ -486,10 +487,10 @@ static int __init domain_handle_dtb_bootmodule(struct domain *d, > */ > if ( dt_node_cmp(name, "gic") == 0 ) > { > - uint32_t phandle_gic = fdt_get_phandle(pfdt, node_next); > + uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); > > - if ( phandle_gic != 0 ) > - kinfo->phandle_gic = phandle_gic; > + if ( phandle_intc != 0 ) > + kinfo->phandle_intc = phandle_intc; > continue; > } > > @@ -532,7 +533,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > int addrcells, sizecells; > int ret, fdt_size = DOMU_DTB_SIZE; > > - kinfo->phandle_gic = GUEST_PHANDLE_GIC; > + kinfo->phandle_intc = GUEST_PHANDLE_GIC; > kinfo->gnttab_start = GUEST_GNTTAB_BASE; > kinfo->gnttab_size = GUEST_GNTTAB_SIZE; > > @@ -594,7 +595,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > /* > * domain_handle_dtb_bootmodule has to be called before the rest of > * the device tree is generated because it depends on the value of > - * the field phandle_gic. > + * the field phandle_intc. > */ > if ( kinfo->dtb_bootmodule ) > { > @@ -611,7 +612,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > if ( ret ) > goto err; > > - if ( kinfo->vpl011 ) > + if ( kinfo->vuart ) > { > ret = -EINVAL; > #ifdef CONFIG_SBSA_VUART_CONSOLE > @@ -839,8 +840,8 @@ int __init construct_domU(struct domain *d, > printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n", > d->max_vcpus, mem); > > - kinfo.vpl011 = dt_property_read_bool(node, "vpl011"); > - if ( kinfo.vpl011 && is_hardware_domain(d) ) > + kinfo.vuart = dt_property_read_bool(node, "vpl011"); > + if ( kinfo.vuart && is_hardware_domain(d) ) > panic("hardware domain cannot specify vpl011\n"); > > rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced); > @@ -872,7 +873,7 @@ int __init construct_domU(struct domain *d, > > #ifdef CONFIG_ARM_64 > /* type must be set before allocate memory */ > - d->arch.type = kinfo.type; > + d->arch.type = kinfo.arch.type; > #endif > if ( is_hardware_domain(d) ) > { > @@ -898,7 +899,7 @@ int __init construct_domU(struct domain *d, > * tree node in prepare_dtb_domU, so initialization on related variables > * shall be done first. > */ > - if ( kinfo.vpl011 ) > + if ( kinfo.vuart ) > { > rc = domain_vpl011_init(d, NULL); > if ( rc < 0 ) > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 270a6b97e4..8c7a054718 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -1,6 +1,7 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > #include > #include > +#include > #include > #include > #include > @@ -20,7 +21,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -747,7 +747,7 @@ static int __init fdt_property_interrupts(const struct kernel_info *kinfo, > return res; > > res = fdt_property_cell(kinfo->fdt, "interrupt-parent", > - kinfo->phandle_gic); > + kinfo->phandle_intc); > > return res; > } > @@ -2026,7 +2026,7 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo) > > ASSERT(dt_host && (dt_host->sibling == NULL)); > > - kinfo->phandle_gic = dt_interrupt_controller->phandle; > + kinfo->phandle_intc = dt_interrupt_controller->phandle; > fdt = device_tree_flattened; > > new_size = fdt_totalsize(fdt) + DOM0_FDT_EXTRA_SIZE; > @@ -2196,13 +2196,13 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo) > > #ifdef CONFIG_ARM_64 > /* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */ > - if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT ) > + if ( !(cpu_has_el1_32) && kinfo->arch.type == DOMAIN_32BIT ) > { > printk("Platform does not support 32-bit domain\n"); > return -EINVAL; > } > > - if ( is_sve_domain(d) && (kinfo->type == DOMAIN_32BIT) ) > + if ( is_sve_domain(d) && (kinfo->arch.type == DOMAIN_32BIT) ) > { > printk("SVE is not available for 32-bit domain\n"); > return -EINVAL; > @@ -2318,7 +2318,7 @@ int __init construct_hwdom(struct kernel_info *kinfo, > > #ifdef CONFIG_ARM_64 > /* type must be set before allocate_memory */ > - d->arch.type = kinfo->type; > + d->arch.type = kinfo->arch.type; > #endif > find_gnttab_region(d, kinfo); > if ( is_domain_direct_mapped(d) ) > diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h > index 378c10cc98..df1c0fe301 100644 > --- a/xen/arch/arm/include/asm/domain_build.h > +++ b/xen/arch/arm/include/asm/domain_build.h > @@ -1,8 +1,8 @@ > #ifndef __ASM_DOMAIN_BUILD_H__ > #define __ASM_DOMAIN_BUILD_H__ > > +#include > #include > -#include > > typedef __be32 gic_interrupt_t[3]; > typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg, > diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h > index bdc96f4c18..cfeab792c7 100644 > --- a/xen/arch/arm/include/asm/kernel.h > +++ b/xen/arch/arm/include/asm/kernel.h > @@ -6,137 +6,15 @@ > #ifndef __ARCH_ARM_KERNEL_H__ > #define __ARCH_ARM_KERNEL_H__ > > -#include > #include > -#include > > -/* > - * List of possible features for dom0less domUs > - * > - * DOM0LESS_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All the > - * default features (excluding Xenstore) will be > - * available. Note that an OS *must* not rely on the > - * availability of Xen features if this is not set. > - * DOM0LESS_XENSTORE: Xenstore will be enabled for the VM. The > - * xenstore page allocation is done by Xen at > - * domain creation. This feature can't be > - * enabled without the DOM0LESS_ENHANCED_NO_XS. > - * DOM0LESS_XS_LEGACY Xenstore will be enabled for the VM, the > - * xenstore page allocation will happen in > - * init-dom0less. This feature can't be enabled > - * without the DOM0LESS_ENHANCED_NO_XS. > - * DOM0LESS_ENHANCED: Notify the OS it is running on top of Xen. All the > - * default features (including Xenstore) will be > - * available. Note that an OS *must* not rely on the > - * availability of Xen features if this is not set. > - * DOM0LESS_ENHANCED_LEGACY: Same as before, but using DOM0LESS_XS_LEGACY. > - */ > -#define DOM0LESS_ENHANCED_NO_XS BIT(0, U) > -#define DOM0LESS_XENSTORE BIT(1, U) > -#define DOM0LESS_XS_LEGACY BIT(2, U) > -#define DOM0LESS_ENHANCED_LEGACY (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XS_LEGACY) > -#define DOM0LESS_ENHANCED (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE) > - > -struct kernel_info { > +struct arch_kernel_info > +{ > #ifdef CONFIG_ARM_64 > enum domain_type type; > #endif > - > - struct domain *d; > - > - void *fdt; /* flat device tree */ > - paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */ > - struct meminfo mem; > -#ifdef CONFIG_STATIC_SHM > - struct shared_meminfo shm_mem; > -#endif > - > - /* kernel entry point */ > - paddr_t entry; > - > - /* grant table region */ > - paddr_t gnttab_start; > - paddr_t gnttab_size; > - > - /* boot blob load addresses */ > - const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule; > - const char* cmdline; > - paddr_t dtb_paddr; > - paddr_t initrd_paddr; > - > - /* Enable pl011 emulation */ > - bool vpl011; > - > - /* Enable/Disable PV drivers interfaces */ > - uint16_t dom0less_feature; > - > - /* GIC phandle */ > - uint32_t phandle_gic; > - > - /* loader to use for this kernel */ > - void (*load)(struct kernel_info *info); > - /* loader specific state */ > - union { > - struct { > - paddr_t kernel_addr; > - paddr_t len; > -#ifdef CONFIG_ARM_64 > - paddr_t text_offset; /* 64-bit Image only */ > -#endif > - paddr_t start; /* Must be 0 for 64-bit Image */ > - } zimage; > - }; > }; > > -static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo) > -{ > - return container_of(&kinfo->mem.common, struct membanks, common); > -} > - > -static inline const struct membanks * > -kernel_info_get_mem_const(const struct kernel_info *kinfo) > -{ > - return container_of(&kinfo->mem.common, const struct membanks, common); > -} > - > -#ifdef CONFIG_STATIC_SHM > -#define KERNEL_INFO_SHM_MEM_INIT \ > - .shm_mem.common.max_banks = NR_SHMEM_BANKS, \ > - .shm_mem.common.type = STATIC_SHARED_MEMORY, This line type = STATIC_SHARED_MEMORY, > -#else > -#define KERNEL_INFO_SHM_MEM_INIT > -#endif > - > -#define KERNEL_INFO_INIT \ > -{ \ > - .mem.common.max_banks = NR_MEM_BANKS, \ > - .mem.common.type = MEMORY, \ and also this line type = MEMORY, ... > - KERNEL_INFO_SHM_MEM_INIT \ > -} > - > -/* > - * Probe the kernel to detemine its type and select a loader. > - * > - * Sets in info: > - * ->type > - * ->load hook, and sets loader specific variables ->zimage > - */ > -int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain); > - > -/* > - * Loads the kernel into guest RAM. > - * > - * Expects to be set in info when called: > - * ->mem > - * ->fdt > - * > - * Sets in info: > - * ->entry > - * ->dtb_paddr > - * ->initrd_paddr > - */ > -void kernel_load(struct kernel_info *info); > - > #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */ > > /* > diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/arch/arm/include/asm/static-memory.h > index 804166e541..a32a3c6553 100644 > --- a/xen/arch/arm/include/asm/static-memory.h > +++ b/xen/arch/arm/include/asm/static-memory.h > @@ -3,8 +3,8 @@ > #ifndef __ASM_STATIC_MEMORY_H_ > #define __ASM_STATIC_MEMORY_H_ > > +#include > #include > -#include > > #ifdef CONFIG_STATIC_MEMORY > > diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h > index 94eaa9d500..a4f853805a 100644 > --- a/xen/arch/arm/include/asm/static-shmem.h > +++ b/xen/arch/arm/include/asm/static-shmem.h > @@ -3,8 +3,8 @@ > #ifndef __ASM_STATIC_SHMEM_H_ > #define __ASM_STATIC_SHMEM_H_ > > +#include > #include > -#include > #include > > #ifdef CONFIG_STATIC_SHM > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c > index 2647812e8e..f00fc388db 100644 > --- a/xen/arch/arm/kernel.c > +++ b/xen/arch/arm/kernel.c > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -16,6 +17,7 @@ > #include > #include > > +#include > #include > #include > > @@ -101,7 +103,7 @@ static paddr_t __init kernel_zimage_place(struct kernel_info *info) > paddr_t load_addr; > > #ifdef CONFIG_ARM_64 > - if ( (info->type == DOMAIN_64BIT) && (info->zimage.start == 0) ) > + if ( (info->arch.type == DOMAIN_64BIT) && (info->zimage.start == 0) ) > return mem->bank[0].start + info->zimage.text_offset; > #endif > > @@ -371,10 +373,10 @@ static int __init kernel_uimage_probe(struct kernel_info *info, > switch ( uimage.arch ) > { > case IH_ARCH_ARM: > - info->type = DOMAIN_32BIT; > + info->arch.type = DOMAIN_32BIT; > break; > case IH_ARCH_ARM64: > - info->type = DOMAIN_64BIT; > + info->arch.type = DOMAIN_64BIT; > break; > default: > printk(XENLOG_ERR "Unsupported uImage arch type %d\n", uimage.arch); > @@ -444,7 +446,7 @@ static int __init kernel_zimage64_probe(struct kernel_info *info, > > info->load = kernel_zimage_load; > > - info->type = DOMAIN_64BIT; > + info->arch.type = DOMAIN_64BIT; > > return 0; > } > @@ -496,7 +498,7 @@ static int __init kernel_zimage32_probe(struct kernel_info *info, > info->load = kernel_zimage_load; > > #ifdef CONFIG_ARM_64 > - info->type = DOMAIN_32BIT; > + info->arch.type = DOMAIN_32BIT; > #endif > > return 0; > diff --git a/xen/arch/arm/static-memory.c b/xen/arch/arm/static-memory.c > index d4585c5a06..e0f76afcd8 100644 > --- a/xen/arch/arm/static-memory.c > +++ b/xen/arch/arm/static-memory.c > @@ -2,6 +2,7 @@ > > #include > > +#include > #include > > static bool __init append_static_memory_to_bank(struct domain *d, > diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c > index e8d4ca3ba3..14ae48fb1e 100644 > --- a/xen/arch/arm/static-shmem.c > +++ b/xen/arch/arm/static-shmem.c > @@ -6,6 +6,7 @@ > #include > > #include > +#include > #include > #include > > diff --git a/xen/common/device-tree/dt-overlay.c b/xen/common/device-tree/dt-overlay.c > index 97fb99eaaa..81107cb48d 100644 > --- a/xen/common/device-tree/dt-overlay.c > +++ b/xen/common/device-tree/dt-overlay.c > @@ -6,8 +6,8 @@ > * Written by Vikram Garhwal > * > */ > -#include > #include > +#include > #include > #include > #include > diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h > index 5655571a66..f095135caa 100644 > --- a/xen/include/asm-generic/dom0less-build.h > +++ b/xen/include/asm-generic/dom0less-build.h > @@ -16,6 +16,34 @@ struct dt_device_node; > #define XENSTORE_PFN_LATE_ALLOC UINT64_MAX > extern bool need_xenstore; > > +/* > + * List of possible features for dom0less domUs > + * > + * DOM0LESS_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All the > + * default features (excluding Xenstore) will be > + * available. Note that an OS *must* not rely on the > + * availability of Xen features if this is not set. > + * DOM0LESS_XENSTORE: Xenstore will be enabled for the VM. The > + * xenstore page allocation is done by Xen at > + * domain creation. This feature can't be > + * enabled without the DOM0LESS_ENHANCED_NO_XS. > + * DOM0LESS_XS_LEGACY Xenstore will be enabled for the VM, the > + * xenstore page allocation will happen in > + * init-dom0less. This feature can't be enabled > + * without the DOM0LESS_ENHANCED_NO_XS. > + * DOM0LESS_ENHANCED: Notify the OS it is running on top of Xen. All the > + * default features (including Xenstore) will be > + * available. Note that an OS *must* not rely on the > + * availability of Xen features if this is not set. > + * DOM0LESS_ENHANCED_LEGACY: Same as before, but using DOM0LESS_XS_LEGACY. > + > + */ > +#define DOM0LESS_ENHANCED_NO_XS BIT(0, U) > +#define DOM0LESS_XENSTORE BIT(1, U) > +#define DOM0LESS_XS_LEGACY BIT(2, U) > +#define DOM0LESS_ENHANCED_LEGACY (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XS_LEGACY) > +#define DOM0LESS_ENHANCED (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE) > + > void create_domUs(void); > bool is_dom0less_mode(void); > void set_xs_domain(struct domain *d); > diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h > new file mode 100644 > index 0000000000..c81e759423 > --- /dev/null > +++ b/xen/include/xen/fdt-kernel.h > @@ -0,0 +1,133 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * For Kernel image loading. > + * > + * Copyright (C) 2011 Citrix Systems, Inc. > + */ > +#ifndef __XEN_FDT_KERNEL_H__ > +#define __XEN_FDT_KERNEL_H__ > + > +#include > +#include > +#include > + > +#if __has_include() > +# include > +#endif > + > +struct kernel_info { > + struct domain *d; > + > + void *fdt; /* flat device tree */ > + paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */ > + struct meminfo mem; > +#ifdef CONFIG_STATIC_SHM > + struct shared_meminfo shm_mem; > +#endif > + > + /* kernel entry point */ > + paddr_t entry; > + > + /* grant table region */ > + paddr_t gnttab_start; > + paddr_t gnttab_size; > + > + /* boot blob load addresses */ > + const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule; > + const char* cmdline; > + paddr_t dtb_paddr; > + paddr_t initrd_paddr; > + > + /* Enable uart emulation */ > + bool vuart; > + > + /* Enable/Disable PV drivers interfaces */ > + uint16_t dom0less_feature; > + > + /* Interrupt controller phandle */ > + uint32_t phandle_intc; > + > + /* loader to use for this kernel */ > + void (*load)(struct kernel_info *info); > + > + /* loader specific state */ > + union { > + struct { > + paddr_t kernel_addr; > + paddr_t len; > +#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64) > + paddr_t text_offset; /* 64-bit Image only */ > +#endif > + paddr_t start; /* Must be 0 for 64-bit Image */ > + } zimage; > + }; > + > +#if __has_include() > + struct arch_kernel_info arch; > +#endif > +}; > + > +static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo) > +{ > + return container_of(&kinfo->mem.common, struct membanks, common); > +} > + > +static inline const struct membanks * > +kernel_info_get_mem_const(const struct kernel_info *kinfo) > +{ > + return container_of(&kinfo->mem.common, const struct membanks, common); > +} > + > +#ifndef KERNEL_INFO_SHM_MEM_INIT > + > +#ifdef CONFIG_STATIC_SHM > +#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS, they are missing here... > +#else > +#define KERNEL_INFO_SHM_MEM_INIT > +#endif > + > +#endif /* KERNEL_INFO_SHM_MEM_INIT */ > + > +#ifndef KERNEL_INFO_INIT > + > +#define KERNEL_INFO_INIT \ > +{ \ > + .mem.common.max_banks = NR_MEM_BANKS, \ and also here. Why? > + KERNEL_INFO_SHM_MEM_INIT \ > +} > + > +#endif /* KERNEL_INFO_INIT */ > + > +/* > + * Probe the kernel to detemine its type and select a loader. > + * > + * Sets in info: > + * ->type > + * ->load hook, and sets loader specific variables ->zimage > + */ > +int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain); > + > +/* > + * Loads the kernel into guest RAM. > + * > + * Expects to be set in info when called: > + * ->mem > + * ->fdt > + * > + * Sets in info: > + * ->entry > + * ->dtb_paddr > + * ->initrd_paddr > + */ > +void kernel_load(struct kernel_info *info); > + > +#endif /* __XEN_FDT_KERNEL_H__ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > -- > 2.49.0 > From xen-devel-bounces@lists.xenproject.org Fri May 02 19:14:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 19:14:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975040.1362742 (Exim 4.92) (envelope-from ) id 1uAvpp-0007lA-LG; Fri, 02 May 2025 19:14:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975040.1362742; Fri, 02 May 2025 19:14: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 1uAvpp-0007l3-HQ; Fri, 02 May 2025 19:14:09 +0000 Received: by outflank-mailman (input) for mailman id 975040; Fri, 02 May 2025 19:14:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAvpo-0007kx-L6 for xen-devel@lists.xenproject.org; Fri, 02 May 2025 19:14:08 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9ad3abed-2789-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 21:14:02 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id D4A5844495; Fri, 2 May 2025 19:13:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25D07C4CEE4; Fri, 2 May 2025 19:13: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" X-Inumbo-ID: 9ad3abed-2789-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746213240; bh=uGGcSP+XC5A+afhF/XOIfsuMCLzMRjeIDkL/zzIXsOY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qgnPSqhrTLn+kFmAP+WY31LB/yZjgzbs6rvfSTK94ur/kVM6poXI4FJiZTTdjoFOf vh8ZrBTjrtPsYLbvQkJlkfP0w/S8AEhhtTzbwfZoTuVMmZ2x3QlsWEDIElilbEYgGy qxoSjk36Mna3DGtMNfCqIa8LWhmq0iEsV5a6p9fdcj3jBXBtkLYlJmGH+G8cokHqg9 w56Z9uO1pBNOsFBE4n5ZgflK6GHfmHlMBg/5dmLmJCuAgvdCt7pLbmk/Q/qGTtYUsK jhckOA85i8oSDNvH+EYYxrsYFM5+N+22Q5ph9QSbyLd5edt4CxGY2e/OaW837Do3kp RRGVC0iStOvTg== Date: Fri, 2 May 2025 12:13:57 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Kurochko cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v3 4/8] arm/static-shmem.h: drop inclusion of asm/setup.h In-Reply-To: <5e02dc75f4f396d054e9b9206b9305889cadb1a5.1746199009.git.oleksii.kurochko@gmail.com> Message-ID: References: <5e02dc75f4f396d054e9b9206b9305889cadb1a5.1746199009.git.oleksii.kurochko@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 2 May 2025, Oleksii Kurochko wrote: > Nothing is dependent from asm/setup.h in asm/static-shmem.h so inclusion of > asm/setup.h is droped. Actually, this patch is not currently dropping any inclusions > After this drop the following compilation error related to impicit declaration > of the following functions device_tree_get_reg and map_device_irqs_to_domain, > device_tree_get_u32 occur during compilation of dom0less-build.c ( as they are > declared in asm/setup.h ). > > Add inclusion of in dt-overlay.c as it is using handle_device() > declared in . > > Signed-off-by: Oleksii Kurochko > --- > Changes in V2-3: > - Nothing changed. Only rebase. > --- > xen/arch/arm/dom0less-build.c | 1 + > xen/common/device-tree/dt-overlay.c | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index c0634dd61e..7eecd06d44 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include > > diff --git a/xen/common/device-tree/dt-overlay.c b/xen/common/device-tree/dt-overlay.c > index 81107cb48d..d184186c01 100644 > --- a/xen/common/device-tree/dt-overlay.c > +++ b/xen/common/device-tree/dt-overlay.c > @@ -13,6 +13,8 @@ > #include > #include > > +#include > + > #define DT_OVERLAY_MAX_SIZE KB(500) > > static LIST_HEAD(overlay_tracker); > -- > 2.49.0 > From xen-devel-bounces@lists.xenproject.org Fri May 02 19:37:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 19:37:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975055.1362751 (Exim 4.92) (envelope-from ) id 1uAwBs-0002XG-Dx; Fri, 02 May 2025 19:36:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975055.1362751; Fri, 02 May 2025 19: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 1uAwBs-0002X9-AL; Fri, 02 May 2025 19:36:56 +0000 Received: by outflank-mailman (input) for mailman id 975055; Fri, 02 May 2025 19:36:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAwBq-0002X3-N2 for xen-devel@lists.xenproject.org; Fri, 02 May 2025 19:36:54 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c9923acb-278c-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 21:36:49 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E43375C5A32; Fri, 2 May 2025 19:34:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49801C4CEE4; Fri, 2 May 2025 19:36: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" X-Inumbo-ID: c9923acb-278c-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746214606; bh=bsYX1y6C9aOuK4WlQ4kkvjZoz15/h3IfIOItFweCaoo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=gp5Fl0V1UL7jIWpNwzdRB0WdW8IjiHsxhdPLtkiZCuHjK1kCv9H6bXZs836PwOdwy F5JohAHVKysh+cojI7reXnXVjBJ4S/B/pvyT9EgWotNFZR6dqseCUEzEFEDY0290iC /QP6Q3QYO/uHNqdBOs4XeJoTTmsIVXcYW2XTYV2ckChcrrNNgQLBl8dH7HnQISEoBs 8GjeKUgBtwG3zKJ1jdV+I5stelDQ9enJo11tyJLB0rTe9m8YR/6PHRDYVIJTSHCJ2p dC4icsLhCbgUmOSGz9t8R5N066RuWWAf9iyA/G5aTAEyRDc+7fjDXCmCVNcN8fykhO ksvslVZ4NiB7g== Date: Fri, 2 May 2025 12:36:43 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Kurochko cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v3 6/8] xen/common: dom0less: introduce common kernel.c In-Reply-To: <4f178bd0e46adf3d4c7a91d6cdd4a0910dbef490.1746199009.git.oleksii.kurochko@gmail.com> Message-ID: References: <4f178bd0e46adf3d4c7a91d6cdd4a0910dbef490.1746199009.git.oleksii.kurochko@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 2 May 2025, Oleksii Kurochko wrote: > The following functions don't have arch specific things so it is moved to > common: > - kernel_prboe() > - kernel_load() > - output_length() > > Functions necessary for dom0less are only moved. > > The following changes are done: > - Swap __init and return type of kernel_decompress() function to be > consistent with defintions of functions in other files. The same > for output_length(). > - Wrap by "ifdef CONFIG_ARM" the call of kernel_uimage_probe() in > kernel_probe() as uImage isn't really used nowadays thereby leave > kernel_uimage_probe() call here just for compatability with Arm code. > - Introduce kernel_zimage_probe() to cover the case that arch can have > different zimage header. > - Add ASSERT() for kernel_load() to check that it argument isn't NULL. > - Make kernel_uimage_probe() non-static in Arm's code as it is used in > common/kernel.c. > > Introduce CONFIG_DOMAIN_BUILD_HELPERS to not provide stubs for archs > which don't provide enough functionality to enable it. > Select CONFIG_DOMAIN_BUILD_HELPERS for CONFIG_ARM as only Arm supports > it, at the moment. > > Signed-off-by: Oleksii Kurochko > --- > Change in v3: > - Empty line after license tag for newly introduced files. > --- > Change in v2: > - Drop inclusion of asm/kernel.h in kernel.c as everything necessary has > been moved to xen/fdt-kernel.h. > --- > xen/arch/arm/Kconfig | 1 + > xen/arch/arm/kernel.c | 221 +--------------------------- > xen/common/Kconfig | 9 +- > xen/common/device-tree/Makefile | 1 + > xen/common/device-tree/kernel.c | 242 +++++++++++++++++++++++++++++++ > xen/include/asm-generic/kernel.h | 141 ++++++++++++++++++ > xen/include/xen/fdt-kernel.h | 13 ++ > 7 files changed, 412 insertions(+), 216 deletions(-) > create mode 100644 xen/common/device-tree/kernel.c > create mode 100644 xen/include/asm-generic/kernel.h > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index d0e0a7753c..3321d89068 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -11,6 +11,7 @@ config ARM_64 > > config ARM > def_bool y > + select DOMAIN_BUILD_HELPERS > select FUNCTION_ALIGNMENT_4B > select GENERIC_UART_INIT > select HAS_ALTERNATIVE if HAS_VMAP > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c > index 5759a3470a..1168c21e97 100644 > --- a/xen/arch/arm/kernel.c > +++ b/xen/arch/arm/kernel.c > @@ -163,105 +163,6 @@ static void __init kernel_zimage_load(struct kernel_info *info) > iounmap(kernel); > } > > -static __init uint32_t output_length(char *image, unsigned long image_len) > -{ > - return *(uint32_t *)&image[image_len - 4]; > -} > - > -static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset) > -{ > - char *output, *input; > - char magic[2]; > - int rc; > - unsigned int kernel_order_out; > - paddr_t output_size; > - struct page_info *pages; > - mfn_t mfn; > - int i; > - paddr_t addr = mod->start; > - paddr_t size = mod->size; > - > - if ( size < offset ) > - return -EINVAL; > - > - /* > - * It might be that gzip header does not appear at the start address > - * (e.g. in case of compressed uImage) so take into account offset to > - * gzip header. > - */ > - addr += offset; > - size -= offset; > - > - if ( size < 2 ) > - return -EINVAL; > - > - copy_from_paddr(magic, addr, sizeof(magic)); > - > - /* only gzip is supported */ > - if ( !gzip_check(magic, size) ) > - return -EINVAL; > - > - input = ioremap_cache(addr, size); > - if ( input == NULL ) > - return -EFAULT; > - > - output_size = output_length(input, size); > - kernel_order_out = get_order_from_bytes(output_size); > - pages = alloc_domheap_pages(NULL, kernel_order_out, 0); > - if ( pages == NULL ) > - { > - iounmap(input); > - return -ENOMEM; > - } > - mfn = page_to_mfn(pages); > - output = vmap_contig(mfn, 1 << kernel_order_out); > - > - rc = perform_gunzip(output, input, size); > - clean_dcache_va_range(output, output_size); > - iounmap(input); > - vunmap(output); > - > - if ( rc ) > - { > - free_domheap_pages(pages, kernel_order_out); > - return rc; > - } > - > - mod->start = page_to_maddr(pages); > - mod->size = output_size; > - > - /* > - * Need to free pages after output_size here because they won't be > - * freed by discard_initial_modules > - */ > - i = PFN_UP(output_size); > - for ( ; i < (1 << kernel_order_out); i++ ) > - free_domheap_page(pages + i); > - > - /* > - * When using static heap feature, don't give bootmodules memory back to > - * the heap allocator > - */ > - if ( using_static_heap ) > - return 0; > - > - /* > - * When freeing the kernel, we need to pass the module start address and > - * size as they were before taking an offset to gzip header into account, > - * so that the entire region will be freed. > - */ > - addr -= offset; > - size += offset; > - > - /* > - * Free the original kernel, update the pointers to the > - * decompressed kernel > - */ > - fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0); > - > - return 0; > -} > - > /* > * Uimage CPU Architecture Codes > */ > @@ -274,8 +175,8 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset) > /* > * Check if the image is a uImage and setup kernel_info > */ > -static int __init kernel_uimage_probe(struct kernel_info *info, > - struct bootmodule *mod) > +int __init kernel_uimage_probe(struct kernel_info *info, > + struct bootmodule *mod) > { > struct { > __be32 magic; /* Image Header Magic Number */ > @@ -505,130 +406,20 @@ static int __init kernel_zimage32_probe(struct kernel_info *info, > return 0; > } > > -int __init kernel_probe(struct kernel_info *info, > - const struct dt_device_node *domain) > +int __init kernel_zimage_probe(struct kernel_info *info, paddr_t addr, > + paddr_t size) > { > - struct bootmodule *mod = NULL; > - struct bootcmdline *cmd = NULL; > - struct dt_device_node *node; > - u64 kernel_addr, initrd_addr, dtb_addr, size; > int rc; > > - /* > - * We need to initialize start to 0. This field may be populated during > - * kernel_xxx_probe() if the image has a fixed entry point (for e.g. > - * uimage.ep). > - * We will use this to determine if the image has a fixed entry point or > - * the load address should be used as the start address. > - */ > - info->entry = 0; > - > - /* domain is NULL only for the hardware domain */ > - if ( domain == NULL ) > - { > - ASSERT(is_hardware_domain(info->d)); > - > - mod = boot_module_find_by_kind(BOOTMOD_KERNEL); > - > - info->kernel_bootmodule = mod; > - info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK); > - > - cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL); > - if ( cmd ) > - info->cmdline = &cmd->cmdline[0]; > - } > - else > - { > - const char *name = NULL; > - > - dt_for_each_child_node(domain, node) > - { > - if ( dt_device_is_compatible(node, "multiboot,kernel") ) > - { > - u32 len; > - const __be32 *val; > - > - val = dt_get_property(node, "reg", &len); > - dt_get_range(&val, node, &kernel_addr, &size); > - mod = boot_module_find_by_addr_and_kind( > - BOOTMOD_KERNEL, kernel_addr); > - info->kernel_bootmodule = mod; > - } > - else if ( dt_device_is_compatible(node, "multiboot,ramdisk") ) > - { > - u32 len; > - const __be32 *val; > - > - val = dt_get_property(node, "reg", &len); > - dt_get_range(&val, node, &initrd_addr, &size); > - info->initrd_bootmodule = boot_module_find_by_addr_and_kind( > - BOOTMOD_RAMDISK, initrd_addr); > - } > - else if ( dt_device_is_compatible(node, "multiboot,device-tree") ) > - { > - uint32_t len; > - const __be32 *val; > - > - val = dt_get_property(node, "reg", &len); > - if ( val == NULL ) > - continue; > - dt_get_range(&val, node, &dtb_addr, &size); > - info->dtb_bootmodule = boot_module_find_by_addr_and_kind( > - BOOTMOD_GUEST_DTB, dtb_addr); > - } > - else > - continue; > - } > - name = dt_node_name(domain); > - cmd = boot_cmdline_find_by_name(name); > - if ( cmd ) > - info->cmdline = &cmd->cmdline[0]; > - } > - if ( !mod || !mod->size ) > - { > - printk(XENLOG_ERR "Missing kernel boot module?\n"); > - return -ENOENT; > - } > - > - printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n", > - info->d, info->kernel_bootmodule->start); > - if ( info->initrd_bootmodule ) > - printk("Loading ramdisk from boot module @ %"PRIpaddr"\n", > - info->initrd_bootmodule->start); > - > - /* > - * uImage header always appears at the top of the image (even compressed), > - * so it needs to be probed first. Note that in case of compressed uImage, > - * kernel_decompress is called from kernel_uimage_probe making the function > - * self-containing (i.e. fall through only in case of a header not found). > - */ > - rc = kernel_uimage_probe(info, mod); > - if ( rc != -ENOENT ) > - return rc; > - > - /* > - * If it is a gzip'ed image, 32bit or 64bit, uncompress it. > - * At this point, gzip header appears (if at all) at the top of the image, > - * so pass 0 as an offset. > - */ > - rc = kernel_decompress(mod, 0); > - if ( rc && rc != -EINVAL ) > - return rc; > - > #ifdef CONFIG_ARM_64 > - rc = kernel_zimage64_probe(info, mod->start, mod->size); > + rc = kernel_zimage64_probe(info, addr, size); > if (rc < 0) > #endif > - rc = kernel_zimage32_probe(info, mod->start, mod->size); > + rc = kernel_zimage32_probe(info, addr, size); > > return rc; > } > > -void __init kernel_load(struct kernel_info *info) > -{ > - info->load(info); > -} > - > /* > * Local variables: > * mode: C > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index be38abf9e1..38981f1d11 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -14,13 +14,20 @@ config CORE_PARKING > > config DOM0LESS_BOOT > bool "Dom0less boot support" if EXPERT > - depends on HAS_DOM0LESS > + depends on HAS_DOM0LESS && DOMAIN_BUILD_HELPERS > default y > help > Dom0less boot support enables Xen to create and start domU guests during > Xen boot without the need of a control domain (Dom0), which could be > present anyway. > > +config DOMAIN_BUILD_HELPERS > + bool > + help > + Introduce functions necessary for working with domain creation, kernel, > + etc. As an examples, these type of functions are going to be used by > + CONFIG_DOM0LESS_BOOT. NIT: If possible, I would make this option a silent option that cannot be manually enabled/disabled. As a choice to the user, I think DOM0LESS_BOOT is sufficient. > config GRANT_TABLE > bool "Grant table support" if EXPERT > default y > diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile > index f3dafc9b81..e88a4d5799 100644 > --- a/xen/common/device-tree/Makefile > +++ b/xen/common/device-tree/Makefile > @@ -4,3 +4,4 @@ obj-y += device-tree.o > obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o > obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o > obj-y += intc.o > +obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o > diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c > new file mode 100644 > index 0000000000..1bf3bbf64e > --- /dev/null > +++ b/xen/common/device-tree/kernel.c > @@ -0,0 +1,242 @@ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +static uint32_t __init output_length(char *image, unsigned long image_len) > +{ > + return *(uint32_t *)&image[image_len - 4]; > +} > + > +int __init kernel_decompress(struct bootmodule *mod, uint32_t offset) > +{ > + char *output, *input; > + char magic[2]; > + int rc; > + unsigned int kernel_order_out; > + paddr_t output_size; > + struct page_info *pages; > + mfn_t mfn; > + int i; > + paddr_t addr = mod->start; > + paddr_t size = mod->size; > + > + if ( size < offset ) > + return -EINVAL; > + > + /* > + * It might be that gzip header does not appear at the start address > + * (e.g. in case of compressed uImage) so take into account offset to > + * gzip header. > + */ > + addr += offset; > + size -= offset; > + > + if ( size < 2 ) > + return -EINVAL; > + > + copy_from_paddr(magic, addr, sizeof(magic)); > + > + /* only gzip is supported */ > + if ( !gzip_check(magic, size) ) > + return -EINVAL; > + > + input = ioremap_cache(addr, size); > + if ( input == NULL ) > + return -EFAULT; > + > + output_size = output_length(input, size); > + kernel_order_out = get_order_from_bytes(output_size); > + pages = alloc_domheap_pages(NULL, kernel_order_out, 0); > + if ( pages == NULL ) > + { > + iounmap(input); > + return -ENOMEM; > + } > + mfn = page_to_mfn(pages); > + output = vmap_contig(mfn, 1 << kernel_order_out); > + > + rc = perform_gunzip(output, input, size); > + clean_dcache_va_range(output, output_size); > + iounmap(input); > + vunmap(output); > + > + if ( rc ) > + { > + free_domheap_pages(pages, kernel_order_out); > + return rc; > + } > + > + mod->start = page_to_maddr(pages); > + mod->size = output_size; > + > + /* > + * Need to free pages after output_size here because they won't be > + * freed by discard_initial_modules > + */ > + i = PFN_UP(output_size); > + for ( ; i < (1 << kernel_order_out); i++ ) > + free_domheap_page(pages + i); > + > + /* > + * When using static heap feature, don't give bootmodules memory back to > + * the heap allocator > + */ > + if ( using_static_heap ) > + return 0; > + > + /* > + * When freeing the kernel, we need to pass the module start address and > + * size as they were before taking an offset to gzip header into account, > + * so that the entire region will be freed. > + */ > + addr -= offset; > + size += offset; > + > + /* > + * Free the original kernel, update the pointers to the > + * decompressed kernel > + */ > + fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0); > + > + return 0; > +} > + > +int __init kernel_probe(struct kernel_info *info, > + const struct dt_device_node *domain) > +{ > + struct bootmodule *mod = NULL; > + struct bootcmdline *cmd = NULL; > + struct dt_device_node *node; > + u64 kernel_addr, initrd_addr, dtb_addr, size; > + int rc; > + > + /* > + * We need to initialize start to 0. This field may be populated during > + * kernel_xxx_probe() if the image has a fixed entry point (for e.g. > + * uimage.ep). > + * We will use this to determine if the image has a fixed entry point or > + * the load address should be used as the start address. > + */ > + info->entry = 0; > + > + /* domain is NULL only for the hardware domain */ > + if ( domain == NULL ) > + { > + ASSERT(is_hardware_domain(info->d)); > + > + mod = boot_module_find_by_kind(BOOTMOD_KERNEL); > + > + info->kernel_bootmodule = mod; > + info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK); > + > + cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL); > + if ( cmd ) > + info->cmdline = &cmd->cmdline[0]; > + } > + else > + { > + const char *name = NULL; > + > + dt_for_each_child_node(domain, node) > + { > + if ( dt_device_is_compatible(node, "multiboot,kernel") ) > + { > + u32 len; > + const __be32 *val; > + > + val = dt_get_property(node, "reg", &len); > + dt_get_range(&val, node, &kernel_addr, &size); > + mod = boot_module_find_by_addr_and_kind( > + BOOTMOD_KERNEL, kernel_addr); > + info->kernel_bootmodule = mod; > + } > + else if ( dt_device_is_compatible(node, "multiboot,ramdisk") ) > + { > + u32 len; > + const __be32 *val; > + > + val = dt_get_property(node, "reg", &len); > + dt_get_range(&val, node, &initrd_addr, &size); > + info->initrd_bootmodule = boot_module_find_by_addr_and_kind( > + BOOTMOD_RAMDISK, initrd_addr); > + } > + else if ( dt_device_is_compatible(node, "multiboot,device-tree") ) > + { > + uint32_t len; > + const __be32 *val; > + > + val = dt_get_property(node, "reg", &len); > + if ( val == NULL ) > + continue; > + dt_get_range(&val, node, &dtb_addr, &size); > + info->dtb_bootmodule = boot_module_find_by_addr_and_kind( > + BOOTMOD_GUEST_DTB, dtb_addr); > + } > + else > + continue; > + } > + name = dt_node_name(domain); > + cmd = boot_cmdline_find_by_name(name); > + if ( cmd ) > + info->cmdline = &cmd->cmdline[0]; > + } > + if ( !mod || !mod->size ) > + { > + printk(XENLOG_ERR "Missing kernel boot module?\n"); > + return -ENOENT; > + } > + > + printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n", > + info->d, info->kernel_bootmodule->start); > + if ( info->initrd_bootmodule ) > + printk("Loading ramdisk from boot module @ %"PRIpaddr"\n", > + info->initrd_bootmodule->start); > + > + /* > + * uImage isn't really used nowadays thereby leave kernel_uimage_probe() > + * call here just for compatability with Arm code. > + */ > +#ifdef CONFIG_ARM > + /* > + * uImage header always appears at the top of the image (even compressed), > + * so it needs to be probed first. Note that in case of compressed uImage, > + * kernel_decompress is called from kernel_uimage_probe making the function > + * self-containing (i.e. fall through only in case of a header not found). > + */ > + rc = kernel_uimage_probe(info, mod); > + if ( rc != -ENOENT ) > + return rc; > +#endif > + > + /* > + * If it is a gzip'ed image, 32bit or 64bit, uncompress it. > + * At this point, gzip header appears (if at all) at the top of the image, > + * so pass 0 as an offset. > + */ > + rc = kernel_decompress(mod, 0); > + if ( rc && rc != -EINVAL ) > + return rc; > + > + rc = kernel_zimage_probe(info, mod->start, mod->size); > + > + return rc; > +} > + > +void __init kernel_load(struct kernel_info *info) > +{ > + ASSERT(info && info->load); > + > + info->load(info); > +} > diff --git a/xen/include/asm-generic/kernel.h b/xen/include/asm-generic/kernel.h > new file mode 100644 > index 0000000000..6857fabb34 > --- /dev/null > +++ b/xen/include/asm-generic/kernel.h This file seems to be a duplicate of the previously introduced xen/include/xen/fdt-kernel.h ? Other than that, I checked the rest of the patch, including all the code movement, and it looks correct to me. > @@ -0,0 +1,141 @@ > +/* > + * Kernel image loading. > + * > + * Copyright (C) 2011 Citrix Systems, Inc. > + */ > + > +#ifndef __ASM_GENERIC_KERNEL_H__ > +#define __ASM_GENERIC_KERNEL_H__ > + > +#include > +#include > +#include > +#include > + > +struct kernel_info { > + struct domain *d; > + > + void *fdt; /* flat device tree */ > + paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */ > + struct meminfo mem; > +#ifdef CONFIG_STATIC_SHM > + struct shared_meminfo shm_mem; > +#endif > + > + /* kernel entry point */ > + paddr_t entry; > + > + /* grant table region */ > + paddr_t gnttab_start; > + paddr_t gnttab_size; > + > + /* boot blob load addresses */ > + const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule; > + const char* cmdline; > + paddr_t dtb_paddr; > + paddr_t initrd_paddr; > + > + /* Enable uart emulation */ > + bool vuart; > + > + /* Enable/Disable PV drivers interfaces */ > + uint16_t dom0less_feature; > + > + /* Interrupt controller phandle */ > + uint32_t phandle_intc; > + > + /* loader to use for this kernel */ > + void (*load)(struct kernel_info *info); > + > + /* loader specific state */ > + union { > + struct { > + paddr_t kernel_addr; > + paddr_t len; > +#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64) > + paddr_t text_offset; /* 64-bit Image only */ > +#endif > + paddr_t start; /* Must be 0 for 64-bit Image */ > + } zimage; > + }; > + > + struct arch_kernel_info arch; > +}; > + > +static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo) > +{ > + return container_of(&kinfo->mem.common, struct membanks, common); > +} > + > +static inline const struct membanks * > +kernel_info_get_mem_const(const struct kernel_info *kinfo) > +{ > + return container_of(&kinfo->mem.common, const struct membanks, common); > +} > + > +#ifndef KERNEL_INFO_SHM_MEM_INIT > + > +#ifdef CONFIG_STATIC_SHM > +#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS, > +#else > +#define KERNEL_INFO_SHM_MEM_INIT > +#endif > + > +#endif /* KERNEL_INFO_SHM_MEM_INIT */ > + > +#ifndef KERNEL_INFO_INIT > + > +#define KERNEL_INFO_INIT \ > +{ \ > + .mem.common.max_banks = NR_MEM_BANKS, \ > + KERNEL_INFO_SHM_MEM_INIT \ > +} > + > +#endif /* KERNEL_INFO_INIT */ > + > +/* > + * Probe the kernel to detemine its type and select a loader. > + * > + * Sets in info: > + * ->type > + * ->load hook, and sets loader specific variables ->zimage > + */ > +int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain); > + > +/* > + * Loads the kernel into guest RAM. > + * > + * Expects to be set in info when called: > + * ->mem > + * ->fdt > + * > + * Sets in info: > + * ->entry > + * ->dtb_paddr > + * ->initrd_paddr > + */ > +void kernel_load(struct kernel_info *info); > + > +int kernel_decompress(struct bootmodule *mod, uint32_t offset); > + > +int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size); > + > +/* > + * uImage isn't really used nowadays thereby leave kernel_uimage_probe() > + * call here just for compatability with Arm code. > + */ > +#ifdef CONFIG_ARM > +struct bootmodule; > +int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod); > +#endif > + > +#endif /*__ASM_GENERIC_KERNEL_H__ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h > index c81e759423..d85324c867 100644 > --- a/xen/include/xen/fdt-kernel.h > +++ b/xen/include/xen/fdt-kernel.h > @@ -121,6 +121,19 @@ int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain); > */ > void kernel_load(struct kernel_info *info); > > +int kernel_decompress(struct bootmodule *mod, uint32_t offset); > + > +int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size); > + > +/* > + * uImage isn't really used nowadays thereby leave kernel_uimage_probe() > + * call here just for compatability with Arm code. > + */ > +#ifdef CONFIG_ARM > +struct bootmodule; > +int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod); > +#endif > + > #endif /* __XEN_FDT_KERNEL_H__ */ > > /* > -- > 2.49.0 > From xen-devel-bounces@lists.xenproject.org Fri May 02 20:02:16 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 20:02:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975077.1362761 (Exim 4.92) (envelope-from ) id 1uAwaI-00070w-CV; Fri, 02 May 2025 20:02:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975077.1362761; Fri, 02 May 2025 20:02: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 1uAwaI-00070p-8U; Fri, 02 May 2025 20:02:10 +0000 Received: by outflank-mailman (input) for mailman id 975077; Fri, 02 May 2025 20:02:08 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAwaG-0006zC-52 for xen-devel@lists.xenproject.org; Fri, 02 May 2025 20:02:08 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 516f99b7-2790-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 22:02:05 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 559F65C4220; Fri, 2 May 2025 19:59:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B093AC4CEED; Fri, 2 May 2025 20:02: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" X-Inumbo-ID: 516f99b7-2790-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746216123; bh=f2KS21WEJz6HDZjUkT0wo1uFKr0HXO046yD8gmFVkLA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TwOv6YxFvKXNxRqZyy0FWcHd3bNUG7sUFwH2XGvDF2Xafp5+fwlAflgVg8YPpDeyt 2YB2INVcSV2SQ4QK+l3s/1mkJsnCb/4oNFM1S1XJZcoQTgDspUIivRvIMGmnyb8MtA gAfKNIbHlPCqZkxkaeWLgZOut4vD2Is6QFYgQT1dPDWPRANnM6/r+3jpGLc1Jk57O+ NT4dt2Y9DClOI90lSq5pTomBgUAiIF+UGYVL6qtctGTgFEtvLzJci5FnO7zcIzZggP 2KpZi1W/AHHDZTCqrpIIe3pU7X0fEx/nkcuJNKPiUR3caGd46fvdagTUYJ2lIJTwSv RFdLNw0DkBaYg== Date: Fri, 2 May 2025 13:02:00 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Kurochko cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v3 7/8] xen/common: dom0less: introduce common domain-build.c In-Reply-To: <291544ec45d69a3f0ff79eb6770266a0aa04e77d.1746199009.git.oleksii.kurochko@gmail.com> Message-ID: References: <291544ec45d69a3f0ff79eb6770266a0aa04e77d.1746199009.git.oleksii.kurochko@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 2 May 2025, Oleksii Kurochko wrote: > Some functions of Arm's domain_build.c could be reused by dom0less or other > features connected to domain construction/build. > > The following functions are moved to common: > - get_allocation_size(). > - allocate_domheap_memory(). > - guest_map_pages(). > - allocate_bank_memory(). > - add_hwdom_free_regions(). > - find_unallocated_memory(). > - allocate_memory(). > - dtb_load(). > - initrd_load(). The declaration of allocate_domheap_memory, allocate_bank_memory, allocate_memory were moved in patch #5. Maybe their movement should be in this patch? > > Prototype of dtb_load() and initrd_load() is updated to recieve a pointer > to copy_to_guest_phys() as some archs require > copy_to_guest_phys_fluch_dcache(). > > Update arm/include/asm/Makefile to generate domain-build.h for Arm as it is > used by domain-build.c. > > Signed-off-by: Oleksii Kurochko > --- > Change in v3: > - Nothing changed. Only rebase. > --- > Change in v2: > - Use xen/fdt-domain-build.h instead of asm/domain_build.h. > --- > xen/arch/arm/domain_build.c | 397 +------------------------ > xen/common/device-tree/Makefile | 1 + > xen/common/device-tree/domain-build.c | 404 ++++++++++++++++++++++++++ > xen/include/xen/fdt-domain-build.h | 33 ++- > 4 files changed, 439 insertions(+), 396 deletions(-) > create mode 100644 xen/common/device-tree/domain-build.c > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 9d649b06b3..df29619c40 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -120,18 +120,6 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0) > return vcpu_create(dom0, 0); > } > > -unsigned int __init get_allocation_size(paddr_t size) > -{ > - /* > - * get_order_from_bytes returns the order greater than or equal to > - * the given size, but we need less than or equal. Adding one to > - * the size pushes an evenly aligned size into the next order, so > - * we can then unconditionally subtract 1 from the order which is > - * returned. > - */ > - return get_order_from_bytes(size + 1) - 1; > -} > - > /* > * Insert the given pages into a memory bank, banks are ordered by address. > * > @@ -418,98 +406,6 @@ static void __init allocate_memory_11(struct domain *d, > } > } > > -bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size, > - alloc_domheap_mem_cb cb, void *extra) > -{ > - unsigned int max_order = UINT_MAX; > - > - while ( tot_size > 0 ) > - { > - unsigned int order = get_allocation_size(tot_size); > - struct page_info *pg; > - > - order = min(max_order, order); > - > - pg = alloc_domheap_pages(d, order, 0); > - if ( !pg ) > - { > - /* > - * If we can't allocate one page, then it is unlikely to > - * succeed in the next iteration. So bail out. > - */ > - if ( !order ) > - return false; > - > - /* > - * If we can't allocate memory with order, then it is > - * unlikely to succeed in the next iteration. > - * Record the order - 1 to avoid re-trying. > - */ > - max_order = order - 1; > - continue; > - } > - > - if ( !cb(d, pg, order, extra) ) > - return false; > - > - tot_size -= (1ULL << (PAGE_SHIFT + order)); > - } > - > - return true; > -} > - > -static bool __init guest_map_pages(struct domain *d, struct page_info *pg, > - unsigned int order, void *extra) > -{ > - gfn_t *sgfn = (gfn_t *)extra; > - int res; > - > - BUG_ON(!sgfn); > - res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order); > - if ( res ) > - { > - dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res); > - return false; > - } > - > - *sgfn = gfn_add(*sgfn, 1UL << order); > - > - return true; > -} > - > -bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, > - paddr_t tot_size) > -{ > - struct membanks *mem = kernel_info_get_mem(kinfo); > - struct domain *d = kinfo->d; > - struct membank *bank; > - > - /* > - * allocate_bank_memory can be called with a tot_size of zero for > - * the second memory bank. It is not an error and we can safely > - * avoid creating a zero-size memory bank. > - */ > - if ( tot_size == 0 ) > - return true; > - > - bank = &mem->bank[mem->nr_banks]; > - bank->start = gfn_to_gaddr(sgfn); > - bank->size = tot_size; > - > - /* > - * Allocate pages from the heap until tot_size is zero and map them to the > - * guest using guest_map_pages, passing the starting gfn as extra parameter > - * for the map operation. > - */ > - if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) ) > - return false; > - > - mem->nr_banks++; > - kinfo->unassigned_mem -= bank->size; > - > - return true; > -} > - > /* > * When PCI passthrough is available we want to keep the > * "linux,pci-domain" in sync for every host bridge. > @@ -900,226 +796,6 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, > return 0; > } > > -static int __init add_hwdom_free_regions(unsigned long s_gfn, > - unsigned long e_gfn, void *data) > -{ > - struct membanks *free_regions = data; > - paddr_t start, size; > - paddr_t s = pfn_to_paddr(s_gfn); > - paddr_t e = pfn_to_paddr(e_gfn); > - unsigned int i, j; > - > - if ( free_regions->nr_banks >= free_regions->max_banks ) > - return 0; > - > - /* > - * Both start and size of the free region should be 2MB aligned to > - * potentially allow superpage mapping. > - */ > - start = (s + SZ_2M - 1) & ~(SZ_2M - 1); > - if ( start > e ) > - return 0; > - > - /* > - * e is actually "end-1" because it is called by rangeset functions > - * which are inclusive of the last address. > - */ > - e += 1; > - size = (e - start) & ~(SZ_2M - 1); > - > - /* Find the insert position (descending order). */ > - for ( i = 0; i < free_regions->nr_banks ; i++ ) > - if ( size > free_regions->bank[i].size ) > - break; > - > - /* Move the other banks to make space. */ > - for ( j = free_regions->nr_banks; j > i ; j-- ) > - { > - free_regions->bank[j].start = free_regions->bank[j - 1].start; > - free_regions->bank[j].size = free_regions->bank[j - 1].size; > - } > - > - free_regions->bank[i].start = start; > - free_regions->bank[i].size = size; > - free_regions->nr_banks++; > - > - return 0; > -} > - > -/* > - * Find unused regions of Host address space which can be exposed to domain > - * using the host memory layout. In order to calculate regions we exclude every > - * region passed in mem_banks from the Host RAM. > - */ > -static int __init find_unallocated_memory(const struct kernel_info *kinfo, > - const struct membanks *mem_banks[], > - unsigned int nr_mem_banks, > - struct membanks *free_regions, > - int (*cb)(unsigned long s_gfn, > - unsigned long e_gfn, > - void *data)) > -{ > - const struct membanks *mem = bootinfo_get_mem(); > - struct rangeset *unalloc_mem; > - paddr_t start, end; > - unsigned int i, j; > - int res; > - > - ASSERT(domain_use_host_layout(kinfo->d)); > - > - unalloc_mem = rangeset_new(NULL, NULL, 0); > - if ( !unalloc_mem ) > - return -ENOMEM; > - > - /* Start with all available RAM */ > - for ( i = 0; i < mem->nr_banks; i++ ) > - { > - start = mem->bank[i].start; > - end = mem->bank[i].start + mem->bank[i].size; > - res = rangeset_add_range(unalloc_mem, PFN_DOWN(start), > - PFN_DOWN(end - 1)); > - if ( res ) > - { > - printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n", > - start, end); > - goto out; > - } > - } > - > - /* Remove all regions listed in mem_banks */ > - for ( i = 0; i < nr_mem_banks; i++ ) > - for ( j = 0; j < mem_banks[i]->nr_banks; j++ ) > - { > - start = mem_banks[i]->bank[j].start; > - > - /* Shared memory banks can contain INVALID_PADDR as start */ > - if ( INVALID_PADDR == start ) > - continue; > - > - end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size; > - res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), > - PFN_DOWN(end - 1)); > - if ( res ) > - { > - printk(XENLOG_ERR > - "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n", > - start, end, res); > - goto out; > - } > - } > - > - start = 0; > - end = (1ULL << p2m_ipa_bits) - 1; > - res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end), > - cb, free_regions); > - if ( res ) > - free_regions->nr_banks = 0; > - else if ( !free_regions->nr_banks ) > - res = -ENOENT; > - > -out: > - rangeset_destroy(unalloc_mem); > - > - return res; > -} > - > -void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) > -{ > - struct membanks *mem = kernel_info_get_mem(kinfo); > - unsigned int i, nr_banks = GUEST_RAM_BANKS; > - struct membanks *hwdom_free_mem = NULL; > - > - printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", > - /* Don't want format this as PRIpaddr (16 digit hex) */ > - (unsigned long)(kinfo->unassigned_mem >> 20), d); > - > - mem->nr_banks = 0; > - /* > - * Use host memory layout for hwdom. Only case for this is when LLC coloring > - * is enabled. > - */ > - if ( is_hardware_domain(d) ) > - { > - struct membanks *gnttab = membanks_xzalloc(1, MEMORY); > - /* > - * Exclude the following regions: > - * 1) Remove reserved memory > - * 2) Grant table assigned to hwdom > - */ > - const struct membanks *mem_banks[] = { > - bootinfo_get_reserved_mem(), > - gnttab, > - }; > - > - if ( !gnttab ) > - goto fail; > - > - gnttab->nr_banks = 1; > - gnttab->bank[0].start = kinfo->gnttab_start; > - gnttab->bank[0].size = kinfo->gnttab_size; > - > - hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY); > - if ( !hwdom_free_mem ) > - goto fail; > - > - if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks), > - hwdom_free_mem, add_hwdom_free_regions) ) > - goto fail; > - > - nr_banks = hwdom_free_mem->nr_banks; > - xfree(gnttab); > - } > - > - for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- ) > - { > - paddr_t bank_start, bank_size; > - > - if ( is_hardware_domain(d) ) > - { > - bank_start = hwdom_free_mem->bank[i].start; > - bank_size = hwdom_free_mem->bank[i].size; > - } > - else > - { > - const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; > - const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; > - > - if ( i >= GUEST_RAM_BANKS ) > - goto fail; > - > - bank_start = bankbase[i]; > - bank_size = banksize[i]; > - } > - > - bank_size = MIN(bank_size, kinfo->unassigned_mem); > - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) ) > - goto fail; > - } > - > - if ( kinfo->unassigned_mem ) > - goto fail; > - > - for( i = 0; i < mem->nr_banks; i++ ) > - { > - printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", > - d, > - i, > - mem->bank[i].start, > - mem->bank[i].start + mem->bank[i].size, > - /* Don't want format this as PRIpaddr (16 digit hex) */ > - (unsigned long)(mem->bank[i].size >> 20)); > - } > - > - xfree(hwdom_free_mem); > - return; > - > - fail: > - panic("Failed to allocate requested domain memory." > - /* Don't want format this as PRIpaddr (16 digit hex) */ > - " %ldKB unallocated. Fix the VMs configurations.\n", > - (unsigned long)kinfo->unassigned_mem >> 10); > -} > - > static int __init handle_pci_range(const struct dt_device_node *dev, > uint64_t addr, uint64_t len, void *data) > { > @@ -2059,75 +1735,6 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo) > return -EINVAL; > } > > -static void __init dtb_load(struct kernel_info *kinfo) > -{ > - unsigned long left; > - > - printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", > - kinfo->d, kinfo->dtb_paddr, > - kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt)); > - > - left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr, > - kinfo->fdt, > - fdt_totalsize(kinfo->fdt)); > - > - if ( left != 0 ) > - panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n", > - kinfo->d, left); > - xfree(kinfo->fdt); > -} > - > -static void __init initrd_load(struct kernel_info *kinfo) > -{ > - const struct bootmodule *mod = kinfo->initrd_bootmodule; > - paddr_t load_addr = kinfo->initrd_paddr; > - paddr_t paddr, len; > - int node; > - int res; > - __be32 val[2]; > - __be32 *cellp; > - void __iomem *initrd; > - > - if ( !mod || !mod->size ) > - return; > - > - paddr = mod->start; > - len = mod->size; > - > - printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", > - kinfo->d, paddr, load_addr, load_addr + len); > - > - /* Fix up linux,initrd-start and linux,initrd-end in /chosen */ > - node = fdt_path_offset(kinfo->fdt, "/chosen"); > - if ( node < 0 ) > - panic("Cannot find the /chosen node\n"); > - > - cellp = (__be32 *)val; > - dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr); > - res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start", > - val, sizeof(val)); > - if ( res ) > - panic("Cannot fix up \"linux,initrd-start\" property\n"); > - > - cellp = (__be32 *)val; > - dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len); > - res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end", > - val, sizeof(val)); > - if ( res ) > - panic("Cannot fix up \"linux,initrd-end\" property\n"); > - > - initrd = ioremap_wc(paddr, len); > - if ( !initrd ) > - panic("Unable to map the %pd initrd\n", kinfo->d); > - > - res = copy_to_guest_phys_flush_dcache(kinfo->d, load_addr, > - initrd, len); > - if ( res != 0 ) > - panic("Unable to copy the initrd in the %pd memory\n", kinfo->d); > - > - iounmap(initrd); > -} > - > /* > * Allocate the event channel PPIs and setup the HVM_PARAM_CALLBACK_IRQ. > * The allocated IRQ will be found in d->arch.evtchn_irq. > @@ -2220,8 +1827,8 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo) > */ > kernel_load(kinfo); > /* initrd_load will fix up the fdt, so call it before dtb_load */ > - initrd_load(kinfo); > - dtb_load(kinfo); > + initrd_load(kinfo, copy_to_guest_phys_flush_dcache); > + dtb_load(kinfo, copy_to_guest_phys_flush_dcache); > > memset(regs, 0, sizeof(*regs)); > > diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile > index e88a4d5799..831b91399b 100644 > --- a/xen/common/device-tree/Makefile > +++ b/xen/common/device-tree/Makefile > @@ -1,6 +1,7 @@ > obj-y += bootfdt.init.o > obj-y += bootinfo.init.o > obj-y += device-tree.o > +obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.o > obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o > obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o > obj-y += intc.o > diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c > new file mode 100644 > index 0000000000..69257a15ba > --- /dev/null > +++ b/xen/common/device-tree/domain-build.c > @@ -0,0 +1,404 @@ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size, > + alloc_domheap_mem_cb cb, void *extra) > +{ > + unsigned int max_order = UINT_MAX; > + > + while ( tot_size > 0 ) > + { > + unsigned int order = get_allocation_size(tot_size); > + struct page_info *pg; > + > + order = min(max_order, order); > + > + pg = alloc_domheap_pages(d, order, 0); > + if ( !pg ) > + { > + /* > + * If we can't allocate one page, then it is unlikely to > + * succeed in the next iteration. So bail out. > + */ > + if ( !order ) > + return false; > + > + /* > + * If we can't allocate memory with order, then it is > + * unlikely to succeed in the next iteration. > + * Record the order - 1 to avoid re-trying. > + */ > + max_order = order - 1; > + continue; > + } > + > + if ( !cb(d, pg, order, extra) ) > + return false; > + > + tot_size -= (1ULL << (PAGE_SHIFT + order)); > + } > + > + return true; > +} > + > +static bool __init guest_map_pages(struct domain *d, struct page_info *pg, > + unsigned int order, void *extra) > +{ > + gfn_t *sgfn = (gfn_t *)extra; > + int res; > + > + BUG_ON(!sgfn); > + res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order); > + if ( res ) > + { > + dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res); > + return false; > + } > + > + *sgfn = gfn_add(*sgfn, 1UL << order); > + > + return true; > +} > + > +bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, > + paddr_t tot_size) > +{ > + struct membanks *mem = kernel_info_get_mem(kinfo); > + struct domain *d = kinfo->d; > + struct membank *bank; > + > + /* > + * allocate_bank_memory can be called with a tot_size of zero for > + * the second memory bank. It is not an error and we can safely > + * avoid creating a zero-size memory bank. > + */ > + if ( tot_size == 0 ) > + return true; > + > + bank = &mem->bank[mem->nr_banks]; > + bank->start = gfn_to_gaddr(sgfn); > + bank->size = tot_size; > + > + /* > + * Allocate pages from the heap until tot_size is zero and map them to the > + * guest using guest_map_pages, passing the starting gfn as extra parameter > + * for the map operation. > + */ > + if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) ) > + return false; > + > + mem->nr_banks++; > + kinfo->unassigned_mem -= bank->size; > + > + return true; > +} > + > +static int __init add_hwdom_free_regions(unsigned long s_gfn, > + unsigned long e_gfn, void *data) > +{ > + struct membanks *free_regions = data; > + paddr_t start, size; > + paddr_t s = pfn_to_paddr(s_gfn); > + paddr_t e = pfn_to_paddr(e_gfn); > + unsigned int i, j; > + > + if ( free_regions->nr_banks >= free_regions->max_banks ) > + return 0; > + > + /* > + * Both start and size of the free region should be 2MB aligned to > + * potentially allow superpage mapping. > + */ > + start = (s + SZ_2M - 1) & ~(SZ_2M - 1); > + if ( start > e ) > + return 0; > + > + /* > + * e is actually "end-1" because it is called by rangeset functions > + * which are inclusive of the last address. > + */ > + e += 1; > + size = (e - start) & ~(SZ_2M - 1); > + > + /* Find the insert position (descending order). */ > + for ( i = 0; i < free_regions->nr_banks ; i++ ) > + if ( size > free_regions->bank[i].size ) > + break; > + > + /* Move the other banks to make space. */ > + for ( j = free_regions->nr_banks; j > i ; j-- ) > + { > + free_regions->bank[j].start = free_regions->bank[j - 1].start; > + free_regions->bank[j].size = free_regions->bank[j - 1].size; > + } > + > + free_regions->bank[i].start = start; > + free_regions->bank[i].size = size; > + free_regions->nr_banks++; > + > + return 0; > +} > + > +/* > + * Find unused regions of Host address space which can be exposed to domain > + * using the host memory layout. In order to calculate regions we exclude every > + * region passed in mem_banks from the Host RAM. > + */ > +int __init find_unallocated_memory(const struct kernel_info *kinfo, > + const struct membanks *mem_banks[], > + unsigned int nr_mem_banks, > + struct membanks *free_regions, > + int (*cb)(unsigned long s_gfn, > + unsigned long e_gfn, > + void *data)) > +{ > + const struct membanks *mem = bootinfo_get_mem(); > + struct rangeset *unalloc_mem; > + paddr_t start, end; > + unsigned int i, j; > + int res; > + > + ASSERT(domain_use_host_layout(kinfo->d)); > + > + unalloc_mem = rangeset_new(NULL, NULL, 0); > + if ( !unalloc_mem ) > + return -ENOMEM; > + > + /* Start with all available RAM */ > + for ( i = 0; i < mem->nr_banks; i++ ) > + { > + start = mem->bank[i].start; > + end = mem->bank[i].start + mem->bank[i].size; > + res = rangeset_add_range(unalloc_mem, PFN_DOWN(start), > + PFN_DOWN(end - 1)); > + if ( res ) > + { > + printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n", > + start, end); > + goto out; > + } > + } > + > + /* Remove all regions listed in mem_banks */ > + for ( i = 0; i < nr_mem_banks; i++ ) > + for ( j = 0; j < mem_banks[i]->nr_banks; j++ ) > + { > + start = mem_banks[i]->bank[j].start; > + > + /* Shared memory banks can contain INVALID_PADDR as start */ > + if ( INVALID_PADDR == start ) > + continue; > + > + end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size; > + res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), > + PFN_DOWN(end - 1)); > + if ( res ) > + { > + printk(XENLOG_ERR > + "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n", > + start, end, res); > + goto out; > + } > + } > + > + start = 0; > + end = (1ULL << p2m_ipa_bits) - 1; > + res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end), > + cb, free_regions); > + if ( res ) > + free_regions->nr_banks = 0; > + else if ( !free_regions->nr_banks ) > + res = -ENOENT; > + > +out: > + rangeset_destroy(unalloc_mem); > + > + return res; > +} > + > +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) > +{ > + struct membanks *mem = kernel_info_get_mem(kinfo); > + unsigned int i, nr_banks = GUEST_RAM_BANKS; > + struct membanks *hwdom_free_mem = NULL; > + > + printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", > + /* Don't want format this as PRIpaddr (16 digit hex) */ > + (unsigned long)(kinfo->unassigned_mem >> 20), d); > + > + mem->nr_banks = 0; > + /* > + * Use host memory layout for hwdom. Only case for this is when LLC coloring > + * is enabled. > + */ > + if ( is_hardware_domain(d) ) > + { > + struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1); shouldn't we set gnttab->max_banks and gnttab->type here? > + /* > + * Exclude the following regions: > + * 1) Remove reserved memory > + * 2) Grant table assigned to hwdom > + */ > + const struct membanks *mem_banks[] = { > + bootinfo_get_reserved_mem(), > + gnttab, > + }; > + > + if ( !gnttab ) > + goto fail; > + > + gnttab->nr_banks = 1; > + gnttab->bank[0].start = kinfo->gnttab_start; > + gnttab->bank[0].size = kinfo->gnttab_size; > + > + hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank, > + NR_MEM_BANKS); > + if ( !hwdom_free_mem ) > + goto fail; > + > + hwdom_free_mem->max_banks = NR_MEM_BANKS; here we are missing setting hwdom_free_mem->type ? > + > + if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks), > + hwdom_free_mem, add_hwdom_free_regions) ) > + goto fail; > + > + nr_banks = hwdom_free_mem->nr_banks; > + xfree(gnttab); > + } > + > + for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- ) > + { > + paddr_t bank_start, bank_size; > + > + if ( is_hardware_domain(d) ) > + { > + bank_start = hwdom_free_mem->bank[i].start; > + bank_size = hwdom_free_mem->bank[i].size; > + } > + else > + { > + const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; > + const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; > + > + if ( i >= GUEST_RAM_BANKS ) > + goto fail; > + > + bank_start = bankbase[i]; > + bank_size = banksize[i]; > + } > + > + bank_size = MIN(bank_size, kinfo->unassigned_mem); > + if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) ) > + goto fail; > + } > + > + if ( kinfo->unassigned_mem ) > + goto fail; > + > + for( i = 0; i < mem->nr_banks; i++ ) > + { > + printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", > + d, > + i, > + mem->bank[i].start, > + mem->bank[i].start + mem->bank[i].size, > + /* Don't want format this as PRIpaddr (16 digit hex) */ > + (unsigned long)(mem->bank[i].size >> 20)); > + } > + > + xfree(hwdom_free_mem); > + return; > + > + fail: > + panic("Failed to allocate requested domain memory." > + /* Don't want format this as PRIpaddr (16 digit hex) */ > + " %ldKB unallocated. Fix the VMs configurations.\n", > + (unsigned long)kinfo->unassigned_mem >> 10); > +} > + > +/* Copy data to guest physical address, then clean the region. */ > +typedef unsigned long (*copy_to_guest_phys_cb)(struct domain *d, > + paddr_t gpa, > + void *buf, > + unsigned int len); This shouldn't be needed because copy_to_guest_phys_cb is already declared in xen/include/xen/fdt-domain-build.h > +void __init dtb_load(struct kernel_info *kinfo, > + copy_to_guest_phys_cb copy_to_guest) > +{ > + unsigned long left; > + > + printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", > + kinfo->d, kinfo->dtb_paddr, > + kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt)); > + > + left = copy_to_guest(kinfo->d, kinfo->dtb_paddr, > + kinfo->fdt, > + fdt_totalsize(kinfo->fdt)); > + > + if ( left != 0 ) > + panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n", > + kinfo->d, left); > + xfree(kinfo->fdt); > +} > + > +void __init initrd_load(struct kernel_info *kinfo, > + copy_to_guest_phys_cb copy_to_guest) > +{ > + const struct bootmodule *mod = kinfo->initrd_bootmodule; > + paddr_t load_addr = kinfo->initrd_paddr; > + paddr_t paddr, len; > + int node; > + int res; > + __be32 val[2]; > + __be32 *cellp; > + void __iomem *initrd; > + > + if ( !mod || !mod->size ) > + return; > + > + paddr = mod->start; > + len = mod->size; > + > + printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", > + kinfo->d, paddr, load_addr, load_addr + len); > + > + /* Fix up linux,initrd-start and linux,initrd-end in /chosen */ > + node = fdt_path_offset(kinfo->fdt, "/chosen"); > + if ( node < 0 ) > + panic("Cannot find the /chosen node\n"); > + > + cellp = (__be32 *)val; > + dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr); > + res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start", > + val, sizeof(val)); > + if ( res ) > + panic("Cannot fix up \"linux,initrd-start\" property\n"); > + > + cellp = (__be32 *)val; > + dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len); > + res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end", > + val, sizeof(val)); > + if ( res ) > + panic("Cannot fix up \"linux,initrd-end\" property\n"); > + > + initrd = ioremap_wc(paddr, len); > + if ( !initrd ) > + panic("Unable to map the hwdom initrd\n"); The original message was: panic("Unable to map the %pd initrd\n", kinfo->d); why change it? It can be called for domUs. > + res = copy_to_guest(kinfo->d, load_addr, > + initrd, len); > + if ( res != 0 ) > + panic("Unable to copy the initrd in the hwdom memory\n"); Same here, the original message was: panic("Unable to copy the initrd in the %pd memory\n", kinfo->d); > + iounmap(initrd); > +} > diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h > index b79e9fabfe..4a0052b2e8 100644 > --- a/xen/include/xen/fdt-domain-build.h > +++ b/xen/include/xen/fdt-domain-build.h > @@ -6,6 +6,7 @@ > #include > #include > #include > +#include > #include > > struct domain; > @@ -29,7 +30,37 @@ int make_memory_node(const struct kernel_info *kinfo, int addrcells, > int sizecells, const struct membanks *mem); > int make_timer_node(const struct kernel_info *kinfo); > > -unsigned int get_allocation_size(paddr_t size); > + > +static inline int get_allocation_size(paddr_t size) > +{ > + /* > + * get_order_from_bytes returns the order greater than or equal to > + * the given size, but we need less than or equal. Adding one to > + * the size pushes an evenly aligned size into the next order, so > + * we can then unconditionally subtract 1 from the order which is > + * returned. > + */ > + return get_order_from_bytes(size + 1) - 1; > +} > + > +typedef unsigned long (*copy_to_guest_phys_cb)(struct domain *d, > + paddr_t gpa, > + void *buf, > + unsigned int len); > + > +void initrd_load(struct kernel_info *kinfo, > + copy_to_guest_phys_cb copy_to_guest); > + > +void dtb_load(struct kernel_info *kinfo, > + copy_to_guest_phys_cb copy_to_guest); > + > +int find_unallocated_memory(const struct kernel_info *kinfo, > + const struct membanks *mem_banks[], > + unsigned int nr_mem_banks, > + struct membanks *free_regions, > + int (*cb)(unsigned long s_gfn, > + unsigned long e_gfn, > + void *data)); > > #endif /* __XEN_FDT_DOMAIN_BUILD_H__ */ > > -- > 2.49.0 > From xen-devel-bounces@lists.xenproject.org Fri May 02 20:53:37 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 20:53:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975100.1362771 (Exim 4.92) (envelope-from ) id 1uAxNr-0005cc-0f; Fri, 02 May 2025 20:53:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975100.1362771; Fri, 02 May 2025 20:53: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 1uAxNq-0005cV-Tx; Fri, 02 May 2025 20:53:22 +0000 Received: by outflank-mailman (input) for mailman id 975100; Fri, 02 May 2025 20:53:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAxNo-0005cP-N1 for xen-devel@lists.xenproject.org; Fri, 02 May 2025 20:53:20 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7373ba5e-2797-11f0-9ffb-bf95429c2676; Fri, 02 May 2025 22:53:08 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id ACBB343B5E; Fri, 2 May 2025 20:53:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 669D1C4CEE4; Fri, 2 May 2025 20:53: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" X-Inumbo-ID: 7373ba5e-2797-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746219186; bh=TYiTPg7+cwCysvJq9ufxXjkjog1EvZ7hm7PXauqXECk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=amvBe2va/zay/dCV3fY7xNj7Q6k2YYGOyzWFiAsurGG1lvR55WdigRdiyRIYfRycb 1wSe4Jhuv8B5y6uulA5hshMV4/vPnry++/30/lDRnY3q2CBtZARXcJIQcaf4WBFqn+ uvqbPUquhR/L2lRsib/w9jo9DT6IKQfBr73NoZg/6YN8M2RKD57QEL4LwCBi58tnUo BYVvawZ8FabgP8u3g8qOM4a4rag2/0umCAR2TUP76osxA/Tpe0ltcwdGMKn9rtYiAb UdlyHF+0CSJxoEajuboa4N4wtwwdWVlTxJlLR+qWzw939VsFfezJ4yNeW7XsZNtj36 izjv41rsZQYhQ== Date: Fri, 2 May 2025 13:53:03 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Kurochko cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v3 8/8] xen/common: dom0less: introduce common dom0less-build.c In-Reply-To: <76390ef52f108b580e1c397ed178ceadf1ae53c4.1746199009.git.oleksii.kurochko@gmail.com> Message-ID: References: <76390ef52f108b580e1c397ed178ceadf1ae53c4.1746199009.git.oleksii.kurochko@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 2 May 2025, Oleksii Kurochko wrote: > Part of Arm's dom0less-build.c could be common between architectures which are > using device tree files to create guest domains. Thereby move some parts of > Arm's dom0less-build.c to common code with minor changes. > > As a part of theses changes the following changes are introduced: > - Introduce make_arch_nodes() to cover arch-specific nodes. For example, in > case of Arm, it is PSCI and vpl011 nodes. > - Introduce set_domain_type() to abstract a way how setting of domain type > happens. For example, RISC-V won't have this member of arch_domain structure > as vCPUs will always have the same bitness as hypervisor. In case of Arm, it > is possible that Arm64 could create 32-bit and 64-bit domains. > - Introduce init_vuart() to cover details of virtual uart initialization. > - Introduce init_intc_phandle() to cover some details of interrupt controller > phandle initialization. As an example, RISC-V could have different name for > interrupt controller node ( APLIC, PLIC, IMSIC, etc ) but the code in > domain_handle_dtb_bootmodule() could handle only one interrupt controller > node name. > - s/make_gic_domU_node/make_intc_domU_node as GIC is Arm specific naming and > add prototype of make_intc_domU_node() to dom0less-build.h > > The following functions are moved to xen/common/device-tree: > - Functions which are moved as is: > - domain_p2m_pages(). > - handle_passthrough_prop(). > - handle_prop_pfdt(). > - scan_pfdt_node(). > - check_partial_fdt(). > - Functions which are moved with some minor changes: > - alloc_xenstore_evtchn(): > - ifdef-ing by CONFIG_HVM accesses to hvm.params. > - prepare_dtb_domU(): > - ifdef-ing access to gnttab_{start,size} by CONFIG_GRANT_TABLE. > - s/make_gic_domU_node/make_intc_domU_node. > - Add call of make_arch_nodes(). > - domain_handle_dtb_bootmodule(): > - hide details of interrupt controller phandle initialization by calling > init_intc_phandle(). > - Update the comment above init_intc_phandle(): s/gic/interrupt controller. > - construct_domU(): > - ifdef-ing by CONFIG_HVM accesses to hvm.params. > - Call init_vuart() to hide Arm's vpl011_init() details there. > - Add call of set_domain_type() instead of setting kinfo->arch.type explicitly. > > Some parts of dom0less-build.c are wraped by #ifdef CONFIG_STATIC_{SHMEM,MEMORY} > as not all archs support these configs. > > Signed-off-by: Oleksii Kurochko FYI for a possible follow-up patch (doesn't have to be done in this patch), the following functions could now be static: alloc_dom0_vcpu0 dom0_max_vcpus > --- > Change in v3: > - Align construct_domU() with the current staging. > - Align alloc_xenstore_params() with the current staging. > - Move defintion of XENSTORE_PFN_LATE_ALLOC to common and > declaration of need_xenstore to common. > --- > Change in v2: > - Wrap by #ifdef CONFIG_STATIC_* inclusions of and > . Wrap also the code which uses something from the > mentioned headers. > - Add handling of legacy case in construct_domU(). > - Use xen/fdt-kernel.h and xen/fdt-domain-build.h instead of asm/*. > - Update the commit message. > --- > xen/arch/arm/dom0less-build.c | 714 ++--------------------- > xen/common/device-tree/dom0less-build.c | 699 ++++++++++++++++++++++ > xen/include/asm-generic/dom0less-build.h | 18 +- > 3 files changed, 751 insertions(+), 680 deletions(-) > > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index 0310579863..627c212b3b 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -25,8 +25,6 @@ > #include > #include > > -bool __initdata need_xenstore; > - > #ifdef CONFIG_VGICV2 > static int __init make_gicv2_domU_node(struct kernel_info *kinfo) > { > @@ -152,7 +150,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo) > } > #endif > > -static int __init make_gic_domU_node(struct kernel_info *kinfo) > +int __init make_intc_domU_node(struct kernel_info *kinfo) > { > switch ( kinfo->d->arch.vgic.version ) > { > @@ -218,708 +216,60 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo) > } > #endif > > -/* > - * Scan device tree properties for passthrough specific information. > - * Returns < 0 on error > - * 0 on success > - */ > -static int __init handle_passthrough_prop(struct kernel_info *kinfo, > - const struct fdt_property *xen_reg, > - const struct fdt_property *xen_path, > - bool xen_force, > - uint32_t address_cells, > - uint32_t size_cells) > -{ > - const __be32 *cell; > - unsigned int i, len; > - struct dt_device_node *node; > - int res; > - paddr_t mstart, size, gstart; > - > - /* xen,reg specifies where to map the MMIO region */ > - cell = (const __be32 *)xen_reg->data; > - len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) * > - sizeof(uint32_t)); > - > - for ( i = 0; i < len; i++ ) > - { > - device_tree_get_reg(&cell, address_cells, size_cells, > - &mstart, &size); > - gstart = dt_next_cell(address_cells, &cell); > - > - if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK ) > - { > - printk(XENLOG_ERR > - "DomU passthrough config has not page aligned addresses/sizes\n"); > - return -EINVAL; > - } > - > - res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart), > - paddr_to_pfn(PAGE_ALIGN(mstart + size - 1))); > - if ( res ) > - { > - printk(XENLOG_ERR "Unable to permit to dom%d access to" > - " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n", > - kinfo->d->domain_id, > - mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1); > - return res; > - } > - > - res = map_regions_p2mt(kinfo->d, > - gaddr_to_gfn(gstart), > - PFN_DOWN(size), > - maddr_to_mfn(mstart), > - p2m_mmio_direct_dev); > - if ( res < 0 ) > - { > - printk(XENLOG_ERR > - "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n", > - mstart, gstart); > - return -EFAULT; > - } > - } > - > - /* > - * If xen_force, we let the user assign a MMIO region with no > - * associated path. > - */ > - if ( xen_path == NULL ) > - return xen_force ? 0 : -EINVAL; > - > - /* > - * xen,path specifies the corresponding node in the host DT. > - * Both interrupt mappings and IOMMU settings are based on it, > - * as they are done based on the corresponding host DT node. > - */ > - node = dt_find_node_by_path(xen_path->data); > - if ( node == NULL ) > - { > - printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n", > - xen_path->data); > - return -EINVAL; > - } > - > - res = map_device_irqs_to_domain(kinfo->d, node, true, NULL); > - if ( res < 0 ) > - return res; > - > - res = iommu_add_dt_device(node); > - if ( res < 0 ) > - return res; > - > - /* If xen_force, we allow assignment of devices without IOMMU protection. */ > - if ( xen_force && !dt_device_is_protected(node) ) > - return 0; > - > - return iommu_assign_dt_device(kinfo->d, node); > -} > - > -static int __init handle_prop_pfdt(struct kernel_info *kinfo, > - const void *pfdt, int nodeoff, > - uint32_t address_cells, uint32_t size_cells, > - bool scan_passthrough_prop) > -{ > - void *fdt = kinfo->fdt; > - int propoff, nameoff, res; > - const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL; > - const char *name; > - bool found, xen_force = false; > - > - for ( propoff = fdt_first_property_offset(pfdt, nodeoff); > - propoff >= 0; > - propoff = fdt_next_property_offset(pfdt, propoff) ) > - { > - if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) ) > - return -FDT_ERR_INTERNAL; > - > - found = false; > - nameoff = fdt32_to_cpu(prop->nameoff); > - name = fdt_string(pfdt, nameoff); > - > - if ( scan_passthrough_prop ) > - { > - if ( dt_prop_cmp("xen,reg", name) == 0 ) > - { > - xen_reg = prop; > - found = true; > - } > - else if ( dt_prop_cmp("xen,path", name) == 0 ) > - { > - xen_path = prop; > - found = true; > - } > - else if ( dt_prop_cmp("xen,force-assign-without-iommu", > - name) == 0 ) > - { > - xen_force = true; > - found = true; > - } > - } > - > - /* > - * Copy properties other than the ones above: xen,reg, xen,path, > - * and xen,force-assign-without-iommu. > - */ > - if ( !found ) > - { > - res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len)); > - if ( res ) > - return res; > - } > - } > - > - /* > - * Only handle passthrough properties if both xen,reg and xen,path > - * are present, or if xen,force-assign-without-iommu is specified. > - */ > - if ( xen_reg != NULL && (xen_path != NULL || xen_force) ) > - { > - res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force, > - address_cells, size_cells); > - if ( res < 0 ) > - { > - printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d); > - return res; > - } > - } > - else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) ) > - { > - printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n", > - kinfo->d); > - return -EINVAL; > - } > - > - /* FDT_ERR_NOTFOUND => There is no more properties for this node */ > - return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0; > -} > - > -static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, > - int nodeoff, > - uint32_t address_cells, uint32_t size_cells, > - bool scan_passthrough_prop) > -{ > - int rc = 0; > - void *fdt = kinfo->fdt; > - int node_next; > - > - rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL)); > - if ( rc ) > - return rc; > - > - rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells, > - scan_passthrough_prop); > - if ( rc ) > - return rc; > - > - address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells", > - DT_ROOT_NODE_ADDR_CELLS_DEFAULT); > - size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells", > - DT_ROOT_NODE_SIZE_CELLS_DEFAULT); > - > - node_next = fdt_first_subnode(pfdt, nodeoff); > - while ( node_next > 0 ) > - { > - rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells, > - scan_passthrough_prop); > - if ( rc ) > - return rc; > - > - node_next = fdt_next_subnode(pfdt, node_next); > - } > - > - return fdt_end_node(fdt); > -} > - > -static int __init check_partial_fdt(void *pfdt, size_t size) > +int __init make_arch_nodes(struct kernel_info *kinfo) > { > - int res; > - > - if ( fdt_magic(pfdt) != FDT_MAGIC ) > - { > - dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree"); > - return -EINVAL; > - } > - > - res = fdt_check_header(pfdt); > - if ( res ) > - { > - dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res); > - return -EINVAL; > - } > - > - if ( fdt_totalsize(pfdt) > size ) > - { > - dprintk(XENLOG_ERR, "Partial FDT totalsize is too big"); > - return -EINVAL; > - } > - > - return 0; > -} > - > -static int __init domain_handle_dtb_bootmodule(struct domain *d, > - struct kernel_info *kinfo) > -{ > - void *pfdt; > - int res, node_next; > - > - pfdt = ioremap_cache(kinfo->dtb_bootmodule->start, > - kinfo->dtb_bootmodule->size); > - if ( pfdt == NULL ) > - return -EFAULT; > - > - res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size); > - if ( res < 0 ) > - goto out; > - > - for ( node_next = fdt_first_subnode(pfdt, 0); > - node_next > 0; > - node_next = fdt_next_subnode(pfdt, node_next) ) > - { > - const char *name = fdt_get_name(pfdt, node_next, NULL); > - > - if ( name == NULL ) > - continue; > - > - /* > - * Only scan /gic /aliases /passthrough, ignore the rest. > - * They don't have to be parsed in order. > - * > - * Take the GIC phandle value from the special /gic node in the > - * DTB fragment. > - */ > - if ( dt_node_cmp(name, "gic") == 0 ) > - { > - uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); > - > - if ( phandle_intc != 0 ) > - kinfo->phandle_intc = phandle_intc; > - continue; > - } > - > - if ( dt_node_cmp(name, "aliases") == 0 ) > - { > - res = scan_pfdt_node(kinfo, pfdt, node_next, > - DT_ROOT_NODE_ADDR_CELLS_DEFAULT, > - DT_ROOT_NODE_SIZE_CELLS_DEFAULT, > - false); > - if ( res ) > - goto out; > - continue; > - } > - if ( dt_node_cmp(name, "passthrough") == 0 ) > - { > - res = scan_pfdt_node(kinfo, pfdt, node_next, > - DT_ROOT_NODE_ADDR_CELLS_DEFAULT, > - DT_ROOT_NODE_SIZE_CELLS_DEFAULT, > - true); > - if ( res ) > - goto out; > - continue; > - } > - } > - > - out: > - iounmap(pfdt); > - > - return res; > -} > - > -/* > - * The max size for DT is 2MB. However, the generated DT is small (not including > - * domU passthrough DT nodes whose size we account separately), 4KB are enough > - * for now, but we might have to increase it in the future. > - */ > -#define DOMU_DTB_SIZE 4096 > -static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > -{ > - int addrcells, sizecells; > - int ret, fdt_size = DOMU_DTB_SIZE; > - > - kinfo->phandle_intc = GUEST_PHANDLE_GIC; > - kinfo->gnttab_start = GUEST_GNTTAB_BASE; > - kinfo->gnttab_size = GUEST_GNTTAB_SIZE; > - > - addrcells = GUEST_ROOT_ADDRESS_CELLS; > - sizecells = GUEST_ROOT_SIZE_CELLS; > - > - /* Account for domU passthrough DT size */ > - if ( kinfo->dtb_bootmodule ) > - fdt_size += kinfo->dtb_bootmodule->size; > - > - /* Cap to max DT size if needed */ > - fdt_size = min(fdt_size, SZ_2M); > - > - kinfo->fdt = xmalloc_bytes(fdt_size); > - if ( kinfo->fdt == NULL ) > - return -ENOMEM; > - > - ret = fdt_create(kinfo->fdt, fdt_size); > - if ( ret < 0 ) > - goto err; > - > - ret = fdt_finish_reservemap(kinfo->fdt); > - if ( ret < 0 ) > - goto err; > - > - ret = fdt_begin_node(kinfo->fdt, ""); > - if ( ret < 0 ) > - goto err; > - > - ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells); > - if ( ret ) > - goto err; > - > - ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells); > - if ( ret ) > - goto err; > - > - ret = make_chosen_node(kinfo); > - if ( ret ) > - goto err; > + int ret; > > ret = make_psci_node(kinfo->fdt); > if ( ret ) > - goto err; > - > - ret = make_cpus_node(d, kinfo->fdt); > - if ( ret ) > - goto err; > - > - ret = make_memory_node(kinfo, addrcells, sizecells, > - kernel_info_get_mem(kinfo)); > - if ( ret ) > - goto err; > - > - ret = make_resv_memory_node(kinfo, addrcells, sizecells); > - if ( ret ) > - goto err; > - > - /* > - * domain_handle_dtb_bootmodule has to be called before the rest of > - * the device tree is generated because it depends on the value of > - * the field phandle_intc. > - */ > - if ( kinfo->dtb_bootmodule ) > - { > - ret = domain_handle_dtb_bootmodule(d, kinfo); > - if ( ret ) > - goto err; > - } > - > - ret = make_gic_domU_node(kinfo); > - if ( ret ) > - goto err; > - > - ret = make_timer_node(kinfo); > - if ( ret ) > - goto err; > + return -EINVAL; > > if ( kinfo->vuart ) > { > - ret = -EINVAL; > #ifdef CONFIG_SBSA_VUART_CONSOLE > ret = make_vpl011_uart_node(kinfo); > #endif > if ( ret ) > - goto err; > - } > - > - if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS ) > - { > - ret = make_hypervisor_node(d, kinfo, addrcells, sizecells); > - if ( ret ) > - goto err; > + return -EINVAL; > } > > - ret = fdt_end_node(kinfo->fdt); > - if ( ret < 0 ) > - goto err; > - > - ret = fdt_finish(kinfo->fdt); > - if ( ret < 0 ) > - goto err; > - > return 0; > - > - err: > - printk("Device tree generation failed (%d).\n", ret); > - xfree(kinfo->fdt); > - > - return -EINVAL; > } > > -#define XENSTORE_PFN_OFFSET 1 > -static int __init alloc_xenstore_page(struct domain *d) > +/* TODO: make arch.type generic ? */ > +#ifdef CONFIG_ARM_64 > +void __init set_domain_type(struct domain *d, struct kernel_info *kinfo) > { > - struct page_info *xenstore_pg; > - struct xenstore_domain_interface *interface; > - mfn_t mfn; > - gfn_t gfn; > - int rc; > - > - if ( (UINT_MAX - d->max_pages) < 1 ) > - { > - printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n", > - d); > - return -EINVAL; > - } > - > - d->max_pages += 1; > - xenstore_pg = alloc_domheap_page(d, MEMF_bits(32)); > - if ( xenstore_pg == NULL && is_64bit_domain(d) ) > - xenstore_pg = alloc_domheap_page(d, 0); > - if ( xenstore_pg == NULL ) > - return -ENOMEM; > - > - mfn = page_to_mfn(xenstore_pg); > - if ( !mfn_x(mfn) ) > - return -ENOMEM; > - > - if ( !is_domain_direct_mapped(d) ) > - gfn = gaddr_to_gfn(GUEST_MAGIC_BASE + > - (XENSTORE_PFN_OFFSET << PAGE_SHIFT)); > - else > - gfn = gaddr_to_gfn(mfn_to_maddr(mfn)); > - > - rc = guest_physmap_add_page(d, gfn, mfn, 0); > - if ( rc ) > - { > - free_domheap_page(xenstore_pg); > - return rc; > - } > - > - d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn); > - interface = map_domain_page(mfn); > - interface->connection = XENSTORE_RECONNECT; > - unmap_domain_page(interface); > - > - return 0; > + /* type must be set before allocate memory */ > + d->arch.type = kinfo->arch.type; > } > - > -static int __init alloc_xenstore_params(struct kernel_info *kinfo) > +#else > +void __init set_domain_type(struct domain *d, struct kernel_info *kinfo) > { > - struct domain *d = kinfo->d; > - int rc = 0; > - > - if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY)) > - == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) ) > - d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC; > - else if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE ) > - { > - rc = alloc_xenstore_page(d); > - if ( rc < 0 ) > - return rc; > - } > - > - return rc; > + /* Nothing to do */ > } > +#endif > > -static void __init domain_vcpu_affinity(struct domain *d, > - const struct dt_device_node *node) > +int __init init_vuart(struct domain *d, struct kernel_info *kinfo, > + const struct dt_device_node *node) > { > - struct dt_device_node *np; > - > - dt_for_each_child_node(node, np) > - { > - const char *hard_affinity_str = NULL; > - uint32_t val; > - int rc; > - struct vcpu *v; > - cpumask_t affinity; > - > - if ( !dt_device_is_compatible(np, "xen,vcpu") ) > - continue; > - > - if ( !dt_property_read_u32(np, "id", &val) ) > - panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node)); > - > - if ( val >= d->max_vcpus ) > - panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val, > - dt_node_name(node), d->max_vcpus); > - > - v = d->vcpu[val]; > - rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str); > - if ( rc < 0 ) > - continue; > - > - cpumask_clear(&affinity); > - while ( *hard_affinity_str != '\0' ) > - { > - unsigned int start, end; > - > - start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); > - > - if ( *hard_affinity_str == '-' ) /* Range */ > - { > - hard_affinity_str++; > - end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); > - } > - else /* Single value */ > - end = start; > - > - if ( end >= nr_cpu_ids ) > - panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node)); > - > - for ( ; start <= end; start++ ) > - cpumask_set_cpu(start, &affinity); > - > - if ( *hard_affinity_str == ',' ) > - hard_affinity_str++; > - else if ( *hard_affinity_str != '\0' ) > - break; > - } > + int rc = 0; > > - rc = vcpu_set_hard_affinity(v, &affinity); > - if ( rc ) > - panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n", > - v->vcpu_id, rc, dt_node_name(node)); > - } > -} > + kinfo->vuart = dt_property_read_bool(node, "vpl011"); > > -#ifdef CONFIG_ARCH_PAGING_MEMPOOL > -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. > + * Base address and irq number are needed when creating vpl011 device > + * tree node in prepare_dtb_domU, so initialization on related variables > + * shall be done first. > */ > - unsigned long memkb = 4 * (256 * smp_cpus + (maxmem_kb / 1024) + 128); > - > - BUILD_BUG_ON(PAGE_SIZE != SZ_4K); > - > - return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT); > -} > - > -static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem, > - const struct dt_device_node *node) > -{ > - unsigned long p2m_pages; > - uint32_t p2m_mem_mb; > - int rc; > - > - rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb); > - /* If xen,domain-p2m-mem-mb is not specified, use the default value. */ > - p2m_pages = rc ? > - p2m_mem_mb << (20 - PAGE_SHIFT) : > - domain_p2m_pages(mem, d->max_vcpus); > - > - spin_lock(&d->arch.paging.lock); > - rc = p2m_set_allocation(d, p2m_pages, NULL); > - spin_unlock(&d->arch.paging.lock); > - > - return rc; > -} > -#else /* !CONFIG_ARCH_PAGING_MEMPOOL */ > -static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem, > - const struct dt_device_node *node) > -{ > - return 0; > -} > -#endif /* CONFIG_ARCH_PAGING_MEMPOOL */ > - > -int __init construct_domU(struct domain *d, > - const struct dt_device_node *node) > -{ > - struct kernel_info kinfo = KERNEL_INFO_INIT; > - const char *dom0less_enhanced; > - int rc; > - u64 mem; > - > - rc = dt_property_read_u64(node, "memory", &mem); > - if ( !rc ) > - { > - printk("Error building DomU: cannot read \"memory\" property\n"); > - return -EINVAL; > - } > - kinfo.unassigned_mem = (paddr_t)mem * SZ_1K; > - > - rc = domain_p2m_set_allocation(d, mem, node); > - if ( rc != 0 ) > - return rc; > - > - printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n", > - d->max_vcpus, mem); > - > - kinfo.vuart = dt_property_read_bool(node, "vpl011"); > - if ( kinfo.vuart && is_hardware_domain(d) ) > - panic("hardware domain cannot specify vpl011\n"); > - > - rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced); > - if ( rc == -EILSEQ || > - rc == -ENODATA || > - (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) ) > - { > - need_xenstore = true; > - kinfo.dom0less_feature = DOM0LESS_ENHANCED; > - } > - else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") ) > - { > - need_xenstore = true; > - kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY; > - } > - else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) > - kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS; > - > - if ( vcpu_create(d, 0) == NULL ) > - return -ENOMEM; > - > - d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; > - > - kinfo.d = d; > - > - rc = kernel_probe(&kinfo, node); > - if ( rc < 0 ) > - return rc; > - > -#ifdef CONFIG_ARM_64 > - /* type must be set before allocate memory */ > - d->arch.type = kinfo.arch.type; > -#endif > - if ( is_hardware_domain(d) ) > - { > - rc = construct_hwdom(&kinfo, node); > - if ( rc < 0 ) > - return rc; > - } I think we should retain this chunk in the code movement. It is OK if it is behind a #ifdef CONFIG_ARM. > - else > + if ( kinfo->vuart ) > { > - if ( !dt_find_property(node, "xen,static-mem", NULL) ) > - allocate_memory(d, &kinfo); > - else if ( !is_domain_direct_mapped(d) ) > - allocate_static_memory(d, &kinfo, node); > - else > - assign_static_memory_11(d, &kinfo, node); > - > - rc = process_shm(d, &kinfo, node); > - if ( rc < 0 ) > - return rc; > - > - /* > - * Base address and irq number are needed when creating vpl011 device > - * tree node in prepare_dtb_domU, so initialization on related variables > - * shall be done first. > - */ > - if ( kinfo.vuart ) > - { > - rc = domain_vpl011_init(d, NULL); > - if ( rc < 0 ) > - return rc; > - } > - > - rc = prepare_dtb_domU(d, &kinfo); > - if ( rc < 0 ) > - return rc; > - > - rc = construct_domain(d, &kinfo); > + rc = domain_vpl011_init(d, NULL); > if ( rc < 0 ) > return rc; > } > > - domain_vcpu_affinity(d, node); > - > - return alloc_xenstore_params(&kinfo); > + return rc; > } > > void __init arch_create_domUs(struct dt_device_node *node, > @@ -995,6 +345,22 @@ void __init arch_create_domUs(struct dt_device_node *node, > } > } > > +int __init init_intc_phandle(struct kernel_info *kinfo, const char *name, > + const int node_next, const void *pfdt) > +{ > + if ( dt_node_cmp(name, "gic") == 0 ) > + { > + uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); > + > + if ( phandle_intc != 0 ) > + kinfo->phandle_intc = phandle_intc; > + > + return 0; > + } > + > + return 1; > +} > + > /* > * Local variables: > * mode: C > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c > index a01a8b6b1a..c3face5b90 100644 > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -3,24 +3,43 @@ > #include > #include > #include > +#include > #include > #include > +#include > +#include > #include > #include > +#include > #include > +#include > #include > +#include > #include > #include > #include > +#include > > #include > #include > #include > +#include > > #include > #include > > +#ifdef CONFIG_STATIC_MEMORY > +#include > +#endif #if __has_include ? > +#ifdef CONFIG_STATIC_SHM > +#include > +#endif Same here? > +#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX > + > static domid_t __initdata xs_domid = DOMID_INVALID; > +static bool __initdata need_xenstore; > > void __init set_xs_domain(struct domain *d) > { > @@ -109,6 +128,686 @@ static void __init initialize_domU_xenstore(void) > } > } > > +/* > + * Scan device tree properties for passthrough specific information. > + * Returns < 0 on error > + * 0 on success > + */ > +static int __init handle_passthrough_prop(struct kernel_info *kinfo, > + const struct fdt_property *xen_reg, > + const struct fdt_property *xen_path, > + bool xen_force, > + uint32_t address_cells, > + uint32_t size_cells) > +{ > + const __be32 *cell; > + unsigned int i, len; > + struct dt_device_node *node; > + int res; > + paddr_t mstart, size, gstart; > + > + /* xen,reg specifies where to map the MMIO region */ > + cell = (const __be32 *)xen_reg->data; > + len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) * > + sizeof(uint32_t)); > + > + for ( i = 0; i < len; i++ ) > + { > + device_tree_get_reg(&cell, address_cells, size_cells, > + &mstart, &size); > + gstart = dt_next_cell(address_cells, &cell); > + > + if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK ) > + { > + printk(XENLOG_ERR > + "DomU passthrough config has not page aligned addresses/sizes\n"); > + return -EINVAL; > + } > + > + res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart), > + paddr_to_pfn(PAGE_ALIGN(mstart + size - 1))); > + if ( res ) > + { > + printk(XENLOG_ERR "Unable to permit to dom%d access to" > + " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n", > + kinfo->d->domain_id, > + mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1); > + return res; > + } > + > + res = map_regions_p2mt(kinfo->d, > + gaddr_to_gfn(gstart), > + PFN_DOWN(size), > + maddr_to_mfn(mstart), > + p2m_mmio_direct_dev); > + if ( res < 0 ) > + { > + printk(XENLOG_ERR > + "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n", > + mstart, gstart); > + return -EFAULT; > + } > + } > + > + /* > + * If xen_force, we let the user assign a MMIO region with no > + * associated path. > + */ > + if ( xen_path == NULL ) > + return xen_force ? 0 : -EINVAL; > + > + /* > + * xen,path specifies the corresponding node in the host DT. > + * Both interrupt mappings and IOMMU settings are based on it, > + * as they are done based on the corresponding host DT node. > + */ > + node = dt_find_node_by_path(xen_path->data); > + if ( node == NULL ) > + { > + printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n", > + xen_path->data); > + return -EINVAL; > + } > + > + res = map_device_irqs_to_domain(kinfo->d, node, true, NULL); > + if ( res < 0 ) > + return res; > + > + res = iommu_add_dt_device(node); > + if ( res < 0 ) > + return res; > + > + /* If xen_force, we allow assignment of devices without IOMMU protection. */ > + if ( xen_force && !dt_device_is_protected(node) ) > + return 0; > + > + return iommu_assign_dt_device(kinfo->d, node); > +} > + > +static int __init handle_prop_pfdt(struct kernel_info *kinfo, > + const void *pfdt, int nodeoff, > + uint32_t address_cells, uint32_t size_cells, > + bool scan_passthrough_prop) > +{ > + void *fdt = kinfo->fdt; > + int propoff, nameoff, res; > + const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL; > + const char *name; > + bool found, xen_force = false; > + > + for ( propoff = fdt_first_property_offset(pfdt, nodeoff); > + propoff >= 0; > + propoff = fdt_next_property_offset(pfdt, propoff) ) > + { > + if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) ) > + return -FDT_ERR_INTERNAL; > + > + found = false; > + nameoff = fdt32_to_cpu(prop->nameoff); > + name = fdt_string(pfdt, nameoff); > + > + if ( scan_passthrough_prop ) > + { > + if ( dt_prop_cmp("xen,reg", name) == 0 ) > + { > + xen_reg = prop; > + found = true; > + } > + else if ( dt_prop_cmp("xen,path", name) == 0 ) > + { > + xen_path = prop; > + found = true; > + } > + else if ( dt_prop_cmp("xen,force-assign-without-iommu", > + name) == 0 ) > + { > + xen_force = true; > + found = true; > + } > + } > + > + /* > + * Copy properties other than the ones above: xen,reg, xen,path, > + * and xen,force-assign-without-iommu. > + */ > + if ( !found ) > + { > + res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len)); > + if ( res ) > + return res; > + } > + } > + > + /* > + * Only handle passthrough properties if both xen,reg and xen,path > + * are present, or if xen,force-assign-without-iommu is specified. > + */ > + if ( xen_reg != NULL && (xen_path != NULL || xen_force) ) > + { > + res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force, > + address_cells, size_cells); > + if ( res < 0 ) > + { > + printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d); > + return res; > + } > + } > + else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) ) > + { > + printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n", > + kinfo->d); > + return -EINVAL; > + } > + > + /* FDT_ERR_NOTFOUND => There is no more properties for this node */ > + return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0; > +} > + > +static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, > + int nodeoff, > + uint32_t address_cells, uint32_t size_cells, > + bool scan_passthrough_prop) > +{ > + int rc = 0; > + void *fdt = kinfo->fdt; > + int node_next; > + > + rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL)); > + if ( rc ) > + return rc; > + > + rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells, > + scan_passthrough_prop); > + if ( rc ) > + return rc; > + > + address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells", > + DT_ROOT_NODE_ADDR_CELLS_DEFAULT); > + size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells", > + DT_ROOT_NODE_SIZE_CELLS_DEFAULT); > + > + node_next = fdt_first_subnode(pfdt, nodeoff); > + while ( node_next > 0 ) > + { > + rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells, > + scan_passthrough_prop); > + if ( rc ) > + return rc; > + > + node_next = fdt_next_subnode(pfdt, node_next); > + } > + > + return fdt_end_node(fdt); > +} > + > +static int __init check_partial_fdt(void *pfdt, size_t size) > +{ > + int res; > + > + if ( fdt_magic(pfdt) != FDT_MAGIC ) > + { > + dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree"); > + return -EINVAL; > + } > + > + res = fdt_check_header(pfdt); > + if ( res ) > + { > + dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res); > + return -EINVAL; > + } > + > + if ( fdt_totalsize(pfdt) > size ) > + { > + dprintk(XENLOG_ERR, "Partial FDT totalsize is too big"); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int __init domain_handle_dtb_bootmodule(struct domain *d, > + struct kernel_info *kinfo) > +{ > + void *pfdt; > + int res, node_next; > + > + pfdt = ioremap_cache(kinfo->dtb_bootmodule->start, > + kinfo->dtb_bootmodule->size); > + if ( pfdt == NULL ) > + return -EFAULT; > + > + res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size); > + if ( res < 0 ) > + goto out; > + > + for ( node_next = fdt_first_subnode(pfdt, 0); > + node_next > 0; > + node_next = fdt_next_subnode(pfdt, node_next) ) > + { > + const char *name = fdt_get_name(pfdt, node_next, NULL); > + > + if ( name == NULL ) > + continue; > + > + /* > + * Only scan /$(interrupt_controller) /aliases /passthrough, > + * ignore the rest. > + * They don't have to be parsed in order. > + * > + * Take the interrupt controller phandle value from the special > + * interrupt controller node in the DTB fragment. > + */ > + if ( init_intc_phandle(kinfo, name, node_next, pfdt) == 0 ) > + continue; > + > + if ( dt_node_cmp(name, "aliases") == 0 ) > + { > + res = scan_pfdt_node(kinfo, pfdt, node_next, > + DT_ROOT_NODE_ADDR_CELLS_DEFAULT, > + DT_ROOT_NODE_SIZE_CELLS_DEFAULT, > + false); > + if ( res ) > + goto out; > + continue; > + } > + if ( dt_node_cmp(name, "passthrough") == 0 ) > + { > + res = scan_pfdt_node(kinfo, pfdt, node_next, > + DT_ROOT_NODE_ADDR_CELLS_DEFAULT, > + DT_ROOT_NODE_SIZE_CELLS_DEFAULT, > + true); > + if ( res ) > + goto out; > + continue; > + } > + } > + > + out: > + iounmap(pfdt); > + > + return res; > +} > + > +/* > + * The max size for DT is 2MB. However, the generated DT is small (not including > + * domU passthrough DT nodes whose size we account separately), 4KB are enough > + * for now, but we might have to increase it in the future. > + */ > +#define DOMU_DTB_SIZE 4096 > +static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > +{ > + int addrcells, sizecells; > + int ret, fdt_size = DOMU_DTB_SIZE; > + > + kinfo->phandle_intc = GUEST_PHANDLE_GIC; > + > +#ifdef CONFIG_GRANT_TABLE > + kinfo->gnttab_start = GUEST_GNTTAB_BASE; > + kinfo->gnttab_size = GUEST_GNTTAB_SIZE; > +#endif > + > + addrcells = GUEST_ROOT_ADDRESS_CELLS; > + sizecells = GUEST_ROOT_SIZE_CELLS; > + > + /* Account for domU passthrough DT size */ > + if ( kinfo->dtb_bootmodule ) > + fdt_size += kinfo->dtb_bootmodule->size; > + > + /* Cap to max DT size if needed */ > + fdt_size = min(fdt_size, SZ_2M); > + > + kinfo->fdt = xmalloc_bytes(fdt_size); > + if ( kinfo->fdt == NULL ) > + return -ENOMEM; > + > + ret = fdt_create(kinfo->fdt, fdt_size); > + if ( ret < 0 ) > + goto err; > + > + ret = fdt_finish_reservemap(kinfo->fdt); > + if ( ret < 0 ) > + goto err; > + > + ret = fdt_begin_node(kinfo->fdt, ""); > + if ( ret < 0 ) > + goto err; > + > + ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells); > + if ( ret ) > + goto err; > + > + ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells); > + if ( ret ) > + goto err; > + > + ret = make_chosen_node(kinfo); > + if ( ret ) > + goto err; > + > + ret = make_cpus_node(d, kinfo->fdt); > + if ( ret ) > + goto err; > + > + ret = make_memory_node(kinfo, addrcells, sizecells, > + kernel_info_get_mem(kinfo)); > + if ( ret ) > + goto err; > + > +#ifdef CONFIG_STATIC_SHM This should not be necessary because there is a stub implementation of make_resv_memory_node available in static-shmem.h for the !CONFIG_STATIC_SHM case. > + ret = make_resv_memory_node(kinfo, addrcells, sizecells); > + if ( ret ) > + goto err; > +#endif > + > + /* > + * domain_handle_dtb_bootmodule has to be called before the rest of > + * the device tree is generated because it depends on the value of > + * the field phandle_intc. > + */ > + if ( kinfo->dtb_bootmodule ) > + { > + ret = domain_handle_dtb_bootmodule(d, kinfo); > + if ( ret ) > + goto err; > + } > + > + ret = make_intc_domU_node(kinfo); > + if ( ret ) > + goto err; > + > + ret = make_timer_node(kinfo); > + if ( ret ) > + goto err; > + > + if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS ) > + { > + ret = make_hypervisor_node(d, kinfo, addrcells, sizecells); > + if ( ret ) > + goto err; > + } > + > + ret = make_arch_nodes(kinfo); > + if ( ret ) > + goto err; > + > + ret = fdt_end_node(kinfo->fdt); > + if ( ret < 0 ) > + goto err; > + > + ret = fdt_finish(kinfo->fdt); > + if ( ret < 0 ) > + goto err; > + > + return 0; > + > + err: > + printk("Device tree generation failed (%d).\n", ret); > + xfree(kinfo->fdt); > + > + return -EINVAL; > +} > + > +#define XENSTORE_PFN_OFFSET 1 > +static int __init alloc_xenstore_page(struct domain *d) > +{ > + struct page_info *xenstore_pg; > + struct xenstore_domain_interface *interface; > + mfn_t mfn; > + gfn_t gfn; > + int rc; > + > + if ( (UINT_MAX - d->max_pages) < 1 ) > + { > + printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n", > + d); > + return -EINVAL; > + } > + > + d->max_pages += 1; > + xenstore_pg = alloc_domheap_page(d, MEMF_bits(32)); > + if ( xenstore_pg == NULL && is_64bit_domain(d) ) > + xenstore_pg = alloc_domheap_page(d, 0); > + if ( xenstore_pg == NULL ) > + return -ENOMEM; > + > + mfn = page_to_mfn(xenstore_pg); > + if ( !mfn_x(mfn) ) > + return -ENOMEM; > + > + if ( !is_domain_direct_mapped(d) ) > + gfn = gaddr_to_gfn(GUEST_MAGIC_BASE + > + (XENSTORE_PFN_OFFSET << PAGE_SHIFT)); > + else > + gfn = gaddr_to_gfn(mfn_to_maddr(mfn)); > + > + rc = guest_physmap_add_page(d, gfn, mfn, 0); > + if ( rc ) > + { > + free_domheap_page(xenstore_pg); > + return rc; > + } > + > +#ifdef CONFIG_HVM > + d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn); > +#endif > + interface = map_domain_page(mfn); > + interface->connection = XENSTORE_RECONNECT; > + unmap_domain_page(interface); > + > + return 0; > +} > + > +static int __init alloc_xenstore_params(struct kernel_info *kinfo) > +{ > + struct domain *d = kinfo->d; > + int rc = 0; > + > +#ifdef CONFIG_HVM > + if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY)) > + == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) ) > + d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC; > + else > +#endif > + if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE ) > + { > + rc = alloc_xenstore_page(d); > + if ( rc < 0 ) > + return rc; > + } > + > + return rc; > +} > + > +static void __init domain_vcpu_affinity(struct domain *d, > + const struct dt_device_node *node) > +{ > + struct dt_device_node *np; > + > + dt_for_each_child_node(node, np) > + { > + const char *hard_affinity_str = NULL; > + uint32_t val; > + int rc; > + struct vcpu *v; > + cpumask_t affinity; > + > + if ( !dt_device_is_compatible(np, "xen,vcpu") ) > + continue; > + > + if ( !dt_property_read_u32(np, "id", &val) ) > + panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node)); > + > + if ( val >= d->max_vcpus ) > + panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val, > + dt_node_name(node), d->max_vcpus); > + > + v = d->vcpu[val]; > + rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str); > + if ( rc < 0 ) > + continue; > + > + cpumask_clear(&affinity); > + while ( *hard_affinity_str != '\0' ) > + { > + unsigned int start, end; > + > + start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); > + > + if ( *hard_affinity_str == '-' ) /* Range */ > + { > + hard_affinity_str++; > + end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); > + } > + else /* Single value */ > + end = start; > + > + if ( end >= nr_cpu_ids ) > + panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node)); > + > + for ( ; start <= end; start++ ) > + cpumask_set_cpu(start, &affinity); > + > + if ( *hard_affinity_str == ',' ) > + hard_affinity_str++; > + else if ( *hard_affinity_str != '\0' ) > + break; > + } > + > + rc = vcpu_set_hard_affinity(v, &affinity); > + if ( rc ) > + panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n", > + v->vcpu_id, rc, dt_node_name(node)); > + } > +} > + > +#ifdef CONFIG_ARCH_PAGING_MEMPOOL > +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); > + > + BUILD_BUG_ON(PAGE_SIZE != SZ_4K); > + > + return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT); > +} > + > +static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem, > + const struct dt_device_node *node) > +{ > + unsigned long p2m_pages; > + uint32_t p2m_mem_mb; > + int rc; > + > + rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb); > + /* If xen,domain-p2m-mem-mb is not specified, use the default value. */ > + p2m_pages = rc ? > + p2m_mem_mb << (20 - PAGE_SHIFT) : > + domain_p2m_pages(mem, d->max_vcpus); > + > + spin_lock(&d->arch.paging.lock); > + rc = p2m_set_allocation(d, p2m_pages, NULL); > + spin_unlock(&d->arch.paging.lock); > + > + return rc; > +} > +#else /* !CONFIG_ARCH_PAGING_MEMPOOL */ > +static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem, > + const struct dt_device_node *node) > +{ > + return 0; > +} > +#endif /* CONFIG_ARCH_PAGING_MEMPOOL */ > + > +static int __init construct_domU(struct domain *d, > + const struct dt_device_node *node) > +{ > + struct kernel_info kinfo = KERNEL_INFO_INIT; > + const char *dom0less_enhanced; > + int rc; > + u64 mem; > + > + rc = dt_property_read_u64(node, "memory", &mem); > + if ( !rc ) > + { > + printk("Error building DomU: cannot read \"memory\" property\n"); > + return -EINVAL; > + } > + kinfo.unassigned_mem = (paddr_t)mem * SZ_1K; > + > + rc = domain_p2m_set_allocation(d, mem, node); > + if ( rc != 0 ) > + return rc; > + > + printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n", > + d->max_vcpus, mem); > + > + rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced); > + if ( rc == -EILSEQ || > + rc == -ENODATA || > + (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) ) > + { > + need_xenstore = true; > + kinfo.dom0less_feature = DOM0LESS_ENHANCED; > + } > + else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") ) > + { > + need_xenstore = true; > + kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY; > + } > + else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) > + kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS; > + > + if ( vcpu_create(d, 0) == NULL ) > + return -ENOMEM; > + > + d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; > + > + kinfo.d = d; > + > + rc = kernel_probe(&kinfo, node); > + if ( rc < 0 ) > + return rc; > + > + set_domain_type(d, &kinfo); > + > + if ( !dt_find_property(node, "xen,static-mem", NULL) ) > + allocate_memory(d, &kinfo); > +#ifdef CONFIG_STATIC_MEMORY Also this should not be needed thanks to the stub implementation of allocate_static_memory and assign_static_memory_11 > + else if ( !is_domain_direct_mapped(d) ) > + allocate_static_memory(d, &kinfo, node); > + else > + assign_static_memory_11(d, &kinfo, node); > +#endif > + > +#ifdef CONFIG_STATIC_SHM There is a stub for process_shm too > + rc = process_shm(d, &kinfo, node); > + if ( rc < 0 ) > + return rc; > +#endif > + > + rc = init_vuart(d, &kinfo, node); > + if ( rc < 0 ) > + return rc; > + > + rc = prepare_dtb_domU(d, &kinfo); > + if ( rc < 0 ) > + return rc; > + > + rc = construct_domain(d, &kinfo); > + if ( rc < 0 ) > + return rc; > + > + domain_vcpu_affinity(d, node); > + > + return alloc_xenstore_params(&kinfo); > +} > + > void __init create_domUs(void) > { > struct dt_device_node *node; > diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h > index f095135caa..c00bb853d6 100644 > --- a/xen/include/asm-generic/dom0less-build.h > +++ b/xen/include/asm-generic/dom0less-build.h > @@ -11,10 +11,7 @@ > > struct domain; > struct dt_device_node; > - > -/* TODO: remove both when construct_domU() will be moved to common. */ > -#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX > -extern bool need_xenstore; > +struct kernel_info; > > /* > * List of possible features for dom0less domUs > @@ -48,12 +45,21 @@ void create_domUs(void); > bool is_dom0less_mode(void); > void set_xs_domain(struct domain *d); > > -int construct_domU(struct domain *d, const struct dt_device_node *node); > - > void arch_create_domUs(struct dt_device_node *node, > struct xen_domctl_createdomain *d_cfg, > unsigned int flags); > > +int init_vuart(struct domain *d, struct kernel_info *kinfo, > + const struct dt_device_node *node); > + > +int make_intc_domU_node(struct kernel_info *kinfo); > +int make_arch_nodes(struct kernel_info *kinfo); > + > +void set_domain_type(struct domain *d, struct kernel_info *kinfo); > + > +int init_intc_phandle(struct kernel_info *kinfo, const char *name, > + const int node_next, const void *pfdt); > + > #else /* !CONFIG_DOM0LESS_BOOT */ > > static inline void create_domUs(void) {} > -- > 2.49.0 > From xen-devel-bounces@lists.xenproject.org Fri May 02 20:55:23 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 20:55:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975113.1362781 (Exim 4.92) (envelope-from ) id 1uAxPl-0006BW-FX; Fri, 02 May 2025 20:55:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975113.1362781; Fri, 02 May 2025 20: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 1uAxPl-0006BP-BW; Fri, 02 May 2025 20:55:21 +0000 Received: by outflank-mailman (input) for mailman id 975113; Fri, 02 May 2025 20:55:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAxPk-0006BH-3c for xen-devel@lists.xenproject.org; Fri, 02 May 2025 20:55:20 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c1027303-2797-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 22:55:18 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id E1756A41176; Fri, 2 May 2025 20:49:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4797C4CEE9; Fri, 2 May 2025 20:55: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" X-Inumbo-ID: c1027303-2797-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746219317; bh=yvqgNLHetnyrzYoipfCXgahI3TfB5nKfX9qRpLs/EgE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=EnBVaZ0762L85xHCoehtbGnoiTTAmZP+G64xR9syVmVdhHW2plwqnfW2uT8bYJno1 NCIVTmD1LgIZWWyvbie9aIns/ANX2wYdh6MWZXInhA8h9u1IJjk0Vjo/v96yR0Ek1V BwbV9mdnyfxjF0TQCnb6BTIEOmOsi0IIgrFcXl67RJeXfFk1UP/LZrlKHWh+UVS6Sg UMwM/GndIzp2S4/KC4gx9o9e/2nTygEv0YHwEqDj1NfZI07IOzCZe2m1zJDCfqneGK mGV8yjIdCYya8S5kQ2ZIRch2rvgV+Uuq2S4bIqkkn6iZsikO4BTIX7LF+bSsUgSmxB RLF7nh1HGoHxA== Date: Fri, 2 May 2025 13:55:14 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Kurochko cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v3 5/8] asm-generic: move some parts of Arm's domain_build.h to common In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 2 May 2025, Oleksii Kurochko wrote: > Nothing changed. Only some functions declaration are moved to xen/include/ > headers as they are expected to be used by common code of domain builing > or dom0less. > > Signed-off-by: Oleksii Kurochko > --- > Chnages in v3: > - Drop inclusion of from xen/fdt-domain-build.h. > - Add empty line after license tag in xen/fdt-domain-build.h. > --- > Chnages in v2: > - Add missed declaration of construct_hwdom(). > - Drop unnessary blank line. > - Introduce xen/fdt-domain-build.h and move parts of Arm's domain_build.h to > it. > - Update the commit message. > --- > xen/arch/arm/acpi/domain_build.c | 1 + > xen/arch/arm/dom0less-build.c | 1 + > xen/arch/arm/domain_build.c | 1 + > xen/arch/arm/include/asm/domain_build.h | 21 ++---------- > xen/arch/arm/kernel.c | 1 + > xen/arch/arm/static-shmem.c | 1 + > xen/include/xen/fdt-domain-build.h | 43 +++++++++++++++++++++++++ > 7 files changed, 51 insertions(+), 18 deletions(-) > create mode 100644 xen/include/xen/fdt-domain-build.h > > diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c > index f9ca8b47e5..1c3555d814 100644 > --- a/xen/arch/arm/acpi/domain_build.c > +++ b/xen/arch/arm/acpi/domain_build.c > @@ -10,6 +10,7 @@ > */ > > #include > +#include > #include > #include > #include > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index 7eecd06d44..0310579863 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -1,6 +1,7 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > #include > #include > +#include > #include > #include > #include > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 8c7a054718..9d649b06b3 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -1,6 +1,7 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > #include > #include > +#include > #include > #include > #include > diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h > index df1c0fe301..397e408a1f 100644 > --- a/xen/arch/arm/include/asm/domain_build.h > +++ b/xen/arch/arm/include/asm/domain_build.h > @@ -5,28 +5,13 @@ > #include > > typedef __be32 gic_interrupt_t[3]; > -typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg, > - unsigned int order, void *extra); > -bool allocate_domheap_memory(struct domain *d, paddr_t tot_size, > - alloc_domheap_mem_cb cb, void *extra); > -bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, > - paddr_t tot_size); > -void allocate_memory(struct domain *d, struct kernel_info *kinfo); > -int construct_domain(struct domain *d, struct kernel_info *kinfo); > -int construct_hwdom(struct kernel_info *kinfo, > - const struct dt_device_node *node); > + > int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit); > -int make_chosen_node(const struct kernel_info *kinfo); > -int make_cpus_node(const struct domain *d, void *fdt); > -int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo, > - int addrcells, int sizecells); > -int make_memory_node(const struct kernel_info *kinfo, int addrcells, > - int sizecells, const struct membanks *mem); > int make_psci_node(void *fdt); > -int make_timer_node(const struct kernel_info *kinfo); > void evtchn_allocate(struct domain *d); > > -unsigned int get_allocation_size(paddr_t size); > +int construct_hwdom(struct kernel_info *kinfo, > + const struct dt_device_node *node); At the end of the series construct_hwdom is only called from within xen/arch/arm/domain_build.c, so it could be made static and removed from here. However, one of my review comments was that I think we should still call construct_hwdom from xen/common/device-tree/dom0less-build.c. So I think we should keep it. > /* > * Helper to write an interrupts with the GIC format > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c > index f00fc388db..5759a3470a 100644 > --- a/xen/arch/arm/kernel.c > +++ b/xen/arch/arm/kernel.c > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c > index 14ae48fb1e..1f8441d920 100644 > --- a/xen/arch/arm/static-shmem.c > +++ b/xen/arch/arm/static-shmem.c > @@ -1,6 +1,7 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > > #include > +#include > #include > #include > #include > diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h > new file mode 100644 > index 0000000000..b79e9fabfe > --- /dev/null > +++ b/xen/include/xen/fdt-domain-build.h > @@ -0,0 +1,43 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#ifndef __XEN_FDT_DOMAIN_BUILD_H__ > +#define __XEN_FDT_DOMAIN_BUILD_H__ > + > +#include > +#include > +#include > +#include > + > +struct domain; > +struct page_info; > +struct membanks; > + > +typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg, > + unsigned int order, void *extra); > +bool allocate_domheap_memory(struct domain *d, paddr_t tot_size, > + alloc_domheap_mem_cb cb, void *extra); > + > +bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, > + paddr_t tot_size); > +void allocate_memory(struct domain *d, struct kernel_info *kinfo); > +int construct_domain(struct domain *d, struct kernel_info *kinfo); > +int make_chosen_node(const struct kernel_info *kinfo); > +int make_cpus_node(const struct domain *d, void *fdt); > +int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo, > + int addrcells, int sizecells); > +int make_memory_node(const struct kernel_info *kinfo, int addrcells, > + int sizecells, const struct membanks *mem); > +int make_timer_node(const struct kernel_info *kinfo); > + > +unsigned int get_allocation_size(paddr_t size); Many of these functions are not actually moved until later patches. It would be best to move the declaration at the time the function is also moved. But if that is difficult for any reason, this is also OK. > +#endif /* __XEN_FDT_DOMAIN_BUILD_H__ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > -- > 2.49.0 > From xen-devel-bounces@lists.xenproject.org Fri May 02 21:50:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 21:50:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975132.1362791 (Exim 4.92) (envelope-from ) id 1uAyHE-00060y-A5; Fri, 02 May 2025 21:50:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975132.1362791; Fri, 02 May 2025 21:50: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 1uAyHE-00060r-74; Fri, 02 May 2025 21:50:36 +0000 Received: by outflank-mailman (input) for mailman id 975132; Fri, 02 May 2025 21:50:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAyHC-0005xo-G7 for xen-devel@lists.xenproject.org; Fri, 02 May 2025 21:50:34 +0000 Received: from gmmr-4.centrum.cz (gmmr-4.centrum.cz [2a00:da80:1:502::8]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7878e348-279f-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 23:50:32 +0200 (CEST) Received: from gmmr-4.centrum.cz (localhost [127.0.0.1]) by gmmr-4.centrum.cz (Postfix) with ESMTP id 6C83940EF for ; Fri, 2 May 2025 23:50:31 +0200 (CEST) Received: from antispam37.centrum.cz (antispam37.cent [10.30.208.37]) by gmmr-4.centrum.cz (Postfix) with ESMTP id 6B1AF2013AD5 for ; Fri, 2 May 2025 23:50:31 +0200 (CEST) Received: from unknown (HELO gm-smtp11.centrum.cz) ([46.255.227.75]) by antispam37.centrum.cz with ESMTP; 02 May 2025 23:50:30 +0200 Received: from localhost.localdomain (ip-213-220-240-96.bb.vodafone.cz [213.220.240.96]) (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 gm-smtp11.centrum.cz (Postfix) with ESMTPSA id A6B10100AE2B1; Fri, 2 May 2025 23:50: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" X-Inumbo-ID: 7878e348-279f-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atlas.cz; s=mail; t=1746222631; bh=YX4Z2wu6WHT3TtCNBsRPyrED6BoxUocx7yjmUHbO4Lc=; h=From:To:Cc:Subject:Date:From; b=mTIZrZnTyoC2e4DzNJx5iPmanoexOD0yIeM2wpdxurZGamNtSFNiVAUE3yPZMoNiJ MJJY94pudIam/c1fmgOb8X9ie+iWx60k2hzZrCHjN/GVr+Qi2+0Dx0hieG7iYfFWsy sn/lRExmy8cgEtVYwxHlOnygk1/9Zaxcj0nuJkjw= X-CSE-ConnectionGUID: m3Nda2qKRzKp4czMMOyS5A== X-CSE-MsgGUID: AeKj+rjyTSmA+YeG1zR4ZQ== X-ThreatScanner-Verdict: Negative X-IPAS-Result: =?us-ascii?q?A2H5AAB0PRVo/0vj/y5aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQAmBSoM0DYFlCYRMpB2BIIxJDwEBAQEBAQEBAQk9FAQBAQMEN?= =?us-ascii?q?wEGhDgKizsnOBMBAgQBAQEBAwIDAQEBAQEBAQEBDQEBBgEBAQEBAQYGAQKBH?= =?us-ascii?q?YU1Rg2CYgGBJIEmAQEBAQEBAQEBAQEBHQINgScPAUYoDQImAl8SgwIBgi8BN?= =?us-ascii?q?BQGsw+BMhoCZdxwAoEjZIEjBoEbLgGITwGEfHAbhR6CDYQOb4EFAYFEgkaDD?= =?us-ascii?q?oJpBIItRD4UkwiLI0iBBRwDWSwBVRMNCgsHBYFpAyoLDAsSHBVuMx2CD4Ufg?= =?us-ascii?q?g+CBIkOhE0tT4UxgSpHQAMLGA1IESw3FBsGPQFuB5VSg2yBDiyBBROUULMvh?= =?us-ascii?q?CWETodLlTIaHhWXUx4DkmWZACKLa4F5lkaEaYF+gX8zIjCDIhIBPxmOR4h8u?= =?us-ascii?q?iZ2AgE5AgcBCgEBAwmCO44CgUsBAQ?= IronPort-PHdr: A9a23:SOfZfhbvAG9kXqFy8mYEnET/LTEt1oqcDmcuAnoPtbtCf+yZ8oj4O wSHvLMx1wWPBd2Qsa0f1rSempujcFJDyK7JiGoFfp1IWk1NouQttCtkLei7TGbWF7rUVRE8B 9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUhrwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9I Ri4swndrNUajZdtJqovyBbErHtFduVLzm50OFyfmArx6ci38JN/6Spbpugv99RHUaX0fqQ4S aJXATE7OG0r58PlqAfOQxKX6nUTSmsZnQNEDhbK4h/nRpv+vTf0ueR72CmBIM35Vqs0Vii47 6dqUxDnliEKPCMk/W7Ni8xwiKVboA+9pxF63oXZbp2ZOOZ4c6jAZt4RW3ZPUdhNWCxAGoO8b pUAD+wdPeZDsoLxo0ICoQaiCQWwAe/izCJDiH3r0q0gy+kvER/I0RI9EdwAs3raq9r6O7sdX +2u0KnFzi/OY+9M1Dvh6oXFdA0qr/GWXbJ3dMrc0VMhGB3ZjlWKtIfqMCma1uITtmiY8uFtU vigi3Qkqw5rpzig3N0sh5LTiYIJzlDL7z55zJwpKty5UUN2Z8OvH5RMuS+ALYR2Xt8iTH9yu CY80rAKp561ciYFxpg62xLSdv+KfpWG7B/gSOqfITV1iWxhdby/mhu8/ketx+7/W8SozVpHq jZIn8XCu3wR2BLe98mKR/1g9Umv3jaP0hrc6uBCIU0slqrUNYQhwrgumZoXq0jDGTX2mErwg aSLdUsk4vCl5uvmb7n8uJORN495hhvgPqgwmMGzG+Y1PwgWU2SF5Oix2qfv8VPnTLlWlPE6j KbUvIzAKckfp6O0BRJe3Jw55BalFTim1cwVnXwALF1YZh2Kl5PpO1TSIPDgCve/nkisnC9rx //YOr3hBY3ALnfGkLv4ZrZ97lJcyBIuwdxC/Z5bFq8OIPTvWk/rqdzYCwU1PBC1wur/CdV90 J0RWX6XD6KWMa7eq0GE6+IvLuWWeoMZpjTwJ+In6vPulXM5nEUSfait3ZsZcnC4GfFmLl2Db nr2gdcOC2IKsRAkTOHxklKCTTpTaGypX64m+j46CZqqDZ3fSYC1nLyBwCC7E4VMZmFGEF+MF 23kd5+DW/gXdi2SONNhkicfWLe7UY8h0AuiuxP9y7piNubU4DEXtYr/1Nhp4O3ejQs99SZ3D 8uH1mGCVXt0k3gSSD8q2KBwu1d9xk2f3ql5m/BYD8Bc5+tVUgcmMp7R1+N7BtPzVw/afdeGV kymQtO4DjE1VN4xxMUOY0llF9W4kh/DxzaqA6MSl7GTAJw086Tc32X+JspkznbG0bIsj1o4Q sRVKWKmhbRz9w/JB47Gi0mZjbqldbwA3C7R82eO1XCBvEJAUA51SqjFWXEfZk3LrdX2/0/CQ biuCakhMgRc08GCNqpKatrvjVlcQ/fjItveb3qrm2isHRaI2q+MbI3ydmQSwirdDlEInB0N8 naYKwc+Ajyso2bfDDx1CVLveFng8OZgp3O9Vk801QaKb09/2LWp5h4Zn/ucS+kc3r4coicut y10HEqh39LRE9ePuhBufLtdYdwg+1pHz3zWuBF9PpO6M6BunEIRcwNyv0/2zRV4Fp1AkdQ2r HMt1AdyLaOY0FVcdzKXxJzwOaPYKnP0/B+xb67bwU/e0NmI9acV8vg4qEvsvBuvFkU893Vry d5V02GT5saCMA1HVZP3T1Zy8h1SpK/TaSp74JnbkTVoMK+ponrB1sgvCe8N1BmtZZFcPbmCG Qu0FNcVVOa0L+l/o1W1dFo6Nebx9+ZgNtmlfv6PwoaiIOJph3StnzIUs8hGzkuQ+n8kGabz1 JEfzqTdh1PfPwo= IronPort-Data: A9a23:ZRNwXq70WSJdbAup7e76YgxRtM7GchMFZxGqfqrLsTDasY5as4F+v jQdWT2OPPnYYWShedp3YIu38khX7ZbTm4IyHgJlrS5kZn8b8sCt6fZ1j6vT04F+CuWZESqLO u1HMoGowPgcFyKa+1H0dOC88BGQ7InQLpLkEunIJyttcgFtTSYlmHpLlvUw6mJSqYHR7zil5 5Wr/qUzBHf/g2Qpaj9MsfrZwP9SlK2aVA0w7wFWic9j4we2e0k9VPo3Oay3Jn3kdYhYdsbSb /rD1ryw4lTC9B4rDN6/+p6jGqHdauO60aCm0xK6aoD66vRwjnVaPpUTaJLwXXxqZwChxLid/ v0W7MDtFl15VkH7sL91vxFwS0mSNEDdkVPNCSDXXce7lyUqf5ZwqhnH4Y5f0YAwo45K7W9yG fMwLWsrYhnZnsGM0pGjFuJ+o+EEPfK2FdZK0p1g5Wmx4fcOTpWGWKDW/YYBmjw9gNxUAPOYb NhxhThHMEqGOUASfA1NV9RhwY9EhVGmG9FcgFuPpqMy6nL7xRB12aOrO8i9ltmiHJ0Oxx3F/ T2fl4j/KjgXF97c0ziUzkmpr6z+kAyiSrhOJoTto5aGh3XWnAT/EiY+T0qyp7+jjUSzQc5EA 0UO/2wlqq1a3EWxTdD4VgeQqWKAtwVaUMg4O/1qtimOx7DS7gLfAXILJhZFado7pIozQBQpy FaCnJXuHzMHmLSWUXe18raSsCP3Ny8IK2MLeS4DS00C+daLiJE+iFfDQ8huFIaxj8bpAnfgz jaSti88ir4Py8kR2M2T8VnZgj6EvJXFTgcpoA7QWwqN6gJ/eZ7gZIGy71XfxehPIZzfTVSbu nUA3c+E44gmFo2EniiAaPsCEavv5PufNjDYx1l1EPEcGy+FpyDlJ90NpmskewE2b67oZAPUX aMagisJjLc7AZdgRfUfj16ZYyjy8ZXdKA== IronPort-HdrOrdr: A9a23:juBlLKMTlAGubcBcTtCjsMiBIKoaSvp037Dk7SxMoHtuA6mlfq GV7ZYmPHDP5gr5NEtLpTniAtjifZq/z/9ICOAqVN/IYOCMggSVxe9ZgLcKuweBJxHD X-Talos-CUID: 9a23:D+Iz1mOs8xwLWe5DXXJB+EdOA+MfYF7FkHzCBmqfGF00YejA X-Talos-MUID: =?us-ascii?q?9a23=3ArFljWw25Exhfum1n9yc06o7XrzUjyqmNCgMXk4Q?= =?us-ascii?q?6gMytdh19FG6PtmiFe9py?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="6.15,257,1739833200"; d="scan'208";a="103135371" From: =?UTF-8?q?Petr=20Van=C4=9Bk?= To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: David Hildenbrand , Andrew Morton , Ryan Roberts , xen-devel@lists.xenproject.org, x86@kernel.org, stable@vger.kernel.org, =?UTF-8?q?Petr=20Van=C4=9Bk?= Subject: [PATCH v2 0/1] mm: Xen PV regression after THP PTE optimization Date: Fri, 2 May 2025 23:50:18 +0200 Message-ID: <20250502215019.822-1-arkamar@atlas.cz> X-Mailer: git-send-email 2.48.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi all, I recently discovered an mm regression introduced in kernel version 6.9 that affects systems running as a Xen PV domain [1]. Original fix proposal wasn't ideal, but it sparked a discussion which helped us fully understand the root cause. The new v2 patch contains changes based on David Hildenbrand's proposal to cap max_nr to the number of PFNs that actually remain in the folio and to clean up the loop. Thanks, Petr [1] https://lore.kernel.org/lkml/20250429142237.22138-1-arkamar@atlas.cz Petr Vaněk (1): mm: fix folio_pte_batch() on XEN PV mm/internal.h | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-) -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Fri May 02 21:50:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 21:50:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975133.1362801 (Exim 4.92) (envelope-from ) id 1uAyHF-0006EY-GS; Fri, 02 May 2025 21:50:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975133.1362801; Fri, 02 May 2025 21:50: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 1uAyHF-0006ER-DW; Fri, 02 May 2025 21:50:37 +0000 Received: by outflank-mailman (input) for mailman id 975133; Fri, 02 May 2025 21:50:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAyHE-0005xo-0C for xen-devel@lists.xenproject.org; Fri, 02 May 2025 21:50:36 +0000 Received: from gmmr-2.centrum.cz (gmmr-2.centrum.cz [46.255.227.203]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7a2914dc-279f-11f0-9eb4-5ba50f476ded; Fri, 02 May 2025 23:50:35 +0200 (CEST) Received: from gmmr-2.centrum.cz (localhost [127.0.0.1]) by gmmr-2.centrum.cz (Postfix) with ESMTP id 027C82025F8E for ; Fri, 2 May 2025 23:50:35 +0200 (CEST) Received: from antispam36.centrum.cz (antispam36.cent [10.30.208.36]) by gmmr-2.centrum.cz (Postfix) with ESMTP id 00D8520258BE for ; Fri, 2 May 2025 23:50:35 +0200 (CEST) Received: from unknown (HELO gm-smtp11.centrum.cz) ([46.255.227.75]) by antispam36.centrum.cz with ESMTP; 02 May 2025 23:50:34 +0200 Received: from localhost.localdomain (ip-213-220-240-96.bb.vodafone.cz [213.220.240.96]) (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 gm-smtp11.centrum.cz (Postfix) with ESMTPSA id 13CC1100AE2B1; Fri, 2 May 2025 23:50: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" X-Inumbo-ID: 7a2914dc-279f-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atlas.cz; s=mail; t=1746222635; bh=ozFHTCk4j8th6UsxDGZ1WDBrNh7xmpTX2eWy7wAljlo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=L4FEM3JGIrnZUMEfaDNN4lLtq3jG8CBtt9p2l3PNZSJhiv8qfCVMpHfR0bbsIh/JV Id4I8Iug9fwqPWBYNZoi7HS9gPAQQ6SANhY+20NvRJzaRmMg5sccXIQfab35WiXC1l uXVI7Xgk2j4V/tCgnd88IUEXzI5j/x6NyAK2fE3Q= X-CSE-ConnectionGUID: 5OJCA9afS+OGGX4cGo5iwQ== X-CSE-MsgGUID: qonAHIxLSja2i0+mAlbagQ== X-ThreatScanner-Verdict: Negative X-IPAS-Result: =?us-ascii?q?A2EzAAB0PRVo/0vj/y5aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQFACYFKgzSBcoRVkXGLeYYzi3+Bag8BAQEBAQEBAQEJU?= =?us-ascii?q?QQBAT+ESAKLOSc4EwECBAEBAQEDAgMBAQEBAQEBAQENAQEGAQEBAQEBBgYBA?= =?us-ascii?q?oEdhTVTgmIBhAAGIwQLAUYQGA0CJgICVgcSgwKCMAEDMbMpfzMaAmXccAJJB?= =?us-ascii?q?VVkgSmBGy4BiE8BhHxwhHdCgg2EB3aEGw6DdYJpBIMvFIQthDOBQ4NegmeCI?= =?us-ascii?q?IsjSIEFHANZLAFVEw0KCwcFgWkDKgsMCxIcFW4zHYIPhR+CD4IEiQ6ETS1Ph?= =?us-ascii?q?TGBKkdAAwsYDUgRLDcUGwY9AW4HlVKDZQcBYypDCXhmk2qQB6BjgQeBPoQlh?= =?us-ascii?q?E6cfRoeFZdTHgOSZS6HZZBtIqNzN4RpgX6BfzMiMIMiUhnRaXY8AgcBCgEBA?= =?us-ascii?q?wmCO41PM4FLAQE?= IronPort-PHdr: A9a23:Y0vQYBcFz/vqoLQ3dKYCiZoUlGM+k9jLVj580XLHo4xHfqnrxZn+J kuXvawr0ASTG92DoKgb0LeI+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHROOjNwjQAcWuURYHG t9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3wOgVvO+v6BJPZgdip2OCu4Z3TZBhDiCagbb9oI xi7oxvdutMKjYd+Jao91BnEr3VIdulX2GhlOU+dkxHg68i/+5Ju7z5esO87+c5aVqX6caU4T bhGAzkjLms4+s7luwTdQAWW/ncSXX0YnRVRDwXb4x/0Q4/9vSTmuOVz3imaJtD2QqsvWTu+9 adrSQTnhzkBOjUk7WzYkM1wjKZcoBK8uxxyxpPfbY+JOPZieK7WYMgXTnRdUMlPSyNBA5u8b 4oRAOoHIeZYtJT2q18XoRejGQWgGObjxzlVjXH0wKI6yfwsHwHY0gE+AtwAvnfaotL3O6ccX u+60KbGwC7fb/5Vwzrx9JLFfgwjrPyKQLl+cdDRyU4qFw7dlFuft5DlPymI3esCqWeb6fRlV eGygGMgsQ5xuDuvyd0piobTnIIY0UrL9Tl9wIkvPt20UlJ0YN+9HZZWqiqVOJd4TNk4TGF0p CY11KcGuZijcSQX1JgqyB7RZ+GDfoaI/x/uSOafLzh3iX9meb+yiBm//0ijx+DiWce501RHo yREn9TMuX0Byh/e58qGR/dg/Uqs3yuE2QPL6uxcLk05lLDXJ4Ahz7MwjJYfr1rPEy3slEj0j KKablso9vWm5uj9fLnquIOQO5VqhgzxLqgigMiyDOU+PwMTRWaU4/6826fm/UDhRbVKieA5n bfBvZDBIMQbura5AwhI0oY/8xq/Dymp0NAfnXQfI1JFfQuLj5PsO1HSOPD0EOqzj06wnzh1w fDGIqfhAojILnTZjLjgfK5x609ayAUt0dBS/51ZB7AbLP7tWkL8tMbUAgEnPwG22erqCtVw2 psbWW2VA6+ZNK3SsUWP5uIqO+SDfpUVuDXnJPgg/fHul2Q0lkUBfamtx5QXc2q0EehnIkmBe 3rjns8BEXsWvgo5VOHqkl2DXiRVZ3qoRaI84So0B5y8DYffXYCgm6aO3D2+HpFMem9GDVWMH W/yd4qYQ/cMdD6SIsh5nzMeT7ihSJUu1RS0uw/g0LdoNPbU+ikCupL4ztR6++zSmQko9TNoF 8Sdz32NT2Zsk2IHRDI73btyoU9jxVeZ16h3nfhYGcZU5/NTXQc2LYTcwPBiC9DuRgLBec+ES FKnQtWgHDEwQcs9w9oLY0tmGNWikArM0DapA7MPkLyLHpM0/rrG33ftP8Z912rG1K45glY8Q ctPLWimi7V79wjSAY7JjkqYm7+kdaQbwS7N8nqMwnCSvEFZVw5wV7/JXXcFZkvZtdj5/F/NT 6eyCbQ7NQtM0cGDJbVMatHwkFpJWunjN8raY2+qn2ewBA2Ixq+XbIbwdGQSwiPdCFAekwAU/ 3aJKxQxBju7r2LZFjxuGkrjY1nw/ulmtHO7Ukg0whmXYEJ7ybq1+wMaiOeGS/wNw70EuD0uq yluEFmh2NLWDsKMpxB9c6VEfdM9/FBH2Hrdtwx8OJygMq9jikcdcwtppUPu0Qt4CoFbnMg0o 3Ml0hByJbib0FxfbTOY247/OrnNJmn15hCvZP2e5laL1NeQ57dK7fEQqEvqtwLvEVAttz1j0 t9Iwz6f64/MAQ46T538SAA0+gJ8qrWcZTMytK3O0ng5CaSoqHf80tSKB6NxwwyjdtJWKouNC Av7CIsRFZ79e6QRh1G1Y0dcb6hp/6kuMpbjLqPesJM= IronPort-Data: A9a23:EEiIx6qbBnVAyP7+dphWhKp2FPpeBmLuZBIvgKrLsJaIsI4StFCzt garIBmPaayDazOjc49+bonk/BsA7ZLTzdNlHQdopXpnHy5D+ePIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkjk7wdOWn9D8kiPzgqoPUUIbsIjp2SRJvVBAvgBdin/9RqoNziLBVOSvU0 T/Ji5OZYQLNNwJcaDpOtvre8Ek35pwehRtB1rAATaEW1LPhvyZNZH4vDfnZB2f1RIBSAtm7S 47rpJml/nnU9gsaEdislLD2aCUiGtY+6iDT4pb+c/HKbilq/kTe4I5iXBYvQRs/ZwGyojxE4 I4lWaqYEl51Y/KWyIzxZDEDe812FfUuFLYquhFTu+TLp6HNWyOEL/mDkCjalGDXkwp6KTgmy BAWFNwCRk2kpcmfkbu1capLqesTcMLEO94epUg1mFk1Dd5+KXzCa6rPoMRdwC9p34ZFEPDCf dccLzF9BPjCS0ERfA1KVdRkxrju2SSXnz5w8Tp5oYI++WvayQVr+LHxNNPOPNeYLSlQth/B9 jiXpD6jU3n2MvSGzjys0lO8otTNlHn6AMEXPbmy//FT1Qj7Kms7TUd+uUGAieOog0j4QdVVJ lYI4QInt610/0uuJvH0RR6xpXeelhcAX9NLVeYogCmdmvT84AuDAGUACDlbZ7QOsM4wWCxv0 1qhnM3gDj8pt6eaIVqU9a+RhTezPzUFaGEFeCkIRBcE5N+lp5s85jrfQ9AmHKOrg9ndHTDr3 yvMvCU4n68Uj8MAy+O851+vqz6luJnFZhQ46gXeQiSu6QYRTIqkYZG4rFvW9/BNKK6HQVSb+ nsJgc6T6KYJF57lvDeRSe8JEZm36Pufdj7Rm1hiG98m7TvFxpK4VdwOpmsjeQEzaJlCJmKBj FLvhD69LaR7ZBOCBZKbqaroYyj25cAMzejYa80= IronPort-HdrOrdr: A9a23:jGD9paHeST9gu3fKpLqE5ceALOsnbusQ8zAXPo5KJSC9Ffbo8P xG/c5rsSMc5wx+ZJhNo7q90ey7MBDhHP1OkOws1NWZPTUO0VHAROpfBMnZsl/d8kbFmdK1u5 0MT0EHMr3NMWQ= X-Talos-CUID: =?us-ascii?q?9a23=3AX0yZnmvMULluB+31Nv6Q1w6K6It4VV/25SbZLXT?= =?us-ascii?q?7LklGeOGeZljN+bxdxp8=3D?= X-Talos-MUID: 9a23:b/dQSATKcsKi3LnZRXT1gzdLFOZ4x5+sARoMydYDks2OPCNJbmI= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="6.15,257,1739833200"; d="scan'208";a="118293229" From: =?UTF-8?q?Petr=20Van=C4=9Bk?= To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: David Hildenbrand , Andrew Morton , Ryan Roberts , xen-devel@lists.xenproject.org, x86@kernel.org, stable@vger.kernel.org, =?UTF-8?q?Petr=20Van=C4=9Bk?= Subject: [PATCH v2 1/1] mm: fix folio_pte_batch() on XEN PV Date: Fri, 2 May 2025 23:50:19 +0200 Message-ID: <20250502215019.822-2-arkamar@atlas.cz> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250502215019.822-1-arkamar@atlas.cz> References: <20250502215019.822-1-arkamar@atlas.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On XEN PV, folio_pte_batch() can incorrectly batch beyond the end of a folio due to a corner case in pte_advance_pfn(). Specifically, when the PFN following the folio maps to an invalidated MFN, expected_pte = pte_advance_pfn(expected_pte, nr); produces a pte_none(). If the actual next PTE in memory is also pte_none(), the pte_same() succeeds, if (!pte_same(pte, expected_pte)) break; the loop is not broken, and batching continues into unrelated memory. For example, with a 4-page folio, the PTE layout might look like this: [ 53.465673] [ T2552] folio_pte_batch: printing PTE values at addr=0x7f1ac9dc5000 [ 53.465674] [ T2552] PTE[453] = 000000010085c125 [ 53.465679] [ T2552] PTE[454] = 000000010085d125 [ 53.465682] [ T2552] PTE[455] = 000000010085e125 [ 53.465684] [ T2552] PTE[456] = 000000010085f125 [ 53.465686] [ T2552] PTE[457] = 0000000000000000 <-- not present [ 53.465689] [ T2552] PTE[458] = 0000000101da7125 pte_advance_pfn(PTE[456]) returns a pte_none() due to invalid PFN->MFN mapping. The next actual PTE (PTE[457]) is also pte_none(), so the loop continues and includes PTE[457] in the batch, resulting in 5 batched entries for a 4-page folio. This triggers the following warning: [ 53.465751] [ T2552] page: refcount:85 mapcount:20 mapping:ffff88813ff4f6a8 index:0x110 pfn:0x10085c [ 53.465754] [ T2552] head: order:2 mapcount:80 entire_mapcount:0 nr_pages_mapped:4 pincount:0 [ 53.465756] [ T2552] memcg:ffff888003573000 [ 53.465758] [ T2552] aops:0xffffffff8226fd20 ino:82467c dentry name(?):"libc.so.6" [ 53.465761] [ T2552] flags: 0x2000000000416c(referenced|uptodate|lru|active|private|head|node=0|zone=2) [ 53.465764] [ T2552] raw: 002000000000416c ffffea0004021f08 ffffea0004021908 ffff88813ff4f6a8 [ 53.465767] [ T2552] raw: 0000000000000110 ffff888133d8bd40 0000005500000013 ffff888003573000 [ 53.465768] [ T2552] head: 002000000000416c ffffea0004021f08 ffffea0004021908 ffff88813ff4f6a8 [ 53.465770] [ T2552] head: 0000000000000110 ffff888133d8bd40 0000005500000013 ffff888003573000 [ 53.465772] [ T2552] head: 0020000000000202 ffffea0004021701 000000040000004f 00000000ffffffff [ 53.465774] [ T2552] head: 0000000300000003 8000000300000002 0000000000000013 0000000000000004 [ 53.465775] [ T2552] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1), const struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *: (struct folio *)_compound_head(page + nr_pages - 1))) != folio) Original code works as expected everywhere, except on XEN PV, where pte_advance_pfn() can yield a pte_none() after balloon inflation due to MFNs invalidation. In XEN, pte_advance_pfn() ends up calling __pte()->xen_make_pte()->pte_pfn_to_mfn(), which returns pte_none() when mfn == INVALID_P2M_ENTRY. The pte_pfn_to_mfn() documents that nastiness: If there's no mfn for the pfn, then just create an empty non-present pte. Unfortunately this loses information about the original pfn, so pte_mfn_to_pfn is asymmetric. While such hacks should certainly be removed, we can do better in folio_pte_batch() and simply check ahead of time how many PTEs we can possibly batch in our folio. This way, we can not only fix the issue but cleanup the code: removing the pte_pfn() check inside the loop body and avoiding end_ptr comparison + arithmetic. Fixes: f8d937761d65 ("mm/memory: optimize fork() with PTE-mapped THP") Cc: stable@vger.kernel.org Co-developed-by: David Hildenbrand Signed-off-by: David Hildenbrand Signed-off-by: Petr Vaněk --- mm/internal.h | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/mm/internal.h b/mm/internal.h index e9695baa5922..25a29872c634 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -248,11 +248,9 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr, pte_t *start_ptep, pte_t pte, int max_nr, fpb_t flags, bool *any_writable, bool *any_young, bool *any_dirty) { - unsigned long folio_end_pfn = folio_pfn(folio) + folio_nr_pages(folio); - const pte_t *end_ptep = start_ptep + max_nr; pte_t expected_pte, *ptep; bool writable, young, dirty; - int nr; + int nr, cur_nr; if (any_writable) *any_writable = false; @@ -265,11 +263,15 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr, VM_WARN_ON_FOLIO(!folio_test_large(folio) || max_nr < 1, folio); VM_WARN_ON_FOLIO(page_folio(pfn_to_page(pte_pfn(pte))) != folio, folio); + /* Limit max_nr to the actual remaining PFNs in the folio we could batch. */ + max_nr = min_t(unsigned long, max_nr, + folio_pfn(folio) + folio_nr_pages(folio) - pte_pfn(pte)); + nr = pte_batch_hint(start_ptep, pte); expected_pte = __pte_batch_clear_ignored(pte_advance_pfn(pte, nr), flags); ptep = start_ptep + nr; - while (ptep < end_ptep) { + while (nr < max_nr) { pte = ptep_get(ptep); if (any_writable) writable = !!pte_write(pte); @@ -282,14 +284,6 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr, if (!pte_same(pte, expected_pte)) break; - /* - * Stop immediately once we reached the end of the folio. In - * corner cases the next PFN might fall into a different - * folio. - */ - if (pte_pfn(pte) >= folio_end_pfn) - break; - if (any_writable) *any_writable |= writable; if (any_young) @@ -297,12 +291,13 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr, if (any_dirty) *any_dirty |= dirty; - nr = pte_batch_hint(ptep, pte); - expected_pte = pte_advance_pfn(expected_pte, nr); - ptep += nr; + cur_nr = pte_batch_hint(ptep, pte); + expected_pte = pte_advance_pfn(expected_pte, cur_nr); + ptep += cur_nr; + nr += cur_nr; } - return min(ptep - start_ptep, max_nr); + return min(nr, max_nr); } /** -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Fri May 02 23:36:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 23:36:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975166.1362821 (Exim 4.92) (envelope-from ) id 1uAzw1-0004JO-Un; Fri, 02 May 2025 23:36:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975166.1362821; Fri, 02 May 2025 23:36: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 1uAzw1-0004JH-SE; Fri, 02 May 2025 23:36:49 +0000 Received: by outflank-mailman (input) for mailman id 975166; Fri, 02 May 2025 23:36:48 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAzw0-0004Ip-0D for xen-devel@lists.xenproject.org; Fri, 02 May 2025 23:36:48 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20621.outbound.protection.outlook.com [2a01:111:f403:2009::621]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4a1f2335-27ae-11f0-9eb4-5ba50f476ded; Sat, 03 May 2025 01:36:38 +0200 (CEST) Received: from BYAPR07CA0078.namprd07.prod.outlook.com (2603:10b6:a03:12b::19) by DS0PR12MB7726.namprd12.prod.outlook.com (2603:10b6:8:130::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.25; Fri, 2 May 2025 23:36:31 +0000 Received: from MWH0EPF000A6730.namprd04.prod.outlook.com (2603:10b6:a03:12b:cafe::60) by BYAPR07CA0078.outlook.office365.com (2603:10b6:a03:12b::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.24 via Frontend Transport; Fri, 2 May 2025 23:36:31 +0000 Received: from SATLEXMB03.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_128_GCM_SHA256) id 15.20.8699.20 via Frontend Transport; Fri, 2 May 2025 23:36:30 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 2 May 2025 18:36:29 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 2 May 2025 18:36:29 -0500 Received: from xsjstefanos51.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Fri, 2 May 2025 18:36: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" X-Inumbo-ID: 4a1f2335-27ae-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VPMME8bWtV4NQgCxx7X0TEKnn2MM0PB7EInuyu1qXHin5Ss39Q5PCQlksepmpYzEHHDVumI5THRoWLwewzalPfQH+4h/E5ZVUvFA/1gu6YduqixJvH0THz+vOdUZcBEkGx5M8IpAdlQL0178jDgHC6NuMC3/c+rDkH3/nAFCrpHu/1XDg47cPmRDLB9A65kKOlD79QunNyP8UcJbGk87AMEobGJslUyLQ04TobTFaNCFSLD9V1uc1o5NUMP/OOA6IANj7lT+p9eG+blFeOMlw4ogK622mrKcGRztSV8vasLo2dL3HWQR/ywkmGfsB9VeG6n9Br5J/idq+JRQ2mtGvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ebXre62h4E4lEtLtAl/1GAQOY4fnih00pEn1pTR/SJo=; b=qZ698n0XnmfORsZXKXg3Z0I2RywnBKkv2n3u0A3dsPnY6lMqIwo16EFJT0Ta532VjzhV1s7kDZQZUilcH9ADliBpYtJK4j9ZBWoI+Q+RAfUp69Unxsj6CWnujIY1UOs9yn33ScO0VTUU9hqAm7CRiWtzMO2KXWnBsUhCOYwcaU5BTiDVzCPPWA8K6f4zi/JXfyraztyQ0DdwVllYwqdFpOV6BzGVTZCpI4nGWfC6laLDFdyPxmiO9TxNy+GENz9NO08A8Jpgswm04WYNLdV7UnXoJIqh5bdA64sRu6SgYdspdXQjCi/HrRQgj6GLdgCqCurL6NFTscEPPlb1TacRQA== 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=ebXre62h4E4lEtLtAl/1GAQOY4fnih00pEn1pTR/SJo=; b=bJ5uMZrLmmv0SxFGJPyxqL6CX3Nx5yYZUNuOMNUhme7AoJ7Hm2tn13jMkIKosCHjxM83I7Sdkl7AbOYxtcCMiiolbjfVplnpRWOQFnDLIkJf+VYVVpQl4geveeSdTMjc0iU+yOUWo+Iln6m0W32apiBB1VXP2G+43AxYNBwH6aM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: To: CC: Nicola Vetrini , Federico Serafini , Victor Lira , "Andrew Cooper" , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano Stabellini" , Bertrand Marquis Subject: [PATCH v2 1/2] x86: x86_emulate: address violations of MISRA C Rule 19.1 Date: Fri, 2 May 2025 16:35:34 -0700 Message-ID: <20250502233535.3532279-1-victorm.lira@amd.com> X-Mailer: git-send-email 2.47.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Received-SPF: None (SATLEXMB05.amd.com: victorm.lira@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000A6730:EE_|DS0PR12MB7726:EE_ X-MS-Office365-Filtering-Correlation-Id: 7d10714d-e92b-4cb8-4925-08dd89d22aa7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|82310400026|7416014|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?5SZFrjy7wseBRU5Y28Rt0+Lp/BeDRDx+Xpui1S+bfreTGssOoAn54irpAVJl?= =?us-ascii?Q?Ob685e6nC9RZkt77BrQSKIyNGuH86UPasBsbNTK5a14PY50qE18jG53updDe?= =?us-ascii?Q?LL8NoYrXMPm8x0aTJBYhPxv7a4u+oUZwSVz3lZ2mRNbYf59oRL9YFdFJGuQ4?= =?us-ascii?Q?4qxXYKUUL+eTSmQm1/jYQUlanLe58Q8LFP2hq8GyRztbjWGdTPjJoeHOpPdc?= =?us-ascii?Q?jkSC8NjDRTpsHT4sBY9pRRvO3cpF09wRbPkXK/1NXy/LgKaUuxXbozLszugh?= =?us-ascii?Q?3PwpQYcU63JjFdgyefzXJth0zrXk0ngB+KN1BEOD2dq/qMeXdeP7BayAzPnV?= =?us-ascii?Q?IPl0sU7tOYZy34EcOYN9atfb8sR58NG21KxSIBFtTl2t0ryMeecBynLISLJ3?= =?us-ascii?Q?SWfsQrkVOglFAwyubTep5NoM3ONuyVhCTuSsLScRx6y2dxS5dJqs0ZlOEk1W?= =?us-ascii?Q?vU/2I6FzkHggyfnOPSDKYciqfG3YY8Gt5gI7HEAXTA2rg9bFgOm/az2uvod+?= =?us-ascii?Q?rOc6VcLW66wk9zB6qrVlGDeigA3mP80tOu3U4u1hVfldLkW3alQxlGIi2Wwn?= =?us-ascii?Q?CP2F2Nvq12NkTuMoyO7vBhVX1AnWOj+IidUtJHf9v56EGs4fVYrSDqWlGiWo?= =?us-ascii?Q?BvCPUhFsnegVGPmYWFYo7K8ncWeCzX/FHj6S1+qEe2tFo1IsZoFN/etdtP0I?= =?us-ascii?Q?pVQ7a9XrZl/hbuFomh8ZNCeuQry8X0wxg1LNNxnKcwwyGxmLAP15CWx6dfw5?= =?us-ascii?Q?jgCgUAvuO8MDqI0Yp+ZWXojpoAQxT1L734idxVBoUVUNAJt9SFbxED9O4Toi?= =?us-ascii?Q?pZMtG0qi4a1GcUlr5/iyJGDldVsCN89XJxgHVs6gwm6PVSJGx2+XSGKPH+vD?= =?us-ascii?Q?nDmN0rnm3yRA2c1cJKmrxQ+IfC1kUhyCjK176/TSetIAV2qcyHt4MAIIRmSV?= =?us-ascii?Q?GwkyiPF6qysKrEEENb2PjMDWHEA7M04ImeJBNLoPYXW6WMOi9suDRQFe/bfI?= =?us-ascii?Q?kvk5hIplAvVQqtRArLLAh0ondyjBgrULI74cZ+FDMyBQTIK4YkAcAaan0qFo?= =?us-ascii?Q?tUFWv7Cn5S2DLW4/4ya+/d/wfiyWNQjIVyHaigzfoGTjQ48awzI2p9WAOOve?= =?us-ascii?Q?p7vBYN7/wPLYE80FCav22ql2GGyPAqMk6e5kMFpk9rJDDj8SlConP8Bs5xm/?= =?us-ascii?Q?8o2VjUIhIhDMsoPRM+liWyc5CmdbVF97oC1AUzg27G0mqudAARYojrKyZQQu?= =?us-ascii?Q?CbuVVLqkpNU+VpD69UD/IHD037xXCjeayUgaJsYqYYUmr5STNhqLm0Ty+BMF?= =?us-ascii?Q?ymhrFf6PFpnFLOmugHqDLbpagMelAc8wa7MPaqJHm2Xwt+fzyarbpbD2Sopf?= =?us-ascii?Q?Cm2b1dpCuT+CxdrjUVaaWryv2yqUD5gVfjzGWBgk3rmgXlVf53ngZwxPZts7?= =?us-ascii?Q?0BdF62EguyiT3TDIZtb/bS2tzjHXfD8satlosuyd6gK82EdqEw3NaTnKLvAW?= =?us-ascii?Q?xa5Xofm6HQoSUWlRpCmvjBBAJfXyJB4lpVW2?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(7416014)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2025 23:36:30.6770 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7d10714d-e92b-4cb8-4925-08dd89d22aa7 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=[SATLEXMB03.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: DS0PR12MB7726 From: Nicola Vetrini =0D Rule 19.1 states: "An object shall not be assigned or copied=0D to an overlapping object". In the function like macro "get_rep_prefix",=0D one member of a union is assigned the value of another member. Reading from= one=0D member and writing to the other violates the rule, while not causing Undefi= ned=0D Behavior due to their relative sizes. Instead, use casts combined with exac= tly=0D overlapping accesses to address violations.=0D =0D No functional change.=0D =0D Signed-off-by: Nicola Vetrini =0D Signed-off-by: Federico Serafini =0D Signed-off-by: Victor Lira =0D ---=0D Changes in v2:=0D - Use casts combined with exactly overlapping accesses to address=0D violations=0D - fix commit message=0D ---=0D Cc: Andrew Cooper =0D Cc: Anthony PERARD =0D Cc: Michal Orzel =0D Cc: Jan Beulich =0D Cc: Julien Grall =0D Cc: Roger Pau Monn=C3=A9 =0D Cc: Stefano Stabellini =0D Cc: Nicola Vetrini =0D Cc: Federico Serafini =0D Cc: Bertrand Marquis =0D ---=0D xen/arch/x86/x86_emulate/x86_emulate.c | 6 +++---=0D 1 file changed, 3 insertions(+), 3 deletions(-)=0D =0D diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emul= ate/x86_emulate.c=0D index 8e14ebb35b..d678855238 100644=0D --- a/xen/arch/x86/x86_emulate/x86_emulate.c=0D +++ b/xen/arch/x86/x86_emulate/x86_emulate.c=0D @@ -527,8 +527,8 @@ static inline void put_loop_count(=0D if ( !amd_like(ctxt) && mode_64bit() && ad_bytes =3D=3D 4 ) = \=0D { \= =0D _regs.r(cx) =3D 0; = \=0D - if ( extend_si ) _regs.r(si) =3D _regs.esi; = \=0D - if ( extend_di ) _regs.r(di) =3D _regs.edi; = \=0D + if ( extend_si ) _regs.r(si) =3D (uint32_t)_regs.r(si); = \=0D + if ( extend_di ) _regs.r(di) =3D (uint32_t)_regs.r(di); = \=0D } \= =0D goto complete_insn; \= =0D } \= =0D @@ -2029,7 +2029,7 @@ x86_emulate(=0D switch ( op_bytes )=0D {=0D case 2: _regs.ax =3D (int8_t)_regs.ax; break; /* cbw */=0D - case 4: _regs.r(ax) =3D (uint32_t)(int16_t)_regs.ax; break; /* cwd= e */=0D + case 4: _regs.r(ax) =3D (uint32_t)(int16_t)_regs.r(ax); break; /* = cwde */=0D case 8: _regs.r(ax) =3D (int32_t)_regs.r(ax); break; /* cdqe */=0D }=0D break;=0D --=0D 2.25.1=0D From xen-devel-bounces@lists.xenproject.org Fri May 02 23:36:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 23:36:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975165.1362811 (Exim 4.92) (envelope-from ) id 1uAzvx-00044w-Oh; Fri, 02 May 2025 23:36:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975165.1362811; Fri, 02 May 2025 23: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 1uAzvx-00044p-Lu; Fri, 02 May 2025 23:36:45 +0000 Received: by outflank-mailman (input) for mailman id 975165; Fri, 02 May 2025 23:36:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uAzvv-00044g-Sz for xen-devel@lists.xenproject.org; Fri, 02 May 2025 23:36:44 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2060a.outbound.protection.outlook.com [2a01:111:f403:2412::60a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4934c938-27ae-11f0-9ffb-bf95429c2676; Sat, 03 May 2025 01:36:37 +0200 (CEST) Received: from CH5P220CA0011.NAMP220.PROD.OUTLOOK.COM (2603:10b6:610:1ef::6) by CH3PR12MB8458.namprd12.prod.outlook.com (2603:10b6:610:155::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Fri, 2 May 2025 23:36:31 +0000 Received: from CH2PEPF0000009E.namprd02.prod.outlook.com (2603:10b6:610:1ef:cafe::b0) by CH5P220CA0011.outlook.office365.com (2603:10b6:610:1ef::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.24 via Frontend Transport; Fri, 2 May 2025 23:36:31 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH2PEPF0000009E.mail.protection.outlook.com (10.167.244.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8699.20 via Frontend Transport; Fri, 2 May 2025 23:36:31 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 2 May 2025 18:36:30 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 2 May 2025 18:36:30 -0500 Received: from xsjstefanos51.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Fri, 2 May 2025 18:36: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" X-Inumbo-ID: 4934c938-27ae-11f0-9ffb-bf95429c2676 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NNQC7lzdHXfn8QCHXpSMeqlimZ08VRbiuND9Qj5mIa4G2zQwBurhl1NLWA3e+bQidoyyHyZLrfGc93SNhTOKw6MxmoGtjlgwINJ8xmhA7BCtFLQ2U01hjJMZfQM5SpBsZfJgCWq+Vv/8bf+SHCDX6hTsWUIckGxu80BVY2ZA2TOB+bcTdepvdtA44q6GWp4k8aRCQIFhhe/1ySvK/XPsDQYmQTHBItP/p5FmW2MfWFVOzy68f15HDTZ3qGsqnz5CAzfkh+4oNKbhxj5TgTYh9W6SFy0hsma2qIXlq0ZR8+hKZA5m+Tb28WUfUOcewiavaEl04XtTUTb0EozYgFnjXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tDhSAjxu89amv5bVNg7tPY7ct3hZuS2WDDY759go5Ck=; b=iWVNv9kIE2gaIwf2GjT2ViPazFFR4yc2iZnjJdFnvfDoWfDW+dVF7b/QR3aLlaUs3YCmI2rEgQ1d3ThnPgswJ+qrLPNxZqBjqwQtdCJnjOetqUw44lqzkCBWnUq2t4OMRega4udzLYDaWSEHpxUV1T5nCJ3xCULehp17s1fZUN4acFaZ6D2HJ6Ky4rueGDeK3JqFcxVvgBJoLSVv6CKeD8FYpl/aSRswelrLoeFseebRKzdLJ13WJ/v90EZ/kGrmGC1w5p4UcBtCRIUOtMwESlkPE7sxJgcsl4yd2zCUx3CEpJZuQG+vzm7YLT8DuJz0p6D4eeDwCITK/Y9O1dw3JQ== 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=tDhSAjxu89amv5bVNg7tPY7ct3hZuS2WDDY759go5Ck=; b=2HOFNf8epZweSP/qHlF9OqQ4ExLUQZdqweyf1IryhNIpG9CESyJmII2Rig44xI71mwKHhlUEIBuf0yzV3VCAjw5c4HCietPULxvluXq1tIgE8UiUzd+4NP+HH2Cuvpix4U3R+DIFO1Mp4UuhRS2SX+YApbPSYhwXDRqZHTy3F+4= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: To: CC: Federico Serafini , Victor Lira , Stefano Stabellini , "Andrew Cooper" , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Nicola Vetrini , Bertrand Marquis Subject: [PATCH v2 2/2] automation/eclair: tag Rule 19.1 as clean Date: Fri, 2 May 2025 16:35:35 -0700 Message-ID: <20250502233535.3532279-2-victorm.lira@amd.com> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20250502233535.3532279-1-victorm.lira@amd.com> References: <20250502233535.3532279-1-victorm.lira@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Received-SPF: None (SATLEXMB05.amd.com: victorm.lira@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF0000009E:EE_|CH3PR12MB8458:EE_ X-MS-Office365-Filtering-Correlation-Id: a8f599af-784a-4bc4-670f-08dd89d22ae7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|1800799024|7416014|36860700013; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?Diw+Dxtka0iLHxYdFFyct5MSiSRWEd6iTV5auNfkTZjnILn1e9TBwuJ+Af7a?= =?us-ascii?Q?lrBVZEufRl4nwhbN93Hjdca0J5gYnYjAXkHobuProdcS5CpOIh+z2ecHh8zr?= =?us-ascii?Q?UYVbHM6ZY5vLtlUlq6fQ0NOI8ZxpEyFlezsPXRlhnAq1FH31pCCS36EAAHRb?= =?us-ascii?Q?pkCGTkVlozMWPwM24zRkBQzRSs7uX6VCf74OFpTLfY4VokptDjEMhem9d6Fi?= =?us-ascii?Q?drG4jIeV0v0afQyHusikQzqZGiwG5B1jUi4MpYAeSqdBcEUXrcOM23qEvWdz?= =?us-ascii?Q?52WEoDbnRmS8ciuOZYJkCc4RRsNGS14Vn7FBJX82x/kvmWvVZabkQ2MWXfn9?= =?us-ascii?Q?2+ecgxLxx4cFyeRQap0gUw+TFPupXqTExrW2zQz3n+OIFpWV2/B7BHbJw2MA?= =?us-ascii?Q?D+2Qfm5ExSD0dfd9TZE5LuxS4OHgDIIq+FTmV0egfSxl1BSYOFS0MrJMP24v?= =?us-ascii?Q?2bvDD4AOyddWtTiuNMBjqwilDJqLn6np+7wxjMDr9aP0rGslgWfNBisU4gY3?= =?us-ascii?Q?cT344q+8ehz6sW3qx355F5vDLZzUu1cKUzTCUaNLL3gCmLaxayYT/W9RowXr?= =?us-ascii?Q?4nrJIwAXCiu2ixekqlvgB/aPw81C3orj301DSa7e8U9sSZ5G9hj0XVjbzg5s?= =?us-ascii?Q?fynfpEQ/786bALGFBMzj65P34xZiKyKgPCvbzF+H8JPZCatcx3IcYWOwgerO?= =?us-ascii?Q?tHhAvFWOpOGTto+aXXpdfdMnAqerdWCpEPxpdVvJV1j5LPtGd0HU5K5yE2HB?= =?us-ascii?Q?j5xA6ZW9HxDAnpvA4ES0ywQS8+98+NbSp9g6Ke1xG+QFlYTIs8vtSu4qHNU4?= =?us-ascii?Q?KdmXeoTIUydt+TCKZfFK1FQkrMF/0TAbcA+HILLihxhe13FVakow48lIR6wX?= =?us-ascii?Q?RvTnFRarlPdiMT0YkHJOumpfIjOdta0qo7YeEhRfOpf+tHCGEFg7E/MA4Ntw?= =?us-ascii?Q?arcXZZqDzguijHBnN8eiNH3Mg+Q90ojtTLs3i3QnJPdAE0z7MaRU2XbMX0Pt?= =?us-ascii?Q?9isDBIJ8+5Jx8B0E4nh7DCdP9AxrXJ9UbFPYrQ6PGN99oUk5hy3UG06AvBeq?= =?us-ascii?Q?NGOl7fXHxJHMK8LKb4mWt79g04McnYVXKOnjvydpzFkw4ZAp1w9rSXB/BTi9?= =?us-ascii?Q?cJbsMCeDtzdA8Z1HtiQQx75tDemPueIgqOCdXdH1vTwY4ev31w0Z/2pMXoDT?= =?us-ascii?Q?+6IcmfuW/OugqDsYLfkvIKS3JOHDjn35NgiyuOZpqzpFoZwV4w3E12ZP6VZV?= =?us-ascii?Q?CO5uGeqUtA/z1CoDWCCaFjywZdevrX4Br81lkadDpHBt9xhIzDP6WPZdEcJw?= =?us-ascii?Q?wCdX3mgLZsirwPNM1ZIAd0D3iPKmiUkCfINKpixXshJ2FQBIuREItUK3891S?= =?us-ascii?Q?3/xOZN9p4LcNGTlUryALzDPgVuJyLLZehZkQkGfpfrrXmWe4o9ZtiZ3MRxyz?= =?us-ascii?Q?S915CLS+acv1IdiGmRmsJ7PLqVeSTdEiyWm44kZ5seXHV62ei+fAy8VwQetY?= =?us-ascii?Q?o7lu4q+vLIhejgO3+8lcLekLAz3Nf+t0ROFw?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(7416014)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2025 23:36:31.1748 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a8f599af-784a-4bc4-670f-08dd89d22ae7 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF0000009E.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8458 From: Federico Serafini =0D Tag MISRA C Rule 19.1 as clean to avoid regressions.=0D =0D Signed-off-by: Federico Serafini =0D Signed-off-by: Victor Lira =0D Acked-by: Stefano Stabellini =0D ---=0D Cc: Andrew Cooper =0D Cc: Anthony PERARD =0D Cc: Michal Orzel =0D Cc: Jan Beulich =0D Cc: Julien Grall =0D Cc: Roger Pau Monn=C3=A9 =0D Cc: Stefano Stabellini =0D Cc: Nicola Vetrini =0D Cc: Federico Serafini =0D Cc: Bertrand Marquis =0D ---=0D automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +=0D 1 file changed, 1 insertion(+)=0D =0D diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/ecl= air_analysis/ECLAIR/tagging.ecl=0D index 1d078d8905..dab3c51faa 100644=0D --- a/automation/eclair_analysis/ECLAIR/tagging.ecl=0D +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl=0D @@ -78,6 +78,7 @@ MC3A2.R17.5||=0D MC3A2.R17.6||=0D MC3A2.R18.6||=0D MC3A2.R18.8||=0D +MC3A2.R19.1||=0D MC3A2.R20.2||=0D MC3A2.R20.3||=0D MC3A2.R20.4||=0D --=0D 2.25.1=0D From xen-devel-bounces@lists.xenproject.org Fri May 02 23:46:00 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 23:46:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975191.1362831 (Exim 4.92) (envelope-from ) id 1uB04p-0006Wk-Qg; Fri, 02 May 2025 23:45:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975191.1362831; Fri, 02 May 2025 23:45: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 1uB04p-0006Wd-Ns; Fri, 02 May 2025 23:45:55 +0000 Received: by outflank-mailman (input) for mailman id 975191; Fri, 02 May 2025 23:45:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uB04p-0006WW-2K for xen-devel@lists.xenproject.org; Fri, 02 May 2025 23:45:55 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2062a.outbound.protection.outlook.com [2a01:111:f403:2413::62a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 949e4024-27af-11f0-9ffb-bf95429c2676; Sat, 03 May 2025 01:45:52 +0200 (CEST) Received: from SJ2PR12MB8876.namprd12.prod.outlook.com (2603:10b6:a03:539::18) by SJ2PR12MB7963.namprd12.prod.outlook.com (2603:10b6:a03:4c1::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.33; Fri, 2 May 2025 23:45:46 +0000 Received: from SJ2PR12MB8876.namprd12.prod.outlook.com ([fe80::69d9:a014:7a29:de4a]) by SJ2PR12MB8876.namprd12.prod.outlook.com ([fe80::69d9:a014:7a29:de4a%4]) with mapi id 15.20.8699.019; Fri, 2 May 2025 23:45:45 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 949e4024-27af-11f0-9ffb-bf95429c2676 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iqb0+6kANc3xwu1g+C9uOZLI5myxytkfb4jc9PgZ4hd0UY+DBgTer3ClFHyLWnLYbNCWpA7JJ1BydSJxOEGsaukapb2liMl8lfUrxDq6mmywtSB5ibS4J/hyjtMJy84iZRFuFBlCAqYU37aMv5nF8XrdV7DN0QF37TwOqAz3daOH1soTjsyVCvAL1TBRdIk3t0xFOnbebnY1h+TcvyxmiGSSgZm5ZT3J0nqF1aMaxTQBsDH1kn/ZOc22fCHdcqU/Pq6ytq9d3Bslu2k8dwURSvgRr5yv0+tp4zQoCQCuCGFqq6LUr0MwTqobx7+tT3HaYyRbWf2R++A2zjxIHjmV9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WSSAEmJkM8IPsZFvN1yjK0BOBv8Jbi0hibXZ+yFDpb4=; b=YrEW0FxSVu//fqaUTbutbO5/TsljD0CM9ewOzVACUJ23tOUvcTUJa3Jt1R7qOlGZriVj4LQugIS/qndAhIkuhGGmCxVoKdzTxDkafGt9kDYdgsKZi10zirHJ17kW8IkkjZ2TsOQAjpqdxmUNystBoofMuna3n4qHSxkIHP2qTrh838Nwy8SW1M+qHBRDNth5DGrRNA7kSrzJE9RFkmZb1S8HRMc21M9n7LVO6MCKp46gGqB8jEYcZNfljoIDJW8qy9d0OOIcR3TjftmP8LC6i6CP183D3LoNVW3L9FbFJFTWSc/XvEnAUozMaJP8TaKLqg3TnwSp0+8146vbyUyedw== 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=WSSAEmJkM8IPsZFvN1yjK0BOBv8Jbi0hibXZ+yFDpb4=; b=UJsnm9ViFxlvtjUwwzc1WZcLN6dqMDGw9zDYzv63DuOzvMqmfLNLQLldCUBpDlNWjGSYye4+/PYxQQoNcnMnfM7hLJ2lq1bboZIYgtBV8T/FhhFQ2bTpNAvuUxDuI5tpoJgfKGvzTmh4H7KrZxzaoc3AvHVKyYtvnHAYdzY6hko= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <68d30d0b-1f85-4480-a2e1-0c9c5effb49b@amd.com> Date: Fri, 2 May 2025 16:45:43 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] automation/eclair: tag Rule 19.1 as clean To: xen-devel@lists.xenproject.org Cc: Federico Serafini , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Nicola Vetrini , Bertrand Marquis References: <20250502233535.3532279-1-victorm.lira@amd.com> <20250502233535.3532279-2-victorm.lira@amd.com> Content-Language: en-US From: "Lira, Victor M" In-Reply-To: <20250502233535.3532279-2-victorm.lira@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PH7PR03CA0014.namprd03.prod.outlook.com (2603:10b6:510:339::10) To SJ2PR12MB8876.namprd12.prod.outlook.com (2603:10b6:a03:539::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ2PR12MB8876:EE_|SJ2PR12MB7963:EE_ X-MS-Office365-Filtering-Correlation-Id: 3e5fc493-ad28-4d50-dbe6-08dd89d37530 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?bFJrN1lKMkZOeDBRR0NPcU1MWkNaL0U5ZjlSUnhDY01OczNQNUxCOWZ6SWc1?= =?utf-8?B?SXpUamlSZ1pkNnlrN05lUTJESzE2WHR1aTVGM3k0ek1XcVB3QWx4M1BzYWxC?= =?utf-8?B?bE9iMThWNkFxYzVKODNZaFcxTkZaOXJHeDRqRkpMeWZsM1hrM0lyZXhkQXR1?= =?utf-8?B?Rmp4ekFtVEQ2ZEdYbGlDd2FIdXNQR3VybHFGMExkT0c3UGdMWXpleWZjRkR1?= =?utf-8?B?dVUxdHNNcEdJTmhiMDFsa283RlpWR3dyM244VFJseXNjeEo4dFVlaVgvUk10?= =?utf-8?B?VGFLVVByWjE4cUhoWVNnSUNNbXRZSFNjRk45QmhQVk5pNnpHT2Q4b1FSM1Jh?= =?utf-8?B?YVdwbmpnWDZFZjVOdjkrenNpWjdDd0VpNWQxbGdZYVZDZVRHNlpxZ3R4RlRB?= =?utf-8?B?clFyc0dudmRsMzgzOERFK1lkN0tGeXNIcE1wQzlMbi9QYnhWcmlwMUp1QlNH?= =?utf-8?B?QTBJa2h6bDlkMGpvUVJTSFpPRjR5MCs1SCthTjVGUk5NZy9tQUZma3p5NUtG?= =?utf-8?B?M1A5Y1prMlZPOURHLzZVT21wSHJmaGtXTWk4RU1LNTV0T2dGNFZjY3RLRUli?= =?utf-8?B?ZXFheXdML25pcEc4Z3hYMjBobWRZTERDNTYxMndzM1VhRzB1WWpSWjZuQ29Q?= =?utf-8?B?T2R3ZmhpZjJGWHJwcXBXUzRuZkN3SndoSGdMRTVUaGxUemJLbHptZEFHMkEr?= =?utf-8?B?Q29JclNYYjRYdEhndHBrRFB1QkFxRTA4UnBFVFhWUjBTV3V2M3RCR2h1bHZP?= =?utf-8?B?dDF0VDVvTTdaT29FL3EvNmRLL1dTQU1obk1PRVhYeGcrTkJHODB5S3RwL2pS?= =?utf-8?B?dXVjNm1ORllOcDMrL2t3Wk00MGE5Q0FlWGl1MGhKbXpCamM2b2ZhTzF4TjBB?= =?utf-8?B?b2g0VFBESHZ5WjNNM3hDa2pLMkUxNmw1L09USW1pOXoxU1F2MnRweHZYdE5Z?= =?utf-8?B?K25CTXBvQkFtbjlRajhwMXFlZTdjMStDRkR1TEFCcGFtSmY0SWc5RnFDSW1i?= =?utf-8?B?V0lkVXBrSnpZWUZxZEgxWWw4dDdTZXJYRS9sRHErN2Z4bWJxaHRoK1NiUmNn?= =?utf-8?B?c05ZRkVFTWxQZGlSVmxETmk2QW5zeHhHd3VwYTBCRHlrbnBEL0RwZis1d2pB?= =?utf-8?B?SDA5cytGNCtBY242b2ZLSDNzYkx3MU5PN01mZjRBeERxNU1JcDV1OEZjSXp1?= =?utf-8?B?aGV5RGljeWltRTJ2RGxPWVRxV093eUx1ekFGWW5iblB2SnArdHpoMWNoc0ox?= =?utf-8?B?NzIrU0VLb1NGOFdZa2RhQ3VpMG5rWHlJakJySVJZd24xbFFzd29acWxER2hQ?= =?utf-8?B?ZnEvcDhTYytSQk9DRnNpUi9aNWMrUEM3MXM2bkpGdHgzK0RiZktsS2VRYlIx?= =?utf-8?B?dUYxcCtxdXozek9oeTlRSFd2YWFrZjRNVzZockdpY3ZEQ3RjdnNpWFc0ZWVt?= =?utf-8?B?L25jSXhwMFIzZzZsTnJsOGFmYVlzNFQ2cEVzbEt2cWtqOWtub1BZaHo1dnJ1?= =?utf-8?B?TjF6LzhxcURqKzl5cm5ncy9mN0g0NjV6Yi9lZjF6MEVJbk45bko2YUZLSXp2?= =?utf-8?B?MThFbE1ZTDFSUTNjeDEzUUdJM2hUdFlaeHB6VzE0ZENwblNCenI2RFFjelFJ?= =?utf-8?B?aEQvVEcyMmI0Wmd3UUg0T05mc2k3MGo5SGNYdW9xNUZrYTlXKzcwL3pLUXFV?= =?utf-8?B?NEJ5STBXYzhGcFN5NHJzOHhleEF6YVNDYWFEOFZVeEFrbTRhK3BPaXlnVUU3?= =?utf-8?B?L1M1YUplcUM3OVBjRmVnUEk3anZwNWVTR0FnOWk2MWV1cEFMTm84cTRtMm1k?= =?utf-8?B?VTJlSGhEQkI0OXZjT3FCeTRvY0FmbGk4V2UvVTUxQ2taT2w0MnFjRkhqbTdL?= =?utf-8?B?RWptWXk0cVZBSnVrbmJHc2lnMDFDbzN5My9Lb255aVpmbHVYZHNvbkRzOWJ4?= =?utf-8?Q?DQjuAKKPX6U=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ2PR12MB8876.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RUNmb2VrYnhUTklieUJFY3BjVDcyZzNlTGhRKzlEMUtiR0xPS0psQkwxcTdY?= =?utf-8?B?NndhS0MyMkI3RkN6NHl4NE56bVZaL3J4NGFYUXFqWWhEU25STHV1ajFJd095?= =?utf-8?B?Z2tDRXdFcVJoRzJ2K1FTV2o0Z2JpMlowVTE0YWlaQzFhTVlJM2lrRW1oN0U2?= =?utf-8?B?N3pWK04yc1FLeTMrYzZrZDZtT05iQWIwVmtkaWNreHdVN2thWGRnZnJiTFkz?= =?utf-8?B?bUVIb0lVVGVCZHZJRVRTR01WQ0IyLy8rRVlhVmQzNzJjdmxrQmxKOThtc3Qr?= =?utf-8?B?U3JTVS9TNG81d2JPNlFONzlkWm5WeWhZRGdXNW1GMTQwUGNHTlBUZ3VkWjFj?= =?utf-8?B?SlRZVVlQL1Z4cXZGUFhPRXNxVG5uTCs4WG5oTFhpOU1KTEVCVUdpMlk0bndG?= =?utf-8?B?WUJCRVlpWmJaNmk3WUZhV1ZVdmlsUnNSV3JFMFN0aWZHakp0S1grYk1jdDhC?= =?utf-8?B?eTNweCs0Q0JReElrK3hKTFhwYTFBSGVjTzdGV1BFYXVsZHJTUFFNazlKOG9Q?= =?utf-8?B?SnZHSVdhY0lVYjVocU41K1E4MGZUa3VLVWJwVVluUEl2MG5EWURFaktUT1lB?= =?utf-8?B?elZNRDQwZWdjTWZRVnlsY1NTSUVRVks3ZDl2VTdFdk43UDVLNzRWSTF3UmIy?= =?utf-8?B?L043L0g1c3plTzVYeUVuckZCd1FtUU9TSjhXcksvWVFXVGZaL3NtY2FIUVNn?= =?utf-8?B?cTN0OEErUGpXRmxmQU0ybkNFUTEyN0tXMW1vZHhYUDRLeG9yV3pJT1BvQTdK?= =?utf-8?B?azhUa0dsQWNVeHFDMCtWa0lTbW96aGZuRWJjQWdvYXBlbHZjcEhHT05tRXJI?= =?utf-8?B?Qk1TQk1BQ3JLOUFZaFBlM2JBNFlOaU9LSFBvek40SUpTUWVwSXI1cG96M1pF?= =?utf-8?B?SkkzeFlPVExHMWtZNHBmZWRLM1p2T3JJRGxLK3ZTMUxXMWlNakFIOFdpTXNT?= =?utf-8?B?azZaVC9sWHFWV1hOaElRSGZGekppdGJ6V3JMdUQxUXIzSkYvTzhlcEhOeFpX?= =?utf-8?B?SHJtL0g5UkJYNjFWSUIxZGdvS2szdk51VFlramYrYVJZMktUQTBLWTc2b2Z4?= =?utf-8?B?ekhwQ1BZbnpjVitFOGk0UEJFVC80U0QxZzQ5OTBWVVQ2M1M0bnFXSlkvRUV4?= =?utf-8?B?RDBzUWIzZktQazYxNVVDNkd4VUhUUFJJSUtCN0c5VnNSaWJSL1BuTGlTdVJl?= =?utf-8?B?T3hieDJ1ZFhMcFM3NURLbVZlclRhaVBWUFdibFJxK0wycGpGblRpWFlRZDN4?= =?utf-8?B?Vkl5TUhLenZyRFEvYnVwY2dvclBWUUFFTjZrVVFHYTZnaHFaNTBHT2ltSXFp?= =?utf-8?B?L0J0bmdPMmUydjBlYWo4b0ppQUNkbEdhSnZzMnp5OTNqS2orOWdscmdVbFUx?= =?utf-8?B?NmMyU1hnNDVQZlBaNktCSUxHU1BxMkxGTDJrQUlTU3VsSVBySExWdW5uUWs2?= =?utf-8?B?R2R4dG5NMnhnUndWQVBSL0lmandISzYxV0V5dVIzaXZ0bVJSMzJ4QWRmNkRG?= =?utf-8?B?UFE5ODhsb0gzUmkzSnBLaTZSTlBKd0NGTTdZOWo0NGw3WjZKMDByN085SlFZ?= =?utf-8?B?SlV3QmJWYURpZGxjcXVvSW9PaGdjSm5TaXVmVWJ4RDZZK0hPbktpYThXRXRZ?= =?utf-8?B?K3kzMzRlMTIzdTB3Kyt2dGgvN0RoSnM3U0pBQW5tUXpMSWk5ZExCZWJ6bkRK?= =?utf-8?B?STlaaVZWUDdFRmRSaEt1Smwxb1FvR2g2OUVjaUNCbTBqWEY4bmpnazF3Ylgy?= =?utf-8?B?czV5ckswRXZaRGNDeUV0QktZSUJUVUZ5R2FneXhlZ20vaytydEthaCtoeXJ4?= =?utf-8?B?Q0hLK1ljZXBsQjRRVkprMUt3eHEvLzFwQ0daSWVyOXZYN1R6TEhKSkg1S2s4?= =?utf-8?B?WDlNcEdUclVXRlBBdzZDWld5ZzF5NlBQVExzczhaYy9LK0RQd1JzRkF4VVNq?= =?utf-8?B?cTRySGZYK3ZQTGxtcnZ6cEZtRVVaaHZnYTNkd3hZS1lTbEVzMS9NdzlRTUF3?= =?utf-8?B?TnVqYVE2ZzdzSHAzZW5iN3VGSE16aGtCTVlBQVJoaDJmNS9BR1RIZ01iVlJD?= =?utf-8?B?UDdYWTNjdEp1ZWNvOEJYTGt1SjFhcDJBcHhNSHJkU0NYdk1PM0x3Q3dubUMz?= =?utf-8?Q?0WAkEzIERxrnnLY0Dd8PbcK3y?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e5fc493-ad28-4d50-dbe6-08dd89d37530 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR12MB8876.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2025 23:45:45.6095 (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: U5A7wUsmpwNUzIlKUS+CUvOvlv9MAYskblLLb5VeaTwcpHURRc4qdqojDNIORcs5DdstcGEmAo//NFeM6alCYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7963 Sorry, the content transfer encoding was wrong so the patch might not apply, I'll re-send this. Victor From xen-devel-bounces@lists.xenproject.org Fri May 02 23:49:43 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 23:49:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975207.1362841 (Exim 4.92) (envelope-from ) id 1uB08U-0007A0-CY; Fri, 02 May 2025 23:49:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975207.1362841; Fri, 02 May 2025 23:49: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 1uB08U-00079t-8q; Fri, 02 May 2025 23:49:42 +0000 Received: by outflank-mailman (input) for mailman id 975207; Fri, 02 May 2025 23:49:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uB08T-00079n-AE for xen-devel@lists.xenproject.org; Fri, 02 May 2025 23:49:41 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20615.outbound.protection.outlook.com [2a01:111:f403:2009::615]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1b0fdf08-27b0-11f0-9eb4-5ba50f476ded; Sat, 03 May 2025 01:49:38 +0200 (CEST) Received: from BL1P222CA0018.NAMP222.PROD.OUTLOOK.COM (2603:10b6:208:2c7::23) by LV3PR12MB9259.namprd12.prod.outlook.com (2603:10b6:408:1b0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.22; Fri, 2 May 2025 23:49:31 +0000 Received: from MN1PEPF0000F0E0.namprd04.prod.outlook.com (2603:10b6:208:2c7:cafe::fe) by BL1P222CA0018.outlook.office365.com (2603:10b6:208:2c7::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8655.42 via Frontend Transport; Fri, 2 May 2025 23:49:31 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by MN1PEPF0000F0E0.mail.protection.outlook.com (10.167.242.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8699.20 via Frontend Transport; Fri, 2 May 2025 23:49:31 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 2 May 2025 18:49:30 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 2 May 2025 18:49:30 -0500 Received: from xsjstefanos51.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Fri, 2 May 2025 18:49: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" X-Inumbo-ID: 1b0fdf08-27b0-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nkKXhpd6QDp6EpsEbtVQjnoPzptoKDrTIvSsU+lWIenUtWQ2qrcuNDeon79jFpRyNgZT3K8y91311viuHlLy5eiYOtlqSSHfZpxbie/GMxv0BlLzVGfrcWvVpxqrleJ2KRygIGJPeFANna2lQuTHXCDk+l+zhvnZxiQ0xViCOHTzVPIi+gEtVJF/Z47C20++gajCwfOAhPHBnomYJ6FIdekxl3aj8HoVd8qRw8Ss7MJYoLeUKt3/OwpYwKGxAra+OHa2iKOfdHw+L8GTxPXcLDolsn14qIfBj88KN6SGbQ+388H0O6M8F82bNZz1usL9yrijIz6a55C1ICQTtaguLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=r3GXvT/dRldNl7HSwbI9tZbjBB2dQtt28Sk8QVn76Nk=; b=CEuKYzEkHcrWmG1khtMq6Bxf86Zv+HdegoGZexev3xgCc0RDl+gB8XmhKWx1TI57wyRMurk4ilDYNPtRHDO7+u4x3hi0IutLolVkydvYhvId9ABFtEhQlqPz93I/zwwPdsvtvdPRb3YPTkAcpiILfeLuM/KFc6bpGBlVSyG5QCuctM19MKJCXrNi4BFB+4CnTBFmdAJUBUEAdFV4tcCYMhMlWWhCB7firwi/YX/guSP1JhcxHxRbbdHNyZKs3m6LNlLgeGcKag/qZV1Tv67840wXwD216mjQrhApjKnhfcRASlI4SAtBIKkm927GN9JGWhkdl14oK0ZjQYSU+/Danw== 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=r3GXvT/dRldNl7HSwbI9tZbjBB2dQtt28Sk8QVn76Nk=; b=Zit6XrL+0QxnVZ6tHByBmslMxMcRyS3mstvKqCF1X3H2yEtFr+I6DTr+4P8aWxFf5mpVuAbaSNuSJJsMEhNF3ec9IfYfnf5l4Qfyoh2d9om5F2MJaFQsVW7YxecPFmZOPgLBFrkc2Dac3/DBFM4K3UHq14kowwcv0tCEVuk0LsY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: To: CC: Nicola Vetrini , Federico Serafini , Victor Lira , "Andrew Cooper" , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano Stabellini" , Bertrand Marquis Subject: [PATCH v2 1/2] x86: x86_emulate: address violations of MISRA C Rule 19.1 Date: Fri, 2 May 2025 16:49:13 -0700 Message-ID: <20250502234917.3533514-1-victorm.lira@amd.com> X-Mailer: git-send-email 2.47.0 In-Reply-To: <68d30d0b-1f85-4480-a2e1-0c9c5effb49b@amd.com> References: <68d30d0b-1f85-4480-a2e1-0c9c5effb49b@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB05.amd.com: victorm.lira@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E0:EE_|LV3PR12MB9259:EE_ X-MS-Office365-Filtering-Correlation-Id: 40f47872-da3c-432b-4986-08dd89d3fbc6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|36860700013|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?bnNaNVlSejdXTFNIQ1lXSW5mUjJFODR2dkYwSW82d1ZvSGpRSithUHd0MUJu?= =?utf-8?B?bUpyZ0VpQ09NNDM0V056YUpRWjVPdEJJWjNsdHVPTThIMDhUN0NGOUJwbzdw?= =?utf-8?B?Q3k4RSs0MW1kVUVvMGV3MG1CY21GWGtCeWtVb1haQzB4RmNkTFJtZWxJRHI5?= =?utf-8?B?VUcvWURMaCsxMFZjbHBkMmdOM0diZFdCcDNGcmlNWE1RS3laYVU1T0hHMyt2?= =?utf-8?B?VStJYVZCNWVQQitTMHV4V2RWaytiWXpPRE5YdTFlNFk0MnhUTXlKQVpoOVMx?= =?utf-8?B?OFB2MHVGYWtkTStWN010ODRNTFVPNWpMV25vWEJNcGl1czNxNDExRVdrRjFl?= =?utf-8?B?ekViRmk0a3FweUVkajRLdjJxK3RGSGFZQ0l3ZHVwcTZGODJqOXEraWh0Tnlo?= =?utf-8?B?THJZYkxaQ2FaS0JtVVg5NUtrT0R0bHp6dE1MOFphcndTTnBFMFMrMDVwOWV1?= =?utf-8?B?dmIxYk9DQ2JHK091clVEdHBxNnBPMS92NGdGU2l1dEo1bTVsL0wxMm5WU3h0?= =?utf-8?B?Z1JzcTV0aHhqUmpBRFZRNkduM2lMbEFRVWZhendEanlnYlZyWEVFYVBzeHBN?= =?utf-8?B?aU1laVU1UUkrOWs2OHdYc082eHA4UGF3UjRWYW1DMnUvcmJSZmRHeXJiOEwr?= =?utf-8?B?L2R3L3ZCZERqV3lSMlNveFhWZE55Sk4yVkw0eWxQTFNqYlJNaXRDWWNzd0Qx?= =?utf-8?B?TCtkV3F1WmRONm5QZ002eXlVWTZOZnJiTFRQdTZNaytueFdNZUpGN2d0VDVU?= =?utf-8?B?Um10R096dG1OeEtpeS93NHd4KzhJcm1RdEVwYi9CM1hHUmFaR3Q2WHQ1dUp5?= =?utf-8?B?MEI0VnNMQVhrem05dERNWXNkemZadFVEck5JUDVCNFlBTmJjN2pVTE51NzZ4?= =?utf-8?B?ZVA3aHRNSHZyMXFxODNBNHhOcitGR0hlYnczeG1ORVpFZTZOV2xzRWFNYUE4?= =?utf-8?B?YnZNQWFaL3VWWTRBYnhwYWZQQnJSbS9TR1B3KzRGbEkzZkdyRzJDQjljN0t5?= =?utf-8?B?MzFqMlNKcit0T1FwSGhrQ2FXOU50d1YyRytFdTIrcVFQWjZBTjNRWDdMR3lF?= =?utf-8?B?dnl2MzFyajRMM21ZUFZUWThDNVlndC9WVTZLSHZZSy9NWHhhYlMzVnRGYUE0?= =?utf-8?B?UWY0dUlwR3VKZW43VkxQT3p2eVZRdG9nb2ZEZ21TaDhhTTg2TEdNV3p1bkhL?= =?utf-8?B?WndKcWhOT3hIU0lMcEQ0MThjVFlxb0RkTmVyUmt6KzNCUHYwVFRHTnFwa2Vs?= =?utf-8?B?NFpIVncwakViOVlFZGN1M29kN01JVWNOSmNzbkV6R1hsNVVETVEwbHZ0Ty9U?= =?utf-8?B?V1RUUWNIVExCZDlQZ0Z2U3VCM3lFMktnSlJVaVZ4emhieFhMWGRWMVMrMFFR?= =?utf-8?B?VmtIWnNDYldFU1hJRTBjYWdRTTJ4a3VhanQwU3JzWDJOMGxqNlBPRGVRS2l6?= =?utf-8?B?WjVOZlEvTWUxbWZQVzU3VTZaUktPRkFkU25XUCtkbVFZdi9nSmw1UXl4YXdK?= =?utf-8?B?OHl0a3pBaERsdUFQQkd1WjBlVkhnRkRYMXJvOVQ1VVh2Y0lQT0pTNzBYZnhT?= =?utf-8?B?d1RsRDltTDVvcXV4MXJWd0ZJbDdXNGhoZnJHeHExb2lCS3lNZUtnMHQ3am9w?= =?utf-8?B?WjA0andnbXh2TFFOZjJqZXFUMmFRZzVIbTBJaTVTMTJ6dWJzY3dJRi9zTHZV?= =?utf-8?B?UWFHZUU1UG5BM0RwMWttMlIzdndJOHRpbDE4eVVxY0crNTMzMG1RS1dKczNV?= =?utf-8?B?UEVHa253RzZEbVVGT2Z6QjlLbVhLcncxZHZ5OVk3QzNqNmkrWVBpTllKdEtR?= =?utf-8?B?akp2KzQvM3dOZVV2QXgvQlovNTd5KzEzdWVzVUpDS053cHVuSGYwQ0JUMDhi?= =?utf-8?B?SGdFRE5sbWlBdS9IK21oTjRINVBxWTVyUkxFUnlPTlJlNkkraExYa3drTVVF?= =?utf-8?B?cGZ3L0ZUSkhORlg0cy9KeGVQaU9hcmZaRVppNzVMVjlzTzFHSHFFUU9WWUov?= =?utf-8?B?OWtzMjJOQzgvck9pMnkySWZMako2YVpCWXpiVlpldTZhTmhQZ0xNY3dxUzhx?= =?utf-8?Q?R2Vv01?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2025 23:49:31.1207 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 40f47872-da3c-432b-4986-08dd89d3fbc6 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000F0E0.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9259 From: Nicola Vetrini Rule 19.1 states: "An object shall not be assigned or copied to an overlapping object". In the function like macro "get_rep_prefix", one member of a union is assigned the value of another member. Reading from one member and writing to the other violates the rule, while not causing Undefined Behavior due to their relative sizes. Instead, use casts combined with exactly overlapping accesses to address violations. No functional change. Signed-off-by: Nicola Vetrini Signed-off-by: Federico Serafini Signed-off-by: Victor Lira --- Changes in v2: - Use casts combined with exactly overlapping accesses to address violations - fix commit message --- Cc: Andrew Cooper Cc: Anthony PERARD Cc: Michal Orzel Cc: Jan Beulich Cc: Julien Grall Cc: Roger Pau Monné Cc: Stefano Stabellini Cc: Nicola Vetrini Cc: Federico Serafini Cc: Bertrand Marquis --- xen/arch/x86/x86_emulate/x86_emulate.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c index 8e14ebb35b..d678855238 100644 --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -527,8 +527,8 @@ static inline void put_loop_count( if ( !amd_like(ctxt) && mode_64bit() && ad_bytes == 4 ) \ { \ _regs.r(cx) = 0; \ - if ( extend_si ) _regs.r(si) = _regs.esi; \ - if ( extend_di ) _regs.r(di) = _regs.edi; \ + if ( extend_si ) _regs.r(si) = (uint32_t)_regs.r(si); \ + if ( extend_di ) _regs.r(di) = (uint32_t)_regs.r(di); \ } \ goto complete_insn; \ } \ @@ -2029,7 +2029,7 @@ x86_emulate( switch ( op_bytes ) { case 2: _regs.ax = (int8_t)_regs.ax; break; /* cbw */ - case 4: _regs.r(ax) = (uint32_t)(int16_t)_regs.ax; break; /* cwde */ + case 4: _regs.r(ax) = (uint32_t)(int16_t)_regs.r(ax); break; /* cwde */ case 8: _regs.r(ax) = (int32_t)_regs.r(ax); break; /* cdqe */ } break; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Fri May 02 23:49:48 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 May 2025 23:49:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975208.1362851 (Exim 4.92) (envelope-from ) id 1uB08a-0007Pz-Hg; Fri, 02 May 2025 23:49:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975208.1362851; Fri, 02 May 2025 23:49:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uB08a-0007Ps-F3; Fri, 02 May 2025 23:49:48 +0000 Received: by outflank-mailman (input) for mailman id 975208; Fri, 02 May 2025 23:49:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uB08Z-0007PO-Bl for xen-devel@lists.xenproject.org; Fri, 02 May 2025 23:49:47 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2061d.outbound.protection.outlook.com [2a01:111:f403:2412::61d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1f88e5ac-27b0-11f0-9ffb-bf95429c2676; Sat, 03 May 2025 01:49:44 +0200 (CEST) Received: from BL1P222CA0002.NAMP222.PROD.OUTLOOK.COM (2603:10b6:208:2c7::7) by DS0PR12MB6488.namprd12.prod.outlook.com (2603:10b6:8:c3::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.20; Fri, 2 May 2025 23:49:39 +0000 Received: from MN1PEPF0000F0E0.namprd04.prod.outlook.com (2603:10b6:208:2c7:cafe::7f) by BL1P222CA0002.outlook.office365.com (2603:10b6:208:2c7::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8655.42 via Frontend Transport; Fri, 2 May 2025 23:49:39 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by MN1PEPF0000F0E0.mail.protection.outlook.com (10.167.242.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8699.20 via Frontend Transport; Fri, 2 May 2025 23:49:39 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 2 May 2025 18:49:31 -0500 Received: from xsjstefanos51.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Fri, 2 May 2025 18:49: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" X-Inumbo-ID: 1f88e5ac-27b0-11f0-9ffb-bf95429c2676 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GIFXPwLVjjPjMUmXDvEinPpOaKTt3ZYdngLgkEXQvuEjBa9kcNIZdgPfdKMdEKugjsc2hGp6cXy0SGU6DNaDgaNS3S86yvlOSfLmH1iEgBjoxgtMHPoB1828gz36z0686L50fpsfWmB2DIWZDTZyrpZEOL06elRkByeqEoWh3MaZWSv7XqgziQh+CkBDin5Uqv5a2D70G6aPuYQ1ew3GG+Y2aQpSw9U+GGpFcCZxTwSn24F76bKLZPHSmrw/XTkHkyfAGIggDNW3BPJIokBy6vt5Fmpr5Bkmu9g2o3539JpvZuMk0Nlis9kYP1Szk9LJqK9U68l+rB3XHEedYh+Nvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ENRW1WL8vnVV2wSr9qF2d8OSvYyx5poSy7A3jhXfvcY=; b=OUL6nFwV/d+f0MmC3AC00MOzKqJP9ewKB0lBpgs/pc6MgjoYHNFYugepO+VwkOAzcUuPhrn0PSEfCYnubz0QXnr/49w92qEtZY0lvHh/LGtR1k+BNktDP5rVkmB7cJ7d5tm8229f0Jqq36AwRtIKRqVaAYz4FV0R8FnME9tTgfRjJAap5Eg46cK18hBQldFJU8yMhJ+hfa79jMNc8HaU6Dfu9nNIw1j//SiX85JBPusVao7qSje33Z/KIQe0YoKT4+AkwbnmVGHvg8DIe1lr1WxFs4kx27xXBhXGjNiAx38w0ISUGQE2F0TEln3rC9uUU8XBtT7tquRp4xmxePjf/A== 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=ENRW1WL8vnVV2wSr9qF2d8OSvYyx5poSy7A3jhXfvcY=; b=JLvnX7wVUJh01DS5+nr3CkmH/EnLllClNZ6j5FzvD+MAfTTfMIdQOi+8fZHPj4FKOb/6YBvUHEUwU7zTWbeZrSUdHPCSCxZmH5YxdPQZ2t67qa84aJXHYDgEwSfk3Usqp8eHTVrL8BRU5P5Y7su3MNomvItVnOT9XvK5dZBppWE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: To: CC: Federico Serafini , Victor Lira , Stefano Stabellini , "Andrew Cooper" , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Nicola Vetrini , Bertrand Marquis Subject: [PATCH v2 2/2] automation/eclair: tag Rule 19.1 as clean Date: Fri, 2 May 2025 16:49:14 -0700 Message-ID: <20250502234917.3533514-2-victorm.lira@amd.com> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20250502234917.3533514-1-victorm.lira@amd.com> References: <68d30d0b-1f85-4480-a2e1-0c9c5effb49b@amd.com> <20250502234917.3533514-1-victorm.lira@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB03.amd.com: victorm.lira@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E0:EE_|DS0PR12MB6488:EE_ X-MS-Office365-Filtering-Correlation-Id: b8b56f8d-7b7a-4a57-2180-08dd89d400b3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|36860700013|1800799024|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Y1Y3MldZeElwSWVzMGo1T3g2MytGK1lTNlMxQ0VoMUpQeWs2bmpXeE5QQkNn?= =?utf-8?B?SEszejhnRnRobHhWSUZHWkFqWjRwVndORWNCZjNLWGpUdCtCM1RNbm0vdzY5?= =?utf-8?B?Y0VDbGtvMTl5RkJERWhIcjFJTWRUODRaejh4aThhdXJUMnA0N1dqZFYrM0pE?= =?utf-8?B?RmR1OHBCd1JjUlUvMWJhcllYU1g2SXg5b2U4L212VStBb2RNYTVYamt5R2Z2?= =?utf-8?B?Vi8xUlZ3bXg1a3pKVm91QktuUEpMRmNwMU1lN2x6NkxUd0tqSDdhaXF6bith?= =?utf-8?B?aW5yNkppUzZaY3lMdkswVldhQUlxS0ppeHU4UHhlRTNJcFVkek1rbzlpYUVV?= =?utf-8?B?b0p1VFNnOC9FTGdHbk0xdGRFT1dLeFhGUVA3TlNNZ3AwRDVSUjVDK1RPc1dw?= =?utf-8?B?dG5ubzJOOWlSbjI3eWZSanBPNXZwelJtNjkrMkxvdjY0Y2pJOGMxQ2oyUVVJ?= =?utf-8?B?dHB1TmJFeUQ2QUVvQjVqUHZXa1BESmRMeWNSeVJhOXFOdWppTGQwN21BTDVR?= =?utf-8?B?U2NWOVFoL2ZhKzBQa0dqUVREWjZ3cE5oa2tDdGtVMGluQjgyZFR4Tlc1UXVq?= =?utf-8?B?M2lETmJKRVcxZmR2MWo3dlk4NGNUaEhxeUVCUUN4Z21HOVAwWXFpSThaQ0xY?= =?utf-8?B?QmY4cFhXYUZ6YVVMQ3JEdTVYYWRwalJGSWxRSlZ3Unhoa0dSbGxkcHhqZmpv?= =?utf-8?B?UTEvWUQ1cURMbmxaRXpiakZ6YWgrTTlLR005MmZhNm4xN0REdC9tQzNMV1Fl?= =?utf-8?B?OGV3TzA0YVMrdm1XUS9lU2pjR3lvMTF1V2I4cFN3VEwrazdlS3h6aUdTTmI1?= =?utf-8?B?RTZ5RkhzZ2NZNkxKT0VNYkZjOUxRM2ZzZmMrbnNiM1BxalQ0WFVLelZJRjJh?= =?utf-8?B?ZzRoQ3RpSUdBZXIrVmZzY2R6bVU0YWhtM1pWNnlKVzJyQXJZMFdWc2wyMzdr?= =?utf-8?B?LytGd3VPamJLdFplK2xWTGkreG9iZjdrOW9ZRGlHRkFQblJ1UFF5QU1kZzJQ?= =?utf-8?B?ME5McGNCeUVaNDNQZVFXSGNVWHpTUnFGQXZ0dm5nSmxpVGVyM1pkNzErSEx3?= =?utf-8?B?YTVlVlRvcW1kOG9PMXlJTXVBeUNvNTFCS1RvdFhSZkx5Z25RYkEyNEptTFFL?= =?utf-8?B?cnBhM0ZWN09qUXY4Vk9GVHJTNE1leGxyWW9lNm96OWh2UEdITWNIL3BTR1dG?= =?utf-8?B?U0k1TlJSREQ1TzNTcGpTMXcxUEpWUzF6V20xMGpZdGNtbGNkVDA5eGFpUHBX?= =?utf-8?B?cXhUU2lpancvY2pRZEZWdFZBZmo0NVVYWitxdjd6VU51L2hLci9JL2JxWVNB?= =?utf-8?B?MFFOeTVSQ0Q4VkMvMzQ2K09TMjM1MUZNNkpPT28za3RVamZiWmsrM3hZM1NV?= =?utf-8?B?NC83ZmxXNmo0TVFWd29veGtaMUNMM00yaU5sNGV6c2F2WXh6SkNkcU9MLytZ?= =?utf-8?B?WHlWRHNZL2E0QlFVNTdxYXpsd3Boa1VIdEFLVUlkc1hyMWlrQVhBaW1hNGd0?= =?utf-8?B?NURsTkV2S000QkZXSENySnlXbURGNWNlZkE2WnlUQ0pUdE1PSjJLQTFzRVlk?= =?utf-8?B?eWR5YVZ5OFFHTGxVM3c5bzR1S1FPTW8wS0hacDI4a3UyaEJUYks4QUxjaXlv?= =?utf-8?B?TGZyRmNtenNqZVgySFR1alE5UHQreHhBMkt2ajJMQng2MEpHV0pvQ0Z3L2RO?= =?utf-8?B?S2R4V3FETE1pZzVQTXV3M0YyckpUYjFMTlNVZVAyNFVaODZ6NVJhV2h5SVlR?= =?utf-8?B?VVN2YXFXK0FiZENRUkR3aVpFTmw0YjZVMWNzc0lSQTkwSmFsdnMzTnp4aXhN?= =?utf-8?B?emd2RHNlNkFxZWVpMFZSZXFtbUN1NWFwR29hZzBDY1lMYUMwNlNOTm16K2Nt?= =?utf-8?B?Um0wVVRjSkpOcjRjKzFjWHJsOUo0NUNZM1lEVDNsNWpGUkVDaW54RUd2TGxt?= =?utf-8?B?MURaWStHekxJNzA1QkkvZUtTOWhUOGFjOHdhZFFDTU8wcmhuZFBhd241WGZG?= =?utf-8?B?cWVFSFJseHBGTHo4S2ZFV2F6ZFMvM0JYdGZFVnNzQkZ3NGZuZnVBT0d3eXdT?= =?utf-8?Q?emCFRB?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2025 23:49:39.3797 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b8b56f8d-7b7a-4a57-2180-08dd89d400b3 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000F0E0.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6488 From: Federico Serafini Tag MISRA C Rule 19.1 as clean to avoid regressions. Signed-off-by: Federico Serafini Signed-off-by: Victor Lira Acked-by: Stefano Stabellini --- Cc: Andrew Cooper Cc: Anthony PERARD Cc: Michal Orzel Cc: Jan Beulich Cc: Julien Grall Cc: Roger Pau Monné Cc: Stefano Stabellini Cc: Nicola Vetrini Cc: Federico Serafini Cc: Bertrand Marquis --- automation/eclair_analysis/ECLAIR/tagging.ecl | 1 + 1 file changed, 1 insertion(+) diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl index 1d078d8905..dab3c51faa 100644 --- a/automation/eclair_analysis/ECLAIR/tagging.ecl +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl @@ -78,6 +78,7 @@ MC3A2.R17.5|| MC3A2.R17.6|| MC3A2.R18.6|| MC3A2.R18.8|| +MC3A2.R19.1|| MC3A2.R20.2|| MC3A2.R20.3|| MC3A2.R20.4|| -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Sat May 03 13:20:04 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 03 May 2025 13:20:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975336.1362866 (Exim 4.92) (envelope-from ) id 1uBCmN-0006jw-5w; Sat, 03 May 2025 13:19:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975336.1362866; Sat, 03 May 2025 13:19: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 1uBCmN-0006jp-2D; Sat, 03 May 2025 13:19:43 +0000 Received: by outflank-mailman (input) for mailman id 975336; Sat, 03 May 2025 13:19:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBCmK-0006jQ-T6 for xen-devel@lists.xenproject.org; Sat, 03 May 2025 13:19:40 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20626.outbound.protection.outlook.com [2a01:111:f403:2413::626]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 413cbe5e-2821-11f0-9ffb-bf95429c2676; Sat, 03 May 2025 15:19:35 +0200 (CEST) Received: from SA1PR05CA0020.namprd05.prod.outlook.com (2603:10b6:806:2d2::22) by PH0PR12MB5632.namprd12.prod.outlook.com (2603:10b6:510:14c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.19; Sat, 3 May 2025 13:19:31 +0000 Received: from SN1PEPF00036F3D.namprd05.prod.outlook.com (2603:10b6:806:2d2:cafe::8c) by SA1PR05CA0020.outlook.office365.com (2603:10b6:806:2d2::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.14 via Frontend Transport; Sat, 3 May 2025 13:19:30 +0000 Received: from SATLEXMB03.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_128_GCM_SHA256) id 15.20.8699.20 via Frontend Transport; Sat, 3 May 2025 13:19:30 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 3 May 2025 08:19:30 -0500 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 3 May 2025 08:19:30 -0500 Received: from amd-BIRMANPLUS.mshome.net (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Sat, 3 May 2025 08:19: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" X-Inumbo-ID: 413cbe5e-2821-11f0-9ffb-bf95429c2676 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RiERQ+EymohCNCMtfmRaaRpVE8FLKbghvFBZfvA5wZRUJ8gnODMworNqKSW9NJNegZWLq4Bzs+8tOrQ8Fx3WPtF+2/hRWx12VMOg3jjQBpXCqPLuWccpi0H9xu6nzNHUI3coDINDehvrtyPHhoLlFohMupyXEbDeJoMjFLhuMq/d+pLaRil+7hPohTGOeglBJszmk/+N/NWp1W1XAjcAw8XXz0TdyikmSMmhELE9DxBXSPLmx9rFZrwjCxCBCngxU4x0n/f0LzfWGRg+X30A8BP5NsbF9gJWik+BLkSCG+FUhUjnrK2CdTcp5jsSOqRluy1DnQEFqfgj99EoATM83g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XThhfT990yCc2xQ1ru4NmFFbo4KjWfIRuJptyrW4mmc=; b=hpO0fQWOGgAUJaJJ5D7mbskayjEh4czOkyf2KZTquSqaNXOJpd3JWtzbSL+vbzAUJAa8eDS/L2jk0M3ALRe2gus2ccsMxPtPuJ/wtoO2mONAnys4xoceLfDhY29t/NJ+dXGl8B+cvUzbMUXwpl5ObYRbtqF7QL3rJxL7Bstmm61etixrFeoW+cE+gOeKvImhIRbGaQoY7WHBXvNgHfIS5hbX9uCxL2KaehuRgDbDvWQNkVMoEmD7bucQIGinvrX6umZtBwbmNKiIA3sBLxoWY7c08a8jZNQpeeeFSoh5bF0oepQan6X5UzMtuEr2mPcN01PLqrGywAcM/b3H3Tanvw== 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=XThhfT990yCc2xQ1ru4NmFFbo4KjWfIRuJptyrW4mmc=; b=tqHE6DGoedmGOqgCqTAbIF5iJy7nmIxncKXojcAywtwnLODzr5KeL6buCHSRtyC4vOirsgRl1Kk6YAJy+0M5g1svGYDOypwzQBQq8adlgzYvdmO0M/q7jzv91GtKuvIz5ibhuGK48/0blve7ABb/4BwWZpu8K3tuGd0LG427c60= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Jason Andryuk To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Jason Andryuk , , Subject: [PATCH] xenbus: Allow PVH dom0 a non-local xenstore Date: Sat, 3 May 2025 09:19:35 -0400 Message-ID: <20250503131935.1885-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: SN1PEPF00036F3D:EE_|PH0PR12MB5632:EE_ X-MS-Office365-Filtering-Correlation-Id: 22331140-6d84-46e3-995f-08dd8a452375 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013|30052699003; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?BwdAME9mYlk1D3vSntdUTciEPrrbMko6u/UG5zl2GvIHcYV8svLeDhJ3N/YV?= =?us-ascii?Q?/uEj6v9lS/fz525NFHkbSEqz/9qWNsJ27Wy6+zIDIGbvEHdxm7PrTWkAts4Z?= =?us-ascii?Q?4cgKKwbPLuC9wTjiDIC4kmCvuxihVvcc3u1yPkIvFqkkeAYn+gUpEvyru5fy?= =?us-ascii?Q?ZEpmOxDgyL6EajN32A1kmmFX4a44eex8qxGsnZ7aBwew0tDQJUOyR+uXPGdp?= =?us-ascii?Q?+n6BG+0T6st7+J2Is5ovO1mAZTo3NIc6MdxdnnQta+4pQt1I/0ByUNSLYdMI?= =?us-ascii?Q?LfNMOlGCH87GZGjTnzxJgQAj7L+k3Mwi85ZXezrz+7OhpJNCZWhjQWXeqCNm?= =?us-ascii?Q?OPx30wAk7+D8GYzpXKzvctuUSV67sPFp749fI90DszlIQTE8Qfm57J41uKiP?= =?us-ascii?Q?wsXMKkcDP9B4fQBiSMCgE+f9pQ7pYzF6UfyzLukoIzty6yy6O7vcuot7k7f6?= =?us-ascii?Q?AGDsiCoWJknIRekjr/XG/JIHwl33O41xN/a+jF1yfsIpLTR9B0Dy/BgFvnEn?= =?us-ascii?Q?RlInJN23AbMnhXzVCK6TklvauMZeC6F6Z4uEjGaBbkfcsJCNxjJMHW7bYJb2?= =?us-ascii?Q?bx8RgcjhbLKzNSHlprkUz2lQgN4tqUUaWgxqZYn57LZOkezXOHV+8hJabRUh?= =?us-ascii?Q?gahZFMJZLlwusGcPVFwFLoHEnP2Sr+6+kRA3I3euFGB8PZzhQp3OPN4P3BWm?= =?us-ascii?Q?yGLVuNg0AQBpBeCFYrm0m+gS74Xg8CnVk2DOBEa/zvKI/tEnHasuD2onEs/D?= =?us-ascii?Q?5pFjjQbtbhUIt7w2aBQq36EoAy9ej7M5OKNmboYZapq3OXRau8Cx2liMR0gM?= =?us-ascii?Q?1pNO9LdoHyOip0mt8uNGhMFG5AG2Q3iHN9+EhdTbV6ZpVmUAn8Y3hPvzjkpQ?= =?us-ascii?Q?+4mtQVMqqPIbuL+gJW2lZgkYvs6i7IpryYSHXo1Iflj4EsYxqjUzF5JHgDX/?= =?us-ascii?Q?ntyZp8zjx0LT/I8RA6P0mlxVyM34dUKJdJr6gihT0BEjtj0Qu9HQY+779UZZ?= =?us-ascii?Q?4RI3t0ltMrK9aNHbQ7ySItGRoxgBNpQPMHqX4pjPF0nl52upA1BMf4amX8Vz?= =?us-ascii?Q?AhYGB0RbV2oNao7NvY+YSZu8F3GNuJuHp/h1EZ6uNyBHj0ZzedaZ1Pw6RiTu?= =?us-ascii?Q?HjmtwSKLYpx1BXUp6pvFYBAHtwK2BokWz2t2R3sbM53UePtMbjuOzuOkHI6F?= =?us-ascii?Q?ly6eOqlZoQw3BTdclm1kdQAtznvqIteJF3FwMmnjD7l2U1EdRcsCeIdvxh6p?= =?us-ascii?Q?ZYSAFb6drMvXCvUGcWXaBF3Jy1SayGDhAMCppRlX9yg+fJRLQ0BZ15VEJJW/?= =?us-ascii?Q?oO3gARUyEx4zqmzyI18OPtpXrTZEDYlvB7fTK2uEpAdCOzFQjiPEMxDnW66w?= =?us-ascii?Q?jC1qMAYrNSNuAWBpQs2w6hRfkRHrIFBv5S6gcExbEc9Rf18Oh+u+XISO4V15?= =?us-ascii?Q?t8Ah6+wVnG5tat5vURbXPK4JC9PxKUzmsLFiuHC4thk+sXOiMeHfbDFiiqPv?= =?us-ascii?Q?29WYzIV4yWHquX/lS+iMXB7rh2GpkadcClZ0?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013)(30052699003);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 May 2025 13:19:30.8131 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 22331140-6d84-46e3-995f-08dd8a452375 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=[SATLEXMB03.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: PH0PR12MB5632 Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a xenstore stubdom, dom0 can be handled as a regular XS_HVM following the late init path. Drop the use of xen_initial_domain() and just check for the event channel instead. This matches the PV case where there is no check for initial domain. Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off chance that high bits are set for the 32bit event channel. Signed-off-by: Jason Andryuk --- drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c index 6d32ffb01136..7604f70ee108 100644 --- a/drivers/xen/xenbus/xenbus_probe.c +++ b/drivers/xen/xenbus/xenbus_probe.c @@ -966,9 +966,15 @@ static int __init xenbus_init(void) if (xen_pv_domain()) xen_store_domain_type = XS_PV; if (xen_hvm_domain()) + { xen_store_domain_type = XS_HVM; - if (xen_hvm_domain() && xen_initial_domain()) - xen_store_domain_type = XS_LOCAL; + err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v); + if (err) + goto out_error; + xen_store_evtchn = (int)v; + if (!v) + xen_store_domain_type = XS_LOCAL; + } if (xen_pv_domain() && !xen_start_info->store_evtchn) xen_store_domain_type = XS_LOCAL; if (xen_pv_domain() && xen_start_info->store_evtchn) @@ -987,10 +993,6 @@ static int __init xenbus_init(void) xen_store_interface = gfn_to_virt(xen_store_gfn); break; case XS_HVM: - err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v); - if (err) - goto out_error; - xen_store_evtchn = (int)v; err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v); if (err) goto out_error; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat May 03 14:23:57 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 03 May 2025 14:23:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975356.1362876 (Exim 4.92) (envelope-from ) id 1uBDmM-00070A-Jw; Sat, 03 May 2025 14:23:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975356.1362876; Sat, 03 May 2025 14:23: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 1uBDmM-000703-H1; Sat, 03 May 2025 14:23:46 +0000 Received: by outflank-mailman (input) for mailman id 975356; Sat, 03 May 2025 14:02:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBDRw-0004gc-G9 for xen-devel@lists.xenproject.org; Sat, 03 May 2025 14:02:41 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2070d.outbound.protection.outlook.com [2a01:111:f403:2614::70d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4340b710-2827-11f0-9ffb-bf95429c2676; Sat, 03 May 2025 16:02:34 +0200 (CEST) Received: from DB9P250MB0523.EURP250.PROD.OUTLOOK.COM (2603:10a6:10:338::7) by AM8P250MB0170.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:321::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Sat, 3 May 2025 14:02:32 +0000 Received: from DB9P250MB0523.EURP250.PROD.OUTLOOK.COM ([fe80::bfa1:a1c3:42a9:744e]) by DB9P250MB0523.EURP250.PROD.OUTLOOK.COM ([fe80::bfa1:a1c3:42a9:744e%6]) with mapi id 15.20.8699.026; Sat, 3 May 2025 14:02: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" X-Inumbo-ID: 4340b710-2827-11f0-9ffb-bf95429c2676 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MEyTBkd5t7GPQ8oyR95neyNl0eUdY7ykQaKmeQsKWQZmNiu0mCeqeWYUVB7bKlhgtMq2tw4Stxf9dJzRcukVhoE7Sm9v5TanQ5wZ13/ZxpuqCbM5fpo8w2OlxU+mPMs0B4rqB1V8LKNXvQ40s+hp5cp3CdrfaTkfy0AcwaulvkfCEERrFrZVnpB3cA+DfbdHXarPN6pQoYE7X5zkBo3O+qbQEI2sMFgJxTw6FGRYmWLCx7D+VBpY1C1OCzemK7gOB6j6LVRW785GS08n7O2Rb/gMVw/DIEGSKAKyGolQ8TPPblqmzqWvcFZVRGaB5OiNZx4wrkpc2PUcBJxRTmMcPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qWfPJ7h2wIyrDdt6ont0+03Q8nQPskSIr/7vUkLZ4Pc=; b=Me+qr3e3OBitYyMrkpR+92O4wlhGcxga9vTqxE+9D27TnhVQDEvEJkjDAkuv3M/bHv3sE7iuy24IduRvfwHJc4Hi2mwFrjVHSZpK/Ww3f1jzBe+ZiLU0I8bMxVcsrVFuB/IELGwLV6przYtUBbwuyUmjYmp6hOiCz/Wr05jK08KL1j0llLGdIYO4LG63TxgduGZeVrhG4yLMb9X5xE0BykhcxkPE27Yw4vw6jEdzGntLy0wuipKP1mtQJr/K3lDOKbLKv+AjJfvvbf/inspdOgtb6n30vUyonvadtv2ChjY9ZjCnz2MdjALZ7vW46Qy26OnuhxQlSyYH1PbY0yXlDQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=student.uliege.be; dmarc=pass action=none header.from=student.uliege.be; dkim=pass header.d=student.uliege.be; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.uliege.be; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qWfPJ7h2wIyrDdt6ont0+03Q8nQPskSIr/7vUkLZ4Pc=; b=XDV9NedFJcei16Rg3L73Vq5YqYMHxvpDpyCMp6MtDZDGSXKufSAKczyWNUa0ldt4oMv2XrR9WujO8s/fsJuR00NO5tiY7xgCEaxNm6Ef+Jo9oxB1dGhbCo4zxMrgfM2tFhN3Jl16wgQXossWMKPWLk38GDlL1X1/3fVs1cBs/vmsAL5HO4myE6yKdg7uCYmRoJ8IRfBRcrXoDMUUcjC9HVi6j9JivJ86atMZgCJbCMBnp9q8++uUWmGfQlcvTUCngcC+RxxULLYYE7xbwckwTCJxIhK8Di5PPszay7TYUHfWucWcoGvuNhEyzYgGFYM+VG4mBxOHJIV+mZJbzph65g== From: Ngamia Djabiri Julie To: "xen-devel@lists.xenproject.org" CC: "jbeulich@suse.com" Subject: Request for patch to fix boot loop issue in Xen 4.17.6 Thread-Topic: Request for patch to fix boot loop issue in Xen 4.17.6 Thread-Index: AQHbu22NmgKiRiHk2kKM1KfVYdOb3w== Date: Sat, 3 May 2025 14:02:32 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=student.uliege.be; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DB9P250MB0523:EE_|AM8P250MB0170:EE_ x-ms-office365-filtering-correlation-id: 58ad76ec-6790-4f4d-0be7-08dd8a4b264f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|10070799003|366016|376014|38070700018|13003099007|8096899003; x-microsoft-antispam-message-info: =?iso-8859-1?Q?XcY6RIlapLt1GLVIK8a09gOIbAjKJf7ZrVUtlJZh7WvsbkJhlEM21eoG1T?= =?iso-8859-1?Q?Bbb/oa3+r32lTGDlIg0mamGsRgoAaHuBdU8LTX5KiPxdVmBNv7qNc1NYIg?= =?iso-8859-1?Q?cSrtHIcBU/1sLzzZdVetD9Pb/473Eto2roKULeYBaW7rS/A7gfHgTnc89g?= =?iso-8859-1?Q?L9GLUoGdYjFCLGlcxkKWMV+T9hBMaR+bxnDUkKdOz2USA9L3c4DiIZ1xx9?= =?iso-8859-1?Q?5KSWdlto8dPxZuxM8YwhF5ndW1rmSeCuFCB2ge5MPJec+/R3VBq/3GPrgp?= =?iso-8859-1?Q?BE3uuX0N7rvaK4hUJAYP1EdhdmCTcztG7yTHOyXhXctLdpbYwRJUYO634d?= =?iso-8859-1?Q?JnVmLx+FuCsxEh2trn3dUNqfYz6g3KpXm+ztc2ZuVpHKKomvX3ecENj5jz?= =?iso-8859-1?Q?gAH29p46Oysp4lwqMnmjgGNjlt+YDVj0RsMZOVJviFufkxWSp9ts9Qj7jm?= =?iso-8859-1?Q?VgfnWM3JwGw1CmpGb+oksnozKMbCMzvVCvPIUtlaPY+gFBx+xAfJOkyUDd?= =?iso-8859-1?Q?FhTwiVfsY6aLOz7arV/Sb3q4j8v/ajW8jInWjmLy/S6TEcFUs4Vhvwqaee?= =?iso-8859-1?Q?cRE0v2l8GyHxK4V5NqaERS4YwHhv8DFn+Nu/Ojzmj0AqB5MdC7BI2MgZEz?= =?iso-8859-1?Q?FN6KLClbkhfBJNMVAahSuwV2xN2w7rTVUsv7B6qHMUS+FDO4infzW+US7O?= =?iso-8859-1?Q?6U4QqCk2t0jlG+/1EYHt9nvNxCV3REKKvV4jV0NawAmxOz3rz7ex2etORx?= =?iso-8859-1?Q?07CGO2ozueZT/uC6G0qWXgEFiQWjkomamel3sw2KNKb2ro3N1rQsO5+TpQ?= =?iso-8859-1?Q?WnyNsXvMXIikHZTuGVqxlJfQ/3LkUxtM9iL0nbd5bN433XAHFQTxNLPvFj?= =?iso-8859-1?Q?RaWQVXRkydV8rvRe3X2ElAgtQGWJ2HSqbrr+8+J3P683nNyvXgQYoWLokB?= =?iso-8859-1?Q?J5t3QE8OoFmWxLcXRqJ+OMZbAauYXxAo+RkuTfZA0ygM3E/X0Z1Lbq4z41?= =?iso-8859-1?Q?yaf6Rx/KpBbKJtK1KurHqQQ1Vqx5cN7SxzUTETUnAEBEIohDRi6EYDKjIz?= =?iso-8859-1?Q?RceCLOGXv+AeDLQHo4DhPIY+0WxO7YyX7ttW8lpHsQXIw+nMlE0e+9bIbu?= =?iso-8859-1?Q?nTdnz66B64Xa1dHMyz86Xe+YrpTEeZTg4TQa/c+IRIIkTWNh1WdtHTTS0Q?= =?iso-8859-1?Q?0NVxGM+v6OGQjt1/IUhfZG6TENSNVQey3grwI/Vun6JeYCaDbKUhBA3GmF?= =?iso-8859-1?Q?yT/LsN9grrq1s0YI+IArKSNc19taegz7mVYsuKbFRfFea/o+qSsHvcmz0R?= =?iso-8859-1?Q?RgLG3Lj5O6adnZuni7UhUAS43NZMvu+wIYUrgWMg5pRieqLk7aaf4yx3jp?= =?iso-8859-1?Q?hKdgRj5k5V1R1cEt83vRI/DiQHmyKRJcHgxppYz5CY3rZ5S5NIbIjw8Jsx?= =?iso-8859-1?Q?XzZl7tIT0pv/YQp9CuLKekJdidu0fT0375jkUKh7tqtdDCxJYBEETixOMY?= =?iso-8859-1?Q?A=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9P250MB0523.EURP250.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(10070799003)(366016)(376014)(38070700018)(13003099007)(8096899003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?SqKuFrc4Gac1kfJjTSA/RPy0b1omFChap0uWuObXsp3RPBC9TovhVM0SRK?= =?iso-8859-1?Q?BRKlyYUpFzpZmuwaI9OibeKJAgVn2e3b0u6vvx3yxeoQY1pUA/j+KT8nAA?= =?iso-8859-1?Q?CoQFlWgAcuyZghTNGlvAqrnpETUVAM6QjdDgiX3MFBuUk4AzkK09nVKuDu?= =?iso-8859-1?Q?sXFVWbMw74t/9h80HbrDE/7pH8bWE6p9142JCatEO9FEUD/UeWg5TiADf0?= =?iso-8859-1?Q?YO5C5W+4T/r+CHPkyncAu+DWpDw0+oMPu/379e7pKUX70lnsHF1ABje6HW?= =?iso-8859-1?Q?HY4eb9+0g9uid2qSXXFPKq9xufdCbypPGDAjFS2WcW4wHsAiV3vvBiE941?= =?iso-8859-1?Q?jDk6R/1JY7GzRYZQpQiHeNKIkjPM3WRA3PKnBQxsyZ8DCeIuITAi3ZSPb/?= =?iso-8859-1?Q?YVNld5WDhcN+x6Ujzfp2NzpLDusyz9cBUS4EUa/HIMZ3EUPcI2oIkwFCaY?= =?iso-8859-1?Q?FRkhmke8efaPJfWYpgxzrsKV8BlP5Fpi3nlZs6wnISh/P1FJkd6pDNBe22?= =?iso-8859-1?Q?GwqmIFMAbecylnZYUbqgHb6a4Q8UVGFKPhCYJ3Tx+jfJcYRkwxINcadOpD?= =?iso-8859-1?Q?0Yzjv3H6MVm1GKrQXOaBz1VkHsgjHNWtHQDix5pw/b7i/XK8/FFbyH4d+I?= =?iso-8859-1?Q?KCsA9+Uv363YcMSe8TudePciTVbTjADHD/bt+8PG/v4cHZkroj+sxANDxi?= =?iso-8859-1?Q?oe0Pr0lWi863WboW9IjbrLyZMUApTzhwEcASQyzmNfQReGpjFfI2tFqKPR?= =?iso-8859-1?Q?PqKPRH7U+8XupwfTnnsI0jOXs87pdt14mJxjR5KXTV2qOXZWivZJ1kgW3D?= =?iso-8859-1?Q?3m4FGc43PREzwUNb8O1MjFr5hKswc89cb0jqTCicLr3jThMaPr1kuZoLdD?= =?iso-8859-1?Q?GXCefPxt0ZlIwMwepnN2d/U35TcvnE+II/mpM8Krgp500YpCYEPHq/BR+h?= =?iso-8859-1?Q?GROtupB8dC8muyThhkgwpMUby96Smk5nlWovat2cbWgA4FboX5nW+7csXp?= =?iso-8859-1?Q?qfyjwpNUwk2AJ4yONwXFt8ahkLS8lW2xIccYlr1geLYRU2mLXNQnkIhl18?= =?iso-8859-1?Q?E1z/A06WMr2IGZ1FVMtvsGPDFaZYu2bOdEe4Czm528N4FTlo2lzsKWj1lu?= =?iso-8859-1?Q?1vBas0Vwjk0+Ylhv10LY/m/KHYmBnKWtSz2dvidyyOFut2UumKL2fQTlEr?= =?iso-8859-1?Q?LHgszLXutbtThYahbcCBOqqsl7IXoGKGrO+lZunVN7/gJrC1Lewl+BYEu6?= =?iso-8859-1?Q?UrZkITlj3YE7iEEJXc1tq95oRzNbkXXUUATUyYi2coEnG8tc5A+pOhjU/G?= =?iso-8859-1?Q?Y/nBURhZKE0ais6I/1WVICnsCfhtmmNlasmo0zQjLUT5FbJkvT5NacobKC?= =?iso-8859-1?Q?yfsHvkIutkdzVLBRCS+UjKieuCKnRnmpS7s7cWGpMcJozAbt9rVq5jVb9o?= =?iso-8859-1?Q?n/k9IGuAGBmM7KozmO1qT7roMi/qlCE2xwAQXeWiBhonFSolaazCxWgh3G?= =?iso-8859-1?Q?/ybbL28O674zo7d7LghNRQiKMvrvjRcpanSHZsI5H22eIf7B2W14Tbm1d/?= =?iso-8859-1?Q?Rw03qHDKrNcRHYnZmuxaDlzjmvqUTum9KA7b1RPPi27MtPl6VHOVf7M8Gf?= =?iso-8859-1?Q?/rjfDEl83wIEkyVeub5lg/QlwW6b5KvRc6IUmtmoiS9h766xOFcYf/I5JA?= =?iso-8859-1?Q?1Cjz0Y7ailkOyrMlLdfp0cu+rEgH76KLWoTaOO8LB5Fa65O6EqrF08gDxj?= =?iso-8859-1?Q?Cq5cfya5EQI64afQpnlytdO3M=3D?= Content-Type: multipart/alternative; boundary="_000_DB9P250MB05235527B537774F77EB9E26A08D2DB9P250MB0523EURP_" MIME-Version: 1.0 X-OriginatorOrg: student.uliege.be X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9P250MB0523.EURP250.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 58ad76ec-6790-4f4d-0be7-08dd8a4b264f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2025 14:02:32.6249 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 62e13b84-1960-4562-8c7f-72472951da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p41RPcu5UzDgNo5x5/A4fy9VR4O591kCRt0FCmK07QUdNFMD7CHmateB7yoY0oSi38ZLnZH7I53rj4/DEUgM41AdvNsN3xgh+Mf6zR6PsyWXm7Ht1v90FcqXPbOpm//K X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P250MB0170 --_000_DB9P250MB05235527B537774F77EB9E26A08D2DB9P250MB0523EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Xen developers, I would like to ask if the following fix can also be included in Xen 4.17.6= (and eventually in the Xen versions after 4.17.6 that don't have the fix) = : https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3Ddd05d265b8ab= da4cc7206b29cd71b77fb46658bf This bug causes a boot loop in nested virtualization environments (for inst= ance nested environments that use VMware Workstation), making Xen unable to= start. It was introduced in version 4.17.3 and the fix has already be incl= uded in 4.19(.2) and 4.20(.0) and woud be planned to be included in Xen 4.1= 8.6 in the coming weeks. Even though Xen 4.17 is in security-only support, this is an issue that blo= cks testing and usage for users and projects such as Alpine Linux. I am a student using Xen in a nested setup for Virtal Machine Introspection= (VMI), and including this fix in 4.17.6 would really help avoid these prob= lems for others in a similar case. Best regards, Julie Ngamia --_000_DB9P250MB05235527B537774F77EB9E26A08D2DB9P250MB0523EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Xen developers,

I would like to ask if the following fix can also be included in Xen 4.17.6= (and eventually in the Xen versions after 4.17.6 that don't have the fix) = :

https://xenbits.xen.org/gitweb/?p= =3Dxen.git;a=3Dcommitdiff;h=3Ddd05d265b8abda4cc7206b29cd71b77fb46658bf<= /div>

This bug causes a boot loop in nested virtualization environments (for inst= ance nested environments that use VMware Workstation), making Xen unable to= start. It was introduced in version 4.17.3 and the fix has already be incl= uded in 4.19(.2) and 4.20(.0) and woud be planned to be included in Xen 4.18.6 in the coming weeks.

Even though Xen 4.17 is in security-only support, this is an issue that blo= cks testing and usage for users and projects such as Alpine Linux.

I am a student using Xen in a nested setup for Virtal Machine Introspection= (VMI), and including this fix in 4.17.6 would really help avoid these prob= lems for others in a similar case.

Best regards,
Julie Ngamia

--_000_DB9P250MB05235527B537774F77EB9E26A08D2DB9P250MB0523EURP_-- From xen-devel-bounces@lists.xenproject.org Sat May 03 14:59:46 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 03 May 2025 14:59:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975375.1362885 (Exim 4.92) (envelope-from ) id 1uBEL7-0002pL-8I; Sat, 03 May 2025 14:59:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975375.1362885; Sat, 03 May 2025 14:59: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 1uBEL7-0002pE-5b; Sat, 03 May 2025 14:59:41 +0000 Received: by outflank-mailman (input) for mailman id 975375; Sat, 03 May 2025 14:59:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBEL5-0002p8-H1 for xen-devel@lists.xenproject.org; Sat, 03 May 2025 14:59:39 +0000 Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [2607:f8b0:4864:20::112a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3b873b87-282f-11f0-9eb4-5ba50f476ded; Sat, 03 May 2025 16:59:38 +0200 (CEST) Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-6fead015247so27501917b3.2 for ; Sat, 03 May 2025 07:59: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" X-Inumbo-ID: 3b873b87-282f-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746284377; x=1746889177; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4q+Qc6SlV9gZdCMK5o3Co8yk/mgFhtRau0S+hN2Hx6Y=; b=XjPuVKmiBkrOG8Upg65+JId9eeGU8EfJ+yh8Rbkro4EDBiqBDU5j1TVqIVbukTw22U +tMN+ZoCbgpLvEhTUmLjjJjv9jJ06t+ZYBXf9iy1POGAUzkyrFJCoewncb2clrGw/+te 73X70cUT5PiGrsjY5T5J0Uc/9EZBajW5f3uBqmLTL4rOUS/Qf3iuoQqkbfZmUIrUGvid JvxB37LtpOqh74l7p6a/DGPotN4HXnHOvBB9/+521UfIpDPOaeniTHktAbnAsdgE/IKB M+h434eeEXtcXY1GySA8vnoUkDxQJKsk3H877KBR7fw3UpRhBXe8zt+u2MfcH957bdji I7zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746284377; x=1746889177; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4q+Qc6SlV9gZdCMK5o3Co8yk/mgFhtRau0S+hN2Hx6Y=; b=vPb/XAy6sGkfRm7rfu0K4gM7DcjXkznihEUaNUH6L0l6iCDmX5inCBbW0Nswz0BQwL Z6C4utUeNJlpK5VOQzudW9MFKvX8dTqhDS7USUz1gNMSNmLHhbHZrq6uFZjuXb9ULXWc OaY+iWH36i3Y0F/gvb0ku9lCHz7PZPmLhNfDlVZMfP3+NH9wnqCGo0ExUffo9MtDbbmW h4pNBJBKUBQ68NY4zHMSXuDQcfzLANx4Xecf+TZ6mjCFrSQxf53ztT30VjPt/KWnqYVW wlNTnyjAyjncG66GelLB/q7iXqre2J+HpsUdutZhex9HFZmVVeK3/qjzDu+QoPyDjYFm fChQ== X-Forwarded-Encrypted: i=1; AJvYcCXQyd76KzhkExALOSOuFOoYog25lqADxOYVA4LPfQVdoQUvjSZSSKU3El0gPcmRLpqnzlHzQEYDNXU=@lists.xenproject.org X-Gm-Message-State: AOJu0YwVyLeGQ39ojurkwRtLS5ZOcp4QOnhWvKMiGTdYlAYyCIJwsUPw E6XuTaaN/YrVJZtQea55uGXrbI5w2HqS4groXabVZyU5W0TRDF623EZRQ5uQwv1aVOVNvSfpv2E cYn1+DrcYTpQW3pszacJUHT98sX0L6g== X-Gm-Gg: ASbGncv5nqwOKG54k61qu6jcd8+JncO62yq+Ry6rVAY1yzVJYy70L95zuqkeFRWRQ6j QneRX8A87yP7Z3yntOB3dZrhMD3680yndikGk1xct7yw3E9EBns9h/OG5OnaQmFrhNMd78T2hcb vBVuTPKFFiecWADnVgvRc/nVRFFW+Qjg== X-Google-Smtp-Source: AGHT+IEPWQ/FsgFWI8Ah2eiyVKUKGdDxNTbLeRyGv4I/o89MCiPd/pJQvrXZnmFmxE9bqLRhGjREtFW2SF9Y8o49ls8= X-Received: by 2002:a05:6902:1ac8:b0:e72:d88e:7af4 with SMTP id 3f1490d57ef6-e757d55f966mr1559769276.43.1746284377078; Sat, 03 May 2025 07:59:37 -0700 (PDT) MIME-Version: 1.0 References: <0f8c0e27-e60d-4e64-bc8a-6cb407c67ab2@xen.org> In-Reply-To: From: Jason Andryuk Date: Sat, 3 May 2025 10:59:24 -0400 X-Gm-Features: ATxdqUHeeIXirakMqjaldYjlbanK1MA3FOHoMkQ_OTgzuuF6Iwq0YvdcmjlUlRI Message-ID: Subject: Re: NULL pointer dereference in xenbus_thread->... To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Cc: Julien Grall , xen-devel , Juergen Gross Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 1, 2025 at 8:01=E2=80=AFPM Marek Marczykowski-G=C3=B3recki wrote: > > I'm curious what process_msg+0x18e/0x2f0 is. process_writes() has a > > direct call to wake_up(), but process_msg() calling req->cb(req) may > > be xs_wake_up() which is a thin wrapper over wake_up(). > > So, it's req->cb(req). Thanks for confirming. Regards, Jason From xen-devel-bounces@lists.xenproject.org Sat May 03 15:09:23 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 03 May 2025 15:09:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975390.1362895 (Exim 4.92) (envelope-from ) id 1uBEUQ-0004eh-4g; Sat, 03 May 2025 15:09:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975390.1362895; Sat, 03 May 2025 15:09:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBEUQ-0004ea-28; Sat, 03 May 2025 15:09:18 +0000 Received: by outflank-mailman (input) for mailman id 975390; Sat, 03 May 2025 15:09:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBEUO-0004eT-Ft for xen-devel@lists.xenproject.org; Sat, 03 May 2025 15:09:16 +0000 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [2607:f8b0:4864:20::b2b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9132b9e9-2830-11f0-9ffb-bf95429c2676; Sat, 03 May 2025 17:09:11 +0200 (CEST) Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-e63a159525bso2408821276.2 for ; Sat, 03 May 2025 08:09: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" X-Inumbo-ID: 9132b9e9-2830-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746284950; x=1746889750; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qfJheMZa7oRhvBxc7nxCAcYw3tBHtFICarHmGPYO6Hs=; b=lff43ST873yLH8MQ/C/ttmwHTSARkpsUNK+nvKYrvRVo9LB7xIYJDTnfJHS5MmKR1+ KMYWHXXc7LKgIB/W/DfK5Bosj6vDiGqvYJMfzd5TT3w+4uZJrSy6VAWDuzxqMApiQ+7y 79DD4n6hMr36OUs05LZaNmTV4zrmOyNrft1fx824VpvuT1vDJ4hLY6401pFXAjqit8uj Q8qFgKNn6XAZLtOAmnhawDsT/QpYBCrp1zw0zig8ivIqDt3rsnVp19px7Xg01U+eW4oE Pzf4/01pIZ6jNU1cwhwux0iAA6WweRT8ZTZV5RHf9B5DJ0Irze/5dVCK5kmAfcG5goSk /pMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746284950; x=1746889750; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qfJheMZa7oRhvBxc7nxCAcYw3tBHtFICarHmGPYO6Hs=; b=fgfPDt7yTVM7TUsHF6uInh9S9UZREu4Lx75hxlm0H7wAwjNg0/5rQRCkNnRri7h35d VaA6WoPQIkh4oKwow8/Pq1DPRlZ/zL+QelCTlpqt6eNxoLebGtfs8L0sj5LxG23Idx6/ hBIknPt9/VzgjYBJ6BAQtRUc6354hccaw/VSpT4z/LqXSqS015Thc9q/vH13ttHHAlPE fP4Pr5ncdp8J3291hdDJUQvisYFXM7yVpNfBCcPfHGm36Zj0QqPRmrBEZCGaJio1C7Io 6JE97wHPi4f4qUgwCQBA/K+radaWXAZmDlNX5A7flb4LRFYU7aje4bw+itjTHTCueb39 M7iA== X-Forwarded-Encrypted: i=1; AJvYcCXhDj6QFrofp46qEaz8psgGWxZDakJOdtJfGUjpaIuWkx1jnvivhz2cifqRC98Dj94vQZt9gQICWUM=@lists.xenproject.org X-Gm-Message-State: AOJu0YwJ17OmJ9wZ4GZgDe2IGC07F6Hgjpp6vDqBqPkFNACdyU6OZxdZ gLZICLYcaRnXuDxfbYPXFNztFXf1j8YFZcOXif/YYkKDBoCX/RMkD4XAgsQBe59QBwiF7xtsTCp 3i5lrZCgjFjP5IZFFNdwPR7s6aeo= X-Gm-Gg: ASbGnctAEHFpfbvWLBb5Gu1YPhMMdVGmAh8IBbUzHNX/nn1VGiwDOhdptp7bBCi9oKQ czWj55aXb+OtmFmu8R9Z9uk9rL1T9iOkrto5F9URlMgbek9weAaZQ+lYoo4fBGLb9AzP21Mb00m ReCyirExWKBAip1Dc0av5CtgAIPpwv1A== X-Google-Smtp-Source: AGHT+IGLTFzWWqcM8q6dknKJ15Q8aT0A/F537d/AuTvJFtSy0akHqrNPmiHWhzgVHZ/e2yvaM2YdEktEGTubLM/0KWo= X-Received: by 2002:a05:690c:7302:b0:6fe:eaac:e55f with SMTP id 00721157ae682-708e11b3c47mr36276787b3.9.1746284950076; Sat, 03 May 2025 08:09:10 -0700 (PDT) MIME-Version: 1.0 References: <0f8c0e27-e60d-4e64-bc8a-6cb407c67ab2@xen.org> <641aef98-5dde-4618-9fa4-7ccfa2e1989d@amd.com> In-Reply-To: From: Jason Andryuk Date: Sat, 3 May 2025 11:08:59 -0400 X-Gm-Features: ATxdqUGszREXZea456Tq2WloQP70-NlHT-_4C983tNQNTXiKYXX3_yxJFF_-dtg Message-ID: Subject: Re: NULL pointer dereference in xenbus_thread->... To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: Jason Andryuk , =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , Julien Grall , xen-devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 30, 2025 at 11:44=E2=80=AFAM J=C3=BCrgen Gro=C3=9F wrote: > I have looked at this issue multiple times now. > > Just some remarks what IMO could go wrong (I didn't find any proof that > this really happened, though), in case someone wants to double check: > > The most probably candidate for something going wrong is a use-after-free > of a struct xb_req_data element (normally named "req" in the related code= ). > > Some words about the not really obvious locking scheme used for those > elements: A "req" is owned by a thread as long as it isn't in any of the > lists it can live in (xs_reply_list or xb_write_list). Putting it into on= e > of the lists or removing it again requires to hold the xb_write_mutex. While I see how the ownership is transferred between lists and the static variables in process_writes(), xs_wait_for_reply()/read_reply() is looking at req, too. > A "req" needs to be in a certain state when either in one of the lists or > when being owned by a worker thread. > > I'm wondering whether it could happen that a thread waiting for a "req" > could be woken up and the "req" is being freed before the waiting thread > can react. Normally this shouldn't be possible, but "never say never". > What catched my eye today is the test of req->state =3D=3D xb_req_state_w= ait_reply > in process_msg() just after dropping the xb_write_mutex. This looks a lit= tle > bit fishy, but OTOH the request has been just removed from the xs_reply_l= ist, > so no mutex should be needed for that test. > > Possible candidates for such an "impossible" scenario include a wrap of > xs_request_id (not very probable, though, as having 4 billion Xenstore > requests "in flight" is rather unlikely IMHO). If read_reply() exits because req->err is set, and req->state is not queued or wait_reply, the req will be freed in xs_wait_for_reply(), but not removed from the list. If it is on the xs_reply_list, req->cb(req) could be called, but that would need req->state =3D=3D wait_reply. I don't see how this could happen, but it came to mind. Put another way, kfree() in xs_wait_for_reply() doesn't know if the req is on the list or not. I wonder if it would be better to just have if (req->state =3D=3D xb_req_state_got_reply) kfree(req); else req->state =3D xb_req_state_aborted; Maybe also some sort of assertion that req is not on a list, too. This would at least make it clear exactly when xs_wait_for_reply() is supposed to free req. Given these states: enum xb_req_state { xb_req_state_queued, xb_req_state_wait_reply, xb_req_state_got_reply, xb_req_state_aborted }; Being explicit on who frees each state would be good. Or if all list manipulations have to be protected by xb_write_mutex, then just let the "caller" xs_wait_for_reply() always unlink and kfree()? Yet it's unclear how req->cb(req) leads to a use-after-free. req->cb() was valid to make the call, but then the waitqueue was (probably) zeroed? That seems like a race. ... or is wake_up() faulting because xs_wait_for_reply() woke up and freed the req before wake_up() finished with it? __wake_up_common (kernel/sched/wait.c:85) is: list_for_each_entry_safe_from(curr, next, &wq_head->head, entry) { I'l need to look more into the wake_up() implementation... Regards, Jason From xen-devel-bounces@lists.xenproject.org Sat May 03 19:14:26 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 03 May 2025 19:14:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975433.1362906 (Exim 4.92) (envelope-from ) id 1uBIJQ-0000xA-FC; Sat, 03 May 2025 19:14:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975433.1362906; Sat, 03 May 2025 19:14:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBIJQ-0000x3-CC; Sat, 03 May 2025 19:14:12 +0000 Received: by outflank-mailman (input) for mailman id 975433; Sat, 03 May 2025 19:14:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBIJP-0000wx-5x for xen-devel@lists.xenproject.org; Sat, 03 May 2025 19:14:11 +0000 Received: from 004.mia.mailroute.net (004.mia.mailroute.net [199.89.3.7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c8eb5bf1-2852-11f0-9ffb-bf95429c2676; Sat, 03 May 2025 21:14:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by 004.mia.mailroute.net (Postfix) with ESMTP id 4ZqcsV3dB1zm0yTv; Sat, 3 May 2025 19:14:06 +0000 (UTC) Received: from 004.mia.mailroute.net ([127.0.0.1]) by localhost (004.mia [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id DqXzoqknLYju; Sat, 3 May 2025 19:13:58 +0000 (UTC) Received: from [192.168.51.14] (c-73-231-117-72.hsd1.ca.comcast.net [73.231.117.72]) (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) (Authenticated sender: bvanassche@acm.org) by 004.mia.mailroute.net (Postfix) with ESMTPSA id 4ZqcrR2bKbzm0yMS; Sat, 3 May 2025 19:13: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" X-Inumbo-ID: c8eb5bf1-2852-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject :user-agent:mime-version:date:date:message-id:received:received; s=mr01; t=1746299638; x=1748891639; bh=INtqWdF1ttpcGxLYcmEEmkHc r1sBjwlLz2bhiN/ZlGY=; b=RKuStUz1pg6Z4V5+H5A4kb2tpH0qoqhbIkzY5+Di 0Mx4FqbPL+wKIdXv00tSUygKf7k37efg+NegA9USEA+BtS9sCBdNxuJsDmcEZkXo KGK//P45RgKzu8d8/alXy0VIGoamRPWPYuJuGoA+pRvHTZS5rvfZ8o0ph1X5HX6J iTP5Of7qhYNNVXT8DuQLC0J7+xnCouyLt/xHnb0fNLYt31jsZFJ6Oj4CRIgSwz0L IaOUfuFPOR6U+kODE48fdLjKvbhtxcv8R6c3Ms1Bh+fzGYiKJWiOfkB3GG1TY+aB jrLZOMGZ2glyEj1WRg+H+/FJlug51RvdD9ZeWxSGVVTS0g== X-Virus-Scanned: by MailRoute Message-ID: <08163d8b-4056-4b84-82a1-3dd553ee6468@acm.org> Date: Sat, 3 May 2025 12:13:08 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC v3 0/8] kernel-hacking: introduce CONFIG_NO_AUTO_INLINE To: Brendan Jackman , Peter Zijlstra Cc: Christoph Hellwig , chenlinxuan@uniontech.com, Keith Busch , Jens Axboe , Sagi Grimberg , Andrew Morton , Yishai Hadas , Jason Gunthorpe , Shameer Kolothum , Kevin Tian , Alex Williamson , Peter Huewe , Jarkko Sakkinen , Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Nick Desaulniers , Bill Wendling , Justin Stitt , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Zi Yan , Mathieu Desnoyers , "Paul E. McKenney" , Boqun Feng , Dmitry Vyukov , Andrey Konovalov , Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-integrity@vger.kernel.org, linux-kbuild@vger.kernel.org, llvm@lists.linux.dev, Winston Wen , kasan-dev@googlegroups.com, xen-devel@lists.xenproject.org, Changbin Du , Linus Torvalds References: <20250429-noautoinline-v3-0-4c49f28ea5b5@uniontech.com> <20250429123504.GA13093@lst.de> <20250501150229.GU4439@noisy.programming.kicks-ass.net> Content-Language: en-US From: Bart Van Assche In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/1/25 8:22 AM, Brendan Jackman wrote: > Personally I sometimes spam a bunch of `noinline` into code > I'm debugging so this seems like a way to just slap that same thing on > the whole tree without dirtying the code, right? If this is for test builds only, has it been consider to add -fno-inline-functions as a local change in the top-level Makefile? Bart. From xen-devel-bounces@lists.xenproject.org Sun May 04 01:29:18 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 01:29:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975477.1362915 (Exim 4.92) (envelope-from ) id 1uBOAB-0002Qp-W7; Sun, 04 May 2025 01:29:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975477.1362915; Sun, 04 May 2025 01: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 1uBOAB-0002Qi-Si; Sun, 04 May 2025 01:29:03 +0000 Received: by outflank-mailman (input) for mailman id 975477; Sun, 04 May 2025 01:29:02 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBOAA-0002Qc-Cz for xen-devel@lists.xenproject.org; Sun, 04 May 2025 01:29:02 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [2604:1380:45d1:ec00::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 27d57f2e-2887-11f0-9eb4-5ba50f476ded; Sun, 04 May 2025 03:29:01 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 1B242A40294; Sun, 4 May 2025 01:23:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDA00C4CEE3; Sun, 4 May 2025 01:28: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" X-Inumbo-ID: 27d57f2e-2887-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1746322139; bh=7n/RkZelCee7HZb0JLnBTglCg0DQoVwRlQDp8IWWaHQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ewOq8mW8UDxL9+9ECv8Qfuakg+agxPoz8hWNSJQFDuvfrugw0npvbJUQxMy9Ahtg+ JM0F3+pCCGGpUGYUttE8oLGguaoQalZDqWc1OPU4/Xo3x4IPlVww/z628p+JTtuzL0 tuggwHoPh9Wt9A8kV+dO1nYp+gzyXcg1Mw2jHHRc= Date: Sat, 3 May 2025 18:28:58 -0700 From: Andrew Morton To: Petr =?UTF-8?B?VmFuxJtr?= Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Hildenbrand , Ryan Roberts , xen-devel@lists.xenproject.org, x86@kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2 1/1] mm: fix folio_pte_batch() on XEN PV Message-Id: <20250503182858.5a02729fcffd6d4723afcfc2@linux-foundation.org> In-Reply-To: <20250502215019.822-2-arkamar@atlas.cz> References: <20250502215019.822-1-arkamar@atlas.cz> <20250502215019.822-2-arkamar@atlas.cz> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, 2 May 2025 23:50:19 +0200 Petr Vaněk wrote: > On XEN PV, folio_pte_batch() can incorrectly batch beyond the end of a > folio due to a corner case in pte_advance_pfn(). Specifically, when the > PFN following the folio maps to an invalidated MFN, > > expected_pte = pte_advance_pfn(expected_pte, nr); > > produces a pte_none(). If the actual next PTE in memory is also > pte_none(), the pte_same() succeeds, > > if (!pte_same(pte, expected_pte)) > break; > > the loop is not broken, and batching continues into unrelated memory. > > ... Looks OK for now I guess but it looks like we should pay some attention to what types we're using. > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -248,11 +248,9 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr, > pte_t *start_ptep, pte_t pte, int max_nr, fpb_t flags, > bool *any_writable, bool *any_young, bool *any_dirty) > { > - unsigned long folio_end_pfn = folio_pfn(folio) + folio_nr_pages(folio); > - const pte_t *end_ptep = start_ptep + max_nr; > pte_t expected_pte, *ptep; > bool writable, young, dirty; > - int nr; > + int nr, cur_nr; > > if (any_writable) > *any_writable = false; > @@ -265,11 +263,15 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr, > VM_WARN_ON_FOLIO(!folio_test_large(folio) || max_nr < 1, folio); > VM_WARN_ON_FOLIO(page_folio(pfn_to_page(pte_pfn(pte))) != folio, folio); > > + /* Limit max_nr to the actual remaining PFNs in the folio we could batch. */ > + max_nr = min_t(unsigned long, max_nr, > + folio_pfn(folio) + folio_nr_pages(folio) - pte_pfn(pte)); > + Methinks max_nr really wants to be unsigned long. That will permit the cleanup of quite a bit of truncation, extension, signedness conversion and general type chaos in folio_pte_batch()'s various callers. And... Why does folio_nr_pages() return a signed quantity? It's a count. And why the heck is folio_pte_batch() inlined? It's larger then my first hard disk and it has five callsites! From xen-devel-bounces@lists.xenproject.org Sun May 04 06:48:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 06:48:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975501.1362925 (Exim 4.92) (envelope-from ) id 1uBT8m-0000J0-U7; Sun, 04 May 2025 06:47:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975501.1362925; Sun, 04 May 2025 06:47: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 1uBT8m-0000It-RL; Sun, 04 May 2025 06:47:56 +0000 Received: by outflank-mailman (input) for mailman id 975501; Sun, 04 May 2025 06:47:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBT8l-0000In-Nu for xen-devel@lists.xenproject.org; Sun, 04 May 2025 06:47:55 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b38e1cb9-28b3-11f0-9eb4-5ba50f476ded; Sun, 04 May 2025 08:47:53 +0200 (CEST) Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-679-bEQyplXNN5mADMbXF8hG8w-1; Sun, 04 May 2025 02:47:48 -0400 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-43ced8c2eb7so25787925e9.1 for ; Sat, 03 May 2025 23:47:48 -0700 (PDT) Received: from ?IPV6:2003:cb:c732:7200:c4da:f12e:1fa8:eaef? (p200300cbc7327200c4daf12e1fa8eaef.dip0.t-ipconnect.de. [2003:cb:c732:7200:c4da:f12e:1fa8:eaef]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-441b2b20a65sm138626545e9.32.2025.05.03.23.47.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 May 2025 23:47: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" X-Inumbo-ID: b38e1cb9-28b3-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1746341272; 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:autocrypt:autocrypt; bh=VciL2Vnq4XFO2l1GLh+8tGcQoZiSbi51G5aHAKQPPMU=; b=OO7oSl+jzM8B3zl/SLi/dFIndspV94s1ajGkM9U7erFh6lpNKPwqHF3ZEUVCckygyrveFp M4Sg1kCiXqS8hNmDWZdtokXMlxHsLrF9MGmVrLUNdmrFSihoi7+Mvz+gQQ06ohqS9p2nut bOkI9KAkXxrMybObnUL57Hz6fkxxY30= X-MC-Unique: bEQyplXNN5mADMbXF8hG8w-1 X-Mimecast-MFC-AGG-ID: bEQyplXNN5mADMbXF8hG8w_1746341268 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746341268; x=1746946068; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=VciL2Vnq4XFO2l1GLh+8tGcQoZiSbi51G5aHAKQPPMU=; b=vVae46JvzP86goXVF/Oh180Kkd5KNEh6f2VGknFTyK5XNQm/c9BiznJXI8+tw5dPRw DkKbF8Qa5Qti8INXnqtR/+c1wGJ3S1yB19umejhzmj526JdYH/CkilB8mQxsviSbQC+V EwxzT3BvNpUxTjCH8KuMMF+T78Z4gIUBkENl/np7kIlCM/0C2Qfc8KbT5LVnD3owEqMJ eyekLR98jR+BK2X2znaJ1qwDKC24ZrtttJ5ViOYM7cAZ1ig3B8bbOkF4Yp4WQSBSGx6k kb1nHwhxIBLW4ZRO7u0bZI4nTunFla6qR6QDLr0k6NBNv31Zt5E6gR/+ZSmioMiTViyP CTFQ== X-Forwarded-Encrypted: i=1; AJvYcCW2Y7lstXrJej3XkJlDfOXFa66vJoKichfQ3opn3Iktp6KLuK9CpEul7hnU8D2YkDYjtu115LjgL/Q=@lists.xenproject.org X-Gm-Message-State: AOJu0YyxWVzzzjyGIZgyfO74oObrcxlJ/AZZNXwW+xNzkGuk/tyXduWe PwFAEWnHk67WXu7QgplkFdIqPfLEkX3zpSzdFD8AFam4pa1ZonVGzHP5iqytwT7BSbgY+IlEL7t cEjxhKoeeYJpwcQoycCHDKBX9+bLXAGEWYyFQchIa9wEiU9pHSogzfN+A/Bxc+R9l X-Gm-Gg: ASbGncunlwRBsW3mK3ENPTpYml8MpLUtAwn0XxeWsi3I/BzkDZ8nS4b8lXLio+kdcO3 NUuwjkHdOos8FPKmJ8W4WstmUde5CIsc3fK1V4mC/tgFsetjbo8gkI6SWoI7HH3Z8xNgvTbg2f2 g2Gviv9QrhsQ3Jvtair3gCQOsFa+l/h5Y7gVlm4OdrauDguGRKD1RDS7zt+w3LMJaiiy5SVHLqm BcEOGrg6nhqZj2pYMUOmgkz5nrAofV/N81MO4uRg7w0rCXc2bLcjU6exw/fvvNnRtIEIXdG92c0 MnH952I4CWZETImB68gA/LFZ0Qa4VUJPJsdzOJFkln17JqbcuA5e7U17Nrhz6rFxKJpCxlZiaaV B+XGXfBHb+1WaKVJQmPT6OjS/UFvd8wMDHNJTOUA= X-Received: by 2002:a05:600c:5290:b0:43d:fa59:bcee with SMTP id 5b1f17b1804b1-441c49340e5mr20735035e9.33.1746341267771; Sat, 03 May 2025 23:47:47 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFXFB3FR+eN6PCitQ4q59SAduxE/fk7xHIzBkM+MEWxbylSCKCwT4qO0+BHzou0JizYj1Y0jw== X-Received: by 2002:a05:600c:5290:b0:43d:fa59:bcee with SMTP id 5b1f17b1804b1-441c49340e5mr20734905e9.33.1746341267422; Sat, 03 May 2025 23:47:47 -0700 (PDT) Message-ID: <9e3fb101-9a5d-43bb-924a-0df3c38333f8@redhat.com> Date: Sun, 4 May 2025 08:47:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] mm: fix folio_pte_batch() on XEN PV To: Andrew Morton , =?UTF-8?Q?Petr_Van=C4=9Bk?= Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ryan Roberts , xen-devel@lists.xenproject.org, x86@kernel.org, stable@vger.kernel.org References: <20250502215019.822-1-arkamar@atlas.cz> <20250502215019.822-2-arkamar@atlas.cz> <20250503182858.5a02729fcffd6d4723afcfc2@linux-foundation.org> From: David Hildenbrand Autocrypt: addr=david@redhat.com; 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 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: <20250503182858.5a02729fcffd6d4723afcfc2@linux-foundation.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: z2Su6aNNJsCcNryE2aZELQJcrror0ERi4RHhW8FetS8_1746341268 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 04.05.25 03:28, Andrew Morton wrote: > On Fri, 2 May 2025 23:50:19 +0200 Petr Vaněk wrote: > >> On XEN PV, folio_pte_batch() can incorrectly batch beyond the end of a >> folio due to a corner case in pte_advance_pfn(). Specifically, when the >> PFN following the folio maps to an invalidated MFN, >> >> expected_pte = pte_advance_pfn(expected_pte, nr); >> >> produces a pte_none(). If the actual next PTE in memory is also >> pte_none(), the pte_same() succeeds, >> >> if (!pte_same(pte, expected_pte)) >> break; >> >> the loop is not broken, and batching continues into unrelated memory. >> >> ... > > Looks OK for now I guess but it looks like we should pay some attention > to what types we're using. > >> --- a/mm/internal.h >> +++ b/mm/internal.h >> @@ -248,11 +248,9 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr, >> pte_t *start_ptep, pte_t pte, int max_nr, fpb_t flags, >> bool *any_writable, bool *any_young, bool *any_dirty) >> { >> - unsigned long folio_end_pfn = folio_pfn(folio) + folio_nr_pages(folio); >> - const pte_t *end_ptep = start_ptep + max_nr; >> pte_t expected_pte, *ptep; >> bool writable, young, dirty; >> - int nr; >> + int nr, cur_nr; >> >> if (any_writable) >> *any_writable = false; >> @@ -265,11 +263,15 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr, >> VM_WARN_ON_FOLIO(!folio_test_large(folio) || max_nr < 1, folio); >> VM_WARN_ON_FOLIO(page_folio(pfn_to_page(pte_pfn(pte))) != folio, folio); >> >> + /* Limit max_nr to the actual remaining PFNs in the folio we could batch. */ >> + max_nr = min_t(unsigned long, max_nr, >> + folio_pfn(folio) + folio_nr_pages(folio) - pte_pfn(pte)); >> + > > Methinks max_nr really wants to be unsigned long. We only batch within a single PTE table, so an integer was sufficient. The unsigned value is the result of a discussion with Ryan regarding similar/related (rmap) functions: " Personally I'd go with signed int (since that's what all the counters in struct folio that we are manipulating are, underneath the atomic_t) then check that nr_pages > 0 in __folio_rmap_sanity_checks(). " https://lore.kernel.org/linux-mm/20231204142146.91437-14-david@redhat.com/T/#ma0bfff0102f0f2391dfa94aa22a8b7219b92c957 As soon as we let "max_nr" be an "unsigned long", also the return value should be an "unsigned long", and everybody calling that function. In this case here, we should likely just use whatever type "max_nr" is. Not sure myself if we should change that here to unsigned long or long. Some callers also operate with the negative values IIRC (e.g., adjust the RSS by doing -= nr). > That will permit the > cleanup of quite a bit of truncation, extension, signedness conversion > and general type chaos in folio_pte_batch()'s various callers. > > And... > > Why does folio_nr_pages() return a signed quantity? It's a count. A partial answer is in 1ea5212aed068 ("mm: factor out large folio handling from folio_nr_pages() into folio_large_nr_pages()"), where I stumbled over the reason for a signed value myself and at least made the other functions be consistent with folio_nr_pages(): " While at it, let's consistently return a "long" value from all these similar functions. Note that we cannot use "unsigned int" (even though _folio_nr_pages is of that type), because it would break some callers that do stuff like "-folio_nr_pages()". Both "int" or "unsigned long" would work as well. " Note that folio_nr_pages() returned a "long" since the very beginning. Probably using a signed value for consistency because also mapcounts / refcounts are all signed. > > And why the heck is folio_pte_batch() inlined? It's larger then my > first hard disk and it has five callsites! :) In case of fork/zap we really want it inlined because (1) We want to optimize out all of the unnecessary checks we added for other users (2) Zap/fork code is very sensitive to function call overhead Probably, as that function sees more widespread use, we might want a non-inlined variant that can be used in places where performance doesn't matter all that much (although I am not sure there will be that many). -- Cheers, David / dhildenb From xen-devel-bounces@lists.xenproject.org Sun May 04 07:16:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 07:16:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975522.1362936 (Exim 4.92) (envelope-from ) id 1uBTZq-0004Zq-2x; Sun, 04 May 2025 07:15:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975522.1362936; Sun, 04 May 2025 07:15: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 1uBTZp-0004Zj-Vw; Sun, 04 May 2025 07:15:53 +0000 Received: by outflank-mailman (input) for mailman id 975522; Sun, 04 May 2025 07:15:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBTZo-0004ZK-Sr for xen-devel@lists.xenproject.org; Sun, 04 May 2025 07:15:52 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9aab5463-28b7-11f0-9ffb-bf95429c2676; Sun, 04 May 2025 09:15:49 +0200 (CEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id C6CF2A4C040; Sun, 4 May 2025 07:10:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF4ACC4CEE7; Sun, 4 May 2025 07:15: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" X-Inumbo-ID: 9aab5463-28b7-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1746342948; bh=VFl4En76y+OpLSujTCsVixWtJLfVBo8Fs18pWu67NIM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=2uXzKB5tvtLWjn/EIY9A1H8ngwh4gxek1y6s8EfSOlGHERXtBEhbis3cIKTA95NjD yjN42znkaYuXQtcC5AV7PmRQ432nN/JjnMJEbs5NSR1otBH6CPfHyYBriZnESpnGbC /m0ml7+nmhQfFTbiTpnqkt55ZUJbHolqqTwmGm24= Date: Sun, 4 May 2025 00:15:47 -0700 From: Andrew Morton To: David Hildenbrand Cc: Petr =?UTF-8?Q?Van=C4=9Bk?= , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ryan Roberts , xen-devel@lists.xenproject.org, x86@kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2 1/1] mm: fix folio_pte_batch() on XEN PV Message-Id: <20250504001547.177b2aba8c2ffbfe63e0552e@linux-foundation.org> In-Reply-To: <9e3fb101-9a5d-43bb-924a-0df3c38333f8@redhat.com> References: <20250502215019.822-1-arkamar@atlas.cz> <20250502215019.822-2-arkamar@atlas.cz> <20250503182858.5a02729fcffd6d4723afcfc2@linux-foundation.org> <9e3fb101-9a5d-43bb-924a-0df3c38333f8@redhat.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 4 May 2025 08:47:45 +0200 David Hildenbrand wrote: > > > > Methinks max_nr really wants to be unsigned long. > > We only batch within a single PTE table, so an integer was sufficient. > > The unsigned value is the result of a discussion with Ryan regarding similar/related > (rmap) functions: > > " > Personally I'd go with signed int (since > that's what all the counters in struct folio that we are manipulating are, > underneath the atomic_t) then check that nr_pages > 0 in > __folio_rmap_sanity_checks(). > " > > https://lore.kernel.org/linux-mm/20231204142146.91437-14-david@redhat.com/T/#ma0bfff0102f0f2391dfa94aa22a8b7219b92c957 > > As soon as we let "max_nr" be an "unsigned long", also the return value > should be an "unsigned long", and everybody calling that function. > > In this case here, we should likely just use whatever type "max_nr" is. > > Not sure myself if we should change that here to unsigned long or long. Some > callers also operate with the negative values IIRC (e.g., adjust the RSS by doing -= nr). "rss -= nr" doesn't require, expect or anticipate that `nr' can be negative! > > > That will permit the > > cleanup of quite a bit of truncation, extension, signedness conversion > > and general type chaos in folio_pte_batch()'s various callers. > > > And... > > > > Why does folio_nr_pages() return a signed quantity? It's a count. > > A partial answer is in 1ea5212aed068 ("mm: factor out large folio handling > from folio_nr_pages() into folio_large_nr_pages()"), where I stumbled over the > reason for a signed value myself and at least made the other > functions be consistent with folio_nr_pages(): > > " > While at it, let's consistently return a "long" value from all these > similar functions. Note that we cannot use "unsigned int" (even though > _folio_nr_pages is of that type), because it would break some callers that > do stuff like "-folio_nr_pages()". Both "int" or "unsigned long" would > work as well. > > " > > Note that folio_nr_pages() returned a "long" since the very beginning. Probably using > a signed value for consistency because also mapcounts / refcounts are all signed. Geeze. Can we step back and look at what we're doing? Anything which counts something (eg, has "nr" in the identifier) cannot be negative. It's that damn "int" thing. I think it was always a mistake that the C language's go-to type is a signed one. It's a system programming language and system software rarely deals with negative scalars. Signed scalars are the rare case. I do expect that the code in and around here would be cleaner and more reliable if we were to do a careful expunging of inappropriately signed variables. > > > > > And why the heck is folio_pte_batch() inlined? It's larger then my > > first hard disk and it has five callsites! > > :) > > In case of fork/zap we really want it inlined because > > (1) We want to optimize out all of the unnecessary checks we added for other users > > (2) Zap/fork code is very sensitive to function call overhead > > Probably, as that function sees more widespread use, we might want a > non-inlined variant that can be used in places where performance doesn't > matter all that much (although I am not sure there will be that many). a quick test. before: text data bss dec hex filename 12380 470 0 12850 3232 mm/madvise.o 52975 2689 24 55688 d988 mm/memory.o 25305 1448 2096 28849 70b1 mm/mempolicy.o 8573 924 4 9501 251d mm/mlock.o 20950 5864 16 26830 68ce mm/rmap.o (120183) after: text data bss dec hex filename 11916 470 0 12386 3062 mm/madvise.o 52990 2697 24 55711 d99f mm/memory.o 25161 1448 2096 28705 7021 mm/mempolicy.o 8381 924 4 9309 245d mm/mlock.o 20806 5864 16 26686 683e mm/rmap.o (119254) so uninlining saves a kilobyte of text - less than I expected but almost 1%. Quite a lot of the inlines in internal.h could do with having a critical eye upon them. From xen-devel-bounces@lists.xenproject.org Sun May 04 08:59:14 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 08:59:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975542.1362946 (Exim 4.92) (envelope-from ) id 1uBVBb-0001MM-Cg; Sun, 04 May 2025 08:58:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975542.1362946; Sun, 04 May 2025 08:58:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBVBb-0001MF-8O; Sun, 04 May 2025 08:58:59 +0000 Received: by outflank-mailman (input) for mailman id 975542; Sun, 04 May 2025 08:58:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBVBa-0001M9-Lk for xen-devel@lists.xenproject.org; Sun, 04 May 2025 08:58:58 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fe88fb92-28c5-11f0-9ffb-bf95429c2676; Sun, 04 May 2025 10:58:50 +0200 (CEST) Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-186-Qzt0BGmZPy2QuSSlsUzgtg-1; Sun, 04 May 2025 04:58:47 -0400 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-43ceb011ea5so18967045e9.2 for ; Sun, 04 May 2025 01:58:47 -0700 (PDT) Received: from ?IPV6:2003:cb:c732:7200:c4da:f12e:1fa8:eaef? (p200300cbc7327200c4daf12e1fa8eaef.dip0.t-ipconnect.de. [2003:cb:c732:7200:c4da:f12e:1fa8:eaef]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-441b8a31695sm97450265e9.40.2025.05.04.01.58.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 May 2025 01:58: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" X-Inumbo-ID: fe88fb92-28c5-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1746349129; 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:autocrypt:autocrypt; bh=vj3NJsau7qgGczjDe65tGwTFiQ1Pl04vVciIlmYsMD8=; b=eM69n1LfPwPCm7KSqnNS+a8vRNGxcDnfjt4rU46AiPGL/G4BcWvjIU9IqBTStjIkLSQwWF fGqSnVVJqD2+QKI1PjsUUyugt9FOSPbyMe36F96vs6kX9QqSZuRwz4uELj4lMg38tUDcRf sg0ik4QHvFZ3qsNlIIqm66ydLk9Xdgw= X-MC-Unique: Qzt0BGmZPy2QuSSlsUzgtg-1 X-Mimecast-MFC-AGG-ID: Qzt0BGmZPy2QuSSlsUzgtg_1746349127 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746349126; x=1746953926; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=vj3NJsau7qgGczjDe65tGwTFiQ1Pl04vVciIlmYsMD8=; b=wmi2AEc7qIiy1RXgR6LbfOd/9TyVbHCooMANDc614+jxn9U4jYoMijXYQ3JMT0hpKe FR/JAoE/t9e3oHGAAMIvY6OX/5alst7cyRb/6o2Kzpn4v7YK7s7smymyMBKF7wDom6L1 JsIRrc9O0irhCXCfWKbvlJukwzt46PA/OTSCBhhBQofPatuXiX6DXRjujIKYI/EKUFre MwOeCicqiVd07a5fwaLNl2RpCxinPmp8nzRcaTMhIHb6C0Btmm5/AMCWXVjwxBAA020W GAJnJZ3+XqhZ5KezxF5zmjn9SgJkZ/2fMBsg3EjUvdG02gSZ7fd2ecCsPVqx/z63mna7 RLyQ== X-Forwarded-Encrypted: i=1; AJvYcCWwTRuigt10nVCZbu/bsAbamn6KHDOAqfKtSaCNTfIJfr8klrE/69Eic5aY4Aq2WzJzgClX+rpkOuA=@lists.xenproject.org X-Gm-Message-State: AOJu0YxT6YSkIwvnj2WRdZYUwlqEpwX4dP2cCjkDRIVYo2kV/unbcxdP tCG8c2rh0ZDc0Bs+ON4hGcdCRy8CpTyS+MAl/kjifx8U0yQlTn8UXsk9CO0ktlABJZziVuR2mKZ o2/R7e/qKFjdBxiqngC73xZIdN/b0vLdN0EL9d59CWV1oMWcZOT14sosFbSnjfL9i X-Gm-Gg: ASbGncvqU9S+fR/1KmmcKnXf0GvkXpkkxqkMwE3EyqaffoSjC6r3QdWMCJmAgVz8UsQ JPd3bW7bOo4bZHG19zAJKiVeCJfDnIYlupqUiIUsarvXD9Hxb+Um9boaMdmgL5VOLED22T5ryGd FGJ0NFhnt4t84SoLB3z3bf+Pa8ZLkS3fxmfoGLvmjXbbf1570LT5nDqBua0yEmZ+WK6KErWUYD0 Q0nBDBX8vkMYel2O5zia5V+mJg01pRGMxQvJDM/xDRrODE4PhT0t4n2syJC5GihdR21ahx3LCZN KOHwcllkSom60+o0Hi4zz9sR/2zcPMILfMjGqkZryQnhgB1Yeand2l3E39Rw1z/svauitaT/pbu OcN54xejy0NcBTwg2nqPMhwYYg5XP6baG3QeLS9w= X-Received: by 2002:a05:600c:1d8c:b0:43d:4e9:27f3 with SMTP id 5b1f17b1804b1-441c48bc74fmr29232045e9.9.1746349126541; Sun, 04 May 2025 01:58:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEn3IQ0vSijkX0LfADp/dGBPf2e0AfGQt6rZMhiI63QBK6irAZUw+VWNy36ePcsHVSEXhRqxA== X-Received: by 2002:a05:600c:1d8c:b0:43d:4e9:27f3 with SMTP id 5b1f17b1804b1-441c48bc74fmr29231845e9.9.1746349126008; Sun, 04 May 2025 01:58:46 -0700 (PDT) Message-ID: <62990a3f-524f-4362-8f64-2fc582986eba@redhat.com> Date: Sun, 4 May 2025 10:58:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] mm: fix folio_pte_batch() on XEN PV To: Andrew Morton Cc: =?UTF-8?Q?Petr_Van=C4=9Bk?= , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ryan Roberts , xen-devel@lists.xenproject.org, x86@kernel.org, stable@vger.kernel.org References: <20250502215019.822-1-arkamar@atlas.cz> <20250502215019.822-2-arkamar@atlas.cz> <20250503182858.5a02729fcffd6d4723afcfc2@linux-foundation.org> <9e3fb101-9a5d-43bb-924a-0df3c38333f8@redhat.com> <20250504001547.177b2aba8c2ffbfe63e0552e@linux-foundation.org> From: David Hildenbrand Autocrypt: addr=david@redhat.com; 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 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: <20250504001547.177b2aba8c2ffbfe63e0552e@linux-foundation.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: YKK6rxa25hunckxZnf-TEVIs8bFRJlqTVSUNAaVNe74_1746349127 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04.05.25 09:15, Andrew Morton wrote: > On Sun, 4 May 2025 08:47:45 +0200 David Hildenbrand wrote: > >>> >>> Methinks max_nr really wants to be unsigned long. >> >> We only batch within a single PTE table, so an integer was sufficient. >> >> The unsigned value is the result of a discussion with Ryan regarding similar/related >> (rmap) functions: >> >> " >> Personally I'd go with signed int (since >> that's what all the counters in struct folio that we are manipulating are, >> underneath the atomic_t) then check that nr_pages > 0 in >> __folio_rmap_sanity_checks(). >> " >> >> https://lore.kernel.org/linux-mm/20231204142146.91437-14-david@redhat.com/T/#ma0bfff0102f0f2391dfa94aa22a8b7219b92c957 >> >> As soon as we let "max_nr" be an "unsigned long", also the return value >> should be an "unsigned long", and everybody calling that function. >> >> In this case here, we should likely just use whatever type "max_nr" is. >> >> Not sure myself if we should change that here to unsigned long or long. Some >> callers also operate with the negative values IIRC (e.g., adjust the RSS by doing -= nr). > > "rss -= nr" doesn't require, expect or anticipate that `nr' can be negative! The one thing I ran into with "unsigned int" around folio_nr_pages() was that if you pass -folio-nr_pages() into a function that expects an "long" (add vs. remove a value to a counter), then the result might not be what one would expect when briefly glimpsing at the code: #include static __attribute__((noinline)) void print(long diff) { printf("%ld\n", diff); } static int value_int() { return 12345; } static unsigned int value_unsigned_int() { return 12345; } static int value_long() { return 12345; } static unsigned long value_unsigned_long() { return 12345; } int main(void) { print(-value_int()); print(-value_unsigned_int()); print(-value_long()); print(-value_unsigned_long()); return 0; } $ ./tmp -12345 4294954951 -12345 -12345 So, I am fine with using "unsigned long" (as stated in that commit description below). > >> >>> That will permit the >>> cleanup of quite a bit of truncation, extension, signedness conversion >>> and general type chaos in folio_pte_batch()'s various callers. >>>> And... >>> >>> Why does folio_nr_pages() return a signed quantity? It's a count. >> >> A partial answer is in 1ea5212aed068 ("mm: factor out large folio handling >> from folio_nr_pages() into folio_large_nr_pages()"), where I stumbled over the >> reason for a signed value myself and at least made the other >> functions be consistent with folio_nr_pages(): >> >> " >> While at it, let's consistently return a "long" value from all these >> similar functions. Note that we cannot use "unsigned int" (even though >> _folio_nr_pages is of that type), because it would break some callers that >> do stuff like "-folio_nr_pages()". Both "int" or "unsigned long" would >> work as well. >> >> " >> >> Note that folio_nr_pages() returned a "long" since the very beginning. Probably using >> a signed value for consistency because also mapcounts / refcounts are all signed. > > Geeze. > > Can we step back and look at what we're doing? Anything which counts > something (eg, has "nr" in the identifier) cannot be negative. Yes. Unless we want to catch underflows (e.g., mapcount / refcount). For "nr_pages" I agree. > > It's that damn "int" thing. I think it was always a mistake that the C > language's go-to type is a signed one. Yeah. But see above that "unsigned int" in combination with long can also cause pain. > It's a system programming > language and system software rarely deals with negative scalars. > Signed scalars are the rare case. > > I do expect that the code in and around here would be cleaner and more > reliable if we were to do a careful expunging of inappropriately signed > variables. Maybe, but it would mostly be a "int -> unsigned long" conversion, probably not much more. I'm not against cleaning that up at all. > >> >>> >>> And why the heck is folio_pte_batch() inlined? It's larger then my >>> first hard disk and it has five callsites! >> >> :) >> >> In case of fork/zap we really want it inlined because >> >> (1) We want to optimize out all of the unnecessary checks we added for other users >> >> (2) Zap/fork code is very sensitive to function call overhead >> >> Probably, as that function sees more widespread use, we might want a >> non-inlined variant that can be used in places where performance doesn't >> matter all that much (although I am not sure there will be that many). > > a quick test. > > before: > text data bss dec hex filename > 12380 470 0 12850 3232 mm/madvise.o > 52975 2689 24 55688 d988 mm/memory.o > 25305 1448 2096 28849 70b1 mm/mempolicy.o > 8573 924 4 9501 251d mm/mlock.o > 20950 5864 16 26830 68ce mm/rmap.o > > (120183) > > after: > > text data bss dec hex filename > 11916 470 0 12386 3062 mm/madvise.o > 52990 2697 24 55711 d99f mm/memory.o > 25161 1448 2096 28705 7021 mm/mempolicy.o > 8381 924 4 9309 245d mm/mlock.o > 20806 5864 16 26686 683e mm/rmap.o > > (119254) > > so uninlining saves a kilobyte of text - less than I expected but > almost 1%. As I said, for fork+zap/unmap we really want to inline -- the first two users of that function when that function was still simpler and resided in mm/memory.o. For the other users, probably okay to have a non-inlined one in mm/util.c . -- Cheers, David / dhildenb From xen-devel-bounces@lists.xenproject.org Sun May 04 13:56:41 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 13:56:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975569.1362955 (Exim 4.92) (envelope-from ) id 1uBZpR-0003jk-9G; Sun, 04 May 2025 13:56:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975569.1362955; Sun, 04 May 2025 13:56:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBZpR-0003jd-6h; Sun, 04 May 2025 13:56:25 +0000 Received: by outflank-mailman (input) for mailman id 975569; Sun, 04 May 2025 13:56:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBZpO-0003jW-HQ for xen-devel@lists.xenproject.org; Sun, 04 May 2025 13:56:23 +0000 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8e3c7962-28ef-11f0-9eb4-5ba50f476ded; Sun, 04 May 2025 15:56: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" X-Inumbo-ID: 8e3c7962-28ef-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1746366978; x=1746626178; bh=BAs05A9tNZO9zdDHA65HFjLKHnUIRzqLHxkHq69nJCM=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=V+Kgf/vyk2Pt3L4cOMuvwWtB4T7u/cVFzSnXNjCM/OuaLbgy8E4K7TN3NzgfkmsGb 3x4h90EDzfRwvHAlr8xiH5VLrXZx+BI913uyS8itwibKTZdyMD46nSLhsTj4PKfWTz DKBc11542pTGwlN4B8mmoiLHlrkJBOQUkTrXnnLrk6FsfPMUEjqADxFbgwN+Fk+WzR N4fx1FOAkVlUzorv8uMx7WvHrGH5YlFZl4UnWvhYkUxxUyKsrwtFhWd3mFyvoFGwcl 7fdkyXdk0mZ3bTy2UlhQyNX+iz0hKsfIPLnCXB9Gf2hyMwZdcLtlhGtzeGzNh7ci3p /397mbkrFGnww== Date: Sun, 04 May 2025 13:56:11 +0000 To: xen-devel@lists.xenproject.org From: dmkhn@proton.me Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com Subject: [PATCH v5 0/2] xen/domain: domain ID allocation Message-ID: <20250504135544.730906-1-dmukhin@ford.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: 66f71772ddeb5757fde42b88c51bd87d1f9b7931 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The patch series adds new library calls for allocating domain IDs. Patch 1 introduces new domid_{init,alloc,free} calls. Patch 2 adjusts hardware domain ID treatment on Arm. Link to v4: https://lore.kernel.org/xen-devel/20250422215322.521464-1-dmukh= in@ford.com/ Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1= 799395667 Denis Mukhin (2): xen/domain: unify domain ID allocation xen/domain: adjust domain ID allocation for Arm xen/arch/arm/dom0less-build.c | 17 ++++---- xen/arch/arm/domain_build.c | 17 +++++--- xen/arch/arm/setup.c | 2 + xen/arch/x86/setup.c | 13 +++++-- xen/common/domain.c | 73 +++++++++++++++++++++++++++++++++++ xen/common/domctl.c | 41 ++------------------ xen/include/xen/domain.h | 4 ++ 7 files changed, 112 insertions(+), 55 deletions(-) --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun May 04 13:56:41 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 13:56:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975571.1362971 (Exim 4.92) (envelope-from ) id 1uBZpZ-00041c-Px; Sun, 04 May 2025 13:56:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975571.1362971; Sun, 04 May 2025 13: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 1uBZpZ-0003zw-Jv; Sun, 04 May 2025 13:56:33 +0000 Received: by outflank-mailman (input) for mailman id 975571; Sun, 04 May 2025 13:56:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBZpY-0003xj-Di for xen-devel@lists.xenproject.org; Sun, 04 May 2025 13:56:32 +0000 Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9344f675-28ef-11f0-9ffb-bf95429c2676; Sun, 04 May 2025 15:56: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" X-Inumbo-ID: 9344f675-28ef-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1746366987; x=1746626187; bh=Q/Risu0ysxwT1e/+FvDwhLYw5obC4RYhC7xzQWwOX9Q=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=B7RzvoAzvLhpaa1x6JXJjl7EtPXi5F13JbXCSwEgcY+t29GZginOc3MvHHEmBuMUo WrNMNtz/WRY3Z9aYzcU0E8JxDLhXeVA8zFN9OraoUgHM5n10DaSfbK5KZm5kjilueR A99SxsRFIKQbY+MjJvYb++kaMgSovScuQYsJMp1adjI30qtYBla7iiEMKsSbmR6S+b kvS6+lXkDFere4FcDURm0NQ1Pjhx1PDlC+3TwOUtCd6YXY/+82/u3yHvFbTLSmdPjo aPYRdwTo1MkfcQckyR0D1gfjVOJUSOlBRcbGm1IHfq/W7Z4lFCqPhjWO7L2VW5fltD xGkFlDCVJR/nA== Date: Sun, 04 May 2025 13:56:24 +0000 To: xen-devel@lists.xenproject.org From: dmkhn@proton.me Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com Subject: [PATCH v5 2/2] xen/domain: adjust domain ID allocation for Arm Message-ID: <20250504135544.730906-3-dmukhin@ford.com> In-Reply-To: <20250504135544.730906-1-dmukhin@ford.com> References: <20250504135544.730906-1-dmukhin@ford.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: f9edfeb1b897157e447f19a61e3e5127edbfb73a MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Denis Mukhin Remove the hardcoded domain ID 0 allocation for hardware domain and replace= it with a call to get_initial_domain_id() (returns the value of hardware_domid= on Arm). Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_domain_id= () ID is skipped during domain ID allocation to cover domU case. Signed-off-by: Denis Mukhin --- Changes since v4: - new patch --- xen/arch/arm/dom0less-build.c | 9 +++------ xen/arch/arm/domain_build.c | 4 ++-- xen/common/domain.c | 5 ++++- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 9eb64ec60d..61e01b7306 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -1216,14 +1216,11 @@ void __init create_domUs(void) if ( !llc_coloring_enabled && llc_colors_str ) panic("'llc-colors' found, but LLC coloring is disabled\n"); =20 - /* - * The variable max_init_domid is initialized with zero, so here i= t's - * very important to use the pre-increment operator to call - * domain_create() with a domid > 0. (domid =3D=3D 0 is reserved f= or Dom0) - */ - domid =3D domid_alloc(++max_init_domid); + domid =3D domid_alloc(DOMID_INVALID); if ( domid =3D=3D DOMID_INVALID ) panic("Error allocating ID for domain %s\n", dt_node_name(node= )); + if ( max_init_domid < domid ) + max_init_domid =3D domid; =20 d =3D domain_create(domid, &d_cfg, flags); if ( IS_ERR(d) ) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 29e22a8809..c85d72fdf1 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -2396,9 +2396,9 @@ void __init create_dom0(void) if ( !llc_coloring_enabled ) flags |=3D CDF_directmap; =20 - domid =3D domid_alloc(0); + domid =3D domid_alloc(get_initial_domain_id()); if ( domid =3D=3D DOMID_INVALID ) - panic("Error allocating domain ID 0\n"); + panic("Error allocating domain ID %d\n", get_initial_domain_id()); =20 dom0 =3D domain_create(domid, &dom0_cfg, flags); if ( IS_ERR(dom0) ) diff --git a/xen/common/domain.c b/xen/common/domain.c index 0ba3cdc47d..055397b5aa 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -85,7 +85,7 @@ void __init domid_init(void) * * If hint is outside of valid [0..DOMID_FIRST_RESERVED - 1] range of IDs, * perform an exhaustive search starting from the end of the used domain I= D - * range. + * range, excluding get_initial_domain_id() ID. */ domid_t domid_alloc(domid_t domid) { @@ -103,6 +103,9 @@ domid_t domid_alloc(domid_t domid) if ( domid =3D=3D DOMID_FIRST_RESERVED ) domid =3D 0; =20 + if ( domid =3D=3D get_initial_domain_id() ) + continue; + if ( !rangeset_contains_singleton(domid_rangeset, domid) ) break; } --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun May 04 13:56:41 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 13:56:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975570.1362966 (Exim 4.92) (envelope-from ) id 1uBZpZ-0003yS-G1; Sun, 04 May 2025 13:56:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975570.1362966; Sun, 04 May 2025 13: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 1uBZpZ-0003yL-DE; Sun, 04 May 2025 13:56:33 +0000 Received: by outflank-mailman (input) for mailman id 975570; Sun, 04 May 2025 13:56:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBZpY-0003xj-2t for xen-devel@lists.xenproject.org; Sun, 04 May 2025 13:56:32 +0000 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9202901f-28ef-11f0-9ffb-bf95429c2676; Sun, 04 May 2025 15:56: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" X-Inumbo-ID: 9202901f-28ef-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1746366985; x=1746626185; bh=w9ckJQdRAD0zaNmswpycxiVeLzH9Wm6su/mpnwt3nQM=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=FQ6DYigNCfwk0GyR4HPq6T2emrS2bAs4EQrLm+6MO127eCrMdA2yfMOm1E1b21Dxg BNv/nzT201qmA2jl1f3obgsoIKIOW+7L9jd3W9apm6MODkqLDY0Tp8kkfpvP0OMp65 C1JpFcbcpYFCZkPESv4G9faKV2WDq89jjCKaJyF0iGu/YvYnCKJ2vpBvGDNc9FPeGY Rn0mMP/9zJkArUWe/tJGSPdEy7UNJwjoBSSmx5ajjW7KvGNv8mpo/toLMz8dEm9amH 87OGWmF8jKTwlHS5mLGL/1txbHfFxIULKmbrvQWo62EZLM7pM5t9SF6+xw6ia5hv7t ufbrspoa7Z53Q== Date: Sun, 04 May 2025 13:56:19 +0000 To: xen-devel@lists.xenproject.org From: dmkhn@proton.me Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com Subject: [PATCH v5 1/2] xen/domain: unify domain ID allocation Message-ID: <20250504135544.730906-2-dmukhin@ford.com> In-Reply-To: <20250504135544.730906-1-dmukhin@ford.com> References: <20250504135544.730906-1-dmukhin@ford.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: d1ee73ced11497387aa6f688008deb6d0012f1ac MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Denis Mukhin Currently, hypervisor code has two different non-system domain ID allocatio= n implementations: (a) Sequential IDs allocation in dom0less Arm code based on max_init_domi= d; (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use max_init_domid (both Arm and x86). It makes sense to have a common helper code for such task across architectu= res (Arm and x86) and between dom0less / toolstack domU allocation. Wrap the domain ID allocation as an arch-independent function domid_alloc()= in common/domain.c based on rangeset. Allocation algorithm: - If an explicit domain ID is provided, verify its availability and use it if ID is not used; - Otherwise, perform an exhaustive search starting from the end of the used domain ID range. domid_alloc() guarantees that two subsequent calls will result in different IDs allocation. Initialize the domain IDs rangeset from the new domid_init() which is calle= d from arch setup code. Also, remove is_free_domid() helper as it is not needed now. No functional change intended. Signed-off-by: Denis Mukhin --- Changes since v4: - reworked to rangeset - dropped hardware_domid change --- xen/arch/arm/dom0less-build.c | 10 +++-- xen/arch/arm/domain_build.c | 17 ++++++--- xen/arch/arm/setup.c | 2 + xen/arch/x86/setup.c | 13 +++++-- xen/common/domain.c | 70 +++++++++++++++++++++++++++++++++++ xen/common/domctl.c | 41 ++------------------ xen/include/xen/domain.h | 4 ++ 7 files changed, 107 insertions(+), 50 deletions(-) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index a356fc94fc..9eb64ec60d 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -1038,15 +1038,13 @@ void __init create_domUs(void) }; unsigned int flags =3D 0U; bool has_dtb =3D false; + domid_t domid; uint32_t val; int rc; =20 if ( !dt_device_is_compatible(node, "xen,domain") ) continue; =20 - if ( (max_init_domid + 1) >=3D DOMID_FIRST_RESERVED ) - panic("No more domain IDs available\n"); - if ( dt_property_read_u32(node, "capabilities", &val) ) { if ( val & ~DOMAIN_CAPS_MASK ) @@ -1223,7 +1221,11 @@ void __init create_domUs(void) * very important to use the pre-increment operator to call * domain_create() with a domid > 0. (domid =3D=3D 0 is reserved f= or Dom0) */ - d =3D domain_create(++max_init_domid, &d_cfg, flags); + domid =3D domid_alloc(++max_init_domid); + if ( domid =3D=3D DOMID_INVALID ) + panic("Error allocating ID for domain %s\n", dt_node_name(node= )); + + d =3D domain_create(domid, &d_cfg, flags); if ( IS_ERR(d) ) panic("Error creating domain %s (rc =3D %ld)\n", dt_node_name(node), PTR_ERR(d)); diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 270a6b97e4..29e22a8809 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -2371,6 +2371,7 @@ void __init create_dom0(void) .grant_opts =3D XEN_DOMCTL_GRANT_version(opt_gnttab_max_version), }; unsigned int flags =3D CDF_privileged | CDF_hardware; + domid_t domid; int rc; =20 /* The vGIC for DOM0 is exactly emulating the hardware GIC */ @@ -2395,19 +2396,25 @@ void __init create_dom0(void) if ( !llc_coloring_enabled ) flags |=3D CDF_directmap; =20 - dom0 =3D domain_create(0, &dom0_cfg, flags); + domid =3D domid_alloc(0); + if ( domid =3D=3D DOMID_INVALID ) + panic("Error allocating domain ID 0\n"); + + dom0 =3D domain_create(domid, &dom0_cfg, flags); if ( IS_ERR(dom0) ) - panic("Error creating domain 0 (rc =3D %ld)\n", PTR_ERR(dom0)); + panic("Error creating domain %d (rc =3D %ld)\n", domid, PTR_ERR(do= m0)); =20 if ( llc_coloring_enabled && (rc =3D dom0_set_llc_colors(dom0)) ) - panic("Error initializing LLC coloring for domain 0 (rc =3D %d)\n"= , rc); + panic("Error initializing LLC coloring for domain %pd (rc =3D %d)\= n", + dom0, rc); =20 if ( alloc_dom0_vcpu0(dom0) =3D=3D NULL ) - panic("Error creating domain 0 vcpu0\n"); + panic("Error creating domain %pdv0\n", dom0); =20 rc =3D construct_dom0(dom0); if ( rc ) - panic("Could not set up DOM0 guest OS (rc =3D %d)\n", rc); + panic("Could not set up guest OS for domain %pd (rc =3D %d)\n", + dom0, rc); =20 set_xs_domain(dom0); } diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 10b46d0684..c3959e8d8e 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -418,6 +418,8 @@ void asmlinkage __init start_xen(unsigned long fdt_padd= r) =20 timer_init(); =20 + domid_init(); + init_idle_domain(); =20 rcu_init(); diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 2518954124..02f665f520 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1030,8 +1030,11 @@ static struct domain *__init create_dom0(struct boot= _info *bi) if ( iommu_enabled ) dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu; =20 - /* Create initial domain. Not d0 for pvshim. */ - bd->domid =3D get_initial_domain_id(); + /* Allocate initial domain ID. Not d0 for pvshim. */ + bd->domid =3D domid_alloc(get_initial_domain_id()); + if ( bd->domid =3D=3D DOMID_INVALID ) + panic("Error allocating domain ID %d\n", get_initial_domain_id()); + d =3D domain_create(bd->domid, &dom0_cfg, pv_shim ? 0 : CDF_privileged | CDF_hardware); if ( IS_ERR(d) ) @@ -1063,7 +1066,7 @@ static struct domain *__init create_dom0(struct boot_= info *bi) =20 if ( (strlen(acpi_param) =3D=3D 0) && acpi_disabled ) { - printk("ACPI is disabled, notifying Domain 0 (acpi=3Doff)\n"); + printk("ACPI is disabled, notifying domain %pd (acpi=3Doff)\n"= , d); safe_strcpy(acpi_param, "off"); } =20 @@ -1078,7 +1081,7 @@ static struct domain *__init create_dom0(struct boot_= info *bi) =20 bd->d =3D d; if ( construct_dom0(bd) !=3D 0 ) - panic("Could not construct domain 0\n"); + panic("Could not construct domain %pd\n", d); =20 bd->cmdline =3D NULL; xfree(cmdline); @@ -1915,6 +1918,8 @@ void asmlinkage __init noreturn __start_xen(void) mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges", RANGESETF_prettyprint_hex); =20 + domid_init(); + xsm_multiboot_init(bi); =20 /* diff --git a/xen/common/domain.c b/xen/common/domain.c index abf1969e60..0ba3cdc47d 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -66,6 +66,74 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock); static struct domain *domain_hash[DOMAIN_HASH_SIZE]; struct domain *domain_list; =20 +/* Non-system domain ID allocator. */ +static DEFINE_SPINLOCK(domid_lock); +static struct rangeset *domid_rangeset; +static unsigned int domid_last; + +void __init domid_init(void) +{ + domid_rangeset =3D rangeset_new(NULL, "domid", RANGESETF_prettyprint_h= ex); + if ( !domid_rangeset ) + panic("cannot allocate domain ID rangeset\n"); + + rangeset_limit(domid_rangeset, DOMID_FIRST_RESERVED); +} + +/* + * Allocate new non-system domain ID based on the hint. + * + * If hint is outside of valid [0..DOMID_FIRST_RESERVED - 1] range of IDs, + * perform an exhaustive search starting from the end of the used domain I= D + * range. + */ +domid_t domid_alloc(domid_t domid) +{ + spin_lock(&domid_lock); + + if ( domid < DOMID_FIRST_RESERVED ) + { + if ( rangeset_contains_singleton(domid_rangeset, domid) ) + domid =3D DOMID_INVALID; + } + else + { + for ( domid =3D domid_last + 1; domid !=3D domid_last; domid++ ) + { + if ( domid =3D=3D DOMID_FIRST_RESERVED ) + domid =3D 0; + + if ( !rangeset_contains_singleton(domid_rangeset, domid) ) + break; + } + + if ( domid =3D=3D domid_last ) + domid =3D DOMID_INVALID; + } + + if ( domid !=3D DOMID_INVALID ) + { + ASSERT(!rangeset_add_singleton(domid_rangeset, domid)); + + if ( domid !=3D domid_last ) + domid_last =3D domid; + } + + spin_unlock(&domid_lock); + + return domid; +} + +void domid_free(domid_t domid) +{ + spin_lock(&domid_lock); + + if ( rangeset_contains_singleton(domid_rangeset, domid) ) + ASSERT(!rangeset_remove_singleton(domid_rangeset, domid)); + + spin_unlock(&domid_lock); +} + /* * Insert a domain into the domlist/hash. This allows the domain to be lo= oked * up by domid, and therefore to be the subject of hypercalls/etc. @@ -1449,6 +1517,8 @@ void domain_destroy(struct domain *d) =20 TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id); =20 + domid_free(d->domain_id); + /* Remove from the domlist/hash. */ domlist_remove(d); =20 diff --git a/xen/common/domctl.c b/xen/common/domctl.c index bfe2e1f9f0..2e02139660 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -49,20 +49,6 @@ static int xenctl_bitmap_to_nodemask(nodemask_t *nodemas= k, MAX_NUMNODES); } =20 -static inline int is_free_domid(domid_t dom) -{ - struct domain *d; - - if ( dom >=3D DOMID_FIRST_RESERVED ) - return 0; - - if ( (d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL ) - return 1; - - rcu_unlock_domain(d); - return 0; -} - void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info= ) { struct vcpu *v; @@ -421,34 +407,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u= _domctl) =20 case XEN_DOMCTL_createdomain: { - domid_t dom; - static domid_t rover =3D 0; + domid_t domid =3D domid_alloc(op->domain); =20 - dom =3D op->domain; - if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) ) + if ( domid =3D=3D DOMID_INVALID ) { ret =3D -EEXIST; - if ( !is_free_domid(dom) ) - break; - } - else - { - for ( dom =3D rover + 1; dom !=3D rover; dom++ ) - { - if ( dom =3D=3D DOMID_FIRST_RESERVED ) - dom =3D 1; - if ( is_free_domid(dom) ) - break; - } - - ret =3D -ENOMEM; - if ( dom =3D=3D rover ) - break; - - rover =3D dom; + break; } =20 - d =3D domain_create(dom, &op->u.createdomain, false); + d =3D domain_create(domid, &op->u.createdomain, false); if ( IS_ERR(d) ) { ret =3D PTR_ERR(d); diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index e10baf2615..3bc960e6a4 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -38,6 +38,10 @@ void arch_get_domain_info(const struct domain *d, =20 domid_t get_initial_domain_id(void); =20 +void domid_init(void); +domid_t domid_alloc(domid_t domid); +void domid_free(domid_t domid); + /* CDF_* constant. Internal flags for domain creation. */ /* Is this a privileged domain? */ #define CDF_privileged (1U << 0) --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun May 04 15:50:13 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 15:50:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975617.1362985 (Exim 4.92) (envelope-from ) id 1uBbbN-00014w-BW; Sun, 04 May 2025 15:50:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975617.1362985; Sun, 04 May 2025 15:50:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBbbN-00014l-8f; Sun, 04 May 2025 15:50:01 +0000 Received: by outflank-mailman (input) for mailman id 975617; Sun, 04 May 2025 15:50:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBbbM-00014d-6T for xen-devel@lists.xenproject.org; Sun, 04 May 2025 15:50:00 +0000 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [2607:f8b0:4864:20::b32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6e3eba36-28ff-11f0-9eb4-5ba50f476ded; Sun, 04 May 2025 17:49:58 +0200 (CEST) Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-e728cd7150dso2677867276.3 for ; Sun, 04 May 2025 08:49:58 -0700 (PDT) Received: from [10.138.7.94] ([45.134.140.51]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e755e6e6f3asm1554990276.9.2025.05.04.08.49.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 May 2025 08:49:56 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6e3eba36-28ff-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746373797; x=1746978597; darn=lists.xenproject.org; h=in-reply-to:autocrypt:from:content-language:references:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=YWgNOmVdag2v7IGmosFwuLvZGoqSMesSEp/hrXcVVqY=; b=VdcGwbzZMDmL7Gd1QP0RHdUeDiYGBE3xF2a2Ak+I4/iu5HTwodoHS+aV9AMnaumsmS HrCC+JlbBhWe7EACgNzuD7K7qrJMshJwhQipFguAFe1vwmxjiCaxxyrTTT7ucl9cHxfB u5NUQ9iMiHXr9zz/O4gJuTPuzCvpgztRMq74ORvIVULTWOv5XSgtMqYv1Ay0rd0a2iEl uoLdsAxZRcJ5aP/4R1OOQY2PskMcF0e2mmOkDDV4LMCtS5/D1DWGastfFz/KaovRdX7M AsCBVV7uO1KgfXVGfQMLcMC7vzfvhoj3Rb/QmyfjZU01IKqnNxJGMEtbrtMWio6b8BKv 5wnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746373797; x=1746978597; h=in-reply-to:autocrypt:from:content-language:references:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=YWgNOmVdag2v7IGmosFwuLvZGoqSMesSEp/hrXcVVqY=; b=lqzh3+GOb2wyn4FEVSAtFG7DOw3w8b9cSfJ6gP/+JE7RFCwJRohE16GGGRhGgYEpj2 ZlhoLdzrRJ+Ign7QFh/Yr/vi9+fK8Dn9Pr57EfhaQu8Fd4aTta7E1QszAZJn7aOL8xnN 8I/gbU90YY6dajYeMEANRe6yfLL8cFZab+Ugez2qA5fmL+1BFSEyIsquMlea055SoED4 SX/YcwYO6pQg9wwcGtsIp1DDTQZX4jKVfXMl0EvIE32of7GEeiNOq6e284kuUfAY8T9E XIT2sXGoIJ8oEihBD/5SxEZaF0zmWPxar2SmthJaswlH9gv4agOCakSRlBdYf7tjYn1z SlfQ== X-Gm-Message-State: AOJu0YzXQfy3JdXaz09d/6CnbtptgZ33oyejl1kvtDMBcH9cWllaC6Yp OphIe+Ynt8zZyJAIyQeuB0/V1/KzvWe8viZrROJcuVOZbE0NKn8j/dgrvA== X-Gm-Gg: ASbGncs3Iqc+uYIqUJJCp/PGhenokNWhpv8uuyw/bVLUlBNygo/ml/ZEKKteNc6GgeO X0uhaoAh3XrYxIaY7wL8DW5MNAxpcsgMvbc6DubYF2Bhb31LzX/niSvumz8+zich8p9eHx7tpyC 4zdaTQpJxsSTAi0D8a17bdftrCFFW/AXBzAbPC5zlqj9F2dEmYHQs1OIM0K3AyoD9xob44xa4nT Mn0LPETDy1wpN89JEQIRYBaaa+Oa8vonUcNrDndojKvA9iCACYvdQRxGCqqGBvP3yovnlAw2YT6 GqdcT0fzTFEugZH7cEtJG//k2JAHCE3WA8yWHTGimDOC X-Google-Smtp-Source: AGHT+IEQeB0jAf95H4USDjz+ejF7XthxVeLxCndwoGTXydYea48YvGVoMeokmqW3IRbqorU5BDVzyg== X-Received: by 2002:a05:6902:478f:b0:e73:20ea:1cc1 with SMTP id 3f1490d57ef6-e757d350a52mr5063487276.39.1746373797323; Sun, 04 May 2025 08:49:57 -0700 (PDT) Message-ID: Date: Sun, 4 May 2025 11:50:21 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 0/2] xen/domain: domain ID allocation To: xen-devel@lists.xenproject.org References: <20250504135544.730906-1-dmukhin@ford.com> Content-Language: en-US From: Demi Marie Obenour Autocrypt: addr=demiobenour@gmail.com; keydata= xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+ VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/ 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E +MYSfkEjBz0E8CLOcAw7JIwAaeBT In-Reply-To: <20250504135544.730906-1-dmukhin@ford.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------sjDQvH9Y000o1l8FPtAEktpj" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------sjDQvH9Y000o1l8FPtAEktpj Content-Type: multipart/mixed; boundary="------------y4GTh5lUWY8Nau9O3U9ZHkTz"; protected-headers="v1" From: Demi Marie Obenour To: xen-devel@lists.xenproject.org Message-ID: Subject: Re: [PATCH v5 0/2] xen/domain: domain ID allocation References: <20250504135544.730906-1-dmukhin@ford.com> In-Reply-To: <20250504135544.730906-1-dmukhin@ford.com> --------------y4GTh5lUWY8Nau9O3U9ZHkTz Content-Type: multipart/mixed; boundary="------------s3xGSTp3Zmkd1Zt9oc8jxtqo" --------------s3xGSTp3Zmkd1Zt9oc8jxtqo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/4/25 9:56 AM, dmkhn@proton.me wrote: > The patch series adds new library calls for allocating domain IDs. > Patch 1 introduces new domid_{init,alloc,free} calls. > Patch 2 adjusts hardware domain ID treatment on Arm. >=20 > Link to v4: https://lore.kernel.org/xen-devel/20250422215322.521464-1-d= mukhin@ford.com/ > Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin= es/1799395667 >=20 > Denis Mukhin (2): > xen/domain: unify domain ID allocation > xen/domain: adjust domain ID allocation for Arm >=20 > xen/arch/arm/dom0less-build.c | 17 ++++---- > xen/arch/arm/domain_build.c | 17 +++++--- > xen/arch/arm/setup.c | 2 + > xen/arch/x86/setup.c | 13 +++++-- > xen/common/domain.c | 73 +++++++++++++++++++++++++++++++++++= > xen/common/domctl.c | 41 ++------------------ > xen/include/xen/domain.h | 4 ++ > 7 files changed, 112 insertions(+), 55 deletions(-) This email was marked as spam due to a DKIM failure. Is this a mailing list misconfiguration? --=20 Sincerely, Demi Marie Obenour (she/her/hers) --------------s3xGSTp3Zmkd1Zt9oc8jxtqo Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/ UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r 6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc /9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4 BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf /5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R /4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ 7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+ AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ 5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41 ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd 8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk /Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH 0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog 2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0 Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9 uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj 6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK 9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64 GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3 J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb 49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6 +3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6 synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8 N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb /Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r 8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D =3Dx94R -----END PGP PUBLIC KEY BLOCK----- --------------s3xGSTp3Zmkd1Zt9oc8jxtqo-- --------------y4GTh5lUWY8Nau9O3U9ZHkTz-- --------------sjDQvH9Y000o1l8FPtAEktpj Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgXjL4ACgkQszaHOrMp 8lPmOBAAmZ0dLPW9S9k6V1f7wSXVdt3Sb5ehcuKrZcDFVMiKx4daBsEtgO6B5RL3 Cjqq/L06wKT/X8OpoSzeVfwfreenraTUo9lMApZQZ6Ch2yo7YrIhUligQ812KBcv Ooo5iXSoAtylhc1WfYoXlhecbR9X277CytMnCYy5Nzy05ehNL/rrZRE3E7SNdFzP jfONJQOcEFwVAAd0rKG4YwhcvV5IXtKS90rg7NY2auYO7jcH0PEue6lQJEQm4XUV rnZn5X6fEGXs9SZak5quiCKRUF0InHg6dD+hwAq9pj6Qhzy9OF2NS8lT+GKe0h2i Lqqsd2eGaKEshj7NKlWaLjqB7CPoSrbKBJgmlfWUYw5FmarBushAQwXSBQ4AsZFB aFaqnsse8CiyWmAyUFKaLonlyAPkHcyyOpFoz5F7/TNiIlVXKhzei934RDXgvIz8 IoW8ijJ2/ug/JCXPBADjntCh7btMBxVkIW/fp3aX8SNmn9ptNb6TzQi7MLSNZ5sF c+q6QwyQrFUKxhlVEvUEjJ4OQr08akSpKNbV3A1G76Nn/B81gjtnHUBekYLf0BhB mzT8bB57IaQaM0aRZ1lEaO+Zhyo/qWZAvKCjW4Cx15yLF1ubt1ZO7YxrAbXdq+zU v4kBdP832JvT4bntMGlalkXHz6f7qDL38kY6U4t0/WeguSkA8t8= =ykpr -----END PGP SIGNATURE----- --------------sjDQvH9Y000o1l8FPtAEktpj-- From xen-devel-bounces@lists.xenproject.org Sun May 04 18:14:56 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 18:14:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975645.1363001 (Exim 4.92) (envelope-from ) id 1uBdrS-00027U-Cb; Sun, 04 May 2025 18:14:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975645.1363001; Sun, 04 May 2025 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 1uBdrS-00026p-6s; Sun, 04 May 2025 18:14:46 +0000 Received: by outflank-mailman (input) for mailman id 975645; Sun, 04 May 2025 18:14:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBdrQ-00024w-EH for xen-devel@lists.xenproject.org; Sun, 04 May 2025 18:14:44 +0000 Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch [109.224.244.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a5718f84-2913-11f0-9ffb-bf95429c2676; Sun, 04 May 2025 20:14: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" X-Inumbo-ID: a5718f84-2913-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1746382479; x=1746641679; bh=0aRmvpa4fxwrMSGMYMT22HdGNClvlgiK8yFRqz28IYE=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=O4phzPdQZXHTGF52PuaP2WEKwh4YzdCAjVoe75hQcQ5lvJd4CT86wPJBUsuFp01aU hFM6V5Pzf8+VJQoKoktQTFicHHS5t9fwVenGblughbtCx2kg0Y5tw68IZ0z8Syuv3p Sni+Q/p6hyzIaWFPsmmNO9ocwi8WVSTAjm6kZ74NrFkfaZU/ocb2sEfxODNvbcmAYM ZSExZzZn+zPWIv+swpT9LlpwPCKbxbaEG5hVV37uxoIh8/rlfOAzWn9hBR5/JAn2J5 gRbPi4COkH3nso6sb65NZJIgMkFkRWJEiVxRqKCH+BIq8wsxzkAAY8BD/fOQwyl/ts AZWsw54XZLMyw== Date: Sun, 04 May 2025 18:14:37 +0000 To: xen-devel@lists.xenproject.org From: dmkhn@proton.me Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com Subject: [PATCH v3 1/3] xen/console: cleanup conring management Message-ID: <20250504181423.2302345-2-dmukhin@ford.com> In-Reply-To: <20250504181423.2302345-1-dmukhin@ford.com> References: <20250504181423.2302345-1-dmukhin@ford.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: 9636db80b5fd8e160d9f8706508cfcd92eaee727 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Denis Mukhin Add new parameter to conring_puts() to trigger conring VIRQ when needed. That cleans up the conring management because it removes VIRQ tasklet code = from few places. Move conring tasklet code close to conring definitions in the console drive= r to enable symbols use in conring_puts(). While doing it, rename conring taskle= t variables to match the code. No functional change. Signed-off-by: Denis Mukhin --- Changes since v2: - renamed notify_dom0_con_ring_ prefix to conring_ prefix for readability - renamed console_locks_busted to conring_no_notify for readability - added extra parameter to conring_puts() to trigger VIRQ_CON_RING --- xen/drivers/char/console.c | 36 +++++++++++++++++------------------- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index c3150fbdb7..20504060cb 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -325,7 +325,17 @@ static void cf_check do_dec_thresh(unsigned char key, = bool unused) * ******************************************************** */ =20 -static void conring_puts(const char *str, size_t len) +static void cf_check conring_notify(void *unused) +{ + send_global_virq(VIRQ_CON_RING); +} + +static DECLARE_SOFTIRQ_TASKLET(conring_tasklet, conring_notify, NULL); + +/* NB: Do not send conring VIRQs during panic. */ +static bool conring_no_notify; + +static void conring_puts(const char *str, size_t len, bool notify) { ASSERT(rspin_is_locked(&console_lock)); =20 @@ -334,6 +344,9 @@ static void conring_puts(const char *str, size_t len) =20 if ( conringp - conringc > conring_size ) conringc =3D conringp - conring_size; + + if ( notify ) + tasklet_schedule(&conring_tasklet); } =20 long read_console_ring(struct xen_sysctl_readconsole *op) @@ -594,13 +607,6 @@ static void cf_check serial_rx(char c) __serial_rx(c); } =20 -static void cf_check notify_dom0_con_ring(void *unused) -{ - send_global_virq(VIRQ_CON_RING); -} -static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet, - notify_dom0_con_ring, NULL); - #ifdef CONFIG_X86 static inline void xen_console_write_debug_port(const char *buf, size_t le= n) { @@ -648,10 +654,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM= (char) buffer, #endif =20 if ( opt_console_to_ring ) - { - conring_puts(kbuf, kcount); - tasklet_schedule(¬ify_dom0_con_ring_tasklet); - } + conring_puts(kbuf, kcount, true); =20 nrspin_unlock_irq(&console_lock); } @@ -753,8 +756,6 @@ long do_console_io( * ***************************************************** */ =20 -static bool console_locks_busted; - static void __putstr(const char *str) { size_t len =3D strlen(str); @@ -774,10 +775,7 @@ static void __putstr(const char *str) } #endif =20 - conring_puts(str, len); - - if ( !console_locks_busted ) - tasklet_schedule(¬ify_dom0_con_ring_tasklet); + conring_puts(str, len, !conring_no_notify); } =20 static int printk_prefix_check(char *p, char **pp) @@ -1171,7 +1169,7 @@ void console_force_unlock(void) spin_debug_disable(); rspin_lock_init(&console_lock); serial_force_unlock(sercon_handle); - console_locks_busted =3D 1; + conring_no_notify =3D true; console_start_sync(); } =20 --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun May 04 18:14:56 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 18:14:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975646.1363017 (Exim 4.92) (envelope-from ) id 1uBdrV-0002X3-Jq; Sun, 04 May 2025 18:14:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975646.1363017; Sun, 04 May 2025 18:14: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 1uBdrV-0002Ww-Fk; Sun, 04 May 2025 18:14:49 +0000 Received: by outflank-mailman (input) for mailman id 975646; Sun, 04 May 2025 18:14:48 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBdrU-0002WI-J0 for xen-devel@lists.xenproject.org; Sun, 04 May 2025 18:14:48 +0000 Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch [79.135.106.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a8d4225d-2913-11f0-9eb4-5ba50f476ded; Sun, 04 May 2025 20:14: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" X-Inumbo-ID: a8d4225d-2913-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1746382484; x=1746641684; bh=jf7ue76YeYbPS45zsnt2Hb+wcYuAiLcM/Jd2uGGzfFU=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=dF8nbCWGoEg25pnlwC5izRVGyWMua1fqzESqPvhIw9KOagc31EEmGFgV/cQXKtYTf 8ADLFf8Ptjx9mLDbXusPrgfiGDv1HbJIFjEWD7oHX0z6jroto+C1LsvJqo2LI2Be50 BQqGZJdboXBs/4/mTOP6myC/p8FbPo3Fw1d5Z/Yd+Tudkhz+ca1KpJky90eWjtghUt iyulzeiDiLnLHL6wIcjMAf0ZH6QoXdhPMoUDt2GAsqz2a0WfyWZ3SOhd8EP5CfpqNN Pryk49Cd2Novd7uRKKmnv+Ld/tHApbkUCf284iibgmEKBOG24vyXqiFTToT+nIX8Ji Z2FM8cNvfARsg== Date: Sun, 04 May 2025 18:14:40 +0000 To: xen-devel@lists.xenproject.org From: dmkhn@proton.me Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com Subject: [PATCH v3 2/3] xen/console: introduce console_puts() Message-ID: <20250504181423.2302345-3-dmukhin@ford.com> In-Reply-To: <20250504181423.2302345-1-dmukhin@ford.com> References: <20250504181423.2302345-1-dmukhin@ford.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: b40dda7706d8352a9e5e0b9586d29980cb6f07ce MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Denis Mukhin guest_console_write() duplicates the code from __putstr(), eliminate code duplication. Introduce console_puts() for writing a buffer to console devices. Also, introduce internal console flags to control which console devices should be used. No functional change intended. Signed-off-by: Denis Mukhin --- Changes since v2: - added CONSOLE_RING_VIRQ flag - dropped locking changes --- xen/drivers/char/console.c | 123 ++++++++++++++++++++++++------------- 1 file changed, 79 insertions(+), 44 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 20504060cb..b788427aa5 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -41,6 +41,28 @@ #include #endif =20 +/* Internal console flags. */ +enum { + CONSOLE_SERIAL =3D BIT(0, U), /* Use serial device. */ + CONSOLE_PV =3D BIT(1, U), /* Use PV console. */ + CONSOLE_VIDEO =3D BIT(2, U), /* Use video device. */ + CONSOLE_DEBUG =3D BIT(3, U), /* Use debug device. */ + CONSOLE_RING =3D BIT(4, U), /* Use console ring. */ + CONSOLE_RING_VIRQ =3D BIT(5, U), /* Use console ring VIRQ. */ + + /* Default console flags. */ + CONSOLE_DEFAULT =3D CONSOLE_SERIAL | + CONSOLE_PV | + CONSOLE_VIDEO | + CONSOLE_RING_VIRQ | + CONSOLE_DEBUG, + + /* Use all known console devices. */ + CONSOLE_ALL =3D CONSOLE_DEFAULT | CONSOLE_RING, +}; + +static void console_puts(const char *str, size_t len, unsigned int flags); + /* console: comma-separated list of console outputs. */ static char __initdata opt_console[30] =3D OPT_CONSOLE_STR; string_param("console", opt_console); @@ -431,9 +453,6 @@ void console_serial_puts(const char *s, size_t nr) serial_steal_fn(s, nr); else serial_puts(sercon_handle, s, nr); - - /* Copy all serial output into PV console */ - pv_console_puts(s, nr); } =20 static void cf_check dump_console_ring_key(unsigned char key) @@ -467,8 +486,7 @@ static void cf_check dump_console_ring_key(unsigned cha= r key) c +=3D len; } =20 - console_serial_puts(buf, sofar); - video_puts(buf, sofar); + console_puts(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV); =20 free_xenheap_pages(buf, order); } @@ -617,11 +635,66 @@ static inline void xen_console_write_debug_port(const= char *buf, size_t len) } #endif =20 +static inline void console_debug_puts(const char *str, size_t len) +{ +#ifdef CONFIG_X86 + if ( opt_console_xen ) + { + if ( xen_guest ) + xen_hypercall_console_write(str, len); + else + xen_console_write_debug_port(str, len); + } +#endif +} + +/* + * Write buffer to all enabled console devices. + * + * That will handle all possible scenarios working w/ console + * - physical console (serial console, VGA console (x86 only)); + * - PV console; + * - debug console (x86 only): debug I/O port or __HYPERVISOR_console_io + * hypercall; + * - console ring. + */ +static void console_puts(const char *str, size_t len, unsigned int flags) +{ + if ( flags & CONSOLE_SERIAL ) + console_serial_puts(str, len); + + if ( flags & CONSOLE_PV ) + pv_console_puts(str, len); + + if ( flags & CONSOLE_VIDEO ) + video_puts(str, len); + + if ( flags & CONSOLE_DEBUG ) + console_debug_puts(str, len); + + if ( flags & CONSOLE_RING ) + conring_puts(str, len, !!(flags & CONSOLE_RING_VIRQ) ); +} + +static inline void __putstr(const char *str) +{ + unsigned int flags =3D CONSOLE_ALL; + + ASSERT(rspin_is_locked(&console_lock)); + + if ( conring_no_notify ) + flags &=3D ~CONSOLE_RING_VIRQ; + + console_puts(str, strlen(str), flags); +} + static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, unsigned int count) { char kbuf[128]; unsigned int kcount =3D 0; + unsigned int flags =3D opt_console_to_ring + ? CONSOLE_ALL : CONSOLE_DEFAULT; struct domain *cd =3D current->domain; =20 while ( count > 0 ) @@ -639,23 +712,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM= (char) buffer, { /* Use direct console output as it could be interactive */ nrspin_lock_irq(&console_lock); - - console_serial_puts(kbuf, kcount); - video_puts(kbuf, kcount); - -#ifdef CONFIG_X86 - if ( opt_console_xen ) - { - if ( xen_guest ) - xen_hypercall_console_write(kbuf, kcount); - else - xen_console_write_debug_port(kbuf, kcount); - } -#endif - - if ( opt_console_to_ring ) - conring_puts(kbuf, kcount, true); - + console_puts(kbuf, kcount, flags); nrspin_unlock_irq(&console_lock); } else @@ -756,28 +813,6 @@ long do_console_io( * ***************************************************** */ =20 -static void __putstr(const char *str) -{ - size_t len =3D strlen(str); - - ASSERT(rspin_is_locked(&console_lock)); - - console_serial_puts(str, len); - video_puts(str, len); - -#ifdef CONFIG_X86 - if ( opt_console_xen ) - { - if ( xen_guest ) - xen_hypercall_console_write(str, len); - else - xen_console_write_debug_port(str, len); - } -#endif - - conring_puts(str, len, !conring_no_notify); -} - static int printk_prefix_check(char *p, char **pp) { int loglvl =3D -1; --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun May 04 18:14:56 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 18:14:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975647.1363026 (Exim 4.92) (envelope-from ) id 1uBdrY-0002n6-P3; Sun, 04 May 2025 18:14:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975647.1363026; Sun, 04 May 2025 18:14: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 1uBdrY-0002mx-MS; Sun, 04 May 2025 18:14:52 +0000 Received: by outflank-mailman (input) for mailman id 975647; Sun, 04 May 2025 18:14:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBdrY-00024w-4r for xen-devel@lists.xenproject.org; Sun, 04 May 2025 18:14:52 +0000 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id aa2f3b1e-2913-11f0-9ffb-bf95429c2676; Sun, 04 May 2025 20:14: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" X-Inumbo-ID: aa2f3b1e-2913-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1746382488; x=1746641688; bh=vUW5r0Dl4Az223I5ofUyyuhJuLavlDSA1r91qpjTtqk=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=Cgsmta8guD4iZs6Mf+h7p4LB2Fqdl36V5qrd5awhBm/r6nayLekwyG2WRZSgnSA2H r4X5clAP8ofx73yBu0E/NiFQuK1erQ1ThhfNDY1lxTgguVU9K4JBmJsa31KuG115z2 kLKoJ45IjRQzjmHyf6XcMt5QSNRrWFTiKTG09/iO5XFGsoeVy4YO+FPCzS06eJ9JGd t7sIkgxWvgSI1M/vH51f5zLwNitfAl4qQQeSGdlflC+KbCcTwQqP6fXU5sHLwIfhA6 WEXkQLGgpvO1JGgvLhgA7rNOueFGapvysZVKRlgSpnEKCcbUJJBQhtU4HmMQumRjgL 50gZxore81ZuQ== Date: Sun, 04 May 2025 18:14:45 +0000 To: xen-devel@lists.xenproject.org From: dmkhn@proton.me Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com Subject: [PATCH v3 3/3] xen/console: introduce conring_flush() Message-ID: <20250504181423.2302345-4-dmukhin@ford.com> In-Reply-To: <20250504181423.2302345-1-dmukhin@ford.com> References: <20250504181423.2302345-1-dmukhin@ford.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: 83ee07173b30a3d7b88373a024dce807b7062f3a MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Denis Mukhin Introduce conring_flush() to ensure all messages kept in the internal console ring are sent to all physical consoles (serial, VGA (x86)) after their initialization is completed. Rename dump_console_ring_key to conring_dump_keyhandler to match the notation for conring management symbols. Resolves: https://gitlab.com/xen-project/xen/-/issues/184 Signed-off-by: Denis Mukhin Reviewed-by: Stefano Stabellini --- Changes since v2: - Kept Stefano's R-b --- xen/drivers/char/console.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index b788427aa5..a089d6e292 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -455,23 +455,19 @@ void console_serial_puts(const char *s, size_t nr) serial_puts(sercon_handle, s, nr); } =20 -static void cf_check dump_console_ring_key(unsigned char key) +/* + * Flush contents of the conring to the physical console devices. + */ +static int conring_flush(void) { uint32_t idx, len, sofar, c; unsigned int order; char *buf; =20 - printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key); - - /* create a buffer in which we'll copy the ring in the correct - order and NUL terminate */ order =3D get_order_from_bytes(conring_size + 1); buf =3D alloc_xenheap_pages(order, 0); if ( buf =3D=3D NULL ) - { - printk("unable to allocate memory!\n"); - return; - } + return -ENOMEM; =20 c =3D conringc; sofar =3D 0; @@ -489,6 +485,18 @@ static void cf_check dump_console_ring_key(unsigned ch= ar key) console_puts(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV); =20 free_xenheap_pages(buf, order); + + return 0; +} + +static void cf_check conring_dump_keyhandler(unsigned char key) +{ + int rc; + + printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key); + rc =3D conring_flush(); + if ( rc ) + printk("failed to dump console ring buffer: %d\n", rc); } =20 /* @@ -1058,6 +1066,9 @@ void __init console_init_preirq(void) serial_set_rx_handler(sercon_handle, serial_rx); pv_console_set_rx_handler(serial_rx); =20 + /* NB: send conring contents to all enabled physical consoles, if any = */ + conring_flush(); + /* HELLO WORLD --- start-of-day banner text. */ nrspin_lock(&console_lock); __putstr(xen_banner()); @@ -1148,7 +1159,7 @@ void __init console_endboot(void) if ( opt_conswitch[1] =3D=3D 'x' ) console_rx =3D max_console_rx; =20 - register_keyhandler('w', dump_console_ring_key, + register_keyhandler('w', conring_dump_keyhandler, "synchronously dump console ring buffer (dmesg)", = 0); register_irq_keyhandler('+', &do_inc_thresh, "increase log level threshold", 0); --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun May 04 18:14:56 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 18:14:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975644.1362996 (Exim 4.92) (envelope-from ) id 1uBdrS-00025E-3D; Sun, 04 May 2025 18:14:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975644.1362996; Sun, 04 May 2025 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 1uBdrS-000257-0A; Sun, 04 May 2025 18:14:46 +0000 Received: by outflank-mailman (input) for mailman id 975644; Sun, 04 May 2025 18:14:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBdrP-00024w-4N for xen-devel@lists.xenproject.org; Sun, 04 May 2025 18:14:44 +0000 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a4415b21-2913-11f0-9ffb-bf95429c2676; Sun, 04 May 2025 20:14: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" X-Inumbo-ID: a4415b21-2913-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1746382478; x=1746641678; bh=AJygGobeGopWh5J6bD84LTNs6md6knJaf1SvbQvM6iE=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=GFXbgzHe72M/Iw77KN+9dgjIsgYfb1ArHmsB6dHAv7stiVHOzL2GpqlPmJmBRm9nc f7H5cwYCT//JehbuMJc1PVrWOAwyqTYJZ7Dq7blVtEW+P2pnm0KKkSN7yjTIlCyeJ6 +QBfZmLmE2rm0ju1tyKX9H6cmoMN1TNdrRbRPGTQHymtZFE9qOJfXHHLarHb5t2Vyf nb1Pdw00OHveMYlv+7fgxmFeUeM7ol66cu53ytVcNHAAN0MVvb+GTHqZt0P08naHLU tdJPIjbcerrxzbuFXOTRx+5FsGNI/6krUuOo1ljbRptiiqOL6ZkwYoPj64URJbv+BK mFr9ADxZJ7LtQ== Date: Sun, 04 May 2025 18:14:32 +0000 To: xen-devel@lists.xenproject.org From: dmkhn@proton.me Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com Subject: [PATCH v3 0/3] xen/console: few cleanups in console driver Message-ID: <20250504181423.2302345-1-dmukhin@ford.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: d78f82172faf701d31078937d206713575851791 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The patch series introduces a few cleanups aimed at reducing code duplicati= on in the console driver. Originally, patches 2 and 3 were part of NS16550 emulator v3 series [1]. Patch 1 removes some code duplication for logging via conring facility. Patch 2 (see [2]) removes code duplication between __putstr() and the rest = of the driver. It also introduces private flags to select console devices for printout which simplifies some code paths. Patch 3 (see [3]) adds conring_flush() to send contents of conring to all currently available console devices. [1] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b3= 1d66c@ford.com/ [2] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-16-c5d36b= 31d66c@ford.com/ [3] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-17-c5d36b= 31d66c@ford.com/ [4] Link to v2: https://lore.kernel.org/xen-devel/20250426185021.100646-1-d= mukhin@ford.com/ [5] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin= es/1799484502=20 Denis Mukhin (3): xen/console: cleanup conring management xen/console: introduce console_puts() xen/console: introduce conring_flush() xen/drivers/char/console.c | 186 +++++++++++++++++++++++-------------- 1 file changed, 115 insertions(+), 71 deletions(-) --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun May 04 22:51:31 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 22:51:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975691.1363036 (Exim 4.92) (envelope-from ) id 1uBiAw-0001mi-0O; Sun, 04 May 2025 22:51:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975691.1363036; Sun, 04 May 2025 22: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 1uBiAv-0001mb-Tq; Sun, 04 May 2025 22:51:09 +0000 Received: by outflank-mailman (input) for mailman id 975691; Sun, 04 May 2025 22:51:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBiAu-0001mV-HH for xen-devel@lists.xenproject.org; Sun, 04 May 2025 22:51:08 +0000 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [2607:f8b0:4864:20::b29]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 42912986-293a-11f0-9ffb-bf95429c2676; Mon, 05 May 2025 00:51:05 +0200 (CEST) Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e6e1cd3f451so3140970276.2 for ; Sun, 04 May 2025 15:51:05 -0700 (PDT) Received: from [10.138.7.94] ([45.134.140.51]) by smtp.gmail.com with ESMTPSA id 00721157ae682-708c3f081ddsm18803777b3.8.2025.05.04.15.51.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 May 2025 15:51: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" X-Inumbo-ID: 42912986-293a-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746399065; x=1747003865; darn=lists.xenproject.org; h=autocrypt:subject:from:cc:to:content-language:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=1HPTqrwMEgkscUY1D+4mGPXsiv2KrzhxS5l+UMXC0Rs=; b=nE2gVXgQ6Y45H7rM/MDFGxFBFxWMEWzprbOOr6Pd30tvAJUonQ5wvbFb0wtY0gaag9 kz6if9p1xTG1Kr2i+qcl1SGJQ4DaxKRFen6FvB5kqxcxGkf/BmeV3KD8OwTBe4fdMEWN ccQZDjXymEVih+B2F8gnJxI3dMOHlMWMoXfpFsJtPkMB7plSl93Znye3y2N6TRKAXqYU +JelzmhR6UEXTuEByHKa+XlaOuQ20KepY+RcHTukBGQOeiNDkuumgd18YF1KqXLhdt0H ntwUO+XBvAuTWX4FWq2imTXU15xR9yY4Xm4LQLhbbScH4yTAxTRod96L2ad9Qmnf1DDG x+SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746399065; x=1747003865; h=autocrypt:subject:from:cc:to:content-language:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=1HPTqrwMEgkscUY1D+4mGPXsiv2KrzhxS5l+UMXC0Rs=; b=jZOm/af5WY7f6A+f4kSgiiAURuqbcz77HbvTD+uazedpU8tWdDGfVDN6ZGRRzXYBIH 4cKNCks1lPJrEqZ+GYLzFu5MneLWf/xX8ETiSFT3gMXLCTnWAV3gb0gk3x3AlZdL9lHR NcyX/F7pLq8TaPCzVN8a7/uGi+OAL9ISnxSHfa5kwiuob2QjmYknMIB0yNncnZOeC5w7 egBTqJWKqybmqU29xHAR24Eyo7kv0i86eiHAqlZFU5kYTBjGfsst6CFge3fpET9jwG72 3hD0cHmJpCNJTmrqJR8s7LHq2Q8xx3i6R5vQiP/UGB+JJ5qF86ZKHWXTWZBQZatzWBT9 VBuA== X-Gm-Message-State: AOJu0Ywujdc2DbifqWhvIA/RXK3lwv7UEtVg4Fg/cSurFMOejnoaRelM 2E6eiMWo+giEnfvyWlsnytYZCIqXE5wj9+UenMpmqBgrqfkPlbKp59V+Z84Y X-Gm-Gg: ASbGncstQSTOSzVuJbnj+b8Hpln0ja3WPgTLfkyXMXCkD0v1xqvwzRFZ36EYNt0C0H7 LD3mdPlYXIMXZ/fzP0a6fkQAGLHkOl6KXskRZ8+uJ74AJMCY3yFaUhwRBc/eRcgQyH1QGJ2eBNV xXxXKRLPqG1PlpcG0kgJ1lK4VDWOqVzWDVN4Z5n18GL7WHGM7CC/l1ySTnF5Wph5VEEk9sg0kmm qtUvF4xQpJUVC/5OURtbKjLK+Gx4Rzp0toHqMimV4L2kU5nCwi6Mua+Drpyi5+tpflQBZckfsdO WYB+M+Uh9LHl3c5l8LhEEY86dJZ1BaueIbUPH+x1v6CA X-Google-Smtp-Source: AGHT+IGqDhmdRlu8dDhlTFJEWkpjfP86x7w03kIihULYyq9g4nrUz9+r/uegS4pWAowu3zh4j5OpNg== X-Received: by 2002:a05:6902:cc4:b0:e5b:4482:a4f7 with SMTP id 3f1490d57ef6-e757d0e1291mr6488967276.12.1746399064674; Sun, 04 May 2025 15:51:04 -0700 (PDT) Message-ID: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com> Date: Sun, 4 May 2025 18:51:46 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Xen developer discussion Cc: Andrew Cooper , Juergen Gross From: Demi Marie Obenour Subject: Mapping memory into a domain Autocrypt: addr=demiobenour@gmail.com; keydata= xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+ VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/ 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E +MYSfkEjBz0E8CLOcAw7JIwAaeBT Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------JccWyaToSCWwDSl0Wu7iNhIu" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------JccWyaToSCWwDSl0Wu7iNhIu Content-Type: multipart/mixed; boundary="------------Au7G8uFJR7YDsyqy0iRr07m5"; protected-headers="v1" From: Demi Marie Obenour To: Xen developer discussion Cc: Andrew Cooper , Juergen Gross Message-ID: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com> Subject: Mapping memory into a domain Autocrypt-Gossip: 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== --------------Au7G8uFJR7YDsyqy0iRr07m5 Content-Type: multipart/mixed; boundary="------------ZtkkHlM9e2XuqT4xlF78fKty" --------------ZtkkHlM9e2XuqT4xlF78fKty Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What are the appropriate Xen internal functions for: 1. Turning a PFN into an MFN? 2. Mapping an MFN into a guest? 3. Unmapping that MFN from a guest? The first patch I am going to send with this information is a documentati= on patch so that others do not need to figure this out for themselves. I remember being unsure even after looking through the source code, which= is why I am asking here. --=20 Sincerely, Demi Marie Obenour (she/her/hers) --------------ZtkkHlM9e2XuqT4xlF78fKty Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/ UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r 6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc /9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4 BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf /5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R /4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ 7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+ AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ 5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41 ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd 8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk /Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH 0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog 2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0 Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9 uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj 6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK 9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64 GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3 J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb 49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6 +3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6 synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8 N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb /Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r 8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D =3Dx94R -----END PGP PUBLIC KEY BLOCK----- --------------ZtkkHlM9e2XuqT4xlF78fKty-- --------------Au7G8uFJR7YDsyqy0iRr07m5-- --------------JccWyaToSCWwDSl0Wu7iNhIu Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgX74MACgkQszaHOrMp 8lMNhg//W9mo33nXFlCn8Zf2IvGpmn4TiTCLwy0jnb7+8zSZe2GnYi0etdfgmybt N+WRm1KcDyjjXcYgLnIhDF9DolErsrlSeFuMmRHrjzTeQHUYNW22L1Et2DknOzYQ hOpEad/nYC9ShzD3u9XVTYSXARzKtea+yAc6cs0JxHpTaF7Lo0qfHxR3uYHph0C9 uC+y31LT1NlBtCHlV7RL1SEFZ7dnKS/1y2lqx4nck5JpVX7KInp8p1BTE5m9YW3U tvBoJUrjncrkkpxGc7rjnp3k1XDwh+Q9zXBWaa0tKCRiHln2952DFb3+TIGKi20i qwt0TaLRthM8cPQlUWVd6mIIPWslS04PFpdSZkEa/M3zMtYtTsAtWlPlPTgjqeNR 4GN8afFHFzLhJSTPsWu60HLEaYbqP0fVG28h6msJKhUcEQ5Ln99ZyAL1J+4mq0AH eBSKh4fvRtpQQ3GZdMhSl2e13PQesmWQHa1arA+Nlq9UVGdiGETlVsV9GONju9Yq K929efBXuT8Mcx8jCxpclA9zlhQaWRQxnAhnIYjblqbUyVymtTHCCzsTI7XJxsod hto4i/b+bblKdtOyJi9d0gP2+9xbkVeuPHeAqdyNsl0LGeOTwaKagjy5pVSgJJbK xe8t0ZZNi2FSini9GhHjmn4m8aYMVCrb6LXrs+P/kZV6MT+qod8= =bFG6 -----END PGP SIGNATURE----- --------------JccWyaToSCWwDSl0Wu7iNhIu-- From xen-devel-bounces@lists.xenproject.org Sun May 04 22:56:13 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 22:56:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975707.1363046 (Exim 4.92) (envelope-from ) id 1uBiFo-0002So-MD; Sun, 04 May 2025 22:56:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975707.1363046; Sun, 04 May 2025 22: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 1uBiFo-0002Sh-J0; Sun, 04 May 2025 22:56:12 +0000 Received: by outflank-mailman (input) for mailman id 975707; Sun, 04 May 2025 22:56:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBiFn-0002Sb-ET for xen-devel@lists.xenproject.org; Sun, 04 May 2025 22:56:11 +0000 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [2a00:1450:4864:20::436]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f86653dd-293a-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 00:56:10 +0200 (CEST) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-39c266c1389so2813107f8f.1 for ; Sun, 04 May 2025 15:56:10 -0700 (PDT) Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a099ae32fesm8388524f8f.22.2025.05.04.15.56.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 May 2025 15:56: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" X-Inumbo-ID: f86653dd-293a-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1746399369; x=1747004169; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=cbaE/GnJz5CyQDcgxDT7E6SEFV3Vy2U3/HcegLmP3aI=; b=CO/YJsaLFN5LjPcga+VX63lUlmI0Gi+hgUTrOlUUOdkUP9s80MzP/vREBaZT3P7ZIR G+Ob4iH+fGak0yFl3AkunBJzVLb255cJBk+bbA4APjCG9kJ9OXut9n/4jRZL1lbPwo+O 0EfSvQXSNwaeQTlM22d3yex3ZbkY//i24mmYU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746399369; x=1747004169; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cbaE/GnJz5CyQDcgxDT7E6SEFV3Vy2U3/HcegLmP3aI=; b=uxNM/P5SzXeTkhX9nFQb0H1D45OsjH/adGqpcbn/KepybhRxVIOcnWmVhcyWVyg/a1 xTD5uNSctZ5VFgTlwMfW2+cx7VGCHIFAiXRXhsD+3LpItKerjUgiGxiyUNF7lHU+nl4j m3WCLefu+mTnmQa4guzHgObGD6MZszYxOYswAsgY0oziFME6FOjAuqYs3VsSX5Jx6ZBR fSqA5Z4LMW/k0PPq/WKwjWtpWi5l/rzx0WABK5Bt/5D03kIjXCNKa+KW5awMJ0NuMCwq C0MvB771e/NB3xPB0vsd1yLjj01up5vy0EbBolL/fo8ofD/xmioWqDciVUWxMRjQ+4Jv DVBg== X-Forwarded-Encrypted: i=1; AJvYcCWje9wV9B2C1PEZpBIThzOcYEEqeQ59tyN3kGfHyCxKOFD+PfoGLL9og1Pk5YPaUppYDJ5aKkgXpBk=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz/chfMGrIeK60PKN7M9lHymo9sm92YJNq4GOIPDiykmkTKKYXV YD4MzdEFvR8T2qPLFzowmLu7II/KCC1n+eFamKKZxFJgz6lhw7jn6y+4pSbXdgM= X-Gm-Gg: ASbGnct5pz4hiwuMtc6wTn6zR/5KVLt11fwImOwokjbakfuR/X15MmfpyasexyMjzCr 6yjUSr4K84wDRE4e4bXNxP/QysrM21jZcL+ZSjjYUpBUhj5dngKk/7nBoogZqof4fihpCUhcIbO XCBanHdx6w3A5UQ1AE7lpVywT1nqffaFRrs6Y5DQuICYwGyZl7JR3iDPL2VkI1QO9cqtkOQ/s/x RjvtwVe+WuPNe6hi0Ris+0BDhvhDhHtSJRGjLB8aga+3hX4tRnIF37ore2lzorzl7woHuWE3pPv VZgQ3n+JroOUWkMs+srrqTrhHdoBGaiF2Xg7PbHZQGfiWVPFlYwU3/mf5RTKee3aqT+jwfWH3Nh TZbZIRA== X-Google-Smtp-Source: AGHT+IE1SSxHLjPeoAZoTBcMCeKvu3uDB013+pb+pGKylR3Qr2Jba3OelLZheIhHAvJ874vh5GTG1w== X-Received: by 2002:a5d:59a4:0:b0:39e:e259:91fd with SMTP id ffacd0b85a97d-3a09fd7326bmr3229692f8f.17.1746399369647; Sun, 04 May 2025 15:56:09 -0700 (PDT) Message-ID: Date: Sun, 4 May 2025 23:56:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Mapping memory into a domain To: Demi Marie Obenour , Xen developer discussion Cc: Juergen Gross References: <82772686-edcd-41e4-b81c-f6b3ded30901@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: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04/05/2025 11:51 pm, Demi Marie Obenour wrote: > What are the appropriate Xen internal functions for: > > 1. Turning a PFN into an MFN? > 2. Mapping an MFN into a guest? > 3. Unmapping that MFN from a guest? > > The first patch I am going to send with this information is a documentation > patch so that others do not need to figure this out for themselves. > I remember being unsure even after looking through the source code, which > is why I am asking here. See the top of xen/include/xen/mm.h which has an overview of terminology, including an explanation of why Xen doesn't know what the guest thinks of as PFN. ~Andrew From xen-devel-bounces@lists.xenproject.org Sun May 04 23:24:15 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 04 May 2025 23:24:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975718.1363055 (Exim 4.92) (envelope-from ) id 1uBigr-00078K-Np; Sun, 04 May 2025 23:24:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975718.1363055; Sun, 04 May 2025 23: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 1uBigr-00078D-Ky; Sun, 04 May 2025 23:24:09 +0000 Received: by outflank-mailman (input) for mailman id 975718; Sun, 04 May 2025 23:24:09 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBigr-000787-7j for xen-devel@lists.xenproject.org; Sun, 04 May 2025 23:24:09 +0000 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [2607:f8b0:4864:20::b2b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id df700c82-293e-11f0-9ffb-bf95429c2676; Mon, 05 May 2025 01:24:06 +0200 (CEST) Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-e75608f945cso2213498276.0 for ; Sun, 04 May 2025 16:24:07 -0700 (PDT) Received: from [10.138.7.94] ([45.134.140.51]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e7564634d68sm1486288276.52.2025.05.04.16.24.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 May 2025 16:24: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" X-Inumbo-ID: df700c82-293e-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746401046; x=1747005846; darn=lists.xenproject.org; h=in-reply-to:subject:autocrypt:from:content-language:references:cc :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=Oog/pXpRYn+nzFeYjsuWOZ/UPPo0ES01AUOoq45A8UI=; b=A4+3oXXo7ZPtqME3Lnppc5rkoa9ZyzWtOxHiM5BZ+/mSlx4479a8CYpT2VUIkNSAtI 539Jgw4Wknpn7B/UoDHVS1M+VT1pAF3OwvQ2dK63YwbWcqCRdkex40fYsdrKKG5CCYMC 0AJZtDI8rXcW6w6kwSBcadfszvKmOlrDBakzNRSkgkrnyZTgY4nSm/hbeNzy5xU0vXor eLfWUjt+M9Ba+M5plZD/uX44lK9gDFSIn/HadEL6I/LTW7UDlhW0nMqES9BHG9x44LwK 6PSAPJH2OpLy7NLkwoYKDJp8lrm2/HugtxpWeZH7cQjKyqvjejaJKt83EV34neDOjV1c O7tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746401046; x=1747005846; h=in-reply-to:subject:autocrypt:from:content-language:references:cc :to:user-agent:mime-version:date:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Oog/pXpRYn+nzFeYjsuWOZ/UPPo0ES01AUOoq45A8UI=; b=re4dxzengP9o708zwk+eR3PWaceWBY64COYCzPqoaYlb3odYc50flOyeSPNu99fzG5 hWYKCPg2zsDJYlPfmdDB4i3xgwpZ+3WwPBxayW50TdZ4wczF6XiGhWIsVEAtx9jQtDCe F5kIGIwezSgjArutowSULYvNix5cafRFl5kzMOXo3kYWtOwLXn5n41m8D8jOY7OHcgwI Z/dLjoRKB93bbmh339VFXOllQTxTdU6up3OHfophDmXDuijVidQ/jwJbZHbV6LQvtrit gHw2AGW4M79p1ogrUanxDDNdLP30DSYN1lVmzcq4NG2Lhd+eV6Q4fixOHeigSDgB4HyF /A0g== X-Forwarded-Encrypted: i=1; AJvYcCUa/DFG32tRgZuwlZfu/7WPvTHXIUt1P+qNbvEjOqJ2lk4c/XeXd4xMJNFTvOtC18UOVKMa9WnaF98=@lists.xenproject.org X-Gm-Message-State: AOJu0YyQDSpZ0ok+llqF96cD85OunPwNnH4J39gMhsiFr3cG2eQlGV56 CoGBaDKqj6FVIYs8nNorxa5s/35Q2t94zP2YHQqzWOMCMqAwQjsH X-Gm-Gg: ASbGncvHfe5PbAWSh3gzvTB+TzwOsff5DsOL/KU1tdv39cheNstk/Yp2MOkAI5DSoGT WCbpblUBpVHIGCndig8d9KIiAAdwN27S5+HI/2KzaFHRYu0BIlkWwTyHZu+ZhlPJXU6XQLyNKaV t80z7WCBlMjF5nsO1urPc9rPRlW6MirhPkykFWh3faU2S8rF33/bI/mBz6Gc+wO0pxRPuAnNPjy dqxi/ny5d3i3tnJTrvN4YxTsVL1XZAd7UHqB8v0bz5lC1EfmgWiF6+sMp1zeO3bmlRTmkCvvPoc xp4QqE4FySmeaEmtbGoQww9SyklVDziA8uOO5T6HKLnq X-Google-Smtp-Source: AGHT+IGpTdWlfQuSyokRK4+gj0qPCJAQUzD9IaFNfmi8gspzn3L9Tjz2URjeWuysQOttxKciQ7wlgQ== X-Received: by 2002:a05:6902:908:b0:e64:3e3a:f000 with SMTP id 3f1490d57ef6-e756557cd10mr12288203276.25.1746401045677; Sun, 04 May 2025 16:24:05 -0700 (PDT) Message-ID: Date: Sun, 4 May 2025 19:24:46 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Andrew Cooper , Xen developer discussion Cc: Juergen Gross References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com> Content-Language: en-US From: Demi Marie Obenour Autocrypt: addr=demiobenour@gmail.com; keydata= xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+ VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/ 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E +MYSfkEjBz0E8CLOcAw7JIwAaeBT Subject: Re: Mapping memory into a domain In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------FhB67lCImQ9UxaVHTzgUIztA" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------FhB67lCImQ9UxaVHTzgUIztA Content-Type: multipart/mixed; boundary="------------7VkIB5HZ0U08T5z3P3SNMNIW"; protected-headers="v1" From: Demi Marie Obenour To: Andrew Cooper , Xen developer discussion Cc: Juergen Gross Message-ID: Subject: Re: Mapping memory into a domain References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com> In-Reply-To: Autocrypt-Gossip: 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== --------------7VkIB5HZ0U08T5z3P3SNMNIW Content-Type: multipart/mixed; boundary="------------2KT62WBWVKP0hj5Epep000dE" --------------2KT62WBWVKP0hj5Epep000dE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/4/25 6:56 PM, Andrew Cooper wrote: > On 04/05/2025 11:51 pm, Demi Marie Obenour wrote: >> What are the appropriate Xen internal functions for: >> >> 1. Turning a PFN into an MFN? >> 2. Mapping an MFN into a guest? >> 3. Unmapping that MFN from a guest? >> >> The first patch I am going to send with this information is a document= ation >> patch so that others do not need to figure this out for themselves. >> I remember being unsure even after looking through the source code, wh= ich >> is why I am asking here. >=20 > See the top of xen/include/xen/mm.h which has an overview of > terminology, including an explanation of why Xen doesn't know what the > guest thinks of as PFN. I read that and am still confused. Are you specifically referring to PV guests? For PVH and HVM guests, Xen needs to know what the guest=E2=80=99= s PFNs are so that it can correctly set up its own page tables. --=20 Sincerely, Demi Marie Obenour (she/her/hers) --------------2KT62WBWVKP0hj5Epep000dE Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/ UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r 6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc /9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4 BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf /5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R /4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ 7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+ AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ 5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41 ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd 8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk /Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH 0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog 2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0 Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9 uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj 6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK 9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64 GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3 J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb 49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6 +3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6 synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8 N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb /Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r 8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D =3Dx94R -----END PGP PUBLIC KEY BLOCK----- --------------2KT62WBWVKP0hj5Epep000dE-- --------------7VkIB5HZ0U08T5z3P3SNMNIW-- --------------FhB67lCImQ9UxaVHTzgUIztA Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgX9z8ACgkQszaHOrMp 8lNCug/9GlN+7ImIE6PlGL7Jjr+bij2e4AJmf7fSwlJXRFAMUn3bHT54Wo4TIHhU TkogbnOt5jbhvUNOey+1+0Bhny6LAGDZ4z6bl/1Ohqet/Iv2V6ZwZnzS6yxVQN8L /mQ+udn1o1K6KoGKztjeEpccG3gcBbee+2xSRhgJ6BH680e0t0YbP+X90tdRWBf2 LPuPLXXXRkVx451KmnFkF/s0YbnjlHmH3SJg6QBfipHsbRvj/G8GMcuhoe8U4Tv8 VsAXYsakZBstTsu0pYDB488INDmhxSLfdjzztq5jtjga2CcYWQI3w2Uvyw6LEoo6 vJdJ+I5HNCQy2PydCk6nTuYaAr2Pzgaj0/OV6oapJljQ45nivkR16XYWcGuYlVXB k47XN/6kb4Yc7oDmmgRh+LvsgMJ4OVHGDkpdpJhGVRL9Of8JbVXCCtjptBBsX1Ls TXU5jsx6d0T+rVVlFOR+UhuzZoJpFOCppA7xHdbLcslUUWYzd2iHeKf65cyvHCTo GH8cy0Dc50tX9mIeJH+MOV6ffceu9iM9kzUQ0HK+LC70HfAgu8gAHIYlBCAQaquz soLyD76U60OBh6ko4sWm2tuULKvdrcUQQw7ly3Duapdfh8I5izKQ9J3FlONPb7su hw5keXoMb0ozAvczUiS5zK0BS2/9iLtmu6KXHhWnWCUjxNejAvs= =2Wch -----END PGP SIGNATURE----- --------------FhB67lCImQ9UxaVHTzgUIztA-- From xen-devel-bounces@lists.xenproject.org Mon May 05 02:57:03 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 02:57:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975734.1363065 (Exim 4.92) (envelope-from ) id 1uBm0d-0000J8-8x; Mon, 05 May 2025 02:56:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975734.1363065; Mon, 05 May 2025 02:56:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBm0d-0000J1-6K; Mon, 05 May 2025 02:56:47 +0000 Received: by outflank-mailman (input) for mailman id 975734; Mon, 05 May 2025 02:56:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBm0b-0000Iv-FW for xen-devel@lists.xenproject.org; Mon, 05 May 2025 02:56:45 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20625.outbound.protection.outlook.com [2a01:111:f403:2413::625]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 922e261b-295c-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 04:56:42 +0200 (CEST) Received: from MW4PR03CA0297.namprd03.prod.outlook.com (2603:10b6:303:b5::32) by DM4PR12MB6253.namprd12.prod.outlook.com (2603:10b6:8:a6::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.25; Mon, 5 May 2025 02:56:38 +0000 Received: from SN1PEPF000397B2.namprd05.prod.outlook.com (2603:10b6:303:b5:cafe::f6) by MW4PR03CA0297.outlook.office365.com (2603:10b6:303:b5::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.29 via Frontend Transport; Mon, 5 May 2025 02:56:38 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SN1PEPF000397B2.mail.protection.outlook.com (10.167.248.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8722.18 via Frontend Transport; Mon, 5 May 2025 02:56:37 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 4 May 2025 21:56:36 -0500 Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Sun, 4 May 2025 21:56: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" X-Inumbo-ID: 922e261b-295c-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TwznU89kxl7F1Bv3cV/ws5FygInpU2ikB8giwJQTiwV0QQbpS2Ig1lLzKoz6kP/+ZkSXCMtKtQ90Pp9METxvUQUZVPz2awuVpB/ZOWwLW5j/+zCXgmuZJf3bxVIDLPAoJW5ZwrnwRtsu3Dyv8ElI+otyub4VYxwEJhGJeOe8bly2qXeJZTkHy52JZOcDAt6sLnCRx8XI/AWhbUM2grwS0beaTkBRWR7gxFjVECGi/r4KA965WJV6rg9m6if6piFzeaEXV8mzkaeAb9qzJcEDKT1fnv84q5QtikEwhyFOnDni8fqHKC/MVpiAoJ5Jc0EVb1dcaiCgRMgukAL6AC4gvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PVGq8F/Hua4ybpdTW1eQsHcn8bwbEhtWSGvMOWqnUS4=; b=bvF7AHsrAJhDlcf9UbVlTl4RHMetnud9aUT2bIMJ9fw9C6vowV44XE13w1ZkFQVvCBqgFj+JybLH94oTXUegSnhX85OSoAiFJyyHbP53ZJXkHJPkwrhAGY3DOibNQdDm3nMBVThgUIQAAKPcrqBGsO68xKMdqDb8gp81bhUvECYJCdgRFKiHEV52PBFESAyMKVU4/NjSJgA9lSwxkXFn0QWiP29IucfehAft1drUM142GW+S4uHPH/6GC8TH2DSS2L4v8foKN5FHzASmdp5sE/Px4uQJTd5AmiGx1Iu3pr+iRLDmZffHmPOpe3TzNtfNhTg35QBr6Yr4yp6bD0e/JQ== 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=PVGq8F/Hua4ybpdTW1eQsHcn8bwbEhtWSGvMOWqnUS4=; b=4qiV5JhDVkwe5jXEkbzOFJFA+C5avUja0aapm6AllZAebIkhSfch5pV/b9oV0x2jK5JKhLeRTvTii171qF4nB1JW4vSLlDJMsRqKHWFoNbqyTwKBpZXBWfzzaYx58rwhZBjJTvOwG2F6CrIl18+rns88iO2GhwOaTsUtVWK8TdM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Stewart Hildebrand To: CC: Stewart Hildebrand , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Juergen Gross , Ayan Kumar Halder , Oleksandr Tyshchenko Subject: [PATCH 0/6] arm: extended regions fixes Date: Sun, 4 May 2025 22:56:23 -0400 Message-ID: <20250505025631.207529-1-stewart.hildebrand@amd.com> X-Mailer: git-send-email 2.49.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB03.amd.com: stewart.hildebrand@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF000397B2:EE_|DM4PR12MB6253:EE_ X-MS-Office365-Filtering-Correlation-Id: e6bf3029-20a1-4d9d-2f55-08dd8b807415 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|82310400026|376014|36860700013|1800799024|13003099007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?n3Jh101DyZSyyNZ6HihYUCi1Hr+VJHHTSI/oHTHonc2bPeoldQBQCPddhAh0?= =?us-ascii?Q?XryyG5Q/kBEMQMNXN0cWOBlnXGfV5+8U2KF/+0STFU4zEQ0M45JmEF867WqV?= =?us-ascii?Q?/KlbHCrjveIKHC0MKda6bGsLu6R3S/Vi9yQT9flXp4k1jUW0NobLop2pLnd6?= =?us-ascii?Q?1+l6KI+CyiwYSdnlL7uOkjrsjxg9gwAuqE9hCTTntvyBinzRnLvr9Gzt9CpV?= =?us-ascii?Q?DPurxdf68iX+iuieGHtfxrSMisjcz8Y8pn6gixehNkYYp31ypWTAo7Xz00sj?= =?us-ascii?Q?xZj6W/elsuutyHGJ3Hnj9LjFbOJV2cgz1I4aOnVe9M1uoYkHuShlXT/c/+qe?= =?us-ascii?Q?ia5jwNiVSvDgNCCo0nCYQm7KoPpoWFFs2aiA6ylDpxmZMah4uR5Tt1OwCwjh?= =?us-ascii?Q?ba1LyK288++7K6XLo8u2Oowd2P9DZnHLZqb05z06xeRM/M8JjTKtDYCBsODM?= =?us-ascii?Q?ZSjlIS2V4SO+tTItSPb4axp9OqIC8T8Vcd+ZTXACZKUVlPTn/Eg+vWXd5dBx?= =?us-ascii?Q?eMZNMQ+ncQ3S5tqBuwbn/gPMlrD5JhpSDgA4h32Bkkls+xP5brD/7C7ima0J?= =?us-ascii?Q?CXK4d7vwVApzXxpc+Kuw9H4CB+WFFS22vz+JfGY6fa/xQ1mfkUKmyWRhKlYm?= =?us-ascii?Q?cRXqMKHgj0Dt0nd11dTYuRAHTFvLuhOw5Dh8V18tcKRmtZbEWgh0vVTlcVs9?= =?us-ascii?Q?+DYzWA3gfWCP8LsVaheYnIb0XMqfXMR0i0dp7FXe6+oY3VJACaVWM07qfc4t?= =?us-ascii?Q?E+1hSTzZxSPctMuhHoi3IhEl2rXLVpw1LY1lLqOCG5g86Nlf2y3m8eQ6VLlc?= =?us-ascii?Q?gX+9NDJ5mjVIa8J8aHgrYq20lSaRhsrrNrxpluN+YWuaX1ITjgocZRaSJ19/?= =?us-ascii?Q?G5obQPwrkowDI/xLaWFsHNHMafJ+Wvo+zGkCRbLgoNHc9kyhdzY72+syBjiR?= =?us-ascii?Q?/EDklW3Uhz0DXtHM/yGPoKsfjiW5em3oADaKoUmCcQ0V+RHjAET0ZnPit639?= =?us-ascii?Q?4kSaoK7xG36Du7El+S++yzlr7pZ+KaOjZJXXekR4yJSYKjm29LjjU9YX2Uli?= =?us-ascii?Q?IpJISQZTjklcawx6sD8qWScAQ4iuu0LGP3jFuUTi9YyGPhQWzCvLdn6ucdT+?= =?us-ascii?Q?l1jBJR8BTQxtmqsOq3T/A6sd6bYlT7SkeDAfA7ZbFbD7ARVeUWUZhWxDPBt1?= =?us-ascii?Q?/Yg3eGdvwRhKvpkFd7+/ftn488VJEh4b7m7NKF85fYfwUxUzr6KED0hb1gWu?= =?us-ascii?Q?khkfCL205U1rLRYbsz5q9b/AOe9LlKc5C1wKOQ+AT6wED5kXmYnfOSBi0TRY?= =?us-ascii?Q?mwMsYrU4QLkoib24jkINE7RYqvaH22C6h80PIYjVJZwRq1lawymSXcd1V5Qb?= =?us-ascii?Q?Wktm+ymSk8omV3xcpZ1RMKLxOzQspcj2nhoWFRixyZba1Pw3IWZwpvlgOMHN?= =?us-ascii?Q?pkl0U06OEmsPH8f4V/2QwdtqOGbNysPRB/HP7uWsUTfogGu9Ca9rZFWAIiA/?= =?us-ascii?Q?o0viaMdC8RDTCfuGaFoNRcEJ9+p+Og5om7TWV2gV1Y8uD0WeRW7vkZ9nYw?= =?us-ascii?Q?=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(82310400026)(376014)(36860700013)(1800799024)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 02:56:37.5412 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e6bf3029-20a1-4d9d-2f55-08dd8b807415 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF000397B2.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6253 pipeline: https://gitlab.com/xen-project/people/stewarthildebrand/xen/-/pipelines/1799738957 Stewart Hildebrand (6): xen/arm: fix math in add_ext_regions xen/arm: fix math in add_hwdom_free_regions xen/arm: switch find_domU_holes to rangesets rangeset: introduce rangeset_subtract xen/arm: exclude xen,reg{-cacheable} from domU extended regions tools/arm: exclude iomem from domU extended regions tools/libs/light/libxl_arm.c | 118 ++++++++++++++++++++---- xen/arch/arm/dom0less-build.c | 19 +++- xen/arch/arm/domain_build.c | 63 ++++++++++--- xen/arch/arm/include/asm/kernel.h | 1 + xen/arch/arm/include/asm/static-shmem.h | 9 -- xen/arch/arm/static-shmem.c | 65 ------------- xen/common/rangeset.c | 12 +++ xen/include/xen/rangeset.h | 3 + 8 files changed, 182 insertions(+), 108 deletions(-) base-commit: 78ce2be733b1e45e2e190c1765fe31da318d435f -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon May 05 02:57:15 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 02:57:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975740.1363076 (Exim 4.92) (envelope-from ) id 1uBm15-0000mt-Ko; Mon, 05 May 2025 02:57:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975740.1363076; Mon, 05 May 2025 02: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 1uBm15-0000mm-I6; Mon, 05 May 2025 02:57:15 +0000 Received: by outflank-mailman (input) for mailman id 975740; Mon, 05 May 2025 02:57:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBm14-0000Iv-Vu for xen-devel@lists.xenproject.org; Mon, 05 May 2025 02:57:14 +0000 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam04on20621.outbound.protection.outlook.com [2a01:111:f403:2408::621]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a5217d05-295c-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 04:57:14 +0200 (CEST) Received: from SN1PR12CA0054.namprd12.prod.outlook.com (2603:10b6:802:20::25) by SA1PR12MB9245.namprd12.prod.outlook.com (2603:10b6:806:3a7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Mon, 5 May 2025 02:57:08 +0000 Received: from SN1PEPF000397B5.namprd05.prod.outlook.com (2603:10b6:802:20:cafe::f4) by SN1PR12CA0054.outlook.office365.com (2603:10b6:802:20::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.26 via Frontend Transport; Mon, 5 May 2025 02:57:08 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SN1PEPF000397B5.mail.protection.outlook.com (10.167.248.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8722.18 via Frontend Transport; Mon, 5 May 2025 02:57:07 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 4 May 2025 21:57:04 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 4 May 2025 21:56:44 -0500 Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Sun, 4 May 2025 21: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" X-Inumbo-ID: a5217d05-295c-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VXCThR/1vhbz5eXZFiHV5S3u2jN8mnNGdu7L1AvPtaufzBc2Gp0TKOyM1Kl7PSeJKXvlbmxuLoxMPruEmYuCmv9LeC3ZDNbhf+MQJ8tR1nvGVS9Lfj+2KQIQi4zVT+2k81WJi88AfM0p9lHJChy60Gezx3frSYGcYUjX9AF6Slvx84Mraf7WCoxyhHLjRRvk24SXL49Y4vJNsF5J2mAotp3hajGViAMaKcJMSJWp/PBFsU/Sya0NTrUJ4bu1NxAqOI0BaVcGbUQlT5kMpxZgZLtwRd/QIbPaTuiAlIu8+Wrco3wuRIOcpPoQ/KzPYxIiWbhP9zwuzighJ3NSeBUmZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=B8Ric0W30oVUy1JBURC09V+g0enK44KOZUfYMZtclAQ=; b=XXYnZQ0Jhxl+pWWgs2mZexMAPR1+uxj1//b2LPDOnsfXmviGCE+RmWTLWWDGhv47UScXDtZefhrnwV0OvSy3YRyUmsI5ztEtOD+x/Din+KXmH5Z+Ka/QwbDD5UUq9QgyhCcqqJ95BPw+xb13uzeV61Gl15yMhzoeiUltD8CazV93C1/MUsFm8RsId/wbG5rM1Ghj45NbK5iB8yOC4SSv57maS4GOS+laFWHBkthIbgbs5qCnDWJeZ+FUOjLikRjQJGbc/HY9ON1i3XTIuJTcfRK0Pw1HXzyqbplRC7K90rFNjkKgqckYUlXs+5LWsCKrPdUwRgLvJ3fE68Z/KbS/MA== 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=B8Ric0W30oVUy1JBURC09V+g0enK44KOZUfYMZtclAQ=; b=zZ85HJ7M1y3lLt5y8PW2NJjj3cRvjiicgIPSvOcFhJoeEzykdHPefHjkyL7mW3CUf5aHvpF2tLf8LWvAmiNZKVd692ym/Nr+U7i2hrySlqwAHwVPkNvhWibPq5N5E3qGGWqqeaxWQ8VfZ8POfKNVRd0u1fLMh1m7F8Q0Q5WKdo8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C From: Stewart Hildebrand To: CC: Stewart Hildebrand , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Ayan Kumar Halder Subject: [PATCH 1/6] xen/arm: fix math in add_ext_regions Date: Sun, 4 May 2025 22:56:24 -0400 Message-ID: <20250505025631.207529-2-stewart.hildebrand@amd.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250505025631.207529-1-stewart.hildebrand@amd.com> References: <20250505025631.207529-1-stewart.hildebrand@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF000397B5:EE_|SA1PR12MB9245:EE_ X-MS-Office365-Filtering-Correlation-Id: 5b3dd7a7-0580-4440-7b3e-08dd8b808630 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?lBHwNmRKT/24ex0mqx7wfy5/oqLvAJEu6D3VgjNQGgU7GmaH8Sbbw/dNEAZQ?= =?us-ascii?Q?8vE+4ICy+eIvCN+pD1BRXUWG1sKQvgnAO6u3QE2SMXWzRlYArzopvi2TSjFX?= =?us-ascii?Q?07awlh/lBaW/dpoM0TbW+5+tZC0a6DBTkk3mYzUrFsu50MtTW0OsYAGQM+w1?= =?us-ascii?Q?76TGUKJmr4Fyk7P9bTPt2EhIa9Tp+GNMdrhCVeItXZfVhOInICOYNYoODRBL?= =?us-ascii?Q?MXKYRlQ8p30SNnblmY3B907CXAUcuuPXEQY638vWwvA81/QdhtjhoA6NthGt?= =?us-ascii?Q?3DeaftbCValvPrfsgSjSvVdmjdKWLMS7UTGrQGFX/d6xVlmurT7W47T0f0ne?= =?us-ascii?Q?7npOa1gtI6MkxWDl8KQRH7BNzlyPpnHkuRkAssEbARVDiQZQiOoNniROw626?= =?us-ascii?Q?KJ5KLj2v4JZN1C9oNfQR8DzvqHjvqsSvy9b8/E3eOMXmfQpfzZysaLrx3qOt?= =?us-ascii?Q?mzfh2Cgjgg65qfykvavKOQ2RdhULZnuNq/oddm/eHOF8sqzVz1qhGp56NowU?= =?us-ascii?Q?PjRdmK+yLJQaHs2pHraIirUdhMRUbOqRh0+DRxGKi0zpd/8OVbPGAajo5KB3?= =?us-ascii?Q?7YAu4VDFoFNQ0E4unwiA9C6tZec7QLAAA7doJSYMY22JAOzO4vcMyu8p4c4y?= =?us-ascii?Q?li2Tjx74LsevWBt6OM2vUP7fYLeuYTNLY1DWUtkQjFZ/yVnYut5Z4EubElyj?= =?us-ascii?Q?5FXD5sOHeOc6exaTkURn4Ev308pSEDRSUDn0njk48o3YLTPv2rYF1ExiSZxi?= =?us-ascii?Q?FbFgxaibvJZkcQiRjkhdTLRSxpXbCST0cc0iPxqhjpPwGYW7Se0aAj5IWCSS?= =?us-ascii?Q?G7aKISv3lBy63q3IYtY6hR8HV9msNkG8mYFhcKnPpLaeUzrt4guUeXVnUQPn?= =?us-ascii?Q?3bJce7+aZIq27TCMf4YWtZYA/wK6yeExu6xF6ZMk5d9SSmyYW0ajamYKomVF?= =?us-ascii?Q?C1q2MIhpVPvrovx0ZkucFm7u+WQGYvw6v+SF9s2sf8WGXg7LQXu8IKVlpzrz?= =?us-ascii?Q?TooIByYsv6h5XMAn2i1KBv1xNkU9S/5F+B08dr5sC0As4cosepoUD2rmpMRI?= =?us-ascii?Q?DWYccRFp4TkwhdMpeiu/r+Eh7FBgZGc87vUIp43IN9akUuwZxNc1z2FzRyIz?= =?us-ascii?Q?Ov+5i7f9YP1oniBAuQVsDWoE4LOMQNe7zgIXgjGsS9xKSUvUy/GZ1Rpw5KAd?= =?us-ascii?Q?ph55IyN+UlSv4PDq1O6H2qzsRrZlYnNTEapOXI67FoFtUxOEek1urjJvTApp?= =?us-ascii?Q?N+Qet+EQWW/Qx7Lk52Toqn1RBFDVgcPKmcM1uBexac2Pu9uOicNX3INysclX?= =?us-ascii?Q?z8gV5O0RpIorp18zq3d4neE5zFa5S1aV0BF0l0lcuylu/oVdm8x9JGHbMW7o?= =?us-ascii?Q?1UaGovktcp6lSWYvtjeL8aKjeZfINjLuaC6Ueh9bQbmx9zyWv2OyPal2Tf2L?= =?us-ascii?Q?cayQknhbJ5KmVEPgYDOxaRVYlQ4OW6H2zHGtvnyCFOJxhwcUBG+EW5b/CLng?= =?us-ascii?Q?lQatdNVec6xmDxb9ALBriyLhwTrbopiZP558?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 02:57:07.9152 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5b3dd7a7-0580-4440-7b3e-08dd8b808630 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF000397B5.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB9245 In commit f37a59813979, the arguments to add_ext_regions() were switched from addresses to frame numbers. add_ext_regions() converts the frame numbers back to addresses, but the end address (e) is rounded down to page size alignment. The logic to calculate the size assumes e points to the last address, not page, effectively leading to the region size being erroneously calculated to be 2M smaller than the actual size of the region. Fix by adding 1 to the frame number before converting back to address. Fixes: f37a59813979 ("xen/arm: domain_build: Track unallocated pages using the frame number") Signed-off-by: Stewart Hildebrand --- xen/arch/arm/domain_build.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 270a6b97e42c..2f655bcc2237 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -864,7 +864,7 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, struct membanks *ext_regions = data; paddr_t start, size; paddr_t s = pfn_to_paddr(s_gfn); - paddr_t e = pfn_to_paddr(e_gfn); + paddr_t e = pfn_to_paddr(e_gfn + 1) - 1; if ( ext_regions->nr_banks >= ext_regions->max_banks ) return 0; -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon May 05 02:57:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 02:57:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975745.1363086 (Exim 4.92) (envelope-from ) id 1uBm1B-000176-TJ; Mon, 05 May 2025 02:57:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975745.1363086; Mon, 05 May 2025 02: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 1uBm1B-00016z-QJ; Mon, 05 May 2025 02:57:21 +0000 Received: by outflank-mailman (input) for mailman id 975745; Mon, 05 May 2025 02:57:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBm1A-0000Iv-Ij for xen-devel@lists.xenproject.org; Mon, 05 May 2025 02:57:20 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2061a.outbound.protection.outlook.com [2a01:111:f403:2416::61a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a8203204-295c-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 04:57:19 +0200 (CEST) Received: from SJ0PR05CA0134.namprd05.prod.outlook.com (2603:10b6:a03:33d::19) by PH8PR12MB7421.namprd12.prod.outlook.com (2603:10b6:510:22b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.20; Mon, 5 May 2025 02:57:13 +0000 Received: from SJ5PEPF000001CB.namprd05.prod.outlook.com (2603:10b6:a03:33d:cafe::81) by SJ0PR05CA0134.outlook.office365.com (2603:10b6:a03:33d::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.24 via Frontend Transport; Mon, 5 May 2025 02:57:13 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ5PEPF000001CB.mail.protection.outlook.com (10.167.242.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8722.18 via Frontend Transport; Mon, 5 May 2025 02:57:12 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 4 May 2025 21:57:12 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 4 May 2025 21:57:11 -0500 Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Sun, 4 May 2025 21:57:10 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a8203204-295c-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IYgIS3azss+0gEM1xVH5N0Ehf+8Adu+jAXrtRgJqHxbCVBuKM3xt6bp7wuj2OE0UAx/x5QeoyahysXzGhdX3zsFhcQenfFZgls7QdtdlyVK3VUxfhL4GEfOsxY29x92zMonq8BSM5hL7akQXRX5ONH12sSCR+n7LekGH3tCWLK2tLYA/5RXWeeBKazm0TDZg11ObTp6b4ZemOVMcSfbYeMgGX+thHrdfM4x8tE5q6609prRFQEI+2DwOnb33vjszp1F8SJkqPfcQKntemmYjtla6kFliSODj/DVXASnOKmYDNuKujTUtXCoo/aFD6CupMBIO8JYy+xCh+65J/3ZzzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qdkdABA0C/3U8XeT6P3gQCCq4cQg5hAvm483R/ZDryY=; b=DerwQIfTnh3ziyZRa/QCrHSDozZZea+yLOLytP0dnpzpezhLzs0jhlTgF0ZDdReqzX/MzQSvP0fdhHI/kzQnSq3vgZ0b/EUuuCdq0B33cvxuhWJCvPTN51QZh+Gjm4Unpe5K4RPVHhBytJmbdz9MRHMzfgBP61QpgM4BMVp/zVwrH8CwFgynzMugCC8ysDcRK26wpTcidy5rH+k7OqthAfOc9bgktQTROIaVO+d6yYuQq/Rm6NZ1s/9HdfgQ0phn3jQ4/8tZaFbWpDwJaxFszAaBFElLg1OxmfN/8j0DdES2knjyvaERbaR2O78crXpapYzf6dT9EPXhvEad/rn1ew== 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=qdkdABA0C/3U8XeT6P3gQCCq4cQg5hAvm483R/ZDryY=; b=ImQJ9URZbB6QtYK1zi0WATbIdhv5v0SOZ5aG5Ecp1kycqFcFiWmoELhJM1Yd/32VE1pFTzoc0HDYNm6YVXXmMLN2EK0Z1vd0ZXtDAqJfOt4c1ghm+dyXTpGkr6Nj9vAZEtvJFPJtwEB71rxV0torpEJhdPj04YScp0ch1xLcEx0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Stewart Hildebrand To: CC: Stewart Hildebrand , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" Subject: [PATCH 2/6] xen/arm: fix math in add_hwdom_free_regions Date: Sun, 4 May 2025 22:56:25 -0400 Message-ID: <20250505025631.207529-3-stewart.hildebrand@amd.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250505025631.207529-1-stewart.hildebrand@amd.com> References: <20250505025631.207529-1-stewart.hildebrand@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CB:EE_|PH8PR12MB7421:EE_ X-MS-Office365-Filtering-Correlation-Id: 0a2e0294-2c9d-45fe-d834-08dd8b80891c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?SoGRKwPowUzS5syzi9Q3AL1KPWY3DInalukKzCZJTnl1OalXzqaTx8w+9tyc?= =?us-ascii?Q?JMHeg5ZRX2exByga9rbbGIreMWIL6Mr2SHO+IBZELM7+xOJZyquwBurS0XtE?= =?us-ascii?Q?2zmpKZrHOWlPAi/tXU/PSvy5vcj5kz+/D4xUT5Mb0uHlBjWoL5qn0dzbuHBQ?= =?us-ascii?Q?F6KOWJ25gDvHhNDQbTkTykZs/Vt89Zc8MAHWDPuh1JNHbE7tczxiA0+oNcRd?= =?us-ascii?Q?q0RZvANI5GxrrIetn1bg8tNnzh1+faRGVYKmEUTlcp8K3Dc+sh8Nt4pKtqrL?= =?us-ascii?Q?dCGI9qdUEL6P1Ch0Q6cruzIK4HppAIoGzYrdzMbkuNZKjClCEBqQqr+EW1DJ?= =?us-ascii?Q?5xK7VPXlDxfE6nlIgLW2uk2rnkZrY6H/X/OZL+K+uMBfZZXtb7WCOimGj/J1?= =?us-ascii?Q?che23/g4MYuC0s0Q/G+fIaKoCM9kZPw+vjIgPspI+FLHAX6GB83qAH4elQxo?= =?us-ascii?Q?ev5kXsOJ5BWHYYH848moU5777Y57u8KokixrImNJxcD6UDhseUoyKWedwRtw?= =?us-ascii?Q?Dc4nWj1ECLH6SBhNLNGFZcRZNdbsSJuf+sB3T3WiwZVLqoStrs0ndfjDxmzd?= =?us-ascii?Q?O5cXiQZ85mwkuLWvt447PuF/zMxVMX91c+XduUpUf42jvZMy5mVekroPDnpG?= =?us-ascii?Q?rEmq6DY3moCC2HnKXkV1IjFu+JTvSfyYJw2mUypQmJB+4pClaRMSAyOS3JMt?= =?us-ascii?Q?khYBWd8cuqvz2GBsgklTMKvS2viKQQTYGS6krRHlRVKuAXV3Ttrb376G9EUT?= =?us-ascii?Q?H9gwpMRkBW3fGjD0IrfqyrHkzqLemCgKRmw5YJUdaSQ7+OGOxkq57128R0qg?= =?us-ascii?Q?W554JEIqHrVeERWqdPkcrgxJaPiqTz+/vb3VGKXWYFSRdGZdavniI8mwdIz1?= =?us-ascii?Q?XTFEcx1mhj/h+UGDMADxuvoNbV4z3XvrMrhebkgSukCXHUo3K871JJRxF3da?= =?us-ascii?Q?iltLBOhZX/Tpq0eHfRUK3SaNqPrNXrXOaBH84Kq6Mff9R7ZvVLZxwO+5pLW4?= =?us-ascii?Q?yQAzLxZipFnCwEW4Q/NgWRJJ6t7Blpug7m4K4mCpyGYC+rQ4zhEZ9jJrI8mk?= =?us-ascii?Q?hwJzAf2dHOV1z08mcTm2VNn0/W+qx1cqtgltnPw93Gw7wJsJxj299B3P1dw7?= =?us-ascii?Q?+ESiFACULrWJWpDHbx7oEculCO+0h8XCL7WWEySSxve2Xn61TR66EbzLrYvw?= =?us-ascii?Q?6/4VYcdB8xO/USzeGLfJhMZsTVJFMeM+OQFW6lX66uujgyn4KJsKLGb+7+F8?= =?us-ascii?Q?VEB+0kt1MYLJlOUOuT3BTUpziAdnS4Fdniuzmh11Tph7ckdokgSm0tQpSoOk?= =?us-ascii?Q?AcTxzyt2hly3IC6BvJso2NRI/X6r5/5zgSHqwZwwDJQyvnuB3TjgJHxXFA23?= =?us-ascii?Q?UEDxT6D5hyx6bdxkgNFuaimQAc/eaRXaoT+/jBCsSXkY8850kSTy1gSkaVyP?= =?us-ascii?Q?9iqUxVbGrSx9A/D186uXb66Wdh0SYvDnkKx+36JiRLAO7m0MTPxkbUqu3CzE?= =?us-ascii?Q?9r7armVPXR69IwXwwXzIHC25ny40962cksIC?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 02:57:12.7597 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0a2e0294-2c9d-45fe-d834-08dd8b80891c 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001CB.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7421 Erroneous logic was duplicated from add_ext_regions() into add_hwdom_free_regions(). Frame numbers are converted to addresses, but the end address (e) is rounded down to page size alignment. The logic to calculate the size assumes e points to the last address, not page, effectively leading to the region size being erroneously calculated to be 2M smaller than the actual size of the region. Fix by adding 1 to the frame number before converting back to address. Fixes: 02975cc38389 ("xen/arm: permit non direct-mapped Dom0 construction") Signed-off-by: Stewart Hildebrand --- xen/arch/arm/domain_build.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 2f655bcc2237..a0f3c074337d 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -905,7 +905,7 @@ static int __init add_hwdom_free_regions(unsigned long s_gfn, struct membanks *free_regions = data; paddr_t start, size; paddr_t s = pfn_to_paddr(s_gfn); - paddr_t e = pfn_to_paddr(e_gfn); + paddr_t e = pfn_to_paddr(e_gfn + 1) - 1; unsigned int i, j; if ( free_regions->nr_banks >= free_regions->max_banks ) -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon May 05 02:57:30 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 02:57:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975751.1363095 (Exim 4.92) (envelope-from ) id 1uBm1K-0001SP-4O; Mon, 05 May 2025 02:57:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975751.1363095; Mon, 05 May 2025 02: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 1uBm1K-0001SI-1G; Mon, 05 May 2025 02:57:30 +0000 Received: by outflank-mailman (input) for mailman id 975751; Mon, 05 May 2025 02:57:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBm1I-0000Iv-G1 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 02:57:28 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20625.outbound.protection.outlook.com [2a01:111:f403:2417::625]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ada391d3-295c-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 04:57:27 +0200 (CEST) Received: from MW4PR04CA0301.namprd04.prod.outlook.com (2603:10b6:303:82::6) 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.20.8678.31; Mon, 5 May 2025 02:57:22 +0000 Received: from SJ5PEPF000001CC.namprd05.prod.outlook.com (2603:10b6:303:82:cafe::44) by MW4PR04CA0301.outlook.office365.com (2603:10b6:303:82::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.29 via Frontend Transport; Mon, 5 May 2025 02:57:22 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ5PEPF000001CC.mail.protection.outlook.com (10.167.242.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8722.18 via Frontend Transport; Mon, 5 May 2025 02:57:21 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 4 May 2025 21:57:20 -0500 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 4 May 2025 21:57:20 -0500 Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Sun, 4 May 2025 21:57: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" X-Inumbo-ID: ada391d3-295c-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=l7S1c23z2/MzThGcLxfrhXjof6dIVOG1d95xFOA1IeAIsIWFZg05d77BaBPaJQeBaVriFsyTEKmV3sj/htiTjOrpQkgAU3FYlmy3GDOM2dzCZ1sAgMnJttke7kdYxRO+JdWhDeR4va7HLe/cz5bpQ+w0y64QYXlvhaJhHmzind4ZX3qqd4z244qjWMM8CP5NNl65DyG0eocy08HqIVBwrK3X/PEEX1H5Sj7S5EjW4LqZn+rGOAow6ed7LjLtBqRb0SRB/5gk0JrXH6HevNm3R9Qo7Pc2tbBQ69v3c152S/SYU0MiJoBQA87lSovNawOjOVPBxm+Z9qgmxy5K943YbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=k7EpWyUGojUhK3l4AHNyX8h5cPPVtoJRAwdIaI1JfS0=; b=iUNwykf8gb0Nfzlzku9q0/YxEH7xTRrcUUFY4niBi7V04B5JX66y+i2Kxk0vGz+RvAp8H0FiWdYdc5AQFdUOwHM/GwJrLuygEUmEupPCAIxHgMaez6m47Gr0a+cS4nNZDg4/dLkMoDPHI6sfLFaHdRS+7zgdkUzdRex3nd25VUfFA6WNW6WhybtgjwBAh7NfhJIIciRMfmAyr0gqPVSs0FOCPe5g2sMnvpGRiPbhyNXCtB/shuV2AIlIHhD+49vqKhcVHYibmMmxvsGMcYavTpVB9qU+w1zMKpWDtC8aysRVHijV/q2va/otjB+JqKNKWtOTCFSAarTiysIHUp5/xg== 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=k7EpWyUGojUhK3l4AHNyX8h5cPPVtoJRAwdIaI1JfS0=; b=jtEr/HD1/VF7+mBfcpscXnWv4vLyuaT05n5zBnDR7jw/w7PyAEmCprQuyyN3Qqpu+gw+TEdU/N8lykp4+yb3vOPM4B/mvEu7p5hFAOWE4Y3oCYYQ9QSy1j5sEL5K5iKssSfSLDzYUqO0s2X8n+9sKyafQ/4ZUbYeRFs7k9iRo8Q= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Stewart Hildebrand To: CC: Stewart Hildebrand , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" Subject: [PATCH 3/6] xen/arm: switch find_domU_holes to rangesets Date: Sun, 4 May 2025 22:56:26 -0400 Message-ID: <20250505025631.207529-4-stewart.hildebrand@amd.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250505025631.207529-1-stewart.hildebrand@amd.com> References: <20250505025631.207529-1-stewart.hildebrand@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CC:EE_|DS5PPF016FC81DF:EE_ X-MS-Office365-Filtering-Correlation-Id: 4b997295-dd6a-46b7-e582-08dd8b808e44 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?ETmDyZ3v27FcrbsAqFHVkSIc0GSkE33R4eaTVS09MkVMOBnzdtumC+Qvg+oC?= =?us-ascii?Q?9ganNQMmraBiHRC4YkakhPAeKoCWP4Lo6qD6KuxT7v1+NpNT2woDEB0PjW7C?= =?us-ascii?Q?exWvivf7Dm3EzFTjkKs57w4kmHiJb5E0hsbIU/sgPESW132tvQtQgM0l1Hor?= =?us-ascii?Q?4qenJ1aQoKjlLzfcLysq30knjlTZAdQX52+V8+ZXebmBWJhFb15voqZW21aq?= =?us-ascii?Q?6P1uyqq4g/2SADLAcS8MK1LOdA01YrPoUEHH81bopcTUgMCXEW+JNgOHb4UY?= =?us-ascii?Q?V02pMUmX3Afs3e4Z9t91bYSF+s1OfJZ4xKjMFxlxEGl+5eyKEF4E4KMTlfYk?= =?us-ascii?Q?dJ1G7mm7/8TPZgcRirJDiAveCd7FU++Nu1/hKxh8DRhe4xYQBFEgVyqFZ9nn?= =?us-ascii?Q?+M856kt1kg/ULXmwEHRTtTtrVhjkJlqwCDIuRqkxHoKpENmmJKuPB8y008rM?= =?us-ascii?Q?tCqkEbK+AaW1nO3LSjOcZo3X5jKgCm5n6sDOx0CTT0zN17I7+DHdjZEDJwDU?= =?us-ascii?Q?HXmts4LvR/52fmYUPpWOsW7SVpIHYKR8cxirh8rabdhm9BBdl/76VKy2zZ4I?= =?us-ascii?Q?QDU/yEvkSEDFjtIfu8mi6vlmfLASed9h4x0Fc850rKGL3zKN0WkpaC205AeB?= =?us-ascii?Q?zVknmJGqyKTSPX0/6V6UDrCxFAtrYadvFT65ETe467Mw0HH4fUMiwqMIAohZ?= =?us-ascii?Q?xXHNK/GkzLD8ujMwrvB0SErEL/C0c05QrKYg/Kb0nwMxf6AU4McCNETwC18I?= =?us-ascii?Q?kbTjLYqXI1egudnxPLgNQPO4N2AgHO32yqX+musFnR6VMVZuV/m+t6JOfMf8?= =?us-ascii?Q?SVZGMBYqhZV9c7j1dSN5lRXeNhMcsrVTnFHN/8zt8eM9iQMgkveE/wH2IZZM?= =?us-ascii?Q?ZMdsAikfXHCGB4QSZNwavq3rPlYHBzJlqAFzPlRvkML9lZW6UySuMDnw88zr?= =?us-ascii?Q?5DaQrcqp+nrO+jOR50k5QN4/W3wFRxYneVxkIyOMdFaOYuyEmOmXbKgVYtu6?= =?us-ascii?Q?XQNQ+ukwy7U62LG8/+8iksP4LoF1pBBapW5GYDP/WYF2D8JHfv+9g+Wl7fSC?= =?us-ascii?Q?aWR5AJN91oVUr0BJIBNpA8BT7UYU7tC2dcJqfBv7xBGCGhkZt1y+81NP7Lm0?= =?us-ascii?Q?WYJmRjDdrJ7NVCWg3PucmUpt4fYHsfNwdQnEftZC91JdtUnmcG+6D6GWGU5S?= =?us-ascii?Q?TWxY7ZffEtHpbTfn11zy/2ZdGKSnvvPSkR4z5BfavuW4tZmOPC5JU91Ko9i0?= =?us-ascii?Q?+tQqOyxknv9UYw5zmti1tqYchjAcSd9W54cdhPdLeRmCw2G5l11elTW24JtX?= =?us-ascii?Q?4XXKCmC0nhA951SKwD6nfeJ+gIaeE+CAgEmaMjqPMfVbFxTMBAq1lwlLlPsr?= =?us-ascii?Q?Y8fwKTYU3Ehj7tJ+/DWx6P/ra5IWllhcpiAfDsnSCwhKohJe+3jGlpRGzi7l?= =?us-ascii?Q?K6YjyoyKEiwMa7AtLiIXXcMCayB9HUEjY0630kEA1O418OxR3zDO/UfUIDJ8?= =?us-ascii?Q?yPTO5f9k6pZpkW+AnM1GxR6A1ixTdQvImz0M?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 02:57:21.4099 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4b997295-dd6a-46b7-e582-08dd8b808e44 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001CC.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPF016FC81DF remove_shm_holes_for_domU() is unnecessarily complex: it re-creates the extended regions from scratch. Move the rangeset into find_domU_holes() and create the extended regions only once. This makes is simpler to further manipulate the rangeset for removing other regions. Remove now-unused remove_shm_holes_for_domU(). Signed-off-by: Stewart Hildebrand --- xen/arch/arm/domain_build.c | 46 ++++++++++++----- xen/arch/arm/include/asm/static-shmem.h | 9 ---- xen/arch/arm/static-shmem.c | 65 ------------------------- 3 files changed, 35 insertions(+), 85 deletions(-) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index a0f3c074337d..3dcdd7a8c46f 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1256,34 +1256,58 @@ static int __init find_domU_holes(const struct kernel_info *kinfo, struct membanks *ext_regions) { unsigned int i; - uint64_t bankend; const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; const struct membanks *kinfo_mem = kernel_info_get_mem_const(kinfo); - int res = -ENOENT; + struct rangeset *mem_holes; + int res; + + mem_holes = rangeset_new(NULL, NULL, 0); + if ( !mem_holes ) + return -ENOMEM; for ( i = 0; i < GUEST_RAM_BANKS; i++ ) { - struct membank *ext_bank = &(ext_regions->bank[ext_regions->nr_banks]); + uint64_t bankend, start, size = 0; - ext_bank->start = ROUNDUP(bankbase[i] + kinfo_mem->bank[i].size, SZ_2M); + start = ROUNDUP(bankbase[i] + kinfo_mem->bank[i].size, SZ_2M); bankend = ~0ULL >> (64 - p2m_ipa_bits); bankend = min(bankend, bankbase[i] + banksize[i] - 1); - if ( bankend > ext_bank->start ) - ext_bank->size = bankend - ext_bank->start + 1; + + if ( bankend > start ) + size = bankend - start + 1; /* 64MB is the minimum size of an extended region */ - if ( ext_bank->size < MB(64) ) + if ( size < MB(64) ) continue; - ext_regions->nr_banks++; - res = 0; + + res = rangeset_add_range(mem_holes, PFN_DOWN(start), PFN_DOWN(bankend)); + if ( res ) + { + printk(XENLOG_ERR "Failed to add: %#"PRIx64"->%#"PRIx64"\n", + start, start + size - 1); + goto out; + } } + /* Remove static shared memory regions */ + res = remove_shm_from_rangeset(kinfo, mem_holes); if ( res ) - return res; + goto out; + + res = rangeset_report_ranges(mem_holes, 0, + PFN_DOWN((1ULL << p2m_ipa_bits) - 1), + add_ext_regions, ext_regions); + if ( res ) + ext_regions->nr_banks = 0; + else if ( !ext_regions->nr_banks ) + res = -ENOENT; - return remove_shm_holes_for_domU(kinfo, ext_regions); + out: + rangeset_destroy(mem_holes); + + return res; } static int __init find_host_extended_regions(const struct kernel_info *kinfo, diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h index 94eaa9d500f9..ad8267c6bfbe 100644 --- a/xen/arch/arm/include/asm/static-shmem.h +++ b/xen/arch/arm/include/asm/static-shmem.h @@ -28,9 +28,6 @@ void init_sharedmem_pages(void); int remove_shm_from_rangeset(const struct kernel_info *kinfo, struct rangeset *rangeset); -int remove_shm_holes_for_domU(const struct kernel_info *kinfo, - struct membanks *ext_regions); - int make_shm_resv_memory_node(const struct kernel_info *kinfo, int addrcells, int sizecells); @@ -74,12 +71,6 @@ static inline int remove_shm_from_rangeset(const struct kernel_info *kinfo, return 0; } -static inline int remove_shm_holes_for_domU(const struct kernel_info *kinfo, - struct membanks *ext_regions) -{ - return 0; -} - static inline int make_shm_resv_memory_node(const struct kernel_info *kinfo, int addrcells, int sizecells) { diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c index e8d4ca3ba3ff..06f32be097c8 100644 --- a/xen/arch/arm/static-shmem.c +++ b/xen/arch/arm/static-shmem.c @@ -820,71 +820,6 @@ int __init remove_shm_from_rangeset(const struct kernel_info *kinfo, return 0; } -int __init remove_shm_holes_for_domU(const struct kernel_info *kinfo, - struct membanks *ext_regions) -{ - const struct membanks *shm_mem = kernel_info_get_shm_mem_const(kinfo); - struct rangeset *guest_holes; - unsigned int i; - paddr_t start; - paddr_t end; - int res; - - /* No static shared memory region. */ - if ( shm_mem->nr_banks == 0 ) - return 0; - - dt_dprintk("Remove static shared memory holes from extended regions of DomU\n"); - - guest_holes = rangeset_new(NULL, NULL, 0); - if ( !guest_holes ) - return -ENOMEM; - - /* Copy extended regions sets into the rangeset */ - for ( i = 0; i < ext_regions->nr_banks; i++ ) - { - start = ext_regions->bank[i].start; - end = start + ext_regions->bank[i].size; - - res = rangeset_add_range(guest_holes, PFN_DOWN(start), - PFN_DOWN(end - 1)); - if ( res ) - { - printk(XENLOG_ERR - "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error: %d\n", - start, end, res); - goto out; - } - } - - /* Remove static shared memory regions */ - res = remove_shm_from_rangeset(kinfo, guest_holes); - if ( res ) - goto out; - - /* - * Take the interval of memory starting from the first extended region bank - * start address and ending to the end of the last extended region bank. - */ - i = ext_regions->nr_banks - 1; - start = ext_regions->bank[0].start; - end = ext_regions->bank[i].start + ext_regions->bank[i].size - 1; - - /* Reset original extended regions to hold new value */ - ext_regions->nr_banks = 0; - res = rangeset_report_ranges(guest_holes, PFN_DOWN(start), PFN_DOWN(end), - add_ext_regions, ext_regions); - if ( res ) - ext_regions->nr_banks = 0; - else if ( !ext_regions->nr_banks ) - res = -ENOENT; - - out: - rangeset_destroy(guest_holes); - - return res; -} - void __init shm_mem_node_fill_reg_range(const struct kernel_info *kinfo, __be32 *reg, int *nr_cells, int addrcells, int sizecells) -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon May 05 03:00:38 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 03:00:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975778.1363106 (Exim 4.92) (envelope-from ) id 1uBm4L-0004Al-OH; Mon, 05 May 2025 03:00:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975778.1363106; Mon, 05 May 2025 03: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 1uBm4L-0004AU-Jp; Mon, 05 May 2025 03:00:37 +0000 Received: by outflank-mailman (input) for mailman id 975778; Mon, 05 May 2025 03:00:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBm1Y-0000Iv-NO for xen-devel@lists.xenproject.org; Mon, 05 May 2025 02:57:44 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2062d.outbound.protection.outlook.com [2a01:111:f403:2418::62d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b6bdf70b-295c-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 04:57:43 +0200 (CEST) Received: from MW4PR02CA0017.namprd02.prod.outlook.com (2603:10b6:303:16d::24) by CH2PR12MB4246.namprd12.prod.outlook.com (2603:10b6:610:a9::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Mon, 5 May 2025 02:57:36 +0000 Received: from SJ5PEPF000001C9.namprd05.prod.outlook.com (2603:10b6:303:16d:cafe::13) by MW4PR02CA0017.outlook.office365.com (2603:10b6:303:16d::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.27 via Frontend Transport; Mon, 5 May 2025 02:57:36 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ5PEPF000001C9.mail.protection.outlook.com (10.167.242.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8722.18 via Frontend Transport; Mon, 5 May 2025 02:57:35 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 4 May 2025 21:57:34 -0500 Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Sun, 4 May 2025 21:57: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" X-Inumbo-ID: b6bdf70b-295c-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=V59qptvdI9oZhyuIamV+aWWeCLQMPRNybFvSaZH3y/fGC+w9goYscAqItYnUYpJsVw2JJeWFDF/Ro/xJ8M5zY+SUIGIh1abb521FbH4eIlbjAPi73n9vHHiLuFE1gGW7RSawUyA4vYun2dExAFYmxSq959uVCnMycN/QJ6f5bKAfZ33Nt462Mxj8jAri/Lv2qTrAb7KFjZ9m6qfRKIJp+Dqs89H+5SGYv4W/58myh4pKBlgDt0lYda0vwPqAMZ7HfoNBZohrZ4t0Ge3q5sXpzK4JsJSij4XtJdlLgD9tuipX3aGeBpO/qVYE/9JN2T5zVexLvb8MgUIUDJOOaibEMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KEvx1wmn01iTjM6pupbHY1kYSQPlwozYMYZ4oM7o7v0=; b=TzbXQDwXPdL/eGEeRhFtaTDe18lTNB5658MU+17FxN0wm9on3EYmMhHV94J5ZCt6ZSBymnDabQUPEdO6Gqwqg7pIf6larykWKBK3vWRbp5NspfWhrfDGRiDeP8ArxwWOZAsfEKR5eC8wm7vjLqrhh/OotdAO+OocjDL9wNUW3hpbrjVvX30VGKLGGgpObS7Vn45xGfH5fm7zeobmETYbubMAWQ+7vQaMHxM1DbhEHMXOEmFTttuZ+KgHJPgZDc3a1SNFt1WgzirHdWXqaQt7+dAn0EZ6cPrNC6/h6TRayUFuZ2Wu8qSxCwtAVGzSG25YlWezjXKipsk22vrh4jvTPQ== 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=KEvx1wmn01iTjM6pupbHY1kYSQPlwozYMYZ4oM7o7v0=; b=elUap8Gi6nWYoNAGky5eNCqqmKMkD0Xx/kJS5XXKLPTVtvMk3DNE5WGDRAB0MuLCSKa6Pz5wZGoi5kTgLQN05FgEhhJYXjBMGm0KhciXFbgTkNrB1JXwARsggqWr2Vp8PAduz4m1xLGB2JfKxjPc4F1SwiXpaInOD1FeT6HhEPc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Stewart Hildebrand To: CC: Stewart Hildebrand , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" Subject: [PATCH 5/6] xen/arm: exclude xen,reg{-cacheable} from domU extended regions Date: Sun, 4 May 2025 22:56:28 -0400 Message-ID: <20250505025631.207529-6-stewart.hildebrand@amd.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250505025631.207529-1-stewart.hildebrand@amd.com> References: <20250505025631.207529-1-stewart.hildebrand@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001C9:EE_|CH2PR12MB4246:EE_ X-MS-Office365-Filtering-Correlation-Id: 851ef4b8-c452-49c8-56c0-08dd8b8096aa X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|36860700013|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?Db7ltdOZ4l0YdJJowGeCr2YmjU85D6oCcICG1z+6JluPvXcqjAFWKe1UxMYx?= =?us-ascii?Q?zuUjGu1UABwfM20niFPO75Zt+omAUXSjyu6rg8LTFpvmRGFJC3ncNFSg2657?= =?us-ascii?Q?2bAmnG1k9uPKHbkH/gMrOBkjQzrBC2jV7qWbxuvF+AKrmcjh9ZkRNvMYE6FJ?= =?us-ascii?Q?Xt+CqU4A8nV5JTIw0qhOVmykkmNXsoZ14xkOxzOUPiZVRI+ksKwDw3C9SA6E?= =?us-ascii?Q?tKZGbYee3jz96BpDPzO+rA6QWa8iRZslA7Y/ErlXl57VD2jvt7Q4cbL1+cd/?= =?us-ascii?Q?4eRuR2rVxMSjbr+oFAKZsfvPcF2yotA0dm+tTFqa4plxtPaoOycO63247663?= =?us-ascii?Q?avTl3x3xEm2E6rSH6ltbmeczNQWaIs9Mnzwuz7vPrBQPviaycA+YJ9UfW+Pl?= =?us-ascii?Q?06LH7iPcSTD3fSMw2l6uWVRcy2QAguZOgv+LtrLpR6AVaTqS5o1hXNDWfL42?= =?us-ascii?Q?Csqn+Yad98SsYfhFG8S4l13SC3gShPJnP9DCoY0wH4oLxcQXDmnku7x779DU?= =?us-ascii?Q?tbX2/Hw11S5Knp5dZDRjTzdS//Nv9FZdtcxkz7bmUnFwVOqZUDAV6uDZeHuo?= =?us-ascii?Q?8T6KRlqwP647JEHblSLNIWWqP5JocCV/cF6Bq62t2QlBx5JDHVxsvWMSD4Qp?= =?us-ascii?Q?56P2rzwYtXtpl6lZ/B5D60idtVoXOIXFNW9unWC623fGnxyonU+RWdS+a2gF?= =?us-ascii?Q?6UoE2OaN2mAxHLmQDvbrQ0zpu8bRIsDo1E/gZyzj2nDzXfnMis6cDA0O0jmZ?= =?us-ascii?Q?+Jy6mlrIg/U8XHtyIY5MJ0YSR2/mEJz6wqxHRS6KQV89/2jGMTu7JP+da9v2?= =?us-ascii?Q?6PsMh8RAM+Fc3fQtretd0ydYQA8Ps18qfi1ErMArOeGBJSgwdXVsIdb0PYNg?= =?us-ascii?Q?Cmq1HDlIleTpjW8DeWmn1b7Xydrf0jQK7zOvD6IvRQYZNy8lTJRod8AZ0iFD?= =?us-ascii?Q?DVA7zl56LIiq27lABIDmGnfmW1oob4m/Vq60PjMRqtB3gSmYnjn8CA9rDgpS?= =?us-ascii?Q?ek4wbiSx5cUHqg+K6ka7x7CuCdDehUVG80DeIThVXOIBlbXHWdVfwGIqywyA?= =?us-ascii?Q?JYhjjF5LtSUprilh3dLn3hrFcwl2gEt+tfgFsfKH3AN7rksojR1BB3DVE+3P?= =?us-ascii?Q?+2qwjoUgmlfx2aWYFD4qksUZtv56UauKrYN7ZJRG1zvNuVr+MZ0CIPTukTL2?= =?us-ascii?Q?G1QxcGUGEWrV74ZIJ3RfASnkHo2NsxZbGn8A03cAnIForVTypb/1LgAsD3UX?= =?us-ascii?Q?gLopwmb7eF/eSI/Tgatwt5u4Qi8h8csQr6/oOgpJRnu06sBfVK+lvMewE2iC?= =?us-ascii?Q?xXZNz/NiPRIxppVi6MIIm0GOvEgkmZYWyPGkhe2ixmvvJCGnp5JqBsMciX2S?= =?us-ascii?Q?Xz047uHhHFtCjfftba3Y+TneOVmNnvgf6YL/W8+5zhM1jyYvCcSmOjx76ttQ?= =?us-ascii?Q?lV7uEHLbccOtdEzwZvZncK93twKTALWozNgC2pos1wKY7wyY/99sqjYPUEMA?= =?us-ascii?Q?qmyyqkD4cDqLPTCtwrRcYskySO3pcvf6Cy0i?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 02:57:35.4879 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 851ef4b8-c452-49c8-56c0-08dd8b8096aa 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001C9.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4246 When a device is passed through to a dom0less domU, the xen,reg{-cacheable} ranges may overlap with the extended regions. Remove xen,reg{-cacheable} from extended regions. Signed-off-by: Stewart Hildebrand --- Not sure if we need a Fixes: tag, but if we do: Fixes: 2a2447757b3c ("xen/arm: implement domU extended regions") I investigated an alternate approach of parsing the partial device tree again to scan for xen,reg{-cacheable} properties, but it resulted in quite a lot of code duplication. Adding a rangeset pointer to "struct kernel_info" has a much smaller diffstat, and then we avoid the need to parse the partial device tree a second time. I discovered this issue when booting a dom0less domU with a device passed through. Partial device tree excerpt: passthrough { ... ... axi_uart16550_0: serial@a0001000 { clocks = <&uart_fixed_clk>; compatible = "ns16550a"; interrupt-parent = <&gic>; interrupts = <0 89 4>; reg = <0x0 0xa0001000 0x0 0x1000>; reg-shift = <2>; xen,reg = <0x0 0xa0001000 0x00 0x1000 0x0 0xa0001000>; xen,path = "/amba_pl@0/serial@a0000000"; xen,force-assign-without-iommu; }; }; The domU was assigned an extended region overlapping with MMIO of the passed through device: (XEN) d1: extended region 0: 0xa0000000->0x100000000 (XEN) d1: extended region 1: 0x200000000->0xf000000000 The domU panicked when attempting to initialize the device: [ 3.490068] a0001000.serial: ttyS0 at MMIO 0xa0001000 (irq = 15, base_baud = 6249375) is a 16550A [ 3.498843] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 [ 3.498853] Mem abort info: [ 3.498855] ESR = 0x0000000096000044 [ 3.498859] EC = 0x25: DABT (current EL), IL = 32 bits [ 3.498864] SET = 0, FnV = 0 [ 3.498867] EA = 0, S1PTW = 0 [ 3.498870] FSC = 0x04: level 0 translation fault [ 3.498874] Data abort info: [ 3.498876] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000 [ 3.498879] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 3.498884] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 3.498888] [0000000000000010] user address but active_mm is swapper [ 3.498894] Internal error: Oops: 0000000096000044 [#1] SMP [ 3.498899] Modules linked in: [ 3.498908] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.10-stew #1 [ 3.498917] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3.498924] pc : mem_serial_out+0x18/0x20 [ 3.498936] lr : serial8250_do_set_mctrl+0x6c/0xc0 [ 3.498943] sp : ffff800081bab6d0 [ 3.498946] x29: ffff800081bab6d0 x28: ffff8000815e0dc8 x27: ffff000001c29c60 [ 3.498957] x26: 0000000000000000 x25: ffff00000347b900 x24: ffff000005504c00 [ 3.498968] x23: ffff00000347b800 x22: 0000000000000000 x21: ffff800081b69d78 [ 3.498978] x20: ffff800081b69d78 x19: 0000000000000000 x18: ffffffffffffffff [ 3.498989] x17: 3d20647561625f65 x16: 736162202c353120 x15: 3d20717269282030 [ 3.498999] x14: 3030313030306178 x13: ffff800081a21ff0 x12: 00000000000007fe [ 3.499010] x11: 00000000000002aa x10: ffff800081a4dff0 x9 : ffff800081a21ff0 [ 3.499020] x8 : 00000000fffff7ff x7 : ffff800081a4dff0 x6 : 0000000000000008 [ 3.499030] x5 : 0000000000000000 x4 : ffff800080797584 x3 : 0000000000000002 [ 3.499040] x2 : 0000000000000000 x1 : 0000000000000010 x0 : 0000000000000000 [ 3.499050] Call trace: [ 3.499053] mem_serial_out+0x18/0x20 [ 3.499059] serial8250_set_mctrl+0x34/0x40 [ 3.499065] serial_core_register_port+0x534/0x7dc [ 3.499075] serial_ctrl_register_port+0x10/0x1c [ 3.499084] uart_add_one_port+0x10/0x1c [ 3.499092] serial8250_register_8250_port+0x308/0x4c0 [ 3.499102] of_platform_serial_probe+0x2c4/0x48c [ 3.499110] platform_probe+0x68/0xdc [ 3.499120] really_probe+0xbc/0x298 [ 3.499128] __driver_probe_device+0x78/0x12c [ 3.499135] driver_probe_device+0xdc/0x160 [ 3.499142] __driver_attach+0x94/0x19c [ 3.499149] bus_for_each_dev+0x74/0xd0 [ 3.499155] driver_attach+0x24/0x30 [ 3.499162] bus_add_driver+0xe4/0x208 [ 3.499168] driver_register+0x60/0x128 [ 3.499176] __platform_driver_register+0x24/0x30 [ 3.499184] of_platform_serial_driver_init+0x1c/0x28 [ 3.499192] do_one_initcall+0x6c/0x1b0 [ 3.499199] kernel_init_freeable+0x178/0x258 [ 3.499209] kernel_init+0x20/0x1d0 [ 3.499218] ret_from_fork+0x10/0x20 [ 3.499228] Code: f9400800 1ac32021 8b21c001 d50332bf (39000022) [ 3.499233] ---[ end trace 0000000000000000 ]--- [ 3.499237] note: swapper/0[1] exited with irqs disabled [ 3.499247] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 3.499251] SMP: stopping secondary CPUs [ 3.499284] Kernel Offset: disabled [ 3.499286] CPU features: 0x00,00000080,00200000,0200420b [ 3.499292] Memory Limit: none [ 3.792412] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- --- xen/arch/arm/dom0less-build.c | 19 ++++++++++++++++++- xen/arch/arm/domain_build.c | 13 ++++++++++++- xen/arch/arm/include/asm/kernel.h | 1 + 3 files changed, 31 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index a356fc94fc4d..23178a801818 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -274,6 +274,14 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo, int res; paddr_t mstart, size, gstart; + if ( !kinfo->xen_reg_assigned ) + { + kinfo->xen_reg_assigned = rangeset_new(NULL, NULL, 0); + + if ( !kinfo->xen_reg_assigned ) + return -ENOMEM; + } + /* xen,reg specifies where to map the MMIO region */ cell = (const __be32 *)xen_reg->data; len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) * @@ -315,6 +323,11 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo, mstart, gstart); return -EFAULT; } + + res = rangeset_add_range(kinfo->xen_reg_assigned, PFN_DOWN(gstart), + PFN_DOWN(gstart + size - 1)); + if ( res ) + return res; } /* @@ -1006,7 +1019,11 @@ static int __init construct_domU(struct domain *d, domain_vcpu_affinity(d, node); - return alloc_xenstore_params(&kinfo); + rc = alloc_xenstore_params(&kinfo); + + rangeset_destroy(kinfo.xen_reg_assigned); + + return rc; } void __init create_domUs(void) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 3dcdd7a8c46f..da7c7c000f1f 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1296,6 +1296,13 @@ static int __init find_domU_holes(const struct kernel_info *kinfo, if ( res ) goto out; + if ( kinfo->xen_reg_assigned ) + { + res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned); + if ( res ) + goto out; + } + res = rangeset_report_ranges(mem_holes, 0, PFN_DOWN((1ULL << p2m_ipa_bits) - 1), add_ext_regions, ext_regions); @@ -2329,7 +2336,11 @@ static int __init construct_dom0(struct domain *d) if ( rc < 0 ) return rc; - return construct_hwdom(&kinfo, NULL); + rc = construct_hwdom(&kinfo, NULL); + + rangeset_destroy(kinfo.xen_reg_assigned); + + return rc; } int __init construct_hwdom(struct kernel_info *kinfo, diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h index bdc96f4c18eb..b3c2d50e1e3d 100644 --- a/xen/arch/arm/include/asm/kernel.h +++ b/xen/arch/arm/include/asm/kernel.h @@ -50,6 +50,7 @@ struct kernel_info { #ifdef CONFIG_STATIC_SHM struct shared_meminfo shm_mem; #endif + struct rangeset *xen_reg_assigned; /* kernel entry point */ paddr_t entry; -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon May 05 03:00:38 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 03:00:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975782.1363112 (Exim 4.92) (envelope-from ) id 1uBm4M-0004E6-5f; Mon, 05 May 2025 03:00:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975782.1363112; Mon, 05 May 2025 03:00: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 1uBm4L-0004Cv-Ub; Mon, 05 May 2025 03:00:37 +0000 Received: by outflank-mailman (input) for mailman id 975782; Mon, 05 May 2025 03:00:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBm1b-0000Iv-Lw for xen-devel@lists.xenproject.org; Mon, 05 May 2025 02:57:47 +0000 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on2060e.outbound.protection.outlook.com [2a01:111:f403:2407::60e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b892a49d-295c-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 04:57:46 +0200 (CEST) Received: from SJ0PR05CA0148.namprd05.prod.outlook.com (2603:10b6:a03:33d::33) by SJ0PR12MB8090.namprd12.prod.outlook.com (2603:10b6:a03:4ea::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Mon, 5 May 2025 02:57:42 +0000 Received: from SJ5PEPF000001CF.namprd05.prod.outlook.com (2603:10b6:a03:33d:cafe::12) by SJ0PR05CA0148.outlook.office365.com (2603:10b6:a03:33d::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.22 via Frontend Transport; Mon, 5 May 2025 02:57:42 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ5PEPF000001CF.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8722.18 via Frontend Transport; Mon, 5 May 2025 02:57:41 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 4 May 2025 21:57:40 -0500 Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Sun, 4 May 2025 21:57: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" X-Inumbo-ID: b892a49d-295c-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ya40Kl7vpXW58SbKmT4wy6fSIm6yQZAsZ3pJs0TyxTohPtIFlh1QisUALELjViLYtHBJnL0JemLqq1Zrkc5tM+68pHa/dxHec6ASswHnI2qBkCmFDO6h48pPlzi1rdjr1I8O/ONtUZ0BEvFW8yB5cQ4cBkrAZzCGMOqqGyLsI7LxjWfuWfdMaKiqHRsw1oAzVRblFprWrzs4q59Yog+E9Rin2mlt2zk2O2H4BUrwbqNreB8J+OnDnYhdJoYDTg/lHMWGV/VqLS9rd1nHxRxL8gIVUhoEgcu+fQFkqCd2OqLSiPqejS+T4+nzyEioOYQWZm8VuqVbxHxRokR+VALVfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DRovNO/Yx1uPn92Z6qKe3rjpCFrCSbTdMugPgoXK3Mw=; b=TthiXljDvLNdx5zvJIWcHuuRtyw4toSL7V75GexyIAEeepcD8MGNSrfJhUdm+wnTvuSvrC/XADFEUqQ6alh4plpDDxl4ib2+TyL4EtmL3pLluI6HmXkUMW2CkfNFvA4PxrLVDN7jKYOphgTeLL3QtqFUtrw4Qivq1gDXUBCTGKw2gRGtjJ0MUocqLc+gqxaQdJzg5yROUv3TYZupjWF/FEPC3glV37FTxLnmWbbve/s9U+WlNDWl2yY8paTH/VC6EFiUuvQ3WQ8G8Wgta6yLYaiHoReupQhSvhIQum7oQsrT+4/qMkBw0bUw6e1Jq7+qFYn6Ldp9cRwIT3fSnYME5Q== 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=DRovNO/Yx1uPn92Z6qKe3rjpCFrCSbTdMugPgoXK3Mw=; b=nPbo9aXLQz3ssy5pugGLZvdcz8zwjG1V0IQiawQ6gWo5wMO6bVCBsLk/lhFaFhfb0IZZJyynnoH4bSJSFdkG/gphtJUbGdRh2hGZ2KuXfphvGjR40GHHc2vhy6cGU5hlKUIpXUj7aDG3jk0wsCwk79+a02Pbgx9kky9sue0Pxkg= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Stewart Hildebrand To: CC: Stewart Hildebrand , Anthony PERARD , Juergen Gross Subject: [PATCH 6/6] tools/arm: exclude iomem from domU extended regions Date: Sun, 4 May 2025 22:56:29 -0400 Message-ID: <20250505025631.207529-7-stewart.hildebrand@amd.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250505025631.207529-1-stewart.hildebrand@amd.com> References: <20250505025631.207529-1-stewart.hildebrand@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CF:EE_|SJ0PR12MB8090:EE_ X-MS-Office365-Filtering-Correlation-Id: b2eaadf3-8d25-4491-f6dc-08dd8b809a5d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?OUaHII7SAKJin7t7jEG4qXm2nsBSz+4FHZWbvgzndMcMrjhMFlcf4lHRpSNv?= =?us-ascii?Q?smvr0bDGyOySVrnUlrY/eJN1wsplEPqeo9n6L1sESxpDbVWmaeydP5pLYRtM?= =?us-ascii?Q?cescWF7HVYuTwvqmNAh7fJQqCXLb2v8Z+Ovy9EPLClwHA4nami0/D7hKYk3j?= =?us-ascii?Q?8DWsW1a14+kjsz3CCNd/IwxHyRCxOKgMP6xmyPFhfBDKMQ2U7dHcBWW2G0J6?= =?us-ascii?Q?jqe7l5krdIVe0YjVmIFFFSo56DLraio3wq+BcSyJJkRkmSSCTOERswmUROYZ?= =?us-ascii?Q?mSkc8eARiqjMjXmjB6b0jt3/NEEmrh0cNvrZMZ3WScGbzCc8GdPEAXER4LS8?= =?us-ascii?Q?+V1dhqgTpg2JMuZ8fKhSqMngJltfxHAVXpuCsDCBP1UPqhjmhQlIrfSNI5hv?= =?us-ascii?Q?4f2tK5u6niJu+Efp9wHVQF8dCgkh2i0fUCXSKZx0mBP/PQygMZwKxbJ6QsCm?= =?us-ascii?Q?zMgsNNv5Hq0rtab+Clo4ndq/t7f6oDap2hEL55+7x2CgaWnLM/vJ6ZDsNChW?= =?us-ascii?Q?E4ej0IOJxReAnBF5SC1R3F3Josk2Z04+tGuVkSTUmSBzVve6TtEv81hSS+Ne?= =?us-ascii?Q?ia5QoX3PAGmit6ZlA+BAmD4240rX3Jv+Hb/s1iWTZO9gC+fWGq1uVT24A0O5?= =?us-ascii?Q?tAq3mKIy/z835DKWV4HmuR7EnQujZvn/dB67g/RKnuqmff8rta9gsEXxHIso?= =?us-ascii?Q?i3PmmW335A4Y/P55WCzZemHzDBbHf82f1jQ5/o9hQ6aXyBnQCfHqj8YT+HIV?= =?us-ascii?Q?MC2Nc0LtFDflXhQpH6KqIQ7EgfiuCypLPpafAVnEGMpdWY26J8nIwe7NS97j?= =?us-ascii?Q?JDCSyIpVD2IJKIfdaAvl+qZ1b3M+Gbhf//P+8UGqz20erH5SW9fd0ymammpJ?= =?us-ascii?Q?OM2GDfFR6DCp13hOFXKrGOb35FChSo5uDsHei5WUSjGxR6u/L8GQRob7zyAB?= =?us-ascii?Q?ilwFvXqYewh6K8L8lTqeO0NY71bd1QO6wb1n2izyy5xCAlIT2YvY6LtvtYFF?= =?us-ascii?Q?hcs5Vi3lS1kyx/FzbTz60BeuhdvPUHCcUN+rRrrahKzzo4AsVvzqLBF87uUU?= =?us-ascii?Q?ZxaCpQIsDGjbkQY4SUZxIUeTjoImwmSzBU+SaGCUAuy0Fd0hGwXCvu9aPVy6?= =?us-ascii?Q?D90lL8rMucKIqU/zd0uvR1VWjvPh8QvJFsLCT01r3EIB+OmUi/p826TCm4BN?= =?us-ascii?Q?e6zPok+5nILHfBn8+IFGxbuc+sP/dIX6TjG/CdV72lLpsVqzSA6oInKLIeYd?= =?us-ascii?Q?339B73G/Mbea+nX5BoqxnLaSioyIbeXauFYpjZcpsMJWCGiIqag1erSW2zJz?= =?us-ascii?Q?5QUYnj9UzuHzyzqxVaeU8tHinyDTwKdSeBUCbLSUbywmgKguFLlXs2O7lrv+?= =?us-ascii?Q?Rsy8EkYATuqu7gB3bJPtJgqOU/iTjVLa3+ISZsSG5nvFEpyA2M4agNdqUa6S?= =?us-ascii?Q?e49r0pWiNvk32ROiBIyK2f6RujjZc+NAbo7U8rUs4+iP8sHL3ZZOS6uoTn04?= =?us-ascii?Q?nVAKrcAjMmB9RBYEzCsqQA6A+5vJfMXlCJIH?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 02:57:41.6993 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b2eaadf3-8d25-4491-f6dc-08dd8b809a5d 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001CF.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB8090 When a device is passed through to a xl domU, the iomem ranges may overlap with the extended regions. Remove iomem from extended regions. Signed-off-by: Stewart Hildebrand --- Not sure if we need a Fixes: tag, but if we do: Fixes: 57f87857dc2d ("libxl/arm: Add handling of extended regions for DomU") --- tools/libs/light/libxl_arm.c | 118 +++++++++++++++++++++++++++++------ 1 file changed, 99 insertions(+), 19 deletions(-) diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c index 75c811053c7c..8ae16a1726fc 100644 --- a/tools/libs/light/libxl_arm.c +++ b/tools/libs/light/libxl_arm.c @@ -798,6 +798,8 @@ static int make_timer_node(libxl__gc *gc, void *fdt, return 0; } +#define MAX_NR_EXT_REGIONS 256 + static int make_hypervisor_node(libxl__gc *gc, void *fdt, const libxl_version_info *vers) { @@ -821,7 +823,7 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt, */ res = fdt_property_reg_placeholder(gc, fdt, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS, - GUEST_RAM_BANKS + 1); + MAX_NR_EXT_REGIONS + 1); if (res) return res; /* @@ -1517,17 +1519,29 @@ static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname, #define EXT_REGION_MIN_SIZE xen_mk_ullong(0x0004000000) /* 64MB */ -static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom) +static int compare_iomem(const void *a, const void *b) +{ + const libxl_iomem_range *x = a, *y = b; + + if (x->gfn < y->gfn) + return -1; + if (x->gfn > y->gfn) + return 1; + return 0; +} + +static int finalize_hypervisor_node(libxl__gc *gc, + libxl_domain_build_info *b_info, + struct xc_dom_image *dom) { void *fdt = dom->devicetree_blob; - uint64_t region_size[GUEST_RAM_BANKS] = {0}, region_base[GUEST_RAM_BANKS], - bankend[GUEST_RAM_BANKS]; + uint64_t region_base[MAX_NR_EXT_REGIONS], region_size[MAX_NR_EXT_REGIONS]; uint32_t regs[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * - (GUEST_RAM_BANKS + 1)]; + (MAX_NR_EXT_REGIONS + 1)]; be32 *cells = ®s[0]; const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; - unsigned int i, len, nr_regions = 0; + unsigned int i, j, len, nr_regions = 0; libxl_dominfo info; int offset, rc; @@ -1542,20 +1556,90 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom) if (info.gpaddr_bits > 64) return ERROR_INVAL; + qsort(b_info->iomem, b_info->num_iomem, sizeof(libxl_iomem_range), + compare_iomem); + /* * Try to allocate separate 2MB-aligned extended regions from the first * and second RAM banks taking into the account the maximum supported * guest physical address space size and the amount of memory assigned * to the guest. */ - for (i = 0; i < GUEST_RAM_BANKS; i++) { - region_base[i] = bankbase[i] + + for (i = 0; i < GUEST_RAM_BANKS && nr_regions < MAX_NR_EXT_REGIONS; i++) { + struct { + uint64_t start; + uint64_t end; /* inclusive */ + } unallocated; + uint64_t size = 0; + + unallocated.start = bankbase[i] + ALIGN_UP_TO_2MB((uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT); - bankend[i] = ~0ULL >> (64 - info.gpaddr_bits); - bankend[i] = min(bankend[i], bankbase[i] + banksize[i] - 1); - if (bankend[i] > region_base[i]) - region_size[i] = bankend[i] - region_base[i] + 1; + unallocated.end = ~0ULL >> (64 - info.gpaddr_bits); + unallocated.end = min(unallocated.end, bankbase[i] + banksize[i] - 1); + + if (unallocated.end > unallocated.start) + size = unallocated.end - unallocated.start + 1; + + if (size < EXT_REGION_MIN_SIZE) + continue; + + /* Exclude iomem */ + for (j = 0; j < b_info->num_iomem && nr_regions < MAX_NR_EXT_REGIONS; + j++) { + struct { + uint64_t start; + uint64_t end; /* inclusive */ + } iomem; + + iomem.start = b_info->iomem[j].gfn << XC_PAGE_SHIFT; + iomem.end = ((b_info->iomem[j].gfn + b_info->iomem[j].number) + << XC_PAGE_SHIFT) - 1; + + if (iomem.end >= unallocated.start + && iomem.start <= unallocated.end) { + + if (iomem.start <= unallocated.start) { + unallocated.start = iomem.end + 1; + + if (iomem.end >= unallocated.end) + /* Complete overlap, discard unallocated region */ + break; + + /* Beginning overlap */ + continue; + } + + if (iomem.start > unallocated.start) { + assert(unallocated.end > unallocated.start); + size = iomem.start - unallocated.start; + + if (size >= EXT_REGION_MIN_SIZE) { + region_base[nr_regions] = unallocated.start; + region_size[nr_regions] = size; + nr_regions++; + } + + unallocated.start = iomem.end + 1; + + if (iomem.end >= unallocated.end) + /* End overlap, discard remaining unallocated region */ + break; + } + } + } + + if (unallocated.end > unallocated.start + && nr_regions < MAX_NR_EXT_REGIONS) + { + size = unallocated.end - unallocated.start + 1; + + if (size >= EXT_REGION_MIN_SIZE) { + region_base[nr_regions] = unallocated.start; + region_size[nr_regions] = size; + nr_regions++; + } + } } /* @@ -1565,16 +1649,12 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom) set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS, GUEST_GNTTAB_BASE, GUEST_GNTTAB_SIZE); - for (i = 0; i < GUEST_RAM_BANKS; i++) { - if (region_size[i] < EXT_REGION_MIN_SIZE) - continue; - + for (i = 0; i < nr_regions; i++) { LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"", - nr_regions, region_base[i], region_base[i] + region_size[i]); + i, region_base[i], region_base[i] + region_size[i]); set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS, region_base[i], region_size[i]); - nr_regions++; } if (!nr_regions) @@ -1626,7 +1706,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc, } - res = finalize_hypervisor_node(gc, dom); + res = finalize_hypervisor_node(gc, &d_config->b_info, dom); if (res) return res; -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon May 05 03:00:44 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 03:00:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975789.1363125 (Exim 4.92) (envelope-from ) id 1uBm4S-0004lM-HF; Mon, 05 May 2025 03:00:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975789.1363125; Mon, 05 May 2025 03: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 1uBm4S-0004lF-EQ; Mon, 05 May 2025 03:00:44 +0000 Received: by outflank-mailman (input) for mailman id 975789; Mon, 05 May 2025 03:00:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBm1R-0000ZH-Cm for xen-devel@lists.xenproject.org; Mon, 05 May 2025 02:57:37 +0000 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2062b.outbound.protection.outlook.com [2a01:111:f403:2409::62b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b25f6222-295c-11f0-9ffb-bf95429c2676; Mon, 05 May 2025 04:57:35 +0200 (CEST) Received: from MW4PR04CA0330.namprd04.prod.outlook.com (2603:10b6:303:82::35) by PH7PR12MB6835.namprd12.prod.outlook.com (2603:10b6:510:1b5::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.21; Mon, 5 May 2025 02:57:28 +0000 Received: from SJ5PEPF000001CC.namprd05.prod.outlook.com (2603:10b6:303:82:cafe::11) by MW4PR04CA0330.outlook.office365.com (2603:10b6:303:82::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.29 via Frontend Transport; Mon, 5 May 2025 02:57:28 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ5PEPF000001CC.mail.protection.outlook.com (10.167.242.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8722.18 via Frontend Transport; Mon, 5 May 2025 02:57:28 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 4 May 2025 21:57:27 -0500 Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Sun, 4 May 2025 21: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" X-Inumbo-ID: b25f6222-295c-11f0-9ffb-bf95429c2676 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vJKJ3l2udGrbZe1eahSinKvUmmDC23VwffH2yLE7QK6X/mbVbfIfuRMWAvPJaI9OcxLf2DrxjdyaraRhw/+Cn72Zrr+NNySGHbJOXd28h+KORXUcj/5CNXLxsqs3jAjLkDdeUcwxbCjs1jSntXc9c2ObCN0vz+tYWqBZi7l6XOFAtNNG/YDEYmD1VYyCY+SHUXnYarE0xqZqAysstLsUl/Y7C/JuyIJs11ovnFWOLe8ZZvjOTw3YSRyYPHMZ64qt76Tk1SmI/r4wBPfeNsFW4cV5Gg2vbUHXqg+Pqs/7GmLNHbOMBPwVeSZg2+IVV2rISzWJ1rP6bT7F+idOj0ByFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1vYNosH374LDHd8Qsbgs/FAQVGbH1a3F/WMoojDLEC8=; b=y04NkEporkXEWcPyrl8M5XKg4Z54rnIfrs1aV0EfGBUh1T9MvEgHCa9zG5jS3+mEs6sOKmxrxy1p3QKmWDe68+NaA2MAVuCN4T++MzeVRZVBD+dm8fNiy3C1sZ7XTHhO9koyziOYfw4qPPpI5OhAmBS0740YxaVZqwyDGmAG7AhkUnqOQcmeYE+IEVfpKu78/7R60jIiWovGLUQQxdNIGVDc61Wba1ktRTp4JV7bpN5/9HIVba323TzM9a5Dj5Lg1Lf6EqeIST1p9Lwc/IJa7rH3lWRHGKKB3yTItX/uTD7fFQ9OzfkU7Rr9NF45QxrSZAx3bShSyQODofIqLVDrLw== 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=1vYNosH374LDHd8Qsbgs/FAQVGbH1a3F/WMoojDLEC8=; b=MdrM8Dpv6lFYFWKjTpzX2Lik8g+VRHslLl81VHysWb0IYT69nNmH1oKJMzqg+XvwYQCICjauaq2BjsCQ1tMNmaVssOar1eCRpFwN5CmSP1wmZeamY3EsU3rrG6Ee61IEHP77JNm23WP3aS5Uye7r2/9rsgrShGlpwvebgiqqKTU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C From: Stewart Hildebrand To: CC: Stewart Hildebrand , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH 4/6] rangeset: introduce rangeset_subtract Date: Sun, 4 May 2025 22:56:27 -0400 Message-ID: <20250505025631.207529-5-stewart.hildebrand@amd.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250505025631.207529-1-stewart.hildebrand@amd.com> References: <20250505025631.207529-1-stewart.hildebrand@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CC:EE_|PH7PR12MB6835:EE_ X-MS-Office365-Filtering-Correlation-Id: c38d09a6-0714-4a27-5d2e-08dd8b80926d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?UZb1mmPA4CUZ1fcJdmgSxmy8YP0/vRlFTORt6xmO/UQNs0XkDnlmBUmYaptv?= =?us-ascii?Q?xAb04U9Vh95zZMSg7s/hEFSlcZilRfaQRH3RxQGGNEYtb8Zr31NWM0jCfh6N?= =?us-ascii?Q?0boEyTh2GRXilHcahfvl7DJd3ITWvHg203CQQOXkHlPH7vVyQSb0eXJeMBwm?= =?us-ascii?Q?WehfDY7ltLFhusvFLF3Q0MES3bQetK0VydYpgfm+jp68Js4PB0vroqT8zEPb?= =?us-ascii?Q?aSgpe8/hl//d0QkTxWUWyesB4rj784SYMg6gpYK2S78YUAEUh0dEYaxdUpXF?= =?us-ascii?Q?Z6GYCRUo8JsXgR/Mu6poE1tlJORPc8KeMCQWfeSPyzPZLnyxLzrLpIEGlpEj?= =?us-ascii?Q?UxLqEwKmcJKj+X27Ok+QEYbx8c+TIsWZJssyzcQSUip4cGK4OAWe3p/8k9L8?= =?us-ascii?Q?DMH6ytUsVzMGY+qK/6+pONOB837L811nZ95j/Jq6rYN2R+1cvJuHznAvD6Qu?= =?us-ascii?Q?gyg4kUxCkTkKmTM0vAS7Yn8LILbqn2HU54Ibt54P28iZi+Ue28nRJmPHXSzM?= =?us-ascii?Q?thPIyMgLix5z+HuDeDZAff2rrV7h7fct18/h8Ec96UPpJSpQK7ODmoRrEeVy?= =?us-ascii?Q?S9rujGURU8gWglLjhixyAYxaJFcNrHhINxL6UeUYejdlA3q6m/8bs1nwbDuk?= =?us-ascii?Q?SGquz2D5CFRnYDyorVpQR+ksl3nWtUC0GOoNKHvI8O5vVtMQDRVhbYq1dZi4?= =?us-ascii?Q?5p8LSq61sCteUx3LPUEh/JqqSuupFB9RbHCrXTd+ZVjRElLH5dUFP5CQ1nrj?= =?us-ascii?Q?2kyQjauQmREWPYiI+Mwrx6MVCMphTA1jvhUIfoodjBEUetNZjuee7lxJXrP7?= =?us-ascii?Q?gGLVvPds0xqT2GxuCuwLWqMILM41Dym9BkKyO+/C1q9hxniihULbwa5o7YNy?= =?us-ascii?Q?e2HPkAPb1S/N+AvBfcr0cE701NcuDHROxzY3/i87UI3vdiZq2+HKe9V6kpHO?= =?us-ascii?Q?ogfjHZI+gSvSducWJHkNIGpmel2M1CfBOnOkK4rF8IT0xLWlLlIbpOr0frof?= =?us-ascii?Q?zWJ2KV6O2tl6JxzjLtRgU1AsRTv+S0LvkKUZWoLcPo0EN8iA3M1AfPvck5Vl?= =?us-ascii?Q?ccchfylqJCP9d6gyKBNwP4nR4KyAbHzkkE/kJInY1sb88h1roW6fdCNzocuR?= =?us-ascii?Q?4Jn40dTxPPnFbyfSlrdWHNIijTOl9F77IxWagIkDFcRPeyGeyVs5HrBChGOg?= =?us-ascii?Q?+GpEG8LF4TSSks+pqu0Ni0Xje5I/aNUe8qjnUDDzsTRMOpQbH1bHJw/Jdr2F?= =?us-ascii?Q?U6EJxgcTb0USq+eYYnCYuqv/YsbWK9zEpNjzjIsj6tkfF1lES50XKFv8JpBc?= =?us-ascii?Q?5YFnRkKeRxucOrzvoBQj2KWxn/yemZ9Vb0eTNMhABs4JGEscJ61Sr3adNZdk?= =?us-ascii?Q?XogDAYjtYkVNr0igYKH5833hAK+nHhFKCGMnjcvon5HaZJAeTcjnAVul15Eh?= =?us-ascii?Q?Dx2/GMX9Fmc6dFl1upzygc1+tcNQTuCiIElWcoUf225iLfNbpv8KSDSPQvw2?= =?us-ascii?Q?f1q6+7Q09gDn3hhyoW2s+hYprA3eQI9CJR3b?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 02:57:28.3791 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c38d09a6-0714-4a27-5d2e-08dd8b80926d 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001CC.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6835 Introduce rangeset_subtract() to remove regions in r2 from r1. Signed-off-by: Stewart Hildebrand --- xen/common/rangeset.c | 12 ++++++++++++ xen/include/xen/rangeset.h | 3 +++ 2 files changed, 15 insertions(+) diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c index e75871039087..b9e8912fb1c3 100644 --- a/xen/common/rangeset.c +++ b/xen/common/rangeset.c @@ -397,6 +397,18 @@ int rangeset_merge(struct rangeset *r1, struct rangeset *r2) return rangeset_report_ranges(r2, 0, ~0UL, merge, r1); } +static int cf_check subtract(unsigned long s, unsigned long e, void *data) +{ + struct rangeset *r = data; + + return rangeset_remove_range(r, s, e); +} + +int rangeset_subtract(struct rangeset *r1, struct rangeset *r2) +{ + return rangeset_report_ranges(r2, 0, ~0UL, subtract, r1); +} + int rangeset_add_singleton( struct rangeset *r, unsigned long s) { diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h index 96c918082501..817505badf6f 100644 --- a/xen/include/xen/rangeset.h +++ b/xen/include/xen/rangeset.h @@ -85,6 +85,9 @@ int rangeset_consume_ranges(struct rangeset *r, /* Merge rangeset r2 into rangeset r1. */ int __must_check rangeset_merge(struct rangeset *r1, struct rangeset *r2); +/* Subtract rangeset r2 from rangeset r1. */ +int __must_check rangeset_subtract(struct rangeset *r1, struct rangeset *r2); + /* Add/remove/query a single number. */ int __must_check rangeset_add_singleton( struct rangeset *r, unsigned long s); -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon May 05 04:25:40 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 04:25:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975832.1363135 (Exim 4.92) (envelope-from ) id 1uBnOR-0007tQ-CI; Mon, 05 May 2025 04:25:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975832.1363135; Mon, 05 May 2025 04:25: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 1uBnOR-0007tJ-9h; Mon, 05 May 2025 04:25:27 +0000 Received: by outflank-mailman (input) for mailman id 975832; Mon, 05 May 2025 04:25:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBnOQ-0007tD-VA for xen-devel@lists.xenproject.org; Mon, 05 May 2025 04:25:27 +0000 Received: from FR5P281CU006.outbound.protection.outlook.com (mail-germanywestcentralazlp170120004.outbound.protection.outlook.com [2a01:111:f403:c20c::4]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f73891b2-2968-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 06:25:25 +0200 (CEST) Received: from FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d18:2::5d) by FR5P281MB4888.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Mon, 5 May 2025 04:25:23 +0000 Received: from FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM ([fe80::4e19:b0d5:6db3:dc90]) by FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM ([fe80::4e19:b0d5:6db3:dc90%3]) with mapi id 15.20.8699.019; Mon, 5 May 2025 04:25: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" X-Inumbo-ID: f73891b2-2968-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rubcwpDE08Mfgz7L1c2mh5nQGpYd3rWVIUrwThZOkf08+VV9YBtb6HYI+iZni3uRC57eq7gwbErh//ItUUEY8N66BpZ3OzCsS8D0j3/mI0ERNj+a/1eY2ZGxzMCqYS21zw9C+pSOAW6X1kCM5VlGsJykgU9ASghqRczX9XdbLJUTCc1KgmTpDuRZCSEYQ/7egGhvpaGO/cksOB/G9efqUg1insX6ZCumwPQdl8guM+NH8B9AXTRzFkIuJ8UhUM1Nn2Fk8PTqYjG2x730/SKeihWnbo1riE+bG4A0cswAst5hEMraApabfMjOPjRa3SphzhHWjm0VFYcvY9aDAYyuXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wCPLpFcuvpNGpG9Zlh+5o7uKYUi9HXdB2CHO+LqZ9RQ=; b=R2kyZK4t49ZgFQCq6wFPVzpZnmWLqSJKG33iAGIq6pzdNMLqbx17eoaEKSxkDTeEv6aHhyPqjDPagnSDTbqi+di2ZFoXNmGSJHm2DROAf8t8G4cAHFNsn24riqROipr7wpKwCyTu9L4MVcHu2IS0wa86vu3kLfMjGKpCoFwr9NoYtQOaxlcSQ8U03emUlH54vMdZUxR7XJ0I2pd+3sXeSzQLFbYVR23TiybwG1LQW7x0ZDK8lIbI1gE7PM+anm8O6WhBOOGL6hRBbZRxInmbDvEx2v1C/C5DKRihI6fEJKzl/oUyDc8jPFkMrBb9RjaF64akxnXW7TFk/6HvfG2J6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=daimlertruck.com; dmarc=pass action=none header.from=daimlertruck.com; dkim=pass header.d=daimlertruck.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daimlertruck.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wCPLpFcuvpNGpG9Zlh+5o7uKYUi9HXdB2CHO+LqZ9RQ=; b=QGus/aLz+rhbUs3vkQoU98bzYCNIJnVXMla69lokupJa2FOLuwE8SbYJZBGOkgZzzcVwmkHgPJ11ai6rzIc3udAZ+KNqSJtZYPMp2ytewcdVvvU7wveapRhlDNfS03u/ZAsloRrHSQJNq3IWaxrWUYpyF8Y7QhPaXTlgFFb3Cdj4hmzoTVCpLlL2q/b2SVziBAp/cvRqocrMC0TlSaP+FHW92e47CzPcc9kISR2bpdITJRMfazhGnVxoQs9GU9Rv5/H7K05Lv7qfAIP1j758lV/H6jG0+yhLn5mUsYUFqeHbvzVitC/dPuooYDnS5xCZUaVtW07fPZozOHtFOVxtkQ== From: "L, John Preetham (893)" To: Volodymyr Babchuk CC: "xen-devel@lists.xenproject.org" , Ruslan Shymkevych Subject: RE: Request for Documentation on Bringing Up Xen on R-Car H3e (H3ULCB) Thread-Topic: Request for Documentation on Bringing Up Xen on R-Car H3e (H3ULCB) Thread-Index: AdtsrjaU74AF3fZpR/+NK9h56D1xZhQx2++A Date: Mon, 5 May 2025 04:25:23 +0000 Message-ID: References: <8734ha2evr.fsf@epam.com> <87ldv0248u.fsf@epam.com> In-Reply-To: <87ldv0248u.fsf@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_ActionId=cb9711b7-4f14-4229-8820-b10613a1c346;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_ContentBits=0;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_Enabled=true;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_Method=Standard;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_Name=DT_Standard;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_SetDate=2025-05-05T04:24:53Z;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_SiteId=505cca53-5750-4134-9501-8d52d5df3cd1;MSIP_Label_b97ea58d-47e6-47cc-9ab7-39ab03def869_Tag=10, 3, 0, 1; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=daimlertruck.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: FR2PPF86245AF1B:EE_|FR5P281MB4888:EE_ x-ms-office365-filtering-correlation-id: a2f51af6-9152-43c0-a082-08dd8b8cda70 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7053199007|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?szM+4id2fQPyQr4FxxQXr6nTENY1wJQ8xfLZDgWbw4y2tRW0Ms/Ed2ZPqdY2?= =?us-ascii?Q?/M6E8zcTo1mgRXAdM11LbNI83li7LOUE8rs/K3bfphodbPp/2AzpCk36a7MT?= =?us-ascii?Q?mHoS9VUn1oE70T78NDn2VZNZApHvrpnVI1HUQbxUB6X46eqFNaBkGhjNFFsh?= =?us-ascii?Q?0oDdFsYoiWW36MXNo6eIbPT8E4a2rhTbcnSyC/iG3IPihyLsMs4/k33CUElT?= =?us-ascii?Q?65lLEGtyslmzYWdPunSUSoCSNQsKqBuiH8/Habzink+PqGQvNakRhRFgsVTn?= =?us-ascii?Q?WNgLD34cioZrOUyNNqVkQrcCfJoOppse9wxKPLn4zuyB6Y0wzSgMxgFiTp1m?= =?us-ascii?Q?plzMowELFhPyCvBP3xuZuOWzuRTpwEmtdUMSs+at2QRWitTxNuAcPubiD1Bc?= =?us-ascii?Q?dkVToOw27unJsyAzuI4GRDUtwHq02QUaKF0nSFdVw1wgF4SZoJv6Dq/NNpCi?= =?us-ascii?Q?ja/woXPxikttk5hmWrNTU7nIk6hCPiasX+VhQfQXR40xjWaxmvrbgeVtaq1i?= =?us-ascii?Q?3wFniu7DX+i6KVCOrNWbiQt8+5xXdp/GqfjqlZY/H2AnJBZvIbjfUSDhf/nR?= =?us-ascii?Q?6QSVMCQ9GxD3N7QhMXJlmpbqffBnyIVuWgv58k01dDWozHCgSyq5hcp6lqza?= =?us-ascii?Q?ICJ+U3b/1ZnVCW/WkfWVmOMdtgQ3fZctfV2/+G1oKPwNAzIB0TroTyUYdti3?= =?us-ascii?Q?wiqTQuSjE1C8ZLGu8jTB/B+06uO0szPx3Wi4pydqDw2l6bJzdN+Sc10oBKeo?= =?us-ascii?Q?w6bhZddLkiueV0sMaBtCNDKnuXs5mzOlEDGwCWTIQMGh1U9KEWGR1qOOrH5p?= =?us-ascii?Q?cq67POwhwYNGcBFMxphESbcYOb9Z1CCNvJ8bhaLQ/5rAqCUGlnLn87d8tXs/?= =?us-ascii?Q?2LBiinLtfJLEiNyN4WESivjoWPj8Gno1v1sqe4N7kSdDzjyDCxK1WgJSWnKv?= =?us-ascii?Q?AzKyZGUGvyaIU9geVvlnqL35TdpBKCkAM+UODHpEdbebNeEbXIhH1MwyKtbU?= =?us-ascii?Q?E04UOIevybcOdHYID3UshhJVj7I23tsCNjrxOsDaczR7HX1JHmZFsZm7IjJo?= =?us-ascii?Q?ZTvBRkxYJfEo0X2e2bxK92eYtAW3XGROUKd57aTx2eI473fTBaPj7jc2IfY9?= =?us-ascii?Q?CtAQQP8bEEjA+LRU/cGrhG878ablVkf2V3pYl8d39eXZ137DG1eBISSNEmQZ?= =?us-ascii?Q?8L5qaPlX/0vUt1WAmAkZ61V5oPSTZN0v5rAuOyzdCu0z44337K0hU+ZQiC35?= =?us-ascii?Q?Rs6eXRlUNQodeK25ox1L/7NpQ7EdTcAvRQZavcQGsWdRpwz9nUKSY/OskJKe?= =?us-ascii?Q?MCIqR8h273rUBwiCboVksLchyPEo6BOeddsICdEue4krXWKgCnCERuT+fSmo?= =?us-ascii?Q?JJH/YsRCFwhG6vJ+CBKXLGGczkhrat3PVDReWeGPn538STCUZ7AR/PVPeH9x?= =?us-ascii?Q?58LmVZiSgfg=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9NDDybl1bK+yvMIVZ139kqZnoFVxMnl6lOLPCGiOHYZIXb8Z7B38RspXQtXB?= =?us-ascii?Q?q0mTezDD169zdhsI0bBDKFb35T0cfmH6nkDIIwznuBSW1vGG9AXzNK7dS4V2?= =?us-ascii?Q?swPwwEdK5L9DClX+kKG90eZ3Ute0/GsH6jA17IffWTUtGk6DJMM7hUwKCLdD?= =?us-ascii?Q?UPbFQYbnfp+SGxHeEFgmkLlDN5uxVzpC0oN08JL5SMkDrFkEU/oWBWjg+iyn?= =?us-ascii?Q?SQVUg5aVbZ0zWQ7VImC33pbYFmlKcJISJH6c5w5YytVFUt+YMLBYVKtuesc8?= =?us-ascii?Q?xmw1gpeB/whPpDhEdSX6gJyVOS8OTstcxSIslwBzySDArDJOfpG0vRSSbYJW?= =?us-ascii?Q?CMeciLCkr7GTCjjYkJA7FTNJlk8o83hMpr9DdyhA49QmQ7+FwhTuu677JQhs?= =?us-ascii?Q?V3GIKtFit7SKM/8UKA0yqDMbTVuDGhW0ygzeEgmIOJq21ja2vCd9gbx/fTwk?= =?us-ascii?Q?dUrxcojB+/d3wk/YSHh0SZTXJ505maFq+Uiu0V+QTIHL9QM/DFvkLbIky8un?= =?us-ascii?Q?BD1XGIz3avqvFes67482/hdQNmrMe0U6p+l7pQ38R90B0njvjm4rUZgiTeTj?= =?us-ascii?Q?P6yLjmuOXXggAvGb3s3acGRXp5Cr2ZtpSe0283ZzYm2gzXifxR6Hu1xpx1Ec?= =?us-ascii?Q?uvKxWfY/ZwfXI5T3wVxrO4nqeiO9mrHeyBB+aaSfF/ow+qhnATDLusHzeOoi?= =?us-ascii?Q?74NTfs3rnCs3p9GDzPjSELxif6iYRPsmSCnMjAj9VSUJPA3VyPCwH6irb+7G?= =?us-ascii?Q?iUp+Fh1+vlA5Tc9XzhVR/CbVwzzRXFDBlTxYb+yRcLNZ3uA4xsg+ykzZZynL?= =?us-ascii?Q?Ma+xqQTuY5BCyx6e6wMrn9NgvIkaceit7A29qB61/PE1BhY0VCCvnKhfWMwL?= =?us-ascii?Q?LGdcjw/DK2nj6IFEcGmLRrhlpNbc/Ppt9//Oy/yf05Tn3TtX5eiffAX1Q5oW?= =?us-ascii?Q?so2cMhX4p8S0p4/GdGgXby39kpxD8H04yJ1vAWK9DwvkGCgTK9GjdK5mwDBT?= =?us-ascii?Q?2Fhgqqd/+RHvr7OpK1riNgSU51EJ3VnNpwKkCl+rwFa+R4w1Sw7HXQC2KK4s?= =?us-ascii?Q?m7+iWsRxAC6qd9iAFkA9ft3OaaMfIFGKKvliZHWJ8qCkklB/Umhb+aT+cgi1?= =?us-ascii?Q?+cQpD0P0XgC7cjIN49A2ewnooo3eUTfTpqcb9A0Fa2AChvyfdXUsDmNgoTqQ?= =?us-ascii?Q?ez6RBx7pZfhg1def+2bzS5rVEFpYq4J2BCpqxU3ulfJCZqg8UC81qvMD5QIV?= =?us-ascii?Q?/MB/dHyr6KYzKJSnfbJdy2zCU4vqvdL9yvMqRfpmSoPhsthRp/794Kosbh4S?= =?us-ascii?Q?eu+v2bg3sqqSVDSddVlQWqvLBVbR9h1s3l6AOOVIOvQUdtJy64Qtbm+CvKQX?= =?us-ascii?Q?muJUHgKLjLG3caxOBkKl31JjXaPkHJdEUbLE1XVFHF1hpIDpyYhJ13UXGPo7?= =?us-ascii?Q?GA3maZRQPOKJrwlH3jMxvgAH828KRvYy/C4ypnM37S3o9PiiV6KapDqVkzft?= =?us-ascii?Q?DbBJ5ghv6w990psQYBfNivRLQ7Fvm5VfOLS9S6DzHmQZNDdCPf5wQHqk2v+e?= =?us-ascii?Q?1qqvYsSxGt/JSk1bWXw=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: daimlertruck.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2PPF86245AF1B.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a2f51af6-9152-43c0-a082-08dd8b8cda70 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2025 04:25:23.2824 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 505cca53-5750-4134-9501-8d52d5df3cd1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BqeWnmOdbxEa74/E8UoujiHAXg3da9fqxY0HE0W9IcrJ8RY/WD9NXop4Ud6bP0x8sRDx3JJgCT1TSawVP9tvLQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR5P281MB4888 Hi Volodymyr, Thank you once again for the detailed explanation and the helpful resources= . With your guidance, I was able to bring up the XEN hypervisor on the R-Car = H3e board successfully. I really appreciate your support. Now, I'm looking to move forward with bringing up a QNX guest on the XEN hy= pervisor. Could you please share the procedure or steps you recommend for t= his? It would also be very helpful if you could provide an example Device T= ree Source (DTS) and XEN domain configuration (CFG) file for the QNX guest,= if available. Looking forward to your input. Best regards, John Preetham L -----Original Message----- From: Volodymyr Babchuk Sent: 24 January 2025 10:33 To: L, John Preetham (893) Cc: xen-devel@lists.xenproject.org; Ruslan Shymkevych Subject: Re: Request for Documentation on Bringing Up Xen on R-Car H3e (H3U= LCB) [You don't often get email from volodymyr_babchuk@epam.com. Learn why this = is important at https://aka.ms/LearnAboutSenderIdentification ] "L, John Preetham (893)" writes: Hi John, > Hi Volodymyr, > > Thank you for the detailed suggestions. > Since I'm new to XEN hypervisor. > > I will approach the recommended method. Yeah, I think this is the best approach if you want get something working A= SAP. > Could you please let me know which Yocto version is stable and tested fro= m your end? As of now we are using Kirkstone. I believe, this is the latest Yocto versi= on supported by Renesas BSP. And we of course can't jump over their head. A= nyways, if you'll follow instruction in README.md, moulin tool will fetch a= ll required meta-layers and configure Yocto for you. If you are interested in exact commit ids, you can check the YAML file used= by moulin tool: https://github.com/xen-troops/meta-xt-prod-devel-rcar/blob/master/prod-deve= l-rcar.yaml#L32 -- WBR, Volodymyr If you are not the addressee, please inform us immediately that you have re= ceived this e-mail by mistake, and delete it. We thank you for your support= . From xen-devel-bounces@lists.xenproject.org Mon May 05 07:35:53 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 07:35:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975851.1363151 (Exim 4.92) (envelope-from ) id 1uBqMU-0005Ph-31; Mon, 05 May 2025 07:35:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975851.1363151; Mon, 05 May 2025 07: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 1uBqMU-0005Pa-01; Mon, 05 May 2025 07:35:38 +0000 Received: by outflank-mailman (input) for mailman id 975851; Mon, 05 May 2025 07:35:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBqMS-0005PS-Nr for xen-devel@lists.xenproject.org; Mon, 05 May 2025 07:35:37 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 870eb97b-2983-11f0-9ffb-bf95429c2676; Mon, 05 May 2025 09:35:33 +0200 (CEST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-acbb85ce788so1056391766b.3 for ; Mon, 05 May 2025 00:35:33 -0700 (PDT) Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad189540eb8sm451666866b.173.2025.05.05.00.35.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 May 2025 00:35: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" X-Inumbo-ID: 870eb97b-2983-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746430533; x=1747035333; darn=lists.xenproject.org; h=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; bh=BSVCoi/A4Hc2vR9OKvCTewLQX3Xyonx3kmhhYYyMneg=; b=ItexaG0xYwj64v9SdvA8CRRztLWhofLaUZTAxDdgl8RxB9657JzKyvz+K+IUQppcus KQ1Q+47JjXrO4PUV0qEbQIz6kK/2VrHKZt4aQQh3tHLyv79XkhFZbcbqJzNpjhugydzZ cGg0MMzpZLSh59kF9lhKOsoFqfSxz8DZgcmH3pvnO4iMXQdd3YhnSsuHnsxbhnLioZyw vdJxR/TyGtVmOmNNVoyCVpyY6AGUsDyQqBqZqo+v9xLi0feiBTkSiNepFBXjAIjS9TTo W2qOv3ndnLdQa2oOjX+tUCO4Inmg1xoU6PoEpSz3X1XVEEurzH/1BEzBJ5oCY5DMvr0S 0AgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746430533; x=1747035333; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=BSVCoi/A4Hc2vR9OKvCTewLQX3Xyonx3kmhhYYyMneg=; b=OO1+t4TWbl9PzfGV71e8CdMejarD9gV4payFeXLh4RlKX5DM+vYvAy8Buadc5IM3aI C64iN9E70qWuHx4ZRKIvJXi2Oev1ZFASrzwRirYN2+ww86iPchOKkmBzAfqfpN6trbXj xcPBdTkiZyY/6B8ehqCV1nvX9xlgjMQ2Ov1CdPQ9XV3Z9iLuMVkZXOsWZSPhlm2NyT+f SFO+706fa9gxsqdF8ycBZL17ZLEF+b2hSubYjrFqmAMz0Mz5Aso20fOIzXi7y++MZT6e ERr5y1c+30OVKDunTJPvC4P4EXi5mvIY9iSev67UfDxpdzWpIG0DUUdI/blhKA1KRD5q tMxg== X-Gm-Message-State: AOJu0YznD/IkLvyUO6Z9W2TJHlsROtl+SVrI1+hzqrtXXC1RUuWJHflr zV4brlFEa88TeagVz5OS4yCjBCqIibzMjBRrM3Pk0DM4ZpXW4jsVtqSIlQ== X-Gm-Gg: ASbGnct6sahWUREpuI8ruxoGVRHFaEsZ+85fXImaBESwyUj28rvNZp5A3uzGt6hdH/Q vYvsvenL67mdYaJfpI5rwfqKpVeEdQqJEIHq8H6rQrn0D2dMycYyRWQgiUCs1K4OmYK9zCv/zQc nevtOUP6HICx5WoI/pL6cWIvlsEbB3TGz+owAV2pxoTiVJ0tkVkDin+pR1SdqvtC+va2rQef7MK aluZOPCkaCraJmvTuehui+/XtDEppn2Lucvy3MaRz+VooFl6InokLvZKqreSJHeHpNBiNLZEHx4 WTNBiyKdrxHBsMkqppDkUEP0mcLkbdGr1F2GnfH+HQqeXEw/p7IOclne4+eQJuNLj+UaA0nEVXI 3idk7LVHmeKroZyXl X-Google-Smtp-Source: AGHT+IE2uwLWAHEdYfHDKexOIySISZO8oTaX96/YBgX+ezNsmNBWKQKktE5qjCNA5ps1/ggYTc53pA== X-Received: by 2002:a17:907:c28f:b0:ace:f2c2:5a4 with SMTP id a640c23a62f3a-ad190654de0mr736726066b.13.1746430532146; Mon, 05 May 2025 00:35:32 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------XhSxytRE3300FoxfdHaztzYN" Message-ID: Date: Mon, 5 May 2025 09:35:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/8] xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <82f0c1d4fe25b4a52d76f3c8004e107b183af56c.1746199009.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: This is a multi-part message in MIME format. --------------XhSxytRE3300FoxfdHaztzYN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/2/25 7:55 PM, Stefano Stabellini wrote: > On Fri, 2 May 2025, Oleksii Kurochko wrote: >> Move some parts of Arm's Dom0Less code to be reused by other architectures. >> At the moment, RISC-V is going to reuse these parts. >> >> Move dom0less-build.h from the Arm-specific directory to asm-generic >> as these header is expected to be the same across acrhictectures with >> some updates: add the following declaration of construct_domU(), >> and arch_create_domUs() as there are some parts which are still >> architecture-specific. >> >> Introduce HAS_DOM0LESS to provide ability to enable generic Dom0less >> code for an architecture. >> >> Relocate the CONFIG_DOM0LESS configuration to the common with adding >> "depends on HAS_DOM0LESS" to not break builds for architectures which >> don't support CONFIG_DOM0LESS config, especically it would be useful >> to not provide stubs for construct_domU(), arch_create_domUs() >> in case of *-randconfig which may set CONFIG_DOM0LESS=y. >> >> Move is_dom0less_mode() function to the common code, as it depends on >> boot modules that are already part of the common code. >> >> Move create_domUs() function to the common code with some updates: >> - Add arch_create_domUs() to cover parsing of arch-specific features, >> for example, SVE (Scalar Vector Extension ) exists only in Arm. >> >> Signed-off-by: Oleksii Kurochko >> --- >> It was suggested to change dom0less to predefined domus or similar >> (https://lore.kernel.org/xen-devel/cd2a3644-c9c6-4e77-9491-2988703906c0@gmail.com/T/#m1d5e81e5f1faca98a3c51efe4f35af25010edbf0): >> >> I decided to go with dom0less name for now as it will require a lot of places to change, >> including CI's test, and IMO we could do in a separate patch. >> If it is necessry to do now, I'll be happy to do that in next version of the current >> patch series. > I think it is fine to use dom0less for now, it will make the code easier > to review and it is not necessary to change the name at this point. > > The patch looks good to me, except for a couple of minor suggestions I > have below. I could make them on commit. With those: > > Reviewed-by: Stefano Stabellini Thanks. I will apply the suggestions below (unless they have already been committed by the time I start preparing the new version of the patch series). ~ Oleksii > > >> --- >> Changes in v3: >> - Move changes connected to the patch "xen/arm: dom0less delay xenstore initialization" >> to common. >> Also, some necessary parts for the mentioned patches were moved >> to common (such as alloc_xenstore_evtchn(), ... ). >> Not all changes are moved, changes connected to alloc_xenstore_params() and >> construct_domu() will be moved in the following patches of this patch series. >> - Move parsing of capabilities property to common code. >> - Align parsing of "passthrough", "multiboot,device-tree" properties with staging. >> - Drop arch_xen_domctl_createdomain(). >> - Add 'select HAS_DEVICE_TREE' for config HAS_DOM0LESS. >> - Add empty lines after license in the top of newly added files. >> - s/arch_create_domus/arch_create_domUs. >> - Add footer below commit message regarding the naming of dom0less. >> --- >> Changes in v2: >> - Convert 'depends on Arm' to 'depends on HAS_DOM0LESS' for >> CONFIG_DOM0LESS_BOOT. >> - Change 'default Arm' to 'default y' for CONFIG_DOM0LESS_BOOT as there is >> dependency on HAS_DOM0LESS. >> - Introduce HAS_DOM0LESS and enable it for Arm. >> - Update the commit message. >> --- >> xen/arch/arm/Kconfig | 9 +- >> xen/arch/arm/dom0less-build.c | 371 ++++------------------ >> xen/arch/arm/include/asm/Makefile | 1 + >> xen/arch/arm/include/asm/dom0less-build.h | 34 -- >> xen/common/Kconfig | 13 + >> xen/common/device-tree/Makefile | 1 + >> xen/common/device-tree/dom0less-build.c | 283 +++++++++++++++++ >> xen/include/asm-generic/dom0less-build.h | 49 +++ >> 8 files changed, 404 insertions(+), 357 deletions(-) >> delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h >> create mode 100644 xen/common/device-tree/dom0less-build.c >> create mode 100644 xen/include/asm-generic/dom0less-build.h >> >> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig >> index da8a406f5a..d0e0a7753c 100644 >> --- a/xen/arch/arm/Kconfig >> +++ b/xen/arch/arm/Kconfig >> @@ -15,6 +15,7 @@ config ARM >> select GENERIC_UART_INIT >> select HAS_ALTERNATIVE if HAS_VMAP >> select HAS_DEVICE_TREE >> + select HAS_DOM0LESS >> select HAS_STACK_PROTECTOR >> select HAS_UBSAN >> >> @@ -120,14 +121,6 @@ config GICV2 >> Driver for the ARM Generic Interrupt Controller v2. >> If unsure, say Y >> >> -config DOM0LESS_BOOT >> - bool "Dom0less boot support" if EXPERT >> - default y >> - help >> - Dom0less boot support enables Xen to create and start domU guests during >> - Xen boot without the need of a control domain (Dom0), which could be >> - present anyway. >> - >> config GICV3 >> bool "GICv3 driver" >> depends on !NEW_VGIC >> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c >> index a356fc94fc..ef49495d4f 100644 >> --- a/xen/arch/arm/dom0less-build.c >> +++ b/xen/arch/arm/dom0less-build.c >> @@ -22,48 +22,7 @@ >> #include >> #include >> >> -#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX >> - >> -static domid_t __initdata xs_domid = DOMID_INVALID; >> -static bool __initdata need_xenstore; >> - >> -void __init set_xs_domain(struct domain *d) >> -{ >> - xs_domid = d->domain_id; >> - set_global_virq_handler(d, VIRQ_DOM_EXC); >> -} >> - >> -bool __init is_dom0less_mode(void) >> -{ >> - struct bootmodules *mods = &bootinfo.modules; >> - struct bootmodule *mod; >> - unsigned int i; >> - bool dom0found = false; >> - bool domUfound = false; >> - >> - /* Look into the bootmodules */ >> - for ( i = 0 ; i < mods->nr_mods ; i++ ) >> - { >> - mod = &mods->module[i]; >> - /* Find if dom0 and domU kernels are present */ >> - if ( mod->kind == BOOTMOD_KERNEL ) >> - { >> - if ( mod->domU == false ) >> - { >> - dom0found = true; >> - break; >> - } >> - else >> - domUfound = true; >> - } >> - } >> - >> - /* >> - * If there is no dom0 kernel but at least one domU, then we are in >> - * dom0less mode >> - */ >> - return ( !dom0found && domUfound ); >> -} >> +bool __initdata need_xenstore; >> >> #ifdef CONFIG_VGICV2 >> static int __init make_gicv2_domU_node(struct kernel_info *kinfo) >> @@ -686,25 +645,6 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) >> return -EINVAL; >> } >> >> -static int __init alloc_xenstore_evtchn(struct domain *d) >> -{ >> - evtchn_alloc_unbound_t alloc; >> - int rc; >> - >> - alloc.dom = d->domain_id; >> - alloc.remote_dom = xs_domid; >> - rc = evtchn_alloc_unbound(&alloc, 0); >> - if ( rc ) >> - { >> - printk("Failed allocating event channel for domain\n"); >> - return rc; >> - } >> - >> - d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port; >> - >> - return 0; >> -} >> - >> #define XENSTORE_PFN_OFFSET 1 >> static int __init alloc_xenstore_page(struct domain *d) >> { >> @@ -771,36 +711,6 @@ static int __init alloc_xenstore_params(struct kernel_info *kinfo) >> return rc; >> } >> >> -static void __init initialize_domU_xenstore(void) >> -{ >> - struct domain *d; >> - >> - if ( xs_domid == DOMID_INVALID ) >> - return; >> - >> - for_each_domain( d ) >> - { >> - uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN]; >> - int rc; >> - >> - if ( gfn == 0 ) >> - continue; >> - >> - if ( is_xenstore_domain(d) ) >> - continue; >> - >> - rc = alloc_xenstore_evtchn(d); >> - if ( rc < 0 ) >> - panic("%pd: Failed to allocate xenstore_evtchn\n", d); >> - >> - if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) ) >> - { >> - ASSERT(gfn < UINT32_MAX); >> - gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn); >> - } >> - } >> -} >> - >> static void __init domain_vcpu_affinity(struct domain *d, >> const struct dt_device_node *node) >> { >> @@ -906,8 +816,8 @@ static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem, >> } >> #endif /* CONFIG_ARCH_PAGING_MEMPOOL */ >> >> -static int __init construct_domU(struct domain *d, >> - const struct dt_device_node *node) >> +int __init construct_domU(struct domain *d, >> + const struct dt_device_node *node) >> { >> struct kernel_info kinfo = KERNEL_INFO_INIT; >> const char *dom0less_enhanced; >> @@ -1009,246 +919,77 @@ static int __init construct_domU(struct domain *d, >> return alloc_xenstore_params(&kinfo); >> } >> >> -void __init create_domUs(void) >> +void __init arch_create_domUs(struct dt_device_node *node, >> + struct xen_domctl_createdomain *d_cfg, >> + unsigned int flags) >> { >> - struct dt_device_node *node; >> - const char *dom0less_iommu; >> - bool iommu = false; >> - const struct dt_device_node *cpupool_node, >> - *chosen = dt_find_node_by_path("/chosen"); >> - const char *llc_colors_str = NULL; >> - >> - BUG_ON(chosen == NULL); >> - dt_for_each_child_node(chosen, node) >> - { >> - struct domain *d; >> - struct xen_domctl_createdomain d_cfg = { >> - .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE, >> - .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap, >> - /* >> - * The default of 1023 should be sufficient for guests because >> - * on ARM we don't bind physical interrupts to event channels. >> - * The only use of the evtchn port is inter-domain communications. >> - * 1023 is also the default value used in libxl. >> - */ >> - .max_evtchn_port = 1023, >> - .max_grant_frames = -1, >> - .max_maptrack_frames = -1, >> - .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version), >> - }; >> - unsigned int flags = 0U; >> - bool has_dtb = false; >> - uint32_t val; >> - int rc; >> - >> - if ( !dt_device_is_compatible(node, "xen,domain") ) >> - continue; >> - >> - if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED ) >> - panic("No more domain IDs available\n"); >> + uint32_t val; >> >> - if ( dt_property_read_u32(node, "capabilities", &val) ) >> - { >> - if ( val & ~DOMAIN_CAPS_MASK ) >> - panic("Invalid capabilities (%"PRIx32")\n", val); >> - >> - if ( val & DOMAIN_CAPS_CONTROL ) >> - flags |= CDF_privileged; >> - >> - if ( val & DOMAIN_CAPS_HARDWARE ) >> - { >> - if ( hardware_domain ) >> - panic("Only 1 hardware domain can be specified! (%pd)\n", >> - hardware_domain); >> - >> - d_cfg.max_grant_frames = gnttab_dom0_frames(); >> - d_cfg.max_evtchn_port = -1; >> - flags |= CDF_hardware; >> - iommu = true; >> - } >> - >> - if ( val & DOMAIN_CAPS_XENSTORE ) >> - { >> - if ( xs_domid != DOMID_INVALID ) >> - panic("Only 1 xenstore domain can be specified! (%u)\n", >> - xs_domid); >> + d_cfg->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; >> + d_cfg->flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap; >> >> - d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain; >> - d_cfg.max_evtchn_port = -1; >> - } >> - } >> - >> - if ( dt_find_property(node, "xen,static-mem", NULL) ) >> - { >> - if ( llc_coloring_enabled ) >> - panic("LLC coloring and static memory are incompatible\n"); >> - >> - flags |= CDF_staticmem; >> - } >> - >> - if ( dt_property_read_bool(node, "direct-map") ) >> - { >> - if ( !(flags & CDF_staticmem) ) >> - panic("direct-map is not valid for domain %s without static allocation.\n", >> - dt_node_name(node)); >> - >> - flags |= CDF_directmap; >> - } >> - >> - if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) ) >> - panic("Missing property 'cpus' for domain %s\n", >> - dt_node_name(node)); >> - >> - if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) ) >> - { >> - if ( flags & CDF_hardware ) >> - panic("Don't specify passthrough for hardware domain\n"); >> - >> - if ( !strcmp(dom0less_iommu, "enabled") ) >> - iommu = true; >> - } >> - >> - if ( (flags & CDF_hardware) && !(flags & CDF_directmap) && >> - !iommu_enabled ) >> - panic("non-direct mapped hardware domain requires iommu\n"); >> - >> - if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") ) >> - { >> - if ( flags & CDF_hardware ) >> - panic("\"multiboot,device-tree\" incompatible with hardware domain\n"); >> - >> - has_dtb = true; >> - } >> - >> - if ( iommu_enabled && (iommu || has_dtb) ) >> - d_cfg.flags |= XEN_DOMCTL_CDF_iommu; >> - >> - if ( !dt_property_read_u32(node, "nr_spis", &d_cfg.arch.nr_spis) ) >> - { >> - int vpl011_virq = GUEST_VPL011_SPI; >> - >> - d_cfg.arch.nr_spis = VGIC_DEF_NR_SPIS; >> - >> - /* >> - * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is >> - * set, in which case it'll match the hardware. >> - * >> - * Since the domain is not yet created, we can't use >> - * d->arch.vpl011.irq. So the logic to find the vIRQ has to >> - * be hardcoded. >> - * The logic here shall be consistent with the one in >> - * domain_vpl011_init(). >> - */ >> - if ( flags & CDF_directmap ) >> - { >> - vpl011_virq = serial_irq(SERHND_DTUART); >> - if ( vpl011_virq < 0 ) >> - panic("Error getting IRQ number for this serial port %d\n", >> - SERHND_DTUART); >> - } >> + if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) ) >> + { >> + int vpl011_virq = GUEST_VPL011_SPI; >> >> - /* >> - * vpl011 uses one emulated SPI. If vpl011 is requested, make >> - * sure that we allocate enough SPIs for it. >> - */ >> - if ( dt_property_read_bool(node, "vpl011") ) >> - d_cfg.arch.nr_spis = MAX(d_cfg.arch.nr_spis, >> - vpl011_virq - 32 + 1); >> - } >> - else if ( flags & CDF_hardware ) >> - panic("nr_spis cannot be specified for hardware domain\n"); >> + d_cfg->arch.nr_spis = VGIC_DEF_NR_SPIS; >> >> - /* Get the optional property domain-cpupool */ >> - cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0); >> - if ( cpupool_node ) >> + /* >> + * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is >> + * set, in which case it'll match the hardware. >> + * >> + * Since the domain is not yet created, we can't use >> + * d->arch.vpl011.irq. So the logic to find the vIRQ has to >> + * be hardcoded. >> + * The logic here shall be consistent with the one in >> + * domain_vpl011_init(). >> + */ >> + if ( flags & CDF_directmap ) >> { >> - int pool_id = btcpupools_get_domain_pool_id(cpupool_node); >> - if ( pool_id < 0 ) >> - panic("Error getting cpupool id from domain-cpupool (%d)\n", >> - pool_id); >> - d_cfg.cpupool_id = pool_id; >> + vpl011_virq = serial_irq(SERHND_DTUART); >> + if ( vpl011_virq < 0 ) >> + panic("Error getting IRQ number for this serial port %d\n", >> + SERHND_DTUART); >> } >> >> - if ( dt_property_read_u32(node, "max_grant_version", &val) ) >> - d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val); >> + /* >> + * vpl011 uses one emulated SPI. If vpl011 is requested, make >> + * sure that we allocate enough SPIs for it. >> + */ >> + if ( dt_property_read_bool(node, "vpl011") ) >> + d_cfg->arch.nr_spis = MAX(d_cfg->arch.nr_spis, >> + vpl011_virq - 32 + 1); >> + } >> + else if ( flags & CDF_hardware ) >> + panic("nr_spis cannot be specified for hardware domain\n"); >> >> - if ( dt_property_read_u32(node, "max_grant_frames", &val) ) >> - { >> - if ( val > INT32_MAX ) >> - panic("max_grant_frames (%"PRIu32") overflow\n", val); >> - d_cfg.max_grant_frames = val; >> - } >> + if ( dt_get_property(node, "sve", &val) ) >> + { >> +#ifdef CONFIG_ARM64_SVE >> + unsigned int sve_vl_bits; >> + bool ret = false; >> >> - if ( dt_property_read_u32(node, "max_maptrack_frames", &val) ) >> + if ( !val ) >> { >> - if ( val > INT32_MAX ) >> - panic("max_maptrack_frames (%"PRIu32") overflow\n", val); >> - d_cfg.max_maptrack_frames = val; >> + /* Property found with no value, means max HW VL supported */ >> + ret = sve_domctl_vl_param(-1, &sve_vl_bits); >> } >> - >> - if ( dt_get_property(node, "sve", &val) ) >> + else >> { >> -#ifdef CONFIG_ARM64_SVE >> - unsigned int sve_vl_bits; >> - bool ret = false; >> - >> - if ( !val ) >> - { >> - /* Property found with no value, means max HW VL supported */ >> - ret = sve_domctl_vl_param(-1, &sve_vl_bits); >> - } >> + if ( dt_property_read_u32(node, "sve", &val) ) >> + ret = sve_domctl_vl_param(val, &sve_vl_bits); >> else >> - { >> - if ( dt_property_read_u32(node, "sve", &val) ) >> - ret = sve_domctl_vl_param(val, &sve_vl_bits); >> - else >> - panic("Error reading 'sve' property\n"); >> - } >> + panic("Error reading 'sve' property\n"); >> + } >> >> - if ( ret ) >> - d_cfg.arch.sve_vl = sve_encode_vl(sve_vl_bits); >> - else >> - panic("SVE vector length error\n"); >> + if ( ret ) >> + d_cfg->arch.sve_vl = sve_encode_vl(sve_vl_bits); >> + else >> + panic("SVE vector length error\n"); >> #else >> - panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n"); >> + panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n"); >> #endif >> - } >> - >> - dt_property_read_string(node, "llc-colors", &llc_colors_str); >> - if ( !llc_coloring_enabled && llc_colors_str ) >> - panic("'llc-colors' found, but LLC coloring is disabled\n"); >> - >> - /* >> - * The variable max_init_domid is initialized with zero, so here it's >> - * very important to use the pre-increment operator to call >> - * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0) >> - */ >> - d = domain_create(++max_init_domid, &d_cfg, flags); >> - if ( IS_ERR(d) ) >> - panic("Error creating domain %s (rc = %ld)\n", >> - dt_node_name(node), PTR_ERR(d)); >> - >> - if ( llc_coloring_enabled && >> - (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) ) >> - panic("Error initializing LLC coloring for domain %s (rc = %d)\n", >> - dt_node_name(node), rc); >> - >> - d->is_console = true; >> - dt_device_set_used_by(node, d->domain_id); >> - >> - rc = construct_domU(d, node); >> - if ( rc ) >> - panic("Could not set up domain %s (rc = %d)\n", >> - dt_node_name(node), rc); >> - >> - if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain ) >> - set_xs_domain(d); >> } >> - >> - if ( need_xenstore && xs_domid == DOMID_INVALID ) >> - panic("xenstore requested, but xenstore domain not present\n"); >> - >> - initialize_domU_xenstore(); >> } >> >> /* >> diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile >> index 4a4036c951..831c914cce 100644 >> --- a/xen/arch/arm/include/asm/Makefile >> +++ b/xen/arch/arm/include/asm/Makefile >> @@ -1,6 +1,7 @@ >> # SPDX-License-Identifier: GPL-2.0-only >> generic-y += altp2m.h >> generic-y += device.h >> +generic-y += dom0less-build.h >> generic-y += hardirq.h >> generic-y += iocap.h >> generic-y += paging.h >> diff --git a/xen/arch/arm/include/asm/dom0less-build.h b/xen/arch/arm/include/asm/dom0less-build.h >> deleted file mode 100644 >> index b0e41a1954..0000000000 >> --- a/xen/arch/arm/include/asm/dom0less-build.h >> +++ /dev/null >> @@ -1,34 +0,0 @@ >> -/* SPDX-License-Identifier: GPL-2.0-only */ >> - >> -#ifndef __ASM_DOM0LESS_BUILD_H_ >> -#define __ASM_DOM0LESS_BUILD_H_ >> - >> -#include >> - >> -#ifdef CONFIG_DOM0LESS_BOOT >> - >> -void create_domUs(void); >> -bool is_dom0less_mode(void); >> -void set_xs_domain(struct domain *d); >> - >> -#else /* !CONFIG_DOM0LESS_BOOT */ >> - >> -static inline void create_domUs(void) {} >> -static inline bool is_dom0less_mode(void) >> -{ >> - return false; >> -} >> -static inline void set_xs_domain(struct domain *d) {} >> - >> -#endif /* CONFIG_DOM0LESS_BOOT */ >> - >> -#endif /* __ASM_DOM0LESS_BUILD_H_ */ >> - >> -/* >> - * Local variables: >> - * mode: C >> - * c-file-style: "BSD" >> - * c-basic-offset: 4 >> - * indent-tabs-mode: nil >> - * End: >> - */ >> diff --git a/xen/common/Kconfig b/xen/common/Kconfig >> index be28060716..be38abf9e1 100644 >> --- a/xen/common/Kconfig >> +++ b/xen/common/Kconfig >> @@ -12,6 +12,15 @@ config CORE_PARKING >> bool >> depends on NR_CPUS > 1 >> >> +config DOM0LESS_BOOT >> + bool "Dom0less boot support" if EXPERT >> + depends on HAS_DOM0LESS > I think it is better to also add here: > > depends on HAS_DEVICE_TREE > > and ... > > >> + default y >> + help >> + Dom0less boot support enables Xen to create and start domU guests during >> + Xen boot without the need of a control domain (Dom0), which could be >> + present anyway. >> + >> config GRANT_TABLE >> bool "Grant table support" if EXPERT >> default y >> @@ -74,6 +83,10 @@ config HAS_DEVICE_TREE >> bool >> select LIBFDT >> >> +config HAS_DOM0LESS >> + bool >> + select HAS_DEVICE_TREE > ... remove select HAS_DEVICE_TREE from here. To reduce the dependencies > complexity. > > >> config HAS_DIT # Data Independent Timing >> bool >> >> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile >> index 7c549be38a..f3dafc9b81 100644 >> --- a/xen/common/device-tree/Makefile >> +++ b/xen/common/device-tree/Makefile >> @@ -1,5 +1,6 @@ >> obj-y += bootfdt.init.o >> obj-y += bootinfo.init.o >> obj-y += device-tree.o >> +obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o >> obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o >> obj-y += intc.o >> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c >> new file mode 100644 >> index 0000000000..a01a8b6b1a >> --- /dev/null >> +++ b/xen/common/device-tree/dom0less-build.c >> @@ -0,0 +1,283 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> + >> +static domid_t __initdata xs_domid = DOMID_INVALID; >> + >> +void __init set_xs_domain(struct domain *d) >> +{ >> + xs_domid = d->domain_id; >> + set_global_virq_handler(d, VIRQ_DOM_EXC); >> +} >> + >> +bool __init is_dom0less_mode(void) >> +{ >> + struct bootmodules *mods = &bootinfo.modules; >> + struct bootmodule *mod; >> + unsigned int i; >> + bool dom0found = false; >> + bool domUfound = false; >> + >> + /* Look into the bootmodules */ >> + for ( i = 0 ; i < mods->nr_mods ; i++ ) >> + { >> + mod = &mods->module[i]; >> + /* Find if dom0 and domU kernels are present */ >> + if ( mod->kind == BOOTMOD_KERNEL ) >> + { >> + if ( mod->domU == false ) >> + { >> + dom0found = true; >> + break; >> + } >> + else >> + domUfound = true; >> + } >> + } >> + >> + /* >> + * If there is no dom0 kernel but at least one domU, then we are in >> + * dom0less mode >> + */ >> + return ( !dom0found && domUfound ); >> +} >> + >> +static int __init alloc_xenstore_evtchn(struct domain *d) >> +{ >> + evtchn_alloc_unbound_t alloc; >> + int rc; >> + >> + alloc.dom = d->domain_id; >> + alloc.remote_dom = xs_domid; >> + rc = evtchn_alloc_unbound(&alloc, 0); >> + if ( rc ) >> + { >> + printk("Failed allocating event channel for domain\n"); >> + return rc; >> + } >> + >> + d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port; >> + >> + return 0; >> +} >> + >> +static void __init initialize_domU_xenstore(void) >> +{ >> + struct domain *d; >> + >> + if ( xs_domid == DOMID_INVALID ) >> + return; >> + >> + for_each_domain( d ) >> + { >> + uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN]; >> + int rc; >> + >> + if ( gfn == 0 ) >> + continue; >> + >> + if ( is_xenstore_domain(d) ) >> + continue; >> + >> + rc = alloc_xenstore_evtchn(d); >> + if ( rc < 0 ) >> + panic("%pd: Failed to allocate xenstore_evtchn\n", d); >> + >> + if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) ) >> + { >> + ASSERT(gfn < UINT32_MAX); >> + gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn); >> + } >> + } >> +} >> + >> +void __init create_domUs(void) >> +{ >> + struct dt_device_node *node; >> + const char *dom0less_iommu; >> + bool iommu = false; >> + const struct dt_device_node *cpupool_node, >> + *chosen = dt_find_node_by_path("/chosen"); >> + const char *llc_colors_str = NULL; >> + >> + BUG_ON(chosen == NULL); >> + dt_for_each_child_node(chosen, node) >> + { >> + struct domain *d; >> + struct xen_domctl_createdomain d_cfg = {0}; >> + unsigned int flags = 0U; >> + bool has_dtb = false; >> + uint32_t val; >> + int rc; >> + >> + if ( !dt_device_is_compatible(node, "xen,domain") ) >> + continue; >> + >> + if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED ) >> + panic("No more domain IDs available\n"); >> + >> + d_cfg.max_evtchn_port = 1023; >> + d_cfg.max_grant_frames = -1; >> + d_cfg.max_maptrack_frames = -1; >> + d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version); >> + >> + if ( dt_property_read_u32(node, "capabilities", &val) ) >> + { >> + if ( val & ~DOMAIN_CAPS_MASK ) >> + panic("Invalid capabilities (%"PRIx32")\n", val); >> + >> + if ( val & DOMAIN_CAPS_CONTROL ) >> + flags |= CDF_privileged; >> + >> + if ( val & DOMAIN_CAPS_HARDWARE ) >> + { >> + if ( hardware_domain ) >> + panic("Only 1 hardware domain can be specified! (%pd)\n", >> + hardware_domain); >> + >> + d_cfg.max_grant_frames = gnttab_dom0_frames(); >> + d_cfg.max_evtchn_port = -1; >> + flags |= CDF_hardware; >> + iommu = true; >> + } >> + >> + if ( val & DOMAIN_CAPS_XENSTORE ) >> + { >> + if ( xs_domid != DOMID_INVALID ) >> + panic("Only 1 xenstore domain can be specified! (%u)\n", >> + xs_domid); >> + >> + d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain; >> + d_cfg.max_evtchn_port = -1; >> + } >> + } >> + >> + if ( dt_find_property(node, "xen,static-mem", NULL) ) >> + { >> + if ( llc_coloring_enabled ) >> + panic("LLC coloring and static memory are incompatible\n"); >> + >> + flags |= CDF_staticmem; >> + } >> + >> + if ( dt_property_read_bool(node, "direct-map") ) >> + { >> + if ( !(flags & CDF_staticmem) ) >> + panic("direct-map is not valid for domain %s without static allocation.\n", >> + dt_node_name(node)); >> + >> + flags |= CDF_directmap; >> + } >> + >> + if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) ) >> + panic("Missing property 'cpus' for domain %s\n", >> + dt_node_name(node)); >> + >> + if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) ) >> + { >> + if ( flags & CDF_hardware ) >> + panic("Don't specify passthrough for hardware domain\n"); >> + >> + if ( !strcmp(dom0less_iommu, "enabled") ) >> + iommu = true; >> + } >> + >> + if ( (flags & CDF_hardware) && !(flags & CDF_directmap) && >> + !iommu_enabled ) >> + panic("non-direct mapped hardware domain requires iommu\n"); >> + >> + if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") ) >> + { >> + if ( flags & CDF_hardware ) >> + panic("\"multiboot,device-tree\" incompatible with hardware domain\n"); >> + >> + has_dtb = true; >> + } >> + >> + if ( iommu_enabled && (iommu || has_dtb) ) >> + d_cfg.flags |= XEN_DOMCTL_CDF_iommu; >> + >> + /* Get the optional property domain-cpupool */ >> + cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0); >> + if ( cpupool_node ) >> + { >> + int pool_id = btcpupools_get_domain_pool_id(cpupool_node); >> + if ( pool_id < 0 ) >> + panic("Error getting cpupool id from domain-cpupool (%d)\n", >> + pool_id); >> + d_cfg.cpupool_id = pool_id; >> + } >> + >> + if ( dt_property_read_u32(node, "max_grant_version", &val) ) >> + d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val); >> + >> + if ( dt_property_read_u32(node, "max_grant_frames", &val) ) >> + { >> + if ( val > INT32_MAX ) >> + panic("max_grant_frames (%"PRIu32") overflow\n", val); >> + d_cfg.max_grant_frames = val; >> + } >> + >> + if ( dt_property_read_u32(node, "max_maptrack_frames", &val) ) >> + { >> + if ( val > INT32_MAX ) >> + panic("max_maptrack_frames (%"PRIu32") overflow\n", val); >> + d_cfg.max_maptrack_frames = val; >> + } >> + >> + dt_property_read_string(node, "llc-colors", &llc_colors_str); >> + if ( !llc_coloring_enabled && llc_colors_str ) >> + panic("'llc-colors' found, but LLC coloring is disabled\n"); >> + >> + arch_create_domUs(node, &d_cfg, flags); >> + >> + /* >> + * The variable max_init_domid is initialized with zero, so here it's >> + * very important to use the pre-increment operator to call >> + * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0) >> + */ >> + d = domain_create(++max_init_domid, &d_cfg, flags); >> + if ( IS_ERR(d) ) >> + panic("Error creating domain %s (rc = %ld)\n", >> + dt_node_name(node), PTR_ERR(d)); >> + >> + if ( llc_coloring_enabled && >> + (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) ) >> + panic("Error initializing LLC coloring for domain %s (rc = %d)\n", >> + dt_node_name(node), rc); >> + >> + d->is_console = true; >> + dt_device_set_used_by(node, d->domain_id); >> + >> + rc = construct_domU(d, node); >> + if ( rc ) >> + panic("Could not set up domain %s (rc = %d)\n", >> + dt_node_name(node), rc); >> + >> + if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain ) >> + set_xs_domain(d); >> + } >> + >> + if ( need_xenstore && xs_domid == DOMID_INVALID ) >> + panic("xenstore requested, but xenstore domain not present\n"); >> + >> + initialize_domU_xenstore(); >> +} >> diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h >> new file mode 100644 >> index 0000000000..5655571a66 >> --- /dev/null >> +++ b/xen/include/asm-generic/dom0less-build.h >> @@ -0,0 +1,49 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> + >> +#ifndef __ASM_GENERIC_DOM0LESS_BUILD_H__ >> +#define __ASM_GENERIC_DOM0LESS_BUILD_H__ >> + >> +#include >> + >> +#ifdef CONFIG_DOM0LESS_BOOT >> + >> +#include >> + >> +struct domain; > This declaration needs to be out of the #ifdef CONFIG_DOM0LESS_BOOT > because... > > >> +struct dt_device_node; >> + >> +/* TODO: remove both when construct_domU() will be moved to common. */ >> +#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX >> +extern bool need_xenstore; >> + >> +void create_domUs(void); >> +bool is_dom0less_mode(void); >> +void set_xs_domain(struct domain *d); >> + >> +int construct_domU(struct domain *d, const struct dt_device_node *node); >> + >> +void arch_create_domUs(struct dt_device_node *node, >> + struct xen_domctl_createdomain *d_cfg, >> + unsigned int flags); >> + >> +#else /* !CONFIG_DOM0LESS_BOOT */ >> + >> +static inline void create_domUs(void) {} >> +static inline bool is_dom0less_mode(void) >> +{ >> + return false; >> +} >> +static inline void set_xs_domain(struct domain *d) {} > ... of this usage of struct domain *d. > > >> +#endif /* CONFIG_DOM0LESS_BOOT */ >> + >> +#endif /* __ASM_GENERIC_DOM0LESS_BUILD_H__ */ >> + >> +/* >> + * Local variables: >> + * mode: C >> + * c-file-style: "BSD" >> + * c-basic-offset: 4 >> + * indent-tabs-mode: nil >> + * End: >> + */ >> -- >> 2.49.0 >> --------------XhSxytRE3300FoxfdHaztzYN Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 5/2/25 7:55 PM, Stefano Stabellini wrote:
On Fri, 2 May 2025, Oleksii Kurochko wrote:

Move some parts of Arm's Dom0Less code to be reused by other architectures.
At the moment, RISC-V is going to reuse these parts.

Move dom0less-build.h from the Arm-specific directory to asm-generic
as these header is expected to be the same across acrhictectures with
some updates: add the following declaration of construct_domU(),
and arch_create_domUs() as there are some parts which are still
architecture-specific.

Introduce HAS_DOM0LESS to provide ability to enable generic Dom0less
code for an architecture.

Relocate the CONFIG_DOM0LESS configuration to the common with adding
"depends on HAS_DOM0LESS" to not break builds for architectures which
don't support CONFIG_DOM0LESS config, especically it would be useful
to not provide stubs for  construct_domU(), arch_create_domUs()
in case of *-randconfig which may set CONFIG_DOM0LESS=y.

Move is_dom0less_mode() function to the common code, as it depends on
boot modules that are already part of the common code.

Move create_domUs() function to the common code with some updates:
- Add arch_create_domUs() to cover parsing of arch-specific features,
  for example, SVE (Scalar Vector Extension ) exists only in Arm.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
It was suggested to change dom0less to predefined domus or similar
(https://lore.kernel.org/xen-devel/cd2a3644-c9c6-4e77-9491-2988703906c0@gmail.com/T/#m1d5e81e5f1faca98a3c51efe4f35af25010edbf0):

I decided to go with dom0less name for now as it will require a lot of places to change,
including CI's test, and IMO we could do in a separate patch.
If it is necessry to do now, I'll be happy to do that in next version of the current
patch series.

I think it is fine to use dom0less for now, it will make the code easier
to review and it is not necessary to change the name at this point.

The patch looks good to me, except for a couple of minor suggestions I
have below. I could make them on commit. With those:

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Thanks.

I will apply the suggestions below (unless they have already been committed by the time I start preparing the new version of the patch series).

~ Oleksii




---
Changes in v3:
 - Move changes connected to the patch "xen/arm: dom0less delay xenstore initialization"
   to common.
   Also, some necessary parts for the mentioned patches were moved
   to common (such as alloc_xenstore_evtchn(), ... ).
   Not all changes are moved, changes connected to alloc_xenstore_params() and
   construct_domu() will be moved in the following patches of this patch series.
 - Move parsing of capabilities property to common code.
 - Align parsing of "passthrough", "multiboot,device-tree" properties with staging.
 - Drop arch_xen_domctl_createdomain().
 - Add 'select HAS_DEVICE_TREE' for config HAS_DOM0LESS.
 - Add empty lines after license in the top of newly added files.
 - s/arch_create_domus/arch_create_domUs.
 - Add footer below commit message regarding the naming of dom0less.
---
Changes in v2:
 - Convert 'depends on Arm' to 'depends on HAS_DOM0LESS' for
   CONFIG_DOM0LESS_BOOT.
 - Change 'default Arm' to 'default y' for CONFIG_DOM0LESS_BOOT as there is
   dependency on HAS_DOM0LESS.
 - Introduce HAS_DOM0LESS and enable it for Arm.
 - Update the commit message.
---
 xen/arch/arm/Kconfig                      |   9 +-
 xen/arch/arm/dom0less-build.c             | 371 ++++------------------
 xen/arch/arm/include/asm/Makefile         |   1 +
 xen/arch/arm/include/asm/dom0less-build.h |  34 --
 xen/common/Kconfig                        |  13 +
 xen/common/device-tree/Makefile           |   1 +
 xen/common/device-tree/dom0less-build.c   | 283 +++++++++++++++++
 xen/include/asm-generic/dom0less-build.h  |  49 +++
 8 files changed, 404 insertions(+), 357 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h
 create mode 100644 xen/common/device-tree/dom0less-build.c
 create mode 100644 xen/include/asm-generic/dom0less-build.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index da8a406f5a..d0e0a7753c 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -15,6 +15,7 @@ config ARM
 	select GENERIC_UART_INIT
 	select HAS_ALTERNATIVE if HAS_VMAP
 	select HAS_DEVICE_TREE
+	select HAS_DOM0LESS
 	select HAS_STACK_PROTECTOR
 	select HAS_UBSAN
 
@@ -120,14 +121,6 @@ config GICV2
 	  Driver for the ARM Generic Interrupt Controller v2.
 	  If unsure, say Y
 
-config DOM0LESS_BOOT
-	bool "Dom0less boot support" if EXPERT
-	default y
-	help
-	  Dom0less boot support enables Xen to create and start domU guests during
-	  Xen boot without the need of a control domain (Dom0), which could be
-	  present anyway.
-
 config GICV3
 	bool "GICv3 driver"
 	depends on !NEW_VGIC
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a356fc94fc..ef49495d4f 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -22,48 +22,7 @@
 #include <asm/static-memory.h>
 #include <asm/static-shmem.h>
 
-#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
-
-static domid_t __initdata xs_domid = DOMID_INVALID;
-static bool __initdata need_xenstore;
-
-void __init set_xs_domain(struct domain *d)
-{
-    xs_domid = d->domain_id;
-    set_global_virq_handler(d, VIRQ_DOM_EXC);
-}
-
-bool __init is_dom0less_mode(void)
-{
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
-    unsigned int i;
-    bool dom0found = false;
-    bool domUfound = false;
-
-    /* Look into the bootmodules */
-    for ( i = 0 ; i < mods->nr_mods ; i++ )
-    {
-        mod = &mods->module[i];
-        /* Find if dom0 and domU kernels are present */
-        if ( mod->kind == BOOTMOD_KERNEL )
-        {
-            if ( mod->domU == false )
-            {
-                dom0found = true;
-                break;
-            }
-            else
-                domUfound = true;
-        }
-    }
-
-    /*
-     * If there is no dom0 kernel but at least one domU, then we are in
-     * dom0less mode
-     */
-    return ( !dom0found && domUfound );
-}
+bool __initdata need_xenstore;
 
 #ifdef CONFIG_VGICV2
 static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
@@ -686,25 +645,6 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     return -EINVAL;
 }
 
-static int __init alloc_xenstore_evtchn(struct domain *d)
-{
-    evtchn_alloc_unbound_t alloc;
-    int rc;
-
-    alloc.dom = d->domain_id;
-    alloc.remote_dom = xs_domid;
-    rc = evtchn_alloc_unbound(&alloc, 0);
-    if ( rc )
-    {
-        printk("Failed allocating event channel for domain\n");
-        return rc;
-    }
-
-    d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port;
-
-    return 0;
-}
-
 #define XENSTORE_PFN_OFFSET 1
 static int __init alloc_xenstore_page(struct domain *d)
 {
@@ -771,36 +711,6 @@ static int __init alloc_xenstore_params(struct kernel_info *kinfo)
     return rc;
 }
 
-static void __init initialize_domU_xenstore(void)
-{
-    struct domain *d;
-
-    if ( xs_domid == DOMID_INVALID )
-        return;
-
-    for_each_domain( d )
-    {
-        uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN];
-        int rc;
-
-        if ( gfn == 0 )
-            continue;
-
-        if ( is_xenstore_domain(d) )
-            continue;
-
-        rc = alloc_xenstore_evtchn(d);
-        if ( rc < 0 )
-            panic("%pd: Failed to allocate xenstore_evtchn\n", d);
-
-        if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) )
-        {
-            ASSERT(gfn < UINT32_MAX);
-            gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn);
-        }
-    }
-}
-
 static void __init domain_vcpu_affinity(struct domain *d,
                                         const struct dt_device_node *node)
 {
@@ -906,8 +816,8 @@ static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
 }
 #endif /* CONFIG_ARCH_PAGING_MEMPOOL */
 
-static int __init construct_domU(struct domain *d,
-                                 const struct dt_device_node *node)
+int __init construct_domU(struct domain *d,
+                          const struct dt_device_node *node)
 {
     struct kernel_info kinfo = KERNEL_INFO_INIT;
     const char *dom0less_enhanced;
@@ -1009,246 +919,77 @@ static int __init construct_domU(struct domain *d,
     return alloc_xenstore_params(&kinfo);
 }
 
-void __init create_domUs(void)
+void __init arch_create_domUs(struct dt_device_node *node,
+                       struct xen_domctl_createdomain *d_cfg,
+                       unsigned int flags)
 {
-    struct dt_device_node *node;
-    const char *dom0less_iommu;
-    bool iommu = false;
-    const struct dt_device_node *cpupool_node,
-                                *chosen = dt_find_node_by_path("/chosen");
-    const char *llc_colors_str = NULL;
-
-    BUG_ON(chosen == NULL);
-    dt_for_each_child_node(chosen, node)
-    {
-        struct domain *d;
-        struct xen_domctl_createdomain d_cfg = {
-            .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
-            .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
-            /*
-             * The default of 1023 should be sufficient for guests because
-             * on ARM we don't bind physical interrupts to event channels.
-             * The only use of the evtchn port is inter-domain communications.
-             * 1023 is also the default value used in libxl.
-             */
-            .max_evtchn_port = 1023,
-            .max_grant_frames = -1,
-            .max_maptrack_frames = -1,
-            .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
-        };
-        unsigned int flags = 0U;
-        bool has_dtb = false;
-        uint32_t val;
-        int rc;
-
-        if ( !dt_device_is_compatible(node, "xen,domain") )
-            continue;
-
-        if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
-            panic("No more domain IDs available\n");
+    uint32_t val;
 
-        if ( dt_property_read_u32(node, "capabilities", &val) )
-        {
-            if ( val & ~DOMAIN_CAPS_MASK )
-                panic("Invalid capabilities (%"PRIx32")\n", val);
-
-            if ( val & DOMAIN_CAPS_CONTROL )
-                flags |= CDF_privileged;
-
-            if ( val & DOMAIN_CAPS_HARDWARE )
-            {
-                if ( hardware_domain )
-                    panic("Only 1 hardware domain can be specified! (%pd)\n",
-                           hardware_domain);
-
-                d_cfg.max_grant_frames = gnttab_dom0_frames();
-                d_cfg.max_evtchn_port = -1;
-                flags |= CDF_hardware;
-                iommu = true;
-            }
-
-            if ( val & DOMAIN_CAPS_XENSTORE )
-            {
-                if ( xs_domid != DOMID_INVALID )
-                    panic("Only 1 xenstore domain can be specified! (%u)\n",
-                          xs_domid);
+    d_cfg->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
+    d_cfg->flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap;
 
-                d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain;
-                d_cfg.max_evtchn_port = -1;
-            }
-        }
-
-        if ( dt_find_property(node, "xen,static-mem", NULL) )
-        {
-            if ( llc_coloring_enabled )
-                panic("LLC coloring and static memory are incompatible\n");
-
-            flags |= CDF_staticmem;
-        }
-
-        if ( dt_property_read_bool(node, "direct-map") )
-        {
-            if ( !(flags & CDF_staticmem) )
-                panic("direct-map is not valid for domain %s without static allocation.\n",
-                      dt_node_name(node));
-
-            flags |= CDF_directmap;
-        }
-
-        if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) )
-            panic("Missing property 'cpus' for domain %s\n",
-                  dt_node_name(node));
-
-        if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) )
-        {
-            if ( flags & CDF_hardware )
-                panic("Don't specify passthrough for hardware domain\n");
-
-            if ( !strcmp(dom0less_iommu, "enabled") )
-                iommu = true;
-        }
-
-        if ( (flags & CDF_hardware) && !(flags & CDF_directmap) &&
-             !iommu_enabled )
-            panic("non-direct mapped hardware domain requires iommu\n");
-
-        if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") )
-        {
-            if ( flags & CDF_hardware )
-                panic("\"multiboot,device-tree\" incompatible with hardware domain\n");
-
-            has_dtb = true;
-        }
-
-        if ( iommu_enabled && (iommu || has_dtb) )
-            d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
-
-        if ( !dt_property_read_u32(node, "nr_spis", &d_cfg.arch.nr_spis) )
-        {
-            int vpl011_virq = GUEST_VPL011_SPI;
-
-            d_cfg.arch.nr_spis = VGIC_DEF_NR_SPIS;
-
-            /*
-             * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
-             * set, in which case it'll match the hardware.
-             *
-             * Since the domain is not yet created, we can't use
-             * d->arch.vpl011.irq. So the logic to find the vIRQ has to
-             * be hardcoded.
-             * The logic here shall be consistent with the one in
-             * domain_vpl011_init().
-             */
-            if ( flags & CDF_directmap )
-            {
-                vpl011_virq = serial_irq(SERHND_DTUART);
-                if ( vpl011_virq < 0 )
-                    panic("Error getting IRQ number for this serial port %d\n",
-                          SERHND_DTUART);
-            }
+    if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) )
+    {
+        int vpl011_virq = GUEST_VPL011_SPI;
 
-            /*
-             * vpl011 uses one emulated SPI. If vpl011 is requested, make
-             * sure that we allocate enough SPIs for it.
-             */
-            if ( dt_property_read_bool(node, "vpl011") )
-                d_cfg.arch.nr_spis = MAX(d_cfg.arch.nr_spis,
-                                         vpl011_virq - 32 + 1);
-        }
-        else if ( flags & CDF_hardware )
-            panic("nr_spis cannot be specified for hardware domain\n");
+        d_cfg->arch.nr_spis = VGIC_DEF_NR_SPIS;
 
-        /* Get the optional property domain-cpupool */
-        cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
-        if ( cpupool_node )
+        /*
+         * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
+         * set, in which case it'll match the hardware.
+         *
+         * Since the domain is not yet created, we can't use
+         * d->arch.vpl011.irq. So the logic to find the vIRQ has to
+         * be hardcoded.
+         * The logic here shall be consistent with the one in
+         * domain_vpl011_init().
+         */
+        if ( flags & CDF_directmap )
         {
-            int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
-            if ( pool_id < 0 )
-                panic("Error getting cpupool id from domain-cpupool (%d)\n",
-                      pool_id);
-            d_cfg.cpupool_id = pool_id;
+            vpl011_virq = serial_irq(SERHND_DTUART);
+            if ( vpl011_virq < 0 )
+                panic("Error getting IRQ number for this serial port %d\n",
+                        SERHND_DTUART);
         }
 
-        if ( dt_property_read_u32(node, "max_grant_version", &val) )
-            d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val);
+        /*
+            * vpl011 uses one emulated SPI. If vpl011 is requested, make
+            * sure that we allocate enough SPIs for it.
+            */
+        if ( dt_property_read_bool(node, "vpl011") )
+            d_cfg->arch.nr_spis = MAX(d_cfg->arch.nr_spis,
+                                      vpl011_virq - 32 + 1);
+    }
+    else if ( flags & CDF_hardware )
+        panic("nr_spis cannot be specified for hardware domain\n");
 
-        if ( dt_property_read_u32(node, "max_grant_frames", &val) )
-        {
-            if ( val > INT32_MAX )
-                panic("max_grant_frames (%"PRIu32") overflow\n", val);
-            d_cfg.max_grant_frames = val;
-        }
+    if ( dt_get_property(node, "sve", &val) )
+    {
+#ifdef CONFIG_ARM64_SVE
+        unsigned int sve_vl_bits;
+        bool ret = false;
 
-        if ( dt_property_read_u32(node, "max_maptrack_frames", &val) )
+        if ( !val )
         {
-            if ( val > INT32_MAX )
-                panic("max_maptrack_frames (%"PRIu32") overflow\n", val);
-            d_cfg.max_maptrack_frames = val;
+            /* Property found with no value, means max HW VL supported */
+            ret = sve_domctl_vl_param(-1, &sve_vl_bits);
         }
-
-        if ( dt_get_property(node, "sve", &val) )
+        else
         {
-#ifdef CONFIG_ARM64_SVE
-            unsigned int sve_vl_bits;
-            bool ret = false;
-
-            if ( !val )
-            {
-                /* Property found with no value, means max HW VL supported */
-                ret = sve_domctl_vl_param(-1, &sve_vl_bits);
-            }
+            if ( dt_property_read_u32(node, "sve", &val) )
+                ret = sve_domctl_vl_param(val, &sve_vl_bits);
             else
-            {
-                if ( dt_property_read_u32(node, "sve", &val) )
-                    ret = sve_domctl_vl_param(val, &sve_vl_bits);
-                else
-                    panic("Error reading 'sve' property\n");
-            }
+                panic("Error reading 'sve' property\n");
+        }
 
-            if ( ret )
-                d_cfg.arch.sve_vl = sve_encode_vl(sve_vl_bits);
-            else
-                panic("SVE vector length error\n");
+        if ( ret )
+            d_cfg->arch.sve_vl = sve_encode_vl(sve_vl_bits);
+        else
+            panic("SVE vector length error\n");
 #else
-            panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
+        panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
 #endif
-        }
-
-        dt_property_read_string(node, "llc-colors", &llc_colors_str);
-        if ( !llc_coloring_enabled && llc_colors_str )
-            panic("'llc-colors' found, but LLC coloring is disabled\n");
-
-        /*
-         * The variable max_init_domid is initialized with zero, so here it's
-         * very important to use the pre-increment operator to call
-         * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
-         */
-        d = domain_create(++max_init_domid, &d_cfg, flags);
-        if ( IS_ERR(d) )
-            panic("Error creating domain %s (rc = %ld)\n",
-                  dt_node_name(node), PTR_ERR(d));
-
-        if ( llc_coloring_enabled &&
-             (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) )
-            panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
-                  dt_node_name(node), rc);
-
-        d->is_console = true;
-        dt_device_set_used_by(node, d->domain_id);
-
-        rc = construct_domU(d, node);
-        if ( rc )
-            panic("Could not set up domain %s (rc = %d)\n",
-                  dt_node_name(node), rc);
-
-        if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain )
-            set_xs_domain(d);
     }
-
-    if ( need_xenstore && xs_domid == DOMID_INVALID )
-        panic("xenstore requested, but xenstore domain not present\n");
-
-    initialize_domU_xenstore();
 }
 
 /*
diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile
index 4a4036c951..831c914cce 100644
--- a/xen/arch/arm/include/asm/Makefile
+++ b/xen/arch/arm/include/asm/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 generic-y += altp2m.h
 generic-y += device.h
+generic-y += dom0less-build.h
 generic-y += hardirq.h
 generic-y += iocap.h
 generic-y += paging.h
diff --git a/xen/arch/arm/include/asm/dom0less-build.h b/xen/arch/arm/include/asm/dom0less-build.h
deleted file mode 100644
index b0e41a1954..0000000000
--- a/xen/arch/arm/include/asm/dom0less-build.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-
-#ifndef __ASM_DOM0LESS_BUILD_H_
-#define __ASM_DOM0LESS_BUILD_H_
-
-#include <xen/stdbool.h>
-
-#ifdef CONFIG_DOM0LESS_BOOT
-
-void create_domUs(void);
-bool is_dom0less_mode(void);
-void set_xs_domain(struct domain *d);
-
-#else /* !CONFIG_DOM0LESS_BOOT */
-
-static inline void create_domUs(void) {}
-static inline bool is_dom0less_mode(void)
-{
-    return false;
-}
-static inline void set_xs_domain(struct domain *d) {}
-
-#endif /* CONFIG_DOM0LESS_BOOT */
-
-#endif /* __ASM_DOM0LESS_BUILD_H_ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index be28060716..be38abf9e1 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -12,6 +12,15 @@ config CORE_PARKING
 	bool
 	depends on NR_CPUS > 1
 
+config DOM0LESS_BOOT
+	bool "Dom0less boot support" if EXPERT
+	depends on HAS_DOM0LESS

I think it is better to also add here:

  depends on HAS_DEVICE_TREE

and ...



+	default y
+	help
+	  Dom0less boot support enables Xen to create and start domU guests during
+	  Xen boot without the need of a control domain (Dom0), which could be
+	  present anyway.
+
 config GRANT_TABLE
 	bool "Grant table support" if EXPERT
 	default y
@@ -74,6 +83,10 @@ config HAS_DEVICE_TREE
 	bool
 	select LIBFDT
 
+config HAS_DOM0LESS
+	bool
+	select HAS_DEVICE_TREE

... remove select HAS_DEVICE_TREE from here. To reduce the dependencies
complexity.



 config HAS_DIT # Data Independent Timing
 	bool
 
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 7c549be38a..f3dafc9b81 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,5 +1,6 @@
 obj-y += bootfdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
+obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
new file mode 100644
index 0000000000..a01a8b6b1a
--- /dev/null
+++ b/xen/common/device-tree/dom0less-build.c
@@ -0,0 +1,283 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include <xen/bootfdt.h>
+#include <xen/device_tree.h>
+#include <xen/domain.h>
+#include <xen/err.h>
+#include <xen/event.h>
+#include <xen/grant_table.h>
+#include <xen/init.h>
+#include <xen/iommu.h>
+#include <xen/llc-coloring.h>
+#include <xen/sched.h>
+#include <xen/stdbool.h>
+#include <xen/types.h>
+
+#include <public/bootfdt.h>
+#include <public/domctl.h>
+#include <public/event_channel.h>
+
+#include <asm/dom0less-build.h>
+#include <asm/setup.h>
+
+static domid_t __initdata xs_domid = DOMID_INVALID;
+
+void __init set_xs_domain(struct domain *d)
+{
+    xs_domid = d->domain_id;
+    set_global_virq_handler(d, VIRQ_DOM_EXC);
+}
+
+bool __init is_dom0less_mode(void)
+{
+    struct bootmodules *mods = &bootinfo.modules;
+    struct bootmodule *mod;
+    unsigned int i;
+    bool dom0found = false;
+    bool domUfound = false;
+
+    /* Look into the bootmodules */
+    for ( i = 0 ; i < mods->nr_mods ; i++ )
+    {
+        mod = &mods->module[i];
+        /* Find if dom0 and domU kernels are present */
+        if ( mod->kind == BOOTMOD_KERNEL )
+        {
+            if ( mod->domU == false )
+            {
+                dom0found = true;
+                break;
+            }
+            else
+                domUfound = true;
+        }
+    }
+
+    /*
+     * If there is no dom0 kernel but at least one domU, then we are in
+     * dom0less mode
+     */
+    return ( !dom0found && domUfound );
+}
+
+static int __init alloc_xenstore_evtchn(struct domain *d)
+{
+    evtchn_alloc_unbound_t alloc;
+    int rc;
+
+    alloc.dom = d->domain_id;
+    alloc.remote_dom = xs_domid;
+    rc = evtchn_alloc_unbound(&alloc, 0);
+    if ( rc )
+    {
+        printk("Failed allocating event channel for domain\n");
+        return rc;
+    }
+
+    d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port;
+
+    return 0;
+}
+
+static void __init initialize_domU_xenstore(void)
+{
+    struct domain *d;
+
+    if ( xs_domid == DOMID_INVALID )
+        return;
+
+    for_each_domain( d )
+    {
+        uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN];
+        int rc;
+
+        if ( gfn == 0 )
+            continue;
+
+        if ( is_xenstore_domain(d) )
+            continue;
+
+        rc = alloc_xenstore_evtchn(d);
+        if ( rc < 0 )
+            panic("%pd: Failed to allocate xenstore_evtchn\n", d);
+
+        if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) )
+        {
+            ASSERT(gfn < UINT32_MAX);
+            gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn);
+        }
+    }
+}
+
+void __init create_domUs(void)
+{
+    struct dt_device_node *node;
+    const char *dom0less_iommu;
+    bool iommu = false;
+    const struct dt_device_node *cpupool_node,
+                                *chosen = dt_find_node_by_path("/chosen");
+    const char *llc_colors_str = NULL;
+
+    BUG_ON(chosen == NULL);
+    dt_for_each_child_node(chosen, node)
+    {
+        struct domain *d;
+        struct xen_domctl_createdomain d_cfg = {0};
+        unsigned int flags = 0U;
+        bool has_dtb = false;
+        uint32_t val;
+        int rc;
+
+        if ( !dt_device_is_compatible(node, "xen,domain") )
+            continue;
+
+        if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
+            panic("No more domain IDs available\n");
+
+        d_cfg.max_evtchn_port = 1023;
+        d_cfg.max_grant_frames = -1;
+        d_cfg.max_maptrack_frames = -1;
+        d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version);
+
+        if ( dt_property_read_u32(node, "capabilities", &val) )
+        {
+            if ( val & ~DOMAIN_CAPS_MASK )
+                panic("Invalid capabilities (%"PRIx32")\n", val);
+
+            if ( val & DOMAIN_CAPS_CONTROL )
+                flags |= CDF_privileged;
+
+            if ( val & DOMAIN_CAPS_HARDWARE )
+            {
+                if ( hardware_domain )
+                    panic("Only 1 hardware domain can be specified! (%pd)\n",
+                            hardware_domain);
+
+                d_cfg.max_grant_frames = gnttab_dom0_frames();
+                d_cfg.max_evtchn_port = -1;
+                flags |= CDF_hardware;
+                iommu = true;
+            }
+
+            if ( val & DOMAIN_CAPS_XENSTORE )
+            {
+                if ( xs_domid != DOMID_INVALID )
+                    panic("Only 1 xenstore domain can be specified! (%u)\n",
+                            xs_domid);
+
+                d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain;
+                d_cfg.max_evtchn_port = -1;
+            }
+        }
+
+        if ( dt_find_property(node, "xen,static-mem", NULL) )
+        {
+            if ( llc_coloring_enabled )
+                panic("LLC coloring and static memory are incompatible\n");
+
+            flags |= CDF_staticmem;
+        }
+
+        if ( dt_property_read_bool(node, "direct-map") )
+        {
+            if ( !(flags & CDF_staticmem) )
+                panic("direct-map is not valid for domain %s without static allocation.\n",
+                      dt_node_name(node));
+
+            flags |= CDF_directmap;
+        }
+
+        if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) )
+            panic("Missing property 'cpus' for domain %s\n",
+                  dt_node_name(node));
+
+        if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) )
+        {
+            if ( flags & CDF_hardware )
+                panic("Don't specify passthrough for hardware domain\n");
+
+            if ( !strcmp(dom0less_iommu, "enabled") )
+                iommu = true;
+        }
+
+        if ( (flags & CDF_hardware) && !(flags & CDF_directmap) &&
+             !iommu_enabled )
+            panic("non-direct mapped hardware domain requires iommu\n");
+
+        if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") )
+        {
+            if ( flags & CDF_hardware )
+                panic("\"multiboot,device-tree\" incompatible with hardware domain\n");
+
+            has_dtb = true;
+        }
+
+        if ( iommu_enabled && (iommu || has_dtb) )
+            d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+
+        /* Get the optional property domain-cpupool */
+        cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
+        if ( cpupool_node )
+        {
+            int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
+            if ( pool_id < 0 )
+                panic("Error getting cpupool id from domain-cpupool (%d)\n",
+                      pool_id);
+            d_cfg.cpupool_id = pool_id;
+        }
+
+        if ( dt_property_read_u32(node, "max_grant_version", &val) )
+            d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val);
+
+        if ( dt_property_read_u32(node, "max_grant_frames", &val) )
+        {
+            if ( val > INT32_MAX )
+                panic("max_grant_frames (%"PRIu32") overflow\n", val);
+            d_cfg.max_grant_frames = val;
+        }
+
+        if ( dt_property_read_u32(node, "max_maptrack_frames", &val) )
+        {
+            if ( val > INT32_MAX )
+                panic("max_maptrack_frames (%"PRIu32") overflow\n", val);
+            d_cfg.max_maptrack_frames = val;
+        }
+
+        dt_property_read_string(node, "llc-colors", &llc_colors_str);
+        if ( !llc_coloring_enabled && llc_colors_str )
+            panic("'llc-colors' found, but LLC coloring is disabled\n");
+
+        arch_create_domUs(node, &d_cfg, flags);
+
+        /*
+         * The variable max_init_domid is initialized with zero, so here it's
+         * very important to use the pre-increment operator to call
+         * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
+         */
+        d = domain_create(++max_init_domid, &d_cfg, flags);
+        if ( IS_ERR(d) )
+            panic("Error creating domain %s (rc = %ld)\n",
+                  dt_node_name(node), PTR_ERR(d));
+
+        if ( llc_coloring_enabled &&
+             (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) )
+            panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
+                  dt_node_name(node), rc);
+
+        d->is_console = true;
+        dt_device_set_used_by(node, d->domain_id);
+
+        rc = construct_domU(d, node);
+        if ( rc )
+            panic("Could not set up domain %s (rc = %d)\n",
+                  dt_node_name(node), rc);
+
+        if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain )
+            set_xs_domain(d);
+    }
+
+    if ( need_xenstore && xs_domid == DOMID_INVALID )
+        panic("xenstore requested, but xenstore domain not present\n");
+
+    initialize_domU_xenstore();
+}
diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
new file mode 100644
index 0000000000..5655571a66
--- /dev/null
+++ b/xen/include/asm-generic/dom0less-build.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __ASM_GENERIC_DOM0LESS_BUILD_H__
+#define __ASM_GENERIC_DOM0LESS_BUILD_H__
+
+#include <xen/stdbool.h>
+
+#ifdef CONFIG_DOM0LESS_BOOT
+
+#include <public/domctl.h>
+
+struct domain;

This declaration needs to be out of the #ifdef CONFIG_DOM0LESS_BOOT
because...



+struct dt_device_node;
+
+/* TODO: remove both when construct_domU() will be moved to common. */
+#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
+extern bool need_xenstore;
+
+void create_domUs(void);
+bool is_dom0less_mode(void);
+void set_xs_domain(struct domain *d);
+
+int construct_domU(struct domain *d, const struct dt_device_node *node);
+
+void arch_create_domUs(struct dt_device_node *node,
+                       struct xen_domctl_createdomain *d_cfg,
+                       unsigned int flags);
+
+#else /* !CONFIG_DOM0LESS_BOOT */
+
+static inline void create_domUs(void) {}
+static inline bool is_dom0less_mode(void)
+{
+    return false;
+}
+static inline void set_xs_domain(struct domain *d) {}

... of this usage of struct domain *d.



+#endif /* CONFIG_DOM0LESS_BOOT */
+
+#endif /* __ASM_GENERIC_DOM0LESS_BUILD_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.49.0
--------------XhSxytRE3300FoxfdHaztzYN-- From xen-devel-bounces@lists.xenproject.org Mon May 05 07:52:54 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 07:52:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975866.1363160 (Exim 4.92) (envelope-from ) id 1uBqd5-0008MT-Jk; Mon, 05 May 2025 07:52:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975866.1363160; Mon, 05 May 2025 07:52: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 1uBqd5-0008MM-GU; Mon, 05 May 2025 07:52:47 +0000 Received: by outflank-mailman (input) for mailman id 975866; Mon, 05 May 2025 07:52:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBqd4-0008MG-79 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 07:52:46 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2061c.outbound.protection.outlook.com [2a01:111:f403:200a::61c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ed257135-2985-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 09:52:45 +0200 (CEST) Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) by DS0PR12MB9346.namprd12.prod.outlook.com (2603:10b6:8:1be::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Mon, 5 May 2025 07:52:40 +0000 Received: from BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13%4]) with mapi id 15.20.8699.026; Mon, 5 May 2025 07:52: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" X-Inumbo-ID: ed257135-2985-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Orcl7anhJ6iQERiDkRanvRT4o251YaJjrtbISMJBPAFD1Vuwnjty+DkR6Yv/vNxMLXbW1P/lvMoU+wKCY4lkx8z2bxeicpO4XakkHfgpOhdLA1OXScPQxXCfVx8wIPbJswEjtNJEigvIiXnl0lZguXkdCV9QGw2nfYiJ9mgUC88nzU/biVdqiyMeV33Je6xyLot02FE0NzWWdTmbCJmFRTHPF6ue2j+hrGldxdF/paBBbJXoMc0DA6Svz4ezBIRTcjF0LES1oTaggEhEmjm3jcwTPjWtoqHU7yoKqrTLSTcuqk+FKOJl2ED4MHqN7lefkZa+zhrAqSfAVkEyB8dOjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0qmRJpmiC86jBahLrJ4W7DAKBIe2WvtZHlOzi0dqJOw=; b=Z7MrPl0xapcJFxKLc3huL1fevzN77dqV0RgL3yiTQNKQSLCmAiFa31+v/jIr2+FUkoXtZ9/JtQgPSPuPkoW9mum9bmRkuA/gER+y+r8dwePjpzzkOyM4w8sk49r3QP4hCBdINtMQMCQQsC+R68ybllrOJeS6SaRMme5oJU85WFOaYN+SI1373cNPrVLO8QYXVL39nxLcEW17c06H2n1iyjjBUkkY+Zr+oA5oZIjqoiXotmj1Y1D8jXNXoSmO64HMFwXthKIBmI48Po7LZYkdAeIteFuWeiPi3L3ypvSX8hCfl8iPj46+JzMGPnB/oGIb5ZdvRtOD4F/vOEvZsvVjGQ== 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=0qmRJpmiC86jBahLrJ4W7DAKBIe2WvtZHlOzi0dqJOw=; b=T8DcpODyLXzBckuOTJTt8PrxmvDcUwzORtXQk/pLiVmlZV8rJaGNoEQ4bGUAkBVDPl9CqpterjcU+pmtHfAtYwqHOk8SbtM5SKXby5dTP5l3NLPa4P/YX74JVc0ddnQFlhPfuRC/WTmwz0+fB896TPPGJNJA51MTFYpFhUSHX0M= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: Date: Mon, 5 May 2025 09:52:36 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] xen/arm: fix math in add_ext_regions To: Stewart Hildebrand , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Ayan Kumar Halder References: <20250505025631.207529-1-stewart.hildebrand@amd.com> <20250505025631.207529-2-stewart.hildebrand@amd.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20250505025631.207529-2-stewart.hildebrand@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR0P281CA0006.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:15::11) To BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS0PR12MB9346:EE_ X-MS-Office365-Filtering-Correlation-Id: 62e82653-8f5e-4130-014e-08dd8ba9cf44 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?RmVZWEFRMkkwaloxT2J2ZXpqZDVsYzVqSGladFR3WXlibWNzeDV0UHI3Zk9m?= =?utf-8?B?V25QcjZ6Z2FlWUJYRnZ2d1RtUG15WWw5VVJFQU94bXcrQTZvRmFaRGw0aHEx?= =?utf-8?B?WlRYV2dQS3NEb0Z2dklRZ3BVejdvaGU4MTBtTnlJSldsbE9MSlNkc3FobjU1?= =?utf-8?B?TnA0QllUR3E5TlRuOHEyYThMeEcwMW4raHVFc05zTFl1L3FFbzJGbFVubXBw?= =?utf-8?B?azJsNjUySXYzcU5tdDJHUUQzT0lxQVRpbTVzUkhQK0l3dENyUWFtSHAzV0Nv?= =?utf-8?B?QTI1eStkN3l2Rlg1SFpxM3JxZlBhVmtBdVFMeHdNZ0VFRGk4a21mSUVIRFp1?= =?utf-8?B?QWVhVTYrQk1yT21qc040c3YvWmdwMFhnSk1mZHYvT0hTNUprZ0hqQ2l0YmVQ?= =?utf-8?B?REtQMVJ4ZWVua2J3RklDcjNhMjJTYmFzNUFUUElTZGIwVm9URG9JVDg4eDAz?= =?utf-8?B?YzBhUzlCU20rVlUvejlDaTIrMERWUnpKcDRGR1JUVExYSDlVTzFPQUNQc1d4?= =?utf-8?B?aENxSjVzSXNDZW5DaTN6OXdnT203Y1YrQjJvV2RDNytBR2hiekN2SVpuTnVJ?= =?utf-8?B?cVhNZkJkK3lrSGRMQm1xZGE3SXZPK2E1Rlo5Vkg4RTNtWnJkQUpLQytYQTZh?= =?utf-8?B?ekQzVnVQV0YxN2tpcXM5R3Y1Yy9SVkE2YUxtMVJQaHRmT2t1VmNXRmVLM1FH?= =?utf-8?B?T0FJL2JWSUJpN2ZLTWYyQ01STEFtQXhTZ3FUNUJRYkhLcE9DZElaRnpVcTh6?= =?utf-8?B?cFlHSEU4V214b21mV3hJVGhmUzZmM0d3Nmh2MlZFUkxIQ3VSdnYyUmE3OWc4?= =?utf-8?B?UDNuczY5eTU4bkJsNHhpSXlEUmZ1dHd2akNTRlNCUUlVS3pXWnNXZ2liUW9L?= =?utf-8?B?di9KbGl2UkpDd1dMeDVmK2FSMFRUQlJ2dGQvQUJvelBzdkJGSTVVSk1TM2pW?= =?utf-8?B?RWRrQVdvVFp6cGVUaEw2OFlhL2k0MDdlL05MZUNHRVRIM2lzRVo1bWUvSVdw?= =?utf-8?B?bDVnMnpDckxsbnU1Skcvb1V4VU8wYTBuNmJiWlJWRzB3bDVjZlN0ZVhjcS9F?= =?utf-8?B?NlJIR3d4Tzg5REFaZ0p3ekdHdnZheWt4MUREVlRadkY1TEpIaVlVelBxRHdV?= =?utf-8?B?endJUldLN2M5a1hEdWZabjVudXZsVWV3cTNINktOY29naW5abWR0RVNlMkEw?= =?utf-8?B?eGVVWGtZbjNaeXJZTWM4RmUyVG9nSStna3FCOHNYdTIzLytDOEc2RDJJV0Ry?= =?utf-8?B?dko3UHNtWnUrVEMvMVlsdFVFRXdVVTJKZzRmMFBkMHlwNlFleG13YXR6VFgz?= =?utf-8?B?bTNwLzNTdjVqejBhSFRiMDRqbjNXb0t0QlVPVERVZWpUVWkvbzlJN2p0dk5D?= =?utf-8?B?bjFoT3hOQ1VuSjJpNExkWnhoM1ZTS0UzRzF2QjZmTWR1YjdhMXJNQWp0dFdE?= =?utf-8?B?d1N2ci9GeVZZWHFlTEFUSW5VR1dMT3dkOFE5Y3JiaFVRWlc4d3hHRkJUMXA0?= =?utf-8?B?SGxLMTlNSlg5ZnRSKzVJZFRhNjM5V0NJQzZnb1BCaC9aUEF2anh2K0FIYWV5?= =?utf-8?B?UXovdTFRQlJ4VVFxMTRuSmlXZldFQUhPY1JJQ3NNUWIxbHdXNHRkM29GSmFP?= =?utf-8?B?Uk1lTG9VdG5nYkwvTHp1SWhCUE91cm1sTDBXd2tVUHNVTTdlU1gzY2cvK20x?= =?utf-8?B?clJvazJPRXB5VlNNR3dWbVhSa3ZrRkxVS1NYNzFtdnF3VmZ2Qk5zRkNkN2pC?= =?utf-8?B?L1psVGJVOExNWFEwZVBwZE95L0tGdFRlWjgvSjloK0U0dUtHWDlQNmpQbnB5?= =?utf-8?B?OGh2cUllWHZWS2NzZ2lvcWJTbndkNVUxUFAyelZMUkloOXh5Y2dKOS9xaHJa?= =?utf-8?B?dnNhRlF1djR3dU43MGl3Zy9mSUZLK1IwOU83MXo2d0Y4ai9Mb2ZaMytpbzdo?= =?utf-8?Q?jF0AMKmC0ps=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M0JEdlFSak52eGFxV0tQWEF0amtLWUlDMUtwMDdNRVdXZ3pwRkNwbDhiM0Yx?= =?utf-8?B?d1c2Mi84MWhpNzlXcDV4ellrWTZCMDR2V0dKZnhVTzJGTFhpOXpwRVlCbzVk?= =?utf-8?B?Ny9pUkY2RGZaZ05rUkdsdTZjc1V0NDNuVjBoU1ptSFZEZ0dpNGJybDh3Z3Fk?= =?utf-8?B?dTJ5Y3NpRFNVZXZmelRPTE5xVWdBOXZWZGJzL2wySVAvajNKTUJKbXF2cDhm?= =?utf-8?B?OW9jTmhXMkdzQ3dnR2xCcVIvWDNOR2phbVVvU1lVU2IwSjhldll4bjVSclhH?= =?utf-8?B?dEZvRzkwNjdEVThyL2hETXlpSlZvdldqMDZJWm1uU252WTZPVHN5NVRyRlFy?= =?utf-8?B?dk5iaS9ZSzVwMko5L0twd3RaT21PN28yQTl4anJ3dUNqYVUwUEF0eHFkblll?= =?utf-8?B?VURRdW9zcHIxZ0pacXhqUWYwSHlyalRYcEhZdUpXeUVtbXFLVkVjVHVJWGpR?= =?utf-8?B?a3d4RERRcFY2NzZGcUtXNGdaRFk4VDVTZDNhU05RZlZJR04vK1o3b08vcFBH?= =?utf-8?B?OTNwdHpPck1iNy9vTzIxRFBiZzhTWnZ1OC9MRndDd2dyNU03cEZyU3k4SDVZ?= =?utf-8?B?NEh6Yy9qbnZGbXdCa2NsQVlGbmw3djVIYml3dFZQY3hXUmNOYkxsVFlua2I0?= =?utf-8?B?U2I3WmFrSnh1UGN1MWJMdkxTbnJIWTg3UHgxYzh1Q2xsSW5PTFV0UXRxeURz?= =?utf-8?B?L0ZtMWxVTDNMMUJnek5mWStuRGo4d3Jla0taUHVzY1lTaGlhZzBQUWNNNDdD?= =?utf-8?B?ZVVhYXRrWnJDNDNRS1JNV3h0eVdQaDhNQ0JPRk0rTWxkVFE4a0dPOW8vN1hm?= =?utf-8?B?bFQrUFNZL2dvbzh3S0sxVElsUjU5RmQ0YzdaUWQyS3BncDAxK2NjdnZmWjRK?= =?utf-8?B?aU9ZMFkyQTJmTVN5RDlocEQybXVvYit5SFR3UVVxdFpBb0tkNUFhVml2R2hG?= =?utf-8?B?ZmkyV1JjMEY2ai8yMGI2c3B6RWk5Qmw3bGgrTzJpc3daek5DbWVka2Fwd2p4?= =?utf-8?B?bXU2UVZHcVQvbFhiQWt3NWl6S01BZnhoZDB1ME9pd0s0RDF1V2gvMVNYTnJG?= =?utf-8?B?MFh1ZTFQU1h5UnA3dXV0U21hNzVhZTYyWkpldWEvYnFwRldUaWNUOGRyb0V6?= =?utf-8?B?MGUrV1h2ZDBRQUo0V0E1VUhqdVhEamVsZjU4NGtFQXMrZWRIK1hxcVJBV0pL?= =?utf-8?B?emZiRG5LdDVYRU1Pc2pyYU1mb0ZzZ1lweCs1SWJNMzYwb1hWWXlYVEdlUndG?= =?utf-8?B?OFJvTmVsOGRvWkM5LzNRMDlXWEhVN0VPdWJ3bzFIWGxCZ3dtVkJPY1NCQXUw?= =?utf-8?B?QXVucFZTNjJHeVY4VU1sWlJmR1V0V1FmUmtrNHptYzMyY1B4dW5xcDIwelk0?= =?utf-8?B?YlNpSEpDM3BtZ1BlaGVqZ0FrajZJRmoza2EzaCt1ckNCSDRXMng5R0NzZFRh?= =?utf-8?B?KzFYTi9WTzduVkVaM0RVT04ydHY3Z3JaR2xDWVVqTHQ4Zk54MS9McjNidEM3?= =?utf-8?B?VE9Td2swUThkc1ZDRDFPT0FnUFNJUEVzZDJCbENiNFlBWXhpN1NaN2s4eXdz?= =?utf-8?B?d1JySThPQXRrd1BOa2dhT1cwVWJjZ1FNVjZMcU1ubnA5Wm55em9WNnRuanlx?= =?utf-8?B?UUlKRWU1YWxDaVVDZ0t5U1JnL3NhSGlkYXRsT1ZqUWo3K0xKeTBXVUpBZ3RX?= =?utf-8?B?N003NzZya3NWdU16Zm5DL1lPdS9NWE95MHQrb1BpdHI0Rk1iMEVmRGRSclZT?= =?utf-8?B?bVF2a0kyMUVzMndBODNGNXNVSFBFM0QwNklmcVdOOXRkYXlsS1A2L2lYQzdu?= =?utf-8?B?N0ZkUGhOUE00L3IxOFQ0emd2MXVXQ0t0RkN4YUEraFNTYS9MdmUvU090ZFpD?= =?utf-8?B?RUVBelp0NlpKMUxzVWl6emlVbnBrZU9VT1lORW4wYWpLbHlIcm8wNjl2VmNp?= =?utf-8?B?aW54NVkwV2FISDlhK2pUcTdMZXA3V3FTSzNZeFNoU0IrR25LUkM4cmZJL1M3?= =?utf-8?B?L0RpNnpTdGRjMlRnNG80ODZWYUZPRDRyOStBamVyb1ZubThGZ3pCTFExN3dO?= =?utf-8?B?L3R3SDNuMVB3d1pJc1FSYU1oNy9IMmlrdVkzS0gwMnRhMjZ6RTE1ZVJCMlp0?= =?utf-8?Q?czLY=3D?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62e82653-8f5e-4130-014e-08dd8ba9cf44 X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 07:52:40.1180 (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: djkvxHhtda4kDZl4Hgs7rRTKU6aeScDUU4GUYGdPwW3OwwVjIkYHw6NB1jVaFp0q X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9346 On 05/05/2025 04:56, Stewart Hildebrand wrote: > In commit f37a59813979, the arguments to add_ext_regions() were switched > from addresses to frame numbers. add_ext_regions() converts the frame > numbers back to addresses, but the end address (e) is rounded down to > page size alignment. The logic to calculate the size assumes e points to > the last address, not page, effectively leading to the region size being > erroneously calculated to be 2M smaller than the actual size of the > region. > > Fix by adding 1 to the frame number before converting back to address. > > Fixes: f37a59813979 ("xen/arm: domain_build: Track unallocated pages using the frame number") > Signed-off-by: Stewart Hildebrand Acked-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Mon May 05 07:53:07 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 07:53:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975870.1363171 (Exim 4.92) (envelope-from ) id 1uBqdP-0000GM-Qt; Mon, 05 May 2025 07:53:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975870.1363171; Mon, 05 May 2025 07:53: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 1uBqdP-0000GF-NW; Mon, 05 May 2025 07:53:07 +0000 Received: by outflank-mailman (input) for mailman id 975870; Mon, 05 May 2025 07:53:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBqdO-0008MG-J4 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 07:53:06 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20619.outbound.protection.outlook.com [2a01:111:f403:2009::619]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f9e04fa7-2985-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 09:53:06 +0200 (CEST) Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) by DS0PR12MB9346.namprd12.prod.outlook.com (2603:10b6:8:1be::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Mon, 5 May 2025 07:53:02 +0000 Received: from BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13%4]) with mapi id 15.20.8699.026; Mon, 5 May 2025 07:53: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" X-Inumbo-ID: f9e04fa7-2985-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eoXP6z363vO+wCgOaAwFGsT+DFRVgZWgjaWYHhziPBEMkgCmgIY1+2XVJafTgwLMXf3Uv4GJYL2fzRuRAcBlQTpuDW3YW8Ey865PP3k6dlF+2XM6/3AQ2YSI+rN95ZZNcBAi8B/OG1GRG5KLlV53jzFmxKKAhtSTXdqQ82i/NMpQk3nUjOT5FlmNZ4+5a4Ac2JCiIsdxiIlbEtCeK9IrUy35KzmRlPoTkovTRTs9/GccAZAfH5uoUP57Nhnkv3CsimoHbCocAp2Dod2eJ7z2fruQ2QiQVR4mNRf+Y9NYXZKtcWmc2vVtyYqwBOrKaoCBgl1UKDnjWgOlxI5OfpKN6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=omH6pmtu5g3vZH53Ks/+qvZpK7FmZYOIbCvEAKvwg7I=; b=JPHJLtaougnxv+pC1JcB+CYHJ1fddqXCm8fx1yZ4jRT4aHl7QiYU4UK5ISskU/JHJCIBwpYI+/wlJnUc8DAI329Do5De+Rl8qC2jRk8PNE6hsfkGGZPtjnYzMx1c6fiexN6XFVM8woY3rfUMMdmVQ7aPaecze94y83iblZyEa5ERHehLzppuidUKlWMDAERdVSsD3shMOSfwxRUhM57peYkoBEVakBBzVrVvbsn2HDb8MO8hPwHg0k/fdsyPYIbryOw5UvP5TgFTiLb92dcgk6pMC98bgaMO0XeNfd1SuJEfQ1/UCJcVviwfMFBvK6qkRPRk59/amPTBBPrDMUckzQ== 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=omH6pmtu5g3vZH53Ks/+qvZpK7FmZYOIbCvEAKvwg7I=; b=fUMSbP9nYoUF85H6dGN/6P48SMFzIAs4OecKBcTS94bc5opgQHEfsDY6B6HfjIskPrWBJ8Sn0dFwLHuCJ5YCAm48tLLBdeZCLr206MyvM/twXIZhVWr1sZeoqneJQQ8WnaQhpg3+bJTy911xmyaxwcmlglg+06KpwjGo3FxyOOI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: Date: Mon, 5 May 2025 09:52:59 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/6] xen/arm: fix math in add_hwdom_free_regions To: Stewart Hildebrand , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20250505025631.207529-1-stewart.hildebrand@amd.com> <20250505025631.207529-3-stewart.hildebrand@amd.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20250505025631.207529-3-stewart.hildebrand@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR0P281CA0007.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:15::12) To BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS0PR12MB9346:EE_ X-MS-Office365-Filtering-Correlation-Id: eb2ee788-b68f-4df1-4b35-08dd8ba9dcc4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?RVY4dEhnYmVrZXNmeFUyNXZrTVRGNWxRd3M2WjZKakxFZEJCd1o3TWJzNzVj?= =?utf-8?B?cGlURnlIYzhZZkZldUhLQzRQYllid2RVVGY0ZjFYWDQ2VEZ6enc3a092ZWVw?= =?utf-8?B?Q1ZCbjlQVnJBQkJkR0lNVXBLY09YbXFBaUJ6YkUxNE93b08rQWFRMHByTExh?= =?utf-8?B?bldSMGRJS2l5TTJwYVBYU3FmT0g5YzYvOXExQ1IycGh3RGUvRmtnZE15c0sz?= =?utf-8?B?TFA3RmY2d1lCMG5ZTmpjTGtvVVNWM2E3M21iaXB3SnRtZGxqNnZwM202aWdS?= =?utf-8?B?c0VvTmlEeHZRcjJYQ3JiaTJrN2NIWVBraEtoSUhQT28vczV5ZUJuejJBdFZJ?= =?utf-8?B?SmVBV1AvamRtc3NwZkVweEZMMVNoL2dnUmR6RHUrbnpFbWw5NUtsM2NEbTJn?= =?utf-8?B?VW1aZWpUWFcyV0cwNXNVSXRoeHJza2IzcFdkMk1pVjZjQVlBRUhqZktiaW82?= =?utf-8?B?cmYxZWVYYWg3TU9nNko2TkdhMmhMc3RjTHN1VlM0Qm5oK2JCQnViSFBKVS92?= =?utf-8?B?TTQ3L3NWNW1iNXFMQy9ET0lRSHEwenpneFZRSWdadUVoS1d5b1VqbGpkYk1V?= =?utf-8?B?dzBGaXNqUkJabDNueWUrcjYwVHFEV0RzdHRyTm9iZ2JsMlcrTUNTTjVCSnpR?= =?utf-8?B?eldVRkR1M2pJZ0xENTFmcTlDV3dZVER5MEZsVkcxR2xGWXFBOERQQXFYbktk?= =?utf-8?B?ZFJyQmFYUzdFVE0rcDUwSXlHdTRxNm4wU2prbkJNUE9GUWF6TmpZWCs0Y3pO?= =?utf-8?B?elBzc21xazRQVi95Y3l4QmtFS1czUENob1F5TWEzTVpaMzM5QnRUekFpV3RO?= =?utf-8?B?bW9CZUtjVG1tQmVZcXgyWE1JaDYwdERIQXFVZ0R1eTRtZEhmYVh1aTB2OVFD?= =?utf-8?B?enZrOVlCdTR3ZGdJVnk1bUpwaVN3UHU4U0ZXVVlOWXA5U2t5ZFdDSWp2VFZv?= =?utf-8?B?RUlMYWhnYmtmSk11bnFZT0lxUHBsRCtUaGFjNHRXZGZBOE4wNG04Sk8vU0M3?= =?utf-8?B?MlJEODh5SHpvWEM4OE1pdVM5dk8wTnU3eUpKNTNsYmZWSjBpVFh4bHRxWFpF?= =?utf-8?B?eTE0Y2hETVFnR3J2VjE3NWlldVpGVDhhcWVhZHdZdHBxcjFJQXlKL0RvN3pm?= =?utf-8?B?Nkw5U3NlQjk1Ujl0K3pXT2w2MXc5ODlZOGxQUjhmeVlhWWE1K0sySmgvT0Zq?= =?utf-8?B?c3BtREw1eHczTDkwTjBQQlFPM09KRHUvRFJDNHZnOVVNS2xBNnJnNTc1eEU4?= =?utf-8?B?ZExZK1FiSlJiK2h4cVY5cXY0bGo1SkFVVFRVOTVrNjhiNGFHRE9ySmRsYkVj?= =?utf-8?B?dThWN0htVDBLVTJpVVN0a3ZnV0hMYXdhNGhzeDlzU09rbWZBS3RmRkQ3dllu?= =?utf-8?B?a011ZzJpS1FmQ2NGbjlDa294QkkyVzlzc0lRY2ZYVmxKL2dIQitUVThMVDNO?= =?utf-8?B?MXpJdm0zY0tFUk5vUkJNOE1TTE5WajZEeXdTT1huR3o0Z3R5eTB3dDU2Y1ND?= =?utf-8?B?cU9HWCt1VHVHd0x1RVVtMVNiOXVhTmJrRG96UHJuUHpKaTRndmZjUEs4bWpN?= =?utf-8?B?WHErZFZQUDE0dUMxUTlmd21pbmp0VWs2NlVqWUoxYjkzS0kwcXhNaFVLanRz?= =?utf-8?B?Z1c5dTYrRjBDNTlVekEzdms0WUlDdmZHL1RHd0dQMzdPcGZ0OTRESUF4V0tn?= =?utf-8?B?dHRQaEhLc1BhdjN4dDFvd3EraFpUblRBOFRWUEpLbDFlMHh6Q05yT2wzMS9u?= =?utf-8?B?ZHArYWp5WFVtZ3I5OVVzMWVtOUVrdmI1SXduZFpjcmlzRUIvY1UvZTAzWjRS?= =?utf-8?B?N3FlTytCbGxoVWVBZ3VmbS9xd1FlNnY2cFlNcEFrYitHMjFrUlBTRDlDYW5i?= =?utf-8?B?OVk2LzFid0cvdHM4c1g5WWdCSnN6V1Q0cktCTUhlZzE5QVpHeUJyaFhyVGFC?= =?utf-8?Q?tKRORr2CnPA=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d0pVdjNVdWJ2QWQ0UzFSUTA1QThDcWphUEdQQnMrTnFYeDN4NHZabzgwMi9L?= =?utf-8?B?TUVLR1k3QXk3SHZiSDZtSmhLekczakFtZ3c5MkZTTlV0dURETE5GZHh4MzYw?= =?utf-8?B?VTZBVVE2NGI0YTNnTFFaQzN3WXU4RjJxaXFPNU9IM1pTdTFpc2NoU3gwaHdQ?= =?utf-8?B?YkhNY0doTmtVZ0x5NlIyczJtTFMzTmFQckpVZVVMaGFyTzBtWnN3UXp1Tm9o?= =?utf-8?B?UTZPbXRkdmRNMjlXdDFGZXF3SzA3N0VZNWp5aVB6SmV1L2NPc2tDbkQ2eXUr?= =?utf-8?B?OFdpRno3c0pITnp3aEpNdWdZQkJzZ2NSblZ3SGxVV1U1SUdXSzZ6OWcvbnpR?= =?utf-8?B?UDErUkFTbzAxckpHVWVkaGRoeE9CWHE0SUt2cGt0eVE1eDZjbk9rLzFLOERZ?= =?utf-8?B?bW0xamt4L3hhOFdXcVJ1V3dFbk9CTlJEVS9XeGdlQWIyS0Z5bU5QTDlOQTRU?= =?utf-8?B?UlBSSzBobG9jT0xZWnZMeVZzS1Q3L1AvVWtXZDlCSU82K014bDNjMFpGclhN?= =?utf-8?B?TGY0ZklRUDhCSE9wNFhsTmlVZjc0U2IvcHpvUE9nVU5qRGI3ZWxSc1F5dWdC?= =?utf-8?B?K242TEJZbysvZlpzWDZOaERDMWlXOGpDUkhZWk5ET0JDU2RnSmthT294NDV6?= =?utf-8?B?Qno1M09jTHpwU0RNMU1DbE5UMXdHUjJmdmZUQ1VYQU54MHA2bHBvVmNydm9s?= =?utf-8?B?RHJQVXp6ZmZ1K3l3aHRNTGVwWHI2cTlDREg2Y2tTLzJtejYwYiszT3hGTEh5?= =?utf-8?B?UUN4YW9BOWdIdzFNMEdSTEZuMVZDSk1yZFRhRVRxYWxzd0s4UWdEK29IcjVz?= =?utf-8?B?WmxXaDZZWk5QMjc4WnlXUW9tMEo4d2UvMGxENXNFUXRFS28wSXNDWDNQaHV0?= =?utf-8?B?cU11dUFCS3JYazFodThvcThCM1BNWUtraFhSWDNFenhtQ0daaHpnWWQrMDBO?= =?utf-8?B?cUkycmpHSmFsQzR4dGJHR3Z3TW1HWm42dlE1S3FrSWJoeldDZk9kRnVodFpn?= =?utf-8?B?cDAzbG1acFhwaTdSb3FkV0FhOERSSG9lMG9lLzNjN0xpUlFFVXZONlNQbFQ5?= =?utf-8?B?QTVLNUJTaXNpWEJDbXBrblEwUHBTK0dzVHdMcmsvZkJ0TVpxQnF3TVRrTW03?= =?utf-8?B?dXBTbzNIMHdOeVhYNlRmSTZMYzRvWkxkc2laMW5ZS1ZwMEtoK25WWllLVTll?= =?utf-8?B?R1VjL1pyank1M0pvS1pEdlJPVDY0V3N4U2YxaFpvNWF3M1pJNFRkTVlPaytK?= =?utf-8?B?STkrUmUwdXljU3UycG5nSzd1R3VQVDlGQWJxb2M1enFKN0ppNkxIaVBxVXcv?= =?utf-8?B?bG9kcE1DYXpoRlpVQXZzRnprcGtGRTFyQmREUGNnTGQ3U3ZlcXVjbW1qQ1h1?= =?utf-8?B?QmNSNytTbFJlQXh4dWdLZnVlWlpycFduQnZFdXFkQTQ3MkowRTk5dllJSkRJ?= =?utf-8?B?S1IzdHlIS0lVM2ZublJPUGRtM3JpL3ZIZ2lLeVFYaHBPVFgvZnZwYm1uTDA0?= =?utf-8?B?VCtYUmx0ZHY2Y3NZUzdnUG8rc0JPbC9BM0puUklxcEgwYzRmeU1FRmhpcG9y?= =?utf-8?B?MmdueVZ5aC9jb2hHa0FqQkNhTWM5bEVUVEgyQnJ5UlZGbjgrTGdsV29PSHA3?= =?utf-8?B?bEE0ZWJ0NnUyK0l5N0RYZ1RuZ085Zk5qYURLQVc2VFFFNkk0Y3VMUXRnK0Uw?= =?utf-8?B?Y21HRjRXRnMraktORDhUeXg3VFg5SmxheEN5ZU5zeDVweUJLKzVzWFg5ZVB5?= =?utf-8?B?cTd5elFURU95YlVZYjEwN3dwNVBrK3R6dk5rSU9mUWJuNDJldHE5SmtHOVpl?= =?utf-8?B?T0ROSkZhVUtsK0V1MUI5OHVpbE9hd2wxajEyQk5BQ2U0dUxINkhDMzhadjJN?= =?utf-8?B?Rkg3QU9oS3plbElJZzdXNkFGTDF2clpZaXpIaXFaZmcwdTRseWFBa0YrOFdy?= =?utf-8?B?UHk5TUFrN2F0ZzBXRjU1UXFCNVRON0FFMFI4RjlTR1R6dTFvZ1JYRWt2anR3?= =?utf-8?B?Q2VxZ3JWQVA2dEJMbDVwRkJ0aUZ0S2Vna3gzMmt6NDlDdHhudkRubGxxQlpv?= =?utf-8?B?QTZPbmFWVzV4TUtCaHZrbE83OHRGMnRycXZwcDdKN3R6d2d3SXBjOVZveGNq?= =?utf-8?Q?sIUjHIKClI5C6o2ZwiYAVUFXl?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb2ee788-b68f-4df1-4b35-08dd8ba9dcc4 X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 07:53:02.7735 (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: LN7WFpPLnsqpBPRHPy64KFmUc/ScaaZoD4sqDHbf8Yt6HnSkgfZelgrJ5+FpeDiZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9346 On 05/05/2025 04:56, Stewart Hildebrand wrote: > Erroneous logic was duplicated from add_ext_regions() into > add_hwdom_free_regions(). Frame numbers are converted to addresses, but > the end address (e) is rounded down to page size alignment. The logic to > calculate the size assumes e points to the last address, not page, > effectively leading to the region size being erroneously calculated to > be 2M smaller than the actual size of the region. > > Fix by adding 1 to the frame number before converting back to address. > > Fixes: 02975cc38389 ("xen/arm: permit non direct-mapped Dom0 construction") > Signed-off-by: Stewart Hildebrand Acked-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Mon May 05 07:57:19 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 07:57:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975886.1363181 (Exim 4.92) (envelope-from ) id 1uBqhS-00011V-9R; Mon, 05 May 2025 07:57:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975886.1363181; Mon, 05 May 2025 07:57:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBqhS-00011O-6b; Mon, 05 May 2025 07:57:18 +0000 Received: by outflank-mailman (input) for mailman id 975886; Mon, 05 May 2025 07:57:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBqhR-00011I-3o for xen-devel@lists.xenproject.org; Mon, 05 May 2025 07:57:17 +0000 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [2a00:1450:4864:20::430]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8f82b6a2-2986-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 09:57:16 +0200 (CEST) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-39ee651e419so1975687f8f.3 for ; Mon, 05 May 2025 00:57:16 -0700 (PDT) Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3a099b16f00sm9376659f8f.84.2025.05.05.00.57.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 May 2025 00:57: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" X-Inumbo-ID: 8f82b6a2-2986-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1746431835; x=1747036635; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=SS0XKfa2BGFD92M7JF8I+ODFTaJnsxA4wXeJO2N0DmE=; b=nu0JL6rW7uXnvQnZS3QoaxVS44td+8CRrw/tupXFdr7sMcBp1xEY69rqP3Pbn7WXRQ acBDPw0b+NsIdOYkfCZKm8s5mFbw40733NAZxlxs4bi58KPptmePb3MQJw5LxTh2HC7g XOB3RqE+RuGWH12KZteGVf6rsR816UEqCZ7Ek= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746431835; x=1747036635; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SS0XKfa2BGFD92M7JF8I+ODFTaJnsxA4wXeJO2N0DmE=; b=NDeLq096Ez448s7z9RXLhu02InjehpvuLq2MuU6AR8xrL+aKdWP+9Nio917ftZQZ5f xws0Z8c3qX3ZFqjjviNCGMHKUPuk7uCv6rN02n+stGyzh65E71+ynN0KN1A8uiQohklI pyAY5R4WsLc4TZ1PIxiVXNyMl7PHeHahr1kaLv1nPvPl0oxfuvu6XRJja7qRnU8nrivk J18fdbb0Ckzl2xg6tV+4MldTk8p+VXDCjfUihIjqyTZgTz8YCBrQ0hiJctxRUOK+KgzE /Vt2OkIzrt9pbuFSyF19PhdTiT3ULAW+9SHJ7VtpgFBYhglelaax3hGVyPBtBAjF7Kj/ xxMg== X-Forwarded-Encrypted: i=1; AJvYcCXsulcPUcHjnTgzVOWTuItRpX+PTHPWZosGUbZJOIyeyUYa6lDriVpj2NhXkJr/hhqlqRDeTeczGgM=@lists.xenproject.org X-Gm-Message-State: AOJu0YzOQU4xjDC3LebOsA6uqrVHdJ3dvFwEnAQizt7lcjdBunyaIZMr aqQl+IbzHD/HprQYHH0UDz9yp4zcKRIfRwM3p+7r47wDxkULZ3Xybo7XJ6F6AWY= X-Gm-Gg: ASbGncuQVzIzx2QagvOTAyr/+wd2wgspAy45jul0uNBJZmQ5a5ur0yZIRgdcvQTR3eH zp6ccmpy+B8wDC97G8KD5j5PbMgZWQkW7ZHtOum6sNiNrhpXJ5H/HLDQ1rURDHVAk1Q6CrS8JZe tzjCdPHPm4hp33/UFRUTInsoNy9gezdfdg3wpey+p1F+o8lpAIfu3qgedAEHS9kafbyEjPHCLPH fWE866ut22oTQwAsXxGKOB9Pnx1vW9prhv3Syf104OW2/yD3mlAMXkAlIEpsCTAHzqhxYFubQwT wpPnLIxGP2UjSFIwqlZ8MfGeeYttdMAaQJSsWNTbRLJfnw== X-Google-Smtp-Source: AGHT+IEXWUJe30SHxGQ6YXrEAVv1mmhC8ZHAnjwp/t2acmZrTGCcxPvdPGg1OdgZSq8lRn23HO5KdA== X-Received: by 2002:a05:6000:3113:b0:390:f9d0:5e3 with SMTP id ffacd0b85a97d-3a099ad1aa7mr10310845f8f.1.1746431835381; Mon, 05 May 2025 00:57:15 -0700 (PDT) Date: Mon, 5 May 2025 09:57:14 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Stefano Stabellini Cc: Jan Beulich , Jason Andryuk , "Ragiadakou, Xenia" , Andrew Cooper , agarciav@amd.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange Message-ID: References: <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com> <06b66971-d8db-456f-8e83-a20ff7df8f5e@suse.com> <59bfc389-66c8-4d0f-92e3-c0079a807374@suse.com> <3e7b4b20-0127-4db2-806d-f142547f275a@amd.com> <773170d1-d8ba-4ba7-90b0-df0d160d8ba8@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, May 02, 2025 at 09:49:30AM -0700, Stefano Stabellini wrote: > On Fri, 2 May 2025, Jan Beulich wrote: > > On 01.05.2025 15:44, Jason Andryuk wrote: > > > On 2025-04-30 20:19, Stefano Stabellini wrote: > > >> On Wed, 30 Apr 2025, Roger Pau Monné wrote: > > >>> On Wed, Apr 30, 2025 at 08:27:55AM +0200, Jan Beulich wrote: > > >>>> On 29.04.2025 23:52, Stefano Stabellini wrote: > > >>>>> On Tue, 29 Apr 2025, Jan Beulich wrote: > > >>>>>> On 28.04.2025 22:00, Stefano Stabellini wrote: > > >>>>>>> On Mon, 28 Apr 2025, Jan Beulich wrote: > > >>>>>>>> On 25.04.2025 22:19, Stefano Stabellini wrote: > > > > > >>>>>>>>> --- a/xen/common/memory.c > > >>>>>>>>> +++ b/xen/common/memory.c > > >>>>>>>>> @@ -794,7 +794,7 @@ static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg) > > >>>>>>>>> rc = guest_physmap_add_page(d, _gfn(gpfn), mfn, > > >>>>>>>>> exch.out.extent_order) ?: rc; > > >>>>>>>>> > > >>>>>>>>> - if ( !paging_mode_translate(d) && > > >>>>>>>>> + if ( (!paging_mode_translate(d) || is_hardware_domain(d)) && > > >>>>>>>>> __copy_mfn_to_guest_offset(exch.out.extent_start, > > >>>>>>>>> (i << out_chunk_order) + j, > > >>>>>>>>> mfn) ) > > >>>>>>>> > > >>>>>>>> Wait, no: A PVH domain (Dom0 or not) can't very well make use of MFNs, can > > >>>>>>>> it? > > >>>>>>> > > >>>>>>> One way or another Dom0 PVH needs to know the MFN to pass it to the > > >>>>>>> co-processor. > > >>>>>> > > >>>>>> I see. That's pretty odd, though. I'm then further concerned of the order of > > >>>>>> the chunks. At present we're rather lax, in permitting PVH and PV Dom0 the > > >>>>>> same upper bound. With both CPU and I/O side translation there is, in > > >>>>>> principle, no reason to permit any kind of contiguity. Of course there's a > > >>>>>> performance aspect, but that hardly matters in the specific case here. Yet at > > >>>>>> the same time, once we expose MFNs, contiguity will start mattering as soon > > >>>>>> as any piece of memory needs to be larger than PAGE_SIZE. Which means it will > > >>>>>> make tightening of the presently lax handling prone to regressions in this > > >>>>>> new behavior you're introducing. What chunk size does the PSP driver require? > > >>>>> > > >>>>> I don't know. The memory returned by XENMEM_exchange is contiguous, > > >>>>> right? Are you worried that Xen cannot allocate the requested amount of > > >>>>> memory contiguously? > > > > > > In the case I looked at, it is 8 pages. The driver defines a ring of 32 > > > * 1k entries. I'm not sure if there are other paths or device versions > > > where it might differ. > > > > As per this ... > > > > >>>> That would be Dom0's problem then. But really for a translated guest the > > >>>> exchanged chunks being contiguous shouldn't matter, correctness-wise. That is, > > >>>> within Xen, rather than failing a request, we could choose to retry using > > >>>> discontiguous chunks (contiguous only in GFN space). Such an (afaict) > > >>>> otherwise correct change would break your use case, as it would invalidate the > > >>>> MFN information passed back. (This fallback approach would similarly apply to > > >>>> other related mem-ops. It's just that during domain creation the tool stack > > >>>> has its own fallback, so it may not be of much use right now.) > > >>> > > >>> I think the description in the public header needs to be expanded to > > >>> specify what the XENMEM_exchange does for translated guests, and > > >>> clearly write down that the underlying MFNs for the exchanged region > > >>> will be contiguous. Possibly a new XENMEMF_ flag needs to be added to > > >>> request contiguous physical memory for the new range. > > >>> > > >>> Sadly this also has the side effect of quite likely shattering > > >>> superpages for dom0 EPT/NPT, which will result in decreased dom0 > > >>> performance. > > > > > > Yes, this appears to happen as memory_exchange seems to always replace > > > the pages. I tested returning the existing MFNs if they are already > > > contiguous since that was sufficient for this driver. It worked, but it > > > was messy. A big loop to copy in the GFN array and check contiguity > > > which duplicated much of the real loop. > > > > ... there may not be a need for the output range to be contiguous? In which > > case - wouldn't a simple "give me the MFN for this GFN" hypercall do? I seem > > to vaguely recall that we even had one, long ago; it was purged because of > > it violating the "no MFNs exposed" principle (and because it not having had > > any use [anymore]). XENMEM_translate_gpfn_list looks like is what I mean; > > see commit 2d2f7977a052. > > Unfortunately I don't think that would work because I am pretty sure > that the PSP needs a consecutive range. In other words, I think the > output needs to be contiguous. The plan for AMD-SEV support was to place a PSP driver in Xen, and not let dom0 interact with the PSP directly (or at least that was my impression from the talks we had about implementing SEV support). Is what you use from the PSP fully isolated from the functionality needed by SEV, so that we could still expose the interface you require to dom0 while letting Xen drive the SEV parts? Otherwise I think we need an agreement about how to integrate your usage of the PSP with the SEV work, as having both Xen and dom0 driving the PSP in parallel might not be a wise idea. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon May 05 08:20:02 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 08:20:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975902.1363191 (Exim 4.92) (envelope-from ) id 1uBr3L-00050d-6i; Mon, 05 May 2025 08:19:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975902.1363191; Mon, 05 May 2025 08:19:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBr3L-00050W-2j; Mon, 05 May 2025 08:19:55 +0000 Received: by outflank-mailman (input) for mailman id 975902; Mon, 05 May 2025 08:19:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBr3K-00050Q-5h for xen-devel@lists.xenproject.org; Mon, 05 May 2025 08:19:54 +0000 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [2a00:1450:4864:20::531]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b7b84f3a-2989-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 10:19:51 +0200 (CEST) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5e5e63162a0so6348893a12.3 for ; Mon, 05 May 2025 01:19:51 -0700 (PDT) Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5fa7781d7d9sm5132185a12.47.2025.05.05.01.19.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 May 2025 01:19: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" X-Inumbo-ID: b7b84f3a-2989-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746433191; x=1747037991; darn=lists.xenproject.org; h=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; bh=2T3o1odibACp4jPCY5sRhwjv8yfLCgCSt05xTQK87+8=; b=hQt1gqCeAzNgaJUog7UNu4yFihHb8It6akTVlLOOktljvUKiT1w9j3wnmJOSEmt6gz 8GFZ+4PR1x7NAb3ZoAYEW/eSWGapF4eF4Gr2QRZ8G36OeVpfhcQPPtooJNMshuDkB3bi 5kYvqPmEKf9n1niO8ki2ru2giawxR9LkB4Ik9RA9VuyWx/UoF6CGOb7a9ePnnllaRgFv uZ6sycOvvZoB3UeFe41SYEDyGwPZXkOuOlP4yxVVtCPq4Xo7Z7c29gqtd1Qbv6faBH0+ HTyh8nzowF0YdXsQlFMNL2cUfxJ0DTbalBxn+AXOIE9TGbAVZmWgGGAyH1l2rkaJHE0W wP7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746433191; x=1747037991; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=2T3o1odibACp4jPCY5sRhwjv8yfLCgCSt05xTQK87+8=; b=LmtB6Qlv8XDWPkXDcNe4MDbrXsxq0uwQT5gGp4XL4F1TKjxsGwzeoaOSWdJp2fiVNF 6ojI6SXHzSKPCudMVlGvZkG3k/Wx8XUwLsjH2rBw9s5Kq2l1F7Q3K/ULz6rfDNaX9RAK izuWYfMqGqezpgEmaXBCq0wq45nczeqDH1YlxRW/dSWJAirqiyfAnkFIa91RPeUhWvX1 guGcRjmXMCepkKee3uLjjEAHsJJdVsZnWDVuTAGFCjxo/aCyhql/6sCoLs46T45U9EJB Y72xJt4vxRIR5lVQpDo+t9SsBZteLVT97XIsIZ12vPri6uaSCw+fn9G3TxueYHrn8HA4 zUdg== X-Gm-Message-State: AOJu0YwZAOcsugG/1iBhHPVe7PLGbL5BIcbRPqAm1yIBVq3HQgwfo/ZV EWjX596GphyXgNTk7OffP2hzpnjHNhGWMqzUvQzUMbPb+ITt3SNX X-Gm-Gg: ASbGnctmx/8K1RcCGMBEXGbs506/vKxI2szsQNIt5Dl9Fohzi7Pq0kt+nY2rQWYvZlL 5gG+NgrzBxeEGCJTlFsGc4jSlatxjjO5eTwxqX6HLzU8KtsLNoAsyYop/p6C9qz0e5SjgcZe2x5 5zyf9YzipVF6Ufh5GNt1RV0i69OV1U0jSaPHMP0LKGmXp4GlzF7SsOfkNdg7lJwZgm+oPbkt9LY WCSbqrtHJQNUhWXEevq2ABtrO7lFbZSnCl487aOdM2QVJ4U1DymYXAWr3wcLrcdfI5l7VPeldVR yikdf+VNv9IRyOUc0gTlkbYzkXoVZIWIEPDuDoE6CGCr8x0kycm5Ufc8y1YAw9Jj+ht2Hg/DsSo J05yyNYSMpt+L9Xrr X-Google-Smtp-Source: AGHT+IEiKdMUY0ooP4LJiPqc4ZkuDFLgfvOTzH43MNbYCfyySrOXB/Bo4UGOfmOmVNjRp9LsSb2emw== X-Received: by 2002:a05:6402:2347:b0:5ed:2a1b:fd7d with SMTP id 4fb4d7f45d1cf-5fa780612dcmr9418510a12.19.1746433191102; Mon, 05 May 2025 01:19:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------NCkU60cuk7PbQbE7VufFRdZ5" Message-ID: <16f1e5e5-da28-4a0d-aa3c-b1eea6b8003c@gmail.com> Date: Mon, 5 May 2025 10:19:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/8] arm/static-shmem.h: drop inclusion of asm/setup.h To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <5e02dc75f4f396d054e9b9206b9305889cadb1a5.1746199009.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: This is a multi-part message in MIME format. --------------NCkU60cuk7PbQbE7VufFRdZ5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/2/25 9:13 PM, Stefano Stabellini wrote: > On Fri, 2 May 2025, Oleksii Kurochko wrote: >> Nothing is dependent from asm/setup.h in asm/static-shmem.h so inclusion of >> asm/setup.h is droped. > Actually, this patch is not currently dropping any inclusions Lost dropping during one of the rebase. I'll return it back. Thanks. ~ Oleksii > > >> After this drop the following compilation error related to impicit declaration >> of the following functions device_tree_get_reg and map_device_irqs_to_domain, >> device_tree_get_u32 occur during compilation of dom0less-build.c ( as they are >> declared in asm/setup.h ). >> >> Add inclusion of in dt-overlay.c as it is using handle_device() >> declared in . >> >> Signed-off-by: Oleksii Kurochko >> --- >> Changes in V2-3: >> - Nothing changed. Only rebase. >> --- >> xen/arch/arm/dom0less-build.c | 1 + >> xen/common/device-tree/dt-overlay.c | 2 ++ >> 2 files changed, 3 insertions(+) >> >> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c >> index c0634dd61e..7eecd06d44 100644 >> --- a/xen/arch/arm/dom0less-build.c >> +++ b/xen/arch/arm/dom0less-build.c >> @@ -20,6 +20,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> >> diff --git a/xen/common/device-tree/dt-overlay.c b/xen/common/device-tree/dt-overlay.c >> index 81107cb48d..d184186c01 100644 >> --- a/xen/common/device-tree/dt-overlay.c >> +++ b/xen/common/device-tree/dt-overlay.c >> @@ -13,6 +13,8 @@ >> #include >> #include >> >> +#include >> + >> #define DT_OVERLAY_MAX_SIZE KB(500) >> >> static LIST_HEAD(overlay_tracker); >> -- >> 2.49.0 >> --------------NCkU60cuk7PbQbE7VufFRdZ5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 5/2/25 9:13 PM, Stefano Stabellini wrote:
On Fri, 2 May 2025, Oleksii Kurochko wrote:

Nothing is dependent from asm/setup.h in asm/static-shmem.h so inclusion of
asm/setup.h is droped.

Actually, this patch is not currently dropping any inclusions
Lost dropping during one of the rebase. I'll return it back.

Thanks.

~ Oleksii




After this drop the following compilation error related to impicit declaration
of the following functions device_tree_get_reg and map_device_irqs_to_domain,
device_tree_get_u32 occur during compilation of dom0less-build.c ( as they are
declared in asm/setup.h ).

Add inclusion of <asm/setup.h> in dt-overlay.c as it is using handle_device()
declared in <asm/setup.h>.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in V2-3:
 - Nothing changed. Only rebase.
---
 xen/arch/arm/dom0less-build.c       | 1 +
 xen/common/device-tree/dt-overlay.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index c0634dd61e..7eecd06d44 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -20,6 +20,7 @@
 #include <asm/dom0less-build.h>
 #include <asm/domain_build.h>
 #include <asm/grant_table.h>
+#include <asm/setup.h>
 #include <asm/static-memory.h>
 #include <asm/static-shmem.h>
 
diff --git a/xen/common/device-tree/dt-overlay.c b/xen/common/device-tree/dt-overlay.c
index 81107cb48d..d184186c01 100644
--- a/xen/common/device-tree/dt-overlay.c
+++ b/xen/common/device-tree/dt-overlay.c
@@ -13,6 +13,8 @@
 #include <xen/libfdt/libfdt.h>
 #include <xen/xmalloc.h>
 
+#include <asm/setup.h>
+
 #define DT_OVERLAY_MAX_SIZE KB(500)
 
 static LIST_HEAD(overlay_tracker);
-- 
2.49.0
--------------NCkU60cuk7PbQbE7VufFRdZ5-- From xen-devel-bounces@lists.xenproject.org Mon May 05 08:35:51 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 08:35:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975913.1363201 (Exim 4.92) (envelope-from ) id 1uBrIZ-0008I1-FM; Mon, 05 May 2025 08:35:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975913.1363201; Mon, 05 May 2025 08:35:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBrIZ-0008Hu-Bj; Mon, 05 May 2025 08:35:39 +0000 Received: by outflank-mailman (input) for mailman id 975913; Mon, 05 May 2025 08:35:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBrIX-0008Hl-Qr for xen-devel@lists.xenproject.org; Mon, 05 May 2025 08:35:37 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20617.outbound.protection.outlook.com [2a01:111:f403:2413::617]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e9502779-298b-11f0-9ffb-bf95429c2676; Mon, 05 May 2025 10:35:35 +0200 (CEST) Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) by DS7PR12MB6045.namprd12.prod.outlook.com (2603:10b6:8:86::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Mon, 5 May 2025 08:35:24 +0000 Received: from BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13%4]) with mapi id 15.20.8699.026; Mon, 5 May 2025 08:35: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" X-Inumbo-ID: e9502779-298b-11f0-9ffb-bf95429c2676 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=k8hRabE1f9pTySSz6SiFaTJ0sH4yZfn+Pb8h0gl1K8elOwOfAKxvi77jqCor9W55DtSNy1xYVqTVXDa+3SLXTmx62zbe3uQFrH7ANUu5eX9QuRqfQpKAnu6Xfa3jBKGDbRNxey2Poxn8sHowflZVoGy+XUuolf8O0IWvkiNng+zhfJzitGcw+v2oiPtvBuSnrL1gxsWi/QPCs+Z2/hJUa2rputCR9rnE9VcEcaONPhx1+C2uVUk54nWKAlFGN/4uXJrZArWcz5rqZwJLYQgb3uJOfpYPO/iIVKAcLAPvWgvYRCEM5TrDcSliQxnaJAGSA9LAml8s/D0gCxq+64zIqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mFfj3SFvh9OVFCFDTh8GYOfxpCFeMSieq0Go9d+yCRw=; b=A5CngbPST5bwlJtFihoYPsn5eLBGq0/72rqJBc7tM2FeniOwxGjk+fKp01HD/CRNUQTnvkqup1ipPz/TsWOAWHtJjssb4seLnLD/oBCd+645+MCezBDwcfKxDe7K1jwnfQwEK28taOWx04Hx9NTPTGGlngPcokKj8HMzs87Lig7bWlmo73dHz6dbXfuYQflwjOSNfh3Ax4Trpi/SxNHCvXEbLqZLf62icFv8+ROWuZ7m3a90sMDyqgQqjFab5D0yQ8pkP2VSr1yQryXsly4Q7hG375cItIEYa84s6DC1Xni5jSR5jvJme5kRuOQrOAaEbdeuuqtbHJ1kNkCRB568Jw== 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=mFfj3SFvh9OVFCFDTh8GYOfxpCFeMSieq0Go9d+yCRw=; b=LIefhivE4Cw0rc7bFYT1ew/fbohFErkQjOZeAXn7+t0Fpd8eRrJg+Jk7791SetHqvBna7agJljhKJAiHjjEG1xKhY12RJ1ffhq/0hBBM1ev6QzUn6PYnm3ohjil6DP39BdO2EfwlGRS3omLpHRgmgavIpaNr0tXLk1PCXJ1yjJ4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: Date: Mon, 5 May 2025 10:35:20 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/8] xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common To: Oleksii Kurochko , Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <82f0c1d4fe25b4a52d76f3c8004e107b183af56c.1746199009.git.oleksii.kurochko@gmail.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR2P281CA0044.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:92::18) To BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS7PR12MB6045:EE_ X-MS-Office365-Filtering-Correlation-Id: 13296506-3ccd-4866-e351-08dd8bafc7a5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|366016|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?YlZBUmJUa0gwa2djS0tmWktSeVBnMHB0UUZMSStEWE8rQlI3KzlacXF4Vk5P?= =?utf-8?B?MnNPazF6ZFZXQ0FIRUZlV1RNUURuR3dCQmpHc1lzc05SRkJDdkFqZ1FQR0lL?= =?utf-8?B?cHlHZmxyTnRXREZqSHZvSUkwOThyNUIydktJNnNGT1RQWS85RGw2eThyaHhL?= =?utf-8?B?cXZESlF4Wjl3cnlWdDRMRERueFN1eHFsNFZNcDVoendPYm9HRGlva25iVU1l?= =?utf-8?B?enV1M3pLcUN2WFlKTGxVWENOczIybFR6dTZpVzlJL2owVGhoOHJ3Z2M4elF6?= =?utf-8?B?emE4R3FTSGdIcFV1UlRtQ2lYTVJrajlqeU5KQW1nL0FOM0FzS3hNTVMyY1JQ?= =?utf-8?B?NnpwQ2lxS3h4NlptYk93Z3hLNk9FczRVbmJoSndKNTNGZ0pCOFoyWHp2dE8w?= =?utf-8?B?aEpNV3dIaWNqcTRXRjhJSU1oYXc1d3FRUFFmTTNsbHJOKzAwMU9PcytyWFJR?= =?utf-8?B?Ry9rcG1rRktRY0hNTkx0TzdwLzUyQUR1YTh5MzY3UzZ6aU95T2VodEY5ak9J?= =?utf-8?B?RUs2YUg3RDNXS2phSzl2d1NEVnByVUhkM2k4RngzcHY3M2Rqbjl0TVdMSVFn?= =?utf-8?B?WGMxb0dsRVBCNlVxY0Z1UlNWYVZSZmFwK3c3WS95a1pjWlNNclB0dlZVTXpy?= =?utf-8?B?eTg2VzlQU0dxWE1pV204Qlh2YnREaUlwYjRubmhzSVQ3cXBPaFBkcnVNaG9u?= =?utf-8?B?RkxCdWJzTGhBQUZsTkxid1o1K2daNW03YmowYk0zRGc0L3VZQjk4a210MmJO?= =?utf-8?B?bERwOWZodXdSajVWMGxPNVF0bkpwMTZJQjFnTGhTZ1A4TTZydjhqekR6WUw1?= =?utf-8?B?U1U1bllCb0lSU3NUelF6ZWVlZkRnYjVZM1FkaEFhNHZSYmZmSElPSlFTSU54?= =?utf-8?B?V2V6Vm9GaGw5WHI3UmVWRzNPQ3M1aityUVNYU2swbHFQSGYrZVQ1eGlmdnlN?= =?utf-8?B?dkJoMEExa2wxNWoyT3p5TWxvMlI2Y2lGTWV1b0x1OHNBT3Z3ZGNuanE2U0th?= =?utf-8?B?S2didTZOUXlQNjBtaXNxcmVPWVVJUU5lYm9QeTN4TFlDOUpaU05Md1UrdVg3?= =?utf-8?B?N29jeTZQOXkydm4vNXFLNTdDTUtoMWs1YTlnSjVLMDNaRDRLZDNOcENFajFt?= =?utf-8?B?NXFnL2tXYzJNZ2NTRTRKeXU0a0NFSG5WUWgvbEZtSEo0WUNBNFAwb09MSnpj?= =?utf-8?B?aDNsUW1PQ2lRUnhVS3hHQUdOa1VFTU1wOHlzM0QxdlJZVkZISEc2WDVndjBv?= =?utf-8?B?UDN5WWQ5TGpvaDF5aGlqRWJqZzA1dnlybTFqNkZ3Y3ZSbFlMdTFodTBoeHFh?= =?utf-8?B?RDA1OWpCdWl0Q3Y4L3JSTjZ0M3ZhQXVCaHY4bThvd2R0dmZuZm1Xc3hTVWJ5?= =?utf-8?B?R0xSOXVHc2I5K0s2RjJyRXd4T3o1NkJocFVxUjRPT1NIQkthVWFCNkFYdGw5?= =?utf-8?B?SGdodFQ2TEIvaTFDZDhkL21tUDlNMXRBNkVVVmlnSTFoUENwKyswQm4xcWV5?= =?utf-8?B?Yi81dHRReWUxeTIxamRsZzRlRW1BMWd5bXpkMzlyY1RPdkFSSFRTQzJCN2JN?= =?utf-8?B?bFo2bGt6UkNXblp4eE52OTJ0Qm84NGY1ejNFSjBYU0pTVzhoTWM1YzlPTmhs?= =?utf-8?B?aGtEa2Z1S09zSVJxQmJjWFptZW5oVlJ2Q29rMERqTmdLRjdSVE9TZzhsYVNO?= =?utf-8?B?clVhQ1U3MDVjdDFQQXRQMjhvZ1VRUTFOUHpnY2xHTGFrOXJlVGNqWlVqbVl0?= =?utf-8?B?ejM2WXNxWmxnVXJGTXVQelM2MXpBclpyb3VSOFM1eGM5SVQ3dzVmNjB4d0F2?= =?utf-8?Q?KDg79hxSJMm6qqzv++pJqrkJoI7nu7+1jHHN8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QnhLbjZVYW9iWEY0MThqZlFsR0lUSEtQVkVScE9WOW1iU1V6TGJsdTExN0dm?= =?utf-8?B?ZCtvZWNxZkhSQldycG45MjhiRkh5TXJIOE9NNGJkMkFUNHVVZzRqYng4S3U1?= =?utf-8?B?Z1kyWXF1S3lTN1EyakxIc2hHUnFWTkJNMjZyNEFoeEVCeVNvR3Rxc05RN25w?= =?utf-8?B?TVBGKytvb0Y1YkJhRnBJMFJiMVkwQmxHYTFTQ0thWDVGNWlRU1ZXY0ZuZ1B3?= =?utf-8?B?ZFVTNEptU1VlcS9WWndmNmZqRGJTaDZxOTFxRjdXaHVhdzdNWW5ZZVd5Z2lM?= =?utf-8?B?c0Q3d0JBZVFjRzU0WWgwSGFHQ3pGV3BneklEVVpsNnFWMGI4eHhKQkhjdGpt?= =?utf-8?B?KzMvR2xVNUNleG12eHh0RVBWbUFSelRWZGNkSGVrd0FPdVorWXBqazd4eExM?= =?utf-8?B?Um03RkNkZEVSenBYOXA5anVheW9DY3EyeXprUW1oNmJibW43RzIzSWZONGxY?= =?utf-8?B?RWhEaHRLWllKZWZjNStvV1B4TzJBTU1SVHkzdGI4OXpYRUhBL05RQ2N4RUFh?= =?utf-8?B?bkd4bW15b0hrNC95OGo4Q3Vxc3lZZzg4Tmt0QW8zdklHNE1DWHRwS1h0SC9H?= =?utf-8?B?UVBucjZFWkEyR1FCVDU0VVVCYkluelV4T1RJeHoxbzNBM0JvM05tOHVjSHVv?= =?utf-8?B?WDdrRFdZSkpKZCs5c2FuMTZqdFB5bEpwMG1Qbkt4R0FPVXE3ZFAxNEVkSks3?= =?utf-8?B?ZnBtb3BZRGlNMU8ycDRXcERnS1k3SEpOcno0bGZ3QzdHczBTWEQ4RlhIaDFO?= =?utf-8?B?WUJBS2l1NzRzVGxHQVBKdjFCcTNUQVZIQkZLb0o4UEZSaW14cCsrSHhZeG95?= =?utf-8?B?YS9kb04xVW9LaVVaRTkzYWQ2YlIvK2QzZ1dZMVNuQ1ZmWTgzeGV4Ym0vektZ?= =?utf-8?B?OWpTZnpCdng1bUhVNWpDV1pyMmRDU2RmVWlsZmtIL3g2a3ZBQm9EN3pvWXV3?= =?utf-8?B?bDZJSkZZVGk3VkY1TWJmMEdTU3RDNHFtcDZmVXF3dE81V0hCa2Z4V1I4UlE3?= =?utf-8?B?UTNEcmh6M2JFVCs3ZlJIY3Y0UEpxcEx3OUgwamtsR0laVFRReFcycDl5WWVD?= =?utf-8?B?Q1hDbHByeDd2UlJnbGdTRVBBd0JSQzNkZDE5K2RGMGdVS0pmcmlENG1kRTJX?= =?utf-8?B?OUUvYzVhc1lBQXBFUUJTMVlzZlowWFRKNjAwQUxxb29xYU5EWXIrZVZ1bEhs?= =?utf-8?B?MGZIRVVvVkFDYTR4L2pYZ1ZzS0VZU0hxbXlDZG5aenZMdnU5K0tHWUFpZzZY?= =?utf-8?B?WDEzYzhxOStQV0thNGV0OHZjTThwQmpZQTNxaWVhcm1BTklIWUpaS09NNFBW?= =?utf-8?B?ajdMUUd5Uy9ZS3pZR2FQSk10Z2NNTnlzMnkxVDJJMVdOSnlmaTNRRnZTWkM3?= =?utf-8?B?OE02MEVpOUErT3JYNVFNOUZQTWNDazJMSEd4QytzbmowMHdVWU9MUCtvR01u?= =?utf-8?B?bllydWdQQi9MYzBvZTkyZkRTWW9UWjFlblpIck55bzlMcFVVeHhLVUpiYXJF?= =?utf-8?B?RmsvWnBOM3Z5Z1NGOFA0UHcyenpYYmlOMCtEQ1QrTDVIT2thdUtYMC8yUkJv?= =?utf-8?B?OS9xcnRMNVViZkNEK2ZCYVpvRmVERVp3Q2kzSlpxbkZwR1BnZUtTaUlhSHN1?= =?utf-8?B?dkF3RGovOTBEMEtFTHdHRVU3VjZSbWJ3UlJOSjdSS2pUQUV4bDFxc01MWU8x?= =?utf-8?B?S2lYSWJiM2h5eU9GOXpDVy9YM0l2ZmswSXAzMkYvalk0bG5SKzlPODFyRHBJ?= =?utf-8?B?dmo2OVd3bGROa2J2QXQwTXgyd3pyeURXVGpuckNaamxOWXFCQzg0ejhGWjNu?= =?utf-8?B?bzlValBwbFE2MjNDeXM4RGJSZVhXK2hZOE9GYVlUU21QWWhtTU9qeFQwVEYr?= =?utf-8?B?QThxQ2ttbmRlTGhHRkZVeXYrV0s4MElhY2tTRkxYNUMrVVJLQ3VNWTJMdHB6?= =?utf-8?B?NXp3eXBUYnE3S2FpMW9wMm5lbnVXcWdFYkpVZzh0Z1JubGx2eDFIWDdxMVdQ?= =?utf-8?B?UUNoK0VqdnBlWmlud3IvemRVNkIxcDdpOHVCbzcyL3kwNHhiR09FRHF4YUVh?= =?utf-8?B?VWJOUUgydEFKaitWaTNrYlRqMzRDUHE4bXdsZUFFSUdkTUNCZmpqZ202QW5k?= =?utf-8?Q?ccPQ=3D?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 13296506-3ccd-4866-e351-08dd8bafc7a5 X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 08:35:24.3263 (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: 3cHj80Z6/D4hodQR/KMK1TGBHq7hv2n5XCCoe9C98VZStqB7tOq7RQkO2Ctvddu4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6045 On 05/05/2025 09:35, Oleksii Kurochko wrote: > > On 5/2/25 7:55 PM, Stefano Stabellini wrote: >> On Fri, 2 May 2025, Oleksii Kurochko wrote: >>> Move some parts of Arm's Dom0Less code to be reused by other architectures. >>> At the moment, RISC-V is going to reuse these parts. >>> >>> Move dom0less-build.h from the Arm-specific directory to asm-generic >>> as these header is expected to be the same across acrhictectures with >>> some updates: add the following declaration of construct_domU(), >>> and arch_create_domUs() as there are some parts which are still >>> architecture-specific. >>> >>> Introduce HAS_DOM0LESS to provide ability to enable generic Dom0less >>> code for an architecture. >>> >>> Relocate the CONFIG_DOM0LESS configuration to the common with adding >>> "depends on HAS_DOM0LESS" to not break builds for architectures which >>> don't support CONFIG_DOM0LESS config, especically it would be useful >>> to not provide stubs for construct_domU(), arch_create_domUs() >>> in case of *-randconfig which may set CONFIG_DOM0LESS=y. >>> >>> Move is_dom0less_mode() function to the common code, as it depends on >>> boot modules that are already part of the common code. >>> >>> Move create_domUs() function to the common code with some updates: >>> - Add arch_create_domUs() to cover parsing of arch-specific features, >>> for example, SVE (Scalar Vector Extension ) exists only in Arm. >>> >>> Signed-off-by: Oleksii Kurochko >>> --- >>> It was suggested to change dom0less to predefined domus or similar >>> (https://lore.kernel.org/xen-devel/cd2a3644- >>> c9c6-4e77-9491-2988703906c0@gmail.com/T/ >>> #m1d5e81e5f1faca98a3c51efe4f35af25010edbf0): >>> >>> I decided to go with dom0less name for now as it will require a lot of places to change, >>> including CI's test, and IMO we could do in a separate patch. >>> If it is necessry to do now, I'll be happy to do that in next version of the current >>> patch series. >> I think it is fine to use dom0less for now, it will make the code easier >> to review and it is not necessary to change the name at this point. >> >> The patch looks good to me, except for a couple of minor suggestions I >> have below. I could make them on commit. With those: >> >> Reviewed-by: Stefano Stabellini > > Thanks. > > I will apply the suggestions below (unless they have already been committed by the time I start preparing the new version of the patch series). NIT: please trim down your replies (unless you want to show the bigger context, which is not necessary here) I only skimmed through the patch and noticed you did not add EMACS comment in dom0less-build.c. Please do. ~Michal From xen-devel-bounces@lists.xenproject.org Mon May 05 09:08:51 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 09:08:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975924.1363210 (Exim 4.92) (envelope-from ) id 1uBroZ-0004OY-Sn; Mon, 05 May 2025 09:08:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975924.1363210; Mon, 05 May 2025 09: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 1uBroZ-0004OR-QD; Mon, 05 May 2025 09:08:43 +0000 Received: by outflank-mailman (input) for mailman id 975924; Mon, 05 May 2025 09:08:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBroX-0004OF-SU for xen-devel@lists.xenproject.org; Mon, 05 May 2025 09:08:42 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2060b.outbound.protection.outlook.com [2a01:111:f403:2414::60b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 886caaf4-2990-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 11:08:40 +0200 (CEST) Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) by DM4PR12MB8571.namprd12.prod.outlook.com (2603:10b6:8:187::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8655.22; Mon, 5 May 2025 09:08:34 +0000 Received: from BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::cf66:58ab:47be:4b13%4]) with mapi id 15.20.8699.026; Mon, 5 May 2025 09:08: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" X-Inumbo-ID: 886caaf4-2990-11f0-9eb4-5ba50f476ded ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HF65BuhwTF2xk9MWr83tX5aj/DdLS4QM2kMMhc6eoEYrgVzwUnTAObEaaiT1B+ZFLbgrA1F/J7Itc0Lu4jgi5T8xL0zYwstEqh5fFqPjwTJ3PG5O/4GGuHlNELK+EKE5Dl0UV90D2Kxz+sIh4grFc5xOVi15VJy5JbHdGz6HSTZ0CAiBQsr7GrFwRz9yRCZxqxl/AGNlKyZgRRgZ9ZhXgiXD47tygBmTva7154f1a1qVcU8s5Je4EklpgxlfVO5fTWTXXTFimxpwewHCsQA4td2Zg6139IMWLpDWDRihT/5kVkSGUec3acx6Jj3FeuseOYkHmRrqFc7tLjqJOI/q2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fB+ToReMZ+sEm46yEXf8goUKEDsp2weTO8yY8r014t8=; b=xN9mixoL7c4Qsp31zS6QLgTopCMaXTtfkqydkr+juqpN1SvQQAFERxv6vpx342RA1CT2blIvwQjWmmjGjT286vHqlgIZVFXyZVmK13Kw2YSYM5Z7aHKu9w0SS/xwfPeT8p35Cp3lcfpHc5djczUWynEyMbspLz9gyn7aerhmCXHrDiEIEdns/YQSZsbpO1lcPFUWEjS4gtL/EfuaPjmko6Y+ERj5Dw2ln+d4YX4T8m+kKlMV14ukUzvl3skLRClNdjfICkjhr9O7LYCkcWYkU0iRM9EXnRW9HOcFMb41jFV8EALs9U0sXOtpmfCC5iISZDffWn/VpSjHMOZNZ441lg== 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=fB+ToReMZ+sEm46yEXf8goUKEDsp2weTO8yY8r014t8=; b=D1AihvxAWe2BfpCTura+x/pMbWX8D+aKU82i9nwCSg9d6fXfwClDqQfyk6kSabSwGWGYYyxpRQzfQFp07UUcApBoKdMYkb6i37yyyiL7kkKDMOjw5Xqm8QuBNEKy1HjDUbaXS2N0HIWdImNSNKpeccUEv6r4XeLj96XfFUSQmhU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <468fa57c-7e64-4a52-bfac-1280fbab4aee@amd.com> Date: Mon, 5 May 2025 11:08:29 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/8] asm-generic: move parts of Arm's asm/kernel.h to common code To: Oleksii Kurochko , 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: <0c16f8fb2702db5fd6751c7da347a97caa431002.1746199009.git.oleksii.kurochko@gmail.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <0c16f8fb2702db5fd6751c7da347a97caa431002.1746199009.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR2P281CA0080.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:9a::13) To BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DM4PR12MB8571:EE_ X-MS-Office365-Filtering-Correlation-Id: 4f769ca8-e522-4d75-77c1-08dd8bb469ef X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?QWk3ZEQ1Y3Iwcm00eTdwUXdIQm53ZDhuQnFDWGNPZldaR2dYV0syNTFYL0ho?= =?utf-8?B?SU9lRDMrWWI0REFwNFBROGtDTXpQNVk2ZXMyeWpwWi9zRlN3cG5JMkV5b0d5?= =?utf-8?B?R0hnVUpSRDZsRzg5akZib0w1S0ZWUENLS04xRlA4NlNoQzNmdGRVb1gvMVVC?= =?utf-8?B?dXVBQXIzaElZZ1BmZUxpK3FLUjFvUUw4V0RHK2UvU2x1RHFoN3pDRTdTZWcx?= =?utf-8?B?MDZXamtlL1pGL3NnY1JveTQ4a1NsVm02Z2hjUkliaGZwQUFNdTRpSUNsQ2NR?= =?utf-8?B?bTg2N2M0Rkx5V01kQWg4RVRtSnRENzRVU2o1OG5FUUJFMGhGMjB2YkdLYU5w?= =?utf-8?B?REEyOTlnNUtURjZ1QURvOVJQMzQveTlJTFlscGJVelFHVFlJNjRwRVlmb0VJ?= =?utf-8?B?WXRveUhRbkFLY3Y5ZzBiWnhoWUhTaHlldzloNVlCdVYvRC9xeENpeElYREZx?= =?utf-8?B?Kyt4NW5FYXJ5OVl5Y0QwVXcwYy8vQzMyWTNGUlRGS1FnK0ZoVDFqZXJlT1My?= =?utf-8?B?K0IwL1F0cUpWOXpnek1ucXNMTGRUOG5pd29FZnNWaG4waEdPVHhjUkZJTEx1?= =?utf-8?B?UHd0amVicGVOeXVRVHA1VUZLTlVoSEtnWmxiUmJ0cUVPbzRzZ1Voa2VIMFow?= =?utf-8?B?ZmthK3h2RzZaYkdWcGdBeDJWRmt6YjA3bk00ckRlSVJxVW1sMlY2emFadkF3?= =?utf-8?B?cTRjY1AyQlVJbiszcHdrcHc2elFHNWVLVDVQeWJ6TU1HcUdZVGc3R1NQMDFI?= =?utf-8?B?bXpkdURvS1VSa1Q3akZLZXpOTVUrSFVrcW9MNERIREpweVd3ZVhEa2RMUklN?= =?utf-8?B?OFVYRm5mZnY1bXlGY1JlSFU4RTdwT09ucG5qdzFtWG5vRVAzZFlsc2VhMlVF?= =?utf-8?B?Z2ZQc2kxRkozb05SSzZoYW9mWHVGSmJkU045c2JiS1dZbUZyUlhDVUF5Q1Z6?= =?utf-8?B?aE1QcnlRd0pSOSs1dDc3NTRtWVovM2h5c0FHVGVFWHRnZGZKRmVEaVlwdUFE?= =?utf-8?B?cElXU3YyaUlCU1V4cDczUW1YSTZQQWxrZS9KQTFoUGJGWW9kMzlHaDdQMHho?= =?utf-8?B?dW5jNy8xTm5jcmpVa2gzRThEYnRpTGFKV0lVaHN5cDZyQjBvczRXcGZ2M1gz?= =?utf-8?B?Znc3SnRxelRpamxJYkx0TDNlZEZYUlBhanN1aGgwbisvWHJ5K1BvWmdWdGVn?= =?utf-8?B?Tm1tWWQ0OWlTM0cwTUprekZDUkFGWERSM2VxMmcwUWp6eUErZnhmRWtWQlhU?= =?utf-8?B?NUp4cDNMVVRmeXhsRzFscXM4NUQ0K1JoRzhwMG16SHAxcjd4eUVvRzZzMitP?= =?utf-8?B?ZEVkd3N6RHNNeHlqckV1dGpvTTBadGttRWRqTFprQ1BsUm96S0xINm5RMjhR?= =?utf-8?B?VnVYeDZxZ3MybUVDMW1uRE16SUhpQmhZS2E4NUN1Njl5WjVMZktYZHhQNnVm?= =?utf-8?B?VFROTyt6czJQK2VldzlCcjdQeDh6MXcvNlBEeGZnZG1BSUlpeWZoTll3bjJu?= =?utf-8?B?ZDYvRGdMbS8wTlpVcitUT25leVNZTzVpQlMxUUZBdngvWmxYaUFiTDFPc3NK?= =?utf-8?B?VjVmeUVqUlkxWkx1aVM2OTR3R21wQmo4emNJd1RMemNPTWtpVU9BUmZBdW1J?= =?utf-8?B?Qllaa1E2M2ZIOGJPeGxnVGdnU0gwTS96c3FiSFNXYVBhQzFXVXRnTTdLTVdy?= =?utf-8?B?b1JxdVc2aXpwMCtObldxOWxUeFc2a2JLMkhFbzlNQVkzQ2J6enoxdThQQjZZ?= =?utf-8?B?dHFpWUxQR1Nib1Vsc2pKd1dMTDRIMWJLUGljUTcwNUdTWEozaHhUZUtJcWFW?= =?utf-8?B?WVlsa1crVWEyOGtLTEQxTzVZU1p4bjZWR0RGOG1kZHprdUdid05wdUFNYWFY?= =?utf-8?B?QVU1VkcrQk9kbWR6MGRDazkrWms3MXgxWEtzRmM3TWVaYVE9PQ==?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NnBId0QrZmcvR3hOTnFyTHVndDdvWGw5WThFRzhydDh1ZDJYL2wreDNaSm40?= =?utf-8?B?TitoMmNkeTFyMlkrZjZia2JrWTNEUDhTeGFBUVRnYjVWMEtYeEpWRHhrVENX?= =?utf-8?B?aGo2Y3ZIQ1ZOLzR3clUySkxMODRCY3NMVSt5WkVyZ0JUVTFSR3RBQUpJZGlh?= =?utf-8?B?aVFJcEJ5Rzd2R2FUZkJzMEdNVXZzVkdEOXZqeEVmVnB3RGdKZERrd3Z2VXBa?= =?utf-8?B?Uys2djV3MmtOSUdhRjJONVRnN0IxMzN0K3UzWlpLQkZlSzh0dXpMRmo2OTZU?= =?utf-8?B?dWhQQUl3VlJOR25zWXdHb2RPNi96ZVZwL2ZYNm9JV2lvejRUWmRxU3JmdmRT?= =?utf-8?B?NXUzRUUza1ZsanZpRncva2RTUU12R0drcFlyd0JSZkhBSHRJWlgxb2NLaFk3?= =?utf-8?B?cEtaVXc4YU42ZkI1NWpLdU1vVkFwY1l4SGJxcjl4M0tHME5qeE1YYTFma256?= =?utf-8?B?R3pGUTlzYzhXRHVXUU03NWVycG5iaitZZlRyY1JrM3hySU9OMW9sQmdTRHY5?= =?utf-8?B?aHFISnhidFpMRXhoNVA5bmVpb0g2UTN0UmtBOVlST1VrbGRQc3BxOW9yVk5N?= =?utf-8?B?R3EzRGVsWXV4bDNBNjBTV0ZSQU1hTEVoa3lOWTNJRVJUTnlwYWFPZGlsbW8w?= =?utf-8?B?emI5RWxMR2NzZk8ycWlkTjVTOUxLNElFRklKd0dzcUlZZFNQM05acC96SmZ0?= =?utf-8?B?MEpYT1Jrblp4dzNoMjIvUW1iUHRkcGIwd3NZNlZDRFRweEtsNDBNUGpVSEVo?= =?utf-8?B?elFQK0VQbFYwbi9ybkpackoxdjIza29VUFZ6S1FqZjNMTENwSmNLZ2dKNUZY?= =?utf-8?B?TlExYm9aM3FQbFE5Tlc0TnhPdFBMeTVxNEdmSWZVYkxYSGNFdHNwNm44Sm9p?= =?utf-8?B?S3R1Q2tYVElVREM5OVVmYWs1RjhabDY3Mk9LemJvMzdKV2VyejBER0JPT0Rl?= =?utf-8?B?MnBNdm54dU5iZ3Z0SlJBalpGSTNNZkhOc092Wk1Sc053MXp3dkcxTDZTY1N6?= =?utf-8?B?cXJVU3V0Q000TmpHSkNrSUQrZ0VwcVNoYnMwRWJYeFY2dmFKQW9MbVh4cXdQ?= =?utf-8?B?K1BoNjNmQjFsV0VNY3I0bk9KL0Jvem41b05nSzBWc2VQSkpJN3dNaUpuNWpS?= =?utf-8?B?Z2ljcmMrMnZmb2tKZFpXa01naVVaYjlHblpBTWVnNnVoY2ZPN0d4S3hqM3Ix?= =?utf-8?B?ZTNWWDRHanBYMUxYSUFMa2g5QkxPUjhnWlVzVUFHaitPOEZibkpCVlZ5OHpa?= =?utf-8?B?c295SXBZQVdldjMzR01waUhyMmpTdVdCSTV4eU13djVlTDlBelpRcG1rNHlr?= =?utf-8?B?ZGdlaTF4YmxEVEJXV0ViT0FJM1cwZVcwL0VMRnZmL2NqMTRWNWJ1dVlDbDdo?= =?utf-8?B?U3REN0w1YzE0a2EyQ3NaeG9QYXdXMFpuSXdnSUphbWxoUWxaeWF3MEw3V29s?= =?utf-8?B?bG1KM2t0eG9UNVpmUTJjSGVSbFhGd1hSTWhCZExrbktQYUU2OWFsNnZlTDFJ?= =?utf-8?B?Z1JwWmVQbHowUjJtZFZpRHJ3eGRhaHdvY2IzSUZCRVZaaHZKT1h6aWN6aWFj?= =?utf-8?B?VXVjcEhMcWpuWnZ0R09tYnNuZHVKOW90RS9SdW9sUXY2NklRa0F4SlhjcGJa?= =?utf-8?B?b1pNUkMxemx4Y0M0RFFnS25yRmowVmo4MThxNVREV2JTVXo5ekk0a2IrSitv?= =?utf-8?B?TjJaMGJZYkNwVEgxeHFWbVpOSE04K01yRVJlVlM5MGxzbXBkNzFmT2hVaU9X?= =?utf-8?B?MU5SdWZETHNYSzZnVE5HR1lBbE9CS1llYkNkTDN1KzJzL1E0WGlVZUc4V0xt?= =?utf-8?B?bitHQ1o2TExnU0J0ZDhEaHFHN0cxRXZUbUNGdG9MWEI2aGQ0ODRnUEhKTWpS?= =?utf-8?B?MVpieXZoRFZyVmxNU01wM3pHM0tDc0d4YkdBd0NlbVcrMWVlenR5alNVT3lD?= =?utf-8?B?anpOdkdWUnUzbCsySll3SmlkRFJidnZ6Tlg5Q05zdUdUOGF4cjJ2dXdaVTVS?= =?utf-8?B?RkNpbkZuTlhVbXNmS0xIQnY5TlREcUVYTHIwYTRneVZqVldhQlpWTEhvdURH?= =?utf-8?B?VzN1UXVXR05yUDErbjRHMUo0YjJweXJtMUdyOU55and4aWVWNVhGL0hoTXk1?= =?utf-8?Q?zNNY=3D?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f769ca8-e522-4d75-77c1-08dd8bb469ef X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 09:08:34.6375 (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: nTXJK/7z/ySWWdU89UDxz7+JhRgnIQXCN2HqsbI/KzFwlvURn9tyJVUihNCbXxky X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB8571 On 02/05/2025 18:22, Oleksii Kurochko wrote: > Move the following parts to common with the following changes: > - struct kernel_info: > - Create arch_kernel_info for arch specific kernel information. > At the moment, it contains domain_type for Arm. > - Rename vpl011 to vuart to have more generic name suitable for other archs. Why do you want to make it common? At the moment it referres to vpl011 which is Arm specific, so it would be better to move it to arch specific struct. Also, there can be more than one emulated UART (especially if you want to make the parsing of vuart common), in which case enum would be the best fit. Also, one remark... [...] > diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h > new file mode 100644 > index 0000000000..c81e759423 > --- /dev/null > +++ b/xen/include/xen/fdt-kernel.h > @@ -0,0 +1,133 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * For Kernel image loading. > + * > + * Copyright (C) 2011 Citrix Systems, Inc. > + */ > +#ifndef __XEN_FDT_KERNEL_H__ > +#define __XEN_FDT_KERNEL_H__ > + > +#include > +#include > +#include > + > +#if __has_include() > +# include > +#endif > + > +struct kernel_info { > + struct domain *d; > + > + void *fdt; /* flat device tree */ > + paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */ > + struct meminfo mem; > +#ifdef CONFIG_STATIC_SHM > + struct shared_meminfo shm_mem; > +#endif > + > + /* kernel entry point */ > + paddr_t entry; > + > + /* grant table region */ > + paddr_t gnttab_start; > + paddr_t gnttab_size; > + > + /* boot blob load addresses */ > + const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule; > + const char* cmdline; > + paddr_t dtb_paddr; > + paddr_t initrd_paddr; > + > + /* Enable uart emulation */ > + bool vuart; > + > + /* Enable/Disable PV drivers interfaces */ > + uint16_t dom0less_feature; > + > + /* Interrupt controller phandle */ > + uint32_t phandle_intc; > + > + /* loader to use for this kernel */ > + void (*load)(struct kernel_info *info); > + > + /* loader specific state */ > + union { > + struct { > + paddr_t kernel_addr; > + paddr_t len; > +#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64) > + paddr_t text_offset; /* 64-bit Image only */ > +#endif > + paddr_t start; /* Must be 0 for 64-bit Image */ > + } zimage; > + }; > + > +#if __has_include() > + struct arch_kernel_info arch; > +#endif > +}; > + > +static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo) > +{ > + return container_of(&kinfo->mem.common, struct membanks, common); > +} > + > +static inline const struct membanks * > +kernel_info_get_mem_const(const struct kernel_info *kinfo) > +{ > + return container_of(&kinfo->mem.common, const struct membanks, common); > +} > + > +#ifndef KERNEL_INFO_SHM_MEM_INIT > + > +#ifdef CONFIG_STATIC_SHM > +#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS, > +#else > +#define KERNEL_INFO_SHM_MEM_INIT > +#endif > + > +#endif /* KERNEL_INFO_SHM_MEM_INIT */ > + > +#ifndef KERNEL_INFO_INIT > + > +#define KERNEL_INFO_INIT \ > +{ \ > + .mem.common.max_banks = NR_MEM_BANKS, \ > + KERNEL_INFO_SHM_MEM_INIT \ > +} > + > +#endif /* KERNEL_INFO_INIT */ > + > +/* > + * Probe the kernel to detemine its type and select a loader. > + * > + * Sets in info: > + * ->type Arm specific information in generic comment. ~Michal From xen-devel-bounces@lists.xenproject.org Mon May 05 09:23:22 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 09:23:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975940.1363221 (Exim 4.92) (envelope-from ) id 1uBs2g-0007Nk-5o; Mon, 05 May 2025 09:23:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975940.1363221; Mon, 05 May 2025 09: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 1uBs2g-0007Nd-1g; Mon, 05 May 2025 09:23:18 +0000 Received: by outflank-mailman (input) for mailman id 975940; Mon, 05 May 2025 09:23:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBs2e-0007NW-9t for xen-devel@lists.xenproject.org; Mon, 05 May 2025 09:23:16 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 91a637b7-2992-11f0-9eb4-5ba50f476ded; Mon, 05 May 2025 11:23:13 +0200 (CEST) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-ace94273f0dso931734466b.3 for ; Mon, 05 May 2025 02:23:13 -0700 (PDT) Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad1894c02b8sm458575266b.118.2025.05.05.02.23.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 May 2025 02:23: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" X-Inumbo-ID: 91a637b7-2992-11f0-9eb4-5ba50f476ded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746436993; x=1747041793; darn=lists.xenproject.org; h=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; bh=hyRH4wkSwVkkqxc1YM8QButqkjlGpIkyhh5Neaboy0c=; b=OVmafuRyLZ4hdKlk75FSQDrwEiMYkz0nHi3n2QiXpc3cZKktG5pLbuxiiCeCJZ2nZp s2jIWIEphU5tFgk1ZMlH02KWhsrH67kujH4vLdLDhAMz8cdrQEsWA52dfBVtGp7UN1LX hkDEO7IkPifCIhYLrxehqQN7YnhMAokWjMjOaMMA/7X9JFTFxkWXr6ocFNFXbOF2RP7e a4tONFhkBSyiWT+5venPoEdQQp4RqYt2pDK/6+O5q73ViVx+e1T3B/PMZ0gOHqGHNR+T xjWJmA4AB7bbnljzkjEReSOHudi8ZhDs0L4zmR1sE+Yq8rRlNZjcXc5l1QzdvtfQStU+ L4rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746436993; x=1747041793; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=hyRH4wkSwVkkqxc1YM8QButqkjlGpIkyhh5Neaboy0c=; b=uVjqXwVe+uQafM+qj2/2kssSzw9jQZsF/v7vs1ZpvdnDZoP3tCxKI/TGHpsuQXlCQu cHlrSna66JDcKPxGo1D08/m/VLsxtZoKsD2MzxDB8w4ntp6PQWK3dQnsGmtm2sxBw1aJ h1drQqleHGPFWjwngXTu4xram9IDeQnK9tKb1TUnWfCbCPx1otxLdTdCR1Ax+d0rRk59 M/4xz0FzdrYEu7AULyzIv2lnohPkP7iYVpRZxpl/QQ8b+2RsrGGpfRq3sCLRy5wV2aWZ y0g1qenejlFiwiwmjgm1MWcnbzciiEs0N+upArCp6iHBfQ016Au5WCPhQ2G9yg8Wejq4 hNPQ== X-Gm-Message-State: AOJu0YzyZLEijN4L1FpdZZH6spUYJRzwhtPUk5ba+m2ubDAwAOm15nOl 0bWuTyd5lMCkDOSGK4bkyh+Z0fFJDgBT57EmG+hmmZB20I3ViA95 X-Gm-Gg: ASbGncs9A9+gOcXo3/Ef02mOwLPvEMomZy4zm7LqbKoIAx8oq8TTlrEQ1RDqA3aJYcM mdV3NKny+j6CTRs2eL/vIS06tRNPCDjJgM1ccxDDDR5NedxXUWJkUkgSqLqVEBgrUlfQx6rSzm5 +ww0wXXyKTMDC0uGnor9+beWEA6gXnf4YowZBSf4KEr5thLvImoSgaQ/rGNYc6XgDPd4c0MKG5B dzU08s/r6bS8Kcq7xFswgz03SH67oAidHRSEDdmAaWxCN9FCF4+LG6Pv/+AL2SnCAkOpjnd85a3 XOTbSJI6kHVA0wqpM9lVFXkE9Srp3N+p0rk/E+/DcqMizmM2fP8GOW0Vamw/tULVitVS3JfReQ/ CNmeUDCyuinsX3eyF X-Google-Smtp-Source: AGHT+IEEEt5ujVIKkt/LPd6tsQHkcUF59W3zqc9z12xYLKCWBHYsUQDDYdbSil2O2X1NzWUlXUoF7g== X-Received: by 2002:a17:906:f58e:b0:ac3:26ff:11a0 with SMTP id a640c23a62f3a-ad1a4aa5d4bmr662095866b.38.1746436992568; Mon, 05 May 2025 02:23:12 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------dc0pdxlLpld0MN514z460mo9" Message-ID: <9349ea00-0c22-48fe-965b-a4f709d8fb19@gmail.com> Date: Mon, 5 May 2025 11:23:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 6/8] xen/common: dom0less: introduce common kernel.c To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <4f178bd0e46adf3d4c7a91d6cdd4a0910dbef490.1746199009.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: This is a multi-part message in MIME format. --------------dc0pdxlLpld0MN514z460mo9 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/2/25 9:36 PM, Stefano Stabellini wrote: > On Fri, 2 May 2025, Oleksii Kurochko wrote: >> The following functions don't have arch specific things so it is moved to >> common: >> - kernel_prboe() >> - kernel_load() >> - output_length() >> >> Functions necessary for dom0less are only moved. >> >> The following changes are done: >> - Swap __init and return type of kernel_decompress() function to be >> consistent with defintions of functions in other files. The same >> for output_length(). >> - Wrap by "ifdef CONFIG_ARM" the call of kernel_uimage_probe() in >> kernel_probe() as uImage isn't really used nowadays thereby leave >> kernel_uimage_probe() call here just for compatability with Arm code. >> - Introduce kernel_zimage_probe() to cover the case that arch can have >> different zimage header. >> - Add ASSERT() for kernel_load() to check that it argument isn't NULL. >> - Make kernel_uimage_probe() non-static in Arm's code as it is used in >> common/kernel.c. >> >> Introduce CONFIG_DOMAIN_BUILD_HELPERS to not provide stubs for archs >> which don't provide enough functionality to enable it. >> Select CONFIG_DOMAIN_BUILD_HELPERS for CONFIG_ARM as only Arm supports >> it, at the moment. >> >> Signed-off-by: Oleksii Kurochko >> --- >> Change in v3: >> - Empty line after license tag for newly introduced files. >> --- >> Change in v2: >> - Drop inclusion of asm/kernel.h in kernel.c as everything necessary has >> been moved to xen/fdt-kernel.h. >> --- >> xen/arch/arm/Kconfig | 1 + >> xen/arch/arm/kernel.c | 221 +--------------------------- >> xen/common/Kconfig | 9 +- >> xen/common/device-tree/Makefile | 1 + >> xen/common/device-tree/kernel.c | 242 +++++++++++++++++++++++++++++++ >> xen/include/asm-generic/kernel.h | 141 ++++++++++++++++++ >> xen/include/xen/fdt-kernel.h | 13 ++ >> 7 files changed, 412 insertions(+), 216 deletions(-) >> create mode 100644 xen/common/device-tree/kernel.c >> create mode 100644 xen/include/asm-generic/kernel.h >> >> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig >> index d0e0a7753c..3321d89068 100644 >> --- a/xen/arch/arm/Kconfig >> +++ b/xen/arch/arm/Kconfig >> @@ -11,6 +11,7 @@ config ARM_64 >> >> config ARM >> def_bool y >> + select DOMAIN_BUILD_HELPERS >> select FUNCTION_ALIGNMENT_4B >> select GENERIC_UART_INIT >> select HAS_ALTERNATIVE if HAS_VMAP >> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c >> index 5759a3470a..1168c21e97 100644 >> --- a/xen/arch/arm/kernel.c >> +++ b/xen/arch/arm/kernel.c >> @@ -163,105 +163,6 @@ static void __init kernel_zimage_load(struct kernel_info *info) >> iounmap(kernel); >> } >> >> -static __init uint32_t output_length(char *image, unsigned long image_len) >> -{ >> - return *(uint32_t *)&image[image_len - 4]; >> -} >> - >> -static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset) >> -{ >> - char *output, *input; >> - char magic[2]; >> - int rc; >> - unsigned int kernel_order_out; >> - paddr_t output_size; >> - struct page_info *pages; >> - mfn_t mfn; >> - int i; >> - paddr_t addr = mod->start; >> - paddr_t size = mod->size; >> - >> - if ( size < offset ) >> - return -EINVAL; >> - >> - /* >> - * It might be that gzip header does not appear at the start address >> - * (e.g. in case of compressed uImage) so take into account offset to >> - * gzip header. >> - */ >> - addr += offset; >> - size -= offset; >> - >> - if ( size < 2 ) >> - return -EINVAL; >> - >> - copy_from_paddr(magic, addr, sizeof(magic)); >> - >> - /* only gzip is supported */ >> - if ( !gzip_check(magic, size) ) >> - return -EINVAL; >> - >> - input = ioremap_cache(addr, size); >> - if ( input == NULL ) >> - return -EFAULT; >> - >> - output_size = output_length(input, size); >> - kernel_order_out = get_order_from_bytes(output_size); >> - pages = alloc_domheap_pages(NULL, kernel_order_out, 0); >> - if ( pages == NULL ) >> - { >> - iounmap(input); >> - return -ENOMEM; >> - } >> - mfn = page_to_mfn(pages); >> - output = vmap_contig(mfn, 1 << kernel_order_out); >> - >> - rc = perform_gunzip(output, input, size); >> - clean_dcache_va_range(output, output_size); >> - iounmap(input); >> - vunmap(output); >> - >> - if ( rc ) >> - { >> - free_domheap_pages(pages, kernel_order_out); >> - return rc; >> - } >> - >> - mod->start = page_to_maddr(pages); >> - mod->size = output_size; >> - >> - /* >> - * Need to free pages after output_size here because they won't be >> - * freed by discard_initial_modules >> - */ >> - i = PFN_UP(output_size); >> - for ( ; i < (1 << kernel_order_out); i++ ) >> - free_domheap_page(pages + i); >> - >> - /* >> - * When using static heap feature, don't give bootmodules memory back to >> - * the heap allocator >> - */ >> - if ( using_static_heap ) >> - return 0; >> - >> - /* >> - * When freeing the kernel, we need to pass the module start address and >> - * size as they were before taking an offset to gzip header into account, >> - * so that the entire region will be freed. >> - */ >> - addr -= offset; >> - size += offset; >> - >> - /* >> - * Free the original kernel, update the pointers to the >> - * decompressed kernel >> - */ >> - fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0); >> - >> - return 0; >> -} >> - >> /* >> * Uimage CPU Architecture Codes >> */ >> @@ -274,8 +175,8 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset) >> /* >> * Check if the image is a uImage and setup kernel_info >> */ >> -static int __init kernel_uimage_probe(struct kernel_info *info, >> - struct bootmodule *mod) >> +int __init kernel_uimage_probe(struct kernel_info *info, >> + struct bootmodule *mod) >> { >> struct { >> __be32 magic; /* Image Header Magic Number */ >> @@ -505,130 +406,20 @@ static int __init kernel_zimage32_probe(struct kernel_info *info, >> return 0; >> } >> >> -int __init kernel_probe(struct kernel_info *info, >> - const struct dt_device_node *domain) >> +int __init kernel_zimage_probe(struct kernel_info *info, paddr_t addr, >> + paddr_t size) >> { >> - struct bootmodule *mod = NULL; >> - struct bootcmdline *cmd = NULL; >> - struct dt_device_node *node; >> - u64 kernel_addr, initrd_addr, dtb_addr, size; >> int rc; >> >> - /* >> - * We need to initialize start to 0. This field may be populated during >> - * kernel_xxx_probe() if the image has a fixed entry point (for e.g. >> - * uimage.ep). >> - * We will use this to determine if the image has a fixed entry point or >> - * the load address should be used as the start address. >> - */ >> - info->entry = 0; >> - >> - /* domain is NULL only for the hardware domain */ >> - if ( domain == NULL ) >> - { >> - ASSERT(is_hardware_domain(info->d)); >> - >> - mod = boot_module_find_by_kind(BOOTMOD_KERNEL); >> - >> - info->kernel_bootmodule = mod; >> - info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK); >> - >> - cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL); >> - if ( cmd ) >> - info->cmdline = &cmd->cmdline[0]; >> - } >> - else >> - { >> - const char *name = NULL; >> - >> - dt_for_each_child_node(domain, node) >> - { >> - if ( dt_device_is_compatible(node, "multiboot,kernel") ) >> - { >> - u32 len; >> - const __be32 *val; >> - >> - val = dt_get_property(node, "reg", &len); >> - dt_get_range(&val, node, &kernel_addr, &size); >> - mod = boot_module_find_by_addr_and_kind( >> - BOOTMOD_KERNEL, kernel_addr); >> - info->kernel_bootmodule = mod; >> - } >> - else if ( dt_device_is_compatible(node, "multiboot,ramdisk") ) >> - { >> - u32 len; >> - const __be32 *val; >> - >> - val = dt_get_property(node, "reg", &len); >> - dt_get_range(&val, node, &initrd_addr, &size); >> - info->initrd_bootmodule = boot_module_find_by_addr_and_kind( >> - BOOTMOD_RAMDISK, initrd_addr); >> - } >> - else if ( dt_device_is_compatible(node, "multiboot,device-tree") ) >> - { >> - uint32_t len; >> - const __be32 *val; >> - >> - val = dt_get_property(node, "reg", &len); >> - if ( val == NULL ) >> - continue; >> - dt_get_range(&val, node, &dtb_addr, &size); >> - info->dtb_bootmodule = boot_module_find_by_addr_and_kind( >> - BOOTMOD_GUEST_DTB, dtb_addr); >> - } >> - else >> - continue; >> - } >> - name = dt_node_name(domain); >> - cmd = boot_cmdline_find_by_name(name); >> - if ( cmd ) >> - info->cmdline = &cmd->cmdline[0]; >> - } >> - if ( !mod || !mod->size ) >> - { >> - printk(XENLOG_ERR "Missing kernel boot module?\n"); >> - return -ENOENT; >> - } >> - >> - printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n", >> - info->d, info->kernel_bootmodule->start); >> - if ( info->initrd_bootmodule ) >> - printk("Loading ramdisk from boot module @ %"PRIpaddr"\n", >> - info->initrd_bootmodule->start); >> - >> - /* >> - * uImage header always appears at the top of the image (even compressed), >> - * so it needs to be probed first. Note that in case of compressed uImage, >> - * kernel_decompress is called from kernel_uimage_probe making the function >> - * self-containing (i.e. fall through only in case of a header not found). >> - */ >> - rc = kernel_uimage_probe(info, mod); >> - if ( rc != -ENOENT ) >> - return rc; >> - >> - /* >> - * If it is a gzip'ed image, 32bit or 64bit, uncompress it. >> - * At this point, gzip header appears (if at all) at the top of the image, >> - * so pass 0 as an offset. >> - */ >> - rc = kernel_decompress(mod, 0); >> - if ( rc && rc != -EINVAL ) >> - return rc; >> - >> #ifdef CONFIG_ARM_64 >> - rc = kernel_zimage64_probe(info, mod->start, mod->size); >> + rc = kernel_zimage64_probe(info, addr, size); >> if (rc < 0) >> #endif >> - rc = kernel_zimage32_probe(info, mod->start, mod->size); >> + rc = kernel_zimage32_probe(info, addr, size); >> >> return rc; >> } >> >> -void __init kernel_load(struct kernel_info *info) >> -{ >> - info->load(info); >> -} >> - >> /* >> * Local variables: >> * mode: C >> diff --git a/xen/common/Kconfig b/xen/common/Kconfig >> index be38abf9e1..38981f1d11 100644 >> --- a/xen/common/Kconfig >> +++ b/xen/common/Kconfig >> @@ -14,13 +14,20 @@ config CORE_PARKING >> >> config DOM0LESS_BOOT >> bool "Dom0less boot support" if EXPERT >> - depends on HAS_DOM0LESS >> + depends on HAS_DOM0LESS && DOMAIN_BUILD_HELPERS >> default y >> help >> Dom0less boot support enables Xen to create and start domU guests during >> Xen boot without the need of a control domain (Dom0), which could be >> present anyway. >> >> +config DOMAIN_BUILD_HELPERS >> + bool >> + help >> + Introduce functions necessary for working with domain creation, kernel, >> + etc. As an examples, these type of functions are going to be used by >> + CONFIG_DOM0LESS_BOOT. > NIT: If possible, I would make this option a silent option that cannot > be manually enabled/disabled. As a choice to the user, I think > DOM0LESS_BOOT is sufficient. Sure, I'll drop 'help' then and add 'select DOMAIN_BUILD_HELPERS' in DOM0LESS_BOOT config. > > >> config GRANT_TABLE >> bool "Grant table support" if EXPERT >> default y >> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile >> index f3dafc9b81..e88a4d5799 100644 >> --- a/xen/common/device-tree/Makefile >> +++ b/xen/common/device-tree/Makefile >> @@ -4,3 +4,4 @@ obj-y += device-tree.o >> obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o >> obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o >> obj-y += intc.o >> +obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o >> diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c >> new file mode 100644 >> index 0000000000..1bf3bbf64e >> --- /dev/null >> +++ b/xen/common/device-tree/kernel.c >> @@ -0,0 +1,242 @@ >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> + >> +static uint32_t __init output_length(char *image, unsigned long image_len) >> +{ >> + return *(uint32_t *)&image[image_len - 4]; >> +} >> + >> +int __init kernel_decompress(struct bootmodule *mod, uint32_t offset) >> +{ >> + char *output, *input; >> + char magic[2]; >> + int rc; >> + unsigned int kernel_order_out; >> + paddr_t output_size; >> + struct page_info *pages; >> + mfn_t mfn; >> + int i; >> + paddr_t addr = mod->start; >> + paddr_t size = mod->size; >> + >> + if ( size < offset ) >> + return -EINVAL; >> + >> + /* >> + * It might be that gzip header does not appear at the start address >> + * (e.g. in case of compressed uImage) so take into account offset to >> + * gzip header. >> + */ >> + addr += offset; >> + size -= offset; >> + >> + if ( size < 2 ) >> + return -EINVAL; >> + >> + copy_from_paddr(magic, addr, sizeof(magic)); >> + >> + /* only gzip is supported */ >> + if ( !gzip_check(magic, size) ) >> + return -EINVAL; >> + >> + input = ioremap_cache(addr, size); >> + if ( input == NULL ) >> + return -EFAULT; >> + >> + output_size = output_length(input, size); >> + kernel_order_out = get_order_from_bytes(output_size); >> + pages = alloc_domheap_pages(NULL, kernel_order_out, 0); >> + if ( pages == NULL ) >> + { >> + iounmap(input); >> + return -ENOMEM; >> + } >> + mfn = page_to_mfn(pages); >> + output = vmap_contig(mfn, 1 << kernel_order_out); >> + >> + rc = perform_gunzip(output, input, size); >> + clean_dcache_va_range(output, output_size); >> + iounmap(input); >> + vunmap(output); >> + >> + if ( rc ) >> + { >> + free_domheap_pages(pages, kernel_order_out); >> + return rc; >> + } >> + >> + mod->start = page_to_maddr(pages); >> + mod->size = output_size; >> + >> + /* >> + * Need to free pages after output_size here because they won't be >> + * freed by discard_initial_modules >> + */ >> + i = PFN_UP(output_size); >> + for ( ; i < (1 << kernel_order_out); i++ ) >> + free_domheap_page(pages + i); >> + >> + /* >> + * When using static heap feature, don't give bootmodules memory back to >> + * the heap allocator >> + */ >> + if ( using_static_heap ) >> + return 0; >> + >> + /* >> + * When freeing the kernel, we need to pass the module start address and >> + * size as they were before taking an offset to gzip header into account, >> + * so that the entire region will be freed. >> + */ >> + addr -= offset; >> + size += offset; >> + >> + /* >> + * Free the original kernel, update the pointers to the >> + * decompressed kernel >> + */ >> + fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0); >> + >> + return 0; >> +} >> + >> +int __init kernel_probe(struct kernel_info *info, >> + const struct dt_device_node *domain) >> +{ >> + struct bootmodule *mod = NULL; >> + struct bootcmdline *cmd = NULL; >> + struct dt_device_node *node; >> + u64 kernel_addr, initrd_addr, dtb_addr, size; >> + int rc; >> + >> + /* >> + * We need to initialize start to 0. This field may be populated during >> + * kernel_xxx_probe() if the image has a fixed entry point (for e.g. >> + * uimage.ep). >> + * We will use this to determine if the image has a fixed entry point or >> + * the load address should be used as the start address. >> + */ >> + info->entry = 0; >> + >> + /* domain is NULL only for the hardware domain */ >> + if ( domain == NULL ) >> + { >> + ASSERT(is_hardware_domain(info->d)); >> + >> + mod = boot_module_find_by_kind(BOOTMOD_KERNEL); >> + >> + info->kernel_bootmodule = mod; >> + info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK); >> + >> + cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL); >> + if ( cmd ) >> + info->cmdline = &cmd->cmdline[0]; >> + } >> + else >> + { >> + const char *name = NULL; >> + >> + dt_for_each_child_node(domain, node) >> + { >> + if ( dt_device_is_compatible(node, "multiboot,kernel") ) >> + { >> + u32 len; >> + const __be32 *val; >> + >> + val = dt_get_property(node, "reg", &len); >> + dt_get_range(&val, node, &kernel_addr, &size); >> + mod = boot_module_find_by_addr_and_kind( >> + BOOTMOD_KERNEL, kernel_addr); >> + info->kernel_bootmodule = mod; >> + } >> + else if ( dt_device_is_compatible(node, "multiboot,ramdisk") ) >> + { >> + u32 len; >> + const __be32 *val; >> + >> + val = dt_get_property(node, "reg", &len); >> + dt_get_range(&val, node, &initrd_addr, &size); >> + info->initrd_bootmodule = boot_module_find_by_addr_and_kind( >> + BOOTMOD_RAMDISK, initrd_addr); >> + } >> + else if ( dt_device_is_compatible(node, "multiboot,device-tree") ) >> + { >> + uint32_t len; >> + const __be32 *val; >> + >> + val = dt_get_property(node, "reg", &len); >> + if ( val == NULL ) >> + continue; >> + dt_get_range(&val, node, &dtb_addr, &size); >> + info->dtb_bootmodule = boot_module_find_by_addr_and_kind( >> + BOOTMOD_GUEST_DTB, dtb_addr); >> + } >> + else >> + continue; >> + } >> + name = dt_node_name(domain); >> + cmd = boot_cmdline_find_by_name(name); >> + if ( cmd ) >> + info->cmdline = &cmd->cmdline[0]; >> + } >> + if ( !mod || !mod->size ) >> + { >> + printk(XENLOG_ERR "Missing kernel boot module?\n"); >> + return -ENOENT; >> + } >> + >> + printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n", >> + info->d, info->kernel_bootmodule->start); >> + if ( info->initrd_bootmodule ) >> + printk("Loading ramdisk from boot module @ %"PRIpaddr"\n", >> + info->initrd_bootmodule->start); >> + >> + /* >> + * uImage isn't really used nowadays thereby leave kernel_uimage_probe() >> + * call here just for compatability with Arm code. >> + */ >> +#ifdef CONFIG_ARM >> + /* >> + * uImage header always appears at the top of the image (even compressed), >> + * so it needs to be probed first. Note that in case of compressed uImage, >> + * kernel_decompress is called from kernel_uimage_probe making the function >> + * self-containing (i.e. fall through only in case of a header not found). >> + */ >> + rc = kernel_uimage_probe(info, mod); >> + if ( rc != -ENOENT ) >> + return rc; >> +#endif >> + >> + /* >> + * If it is a gzip'ed image, 32bit or 64bit, uncompress it. >> + * At this point, gzip header appears (if at all) at the top of the image, >> + * so pass 0 as an offset. >> + */ >> + rc = kernel_decompress(mod, 0); >> + if ( rc && rc != -EINVAL ) >> + return rc; >> + >> + rc = kernel_zimage_probe(info, mod->start, mod->size); >> + >> + return rc; >> +} >> + >> +void __init kernel_load(struct kernel_info *info) >> +{ >> + ASSERT(info && info->load); >> + >> + info->load(info); >> +} >> diff --git a/xen/include/asm-generic/kernel.h b/xen/include/asm-generic/kernel.h >> new file mode 100644 >> index 0000000000..6857fabb34 >> --- /dev/null >> +++ b/xen/include/asm-generic/kernel.h > This file seems to be a duplicate of the previously introduced > xen/include/xen/fdt-kernel.h ? > > Other than that, I checked the rest of the patch, including all the code > movement, and it looks correct to me. I will drop asm-generic/kernel.h, it was created in the initial version of this patch series before it was suggested to move such header to xen/. And I missed to drop it. Thanks. ~ Oleksii > > > >> @@ -0,0 +1,141 @@ >> +/* >> + * Kernel image loading. >> + * >> + * Copyright (C) 2011 Citrix Systems, Inc. >> + */ >> + >> +#ifndef __ASM_GENERIC_KERNEL_H__ >> +#define __ASM_GENERIC_KERNEL_H__ >> + >> +#include >> +#include >> +#include >> +#include >> + >> +struct kernel_info { >> + struct domain *d; >> + >> + void *fdt; /* flat device tree */ >> + paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */ >> + struct meminfo mem; >> +#ifdef CONFIG_STATIC_SHM >> + struct shared_meminfo shm_mem; >> +#endif >> + >> + /* kernel entry point */ >> + paddr_t entry; >> + >> + /* grant table region */ >> + paddr_t gnttab_start; >> + paddr_t gnttab_size; >> + >> + /* boot blob load addresses */ >> + const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule; >> + const char* cmdline; >> + paddr_t dtb_paddr; >> + paddr_t initrd_paddr; >> + >> + /* Enable uart emulation */ >> + bool vuart; >> + >> + /* Enable/Disable PV drivers interfaces */ >> + uint16_t dom0less_feature; >> + >> + /* Interrupt controller phandle */ >> + uint32_t phandle_intc; >> + >> + /* loader to use for this kernel */ >> + void (*load)(struct kernel_info *info); >> + >> + /* loader specific state */ >> + union { >> + struct { >> + paddr_t kernel_addr; >> + paddr_t len; >> +#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64) >> + paddr_t text_offset; /* 64-bit Image only */ >> +#endif >> + paddr_t start; /* Must be 0 for 64-bit Image */ >> + } zimage; >> + }; >> + >> + struct arch_kernel_info arch; >> +}; >> + >> +static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo) >> +{ >> + return container_of(&kinfo->mem.common, struct membanks, common); >> +} >> + >> +static inline const struct membanks * >> +kernel_info_get_mem_const(const struct kernel_info *kinfo) >> +{ >> + return container_of(&kinfo->mem.common, const struct membanks, common); >> +} >> + >> +#ifndef KERNEL_INFO_SHM_MEM_INIT >> + >> +#ifdef CONFIG_STATIC_SHM >> +#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS, >> +#else >> +#define KERNEL_INFO_SHM_MEM_INIT >> +#endif >> + >> +#endif /* KERNEL_INFO_SHM_MEM_INIT */ >> + >> +#ifndef KERNEL_INFO_INIT >> + >> +#define KERNEL_INFO_INIT \ >> +{ \ >> + .mem.common.max_banks = NR_MEM_BANKS, \ >> + KERNEL_INFO_SHM_MEM_INIT \ >> +} >> + >> +#endif /* KERNEL_INFO_INIT */ >> + >> +/* >> + * Probe the kernel to detemine its type and select a loader. >> + * >> + * Sets in info: >> + * ->type >> + * ->load hook, and sets loader specific variables ->zimage >> + */ >> +int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain); >> + >> +/* >> + * Loads the kernel into guest RAM. >> + * >> + * Expects to be set in info when called: >> + * ->mem >> + * ->fdt >> + * >> + * Sets in info: >> + * ->entry >> + * ->dtb_paddr >> + * ->initrd_paddr >> + */ >> +void kernel_load(struct kernel_info *info); >> + >> +int kernel_decompress(struct bootmodule *mod, uint32_t offset); >> + >> +int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size); >> + >> +/* >> + * uImage isn't really used nowadays thereby leave kernel_uimage_probe() >> + * call here just for compatability with Arm code. >> + */ >> +#ifdef CONFIG_ARM >> +struct bootmodule; >> +int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod); >> +#endif >> + >> +#endif /*__ASM_GENERIC_KERNEL_H__ */ >> + >> +/* >> + * Local variables: >> + * mode: C >> + * c-file-style: "BSD" >> + * c-basic-offset: 4 >> + * indent-tabs-mode: nil >> + * End: >> + */ >> diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h >> index c81e759423..d85324c867 100644 >> --- a/xen/include/xen/fdt-kernel.h >> +++ b/xen/include/xen/fdt-kernel.h >> @@ -121,6 +121,19 @@ int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain); >> */ >> void kernel_load(struct kernel_info *info); >> >> +int kernel_decompress(struct bootmodule *mod, uint32_t offset); >> + >> +int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size); >> + >> +/* >> + * uImage isn't really used nowadays thereby leave kernel_uimage_probe() >> + * call here just for compatability with Arm code. >> + */ >> +#ifdef CONFIG_ARM >> +struct bootmodule; >> +int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod); >> +#endif >> + >> #endif /* __XEN_FDT_KERNEL_H__ */ >> >> /* >> -- >> 2.49.0 >> --------------dc0pdxlLpld0MN514z460mo9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 5/2/25 9:36 PM, Stefano Stabellini wrote:
On Fri, 2 May 2025, Oleksii Kurochko wrote:

The following functions don't have arch specific things so it is moved to
common:
- kernel_prboe()
- kernel_load()
- output_length()

Functions necessary for dom0less are only moved.

The following changes are done:
- Swap __init and return type of kernel_decompress() function to be
  consistent with defintions of functions in other files. The same
  for output_length().
- Wrap by "ifdef CONFIG_ARM" the call of kernel_uimage_probe() in
  kernel_probe() as uImage isn't really used nowadays thereby leave
  kernel_uimage_probe() call here just for compatability with Arm code.
- Introduce kernel_zimage_probe() to cover the case that arch can have
  different zimage header.
- Add ASSERT() for kernel_load() to check that it argument isn't NULL.
- Make kernel_uimage_probe() non-static in Arm's code as it is used in
  common/kernel.c.

Introduce CONFIG_DOMAIN_BUILD_HELPERS to not provide stubs for archs
which don't provide enough functionality to enable it.
Select CONFIG_DOMAIN_BUILD_HELPERS for CONFIG_ARM as only Arm supports
it, at the moment.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Change in v3:
 - Empty line after license tag for newly introduced files.
---
Change in v2:
 - Drop inclusion of asm/kernel.h in kernel.c as everything necessary has
   been moved to xen/fdt-kernel.h.
---
 xen/arch/arm/Kconfig             |   1 +
 xen/arch/arm/kernel.c            | 221 +---------------------------
 xen/common/Kconfig               |   9 +-
 xen/common/device-tree/Makefile  |   1 +
 xen/common/device-tree/kernel.c  | 242 +++++++++++++++++++++++++++++++
 xen/include/asm-generic/kernel.h | 141 ++++++++++++++++++
 xen/include/xen/fdt-kernel.h     |  13 ++
 7 files changed, 412 insertions(+), 216 deletions(-)
 create mode 100644 xen/common/device-tree/kernel.c
 create mode 100644 xen/include/asm-generic/kernel.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index d0e0a7753c..3321d89068 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -11,6 +11,7 @@ config ARM_64
 
 config ARM
 	def_bool y
+	select DOMAIN_BUILD_HELPERS
 	select FUNCTION_ALIGNMENT_4B
 	select GENERIC_UART_INIT
 	select HAS_ALTERNATIVE if HAS_VMAP
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 5759a3470a..1168c21e97 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -163,105 +163,6 @@ static void __init kernel_zimage_load(struct kernel_info *info)
     iounmap(kernel);
 }
 
-static __init uint32_t output_length(char *image, unsigned long image_len)
-{
-    return *(uint32_t *)&image[image_len - 4];
-}
-
-static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset)
-{
-    char *output, *input;
-    char magic[2];
-    int rc;
-    unsigned int kernel_order_out;
-    paddr_t output_size;
-    struct page_info *pages;
-    mfn_t mfn;
-    int i;
-    paddr_t addr = mod->start;
-    paddr_t size = mod->size;
-
-    if ( size < offset )
-        return -EINVAL;
-
-    /*
-     * It might be that gzip header does not appear at the start address
-     * (e.g. in case of compressed uImage) so take into account offset to
-     * gzip header.
-     */
-    addr += offset;
-    size -= offset;
-
-    if ( size < 2 )
-        return -EINVAL;
-
-    copy_from_paddr(magic, addr, sizeof(magic));
-
-    /* only gzip is supported */
-    if ( !gzip_check(magic, size) )
-        return -EINVAL;
-
-    input = ioremap_cache(addr, size);
-    if ( input == NULL )
-        return -EFAULT;
-
-    output_size = output_length(input, size);
-    kernel_order_out = get_order_from_bytes(output_size);
-    pages = alloc_domheap_pages(NULL, kernel_order_out, 0);
-    if ( pages == NULL )
-    {
-        iounmap(input);
-        return -ENOMEM;
-    }
-    mfn = page_to_mfn(pages);
-    output = vmap_contig(mfn, 1 << kernel_order_out);
-
-    rc = perform_gunzip(output, input, size);
-    clean_dcache_va_range(output, output_size);
-    iounmap(input);
-    vunmap(output);
-
-    if ( rc )
-    {
-        free_domheap_pages(pages, kernel_order_out);
-        return rc;
-    }
-
-    mod->start = page_to_maddr(pages);
-    mod->size = output_size;
-
-    /*
-     * Need to free pages after output_size here because they won't be
-     * freed by discard_initial_modules
-     */
-    i = PFN_UP(output_size);
-    for ( ; i < (1 << kernel_order_out); i++ )
-        free_domheap_page(pages + i);
-
-    /*
-     * When using static heap feature, don't give bootmodules memory back to
-     * the heap allocator
-     */
-    if ( using_static_heap )
-        return 0;
-
-    /*
-     * When freeing the kernel, we need to pass the module start address and
-     * size as they were before taking an offset to gzip header into account,
-     * so that the entire region will be freed.
-     */
-    addr -= offset;
-    size += offset;
-
-    /*
-     * Free the original kernel, update the pointers to the
-     * decompressed kernel
-     */
-    fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
-
-    return 0;
-}
-
 /*
  * Uimage CPU Architecture Codes
  */
@@ -274,8 +175,8 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset)
 /*
  * Check if the image is a uImage and setup kernel_info
  */
-static int __init kernel_uimage_probe(struct kernel_info *info,
-                                      struct bootmodule *mod)
+int __init kernel_uimage_probe(struct kernel_info *info,
+                               struct bootmodule *mod)
 {
     struct {
         __be32 magic;   /* Image Header Magic Number */
@@ -505,130 +406,20 @@ static int __init kernel_zimage32_probe(struct kernel_info *info,
     return 0;
 }
 
-int __init kernel_probe(struct kernel_info *info,
-                        const struct dt_device_node *domain)
+int __init kernel_zimage_probe(struct kernel_info *info, paddr_t addr,
+                               paddr_t size)
 {
-    struct bootmodule *mod = NULL;
-    struct bootcmdline *cmd = NULL;
-    struct dt_device_node *node;
-    u64 kernel_addr, initrd_addr, dtb_addr, size;
     int rc;
 
-    /*
-     * We need to initialize start to 0. This field may be populated during
-     * kernel_xxx_probe() if the image has a fixed entry point (for e.g.
-     * uimage.ep).
-     * We will use this to determine if the image has a fixed entry point or
-     * the load address should be used as the start address.
-     */
-    info->entry = 0;
-
-    /* domain is NULL only for the hardware domain */
-    if ( domain == NULL )
-    {
-        ASSERT(is_hardware_domain(info->d));
-
-        mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
-
-        info->kernel_bootmodule = mod;
-        info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
-
-        cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
-        if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
-    }
-    else
-    {
-        const char *name = NULL;
-
-        dt_for_each_child_node(domain, node)
-        {
-            if ( dt_device_is_compatible(node, "multiboot,kernel") )
-            {
-                u32 len;
-                const __be32 *val;
-
-                val = dt_get_property(node, "reg", &len);
-                dt_get_range(&val, node, &kernel_addr, &size);
-                mod = boot_module_find_by_addr_and_kind(
-                        BOOTMOD_KERNEL, kernel_addr);
-                info->kernel_bootmodule = mod;
-            }
-            else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
-            {
-                u32 len;
-                const __be32 *val;
-
-                val = dt_get_property(node, "reg", &len);
-                dt_get_range(&val, node, &initrd_addr, &size);
-                info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
-                        BOOTMOD_RAMDISK, initrd_addr);
-            }
-            else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
-            {
-                uint32_t len;
-                const __be32 *val;
-
-                val = dt_get_property(node, "reg", &len);
-                if ( val == NULL )
-                    continue;
-                dt_get_range(&val, node, &dtb_addr, &size);
-                info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
-                        BOOTMOD_GUEST_DTB, dtb_addr);
-            }
-            else
-                continue;
-        }
-        name = dt_node_name(domain);
-        cmd = boot_cmdline_find_by_name(name);
-        if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
-    }
-    if ( !mod || !mod->size )
-    {
-        printk(XENLOG_ERR "Missing kernel boot module?\n");
-        return -ENOENT;
-    }
-
-    printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
-           info->d, info->kernel_bootmodule->start);
-    if ( info->initrd_bootmodule )
-        printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
-               info->initrd_bootmodule->start);
-
-    /*
-     * uImage header always appears at the top of the image (even compressed),
-     * so it needs to be probed first. Note that in case of compressed uImage,
-     * kernel_decompress is called from kernel_uimage_probe making the function
-     * self-containing (i.e. fall through only in case of a header not found).
-     */
-    rc = kernel_uimage_probe(info, mod);
-    if ( rc != -ENOENT )
-        return rc;
-
-    /*
-     * If it is a gzip'ed image, 32bit or 64bit, uncompress it.
-     * At this point, gzip header appears (if at all) at the top of the image,
-     * so pass 0 as an offset.
-     */
-    rc = kernel_decompress(mod, 0);
-    if ( rc && rc != -EINVAL )
-        return rc;
-
 #ifdef CONFIG_ARM_64
-    rc = kernel_zimage64_probe(info, mod->start, mod->size);
+    rc = kernel_zimage64_probe(info, addr, size);
     if (rc < 0)
 #endif
-        rc = kernel_zimage32_probe(info, mod->start, mod->size);
+        rc = kernel_zimage32_probe(info, addr, size);
 
     return rc;
 }
 
-void __init kernel_load(struct kernel_info *info)
-{
-    info->load(info);
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index be38abf9e1..38981f1d11 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -14,13 +14,20 @@ config CORE_PARKING
 
 config DOM0LESS_BOOT
 	bool "Dom0less boot support" if EXPERT
-	depends on HAS_DOM0LESS
+	depends on HAS_DOM0LESS && DOMAIN_BUILD_HELPERS
 	default y
 	help
 	  Dom0less boot support enables Xen to create and start domU guests during
 	  Xen boot without the need of a control domain (Dom0), which could be
 	  present anyway.
 
+config DOMAIN_BUILD_HELPERS
+	bool
+	help
+	  Introduce functions necessary for working with domain creation, kernel,
+	  etc. As an examples, these type of functions are going to be used by
+	  CONFIG_DOM0LESS_BOOT.

NIT: If possible, I would make this option a silent option that cannot
be manually enabled/disabled. As a choice to the user, I think
DOM0LESS_BOOT is sufficient.
Sure, I'll drop 'help' then and add 'select DOMAIN_BUILD_HELPERS' in DOM0LESS_BOOT
config.




 config GRANT_TABLE
 	bool "Grant table support" if EXPERT
 	default y
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index f3dafc9b81..e88a4d5799 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -4,3 +4,4 @@ obj-y += device-tree.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
+obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
new file mode 100644
index 0000000000..1bf3bbf64e
--- /dev/null
+++ b/xen/common/device-tree/kernel.c
@@ -0,0 +1,242 @@
+#include <xen/bootfdt.h>
+#include <xen/device_tree.h>
+#include <xen/fdt-kernel.h>
+#include <xen/errno.h>
+#include <xen/gunzip.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/pfn.h>
+#include <xen/sched.h>
+#include <xen/types.h>
+#include <xen/vmap.h>
+
+#include <asm/page.h>
+#include <asm/setup.h>
+
+static uint32_t __init output_length(char *image, unsigned long image_len)
+{
+    return *(uint32_t *)&image[image_len - 4];
+}
+
+int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
+{
+    char *output, *input;
+    char magic[2];
+    int rc;
+    unsigned int kernel_order_out;
+    paddr_t output_size;
+    struct page_info *pages;
+    mfn_t mfn;
+    int i;
+    paddr_t addr = mod->start;
+    paddr_t size = mod->size;
+
+    if ( size < offset )
+        return -EINVAL;
+
+    /*
+     * It might be that gzip header does not appear at the start address
+     * (e.g. in case of compressed uImage) so take into account offset to
+     * gzip header.
+     */
+    addr += offset;
+    size -= offset;
+
+    if ( size < 2 )
+        return -EINVAL;
+
+    copy_from_paddr(magic, addr, sizeof(magic));
+
+    /* only gzip is supported */
+    if ( !gzip_check(magic, size) )
+        return -EINVAL;
+
+    input = ioremap_cache(addr, size);
+    if ( input == NULL )
+        return -EFAULT;
+
+    output_size = output_length(input, size);
+    kernel_order_out = get_order_from_bytes(output_size);
+    pages = alloc_domheap_pages(NULL, kernel_order_out, 0);
+    if ( pages == NULL )
+    {
+        iounmap(input);
+        return -ENOMEM;
+    }
+    mfn = page_to_mfn(pages);
+    output = vmap_contig(mfn, 1 << kernel_order_out);
+
+    rc = perform_gunzip(output, input, size);
+    clean_dcache_va_range(output, output_size);
+    iounmap(input);
+    vunmap(output);
+
+    if ( rc )
+    {
+        free_domheap_pages(pages, kernel_order_out);
+        return rc;
+    }
+
+    mod->start = page_to_maddr(pages);
+    mod->size = output_size;
+
+    /*
+     * Need to free pages after output_size here because they won't be
+     * freed by discard_initial_modules
+     */
+    i = PFN_UP(output_size);
+    for ( ; i < (1 << kernel_order_out); i++ )
+        free_domheap_page(pages + i);
+
+    /*
+     * When using static heap feature, don't give bootmodules memory back to
+     * the heap allocator
+     */
+    if ( using_static_heap )
+        return 0;
+
+    /*
+     * When freeing the kernel, we need to pass the module start address and
+     * size as they were before taking an offset to gzip header into account,
+     * so that the entire region will be freed.
+     */
+    addr -= offset;
+    size += offset;
+
+    /*
+     * Free the original kernel, update the pointers to the
+     * decompressed kernel
+     */
+    fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
+
+    return 0;
+}
+
+int __init kernel_probe(struct kernel_info *info,
+                        const struct dt_device_node *domain)
+{
+    struct bootmodule *mod = NULL;
+    struct bootcmdline *cmd = NULL;
+    struct dt_device_node *node;
+    u64 kernel_addr, initrd_addr, dtb_addr, size;
+    int rc;
+
+    /*
+     * We need to initialize start to 0. This field may be populated during
+     * kernel_xxx_probe() if the image has a fixed entry point (for e.g.
+     * uimage.ep).
+     * We will use this to determine if the image has a fixed entry point or
+     * the load address should be used as the start address.
+     */
+    info->entry = 0;
+
+    /* domain is NULL only for the hardware domain */
+    if ( domain == NULL )
+    {
+        ASSERT(is_hardware_domain(info->d));
+
+        mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+
+        info->kernel_bootmodule = mod;
+        info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+
+        cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
+        if ( cmd )
+            info->cmdline = &cmd->cmdline[0];
+    }
+    else
+    {
+        const char *name = NULL;
+
+        dt_for_each_child_node(domain, node)
+        {
+            if ( dt_device_is_compatible(node, "multiboot,kernel") )
+            {
+                u32 len;
+                const __be32 *val;
+
+                val = dt_get_property(node, "reg", &len);
+                dt_get_range(&val, node, &kernel_addr, &size);
+                mod = boot_module_find_by_addr_and_kind(
+                        BOOTMOD_KERNEL, kernel_addr);
+                info->kernel_bootmodule = mod;
+            }
+            else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
+            {
+                u32 len;
+                const __be32 *val;
+
+                val = dt_get_property(node, "reg", &len);
+                dt_get_range(&val, node, &initrd_addr, &size);
+                info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
+                        BOOTMOD_RAMDISK, initrd_addr);
+            }
+            else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
+            {
+                uint32_t len;
+                const __be32 *val;
+
+                val = dt_get_property(node, "reg", &len);
+                if ( val == NULL )
+                    continue;
+                dt_get_range(&val, node, &dtb_addr, &size);
+                info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
+                        BOOTMOD_GUEST_DTB, dtb_addr);
+            }
+            else
+                continue;
+        }
+        name = dt_node_name(domain);
+        cmd = boot_cmdline_find_by_name(name);
+        if ( cmd )
+            info->cmdline = &cmd->cmdline[0];
+    }
+    if ( !mod || !mod->size )
+    {
+        printk(XENLOG_ERR "Missing kernel boot module?\n");
+        return -ENOENT;
+    }
+
+    printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
+           info->d, info->kernel_bootmodule->start);
+    if ( info->initrd_bootmodule )
+        printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
+               info->initrd_bootmodule->start);
+
+    /*
+     * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
+     * call here just for compatability with Arm code.
+     */
+#ifdef CONFIG_ARM
+    /*
+     * uImage header always appears at the top of the image (even compressed),
+     * so it needs to be probed first. Note that in case of compressed uImage,
+     * kernel_decompress is called from kernel_uimage_probe making the function
+     * self-containing (i.e. fall through only in case of a header not found).
+     */
+    rc = kernel_uimage_probe(info, mod);
+    if ( rc != -ENOENT )
+        return rc;
+#endif
+
+    /*
+     * If it is a gzip'ed image, 32bit or 64bit, uncompress it.
+     * At this point, gzip header appears (if at all) at the top of the image,
+     * so pass 0 as an offset.
+     */
+    rc = kernel_decompress(mod, 0);
+    if ( rc && rc != -EINVAL )
+        return rc;
+
+    rc = kernel_zimage_probe(info, mod->start, mod->size);
+
+    return rc;
+}
+
+void __init kernel_load(struct kernel_info *info)
+{
+    ASSERT(info && info->load);
+
+    info->load(info);
+}
diff --git a/xen/include/asm-generic/kernel.h b/xen/include/asm-generic/kernel.h
new file mode 100644
index 0000000000..6857fabb34
--- /dev/null
+++ b/xen/include/asm-generic/kernel.h

This file seems to be a duplicate of the previously introduced
xen/include/xen/fdt-kernel.h ?

Other than that, I checked the rest of the patch, including all the code
movement, and it looks correct to me.
I will drop asm-generic/kernel.h, it  was created in the initial version of this
patch series before it was suggested to move such header to xen/. And I missed to drop it.

Thanks.

~ Oleksii





@@ -0,0 +1,141 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+
+#ifndef __ASM_GENERIC_KERNEL_H__
+#define __ASM_GENERIC_KERNEL_H__
+
+#include <xen/bootfdt.h>
+#include <xen/device_tree.h>
+#include <xen/sched.h>
+#include <xen/types.h>
+
+struct kernel_info {
+    struct domain *d;
+
+    void *fdt; /* flat device tree */
+    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+    struct meminfo mem;
+#ifdef CONFIG_STATIC_SHM
+    struct shared_meminfo shm_mem;
+#endif
+
+    /* kernel entry point */
+    paddr_t entry;
+
+    /* grant table region */
+    paddr_t gnttab_start;
+    paddr_t gnttab_size;
+
+    /* boot blob load addresses */
+    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
+    const char* cmdline;
+    paddr_t dtb_paddr;
+    paddr_t initrd_paddr;
+
+    /* Enable uart emulation */
+    bool vuart;
+
+    /* Enable/Disable PV drivers interfaces */
+    uint16_t dom0less_feature;
+
+    /* Interrupt controller phandle */
+    uint32_t phandle_intc;
+
+    /* loader to use for this kernel */
+    void (*load)(struct kernel_info *info);
+
+    /* loader specific state */
+    union {
+        struct {
+            paddr_t kernel_addr;
+            paddr_t len;
+#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64)
+            paddr_t text_offset; /* 64-bit Image only */
+#endif
+            paddr_t start; /* Must be 0 for 64-bit Image */
+        } zimage;
+    };
+
+    struct arch_kernel_info arch;
+};
+
+static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo)
+{
+    return container_of(&kinfo->mem.common, struct membanks, common);
+}
+
+static inline const struct membanks *
+kernel_info_get_mem_const(const struct kernel_info *kinfo)
+{
+    return container_of(&kinfo->mem.common, const struct membanks, common);
+}
+
+#ifndef KERNEL_INFO_SHM_MEM_INIT
+
+#ifdef CONFIG_STATIC_SHM
+#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS,
+#else
+#define KERNEL_INFO_SHM_MEM_INIT
+#endif
+
+#endif /* KERNEL_INFO_SHM_MEM_INIT */
+
+#ifndef KERNEL_INFO_INIT
+
+#define KERNEL_INFO_INIT                        \
+{                                               \
+    .mem.common.max_banks = NR_MEM_BANKS,       \
+    KERNEL_INFO_SHM_MEM_INIT                    \
+}
+
+#endif /* KERNEL_INFO_INIT */
+
+/*
+ * Probe the kernel to detemine its type and select a loader.
+ *
+ * Sets in info:
+ *  ->type
+ *  ->load hook, and sets loader specific variables ->zimage
+ */
+int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
+
+/*
+ * Loads the kernel into guest RAM.
+ *
+ * Expects to be set in info when called:
+ *  ->mem
+ *  ->fdt
+ *
+ * Sets in info:
+ *  ->entry
+ *  ->dtb_paddr
+ *  ->initrd_paddr
+ */
+void kernel_load(struct kernel_info *info);
+
+int kernel_decompress(struct bootmodule *mod, uint32_t offset);
+
+int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size);
+
+/*
+ * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
+ * call here just for compatability with Arm code.
+ */
+#ifdef CONFIG_ARM
+struct bootmodule;
+int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod);
+#endif
+
+#endif /*__ASM_GENERIC_KERNEL_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index c81e759423..d85324c867 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -121,6 +121,19 @@ int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
  */
 void kernel_load(struct kernel_info *info);
 
+int kernel_decompress(struct bootmodule *mod, uint32_t offset);
+
+int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size);
+
+/*
+ * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
+ * call here just for compatability with Arm code.
+ */
+#ifdef CONFIG_ARM
+struct bootmodule;
+int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod);
+#endif
+
 #endif /* __XEN_FDT_KERNEL_H__ */
 
 /*
-- 
2.49.0
--------------dc0pdxlLpld0MN514z460mo9-- From xen-devel-bounces@lists.xenproject.org Mon May 05 10:07:07 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 10:07:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975955.1363231 (Exim 4.92) (envelope-from ) id 1uBsir-0004VG-Ea; Mon, 05 May 2025 10:06:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975955.1363231; Mon, 05 May 2025 10: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 1uBsir-0004V9-AM; Mon, 05 May 2025 10:06:53 +0000 Received: by outflank-mailman (input) for mailman id 975955; Mon, 05 May 2025 10:06:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBsip-0004V3-Qc for xen-devel@lists.xenproject.org; Mon, 05 May 2025 10:06:52 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a86aeaab-2998-11f0-9ffb-bf95429c2676; Mon, 05 May 2025 12:06:48 +0200 (CEST) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-acb5ec407b1so732848866b.1 for ; Mon, 05 May 2025 03:06:48 -0700 (PDT) Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad189146fb4sm474942266b.10.2025.05.05.03.06.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 May 2025 03: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" X-Inumbo-ID: a86aeaab-2998-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746439608; x=1747044408; darn=lists.xenproject.org; h=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; bh=wnWbTMR6PFtZ/HWhz6xzS0TH/ykoGRXRZPYKmmnoTOI=; b=JpkPs5vmIJv2gFlok8K3zD0TVmH0ugLHreN+4L2cXGCAuLt9A3dNjh/vI4bOmIBS60 p/GrowlNVcbfRA7CHmT92BrLjxKAbe7dpkw47N4q7AmNV3RgjUfak2oBFsNuf/FUMH7n ogtgNVYB7Bv2lPK1HopfEnw0AqwwVpZyCzZ7v5hlTxgJleCtLMbgCiNoP6ee0l4ewW+B gHFnGINEIyE69ISbHxO0hv28z3l+e/tUZPLr/Qogp3ZIS+/EPmg16Eba/nIRD/bF2eFt pmQyuViy+ds54GrHFR7RiHE4VY6W0rS7cEd/Ya5QRW5UnFQiC8fn7D5Qkq16n5hf3/Aj Y5sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746439608; x=1747044408; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=wnWbTMR6PFtZ/HWhz6xzS0TH/ykoGRXRZPYKmmnoTOI=; b=Y4SJJH9YeC1KV/TEHzskff4eL95gg6s1ziwQnWmsoV+xR1Bdt8gbPv491Eddmcir59 qUf8OV9Ovc0wDJw0e4TkYbwKQjRnHeqdxaaCgwLeXYUsHTR/Bmvjv6Pnt9Bmv4VLi5gh /KDBN22x2IXUDKVCN8y1HLfUV5jXrrshRAeVXJDKOKuwAq9Cnw83yEwildwS0vNPxAJB M/+pKDeKnTJLfUzabmjYjcTwxW6oC22DzTzqXk+MtDVL5HTK+SklVys2j5tACjumsKXh j0CRlHVRRT6OKbEj6MtC89puT1fClF0iYMWAfLCjSy7defA7xHIHUk3kTaghvqXl8Gnh VnIQ== X-Gm-Message-State: AOJu0YzIbSYBD5P4ZDzx3hs3co+AYTTzkHvsY7aKoPZJn/ZmSWDnpqZX sTIY7e+29U/5PFQ2Oje/r8noEdONH946Lad19qR+MCxgeqGH89AJ/OOsiA== X-Gm-Gg: ASbGncvFnIgomt/toVuE5K2kg8DYnBa6tJGL1MRsquRa1YkPvDvfRCLQmO5hmYmHSeS SdnxJmGs6IpNaC18so6favKUUTQR21rbS/OnnQ7QZOHGKv/1XfheMRtDpHNhEMyE/WKlLRJMCE1 m/f/20BRoE3T4vqrt8V7rUt2LSvvvdyYFboTTVSl69IZ1NsahsUcnZ3jhO9MLW4uEnah00zfZnw jVR/HyEd5/FuuCViL+LRyJYZBtteIKRaqGEktYChuLRRRdtSj3zDUxxa1dabk8/pI4fnYWK294d Neh2HBZuqnGlUOACokszW2mumLos79hSF3tWdhUi6LyFfBl1MNAJDZ23WVN5+QrMG72uuU3y1UK 3Hv/gra8PSyXsMsVd X-Google-Smtp-Source: AGHT+IH1bl3Z5HCcH44OHj+U7z/CJBV4TnuQUNP3FTvsZTQhPCkyw4IX7xlKnsdPXXUHojQ61kzrlA== X-Received: by 2002:a17:907:96a2:b0:ac7:391b:e684 with SMTP id a640c23a62f3a-ad1a4b5b9abmr573296666b.58.1746439607617; Mon, 05 May 2025 03:06:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------c3Tx0EG8Ky8f2ynJQQQ1P3ru" Message-ID: Date: Mon, 5 May 2025 12:06:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 7/8] xen/common: dom0less: introduce common domain-build.c To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <291544ec45d69a3f0ff79eb6770266a0aa04e77d.1746199009.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: This is a multi-part message in MIME format. --------------c3Tx0EG8Ky8f2ynJQQQ1P3ru Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/2/25 10:02 PM, Stefano Stabellini wrote: > On Fri, 2 May 2025, Oleksii Kurochko wrote: >> Some functions of Arm's domain_build.c could be reused by dom0less or other >> features connected to domain construction/build. >> >> The following functions are moved to common: >> - get_allocation_size(). >> - allocate_domheap_memory(). >> - guest_map_pages(). >> - allocate_bank_memory(). >> - add_hwdom_free_regions(). >> - find_unallocated_memory(). >> - allocate_memory(). >> - dtb_load(). >> - initrd_load(). > The declaration of allocate_domheap_memory, allocate_bank_memory, > allocate_memory were moved in patch #5. Maybe their movement should be > in this patch? Sure, it makes sense. > >> Prototype of dtb_load() and initrd_load() is updated to recieve a pointer >> to copy_to_guest_phys() as some archs require >> copy_to_guest_phys_fluch_dcache(). >> >> Update arm/include/asm/Makefile to generate domain-build.h for Arm as it is >> used by domain-build.c. >> >> Signed-off-by: Oleksii Kurochko >> --- >> Change in v3: >> - Nothing changed. Only rebase. >> --- >> Change in v2: >> - Use xen/fdt-domain-build.h instead of asm/domain_build.h. >> --- >> xen/arch/arm/domain_build.c | 397 +------------------------ >> xen/common/device-tree/Makefile | 1 + >> xen/common/device-tree/domain-build.c | 404 ++++++++++++++++++++++++++ >> xen/include/xen/fdt-domain-build.h | 33 ++- >> 4 files changed, 439 insertions(+), 396 deletions(-) >> create mode 100644 xen/common/device-tree/domain-build.c >> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index 9d649b06b3..df29619c40 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -120,18 +120,6 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0) >> return vcpu_create(dom0, 0); >> } >> >> -unsigned int __init get_allocation_size(paddr_t size) >> -{ >> - /* >> - * get_order_from_bytes returns the order greater than or equal to >> - * the given size, but we need less than or equal. Adding one to >> - * the size pushes an evenly aligned size into the next order, so >> - * we can then unconditionally subtract 1 from the order which is >> - * returned. >> - */ >> - return get_order_from_bytes(size + 1) - 1; >> -} >> - >> /* >> * Insert the given pages into a memory bank, banks are ordered by address. >> * >> @@ -418,98 +406,6 @@ static void __init allocate_memory_11(struct domain *d, >> } >> } >> >> -bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size, >> - alloc_domheap_mem_cb cb, void *extra) >> -{ >> - unsigned int max_order = UINT_MAX; >> - >> - while ( tot_size > 0 ) >> - { >> - unsigned int order = get_allocation_size(tot_size); >> - struct page_info *pg; >> - >> - order = min(max_order, order); >> - >> - pg = alloc_domheap_pages(d, order, 0); >> - if ( !pg ) >> - { >> - /* >> - * If we can't allocate one page, then it is unlikely to >> - * succeed in the next iteration. So bail out. >> - */ >> - if ( !order ) >> - return false; >> - >> - /* >> - * If we can't allocate memory with order, then it is >> - * unlikely to succeed in the next iteration. >> - * Record the order - 1 to avoid re-trying. >> - */ >> - max_order = order - 1; >> - continue; >> - } >> - >> - if ( !cb(d, pg, order, extra) ) >> - return false; >> - >> - tot_size -= (1ULL << (PAGE_SHIFT + order)); >> - } >> - >> - return true; >> -} >> - >> -static bool __init guest_map_pages(struct domain *d, struct page_info *pg, >> - unsigned int order, void *extra) >> -{ >> - gfn_t *sgfn = (gfn_t *)extra; >> - int res; >> - >> - BUG_ON(!sgfn); >> - res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order); >> - if ( res ) >> - { >> - dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res); >> - return false; >> - } >> - >> - *sgfn = gfn_add(*sgfn, 1UL << order); >> - >> - return true; >> -} >> - >> -bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, >> - paddr_t tot_size) >> -{ >> - struct membanks *mem = kernel_info_get_mem(kinfo); >> - struct domain *d = kinfo->d; >> - struct membank *bank; >> - >> - /* >> - * allocate_bank_memory can be called with a tot_size of zero for >> - * the second memory bank. It is not an error and we can safely >> - * avoid creating a zero-size memory bank. >> - */ >> - if ( tot_size == 0 ) >> - return true; >> - >> - bank = &mem->bank[mem->nr_banks]; >> - bank->start = gfn_to_gaddr(sgfn); >> - bank->size = tot_size; >> - >> - /* >> - * Allocate pages from the heap until tot_size is zero and map them to the >> - * guest using guest_map_pages, passing the starting gfn as extra parameter >> - * for the map operation. >> - */ >> - if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) ) >> - return false; >> - >> - mem->nr_banks++; >> - kinfo->unassigned_mem -= bank->size; >> - >> - return true; >> -} >> - >> /* >> * When PCI passthrough is available we want to keep the >> * "linux,pci-domain" in sync for every host bridge. >> @@ -900,226 +796,6 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, >> return 0; >> } >> >> -static int __init add_hwdom_free_regions(unsigned long s_gfn, >> - unsigned long e_gfn, void *data) >> -{ >> - struct membanks *free_regions = data; >> - paddr_t start, size; >> - paddr_t s = pfn_to_paddr(s_gfn); >> - paddr_t e = pfn_to_paddr(e_gfn); >> - unsigned int i, j; >> - >> - if ( free_regions->nr_banks >= free_regions->max_banks ) >> - return 0; >> - >> - /* >> - * Both start and size of the free region should be 2MB aligned to >> - * potentially allow superpage mapping. >> - */ >> - start = (s + SZ_2M - 1) & ~(SZ_2M - 1); >> - if ( start > e ) >> - return 0; >> - >> - /* >> - * e is actually "end-1" because it is called by rangeset functions >> - * which are inclusive of the last address. >> - */ >> - e += 1; >> - size = (e - start) & ~(SZ_2M - 1); >> - >> - /* Find the insert position (descending order). */ >> - for ( i = 0; i < free_regions->nr_banks ; i++ ) >> - if ( size > free_regions->bank[i].size ) >> - break; >> - >> - /* Move the other banks to make space. */ >> - for ( j = free_regions->nr_banks; j > i ; j-- ) >> - { >> - free_regions->bank[j].start = free_regions->bank[j - 1].start; >> - free_regions->bank[j].size = free_regions->bank[j - 1].size; >> - } >> - >> - free_regions->bank[i].start = start; >> - free_regions->bank[i].size = size; >> - free_regions->nr_banks++; >> - >> - return 0; >> -} >> - >> -/* >> - * Find unused regions of Host address space which can be exposed to domain >> - * using the host memory layout. In order to calculate regions we exclude every >> - * region passed in mem_banks from the Host RAM. >> - */ >> -static int __init find_unallocated_memory(const struct kernel_info *kinfo, >> - const struct membanks *mem_banks[], >> - unsigned int nr_mem_banks, >> - struct membanks *free_regions, >> - int (*cb)(unsigned long s_gfn, >> - unsigned long e_gfn, >> - void *data)) >> -{ >> - const struct membanks *mem = bootinfo_get_mem(); >> - struct rangeset *unalloc_mem; >> - paddr_t start, end; >> - unsigned int i, j; >> - int res; >> - >> - ASSERT(domain_use_host_layout(kinfo->d)); >> - >> - unalloc_mem = rangeset_new(NULL, NULL, 0); >> - if ( !unalloc_mem ) >> - return -ENOMEM; >> - >> - /* Start with all available RAM */ >> - for ( i = 0; i < mem->nr_banks; i++ ) >> - { >> - start = mem->bank[i].start; >> - end = mem->bank[i].start + mem->bank[i].size; >> - res = rangeset_add_range(unalloc_mem, PFN_DOWN(start), >> - PFN_DOWN(end - 1)); >> - if ( res ) >> - { >> - printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n", >> - start, end); >> - goto out; >> - } >> - } >> - >> - /* Remove all regions listed in mem_banks */ >> - for ( i = 0; i < nr_mem_banks; i++ ) >> - for ( j = 0; j < mem_banks[i]->nr_banks; j++ ) >> - { >> - start = mem_banks[i]->bank[j].start; >> - >> - /* Shared memory banks can contain INVALID_PADDR as start */ >> - if ( INVALID_PADDR == start ) >> - continue; >> - >> - end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size; >> - res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), >> - PFN_DOWN(end - 1)); >> - if ( res ) >> - { >> - printk(XENLOG_ERR >> - "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n", >> - start, end, res); >> - goto out; >> - } >> - } >> - >> - start = 0; >> - end = (1ULL << p2m_ipa_bits) - 1; >> - res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end), >> - cb, free_regions); >> - if ( res ) >> - free_regions->nr_banks = 0; >> - else if ( !free_regions->nr_banks ) >> - res = -ENOENT; >> - >> -out: >> - rangeset_destroy(unalloc_mem); >> - >> - return res; >> -} >> - >> -void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) >> -{ >> - struct membanks *mem = kernel_info_get_mem(kinfo); >> - unsigned int i, nr_banks = GUEST_RAM_BANKS; >> - struct membanks *hwdom_free_mem = NULL; >> - >> - printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", >> - /* Don't want format this as PRIpaddr (16 digit hex) */ >> - (unsigned long)(kinfo->unassigned_mem >> 20), d); >> - >> - mem->nr_banks = 0; >> - /* >> - * Use host memory layout for hwdom. Only case for this is when LLC coloring >> - * is enabled. >> - */ >> - if ( is_hardware_domain(d) ) >> - { >> - struct membanks *gnttab = membanks_xzalloc(1, MEMORY); >> - /* >> - * Exclude the following regions: >> - * 1) Remove reserved memory >> - * 2) Grant table assigned to hwdom >> - */ >> - const struct membanks *mem_banks[] = { >> - bootinfo_get_reserved_mem(), >> - gnttab, >> - }; >> - >> - if ( !gnttab ) >> - goto fail; >> - >> - gnttab->nr_banks = 1; >> - gnttab->bank[0].start = kinfo->gnttab_start; >> - gnttab->bank[0].size = kinfo->gnttab_size; >> - >> - hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY); >> - if ( !hwdom_free_mem ) >> - goto fail; >> - >> - if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks), >> - hwdom_free_mem, add_hwdom_free_regions) ) >> - goto fail; >> - >> - nr_banks = hwdom_free_mem->nr_banks; >> - xfree(gnttab); >> - } >> - >> - for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- ) >> - { >> - paddr_t bank_start, bank_size; >> - >> - if ( is_hardware_domain(d) ) >> - { >> - bank_start = hwdom_free_mem->bank[i].start; >> - bank_size = hwdom_free_mem->bank[i].size; >> - } >> - else >> - { >> - const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; >> - const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; >> - >> - if ( i >= GUEST_RAM_BANKS ) >> - goto fail; >> - >> - bank_start = bankbase[i]; >> - bank_size = banksize[i]; >> - } >> - >> - bank_size = MIN(bank_size, kinfo->unassigned_mem); >> - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) ) >> - goto fail; >> - } >> - >> - if ( kinfo->unassigned_mem ) >> - goto fail; >> - >> - for( i = 0; i < mem->nr_banks; i++ ) >> - { >> - printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", >> - d, >> - i, >> - mem->bank[i].start, >> - mem->bank[i].start + mem->bank[i].size, >> - /* Don't want format this as PRIpaddr (16 digit hex) */ >> - (unsigned long)(mem->bank[i].size >> 20)); >> - } >> - >> - xfree(hwdom_free_mem); >> - return; >> - >> - fail: >> - panic("Failed to allocate requested domain memory." >> - /* Don't want format this as PRIpaddr (16 digit hex) */ >> - " %ldKB unallocated. Fix the VMs configurations.\n", >> - (unsigned long)kinfo->unassigned_mem >> 10); >> -} >> - >> static int __init handle_pci_range(const struct dt_device_node *dev, >> uint64_t addr, uint64_t len, void *data) >> { >> @@ -2059,75 +1735,6 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo) >> return -EINVAL; >> } >> >> -static void __init dtb_load(struct kernel_info *kinfo) >> -{ >> - unsigned long left; >> - >> - printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", >> - kinfo->d, kinfo->dtb_paddr, >> - kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt)); >> - >> - left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr, >> - kinfo->fdt, >> - fdt_totalsize(kinfo->fdt)); >> - >> - if ( left != 0 ) >> - panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n", >> - kinfo->d, left); >> - xfree(kinfo->fdt); >> -} >> - >> -static void __init initrd_load(struct kernel_info *kinfo) >> -{ >> - const struct bootmodule *mod = kinfo->initrd_bootmodule; >> - paddr_t load_addr = kinfo->initrd_paddr; >> - paddr_t paddr, len; >> - int node; >> - int res; >> - __be32 val[2]; >> - __be32 *cellp; >> - void __iomem *initrd; >> - >> - if ( !mod || !mod->size ) >> - return; >> - >> - paddr = mod->start; >> - len = mod->size; >> - >> - printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", >> - kinfo->d, paddr, load_addr, load_addr + len); >> - >> - /* Fix up linux,initrd-start and linux,initrd-end in /chosen */ >> - node = fdt_path_offset(kinfo->fdt, "/chosen"); >> - if ( node < 0 ) >> - panic("Cannot find the /chosen node\n"); >> - >> - cellp = (__be32 *)val; >> - dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr); >> - res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start", >> - val, sizeof(val)); >> - if ( res ) >> - panic("Cannot fix up \"linux,initrd-start\" property\n"); >> - >> - cellp = (__be32 *)val; >> - dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len); >> - res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end", >> - val, sizeof(val)); >> - if ( res ) >> - panic("Cannot fix up \"linux,initrd-end\" property\n"); >> - >> - initrd = ioremap_wc(paddr, len); >> - if ( !initrd ) >> - panic("Unable to map the %pd initrd\n", kinfo->d); >> - >> - res = copy_to_guest_phys_flush_dcache(kinfo->d, load_addr, >> - initrd, len); >> - if ( res != 0 ) >> - panic("Unable to copy the initrd in the %pd memory\n", kinfo->d); >> - >> - iounmap(initrd); >> -} >> - >> /* >> * Allocate the event channel PPIs and setup the HVM_PARAM_CALLBACK_IRQ. >> * The allocated IRQ will be found in d->arch.evtchn_irq. >> @@ -2220,8 +1827,8 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo) >> */ >> kernel_load(kinfo); >> /* initrd_load will fix up the fdt, so call it before dtb_load */ >> - initrd_load(kinfo); >> - dtb_load(kinfo); >> + initrd_load(kinfo, copy_to_guest_phys_flush_dcache); >> + dtb_load(kinfo, copy_to_guest_phys_flush_dcache); >> >> memset(regs, 0, sizeof(*regs)); >> >> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile >> index e88a4d5799..831b91399b 100644 >> --- a/xen/common/device-tree/Makefile >> +++ b/xen/common/device-tree/Makefile >> @@ -1,6 +1,7 @@ >> obj-y += bootfdt.init.o >> obj-y += bootinfo.init.o >> obj-y += device-tree.o >> +obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.o >> obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o >> obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o >> obj-y += intc.o >> diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c >> new file mode 100644 >> index 0000000000..69257a15ba >> --- /dev/null >> +++ b/xen/common/device-tree/domain-build.c >> @@ -0,0 +1,404 @@ >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> + >> +bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size, >> + alloc_domheap_mem_cb cb, void *extra) >> +{ >> + unsigned int max_order = UINT_MAX; >> + >> + while ( tot_size > 0 ) >> + { >> + unsigned int order = get_allocation_size(tot_size); >> + struct page_info *pg; >> + >> + order = min(max_order, order); >> + >> + pg = alloc_domheap_pages(d, order, 0); >> + if ( !pg ) >> + { >> + /* >> + * If we can't allocate one page, then it is unlikely to >> + * succeed in the next iteration. So bail out. >> + */ >> + if ( !order ) >> + return false; >> + >> + /* >> + * If we can't allocate memory with order, then it is >> + * unlikely to succeed in the next iteration. >> + * Record the order - 1 to avoid re-trying. >> + */ >> + max_order = order - 1; >> + continue; >> + } >> + >> + if ( !cb(d, pg, order, extra) ) >> + return false; >> + >> + tot_size -= (1ULL << (PAGE_SHIFT + order)); >> + } >> + >> + return true; >> +} >> + >> +static bool __init guest_map_pages(struct domain *d, struct page_info *pg, >> + unsigned int order, void *extra) >> +{ >> + gfn_t *sgfn = (gfn_t *)extra; >> + int res; >> + >> + BUG_ON(!sgfn); >> + res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order); >> + if ( res ) >> + { >> + dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res); >> + return false; >> + } >> + >> + *sgfn = gfn_add(*sgfn, 1UL << order); >> + >> + return true; >> +} >> + >> +bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, >> + paddr_t tot_size) >> +{ >> + struct membanks *mem = kernel_info_get_mem(kinfo); >> + struct domain *d = kinfo->d; >> + struct membank *bank; >> + >> + /* >> + * allocate_bank_memory can be called with a tot_size of zero for >> + * the second memory bank. It is not an error and we can safely >> + * avoid creating a zero-size memory bank. >> + */ >> + if ( tot_size == 0 ) >> + return true; >> + >> + bank = &mem->bank[mem->nr_banks]; >> + bank->start = gfn_to_gaddr(sgfn); >> + bank->size = tot_size; >> + >> + /* >> + * Allocate pages from the heap until tot_size is zero and map them to the >> + * guest using guest_map_pages, passing the starting gfn as extra parameter >> + * for the map operation. >> + */ >> + if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) ) >> + return false; >> + >> + mem->nr_banks++; >> + kinfo->unassigned_mem -= bank->size; >> + >> + return true; >> +} >> + >> +static int __init add_hwdom_free_regions(unsigned long s_gfn, >> + unsigned long e_gfn, void *data) >> +{ >> + struct membanks *free_regions = data; >> + paddr_t start, size; >> + paddr_t s = pfn_to_paddr(s_gfn); >> + paddr_t e = pfn_to_paddr(e_gfn); >> + unsigned int i, j; >> + >> + if ( free_regions->nr_banks >= free_regions->max_banks ) >> + return 0; >> + >> + /* >> + * Both start and size of the free region should be 2MB aligned to >> + * potentially allow superpage mapping. >> + */ >> + start = (s + SZ_2M - 1) & ~(SZ_2M - 1); >> + if ( start > e ) >> + return 0; >> + >> + /* >> + * e is actually "end-1" because it is called by rangeset functions >> + * which are inclusive of the last address. >> + */ >> + e += 1; >> + size = (e - start) & ~(SZ_2M - 1); >> + >> + /* Find the insert position (descending order). */ >> + for ( i = 0; i < free_regions->nr_banks ; i++ ) >> + if ( size > free_regions->bank[i].size ) >> + break; >> + >> + /* Move the other banks to make space. */ >> + for ( j = free_regions->nr_banks; j > i ; j-- ) >> + { >> + free_regions->bank[j].start = free_regions->bank[j - 1].start; >> + free_regions->bank[j].size = free_regions->bank[j - 1].size; >> + } >> + >> + free_regions->bank[i].start = start; >> + free_regions->bank[i].size = size; >> + free_regions->nr_banks++; >> + >> + return 0; >> +} >> + >> +/* >> + * Find unused regions of Host address space which can be exposed to domain >> + * using the host memory layout. In order to calculate regions we exclude every >> + * region passed in mem_banks from the Host RAM. >> + */ >> +int __init find_unallocated_memory(const struct kernel_info *kinfo, >> + const struct membanks *mem_banks[], >> + unsigned int nr_mem_banks, >> + struct membanks *free_regions, >> + int (*cb)(unsigned long s_gfn, >> + unsigned long e_gfn, >> + void *data)) >> +{ >> + const struct membanks *mem = bootinfo_get_mem(); >> + struct rangeset *unalloc_mem; >> + paddr_t start, end; >> + unsigned int i, j; >> + int res; >> + >> + ASSERT(domain_use_host_layout(kinfo->d)); >> + >> + unalloc_mem = rangeset_new(NULL, NULL, 0); >> + if ( !unalloc_mem ) >> + return -ENOMEM; >> + >> + /* Start with all available RAM */ >> + for ( i = 0; i < mem->nr_banks; i++ ) >> + { >> + start = mem->bank[i].start; >> + end = mem->bank[i].start + mem->bank[i].size; >> + res = rangeset_add_range(unalloc_mem, PFN_DOWN(start), >> + PFN_DOWN(end - 1)); >> + if ( res ) >> + { >> + printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n", >> + start, end); >> + goto out; >> + } >> + } >> + >> + /* Remove all regions listed in mem_banks */ >> + for ( i = 0; i < nr_mem_banks; i++ ) >> + for ( j = 0; j < mem_banks[i]->nr_banks; j++ ) >> + { >> + start = mem_banks[i]->bank[j].start; >> + >> + /* Shared memory banks can contain INVALID_PADDR as start */ >> + if ( INVALID_PADDR == start ) >> + continue; >> + >> + end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size; >> + res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), >> + PFN_DOWN(end - 1)); >> + if ( res ) >> + { >> + printk(XENLOG_ERR >> + "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n", >> + start, end, res); >> + goto out; >> + } >> + } >> + >> + start = 0; >> + end = (1ULL << p2m_ipa_bits) - 1; >> + res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end), >> + cb, free_regions); >> + if ( res ) >> + free_regions->nr_banks = 0; >> + else if ( !free_regions->nr_banks ) >> + res = -ENOENT; >> + >> +out: >> + rangeset_destroy(unalloc_mem); >> + >> + return res; >> +} >> + >> +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) >> +{ >> + struct membanks *mem = kernel_info_get_mem(kinfo); >> + unsigned int i, nr_banks = GUEST_RAM_BANKS; >> + struct membanks *hwdom_free_mem = NULL; >> + >> + printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", >> + /* Don't want format this as PRIpaddr (16 digit hex) */ >> + (unsigned long)(kinfo->unassigned_mem >> 20), d); >> + >> + mem->nr_banks = 0; >> + /* >> + * Use host memory layout for hwdom. Only case for this is when LLC coloring >> + * is enabled. >> + */ >> + if ( is_hardware_domain(d) ) >> + { >> + struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1); > shouldn't we set gnttab->max_banks and gnttab->type here? Here and ... > > >> + /* >> + * Exclude the following regions: >> + * 1) Remove reserved memory >> + * 2) Grant table assigned to hwdom >> + */ >> + const struct membanks *mem_banks[] = { >> + bootinfo_get_reserved_mem(), >> + gnttab, >> + }; >> + >> + if ( !gnttab ) >> + goto fail; >> + >> + gnttab->nr_banks = 1; >> + gnttab->bank[0].start = kinfo->gnttab_start; >> + gnttab->bank[0].size = kinfo->gnttab_size; >> + >> + hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank, >> + NR_MEM_BANKS); >> + if ( !hwdom_free_mem ) >> + goto fail; >> + >> + hwdom_free_mem->max_banks = NR_MEM_BANKS; > here we are missing setting hwdom_free_mem->type ? ... here, membanks_xzalloc() should be really used. for the first one case - membanks_xzalloc(1, MEMORY) and for the second - membanks_xzalloc(NR_MEM_BANKS, MEMORY). Good catch. > >> + >> + if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks), >> + hwdom_free_mem, add_hwdom_free_regions) ) >> + goto fail; >> + >> + nr_banks = hwdom_free_mem->nr_banks; >> + xfree(gnttab); >> + } >> + >> + for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- ) >> + { >> + paddr_t bank_start, bank_size; >> + >> + if ( is_hardware_domain(d) ) >> + { >> + bank_start = hwdom_free_mem->bank[i].start; >> + bank_size = hwdom_free_mem->bank[i].size; >> + } >> + else >> + { >> + const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; >> + const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; >> + >> + if ( i >= GUEST_RAM_BANKS ) >> + goto fail; >> + >> + bank_start = bankbase[i]; >> + bank_size = banksize[i]; >> + } >> + >> + bank_size = MIN(bank_size, kinfo->unassigned_mem); >> + if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) ) >> + goto fail; >> + } >> + >> + if ( kinfo->unassigned_mem ) >> + goto fail; >> + >> + for( i = 0; i < mem->nr_banks; i++ ) >> + { >> + printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", >> + d, >> + i, >> + mem->bank[i].start, >> + mem->bank[i].start + mem->bank[i].size, >> + /* Don't want format this as PRIpaddr (16 digit hex) */ >> + (unsigned long)(mem->bank[i].size >> 20)); >> + } >> + >> + xfree(hwdom_free_mem); >> + return; >> + >> + fail: >> + panic("Failed to allocate requested domain memory." >> + /* Don't want format this as PRIpaddr (16 digit hex) */ >> + " %ldKB unallocated. Fix the VMs configurations.\n", >> + (unsigned long)kinfo->unassigned_mem >> 10); >> +} >> + >> +/* Copy data to guest physical address, then clean the region. */ >> +typedef unsigned long (*copy_to_guest_phys_cb)(struct domain *d, >> + paddr_t gpa, >> + void *buf, >> + unsigned int len); > This shouldn't be needed because copy_to_guest_phys_cb is already > declared in xen/include/xen/fdt-domain-build.h > > >> +void __init dtb_load(struct kernel_info *kinfo, >> + copy_to_guest_phys_cb copy_to_guest) >> +{ >> + unsigned long left; >> + >> + printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", >> + kinfo->d, kinfo->dtb_paddr, >> + kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt)); >> + >> + left = copy_to_guest(kinfo->d, kinfo->dtb_paddr, >> + kinfo->fdt, >> + fdt_totalsize(kinfo->fdt)); >> + >> + if ( left != 0 ) >> + panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n", >> + kinfo->d, left); >> + xfree(kinfo->fdt); >> +} >> + >> +void __init initrd_load(struct kernel_info *kinfo, >> + copy_to_guest_phys_cb copy_to_guest) >> +{ >> + const struct bootmodule *mod = kinfo->initrd_bootmodule; >> + paddr_t load_addr = kinfo->initrd_paddr; >> + paddr_t paddr, len; >> + int node; >> + int res; >> + __be32 val[2]; >> + __be32 *cellp; >> + void __iomem *initrd; >> + >> + if ( !mod || !mod->size ) >> + return; >> + >> + paddr = mod->start; >> + len = mod->size; >> + >> + printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n", >> + kinfo->d, paddr, load_addr, load_addr + len); >> + >> + /* Fix up linux,initrd-start and linux,initrd-end in /chosen */ >> + node = fdt_path_offset(kinfo->fdt, "/chosen"); >> + if ( node < 0 ) >> + panic("Cannot find the /chosen node\n"); >> + >> + cellp = (__be32 *)val; >> + dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr); >> + res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start", >> + val, sizeof(val)); >> + if ( res ) >> + panic("Cannot fix up \"linux,initrd-start\" property\n"); >> + >> + cellp = (__be32 *)val; >> + dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len); >> + res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end", >> + val, sizeof(val)); >> + if ( res ) >> + panic("Cannot fix up \"linux,initrd-end\" property\n"); >> + >> + initrd = ioremap_wc(paddr, len); >> + if ( !initrd ) >> + panic("Unable to map the hwdom initrd\n"); > The original message was: > > panic("Unable to map the %pd initrd\n", kinfo->d); > > why change it? It can be called for domUs. > > >> + res = copy_to_guest(kinfo->d, load_addr, >> + initrd, len); >> + if ( res != 0 ) >> + panic("Unable to copy the initrd in the hwdom memory\n"); > Same here, the original message was: > > panic("Unable to copy the initrd in the %pd memory\n", kinfo->d); This is "new" (introduced 1 month ago), so I just overlooked them when doing rebasing. I'll update the messages. Thanks for review. ~ Oleksii > > >> + iounmap(initrd); >> +} >> diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h >> index b79e9fabfe..4a0052b2e8 100644 >> --- a/xen/include/xen/fdt-domain-build.h >> +++ b/xen/include/xen/fdt-domain-build.h >> @@ -6,6 +6,7 @@ >> #include >> #include >> #include >> +#include >> #include >> >> struct domain; >> @@ -29,7 +30,37 @@ int make_memory_node(const struct kernel_info *kinfo, int addrcells, >> int sizecells, const struct membanks *mem); >> int make_timer_node(const struct kernel_info *kinfo); >> >> -unsigned int get_allocation_size(paddr_t size); >> + >> +static inline int get_allocation_size(paddr_t size) >> +{ >> + /* >> + * get_order_from_bytes returns the order greater than or equal to >> + * the given size, but we need less than or equal. Adding one to >> + * the size pushes an evenly aligned size into the next order, so >> + * we can then unconditionally subtract 1 from the order which is >> + * returned. >> + */ >> + return get_order_from_bytes(size + 1) - 1; >> +} >> + >> +typedef unsigned long (*copy_to_guest_phys_cb)(struct domain *d, >> + paddr_t gpa, >> + void *buf, >> + unsigned int len); >> + >> +void initrd_load(struct kernel_info *kinfo, >> + copy_to_guest_phys_cb copy_to_guest); >> + >> +void dtb_load(struct kernel_info *kinfo, >> + copy_to_guest_phys_cb copy_to_guest); >> + >> +int find_unallocated_memory(const struct kernel_info *kinfo, >> + const struct membanks *mem_banks[], >> + unsigned int nr_mem_banks, >> + struct membanks *free_regions, >> + int (*cb)(unsigned long s_gfn, >> + unsigned long e_gfn, >> + void *data)); >> >> #endif /* __XEN_FDT_DOMAIN_BUILD_H__ */ >> >> -- >> 2.49.0 >> --------------c3Tx0EG8Ky8f2ynJQQQ1P3ru Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 5/2/25 10:02 PM, Stefano Stabellini wrote:
On Fri, 2 May 2025, Oleksii Kurochko wrote:

Some functions of Arm's domain_build.c could be reused by dom0less or other
features connected to domain construction/build.

The following functions are moved to common:
- get_allocation_size().
- allocate_domheap_memory().
- guest_map_pages().
- allocate_bank_memory().
- add_hwdom_free_regions().
- find_unallocated_memory().
- allocate_memory().
- dtb_load().
- initrd_load().

The declaration of allocate_domheap_memory, allocate_bank_memory,
allocate_memory were moved in patch #5. Maybe their movement should be
in this patch?
Sure, it makes sense.




Prototype of dtb_load() and initrd_load() is updated to recieve a pointer
to copy_to_guest_phys() as some archs require
copy_to_guest_phys_fluch_dcache().

Update arm/include/asm/Makefile to generate  domain-build.h for Arm as it is
used by domain-build.c.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Change in v3:
 - Nothing changed. Only rebase.
---
Change in v2:
 - Use xen/fdt-domain-build.h instead of asm/domain_build.h.
---
 xen/arch/arm/domain_build.c           | 397 +------------------------
 xen/common/device-tree/Makefile       |   1 +
 xen/common/device-tree/domain-build.c | 404 ++++++++++++++++++++++++++
 xen/include/xen/fdt-domain-build.h    |  33 ++-
 4 files changed, 439 insertions(+), 396 deletions(-)
 create mode 100644 xen/common/device-tree/domain-build.c

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9d649b06b3..df29619c40 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -120,18 +120,6 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
     return vcpu_create(dom0, 0);
 }
 
-unsigned int __init get_allocation_size(paddr_t size)
-{
-    /*
-     * get_order_from_bytes returns the order greater than or equal to
-     * the given size, but we need less than or equal. Adding one to
-     * the size pushes an evenly aligned size into the next order, so
-     * we can then unconditionally subtract 1 from the order which is
-     * returned.
-     */
-    return get_order_from_bytes(size + 1) - 1;
-}
-
 /*
  * Insert the given pages into a memory bank, banks are ordered by address.
  *
@@ -418,98 +406,6 @@ static void __init allocate_memory_11(struct domain *d,
     }
 }
 
-bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
-                                    alloc_domheap_mem_cb cb, void *extra)
-{
-    unsigned int max_order = UINT_MAX;
-
-    while ( tot_size > 0 )
-    {
-        unsigned int order = get_allocation_size(tot_size);
-        struct page_info *pg;
-
-        order = min(max_order, order);
-
-        pg = alloc_domheap_pages(d, order, 0);
-        if ( !pg )
-        {
-            /*
-             * If we can't allocate one page, then it is unlikely to
-             * succeed in the next iteration. So bail out.
-             */
-            if ( !order )
-                return false;
-
-            /*
-             * If we can't allocate memory with order, then it is
-             * unlikely to succeed in the next iteration.
-             * Record the order - 1 to avoid re-trying.
-             */
-            max_order = order - 1;
-            continue;
-        }
-
-        if ( !cb(d, pg, order, extra) )
-            return false;
-
-        tot_size -= (1ULL << (PAGE_SHIFT + order));
-    }
-
-    return true;
-}
-
-static bool __init guest_map_pages(struct domain *d, struct page_info *pg,
-                                   unsigned int order, void *extra)
-{
-    gfn_t *sgfn = (gfn_t *)extra;
-    int res;
-
-    BUG_ON(!sgfn);
-    res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order);
-    if ( res )
-    {
-        dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
-        return false;
-    }
-
-    *sgfn = gfn_add(*sgfn, 1UL << order);
-
-    return true;
-}
-
-bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
-                                 paddr_t tot_size)
-{
-    struct membanks *mem = kernel_info_get_mem(kinfo);
-    struct domain *d = kinfo->d;
-    struct membank *bank;
-
-    /*
-     * allocate_bank_memory can be called with a tot_size of zero for
-     * the second memory bank. It is not an error and we can safely
-     * avoid creating a zero-size memory bank.
-     */
-    if ( tot_size == 0 )
-        return true;
-
-    bank = &mem->bank[mem->nr_banks];
-    bank->start = gfn_to_gaddr(sgfn);
-    bank->size = tot_size;
-
-    /*
-     * Allocate pages from the heap until tot_size is zero and map them to the
-     * guest using guest_map_pages, passing the starting gfn as extra parameter
-     * for the map operation.
-     */
-    if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) )
-        return false;
-
-    mem->nr_banks++;
-    kinfo->unassigned_mem -= bank->size;
-
-    return true;
-}
-
 /*
  * When PCI passthrough is available we want to keep the
  * "linux,pci-domain" in sync for every host bridge.
@@ -900,226 +796,6 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
     return 0;
 }
 
-static int __init add_hwdom_free_regions(unsigned long s_gfn,
-                                         unsigned long e_gfn, void *data)
-{
-    struct membanks *free_regions = data;
-    paddr_t start, size;
-    paddr_t s = pfn_to_paddr(s_gfn);
-    paddr_t e = pfn_to_paddr(e_gfn);
-    unsigned int i, j;
-
-    if ( free_regions->nr_banks >= free_regions->max_banks )
-        return 0;
-
-    /*
-     * Both start and size of the free region should be 2MB aligned to
-     * potentially allow superpage mapping.
-     */
-    start = (s + SZ_2M - 1) & ~(SZ_2M - 1);
-    if ( start > e )
-        return 0;
-
-    /*
-     * e is actually "end-1" because it is called by rangeset functions
-     * which are inclusive of the last address.
-     */
-    e += 1;
-    size = (e - start) & ~(SZ_2M - 1);
-
-    /* Find the insert position (descending order). */
-    for ( i = 0; i < free_regions->nr_banks ; i++ )
-        if ( size > free_regions->bank[i].size )
-            break;
-
-    /* Move the other banks to make space. */
-    for ( j = free_regions->nr_banks; j > i ; j-- )
-    {
-        free_regions->bank[j].start = free_regions->bank[j - 1].start;
-        free_regions->bank[j].size = free_regions->bank[j - 1].size;
-    }
-
-    free_regions->bank[i].start = start;
-    free_regions->bank[i].size = size;
-    free_regions->nr_banks++;
-
-    return 0;
-}
-
-/*
- * Find unused regions of Host address space which can be exposed to domain
- * using the host memory layout. In order to calculate regions we exclude every
- * region passed in mem_banks from the Host RAM.
- */
-static int __init find_unallocated_memory(const struct kernel_info *kinfo,
-                                          const struct membanks *mem_banks[],
-                                          unsigned int nr_mem_banks,
-                                          struct membanks *free_regions,
-                                          int (*cb)(unsigned long s_gfn,
-                                                    unsigned long e_gfn,
-                                                    void *data))
-{
-    const struct membanks *mem = bootinfo_get_mem();
-    struct rangeset *unalloc_mem;
-    paddr_t start, end;
-    unsigned int i, j;
-    int res;
-
-    ASSERT(domain_use_host_layout(kinfo->d));
-
-    unalloc_mem = rangeset_new(NULL, NULL, 0);
-    if ( !unalloc_mem )
-        return -ENOMEM;
-
-    /* Start with all available RAM */
-    for ( i = 0; i < mem->nr_banks; i++ )
-    {
-        start = mem->bank[i].start;
-        end = mem->bank[i].start + mem->bank[i].size;
-        res = rangeset_add_range(unalloc_mem, PFN_DOWN(start),
-                                 PFN_DOWN(end - 1));
-        if ( res )
-        {
-            printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n",
-                   start, end);
-            goto out;
-        }
-    }
-
-    /* Remove all regions listed in mem_banks */
-    for ( i = 0; i < nr_mem_banks; i++ )
-        for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
-        {
-            start = mem_banks[i]->bank[j].start;
-
-            /* Shared memory banks can contain INVALID_PADDR as start */
-            if ( INVALID_PADDR == start )
-                continue;
-
-            end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size;
-            res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start),
-                                        PFN_DOWN(end - 1));
-            if ( res )
-            {
-                printk(XENLOG_ERR
-                       "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n",
-                       start, end, res);
-                goto out;
-            }
-        }
-
-    start = 0;
-    end = (1ULL << p2m_ipa_bits) - 1;
-    res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end),
-                                 cb, free_regions);
-    if ( res )
-        free_regions->nr_banks = 0;
-    else if ( !free_regions->nr_banks )
-        res = -ENOENT;
-
-out:
-    rangeset_destroy(unalloc_mem);
-
-    return res;
-}
-
-void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
-{
-    struct membanks *mem = kernel_info_get_mem(kinfo);
-    unsigned int i, nr_banks = GUEST_RAM_BANKS;
-    struct membanks *hwdom_free_mem = NULL;
-
-    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
-           /* Don't want format this as PRIpaddr (16 digit hex) */
-           (unsigned long)(kinfo->unassigned_mem >> 20), d);
-
-    mem->nr_banks = 0;
-    /*
-     * Use host memory layout for hwdom. Only case for this is when LLC coloring
-     * is enabled.
-     */
-    if ( is_hardware_domain(d) )
-    {
-        struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
-        /*
-         * Exclude the following regions:
-         * 1) Remove reserved memory
-         * 2) Grant table assigned to hwdom
-         */
-        const struct membanks *mem_banks[] = {
-            bootinfo_get_reserved_mem(),
-            gnttab,
-        };
-
-        if ( !gnttab )
-            goto fail;
-
-        gnttab->nr_banks = 1;
-        gnttab->bank[0].start = kinfo->gnttab_start;
-        gnttab->bank[0].size = kinfo->gnttab_size;
-
-        hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
-        if ( !hwdom_free_mem )
-            goto fail;
-
-        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
-                                     hwdom_free_mem, add_hwdom_free_regions) )
-            goto fail;
-
-        nr_banks = hwdom_free_mem->nr_banks;
-        xfree(gnttab);
-    }
-
-    for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- )
-    {
-        paddr_t bank_start, bank_size;
-
-        if ( is_hardware_domain(d) )
-        {
-            bank_start = hwdom_free_mem->bank[i].start;
-            bank_size = hwdom_free_mem->bank[i].size;
-        }
-        else
-        {
-            const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
-            const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
-
-            if ( i >= GUEST_RAM_BANKS )
-                goto fail;
-
-            bank_start = bankbase[i];
-            bank_size = banksize[i];
-        }
-
-        bank_size = MIN(bank_size, kinfo->unassigned_mem);
-        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) )
-            goto fail;
-    }
-
-    if ( kinfo->unassigned_mem )
-        goto fail;
-
-    for( i = 0; i < mem->nr_banks; i++ )
-    {
-        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
-               d,
-               i,
-               mem->bank[i].start,
-               mem->bank[i].start + mem->bank[i].size,
-               /* Don't want format this as PRIpaddr (16 digit hex) */
-               (unsigned long)(mem->bank[i].size >> 20));
-    }
-
-    xfree(hwdom_free_mem);
-    return;
-
-  fail:
-    panic("Failed to allocate requested domain memory."
-          /* Don't want format this as PRIpaddr (16 digit hex) */
-          " %ldKB unallocated. Fix the VMs configurations.\n",
-          (unsigned long)kinfo->unassigned_mem >> 10);
-}
-
 static int __init handle_pci_range(const struct dt_device_node *dev,
                                    uint64_t addr, uint64_t len, void *data)
 {
@@ -2059,75 +1735,6 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo)
     return -EINVAL;
 }
 
-static void __init dtb_load(struct kernel_info *kinfo)
-{
-    unsigned long left;
-
-    printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, kinfo->dtb_paddr,
-           kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
-
-    left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
-                                           kinfo->fdt,
-                                           fdt_totalsize(kinfo->fdt));
-
-    if ( left != 0 )
-        panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n",
-              kinfo->d, left);
-    xfree(kinfo->fdt);
-}
-
-static void __init initrd_load(struct kernel_info *kinfo)
-{
-    const struct bootmodule *mod = kinfo->initrd_bootmodule;
-    paddr_t load_addr = kinfo->initrd_paddr;
-    paddr_t paddr, len;
-    int node;
-    int res;
-    __be32 val[2];
-    __be32 *cellp;
-    void __iomem *initrd;
-
-    if ( !mod || !mod->size )
-        return;
-
-    paddr = mod->start;
-    len = mod->size;
-
-    printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, paddr, load_addr, load_addr + len);
-
-    /* Fix up linux,initrd-start and linux,initrd-end in /chosen */
-    node = fdt_path_offset(kinfo->fdt, "/chosen");
-    if ( node < 0 )
-        panic("Cannot find the /chosen node\n");
-
-    cellp = (__be32 *)val;
-    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr);
-    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start",
-                              val, sizeof(val));
-    if ( res )
-        panic("Cannot fix up \"linux,initrd-start\" property\n");
-
-    cellp = (__be32 *)val;
-    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len);
-    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end",
-                              val, sizeof(val));
-    if ( res )
-        panic("Cannot fix up \"linux,initrd-end\" property\n");
-
-    initrd = ioremap_wc(paddr, len);
-    if ( !initrd )
-        panic("Unable to map the %pd initrd\n", kinfo->d);
-
-    res = copy_to_guest_phys_flush_dcache(kinfo->d, load_addr,
-                                          initrd, len);
-    if ( res != 0 )
-        panic("Unable to copy the initrd in the %pd memory\n", kinfo->d);
-
-    iounmap(initrd);
-}
-
 /*
  * Allocate the event channel PPIs and setup the HVM_PARAM_CALLBACK_IRQ.
  * The allocated IRQ will be found in d->arch.evtchn_irq.
@@ -2220,8 +1827,8 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
      */
     kernel_load(kinfo);
     /* initrd_load will fix up the fdt, so call it before dtb_load */
-    initrd_load(kinfo);
-    dtb_load(kinfo);
+    initrd_load(kinfo, copy_to_guest_phys_flush_dcache);
+    dtb_load(kinfo, copy_to_guest_phys_flush_dcache);
 
     memset(regs, 0, sizeof(*regs));
 
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index e88a4d5799..831b91399b 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,6 +1,7 @@
 obj-y += bootfdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
+obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
new file mode 100644
index 0000000000..69257a15ba
--- /dev/null
+++ b/xen/common/device-tree/domain-build.c
@@ -0,0 +1,404 @@
+#include <xen/bootfdt.h>
+#include <xen/fdt-domain-build.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/libfdt/libfdt.h>
+#include <xen/mm.h>
+#include <xen/sched.h>
+#include <xen/sizes.h>
+#include <xen/types.h>
+#include <xen/vmap.h>
+
+#include <asm/p2m.h>
+
+bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
+                                    alloc_domheap_mem_cb cb, void *extra)
+{
+    unsigned int max_order = UINT_MAX;
+
+    while ( tot_size > 0 )
+    {
+        unsigned int order = get_allocation_size(tot_size);
+        struct page_info *pg;
+
+        order = min(max_order, order);
+
+        pg = alloc_domheap_pages(d, order, 0);
+        if ( !pg )
+        {
+            /*
+             * If we can't allocate one page, then it is unlikely to
+             * succeed in the next iteration. So bail out.
+             */
+            if ( !order )
+                return false;
+
+            /*
+             * If we can't allocate memory with order, then it is
+             * unlikely to succeed in the next iteration.
+             * Record the order - 1 to avoid re-trying.
+             */
+            max_order = order - 1;
+            continue;
+        }
+
+        if ( !cb(d, pg, order, extra) )
+            return false;
+
+        tot_size -= (1ULL << (PAGE_SHIFT + order));
+    }
+
+    return true;
+}
+
+static bool __init guest_map_pages(struct domain *d, struct page_info *pg,
+                                   unsigned int order, void *extra)
+{
+    gfn_t *sgfn = (gfn_t *)extra;
+    int res;
+
+    BUG_ON(!sgfn);
+    res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order);
+    if ( res )
+    {
+        dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
+        return false;
+    }
+
+    *sgfn = gfn_add(*sgfn, 1UL << order);
+
+    return true;
+}
+
+bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
+                                 paddr_t tot_size)
+{
+    struct membanks *mem = kernel_info_get_mem(kinfo);
+    struct domain *d = kinfo->d;
+    struct membank *bank;
+
+    /*
+     * allocate_bank_memory can be called with a tot_size of zero for
+     * the second memory bank. It is not an error and we can safely
+     * avoid creating a zero-size memory bank.
+     */
+    if ( tot_size == 0 )
+        return true;
+
+    bank = &mem->bank[mem->nr_banks];
+    bank->start = gfn_to_gaddr(sgfn);
+    bank->size = tot_size;
+
+    /*
+     * Allocate pages from the heap until tot_size is zero and map them to the
+     * guest using guest_map_pages, passing the starting gfn as extra parameter
+     * for the map operation.
+     */
+    if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) )
+        return false;
+
+    mem->nr_banks++;
+    kinfo->unassigned_mem -= bank->size;
+
+    return true;
+}
+
+static int __init add_hwdom_free_regions(unsigned long s_gfn,
+                                         unsigned long e_gfn, void *data)
+{
+    struct membanks *free_regions = data;
+    paddr_t start, size;
+    paddr_t s = pfn_to_paddr(s_gfn);
+    paddr_t e = pfn_to_paddr(e_gfn);
+    unsigned int i, j;
+
+    if ( free_regions->nr_banks >= free_regions->max_banks )
+        return 0;
+
+    /*
+     * Both start and size of the free region should be 2MB aligned to
+     * potentially allow superpage mapping.
+     */
+    start = (s + SZ_2M - 1) & ~(SZ_2M - 1);
+    if ( start > e )
+        return 0;
+
+    /*
+     * e is actually "end-1" because it is called by rangeset functions
+     * which are inclusive of the last address.
+     */
+    e += 1;
+    size = (e - start) & ~(SZ_2M - 1);
+
+    /* Find the insert position (descending order). */
+    for ( i = 0; i < free_regions->nr_banks ; i++ )
+        if ( size > free_regions->bank[i].size )
+            break;
+
+    /* Move the other banks to make space. */
+    for ( j = free_regions->nr_banks; j > i ; j-- )
+    {
+        free_regions->bank[j].start = free_regions->bank[j - 1].start;
+        free_regions->bank[j].size = free_regions->bank[j - 1].size;
+    }
+
+    free_regions->bank[i].start = start;
+    free_regions->bank[i].size = size;
+    free_regions->nr_banks++;
+
+    return 0;
+}
+
+/*
+ * Find unused regions of Host address space which can be exposed to domain
+ * using the host memory layout. In order to calculate regions we exclude every
+ * region passed in mem_banks from the Host RAM.
+ */
+int __init find_unallocated_memory(const struct kernel_info *kinfo,
+                                   const struct membanks *mem_banks[],
+                                   unsigned int nr_mem_banks,
+                                   struct membanks *free_regions,
+                                   int (*cb)(unsigned long s_gfn,
+                                             unsigned long e_gfn,
+                                             void *data))
+{
+    const struct membanks *mem = bootinfo_get_mem();
+    struct rangeset *unalloc_mem;
+    paddr_t start, end;
+    unsigned int i, j;
+    int res;
+
+    ASSERT(domain_use_host_layout(kinfo->d));
+
+    unalloc_mem = rangeset_new(NULL, NULL, 0);
+    if ( !unalloc_mem )
+        return -ENOMEM;
+
+    /* Start with all available RAM */
+    for ( i = 0; i < mem->nr_banks; i++ )
+    {
+        start = mem->bank[i].start;
+        end = mem->bank[i].start + mem->bank[i].size;
+        res = rangeset_add_range(unalloc_mem, PFN_DOWN(start),
+                                 PFN_DOWN(end - 1));
+        if ( res )
+        {
+            printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n",
+                   start, end);
+            goto out;
+        }
+    }
+
+    /* Remove all regions listed in mem_banks */
+    for ( i = 0; i < nr_mem_banks; i++ )
+        for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
+        {
+            start = mem_banks[i]->bank[j].start;
+
+            /* Shared memory banks can contain INVALID_PADDR as start */
+            if ( INVALID_PADDR == start )
+                continue;
+
+            end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size;
+            res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start),
+                                        PFN_DOWN(end - 1));
+            if ( res )
+            {
+                printk(XENLOG_ERR
+                       "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n",
+                       start, end, res);
+                goto out;
+            }
+        }
+
+    start = 0;
+    end = (1ULL << p2m_ipa_bits) - 1;
+    res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end),
+                                 cb, free_regions);
+    if ( res )
+        free_regions->nr_banks = 0;
+    else if ( !free_regions->nr_banks )
+        res = -ENOENT;
+
+out:
+    rangeset_destroy(unalloc_mem);
+
+    return res;
+}
+
+void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+    struct membanks *mem = kernel_info_get_mem(kinfo);
+    unsigned int i, nr_banks = GUEST_RAM_BANKS;
+    struct membanks *hwdom_free_mem = NULL;
+
+    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
+           /* Don't want format this as PRIpaddr (16 digit hex) */
+           (unsigned long)(kinfo->unassigned_mem >> 20), d);
+
+    mem->nr_banks = 0;
+    /*
+     * Use host memory layout for hwdom. Only case for this is when LLC coloring
+     * is enabled.
+     */
+    if ( is_hardware_domain(d) )
+    {
+        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);

shouldn't we set gnttab->max_banks and gnttab->type here?
Here and ...





+        /*
+         * Exclude the following regions:
+         * 1) Remove reserved memory
+         * 2) Grant table assigned to hwdom
+         */
+        const struct membanks *mem_banks[] = {
+            bootinfo_get_reserved_mem(),
+            gnttab,
+        };
+
+        if ( !gnttab )
+            goto fail;
+
+        gnttab->nr_banks = 1;
+        gnttab->bank[0].start = kinfo->gnttab_start;
+        gnttab->bank[0].size = kinfo->gnttab_size;
+
+        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
+                                             NR_MEM_BANKS);
+        if ( !hwdom_free_mem )
+            goto fail;
+
+        hwdom_free_mem->max_banks = NR_MEM_BANKS;

here we are missing setting hwdom_free_mem->type ?
... here, membanks_xzalloc() should be really used.
for the first one case - membanks_xzalloc(1, MEMORY) and
for the second - membanks_xzalloc(NR_MEM_BANKS, MEMORY).
Good catch.



+
+        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
+                                     hwdom_free_mem, add_hwdom_free_regions) )
+            goto fail;
+
+        nr_banks = hwdom_free_mem->nr_banks;
+        xfree(gnttab);
+    }
+
+    for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- )
+    {
+        paddr_t bank_start, bank_size;
+
+        if ( is_hardware_domain(d) )
+        {
+            bank_start = hwdom_free_mem->bank[i].start;
+            bank_size = hwdom_free_mem->bank[i].size;
+        }
+        else
+        {
+            const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+            const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
+
+            if ( i >= GUEST_RAM_BANKS )
+                goto fail;
+
+            bank_start = bankbase[i];
+            bank_size = banksize[i];
+        }
+
+        bank_size = MIN(bank_size, kinfo->unassigned_mem);
+        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) )
+            goto fail;
+    }
+
+    if ( kinfo->unassigned_mem )
+        goto fail;
+
+    for( i = 0; i < mem->nr_banks; i++ )
+    {
+        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
+               d,
+               i,
+               mem->bank[i].start,
+               mem->bank[i].start + mem->bank[i].size,
+               /* Don't want format this as PRIpaddr (16 digit hex) */
+               (unsigned long)(mem->bank[i].size >> 20));
+    }
+
+    xfree(hwdom_free_mem);
+    return;
+
+  fail:
+    panic("Failed to allocate requested domain memory."
+          /* Don't want format this as PRIpaddr (16 digit hex) */
+          " %ldKB unallocated. Fix the VMs configurations.\n",
+          (unsigned long)kinfo->unassigned_mem >> 10);
+}
+
+/* Copy data to guest physical address, then clean the region. */
+typedef unsigned long (*copy_to_guest_phys_cb)(struct domain *d,
+                                               paddr_t gpa,
+                                               void *buf,
+                                               unsigned int len);

This shouldn't be needed because copy_to_guest_phys_cb is already
declared in xen/include/xen/fdt-domain-build.h



+void __init dtb_load(struct kernel_info *kinfo,
+                     copy_to_guest_phys_cb copy_to_guest)
+{
+    unsigned long left;
+
+    printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+           kinfo->d, kinfo->dtb_paddr,
+           kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
+
+    left = copy_to_guest(kinfo->d, kinfo->dtb_paddr,
+                         kinfo->fdt,
+                         fdt_totalsize(kinfo->fdt));
+
+    if ( left != 0 )
+        panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n",
+              kinfo->d, left);
+    xfree(kinfo->fdt);
+}
+
+void __init initrd_load(struct kernel_info *kinfo,
+                        copy_to_guest_phys_cb copy_to_guest)
+{
+    const struct bootmodule *mod = kinfo->initrd_bootmodule;
+    paddr_t load_addr = kinfo->initrd_paddr;
+    paddr_t paddr, len;
+    int node;
+    int res;
+    __be32 val[2];
+    __be32 *cellp;
+    void __iomem *initrd;
+
+    if ( !mod || !mod->size )
+        return;
+
+    paddr = mod->start;
+    len = mod->size;
+
+    printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+           kinfo->d, paddr, load_addr, load_addr + len);
+
+    /* Fix up linux,initrd-start and linux,initrd-end in /chosen */
+    node = fdt_path_offset(kinfo->fdt, "/chosen");
+    if ( node < 0 )
+        panic("Cannot find the /chosen node\n");
+
+    cellp = (__be32 *)val;
+    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr);
+    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start",
+                              val, sizeof(val));
+    if ( res )
+        panic("Cannot fix up \"linux,initrd-start\" property\n");
+
+    cellp = (__be32 *)val;
+    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len);
+    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end",
+                              val, sizeof(val));
+    if ( res )
+        panic("Cannot fix up \"linux,initrd-end\" property\n");
+
+    initrd = ioremap_wc(paddr, len);
+    if ( !initrd )
+        panic("Unable to map the hwdom initrd\n");

The original message was:

  panic("Unable to map the %pd initrd\n", kinfo->d);

why change it? It can be called for domUs.



+    res = copy_to_guest(kinfo->d, load_addr,
+                        initrd, len);
+    if ( res != 0 )
+        panic("Unable to copy the initrd in the hwdom memory\n");

Same here, the original message was:

  panic("Unable to copy the initrd in the %pd memory\n", kinfo->d);
This is "new" (introduced 1 month ago), so I just overlooked them when doing rebasing. I'll update
the messages.

Thanks for review.

~ Oleksii




+    iounmap(initrd);
+}
diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
index b79e9fabfe..4a0052b2e8 100644
--- a/xen/include/xen/fdt-domain-build.h
+++ b/xen/include/xen/fdt-domain-build.h
@@ -6,6 +6,7 @@
 #include <xen/bootfdt.h>
 #include <xen/device_tree.h>
 #include <xen/fdt-kernel.h>
+#include <xen/mm.h>
 #include <xen/types.h>
 
 struct domain;
@@ -29,7 +30,37 @@ int make_memory_node(const struct kernel_info *kinfo, int addrcells,
                      int sizecells, const struct membanks *mem);
 int make_timer_node(const struct kernel_info *kinfo);
 
-unsigned int get_allocation_size(paddr_t size);
+
+static inline int get_allocation_size(paddr_t size)
+{
+    /*
+     * get_order_from_bytes returns the order greater than or equal to
+     * the given size, but we need less than or equal. Adding one to
+     * the size pushes an evenly aligned size into the next order, so
+     * we can then unconditionally subtract 1 from the order which is
+     * returned.
+     */
+    return get_order_from_bytes(size + 1) - 1;
+}
+
+typedef unsigned long (*copy_to_guest_phys_cb)(struct domain *d,
+                                               paddr_t gpa,
+                                               void *buf,
+                                               unsigned int len);
+
+void initrd_load(struct kernel_info *kinfo,
+                 copy_to_guest_phys_cb copy_to_guest);
+
+void dtb_load(struct kernel_info *kinfo,
+              copy_to_guest_phys_cb copy_to_guest);
+
+int find_unallocated_memory(const struct kernel_info *kinfo,
+                            const struct membanks *mem_banks[],
+                            unsigned int nr_mem_banks,
+                            struct membanks *free_regions,
+                            int (*cb)(unsigned long s_gfn,
+                                      unsigned long e_gfn,
+                                      void *data));
 
 #endif /* __XEN_FDT_DOMAIN_BUILD_H__ */
 
-- 
2.49.0
--------------c3Tx0EG8Ky8f2ynJQQQ1P3ru-- From xen-devel-bounces@lists.xenproject.org Mon May 05 10:40:40 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 10:40:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975970.1363240 (Exim 4.92) (envelope-from ) id 1uBtFP-0001E0-VA; Mon, 05 May 2025 10:40:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975970.1363240; Mon, 05 May 2025 10:40:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBtFP-0001Dt-Sd; Mon, 05 May 2025 10:40:31 +0000 Received: by outflank-mailman (input) for mailman id 975970; Mon, 05 May 2025 10:40:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBtFN-0001Dn-TO for xen-devel@lists.xenproject.org; Mon, 05 May 2025 10:40:30 +0000 Received: from fout-a2-smtp.messagingengine.com (fout-a2-smtp.messagingengine.com [103.168.172.145]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 59fde89b-299d-11f0-9ffb-bf95429c2676; Mon, 05 May 2025 12:40:25 +0200 (CEST) Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.phl.internal (Postfix) with ESMTP id B63CA13808CB; Mon, 5 May 2025 06:40:23 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Mon, 05 May 2025 06:40:23 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 5 May 2025 06:40:22 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 59fde89b-299d-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1746441623; x=1746528023; bh=29Ps2y4SaSAbFjQ5BF2wB8HEg3NPVt1KQ5XXQkA+MLs=; b= lTrohVdRcmxrX9xYyq23FDO2DuTmj8vVcY5jimWreokKllMAw/Kv+WUl7HU+EJEp FtpPRgNHKO01WveGDttTYRuSv8vr+3fi3vlMBpKBOkZK88VK5kuLRxYmUORmSkiU c3z242/KqO6lnNmAkNbexO/GHvZuUNu1+7k7jjA0sVVuNbnq2ofrYvYsKRIsYKJX DxJ8lxoVYhTrR/NAD/tI08+oCd54G8HgJ2HDAXf8G/SscaijDRqkrospEYz8c01J 3kg1ht1EGnteqZV9MHBIjlYgeMuB/7AthYsolLUFblxGPGR6Hyob9VqFxg3L/C7x +XJinbF8KhKSH+eGUxhSPw== 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=fm3; t= 1746441623; x=1746528023; bh=29Ps2y4SaSAbFjQ5BF2wB8HEg3NPVt1KQ5X XQkA+MLs=; b=UALJ/Fe+Zpg/TL8jax6wcijWeDKOrUA4vRZjCKdReAoR/Oy1RPx MpPrJv+YRp89JlFScRD/ibbSUNnB3Kcxiy03z3m8kxznEJOqIzBmgKKhsbXnDoE5 b6BL+jOWtOqIsaR/tUT8CsT1m7nGDyWvkBauyagHGUEoPtZz6n2GWrvoryCCPSlg TPxuOwzk5lVsIu4oqgWBXE9Lh5HxoB/AL8iyyn+wxe+5S8e883K9qz870tdHmq+3 i8jePewvmY3AQOWfx8eE+QBnSTwV4xFNTV8DH/0BNygtdvecYD7li2sX61S8CJxm dOD9MvJ05RqDnQqVEAE6yiO7XC/Z4tq4QwA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvkedtkeejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu ggftrfgrthhtvghrnhepudeffeehkedtfeelueduleejieeutdeludffveeikeekkeeige duleegudeujeffnecuffhomhgrihhnpeigvghnphhrohhjvggtthdrohhrghdpghhithhh uhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdp nhgspghrtghpthhtohepkedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshhsth grsggvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepjhgsvghulhhitghh sehsuhhsvgdrtghomhdprhgtphhtthhopeigvghnihgrrdhrrghgihgruggrkhhouhesrg hmugdrtghomhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihig rdgtohhmpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtg hpthhtohepjhgrshhonhdrrghnughrhihukhesrghmugdrtghomhdprhgtphhtthhopegr ghgrrhgtihgrvhesrghmugdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlih hsthhsrdigvghnphhrohhjvggtthdrohhrgh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 5 May 2025 12:40:18 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Stefano Stabellini Cc: Jan Beulich , "Ragiadakou, Xenia" , Andrew Cooper , Roger Pau =?utf-8?B?TW9ubsOp?= , jason.andryuk@amd.com, agarciav@amd.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange Message-ID: References: <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oT+uxnubbYQ3cQdc" Content-Disposition: inline In-Reply-To: --oT+uxnubbYQ3cQdc Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 5 May 2025 12:40:18 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Stefano Stabellini Cc: Jan Beulich , "Ragiadakou, Xenia" , Andrew Cooper , Roger Pau =?utf-8?B?TW9ubsOp?= , jason.andryuk@amd.com, agarciav@amd.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote: > On Mon, 28 Apr 2025, Jan Beulich wrote: > > On 25.04.2025 22:19, Stefano Stabellini wrote: > > > From: Xenia Ragiadakou > > >=20 > > > Dom0 PVH might need XENMEM_exchange when passing contiguous memory > > > addresses to firmware or co-processors not behind an IOMMU. > >=20 > > I definitely don't understand the firmware part: It's subject to the > > same transparent P2M translations as the rest of the VM; it's just > > another piece of software running there. > >=20 > > "Co-processors not behind an IOMMU" is also interesting; a more > > concrete scenario might be nice, yet I realize you may be limited in > > what you're allowed to say. >=20 > Sure. On AMD x86 platforms there is a co-processor called PSP running > TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionally to > pass addresses to it. See drivers/tee/amdtee/ and > include/linux/psp-tee.h in Linux. We had (have?) similar issue with amdgpu (for integrated graphics) - it uses PSP for loading its firmware. With PV dom0 there is a workaround as dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, but I expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's the one I used for debugging this issue). References: https://lists.xenproject.org/archives/html/xen-devel/2022-06/msg01660.html https://github.com/QubesOS/qubes-issues/issues/6923 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --oT+uxnubbYQ3cQdc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgYlZMACgkQ24/THMrX 1yyX1wf/dXw+1AltqC+Ss5NgT6xGvdDHAXzQ2lKSjJ78Sru0OmZCeFhz7SGrP8o7 Em1tJo/fXVLkcjrYYUNnqkCoZPIk1PY/MZMGPLB9IC6t5/Vq+PWW1C1K96CjdRDz afK35JLLV4yqy69s7rSzAyhX4zym8tNH/VNJTzISIbVaZsd6bWrl4PZtHcjfIGt0 HMCIDZX4VDqK2RLMpm1EdmmSoQJ+4oL7pwAZgoTlj7jyaRAZzSp4XKZ2d2HXtbWf O34xZf55xG3RMTN6MwmVAw4dxHPswQIen9mnU48SMjfOEjfoIJqblPojygOx5bqW p2dPIBKx5DooDWoG/8nHjG0HucQeIQ== =Vldb -----END PGP SIGNATURE----- --oT+uxnubbYQ3cQdc-- From xen-devel-bounces@lists.xenproject.org Mon May 05 10:47:04 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 10:47:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975981.1363251 (Exim 4.92) (envelope-from ) id 1uBtLg-0001w9-IY; Mon, 05 May 2025 10:47:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975981.1363251; Mon, 05 May 2025 10:47: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 1uBtLg-0001w2-FJ; Mon, 05 May 2025 10:47:00 +0000 Received: by outflank-mailman (input) for mailman id 975981; Mon, 05 May 2025 10:46:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBtLe-0001vw-3W for xen-devel@lists.xenproject.org; Mon, 05 May 2025 10:46:58 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 42419709-299e-11f0-9ffb-bf95429c2676; Mon, 05 May 2025 12:46:54 +0200 (CEST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-ac345bd8e13so704939566b.0 for ; Mon, 05 May 2025 03:46:54 -0700 (PDT) Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5fa777c5a94sm5289446a12.26.2025.05.05.03.46.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 May 2025 03:46: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" X-Inumbo-ID: 42419709-299e-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746442014; x=1747046814; darn=lists.xenproject.org; h=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; bh=A523VmheOzqHsrElYC46Yg580McTffOJTQNKMDCNGOc=; b=Yf0aMSoI+TweTIx6teZqLg+NsyL4GbxjqpaM3eUkOz5eBHqDtksHgLAQV+B6VYO4Df cHshnBsDWKTMjf36P15IG9mihpeXxRJPGoIJHUomD4JNZLbMcZBrXWz+Y0BPvpAeq+3T C+xCpgkrFMlLYnh8EzyO4wNooWNz3iRCm/d4yV9DSTIt8VTuUNSCtfq+4oskJNccT5LE WikgpO/uQzZAD876PlqQNSkOkXsLv/DtggrJucbrVvaTrXE4Wt6DKgLZ2lDeXN3dfxZI Ak0n7uQiluOFAmd4gABkYO4Ntf8jk486lQvbIPwh9J22T/Djf6vBi8LuhiAJiq9tEXog qWEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746442014; x=1747046814; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=A523VmheOzqHsrElYC46Yg580McTffOJTQNKMDCNGOc=; b=VISBU2YeS6FHIXj4PaPJL3pBkdVPaJZWeywtXToRnipdTh/cUQd8OoPMwwFSnrHbIp a+H7mmyrI5hfAUJmRuFKZxJX/MdPN/+cA8Haeo64ja9Q3xAPW0+CjfS+E5qnwJ8+KsCZ C3S7xXLSWCSoJDwa0Z4naAY/SgT2V3Gp7ySX9AUE5vfvXHbRrimfcWlii3r7LHp3M+DP ntp3y4WT7gnDjZfBpKFHBv9cFk39bKofPcPuzp2I41ZmNd5fPPq3aqdFclCHQGpJc7iY qI4hSHTlKS5d+ecxkRDUJPHzcC03uHAUibuSfQU/Mc/zNWh26SLqyJY1tQ69dkRbkEym AG8A== X-Gm-Message-State: AOJu0YxHApVIUVHAC42LOhew3+fjInNtxPC+xBfTKD/bmUgQ7fKobXsJ trex/o3Flmxs9Oe6l7/BxQQbrGI4GwlcaOw+TRl4qjkCvVZeuF08 X-Gm-Gg: ASbGncvzQ9aFQHPlzUflCIRbI8aLlkPFgX2IdyemgscRBUMchn+vqp29fAl6UL/KMQ8 jhNqnS91yZlGLm3d2R4BMtrnSdAuxuMRVP5m1AxznbEN4o6mD4vK6rXfx4pMr1gGJWoUfQ2TtBG zxt3Vlnd6BsTScbxbMT/RVdR+fuzsQWUOtIULAmo5lSvbuUymrMAbcdz6WEKt/Bhu0UnYhqpw8W Xcd8RQ4pXv/C3G0vS9545Utbs75wDxIPklY8u8Cy3NBpC4XHSCz8pSbTAJnfHEjIdgRMpxYz1rU svqqGJNwe8W3h8xw/Z+H2pwxM0VwUu0m0B3RGkURhYZofAjGipV1nRs9uZLnM1JnS3hpc1QHIL7 GHqL16egq8eq635Ut X-Google-Smtp-Source: AGHT+IEx0z5AzVepwiFPpVFW72O2Q5nLS+hnX+3ELKFvKQx7dF6xIFbYElrxYHMFIT81FabXmO/jUw== X-Received: by 2002:a17:907:2dab:b0:ac7:95b5:f5d1 with SMTP id a640c23a62f3a-ad19083700dmr725466766b.42.1746442013171; Mon, 05 May 2025 03:46:53 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------5xbHStcDnUr1SCGu0GXO5f1l" Message-ID: <5523bf0d-a94e-444d-a1fa-035ecccb4448@gmail.com> Date: Mon, 5 May 2025 12:46:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 8/8] xen/common: dom0less: introduce common dom0less-build.c To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <76390ef52f108b580e1c397ed178ceadf1ae53c4.1746199009.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: This is a multi-part message in MIME format. --------------5xbHStcDnUr1SCGu0GXO5f1l Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/2/25 10:53 PM, Stefano Stabellini wrote: > On Fri, 2 May 2025, Oleksii Kurochko wrote: >> Part of Arm's dom0less-build.c could be common between architectures which are >> using device tree files to create guest domains. Thereby move some parts of >> Arm's dom0less-build.c to common code with minor changes. >> >> As a part of theses changes the following changes are introduced: >> - Introduce make_arch_nodes() to cover arch-specific nodes. For example, in >> case of Arm, it is PSCI and vpl011 nodes. >> - Introduce set_domain_type() to abstract a way how setting of domain type >> happens. For example, RISC-V won't have this member of arch_domain structure >> as vCPUs will always have the same bitness as hypervisor. In case of Arm, it >> is possible that Arm64 could create 32-bit and 64-bit domains. >> - Introduce init_vuart() to cover details of virtual uart initialization. >> - Introduce init_intc_phandle() to cover some details of interrupt controller >> phandle initialization. As an example, RISC-V could have different name for >> interrupt controller node ( APLIC, PLIC, IMSIC, etc ) but the code in >> domain_handle_dtb_bootmodule() could handle only one interrupt controller >> node name. >> - s/make_gic_domU_node/make_intc_domU_node as GIC is Arm specific naming and >> add prototype of make_intc_domU_node() to dom0less-build.h >> >> The following functions are moved to xen/common/device-tree: >> - Functions which are moved as is: >> - domain_p2m_pages(). >> - handle_passthrough_prop(). >> - handle_prop_pfdt(). >> - scan_pfdt_node(). >> - check_partial_fdt(). >> - Functions which are moved with some minor changes: >> - alloc_xenstore_evtchn(): >> - ifdef-ing by CONFIG_HVM accesses to hvm.params. >> - prepare_dtb_domU(): >> - ifdef-ing access to gnttab_{start,size} by CONFIG_GRANT_TABLE. >> - s/make_gic_domU_node/make_intc_domU_node. >> - Add call of make_arch_nodes(). >> - domain_handle_dtb_bootmodule(): >> - hide details of interrupt controller phandle initialization by calling >> init_intc_phandle(). >> - Update the comment above init_intc_phandle(): s/gic/interrupt controller. >> - construct_domU(): >> - ifdef-ing by CONFIG_HVM accesses to hvm.params. >> - Call init_vuart() to hide Arm's vpl011_init() details there. >> - Add call of set_domain_type() instead of setting kinfo->arch.type explicitly. >> >> Some parts of dom0less-build.c are wraped by #ifdef CONFIG_STATIC_{SHMEM,MEMORY} >> as not all archs support these configs. >> >> Signed-off-by: Oleksii Kurochko > FYI for a possible follow-up patch (doesn't have to be done in this > patch), the following functions could now be static: > > alloc_dom0_vcpu0 > dom0_max_vcpus I will make them static in follow-up patch in the next patch series version. > > > >> --- >> Change in v3: >> - Align construct_domU() with the current staging. >> - Align alloc_xenstore_params() with the current staging. >> - Move defintion of XENSTORE_PFN_LATE_ALLOC to common and >> declaration of need_xenstore to common. >> --- >> Change in v2: >> - Wrap by #ifdef CONFIG_STATIC_* inclusions of and >> . Wrap also the code which uses something from the >> mentioned headers. >> - Add handling of legacy case in construct_domU(). >> - Use xen/fdt-kernel.h and xen/fdt-domain-build.h instead of asm/*. >> - Update the commit message. >> --- >> xen/arch/arm/dom0less-build.c | 714 ++--------------------- >> xen/common/device-tree/dom0less-build.c | 699 ++++++++++++++++++++++ >> xen/include/asm-generic/dom0less-build.h | 18 +- >> 3 files changed, 751 insertions(+), 680 deletions(-) >> >> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c >> index 0310579863..627c212b3b 100644 >> --- a/xen/arch/arm/dom0less-build.c >> +++ b/xen/arch/arm/dom0less-build.c >> @@ -25,8 +25,6 @@ >> #include >> #include >> >> -bool __initdata need_xenstore; >> - >> #ifdef CONFIG_VGICV2 >> static int __init make_gicv2_domU_node(struct kernel_info *kinfo) >> { >> @@ -152,7 +150,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo) >> } >> #endif >> >> -static int __init make_gic_domU_node(struct kernel_info *kinfo) >> +int __init make_intc_domU_node(struct kernel_info *kinfo) >> { >> switch ( kinfo->d->arch.vgic.version ) >> { >> @@ -218,708 +216,60 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo) >> } >> #endif >> >> -/* >> - * Scan device tree properties for passthrough specific information. >> - * Returns < 0 on error >> - * 0 on success >> - */ >> -static int __init handle_passthrough_prop(struct kernel_info *kinfo, >> - const struct fdt_property *xen_reg, >> - const struct fdt_property *xen_path, >> - bool xen_force, >> - uint32_t address_cells, >> - uint32_t size_cells) >> -{ >> - const __be32 *cell; >> - unsigned int i, len; >> - struct dt_device_node *node; >> - int res; >> - paddr_t mstart, size, gstart; >> - >> - /* xen,reg specifies where to map the MMIO region */ >> - cell = (const __be32 *)xen_reg->data; >> - len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) * >> - sizeof(uint32_t)); >> - >> - for ( i = 0; i < len; i++ ) >> - { >> - device_tree_get_reg(&cell, address_cells, size_cells, >> - &mstart, &size); >> - gstart = dt_next_cell(address_cells, &cell); >> - >> - if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK ) >> - { >> - printk(XENLOG_ERR >> - "DomU passthrough config has not page aligned addresses/sizes\n"); >> - return -EINVAL; >> - } >> - >> - res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart), >> - paddr_to_pfn(PAGE_ALIGN(mstart + size - 1))); >> - if ( res ) >> - { >> - printk(XENLOG_ERR "Unable to permit to dom%d access to" >> - " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n", >> - kinfo->d->domain_id, >> - mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1); >> - return res; >> - } >> - >> - res = map_regions_p2mt(kinfo->d, >> - gaddr_to_gfn(gstart), >> - PFN_DOWN(size), >> - maddr_to_mfn(mstart), >> - p2m_mmio_direct_dev); >> - if ( res < 0 ) >> - { >> - printk(XENLOG_ERR >> - "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n", >> - mstart, gstart); >> - return -EFAULT; >> - } >> - } >> - >> - /* >> - * If xen_force, we let the user assign a MMIO region with no >> - * associated path. >> - */ >> - if ( xen_path == NULL ) >> - return xen_force ? 0 : -EINVAL; >> - >> - /* >> - * xen,path specifies the corresponding node in the host DT. >> - * Both interrupt mappings and IOMMU settings are based on it, >> - * as they are done based on the corresponding host DT node. >> - */ >> - node = dt_find_node_by_path(xen_path->data); >> - if ( node == NULL ) >> - { >> - printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n", >> - xen_path->data); >> - return -EINVAL; >> - } >> - >> - res = map_device_irqs_to_domain(kinfo->d, node, true, NULL); >> - if ( res < 0 ) >> - return res; >> - >> - res = iommu_add_dt_device(node); >> - if ( res < 0 ) >> - return res; >> - >> - /* If xen_force, we allow assignment of devices without IOMMU protection. */ >> - if ( xen_force && !dt_device_is_protected(node) ) >> - return 0; >> - >> - return iommu_assign_dt_device(kinfo->d, node); >> -} >> - >> -static int __init handle_prop_pfdt(struct kernel_info *kinfo, >> - const void *pfdt, int nodeoff, >> - uint32_t address_cells, uint32_t size_cells, >> - bool scan_passthrough_prop) >> -{ >> - void *fdt = kinfo->fdt; >> - int propoff, nameoff, res; >> - const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL; >> - const char *name; >> - bool found, xen_force = false; >> - >> - for ( propoff = fdt_first_property_offset(pfdt, nodeoff); >> - propoff >= 0; >> - propoff = fdt_next_property_offset(pfdt, propoff) ) >> - { >> - if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) ) >> - return -FDT_ERR_INTERNAL; >> - >> - found = false; >> - nameoff = fdt32_to_cpu(prop->nameoff); >> - name = fdt_string(pfdt, nameoff); >> - >> - if ( scan_passthrough_prop ) >> - { >> - if ( dt_prop_cmp("xen,reg", name) == 0 ) >> - { >> - xen_reg = prop; >> - found = true; >> - } >> - else if ( dt_prop_cmp("xen,path", name) == 0 ) >> - { >> - xen_path = prop; >> - found = true; >> - } >> - else if ( dt_prop_cmp("xen,force-assign-without-iommu", >> - name) == 0 ) >> - { >> - xen_force = true; >> - found = true; >> - } >> - } >> - >> - /* >> - * Copy properties other than the ones above: xen,reg, xen,path, >> - * and xen,force-assign-without-iommu. >> - */ >> - if ( !found ) >> - { >> - res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len)); >> - if ( res ) >> - return res; >> - } >> - } >> - >> - /* >> - * Only handle passthrough properties if both xen,reg and xen,path >> - * are present, or if xen,force-assign-without-iommu is specified. >> - */ >> - if ( xen_reg != NULL && (xen_path != NULL || xen_force) ) >> - { >> - res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force, >> - address_cells, size_cells); >> - if ( res < 0 ) >> - { >> - printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d); >> - return res; >> - } >> - } >> - else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) ) >> - { >> - printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n", >> - kinfo->d); >> - return -EINVAL; >> - } >> - >> - /* FDT_ERR_NOTFOUND => There is no more properties for this node */ >> - return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0; >> -} >> - >> -static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, >> - int nodeoff, >> - uint32_t address_cells, uint32_t size_cells, >> - bool scan_passthrough_prop) >> -{ >> - int rc = 0; >> - void *fdt = kinfo->fdt; >> - int node_next; >> - >> - rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL)); >> - if ( rc ) >> - return rc; >> - >> - rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells, >> - scan_passthrough_prop); >> - if ( rc ) >> - return rc; >> - >> - address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells", >> - DT_ROOT_NODE_ADDR_CELLS_DEFAULT); >> - size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells", >> - DT_ROOT_NODE_SIZE_CELLS_DEFAULT); >> - >> - node_next = fdt_first_subnode(pfdt, nodeoff); >> - while ( node_next > 0 ) >> - { >> - rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells, >> - scan_passthrough_prop); >> - if ( rc ) >> - return rc; >> - >> - node_next = fdt_next_subnode(pfdt, node_next); >> - } >> - >> - return fdt_end_node(fdt); >> -} >> - >> -static int __init check_partial_fdt(void *pfdt, size_t size) >> +int __init make_arch_nodes(struct kernel_info *kinfo) >> { >> - int res; >> - >> - if ( fdt_magic(pfdt) != FDT_MAGIC ) >> - { >> - dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree"); >> - return -EINVAL; >> - } >> - >> - res = fdt_check_header(pfdt); >> - if ( res ) >> - { >> - dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res); >> - return -EINVAL; >> - } >> - >> - if ( fdt_totalsize(pfdt) > size ) >> - { >> - dprintk(XENLOG_ERR, "Partial FDT totalsize is too big"); >> - return -EINVAL; >> - } >> - >> - return 0; >> -} >> - >> -static int __init domain_handle_dtb_bootmodule(struct domain *d, >> - struct kernel_info *kinfo) >> -{ >> - void *pfdt; >> - int res, node_next; >> - >> - pfdt = ioremap_cache(kinfo->dtb_bootmodule->start, >> - kinfo->dtb_bootmodule->size); >> - if ( pfdt == NULL ) >> - return -EFAULT; >> - >> - res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size); >> - if ( res < 0 ) >> - goto out; >> - >> - for ( node_next = fdt_first_subnode(pfdt, 0); >> - node_next > 0; >> - node_next = fdt_next_subnode(pfdt, node_next) ) >> - { >> - const char *name = fdt_get_name(pfdt, node_next, NULL); >> - >> - if ( name == NULL ) >> - continue; >> - >> - /* >> - * Only scan /gic /aliases /passthrough, ignore the rest. >> - * They don't have to be parsed in order. >> - * >> - * Take the GIC phandle value from the special /gic node in the >> - * DTB fragment. >> - */ >> - if ( dt_node_cmp(name, "gic") == 0 ) >> - { >> - uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); >> - >> - if ( phandle_intc != 0 ) >> - kinfo->phandle_intc = phandle_intc; >> - continue; >> - } >> - >> - if ( dt_node_cmp(name, "aliases") == 0 ) >> - { >> - res = scan_pfdt_node(kinfo, pfdt, node_next, >> - DT_ROOT_NODE_ADDR_CELLS_DEFAULT, >> - DT_ROOT_NODE_SIZE_CELLS_DEFAULT, >> - false); >> - if ( res ) >> - goto out; >> - continue; >> - } >> - if ( dt_node_cmp(name, "passthrough") == 0 ) >> - { >> - res = scan_pfdt_node(kinfo, pfdt, node_next, >> - DT_ROOT_NODE_ADDR_CELLS_DEFAULT, >> - DT_ROOT_NODE_SIZE_CELLS_DEFAULT, >> - true); >> - if ( res ) >> - goto out; >> - continue; >> - } >> - } >> - >> - out: >> - iounmap(pfdt); >> - >> - return res; >> -} >> - >> -/* >> - * The max size for DT is 2MB. However, the generated DT is small (not including >> - * domU passthrough DT nodes whose size we account separately), 4KB are enough >> - * for now, but we might have to increase it in the future. >> - */ >> -#define DOMU_DTB_SIZE 4096 >> -static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) >> -{ >> - int addrcells, sizecells; >> - int ret, fdt_size = DOMU_DTB_SIZE; >> - >> - kinfo->phandle_intc = GUEST_PHANDLE_GIC; >> - kinfo->gnttab_start = GUEST_GNTTAB_BASE; >> - kinfo->gnttab_size = GUEST_GNTTAB_SIZE; >> - >> - addrcells = GUEST_ROOT_ADDRESS_CELLS; >> - sizecells = GUEST_ROOT_SIZE_CELLS; >> - >> - /* Account for domU passthrough DT size */ >> - if ( kinfo->dtb_bootmodule ) >> - fdt_size += kinfo->dtb_bootmodule->size; >> - >> - /* Cap to max DT size if needed */ >> - fdt_size = min(fdt_size, SZ_2M); >> - >> - kinfo->fdt = xmalloc_bytes(fdt_size); >> - if ( kinfo->fdt == NULL ) >> - return -ENOMEM; >> - >> - ret = fdt_create(kinfo->fdt, fdt_size); >> - if ( ret < 0 ) >> - goto err; >> - >> - ret = fdt_finish_reservemap(kinfo->fdt); >> - if ( ret < 0 ) >> - goto err; >> - >> - ret = fdt_begin_node(kinfo->fdt, ""); >> - if ( ret < 0 ) >> - goto err; >> - >> - ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells); >> - if ( ret ) >> - goto err; >> - >> - ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells); >> - if ( ret ) >> - goto err; >> - >> - ret = make_chosen_node(kinfo); >> - if ( ret ) >> - goto err; >> + int ret; >> >> ret = make_psci_node(kinfo->fdt); >> if ( ret ) >> - goto err; >> - >> - ret = make_cpus_node(d, kinfo->fdt); >> - if ( ret ) >> - goto err; >> - >> - ret = make_memory_node(kinfo, addrcells, sizecells, >> - kernel_info_get_mem(kinfo)); >> - if ( ret ) >> - goto err; >> - >> - ret = make_resv_memory_node(kinfo, addrcells, sizecells); >> - if ( ret ) >> - goto err; >> - >> - /* >> - * domain_handle_dtb_bootmodule has to be called before the rest of >> - * the device tree is generated because it depends on the value of >> - * the field phandle_intc. >> - */ >> - if ( kinfo->dtb_bootmodule ) >> - { >> - ret = domain_handle_dtb_bootmodule(d, kinfo); >> - if ( ret ) >> - goto err; >> - } >> - >> - ret = make_gic_domU_node(kinfo); >> - if ( ret ) >> - goto err; >> - >> - ret = make_timer_node(kinfo); >> - if ( ret ) >> - goto err; >> + return -EINVAL; >> >> if ( kinfo->vuart ) >> { >> - ret = -EINVAL; >> #ifdef CONFIG_SBSA_VUART_CONSOLE >> ret = make_vpl011_uart_node(kinfo); >> #endif >> if ( ret ) >> - goto err; >> - } >> - >> - if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS ) >> - { >> - ret = make_hypervisor_node(d, kinfo, addrcells, sizecells); >> - if ( ret ) >> - goto err; >> + return -EINVAL; >> } >> >> - ret = fdt_end_node(kinfo->fdt); >> - if ( ret < 0 ) >> - goto err; >> - >> - ret = fdt_finish(kinfo->fdt); >> - if ( ret < 0 ) >> - goto err; >> - >> return 0; >> - >> - err: >> - printk("Device tree generation failed (%d).\n", ret); >> - xfree(kinfo->fdt); >> - >> - return -EINVAL; >> } >> >> -#define XENSTORE_PFN_OFFSET 1 >> -static int __init alloc_xenstore_page(struct domain *d) >> +/* TODO: make arch.type generic ? */ >> +#ifdef CONFIG_ARM_64 >> +void __init set_domain_type(struct domain *d, struct kernel_info *kinfo) >> { >> - struct page_info *xenstore_pg; >> - struct xenstore_domain_interface *interface; >> - mfn_t mfn; >> - gfn_t gfn; >> - int rc; >> - >> - if ( (UINT_MAX - d->max_pages) < 1 ) >> - { >> - printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n", >> - d); >> - return -EINVAL; >> - } >> - >> - d->max_pages += 1; >> - xenstore_pg = alloc_domheap_page(d, MEMF_bits(32)); >> - if ( xenstore_pg == NULL && is_64bit_domain(d) ) >> - xenstore_pg = alloc_domheap_page(d, 0); >> - if ( xenstore_pg == NULL ) >> - return -ENOMEM; >> - >> - mfn = page_to_mfn(xenstore_pg); >> - if ( !mfn_x(mfn) ) >> - return -ENOMEM; >> - >> - if ( !is_domain_direct_mapped(d) ) >> - gfn = gaddr_to_gfn(GUEST_MAGIC_BASE + >> - (XENSTORE_PFN_OFFSET << PAGE_SHIFT)); >> - else >> - gfn = gaddr_to_gfn(mfn_to_maddr(mfn)); >> - >> - rc = guest_physmap_add_page(d, gfn, mfn, 0); >> - if ( rc ) >> - { >> - free_domheap_page(xenstore_pg); >> - return rc; >> - } >> - >> - d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn); >> - interface = map_domain_page(mfn); >> - interface->connection = XENSTORE_RECONNECT; >> - unmap_domain_page(interface); >> - >> - return 0; >> + /* type must be set before allocate memory */ >> + d->arch.type = kinfo->arch.type; >> } >> - >> -static int __init alloc_xenstore_params(struct kernel_info *kinfo) >> +#else >> +void __init set_domain_type(struct domain *d, struct kernel_info *kinfo) >> { >> - struct domain *d = kinfo->d; >> - int rc = 0; >> - >> - if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY)) >> - == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) ) >> - d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC; >> - else if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE ) >> - { >> - rc = alloc_xenstore_page(d); >> - if ( rc < 0 ) >> - return rc; >> - } >> - >> - return rc; >> + /* Nothing to do */ >> } >> +#endif >> >> -static void __init domain_vcpu_affinity(struct domain *d, >> - const struct dt_device_node *node) >> +int __init init_vuart(struct domain *d, struct kernel_info *kinfo, >> + const struct dt_device_node *node) >> { >> - struct dt_device_node *np; >> - >> - dt_for_each_child_node(node, np) >> - { >> - const char *hard_affinity_str = NULL; >> - uint32_t val; >> - int rc; >> - struct vcpu *v; >> - cpumask_t affinity; >> - >> - if ( !dt_device_is_compatible(np, "xen,vcpu") ) >> - continue; >> - >> - if ( !dt_property_read_u32(np, "id", &val) ) >> - panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node)); >> - >> - if ( val >= d->max_vcpus ) >> - panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val, >> - dt_node_name(node), d->max_vcpus); >> - >> - v = d->vcpu[val]; >> - rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str); >> - if ( rc < 0 ) >> - continue; >> - >> - cpumask_clear(&affinity); >> - while ( *hard_affinity_str != '\0' ) >> - { >> - unsigned int start, end; >> - >> - start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); >> - >> - if ( *hard_affinity_str == '-' ) /* Range */ >> - { >> - hard_affinity_str++; >> - end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); >> - } >> - else /* Single value */ >> - end = start; >> - >> - if ( end >= nr_cpu_ids ) >> - panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node)); >> - >> - for ( ; start <= end; start++ ) >> - cpumask_set_cpu(start, &affinity); >> - >> - if ( *hard_affinity_str == ',' ) >> - hard_affinity_str++; >> - else if ( *hard_affinity_str != '\0' ) >> - break; >> - } >> + int rc = 0; >> >> - rc = vcpu_set_hard_affinity(v, &affinity); >> - if ( rc ) >> - panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n", >> - v->vcpu_id, rc, dt_node_name(node)); >> - } >> -} >> + kinfo->vuart = dt_property_read_bool(node, "vpl011"); >> >> -#ifdef CONFIG_ARCH_PAGING_MEMPOOL >> -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. >> + * Base address and irq number are needed when creating vpl011 device >> + * tree node in prepare_dtb_domU, so initialization on related variables >> + * shall be done first. >> */ >> - unsigned long memkb = 4 * (256 * smp_cpus + (maxmem_kb / 1024) + 128); >> - >> - BUILD_BUG_ON(PAGE_SIZE != SZ_4K); >> - >> - return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT); >> -} >> - >> -static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem, >> - const struct dt_device_node *node) >> -{ >> - unsigned long p2m_pages; >> - uint32_t p2m_mem_mb; >> - int rc; >> - >> - rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb); >> - /* If xen,domain-p2m-mem-mb is not specified, use the default value. */ >> - p2m_pages = rc ? >> - p2m_mem_mb << (20 - PAGE_SHIFT) : >> - domain_p2m_pages(mem, d->max_vcpus); >> - >> - spin_lock(&d->arch.paging.lock); >> - rc = p2m_set_allocation(d, p2m_pages, NULL); >> - spin_unlock(&d->arch.paging.lock); >> - >> - return rc; >> -} >> -#else /* !CONFIG_ARCH_PAGING_MEMPOOL */ >> -static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem, >> - const struct dt_device_node *node) >> -{ >> - return 0; >> -} >> -#endif /* CONFIG_ARCH_PAGING_MEMPOOL */ >> - >> -int __init construct_domU(struct domain *d, >> - const struct dt_device_node *node) >> -{ >> - struct kernel_info kinfo = KERNEL_INFO_INIT; >> - const char *dom0less_enhanced; >> - int rc; >> - u64 mem; >> - >> - rc = dt_property_read_u64(node, "memory", &mem); >> - if ( !rc ) >> - { >> - printk("Error building DomU: cannot read \"memory\" property\n"); >> - return -EINVAL; >> - } >> - kinfo.unassigned_mem = (paddr_t)mem * SZ_1K; >> - >> - rc = domain_p2m_set_allocation(d, mem, node); >> - if ( rc != 0 ) >> - return rc; >> - >> - printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n", >> - d->max_vcpus, mem); >> - >> - kinfo.vuart = dt_property_read_bool(node, "vpl011"); >> - if ( kinfo.vuart && is_hardware_domain(d) ) >> - panic("hardware domain cannot specify vpl011\n"); >> - >> - rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced); >> - if ( rc == -EILSEQ || >> - rc == -ENODATA || >> - (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) ) >> - { >> - need_xenstore = true; >> - kinfo.dom0less_feature = DOM0LESS_ENHANCED; >> - } >> - else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") ) >> - { >> - need_xenstore = true; >> - kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY; >> - } >> - else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) >> - kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS; >> - >> - if ( vcpu_create(d, 0) == NULL ) >> - return -ENOMEM; >> - >> - d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; >> - >> - kinfo.d = d; >> - >> - rc = kernel_probe(&kinfo, node); >> - if ( rc < 0 ) >> - return rc; >> - >> -#ifdef CONFIG_ARM_64 >> - /* type must be set before allocate memory */ >> - d->arch.type = kinfo.arch.type; >> -#endif >> - if ( is_hardware_domain(d) ) >> - { >> - rc = construct_hwdom(&kinfo, node); >> - if ( rc < 0 ) >> - return rc; >> - } > I think we should retain this chunk in the code movement. It is OK if it > is behind a #ifdef CONFIG_ARM. I'll is_hardware_domain() handling. I think it can be without #ifdef, it seems to me it is a good thing to re-use construct_hwdom() in the case of creation of h/w domain. > > >> - else >> + if ( kinfo->vuart ) >> { >> - if ( !dt_find_property(node, "xen,static-mem", NULL) ) >> - allocate_memory(d, &kinfo); >> - else if ( !is_domain_direct_mapped(d) ) >> - allocate_static_memory(d, &kinfo, node); >> - else >> - assign_static_memory_11(d, &kinfo, node); >> - >> - rc = process_shm(d, &kinfo, node); >> - if ( rc < 0 ) >> - return rc; >> - >> - /* >> - * Base address and irq number are needed when creating vpl011 device >> - * tree node in prepare_dtb_domU, so initialization on related variables >> - * shall be done first. >> - */ >> - if ( kinfo.vuart ) >> - { >> - rc = domain_vpl011_init(d, NULL); >> - if ( rc < 0 ) >> - return rc; >> - } >> - >> - rc = prepare_dtb_domU(d, &kinfo); >> - if ( rc < 0 ) >> - return rc; >> - >> - rc = construct_domain(d, &kinfo); >> + rc = domain_vpl011_init(d, NULL); >> if ( rc < 0 ) >> return rc; >> } >> >> - domain_vcpu_affinity(d, node); >> - >> - return alloc_xenstore_params(&kinfo); >> + return rc; >> } >> >> void __init arch_create_domUs(struct dt_device_node *node, >> @@ -995,6 +345,22 @@ void __init arch_create_domUs(struct dt_device_node *node, >> } >> } >> >> +int __init init_intc_phandle(struct kernel_info *kinfo, const char *name, >> + const int node_next, const void *pfdt) >> +{ >> + if ( dt_node_cmp(name, "gic") == 0 ) >> + { >> + uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); >> + >> + if ( phandle_intc != 0 ) >> + kinfo->phandle_intc = phandle_intc; >> + >> + return 0; >> + } >> + >> + return 1; >> +} >> + >> /* >> * Local variables: >> * mode: C >> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c >> index a01a8b6b1a..c3face5b90 100644 >> --- a/xen/common/device-tree/dom0less-build.c >> +++ b/xen/common/device-tree/dom0less-build.c >> @@ -3,24 +3,43 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> +#include >> +#include >> #include >> #include >> +#include >> #include >> +#include >> #include >> +#include >> #include >> #include >> #include >> +#include >> >> #include >> #include >> #include >> +#include >> >> #include >> #include >> >> +#ifdef CONFIG_STATIC_MEMORY >> +#include >> +#endif > #if __has_include ? > > >> +#ifdef CONFIG_STATIC_SHM >> +#include >> +#endif > Same here? I thought that if we have already some CONFIG_* then it is better to use #ifdef, but I am okay with changing it to __has_include. > > >> +#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX >> + >> static domid_t __initdata xs_domid = DOMID_INVALID; >> +static bool __initdata need_xenstore; >> >> void __init set_xs_domain(struct domain *d) >> { >> @@ -109,6 +128,686 @@ static void __init initialize_domU_xenstore(void) >> } >> } >> >> +/* >> + * Scan device tree properties for passthrough specific information. >> + * Returns < 0 on error >> + * 0 on success >> + */ >> +static int __init handle_passthrough_prop(struct kernel_info *kinfo, >> + const struct fdt_property *xen_reg, >> + const struct fdt_property *xen_path, >> + bool xen_force, >> + uint32_t address_cells, >> + uint32_t size_cells) >> +{ >> + const __be32 *cell; >> + unsigned int i, len; >> + struct dt_device_node *node; >> + int res; >> + paddr_t mstart, size, gstart; >> + >> + /* xen,reg specifies where to map the MMIO region */ >> + cell = (const __be32 *)xen_reg->data; >> + len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) * >> + sizeof(uint32_t)); >> + >> + for ( i = 0; i < len; i++ ) >> + { >> + device_tree_get_reg(&cell, address_cells, size_cells, >> + &mstart, &size); >> + gstart = dt_next_cell(address_cells, &cell); >> + >> + if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK ) >> + { >> + printk(XENLOG_ERR >> + "DomU passthrough config has not page aligned addresses/sizes\n"); >> + return -EINVAL; >> + } >> + >> + res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart), >> + paddr_to_pfn(PAGE_ALIGN(mstart + size - 1))); >> + if ( res ) >> + { >> + printk(XENLOG_ERR "Unable to permit to dom%d access to" >> + " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n", >> + kinfo->d->domain_id, >> + mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1); >> + return res; >> + } >> + >> + res = map_regions_p2mt(kinfo->d, >> + gaddr_to_gfn(gstart), >> + PFN_DOWN(size), >> + maddr_to_mfn(mstart), >> + p2m_mmio_direct_dev); >> + if ( res < 0 ) >> + { >> + printk(XENLOG_ERR >> + "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n", >> + mstart, gstart); >> + return -EFAULT; >> + } >> + } >> + >> + /* >> + * If xen_force, we let the user assign a MMIO region with no >> + * associated path. >> + */ >> + if ( xen_path == NULL ) >> + return xen_force ? 0 : -EINVAL; >> + >> + /* >> + * xen,path specifies the corresponding node in the host DT. >> + * Both interrupt mappings and IOMMU settings are based on it, >> + * as they are done based on the corresponding host DT node. >> + */ >> + node = dt_find_node_by_path(xen_path->data); >> + if ( node == NULL ) >> + { >> + printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n", >> + xen_path->data); >> + return -EINVAL; >> + } >> + >> + res = map_device_irqs_to_domain(kinfo->d, node, true, NULL); >> + if ( res < 0 ) >> + return res; >> + >> + res = iommu_add_dt_device(node); >> + if ( res < 0 ) >> + return res; >> + >> + /* If xen_force, we allow assignment of devices without IOMMU protection. */ >> + if ( xen_force && !dt_device_is_protected(node) ) >> + return 0; >> + >> + return iommu_assign_dt_device(kinfo->d, node); >> +} >> + >> +static int __init handle_prop_pfdt(struct kernel_info *kinfo, >> + const void *pfdt, int nodeoff, >> + uint32_t address_cells, uint32_t size_cells, >> + bool scan_passthrough_prop) >> +{ >> + void *fdt = kinfo->fdt; >> + int propoff, nameoff, res; >> + const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL; >> + const char *name; >> + bool found, xen_force = false; >> + >> + for ( propoff = fdt_first_property_offset(pfdt, nodeoff); >> + propoff >= 0; >> + propoff = fdt_next_property_offset(pfdt, propoff) ) >> + { >> + if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) ) >> + return -FDT_ERR_INTERNAL; >> + >> + found = false; >> + nameoff = fdt32_to_cpu(prop->nameoff); >> + name = fdt_string(pfdt, nameoff); >> + >> + if ( scan_passthrough_prop ) >> + { >> + if ( dt_prop_cmp("xen,reg", name) == 0 ) >> + { >> + xen_reg = prop; >> + found = true; >> + } >> + else if ( dt_prop_cmp("xen,path", name) == 0 ) >> + { >> + xen_path = prop; >> + found = true; >> + } >> + else if ( dt_prop_cmp("xen,force-assign-without-iommu", >> + name) == 0 ) >> + { >> + xen_force = true; >> + found = true; >> + } >> + } >> + >> + /* >> + * Copy properties other than the ones above: xen,reg, xen,path, >> + * and xen,force-assign-without-iommu. >> + */ >> + if ( !found ) >> + { >> + res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len)); >> + if ( res ) >> + return res; >> + } >> + } >> + >> + /* >> + * Only handle passthrough properties if both xen,reg and xen,path >> + * are present, or if xen,force-assign-without-iommu is specified. >> + */ >> + if ( xen_reg != NULL && (xen_path != NULL || xen_force) ) >> + { >> + res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force, >> + address_cells, size_cells); >> + if ( res < 0 ) >> + { >> + printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d); >> + return res; >> + } >> + } >> + else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) ) >> + { >> + printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n", >> + kinfo->d); >> + return -EINVAL; >> + } >> + >> + /* FDT_ERR_NOTFOUND => There is no more properties for this node */ >> + return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0; >> +} >> + >> +static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, >> + int nodeoff, >> + uint32_t address_cells, uint32_t size_cells, >> + bool scan_passthrough_prop) >> +{ >> + int rc = 0; >> + void *fdt = kinfo->fdt; >> + int node_next; >> + >> + rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL)); >> + if ( rc ) >> + return rc; >> + >> + rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells, >> + scan_passthrough_prop); >> + if ( rc ) >> + return rc; >> + >> + address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells", >> + DT_ROOT_NODE_ADDR_CELLS_DEFAULT); >> + size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells", >> + DT_ROOT_NODE_SIZE_CELLS_DEFAULT); >> + >> + node_next = fdt_first_subnode(pfdt, nodeoff); >> + while ( node_next > 0 ) >> + { >> + rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells, >> + scan_passthrough_prop); >> + if ( rc ) >> + return rc; >> + >> + node_next = fdt_next_subnode(pfdt, node_next); >> + } >> + >> + return fdt_end_node(fdt); >> +} >> + >> +static int __init check_partial_fdt(void *pfdt, size_t size) >> +{ >> + int res; >> + >> + if ( fdt_magic(pfdt) != FDT_MAGIC ) >> + { >> + dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree"); >> + return -EINVAL; >> + } >> + >> + res = fdt_check_header(pfdt); >> + if ( res ) >> + { >> + dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res); >> + return -EINVAL; >> + } >> + >> + if ( fdt_totalsize(pfdt) > size ) >> + { >> + dprintk(XENLOG_ERR, "Partial FDT totalsize is too big"); >> + return -EINVAL; >> + } >> + >> + return 0; >> +} >> + >> +static int __init domain_handle_dtb_bootmodule(struct domain *d, >> + struct kernel_info *kinfo) >> +{ >> + void *pfdt; >> + int res, node_next; >> + >> + pfdt = ioremap_cache(kinfo->dtb_bootmodule->start, >> + kinfo->dtb_bootmodule->size); >> + if ( pfdt == NULL ) >> + return -EFAULT; >> + >> + res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size); >> + if ( res < 0 ) >> + goto out; >> + >> + for ( node_next = fdt_first_subnode(pfdt, 0); >> + node_next > 0; >> + node_next = fdt_next_subnode(pfdt, node_next) ) >> + { >> + const char *name = fdt_get_name(pfdt, node_next, NULL); >> + >> + if ( name == NULL ) >> + continue; >> + >> + /* >> + * Only scan /$(interrupt_controller) /aliases /passthrough, >> + * ignore the rest. >> + * They don't have to be parsed in order. >> + * >> + * Take the interrupt controller phandle value from the special >> + * interrupt controller node in the DTB fragment. >> + */ >> + if ( init_intc_phandle(kinfo, name, node_next, pfdt) == 0 ) >> + continue; >> + >> + if ( dt_node_cmp(name, "aliases") == 0 ) >> + { >> + res = scan_pfdt_node(kinfo, pfdt, node_next, >> + DT_ROOT_NODE_ADDR_CELLS_DEFAULT, >> + DT_ROOT_NODE_SIZE_CELLS_DEFAULT, >> + false); >> + if ( res ) >> + goto out; >> + continue; >> + } >> + if ( dt_node_cmp(name, "passthrough") == 0 ) >> + { >> + res = scan_pfdt_node(kinfo, pfdt, node_next, >> + DT_ROOT_NODE_ADDR_CELLS_DEFAULT, >> + DT_ROOT_NODE_SIZE_CELLS_DEFAULT, >> + true); >> + if ( res ) >> + goto out; >> + continue; >> + } >> + } >> + >> + out: >> + iounmap(pfdt); >> + >> + return res; >> +} >> + >> +/* >> + * The max size for DT is 2MB. However, the generated DT is small (not including >> + * domU passthrough DT nodes whose size we account separately), 4KB are enough >> + * for now, but we might have to increase it in the future. >> + */ >> +#define DOMU_DTB_SIZE 4096 >> +static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) >> +{ >> + int addrcells, sizecells; >> + int ret, fdt_size = DOMU_DTB_SIZE; >> + >> + kinfo->phandle_intc = GUEST_PHANDLE_GIC; >> + >> +#ifdef CONFIG_GRANT_TABLE >> + kinfo->gnttab_start = GUEST_GNTTAB_BASE; >> + kinfo->gnttab_size = GUEST_GNTTAB_SIZE; >> +#endif >> + >> + addrcells = GUEST_ROOT_ADDRESS_CELLS; >> + sizecells = GUEST_ROOT_SIZE_CELLS; >> + >> + /* Account for domU passthrough DT size */ >> + if ( kinfo->dtb_bootmodule ) >> + fdt_size += kinfo->dtb_bootmodule->size; >> + >> + /* Cap to max DT size if needed */ >> + fdt_size = min(fdt_size, SZ_2M); >> + >> + kinfo->fdt = xmalloc_bytes(fdt_size); >> + if ( kinfo->fdt == NULL ) >> + return -ENOMEM; >> + >> + ret = fdt_create(kinfo->fdt, fdt_size); >> + if ( ret < 0 ) >> + goto err; >> + >> + ret = fdt_finish_reservemap(kinfo->fdt); >> + if ( ret < 0 ) >> + goto err; >> + >> + ret = fdt_begin_node(kinfo->fdt, ""); >> + if ( ret < 0 ) >> + goto err; >> + >> + ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells); >> + if ( ret ) >> + goto err; >> + >> + ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells); >> + if ( ret ) >> + goto err; >> + >> + ret = make_chosen_node(kinfo); >> + if ( ret ) >> + goto err; >> + >> + ret = make_cpus_node(d, kinfo->fdt); >> + if ( ret ) >> + goto err; >> + >> + ret = make_memory_node(kinfo, addrcells, sizecells, >> + kernel_info_get_mem(kinfo)); >> + if ( ret ) >> + goto err; >> + >> +#ifdef CONFIG_STATIC_SHM > This should not be necessary because there is a stub implementation of > make_resv_memory_node available in static-shmem.h for the > !CONFIG_STATIC_SHM case. But static-shmem.h isn't available on all architectures. Until static-shmem.h isn't moved to asm-generic or xen folders and then re-used by an architecture we have to have #ifdef. > > >> + ret = make_resv_memory_node(kinfo, addrcells, sizecells); >> + if ( ret ) >> + goto err; >> +#endif >> + >> + /* >> + * domain_handle_dtb_bootmodule has to be called before the rest of >> + * the device tree is generated because it depends on the value of >> + * the field phandle_intc. >> + */ >> + if ( kinfo->dtb_bootmodule ) >> + { >> + ret = domain_handle_dtb_bootmodule(d, kinfo); >> + if ( ret ) >> + goto err; >> + } >> + >> + ret = make_intc_domU_node(kinfo); >> + if ( ret ) >> + goto err; >> + >> + ret = make_timer_node(kinfo); >> + if ( ret ) >> + goto err; >> + >> + if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS ) >> + { >> + ret = make_hypervisor_node(d, kinfo, addrcells, sizecells); >> + if ( ret ) >> + goto err; >> + } >> + >> + ret = make_arch_nodes(kinfo); >> + if ( ret ) >> + goto err; >> + >> + ret = fdt_end_node(kinfo->fdt); >> + if ( ret < 0 ) >> + goto err; >> + >> + ret = fdt_finish(kinfo->fdt); >> + if ( ret < 0 ) >> + goto err; >> + >> + return 0; >> + >> + err: >> + printk("Device tree generation failed (%d).\n", ret); >> + xfree(kinfo->fdt); >> + >> + return -EINVAL; >> +} >> + >> +#define XENSTORE_PFN_OFFSET 1 >> +static int __init alloc_xenstore_page(struct domain *d) >> +{ >> + struct page_info *xenstore_pg; >> + struct xenstore_domain_interface *interface; >> + mfn_t mfn; >> + gfn_t gfn; >> + int rc; >> + >> + if ( (UINT_MAX - d->max_pages) < 1 ) >> + { >> + printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n", >> + d); >> + return -EINVAL; >> + } >> + >> + d->max_pages += 1; >> + xenstore_pg = alloc_domheap_page(d, MEMF_bits(32)); >> + if ( xenstore_pg == NULL && is_64bit_domain(d) ) >> + xenstore_pg = alloc_domheap_page(d, 0); >> + if ( xenstore_pg == NULL ) >> + return -ENOMEM; >> + >> + mfn = page_to_mfn(xenstore_pg); >> + if ( !mfn_x(mfn) ) >> + return -ENOMEM; >> + >> + if ( !is_domain_direct_mapped(d) ) >> + gfn = gaddr_to_gfn(GUEST_MAGIC_BASE + >> + (XENSTORE_PFN_OFFSET << PAGE_SHIFT)); >> + else >> + gfn = gaddr_to_gfn(mfn_to_maddr(mfn)); >> + >> + rc = guest_physmap_add_page(d, gfn, mfn, 0); >> + if ( rc ) >> + { >> + free_domheap_page(xenstore_pg); >> + return rc; >> + } >> + >> +#ifdef CONFIG_HVM >> + d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn); >> +#endif >> + interface = map_domain_page(mfn); >> + interface->connection = XENSTORE_RECONNECT; >> + unmap_domain_page(interface); >> + >> + return 0; >> +} >> + >> +static int __init alloc_xenstore_params(struct kernel_info *kinfo) >> +{ >> + struct domain *d = kinfo->d; >> + int rc = 0; >> + >> +#ifdef CONFIG_HVM >> + if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY)) >> + == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) ) >> + d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC; >> + else >> +#endif >> + if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE ) >> + { >> + rc = alloc_xenstore_page(d); >> + if ( rc < 0 ) >> + return rc; >> + } >> + >> + return rc; >> +} >> + >> +static void __init domain_vcpu_affinity(struct domain *d, >> + const struct dt_device_node *node) >> +{ >> + struct dt_device_node *np; >> + >> + dt_for_each_child_node(node, np) >> + { >> + const char *hard_affinity_str = NULL; >> + uint32_t val; >> + int rc; >> + struct vcpu *v; >> + cpumask_t affinity; >> + >> + if ( !dt_device_is_compatible(np, "xen,vcpu") ) >> + continue; >> + >> + if ( !dt_property_read_u32(np, "id", &val) ) >> + panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node)); >> + >> + if ( val >= d->max_vcpus ) >> + panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val, >> + dt_node_name(node), d->max_vcpus); >> + >> + v = d->vcpu[val]; >> + rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str); >> + if ( rc < 0 ) >> + continue; >> + >> + cpumask_clear(&affinity); >> + while ( *hard_affinity_str != '\0' ) >> + { >> + unsigned int start, end; >> + >> + start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); >> + >> + if ( *hard_affinity_str == '-' ) /* Range */ >> + { >> + hard_affinity_str++; >> + end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0); >> + } >> + else /* Single value */ >> + end = start; >> + >> + if ( end >= nr_cpu_ids ) >> + panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node)); >> + >> + for ( ; start <= end; start++ ) >> + cpumask_set_cpu(start, &affinity); >> + >> + if ( *hard_affinity_str == ',' ) >> + hard_affinity_str++; >> + else if ( *hard_affinity_str != '\0' ) >> + break; >> + } >> + >> + rc = vcpu_set_hard_affinity(v, &affinity); >> + if ( rc ) >> + panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n", >> + v->vcpu_id, rc, dt_node_name(node)); >> + } >> +} >> + >> +#ifdef CONFIG_ARCH_PAGING_MEMPOOL >> +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); >> + >> + BUILD_BUG_ON(PAGE_SIZE != SZ_4K); >> + >> + return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT); >> +} >> + >> +static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem, >> + const struct dt_device_node *node) >> +{ >> + unsigned long p2m_pages; >> + uint32_t p2m_mem_mb; >> + int rc; >> + >> + rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb); >> + /* If xen,domain-p2m-mem-mb is not specified, use the default value. */ >> + p2m_pages = rc ? >> + p2m_mem_mb << (20 - PAGE_SHIFT) : >> + domain_p2m_pages(mem, d->max_vcpus); >> + >> + spin_lock(&d->arch.paging.lock); >> + rc = p2m_set_allocation(d, p2m_pages, NULL); >> + spin_unlock(&d->arch.paging.lock); >> + >> + return rc; >> +} >> +#else /* !CONFIG_ARCH_PAGING_MEMPOOL */ >> +static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem, >> + const struct dt_device_node *node) >> +{ >> + return 0; >> +} >> +#endif /* CONFIG_ARCH_PAGING_MEMPOOL */ >> + >> +static int __init construct_domU(struct domain *d, >> + const struct dt_device_node *node) >> +{ >> + struct kernel_info kinfo = KERNEL_INFO_INIT; >> + const char *dom0less_enhanced; >> + int rc; >> + u64 mem; >> + >> + rc = dt_property_read_u64(node, "memory", &mem); >> + if ( !rc ) >> + { >> + printk("Error building DomU: cannot read \"memory\" property\n"); >> + return -EINVAL; >> + } >> + kinfo.unassigned_mem = (paddr_t)mem * SZ_1K; >> + >> + rc = domain_p2m_set_allocation(d, mem, node); >> + if ( rc != 0 ) >> + return rc; >> + >> + printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n", >> + d->max_vcpus, mem); >> + >> + rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced); >> + if ( rc == -EILSEQ || >> + rc == -ENODATA || >> + (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) ) >> + { >> + need_xenstore = true; >> + kinfo.dom0less_feature = DOM0LESS_ENHANCED; >> + } >> + else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") ) >> + { >> + need_xenstore = true; >> + kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY; >> + } >> + else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) >> + kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS; >> + >> + if ( vcpu_create(d, 0) == NULL ) >> + return -ENOMEM; >> + >> + d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; >> + >> + kinfo.d = d; >> + >> + rc = kernel_probe(&kinfo, node); >> + if ( rc < 0 ) >> + return rc; >> + >> + set_domain_type(d, &kinfo); >> + >> + if ( !dt_find_property(node, "xen,static-mem", NULL) ) >> + allocate_memory(d, &kinfo); >> +#ifdef CONFIG_STATIC_MEMORY > Also this should not be needed thanks to the stub implementation of > allocate_static_memory and assign_static_memory_11 > > >> + else if ( !is_domain_direct_mapped(d) ) >> + allocate_static_memory(d, &kinfo, node); >> + else >> + assign_static_memory_11(d, &kinfo, node); >> +#endif >> + >> +#ifdef CONFIG_STATIC_SHM > There is a stub for process_shm too The same as with make_resv_memory_node(), static-shmem.h header isn't available for all archs. I can return my patches which move static-shmem.h to asm-generic and then drop all the ifdef-s connect to it: https://lore.kernel.org/xen-devel/0203b98aa6a42aa69e22e7c973320add3ff4bb5d.1736334615.git.oleksii.kurochko@gmail.com/ https://lore.kernel.org/xen-devel/0203b98aa6a42aa69e22e7c973320add3ff4bb5d.1736334615.git.oleksii.kurochko@gmail.com/ Let me know if it is better to do now or should it be better to drop #ifdef-ing when an architrecture will require static-shmem or static-mem features? ~ Oleksii > >> + rc = process_shm(d, &kinfo, node); >> + if ( rc < 0 ) >> + return rc; >> +#endif >> + >> + rc = init_vuart(d, &kinfo, node); >> + if ( rc < 0 ) >> + return rc; >> + >> + rc = prepare_dtb_domU(d, &kinfo); >> + if ( rc < 0 ) >> + return rc; >> + >> + rc = construct_domain(d, &kinfo); >> + if ( rc < 0 ) >> + return rc; >> + >> + domain_vcpu_affinity(d, node); >> + >> + return alloc_xenstore_params(&kinfo); >> +} >> + >> void __init create_domUs(void) >> { >> struct dt_device_node *node; >> diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h >> index f095135caa..c00bb853d6 100644 >> --- a/xen/include/asm-generic/dom0less-build.h >> +++ b/xen/include/asm-generic/dom0less-build.h >> @@ -11,10 +11,7 @@ >> >> struct domain; >> struct dt_device_node; >> - >> -/* TODO: remove both when construct_domU() will be moved to common. */ >> -#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX >> -extern bool need_xenstore; >> +struct kernel_info; >> >> /* >> * List of possible features for dom0less domUs >> @@ -48,12 +45,21 @@ void create_domUs(void); >> bool is_dom0less_mode(void); >> void set_xs_domain(struct domain *d); >> >> -int construct_domU(struct domain *d, const struct dt_device_node *node); >> - >> void arch_create_domUs(struct dt_device_node *node, >> struct xen_domctl_createdomain *d_cfg, >> unsigned int flags); >> >> +int init_vuart(struct domain *d, struct kernel_info *kinfo, >> + const struct dt_device_node *node); >> + >> +int make_intc_domU_node(struct kernel_info *kinfo); >> +int make_arch_nodes(struct kernel_info *kinfo); >> + >> +void set_domain_type(struct domain *d, struct kernel_info *kinfo); >> + >> +int init_intc_phandle(struct kernel_info *kinfo, const char *name, >> + const int node_next, const void *pfdt); >> + >> #else /* !CONFIG_DOM0LESS_BOOT */ >> >> static inline void create_domUs(void) {} >> -- >> 2.49.0 >> --------------5xbHStcDnUr1SCGu0GXO5f1l Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 5/2/25 10:53 PM, Stefano Stabellini wrote:
On Fri, 2 May 2025, Oleksii Kurochko wrote:

Part of Arm's dom0less-build.c could be common between architectures which are
using device tree files to create guest domains. Thereby move some parts of
Arm's dom0less-build.c to common code with minor changes.

As a part of theses changes the following changes are introduced:
- Introduce make_arch_nodes() to cover arch-specific nodes. For example, in
  case of Arm, it is PSCI and vpl011 nodes.
- Introduce set_domain_type() to abstract a way how setting of domain type
  happens. For example, RISC-V won't have this member of arch_domain structure
  as vCPUs will always have the same bitness as hypervisor. In case of Arm, it
  is possible that Arm64 could create 32-bit and 64-bit domains.
- Introduce init_vuart() to cover details of virtual uart initialization.
- Introduce init_intc_phandle() to cover some details of interrupt controller
  phandle initialization. As an example, RISC-V could have different name for
  interrupt controller node ( APLIC, PLIC, IMSIC, etc ) but the code in
  domain_handle_dtb_bootmodule() could handle only one interrupt controller
  node name.
- s/make_gic_domU_node/make_intc_domU_node as GIC is Arm specific naming and
  add prototype of make_intc_domU_node() to dom0less-build.h

The following functions are moved to xen/common/device-tree:
- Functions which are moved as is:
  - domain_p2m_pages().
  - handle_passthrough_prop().
  - handle_prop_pfdt().
  - scan_pfdt_node().
  - check_partial_fdt().
- Functions which are moved with some minor changes:
  - alloc_xenstore_evtchn():
    - ifdef-ing by CONFIG_HVM accesses to hvm.params.
  - prepare_dtb_domU():
    - ifdef-ing access to gnttab_{start,size} by CONFIG_GRANT_TABLE.
    - s/make_gic_domU_node/make_intc_domU_node.
    - Add call of make_arch_nodes().
- domain_handle_dtb_bootmodule():
  - hide details of interrupt controller phandle initialization by calling
    init_intc_phandle().
  - Update the comment above init_intc_phandle(): s/gic/interrupt controller.
- construct_domU():
  - ifdef-ing by CONFIG_HVM accesses to hvm.params.
  - Call init_vuart() to hide Arm's vpl011_init() details there.
  - Add call of set_domain_type() instead of setting kinfo->arch.type explicitly.

Some parts of dom0less-build.c are wraped by #ifdef CONFIG_STATIC_{SHMEM,MEMORY}
as not all archs support these configs.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

FYI for a possible follow-up patch (doesn't have to be done in this
patch), the following functions could now be static:

alloc_dom0_vcpu0
dom0_max_vcpus
I will make them static in follow-up patch in the next patch series version.






---
Change in v3:
 - Align construct_domU() with the current staging.
 - Align alloc_xenstore_params() with the current staging.
 - Move defintion of XENSTORE_PFN_LATE_ALLOC to common and
   declaration of need_xenstore to common.
---
Change in v2:
 - Wrap by #ifdef CONFIG_STATIC_* inclusions of <asm/static-memory.h> and
   <asm/static-shmem.h>. Wrap also the code which uses something from the
   mentioned headers.
 - Add handling of legacy case in construct_domU().
 - Use xen/fdt-kernel.h and xen/fdt-domain-build.h instead of asm/*.
 - Update the commit message.
---
 xen/arch/arm/dom0less-build.c            | 714 ++---------------------
 xen/common/device-tree/dom0less-build.c  | 699 ++++++++++++++++++++++
 xen/include/asm-generic/dom0less-build.h |  18 +-
 3 files changed, 751 insertions(+), 680 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 0310579863..627c212b3b 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -25,8 +25,6 @@
 #include <asm/static-memory.h>
 #include <asm/static-shmem.h>
 
-bool __initdata need_xenstore;
-
 #ifdef CONFIG_VGICV2
 static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
 {
@@ -152,7 +150,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
 }
 #endif
 
-static int __init make_gic_domU_node(struct kernel_info *kinfo)
+int __init make_intc_domU_node(struct kernel_info *kinfo)
 {
     switch ( kinfo->d->arch.vgic.version )
     {
@@ -218,708 +216,60 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
 }
 #endif
 
-/*
- * Scan device tree properties for passthrough specific information.
- * Returns < 0 on error
- *         0 on success
- */
-static int __init handle_passthrough_prop(struct kernel_info *kinfo,
-                                          const struct fdt_property *xen_reg,
-                                          const struct fdt_property *xen_path,
-                                          bool xen_force,
-                                          uint32_t address_cells,
-                                          uint32_t size_cells)
-{
-    const __be32 *cell;
-    unsigned int i, len;
-    struct dt_device_node *node;
-    int res;
-    paddr_t mstart, size, gstart;
-
-    /* xen,reg specifies where to map the MMIO region */
-    cell = (const __be32 *)xen_reg->data;
-    len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
-                                        sizeof(uint32_t));
-
-    for ( i = 0; i < len; i++ )
-    {
-        device_tree_get_reg(&cell, address_cells, size_cells,
-                            &mstart, &size);
-        gstart = dt_next_cell(address_cells, &cell);
-
-        if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK )
-        {
-            printk(XENLOG_ERR
-                   "DomU passthrough config has not page aligned addresses/sizes\n");
-            return -EINVAL;
-        }
-
-        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
-                                  paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
-        if ( res )
-        {
-            printk(XENLOG_ERR "Unable to permit to dom%d access to"
-                   " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
-                   kinfo->d->domain_id,
-                   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
-            return res;
-        }
-
-        res = map_regions_p2mt(kinfo->d,
-                               gaddr_to_gfn(gstart),
-                               PFN_DOWN(size),
-                               maddr_to_mfn(mstart),
-                               p2m_mmio_direct_dev);
-        if ( res < 0 )
-        {
-            printk(XENLOG_ERR
-                   "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n",
-                   mstart, gstart);
-            return -EFAULT;
-        }
-    }
-
-    /*
-     * If xen_force, we let the user assign a MMIO region with no
-     * associated path.
-     */
-    if ( xen_path == NULL )
-        return xen_force ? 0 : -EINVAL;
-
-    /*
-     * xen,path specifies the corresponding node in the host DT.
-     * Both interrupt mappings and IOMMU settings are based on it,
-     * as they are done based on the corresponding host DT node.
-     */
-    node = dt_find_node_by_path(xen_path->data);
-    if ( node == NULL )
-    {
-        printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n",
-               xen_path->data);
-        return -EINVAL;
-    }
-
-    res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
-    if ( res < 0 )
-        return res;
-
-    res = iommu_add_dt_device(node);
-    if ( res < 0 )
-        return res;
-
-    /* If xen_force, we allow assignment of devices without IOMMU protection. */
-    if ( xen_force && !dt_device_is_protected(node) )
-        return 0;
-
-    return iommu_assign_dt_device(kinfo->d, node);
-}
-
-static int __init handle_prop_pfdt(struct kernel_info *kinfo,
-                                   const void *pfdt, int nodeoff,
-                                   uint32_t address_cells, uint32_t size_cells,
-                                   bool scan_passthrough_prop)
-{
-    void *fdt = kinfo->fdt;
-    int propoff, nameoff, res;
-    const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL;
-    const char *name;
-    bool found, xen_force = false;
-
-    for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
-          propoff >= 0;
-          propoff = fdt_next_property_offset(pfdt, propoff) )
-    {
-        if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) )
-            return -FDT_ERR_INTERNAL;
-
-        found = false;
-        nameoff = fdt32_to_cpu(prop->nameoff);
-        name = fdt_string(pfdt, nameoff);
-
-        if ( scan_passthrough_prop )
-        {
-            if ( dt_prop_cmp("xen,reg", name) == 0 )
-            {
-                xen_reg = prop;
-                found = true;
-            }
-            else if ( dt_prop_cmp("xen,path", name) == 0 )
-            {
-                xen_path = prop;
-                found = true;
-            }
-            else if ( dt_prop_cmp("xen,force-assign-without-iommu",
-                                  name) == 0 )
-            {
-                xen_force = true;
-                found = true;
-            }
-        }
-
-        /*
-         * Copy properties other than the ones above: xen,reg, xen,path,
-         * and xen,force-assign-without-iommu.
-         */
-        if ( !found )
-        {
-            res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len));
-            if ( res )
-                return res;
-        }
-    }
-
-    /*
-     * Only handle passthrough properties if both xen,reg and xen,path
-     * are present, or if xen,force-assign-without-iommu is specified.
-     */
-    if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
-    {
-        res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
-                                      address_cells, size_cells);
-        if ( res < 0 )
-        {
-            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
-            return res;
-        }
-    }
-    else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
-    {
-        printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
-               kinfo->d);
-        return -EINVAL;
-    }
-
-    /* FDT_ERR_NOTFOUND => There is no more properties for this node */
-    return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
-}
-
-static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt,
-                                 int nodeoff,
-                                 uint32_t address_cells, uint32_t size_cells,
-                                 bool scan_passthrough_prop)
-{
-    int rc = 0;
-    void *fdt = kinfo->fdt;
-    int node_next;
-
-    rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL));
-    if ( rc )
-        return rc;
-
-    rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells,
-                          scan_passthrough_prop);
-    if ( rc )
-        return rc;
-
-    address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells",
-                                        DT_ROOT_NODE_ADDR_CELLS_DEFAULT);
-    size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells",
-                                     DT_ROOT_NODE_SIZE_CELLS_DEFAULT);
-
-    node_next = fdt_first_subnode(pfdt, nodeoff);
-    while ( node_next > 0 )
-    {
-        rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells,
-                            scan_passthrough_prop);
-        if ( rc )
-            return rc;
-
-        node_next = fdt_next_subnode(pfdt, node_next);
-    }
-
-    return fdt_end_node(fdt);
-}
-
-static int __init check_partial_fdt(void *pfdt, size_t size)
+int __init make_arch_nodes(struct kernel_info *kinfo)
 {
-    int res;
-
-    if ( fdt_magic(pfdt) != FDT_MAGIC )
-    {
-        dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree");
-        return -EINVAL;
-    }
-
-    res = fdt_check_header(pfdt);
-    if ( res )
-    {
-        dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res);
-        return -EINVAL;
-    }
-
-    if ( fdt_totalsize(pfdt) > size )
-    {
-        dprintk(XENLOG_ERR, "Partial FDT totalsize is too big");
-        return -EINVAL;
-    }
-
-    return 0;
-}
-
-static int __init domain_handle_dtb_bootmodule(struct domain *d,
-                                               struct kernel_info *kinfo)
-{
-    void *pfdt;
-    int res, node_next;
-
-    pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
-                         kinfo->dtb_bootmodule->size);
-    if ( pfdt == NULL )
-        return -EFAULT;
-
-    res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size);
-    if ( res < 0 )
-        goto out;
-
-    for ( node_next = fdt_first_subnode(pfdt, 0);
-          node_next > 0;
-          node_next = fdt_next_subnode(pfdt, node_next) )
-    {
-        const char *name = fdt_get_name(pfdt, node_next, NULL);
-
-        if ( name == NULL )
-            continue;
-
-        /*
-         * Only scan /gic /aliases /passthrough, ignore the rest.
-         * They don't have to be parsed in order.
-         *
-         * Take the GIC phandle value from the special /gic node in the
-         * DTB fragment.
-         */
-        if ( dt_node_cmp(name, "gic") == 0 )
-        {
-            uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
-
-            if ( phandle_intc != 0 )
-                kinfo->phandle_intc = phandle_intc;
-            continue;
-        }
-
-        if ( dt_node_cmp(name, "aliases") == 0 )
-        {
-            res = scan_pfdt_node(kinfo, pfdt, node_next,
-                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
-                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
-                                 false);
-            if ( res )
-                goto out;
-            continue;
-        }
-        if ( dt_node_cmp(name, "passthrough") == 0 )
-        {
-            res = scan_pfdt_node(kinfo, pfdt, node_next,
-                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
-                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
-                                 true);
-            if ( res )
-                goto out;
-            continue;
-        }
-    }
-
- out:
-    iounmap(pfdt);
-
-    return res;
-}
-
-/*
- * The max size for DT is 2MB. However, the generated DT is small (not including
- * domU passthrough DT nodes whose size we account separately), 4KB are enough
- * for now, but we might have to increase it in the future.
- */
-#define DOMU_DTB_SIZE 4096
-static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
-{
-    int addrcells, sizecells;
-    int ret, fdt_size = DOMU_DTB_SIZE;
-
-    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
-    kinfo->gnttab_start = GUEST_GNTTAB_BASE;
-    kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
-
-    addrcells = GUEST_ROOT_ADDRESS_CELLS;
-    sizecells = GUEST_ROOT_SIZE_CELLS;
-
-    /* Account for domU passthrough DT size */
-    if ( kinfo->dtb_bootmodule )
-        fdt_size += kinfo->dtb_bootmodule->size;
-
-    /* Cap to max DT size if needed */
-    fdt_size = min(fdt_size, SZ_2M);
-
-    kinfo->fdt = xmalloc_bytes(fdt_size);
-    if ( kinfo->fdt == NULL )
-        return -ENOMEM;
-
-    ret = fdt_create(kinfo->fdt, fdt_size);
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_finish_reservemap(kinfo->fdt);
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_begin_node(kinfo->fdt, "");
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells);
-    if ( ret )
-        goto err;
-
-    ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells);
-    if ( ret )
-        goto err;
-
-    ret = make_chosen_node(kinfo);
-    if ( ret )
-        goto err;
+    int ret;
 
     ret = make_psci_node(kinfo->fdt);
     if ( ret )
-        goto err;
-
-    ret = make_cpus_node(d, kinfo->fdt);
-    if ( ret )
-        goto err;
-
-    ret = make_memory_node(kinfo, addrcells, sizecells,
-                           kernel_info_get_mem(kinfo));
-    if ( ret )
-        goto err;
-
-    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
-    if ( ret )
-        goto err;
-
-    /*
-     * domain_handle_dtb_bootmodule has to be called before the rest of
-     * the device tree is generated because it depends on the value of
-     * the field phandle_intc.
-     */
-    if ( kinfo->dtb_bootmodule )
-    {
-        ret = domain_handle_dtb_bootmodule(d, kinfo);
-        if ( ret )
-            goto err;
-    }
-
-    ret = make_gic_domU_node(kinfo);
-    if ( ret )
-        goto err;
-
-    ret = make_timer_node(kinfo);
-    if ( ret )
-        goto err;
+        return -EINVAL;
 
     if ( kinfo->vuart )
     {
-        ret = -EINVAL;
 #ifdef CONFIG_SBSA_VUART_CONSOLE
         ret = make_vpl011_uart_node(kinfo);
 #endif
         if ( ret )
-            goto err;
-    }
-
-    if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
-    {
-        ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
-        if ( ret )
-            goto err;
+            return -EINVAL;
     }
 
-    ret = fdt_end_node(kinfo->fdt);
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_finish(kinfo->fdt);
-    if ( ret < 0 )
-        goto err;
-
     return 0;
-
-  err:
-    printk("Device tree generation failed (%d).\n", ret);
-    xfree(kinfo->fdt);
-
-    return -EINVAL;
 }
 
-#define XENSTORE_PFN_OFFSET 1
-static int __init alloc_xenstore_page(struct domain *d)
+/* TODO: make arch.type generic ? */
+#ifdef CONFIG_ARM_64
+void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
 {
-    struct page_info *xenstore_pg;
-    struct xenstore_domain_interface *interface;
-    mfn_t mfn;
-    gfn_t gfn;
-    int rc;
-
-    if ( (UINT_MAX - d->max_pages) < 1 )
-    {
-        printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n",
-               d);
-        return -EINVAL;
-    }
-
-    d->max_pages += 1;
-    xenstore_pg = alloc_domheap_page(d, MEMF_bits(32));
-    if ( xenstore_pg == NULL && is_64bit_domain(d) )
-        xenstore_pg = alloc_domheap_page(d, 0);
-    if ( xenstore_pg == NULL )
-        return -ENOMEM;
-
-    mfn = page_to_mfn(xenstore_pg);
-    if ( !mfn_x(mfn) )
-        return -ENOMEM;
-
-    if ( !is_domain_direct_mapped(d) )
-        gfn = gaddr_to_gfn(GUEST_MAGIC_BASE +
-                           (XENSTORE_PFN_OFFSET << PAGE_SHIFT));
-    else
-        gfn = gaddr_to_gfn(mfn_to_maddr(mfn));
-
-    rc = guest_physmap_add_page(d, gfn, mfn, 0);
-    if ( rc )
-    {
-        free_domheap_page(xenstore_pg);
-        return rc;
-    }
-
-    d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn);
-    interface = map_domain_page(mfn);
-    interface->connection = XENSTORE_RECONNECT;
-    unmap_domain_page(interface);
-
-    return 0;
+    /* type must be set before allocate memory */
+    d->arch.type = kinfo->arch.type;
 }
-
-static int __init alloc_xenstore_params(struct kernel_info *kinfo)
+#else
+void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
 {
-    struct domain *d = kinfo->d;
-    int rc = 0;
-
-    if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY))
-                                 == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) )
-        d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC;
-    else if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE )
-    {
-        rc = alloc_xenstore_page(d);
-        if ( rc < 0 )
-            return rc;
-    }
-
-    return rc;
+    /* Nothing to do */
 }
+#endif
 
-static void __init domain_vcpu_affinity(struct domain *d,
-                                        const struct dt_device_node *node)
+int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
+                      const struct dt_device_node *node)
 {
-    struct dt_device_node *np;
-
-    dt_for_each_child_node(node, np)
-    {
-        const char *hard_affinity_str = NULL;
-        uint32_t val;
-        int rc;
-        struct vcpu *v;
-        cpumask_t affinity;
-
-        if ( !dt_device_is_compatible(np, "xen,vcpu") )
-            continue;
-
-        if ( !dt_property_read_u32(np, "id", &val) )
-            panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node));
-
-        if ( val >= d->max_vcpus )
-            panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val,
-                  dt_node_name(node), d->max_vcpus);
-
-        v = d->vcpu[val];
-        rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str);
-        if ( rc < 0 )
-            continue;
-
-        cpumask_clear(&affinity);
-        while ( *hard_affinity_str != '\0' )
-        {
-            unsigned int start, end;
-
-            start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
-
-            if ( *hard_affinity_str == '-' )    /* Range */
-            {
-                hard_affinity_str++;
-                end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
-            }
-            else                /* Single value */
-                end = start;
-
-            if ( end >= nr_cpu_ids )
-                panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node));
-
-            for ( ; start <= end; start++ )
-                cpumask_set_cpu(start, &affinity);
-
-            if ( *hard_affinity_str == ',' )
-                hard_affinity_str++;
-            else if ( *hard_affinity_str != '\0' )
-                break;
-        }
+    int rc = 0;
 
-        rc = vcpu_set_hard_affinity(v, &affinity);
-        if ( rc )
-            panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n",
-                  v->vcpu_id, rc, dt_node_name(node));
-    }
-}
+    kinfo->vuart = dt_property_read_bool(node, "vpl011");
 
-#ifdef CONFIG_ARCH_PAGING_MEMPOOL
-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.
+     * Base address and irq number are needed when creating vpl011 device
+     * tree node in prepare_dtb_domU, so initialization on related variables
+     * shall be done first.
      */
-    unsigned long memkb = 4 * (256 * smp_cpus + (maxmem_kb / 1024) + 128);
-
-    BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
-
-    return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT);
-}
-
-static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem,
-                                            const struct dt_device_node *node)
-{
-    unsigned long p2m_pages;
-    uint32_t p2m_mem_mb;
-    int rc;
-
-    rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb);
-    /* If xen,domain-p2m-mem-mb is not specified, use the default value. */
-    p2m_pages = rc ?
-                p2m_mem_mb << (20 - PAGE_SHIFT) :
-                domain_p2m_pages(mem, d->max_vcpus);
-
-    spin_lock(&d->arch.paging.lock);
-    rc = p2m_set_allocation(d, p2m_pages, NULL);
-    spin_unlock(&d->arch.paging.lock);
-
-    return rc;
-}
-#else /* !CONFIG_ARCH_PAGING_MEMPOOL */
-static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
-                                            const struct dt_device_node *node)
-{
-    return 0;
-}
-#endif /* CONFIG_ARCH_PAGING_MEMPOOL */
-
-int __init construct_domU(struct domain *d,
-                          const struct dt_device_node *node)
-{
-    struct kernel_info kinfo = KERNEL_INFO_INIT;
-    const char *dom0less_enhanced;
-    int rc;
-    u64 mem;
-
-    rc = dt_property_read_u64(node, "memory", &mem);
-    if ( !rc )
-    {
-        printk("Error building DomU: cannot read \"memory\" property\n");
-        return -EINVAL;
-    }
-    kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
-
-    rc = domain_p2m_set_allocation(d, mem, node);
-    if ( rc != 0 )
-        return rc;
-
-    printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
-           d->max_vcpus, mem);
-
-    kinfo.vuart = dt_property_read_bool(node, "vpl011");
-    if ( kinfo.vuart && is_hardware_domain(d) )
-        panic("hardware domain cannot specify vpl011\n");
-
-    rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
-    if ( rc == -EILSEQ ||
-         rc == -ENODATA ||
-         (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
-    {
-        need_xenstore = true;
-        kinfo.dom0less_feature = DOM0LESS_ENHANCED;
-    }
-    else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") )
-    {
-        need_xenstore = true;
-        kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY;
-    }
-    else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") )
-        kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS;
-
-    if ( vcpu_create(d, 0) == NULL )
-        return -ENOMEM;
-
-    d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
-
-    kinfo.d = d;
-
-    rc = kernel_probe(&kinfo, node);
-    if ( rc < 0 )
-        return rc;
-
-#ifdef CONFIG_ARM_64
-    /* type must be set before allocate memory */
-    d->arch.type = kinfo.arch.type;
-#endif
-    if ( is_hardware_domain(d) )
-    {
-        rc = construct_hwdom(&kinfo, node);
-        if ( rc < 0 )
-            return rc;
-    }

I think we should retain this chunk in the code movement. It is OK if it
is behind a #ifdef CONFIG_ARM.
I'll is_hardware_domain() handling. I think it can be without #ifdef, it seems to me
it is a good thing to re-use construct_hwdom() in the case of creation of h/w domain.





-    else
+    if ( kinfo->vuart )
     {
-        if ( !dt_find_property(node, "xen,static-mem", NULL) )
-            allocate_memory(d, &kinfo);
-        else if ( !is_domain_direct_mapped(d) )
-            allocate_static_memory(d, &kinfo, node);
-        else
-            assign_static_memory_11(d, &kinfo, node);
-
-        rc = process_shm(d, &kinfo, node);
-        if ( rc < 0 )
-            return rc;
-
-        /*
-         * Base address and irq number are needed when creating vpl011 device
-         * tree node in prepare_dtb_domU, so initialization on related variables
-         * shall be done first.
-         */
-        if ( kinfo.vuart )
-        {
-            rc = domain_vpl011_init(d, NULL);
-            if ( rc < 0 )
-                return rc;
-        }
-
-        rc = prepare_dtb_domU(d, &kinfo);
-        if ( rc < 0 )
-            return rc;
-
-        rc = construct_domain(d, &kinfo);
+        rc = domain_vpl011_init(d, NULL);
         if ( rc < 0 )
             return rc;
     }
 
-    domain_vcpu_affinity(d, node);
-
-    return alloc_xenstore_params(&kinfo);
+    return rc;
 }
 
 void __init arch_create_domUs(struct dt_device_node *node,
@@ -995,6 +345,22 @@ void __init arch_create_domUs(struct dt_device_node *node,
     }
 }
 
+int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
+                             const int node_next, const void *pfdt)
+{
+    if ( dt_node_cmp(name, "gic") == 0 )
+    {
+        uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
+
+        if ( phandle_intc != 0 )
+            kinfo->phandle_intc = phandle_intc;
+
+        return 0;
+    }
+
+    return 1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index a01a8b6b1a..c3face5b90 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -3,24 +3,43 @@
 #include <xen/bootfdt.h>
 #include <xen/device_tree.h>
 #include <xen/domain.h>
+#include <xen/domain_page.h>
 #include <xen/err.h>
 #include <xen/event.h>
+#include <xen/fdt-domain-build.h>
+#include <xen/fdt-kernel.h>
 #include <xen/grant_table.h>
 #include <xen/init.h>
+#include <xen/iocap.h>
 #include <xen/iommu.h>
+#include <xen/libfdt/libfdt.h>
 #include <xen/llc-coloring.h>
+#include <xen/sizes.h>
 #include <xen/sched.h>
 #include <xen/stdbool.h>
 #include <xen/types.h>
+#include <xen/vmap.h>
 
 #include <public/bootfdt.h>
 #include <public/domctl.h>
 #include <public/event_channel.h>
+#include <public/io/xs_wire.h>
 
 #include <asm/dom0less-build.h>
 #include <asm/setup.h>
 
+#ifdef CONFIG_STATIC_MEMORY
+#include <asm/static-memory.h>
+#endif

#if __has_include ?



+#ifdef CONFIG_STATIC_SHM
+#include <asm/static-shmem.h>
+#endif

Same here?
I thought that if we have already some CONFIG_* then it is better to use #ifdef, but I am okay with
changing it to __has_include.





+#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
+
 static domid_t __initdata xs_domid = DOMID_INVALID;
+static bool __initdata need_xenstore;
 
 void __init set_xs_domain(struct domain *d)
 {
@@ -109,6 +128,686 @@ static void __init initialize_domU_xenstore(void)
     }
 }
 
+/*
+ * Scan device tree properties for passthrough specific information.
+ * Returns < 0 on error
+ *         0 on success
+ */
+static int __init handle_passthrough_prop(struct kernel_info *kinfo,
+                                          const struct fdt_property *xen_reg,
+                                          const struct fdt_property *xen_path,
+                                          bool xen_force,
+                                          uint32_t address_cells,
+                                          uint32_t size_cells)
+{
+    const __be32 *cell;
+    unsigned int i, len;
+    struct dt_device_node *node;
+    int res;
+    paddr_t mstart, size, gstart;
+
+    /* xen,reg specifies where to map the MMIO region */
+    cell = (const __be32 *)xen_reg->data;
+    len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
+                                        sizeof(uint32_t));
+
+    for ( i = 0; i < len; i++ )
+    {
+        device_tree_get_reg(&cell, address_cells, size_cells,
+                            &mstart, &size);
+        gstart = dt_next_cell(address_cells, &cell);
+
+        if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK )
+        {
+            printk(XENLOG_ERR
+                   "DomU passthrough config has not page aligned addresses/sizes\n");
+            return -EINVAL;
+        }
+
+        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
+                                  paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
+        if ( res )
+        {
+            printk(XENLOG_ERR "Unable to permit to dom%d access to"
+                   " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
+                   kinfo->d->domain_id,
+                   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
+            return res;
+        }
+
+        res = map_regions_p2mt(kinfo->d,
+                               gaddr_to_gfn(gstart),
+                               PFN_DOWN(size),
+                               maddr_to_mfn(mstart),
+                               p2m_mmio_direct_dev);
+        if ( res < 0 )
+        {
+            printk(XENLOG_ERR
+                   "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n",
+                   mstart, gstart);
+            return -EFAULT;
+        }
+    }
+
+    /*
+     * If xen_force, we let the user assign a MMIO region with no
+     * associated path.
+     */
+    if ( xen_path == NULL )
+        return xen_force ? 0 : -EINVAL;
+
+    /*
+     * xen,path specifies the corresponding node in the host DT.
+     * Both interrupt mappings and IOMMU settings are based on it,
+     * as they are done based on the corresponding host DT node.
+     */
+    node = dt_find_node_by_path(xen_path->data);
+    if ( node == NULL )
+    {
+        printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n",
+               xen_path->data);
+        return -EINVAL;
+    }
+
+    res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
+    if ( res < 0 )
+        return res;
+
+    res = iommu_add_dt_device(node);
+    if ( res < 0 )
+        return res;
+
+    /* If xen_force, we allow assignment of devices without IOMMU protection. */
+    if ( xen_force && !dt_device_is_protected(node) )
+        return 0;
+
+    return iommu_assign_dt_device(kinfo->d, node);
+}
+
+static int __init handle_prop_pfdt(struct kernel_info *kinfo,
+                                   const void *pfdt, int nodeoff,
+                                   uint32_t address_cells, uint32_t size_cells,
+                                   bool scan_passthrough_prop)
+{
+    void *fdt = kinfo->fdt;
+    int propoff, nameoff, res;
+    const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL;
+    const char *name;
+    bool found, xen_force = false;
+
+    for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
+          propoff >= 0;
+          propoff = fdt_next_property_offset(pfdt, propoff) )
+    {
+        if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) )
+            return -FDT_ERR_INTERNAL;
+
+        found = false;
+        nameoff = fdt32_to_cpu(prop->nameoff);
+        name = fdt_string(pfdt, nameoff);
+
+        if ( scan_passthrough_prop )
+        {
+            if ( dt_prop_cmp("xen,reg", name) == 0 )
+            {
+                xen_reg = prop;
+                found = true;
+            }
+            else if ( dt_prop_cmp("xen,path", name) == 0 )
+            {
+                xen_path = prop;
+                found = true;
+            }
+            else if ( dt_prop_cmp("xen,force-assign-without-iommu",
+                                  name) == 0 )
+            {
+                xen_force = true;
+                found = true;
+            }
+        }
+
+        /*
+         * Copy properties other than the ones above: xen,reg, xen,path,
+         * and xen,force-assign-without-iommu.
+         */
+        if ( !found )
+        {
+            res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len));
+            if ( res )
+                return res;
+        }
+    }
+
+    /*
+     * Only handle passthrough properties if both xen,reg and xen,path
+     * are present, or if xen,force-assign-without-iommu is specified.
+     */
+    if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
+    {
+        res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
+                                      address_cells, size_cells);
+        if ( res < 0 )
+        {
+            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
+            return res;
+        }
+    }
+    else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
+    {
+        printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
+               kinfo->d);
+        return -EINVAL;
+    }
+
+    /* FDT_ERR_NOTFOUND => There is no more properties for this node */
+    return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
+}
+
+static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt,
+                                 int nodeoff,
+                                 uint32_t address_cells, uint32_t size_cells,
+                                 bool scan_passthrough_prop)
+{
+    int rc = 0;
+    void *fdt = kinfo->fdt;
+    int node_next;
+
+    rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL));
+    if ( rc )
+        return rc;
+
+    rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells,
+                          scan_passthrough_prop);
+    if ( rc )
+        return rc;
+
+    address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells",
+                                        DT_ROOT_NODE_ADDR_CELLS_DEFAULT);
+    size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells",
+                                     DT_ROOT_NODE_SIZE_CELLS_DEFAULT);
+
+    node_next = fdt_first_subnode(pfdt, nodeoff);
+    while ( node_next > 0 )
+    {
+        rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells,
+                            scan_passthrough_prop);
+        if ( rc )
+            return rc;
+
+        node_next = fdt_next_subnode(pfdt, node_next);
+    }
+
+    return fdt_end_node(fdt);
+}
+
+static int __init check_partial_fdt(void *pfdt, size_t size)
+{
+    int res;
+
+    if ( fdt_magic(pfdt) != FDT_MAGIC )
+    {
+        dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree");
+        return -EINVAL;
+    }
+
+    res = fdt_check_header(pfdt);
+    if ( res )
+    {
+        dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res);
+        return -EINVAL;
+    }
+
+    if ( fdt_totalsize(pfdt) > size )
+    {
+        dprintk(XENLOG_ERR, "Partial FDT totalsize is too big");
+        return -EINVAL;
+    }
+
+    return 0;
+}
+
+static int __init domain_handle_dtb_bootmodule(struct domain *d,
+                                               struct kernel_info *kinfo)
+{
+    void *pfdt;
+    int res, node_next;
+
+    pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
+                         kinfo->dtb_bootmodule->size);
+    if ( pfdt == NULL )
+        return -EFAULT;
+
+    res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size);
+    if ( res < 0 )
+        goto out;
+
+    for ( node_next = fdt_first_subnode(pfdt, 0);
+          node_next > 0;
+          node_next = fdt_next_subnode(pfdt, node_next) )
+    {
+        const char *name = fdt_get_name(pfdt, node_next, NULL);
+
+        if ( name == NULL )
+            continue;
+
+        /*
+         * Only scan /$(interrupt_controller) /aliases /passthrough,
+         * ignore the rest.
+         * They don't have to be parsed in order.
+         *
+         * Take the interrupt controller phandle value from the special
+         * interrupt controller node in the DTB fragment.
+         */
+        if ( init_intc_phandle(kinfo, name, node_next, pfdt) == 0 )
+            continue;
+
+        if ( dt_node_cmp(name, "aliases") == 0 )
+        {
+            res = scan_pfdt_node(kinfo, pfdt, node_next,
+                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
+                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
+                                 false);
+            if ( res )
+                goto out;
+            continue;
+        }
+        if ( dt_node_cmp(name, "passthrough") == 0 )
+        {
+            res = scan_pfdt_node(kinfo, pfdt, node_next,
+                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
+                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
+                                 true);
+            if ( res )
+                goto out;
+            continue;
+        }
+    }
+
+ out:
+    iounmap(pfdt);
+
+    return res;
+}
+
+/*
+ * The max size for DT is 2MB. However, the generated DT is small (not including
+ * domU passthrough DT nodes whose size we account separately), 4KB are enough
+ * for now, but we might have to increase it in the future.
+ */
+#define DOMU_DTB_SIZE 4096
+static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
+{
+    int addrcells, sizecells;
+    int ret, fdt_size = DOMU_DTB_SIZE;
+
+    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
+
+#ifdef CONFIG_GRANT_TABLE
+    kinfo->gnttab_start = GUEST_GNTTAB_BASE;
+    kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
+#endif
+
+    addrcells = GUEST_ROOT_ADDRESS_CELLS;
+    sizecells = GUEST_ROOT_SIZE_CELLS;
+
+    /* Account for domU passthrough DT size */
+    if ( kinfo->dtb_bootmodule )
+        fdt_size += kinfo->dtb_bootmodule->size;
+
+    /* Cap to max DT size if needed */
+    fdt_size = min(fdt_size, SZ_2M);
+
+    kinfo->fdt = xmalloc_bytes(fdt_size);
+    if ( kinfo->fdt == NULL )
+        return -ENOMEM;
+
+    ret = fdt_create(kinfo->fdt, fdt_size);
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_finish_reservemap(kinfo->fdt);
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_begin_node(kinfo->fdt, "");
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells);
+    if ( ret )
+        goto err;
+
+    ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells);
+    if ( ret )
+        goto err;
+
+    ret = make_chosen_node(kinfo);
+    if ( ret )
+        goto err;
+
+    ret = make_cpus_node(d, kinfo->fdt);
+    if ( ret )
+        goto err;
+
+    ret = make_memory_node(kinfo, addrcells, sizecells,
+                           kernel_info_get_mem(kinfo));
+    if ( ret )
+        goto err;
+
+#ifdef CONFIG_STATIC_SHM

This should not be necessary because there is a stub implementation of
make_resv_memory_node available in static-shmem.h for the
!CONFIG_STATIC_SHM case.
But static-shmem.h isn't available on all architectures. Until static-shmem.h isn't moved to
asm-generic or xen folders and then re-used by an architecture we have to have #ifdef.





+    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
+    if ( ret )
+        goto err;
+#endif
+
+    /*
+     * domain_handle_dtb_bootmodule has to be called before the rest of
+     * the device tree is generated because it depends on the value of
+     * the field phandle_intc.
+     */
+    if ( kinfo->dtb_bootmodule )
+    {
+        ret = domain_handle_dtb_bootmodule(d, kinfo);
+        if ( ret )
+            goto err;
+    }
+
+    ret = make_intc_domU_node(kinfo);
+    if ( ret )
+        goto err;
+
+    ret = make_timer_node(kinfo);
+    if ( ret )
+        goto err;
+
+    if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
+    {
+        ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
+        if ( ret )
+            goto err;
+    }
+
+    ret = make_arch_nodes(kinfo);
+    if ( ret )
+        goto err;
+
+    ret = fdt_end_node(kinfo->fdt);
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_finish(kinfo->fdt);
+    if ( ret < 0 )
+        goto err;
+
+    return 0;
+
+  err:
+    printk("Device tree generation failed (%d).\n", ret);
+    xfree(kinfo->fdt);
+
+    return -EINVAL;
+}
+
+#define XENSTORE_PFN_OFFSET 1
+static int __init alloc_xenstore_page(struct domain *d)
+{
+    struct page_info *xenstore_pg;
+    struct xenstore_domain_interface *interface;
+    mfn_t mfn;
+    gfn_t gfn;
+    int rc;
+
+    if ( (UINT_MAX - d->max_pages) < 1 )
+    {
+        printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n",
+               d);
+        return -EINVAL;
+    }
+
+    d->max_pages += 1;
+    xenstore_pg = alloc_domheap_page(d, MEMF_bits(32));
+    if ( xenstore_pg == NULL && is_64bit_domain(d) )
+        xenstore_pg = alloc_domheap_page(d, 0);
+    if ( xenstore_pg == NULL )
+        return -ENOMEM;
+
+    mfn = page_to_mfn(xenstore_pg);
+    if ( !mfn_x(mfn) )
+        return -ENOMEM;
+
+    if ( !is_domain_direct_mapped(d) )
+        gfn = gaddr_to_gfn(GUEST_MAGIC_BASE +
+                           (XENSTORE_PFN_OFFSET << PAGE_SHIFT));
+    else
+        gfn = gaddr_to_gfn(mfn_to_maddr(mfn));
+
+    rc = guest_physmap_add_page(d, gfn, mfn, 0);
+    if ( rc )
+    {
+        free_domheap_page(xenstore_pg);
+        return rc;
+    }
+
+#ifdef CONFIG_HVM
+    d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn);
+#endif
+    interface = map_domain_page(mfn);
+    interface->connection = XENSTORE_RECONNECT;
+    unmap_domain_page(interface);
+
+    return 0;
+}
+
+static int __init alloc_xenstore_params(struct kernel_info *kinfo)
+{
+    struct domain *d = kinfo->d;
+    int rc = 0;
+
+#ifdef CONFIG_HVM
+    if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY))
+                                 == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) )
+        d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC;
+    else
+#endif
+    if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE )
+    {
+        rc = alloc_xenstore_page(d);
+        if ( rc < 0 )
+            return rc;
+    }
+
+    return rc;
+}
+
+static void __init domain_vcpu_affinity(struct domain *d,
+                                        const struct dt_device_node *node)
+{
+    struct dt_device_node *np;
+
+    dt_for_each_child_node(node, np)
+    {
+        const char *hard_affinity_str = NULL;
+        uint32_t val;
+        int rc;
+        struct vcpu *v;
+        cpumask_t affinity;
+
+        if ( !dt_device_is_compatible(np, "xen,vcpu") )
+            continue;
+
+        if ( !dt_property_read_u32(np, "id", &val) )
+            panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node));
+
+        if ( val >= d->max_vcpus )
+            panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val,
+                  dt_node_name(node), d->max_vcpus);
+
+        v = d->vcpu[val];
+        rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str);
+        if ( rc < 0 )
+            continue;
+
+        cpumask_clear(&affinity);
+        while ( *hard_affinity_str != '\0' )
+        {
+            unsigned int start, end;
+
+            start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
+
+            if ( *hard_affinity_str == '-' )    /* Range */
+            {
+                hard_affinity_str++;
+                end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
+            }
+            else                /* Single value */
+                end = start;
+
+            if ( end >= nr_cpu_ids )
+                panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node));
+
+            for ( ; start <= end; start++ )
+                cpumask_set_cpu(start, &affinity);
+
+            if ( *hard_affinity_str == ',' )
+                hard_affinity_str++;
+            else if ( *hard_affinity_str != '\0' )
+                break;
+        }
+
+        rc = vcpu_set_hard_affinity(v, &affinity);
+        if ( rc )
+            panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n",
+                  v->vcpu_id, rc, dt_node_name(node));
+    }
+}
+
+#ifdef CONFIG_ARCH_PAGING_MEMPOOL
+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);
+
+    BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
+
+    return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT);
+}
+
+static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem,
+                                            const struct dt_device_node *node)
+{
+    unsigned long p2m_pages;
+    uint32_t p2m_mem_mb;
+    int rc;
+
+    rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb);
+    /* If xen,domain-p2m-mem-mb is not specified, use the default value. */
+    p2m_pages = rc ?
+                p2m_mem_mb << (20 - PAGE_SHIFT) :
+                domain_p2m_pages(mem, d->max_vcpus);
+
+    spin_lock(&d->arch.paging.lock);
+    rc = p2m_set_allocation(d, p2m_pages, NULL);
+    spin_unlock(&d->arch.paging.lock);
+
+    return rc;
+}
+#else /* !CONFIG_ARCH_PAGING_MEMPOOL */
+static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
+                                            const struct dt_device_node *node)
+{
+    return 0;
+}
+#endif /* CONFIG_ARCH_PAGING_MEMPOOL */
+
+static int __init construct_domU(struct domain *d,
+                          const struct dt_device_node *node)
+{
+    struct kernel_info kinfo = KERNEL_INFO_INIT;
+    const char *dom0less_enhanced;
+    int rc;
+    u64 mem;
+
+    rc = dt_property_read_u64(node, "memory", &mem);
+    if ( !rc )
+    {
+        printk("Error building DomU: cannot read \"memory\" property\n");
+        return -EINVAL;
+    }
+    kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
+
+    rc = domain_p2m_set_allocation(d, mem, node);
+    if ( rc != 0 )
+        return rc;
+
+    printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
+           d->max_vcpus, mem);
+
+    rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
+    if ( rc == -EILSEQ ||
+         rc == -ENODATA ||
+         (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
+    {
+        need_xenstore = true;
+        kinfo.dom0less_feature = DOM0LESS_ENHANCED;
+    }
+    else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") )
+    {
+        need_xenstore = true;
+        kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY;
+    }
+    else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") )
+        kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS;
+
+    if ( vcpu_create(d, 0) == NULL )
+        return -ENOMEM;
+
+    d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
+
+    kinfo.d = d;
+
+    rc = kernel_probe(&kinfo, node);
+    if ( rc < 0 )
+        return rc;
+
+    set_domain_type(d, &kinfo);
+
+    if ( !dt_find_property(node, "xen,static-mem", NULL) )
+        allocate_memory(d, &kinfo);
+#ifdef CONFIG_STATIC_MEMORY

Also this should not be needed thanks to the stub implementation of
allocate_static_memory and assign_static_memory_11



+    else if ( !is_domain_direct_mapped(d) )
+        allocate_static_memory(d, &kinfo, node);
+    else
+        assign_static_memory_11(d, &kinfo, node);
+#endif
+
+#ifdef CONFIG_STATIC_SHM

There is a stub for process_shm too
The same as with make_resv_memory_node(), static-shmem.h header isn't available for
all archs.
I can return my patches which move static-shmem.h to asm-generic and then drop all the ifdef-s connect to it:
https://lore.kernel.org/xen-devel/0203b98aa6a42aa69e22e7c973320add3ff4bb5d.1736334615.git.oleksii.kurochko@gmail.com/
https://lore.kernel.org/xen-devel/0203b98aa6a42aa69e22e7c973320add3ff4bb5d.1736334615.git.oleksii.kurochko@gmail.com/

Let me know if it is better to do now or should it be better to drop #ifdef-ing when an architrecture will require
static-shmem or static-mem features?

~ Oleksii


+    rc = process_shm(d, &kinfo, node);
+    if ( rc < 0 )
+        return rc;
+#endif
+
+    rc = init_vuart(d, &kinfo, node);
+    if ( rc < 0 )
+        return rc;
+
+    rc = prepare_dtb_domU(d, &kinfo);
+    if ( rc < 0 )
+        return rc;
+
+    rc = construct_domain(d, &kinfo);
+    if ( rc < 0 )
+        return rc;
+
+    domain_vcpu_affinity(d, node);
+
+    return alloc_xenstore_params(&kinfo);
+}
+
 void __init create_domUs(void)
 {
     struct dt_device_node *node;
diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
index f095135caa..c00bb853d6 100644
--- a/xen/include/asm-generic/dom0less-build.h
+++ b/xen/include/asm-generic/dom0less-build.h
@@ -11,10 +11,7 @@
 
 struct domain;
 struct dt_device_node;
-
-/* TODO: remove both when construct_domU() will be moved to common. */
-#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
-extern bool need_xenstore;
+struct kernel_info;
 
 /*
  * List of possible features for dom0less domUs
@@ -48,12 +45,21 @@ void create_domUs(void);
 bool is_dom0less_mode(void);
 void set_xs_domain(struct domain *d);
 
-int construct_domU(struct domain *d, const struct dt_device_node *node);
-
 void arch_create_domUs(struct dt_device_node *node,
                        struct xen_domctl_createdomain *d_cfg,
                        unsigned int flags);
 
+int init_vuart(struct domain *d, struct kernel_info *kinfo,
+               const struct dt_device_node *node);
+
+int make_intc_domU_node(struct kernel_info *kinfo);
+int make_arch_nodes(struct kernel_info *kinfo);
+
+void set_domain_type(struct domain *d, struct kernel_info *kinfo);
+
+int init_intc_phandle(struct kernel_info *kinfo, const char *name,
+                      const int node_next, const void *pfdt);
+
 #else /* !CONFIG_DOM0LESS_BOOT */
 
 static inline void create_domUs(void) {}
-- 
2.49.0
--------------5xbHStcDnUr1SCGu0GXO5f1l-- From xen-devel-bounces@lists.xenproject.org Mon May 05 10:57:09 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 10:57:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.975996.1363261 (Exim 4.92) (envelope-from ) id 1uBtVQ-0003o3-It; Mon, 05 May 2025 10:57:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 975996.1363261; Mon, 05 May 2025 10: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 1uBtVQ-0003nw-G1; Mon, 05 May 2025 10:57:04 +0000 Received: by outflank-mailman (input) for mailman id 975996; Mon, 05 May 2025 10:57:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBtVP-0003nn-4u for xen-devel@lists.xenproject.org; Mon, 05 May 2025 10:57:03 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id abff4318-299f-11f0-9ffb-bf95429c2676; Mon, 05 May 2025 12:57:01 +0200 (CEST) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-ac34257295dso8677266b.2 for ; Mon, 05 May 2025 03:57:01 -0700 (PDT) Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5fa777c8b9asm5487857a12.25.2025.05.05.03.56.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 May 2025 03:57:00 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: abff4318-299f-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746442620; x=1747047420; darn=lists.xenproject.org; h=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; bh=44wKNcao3Ypys3ZarhO/S69YBr4OASt4mbEgTrWUUZw=; b=jP1kkVtc8t1E69KIfiTH9Qf8xZFv7x1Mkh2Sc3O79REFS2NDD6H6V4wQG/1eV9AZ/u WupgAxqu0JXjFTLT2B9H5BkrTfiulybk4dUXnpPxKciUlKXHvEvsmBPasA60ZvaGRfQi 1O+VZUgb5mW1hNCYcyjtyJBGZL5f0ajyhvRu1FiPDrOuFtq6ZuhMJQ1/T5OTpdTxm75+ p1emkI4dkIq8EGAXzKNenL3geTDbt8lSCcKmZLGMdmx6MpUKGxCnznWSwEdkOHsJwlT2 yrH1LWNXlSkx7VIjBApHobduS1CJbBAwQY0KOuueoMS5cessEaO6DGctqYLoP/Q4isRo iPkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746442620; x=1747047420; h=in-reply-to:content-language:references:cc:to:from:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=44wKNcao3Ypys3ZarhO/S69YBr4OASt4mbEgTrWUUZw=; b=cW2b1xOIL/liENiNiIDHMNeUM91qQf1WFc04YJWDVvF/tj9WFW9ZlLri2hDpB1H9sd x5MO+zI0jBSkzZrK4heWqsVFWKXhkAZ9GO+DFNIQUNiv0aN8VesaowFreMk2a1V/Q35R QlqKRX5HVLqtSsDNlwbGSsavKTfupl+ZL84zFuY+ZlNRgx6BRhoLSloVDE8CQlpdVy6R zjgQ2zGso9sP2/+0uAqg0UqqowPCrEM6O3iwdn9b6PZ1CsM+22nyooG/fjfXKQrvEfOP uHG1Sk8mPnI55RrrycJ+sgp7BKbSXyCx7yIDQ3WGrasOT893t/OsCvDvHE6YO691gmKh +m9g== X-Gm-Message-State: AOJu0Yw6X+9meF0nL+LP0GcCQa8XNcHCDcoqOq3hFhcJamDUpiUzxP0G uJ6Gu3Lf0IJS7FjFZ1/ayMMAJ4awWw1Tzskfcf5gcOOExrIurr9M X-Gm-Gg: ASbGncuovDxNuKktJwF0gR6qWNtNCKkw97MttADmB6BYzOBNJk90gnqXUWqXZZRVKLN 54MKzfxfnkGl2oSSlfQe5Af2ZBmgUDhRQ9a9oKmLTFuKrj2m33rEwyTjBW/KxQ1DBqn0C7OQb6a TfM9bqWS67hijJv40GFMPqCTHguvuZOrtKj2pHEWTGqGoBONnjbkz38LEcIMmwy5BHUcCEaNMx5 kTSRXWTCvK+DKYQC8DOLT1ZlJoHioFJFqWVJPGovkqgTxWSfqNwLu5IZWH38cPVedx76wbuRVe3 5UfcrKSuRUq6o/Q+0QPtY1kuXdVYpG/DN8X2lApvoGhehmk8r+q1za9nRt9siyzpZryEsLU1nW0 o8q+Q+z8jFOM8hS2THKu+eiba+2A= X-Google-Smtp-Source: AGHT+IFMaWwl3t1KRsSN2WvQhlK7qWjnVwIns+uNkn78gur7+P8lWCJ09yxfRRmZVdvZzXb0y+UiQA== X-Received: by 2002:a17:907:968e:b0:acb:b9db:aa22 with SMTP id a640c23a62f3a-ad1a45c168emr590909566b.0.1746442620256; Mon, 05 May 2025 03:57:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------20PM6hHM9mfnG0yY7fo6thf7" Message-ID: <1d63c212-e6fb-4907-845d-296fb98fcc08@gmail.com> Date: Mon, 5 May 2025 12:56:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 8/8] xen/common: dom0less: introduce common dom0less-build.c From: Oleksii Kurochko To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <76390ef52f108b580e1c397ed178ceadf1ae53c4.1746199009.git.oleksii.kurochko@gmail.com> <5523bf0d-a94e-444d-a1fa-035ecccb4448@gmail.com> Content-Language: en-US In-Reply-To: <5523bf0d-a94e-444d-a1fa-035ecccb4448@gmail.com> This is a multi-part message in MIME format. --------------20PM6hHM9mfnG0yY7fo6thf7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/5/25 12:46 PM, Oleksii Kurochko wrote: > > > On 5/2/25 10:53 PM, Stefano Stabellini wrote: >> On Fri, 2 May 2025, Oleksii Kurochko wrote: >>> Part of Arm's dom0less-build.c could be common between architectures which are >>> using device tree files to create guest domains. Thereby move some parts of >>> Arm's dom0less-build.c to common code with minor changes. >>> >>> As a part of theses changes the following changes are introduced: >>> - Introduce make_arch_nodes() to cover arch-specific nodes. For example, in >>> case of Arm, it is PSCI and vpl011 nodes. >>> - Introduce set_domain_type() to abstract a way how setting of domain type >>> happens. For example, RISC-V won't have this member of arch_domain structure >>> as vCPUs will always have the same bitness as hypervisor. In case of Arm, it >>> is possible that Arm64 could create 32-bit and 64-bit domains. >>> - Introduce init_vuart() to cover details of virtual uart initialization. >>> - Introduce init_intc_phandle() to cover some details of interrupt controller >>> phandle initialization. As an example, RISC-V could have different name for >>> interrupt controller node ( APLIC, PLIC, IMSIC, etc ) but the code in >>> domain_handle_dtb_bootmodule() could handle only one interrupt controller >>> node name. >>> - s/make_gic_domU_node/make_intc_domU_node as GIC is Arm specific naming and >>> add prototype of make_intc_domU_node() to dom0less-build.h >>> >>> The following functions are moved to xen/common/device-tree: >>> - Functions which are moved as is: >>> - domain_p2m_pages(). >>> - handle_passthrough_prop(). >>> - handle_prop_pfdt(). >>> - scan_pfdt_node(). >>> - check_partial_fdt(). >>> - Functions which are moved with some minor changes: >>> - alloc_xenstore_evtchn(): >>> - ifdef-ing by CONFIG_HVM accesses to hvm.params. >>> - prepare_dtb_domU(): >>> - ifdef-ing access to gnttab_{start,size} by CONFIG_GRANT_TABLE. >>> - s/make_gic_domU_node/make_intc_domU_node. >>> - Add call of make_arch_nodes(). >>> - domain_handle_dtb_bootmodule(): >>> - hide details of interrupt controller phandle initialization by calling >>> init_intc_phandle(). >>> - Update the comment above init_intc_phandle(): s/gic/interrupt controller. >>> - construct_domU(): >>> - ifdef-ing by CONFIG_HVM accesses to hvm.params. >>> - Call init_vuart() to hide Arm's vpl011_init() details there. >>> - Add call of set_domain_type() instead of setting kinfo->arch.type explicitly. >>> >>> Some parts of dom0less-build.c are wraped by #ifdef CONFIG_STATIC_{SHMEM,MEMORY} >>> as not all archs support these configs. >>> >>> Signed-off-by: Oleksii Kurochko >> FYI for a possible follow-up patch (doesn't have to be done in this >> patch), the following functions could now be static: >> >> alloc_dom0_vcpu0 >> dom0_max_vcpus > I will make them static in follow-up patch in the next patch series version. Oh, I just noticed that we can't make them static as there is none static declaration in xen/domain.h ~ Oleksii --------------20PM6hHM9mfnG0yY7fo6thf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 5/5/25 12:46 PM, Oleksii Kurochko wrote:


On 5/2/25 10:53 PM, Stefano Stabellini wrote:
On Fri, 2 May 2025, Oleksii Kurochko wrote:

Part of Arm's dom0less-build.c could be common between architectures which are
using device tree files to create guest domains. Thereby move some parts of
Arm's dom0less-build.c to common code with minor changes.

As a part of theses changes the following changes are introduced:
- Introduce make_arch_nodes() to cover arch-specific nodes. For example, in
  case of Arm, it is PSCI and vpl011 nodes.
- Introduce set_domain_type() to abstract a way how setting of domain type
  happens. For example, RISC-V won't have this member of arch_domain structure
  as vCPUs will always have the same bitness as hypervisor. In case of Arm, it
  is possible that Arm64 could create 32-bit and 64-bit domains.
- Introduce init_vuart() to cover details of virtual uart initialization.
- Introduce init_intc_phandle() to cover some details of interrupt controller
  phandle initialization. As an example, RISC-V could have different name for
  interrupt controller node ( APLIC, PLIC, IMSIC, etc ) but the code in
  domain_handle_dtb_bootmodule() could handle only one interrupt controller
  node name.
- s/make_gic_domU_node/make_intc_domU_node as GIC is Arm specific naming and
  add prototype of make_intc_domU_node() to dom0less-build.h

The following functions are moved to xen/common/device-tree:
- Functions which are moved as is:
  - domain_p2m_pages().
  - handle_passthrough_prop().
  - handle_prop_pfdt().
  - scan_pfdt_node().
  - check_partial_fdt().
- Functions which are moved with some minor changes:
  - alloc_xenstore_evtchn():
    - ifdef-ing by CONFIG_HVM accesses to hvm.params.
  - prepare_dtb_domU():
    - ifdef-ing access to gnttab_{start,size} by CONFIG_GRANT_TABLE.
    - s/make_gic_domU_node/make_intc_domU_node.
    - Add call of make_arch_nodes().
- domain_handle_dtb_bootmodule():
  - hide details of interrupt controller phandle initialization by calling
    init_intc_phandle().
  - Update the comment above init_intc_phandle(): s/gic/interrupt controller.
- construct_domU():
  - ifdef-ing by CONFIG_HVM accesses to hvm.params.
  - Call init_vuart() to hide Arm's vpl011_init() details there.
  - Add call of set_domain_type() instead of setting kinfo->arch.type explicitly.

Some parts of dom0less-build.c are wraped by #ifdef CONFIG_STATIC_{SHMEM,MEMORY}
as not all archs support these configs.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

FYI for a possible follow-up patch (doesn't have to be done in this
patch), the following functions could now be static:

alloc_dom0_vcpu0
dom0_max_vcpus
I will make them static in follow-up patch in the next patch series version.
Oh, I just noticed that we can't make them static as there is none static declaration in
xen/domain.h

~ Oleksii
--------------20PM6hHM9mfnG0yY7fo6thf7-- From xen-devel-bounces@lists.xenproject.org Mon May 05 11:09:13 2025 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 May 2025 11:09:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.976007.1363270 (Exim 4.92) (envelope-from ) id 1uBth2-0005gR-IF; Mon, 05 May 2025 11:09:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 976007.1363270; Mon, 05 May 2025 11:09:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBth2-0005gK-Fb; Mon, 05 May 2025 11:09:04 +0000 Received: by outflank-mailman (input) for mailman id 976007; Mon, 05 May 2025 11:09:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uBth1-0005gE-CQ for xen-devel@lists.xenproject.org; Mon, 05 May 2025 11:09:03 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 59169a23-29a1-11f0-9ffb-bf95429c2676; Mon, 05 May 2025 13:09:01 +0200 (CEST) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-ac289147833so801790166b.2 for ; Mon, 05 May 2025 04:09:01 -0700 (PDT) Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl. [109.243.69.225]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad189147329sm474669466b.1.2025.05.05.04.08.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 May 2025 04:08: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" X-Inumbo-ID: 59169a23-29a1-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746443340; x=1747048140; darn=lists.xenproject.org; h=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; bh=7VIDio7v4eCyn7zzPuwMIMy5LSP9PCMQAr+XZhqwV80=; b=DR5eS1UbFQ4K91F+d5J2pyAeMWGn/VwfKusxj9JJIofhDTZR/8/JYyQ8H8yufyVVdL 9Y9ewkzUMn1ySokwfrCSu6YVrjBxdoKRMZmV6HvKH3Ec9JElZuvL+FCZ1RV5iGQA76MY WTfsvFn1627LlFkeXe1fS6kVGjqKiPsz1sFX3dcc8vU8rTutDtxrSrnIGk5jq0t2weqy I++0EX1e/cI7iQuQJCEGrVZiFqucq+pG4JmzXhgtPHXA0R/9lkId+THd62w/xi4YQuLQ TYJugF6qLuNmUY6dvFO9VEKHILGlPCL+9rOX66635/QJOFlIJrM7DPIXyJ4KQffOhu1i Yx+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746443340; x=1747048140; h=in-reply-to:content-language:references:cc:to:subject:from :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=7VIDio7v4eCyn7zzPuwMIMy5LSP9PCMQAr+XZhqwV80=; b=uz2biA5T2r7JRZUcznTubz/F6DvTC+2ccGSL/uH/AKlqlIzW6mXJ09j+R7nMjJOyGP iqQYSBMd+nHo1LUJArrZ+rAEGql+jIkNwim7+dldFR+KB2oSWBKAll9VTG5Ijkfeuhp1 lmc3s+gtv9/oFD56QF1Z9F7gMFAHNctAq9wqFMK4oc6ZrtY+m4VdXjLdKhqgGQotPZI1 zA+gI6pFjap1ycKCY5U4NIdwmM7xQBkpCiyaXSK6AXGA9V1VEtZtMbDbSdMYY3Z0T6Ao xOcVkBB+pCY08/3D5uxiPnxwpRgAcDsq5/wnnJTwG0Ihue+atYY6+9cs6427s12fuB5i lpcg== X-Gm-Message-State: AOJu0YwTME3qYsjj4Di/3m2C09zaedIhXB0QjKDEm3SBH5R6c9PNwGQt pt5nM468qAd2z3E1RS3SVOC1TvDyZZ1qNC/2ASb1Y/psPK4c71yv X-Gm-Gg: ASbGncvX+likIFB1XPzyPUUr/H3fdbWUU70827GNpJRNBG3HDwyrY4+BItxrV7g3cNL SgT0732MMsRW8Q98S3eaOYLnquAYWMGld4kZxQtA5XumBAM5NQ/SySzA1G55xNFXOUxScjzlbVq /60ku3mW6J1k2U9v/D5y3PEh2cTcApCMA7bR+Xf8iY5Mujz4umIj7qCXD9uo2sq8E3Js88nvV7Q qAqLfTf2HJTkGUjUP50SnwEYwHMu1zOWXhwuClpHhnWnrH3pibP1Wb6drSAxD/GUfXddC9X3nGn i9l7yjVkmnB/mN+/UjNQlx7IoRl5codRiTwC/WQUTngiDC7JQR3GjkadB9NXBE1SNT/S2Y/DKUa cIaKNsz3aYCkCNlhw X-Google-Smtp-Source: AGHT+IHIWLe66K68wHnMmWuuyS5SLDIXeBriNeLmArRF/X/Qsgykbm7FT9CWY6F7r/eqGbrRZBPJkA== X-Received: by 2002:a17:907:9689:b0:acb:52cb:415f with SMTP id a640c23a62f3a-ad1a4acc679mr606225966b.48.1746443340218; Mon, 05 May 2025 04:09:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------i5KdX35EEWsNYYNEX0T1EBlw" Message-ID: <21ef8c7d-90a1-426d-b642-d5eb40d4ce5e@gmail.com> Date: Mon, 5 May 2025 13:08:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v3 5/8] asm-generic: move some parts of Arm's domain_build.h to common To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US In-Reply-To: This is a multi-part message in MIME format. --------------i5KdX35EEWsNYYNEX0T1EBlw Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/2/25 10:55 PM, Stefano Stabellini wrote: > On Fri, 2 May 2025, Oleksii Kurochko wrote: >> Nothing changed. Only some functions declaration are moved to xen/include/ >> headers as they are expected to be used by common code of domain builing >> or dom0less. >> >> Signed-off-by: Oleksii Kurochko >> --- >> Chnages in v3: >> - Drop inclusion of from xen/fdt-domain-build.h. >> - Add empty line after license tag in xen/fdt-domain-build.h. >> --- >> Chnages in v2: >> - Add missed declaration of construct_hwdom(). >> - Drop unnessary blank line. >> - Introduce xen/fdt-domain-build.h and move parts of Arm's domain_build.h to >> it. >> - Update the commit message. >> --- >> xen/arch/arm/acpi/domain_build.c | 1 + >> xen/arch/arm/dom0less-build.c | 1 + >> xen/arch/arm/domain_build.c | 1 + >> xen/arch/arm/include/asm/domain_build.h | 21 ++---------- >> xen/arch/arm/kernel.c | 1 + >> xen/arch/arm/static-shmem.c | 1 + >> xen/include/xen/fdt-domain-build.h | 43 +++++++++++++++++++++++++ >> 7 files changed, 51 insertions(+), 18 deletions(-) >> create mode 100644 xen/include/xen/fdt-domain-build.h >> >> diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c >> index f9ca8b47e5..1c3555d814 100644 >> --- a/xen/arch/arm/acpi/domain_build.c >> +++ b/xen/arch/arm/acpi/domain_build.c >> @@ -10,6 +10,7 @@ >> */ >> >> #include >> +#include >> #include >> #include >> #include >> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c >> index 7eecd06d44..0310579863 100644 >> --- a/xen/arch/arm/dom0less-build.c >> +++ b/xen/arch/arm/dom0less-build.c >> @@ -1,6 +1,7 @@ >> /* SPDX-License-Identifier: GPL-2.0-only */ >> #include >> #include >> +#include >> #include >> #include >> #include >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index 8c7a054718..9d649b06b3 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -1,6 +1,7 @@ >> /* SPDX-License-Identifier: GPL-2.0-only */ >> #include >> #include >> +#include >> #include >> #include >> #include >> diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h >> index df1c0fe301..397e408a1f 100644 >> --- a/xen/arch/arm/include/asm/domain_build.h >> +++ b/xen/arch/arm/include/asm/domain_build.h >> @@ -5,28 +5,13 @@ >> #include >> >> typedef __be32 gic_interrupt_t[3]; >> -typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg, >> - unsigned int order, void *extra); >> -bool allocate_domheap_memory(struct domain *d, paddr_t tot_size, >> - alloc_domheap_mem_cb cb, void *extra); >> -bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, >> - paddr_t tot_size); >> -void allocate_memory(struct domain *d, struct kernel_info *kinfo); >> -int construct_domain(struct domain *d, struct kernel_info *kinfo); >> -int construct_hwdom(struct kernel_info *kinfo, >> - const struct dt_device_node *node); >> + >> int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit); >> -int make_chosen_node(const struct kernel_info *kinfo); >> -int make_cpus_node(const struct domain *d, void *fdt); >> -int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo, >> - int addrcells, int sizecells); >> -int make_memory_node(const struct kernel_info *kinfo, int addrcells, >> - int sizecells, const struct membanks *mem); >> int make_psci_node(void *fdt); >> -int make_timer_node(const struct kernel_info *kinfo); >> void evtchn_allocate(struct domain *d); >> >> -unsigned int get_allocation_size(paddr_t size); >> +int construct_hwdom(struct kernel_info *kinfo, >> + const struct dt_device_node *node); > At the end of the series construct_hwdom is only called from within > xen/arch/arm/domain_build.c, so it could be made static and removed from > here. However, one of my review comments was that I think we should > still call construct_hwdom from xen/common/device-tree/dom0less-build.c. > So I think we should keep it. I will move this change to the patch where this function will be really used. > > >> /* >> * Helper to write an interrupts with the GIC format >> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c >> index f00fc388db..5759a3470a 100644 >> --- a/xen/arch/arm/kernel.c >> +++ b/xen/arch/arm/kernel.c >> @@ -7,6 +7,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c >> index 14ae48fb1e..1f8441d920 100644 >> --- a/xen/arch/arm/static-shmem.c >> +++ b/xen/arch/arm/static-shmem.c >> @@ -1,6 +1,7 @@ >> /* SPDX-License-Identifier: GPL-2.0-only */ >> >> #include >> +#include >> #include >> #include >> #include >> diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h >> new file mode 100644 >> index 0000000000..b79e9fabfe >> --- /dev/null >> +++ b/xen/include/xen/fdt-domain-build.h >> @@ -0,0 +1,43 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> + >> +#ifndef __XEN_FDT_DOMAIN_BUILD_H__ >> +#define __XEN_FDT_DOMAIN_BUILD_H__ >> + >> +#include >> +#include >> +#include >> +#include >> + >> +struct domain; >> +struct page_info; >> +struct membanks; >> + >> +typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg, >> + unsigned int order, void *extra); >> +bool allocate_domheap_memory(struct domain *d, paddr_t tot_size, >> + alloc_domheap_mem_cb cb, void *extra); >> + >> +bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, >> + paddr_t tot_size); >> +void allocate_memory(struct domain *d, struct kernel_info *kinfo); >> +int construct_domain(struct domain *d, struct kernel_info *kinfo); >> +int make_chosen_node(const struct kernel_info *kinfo); >> +int make_cpus_node(const struct domain *d, void *fdt); >> +int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo, >> + int addrcells, int sizecells); >> +int make_memory_node(const struct kernel_info *kinfo, int addrcells, >> + int sizecells, const struct membanks *mem); >> +int make_timer_node(const struct kernel_info *kinfo); >> + >> +unsigned int get_allocation_size(paddr_t size); > Many of these functions are not actually moved until later patches. It > would be best to move the declaration at the time the function is also > moved. But if that is difficult for any reason, this is also OK. I'll move then allocate_*(), to the patch where defintions for these functions are introduced. ~ Oleksii >> +#endif /* __XEN_FDT_DOMAIN_BUILD_H__ */ >> + >> +/* >> + * Local variables: >> + * mode: C >> + * c-file-style: "BSD" >> + * c-basic-offset: 4 >> + * indent-tabs-mode: nil >> + * End: >> + */ >> -- >> 2.49.0 >> --------------i5KdX35EEWsNYYNEX0T1EBlw Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 5/2/25 10:55 PM, Stefano Stabellini wrote:
On Fri, 2 May 2025, Oleksii Kurochko wrote:

Nothing changed. Only some functions declaration are moved to xen/include/
headers as they are expected to be used by common code of domain builing
or dom0less.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 Chnages in v3:
 - Drop inclusion of <asm/domain_build.h> from xen/fdt-domain-build.h.
 - Add empty line after license tag in xen/fdt-domain-build.h.
---
 Chnages in v2:
  - Add missed declaration of construct_hwdom().
  - Drop unnessary blank line.
  - Introduce xen/fdt-domain-build.h and move parts of Arm's domain_build.h to
    it.
  - Update the commit message.
---
 xen/arch/arm/acpi/domain_build.c        |  1 +
 xen/arch/arm/dom0less-build.c           |  1 +
 xen/arch/arm/domain_build.c             |  1 +
 xen/arch/arm/include/asm/domain_build.h | 21 ++----------
 xen/arch/arm/kernel.c                   |  1 +
 xen/arch/arm/static-shmem.c             |  1 +
 xen/include/xen/fdt-domain-build.h      | 43 +++++++++++++++++++++++++
 7 files changed, 51 insertions(+), 18 deletions(-)
 create mode 100644 xen/include/xen/fdt-domain-build.h

diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
index f9ca8b47e5..1c3555d814 100644
--- a/xen/arch/arm/acpi/domain_build.c
+++ b/xen/arch/arm/acpi/domain_build.c
@@ -10,6 +10,7 @@
  */
 
 #include <xen/compile.h>
+#include <xen/fdt-domain-build.h>
 #include <xen/fdt-kernel.h>
 #include <xen/mm.h>
 #include <xen/sched.h>
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 7eecd06d44..0310579863 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include <xen/device_tree.h>
 #include <xen/domain_page.h>
+#include <xen/fdt-domain-build.h>
 #include <xen/fdt-kernel.h>
 #include <xen/err.h>
 #include <xen/event.h>
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 8c7a054718..9d649b06b3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include <xen/init.h>
 #include <xen/compile.h>
+#include <xen/fdt-domain-build.h>
 #include <xen/fdt-kernel.h>
 #include <xen/lib.h>
 #include <xen/llc-coloring.h>
diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
index df1c0fe301..397e408a1f 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -5,28 +5,13 @@
 #include <xen/sched.h>
 
 typedef __be32 gic_interrupt_t[3];
-typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
-                                     unsigned int order, void *extra);
-bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
-                             alloc_domheap_mem_cb cb, void *extra);
-bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
-                          paddr_t tot_size);
-void allocate_memory(struct domain *d, struct kernel_info *kinfo);
-int construct_domain(struct domain *d, struct kernel_info *kinfo);
-int construct_hwdom(struct kernel_info *kinfo,
-                    const struct dt_device_node *node);
+
 int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
-int make_chosen_node(const struct kernel_info *kinfo);
-int make_cpus_node(const struct domain *d, void *fdt);
-int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
-                         int addrcells, int sizecells);
-int make_memory_node(const struct kernel_info *kinfo, int addrcells,
-                     int sizecells, const struct membanks *mem);
 int make_psci_node(void *fdt);
-int make_timer_node(const struct kernel_info *kinfo);
 void evtchn_allocate(struct domain *d);
 
-unsigned int get_allocation_size(paddr_t size);
+int construct_hwdom(struct kernel_info *kinfo,
+                    const struct dt_device_node *node);

At the end of the series construct_hwdom is only called from within
xen/arch/arm/domain_build.c, so it could be made static and removed from
here. However, one of my review comments was that I think we should
still call construct_hwdom from xen/common/device-tree/dom0less-build.c.
So I think we should keep it.
I will move this change to the patch where this function will be really used.





 /*
  * Helper to write an interrupts with the GIC format
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index f00fc388db..5759a3470a 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -7,6 +7,7 @@
 #include <xen/byteorder.h>
 #include <xen/domain_page.h>
 #include <xen/errno.h>
+#include <xen/fdt-domain-build.h>
 #include <xen/fdt-kernel.h>
 #include <xen/guest_access.h>
 #include <xen/gunzip.h>
diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
index 14ae48fb1e..1f8441d920 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/arch/arm/static-shmem.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
 #include <xen/device_tree.h>
+#include <xen/fdt-domain-build.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/rangeset.h>
 #include <xen/sched.h>
diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
new file mode 100644
index 0000000000..b79e9fabfe
--- /dev/null
+++ b/xen/include/xen/fdt-domain-build.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __XEN_FDT_DOMAIN_BUILD_H__
+#define __XEN_FDT_DOMAIN_BUILD_H__
+
+#include <xen/bootfdt.h>
+#include <xen/device_tree.h>
+#include <xen/fdt-kernel.h>
+#include <xen/types.h>
+
+struct domain;
+struct page_info;
+struct membanks;
+
+typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
+                                     unsigned int order, void *extra);
+bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
+                             alloc_domheap_mem_cb cb, void *extra);
+
+bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
+                          paddr_t tot_size);
+void allocate_memory(struct domain *d, struct kernel_info *kinfo);
+int construct_domain(struct domain *d, struct kernel_info *kinfo);
+int make_chosen_node(const struct kernel_info *kinfo);
+int make_cpus_node(const struct domain *d, void *fdt);
+int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
+                         int addrcells, int sizecells);
+int make_memory_node(const struct kernel_info *kinfo, int addrcells,
+                     int sizecells, const struct membanks *mem);
+int make_timer_node(const struct kernel_info *kinfo);
+
+unsigned int get_allocation_size(paddr_t size);

Many of these functions are not actually moved until later patches. It
would be best to move the declaration at the time the function is also
moved. But if that is difficult for any reason, this is also OK.
I'll move then allocate_*(), to the patch where defintions
for these functions are introduced.

~ Oleksii



      

        
+#endif /* __XEN_FDT_DOMAIN_BUILD_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.49.0



      

    

  


--------------i5KdX35EEWsNYYNEX0T1EBlw--


From xen-devel-bounces@lists.xenproject.org Mon May 05 11:10:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 11:10:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976021.1363280 (Exim 4.92)
	(envelope-from )
	id 1uBtiR-0007Aw-0Z; Mon, 05 May 2025 11:10:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976021.1363280; Mon, 05 May 2025 11:10:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uBtiQ-0007Ap-U9; Mon, 05 May 2025 11:10:30 +0000
Received: by outflank-mailman (input) for mailman id 976021;
 Mon, 05 May 2025 11:10:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBtiP-0007AT-2Y
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 11:10:29 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8c2a4596-29a1-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 13:10:26 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ac34257295dso10791066b.2
 for ; Mon, 05 May 2025 04:10:26 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3f1asm482484166b.64.2025.05.05.04.10.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 05 May 2025 04:10:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8c2a4596-29a1-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746443426; x=1747048226; darn=lists.xenproject.org;
        h=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;
        bh=pUSeXS1ve20OcpOHuz+EbEGszrVJguKDW78QeotAlLk=;
        b=YyQ/a43yhyjOwRwNouDGEkhUEp152eCeV0Eq/xNcA7U79A0ZPQ5yVoQFvauTpqgLfN
         4UoMFOgJFpQJ79zQh17CPx9LBL9XK9i32op5hTkxer3XJ9/XrV6Eg0CqCtMzsqOlNdPo
         XexL5vpVpU0nqGU/XKHKR3uNUhQo1DysDXFgD7d/PJQ9gPmm5p4kD12mf5vAEDKVBM3b
         wpxZL5QREXulojl/jD4ZxFH4PRSS7rvS0CsDEgThKwIK6iJZTLCB4t8kPseLHUeffC8j
         R/TMGzH38Sq6QfgykdU15uUsSJoE9iG+/lzuExZLoEuJnRBHrnUsZfLu2BkIbZwD7Ctl
         CDQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746443426; x=1747048226;
        h=in-reply-to:content-language:references:cc:to:subject:from
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=pUSeXS1ve20OcpOHuz+EbEGszrVJguKDW78QeotAlLk=;
        b=wtzQgmzJhDFNhGwzVSeJ1qkXh+sIFu2c16qPmkVGHtVza34sAsk9GidLBeipeRe1Od
         MjCATaEhgnGbSwKgW1424aYOlFosJLLsuDreZOpxyD84qVg5NVYIScd/OXWKfBc1ss8k
         9PqHWkf+012xoj2SgTn1ipOO5tNg8qISInxwkudZFKSyZCeyOfDDJcwTIyUI/0PSpqrH
         69ahY696t9n6qMF17wF7kMU7Xf2XogZrNY4/XSDV8cER5f8UYR/LyZPbJhHlliCKosEw
         Qo+Sy/Y7fhvi32w+p3WAUHBQk+v0arJD7YaLm933nFWj57x2dBE0mMzYMEe+n4wKlvvT
         mJ/g==
X-Gm-Message-State: AOJu0YxlDiJvuJCCcdTO7hCEmnbb9j1AYd/BVEDBidhvK9si+znTSPO6
	f3Q96R749FAk9tiNk92vDaC3FveoCtfbz9pzQzxcbXBWRMHdmPoA
X-Gm-Gg: ASbGncvwU8HmY0r63QK4Ll0rh+WFWqPWrq3qktkdxvXon+YzB8y9w49vEf4Vj5XnFrN
	219AkZXRG7wHOuAyp8UE530keM8VHFNnxJYV/1kJjaV/pD1k+iHjiutUiDKbVUVo5TxKHoubh95
	pzcdKqylppcuPLz00Nc1h1FGfnXZHFZmaPMfU1FDXsL6cqcNB5M5rxLFY1PZCQ/xzJGORgjORET
	v2TNnwh57h0h5vJ7T1k08EFSdWrNK4DPeJi2a2JkDjhPnpeu93Av3sHOtDxlMphKjO81DhnZJZF
	8vJNP0rHncz5mpl45NrISqGB6Tr5EHknXZChMYLmTO0vfPVGYdYGtmdTovP+ugSdf85ywdxPMQ9
	90jTYL20Js48UXNSd
X-Google-Smtp-Source: AGHT+IEsR7JVEdklr0G4IMQD3bbDct3hhBxRqLAousYVY21tWYOX3fel7vHxoWZfP7V2+RkiiZKrgA==
X-Received: by 2002:a17:907:3f2a:b0:ace:6bfb:372a with SMTP id a640c23a62f3a-ad1a4b0d72fmr630552066b.54.1746443425825;
        Mon, 05 May 2025 04:10:25 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------nQ31WACAUenHgWQW15sowI58"
Message-ID: <41007627-a04c-4c69-9782-4c3ea06a91f1@gmail.com>
Date: Mon, 5 May 2025 13:10:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko 
Subject: Re: [PATCH v3 3/8] asm-generic: move parts of Arm's asm/kernel.h to
 common code
To: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org, Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 <0c16f8fb2702db5fd6751c7da347a97caa431002.1746199009.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
In-Reply-To: 

This is a multi-part message in MIME format.
--------------nQ31WACAUenHgWQW15sowI58
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/2/25 8:13 PM, Stefano Stabellini wrote:
> On Fri, 2 May 2025, Oleksii Kurochko wrote:
>> Move the following parts to common with the following changes:
>> - struct kernel_info:
>>    - Create arch_kernel_info for arch specific kernel information.
>>      At the moment, it contains domain_type for Arm.
>>    - Rename vpl011 to vuart to have more generic name suitable for other archs.
>>    - s/phandle_gic/phandle_intc to have more generic name suitable for other
>>      archs.
>>    - Make text_offset of zimage structure available for RISCV_64.
>> - Wrap by `#ifdef KERNEL_INFO_SHM_MEM_INIT` definition of KERNEL_SHM_MEM_INIT
>>    and wrap by `#ifndef KERNEL_INFO_INIT` definition of KERNEL_INFO_INIT to have
>>    ability to override KERNEL_INFO_SHM_MEM_INIT for arch in case it doesn't
>>    want to use generic one.
>> - Move DOM0LESS_* macros to dom0less-build.h.
>> - Move all others parts of Arm's kernel.h to xen/fdt-kernel.h.
>>
>> Because of the changes in struct kernel_info the correspondent parts of Arm's
>> code are updated.
>>
>> As part of this patch the following clean up happens:
>> - Drop asm/setup.h from asm/kernel.h as nothing depends from it.
>>    Add inclusion of asm/setup.h for a code which uses device_tree_get_reg() to
>>    avoid compilation issues for CONFIG_STATIC_MEMORY and CONFIG_STATIC_SHM.
>> - Drop inclusion of asm/kernel.h everywhere except xen/fdt-kernel.h.
>>
>> Signed-off-by: Oleksii Kurochko
> Everything looks good except for one question below. This patch looks
> like a lot of work, thanks Oleksii!
>
>
>> ---
>> Changes in v3:
>>   - Only resolving of merge conflicts.
>> ---
>> Changes in v2:
>>   - Introduce xen/fdt-kernel.h.
>>   - Move DOM0LESS_* macros to dom0less-build.h.
>>   - Move the rest in asm-generic/kernel.h to xen/fdt-kernel.h.
>>   - Drop inclusion of asm/kernel.h everywhere except xen/fdt-kernel.h.
>>   - Wrap by #if __has_include(....) the member of kernel_info structure:
>>       struct arch_kernel_info arch.
>>   - Update the commit message.
>> ---
>>   xen/arch/arm/acpi/domain_build.c         |   2 +-
>>   xen/arch/arm/dom0less-build.c            |  31 +++---
>>   xen/arch/arm/domain_build.c              |  12 +-
>>   xen/arch/arm/include/asm/domain_build.h  |   2 +-
>>   xen/arch/arm/include/asm/kernel.h        | 126 +--------------------
>>   xen/arch/arm/include/asm/static-memory.h |   2 +-
>>   xen/arch/arm/include/asm/static-shmem.h  |   2 +-
>>   xen/arch/arm/kernel.c                    |  12 +-
>>   xen/arch/arm/static-memory.c             |   1 +
>>   xen/arch/arm/static-shmem.c              |   1 +
>>   xen/common/device-tree/dt-overlay.c      |   2 +-
>>   xen/include/asm-generic/dom0less-build.h |  28 +++++
>>   xen/include/xen/fdt-kernel.h             | 133 +++++++++++++++++++++++
>>   13 files changed, 199 insertions(+), 155 deletions(-)
>>   create mode 100644 xen/include/xen/fdt-kernel.h
>>
>> diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
>> index 2ce75543d0..f9ca8b47e5 100644
>> --- a/xen/arch/arm/acpi/domain_build.c
>> +++ b/xen/arch/arm/acpi/domain_build.c
>> @@ -10,6 +10,7 @@
>>    */
>>   
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -18,7 +19,6 @@
>>   #include 
>>   #include 
>>   #include 
>> -#include 
>>   #include 
>>   
>>   /* Override macros from asm/page.h to make them work with mfn_t */
>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
>> index ef49495d4f..c0634dd61e 100644
>> --- a/xen/arch/arm/dom0less-build.c
>> +++ b/xen/arch/arm/dom0less-build.c
>> @@ -1,6 +1,7 @@
>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -64,11 +65,11 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
>>       if (res)
>>           return res;
>>   
>> -    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic);
>> +    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc);
>>       if (res)
>>           return res;
>>   
>> -    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic);
>> +    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc);
>>       if (res)
>>           return res;
>>   
>> @@ -135,11 +136,11 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
>>       if (res)
>>           return res;
>>   
>> -    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic);
>> +    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc);
>>       if (res)
>>           return res;
>>   
>> -    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic);
>> +    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc);
>>       if (res)
>>           return res;
>>   
>> @@ -200,7 +201,7 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
>>           return res;
>>   
>>       res = fdt_property_cell(fdt, "interrupt-parent",
>> -                            kinfo->phandle_gic);
>> +                            kinfo->phandle_intc);
>>       if ( res )
>>           return res;
>>   
>> @@ -486,10 +487,10 @@ static int __init domain_handle_dtb_bootmodule(struct domain *d,
>>            */
>>           if ( dt_node_cmp(name, "gic") == 0 )
>>           {
>> -            uint32_t phandle_gic = fdt_get_phandle(pfdt, node_next);
>> +            uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
>>   
>> -            if ( phandle_gic != 0 )
>> -                kinfo->phandle_gic = phandle_gic;
>> +            if ( phandle_intc != 0 )
>> +                kinfo->phandle_intc = phandle_intc;
>>               continue;
>>           }
>>   
>> @@ -532,7 +533,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
>>       int addrcells, sizecells;
>>       int ret, fdt_size = DOMU_DTB_SIZE;
>>   
>> -    kinfo->phandle_gic = GUEST_PHANDLE_GIC;
>> +    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
>>       kinfo->gnttab_start = GUEST_GNTTAB_BASE;
>>       kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
>>   
>> @@ -594,7 +595,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
>>       /*
>>        * domain_handle_dtb_bootmodule has to be called before the rest of
>>        * the device tree is generated because it depends on the value of
>> -     * the field phandle_gic.
>> +     * the field phandle_intc.
>>        */
>>       if ( kinfo->dtb_bootmodule )
>>       {
>> @@ -611,7 +612,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
>>       if ( ret )
>>           goto err;
>>   
>> -    if ( kinfo->vpl011 )
>> +    if ( kinfo->vuart )
>>       {
>>           ret = -EINVAL;
>>   #ifdef CONFIG_SBSA_VUART_CONSOLE
>> @@ -839,8 +840,8 @@ int __init construct_domU(struct domain *d,
>>       printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
>>              d->max_vcpus, mem);
>>   
>> -    kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
>> -    if ( kinfo.vpl011 && is_hardware_domain(d) )
>> +    kinfo.vuart = dt_property_read_bool(node, "vpl011");
>> +    if ( kinfo.vuart && is_hardware_domain(d) )
>>           panic("hardware domain cannot specify vpl011\n");
>>   
>>       rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
>> @@ -872,7 +873,7 @@ int __init construct_domU(struct domain *d,
>>   
>>   #ifdef CONFIG_ARM_64
>>       /* type must be set before allocate memory */
>> -    d->arch.type = kinfo.type;
>> +    d->arch.type = kinfo.arch.type;
>>   #endif
>>       if ( is_hardware_domain(d) )
>>       {
>> @@ -898,7 +899,7 @@ int __init construct_domU(struct domain *d,
>>            * tree node in prepare_dtb_domU, so initialization on related variables
>>            * shall be done first.
>>            */
>> -        if ( kinfo.vpl011 )
>> +        if ( kinfo.vuart )
>>           {
>>               rc = domain_vpl011_init(d, NULL);
>>               if ( rc < 0 )
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 270a6b97e4..8c7a054718 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1,6 +1,7 @@
>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -20,7 +21,6 @@
>>   #include 
>>   #include 
>>   #include 
>> -#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -747,7 +747,7 @@ static int __init fdt_property_interrupts(const struct kernel_info *kinfo,
>>           return res;
>>   
>>       res = fdt_property_cell(kinfo->fdt, "interrupt-parent",
>> -                            kinfo->phandle_gic);
>> +                            kinfo->phandle_intc);
>>   
>>       return res;
>>   }
>> @@ -2026,7 +2026,7 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo)
>>   
>>       ASSERT(dt_host && (dt_host->sibling == NULL));
>>   
>> -    kinfo->phandle_gic = dt_interrupt_controller->phandle;
>> +    kinfo->phandle_intc = dt_interrupt_controller->phandle;
>>       fdt = device_tree_flattened;
>>   
>>       new_size = fdt_totalsize(fdt) + DOM0_FDT_EXTRA_SIZE;
>> @@ -2196,13 +2196,13 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
>>   
>>   #ifdef CONFIG_ARM_64
>>       /* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */
>> -    if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT )
>> +    if ( !(cpu_has_el1_32) && kinfo->arch.type == DOMAIN_32BIT )
>>       {
>>           printk("Platform does not support 32-bit domain\n");
>>           return -EINVAL;
>>       }
>>   
>> -    if ( is_sve_domain(d) && (kinfo->type == DOMAIN_32BIT) )
>> +    if ( is_sve_domain(d) && (kinfo->arch.type == DOMAIN_32BIT) )
>>       {
>>           printk("SVE is not available for 32-bit domain\n");
>>           return -EINVAL;
>> @@ -2318,7 +2318,7 @@ int __init construct_hwdom(struct kernel_info *kinfo,
>>   
>>   #ifdef CONFIG_ARM_64
>>       /* type must be set before allocate_memory */
>> -    d->arch.type = kinfo->type;
>> +    d->arch.type = kinfo->arch.type;
>>   #endif
>>       find_gnttab_region(d, kinfo);
>>       if ( is_domain_direct_mapped(d) )
>> diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
>> index 378c10cc98..df1c0fe301 100644
>> --- a/xen/arch/arm/include/asm/domain_build.h
>> +++ b/xen/arch/arm/include/asm/domain_build.h
>> @@ -1,8 +1,8 @@
>>   #ifndef __ASM_DOMAIN_BUILD_H__
>>   #define __ASM_DOMAIN_BUILD_H__
>>   
>> +#include 
>>   #include 
>> -#include 
>>   
>>   typedef __be32 gic_interrupt_t[3];
>>   typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
>> diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
>> index bdc96f4c18..cfeab792c7 100644
>> --- a/xen/arch/arm/include/asm/kernel.h
>> +++ b/xen/arch/arm/include/asm/kernel.h
>> @@ -6,137 +6,15 @@
>>   #ifndef __ARCH_ARM_KERNEL_H__
>>   #define __ARCH_ARM_KERNEL_H__
>>   
>> -#include 
>>   #include 
>> -#include 
>>   
>> -/*
>> - * List of possible features for dom0less domUs
>> - *
>> - * DOM0LESS_ENHANCED_NO_XS:  Notify the OS it is running on top of Xen. All the
>> - *                           default features (excluding Xenstore) will be
>> - *                           available. Note that an OS *must* not rely on the
>> - *                           availability of Xen features if this is not set.
>> - * DOM0LESS_XENSTORE:        Xenstore will be enabled for the VM. The
>> - *                           xenstore page allocation is done by Xen at
>> - *                           domain creation. This feature can't be
>> - *                           enabled without the DOM0LESS_ENHANCED_NO_XS.
>> - * DOM0LESS_XS_LEGACY        Xenstore will be enabled for the VM, the
>> - *                           xenstore page allocation will happen in
>> - *                           init-dom0less. This feature can't be enabled
>> - *                           without the DOM0LESS_ENHANCED_NO_XS.
>> - * DOM0LESS_ENHANCED:        Notify the OS it is running on top of Xen. All the
>> - *                           default features (including Xenstore) will be
>> - *                           available. Note that an OS *must* not rely on the
>> - *                           availability of Xen features if this is not set.
>> - * DOM0LESS_ENHANCED_LEGACY: Same as before, but using DOM0LESS_XS_LEGACY.
>> - */
>> -#define DOM0LESS_ENHANCED_NO_XS  BIT(0, U)
>> -#define DOM0LESS_XENSTORE        BIT(1, U)
>> -#define DOM0LESS_XS_LEGACY       BIT(2, U)
>> -#define DOM0LESS_ENHANCED_LEGACY (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XS_LEGACY)
>> -#define DOM0LESS_ENHANCED        (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE)
>> -
>> -struct kernel_info {
>> +struct arch_kernel_info
>> +{
>>   #ifdef CONFIG_ARM_64
>>       enum domain_type type;
>>   #endif
>> -
>> -    struct domain *d;
>> -
>> -    void *fdt; /* flat device tree */
>> -    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
>> -    struct meminfo mem;
>> -#ifdef CONFIG_STATIC_SHM
>> -    struct shared_meminfo shm_mem;
>> -#endif
>> -
>> -    /* kernel entry point */
>> -    paddr_t entry;
>> -
>> -    /* grant table region */
>> -    paddr_t gnttab_start;
>> -    paddr_t gnttab_size;
>> -
>> -    /* boot blob load addresses */
>> -    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
>> -    const char* cmdline;
>> -    paddr_t dtb_paddr;
>> -    paddr_t initrd_paddr;
>> -
>> -    /* Enable pl011 emulation */
>> -    bool vpl011;
>> -
>> -    /* Enable/Disable PV drivers interfaces */
>> -    uint16_t dom0less_feature;
>> -
>> -    /* GIC phandle */
>> -    uint32_t phandle_gic;
>> -
>> -    /* loader to use for this kernel */
>> -    void (*load)(struct kernel_info *info);
>> -    /* loader specific state */
>> -    union {
>> -        struct {
>> -            paddr_t kernel_addr;
>> -            paddr_t len;
>> -#ifdef CONFIG_ARM_64
>> -            paddr_t text_offset; /* 64-bit Image only */
>> -#endif
>> -            paddr_t start; /* Must be 0 for 64-bit Image */
>> -        } zimage;
>> -    };
>>   };
>>   
>> -static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo)
>> -{
>> -    return container_of(&kinfo->mem.common, struct membanks, common);
>> -}
>> -
>> -static inline const struct membanks *
>> -kernel_info_get_mem_const(const struct kernel_info *kinfo)
>> -{
>> -    return container_of(&kinfo->mem.common, const struct membanks, common);
>> -}
>> -
>> -#ifdef CONFIG_STATIC_SHM
>> -#define KERNEL_INFO_SHM_MEM_INIT                \
>> -    .shm_mem.common.max_banks = NR_SHMEM_BANKS, \
>> -    .shm_mem.common.type = STATIC_SHARED_MEMORY,
> This line type = STATIC_SHARED_MEMORY,
>
>
>> -#else
>> -#define KERNEL_INFO_SHM_MEM_INIT
>> -#endif
>> -
>> -#define KERNEL_INFO_INIT                        \
>> -{                                               \
>> -    .mem.common.max_banks = NR_MEM_BANKS,       \
>> -    .mem.common.type = MEMORY,                  \
> and also this line type = MEMORY,
> ...
>
>
>> -    KERNEL_INFO_SHM_MEM_INIT                    \
>> -}
>> -
>> -/*
>> - * Probe the kernel to detemine its type and select a loader.
>> - *
>> - * Sets in info:
>> - *  ->type
>> - *  ->load hook, and sets loader specific variables ->zimage
>> - */
>> -int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
>> -
>> -/*
>> - * Loads the kernel into guest RAM.
>> - *
>> - * Expects to be set in info when called:
>> - *  ->mem
>> - *  ->fdt
>> - *
>> - * Sets in info:
>> - *  ->entry
>> - *  ->dtb_paddr
>> - *  ->initrd_paddr
>> - */
>> -void kernel_load(struct kernel_info *info);
>> -
>>   #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
>>   
>>   /*
>> diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/arch/arm/include/asm/static-memory.h
>> index 804166e541..a32a3c6553 100644
>> --- a/xen/arch/arm/include/asm/static-memory.h
>> +++ b/xen/arch/arm/include/asm/static-memory.h
>> @@ -3,8 +3,8 @@
>>   #ifndef __ASM_STATIC_MEMORY_H_
>>   #define __ASM_STATIC_MEMORY_H_
>>   
>> +#include 
>>   #include 
>> -#include 
>>   
>>   #ifdef CONFIG_STATIC_MEMORY
>>   
>> diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h
>> index 94eaa9d500..a4f853805a 100644
>> --- a/xen/arch/arm/include/asm/static-shmem.h
>> +++ b/xen/arch/arm/include/asm/static-shmem.h
>> @@ -3,8 +3,8 @@
>>   #ifndef __ASM_STATIC_SHMEM_H_
>>   #define __ASM_STATIC_SHMEM_H_
>>   
>> +#include 
>>   #include 
>> -#include 
>>   #include 
>>   
>>   #ifdef CONFIG_STATIC_SHM
>> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
>> index 2647812e8e..f00fc388db 100644
>> --- a/xen/arch/arm/kernel.c
>> +++ b/xen/arch/arm/kernel.c
>> @@ -7,6 +7,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -16,6 +17,7 @@
>>   #include 
>>   #include 
>>   
>> +#include 
>>   #include 
>>   #include 
>>   
>> @@ -101,7 +103,7 @@ static paddr_t __init kernel_zimage_place(struct kernel_info *info)
>>       paddr_t load_addr;
>>   
>>   #ifdef CONFIG_ARM_64
>> -    if ( (info->type == DOMAIN_64BIT) && (info->zimage.start == 0) )
>> +    if ( (info->arch.type == DOMAIN_64BIT) && (info->zimage.start == 0) )
>>           return mem->bank[0].start + info->zimage.text_offset;
>>   #endif
>>   
>> @@ -371,10 +373,10 @@ static int __init kernel_uimage_probe(struct kernel_info *info,
>>       switch ( uimage.arch )
>>       {
>>       case IH_ARCH_ARM:
>> -        info->type = DOMAIN_32BIT;
>> +        info->arch.type = DOMAIN_32BIT;
>>           break;
>>       case IH_ARCH_ARM64:
>> -        info->type = DOMAIN_64BIT;
>> +        info->arch.type = DOMAIN_64BIT;
>>           break;
>>       default:
>>           printk(XENLOG_ERR "Unsupported uImage arch type %d\n", uimage.arch);
>> @@ -444,7 +446,7 @@ static int __init kernel_zimage64_probe(struct kernel_info *info,
>>   
>>       info->load = kernel_zimage_load;
>>   
>> -    info->type = DOMAIN_64BIT;
>> +    info->arch.type = DOMAIN_64BIT;
>>   
>>       return 0;
>>   }
>> @@ -496,7 +498,7 @@ static int __init kernel_zimage32_probe(struct kernel_info *info,
>>       info->load = kernel_zimage_load;
>>   
>>   #ifdef CONFIG_ARM_64
>> -    info->type = DOMAIN_32BIT;
>> +    info->arch.type = DOMAIN_32BIT;
>>   #endif
>>   
>>       return 0;
>> diff --git a/xen/arch/arm/static-memory.c b/xen/arch/arm/static-memory.c
>> index d4585c5a06..e0f76afcd8 100644
>> --- a/xen/arch/arm/static-memory.c
>> +++ b/xen/arch/arm/static-memory.c
>> @@ -2,6 +2,7 @@
>>   
>>   #include 
>>   
>> +#include 
>>   #include 
>>   
>>   static bool __init append_static_memory_to_bank(struct domain *d,
>> diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
>> index e8d4ca3ba3..14ae48fb1e 100644
>> --- a/xen/arch/arm/static-shmem.c
>> +++ b/xen/arch/arm/static-shmem.c
>> @@ -6,6 +6,7 @@
>>   #include 
>>   
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   
>> diff --git a/xen/common/device-tree/dt-overlay.c b/xen/common/device-tree/dt-overlay.c
>> index 97fb99eaaa..81107cb48d 100644
>> --- a/xen/common/device-tree/dt-overlay.c
>> +++ b/xen/common/device-tree/dt-overlay.c
>> @@ -6,8 +6,8 @@
>>    * Written by Vikram Garhwal
>>    *
>>    */
>> -#include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
>> index 5655571a66..f095135caa 100644
>> --- a/xen/include/asm-generic/dom0less-build.h
>> +++ b/xen/include/asm-generic/dom0less-build.h
>> @@ -16,6 +16,34 @@ struct dt_device_node;
>>   #define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
>>   extern bool need_xenstore;
>>   
>> +/*
>> + * List of possible features for dom0less domUs
>> + *
>> + * DOM0LESS_ENHANCED_NO_XS:  Notify the OS it is running on top of Xen. All the
>> + *                           default features (excluding Xenstore) will be
>> + *                           available. Note that an OS *must* not rely on the
>> + *                           availability of Xen features if this is not set.
>> + * DOM0LESS_XENSTORE:        Xenstore will be enabled for the VM. The
>> + *                           xenstore page allocation is done by Xen at
>> + *                           domain creation. This feature can't be
>> + *                           enabled without the DOM0LESS_ENHANCED_NO_XS.
>> + * DOM0LESS_XS_LEGACY        Xenstore will be enabled for the VM, the
>> + *                           xenstore page allocation will happen in
>> + *                           init-dom0less. This feature can't be enabled
>> + *                           without the DOM0LESS_ENHANCED_NO_XS.
>> + * DOM0LESS_ENHANCED:        Notify the OS it is running on top of Xen. All the
>> + *                           default features (including Xenstore) will be
>> + *                           available. Note that an OS *must* not rely on the
>> + *                           availability of Xen features if this is not set.
>> + * DOM0LESS_ENHANCED_LEGACY: Same as before, but using DOM0LESS_XS_LEGACY.
>> +
>> + */
>> +#define DOM0LESS_ENHANCED_NO_XS  BIT(0, U)
>> +#define DOM0LESS_XENSTORE        BIT(1, U)
>> +#define DOM0LESS_XS_LEGACY       BIT(2, U)
>> +#define DOM0LESS_ENHANCED_LEGACY (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XS_LEGACY)
>> +#define DOM0LESS_ENHANCED        (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE)
>> +
>>   void create_domUs(void);
>>   bool is_dom0less_mode(void);
>>   void set_xs_domain(struct domain *d);
>> diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
>> new file mode 100644
>> index 0000000000..c81e759423
>> --- /dev/null
>> +++ b/xen/include/xen/fdt-kernel.h
>> @@ -0,0 +1,133 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * For Kernel image loading.
>> + *
>> + * Copyright (C) 2011 Citrix Systems, Inc.
>> + */
>> +#ifndef __XEN_FDT_KERNEL_H__
>> +#define __XEN_FDT_KERNEL_H__
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#if __has_include()
>> +#   include 
>> +#endif
>> +
>> +struct kernel_info {
>> +    struct domain *d;
>> +
>> +    void *fdt; /* flat device tree */
>> +    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
>> +    struct meminfo mem;
>> +#ifdef CONFIG_STATIC_SHM
>> +    struct shared_meminfo shm_mem;
>> +#endif
>> +
>> +    /* kernel entry point */
>> +    paddr_t entry;
>> +
>> +    /* grant table region */
>> +    paddr_t gnttab_start;
>> +    paddr_t gnttab_size;
>> +
>> +    /* boot blob load addresses */
>> +    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
>> +    const char* cmdline;
>> +    paddr_t dtb_paddr;
>> +    paddr_t initrd_paddr;
>> +
>> +    /* Enable uart emulation */
>> +    bool vuart;
>> +
>> +    /* Enable/Disable PV drivers interfaces */
>> +    uint16_t dom0less_feature;
>> +
>> +    /* Interrupt controller phandle */
>> +    uint32_t phandle_intc;
>> +
>> +    /* loader to use for this kernel */
>> +    void (*load)(struct kernel_info *info);
>> +
>> +    /* loader specific state */
>> +    union {
>> +        struct {
>> +            paddr_t kernel_addr;
>> +            paddr_t len;
>> +#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64)
>> +            paddr_t text_offset; /* 64-bit Image only */
>> +#endif
>> +            paddr_t start; /* Must be 0 for 64-bit Image */
>> +        } zimage;
>> +    };
>> +
>> +#if __has_include()
>> +    struct arch_kernel_info arch;
>> +#endif
>> +};
>> +
>> +static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo)
>> +{
>> +    return container_of(&kinfo->mem.common, struct membanks, common);
>> +}
>> +
>> +static inline const struct membanks *
>> +kernel_info_get_mem_const(const struct kernel_info *kinfo)
>> +{
>> +    return container_of(&kinfo->mem.common, const struct membanks, common);
>> +}
>> +
>> +#ifndef KERNEL_INFO_SHM_MEM_INIT
>> +
>> +#ifdef CONFIG_STATIC_SHM
>> +#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS,
> they are missing here...
>
>
>> +#else
>> +#define KERNEL_INFO_SHM_MEM_INIT
>> +#endif
>> +
>> +#endif /* KERNEL_INFO_SHM_MEM_INIT */
>> +
>> +#ifndef KERNEL_INFO_INIT
>> +
>> +#define KERNEL_INFO_INIT                        \
>> +{                                               \
>> +    .mem.common.max_banks = NR_MEM_BANKS,       \
> and also here.
>
> Why?

I just overlooked these changes (they’re relatively "new"). Thanks for pointing that out.

I’ll restore those types.

~ Oleksii

>> +    KERNEL_INFO_SHM_MEM_INIT                    \
>> +}
>> +
>> +#endif /* KERNEL_INFO_INIT */
>> +
>> +/*
>> + * Probe the kernel to detemine its type and select a loader.
>> + *
>> + * Sets in info:
>> + *  ->type
>> + *  ->load hook, and sets loader specific variables ->zimage
>> + */
>> +int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
>> +
>> +/*
>> + * Loads the kernel into guest RAM.
>> + *
>> + * Expects to be set in info when called:
>> + *  ->mem
>> + *  ->fdt
>> + *
>> + * Sets in info:
>> + *  ->entry
>> + *  ->dtb_paddr
>> + *  ->initrd_paddr
>> + */
>> +void kernel_load(struct kernel_info *info);
>> +
>> +#endif /* __XEN_FDT_KERNEL_H__ */
>> +
>> +/*
>> + * Local variables:
>> + * mode: C
>> + * c-file-style: "BSD"
>> + * c-basic-offset: 4
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>> -- 
>> 2.49.0
>>
--------------nQ31WACAUenHgWQW15sowI58
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    


    

    
On 5/2/25 8:13 PM, Stefano Stabellini
      wrote:

    

    

      
On Fri, 2 May 2025, Oleksii Kurochko wrote:


      

        
Move the following parts to common with the following changes:
- struct kernel_info:
  - Create arch_kernel_info for arch specific kernel information.
    At the moment, it contains domain_type for Arm.
  - Rename vpl011 to vuart to have more generic name suitable for other archs.
  - s/phandle_gic/phandle_intc to have more generic name suitable for other
    archs.
  - Make text_offset of zimage structure available for RISCV_64.
- Wrap by `#ifdef KERNEL_INFO_SHM_MEM_INIT` definition of KERNEL_SHM_MEM_INIT
  and wrap by `#ifndef KERNEL_INFO_INIT` definition of KERNEL_INFO_INIT to have
  ability to override KERNEL_INFO_SHM_MEM_INIT for arch in case it doesn't
  want to use generic one.
- Move DOM0LESS_* macros to dom0less-build.h.
- Move all others parts of Arm's kernel.h to xen/fdt-kernel.h.

Because of the changes in struct kernel_info the correspondent parts of Arm's
code are updated.

As part of this patch the following clean up happens:
- Drop asm/setup.h from asm/kernel.h as nothing depends from it.
  Add inclusion of asm/setup.h for a code which uses device_tree_get_reg() to
  avoid compilation issues for CONFIG_STATIC_MEMORY and CONFIG_STATIC_SHM.
- Drop inclusion of asm/kernel.h everywhere except xen/fdt-kernel.h.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>


      

      
Everything looks good except for one question below. This patch looks
like a lot of work, thanks Oleksii!




      

        
---
Changes in v3:
 - Only resolving of merge conflicts.
---
Changes in v2:
 - Introduce xen/fdt-kernel.h.
 - Move DOM0LESS_* macros to dom0less-build.h.
 - Move the rest in asm-generic/kernel.h to xen/fdt-kernel.h.
 - Drop inclusion of asm/kernel.h everywhere except xen/fdt-kernel.h.
 - Wrap by #if __has_include(....) the member of kernel_info structure:
     struct arch_kernel_info arch.
 - Update the commit message.
---
 xen/arch/arm/acpi/domain_build.c         |   2 +-
 xen/arch/arm/dom0less-build.c            |  31 +++---
 xen/arch/arm/domain_build.c              |  12 +-
 xen/arch/arm/include/asm/domain_build.h  |   2 +-
 xen/arch/arm/include/asm/kernel.h        | 126 +--------------------
 xen/arch/arm/include/asm/static-memory.h |   2 +-
 xen/arch/arm/include/asm/static-shmem.h  |   2 +-
 xen/arch/arm/kernel.c                    |  12 +-
 xen/arch/arm/static-memory.c             |   1 +
 xen/arch/arm/static-shmem.c              |   1 +
 xen/common/device-tree/dt-overlay.c      |   2 +-
 xen/include/asm-generic/dom0less-build.h |  28 +++++
 xen/include/xen/fdt-kernel.h             | 133 +++++++++++++++++++++++
 13 files changed, 199 insertions(+), 155 deletions(-)
 create mode 100644 xen/include/xen/fdt-kernel.h

diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
index 2ce75543d0..f9ca8b47e5 100644
--- a/xen/arch/arm/acpi/domain_build.c
+++ b/xen/arch/arm/acpi/domain_build.c
@@ -10,6 +10,7 @@
  */
 
 #include <xen/compile.h>
+#include <xen/fdt-kernel.h>
 #include <xen/mm.h>
 #include <xen/sched.h>
 #include <xen/acpi.h>
@@ -18,7 +19,6 @@
 #include <xen/device_tree.h>
 #include <xen/libfdt/libfdt.h>
 #include <acpi/actables.h>
-#include <asm/kernel.h>
 #include <asm/domain_build.h>
 
 /* Override macros from asm/page.h to make them work with mfn_t */
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index ef49495d4f..c0634dd61e 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include <xen/device_tree.h>
 #include <xen/domain_page.h>
+#include <xen/fdt-kernel.h>
 #include <xen/err.h>
 #include <xen/event.h>
 #include <xen/grant_table.h>
@@ -64,11 +65,11 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
@@ -135,11 +136,11 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
@@ -200,7 +201,7 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
         return res;
 
     res = fdt_property_cell(fdt, "interrupt-parent",
-                            kinfo->phandle_gic);
+                            kinfo->phandle_intc);
     if ( res )
         return res;
 
@@ -486,10 +487,10 @@ static int __init domain_handle_dtb_bootmodule(struct domain *d,
          */
         if ( dt_node_cmp(name, "gic") == 0 )
         {
-            uint32_t phandle_gic = fdt_get_phandle(pfdt, node_next);
+            uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
 
-            if ( phandle_gic != 0 )
-                kinfo->phandle_gic = phandle_gic;
+            if ( phandle_intc != 0 )
+                kinfo->phandle_intc = phandle_intc;
             continue;
         }
 
@@ -532,7 +533,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     int addrcells, sizecells;
     int ret, fdt_size = DOMU_DTB_SIZE;
 
-    kinfo->phandle_gic = GUEST_PHANDLE_GIC;
+    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
     kinfo->gnttab_start = GUEST_GNTTAB_BASE;
     kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
 
@@ -594,7 +595,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     /*
      * domain_handle_dtb_bootmodule has to be called before the rest of
      * the device tree is generated because it depends on the value of
-     * the field phandle_gic.
+     * the field phandle_intc.
      */
     if ( kinfo->dtb_bootmodule )
     {
@@ -611,7 +612,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     if ( ret )
         goto err;
 
-    if ( kinfo->vpl011 )
+    if ( kinfo->vuart )
     {
         ret = -EINVAL;
 #ifdef CONFIG_SBSA_VUART_CONSOLE
@@ -839,8 +840,8 @@ int __init construct_domU(struct domain *d,
     printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
            d->max_vcpus, mem);
 
-    kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
-    if ( kinfo.vpl011 && is_hardware_domain(d) )
+    kinfo.vuart = dt_property_read_bool(node, "vpl011");
+    if ( kinfo.vuart && is_hardware_domain(d) )
         panic("hardware domain cannot specify vpl011\n");
 
     rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
@@ -872,7 +873,7 @@ int __init construct_domU(struct domain *d,
 
 #ifdef CONFIG_ARM_64
     /* type must be set before allocate memory */
-    d->arch.type = kinfo.type;
+    d->arch.type = kinfo.arch.type;
 #endif
     if ( is_hardware_domain(d) )
     {
@@ -898,7 +899,7 @@ int __init construct_domU(struct domain *d,
          * tree node in prepare_dtb_domU, so initialization on related variables
          * shall be done first.
          */
-        if ( kinfo.vpl011 )
+        if ( kinfo.vuart )
         {
             rc = domain_vpl011_init(d, NULL);
             if ( rc < 0 )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 270a6b97e4..8c7a054718 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include <xen/init.h>
 #include <xen/compile.h>
+#include <xen/fdt-kernel.h>
 #include <xen/lib.h>
 #include <xen/llc-coloring.h>
 #include <xen/mm.h>
@@ -20,7 +21,6 @@
 #include <xen/vmap.h>
 #include <xen/warning.h>
 #include <asm/device.h>
-#include <asm/kernel.h>
 #include <asm/setup.h>
 #include <asm/tee/tee.h>
 #include <asm/pci.h>
@@ -747,7 +747,7 @@ static int __init fdt_property_interrupts(const struct kernel_info *kinfo,
         return res;
 
     res = fdt_property_cell(kinfo->fdt, "interrupt-parent",
-                            kinfo->phandle_gic);
+                            kinfo->phandle_intc);
 
     return res;
 }
@@ -2026,7 +2026,7 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo)
 
     ASSERT(dt_host && (dt_host->sibling == NULL));
 
-    kinfo->phandle_gic = dt_interrupt_controller->phandle;
+    kinfo->phandle_intc = dt_interrupt_controller->phandle;
     fdt = device_tree_flattened;
 
     new_size = fdt_totalsize(fdt) + DOM0_FDT_EXTRA_SIZE;
@@ -2196,13 +2196,13 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
 
 #ifdef CONFIG_ARM_64
     /* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */
-    if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT )
+    if ( !(cpu_has_el1_32) && kinfo->arch.type == DOMAIN_32BIT )
     {
         printk("Platform does not support 32-bit domain\n");
         return -EINVAL;
     }
 
-    if ( is_sve_domain(d) && (kinfo->type == DOMAIN_32BIT) )
+    if ( is_sve_domain(d) && (kinfo->arch.type == DOMAIN_32BIT) )
     {
         printk("SVE is not available for 32-bit domain\n");
         return -EINVAL;
@@ -2318,7 +2318,7 @@ int __init construct_hwdom(struct kernel_info *kinfo,
 
 #ifdef CONFIG_ARM_64
     /* type must be set before allocate_memory */
-    d->arch.type = kinfo->type;
+    d->arch.type = kinfo->arch.type;
 #endif
     find_gnttab_region(d, kinfo);
     if ( is_domain_direct_mapped(d) )
diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
index 378c10cc98..df1c0fe301 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -1,8 +1,8 @@
 #ifndef __ASM_DOMAIN_BUILD_H__
 #define __ASM_DOMAIN_BUILD_H__
 
+#include <xen/fdt-kernel.h>
 #include <xen/sched.h>
-#include <asm/kernel.h>
 
 typedef __be32 gic_interrupt_t[3];
 typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
index bdc96f4c18..cfeab792c7 100644
--- a/xen/arch/arm/include/asm/kernel.h
+++ b/xen/arch/arm/include/asm/kernel.h
@@ -6,137 +6,15 @@
 #ifndef __ARCH_ARM_KERNEL_H__
 #define __ARCH_ARM_KERNEL_H__
 
-#include <xen/device_tree.h>
 #include <asm/domain.h>
-#include <asm/setup.h>
 
-/*
- * List of possible features for dom0less domUs
- *
- * DOM0LESS_ENHANCED_NO_XS:  Notify the OS it is running on top of Xen. All the
- *                           default features (excluding Xenstore) will be
- *                           available. Note that an OS *must* not rely on the
- *                           availability of Xen features if this is not set.
- * DOM0LESS_XENSTORE:        Xenstore will be enabled for the VM. The
- *                           xenstore page allocation is done by Xen at
- *                           domain creation. This feature can't be
- *                           enabled without the DOM0LESS_ENHANCED_NO_XS.
- * DOM0LESS_XS_LEGACY        Xenstore will be enabled for the VM, the
- *                           xenstore page allocation will happen in
- *                           init-dom0less. This feature can't be enabled
- *                           without the DOM0LESS_ENHANCED_NO_XS.
- * DOM0LESS_ENHANCED:        Notify the OS it is running on top of Xen. All the
- *                           default features (including Xenstore) will be
- *                           available. Note that an OS *must* not rely on the
- *                           availability of Xen features if this is not set.
- * DOM0LESS_ENHANCED_LEGACY: Same as before, but using DOM0LESS_XS_LEGACY.
- */
-#define DOM0LESS_ENHANCED_NO_XS  BIT(0, U)
-#define DOM0LESS_XENSTORE        BIT(1, U)
-#define DOM0LESS_XS_LEGACY       BIT(2, U)
-#define DOM0LESS_ENHANCED_LEGACY (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XS_LEGACY)
-#define DOM0LESS_ENHANCED        (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE)
-
-struct kernel_info {
+struct arch_kernel_info
+{
 #ifdef CONFIG_ARM_64
     enum domain_type type;
 #endif
-
-    struct domain *d;
-
-    void *fdt; /* flat device tree */
-    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
-    struct meminfo mem;
-#ifdef CONFIG_STATIC_SHM
-    struct shared_meminfo shm_mem;
-#endif
-
-    /* kernel entry point */
-    paddr_t entry;
-
-    /* grant table region */
-    paddr_t gnttab_start;
-    paddr_t gnttab_size;
-
-    /* boot blob load addresses */
-    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
-    const char* cmdline;
-    paddr_t dtb_paddr;
-    paddr_t initrd_paddr;
-
-    /* Enable pl011 emulation */
-    bool vpl011;
-
-    /* Enable/Disable PV drivers interfaces */
-    uint16_t dom0less_feature;
-
-    /* GIC phandle */
-    uint32_t phandle_gic;
-
-    /* loader to use for this kernel */
-    void (*load)(struct kernel_info *info);
-    /* loader specific state */
-    union {
-        struct {
-            paddr_t kernel_addr;
-            paddr_t len;
-#ifdef CONFIG_ARM_64
-            paddr_t text_offset; /* 64-bit Image only */
-#endif
-            paddr_t start; /* Must be 0 for 64-bit Image */
-        } zimage;
-    };
 };
 
-static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo)
-{
-    return container_of(&kinfo->mem.common, struct membanks, common);
-}
-
-static inline const struct membanks *
-kernel_info_get_mem_const(const struct kernel_info *kinfo)
-{
-    return container_of(&kinfo->mem.common, const struct membanks, common);
-}
-
-#ifdef CONFIG_STATIC_SHM
-#define KERNEL_INFO_SHM_MEM_INIT                \
-    .shm_mem.common.max_banks = NR_SHMEM_BANKS, \
-    .shm_mem.common.type = STATIC_SHARED_MEMORY,


      

      
This line type = STATIC_SHARED_MEMORY,




      

        
-#else
-#define KERNEL_INFO_SHM_MEM_INIT
-#endif
-
-#define KERNEL_INFO_INIT                        \
-{                                               \
-    .mem.common.max_banks = NR_MEM_BANKS,       \
-    .mem.common.type = MEMORY,                  \


      

      
and also this line type = MEMORY,
...




      

        
-    KERNEL_INFO_SHM_MEM_INIT                    \
-}
-
-/*
- * Probe the kernel to detemine its type and select a loader.
- *
- * Sets in info:
- *  ->type
- *  ->load hook, and sets loader specific variables ->zimage
- */
-int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
-
-/*
- * Loads the kernel into guest RAM.
- *
- * Expects to be set in info when called:
- *  ->mem
- *  ->fdt
- *
- * Sets in info:
- *  ->entry
- *  ->dtb_paddr
- *  ->initrd_paddr
- */
-void kernel_load(struct kernel_info *info);
-
 #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
 
 /*
diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/arch/arm/include/asm/static-memory.h
index 804166e541..a32a3c6553 100644
--- a/xen/arch/arm/include/asm/static-memory.h
+++ b/xen/arch/arm/include/asm/static-memory.h
@@ -3,8 +3,8 @@
 #ifndef __ASM_STATIC_MEMORY_H_
 #define __ASM_STATIC_MEMORY_H_
 
+#include <xen/fdt-kernel.h>
 #include <xen/pfn.h>
-#include <asm/kernel.h>
 
 #ifdef CONFIG_STATIC_MEMORY
 
diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h
index 94eaa9d500..a4f853805a 100644
--- a/xen/arch/arm/include/asm/static-shmem.h
+++ b/xen/arch/arm/include/asm/static-shmem.h
@@ -3,8 +3,8 @@
 #ifndef __ASM_STATIC_SHMEM_H_
 #define __ASM_STATIC_SHMEM_H_
 
+#include <xen/fdt-kernel.h>
 #include <xen/types.h>
-#include <asm/kernel.h>
 #include <asm/setup.h>
 
 #ifdef CONFIG_STATIC_SHM
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 2647812e8e..f00fc388db 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -7,6 +7,7 @@
 #include <xen/byteorder.h>
 #include <xen/domain_page.h>
 #include <xen/errno.h>
+#include <xen/fdt-kernel.h>
 #include <xen/guest_access.h>
 #include <xen/gunzip.h>
 #include <xen/init.h>
@@ -16,6 +17,7 @@
 #include <xen/sched.h>
 #include <xen/vmap.h>
 
+#include <asm/domain_build.h>
 #include <asm/kernel.h>
 #include <asm/setup.h>
 
@@ -101,7 +103,7 @@ static paddr_t __init kernel_zimage_place(struct kernel_info *info)
     paddr_t load_addr;
 
 #ifdef CONFIG_ARM_64
-    if ( (info->type == DOMAIN_64BIT) && (info->zimage.start == 0) )
+    if ( (info->arch.type == DOMAIN_64BIT) && (info->zimage.start == 0) )
         return mem->bank[0].start + info->zimage.text_offset;
 #endif
 
@@ -371,10 +373,10 @@ static int __init kernel_uimage_probe(struct kernel_info *info,
     switch ( uimage.arch )
     {
     case IH_ARCH_ARM:
-        info->type = DOMAIN_32BIT;
+        info->arch.type = DOMAIN_32BIT;
         break;
     case IH_ARCH_ARM64:
-        info->type = DOMAIN_64BIT;
+        info->arch.type = DOMAIN_64BIT;
         break;
     default:
         printk(XENLOG_ERR "Unsupported uImage arch type %d\n", uimage.arch);
@@ -444,7 +446,7 @@ static int __init kernel_zimage64_probe(struct kernel_info *info,
 
     info->load = kernel_zimage_load;
 
-    info->type = DOMAIN_64BIT;
+    info->arch.type = DOMAIN_64BIT;
 
     return 0;
 }
@@ -496,7 +498,7 @@ static int __init kernel_zimage32_probe(struct kernel_info *info,
     info->load = kernel_zimage_load;
 
 #ifdef CONFIG_ARM_64
-    info->type = DOMAIN_32BIT;
+    info->arch.type = DOMAIN_32BIT;
 #endif
 
     return 0;
diff --git a/xen/arch/arm/static-memory.c b/xen/arch/arm/static-memory.c
index d4585c5a06..e0f76afcd8 100644
--- a/xen/arch/arm/static-memory.c
+++ b/xen/arch/arm/static-memory.c
@@ -2,6 +2,7 @@
 
 #include <xen/sched.h>
 
+#include <asm/setup.h>
 #include <asm/static-memory.h>
 
 static bool __init append_static_memory_to_bank(struct domain *d,
diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
index e8d4ca3ba3..14ae48fb1e 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/arch/arm/static-shmem.c
@@ -6,6 +6,7 @@
 #include <xen/sched.h>
 
 #include <asm/domain_build.h>
+#include <asm/setup.h>
 #include <asm/static-memory.h>
 #include <asm/static-shmem.h>
 
diff --git a/xen/common/device-tree/dt-overlay.c b/xen/common/device-tree/dt-overlay.c
index 97fb99eaaa..81107cb48d 100644
--- a/xen/common/device-tree/dt-overlay.c
+++ b/xen/common/device-tree/dt-overlay.c
@@ -6,8 +6,8 @@
  * Written by Vikram Garhwal <vikram.garhwal@amd.com>
  *
  */
-#include <asm/domain_build.h>
 #include <xen/dt-overlay.h>
+#include <xen/fdt-kernel.h>
 #include <xen/guest_access.h>
 #include <xen/iocap.h>
 #include <xen/libfdt/libfdt.h>
diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
index 5655571a66..f095135caa 100644
--- a/xen/include/asm-generic/dom0less-build.h
+++ b/xen/include/asm-generic/dom0less-build.h
@@ -16,6 +16,34 @@ struct dt_device_node;
 #define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
 extern bool need_xenstore;
 
+/*
+ * List of possible features for dom0less domUs
+ *
+ * DOM0LESS_ENHANCED_NO_XS:  Notify the OS it is running on top of Xen. All the
+ *                           default features (excluding Xenstore) will be
+ *                           available. Note that an OS *must* not rely on the
+ *                           availability of Xen features if this is not set.
+ * DOM0LESS_XENSTORE:        Xenstore will be enabled for the VM. The
+ *                           xenstore page allocation is done by Xen at
+ *                           domain creation. This feature can't be
+ *                           enabled without the DOM0LESS_ENHANCED_NO_XS.
+ * DOM0LESS_XS_LEGACY        Xenstore will be enabled for the VM, the
+ *                           xenstore page allocation will happen in
+ *                           init-dom0less. This feature can't be enabled
+ *                           without the DOM0LESS_ENHANCED_NO_XS.
+ * DOM0LESS_ENHANCED:        Notify the OS it is running on top of Xen. All the
+ *                           default features (including Xenstore) will be
+ *                           available. Note that an OS *must* not rely on the
+ *                           availability of Xen features if this is not set.
+ * DOM0LESS_ENHANCED_LEGACY: Same as before, but using DOM0LESS_XS_LEGACY.
+
+ */
+#define DOM0LESS_ENHANCED_NO_XS  BIT(0, U)
+#define DOM0LESS_XENSTORE        BIT(1, U)
+#define DOM0LESS_XS_LEGACY       BIT(2, U)
+#define DOM0LESS_ENHANCED_LEGACY (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XS_LEGACY)
+#define DOM0LESS_ENHANCED        (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE)
+
 void create_domUs(void);
 bool is_dom0less_mode(void);
 void set_xs_domain(struct domain *d);
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
new file mode 100644
index 0000000000..c81e759423
--- /dev/null
+++ b/xen/include/xen/fdt-kernel.h
@@ -0,0 +1,133 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * For Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __XEN_FDT_KERNEL_H__
+#define __XEN_FDT_KERNEL_H__
+
+#include <xen/bootfdt.h>
+#include <xen/device_tree.h>
+#include <xen/types.h>
+
+#if __has_include(<asm/kernel.h>)
+#   include <asm/kernel.h>
+#endif
+
+struct kernel_info {
+    struct domain *d;
+
+    void *fdt; /* flat device tree */
+    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+    struct meminfo mem;
+#ifdef CONFIG_STATIC_SHM
+    struct shared_meminfo shm_mem;
+#endif
+
+    /* kernel entry point */
+    paddr_t entry;
+
+    /* grant table region */
+    paddr_t gnttab_start;
+    paddr_t gnttab_size;
+
+    /* boot blob load addresses */
+    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
+    const char* cmdline;
+    paddr_t dtb_paddr;
+    paddr_t initrd_paddr;
+
+    /* Enable uart emulation */
+    bool vuart;
+
+    /* Enable/Disable PV drivers interfaces */
+    uint16_t dom0less_feature;
+
+    /* Interrupt controller phandle */
+    uint32_t phandle_intc;
+
+    /* loader to use for this kernel */
+    void (*load)(struct kernel_info *info);
+
+    /* loader specific state */
+    union {
+        struct {
+            paddr_t kernel_addr;
+            paddr_t len;
+#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64)
+            paddr_t text_offset; /* 64-bit Image only */
+#endif
+            paddr_t start; /* Must be 0 for 64-bit Image */
+        } zimage;
+    };
+
+#if __has_include(<asm/kernel.h>)
+    struct arch_kernel_info arch;
+#endif
+};
+
+static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo)
+{
+    return container_of(&kinfo->mem.common, struct membanks, common);
+}
+
+static inline const struct membanks *
+kernel_info_get_mem_const(const struct kernel_info *kinfo)
+{
+    return container_of(&kinfo->mem.common, const struct membanks, common);
+}
+
+#ifndef KERNEL_INFO_SHM_MEM_INIT
+
+#ifdef CONFIG_STATIC_SHM
+#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS,


      

      
they are missing here...




      

        
+#else
+#define KERNEL_INFO_SHM_MEM_INIT
+#endif
+
+#endif /* KERNEL_INFO_SHM_MEM_INIT */
+
+#ifndef KERNEL_INFO_INIT
+
+#define KERNEL_INFO_INIT                        \
+{                                               \
+    .mem.common.max_banks = NR_MEM_BANKS,       \


      

      
and also here.

Why?

    

    
I just overlooked these changes (they’re relatively "new"). Thanks for pointing that out.

I’ll restore those types.

~ Oleksii


    

      

      

        
+    KERNEL_INFO_SHM_MEM_INIT                    \
+}
+
+#endif /* KERNEL_INFO_INIT */
+
+/*
+ * Probe the kernel to detemine its type and select a loader.
+ *
+ * Sets in info:
+ *  ->type
+ *  ->load hook, and sets loader specific variables ->zimage
+ */
+int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
+
+/*
+ * Loads the kernel into guest RAM.
+ *
+ * Expects to be set in info when called:
+ *  ->mem
+ *  ->fdt
+ *
+ * Sets in info:
+ *  ->entry
+ *  ->dtb_paddr
+ *  ->initrd_paddr
+ */
+void kernel_load(struct kernel_info *info);
+
+#endif /* __XEN_FDT_KERNEL_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.49.0



      

    

  


--------------nQ31WACAUenHgWQW15sowI58--


From xen-devel-bounces@lists.xenproject.org Mon May 05 11:33:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 11:33:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976043.1363291 (Exim 4.92)
	(envelope-from )
	id 1uBu4A-00028w-TP; Mon, 05 May 2025 11:32:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976043.1363291; Mon, 05 May 2025 11:32: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 1uBu4A-00028p-Ql; Mon, 05 May 2025 11:32:58 +0000
Received: by outflank-mailman (input) for mailman id 976043;
 Mon, 05 May 2025 11:32:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBu4A-00028e-2m
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 11:32:58 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20614.outbound.protection.outlook.com
 [2a01:111:f403:2408::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id af68c32a-29a4-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 13:32:55 +0200 (CEST)
Received: from SA0PR11CA0084.namprd11.prod.outlook.com (2603:10b6:806:d2::29)
 by SN7PR12MB7419.namprd12.prod.outlook.com (2603:10b6:806:2a6::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Mon, 5 May
 2025 11:32:51 +0000
Received: from SA2PEPF00003F65.namprd04.prod.outlook.com
 (2603:10b6:806:d2:cafe::22) by SA0PR11CA0084.outlook.office365.com
 (2603:10b6:806:d2::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.31 via Frontend Transport; Mon,
 5 May 2025 11:32:51 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00003F65.mail.protection.outlook.com (10.167.248.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Mon, 5 May 2025 11:32:50 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 5 May
 2025 06:32: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" 
X-Inumbo-ID: af68c32a-29a4-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=T//xABOGXvC0fEhwDWeUwgh/aKDLETJ2xTtn4CKIY7InKZE0/e+huu3koIJLA4CTLpvuguuzxTE8vsEk9N1FhdYzODxv2nyxDKH1V8H5fOoYqhGwMcyhvrCAYDIHDL5Ks5CQLiOUqLxqHjBZu3uqntG37snuNSdtMkKNboRmeTeZzv4O4upop5ovJ3VlaW3dBVhm9dKysHwuUc3y6LEKNRYDB4e4HlAYvRKiN2L5aKFBqtqppmV3g4Fo2hBZ6LigOObMLRfvJ1bqdR/Sz4GJubuKcGmKO+BTaoQ6TdaHKwsx17H9zTgdxDUjbuPRLg5oCYOx8iz09zIZLn6DJpl4FA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Co2k8Dvcv0C0IMqeGm4Y4i8zTo2rRA74FE65agiEEbY=;
 b=Vdc6ls4WK86Gg1oaLRN0qfuvlZzAF0KChoyo/9vCISpcggM8IE1PLN77hXS81xung3ZhaTwxCuW99CwBtALqUbiENgeGyMjfUspruZojuUWdUo/ZlnL2rONlgXeNEZrCQxngm3iocwh77RgInopwXjC2Xh/i8uWLd/YfLBMMEIeGBbpBCoMpTl3+Aer6EH4VwmVV9u//hXORWvfNKV5ULTCOIyRFGlq9uHOaiIlOb04Xnrx8QPx7ZH2sp0g1PQTyMvUwH0anU+NHw75BRNsIONTQjIkeOpUXnHzXdDURgfZ2SX6LpyKOGelJfPnLlyNzhxYR/w9nHzEzEpFhe9Cjpw==
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=Co2k8Dvcv0C0IMqeGm4Y4i8zTo2rRA74FE65agiEEbY=;
 b=Jmc6VCmL6Ht5pt7sk7cJYEeWYI+LnfZmcdsAHlX6l6wk38qOmsSZg/u95CHL/NbxK0iRx21c5c1zl0NEZEwq3L6K8J6KzWd3X1w0Fw+cBcGj42blt7VttFdPCmCi/1NTbjS+4RQwzCyrXaPuD7J49uE7HuOsLyoL7gx42zsJFKI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 5 May 2025 13:32:47 +0200
Message-ID: 
Subject: Re: Mapping memory into a domain
From: Alejandro Vallejo 
To: Demi Marie Obenour , Xen developer discussion
	
CC: Andrew Cooper , Juergen Gross
	, Xen-devel 
X-Mailer: aerc 0.20.1
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
In-Reply-To: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00003F65:EE_|SN7PR12MB7419:EE_
X-MS-Office365-Filtering-Correlation-Id: d79466fd-5cb9-46cc-b2bf-08dd8bc891b1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dktLWlR1b1NSVXNHNUZHWWRzN282cytnVlV2alpqWHJZdFlzOUw3OVZTTUlw?=
 =?utf-8?B?TEs3RklxZUxIZmZFelE0c3ZmQ0VxRVArUkV6VU9lVnQ4bGpxcmMrcTNXZGxR?=
 =?utf-8?B?cUZrMXJhc3c2Vi9LaVJ3bW0xU0d0RUI4QlphVjJzcnJwNEZ4eG5yeVYzQmpU?=
 =?utf-8?B?bGlleGNXaDh1eEsrUGRQdWZRNVBUWUFhYlAvelNzaC9UZmRZTjhJaytUNHlX?=
 =?utf-8?B?WEpzNXZXSHR0UkJicDhXbjNsTVQ4ZkttV3QvWWN0MXRjdGVmUGtxa0dmY3pP?=
 =?utf-8?B?OTdFdHR6NjlUMW5QVnhQbUViYk5MTEsvNVF4K2I2MUhoVjR5TXBzVFJqWVA5?=
 =?utf-8?B?M3ZnRTUyUTZQNDBuNUJCUTk3Y3ZuT2htbm1CNU9ZZyszb0RHeHNkMmlTU0hD?=
 =?utf-8?B?UW9pTFZsRHpkbXU5MmVxd0pqbHBUd292c3V3V1JiaUpBT2o5WFdSTlV3cUdR?=
 =?utf-8?B?TE5QWlVacGdWK3pGT1huRm53elp2TFFKejd6MlNSZ1VUMGtLUXRvblI3T1dO?=
 =?utf-8?B?RnBwL0xYbzFFSDFGWk0xQ3lOYmtWb3g2QXpzN2JUM0NieHhla0Jkck04NFBV?=
 =?utf-8?B?ZjcwSkVJdmNwMzYxSHhyT3ZrczdXU1NabXFMWlR2NDRDLzdZcUZ5UmY4SU1Y?=
 =?utf-8?B?d0wzOE9nYVY3UUxsT1NhSXB1aWtmcnQrVVpiV2dIay9WT3dWa00wVjhoK2Rj?=
 =?utf-8?B?Wmc3SkFuT0V3dEJmTHorV0VXV0xYdVlNVmw1Q085UUg0R1RWQy9iRFVHSGUy?=
 =?utf-8?B?Rk5wSHl0ckhHUGc3OG5RT1dweGMyRFg0YmYxdnMxMW95M054QTFHa1pjVkxj?=
 =?utf-8?B?YU0vekhRbG95N0hVaVFkV1lwMVcxQ0gxN3dXRGs0V1ZrdzhxZEJOMHRjY3c3?=
 =?utf-8?B?YW1qMS8zc25CeUZXQjBYZzNzL1hMUFFqbFNvUXMyOTAwWHBsemsxaTVyT2JQ?=
 =?utf-8?B?MW1jai83RGE1Z01LZmVYYjl2eFRVYkUxZ2lhakhTZW10dlZtb211aURWWG5J?=
 =?utf-8?B?U0g2V21OWFRZOTl1aXJrZWsySnJiclc3ZDZwL2VEZnkxaTc1R041VWU4TTlZ?=
 =?utf-8?B?L1dGOS9LTER5dGRGL3dhemhmRUtqejA3UGY4cDIwbkJXTjRUbUZycUkrK3NL?=
 =?utf-8?B?U0dEeCtjSjVrYnNDaEJZazdNaHdzZlhSRHBQUWpQUVdiQTh5OG9Nc2hvQTNu?=
 =?utf-8?B?WnUwMEI2QlRGcHh0YlRuVWswSXpWMW1RV2p5NXpyMTFrcTYxWnozc0ZiZWRS?=
 =?utf-8?B?d0RzeGUrYllqUG1CUE5NeDVaclFFY0daUjVHUkFTbmFuMlFaQXVzNWlaaWN5?=
 =?utf-8?B?bjdKeUF2cDlJUWZNVlRyS1d4TTQ5V1VyR2xWSVdqTGU5WHo5TDRTSDhOYjBU?=
 =?utf-8?B?SDRCMUR4VXppZHIxS0VDYzVJL1p2WDYwbUwyWFFUUVJiUUpEQkpIYm42Qjcy?=
 =?utf-8?B?UWFyZTlJYi9GaDBlbDNzV0lHT1NGeGRrbUllNWx2MlpsQTJkTk8yZ01oNU1P?=
 =?utf-8?B?Q3d4c3dCVG9nNTZ1SXJkZVNpVlhEVmlRU2EyaXpMLzQ3d1Fqd2pPbFdUTnlv?=
 =?utf-8?B?SDBGTUdsS251Z0luV0RkU0VoUkI2cEg5eW9CWnZXOFFSZU1OaGl6SjBlS0Rr?=
 =?utf-8?B?bU10d25DQTlyTlhpUEJPbVhDeC94UWw1d3laaDdKZVJsbjlhVVhSR3NNSFVl?=
 =?utf-8?B?NHI1TjRWRGdncXV6cVpvU3hDeGp0bk42OUVvbENlZXArbURuRGMrdXhmVXp3?=
 =?utf-8?B?N1IzQWtGYWFBbTFVUTNYZ2p4VVNtSzlTaEN1US9KRlo1bWVHczB6djNzUmw4?=
 =?utf-8?B?Uk9tQTNTcHhLWjIwenZaQ2E3TGQ3Nm1hWmY4R0xOekdWRW16dmhKekhvYXpx?=
 =?utf-8?B?WStNWFVVRWVyT0VIVEI3RlJreWlNWWs4Z1J5SEVabUJVcDhlM3BzZEVRZDht?=
 =?utf-8?B?TWNieU9Qb3JHckFSSi9MbjJacmFMMmRsNkFRa3VSRkRWOVUvb05JdmMrWWpn?=
 =?utf-8?B?ZWxHL3lQdW1WdHZUS2RIbmRHbUh1SGVNT1g2RXlSdklNT2p5Qlg0eU5odUU2?=
 =?utf-8?Q?Ax7h2d?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 11:32:50.9853
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d79466fd-5cb9-46cc-b2bf-08dd8bc891b1
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF00003F65.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7419

I suppose this is still about multiplexing the GPU driver the way we
last discussed at Xen Summit?

On Mon May 5, 2025 at 12:51 AM CEST, Demi Marie Obenour wrote:
> What are the appropriate Xen internal functions for:
>
> 1. Turning a PFN into an MFN?
> 2. Mapping an MFN into a guest?
> 3. Unmapping that MFN from a guest?

The p2m is the single source of truth about such mappings.

This is all racy business. You want to keep the p2m lock for the full
duration of whatever operation you wish do, or you risk another CPU
taking it and pulling the rug under your feet at the most inconvenient
time.

In general all this faff is hidden under way too many layers beneath
copy_{to,from}_guest(). Other p2m manipulation high-level constructs
that might do interesting things worth looking at may be {map,unmap}_mmio_r=
egion()

Note that not every pfn has an associated mfn. Not even every valid pfn
has necessarily an associated mfn (there's pod). And all of this is
volatile business in the presence of a baloon driver or vPCI placing
mmio windows over guest memory.

In general anything up this alley would need a cohesive pair for
map/unmap and a credible plan for concurrency and how it's all handled
in conjunction with other bits that touch the p2m.

>
> The first patch I am going to send with this information is a documentati=
on
> patch so that others do not need to figure this out for themselves.
> I remember being unsure even after looking through the source code, which
> is why I am asking here.

That's not surprising. There's per-arch stuff, per-p2mtype stuff,
per-guesttype stuff. Plus madness like on-demand memory. It's no wonder
such helpers don't exist and the general manipulations are hard to
explain.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon May 05 11:56:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 11:56:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976055.1363300 (Exim 4.92)
	(envelope-from )
	id 1uBuQj-0005Aj-Ky; Mon, 05 May 2025 11:56:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976055.1363300; Mon, 05 May 2025 11: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 1uBuQj-0005Ac-IK; Mon, 05 May 2025 11:56:17 +0000
Received: by outflank-mailman (input) for mailman id 976055;
 Mon, 05 May 2025 11:56:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBuQi-0005AW-8j
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 11:56:16 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f1e63c2a-29a7-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 13:56:14 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-acae7e7587dso691501066b.2
 for ; Mon, 05 May 2025 04:56:14 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1894c022bsm477030766b.89.2025.05.05.04.56.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 05 May 2025 04:56: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" 
X-Inumbo-ID: f1e63c2a-29a7-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746446174; x=1747050974; darn=lists.xenproject.org;
        h=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;
        bh=kq8FQfr0WeKKJCjisU3fxWI+DuWETWkFkZ7f6juxceg=;
        b=jRvSqw2Yr7WC1zt8beJeNSQUDbWmVItPZ3Fc68fUGgNrTZpI+djVnSVn0C/+WYC+vi
         jFgdVZumM9Y74OJvdO+5g0gTHS38o8uSAPT8OmEunUqSPFwN2CVFpAyK8l6cVkOBwC6r
         eFZxjnyNhuMfl9yfAZFQK758yw9bdmbuOU+3/uOChK0TONuOulThvodWT1Pt11+gNk6T
         IAvD7G2RwzW4m4gHbb5iU+lGXhYqO1MxyHzrHhE7E4uGfiJz3L6l1kua+PN5UQLv8LzI
         C0C9BBR6cT5vrKM6qmxTnd11MvrGXtv3GfL3hJem9tLgPg8jzguPDY9garC6EFZ/++XK
         Odgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746446174; x=1747050974;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=kq8FQfr0WeKKJCjisU3fxWI+DuWETWkFkZ7f6juxceg=;
        b=tpLzd1L7kYgr8EW5d/LpP1N8p+zg49gM4hnun4HvQVITOEl6drMRJg+ep2gwXkfS8E
         kauYQMrngFsmMIpc4Bixia7mlhEohUMhHGQJaVsf9TdXJlBa80frTGkWBiI9oECzmsPG
         maxEK1JsHQUjit+4fKcJv9f4yvppzfulDmgHjhMOzkg+Me8RacwM4HehSWudHWxFNppb
         vg5VmnzGm6ZlWkTjIKwDMaLFiheNavbPEamzx0sqGMZCVX1UnzHPx2OhkLCMygFnPEaK
         4eH84beSi5mklUqan4GynMwv66DDw2pDazIA1FrOkUiWl4Vgpg3UUpXqWwizZ/Vf/agF
         JDyQ==
X-Forwarded-Encrypted: i=1; AJvYcCUXbCqZtoW7nHsLXvRdikfZAGb1sR94i7ueojwi74E27txoacF3s2hWeSzsudlD+QEkXyY28+vF1G4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzypt8VnLmHopBYv7SQMR76u3fITEs8Vuk8fWcsQS78VSQG8z+A
	W5Bkxh5fWt8Rq358m0a61iA4X3oeytwo0IAmd++DzSq1yn6l77P9
X-Gm-Gg: ASbGncvG3zHuOMlA1qgvgHq39WJ2rLHVHbsidIgYe/56S0DAxpKGzgdcvyGkoDxYXYO
	EBULi4irDj0uPoe7e450U8jWi24AoT9KXDkjViBeT2lOBU/oGn0S5kWvqovekwgaTSsRp03olj1
	4iuKmAmv2bWUiJpQkyV5X1qG5S2w5DWCOxv+2jeXi4+AfasG3BtrLsAF7/0rY9UioQPzmmN7HBO
	1jf1dvdHUCuUZBq6PhSeI50K3ooU32uuMx9WzVMtTl0KZkLL9xT0ERs5wvJx0+yG8g2JSz/rhpc
	f8q0qwOnBoGu7b9Lg+BGmsin2pgjdLjVThX0uDKxSfuiWEb7hukWEZorqouljxybDMSKeU19LL1
	Y8149lHQgO9nMcSC1
X-Google-Smtp-Source: AGHT+IFMXlE81FNBLcQpMsjfS2JkJFfW54rZiWbQyl9SyOFAJJDaBFsmKVORMa1S2Fq0B1z7/igoNA==
X-Received: by 2002:a17:907:25c6:b0:ace:6d53:3da3 with SMTP id a640c23a62f3a-ad1a493159dmr539798266b.23.1746446173668;
        Mon, 05 May 2025 04:56:13 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------ZvohIC1AKe8bsEWLb3jw92ev"
Message-ID: <4616ca34-d6c1-4f63-8a27-8bd3ab40f879@gmail.com>
Date: Mon, 5 May 2025 13:56:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/8] asm-generic: move parts of Arm's asm/kernel.h 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: 
 <0c16f8fb2702db5fd6751c7da347a97caa431002.1746199009.git.oleksii.kurochko@gmail.com>
 <468fa57c-7e64-4a52-bfac-1280fbab4aee@amd.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <468fa57c-7e64-4a52-bfac-1280fbab4aee@amd.com>

This is a multi-part message in MIME format.
--------------ZvohIC1AKe8bsEWLb3jw92ev
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/5/25 11:08 AM, Orzel, Michal wrote:
> On 02/05/2025 18:22, Oleksii Kurochko wrote:
>> Move the following parts to common with the following changes:
>> - struct kernel_info:
>>    - Create arch_kernel_info for arch specific kernel information.
>>      At the moment, it contains domain_type for Arm.
>>    - Rename vpl011 to vuart to have more generic name suitable for other archs.
> Why do you want to make it common? At the moment it referres to vpl011 which is
> Arm specific, so it would be better to move it to arch specific struct. Also,
> there can be more than one emulated UART (especially if you want to make the
> parsing of vuart common), in which case enum would be the best fit.

Good point. Actually, vuart/vpl011 could be moved to arch specific struct as
it doesn't used in common code anyway.

Thanks!

~ Oleksii

--------------ZvohIC1AKe8bsEWLb3jw92ev
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 5/5/25 11:08 AM, Orzel, Michal
      wrote:

    

    

      
On 02/05/2025 18:22, Oleksii Kurochko wrote:

Move the following parts to common with the following changes:
- struct kernel_info:
  - Create arch_kernel_info for arch specific kernel information.
    At the moment, it contains domain_type for Arm.
  - Rename vpl011 to vuart to have more generic name suitable for other archs.

Why do you want to make it common? At the moment it referres to vpl011 which is
Arm specific, so it would be better to move it to arch specific struct. Also,
there can be more than one emulated UART (especially if you want to make the
parsing of vuart common), in which case enum would be the best fit.

    

    
Good point. Actually, vuart/vpl011 could be moved to arch specific struct as
it doesn't used in common code anyway.

Thanks!

~ Oleksii



  


--------------ZvohIC1AKe8bsEWLb3jw92ev--


From xen-devel-bounces@lists.xenproject.org Mon May 05 11:56:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 11:56:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976060.1363310 (Exim 4.92)
	(envelope-from )
	id 1uBuRD-0005aJ-SR; Mon, 05 May 2025 11:56:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976060.1363310; Mon, 05 May 2025 11:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uBuRD-0005aC-Pk; Mon, 05 May 2025 11:56:47 +0000
Received: by outflank-mailman (input) for mailman id 976060;
 Mon, 05 May 2025 11:56:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBuRC-0005AW-V6
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 11:56:47 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20600.outbound.protection.outlook.com
 [2a01:111:f403:2407::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 035634b8-29a8-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 13:56:44 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SA1PR12MB6869.namprd12.prod.outlook.com (2603:10b6:806:25d::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Mon, 5 May
 2025 11:56:40 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%4]) with mapi id 15.20.8699.026; Mon, 5 May 2025
 11:56: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" 
X-Inumbo-ID: 035634b8-29a8-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IF0e0sxKMPiBo6SBQcbKUmDGKPsA/qIKiVVj69bQr4ZeG+e2kJU7nU5W58qJxeGxGXn3kWXMxEG6P5XUvTBciIXtlvPbOB1Mpk5EY66sBGVDPZsvgteQM99D1bA86tFdvpYTMYDVoHhhnlplWcQSH5UBKOkbmTXZlQ+15y+TLZnYfCiOGpcjxBKAFOB1wG83wK3JueBP9yQklCBpR0CqaEYyCcyG7RuBpmIJ9OxOBMUYsmtw5qmCZLurReZ+tt2HesNdS9sp7sp5Bfmu954kv9wpzY+lHayoWN6CwxmPsli69RWVi5kUfxGxODv1JfRE67l8oHtQNQVRWWpfmUCzvA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Gdyd1A7VaCsDKtBqZm7s0KOI1JJTWCPGPRXkE6vmliU=;
 b=jM+xpHtUM8nCs9s/+W0RJLFFqX/6OhBLU03Ge+Wze+sn3OUH4R6cr7dDZCBPa2F/3izX+qKgkMsx73Vs+3j0bz50H4B42jHumSZsDzMzY/qL0Z1iuNhGzVSe7U/O2A3FyNPdJlGXoh/H/o0NbbXm033BHZSx0u3gplPhK0+t4Q7hYQwhDyf7GtRToTH0V7qf53sUZowpLPOhbLKAYV/QWA2t3Tks1lphA1yrrltC9Dc3gWZtswImKhmZXqC7UkAi5iPUveqdDgZ94NXXqw6+TgPAWkN2Hnk7/scNR4kQvNemtira+jrM4R0VYCVG6U7penWl92i0AFuw+0sm7eQewA==
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=Gdyd1A7VaCsDKtBqZm7s0KOI1JJTWCPGPRXkE6vmliU=;
 b=m2x7qFCPE4L8sLkHY7YQUAaKcIwDph5u4TYDNJpRIpndKpjm2EFrupXCCUh8gtYISYm7NasKSt+Odmsg8lUquvltJYFMk/jwNP7KMmAre858lgK+3ndpMzaNtq2YzXLf8mPD9eofoDvkJ4I2bSy4EfFegoyq585IbHjlYwjl9jU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Mon, 5 May 2025 13:56:37 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 4/7] arm/mpu: Provide access to the MPU region from the
 C code
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-5-luca.fancellu@arm.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250429152057.2380536-5-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0161.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:99::20) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SA1PR12MB6869:EE_
X-MS-Office365-Filtering-Correlation-Id: caba65c2-20df-48a4-0f50-08dd8bcbe5c2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?K3Q4VkFyc3RLOGJ0S2lCaEdQWkpNN3dBb0lBcEtWc2dzYTlzUy91MlVBdU5U?=
 =?utf-8?B?Q2hCVm4xNVdnMnJCWjI1YkFEQVlrbC80cWhPTHFXVjZMeElMTUJtcSthMkJ0?=
 =?utf-8?B?cFpuUExWOVVBMms2NkJTZ0R2bVFXTmg3dkE2Tk1HQ1UrVTNqdnhCUzBkMGJY?=
 =?utf-8?B?TEVEazd3VWZCbkdrQXkzdzdTYmRvYWVFcGcyckxRSlhVdFJnc3FJS1B1RSsw?=
 =?utf-8?B?ZVl6NXFRcnhROGY2aGg3LzE5Y09ubGxuZ2J2ZlA4OTBwRVJJM1hZaHBrL0gy?=
 =?utf-8?B?TGRGeVA4eWk0THRNeFpVVFZ2aFdNMTRrTzVjdTlORlZwYUZIaWp1aWFEc3pZ?=
 =?utf-8?B?bmkrNE5QZEY1QXZ1eUhXNXUwV0hnaFdoeHdXRlRJVFVQeG9IVEpQdUh3Vkly?=
 =?utf-8?B?VjFRRnB0VUd3NFU4SHNjNFI2YSs3Tnh0aXEwaHp1YUJXakVidU9qNGlyTUxU?=
 =?utf-8?B?U3B2NjRNVzhOc0lNSEsxMUhaODZqeFFuRnZFSW0xQTZzVHU5TGd2YUh6VmZi?=
 =?utf-8?B?d2VFVkZLNWJUd1Vvc1JrYWQ1Skg2cmJ5SEZncDFYWTkxSXNveVN4Vk9SU0FN?=
 =?utf-8?B?c1ZVa29TaGRES21DenVYTDNNbCtmSlAvSU43K2RWYk01OVhObjIzYTh1R0FP?=
 =?utf-8?B?bVhETWc1ZHZyRWY2WUhVendiWlNXRXR2OEswa3ZvWms5RlZPblM5SmdYbEgr?=
 =?utf-8?B?WHBrczJBa0FlUy9LMWdneUJtWDZCYjdFOFZoSEFvVjFaZWZtSnFkTE9ybTVv?=
 =?utf-8?B?ZG1IUnRjd1RqaFZnYnh3eHNDK0Z3bEFsK0VLVHZ1N3hGNDhObG1UVHJIeHRa?=
 =?utf-8?B?aUtlT1VKVnpmZ3ZuRmgybWdnSlp5K1MwczNveHFNeEsxTGlLTFNhTi9rNUNh?=
 =?utf-8?B?QTJ5NDYrbjYzYjhTOHBaK0k0QzVEb2pVM0dDVi9GQUt4NFk5K25NeHpJYTBw?=
 =?utf-8?B?dXA2ZmhuYW4wTk05cDZQTFUzRlp3RGJuOVFySEdyNFo5M3UrbUdpZlVyWmRO?=
 =?utf-8?B?RjE5QThXYUlkWUFkbjNZbENFdjRaQk5uSzl1RngvZG1rNTl6QXN6YlAxSVZF?=
 =?utf-8?B?OEkzU0RUc3BvWktrVC84enRrNGRkVVFHL3pkWitLOUw1NU12OXRGWURmNlVV?=
 =?utf-8?B?R2R0ZXFZcEVoT0dhZW0zMjhvVmtRMVVtbTFhMVBQZnM0Y3ZmOUlKbjJkVG9O?=
 =?utf-8?B?ZkFvUE9HSHdMREFmZXc4UDZ1ejk2V1FCUHMzaXJZS0FISFZWYUQzbHB5a3Er?=
 =?utf-8?B?SmVHMHQxWDhJZUFZMU1uMlpYbS9JdHI0ZHNaMWhvTUZ4b1REbTArU0pVRHlS?=
 =?utf-8?B?RDFVS3ZPQXFmTlpoc3ZtT0pYNmw3U0VwQ0tTeXVVQ1FmRDVVakI5bnRYa2ps?=
 =?utf-8?B?NFprNHRDTGQ0MW5ocGFPNVk2QlFmNU1EMjkzc3ZZWTkyWFo4OWZOMWkydXd6?=
 =?utf-8?B?VHcwZDVFRGgxbWtmNzFMWEZST3BJT2lUcFQ5YjRUZjRFbWJha1pzcG5PcW8x?=
 =?utf-8?B?VEhWNG9zaE1KczcrcXBmUy9FV3dkc0VnYU53L3hlY1g4cXl2MFlkM0VJWDlh?=
 =?utf-8?B?K3Z1Ry9QNUppRGRsaGZwZGQvWlVTRGlYdkFUU2ZnNTFCaGhHTzFjZHhmY1h0?=
 =?utf-8?B?MVJ2N1NnRkZBSnlXY2NkWUt0NFZ2OVcrbTBQdUpybUhxNW1LWFZ4TGtadVZv?=
 =?utf-8?B?dzY4NzFVTzJ4NUxVRG1hemg4SDlKOXRsZmJhRWxPS1grYnpYM2JZVFc1ZUow?=
 =?utf-8?B?LzJsWDBjKzNUVXNiOFJpMnBWL0R2bW4rY1owaFl4WTNod1BFN253cWw2S1BM?=
 =?utf-8?B?RzNYVGVMS3VUdVZybG9VNjVHWkhuRWdMemphWXRabmdrNzV3MTdaSUVuODJQ?=
 =?utf-8?B?NFFDNndPeHdwUytDQmppTEJra0dvRUhiaExNTGNNUFJGNi94bVhaV1VXWGJ1?=
 =?utf-8?Q?TiOOA0ze60A=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QmxpWGJrTXFKVUhCY1lhODBLUFFCN3NHRHI4M1d2ckF5Rm9sZU44dFJLQjRC?=
 =?utf-8?B?TEZ0V05EaG5UQXF4dE0vc0ltdzdtTEN2TWhNWFEwK3QxSVZZRkQxT1dMR2tW?=
 =?utf-8?B?VFRXSE42SUJUNlljSldPRFZ0S0JyU2JmczhXbGxGQm1EZEE1QXlUekk5RUN2?=
 =?utf-8?B?N1VmQ29HUG43K28vRE44ZzR6U3dtS0xZajRaaHBhWGIraFdhS0RlNzI5OVJK?=
 =?utf-8?B?R3NLSzdhcnpnNDdMOWVBR3NtdFlDbVk1VFM0WmRIT0p0WTlidGhWN0FhczlC?=
 =?utf-8?B?ZlNxZXZsT29hVUpDQzg1OFNXcDdxSnllN1ExOEJCR3FYaTlXcy8veU5IcjJV?=
 =?utf-8?B?M3NaT2lXclBnV2Rhbkl4bnJXQ0hjcmw3azA2OWxYRndpRG10Rmt6ZGpGVkNF?=
 =?utf-8?B?MzkzQ3NUcDZtemRpTTRUaFpWbDNxT0hwRS9PS1UwU0JMbHVXTnFWSjhxNkxn?=
 =?utf-8?B?NzhTUktSZGIvb2lQRzBrdm1aSlQ0ZldyVTNNdGJ2TkpTSU1tMHBwc1NZc0k3?=
 =?utf-8?B?aC9KRjJQellWMGdiRE41VG9ySGZXNlVNMm1IMXB4bE5RZWxCNXVDSkNVQVFP?=
 =?utf-8?B?aDJla20rNWYrUEN1clBXK01XVTBTTm5sSW5ZaTFwV3MyNitORnFaWmhVN3JP?=
 =?utf-8?B?aE1jTEVOSExTWjlOQkg3SXF6UW53TWdvK3dIWjVXWVhPZlJQK2NrcEFMZzBE?=
 =?utf-8?B?VWFZOGk0VWNlV1ZqdEZycmo3azMya2g2RjVQTnpNRDF5Zk0xQmxyN3RQRFF1?=
 =?utf-8?B?eHQ0bkx1SXdFQ2tKUm0vdGpvMzFNUzQvN3owcUMxOERtQWdqTGtNN1M3OFJ4?=
 =?utf-8?B?TFc3VWFWcEQ2dHdEakdLZ3VxYXdLSFZKbng4WG4xbGZDdWcxbWp3dzNhOEM1?=
 =?utf-8?B?SHVRMlRwQjkyclN2TzVwalBLdEpnLzNNK1krSXN4dU5GeTdITjJuL1dRdUMw?=
 =?utf-8?B?bWNGYytnenhGek1JYTNMN09xNU00L2s2TktkNms3TWxBSnk0ZWhwNGJFWGVW?=
 =?utf-8?B?SWpTSVdBWExkNVYwcjMySC8zMWVXdDkxaEJqQU03WUtJbStCZWEwS2U2Zldt?=
 =?utf-8?B?R0pyU294MFNKWEl3bHkvT0dESVBHMWh5RlM0NGRTNFlyY1RrQWxCdEVUZTlx?=
 =?utf-8?B?eENrSWY4KzMvWk9RVFFaOS9YaXZselBsNlhJQWZDa2R5SFZEUTJUMlU5Mmdo?=
 =?utf-8?B?SUx1UHBLRWFUb2tyVitkM0doMUpjaHpHUVFIdndnbWxvbkNTZnJrczMrSHhF?=
 =?utf-8?B?N2N3dmdKcUdQNmFENjhieWMwZzFQNG9RcGt2TkF6ak5lU1VFaWl3SGh6c2ZX?=
 =?utf-8?B?bEx3SEdmSDBFN0plRkFCc09HaFdPZXNRVEZNN3U5d1c1ODJqcmhkUnlqZXdU?=
 =?utf-8?B?MnVEZTYzVzYvRVUyZWVkUTRzRndsKy8wckF5L3pnbTZvNWh0Y0RDakFaR1Az?=
 =?utf-8?B?ZENERHdDME05d3Q3RVRPMkFQSndmaWFyR2szSGlLQXJOL2VQelN5MzJZbGxa?=
 =?utf-8?B?Mnp4N0NNUnlTRFJLUVhKbW1SOXROQmhKclpLYlY1SEUzYkFuaVdUalFuVDEv?=
 =?utf-8?B?VlQyUmloc1JyOE1zMFZRYk5nRVllSkhlbDdBRUlVSi9Yb3ZzLzJKZm1zWmtO?=
 =?utf-8?B?WlJGdGNJMGx4TFF4bGM2U2RGMU9VR3F0ZmV1cW16Z3FNT04xV2E3ODdXTFhU?=
 =?utf-8?B?YUJOSXVvM3ZLdEE0N2VWc2RsNVo2cmR2L25OUDBpVHNocGlJK2dYTGMrUGFI?=
 =?utf-8?B?N1RjNG5GWWNpZW5HQVRnQUdtRWJKUHpCZm1LeklDUm1qYjhCMFp5TjRkZ0JO?=
 =?utf-8?B?VzFQMDROTTh1MEZ6QklmckNqTTZHdjk4TUJ5R25TV1U1R1p4eGI5QlVhbnhw?=
 =?utf-8?B?S1lmaXFBZTlUZlNKQzBlei96UGlnRUt5RlFYQzNyM0E2NGJuQm04aGhOYnJU?=
 =?utf-8?B?alo4NXYyN3VUQk96VHVjNzIrb2wvYWQ5cExaUTZEMDNQeEZQbXNvL0J6QnZx?=
 =?utf-8?B?R285dTZNWU5vMmx4TWFzZGVjRmwrNUFZUTVsbU1zWjRPbXJrQ3RCamlJYVR0?=
 =?utf-8?B?QldnZC9JL0xoNDhXdHRrMTY0L3NTMWtDYXdNT2t4bnZBTnU0U2lldUFQTEx4?=
 =?utf-8?Q?oDaU=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: caba65c2-20df-48a4-0f50-08dd8bcbe5c2
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 11:56:40.7747
 (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: Z+X5u/+7NtQB181h9QnXqRMb+rPQmvAvNCcShO/q5h83A1JmijSArTI06w3fnQL1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6869



On 29/04/2025 17:20, Luca Fancellu wrote:
> Implement some utility function in order to access the MPU regions
s/function/functions/

> from the C world.
> 
> Signed-off-by: Luca Fancellu 
> ---
> v4 changes:
>  - moved back PRBAR0_EL2/PRLAR0_EL2 to mm.c and protect
>    them with CONFIG_ARM_64, changed comments, fixed typos and code
>    style
>  - Add PRBAR_EL2_(n) definition, to be overriden by Arm32
>  - protect prepare_selector, read_protection_region,
>    write_protection_region by Arm64 to ensure compilation on both
>    arm32 and arm64, Arm32 will modify that later while introducing
>    the arm32 bits.
> v3 changes:
>  - Moved PRBAR0_EL2/PRLAR0_EL2 to arm64 specific
>  - Modified prepare_selector() to be easily made a NOP
>    for Arm32, which can address up to 32 region without
>    changing selector and it is also its maximum amount
>    of MPU regions.
> ---
> ---
>  xen/arch/arm/include/asm/mpu.h    |   1 +
>  xen/arch/arm/include/asm/mpu/mm.h |  34 +++++++++
>  xen/arch/arm/mpu/mm.c             | 117 ++++++++++++++++++++++++++++++
>  3 files changed, 152 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
> index 1368b2eb990f..40a86140b6cc 100644
> --- a/xen/arch/arm/include/asm/mpu.h
> +++ b/xen/arch/arm/include/asm/mpu.h
> @@ -17,6 +17,7 @@
>  #define MPU_REGION_SHIFT  6
>  #define MPU_REGION_ALIGN  (_AC(1, UL) << MPU_REGION_SHIFT)
>  #define MPU_REGION_MASK   (~(MPU_REGION_ALIGN - 1))
> +#define MPU_REGION_RES0   (0xFFFFULL << 48)
This does not look like a common macro. It's arm64 specific.
Also, it looks like you use it in macros that are common too.

>  
>  #define NUM_MPU_REGIONS_SHIFT   8
>  #define NUM_MPU_REGIONS         (_AC(1, UL) << NUM_MPU_REGIONS_SHIFT)
> diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
> index 28339259c458..e2235e568e81 100644
> --- a/xen/arch/arm/include/asm/mpu/mm.h
> +++ b/xen/arch/arm/include/asm/mpu/mm.h
> @@ -41,6 +41,40 @@ static inline struct page_info *virt_to_page(const void *v)
>      return mfn_to_page(mfn);
>  }
>  
> +/* Utility function to be used whenever MPU regions are modified */
> +static inline void context_sync_mpu(void)
> +{
> +    /*
> +     * ARM DDI 0600B.a, C1.7.1
> +     * Writes to MPU registers are only guaranteed to be visible following a
> +     * Context synchronization event and DSB operation.
> +     */
> +    dsb(sy);
> +    isb();
> +}
> +
> +/*
> + * The following API requires context_sync_mpu() after being used to modify MPU
> + * regions:
> + *  - write_protection_region
> + */
> +
> +/*
> + * Reads the MPU region with index 'sel' from the HW.
If you use @foo style, you should use @sel here.
But IMO this comment does not bring any usefulness.
The name of the helper and parameter description is enough.

> + *
> + * @pr_read: mpu protection region returned by read op.
> + * @sel: mpu protection region selector
> + */
> +extern void read_protection_region(pr_t *pr_read, uint8_t sel);
> +
> +/*
> + * Writes the MPU region with index 'sel' to the HW.
> + *
> + * @pr_write: const mpu protection region passed through write op.
No need to say const in parameter description

> + * @sel: mpu protection region selector
Same here.

> + */
> +extern void write_protection_region(const pr_t *pr_write, uint8_t sel);
> +
>  #endif /* __ARM_MPU_MM_H__ */
>  
>  /*
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index 9eab09ff2044..40ccf99adc94 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -8,6 +8,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  struct page_info *frame_table;
>  
> @@ -26,6 +28,35 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
>  /* EL2 Xen MPU memory region mapping table. */
>  pr_t __section(".data.page_aligned") xen_mpumap[MAX_MPU_REGION_NR];
>  
> +#ifdef CONFIG_ARM_64
> +/*
> + * The following are needed for the case generators GENERATE_WRITE_PR_REG_CASE
It's read a bit odd. Perhaps remove 'generators' word and use 'cases:'

> + * and GENERATE_READ_PR_REG_CASE with num==0
> + */
> +#define PRBAR0_EL2 PRBAR_EL2
> +#define PRLAR0_EL2 PRLAR_EL2
> +
> +#define PRBAR_EL2_(n)   PRBAR##n##_EL2
> +#define PRLAR_EL2_(n)   PRLAR##n##_EL2
> +
> +#endif
> +
> +#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
> +    case num:                                                               \
> +    {                                                                       \
> +        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
> +        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
> +        break;                                                              \
> +    }
> +
> +#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
> +    case num:                                                   \
> +    {                                                           \
> +        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
> +        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
> +        break;                                                  \
> +    }
> +
>  static void __init __maybe_unused build_assertions(void)
>  {
>      /*
> @@ -36,6 +67,92 @@ static void __init __maybe_unused build_assertions(void)
>      BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
>  }
>  
> +#ifdef CONFIG_ARM_64
> +/*
> + * Armv8-R supports direct access and indirect access to the MPU regions through
> + * registers, indirect access involves changing the MPU region selector, issuing
s/registers,/registers:/ and perhaps use bullet points

> + * an isb barrier and accessing the selected region through specific registers;
> + * instead direct access involves accessing specific registers that points to
> + * a specific MPU region, without changing the selector (in some cases) and
What do you mean by "in some cases"?

> + * issuing barriers because of that.
> + * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR_ELx, n=1..15, are used
If for n==0 you used (), why not following the same style for 1..15?
It all improves readability of such long comments.

> + * for the direct access to the regions selected by PRSELR_EL2.REGION<7:4>:n, so
> + * 16 regions can be directly access when the selector is multiple of 16, giving
s/access/accessed/
s/is multiple/is a multiple/

> + * access to all the supported memory regions.
> + */
> +static void prepare_selector(uint8_t *sel)
> +{
> +    uint8_t cur_sel = *sel;
> +
> +    /*
> +     * {read,write}_protection_region works using the direct access to the 0..15
> +     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
> +     * only when needed, so when the upper 4 bits of the selector will change.
> +     */
> +    cur_sel &= 0xF0U;
> +    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
> +    {
> +        WRITE_SYSREG(cur_sel, PRSELR_EL2);
> +        isb();
> +    }
> +    *sel = *sel & 0xFU;
> +}
> +
> +void read_protection_region(pr_t *pr_read, uint8_t sel)
> +{
> +    prepare_selector(&sel);
> +
> +    switch ( sel )
> +    {
> +        GENERATE_READ_PR_REG_CASE(0, pr_read);
> +        GENERATE_READ_PR_REG_CASE(1, pr_read);
> +        GENERATE_READ_PR_REG_CASE(2, pr_read);
> +        GENERATE_READ_PR_REG_CASE(3, pr_read);
> +        GENERATE_READ_PR_REG_CASE(4, pr_read);
> +        GENERATE_READ_PR_REG_CASE(5, pr_read);
> +        GENERATE_READ_PR_REG_CASE(6, pr_read);
> +        GENERATE_READ_PR_REG_CASE(7, pr_read);
> +        GENERATE_READ_PR_REG_CASE(8, pr_read);
> +        GENERATE_READ_PR_REG_CASE(9, pr_read);
> +        GENERATE_READ_PR_REG_CASE(10, pr_read);
> +        GENERATE_READ_PR_REG_CASE(11, pr_read);
> +        GENERATE_READ_PR_REG_CASE(12, pr_read);
> +        GENERATE_READ_PR_REG_CASE(13, pr_read);
> +        GENERATE_READ_PR_REG_CASE(14, pr_read);
> +        GENERATE_READ_PR_REG_CASE(15, pr_read);
> +    default:
> +        BUG(); /* Can't happen */
> +    }
> +}
> +
> +void write_protection_region(const pr_t *pr_write, uint8_t sel)
> +{
> +    prepare_selector(&sel);
> +
> +    switch ( sel )
> +    {
> +        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
> +    default:
> +        BUG(); /* Can't happen */
> +    }
> +}
> +#endif
> +
>  void __init setup_mm(void)
>  {
>      BUG_ON("unimplemented");

~Michal



From xen-devel-bounces@lists.xenproject.org Mon May 05 12:08:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 12:08:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976083.1363321 (Exim 4.92)
	(envelope-from )
	id 1uBucR-0007hw-0W; Mon, 05 May 2025 12:08:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976083.1363321; Mon, 05 May 2025 12: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 1uBucQ-0007hp-Tx; Mon, 05 May 2025 12:08:22 +0000
Received: by outflank-mailman (input) for mailman id 976083;
 Mon, 05 May 2025 12:08:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBucP-0007hj-Gk
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 12:08:21 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20627.outbound.protection.outlook.com
 [2a01:111:f403:2414::627])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a088286f-29a9-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 14:08:18 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CY3PR12MB9556.namprd12.prod.outlook.com (2603:10b6:930:10a::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Mon, 5 May
 2025 12:08:14 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%4]) with mapi id 15.20.8699.026; Mon, 5 May 2025
 12:08:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a088286f-29a9-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Hw0Wqakt7LIMbPb8XSIxAtwpYrClvBJiOfVCGtPSaaWxFkOAl59ZDiNBhZZxwKZ/NDPn9Wh6nXHFRjTP3qkMVjtIbMvfh5/5zRpOddrfMDOtwv38u4KkRABnqyvK/cmn5NjOL8/CURmhMnZ2TWe7QQn8WD9E3gNpiGgL4XY0G0J4j2XkxVrYbHIa7S5VJdf9XjOSVI2Ksh12zQfKGdRg4L2TQ5cdFGk6PGJEeX7S78q8z5k0uooTSFjpjTiivE4UJ+hV+95+XZm3zFZvPO0fyZC0p4l+d62Y7Pqr5a1FsuQuPtliQIzeYq9TG0pCNVIcOkpHgwkloKCNMqcQu8IdhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mJJ0qItWcnQ3XRF6aJ7N1gpfTNCYMYpoKwARsVw8rrY=;
 b=aA77pxBXukECKCmivptTRL1YWbk1xuzbwBDU8yhTEKKKpiS/pedPaRdYeeTu2a6qZ6Ok+l81Uoa43a9jsYdMC9aOLNkiCP4SIY6ECqhcrF0XwNN3bnbuU5JjRaoL26r1nXFQpBsPwNMI0P396Sd2SQKAnMq6D8G6ZD72Gx5HY66Pid/cSRvB5DB5fTrE6+Dio3w9T+6iQhV2ewmIcKlBV4chZa5WYlUHN6lLTAUrcowQ0IzIWJrXnHfaxn/3ml8LY3TY+VGGZv6poy7Aix0ETGsfDJnkWYEh85fY/v5qBu5goROlboL7dNJBtuFMsLngfyJyMP2a4cbd5ELwJOa1gA==
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=mJJ0qItWcnQ3XRF6aJ7N1gpfTNCYMYpoKwARsVw8rrY=;
 b=TfdvJSNjKn6fjpve0ZOuKJ7QWEGe1ObUW0R5mdMWQTIhHVckaN/OCXrLJDui0hvXD1f1Ym5Ll9rBKVgk8GI9IIcM+GDNWdPIl0d25txVlFenMq6h/medXOXZFTsvMHlqVWxPt20h4bdEnarbqF6pPoowXaEyedSbbIbIm0RhwXE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Mon, 5 May 2025 14:08:10 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 5/7] arm/mpu: Introduce utility functions for the pr_t
 type
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-6-luca.fancellu@arm.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250429152057.2380536-6-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0065.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:93::11) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CY3PR12MB9556:EE_
X-MS-Office365-Filtering-Correlation-Id: 6ab03f44-0eb3-477f-9e19-08dd8bcd8349
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OWpQeGtjVnNlYisvMDdvUlpzOU1xckdWQlBoSTI0dzhKWWsrM050ME1rWUJk?=
 =?utf-8?B?anBPRE1Rd2hpVW9NTjIvQ2ZRbjBlTkh1dDA5TnhQYkY3U29TdjFpejNnbjFm?=
 =?utf-8?B?S2JtOVBwL2Y1N1VreVl3NjJwVm1KOUc5a1AweklNUGpqV2Nnd1o3Z0N5VVVG?=
 =?utf-8?B?UGFXNDl4UjAvRENoemRScW4ycVhMa3R1NG50VVg5eEpXOGZaVDZLb0tTYmNx?=
 =?utf-8?B?c0JnR2k4T2JvUVVTTEJoQTBDTHg2RFNZaWQ4SVJYcjNmU05naDBDNFBSVVlL?=
 =?utf-8?B?TDBnc3FuakoxZE41bk5QUTArelNUTmc2eEJMR0FpYnhMZVlvZGFqaElGUHBi?=
 =?utf-8?B?VFA3cmo5MndYTW13VkFJSHRtcDloTk5jRjU3T2IzZDFhV2l3MnRvK0VrL3dS?=
 =?utf-8?B?TFFMU2RxQ2FrYnNvbmFiK1B5ajRlMmIya2xYR1JCWHh1bDRTVDBYNVlpUzB2?=
 =?utf-8?B?a0NGelF4SFdiSHRmTUl1STl0bTN3c2dKWkpqY0s2L2xlWXRBcTJOLzFackVx?=
 =?utf-8?B?bjFRejUzNXV1RzVvaDVRL0VEdkhDWkFyaGcrcGI2bG0wWHJIYUtMelZobzBn?=
 =?utf-8?B?aXlPd0ovTXFVYTNJWUY2bEpQVkE4MkpYZDQvdlRmT2RmdmlReFFpaGxnd3VM?=
 =?utf-8?B?YW5jRW1DSk5BUkl5Qm0rRWFNVzF0WmZvbEUyWjNZeVFPT0wyUkV4Z09FR3c0?=
 =?utf-8?B?MW5iQnRLYjkvSVE1SWlGVGlQL00rU0JJaEJHSTluMW9rS0FxVHBBWGx6V2VE?=
 =?utf-8?B?R2g0aDdkWHhzMFo5eDB0aEhJS2FDZDN0RUQvSkIyRERZZmlCbDdDbkc2c0Z2?=
 =?utf-8?B?cmJnU250WlA4eEF5TW1iVkRDRmdUNmhTaHgyZEluRGhMZ1paRGQzRm9IeXd2?=
 =?utf-8?B?M1hVaUhhN3ozeE14RjZqUHc2K2JESTdQOVY3ODc5M0pOQURHRTFxY0NnV0Uy?=
 =?utf-8?B?bGtHK1phb1lERzlHLzgySUF0WjRYK0dJRUpsZk5yZzNxdHRDRitKbzBXWXln?=
 =?utf-8?B?RTI5VTlpY0tORDRERHptODRBREZObGwvUk00M2lMb2VvSDBoRGI1L1VsZ25O?=
 =?utf-8?B?NSsvYytYbkE2TGczTS9hY2oxU0FYVkUzVXh0Y2J0ZmppaHNuL2dSK0VXQ0xD?=
 =?utf-8?B?bXZtSnZkeFNoQ3pmVlFHeE1QQTJrTzh0a0wrUCtuZExyc1VsNlJ5QllhWlZ2?=
 =?utf-8?B?N3Nia1dvWXp3OXNSTmZxQ1l2KzJiRm1oRVhpRlBVeDFmWk5UMm1VZkl1bXQz?=
 =?utf-8?B?TTBaVS9pWEY5MlVhK1ZuL0dOUGZOMlZGT0pwVTlaa1pCVlQrb3ppT2lISk5B?=
 =?utf-8?B?bWhjRE1PMDVVdVJDTWJyb0s3WHhHVGRUZGd4eVB5ci9qV290cU9YNXJQNDJR?=
 =?utf-8?B?cThTRktlNHNNSHdiRDRHQjlCeGwxcllicFFpby9tU0pIRlRCdTN0djB0aU8w?=
 =?utf-8?B?ZU5WbFg0Z1FjR2NRYU5rclRlYXE2cHgyNDZXWlUvTzVWL0c1WmVxYnljbXVn?=
 =?utf-8?B?NWhuR1hnK3lXQUtHVmxmWnpRUTV3bHVVakszb0tDRTEwMTBFcEVtQ2x4bUdl?=
 =?utf-8?B?Skw1U0JTK1NOdTZ2UjVjOWllNGlwUnYvWVlIUm9naEY5U1JnV2hZSXB5SEVt?=
 =?utf-8?B?NlByTmk2amw5cHQyUllOaWxhWFVWbmxyM1Yzd3A3Z0xMUWFIeHJmYURIY3N6?=
 =?utf-8?B?K3FHYnBKWXJpZ3kzUXZBTExEY2FUYTVkT1VOUnN0OWM0aFNvcGQxWjhsbzAv?=
 =?utf-8?B?azdjei9maWhGdE92SFJJdEZkSXA5VzJkLzBYU2xuWmxQVE44YWdEcnZXTjlP?=
 =?utf-8?B?WXhFRmozeEc0bTk2eTZSRkUzNllTVkQ4UTBSSHYxQVpuMi9GOTQrYU8zZTBL?=
 =?utf-8?B?VlJYWk40SU8wS08ycEJTUGhJdWMrTGZVM2oyNmNzUUVVT0VMRG93SThEczcv?=
 =?utf-8?Q?t+/4W0lc4t0=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?WHNTbmRvdmFLQS9RejBKd3FuSjlycUd0cSt1R05iVTFJMzRuYUxqWVd1WTBy?=
 =?utf-8?B?WXl5YVltNGN4L1h1M3JEZEhucWU5SkJUTEJnMGxRT0k5RXpWeDBDWUZocml4?=
 =?utf-8?B?UzhaTjY0UFdKdkMyRUMxcithTmFhMXhZcERFNmJMaUFuRlQ4SnVybXlNUjFn?=
 =?utf-8?B?UktnOUMxUGdUVEdFWHVhOUtMdEtwVjJDaXNhSXBCYTRLVFo0ejd1R1dTZjlH?=
 =?utf-8?B?cUNJRGVmbmN1d256WUdTSS82YXRQM0lGMnEvTy90cm93YS9rQ01XREZ0WjZ4?=
 =?utf-8?B?b2R3cU03TFVvZjVjaXBKTkwyeDdaeUxnVWxCRGkvN2JISXFMbjhmSllqcnQ4?=
 =?utf-8?B?bzhGV3NYZEtJc1pZK3BDN2VKcUljVjRWOWN6N01KNzRkOHhhblFrOFhzdno1?=
 =?utf-8?B?UGZSd0tPVjIzMzgyYzFyVW56eC93UnBCUzBnS2JTSDNnZGg0WUlaRTFSS0Jr?=
 =?utf-8?B?VXM1MFhZZWlxQWhYd0M0SS9CR3ZmWWdhL1ZZWUJMT0hLb3RsL0JJUFVPblRI?=
 =?utf-8?B?anhSTnhkK1dPWHg1bk9ObDhXaUswVU9DNGlhMWpKbUdGaURwakZWbXYwbzQx?=
 =?utf-8?B?UGk5blFTaWEwcUphenZCbmxwRzdYTVhZRS9rb0tOUEhvMTRON2NKRHpoMzIy?=
 =?utf-8?B?dm4rZGFreWR0YWFKdmZVUWttY2V1Ri9ZMlBFQnYrYWlGOWJka3draTYybCtY?=
 =?utf-8?B?ZGpOcG1wR0ZkZmRRdzM0NkRoK1lBa1RxZmgreGhoWGZYNXhvK0ZmVkJGTkdY?=
 =?utf-8?B?VUVka1JYZ1ZveE9HeS9KZngwYjIrZFB4a091c2xZUGZVYXliWmhraEJ5OEF0?=
 =?utf-8?B?bUR0ckRMUlo4VmRJVHU1cHpuYmNRcEpWV0JqMm81Tk1rTHpyWTA1YktEeDU1?=
 =?utf-8?B?L0dOMGZzK2dlcy93MXJVdk96QmZjWkNCdlVOT2FEbVFYWFRIaldRQ1lMM0xN?=
 =?utf-8?B?T0g0TVNrK3JxdVoySmlDSmFVd21UNlV1ZXU4QVFzZEw0bWQ3dUg5L1ZzSWxW?=
 =?utf-8?B?K0hVMHFjbzdmN2cwS2s5U250SThYZ0Fnd2EzTEVWWlBZVktOWFFIbVh0UzM2?=
 =?utf-8?B?aFlNd29qeE85R3BiclZLL3VOR3lNRU9yNitjMzNqTkRMRDUyYXVxMmtiSWky?=
 =?utf-8?B?dERBVTBKd3Q4MXVGMlRWNUZLSGRHN080SFNMcmhKd29jc0RxeWpLaSt4OHF4?=
 =?utf-8?B?aitNeVRRbk5lbVdNU0czZnNzR1poeWtSbWNqSlhOUTBRN3NZWEZRRExKcXp4?=
 =?utf-8?B?c1h5YW9iQUtoMy9NNGU2T2YvN0J6THNHWW5JUWlabHlsV2pFbEF0MnorYmor?=
 =?utf-8?B?NHE1b1FkN2s1OURuREVlcmFMSjRMQXF4eUVuOHBIYThuV3FQSURRSEZEWmJC?=
 =?utf-8?B?WE50YUdSQWk0UExRdFBUS3lOcnVVZ29jUnNaQkFCbGNBVUxqWDNucjN2Nlhw?=
 =?utf-8?B?bENWME9OTzNMbXdCbHRkSWJDSDd5VFVPczlQZTRuMFZRV2ZjRXA4VzkvYkFD?=
 =?utf-8?B?ak9Md212bmF5ODJsTzA3TmtPNlNDSGw1SlQ0My9sbDNWWTFpdUZ1NTdaNlph?=
 =?utf-8?B?VTZwd2JmK3VQVkcxNFBuVGlZVWMySkFLNERNVHE0OG9DSjVFL0lqMUQ4S1JP?=
 =?utf-8?B?WSt1VW9PYnF2NjBzS1hkcCt4am9sY2UwMmd2NGxEVllWL3N5SUJLVlVpUmxv?=
 =?utf-8?B?eTUzOU5tN1lLSUthNkJ3NGxYRUlzb25aNjBQYnIrdk54UlBkMDE3c3dGM0sy?=
 =?utf-8?B?NmljL0wyS0xpdHhBdFprNExuS2RZaFRHNE5WMFBVZ1dwNzJqT1NRMk55UGIv?=
 =?utf-8?B?eGcyeW5TeG5CMkRtWGtlbFczeXpQSWtNVHNZK3ZuZkR1VVYrNFB4a2hoN1RC?=
 =?utf-8?B?TWJnOEd6b0tvTFMzbGMrdXhpdDRidWN4dDVtMzRzM1FFRTNHTTM2TUpFajF0?=
 =?utf-8?B?Vk9MQkp2M3pIZkNOTGxOSzZiUi92VUluaEpFUnJRVUVvYUphSEY2T2RrOUlZ?=
 =?utf-8?B?WGhDNjhITXdNKzJSTmhpTXV1Y3cwM1QybWkza2l3a1YxRFJ0N3RzSHptbk1W?=
 =?utf-8?B?d2xWN0NjSnUvZUc0aWlTaEhvSW9rbmVMVWRhaUVYQTZWeUlYWk5VT29mUXhP?=
 =?utf-8?Q?QUvPf2LVblCkvKdhUPqLtvUZZ?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ab03f44-0eb3-477f-9e19-08dd8bcd8349
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2025 12:08:14.5062
 (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: a39ga0zNSqkkNN43sewY/xh9atW+Czq8KXMslGZyiWQ+2MDj+fFtNE1+WU2Cq8wu
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY3PR12MB9556



On 29/04/2025 17:20, Luca Fancellu wrote:
> Introduce few utility function to manipulate and handle the
s/few/a few/
s/function/functions/

> pr_t type.
> 
> Signed-off-by: Luca Fancellu 
> ---
> v4 changes:
>  - Modify comment on top of the helpers. Clarify pr_set_limit
>    takes exclusive address.
>    Protected common code with #ifdef Arm64 until Arm32 is ready
>    with pr_t
> ---
>  xen/arch/arm/include/asm/mpu.h | 64 ++++++++++++++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
> index 40a86140b6cc..0e0a7f05ade9 100644
> --- a/xen/arch/arm/include/asm/mpu.h
> +++ b/xen/arch/arm/include/asm/mpu.h
> @@ -24,6 +24,70 @@
>  #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
>  #define MAX_MPU_REGION_NR       255
>  
> +#ifndef __ASSEMBLY__
> +
> +#ifdef CONFIG_ARM_64
> +/*
> + * Set base address of MPU protection region.
> + *
> + * @pr: pointer to the protection region structure.
> + * @base: base address as base of the protection region.
> + */
> +static inline void pr_set_base(pr_t *pr, paddr_t base)
> +{
> +    pr->prbar.reg.base = (base >> MPU_REGION_SHIFT);
Shouldn't you take MPU_REGION_RES0 into account?

~Michal



From xen-devel-bounces@lists.xenproject.org Mon May 05 12:47:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 12:47:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976096.1363330 (Exim 4.92)
	(envelope-from )
	id 1uBvDf-0004oM-LM; Mon, 05 May 2025 12:46:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976096.1363330; Mon, 05 May 2025 12:46: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 1uBvDf-0004oF-Ik; Mon, 05 May 2025 12:46:51 +0000
Received: by outflank-mailman (input) for mailman id 976096;
 Mon, 05 May 2025 12:46:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBvDe-0004o9-10
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 12:46:50 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 02884c22-29af-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 14:46:48 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-39c1ef4ae3aso2551342f8f.1
 for ; Mon, 05 May 2025 05:46:48 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099ae79d8sm10137329f8f.42.2025.05.05.05.46.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 05:46: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" 
X-Inumbo-ID: 02884c22-29af-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746449208; x=1747054008; 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;
        bh=P+VL0wqxMqE1quEoDvljUttyjHUDK003gdW4PwSJ+m8=;
        b=qJ2fjmS1JTUeH0kKyZOkyAD4gMHwIPSTuQJdi0Qb0hCe6LAnAp+qegZulrxHbGaFea
         RKJJnHeb3b2acB1UWAXOiEl49S+86+fznuNUtyHQHZxQWhDCoVE3iI1+U5hsioSRzq9O
         nV4NYJ/fJvOG8ftC84fGmVSHHxXiYZsKhjdvU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746449208; x=1747054008;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=P+VL0wqxMqE1quEoDvljUttyjHUDK003gdW4PwSJ+m8=;
        b=cosly43sICDw22605ny9asthTJBvh3B0030goA9k5o0Wu9B1Xoag27gvSatyIQ23sY
         dN8PrZWmPUwVFpWdv2IUyrPDFW+4idc6Z7LuL3pNei4Up4VYY0IXN6G7EwaLvvQMLYOL
         iCdZqct9UJyY5pjKZsWJh0a3Pi2D6u1C2GlkvblFq4u/PwT2badSmuwJdcTNZeKLkue4
         O6gVdrwR29M51jGLXAfexCXQMcxHnowvFbPrrtVS947p7gp5TiJ0SXqV2WdIKCR/lmeM
         UobehU36WrEk1eEauHj1CEw7Ae5clSzlzhDi9obX0H/27UbLo3lUlM9WoucSa7hRBvpl
         9NbA==
X-Gm-Message-State: AOJu0YzHE9j24vFXQSr7eyKLYgw+7qQ4iZ/iDcuDm+XahY/bOs9W4l/b
	B4hV8cCBtrKd9GJvbUsmvfneb+LWqbyzTI5orltyoX7BdY/5Klzr+Z0CDsoEc9Dm/3Vfc5KTuOc
	/DdI=
X-Gm-Gg: ASbGnctELXVO8tl24wSdqDkVAoMTJhw7sFtmrgtFQWkDRLlNgBueaNSAS1WAkFaz05G
	K7WYHAFxqZ4kkpI2OZ4ShtN5sHeY7yR2OzI8KmRiaMRde8jf546n+5rJrrVH+mA/lNkScP+ugHH
	c8yxkT5UcVgdmpF7BvzjOnQooMyAzcZBy0DdcaSQ5yUcDlQcY7qjEldROkt+NQHvN/JCfr0Znx+
	WiSfGGC6I2+BZdxxM+IFf9E4jMI4nv4bjoUT3aju+Jm/e3FLtE/gGGz66WODFaOo7PqoJhR4BC7
	Ve04xLPjE/4KmDjpXLKQJd7yvdQ3PI4gWuH6xNiQo7VqGznr8TGTJTjXfo/Mgs7rSgDrslXWLdo
	Op8RONv8jNMDM1g==
X-Google-Smtp-Source: AGHT+IFzb+Lb4Udr3dz0EmFhJodPqS3NWucS8PSc99lV2WQTX6ulqVzK4K9TJrViknXbfQKD64sOGw==
X-Received: by 2002:a5d:588a:0:b0:38d:dc03:a3d6 with SMTP id ffacd0b85a97d-3a09402ca18mr11846814f8f.4.1746449208050;
        Mon, 05 May 2025 05:46:48 -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 ,
	Roberto Bagnara ,
	Nicola Vetrini ,
	"consulting @ bugseng . com" 
Subject: [PATCH] xen: Use __auto_type
Date: Mon,  5 May 2025 13:46:46 +0100
Message-Id: <20250505124646.1569767-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

In macros it is common to declare local variables using typeof(param) in order
to ensure that side effects are only evaluated once.  A consequence of this is
double textural expansion of the parameter, which can get out of hand very
quickly with nested macros.

A GCC extension, __auto_type, is now avaialble in the new toolchain baseline
and avoids the double textural expansion.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Roberto Bagnara 
CC: Nicola Vetrini 
CC: consulting@bugseng.com 

The resulting build is identical.

RFC.  This requires a MISRA change, as it currently manifests as a R1.1
violation.  Nevertheless, I think we want to start using in places where we
currently use typeof(expression of ).

Eclair run on this patch (expecting a failure):
  https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1800631949

Min toolchain check:
  https://godbolt.org/z/f9WjooPYj

GCC Manual:
  https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
---
 xen/include/xen/macros.h | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/include/xen/macros.h b/xen/include/xen/macros.h
index cd528fbdb127..b5e5ff4b1c2f 100644
--- a/xen/include/xen/macros.h
+++ b/xen/include/xen/macros.h
@@ -71,18 +71,18 @@
 /* Hide a value from the optimiser. */
 #define HIDE(x)                                 \
     ({                                          \
-        typeof(x) _x = (x);                     \
+        __auto_type _x = (x);                   \
         asm volatile ( "" : "+r" (_x) );        \
         _x;                                     \
     })
 
 #define ABS(x) ({                              \
-    typeof(x) x_ = (x);                        \
+    __auto_type x_ = (x);                      \
     (x_ < 0) ? -x_ : x_;                       \
 })
 
 #define SWAP(a, b) \
-   do { typeof(a) t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
+   do { __auto_type t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
 
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + __must_be_array(x))
 
@@ -110,15 +110,15 @@
  */
 #define min(x, y)                               \
     ({                                          \
-        const typeof(x) _x = (x);               \
-        const typeof(y) _y = (y);               \
+        const __auto_type _x = (x);             \
+        const __auto_type _y = (y);             \
         (void)(&_x == &_y); /* typecheck */     \
         _x < _y ? _x : _y;                      \
     })
 #define max(x, y)                               \
     ({                                          \
-        const typeof(x) _x = (x);               \
-        const typeof(y) _y = (y);               \
+        const __auto_type _x = (x);             \
+        const __auto_type _y = (y);             \
         (void)(&_x == &_y); /* typecheck */     \
         _x > _y ? _x : _y;                      \
     })

base-commit: 78ce2be733b1e45e2e190c1765fe31da318d435f
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 05 12:57:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 12:57:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976107.1363342 (Exim 4.92)
	(envelope-from )
	id 1uBvNq-0006aD-IX; Mon, 05 May 2025 12:57:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976107.1363342; Mon, 05 May 2025 12:57: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 1uBvNq-0006a6-E8; Mon, 05 May 2025 12:57:22 +0000
Received: by outflank-mailman (input) for mailman id 976107;
 Mon, 05 May 2025 12:57:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBvNo-0006Zw-I0
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 12:57:21 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78e92764-29b0-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 14:57:17 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 0D7524EE7DAE;
 Mon,  5 May 2025 14:57: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" 
X-Inumbo-ID: 78e92764-29b0-11f0-9ffb-bf95429c2676
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=1746449836;
	b=cfDBtjv74drHMsMMvIwOjp9ak2ybpgOLQmEQJqD0b2fyuDOxemnN+mFhSmvZ5vsMPweN
	 xfp0gWSGKUcNp/nkkqwQUNmI+XEIooCyzH+PcEcZ0Jo/d0DIky64X9GFAcQiyr0yza15a
	 vS3IYAldspdMwZfK71c8WSn5I2MY7viLUF9z4PaZtIS2fStLm9bMLuQRihFrlrERJWmhi
	 NfcvQ68BfJcxmdro7XCvFoJW2aRYtzGmZ2zKNNSPIAMMzGrls1bI7Xjmxui12v2lKopki
	 HGiJ9VlUjZYvCGbz7h3vJWP23uKXBE7avu9Q+UEIqV1epTUM8TsHauZeh9f9ETbLK5GFA
	 73tINZlaF5JBw00V6xsmjqQel62Ww21Yxwq2361yw4TIl9yKOclLP4YS7+KLOk+6FT2F/
	 YZDiP8peSOi4OyEBEj/pQ+XmkLnN3ljXhurDlVnVCcne6YkaWvN7vKPGcdXJWFdxjDYgx
	 3QDqfawNJL1hLzuwlk5oHE3y7l827f2s8p4DwXCZ72nH+tuyZGkT7kPU5BfN8WoLAmrLN
	 0ZIZCiuEaZjJtlMiLHzTMGlVZdqyxcmmV82RFmjcGPLYjtw4y4ovXgNi9w/i6vJM2v03n
	 sEESv4cp2JP9PJEFf3DW0aVFM8bL7BLzFdc48+GC5/NnkFAFhtCCsNP4JKwzleg=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1746449836;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=+6q07O2QYqE5gk+2iKSDXVQnl8JvJZKymTeJI/7hVDk=;
	b=RzCc8xwKw9NIdpl+Y4gYZlcK2n8cFvDLE5FDvqQdsawDl/sWLfEtj3PtvnATm6A+UZvT
	 +kUCPyFXuvElj/AurjjddEkxWBPEt4VALVj64vOxvXNgcGmYagcOyElDvwKQAIicGAj6z
	 Ti9usDanqpqgl4/3ezCsGoHEFEunKLw15Q5Hhl183QNPGDb0pPbVj/jkV3faxYlOQyWTF
	 CEOdNSk4XTyfZmFgyYBS7JP9tOrAHxZj6/uzchwaGyo9hrXlngLtlwNMosP+8rX6GQ0Lg
	 L72k1aMCUbMmg2VowqIbR6kuTxV/0+mdvNSyAm8yXeISCVCdOobgElys1sr0XWNj1wAv3
	 cQiVYgIwZTxDtIYn2Dk+DLOhK9IgqkX8d1zmYSEgAyKsSsiV/71dqtJvKnY6VGn0LKOHR
	 BXmB7gQAZI/r6x9OAKYZIoteZSBf33tWHd3KYAtVp/q1VeLnTnmdWazQSui9FI6FQ6tlj
	 QZeXxIkGx9D51BnGiuaHu2++E995WFpzvUAicOG4V0o0vjWhT0P7ffbJpMin2VaqdJDPH
	 iodjuu0oT0nprI6iITjrr+we8cT6kd5klshGMmXTaOzRbs6NIXOfr97qakOW1EiyijsMN
	 rQu38R5dsAjR8IjPWGryGocSy2Z0QJWR7RaLfEhKJPqjP2VP50frMvmRcnS7WzU=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1746449836; bh=f+qrYVZxqGp3o1hxx/v0ijYEK0ZG3VMS8sHMYJ+qfoA=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=uEzTkcT4jm2aDHsNd6012W5YQg2Luc2sZC1N+aDI5nN+2wYpMVmwx2VQJMJJjCHt1
	 rnJBka9Fm4QxHGXlBGU6D1k8kDBckxjNRA/P6jUXd+aDRJ0iGIRm42cvruygsOShHx
	 X9i38Hfj1YvRRTHtgOM1frK3e7plbMVaggcsBqD3i0XmedHsb58v9auNPdgm7Sh1pL
	 U+ZyseiEmjtZNS5JxoG5i1DQ1c6FdR4ElHrVJ2heN4Vtih+ucOo/iUYiWlXN8TrCtE
	 BMUQ3PP8stHzpW8RnpRl1zt0ZEWZTQhzAR80C3FKAGJzdUgNQRxaM+/qEmUpgV7ga7
	 CbjnhJ5LnZmsg==
MIME-Version: 1.0
Date: Mon, 05 May 2025 14:57:16 +0200
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: Xen-devel , Anthony PERARD
 , Michal Orzel , Jan
 Beulich , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini
 , Roberto Bagnara ,
 "consulting @ bugseng . com" 
Subject: Re: [PATCH] xen: Use __auto_type
In-Reply-To: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
References: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
Message-ID: <707b9f833fd4cd0341ad09cbc3265ec9@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2025-05-05 14:46, Andrew Cooper wrote:
> In macros it is common to declare local variables using typeof(param) 
> in order
> to ensure that side effects are only evaluated once.  A consequence of 
> this is
> double textural expansion of the parameter, which can get out of hand 
> very
> quickly with nested macros.
> 
> A GCC extension, __auto_type, is now avaialble in the new toolchain 
> baseline
> and avoids the double textural expansion.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monné 
> CC: Stefano Stabellini 
> CC: Roberto Bagnara 
> CC: Nicola Vetrini 
> CC: consulting@bugseng.com 
> 
> The resulting build is identical.
> 
> RFC.  This requires a MISRA change, as it currently manifests as a R1.1
> violation.  Nevertheless, I think we want to start using in places 
> where we
> currently use typeof(expression of ).
> 
> Eclair run on this patch (expecting a failure):
>   
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1800631949
> 

Hi,

to make the analysis pass you need a couple of hunks in 
eclair_analysis/ECLAIR/toolchain.ecl:

-name_selector+={auto_type, "^__auto_type$"}

and add auto_type to the STD.tokenext config below around line 25, then 
later

-name_selector+={ext_auto_type, "^ext_auto_type$"}

and add "ext_auto_type" to the -config lines below

around line 125, along with a reference to the gcc docs above the 
configurations and in C-language-toolchain.rst

This is an extension, so it's usable without further MISRA impact.

> Min toolchain check:
>   https://godbolt.org/z/f9WjooPYj
> 
> GCC Manual:
>   
> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
> ---
>  xen/include/xen/macros.h | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/include/xen/macros.h b/xen/include/xen/macros.h
> index cd528fbdb127..b5e5ff4b1c2f 100644
> --- a/xen/include/xen/macros.h
> +++ b/xen/include/xen/macros.h
> @@ -71,18 +71,18 @@
>  /* Hide a value from the optimiser. */
>  #define HIDE(x)                                 \
>      ({                                          \
> -        typeof(x) _x = (x);                     \
> +        __auto_type _x = (x);                   \
>          asm volatile ( "" : "+r" (_x) );        \
>          _x;                                     \
>      })
> 
>  #define ABS(x) ({                              \
> -    typeof(x) x_ = (x);                        \
> +    __auto_type x_ = (x);                      \
>      (x_ < 0) ? -x_ : x_;                       \
>  })
> 
>  #define SWAP(a, b) \
> -   do { typeof(a) t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
> +   do { __auto_type t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
> 
>  #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + 
> __must_be_array(x))
> 
> @@ -110,15 +110,15 @@
>   */
>  #define min(x, y)                               \
>      ({                                          \
> -        const typeof(x) _x = (x);               \
> -        const typeof(y) _y = (y);               \
> +        const __auto_type _x = (x);             \
> +        const __auto_type _y = (y);             \
>          (void)(&_x == &_y); /* typecheck */     \
>          _x < _y ? _x : _y;                      \
>      })
>  #define max(x, y)                               \
>      ({                                          \
> -        const typeof(x) _x = (x);               \
> -        const typeof(y) _y = (y);               \
> +        const __auto_type _x = (x);             \
> +        const __auto_type _y = (y);             \
>          (void)(&_x == &_y); /* typecheck */     \
>          _x > _y ? _x : _y;                      \
>      })
> 
> base-commit: 78ce2be733b1e45e2e190c1765fe31da318d435f

-- 
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 May 05 13:00:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 13:00:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976117.1363350 (Exim 4.92)
	(envelope-from )
	id 1uBvQd-00085b-T8; Mon, 05 May 2025 13:00:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976117.1363350; Mon, 05 May 2025 13: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 1uBvQd-00085U-QV; Mon, 05 May 2025 13:00:15 +0000
Received: by outflank-mailman (input) for mailman id 976117;
 Mon, 05 May 2025 13:00:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBvQc-00085O-S7
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 13:00:14 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e26b378a-29b0-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 15:00:13 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-39c1efc457bso2900356f8f.2
 for ; Mon, 05 May 2025 06:00:13 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-441ae456d7dsm124743805e9.1.2025.05.05.06.00.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 05 May 2025 06:00: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" 
X-Inumbo-ID: e26b378a-29b0-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746450013; x=1747054813; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ckRb3816xOvrOSfUwo4e4ezXTtORSRAUO0FgMicU0EE=;
        b=NUNrYxSkDnDwS4WIIUnv0//4ZkALhzVqmTDGKNJARVRVO79ix51xQybrQcLhf+Ea1W
         RTV7Mi5428oj6d+dp5F3cZsoR+mHXv3yMPBVpUMW/UgPhkNoTBqUMjabYnz42zx20g4X
         oqsO7/AMO3h8PHi9FgMopHMSK5gvDYIZkmBLg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746450013; x=1747054813;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ckRb3816xOvrOSfUwo4e4ezXTtORSRAUO0FgMicU0EE=;
        b=HpCEQU79bBo65hsEDIGVC2H8fS60z5hHGwaYSZWrgxKWMMovJGWbAkIaNW/e9LSQSP
         bgQqB4D98OcnGfOfiW/RXWpM7pf4dhOUf8vluLFB8i2t8Vb8AXAqzsfh22CdiS31fmqs
         8F9kH+pZmZj0AM7oZmY1f1W6CujHWZtAUHtJ13ArvxpUCloXspn6ba7/CAxOEKaNwzme
         MibKjx4n4x9pmdZsGcQiY1IeLxuDcLhjAt6QL1gKKQ1HXPa2ZIyDh/wygvoCW0NYIKMZ
         pA7wp0iTXcqn7TwXi/QVDXBN3kOV/73HCLNFDuLYTAFjlgeli0loIiqKv75+oTv9Mo7A
         BO0w==
X-Gm-Message-State: AOJu0Yy0b5Tgk6fYsgWcjAlbFY+ruIrYPWkMCfD+Tw9a99zyIKtjzp9r
	5GAWcMk/pDArkYRMPdixuqboLBZT24VlSZp5vkTL+7PIW+CHwGykIht2XZ3MUwo=
X-Gm-Gg: ASbGncvdHIjionAVtrxwnq2kmH0Cws1ibnBhRHfmLyvshcTwYO47IL5qrj1ev+M4aX7
	IrKTh247EOh1t/0yBTPT/hsFy+vQJipxXoYsioxAneocZdO7nR6gMCKWjuDkW57gkbV5ghJhU7e
	XfcFTbpe7n0Ur001p88mkiJeTBhpg2c4/3LtcoX1vvBlWtiOIx9pszx+o/uQ+N5ZelZqPrGNIZf
	x0P3lF3BatvaLpvdSSm4yX4/Bttc7ptM1+D5AGrvzkKiO+gDoBDb+NgzOPnh4EYu1RrmAvDvukT
	YVxUa/1HiK9MFwXtThKy3amMvDrrVlqw1ycgTsEb5LYuI2l+YTmQ2J2KilAGS1V4Vk5RNj0AKxe
	mQhx52A==
X-Google-Smtp-Source: AGHT+IGIR2islggJYNlehilJg4010xIsu9DKOnt83vCTBASxQaD70HpLgNgl6pfbrS0yYhCp9CWqog==
X-Received: by 2002:a05:6000:40e1:b0:391:4bfd:6d5 with SMTP id ffacd0b85a97d-3a09fdd7bc3mr6082199f8f.52.1746450013399;
        Mon, 05 May 2025 06:00:13 -0700 (PDT)
Message-ID: <58c1c979-1dd7-4ed3-8eb6-2c7f7046fcf0@citrix.com>
Date: Mon, 5 May 2025 14:00:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Use __auto_type
To: Nicola Vetrini 
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Roberto Bagnara ,
 "consulting @ bugseng . com" 
References: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
 <707b9f833fd4cd0341ad09cbc3265ec9@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: <707b9f833fd4cd0341ad09cbc3265ec9@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 05/05/2025 1:57 pm, Nicola Vetrini wrote:
> On 2025-05-05 14:46, Andrew Cooper wrote:
>> In macros it is common to declare local variables using typeof(param)
>> in order
>> to ensure that side effects are only evaluated once.  A consequence
>> of this is
>> double textural expansion of the parameter, which can get out of hand
>> very
>> quickly with nested macros.
>>
>> A GCC extension, __auto_type, is now avaialble in the new toolchain
>> baseline
>> and avoids the double textural expansion.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Anthony PERARD 
>> CC: Michal Orzel 
>> CC: Jan Beulich 
>> CC: Julien Grall 
>> CC: Roger Pau Monné 
>> CC: Stefano Stabellini 
>> CC: Roberto Bagnara 
>> CC: Nicola Vetrini 
>> CC: consulting@bugseng.com 
>>
>> The resulting build is identical.
>>
>> RFC.  This requires a MISRA change, as it currently manifests as a R1.1
>> violation.  Nevertheless, I think we want to start using in places
>> where we
>> currently use typeof(expression of ).
>>
>> Eclair run on this patch (expecting a failure):
>>  
>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1800631949
>>
>
> Hi,
>
> to make the analysis pass you need a couple of hunks in
> eclair_analysis/ECLAIR/toolchain.ecl:
>
> -name_selector+={auto_type, "^__auto_type$"}
>
> and add auto_type to the STD.tokenext config below around line 25,
> then later
>
> -name_selector+={ext_auto_type, "^ext_auto_type$"}
>
> and add "ext_auto_type" to the -config lines below
>
> around line 125, along with a reference to the gcc docs above the
> configurations and in C-language-toolchain.rst
>
> This is an extension, so it's usable without further MISRA impact.

Excellent, thankyou.

I'll leave this email out for discussion, and if it goes in a positive
direction, I'll submit a v2 with (hopefully) all the MISRA/Eclair
changes required.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 05 13:20:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 13:20:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976135.1363361 (Exim 4.92)
	(envelope-from )
	id 1uBvjf-0001ww-Er; Mon, 05 May 2025 13:19:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976135.1363361; Mon, 05 May 2025 13:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uBvjf-0001wp-Bw; Mon, 05 May 2025 13:19:55 +0000
Received: by outflank-mailman (input) for mailman id 976135;
 Mon, 05 May 2025 13:19:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBvjd-0001wj-Rv
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 13:19:53 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a042650a-29b3-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 15:19:51 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5f5bef591d6so8839825a12.1
 for ; Mon, 05 May 2025 06:19:51 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5fa77bf3f01sm5420515a12.70.2025.05.05.06.19.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 05 May 2025 06:19: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" 
X-Inumbo-ID: a042650a-29b3-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746451191; x=1747055991; darn=lists.xenproject.org;
        h=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;
        bh=bwfPy/WlxFS+xjL+sGzQ9+jQ9+Cj3IlH5XVfxD04LC0=;
        b=Yypa+MPtSU8jxe1k2nYPhI6Ol1BuLD57au2zCv/veZhW9LkmIuFQFcaGk4BZ1F8JHK
         HDln+k+In4Z6OE2eLb9rfcXoOJXjSYgs+kNWbOJinbg6YdBUoFVYd6qg+WqkaDwDYHtT
         W8+GtckswLGgN8LpKGTIEL4EeVfN3fRz4+vSFXTtUpF6cGb3wUoo7SwXBzqXwDQ6SfHH
         LTCQcx8sTa5Y2yqlRb7NqaPuCJ3JW7OyrGbVN3RZLvKrtVyNY2St1J8THIFFob9nuL13
         ficSnBEkw+IudpY9VwsQByh2ZjPMOrkg924JMKV0Si5bRjwt7kEkD9T4j+Z/tHtkdqpg
         ImZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746451191; x=1747055991;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=bwfPy/WlxFS+xjL+sGzQ9+jQ9+Cj3IlH5XVfxD04LC0=;
        b=jTeLLjcbd1+UHDiFC9kcfmklKzq5eCvOeUPY3ZpuqVT1R1rC1SmlXRedXosq+f7CpF
         J7vDmfDvdQ6dlHVGxyheIoC2y3jXynPHPtPUOL4s+NoKdtvia/zTSd78yvEypagI3Kns
         +r+Pb5QZ4q8jkQUuhw7/F1mtrD80XecLsikgqzpkR73Cqhq9XCw/cIg1jh40zX53f+yt
         A1PjHBkL0FtsPXU8KcQCTFByrwDh7qIp5Nk52VQXEW5Bg10yDD374xGWRCM4KA45zeXd
         a6M9DtOiIqwEl0TrTshtoHJA3MzHy/XvTzPZWQKmWCYZQ4Yy5sP5BOQmqisHAyxqaGM4
         t6yw==
X-Gm-Message-State: AOJu0YwL8fZp+qCbv78Oib8DugauGh7dycl0lclSTQc2AxPhWUwRne/H
	AzFSEv4H5z17fi3HKAT41UPS1R9kg8t5quYIlqqfDMJGRCi1X22T
X-Gm-Gg: ASbGncv1hw+K9+WXEQOub5hbSJIJGzk1+97AjL7HZGHLarVHLpMthR5VLUMyT0Je65y
	+RwRw8FivHXujCvFZ4oQtPoBGEHGknB9/wKhxxclM4NbCZI9/e7nUhHYe08NaRQZsbz+2bPlID7
	KNCs/1yr7rtDweErISf+rtN/zoMxfZHRWxSuN4iTI/DEKQF9WrbR8ha64iqrbSoJRKmgvawIFxy
	Px9ANXdE0U5OwJvnAXRbafBDQMBING04Y7qt4l3qVj9rbOwyJSgV0p4QU8uWXDxbqowG0jCaio2
	f7k1Z1TRSLvxroba++YRyqZitKfm4YAilYcI+//eD8NLPO1ItKLdr9CdJpnmpSQ9M85sX7o+Yg4
	O7we+JuQ+dEeF9fVG
X-Google-Smtp-Source: AGHT+IEkdEUtyrP6ECgxH924iiZzuUnmlKQwrMGJTEXjmJ7r/86x1Rqopg0y8rkjjX5VKYMbWNr+0w==
X-Received: by 2002:a05:6402:2811:b0:5ed:c09c:10f with SMTP id 4fb4d7f45d1cf-5fa7805567dmr9365247a12.15.1746451191110;
        Mon, 05 May 2025 06:19:51 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------oy0RkXrUhnNWVpH2vi0dh6Sn"
Message-ID: 
Date: Mon, 5 May 2025 15:19:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/8] xen/common: dom0less: make some parts of Arm's
 CONFIG_DOM0LESS common
To: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org, Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 <82f0c1d4fe25b4a52d76f3c8004e107b183af56c.1746199009.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------oy0RkXrUhnNWVpH2vi0dh6Sn
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/2/25 7:55 PM, Stefano Stabellini wrote:
> On Fri, 2 May 2025, Oleksii Kurochko wrote:
>> Move some parts of Arm's Dom0Less code to be reused by other architectures.
>> At the moment, RISC-V is going to reuse these parts.
>>
>> Move dom0less-build.h from the Arm-specific directory to asm-generic
>> as these header is expected to be the same across acrhictectures with
>> some updates: add the following declaration of construct_domU(),
>> and arch_create_domUs() as there are some parts which are still
>> architecture-specific.
>>
>> Introduce HAS_DOM0LESS to provide ability to enable generic Dom0less
>> code for an architecture.
>>
>> Relocate the CONFIG_DOM0LESS configuration to the common with adding
>> "depends on HAS_DOM0LESS" to not break builds for architectures which
>> don't support CONFIG_DOM0LESS config, especically it would be useful
>> to not provide stubs for  construct_domU(), arch_create_domUs()
>> in case of *-randconfig which may set CONFIG_DOM0LESS=y.
>>
>> Move is_dom0less_mode() function to the common code, as it depends on
>> boot modules that are already part of the common code.
>>
>> Move create_domUs() function to the common code with some updates:
>> - Add arch_create_domUs() to cover parsing of arch-specific features,
>>    for example, SVE (Scalar Vector Extension ) exists only in Arm.
>>
>> Signed-off-by: Oleksii Kurochko
>> ---
>> It was suggested to change dom0less to predefined domus or similar
>> (https://lore.kernel.org/xen-devel/cd2a3644-c9c6-4e77-9491-2988703906c0@gmail.com/T/#m1d5e81e5f1faca98a3c51efe4f35af25010edbf0):
>>
>> I decided to go with dom0less name for now as it will require a lot of places to change,
>> including CI's test, and IMO we could do in a separate patch.
>> If it is necessry to do now, I'll be happy to do that in next version of the current
>> patch series.
> I think it is fine to use dom0less for now, it will make the code easier
> to review and it is not necessary to change the name at this point.
>
> The patch looks good to me, except for a couple of minor suggestions I
> have below. I could make them on commit. With those:
>
> Reviewed-by: Stefano Stabellini

During the randconfig testing the following issue occurs:
   
common/device-tree/dom0less-build.c: In function 'create_domUs':
common/device-tree/dom0less-build.c:156:42: error: implicit declaration of function 'gnttab_dom0_frames'; did you mean 'gnttab_map_frame'? [-Werror=implicit-function-declaration]
   156 |                 d_cfg.max_grant_frames = gnttab_dom0_frames();
       |                                          ^~~~~~~~~~~~~~~~~~
       |                                          gnttab_map_frame
common/device-tree/dom0less-build.c:156:42: error: nested extern declaration of 'gnttab_dom0_frames' [-Werror=nested-externs]

I fixed that by the following #ifdef-ing:
...
         d_cfg.max_grant_frames = -1;
...

         if ( dt_property_read_u32(node, "capabilities", &val) )
         {
...

#ifdef CONFIG_GRANT_TABLE
                 d_cfg.max_grant_frames = gnttab_dom0_frames();
#endif
                 d_cfg.max_evtchn_port = -1;
                 flags |= CDF_hardware;
                 iommu = true;
             }

Do you agree with such fix?

If the CONFIG_GRANT_TABLE=n then the init value (d_cfg.max_grant_frames = -1;) will be used.

~ Oleksii

--------------oy0RkXrUhnNWVpH2vi0dh6Sn
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 5/2/25 7:55 PM, Stefano Stabellini
      wrote:

    

    

      
On Fri, 2 May 2025, Oleksii Kurochko wrote:

Move some parts of Arm's Dom0Less code to be reused by other architectures.
At the moment, RISC-V is going to reuse these parts.

Move dom0less-build.h from the Arm-specific directory to asm-generic
as these header is expected to be the same across acrhictectures with
some updates: add the following declaration of construct_domU(),
and arch_create_domUs() as there are some parts which are still
architecture-specific.

Introduce HAS_DOM0LESS to provide ability to enable generic Dom0less
code for an architecture.

Relocate the CONFIG_DOM0LESS configuration to the common with adding
"depends on HAS_DOM0LESS" to not break builds for architectures which
don't support CONFIG_DOM0LESS config, especically it would be useful
to not provide stubs for  construct_domU(), arch_create_domUs()
in case of *-randconfig which may set CONFIG_DOM0LESS=y.

Move is_dom0less_mode() function to the common code, as it depends on
boot modules that are already part of the common code.

Move create_domUs() function to the common code with some updates:
- Add arch_create_domUs() to cover parsing of arch-specific features,
  for example, SVE (Scalar Vector Extension ) exists only in Arm.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
It was suggested to change dom0less to predefined domus or similar
(https://lore.kernel.org/xen-devel/cd2a3644-c9c6-4e77-9491-2988703906c0@gmail.com/T/#m1d5e81e5f1faca98a3c51efe4f35af25010edbf0):

I decided to go with dom0less name for now as it will require a lot of places to change,
including CI's test, and IMO we could do in a separate patch.
If it is necessry to do now, I'll be happy to do that in next version of the current
patch series.

I think it is fine to use dom0less for now, it will make the code easier
to review and it is not necessary to change the name at this point.

The patch looks good to me, except for a couple of minor suggestions I
have below. I could make them on commit. With those:

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

    

    
During the randconfig testing the following issue occurs:
  
common/device-tree/dom0less-build.c: In function 'create_domUs':
common/device-tree/dom0less-build.c:156:42: error: implicit declaration of function 'gnttab_dom0_frames'; did you mean 'gnttab_map_frame'? [-Werror=implicit-function-declaration]
  156 |                 d_cfg.max_grant_frames = gnttab_dom0_frames();
      |                                          ^~~~~~~~~~~~~~~~~~
      |                                          gnttab_map_frame
common/device-tree/dom0less-build.c:156:42: error: nested extern declaration of 'gnttab_dom0_frames' [-Werror=nested-externs]

I fixed that by the following #ifdef-ing:
...
        d_cfg.max_grant_frames = -1;
...

        if ( dt_property_read_u32(node, "capabilities", &val) )
        {
...

#ifdef CONFIG_GRANT_TABLE
                d_cfg.max_grant_frames = gnttab_dom0_frames();
#endif
                d_cfg.max_evtchn_port = -1;
                flags |= CDF_hardware;
                iommu = true;
            }

Do you agree with such fix?

If the CONFIG_GRANT_TABLE=n then the init value (d_cfg.max_grant_frames = -1;) will be used.

~ Oleksii


  


--------------oy0RkXrUhnNWVpH2vi0dh6Sn--


From xen-devel-bounces@lists.xenproject.org Mon May 05 14:21:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 14:21:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976149.1363370 (Exim 4.92)
	(envelope-from )
	id 1uBwgX-0002S3-Ly; Mon, 05 May 2025 14:20:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976149.1363370; Mon, 05 May 2025 14:20: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 1uBwgX-0002Rw-JQ; Mon, 05 May 2025 14:20:45 +0000
Received: by outflank-mailman (input) for mailman id 976149;
 Mon, 05 May 2025 14:20:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBwgW-0002Rp-Fy
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 14:20:44 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 203b4fa6-29bc-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 16:20:42 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ac2902f7c2aso713001666b.1
 for ; Mon, 05 May 2025 07:20:42 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad18950964asm503786966b.141.2025.05.05.07.20.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 07: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" 
X-Inumbo-ID: 203b4fa6-29bc-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746454841; x=1747059641; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Zm8qqxJidIZwUnpMvKpQaP58jct5MPcPPi8zdUSg0es=;
        b=Xbqpv9MWvpEPAucdURm6F2fK5rirI9H7pl0pPrbMy7kpPWR5KwttAH/+OA5xNRx6r+
         95c40v/znUnh+LvMqP2u4uwX1p5zDeFNUqnhcdXL3zFe8xxbn84PdgwX5l2OYAEdmUZp
         Bgi4m9DzTAVOG07cxVcA9LMMI6yMpTN1ZBb2s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746454841; x=1747059641;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Zm8qqxJidIZwUnpMvKpQaP58jct5MPcPPi8zdUSg0es=;
        b=k5MacOsShZjpHaJzQ5xMshxOQl2oENYGT4SaRanrRIB/vxcLHWuUc59DlRMSlZvfcg
         br0LW4e6DjUoNNIFmW2ngXXJTtKafNsC1Cq8sPd6TCzsk4YzGcERNBsWXawDLlDEhhyt
         CFjUosyfBD059yHVN/G7llQ4wuVt8Z8ZVCR/5Hlq5wAeOZyLB9T+0Vc7zf26P9hkM66x
         lXDsrs3GG5nuclinDe3y7DAxc4/NAn8QeUQyKrUW9DQEuomY4JNUqCFQ4fc2vN5U5anK
         iaOIn2aNJzCmcOe2si9l/wiBN37BruO+Tk6DWYNMsd+GMgfQU+PNeg1h/ibKskB9E674
         HmDg==
X-Forwarded-Encrypted: i=1; AJvYcCWZHUDOFCLdZZkCUEwLd8CbfObzLhy1Pk/HCiPfbiiisL9xvRSlS9Fc9Qfe41e3ZK5GK7qXzqsx1M4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwXOjFv2X55CUAf/L5K3xrWmXFEf2ylIUoMIieUNdRq4zF9GgNr
	q2MsgPpk7Bv8kMcx2de1Ng8Yl5FC2WL22eS89xjTGiDKUNDc29XyES3XqzISqDlVt01St7Zqflc
	c
X-Gm-Gg: ASbGncvi/WilhcGjtxqAiYiEdZYbRLfzjxq6IJOJHUyaqerYS3aPg6FDS/PZup4RawO
	ZgdYVV1NCw+dCt+T6FMl8/TM/85ZKAw9B4DFsQ3lFZhVJ1mSJI5fDzYJzbchleA0Bw6jVDqv82M
	0l3DciMVZ/Eh/k0JgGizPpzvLvqE51lYHmz1h98s1SUkt11D9mRw89suWdc8C3c72/ykf20RBb1
	nDoQhfGYUiHntKT1GzbxWgpApMxgC0Pdsr97RMAjXaE24r4SHZepNTVYEhjc5Ep3sUtKcyaUF2y
	8Gj8QKNEah4ohibrfCBlINGI9rTB8c9cIRxV/RuGuBQnXA==
X-Google-Smtp-Source: AGHT+IGKpv6NtcWRfb9+WLroopHpq71353XI9aofjNIk/4qffqQN+DPb/AvtYcd8QpPLgUaTqatH+Q==
X-Received: by 2002:a17:907:720b:b0:ace:3a24:97d with SMTP id a640c23a62f3a-ad1a48be280mr726975366b.4.1746454841476;
        Mon, 05 May 2025 07:20:41 -0700 (PDT)
Date: Mon, 5 May 2025 16:20:40 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Demi Marie Obenour 
Cc: Andrew Cooper ,
	Xen developer discussion ,
	Juergen Gross 
Subject: Re: Mapping memory into a domain
Message-ID: 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Sun, May 04, 2025 at 07:24:46PM -0400, Demi Marie Obenour wrote:
> On 5/4/25 6:56 PM, Andrew Cooper wrote:
> > On 04/05/2025 11:51 pm, Demi Marie Obenour wrote:
> >> What are the appropriate Xen internal functions for:
> >>
> >> 1. Turning a PFN into an MFN?
> >> 2. Mapping an MFN into a guest?
> >> 3. Unmapping that MFN from a guest?
> >>
> >> The first patch I am going to send with this information is a documentation
> >> patch so that others do not need to figure this out for themselves.
> >> I remember being unsure even after looking through the source code, which
> >> is why I am asking here.
> > 
> > See the top of xen/include/xen/mm.h which has an overview of
> > terminology, including an explanation of why Xen doesn't know what the
> > guest thinks of as PFN.
> I read that and am still confused.  Are you specifically referring to PV
> guests?  For PVH and HVM guests, Xen needs to know what the guest’s PFNs
> are so that it can correctly set up its own page tables.

The term PFN on PVH and HVM is confusing, and IMO it shouldn't be used
in that context.  PFNs should only be used in PV domains context.

I'm afraid I cannot understand the question in your last sentence.
What's "its own page tables"?  Are you referring to the domain second
stage translation page-tables, iow: the p2m?  Or is it something
else?

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 05 14:31:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 14:31:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976162.1363381 (Exim 4.92)
	(envelope-from )
	id 1uBwqX-0004AL-Ie; Mon, 05 May 2025 14:31:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976162.1363381; Mon, 05 May 2025 14:31:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uBwqX-0004AE-Fl; Mon, 05 May 2025 14:31:05 +0000
Received: by outflank-mailman (input) for mailman id 976162;
 Mon, 05 May 2025 14:31:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBwqW-0004A8-1r
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 14:31:04 +0000
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com
 [2607:f8b0:4864:20::432])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91e9432e-29bd-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 16:31:03 +0200 (CEST)
Received: by mail-pf1-x432.google.com with SMTP id
 d2e1a72fcca58-7398d65476eso3556958b3a.1
 for ; Mon, 05 May 2025 07:31:03 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-7405902144fsm7008388b3a.100.2025.05.05.07.30.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 07:31: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" 
X-Inumbo-ID: 91e9432e-29bd-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746455461; x=1747060261; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=eMZ3ZgtWdz2WrPotARKXu8189+8YqmclI8t9PsACamo=;
        b=FZpKPeUj/EYRSZPAOk02Ip4iNiTq1O1CLZZYOhiby1EY2sSNORhQmQNvVlnZ0QvvVL
         pFIlN3lQMfF9XRgfrnR86QW1ivt8//WQSMBdrqm8XaSyu00vBo3n24Jhjn/AiW/Nt/1V
         O16G/UWmPRD/KIank/68Sw6DGfXM5tLRLgw0k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746455461; x=1747060261;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=eMZ3ZgtWdz2WrPotARKXu8189+8YqmclI8t9PsACamo=;
        b=YWkkunXBuvGRArgFB9cvUvSDZbNomu7O3A+gMVU1RFG8Qfvo9cfgHzw4hrgKGkoH4P
         mZmIKsgwT6h4O2+DvMfMwP5I1DcHoG/QmlOomNS9fx58tTPCXchWfDSemH+v2Cf7VguD
         Glmk7uoBdJ1cNvTBitR5IXI2FXGFD0wBam5RMvmXX6EQ/6hRghLnp7NRllXG1Cm2dYvk
         XNJL/knvRdihpKMDN2WwaW/RBKIsq0amk1+a+n4RHMJszCU3EQGduIbrXLPKtQRtyDrQ
         WF3PTQmBuQa4WDR4NP27Ppv6zSO4UhIJHd1+FO8WkvEv6Npd5VTrKgl3XgqpoAWZH8kj
         s96g==
X-Forwarded-Encrypted: i=1; AJvYcCW7wsH4FiAWczO0WDwVUCY1UdTPdgGVnpYImVKrw+IWp5DqOiYXb0CS+zC3Cp1YuwjRuIlcbUvZA6g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzE11h9olTtta58OI2jtnxVbhqYIUsCeErdmbssyBCXr4onAs98
	6bLLJC/0LazsVHgUk73VNNNXHsMcombclioFq8LD8GT73VL32DsW9PK7W0h7C2c=
X-Gm-Gg: ASbGncvKnzRIn2VYKis8DRrXQsMWbOnIK1su3ondRNSh6QqlyhUmQ42lLjGDF928AlG
	sAGs8YciFuj+PcEePh8EV6YOhENMxWQWImiYUFkFOliipM+wWhj5ujbSVFqsoerWlgI1vDvnYdu
	8Zo5PDAUFaJeyqxXcuQhdL71kFMeKCt+igqJ+5harad3wKtXDNBTQvXA9q7eshjSibyCumLWA5j
	pftgBe8gjb/TS/UVIETfpQSMDuhd63Eb5U9kKaPNe9u4w6cMoL8f3gi5ZMU5HVT+aAXQsxLZZxJ
	Qep1oWtG0/Nih2/YbjGCRX3Z99aIams1RbcD0wylqUrDYg==
X-Google-Smtp-Source: AGHT+IGIDRUgZ+dWKY2YUeYkt0lw9lZQGeJK+U9vLSa7M/qWQUNvqcBiyb6BRudVp6jslHjoB6lpmg==
X-Received: by 2002:a05:6a00:2e9d:b0:734:26c6:26d3 with SMTP id d2e1a72fcca58-74049198213mr29870873b3a.5.1746455461503;
        Mon, 05 May 2025 07:31:01 -0700 (PDT)
Date: Mon, 5 May 2025 16:30:56 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
Cc: Stefano Stabellini ,
	Jan Beulich ,
	"Ragiadakou, Xenia" ,
	Andrew Cooper , jason.andryuk@amd.com,
	agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
Message-ID: 
References: 
 <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@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, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
> > On Mon, 28 Apr 2025, Jan Beulich wrote:
> > > On 25.04.2025 22:19, Stefano Stabellini wrote:
> > > > From: Xenia Ragiadakou 
> > > > 
> > > > Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> > > > addresses to firmware or co-processors not behind an IOMMU.
> > > 
> > > I definitely don't understand the firmware part: It's subject to the
> > > same transparent P2M translations as the rest of the VM; it's just
> > > another piece of software running there.
> > > 
> > > "Co-processors not behind an IOMMU" is also interesting; a more
> > > concrete scenario might be nice, yet I realize you may be limited in
> > > what you're allowed to say.
> > 
> > Sure. On AMD x86 platforms there is a co-processor called PSP running
> > TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionally to
> > pass addresses to it.  See drivers/tee/amdtee/ and
> > include/linux/psp-tee.h in Linux.
> 
> We had (have?) similar issue with amdgpu (for integrated graphics) - it
> uses PSP for loading its firmware. With PV dom0 there is a workaround as
> dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, but I
> expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's
> the one I used for debugging this issue).

That's ugly, and problematic when used in conjunction with AMD-SEV.

I wonder if Xen could emulate/mediate some parts of the PSP for dom0
to use, while allowing Xen to be the sole owner of the device.  Having
both Xen and dom0 use it (for different purposes) seems like asking
for trouble.  But I also have no idea how complex the PSP interface
is, neither whether it would be feasible to emulate the
interfaces/registers needed for firmware loading.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 05 17:20:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 17:20:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976180.1363391 (Exim 4.92)
	(envelope-from )
	id 1uBzTv-0006UB-T6; Mon, 05 May 2025 17:19:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976180.1363391; Mon, 05 May 2025 17:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uBzTv-0006U4-QA; Mon, 05 May 2025 17:19:55 +0000
Received: by outflank-mailman (input) for mailman id 976180;
 Mon, 05 May 2025 17:19:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBzTu-0006Ty-IF
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 17:19:54 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 26dda250-29d5-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 19:19:51 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 6B76E5C4624;
 Mon,  5 May 2025 17:17:32 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA192C4CEE4;
 Mon,  5 May 2025 17:19: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" 
X-Inumbo-ID: 26dda250-29d5-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746465589;
	bh=tKyAZaSY4McK3YCahgeUO7ZbO9yDo3+bLojf3JFda50=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=vMarw99m2Omwn8crTX3hmU1e63RRKqee5hNXLgprEh8wAdP5bm6VHyOSFH7k0jad7
	 3UkJV+BBSeDb19hBfpUE3zvSLSnwW5ziUYzXo4/Gi58H5jmF/wdUxTyXKrS/4ZIRcS
	 lrFaOcuQBAISPVP/Gg4sQUsC7WvmHActL918UtuV1pdZv9YQADFNYclXM7tEaNO2Jq
	 tY4ZR+3nZVTOeKT7bsDEcI7xv2TJsmhp1ZCoZedD+Y73anvR3zg6CpCb7hNuukUp00
	 zebecKLY3NE4zJXErJFzt+XQEgKJQ7Nhta0WQQyvYZxvCcdFpnw8x7t49x82pt9Wxt
	 U4R/kaSpFNnkw==
Date: Mon, 5 May 2025 10:19:46 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Kurochko 
cc: Stefano Stabellini , 
    xen-devel@lists.xenproject.org, Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v3 2/8] xen/common: dom0less: make some parts of Arm's
 CONFIG_DOM0LESS common
In-Reply-To: 
Message-ID: 
References:  <82f0c1d4fe25b4a52d76f3c8004e107b183af56c.1746199009.git.oleksii.kurochko@gmail.com> 
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 5 May 2025, Oleksii Kurochko wrote:
> On 5/2/25 7:55 PM, Stefano Stabellini wrote:
> 
> On Fri, 2 May 2025, Oleksii Kurochko wrote:
> Move some parts of Arm's Dom0Less code to be reused by other architectures.
> At the moment, RISC-V is going to reuse these parts.
> 
> Move dom0less-build.h from the Arm-specific directory to asm-generic
> as these header is expected to be the same across acrhictectures with
> some updates: add the following declaration of construct_domU(),
> and arch_create_domUs() as there are some parts which are still
> architecture-specific.
> 
> Introduce HAS_DOM0LESS to provide ability to enable generic Dom0less
> code for an architecture.
> 
> Relocate the CONFIG_DOM0LESS configuration to the common with adding
> "depends on HAS_DOM0LESS" to not break builds for architectures which
> don't support CONFIG_DOM0LESS config, especically it would be useful
> to not provide stubs for  construct_domU(), arch_create_domUs()
> in case of *-randconfig which may set CONFIG_DOM0LESS=y.
> 
> Move is_dom0less_mode() function to the common code, as it depends on
> boot modules that are already part of the common code.
> 
> Move create_domUs() function to the common code with some updates:
> - Add arch_create_domUs() to cover parsing of arch-specific features,
>   for example, SVE (Scalar Vector Extension ) exists only in Arm.
> 
> Signed-off-by: Oleksii Kurochko 
> ---
> It was suggested to change dom0less to predefined domus or similar
> (https://lore.kernel.org/xen-devel/cd2a3644-c9c6-4e77-9491-2988703906c0@gmail.com/T/#m1d5e81e5f1faca98a3c51efe4f35af25010edbf0):
> 
> I decided to go with dom0less name for now as it will require a lot of places to change,
> including CI's test, and IMO we could do in a separate patch.
> If it is necessry to do now, I'll be happy to do that in next version of the current
> patch series.
> I think it is fine to use dom0less for now, it will make the code easier
> to review and it is not necessary to change the name at this point.
> 
> The patch looks good to me, except for a couple of minor suggestions I
> have below. I could make them on commit. With those:
> 
> Reviewed-by: Stefano Stabellini 
> 
> During the randconfig testing the following issue occurs:
>   
> common/device-tree/dom0less-build.c: In function 'create_domUs':
> common/device-tree/dom0less-build.c:156:42: error: implicit declaration of function 'gnttab_dom0_frames'; did you mean 'gnttab_map_frame'? 
> [-Werror=implicit-function-declaration]
>   156 |                 d_cfg.max_grant_frames = gnttab_dom0_frames();
>       |                                          ^~~~~~~~~~~~~~~~~~
>       |                                          gnttab_map_frame
> common/device-tree/dom0less-build.c:156:42: error: nested extern declaration of 'gnttab_dom0_frames' [-Werror=nested-externs]
> 
> I fixed that by the following #ifdef-ing:
> ...
>         d_cfg.max_grant_frames = -1;
> ...
> 
>         if ( dt_property_read_u32(node, "capabilities", &val) )
>         {
> ...
> 
> #ifdef CONFIG_GRANT_TABLE
>                 d_cfg.max_grant_frames = gnttab_dom0_frames();
> #endif
>                 d_cfg.max_evtchn_port = -1;
>                 flags |= CDF_hardware;
>                 iommu = true;
>             }
> 
> Do you agree with such fix?
> 
> If the CONFIG_GRANT_TABLE=n then the init value (d_cfg.max_grant_frames = -1;) will be used.

Yes, OK


From xen-devel-bounces@lists.xenproject.org Mon May 05 17:35:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 17:35:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976195.1363401 (Exim 4.92)
	(envelope-from )
	id 1uBzjI-0000sz-87; Mon, 05 May 2025 17:35:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976195.1363401; Mon, 05 May 2025 17:35: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 1uBzjI-0000ss-4i; Mon, 05 May 2025 17:35:48 +0000
Received: by outflank-mailman (input) for mailman id 976195;
 Mon, 05 May 2025 17:35:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uBzjG-0000sm-SS
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 17:35:46 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5f28ded2-29d7-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 19:35:44 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id EBEA8A4C5AB;
 Mon,  5 May 2025 17:30:15 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id F11D3C4CEE4;
 Mon,  5 May 2025 17:35: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" 
X-Inumbo-ID: 5f28ded2-29d7-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746466543;
	bh=w57YziwY5ywU3p0r/3ZcUL0HAETzSk5/VSiQUFBwBIM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=IbcFOjVVXzKHbdSCgJ/ESLUeyKuR093yUX+bXJjgj+4DYW4NX34OfIp8GCWzo6fYx
	 b6oKl6KXNWX4KRYXdDR3EFKuNw9s1amlbwUMPv+2btTvWBWMFBEklI/WYZ2l8NJAyf
	 6E4ySEJhEPgqvkZyw6+KZ+yoDHadNOW5TElcFppujgTSb/kGF7v1oWAKq+dtaX04Va
	 JAnM/teHjkjNWochAJElEs0XJNdeUFEuVw4sz20bubboYD0r+kmmUcO3IuR8lRstNb
	 rqxZ/XfqMn7Icy8sWfI3lXbcQRNIopLKJrkB27moqOWkZHeXFIb0gOIYiDBT4DB6l6
	 L9K39SSR+B79A==
Date: Mon, 5 May 2025 10:35:39 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Kurochko 
cc: Stefano Stabellini , 
    xen-devel@lists.xenproject.org, Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v3 8/8] xen/common: dom0less: introduce common
 dom0less-build.c
In-Reply-To: <5523bf0d-a94e-444d-a1fa-035ecccb4448@gmail.com>
Message-ID: 
References:  <76390ef52f108b580e1c397ed178ceadf1ae53c4.1746199009.git.oleksii.kurochko@gmail.com> 
 <5523bf0d-a94e-444d-a1fa-035ecccb4448@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Hi Oleksii,

FYI I know you might not be able to disable HTML in your email client
replies, but just as a heads up, my email client doesn't support HTML at
all so my replies will have your text and my older text mixed up.


On Mon, 5 May 2025, Oleksii Kurochko wrote:
> On 5/2/25 10:53 PM, Stefano Stabellini wrote:
> 
> On Fri, 2 May 2025, Oleksii Kurochko wrote:
> 
> Part of Arm's dom0less-build.c could be common between architectures which are
> using device tree files to create guest domains. Thereby move some parts of
> Arm's dom0less-build.c to common code with minor changes.
> 
> As a part of theses changes the following changes are introduced:
> - Introduce make_arch_nodes() to cover arch-specific nodes. For example, in
>   case of Arm, it is PSCI and vpl011 nodes.
> - Introduce set_domain_type() to abstract a way how setting of domain type
>   happens. For example, RISC-V won't have this member of arch_domain structure
>   as vCPUs will always have the same bitness as hypervisor. In case of Arm, it
>   is possible that Arm64 could create 32-bit and 64-bit domains.
> - Introduce init_vuart() to cover details of virtual uart initialization.
> - Introduce init_intc_phandle() to cover some details of interrupt controller
>   phandle initialization. As an example, RISC-V could have different name for
>   interrupt controller node ( APLIC, PLIC, IMSIC, etc ) but the code in
>   domain_handle_dtb_bootmodule() could handle only one interrupt controller
>   node name.
> - s/make_gic_domU_node/make_intc_domU_node as GIC is Arm specific naming and
>   add prototype of make_intc_domU_node() to dom0less-build.h
> 
> The following functions are moved to xen/common/device-tree:
> - Functions which are moved as is:
>   - domain_p2m_pages().
>   - handle_passthrough_prop().
>   - handle_prop_pfdt().
>   - scan_pfdt_node().
>   - check_partial_fdt().
> - Functions which are moved with some minor changes:
>   - alloc_xenstore_evtchn():
>     - ifdef-ing by CONFIG_HVM accesses to hvm.params.
>   - prepare_dtb_domU():
>     - ifdef-ing access to gnttab_{start,size} by CONFIG_GRANT_TABLE.
>     - s/make_gic_domU_node/make_intc_domU_node.
>     - Add call of make_arch_nodes().
> - domain_handle_dtb_bootmodule():
>   - hide details of interrupt controller phandle initialization by calling
>     init_intc_phandle().
>   - Update the comment above init_intc_phandle(): s/gic/interrupt controller.
> - construct_domU():
>   - ifdef-ing by CONFIG_HVM accesses to hvm.params.
>   - Call init_vuart() to hide Arm's vpl011_init() details there.
>   - Add call of set_domain_type() instead of setting kinfo->arch.type explicitly.
> 
> Some parts of dom0less-build.c are wraped by #ifdef CONFIG_STATIC_{SHMEM,MEMORY}
> as not all archs support these configs.
> 
> Signed-off-by: Oleksii Kurochko 

[...]


> +    ret = make_memory_node(kinfo, addrcells, sizecells,
> +                           kernel_info_get_mem(kinfo));
> +    if ( ret )
> +        goto err;
> +
> +#ifdef CONFIG_STATIC_SHM
> 
> This should not be necessary because there is a stub implementation of
> make_resv_memory_node available in static-shmem.h for the
> !CONFIG_STATIC_SHM case.
> 
> But static-shmem.h isn't available on all architectures. Until static-shmem.h isn't moved to
> asm-generic or xen folders and then re-used by an architecture we have to have #ifdef.
 
OK let's keep it as is so that we don't need to move static-shmem.h

 
> +    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
> +    if ( ret )
> +        goto err;
> +#endif

[...]


> +    if ( !dt_find_property(node, "xen,static-mem", NULL) )
> +        allocate_memory(d, &kinfo);
> +#ifdef CONFIG_STATIC_MEMORY
> 
> Also this should not be needed thanks to the stub implementation of
> allocate_static_memory and assign_static_memory_11
> 
> 
> +    else if ( !is_domain_direct_mapped(d) )
> +        allocate_static_memory(d, &kinfo, node);
> +    else
> +        assign_static_memory_11(d, &kinfo, node);
> +#endif
> +
> +#ifdef CONFIG_STATIC_SHM
> 
> There is a stub for process_shm too
> 
> The same as with make_resv_memory_node(), static-shmem.h header isn't available for
> all archs.
> I can return my patches which move static-shmem.h to asm-generic and then drop all the ifdef-s connect to it:
> https://lore.kernel.org/xen-devel/0203b98aa6a42aa69e22e7c973320add3ff4bb5d.1736334615.git.oleksii.kurochko@gmail.com/
> https://lore.kernel.org/xen-devel/0203b98aa6a42aa69e22e7c973320add3ff4bb5d.1736334615.git.oleksii.kurochko@gmail.com/
> 
> Let me know if it is better to do now or should it be better to drop #ifdef-ing when an architrecture will require
> static-shmem or static-mem features?

I see Jan's point that they are advanced features probably not needed
initially. So maybe it is better to start with something simpler. I
think it is OK to keep the patch as is.


From xen-devel-bounces@lists.xenproject.org Mon May 05 18:10:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 18:10:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976207.1363421 (Exim 4.92)
	(envelope-from )
	id 1uC0H8-0006Ca-TN; Mon, 05 May 2025 18:10:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976207.1363421; Mon, 05 May 2025 18:10:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uC0H8-0006CT-QC; Mon, 05 May 2025 18:10:46 +0000
Received: by outflank-mailman (input) for mailman id 976207;
 Mon, 05 May 2025 18:10:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC0H7-0005wU-7w
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 18:10:45 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 432ccb37-29dc-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 20:10:44 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-acbb85ce788so1241648766b.3
 for ; Mon, 05 May 2025 11:10:44 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189146fcbsm530372366b.34.2025.05.05.11.10.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 11:10: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" 
X-Inumbo-ID: 432ccb37-29dc-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746468643; x=1747073443; 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;
        bh=lCXevhzoSlFnjdkbSHTRKfTx5Fl+QjfRaAJtPlYKQIc=;
        b=BiW9+FrgL5ejdZe/BexQjnMAn+bEJWAUjNPfnPqOUzoVxYH8JqMbofgP6pAvqQi2/e
         f2nX71IZ6HJbKnSoeeBzNALzlxnBKzz1zYttwS9kigM1PKkuAT0w/0bLoKTlQsw5pFsB
         Nn2L4aGZBOCSEf2AxSN4KPHG+f2YmYaL9NkTopaA8Rq8HfjES7Q1NEuPR6jgZgfq+XYE
         GMU1qBv8bYj0t1rIPESpTz2Y8v5cmm6BbjXAfGVuJ7NgS88ngqm1dDBVfNocPOv0E31h
         Z9UzyPSZ5XIAHY4L/EdW5SzpsEZzIfPGl02a06O6ruoQRIRx/FPWLkZ2KBz7y5Ya3FhX
         iqAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746468643; x=1747073443;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=lCXevhzoSlFnjdkbSHTRKfTx5Fl+QjfRaAJtPlYKQIc=;
        b=M8FL2KNf0Q9/ernpZ2j4GmsuI7aBSG2kYLYe5RkofCnXrBMD0CAdEkFC0scTAHefyZ
         12Z47/uk1Fb2g3yfoCvKNz+1idvOpGFq+v7vYC/p4bpqVbCNYWlHKEYmjkZ3iW2/Z2T8
         HyrfPbTAqEzGQzxJcJ5u6qZXJorO4cuYMi7blCq/P2mMbG9wlgnlvQac78M5jrC6DtTQ
         WBx1N8nv2D4ILDfxsZUsLOLASfPoRzTllYNDlt98EwIuXYz24BS6FLdoLoDjC6xYZDpd
         FCA64R8nTy9+CoXQgjPrZnEdZig39Vk0eLlyIOov4AP7loTh5T1QbGdX6rkzuWSZk+5u
         APbA==
X-Gm-Message-State: AOJu0YyD1ZK28nRXyZJCL+c7kzbbjXf1Z1AtI0hORTsvFHsJeI9Vm6Nx
	Oney/Eyl2A/0Z0YcQqYea1LptH1VbNPOBbVpQXviwiRPG0ysg5PcWythIg==
X-Gm-Gg: ASbGnctimwB7HEp2vNVwh7QxKbBB62f1pxEsCOdVA5r9YI11wM+kaQ6YGye4DaTQrX7
	oGCUoXkRfg4wKjqOUYDEdFPkkdnVOzVd7wH0KbfmVpTNhMg2vvQMvYwWbUDiKzpGDSqP0e/P7pJ
	irkx5fV39SudAIcMJGMpiylBQ6jGqYEZjdxVuJ/sOdIIdOdxTlSFHL7B6wUS9uDE4WUuMeImhPg
	UfVp50Wx8pvo1cO4eOWa9fiuRhlfnUMurNcxZawvAT0GtP6xu2jx6PSOTr4Gwc1gJ0+ioR3c8wS
	D262da7I4M7SexTlg0RvcwZLiW9a0XcBzOylk1N1ba7A2sBKV5KrmtNkbbO2ddaGlfe/ZD0Uv2g
	lC9K4XICErg==
X-Google-Smtp-Source: AGHT+IGYQHsuF93pm8ezQpHETFSM/heQ0yodhDd6lRDtiaumu5Y3ruCU0sgzkNcTCucg/KsFMIch9Q==
X-Received: by 2002:a17:907:d48f:b0:aca:c687:6ca2 with SMTP id a640c23a62f3a-ad1d459609fmr1472366b.26.1746468643304;
        Mon, 05 May 2025 11:10:43 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v4 4/8] arm/static-shmem.h: drop inclusion of asm/setup.h
Date: Mon,  5 May 2025 20:10:34 +0200
Message-ID: <2b126e4fde36d2a93c4a1ff6cb7266710738340a.1746468003.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Nothing is dependent from asm/setup.h in asm/static-shmem.h so inclusion of
asm/setup.h is droped.

After this drop the following compilation error related to impicit declaration
of the following functions device_tree_get_reg and map_device_irqs_to_domain,
device_tree_get_u32 occur during compilation of dom0less-build.c ( as they are
declared in asm/setup.h ).

Add inclusion of  in dt-overlay.c as it is using handle_device()
declared in .

Signed-off-by: Oleksii Kurochko 
------
Changes in V4:
 - Return back dropping of asm/setup.h inclusion in asm/static-shmem.h
   as it was lost during one of reabses.
---
Changes in V2-3:
 - Nothing changed. Only rebase.
---
 xen/arch/arm/dom0less-build.c           | 1 +
 xen/arch/arm/include/asm/static-shmem.h | 1 -
 xen/common/device-tree/dt-overlay.c     | 2 ++
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 18d55d90c6..7e9cedb0c8 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h
index a4f853805a..4034cec32f 100644
--- a/xen/arch/arm/include/asm/static-shmem.h
+++ b/xen/arch/arm/include/asm/static-shmem.h
@@ -5,7 +5,6 @@
 
 #include 
 #include 
-#include 
 
 #ifdef CONFIG_STATIC_SHM
 
diff --git a/xen/common/device-tree/dt-overlay.c b/xen/common/device-tree/dt-overlay.c
index 81107cb48d..d184186c01 100644
--- a/xen/common/device-tree/dt-overlay.c
+++ b/xen/common/device-tree/dt-overlay.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include 
+
 #define DT_OVERLAY_MAX_SIZE KB(500)
 
 static LIST_HEAD(overlay_tracker);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 05 18:10:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 18:10:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976208.1363427 (Exim 4.92)
	(envelope-from )
	id 1uC0H9-0006F5-7t; Mon, 05 May 2025 18:10:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976208.1363427; Mon, 05 May 2025 18:10: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 1uC0H9-0006EW-11; Mon, 05 May 2025 18:10:47 +0000
Received: by outflank-mailman (input) for mailman id 976208;
 Mon, 05 May 2025 18:10:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC0H7-0005wU-FB
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 18:10:45 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 429e5edc-29dc-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 20:10:43 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ac2aeada833so920439466b.0
 for ; Mon, 05 May 2025 11:10:43 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189146fcbsm530372366b.34.2025.05.05.11.10.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 11:10: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" 
X-Inumbo-ID: 429e5edc-29dc-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746468643; x=1747073443; 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;
        bh=wBa0jvpO6jhfDLOOrRGvlv4gr02CAjukBDRrpmIUqss=;
        b=nHcAO74geUVY5f+XP6AMnFOz8MTy9LTqJSKLcYzaSU17BESZnAaX5xx74aoLWcDanx
         b9JyjBZ0PRH35Oo0saHgzkAKRusQ4eXXBL8B16BtdVFb/uXu9+lFP701+QVt5qnKp+a6
         zd927Bp+b83yGJWRkMXRXlqG9KnLRfhilA/lwDTTELD8Eu0EQ23eXrbWdPYzW2h1wXVM
         KtpCL+xbKBXyxH6rtG1EmqgEwLJ6IzqiTX/b7fk9HclR0AXmxZxzjqISzuPRCUyqlPst
         RmCVsSNERJ9621lQTwj6y599S6hvMWnUsKyBNkscQbcLyjwJvuIcSBrPQG9LgVUksliE
         m0OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746468643; x=1747073443;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=wBa0jvpO6jhfDLOOrRGvlv4gr02CAjukBDRrpmIUqss=;
        b=dmcxbilkColqm6kBxNl3KjZM/2n2Q5v73nxZGrUBrVFokVb2mcQYO6Zn1c5HtOGMmy
         QzN67QIxuZCfheXKqiLMzu6cv1a+KlHQHPNIvScM4CUF38RUW4DuwRls0i4HMHbCE+H+
         jjWLVJbDSvNQ8a0w1JagLefpOJw6QhT3DFYb4dDdBz5ZY6+xbzihn8+qWKOp2v0aVjMu
         L4qWRdEJe4wFHK0fFlYhapbOi0tLRlBeT1fEko6prAnmckSjYSs1IlzV2ST+fBY/SK6W
         Yz55TVWPEyjwM3HU4jQTISKEDZm+ttAPG9h+c2QSPn4cSBqQdzydoZwPqhik9mbczvs/
         zrXg==
X-Gm-Message-State: AOJu0YyV6B4y/L+lnUiA96W8jbKNtppB/qCKmPg5ByjRMYaX9qD6RAjM
	0kmHTsxJ9oM9bNMp0678hkp43JoWTqLZP7wq1eaR4zv3ldiJV5GXPQeM/w==
X-Gm-Gg: ASbGncusCZj7SLUMLlyHW6vyTmuARAeTRB5puRK7II/RktqFrffEvxiejXAUjL5O1Cg
	FxkU4TbNwjZX0PcwoQm7EE18pZBZi2o0O5Npgt3aYxU5c4rU2gggL92whYjnwUoI9SZ0mz7nEdC
	iCs4jrX5M8agle4zFb0NaOfLcvtHN771QtKPwOhkU9tveVk8GHykJdVsYJtrNPpcc3f7WUsIVjg
	zGMtlQ/VjRKTfVuodjyp73A54nYlxxSivL9lpZjMdsck+5ezr0FzIdUCsg7npkA64+qIUktuUAk
	0lYzFMewvuay8q0OTIL6ok4LeKr1XHtrhY3CncPkuOA063TMeVGNsAOmJjLDlJLbv8jOj/k6G9A
	/QY3VrxQtMw==
X-Google-Smtp-Source: AGHT+IGy1GP7jVAkrwT4cjrAWtqJcxcgPXfyS+/XLdRm5htnSwMcg/qqELUQV2JHEVyHRsE6GULEpQ==
X-Received: by 2002:a17:906:ba8b:b0:ac1:791c:153a with SMTP id a640c23a62f3a-ad1d2f30d8cmr36499566b.27.1746468642710;
        Mon, 05 May 2025 11:10:42 -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 v4 3/8] asm-generic: move parts of Arm's asm/kernel.h to common code
Date: Mon,  5 May 2025 20:10:33 +0200
Message-ID: <578b923f4103e312f3840619bb286d3dba39300b.1746468003.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Move the following parts to common with the following changes:
- struct kernel_info:
  - Create arch_kernel_info for arch specific kernel information.
    At the moment, it contains domain_type for Arm.
  - s/phandle_gic/phandle_intc to have more generic name suitable for other
    archs.
  - Make text_offset of zimage structure available for RISCV_64.
- Wrap by `#ifdef KERNEL_INFO_SHM_MEM_INIT` definition of KERNEL_SHM_MEM_INIT
  and wrap by `#ifndef KERNEL_INFO_INIT` definition of KERNEL_INFO_INIT to have
  ability to override KERNEL_INFO_SHM_MEM_INIT for arch in case it doesn't
  want to use generic one.
- Move DOM0LESS_* macros to dom0less-build.h.
- Move all others parts of Arm's kernel.h to xen/fdt-kernel.h.

Because of the changes in struct kernel_info the correspondent parts of Arm's
code are updated.

As part of this patch the following clean up happens:
- Drop asm/setup.h from asm/kernel.h as nothing depends from it.
  Add inclusion of asm/setup.h for a code which uses device_tree_get_reg() to
  avoid compilation issues for CONFIG_STATIC_MEMORY and CONFIG_STATIC_SHM.
- Drop inclusion of asm/kernel.h everywhere except xen/fdt-kernel.h.

Signed-off-by: Oleksii Kurochko 
---
Changes in v4:
 - Update the macros KERNEL_INFO_SHM_MEM_INIT and KERNEL_INFO_INIT to include
   setting the *.type field, which was previously omitted.
 - Drop inclusion of  and use  instead in
   xen/arch/arm/kernel.c.
 - Drop Arm specific information in the comment above declaration of kernel_probe().
 - Move vpl011 to arch specific structure, instead of renaming it to vuart as it
   isn't used in the common code.
 - Update the commit message: drop "Rename vpl011 to vuart to have more generic
   name suitable for other archs.".
---
Changes in v3:
 - Only resolving of merge conflicts.
---
Changes in v2:
 - Introduce xen/fdt-kernel.h.
 - Move DOM0LESS_* macros to dom0less-build.h.
 - Move the rest in asm-generic/kernel.h to xen/fdt-kernel.h.
 - Drop inclusion of asm/kernel.h everywhere except xen/fdt-kernel.h.
 - Wrap by #if __has_include(....) the member of kernel_info structure:
     struct arch_kernel_info arch.
 - Update the commit message.
---
 xen/arch/arm/acpi/domain_build.c         |   2 +-
 xen/arch/arm/dom0less-build.c            |  31 +++---
 xen/arch/arm/domain_build.c              |  12 +--
 xen/arch/arm/include/asm/domain_build.h  |   2 +-
 xen/arch/arm/include/asm/kernel.h        | 123 +--------------------
 xen/arch/arm/include/asm/static-memory.h |   2 +-
 xen/arch/arm/include/asm/static-shmem.h  |   2 +-
 xen/arch/arm/kernel.c                    |  13 +--
 xen/arch/arm/static-memory.c             |   1 +
 xen/arch/arm/static-shmem.c              |   1 +
 xen/common/device-tree/dt-overlay.c      |   2 +-
 xen/include/asm-generic/dom0less-build.h |  28 +++++
 xen/include/xen/fdt-kernel.h             | 132 +++++++++++++++++++++++
 13 files changed, 198 insertions(+), 153 deletions(-)
 create mode 100644 xen/include/xen/fdt-kernel.h

diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
index 2ce75543d0..f9ca8b47e5 100644
--- a/xen/arch/arm/acpi/domain_build.c
+++ b/xen/arch/arm/acpi/domain_build.c
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /* Override macros from asm/page.h to make them work with mfn_t */
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index ef49495d4f..18d55d90c6 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -64,11 +65,11 @@ static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
@@ -135,11 +136,11 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
-    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic);
+    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc);
     if (res)
         return res;
 
@@ -200,7 +201,7 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
         return res;
 
     res = fdt_property_cell(fdt, "interrupt-parent",
-                            kinfo->phandle_gic);
+                            kinfo->phandle_intc);
     if ( res )
         return res;
 
@@ -486,10 +487,10 @@ static int __init domain_handle_dtb_bootmodule(struct domain *d,
          */
         if ( dt_node_cmp(name, "gic") == 0 )
         {
-            uint32_t phandle_gic = fdt_get_phandle(pfdt, node_next);
+            uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
 
-            if ( phandle_gic != 0 )
-                kinfo->phandle_gic = phandle_gic;
+            if ( phandle_intc != 0 )
+                kinfo->phandle_intc = phandle_intc;
             continue;
         }
 
@@ -532,7 +533,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     int addrcells, sizecells;
     int ret, fdt_size = DOMU_DTB_SIZE;
 
-    kinfo->phandle_gic = GUEST_PHANDLE_GIC;
+    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
     kinfo->gnttab_start = GUEST_GNTTAB_BASE;
     kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
 
@@ -594,7 +595,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     /*
      * domain_handle_dtb_bootmodule has to be called before the rest of
      * the device tree is generated because it depends on the value of
-     * the field phandle_gic.
+     * the field phandle_intc.
      */
     if ( kinfo->dtb_bootmodule )
     {
@@ -611,7 +612,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     if ( ret )
         goto err;
 
-    if ( kinfo->vpl011 )
+    if ( kinfo->arch.vpl011 )
     {
         ret = -EINVAL;
 #ifdef CONFIG_SBSA_VUART_CONSOLE
@@ -839,8 +840,8 @@ int __init construct_domU(struct domain *d,
     printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
            d->max_vcpus, mem);
 
-    kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
-    if ( kinfo.vpl011 && is_hardware_domain(d) )
+    kinfo.arch.vpl011  = dt_property_read_bool(node, "vpl011");
+    if ( kinfo.arch.vpl011  && is_hardware_domain(d) )
         panic("hardware domain cannot specify vpl011\n");
 
     rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
@@ -872,7 +873,7 @@ int __init construct_domU(struct domain *d,
 
 #ifdef CONFIG_ARM_64
     /* type must be set before allocate memory */
-    d->arch.type = kinfo.type;
+    d->arch.type = kinfo.arch.type;
 #endif
     if ( is_hardware_domain(d) )
     {
@@ -898,7 +899,7 @@ int __init construct_domU(struct domain *d,
          * tree node in prepare_dtb_domU, so initialization on related variables
          * shall be done first.
          */
-        if ( kinfo.vpl011 )
+        if ( kinfo.arch.vpl011  )
         {
             rc = domain_vpl011_init(d, NULL);
             if ( rc < 0 )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 270a6b97e4..8c7a054718 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -20,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -747,7 +747,7 @@ static int __init fdt_property_interrupts(const struct kernel_info *kinfo,
         return res;
 
     res = fdt_property_cell(kinfo->fdt, "interrupt-parent",
-                            kinfo->phandle_gic);
+                            kinfo->phandle_intc);
 
     return res;
 }
@@ -2026,7 +2026,7 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo)
 
     ASSERT(dt_host && (dt_host->sibling == NULL));
 
-    kinfo->phandle_gic = dt_interrupt_controller->phandle;
+    kinfo->phandle_intc = dt_interrupt_controller->phandle;
     fdt = device_tree_flattened;
 
     new_size = fdt_totalsize(fdt) + DOM0_FDT_EXTRA_SIZE;
@@ -2196,13 +2196,13 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
 
 #ifdef CONFIG_ARM_64
     /* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */
-    if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT )
+    if ( !(cpu_has_el1_32) && kinfo->arch.type == DOMAIN_32BIT )
     {
         printk("Platform does not support 32-bit domain\n");
         return -EINVAL;
     }
 
-    if ( is_sve_domain(d) && (kinfo->type == DOMAIN_32BIT) )
+    if ( is_sve_domain(d) && (kinfo->arch.type == DOMAIN_32BIT) )
     {
         printk("SVE is not available for 32-bit domain\n");
         return -EINVAL;
@@ -2318,7 +2318,7 @@ int __init construct_hwdom(struct kernel_info *kinfo,
 
 #ifdef CONFIG_ARM_64
     /* type must be set before allocate_memory */
-    d->arch.type = kinfo->type;
+    d->arch.type = kinfo->arch.type;
 #endif
     find_gnttab_region(d, kinfo);
     if ( is_domain_direct_mapped(d) )
diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
index 378c10cc98..df1c0fe301 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -1,8 +1,8 @@
 #ifndef __ASM_DOMAIN_BUILD_H__
 #define __ASM_DOMAIN_BUILD_H__
 
+#include 
 #include 
-#include 
 
 typedef __be32 gic_interrupt_t[3];
 typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
index bdc96f4c18..7c3b7fde5b 100644
--- a/xen/arch/arm/include/asm/kernel.h
+++ b/xen/arch/arm/include/asm/kernel.h
@@ -6,137 +6,18 @@
 #ifndef __ARCH_ARM_KERNEL_H__
 #define __ARCH_ARM_KERNEL_H__
 
-#include 
 #include 
-#include 
 
-/*
- * List of possible features for dom0less domUs
- *
- * DOM0LESS_ENHANCED_NO_XS:  Notify the OS it is running on top of Xen. All the
- *                           default features (excluding Xenstore) will be
- *                           available. Note that an OS *must* not rely on the
- *                           availability of Xen features if this is not set.
- * DOM0LESS_XENSTORE:        Xenstore will be enabled for the VM. The
- *                           xenstore page allocation is done by Xen at
- *                           domain creation. This feature can't be
- *                           enabled without the DOM0LESS_ENHANCED_NO_XS.
- * DOM0LESS_XS_LEGACY        Xenstore will be enabled for the VM, the
- *                           xenstore page allocation will happen in
- *                           init-dom0less. This feature can't be enabled
- *                           without the DOM0LESS_ENHANCED_NO_XS.
- * DOM0LESS_ENHANCED:        Notify the OS it is running on top of Xen. All the
- *                           default features (including Xenstore) will be
- *                           available. Note that an OS *must* not rely on the
- *                           availability of Xen features if this is not set.
- * DOM0LESS_ENHANCED_LEGACY: Same as before, but using DOM0LESS_XS_LEGACY.
- */
-#define DOM0LESS_ENHANCED_NO_XS  BIT(0, U)
-#define DOM0LESS_XENSTORE        BIT(1, U)
-#define DOM0LESS_XS_LEGACY       BIT(2, U)
-#define DOM0LESS_ENHANCED_LEGACY (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XS_LEGACY)
-#define DOM0LESS_ENHANCED        (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE)
-
-struct kernel_info {
+struct arch_kernel_info
+{
 #ifdef CONFIG_ARM_64
     enum domain_type type;
 #endif
 
-    struct domain *d;
-
-    void *fdt; /* flat device tree */
-    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
-    struct meminfo mem;
-#ifdef CONFIG_STATIC_SHM
-    struct shared_meminfo shm_mem;
-#endif
-
-    /* kernel entry point */
-    paddr_t entry;
-
-    /* grant table region */
-    paddr_t gnttab_start;
-    paddr_t gnttab_size;
-
-    /* boot blob load addresses */
-    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
-    const char* cmdline;
-    paddr_t dtb_paddr;
-    paddr_t initrd_paddr;
-
     /* Enable pl011 emulation */
     bool vpl011;
-
-    /* Enable/Disable PV drivers interfaces */
-    uint16_t dom0less_feature;
-
-    /* GIC phandle */
-    uint32_t phandle_gic;
-
-    /* loader to use for this kernel */
-    void (*load)(struct kernel_info *info);
-    /* loader specific state */
-    union {
-        struct {
-            paddr_t kernel_addr;
-            paddr_t len;
-#ifdef CONFIG_ARM_64
-            paddr_t text_offset; /* 64-bit Image only */
-#endif
-            paddr_t start; /* Must be 0 for 64-bit Image */
-        } zimage;
-    };
 };
 
-static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo)
-{
-    return container_of(&kinfo->mem.common, struct membanks, common);
-}
-
-static inline const struct membanks *
-kernel_info_get_mem_const(const struct kernel_info *kinfo)
-{
-    return container_of(&kinfo->mem.common, const struct membanks, common);
-}
-
-#ifdef CONFIG_STATIC_SHM
-#define KERNEL_INFO_SHM_MEM_INIT                \
-    .shm_mem.common.max_banks = NR_SHMEM_BANKS, \
-    .shm_mem.common.type = STATIC_SHARED_MEMORY,
-#else
-#define KERNEL_INFO_SHM_MEM_INIT
-#endif
-
-#define KERNEL_INFO_INIT                        \
-{                                               \
-    .mem.common.max_banks = NR_MEM_BANKS,       \
-    .mem.common.type = MEMORY,                  \
-    KERNEL_INFO_SHM_MEM_INIT                    \
-}
-
-/*
- * Probe the kernel to detemine its type and select a loader.
- *
- * Sets in info:
- *  ->type
- *  ->load hook, and sets loader specific variables ->zimage
- */
-int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
-
-/*
- * Loads the kernel into guest RAM.
- *
- * Expects to be set in info when called:
- *  ->mem
- *  ->fdt
- *
- * Sets in info:
- *  ->entry
- *  ->dtb_paddr
- *  ->initrd_paddr
- */
-void kernel_load(struct kernel_info *info);
-
 #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
 
 /*
diff --git a/xen/arch/arm/include/asm/static-memory.h b/xen/arch/arm/include/asm/static-memory.h
index 804166e541..a32a3c6553 100644
--- a/xen/arch/arm/include/asm/static-memory.h
+++ b/xen/arch/arm/include/asm/static-memory.h
@@ -3,8 +3,8 @@
 #ifndef __ASM_STATIC_MEMORY_H_
 #define __ASM_STATIC_MEMORY_H_
 
+#include 
 #include 
-#include 
 
 #ifdef CONFIG_STATIC_MEMORY
 
diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h
index 94eaa9d500..a4f853805a 100644
--- a/xen/arch/arm/include/asm/static-shmem.h
+++ b/xen/arch/arm/include/asm/static-shmem.h
@@ -3,8 +3,8 @@
 #ifndef __ASM_STATIC_SHMEM_H_
 #define __ASM_STATIC_SHMEM_H_
 
+#include 
 #include 
-#include 
 #include 
 
 #ifdef CONFIG_STATIC_SHM
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 2647812e8e..34c8233853 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -16,7 +17,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 
 #define UIMAGE_MAGIC          0x27051956
@@ -101,7 +102,7 @@ static paddr_t __init kernel_zimage_place(struct kernel_info *info)
     paddr_t load_addr;
 
 #ifdef CONFIG_ARM_64
-    if ( (info->type == DOMAIN_64BIT) && (info->zimage.start == 0) )
+    if ( (info->arch.type == DOMAIN_64BIT) && (info->zimage.start == 0) )
         return mem->bank[0].start + info->zimage.text_offset;
 #endif
 
@@ -371,10 +372,10 @@ static int __init kernel_uimage_probe(struct kernel_info *info,
     switch ( uimage.arch )
     {
     case IH_ARCH_ARM:
-        info->type = DOMAIN_32BIT;
+        info->arch.type = DOMAIN_32BIT;
         break;
     case IH_ARCH_ARM64:
-        info->type = DOMAIN_64BIT;
+        info->arch.type = DOMAIN_64BIT;
         break;
     default:
         printk(XENLOG_ERR "Unsupported uImage arch type %d\n", uimage.arch);
@@ -444,7 +445,7 @@ static int __init kernel_zimage64_probe(struct kernel_info *info,
 
     info->load = kernel_zimage_load;
 
-    info->type = DOMAIN_64BIT;
+    info->arch.type = DOMAIN_64BIT;
 
     return 0;
 }
@@ -496,7 +497,7 @@ static int __init kernel_zimage32_probe(struct kernel_info *info,
     info->load = kernel_zimage_load;
 
 #ifdef CONFIG_ARM_64
-    info->type = DOMAIN_32BIT;
+    info->arch.type = DOMAIN_32BIT;
 #endif
 
     return 0;
diff --git a/xen/arch/arm/static-memory.c b/xen/arch/arm/static-memory.c
index d4585c5a06..e0f76afcd8 100644
--- a/xen/arch/arm/static-memory.c
+++ b/xen/arch/arm/static-memory.c
@@ -2,6 +2,7 @@
 
 #include 
 
+#include 
 #include 
 
 static bool __init append_static_memory_to_bank(struct domain *d,
diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
index e8d4ca3ba3..14ae48fb1e 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/arch/arm/static-shmem.c
@@ -6,6 +6,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/xen/common/device-tree/dt-overlay.c b/xen/common/device-tree/dt-overlay.c
index 97fb99eaaa..81107cb48d 100644
--- a/xen/common/device-tree/dt-overlay.c
+++ b/xen/common/device-tree/dt-overlay.c
@@ -6,8 +6,8 @@
  * Written by Vikram Garhwal 
  *
  */
-#include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
index ef2073d802..2003be743f 100644
--- a/xen/include/asm-generic/dom0less-build.h
+++ b/xen/include/asm-generic/dom0less-build.h
@@ -17,6 +17,34 @@ struct dt_device_node;
 #define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
 extern bool need_xenstore;
 
+/*
+ * List of possible features for dom0less domUs
+ *
+ * DOM0LESS_ENHANCED_NO_XS:  Notify the OS it is running on top of Xen. All the
+ *                           default features (excluding Xenstore) will be
+ *                           available. Note that an OS *must* not rely on the
+ *                           availability of Xen features if this is not set.
+ * DOM0LESS_XENSTORE:        Xenstore will be enabled for the VM. The
+ *                           xenstore page allocation is done by Xen at
+ *                           domain creation. This feature can't be
+ *                           enabled without the DOM0LESS_ENHANCED_NO_XS.
+ * DOM0LESS_XS_LEGACY        Xenstore will be enabled for the VM, the
+ *                           xenstore page allocation will happen in
+ *                           init-dom0less. This feature can't be enabled
+ *                           without the DOM0LESS_ENHANCED_NO_XS.
+ * DOM0LESS_ENHANCED:        Notify the OS it is running on top of Xen. All the
+ *                           default features (including Xenstore) will be
+ *                           available. Note that an OS *must* not rely on the
+ *                           availability of Xen features if this is not set.
+ * DOM0LESS_ENHANCED_LEGACY: Same as before, but using DOM0LESS_XS_LEGACY.
+
+ */
+#define DOM0LESS_ENHANCED_NO_XS  BIT(0, U)
+#define DOM0LESS_XENSTORE        BIT(1, U)
+#define DOM0LESS_XS_LEGACY       BIT(2, U)
+#define DOM0LESS_ENHANCED_LEGACY (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XS_LEGACY)
+#define DOM0LESS_ENHANCED        (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE)
+
 void create_domUs(void);
 bool is_dom0less_mode(void);
 void set_xs_domain(struct domain *d);
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
new file mode 100644
index 0000000000..516cc68e90
--- /dev/null
+++ b/xen/include/xen/fdt-kernel.h
@@ -0,0 +1,132 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * For Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __XEN_FDT_KERNEL_H__
+#define __XEN_FDT_KERNEL_H__
+
+#include 
+#include 
+#include 
+
+#if __has_include()
+#   include 
+#endif
+
+struct kernel_info {
+    struct domain *d;
+
+    void *fdt; /* flat device tree */
+    paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+    struct meminfo mem;
+#ifdef CONFIG_STATIC_SHM
+    struct shared_meminfo shm_mem;
+#endif
+
+    /* kernel entry point */
+    paddr_t entry;
+
+    /* grant table region */
+    paddr_t gnttab_start;
+    paddr_t gnttab_size;
+
+    /* boot blob load addresses */
+    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
+    const char* cmdline;
+    paddr_t dtb_paddr;
+    paddr_t initrd_paddr;
+
+    /* Enable/Disable PV drivers interfaces */
+    uint16_t dom0less_feature;
+
+    /* Interrupt controller phandle */
+    uint32_t phandle_intc;
+
+    /* loader to use for this kernel */
+    void (*load)(struct kernel_info *info);
+
+    /* loader specific state */
+    union {
+        struct {
+            paddr_t kernel_addr;
+            paddr_t len;
+#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64)
+            paddr_t text_offset; /* 64-bit Image only */
+#endif
+            paddr_t start; /* Must be 0 for 64-bit Image */
+        } zimage;
+    };
+
+#if __has_include()
+    struct arch_kernel_info arch;
+#endif
+};
+
+static inline struct membanks *kernel_info_get_mem(struct kernel_info *kinfo)
+{
+    return container_of(&kinfo->mem.common, struct membanks, common);
+}
+
+static inline const struct membanks *
+kernel_info_get_mem_const(const struct kernel_info *kinfo)
+{
+    return container_of(&kinfo->mem.common, const struct membanks, common);
+}
+
+#ifndef KERNEL_INFO_SHM_MEM_INIT
+
+#ifdef CONFIG_STATIC_SHM
+#define KERNEL_INFO_SHM_MEM_INIT                \
+    .shm_mem.common.max_banks = NR_SHMEM_BANKS, \
+    .shm_mem.common.type = STATIC_SHARED_MEMORY,
+#else
+#define KERNEL_INFO_SHM_MEM_INIT
+#endif
+
+#endif /* KERNEL_INFO_SHM_MEM_INIT */
+
+#ifndef KERNEL_INFO_INIT
+
+#define KERNEL_INFO_INIT                        \
+{                                               \
+    .mem.common.max_banks = NR_MEM_BANKS,       \
+    .mem.common.type = MEMORY,                  \
+    KERNEL_INFO_SHM_MEM_INIT                    \
+}
+
+#endif /* KERNEL_INFO_INIT */
+
+/*
+ * Probe the kernel to detemine its type and select a loader.
+ *
+ * Sets in info:
+ *  ->load hook, and sets loader specific variables ->zimage
+ */
+int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
+
+/*
+ * Loads the kernel into guest RAM.
+ *
+ * Expects to be set in info when called:
+ *  ->mem
+ *  ->fdt
+ *
+ * Sets in info:
+ *  ->entry
+ *  ->dtb_paddr
+ *  ->initrd_paddr
+ */
+void kernel_load(struct kernel_info *info);
+
+#endif /* __XEN_FDT_KERNEL_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 05 18:10:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 18:10:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976210.1363443 (Exim 4.92)
	(envelope-from )
	id 1uC0HA-0006ce-BB; Mon, 05 May 2025 18:10:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976210.1363443; Mon, 05 May 2025 18:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uC0HA-0006bi-3C; Mon, 05 May 2025 18:10:48 +0000
Received: by outflank-mailman (input) for mailman id 976210;
 Mon, 05 May 2025 18:10:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC0H8-0005wU-90
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 18:10:46 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 43c6444a-29dc-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 20:10:45 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5ed43460d6bso7291598a12.0
 for ; Mon, 05 May 2025 11:10:45 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189146fcbsm530372366b.34.2025.05.05.11.10.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 11:10: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" 
X-Inumbo-ID: 43c6444a-29dc-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746468645; x=1747073445; 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;
        bh=tlG03+gXnXCUtXssnU/J0TI7pH+zT0PZJfNCpBDG6K0=;
        b=jrceSAMscZZ7Dr6HvcTBofoMZ2jMqTODlpNaRVoQuEq6Cx7O/MA3kiqXsFKobtdu0f
         r/pWbzD8oWqvI4767PfyyZV/IsJQ0l33YMujXwVA9LsNH37XyHy1yVrz6qLzNL/wL0xx
         QGa8uClYbJonQ/Nn5mKEfai4ulJE5HgwtzdtaDRZAwurjBuPvgUwB1xYqU0x162cPXiT
         ZYoQ7Eono50SBGgTAUkxyxy6Abjuk4Tnv0KiUNDJoy313wxf8rDD+ssKS/Wx99ENo4xF
         BZcaVtRplBmaojWjpoWkSR7GyIJJpiKxAo8jR4RRblKMRGzjro8DBMJg7/6BZ9QfogRY
         xdDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746468645; x=1747073445;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=tlG03+gXnXCUtXssnU/J0TI7pH+zT0PZJfNCpBDG6K0=;
        b=N5NXbHtRkc/c2LiEWexeWBBmBtPrV+2/MFyhRsdbusRUKnmwJlozu9hltwhN2dmkkj
         8m77PlvBsKVK27Q7OB4FzGt48gxZgFsxXXlnRYH0a/kbBPHnqF7W49KXQWOAWJJw4Eul
         nFZXV2eeunl0pFpHOUYV/E3fEtUDz/+1nr1w3+/8J9chrjXAy1rkUngAVZYBM6wY43KH
         43FmDWFmcNFVpUZoQ56OVW0bK/s471fRoCl74DfbAJ/c2RZNqq/Ml2VWXfJ4xn/KQV+U
         HJbz94fQsmTUWNylyv8/IwwRQjurlwC0HfpLObMbJ6EwiWWCenoLIGC251Rrm4AeyiBg
         grGg==
X-Gm-Message-State: AOJu0YxQ/pW/aXbftAkgDOJFBdrgI50/tJMTw9YgHhpApWH5EmXpEbLq
	bEZgNFfHFfUzVCxRSvxLeGen091t4nveh60k3WWOX/Djm8WsToWMWWm7rA==
X-Gm-Gg: ASbGncuNXZoLdeZDlXyXag3c8ezXryCkjXGGIL4lSEw4I2cmgC5/WNzNN44Kn8o6JQ3
	6cG3ByKTz4vYzA5M48XlLibjePyVFUVho73Kx2gst5NcEyGWqNBacLUd6mMkvakguD3sfeSKedb
	LCcPAVG9PlZbgzdS4b98pVcXY/E52Q9tQqwxG/+/jasF6XE9wmz7JZCjrChMGOhMXx6PLdZFi7i
	48C9Z3ij+tFShGZXxrxj2VZD0bh8CwON2p2yCKxy/Bl30dYdnPsQN5nXNvW0R0PDIBCl6hV75Sx
	LwQmdK9734RLBYLk/XMuWRuNwsR0ZqlLa1zbAWn1pm5Dk7vItuf6CxHLX5t0XizjLa6F0/zpgJ2
	PVtNr0lomWg==
X-Google-Smtp-Source: AGHT+IFX97REERVNC4KQ9UY17R25rYwsjgOlf0v8AFy1Kit/MJpLDE3DtVEtQPqvosYWLu9W0t87Nw==
X-Received: by 2002:a17:907:968c:b0:ad1:7858:a74c with SMTP id a640c23a62f3a-ad1a4931545mr663380666b.22.1746468644604;
        Mon, 05 May 2025 11:10:44 -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 v4 5/8] asm-generic: move some parts of Arm's domain_build.h to common
Date: Mon,  5 May 2025 20:10:35 +0200
Message-ID: <3e8bcf195a5c7bec8b32aaf01a128dcb25e68b9e.1746468003.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Nothing changed. Only some functions declaration are moved to xen/include/
headers as they are expected to be used by common code of domain builing
or dom0less.

Signed-off-by: Oleksii Kurochko 
---
Chnages in v4:
 - Move declaration of allocate_*() to the patch where defintions of them are introduced.
 - Move declaration of 'int construct_hwdom(struct kernel_info *kinfo,
   const struct dt_device_node *node) to fdt-domain-build.h.
 - Drop declaration of get_allocation_size() from fdt-domain-build.h as defintion/declaration
   will be added in the further patch of this patch series.
---
 Chnages in v3:
 - Drop inclusion of  from xen/fdt-domain-build.h.
 - Add empty line after license tag in xen/fdt-domain-build.h.
---
 Chnages in v2:
  - Add missed declaration of construct_hwdom().
  - Drop unnessary blank line.
  - Introduce xen/fdt-domain-build.h and move parts of Arm's domain_build.h to
    it.
  - Update the commit message.
---
 xen/arch/arm/acpi/domain_build.c        |  1 +
 xen/arch/arm/dom0less-build.c           |  1 +
 xen/arch/arm/domain_build.c             |  1 +
 xen/arch/arm/include/asm/domain_build.h | 11 +-------
 xen/arch/arm/kernel.c                   |  1 +
 xen/arch/arm/static-shmem.c             |  1 +
 xen/include/xen/fdt-domain-build.h      | 35 +++++++++++++++++++++++++
 7 files changed, 41 insertions(+), 10 deletions(-)
 create mode 100644 xen/include/xen/fdt-domain-build.h

diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
index f9ca8b47e5..1c3555d814 100644
--- a/xen/arch/arm/acpi/domain_build.c
+++ b/xen/arch/arm/acpi/domain_build.c
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 7e9cedb0c8..47eb38b9ad 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 8c7a054718..9d649b06b3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
index df1c0fe301..9d72108f35 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -9,21 +9,12 @@ typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
                                      unsigned int order, void *extra);
 bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
                              alloc_domheap_mem_cb cb, void *extra);
+
 bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
                           paddr_t tot_size);
 void allocate_memory(struct domain *d, struct kernel_info *kinfo);
-int construct_domain(struct domain *d, struct kernel_info *kinfo);
-int construct_hwdom(struct kernel_info *kinfo,
-                    const struct dt_device_node *node);
 int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
-int make_chosen_node(const struct kernel_info *kinfo);
-int make_cpus_node(const struct domain *d, void *fdt);
-int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
-                         int addrcells, int sizecells);
-int make_memory_node(const struct kernel_info *kinfo, int addrcells,
-                     int sizecells, const struct membanks *mem);
 int make_psci_node(void *fdt);
-int make_timer_node(const struct kernel_info *kinfo);
 void evtchn_allocate(struct domain *d);
 
 unsigned int get_allocation_size(paddr_t size);
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 34c8233853..aea8f44413 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
index 14ae48fb1e..1f8441d920 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/arch/arm/static-shmem.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
new file mode 100644
index 0000000000..30d5358a0f
--- /dev/null
+++ b/xen/include/xen/fdt-domain-build.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __XEN_FDT_DOMAIN_BUILD_H__
+#define __XEN_FDT_DOMAIN_BUILD_H__
+
+#include 
+#include 
+#include 
+#include 
+
+struct domain;
+struct page_info;
+struct membanks;
+
+int construct_domain(struct domain *d, struct kernel_info *kinfo);
+int construct_hwdom(struct kernel_info *kinfo,
+                    const struct dt_device_node *node);
+int make_chosen_node(const struct kernel_info *kinfo);
+int make_cpus_node(const struct domain *d, void *fdt);
+int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
+                         int addrcells, int sizecells);
+int make_memory_node(const struct kernel_info *kinfo, int addrcells,
+                     int sizecells, const struct membanks *mem);
+int make_timer_node(const struct kernel_info *kinfo);
+
+#endif /* __XEN_FDT_DOMAIN_BUILD_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 05 18:10:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 18:10:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976206.1363411 (Exim 4.92)
	(envelope-from )
	id 1uC0H6-0005ye-Mk; Mon, 05 May 2025 18:10:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976206.1363411; Mon, 05 May 2025 18:10: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 1uC0H6-0005yX-J9; Mon, 05 May 2025 18:10:44 +0000
Received: by outflank-mailman (input) for mailman id 976206;
 Mon, 05 May 2025 18:10:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC0H5-0005wU-0F
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 18:10:43 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4197770e-29dc-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 20:10:42 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ad1a87d93f7so306978866b.0
 for ; Mon, 05 May 2025 11:10:42 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189146fcbsm530372366b.34.2025.05.05.11.10.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 11:10:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4197770e-29dc-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746468641; x=1747073441; 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;
        bh=n7TtHnmj/5FH2NS/byj2XTa9Q7kgraZ74IRrvmZxlqM=;
        b=WkqtxcZr2Or2c8cms/0ltqyD3aGEWqQsxezEaAGfxSUEV1rzpljKa2ZPxUakuVdlKG
         3nJPSHrDFRq6jf9BZofdGzvNPjWL+85t4QYRffNmQ3mj3xJqKzXcxipO+akjqGAjrS6d
         jLZ7lLAt1mpka0DPIZqVpnkJSCuo6tyR151r/Anw0MU8cmTbhDRl6GN4wS4qWYujNl7x
         VJ/EzCwZCc4eFmLY9Nuhn7zc+0oo6Dy27IZ9D7JV2df98datB5jjydh4zdb5GI/GG6JR
         +mdJYhrnxzNByVv3UGFZ44UyUIQjTmYV+O9k4BfQ3HECHt2WWQggpcmijDiLH3bE68Hk
         jsXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746468641; x=1747073441;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=n7TtHnmj/5FH2NS/byj2XTa9Q7kgraZ74IRrvmZxlqM=;
        b=G51MrEIYV4sGpxxZdyLoD8IJM19PIDQRa/7tcSuq/l2t0PWe/tvd1wY2Ayy2oBEOEf
         BPp7o1AS8jIGX4OhHdYtOmXpB+brvXK7WqxkKKKpTgTvQHstSK4dwwqaRvLQz2NCyuOh
         NF8Upv/bmmiyHR0VnU4n+kHo0Nc84JODnaudfOuk1mm7NPpN6GSmuUofAVcrm36rPIeK
         dEi9J3DwGAm8MNrFd7SiFhzaxukDaFhbqArM9nVGGCTWp6sgIUR0qNrfMwiXPAo9Sq9T
         yjoY6VCmCSQGKo7APaSndFYe/4srXTupoXGPRL8uhFH461+v6b+8BLZYwBcJ7eBXu7PZ
         BMcg==
X-Gm-Message-State: AOJu0YyB+GfV4hxR02l6MXuPmQuSfn/x3FwRyOVI6h+uwOV5It5Syhg+
	Y8aEzpCyaCCi7fwaNsqbuN7W5HrZsoJ1AK9g6Gk5tdZN6xtsCL7jsmKfcQ==
X-Gm-Gg: ASbGncsghN7tYdiIVZiL3nFX0wkNSfYUv90E0yeSXweLwLHxdTJGSw2YSETyq6diRBp
	kyD3XuEFl3phITRtHTW+E3UooPswakzBbO6OncIkxYEezpWR/0f8G+wxmlafozrUMAHnxGsVNhv
	9jqJ88+TjbD/a/RVRJuMUOJ43Rij/jXdCEf5VL3wrviFIffJTbdmB4c+ROuV7H17QQEjCbx0OIx
	hEkgKmN8jBrQFikTi2YOhFeB+JPx0QQp9gDlXx8nx//vmKALqlaBVI4I+1Uzw7xqyd6KyNUnuCX
	Om8KLBJue5L1tWkih6KJPzgy0t3BggaxDv8UKt50bkVbUne3zNQjBtalzaHZmtC6j8PM8H+a/AH
	E+J6VsaiNQQ==
X-Google-Smtp-Source: AGHT+IFD2fkk0khKwFhTmebLcoTKYeyVppAqrQVO+tbjTiaBVUwoTeZYiCf+3BRsnhWQ4Ahv6bhrYQ==
X-Received: by 2002:a17:907:7f05:b0:aca:d6f2:5d5 with SMTP id a640c23a62f3a-ad1d355c9f1mr24033866b.39.1746468641001;
        Mon, 05 May 2025 11:10:41 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v4 1/8] xen/arm: drop declaration of handle_device_interrupts()
Date: Mon,  5 May 2025 20:10:31 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

There is no definition of handle_device_interrupts() thereby it
could be dropped.

Signed-off-by: Oleksii Kurochko 
Reviewed-by: Michal Orzel 
---
Change in v4:
 - Nothing changed. Only rebase.
---
Change in v3:
 - Update commit message
 - Add Reviewed-by: Michal Orzel .
---
 xen/arch/arm/include/asm/domain_build.h | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
index 17619c875d..378c10cc98 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -28,17 +28,6 @@ void evtchn_allocate(struct domain *d);
 
 unsigned int get_allocation_size(paddr_t size);
 
-/*
- * handle_device_interrupts retrieves the interrupts configuration from
- * a device tree node and maps those interrupts to the target domain.
- *
- * Returns:
- *   < 0 error
- *   0   success
- */
-int handle_device_interrupts(struct domain *d, struct dt_device_node *dev,
-                             bool need_mapping);
-
 /*
  * Helper to write an interrupts with the GIC format
  * This code is assuming the irq is an PPI.
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 05 18:10:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 18:10:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976209.1363431 (Exim 4.92)
	(envelope-from )
	id 1uC0H9-0006LG-H2; Mon, 05 May 2025 18:10:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976209.1363431; Mon, 05 May 2025 18:10: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 1uC0H9-0006I2-AB; Mon, 05 May 2025 18:10:47 +0000
Received: by outflank-mailman (input) for mailman id 976209;
 Mon, 05 May 2025 18:10:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC0H7-000675-DR
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 18:10:45 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 424e38d3-29dc-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 20:10:43 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ace94273f0dso125302266b.3
 for ; Mon, 05 May 2025 11:10:43 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189146fcbsm530372366b.34.2025.05.05.11.10.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 11:10: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" 
X-Inumbo-ID: 424e38d3-29dc-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746468642; x=1747073442; 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;
        bh=+Dmg4OJDfAkrWVudvhelb2AOi75q5BWZSucBriqVubU=;
        b=UGVNGspMpJINUVT0kmuj3X/ujTgTs8Oyj8lK7QTzMOn3y+RXVBR8Dpgj4Ma3Xh9khq
         qznB6LUt9Vcj/cd6MpTCukNHDsRW9nrf8YUzGDsFAHq7lQ/HV9yywgItEvNSUaZPBUbF
         npyyqXYk1bTLZt0yPzstuzSFr/htnJbYnOUCSkoYvlISHZQwykwd66qDVRWkx75EuHJi
         xnBpwkCbVBtkEziyRrWooAwcDsE1QaVEv6qDwOWoEdWeQJkQMJ3C9K1I7zsLPeInSsDb
         QhdYCmzkMyp4bGddSiDOUd6BFPQIKYgF56gbs0+cAE6ggMGiqH9JDHiCBqYtoGMNjaIY
         XhxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746468642; x=1747073442;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+Dmg4OJDfAkrWVudvhelb2AOi75q5BWZSucBriqVubU=;
        b=xFpW033vrveaC6DWuu898vnBfXhbY0oSF+7KNBUMR9qCoiEW+RRdqSyqwmqI8/GhLs
         /lmHOStpvNLUlMMk8KQr/rhaf0ghNI8FJebxoaPgj76FsdWf5OuIALtSk+FqL5DSOKOu
         BgG7UKvscNwzq6jUEfqBKlvhi5/6DzUcPcMGEPJJr4qvTVkQ0dmQwoT9CiQjy0ZxQBaC
         tAXIPXsDJjBEpmJDeEY/GPJFbOhnI6WVSH2RzV7SU0j7ctA0/Ww6c7je173h4YjcbT21
         5YnDzgLd9X5YBmdcZmmSWzfgPGLhKfEWmPkOQJW89qnQyRomNyRLc12c5MTLyiG/hb+7
         tuqA==
X-Gm-Message-State: AOJu0Yx7yGwKxoo5IVyoD+IaZotV7BVl7R4roa+jtoR/Zj3TkFUBqspX
	sT+QP3LV+WPtCRHr9DKNtSMZOfExxRLGPtbIcaL2SUeVlPJfzFNFbuqROw==
X-Gm-Gg: ASbGncuNW162l2VlEP1hm1EFCOgL7kW8ioBeSqZVsJXcqvbBF54N7EZaJSIoCCT+C32
	qiKW1HGEM3rCVW8hQL++Ws34+sGKUcWSQpJPLIPqIotqJFRAhaMK4pMZxHEYAZRjphAtBaoCBk8
	mEzjjOqG6vTX235DYCvO3XpkUdwa+Ul2+M5waqsOYR7oikPFsBRwQpO+bvaX02yXc765P/wgOtz
	ewJE0fA3CcYgP272H/9k0y0P8aNYR88jnTE4oFCac8z4vPSG5Jg6nldmCHHtBTGeLsGki5Egn0z
	g1kgBKRie3GpJGzNoQsvQB/4Mu0cvlGnRmCBY3o6K+VKeJCHK2USZQxKCxcq5jPU2iAs0D03ssK
	cjy6/BmOVcQ==
X-Google-Smtp-Source: AGHT+IE7Gvpp5W5MIsV5Gm3m3GqKV7R/LAcPyO8O4/iFMgelv4amN3u4sJq1Nks8P1MfraJjCWu22w==
X-Received: by 2002:a17:907:6e94:b0:acf:8758:50f5 with SMTP id a640c23a62f3a-ad1a48bd704mr853404866b.5.1746468641992;
        Mon, 05 May 2025 11:10:41 -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 v4 2/8] xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common
Date: Mon,  5 May 2025 20:10:32 +0200
Message-ID: <3c096d750b9ff6ebec0f391d1566d1386301eef7.1746468003.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Move some parts of Arm's Dom0Less code to be reused by other architectures.
At the moment, RISC-V is going to reuse these parts.

Move dom0less-build.h from the Arm-specific directory to asm-generic
as these header is expected to be the same across acrhictectures with
some updates: add the following declaration of construct_domU(),
and arch_create_domUs() as there are some parts which are still
architecture-specific.

Introduce HAS_DOM0LESS to provide ability to enable generic Dom0less
code for an architecture.

Relocate the CONFIG_DOM0LESS configuration to the common with adding
"depends on HAS_DOM0LESS" to not break builds for architectures which
don't support CONFIG_DOM0LESS config, especically it would be useful
to not provide stubs for  construct_domU(), arch_create_domUs()
in case of *-randconfig which may set CONFIG_DOM0LESS=y.

Move is_dom0less_mode() function to the common code, as it depends on
boot modules that are already part of the common code.

Move create_domUs() function to the common code with some updates:
- Add arch_create_domUs() to cover parsing of arch-specific features,
  for example, SVE (Scalar Vector Extension ) exists only in Arm.

Signed-off-by: Oleksii Kurochko 
Reviewed-by: Stefano Stabellini 
---
Changes in v4:
- Add HAS_DEVICE_TREE dependency to DOM0LESS_BOOT config and
  drop 'select HAS_DEVICE_TREE' from HAS_DOM0LESS.
- Move forward declaration of 'struct domain' outside #ifdef CONFIG_DOM0LESS_BOOT
  as it is used by an argument of set_xs_domain().
- Add Reviewed-by: Stefano Stabellini .
- Drop footer after commit message: the change of dom0less to something else
  (predefined domains or similar) will be done separately, outside this patch
  series.
- Add EMACS stuff at the end of dom0less-build.c file.
- Wrap "d_cfg.max_grant_frames = gnttab_dom0_frames();" by #ifdef CONFIG_GRANT_TABLE
  as gnttab_dom0_frames() is only defined in case when CONFIG_GRANT_TABLE=y.
- Update the commit message: drop info about arch_xen_domctl_createdomain() as this
  function was dropped in previous version of this patch.
---
Changes in v3:
 - Move changes connected to the patch "xen/arm: dom0less delay xenstore initialization"
   to common.
   Also, some necessary parts for the mentioned patches were moved
   to common (such as alloc_xenstore_evtchn(), ... ).
   Not all changes are moved, changes connected to alloc_xenstore_params() and
   construct_domu() will be moved in the following patches of this patch series.
 - Move parsing of capabilities property to common code.
 - Align parsing of "passthrough", "multiboot,device-tree" properties with staging.
 - Drop arch_xen_domctl_createdomain().
 - Add 'select HAS_DEVICE_TREE' for config HAS_DOM0LESS.
 - Add empty lines after license in the top of newly added files.
 - s/arch_create_domus/arch_create_domUs.
 - Add footer below commit message regarding the naming of dom0less.
---
Changes in v2:
 - Convert 'depends on Arm' to 'depends on HAS_DOM0LESS' for
   CONFIG_DOM0LESS_BOOT.
 - Change 'default Arm' to 'default y' for CONFIG_DOM0LESS_BOOT as there is
   dependency on HAS_DOM0LESS.
 - Introduce HAS_DOM0LESS and enable it for Arm.
 - Update the commit message.
---
 xen/arch/arm/Kconfig                      |   9 +-
 xen/arch/arm/dom0less-build.c             | 371 ++++------------------
 xen/arch/arm/include/asm/Makefile         |   1 +
 xen/arch/arm/include/asm/dom0less-build.h |  34 --
 xen/common/Kconfig                        |  12 +
 xen/common/device-tree/Makefile           |   1 +
 xen/common/device-tree/dom0less-build.c   | 294 +++++++++++++++++
 xen/include/asm-generic/dom0less-build.h  |  50 +++
 8 files changed, 415 insertions(+), 357 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h
 create mode 100644 xen/common/device-tree/dom0less-build.c
 create mode 100644 xen/include/asm-generic/dom0less-build.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index da8a406f5a..d0e0a7753c 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -15,6 +15,7 @@ config ARM
 	select GENERIC_UART_INIT
 	select HAS_ALTERNATIVE if HAS_VMAP
 	select HAS_DEVICE_TREE
+	select HAS_DOM0LESS
 	select HAS_STACK_PROTECTOR
 	select HAS_UBSAN
 
@@ -120,14 +121,6 @@ config GICV2
 	  Driver for the ARM Generic Interrupt Controller v2.
 	  If unsure, say Y
 
-config DOM0LESS_BOOT
-	bool "Dom0less boot support" if EXPERT
-	default y
-	help
-	  Dom0less boot support enables Xen to create and start domU guests during
-	  Xen boot without the need of a control domain (Dom0), which could be
-	  present anyway.
-
 config GICV3
 	bool "GICv3 driver"
 	depends on !NEW_VGIC
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a356fc94fc..ef49495d4f 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -22,48 +22,7 @@
 #include 
 #include 
 
-#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
-
-static domid_t __initdata xs_domid = DOMID_INVALID;
-static bool __initdata need_xenstore;
-
-void __init set_xs_domain(struct domain *d)
-{
-    xs_domid = d->domain_id;
-    set_global_virq_handler(d, VIRQ_DOM_EXC);
-}
-
-bool __init is_dom0less_mode(void)
-{
-    struct bootmodules *mods = &bootinfo.modules;
-    struct bootmodule *mod;
-    unsigned int i;
-    bool dom0found = false;
-    bool domUfound = false;
-
-    /* Look into the bootmodules */
-    for ( i = 0 ; i < mods->nr_mods ; i++ )
-    {
-        mod = &mods->module[i];
-        /* Find if dom0 and domU kernels are present */
-        if ( mod->kind == BOOTMOD_KERNEL )
-        {
-            if ( mod->domU == false )
-            {
-                dom0found = true;
-                break;
-            }
-            else
-                domUfound = true;
-        }
-    }
-
-    /*
-     * If there is no dom0 kernel but at least one domU, then we are in
-     * dom0less mode
-     */
-    return ( !dom0found && domUfound );
-}
+bool __initdata need_xenstore;
 
 #ifdef CONFIG_VGICV2
 static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
@@ -686,25 +645,6 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     return -EINVAL;
 }
 
-static int __init alloc_xenstore_evtchn(struct domain *d)
-{
-    evtchn_alloc_unbound_t alloc;
-    int rc;
-
-    alloc.dom = d->domain_id;
-    alloc.remote_dom = xs_domid;
-    rc = evtchn_alloc_unbound(&alloc, 0);
-    if ( rc )
-    {
-        printk("Failed allocating event channel for domain\n");
-        return rc;
-    }
-
-    d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port;
-
-    return 0;
-}
-
 #define XENSTORE_PFN_OFFSET 1
 static int __init alloc_xenstore_page(struct domain *d)
 {
@@ -771,36 +711,6 @@ static int __init alloc_xenstore_params(struct kernel_info *kinfo)
     return rc;
 }
 
-static void __init initialize_domU_xenstore(void)
-{
-    struct domain *d;
-
-    if ( xs_domid == DOMID_INVALID )
-        return;
-
-    for_each_domain( d )
-    {
-        uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN];
-        int rc;
-
-        if ( gfn == 0 )
-            continue;
-
-        if ( is_xenstore_domain(d) )
-            continue;
-
-        rc = alloc_xenstore_evtchn(d);
-        if ( rc < 0 )
-            panic("%pd: Failed to allocate xenstore_evtchn\n", d);
-
-        if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) )
-        {
-            ASSERT(gfn < UINT32_MAX);
-            gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn);
-        }
-    }
-}
-
 static void __init domain_vcpu_affinity(struct domain *d,
                                         const struct dt_device_node *node)
 {
@@ -906,8 +816,8 @@ static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
 }
 #endif /* CONFIG_ARCH_PAGING_MEMPOOL */
 
-static int __init construct_domU(struct domain *d,
-                                 const struct dt_device_node *node)
+int __init construct_domU(struct domain *d,
+                          const struct dt_device_node *node)
 {
     struct kernel_info kinfo = KERNEL_INFO_INIT;
     const char *dom0less_enhanced;
@@ -1009,246 +919,77 @@ static int __init construct_domU(struct domain *d,
     return alloc_xenstore_params(&kinfo);
 }
 
-void __init create_domUs(void)
+void __init arch_create_domUs(struct dt_device_node *node,
+                       struct xen_domctl_createdomain *d_cfg,
+                       unsigned int flags)
 {
-    struct dt_device_node *node;
-    const char *dom0less_iommu;
-    bool iommu = false;
-    const struct dt_device_node *cpupool_node,
-                                *chosen = dt_find_node_by_path("/chosen");
-    const char *llc_colors_str = NULL;
-
-    BUG_ON(chosen == NULL);
-    dt_for_each_child_node(chosen, node)
-    {
-        struct domain *d;
-        struct xen_domctl_createdomain d_cfg = {
-            .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
-            .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
-            /*
-             * The default of 1023 should be sufficient for guests because
-             * on ARM we don't bind physical interrupts to event channels.
-             * The only use of the evtchn port is inter-domain communications.
-             * 1023 is also the default value used in libxl.
-             */
-            .max_evtchn_port = 1023,
-            .max_grant_frames = -1,
-            .max_maptrack_frames = -1,
-            .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
-        };
-        unsigned int flags = 0U;
-        bool has_dtb = false;
-        uint32_t val;
-        int rc;
-
-        if ( !dt_device_is_compatible(node, "xen,domain") )
-            continue;
-
-        if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
-            panic("No more domain IDs available\n");
+    uint32_t val;
 
-        if ( dt_property_read_u32(node, "capabilities", &val) )
-        {
-            if ( val & ~DOMAIN_CAPS_MASK )
-                panic("Invalid capabilities (%"PRIx32")\n", val);
-
-            if ( val & DOMAIN_CAPS_CONTROL )
-                flags |= CDF_privileged;
-
-            if ( val & DOMAIN_CAPS_HARDWARE )
-            {
-                if ( hardware_domain )
-                    panic("Only 1 hardware domain can be specified! (%pd)\n",
-                           hardware_domain);
-
-                d_cfg.max_grant_frames = gnttab_dom0_frames();
-                d_cfg.max_evtchn_port = -1;
-                flags |= CDF_hardware;
-                iommu = true;
-            }
-
-            if ( val & DOMAIN_CAPS_XENSTORE )
-            {
-                if ( xs_domid != DOMID_INVALID )
-                    panic("Only 1 xenstore domain can be specified! (%u)\n",
-                          xs_domid);
+    d_cfg->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
+    d_cfg->flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap;
 
-                d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain;
-                d_cfg.max_evtchn_port = -1;
-            }
-        }
-
-        if ( dt_find_property(node, "xen,static-mem", NULL) )
-        {
-            if ( llc_coloring_enabled )
-                panic("LLC coloring and static memory are incompatible\n");
-
-            flags |= CDF_staticmem;
-        }
-
-        if ( dt_property_read_bool(node, "direct-map") )
-        {
-            if ( !(flags & CDF_staticmem) )
-                panic("direct-map is not valid for domain %s without static allocation.\n",
-                      dt_node_name(node));
-
-            flags |= CDF_directmap;
-        }
-
-        if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) )
-            panic("Missing property 'cpus' for domain %s\n",
-                  dt_node_name(node));
-
-        if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) )
-        {
-            if ( flags & CDF_hardware )
-                panic("Don't specify passthrough for hardware domain\n");
-
-            if ( !strcmp(dom0less_iommu, "enabled") )
-                iommu = true;
-        }
-
-        if ( (flags & CDF_hardware) && !(flags & CDF_directmap) &&
-             !iommu_enabled )
-            panic("non-direct mapped hardware domain requires iommu\n");
-
-        if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") )
-        {
-            if ( flags & CDF_hardware )
-                panic("\"multiboot,device-tree\" incompatible with hardware domain\n");
-
-            has_dtb = true;
-        }
-
-        if ( iommu_enabled && (iommu || has_dtb) )
-            d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
-
-        if ( !dt_property_read_u32(node, "nr_spis", &d_cfg.arch.nr_spis) )
-        {
-            int vpl011_virq = GUEST_VPL011_SPI;
-
-            d_cfg.arch.nr_spis = VGIC_DEF_NR_SPIS;
-
-            /*
-             * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
-             * set, in which case it'll match the hardware.
-             *
-             * Since the domain is not yet created, we can't use
-             * d->arch.vpl011.irq. So the logic to find the vIRQ has to
-             * be hardcoded.
-             * The logic here shall be consistent with the one in
-             * domain_vpl011_init().
-             */
-            if ( flags & CDF_directmap )
-            {
-                vpl011_virq = serial_irq(SERHND_DTUART);
-                if ( vpl011_virq < 0 )
-                    panic("Error getting IRQ number for this serial port %d\n",
-                          SERHND_DTUART);
-            }
+    if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) )
+    {
+        int vpl011_virq = GUEST_VPL011_SPI;
 
-            /*
-             * vpl011 uses one emulated SPI. If vpl011 is requested, make
-             * sure that we allocate enough SPIs for it.
-             */
-            if ( dt_property_read_bool(node, "vpl011") )
-                d_cfg.arch.nr_spis = MAX(d_cfg.arch.nr_spis,
-                                         vpl011_virq - 32 + 1);
-        }
-        else if ( flags & CDF_hardware )
-            panic("nr_spis cannot be specified for hardware domain\n");
+        d_cfg->arch.nr_spis = VGIC_DEF_NR_SPIS;
 
-        /* Get the optional property domain-cpupool */
-        cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
-        if ( cpupool_node )
+        /*
+         * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
+         * set, in which case it'll match the hardware.
+         *
+         * Since the domain is not yet created, we can't use
+         * d->arch.vpl011.irq. So the logic to find the vIRQ has to
+         * be hardcoded.
+         * The logic here shall be consistent with the one in
+         * domain_vpl011_init().
+         */
+        if ( flags & CDF_directmap )
         {
-            int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
-            if ( pool_id < 0 )
-                panic("Error getting cpupool id from domain-cpupool (%d)\n",
-                      pool_id);
-            d_cfg.cpupool_id = pool_id;
+            vpl011_virq = serial_irq(SERHND_DTUART);
+            if ( vpl011_virq < 0 )
+                panic("Error getting IRQ number for this serial port %d\n",
+                        SERHND_DTUART);
         }
 
-        if ( dt_property_read_u32(node, "max_grant_version", &val) )
-            d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val);
+        /*
+            * vpl011 uses one emulated SPI. If vpl011 is requested, make
+            * sure that we allocate enough SPIs for it.
+            */
+        if ( dt_property_read_bool(node, "vpl011") )
+            d_cfg->arch.nr_spis = MAX(d_cfg->arch.nr_spis,
+                                      vpl011_virq - 32 + 1);
+    }
+    else if ( flags & CDF_hardware )
+        panic("nr_spis cannot be specified for hardware domain\n");
 
-        if ( dt_property_read_u32(node, "max_grant_frames", &val) )
-        {
-            if ( val > INT32_MAX )
-                panic("max_grant_frames (%"PRIu32") overflow\n", val);
-            d_cfg.max_grant_frames = val;
-        }
+    if ( dt_get_property(node, "sve", &val) )
+    {
+#ifdef CONFIG_ARM64_SVE
+        unsigned int sve_vl_bits;
+        bool ret = false;
 
-        if ( dt_property_read_u32(node, "max_maptrack_frames", &val) )
+        if ( !val )
         {
-            if ( val > INT32_MAX )
-                panic("max_maptrack_frames (%"PRIu32") overflow\n", val);
-            d_cfg.max_maptrack_frames = val;
+            /* Property found with no value, means max HW VL supported */
+            ret = sve_domctl_vl_param(-1, &sve_vl_bits);
         }
-
-        if ( dt_get_property(node, "sve", &val) )
+        else
         {
-#ifdef CONFIG_ARM64_SVE
-            unsigned int sve_vl_bits;
-            bool ret = false;
-
-            if ( !val )
-            {
-                /* Property found with no value, means max HW VL supported */
-                ret = sve_domctl_vl_param(-1, &sve_vl_bits);
-            }
+            if ( dt_property_read_u32(node, "sve", &val) )
+                ret = sve_domctl_vl_param(val, &sve_vl_bits);
             else
-            {
-                if ( dt_property_read_u32(node, "sve", &val) )
-                    ret = sve_domctl_vl_param(val, &sve_vl_bits);
-                else
-                    panic("Error reading 'sve' property\n");
-            }
+                panic("Error reading 'sve' property\n");
+        }
 
-            if ( ret )
-                d_cfg.arch.sve_vl = sve_encode_vl(sve_vl_bits);
-            else
-                panic("SVE vector length error\n");
+        if ( ret )
+            d_cfg->arch.sve_vl = sve_encode_vl(sve_vl_bits);
+        else
+            panic("SVE vector length error\n");
 #else
-            panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
+        panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
 #endif
-        }
-
-        dt_property_read_string(node, "llc-colors", &llc_colors_str);
-        if ( !llc_coloring_enabled && llc_colors_str )
-            panic("'llc-colors' found, but LLC coloring is disabled\n");
-
-        /*
-         * The variable max_init_domid is initialized with zero, so here it's
-         * very important to use the pre-increment operator to call
-         * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
-         */
-        d = domain_create(++max_init_domid, &d_cfg, flags);
-        if ( IS_ERR(d) )
-            panic("Error creating domain %s (rc = %ld)\n",
-                  dt_node_name(node), PTR_ERR(d));
-
-        if ( llc_coloring_enabled &&
-             (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) )
-            panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
-                  dt_node_name(node), rc);
-
-        d->is_console = true;
-        dt_device_set_used_by(node, d->domain_id);
-
-        rc = construct_domU(d, node);
-        if ( rc )
-            panic("Could not set up domain %s (rc = %d)\n",
-                  dt_node_name(node), rc);
-
-        if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain )
-            set_xs_domain(d);
     }
-
-    if ( need_xenstore && xs_domid == DOMID_INVALID )
-        panic("xenstore requested, but xenstore domain not present\n");
-
-    initialize_domU_xenstore();
 }
 
 /*
diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile
index 4a4036c951..831c914cce 100644
--- a/xen/arch/arm/include/asm/Makefile
+++ b/xen/arch/arm/include/asm/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 generic-y += altp2m.h
 generic-y += device.h
+generic-y += dom0less-build.h
 generic-y += hardirq.h
 generic-y += iocap.h
 generic-y += paging.h
diff --git a/xen/arch/arm/include/asm/dom0less-build.h b/xen/arch/arm/include/asm/dom0less-build.h
deleted file mode 100644
index b0e41a1954..0000000000
--- a/xen/arch/arm/include/asm/dom0less-build.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-
-#ifndef __ASM_DOM0LESS_BUILD_H_
-#define __ASM_DOM0LESS_BUILD_H_
-
-#include 
-
-#ifdef CONFIG_DOM0LESS_BOOT
-
-void create_domUs(void);
-bool is_dom0less_mode(void);
-void set_xs_domain(struct domain *d);
-
-#else /* !CONFIG_DOM0LESS_BOOT */
-
-static inline void create_domUs(void) {}
-static inline bool is_dom0less_mode(void)
-{
-    return false;
-}
-static inline void set_xs_domain(struct domain *d) {}
-
-#endif /* CONFIG_DOM0LESS_BOOT */
-
-#endif /* __ASM_DOM0LESS_BUILD_H_ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index be28060716..f291a5c1c7 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -12,6 +12,15 @@ config CORE_PARKING
 	bool
 	depends on NR_CPUS > 1
 
+config DOM0LESS_BOOT
+	bool "Dom0less boot support" if EXPERT
+	depends on HAS_DOM0LESS && HAS_DEVICE_TREE
+	default y
+	help
+	  Dom0less boot support enables Xen to create and start domU guests during
+	  Xen boot without the need of a control domain (Dom0), which could be
+	  present anyway.
+
 config GRANT_TABLE
 	bool "Grant table support" if EXPERT
 	default y
@@ -74,6 +83,9 @@ config HAS_DEVICE_TREE
 	bool
 	select LIBFDT
 
+config HAS_DOM0LESS
+	bool
+
 config HAS_DIT # Data Independent Timing
 	bool
 
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 7c549be38a..f3dafc9b81 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,5 +1,6 @@
 obj-y += bootfdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
+obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
new file mode 100644
index 0000000000..203b762e2c
--- /dev/null
+++ b/xen/common/device-tree/dom0less-build.c
@@ -0,0 +1,294 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static domid_t __initdata xs_domid = DOMID_INVALID;
+
+void __init set_xs_domain(struct domain *d)
+{
+    xs_domid = d->domain_id;
+    set_global_virq_handler(d, VIRQ_DOM_EXC);
+}
+
+bool __init is_dom0less_mode(void)
+{
+    struct bootmodules *mods = &bootinfo.modules;
+    struct bootmodule *mod;
+    unsigned int i;
+    bool dom0found = false;
+    bool domUfound = false;
+
+    /* Look into the bootmodules */
+    for ( i = 0 ; i < mods->nr_mods ; i++ )
+    {
+        mod = &mods->module[i];
+        /* Find if dom0 and domU kernels are present */
+        if ( mod->kind == BOOTMOD_KERNEL )
+        {
+            if ( mod->domU == false )
+            {
+                dom0found = true;
+                break;
+            }
+            else
+                domUfound = true;
+        }
+    }
+
+    /*
+     * If there is no dom0 kernel but at least one domU, then we are in
+     * dom0less mode
+     */
+    return ( !dom0found && domUfound );
+}
+
+static int __init alloc_xenstore_evtchn(struct domain *d)
+{
+    evtchn_alloc_unbound_t alloc;
+    int rc;
+
+    alloc.dom = d->domain_id;
+    alloc.remote_dom = xs_domid;
+    rc = evtchn_alloc_unbound(&alloc, 0);
+    if ( rc )
+    {
+        printk("Failed allocating event channel for domain\n");
+        return rc;
+    }
+
+    d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port;
+
+    return 0;
+}
+
+static void __init initialize_domU_xenstore(void)
+{
+    struct domain *d;
+
+    if ( xs_domid == DOMID_INVALID )
+        return;
+
+    for_each_domain( d )
+    {
+        uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN];
+        int rc;
+
+        if ( gfn == 0 )
+            continue;
+
+        if ( is_xenstore_domain(d) )
+            continue;
+
+        rc = alloc_xenstore_evtchn(d);
+        if ( rc < 0 )
+            panic("%pd: Failed to allocate xenstore_evtchn\n", d);
+
+        if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) )
+        {
+            ASSERT(gfn < UINT32_MAX);
+            gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn);
+        }
+    }
+}
+
+void __init create_domUs(void)
+{
+    struct dt_device_node *node;
+    const char *dom0less_iommu;
+    bool iommu = false;
+    const struct dt_device_node *cpupool_node,
+                                *chosen = dt_find_node_by_path("/chosen");
+    const char *llc_colors_str = NULL;
+
+    BUG_ON(chosen == NULL);
+    dt_for_each_child_node(chosen, node)
+    {
+        struct domain *d;
+        struct xen_domctl_createdomain d_cfg = {0};
+        unsigned int flags = 0U;
+        bool has_dtb = false;
+        uint32_t val;
+        int rc;
+
+        if ( !dt_device_is_compatible(node, "xen,domain") )
+            continue;
+
+        if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
+            panic("No more domain IDs available\n");
+
+        d_cfg.max_evtchn_port = 1023;
+        d_cfg.max_grant_frames = -1;
+        d_cfg.max_maptrack_frames = -1;
+        d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version);
+
+        if ( dt_property_read_u32(node, "capabilities", &val) )
+        {
+            if ( val & ~DOMAIN_CAPS_MASK )
+                panic("Invalid capabilities (%"PRIx32")\n", val);
+
+            if ( val & DOMAIN_CAPS_CONTROL )
+                flags |= CDF_privileged;
+
+            if ( val & DOMAIN_CAPS_HARDWARE )
+            {
+                if ( hardware_domain )
+                    panic("Only 1 hardware domain can be specified! (%pd)\n",
+                            hardware_domain);
+
+#ifdef CONFIG_GRANT_TABLE
+                d_cfg.max_grant_frames = gnttab_dom0_frames();
+#endif
+                d_cfg.max_evtchn_port = -1;
+                flags |= CDF_hardware;
+                iommu = true;
+            }
+
+            if ( val & DOMAIN_CAPS_XENSTORE )
+            {
+                if ( xs_domid != DOMID_INVALID )
+                    panic("Only 1 xenstore domain can be specified! (%u)\n",
+                            xs_domid);
+
+                d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain;
+                d_cfg.max_evtchn_port = -1;
+            }
+        }
+
+        if ( dt_find_property(node, "xen,static-mem", NULL) )
+        {
+            if ( llc_coloring_enabled )
+                panic("LLC coloring and static memory are incompatible\n");
+
+            flags |= CDF_staticmem;
+        }
+
+        if ( dt_property_read_bool(node, "direct-map") )
+        {
+            if ( !(flags & CDF_staticmem) )
+                panic("direct-map is not valid for domain %s without static allocation.\n",
+                      dt_node_name(node));
+
+            flags |= CDF_directmap;
+        }
+
+        if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) )
+            panic("Missing property 'cpus' for domain %s\n",
+                  dt_node_name(node));
+
+        if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) )
+        {
+            if ( flags & CDF_hardware )
+                panic("Don't specify passthrough for hardware domain\n");
+
+            if ( !strcmp(dom0less_iommu, "enabled") )
+                iommu = true;
+        }
+
+        if ( (flags & CDF_hardware) && !(flags & CDF_directmap) &&
+             !iommu_enabled )
+            panic("non-direct mapped hardware domain requires iommu\n");
+
+        if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") )
+        {
+            if ( flags & CDF_hardware )
+                panic("\"multiboot,device-tree\" incompatible with hardware domain\n");
+
+            has_dtb = true;
+        }
+
+        if ( iommu_enabled && (iommu || has_dtb) )
+            d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+
+        /* Get the optional property domain-cpupool */
+        cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
+        if ( cpupool_node )
+        {
+            int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
+            if ( pool_id < 0 )
+                panic("Error getting cpupool id from domain-cpupool (%d)\n",
+                      pool_id);
+            d_cfg.cpupool_id = pool_id;
+        }
+
+        if ( dt_property_read_u32(node, "max_grant_version", &val) )
+            d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val);
+
+        if ( dt_property_read_u32(node, "max_grant_frames", &val) )
+        {
+            if ( val > INT32_MAX )
+                panic("max_grant_frames (%"PRIu32") overflow\n", val);
+            d_cfg.max_grant_frames = val;
+        }
+
+        if ( dt_property_read_u32(node, "max_maptrack_frames", &val) )
+        {
+            if ( val > INT32_MAX )
+                panic("max_maptrack_frames (%"PRIu32") overflow\n", val);
+            d_cfg.max_maptrack_frames = val;
+        }
+
+        dt_property_read_string(node, "llc-colors", &llc_colors_str);
+        if ( !llc_coloring_enabled && llc_colors_str )
+            panic("'llc-colors' found, but LLC coloring is disabled\n");
+
+        arch_create_domUs(node, &d_cfg, flags);
+
+        /*
+         * The variable max_init_domid is initialized with zero, so here it's
+         * very important to use the pre-increment operator to call
+         * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
+         */
+        d = domain_create(++max_init_domid, &d_cfg, flags);
+        if ( IS_ERR(d) )
+            panic("Error creating domain %s (rc = %ld)\n",
+                  dt_node_name(node), PTR_ERR(d));
+
+        if ( llc_coloring_enabled &&
+             (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) )
+            panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
+                  dt_node_name(node), rc);
+
+        d->is_console = true;
+        dt_device_set_used_by(node, d->domain_id);
+
+        rc = construct_domU(d, node);
+        if ( rc )
+            panic("Could not set up domain %s (rc = %d)\n",
+                  dt_node_name(node), rc);
+
+        if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain )
+            set_xs_domain(d);
+    }
+
+    if ( need_xenstore && xs_domid == DOMID_INVALID )
+        panic("xenstore requested, but xenstore domain not present\n");
+
+    initialize_domU_xenstore();
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
new file mode 100644
index 0000000000..ef2073d802
--- /dev/null
+++ b/xen/include/asm-generic/dom0less-build.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __ASM_GENERIC_DOM0LESS_BUILD_H__
+#define __ASM_GENERIC_DOM0LESS_BUILD_H__
+
+#include 
+
+struct domain;
+
+#ifdef CONFIG_DOM0LESS_BOOT
+
+#include 
+
+struct dt_device_node;
+
+/* TODO: remove both when construct_domU() will be moved to common. */
+#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
+extern bool need_xenstore;
+
+void create_domUs(void);
+bool is_dom0less_mode(void);
+void set_xs_domain(struct domain *d);
+
+int construct_domU(struct domain *d, const struct dt_device_node *node);
+
+void arch_create_domUs(struct dt_device_node *node,
+                       struct xen_domctl_createdomain *d_cfg,
+                       unsigned int flags);
+
+#else /* !CONFIG_DOM0LESS_BOOT */
+
+static inline void create_domUs(void) {}
+static inline bool is_dom0less_mode(void)
+{
+    return false;
+}
+static inline void set_xs_domain(struct domain *d) {}
+
+#endif /* CONFIG_DOM0LESS_BOOT */
+
+#endif /* __ASM_GENERIC_DOM0LESS_BUILD_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 05 18:10:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 18:10:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976211.1363460 (Exim 4.92)
	(envelope-from )
	id 1uC0HB-000749-Jy; Mon, 05 May 2025 18:10:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976211.1363460; Mon, 05 May 2025 18:10: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 1uC0HB-00073D-Eo; Mon, 05 May 2025 18:10:49 +0000
Received: by outflank-mailman (input) for mailman id 976211;
 Mon, 05 May 2025 18:10:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC0HA-000675-0c
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 18:10:48 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4432708b-29dc-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 20:10:46 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5e5e63162a0so7249287a12.3
 for ; Mon, 05 May 2025 11:10:46 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189146fcbsm530372366b.34.2025.05.05.11.10.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 11:10: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" 
X-Inumbo-ID: 4432708b-29dc-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746468646; x=1747073446; 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;
        bh=+ncF17W3CTTSQUsFN9MAsJJRH+seNVqW8TKw5sOfUUk=;
        b=CICBgHkEBEKNYhJSrescW1P+Pb2gsSuSNqQkFkZJlOfwMLvWnUoK266xt5VRkj8Rgs
         VvGRVju3LqgIZ/1UeFdYB73Z569Lg3lB8yjjEc4rJiGAmsWSp1ZUAtubZ5CmfKgvh05g
         1BH3gT2Bhl4OpsodzzgH0bfvhGZPvDIRfsAdV6jTCVQjRFF/Z6HT5J//lmPqkae433CS
         Dp8JwCLn9wSpSAdobO6N7ag4s+nrNQOJ/MqoDaHyoRlsDcqRNFUG6MEolM26YFZhLKfr
         xzYt4sNhrC7JMU32njTIW2EcBDF1QgYkQlRSOf+n3nYvAqcEWFxJkRzW8fpJa/RaupvR
         K6pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746468646; x=1747073446;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+ncF17W3CTTSQUsFN9MAsJJRH+seNVqW8TKw5sOfUUk=;
        b=usn77UfCn7oiEQd1JiG0rEax4WqxgpFQTBo6UnR1UTo7EGGyx0ZqG3K+8fEFm7KdcX
         nY5NqcrqN/NcI6OKDyLulGoKX+HpNaqCxnzltWsr4oRpI0wnC9iK86lmXHm70TCYNHXg
         DmAna6UzLXzLcTLjz+0t1YC2vprb8wWkDanjRD2yuZZ3MZDHUz1nXs85oFKDNjiXb1Cv
         Jk0QNfncSx+V12KWiV7+RuydOK7ZhKTNUv0Yuy2c7DoRwFtYU5tni1/wIqQtIc98lBvF
         s3f8Egi13BVh1s05tATMUmFnmNUroq7sLV4dBGYDFx52v4PciBSb3tjZzIK2//G0WI0T
         kKzg==
X-Gm-Message-State: AOJu0YwuxYYFs9Nw/DNBXJzIIpZ90Ban3DdnWEZU0Kr1kK/4c9MCQ7jK
	hyBdUva+6A0tO1D8AElwV+m/7jqS6uq4OmMJLx/K0RvTbEsL4jLMM/JIcg==
X-Gm-Gg: ASbGncuIS0Bl+gB3H1JWSz1WzRnPnA7zRHSx/ssS1BrQWnDFtH7+Yu5l5KA+6YAiQVw
	tGc+KWLdasGts9sws/eTBto6INrPyky4XaUJBrxWqxdYZKcAstnirSUhkAn74JDNAovkwE/Bhtx
	edvhCyoVkmukCPI5O2gqjznUP8H6SP8TurUHMQDFwN3xOdkyMTmKsuIwJObde3ig0YPZrzBrVUz
	FdSb9I23rEbXf9sxq6IlceeP9fLTeLsAYDElSZZazvypctARHqKq46E4kvT6Iud7z84P6poLCA+
	DJ87e5FoUzM2HM0NQr4rS2qgKW0oYTcEQZIEk+eKtfhc1u7MEvgoQueflbp8M0z6GmKIobgugmE
	f0tfmZ0+M1Q==
X-Google-Smtp-Source: AGHT+IHlpoXXo/hazRC6lYETJ0cFIISQhotBD+PG0qpU6XO/GSq2Cm/zo7gnZ1IqTpTuCaZGj1xiLQ==
X-Received: by 2002:a17:906:a0c:b0:ad1:8e69:e838 with SMTP id a640c23a62f3a-ad18e69e87bmr776144866b.52.1746468645332;
        Mon, 05 May 2025 11:10:45 -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 v4 6/8] xen/common: dom0less: introduce common kernel.c
Date: Mon,  5 May 2025 20:10:36 +0200
Message-ID: <854e4ce870e07add71a4fe429bee1e83a5f6958d.1746468003.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The following functions don't have arch specific things so it is moved to
common:
- kernel_prboe()
- kernel_load()
- output_length()

Functions necessary for dom0less are only moved.

The following changes are done:
- Swap __init and return type of kernel_decompress() function to be
  consistent with defintions of functions in other files. The same
  for output_length().
- Wrap by "ifdef CONFIG_ARM" the call of kernel_uimage_probe() in
  kernel_probe() as uImage isn't really used nowadays thereby leave
  kernel_uimage_probe() call here just for compatability with Arm code.
- Introduce kernel_zimage_probe() to cover the case that arch can have
  different zimage header.
- Add ASSERT() for kernel_load() to check that it argument isn't NULL.
- Make kernel_uimage_probe() non-static in Arm's code as it is used in
  common/kernel.c.

Introduce CONFIG_DOMAIN_BUILD_HELPERS to not provide stubs for archs
which don't provide enough functionality to enable it.
Select CONFIG_DOMAIN_BUILD_HELPERS for CONFIG_ARM as only Arm supports
it, at the moment.

Signed-off-by: Oleksii Kurochko 
---
Change in v4:
 - Drop 'help' for CONFIG_DOMAIN_BUILD_HELPERS to make
   CONFIG_DOMAIN_BUILD_HELPERS silent option.
 - Remove asm-generic/kernel.h as it is a duplication of xen/fdt-kernel.h and
   I just missed to remove it earler after xen/fdt-kernel.h has been
   introduced.
---
Change in v3:
 - Empty line after license tag for newly introduced files.
---
Change in v2:
 - Drop inclusion of asm/kernel.h in kernel.c as everything necessary has
   been moved to xen/fdt-kernel.h.
---
 xen/arch/arm/Kconfig            |   1 +
 xen/arch/arm/kernel.c           | 221 +----------------------------
 xen/common/Kconfig              |   5 +-
 xen/common/device-tree/Makefile |   1 +
 xen/common/device-tree/kernel.c | 242 ++++++++++++++++++++++++++++++++
 xen/include/xen/fdt-kernel.h    |  13 ++
 6 files changed, 267 insertions(+), 216 deletions(-)
 create mode 100644 xen/common/device-tree/kernel.c

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index d0e0a7753c..3321d89068 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -11,6 +11,7 @@ config ARM_64
 
 config ARM
 	def_bool y
+	select DOMAIN_BUILD_HELPERS
 	select FUNCTION_ALIGNMENT_4B
 	select GENERIC_UART_INIT
 	select HAS_ALTERNATIVE if HAS_VMAP
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index aea8f44413..cb1efb19e7 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -162,105 +162,6 @@ static void __init kernel_zimage_load(struct kernel_info *info)
     iounmap(kernel);
 }
 
-static __init uint32_t output_length(char *image, unsigned long image_len)
-{
-    return *(uint32_t *)&image[image_len - 4];
-}
-
-static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset)
-{
-    char *output, *input;
-    char magic[2];
-    int rc;
-    unsigned int kernel_order_out;
-    paddr_t output_size;
-    struct page_info *pages;
-    mfn_t mfn;
-    int i;
-    paddr_t addr = mod->start;
-    paddr_t size = mod->size;
-
-    if ( size < offset )
-        return -EINVAL;
-
-    /*
-     * It might be that gzip header does not appear at the start address
-     * (e.g. in case of compressed uImage) so take into account offset to
-     * gzip header.
-     */
-    addr += offset;
-    size -= offset;
-
-    if ( size < 2 )
-        return -EINVAL;
-
-    copy_from_paddr(magic, addr, sizeof(magic));
-
-    /* only gzip is supported */
-    if ( !gzip_check(magic, size) )
-        return -EINVAL;
-
-    input = ioremap_cache(addr, size);
-    if ( input == NULL )
-        return -EFAULT;
-
-    output_size = output_length(input, size);
-    kernel_order_out = get_order_from_bytes(output_size);
-    pages = alloc_domheap_pages(NULL, kernel_order_out, 0);
-    if ( pages == NULL )
-    {
-        iounmap(input);
-        return -ENOMEM;
-    }
-    mfn = page_to_mfn(pages);
-    output = vmap_contig(mfn, 1 << kernel_order_out);
-
-    rc = perform_gunzip(output, input, size);
-    clean_dcache_va_range(output, output_size);
-    iounmap(input);
-    vunmap(output);
-
-    if ( rc )
-    {
-        free_domheap_pages(pages, kernel_order_out);
-        return rc;
-    }
-
-    mod->start = page_to_maddr(pages);
-    mod->size = output_size;
-
-    /*
-     * Need to free pages after output_size here because they won't be
-     * freed by discard_initial_modules
-     */
-    i = PFN_UP(output_size);
-    for ( ; i < (1 << kernel_order_out); i++ )
-        free_domheap_page(pages + i);
-
-    /*
-     * When using static heap feature, don't give bootmodules memory back to
-     * the heap allocator
-     */
-    if ( using_static_heap )
-        return 0;
-
-    /*
-     * When freeing the kernel, we need to pass the module start address and
-     * size as they were before taking an offset to gzip header into account,
-     * so that the entire region will be freed.
-     */
-    addr -= offset;
-    size += offset;
-
-    /*
-     * Free the original kernel, update the pointers to the
-     * decompressed kernel
-     */
-    fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
-
-    return 0;
-}
-
 /*
  * Uimage CPU Architecture Codes
  */
@@ -273,8 +174,8 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset)
 /*
  * Check if the image is a uImage and setup kernel_info
  */
-static int __init kernel_uimage_probe(struct kernel_info *info,
-                                      struct bootmodule *mod)
+int __init kernel_uimage_probe(struct kernel_info *info,
+                               struct bootmodule *mod)
 {
     struct {
         __be32 magic;   /* Image Header Magic Number */
@@ -504,130 +405,20 @@ static int __init kernel_zimage32_probe(struct kernel_info *info,
     return 0;
 }
 
-int __init kernel_probe(struct kernel_info *info,
-                        const struct dt_device_node *domain)
+int __init kernel_zimage_probe(struct kernel_info *info, paddr_t addr,
+                               paddr_t size)
 {
-    struct bootmodule *mod = NULL;
-    struct bootcmdline *cmd = NULL;
-    struct dt_device_node *node;
-    u64 kernel_addr, initrd_addr, dtb_addr, size;
     int rc;
 
-    /*
-     * We need to initialize start to 0. This field may be populated during
-     * kernel_xxx_probe() if the image has a fixed entry point (for e.g.
-     * uimage.ep).
-     * We will use this to determine if the image has a fixed entry point or
-     * the load address should be used as the start address.
-     */
-    info->entry = 0;
-
-    /* domain is NULL only for the hardware domain */
-    if ( domain == NULL )
-    {
-        ASSERT(is_hardware_domain(info->d));
-
-        mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
-
-        info->kernel_bootmodule = mod;
-        info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
-
-        cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
-        if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
-    }
-    else
-    {
-        const char *name = NULL;
-
-        dt_for_each_child_node(domain, node)
-        {
-            if ( dt_device_is_compatible(node, "multiboot,kernel") )
-            {
-                u32 len;
-                const __be32 *val;
-
-                val = dt_get_property(node, "reg", &len);
-                dt_get_range(&val, node, &kernel_addr, &size);
-                mod = boot_module_find_by_addr_and_kind(
-                        BOOTMOD_KERNEL, kernel_addr);
-                info->kernel_bootmodule = mod;
-            }
-            else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
-            {
-                u32 len;
-                const __be32 *val;
-
-                val = dt_get_property(node, "reg", &len);
-                dt_get_range(&val, node, &initrd_addr, &size);
-                info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
-                        BOOTMOD_RAMDISK, initrd_addr);
-            }
-            else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
-            {
-                uint32_t len;
-                const __be32 *val;
-
-                val = dt_get_property(node, "reg", &len);
-                if ( val == NULL )
-                    continue;
-                dt_get_range(&val, node, &dtb_addr, &size);
-                info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
-                        BOOTMOD_GUEST_DTB, dtb_addr);
-            }
-            else
-                continue;
-        }
-        name = dt_node_name(domain);
-        cmd = boot_cmdline_find_by_name(name);
-        if ( cmd )
-            info->cmdline = &cmd->cmdline[0];
-    }
-    if ( !mod || !mod->size )
-    {
-        printk(XENLOG_ERR "Missing kernel boot module?\n");
-        return -ENOENT;
-    }
-
-    printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
-           info->d, info->kernel_bootmodule->start);
-    if ( info->initrd_bootmodule )
-        printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
-               info->initrd_bootmodule->start);
-
-    /*
-     * uImage header always appears at the top of the image (even compressed),
-     * so it needs to be probed first. Note that in case of compressed uImage,
-     * kernel_decompress is called from kernel_uimage_probe making the function
-     * self-containing (i.e. fall through only in case of a header not found).
-     */
-    rc = kernel_uimage_probe(info, mod);
-    if ( rc != -ENOENT )
-        return rc;
-
-    /*
-     * If it is a gzip'ed image, 32bit or 64bit, uncompress it.
-     * At this point, gzip header appears (if at all) at the top of the image,
-     * so pass 0 as an offset.
-     */
-    rc = kernel_decompress(mod, 0);
-    if ( rc && rc != -EINVAL )
-        return rc;
-
 #ifdef CONFIG_ARM_64
-    rc = kernel_zimage64_probe(info, mod->start, mod->size);
+    rc = kernel_zimage64_probe(info, addr, size);
     if (rc < 0)
 #endif
-        rc = kernel_zimage32_probe(info, mod->start, mod->size);
+        rc = kernel_zimage32_probe(info, addr, size);
 
     return rc;
 }
 
-void __init kernel_load(struct kernel_info *info)
-{
-    info->load(info);
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index f291a5c1c7..4bec78c6f2 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -14,13 +14,16 @@ config CORE_PARKING
 
 config DOM0LESS_BOOT
 	bool "Dom0less boot support" if EXPERT
-	depends on HAS_DOM0LESS && HAS_DEVICE_TREE
+	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
 	default y
 	help
 	  Dom0less boot support enables Xen to create and start domU guests during
 	  Xen boot without the need of a control domain (Dom0), which could be
 	  present anyway.
 
+config DOMAIN_BUILD_HELPERS
+	bool
+
 config GRANT_TABLE
 	bool "Grant table support" if EXPERT
 	default y
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index f3dafc9b81..e88a4d5799 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -4,3 +4,4 @@ obj-y += device-tree.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
+obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
new file mode 100644
index 0000000000..1bf3bbf64e
--- /dev/null
+++ b/xen/common/device-tree/kernel.c
@@ -0,0 +1,242 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static uint32_t __init output_length(char *image, unsigned long image_len)
+{
+    return *(uint32_t *)&image[image_len - 4];
+}
+
+int __init kernel_decompress(struct bootmodule *mod, uint32_t offset)
+{
+    char *output, *input;
+    char magic[2];
+    int rc;
+    unsigned int kernel_order_out;
+    paddr_t output_size;
+    struct page_info *pages;
+    mfn_t mfn;
+    int i;
+    paddr_t addr = mod->start;
+    paddr_t size = mod->size;
+
+    if ( size < offset )
+        return -EINVAL;
+
+    /*
+     * It might be that gzip header does not appear at the start address
+     * (e.g. in case of compressed uImage) so take into account offset to
+     * gzip header.
+     */
+    addr += offset;
+    size -= offset;
+
+    if ( size < 2 )
+        return -EINVAL;
+
+    copy_from_paddr(magic, addr, sizeof(magic));
+
+    /* only gzip is supported */
+    if ( !gzip_check(magic, size) )
+        return -EINVAL;
+
+    input = ioremap_cache(addr, size);
+    if ( input == NULL )
+        return -EFAULT;
+
+    output_size = output_length(input, size);
+    kernel_order_out = get_order_from_bytes(output_size);
+    pages = alloc_domheap_pages(NULL, kernel_order_out, 0);
+    if ( pages == NULL )
+    {
+        iounmap(input);
+        return -ENOMEM;
+    }
+    mfn = page_to_mfn(pages);
+    output = vmap_contig(mfn, 1 << kernel_order_out);
+
+    rc = perform_gunzip(output, input, size);
+    clean_dcache_va_range(output, output_size);
+    iounmap(input);
+    vunmap(output);
+
+    if ( rc )
+    {
+        free_domheap_pages(pages, kernel_order_out);
+        return rc;
+    }
+
+    mod->start = page_to_maddr(pages);
+    mod->size = output_size;
+
+    /*
+     * Need to free pages after output_size here because they won't be
+     * freed by discard_initial_modules
+     */
+    i = PFN_UP(output_size);
+    for ( ; i < (1 << kernel_order_out); i++ )
+        free_domheap_page(pages + i);
+
+    /*
+     * When using static heap feature, don't give bootmodules memory back to
+     * the heap allocator
+     */
+    if ( using_static_heap )
+        return 0;
+
+    /*
+     * When freeing the kernel, we need to pass the module start address and
+     * size as they were before taking an offset to gzip header into account,
+     * so that the entire region will be freed.
+     */
+    addr -= offset;
+    size += offset;
+
+    /*
+     * Free the original kernel, update the pointers to the
+     * decompressed kernel
+     */
+    fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
+
+    return 0;
+}
+
+int __init kernel_probe(struct kernel_info *info,
+                        const struct dt_device_node *domain)
+{
+    struct bootmodule *mod = NULL;
+    struct bootcmdline *cmd = NULL;
+    struct dt_device_node *node;
+    u64 kernel_addr, initrd_addr, dtb_addr, size;
+    int rc;
+
+    /*
+     * We need to initialize start to 0. This field may be populated during
+     * kernel_xxx_probe() if the image has a fixed entry point (for e.g.
+     * uimage.ep).
+     * We will use this to determine if the image has a fixed entry point or
+     * the load address should be used as the start address.
+     */
+    info->entry = 0;
+
+    /* domain is NULL only for the hardware domain */
+    if ( domain == NULL )
+    {
+        ASSERT(is_hardware_domain(info->d));
+
+        mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+
+        info->kernel_bootmodule = mod;
+        info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+
+        cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
+        if ( cmd )
+            info->cmdline = &cmd->cmdline[0];
+    }
+    else
+    {
+        const char *name = NULL;
+
+        dt_for_each_child_node(domain, node)
+        {
+            if ( dt_device_is_compatible(node, "multiboot,kernel") )
+            {
+                u32 len;
+                const __be32 *val;
+
+                val = dt_get_property(node, "reg", &len);
+                dt_get_range(&val, node, &kernel_addr, &size);
+                mod = boot_module_find_by_addr_and_kind(
+                        BOOTMOD_KERNEL, kernel_addr);
+                info->kernel_bootmodule = mod;
+            }
+            else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
+            {
+                u32 len;
+                const __be32 *val;
+
+                val = dt_get_property(node, "reg", &len);
+                dt_get_range(&val, node, &initrd_addr, &size);
+                info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
+                        BOOTMOD_RAMDISK, initrd_addr);
+            }
+            else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
+            {
+                uint32_t len;
+                const __be32 *val;
+
+                val = dt_get_property(node, "reg", &len);
+                if ( val == NULL )
+                    continue;
+                dt_get_range(&val, node, &dtb_addr, &size);
+                info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
+                        BOOTMOD_GUEST_DTB, dtb_addr);
+            }
+            else
+                continue;
+        }
+        name = dt_node_name(domain);
+        cmd = boot_cmdline_find_by_name(name);
+        if ( cmd )
+            info->cmdline = &cmd->cmdline[0];
+    }
+    if ( !mod || !mod->size )
+    {
+        printk(XENLOG_ERR "Missing kernel boot module?\n");
+        return -ENOENT;
+    }
+
+    printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
+           info->d, info->kernel_bootmodule->start);
+    if ( info->initrd_bootmodule )
+        printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
+               info->initrd_bootmodule->start);
+
+    /*
+     * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
+     * call here just for compatability with Arm code.
+     */
+#ifdef CONFIG_ARM
+    /*
+     * uImage header always appears at the top of the image (even compressed),
+     * so it needs to be probed first. Note that in case of compressed uImage,
+     * kernel_decompress is called from kernel_uimage_probe making the function
+     * self-containing (i.e. fall through only in case of a header not found).
+     */
+    rc = kernel_uimage_probe(info, mod);
+    if ( rc != -ENOENT )
+        return rc;
+#endif
+
+    /*
+     * If it is a gzip'ed image, 32bit or 64bit, uncompress it.
+     * At this point, gzip header appears (if at all) at the top of the image,
+     * so pass 0 as an offset.
+     */
+    rc = kernel_decompress(mod, 0);
+    if ( rc && rc != -EINVAL )
+        return rc;
+
+    rc = kernel_zimage_probe(info, mod->start, mod->size);
+
+    return rc;
+}
+
+void __init kernel_load(struct kernel_info *info)
+{
+    ASSERT(info && info->load);
+
+    info->load(info);
+}
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 516cc68e90..7a6cd67c22 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -120,6 +120,19 @@ int kernel_probe(struct kernel_info *info, const struct dt_device_node *domain);
  */
 void kernel_load(struct kernel_info *info);
 
+int kernel_decompress(struct bootmodule *mod, uint32_t offset);
+
+int kernel_zimage_probe(struct kernel_info *info, paddr_t addr, paddr_t size);
+
+/*
+ * uImage isn't really used nowadays thereby leave kernel_uimage_probe()
+ * call here just for compatability with Arm code.
+ */
+#ifdef CONFIG_ARM
+struct bootmodule;
+int kernel_uimage_probe(struct kernel_info *info, struct bootmodule *mod);
+#endif
+
 #endif /* __XEN_FDT_KERNEL_H__ */
 
 /*
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 05 18:10:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 18:10:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976212.1363471 (Exim 4.92)
	(envelope-from )
	id 1uC0HE-0007UR-77; Mon, 05 May 2025 18:10:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976212.1363471; Mon, 05 May 2025 18:10: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 1uC0HE-0007UA-2m; Mon, 05 May 2025 18:10:52 +0000
Received: by outflank-mailman (input) for mailman id 976212;
 Mon, 05 May 2025 18:10:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC0HB-000675-FF
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 18:10:49 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 44ef776e-29dc-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 20:10:47 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ac2902f7c2aso755614966b.1
 for ; Mon, 05 May 2025 11:10:47 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189146fcbsm530372366b.34.2025.05.05.11.10.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 11:10: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" 
X-Inumbo-ID: 44ef776e-29dc-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746468647; x=1747073447; 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;
        bh=xpVFgkcPQ6fPs9H/PlKDyxVc95bTNIcIchbqC+uj+ME=;
        b=KvPr6GdmCdHQV5/iQXHYFee5+Fp3kRRpC4TBMrGjvWWbGmar2xlTAj/dcNfdGrVmRj
         6cMQJkfoM1ogvIVMjo+ypnxnDDvsecCWfQRaeOfINzkmUTgcZHwwa2tfhDU3xUOWo5rx
         iqdjJFzxtBiQp9tFhNGVFiGopKVnsmZP5nvDtnchV73w2FkCuysAfAEf0DaqD0478R8P
         gw8HAMHCplWY4rz14VuLUbyHjgCzwac42JbLZq4bLmM5Bq0r4LwQhfiuI5q3jafeR04D
         G46XKHwE64xfPkvqe2iUyYqfAD4IRzW5dGKzEImCMcowrwn0XXRAHS+BEQhRf3bOTuiz
         PbRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746468647; x=1747073447;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=xpVFgkcPQ6fPs9H/PlKDyxVc95bTNIcIchbqC+uj+ME=;
        b=LnY/cb2IYhi4kK3I7hoJdp2yoLpPMFAEteOtMnrCS9ZpkjHIqh996jj3ug+Kljj92B
         rjTaIbf9eIKOkegj/h5hHGKGg9Lylu2H7hpdYqoF9uwsnvMXxu2lcamYNFsXOrvrBphd
         zTFNKbUxGNsnrMmj9X2Rw8bWM2vVqbt2FtimcB+D5qWt6UnTtxX2pI3Ar2sp5aZp2589
         K6DqHZw8lmUgoZUGJSaYYqUKcQInVOPU4yGmFOSycDkYd6M5oLdAqKCf9r654rEMqwvt
         vKAs8GSwZgXSoNLPImk+B3hxSKE0DkXh8Dp0sb6tABl2HttixAYWW/tBJ+zgaK8WrkQ4
         RUqw==
X-Gm-Message-State: AOJu0YyztQRKYWtSbCqpuHRngLELjPY+00ObRAlXDq6QroaJILrusmVk
	pa9nByWXV3HVigzynq+69HX64R83NU4m4oTQg/l8RSpwLNzHNFwMo6pkSw==
X-Gm-Gg: ASbGnctm6CKv5rD5DI+lJSdYWJPrX+AOo6u5hJY4LpTffRnxn2poerr6uWEe9Kk6NAK
	dbcip/IQi8axTqjYiTZOjM9f5ZIWXHzJTse1uFL5ALD9StUx9/MjSZckHt/bz9T10RYynnLgccY
	iPVHOJVDCt9/pmShkH8SaBZ3luMWDHuYo+E7xYf8Q/qMrQC8z4ILDHrQOwSp7v+QzX19ZjVylxt
	bTEYZu2yC2ycMMx3bae96usBU77eQNCzWtvQ4kU8ijaC4BXH42Oq5Ok3OpkB78dFNQBdkjiGP2i
	Vj4CqIsWeSJlFVmRQRyXCV1zNS7J0q1Z6xATyoJr+s/A/659fWv2gp16msp2R50zYL/xEMQkbEl
	dgFBoraoO0g==
X-Google-Smtp-Source: AGHT+IGRhBzizUlE8RqkE341hku/cyOcX635xFjrJDUInJP70tQYN4dzmbu3NGRJdn/q9DY674auoQ==
X-Received: by 2002:a17:907:7f8b:b0:acb:63a4:e8e5 with SMTP id a640c23a62f3a-ad1a48bc622mr780802066b.6.1746468646378;
        Mon, 05 May 2025 11:10:46 -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 v4 7/8] xen/common: dom0less: introduce common domain-build.c
Date: Mon,  5 May 2025 20:10:37 +0200
Message-ID: <0bfc572f0d82e9d81bbc07bab5b6b7fb0d7634f8.1746468003.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Some functions of Arm's domain_build.c could be reused by dom0less or other
features connected to domain construction/build.

The following functions are moved to common:
- get_allocation_size().
- allocate_domheap_memory().
- guest_map_pages().
- allocate_bank_memory().
- add_hwdom_free_regions().
- find_unallocated_memory().
- allocate_memory().
- dtb_load().
- initrd_load().

Prototype of dtb_load() and initrd_load() is updated to recieve a pointer
to copy_to_guest_phys() as some archs require
copy_to_guest_phys_fluch_dcache().

Update arm/include/asm/Makefile to generate  domain-build.h for Arm as it is
used by domain-build.c.

Signed-off-by: Oleksii Kurochko 
---
Change in v4:
 - Move declaration of alloc_*() and get_allocation_size() to xen/fdt-domain-build.h.
 - Allocate gnttab using membanks_xzalloc(1, MEMORY) to have gnttab->max_banks
   and gnttab->type properly set.
 - Allocate hwdom_free_mem using membanks_xzalloc(NR_MEM_BANKS, MEMORY) to
   have hwdom_free_mem->type proprely set.
 - Drop introduction of function callbacktype: copy_to_guest_phys_cb() as it
   is already introduced in xen/fdt-domain-build.h.
 - Return original panic messages at the end of initrd_load() as I missed to
   align them with the newest staging. There were changed in the patch:
   "xen/arm: Don't blindly print hwdom in generic panic messages".
---
Change in v3:
 - Nothing changed. Only rebase.
---
Change in v2:
 - Use xen/fdt-domain-build.h instead of asm/domain_build.h.
---
 xen/arch/arm/domain_build.c             | 397 +-----------------------
 xen/arch/arm/include/asm/domain_build.h |  10 -
 xen/common/device-tree/Makefile         |   1 +
 xen/common/device-tree/domain-build.c   | 395 +++++++++++++++++++++++
 xen/include/xen/fdt-domain-build.h      |  40 +++
 5 files changed, 438 insertions(+), 405 deletions(-)
 create mode 100644 xen/common/device-tree/domain-build.c

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9d649b06b3..df29619c40 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -120,18 +120,6 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
     return vcpu_create(dom0, 0);
 }
 
-unsigned int __init get_allocation_size(paddr_t size)
-{
-    /*
-     * get_order_from_bytes returns the order greater than or equal to
-     * the given size, but we need less than or equal. Adding one to
-     * the size pushes an evenly aligned size into the next order, so
-     * we can then unconditionally subtract 1 from the order which is
-     * returned.
-     */
-    return get_order_from_bytes(size + 1) - 1;
-}
-
 /*
  * Insert the given pages into a memory bank, banks are ordered by address.
  *
@@ -418,98 +406,6 @@ static void __init allocate_memory_11(struct domain *d,
     }
 }
 
-bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
-                                    alloc_domheap_mem_cb cb, void *extra)
-{
-    unsigned int max_order = UINT_MAX;
-
-    while ( tot_size > 0 )
-    {
-        unsigned int order = get_allocation_size(tot_size);
-        struct page_info *pg;
-
-        order = min(max_order, order);
-
-        pg = alloc_domheap_pages(d, order, 0);
-        if ( !pg )
-        {
-            /*
-             * If we can't allocate one page, then it is unlikely to
-             * succeed in the next iteration. So bail out.
-             */
-            if ( !order )
-                return false;
-
-            /*
-             * If we can't allocate memory with order, then it is
-             * unlikely to succeed in the next iteration.
-             * Record the order - 1 to avoid re-trying.
-             */
-            max_order = order - 1;
-            continue;
-        }
-
-        if ( !cb(d, pg, order, extra) )
-            return false;
-
-        tot_size -= (1ULL << (PAGE_SHIFT + order));
-    }
-
-    return true;
-}
-
-static bool __init guest_map_pages(struct domain *d, struct page_info *pg,
-                                   unsigned int order, void *extra)
-{
-    gfn_t *sgfn = (gfn_t *)extra;
-    int res;
-
-    BUG_ON(!sgfn);
-    res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order);
-    if ( res )
-    {
-        dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
-        return false;
-    }
-
-    *sgfn = gfn_add(*sgfn, 1UL << order);
-
-    return true;
-}
-
-bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
-                                 paddr_t tot_size)
-{
-    struct membanks *mem = kernel_info_get_mem(kinfo);
-    struct domain *d = kinfo->d;
-    struct membank *bank;
-
-    /*
-     * allocate_bank_memory can be called with a tot_size of zero for
-     * the second memory bank. It is not an error and we can safely
-     * avoid creating a zero-size memory bank.
-     */
-    if ( tot_size == 0 )
-        return true;
-
-    bank = &mem->bank[mem->nr_banks];
-    bank->start = gfn_to_gaddr(sgfn);
-    bank->size = tot_size;
-
-    /*
-     * Allocate pages from the heap until tot_size is zero and map them to the
-     * guest using guest_map_pages, passing the starting gfn as extra parameter
-     * for the map operation.
-     */
-    if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) )
-        return false;
-
-    mem->nr_banks++;
-    kinfo->unassigned_mem -= bank->size;
-
-    return true;
-}
-
 /*
  * When PCI passthrough is available we want to keep the
  * "linux,pci-domain" in sync for every host bridge.
@@ -900,226 +796,6 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
     return 0;
 }
 
-static int __init add_hwdom_free_regions(unsigned long s_gfn,
-                                         unsigned long e_gfn, void *data)
-{
-    struct membanks *free_regions = data;
-    paddr_t start, size;
-    paddr_t s = pfn_to_paddr(s_gfn);
-    paddr_t e = pfn_to_paddr(e_gfn);
-    unsigned int i, j;
-
-    if ( free_regions->nr_banks >= free_regions->max_banks )
-        return 0;
-
-    /*
-     * Both start and size of the free region should be 2MB aligned to
-     * potentially allow superpage mapping.
-     */
-    start = (s + SZ_2M - 1) & ~(SZ_2M - 1);
-    if ( start > e )
-        return 0;
-
-    /*
-     * e is actually "end-1" because it is called by rangeset functions
-     * which are inclusive of the last address.
-     */
-    e += 1;
-    size = (e - start) & ~(SZ_2M - 1);
-
-    /* Find the insert position (descending order). */
-    for ( i = 0; i < free_regions->nr_banks ; i++ )
-        if ( size > free_regions->bank[i].size )
-            break;
-
-    /* Move the other banks to make space. */
-    for ( j = free_regions->nr_banks; j > i ; j-- )
-    {
-        free_regions->bank[j].start = free_regions->bank[j - 1].start;
-        free_regions->bank[j].size = free_regions->bank[j - 1].size;
-    }
-
-    free_regions->bank[i].start = start;
-    free_regions->bank[i].size = size;
-    free_regions->nr_banks++;
-
-    return 0;
-}
-
-/*
- * Find unused regions of Host address space which can be exposed to domain
- * using the host memory layout. In order to calculate regions we exclude every
- * region passed in mem_banks from the Host RAM.
- */
-static int __init find_unallocated_memory(const struct kernel_info *kinfo,
-                                          const struct membanks *mem_banks[],
-                                          unsigned int nr_mem_banks,
-                                          struct membanks *free_regions,
-                                          int (*cb)(unsigned long s_gfn,
-                                                    unsigned long e_gfn,
-                                                    void *data))
-{
-    const struct membanks *mem = bootinfo_get_mem();
-    struct rangeset *unalloc_mem;
-    paddr_t start, end;
-    unsigned int i, j;
-    int res;
-
-    ASSERT(domain_use_host_layout(kinfo->d));
-
-    unalloc_mem = rangeset_new(NULL, NULL, 0);
-    if ( !unalloc_mem )
-        return -ENOMEM;
-
-    /* Start with all available RAM */
-    for ( i = 0; i < mem->nr_banks; i++ )
-    {
-        start = mem->bank[i].start;
-        end = mem->bank[i].start + mem->bank[i].size;
-        res = rangeset_add_range(unalloc_mem, PFN_DOWN(start),
-                                 PFN_DOWN(end - 1));
-        if ( res )
-        {
-            printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n",
-                   start, end);
-            goto out;
-        }
-    }
-
-    /* Remove all regions listed in mem_banks */
-    for ( i = 0; i < nr_mem_banks; i++ )
-        for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
-        {
-            start = mem_banks[i]->bank[j].start;
-
-            /* Shared memory banks can contain INVALID_PADDR as start */
-            if ( INVALID_PADDR == start )
-                continue;
-
-            end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size;
-            res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start),
-                                        PFN_DOWN(end - 1));
-            if ( res )
-            {
-                printk(XENLOG_ERR
-                       "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n",
-                       start, end, res);
-                goto out;
-            }
-        }
-
-    start = 0;
-    end = (1ULL << p2m_ipa_bits) - 1;
-    res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end),
-                                 cb, free_regions);
-    if ( res )
-        free_regions->nr_banks = 0;
-    else if ( !free_regions->nr_banks )
-        res = -ENOENT;
-
-out:
-    rangeset_destroy(unalloc_mem);
-
-    return res;
-}
-
-void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
-{
-    struct membanks *mem = kernel_info_get_mem(kinfo);
-    unsigned int i, nr_banks = GUEST_RAM_BANKS;
-    struct membanks *hwdom_free_mem = NULL;
-
-    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
-           /* Don't want format this as PRIpaddr (16 digit hex) */
-           (unsigned long)(kinfo->unassigned_mem >> 20), d);
-
-    mem->nr_banks = 0;
-    /*
-     * Use host memory layout for hwdom. Only case for this is when LLC coloring
-     * is enabled.
-     */
-    if ( is_hardware_domain(d) )
-    {
-        struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
-        /*
-         * Exclude the following regions:
-         * 1) Remove reserved memory
-         * 2) Grant table assigned to hwdom
-         */
-        const struct membanks *mem_banks[] = {
-            bootinfo_get_reserved_mem(),
-            gnttab,
-        };
-
-        if ( !gnttab )
-            goto fail;
-
-        gnttab->nr_banks = 1;
-        gnttab->bank[0].start = kinfo->gnttab_start;
-        gnttab->bank[0].size = kinfo->gnttab_size;
-
-        hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
-        if ( !hwdom_free_mem )
-            goto fail;
-
-        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
-                                     hwdom_free_mem, add_hwdom_free_regions) )
-            goto fail;
-
-        nr_banks = hwdom_free_mem->nr_banks;
-        xfree(gnttab);
-    }
-
-    for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- )
-    {
-        paddr_t bank_start, bank_size;
-
-        if ( is_hardware_domain(d) )
-        {
-            bank_start = hwdom_free_mem->bank[i].start;
-            bank_size = hwdom_free_mem->bank[i].size;
-        }
-        else
-        {
-            const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
-            const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
-
-            if ( i >= GUEST_RAM_BANKS )
-                goto fail;
-
-            bank_start = bankbase[i];
-            bank_size = banksize[i];
-        }
-
-        bank_size = MIN(bank_size, kinfo->unassigned_mem);
-        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) )
-            goto fail;
-    }
-
-    if ( kinfo->unassigned_mem )
-        goto fail;
-
-    for( i = 0; i < mem->nr_banks; i++ )
-    {
-        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
-               d,
-               i,
-               mem->bank[i].start,
-               mem->bank[i].start + mem->bank[i].size,
-               /* Don't want format this as PRIpaddr (16 digit hex) */
-               (unsigned long)(mem->bank[i].size >> 20));
-    }
-
-    xfree(hwdom_free_mem);
-    return;
-
-  fail:
-    panic("Failed to allocate requested domain memory."
-          /* Don't want format this as PRIpaddr (16 digit hex) */
-          " %ldKB unallocated. Fix the VMs configurations.\n",
-          (unsigned long)kinfo->unassigned_mem >> 10);
-}
-
 static int __init handle_pci_range(const struct dt_device_node *dev,
                                    uint64_t addr, uint64_t len, void *data)
 {
@@ -2059,75 +1735,6 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo)
     return -EINVAL;
 }
 
-static void __init dtb_load(struct kernel_info *kinfo)
-{
-    unsigned long left;
-
-    printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, kinfo->dtb_paddr,
-           kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
-
-    left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
-                                           kinfo->fdt,
-                                           fdt_totalsize(kinfo->fdt));
-
-    if ( left != 0 )
-        panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n",
-              kinfo->d, left);
-    xfree(kinfo->fdt);
-}
-
-static void __init initrd_load(struct kernel_info *kinfo)
-{
-    const struct bootmodule *mod = kinfo->initrd_bootmodule;
-    paddr_t load_addr = kinfo->initrd_paddr;
-    paddr_t paddr, len;
-    int node;
-    int res;
-    __be32 val[2];
-    __be32 *cellp;
-    void __iomem *initrd;
-
-    if ( !mod || !mod->size )
-        return;
-
-    paddr = mod->start;
-    len = mod->size;
-
-    printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-           kinfo->d, paddr, load_addr, load_addr + len);
-
-    /* Fix up linux,initrd-start and linux,initrd-end in /chosen */
-    node = fdt_path_offset(kinfo->fdt, "/chosen");
-    if ( node < 0 )
-        panic("Cannot find the /chosen node\n");
-
-    cellp = (__be32 *)val;
-    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr);
-    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start",
-                              val, sizeof(val));
-    if ( res )
-        panic("Cannot fix up \"linux,initrd-start\" property\n");
-
-    cellp = (__be32 *)val;
-    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len);
-    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end",
-                              val, sizeof(val));
-    if ( res )
-        panic("Cannot fix up \"linux,initrd-end\" property\n");
-
-    initrd = ioremap_wc(paddr, len);
-    if ( !initrd )
-        panic("Unable to map the %pd initrd\n", kinfo->d);
-
-    res = copy_to_guest_phys_flush_dcache(kinfo->d, load_addr,
-                                          initrd, len);
-    if ( res != 0 )
-        panic("Unable to copy the initrd in the %pd memory\n", kinfo->d);
-
-    iounmap(initrd);
-}
-
 /*
  * Allocate the event channel PPIs and setup the HVM_PARAM_CALLBACK_IRQ.
  * The allocated IRQ will be found in d->arch.evtchn_irq.
@@ -2220,8 +1827,8 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
      */
     kernel_load(kinfo);
     /* initrd_load will fix up the fdt, so call it before dtb_load */
-    initrd_load(kinfo);
-    dtb_load(kinfo);
+    initrd_load(kinfo, copy_to_guest_phys_flush_dcache);
+    dtb_load(kinfo, copy_to_guest_phys_flush_dcache);
 
     memset(regs, 0, sizeof(*regs));
 
diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
index 9d72108f35..9655e9d453 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -5,20 +5,10 @@
 #include 
 
 typedef __be32 gic_interrupt_t[3];
-typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
-                                     unsigned int order, void *extra);
-bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
-                             alloc_domheap_mem_cb cb, void *extra);
-
-bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
-                          paddr_t tot_size);
-void allocate_memory(struct domain *d, struct kernel_info *kinfo);
 int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
 int make_psci_node(void *fdt);
 void evtchn_allocate(struct domain *d);
 
-unsigned int get_allocation_size(paddr_t size);
-
 /*
  * Helper to write an interrupts with the GIC format
  * This code is assuming the irq is an PPI.
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index e88a4d5799..831b91399b 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,6 +1,7 @@
 obj-y += bootfdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
+obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
new file mode 100644
index 0000000000..762b63e2b0
--- /dev/null
+++ b/xen/common/device-tree/domain-build.c
@@ -0,0 +1,395 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
+                                    alloc_domheap_mem_cb cb, void *extra)
+{
+    unsigned int max_order = UINT_MAX;
+
+    while ( tot_size > 0 )
+    {
+        unsigned int order = get_allocation_size(tot_size);
+        struct page_info *pg;
+
+        order = min(max_order, order);
+
+        pg = alloc_domheap_pages(d, order, 0);
+        if ( !pg )
+        {
+            /*
+             * If we can't allocate one page, then it is unlikely to
+             * succeed in the next iteration. So bail out.
+             */
+            if ( !order )
+                return false;
+
+            /*
+             * If we can't allocate memory with order, then it is
+             * unlikely to succeed in the next iteration.
+             * Record the order - 1 to avoid re-trying.
+             */
+            max_order = order - 1;
+            continue;
+        }
+
+        if ( !cb(d, pg, order, extra) )
+            return false;
+
+        tot_size -= (1ULL << (PAGE_SHIFT + order));
+    }
+
+    return true;
+}
+
+static bool __init guest_map_pages(struct domain *d, struct page_info *pg,
+                                   unsigned int order, void *extra)
+{
+    gfn_t *sgfn = (gfn_t *)extra;
+    int res;
+
+    BUG_ON(!sgfn);
+    res = guest_physmap_add_page(d, *sgfn, page_to_mfn(pg), order);
+    if ( res )
+    {
+        dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
+        return false;
+    }
+
+    *sgfn = gfn_add(*sgfn, 1UL << order);
+
+    return true;
+}
+
+bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
+                                 paddr_t tot_size)
+{
+    struct membanks *mem = kernel_info_get_mem(kinfo);
+    struct domain *d = kinfo->d;
+    struct membank *bank;
+
+    /*
+     * allocate_bank_memory can be called with a tot_size of zero for
+     * the second memory bank. It is not an error and we can safely
+     * avoid creating a zero-size memory bank.
+     */
+    if ( tot_size == 0 )
+        return true;
+
+    bank = &mem->bank[mem->nr_banks];
+    bank->start = gfn_to_gaddr(sgfn);
+    bank->size = tot_size;
+
+    /*
+     * Allocate pages from the heap until tot_size is zero and map them to the
+     * guest using guest_map_pages, passing the starting gfn as extra parameter
+     * for the map operation.
+     */
+    if ( !allocate_domheap_memory(d, tot_size, guest_map_pages, &sgfn) )
+        return false;
+
+    mem->nr_banks++;
+    kinfo->unassigned_mem -= bank->size;
+
+    return true;
+}
+
+static int __init add_hwdom_free_regions(unsigned long s_gfn,
+                                         unsigned long e_gfn, void *data)
+{
+    struct membanks *free_regions = data;
+    paddr_t start, size;
+    paddr_t s = pfn_to_paddr(s_gfn);
+    paddr_t e = pfn_to_paddr(e_gfn);
+    unsigned int i, j;
+
+    if ( free_regions->nr_banks >= free_regions->max_banks )
+        return 0;
+
+    /*
+     * Both start and size of the free region should be 2MB aligned to
+     * potentially allow superpage mapping.
+     */
+    start = (s + SZ_2M - 1) & ~(SZ_2M - 1);
+    if ( start > e )
+        return 0;
+
+    /*
+     * e is actually "end-1" because it is called by rangeset functions
+     * which are inclusive of the last address.
+     */
+    e += 1;
+    size = (e - start) & ~(SZ_2M - 1);
+
+    /* Find the insert position (descending order). */
+    for ( i = 0; i < free_regions->nr_banks ; i++ )
+        if ( size > free_regions->bank[i].size )
+            break;
+
+    /* Move the other banks to make space. */
+    for ( j = free_regions->nr_banks; j > i ; j-- )
+    {
+        free_regions->bank[j].start = free_regions->bank[j - 1].start;
+        free_regions->bank[j].size = free_regions->bank[j - 1].size;
+    }
+
+    free_regions->bank[i].start = start;
+    free_regions->bank[i].size = size;
+    free_regions->nr_banks++;
+
+    return 0;
+}
+
+/*
+ * Find unused regions of Host address space which can be exposed to domain
+ * using the host memory layout. In order to calculate regions we exclude every
+ * region passed in mem_banks from the Host RAM.
+ */
+int __init find_unallocated_memory(const struct kernel_info *kinfo,
+                                   const struct membanks *mem_banks[],
+                                   unsigned int nr_mem_banks,
+                                   struct membanks *free_regions,
+                                   int (*cb)(unsigned long s_gfn,
+                                             unsigned long e_gfn,
+                                             void *data))
+{
+    const struct membanks *mem = bootinfo_get_mem();
+    struct rangeset *unalloc_mem;
+    paddr_t start, end;
+    unsigned int i, j;
+    int res;
+
+    ASSERT(domain_use_host_layout(kinfo->d));
+
+    unalloc_mem = rangeset_new(NULL, NULL, 0);
+    if ( !unalloc_mem )
+        return -ENOMEM;
+
+    /* Start with all available RAM */
+    for ( i = 0; i < mem->nr_banks; i++ )
+    {
+        start = mem->bank[i].start;
+        end = mem->bank[i].start + mem->bank[i].size;
+        res = rangeset_add_range(unalloc_mem, PFN_DOWN(start),
+                                 PFN_DOWN(end - 1));
+        if ( res )
+        {
+            printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n",
+                   start, end);
+            goto out;
+        }
+    }
+
+    /* Remove all regions listed in mem_banks */
+    for ( i = 0; i < nr_mem_banks; i++ )
+        for ( j = 0; j < mem_banks[i]->nr_banks; j++ )
+        {
+            start = mem_banks[i]->bank[j].start;
+
+            /* Shared memory banks can contain INVALID_PADDR as start */
+            if ( INVALID_PADDR == start )
+                continue;
+
+            end = mem_banks[i]->bank[j].start + mem_banks[i]->bank[j].size;
+            res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start),
+                                        PFN_DOWN(end - 1));
+            if ( res )
+            {
+                printk(XENLOG_ERR
+                       "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error %d\n",
+                       start, end, res);
+                goto out;
+            }
+        }
+
+    start = 0;
+    end = (1ULL << p2m_ipa_bits) - 1;
+    res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end),
+                                 cb, free_regions);
+    if ( res )
+        free_regions->nr_banks = 0;
+    else if ( !free_regions->nr_banks )
+        res = -ENOENT;
+
+out:
+    rangeset_destroy(unalloc_mem);
+
+    return res;
+}
+
+void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+    struct membanks *mem = kernel_info_get_mem(kinfo);
+    unsigned int i, nr_banks = GUEST_RAM_BANKS;
+    struct membanks *hwdom_free_mem = NULL;
+
+    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
+           /* Don't want format this as PRIpaddr (16 digit hex) */
+           (unsigned long)(kinfo->unassigned_mem >> 20), d);
+
+    mem->nr_banks = 0;
+    /*
+     * Use host memory layout for hwdom. Only case for this is when LLC coloring
+     * is enabled.
+     */
+    if ( is_hardware_domain(d) )
+    {
+        struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
+        /*
+         * Exclude the following regions:
+         * 1) Remove reserved memory
+         * 2) Grant table assigned to hwdom
+         */
+        const struct membanks *mem_banks[] = {
+            bootinfo_get_reserved_mem(),
+            gnttab,
+        };
+
+        if ( !gnttab )
+            goto fail;
+
+        gnttab->nr_banks = 1;
+        gnttab->bank[0].start = kinfo->gnttab_start;
+        gnttab->bank[0].size = kinfo->gnttab_size;
+
+        hwdom_free_mem = membanks_xzalloc(NR_MEM_BANKS, MEMORY);
+        if ( !hwdom_free_mem )
+            goto fail;
+
+        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
+                                     hwdom_free_mem, add_hwdom_free_regions) )
+            goto fail;
+
+        nr_banks = hwdom_free_mem->nr_banks;
+        xfree(gnttab);
+    }
+
+    for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- )
+    {
+        paddr_t bank_start, bank_size;
+
+        if ( is_hardware_domain(d) )
+        {
+            bank_start = hwdom_free_mem->bank[i].start;
+            bank_size = hwdom_free_mem->bank[i].size;
+        }
+        else
+        {
+            const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+            const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
+
+            if ( i >= GUEST_RAM_BANKS )
+                goto fail;
+
+            bank_start = bankbase[i];
+            bank_size = banksize[i];
+        }
+
+        bank_size = MIN(bank_size, kinfo->unassigned_mem);
+        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) )
+            goto fail;
+    }
+
+    if ( kinfo->unassigned_mem )
+        goto fail;
+
+    for( i = 0; i < mem->nr_banks; i++ )
+    {
+        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
+               d,
+               i,
+               mem->bank[i].start,
+               mem->bank[i].start + mem->bank[i].size,
+               /* Don't want format this as PRIpaddr (16 digit hex) */
+               (unsigned long)(mem->bank[i].size >> 20));
+    }
+
+    xfree(hwdom_free_mem);
+    return;
+
+  fail:
+    panic("Failed to allocate requested domain memory."
+          /* Don't want format this as PRIpaddr (16 digit hex) */
+          " %ldKB unallocated. Fix the VMs configurations.\n",
+          (unsigned long)kinfo->unassigned_mem >> 10);
+}
+
+void __init dtb_load(struct kernel_info *kinfo,
+                     copy_to_guest_phys_cb copy_to_guest)
+{
+    unsigned long left;
+
+    printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+           kinfo->d, kinfo->dtb_paddr,
+           kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
+
+    left = copy_to_guest(kinfo->d, kinfo->dtb_paddr,
+                         kinfo->fdt,
+                         fdt_totalsize(kinfo->fdt));
+
+    if ( left != 0 )
+        panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n",
+              kinfo->d, left);
+    xfree(kinfo->fdt);
+}
+
+void __init initrd_load(struct kernel_info *kinfo,
+                        copy_to_guest_phys_cb copy_to_guest)
+{
+    const struct bootmodule *mod = kinfo->initrd_bootmodule;
+    paddr_t load_addr = kinfo->initrd_paddr;
+    paddr_t paddr, len;
+    int node;
+    int res;
+    __be32 val[2];
+    __be32 *cellp;
+    void __iomem *initrd;
+
+    if ( !mod || !mod->size )
+        return;
+
+    paddr = mod->start;
+    len = mod->size;
+
+    printk("Loading %pd initrd from %"PRIpaddr" to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+           kinfo->d, paddr, load_addr, load_addr + len);
+
+    /* Fix up linux,initrd-start and linux,initrd-end in /chosen */
+    node = fdt_path_offset(kinfo->fdt, "/chosen");
+    if ( node < 0 )
+        panic("Cannot find the /chosen node\n");
+
+    cellp = (__be32 *)val;
+    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr);
+    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-start",
+                              val, sizeof(val));
+    if ( res )
+        panic("Cannot fix up \"linux,initrd-start\" property\n");
+
+    cellp = (__be32 *)val;
+    dt_set_cell(&cellp, ARRAY_SIZE(val), load_addr + len);
+    res = fdt_setprop_inplace(kinfo->fdt, node, "linux,initrd-end",
+                              val, sizeof(val));
+    if ( res )
+        panic("Cannot fix up \"linux,initrd-end\" property\n");
+
+    initrd = ioremap_wc(paddr, len);
+    if ( !initrd )
+        panic("Unable to map the %pd initrd\n", kinfo->d);
+
+    res = copy_to_guest(kinfo->d, load_addr,
+                        initrd, len);
+    if ( res != 0 )
+        panic("Unable to copy the initrd in the %pd memory\n", kinfo->d);
+
+    iounmap(initrd);
+}
diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
index 30d5358a0f..45981dbec0 100644
--- a/xen/include/xen/fdt-domain-build.h
+++ b/xen/include/xen/fdt-domain-build.h
@@ -6,12 +6,21 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct domain;
 struct page_info;
 struct membanks;
 
+typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
+                                     unsigned int order, void *extra);
+bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
+                             alloc_domheap_mem_cb cb, void *extra);
+
+bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
+                          paddr_t tot_size);
+void allocate_memory(struct domain *d, struct kernel_info *kinfo);
 int construct_domain(struct domain *d, struct kernel_info *kinfo);
 int construct_hwdom(struct kernel_info *kinfo,
                     const struct dt_device_node *node);
@@ -23,6 +32,37 @@ int make_memory_node(const struct kernel_info *kinfo, int addrcells,
                      int sizecells, const struct membanks *mem);
 int make_timer_node(const struct kernel_info *kinfo);
 
+static inline int get_allocation_size(paddr_t size)
+{
+    /*
+     * get_order_from_bytes returns the order greater than or equal to
+     * the given size, but we need less than or equal. Adding one to
+     * the size pushes an evenly aligned size into the next order, so
+     * we can then unconditionally subtract 1 from the order which is
+     * returned.
+     */
+    return get_order_from_bytes(size + 1) - 1;
+}
+
+typedef unsigned long (*copy_to_guest_phys_cb)(struct domain *d,
+                                               paddr_t gpa,
+                                               void *buf,
+                                               unsigned int len);
+
+void initrd_load(struct kernel_info *kinfo,
+                 copy_to_guest_phys_cb copy_to_guest);
+
+void dtb_load(struct kernel_info *kinfo,
+              copy_to_guest_phys_cb copy_to_guest);
+
+int find_unallocated_memory(const struct kernel_info *kinfo,
+                            const struct membanks *mem_banks[],
+                            unsigned int nr_mem_banks,
+                            struct membanks *free_regions,
+                            int (*cb)(unsigned long s_gfn,
+                                      unsigned long e_gfn,
+                                      void *data));
+
 #endif /* __XEN_FDT_DOMAIN_BUILD_H__ */
 
 /*
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 05 18:10:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 18:10:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976213.1363475 (Exim 4.92)
	(envelope-from )
	id 1uC0HE-0007YP-JO; Mon, 05 May 2025 18:10:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976213.1363475; Mon, 05 May 2025 18:10: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 1uC0HE-0007XL-Bo; Mon, 05 May 2025 18:10:52 +0000
Received: by outflank-mailman (input) for mailman id 976213;
 Mon, 05 May 2025 18:10:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC0HC-0005wU-72
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 18:10:50 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4141960f-29dc-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 20:10:41 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5f5bef591d6so9552963a12.1
 for ; Mon, 05 May 2025 11:10:41 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189146fcbsm530372366b.34.2025.05.05.11.10.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 11:10:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4141960f-29dc-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746468641; x=1747073441; 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;
        bh=KE1jKxotKKMDmhRdw2Lt1lYv08YopenK59ESAW9TYl0=;
        b=LjVM9A3e8nUUgcsSGnLvoEzPVSRbYP6wcloXa8EqQKce74rNMWw31VEhbosDJUUGh8
         cCCPHyIEgNQqtBvIomUnoIvYtgJ++AL2mV2W/osMATRoWaK+nfrfkhLUOqbf893gwxGk
         ncx9ZmdRJ3r6o0cOvC64iUxnV+nL8ac+V0TkkW06T8ZGSUZqGNM9Q+7GO9FvFUQFJ8+u
         p+lXy4mzLjlriOPek82br16sws0GRmJzTIm9rvFgv2YxV9vX/c6rWjR8sXY9Ewf9Q/2B
         2Wr98eP9a4Q5bvOwLlZGGT5uL2Un1Gbdk7WflJkz1x+DWcVu6emKuK8IJY4m6T9ntjDK
         DcBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746468641; x=1747073441;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=KE1jKxotKKMDmhRdw2Lt1lYv08YopenK59ESAW9TYl0=;
        b=XQ4kD4YYZw7+7seg+MRi9ryZVKXjXfSadaCMFawHHHwwmOvIIHD79nwpjF520hC1UM
         IBtgm324ets3G85jmoDdkSMmJeXz3nehVHDVezqJVeY7mDB2oEAKiqX8BQIrMOOsbmrR
         mWt/lGJoHVHSLuL6P13EBbWKFb3kwE8k0cOxthcvCklr+z5X08Oz8w1zscGXskmuUpQa
         trpsVybD7nE497tJbgr3y/isX1LYk/LhIHYKkRXB7UAhy0N9tjdHiApCz0aqAPqIPH2j
         MFxfYQwGnAxtgnlx2u6nt5/m0CdiYCyoWGkVIkyrNGWUIfqsVKriM6kdyNFVf5ShKFCX
         GwxA==
X-Gm-Message-State: AOJu0YyD4Z/6zmiBaYueh1VSUxng6xo9Ky7mlQ0VbtekPx+Cew82Vk9R
	vdR6ykDwgnqwmFHAihkNtsuEMewDK9Ts/W72vzDlw7SFijS8Jk/BkWKU1A==
X-Gm-Gg: ASbGncu8IgC6vAaJ6Casb6oUE4tjR8SLx4FmSSr88jNEStYgjWcaEUOATYN0q0xHhh2
	0fMLnbqQKWqq6rRfe8oadC+S44M4wmqrYG+f3uFW3Zo7x2eLCm57ox1x3JR0Suz2frVRJivxlJG
	W6wgPgsdgPvB6osWFeIW2it6zDJVeJoWkM/ZrqAQtMeVfLX2ppRuGV0CuP6DSQgpq4n2iWMPa63
	ykc3aU/SfVXc2/ku2mMjkeyFG3/9SN/06aPU4Vv2txbNJtQCdToJnqT2cw/ag9dFEwtGRkEGiny
	mqBgFbIwvZqqdZba64vvfl6Z1sEkJ4DU/bc5X6r45CacdNywYP/qd09i72+EhUCyEz0jPj5hDxA
	vDOMSzrRInw==
X-Google-Smtp-Source: AGHT+IGSKAvfanif6qheU3nuI1TNGHrqhgGfeaqR/oM1blP2rJpwQQWxcZh7wVPCC0fxPdovSncb7g==
X-Received: by 2002:a17:907:3d8c:b0:acb:4f4a:cbd0 with SMTP id a640c23a62f3a-ad17b5ad337mr1255527866b.14.1746468640401;
        Mon, 05 May 2025 11:10: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 v4 0/8] Move parts of Arm's Dom0less to common code
Date: Mon,  5 May 2025 20:10:30 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Some parts of Arm's Dom0less solution could be moved to common code as they are
not truly Arm-specific.

Most of the code is moved as is, with only minor changes introduced to provide
abstractions that hide Arm-specific details, while maintaining functional
equivalence with original Arm's code.

There are several open questions:
1. The u64 and u32 types are widely used in the code where device tree
   functionality is implemented because these types are used in device tree
   function arguments.
   Should this be reworked to use uint32_t and uint64_t instead? If so, will it
   also be necessary to change the type of variables passed to dt-related
   functions, or should the argument types of device tree functions be updated
   too? For example:
   ```
    u64 mem;
    ...
    rc = dt_property_read_u64(node, "memory", &mem);
   ```
   where dt_property_read_u64 is declared as:
     bool dt_property_read_u64(... , u64 *out_value);
2. Instead of providing init_intc_phandle() (see the patch: [1]), perhaps it
   would be better to add a for loop in domain_handle_dtb_bootmodule()?
   Something like:
   ```
    bool is_intc_phandle_inited = false;
    for ( unsigned int i = 0; i < ARRAY_SIZE(intc_names_array); i++ )
    {
        if ( dt_node_cmp(name, intc_names_array[i]) == 0 )
        {
            uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);

            if ( phandle_intc != 0 )
                kinfo->phandle_intc = phandle_intc;

            is_intc_phandle_inited = true;
            break;
        }
    }

    if ( is_intc_phandle_inited ) continue;
  ```

CI's test for the current patch series:
  https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1801183107

---
Changes in v4:
 - Drop item 3 from the cover letter message as it was decided to rename
   dom0less to predefined domains separately.
 - Update the link with results of CI testing.
 - All other changes please look in the specific patch.
---
Changes in v3:
- Rebase on top of current staging and fixing merge conflicts.
- Ingrate changes done in the commit:
    "xen/arm: dom0less delay xenstore initialization"
- All other changes please look in the specific patch.
- Update cover letter message.
---
Changes in v2:
- Update cover letter message.
- Rebase on top of the current staging.
- Drop patches:
   - asm-generic: move Arm's static-memory.h to asm-generic
   - asm-generic: move Arm's static-shmem.h to asm-generic
  as in the nearest future there is no real users of STATIC_MEMORY and
  STATIC_SHMEM.
- Add new cleanup patch:
  [PATCH v2 1/8] xen/arm: drop declaration of handle_device_interrupts()
- All other changes are patch specific. Please check them seprately for each
  patch
---

Oleksii Kurochko (8):
  xen/arm: drop declaration of handle_device_interrupts()
  xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common
  asm-generic: move parts of Arm's asm/kernel.h to common code
  arm/static-shmem.h: drop inclusion of asm/setup.h
  asm-generic: move some parts of Arm's domain_build.h to common
  xen/common: dom0less: introduce common kernel.c
  xen/common: dom0less: introduce common domain-build.c
  xen/common: dom0less: introduce common dom0less-build.c

 xen/arch/arm/Kconfig                      |   10 +-
 xen/arch/arm/acpi/domain_build.c          |    3 +-
 xen/arch/arm/dom0less-build.c             | 1078 ++-------------------
 xen/arch/arm/domain_build.c               |  410 +-------
 xen/arch/arm/include/asm/Makefile         |    1 +
 xen/arch/arm/include/asm/dom0less-build.h |   34 -
 xen/arch/arm/include/asm/domain_build.h   |   32 +-
 xen/arch/arm/include/asm/kernel.h         |  123 +--
 xen/arch/arm/include/asm/static-memory.h  |    2 +-
 xen/arch/arm/include/asm/static-shmem.h   |    3 +-
 xen/arch/arm/kernel.c                     |  235 +----
 xen/arch/arm/static-memory.c              |    1 +
 xen/arch/arm/static-shmem.c               |    2 +
 xen/common/Kconfig                        |   15 +
 xen/common/device-tree/Makefile           |    3 +
 xen/common/device-tree/dom0less-build.c   | 1002 +++++++++++++++++++
 xen/common/device-tree/domain-build.c     |  395 ++++++++
 xen/common/device-tree/dt-overlay.c       |    4 +-
 xen/common/device-tree/kernel.c           |  242 +++++
 xen/include/asm-generic/dom0less-build.h  |   84 ++
 xen/include/xen/fdt-domain-build.h        |   75 ++
 xen/include/xen/fdt-kernel.h              |  145 +++
 22 files changed, 2094 insertions(+), 1805 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h
 create mode 100644 xen/common/device-tree/dom0less-build.c
 create mode 100644 xen/common/device-tree/domain-build.c
 create mode 100644 xen/common/device-tree/kernel.c
 create mode 100644 xen/include/asm-generic/dom0less-build.h
 create mode 100644 xen/include/xen/fdt-domain-build.h
 create mode 100644 xen/include/xen/fdt-kernel.h

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 05 18:10:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 18:10:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976214.1363483 (Exim 4.92)
	(envelope-from )
	id 1uC0HF-0007jw-BS; Mon, 05 May 2025 18:10:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976214.1363483; Mon, 05 May 2025 18:10: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 1uC0HF-0007hn-2q; Mon, 05 May 2025 18:10:53 +0000
Received: by outflank-mailman (input) for mailman id 976214;
 Mon, 05 May 2025 18:10:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC0HD-0005wU-7N
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 18:10:51 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 458ee132-29dc-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 20:10:48 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ac3b12e8518so808977266b.0
 for ; Mon, 05 May 2025 11:10:48 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189146fcbsm530372366b.34.2025.05.05.11.10.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 05 May 2025 11:10: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" 
X-Inumbo-ID: 458ee132-29dc-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746468648; x=1747073448; 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;
        bh=ALiYnXDRmjufuE9L6F7ReI1kTKI4ociQbNKWfEaDzr0=;
        b=CHH9IlpkBuLbee/3c0Cih+Zh6c3leKoGBwoPftAdNn31l81l+A9XI/+u8AJaeLNT6g
         w9+j06AMLxQ0g/u4587ipHlBEcsMNBUxB9QZifZNdj7GJeEBf/PpQBxLY1NdppwEsnZx
         was+1mkSnmIx6vYl/hXYRIHuNR2aLi5Ks4PGG7AJwse95C4XwhQyxvc03Vt5X5OOZxAt
         mV7M8qtSDtiB26/j2Y5m1tVsU1tQoQSXnSRmDlFSnpa/DfTDUDS+q97YHAa1yR/k5P1Y
         i3hzM8EskPlEcYMtPjvi/LcDFUhTsXtGojuQxEgIPtl+kC2ubMVokz88L/Wd/pqPsHQI
         eOiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746468648; x=1747073448;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ALiYnXDRmjufuE9L6F7ReI1kTKI4ociQbNKWfEaDzr0=;
        b=PgdaIfdB1SO6cwSJspQhpt1CfxlZENZJSnQ02WJQnMc3IaeARtmvor0B1Asqf0cDsY
         M6XSTRw7cpK3Low8XHpRAkwK/BvnD6Z8GnVIFyHX8hBtuM8vIVIBlSGoWfuSYIPPWgE8
         /tC36/T24Ba57qcb4GczZKqlK8nOHq+9LTFBJKiTjUksDCF2HI2FQGzcWdc1/adjvlHF
         nB2CZP26NvM7jlnYbtoD7Aod9lBxH4MN1P5nbrQaFrNHuJOcQuC5A2JbsNsJZFRiwkGO
         yT4W2AJb7frwGWNRipnntF2jWhgXsrkwoBp8E/ckKYiT4L0su1TFIby8iOpo6W+Ohkn3
         MC3A==
X-Gm-Message-State: AOJu0YyVKYlx4nvKOgq7fPdmccNjtIesr75xdsFzbW0+xSfbu6k2BmBn
	FwUtCLBj2bKo5VNo1wDSZqsFPjq9MarqCc+ZVEnilGoU/cE2zIvnnK+jcw==
X-Gm-Gg: ASbGncue9VYTR97oqrn+I7zFEwDw52LDRtI5cwN3rVvu4TR43QbKLlZKaHXgIi0DAsS
	LjJ1Z9qIdtW53UWZ4nJw6YBgCKt7a62wEHkm45mJxAsV46gim4go/rtjuNPfnzmgi7TUkcO9pJo
	9sWPzei5bOLpq2+n8HgrFVbr09O17VtVDUy6YfFONpvAukKQFRtypi57SQJZzbvrp51Xjiqk0M1
	G1qtdxcOS75A6M7gtv/79RB+SlguDvELr3/Z6lJTKdBHr0X5DhM5fkzh2TtNnoKMM73p5bT/2ql
	96CPjkE7JnXZMgUDTGzvymOEfxX/+Y9tWMpV7lvEERQK8BYAqdWgz98cZqaHmVZG8SgjgHLet+9
	M/cvFq61iTA==
X-Google-Smtp-Source: AGHT+IGrZ8OuA76+YmtJr9d67MzeH5wY/CQHR5Y1i6moLVLLZhkPUmtx+JMvxT7ATHk3MZ2i6QCENw==
X-Received: by 2002:a17:907:948c:b0:acb:6081:14ec with SMTP id a640c23a62f3a-ad1a4b85d03mr656873266b.61.1746468647275;
        Mon, 05 May 2025 11:10:47 -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 v4 8/8] xen/common: dom0less: introduce common dom0less-build.c
Date: Mon,  5 May 2025 20:10:38 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Part of Arm's dom0less-build.c could be common between architectures which are
using device tree files to create guest domains. Thereby move some parts of
Arm's dom0less-build.c to common code with minor changes.

As a part of theses changes the following changes are introduced:
- Introduce make_arch_nodes() to cover arch-specific nodes. For example, in
  case of Arm, it is PSCI and vpl011 nodes.
- Introduce set_domain_type() to abstract a way how setting of domain type
  happens. For example, RISC-V won't have this member of arch_domain structure
  as vCPUs will always have the same bitness as hypervisor. In case of Arm, it
  is possible that Arm64 could create 32-bit and 64-bit domains.
- Introduce init_vuart() to cover details of virtual uart initialization.
- Introduce init_intc_phandle() to cover some details of interrupt controller
  phandle initialization. As an example, RISC-V could have different name for
  interrupt controller node ( APLIC, PLIC, IMSIC, etc ) but the code in
  domain_handle_dtb_bootmodule() could handle only one interrupt controller
  node name.
- s/make_gic_domU_node/make_intc_domU_node as GIC is Arm specific naming and
  add prototype of make_intc_domU_node() to dom0less-build.h

The following functions are moved to xen/common/device-tree:
- Functions which are moved as is:
  - domain_p2m_pages().
  - handle_passthrough_prop().
  - handle_prop_pfdt().
  - scan_pfdt_node().
  - check_partial_fdt().
- Functions which are moved with some minor changes:
  - alloc_xenstore_evtchn():
    - ifdef-ing by CONFIG_HVM accesses to hvm.params.
  - prepare_dtb_domU():
    - ifdef-ing access to gnttab_{start,size} by CONFIG_GRANT_TABLE.
    - s/make_gic_domU_node/make_intc_domU_node.
    - Add call of make_arch_nodes().
- domain_handle_dtb_bootmodule():
  - hide details of interrupt controller phandle initialization by calling
    init_intc_phandle().
  - Update the comment above init_intc_phandle(): s/gic/interrupt controller.
- construct_domU():
  - ifdef-ing by CONFIG_HVM accesses to hvm.params.
  - Call init_vuart() to hide Arm's vpl011_init() details there.
  - Add call of set_domain_type() instead of setting kinfo->arch.type explicitly.

Some parts of dom0less-build.c are wraped by #ifdef CONFIG_STATIC_{SHMEM,MEMORY}
as not all archs support these configs.

Signed-off-by: Oleksii Kurochko 
---
Changes in v4:
 - Add a chunk of code, which was introduced in the patch:
   "xen/arm: dom0less hwdom construction", in moved to common
   construct_domU(). The part which re-uses construct_hwdom().
 - Use __has_include() instead of #ifdef-ing for inclusion of
   asm/static-{memory, shmem}.h in the common code.
---
Change in v3:
 - Align construct_domU() with the current staging:
 - Align alloc_xenstore_params() with the current staging.
 - Move defintion of XENSTORE_PFN_LATE_ALLOC to common and
   declaration of need_xenstore to common.
---
Change in v2:
 - Wrap by #ifdef CONFIG_STATIC_* inclusions of  and
   . Wrap also the code which uses something from the
   mentioned headers.
 - Add handling of legacy case in construct_domU().
 - Use xen/fdt-kernel.h and xen/fdt-domain-build.h instead of asm/*.
 - Update the commit message.
---
 xen/arch/arm/dom0less-build.c            | 714 ++---------------------
 xen/common/device-tree/dom0less-build.c  | 708 ++++++++++++++++++++++
 xen/include/asm-generic/dom0less-build.h |  18 +-
 3 files changed, 760 insertions(+), 680 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 47eb38b9ad..ebb1c58f0e 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -25,8 +25,6 @@
 #include 
 #include 
 
-bool __initdata need_xenstore;
-
 #ifdef CONFIG_VGICV2
 static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
 {
@@ -152,7 +150,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
 }
 #endif
 
-static int __init make_gic_domU_node(struct kernel_info *kinfo)
+int __init make_intc_domU_node(struct kernel_info *kinfo)
 {
     switch ( kinfo->d->arch.vgic.version )
     {
@@ -218,708 +216,60 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
 }
 #endif
 
-/*
- * Scan device tree properties for passthrough specific information.
- * Returns < 0 on error
- *         0 on success
- */
-static int __init handle_passthrough_prop(struct kernel_info *kinfo,
-                                          const struct fdt_property *xen_reg,
-                                          const struct fdt_property *xen_path,
-                                          bool xen_force,
-                                          uint32_t address_cells,
-                                          uint32_t size_cells)
-{
-    const __be32 *cell;
-    unsigned int i, len;
-    struct dt_device_node *node;
-    int res;
-    paddr_t mstart, size, gstart;
-
-    /* xen,reg specifies where to map the MMIO region */
-    cell = (const __be32 *)xen_reg->data;
-    len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
-                                        sizeof(uint32_t));
-
-    for ( i = 0; i < len; i++ )
-    {
-        device_tree_get_reg(&cell, address_cells, size_cells,
-                            &mstart, &size);
-        gstart = dt_next_cell(address_cells, &cell);
-
-        if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK )
-        {
-            printk(XENLOG_ERR
-                   "DomU passthrough config has not page aligned addresses/sizes\n");
-            return -EINVAL;
-        }
-
-        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
-                                  paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
-        if ( res )
-        {
-            printk(XENLOG_ERR "Unable to permit to dom%d access to"
-                   " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
-                   kinfo->d->domain_id,
-                   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
-            return res;
-        }
-
-        res = map_regions_p2mt(kinfo->d,
-                               gaddr_to_gfn(gstart),
-                               PFN_DOWN(size),
-                               maddr_to_mfn(mstart),
-                               p2m_mmio_direct_dev);
-        if ( res < 0 )
-        {
-            printk(XENLOG_ERR
-                   "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n",
-                   mstart, gstart);
-            return -EFAULT;
-        }
-    }
-
-    /*
-     * If xen_force, we let the user assign a MMIO region with no
-     * associated path.
-     */
-    if ( xen_path == NULL )
-        return xen_force ? 0 : -EINVAL;
-
-    /*
-     * xen,path specifies the corresponding node in the host DT.
-     * Both interrupt mappings and IOMMU settings are based on it,
-     * as they are done based on the corresponding host DT node.
-     */
-    node = dt_find_node_by_path(xen_path->data);
-    if ( node == NULL )
-    {
-        printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n",
-               xen_path->data);
-        return -EINVAL;
-    }
-
-    res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
-    if ( res < 0 )
-        return res;
-
-    res = iommu_add_dt_device(node);
-    if ( res < 0 )
-        return res;
-
-    /* If xen_force, we allow assignment of devices without IOMMU protection. */
-    if ( xen_force && !dt_device_is_protected(node) )
-        return 0;
-
-    return iommu_assign_dt_device(kinfo->d, node);
-}
-
-static int __init handle_prop_pfdt(struct kernel_info *kinfo,
-                                   const void *pfdt, int nodeoff,
-                                   uint32_t address_cells, uint32_t size_cells,
-                                   bool scan_passthrough_prop)
-{
-    void *fdt = kinfo->fdt;
-    int propoff, nameoff, res;
-    const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL;
-    const char *name;
-    bool found, xen_force = false;
-
-    for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
-          propoff >= 0;
-          propoff = fdt_next_property_offset(pfdt, propoff) )
-    {
-        if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) )
-            return -FDT_ERR_INTERNAL;
-
-        found = false;
-        nameoff = fdt32_to_cpu(prop->nameoff);
-        name = fdt_string(pfdt, nameoff);
-
-        if ( scan_passthrough_prop )
-        {
-            if ( dt_prop_cmp("xen,reg", name) == 0 )
-            {
-                xen_reg = prop;
-                found = true;
-            }
-            else if ( dt_prop_cmp("xen,path", name) == 0 )
-            {
-                xen_path = prop;
-                found = true;
-            }
-            else if ( dt_prop_cmp("xen,force-assign-without-iommu",
-                                  name) == 0 )
-            {
-                xen_force = true;
-                found = true;
-            }
-        }
-
-        /*
-         * Copy properties other than the ones above: xen,reg, xen,path,
-         * and xen,force-assign-without-iommu.
-         */
-        if ( !found )
-        {
-            res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len));
-            if ( res )
-                return res;
-        }
-    }
-
-    /*
-     * Only handle passthrough properties if both xen,reg and xen,path
-     * are present, or if xen,force-assign-without-iommu is specified.
-     */
-    if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
-    {
-        res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
-                                      address_cells, size_cells);
-        if ( res < 0 )
-        {
-            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
-            return res;
-        }
-    }
-    else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
-    {
-        printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
-               kinfo->d);
-        return -EINVAL;
-    }
-
-    /* FDT_ERR_NOTFOUND => There is no more properties for this node */
-    return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
-}
-
-static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt,
-                                 int nodeoff,
-                                 uint32_t address_cells, uint32_t size_cells,
-                                 bool scan_passthrough_prop)
-{
-    int rc = 0;
-    void *fdt = kinfo->fdt;
-    int node_next;
-
-    rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL));
-    if ( rc )
-        return rc;
-
-    rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells,
-                          scan_passthrough_prop);
-    if ( rc )
-        return rc;
-
-    address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells",
-                                        DT_ROOT_NODE_ADDR_CELLS_DEFAULT);
-    size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells",
-                                     DT_ROOT_NODE_SIZE_CELLS_DEFAULT);
-
-    node_next = fdt_first_subnode(pfdt, nodeoff);
-    while ( node_next > 0 )
-    {
-        rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells,
-                            scan_passthrough_prop);
-        if ( rc )
-            return rc;
-
-        node_next = fdt_next_subnode(pfdt, node_next);
-    }
-
-    return fdt_end_node(fdt);
-}
-
-static int __init check_partial_fdt(void *pfdt, size_t size)
+int __init make_arch_nodes(struct kernel_info *kinfo)
 {
-    int res;
-
-    if ( fdt_magic(pfdt) != FDT_MAGIC )
-    {
-        dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree");
-        return -EINVAL;
-    }
-
-    res = fdt_check_header(pfdt);
-    if ( res )
-    {
-        dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res);
-        return -EINVAL;
-    }
-
-    if ( fdt_totalsize(pfdt) > size )
-    {
-        dprintk(XENLOG_ERR, "Partial FDT totalsize is too big");
-        return -EINVAL;
-    }
-
-    return 0;
-}
-
-static int __init domain_handle_dtb_bootmodule(struct domain *d,
-                                               struct kernel_info *kinfo)
-{
-    void *pfdt;
-    int res, node_next;
-
-    pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
-                         kinfo->dtb_bootmodule->size);
-    if ( pfdt == NULL )
-        return -EFAULT;
-
-    res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size);
-    if ( res < 0 )
-        goto out;
-
-    for ( node_next = fdt_first_subnode(pfdt, 0);
-          node_next > 0;
-          node_next = fdt_next_subnode(pfdt, node_next) )
-    {
-        const char *name = fdt_get_name(pfdt, node_next, NULL);
-
-        if ( name == NULL )
-            continue;
-
-        /*
-         * Only scan /gic /aliases /passthrough, ignore the rest.
-         * They don't have to be parsed in order.
-         *
-         * Take the GIC phandle value from the special /gic node in the
-         * DTB fragment.
-         */
-        if ( dt_node_cmp(name, "gic") == 0 )
-        {
-            uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
-
-            if ( phandle_intc != 0 )
-                kinfo->phandle_intc = phandle_intc;
-            continue;
-        }
-
-        if ( dt_node_cmp(name, "aliases") == 0 )
-        {
-            res = scan_pfdt_node(kinfo, pfdt, node_next,
-                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
-                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
-                                 false);
-            if ( res )
-                goto out;
-            continue;
-        }
-        if ( dt_node_cmp(name, "passthrough") == 0 )
-        {
-            res = scan_pfdt_node(kinfo, pfdt, node_next,
-                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
-                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
-                                 true);
-            if ( res )
-                goto out;
-            continue;
-        }
-    }
-
- out:
-    iounmap(pfdt);
-
-    return res;
-}
-
-/*
- * The max size for DT is 2MB. However, the generated DT is small (not including
- * domU passthrough DT nodes whose size we account separately), 4KB are enough
- * for now, but we might have to increase it in the future.
- */
-#define DOMU_DTB_SIZE 4096
-static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
-{
-    int addrcells, sizecells;
-    int ret, fdt_size = DOMU_DTB_SIZE;
-
-    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
-    kinfo->gnttab_start = GUEST_GNTTAB_BASE;
-    kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
-
-    addrcells = GUEST_ROOT_ADDRESS_CELLS;
-    sizecells = GUEST_ROOT_SIZE_CELLS;
-
-    /* Account for domU passthrough DT size */
-    if ( kinfo->dtb_bootmodule )
-        fdt_size += kinfo->dtb_bootmodule->size;
-
-    /* Cap to max DT size if needed */
-    fdt_size = min(fdt_size, SZ_2M);
-
-    kinfo->fdt = xmalloc_bytes(fdt_size);
-    if ( kinfo->fdt == NULL )
-        return -ENOMEM;
-
-    ret = fdt_create(kinfo->fdt, fdt_size);
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_finish_reservemap(kinfo->fdt);
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_begin_node(kinfo->fdt, "");
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells);
-    if ( ret )
-        goto err;
-
-    ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells);
-    if ( ret )
-        goto err;
-
-    ret = make_chosen_node(kinfo);
-    if ( ret )
-        goto err;
+    int ret;
 
     ret = make_psci_node(kinfo->fdt);
     if ( ret )
-        goto err;
-
-    ret = make_cpus_node(d, kinfo->fdt);
-    if ( ret )
-        goto err;
-
-    ret = make_memory_node(kinfo, addrcells, sizecells,
-                           kernel_info_get_mem(kinfo));
-    if ( ret )
-        goto err;
-
-    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
-    if ( ret )
-        goto err;
-
-    /*
-     * domain_handle_dtb_bootmodule has to be called before the rest of
-     * the device tree is generated because it depends on the value of
-     * the field phandle_intc.
-     */
-    if ( kinfo->dtb_bootmodule )
-    {
-        ret = domain_handle_dtb_bootmodule(d, kinfo);
-        if ( ret )
-            goto err;
-    }
-
-    ret = make_gic_domU_node(kinfo);
-    if ( ret )
-        goto err;
-
-    ret = make_timer_node(kinfo);
-    if ( ret )
-        goto err;
+        return -EINVAL;
 
     if ( kinfo->arch.vpl011 )
     {
-        ret = -EINVAL;
 #ifdef CONFIG_SBSA_VUART_CONSOLE
         ret = make_vpl011_uart_node(kinfo);
 #endif
         if ( ret )
-            goto err;
-    }
-
-    if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
-    {
-        ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
-        if ( ret )
-            goto err;
+            return -EINVAL;
     }
 
-    ret = fdt_end_node(kinfo->fdt);
-    if ( ret < 0 )
-        goto err;
-
-    ret = fdt_finish(kinfo->fdt);
-    if ( ret < 0 )
-        goto err;
-
     return 0;
-
-  err:
-    printk("Device tree generation failed (%d).\n", ret);
-    xfree(kinfo->fdt);
-
-    return -EINVAL;
 }
 
-#define XENSTORE_PFN_OFFSET 1
-static int __init alloc_xenstore_page(struct domain *d)
+/* TODO: make arch.type generic ? */
+#ifdef CONFIG_ARM_64
+void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
 {
-    struct page_info *xenstore_pg;
-    struct xenstore_domain_interface *interface;
-    mfn_t mfn;
-    gfn_t gfn;
-    int rc;
-
-    if ( (UINT_MAX - d->max_pages) < 1 )
-    {
-        printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n",
-               d);
-        return -EINVAL;
-    }
-
-    d->max_pages += 1;
-    xenstore_pg = alloc_domheap_page(d, MEMF_bits(32));
-    if ( xenstore_pg == NULL && is_64bit_domain(d) )
-        xenstore_pg = alloc_domheap_page(d, 0);
-    if ( xenstore_pg == NULL )
-        return -ENOMEM;
-
-    mfn = page_to_mfn(xenstore_pg);
-    if ( !mfn_x(mfn) )
-        return -ENOMEM;
-
-    if ( !is_domain_direct_mapped(d) )
-        gfn = gaddr_to_gfn(GUEST_MAGIC_BASE +
-                           (XENSTORE_PFN_OFFSET << PAGE_SHIFT));
-    else
-        gfn = gaddr_to_gfn(mfn_to_maddr(mfn));
-
-    rc = guest_physmap_add_page(d, gfn, mfn, 0);
-    if ( rc )
-    {
-        free_domheap_page(xenstore_pg);
-        return rc;
-    }
-
-    d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn);
-    interface = map_domain_page(mfn);
-    interface->connection = XENSTORE_RECONNECT;
-    unmap_domain_page(interface);
-
-    return 0;
+    /* type must be set before allocate memory */
+    d->arch.type = kinfo->arch.type;
 }
-
-static int __init alloc_xenstore_params(struct kernel_info *kinfo)
+#else
+void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
 {
-    struct domain *d = kinfo->d;
-    int rc = 0;
-
-    if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY))
-                                 == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) )
-        d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC;
-    else if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE )
-    {
-        rc = alloc_xenstore_page(d);
-        if ( rc < 0 )
-            return rc;
-    }
-
-    return rc;
+    /* Nothing to do */
 }
+#endif
 
-static void __init domain_vcpu_affinity(struct domain *d,
-                                        const struct dt_device_node *node)
+int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
+                      const struct dt_device_node *node)
 {
-    struct dt_device_node *np;
-
-    dt_for_each_child_node(node, np)
-    {
-        const char *hard_affinity_str = NULL;
-        uint32_t val;
-        int rc;
-        struct vcpu *v;
-        cpumask_t affinity;
-
-        if ( !dt_device_is_compatible(np, "xen,vcpu") )
-            continue;
-
-        if ( !dt_property_read_u32(np, "id", &val) )
-            panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node));
-
-        if ( val >= d->max_vcpus )
-            panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val,
-                  dt_node_name(node), d->max_vcpus);
-
-        v = d->vcpu[val];
-        rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str);
-        if ( rc < 0 )
-            continue;
-
-        cpumask_clear(&affinity);
-        while ( *hard_affinity_str != '\0' )
-        {
-            unsigned int start, end;
-
-            start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
-
-            if ( *hard_affinity_str == '-' )    /* Range */
-            {
-                hard_affinity_str++;
-                end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
-            }
-            else                /* Single value */
-                end = start;
-
-            if ( end >= nr_cpu_ids )
-                panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node));
-
-            for ( ; start <= end; start++ )
-                cpumask_set_cpu(start, &affinity);
-
-            if ( *hard_affinity_str == ',' )
-                hard_affinity_str++;
-            else if ( *hard_affinity_str != '\0' )
-                break;
-        }
+    int rc = 0;
 
-        rc = vcpu_set_hard_affinity(v, &affinity);
-        if ( rc )
-            panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n",
-                  v->vcpu_id, rc, dt_node_name(node));
-    }
-}
+    kinfo->arch.vpl011 = dt_property_read_bool(node, "vpl011");
 
-#ifdef CONFIG_ARCH_PAGING_MEMPOOL
-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.
+     * Base address and irq number are needed when creating vpl011 device
+     * tree node in prepare_dtb_domU, so initialization on related variables
+     * shall be done first.
      */
-    unsigned long memkb = 4 * (256 * smp_cpus + (maxmem_kb / 1024) + 128);
-
-    BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
-
-    return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT);
-}
-
-static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem,
-                                            const struct dt_device_node *node)
-{
-    unsigned long p2m_pages;
-    uint32_t p2m_mem_mb;
-    int rc;
-
-    rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb);
-    /* If xen,domain-p2m-mem-mb is not specified, use the default value. */
-    p2m_pages = rc ?
-                p2m_mem_mb << (20 - PAGE_SHIFT) :
-                domain_p2m_pages(mem, d->max_vcpus);
-
-    spin_lock(&d->arch.paging.lock);
-    rc = p2m_set_allocation(d, p2m_pages, NULL);
-    spin_unlock(&d->arch.paging.lock);
-
-    return rc;
-}
-#else /* !CONFIG_ARCH_PAGING_MEMPOOL */
-static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
-                                            const struct dt_device_node *node)
-{
-    return 0;
-}
-#endif /* CONFIG_ARCH_PAGING_MEMPOOL */
-
-int __init construct_domU(struct domain *d,
-                          const struct dt_device_node *node)
-{
-    struct kernel_info kinfo = KERNEL_INFO_INIT;
-    const char *dom0less_enhanced;
-    int rc;
-    u64 mem;
-
-    rc = dt_property_read_u64(node, "memory", &mem);
-    if ( !rc )
-    {
-        printk("Error building DomU: cannot read \"memory\" property\n");
-        return -EINVAL;
-    }
-    kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
-
-    rc = domain_p2m_set_allocation(d, mem, node);
-    if ( rc != 0 )
-        return rc;
-
-    printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
-           d->max_vcpus, mem);
-
-    kinfo.arch.vpl011  = dt_property_read_bool(node, "vpl011");
-    if ( kinfo.arch.vpl011  && is_hardware_domain(d) )
-        panic("hardware domain cannot specify vpl011\n");
-
-    rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
-    if ( rc == -EILSEQ ||
-         rc == -ENODATA ||
-         (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
-    {
-        need_xenstore = true;
-        kinfo.dom0less_feature = DOM0LESS_ENHANCED;
-    }
-    else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") )
-    {
-        need_xenstore = true;
-        kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY;
-    }
-    else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") )
-        kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS;
-
-    if ( vcpu_create(d, 0) == NULL )
-        return -ENOMEM;
-
-    d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
-
-    kinfo.d = d;
-
-    rc = kernel_probe(&kinfo, node);
-    if ( rc < 0 )
-        return rc;
-
-#ifdef CONFIG_ARM_64
-    /* type must be set before allocate memory */
-    d->arch.type = kinfo.arch.type;
-#endif
-    if ( is_hardware_domain(d) )
-    {
-        rc = construct_hwdom(&kinfo, node);
-        if ( rc < 0 )
-            return rc;
-    }
-    else
+    if ( kinfo->arch.vpl011 )
     {
-        if ( !dt_find_property(node, "xen,static-mem", NULL) )
-            allocate_memory(d, &kinfo);
-        else if ( !is_domain_direct_mapped(d) )
-            allocate_static_memory(d, &kinfo, node);
-        else
-            assign_static_memory_11(d, &kinfo, node);
-
-        rc = process_shm(d, &kinfo, node);
-        if ( rc < 0 )
-            return rc;
-
-        /*
-         * Base address and irq number are needed when creating vpl011 device
-         * tree node in prepare_dtb_domU, so initialization on related variables
-         * shall be done first.
-         */
-        if ( kinfo.arch.vpl011  )
-        {
-            rc = domain_vpl011_init(d, NULL);
-            if ( rc < 0 )
-                return rc;
-        }
-
-        rc = prepare_dtb_domU(d, &kinfo);
-        if ( rc < 0 )
-            return rc;
-
-        rc = construct_domain(d, &kinfo);
+        rc = domain_vpl011_init(d, NULL);
         if ( rc < 0 )
             return rc;
     }
 
-    domain_vcpu_affinity(d, node);
-
-    return alloc_xenstore_params(&kinfo);
+    return rc;
 }
 
 void __init arch_create_domUs(struct dt_device_node *node,
@@ -995,6 +345,22 @@ void __init arch_create_domUs(struct dt_device_node *node,
     }
 }
 
+int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
+                             const int node_next, const void *pfdt)
+{
+    if ( dt_node_cmp(name, "gic") == 0 )
+    {
+        uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
+
+        if ( phandle_intc != 0 )
+            kinfo->phandle_intc = phandle_intc;
+
+        return 0;
+    }
+
+    return 1;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 203b762e2c..e1d68cb373 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -3,24 +3,43 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 
+#if __has_include()
+#   include 
+#endif
+
+#if __has_include()
+#include 
+#endif
+
+#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
+
 static domid_t __initdata xs_domid = DOMID_INVALID;
+static bool __initdata need_xenstore;
 
 void __init set_xs_domain(struct domain *d)
 {
@@ -109,6 +128,695 @@ static void __init initialize_domU_xenstore(void)
     }
 }
 
+/*
+ * Scan device tree properties for passthrough specific information.
+ * Returns < 0 on error
+ *         0 on success
+ */
+static int __init handle_passthrough_prop(struct kernel_info *kinfo,
+                                          const struct fdt_property *xen_reg,
+                                          const struct fdt_property *xen_path,
+                                          bool xen_force,
+                                          uint32_t address_cells,
+                                          uint32_t size_cells)
+{
+    const __be32 *cell;
+    unsigned int i, len;
+    struct dt_device_node *node;
+    int res;
+    paddr_t mstart, size, gstart;
+
+    /* xen,reg specifies where to map the MMIO region */
+    cell = (const __be32 *)xen_reg->data;
+    len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
+                                        sizeof(uint32_t));
+
+    for ( i = 0; i < len; i++ )
+    {
+        device_tree_get_reg(&cell, address_cells, size_cells,
+                            &mstart, &size);
+        gstart = dt_next_cell(address_cells, &cell);
+
+        if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK )
+        {
+            printk(XENLOG_ERR
+                   "DomU passthrough config has not page aligned addresses/sizes\n");
+            return -EINVAL;
+        }
+
+        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
+                                  paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
+        if ( res )
+        {
+            printk(XENLOG_ERR "Unable to permit to dom%d access to"
+                   " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
+                   kinfo->d->domain_id,
+                   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
+            return res;
+        }
+
+        res = map_regions_p2mt(kinfo->d,
+                               gaddr_to_gfn(gstart),
+                               PFN_DOWN(size),
+                               maddr_to_mfn(mstart),
+                               p2m_mmio_direct_dev);
+        if ( res < 0 )
+        {
+            printk(XENLOG_ERR
+                   "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n",
+                   mstart, gstart);
+            return -EFAULT;
+        }
+    }
+
+    /*
+     * If xen_force, we let the user assign a MMIO region with no
+     * associated path.
+     */
+    if ( xen_path == NULL )
+        return xen_force ? 0 : -EINVAL;
+
+    /*
+     * xen,path specifies the corresponding node in the host DT.
+     * Both interrupt mappings and IOMMU settings are based on it,
+     * as they are done based on the corresponding host DT node.
+     */
+    node = dt_find_node_by_path(xen_path->data);
+    if ( node == NULL )
+    {
+        printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n",
+               xen_path->data);
+        return -EINVAL;
+    }
+
+    res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
+    if ( res < 0 )
+        return res;
+
+    res = iommu_add_dt_device(node);
+    if ( res < 0 )
+        return res;
+
+    /* If xen_force, we allow assignment of devices without IOMMU protection. */
+    if ( xen_force && !dt_device_is_protected(node) )
+        return 0;
+
+    return iommu_assign_dt_device(kinfo->d, node);
+}
+
+static int __init handle_prop_pfdt(struct kernel_info *kinfo,
+                                   const void *pfdt, int nodeoff,
+                                   uint32_t address_cells, uint32_t size_cells,
+                                   bool scan_passthrough_prop)
+{
+    void *fdt = kinfo->fdt;
+    int propoff, nameoff, res;
+    const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL;
+    const char *name;
+    bool found, xen_force = false;
+
+    for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
+          propoff >= 0;
+          propoff = fdt_next_property_offset(pfdt, propoff) )
+    {
+        if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) )
+            return -FDT_ERR_INTERNAL;
+
+        found = false;
+        nameoff = fdt32_to_cpu(prop->nameoff);
+        name = fdt_string(pfdt, nameoff);
+
+        if ( scan_passthrough_prop )
+        {
+            if ( dt_prop_cmp("xen,reg", name) == 0 )
+            {
+                xen_reg = prop;
+                found = true;
+            }
+            else if ( dt_prop_cmp("xen,path", name) == 0 )
+            {
+                xen_path = prop;
+                found = true;
+            }
+            else if ( dt_prop_cmp("xen,force-assign-without-iommu",
+                                  name) == 0 )
+            {
+                xen_force = true;
+                found = true;
+            }
+        }
+
+        /*
+         * Copy properties other than the ones above: xen,reg, xen,path,
+         * and xen,force-assign-without-iommu.
+         */
+        if ( !found )
+        {
+            res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len));
+            if ( res )
+                return res;
+        }
+    }
+
+    /*
+     * Only handle passthrough properties if both xen,reg and xen,path
+     * are present, or if xen,force-assign-without-iommu is specified.
+     */
+    if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
+    {
+        res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
+                                      address_cells, size_cells);
+        if ( res < 0 )
+        {
+            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
+            return res;
+        }
+    }
+    else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
+    {
+        printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
+               kinfo->d);
+        return -EINVAL;
+    }
+
+    /* FDT_ERR_NOTFOUND => There is no more properties for this node */
+    return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
+}
+
+static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt,
+                                 int nodeoff,
+                                 uint32_t address_cells, uint32_t size_cells,
+                                 bool scan_passthrough_prop)
+{
+    int rc = 0;
+    void *fdt = kinfo->fdt;
+    int node_next;
+
+    rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL));
+    if ( rc )
+        return rc;
+
+    rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells,
+                          scan_passthrough_prop);
+    if ( rc )
+        return rc;
+
+    address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells",
+                                        DT_ROOT_NODE_ADDR_CELLS_DEFAULT);
+    size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells",
+                                     DT_ROOT_NODE_SIZE_CELLS_DEFAULT);
+
+    node_next = fdt_first_subnode(pfdt, nodeoff);
+    while ( node_next > 0 )
+    {
+        rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells,
+                            scan_passthrough_prop);
+        if ( rc )
+            return rc;
+
+        node_next = fdt_next_subnode(pfdt, node_next);
+    }
+
+    return fdt_end_node(fdt);
+}
+
+static int __init check_partial_fdt(void *pfdt, size_t size)
+{
+    int res;
+
+    if ( fdt_magic(pfdt) != FDT_MAGIC )
+    {
+        dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree");
+        return -EINVAL;
+    }
+
+    res = fdt_check_header(pfdt);
+    if ( res )
+    {
+        dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res);
+        return -EINVAL;
+    }
+
+    if ( fdt_totalsize(pfdt) > size )
+    {
+        dprintk(XENLOG_ERR, "Partial FDT totalsize is too big");
+        return -EINVAL;
+    }
+
+    return 0;
+}
+
+static int __init domain_handle_dtb_bootmodule(struct domain *d,
+                                               struct kernel_info *kinfo)
+{
+    void *pfdt;
+    int res, node_next;
+
+    pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
+                         kinfo->dtb_bootmodule->size);
+    if ( pfdt == NULL )
+        return -EFAULT;
+
+    res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size);
+    if ( res < 0 )
+        goto out;
+
+    for ( node_next = fdt_first_subnode(pfdt, 0);
+          node_next > 0;
+          node_next = fdt_next_subnode(pfdt, node_next) )
+    {
+        const char *name = fdt_get_name(pfdt, node_next, NULL);
+
+        if ( name == NULL )
+            continue;
+
+        /*
+         * Only scan /$(interrupt_controller) /aliases /passthrough,
+         * ignore the rest.
+         * They don't have to be parsed in order.
+         *
+         * Take the interrupt controller phandle value from the special
+         * interrupt controller node in the DTB fragment.
+         */
+        if ( init_intc_phandle(kinfo, name, node_next, pfdt) == 0 )
+            continue;
+
+        if ( dt_node_cmp(name, "aliases") == 0 )
+        {
+            res = scan_pfdt_node(kinfo, pfdt, node_next,
+                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
+                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
+                                 false);
+            if ( res )
+                goto out;
+            continue;
+        }
+        if ( dt_node_cmp(name, "passthrough") == 0 )
+        {
+            res = scan_pfdt_node(kinfo, pfdt, node_next,
+                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
+                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
+                                 true);
+            if ( res )
+                goto out;
+            continue;
+        }
+    }
+
+ out:
+    iounmap(pfdt);
+
+    return res;
+}
+
+/*
+ * The max size for DT is 2MB. However, the generated DT is small (not including
+ * domU passthrough DT nodes whose size we account separately), 4KB are enough
+ * for now, but we might have to increase it in the future.
+ */
+#define DOMU_DTB_SIZE 4096
+static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
+{
+    int addrcells, sizecells;
+    int ret, fdt_size = DOMU_DTB_SIZE;
+
+    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
+
+#ifdef CONFIG_GRANT_TABLE
+    kinfo->gnttab_start = GUEST_GNTTAB_BASE;
+    kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
+#endif
+
+    addrcells = GUEST_ROOT_ADDRESS_CELLS;
+    sizecells = GUEST_ROOT_SIZE_CELLS;
+
+    /* Account for domU passthrough DT size */
+    if ( kinfo->dtb_bootmodule )
+        fdt_size += kinfo->dtb_bootmodule->size;
+
+    /* Cap to max DT size if needed */
+    fdt_size = min(fdt_size, SZ_2M);
+
+    kinfo->fdt = xmalloc_bytes(fdt_size);
+    if ( kinfo->fdt == NULL )
+        return -ENOMEM;
+
+    ret = fdt_create(kinfo->fdt, fdt_size);
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_finish_reservemap(kinfo->fdt);
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_begin_node(kinfo->fdt, "");
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells);
+    if ( ret )
+        goto err;
+
+    ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells);
+    if ( ret )
+        goto err;
+
+    ret = make_chosen_node(kinfo);
+    if ( ret )
+        goto err;
+
+    ret = make_cpus_node(d, kinfo->fdt);
+    if ( ret )
+        goto err;
+
+    ret = make_memory_node(kinfo, addrcells, sizecells,
+                           kernel_info_get_mem(kinfo));
+    if ( ret )
+        goto err;
+
+#ifdef CONFIG_STATIC_SHM
+    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
+    if ( ret )
+        goto err;
+#endif
+
+    /*
+     * domain_handle_dtb_bootmodule has to be called before the rest of
+     * the device tree is generated because it depends on the value of
+     * the field phandle_intc.
+     */
+    if ( kinfo->dtb_bootmodule )
+    {
+        ret = domain_handle_dtb_bootmodule(d, kinfo);
+        if ( ret )
+            goto err;
+    }
+
+    ret = make_intc_domU_node(kinfo);
+    if ( ret )
+        goto err;
+
+    ret = make_timer_node(kinfo);
+    if ( ret )
+        goto err;
+
+    if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
+    {
+        ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
+        if ( ret )
+            goto err;
+    }
+
+    ret = make_arch_nodes(kinfo);
+    if ( ret )
+        goto err;
+
+    ret = fdt_end_node(kinfo->fdt);
+    if ( ret < 0 )
+        goto err;
+
+    ret = fdt_finish(kinfo->fdt);
+    if ( ret < 0 )
+        goto err;
+
+    return 0;
+
+  err:
+    printk("Device tree generation failed (%d).\n", ret);
+    xfree(kinfo->fdt);
+
+    return -EINVAL;
+}
+
+#define XENSTORE_PFN_OFFSET 1
+static int __init alloc_xenstore_page(struct domain *d)
+{
+    struct page_info *xenstore_pg;
+    struct xenstore_domain_interface *interface;
+    mfn_t mfn;
+    gfn_t gfn;
+    int rc;
+
+    if ( (UINT_MAX - d->max_pages) < 1 )
+    {
+        printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n",
+               d);
+        return -EINVAL;
+    }
+
+    d->max_pages += 1;
+    xenstore_pg = alloc_domheap_page(d, MEMF_bits(32));
+    if ( xenstore_pg == NULL && is_64bit_domain(d) )
+        xenstore_pg = alloc_domheap_page(d, 0);
+    if ( xenstore_pg == NULL )
+        return -ENOMEM;
+
+    mfn = page_to_mfn(xenstore_pg);
+    if ( !mfn_x(mfn) )
+        return -ENOMEM;
+
+    if ( !is_domain_direct_mapped(d) )
+        gfn = gaddr_to_gfn(GUEST_MAGIC_BASE +
+                           (XENSTORE_PFN_OFFSET << PAGE_SHIFT));
+    else
+        gfn = gaddr_to_gfn(mfn_to_maddr(mfn));
+
+    rc = guest_physmap_add_page(d, gfn, mfn, 0);
+    if ( rc )
+    {
+        free_domheap_page(xenstore_pg);
+        return rc;
+    }
+
+#ifdef CONFIG_HVM
+    d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn);
+#endif
+    interface = map_domain_page(mfn);
+    interface->connection = XENSTORE_RECONNECT;
+    unmap_domain_page(interface);
+
+    return 0;
+}
+
+static int __init alloc_xenstore_params(struct kernel_info *kinfo)
+{
+    struct domain *d = kinfo->d;
+    int rc = 0;
+
+#ifdef CONFIG_HVM
+    if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY))
+                                 == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) )
+        d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC;
+    else
+#endif
+    if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE )
+    {
+        rc = alloc_xenstore_page(d);
+        if ( rc < 0 )
+            return rc;
+    }
+
+    return rc;
+}
+
+static void __init domain_vcpu_affinity(struct domain *d,
+                                        const struct dt_device_node *node)
+{
+    struct dt_device_node *np;
+
+    dt_for_each_child_node(node, np)
+    {
+        const char *hard_affinity_str = NULL;
+        uint32_t val;
+        int rc;
+        struct vcpu *v;
+        cpumask_t affinity;
+
+        if ( !dt_device_is_compatible(np, "xen,vcpu") )
+            continue;
+
+        if ( !dt_property_read_u32(np, "id", &val) )
+            panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node));
+
+        if ( val >= d->max_vcpus )
+            panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val,
+                  dt_node_name(node), d->max_vcpus);
+
+        v = d->vcpu[val];
+        rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str);
+        if ( rc < 0 )
+            continue;
+
+        cpumask_clear(&affinity);
+        while ( *hard_affinity_str != '\0' )
+        {
+            unsigned int start, end;
+
+            start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
+
+            if ( *hard_affinity_str == '-' )    /* Range */
+            {
+                hard_affinity_str++;
+                end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
+            }
+            else                /* Single value */
+                end = start;
+
+            if ( end >= nr_cpu_ids )
+                panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node));
+
+            for ( ; start <= end; start++ )
+                cpumask_set_cpu(start, &affinity);
+
+            if ( *hard_affinity_str == ',' )
+                hard_affinity_str++;
+            else if ( *hard_affinity_str != '\0' )
+                break;
+        }
+
+        rc = vcpu_set_hard_affinity(v, &affinity);
+        if ( rc )
+            panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n",
+                  v->vcpu_id, rc, dt_node_name(node));
+    }
+}
+
+#ifdef CONFIG_ARCH_PAGING_MEMPOOL
+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);
+
+    BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
+
+    return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT);
+}
+
+static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem,
+                                            const struct dt_device_node *node)
+{
+    unsigned long p2m_pages;
+    uint32_t p2m_mem_mb;
+    int rc;
+
+    rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb);
+    /* If xen,domain-p2m-mem-mb is not specified, use the default value. */
+    p2m_pages = rc ?
+                p2m_mem_mb << (20 - PAGE_SHIFT) :
+                domain_p2m_pages(mem, d->max_vcpus);
+
+    spin_lock(&d->arch.paging.lock);
+    rc = p2m_set_allocation(d, p2m_pages, NULL);
+    spin_unlock(&d->arch.paging.lock);
+
+    return rc;
+}
+#else /* !CONFIG_ARCH_PAGING_MEMPOOL */
+static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
+                                            const struct dt_device_node *node)
+{
+    return 0;
+}
+#endif /* CONFIG_ARCH_PAGING_MEMPOOL */
+
+static int __init construct_domU(struct domain *d,
+                          const struct dt_device_node *node)
+{
+    struct kernel_info kinfo = KERNEL_INFO_INIT;
+    const char *dom0less_enhanced;
+    int rc;
+    u64 mem;
+
+    rc = dt_property_read_u64(node, "memory", &mem);
+    if ( !rc )
+    {
+        printk("Error building DomU: cannot read \"memory\" property\n");
+        return -EINVAL;
+    }
+    kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
+
+    rc = domain_p2m_set_allocation(d, mem, node);
+    if ( rc != 0 )
+        return rc;
+
+    printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
+           d->max_vcpus, mem);
+
+    rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
+    if ( rc == -EILSEQ ||
+         rc == -ENODATA ||
+         (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
+    {
+        need_xenstore = true;
+        kinfo.dom0less_feature = DOM0LESS_ENHANCED;
+    }
+    else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") )
+    {
+        need_xenstore = true;
+        kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY;
+    }
+    else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") )
+        kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS;
+
+    if ( vcpu_create(d, 0) == NULL )
+        return -ENOMEM;
+
+    d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
+
+    kinfo.d = d;
+
+    rc = kernel_probe(&kinfo, node);
+    if ( rc < 0 )
+        return rc;
+
+    set_domain_type(d, &kinfo);
+
+    if ( is_hardware_domain(d) )
+    {
+        rc = construct_hwdom(&kinfo, node);
+        if ( rc < 0 )
+            return rc;
+    }
+    else
+    {
+        if ( !dt_find_property(node, "xen,static-mem", NULL) )
+            allocate_memory(d, &kinfo);
+    #ifdef CONFIG_STATIC_MEMORY
+        else if ( !is_domain_direct_mapped(d) )
+            allocate_static_memory(d, &kinfo, node);
+        else
+            assign_static_memory_11(d, &kinfo, node);
+    #endif
+
+    #ifdef CONFIG_STATIC_SHM
+        rc = process_shm(d, &kinfo, node);
+        if ( rc < 0 )
+            return rc;
+    #endif
+
+        rc = init_vuart(d, &kinfo, node);
+        if ( rc < 0 )
+            return rc;
+
+        rc = prepare_dtb_domU(d, &kinfo);
+        if ( rc < 0 )
+            return rc;
+
+        rc = construct_domain(d, &kinfo);
+        if ( rc < 0 )
+            return rc;
+    }
+
+    domain_vcpu_affinity(d, node);
+
+    return alloc_xenstore_params(&kinfo);
+}
+
 void __init create_domUs(void)
 {
     struct dt_device_node *node;
diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
index 2003be743f..e0ad0429ec 100644
--- a/xen/include/asm-generic/dom0less-build.h
+++ b/xen/include/asm-generic/dom0less-build.h
@@ -12,10 +12,7 @@ struct domain;
 #include 
 
 struct dt_device_node;
-
-/* TODO: remove both when construct_domU() will be moved to common. */
-#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
-extern bool need_xenstore;
+struct kernel_info;
 
 /*
  * List of possible features for dom0less domUs
@@ -49,12 +46,21 @@ void create_domUs(void);
 bool is_dom0less_mode(void);
 void set_xs_domain(struct domain *d);
 
-int construct_domU(struct domain *d, const struct dt_device_node *node);
-
 void arch_create_domUs(struct dt_device_node *node,
                        struct xen_domctl_createdomain *d_cfg,
                        unsigned int flags);
 
+int init_vuart(struct domain *d, struct kernel_info *kinfo,
+               const struct dt_device_node *node);
+
+int make_intc_domU_node(struct kernel_info *kinfo);
+int make_arch_nodes(struct kernel_info *kinfo);
+
+void set_domain_type(struct domain *d, struct kernel_info *kinfo);
+
+int init_intc_phandle(struct kernel_info *kinfo, const char *name,
+                      const int node_next, const void *pfdt);
+
 #else /* !CONFIG_DOM0LESS_BOOT */
 
 static inline void create_domUs(void) {}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 05 18:21:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 18:21:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976316.1363501 (Exim 4.92)
	(envelope-from )
	id 1uC0RX-00043h-Kn; Mon, 05 May 2025 18:21:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976316.1363501; Mon, 05 May 2025 18:21: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 1uC0RX-00043a-HE; Mon, 05 May 2025 18:21:31 +0000
Received: by outflank-mailman (input) for mailman id 976316;
 Mon, 05 May 2025 18:21:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC0Hj-000675-80
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 18:11:23 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5496bc62-29dc-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 20:11:14 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 68D5E43B7A;
 Mon,  5 May 2025 18:11:10 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9C01C4CEE4;
 Mon,  5 May 2025 18:11: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" 
X-Inumbo-ID: 5496bc62-29dc-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746468673;
	bh=Jw+kt6fAdtv0LkN9dBikD9J6ZjCDDIgHaCp38BMu5T0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=FkEQgd5wogulWqxd6k18heqjn0JTj+TLAU+/2LVSgfB6EajNAvaD5cR280OkqbiaP
	 j8tLBnLMxYpr/4ZCBEej5aPqbS6bv04fm1H0xzi1FIQRPdyWWoF3bok+72kpzhHd5q
	 Zck2vjSWZREBbd2si4fJN1KQcRATQOmhKmr+UzfcACPXTmn0WDKzE59tJhd6Gnq2fL
	 iP3GZJ/LUFYpFlPW82Jd/bef/RgJOjVJO7pexRCRE72r7f27JTCls8QVXj+k9Zc1oP
	 y9xCWsjyEAbSmzz5PqD8U4Bsi8mGiPae34ASI/Aysah3z3zBvsq0/IZW8RCY74ouvH
	 snyPtdWAVvS7w==
Date: Mon, 5 May 2025 11:11:10 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Stefano Stabellini , 
    Jan Beulich , 
    "Ragiadakou, Xenia" , 
    Andrew Cooper , jason.andryuk@amd.com, 
    agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
In-Reply-To: 
Message-ID: 
References:  <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>  
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-798408408-1746468672=:3879245"

  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-798408408-1746468672=:3879245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 5 May 2025, Roger Pau Monné wrote:
> On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> > On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
> > > On Mon, 28 Apr 2025, Jan Beulich wrote:
> > > > On 25.04.2025 22:19, Stefano Stabellini wrote:
> > > > > From: Xenia Ragiadakou 
> > > > > 
> > > > > Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> > > > > addresses to firmware or co-processors not behind an IOMMU.
> > > > 
> > > > I definitely don't understand the firmware part: It's subject to the
> > > > same transparent P2M translations as the rest of the VM; it's just
> > > > another piece of software running there.
> > > > 
> > > > "Co-processors not behind an IOMMU" is also interesting; a more
> > > > concrete scenario might be nice, yet I realize you may be limited in
> > > > what you're allowed to say.
> > > 
> > > Sure. On AMD x86 platforms there is a co-processor called PSP running
> > > TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionally to
> > > pass addresses to it.  See drivers/tee/amdtee/ and
> > > include/linux/psp-tee.h in Linux.
> > 
> > We had (have?) similar issue with amdgpu (for integrated graphics) - it
> > uses PSP for loading its firmware. With PV dom0 there is a workaround as
> > dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, but I
> > expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's
> > the one I used for debugging this issue).
> 
> That's ugly, and problematic when used in conjunction with AMD-SEV.
> 
> I wonder if Xen could emulate/mediate some parts of the PSP for dom0
> to use, while allowing Xen to be the sole owner of the device.  Having
> both Xen and dom0 use it (for different purposes) seems like asking
> for trouble.  But I also have no idea how complex the PSP interface
> is, neither whether it would be feasible to emulate the
> interfaces/registers needed for firmware loading.

Let me take a step back from the PSP for a moment. I am not opposed to a
PSP mediator in Xen, but I want to emphasize that the issue is more
general and extends well beyond the PSP.

In my years working in embedded systems, I have consistently seen cases
where Dom0 needs to communicate with something that does not go through
the IOMMU. This could be due to special firmware on a co-processor, a
hardware erratum that prevents proper IOMMU usage, or a high-bandwidth
device that technically supports the IOMMU but performs poorly unless
the IOMMU is disabled. All of these are real-world examples that I have
seen personally.

In my opinion, we definitely need a solution like this patch for Dom0
PVH to function correctly in all scenarios.

Additionally, we could add a PSP mediator in Xen to provide best PSP
support, and also for cases where both Xen and Dom0 need access, but I
cannot fully assess the complexity involved, as I am not very familiar
with the API. Probably it is not going to be simple.

Even with the PSP mediator in place, I would still recommend this patch.
--8323329-798408408-1746468672=:3879245--


From xen-devel-bounces@lists.xenproject.org Mon May 05 19:44:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 19:44:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976342.1363510 (Exim 4.92)
	(envelope-from )
	id 1uC1jx-0007eG-8T; Mon, 05 May 2025 19:44:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976342.1363510; Mon, 05 May 2025 19:44: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 1uC1jx-0007e9-5z; Mon, 05 May 2025 19:44:37 +0000
Received: by outflank-mailman (input) for mailman id 976342;
 Mon, 05 May 2025 19:44:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC1jw-0007e3-28
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 19:44:36 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5cecfa2a-29e9-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 21:44:32 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id AA2364A5A1;
 Mon,  5 May 2025 19:44:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9ABAC4CEE4;
 Mon,  5 May 2025 19:44: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" 
X-Inumbo-ID: 5cecfa2a-29e9-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746474270;
	bh=OA60VWp0llEUQpPM/Acri1qpDoUSmwYiYugg4nz4CZ8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=VQo3euLvozySondpySpsUj3pJ2eXh0ez+CM97pmQVbEidIWWkcVAyxVwjBgH24Bdr
	 i/VGuYZuos/9kTyCaH20vTzj9olf63YoVghd6xG1Y2TNtSUCyL4qqRHZ3hVSitUdGY
	 hSqoHX1hdHHl5ypr8LJyykx7YbRFvsdQybnMuYnugJlCBtZgXhNeD4ynQ+ISjUiI6W
	 ntxiU3CdEtCEpK8ZafGlSnU1uaRMdTe2eOqMl3dOsuZDiU5N0xIiC1dQ446/gcsuQh
	 MKJERQIl0gbb4No+UbcTRlNbjFttScxvY7gD+E9jIxrksayDDoi4DFYhxk/cFX+WWs
	 BkvZIizArb11g==
Date: Mon, 5 May 2025 12:44:27 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Xen-devel , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Roberto Bagnara , 
    Nicola Vetrini , 
    "consulting @ bugseng . com" 
Subject: Re: [PATCH] xen: Use __auto_type
In-Reply-To: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
Message-ID: 
References: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1097180844-1746474270=:3879245"

  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-1097180844-1746474270=:3879245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 5 May 2025, Andrew Cooper wrote:
> In macros it is common to declare local variables using typeof(param) in order
> to ensure that side effects are only evaluated once.  A consequence of this is
> double textural expansion of the parameter, which can get out of hand very
> quickly with nested macros.
> 
> A GCC extension, __auto_type, is now avaialble in the new toolchain baseline
> and avoids the double textural expansion.

I think this is a good 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 
> CC: Roberto Bagnara 
> CC: Nicola Vetrini 
> CC: consulting@bugseng.com 
> 
> The resulting build is identical.
> 
> RFC.  This requires a MISRA change, as it currently manifests as a R1.1
> violation.  Nevertheless, I think we want to start using in places where we
> currently use typeof(expression of ).
> 
> Eclair run on this patch (expecting a failure):
>   https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1800631949
> 
> Min toolchain check:
>   https://godbolt.org/z/f9WjooPYj
> 
> GCC Manual:
>   https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Auto-Type.html
> ---
>  xen/include/xen/macros.h | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/include/xen/macros.h b/xen/include/xen/macros.h
> index cd528fbdb127..b5e5ff4b1c2f 100644
> --- a/xen/include/xen/macros.h
> +++ b/xen/include/xen/macros.h
> @@ -71,18 +71,18 @@
>  /* Hide a value from the optimiser. */
>  #define HIDE(x)                                 \
>      ({                                          \
> -        typeof(x) _x = (x);                     \
> +        __auto_type _x = (x);                   \
>          asm volatile ( "" : "+r" (_x) );        \
>          _x;                                     \
>      })
>  
>  #define ABS(x) ({                              \
> -    typeof(x) x_ = (x);                        \
> +    __auto_type x_ = (x);                      \
>      (x_ < 0) ? -x_ : x_;                       \
>  })
>  
>  #define SWAP(a, b) \
> -   do { typeof(a) t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
> +   do { __auto_type t_ = (a); (a) = (b); (b) = t_; } while ( 0 )
>  
>  #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + __must_be_array(x))
>  
> @@ -110,15 +110,15 @@
>   */
>  #define min(x, y)                               \
>      ({                                          \
> -        const typeof(x) _x = (x);               \
> -        const typeof(y) _y = (y);               \
> +        const __auto_type _x = (x);             \
> +        const __auto_type _y = (y);             \
>          (void)(&_x == &_y); /* typecheck */     \
>          _x < _y ? _x : _y;                      \
>      })
>  #define max(x, y)                               \
>      ({                                          \
> -        const typeof(x) _x = (x);               \
> -        const typeof(y) _y = (y);               \
> +        const __auto_type _x = (x);             \
> +        const __auto_type _y = (y);             \
>          (void)(&_x == &_y); /* typecheck */     \
>          _x > _y ? _x : _y;                      \
>      })
> 
> base-commit: 78ce2be733b1e45e2e190c1765fe31da318d435f
> -- 
> 2.39.5
> 
--8323329-1097180844-1746474270=:3879245--


From xen-devel-bounces@lists.xenproject.org Mon May 05 19:51:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 19:51:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976355.1363521 (Exim 4.92)
	(envelope-from )
	id 1uC1qN-0000sm-06; Mon, 05 May 2025 19:51:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976355.1363521; Mon, 05 May 2025 19:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uC1qM-0000sf-SN; Mon, 05 May 2025 19:51:14 +0000
Received: by outflank-mailman (input) for mailman id 976355;
 Mon, 05 May 2025 19:51:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC1qL-0000sZ-FR
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 19:51:13 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4aac6a59-29ea-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 21:51:11 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id F18705C58F9;
 Mon,  5 May 2025 19:48:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73801C4CEE4;
 Mon,  5 May 2025 19:51: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" 
X-Inumbo-ID: 4aac6a59-29ea-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746474668;
	bh=L5JU1f17MQAAFxdWsVzAj7rxAFtDBmBQnvQJHA42sgE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=tuZP3XN0CqozriUzBDrR2sIwJ4KnSLE/Fn5FOJx33QOdp84qlhb1tgWg+Fy0Fod81
	 5Jd6vmox1SSXi4RwNzEIQDrQ+nzNu1TjNUrQaJATcDD/TnNNTU3TgyjKAvN+SGvJK4
	 Zku/E22+Vu/5HcER8WXXXhWSzrs37yamK080uTy6TAG3+AbXniS0h17CwYseEG1yCH
	 k7S12gBIGOk3CAEoii0/xyCZWlrTvRZOef1lTbOPiUC9OMsMAVNvR9ZpRuhkXGNpQx
	 Zwpfpf9c4hnMq3G6jndglNw82rI+pIFw5clzyBLLfDlmN3q+tsRJDCme4ooB5qq2Ws
	 gKJz+l/459SGQ==
Date: Mon, 5 May 2025 12:51:06 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Kurochko 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v4 3/8] asm-generic: move parts of Arm's asm/kernel.h to
 common code
In-Reply-To: <578b923f4103e312f3840619bb286d3dba39300b.1746468003.git.oleksii.kurochko@gmail.com>
Message-ID: 
References:  <578b923f4103e312f3840619bb286d3dba39300b.1746468003.git.oleksii.kurochko@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 5 May 2025, Oleksii Kurochko wrote:
> Move the following parts to common with the following changes:
> - struct kernel_info:
>   - Create arch_kernel_info for arch specific kernel information.
>     At the moment, it contains domain_type for Arm.
>   - s/phandle_gic/phandle_intc to have more generic name suitable for other
>     archs.
>   - Make text_offset of zimage structure available for RISCV_64.
> - Wrap by `#ifdef KERNEL_INFO_SHM_MEM_INIT` definition of KERNEL_SHM_MEM_INIT
>   and wrap by `#ifndef KERNEL_INFO_INIT` definition of KERNEL_INFO_INIT to have
>   ability to override KERNEL_INFO_SHM_MEM_INIT for arch in case it doesn't
>   want to use generic one.
> - Move DOM0LESS_* macros to dom0less-build.h.
> - Move all others parts of Arm's kernel.h to xen/fdt-kernel.h.
> 
> Because of the changes in struct kernel_info the correspondent parts of Arm's
> code are updated.
> 
> As part of this patch the following clean up happens:
> - Drop asm/setup.h from asm/kernel.h as nothing depends from it.
>   Add inclusion of asm/setup.h for a code which uses device_tree_get_reg() to
>   avoid compilation issues for CONFIG_STATIC_MEMORY and CONFIG_STATIC_SHM.
> - Drop inclusion of asm/kernel.h everywhere except xen/fdt-kernel.h.
> 
> Signed-off-by: Oleksii Kurochko 


Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Mon May 05 19:54:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 19:54:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976366.1363532 (Exim 4.92)
	(envelope-from )
	id 1uC1tF-0001RT-C9; Mon, 05 May 2025 19:54:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976366.1363532; Mon, 05 May 2025 19:54:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uC1tF-0001RM-8Q; Mon, 05 May 2025 19:54:13 +0000
Received: by outflank-mailman (input) for mailman id 976366;
 Mon, 05 May 2025 19:54:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC1tE-0001RG-Bx
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 19:54:12 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b612bd06-29ea-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 21:54:11 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id B14445C0717;
 Mon,  5 May 2025 19:51:52 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1ED7C4CEE4;
 Mon,  5 May 2025 19:54: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" 
X-Inumbo-ID: b612bd06-29ea-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746474849;
	bh=FI7V+8ZY3yhDWgiLgRNVXUBi91dr2BoVnQYvjNbejrk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=VH8r5luMZInYS0Ehg/OUWFKUfVTrO95eBf/5sImLPEaYwzFNDCqRbSsGqnsMbGXec
	 AGr12hfJgCOB3Jg7gNTHQv2Updk5exKhQJ75fx1t6MpdI6LXkU9rvutSunpikUcQQN
	 cU8szMyZxLBagwhDVGP6LnDr5B3Na8uy6sWqIMqblPFTGIFOjyOXGYu+rbm5tiakbw
	 E7JKvm2InGa+G+l6Yll2MkI4tli1q3UoBnz+X6+J+oh+dkKVuPEOC/ZRseKfB2/S8I
	 TPt1dSNZvobDbQvI5VtNFqPypJ9ENPaJQDj1P/YCUgGRB0TEUd4ZHZK1DWtLNiAaHN
	 99poqgtjNnHAQ==
Date: Mon, 5 May 2025 12:54:07 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Kurochko 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk 
Subject: Re: [PATCH v4 4/8] arm/static-shmem.h: drop inclusion of
 asm/setup.h
In-Reply-To: <2b126e4fde36d2a93c4a1ff6cb7266710738340a.1746468003.git.oleksii.kurochko@gmail.com>
Message-ID: 
References:  <2b126e4fde36d2a93c4a1ff6cb7266710738340a.1746468003.git.oleksii.kurochko@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 5 May 2025, Oleksii Kurochko wrote:
> Nothing is dependent from asm/setup.h in asm/static-shmem.h so inclusion of
> asm/setup.h is droped.
> 
> After this drop the following compilation error related to impicit declaration
> of the following functions device_tree_get_reg and map_device_irqs_to_domain,
> device_tree_get_u32 occur during compilation of dom0less-build.c ( as they are
> declared in asm/setup.h ).
> 
> Add inclusion of  in dt-overlay.c as it is using handle_device()
> declared in .
> 
> Signed-off-by: Oleksii Kurochko 


Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Mon May 05 20:07:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 20:07:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976377.1363540 (Exim 4.92)
	(envelope-from )
	id 1uC265-0003Mx-Dc; Mon, 05 May 2025 20:07:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976377.1363540; Mon, 05 May 2025 20: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 1uC265-0003Mq-Ax; Mon, 05 May 2025 20:07:29 +0000
Received: by outflank-mailman (input) for mailman id 976377;
 Mon, 05 May 2025 20:07:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC264-0003Mk-EV
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 20:07:28 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8b20c8e7-29ec-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 22:07:17 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id BD5BA61F1B;
 Mon,  5 May 2025 20:06:44 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5C4DC4CEE4;
 Mon,  5 May 2025 20:07: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" 
X-Inumbo-ID: 8b20c8e7-29ec-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746475636;
	bh=0VGf1wA6wrUQNAP1iK28C/pi619OQRj+cVV0YQpDCss=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=CBn/qjyWKUnpvGn+nQWaFdb1kRaSPtpwGDTIc1BRfs9f3stLMXnCoyiHSO1pc6KBo
	 8kJRbmJ2gjkozgMv3lllh3M6H2+tQsoPEjsx+Bk920tm+Za7ghdMGEdtrYZ5Rn3pJN
	 A9Ks/utWXbk5o2dSyknDIuJlZ/XheIGAaxoi2YcUl/2oIz479+MlTpZaYloOhrRmjb
	 yw/343Q0oiepvL6oMAgGto6wNE6R3R6cQ+JmoGb4TEdHpnUbmuEMreRt8KsuwQp+F4
	 8QbdRsbUMApiwnCCmRSgKlVnupsHrCkEhoq28lw2YSJ2R5mOyV3xNhuELWkxlbMBZM
	 Tue5oLLfFyg4g==
Date: Mon, 5 May 2025 13:07:13 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Kurochko 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v4 7/8] xen/common: dom0less: introduce common
 domain-build.c
In-Reply-To: <0bfc572f0d82e9d81bbc07bab5b6b7fb0d7634f8.1746468003.git.oleksii.kurochko@gmail.com>
Message-ID: 
References:  <0bfc572f0d82e9d81bbc07bab5b6b7fb0d7634f8.1746468003.git.oleksii.kurochko@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 5 May 2025, Oleksii Kurochko wrote:
> Some functions of Arm's domain_build.c could be reused by dom0less or other
> features connected to domain construction/build.
> 
> The following functions are moved to common:
> - get_allocation_size().
> - allocate_domheap_memory().
> - guest_map_pages().
> - allocate_bank_memory().
> - add_hwdom_free_regions().
> - find_unallocated_memory().
> - allocate_memory().
> - dtb_load().
> - initrd_load().
> 
> Prototype of dtb_load() and initrd_load() is updated to recieve a pointer
> to copy_to_guest_phys() as some archs require
> copy_to_guest_phys_fluch_dcache().
> 
> Update arm/include/asm/Makefile to generate  domain-build.h for Arm as it is
> used by domain-build.c.
> 
> Signed-off-by: Oleksii Kurochko 


Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Mon May 05 20:13:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 20:13:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976388.1363552 (Exim 4.92)
	(envelope-from )
	id 1uC2BN-00052Z-1H; Mon, 05 May 2025 20:12:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976388.1363552; Mon, 05 May 2025 20:12: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 1uC2BM-00052S-T6; Mon, 05 May 2025 20:12:56 +0000
Received: by outflank-mailman (input) for mailman id 976388;
 Mon, 05 May 2025 20:12:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC2BL-00052M-1P
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 20:12:55 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 503a5dbe-29ed-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 22:12:48 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 9E952A4C6B7;
 Mon,  5 May 2025 20:07:19 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66D40C4CEED;
 Mon,  5 May 2025 20:12: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" 
X-Inumbo-ID: 503a5dbe-29ed-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746475967;
	bh=50Xf3Vdbo82GmsYHIByG5J5OTCTH6M9yCAhuE8fae1Q=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=KPindAfj9F458mL6qKiH/sOp82wWg/SdUJe4t9HkrkLxdf8votRNNHofcpWLI3oyx
	 hA1CIoh9LwA8PkpB/GFTy6budOu3Q+qIviLBJEJiYo+9ini7rreFFWrXqMqDCb/GDH
	 ZAppf2ygonYdQApVRyy5JFi5kiE48BWfd059nFANZA9P0Os+z9K+heQZP4PgaLDUVl
	 I/+fAQj0I6UXhznFqorzriYhoN3eyAZivIUgsgk/QBYfEqzUWRa24OGbo4xMQiJe3Z
	 zGaQk3clnGKGOd5DROTKOUx3Cp8H27TNaAoTIOT6FaZV6cNlMxHLQqjrwu/wN75C9u
	 giEmZYekvapDg==
Date: Mon, 5 May 2025 13:12:43 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Kurochko 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v4 8/8] xen/common: dom0less: introduce common
 dom0less-build.c
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 5 May 2025, Oleksii Kurochko wrote:
> Part of Arm's dom0less-build.c could be common between architectures which are
> using device tree files to create guest domains. Thereby move some parts of
> Arm's dom0less-build.c to common code with minor changes.
> 
> As a part of theses changes the following changes are introduced:
> - Introduce make_arch_nodes() to cover arch-specific nodes. For example, in
>   case of Arm, it is PSCI and vpl011 nodes.
> - Introduce set_domain_type() to abstract a way how setting of domain type
>   happens. For example, RISC-V won't have this member of arch_domain structure
>   as vCPUs will always have the same bitness as hypervisor. In case of Arm, it
>   is possible that Arm64 could create 32-bit and 64-bit domains.
> - Introduce init_vuart() to cover details of virtual uart initialization.
> - Introduce init_intc_phandle() to cover some details of interrupt controller
>   phandle initialization. As an example, RISC-V could have different name for
>   interrupt controller node ( APLIC, PLIC, IMSIC, etc ) but the code in
>   domain_handle_dtb_bootmodule() could handle only one interrupt controller
>   node name.
> - s/make_gic_domU_node/make_intc_domU_node as GIC is Arm specific naming and
>   add prototype of make_intc_domU_node() to dom0less-build.h
> 
> The following functions are moved to xen/common/device-tree:
> - Functions which are moved as is:
>   - domain_p2m_pages().
>   - handle_passthrough_prop().
>   - handle_prop_pfdt().
>   - scan_pfdt_node().
>   - check_partial_fdt().
> - Functions which are moved with some minor changes:
>   - alloc_xenstore_evtchn():
>     - ifdef-ing by CONFIG_HVM accesses to hvm.params.
>   - prepare_dtb_domU():
>     - ifdef-ing access to gnttab_{start,size} by CONFIG_GRANT_TABLE.
>     - s/make_gic_domU_node/make_intc_domU_node.
>     - Add call of make_arch_nodes().
> - domain_handle_dtb_bootmodule():
>   - hide details of interrupt controller phandle initialization by calling
>     init_intc_phandle().
>   - Update the comment above init_intc_phandle(): s/gic/interrupt controller.
> - construct_domU():
>   - ifdef-ing by CONFIG_HVM accesses to hvm.params.
>   - Call init_vuart() to hide Arm's vpl011_init() details there.
>   - Add call of set_domain_type() instead of setting kinfo->arch.type explicitly.
> 
> Some parts of dom0less-build.c are wraped by #ifdef CONFIG_STATIC_{SHMEM,MEMORY}
> as not all archs support these configs.
> 
> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in v4:
>  - Add a chunk of code, which was introduced in the patch:
>    "xen/arm: dom0less hwdom construction", in moved to common
>    construct_domU(). The part which re-uses construct_hwdom().
>  - Use __has_include() instead of #ifdef-ing for inclusion of
>    asm/static-{memory, shmem}.h in the common code.
> ---
> Change in v3:
>  - Align construct_domU() with the current staging:
>  - Align alloc_xenstore_params() with the current staging.
>  - Move defintion of XENSTORE_PFN_LATE_ALLOC to common and
>    declaration of need_xenstore to common.
> ---
> Change in v2:
>  - Wrap by #ifdef CONFIG_STATIC_* inclusions of  and
>    . Wrap also the code which uses something from the
>    mentioned headers.
>  - Add handling of legacy case in construct_domU().
>  - Use xen/fdt-kernel.h and xen/fdt-domain-build.h instead of asm/*.
>  - Update the commit message.
> ---
>  xen/arch/arm/dom0less-build.c            | 714 ++---------------------
>  xen/common/device-tree/dom0less-build.c  | 708 ++++++++++++++++++++++
>  xen/include/asm-generic/dom0less-build.h |  18 +-
>  3 files changed, 760 insertions(+), 680 deletions(-)
> 
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index 47eb38b9ad..ebb1c58f0e 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -25,8 +25,6 @@
>  #include 
>  #include 
>  
> -bool __initdata need_xenstore;
> -
>  #ifdef CONFIG_VGICV2
>  static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
>  {
> @@ -152,7 +150,7 @@ static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
>  }
>  #endif
>  
> -static int __init make_gic_domU_node(struct kernel_info *kinfo)
> +int __init make_intc_domU_node(struct kernel_info *kinfo)
>  {
>      switch ( kinfo->d->arch.vgic.version )
>      {
> @@ -218,708 +216,60 @@ static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
>  }
>  #endif
>  
> -/*
> - * Scan device tree properties for passthrough specific information.
> - * Returns < 0 on error
> - *         0 on success
> - */
> -static int __init handle_passthrough_prop(struct kernel_info *kinfo,
> -                                          const struct fdt_property *xen_reg,
> -                                          const struct fdt_property *xen_path,
> -                                          bool xen_force,
> -                                          uint32_t address_cells,
> -                                          uint32_t size_cells)
> -{
> -    const __be32 *cell;
> -    unsigned int i, len;
> -    struct dt_device_node *node;
> -    int res;
> -    paddr_t mstart, size, gstart;
> -
> -    /* xen,reg specifies where to map the MMIO region */
> -    cell = (const __be32 *)xen_reg->data;
> -    len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
> -                                        sizeof(uint32_t));
> -
> -    for ( i = 0; i < len; i++ )
> -    {
> -        device_tree_get_reg(&cell, address_cells, size_cells,
> -                            &mstart, &size);
> -        gstart = dt_next_cell(address_cells, &cell);
> -
> -        if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK )
> -        {
> -            printk(XENLOG_ERR
> -                   "DomU passthrough config has not page aligned addresses/sizes\n");
> -            return -EINVAL;
> -        }
> -
> -        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
> -                                  paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
> -        if ( res )
> -        {
> -            printk(XENLOG_ERR "Unable to permit to dom%d access to"
> -                   " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
> -                   kinfo->d->domain_id,
> -                   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
> -            return res;
> -        }
> -
> -        res = map_regions_p2mt(kinfo->d,
> -                               gaddr_to_gfn(gstart),
> -                               PFN_DOWN(size),
> -                               maddr_to_mfn(mstart),
> -                               p2m_mmio_direct_dev);
> -        if ( res < 0 )
> -        {
> -            printk(XENLOG_ERR
> -                   "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n",
> -                   mstart, gstart);
> -            return -EFAULT;
> -        }
> -    }
> -
> -    /*
> -     * If xen_force, we let the user assign a MMIO region with no
> -     * associated path.
> -     */
> -    if ( xen_path == NULL )
> -        return xen_force ? 0 : -EINVAL;
> -
> -    /*
> -     * xen,path specifies the corresponding node in the host DT.
> -     * Both interrupt mappings and IOMMU settings are based on it,
> -     * as they are done based on the corresponding host DT node.
> -     */
> -    node = dt_find_node_by_path(xen_path->data);
> -    if ( node == NULL )
> -    {
> -        printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n",
> -               xen_path->data);
> -        return -EINVAL;
> -    }
> -
> -    res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
> -    if ( res < 0 )
> -        return res;
> -
> -    res = iommu_add_dt_device(node);
> -    if ( res < 0 )
> -        return res;
> -
> -    /* If xen_force, we allow assignment of devices without IOMMU protection. */
> -    if ( xen_force && !dt_device_is_protected(node) )
> -        return 0;
> -
> -    return iommu_assign_dt_device(kinfo->d, node);
> -}
> -
> -static int __init handle_prop_pfdt(struct kernel_info *kinfo,
> -                                   const void *pfdt, int nodeoff,
> -                                   uint32_t address_cells, uint32_t size_cells,
> -                                   bool scan_passthrough_prop)
> -{
> -    void *fdt = kinfo->fdt;
> -    int propoff, nameoff, res;
> -    const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL;
> -    const char *name;
> -    bool found, xen_force = false;
> -
> -    for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
> -          propoff >= 0;
> -          propoff = fdt_next_property_offset(pfdt, propoff) )
> -    {
> -        if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) )
> -            return -FDT_ERR_INTERNAL;
> -
> -        found = false;
> -        nameoff = fdt32_to_cpu(prop->nameoff);
> -        name = fdt_string(pfdt, nameoff);
> -
> -        if ( scan_passthrough_prop )
> -        {
> -            if ( dt_prop_cmp("xen,reg", name) == 0 )
> -            {
> -                xen_reg = prop;
> -                found = true;
> -            }
> -            else if ( dt_prop_cmp("xen,path", name) == 0 )
> -            {
> -                xen_path = prop;
> -                found = true;
> -            }
> -            else if ( dt_prop_cmp("xen,force-assign-without-iommu",
> -                                  name) == 0 )
> -            {
> -                xen_force = true;
> -                found = true;
> -            }
> -        }
> -
> -        /*
> -         * Copy properties other than the ones above: xen,reg, xen,path,
> -         * and xen,force-assign-without-iommu.
> -         */
> -        if ( !found )
> -        {
> -            res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len));
> -            if ( res )
> -                return res;
> -        }
> -    }
> -
> -    /*
> -     * Only handle passthrough properties if both xen,reg and xen,path
> -     * are present, or if xen,force-assign-without-iommu is specified.
> -     */
> -    if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
> -    {
> -        res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
> -                                      address_cells, size_cells);
> -        if ( res < 0 )
> -        {
> -            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
> -            return res;
> -        }
> -    }
> -    else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
> -    {
> -        printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
> -               kinfo->d);
> -        return -EINVAL;
> -    }
> -
> -    /* FDT_ERR_NOTFOUND => There is no more properties for this node */
> -    return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
> -}
> -
> -static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt,
> -                                 int nodeoff,
> -                                 uint32_t address_cells, uint32_t size_cells,
> -                                 bool scan_passthrough_prop)
> -{
> -    int rc = 0;
> -    void *fdt = kinfo->fdt;
> -    int node_next;
> -
> -    rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL));
> -    if ( rc )
> -        return rc;
> -
> -    rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells,
> -                          scan_passthrough_prop);
> -    if ( rc )
> -        return rc;
> -
> -    address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells",
> -                                        DT_ROOT_NODE_ADDR_CELLS_DEFAULT);
> -    size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells",
> -                                     DT_ROOT_NODE_SIZE_CELLS_DEFAULT);
> -
> -    node_next = fdt_first_subnode(pfdt, nodeoff);
> -    while ( node_next > 0 )
> -    {
> -        rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells,
> -                            scan_passthrough_prop);
> -        if ( rc )
> -            return rc;
> -
> -        node_next = fdt_next_subnode(pfdt, node_next);
> -    }
> -
> -    return fdt_end_node(fdt);
> -}
> -
> -static int __init check_partial_fdt(void *pfdt, size_t size)
> +int __init make_arch_nodes(struct kernel_info *kinfo)
>  {
> -    int res;
> -
> -    if ( fdt_magic(pfdt) != FDT_MAGIC )
> -    {
> -        dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree");
> -        return -EINVAL;
> -    }
> -
> -    res = fdt_check_header(pfdt);
> -    if ( res )
> -    {
> -        dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res);
> -        return -EINVAL;
> -    }
> -
> -    if ( fdt_totalsize(pfdt) > size )
> -    {
> -        dprintk(XENLOG_ERR, "Partial FDT totalsize is too big");
> -        return -EINVAL;
> -    }
> -
> -    return 0;
> -}
> -
> -static int __init domain_handle_dtb_bootmodule(struct domain *d,
> -                                               struct kernel_info *kinfo)
> -{
> -    void *pfdt;
> -    int res, node_next;
> -
> -    pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
> -                         kinfo->dtb_bootmodule->size);
> -    if ( pfdt == NULL )
> -        return -EFAULT;
> -
> -    res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size);
> -    if ( res < 0 )
> -        goto out;
> -
> -    for ( node_next = fdt_first_subnode(pfdt, 0);
> -          node_next > 0;
> -          node_next = fdt_next_subnode(pfdt, node_next) )
> -    {
> -        const char *name = fdt_get_name(pfdt, node_next, NULL);
> -
> -        if ( name == NULL )
> -            continue;
> -
> -        /*
> -         * Only scan /gic /aliases /passthrough, ignore the rest.
> -         * They don't have to be parsed in order.
> -         *
> -         * Take the GIC phandle value from the special /gic node in the
> -         * DTB fragment.
> -         */
> -        if ( dt_node_cmp(name, "gic") == 0 )
> -        {
> -            uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
> -
> -            if ( phandle_intc != 0 )
> -                kinfo->phandle_intc = phandle_intc;
> -            continue;
> -        }
> -
> -        if ( dt_node_cmp(name, "aliases") == 0 )
> -        {
> -            res = scan_pfdt_node(kinfo, pfdt, node_next,
> -                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
> -                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
> -                                 false);
> -            if ( res )
> -                goto out;
> -            continue;
> -        }
> -        if ( dt_node_cmp(name, "passthrough") == 0 )
> -        {
> -            res = scan_pfdt_node(kinfo, pfdt, node_next,
> -                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
> -                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
> -                                 true);
> -            if ( res )
> -                goto out;
> -            continue;
> -        }
> -    }
> -
> - out:
> -    iounmap(pfdt);
> -
> -    return res;
> -}
> -
> -/*
> - * The max size for DT is 2MB. However, the generated DT is small (not including
> - * domU passthrough DT nodes whose size we account separately), 4KB are enough
> - * for now, but we might have to increase it in the future.
> - */
> -#define DOMU_DTB_SIZE 4096
> -static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
> -{
> -    int addrcells, sizecells;
> -    int ret, fdt_size = DOMU_DTB_SIZE;
> -
> -    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
> -    kinfo->gnttab_start = GUEST_GNTTAB_BASE;
> -    kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
> -
> -    addrcells = GUEST_ROOT_ADDRESS_CELLS;
> -    sizecells = GUEST_ROOT_SIZE_CELLS;
> -
> -    /* Account for domU passthrough DT size */
> -    if ( kinfo->dtb_bootmodule )
> -        fdt_size += kinfo->dtb_bootmodule->size;
> -
> -    /* Cap to max DT size if needed */
> -    fdt_size = min(fdt_size, SZ_2M);
> -
> -    kinfo->fdt = xmalloc_bytes(fdt_size);
> -    if ( kinfo->fdt == NULL )
> -        return -ENOMEM;
> -
> -    ret = fdt_create(kinfo->fdt, fdt_size);
> -    if ( ret < 0 )
> -        goto err;
> -
> -    ret = fdt_finish_reservemap(kinfo->fdt);
> -    if ( ret < 0 )
> -        goto err;
> -
> -    ret = fdt_begin_node(kinfo->fdt, "");
> -    if ( ret < 0 )
> -        goto err;
> -
> -    ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells);
> -    if ( ret )
> -        goto err;
> -
> -    ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells);
> -    if ( ret )
> -        goto err;
> -
> -    ret = make_chosen_node(kinfo);
> -    if ( ret )
> -        goto err;
> +    int ret;
>  
>      ret = make_psci_node(kinfo->fdt);
>      if ( ret )
> -        goto err;
> -
> -    ret = make_cpus_node(d, kinfo->fdt);
> -    if ( ret )
> -        goto err;
> -
> -    ret = make_memory_node(kinfo, addrcells, sizecells,
> -                           kernel_info_get_mem(kinfo));
> -    if ( ret )
> -        goto err;
> -
> -    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
> -    if ( ret )
> -        goto err;
> -
> -    /*
> -     * domain_handle_dtb_bootmodule has to be called before the rest of
> -     * the device tree is generated because it depends on the value of
> -     * the field phandle_intc.
> -     */
> -    if ( kinfo->dtb_bootmodule )
> -    {
> -        ret = domain_handle_dtb_bootmodule(d, kinfo);
> -        if ( ret )
> -            goto err;
> -    }
> -
> -    ret = make_gic_domU_node(kinfo);
> -    if ( ret )
> -        goto err;
> -
> -    ret = make_timer_node(kinfo);
> -    if ( ret )
> -        goto err;
> +        return -EINVAL;
>  
>      if ( kinfo->arch.vpl011 )
>      {
> -        ret = -EINVAL;
>  #ifdef CONFIG_SBSA_VUART_CONSOLE
>          ret = make_vpl011_uart_node(kinfo);
>  #endif
>          if ( ret )
> -            goto err;
> -    }
> -
> -    if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
> -    {
> -        ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
> -        if ( ret )
> -            goto err;
> +            return -EINVAL;
>      }
>  
> -    ret = fdt_end_node(kinfo->fdt);
> -    if ( ret < 0 )
> -        goto err;
> -
> -    ret = fdt_finish(kinfo->fdt);
> -    if ( ret < 0 )
> -        goto err;
> -
>      return 0;
> -
> -  err:
> -    printk("Device tree generation failed (%d).\n", ret);
> -    xfree(kinfo->fdt);
> -
> -    return -EINVAL;
>  }
>  
> -#define XENSTORE_PFN_OFFSET 1
> -static int __init alloc_xenstore_page(struct domain *d)
> +/* TODO: make arch.type generic ? */
> +#ifdef CONFIG_ARM_64
> +void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
>  {
> -    struct page_info *xenstore_pg;
> -    struct xenstore_domain_interface *interface;
> -    mfn_t mfn;
> -    gfn_t gfn;
> -    int rc;
> -
> -    if ( (UINT_MAX - d->max_pages) < 1 )
> -    {
> -        printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n",
> -               d);
> -        return -EINVAL;
> -    }
> -
> -    d->max_pages += 1;
> -    xenstore_pg = alloc_domheap_page(d, MEMF_bits(32));
> -    if ( xenstore_pg == NULL && is_64bit_domain(d) )
> -        xenstore_pg = alloc_domheap_page(d, 0);
> -    if ( xenstore_pg == NULL )
> -        return -ENOMEM;
> -
> -    mfn = page_to_mfn(xenstore_pg);
> -    if ( !mfn_x(mfn) )
> -        return -ENOMEM;
> -
> -    if ( !is_domain_direct_mapped(d) )
> -        gfn = gaddr_to_gfn(GUEST_MAGIC_BASE +
> -                           (XENSTORE_PFN_OFFSET << PAGE_SHIFT));
> -    else
> -        gfn = gaddr_to_gfn(mfn_to_maddr(mfn));
> -
> -    rc = guest_physmap_add_page(d, gfn, mfn, 0);
> -    if ( rc )
> -    {
> -        free_domheap_page(xenstore_pg);
> -        return rc;
> -    }
> -
> -    d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn);
> -    interface = map_domain_page(mfn);
> -    interface->connection = XENSTORE_RECONNECT;
> -    unmap_domain_page(interface);
> -
> -    return 0;
> +    /* type must be set before allocate memory */
> +    d->arch.type = kinfo->arch.type;
>  }
> -
> -static int __init alloc_xenstore_params(struct kernel_info *kinfo)
> +#else
> +void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
>  {
> -    struct domain *d = kinfo->d;
> -    int rc = 0;
> -
> -    if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY))
> -                                 == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) )
> -        d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC;
> -    else if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE )
> -    {
> -        rc = alloc_xenstore_page(d);
> -        if ( rc < 0 )
> -            return rc;
> -    }
> -
> -    return rc;
> +    /* Nothing to do */
>  }
> +#endif
>  
> -static void __init domain_vcpu_affinity(struct domain *d,
> -                                        const struct dt_device_node *node)
> +int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
> +                      const struct dt_device_node *node)
>  {
> -    struct dt_device_node *np;
> -
> -    dt_for_each_child_node(node, np)
> -    {
> -        const char *hard_affinity_str = NULL;
> -        uint32_t val;
> -        int rc;
> -        struct vcpu *v;
> -        cpumask_t affinity;
> -
> -        if ( !dt_device_is_compatible(np, "xen,vcpu") )
> -            continue;
> -
> -        if ( !dt_property_read_u32(np, "id", &val) )
> -            panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node));
> -
> -        if ( val >= d->max_vcpus )
> -            panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val,
> -                  dt_node_name(node), d->max_vcpus);
> -
> -        v = d->vcpu[val];
> -        rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str);
> -        if ( rc < 0 )
> -            continue;
> -
> -        cpumask_clear(&affinity);
> -        while ( *hard_affinity_str != '\0' )
> -        {
> -            unsigned int start, end;
> -
> -            start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
> -
> -            if ( *hard_affinity_str == '-' )    /* Range */
> -            {
> -                hard_affinity_str++;
> -                end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
> -            }
> -            else                /* Single value */
> -                end = start;
> -
> -            if ( end >= nr_cpu_ids )
> -                panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node));
> -
> -            for ( ; start <= end; start++ )
> -                cpumask_set_cpu(start, &affinity);
> -
> -            if ( *hard_affinity_str == ',' )
> -                hard_affinity_str++;
> -            else if ( *hard_affinity_str != '\0' )
> -                break;
> -        }
> +    int rc = 0;
>  
> -        rc = vcpu_set_hard_affinity(v, &affinity);
> -        if ( rc )
> -            panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n",
> -                  v->vcpu_id, rc, dt_node_name(node));
> -    }
> -}
> +    kinfo->arch.vpl011 = dt_property_read_bool(node, "vpl011");
>  
> -#ifdef CONFIG_ARCH_PAGING_MEMPOOL
> -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.
> +     * Base address and irq number are needed when creating vpl011 device
> +     * tree node in prepare_dtb_domU, so initialization on related variables
> +     * shall be done first.
>       */
> -    unsigned long memkb = 4 * (256 * smp_cpus + (maxmem_kb / 1024) + 128);
> -
> -    BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
> -
> -    return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT);
> -}
> -
> -static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem,
> -                                            const struct dt_device_node *node)
> -{
> -    unsigned long p2m_pages;
> -    uint32_t p2m_mem_mb;
> -    int rc;
> -
> -    rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb);
> -    /* If xen,domain-p2m-mem-mb is not specified, use the default value. */
> -    p2m_pages = rc ?
> -                p2m_mem_mb << (20 - PAGE_SHIFT) :
> -                domain_p2m_pages(mem, d->max_vcpus);
> -
> -    spin_lock(&d->arch.paging.lock);
> -    rc = p2m_set_allocation(d, p2m_pages, NULL);
> -    spin_unlock(&d->arch.paging.lock);
> -
> -    return rc;
> -}
> -#else /* !CONFIG_ARCH_PAGING_MEMPOOL */
> -static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
> -                                            const struct dt_device_node *node)
> -{
> -    return 0;
> -}
> -#endif /* CONFIG_ARCH_PAGING_MEMPOOL */
> -
> -int __init construct_domU(struct domain *d,
> -                          const struct dt_device_node *node)
> -{
> -    struct kernel_info kinfo = KERNEL_INFO_INIT;
> -    const char *dom0less_enhanced;
> -    int rc;
> -    u64 mem;
> -
> -    rc = dt_property_read_u64(node, "memory", &mem);
> -    if ( !rc )
> -    {
> -        printk("Error building DomU: cannot read \"memory\" property\n");
> -        return -EINVAL;
> -    }
> -    kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
> -
> -    rc = domain_p2m_set_allocation(d, mem, node);
> -    if ( rc != 0 )
> -        return rc;
> -
> -    printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
> -           d->max_vcpus, mem);
> -
> -    kinfo.arch.vpl011  = dt_property_read_bool(node, "vpl011");
> -    if ( kinfo.arch.vpl011  && is_hardware_domain(d) )
> -        panic("hardware domain cannot specify vpl011\n");
> -
> -    rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
> -    if ( rc == -EILSEQ ||
> -         rc == -ENODATA ||
> -         (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
> -    {
> -        need_xenstore = true;
> -        kinfo.dom0less_feature = DOM0LESS_ENHANCED;
> -    }
> -    else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") )
> -    {
> -        need_xenstore = true;
> -        kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY;
> -    }
> -    else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") )
> -        kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS;
> -
> -    if ( vcpu_create(d, 0) == NULL )
> -        return -ENOMEM;
> -
> -    d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
> -
> -    kinfo.d = d;
> -
> -    rc = kernel_probe(&kinfo, node);
> -    if ( rc < 0 )
> -        return rc;
> -
> -#ifdef CONFIG_ARM_64
> -    /* type must be set before allocate memory */
> -    d->arch.type = kinfo.arch.type;
> -#endif
> -    if ( is_hardware_domain(d) )
> -    {
> -        rc = construct_hwdom(&kinfo, node);
> -        if ( rc < 0 )
> -            return rc;
> -    }
> -    else
> +    if ( kinfo->arch.vpl011 )
>      {
> -        if ( !dt_find_property(node, "xen,static-mem", NULL) )
> -            allocate_memory(d, &kinfo);
> -        else if ( !is_domain_direct_mapped(d) )
> -            allocate_static_memory(d, &kinfo, node);
> -        else
> -            assign_static_memory_11(d, &kinfo, node);
> -
> -        rc = process_shm(d, &kinfo, node);
> -        if ( rc < 0 )
> -            return rc;
> -
> -        /*
> -         * Base address and irq number are needed when creating vpl011 device
> -         * tree node in prepare_dtb_domU, so initialization on related variables
> -         * shall be done first.
> -         */
> -        if ( kinfo.arch.vpl011  )
> -        {
> -            rc = domain_vpl011_init(d, NULL);
> -            if ( rc < 0 )
> -                return rc;
> -        }
> -
> -        rc = prepare_dtb_domU(d, &kinfo);
> -        if ( rc < 0 )
> -            return rc;
> -
> -        rc = construct_domain(d, &kinfo);
> +        rc = domain_vpl011_init(d, NULL);
>          if ( rc < 0 )
>              return rc;
>      }
>  
> -    domain_vcpu_affinity(d, node);
> -
> -    return alloc_xenstore_params(&kinfo);
> +    return rc;
>  }
>  
>  void __init arch_create_domUs(struct dt_device_node *node,
> @@ -995,6 +345,22 @@ void __init arch_create_domUs(struct dt_device_node *node,
>      }
>  }
>  
> +int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
> +                             const int node_next, const void *pfdt)
> +{
> +    if ( dt_node_cmp(name, "gic") == 0 )
> +    {
> +        uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
> +
> +        if ( phandle_intc != 0 )
> +            kinfo->phandle_intc = phandle_intc;
> +
> +        return 0;
> +    }
> +
> +    return 1;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 203b762e2c..e1d68cb373 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -3,24 +3,43 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
>  
> +#if __has_include()
> +#   include 
> +#endif
> +
> +#if __has_include()
> +#include 

NIT: code style. I can fix on commit.



> +#endif
> +
> +#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
> +
>  static domid_t __initdata xs_domid = DOMID_INVALID;
> +static bool __initdata need_xenstore;
>  
>  void __init set_xs_domain(struct domain *d)
>  {
> @@ -109,6 +128,695 @@ static void __init initialize_domU_xenstore(void)
>      }
>  }
>  
> +/*
> + * Scan device tree properties for passthrough specific information.
> + * Returns < 0 on error
> + *         0 on success
> + */
> +static int __init handle_passthrough_prop(struct kernel_info *kinfo,
> +                                          const struct fdt_property *xen_reg,
> +                                          const struct fdt_property *xen_path,
> +                                          bool xen_force,
> +                                          uint32_t address_cells,
> +                                          uint32_t size_cells)
> +{
> +    const __be32 *cell;
> +    unsigned int i, len;
> +    struct dt_device_node *node;
> +    int res;
> +    paddr_t mstart, size, gstart;
> +
> +    /* xen,reg specifies where to map the MMIO region */
> +    cell = (const __be32 *)xen_reg->data;
> +    len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
> +                                        sizeof(uint32_t));
> +
> +    for ( i = 0; i < len; i++ )
> +    {
> +        device_tree_get_reg(&cell, address_cells, size_cells,
> +                            &mstart, &size);
> +        gstart = dt_next_cell(address_cells, &cell);
> +
> +        if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK )
> +        {
> +            printk(XENLOG_ERR
> +                   "DomU passthrough config has not page aligned addresses/sizes\n");
> +            return -EINVAL;
> +        }
> +
> +        res = iomem_permit_access(kinfo->d, paddr_to_pfn(mstart),
> +                                  paddr_to_pfn(PAGE_ALIGN(mstart + size - 1)));
> +        if ( res )
> +        {
> +            printk(XENLOG_ERR "Unable to permit to dom%d access to"
> +                   " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
> +                   kinfo->d->domain_id,
> +                   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
> +            return res;
> +        }
> +
> +        res = map_regions_p2mt(kinfo->d,
> +                               gaddr_to_gfn(gstart),
> +                               PFN_DOWN(size),
> +                               maddr_to_mfn(mstart),
> +                               p2m_mmio_direct_dev);
> +        if ( res < 0 )
> +        {
> +            printk(XENLOG_ERR
> +                   "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n",
> +                   mstart, gstart);
> +            return -EFAULT;
> +        }
> +    }
> +
> +    /*
> +     * If xen_force, we let the user assign a MMIO region with no
> +     * associated path.
> +     */
> +    if ( xen_path == NULL )
> +        return xen_force ? 0 : -EINVAL;
> +
> +    /*
> +     * xen,path specifies the corresponding node in the host DT.
> +     * Both interrupt mappings and IOMMU settings are based on it,
> +     * as they are done based on the corresponding host DT node.
> +     */
> +    node = dt_find_node_by_path(xen_path->data);
> +    if ( node == NULL )
> +    {
> +        printk(XENLOG_ERR "Couldn't find node %s in host_dt!\n",
> +               xen_path->data);
> +        return -EINVAL;
> +    }
> +
> +    res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
> +    if ( res < 0 )
> +        return res;
> +
> +    res = iommu_add_dt_device(node);
> +    if ( res < 0 )
> +        return res;
> +
> +    /* If xen_force, we allow assignment of devices without IOMMU protection. */
> +    if ( xen_force && !dt_device_is_protected(node) )
> +        return 0;
> +
> +    return iommu_assign_dt_device(kinfo->d, node);
> +}
> +
> +static int __init handle_prop_pfdt(struct kernel_info *kinfo,
> +                                   const void *pfdt, int nodeoff,
> +                                   uint32_t address_cells, uint32_t size_cells,
> +                                   bool scan_passthrough_prop)
> +{
> +    void *fdt = kinfo->fdt;
> +    int propoff, nameoff, res;
> +    const struct fdt_property *prop, *xen_reg = NULL, *xen_path = NULL;
> +    const char *name;
> +    bool found, xen_force = false;
> +
> +    for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
> +          propoff >= 0;
> +          propoff = fdt_next_property_offset(pfdt, propoff) )
> +    {
> +        if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) )
> +            return -FDT_ERR_INTERNAL;
> +
> +        found = false;
> +        nameoff = fdt32_to_cpu(prop->nameoff);
> +        name = fdt_string(pfdt, nameoff);
> +
> +        if ( scan_passthrough_prop )
> +        {
> +            if ( dt_prop_cmp("xen,reg", name) == 0 )
> +            {
> +                xen_reg = prop;
> +                found = true;
> +            }
> +            else if ( dt_prop_cmp("xen,path", name) == 0 )
> +            {
> +                xen_path = prop;
> +                found = true;
> +            }
> +            else if ( dt_prop_cmp("xen,force-assign-without-iommu",
> +                                  name) == 0 )
> +            {
> +                xen_force = true;
> +                found = true;
> +            }
> +        }
> +
> +        /*
> +         * Copy properties other than the ones above: xen,reg, xen,path,
> +         * and xen,force-assign-without-iommu.
> +         */
> +        if ( !found )
> +        {
> +            res = fdt_property(fdt, name, prop->data, fdt32_to_cpu(prop->len));
> +            if ( res )
> +                return res;
> +        }
> +    }
> +
> +    /*
> +     * Only handle passthrough properties if both xen,reg and xen,path
> +     * are present, or if xen,force-assign-without-iommu is specified.
> +     */
> +    if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
> +    {
> +        res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
> +                                      address_cells, size_cells);
> +        if ( res < 0 )
> +        {
> +            printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);
> +            return res;
> +        }
> +    }
> +    else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
> +    {
> +        printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
> +               kinfo->d);
> +        return -EINVAL;
> +    }
> +
> +    /* FDT_ERR_NOTFOUND => There is no more properties for this node */
> +    return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
> +}
> +
> +static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt,
> +                                 int nodeoff,
> +                                 uint32_t address_cells, uint32_t size_cells,
> +                                 bool scan_passthrough_prop)
> +{
> +    int rc = 0;
> +    void *fdt = kinfo->fdt;
> +    int node_next;
> +
> +    rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL));
> +    if ( rc )
> +        return rc;
> +
> +    rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells,
> +                          scan_passthrough_prop);
> +    if ( rc )
> +        return rc;
> +
> +    address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells",
> +                                        DT_ROOT_NODE_ADDR_CELLS_DEFAULT);
> +    size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells",
> +                                     DT_ROOT_NODE_SIZE_CELLS_DEFAULT);
> +
> +    node_next = fdt_first_subnode(pfdt, nodeoff);
> +    while ( node_next > 0 )
> +    {
> +        rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells,
> +                            scan_passthrough_prop);
> +        if ( rc )
> +            return rc;
> +
> +        node_next = fdt_next_subnode(pfdt, node_next);
> +    }
> +
> +    return fdt_end_node(fdt);
> +}
> +
> +static int __init check_partial_fdt(void *pfdt, size_t size)
> +{
> +    int res;
> +
> +    if ( fdt_magic(pfdt) != FDT_MAGIC )
> +    {
> +        dprintk(XENLOG_ERR, "Partial FDT is not a valid Flat Device Tree");
> +        return -EINVAL;
> +    }
> +
> +    res = fdt_check_header(pfdt);
> +    if ( res )
> +    {
> +        dprintk(XENLOG_ERR, "Failed to check the partial FDT (%d)", res);
> +        return -EINVAL;
> +    }
> +
> +    if ( fdt_totalsize(pfdt) > size )
> +    {
> +        dprintk(XENLOG_ERR, "Partial FDT totalsize is too big");
> +        return -EINVAL;
> +    }
> +
> +    return 0;
> +}
> +
> +static int __init domain_handle_dtb_bootmodule(struct domain *d,
> +                                               struct kernel_info *kinfo)
> +{
> +    void *pfdt;
> +    int res, node_next;
> +
> +    pfdt = ioremap_cache(kinfo->dtb_bootmodule->start,
> +                         kinfo->dtb_bootmodule->size);
> +    if ( pfdt == NULL )
> +        return -EFAULT;
> +
> +    res = check_partial_fdt(pfdt, kinfo->dtb_bootmodule->size);
> +    if ( res < 0 )
> +        goto out;
> +
> +    for ( node_next = fdt_first_subnode(pfdt, 0);
> +          node_next > 0;
> +          node_next = fdt_next_subnode(pfdt, node_next) )
> +    {
> +        const char *name = fdt_get_name(pfdt, node_next, NULL);
> +
> +        if ( name == NULL )
> +            continue;
> +
> +        /*
> +         * Only scan /$(interrupt_controller) /aliases /passthrough,
> +         * ignore the rest.
> +         * They don't have to be parsed in order.
> +         *
> +         * Take the interrupt controller phandle value from the special
> +         * interrupt controller node in the DTB fragment.
> +         */
> +        if ( init_intc_phandle(kinfo, name, node_next, pfdt) == 0 )
> +            continue;
> +
> +        if ( dt_node_cmp(name, "aliases") == 0 )
> +        {
> +            res = scan_pfdt_node(kinfo, pfdt, node_next,
> +                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
> +                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
> +                                 false);
> +            if ( res )
> +                goto out;
> +            continue;
> +        }
> +        if ( dt_node_cmp(name, "passthrough") == 0 )
> +        {
> +            res = scan_pfdt_node(kinfo, pfdt, node_next,
> +                                 DT_ROOT_NODE_ADDR_CELLS_DEFAULT,
> +                                 DT_ROOT_NODE_SIZE_CELLS_DEFAULT,
> +                                 true);
> +            if ( res )
> +                goto out;
> +            continue;
> +        }
> +    }
> +
> + out:
> +    iounmap(pfdt);
> +
> +    return res;
> +}
> +
> +/*
> + * The max size for DT is 2MB. However, the generated DT is small (not including
> + * domU passthrough DT nodes whose size we account separately), 4KB are enough
> + * for now, but we might have to increase it in the future.
> + */
> +#define DOMU_DTB_SIZE 4096
> +static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
> +{
> +    int addrcells, sizecells;
> +    int ret, fdt_size = DOMU_DTB_SIZE;
> +
> +    kinfo->phandle_intc = GUEST_PHANDLE_GIC;
> +
> +#ifdef CONFIG_GRANT_TABLE
> +    kinfo->gnttab_start = GUEST_GNTTAB_BASE;
> +    kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
> +#endif
> +
> +    addrcells = GUEST_ROOT_ADDRESS_CELLS;
> +    sizecells = GUEST_ROOT_SIZE_CELLS;
> +
> +    /* Account for domU passthrough DT size */
> +    if ( kinfo->dtb_bootmodule )
> +        fdt_size += kinfo->dtb_bootmodule->size;
> +
> +    /* Cap to max DT size if needed */
> +    fdt_size = min(fdt_size, SZ_2M);
> +
> +    kinfo->fdt = xmalloc_bytes(fdt_size);
> +    if ( kinfo->fdt == NULL )
> +        return -ENOMEM;
> +
> +    ret = fdt_create(kinfo->fdt, fdt_size);
> +    if ( ret < 0 )
> +        goto err;
> +
> +    ret = fdt_finish_reservemap(kinfo->fdt);
> +    if ( ret < 0 )
> +        goto err;
> +
> +    ret = fdt_begin_node(kinfo->fdt, "");
> +    if ( ret < 0 )
> +        goto err;
> +
> +    ret = fdt_property_cell(kinfo->fdt, "#address-cells", addrcells);
> +    if ( ret )
> +        goto err;
> +
> +    ret = fdt_property_cell(kinfo->fdt, "#size-cells", sizecells);
> +    if ( ret )
> +        goto err;
> +
> +    ret = make_chosen_node(kinfo);
> +    if ( ret )
> +        goto err;
> +
> +    ret = make_cpus_node(d, kinfo->fdt);
> +    if ( ret )
> +        goto err;
> +
> +    ret = make_memory_node(kinfo, addrcells, sizecells,
> +                           kernel_info_get_mem(kinfo));
> +    if ( ret )
> +        goto err;
> +
> +#ifdef CONFIG_STATIC_SHM
> +    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
> +    if ( ret )
> +        goto err;
> +#endif
> +
> +    /*
> +     * domain_handle_dtb_bootmodule has to be called before the rest of
> +     * the device tree is generated because it depends on the value of
> +     * the field phandle_intc.
> +     */
> +    if ( kinfo->dtb_bootmodule )
> +    {
> +        ret = domain_handle_dtb_bootmodule(d, kinfo);
> +        if ( ret )
> +            goto err;
> +    }
> +
> +    ret = make_intc_domU_node(kinfo);
> +    if ( ret )
> +        goto err;
> +
> +    ret = make_timer_node(kinfo);
> +    if ( ret )
> +        goto err;
> +
> +    if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
> +    {
> +        ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
> +        if ( ret )
> +            goto err;
> +    }
> +
> +    ret = make_arch_nodes(kinfo);
> +    if ( ret )
> +        goto err;
> +
> +    ret = fdt_end_node(kinfo->fdt);
> +    if ( ret < 0 )
> +        goto err;
> +
> +    ret = fdt_finish(kinfo->fdt);
> +    if ( ret < 0 )
> +        goto err;
> +
> +    return 0;
> +
> +  err:
> +    printk("Device tree generation failed (%d).\n", ret);
> +    xfree(kinfo->fdt);
> +
> +    return -EINVAL;
> +}
> +
> +#define XENSTORE_PFN_OFFSET 1
> +static int __init alloc_xenstore_page(struct domain *d)
> +{
> +    struct page_info *xenstore_pg;
> +    struct xenstore_domain_interface *interface;
> +    mfn_t mfn;
> +    gfn_t gfn;
> +    int rc;
> +
> +    if ( (UINT_MAX - d->max_pages) < 1 )
> +    {
> +        printk(XENLOG_ERR "%pd: Over-allocation for d->max_pages by 1 page.\n",
> +               d);
> +        return -EINVAL;
> +    }
> +
> +    d->max_pages += 1;
> +    xenstore_pg = alloc_domheap_page(d, MEMF_bits(32));
> +    if ( xenstore_pg == NULL && is_64bit_domain(d) )
> +        xenstore_pg = alloc_domheap_page(d, 0);
> +    if ( xenstore_pg == NULL )
> +        return -ENOMEM;
> +
> +    mfn = page_to_mfn(xenstore_pg);
> +    if ( !mfn_x(mfn) )
> +        return -ENOMEM;
> +
> +    if ( !is_domain_direct_mapped(d) )
> +        gfn = gaddr_to_gfn(GUEST_MAGIC_BASE +
> +                           (XENSTORE_PFN_OFFSET << PAGE_SHIFT));
> +    else
> +        gfn = gaddr_to_gfn(mfn_to_maddr(mfn));
> +
> +    rc = guest_physmap_add_page(d, gfn, mfn, 0);
> +    if ( rc )
> +    {
> +        free_domheap_page(xenstore_pg);
> +        return rc;
> +    }
> +
> +#ifdef CONFIG_HVM
> +    d->arch.hvm.params[HVM_PARAM_STORE_PFN] = gfn_x(gfn);
> +#endif
> +    interface = map_domain_page(mfn);
> +    interface->connection = XENSTORE_RECONNECT;
> +    unmap_domain_page(interface);
> +
> +    return 0;
> +}
> +
> +static int __init alloc_xenstore_params(struct kernel_info *kinfo)
> +{
> +    struct domain *d = kinfo->d;
> +    int rc = 0;
> +
> +#ifdef CONFIG_HVM
> +    if ( (kinfo->dom0less_feature & (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY))
> +                                 == (DOM0LESS_XENSTORE | DOM0LESS_XS_LEGACY) )
> +        d->arch.hvm.params[HVM_PARAM_STORE_PFN] = XENSTORE_PFN_LATE_ALLOC;
> +    else
> +#endif
> +    if ( kinfo->dom0less_feature & DOM0LESS_XENSTORE )
> +    {
> +        rc = alloc_xenstore_page(d);
> +        if ( rc < 0 )
> +            return rc;
> +    }
> +
> +    return rc;
> +}
> +
> +static void __init domain_vcpu_affinity(struct domain *d,
> +                                        const struct dt_device_node *node)
> +{
> +    struct dt_device_node *np;
> +
> +    dt_for_each_child_node(node, np)
> +    {
> +        const char *hard_affinity_str = NULL;
> +        uint32_t val;
> +        int rc;
> +        struct vcpu *v;
> +        cpumask_t affinity;
> +
> +        if ( !dt_device_is_compatible(np, "xen,vcpu") )
> +            continue;
> +
> +        if ( !dt_property_read_u32(np, "id", &val) )
> +            panic("Invalid xen,vcpu node for domain %s\n", dt_node_name(node));
> +
> +        if ( val >= d->max_vcpus )
> +            panic("Invalid vcpu_id %u for domain %s, max_vcpus=%u\n", val,
> +                  dt_node_name(node), d->max_vcpus);
> +
> +        v = d->vcpu[val];
> +        rc = dt_property_read_string(np, "hard-affinity", &hard_affinity_str);
> +        if ( rc < 0 )
> +            continue;
> +
> +        cpumask_clear(&affinity);
> +        while ( *hard_affinity_str != '\0' )
> +        {
> +            unsigned int start, end;
> +
> +            start = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
> +
> +            if ( *hard_affinity_str == '-' )    /* Range */
> +            {
> +                hard_affinity_str++;
> +                end = simple_strtoul(hard_affinity_str, &hard_affinity_str, 0);
> +            }
> +            else                /* Single value */
> +                end = start;
> +
> +            if ( end >= nr_cpu_ids )
> +                panic("Invalid pCPU %u for domain %s\n", end, dt_node_name(node));
> +
> +            for ( ; start <= end; start++ )
> +                cpumask_set_cpu(start, &affinity);
> +
> +            if ( *hard_affinity_str == ',' )
> +                hard_affinity_str++;
> +            else if ( *hard_affinity_str != '\0' )
> +                break;
> +        }
> +
> +        rc = vcpu_set_hard_affinity(v, &affinity);
> +        if ( rc )
> +            panic("vcpu%d: failed (rc=%d) to set hard affinity for domain %s\n",
> +                  v->vcpu_id, rc, dt_node_name(node));
> +    }
> +}
> +
> +#ifdef CONFIG_ARCH_PAGING_MEMPOOL
> +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);
> +
> +    BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
> +
> +    return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT);
> +}
> +
> +static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem,
> +                                            const struct dt_device_node *node)
> +{
> +    unsigned long p2m_pages;
> +    uint32_t p2m_mem_mb;
> +    int rc;
> +
> +    rc = dt_property_read_u32(node, "xen,domain-p2m-mem-mb", &p2m_mem_mb);
> +    /* If xen,domain-p2m-mem-mb is not specified, use the default value. */
> +    p2m_pages = rc ?
> +                p2m_mem_mb << (20 - PAGE_SHIFT) :
> +                domain_p2m_pages(mem, d->max_vcpus);
> +
> +    spin_lock(&d->arch.paging.lock);
> +    rc = p2m_set_allocation(d, p2m_pages, NULL);
> +    spin_unlock(&d->arch.paging.lock);
> +
> +    return rc;
> +}
> +#else /* !CONFIG_ARCH_PAGING_MEMPOOL */
> +static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
> +                                            const struct dt_device_node *node)
> +{
> +    return 0;
> +}
> +#endif /* CONFIG_ARCH_PAGING_MEMPOOL */
> +
> +static int __init construct_domU(struct domain *d,
> +                          const struct dt_device_node *node)
> +{
> +    struct kernel_info kinfo = KERNEL_INFO_INIT;
> +    const char *dom0less_enhanced;
> +    int rc;
> +    u64 mem;
> +
> +    rc = dt_property_read_u64(node, "memory", &mem);
> +    if ( !rc )
> +    {
> +        printk("Error building DomU: cannot read \"memory\" property\n");
> +        return -EINVAL;
> +    }
> +    kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
> +
> +    rc = domain_p2m_set_allocation(d, mem, node);
> +    if ( rc != 0 )
> +        return rc;
> +
> +    printk("*** LOADING DOMU cpus=%u memory=%#"PRIx64"KB ***\n",
> +           d->max_vcpus, mem);
> +
> +    rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
> +    if ( rc == -EILSEQ ||
> +         rc == -ENODATA ||
> +         (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
> +    {
> +        need_xenstore = true;
> +        kinfo.dom0less_feature = DOM0LESS_ENHANCED;
> +    }
> +    else if ( rc == 0 && !strcmp(dom0less_enhanced, "legacy") )
> +    {
> +        need_xenstore = true;
> +        kinfo.dom0less_feature = DOM0LESS_ENHANCED_LEGACY;
> +    }
> +    else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") )
> +        kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS;
> +
> +    if ( vcpu_create(d, 0) == NULL )
> +        return -ENOMEM;
> +
> +    d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
> +
> +    kinfo.d = d;
> +
> +    rc = kernel_probe(&kinfo, node);
> +    if ( rc < 0 )
> +        return rc;
> +
> +    set_domain_type(d, &kinfo);
> +
> +    if ( is_hardware_domain(d) )
> +    {
> +        rc = construct_hwdom(&kinfo, node);
> +        if ( rc < 0 )
> +            return rc;
> +    }
> +    else
> +    {
> +        if ( !dt_find_property(node, "xen,static-mem", NULL) )
> +            allocate_memory(d, &kinfo);
> +    #ifdef CONFIG_STATIC_MEMORY

code style, I can fix on commit


> +        else if ( !is_domain_direct_mapped(d) )
> +            allocate_static_memory(d, &kinfo, node);
> +        else
> +            assign_static_memory_11(d, &kinfo, node);
> +    #endif

also gere

> +    #ifdef CONFIG_STATIC_SHM

and here


> +        rc = process_shm(d, &kinfo, node);
> +        if ( rc < 0 )
> +            return rc;
> +    #endif

and here


> +        rc = init_vuart(d, &kinfo, node);
> +        if ( rc < 0 )
> +            return rc;
> +
> +        rc = prepare_dtb_domU(d, &kinfo);
> +        if ( rc < 0 )
> +            return rc;
> +
> +        rc = construct_domain(d, &kinfo);
> +        if ( rc < 0 )
> +            return rc;
> +    }
> +
> +    domain_vcpu_affinity(d, node);
> +
> +    return alloc_xenstore_params(&kinfo);
> +}
> +
>  void __init create_domUs(void)
>  {
>      struct dt_device_node *node;
> diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
> index 2003be743f..e0ad0429ec 100644
> --- a/xen/include/asm-generic/dom0less-build.h
> +++ b/xen/include/asm-generic/dom0less-build.h
> @@ -12,10 +12,7 @@ struct domain;
>  #include 
>  
>  struct dt_device_node;
> -
> -/* TODO: remove both when construct_domU() will be moved to common. */
> -#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
> -extern bool need_xenstore;
> +struct kernel_info;
>  
>  /*
>   * List of possible features for dom0less domUs
> @@ -49,12 +46,21 @@ void create_domUs(void);
>  bool is_dom0less_mode(void);
>  void set_xs_domain(struct domain *d);
>  
> -int construct_domU(struct domain *d, const struct dt_device_node *node);
> -
>  void arch_create_domUs(struct dt_device_node *node,
>                         struct xen_domctl_createdomain *d_cfg,
>                         unsigned int flags);
>  
> +int init_vuart(struct domain *d, struct kernel_info *kinfo,
> +               const struct dt_device_node *node);
> +
> +int make_intc_domU_node(struct kernel_info *kinfo);
> +int make_arch_nodes(struct kernel_info *kinfo);
> +
> +void set_domain_type(struct domain *d, struct kernel_info *kinfo);
> +
> +int init_intc_phandle(struct kernel_info *kinfo, const char *name,
> +                      const int node_next, const void *pfdt);
> +
>  #else /* !CONFIG_DOM0LESS_BOOT */
>  
>  static inline void create_domUs(void) {}
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Mon May 05 20:19:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 20:19:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976403.1363560 (Exim 4.92)
	(envelope-from )
	id 1uC2I4-0005h4-PW; Mon, 05 May 2025 20:19:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976403.1363560; Mon, 05 May 2025 20:19: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 1uC2I4-0005gx-Mk; Mon, 05 May 2025 20:19:52 +0000
Received: by outflank-mailman (input) for mailman id 976403;
 Mon, 05 May 2025 20:19:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC2I3-0005gr-F7
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 20:19:51 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 439a21e9-29ee-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 22:19:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id B4BA14A60A;
 Mon,  5 May 2025 20:19:32 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7E00C4CEED;
 Mon,  5 May 2025 20:19: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" 
X-Inumbo-ID: 439a21e9-29ee-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746476375;
	bh=9QzdqWQzlY8mmANonXjZYlJmP6G69bzQ/ebjcS17X4U=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Fg2W5gglvEU5kFI6EI6cYgQt0nytDxgxKBe5nRBmt4AacTbZd0ZnsqFb6Zl8KdxW8
	 3vw7fJiC/iX0vzhvbdp/Zqo1Z8dgnFDdnQXe919BHp7SaTY+0EjNd3SOe/8sO5IBkx
	 OAaEI58xMWEO+0EIHAsTXh1RNH4MmdiJDg22O61EYKYxPv/t7Ku4cvzO5Wi72bOywf
	 HYFe7OnLBSOYweYrzCM/2uMIOJWGGghd4OZMEvxg5gvWbyeZkBmmMy7+crSfl/XhKz
	 SYaYKVUtbBtmGxzu5/nlGrWrjQtdIenixwoOsPFaDovljksEiw4JpAbesscpPMVHSe
	 Iejf4TJAUKdcA==
Date: Mon, 5 May 2025 13:19:32 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Kurochko 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v4 5/8] asm-generic: move some parts of Arm's domain_build.h
 to common
In-Reply-To: <3e8bcf195a5c7bec8b32aaf01a128dcb25e68b9e.1746468003.git.oleksii.kurochko@gmail.com>
Message-ID: 
References:  <3e8bcf195a5c7bec8b32aaf01a128dcb25e68b9e.1746468003.git.oleksii.kurochko@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 5 May 2025, Oleksii Kurochko wrote:
> Nothing changed. Only some functions declaration are moved to xen/include/
> headers as they are expected to be used by common code of domain builing
> or dom0less.
> 
> Signed-off-by: Oleksii Kurochko 
> ---
> Chnages in v4:
>  - Move declaration of allocate_*() to the patch where defintions of them are introduced.
>  - Move declaration of 'int construct_hwdom(struct kernel_info *kinfo,
>    const struct dt_device_node *node) to fdt-domain-build.h.
>  - Drop declaration of get_allocation_size() from fdt-domain-build.h as defintion/declaration
>    will be added in the further patch of this patch series.
> ---
>  Chnages in v3:
>  - Drop inclusion of  from xen/fdt-domain-build.h.
>  - Add empty line after license tag in xen/fdt-domain-build.h.
> ---
>  Chnages in v2:
>   - Add missed declaration of construct_hwdom().
>   - Drop unnessary blank line.
>   - Introduce xen/fdt-domain-build.h and move parts of Arm's domain_build.h to
>     it.
>   - Update the commit message.
> ---
>  xen/arch/arm/acpi/domain_build.c        |  1 +
>  xen/arch/arm/dom0less-build.c           |  1 +
>  xen/arch/arm/domain_build.c             |  1 +
>  xen/arch/arm/include/asm/domain_build.h | 11 +-------
>  xen/arch/arm/kernel.c                   |  1 +
>  xen/arch/arm/static-shmem.c             |  1 +
>  xen/include/xen/fdt-domain-build.h      | 35 +++++++++++++++++++++++++
>  7 files changed, 41 insertions(+), 10 deletions(-)
>  create mode 100644 xen/include/xen/fdt-domain-build.h
> 
> diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
> index f9ca8b47e5..1c3555d814 100644
> --- a/xen/arch/arm/acpi/domain_build.c
> +++ b/xen/arch/arm/acpi/domain_build.c
> @@ -10,6 +10,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index 7e9cedb0c8..47eb38b9ad 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -1,6 +1,7 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 8c7a054718..9d649b06b3 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1,6 +1,7 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
> index df1c0fe301..9d72108f35 100644
> --- a/xen/arch/arm/include/asm/domain_build.h
> +++ b/xen/arch/arm/include/asm/domain_build.h
> @@ -9,21 +9,12 @@ typedef bool (*alloc_domheap_mem_cb)(struct domain *d, struct page_info *pg,
>                                       unsigned int order, void *extra);
>  bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
>                               alloc_domheap_mem_cb cb, void *extra);
> +

NIT: no need for new line

I can fix on commit

Reviewed-by: Stefano Stabellini 

>  bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
>                            paddr_t tot_size);
>  void allocate_memory(struct domain *d, struct kernel_info *kinfo);
> -int construct_domain(struct domain *d, struct kernel_info *kinfo);
> -int construct_hwdom(struct kernel_info *kinfo,
> -                    const struct dt_device_node *node);
>  int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
> -int make_chosen_node(const struct kernel_info *kinfo);
> -int make_cpus_node(const struct domain *d, void *fdt);
> -int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
> -                         int addrcells, int sizecells);
> -int make_memory_node(const struct kernel_info *kinfo, int addrcells,
> -                     int sizecells, const struct membanks *mem);
>  int make_psci_node(void *fdt);
> -int make_timer_node(const struct kernel_info *kinfo);
>  void evtchn_allocate(struct domain *d);
>  
>  unsigned int get_allocation_size(paddr_t size);
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index 34c8233853..aea8f44413 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
> index 14ae48fb1e..1f8441d920 100644
> --- a/xen/arch/arm/static-shmem.c
> +++ b/xen/arch/arm/static-shmem.c
> @@ -1,6 +1,7 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
> new file mode 100644
> index 0000000000..30d5358a0f
> --- /dev/null
> +++ b/xen/include/xen/fdt-domain-build.h
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __XEN_FDT_DOMAIN_BUILD_H__
> +#define __XEN_FDT_DOMAIN_BUILD_H__
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct domain;
> +struct page_info;
> +struct membanks;
> +
> +int construct_domain(struct domain *d, struct kernel_info *kinfo);
> +int construct_hwdom(struct kernel_info *kinfo,
> +                    const struct dt_device_node *node);
> +int make_chosen_node(const struct kernel_info *kinfo);
> +int make_cpus_node(const struct domain *d, void *fdt);
> +int make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo,
> +                         int addrcells, int sizecells);
> +int make_memory_node(const struct kernel_info *kinfo, int addrcells,
> +                     int sizecells, const struct membanks *mem);
> +int make_timer_node(const struct kernel_info *kinfo);
> +
> +#endif /* __XEN_FDT_DOMAIN_BUILD_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Mon May 05 20:35:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 20:35:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976414.1363571 (Exim 4.92)
	(envelope-from )
	id 1uC2XZ-0000N1-15; Mon, 05 May 2025 20:35:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976414.1363571; Mon, 05 May 2025 20:35: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 1uC2XY-0000Mu-UG; Mon, 05 May 2025 20:35:52 +0000
Received: by outflank-mailman (input) for mailman id 976414;
 Mon, 05 May 2025 20:35:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC2XW-0000Mo-T7
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 20:35:51 +0000
Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com
 [2607:f8b0:4864:20::112c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8769cda0-29f0-11f0-9eb4-5ba50f476ded;
 Mon, 05 May 2025 22:35:49 +0200 (CEST)
Received: by mail-yw1-x112c.google.com with SMTP id
 00721157ae682-6ff1e375a47so45415987b3.1
 for ; Mon, 05 May 2025 13:35:49 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-708c467fcdcsm23584907b3.82.2025.05.05.13.35.47
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 05 May 2025 13:35: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" 
X-Inumbo-ID: 8769cda0-29f0-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746477348; x=1747082148; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:to
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=lPqH87sOn/Y1cdLdipiCuKQbaUf0sJV2N0JiO/VPaTA=;
        b=T/kg4JjPbx3UUjir2qVO75FZiWSPe9edroPlkcFwrUhre1h0F+v/Dil8w61tCrMBFW
         hilvDgI7ga/ZhUdsQbcF/A7lMIEo0whA6N76PnNmLdjZpNtwuArFbJx1rNcDbSQ/biCh
         Ma57rmT8Msns20ofHIn8+pxR5Uuc4gAkhk4aUEOPxoKAJZrj/18EE8et6ajbHxv13D0y
         PoeqIu41oVLfqn/z5rpUxzPH9K/cH88xpcOhUouIqd7KBB6C2+VZkQqCIELlIyAER1vA
         lpTccPQO7kPxFaXi34VTd52C1I7Vm30+JAkf0fBEkezrfNnPnmaoicb7tIeTA2H6FVgs
         8SMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746477348; x=1747082148;
        h=in-reply-to:subject:autocrypt:from:content-language:references:to
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=lPqH87sOn/Y1cdLdipiCuKQbaUf0sJV2N0JiO/VPaTA=;
        b=EvkdCuhylG8XaLN1Y1bdf+dvVVGYUy5BBSP9hAAV7/ZkIAFUMLutmDpPAJ67I27tDo
         enknGGUDvlJxQRurS7Y01aGSVbge5nd7xVXZpZM6FALd7xjTFV17WHg8cv/dnoHCaLW4
         u7wFFWHub+9wlByLoW6Bq2UNOwQjYqxqV2D77WuW/DLpX6BIazlYM804SGFbUmltnsBI
         98Z6q7s7NTXGsmDXAVNUhIC0KLssCh7qzsBe0R4y5UcfHIDqpzagyxs4wKlkZ5l4vjW/
         IOuncfiQvEY6zDwrQwuQXZZIU8LZP0aa3V3HIgSp/AXClHbTlLj55Wjk2RJLmngo6UnS
         1Aow==
X-Gm-Message-State: AOJu0YyK1NSkAUfn4wvg75sBjmPWjWa9u8Lti9h/53JgvPOC/ZiDIjj2
	MeD7SJduxjhF+CJ66QTP5Gc//BP7gAvT0TMCoZm2l9JJ7Ey0rn8hFcLNJw==
X-Gm-Gg: ASbGncvd4Psqk41G8zHESaVpxHCWIDjKc3QQ3azh4W9Q8DqTQIchDyMh9pj2u5yKs0D
	vj/9dmravtBHL+LUbRPXrA/6cLtSwcdqlb7w+71eua4DwmwYPHkAKWWLjkCr8H9iBipg7xo8RI+
	S7dal7wLQ0UB4aH242inEJk6vcKdCtj/3vYAsMrrFEuYwIqFvLAiK0kM+H6Sg7KkfkqrA8pL7Ve
	r0h4oZ9QfVSgz29C4O9wiJ4zEQzxcAV9A2UAAmgrGEzyAmDZiPwjjkn0CYYIzn0Tb3+kEhHd3nq
	A5qCTNPrT1av2zyO+WczPPPYSX4ZJmy6HeS68NAMwUg3
X-Google-Smtp-Source: AGHT+IHJ3aWkzkc/CXp4yJ7laLfCTDaRKVvxseR6/xvojfgMJwQXGC3opf8C822bacp3zptkBrGIuQ==
X-Received: by 2002:a05:690c:680c:b0:702:52fb:4629 with SMTP id 00721157ae682-70919868a47mr10025837b3.23.1746477348329;
        Mon, 05 May 2025 13:35:48 -0700 (PDT)
Message-ID: 
Date: Mon, 5 May 2025 16:36:29 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: xen-devel@lists.xenproject.org
References: 
 <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>
 
  
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------793uh3TQnfnvmgnYsE00a0nU"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------793uh3TQnfnvmgnYsE00a0nU
Content-Type: multipart/mixed; boundary="------------LbFLMfTs6VtEKwldlR5lRgNr";
 protected-headers="v1"
From: Demi Marie Obenour 
To: xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
References: 
 <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>
 
  
 
In-Reply-To: 

--------------LbFLMfTs6VtEKwldlR5lRgNr
Content-Type: multipart/mixed; boundary="------------M4pYXugA6P2E7xgY4Y0XgdWR"

--------------M4pYXugA6P2E7xgY4Y0XgdWR
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/5/25 2:11 PM, Stefano Stabellini wrote:
> On Mon, 5 May 2025, Roger Pau Monn=C3=A9 wrote:
>> On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-G=C3=B3re=
cki wrote:
>>> On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
>>>> On Mon, 28 Apr 2025, Jan Beulich wrote:
>>>>> On 25.04.2025 22:19, Stefano Stabellini wrote:
>>>>>> From: Xenia Ragiadakou 
>>>>>>
>>>>>> Dom0 PVH might need XENMEM_exchange when passing contiguous memory=

>>>>>> addresses to firmware or co-processors not behind an IOMMU.
>>>>>
>>>>> I definitely don't understand the firmware part: It's subject to th=
e
>>>>> same transparent P2M translations as the rest of the VM; it's just
>>>>> another piece of software running there.
>>>>>
>>>>> "Co-processors not behind an IOMMU" is also interesting; a more
>>>>> concrete scenario might be nice, yet I realize you may be limited i=
n
>>>>> what you're allowed to say.
>>>>
>>>> Sure. On AMD x86 platforms there is a co-processor called PSP runnin=
g
>>>> TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionall=
y to
>>>> pass addresses to it.  See drivers/tee/amdtee/ and
>>>> include/linux/psp-tee.h in Linux.
>>>
>>> We had (have?) similar issue with amdgpu (for integrated graphics) - =
it
>>> uses PSP for loading its firmware. With PV dom0 there is a workaround=
 as
>>> dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, bu=
t I
>>> expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's=

>>> the one I used for debugging this issue).
>>
>> That's ugly, and problematic when used in conjunction with AMD-SEV.
>>
>> I wonder if Xen could emulate/mediate some parts of the PSP for dom0
>> to use, while allowing Xen to be the sole owner of the device.  Having=

>> both Xen and dom0 use it (for different purposes) seems like asking
>> for trouble.  But I also have no idea how complex the PSP interface
>> is, neither whether it would be feasible to emulate the
>> interfaces/registers needed for firmware loading.
>=20
> Let me take a step back from the PSP for a moment. I am not opposed to =
a
> PSP mediator in Xen, but I want to emphasize that the issue is more
> general and extends well beyond the PSP.
>=20
> In my years working in embedded systems, I have consistently seen cases=

> where Dom0 needs to communicate with something that does not go through=

> the IOMMU. This could be due to special firmware on a co-processor, a
> hardware erratum that prevents proper IOMMU usage, or a high-bandwidth
> device that technically supports the IOMMU but performs poorly unless
> the IOMMU is disabled. All of these are real-world examples that I have=

> seen personally.
>=20
> In my opinion, we definitely need a solution like this patch for Dom0
> PVH to function correctly in all scenarios.
>=20
> Additionally, we could add a PSP mediator in Xen to provide best PSP
> support, and also for cases where both Xen and Dom0 need access, but I
> cannot fully assess the complexity involved, as I am not very familiar
> with the API. Probably it is not going to be simple.
>=20
> Even with the PSP mediator in place, I would still recommend this patch=
=2E

How does this patch interact with dom0 deprivilege?
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------M4pYXugA6P2E7xgY4Y0XgdWR
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------M4pYXugA6P2E7xgY4Y0XgdWR--

--------------LbFLMfTs6VtEKwldlR5lRgNr--

--------------793uh3TQnfnvmgnYsE00a0nU
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgZIU8ACgkQszaHOrMp
8lOa6Q//YXD+kGGjiTznGNYSwaKPCu9j3R25Qs0Gfv68tgHbIVMxTAlzDVIrcYa6
rRlpIBkbro2zC357FtDV1T+K/5cKVKgx4HKHNet/Vaxk7zA0xtCGqu148GC+sIXU
+9S6hTYEIn3Yvj5kFW1R+keTo82ftuMvPDeVeLmlUk1OLBb+sTpDwBWS0nLWs3Dg
uvqQObtHbDrsTwQZYbmyKqAihJBKuHZifcOIcpW9fLygXHRqLQL0GoiOOropewfH
8qz01i6fCc/UoFdBlrnHvqQ0MhNDkkKJV6MmICQ5kYKlt/paHxmdAX8V3gKKH7YQ
si8mPf87jKUwr1SzKkNMZWKzBH0Ub7Oz2l/+kDYobkYviM2QlvfvI/vh7vB+P5Y9
vPvtnRRWy+8GcH1kegpAJsnKg296ThSeomxrMGBfRCNbOA2OZ7gia0AqQG2JN/24
2JPMmH9DZGuSvTa9rkAFRqCwvTCb8IfI+OVYoNcj9S6lWpUr+4QdOb2RxjARUz/V
1LY5Ch/hM7G+Y1lc3pDq6pmJjxAUJxCqSlkZxngeiGnfrayitWIcDKzoSW5vgKb7
4gyzl+tyzvwRehILsE2RO77mtkRluSopTfcElV4Ssr76clbf8L1RvMUOTshJFIzb
n273lHCjFVksWZyhbVr6GIGb4+iFf12huLal3WW6DeD5fkmNhcs=
=TGvv
-----END PGP SIGNATURE-----

--------------793uh3TQnfnvmgnYsE00a0nU--


From xen-devel-bounces@lists.xenproject.org Mon May 05 20:45:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 20:45:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976429.1363582 (Exim 4.92)
	(envelope-from )
	id 1uC2gT-0002I4-1Y; Mon, 05 May 2025 20:45:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976429.1363582; Mon, 05 May 2025 20: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 1uC2gS-0002Hx-Sx; Mon, 05 May 2025 20:45:04 +0000
Received: by outflank-mailman (input) for mailman id 976429;
 Mon, 05 May 2025 20:45:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC2gR-0002Hr-MM
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 20:45:03 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cf4cbdd1-29f1-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 22:44:59 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 9BF6061129;
 Mon,  5 May 2025 20:44:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D746C4CEE4;
 Mon,  5 May 2025 20:44: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" 
X-Inumbo-ID: cf4cbdd1-29f1-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746477898;
	bh=ubdBjhQyfvrlKkg+rzmLXqPA/dVljltrJ12y21NRBts=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=jpT1K7p+AEBP+oiObyE85RAqOoZ8tHiEgeiYpmZYZJ3hzPrs3CaZ5A1xu0+zboUIa
	 NzIEkxm6GdfknuSmd6WmiRM47EuEbSlQFL+FCTFjtxPD8szjXg8iE/87bK00HjP5zq
	 43W2pRMGkb1sPdACK4xn4gyda55fQ5/nd4Rd/3ikfjc+eogKbil4jR8KMiZ4WrL59i
	 pe8M1Ipz+e68Gj727wssLS1MWG4iEgSZOkofJULqkYKStbDrNPNci+4nUtU9LJ36r1
	 W/sdzh4H19Y+usS0xxWihYuowfIp+gVK6737RDp841QaZ+BIjklthDB9bWUTklzhoB
	 kjKHcfLDENSKQ==
Date: Mon, 5 May 2025 13:44:55 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jason Andryuk 
cc: Juergen Gross , 
    Stefano Stabellini , 
    Oleksandr Tyshchenko , 
    xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xenbus: Allow PVH dom0 a non-local xenstore
In-Reply-To: <20250503131935.1885-1-jason.andryuk@amd.com>
Message-ID: 
References: <20250503131935.1885-1-jason.andryuk@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Sat, 3 May 2025, Jason Andryuk wrote:
> Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
> currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
> xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
> late init path.
> 
> Drop the use of xen_initial_domain() and just check for the event
> channel instead.  This matches the PV case where there is no check for
> initial domain.
> 
> Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
> chance that high bits are set for the 32bit event channel.
> 
> Signed-off-by: Jason Andryuk 

Reviewed-by: Stefano Stabellini 


> ---
>  drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index 6d32ffb01136..7604f70ee108 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -966,9 +966,15 @@ static int __init xenbus_init(void)
>  	if (xen_pv_domain())
>  		xen_store_domain_type = XS_PV;
>  	if (xen_hvm_domain())
> +	{
>  		xen_store_domain_type = XS_HVM;
> -	if (xen_hvm_domain() && xen_initial_domain())
> -		xen_store_domain_type = XS_LOCAL;
> +		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> +		if (err)
> +			goto out_error;
> +		xen_store_evtchn = (int)v;
> +		if (!v)
> +			xen_store_domain_type = XS_LOCAL;
> +	}
>  	if (xen_pv_domain() && !xen_start_info->store_evtchn)
>  		xen_store_domain_type = XS_LOCAL;
>  	if (xen_pv_domain() && xen_start_info->store_evtchn)
> @@ -987,10 +993,6 @@ static int __init xenbus_init(void)
>  		xen_store_interface = gfn_to_virt(xen_store_gfn);
>  		break;
>  	case XS_HVM:
> -		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> -		if (err)
> -			goto out_error;
> -		xen_store_evtchn = (int)v;
>  		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
>  		if (err)
>  			goto out_error;
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Mon May 05 21:41:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 21:41:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976440.1363591 (Exim 4.92)
	(envelope-from )
	id 1uC3Yb-0001qi-QN; Mon, 05 May 2025 21:41:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976440.1363591; Mon, 05 May 2025 21:41: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 1uC3Yb-0001qb-NK; Mon, 05 May 2025 21:41:01 +0000
Received: by outflank-mailman (input) for mailman id 976440;
 Mon, 05 May 2025 21:41:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC3Ya-0001qP-GC
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 21:41:00 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 99ed1720-29f9-11f0-9ffb-bf95429c2676;
 Mon, 05 May 2025 23:40:46 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 6D6435C47C4;
 Mon,  5 May 2025 21:38:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C264EC4CEE4;
 Mon,  5 May 2025 21:40: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" 
X-Inumbo-ID: 99ed1720-29f9-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746481244;
	bh=EnVhm1DKHuswKyuwolsUOUoE6jg7Eh2nFnyxE4UZ7a0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=cqcCPAX5CQnc4LS5m3fzrOfEaE7cE6KRNXJ0cmFfxjNk75VD+ffGj/BPvL+BiInkA
	 ZStVRcLnyqCoFGi+oTt4FFa5ANT3P2SZ55DqWk4yBOGsk5OHKM6w/sadAFm6YR2czO
	 JAVywE4sOiRj5VSLk2gfs9/smkbSgi5FxaT0xjAGm9CV1TIBXY9rmixGMCTtvjFyzg
	 ypqQkO1UxVnRXV55BIagpLDUu0+ZQAucwMLzbl9i7QtqfUx5QaHkVvzCrt1FV0mZIh
	 2GUy0gBKGv3ubHSfCfaEgmjBOjaqltdk+GnFcyMc/qn5tmYlLlur0CC/quc0eDCY1N
	 FEoMJjTtWeqYA==
Date: Mon, 5 May 2025 14:40:41 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Kurochko 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v4 2/8] xen/common: dom0less: make some parts of Arm's
 CONFIG_DOM0LESS common
In-Reply-To: <3c096d750b9ff6ebec0f391d1566d1386301eef7.1746468003.git.oleksii.kurochko@gmail.com>
Message-ID: 
References:  <3c096d750b9ff6ebec0f391d1566d1386301eef7.1746468003.git.oleksii.kurochko@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 5 May 2025, Oleksii Kurochko wrote:
> Move some parts of Arm's Dom0Less code to be reused by other architectures.
> At the moment, RISC-V is going to reuse these parts.
> 
> Move dom0less-build.h from the Arm-specific directory to asm-generic
> as these header is expected to be the same across acrhictectures with
> some updates: add the following declaration of construct_domU(),
> and arch_create_domUs() as there are some parts which are still
> architecture-specific.
> 
> Introduce HAS_DOM0LESS to provide ability to enable generic Dom0less
> code for an architecture.
> 
> Relocate the CONFIG_DOM0LESS configuration to the common with adding
> "depends on HAS_DOM0LESS" to not break builds for architectures which
> don't support CONFIG_DOM0LESS config, especically it would be useful
> to not provide stubs for  construct_domU(), arch_create_domUs()
> in case of *-randconfig which may set CONFIG_DOM0LESS=y.
> 
> Move is_dom0less_mode() function to the common code, as it depends on
> boot modules that are already part of the common code.
> 
> Move create_domUs() function to the common code with some updates:
> - Add arch_create_domUs() to cover parsing of arch-specific features,
>   for example, SVE (Scalar Vector Extension ) exists only in Arm.
> 
> Signed-off-by: Oleksii Kurochko 
> Reviewed-by: Stefano Stabellini 
> ---
> Changes in v4:
> - Add HAS_DEVICE_TREE dependency to DOM0LESS_BOOT config and
>   drop 'select HAS_DEVICE_TREE' from HAS_DOM0LESS.
> - Move forward declaration of 'struct domain' outside #ifdef CONFIG_DOM0LESS_BOOT
>   as it is used by an argument of set_xs_domain().
> - Add Reviewed-by: Stefano Stabellini .
> - Drop footer after commit message: the change of dom0less to something else
>   (predefined domains or similar) will be done separately, outside this patch
>   series.
> - Add EMACS stuff at the end of dom0less-build.c file.
> - Wrap "d_cfg.max_grant_frames = gnttab_dom0_frames();" by #ifdef CONFIG_GRANT_TABLE
>   as gnttab_dom0_frames() is only defined in case when CONFIG_GRANT_TABLE=y.
> - Update the commit message: drop info about arch_xen_domctl_createdomain() as this
>   function was dropped in previous version of this patch.
> ---
> Changes in v3:
>  - Move changes connected to the patch "xen/arm: dom0less delay xenstore initialization"
>    to common.
>    Also, some necessary parts for the mentioned patches were moved
>    to common (such as alloc_xenstore_evtchn(), ... ).
>    Not all changes are moved, changes connected to alloc_xenstore_params() and
>    construct_domu() will be moved in the following patches of this patch series.
>  - Move parsing of capabilities property to common code.
>  - Align parsing of "passthrough", "multiboot,device-tree" properties with staging.
>  - Drop arch_xen_domctl_createdomain().
>  - Add 'select HAS_DEVICE_TREE' for config HAS_DOM0LESS.
>  - Add empty lines after license in the top of newly added files.
>  - s/arch_create_domus/arch_create_domUs.
>  - Add footer below commit message regarding the naming of dom0less.
> ---
> Changes in v2:
>  - Convert 'depends on Arm' to 'depends on HAS_DOM0LESS' for
>    CONFIG_DOM0LESS_BOOT.
>  - Change 'default Arm' to 'default y' for CONFIG_DOM0LESS_BOOT as there is
>    dependency on HAS_DOM0LESS.
>  - Introduce HAS_DOM0LESS and enable it for Arm.
>  - Update the commit message.
> ---
>  xen/arch/arm/Kconfig                      |   9 +-
>  xen/arch/arm/dom0less-build.c             | 371 ++++------------------
>  xen/arch/arm/include/asm/Makefile         |   1 +
>  xen/arch/arm/include/asm/dom0less-build.h |  34 --
>  xen/common/Kconfig                        |  12 +
>  xen/common/device-tree/Makefile           |   1 +
>  xen/common/device-tree/dom0less-build.c   | 294 +++++++++++++++++
>  xen/include/asm-generic/dom0less-build.h  |  50 +++
>  8 files changed, 415 insertions(+), 357 deletions(-)
>  delete mode 100644 xen/arch/arm/include/asm/dom0less-build.h
>  create mode 100644 xen/common/device-tree/dom0less-build.c
>  create mode 100644 xen/include/asm-generic/dom0less-build.h
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index da8a406f5a..d0e0a7753c 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -15,6 +15,7 @@ config ARM
>  	select GENERIC_UART_INIT
>  	select HAS_ALTERNATIVE if HAS_VMAP
>  	select HAS_DEVICE_TREE
> +	select HAS_DOM0LESS
>  	select HAS_STACK_PROTECTOR
>  	select HAS_UBSAN
>  
> @@ -120,14 +121,6 @@ config GICV2
>  	  Driver for the ARM Generic Interrupt Controller v2.
>  	  If unsure, say Y
>  
> -config DOM0LESS_BOOT
> -	bool "Dom0less boot support" if EXPERT
> -	default y
> -	help
> -	  Dom0less boot support enables Xen to create and start domU guests during
> -	  Xen boot without the need of a control domain (Dom0), which could be
> -	  present anyway.
> -
>  config GICV3
>  	bool "GICv3 driver"
>  	depends on !NEW_VGIC
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index a356fc94fc..ef49495d4f 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -22,48 +22,7 @@
>  #include 
>  #include 
>  
> -#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
> -
> -static domid_t __initdata xs_domid = DOMID_INVALID;
> -static bool __initdata need_xenstore;
> -
> -void __init set_xs_domain(struct domain *d)
> -{
> -    xs_domid = d->domain_id;
> -    set_global_virq_handler(d, VIRQ_DOM_EXC);
> -}
> -
> -bool __init is_dom0less_mode(void)
> -{
> -    struct bootmodules *mods = &bootinfo.modules;
> -    struct bootmodule *mod;
> -    unsigned int i;
> -    bool dom0found = false;
> -    bool domUfound = false;
> -
> -    /* Look into the bootmodules */
> -    for ( i = 0 ; i < mods->nr_mods ; i++ )
> -    {
> -        mod = &mods->module[i];
> -        /* Find if dom0 and domU kernels are present */
> -        if ( mod->kind == BOOTMOD_KERNEL )
> -        {
> -            if ( mod->domU == false )
> -            {
> -                dom0found = true;
> -                break;
> -            }
> -            else
> -                domUfound = true;
> -        }
> -    }
> -
> -    /*
> -     * If there is no dom0 kernel but at least one domU, then we are in
> -     * dom0less mode
> -     */
> -    return ( !dom0found && domUfound );
> -}
> +bool __initdata need_xenstore;
>  
>  #ifdef CONFIG_VGICV2
>  static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
> @@ -686,25 +645,6 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
>      return -EINVAL;
>  }
>  
> -static int __init alloc_xenstore_evtchn(struct domain *d)
> -{
> -    evtchn_alloc_unbound_t alloc;
> -    int rc;
> -
> -    alloc.dom = d->domain_id;
> -    alloc.remote_dom = xs_domid;
> -    rc = evtchn_alloc_unbound(&alloc, 0);
> -    if ( rc )
> -    {
> -        printk("Failed allocating event channel for domain\n");
> -        return rc;
> -    }
> -
> -    d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port;
> -
> -    return 0;
> -}
> -
>  #define XENSTORE_PFN_OFFSET 1
>  static int __init alloc_xenstore_page(struct domain *d)
>  {
> @@ -771,36 +711,6 @@ static int __init alloc_xenstore_params(struct kernel_info *kinfo)
>      return rc;
>  }
>  
> -static void __init initialize_domU_xenstore(void)
> -{
> -    struct domain *d;
> -
> -    if ( xs_domid == DOMID_INVALID )
> -        return;
> -
> -    for_each_domain( d )
> -    {
> -        uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN];
> -        int rc;
> -
> -        if ( gfn == 0 )
> -            continue;
> -
> -        if ( is_xenstore_domain(d) )
> -            continue;
> -
> -        rc = alloc_xenstore_evtchn(d);
> -        if ( rc < 0 )
> -            panic("%pd: Failed to allocate xenstore_evtchn\n", d);
> -
> -        if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) )
> -        {
> -            ASSERT(gfn < UINT32_MAX);
> -            gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn);
> -        }
> -    }
> -}
> -
>  static void __init domain_vcpu_affinity(struct domain *d,
>                                          const struct dt_device_node *node)
>  {
> @@ -906,8 +816,8 @@ static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
>  }
>  #endif /* CONFIG_ARCH_PAGING_MEMPOOL */
>  
> -static int __init construct_domU(struct domain *d,
> -                                 const struct dt_device_node *node)
> +int __init construct_domU(struct domain *d,
> +                          const struct dt_device_node *node)
>  {
>      struct kernel_info kinfo = KERNEL_INFO_INIT;
>      const char *dom0less_enhanced;
> @@ -1009,246 +919,77 @@ static int __init construct_domU(struct domain *d,
>      return alloc_xenstore_params(&kinfo);
>  }
>  
> -void __init create_domUs(void)
> +void __init arch_create_domUs(struct dt_device_node *node,
> +                       struct xen_domctl_createdomain *d_cfg,
> +                       unsigned int flags)
>  {
> -    struct dt_device_node *node;
> -    const char *dom0less_iommu;
> -    bool iommu = false;
> -    const struct dt_device_node *cpupool_node,
> -                                *chosen = dt_find_node_by_path("/chosen");
> -    const char *llc_colors_str = NULL;
> -
> -    BUG_ON(chosen == NULL);
> -    dt_for_each_child_node(chosen, node)
> -    {
> -        struct domain *d;
> -        struct xen_domctl_createdomain d_cfg = {
> -            .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
> -            .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
> -            /*
> -             * The default of 1023 should be sufficient for guests because
> -             * on ARM we don't bind physical interrupts to event channels.
> -             * The only use of the evtchn port is inter-domain communications.
> -             * 1023 is also the default value used in libxl.
> -             */
> -            .max_evtchn_port = 1023,
> -            .max_grant_frames = -1,
> -            .max_maptrack_frames = -1,
> -            .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
> -        };
> -        unsigned int flags = 0U;
> -        bool has_dtb = false;
> -        uint32_t val;
> -        int rc;
> -
> -        if ( !dt_device_is_compatible(node, "xen,domain") )
> -            continue;
> -
> -        if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
> -            panic("No more domain IDs available\n");
> +    uint32_t val;
>  
> -        if ( dt_property_read_u32(node, "capabilities", &val) )
> -        {
> -            if ( val & ~DOMAIN_CAPS_MASK )
> -                panic("Invalid capabilities (%"PRIx32")\n", val);
> -
> -            if ( val & DOMAIN_CAPS_CONTROL )
> -                flags |= CDF_privileged;
> -
> -            if ( val & DOMAIN_CAPS_HARDWARE )
> -            {
> -                if ( hardware_domain )
> -                    panic("Only 1 hardware domain can be specified! (%pd)\n",
> -                           hardware_domain);
> -
> -                d_cfg.max_grant_frames = gnttab_dom0_frames();
> -                d_cfg.max_evtchn_port = -1;
> -                flags |= CDF_hardware;
> -                iommu = true;
> -            }
> -
> -            if ( val & DOMAIN_CAPS_XENSTORE )
> -            {
> -                if ( xs_domid != DOMID_INVALID )
> -                    panic("Only 1 xenstore domain can be specified! (%u)\n",
> -                          xs_domid);
> +    d_cfg->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> +    d_cfg->flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap;

I did some more tests and discovered that this needs to be |= to modify
flags passed to it (e.g. XEN_DOMCTL_CDF_iommu), rather than reset them
completely. Overall, it should be

    d_cfg->flags |= XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap;

I'll fix it on commit
  
> -                d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain;
> -                d_cfg.max_evtchn_port = -1;
> -            }
> -        }
> -
> -        if ( dt_find_property(node, "xen,static-mem", NULL) )
> -        {
> -            if ( llc_coloring_enabled )
> -                panic("LLC coloring and static memory are incompatible\n");
> -
> -            flags |= CDF_staticmem;
> -        }
> -
> -        if ( dt_property_read_bool(node, "direct-map") )
> -        {
> -            if ( !(flags & CDF_staticmem) )
> -                panic("direct-map is not valid for domain %s without static allocation.\n",
> -                      dt_node_name(node));
> -
> -            flags |= CDF_directmap;
> -        }
> -
> -        if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) )
> -            panic("Missing property 'cpus' for domain %s\n",
> -                  dt_node_name(node));
> -
> -        if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) )
> -        {
> -            if ( flags & CDF_hardware )
> -                panic("Don't specify passthrough for hardware domain\n");
> -
> -            if ( !strcmp(dom0less_iommu, "enabled") )
> -                iommu = true;
> -        }
> -
> -        if ( (flags & CDF_hardware) && !(flags & CDF_directmap) &&
> -             !iommu_enabled )
> -            panic("non-direct mapped hardware domain requires iommu\n");
> -
> -        if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") )
> -        {
> -            if ( flags & CDF_hardware )
> -                panic("\"multiboot,device-tree\" incompatible with hardware domain\n");
> -
> -            has_dtb = true;
> -        }
> -
> -        if ( iommu_enabled && (iommu || has_dtb) )
> -            d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
> -
> -        if ( !dt_property_read_u32(node, "nr_spis", &d_cfg.arch.nr_spis) )
> -        {
> -            int vpl011_virq = GUEST_VPL011_SPI;
> -
> -            d_cfg.arch.nr_spis = VGIC_DEF_NR_SPIS;
> -
> -            /*
> -             * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
> -             * set, in which case it'll match the hardware.
> -             *
> -             * Since the domain is not yet created, we can't use
> -             * d->arch.vpl011.irq. So the logic to find the vIRQ has to
> -             * be hardcoded.
> -             * The logic here shall be consistent with the one in
> -             * domain_vpl011_init().
> -             */
> -            if ( flags & CDF_directmap )
> -            {
> -                vpl011_virq = serial_irq(SERHND_DTUART);
> -                if ( vpl011_virq < 0 )
> -                    panic("Error getting IRQ number for this serial port %d\n",
> -                          SERHND_DTUART);
> -            }
> +    if ( !dt_property_read_u32(node, "nr_spis", &d_cfg->arch.nr_spis) )
> +    {
> +        int vpl011_virq = GUEST_VPL011_SPI;
>  
> -            /*
> -             * vpl011 uses one emulated SPI. If vpl011 is requested, make
> -             * sure that we allocate enough SPIs for it.
> -             */
> -            if ( dt_property_read_bool(node, "vpl011") )
> -                d_cfg.arch.nr_spis = MAX(d_cfg.arch.nr_spis,
> -                                         vpl011_virq - 32 + 1);
> -        }
> -        else if ( flags & CDF_hardware )
> -            panic("nr_spis cannot be specified for hardware domain\n");
> +        d_cfg->arch.nr_spis = VGIC_DEF_NR_SPIS;
>  
> -        /* Get the optional property domain-cpupool */
> -        cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
> -        if ( cpupool_node )
> +        /*
> +         * The VPL011 virq is GUEST_VPL011_SPI, unless direct-map is
> +         * set, in which case it'll match the hardware.
> +         *
> +         * Since the domain is not yet created, we can't use
> +         * d->arch.vpl011.irq. So the logic to find the vIRQ has to
> +         * be hardcoded.
> +         * The logic here shall be consistent with the one in
> +         * domain_vpl011_init().
> +         */
> +        if ( flags & CDF_directmap )
>          {
> -            int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
> -            if ( pool_id < 0 )
> -                panic("Error getting cpupool id from domain-cpupool (%d)\n",
> -                      pool_id);
> -            d_cfg.cpupool_id = pool_id;
> +            vpl011_virq = serial_irq(SERHND_DTUART);
> +            if ( vpl011_virq < 0 )
> +                panic("Error getting IRQ number for this serial port %d\n",
> +                        SERHND_DTUART);
>          }
>  
> -        if ( dt_property_read_u32(node, "max_grant_version", &val) )
> -            d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val);
> +        /*
> +            * vpl011 uses one emulated SPI. If vpl011 is requested, make
> +            * sure that we allocate enough SPIs for it.
> +            */
> +        if ( dt_property_read_bool(node, "vpl011") )
> +            d_cfg->arch.nr_spis = MAX(d_cfg->arch.nr_spis,
> +                                      vpl011_virq - 32 + 1);
> +    }
> +    else if ( flags & CDF_hardware )
> +        panic("nr_spis cannot be specified for hardware domain\n");
>  
> -        if ( dt_property_read_u32(node, "max_grant_frames", &val) )
> -        {
> -            if ( val > INT32_MAX )
> -                panic("max_grant_frames (%"PRIu32") overflow\n", val);
> -            d_cfg.max_grant_frames = val;
> -        }
> +    if ( dt_get_property(node, "sve", &val) )
> +    {
> +#ifdef CONFIG_ARM64_SVE
> +        unsigned int sve_vl_bits;
> +        bool ret = false;
>  
> -        if ( dt_property_read_u32(node, "max_maptrack_frames", &val) )
> +        if ( !val )
>          {
> -            if ( val > INT32_MAX )
> -                panic("max_maptrack_frames (%"PRIu32") overflow\n", val);
> -            d_cfg.max_maptrack_frames = val;
> +            /* Property found with no value, means max HW VL supported */
> +            ret = sve_domctl_vl_param(-1, &sve_vl_bits);
>          }
> -
> -        if ( dt_get_property(node, "sve", &val) )
> +        else
>          {
> -#ifdef CONFIG_ARM64_SVE
> -            unsigned int sve_vl_bits;
> -            bool ret = false;
> -
> -            if ( !val )
> -            {
> -                /* Property found with no value, means max HW VL supported */
> -                ret = sve_domctl_vl_param(-1, &sve_vl_bits);
> -            }
> +            if ( dt_property_read_u32(node, "sve", &val) )
> +                ret = sve_domctl_vl_param(val, &sve_vl_bits);
>              else
> -            {
> -                if ( dt_property_read_u32(node, "sve", &val) )
> -                    ret = sve_domctl_vl_param(val, &sve_vl_bits);
> -                else
> -                    panic("Error reading 'sve' property\n");
> -            }
> +                panic("Error reading 'sve' property\n");
> +        }
>  
> -            if ( ret )
> -                d_cfg.arch.sve_vl = sve_encode_vl(sve_vl_bits);
> -            else
> -                panic("SVE vector length error\n");
> +        if ( ret )
> +            d_cfg->arch.sve_vl = sve_encode_vl(sve_vl_bits);
> +        else
> +            panic("SVE vector length error\n");
>  #else
> -            panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
> +        panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
>  #endif
> -        }
> -
> -        dt_property_read_string(node, "llc-colors", &llc_colors_str);
> -        if ( !llc_coloring_enabled && llc_colors_str )
> -            panic("'llc-colors' found, but LLC coloring is disabled\n");
> -
> -        /*
> -         * The variable max_init_domid is initialized with zero, so here it's
> -         * very important to use the pre-increment operator to call
> -         * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
> -         */
> -        d = domain_create(++max_init_domid, &d_cfg, flags);
> -        if ( IS_ERR(d) )
> -            panic("Error creating domain %s (rc = %ld)\n",
> -                  dt_node_name(node), PTR_ERR(d));
> -
> -        if ( llc_coloring_enabled &&
> -             (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) )
> -            panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
> -                  dt_node_name(node), rc);
> -
> -        d->is_console = true;
> -        dt_device_set_used_by(node, d->domain_id);
> -
> -        rc = construct_domU(d, node);
> -        if ( rc )
> -            panic("Could not set up domain %s (rc = %d)\n",
> -                  dt_node_name(node), rc);
> -
> -        if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain )
> -            set_xs_domain(d);
>      }
> -
> -    if ( need_xenstore && xs_domid == DOMID_INVALID )
> -        panic("xenstore requested, but xenstore domain not present\n");
> -
> -    initialize_domU_xenstore();
>  }
>  
>  /*
> diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile
> index 4a4036c951..831c914cce 100644
> --- a/xen/arch/arm/include/asm/Makefile
> +++ b/xen/arch/arm/include/asm/Makefile
> @@ -1,6 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  generic-y += altp2m.h
>  generic-y += device.h
> +generic-y += dom0less-build.h
>  generic-y += hardirq.h
>  generic-y += iocap.h
>  generic-y += paging.h
> diff --git a/xen/arch/arm/include/asm/dom0less-build.h b/xen/arch/arm/include/asm/dom0less-build.h
> deleted file mode 100644
> index b0e41a1954..0000000000
> --- a/xen/arch/arm/include/asm/dom0less-build.h
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -
> -#ifndef __ASM_DOM0LESS_BUILD_H_
> -#define __ASM_DOM0LESS_BUILD_H_
> -
> -#include 
> -
> -#ifdef CONFIG_DOM0LESS_BOOT
> -
> -void create_domUs(void);
> -bool is_dom0less_mode(void);
> -void set_xs_domain(struct domain *d);
> -
> -#else /* !CONFIG_DOM0LESS_BOOT */
> -
> -static inline void create_domUs(void) {}
> -static inline bool is_dom0less_mode(void)
> -{
> -    return false;
> -}
> -static inline void set_xs_domain(struct domain *d) {}
> -
> -#endif /* CONFIG_DOM0LESS_BOOT */
> -
> -#endif /* __ASM_DOM0LESS_BUILD_H_ */
> -
> -/*
> - * Local variables:
> - * mode: C
> - * c-file-style: "BSD"
> - * c-basic-offset: 4
> - * indent-tabs-mode: nil
> - * End:
> - */
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index be28060716..f291a5c1c7 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -12,6 +12,15 @@ config CORE_PARKING
>  	bool
>  	depends on NR_CPUS > 1
>  
> +config DOM0LESS_BOOT
> +	bool "Dom0less boot support" if EXPERT
> +	depends on HAS_DOM0LESS && HAS_DEVICE_TREE
> +	default y
> +	help
> +	  Dom0less boot support enables Xen to create and start domU guests during
> +	  Xen boot without the need of a control domain (Dom0), which could be
> +	  present anyway.
> +
>  config GRANT_TABLE
>  	bool "Grant table support" if EXPERT
>  	default y
> @@ -74,6 +83,9 @@ config HAS_DEVICE_TREE
>  	bool
>  	select LIBFDT
>  
> +config HAS_DOM0LESS
> +	bool
> +
>  config HAS_DIT # Data Independent Timing
>  	bool
>  
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 7c549be38a..f3dafc9b81 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1,5 +1,6 @@
>  obj-y += bootfdt.init.o
>  obj-y += bootinfo.init.o
>  obj-y += device-tree.o
> +obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
>  obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
>  obj-y += intc.o
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> new file mode 100644
> index 0000000000..203b762e2c
> --- /dev/null
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -0,0 +1,294 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static domid_t __initdata xs_domid = DOMID_INVALID;
> +
> +void __init set_xs_domain(struct domain *d)
> +{
> +    xs_domid = d->domain_id;
> +    set_global_virq_handler(d, VIRQ_DOM_EXC);
> +}
> +
> +bool __init is_dom0less_mode(void)
> +{
> +    struct bootmodules *mods = &bootinfo.modules;
> +    struct bootmodule *mod;
> +    unsigned int i;
> +    bool dom0found = false;
> +    bool domUfound = false;
> +
> +    /* Look into the bootmodules */
> +    for ( i = 0 ; i < mods->nr_mods ; i++ )
> +    {
> +        mod = &mods->module[i];
> +        /* Find if dom0 and domU kernels are present */
> +        if ( mod->kind == BOOTMOD_KERNEL )
> +        {
> +            if ( mod->domU == false )
> +            {
> +                dom0found = true;
> +                break;
> +            }
> +            else
> +                domUfound = true;
> +        }
> +    }
> +
> +    /*
> +     * If there is no dom0 kernel but at least one domU, then we are in
> +     * dom0less mode
> +     */
> +    return ( !dom0found && domUfound );
> +}
> +
> +static int __init alloc_xenstore_evtchn(struct domain *d)
> +{
> +    evtchn_alloc_unbound_t alloc;
> +    int rc;
> +
> +    alloc.dom = d->domain_id;
> +    alloc.remote_dom = xs_domid;
> +    rc = evtchn_alloc_unbound(&alloc, 0);
> +    if ( rc )
> +    {
> +        printk("Failed allocating event channel for domain\n");
> +        return rc;
> +    }
> +
> +    d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port;
> +
> +    return 0;
> +}
> +
> +static void __init initialize_domU_xenstore(void)
> +{
> +    struct domain *d;
> +
> +    if ( xs_domid == DOMID_INVALID )
> +        return;
> +
> +    for_each_domain( d )
> +    {
> +        uint64_t gfn = d->arch.hvm.params[HVM_PARAM_STORE_PFN];
> +        int rc;
> +
> +        if ( gfn == 0 )
> +            continue;
> +
> +        if ( is_xenstore_domain(d) )
> +            continue;
> +
> +        rc = alloc_xenstore_evtchn(d);
> +        if ( rc < 0 )
> +            panic("%pd: Failed to allocate xenstore_evtchn\n", d);
> +
> +        if ( gfn != XENSTORE_PFN_LATE_ALLOC && IS_ENABLED(CONFIG_GRANT_TABLE) )
> +        {
> +            ASSERT(gfn < UINT32_MAX);
> +            gnttab_seed_entry(d, GNTTAB_RESERVED_XENSTORE, xs_domid, gfn);
> +        }
> +    }
> +}
> +
> +void __init create_domUs(void)
> +{
> +    struct dt_device_node *node;
> +    const char *dom0less_iommu;
> +    bool iommu = false;
> +    const struct dt_device_node *cpupool_node,
> +                                *chosen = dt_find_node_by_path("/chosen");
> +    const char *llc_colors_str = NULL;
> +
> +    BUG_ON(chosen == NULL);
> +    dt_for_each_child_node(chosen, node)
> +    {
> +        struct domain *d;
> +        struct xen_domctl_createdomain d_cfg = {0};
> +        unsigned int flags = 0U;
> +        bool has_dtb = false;
> +        uint32_t val;
> +        int rc;
> +
> +        if ( !dt_device_is_compatible(node, "xen,domain") )
> +            continue;
> +
> +        if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
> +            panic("No more domain IDs available\n");
> +
> +        d_cfg.max_evtchn_port = 1023;
> +        d_cfg.max_grant_frames = -1;
> +        d_cfg.max_maptrack_frames = -1;
> +        d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version);
> +
> +        if ( dt_property_read_u32(node, "capabilities", &val) )
> +        {
> +            if ( val & ~DOMAIN_CAPS_MASK )
> +                panic("Invalid capabilities (%"PRIx32")\n", val);
> +
> +            if ( val & DOMAIN_CAPS_CONTROL )
> +                flags |= CDF_privileged;
> +
> +            if ( val & DOMAIN_CAPS_HARDWARE )
> +            {
> +                if ( hardware_domain )
> +                    panic("Only 1 hardware domain can be specified! (%pd)\n",
> +                            hardware_domain);
> +
> +#ifdef CONFIG_GRANT_TABLE
> +                d_cfg.max_grant_frames = gnttab_dom0_frames();
> +#endif
> +                d_cfg.max_evtchn_port = -1;
> +                flags |= CDF_hardware;
> +                iommu = true;
> +            }
> +
> +            if ( val & DOMAIN_CAPS_XENSTORE )
> +            {
> +                if ( xs_domid != DOMID_INVALID )
> +                    panic("Only 1 xenstore domain can be specified! (%u)\n",
> +                            xs_domid);
> +
> +                d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain;
> +                d_cfg.max_evtchn_port = -1;
> +            }
> +        }
> +
> +        if ( dt_find_property(node, "xen,static-mem", NULL) )
> +        {
> +            if ( llc_coloring_enabled )
> +                panic("LLC coloring and static memory are incompatible\n");
> +
> +            flags |= CDF_staticmem;
> +        }
> +
> +        if ( dt_property_read_bool(node, "direct-map") )
> +        {
> +            if ( !(flags & CDF_staticmem) )
> +                panic("direct-map is not valid for domain %s without static allocation.\n",
> +                      dt_node_name(node));
> +
> +            flags |= CDF_directmap;
> +        }
> +
> +        if ( !dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus) )
> +            panic("Missing property 'cpus' for domain %s\n",
> +                  dt_node_name(node));
> +
> +        if ( !dt_property_read_string(node, "passthrough", &dom0less_iommu) )
> +        {
> +            if ( flags & CDF_hardware )
> +                panic("Don't specify passthrough for hardware domain\n");
> +
> +            if ( !strcmp(dom0less_iommu, "enabled") )
> +                iommu = true;
> +        }
> +
> +        if ( (flags & CDF_hardware) && !(flags & CDF_directmap) &&
> +             !iommu_enabled )
> +            panic("non-direct mapped hardware domain requires iommu\n");
> +
> +        if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") )
> +        {
> +            if ( flags & CDF_hardware )
> +                panic("\"multiboot,device-tree\" incompatible with hardware domain\n");
> +
> +            has_dtb = true;
> +        }
> +
> +        if ( iommu_enabled && (iommu || has_dtb) )
> +            d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
> +
> +        /* Get the optional property domain-cpupool */
> +        cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
> +        if ( cpupool_node )
> +        {
> +            int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
> +            if ( pool_id < 0 )
> +                panic("Error getting cpupool id from domain-cpupool (%d)\n",
> +                      pool_id);
> +            d_cfg.cpupool_id = pool_id;
> +        }
> +
> +        if ( dt_property_read_u32(node, "max_grant_version", &val) )
> +            d_cfg.grant_opts = XEN_DOMCTL_GRANT_version(val);
> +
> +        if ( dt_property_read_u32(node, "max_grant_frames", &val) )
> +        {
> +            if ( val > INT32_MAX )
> +                panic("max_grant_frames (%"PRIu32") overflow\n", val);
> +            d_cfg.max_grant_frames = val;
> +        }
> +
> +        if ( dt_property_read_u32(node, "max_maptrack_frames", &val) )
> +        {
> +            if ( val > INT32_MAX )
> +                panic("max_maptrack_frames (%"PRIu32") overflow\n", val);
> +            d_cfg.max_maptrack_frames = val;
> +        }
> +
> +        dt_property_read_string(node, "llc-colors", &llc_colors_str);
> +        if ( !llc_coloring_enabled && llc_colors_str )
> +            panic("'llc-colors' found, but LLC coloring is disabled\n");
> +
> +        arch_create_domUs(node, &d_cfg, flags);
> +
> +        /*
> +         * The variable max_init_domid is initialized with zero, so here it's
> +         * very important to use the pre-increment operator to call
> +         * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
> +         */
> +        d = domain_create(++max_init_domid, &d_cfg, flags);
> +        if ( IS_ERR(d) )
> +            panic("Error creating domain %s (rc = %ld)\n",
> +                  dt_node_name(node), PTR_ERR(d));
> +
> +        if ( llc_coloring_enabled &&
> +             (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) )
> +            panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
> +                  dt_node_name(node), rc);
> +
> +        d->is_console = true;
> +        dt_device_set_used_by(node, d->domain_id);
> +
> +        rc = construct_domU(d, node);
> +        if ( rc )
> +            panic("Could not set up domain %s (rc = %d)\n",
> +                  dt_node_name(node), rc);
> +
> +        if ( d_cfg.flags & XEN_DOMCTL_CDF_xs_domain )
> +            set_xs_domain(d);
> +    }
> +
> +    if ( need_xenstore && xs_domid == DOMID_INVALID )
> +        panic("xenstore requested, but xenstore domain not present\n");
> +
> +    initialize_domU_xenstore();
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
> new file mode 100644
> index 0000000000..ef2073d802
> --- /dev/null
> +++ b/xen/include/asm-generic/dom0less-build.h
> @@ -0,0 +1,50 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __ASM_GENERIC_DOM0LESS_BUILD_H__
> +#define __ASM_GENERIC_DOM0LESS_BUILD_H__
> +
> +#include 
> +
> +struct domain;
> +
> +#ifdef CONFIG_DOM0LESS_BOOT
> +
> +#include 
> +
> +struct dt_device_node;
> +
> +/* TODO: remove both when construct_domU() will be moved to common. */
> +#define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
> +extern bool need_xenstore;
> +
> +void create_domUs(void);
> +bool is_dom0less_mode(void);
> +void set_xs_domain(struct domain *d);
> +
> +int construct_domU(struct domain *d, const struct dt_device_node *node);
> +
> +void arch_create_domUs(struct dt_device_node *node,
> +                       struct xen_domctl_createdomain *d_cfg,
> +                       unsigned int flags);
> +
> +#else /* !CONFIG_DOM0LESS_BOOT */
> +
> +static inline void create_domUs(void) {}
> +static inline bool is_dom0less_mode(void)
> +{
> +    return false;
> +}
> +static inline void set_xs_domain(struct domain *d) {}
> +
> +#endif /* CONFIG_DOM0LESS_BOOT */
> +
> +#endif /* __ASM_GENERIC_DOM0LESS_BUILD_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Mon May 05 22:16:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 22:16:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976455.1363600 (Exim 4.92)
	(envelope-from )
	id 1uC476-000664-FV; Mon, 05 May 2025 22:16:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976455.1363600; Mon, 05 May 2025 22:16: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 1uC476-00065x-Cx; Mon, 05 May 2025 22:16:40 +0000
Received: by outflank-mailman (input) for mailman id 976455;
 Mon, 05 May 2025 22:16:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uC475-00065r-Be
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 22:16:39 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9bbd5c32-29fe-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 00:16:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 02C9A5C051C;
 Mon,  5 May 2025 22:14:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BC75C4CEED;
 Mon,  5 May 2025 22:16: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" 
X-Inumbo-ID: 9bbd5c32-29fe-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746483394;
	bh=CjL8LGPu4Bfyc0hVImZlWY5Ujss/SIQuzx4+7U/11jM=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Yg9m73fCFG2UQA3AXy4JoAElcp2Oc8PpK0bVsoZyIfZnpRSvLKvzBFAW+jQoEGlox
	 MdAhtBJgstWe9a+juPpDhJLmpYi3gCxdKgsFPObH5tF/33xiWAN6dCdCZxFKvVweg6
	 1eGWyK6RDPzFpS5bx1cdxZG1fm41GHbEPIroav0UYNgmqJuvac+wDnqCGRYFXjsuAq
	 s6j/z09nBGj9EkqvUKQ87NR4QiQBLoPCtOiHM7befVii8mksInUlBc2zQC/tqNRtTS
	 vZNR8/q8HgTgsSMVlfkHRxHIqwNuDlRUuOA2pdFDtkdhRuL8OKZZLSoz1uYZaYuNed
	 8dqFFDYy5zh6A==
From: Sasha Levin 
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Roger Pau Monne ,
	Juergen Gross ,
	Sasha Levin ,
	sstabellini@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH AUTOSEL 6.14 064/642] xen/pci: Do not register devices with segments >= 0x10000
Date: Mon,  5 May 2025 18:04:40 -0400
Message-Id: <20250505221419.2672473-64-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250505221419.2672473-1-sashal@kernel.org>
References: <20250505221419.2672473-1-sashal@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.14.5
Content-Transfer-Encoding: 8bit

From: Roger Pau Monne 

[ Upstream commit 5ccf1b8ae76ddf348e02a0d1564ff9baf8b6c415 ]

The current hypercall interface for doing PCI device operations always uses
a segment field that has a 16 bit width.  However on Linux there are buses
like VMD that hook up devices into the PCI hierarchy at segment >= 0x10000,
after the maximum possible segment enumerated in ACPI.

Attempting to register or manage those devices with Xen would result in
errors at best, or overlaps with existing devices living on the truncated
equivalent segment values.  Note also that the VMD segment numbers are
arbitrarily assigned by the OS, and hence there would need to be some
negotiation between Xen and the OS to agree on how to enumerate VMD
segments and devices behind them.

Skip notifying Xen about those devices.  Given how VMD bridges can
multiplex interrupts on behalf of devices behind them there's no need for
Xen to be aware of such devices for them to be usable by Linux.

Signed-off-by: Roger Pau Monné 
Acked-by: Juergen Gross 
Message-ID: <20250219092059.90850-2-roger.pau@citrix.com>
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 drivers/xen/pci.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 416f231809cb6..bfe07adb3e3a6 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -43,6 +43,18 @@ static int xen_add_device(struct device *dev)
 		pci_mcfg_reserved = true;
 	}
 #endif
+
+	if (pci_domain_nr(pci_dev->bus) >> 16) {
+		/*
+		 * The hypercall interface is limited to 16bit PCI segment
+		 * values, do not attempt to register devices with Xen in
+		 * segments greater or equal than 0x10000.
+		 */
+		dev_info(dev,
+			 "not registering with Xen: invalid PCI segment\n");
+		return 0;
+	}
+
 	if (pci_seg_supported) {
 		DEFINE_RAW_FLEX(struct physdev_pci_device_add, add, optarr, 1);
 
@@ -149,6 +161,16 @@ static int xen_remove_device(struct device *dev)
 	int r;
 	struct pci_dev *pci_dev = to_pci_dev(dev);
 
+	if (pci_domain_nr(pci_dev->bus) >> 16) {
+		/*
+		 * The hypercall interface is limited to 16bit PCI segment
+		 * values.
+		 */
+		dev_info(dev,
+			 "not unregistering with Xen: invalid PCI segment\n");
+		return 0;
+	}
+
 	if (pci_seg_supported) {
 		struct physdev_pci_device device = {
 			.seg = pci_domain_nr(pci_dev->bus),
@@ -182,6 +204,16 @@ int xen_reset_device(const struct pci_dev *dev)
 		.flags = PCI_DEVICE_RESET_FLR,
 	};
 
+	if (pci_domain_nr(dev->bus) >> 16) {
+		/*
+		 * The hypercall interface is limited to 16bit PCI segment
+		 * values.
+		 */
+		dev_info(&dev->dev,
+			 "unable to notify Xen of device reset: invalid PCI segment\n");
+		return 0;
+	}
+
 	return HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_reset, &device);
 }
 EXPORT_SYMBOL_GPL(xen_reset_device);
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 05 22:18:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 22:18:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976465.1363611 (Exim 4.92)
	(envelope-from )
	id 1uC48l-0006cx-QA; Mon, 05 May 2025 22:18:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976465.1363611; Mon, 05 May 2025 22:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uC48l-0006cq-Mz; Mon, 05 May 2025 22:18:23 +0000
Received: by outflank-mailman (input) for mailman id 976465;
 Mon, 05 May 2025 22:18:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uC48j-0006ce-C0
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 22:18:21 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d7cdce45-29fe-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 00:18:17 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 3BEC843992;
 Mon,  5 May 2025 22:18:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E307AC4CEE4;
 Mon,  5 May 2025 22:18: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" 
X-Inumbo-ID: d7cdce45-29fe-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746483495;
	bh=LKiJ3Du4PrOTCeqmGeKj0jGL1iCrO4RXSL8UDCjyWlI=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=PwyvDaRFOrMF/MuFQJLoADuzP2LbBcJXxfwFZOGUnQ/5BmCRypZe0y0LR2xQAPOQQ
	 yg/KuregDORFnBzarsge1b0BJDcOvIEwv8drl3o4ol/6/re9ROS6slxDCz3MQn5tMG
	 weR6rnNPgOaQgkjsBWejPERksw+5yuA/Okg8xhKelbhDSbuMw1qFFNnmcxstwxmFjX
	 TTYFj81YsgdzKekGeGSqEUhADbWUBgtY3aPNsgBAg7w+o2HIK+nEDIW7H9bRThOUSn
	 xVwqEo97vQnDNmmGH/vX2PmZXCJJIGpLaCMu83TTbwFzsPrh1pTCSWil2N9Aq9Pf8e
	 zbNMCu68sy7vQ==
From: Sasha Levin 
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Thomas Huth ,
	Ingo Molnar ,
	Brian Gerst ,
	Juergen Gross ,
	"H . Peter Anvin" ,
	Kees Cook ,
	Linus Torvalds ,
	Sasha Levin ,
	tglx@linutronix.de,
	mingo@redhat.com,
	bp@alien8.de,
	dave.hansen@linux.intel.com,
	x86@kernel.org,
	luto@kernel.org,
	xin@zytor.com,
	rostedt@goodmis.org,
	mhiramat@kernel.org,
	peterz@infradead.org,
	jpoimboe@kernel.org,
	jbaron@akamai.com,
	ryabinin.a.a@gmail.com,
	dennis@kernel.org,
	tj@kernel.org,
	cl@linux.com,
	oleg@redhat.com,
	pbonzini@redhat.com,
	kirill.shutemov@linux.intel.com,
	tytso@mit.edu,
	Jason@zx2c4.com,
	billm@melbpc.org.au,
	nathan@kernel.org,
	linux@treblig.org,
	rppt@kernel.org,
	sohil.mehta@intel.com,
	jackmanb@google.com,
	nik.borisov@suse.com,
	ubizjak@gmail.com,
	samitolvanen@google.com,
	ast@kernel.org,
	andrii@kernel.org,
	dvyukov@google.com,
	glider@google.com,
	ak@linux.intel.com,
	thomas.lendacky@amd.com,
	dwmw@amazon.co.uk,
	andrew.cooper3@citrix.com,
	wangkefeng.wang@huawei.com,
	akpm@linux-foundation.org,
	baohua@kernel.org,
	ziy@nvidia.com,
	arnd@arndb.de,
	kees@kernel.org,
	seanjc@google.com,
	pankaj.gupta@amd.com,
	jhubbard@nvidia.com,
	vincenzo.frascino@arm.com,
	geert@linux-m68k.org,
	peterx@redhat.com,
	david@redhat.com,
	anshuman.khandual@arm.com,
	lorenzo.stoakes@oracle.com,
	broonie@kernel.org,
	jason.andryuk@amd.com,
	apopple@nvidia.com,
	bhe@redhat.com,
	yuehaibing@huawei.com,
	ardb@kernel.org,
	joel.granados@kernel.org,
	jolsa@kernel.org,
	rick.p.edgecombe@intel.com,
	kai.huang@intel.com,
	patryk.wlazlyn@linux.intel.com,
	kevin.brodsky@arm.com,
	bigeasy@linutronix.de,
	thomas.weissschuh@linutronix.de,
	sneves@dei.uc.pt,
	namcao@linutronix.de,
	anna-maria@linutronix.de,
	christophe.leroy@csgroup.eu,
	linux-trace-kernel@vger.kernel.org,
	kasan-dev@googlegroups.com,
	virtualization@lists.linux.dev,
	linux-mm@kvack.org,
	xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org,
	linux-coco@lists.linux.dev,
	llvm@lists.linux.dev
Subject: [PATCH AUTOSEL 6.14 083/642] x86/headers: Replace __ASSEMBLY__ with __ASSEMBLER__ in non-UAPI headers
Date: Mon,  5 May 2025 18:04:59 -0400
Message-Id: <20250505221419.2672473-83-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250505221419.2672473-1-sashal@kernel.org>
References: <20250505221419.2672473-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.14.5
Content-Transfer-Encoding: 8bit

From: Thomas Huth 

[ Upstream commit 24a295e4ef1ca8e97d8b7015e1887b6e83e1c8be ]

While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.

This can be very confusing when switching between userspace
and kernelspace coding, or when dealing with UAPI headers that
rather should use __ASSEMBLER__ instead. So let's standardize on
the __ASSEMBLER__ macro that is provided by the compilers now.

This is mostly a mechanical patch (done with a simple "sed -i"
statement), with some manual tweaks in , 
and  that mentioned this macro in comments with some
missing underscores.

Signed-off-by: Thomas Huth 
Signed-off-by: Ingo Molnar 
Cc: Brian Gerst 
Cc: Juergen Gross 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/20250314071013.1575167-38-thuth@redhat.com
Signed-off-by: Sasha Levin 
---
 arch/x86/boot/boot.h                        |  4 ++--
 arch/x86/entry/vdso/extable.h               |  2 +-
 arch/x86/include/asm/alternative.h          |  6 +++---
 arch/x86/include/asm/asm.h                  | 10 +++++-----
 arch/x86/include/asm/boot.h                 |  2 +-
 arch/x86/include/asm/cpufeature.h           |  4 ++--
 arch/x86/include/asm/cpumask.h              |  4 ++--
 arch/x86/include/asm/current.h              |  4 ++--
 arch/x86/include/asm/desc_defs.h            |  4 ++--
 arch/x86/include/asm/dwarf2.h               |  2 +-
 arch/x86/include/asm/fixmap.h               |  4 ++--
 arch/x86/include/asm/frame.h                | 10 +++++-----
 arch/x86/include/asm/fred.h                 |  4 ++--
 arch/x86/include/asm/fsgsbase.h             |  4 ++--
 arch/x86/include/asm/ftrace.h               |  8 ++++----
 arch/x86/include/asm/hw_irq.h               |  4 ++--
 arch/x86/include/asm/ibt.h                  | 12 ++++++------
 arch/x86/include/asm/idtentry.h             |  6 +++---
 arch/x86/include/asm/inst.h                 |  2 +-
 arch/x86/include/asm/irqflags.h             | 10 +++++-----
 arch/x86/include/asm/jump_label.h           |  4 ++--
 arch/x86/include/asm/kasan.h                |  2 +-
 arch/x86/include/asm/kexec.h                |  4 ++--
 arch/x86/include/asm/linkage.h              |  6 +++---
 arch/x86/include/asm/mem_encrypt.h          |  4 ++--
 arch/x86/include/asm/msr.h                  |  4 ++--
 arch/x86/include/asm/nops.h                 |  2 +-
 arch/x86/include/asm/nospec-branch.h        |  6 +++---
 arch/x86/include/asm/orc_types.h            |  4 ++--
 arch/x86/include/asm/page.h                 |  4 ++--
 arch/x86/include/asm/page_32.h              |  4 ++--
 arch/x86/include/asm/page_32_types.h        |  4 ++--
 arch/x86/include/asm/page_64.h              |  4 ++--
 arch/x86/include/asm/page_64_types.h        |  2 +-
 arch/x86/include/asm/page_types.h           |  4 ++--
 arch/x86/include/asm/paravirt.h             | 14 +++++++-------
 arch/x86/include/asm/paravirt_types.h       |  4 ++--
 arch/x86/include/asm/percpu.h               |  4 ++--
 arch/x86/include/asm/pgtable-2level_types.h |  4 ++--
 arch/x86/include/asm/pgtable-3level_types.h |  4 ++--
 arch/x86/include/asm/pgtable-invert.h       |  4 ++--
 arch/x86/include/asm/pgtable.h              | 12 ++++++------
 arch/x86/include/asm/pgtable_32.h           |  4 ++--
 arch/x86/include/asm/pgtable_32_areas.h     |  2 +-
 arch/x86/include/asm/pgtable_64.h           |  6 +++---
 arch/x86/include/asm/pgtable_64_types.h     |  4 ++--
 arch/x86/include/asm/pgtable_types.h        | 10 +++++-----
 arch/x86/include/asm/prom.h                 |  4 ++--
 arch/x86/include/asm/pti.h                  |  4 ++--
 arch/x86/include/asm/ptrace.h               |  4 ++--
 arch/x86/include/asm/purgatory.h            |  4 ++--
 arch/x86/include/asm/pvclock-abi.h          |  4 ++--
 arch/x86/include/asm/realmode.h             |  4 ++--
 arch/x86/include/asm/segment.h              |  8 ++++----
 arch/x86/include/asm/setup.h                |  6 +++---
 arch/x86/include/asm/setup_data.h           |  4 ++--
 arch/x86/include/asm/shared/tdx.h           |  4 ++--
 arch/x86/include/asm/shstk.h                |  4 ++--
 arch/x86/include/asm/signal.h               |  8 ++++----
 arch/x86/include/asm/smap.h                 |  6 +++---
 arch/x86/include/asm/smp.h                  |  4 ++--
 arch/x86/include/asm/tdx.h                  |  4 ++--
 arch/x86/include/asm/thread_info.h          | 12 ++++++------
 arch/x86/include/asm/unwind_hints.h         |  4 ++--
 arch/x86/include/asm/vdso/getrandom.h       |  4 ++--
 arch/x86/include/asm/vdso/gettimeofday.h    |  4 ++--
 arch/x86/include/asm/vdso/processor.h       |  4 ++--
 arch/x86/include/asm/vdso/vsyscall.h        |  4 ++--
 arch/x86/include/asm/xen/interface.h        | 10 +++++-----
 arch/x86/include/asm/xen/interface_32.h     |  4 ++--
 arch/x86/include/asm/xen/interface_64.h     |  4 ++--
 arch/x86/math-emu/control_w.h               |  2 +-
 arch/x86/math-emu/exception.h               |  6 +++---
 arch/x86/math-emu/fpu_emu.h                 |  6 +++---
 arch/x86/math-emu/status_w.h                |  6 +++---
 arch/x86/realmode/rm/realmode.h             |  4 ++--
 arch/x86/realmode/rm/wakeup.h               |  2 +-
 tools/arch/x86/include/asm/asm.h            |  8 ++++----
 tools/arch/x86/include/asm/nops.h           |  2 +-
 tools/arch/x86/include/asm/orc_types.h      |  4 ++--
 tools/arch/x86/include/asm/pvclock-abi.h    |  4 ++--
 81 files changed, 201 insertions(+), 201 deletions(-)

diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index 0f24f7ebec9ba..38f17a1e1e367 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -16,7 +16,7 @@
 
 #define STACK_SIZE	1024	/* Minimum number of bytes for stack */
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 #include 
@@ -327,6 +327,6 @@ void probe_cards(int unsafe);
 /* video-vesa.c */
 void vesa_store_edid(void);
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* BOOT_BOOT_H */
diff --git a/arch/x86/entry/vdso/extable.h b/arch/x86/entry/vdso/extable.h
index b56f6b0129416..baba612b832c3 100644
--- a/arch/x86/entry/vdso/extable.h
+++ b/arch/x86/entry/vdso/extable.h
@@ -7,7 +7,7 @@
  * vDSO uses a dedicated handler the addresses are relative to the overall
  * exception table, not each individual entry.
  */
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 #define _ASM_VDSO_EXTABLE_HANDLE(from, to)	\
 	ASM_VDSO_EXTABLE_HANDLE from to
 
diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
index e3903b731305c..8e4fb4828e1bd 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -15,7 +15,7 @@
 #define ALT_DIRECT_CALL(feature) ((ALT_FLAG_DIRECT_CALL << ALT_FLAGS_SHIFT) | (feature))
 #define ALT_CALL_ALWAYS		ALT_DIRECT_CALL(X86_FEATURE_ALWAYS)
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 
@@ -286,7 +286,7 @@ static inline int alternatives_text_reserved(void *start, void *end)
 void BUG_func(void);
 void nop_func(void);
 
-#else /* __ASSEMBLY__ */
+#else /* __ASSEMBLER__ */
 
 #ifdef CONFIG_SMP
 	.macro LOCK_PREFIX
@@ -369,6 +369,6 @@ void nop_func(void);
 	ALTERNATIVE_2 oldinstr, newinstr_no, X86_FEATURE_ALWAYS,	\
 	newinstr_yes, ft_flags
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ASM_X86_ALTERNATIVE_H */
diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
index 2bec0c89a95c2..e9653ee72813c 100644
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_ASM_H
 #define _ASM_X86_ASM_H
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 # define __ASM_FORM(x, ...)		x,## __VA_ARGS__
 # define __ASM_FORM_RAW(x, ...)		x,## __VA_ARGS__
 # define __ASM_FORM_COMMA(x, ...)	x,## __VA_ARGS__,
@@ -113,7 +113,7 @@
 
 #endif
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #ifndef __pic__
 static __always_inline __pure void *rip_rel_ptr(void *p)
 {
@@ -144,7 +144,7 @@ static __always_inline __pure void *rip_rel_ptr(void *p)
 # include 
 
 /* Exception table entry */
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 
 # define _ASM_EXTABLE_TYPE(from, to, type)			\
 	.pushsection "__ex_table","a" ;				\
@@ -164,7 +164,7 @@ static __always_inline __pure void *rip_rel_ptr(void *p)
 #  define _ASM_NOKPROBE(entry)
 # endif
 
-#else /* ! __ASSEMBLY__ */
+#else /* ! __ASSEMBLER__ */
 
 # define DEFINE_EXTABLE_TYPE_REG \
 	".macro extable_type_reg type:req reg:req\n"						\
@@ -221,7 +221,7 @@ static __always_inline __pure void *rip_rel_ptr(void *p)
  */
 register unsigned long current_stack_pointer asm(_ASM_SP);
 #define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #define _ASM_EXTABLE(from, to)					\
 	_ASM_EXTABLE_TYPE(from, to, EX_TYPE_DEFAULT)
diff --git a/arch/x86/include/asm/boot.h b/arch/x86/include/asm/boot.h
index 3e5b111e619d4..3f02ff6d333d3 100644
--- a/arch/x86/include/asm/boot.h
+++ b/arch/x86/include/asm/boot.h
@@ -74,7 +74,7 @@
 # define BOOT_STACK_SIZE	0x1000
 #endif
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 extern unsigned int output_len;
 extern const unsigned long kernel_text_size;
 extern const unsigned long kernel_total_size;
diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index de1ad09fe8d72..7e67bacf02f37 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -4,7 +4,7 @@
 
 #include 
 
-#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
+#if defined(__KERNEL__) && !defined(__ASSEMBLER__)
 
 #include 
 #include 
@@ -208,5 +208,5 @@ static __always_inline bool _static_cpu_has(u16 bit)
 #define CPU_FEATURE_TYPEVAL		boot_cpu_data.x86_vendor, boot_cpu_data.x86, \
 					boot_cpu_data.x86_model
 
-#endif /* defined(__KERNEL__) && !defined(__ASSEMBLY__) */
+#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) */
 #endif /* _ASM_X86_CPUFEATURE_H */
diff --git a/arch/x86/include/asm/cpumask.h b/arch/x86/include/asm/cpumask.h
index 4acfd57de8f1c..70f6b60ad67b9 100644
--- a/arch/x86/include/asm/cpumask.h
+++ b/arch/x86/include/asm/cpumask.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 #ifndef _ASM_X86_CPUMASK_H
 #define _ASM_X86_CPUMASK_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 extern void setup_cpu_local_masks(void);
@@ -34,5 +34,5 @@ static __always_inline void arch_cpumask_clear_cpu(int cpu, struct cpumask *dstp
 
 #define arch_cpu_is_offline(cpu)	unlikely(!arch_cpu_online(cpu))
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #endif /* _ASM_X86_CPUMASK_H */
diff --git a/arch/x86/include/asm/current.h b/arch/x86/include/asm/current.h
index bf5953883ec36..f2d0b38879808 100644
--- a/arch/x86/include/asm/current.h
+++ b/arch/x86/include/asm/current.h
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 #include 
@@ -51,6 +51,6 @@ static __always_inline struct task_struct *get_current(void)
 
 #define current get_current()
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ASM_X86_CURRENT_H */
diff --git a/arch/x86/include/asm/desc_defs.h b/arch/x86/include/asm/desc_defs.h
index d440a65af8f39..7e6b9314758a1 100644
--- a/arch/x86/include/asm/desc_defs.h
+++ b/arch/x86/include/asm/desc_defs.h
@@ -58,7 +58,7 @@
 
 #define DESC_USER		(_DESC_DPL(3))
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 
@@ -166,7 +166,7 @@ struct desc_ptr {
 	unsigned long address;
 } __attribute__((packed)) ;
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 /* Boot IDT definitions */
 #define	BOOT_IDT_ENTRIES	32
diff --git a/arch/x86/include/asm/dwarf2.h b/arch/x86/include/asm/dwarf2.h
index 430fca13bb568..302e11b15da86 100644
--- a/arch/x86/include/asm/dwarf2.h
+++ b/arch/x86/include/asm/dwarf2.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_DWARF2_H
 #define _ASM_X86_DWARF2_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #warning "asm/dwarf2.h should be only included in pure assembly files"
 #endif
 
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index d0dcefb5cc59d..4519c9f35ba04 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -31,7 +31,7 @@
 /* fixmap starts downwards from the 507th entry in level2_fixmap_pgt */
 #define FIXMAP_PMD_TOP	507
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 #include 
 #include 
@@ -196,5 +196,5 @@ void __init *early_memremap_decrypted_wp(resource_size_t phys_addr,
 void __early_set_fixmap(enum fixed_addresses idx,
 			phys_addr_t phys, pgprot_t flags);
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 #endif /* _ASM_X86_FIXMAP_H */
diff --git a/arch/x86/include/asm/frame.h b/arch/x86/include/asm/frame.h
index fb42659f6e988..0ab65073c1cc0 100644
--- a/arch/x86/include/asm/frame.h
+++ b/arch/x86/include/asm/frame.h
@@ -11,7 +11,7 @@
 
 #ifdef CONFIG_FRAME_POINTER
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 
 .macro FRAME_BEGIN
 	push %_ASM_BP
@@ -51,7 +51,7 @@
 .endm
 #endif /* CONFIG_X86_64 */
 
-#else /* !__ASSEMBLY__ */
+#else /* !__ASSEMBLER__ */
 
 #define FRAME_BEGIN				\
 	"push %" _ASM_BP "\n"			\
@@ -82,18 +82,18 @@ static inline unsigned long encode_frame_pointer(struct pt_regs *regs)
 
 #endif /* CONFIG_X86_64 */
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #define FRAME_OFFSET __ASM_SEL(4, 8)
 
 #else /* !CONFIG_FRAME_POINTER */
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 
 .macro ENCODE_FRAME_POINTER ptregs_offset=0
 .endm
 
-#else /* !__ASSEMBLY */
+#else /* !__ASSEMBLER__ */
 
 #define ENCODE_FRAME_POINTER
 
diff --git a/arch/x86/include/asm/fred.h b/arch/x86/include/asm/fred.h
index 25ca00bd70e83..2a29e52168815 100644
--- a/arch/x86/include/asm/fred.h
+++ b/arch/x86/include/asm/fred.h
@@ -32,7 +32,7 @@
 #define FRED_CONFIG_INT_STKLVL(l)	(_AT(unsigned long, l) << 9)
 #define FRED_CONFIG_ENTRYPOINT(p)	_AT(unsigned long, (p))
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #ifdef CONFIG_X86_FRED
 #include 
@@ -113,6 +113,6 @@ static inline void fred_entry_from_kvm(unsigned int type, unsigned int vector) {
 static inline void fred_sync_rsp0(unsigned long rsp0) { }
 static inline void fred_update_rsp0(void) { }
 #endif /* CONFIG_X86_FRED */
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 #endif /* ASM_X86_FRED_H */
diff --git a/arch/x86/include/asm/fsgsbase.h b/arch/x86/include/asm/fsgsbase.h
index 9e7e8ca8e2997..02f239569b93d 100644
--- a/arch/x86/include/asm/fsgsbase.h
+++ b/arch/x86/include/asm/fsgsbase.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_FSGSBASE_H
 #define _ASM_FSGSBASE_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #ifdef CONFIG_X86_64
 
@@ -80,6 +80,6 @@ extern unsigned long x86_fsgsbase_read_task(struct task_struct *task,
 
 #endif /* CONFIG_X86_64 */
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ASM_FSGSBASE_H */
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index f9cb4d07df58f..2d02d5b0517c1 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -22,7 +22,7 @@
 #define ARCH_SUPPORTS_FTRACE_OPS 1
 #endif
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 extern void __fentry__(void);
 
 static inline unsigned long ftrace_call_adjust(unsigned long addr)
@@ -118,11 +118,11 @@ struct dyn_arch_ftrace {
 };
 
 #endif /*  CONFIG_DYNAMIC_FTRACE */
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #endif /* CONFIG_FUNCTION_TRACER */
 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 void prepare_ftrace_return(unsigned long ip, unsigned long *parent,
 			   unsigned long frame_pointer);
@@ -166,6 +166,6 @@ static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
 }
 #endif /* CONFIG_FTRACE_SYSCALLS && CONFIG_IA32_EMULATION */
 #endif /* !COMPILE_OFFSETS */
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 #endif /* _ASM_X86_FTRACE_H */
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index edebf1020e049..162ebd73a6981 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -16,7 +16,7 @@
 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 #include 
@@ -128,6 +128,6 @@ extern char spurious_entries_start[];
 typedef struct irq_desc* vector_irq_t[NR_VECTORS];
 DECLARE_PER_CPU(vector_irq_t, vector_irq);
 
-#endif /* !ASSEMBLY_ */
+#endif /* !__ASSEMBLER__ */
 
 #endif /* _ASM_X86_HW_IRQ_H */
diff --git a/arch/x86/include/asm/ibt.h b/arch/x86/include/asm/ibt.h
index 1e59581d500ca..e7f4caa42839a 100644
--- a/arch/x86/include/asm/ibt.h
+++ b/arch/x86/include/asm/ibt.h
@@ -21,7 +21,7 @@
 
 #define HAS_KERNEL_IBT	1
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #ifdef CONFIG_X86_64
 #define ASM_ENDBR	"endbr64\n\t"
@@ -77,7 +77,7 @@ static inline bool is_endbr(u32 val)
 extern __noendbr u64 ibt_save(bool disable);
 extern __noendbr void ibt_restore(u64 save);
 
-#else /* __ASSEMBLY__ */
+#else /* __ASSEMBLER__ */
 
 #ifdef CONFIG_X86_64
 #define ENDBR	endbr64
@@ -85,13 +85,13 @@ extern __noendbr void ibt_restore(u64 save);
 #define ENDBR	endbr32
 #endif
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #else /* !IBT */
 
 #define HAS_KERNEL_IBT	0
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #define ASM_ENDBR
 #define IBT_NOSEAL(name)
@@ -103,11 +103,11 @@ static inline bool is_endbr(u32 val) { return false; }
 static inline u64 ibt_save(bool disable) { return 0; }
 static inline void ibt_restore(u64 save) { }
 
-#else /* __ASSEMBLY__ */
+#else /* __ASSEMBLER__ */
 
 #define ENDBR
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* CONFIG_X86_KERNEL_IBT */
 
diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
index ad5c68f0509d4..a4ec27c679887 100644
--- a/arch/x86/include/asm/idtentry.h
+++ b/arch/x86/include/asm/idtentry.h
@@ -7,7 +7,7 @@
 
 #define IDT_ALIGN	(8 * (1 + HAS_KERNEL_IBT))
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 #include 
 
@@ -474,7 +474,7 @@ static inline void fred_install_sysvec(unsigned int vector, const idtentry_t fun
 		idt_install_sysvec(vector, asm_##function);		\
 }
 
-#else /* !__ASSEMBLY__ */
+#else /* !__ASSEMBLER__ */
 
 /*
  * The ASM variants for DECLARE_IDTENTRY*() which emit the ASM entry stubs.
@@ -579,7 +579,7 @@ SYM_CODE_START(spurious_entries_start)
 SYM_CODE_END(spurious_entries_start)
 #endif
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 /*
  * The actual entry points. Note that DECLARE_IDTENTRY*() serves two
diff --git a/arch/x86/include/asm/inst.h b/arch/x86/include/asm/inst.h
index 438ccd4f3cc45..e48a00b3311d5 100644
--- a/arch/x86/include/asm/inst.h
+++ b/arch/x86/include/asm/inst.h
@@ -6,7 +6,7 @@
 #ifndef X86_ASM_INST_H
 #define X86_ASM_INST_H
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 
 #define REG_NUM_INVALID		100
 
diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index 1c2db11a2c3cb..9a9b21b78905a 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -4,7 +4,7 @@
 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 
@@ -101,7 +101,7 @@ static __always_inline void halt(void)
 #ifdef CONFIG_PARAVIRT_XXL
 #include 
 #else
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 static __always_inline unsigned long arch_local_save_flags(void)
@@ -137,10 +137,10 @@ static __always_inline unsigned long arch_local_irq_save(void)
 
 #endif
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #endif /* CONFIG_PARAVIRT_XXL */
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 static __always_inline int arch_irqs_disabled_flags(unsigned long flags)
 {
 	return !(flags & X86_EFLAGS_IF);
@@ -158,6 +158,6 @@ static __always_inline void arch_local_irq_restore(unsigned long flags)
 	if (!arch_irqs_disabled_flags(flags))
 		arch_local_irq_enable();
 }
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 #endif
diff --git a/arch/x86/include/asm/jump_label.h b/arch/x86/include/asm/jump_label.h
index 3f1c1d6c0da12..61dd1dee7812e 100644
--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -7,7 +7,7 @@
 #include 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 #include 
@@ -55,6 +55,6 @@ static __always_inline bool arch_static_branch_jump(struct static_key * const ke
 
 extern int arch_jump_entry_size(struct jump_entry *entry);
 
-#endif	/* __ASSEMBLY__ */
+#endif	/* __ASSEMBLER__ */
 
 #endif
diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
index de75306b932ef..d7e33c7f096b0 100644
--- a/arch/x86/include/asm/kasan.h
+++ b/arch/x86/include/asm/kasan.h
@@ -23,7 +23,7 @@
 					(1ULL << (__VIRTUAL_MASK_SHIFT - \
 						  KASAN_SHADOW_SCALE_SHIFT)))
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #ifdef CONFIG_KASAN
 void __init kasan_early_init(void);
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 8ad187462b68e..c75509241ff28 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -13,7 +13,7 @@
 # define KEXEC_CONTROL_PAGE_SIZE	4096
 # define KEXEC_CONTROL_CODE_MAX_SIZE	2048
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 #include 
@@ -225,6 +225,6 @@ unsigned int arch_crash_get_elfcorehdr_size(void);
 #define crash_get_elfcorehdr_size arch_crash_get_elfcorehdr_size
 #endif
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ASM_X86_KEXEC_H */
diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
index dc31b13b87a0d..c95dad65801d5 100644
--- a/arch/x86/include/asm/linkage.h
+++ b/arch/x86/include/asm/linkage.h
@@ -38,7 +38,7 @@
 #define ASM_FUNC_ALIGN		__stringify(__FUNC_ALIGN)
 #define SYM_F_ALIGN		__FUNC_ALIGN
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 
 #if defined(CONFIG_MITIGATION_RETHUNK) && !defined(__DISABLE_EXPORTS) && !defined(BUILD_VDSO)
 #define RET	jmp __x86_return_thunk
@@ -50,7 +50,7 @@
 #endif
 #endif /* CONFIG_MITIGATION_RETPOLINE */
 
-#else /* __ASSEMBLY__ */
+#else /* __ASSEMBLER__ */
 
 #if defined(CONFIG_MITIGATION_RETHUNK) && !defined(__DISABLE_EXPORTS) && !defined(BUILD_VDSO)
 #define ASM_RET	"jmp __x86_return_thunk\n\t"
@@ -62,7 +62,7 @@
 #endif
 #endif /* CONFIG_MITIGATION_RETPOLINE */
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 /*
  * Depending on -fpatchable-function-entry=N,N usage (CONFIG_CALL_PADDING) the
diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h
index f922b682b9b4c..1530ee301dfea 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -10,7 +10,7 @@
 #ifndef __X86_MEM_ENCRYPT_H__
 #define __X86_MEM_ENCRYPT_H__
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 #include 
@@ -114,6 +114,6 @@ void add_encrypt_protection_map(void);
 
 extern char __start_bss_decrypted[], __end_bss_decrypted[], __start_bss_decrypted_unused[];
 
-#endif	/* __ASSEMBLY__ */
+#endif	/* __ASSEMBLER__ */
 
 #endif	/* __X86_MEM_ENCRYPT_H__ */
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 001853541f1e8..9397a319d165d 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -4,7 +4,7 @@
 
 #include "msr-index.h"
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 #include 
@@ -397,5 +397,5 @@ static inline int wrmsr_safe_regs_on_cpu(unsigned int cpu, u32 regs[8])
 	return wrmsr_safe_regs(regs);
 }
 #endif  /* CONFIG_SMP */
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #endif /* _ASM_X86_MSR_H */
diff --git a/arch/x86/include/asm/nops.h b/arch/x86/include/asm/nops.h
index 1c1b7550fa550..cd94221d83358 100644
--- a/arch/x86/include/asm/nops.h
+++ b/arch/x86/include/asm/nops.h
@@ -82,7 +82,7 @@
 #define ASM_NOP7 _ASM_BYTES(BYTES_NOP7)
 #define ASM_NOP8 _ASM_BYTES(BYTES_NOP8)
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 extern const unsigned char * const x86_nops[];
 #endif
 
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index aee26bb8230f8..1dbc40080448d 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -177,7 +177,7 @@
 	add	$(BITS_PER_LONG/8), %_ASM_SP;		\
 	lfence;
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 
 /*
  * (ab)use RETPOLINE_SAFE on RET to annotate away 'bare' RET instructions
@@ -335,7 +335,7 @@
 #define CLEAR_BRANCH_HISTORY_VMEXIT
 #endif
 
-#else /* __ASSEMBLY__ */
+#else /* __ASSEMBLER__ */
 
 typedef u8 retpoline_thunk_t[RETPOLINE_THUNK_SIZE];
 extern retpoline_thunk_t __x86_indirect_thunk_array[];
@@ -602,6 +602,6 @@ static __always_inline void mds_idle_clear_cpu_buffers(void)
 		mds_clear_cpu_buffers();
 }
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ASM_X86_NOSPEC_BRANCH_H_ */
diff --git a/arch/x86/include/asm/orc_types.h b/arch/x86/include/asm/orc_types.h
index 46d7e06763c9f..e0125afa53fb9 100644
--- a/arch/x86/include/asm/orc_types.h
+++ b/arch/x86/include/asm/orc_types.h
@@ -45,7 +45,7 @@
 #define ORC_TYPE_REGS			3
 #define ORC_TYPE_REGS_PARTIAL		4
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 /*
@@ -73,6 +73,6 @@ struct orc_entry {
 #endif
 } __packed;
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ORC_TYPES_H */
diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h
index c9fe207916f48..9265f2fca99ae 100644
--- a/arch/x86/include/asm/page.h
+++ b/arch/x86/include/asm/page.h
@@ -14,7 +14,7 @@
 #include 
 #endif	/* CONFIG_X86_64 */
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 struct page;
 
@@ -84,7 +84,7 @@ static __always_inline u64 __is_canonical_address(u64 vaddr, u8 vaddr_bits)
 	return __canonical_address(vaddr, vaddr_bits) == vaddr;
 }
 
-#endif	/* __ASSEMBLY__ */
+#endif	/* __ASSEMBLER__ */
 
 #include 
 #include 
diff --git a/arch/x86/include/asm/page_32.h b/arch/x86/include/asm/page_32.h
index 580d71aca65a4..0c623706cb7ef 100644
--- a/arch/x86/include/asm/page_32.h
+++ b/arch/x86/include/asm/page_32.h
@@ -4,7 +4,7 @@
 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #define __phys_addr_nodebug(x)	((x) - PAGE_OFFSET)
 #ifdef CONFIG_DEBUG_VIRTUAL
@@ -26,6 +26,6 @@ static inline void copy_page(void *to, void *from)
 {
 	memcpy(to, from, PAGE_SIZE);
 }
-#endif	/* !__ASSEMBLY__ */
+#endif	/* !__ASSEMBLER__ */
 
 #endif /* _ASM_X86_PAGE_32_H */
diff --git a/arch/x86/include/asm/page_32_types.h b/arch/x86/include/asm/page_32_types.h
index faf9cc1c14bb6..88e3c8d582986 100644
--- a/arch/x86/include/asm/page_32_types.h
+++ b/arch/x86/include/asm/page_32_types.h
@@ -63,7 +63,7 @@
  */
 #define KERNEL_IMAGE_SIZE	(512 * 1024 * 1024)
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 /*
  * This much address space is reserved for vmalloc() and iomap()
@@ -75,6 +75,6 @@ extern int sysctl_legacy_va_layout;
 extern void find_low_pfn_range(void);
 extern void setup_bootmem_allocator(void);
 
-#endif	/* !__ASSEMBLY__ */
+#endif	/* !__ASSEMBLER__ */
 
 #endif /* _ASM_X86_PAGE_32_DEFS_H */
diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h
index d63576608ce76..442357defa117 100644
--- a/arch/x86/include/asm/page_64.h
+++ b/arch/x86/include/asm/page_64.h
@@ -4,7 +4,7 @@
 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 #include 
 
@@ -94,7 +94,7 @@ static __always_inline unsigned long task_size_max(void)
 }
 #endif	/* CONFIG_X86_5LEVEL */
 
-#endif	/* !__ASSEMBLY__ */
+#endif	/* !__ASSEMBLER__ */
 
 #ifdef CONFIG_X86_VSYSCALL_EMULATION
 # define __HAVE_ARCH_GATE_AREA 1
diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 06ef25411d622..1faa8f88850ab 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_PAGE_64_DEFS_H
 #define _ASM_X86_PAGE_64_DEFS_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 #endif
 
diff --git a/arch/x86/include/asm/page_types.h b/arch/x86/include/asm/page_types.h
index 974688973cf6e..9f77bf03d7472 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -43,7 +43,7 @@
 #define IOREMAP_MAX_ORDER       (PMD_SHIFT)
 #endif	/* CONFIG_X86_64 */
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #ifdef CONFIG_DYNAMIC_PHYSICAL_MASK
 extern phys_addr_t physical_mask;
@@ -66,6 +66,6 @@ bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn);
 
 extern void initmem_init(void);
 
-#endif	/* !__ASSEMBLY__ */
+#endif	/* !__ASSEMBLER__ */
 
 #endif	/* _ASM_X86_PAGE_DEFS_H */
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 29e7331a0c98d..0ace044d6f2cd 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -6,7 +6,7 @@
 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 struct mm_struct;
 #endif
 
@@ -15,7 +15,7 @@ struct mm_struct;
 #include 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 #include 
 #include 
@@ -720,7 +720,7 @@ static __always_inline unsigned long arch_local_irq_save(void)
 extern void default_banner(void);
 void native_pv_lock_init(void) __init;
 
-#else  /* __ASSEMBLY__ */
+#else  /* __ASSEMBLER__ */
 
 #ifdef CONFIG_X86_64
 #ifdef CONFIG_PARAVIRT_XXL
@@ -740,18 +740,18 @@ void native_pv_lock_init(void) __init;
 #endif /* CONFIG_PARAVIRT_XXL */
 #endif	/* CONFIG_X86_64 */
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #else  /* CONFIG_PARAVIRT */
 # define default_banner x86_init_noop
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 static inline void native_pv_lock_init(void)
 {
 }
 #endif
 #endif /* !CONFIG_PARAVIRT */
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #ifndef CONFIG_PARAVIRT_XXL
 static inline void paravirt_enter_mmap(struct mm_struct *mm)
 {
@@ -769,5 +769,5 @@ static inline void paravirt_set_cap(void)
 {
 }
 #endif
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #endif /* _ASM_X86_PARAVIRT_H */
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index abccfccc2e3fa..1fca6281988a9 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -4,7 +4,7 @@
 
 #ifdef CONFIG_PARAVIRT
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 #include 
@@ -518,7 +518,7 @@ unsigned long pv_native_read_cr2(void);
 
 #define paravirt_nop	((void *)nop_func)
 
-#endif	/* __ASSEMBLY__ */
+#endif	/* __ASSEMBLER__ */
 
 #define ALT_NOT_XEN	ALT_NOT(X86_FEATURE_XENPV)
 
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index e525cd85f999f..afb9099fba9fc 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -10,7 +10,7 @@
 # define __percpu_rel
 #endif
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 
 #ifdef CONFIG_SMP
 # define __percpu		%__percpu_seg:
@@ -619,7 +619,7 @@ do {									\
 /* We can use this directly for local CPU (faster). */
 DECLARE_PER_CPU_READ_MOSTLY(unsigned long, this_cpu_off);
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 #ifdef CONFIG_SMP
 
diff --git a/arch/x86/include/asm/pgtable-2level_types.h b/arch/x86/include/asm/pgtable-2level_types.h
index 4a12c276b1812..66425424ce91a 100644
--- a/arch/x86/include/asm/pgtable-2level_types.h
+++ b/arch/x86/include/asm/pgtable-2level_types.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_PGTABLE_2LEVEL_DEFS_H
 #define _ASM_X86_PGTABLE_2LEVEL_DEFS_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 typedef unsigned long	pteval_t;
@@ -16,7 +16,7 @@ typedef union {
 	pteval_t pte;
 	pteval_t pte_low;
 } pte_t;
-#endif	/* !__ASSEMBLY__ */
+#endif	/* !__ASSEMBLER__ */
 
 #define SHARED_KERNEL_PMD	0
 
diff --git a/arch/x86/include/asm/pgtable-3level_types.h b/arch/x86/include/asm/pgtable-3level_types.h
index 80911349519e8..9d5b257d44e3c 100644
--- a/arch/x86/include/asm/pgtable-3level_types.h
+++ b/arch/x86/include/asm/pgtable-3level_types.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_PGTABLE_3LEVEL_DEFS_H
 #define _ASM_X86_PGTABLE_3LEVEL_DEFS_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 typedef u64	pteval_t;
@@ -25,7 +25,7 @@ typedef union {
 	};
 	pmdval_t pmd;
 } pmd_t;
-#endif	/* !__ASSEMBLY__ */
+#endif	/* !__ASSEMBLER__ */
 
 #define SHARED_KERNEL_PMD	(!static_cpu_has(X86_FEATURE_PTI))
 
diff --git a/arch/x86/include/asm/pgtable-invert.h b/arch/x86/include/asm/pgtable-invert.h
index a0c1525f1b6f4..e12e52ae8083d 100644
--- a/arch/x86/include/asm/pgtable-invert.h
+++ b/arch/x86/include/asm/pgtable-invert.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_PGTABLE_INVERT_H
 #define _ASM_PGTABLE_INVERT_H 1
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 /*
  * A clear pte value is special, and doesn't get inverted.
@@ -36,6 +36,6 @@ static inline u64 flip_protnone_guard(u64 oldval, u64 val, u64 mask)
 	return val;
 }
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 593f10aabd45a..7bd6bd6df4a11 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -15,7 +15,7 @@
 		     cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS)))	\
 	 : (prot))
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 #include 
 #include 
@@ -973,7 +973,7 @@ static inline pgd_t pti_set_user_pgtbl(pgd_t *pgdp, pgd_t pgd)
 }
 #endif  /* CONFIG_MITIGATION_PAGE_TABLE_ISOLATION */
 
-#endif	/* __ASSEMBLY__ */
+#endif	/* __ASSEMBLER__ */
 
 
 #ifdef CONFIG_X86_32
@@ -982,7 +982,7 @@ static inline pgd_t pti_set_user_pgtbl(pgd_t *pgdp, pgd_t pgd)
 # include 
 #endif
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 #include 
 #include 
@@ -1233,12 +1233,12 @@ static inline int pgd_none(pgd_t pgd)
 }
 #endif	/* CONFIG_PGTABLE_LEVELS > 4 */
 
-#endif	/* __ASSEMBLY__ */
+#endif	/* __ASSEMBLER__ */
 
 #define KERNEL_PGD_BOUNDARY	pgd_index(PAGE_OFFSET)
 #define KERNEL_PGD_PTRS		(PTRS_PER_PGD - KERNEL_PGD_BOUNDARY)
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 extern int direct_gbpages;
 void init_mem_mapping(void);
@@ -1812,6 +1812,6 @@ bool arch_is_platform_page(u64 paddr);
 	WARN_ON_ONCE(pgd_present(*pgdp) && !pgd_same(*pgdp, pgd)); \
 	set_pgd(pgdp, pgd); \
 })
-#endif	/* __ASSEMBLY__ */
+#endif	/* __ASSEMBLER__ */
 
 #endif /* _ASM_X86_PGTABLE_H */
diff --git a/arch/x86/include/asm/pgtable_32.h b/arch/x86/include/asm/pgtable_32.h
index 7d4ad8907297c..b612cc57a4d34 100644
--- a/arch/x86/include/asm/pgtable_32.h
+++ b/arch/x86/include/asm/pgtable_32.h
@@ -13,7 +13,7 @@
  * This file contains the functions and defines necessary to modify and use
  * the i386 page table tree.
  */
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 #include 
 #include 
@@ -45,7 +45,7 @@ do {						\
 	flush_tlb_one_kernel((vaddr));		\
 } while (0)
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 /*
  * This is used to calculate the .brk reservation for initial pagetables.
diff --git a/arch/x86/include/asm/pgtable_32_areas.h b/arch/x86/include/asm/pgtable_32_areas.h
index b6355416a15a8..921148b429676 100644
--- a/arch/x86/include/asm/pgtable_32_areas.h
+++ b/arch/x86/include/asm/pgtable_32_areas.h
@@ -13,7 +13,7 @@
  */
 #define VMALLOC_OFFSET	(8 * 1024 * 1024)
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 extern bool __vmalloc_start_set; /* set once high_memory is set */
 #endif
 
diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
index d1426b64c1b97..b89f8f1194a9f 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 /*
  * This file contains the functions and defines necessary to modify and use
@@ -270,7 +270,7 @@ static inline bool gup_fast_permitted(unsigned long start, unsigned long end)
 
 #include 
 
-#else /* __ASSEMBLY__ */
+#else /* __ASSEMBLER__ */
 
 #define l4_index(x)	(((x) >> 39) & 511)
 #define pud_index(x)	(((x) >> PUD_SHIFT) & (PTRS_PER_PUD - 1))
@@ -291,5 +291,5 @@ L3_START_KERNEL = pud_index(__START_KERNEL_map)
 	i = i + 1 ;					\
 	.endr
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #endif /* _ASM_X86_PGTABLE_64_H */
diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index ec68f8369bdca..5bb782d856f2c 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -4,7 +4,7 @@
 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 #include 
 
@@ -44,7 +44,7 @@ static inline bool pgtable_l5_enabled(void)
 extern unsigned int pgdir_shift;
 extern unsigned int ptrs_per_p4d;
 
-#endif	/* !__ASSEMBLY__ */
+#endif	/* !__ASSEMBLER__ */
 
 #define SHARED_KERNEL_PMD	0
 
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 4b804531b03c3..ded7075c60634 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -164,7 +164,7 @@
  * to have the WB mode at index 0 (all bits clear). This is the default
  * right now and likely would break too much if changed.
  */
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 enum page_cache_mode {
 	_PAGE_CACHE_MODE_WB       = 0,
 	_PAGE_CACHE_MODE_WC       = 1,
@@ -239,7 +239,7 @@ enum page_cache_mode {
 #define __PAGE_KERNEL_IO_NOCACHE	__PAGE_KERNEL_NOCACHE
 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #define __PAGE_KERNEL_ENC	(__PAGE_KERNEL    | _ENC)
 #define __PAGE_KERNEL_ENC_WP	(__PAGE_KERNEL_WP | _ENC)
@@ -262,7 +262,7 @@ enum page_cache_mode {
 #define PAGE_KERNEL_IO		__pgprot_mask(__PAGE_KERNEL_IO)
 #define PAGE_KERNEL_IO_NOCACHE	__pgprot_mask(__PAGE_KERNEL_IO_NOCACHE)
 
-#endif	/* __ASSEMBLY__ */
+#endif	/* __ASSEMBLER__ */
 
 /*
  * early identity mapping  pte attrib macros.
@@ -281,7 +281,7 @@ enum page_cache_mode {
 # include 
 #endif
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 
@@ -580,6 +580,6 @@ extern int __init kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn,
 					  unsigned long page_flags);
 extern int __init kernel_unmap_pages_in_pgd(pgd_t *pgd, unsigned long address,
 					    unsigned long numpages);
-#endif	/* !__ASSEMBLY__ */
+#endif	/* !__ASSEMBLER__ */
 
 #endif /* _ASM_X86_PGTABLE_DEFS_H */
diff --git a/arch/x86/include/asm/prom.h b/arch/x86/include/asm/prom.h
index 365798cb4408d..5d0dbab852640 100644
--- a/arch/x86/include/asm/prom.h
+++ b/arch/x86/include/asm/prom.h
@@ -8,7 +8,7 @@
 
 #ifndef _ASM_X86_PROM_H
 #define _ASM_X86_PROM_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 #include 
@@ -33,5 +33,5 @@ static inline void x86_flattree_get_config(void) { }
 
 extern char cmd_line[COMMAND_LINE_SIZE];
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #endif
diff --git a/arch/x86/include/asm/pti.h b/arch/x86/include/asm/pti.h
index ab167c96b9ab4..88d0a1ab1f77e 100644
--- a/arch/x86/include/asm/pti.h
+++ b/arch/x86/include/asm/pti.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 #ifndef _ASM_X86_PTI_H
 #define _ASM_X86_PTI_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #ifdef CONFIG_MITIGATION_PAGE_TABLE_ISOLATION
 extern void pti_init(void);
@@ -11,5 +11,5 @@ extern void pti_finalize(void);
 static inline void pti_check_boottime_disable(void) { }
 #endif
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #endif /* _ASM_X86_PTI_H */
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 5a83fbd9bc0b4..50f75467f73d0 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -6,7 +6,7 @@
 #include 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #ifdef __i386__
 
 struct pt_regs {
@@ -469,5 +469,5 @@ extern int do_set_thread_area(struct task_struct *p, int idx,
 # define do_set_thread_area_64(p, s, t)	(0)
 #endif
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 #endif /* _ASM_X86_PTRACE_H */
diff --git a/arch/x86/include/asm/purgatory.h b/arch/x86/include/asm/purgatory.h
index 5528e93250494..2fee5e9f1ccc3 100644
--- a/arch/x86/include/asm/purgatory.h
+++ b/arch/x86/include/asm/purgatory.h
@@ -2,10 +2,10 @@
 #ifndef _ASM_X86_PURGATORY_H
 #define _ASM_X86_PURGATORY_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 extern void purgatory(void);
-#endif	/* __ASSEMBLY__ */
+#endif	/* __ASSEMBLER__ */
 
 #endif /* _ASM_PURGATORY_H */
diff --git a/arch/x86/include/asm/pvclock-abi.h b/arch/x86/include/asm/pvclock-abi.h
index 1436226efe3ef..b9fece5fc96d6 100644
--- a/arch/x86/include/asm/pvclock-abi.h
+++ b/arch/x86/include/asm/pvclock-abi.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 #ifndef _ASM_X86_PVCLOCK_ABI_H
 #define _ASM_X86_PVCLOCK_ABI_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 /*
  * These structs MUST NOT be changed.
@@ -44,5 +44,5 @@ struct pvclock_wall_clock {
 #define PVCLOCK_GUEST_STOPPED	(1 << 1)
 /* PVCLOCK_COUNTS_FROM_ZERO broke ABI and can't be used anymore. */
 #define PVCLOCK_COUNTS_FROM_ZERO (1 << 2)
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #endif /* _ASM_X86_PVCLOCK_ABI_H */
diff --git a/arch/x86/include/asm/realmode.h b/arch/x86/include/asm/realmode.h
index 87e5482acd0dc..f607081a022ab 100644
--- a/arch/x86/include/asm/realmode.h
+++ b/arch/x86/include/asm/realmode.h
@@ -9,7 +9,7 @@
 #define TH_FLAGS_SME_ACTIVE_BIT		0
 #define TH_FLAGS_SME_ACTIVE		BIT(TH_FLAGS_SME_ACTIVE_BIT)
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 #include 
@@ -95,6 +95,6 @@ void reserve_real_mode(void);
 void load_trampoline_pgtable(void);
 void init_real_mode(void);
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ARCH_X86_REALMODE_H */
diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h
index 9d6411c659205..77d8f49b92bdd 100644
--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -233,7 +233,7 @@
 #define VDSO_CPUNODE_BITS		12
 #define VDSO_CPUNODE_MASK		0xfff
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 /* Helper functions to store/load CPU and node numbers */
 
@@ -265,7 +265,7 @@ static inline void vdso_read_cpunode(unsigned *cpu, unsigned *node)
 		*node = (p >> VDSO_CPUNODE_BITS);
 }
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 #ifdef __KERNEL__
 
@@ -286,7 +286,7 @@ static inline void vdso_read_cpunode(unsigned *cpu, unsigned *node)
  */
 #define XEN_EARLY_IDT_HANDLER_SIZE (8 + ENDBR_INSN_SIZE)
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 extern const char early_idt_handler_array[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_SIZE];
 extern void early_ignore_irq(void);
@@ -350,7 +350,7 @@ static inline void __loadsegment_fs(unsigned short value)
 #define savesegment(seg, value)				\
 	asm("mov %%" #seg ",%0":"=r" (value) : : "memory")
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 #endif /* __KERNEL__ */
 
 #endif /* _ASM_X86_SEGMENT_H */
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 85f4fde3515c4..09201d47c967b 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -27,7 +27,7 @@
 #define OLD_CL_ADDRESS		0x020	/* Relative to real mode data */
 #define NEW_CL_POINTER		0x228	/* Relative to real mode data */
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 #include 
@@ -141,7 +141,7 @@ extern bool builtin_cmdline_added __ro_after_init;
 #define builtin_cmdline_added 0
 #endif
 
-#else  /* __ASSEMBLY */
+#else  /* __ASSEMBLER__ */
 
 .macro __RESERVE_BRK name, size
 	.pushsection .bss..brk, "aw"
@@ -153,6 +153,6 @@ SYM_DATA_END(__brk_\name)
 
 #define RESERVE_BRK(name, size) __RESERVE_BRK name, size
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ASM_X86_SETUP_H */
diff --git a/arch/x86/include/asm/setup_data.h b/arch/x86/include/asm/setup_data.h
index 77c51111a8939..7bb16f843c93d 100644
--- a/arch/x86/include/asm/setup_data.h
+++ b/arch/x86/include/asm/setup_data.h
@@ -4,7 +4,7 @@
 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 struct pci_setup_rom {
 	struct setup_data data;
@@ -27,6 +27,6 @@ struct efi_setup_data {
 	u64 reserved[8];
 };
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ASM_X86_SETUP_DATA_H */
diff --git a/arch/x86/include/asm/shared/tdx.h b/arch/x86/include/asm/shared/tdx.h
index fcbbef484a78e..a28ff6b141458 100644
--- a/arch/x86/include/asm/shared/tdx.h
+++ b/arch/x86/include/asm/shared/tdx.h
@@ -106,7 +106,7 @@
 #define TDX_PS_1G	2
 #define TDX_PS_NR	(TDX_PS_1G + 1)
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 
@@ -177,5 +177,5 @@ static __always_inline u64 hcall_func(u64 exit_reason)
         return exit_reason;
 }
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 #endif /* _ASM_X86_SHARED_TDX_H */
diff --git a/arch/x86/include/asm/shstk.h b/arch/x86/include/asm/shstk.h
index 4cb77e004615d..ba6f2fe438488 100644
--- a/arch/x86/include/asm/shstk.h
+++ b/arch/x86/include/asm/shstk.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_SHSTK_H
 #define _ASM_X86_SHSTK_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 struct task_struct;
@@ -37,6 +37,6 @@ static inline int shstk_update_last_frame(unsigned long val) { return 0; }
 static inline bool shstk_is_enabled(void) { return false; }
 #endif /* CONFIG_X86_USER_SHADOW_STACK */
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ASM_X86_SHSTK_H */
diff --git a/arch/x86/include/asm/signal.h b/arch/x86/include/asm/signal.h
index 4a4043ca64934..c72d461753742 100644
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_SIGNAL_H
 #define _ASM_X86_SIGNAL_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 /* Most things should be clean enough to redefine this at will, if care
@@ -28,9 +28,9 @@ typedef struct {
 #define SA_IA32_ABI	0x02000000u
 #define SA_X32_ABI	0x01000000u
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #include 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #define __ARCH_HAS_SA_RESTORER
 
@@ -101,5 +101,5 @@ struct pt_regs;
 
 #endif /* !__i386__ */
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #endif /* _ASM_X86_SIGNAL_H */
diff --git a/arch/x86/include/asm/smap.h b/arch/x86/include/asm/smap.h
index 2de1e5a75c573..daea94c2993c5 100644
--- a/arch/x86/include/asm/smap.h
+++ b/arch/x86/include/asm/smap.h
@@ -13,7 +13,7 @@
 #include 
 #include 
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 
 #define ASM_CLAC \
 	ALTERNATIVE "", "clac", X86_FEATURE_SMAP
@@ -21,7 +21,7 @@
 #define ASM_STAC \
 	ALTERNATIVE "", "stac", X86_FEATURE_SMAP
 
-#else /* __ASSEMBLY__ */
+#else /* __ASSEMBLER__ */
 
 static __always_inline void clac(void)
 {
@@ -61,6 +61,6 @@ static __always_inline void smap_restore(unsigned long flags)
 #define ASM_STAC \
 	ALTERNATIVE("", "stac", X86_FEATURE_SMAP)
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ASM_X86_SMAP_H */
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index ca073f40698fa..d234a6321c189 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 #ifndef _ASM_X86_SMP_H
 #define _ASM_X86_SMP_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 #include 
@@ -175,7 +175,7 @@ extern void nmi_selftest(void);
 extern unsigned int smpboot_control;
 extern unsigned long apic_mmio_base;
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 /* Control bits for startup_64 */
 #define STARTUP_READ_APICID	0x80000000
diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
index 40f9a97371a90..4a1922ec80cf7 100644
--- a/arch/x86/include/asm/tdx.h
+++ b/arch/x86/include/asm/tdx.h
@@ -30,7 +30,7 @@
 #define TDX_SUCCESS		0ULL
 #define TDX_RND_NO_ENTROPY	0x8000020300000000ULL
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 
@@ -126,5 +126,5 @@ static inline int tdx_enable(void)  { return -ENODEV; }
 static inline const char *tdx_dump_mce_info(struct mce *m) { return NULL; }
 #endif	/* CONFIG_INTEL_TDX_HOST */
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 #endif /* _ASM_X86_TDX_H */
diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index a55c214f3ba64..9282465eea21d 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -54,7 +54,7 @@
  * - this struct should fit entirely inside of one cache line
  * - this struct shares the supervisor stack pages
  */
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 struct task_struct;
 #include 
 #include 
@@ -73,7 +73,7 @@ struct thread_info {
 	.flags		= 0,			\
 }
 
-#else /* !__ASSEMBLY__ */
+#else /* !__ASSEMBLER__ */
 
 #include 
 
@@ -161,7 +161,7 @@ struct thread_info {
  *
  * preempt_count needs to be 1 initially, until the scheduler is functional.
  */
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 /*
  * Walks up the stack frames to make sure that the specified object is
@@ -213,7 +213,7 @@ static inline int arch_within_stack_frames(const void * const stack,
 #endif
 }
 
-#endif  /* !__ASSEMBLY__ */
+#endif  /* !__ASSEMBLER__ */
 
 /*
  * Thread-synchronous status.
@@ -224,7 +224,7 @@ static inline int arch_within_stack_frames(const void * const stack,
  */
 #define TS_COMPAT		0x0002	/* 32bit syscall active (64BIT)*/
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #ifdef CONFIG_COMPAT
 #define TS_I386_REGS_POKED	0x0004	/* regs poked by 32-bit ptracer */
 
@@ -242,6 +242,6 @@ static inline int arch_within_stack_frames(const void * const stack,
 
 extern void arch_setup_new_exec(void);
 #define arch_setup_new_exec arch_setup_new_exec
-#endif	/* !__ASSEMBLY__ */
+#endif	/* !__ASSEMBLER__ */
 
 #endif /* _ASM_X86_THREAD_INFO_H */
diff --git a/arch/x86/include/asm/unwind_hints.h b/arch/x86/include/asm/unwind_hints.h
index 85cc57cb65392..8f4579c5a6f8b 100644
--- a/arch/x86/include/asm/unwind_hints.h
+++ b/arch/x86/include/asm/unwind_hints.h
@@ -5,7 +5,7 @@
 
 #include "orc_types.h"
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 
 .macro UNWIND_HINT_END_OF_STACK
 	UNWIND_HINT type=UNWIND_HINT_TYPE_END_OF_STACK
@@ -88,6 +88,6 @@
 #define UNWIND_HINT_RESTORE \
 	UNWIND_HINT(UNWIND_HINT_TYPE_RESTORE, 0, 0, 0)
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ASM_X86_UNWIND_HINTS_H */
diff --git a/arch/x86/include/asm/vdso/getrandom.h b/arch/x86/include/asm/vdso/getrandom.h
index 2bf9c0e970c3e..785f8edcb9c99 100644
--- a/arch/x86/include/asm/vdso/getrandom.h
+++ b/arch/x86/include/asm/vdso/getrandom.h
@@ -5,7 +5,7 @@
 #ifndef __ASM_VDSO_GETRANDOM_H
 #define __ASM_VDSO_GETRANDOM_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 
@@ -37,6 +37,6 @@ static __always_inline const struct vdso_rng_data *__arch_get_vdso_rng_data(void
 	return &vdso_rng_data;
 }
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 #endif /* __ASM_VDSO_GETRANDOM_H */
diff --git a/arch/x86/include/asm/vdso/gettimeofday.h b/arch/x86/include/asm/vdso/gettimeofday.h
index 375a34b0f3657..428f3f4c2235f 100644
--- a/arch/x86/include/asm/vdso/gettimeofday.h
+++ b/arch/x86/include/asm/vdso/gettimeofday.h
@@ -10,7 +10,7 @@
 #ifndef __ASM_VDSO_GETTIMEOFDAY_H
 #define __ASM_VDSO_GETTIMEOFDAY_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 #include 
@@ -350,6 +350,6 @@ static __always_inline u64 vdso_calc_ns(const struct vdso_data *vd, u64 cycles,
 }
 #define vdso_calc_ns vdso_calc_ns
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 #endif /* __ASM_VDSO_GETTIMEOFDAY_H */
diff --git a/arch/x86/include/asm/vdso/processor.h b/arch/x86/include/asm/vdso/processor.h
index 2cbce97d29eaf..c9b2ba7a9ec4c 100644
--- a/arch/x86/include/asm/vdso/processor.h
+++ b/arch/x86/include/asm/vdso/processor.h
@@ -5,7 +5,7 @@
 #ifndef __ASM_VDSO_PROCESSOR_H
 #define __ASM_VDSO_PROCESSOR_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 /* REP NOP (PAUSE) is a good thing to insert into busy-wait loops. */
 static __always_inline void rep_nop(void)
@@ -22,6 +22,6 @@ struct getcpu_cache;
 
 notrace long __vdso_getcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *unused);
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* __ASM_VDSO_PROCESSOR_H */
diff --git a/arch/x86/include/asm/vdso/vsyscall.h b/arch/x86/include/asm/vdso/vsyscall.h
index 88b31d4cdfaf3..6622e0103444e 100644
--- a/arch/x86/include/asm/vdso/vsyscall.h
+++ b/arch/x86/include/asm/vdso/vsyscall.h
@@ -10,7 +10,7 @@
 #define VDSO_PAGE_PVCLOCK_OFFSET	0
 #define VDSO_PAGE_HVCLOCK_OFFSET	1
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include 
 #include 
@@ -37,6 +37,6 @@ struct vdso_rng_data *__x86_get_k_vdso_rng_data(void)
 /* The asm-generic header needs to be included after the definitions above */
 #include 
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 #endif /* __ASM_VDSO_VSYSCALL_H */
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index baca0b00ef768..a078a2b0f032b 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -72,7 +72,7 @@
 #endif
 #endif
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 /* Explicitly size integers that represent pfns in the public interface
  * with Xen so that on ARM we can have one ABI that works for 32 and 64
  * bit guests. */
@@ -137,7 +137,7 @@ DEFINE_GUEST_HANDLE(xen_ulong_t);
 #define TI_SET_DPL(_ti, _dpl)	((_ti)->flags |= (_dpl))
 #define TI_SET_IF(_ti, _if)	((_ti)->flags |= ((!!(_if))<<2))
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 struct trap_info {
     uint8_t       vector;  /* exception vector                              */
     uint8_t       flags;   /* 0-3: privilege level; 4: clear event enable?  */
@@ -186,7 +186,7 @@ struct arch_shared_info {
 	uint32_t wc_sec_hi;
 #endif
 };
-#endif	/* !__ASSEMBLY__ */
+#endif	/* !__ASSEMBLER__ */
 
 #ifdef CONFIG_X86_32
 #include 
@@ -196,7 +196,7 @@ struct arch_shared_info {
 
 #include 
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 /*
  * The following is all CPU context. Note that the fpu_ctxt block is filled
  * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
@@ -376,7 +376,7 @@ struct xen_pmu_arch {
 	} c;
 };
 
-#endif	/* !__ASSEMBLY__ */
+#endif	/* !__ASSEMBLER__ */
 
 /*
  * Prefix forces emulation of some non-trapping instructions.
diff --git a/arch/x86/include/asm/xen/interface_32.h b/arch/x86/include/asm/xen/interface_32.h
index dc40578abded7..74d9768a9cf77 100644
--- a/arch/x86/include/asm/xen/interface_32.h
+++ b/arch/x86/include/asm/xen/interface_32.h
@@ -44,7 +44,7 @@
  */
 #define __HYPERVISOR_VIRT_START 0xF5800000
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 struct cpu_user_regs {
     uint32_t ebx;
@@ -85,7 +85,7 @@ typedef struct xen_callback xen_callback_t;
 
 #define XEN_CALLBACK(__cs, __eip)				\
 	((struct xen_callback){ .cs = (__cs), .eip = (unsigned long)(__eip) })
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 
 /*
diff --git a/arch/x86/include/asm/xen/interface_64.h b/arch/x86/include/asm/xen/interface_64.h
index c10f279aae936..38a19edb81a31 100644
--- a/arch/x86/include/asm/xen/interface_64.h
+++ b/arch/x86/include/asm/xen/interface_64.h
@@ -77,7 +77,7 @@
 #define VGCF_in_syscall  (1<<_VGCF_in_syscall)
 #define VGCF_IN_SYSCALL  VGCF_in_syscall
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 struct iret_context {
     /* Top of stack (%rsp at point of hypercall). */
@@ -143,7 +143,7 @@ typedef unsigned long xen_callback_t;
 #define XEN_CALLBACK(__cs, __rip)				\
 	((unsigned long)(__rip))
 
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
 
 
 #endif /* _ASM_X86_XEN_INTERFACE_64_H */
diff --git a/arch/x86/math-emu/control_w.h b/arch/x86/math-emu/control_w.h
index 60f4dcc5edc3c..93cbc89b34e25 100644
--- a/arch/x86/math-emu/control_w.h
+++ b/arch/x86/math-emu/control_w.h
@@ -11,7 +11,7 @@
 #ifndef _CONTROLW_H_
 #define _CONTROLW_H_
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 #define	_Const_(x)	$##x
 #else
 #define	_Const_(x)	x
diff --git a/arch/x86/math-emu/exception.h b/arch/x86/math-emu/exception.h
index 75230b9775777..59961d350bc4d 100644
--- a/arch/x86/math-emu/exception.h
+++ b/arch/x86/math-emu/exception.h
@@ -10,7 +10,7 @@
 #ifndef _EXCEPTION_H_
 #define _EXCEPTION_H_
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 #define	Const_(x)	$##x
 #else
 #define	Const_(x)	x
@@ -37,7 +37,7 @@
 #define PRECISION_LOST_UP    Const_((EX_Precision | SW_C1))
 #define PRECISION_LOST_DOWN  Const_(EX_Precision)
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #ifdef DEBUG
 #define	EXCEPTION(x)	{ printk("exception in %s at line %d\n", \
@@ -46,6 +46,6 @@
 #define	EXCEPTION(x)	FPU_exception(x)
 #endif
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _EXCEPTION_H_ */
diff --git a/arch/x86/math-emu/fpu_emu.h b/arch/x86/math-emu/fpu_emu.h
index 0c122226ca56f..def569c50b760 100644
--- a/arch/x86/math-emu/fpu_emu.h
+++ b/arch/x86/math-emu/fpu_emu.h
@@ -20,7 +20,7 @@
  */
 #define PECULIAR_486
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 #include "fpu_asm.h"
 #define	Const(x)	$##x
 #else
@@ -68,7 +68,7 @@
 
 #define FPU_Exception   Const(0x80000000)	/* Added to tag returns. */
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #include "fpu_system.h"
 
@@ -213,6 +213,6 @@ asmlinkage int FPU_round(FPU_REG *arg, unsigned int extent, int dummy,
 #include "fpu_proto.h"
 #endif
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _FPU_EMU_H_ */
diff --git a/arch/x86/math-emu/status_w.h b/arch/x86/math-emu/status_w.h
index b77bafec95260..f642957330efc 100644
--- a/arch/x86/math-emu/status_w.h
+++ b/arch/x86/math-emu/status_w.h
@@ -13,7 +13,7 @@
 
 #include "fpu_emu.h"		/* for definition of PECULIAR_486 */
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 #define	Const__(x)	$##x
 #else
 #define	Const__(x)	x
@@ -37,7 +37,7 @@
 
 #define SW_Exc_Mask     Const__(0x27f)	/* Status word exception bit mask */
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 #define COMP_A_gt_B	1
 #define COMP_A_eq_B	2
@@ -63,6 +63,6 @@ static inline void setcc(int cc)
 #  define clear_C1()
 #endif /* PECULIAR_486 */
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _STATUS_H_ */
diff --git a/arch/x86/realmode/rm/realmode.h b/arch/x86/realmode/rm/realmode.h
index c76041a353970..867e55f1d6af4 100644
--- a/arch/x86/realmode/rm/realmode.h
+++ b/arch/x86/realmode/rm/realmode.h
@@ -2,7 +2,7 @@
 #ifndef ARCH_X86_REALMODE_RM_REALMODE_H
 #define ARCH_X86_REALMODE_RM_REALMODE_H
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 
 /*
  * 16-bit ljmpw to the real_mode_seg
@@ -12,7 +12,7 @@
  */
 #define LJMPW_RM(to)	.byte 0xea ; .word (to), real_mode_seg
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 /*
  * Signature at the end of the realmode region
diff --git a/arch/x86/realmode/rm/wakeup.h b/arch/x86/realmode/rm/wakeup.h
index 0e4fd08ae4471..3b6d8fa82d3e1 100644
--- a/arch/x86/realmode/rm/wakeup.h
+++ b/arch/x86/realmode/rm/wakeup.h
@@ -7,7 +7,7 @@
 #ifndef ARCH_X86_KERNEL_ACPI_RM_WAKEUP_H
 #define ARCH_X86_KERNEL_ACPI_RM_WAKEUP_H
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 /* This must match data at wakeup.S */
diff --git a/tools/arch/x86/include/asm/asm.h b/tools/arch/x86/include/asm/asm.h
index 3ad3da9a7d974..dbe39b44256ba 100644
--- a/tools/arch/x86/include/asm/asm.h
+++ b/tools/arch/x86/include/asm/asm.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_ASM_H
 #define _ASM_X86_ASM_H
 
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 # define __ASM_FORM(x, ...)		x,## __VA_ARGS__
 # define __ASM_FORM_RAW(x, ...)		x,## __VA_ARGS__
 # define __ASM_FORM_COMMA(x, ...)	x,## __VA_ARGS__,
@@ -123,7 +123,7 @@
 #ifdef __KERNEL__
 
 /* Exception table entry */
-#ifdef __ASSEMBLY__
+#ifdef __ASSEMBLER__
 # define _ASM_EXTABLE_HANDLE(from, to, handler)			\
 	.pushsection "__ex_table","a" ;				\
 	.balign 4 ;						\
@@ -154,7 +154,7 @@
 #  define _ASM_NOKPROBE(entry)
 # endif
 
-#else /* ! __ASSEMBLY__ */
+#else /* ! __ASSEMBLER__ */
 # define _EXPAND_EXTABLE_HANDLE(x) #x
 # define _ASM_EXTABLE_HANDLE(from, to, handler)			\
 	" .pushsection \"__ex_table\",\"a\"\n"			\
@@ -186,7 +186,7 @@
  */
 register unsigned long current_stack_pointer asm(_ASM_SP);
 #define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* __KERNEL__ */
 
diff --git a/tools/arch/x86/include/asm/nops.h b/tools/arch/x86/include/asm/nops.h
index 1c1b7550fa550..cd94221d83358 100644
--- a/tools/arch/x86/include/asm/nops.h
+++ b/tools/arch/x86/include/asm/nops.h
@@ -82,7 +82,7 @@
 #define ASM_NOP7 _ASM_BYTES(BYTES_NOP7)
 #define ASM_NOP8 _ASM_BYTES(BYTES_NOP8)
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 extern const unsigned char * const x86_nops[];
 #endif
 
diff --git a/tools/arch/x86/include/asm/orc_types.h b/tools/arch/x86/include/asm/orc_types.h
index 46d7e06763c9f..e0125afa53fb9 100644
--- a/tools/arch/x86/include/asm/orc_types.h
+++ b/tools/arch/x86/include/asm/orc_types.h
@@ -45,7 +45,7 @@
 #define ORC_TYPE_REGS			3
 #define ORC_TYPE_REGS_PARTIAL		4
 
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 #include 
 
 /*
@@ -73,6 +73,6 @@ struct orc_entry {
 #endif
 } __packed;
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #endif /* _ORC_TYPES_H */
diff --git a/tools/arch/x86/include/asm/pvclock-abi.h b/tools/arch/x86/include/asm/pvclock-abi.h
index 1436226efe3ef..b9fece5fc96d6 100644
--- a/tools/arch/x86/include/asm/pvclock-abi.h
+++ b/tools/arch/x86/include/asm/pvclock-abi.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 #ifndef _ASM_X86_PVCLOCK_ABI_H
 #define _ASM_X86_PVCLOCK_ABI_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
 
 /*
  * These structs MUST NOT be changed.
@@ -44,5 +44,5 @@ struct pvclock_wall_clock {
 #define PVCLOCK_GUEST_STOPPED	(1 << 1)
 /* PVCLOCK_COUNTS_FROM_ZERO broke ABI and can't be used anymore. */
 #define PVCLOCK_COUNTS_FROM_ZERO (1 << 2)
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 #endif /* _ASM_X86_PVCLOCK_ABI_H */
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 05 22:20:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 22:20:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976480.1363621 (Exim 4.92)
	(envelope-from )
	id 1uC4Af-0008A7-A5; Mon, 05 May 2025 22:20:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976480.1363621; Mon, 05 May 2025 22: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 1uC4Af-0008A0-7N; Mon, 05 May 2025 22:20:21 +0000
Received: by outflank-mailman (input) for mailman id 976480;
 Mon, 05 May 2025 22:20:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uC4Ae-00089s-Ae
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 22:20:20 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2062c278-29ff-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 00:20:19 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 16444629CA;
 Mon,  5 May 2025 22:19:46 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5F63C4CEEF;
 Mon,  5 May 2025 22:20: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" 
X-Inumbo-ID: 2062c278-29ff-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746483617;
	bh=1rX1VygvKUtt1fWJvrpYXGnj2mNZwGwmHDPfH9Do8c8=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=QRllFpBZ/+6qJN8aKawG4XXh0h4fYDOk9OyLc0BTOwPeiH/iZx2nrgR//nwiE95Ff
	 /idKnl8YDAnZ11AnOiG82yifheTiktK2JxZaP6lCoI33KTYR7IQPA0ap0QIAO/c4yP
	 UrCQqc2dB0e7Vkpw3+cHPfGuI/YeFllIWu8ld/jUqGE4IjPkuQcd1qGAd367S6J6sO
	 oBYOftaOpLDCtEkeKMShVe8pP+xYaj/66wz3zZEVvv69FeC4CcIF05KrUtYMX/SEd3
	 hi7qkuGzAc9RondHcguok9lp+2iHrpyUgMTOhYHWvVeMjVzJwjInJuHBX40OO3poat
	 6eMxXPu7CNQMg==
From: Sasha Levin 
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Frediano Ziglio ,
	Juergen Gross ,
	Sasha Levin ,
	sstabellini@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH AUTOSEL 6.14 146/642] xen: Add support for XenServer 6.1 platform device
Date: Mon,  5 May 2025 18:06:02 -0400
Message-Id: <20250505221419.2672473-146-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250505221419.2672473-1-sashal@kernel.org>
References: <20250505221419.2672473-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.14.5
Content-Transfer-Encoding: 8bit

From: Frediano Ziglio 

[ Upstream commit 2356f15caefc0cc63d9cc5122641754f76ef9b25 ]

On XenServer on Windows machine a platform device with ID 2 instead of
1 is used.

This device is mainly identical to device 1 but due to some Windows
update behaviour it was decided to use a device with a different ID.

This causes compatibility issues with Linux which expects, if Xen
is detected, to find a Xen platform device (5853:0001) otherwise code
will crash due to some missing initialization (specifically grant
tables). Specifically from dmesg

    RIP: 0010:gnttab_expand+0x29/0x210
    Code: 90 0f 1f 44 00 00 55 31 d2 48 89 e5 41 57 41 56 41 55 41 89 fd
          41 54 53 48 83 ec 10 48 8b 05 7e 9a 49 02 44 8b 35 a7 9a 49 02
          <8b> 48 04 8d 44 39 ff f7 f1 45 8d 24 06 89 c3 e8 43 fe ff ff
          44 39
    RSP: 0000:ffffba34c01fbc88 EFLAGS: 00010086
    ...

The device 2 is presented by Xapi adding device specification to
Qemu command line.

Signed-off-by: Frediano Ziglio 
Acked-by: Juergen Gross 
Message-ID: <20250227145016.25350-1-frediano.ziglio@cloud.com>
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 drivers/xen/platform-pci.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 544d3f9010b92..1db82da56db62 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -26,6 +26,8 @@
 
 #define DRV_NAME    "xen-platform-pci"
 
+#define PCI_DEVICE_ID_XEN_PLATFORM_XS61	0x0002
+
 static unsigned long platform_mmio;
 static unsigned long platform_mmio_alloc;
 static unsigned long platform_mmiolen;
@@ -174,6 +176,8 @@ static int platform_pci_probe(struct pci_dev *pdev,
 static const struct pci_device_id platform_pci_tbl[] = {
 	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM,
 		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM_XS61,
+		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{0,}
 };
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 05 22:41:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 22:41:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976492.1363630 (Exim 4.92)
	(envelope-from )
	id 1uC4Uj-0003Fw-RJ; Mon, 05 May 2025 22:41:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976492.1363630; Mon, 05 May 2025 22: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 1uC4Uj-0003Fp-OE; Mon, 05 May 2025 22:41:05 +0000
Received: by outflank-mailman (input) for mailman id 976492;
 Mon, 05 May 2025 22:41:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uC4Ui-0003Fj-ID
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 22:41:04 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0569242b-2a02-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 00:41:02 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 65A3143DCD;
 Mon,  5 May 2025 22:40:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31704C4CEF2;
 Mon,  5 May 2025 22:41: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" 
X-Inumbo-ID: 0569242b-2a02-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746484861;
	bh=CjL8LGPu4Bfyc0hVImZlWY5Ujss/SIQuzx4+7U/11jM=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=cejBm3muQz4uKz1jUyK8WoEPhNTe2LI8KOJMCMrPaORusLUvjFU3pq2F0lTlIgQgB
	 tlaLLat4KAFXvemXBZpCUXMv0qo1IWv2JXd6s0/mGNVMpSlDOxuLTBosGJZONGF3E/
	 Uw++txwW28F3BhzpicLCW4CeYfuOCwHsnXHNtaXtmSzmbAAMu9I7nlbEB78s2yqBO9
	 tTnq+Py7LDC1YpNTowigUSG6/J+ce/d6WeioUR0jMH0MVrPE5iV+zS/V54FExz0VHi
	 xPHj2k2nlhlhUgIJhx+oR1TidxGwpFt5xOjo8UOSRf/DI5NaenuvcO6INU/sXtQlMo
	 d91VWMMDNJEzw==
From: Sasha Levin 
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Roger Pau Monne ,
	Juergen Gross ,
	Sasha Levin ,
	sstabellini@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH AUTOSEL 6.12 052/486] xen/pci: Do not register devices with segments >= 0x10000
Date: Mon,  5 May 2025 18:32:08 -0400
Message-Id: <20250505223922.2682012-52-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250505223922.2682012-1-sashal@kernel.org>
References: <20250505223922.2682012-1-sashal@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.12.26
Content-Transfer-Encoding: 8bit

From: Roger Pau Monne 

[ Upstream commit 5ccf1b8ae76ddf348e02a0d1564ff9baf8b6c415 ]

The current hypercall interface for doing PCI device operations always uses
a segment field that has a 16 bit width.  However on Linux there are buses
like VMD that hook up devices into the PCI hierarchy at segment >= 0x10000,
after the maximum possible segment enumerated in ACPI.

Attempting to register or manage those devices with Xen would result in
errors at best, or overlaps with existing devices living on the truncated
equivalent segment values.  Note also that the VMD segment numbers are
arbitrarily assigned by the OS, and hence there would need to be some
negotiation between Xen and the OS to agree on how to enumerate VMD
segments and devices behind them.

Skip notifying Xen about those devices.  Given how VMD bridges can
multiplex interrupts on behalf of devices behind them there's no need for
Xen to be aware of such devices for them to be usable by Linux.

Signed-off-by: Roger Pau Monné 
Acked-by: Juergen Gross 
Message-ID: <20250219092059.90850-2-roger.pau@citrix.com>
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 drivers/xen/pci.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 416f231809cb6..bfe07adb3e3a6 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -43,6 +43,18 @@ static int xen_add_device(struct device *dev)
 		pci_mcfg_reserved = true;
 	}
 #endif
+
+	if (pci_domain_nr(pci_dev->bus) >> 16) {
+		/*
+		 * The hypercall interface is limited to 16bit PCI segment
+		 * values, do not attempt to register devices with Xen in
+		 * segments greater or equal than 0x10000.
+		 */
+		dev_info(dev,
+			 "not registering with Xen: invalid PCI segment\n");
+		return 0;
+	}
+
 	if (pci_seg_supported) {
 		DEFINE_RAW_FLEX(struct physdev_pci_device_add, add, optarr, 1);
 
@@ -149,6 +161,16 @@ static int xen_remove_device(struct device *dev)
 	int r;
 	struct pci_dev *pci_dev = to_pci_dev(dev);
 
+	if (pci_domain_nr(pci_dev->bus) >> 16) {
+		/*
+		 * The hypercall interface is limited to 16bit PCI segment
+		 * values.
+		 */
+		dev_info(dev,
+			 "not unregistering with Xen: invalid PCI segment\n");
+		return 0;
+	}
+
 	if (pci_seg_supported) {
 		struct physdev_pci_device device = {
 			.seg = pci_domain_nr(pci_dev->bus),
@@ -182,6 +204,16 @@ int xen_reset_device(const struct pci_dev *dev)
 		.flags = PCI_DEVICE_RESET_FLR,
 	};
 
+	if (pci_domain_nr(dev->bus) >> 16) {
+		/*
+		 * The hypercall interface is limited to 16bit PCI segment
+		 * values.
+		 */
+		dev_info(&dev->dev,
+			 "unable to notify Xen of device reset: invalid PCI segment\n");
+		return 0;
+	}
+
 	return HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_reset, &device);
 }
 EXPORT_SYMBOL_GPL(xen_reset_device);
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 05 22:43:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 22:43:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976502.1363641 (Exim 4.92)
	(envelope-from )
	id 1uC4Wv-0003yk-6o; Mon, 05 May 2025 22:43:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976502.1363641; Mon, 05 May 2025 22: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 1uC4Wv-0003yd-3C; Mon, 05 May 2025 22:43:21 +0000
Received: by outflank-mailman (input) for mailman id 976502;
 Mon, 05 May 2025 22:43:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uC4Wt-0003yX-IM
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 22:43:19 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 561afd10-2a02-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 00:43:18 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 3335E49CE9;
 Mon,  5 May 2025 22:43:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7F3CC4CEF1;
 Mon,  5 May 2025 22:43: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" 
X-Inumbo-ID: 561afd10-2a02-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746484996;
	bh=1rX1VygvKUtt1fWJvrpYXGnj2mNZwGwmHDPfH9Do8c8=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=g5PP+AIhnTqpIR8E8rShkE+8WwTq89tcv3i6axFqB5+Kt8VXED7wpdCDhQ9VVcfnL
	 ejmSrXXsFCgCjypYJlbY/R2QMh9zoAWbG8GGgbNAPUkmrTGssUV4sCaa2aReNrVO9G
	 7om32qCqsbC2c5xwlLPa9iump10x6qRnKQYdh2AP0TVfeX5ijAx3lAnHqRwnciTlo2
	 93ZdD9GA6CfuraL8WpFxZ7SzhGyuXt0xnpgGzp+ZfRm85qQCAWGnaNrikO4ZtudhYG
	 N45G5FKuHENeKGsDs3vtteT8/XLvN5l2I2KdDWsHjboN95HzpCHaI1sD7zPVPBZ5l2
	 Av1mf3WSQuNOg==
From: Sasha Levin 
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Frediano Ziglio ,
	Juergen Gross ,
	Sasha Levin ,
	sstabellini@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH AUTOSEL 6.12 117/486] xen: Add support for XenServer 6.1 platform device
Date: Mon,  5 May 2025 18:33:13 -0400
Message-Id: <20250505223922.2682012-117-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250505223922.2682012-1-sashal@kernel.org>
References: <20250505223922.2682012-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.12.26
Content-Transfer-Encoding: 8bit

From: Frediano Ziglio 

[ Upstream commit 2356f15caefc0cc63d9cc5122641754f76ef9b25 ]

On XenServer on Windows machine a platform device with ID 2 instead of
1 is used.

This device is mainly identical to device 1 but due to some Windows
update behaviour it was decided to use a device with a different ID.

This causes compatibility issues with Linux which expects, if Xen
is detected, to find a Xen platform device (5853:0001) otherwise code
will crash due to some missing initialization (specifically grant
tables). Specifically from dmesg

    RIP: 0010:gnttab_expand+0x29/0x210
    Code: 90 0f 1f 44 00 00 55 31 d2 48 89 e5 41 57 41 56 41 55 41 89 fd
          41 54 53 48 83 ec 10 48 8b 05 7e 9a 49 02 44 8b 35 a7 9a 49 02
          <8b> 48 04 8d 44 39 ff f7 f1 45 8d 24 06 89 c3 e8 43 fe ff ff
          44 39
    RSP: 0000:ffffba34c01fbc88 EFLAGS: 00010086
    ...

The device 2 is presented by Xapi adding device specification to
Qemu command line.

Signed-off-by: Frediano Ziglio 
Acked-by: Juergen Gross 
Message-ID: <20250227145016.25350-1-frediano.ziglio@cloud.com>
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 drivers/xen/platform-pci.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 544d3f9010b92..1db82da56db62 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -26,6 +26,8 @@
 
 #define DRV_NAME    "xen-platform-pci"
 
+#define PCI_DEVICE_ID_XEN_PLATFORM_XS61	0x0002
+
 static unsigned long platform_mmio;
 static unsigned long platform_mmio_alloc;
 static unsigned long platform_mmiolen;
@@ -174,6 +176,8 @@ static int platform_pci_probe(struct pci_dev *pdev,
 static const struct pci_device_id platform_pci_tbl[] = {
 	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM,
 		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM_XS61,
+		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{0,}
 };
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 05 22:59:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 22:59:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976515.1363650 (Exim 4.92)
	(envelope-from )
	id 1uC4m3-00063d-C1; Mon, 05 May 2025 22:58:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976515.1363650; Mon, 05 May 2025 22:58:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uC4m3-00063W-9X; Mon, 05 May 2025 22:58:59 +0000
Received: by outflank-mailman (input) for mailman id 976515;
 Mon, 05 May 2025 22:58:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uC4m1-00063O-Kr
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 22:58:57 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 846708d0-2a04-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 00:58:54 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id F00AD5C5B3F;
 Mon,  5 May 2025 22:56:35 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02231C4CEEF;
 Mon,  5 May 2025 22:58: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" 
X-Inumbo-ID: 846708d0-2a04-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746485932;
	bh=1rX1VygvKUtt1fWJvrpYXGnj2mNZwGwmHDPfH9Do8c8=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=tQj6BFaPpV1r1sbPTgQUPG+EGnURPRbgcwNdnj/JFjuLBenw1bG+MUex0DVfuT6gO
	 I4BVTJuCT/mK4pUMV9sVsTm274d/ewHHp5gXL5H/cWi7/beeaPzF9I2hOy1zIDitu2
	 JnMUwJSLDAIUWsfSG6Odyc7D+ERAvusy7JKwmKTen3P9Hi3CzKQxvUjsShMkVe72Ng
	 93P/1FXS4rR/NIVGFJLg/GZgY6LD4bGWnDfCHnUno1j2mehFyz064D6ZNB4kAtaf0Z
	 gezh++TZiZjKfD1RO+vfB6GUb25c0jU0LDWQDb02zhub3MPGnDRC5fKRDFGmoFfvBq
	 8J6vu1izzR5Aw==
From: Sasha Levin 
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Frediano Ziglio ,
	Juergen Gross ,
	Sasha Levin ,
	sstabellini@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH AUTOSEL 6.6 073/294] xen: Add support for XenServer 6.1 platform device
Date: Mon,  5 May 2025 18:52:53 -0400
Message-Id: <20250505225634.2688578-73-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250505225634.2688578-1-sashal@kernel.org>
References: <20250505225634.2688578-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.6.89
Content-Transfer-Encoding: 8bit

From: Frediano Ziglio 

[ Upstream commit 2356f15caefc0cc63d9cc5122641754f76ef9b25 ]

On XenServer on Windows machine a platform device with ID 2 instead of
1 is used.

This device is mainly identical to device 1 but due to some Windows
update behaviour it was decided to use a device with a different ID.

This causes compatibility issues with Linux which expects, if Xen
is detected, to find a Xen platform device (5853:0001) otherwise code
will crash due to some missing initialization (specifically grant
tables). Specifically from dmesg

    RIP: 0010:gnttab_expand+0x29/0x210
    Code: 90 0f 1f 44 00 00 55 31 d2 48 89 e5 41 57 41 56 41 55 41 89 fd
          41 54 53 48 83 ec 10 48 8b 05 7e 9a 49 02 44 8b 35 a7 9a 49 02
          <8b> 48 04 8d 44 39 ff f7 f1 45 8d 24 06 89 c3 e8 43 fe ff ff
          44 39
    RSP: 0000:ffffba34c01fbc88 EFLAGS: 00010086
    ...

The device 2 is presented by Xapi adding device specification to
Qemu command line.

Signed-off-by: Frediano Ziglio 
Acked-by: Juergen Gross 
Message-ID: <20250227145016.25350-1-frediano.ziglio@cloud.com>
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 drivers/xen/platform-pci.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 544d3f9010b92..1db82da56db62 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -26,6 +26,8 @@
 
 #define DRV_NAME    "xen-platform-pci"
 
+#define PCI_DEVICE_ID_XEN_PLATFORM_XS61	0x0002
+
 static unsigned long platform_mmio;
 static unsigned long platform_mmio_alloc;
 static unsigned long platform_mmiolen;
@@ -174,6 +176,8 @@ static int platform_pci_probe(struct pci_dev *pdev,
 static const struct pci_device_id platform_pci_tbl[] = {
 	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM,
 		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM_XS61,
+		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{0,}
 };
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 05 23:08:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 23:08:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976526.1363661 (Exim 4.92)
	(envelope-from )
	id 1uC4v3-00085x-6y; Mon, 05 May 2025 23:08:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976526.1363661; Mon, 05 May 2025 23:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uC4v3-00085q-3p; Mon, 05 May 2025 23:08:17 +0000
Received: by outflank-mailman (input) for mailman id 976526;
 Mon, 05 May 2025 23:08:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uC4v1-00085i-ML
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 23:08:15 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d21ea10b-2a05-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 01:08:14 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 97665A4D33D;
 Mon,  5 May 2025 23:02:45 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DDACC4CEEF;
 Mon,  5 May 2025 23:08: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" 
X-Inumbo-ID: d21ea10b-2a05-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746486492;
	bh=1rX1VygvKUtt1fWJvrpYXGnj2mNZwGwmHDPfH9Do8c8=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=TvAO0jLb25amMByUDLJDhIkH386Nh81qHTFycwZlLzWDph+K+odnbo2eli6r4KdBJ
	 mEZvE9IksasZyRGZftOWx+PuJc32MH1HkVZG3SqD29IUjmsCPGRRbMfwPRSGIEJtG7
	 Xdlg0/lIriFlofR+tz70c04WtMq2meSt0cIMJH8LwJNgeu0HPp786Nepwh+/Qjh98L
	 m0V2k7N+7gkPBOf2F5dozeqJ1cFRkvDcsSuxy0IDC6r4u8y+iCB6wJY8wjH4KE5Oxm
	 h8FaDwiMzn+PJj7QuyWl10bwcdsPiNg5AURa2PWYRktifweHhATlL1mYGWIzfO96l2
	 6o7tsYLNlmJpg==
From: Sasha Levin 
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Frediano Ziglio ,
	Juergen Gross ,
	Sasha Levin ,
	sstabellini@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH AUTOSEL 6.1 059/212] xen: Add support for XenServer 6.1 platform device
Date: Mon,  5 May 2025 19:03:51 -0400
Message-Id: <20250505230624.2692522-59-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250505230624.2692522-1-sashal@kernel.org>
References: <20250505230624.2692522-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.1.136
Content-Transfer-Encoding: 8bit

From: Frediano Ziglio 

[ Upstream commit 2356f15caefc0cc63d9cc5122641754f76ef9b25 ]

On XenServer on Windows machine a platform device with ID 2 instead of
1 is used.

This device is mainly identical to device 1 but due to some Windows
update behaviour it was decided to use a device with a different ID.

This causes compatibility issues with Linux which expects, if Xen
is detected, to find a Xen platform device (5853:0001) otherwise code
will crash due to some missing initialization (specifically grant
tables). Specifically from dmesg

    RIP: 0010:gnttab_expand+0x29/0x210
    Code: 90 0f 1f 44 00 00 55 31 d2 48 89 e5 41 57 41 56 41 55 41 89 fd
          41 54 53 48 83 ec 10 48 8b 05 7e 9a 49 02 44 8b 35 a7 9a 49 02
          <8b> 48 04 8d 44 39 ff f7 f1 45 8d 24 06 89 c3 e8 43 fe ff ff
          44 39
    RSP: 0000:ffffba34c01fbc88 EFLAGS: 00010086
    ...

The device 2 is presented by Xapi adding device specification to
Qemu command line.

Signed-off-by: Frediano Ziglio 
Acked-by: Juergen Gross 
Message-ID: <20250227145016.25350-1-frediano.ziglio@cloud.com>
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 drivers/xen/platform-pci.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 544d3f9010b92..1db82da56db62 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -26,6 +26,8 @@
 
 #define DRV_NAME    "xen-platform-pci"
 
+#define PCI_DEVICE_ID_XEN_PLATFORM_XS61	0x0002
+
 static unsigned long platform_mmio;
 static unsigned long platform_mmio_alloc;
 static unsigned long platform_mmiolen;
@@ -174,6 +176,8 @@ static int platform_pci_probe(struct pci_dev *pdev,
 static const struct pci_device_id platform_pci_tbl[] = {
 	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM,
 		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM_XS61,
+		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{0,}
 };
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 05 23:12:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 23:12:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976538.1363671 (Exim 4.92)
	(envelope-from )
	id 1uC4z1-0001fV-MH; Mon, 05 May 2025 23:12:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976538.1363671; Mon, 05 May 2025 23:12:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uC4z1-0001fO-Iv; Mon, 05 May 2025 23:12:23 +0000
Received: by outflank-mailman (input) for mailman id 976538;
 Mon, 05 May 2025 23:12:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC4yz-0001fI-OM
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 23:12:21 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5d15cf7f-2a06-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 01:12:07 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 7178D629CE;
 Mon,  5 May 2025 23:11:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7122CC4CEED;
 Mon,  5 May 2025 23:12: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" 
X-Inumbo-ID: 5d15cf7f-2a06-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746486726;
	bh=88PaDfHURWWSCqM62oUkcoRn9IbHXT97qREKVCVw/Kc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=QtuA4exxz3syuD1rKJx+Rapmp+b3sD+J2LBdODvTaFaGpod9wpV04gc2rZM3EmPcW
	 nTcKONttmTsYA91aRl2XEtuFw/bsS/P2FOemARSzz7DXTMjgHbrM5a4HzPMlgzGGwl
	 pGPtgokjIU8FbTdbSlWiNIWDAY73HhAA9u9ko/E8UDRWDIRQgx+f8NWyI2tLz28cbk
	 Ez4NotzmLNBXw6awHYG1y3OFshGDm1AdwPueK/i/gCkdKnLRXnryi/v4blR82QbysK
	 ltZmriI9+aZG1J7UFCNsHDxotrqX8qtucQDr8wSZRsbfWYqRgn/eDG22JRXc9o5WV9
	 dO13oX8f88lsA==
Date: Mon, 5 May 2025 16:12:02 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Victor Lira 
cc: xen-devel@lists.xenproject.org, 
    Nicola Vetrini , 
    Federico Serafini , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Bertrand Marquis 
Subject: Re: [PATCH v2 1/2] x86: x86_emulate: address violations of MISRA C
 Rule 19.1
In-Reply-To: <20250502233535.3532279-1-victorm.lira@amd.com>
Message-ID: 
References: <20250502233535.3532279-1-victorm.lira@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 2 May 2025, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
> 
> Rule 19.1 states: "An object shall not be assigned or copied
> to an overlapping object". In the function like macro "get_rep_prefix",
> one member of a union is assigned the value of another member. Reading from one
> member and writing to the other violates the rule, while not causing Undefined
> Behavior due to their relative sizes. Instead, use casts combined with exactly
> overlapping accesses to address violations.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> Signed-off-by: Federico Serafini 
> Signed-off-by: Victor Lira 
> ---
> Changes in v2:
> - Use casts combined with exactly overlapping accesses to address
>   violations
> - fix commit message
> ---
> Cc: Andrew Cooper 
> Cc: Anthony PERARD 
> Cc: Michal Orzel 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Roger Pau Monn?? 
> Cc: Stefano Stabellini 
> Cc: Nicola Vetrini 
> Cc: Federico Serafini 
> Cc: Bertrand Marquis 
> ---
>  xen/arch/x86/x86_emulate/x86_emulate.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
> index 8e14ebb35b..d678855238 100644
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -527,8 +527,8 @@ static inline void put_loop_count(
>          if ( !amd_like(ctxt) && mode_64bit() && ad_bytes == 4 )         \
>          {                                                               \
>              _regs.r(cx) = 0;                                            \
> -            if ( extend_si ) _regs.r(si) = _regs.esi;                   \
> -            if ( extend_di ) _regs.r(di) = _regs.edi;                   \
> +            if ( extend_si ) _regs.r(si) = (uint32_t)_regs.r(si);        \
> +            if ( extend_di ) _regs.r(di) = (uint32_t)_regs.r(di);        \

NIT: code style, alignment of the \

Can be fixed on commit.

Reviewed-by: Stefano Stabellini 


>          }                                                               \
>          goto complete_insn;                                             \
>      }                                                                   \
> @@ -2029,7 +2029,7 @@ x86_emulate(
>          switch ( op_bytes )
>          {
>          case 2: _regs.ax = (int8_t)_regs.ax; break; /* cbw */
> -        case 4: _regs.r(ax) = (uint32_t)(int16_t)_regs.ax; break; /* cwde */
> +        case 4: _regs.r(ax) = (uint32_t)(int16_t)_regs.r(ax); break; /* cwde */
>          case 8: _regs.r(ax) = (int32_t)_regs.r(ax); break; /* cdqe */
>          }
>          break;
> --
> 2.25.1
> 


From xen-devel-bounces@lists.xenproject.org Mon May 05 23:14:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 23:14:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976553.1363680 (Exim 4.92)
	(envelope-from )
	id 1uC51O-0002G8-4v; Mon, 05 May 2025 23:14:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976553.1363680; Mon, 05 May 2025 23: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 1uC51O-0002G1-2I; Mon, 05 May 2025 23:14:50 +0000
Received: by outflank-mailman (input) for mailman id 976553;
 Mon, 05 May 2025 23:14:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uC51N-0002Fv-2z
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 23:14:49 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bbf7f4fb-2a06-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 01:14:47 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id BA7AF4A252;
 Mon,  5 May 2025 23:14:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81328C4CEF1;
 Mon,  5 May 2025 23:14: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" 
X-Inumbo-ID: bbf7f4fb-2a06-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746486885;
	bh=AaVyXzjXMB89c+N3cLGs6RLB1uFIyFBHLakI9cGBQ9U=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=HVPTCFIQrJ2KaeujaUMNIqDB06WwR297YjQeAukSKLIIB0XXHltgVekrrbIuYIkaS
	 Iw7F/hzIPdal+bOqI8rZPFjj1UYtPlXldDRD+YXSkDjzp6JFkKh7yz8XL7unJk8aHg
	 pRJ/IZlwmsw0YjoUGreLdacF5mhZmOp+DibkeU+CR8gwIMruZUliEyuXBUQElcHp6/
	 ndFkvVjUl9Jx67ZsFdXbK5gCebj/pcDDeekzp+9MNtd9BhHiPguw0nG2bJYdynNhAg
	 m7eCONGMSz8nWVe7wmEk/jTmECVtcbjcjhUrft50KCU6wmPul7cPKQT8tXVqkhuh8Q
	 rgIhGy8TAT9tg==
From: Sasha Levin 
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Frediano Ziglio ,
	Juergen Gross ,
	Sasha Levin ,
	sstabellini@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH AUTOSEL 5.15 043/153] xen: Add support for XenServer 6.1 platform device
Date: Mon,  5 May 2025 19:11:30 -0400
Message-Id: <20250505231320.2695319-43-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250505231320.2695319-1-sashal@kernel.org>
References: <20250505231320.2695319-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 5.15.181
Content-Transfer-Encoding: 8bit

From: Frediano Ziglio 

[ Upstream commit 2356f15caefc0cc63d9cc5122641754f76ef9b25 ]

On XenServer on Windows machine a platform device with ID 2 instead of
1 is used.

This device is mainly identical to device 1 but due to some Windows
update behaviour it was decided to use a device with a different ID.

This causes compatibility issues with Linux which expects, if Xen
is detected, to find a Xen platform device (5853:0001) otherwise code
will crash due to some missing initialization (specifically grant
tables). Specifically from dmesg

    RIP: 0010:gnttab_expand+0x29/0x210
    Code: 90 0f 1f 44 00 00 55 31 d2 48 89 e5 41 57 41 56 41 55 41 89 fd
          41 54 53 48 83 ec 10 48 8b 05 7e 9a 49 02 44 8b 35 a7 9a 49 02
          <8b> 48 04 8d 44 39 ff f7 f1 45 8d 24 06 89 c3 e8 43 fe ff ff
          44 39
    RSP: 0000:ffffba34c01fbc88 EFLAGS: 00010086
    ...

The device 2 is presented by Xapi adding device specification to
Qemu command line.

Signed-off-by: Frediano Ziglio 
Acked-by: Juergen Gross 
Message-ID: <20250227145016.25350-1-frediano.ziglio@cloud.com>
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 drivers/xen/platform-pci.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 6ebd819338ecb..2c77cac5594ba 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -26,6 +26,8 @@
 
 #define DRV_NAME    "xen-platform-pci"
 
+#define PCI_DEVICE_ID_XEN_PLATFORM_XS61	0x0002
+
 static unsigned long platform_mmio;
 static unsigned long platform_mmio_alloc;
 static unsigned long platform_mmiolen;
@@ -174,6 +176,8 @@ static int platform_pci_probe(struct pci_dev *pdev,
 static const struct pci_device_id platform_pci_tbl[] = {
 	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM,
 		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM_XS61,
+		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{0,}
 };
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 05 23:19:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 23:19:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976564.1363691 (Exim 4.92)
	(envelope-from )
	id 1uC55m-0002qm-LJ; Mon, 05 May 2025 23:19:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976564.1363691; Mon, 05 May 2025 23:19:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uC55m-0002qf-II; Mon, 05 May 2025 23:19:22 +0000
Received: by outflank-mailman (input) for mailman id 976564;
 Mon, 05 May 2025 23:19:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uC55l-0002qX-2E
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 23:19:21 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5d860eb4-2a07-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 01:19:18 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 1AC2FA4D3F3;
 Mon,  5 May 2025 23:13:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91F26C4CEEE;
 Mon,  5 May 2025 23:19: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" 
X-Inumbo-ID: 5d860eb4-2a07-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746487156;
	bh=CFlI8amxnvW9hCT1y9g6G11aTMlGoZyNkfPHFYbFLko=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=ZX/XRmhSW+p/63+gkpHp0Q7Hbhd/mzyRml7E+wa3ofaDuEZOTJXLxJegl0GMssZWg
	 vA+OI3mNFD5RhmSFqsdTG9SOyVhzK9b5AWaYxlC7dcWoCPte930VS9JN7n/rUxRLXI
	 syhSZpqj9jIy/LLEZlSSbBa8739Mthz5X42CKVrasKrEy4W7NY04rqJGidmegHQIma
	 mJUdpDQ0FJxdKP27+x4+lJmV1L2PhDvm/QBmQ8bPQ2B22aCH3dgtVZJT2FOjqvIuKQ
	 Y0MYTkttFUfpWtVb+2KKH4UJH5dYeSR+G4IpBxP6ecYiHEpIxVgJGaxWBpGQgjl1u/
	 XFGaMv+uo2sZw==
From: Sasha Levin 
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Frediano Ziglio ,
	Juergen Gross ,
	Sasha Levin ,
	sstabellini@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH AUTOSEL 5.10 031/114] xen: Add support for XenServer 6.1 platform device
Date: Mon,  5 May 2025 19:16:54 -0400
Message-Id: <20250505231817.2697367-31-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250505231817.2697367-1-sashal@kernel.org>
References: <20250505231817.2697367-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 5.10.237
Content-Transfer-Encoding: 8bit

From: Frediano Ziglio 

[ Upstream commit 2356f15caefc0cc63d9cc5122641754f76ef9b25 ]

On XenServer on Windows machine a platform device with ID 2 instead of
1 is used.

This device is mainly identical to device 1 but due to some Windows
update behaviour it was decided to use a device with a different ID.

This causes compatibility issues with Linux which expects, if Xen
is detected, to find a Xen platform device (5853:0001) otherwise code
will crash due to some missing initialization (specifically grant
tables). Specifically from dmesg

    RIP: 0010:gnttab_expand+0x29/0x210
    Code: 90 0f 1f 44 00 00 55 31 d2 48 89 e5 41 57 41 56 41 55 41 89 fd
          41 54 53 48 83 ec 10 48 8b 05 7e 9a 49 02 44 8b 35 a7 9a 49 02
          <8b> 48 04 8d 44 39 ff f7 f1 45 8d 24 06 89 c3 e8 43 fe ff ff
          44 39
    RSP: 0000:ffffba34c01fbc88 EFLAGS: 00010086
    ...

The device 2 is presented by Xapi adding device specification to
Qemu command line.

Signed-off-by: Frediano Ziglio 
Acked-by: Juergen Gross 
Message-ID: <20250227145016.25350-1-frediano.ziglio@cloud.com>
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 drivers/xen/platform-pci.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 804d8f4d0e73d..e7a95f7926c4e 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -26,6 +26,8 @@
 
 #define DRV_NAME    "xen-platform-pci"
 
+#define PCI_DEVICE_ID_XEN_PLATFORM_XS61	0x0002
+
 static unsigned long platform_mmio;
 static unsigned long platform_mmio_alloc;
 static unsigned long platform_mmiolen;
@@ -167,6 +169,8 @@ static int platform_pci_probe(struct pci_dev *pdev,
 static const struct pci_device_id platform_pci_tbl[] = {
 	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM,
 		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM_XS61,
+		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{0,}
 };
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 05 23:22:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 23:22:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976575.1363701 (Exim 4.92)
	(envelope-from )
	id 1uC58u-0004t1-3n; Mon, 05 May 2025 23:22:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976575.1363701; Mon, 05 May 2025 23: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 1uC58u-0004su-05; Mon, 05 May 2025 23:22:36 +0000
Received: by outflank-mailman (input) for mailman id 976575;
 Mon, 05 May 2025 23:22:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uC58s-0004so-RI
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 23:22:34 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d1d79d28-2a07-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 01:22:33 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 023305C5BB5;
 Mon,  5 May 2025 23:20:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08FA7C4CEE4;
 Mon,  5 May 2025 23:22: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" 
X-Inumbo-ID: d1d79d28-2a07-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746487350;
	bh=HxW3KPz/RO3rWxVR1Rw69EqEbR6Y4Kb5Xqh7O+IvnNE=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=RMy/6oDEH11o5w5R87lYuhfOjlxOHBHy7BqAUNDQdRqcTJvOJ/keTMGmtEPeG9lHb
	 XQ1fZPw6XsdxeKBmGcDHQqw7+rw5mI6tnblLjraigDIBKU9oAShp3QOQprn9nTOv1n
	 NOVJKS3at+AGnAn4FZiquYsMGw+tvIxDrbBuWcYNdNOjq76caVDaddeV7zGg56FtSc
	 OiAIKsoUO0d3uLYe04ZqkKs7KwIqq+kgmkw+G0z/A8cGzlqIHn+U4xXo9gL1PlScEG
	 uRzQBOO7u2d3PfJVrvJZVZedFbnl4E1mdSKw84y+dzgKSagQ+Y0ORD8pdFolF7AL1o
	 ErBni4MAij6Eg==
From: Sasha Levin 
To: linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Cc: Frediano Ziglio ,
	Juergen Gross ,
	Sasha Levin ,
	sstabellini@kernel.org,
	xen-devel@lists.xenproject.org
Subject: [PATCH AUTOSEL 5.4 23/79] xen: Add support for XenServer 6.1 platform device
Date: Mon,  5 May 2025 19:20:55 -0400
Message-Id: <20250505232151.2698893-23-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250505232151.2698893-1-sashal@kernel.org>
References: <20250505232151.2698893-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 5.4.293
Content-Transfer-Encoding: 8bit

From: Frediano Ziglio 

[ Upstream commit 2356f15caefc0cc63d9cc5122641754f76ef9b25 ]

On XenServer on Windows machine a platform device with ID 2 instead of
1 is used.

This device is mainly identical to device 1 but due to some Windows
update behaviour it was decided to use a device with a different ID.

This causes compatibility issues with Linux which expects, if Xen
is detected, to find a Xen platform device (5853:0001) otherwise code
will crash due to some missing initialization (specifically grant
tables). Specifically from dmesg

    RIP: 0010:gnttab_expand+0x29/0x210
    Code: 90 0f 1f 44 00 00 55 31 d2 48 89 e5 41 57 41 56 41 55 41 89 fd
          41 54 53 48 83 ec 10 48 8b 05 7e 9a 49 02 44 8b 35 a7 9a 49 02
          <8b> 48 04 8d 44 39 ff f7 f1 45 8d 24 06 89 c3 e8 43 fe ff ff
          44 39
    RSP: 0000:ffffba34c01fbc88 EFLAGS: 00010086
    ...

The device 2 is presented by Xapi adding device specification to
Qemu command line.

Signed-off-by: Frediano Ziglio 
Acked-by: Juergen Gross 
Message-ID: <20250227145016.25350-1-frediano.ziglio@cloud.com>
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 drivers/xen/platform-pci.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index e1cb277a9e16f..69bceab71c3f7 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -26,6 +26,8 @@
 
 #define DRV_NAME    "xen-platform-pci"
 
+#define PCI_DEVICE_ID_XEN_PLATFORM_XS61	0x0002
+
 static unsigned long platform_mmio;
 static unsigned long platform_mmio_alloc;
 static unsigned long platform_mmiolen;
@@ -167,6 +169,8 @@ static int platform_pci_probe(struct pci_dev *pdev,
 static const struct pci_device_id platform_pci_tbl[] = {
 	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM,
 		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+	{PCI_VENDOR_ID_XEN, PCI_DEVICE_ID_XEN_PLATFORM_XS61,
+		PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{0,}
 };
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 05 23:25:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 23:25:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976586.1363711 (Exim 4.92)
	(envelope-from )
	id 1uC5Bs-0005UF-HX; Mon, 05 May 2025 23:25:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976586.1363711; Mon, 05 May 2025 23: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 1uC5Bs-0005U8-De; Mon, 05 May 2025 23:25:40 +0000
Received: by outflank-mailman (input) for mailman id 976586;
 Mon, 05 May 2025 23:25:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC5Bq-0005U2-TV
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 23:25:38 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3e2b360e-2a08-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 01:25:34 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 9A25C629CA;
 Mon,  5 May 2025 23:25:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37559C4CEE4;
 Mon,  5 May 2025 23:25: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" 
X-Inumbo-ID: 3e2b360e-2a08-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746487533;
	bh=Q1yJA4SS3bjMpoJiCL9Fm0psuO3lko1C/k5Ebu3H3KY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=J1FDZsu/Q4+XtE8n0oDvXKgV+ISYxwjpuuRxcRIoHWZZ/bg/xNazDVKXAkPnWTLTQ
	 UoROAJT8zUycXdsPD5HlG/1WwCuQYHjtCuNV2vp//sGS7wczvl2fnTSsLMQXX5irHF
	 NyEVFGVNjVlvUxDM6t5/8u+FOGLDlEMiFczvXX72InuN4O1n7bU8jwbnLj4Euo5qMb
	 ssSZoAVT1mAl+AhzBqK87g9m6V7RPN8uOsU/DWD7OmD92q8AblsFKRzAMnwboN0dmm
	 AIegqtguqpnp91MGYUEaxsWnoC6uZInePgBEvahRKWl45H37YuludbzcG5DIpTIDtK
	 cAtCj1TdHFk6g==
Date: Mon, 5 May 2025 16:25:30 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stewart Hildebrand 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk 
Subject: Re: [PATCH 3/6] xen/arm: switch find_domU_holes to rangesets
In-Reply-To: <20250505025631.207529-4-stewart.hildebrand@amd.com>
Message-ID: 
References: <20250505025631.207529-1-stewart.hildebrand@amd.com> <20250505025631.207529-4-stewart.hildebrand@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Sun, 4 May 2025, Stewart Hildebrand wrote:
> remove_shm_holes_for_domU() is unnecessarily complex: it re-creates the
> extended regions from scratch.
> 
> Move the rangeset into find_domU_holes() and create the extended regions
> only once. This makes is simpler to further manipulate the rangeset for
> removing other regions.
> 
> Remove now-unused remove_shm_holes_for_domU().
> 
> Signed-off-by: Stewart Hildebrand 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/domain_build.c             | 46 ++++++++++++-----
>  xen/arch/arm/include/asm/static-shmem.h |  9 ----
>  xen/arch/arm/static-shmem.c             | 65 -------------------------
>  3 files changed, 35 insertions(+), 85 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index a0f3c074337d..3dcdd7a8c46f 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1256,34 +1256,58 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>                                    struct membanks *ext_regions)
>  {
>      unsigned int i;
> -    uint64_t bankend;
>      const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
>      const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
>      const struct membanks *kinfo_mem = kernel_info_get_mem_const(kinfo);
> -    int res = -ENOENT;
> +    struct rangeset *mem_holes;
> +    int res;
> +
> +    mem_holes = rangeset_new(NULL, NULL, 0);
> +    if ( !mem_holes )
> +        return -ENOMEM;
>  
>      for ( i = 0; i < GUEST_RAM_BANKS; i++ )
>      {
> -        struct membank *ext_bank = &(ext_regions->bank[ext_regions->nr_banks]);
> +        uint64_t bankend, start, size = 0;
>  
> -        ext_bank->start = ROUNDUP(bankbase[i] + kinfo_mem->bank[i].size, SZ_2M);
> +        start = ROUNDUP(bankbase[i] + kinfo_mem->bank[i].size, SZ_2M);
>  
>          bankend = ~0ULL >> (64 - p2m_ipa_bits);
>          bankend = min(bankend, bankbase[i] + banksize[i] - 1);
> -        if ( bankend > ext_bank->start )
> -            ext_bank->size = bankend - ext_bank->start + 1;
> +
> +        if ( bankend > start )
> +            size = bankend - start + 1;
>  
>          /* 64MB is the minimum size of an extended region */
> -        if ( ext_bank->size < MB(64) )
> +        if ( size < MB(64) )
>              continue;
> -        ext_regions->nr_banks++;
> -        res = 0;
> +
> +        res = rangeset_add_range(mem_holes, PFN_DOWN(start), PFN_DOWN(bankend));
> +        if ( res )
> +        {
> +            printk(XENLOG_ERR "Failed to add: %#"PRIx64"->%#"PRIx64"\n",
> +                   start, start + size - 1);
> +            goto out;
> +        }
>      }
>  
> +    /* Remove static shared memory regions */
> +    res = remove_shm_from_rangeset(kinfo, mem_holes);
>      if ( res )
> -        return res;
> +        goto out;
> +
> +    res = rangeset_report_ranges(mem_holes, 0,
> +                                 PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
> +                                 add_ext_regions, ext_regions);
> +    if ( res )
> +        ext_regions->nr_banks = 0;
> +    else if ( !ext_regions->nr_banks )
> +        res = -ENOENT;
>  
> -    return remove_shm_holes_for_domU(kinfo, ext_regions);
> + out:
> +    rangeset_destroy(mem_holes);
> +
> +    return res;
>  }
>  
>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
> diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h
> index 94eaa9d500f9..ad8267c6bfbe 100644
> --- a/xen/arch/arm/include/asm/static-shmem.h
> +++ b/xen/arch/arm/include/asm/static-shmem.h
> @@ -28,9 +28,6 @@ void init_sharedmem_pages(void);
>  int remove_shm_from_rangeset(const struct kernel_info *kinfo,
>                               struct rangeset *rangeset);
>  
> -int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
> -                              struct membanks *ext_regions);
> -
>  int make_shm_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
>                                int sizecells);
>  
> @@ -74,12 +71,6 @@ static inline int remove_shm_from_rangeset(const struct kernel_info *kinfo,
>      return 0;
>  }
>  
> -static inline int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
> -                                            struct membanks *ext_regions)
> -{
> -    return 0;
> -}
> -
>  static inline int make_shm_resv_memory_node(const struct kernel_info *kinfo,
>                                              int addrcells, int sizecells)
>  {
> diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
> index e8d4ca3ba3ff..06f32be097c8 100644
> --- a/xen/arch/arm/static-shmem.c
> +++ b/xen/arch/arm/static-shmem.c
> @@ -820,71 +820,6 @@ int __init remove_shm_from_rangeset(const struct kernel_info *kinfo,
>      return 0;
>  }
>  
> -int __init remove_shm_holes_for_domU(const struct kernel_info *kinfo,
> -                                     struct membanks *ext_regions)
> -{
> -    const struct membanks *shm_mem = kernel_info_get_shm_mem_const(kinfo);
> -    struct rangeset *guest_holes;
> -    unsigned int i;
> -    paddr_t start;
> -    paddr_t end;
> -    int res;
> -
> -    /* No static shared memory region. */
> -    if ( shm_mem->nr_banks == 0 )
> -        return 0;
> -
> -    dt_dprintk("Remove static shared memory holes from extended regions of DomU\n");
> -
> -    guest_holes = rangeset_new(NULL, NULL, 0);
> -    if ( !guest_holes )
> -        return -ENOMEM;
> -
> -    /* Copy extended regions sets into the rangeset */
> -    for ( i = 0; i < ext_regions->nr_banks; i++ )
> -    {
> -        start = ext_regions->bank[i].start;
> -        end = start + ext_regions->bank[i].size;
> -
> -        res = rangeset_add_range(guest_holes, PFN_DOWN(start),
> -                                 PFN_DOWN(end - 1));
> -        if ( res )
> -        {
> -            printk(XENLOG_ERR
> -                   "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error: %d\n",
> -                   start, end, res);
> -            goto out;
> -        }
> -    }
> -
> -    /* Remove static shared memory regions */
> -    res = remove_shm_from_rangeset(kinfo, guest_holes);
> -    if ( res )
> -        goto out;
> -
> -    /*
> -     * Take the interval of memory starting from the first extended region bank
> -     * start address and ending to the end of the last extended region bank.
> -     */
> -    i = ext_regions->nr_banks - 1;
> -    start = ext_regions->bank[0].start;
> -    end = ext_regions->bank[i].start + ext_regions->bank[i].size - 1;
> -
> -    /* Reset original extended regions to hold new value */
> -    ext_regions->nr_banks = 0;
> -    res = rangeset_report_ranges(guest_holes, PFN_DOWN(start), PFN_DOWN(end),
> -                                 add_ext_regions, ext_regions);
> -    if ( res )
> -        ext_regions->nr_banks = 0;
> -    else if ( !ext_regions->nr_banks )
> -        res = -ENOENT;
> -
> - out:
> -    rangeset_destroy(guest_holes);
> -
> -    return res;
> -}
> -
>  void __init shm_mem_node_fill_reg_range(const struct kernel_info *kinfo,
>                                          __be32 *reg, int *nr_cells,
>                                          int addrcells, int sizecells)
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Mon May 05 23:32:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 05 May 2025 23:32:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976597.1363720 (Exim 4.92)
	(envelope-from )
	id 1uC5Hy-0007Vy-41; Mon, 05 May 2025 23:31:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976597.1363720; Mon, 05 May 2025 23: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 1uC5Hy-0007Vr-1O; Mon, 05 May 2025 23:31:58 +0000
Received: by outflank-mailman (input) for mailman id 976597;
 Mon, 05 May 2025 23:31:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC5Hw-0007UU-D5
 for xen-devel@lists.xenproject.org; Mon, 05 May 2025 23:31:56 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2093ad09-2a09-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 01:31:54 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id BFC255C5BAA;
 Mon,  5 May 2025 23:29:35 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7D66C4CEE4;
 Mon,  5 May 2025 23:31: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" 
X-Inumbo-ID: 2093ad09-2a09-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746487912;
	bh=NRLCMepId2/GntPrH4x+Ezogv+pmsrC0N/yLmAv6hHw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=cSjZLiW9f87wn29EqiDrdUZzJX9i3AmQCGaWyWpI/SF3Y21wR5FaZoTwzMFxkmzi3
	 6njzuqIXSV+5wX2j8/BXby9vThv6yJtvW7ltHRFh1i2Jxxu2/sHbv6NJQkx+G8P1UL
	 Yg1aMG6PRqYsSzTXs/3iIm2QvKAao/+kRWKpgPsUnMc9S59fXlA5chN5H6Y8KZHD+K
	 4ATtPDhS8siYka94o27AcTzd5T1gFUFwWVt84kxZf5k9xp9YToEHhySjmZMmPZRQ/X
	 98j1VuGKGQzJZoUZAganCjaw2G24rhkB57ORNhKHq67wko59sqFNEYD/RbhX/d8iPQ
	 M29Qv9UErFRKg==
Date: Mon, 5 May 2025 16:31:50 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stewart Hildebrand 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk 
Subject: Re: [PATCH 5/6] xen/arm: exclude xen,reg{-cacheable} from domU
 extended regions
In-Reply-To: <20250505025631.207529-6-stewart.hildebrand@amd.com>
Message-ID: 
References: <20250505025631.207529-1-stewart.hildebrand@amd.com> <20250505025631.207529-6-stewart.hildebrand@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Sun, 4 May 2025, Stewart Hildebrand wrote:
> When a device is passed through to a dom0less domU, the
> xen,reg{-cacheable} ranges may overlap with the extended regions. Remove
> xen,reg{-cacheable} from extended regions.

There is no reg-cacheable upstream, the commit message should avoid
mentioning it


> Signed-off-by: Stewart Hildebrand 
> ---
> Not sure if we need a Fixes: tag, but if we do:
> Fixes: 2a2447757b3c ("xen/arm: implement domU extended regions")
> 
> I investigated an alternate approach of parsing the partial device tree
> again to scan for xen,reg{-cacheable} properties, but it resulted in
> quite a lot of code duplication. Adding a rangeset pointer to "struct
> kernel_info" has a much smaller diffstat, and then we avoid the need to
> parse the partial device tree a second time.
> 
> I discovered this issue when booting a dom0less domU with a device
> passed through. Partial device tree excerpt:
> 
>     passthrough {
>         ...  ...
> 
>         axi_uart16550_0: serial@a0001000 {
>             clocks = <&uart_fixed_clk>;
>             compatible = "ns16550a";
>             interrupt-parent = <&gic>;
>             interrupts = <0 89 4>;
>             reg = <0x0 0xa0001000 0x0 0x1000>;
>             reg-shift = <2>;
> 
>             xen,reg = <0x0 0xa0001000 0x00 0x1000 0x0 0xa0001000>;
>             xen,path = "/amba_pl@0/serial@a0000000";
>             xen,force-assign-without-iommu;
>         };
>     };
> 
> The domU was assigned an extended region overlapping with MMIO of the
> passed through device:
> 
> (XEN) d1: extended region 0: 0xa0000000->0x100000000
> (XEN) d1: extended region 1: 0x200000000->0xf000000000
> 
> The domU panicked when attempting to initialize the device:
> 
> [    3.490068] a0001000.serial: ttyS0 at MMIO 0xa0001000 (irq = 15, base_baud = 6249375) is a 16550A
> [    3.498843] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
> [    3.498853] Mem abort info:
> [    3.498855]   ESR = 0x0000000096000044
> [    3.498859]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    3.498864]   SET = 0, FnV = 0
> [    3.498867]   EA = 0, S1PTW = 0
> [    3.498870]   FSC = 0x04: level 0 translation fault
> [    3.498874] Data abort info:
> [    3.498876]   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
> [    3.498879]   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
> [    3.498884]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [    3.498888] [0000000000000010] user address but active_mm is swapper
> [    3.498894] Internal error: Oops: 0000000096000044 [#1] SMP
> [    3.498899] Modules linked in:
> [    3.498908] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.10-stew #1
> [    3.498917] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [    3.498924] pc : mem_serial_out+0x18/0x20
> [    3.498936] lr : serial8250_do_set_mctrl+0x6c/0xc0
> [    3.498943] sp : ffff800081bab6d0
> [    3.498946] x29: ffff800081bab6d0 x28: ffff8000815e0dc8 x27: ffff000001c29c60
> [    3.498957] x26: 0000000000000000 x25: ffff00000347b900 x24: ffff000005504c00
> [    3.498968] x23: ffff00000347b800 x22: 0000000000000000 x21: ffff800081b69d78
> [    3.498978] x20: ffff800081b69d78 x19: 0000000000000000 x18: ffffffffffffffff
> [    3.498989] x17: 3d20647561625f65 x16: 736162202c353120 x15: 3d20717269282030
> [    3.498999] x14: 3030313030306178 x13: ffff800081a21ff0 x12: 00000000000007fe
> [    3.499010] x11: 00000000000002aa x10: ffff800081a4dff0 x9 : ffff800081a21ff0
> [    3.499020] x8 : 00000000fffff7ff x7 : ffff800081a4dff0 x6 : 0000000000000008
> [    3.499030] x5 : 0000000000000000 x4 : ffff800080797584 x3 : 0000000000000002
> [    3.499040] x2 : 0000000000000000 x1 : 0000000000000010 x0 : 0000000000000000
> [    3.499050] Call trace:
> [    3.499053]  mem_serial_out+0x18/0x20
> [    3.499059]  serial8250_set_mctrl+0x34/0x40
> [    3.499065]  serial_core_register_port+0x534/0x7dc
> [    3.499075]  serial_ctrl_register_port+0x10/0x1c
> [    3.499084]  uart_add_one_port+0x10/0x1c
> [    3.499092]  serial8250_register_8250_port+0x308/0x4c0
> [    3.499102]  of_platform_serial_probe+0x2c4/0x48c
> [    3.499110]  platform_probe+0x68/0xdc
> [    3.499120]  really_probe+0xbc/0x298
> [    3.499128]  __driver_probe_device+0x78/0x12c
> [    3.499135]  driver_probe_device+0xdc/0x160
> [    3.499142]  __driver_attach+0x94/0x19c
> [    3.499149]  bus_for_each_dev+0x74/0xd0
> [    3.499155]  driver_attach+0x24/0x30
> [    3.499162]  bus_add_driver+0xe4/0x208
> [    3.499168]  driver_register+0x60/0x128
> [    3.499176]  __platform_driver_register+0x24/0x30
> [    3.499184]  of_platform_serial_driver_init+0x1c/0x28
> [    3.499192]  do_one_initcall+0x6c/0x1b0
> [    3.499199]  kernel_init_freeable+0x178/0x258
> [    3.499209]  kernel_init+0x20/0x1d0
> [    3.499218]  ret_from_fork+0x10/0x20
> [    3.499228] Code: f9400800 1ac32021 8b21c001 d50332bf (39000022)
> [    3.499233] ---[ end trace 0000000000000000 ]---
> [    3.499237] note: swapper/0[1] exited with irqs disabled
> [    3.499247] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [    3.499251] SMP: stopping secondary CPUs
> [    3.499284] Kernel Offset: disabled
> [    3.499286] CPU features: 0x00,00000080,00200000,0200420b
> [    3.499292] Memory Limit: none
> [    3.792412] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> ---
>  xen/arch/arm/dom0less-build.c     | 19 ++++++++++++++++++-
>  xen/arch/arm/domain_build.c       | 13 ++++++++++++-
>  xen/arch/arm/include/asm/kernel.h |  1 +
>  3 files changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index a356fc94fc4d..23178a801818 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -274,6 +274,14 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>      int res;
>      paddr_t mstart, size, gstart;
>  
> +    if ( !kinfo->xen_reg_assigned )
> +    {
> +        kinfo->xen_reg_assigned = rangeset_new(NULL, NULL, 0);
> +
> +        if ( !kinfo->xen_reg_assigned )
> +            return -ENOMEM;
> +    }
> +
>      /* xen,reg specifies where to map the MMIO region */
>      cell = (const __be32 *)xen_reg->data;
>      len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
> @@ -315,6 +323,11 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>                     mstart, gstart);
>              return -EFAULT;
>          }
> +
> +        res = rangeset_add_range(kinfo->xen_reg_assigned, PFN_DOWN(gstart),
> +                                 PFN_DOWN(gstart + size - 1));
> +        if ( res )
> +            return res;
>      }
>  
>      /*
> @@ -1006,7 +1019,11 @@ static int __init construct_domU(struct domain *d,
>  
>      domain_vcpu_affinity(d, node);
>  
> -    return alloc_xenstore_params(&kinfo);
> +    rc = alloc_xenstore_params(&kinfo);
> +
> +    rangeset_destroy(kinfo.xen_reg_assigned);
> +
> +    return rc;
>  }
>  
>  void __init create_domUs(void)
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 3dcdd7a8c46f..da7c7c000f1f 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1296,6 +1296,13 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>      if ( res )
>          goto out;
>  
> +    if ( kinfo->xen_reg_assigned )
> +    {
> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
> +        if ( res )
> +            goto out;
> +    }
> +
>      res = rangeset_report_ranges(mem_holes, 0,
>                                   PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
>                                   add_ext_regions, ext_regions);
> @@ -2329,7 +2336,11 @@ static int __init construct_dom0(struct domain *d)
>      if ( rc < 0 )
>          return rc;
>  
> -    return construct_hwdom(&kinfo, NULL);
> +    rc = construct_hwdom(&kinfo, NULL);
> +
> +    rangeset_destroy(kinfo.xen_reg_assigned);

handle_passthrough_prop is never called for the hardware domain


> +    return rc;
>  }
>  
>  int __init construct_hwdom(struct kernel_info *kinfo,
> diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
> index bdc96f4c18eb..b3c2d50e1e3d 100644
> --- a/xen/arch/arm/include/asm/kernel.h
> +++ b/xen/arch/arm/include/asm/kernel.h
> @@ -50,6 +50,7 @@ struct kernel_info {
>  #ifdef CONFIG_STATIC_SHM
>      struct shared_meminfo shm_mem;
>  #endif
> +    struct rangeset *xen_reg_assigned;
>  
>      /* kernel entry point */
>      paddr_t entry;
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Tue May 06 01:01:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 01:01:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976623.1363768 (Exim 4.92)
	(envelope-from )
	id 1uC6gj-0000H1-JZ; Tue, 06 May 2025 01:01:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976623.1363768; Tue, 06 May 2025 01:01: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 1uC6gj-0000Gk-Cx; Tue, 06 May 2025 01:01:37 +0000
Received: by outflank-mailman (input) for mailman id 976623;
 Tue, 06 May 2025 01:01:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC6gi-00082j-JA
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 01:01:36 +0000
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com
 [2607:f8b0:4864:20::b31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a65c2def-2a15-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 03:01:32 +0200 (CEST)
Received: by mail-yb1-xb31.google.com with SMTP id
 3f1490d57ef6-e7311e66a8eso4580548276.2; 
 Mon, 05 May 2025 18:01:32 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 3f1490d57ef6-e755e7a897asm2246589276.38.2025.05.05.18.01.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 05 May 2025 18:01: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" 
X-Inumbo-ID: a65c2def-2a15-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746493292; x=1747098092; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WM4J8FV6gyq4AK+rkDKf684ABmAyuMzt7lo4bEejKfk=;
        b=ZeJ27zmys/EnJaovfl2okNDwGuwRERmORRhIogDnM7DMlTTJXpwrVt8SQ5AT3ANSfL
         geFMr5GoJXyqKuO6XnzBzO15LNbeHw1lXhU5nvXPKuub+BSQpwJ0ZAEo7K6I1C5ajvZw
         yce+w6tQcJxmmAcWfIQzC4YFWRvChLjiTfZBZ3ZgfxWm0DsMU54zvSss5d0pgOV1G2Q0
         1qoyO5Vznlcbmhb/0Pn2RyC4+nNjCDwIO320B9KF6YPWHF/O79FxQ20t4cB1kw5Loai4
         E7gqXj5ZORQh5+3nznebnmKDGHHGys6BUaZIONq1c0uBloBvCWtBZnwL4Rtwq5U3LW3J
         ROlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746493292; x=1747098092;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=WM4J8FV6gyq4AK+rkDKf684ABmAyuMzt7lo4bEejKfk=;
        b=jAf9nI8olvc9OzZqGv/HudnFa4iBu2vnVAnAxbx+0oqyDCVyls+bSfJqNx4yPDORr5
         IW5JD67Rfr4dJw7FMjeaXIIoVVzw5/kDmQQSNZ0+/tnI1451Kwd6nO7oi1lw3YdG1cIL
         /9R2NIpmuIUjjI8iuHyJw3/nbqrYQSdoCtVohJRCVTj/gror/5mKDZRswhG0x3jE/yDv
         KkrxooKWUBLn5ptKN1hNjnzONpuDZm/8DHkE32U4KaB1c58Va4g/K2gAu/ftU+3zzOVt
         afBW2v2vOSkUlowoheujZ6GV+Igneo6MUvDrKKhGCdgSfEIxc4YeMOUYdDhKo9GNR9ks
         iShw==
X-Forwarded-Encrypted: i=1; AJvYcCXrdoRNEGBTYHSnkeBhgU/P0Bd4dww+lyxdvWYmPmQyMyd+UQoRgmFqYjT4Npp7DRSaFkJJHbV+BNamkAEqO6KW5g==@lists.xenproject.org, AJvYcCXwxR2gkHIh0MOfc5m9yx+lWI/o6J75zbmkzaLacFddiAX+i51gQUxxINh92OGe+zbvlEbHlMFd5NP4@lists.xenproject.org
X-Gm-Message-State: AOJu0YxsMua9BwHfS/DUetNRPExsple5sTW8zPyhjX3qiVHt3HtZlOYJ
	vnER++kYH81kMXcANxLVEjnZ/T7LXVady80sLDWQNOuLVHHk5zSf
X-Gm-Gg: ASbGncujTi4DqqeDkJixkYCHD+h4mY5AeLUsJMO3P6WF89DUnlJXNYL0ggPbg0uxDGU
	Lq7rhI5kUXNaJcZw+r8dOXJ3GKyPgZr9YYi8YDK3tai5/oeaOD4iPyp5kKoUs8uh2jXEuLeQyLb
	Tap0Db4McpInzADTAzwXpnuKotsrVO7Bu2KRfYjrIRWA8llcJ2QclnPQRLJHRsQKy74PXk3ruEC
	l6OSst5NwvS6Smystw3J5nRzWrvS/becz4t5ks0/DS7rvZpmRCBVHjGhO0KAoJ3gtN3EMkbqNVK
	foHzA+DnTN6U/YX1/0fKqkW9l1sunSPu+lpwzI5uvjG8
X-Google-Smtp-Source: AGHT+IFAamOxm/074Tvy3tfOq0HdSlXrgszcw7KOPX63SmvS9pO5Zt8NhY3qEb2mM4B+V/V9rImWdw==
X-Received: by 2002:a05:6902:2407:b0:e6d:e183:4e08 with SMTP id 3f1490d57ef6-e757d0e3682mr12639915276.15.1746493291506;
        Mon, 05 May 2025 18:01:31 -0700 (PDT)
Message-ID: <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
Date: Mon, 5 May 2025 21:02:13 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Alejandro Vallejo ,
 Xen developer discussion 
Cc: Andrew Cooper , Juergen Gross
 , Xen-devel 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: Mapping memory into a domain
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------ah0X3k68B70IJduvbItfinLt"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------ah0X3k68B70IJduvbItfinLt
Content-Type: multipart/mixed; boundary="------------mTO4jB3vYlxKp0lVm9wTy0Du";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Alejandro Vallejo ,
 Xen developer discussion 
Cc: Andrew Cooper , Juergen Gross
 , Xen-devel 
Message-ID: <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
Subject: Re: Mapping memory into a domain
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
In-Reply-To: 
Autocrypt-Gossip: 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==

--------------mTO4jB3vYlxKp0lVm9wTy0Du
Content-Type: multipart/mixed; boundary="------------JujrRTYXEcyz1adxuM9xUYnF"

--------------JujrRTYXEcyz1adxuM9xUYnF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/5/25 7:32 AM, Alejandro Vallejo wrote:
> I suppose this is still about multiplexing the GPU driver the way we
> last discussed at Xen Summit?
>=20
> On Mon May 5, 2025 at 12:51 AM CEST, Demi Marie Obenour wrote:
>> What are the appropriate Xen internal functions for:
>>
>> 1. Turning a PFN into an MFN?
>> 2. Mapping an MFN into a guest?
>> 3. Unmapping that MFN from a guest?
>=20
> The p2m is the single source of truth about such mappings.
>=20
> This is all racy business. You want to keep the p2m lock for the full
> duration of whatever operation you wish do, or you risk another CPU
> taking it and pulling the rug under your feet at the most inconvenient
> time.
>=20
> In general all this faff is hidden under way too many layers beneath
> copy_{to,from}_guest(). Other p2m manipulation high-level constructs
> that might do interesting things worth looking at may be {map,unmap}_mm=
io_region()
>=20
> Note that not every pfn has an associated mfn. Not even every valid pfn=

> has necessarily an associated mfn (there's pod). And all of this is
> volatile business in the presence of a baloon driver or vPCI placing
> mmio windows over guest memory.

Can I check that POD is not in use? =20

> In general anything up this alley would need a cohesive pair for
> map/unmap and a credible plan for concurrency and how it's all handled
> in conjunction with other bits that touch the p2m.

Is taking the p2m lock for the entire operation a reasonable approach
for concurrency?  Will this cause too much lock contention?

>> The first patch I am going to send with this information is a document=
ation
>> patch so that others do not need to figure this out for themselves.
>> I remember being unsure even after looking through the source code, wh=
ich
>> is why I am asking here.
>=20
> That's not surprising. There's per-arch stuff, per-p2mtype stuff,
> per-guesttype stuff. Plus madness like on-demand memory. It's no wonder=

> such helpers don't exist and the general manipulations are hard to
> explain.

Is this a task that is only suitable for someone who has several years
experience working on Xen, or is it something that would make sense for
someone who is less experienced?
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------JujrRTYXEcyz1adxuM9xUYnF
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------JujrRTYXEcyz1adxuM9xUYnF--

--------------mTO4jB3vYlxKp0lVm9wTy0Du--

--------------ah0X3k68B70IJduvbItfinLt
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgZX5cACgkQszaHOrMp
8lMVahAApzeVWp2BiKuVP7DnHs1FM7FrjKCejl3AqN6FYvPSDs8xhmjShQYQ9KYQ
g2oKKDu6DnOFG2p/LfbTY0C0qfjQX1Agml8RR+5+gkYgrJLl7ZJowbv3K3/+dtCd
XfTkUDUI0Ji5+NVhuPmkMYtH+fKdrBn3abWsPU0hfsYEHU/bSn8T3D0+/x1TGsUx
IRB4Es4u7d58bD25lv6XXx5Znghb243Lwv6L14GilqExoyPH3QXRSnWi1HVewtrZ
/4PUzqtcjJ92ikmCbm/gER4KcLWTqSGz49Ofh0m2uhGGgOJ6vm45HS8J8sBIampT
DVFCcRHVuP+B11i59FaDs3OOQ9OtZ0TbuGCk24WGJ4NV3xPHJtKKecLnRLX8XIsq
/QS/cFYzE5BwcyfrwXVeltSv/vHoKSdiLBjAT0olByyO9fnxYktBZUPjQrphBkvH
BRnepIChC/4C/Fyl9VRy27jipTkBe23upuURStnUITYt4bJPIrHP+tJC6A9ZFsHA
re2iuzlOjJyJlvoFC7jXUqXDlSuuIwmspTGX1L1zMSzN7Md5C/8uvylDrDkxnOrb
vgLl58YbnNmHFidiYCNePCoy6pV3/nvhTPhNYNj9uvQVQbdwG+QYe/9ZHYJwT3PA
VCVbGy0zEOpPXGAjp/8whEKnkmSa1c52R8PVdHPAaqmAhc/G1Ko=
=f3mi
-----END PGP SIGNATURE-----

--------------ah0X3k68B70IJduvbItfinLt--


From xen-devel-bounces@lists.xenproject.org Tue May 06 05:33:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 05:33:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976650.1363813 (Exim 4.92)
	(envelope-from )
	id 1uCAvo-0002sv-AK; Tue, 06 May 2025 05:33:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976650.1363813; Tue, 06 May 2025 05:33: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 1uCAvo-0002so-6Q; Tue, 06 May 2025 05:33:28 +0000
Received: by outflank-mailman (input) for mailman id 976650;
 Tue, 06 May 2025 05:33:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCAvn-0002si-FQ
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 05:33:27 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20607.outbound.protection.outlook.com
 [2a01:111:f403:2408::607])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a18e5d37-2a3b-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 07:33:25 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 MW6PR12MB8959.namprd12.prod.outlook.com (2603:10b6:303:23c::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.20; Tue, 6 May
 2025 05:33:16 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 05:33: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" 
X-Inumbo-ID: a18e5d37-2a3b-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UqKSXRaXu32Bt3HpfWv6tRroQcGtheHlxPcrbwyhSZ66K94pzsYg/5vE/45I5Z2l9RWP5lklK+eWf6+khmLU/Oc8MLAELdRCjcvNJwC8VDiBwmPpJoc9fxcn+g3vv27GR3bhlW7VNwyMwVsmp5q0WeuPFnX31l2fBHqxw25zTupFzwr5PIrlzrpTz0EXEAbCg9wVMxJ8m30NUSK8Ewq2FUrJP+/FYZhubD2/oK21B1aBopluJrznsvWtd6Efo47W24lWsrBGJzkGUbSVg/bDRb0dj7BGBxtVYVLR7HtnYyN8/HIB9XcyfMzpD5SPwdqiQjvou3pFq4wtWc1mZVaoww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NgH5atrwI9S1LyAVIiw6U2HammoJaq3frSdF73xa3DI=;
 b=eXe0YDunfu5CF2JTiQ0r68ZyORktqKV426FhlXZD0PasxpzU/bz4kw4U4w3ZLzdJ4EdY4JOrUJvBNIs/eqv6FFYXCvoHzedNO24hGt4HXiAm1Y/r5Gp0f22GK+eTSNvByTtEXkjtRQF7HVkucvUsT3Rl7zZYPfpUqj3muPVb4ShU6MZ/XTWj+8h2Be11v3uVn1uyqYPzDJ/xovvXe1R3PCp+gwY8pD/LteqqsiNMxxReTZ/E6IQwwDLX2oR/3ynv+tADOUBSvOD/9eTGF+fg15ufKseRw7YOT3hT4OWSWr+P+0FpcbJt0GYgFvaHAsa6Qttx4cyTUCxmy/Vd70DoaQ==
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=NgH5atrwI9S1LyAVIiw6U2HammoJaq3frSdF73xa3DI=;
 b=kKOP4R/uzMx1ySQAa9hx/Sypu6KJ5N3LLRpeDnteH85Xdpsan/OtXs1GEvMuM1GgfIonHFpcUxBddmI+Yu5eQKlDaEBKpWHjwW+hDPJ2XXqkwN5SZuaFe4cOpjhbtF/f+L4N9vPpUN8Aho8dqNGP+U6sqsZOG4xyVIxAon5O1Kg=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 01/15] xen/cpufreq: move "init" flag into common
 structure
Thread-Topic: [PATCH v4 01/15] xen/cpufreq: move "init" flag into common
 structure
Thread-Index: AQHbrRCfHxxYxeWsPkK2Iot0Lv1PhrOn/B0AgB05whA=
Date: Tue, 6 May 2025 05:33:16 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-2-Penny.Zheng@amd.com>
 <26067708-2854-4493-8801-d0fb709242d0@suse.com>
In-Reply-To: <26067708-2854-4493-8801-d0fb709242d0@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=53968fb7-d563-4c53-bc82-a3b08ce75bf2;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-06T05:32:58Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|MW6PR12MB8959:EE_
x-ms-office365-filtering-correlation-id: 7179fecb-f9d9-4335-ee52-08dd8c5f8086
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?Tmo5NkVYdkViN1REQldBbXczZy9WOTFWSnh5L3FUNzdXUDAxaG9ZVW93U1ZC?=
 =?utf-8?B?RUNVU0ROWVlxOVlzR05oQitIbmdFZmVod01XQ0VmdVNDbm43ZUUzY2lSSmJE?=
 =?utf-8?B?WmFicHhWY3NiY1dVeHdaM0NpaUJaSmFFWnljeEhtLzQxTm4rZU4yME1LNmJU?=
 =?utf-8?B?aElsUVlEMWpnSGU3SEhsSkxuOXdzakJJcnZOdkNabkJrdEV1TmMyQlFOMU5v?=
 =?utf-8?B?L0F1NDBtajdwRERMQ3FjcWp1d0FFUVNvQUtoSTYrc2V5OHo0MkFCaXlwUU8z?=
 =?utf-8?B?K2NvcjFiWE1oSjIzL29UQlM0d1NGRGpPWmVxOC84blpNMkVlNjZ4L1hsSGFW?=
 =?utf-8?B?MHFtZ0FYUzZKTTdWZlVSM29COEVRcE12NmxyMzlHeFN0Q2pKcTFLbDhvWUZJ?=
 =?utf-8?B?dEJuM0FqaHVGOHpzUnhkcGwzZDVJVjVWUURZaWJSNlY5Q3haVjZSY2RBY3ZM?=
 =?utf-8?B?NGFuUkdLL1RDdS8vU0NoeWlRYWo1c3oyZnJLV01YTEFDSmdIOTRaUkdCZTQr?=
 =?utf-8?B?amNWN0t2R2haajM3LzNOWDhhWFE1Z3hNZERNaDZiM05CRzZRcTZvOEMzTE1C?=
 =?utf-8?B?QXdJdWpyNjVoRzJkNG1VRjZ6cUhtdjY5RDROT1dQMU9IbUx4UjdCUTVzLy8w?=
 =?utf-8?B?RStreE5oczBpMlh1eEVLQjVmcXoxOFhrdjVsbjRZVlBTVFJDWDh2aWFseGE2?=
 =?utf-8?B?QlpWZTFBRUZkY1h0bUdpdStSMXJMaGtsM3hMQ2R4VVBBbTRmTWJoeFdEck5B?=
 =?utf-8?B?clhEWjVjNjJKUW9QdHd6eUxRR3pBU1VrdTUvSmJTa3FNbm1iRFk2RFljWVE0?=
 =?utf-8?B?Mk1waVcwSTBiMUJHVVVFeGxvYkRlcG44OVpJS3VjV0kvcEJGOTJMcnNQQUV6?=
 =?utf-8?B?RHM2YTVtUkhwVFhQMVlXZmZtRGtIQTZYNFU4Q2RvMDdEWHFvNU1naHkyck96?=
 =?utf-8?B?ZXphU3AxT1REblhucXNQdDFuVGQrNnNwcFIxRTIxY0V0WkpRZEtFc0swSHR2?=
 =?utf-8?B?YVE0THlhVHh3clBFeFc4KzgzNnRmd0RJUlBNbGhtbUNGbGlQSHA0blVJM1pL?=
 =?utf-8?B?Z21Dbm1oeXFKZDdUUFdSODh2OHQ1RGg1Nk5ubHpjYTNPR05Hb0hLZGNyZm1l?=
 =?utf-8?B?K1ZHU2FRSFZWeEsvM251aWp3ZWJUalpncUxxYmlPaURiNEYrVHN3UGtsdWth?=
 =?utf-8?B?WDdrcUlZOFV5NUNLVVVZMkxCTEV0Y1loZ0xvK2J6UW00Y0ZTSkdLL2MzMXNm?=
 =?utf-8?B?U3owNG5QeEtFUEFFMzlWRnV4YVZUQkNlMW41a2VNMmpCZXlnYnFjWS80TFYr?=
 =?utf-8?B?RFMvdmpSM1VhNnI3d1NVaXF1VndYYTFPL2xNZVJxOEdtT1NEWXgvaW93d2NE?=
 =?utf-8?B?TXBFeXVocWZjak5taEd6bnNsWDV3V3h2N2swb2tlTm8zbCtjaHM1dzJYUmUw?=
 =?utf-8?B?OVlnNDZxc3ZaSk5pckp2a1pQZkdhMWVVK0htT2Q4TzlJbTRxSGxrREN4NW5B?=
 =?utf-8?B?V0NsK0d4OEFybVVYWWVoVkxlUXhEV09jM0gxOTBPRlNWTXE0RmNMN2Z2Q1F1?=
 =?utf-8?B?dm9COHZoRzJ4NHo3dFh0R2xGRW5OMklZUWp4eFBVMWxmQkFCMWNoQy9FS0xT?=
 =?utf-8?B?ckZ4VWVSekg5c0cxYzh5ckcwcndwNjdXWEN0ZzFiQ3FOeWRQcWxKYm4yVHYr?=
 =?utf-8?B?U2FXSUNzUzkvelhXZ0VWTzVxdzMyV0huOXBXb2g0elFHUEIwVVF5bW4yRHRD?=
 =?utf-8?B?cjdRa0EyTWdtMlNTZnFUSzNibUhlYzdPb0p6NGl6RlZDamFlQmFsRHFkV2E4?=
 =?utf-8?B?Mzg0Y0daeHB5NTBmTEtHZlg0VFE1OVBxTDA1YjJRRlB2eDBwbmc1dmV3NHln?=
 =?utf-8?B?cWhNV1BiNkk1SStNMmR5a3dRZEw4UzhweTAxSmE1YnJ0WWZxV2txV2ZRQnc5?=
 =?utf-8?B?NjdHaW1DMXJYYVhtMmZvTDN0UTFnd2IvUWMzMkkwdStqWVNUeVdXeHV2N2wy?=
 =?utf-8?Q?Z+pUQu4EP0/mmBTqEgQfpQntJwGGRM=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?amxkM29sbWRubFFFN09RanB4c3o0VXVDdG9TS0l6M2hUVUZQTlJXNkhQYWQy?=
 =?utf-8?B?a1UzN09wMU5uMzVkOFQyaWxIY3cvZE1LY0hHTSt1cE1sYWlsbFB5UWhEdyt0?=
 =?utf-8?B?dG42YVRtNFhnTE5TdjR1eFFvelhsblVCZXZsNEZBWWk1NjY0dDhrNWlCdzNS?=
 =?utf-8?B?ZkczbWI3TnJtYVlFYmp5MUorTXp2ZGRnZWdVc3I4cm1DR05sL0oyTDhvZzBZ?=
 =?utf-8?B?MENYam5Tc2pnWllWdVFzTkRGWXBtekRyZzhHKzd4aGhhVy94S0M1SEhVMUpN?=
 =?utf-8?B?NjRVMnlEOTFEUGdNeTdNQUVGb3lpMjdJd0IyandHYXdkcmM5ZVVlNGZwWFRZ?=
 =?utf-8?B?dDJtMEkvRVVZbTVGTERpKzJPc01sL2dkU25nRUs0L3NBL0tVWXc3OWN4c1FZ?=
 =?utf-8?B?cGhOeklFWm40N0VNVUZTbjh4ZG9vRmlvcWRGUGh1YnlIWjJ6ZDRYWG5vNUI1?=
 =?utf-8?B?b1Rud3NpSlR3elNCRXB6T0RiWk9OaWRUdFEzalFPRUxqc1RvQVZnRnp3QmlO?=
 =?utf-8?B?R1BSbk14Y0xzQ3d1eHJMdHRzZHVPSWh6U3Y4WTl6UG5hTVM3WHVuR3RiOERW?=
 =?utf-8?B?UjhRMjdVK0FuRUptVWthZVVpWTNqM3NEZWdmOHJpb3ZocGpyRU5pbXdSREFo?=
 =?utf-8?B?VGV4dzhpb1hKNDNNZE1pYzFEWUllU0ZjWHdBTXFjSlB0T25OakdKWXdwa1lG?=
 =?utf-8?B?T3NxQ3FSRURXdVBYV0w4NmNLUlZsblVjSFFGaWdxWWJhZFJjUHdYUFROdHFp?=
 =?utf-8?B?WWJSQzgvcEtvZFF2eU1qVDgwc2VseUNxUDY3YmpFeXhIU1VyNmQydXRoS2dU?=
 =?utf-8?B?Y2pEWWlhbUM0bHJMNlVnSjlUcTBZR0FzRjNTdlV5amI1UVJZN3NsZG5ldThN?=
 =?utf-8?B?Z21JZmZFSG5kSmJadWNhZ2pzSGNuVVQyWkt1RjhGTmRlK3ZkV0xRRGhoZVJo?=
 =?utf-8?B?dDVScUJXT3EwQjlDaFAvaWNuNDhnTnU5L2ErNlRzb1h0dVBBVzBwS09TZk9U?=
 =?utf-8?B?RDYzS2NIKzhzVlNPVGJWdytob2lzVEFubElwNHU1QW5DaW5MSVo3QXZMTU9y?=
 =?utf-8?B?dkQ4cThleEIvVWp3VGJwVVJIc3hnWWoxb1R5TDgvdEJpdmp2MFZLS0tMNW93?=
 =?utf-8?B?eTFJeFNFUWpmNnZjMkwxWmtmZnREd1F4OGF1eHFNSXMzSFBEdVFVL0ZEdVMw?=
 =?utf-8?B?SEU4UmsyZ0FEbDc5UE03MGptL3cwbUYrWjlzRjh6SmQ3NDJ5RTlBcnVnTHpI?=
 =?utf-8?B?RUtVYjdqN1pxNWppcUJBd2FrZ3lwUjhHVlVDNHFrN0hCU0w5Qk9VV0pBd0s3?=
 =?utf-8?B?aTNjS1NRVm9HQjQ4Q2lXMk54Z3JldmlNczBMaFpwMy9pUHlWTzBidTkvTmtY?=
 =?utf-8?B?Z2tYeUZVTlFtLytvU0VVQklnK3l3WWhWRVY2bVdBSUlTb0JwbzEwZXJtVW5o?=
 =?utf-8?B?OUdtakI4RmM0Y1o3YTVnWHlYaVhxMjJlV3Yyb1VwbTA3K3VKbVZMSXZpTGIv?=
 =?utf-8?B?RzNOZERHRlhXMXExNytmRzFXWlBRV0NJL01BVlFXZmJWbDc5SXBvdk81bVM3?=
 =?utf-8?B?eERkempNTmFoVC96MExPa2dPVkJmU0xIYzc1TWtSV3MvSVNCT2ZKNGdhbVBD?=
 =?utf-8?B?ZTB3SUxLZitqcEhyNVNSZjVteTZSY09rcEIySmptLzR6cmpQQlZuYTY5Y3Yx?=
 =?utf-8?B?Q0pETGFLQWxSVEF5dTdlMkZzRWVwd0VSTmV5amx6YTM0WTRBTmxIanRkRDBH?=
 =?utf-8?B?ZVRuRHBYVFJ2dm1tZm45NGQ3N0JFOUpSNFN2cjZqY1NEVlA1UTBNV2pJYVYx?=
 =?utf-8?B?SkM2Z3Y2cnNaWDMzNVZsaDJ5bGptcy9ZbVhyNHVESmdnZWtRWE9HYXBDeGhV?=
 =?utf-8?B?cG5nejJXUG5LTGVySFNYZDA4L3VyV2ZXODBOV1JWZ3ljdTh1Z3RqWVB1OFQ1?=
 =?utf-8?B?TU9Kb2VuSm9WdUdGU3p0RmZ0dG1jWXBVMWxoaHNpWllORmYyaHBJaFJvcEp0?=
 =?utf-8?B?elR0ZUE1UCtKSGZiem9lVitxd1ZPWElzdUpiSzEwKzk3bTJqekZPbDYyOEFD?=
 =?utf-8?B?Zzc2bkduTnhicm03azJ1NlZQbGt0Ull6UHIxZ2tiNyt1TWI2ZGszTDBKcXNC?=
 =?utf-8?Q?2Myk=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7179fecb-f9d9-4335-ee52-08dd8c5f8086
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2025 05:33:16.2261
 (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: fu948eQGYvVGP8O5FcTdDINSh070ODVG/gT+SOEotTPArLrUGjp9NO5cEFbcUQERAgDiMq5MXzZMOwHvzPTDpw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8959

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwg
MTcsIDIwMjUgMTE6MTIgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNv
bT4NCj4gQ2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgeGVuLWRldmVsQGxpc3Rz
LnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjQgMDEvMTVdIHhlbi9jcHVm
cmVxOiBtb3ZlICJpbml0IiBmbGFnIGludG8gY29tbW9uIHN0cnVjdHVyZQ0KPg0KPiBPbiAxNC4w
NC4yMDI1IDA5OjQwLCBQZW5ueSBaaGVuZyB3cm90ZToNCj4gPiBBTUQgY3B1ZnJlcSBjb3JlcyB3
aWxsIGJlIGludGlhbGl6ZWQgaW4gdHdvIG1vZGVzLCBsZWdhY3kgUC1zdGF0ZQ0KPiA+IG1vZGUs
IGFuZCBDUFBDIG1vZGUuIFNvICJpbml0IiBmbGFnIHNoYWxsIGJlIGV4dHJhY3RlZCBmcm9tIHNw
ZWNpZmljDQo+ID4gInN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmYiLCBhbmQgcGxhY2VkIGluIHRo
ZSBjb21tb24gInN0cnVjdA0KPiA+IHByb2Nlc3Nvcl9wbWluZm8iLg0KPg0KPiBUaGUgY29kZSBj
aGFuZ2UgaXMgY2VydGFpbmx5IGFjY2VwdGFibGUsIGFzIGJlaW5nIGxhcmdlbHkgbWVjaGFuaWNh
bC4NCj4gSG93ZXZlciwgdGhlIGFib3ZlIGRvZXNuJ3QgZXhwbGFpbiBfd2h5XyB3ZSBuZWVkIHRo
YXQgY2hhbmdlLiBUaGVyZSdzDQo+IHByb2JhYmx5IGEgbGl0dGxlIG1vcmUgY29ubmVjdGlvbiB0
aGF0IG5lZWRzIG1ha2luZyBiZXR3ZWVuIHRoYXQncyB0aGVyZSBhbmQgd2hhdA0KPiB5b3UgbWVh
biB0byBhZGQuDQo+DQoNCkhvdyBhYm91dCBjb21wbGVtZW50IHRoZSBmb2xsb3dpbmcgZGVzY3Jp
cHRpb246DQpgYGANCk90aGVyd2lzZSwgbGF0ZXIgd2hlbiBpbnRyb2R1Y2luZyBuZXcgc3ViLWh5
cGVyY2FsbA0KdG8gcHJvcGFnYXRlIENQUEMgZGF0YSBpbiBjb21taXQgInhlbi94ODY6IGludHJv
ZHVjZSBuZXcgc3ViLWh5cGVyY2FsbCB0bw0KcHJvcGFnYXRlIENQUEMgZGF0YSIsIHdlIG5lZWQg
dG8gcGFzcyBpcnJlbGV2YW50IHB4LXNwZWNpZmljDQoic3RydWN0IHhlbl9wcm9jZXNzb3JfcGVy
ZiIgaW4gc2V0X2NwcGNfcG1pbmZvKCkgdG8ganVzdCBzZXQgaW5pdCBmbGFnLg0KYGBgDQoNCj4g
SmFuDQo=


From xen-devel-bounces@lists.xenproject.org Tue May 06 05:57:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 05:57:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976666.1363823 (Exim 4.92)
	(envelope-from )
	id 1uCBIf-0005qE-4d; Tue, 06 May 2025 05:57:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976666.1363823; Tue, 06 May 2025 05:57: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 1uCBIf-0005q6-1n; Tue, 06 May 2025 05:57:05 +0000
Received: by outflank-mailman (input) for mailman id 976666;
 Tue, 06 May 2025 05:57:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCBId-0005px-Sq
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 05:57:03 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2062a.outbound.protection.outlook.com
 [2a01:111:f403:200a::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id edb0662c-2a3e-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 07:57:02 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 PH7PR12MB7236.namprd12.prod.outlook.com (2603:10b6:510:207::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Tue, 6 May
 2025 05:56:53 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 05:56: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" 
X-Inumbo-ID: edb0662c-2a3e-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GUY/UTHb4nVEXSkyeDqEpuEGfSW06l+0kGqWquyWVeYELp5NUpHsK+XUJ5c427eXRvZ7NEQ1rFpU5K/ScIpvcjmjjFOavTt2ywNOqBDUfeZKKzbScW1zQGpYjTDlboAU8XF09XHZ3StFH5Bp6QTHZ5qnjYGTIwS3oPUuNet7QT8I76syvc5eiTh+GYDHbbXoiKoN0UfPOa5Nn8gydPnd0eAetspEryUjKAyUWXDbChZxRkZGlC4MtohtV7fyZ0o0VfYqAdtrXsDC0QXhBai8DqVn2cl5TnkIbjb1v7oXcMYhcaXigGMjy/ucS8WGPgZ/KCaoyTfX+4QCtB/+OVCVhQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DUBl8Rnqs0qCWPJqYo6r4GSSt71kGKV1pI1VJVeKVAk=;
 b=e89YLewZcDoF1vSA32OgvxlES2NPAtyX3mpRqaW2WtzexOl4Ks61UO+mX1Y4tVoLNEJHbANLUtyj60wOqVLgny2knRxNKuZ8pb7x+qmGtb4FQj5LnupJlPo27+Vcqdgb06j2KEd/Pp5XDS8WLTM35iTqlIC6N/qFv/uVq5v2fYpF4rJa8rHbQ9kH9TjzwvkTKEMCpSetzPHigdQo4nQy3KfcoKBM6Ed1JdGLf4oeVL6A9SUZkD6bKfYXqStuonSaoDKmJV9HPhMbfRDZXcrkTOMcBB5iSQ3Vcggp3c4rZ9XeZ96ay57YN/ekjK7uQGUZ3/N2xBvqVqYLMtDGxGrqeQ==
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=DUBl8Rnqs0qCWPJqYo6r4GSSt71kGKV1pI1VJVeKVAk=;
 b=Z1dSsogAZwl4qLDpo079o8/sGwtzHzl37d4EOBLTTrwlq9Alu1+eTIFz2o1wrfV8Wxz7yVS4ezn4FQBnmiuYa/Is5SUA+LcmdKliwss2iYDXqkFkE2ZWzCFMXAjSKx4LZl5Dn9cVHnSs2UllEb8ij+meJTn5wO9gFq9mLFocdeA=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Topic: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Index: AQHbrRCjQUXzVZg75kKZW3IeVU/v2LO5SzoAgAvud1A=
Date: Tue, 6 May 2025 05:56:52 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-3-Penny.Zheng@amd.com>
 <829e710d-d257-455a-b4fc-1746119609ef@suse.com>
In-Reply-To: <829e710d-d257-455a-b4fc-1746119609ef@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=45b0fe01-60a5-49de-bfe8-30ff36e8e4ae;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-06T05:56:44Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|PH7PR12MB7236:EE_
x-ms-office365-filtering-correlation-id: 9097dada-adc2-4c39-90eb-08dd8c62cc9d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?aUk0ckxUcHJ4RnVPV1RaM285S29Wc1YrTTBPcUVKcVpDYkRwU2NIVzZUS3lP?=
 =?utf-8?B?dVZZNy9PR0EyQ3c5ZHFWbGdydkVzUFNoWG9WTGxuT1A5R1NOSlBRaW1WOGhF?=
 =?utf-8?B?dnBwTXlacURadjRUeWFZQng1R1RRaFhqNGFpZkpTc1VZc0VTSEdtTGhvQ0lV?=
 =?utf-8?B?S1FaNmJBOS9haDkrYWVPS2d3NTFXWCt4dzN6YVdNQ1o3SUVtVUhOMm9BWWw1?=
 =?utf-8?B?dGVwRWhUWXhkT3RaKzNhK0JmY01CbEpCdGRTQk5RTFJwaFZKNXNOUGVONHMz?=
 =?utf-8?B?dytjSFV2MTV4NVBFakpWT0xsanFWQzRESSttd3I0LzlOV3RiU1BaRWlpc1pF?=
 =?utf-8?B?Y09KcVVnVHBTY09oRzlINHg1a3hUWEIzSGIyQ0lvZ0krZFJxckJyY1hVNXpK?=
 =?utf-8?B?NW54V0JlRHFRYlVmeDYzRkszdVpiRTdPSmJwYmlNcmVVTUEzZ1h4ZE16MjF4?=
 =?utf-8?B?YTZFeXFFcE83TDZOWHdscFFKQjZYcUlMaE84ZWNOd0gweWl0dy90Ulp5NjNy?=
 =?utf-8?B?b1Z4a3RMQlZqc2gvMVJuck9xMEYvSHNTVUxlYm1UOEt2bUxTUksweGZFNXhu?=
 =?utf-8?B?WE55QjRPM1ROaEJKTEl6NGRlcENPSFhLSnhVelBMM2VCOCtlZ3Jjb2doamF4?=
 =?utf-8?B?Mk5HU0VVckxyMmJ4N3Ard0s0UFZoRG1rb3YyMTIxSENIa2dHYTg5c3IzWkUz?=
 =?utf-8?B?d1lLb3F4dk1BQitIZ0VtNjZ6aTFMVnlFcFFUS1dwR21zVWRnRk80aEsveFdr?=
 =?utf-8?B?ZXRtU01Nb3BMYlBTV21wQUZyY2NFTUlxeGZGMVQ1KytHQUJQbmRQa3d2UXJo?=
 =?utf-8?B?Yy9VUW9Sd0NxZ2d1dlNoekhaejYvdDVBL0kzQ2kvQk9CdjN3dXhFbVlsVlNH?=
 =?utf-8?B?bjRvRktSbnFPOGdManUzQ2tWbFV2WFB3SW1XbEgzeVB6aktHK3pyOFRVNC9w?=
 =?utf-8?B?bVY4NHAyQUQ5SkxaOVVUTFpXNGo0bmtlajdzV0NzU0RhR0RhT3FlZ2lEaDI4?=
 =?utf-8?B?dWFwa3YxdDZxYURoU1hTRnBDYXE1alduU2Q0TWs1OW5NTjZPV3oyOWNocENJ?=
 =?utf-8?B?cGlHTFc0MkRyWE11Q3Z6MS9JNUs0d3VsR1M1OFFjekNsazdJMVdpS2dXV2lp?=
 =?utf-8?B?WVZzc1FzazU2Wlh5aEw3YjNWakdLWHlacno3dFl2emF4R0NmVEhnSmZwSDIx?=
 =?utf-8?B?LzBVd1JQZVdqWVJIV1BEMUtQbi9iK2dHNWhXOGNwU2pHR3VBdjR4NTVYZm8x?=
 =?utf-8?B?Yy8vWVJicUE2SjlZTmtFcEhxNnhaSndYZmpxcHFNdVZWNXRKM0RXRWZyK2tR?=
 =?utf-8?B?Y3pyNkNVZHhTUmhtd1FOelJEbDV4dDR5QXVvU1dYcUc5dmtyS1pIdEE0ajBi?=
 =?utf-8?B?ZkovRTJwUnB4NlN3N0tBWWRBZ0VGdlhiNzlPYXMxOE9Hb2h0QS9RTTFEaWsz?=
 =?utf-8?B?eDZwS3JrLzNINmhhZXFlMGlQTlRiNGFpYUR1U1lOSXlQa3pvNXlJdGR6c2ow?=
 =?utf-8?B?ZXJCaW9wMXFBVmVtTVczQlRETi9DLzdPempHSWFlWTB0bVd6NjVYSHY4cUlO?=
 =?utf-8?B?VERzZFlhampZVzlKVXVPT3hOb1N3eFlNVnNHbWZaWlFpZFQxYW5QTVRxUVBL?=
 =?utf-8?B?Q20zenZtVnAycDU1ZWVKYnkxR0hIU21aUlpqVHFMMnB3YlhsU1hLMm9nVXhl?=
 =?utf-8?B?cWt1Mk9Ebmh1Mk0vVzYxM0NRc3YzTkFPblRqUGF1VFZwTGdqQUZHbUxadnZm?=
 =?utf-8?B?VHlRMHJUTXQ4cUo2UEIzeUNSbklITFB6TnlscDExbG1Wa1o5cXlYMnZnL2Iv?=
 =?utf-8?B?TEtmUTRaMFpCNU5BTjlQNnNWaWIvc1MzOXBNdDd0WXBSd3hvVmt0Ni93MGc5?=
 =?utf-8?B?K05lTFpyekZld2ZpbS9xTE9vVmw1Z3cwbU9pbm1weWhNVnprNG4vbG5waEhG?=
 =?utf-8?B?dU01SEF0dHd1ZVFIazZ5c2pKUCtsUVpCbzhVUVplYnFxWFdySDczYnA0Mm1O?=
 =?utf-8?Q?1KN0U9OeFEi2S3hTzr2Le4QRNlduDs=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Q1NvbzZjenRIQVYxaDRQeEtSOXo1YVQyclovek82MCtNSUZBWDF3THZwaUFI?=
 =?utf-8?B?cUZLL21INVdLZ2RUUUJqa2xEL240SXJUY1VPYnVaR0x2TjJ0MzkyaFdKWTlJ?=
 =?utf-8?B?UlpackVZK0d5SHFDZHV0ZC84UGdsTGZlckkwQmYydEZ0Q2ErZ2tlSnY2cHVI?=
 =?utf-8?B?ZWdqZmlickFCN1IrZ2E4TDN0NFFXSlBiVXVLNDQ5WEVwdjM1M2pDTmQ0eSt0?=
 =?utf-8?B?aUtDK1c5MFBsT09GSzYrZXNYZFpnMEcrQmQ3bXJmOTF3NVZzTUhZcVp4N3ZP?=
 =?utf-8?B?WEhXRGE4SlJZTm9pczFiamZhNmJqNFlGczNtTGV0TDNDQ2lzL0VVMkVhaURE?=
 =?utf-8?B?eGx6aU01QnJlbVUwMjFSMGRWb1Y2WWF1WXlWOEtkTUxNYWwwN09iQzgvWEJo?=
 =?utf-8?B?MDFZWStvaEJTeFpTVklEN3BFMUVXTUhMNkpIYlVkRmZ1TDgyQWVlamhhNE5p?=
 =?utf-8?B?VENvYXdqNzNRaG5LZi9IOWZDNXRpM1gzUHZrb1BDNzl6dHRtZ2xTd3FlWkd3?=
 =?utf-8?B?SldwbGlVY20ycERHeUhac3BiWE5JL3VJdzZkMlFQL3dZdmVGeStpWnluUVY5?=
 =?utf-8?B?Q3FKMS9QTXN0VndvRG9tMWZ1aHpZNG90cmYrc3V4SnUyN2IwOVV2VklvNmQy?=
 =?utf-8?B?Mm53VmJuTGFYTWxwSFg4ejYxN2xNS1JzbXFUZ3RpcFg0d2JmUGx4UUkvNzht?=
 =?utf-8?B?RkYrWC85NU9lekpRb3AzZkxINDVJQ0l1K0YwUVMxTTJjZ1pZbVZPMGpsZ0c2?=
 =?utf-8?B?cUFCUzFUZi85UXhLMmlTTkd4bDBPVDBzNWZJcWU5amJDdThFek96WXBFcXpz?=
 =?utf-8?B?K3c5MFMxMHhxZU9GUEpXWnNRWWl5LzVrKzRuOC9ud0F0aDlwWVlGYlhaMG1k?=
 =?utf-8?B?RVUydHkwZGxaUXNCUExTUzRiWldIaGM1R2NGQlRSZkkraDRSTVl3TEFSTFlx?=
 =?utf-8?B?dUxsRmFsS0RMTWdEZkVZMFZzdHVRMGZidFI3OFpRRXdtMXUydEppT0JiRDdC?=
 =?utf-8?B?VU04L040M3U1eHVsM3IwL1Izc0UrNUY4N2YwN3J5Q29Kd1JtWEVjaTlremVN?=
 =?utf-8?B?VWkxT3EvRUF6OVpzbVZkQzJlVy8rS3RYZkYvam5BTW11QzduWmpsSjNuZjFi?=
 =?utf-8?B?WWpqelhKcng2TlJRUkVHQUJIc09OeEREYzNFWENwL3RyeUN2MGZsazh1cTR1?=
 =?utf-8?B?UmRDd0wwNEx6SHNRMzB6NVprU1R5ZGgyV0toZjIrTW9rdDF5dWQ0bEg4anE3?=
 =?utf-8?B?WnJtNmxqcmtobEx2UUV5YjI0UUlTM0lTZUY2dXRMT2FDNnJhZnM4eTVvYkla?=
 =?utf-8?B?emdHYytZa3Bhd0N5a05pZUNVTkRNcGlBcGQxRmVVVDZiK09Sa2ZoZGVWNDh2?=
 =?utf-8?B?dC9CS05mU3hQVndOeG5nckgrZGVmYVZCNzlXRlljWVMrd2x1R2dtR3kwUHZQ?=
 =?utf-8?B?TWpUUjBJVWM5SkpHR2Q4N3RMY0RMZlZienJ3cmdnYTU2MHRjT015UkhUZXdB?=
 =?utf-8?B?elBZejczS0p0a050SEJPZkxidG1VUVVTNHRVU3ZwamhrUlBTc3paSmxtQk55?=
 =?utf-8?B?SWtPMWpGVlVGWGtKQUV3MDZjUGxadkNINnNKQ0toRFZLK1FDNWNYQU9HRWRU?=
 =?utf-8?B?bHlpQm4xeEJoQ1R5cTdqcFlkbnVQcEdybWcwMUxUTHpKNm1QWmxlRFZjME1E?=
 =?utf-8?B?WDNTUXpCc3J6eXprZS8zc3dQVFlRWUFSVEI3VlorVlJRNVV0WE8wZWdrbEhu?=
 =?utf-8?B?N1d5aVY3Z3dNVUdVWVM3OUt5VjIvZ3hwUDhRdjFzaERqcmdicTRKdUtsSTcw?=
 =?utf-8?B?K21ZWkxjM3R3UXpQQ2h1bURSS1crc2JnV0ZaejBjNkpoRldIUDdWTm9vWkFr?=
 =?utf-8?B?aWJxdTBtQ2NDTlY1UjFHUExSa05XZEs5Rit5VUJEM1NaOU9kcDJHTm5XUDRr?=
 =?utf-8?B?YXVoZUJ4N3l1ZENCVlA2NU5HUHhuMnY2SDNjRWVvYy9jUnNoMERld1IxcXRV?=
 =?utf-8?B?aldlem1RWE1FdFU0Ry9mUmx6UllFTFZFWWg3QXJBWlVCYzRRUFJqUEptV05P?=
 =?utf-8?B?STVEWGlzcXJTSkkwSDZSc1ZCdXoxeDMyblY3NEhGUDN3S0wzMUhhcW9LOHJX?=
 =?utf-8?Q?uX8Y=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9097dada-adc2-4c39-90eb-08dd8c62cc9d
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2025 05:56:52.3764
 (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: 2CmLssPtb5iE8r57Ovf+SWqIrwIwgDI/MSbMneH0S5lRSLRi4pCnZEOlCeUjsEgGA3vvPYKxnX6dzDzt0Uq2Zw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7236

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBNb25kYXksIEFwcmlsIDI4
LCAyMDI1IDExOjMyIFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+
DQo+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4g
PGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJh
cmRAdmF0ZXMudGVjaD47DQo+IE9yemVsLCBNaWNoYWwgPE1pY2hhbC5PcnplbEBhbWQuY29tPjsg
SnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2VyDQo+IFBhdSBNb25uw6kgPHJvZ2Vy
LnBhdUBjaXRyaXguY29tPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwu
b3JnPjsNCj4geGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBb
UEFUQ0ggdjQgMDIvMTVdIHhlbi9jcHVmcmVxOiBleHRyYWN0IF9QU0QgaW5mbyBmcm9tICJzdHJ1
Y3QNCj4geGVuX3Byb2Nlc3Nvcl9wZXJmb3JtYW5jZSINCj4NCj4gT24gMTQuMDQuMjAyNSAwOTo0
MCwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4gLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL3BsYXRm
b3JtLmgNCj4gPiArKysgYi94ZW4vaW5jbHVkZS9wdWJsaWMvcGxhdGZvcm0uaA0KPiA+IEBAIC00
NDAsNiArNDQwLDExIEBAIHN0cnVjdCB4ZW5fcHNkX3BhY2thZ2Ugew0KPiA+ICAgICAgdWludDY0
X3QgbnVtX3Byb2Nlc3NvcnM7DQo+ID4gIH07DQo+ID4NCj4gPiArLyogQ29vcmRpbmF0aW9uIHR5
cGUgdmFsdWUgKi8NCj4gPiArI2RlZmluZSBYRU5fQ1BVUEVSRl9TSEFSRURfVFlQRV9IVyAgIDEg
LyogSFcgZG9lcyBuZWVkZWQNCj4gY29vcmRpbmF0aW9uICovDQo+ID4gKyNkZWZpbmUgWEVOX0NQ
VVBFUkZfU0hBUkVEX1RZUEVfQUxMICAyIC8qIEFsbCBkZXBlbmRlbnQgQ1BVcw0KPiBzaG91bGQN
Cj4gPiArc2V0IGZyZXEgKi8gI2RlZmluZSBYRU5fQ1BVUEVSRl9TSEFSRURfVFlQRV9BTlkgIDMg
LyogRnJlcSBjYW4gYmUNCj4gc2V0DQo+ID4gK2Zyb20gYW55IGRlcGVuZGVudCBDUFUgKi8NCj4g
PiArDQo+ID4gIHN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlIHsNCj4gPiAgICAgIHVp
bnQzMl90IGZsYWdzOyAgICAgLyogZmxhZyBmb3IgUHggc3ViIGluZm8gdHlwZSAqLw0KPiA+ICAg
ICAgdWludDMyX3QgcGxhdGZvcm1fbGltaXQ7ICAvKiBQbGF0Zm9ybSBsaW1pdGF0aW9uIG9uIGZy
ZXEgdXNhZ2UgKi8NCj4gPiBAQCAtNDQ5LDEwICs0NTQsNyBAQCBzdHJ1Y3QgeGVuX3Byb2Nlc3Nv
cl9wZXJmb3JtYW5jZSB7DQo+ID4gICAgICBYRU5fR1VFU1RfSEFORExFKHhlbl9wcm9jZXNzb3Jf
cHhfdCkgc3RhdGVzOw0KPiA+ICAgICAgc3RydWN0IHhlbl9wc2RfcGFja2FnZSBkb21haW5faW5m
bzsNCj4gPiAgICAgIC8qIENvb3JkaW5hdGlvbiB0eXBlIG9mIHRoaXMgcHJvY2Vzc29yICovDQo+
ID4gLSNkZWZpbmUgWEVOX0NQVVBFUkZfU0hBUkVEX1RZUEVfSFcgICAxIC8qIEhXIGRvZXMgbmVl
ZGVkDQo+IGNvb3JkaW5hdGlvbiAqLw0KPiA+IC0jZGVmaW5lIFhFTl9DUFVQRVJGX1NIQVJFRF9U
WVBFX0FMTCAgMiAvKiBBbGwgZGVwZW5kZW50IENQVXMNCj4gc2hvdWxkDQo+ID4gc2V0IGZyZXEg
Ki8gLSNkZWZpbmUgWEVOX0NQVVBFUkZfU0hBUkVEX1RZUEVfQU5ZICAzIC8qIEZyZXEgY2FuIGJl
IHNldA0KPiBmcm9tIGFueSBkZXBlbmRlbnQgQ1BVICovDQo+ID4gLSAgICB1aW50MzJfdCBzaGFy
ZWRfdHlwZTsNCj4gPiArICAgIHVpbnQzMl90IHNoYXJlZF90eXBlOyAvKiBYRU5fQ1BVUEVSRl9T
SEFSRURfVFlQRV94eHggKi8NCj4gPiAgfTsNCj4gPiAgdHlwZWRlZiBzdHJ1Y3QgeGVuX3Byb2Nl
c3Nvcl9wZXJmb3JtYW5jZSB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlX3Q7DQo+ID4gREVGSU5F
X1hFTl9HVUVTVF9IQU5ETEUoeGVuX3Byb2Nlc3Nvcl9wZXJmb3JtYW5jZV90KTsNCj4NCj4gV2hh
dCdzIHRoaXMgbW92ZW1lbnQgYWJvdXQ/IEluIHRoZSBwdWJsaWMgaW50ZXJmYWNlIG5vdGhpbmcg
Y2hhbmdlcz8NCj4NCg0KQXMgd2Ugd2lsbCBoYXZlIHNoYXJlZCB0eXBlIGluICJzdHJ1Y3QgeGVu
X3Byb2Nlc3Nvcl9jcHBjIiB0b28sIG1heWJlIHRoZSBkZWZpbml0aW9uIHdvdWxkIGxpa2UgdG8g
bGl2ZQ0KYXQgbW9yZSBjb21tb24gcGxhY2UsIHRoZW4gaXQgY291bGQgYmUgc2hhcmVkPw0KTGl2
aW5nIGluc2lkZSAic3RydWN0IHhlbl9wcm9jZXNzb3JfcGVyZm9ybWFuY2UiIGxvb2tzIGxpa2Ug
aW50ZXJuYWwgdmFsdWVzIGZvciBpbnRlcm5hbCBmaWVsZC4NCklmIGl0IGJyZWFrcyB0aGUgcHVi
bGljIGludGVyZmFjZSBzb21lIHdheSwgSSdsbCBjaGFuZ2UgaXQgYmFjayBhbmQgZHVwbGljYXRl
IHRoZSBkZWZpbml0aW9uIGluICJzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9jcHBjIiB0b28NCg0KPiBK
YW4NCg==


From xen-devel-bounces@lists.xenproject.org Tue May 06 06:35:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 06:35:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976644.1363832 (Exim 4.92)
	(envelope-from )
	id 1uCBu3-0002k3-TB; Tue, 06 May 2025 06:35:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976644.1363832; Tue, 06 May 2025 06:35:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCBu3-0002jx-PT; Tue, 06 May 2025 06:35:43 +0000
Received: by outflank-mailman (input) for mailman id 976644;
 Tue, 06 May 2025 02:32:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC86o-0007B0-Al
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 02:32:38 +0000
Received: from smtpbgeu1.qq.com (smtpbgeu1.qq.com [52.59.177.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5b290666-2a22-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 04:32:31 +0200 (CEST)
Received: from localhost.localdomain ( [113.57.152.160])
 by bizesmtp.qq.com (ESMTP) with 
 id ; Tue, 06 May 2025 10:30:59 +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" 
X-Inumbo-ID: 5b290666-2a22-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniontech.com;
	s=onoh2408; t=1746498699;
	bh=RK8CB/ILucoxkojMLroxyaAqpj6rXkr8cb1h0tuO+FM=;
	h=From:To:Subject:Date:Message-ID:MIME-Version;
	b=kafLiDKXS816BmywaQFx+/F9Y6knLlHjegnJC8EOCpdTsnxr/e1yaY6y4wWVWU5Cc
	 pEmJcSIFvrEg1Nxq/uND+kyneyz+lm4cL848VLV2wWlvOab3SEPuOTkyOQdSj+ClQW
	 LZ+Ex6H0L9ikuOIyZud7Tr25Wd3PVQAdT9G4v3o8=
X-QQ-mid: esmtpsz17t1746498663t4c1b9905
X-QQ-Originating-IP: 2vhUXsJq6NqiLO1Htm0IxhFYAPx746WeA0MvTVyM9nk=
X-QQ-SSF: 0000000000000000000000000000000
X-QQ-GoodBg: 1
X-BIZMAIL-ID: 1353101163767275647
EX-QQ-RecipientCnt: 52
From: Chen Linxuan 
To: hch@lst.de
Cc: akpm@linux-foundation.org,
	alex.williamson@redhat.com,
	andreyknvl@gmail.com,
	axboe@kernel.dk,
	boqun.feng@gmail.com,
	boris.ostrovsky@oracle.com,
	bp@alien8.de,
	changbin.du@intel.com,
	chenlinxuan@uniontech.com,
	dave.hansen@linux.intel.com,
	dvyukov@google.com,
	hannes@cmpxchg.org,
	hpa@zytor.com,
	jackmanb@google.com,
	jarkko@kernel.org,
	jgg@ziepe.ca,
	jgross@suse.com,
	justinstitt@google.com,
	kasan-dev@googlegroups.com,
	kbusch@kernel.org,
	kevin.tian@intel.com,
	kvm@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	linux-kbuild@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,
	linux-nvme@lists.infradead.org,
	llvm@lists.linux.dev,
	masahiroy@kernel.org,
	mathieu.desnoyers@efficios.com,
	mhocko@suse.com,
	mingo@redhat.com,
	morbo@google.com,
	nathan@kernel.org,
	nick.desaulniers+lkml@gmail.com,
	nicolas.schier@linux.dev,
	paulmck@kernel.org,
	peterhuewe@gmx.de,
	peterz@infradead.org,
	sagi@grimberg.me,
	shameerali.kolothum.thodi@huawei.com,
	surenb@google.com,
	tglx@linutronix.de,
	torvalds@linux-foundation.org,
	vbabka@suse.cz,
	virtualization@lists.linux.dev,
	wentao@uniontech.com,
	x86@kernel.org,
	xen-devel@lists.xenproject.org,
	yishaih@nvidia.com,
	ziy@nvidia.com
Subject: Re: [PATCH RFC v3 0/8] kernel-hacking: introduce CONFIG_NO_AUTO_INLINE
Date: Tue,  6 May 2025 10:30:53 +0800
Message-ID: 
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250429123504.GA13093@lst.de>
References: <20250429123504.GA13093@lst.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-QQ-SENDSIZE: 520
Feedback-ID: esmtpsz:uniontech.com:qybglogicsvrgz:qybglogicsvrgz5a-1
X-QQ-XMAILINFO: MIXayioyWBZjdXIIg9vqEFEP1rndaeDbBxgcX+6TdOBY4fgPWBVGCH7p
	2JsHdKJTuNk6u8AM4q4ieHCa2JqpFTHWwRRL4JiA/mhRy6XEomq0Rcxy/vNg3zyQ8FVuKLk
	8u8FKj8M5lKtxCc/AqTb4cgg61ofZ0b0vrixlYN4JBF1kCxPgn8qobIDmHUgdW9IFOYw1+N
	NzCrUuumdTal59UvJXIVIFoyfA9UBsYY3QApHJufslFjIYbt35eMNpV5rvVKf1I/YYKCDNC
	P9yTyAZep/MN4DPY0aYU4VKEhzq4hfUEtrTG+yS8IFi8cu4WnxADpZzlhEfh6sgIPFr9D/5
	LAjp9zJsR/w/WJBlV0/AeccvTg2ivMv8/8ld0KRxxvkD56dIxmj6YXZNshVuONjuE0nJjBO
	/ZkGZ6luDwhjEO+vkDN/jlP28nAAeQhf+qskcK1/Y9pNoGKLQM3DBAIcozpo04ivN/6cYTB
	mj2nrsDyaK1C+tCjVrjTPZFIfhssizrE/gf8iGN1F7O/hmuxJwA/dK3NI1t8SeRqO7lQz4L
	B4hzjQne+6C9oeYpkB+VOOK9PsOSswtEhn02iTK5I9PQ+Ycv7ivq6ZY5n6oWMcqKlxPN7BO
	H5JnZY5xmDNSQq3b5Wuosg7tUvfTmTgSSX4FEIzlh0XnGAcc9uh0LsxhMPWJEoyR1zYtXT8
	wYAyFsEm6cQkmgHkhA1RIcJKVmauWeY1Ior96a9f1buQZB8VVfJt+WJbMtDmDfETYG5hNrJ
	v32eTkTlFFTYKKE7IcWnK/aaTY4CI/qOHh5uVSzxCPgXjhOLX3h3MBL7nZPgOYEiV7v/m1b
	LeNwKkEEMf/YAs1XwZqw6xD/OrRuB9gCzaDRun3T8Eq2tb0DK8XA3tPUX/869R/Ki7azM8P
	ztB3y+QhyBBY/ymt6WbrLX+aRWFcGEL38eFBGQtoKi2UIVz7HU4hJjuodhguJq7uPcST0KO
	L2QyrEpCbzrrs0aGqC9GCbTWQp+Bzf9NeEGo3iubNJE93+fc0YEPkQoz3WNGg0lh7Q8ZEbe
	a4N/7YW8KVwYAvMNJi3geZoASlc1w=
X-QQ-XMRINFO: NyFYKkN4Ny6FSmKK/uo/jdU=
X-QQ-RECHKSPAM: 0

On Tue, 29 Apr 2025 14:35:04 +0200 Christoph Hellwig wrote:

> On Tue, Apr 29, 2025 at 12:06:04PM +0800, Chen Linxuan via B4 Relay wrote:
>
> > This series introduces a new kernel configuration option NO_AUTO_INLINE,
> > which can be used to disable the automatic inlining of functions.
> >
> > This will allow the function tracer to trace more functions
> > because it only traces functions that the compiler has not inlined.
>
> This still feels like a bad idea because it is extremely fragile.

I'm not entirely sure if we're on the same page regarding this issue.
However, I'd like to address the concerns about the fragility of NO_AUTO_INLINE.

Maintaining NO_AUTO_INLINE to function correctly is indeed challenging,
and I share some reservations about whether it should exist as a Kbuild option,
which is precisely why this patch series is submitted as an RFC.
I cannot even guarantee that I've addressed all existing issues in the current
kernel repository with this patch series, as testing all possible compilation
configurations is beyond my capabilities.

Looking at the functions where I've added __always_inline in this patch series,
nearly all of them require inlining specifically because their calls need to be
resolved at compile time.

The fundamental source of this fragility stems from the fact that compiler
auto-inlining decisions aren't well-defined. If these functions were to change
in the future for unrelated reasons - for example, if they became longer - and
the compiler consequently decided not to automatically inline them, these same
issues would surface regardless.


From xen-devel-bounces@lists.xenproject.org Tue May 06 06:35:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 06:35:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976646.1363839 (Exim 4.92)
	(envelope-from )
	id 1uCBu4-0002ms-6S; Tue, 06 May 2025 06:35:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976646.1363839; Tue, 06 May 2025 06:35: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 1uCBu3-0002lp-W0; Tue, 06 May 2025 06:35:43 +0000
Received: by outflank-mailman (input) for mailman id 976646;
 Tue, 06 May 2025 02:41:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uC8FN-0008H2-0X
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 02:41:29 +0000
Received: from smtpbguseast1.qq.com (smtpbguseast1.qq.com [54.204.34.129])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 95b42aea-2a23-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 04:41:22 +0200 (CEST)
Received: from mail-yb1-f171.google.com ( [209.85.219.171])
 by bizesmtp.qq.com (ESMTP) with SMTP id 0
 for ; Tue, 06 May 2025 10:41:11 +0800 (CST)
Received: by mail-yb1-f171.google.com with SMTP id
 3f1490d57ef6-e6e1cd3f1c5so4199383276.0
 for ; Mon, 05 May 2025 19:41: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" 
X-Inumbo-ID: 95b42aea-2a23-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniontech.com;
	s=onoh2408; t=1746499275;
	bh=dDn4W5v9t6AyHBHxLWO7FuLjj98KbpZnLxWf1Zria3s=;
	h=MIME-Version:From:Date:Message-ID:Subject:To;
	b=n8r4R3u7gzqMxHc2aQ3peYjPOWOKjtBW9b6RgtRAJNk6dHbpxJUR6DPrZeBXWPSF+
	 GczkkIOhC7KbRR9T2Skwi+6r4ccDpcJQF645RYV3AIcSq6bm92mzpeTq02mh5qfw7h
	 qDLlodeU0Vqb3lAfPTGJoozZFJW/oNaQXlsuI5BE=
X-QQ-mid: esmtpsz17t1746499273t630b486b
X-QQ-Originating-IP: 4wO1RVpWYuRmz1iqaXDmgWdmyHXV9qrlyAfAABcWJFU=
X-QQ-SSF: 0000000000000000000000000000000
X-QQ-GoodBg: 0
X-BIZMAIL-ID: 17737050764760768362
X-Forwarded-Encrypted: i=1; AJvYcCUGXp1kBSkowvVxMJblx8erT58a8VX6M1MkWy+OEjoEi4Gel8nF2tKgs72C0MfkOXD9YWY4zwcr6/s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzebVtWAqvEUuTSIXBPIwaN+Hor+QOmLgd2pj8IHXdLZqgaJrQo
	AEp/wVU3qM0TZmbPzcN+tGyAtX/09yeKP+lG7saWO4QmnFDS626NmRJojwUgLltDzSAIXSjc+wM
	0yI1PAC08mBvQMuBIbrGNGKicwi4=
X-Google-Smtp-Source: AGHT+IFgFFlMacdloLtgDC8BYlif3b1M5uLk0pWcJg25Fujp9vccWuhfsfXobAggGBnTnNta+8cIxYeCcW4lzf1hqZQ=
X-Received: by 2002:a05:6902:1ac5:b0:e6d:f3ca:3e15 with SMTP id
 3f1490d57ef6-e75c08b698bmr1960395276.3.1746499270786; Mon, 05 May 2025
 19:41:10 -0700 (PDT)
MIME-Version: 1.0
References: <20250429-noautoinline-v3-0-4c49f28ea5b5@uniontech.com>
 <20250429123504.GA13093@lst.de> 
 <20250501150229.GU4439@noisy.programming.kicks-ass.net> 
 <08163d8b-4056-4b84-82a1-3dd553ee6468@acm.org>
In-Reply-To: <08163d8b-4056-4b84-82a1-3dd553ee6468@acm.org>
From: Chen Linxuan 
Date: Tue, 6 May 2025 10:40:59 +0800
X-Gmail-Original-Message-ID: <973B455678FC1BDD+CAC1kPDM2pUEwFRiUZFHKq_7sYpjARkFczJnp_FRu+r9-xYdgKg@mail.gmail.com>
X-Gm-Features: ATxdqUHhA0M6lhr1xavQzClQ8qzartLkG1qHh9aYbVlX-6LFgZ39KxjHPoTQnkI
Message-ID: 
Subject: Re: [PATCH RFC v3 0/8] kernel-hacking: introduce CONFIG_NO_AUTO_INLINE
To: Bart Van Assche 
Cc: Brendan Jackman , Peter Zijlstra , 
	Christoph Hellwig , chenlinxuan@uniontech.com, Keith Busch , 
	Jens Axboe , Sagi Grimberg , 
	Andrew Morton , Yishai Hadas , 
	Jason Gunthorpe , Shameer Kolothum , 
	Kevin Tian , Alex Williamson , 
	Peter Huewe , Jarkko Sakkinen , 
	Masahiro Yamada , Nathan Chancellor , 
	Nicolas Schier , 
	Nick Desaulniers , Bill Wendling , 
	Justin Stitt , Vlastimil Babka , 
	Suren Baghdasaryan , Michal Hocko , 
	Johannes Weiner , Zi Yan , 
	Mathieu Desnoyers , "Paul E. McKenney" , 
	Boqun Feng , Dmitry Vyukov , 
	Andrey Konovalov , Juergen Gross , 
	Boris Ostrovsky , Thomas Gleixner , 
	Ingo Molnar , Borislav Petkov , 
	Dave Hansen , x86@kernel.org, 
	"H. Peter Anvin" , linux-nvme@lists.infradead.org, 
	linux-kernel@vger.kernel.org, linux-mm@kvack.org, kvm@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-integrity@vger.kernel.org, 
	linux-kbuild@vger.kernel.org, llvm@lists.linux.dev, 
	Winston Wen , kasan-dev@googlegroups.com, 
	xen-devel@lists.xenproject.org, Changbin Du , 
	Linus Torvalds 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-QQ-SENDSIZE: 520
Feedback-ID: esmtpsz:uniontech.com:qybglogicsvrgz:qybglogicsvrgz5a-1
X-QQ-XMAILINFO: OH9BrnvZTfElGrk0Q+UcGL13NtIpBrfmPUi86ZY2KkfllqNFAYDgaUPV
	VZvCUUzOCij0nuQiYaPOgDiTD4unvG1IRatUdaoxL77lni/qTmQdoy/ziJTVvwQPRQCLSP+
	UWVPnBF3hxTykpaxkHQISpwNN5S4GTx8C/HvRPede4zDvdp40TBIg9pfQMQDoNOJQaYGIGu
	o9mbDBzIuiIVI/VXuY5xd+RH1iuWNUdibI0sAQh3as12Ue27r7JgCFBDeshb4L9pURKODNv
	OtK0AzvBPtoq/JyPjHBU9zjdJKALP6GXt7xfiueG03xs50BR8Mexq7F0rLNHMqmmW3z4mRS
	xLlB73rspaiZBp6Tj4IBXyG001C90qyMj43tdJlq/2W9VWzO1EeH0s27fOaVqibkhcVxgry
	o5v3McDa3EBRjZ7QJhHKbKpoa/0wCBvSKT1bs791DWg/NFzS6Hu32t8/a4kcIzArmC4NN5M
	pAxdaq2aOqOYn2JPEEMs67SsMKjaOeO2x821QgQ+UFr6I8pYG1fXU513x+NwPf0oqk2xXlx
	y+VhTq58W6Bv/QMwdP0F4yvqsfy/uyIU/ILOfYLMkxD91IDUU71/vdf6NKwinH1ek0sKbd6
	Z7HfMdFfLfrcl+l1gEKLMT5cUuB5urXgAg6sg5YqL68P5qa45mSB3REQ9p9lJrLQWFbrY/U
	tLQeqwpgzyDyszI+BvZvMAxbZAM1XPwxuVAfp21i1gnnp34nH9fFfMTldYimu6rH3ThdHkQ
	XFYC3jMDZb2a92TDn+bS8pW9xPAnUBRpwJGrJAFW0cS0a1ZJccTWlybYMDCK6kWzyIs/5SF
	sZHWdHNl3DB2TLuEkAXXWRFN4JYxaCxpCfjGBnJ9EYBEU2qbS8XoK1y3ZW3Ow6FUZgUy4PU
	UoDVD2kRdiJ0cYSKho3png0ZnlCZmPKM0QL76MibOc2eJ+9wF6wn4KJxIDtQfI0Hif+TTB4
	kukqkk3URjYZqLHuZSAznNm1UHfwaudBIVl+BTnrwV0di1n8e6Z1Sx7VKy+XuNUBceE+R0A
	X20OZ1qxKLut4syR/+OtozPCutGkj413SvYNnA8kOzU/VdUY3P
X-QQ-XMRINFO: NyFYKkN4Ny6FSmKK/uo/jdU=
X-QQ-RECHKSPAM: 0

On Sun, May 4, 2025 at 3:14=E2=80=AFAM Bart Van Assche =
 wrote:

> If this is for test builds only, has it been consider to add
> -fno-inline-functions as a local change in the top-level Makefile?

The issue here is that the current kernel cannot be compiled when
these compiler options that reduce inlining behavior are added.


From xen-devel-bounces@lists.xenproject.org Tue May 06 07:23:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 07:23:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976698.1363853 (Exim 4.92)
	(envelope-from )
	id 1uCCdl-0001Sr-D3; Tue, 06 May 2025 07:22:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976698.1363853; Tue, 06 May 2025 07:22: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 1uCCdl-0001Sk-AP; Tue, 06 May 2025 07:22:57 +0000
Received: by outflank-mailman (input) for mailman id 976698;
 Tue, 06 May 2025 07:22:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCCdk-0001Se-0Q
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 07:22:56 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20624.outbound.protection.outlook.com
 [2a01:111:f403:2414::624])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e9fd4b3b-2a4a-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 09:22:50 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 MW4PR12MB5625.namprd12.prod.outlook.com (2603:10b6:303:168::6) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8699.19; Tue, 6 May 2025 07:22:41 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 07:22: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" 
X-Inumbo-ID: e9fd4b3b-2a4a-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gUCgRnkpOcuaIIZJUYi4u2+Frrz6HtM2IBGUDyV9Gkt/DSi+o5mZvyvhv4Md7dPbV9M6BDqwia4EL07QwqwCLOkwp3WKajn23JhbvivfGltHvfyluTg1XZQ7XH42yR/YXS01d0ZZ3nMZnjVR7p47bfidbgYXcqRdqFRepgw5cMMOMeqpsKzBPTG3o2rf4KNYOoDzo4JVGBwLqRAZpzE3XgBbvUdibH1qJcU1nW2IHxruae1ZwwFcC5/mcgi396QCNP/bTyOEf8GhbOANbTATo9DTf1tO0lM/HVTjqJuVfy3wMKBhzjhyoZYuW4UEX3Ks0CX1uGTxFKlVdhzyeFA5hA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=v2+gJ7NxO/tieKwOd+C7kF5sZB2s+VUhGpthCroc7vM=;
 b=kHOe3ZFeijvlU2piLx45J5G8wGG8JM689A7IAfuosGSxvnPbdX+u0fogbgtBwNerlTmkyPPn1IAYR16Jkkjx/J1Lcrz8tY53BFpd+TL4rXOIIoKIVO2uuHg3M7zqKBwb9afMASu0rvzsmSWyuiqZPxNOwDgSf74VIKrtUL19rMsSMbRE5+x7z1lsjYcJr7QdCDY3cOkWNnTWT2xEln4ZdwXSGICeb79+QpPCuGWimLVU94Rjh+HVoBFmuCl1W4haBM04J1jDB0htehWoDA7x8qIxmnwS7R58/R1YJ4j8ESucPjGBcbvCpM6QADPaqD2Z/xev/7ATAGFHCNzij2hzvQ==
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=v2+gJ7NxO/tieKwOd+C7kF5sZB2s+VUhGpthCroc7vM=;
 b=nb4whos7Y6oZxx2IENK2NkNVRlRy61VaW126u91/Y8OOMgV5hlRHrDZxZZIrbbq1UnbXqOqjTmUCqpVASzOeScgZZP+AAoJ4mV+dhkYkyVuMZ8Kvoa7lbl+bZFzlj2D3TMKBQ8RAjDeMgt+mdHUUlG/EByYdnRgjNP1EQfSkut4=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Topic: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Index: AQHbrRCjQUXzVZg75kKZW3IeVU/v2LO5SzoAgAv/ooA=
Date: Tue, 6 May 2025 07:22:41 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-3-Penny.Zheng@amd.com>
 <829e710d-d257-455a-b4fc-1746119609ef@suse.com>
In-Reply-To: <829e710d-d257-455a-b4fc-1746119609ef@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=7dfca292-8034-463d-a626-2ab4fbf23c8f;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-06T07:21:59Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|MW4PR12MB5625:EE_
x-ms-office365-filtering-correlation-id: 95bada94-ab7d-4d19-7f48-08dd8c6ec9ad
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?RzBnaGZjQlFPcXlKRjIzSFo1ekhaQ3RXYmI5T3dZNUtORUtLVjJ4eVZDeitP?=
 =?utf-8?B?T1ZRZ1phRlRkTGhzV0g4MFgxTEc2eHN5Z1NZVXJpWDd6bVBRT1Q4NWxYNVJN?=
 =?utf-8?B?d250MmxkanpXYnhGWEZWeGJROE0wckZCMHdTcXFhNDBZV1VHc1B2K1J5ZEhC?=
 =?utf-8?B?cTVsV3ZXbGo5M3V6dzJOR3ZxWVFwMU9UaSs4VmZ3UG94UkRDamp5SW5lM1Nw?=
 =?utf-8?B?SjVpeTF5UHdQU0drMW10TTVwd2hKOXl3eWhoRW9OZTlrWVpITm1XQnh0MWhG?=
 =?utf-8?B?WDQvQ3F6TzhKSzVyVUxwQ2ZRWHdHaVlXVXh4ejRtSGd0UDZjWWNZL3V0S25x?=
 =?utf-8?B?ZElwbjU5cXVsVm1VQVp5VW5wZFlBTTBoQTU3NzlzWFNhTnFVTkI5aGZ5QlU2?=
 =?utf-8?B?c2dqKzJyN0xCUWJzUFo3Sjgrdlp1VXN5SnpsUXBOa2dhZktTbzFDOVlqY3Iy?=
 =?utf-8?B?dlZ4Y21EMTFNdXJVSkZKbnh2TkM5ZWI5V243MEt2T1VPbDl5RHZNMnovcHow?=
 =?utf-8?B?NXRiV2lkVmpuZlRXTDFTeFVUeGZzdmVyUjlxeUh0MFhVRk5HcjRHUWVGNTlo?=
 =?utf-8?B?MVFOV3dkOXZJNlczZWFCbTNPOVRmMmZEV3J3WWtUNTNvVCt3TW1IYjBmTkVm?=
 =?utf-8?B?ME1xeGQ0VFJsa2JDVndxMkhHYVQzWkRqL3A1L2RUNGxlM08rc0NjY0FDN1BU?=
 =?utf-8?B?Y1QzRnV4d0tWRFloUjBhLzBkOUs2WnBiemF1VE1PaDNsaXpmQi9LaWxWanh1?=
 =?utf-8?B?U0M0alhZcWEzQTRBL3ZaZHlja2pIeGJwNU1sY1ozY2V3UUpnYy9zSzFQUjNv?=
 =?utf-8?B?S2NiMTFpZVJYUURub2NrUnN2V2ZuV0ZiSmd3Qmc2bHVtQnB5MEJvcGFEbHBo?=
 =?utf-8?B?dWlsRDVhNDhZNlgrQXBrb2lYYkVuRnlmd0N6UHZMYlo2a0FXKzRPekVBWUtR?=
 =?utf-8?B?WVNMUmZZaTVhMXB3R282NjJGYS9XaUg3MHA5WnZZSXhtajcrMkVma29BY3Jj?=
 =?utf-8?B?Zll5cDVaMHl4VDlKTmdudVNFZ0FMSllhUytLaklSRTUvZ0t3aFdjSGVkd2tw?=
 =?utf-8?B?Tmt6R3FOaTRKQ0dPTCs0TlhReCtDM1JtTVFEMDJxRkhaMzMwL2VOSXpuR2tX?=
 =?utf-8?B?S2d0NCt1VHYwajZwQkxoZTNzVExtNkkyNUJuSkpEOVRkd0F0QVozTWZCd1Vm?=
 =?utf-8?B?OUF0SkI3Vk1aZGREVi9laDFvY2dEazFTYklNZDk1djZkUDd2V2o4dVlmWDZx?=
 =?utf-8?B?Y0lUVldzaWY5WnZWTnByT1ZacTRMQStRM1d1NFRDNlVCL21wRVcySFNjTklC?=
 =?utf-8?B?eVdTdk1CdGNKMEFYWXdkby9mRVJQTTY4TE5yeVAveWRLREMraTJWWWpqdnc3?=
 =?utf-8?B?b3BaRmtDbHN5bFNMZUhheXRQV0xocHowY0hGS2xMMHdhempnVnRvMmVZTWV0?=
 =?utf-8?B?aGFDYm0yQ1RxRStrbm1BdzJkSHFpV0tmQWowQWVuRWhTMGVXZDIyZ2owWjVp?=
 =?utf-8?B?eFFlTmxld1lGWmlYVFB4Q3dtUTJTRHgraFpVZ0dqaURiQ2FxOVY5Z05oaFNX?=
 =?utf-8?B?UEI2T2ptSFIzM1ZVY1FISkVXeVUwV1kwWnYxT0dVM0x2L3BPUjBERjZ5TUhF?=
 =?utf-8?B?RXU2RGMwRE50WUk1NW0rOGxjbk1QU2d6V0NNMy9YekpEVHZuY3ZsWktaMHZF?=
 =?utf-8?B?ZklDdG00eFk0dXRva1M4NUxJVThEZWNTck96azVYWXJwKzJrVFlnKzEySlU1?=
 =?utf-8?B?N3ZzdzNxQWVta00vODJ1VForNGMvK2p2UmF5VkNQN2loOFRxTi9uTnBGaDYr?=
 =?utf-8?B?emNQQlE5Y1dCSmNOZ3FuUjUxYUVIKzRkbGprd3pWVlVsYVBVMW05UW52Q0xo?=
 =?utf-8?B?NGpSUm40MG8xQUpha2d5NFpmMzhhWW9xUE9UeGNTSDU1ek9SVDc3WndGbmRQ?=
 =?utf-8?B?OUJvUWlibU1iTnJJNnFlZHlGaWtvR0pBbUVPRHdlVko2eVkxbWpPd1NoMXVw?=
 =?utf-8?Q?Eq7JEpDSmzzCbd6zCsk3031TOfgzfo=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?N2xGeW5Dd1JjbzhkZm00VjR0SHd0K0pvbjQ4Ullocm13WFZ2amlJZ1MyV3BY?=
 =?utf-8?B?U21WZkszMm9RZG9WaGJ6QkxIK20rRXNoL0FlUjhOMjhyMXhpcnduQmhUWUlp?=
 =?utf-8?B?VTBPNzF5b3F6VzNLT0UzZ2ZpejdPTm5PRnZEa3c2QkdXYmM0aHkvdVlsRU0w?=
 =?utf-8?B?dVAvK1JJTUlEdVhtNVVwK05qak1OckV2dTRpeUo3K1JmTlRwYmNTRktleSta?=
 =?utf-8?B?STZFc0o1SjhuUnc2Z2tBNUhXM2JkaXZyVFhDL2pTbFErdGdmRGhDOEIwSnhD?=
 =?utf-8?B?bzBrQ21NWTVJYncydUc3QXBBVXNCdysrU1dvSGNnWDJZQXhzOG0rNWROM1FC?=
 =?utf-8?B?SXREUExCcU9JL3hwOUZUUmFNRkZEYUNUNU9xUGtOZWQ5Yi9aN2lCcWY5N3Vs?=
 =?utf-8?B?ck1KaU9SaWN6REVNTEQwMXExQ3Q1YXV5by9uNFJaUXlsblpYOHM1S0hLaGtL?=
 =?utf-8?B?bStRL3VhZVdjWGFhd3FJU0d0QTZOYi9zV0J5bzNCZEE3V3lwZ1hMZThBbXdF?=
 =?utf-8?B?ZnY4ZTFUQUF5cEFrYi9ubThnbEhkWXFZaWFIU0UzMzJtYVBncjVqdU5xT2pW?=
 =?utf-8?B?ZGlJQjFUams5cVNsMy9yT0hHdFlVRkplcitzTGFDZ3JHSEJBVVJ6Y2QvSW9s?=
 =?utf-8?B?R1F6QW80K1FIWXJvT0hkeFlFcGlDTEx4OFRWZW9pZHVLSnQwNEpGclgyTGJM?=
 =?utf-8?B?UFgrTi9rZGhic3k2TzI5akhtUkZVNC9udTltNnRVL3dLb0pTVmlIM0NkSDVt?=
 =?utf-8?B?MjdoMWZWOVNWK01ITGdMMFlKUmVMSXRlRkhnZG43NjRUNzlCMWhaQVlQcFpF?=
 =?utf-8?B?cEpOVFllcXZza0VTek1DTUY3eGJDektMbWJGSGJoZUw0Y052STFVQTFiaUp1?=
 =?utf-8?B?dU1weGV3UmwrSmVsZkY5QzIrN0IxUjcyaklZcW9zalIvRzdUaFNKU2x0U2dE?=
 =?utf-8?B?SERWVlB0Z0lkZ3RGdzQ4QVhaeDVTRkp0V2x0ODFSbnBITXFxcWlMZ0lBYnVm?=
 =?utf-8?B?Y2UyYk1zaEc4Z3IxaG1BQmdQZjRwcndQdmplMFptWklVVXowaWprWnhYWU5H?=
 =?utf-8?B?MXpvZE9uMnRBMHNmUDJ6MlJ3SkN4ZWtTSGtYTjBuenRZNFdpeUZ3bUFmbWlx?=
 =?utf-8?B?eEJLYVRYMmpTb0JJU0pwMDRNT2RMZDVjS0FRNzJIeW1oa0NWVjhCREZHOXla?=
 =?utf-8?B?MjVJWk5GNjB6UkEwMXA3aExJQmtMVlRmd0FneURmNzdXWGZHSVI2b1Q5Mlhn?=
 =?utf-8?B?ZjdZd0N2RlBSMk9PNGJBcjR3aWJ4Z2dnSVJLQSs5d1U3NFFONFFrR1FVcGxp?=
 =?utf-8?B?RjVRc3R2V3Q0NnJiZmN4MnNvdi9TWjdaKzdJNFdiWDBFSzk1SWhxSWd5UFQz?=
 =?utf-8?B?N1I1V1UxQ3pJdlF5dXE0MForYi9WVzZPRHo2QmxVRjQzNUVGRDZrdVNpTVU0?=
 =?utf-8?B?UEtDOG5wUU9DVU9Hd1N2UE83NkdvZFA4alBYVDBDZ24xNEc4VlUvY25WV0dq?=
 =?utf-8?B?TjlwQ2xVTURRV0tmYXFsRENoZmU1Nm1iaGx4Mm4xeGN0akdHYW04aW85Y3Zu?=
 =?utf-8?B?aGp5OUpSeHRJdXNWc2J3VldzL2ZSWXdtaG9mc2lhUHoyYVhYbUVQV2ExOEFv?=
 =?utf-8?B?QUlBOVVwOThrcE1ZK3ozZ0hoL3hoRFlwU3pUNnBUS1hnS1Ftek84aGlKQTRI?=
 =?utf-8?B?Q25FcTQ0bjhudVJVNDhEMVBZL1NOMS9mWnp6NGdwYU9RdEVrNWtQdDZKQ3NR?=
 =?utf-8?B?aXVVQ2tmMzJTMkZQdEUranVPNHp0NlhyWFgzbE5SQ005Umx4SmJObkhqUGZH?=
 =?utf-8?B?RW9uY0o1TThBSThDOVByOFJFd2NPZEZjQkFDNHc0amdOTmNsNlhyTVJjQ2Ur?=
 =?utf-8?B?WGtZYlJEaUpYeHR5UGlNd1NYaEM5V0Y3WENzVUdrdzdiaEdjR0N2eUNFazRN?=
 =?utf-8?B?ZVVIWDZRbTFtUGNvYVpBRlg5VVpaamU0YjY1dmxnNEFxOVpjbmUvWko2ZlE0?=
 =?utf-8?B?WjE1eUxWWThGdFJrODEvbVN4RWpiTVBJQkkrM0Q1a1lzYWIzbmYrYXppdHQ4?=
 =?utf-8?B?WGlWdEphMEx4R3NxSVl5TEIvamRydytLSWZlbWhYZmRONVFCb1UxUVphd3NL?=
 =?utf-8?Q?ZE5A=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 95bada94-ab7d-4d19-7f48-08dd8c6ec9ad
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2025 07:22:41.4137
 (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: SCu4Tf+r5IL5bqumbXXRqqpAchcfRJpGuIdDsYJM5MTEoXHbDJn9jcnJSAkZumuoHy8Ev6MdSA08PDvTzMGAWQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB5625

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBNb25kYXksIEFwcmlsIDI4
LCAyMDI1IDExOjMyIFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+
DQo+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4g
PGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJh
cmRAdmF0ZXMudGVjaD47DQo+IE9yemVsLCBNaWNoYWwgPE1pY2hhbC5PcnplbEBhbWQuY29tPjsg
SnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2VyDQo+IFBhdSBNb25uw6kgPHJvZ2Vy
LnBhdUBjaXRyaXguY29tPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwu
b3JnPjsNCj4geGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBb
UEFUQ0ggdjQgMDIvMTVdIHhlbi9jcHVmcmVxOiBleHRyYWN0IF9QU0QgaW5mbyBmcm9tICJzdHJ1
Y3QNCj4geGVuX3Byb2Nlc3Nvcl9wZXJmb3JtYW5jZSINCj4NCj4gT24gMTQuMDQuMjAyNSAwOTo0
MCwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4gLS0tIGEveGVuL2RyaXZlcnMvY3B1ZnJlcS9jcHVm
cmVxLmMNCj4gPiArKysgYi94ZW4vZHJpdmVycy9jcHVmcmVxL2NwdWZyZXEuYw0KPiA+ICsgICAg
ew0KPiA+ICsgICAgY2FzZSBYRU5fUFhfSU5JVDoNCj4gPiArICAgICAgICBpZiAoIHNoYXJlZF90
eXBlICkNCj4gPiArICAgICAgICAgICAgKnNoYXJlZF90eXBlID0gcHJvY2Vzc29yX3BtaW5mb1tj
cHVdLT5wZXJmLnNoYXJlZF90eXBlOw0KPiA+ICsgICAgICAgIGlmICggZG9tYWluX2luZm8gKQ0K
PiA+ICsgICAgICAgICAgICAqZG9tYWluX2luZm8gPSBwcm9jZXNzb3JfcG1pbmZvW2NwdV0tPnBl
cmYuZG9tYWluX2luZm87DQo+DQo+IERvZXMgdGhpcyBuZWVkIHRvIGJlIGEgc3RydWN0dXJlIGNv
cHk/IENhbid0IHlvdSBoYW5kIGJhY2sganVzdCBhIHBvaW50ZXIsIHdpdGggdGhlDQo+IGZ1bmN0
aW9uIHBhcmFtZXRlciBiZWluZyBjb25zdCBzdHJ1Y3QgeGVuX3BzZF9wYWNrYWdlICoqPw0KPg0K
DQpJJ3ZlIGNvbnNpZGVyZWQgaGFuZGluZyBiYWNraW5nIGEgcG9pbnRlciwgdGhlbiBtYXliZSB3
ZSBuZWVkIHRvIGFsbG9jYXRlIHNwYWNlIGZvcg0KInN0cnVjdCB4ZW5fcHNkX3BhY2thZ2UgKipk
b21haW5faW5mbyA9IHh2emFsbG9jKHN0cnVjdCB4ZW5fcHNkX3BhY2thZ2UgKik7IiwgYW5kIFhW
RlJFRSh4eHgpDQppdCBpbiBlYWNoIGV4aXQsIGVzcGVjaWFsbHkgY3B1ZnJlcV9hZGRfY3B1KCkg
aGFzIGEgbG90IGV4aXRzLCB3aGljaCBjb3VsZCBiZSBhIGZldyBjb2RlIGNodXJuLg0KU28gSSBj
aG9zZSB0aGUgc3RydWN0IGNvcHkgdG8gaGF2ZSB0aGUgc21hbGxlc3QgY2hhbmdlLg0KDQo+ID4g
KyAgICAgICAgYnJlYWs7DQo+ID4gKyAgICBkZWZhdWx0Og0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Tue May 06 08:08:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:08:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976719.1363863 (Exim 4.92)
	(envelope-from )
	id 1uCDLW-0007ds-PO; Tue, 06 May 2025 08:08:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976719.1363863; Tue, 06 May 2025 08:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCDLW-0007dl-Mk; Tue, 06 May 2025 08:08:10 +0000
Received: by outflank-mailman (input) for mailman id 976719;
 Tue, 06 May 2025 08:08:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDLV-0007de-0R
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:08:09 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20624.outbound.protection.outlook.com
 [2a01:111:f403:2416::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3d54f7d8-2a51-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 10:08:07 +0200 (CEST)
Received: from BN6PR17CA0047.namprd17.prod.outlook.com (2603:10b6:405:75::36)
 by MW5PR12MB5649.namprd12.prod.outlook.com (2603:10b6:303:19d::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Tue, 6 May
 2025 08:07:56 +0000
Received: from BN2PEPF000044A4.namprd02.prod.outlook.com
 (2603:10b6:405:75:cafe::b9) by BN6PR17CA0047.outlook.office365.com
 (2603:10b6:405:75::36) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.29 via Frontend Transport; Tue,
 6 May 2025 08:07:56 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF000044A4.mail.protection.outlook.com (10.167.243.155) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Tue, 6 May 2025 08:07:55 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 May
 2025 03:07:55 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 May
 2025 03:07:54 -0500
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 6 May 2025 03:07: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" 
X-Inumbo-ID: 3d54f7d8-2a51-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Q2M1IYxMoMwfeClqAboUuEFXf0mjFPU+nH6pkTz5Rd8OIggVQVXd6ycZCBAYCn3zG1V2ekcQqKPktV9dTtoa2wCmcN9ETie4M6cj/HuB41RxmMgrlBXRqGPEpRR1WveehPPHpNBfKtuUv2isFgRtmjdeqpGxxpF8NOQGXnEa58I9c9t1Lks1txwx+npwH0y9Mvy6oFjk8+7NU0u2OmLBSZ1QXMsIzkML/xn7R3NuIO/D69ZnXlWgG1dJndZKTf9yYa4pPYjdwxj+tPy1gF6bHypGF8jpMJ/FrkFXRaQoUWIFbSWX3X5GUrzpusUALzXedf7rPV3ArGvgVRJU28KLOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8ILS/hC1n3y4E0velyOtlWSjEyWQphmIDe8wp9R6jOE=;
 b=kf0U6uHO2CyVstKelXW9V5/DThVrL+wwXC7EZAZndi/mi75XjJRp3zmYvJDFyPWBXn6BeXBV2D1gIavLUz3jAs33sjj/PNPVSucRMs8MnNKVTa3H1Ywh+e7JKjiHsKFjP/9xYjHMLkCsegPeGAOM+obijwYKDDq1RH24lTW8dOlkeZgBXgaX3EV7bdBvFFPBye5uqPdabFCpOZhcm72PTUNxdePpNN1Mul5cuNB28t7u24ed9tytWJ7Hrn+FtNI4voU6ioZRNNV7HMeC9zUX1wa4QZueOW0vWvAh5rHXM4yLEuaZfYL27wJ5SDw4422IzGTEek15xGWmMn0NWUJWYg==
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=8ILS/hC1n3y4E0velyOtlWSjEyWQphmIDe8wp9R6jOE=;
 b=TuBG973LO0eZ2jY10X6unhpAgHZZe/hg+qMagZhkazEm/Kd036yefUAU3zDyf/OlkfCDzh/N75rUV91FXBoKpq0sTcyYnlkxPijLemAQW4+Ah2GfyiOHCDsRPeJeyn347NdGUy1yyjZXl5HyD68kolkpPDmnB6KztHM9PznLArk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Michal Orzel 
To: 
CC: Michal Orzel , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	
Subject: [PATCH] device-tree: Add missing SPDX identifiers and EMACS comment blocks
Date: Tue, 6 May 2025 10:07:52 +0200
Message-ID: <20250506080752.23307-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A4:EE_|MW5PR12MB5649:EE_
X-MS-Office365-Filtering-Correlation-Id: c6d9aeda-178a-4ea9-ff2a-08dd8c751b74
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?VqyR1kQrjuDsmWm55ZL9F4dxvsMf7tEY5iA6a3MASLJ6/+9nAsgdqILt1xon?=
 =?us-ascii?Q?acjSmycOBfugrKiViTQ2A3b+/JnIz5YvKHPEGUeCZW0Sj/oLB0KiJCQTD9iz?=
 =?us-ascii?Q?ZPZ8PASTm4oOeTZp0aCmHzCFyHtizuScbzq6mwbgl85qbC6rv9kyzDYmVIsw?=
 =?us-ascii?Q?spV+H8Atyr5vVhnnjrh/uw1gtLFBjtm/T9tzSybsSBzyDEBQx9xw7vlK4Ubk?=
 =?us-ascii?Q?O1j6rAAQV3Ti2QJKQ18S4sYD2kFEhQEEEGZnVtB7xzxOIh27Q7JqPqkwFHhi?=
 =?us-ascii?Q?iWid0UiNw4PsaeTOf6SIQZUhPSqJ9VxiNAJpjgmCYKrGIMzboPBapCgE4ujc?=
 =?us-ascii?Q?32UTj5i4U9VG8988E0O/w4EYBFfcIb9Z/7lMTJvc/jS1auIO78BT+4X5/pD/?=
 =?us-ascii?Q?31xCgT4Y6UogkSvxeFmMgF2RA3w7QjWVKYGzX0Jn164kDgR2hxPRp1Bgt5Yo?=
 =?us-ascii?Q?/TB3yBHvIk4LY2nSgz7BnVoXR1GkYT2/ZEpzMy5Cz3vvu6n1h+Z/hrKGMZdy?=
 =?us-ascii?Q?00DJg7hAnvWoDw7Pl8wwWOSKTbQ2f9DOeqm4xWlqJL02Av54TsbXKtMnqN8Y?=
 =?us-ascii?Q?l1AP4CK9PaNMii7REJKM06h2PozwpRjGvoDWKW8bKq21suJq9QwdEM1Am7PJ?=
 =?us-ascii?Q?nNDQV/jfUua6uE/glG2JPqD9ykbUTY55sV9wOWjfPC91eZsemz4bOGzYS3qb?=
 =?us-ascii?Q?mBPg6AoUqt1nJHLxZyRXfppX8jgj6pmbRRORg3YOi5DG2xoh2ds1AkLJE48K?=
 =?us-ascii?Q?PcGUWWrRuvlOlCscgONG1Mr1YqS4QSRgInH1A7ekgvwp61Y7tcVnACKyvBcH?=
 =?us-ascii?Q?VidzwPvz5IbDoO51Hj/txCO2RjvCucDu8MTD+lR9aFQqe3SfHDaNCcuVctvg?=
 =?us-ascii?Q?K0OAUUqPz0cF6m9SODpDyUFiwPkc5bPMCWibZoDW37OIJGJaHQhWUfKVJkzV?=
 =?us-ascii?Q?zwNwowxA5lhXjPvQ1NQ5F6lTfNNnbTv6fRca9osfIJ363q8zamP4oMsuaEa8?=
 =?us-ascii?Q?MM66Ms0zNGCD5ejJoVfpuL0g1VP31eqZd0diMi1XmIYgkuMUeePwSi0dYaUl?=
 =?us-ascii?Q?20wSenXyuBk1EhtdMfSwV2xE9CfomUnx+lm97Ac4TWFzo68eVyNE3OAB5uIZ?=
 =?us-ascii?Q?c17wATVmUXCmmBQe7MrgSP/cUnwoFaEpKEwBy6n4JitCobkD8i8j/N2LLTsE?=
 =?us-ascii?Q?Q8H1XKAxANiOG/QlQ/IsJV1MLH/J4XvhF/L/6LIz5IQj7IoJSRRYLeWQWu6q?=
 =?us-ascii?Q?ZNBm5Jci0guHS+LK3dmsmFsEbphzEb1EQ76qsFlimaPAH6mw4GQHcxTV0AfE?=
 =?us-ascii?Q?Y+Mk4xQG0NzsDg3CSDpJgXYhxTYuCFtcxeAm4DJFKHqhR0bZHlaq5d6/EFeE?=
 =?us-ascii?Q?uYD4UQsWlYPpDljqgLdcCiae0XMUJcH4k+oOEoo35hQB0fVhXI86yzZVafUd?=
 =?us-ascii?Q?lMHh0679PfwiPFFZA0qU9i1odCZvvFd6Mi17zpHhKKnPy0sJXVbNZcVJOlHh?=
 =?us-ascii?Q?6y0XBeZxp1i7Zm1P0V9SWNgwSa2bpJWo2x4P?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 08:07:55.5744
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c6d9aeda-178a-4ea9-ff2a-08dd8c751b74
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A4.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR12MB5649

Use the same license as the files from which the code originated during
recent code movements. Take the opportunity to add SPDX identifier for
device-tree.c and remove the license text.

Signed-off-by: Michal Orzel 
---
This is mostly fixing files added recently by Oleksii.
---
 xen/common/device-tree/device-tree.c  |  5 +----
 xen/common/device-tree/domain-build.c | 11 +++++++++++
 xen/common/device-tree/kernel.c       | 11 +++++++++++
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
index 90fee2ba0315..886e6c7712de 100644
--- a/xen/common/device-tree/device-tree.c
+++ b/xen/common/device-tree/device-tree.c
@@ -1,13 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*
  * Device Tree
  *
  * Copyright (C) 2012 Citrix Systems, Inc.
  * Copyright 2009 Benjamin Herrenschmidt, IBM Corp
  * benh@kernel.crashing.org
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include 
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 762b63e2b00a..3d7fc7a19ef6 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
 #include 
 #include 
 #include 
@@ -393,3 +395,12 @@ void __init initrd_load(struct kernel_info *kinfo,
 
     iounmap(initrd);
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
index 1bf3bbf64eae..cb04cd9d5014 100644
--- a/xen/common/device-tree/kernel.c
+++ b/xen/common/device-tree/kernel.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
 #include 
 #include 
 #include 
@@ -240,3 +242,12 @@ void __init kernel_load(struct kernel_info *info)
 
     info->load(info);
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 08:15:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:15:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976732.1363873 (Exim 4.92)
	(envelope-from )
	id 1uCDSD-0000v2-EE; Tue, 06 May 2025 08:15:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976732.1363873; Tue, 06 May 2025 08: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 1uCDSD-0000uu-BF; Tue, 06 May 2025 08:15:05 +0000
Received: by outflank-mailman (input) for mailman id 976732;
 Tue, 06 May 2025 08:15:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDSC-0000um-1G
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:15:04 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 35d1acb1-2a52-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 10:15:02 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5e5bc066283so7940026a12.0
 for ; Tue, 06 May 2025 01:15:02 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1894c0276sm659748166b.108.2025.05.06.01.15.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01: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" 
X-Inumbo-ID: 35d1acb1-2a52-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746519302; x=1747124102; 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;
        bh=uqyBqxUAyi5ilsJoxz1bXn/zQ+HZlt2a0tHEzNMVOEE=;
        b=QOYEnr2YVOanOscx148E3l6qbMEb9BM6SLXd1XR1fUa3NRWkfjU32mYnqpWuJPrF6v
         RAvUheezvecZLk+mhsQ1TDJCQDmbIyVyWG81UnHn4hXLeB8yMjgkA0gatHutJ1Z9gKhL
         BMPzFXzztvkWc4Qwg3FM1KFkehLKKkOntqPEQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746519302; x=1747124102;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=uqyBqxUAyi5ilsJoxz1bXn/zQ+HZlt2a0tHEzNMVOEE=;
        b=RsMo8YS9W/SoW9YYMaGvijcTi8Ujf3bfRVCH1+j5uVoMF7rkmfGfU/ZsA/HPLLdqI4
         XFx/d0sf0VMTwy7d29tjh58qsKr+Ec1j/UXQbyV3Gr1D/63/PXA3ALfL4uA8e7ztiFAC
         ZeYdiEikSbPl3a9EI/n/gtqkIBbj0s2anpsmNDoGhZDsNvvxAP/mtXMpWMqxFJSxsX/p
         IShZznatzAE9aBPn4fjj4KTfMCWzgOre61brJ4ssfL7paKZBOVEApFqnM60olRZYzNrG
         yx/eCseR2ShWPNttlLwbrUPY5lX3XM+X7S6YaoNdIhkEXmxwsZq5oJG/FyRYgY6Ldxn1
         kkIg==
X-Gm-Message-State: AOJu0YwJ5h+l2bwWsCTUU+yeP1Qr+D4qSxjW6sK/2vVnGwkcWsgv+0rn
	vY83vOZ8ezfCBRsr9thoyHd4jy451vlhJ5tJtQceWoB/MZa7sA6v7hCZkIRWn21CVpsEn8YyXFV
	58nk=
X-Gm-Gg: ASbGncubodelbNUlW15a/TIditUB4LfNeGs3/R1FHvWJBOCH7uITY61tI1rY9s4iXrM
	9myHnRhGdNPrnkyJQ+xcsA2x6/e4Xz0zYMM9H4LzKgtkraF2XhIB/MrQ+KNoWfHBe3N3SDRzKNT
	hyxzHgSua7Id7WX496keoMuJyOQfOiTf+it2sdcS7XT7XzqMfs/5qOTIPvRsLhe/fgoftZdzeYo
	PJoJeT7ptfGtmGQzEcyxZfPEZRH6j+Bq8fVQFkTHiTfl9RSaYpUKX4A8XCTsWYFJiaqGLNegqdL
	Jyp1XLZ+b41AJHKnqpwUJz9Daf1p+Slb8Hbkw7tw8XwhHlLrzVW1WCOnBQ==
X-Google-Smtp-Source: AGHT+IEOLk7s4WFABEB2b+m3lLblkvJi77LlzsZeXTYNRTVqnUswZZeYA5wwORlj3zO7NlB+NMu3kA==
X-Received: by 2002:a17:907:86a2:b0:acb:94d6:a841 with SMTP id a640c23a62f3a-ad1a490fc9emr959820766b.16.1746519301693;
        Tue, 06 May 2025 01:15:01 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com,
	roger.pau@citrix.com,
	andrew.cooper3@citrix.com,
	Kevin Lampis 
Subject: [PATCH v2] x86/cpufeatures: cpuid features for Sierra Forest
Date: Tue,  6 May 2025 09:13:30 +0100
Message-ID: <20250506081456.1572050-1-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add new cpuid features for Sierra Forest.

Signed-off-by: Kevin Lampis 
---
Changes in v2:
- change INVD_DISABLE to NO_INVD
- change UC_LOCK_DISABLE to UC_LOCK_DIS
- better comment for UIRET_UIF
- use MCU_ENUM because it's shorter and add better comment
---
 xen/include/public/arch-x86/cpufeatureset.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index cc6e984a88..089a133519 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -304,13 +304,18 @@ XEN_CPUFEATURE(SM3,          10*32+ 1) /*A  SM3 Instructions */
 XEN_CPUFEATURE(SM4,          10*32+ 2) /*A  SM4 Instructions */
 XEN_CPUFEATURE(AVX_VNNI,     10*32+ 4) /*A  AVX-VNNI Instructions */
 XEN_CPUFEATURE(AVX512_BF16,  10*32+ 5) /*A  AVX512 BFloat16 Instructions */
+XEN_CPUFEATURE(LASS,         10*32+ 6) /*   Linear Address Space Separation */
 XEN_CPUFEATURE(CMPCCXADD,    10*32+ 7) /*a  CMPccXADD Instructions */
+XEN_CPUFEATURE(ARCH_PERF_MON, 10*32+ 8) /*  ArchPerfMonExt */
 XEN_CPUFEATURE(FZRM,         10*32+10) /*A  Fast Zero-length REP MOVSB */
 XEN_CPUFEATURE(FSRS,         10*32+11) /*A  Fast Short REP STOSB */
 XEN_CPUFEATURE(FSRCS,        10*32+12) /*A  Fast Short REP CMPSB/SCASB */
 XEN_CPUFEATURE(WRMSRNS,      10*32+19) /*S  WRMSR Non-Serialising */
 XEN_CPUFEATURE(AMX_FP16,     10*32+21) /*   AMX FP16 instruction */
 XEN_CPUFEATURE(AVX_IFMA,     10*32+23) /*A  AVX-IFMA Instructions */
+XEN_CPUFEATURE(LAM,          10*32+26) /*   Linear Address Masking */
+XEN_CPUFEATURE(MSRLIST,      10*32+27) /*   RDMSRLIST/WRMSRLIST/WRMSRNS */
+XEN_CPUFEATURE(NO_INVD,      10*32+30) /*   INVD_DISABLE_POST_BIOS_DONE */
 
 /* AMD-defined CPU features, CPUID level 0x80000021.eax, word 11 */
 XEN_CPUFEATURE(NO_NEST_BP,         11*32+ 0) /*A  No Nested Data Breakpoints */
@@ -340,6 +345,7 @@ XEN_CPUFEATURE(RRSBA_CTRL,         13*32+ 2) /*S  MSR_SPEC_CTRL.RRSBA_DIS_* */
 XEN_CPUFEATURE(DDP_CTRL,           13*32+ 3) /*   MSR_SPEC_CTRL.DDP_DIS_U */
 XEN_CPUFEATURE(BHI_CTRL,           13*32+ 4) /*S  MSR_SPEC_CTRL.BHI_DIS_S */
 XEN_CPUFEATURE(MCDT_NO,            13*32+ 5) /*A  MCDT_NO */
+XEN_CPUFEATURE(UC_LOCK_DIS,        13*32+ 6) /*   UC-lock disable */
 
 /* Intel-defined CPU features, CPUID level 0x00000007:1.ecx, word 14 */
 
@@ -349,7 +355,9 @@ XEN_CPUFEATURE(AVX_NE_CONVERT,     15*32+ 5) /*A  AVX-NE-CONVERT Instructions */
 XEN_CPUFEATURE(AMX_COMPLEX,        15*32+ 8) /*   AMX Complex Instructions */
 XEN_CPUFEATURE(AVX_VNNI_INT16,     15*32+10) /*A  AVX-VNNI-INT16 Instructions */
 XEN_CPUFEATURE(PREFETCHI,          15*32+14) /*A  PREFETCHIT{0,1} Instructions */
+XEN_CPUFEATURE(UIRET_UIF,          15*32+17) /*   UIRET updates UIF */
 XEN_CPUFEATURE(CET_SSS,            15*32+18) /*   CET Supervisor Shadow Stacks safe to use */
+XEN_CPUFEATURE(SLSM,               15*32+24) /*   Static Lockstep Mode */
 
 /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.eax, word 16 */
 XEN_CPUFEATURE(RDCL_NO,            16*32+ 0) /*A  No Rogue Data Cache Load (Meltdown) */
@@ -368,6 +376,7 @@ XEN_CPUFEATURE(DOITM,              16*32+12) /*   Data Operand Invariant Timing
 XEN_CPUFEATURE(SBDR_SSDP_NO,       16*32+13) /*A  No Shared Buffer Data Read or Sideband Stale Data Propagation */
 XEN_CPUFEATURE(FBSDP_NO,           16*32+14) /*A  No Fill Buffer Stale Data Propagation */
 XEN_CPUFEATURE(PSDP_NO,            16*32+15) /*A  No Primary Stale Data Propagation */
+XEN_CPUFEATURE(MCU_ENUM,           16*32+16) /*   Runtime Microcode Update features */
 XEN_CPUFEATURE(FB_CLEAR,           16*32+17) /*!A| Fill Buffers cleared by VERW */
 XEN_CPUFEATURE(FB_CLEAR_CTRL,      16*32+18) /*   MSR_OPT_CPU_CTRL.FB_CLEAR_DIS */
 XEN_CPUFEATURE(RRSBA,              16*32+19) /*!  Restricted RSB Alternative */
@@ -379,6 +388,7 @@ XEN_CPUFEATURE(GDS_CTRL,           16*32+25) /*   MCU_OPT_CTRL.GDS_MIT_{DIS,LOCK
 XEN_CPUFEATURE(GDS_NO,             16*32+26) /*A  No Gather Data Sampling */
 XEN_CPUFEATURE(RFDS_NO,            16*32+27) /*A  No Register File Data Sampling */
 XEN_CPUFEATURE(RFDS_CLEAR,         16*32+28) /*!A| Register File(s) cleared by VERW */
+XEN_CPUFEATURE(IGN_UMONITOR,       16*32+29) /*   IGN_UMONITOR_SUPPORT */
 
 /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.edx, word 17 */
 
-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 08:34:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:34:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976748.1363898 (Exim 4.92)
	(envelope-from )
	id 1uCDlK-0004MJ-GL; Tue, 06 May 2025 08:34:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976748.1363898; Tue, 06 May 2025 08:34: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 1uCDlK-0004Lh-Cy; Tue, 06 May 2025 08:34:50 +0000
Received: by outflank-mailman (input) for mailman id 976748;
 Tue, 06 May 2025 08:34:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDlJ-00041m-5V
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:34:49 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f7bd8322-2a54-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 10:34:47 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-39c1ef4ae3aso3159025f8f.1
 for ; Tue, 06 May 2025 01:34:47 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099ae0cd6sm12761237f8f.5.2025.05.06.01.34.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01:34:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f7bd8322-2a54-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746520486; x=1747125286; 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;
        bh=uFdCdonHRi/V3I4AjrrMy18B5UWA7t/AwxBRWIfPBMg=;
        b=khONc6ytuiUIT1BJ+pmydxnoDLJL7xYURNcVYV2TPgZ+kQQYrgnV7nPCvNWEEsJDKB
         FrWEnKjvGNFAapErAI4FbOxLESigcYwLNPQZXOCKrqhxsUaKqyKP17ubHXRR57mcAydZ
         PqqHmwYdpuPo+z03OYgdLr5cf6myJk5bHkzGI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746520486; x=1747125286;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=uFdCdonHRi/V3I4AjrrMy18B5UWA7t/AwxBRWIfPBMg=;
        b=jE/A902WPABNkVH53gPSk1nXHu1TqYQGw5HRDgVoSIrMc16EVfuGvnHGqP2ufHV2wl
         JDI1Swi2+IQEea/OI8ReyFOmbBMzfTwn9cnyOr5B0qda71Z4kYNzqs66fCz6p00WJJ8U
         YyxETfElmBfmrGfww/0bDGhsG7wV90H0YA1O2QB96qUSAimuWotGjH9HR24vKIhCLQId
         MJ5LSK5bQ1rJLw2zPYaPDJno5R6XYcRcgbPR+xbTEGVDIqtvxgYPkPk1K6sQpQhaZwz5
         5rgmfEz8nTmETg0XEsdFmf4tMdAIdPup9GdLiApf5VKj0WNpYsjKUvh4KDMxeZvEL3wk
         RtjQ==
X-Gm-Message-State: AOJu0YxpOPyfkgRkCr+wU8TFIO5WLgPP3cHOv7HRInF9uygESwfnSGBp
	yGknYyTWbttDoEykmbHEG6PXALNRsLiU25QzEhi1lv4RJMnOl2rkn+aaoY/Sj2Y0z6d+Uvl2lZ7
	O
X-Gm-Gg: ASbGncvUUdHjYs0P8EJzdmWqPGkw67eir056azg5C/iqtWsljRlUdy3chGwUftpsrDl
	rBvqhFHzJEbBZEQX2qFc7DPqwyLnAhzRczHYt3/WAL53CDwH5ChZ0Bj7x00umvsOGCOSgfBdGGm
	HAkOeEzWSBUDNypouZg+Q0XtIsf23UzAST3p0boON8Tmi2U4yYD9BPjBGue2PkdsEwG/530MZk2
	eOcxHSM5cMyUanmLxvoWfpniOJ09Y3ytJZd/x5bQjihLRIRrkWTtlf33oYNprY8IOao6kJwlN3V
	k82ElcvRft0ffSwwm3VlIEVtMNHTtwk1353gBQiSMySXAA==
X-Google-Smtp-Source: AGHT+IEEJgMoX/Ygxj+QlDyIS89kjsS1lbFo+fjNJSn53rHstrrpDwm8RRtBETzoxMFmPHbFlEJ1/g==
X-Received: by 2002:a05:6000:2902:b0:39f:c05:c220 with SMTP id ffacd0b85a97d-3a0ab5b32bemr1901163f8f.22.1746520486355;
        Tue, 06 May 2025 01:34:46 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 2/9] x86/pv: fix emulation of wb{,no}invd to flush all pCPU caches
Date: Tue,  6 May 2025 10:31:41 +0200
Message-ID: <20250506083148.34963-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250506083148.34963-1-roger.pau@citrix.com>
References: <20250506083148.34963-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current emulation of wb{,no}invd is bogus for PV guests: it will only
flush the current pCPU cache, without taking into account pCPUs where the
vCPU had run previously.  Since there's no tracking of dirty cache pCPUs
currently, resort to flushing the cache on all host pCPUs.  Also as a
result of having no mechanism to broadcast a wbnoinvd instruction, resort
to emulating it using wbinvd behavior, which is more expensive performance
wise, but correct.

Fixes: 2f6070f0b988 ("Priv-op emulation in Xen, for RDMSR/WRMSR/WBINVD")
Signed-off-by: Roger Pau Monné 
---
Note further patches will limit the broadcast cache flush to only pCPU
where the vCPU has ran.
---
 xen/arch/x86/pv/emul-priv-op.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 70150c272276..089d4cb4d905 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -1193,17 +1193,18 @@ static int cf_check cache_op(
 {
     ASSERT(op == x86emul_wbinvd || op == x86emul_wbnoinvd);
 
-    /* Ignore the instruction if unprivileged. */
-    if ( !cache_flush_permitted(current->domain) )
+    /*
+     * Ignore the instruction if domain doesn't have cache control.
+     * Non-physdev domain attempted WBINVD; ignore for now since
+     * newer linux uses this in some start-of-day timing loops.
+     */
+    if ( cache_flush_permitted(current->domain) )
         /*
-         * Non-physdev domain attempted WBINVD; ignore for now since
-         * newer linux uses this in some start-of-day timing loops.
+         * Handle wbnoinvd as wbinvd, at the expense of higher cost.  Broadcast
+         * the flush to all pCPUs, Xen doesn't track where the vCPU has ran
+         * previously.
          */
-        ;
-    else if ( op == x86emul_wbnoinvd /* && cpu_has_wbnoinvd */ )
-        wbnoinvd();
-    else
-        wbinvd();
+        flush_all(FLUSH_CACHE);
 
     return X86EMUL_OKAY;
 }
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 08:34:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:34:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976746.1363883 (Exim 4.92)
	(envelope-from )
	id 1uCDlI-000424-VB; Tue, 06 May 2025 08:34:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976746.1363883; Tue, 06 May 2025 08:34: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 1uCDlI-00041x-SI; Tue, 06 May 2025 08:34:48 +0000
Received: by outflank-mailman (input) for mailman id 976746;
 Tue, 06 May 2025 08:34:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDlH-00041m-Fb
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:34:47 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f68a342d-2a54-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 10:34:45 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43d2d952eb1so29528825e9.1
 for ; Tue, 06 May 2025 01:34:45 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441c0dfc537sm114483145e9.16.2025.05.06.01.34.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01:34: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" 
X-Inumbo-ID: f68a342d-2a54-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746520484; x=1747125284; 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;
        bh=VcW29tlgqCX35x9Q2VuHPxyDBhbeqQG+9E2OIuIdqs8=;
        b=gkqkR7WNfcwiPTZg0HlWA2v5/wlWztp/Fq2UNDCJuKISYKkFlcRDJmkEK4buex0DI2
         et+b1rAkpLwobRvwHTxZ4Of/uTXN+euF0YzGaBt3P+H6VxlkU/jQpEI0jnzZxEjKXq+r
         IkMIYdVkkpKynHM4PN04DZhDZzwAfB0tgLWcw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746520484; x=1747125284;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=VcW29tlgqCX35x9Q2VuHPxyDBhbeqQG+9E2OIuIdqs8=;
        b=qqy3auOxEIMOm5DBaIvu4b5wVsxXO83UvfhofF/1KVtu8cxpAVgj06kd7KXmh45KN5
         2YWJcEYsscHdj60XYhIWUUSC6I7uL5tZ8ICGKBYkL+Yc8HPM/0QEOOGRVRCC7+LJxFYN
         z4vdiNdiMxAM4dH8GYJGwH0HAd0HeNigb0q87BhzoZy/TCouhFduxs8mfA+Me/3g7FGH
         lJzSGLSAzxseJOFIW3B3LF2dse3Yn0fM4p+ULHJSzpZ3mJRZMXXVUQ1v8ilcvuJ2hhQl
         LfYEKatdnr7ECEq6yfS0ea3OYev1NrtpcEVBOBSKzrLYkIzEwTHnJkQ5nJBGs/SDp8Ag
         IsQw==
X-Gm-Message-State: AOJu0YxPicI3qOPKDeyiTH/Ta5CjlBZaYNRc4xReRdDY/hRKfpOXIL7M
	ruj6AnCHshYw0mLUZxuAgzD/mVOpQDawcJqiKrnF0Qq0RJ5ks+ie2vUshZIQ+Pr3r4pnYfto6k5
	Y
X-Gm-Gg: ASbGnct6tIbZrr9FOoX0ERQRB+SKEyRbYbeofZEi+GPNgzyoX+5dB3U3CGHJ/kbI5zo
	4XRQWUIt6lxk9Ro7yZFGb1o6+oIND2GmM4Y4hoMO5uVTz52F75LTxfqxlq6KaVRMU/rUqH80Je3
	+CFjcM2U1G9U+X1k10ImRC5Vn67Uxefwkl/n+cZtuQ9lktK3AhpWpgJfZr8vGUsmJoNwI+dtPIy
	rDXtzACwEg4n4qkTde4oIWiwPNk9ZofzqYa3YwnFtJRYRJ388bGf3fC7dX/nnW/AAJzKbRMqyPb
	U8FNPKsSvFPRXdGap5SqF3eE9Yra/0Tr17cJEr9YGddEhA==
X-Google-Smtp-Source: AGHT+IGAlqormNOZykPxlIggIY/CsIhXy0w5RwQsCodUE6SrqVTWTB/qaz2icYmwkMa/kqwLyTK4Fg==
X-Received: by 2002:a05:600c:5491:b0:43d:5ec:b2f4 with SMTP id 5b1f17b1804b1-441d0fccbf5mr15642135e9.10.1746520484253;
        Tue, 06 May 2025 01:34:44 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Christian Lindig ,
	David Scott ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH 0/8] xen: cache control improvements
Date: Tue,  6 May 2025 10:31:39 +0200
Message-ID: <20250506083148.34963-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

Following series contain some fixes for cache control operations, the
main focus is to reduce the load on big systems when cache control
operations are executed.

Patches 1-4 are bugfixes, while patches starting from 5 are improvements
to the current code.  Patch 9 is an optimization to avoid having to
broadcast cache flushes on all pCPUs on x86.

Thanks, Roger.

Roger Pau Monne (9):
  x86/pv: fix MMUEXT_FLUSH_CACHE to flush all pCPU caches
  x86/pv: fix emulation of wb{,no}invd to flush all pCPU caches
  xen/gnttab: limit cache flush operation to guests allowed cache
    control
  x86/gnttab: do not implement GNTTABOP_cache_flush
  x86/mtrr: use memory_type_changed() in hvm_set_mem_pinned_cacheattr()
  x86/p2m: limit cache flush in memory_type_changed()
  xen/x86: rename cache_flush_permitted() to has_arch_io_resources()
  xen: introduce flag when a domain requires cache control
  xen/x86: track dirty pCPU caches for a given vCPU

 docs/man/xl.cfg.5.pod.in            | 10 +++++++
 tools/include/libxl.h               |  7 +++++
 tools/libs/light/libxl_create.c     |  6 ++++
 tools/libs/light/libxl_types.idl    |  3 ++
 tools/ocaml/libs/xc/xenctrl.ml      |  1 +
 tools/ocaml/libs/xc/xenctrl.mli     |  1 +
 tools/xl/xl_parse.c                 |  2 ++
 xen/arch/arm/dom0less-build.c       | 12 ++++++--
 xen/arch/arm/domain.c               |  3 +-
 xen/arch/arm/domain_build.c         |  6 ++++
 xen/arch/x86/domain.c               | 43 +++++++++++++++++++++++++++++
 xen/arch/x86/hvm/hvm.c              |  2 +-
 xen/arch/x86/hvm/mtrr.c             | 29 ++++---------------
 xen/arch/x86/hvm/svm/svm.c          |  6 ++--
 xen/arch/x86/hvm/vmx/vmcs.c         |  3 +-
 xen/arch/x86/hvm/vmx/vmx.c          |  6 ++--
 xen/arch/x86/include/asm/domain.h   |  9 ++++++
 xen/arch/x86/include/asm/flushtlb.h | 15 ----------
 xen/arch/x86/include/asm/iocap.h    | 19 ++-----------
 xen/arch/x86/include/asm/p2m.h      |  2 +-
 xen/arch/x86/mm.c                   | 21 ++++----------
 xen/arch/x86/mm/p2m-ept.c           |  7 +----
 xen/arch/x86/mm/p2m-pod.c           |  4 +--
 xen/arch/x86/mm/p2m.c               | 13 ++++++++-
 xen/arch/x86/pv/emul-priv-op.c      | 19 ++++++-------
 xen/arch/x86/setup.c                |  7 +++++
 xen/common/domain.c                 |  3 +-
 xen/common/grant_table.c            | 11 ++++++++
 xen/common/memory.c                 |  2 +-
 xen/include/asm-generic/iocap.h     |  2 +-
 xen/include/public/domctl.h         |  4 ++-
 xen/include/xen/iocap.h             | 25 ++---------------
 xen/include/xen/sched.h             |  6 ++++
 33 files changed, 181 insertions(+), 128 deletions(-)

-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 08:34:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:34:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976749.1363905 (Exim 4.92)
	(envelope-from )
	id 1uCDlK-0004QV-Qc; Tue, 06 May 2025 08:34:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976749.1363905; Tue, 06 May 2025 08:34: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 1uCDlK-0004PL-LH; Tue, 06 May 2025 08:34:50 +0000
Received: by outflank-mailman (input) for mailman id 976749;
 Tue, 06 May 2025 08:34:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDlJ-00048v-Jn
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:34:49 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f859a0a5-2a54-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 10:34:48 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43cebe06e9eso33352265e9.3
 for ; Tue, 06 May 2025 01:34:48 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441b2ad781csm205613275e9.8.2025.05.06.01.34.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01:34: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" 
X-Inumbo-ID: f859a0a5-2a54-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746520487; x=1747125287; 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;
        bh=19/KyvkkozHoKYd6THg8hoTBnLfqHO1KkIE+C5r6Ttw=;
        b=DnEpj6Ggz/7xcVhoCfkCW6eRtzC8+kCfh/4vLG/Z1Tz9VUIw0gB2xMaKEa0Hn9Ztyc
         tvMrtz0PSUC+++8ohnfblXlo+ts2qv4RUQDNQl4i9KhvCUBtgVN+2vNo7YKZ4AXceCGq
         fmWircFhNXUT/wFIuMuu5QFmAK2l3zT/DX1sY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746520487; x=1747125287;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=19/KyvkkozHoKYd6THg8hoTBnLfqHO1KkIE+C5r6Ttw=;
        b=mvuNUhrh613unIxfaaZ2feAHxvDtQzELwyREHVZmyJIoKJbS2sun4IA74dZVJzvP6A
         EMlpb79jVqhT3jY9gsrs8ok2lrX8uArueqA53btGupyLO77ce02Ke7P69j+2yWEkNTqz
         jVUxFm+sz5ft1y9KWZXEtKn1UD9D/iZCxFjLgOjvnSFihBiZu6d6617J7nb/hqEVNydf
         BPHgmeNza92Ihhoz9tJyx5+f49xxQckfoKG3WM/qFXJ11RdtT6gF8YHC+0IVj7uCCie8
         H9xLNmFEDg/UmQeKWnZzWYyhue+xQjkBpv0E8VrTEtIkM7rfIkWbB0WrWuyUBGgfbgJC
         YAMQ==
X-Gm-Message-State: AOJu0YzS7NVPDyHLu5L8xohxoVUFfubMCXT7Q9BYBtTTGhqLDYiCbwcB
	I6bB3intj3EMUXV1K2WePShvLvb6d4jxGFuxRE1syfcX0JES7plcaRfqETf/4vHr98Iqp0n2Y9L
	+
X-Gm-Gg: ASbGnct5SpwrEEMwItHDuJIY1sbZ87BES2vCAYrYClfew83n03ItNVxXXriDcdgUuwK
	LuHL0NexbXtI4TNRkF0TWoSKUXOvF1curWoQBgfZooKvuPCI4UbKcSv+366O0JXiYF2DiBwvzIN
	BaTYqHzFDiziWTwZpJaRvvWFN2Aav4xjareAovimpsEJk6I6u21Gt3TR8DyrMGCsSe66MEE8Dnk
	OArjZCw8/xtKoxtt3aR8KxUbM6FHHDo1kH4iorzE7VXEVpx3nvzy2Kwb/4XXfAhTKAlP1fE9fJ5
	NUbFg1oO+S3eH+JPVzf7YZ8yvRp/cbky9kfGYhU9Y7JXCA==
X-Google-Smtp-Source: AGHT+IGeiYHYC7We2Fl1uR/572QDRTgfKbWh2I7K7bHpEmD3xsWylfGZiO1SHAizD8Ez5pgi7kFCDA==
X-Received: by 2002:a05:600c:c17:b0:43c:eeee:b706 with SMTP id 5b1f17b1804b1-441d0531273mr17628335e9.24.1746520487359;
        Tue, 06 May 2025 01:34:47 -0700 (PDT)
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 3/9] xen/gnttab: limit cache flush operation to guests allowed cache control
Date: Tue,  6 May 2025 10:31:42 +0200
Message-ID: <20250506083148.34963-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250506083148.34963-1-roger.pau@citrix.com>
References: <20250506083148.34963-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Whether a domain is allowed to issue cache-control operations is reported
by the cache_flush_permitted() check.  Introduce such check to limit the
availability of GNTTABOP_cache_flush to only guests that are granted cache
control.

Fixes: 18e8d22fe750 ("introduce GNTTABOP_cache_flush")
Signed-off-by: Roger Pau Monné 
---
 xen/common/grant_table.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index e75ff98aff1c..d874ac5f1241 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3780,6 +3780,11 @@ long do_grant_table_op(
 
         if ( unlikely(!guest_handle_okay(cflush, count)) )
             goto out;
+
+        rc = -EPERM;
+        if ( !cache_flush_permitted(current->domain) )
+            goto out;
+
         rc = gnttab_cache_flush(cflush, &opaque_in, count);
         if ( rc >= 0 )
         {
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 08:34:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:34:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976750.1363923 (Exim 4.92)
	(envelope-from )
	id 1uCDlN-0004y3-0S; Tue, 06 May 2025 08:34:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976750.1363923; Tue, 06 May 2025 08: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 1uCDlM-0004xw-TK; Tue, 06 May 2025 08:34:52 +0000
Received: by outflank-mailman (input) for mailman id 976750;
 Tue, 06 May 2025 08:34:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDlL-00041m-Ox
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:34:51 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f9972bec-2a54-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 10:34:50 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-39ee5ac4321so6478568f8f.1
 for ; Tue, 06 May 2025 01:34:50 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099ae32fesm12669233f8f.22.2025.05.06.01.34.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01: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" 
X-Inumbo-ID: f9972bec-2a54-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746520489; x=1747125289; 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;
        bh=p5UfBLcVStfB7Hed8NA5DfE3BRvsSJIoJFqhzuS6DZw=;
        b=TikPXyvOnU2anYiYC+OXdBZxH2AQ3ySb/erSnJdwqkyXrzVk2DASMhpfLD9RI78l5j
         ju/DsiLPqtCd0Aoz7QwpmyedkUsCfiC5qFGxXesV+qXxCSMu1nf8Fxe/B/Rs1emiBV+q
         gIspOu3t59yY1j3igLFGwSdv6tkzWIL6YpPaE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746520489; x=1747125289;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=p5UfBLcVStfB7Hed8NA5DfE3BRvsSJIoJFqhzuS6DZw=;
        b=xUSCApvz1mT0UygWLwa/kA1V1+ftHrN9M3vtKRAKBxxBfb3JECk97YF6T1oJfDUyyT
         PkYKjMNS9paNET/x5wTkgcyNucqT3b558VBuZHq0SB4b8SkTA+QyfZhzeklcdrAmQ6wG
         nsu8P9zM3CY02dG/nZsnQRkN2SciqUaplLL7voGN5VSxmFk3Qf0MCrIX0HgJQTrpyJpS
         RNTyJDXLDlmtMWtv1iEhaT0am1VjmoHSMZGTDs+SiDb2TDfUgRX/GOdDhYT/1PeOeXwF
         +jhfLj7KdpLpDlnDb1Rd6hkMYGIZ6W9fDOEivQB1XdSUJp0Zr60jjQkhkAE6jl2pg5GQ
         UcGw==
X-Gm-Message-State: AOJu0YyVP2HFpPBFVIbqprNdg9XMNBBsZ1pX5P2MmghIznujQk8pFFCa
	2srgh9FrvpPqWBDf4wjTKlbVqnPzhWqn33/EPfC1O5UbUZbdFCWoHgimT8T0R1z9B4dD2JohxFP
	K
X-Gm-Gg: ASbGnctss8B6cNv1Xjzt9m5cnoD5mIc2fAmpV9yxKq7n8rZwBqP5HCbuF9df9yFf0Pi
	XQRLCPDbFn2V8aR8qIC8RKGsTX3uzixdwIFczCKcN+NT72Ay6RTeTccbcfPZe/vjeFLDS1u9SjQ
	WhFrqm9ev1wuYo2sauzaWqAqHfBazDACtxub6tJPrw3xwX6gMHejjlRUgFBhNWZe0rN5PVBmfZ+
	tQFHPODxr0moWu8ae65XFDSZY6Rag/yd1LZf5HFgWtF3WC9Id3GAuIPz21d5k6DTAanUtMQWSF1
	qJM+evdxP3mnTfsMfXg6j5TJeYqTCOmF0Vb0O7t2STP9sHmegB0kUL3h
X-Google-Smtp-Source: AGHT+IG8SbqAp820tgfep77WqAq8u/7HTxpv/gmNciMOaCRPklO3tPbEepKkjQU+MEYnB+mrs5NwOg==
X-Received: by 2002:a05:6000:2a3:b0:3a0:85ad:5ed9 with SMTP id ffacd0b85a97d-3a09fd7a183mr7019642f8f.4.1746520489409;
        Tue, 06 May 2025 01:34:49 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 5/9] x86/mtrr: use memory_type_changed() in hvm_set_mem_pinned_cacheattr()
Date: Tue,  6 May 2025 10:31:44 +0200
Message-ID: <20250506083148.34963-6-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250506083148.34963-1-roger.pau@citrix.com>
References: <20250506083148.34963-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current logic partially open-codes memory_type_changed(), but doesn't
check whether the type change or the cache flush is actually needed.
Instead switch to using memory_type_changed(), at possibly a higher expense
cost of not exclusively issuing cache flushes when limiting cacheability.

However using memory_type_changed() has the benefit of limiting
recalculations and cache flushes to strictly only when it's meaningful due
to the guest configuration, like having devices or IO regions assigned.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/hvm/mtrr.c | 22 +++-------------------
 1 file changed, 3 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 797f2ae7fd3a..b88e81eb44b1 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -605,22 +605,8 @@ int hvm_set_mem_pinned_cacheattr(struct domain *d, uint64_t gfn_start,
 
                 type = range->type;
                 call_rcu(&range->rcu, free_pinned_cacheattr_entry);
-                p2m_memory_type_changed(d);
-                switch ( type )
-                {
-                case X86_MT_UCM:
-                    /*
-                     * For EPT we can also avoid the flush in this case;
-                     * see epte_get_entry_emt().
-                     */
-                    if ( hap_enabled(d) && cpu_has_vmx )
-                case X86_MT_UC:
-                        break;
-                    /* fall through */
-                default:
-                    flush_all(FLUSH_CACHE);
-                    break;
-                }
+                memory_type_changed(d);
+
                 return 0;
             }
         domain_unlock(d);
@@ -682,9 +668,7 @@ int hvm_set_mem_pinned_cacheattr(struct domain *d, uint64_t gfn_start,
 
     xfree(newr);
 
-    p2m_memory_type_changed(d);
-    if ( type != X86_MT_WB )
-        flush_all(FLUSH_CACHE);
+    memory_type_changed(d);
 
     return rc;
 }
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 08:34:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:34:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976747.1363893 (Exim 4.92)
	(envelope-from )
	id 1uCDlK-0004Fr-5Y; Tue, 06 May 2025 08:34:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976747.1363893; Tue, 06 May 2025 08:34: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 1uCDlK-0004Fk-2J; Tue, 06 May 2025 08:34:50 +0000
Received: by outflank-mailman (input) for mailman id 976747;
 Tue, 06 May 2025 08:34:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDlI-00041m-5G
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:34:48 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f7235d67-2a54-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 10:34:46 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-39141ffa9fcso5709969f8f.0
 for ; Tue, 06 May 2025 01:34:46 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099ae7cc6sm13132515f8f.55.2025.05.06.01.34.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01:34: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" 
X-Inumbo-ID: f7235d67-2a54-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746520485; x=1747125285; 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;
        bh=st45ZJ9i+zKbNGPJ/gNiCriyCwXBLOobUVRy9hZSFAA=;
        b=a8ZLtsKkNfiDnWk9AHFIHBY98W9ixl0Z71swNHBGKXOBG4GnMUYVx+fLGP3tAj86yi
         gFECgZUXWV7kXkO1EYoqAmUnS2Pw3l3SrO6IC8i19OfpTCnNkHRR6KC61Nux3dIEgFA1
         Ee67in+25XPxQxgJ0q72BsyPcRlv/1YUW7hIU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746520485; x=1747125285;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=st45ZJ9i+zKbNGPJ/gNiCriyCwXBLOobUVRy9hZSFAA=;
        b=dGq9O4wPMzAzOemq3HKZTGbxnON8dWdtVTcNcuBf35KCyHL9s7R+HDkB0rnrfBQ+xx
         nejsUq5XU028k5o7yOC6UftlsCvjm3BCObobu9fpdeNbNRQ01pco+l0M/0MBj6oZ0a8E
         7yF7KSRm5DZcp6QLgB6a0V4/JTiwGIu9s3WqQwOG/OkmnUSj2vh2f9frCD4T/mbudqAu
         kemmO83jfrhjzF7mriEMOzLgOViOoOBNIlWDPw5XmBTakoU0LJXtu2BfBHZvVW3XKjkS
         xKVDb0W6ZXsuU3tC1CjvnKIKENG45yTasbmeTA2oQvINoju8CCusfMephHV7q8HHCgPg
         0Jpg==
X-Gm-Message-State: AOJu0YxeXIN8X/ohwUUdYv4vqJJLKULTN9079qH2/H1YI+7oP88qZO+u
	xPtl6zWNkOaAFFOH9f5KyNbfyXEUQzzGFcG0U7RN5svUy23PqHhfhvYVnDHYYccuaOQWVuGdkDh
	R
X-Gm-Gg: ASbGnct+zEM8EBXwl6ldZJaGujUoVjrfoK3L13LAwsl5ScUpRnIxri9+0wtNPaqZEh4
	37xCXPtfL5r927DO3Z4b/o1GhpMR5NflsZLcQQkm+IpvVMVa8gJPnw0SIafd54b4wWG0Gtxq7HI
	g3D5Y313vm04PI+tXFMzXwhN4HlQBqewOcQUIr0fHPycnz/m1M8ROftyUmNBYjQIsKd3iHho5Qk
	4pUUffYDRmGqz9i5aEUFs6RzDjryR/PK/nKWpQv7uxp9wOs7GsCxDifabRt3UtYGeixYvoLpeA1
	KITHmpNvSAfoXZ40bRaGzkVzO23TxXzxFFk11LTX89IZIA==
X-Google-Smtp-Source: AGHT+IHVj/uKcBnWhZL2WS4VG4BiWU+QA7k/IU9uSQePRA0qdu0xcCV8sfNEBXnjmr16UVzoeHKt1g==
X-Received: by 2002:a05:6000:4383:b0:39c:f0d:9146 with SMTP id ffacd0b85a97d-3a0ac1ff746mr1264138f8f.45.1746520485296;
        Tue, 06 May 2025 01:34:45 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 1/9] x86/pv: fix MMUEXT_FLUSH_CACHE to flush all pCPU caches
Date: Tue,  6 May 2025 10:31:40 +0200
Message-ID: <20250506083148.34963-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250506083148.34963-1-roger.pau@citrix.com>
References: <20250506083148.34963-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The implementation of MMUEXT_FLUSH_CACHE is bogus, as it doesn't account to
flush the cache of any previous pCPU where the current vCPU might have run,
and hence is likely to not work as expected.

Fix this by resorting to use the same logic as MMUEXT_FLUSH_CACHE_GLOBAL,
which will be correct in all cases.

Fixes: 534ffcb416bb ("Fix WBINVD by adding a new hypercall.")
Signed-off-by: Roger Pau Monné 
---
Alternatively, the hypercall could be made correct by keeping track of the
pCPUs the vCPU has run on since the last cache flush.  That's however more
work.  See later in the series.
---
 xen/arch/x86/mm.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 66c15a3c864f..38e214352201 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3805,14 +3805,11 @@ long do_mmuext_op(
             break;
 
         case MMUEXT_FLUSH_CACHE:
-            if ( unlikely(currd != pg_owner) )
-                rc = -EPERM;
-            else if ( unlikely(!cache_flush_permitted(currd)) )
-                rc = -EACCES;
-            else
-                wbinvd();
-            break;
-
+            /*
+             * Dirty pCPU caches where the current vCPU has been scheduled are
+             * not tracked, and hence we need to resort to a global cache
+             * flush for correctness.
+             */
         case MMUEXT_FLUSH_CACHE_GLOBAL:
             if ( unlikely(currd != pg_owner) )
                 rc = -EPERM;
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 08:34:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:34:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976751.1363933 (Exim 4.92)
	(envelope-from )
	id 1uCDlO-0005E5-8C; Tue, 06 May 2025 08:34:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976751.1363933; Tue, 06 May 2025 08: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 1uCDlO-0005DP-3i; Tue, 06 May 2025 08:34:54 +0000
Received: by outflank-mailman (input) for mailman id 976751;
 Tue, 06 May 2025 08:34:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDlM-00048v-7Q
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:34:52 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa5497cd-2a54-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 10:34:51 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-43d2d952eb1so29529405e9.1
 for ; Tue, 06 May 2025 01:34:51 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441b2b20b36sm207541225e9.25.2025.05.06.01.34.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01: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" 
X-Inumbo-ID: fa5497cd-2a54-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746520491; x=1747125291; 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;
        bh=fgghoeas14+y+/fNB0eokRVfIB1w/ZzOUGRan/5YZkA=;
        b=PlC5a2Y5PlpVAQwWiv0r0U/TDy/bZtUJRfwTKGNhnvC1jRMnOoaWZcVGhBVPYmo8sl
         OuMAsNpnjJg7YHKu08OhT5UaSW1+kycz3gr7H0vPkK2kvHaGC0YLZbsmdJq5Su4RXDQI
         a8ChVLK63iTullXW5ZwVSv67pLBPyerbGgoKM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746520491; x=1747125291;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fgghoeas14+y+/fNB0eokRVfIB1w/ZzOUGRan/5YZkA=;
        b=iP6iRIF5xDMFp0exGxq8CyH/ov7Mm9yweGKtb5lNQzQL0m+tJPK6S9VKq+d0RJlgLo
         Yfj6PwcqHtt7gSqOGeFhCoOtjzLMWdfnC/fYQhpxR9ANHY/c/KnleJRT6TVNfphe6lw9
         fJici6B4vvJABnZaMS1MFyGaGg4BlhJcT34l2rrxcGCDihA3M2/IelAdMjGMoNGILjXF
         48l2rxBCcjs3k9WH01PfL76fjHGVUOc9s53AfoxFFLM9OII0ta8lJe500zZHK+hROk1v
         C8n0iIMq5zQuNUK8u14CCw1aC+x2V2P297FN5acK00pjETmiZkvpDl82BI/pwsC+lzfT
         tefg==
X-Gm-Message-State: AOJu0Yzzb1AkR0U4HyfAFebJfmNWOvU6eSVg1f1+ucMNJc8DpSKRPCqE
	Fetk3PDU8cFlis9sKAsGYD7LLrLgacuZoL9Sk2c1ACAjFS9kyOXp4mljKQaVzcThlAofH3WbpYk
	L
X-Gm-Gg: ASbGncsjUBEcCgHWNykAr46pkVYihymmuZbn0RTRQ183BDwQAW9BTxDHK1q2q3kuey8
	5kJPOu87wJgF6zcaZNyC3LMq947nElLVhJaX8roULJ3YftgjnQgMLzyIIm9wVXwnW9RsiAZ3mOh
	zs4+9EmnlzhWFSVcO5ITEmeSHNMPs8u5y6jV3rBZllqkcw3vSVbzsMpccyvv7uYFNJcNX2OM5KS
	xzk7PZcafzdtvQvl8GgjSysMOIPMBbdFuKepbaqemTXqjtWDdjzjjdrZZwAgUxrILLIarNSFocX
	nEakoQLtNwTWpRiK/XhXcc5VUQMfUJVshCVEKFQ5/al+xg==
X-Google-Smtp-Source: AGHT+IFy3ozUxsGi2jitSr9ubKsaPbVL8wW6yqXgzNmoNPsoSYOYTdbpTX/VTHQ8XuEd/keRVE0rUQ==
X-Received: by 2002:a05:600c:5010:b0:43d:526:e0ce with SMTP id 5b1f17b1804b1-441d100b3c5mr16425255e9.21.1746520490691;
        Tue, 06 May 2025 01:34:50 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 6/9] x86/p2m: limit cache flush in memory_type_changed()
Date: Tue,  6 May 2025 10:31:45 +0200
Message-ID: <20250506083148.34963-7-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250506083148.34963-1-roger.pau@citrix.com>
References: <20250506083148.34963-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Only do the cache flush when there's a p2m type change to propagate,
otherwise there's no change in the p2m effective caching attributes.

If the p2m memory_type_changed hook is not set p2m_memory_type_changed() is
a no-op, no recalculation of caching attributes is needed, nor flushing of
the previous cache contents.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/hvm/mtrr.c        |  3 +--
 xen/arch/x86/include/asm/p2m.h |  2 +-
 xen/arch/x86/mm/p2m.c          | 13 ++++++++++++-
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index b88e81eb44b1..e7acfb6e8dc4 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -767,9 +767,8 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr, NULL, hvm_load_mtrr_msr, 1,
 void memory_type_changed(struct domain *d)
 {
     if ( (is_iommu_enabled(d) || cache_flush_permitted(d)) &&
-         d->vcpu && d->vcpu[0] )
+         d->vcpu && d->vcpu[0] && p2m_memory_type_changed(d) )
     {
-        p2m_memory_type_changed(d);
         flush_all(FLUSH_CACHE);
     }
 }
diff --git a/xen/arch/x86/include/asm/p2m.h b/xen/arch/x86/include/asm/p2m.h
index b9ce7d8705ba..4358cc15a2a1 100644
--- a/xen/arch/x86/include/asm/p2m.h
+++ b/xen/arch/x86/include/asm/p2m.h
@@ -700,7 +700,7 @@ void p2m_pod_dump_data(struct domain *d);
 #ifdef CONFIG_HVM
 
 /* Report a change affecting memory types. */
-void p2m_memory_type_changed(struct domain *d);
+bool p2m_memory_type_changed(struct domain *d);
 
 /* Called by p2m code when demand-populating a PoD page */
 bool
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 3a39b5d1246b..b9a7c2dc5302 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -126,12 +126,21 @@ static void _memory_type_changed(struct p2m_domain *p2m)
 {
     if ( p2m->memory_type_changed )
         p2m->memory_type_changed(p2m);
+    else
+        ASSERT_UNREACHABLE();
 }
 
-void p2m_memory_type_changed(struct domain *d)
+bool p2m_memory_type_changed(struct domain *d)
 {
     struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
 
+    /*
+     * The p2m memory_type_changed hook will be the same for the host p2m or
+     * the altp2ms, do the check early and return if not set.
+     */
+    if ( !hostp2m->memory_type_changed )
+        return false;
+
     p2m_lock(hostp2m);
 
     _memory_type_changed(hostp2m);
@@ -154,6 +163,8 @@ void p2m_memory_type_changed(struct domain *d)
     }
 
     p2m_unlock(hostp2m);
+
+    return true;
 }
 
 int p2m_set_ioreq_server(struct domain *d,
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 08:34:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:34:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976752.1363943 (Exim 4.92)
	(envelope-from )
	id 1uCDlP-0005UQ-HJ; Tue, 06 May 2025 08:34:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976752.1363943; Tue, 06 May 2025 08:34: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 1uCDlP-0005Tr-DE; Tue, 06 May 2025 08:34:55 +0000
Received: by outflank-mailman (input) for mailman id 976752;
 Tue, 06 May 2025 08:34:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDlO-00041m-5V
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:34:54 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fafbc382-2a54-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 10:34:52 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43cebe06e9eso33352915e9.3
 for ; Tue, 06 May 2025 01:34:52 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099b107c4sm12878526f8f.76.2025.05.06.01.34.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01:34: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" 
X-Inumbo-ID: fafbc382-2a54-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746520492; x=1747125292; 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;
        bh=pUxyovW21TXrkfyeOo/OFKomE9nboVw2dKjf//O9Bi4=;
        b=VKSpbpMHxyF6v5UdV+XV58q70CKt/G/mH0tA2TQMd47OYsX94WpAvNOaOUZHJxiDez
         pcxBOirR7Jygtc5/k1weWmHoHHO0jcXt7wXJXH5nm4aRiZ3WaIFaah2yUSErFGK4Quro
         DaMF5VrmeEbb2Qyka8IudGzSXlbg2FA3tD/6A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746520492; x=1747125292;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=pUxyovW21TXrkfyeOo/OFKomE9nboVw2dKjf//O9Bi4=;
        b=QnQcZE4SdpwQsaZQRhiISf+1KUXCawS4JXqw06iTEypx1IQUiXfOCFJef8MacBdS4G
         hvxyJon1oANVXX3x5Qj8cFl5rsibvUPqsEYauVHZp8F0brMaIWca1UpQsEk83dc8OHYJ
         Qocw6pea2/B7VE3AT7z2q6CjC1dAkUrv002yap/sTYZHmV6WbDPqCGkWVGVf6wGYSvwT
         Yh+NseotpB3c7xlKSLrlWJkhaWC0eX1tME22MxYWp0mhVb7k52M5eUXOh8Hz5BlbLMFs
         Jsn8dw8Jjloz0qfOFubuhizla/C36HmdPAWddFPpzLQPUJtU1iP2Bwc2kUpL/rtJJM7C
         gvlw==
X-Gm-Message-State: AOJu0Ywoawg7APmpnrbpmdlxc84L8g6eTivOVpWdfZZMr+VUVtiIS4VN
	WpVe9VeLXOSYicnvYyTVUm7jJPiBB2+zHj5dXIp+ym7NMyJlz81M/PTigAJ1Wm39XTtDw+6lwxv
	o
X-Gm-Gg: ASbGnctSYsvhCp3zKXyorh8ny+G6iTINxlcg/jxaztbvU8jANJN8PaVLeGP3ODCmz8L
	Igh2gc5X0I9oonYH/chFGoY3QmE4dS8XjaTF+hFX783r2DRe6USpWA904iozL8UKmIE1mkstwF1
	umzf103IpBLUIxxIYwOhA6+E+tKaWcgXE8A6d8kmvIfMT7iTHm/GCuiNGKZ9z0u/Z5k9sdq03ku
	ZciKXZfPfKuPEYAGIk2G66OnpHC1/nwsj4hoKyVlAPsKCn7Va4DfHKt4Jhac4sHsDxbGZxjX0W9
	Min0RIya9w4ELWZ21HCi1L4GQUmGBV4LQB3d4N2jt6wN6gzFZw4smmWM
X-Google-Smtp-Source: AGHT+IFr9NSIj+NlQPKwWheTGOLpyFdRFPuyLgygAmUJmDy/hDkqsc6dOXunC/GQzkZLsGAngTYnFw==
X-Received: by 2002:a05:600c:4f01:b0:43b:ca39:6c7d with SMTP id 5b1f17b1804b1-441d04f46b2mr18694515e9.3.1746520491734;
        Tue, 06 May 2025 01:34:51 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 7/9] xen/x86: rename cache_flush_permitted() to has_arch_io_resources()
Date: Tue,  6 May 2025 10:31:46 +0200
Message-ID: <20250506083148.34963-8-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250506083148.34963-1-roger.pau@citrix.com>
References: <20250506083148.34963-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

To better describe the underlying implementation.  Define
cache_flush_permitted() as an alias of has_arch_io_resources(), so that
current users of cache_flush_permitted() are not effectively modified.

With the introduction of the new handler, change some of the call sites of
cache_flush_permitted() to instead use has_arch_io_resources() as such
callers are not after whether cache flush is enabled, but rather whether
the domain has any IO resources assigned.

Take the opportunity to adjust l1_disallow_mask() to use the newly
introduced has_arch_io_resources() macro.

No functional change intended.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/include/asm/iocap.h | 4 +++-
 xen/arch/x86/mm.c                | 3 +--
 xen/arch/x86/mm/p2m-pod.c        | 4 ++--
 xen/common/memory.c              | 2 +-
 xen/include/asm-generic/iocap.h  | 4 +++-
 5 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/include/asm/iocap.h b/xen/arch/x86/include/asm/iocap.h
index 53d87ae8a334..61d026dbf5f6 100644
--- a/xen/arch/x86/include/asm/iocap.h
+++ b/xen/arch/x86/include/asm/iocap.h
@@ -15,10 +15,12 @@
 #define ioports_access_permitted(d, s, e)               \
     rangeset_contains_range((d)->arch.ioport_caps, s, e)
 
-#define cache_flush_permitted(d)                        \
+#define has_arch_io_resources(d)                        \
     (!rangeset_is_empty((d)->iomem_caps) ||             \
      !rangeset_is_empty((d)->arch.ioport_caps))
 
+#define cache_flush_permitted has_arch_io_resources
+
 static inline int ioports_permit_access(struct domain *d, unsigned long s,
                                         unsigned long e)
 {
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 38e214352201..59b60b1e62a7 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -172,8 +172,7 @@ static DEFINE_SPINLOCK(subpage_ro_lock);
 
 #define l1_disallow_mask(d)                                     \
     (((d) != dom_io) &&                                         \
-     (rangeset_is_empty((d)->iomem_caps) &&                     \
-      rangeset_is_empty((d)->arch.ioport_caps) &&               \
+     (!has_arch_io_resources(d) &&                              \
       !has_arch_pdevs(d) &&                                     \
       is_pv_domain(d)) ?                                        \
      L1_DISALLOW_MASK : (L1_DISALLOW_MASK & ~PAGE_CACHE_ATTRS))
diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index df2a1cc0749b..05633fe2ac88 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -338,7 +338,7 @@ p2m_pod_set_mem_target(struct domain *d, unsigned long target)
 
     ASSERT( pod_target >= p2m->pod.count );
 
-    if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
+    if ( has_arch_pdevs(d) || has_arch_io_resources(d) )
         ret = -ENOTEMPTY;
     else
         ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
@@ -1395,7 +1395,7 @@ guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
     if ( !paging_mode_translate(d) )
         return -EINVAL;
 
-    if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
+    if ( has_arch_pdevs(d) || has_arch_io_resources(d) )
         return -ENOTEMPTY;
 
     do {
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8ca4e1a8425b..46620ed8253d 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -86,7 +86,7 @@ static unsigned int max_order(const struct domain *d)
     unsigned int order = domu_max_order;
 
 #ifdef CONFIG_HAS_PASSTHROUGH
-    if ( cache_flush_permitted(d) && order < ptdom_max_order )
+    if ( has_arch_io_resources(d) && order < ptdom_max_order )
         order = ptdom_max_order;
 #endif
 
diff --git a/xen/include/asm-generic/iocap.h b/xen/include/asm-generic/iocap.h
index dd7cb45488f7..664bbc8971fe 100644
--- a/xen/include/asm-generic/iocap.h
+++ b/xen/include/asm-generic/iocap.h
@@ -2,9 +2,11 @@
 #ifndef __ASM_GENERIC_IOCAP_H__
 #define __ASM_GENERIC_IOCAP_H__
 
-#define cache_flush_permitted(d)                        \
+#define has_arch_io_resources(d)                        \
     (!rangeset_is_empty((d)->iomem_caps))
 
+#define cache_flush_permitted has_arch_io_resources
+
 #endif /* __ASM_GENERIC_IOCAP_H__ */
 
 /*
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 08:34:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:34:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976753.1363947 (Exim 4.92)
	(envelope-from )
	id 1uCDlP-0005YH-TV; Tue, 06 May 2025 08:34:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976753.1363947; Tue, 06 May 2025 08:34: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 1uCDlP-0005WU-O6; Tue, 06 May 2025 08:34:55 +0000
Received: by outflank-mailman (input) for mailman id 976753;
 Tue, 06 May 2025 08:34:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDlO-00048v-Nn
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:34:54 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fbf559b1-2a54-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 10:34:54 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43cf06eabdaso43079385e9.2
 for ; Tue, 06 May 2025 01:34:54 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441b2af306bsm208429945e9.21.2025.05.06.01.34.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01:34: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" 
X-Inumbo-ID: fbf559b1-2a54-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746520493; x=1747125293; 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;
        bh=jVsCpnQ84evwLMOD0Ne9LGSyDVtOtlci+rB7YWLWgTI=;
        b=lgGi3/G/ubnc6ViHuYdQBzRzbBnJOePxnSXhUQfsr+F/GcHn5cCBXd9In5ejiC6SOw
         Obu35BuPi8+xiVNkGK0/Y8g8G0W3XK9ssMBFn6PRL0OatHuhvz1qZLb6bTfr7GB6DWXy
         9eeJ0V6HsGgyjk/mAHQsay9UPdjMPH2qjXNdE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746520493; x=1747125293;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jVsCpnQ84evwLMOD0Ne9LGSyDVtOtlci+rB7YWLWgTI=;
        b=Ylq1yXOGYCHIkur9iKrH5X92oBf0JYDyrq74CFUE9p4yefxyNZzv54GHjoPI7hnaTi
         L5u3lDXQibbVABnS6z0QbwDjj/eTajVawFVY9Hecdvn0Z6/ZP/dNJcK1pIGI2vW+TXMT
         12dRbskD9Fk6R9GByhs3npsPOeAcSsLXBG5qmkwT5c0EYV2+5iNaoF+lrpOsNDf9xa30
         6bjOZuDtBhZjO8AIhhY2mCGdRK9UKb9j0/H8TmbUM59c2OQIlIL5D/DJIPJNBtJUYxS2
         bU3Vo97EX0tubzQMPaJFWYKBTo29+9R3fO9I4sBaKFAHrm4PfY6cSpA8kDZqxPsJ9Bn4
         Usrg==
X-Gm-Message-State: AOJu0YxkBpD78jDmGiIcPi0TzplSF++wrykFbeXOywggQnh/VR4CukN2
	nY0VRQELv1H6s2M4yjHk555YGMCC9MCrwYSGoB343hpGCugwAuwh4scxx/5EUKHRkeWH+LTM4z8
	6
X-Gm-Gg: ASbGncsyLt8d2XtBflf3x7tFTaJEC6JOY5Ozlt3KMjpIKIxUhzR0ecGPED1cAmSoSco
	JysNVV5bzasgw0Rkjn0U6lfQIcbDKt5yfyncbX+uUboAXe9J5RGHHfm5jVLiJ8DOg8P3XpilAYV
	h7rEWhyIAabaEafsSNfmFswUtxoWTLm5cyJjCOvn8LeZZ+87doNLVXD+6Te8SuMAKn9ZnMFuv5V
	aQ7DA6wONMbFcG857tO73CUThOMKtqbBP3F6SvPdctcnduiwkljqAmKqR3d5g96Q+hOU6QQWywm
	3sEHsB2x1FVqA8/EcRAPPnarCUoIdtYMIaxw3q/hV6vZgA==
X-Google-Smtp-Source: AGHT+IF3dBRn3/Jgs4mw0xEm6RRkSp1VNCEoLHtuUvy28npJedhfACuCeVrkkTxKolBgMX9AMQ39qw==
X-Received: by 2002:a05:600c:4690:b0:43d:762:e0c4 with SMTP id 5b1f17b1804b1-441d054c744mr18730875e9.27.1746520492790;
        Tue, 06 May 2025 01:34:52 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Christian Lindig ,
	David Scott ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH 8/9] xen: introduce flag when a domain requires cache control
Date: Tue,  6 May 2025 10:31:47 +0200
Message-ID: <20250506083148.34963-9-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250506083148.34963-1-roger.pau@citrix.com>
References: <20250506083148.34963-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Such flag is added to the domain create hypercall, and a matching option is
added to xl and libxl to set the flag: `cache_control`.  When the flag is
set, the domain is allowed the usage of cache control operations.  If the
flag is not explicitly set, libxl will set it if the domain has any `iomem`
or `ioports` ranges assigned.

Modify cache_flush_permitted() helper so that it's return value is no
longer based on the IO resources assigned to the domain, but rather whether
the domain has been explicitly allowed control over the cache, or if it has
IOMMU support and there's a single IOMMU in the system that doesn't allow
forcing snooping behind the guest back.  As a result of this, the return of
cache_flush_permitted() is constant for the lifetime of a domain, based on
the domain creation flags and the capabilities of the IOMMU if enabled
for the domain.

Since cache control is now known at domain creation, and doesn't change for
the lifetime of a domain, the cache related checks can be simplified,
specially in iomem_{permit,deny}_access() and
ioports_{permit,deny}_access(), as the EPT EMT values won't depend on
whether the domain has IO resources assigned, but rather chosen at creation
time.

As cache_flush_permitted() now also takes into account if a domain has an
IOMMU assigned, and whether the IOMMU supports forcing snooping, some of
the checks can be simplified to drop the iommu_snoop or is_iommu_enabled()
checks previously used in conjunction with cache_flush_permitted().

Signed-off-by: Roger Pau Monné 
---
 docs/man/xl.cfg.5.pod.in         | 10 ++++++++++
 tools/include/libxl.h            |  7 +++++++
 tools/libs/light/libxl_create.c  |  6 ++++++
 tools/libs/light/libxl_types.idl |  3 +++
 tools/ocaml/libs/xc/xenctrl.ml   |  1 +
 tools/ocaml/libs/xc/xenctrl.mli  |  1 +
 tools/xl/xl_parse.c              |  2 ++
 xen/arch/arm/dom0less-build.c    | 12 ++++++++++--
 xen/arch/arm/domain.c            |  3 ++-
 xen/arch/arm/domain_build.c      |  6 ++++++
 xen/arch/x86/hvm/mtrr.c          |  2 +-
 xen/arch/x86/hvm/vmx/vmcs.c      |  3 +--
 xen/arch/x86/hvm/vmx/vmx.c       |  2 +-
 xen/arch/x86/include/asm/iocap.h | 19 ++-----------------
 xen/arch/x86/mm/p2m-ept.c        |  7 +------
 xen/arch/x86/setup.c             |  7 +++++++
 xen/common/domain.c              |  3 ++-
 xen/include/asm-generic/iocap.h  |  2 --
 xen/include/public/domctl.h      |  4 +++-
 xen/include/xen/iocap.h          | 25 ++-----------------------
 xen/include/xen/sched.h          |  6 ++++++
 21 files changed, 74 insertions(+), 57 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 7339c44efd54..d61685de4db3 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -1705,6 +1705,16 @@ This feature is a B.
 
 =back
 
+=item B
+
+If this option is B, Xen allows the guest to perform cache control
+operations.
+
+If this option is missing the default will be set based on whether there are
+any iomem or ioports (if applicable) assigned to the guest.  Note that
+enabling passthrough support can also allow guest cache control operations
+depending on the IOMMU features.
+
 =back
 
 =head2 Paravirtualised (PV) Guest Specific Options
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index b7ad7735ca4c..9a55e98f28bb 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -647,6 +647,13 @@
  */
 #define LIBXL_HAVE_DT_OVERLAY_DOMAIN 1
 
+/*
+ * LIBXL_HAVE_CACHE_CONTROL indicates the presence of cache_control boolean
+ * field in libxl_domain_build_info.  The field signals whether a domain is
+ * allowed access to cache control operations.
+ */
+#define LIBXL_HAVE_CACHE_CONTROL 1
+
 /*
  * libxl memory management
  *
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index e03599ea99d1..469fa306e2f0 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -493,6 +493,9 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         b_info->bootloader_user =
             libxl__strdup(gc, getenv("LIBXL_BOOTLOADER_USER"));
 
+    libxl_defbool_setdefault(&b_info->cache_control,
+                             b_info->num_iomem || b_info->num_ioports);
+
     return 0;
 }
 
@@ -667,6 +670,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
         if (libxl_defbool_val(b_info->vpmu))
             create.flags |= XEN_DOMCTL_CDF_vpmu;
 
+        if (libxl_defbool_val(b_info->cache_control))
+            create.flags |= XEN_DOMCTL_CDF_cache_control;
+
         assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
         LOG(DETAIL, "passthrough: %s",
             libxl_passthrough_to_string(info->passthrough));
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 9bb296993199..59303e8df74a 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -737,6 +737,9 @@ libxl_domain_build_info = Struct("domain_build_info",[
 
     ("vpmu", libxl_defbool),
 
+    # Allow guest access to cache control instructions.
+    ("cache_control", libxl_defbool),
+
     ], dir=DIR_IN,
        copy_deprecated_fn="libxl__domain_build_info_copy_deprecated",
 )
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 2690f9a92316..15ea2cbb0490 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -70,6 +70,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_cache_control
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index febbe1f6ae3f..c9ce99a62c16 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -63,6 +63,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_cache_control
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 089a88935aff..b5f3133581cb 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2993,6 +2993,8 @@ skip_usbdev:
 
     xlu_cfg_get_defbool(config, "vpmu", &b_info->vpmu, 0);
 
+    xlu_cfg_get_defbool(config, "cache_control", &b_info->cache_control, 0);
+
     xlu_cfg_destroy(config);
 }
 
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a356fc94fc4d..e0f0b828d0b6 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -1106,6 +1106,8 @@ void __init create_domUs(void)
 
             if ( !strcmp(dom0less_iommu, "enabled") )
                 iommu = true;
+            else
+                d_cfg.flags |= XEN_DOMCTL_CDF_cache_control;
         }
 
         if ( (flags & CDF_hardware) && !(flags & CDF_directmap) &&
@@ -1120,8 +1122,14 @@ void __init create_domUs(void)
             has_dtb = true;
         }
 
-        if ( iommu_enabled && (iommu || has_dtb) )
-            d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+        if ( iommu || has_dtb )
+            /*
+             * Domain has devices assigned, either enable IOMMU support (if
+             * present), or explicitly allow cache control operations for DMA
+             * coherency.
+             */
+            d_cfg.flags |= iommu_enabled ? XEN_DOMCTL_CDF_iommu
+                                         : XEN_DOMCTL_CDF_cache_control;
 
         if ( !dt_property_read_u32(node, "nr_spis", &d_cfg.arch.nr_spis) )
         {
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 45aeb8bddcb0..1a8503f8d471 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -612,7 +612,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
     unsigned int max_vcpus;
     unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
     unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu |
-                                   XEN_DOMCTL_CDF_xs_domain );
+                                   XEN_DOMCTL_CDF_xs_domain |
+                                   XEN_DOMCTL_CDF_cache_control);
     unsigned int sve_vl_bits = sve_decode_vl(config->arch.sve_vl);
 
     if ( (config->flags & ~flags_optional) != flags_required )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 270a6b97e42c..0e7e6a6ac044 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2381,6 +2381,12 @@ void __init create_dom0(void)
 
     if ( iommu_enabled )
         dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+    else
+        /*
+         * A hardware domain without IOMMU will need cache control to
+         * ensure DMA coherency.
+         */
+        dom0_cfg.flags |= XEN_DOMCTL_CDF_cache_control;
 
     if ( opt_dom0_sve )
     {
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index e7acfb6e8dc4..887994d2b984 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -766,7 +766,7 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr, NULL, hvm_load_mtrr_msr, 1,
 
 void memory_type_changed(struct domain *d)
 {
-    if ( (is_iommu_enabled(d) || cache_flush_permitted(d)) &&
+    if ( cache_flush_permitted(d) &&
          d->vcpu && d->vcpu[0] && p2m_memory_type_changed(d) )
     {
         flush_all(FLUSH_CACHE);
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index a44475ae15bd..fba62b5d47d8 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1921,8 +1921,7 @@ void cf_check vmx_do_resume(void)
          *  2: execute wbinvd on all dirty pCPUs when guest wbinvd exits.
          * If VT-d engine can force snooping, we don't need to do these.
          */
-        if ( has_arch_pdevs(v->domain) && !iommu_snoop
-                && !cpu_has_wbinvd_exiting )
+        if ( cache_flush_permitted(v->domain) && !cpu_has_wbinvd_exiting )
         {
             int cpu = v->arch.hvm.vmx.active_cpu;
             if ( cpu != -1 )
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 827db6bdd807..639882ceb216 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3840,7 +3840,7 @@ static void vmx_do_extint(struct cpu_user_regs *regs)
 
 static void cf_check vmx_wbinvd_intercept(void)
 {
-    if ( !cache_flush_permitted(current->domain) || iommu_snoop )
+    if ( !cache_flush_permitted(current->domain) )
         return;
 
     if ( cpu_has_wbinvd_exiting )
diff --git a/xen/arch/x86/include/asm/iocap.h b/xen/arch/x86/include/asm/iocap.h
index 61d026dbf5f6..d3bb66f0e97a 100644
--- a/xen/arch/x86/include/asm/iocap.h
+++ b/xen/arch/x86/include/asm/iocap.h
@@ -19,31 +19,16 @@
     (!rangeset_is_empty((d)->iomem_caps) ||             \
      !rangeset_is_empty((d)->arch.ioport_caps))
 
-#define cache_flush_permitted has_arch_io_resources
-
 static inline int ioports_permit_access(struct domain *d, unsigned long s,
                                         unsigned long e)
 {
-    bool flush = cache_flush_permitted(d);
-    int ret = rangeset_add_range(d->arch.ioport_caps, s, e);
-
-    if ( !ret && !is_iommu_enabled(d) && !flush )
-        /* See comment in iomem_permit_access(). */
-        memory_type_changed(d);
-
-    return ret;
+    return rangeset_add_range(d->arch.ioport_caps, s, e);
 }
 
 static inline int ioports_deny_access(struct domain *d, unsigned long s,
                                       unsigned long e)
 {
-    int ret = rangeset_remove_range(d->arch.ioport_caps, s, e);
-
-    if ( !ret && !is_iommu_enabled(d) && !cache_flush_permitted(d) )
-        /* See comment in iomem_deny_access(). */
-        memory_type_changed(d);
-
-    return ret;
+    return rangeset_remove_range(d->arch.ioport_caps, s, e);
 }
 
 #endif /* __X86_IOCAP_H__ */
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 0cf6818c13f0..d3ce422d76d7 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -505,12 +505,7 @@ int epte_get_entry_emt(struct domain *d, gfn_t gfn, mfn_t mfn,
         return -1;
     }
 
-    /*
-     * Conditional must be kept in sync with the code in
-     * {iomem,ioports}_{permit,deny}_access().
-     */
-    if ( type != p2m_mmio_direct && !is_iommu_enabled(d) &&
-         !cache_flush_permitted(d) )
+    if ( type != p2m_mmio_direct && !cache_flush_permitted(d) )
     {
         *ipat = true;
         return X86_MT_WB;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 25189541244d..ec1b9772bec0 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1029,6 +1029,13 @@ static struct domain *__init create_dom0(struct boot_info *bi)
 
     if ( iommu_enabled )
         dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+    else if ( !pv_shim )
+        /*
+         * pvshim doesn't support passthrough, so never allow it cache control.
+         * Otherwise a hardware domain without IOMMU will need cache control to
+         * ensure DMA coherency.
+         */
+        dom0_cfg.flags |= XEN_DOMCTL_CDF_cache_control;
 
     /* Create initial domain.  Not d0 for pvshim. */
     bd->domid = get_initial_domain_id();
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60e3..07b81a70c7a6 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -721,7 +721,8 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
          ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
            XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
            XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu |
-           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) )
+           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu |
+           XEN_DOMCTL_CDF_cache_control) )
     {
         dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
         return -EINVAL;
diff --git a/xen/include/asm-generic/iocap.h b/xen/include/asm-generic/iocap.h
index 664bbc8971fe..011c1a475072 100644
--- a/xen/include/asm-generic/iocap.h
+++ b/xen/include/asm-generic/iocap.h
@@ -5,8 +5,6 @@
 #define has_arch_io_resources(d)                        \
     (!rangeset_is_empty((d)->iomem_caps))
 
-#define cache_flush_permitted has_arch_io_resources
-
 #endif /* __ASM_GENERIC_IOCAP_H__ */
 
 /*
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5b2063eed984..9134dde7e105 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -66,9 +66,11 @@ struct xen_domctl_createdomain {
 #define XEN_DOMCTL_CDF_nested_virt    (1U << _XEN_DOMCTL_CDF_nested_virt)
 /* Should we expose the vPMU to the guest? */
 #define XEN_DOMCTL_CDF_vpmu           (1U << 7)
+/* Guest has control over the cache? */
+#define XEN_DOMCTL_CDF_cache_control  (1U << 8)
 
 /* Max XEN_DOMCTL_CDF_* constant.  Used for ABI checking. */
-#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_vpmu
+#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_cache_control
 
     uint32_t flags;
 
diff --git a/xen/include/xen/iocap.h b/xen/include/xen/iocap.h
index ffbc48b60fd5..a753fea2ec50 100644
--- a/xen/include/xen/iocap.h
+++ b/xen/include/xen/iocap.h
@@ -15,34 +15,13 @@
 static inline int iomem_permit_access(struct domain *d, unsigned long s,
                                       unsigned long e)
 {
-    bool flush = cache_flush_permitted(d);
-    int ret = rangeset_add_range(d->iomem_caps, s, e);
-
-    if ( !ret && !is_iommu_enabled(d) && !flush )
-        /*
-         * Only flush if the range(s) are empty before this addition and
-         * IOMMU is not enabled for the domain, otherwise it makes no
-         * difference for effective cache attribute calculation purposes.
-         */
-        memory_type_changed(d);
-
-    return ret;
+    return rangeset_add_range(d->iomem_caps, s, e);
 }
 
 static inline int iomem_deny_access(struct domain *d, unsigned long s,
                                     unsigned long e)
 {
-    int ret = rangeset_remove_range(d->iomem_caps, s, e);
-
-    if ( !ret && !is_iommu_enabled(d) && !cache_flush_permitted(d) )
-        /*
-         * Only flush if the range(s) are empty after this removal and
-         * IOMMU is not enabled for the domain, otherwise it makes no
-         * difference for effective cache attribute calculation purposes.
-         */
-        memory_type_changed(d);
-
-    return ret;
+    return rangeset_remove_range(d->iomem_caps, s, e);
 }
 
 #define iomem_access_permitted(d, s, e)                 \
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 559d201e0c7e..908a3b7292ff 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1222,6 +1222,12 @@ static always_inline bool is_iommu_enabled(const struct domain *d)
     return evaluate_nospec(d->options & XEN_DOMCTL_CDF_iommu);
 }
 
+static inline bool cache_flush_permitted(const struct domain *d)
+{
+    return (d->options & XEN_DOMCTL_CDF_cache_control) ||
+           (is_iommu_enabled(d) && !iommu_snoop);
+}
+
 #ifdef CONFIG_MEM_PAGING
 # define mem_paging_enabled(d) vm_event_check_ring((d)->vm_event_paging)
 #else
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 08:34:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:34:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976754.1363964 (Exim 4.92)
	(envelope-from )
	id 1uCDlS-00065H-Ig; Tue, 06 May 2025 08:34:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976754.1363964; Tue, 06 May 2025 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 1uCDlS-00064s-Ap; Tue, 06 May 2025 08:34:58 +0000
Received: by outflank-mailman (input) for mailman id 976754;
 Tue, 06 May 2025 08:34:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDlQ-00041m-Uj
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:34:56 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fc93c8b4-2a54-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 10:34:55 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43cf06eabdaso43079535e9.2
 for ; Tue, 06 May 2025 01:34:55 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a0b22bd6a3sm331993f8f.27.2025.05.06.01.34.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01: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" 
X-Inumbo-ID: fc93c8b4-2a54-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746520494; x=1747125294; 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;
        bh=Lijm60qofSbPzMh7l1KwxnIJENLBQ/io7X5j2PqNzlk=;
        b=AtKFX+MQFOcCQWM9fQd7PQXiqiL2U6M/PUjGh06wEsr61dipb9Csc8QY+ZY/eZ44qQ
         7T7sKaYBPUe/JuqDVucugtejy0b3Dn1Ndt0LljIEmf6z83cG+xGXeYt9ZiTsKU+sr1Gu
         omFpRdWVps1rBxo56yS/PbnjpHnykLM0Te1uE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746520494; x=1747125294;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Lijm60qofSbPzMh7l1KwxnIJENLBQ/io7X5j2PqNzlk=;
        b=oivJv41yuEulwrySmzfjbv9ToxdLoyMfcgH9r89YUsbJBtjAKNW7gpmiZyRHz7r8EJ
         45Uu+gwuswN2GCMPfmVAt6JdDA65JKA+YxjPqRUgqpvwnYPJkYATFiRMvgGvJ781wiYe
         mEslfaadItYc49NUr+lsl8wREV0GotXGaSYXISywDJmsQGhpkMDutBUx6bYTVr+ogNeg
         OpqANPTTwltvXK4rBtygo9InCMYz0yxxIAaT8dR2TCHQqeiqHPeaEo5KYvXX5kegc3Vn
         5mQvebesp/lZLl+3nOZpLDU57mjy6uEOOGrcnrQ11nSzL5dWLzzb3ueqHU432XuFeNXs
         6uiA==
X-Gm-Message-State: AOJu0YxpYerPeQINb6uG1G/O/q1vG/9J1NuwYSLUZalIgBtcyQDDxCST
	c0Lsw0zNrDla5IQOPyRmz4b/bQ5PhFAEDvNluKQt1hk8ejL9LeqjBIyfPbci8w8VxAimmd7wZW0
	K
X-Gm-Gg: ASbGncvj3IL0rIHWFM5GOXRdNKsTg8TvKwYRw5h3uJqN8qQmgRmAvZJuWeR55n6zEuk
	ZSXHvzNbt4CHRu0ken4BCQ6FvA65v08U0N93R4OX6smD33hOfftdx3tHSSEW2HMFJxIBKEtNFDk
	+WqNvjyNn3+6XhRSh1zwcU+HtjE12oHZq4Ag937asShRLhn9XcgUszzbKmL8+fKzXRvVSaDeqT0
	HyTynnlPvCs+BSXGoB49PBHEfdD+y/s8GGeZ92tqhTob2ABR95lLTbF5sNEiFS0NxpHi7zeMUiI
	y6Z4pr/1i8MMlJTIR0jUMpLHiZSV1R99c7veeRjnQkwN7g==
X-Google-Smtp-Source: AGHT+IGGh8zKa04McfL2H41nAuyZq30mLgV+7e5ifR/aNO8hMNZAOt0rGoSXkMlVgW4esZ4GKIMiaw==
X-Received: by 2002:a05:6000:3113:b0:39c:e0e:bb46 with SMTP id ffacd0b85a97d-3a0ac0cb00fmr1421475f8f.4.1746520494283;
        Tue, 06 May 2025 01:34:54 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 9/9] xen/x86: track dirty pCPU caches for a given vCPU
Date: Tue,  6 May 2025 10:31:48 +0200
Message-ID: <20250506083148.34963-10-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250506083148.34963-1-roger.pau@citrix.com>
References: <20250506083148.34963-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When a guest is allowed access to cache control operations such tracking
prevents having to issue a system-wide cache flush, and rather just flush
the pCPUs where the vCPU has been scheduled since the last flush.

Note that domain-wide flushes accumulate the dirty caches from all the
vCPUs, but clearing the vCPU masks will require pausing all vCPUs, which
seems overkill.  Instead leave the vCPU dirty masks as-is, worse case it
will result in redundant flushes in further calls.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/domain.c             | 43 +++++++++++++++++++++++++++++++
 xen/arch/x86/hvm/hvm.c            |  2 +-
 xen/arch/x86/hvm/mtrr.c           |  2 +-
 xen/arch/x86/hvm/svm/svm.c        |  6 +++--
 xen/arch/x86/hvm/vmx/vmx.c        |  6 +++--
 xen/arch/x86/include/asm/domain.h |  9 +++++++
 xen/arch/x86/mm.c                 | 25 +++++++-----------
 xen/arch/x86/pv/emul-priv-op.c    |  8 ++----
 8 files changed, 73 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index f197dad4c0cd..3d08b829d2db 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -579,6 +579,13 @@ int arch_vcpu_create(struct vcpu *v)
 
         if ( (rc = init_vcpu_msr_policy(v)) )
             goto fail;
+
+        if ( cache_flush_permitted(d) &&
+             !cond_zalloc_cpumask_var(&v->arch.dirty_cache) )
+        {
+            rc = -ENOMEM;
+            goto fail;
+        }
     }
     else if ( (rc = xstate_alloc_save_area(v)) != 0 )
         return rc;
@@ -614,6 +621,7 @@ int arch_vcpu_create(struct vcpu *v)
     vcpu_destroy_fpu(v);
     xfree(v->arch.msrs);
     v->arch.msrs = NULL;
+    FREE_CPUMASK_VAR(v->arch.dirty_cache);
 
     return rc;
 }
@@ -628,6 +636,8 @@ void arch_vcpu_destroy(struct vcpu *v)
     xfree(v->arch.msrs);
     v->arch.msrs = NULL;
 
+    FREE_CPUMASK_VAR(v->arch.dirty_cache);
+
     if ( is_hvm_vcpu(v) )
         hvm_vcpu_destroy(v);
     else
@@ -2018,6 +2028,9 @@ static void __context_switch(void)
         cpumask_set_cpu(cpu, nd->dirty_cpumask);
     write_atomic(&n->dirty_cpu, cpu);
 
+    if ( cache_flush_permitted(nd) )
+        __cpumask_set_cpu(cpu, n->arch.dirty_cache);
+
     if ( !is_idle_domain(nd) )
     {
         memcpy(stack_regs, &n->arch.user_regs, CTXT_SWITCH_STACK_BYTES);
@@ -2606,6 +2619,36 @@ unsigned int domain_max_paddr_bits(const struct domain *d)
     return bits;
 }
 
+void vcpu_flush_cache(struct vcpu *curr)
+{
+    ASSERT(curr == current);
+    ASSERT(cache_flush_permitted(curr->domain));
+
+    flush_mask(curr->arch.dirty_cache, FLUSH_CACHE);
+    cpumask_clear(curr->arch.dirty_cache);
+    __cpumask_set_cpu(smp_processor_id(), curr->arch.dirty_cache);
+}
+
+void domain_flush_cache(const struct domain *d)
+{
+    const struct vcpu *v;
+    cpumask_t *mask = this_cpu(scratch_cpumask);
+
+    ASSERT(cache_flush_permitted(d));
+
+    cpumask_clear(mask);
+    for_each_vcpu( d, v )
+        cpumask_or(mask, mask, v->arch.dirty_cache);
+
+    flush_mask(mask, FLUSH_CACHE);
+    /*
+     * Clearing the mask of vCPUs in the domain would be racy unless all vCPUs
+     * are paused, so just leave them as-is, at the cost of possibly doing
+     * redundant flushes in later calls.  It's still better than doing a
+     * host-wide cache flush.
+     */
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4cb2e13046d1..aed582a215a0 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2277,7 +2277,7 @@ void hvm_shadow_handle_cd(struct vcpu *v, unsigned long value)
             domain_pause_nosync(v->domain);
 
             /* Flush physical caches. */
-            flush_all(FLUSH_CACHE);
+            domain_flush_cache(v->domain);
             hvm_set_uc_mode(v, 1);
 
             domain_unpause(v->domain);
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 887994d2b984..cfe0d44459c2 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -769,7 +769,7 @@ void memory_type_changed(struct domain *d)
     if ( cache_flush_permitted(d) &&
          d->vcpu && d->vcpu[0] && p2m_memory_type_changed(d) )
     {
-        flush_all(FLUSH_CACHE);
+        domain_flush_cache(d);
     }
 }
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index e33a38c1e446..5d1777ace335 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2315,8 +2315,10 @@ static void svm_vmexit_mce_intercept(
 
 static void cf_check svm_wbinvd_intercept(void)
 {
-    if ( cache_flush_permitted(current->domain) )
-        flush_all(FLUSH_CACHE);
+    struct vcpu *curr = current;
+
+    if ( cache_flush_permitted(curr->domain) )
+        vcpu_flush_cache(curr);
 }
 
 static void svm_vmexit_do_invalidate_cache(struct cpu_user_regs *regs,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 639882ceb216..9273607d576c 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3840,11 +3840,13 @@ static void vmx_do_extint(struct cpu_user_regs *regs)
 
 static void cf_check vmx_wbinvd_intercept(void)
 {
-    if ( !cache_flush_permitted(current->domain) )
+    struct vcpu *curr = current;
+
+    if ( !cache_flush_permitted(curr->domain) )
         return;
 
     if ( cpu_has_wbinvd_exiting )
-        flush_all(FLUSH_CACHE);
+        vcpu_flush_cache(curr);
     else
         wbinvd();
 }
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index 8c0dea12a526..064b51889dc2 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -668,6 +668,12 @@ struct arch_vcpu
 
     struct vcpu_msrs *msrs;
 
+    /*
+     * When vCPU is allowed cache control track the pCPUs the vCPU has run on
+     * since the last flush.
+     */
+    cpumask_var_t dirty_cache;
+
     struct {
         bool next_interrupt_enabled;
     } monitor;
@@ -790,6 +796,9 @@ unsigned int domain_max_paddr_bits(const struct domain *d);
 #define arch_init_idle_domain arch_init_idle_domain
 void arch_init_idle_domain(struct domain *d);
 
+void vcpu_flush_cache(struct vcpu *curr);
+void domain_flush_cache(const struct domain *d);
+
 #endif /* __ASM_DOMAIN_H__ */
 
 /*
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 59b60b1e62a7..11b59398a2c4 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3804,26 +3804,19 @@ long do_mmuext_op(
             break;
 
         case MMUEXT_FLUSH_CACHE:
-            /*
-             * Dirty pCPU caches where the current vCPU has been scheduled are
-             * not tracked, and hence we need to resort to a global cache
-             * flush for correctness.
-             */
+            if ( unlikely(currd != pg_owner) )
+                rc = -EPERM;
+            else if ( likely(cache_flush_permitted(currd)) )
+                vcpu_flush_cache(curr);
+            else
+                rc = -EINVAL;
+            break;
+
         case MMUEXT_FLUSH_CACHE_GLOBAL:
             if ( unlikely(currd != pg_owner) )
                 rc = -EPERM;
             else if ( likely(cache_flush_permitted(currd)) )
-            {
-                unsigned int cpu;
-                cpumask_t *mask = this_cpu(scratch_cpumask);
-
-                cpumask_clear(mask);
-                for_each_online_cpu(cpu)
-                    if ( !cpumask_intersects(mask,
-                                             per_cpu(cpu_sibling_mask, cpu)) )
-                        __cpumask_set_cpu(cpu, mask);
-                flush_mask(mask, FLUSH_CACHE);
-            }
+                domain_flush_cache(currd);
             else
                 rc = -EINVAL;
             break;
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 089d4cb4d905..076ce8f00457 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -1199,12 +1199,8 @@ static int cf_check cache_op(
      * newer linux uses this in some start-of-day timing loops.
      */
     if ( cache_flush_permitted(current->domain) )
-        /*
-         * Handle wbnoinvd as wbinvd, at the expense of higher cost.  Broadcast
-         * the flush to all pCPUs, Xen doesn't track where the vCPU has ran
-         * previously.
-         */
-        flush_all(FLUSH_CACHE);
+        /* Handle wbnoinvd as wbinvd, at the expense of higher cost. */
+        vcpu_flush_cache(current);
 
     return X86EMUL_OKAY;
 }
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 08:46:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:46:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976857.1363977 (Exim 4.92)
	(envelope-from )
	id 1uCDwf-0002L0-1R; Tue, 06 May 2025 08:46:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976857.1363977; Tue, 06 May 2025 08: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 1uCDwe-0002KN-UG; Tue, 06 May 2025 08:46:32 +0000
Received: by outflank-mailman (input) for mailman id 976857;
 Tue, 06 May 2025 08:46:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDwd-0002Hf-SQ
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:46:31 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170110001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 967a3719-2a56-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 10:46:23 +0200 (CEST)
Received: from DUZPR01CA0272.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:4b9::12) by AM8PR08MB5697.eurprd08.prod.outlook.com
 (2603:10a6:20b:1d7::24) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.22; Tue, 6 May
 2025 08:46:21 +0000
Received: from DU2PEPF0001E9C5.eurprd03.prod.outlook.com
 (2603:10a6:10:4b9:cafe::7) by DUZPR01CA0272.outlook.office365.com
 (2603:10a6:10:4b9::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Tue,
 6 May 2025 08:46:24 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DU2PEPF0001E9C5.mail.protection.outlook.com (10.167.8.74) with Microsoft SMTP
 Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.18 via
 Frontend Transport; Tue, 6 May 2025 08:46:20 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 DB9PR08MB9684.eurprd08.prod.outlook.com (2603:10a6:10:460::18) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8699.21; Tue, 6 May 2025 08:45:48 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 08:45:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 967a3719-2a56-11f0-9eb4-5ba50f476ded
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=w+3jHi2Lhe4DLm8uI/cJuOJLsQQLwMe/BhUvgdOz6l1XfSOWCJaN2jaXue1p8jPGCrshcQbGXY2HiZQjAaLWiW+Hhon+NYln+t36AKInmRYHLmVaMXRpRcMCyIJJ1FzXHQF51u3PE9tMJCvrhhxxbfonDFXtIB7ai/YkyTm2A3vbHQb2N92pss2Ml1wXafOoAHt6RIu0TJ95iW5LzqxHlRpEZlWIT7YhuTsLmEckiZvtO7LkFhWStpEStOtIsvHsDxPKorOUIF8KB/w+Oe5CY5HmEC88JXoMQhfAMiaHEIpo5+QlK7iah8cyC2gwnFcmREyv+6ly9JPfn8a5yjTACw==
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=ZvUJUrNl6ANajshaEcEYREoNVnfY8bz+KZSy/ybfWM4=;
 b=uYf+uRsIohZ7cqGvb/Ol9bdDj7GthQAJizJunHQa4bm8RsA6YMnRktPUpdkwp+c9tTc90GnGymiK6vUDzeaX7DzrryM3m5nZtZLpopTMzywABcd8MreMWGvFVvkf88aY3MDbIZmepbFcaAtx+HWVROE2oMKzkUVrsc9aAHICfmI/9WKl5r7d/++A5w0q8G6TRm6FhpOYW7osv6jOa5CbvoIt51NAJkq0opZFmqj0Ny36BtkAmrHhmQ7/7ejfCiMOk5NMtrdpK1wQ4UNiq+1qKUBGrj65UkfACnAmQNOvHid+OJUGBcqGvjB/aNy7ezGXSnrENTghPKbTkVPxUvX4cA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.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=ZvUJUrNl6ANajshaEcEYREoNVnfY8bz+KZSy/ybfWM4=;
 b=bjPaJGDDkkq6rw7R1GcOy/lMnzqne+BbnSPYejtDa5mHYU+QfkWUxGxXVewknsIO5plhIa17LMxEIQr2Km7g50FmhllvRZFazL6eTKkfx1HolC6zbgmGv8ZoL+Izfd4glfsdXpJPw3iaRrPnf4/AdEofJ9+RkM4J7JNxVnwUxzA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jh6L38isQPgmjrLXEBymkwVUZ3OTZYkCpSXPEU+qtd71TYNO72CK16y05H7aHlRcH+Oh/NabNBsneYK/eiTcL/7Q3w9pSvEr8cVeeApbCxixUMa7diElcG/OPkek6a5+9Tj+Y6D53laMj+h+RxJf+A1UOsQo5rRxUlKciCsEDEDAENfKbW59R0VmSeOjiOlj8qeUp7kGLJzbMbP6HX8XCTQvzJtDFZC2NodJWHQ4fPmGXhyiqcps2qwCKwu6OjunA7SMF98bq+wnV7WpvpePT6YllFS4nyBirXP31K39Lc8huc7qK/HGDp8B6EdjX2Q/lZP8VrQ3SWZFzDYSdIqj0Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZvUJUrNl6ANajshaEcEYREoNVnfY8bz+KZSy/ybfWM4=;
 b=UL3DOQPYi5K8Z6PEX1xUCL4lv6RtOAPYcXf72IZBPPFHFZRL/sQtG4/WdTWmKUaC+Q5YkePzyUwiEUSdEhhRai9sTl7mB4VSrf5yviV1eTghU2YyaPXCuolIgD1FblTToSNLmv6er1C+nnST979fLW0oIgi72aiViRBuJ9VytT6mELVK+WIpJZJfbG33NOR/izlLsdI38rBAUpAqjQsLpNY7aihBJOA/95XqZpPChHF2wIieo1n3ceCZlAGSkNQbjLYx9yyo7zlduQHsvrtLJXemriY+xBw1EvKxJgkHaYLHQazOdstaY24OQJrGbPB0P0Fxk2Wc+QSVSq5gEn0SVw==
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=ZvUJUrNl6ANajshaEcEYREoNVnfY8bz+KZSy/ybfWM4=;
 b=bjPaJGDDkkq6rw7R1GcOy/lMnzqne+BbnSPYejtDa5mHYU+QfkWUxGxXVewknsIO5plhIa17LMxEIQr2Km7g50FmhllvRZFazL6eTKkfx1HolC6zbgmGv8ZoL+Izfd4glfsdXpJPw3iaRrPnf4/AdEofJ9+RkM4J7JNxVnwUxzA=
From: Luca Fancellu 
To: "Orzel, Michal" 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	
Subject: Re: [PATCH v4 5/7] arm/mpu: Introduce utility functions for the pr_t
 type
Thread-Topic: [PATCH v4 5/7] arm/mpu: Introduce utility functions for the pr_t
 type
Thread-Index: AQHbuRpkN0hqV8eyHEGiv1K+YR6eKbPD+ocAgAFZpwA=
Date: Tue, 6 May 2025 08:45:48 +0000
Message-ID: 
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-6-luca.fancellu@arm.com>
 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|DB9PR08MB9684:EE_|DU2PEPF0001E9C5:EE_|AM8PR08MB5697:EE_
X-MS-Office365-Filtering-Correlation-Id: 80bad79f-25d1-4738-e15a-08dd8c7a7989
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?TkZYY3hXY0dXMi9EZHg5WDIremZqaW54VHpNL1FSUk92bVBmMFhCRWdNQ3dB?=
 =?utf-8?B?U0l4R0VJMGtQSGdCbFMvVU1CTXRYaFY4eEZhdHVDSTk2eUJpY3cvVHN3ZmVV?=
 =?utf-8?B?ZkhmQ0N1VzE4QnhLZFRVSFdhUi9BOUJkUHdoeEdjUEFQTGV0QVJjQnFUTEVD?=
 =?utf-8?B?NFQvVGJvanhONGo4WlE3aTJtOXRPVUd3dGZ6QlhEcit3aldLY1hHaFI0cDBB?=
 =?utf-8?B?NUJkMGZNalc0RWlpaWwzeTZnbDU0WlEzK1ozSTNIUnpJRURTYTZGTkpiSjRn?=
 =?utf-8?B?d3FxLzBQSDRSUXhLQTlMT2NVV2pUc2MvYm9GQ2M5OXpvNFJmbnJmSWRvZlBr?=
 =?utf-8?B?bGVxbTRocERwTURHUzBOQ2YzUVJlNWVyMW5LRkxqZkpERjFNRlZRbUxWU3Na?=
 =?utf-8?B?dnRGa3NXM3liSmVmMzk4REVMT3BLdVVPNDJ4WmQxRkVtcnZGczRKcE1RUkJO?=
 =?utf-8?B?WTg2eFA3cWVUb0t6ZDF1N3hiM2pubHVPUkgvUU0xOHlOWHVlSmdoVUJwRUJT?=
 =?utf-8?B?R2NGMmtCYmRzY0F2SWZTRGxUaFNmVXVjZUZBSm1PQ09Xdm10OTcvZy9VTmtu?=
 =?utf-8?B?K2ZkUUFHaEp5eTY1Q3JVSUJZZm4wZktNNVNKZGtydytyVG9sWXBxYXBXMGNw?=
 =?utf-8?B?SkZCTk9ONEpnczFFVU5TMngzWVl5KzJFRyt2eFdJVnZpTDVsYjJLNi9EMk9Q?=
 =?utf-8?B?dGhnbzJ6NFU2TGtEMHZJRDNBekZhQm5BWXg4Z1RDamk2S3ZoWkpvdGtDQk5H?=
 =?utf-8?B?UmVodFNOTndNNlc1NW9yVFc0Vk5RZm11Uk1zSFAzYXk2L0tEaUJNWUxpRkM3?=
 =?utf-8?B?VWd2ZCtlNWg2ZXk4UVRNYnV6STg1d3J4em1hYXNKQWt5Z1NmeTdEMExrcXYr?=
 =?utf-8?B?S0IrY0lrem80NVpsV0lwdm9TYVUydEpQUGJKd0QydXc3T2xSR0NBeXNUcUU2?=
 =?utf-8?B?YW10M0p3T21MRlRDMm02RjdLUW41UU1CRm1WTzVYYUhNZGlNbXpsajdoTitr?=
 =?utf-8?B?VzdpSUtocS9LcW5rT1NwVW5qcmlmWUFxUmNPaXRnZW40RGtYTk9rUnRLdEpC?=
 =?utf-8?B?TUNNS3JvNllWUjZ2M1BKckxXNmVLUkhtTHBnTnZZeDhhMzNPZXRybi9obFR4?=
 =?utf-8?B?SnV1MkpzaW1EZGFkeVNjNUx0dnJ1Qno3MWhyZjNMS1pONVhxdjUyL0tWNzNn?=
 =?utf-8?B?R2NtV0Zjcy9KbTBxT3czb0pFODYxZ2JaTEsyMlVvQ2lmYTVVcjFZL2Z5akhG?=
 =?utf-8?B?ckNGd2xpZGRjeTBUdUk5S1BoSkdRbFJhdTV2WlkwMUxqc1NOZVJuRXRQY3Z0?=
 =?utf-8?B?YlFLN0hCQ3BibENqWmZHeUhuRzA3Q1oyejZpRTIyclJlM1VsS3FteW54ZG00?=
 =?utf-8?B?ZjBUcXd4Z1NGbm8vMU03TWF0MThRd0RXcXdNN2RHbG9aVEZRNm52ZHBWTjEx?=
 =?utf-8?B?WDI0Q0ZlMU1nQXpSMnlPc2R3UjdhZWlUY2ZyOVlZdkREYitYb2NrUlBOdW8v?=
 =?utf-8?B?bEEyOVZlMDNjcnVaNityWlhhWFA3ZmUzbVlQdG1VbE9qK3NmR1BsOGlucnpr?=
 =?utf-8?B?NG5oVEx1Q2EzcGFpUnc3V0dOUXc2bDN5clRhVGFKZzh0K3ZMM1doN2RRcFZx?=
 =?utf-8?B?QVg0NFR4VHVBcmNnNUcyUW9YTmJNZ25WRXpuRzZVSkhVTXZmSFZBSXFVd2xP?=
 =?utf-8?B?QXpvdEk0clJHNzlRQTNXeXZybGxycDZsRkl6QkNITVdhVmJySWRKeXRIWVFq?=
 =?utf-8?B?K1pYakp6MUFXM0gwQWRMdWlGY0g0WGI5MjNyU2RodUpZM1o0d1paR0UvQ216?=
 =?utf-8?B?V2F3Qm9FbWdBanVCSnR4SzdpLzBjRFhXcDRyUElvaGRUOVA5NWpYSjh6ditj?=
 =?utf-8?B?eDBVZnIvdzBSYjVHNmpmQ3gxNzhZNE5zb0VtaDExTVVPWjdBQUtKdlNHdUpE?=
 =?utf-8?B?SGp0V2x0VUJzdmgyZ3J6QU8xanRocldTUEszelJ4NXJweXJyT3Q0T2RVb1dN?=
 =?utf-8?Q?x+rE235fQFw34Eib4HrX1LnMFyTN8o=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <7D446BEEDB408D419C1E57A7917DF399@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB9684
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU2PEPF0001E9C5.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	cfa1caf3-aaaf-4f1e-29e7-08dd8c7a6617
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|35042699022|82310400026|1800799024|36860700013|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Zi90aWQ2enphK1VMY2JxZlk3T3drV29LcW4vZGVRMEY5Nkd4K2p6cEw4akUx?=
 =?utf-8?B?eW5QYVo0dC9La0hhYnNMRHVXOEdSTHlIM0t4dGxzakJlK0pJMFhXbGUyMloz?=
 =?utf-8?B?cXpxTTNtTmxTMTd1QUxEYk04QTZ5UTlBd2NOVm9ucTE5TmhJMlpFd0dSblBy?=
 =?utf-8?B?UnVKRVRIeFNEYWs4T3RZSG5MMTVXek00dHdwY2NDR1ZGZVJoWHRnaEFza1FI?=
 =?utf-8?B?aHNTWEs2MTRrc1NLc3ZYKy9VMHJlbnFZWWNBWTJLbGlja3R3NldrYWorRVdN?=
 =?utf-8?B?YWdUZjdaRmxQcDFkRko4SFlENlRRVGpTQWZHckpabnBISndmbVVsQlRTc0E3?=
 =?utf-8?B?NGNzT2oybkJKWkcwaElhVXFmNEVZcmFwSWVUZnp3WmtjSElWb0Q4V1E2QWNW?=
 =?utf-8?B?cGNENDkyaEJJTm1RbmZHeHhtRUE4Q25BREpJZVd0aGNKMml1S3k1N25LK2Mw?=
 =?utf-8?B?cGpCQ3JwU2hEeHFHdEtrUWphOCtpd1VFUVhTdHVDRVUwRE1tRHN6YlVtemt4?=
 =?utf-8?B?dWJrNXgraWRMd2lTcVRHYTJzbERHdkNPQzI4ckx6eksrTnM2NHg5Qlc2VVBU?=
 =?utf-8?B?a3ZPTkRpYTBKSlBlakxyVXB5M0tzSGY5dVBkV0F1UWZMMG1TY3hMY2pEaTVW?=
 =?utf-8?B?N1FvaXpwa0ZKMEt0bkJGNm1PWTFkZysyQ3VrUXpab0d4V3krMkU2bFp6MmtG?=
 =?utf-8?B?bUZQek1tOUowOGNRUHlRMFo3eU5tQWovd1RZckJuTjNBb2pla0VYeWhGWTZG?=
 =?utf-8?B?Ti9ZWkliemtvWWhMcERjSnBpU210OGdRYmYrRllTVU1Hc0M2ci9iQ1NTcmNl?=
 =?utf-8?B?MmtyeXdaTy9yOVJZNXVvT2VEYUNPWjE4YTlTaytHY0Rvd2ZPa0lkU0Q3NWoz?=
 =?utf-8?B?cU1iT2xOd0c5UnExakQxTnpkSzFkUjJqWWkvU2hTM0hqbG1Za3ZUMDUya0Rw?=
 =?utf-8?B?ZzdoWWZTZ3lCNFYraGw0bEFFd3dvZkJRZG9IbFVjaVd6TTA3UDdaUkFRY2hD?=
 =?utf-8?B?cStvS01CN1RIWnY3OTZxMlB1WElMN285K21uU2tQeEloYS9KTk1hOE9sc3FJ?=
 =?utf-8?B?Tytnb3hlc05iaWpOS1k3dEFUU2tNTXBjNlBWUEpXYXo2ejgxbkNTY3RyL1JY?=
 =?utf-8?B?ZXdISUZON2JiSWtWenlrcThzcXVmWDFhYmZXMFRzMWpIUkxZdVNibzllMnZK?=
 =?utf-8?B?YzFySG5jdlZza0Rub2M3RG5TVGhrV2N0VFF6a1k4by94OVNqUnpxR3VPdUhL?=
 =?utf-8?B?d2JTS3RJVkdpWWZpVFFyNnJyNk9UcjlhTVdLem1Qb1Q2SUJUVkxMUjV1a1hN?=
 =?utf-8?B?ZWNTdmtDMXIvQlpXQld6S1U1dXlaaTdoa1BjNGVQUnlRMVRQd1FCV0Y2ZE9i?=
 =?utf-8?B?NnJQS1EwdThZRGhQNFFyQlQzUmxiK2xsaytMaTRpb2xTS0FsNEMwSEhCVnhz?=
 =?utf-8?B?bDJtdG5jT1lRZHRnQWo5ZkFzSmR6QXhERjJzUnVpcDFieEo1Yng3d0NvTzdk?=
 =?utf-8?B?N213b3UzVEJjUTZnVmpZNit0akZDNC93TkJNam5vNEVIOVVhV0JUZ0x1SXBx?=
 =?utf-8?B?YkgyVWxXeG1NbXN1WkErZVBDaTJCT2NDaUs3QUFpdU1pQnNJRExIV01WOS92?=
 =?utf-8?B?R1lyL3hZTGlTWElOSGNPR0NVOWg4ZjdFMXR4eXlSeWVEN3VYaittZ0lnSTAv?=
 =?utf-8?B?SVYwN3hTa0M4TkxxaWRpR09VVk1QNWRxL0VHanpZOXd6OVROZU1tWWdsckN4?=
 =?utf-8?B?dHpEYzRmMk1hcG5IejJ5Z0xNTUhiMHVKNVE2VkgwTHFDMTRpK2t4ZTljeElv?=
 =?utf-8?B?WEtPV2QvSDVwVTkrS2xURWFyeW81RTJIWkNzWVFjb3o5ZHpVQytHTkh5VVIv?=
 =?utf-8?B?cUhKUVVsRmN3bWRkZ0U2NEl2THREQjB4TTdiQkU2NEIzMjFuRzh2U0Q1TXN3?=
 =?utf-8?B?YmJ1REJPS0pMRWJnR2RKSmRRMmNQY1VsWFNOWHNsWW81NWNWSVdMYkl2aXZO?=
 =?utf-8?B?b3hCZGVSZytGYTF5aFJJcmE1MzFoOGp4VmVKbmk2SXRYZmI4V2R3VHhHejl1?=
 =?utf-8?Q?VCrlXJ?=
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)(14060799003)(35042699022)(82310400026)(1800799024)(36860700013)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 08:46:20.8321
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 80bad79f-25d1-4738-e15a-08dd8c7a7989
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:
	DU2PEPF0001E9C5.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5697

SGkgTWljaGFsLA0KDQo+IE9uIDUgTWF5IDIwMjUsIGF0IDEzOjA4LCBPcnplbCwgTWljaGFsIDxN
aWNoYWwuT3J6ZWxAYW1kLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gDQo+IE9uIDI5LzA0LzIwMjUg
MTc6MjAsIEx1Y2EgRmFuY2VsbHUgd3JvdGU6DQo+PiBJbnRyb2R1Y2UgZmV3IHV0aWxpdHkgZnVu
Y3Rpb24gdG8gbWFuaXB1bGF0ZSBhbmQgaGFuZGxlIHRoZQ0KPiBzL2Zldy9hIGZldy8NCj4gcy9m
dW5jdGlvbi9mdW5jdGlvbnMvDQoNCk9rDQoNCj4+IA0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L2FybS9pbmNsdWRlL2FzbS9tcHUuaCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9tcHUuaA0K
Pj4gaW5kZXggNDBhODYxNDBiNmNjLi4wZTBhN2YwNWFkZTkgMTAwNjQ0DQo+PiAtLS0gYS94ZW4v
YXJjaC9hcm0vaW5jbHVkZS9hc20vbXB1LmgNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRl
L2FzbS9tcHUuaA0KPj4gQEAgLTI0LDYgKzI0LDcwIEBADQo+PiAjZGVmaW5lIE5VTV9NUFVfUkVH
SU9OU19NQVNLICAgIChOVU1fTVBVX1JFR0lPTlMgLSAxKQ0KPj4gI2RlZmluZSBNQVhfTVBVX1JF
R0lPTl9OUiAgICAgICAyNTUNCj4+IA0KPj4gKyNpZm5kZWYgX19BU1NFTUJMWV9fDQo+PiArDQo+
PiArI2lmZGVmIENPTkZJR19BUk1fNjQNCj4+ICsvKg0KPj4gKyAqIFNldCBiYXNlIGFkZHJlc3Mg
b2YgTVBVIHByb3RlY3Rpb24gcmVnaW9uLg0KPj4gKyAqDQo+PiArICogQHByOiBwb2ludGVyIHRv
IHRoZSBwcm90ZWN0aW9uIHJlZ2lvbiBzdHJ1Y3R1cmUuDQo+PiArICogQGJhc2U6IGJhc2UgYWRk
cmVzcyBhcyBiYXNlIG9mIHRoZSBwcm90ZWN0aW9uIHJlZ2lvbi4NCj4+ICsgKi8NCj4+ICtzdGF0
aWMgaW5saW5lIHZvaWQgcHJfc2V0X2Jhc2UocHJfdCAqcHIsIHBhZGRyX3QgYmFzZSkNCj4+ICt7
DQo+PiArICAgIHByLT5wcmJhci5yZWcuYmFzZSA9IChiYXNlID4+IE1QVV9SRUdJT05fU0hJRlQp
Ow0KPiBTaG91bGRuJ3QgeW91IHRha2UgTVBVX1JFR0lPTl9SRVMwIGludG8gYWNjb3VudD8NCg0K
WWVzIGluZGVlZCwgSeKAmWxsIGZpeA0KDQpDaGVlcnMsDQpMdWNhDQoNCg==


From xen-devel-bounces@lists.xenproject.org Tue May 06 08:46:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:46:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976856.1363972 (Exim 4.92)
	(envelope-from )
	id 1uCDwe-0002Hx-Q8; Tue, 06 May 2025 08:46:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976856.1363972; Tue, 06 May 2025 08:46: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 1uCDwe-0002Hq-NY; Tue, 06 May 2025 08:46:32 +0000
Received: by outflank-mailman (input) for mailman id 976856;
 Tue, 06 May 2025 08:46:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCDwd-0002Hf-6r
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:46:31 +0000
Received: from PA4PR04CU001.outbound.protection.outlook.com
 (mail-francecentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c20a::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 82bbc6df-2a56-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 10:45:50 +0200 (CEST)
Received: from DUZPR01CA0321.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:4ba::15) by AS8PR08MB7815.eurprd08.prod.outlook.com
 (2603:10a6:20b:529::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Tue, 6 May
 2025 08:45:46 +0000
Received: from DB1PEPF000509F7.eurprd02.prod.outlook.com
 (2603:10a6:10:4ba:cafe::27) by DUZPR01CA0321.outlook.office365.com
 (2603:10a6:10:4ba::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.32 via Frontend Transport; Tue,
 6 May 2025 08:45:48 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB1PEPF000509F7.mail.protection.outlook.com (10.167.242.153) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.18
 via Frontend Transport; Tue, 6 May 2025 08:45:46 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 DB9PR08MB9684.eurprd08.prod.outlook.com (2603:10a6:10:460::18) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8699.21; Tue, 6 May 2025 08:45:10 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 08:45:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 82bbc6df-2a56-11f0-9eb4-5ba50f476ded
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=ls37upRf30SHWYX3Ae5mQN5UTsqis5ywK1bZocZ6RdePav/XMQilX213qKIXjaVZ5VFh5ActA5oIftnPo9xyPUHQnJ+jAPKC0KWlBqrPu+r9cfTFupgzfoCaJyoGPh30wWNFv1Hlx093iCK23V8Y4dbGK58XJ7ugOxBTWtl9iiu1kaJYbLfHKghO8wFnx6z0rT+Vb77UbnSh+Vhfl4gCapeD7gJvYSLVwXMURzEtw++VzzCW0GyBHc1sG6w9Fx1B58IB8vj0p22vbE0bSyYiftJBuoilP7vpfsSzDw9DxdywIKkEQwgBGQv/Scb5FDOXpZjJIycfKBdCC1zfYZiXnA==
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=5ky/vAF+1Bjeyis2x8vdk9xTxAD3UbJzPp2bnjUseFU=;
 b=w10mMxh+I6Nx9XVZOC3ddiH4HFrqee4cEyEMpqXXX4ymyqED+Vm8d7DbGSCyjsnySg8YZAMcCXZFAeyZpfomeTDnn9XQFagvREovp+1Ix01ajh2Nnd7oeIKO4YUA66kHHoH3174z2pLrYyI6YHNKUSlkhxQknlUFppgu3BUSiHexR/E6uw4W4HEhJXjpwcnMAnwr/NQouQmCXHRcnV0IeGmavzD9LCzErKokqhB+i02H/wqBYcRrgpf8/N3Zlv4e2VeoYevXWnc4D5ahdz3VzzPYaGP4yriJBdoNyosJ/TqrD2MElojywkl44L1OOhSr9Wg9DWAEaiDfWgwsPMIVzg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.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=5ky/vAF+1Bjeyis2x8vdk9xTxAD3UbJzPp2bnjUseFU=;
 b=lVe0t2+fp+OZNsWz1k4+WSvJdidtsAiyquttz3YomtvYiQOLcd1VlwA9XsWU9ouxZ8C9HtQpznkKzduLA3C8pDCyNn6DkEekcxwKX5k8E3cRywbFHiXiB8T6jTqTlD9JPUkJF6LpwjHk/ZIKF/RfsQj9PbRJmg9Qm7r1/J3XgeY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tXpUJaACgdRTGXbpBkw/0X0GaqFUIvReSdFB9WlCPG5NkI4gpHwfNt7scW+G1xmLu64N3iTM4mlUhRQn08s5rsRijJ950jlS+rNoTra6sd31y0a9ZPSgpq9HI7ERvE7hq0jtu8x+2aNiAQ8ZvOPaiS4O3nHqf/+RuowgspfZ4ShBpeIG6Cy65kAZ6KxtAEPqcVLbweoBoVRqykXk+0HYrZwo+C22tfkbhS9FJDSZ3T8kOASXuBfc9Cgku/3SgXaJR47lnctFyNrHnAJIhOzze1ZapopSVum8DPTTo6ZiHojL27MHIY2vY75638nal6IlM8bvY3yeCW6A173nKnlBFQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5ky/vAF+1Bjeyis2x8vdk9xTxAD3UbJzPp2bnjUseFU=;
 b=Inl7HnorQsNiSPTN67DBRyHtPAzihQWV1msh2mebRKYxcEp6YOPg24pVI6dyyQx9sQWeTpLRL/oLDyvEYtkPAwD4XE7LZelqXAk1Lvpl4EhaUYYlV1phXcQF9V/O4jfDKeU/RW1owwtAL6l/GD4HQDmRfshKl0s3GEeNTgVtZiqGZ1/cApUJc47/rutm3QIK0W6M6qjkYz+8Z8y8auOT0zHvJHHq2CPMsvqndGQT7WJQR+AEaqOEXJZs0VWjoaQqIYfyxlUt7mKbf+iUKjsgf/5zC07RjYk8QEtngWHMpcTgSej97DYkkVSQ74Se4fhO/esJImPeTwKTCIePevZArA==
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=5ky/vAF+1Bjeyis2x8vdk9xTxAD3UbJzPp2bnjUseFU=;
 b=lVe0t2+fp+OZNsWz1k4+WSvJdidtsAiyquttz3YomtvYiQOLcd1VlwA9XsWU9ouxZ8C9HtQpznkKzduLA3C8pDCyNn6DkEekcxwKX5k8E3cRywbFHiXiB8T6jTqTlD9JPUkJF6LpwjHk/ZIKF/RfsQj9PbRJmg9Qm7r1/J3XgeY=
From: Luca Fancellu 
To: "Orzel, Michal" 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	
Subject: Re: [PATCH v4 4/7] arm/mpu: Provide access to the MPU region from the
 C code
Thread-Topic: [PATCH v4 4/7] arm/mpu: Provide access to the MPU region from
 the C code
Thread-Index: AQHbuRpwLITrbiULPkuuL8oh5S0krbPD902AgAFcswA=
Date: Tue, 6 May 2025 08:45:10 +0000
Message-ID: 
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-5-luca.fancellu@arm.com>
 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|DB9PR08MB9684:EE_|DB1PEPF000509F7:EE_|AS8PR08MB7815:EE_
X-MS-Office365-Filtering-Correlation-Id: 4d5912bf-2a32-44d8-b23b-08dd8c7a651e
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?NTVKaWJjaDhMZTAxWlBsbUE2SDhHMGF0NnZyUTdGUnVrSi9xSVEyVU5nV25E?=
 =?utf-8?B?eUVtQW5JTUlPcE1vTW5MQWVGSmJHdFdoOUVUQ0gyTjFnbkk5VFM1QjE0WUZm?=
 =?utf-8?B?NjFNcWx3UnBiKzUycC8za3lTMEpsQm5kNjVrcHNKR084U3BET1N2cVh1T2xn?=
 =?utf-8?B?dklDc08yeFZ3ZTlJQUJ2VzExVmU1MXhCaXZxWXJ2bFFGVnVrRmFiWnpZcDBS?=
 =?utf-8?B?N1BmdkZyMU5jUk0vbUtGNlQ2NG9DMldUNWxhcEdwK1FnU3VMR3cvbDE5RThJ?=
 =?utf-8?B?NUY1UVhmVkhiUmpsTnRLd2dONzRxcjdZQ3p6dzJDeUVtZ09nR3UzVkdNRzMz?=
 =?utf-8?B?UWRVUDV4dDNRVFJTdkNXUXJ2NFZWcFI0ZUk0Z2xtOGlRSzB5dlFJZ05qWUds?=
 =?utf-8?B?TEF1VmlKLzVqdUxEZmVuSzBxb2hhdlc5YVZDbDFRUm04Ukh3ZDZ0ZzZJTC91?=
 =?utf-8?B?ZG5xZjFDbEZpMlNPdHVwYTBSdEltS0pQMkgvZE5aZ05wT25yWXQ2M0Y0YlMw?=
 =?utf-8?B?cTRoMDNTcXI2c1RJVjhMakpKU3l2Z1pQWDc1ZmdzTkdpSWJ2dUFhdHJTRGhZ?=
 =?utf-8?B?NDFpQnhtRWxmYVVoeFVtWk83Z1VseERtWGhTY3pRSG1qT1hqNGVzRi9XS05T?=
 =?utf-8?B?QjhYTmxCVzJuUlpPWnJIenZBM3FPMnlWRUVtSFB0NVh0YmtjY1J5bXhBR0U4?=
 =?utf-8?B?cDNkck5TeHdKVE9CY2p0Rkc4VHJjczdWMHNSYVg3N0xDWnNUdnhqKzhLWUxT?=
 =?utf-8?B?VDFscmdVbG5DWGRZQVNyQnpod21ueG43NWdzbUlub2w3Z1hJY3hGajdoNnRB?=
 =?utf-8?B?SGRIek5JSjUzQ3FwT1FsOEZrdVdmN01jV1hhQjNVbVZCSjFLSkY0WjFnT1hE?=
 =?utf-8?B?R0NWY3d0OVlETWtBVjJuVWlHLzIyZ3BsaDliRHFSbnBkdzlOdkxRSm4zbEJY?=
 =?utf-8?B?Y1FtRytRZC80bnl0WW0xZCs4c0lna2w5N3BwMkhpSis0VVBEQXQxcDkzYi9o?=
 =?utf-8?B?QTVTZG5pcGMxQnJ1UC82V1AzbmJPeXBlaFVkWWVuVGM0Mk04YmFMR2tHbnZM?=
 =?utf-8?B?ckxFTEROcEh0RmMyc3RobktXN29GUGJFcXBOZWpQMzdqeThIVDdKSlhKcmJW?=
 =?utf-8?B?b1BxZlBmRTBoYmU4OEIvbk9pb1lEbjRicU8rbWp2MnJ2R3NCSGwvcDlTeTRq?=
 =?utf-8?B?K25GcFBGeG5PZmRwL0o4ZTNYRGFCbEhONElNdFZIOW5IcDBuQm1oRTg3bGZQ?=
 =?utf-8?B?dkR6dm9adVFJbDZvQ1pvRlhXK1VtbUdjSmNIeUZtTVdJbXduMEwrbXhheGNn?=
 =?utf-8?B?Q2QxaDEwYlRpRmdmZU9TVzFyYStPUlVtekRCcGhNV01pbWpISDJuc2U5Yjkw?=
 =?utf-8?B?d2kxYkx5REdYWGZsZE53cFp0U3NSVDRkbnpnSnFpYTRIUFhIaHlCVHFFOEh2?=
 =?utf-8?B?UHhBSEV6bkpJOVJjeUthS3BoQ1NPanM3bm85NmtISWtVTzdtSE1sWFB1UlFp?=
 =?utf-8?B?NmtZTFhKMnlnZWlLQ3BUbDM3VVRBVzFnSUxiVC9KZ2hISllMdmZGSHIrR1JQ?=
 =?utf-8?B?ME1jM0dvaGNZSzAvcWxBQ0s4ZUxzdTdRNzk4cmRkcnAweVEzVDE5azg2N1ZH?=
 =?utf-8?B?dzhjZEN0MUQ5MTYzZmdVM081TDRhWVErc0xrWWVTbWdXeGw4WEZmSlBTN0JX?=
 =?utf-8?B?QVdVNXJyajlrT2RIeDlWTEM3aDdMKzNZUDMySHFoN2VNNnZ0UVd4bHdLS1Nv?=
 =?utf-8?B?dUpxa0kwWlBHeWgvZ3FHSGdjamUvQmtDREJBSW9ZUEZqUndJblpLdVVpZWFH?=
 =?utf-8?B?QWlnSytkQXZrWHcxSTVvWjNmRmRrODRiQU9ZWjdHVVpuTDNaLzBOQnNwUEFO?=
 =?utf-8?B?ZFBHNEttRlJOeWRlKzNTQk5SeE9MVDRiSkc3Q3Jnb0hyeHNNekxBTkE5eDZY?=
 =?utf-8?B?VExYbG1WTFVENEswQ1Q1TitDK0hWdzdrOUFBZFgvNERkNUJuaUNsRC9SZ3N2?=
 =?utf-8?B?M1dhL21DQklnPT0=?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB9684
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF000509F7.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	bda6d37e-fa5a-48d4-fe5d-08dd8c7a4fb5
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|82310400026|376014|36860700013|1800799024|35042699022;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MU1kNCsySVF1YmtqZjU3VUxlSHVJeVdsR01SN2RqS1pEY1RHeEZRKzZqV1pE?=
 =?utf-8?B?UlFXWlFPRnVqa3BlTVNOcURwYVVBbzB4VUdxQWI1QjRFcEhBbS9kVkU4MVBE?=
 =?utf-8?B?N2tmWDRXWmhMUEhpZnBVUHZSd2hzN09yQ29qRzFhQWlSdmhFeVY5cmphOHlN?=
 =?utf-8?B?S0tWcFBIWTNUU3FoSHJzYVo5ZFowMzZCOGVSekpkZW9BZElqYkxHN1ArRWxG?=
 =?utf-8?B?d0tCZXhWRyt1UVZVOXBNeXczVlNISC9HaWpCMlVXOGYxMGdEWWx3QnFyYVBo?=
 =?utf-8?B?MDNBNW5iM3JLSXArZkNSdmRSRmdiNnZKd08vMG1nUWwzOUlxMytOTk5KdHda?=
 =?utf-8?B?R2ZzakFCbmljRng4RExxMEtQbDRXcUJaVU03bUJvamRxU1kwLy9NUjlBZG92?=
 =?utf-8?B?T3FUWXgyYy9ldlFXL2Z3SFlhcmFlMjFCM3dBU0hqVStsQnNqNE83cFlXRWdF?=
 =?utf-8?B?MDBpYXBEZlQzcVFLdmM1OTlLc0ZHUUJIamY1eDJMek9COG81dlFCZ253UDRP?=
 =?utf-8?B?aWNnQXp4MWl0UUZzSzJqTzJrNnVyZUFuWEJDNjY0TFBNaS9xRlAzYml1V0xV?=
 =?utf-8?B?dHhUOElBaVdPZ0VvVW1FSGhMbHI1cldEOXk5eWlZNFoxV1JNbVRKbHBRK3Zp?=
 =?utf-8?B?T09XV1lYYnNHS1FIN1Zqd0pyRTY3T0s5TU1vSFVrUmlQWTZMakxRaG9VK1ZS?=
 =?utf-8?B?UUxwTDNZazlBdjdaU2hRQWJ1dWpzWG5vcHhoUnN4NHZLM2RzUUhNSWdTZ2hq?=
 =?utf-8?B?NVdUdlhiSXphMU9VZkVmWUQ0MHVmYTQ5emtzMEs4RXdrTTk1TmF6bFVFMHJw?=
 =?utf-8?B?M2ZieExLVHJSb284c2NoTkpRZUIwZDVsczRPY1FBVng5L0oweTRRckR5b1Vn?=
 =?utf-8?B?K3F0YXFYRjRocjMrNzRSMWRhdDRtUE5MM2xGd1RCN01WV1MxTy9KdGJuejVI?=
 =?utf-8?B?MHV1Z1o3eGFNVlRpSUtnMFdUdHFBc3Q3d3Z4cUZYS1FMNm0xOHdrTlRyemtm?=
 =?utf-8?B?L2VDOXFxMVFNNkRWdUQ3M0NjUXY2VS9rZDYzdEpyT0l4UHUvbkRTU1RuVzBm?=
 =?utf-8?B?a0ZZOVEzZFo4azdLU1loNzRRVDQyNEJybnlCSTJacHNoMXd0VHRFMWZxclRZ?=
 =?utf-8?B?ZkM2S1V0WFEyZmlrVENwUXhSdy9TcElCdEpwbk9wYUNOWUtMMTVEajVzRjFG?=
 =?utf-8?B?cFBJMzhnQkFINnFtbW4rUDhLN2VpcExpemlwVVIzcm0weTgxRDRqbjBCSnBF?=
 =?utf-8?B?azFqYjFITlB3cVpBNUpiSGRkM1JuYnlRZ2VGcnhidnVCbnRjUThRVS9DTjVk?=
 =?utf-8?B?SjYwdUU0anB0VVRXZzVWbFU4UDFBSW5aQVJkK09rc3RBMFh4Y2Zuc1JxZER6?=
 =?utf-8?B?Z21kdy9FNGZKU0NPaVlBdUVQUTArNHpLc0h3aFNlT0thc0lXVUJzS2FQQm5a?=
 =?utf-8?B?VU5LTUlIWTk5enBsS3V1RThKYUUvb2FUN3J0MEc5emJ6OVBWSk5uRXYxTHRB?=
 =?utf-8?B?MnkvYmNWUVdGNUtZaFhPeVN3SC9QRHM3aEFQNGRLQ2hxV3BuS1lvZTZyb2FP?=
 =?utf-8?B?ZWxRNGtTNnh4WllxbkVzNHM5bFpMYWozMEM3M29OOUVhTXRSR2NEL3hsVHFk?=
 =?utf-8?B?YVYxZGFLcHN5KzBsd1NVaVFwSFdrMldzWWdmU2lFMFpqbmZINDFZVW5UaHJ0?=
 =?utf-8?B?Mmc4cElpaUo2NTVjcGhqSWc4UHUxR08rU0ozYzd3K21CVmZ3eFIxQjlJR1py?=
 =?utf-8?B?RE5YVTJ2SExsZkV4YkUrN3RUcmIrMzBlRGcvNHVZSHVvdC9ISXlQMVZVaGI4?=
 =?utf-8?B?bFJCMmhTRnpUNGo2S2xEOXlETWN2VmpMZnc5dHRxY2VhMXpZaVVjQ2ZTdDBR?=
 =?utf-8?B?YWYyMjJHN1FlNS9lbk1Ga0xHT05DcTlnZE9vYTF0LzB0S0lDRms2SXNaTlNH?=
 =?utf-8?B?WUtYa0EvNldVNFhqSFBieEJnbUNzWHhXTzlkV2JjVVo1dWdTYm54Q2dUZmRn?=
 =?utf-8?B?d08wVkJZZHRpZnk5VVFmWkdneGVVbXRReVNBZkJwRmtEK3pDWWFiTXZtSUNv?=
 =?utf-8?Q?naDfzw?=
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)(14060799003)(82310400026)(376014)(36860700013)(1800799024)(35042699022);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 08:45:46.5675
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d5912bf-2a32-44d8-b23b-08dd8c7a651e
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:
	DB1PEPF000509F7.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7815

SGkgTWljaGFsLA0KDQo+PiANCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9h
c20vbXB1LmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vbXB1LmgNCj4+IGluZGV4IDEzNjhi
MmViOTkwZi4uNDBhODYxNDBiNmNjIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1
ZGUvYXNtL21wdS5oDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vbXB1LmgNCj4+
IEBAIC0xNyw2ICsxNyw3IEBADQo+PiAjZGVmaW5lIE1QVV9SRUdJT05fU0hJRlQgIDYNCj4+ICNk
ZWZpbmUgTVBVX1JFR0lPTl9BTElHTiAgKF9BQygxLCBVTCkgPDwgTVBVX1JFR0lPTl9TSElGVCkN
Cj4+ICNkZWZpbmUgTVBVX1JFR0lPTl9NQVNLICAgKH4oTVBVX1JFR0lPTl9BTElHTiAtIDEpKQ0K
Pj4gKyNkZWZpbmUgTVBVX1JFR0lPTl9SRVMwICAgKDB4RkZGRlVMTCA8PCA0OCkNCj4gVGhpcyBk
b2VzIG5vdCBsb29rIGxpa2UgYSBjb21tb24gbWFjcm8uIEl0J3MgYXJtNjQgc3BlY2lmaWMuDQo+
IEFsc28sIGl0IGxvb2tzIGxpa2UgeW91IHVzZSBpdCBpbiBtYWNyb3MgdGhhdCBhcmUgY29tbW9u
IHRvby4NCg0KWWVzIHJpZ2h0LCBJ4oCZbGwgbW92ZSB0aGF0IGludG8gYXNtL2FybTY0L21wdS5o
DQoNCj4+IA0KPj4gKy8qDQo+PiArICogUmVhZHMgdGhlIE1QVSByZWdpb24gd2l0aCBpbmRleCAn
c2VsJyBmcm9tIHRoZSBIVy4NCj4gSWYgeW91IHVzZSBAZm9vIHN0eWxlLCB5b3Ugc2hvdWxkIHVz
ZSBAc2VsIGhlcmUuDQo+IEJ1dCBJTU8gdGhpcyBjb21tZW50IGRvZXMgbm90IGJyaW5nIGFueSB1
c2VmdWxuZXNzLg0KPiBUaGUgbmFtZSBvZiB0aGUgaGVscGVyIGFuZCBwYXJhbWV0ZXIgZGVzY3Jp
cHRpb24gaXMgZW5vdWdoLg0KPiANCj4+ICsgKg0KPj4gKyAqIEBwcl9yZWFkOiBtcHUgcHJvdGVj
dGlvbiByZWdpb24gcmV0dXJuZWQgYnkgcmVhZCBvcC4NCj4+ICsgKiBAc2VsOiBtcHUgcHJvdGVj
dGlvbiByZWdpb24gc2VsZWN0b3INCj4+ICsgKi8NCj4+ICtleHRlcm4gdm9pZCByZWFkX3Byb3Rl
Y3Rpb25fcmVnaW9uKHByX3QgKnByX3JlYWQsIHVpbnQ4X3Qgc2VsKTsNCj4+ICsNCj4+ICsvKg0K
Pj4gKyAqIFdyaXRlcyB0aGUgTVBVIHJlZ2lvbiB3aXRoIGluZGV4ICdzZWwnIHRvIHRoZSBIVy4N
Cj4+ICsgKg0KPj4gKyAqIEBwcl93cml0ZTogY29uc3QgbXB1IHByb3RlY3Rpb24gcmVnaW9uIHBh
c3NlZCB0aHJvdWdoIHdyaXRlIG9wLg0KPiBObyBuZWVkIHRvIHNheSBjb25zdCBpbiBwYXJhbWV0
ZXIgZGVzY3JpcHRpb24NCj4gDQo+PiArICogQHNlbDogbXB1IHByb3RlY3Rpb24gcmVnaW9uIHNl
bGVjdG9yDQo+IFNhbWUgaGVyZS4NCg0KSeKAmWxsIG1vZGlmeSB0aGVzZSBhYm92ZQ0KDQo+PiAN
Cj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vbXB1L21tLmMgYi94ZW4vYXJjaC9hcm0vbXB1
L21tLmMNCj4+IGluZGV4IDllYWIwOWZmMjA0NC4uNDBjY2Y5OWFkYzk0IDEwMDY0NA0KPj4gLS0t
IGEveGVuL2FyY2gvYXJtL21wdS9tbS5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vbXB1L21tLmMN
Cj4+IEBAIC04LDYgKzgsOCBAQA0KPj4gI2luY2x1ZGUgPHhlbi9zaXplcy5oPg0KPj4gI2luY2x1
ZGUgPHhlbi90eXBlcy5oPg0KPj4gI2luY2x1ZGUgPGFzbS9tcHUuaD4NCj4+ICsjaW5jbHVkZSA8
YXNtL21wdS9tbS5oPg0KPj4gKyNpbmNsdWRlIDxhc20vc3lzcmVncy5oPg0KPj4gDQo+PiBzdHJ1
Y3QgcGFnZV9pbmZvICpmcmFtZV90YWJsZTsNCj4+IA0KPj4gQEAgLTI2LDYgKzI4LDM1IEBAIERF
Q0xBUkVfQklUTUFQKHhlbl9tcHVtYXBfbWFzaywgTUFYX01QVV9SRUdJT05fTlIpIFwNCj4+IC8q
IEVMMiBYZW4gTVBVIG1lbW9yeSByZWdpb24gbWFwcGluZyB0YWJsZS4gKi8NCj4+IHByX3QgX19z
ZWN0aW9uKCIuZGF0YS5wYWdlX2FsaWduZWQiKSB4ZW5fbXB1bWFwW01BWF9NUFVfUkVHSU9OX05S
XTsNCj4+IA0KPj4gKyNpZmRlZiBDT05GSUdfQVJNXzY0DQo+PiArLyoNCj4+ICsgKiBUaGUgZm9s
bG93aW5nIGFyZSBuZWVkZWQgZm9yIHRoZSBjYXNlIGdlbmVyYXRvcnMgR0VORVJBVEVfV1JJVEVf
UFJfUkVHX0NBU0UNCj4gSXQncyByZWFkIGEgYml0IG9kZC4gUGVyaGFwcyByZW1vdmUgJ2dlbmVy
YXRvcnMnIHdvcmQgYW5kIHVzZSAnY2FzZXM6Jw0KDQpvaw0KDQo+PiANCj4+IA0KPj4gKyNpZmRl
ZiBDT05GSUdfQVJNXzY0DQo+PiArLyoNCj4+ICsgKiBBcm12OC1SIHN1cHBvcnRzIGRpcmVjdCBh
Y2Nlc3MgYW5kIGluZGlyZWN0IGFjY2VzcyB0byB0aGUgTVBVIHJlZ2lvbnMgdGhyb3VnaA0KPj4g
KyAqIHJlZ2lzdGVycywgaW5kaXJlY3QgYWNjZXNzIGludm9sdmVzIGNoYW5naW5nIHRoZSBNUFUg
cmVnaW9uIHNlbGVjdG9yLCBpc3N1aW5nDQo+IHMvcmVnaXN0ZXJzLC9yZWdpc3RlcnM6LyBhbmQg
cGVyaGFwcyB1c2UgYnVsbGV0IHBvaW50cw0KPiANCj4+ICsgKiBhbiBpc2IgYmFycmllciBhbmQg
YWNjZXNzaW5nIHRoZSBzZWxlY3RlZCByZWdpb24gdGhyb3VnaCBzcGVjaWZpYyByZWdpc3RlcnM7
DQo+PiArICogaW5zdGVhZCBkaXJlY3QgYWNjZXNzIGludm9sdmVzIGFjY2Vzc2luZyBzcGVjaWZp
YyByZWdpc3RlcnMgdGhhdCBwb2ludHMgdG8NCj4+ICsgKiBhIHNwZWNpZmljIE1QVSByZWdpb24s
IHdpdGhvdXQgY2hhbmdpbmcgdGhlIHNlbGVjdG9yIChpbiBzb21lIGNhc2VzKSBhbmQNCj4gV2hh
dCBkbyB5b3UgbWVhbiBieSAiaW4gc29tZSBjYXNlcyI/DQoNCndoYXQgSSBoYWQgaW4gbWluZCB3
YXMgdGhhdCBldmVudHVhbGx5IHlvdeKAmWxsIG5lZWQgdG8gY2hhbmdlIHRoZSBzZWxlY3RvciBh
dCBzb21lIHBvaW50LA0KbGlrZSBhcm02NCBldmVyeSAxNiByZWdpb25zIG9yIG9uIGFybTMyIGZy
b20gcmVnaW9uIDMyIG9ud2FyZHMsIGJ1dCBtYXliZSBJIGNhbiBzaW1wbGlmeQ0KYW5kIHJlbW92
ZSB0aGlzIHBhcnQuDQoNCj4gDQo+PiArICogaXNzdWluZyBiYXJyaWVycyBiZWNhdXNlIG9mIHRo
YXQuDQo+PiArICogRm9yIEFybTY0IHRoZSBQUntCLEx9QVJfRUx4IChmb3Igbj0wKSBhbmQgUFJ7
QixMfUFSPG4+X0VMeCwgbj0xLi4xNSwgYXJlIHVzZWQNCj4gSWYgZm9yIG49PTAgeW91IHVzZWQg
KCksIHdoeSBub3QgZm9sbG93aW5nIHRoZSBzYW1lIHN0eWxlIGZvciAxLi4xNT8NCj4gSXQgYWxs
IGltcHJvdmVzIHJlYWRhYmlsaXR5IG9mIHN1Y2ggbG9uZyBjb21tZW50cy4NCj4gDQo+PiArICog
Zm9yIHRoZSBkaXJlY3QgYWNjZXNzIHRvIHRoZSByZWdpb25zIHNlbGVjdGVkIGJ5IFBSU0VMUl9F
TDIuUkVHSU9OPDc6ND46biwgc28NCj4+ICsgKiAxNiByZWdpb25zIGNhbiBiZSBkaXJlY3RseSBh
Y2Nlc3Mgd2hlbiB0aGUgc2VsZWN0b3IgaXMgbXVsdGlwbGUgb2YgMTYsIGdpdmluZw0KPiBzL2Fj
Y2Vzcy9hY2Nlc3NlZC8NCj4gcy9pcyBtdWx0aXBsZS9pcyBhIG11bHRpcGxlLw0KDQpvayBhbGwg
dGhlIGFib3ZlDQoNCkNoZWVycywNCkx1Y2E=


From xen-devel-bounces@lists.xenproject.org Tue May 06 08:54:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 08:54:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976882.1363993 (Exim 4.92)
	(envelope-from )
	id 1uCE4O-00053y-Sw; Tue, 06 May 2025 08:54:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976882.1363993; Tue, 06 May 2025 08: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 1uCE4O-00053r-Pp; Tue, 06 May 2025 08:54:32 +0000
Received: by outflank-mailman (input) for mailman id 976882;
 Tue, 06 May 2025 08:54:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCE4M-00053l-Kn
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 08:54:30 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b897d3c9-2a57-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 10:54:29 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43cf628cb14so44676745e9.1
 for ; Tue, 06 May 2025 01:54:29 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441b89cc480sm164539785e9.2.2025.05.06.01.54.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01:54: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" 
X-Inumbo-ID: b897d3c9-2a57-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746521669; x=1747126469; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=+0SajNHqz8FlHrvr6rdfNoWBqxUWnEZs/LJ4gSlGzr0=;
        b=J2a1mw63rnduitq/WHvJP5YOrq43zlaGFmpirhoES1IWn9R8uznLXkLNr7oNvD9PWb
         bdeInbJkGIP8M/K/dtd5LbuoVendlyrxdTcmUWCsJcCIwz6/m38rrBKiwm5k7IuyJB6p
         dIomP7wqRVBCh4yDw+chAe9Y9iWfGP5U8oWOU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746521669; x=1747126469;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=+0SajNHqz8FlHrvr6rdfNoWBqxUWnEZs/LJ4gSlGzr0=;
        b=bqmLrYUKua5eyIXFHmsKXh+/jQXFipzCqu+t6sTbS6KSUtd7oYMrZjV3MTAPpmVEAG
         uKfbKjL8x4W6p76Rx+nX81+tIrOGncqwPdSXhNOsyc+6ADhi38G+VjPNUvllwxnXjKp6
         b7uFiIdm6kbPDtQ0cSfmWRXwlVEfu6Sm1s332kK1Akn+fuxeGTyrFQ8k2CDxObaeU8En
         lWF1NLD9uBo1wxRfgpthDd1rZ/i9UF/WlGkQjbBvUKjOs8xAc72ji1maS+CmmigHnjIM
         pjvoZnl485Qh8GDZK9hvRUnuSHC32CBUTG81MJNhu7t2rsNB8MFE+0L9cGzrjyTrqEt3
         mFYA==
X-Forwarded-Encrypted: i=1; AJvYcCVuz9MzIeJx93iTQ4Z/sxugI5c2fGHPyVtzf/A0VdlipuvEgKMsEIPCuzFFoxC+Ba3MTRB8ie1I5kA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz6MERjMCUUfqdEKBtEhE4DJ3kkFhCMnHGNBDiJ7RjuxYntSsrl
	K7n26XFQWKTUVnfTP3JrBrH/cTPUDmLDzHRujb9Qnky2VM/4A8otQ0/LhtAJnqo=
X-Gm-Gg: ASbGnctYe3D6RwNdOYt+JO+cqo9afh7MdRCOkBlzFXlJMT+1k3xWsqJVFxPXXqeZB2r
	I4eZ9apLo1kPhoHqhDeS2us6a/BXkChp+RazVnnUnVIZS1WmxWVpPufqT6zhf4LbvrVE13dWYnS
	QCJoWwJEQSsROX2oiy6rWW7yMccEE7vDhEGjQZeIzcZZloXO0hNJuOcLw0iRD4hxPboCzFpqbwf
	Pp1Glo4qdIO7UYxRQ5T2i6iWHrYeRcvIsKoG3gkkLaV7RyxokEIh89gtEE6291nUBFuZE/riVXq
	f90iGNZkPZj4HvbM9J2eiRRVhB0CRYyE49T/kZmXwytPGQ==
X-Google-Smtp-Source: AGHT+IGcfeuMfQA6qm9TEp5NEI75xmqMffcPFN6YhQwISDTqYwB+9zrq9ETiFz9lGJmSic7d2JGQ9g==
X-Received: by 2002:a05:600c:83cd:b0:43d:b33:679c with SMTP id 5b1f17b1804b1-441d00fa788mr25297895e9.14.1746521669092;
        Tue, 06 May 2025 01:54:29 -0700 (PDT)
Date: Tue, 6 May 2025 10:54:27 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stefano Stabellini 
Cc: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	Jan Beulich ,
	"Ragiadakou, Xenia" ,
	Andrew Cooper , jason.andryuk@amd.com,
	agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
Message-ID: 
References: 
 <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@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, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
> On Mon, 5 May 2025, Roger Pau Monné wrote:
> > On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> > > On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
> > > > On Mon, 28 Apr 2025, Jan Beulich wrote:
> > > > > On 25.04.2025 22:19, Stefano Stabellini wrote:
> > > > > > From: Xenia Ragiadakou 
> > > > > > 
> > > > > > Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> > > > > > addresses to firmware or co-processors not behind an IOMMU.
> > > > > 
> > > > > I definitely don't understand the firmware part: It's subject to the
> > > > > same transparent P2M translations as the rest of the VM; it's just
> > > > > another piece of software running there.
> > > > > 
> > > > > "Co-processors not behind an IOMMU" is also interesting; a more
> > > > > concrete scenario might be nice, yet I realize you may be limited in
> > > > > what you're allowed to say.
> > > > 
> > > > Sure. On AMD x86 platforms there is a co-processor called PSP running
> > > > TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionally to
> > > > pass addresses to it.  See drivers/tee/amdtee/ and
> > > > include/linux/psp-tee.h in Linux.
> > > 
> > > We had (have?) similar issue with amdgpu (for integrated graphics) - it
> > > uses PSP for loading its firmware. With PV dom0 there is a workaround as
> > > dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, but I
> > > expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's
> > > the one I used for debugging this issue).
> > 
> > That's ugly, and problematic when used in conjunction with AMD-SEV.
> > 
> > I wonder if Xen could emulate/mediate some parts of the PSP for dom0
> > to use, while allowing Xen to be the sole owner of the device.  Having
> > both Xen and dom0 use it (for different purposes) seems like asking
> > for trouble.  But I also have no idea how complex the PSP interface
> > is, neither whether it would be feasible to emulate the
> > interfaces/registers needed for firmware loading.
> 
> Let me take a step back from the PSP for a moment. I am not opposed to a
> PSP mediator in Xen, but I want to emphasize that the issue is more
> general and extends well beyond the PSP.
> 
> In my years working in embedded systems, I have consistently seen cases
> where Dom0 needs to communicate with something that does not go through
> the IOMMU. This could be due to special firmware on a co-processor, a
> hardware erratum that prevents proper IOMMU usage, or a high-bandwidth
> device that technically supports the IOMMU but performs poorly unless
> the IOMMU is disabled. All of these are real-world examples that I have
> seen personally.

I wouldn't be surprised, classic PV dom0 avoided those issues because
it was dealing directly with host addresses (mfns), but that's not the
case with PVH dom0.

> In my opinion, we definitely need a solution like this patch for Dom0
> PVH to function correctly in all scenarios.

I'm not opposed to having such interface available for PVH hardware
domains.  I find it ugly, but I don't see much other way to deal with
those kind of "devices".  Xen mediating accesses for each one of them
is unlikely to be doable.

How do you hook this exchange interface into Linux to differentiate
which drivers need to use mfns when interacting with the hardware?

> Additionally, we could add a PSP mediator in Xen to provide best PSP
> support, and also for cases where both Xen and Dom0 need access, but I
> cannot fully assess the complexity involved, as I am not very familiar
> with the API. Probably it is not going to be simple.

For the specific PSP example, and kind of following from the question
above: if we add some mediation layer in Xen for PSP registers, how
could Linux differentiate whether it needs to use mfn of gfns when
interacting with the device?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 09:00:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 09:00:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976893.1364003 (Exim 4.92)
	(envelope-from )
	id 1uCEAM-0006bM-GH; Tue, 06 May 2025 09:00:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976893.1364003; Tue, 06 May 2025 09:00: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 1uCEAM-0006bF-D6; Tue, 06 May 2025 09:00:42 +0000
Received: by outflank-mailman (input) for mailman id 976893;
 Tue, 06 May 2025 09:00:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCEAL-0006b9-2R
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 09:00:41 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9561280a-2a58-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 11:00:40 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ace94273f0dso251252266b.3
 for ; Tue, 06 May 2025 02:00:40 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099ae34e2sm12632186f8f.24.2025.05.06.01.34.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 01: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" 
X-Inumbo-ID: 9561280a-2a58-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746522039; x=1747126839; 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;
        bh=N+W9lEzZ3YPqEiQclAW6B381YvWea5VfolcXUQFEZ2o=;
        b=WAgbHJofF7HgM3TMPI8TiQstYkTEQQwtthrPWF58srf1m8N5cb6pV0eLFI+tf8Xi8a
         4tFBhyZp9yg0272GIGPEcVO6l6HfoUSp8/fkLlsCjKiYBiIbsNmD3ZAZDw7AW7whoEa4
         +3mZZToVGaJZ3zzUkQVZGWkF8TazU6zB7DPOY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746522039; x=1747126839;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=N+W9lEzZ3YPqEiQclAW6B381YvWea5VfolcXUQFEZ2o=;
        b=ULECoRQa5H+GO103fTqwpdPlnboMArrWMUl0iZOM8SKwQpuGw1jhed81V5Fxh9NkWG
         o+AMuiFEbt2x4KerQ8o8ltAMMnnN8V4pfoLSVL5wV5y3Az3412OO+7tmyDlYT/lhlw7g
         kZrCNdpuyWqVhRp/DniaOmnsYyx0gEmdQS8t8qwVUKN1seyPKd6s5j5PwAlTxGQ7Mn4w
         u2l3RBD0wib9RRa16fV0evGFYJzzOXXypnNfBJlRWyG6ZUW0jAnHXamVUgvyl14hgny5
         U7P88MnY1ETAdX5qV/ytfZ7Xg8dQm2z3wsqS2dI7U7auOIc7/cU74sDYn0KD5RH6le6m
         R/tw==
X-Gm-Message-State: AOJu0YxhAgsGxRhMMo0CY2EXd0WM96LnfmFgqQ+UHQbkXZ8vaEoisJEt
	X7y9+4lhcWQLcpDHtYuuohQw9/gfQWoKsWMzjW8H37Cs5hNWXgRrM0RQJr9ACCgxocaU/obKkYm
	g
X-Gm-Gg: ASbGncvUe163xnv2zbm6U4d6TWb/BgQrrTp6e69uErJ3QiZjaW4wBHFY41XrV41ht1a
	gewdQa/1vyq/om+WyjB5Kr9LNAESRiShFbrGobR9UpaTjNkuCwRjtCRfr5WqjmbZkwNf9emTHRP
	iMHhKCehn4O73maQY6FmYZYz5LbFKXVHRluPmziU4N/gXEzG9tgphhdAgjsdnpmywTWWUjpI4Ya
	gaYHIXLcNjURMBgwhy36rDl40m5drKaGSIEinqoX3cb6EqMWD9bluA81dRNKIdf+WEptZFUGbB2
	KrRQASIOrknxN70Kzd0TzTWfgxCvNtSgVKCm0YxdKlezvA==
X-Google-Smtp-Source: AGHT+IGhxmBqCb7xdHw4VhQuhl4tgy/BOqgPbggvS46dewpZnmq+sg0FvdSOBL2lOWhwvg/D+TI0Bw==
X-Received: by 2002:a05:6000:1886:b0:39c:1f10:c736 with SMTP id ffacd0b85a97d-3a09fdbc906mr9154530f8f.43.1746520488398;
        Tue, 06 May 2025 01:34:48 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 4/9] x86/gnttab: do not implement GNTTABOP_cache_flush
Date: Tue,  6 May 2025 10:31:43 +0200
Message-ID: <20250506083148.34963-5-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250506083148.34963-1-roger.pau@citrix.com>
References: <20250506083148.34963-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current underlying implementation of GNTTABOP_cache_flush on x86 won't
work as expected.  The provided {clean,invalidate}_dcache_va_range()
helpers only do a local pCPU cache flush, so the cache of previous pCPUs
where the vCPU might have run are not flushed.

However instead of attempting to fix this, make the GNTTABOP_cache_flush
operation only available to ARM.  There are no known users on x86, the
implementation is broken, and other architectures don't have grant-table
support yet.

With that operation not implemented on x86, the related
{clean,invalidate}_dcache_va_range() helpers can also be removed.

Fixes: f62dc81c2df7 ("x86: introduce more cache maintenance operations")
Fixes: 18e8d22fe750 ("introduce GNTTABOP_cache_flush")
Signed-off-by: Roger Pau Monné 
---
I've attempted to introduce a new arch_do_grant_table_op() in a separate
arch-specific file, but it required exposing too much functionality from
the common grant_table.c, ifdefying is probably better for the time being.
---
 xen/arch/x86/include/asm/flushtlb.h | 15 ---------------
 xen/common/grant_table.c            |  6 ++++++
 2 files changed, 6 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/include/asm/flushtlb.h b/xen/arch/x86/include/asm/flushtlb.h
index bb0ad58db49b..d0c9120b5faf 100644
--- a/xen/arch/x86/include/asm/flushtlb.h
+++ b/xen/arch/x86/include/asm/flushtlb.h
@@ -182,21 +182,6 @@ void flush_area_mask(const cpumask_t *mask, const void *va,
 }
 
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache) {}
-static inline int invalidate_dcache_va_range(const void *p,
-                                             unsigned long size)
-{ return -EOPNOTSUPP; }
-static inline int clean_and_invalidate_dcache_va_range(const void *p,
-                                                       unsigned long size)
-{
-    unsigned int order = get_order_from_bytes(size);
-    /* sub-page granularity support needs to be added if necessary */
-    flush_area_local(p, FLUSH_CACHE|FLUSH_ORDER(order));
-    return 0;
-}
-static inline int clean_dcache_va_range(const void *p, unsigned long size)
-{
-    return clean_and_invalidate_dcache_va_range(p, size);
-}
 
 unsigned int guest_flush_tlb_flags(const struct domain *d);
 void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask);
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index d874ac5f1241..cc7c7d004065 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -940,6 +940,7 @@ static void reduce_status_for_pin(struct domain *rd,
         gnttab_clear_flags(rd, clear_flags, status);
 }
 
+#ifdef CONFIG_ARM
 static struct active_grant_entry *grant_map_exists(const struct domain *ld,
                                                    struct grant_table *rgt,
                                                    mfn_t mfn,
@@ -975,6 +976,7 @@ static struct active_grant_entry *grant_map_exists(const struct domain *ld,
 
     return ERR_PTR(-EINVAL);
 }
+#endif /* CONFIG_ARM */
 
 union maptrack_node {
     struct {
@@ -3520,6 +3522,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) uop,
     return 0;
 }
 
+#ifdef CONFIG_ARM
 static int _cache_flush(const gnttab_cache_flush_t *cflush, grant_ref_t *cur_ref)
 {
     struct domain *d, *owner;
@@ -3631,6 +3634,7 @@ gnttab_cache_flush(XEN_GUEST_HANDLE_PARAM(gnttab_cache_flush_t) uop,
 
     return 0;
 }
+#endif /* CONFIG_ARM */
 
 long do_grant_table_op(
     unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
@@ -3773,6 +3777,7 @@ long do_grant_table_op(
         break;
     }
 
+#ifdef CONFIG_ARM
     case GNTTABOP_cache_flush:
     {
         XEN_GUEST_HANDLE_PARAM(gnttab_cache_flush_t) cflush =
@@ -3794,6 +3799,7 @@ long do_grant_table_op(
         }
         break;
     }
+#endif
 
     default:
         rc = -ENOSYS;
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 09:11:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 09:11:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976907.1364013 (Exim 4.92)
	(envelope-from )
	id 1uCEKX-0000rO-Ci; Tue, 06 May 2025 09:11:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976907.1364013; Tue, 06 May 2025 09:11: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 1uCEKX-0000rH-A2; Tue, 06 May 2025 09:11:13 +0000
Received: by outflank-mailman (input) for mailman id 976907;
 Tue, 06 May 2025 09:11:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCEKW-0000rB-2O
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 09:11:12 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2415::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0badb737-2a5a-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 11:11:09 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH3PR12MB7689.namprd12.prod.outlook.com (2603:10b6:610:14d::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.21; Tue, 6 May
 2025 09:11:01 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 09:11: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" 
X-Inumbo-ID: 0badb737-2a5a-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=L2EI/raqi3TkcuhY0jhHc6aGB4h4/ZSwUQAqTmQ22d1BMRbFrEXqLkv600GadQ9oppva4rPUQFFOUIHlFKHbndqG4SvLMzrK8AqdZT4L1ulXe+M5iszQgL1Pvc8A/2zb9NozfQfQJOSHa+wWIqgP9d8KuvLBX6uesKVLaWFUQzs8EwoleV+cQHRspcupkbt7XH+MdlvhkOV43Pw+wq3PGCxqySHqoVKtM0uQWAXX8aPYiJ0MoTAoiX6V6R9MbkRmUU54dSeI6LvphuGfqhMgRB+uh6zY1OMWJGZquVGtHP075PEEpOEm5TDQXjN5l+V0BIWp6PVKSluyowwdHh13kA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6A3uaH0VVPxzCGmuST5QWIYz6b0JbRau4C/+yRuexQo=;
 b=gTiRzxp2FRKpLYuwFpiANSS2gwJRFZsAUPM6segZiIdWmXWw+S3IuLvtfH7N+RFOgfTFqVVlSJGKbG23Y0Hzf048vObhRtik70cotv2On1c4bOQNtlch070um1PvhNVkGaIrcLGy1rra5Iwu5efyfrYV7KlOuVPEM+DgBJhiScCFQEWs/kxU7J3Gs7dfayf8fNKyUU8a23HLn5TliCN7Avhgcexi+70/ebVU27w3AqjNO2BGF5jDHeJHDUF6J5cBJwan1jr0Z/GUNpb2RbRnUnGsN/BFTaGjhx/Le4YEHFsvdx46geaaF6XBQ1dQIj2EtdK+jUEVym6vg/ZOh5T8Cw==
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=6A3uaH0VVPxzCGmuST5QWIYz6b0JbRau4C/+yRuexQo=;
 b=x9zfV+F6L02LOtVdFyAAQWQwTZ7HSXQEfu/mjadCKcQFygpu3Dyc5UhBxa0RxKZaQiE42GYr4UE+lmvPyQivU7V0KrZ+Bd0awS1qccALZEilmCX2fxyDXJRedew4IQtRjPhs7ds5eKqFvfNqWpBNoqkothwy56F+fILSHdM4MiU=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Anthony PERARD , "Orzel,
 Michal" , Julien Grall , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 03/15] xen/x86: introduce new sub-hypercall to
 propagate CPPC data
Thread-Topic: [PATCH v4 03/15] xen/x86: introduce new sub-hypercall to
 propagate CPPC data
Thread-Index: AQHbrRCmWPNHyarMuUaK4nZ2TXIaALO5UliAgAwK3VA=
Date: Tue, 6 May 2025 09:11:01 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-4-Penny.Zheng@amd.com>
 <2e1de23f-cc79-4d37-8667-0afd07736db3@suse.com>
In-Reply-To: <2e1de23f-cc79-4d37-8667-0afd07736db3@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=a2e2940d-15e5-4846-bbe2-5a87bdc763f5;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-06T09:10:54Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|CH3PR12MB7689:EE_
x-ms-office365-filtering-correlation-id: 88156d1d-a0d2-4e80-b036-08dd8c7dec10
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?eXBVMWUvemtPK1V3aXhvdHlUdXFYeVdRTlB0MWpJMFMxazc1aDRzQU9CQ2h3?=
 =?utf-8?B?RFdKeTFGSHd3UktuMEZMK2JKdnZwUGNsYWh3WUhYSXVIMElUbDdLVTVLbmdn?=
 =?utf-8?B?QjAveFRYSVEybGFqazhsYXdXcVRKNCtUVjFpbC9iTHFaYTdDYW55ZUhQVFp5?=
 =?utf-8?B?eDdoT2xLekg1NSt4VW9OZFR3L2ljeG5LbG12dU9ac0tQY2tEQ1pPaDFscVZ0?=
 =?utf-8?B?MWV0ajExN25teUtRWFI1VExsUFE5aENtOE1pbzNvYUkzVk9aaDlKbVhEMjlk?=
 =?utf-8?B?SFVDMWJxU1RHN0l5QWZtOUdDTGkzeUZWc25oeFNwYXFEWU9FZmx3eWtRQW54?=
 =?utf-8?B?SXkzTHhGdlNPUloxMjA2bHhhYkF3bTl2L3MxUjRWb0QvRUY1ZXZvNFg4aVlv?=
 =?utf-8?B?ZE0rMVdPeXpiVVNMaHcyNzNRVHU1VmxMV21qcEQ3WXpFeWcyR1lST2tzL1Vn?=
 =?utf-8?B?Y2xpRCswUWMwZlovbVEramlyOVdYNnJ1Ynl1TnFsV3ZuUS9ralh4TkxFUnlm?=
 =?utf-8?B?dVoxMG1CdXFoQW9YRzcxTnJDQkVZalZBdWo3S3h0c1l0KzN0NVVIMUJrQURR?=
 =?utf-8?B?SkpiSlpOdDdXbG5NbXVCaWJRczFBVDdSOWdYbUVTeS9ybUtzUXBlTFo5eFNm?=
 =?utf-8?B?aXQ1Ry9zMVd5Z0hLdlEzazg5TTJBMS92bjBONC9kYjJSYnpYSGJjbG4yTGN3?=
 =?utf-8?B?VzBQQURVdG42N1FPaGRYVXNGY0laT0l3RXJJWkFNMk5OUWpnZUFoTjV4Y2RQ?=
 =?utf-8?B?Q0RqRlZZL21SS2loNzYwU05TSjhLdVZzSmR3MTRjVTVpVkd3NzNjeTNkQ3Fk?=
 =?utf-8?B?REFKUDJjTDRzbXNEQndTRlg4VHRvMGZmTWx6Q3ZzSHNOeXBHNXY3dWZpc0dJ?=
 =?utf-8?B?NEhQbzVlN2JHdFNVYmZVS3ZKdDZnazFMQXpETE5wY0lqamlUMjIyUEViV1Rr?=
 =?utf-8?B?V3Z6ejNodDQ2ZVNEaDF4cVZhR256M0JDc2RsTGFXRzVTNHNwMTRObDdTQTFT?=
 =?utf-8?B?K2UzWTdENVRXV1NyUldSbnR1WkdwcGw2dXRMMjg5RDJWbWZCWHV4SnlZdFFG?=
 =?utf-8?B?K3FTbXZBbmEvUjV2YUNhQWpaOCtCcGM5R1JxbDNHai9qOWpVcDFpK3N6VVRa?=
 =?utf-8?B?RHRZZVhhcFFOWk85aXE5WVRVUEZXWkx1anhleUdKUE04Z2tnQXZnb0xLS2xD?=
 =?utf-8?B?M0tHTVVIRmFiRlZ0WDRGOHVFbjhRbnVNejNwQ2ZCek12Y0Fka2NsbG41cUxu?=
 =?utf-8?B?Vm1wNG9EaG11K2w0ZXBlREQ1SnVNMHhvcnc5Tk9ubEtnUmgwNllUUnpwTGFT?=
 =?utf-8?B?aklIbjJvQ3Nwbm5jQjJ3TlZQZFZRQ0JFZ1h0M2pkejEyOEZhck5EMWJpTzVG?=
 =?utf-8?B?SzdZaXJoUUd5dlI1TlIraEw1eFRDbWt6VCtIR2g4aU9xZ3pLbkdSbE02SFdx?=
 =?utf-8?B?MnM2SWhWOUcyVGJqZittQzZNTUJVdExjdy9BOG5VeFcvTXJ5ckNBaVdUY2Fi?=
 =?utf-8?B?Tm51a1VXRkxPaEdvTGFkSENiWVZnZm9lYW1lV1lxNmUxTmVwd0c4aE9aOXFG?=
 =?utf-8?B?N2ZXU1RYM0kvVTZOV1U4Qnh3VURvM1dGNHNEOVh2UnM5bzI2NXNEdUIwRjdk?=
 =?utf-8?B?NzIyd1NmTEVWOEFKRDh2WG5YL25IK0VnZ3NueXFkVDdmcFNkY0Fsb2RJd1k0?=
 =?utf-8?B?ZW9udFJCRnNaSkRlL0hJekhBY2xSaVFyTjFtUXhsTEpsOEEwNmJycFpKV1lB?=
 =?utf-8?B?Q0RyYkFtUjdFTVFvZ0Z1WDdlRzBhR0Zod2p5NHVwSW1Bc3VjTStkSFdKalc2?=
 =?utf-8?B?c0N3L1pPUVVCSkVrMlNCaUtqL2duUUtNNmI2ZThNcW92cWhWYUJWWmZRbHRR?=
 =?utf-8?B?cmtZSU82YlVuTGVialM1enFtcUtFcXNLcDJ2eDlVdU1uSDhxRmdOYlBHNUxB?=
 =?utf-8?Q?4rtPpvLTsEo=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WEJyN0MybFRXazlFMkFrdnZYenZuWFFuV3RYa015Q3VnQkVWNTJiV1QrYUZQ?=
 =?utf-8?B?d3VSNlpSVHJRYTIzRlpLTHliZ3ZVQ3hVdkRIMHpsWm5XbjJTUnpSTkV5bjlr?=
 =?utf-8?B?UUEzNEFXZVhvdW00NUVoZXRRUDdzMTVzbm1DOGF3eWZUVjZIbm9RSlNYN200?=
 =?utf-8?B?N0hXQ1A4NG90WmZQaW9vTzQxMzAyQjhGMHBMQmpnUEtNaWh5U01PaDAzc3BF?=
 =?utf-8?B?dkExQ0h4dFRiSU9ITGxWMUFCaGYrWDJDVXpWamdWYndZT0Qyb1ArcUZ0NnVD?=
 =?utf-8?B?SGVnbHFrbGtzT041a0RicVpjYXhpZlFOa00wWmViVjN2Q0hHdXZ5d1ZiNzJI?=
 =?utf-8?B?dzQyVnkwdi9JWFRYZ29tOVhwc3YzWFk5dDMzSEgrRS81b0pnTU9oQTcwcm1P?=
 =?utf-8?B?YnNvNEtLOXNXay9iVk1TQkQvQTZFUEwwZktVTWpRV2RtcTBOWnhvdk01Vy9k?=
 =?utf-8?B?N09BSzUzeHU4N21DdWZCV1A5aXFZWU90YUQ5dzFCNjEvM0FzOG5CaEpybUhu?=
 =?utf-8?B?cUx3cTJpTkhmbHNhdWU5NStHZHJiQm9ydEgwRk1sbGFCWUt6ai9yWWdzTnFT?=
 =?utf-8?B?bDhrM1ozdDFvbW1XS29ubWI2cE1waG9lM3plc0wrT2VLaUdrK2hkNHNpWUpm?=
 =?utf-8?B?c3A1aVNTbEVSZitUWlJzcUowUFFGcnNCekJzazNKOCttcERNTzk4R2kwYVRF?=
 =?utf-8?B?cFpzZjF4UmVTYlNpUG83bERJSXVrdVRQZ3RCeWtabVgyM2N3UWdGa1d0TUdW?=
 =?utf-8?B?MlJWeUUrVitzdmRVOWFQSXdSU3ZNZTdLYmc1azhyTisySmk0Tjc5OVBycGxj?=
 =?utf-8?B?aWxqSUhmY1prNjV2bjZNUFExYW5kT1lQOGZJaStKVy8zYXdVR3laRnNOdFB4?=
 =?utf-8?B?RlNveUR2eklCelp6YUo1dHNMZGZJa0xoRXlqYjlvdVdKRTNKNjFUNlRIbVNE?=
 =?utf-8?B?ZmtnNUNRRGg2TERKaGpKK3FmMnFnSkxhcE95TE4rMjI3c0ppR01kYzZURHFC?=
 =?utf-8?B?VTFzY3BLVE94ZjRLdUJhOVhnOUtMcVJNaytsVnlKSURjbUMyYlBMZ2RNVlND?=
 =?utf-8?B?aDd1cElLWTdNZjJqTkxNUHJHZFRqN0RaOEhERjRKa09OQ25jeE1OT1BFYzZk?=
 =?utf-8?B?UTRqMnZ6SWJFM3R6U3RqZWFvZGx2NFYrYjVIeitmclYvZlpuRDJTTlVFZlpv?=
 =?utf-8?B?a3hkcXdCWUl0bFRkOFNXNDR5QUJNVjZod2w5Z2RkeERkV1BlR2FaVzJEUFlU?=
 =?utf-8?B?cGx4dG4xSlFnNXF2UmxLbjZuaUE3SVZiVkJTRnFMeEJhUFZMd1hTT2pzTUFC?=
 =?utf-8?B?cUJzYzNlcFROeHdRZ1ZiUkw1VTZJcys1VzlKc2RMOHdkS0pnTlY2d1NiQlFN?=
 =?utf-8?B?S1MzaVdXRTE5cm5ZdThVUXkzcWFLck5DcHMzazRLSXl2cllWS1RVRVNCdDFS?=
 =?utf-8?B?YWZOSG4wSTB3aWN3c2EwRXo3L1BoUWt1Njd0SlRFUnRKaGxZaU1UTyswejV0?=
 =?utf-8?B?RmdOWjFGQkw1dXR3dGtrMCthMEpNYjJIQ0RGVEl4MlhranMvczJYdGJ0VURT?=
 =?utf-8?B?djdOTUhPczJZTUlPSFFhenYrZXRVOVNkUkx2NkVDdG9TUlpEam5xeFNSVm9W?=
 =?utf-8?B?QVB0dHA1K3U4NjlYb04xZGt6cXUrcFZmSkZSWHg2Y3Rsck5VUFdrYUZSMDRa?=
 =?utf-8?B?Y1Z1cG5oazNqR0h1MzZrTjQxMXJJMktaZjJXbXl3cHpxWExQTFFJaklpdnpK?=
 =?utf-8?B?bUxDY1dYRTFwamZ1ZDBSOUo2WHFwcVZzR09ObmhSdGV2amVjZVpyZG45K0tu?=
 =?utf-8?B?dCttQW9TM0NYVW40WW94cG1ocFhPbnozMEJsZUVLejY4Ym1zK2M3eVZ6YXU4?=
 =?utf-8?B?M09xYXdOSUhJNU90bVhGaEVvSm5nWVd3dFo1SkNBZzdYa093Qlh0V25ucVRD?=
 =?utf-8?B?elZFeUtpaVJWY2RHL1FjdE9BK1NqNCsvejBiZXJzeC8vMm4vbytKOVV6aWJS?=
 =?utf-8?B?OElEQ2ZMYUplVC8rRzFua1NZK1ViOTJKOUgrWjNJbGpkL09sdEw2NVBDLzVp?=
 =?utf-8?B?S3RMNHByZ1lLMU5lZlN4YzhxaG42WmQ2eTcrWUxtTnRQaFFoVTJXaEROUWVr?=
 =?utf-8?Q?d0A4=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 88156d1d-a0d2-4e80-b036-08dd8c7dec10
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2025 09:11:01.5469
 (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: ogfTtX1l2xWS0iFbkkyNxbvBQjRmaQEe/FaENGAimnWSGTghef6mclKeJysUfMBRQkji95D5patAKFq1zVgCuQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7689

W1B1YmxpY10NCg0KSEkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBK
YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgMjgs
IDIwMjUgMTE6NTcgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4N
Cj4gQ2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBj
aXRyaXguY29tPjsNCj4gQW50aG9ueSBQRVJBUkQgPGFudGhvbnkucGVyYXJkQHZhdGVzLnRlY2g+
OyBPcnplbCwgTWljaGFsDQo+IDxNaWNoYWwuT3J6ZWxAYW1kLmNvbT47IEp1bGllbiBHcmFsbCA8
anVsaWVuQHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHNzdGFiZWxsaW5pQGtlcm5l
bC5vcmc+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQ
QVRDSCB2NCAwMy8xNV0geGVuL3g4NjogaW50cm9kdWNlIG5ldyBzdWItaHlwZXJjYWxsIHRvIHBy
b3BhZ2F0ZQ0KPiBDUFBDIGRhdGENCj4NCj4gT24gMTQuMDQuMjAyNSAwOTo0MCwgUGVubnkgWmhl
bmcgd3JvdGU6DQo+ID4gKyAgICBpZiAoIGNwcGNfZGF0YS0+ZmxhZ3MgJiBYRU5fQ1BQQ19DUEMg
KQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIGlmICggY3BwY19kYXRhLT5jcGMuaGlnaGVzdF9w
ZXJmID09IDAgfHwNCj4gPiArICAgICAgICAgICAgIGNwcGNfZGF0YS0+Y3BjLmhpZ2hlc3RfcGVy
ZiA+IFVJTlQ4X01BWCB8fA0KPiA+ICsgICAgICAgICAgICAgY3BwY19kYXRhLT5jcGMubm9taW5h
bF9wZXJmID09IDAgfHwNCj4gPiArICAgICAgICAgICAgIGNwcGNfZGF0YS0+Y3BjLm5vbWluYWxf
cGVyZiA+IFVJTlQ4X01BWCB8fA0KPiA+ICsgICAgICAgICAgICAgY3BwY19kYXRhLT5jcGMubG93
ZXN0X25vbmxpbmVhcl9wZXJmID09IDAgfHwNCj4gPiArICAgICAgICAgICAgIGNwcGNfZGF0YS0+
Y3BjLmxvd2VzdF9ub25saW5lYXJfcGVyZiA+IFVJTlQ4X01BWCB8fA0KPiA+ICsgICAgICAgICAg
ICAgY3BwY19kYXRhLT5jcGMubG93ZXN0X3BlcmYgPT0gMCB8fA0KPiA+ICsgICAgICAgICAgICAg
Y3BwY19kYXRhLT5jcGMubG93ZXN0X3BlcmYgPiBVSU5UOF9NQVggfHwNCj4gPiArICAgICAgICAg
ICAgIGNwcGNfZGF0YS0+Y3BjLmxvd2VzdF9wZXJmID4NCj4gPiArICAgICAgICAgICAgICAgIGNw
cGNfZGF0YS0+Y3BjLmxvd2VzdF9ub25saW5lYXJfcGVyZiB8fA0KPg0KPiBXaGVyZSdzIHRoaXMg
b3JkZXJpbmcgc3BlbGxlZCBvdXQgaW4gdGhlIHNwZWM/DQo+DQoNCkNsaXAgYSBzbmlwcGV0IGZy
b20gZGVzY3JpcHRpb24gb24gbG93ZXN0IHBlcmZvcm1hbmNlWzFdLCB3ZSBtYXkgZGVkdWNlIHRo
YXQNCmBgYA0KU2VsZWN0aW5nIGEgcGVyZm9ybWFuY2UgbGV2ZWwgbG93ZXIgdGhhbiB0aGUgbG93
ZXN0IG5vbmxpbmVhciBwZXJmb3JtYW5jZSBsZXZlbCBtYXkgYWN0dWFsbHkgY2F1c2UgYW4gZWZm
aWNpZW5jeSBwZW5hbHR5LA0KYnV0IHNob3VsZCByZWR1Y2UgdGhlIGluc3RhbnRhbmVvdXMgcG93
ZXIgY29uc3VtcHRpb24gb2YgdGhlIHByb2Nlc3Nvcg0KYGBgDQpsb3dlc3QgaXMgc21hbGxlciB0
aGFuIGxvd2VzdCBub25saW5lYXINCg0KPiA+ICsgICAgICAgICAgICAgY3BwY19kYXRhLT5jcGMu
bG93ZXN0X25vbmxpbmVhcl9wZXJmID4NCj4gPiArICAgICAgICAgICAgICAgIGNwcGNfZGF0YS0+
Y3BjLm5vbWluYWxfcGVyZiB8fA0KPiA+ICsgICAgICAgICAgICAgY3BwY19kYXRhLT5jcGMubm9t
aW5hbF9wZXJmID4gY3BwY19kYXRhLT5jcGMuaGlnaGVzdF9wZXJmICkNCj4gPiArICAgICAgICAg
ICAgLyoNCj4gPiArICAgICAgICAgICAgICogUmlnaHQgbm93LCBYZW4gZG9lc24ndCBhY3R1YWxs
eSB1c2UgcGVyZiB2YWx1ZXMNCj4gPiArICAgICAgICAgICAgICogaW4gQUNQSSBfQ1BDIHRhYmxl
LCB3YXJuaW5nIGlzIGVub3VnaC4NCj4gPiArICAgICAgICAgICAgICovDQo+ID4gKyAgICAgICAg
ICAgIHByaW50ayhYRU5MT0dfV0FSTklORw0KPiA+ICsgICAgICAgICAgICAgICAgICAgIkJyb2tl
biBDUFBDIHBlcmYgdmFsdWVzOiBsb3dlc3QoJXUpLCBub25saW5lYXJfbG93ZXN0KCV1KSwNCj4g
bm9taW5hbCgldSksIGhpZ2hlc3QoJXUpXG4iLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgY3Bw
Y19kYXRhLT5jcGMubG93ZXN0X3BlcmYsDQo+ID4gKyAgICAgICAgICAgICAgICAgICBjcHBjX2Rh
dGEtPmNwYy5sb3dlc3Rfbm9ubGluZWFyX3BlcmYsDQo+ID4gKyAgICAgICAgICAgICAgICAgICBj
cHBjX2RhdGEtPmNwYy5ub21pbmFsX3BlcmYsDQo+ID4gKyAgICAgICAgICAgICAgICAgICBjcHBj
X2RhdGEtPmNwYy5oaWdoZXN0X3BlcmYpOw0KPg0KPiBJZiB0aGlzIHdhcm5pbmcgd2FzIHRvIGV2
ZXIgc3VyZmFjZSwgaXQgd291bGQgbGlrZWx5IHN1cmZhY2UgZm9yIGV2ZXJ5IENQVS4NCj4gVGhh
dCdzIHVubmVjZXNzYXJpbHkgdmVyYm9zZSwgSSBndWVzcy4gUGxlYXNlIGNvbnNpZGVyIHVzaW5n
IHByaW50a19vbmNlKCkgaGVyZS4NCj4NCg0KVW5kZXJzdG9vZA0KDQo+IEFsc28sIGlzICJyaWdo
dCBub3ciIChhcyB0aGUgY29tbWVudCBzYXlzKSBzdGlsbCBnb2luZyB0byBiZSB0cnVlIGJ5IHRo
ZSBlbmQgb2YgdGhlDQo+IHNlcmllcz8gRGlkbid0IEkgc2VlIHlvdSB1c2UgdGhlIHZhbHVlcyBp
biBlYXJsaWVyIHZlcnNpb25zPw0KPg0KDQpUaGUgcmVhc29uIHdoeSBJIGFkZGVkIHRoaXMgY29t
bWVudCBpcyB0aGF0IGluIGN1cnJlbnQgaW1wbGVtZW50YXRpb24sIHdlIGFjdHVhbGx5DQpkb24n
dCB1c2UgdmFsdWVzIHJlYWQgZnJvbSBBQ1BJIF9DUEMgdGFibGUgZm9yIGxvd2VzdF9wZXJmLCBs
b3dlc3Rfbm9ubGluZWFyX3BlcmYsDQpub21pbmFsX3BlcmYsIGFuZCBoaWdoZXN0X3BlcmYuDQpX
ZSByZWFkIENQUEMgY2FwYWJpbGl0eSBNU1IgdG8gZ2V0IHRoZXNlIGZvdXIgdmFsdWVzLg0KV2hh
dCB3ZSBhY3R1YWxseSB1c2UgaXMgdGhlIGZvbGxvd2luZyBvcHRpb25hbCBsb3dlc3RfbWh6IGFu
ZCBub21pbmFsX21oei4gV2UgcmVhZA0KdGhlc2UgdHdvIHZhbHVlcyBmb3IgcGVyZl90b19raHog
dHJhbnNpdGlvbi4NCg0KVGhlcmUgYXJlIHR3byB3YXlzIHRvIHJlYWQgQ1BQQyBjYXBhYmlsaXR5
IGluZm8sIG9uZSBpcyBmcm9tIE1TUiByZWdpc3RlciwgYW5kIHRoZSBvdGhlciBpcyBmcm9tDQpf
Q1BDIHRhYmxlLiBPbmx5IGluIHZlcnkgZmV3IGhhcmR3YXJlLCBNU1IgaXMgbm90IHN1cHBvcnRl
ZCwgYW5kIHdlIG11c3Qgc3dpdGNoIHRvIHVzZSBBQ1BJIF9DUEMNClN1Y2ggc2NlbmFyaW8gaXMg
bm90IGNvdmVyZWQgaW4gdGhpcyBwYXRjaCBzZXJpZS4gSSd2ZSBtZW50aW9uZWQgaXQgaW4gdGhl
IGNvdmVyIGxldHRlci4NClRoZSBkaWZmaWN1bHR5IGFjdHVhbGx5IGlzIHRoYXQgd2hlbiB3ZSB0
cnkgdG8gdXNlIEFDUEkgX0NQQyB0byBkbyBDUFBDIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcsDQpz
b21lIGNvbnRyb2wgcmVnaXN0ZXJzIGFyZSBwcm9iYWJseSBpbXBsZW1lbnRlZCBpbiB0aGUgUGxh
dGZvcm0gQ29tbXVuaWNhdGlvbnMgQ2hhbm5lbCAoUENDKSBpbnRlcmZhY2UsIHdoaWNoDQppcyBu
b3Qgc3VwcG9ydGVkIGluIFhlbi4NCg0KPiA+ICsNCj4gPiArICAgIGlmICggY3BwY19kYXRhLT5m
bGFncyA9PSAoWEVOX0NQUENfUFNEIHwgWEVOX0NQUENfQ1BDKSApDQo+DQo+IElmIGVpdGhlciBm
bGFnIG1heSBiZSBjbGVhciwgLi4uDQo+DQo+ID4gKyAgICB7DQo+ID4gKyAgICAgICAgcG1faW5m
by0+Y3BwY19kYXRhID0gKmNwcGNfZGF0YTsNCj4gPiArICAgICAgICBpZiAoIGNwdWZyZXFfdmVy
Ym9zZSApDQo+ID4gKyAgICAgICAgew0KPiA+ICsgICAgICAgICAgICBwcmludF9QU0QoJnBtX2lu
Zm8tPmNwcGNfZGF0YS5kb21haW5faW5mbyk7DQo+ID4gKyAgICAgICAgICAgIHByaW50X0NQUEMo
JnBtX2luZm8tPmNwcGNfZGF0YSk7DQo+DQo+IC4uLiB3aHkgdW5jb25kaXRpb25hbGx5IGxvb2cg
Ym90aD8NCj4NCj4gPiArICAgICAgICB9DQo+ID4gKw0KPiA+ICsgICAgICAgIHBtX2luZm8tPmlu
aXQgPSBYRU5fQ1BQQ19JTklUOw0KPg0KPiBQbHVzIGlzIGl0IGNvcnJlY3QgdG8gc2V0IHRoaXMg
ZmxhZyBpZiBlaXRoZXIgb2YgdGhlIGluY29taW5nIGZsYWdzIHdhcyBjbGVhcj8NCj4NCg0KSG1t
LCBJIG1heSBub3QgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuIGhlcmUuLi4NCkkgbG9nIGFuZCBz
ZXQgdGhpcyBmbGFnIG9ubHkgd2hlbiBib3RoIGZsYWdzIGFyZSBzZXQgKGNwcGNfZGF0YS0+Zmxh
Z3MgPT0gKFhFTl9DUFBDX1BTRCB8IFhFTl9DUFBDX0NQQykpDQpfUFNEIGVudHJ5IGFuZCBfQ1BD
IGVudHJ5IGFyZSBib3RoIG1hbmRhdG9yeQ0KRGlkIHlvdSBzdWdnZXN0IHRoYXQgd2Ugc2hhbGwg
Z2l2ZSB3YXJuaW5nIG1lc3NhZ2Ugd2hlbiBlaXRoZXIgZmxhZyBpcyBjbGVhcj8NCg0KPiBKYW4N
Cg0KWzFdIGh0dHBzOi8vdWVmaS5vcmcvc3BlY3MvQUNQSS82LjUvMDhfUHJvY2Vzc29yX0NvbmZp
Z3VyYXRpb25fYW5kX0NvbnRyb2wuaHRtbD9oaWdobGlnaHQ9Y3BwYyNsb3dlc3QtcGVyZm9ybWFu
Y2UNCg==


From xen-devel-bounces@lists.xenproject.org Tue May 06 09:20:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 09:20:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976922.1364022 (Exim 4.92)
	(envelope-from )
	id 1uCETW-0002Tp-9f; Tue, 06 May 2025 09:20:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976922.1364022; Tue, 06 May 2025 09:20: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 1uCETW-0002Ti-72; Tue, 06 May 2025 09:20:30 +0000
Received: by outflank-mailman (input) for mailman id 976922;
 Tue, 06 May 2025 09:20:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uCETU-0002Tc-W4
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 09:20:29 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 56e0d9f0-2a5b-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 11:20:24 +0200 (CEST)
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 3906C1F395;
 Tue,  6 May 2025 09:20: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 67499137CF;
 Tue,  6 May 2025 09:20:22 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id aNu9F1bUGWgBbAAAD6G6ig
 (envelope-from ); Tue, 06 May 2025 09:20: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" 
X-Inumbo-ID: 56e0d9f0-2a5b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1746523223; 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=SOSwn+O7fzFgeK18tfEQyq0imvcETcUg8KBVasQSn4w=;
	b=kriZpqdhOLBPPcruOud6UNmVzlEUq2xRjIwz8bZZFAG+0IQ5YwsePmFs/IObVQ5uX+3Bte
	GWUV+IhgDAcRFRchqFV+riec8rrlg/N9toymI+5EMWGjsxZHeP5YYMLN1WlStdR21cnlWk
	LAaqaoRE1YHJp6Eh3MpIfn/2a8tqxB8=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1746523223; 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=SOSwn+O7fzFgeK18tfEQyq0imvcETcUg8KBVasQSn4w=;
	b=kriZpqdhOLBPPcruOud6UNmVzlEUq2xRjIwz8bZZFAG+0IQ5YwsePmFs/IObVQ5uX+3Bte
	GWUV+IhgDAcRFRchqFV+riec8rrlg/N9toymI+5EMWGjsxZHeP5YYMLN1WlStdR21cnlWk
	LAaqaoRE1YHJp6Eh3MpIfn/2a8tqxB8=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	linux-coco@lists.linux.dev,
	kvm@vger.kernel.org,
	linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev
Cc: xin@zytor.com,
	Juergen Gross ,
	"Kirill A. Shutemov" ,
	Dave Hansen ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	"H. Peter Anvin" ,
	Sean Christopherson ,
	Paolo Bonzini ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu ,
	Dexuan Cui ,
	Vitaly Kuznetsov ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list 
Subject: [PATCH 0/6] x86/msr: let paravirt inline rdmsr/wrmsr instructions
Date: Tue,  6 May 2025 11:20:09 +0200
Message-ID: <20250506092015.1849-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[26];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -2.80
X-Spam-Flag: NO

When building a kernel with CONFIG_PARAVIRT_XXL the paravirt
infrastructure will always use functions for reading or writing MSRs,
even when running on bare metal.

Switch to inline RDMSR/WRMSR instructions in this case, reducing the
paravirt overhead.

In order to make this less intrusive, some further reorganization of
the MSR access helpers is done in the first 4 patches.

This series has been tested to work with Xen PV and on bare metal.

There has been another approach by Xin Li, which used dedicated #ifdef
and removing the MSR related paravirt hooks instead of just modifying
the paravirt code generation.

Please note that I haven't included the use of WRMSRNS or the
immediate forms of WRMSR and RDMSR, because I wanted to get some
feedback on my approach first. Enhancing paravirt for those cases
is not very complicated, as the main base is already prepared for
that enhancement.

This series is based on the x86/msr branch of the tip tree.

Juergen Gross (6):
  coco/tdx: Rename MSR access helpers
  x86/kvm: Rename the KVM private read_msr() function
  x86/msr: minimize usage of native_*() msr access functions
  x86/msr: Move MSR trace calls one function level up
  x86/paravirt: Switch MSR access pv_ops functions to instruction
    interfaces
  x86/msr: reduce number of low level MSR access helpers

 arch/x86/coco/tdx/tdx.c                   |   8 +-
 arch/x86/hyperv/ivm.c                     |   2 +-
 arch/x86/include/asm/kvm_host.h           |   2 +-
 arch/x86/include/asm/msr.h                | 116 ++++++++++-------
 arch/x86/include/asm/paravirt.h           | 152 ++++++++++++++--------
 arch/x86/include/asm/paravirt_types.h     |  13 +-
 arch/x86/include/asm/qspinlock_paravirt.h |   5 +-
 arch/x86/kernel/kvmclock.c                |   2 +-
 arch/x86/kernel/paravirt.c                |  26 +++-
 arch/x86/kvm/svm/svm.c                    |  16 +--
 arch/x86/kvm/vmx/vmx.c                    |   4 +-
 arch/x86/xen/enlighten_pv.c               |  60 ++++++---
 arch/x86/xen/pmu.c                        |   4 +-
 13 files changed, 262 insertions(+), 148 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 09:20:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 09:20:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976923.1364033 (Exim 4.92)
	(envelope-from )
	id 1uCETj-0002mD-HS; Tue, 06 May 2025 09:20:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976923.1364033; Tue, 06 May 2025 09: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 1uCETj-0002m6-Dt; Tue, 06 May 2025 09:20:43 +0000
Received: by outflank-mailman (input) for mailman id 976923;
 Tue, 06 May 2025 09:20:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uCETi-0002lJ-Ae
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 09:20:42 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 614736f9-2a5b-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 11:20:41 +0200 (CEST)
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 F06B01F391;
 Tue,  6 May 2025 09:20: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 49800137CF;
 Tue,  6 May 2025 09:20: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 zH5wEGjUGWggbAAAD6G6ig
 (envelope-from ); Tue, 06 May 2025 09: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" 
X-Inumbo-ID: 614736f9-2a5b-11f0-9eb4-5ba50f476ded
Authentication-Results: smtp-out2.suse.de;
	none
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	linux-hyperv@vger.kernel.org,
	kvm@vger.kernel.org
Cc: xin@zytor.com,
	Juergen Gross ,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu ,
	Dexuan Cui ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Sean Christopherson ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 3/6] x86/msr: minimize usage of native_*() msr access functions
Date: Tue,  6 May 2025 11:20:12 +0200
Message-ID: <20250506092015.1849-4-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250506092015.1849-1-jgross@suse.com>
References: <20250506092015.1849-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spam-Level: 
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Spam-Score: -4.00
X-Spam-Flag: NO
X-Rspamd-Queue-Id: F06B01F391
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

In order to prepare for some MSR access function reorg work, switch
most users of native_{read|write}_msr[_safe]() to the more generic
rdmsr*()/wrmsr*() variants.

For now this will have some intermediate performance impact with
paravirtualization configured when running on bare metal, but this
is a prereq change for the planned direct inlining of the rdmsr/wrmsr
instructions with this configuration.

The main reason for this switch is the planned move of the MSR trace
function invocation from the native_*() functions to the generic
rdmsr*()/wrmsr*() variants. Without this switch the users of the
native_*() functions would lose the related tracing entries.

Note that the Xen related MSR access functions will not be switched,
as these will be handled after the move of the trace hooks.

Signed-off-by: Juergen Gross 
---
 arch/x86/hyperv/ivm.c      |  2 +-
 arch/x86/kernel/kvmclock.c |  2 +-
 arch/x86/kvm/svm/svm.c     | 16 ++++++++--------
 arch/x86/xen/pmu.c         |  4 ++--
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c
index 09a165a3c41e..fe177a6be581 100644
--- a/arch/x86/hyperv/ivm.c
+++ b/arch/x86/hyperv/ivm.c
@@ -319,7 +319,7 @@ int hv_snp_boot_ap(u32 cpu, unsigned long start_ip)
 	asm volatile("movl %%ds, %%eax;" : "=a" (vmsa->ds.selector));
 	hv_populate_vmcb_seg(vmsa->ds, vmsa->gdtr.base);
 
-	vmsa->efer = native_read_msr(MSR_EFER);
+	rdmsrq(MSR_EFER, vmsa->efer);
 
 	vmsa->cr4 = native_read_cr4();
 	vmsa->cr3 = __native_read_cr3();
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index ca0a49eeac4a..b6cd45cce5fe 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -196,7 +196,7 @@ static void kvm_setup_secondary_clock(void)
 void kvmclock_disable(void)
 {
 	if (msr_kvm_system_time)
-		native_write_msr(msr_kvm_system_time, 0);
+		wrmsrq(msr_kvm_system_time, 0);
 }
 
 static void __init kvmclock_init_mem(void)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 4c2a843780bf..3f0eed84f82a 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -482,12 +482,12 @@ static void svm_init_erratum_383(void)
 		return;
 
 	/* Use _safe variants to not break nested virtualization */
-	if (native_read_msr_safe(MSR_AMD64_DC_CFG, &val))
+	if (rdmsrq_safe(MSR_AMD64_DC_CFG, &val))
 		return;
 
 	val |= (1ULL << 47);
 
-	native_write_msr_safe(MSR_AMD64_DC_CFG, val);
+	wrmsrq_safe(MSR_AMD64_DC_CFG, val);
 
 	erratum_383_found = true;
 }
@@ -650,9 +650,9 @@ static int svm_enable_virtualization_cpu(void)
 		u64 len, status = 0;
 		int err;
 
-		err = native_read_msr_safe(MSR_AMD64_OSVW_ID_LENGTH, &len);
+		err = rdmsrq_safe(MSR_AMD64_OSVW_ID_LENGTH, &len);
 		if (!err)
-			err = native_read_msr_safe(MSR_AMD64_OSVW_STATUS, &status);
+			err = rdmsrq_safe(MSR_AMD64_OSVW_STATUS, &status);
 
 		if (err)
 			osvw_status = osvw_len = 0;
@@ -2149,7 +2149,7 @@ static bool is_erratum_383(void)
 	if (!erratum_383_found)
 		return false;
 
-	if (native_read_msr_safe(MSR_IA32_MC0_STATUS, &value))
+	if (rdmsrq_safe(MSR_IA32_MC0_STATUS, &value))
 		return false;
 
 	/* Bit 62 may or may not be set for this mce */
@@ -2160,11 +2160,11 @@ static bool is_erratum_383(void)
 
 	/* Clear MCi_STATUS registers */
 	for (i = 0; i < 6; ++i)
-		native_write_msr_safe(MSR_IA32_MCx_STATUS(i), 0);
+		wrmsrq_safe(MSR_IA32_MCx_STATUS(i), 0);
 
-	if (!native_read_msr_safe(MSR_IA32_MCG_STATUS, &value)) {
+	if (!rdmsrq_safe(MSR_IA32_MCG_STATUS, &value)) {
 		value &= ~(1ULL << 2);
-		native_write_msr_safe(MSR_IA32_MCG_STATUS, value);
+		wrmsrq_safe(MSR_IA32_MCG_STATUS, value);
 	}
 
 	/* Flush tlb to evict multi-match entries */
diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index 8f89ce0b67e3..d49a3bdc448b 100644
--- a/arch/x86/xen/pmu.c
+++ b/arch/x86/xen/pmu.c
@@ -323,7 +323,7 @@ static u64 xen_amd_read_pmc(int counter)
 		u64 val;
 
 		msr = amd_counters_base + (counter * amd_msr_step);
-		native_read_msr_safe(msr, &val);
+		rdmsrq_safe(msr, &val);
 		return val;
 	}
 
@@ -349,7 +349,7 @@ static u64 xen_intel_read_pmc(int counter)
 		else
 			msr = MSR_IA32_PERFCTR0 + counter;
 
-		native_read_msr_safe(msr, &val);
+		rdmsrq_safe(msr, &val);
 		return val;
 	}
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 09:20:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 09:20:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976930.1364042 (Exim 4.92)
	(envelope-from )
	id 1uCETw-0003K0-Nj; Tue, 06 May 2025 09:20:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976930.1364042; Tue, 06 May 2025 09:20:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCETw-0003J3-L7; Tue, 06 May 2025 09:20:56 +0000
Received: by outflank-mailman (input) for mailman id 976930;
 Tue, 06 May 2025 09:20:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uCETu-0002Tc-ST
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 09:20:54 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6860900b-2a5b-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 11:20:53 +0200 (CEST)
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 B8A1D21270;
 Tue,  6 May 2025 09:20:52 +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 473CC137CF;
 Tue,  6 May 2025 09:20: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 ohjMD3TUGWgwbAAAD6G6ig
 (envelope-from ); Tue, 06 May 2025 09:20: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" 
X-Inumbo-ID: 6860900b-2a5b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1746523252; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=gPlVcBnM9+OR95b5HV2hq0XADQ62f4TXKXOpPPlrJtg=;
	b=Qcv5A5+jJolUiYSL/xbYaKM+tOzQd2BWTuMC5vBF+z3e2BZ5SLmxUbej2VdyV00bfdPfq8
	DQbE20nPcxjIRw1Rcmaps6PZZYAH6DU/CtA/Dity53R6g6xD6JeYrH0qZOitbGgOjNBlC/
	x1eP+a5DMiPp9kuSpDjGSCFiA4VRbdE=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1746523252; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=gPlVcBnM9+OR95b5HV2hq0XADQ62f4TXKXOpPPlrJtg=;
	b=Qcv5A5+jJolUiYSL/xbYaKM+tOzQd2BWTuMC5vBF+z3e2BZ5SLmxUbej2VdyV00bfdPfq8
	DQbE20nPcxjIRw1Rcmaps6PZZYAH6DU/CtA/Dity53R6g6xD6JeYrH0qZOitbGgOjNBlC/
	x1eP+a5DMiPp9kuSpDjGSCFiA4VRbdE=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev
Cc: xin@zytor.com,
	Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Broadcom internal kernel review list ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to instruction interfaces
Date: Tue,  6 May 2025 11:20:14 +0200
Message-ID: <20250506092015.1849-6-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250506092015.1849-1-jgross@suse.com>
References: <20250506092015.1849-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWELVE(0.00)[15];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo]
X-Spam-Score: -6.80
X-Spam-Flag: NO

Instead of having callback functions for rdmsr/wrmsr on native, switch
to inline the respective instructions directly in order to avoid
overhead with the call interface.

This requires to use the instruction interfaces for rdmsr/wrmsr
emulation when running as a Xen PV guest.

In order to prepare support for the immediate forms of RDMSR and WRMSR
when not running as a Xen PV guest, use the RDMSR and WRMSR
instructions as the fallback case instead of ALT_CALL_INSTR.

Note that in the Xen PV case the RDMSR/WRMSR patching must not happen
even as an intermediate step, as this would clobber the indirect call
information needed when patching in the direct call for the Xen case.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/paravirt.h           | 114 +++++++++++++++++-----
 arch/x86/include/asm/paravirt_types.h     |  13 ++-
 arch/x86/include/asm/qspinlock_paravirt.h |   5 +-
 arch/x86/kernel/paravirt.c                |  26 ++++-
 arch/x86/xen/enlighten_pv.c               |  56 ++++++++---
 5 files changed, 167 insertions(+), 47 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index a463c747c780..df10b0e4f7b8 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -175,24 +175,72 @@ static inline void __write_cr4(unsigned long x)
 	PVOP_VCALL1(cpu.write_cr4, x);
 }
 
-static inline u64 paravirt_read_msr(u32 msr)
+static __always_inline u64 paravirt_read_msr(u32 msr)
 {
-	return PVOP_CALL1(u64, cpu.read_msr, msr);
+	EAX_EDX_DECLARE_ARGS(val, low, high);
+
+	PVOP_TEST_NULL(cpu.read_msr);
+	asm volatile("1: "ALTERNATIVE_2(PARAVIRT_CALL,
+					"rdmsr", ALT_NOT_XEN,
+					ALT_CALL_INSTR, ALT_XENPV_CALL)
+		     "2:\n"
+		     _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_RDMSR)
+		     : EAX_EDX_RET(val, low, high), ASM_CALL_CONSTRAINT
+		     : paravirt_ptr(cpu.read_msr), "c" (msr));
+
+	return EAX_EDX_VAL(val, low, high);
 }
 
-static inline void paravirt_write_msr(u32 msr, u64 val)
+static __always_inline void paravirt_write_msr(u32 msr, u64 val)
 {
-	PVOP_VCALL2(cpu.write_msr, msr, val);
+	PVOP_TEST_NULL(cpu.write_msr);
+	asm volatile("1: "ALTERNATIVE_2(PARAVIRT_CALL,
+					"wrmsr", ALT_NOT_XEN,
+					ALT_CALL_INSTR, ALT_XENPV_CALL)
+		      "2:\n"
+		      _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_WRMSR)
+		      : ASM_CALL_CONSTRAINT
+		      : paravirt_ptr(cpu.write_msr),
+			  "c" (msr), "a" ((u32)val), "d" ((u32)(val >> 32))
+		      : "memory");
 }
 
-static inline int paravirt_read_msr_safe(u32 msr, u64 *val)
+static __always_inline int paravirt_read_msr_safe(u32 msr, u64 *p)
 {
-	return PVOP_CALL2(int, cpu.read_msr_safe, msr, val);
+	int err;
+	EAX_EDX_DECLARE_ARGS(val, low, high);
+
+	PVOP_TEST_NULL(cpu.read_msr_safe);
+	asm volatile("1: "ALTERNATIVE_2(PARAVIRT_CALL,
+					"rdmsr; xor %[err],%[err]", ALT_NOT_XEN,
+					ALT_CALL_INSTR, ALT_XENPV_CALL)
+		     "2:\n"
+		     _ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_RDMSR_SAFE, %[err])
+		     : [err] "=c" (err), EAX_EDX_RET(val, low, high),
+		       ASM_CALL_CONSTRAINT
+		     : paravirt_ptr(cpu.read_msr_safe), "0" (msr));
+
+	*p = EAX_EDX_VAL(val, low, high);
+
+	return err;
 }
 
-static inline int paravirt_write_msr_safe(u32 msr, u64 val)
+static __always_inline int paravirt_write_msr_safe(u32 msr, u64 val)
 {
-	return PVOP_CALL2(int, cpu.write_msr_safe, msr, val);
+	int err;
+
+	PVOP_TEST_NULL(cpu.write_msr_safe);
+	asm volatile("1: "ALTERNATIVE_2(PARAVIRT_CALL,
+					"wrmsr; xor %[err],%[err]", ALT_NOT_XEN,
+					ALT_CALL_INSTR, ALT_XENPV_CALL)
+		     "2:\n"
+		     _ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_WRMSR_SAFE, %[err])
+		     : [err] "=a" (err), ASM_CALL_CONSTRAINT
+		     : paravirt_ptr(cpu.write_msr_safe),
+		       "c" (msr), "0" ((u32)val), "d" ((u32)(val >> 32))
+		     : "memory");
+
+	return err;
 }
 
 static __always_inline u64 read_msr(u32 msr)
@@ -573,27 +621,43 @@ bool __raw_callee_save___native_vcpu_is_preempted(long cpu);
 #define PV_SAVE_ALL_CALLER_REGS		"pushl %ecx;"
 #define PV_RESTORE_ALL_CALLER_REGS	"popl  %ecx;"
 #else
+/* save and restore caller-save registers, except %rax, %rcx and %rdx. */
+#define PV_SAVE_COMMON_CALLER_REGS	\
+	"push %rsi;"			\
+	"push %rdi;"			\
+	"push %r8;"			\
+	"push %r9;"			\
+	"push %r10;"			\
+	"push %r11;"
+#define PV_RESTORE_COMMON_CALLER_REGS	\
+	"pop %r11;"			\
+	"pop %r10;"			\
+	"pop %r9;"			\
+	"pop %r8;"			\
+	"pop %rdi;"			\
+	"pop %rsi;"
+
+#define PV_PROLOGUE_MSR(func)		\
+	PV_SAVE_COMMON_CALLER_REGS	\
+	PV_PROLOGUE_MSR_##func
+#define PV_EPILOGUE_MSR(func)		\
+	PV_EPILOGUE_MSR_##func		\
+	PV_RESTORE_COMMON_CALLER_REGS
+
 /* save and restore all caller-save registers, except return value */
 #define PV_SAVE_ALL_CALLER_REGS						\
 	"push %rcx;"							\
 	"push %rdx;"							\
-	"push %rsi;"							\
-	"push %rdi;"							\
-	"push %r8;"							\
-	"push %r9;"							\
-	"push %r10;"							\
-	"push %r11;"
+	PV_SAVE_COMMON_CALLER_REGS
 #define PV_RESTORE_ALL_CALLER_REGS					\
-	"pop %r11;"							\
-	"pop %r10;"							\
-	"pop %r9;"							\
-	"pop %r8;"							\
-	"pop %rdi;"							\
-	"pop %rsi;"							\
+	PV_RESTORE_COMMON_CALLER_REGS					\
 	"pop %rdx;"							\
 	"pop %rcx;"
 #endif
 
+#define PV_PROLOGUE_ALL(func)	PV_SAVE_ALL_CALLER_REGS
+#define PV_EPILOGUE_ALL(func)	PV_RESTORE_ALL_CALLER_REGS
+
 /*
  * Generate a thunk around a function which saves all caller-save
  * registers except for the return value.  This allows C functions to
@@ -607,7 +671,7 @@ bool __raw_callee_save___native_vcpu_is_preempted(long cpu);
  * functions.
  */
 #define PV_THUNK_NAME(func) "__raw_callee_save_" #func
-#define __PV_CALLEE_SAVE_REGS_THUNK(func, section)			\
+#define __PV_CALLEE_SAVE_REGS_THUNK(func, section, helper)		\
 	extern typeof(func) __raw_callee_save_##func;			\
 									\
 	asm(".pushsection " section ", \"ax\";"				\
@@ -617,16 +681,18 @@ bool __raw_callee_save___native_vcpu_is_preempted(long cpu);
 	    PV_THUNK_NAME(func) ":"					\
 	    ASM_ENDBR							\
 	    FRAME_BEGIN							\
-	    PV_SAVE_ALL_CALLER_REGS					\
+	    PV_PROLOGUE_##helper(func)					\
 	    "call " #func ";"						\
-	    PV_RESTORE_ALL_CALLER_REGS					\
+	    PV_EPILOGUE_##helper(func)					\
 	    FRAME_END							\
 	    ASM_RET							\
 	    ".size " PV_THUNK_NAME(func) ", .-" PV_THUNK_NAME(func) ";"	\
 	    ".popsection")
 
 #define PV_CALLEE_SAVE_REGS_THUNK(func)			\
-	__PV_CALLEE_SAVE_REGS_THUNK(func, ".text")
+	__PV_CALLEE_SAVE_REGS_THUNK(func, ".text", ALL)
+#define PV_CALLEE_SAVE_REGS_MSR_THUNK(func)		\
+	__PV_CALLEE_SAVE_REGS_THUNK(func, ".text", MSR)
 
 /* Get a reference to a callee-save function */
 #define PV_CALLEE_SAVE(func)						\
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index b08b9d3122d6..f7f879319e90 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -91,15 +91,15 @@ struct pv_cpu_ops {
 		      unsigned int *ecx, unsigned int *edx);
 
 	/* Unsafe MSR operations.  These will warn or panic on failure. */
-	u64 (*read_msr)(u32 msr);
-	void (*write_msr)(u32 msr, u64 val);
+	struct paravirt_callee_save read_msr;
+	struct paravirt_callee_save write_msr;
 
 	/*
 	 * Safe MSR operations.
 	 * Returns 0 or -EIO.
 	 */
-	int (*read_msr_safe)(u32 msr, u64 *val);
-	int (*write_msr_safe)(u32 msr, u64 val);
+	struct paravirt_callee_save read_msr_safe;
+	struct paravirt_callee_save write_msr_safe;
 
 	u64 (*read_pmc)(int counter);
 
@@ -520,6 +520,10 @@ unsigned long pv_native_save_fl(void);
 void pv_native_irq_disable(void);
 void pv_native_irq_enable(void);
 unsigned long pv_native_read_cr2(void);
+void pv_native_rdmsr(void);
+void pv_native_wrmsr(void);
+void pv_native_rdmsr_safe(void);
+void pv_native_wrmsr_safe(void);
 #endif
 
 #define paravirt_nop	((void *)nop_func)
@@ -527,6 +531,7 @@ unsigned long pv_native_read_cr2(void);
 #endif	/* __ASSEMBLER__ */
 
 #define ALT_NOT_XEN	ALT_NOT(X86_FEATURE_XENPV)
+#define ALT_XENPV_CALL	ALT_DIRECT_CALL(X86_FEATURE_XENPV)
 
 #endif  /* CONFIG_PARAVIRT */
 #endif	/* _ASM_X86_PARAVIRT_TYPES_H */
diff --git a/arch/x86/include/asm/qspinlock_paravirt.h b/arch/x86/include/asm/qspinlock_paravirt.h
index 0a985784be9b..0351acb5a143 100644
--- a/arch/x86/include/asm/qspinlock_paravirt.h
+++ b/arch/x86/include/asm/qspinlock_paravirt.h
@@ -14,7 +14,8 @@ void __lockfunc __pv_queued_spin_unlock_slowpath(struct qspinlock *lock, u8 lock
  */
 #ifdef CONFIG_64BIT
 
-__PV_CALLEE_SAVE_REGS_THUNK(__pv_queued_spin_unlock_slowpath, ".spinlock.text");
+__PV_CALLEE_SAVE_REGS_THUNK(__pv_queued_spin_unlock_slowpath, ".spinlock.text",
+			    ALL);
 #define __pv_queued_spin_unlock	__pv_queued_spin_unlock
 
 /*
@@ -61,7 +62,7 @@ DEFINE_ASM_FUNC(__raw_callee_save___pv_queued_spin_unlock,
 #else /* CONFIG_64BIT */
 
 extern void __lockfunc __pv_queued_spin_unlock(struct qspinlock *lock);
-__PV_CALLEE_SAVE_REGS_THUNK(__pv_queued_spin_unlock, ".spinlock.text");
+__PV_CALLEE_SAVE_REGS_THUNK(__pv_queued_spin_unlock, ".spinlock.text", ALL);
 
 #endif /* CONFIG_64BIT */
 #endif
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 015bf298434f..ff7d7fdae360 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -50,6 +50,24 @@ DEFINE_ASM_FUNC(pv_native_save_fl, "pushf; pop %rax", .noinstr.text);
 DEFINE_ASM_FUNC(pv_native_irq_disable, "cli", .noinstr.text);
 DEFINE_ASM_FUNC(pv_native_irq_enable, "sti", .noinstr.text);
 DEFINE_ASM_FUNC(pv_native_read_cr2, "mov %cr2, %rax", .noinstr.text);
+DEFINE_ASM_FUNC(pv_native_rdmsr,
+		"1: rdmsr\n"
+		"2:\n"
+		_ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_RDMSR), .noinstr.text);
+DEFINE_ASM_FUNC(pv_native_wrmsr,
+		"1: wrmsr\n"
+		"2:\n"
+		_ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_WRMSR), .noinstr.text);
+DEFINE_ASM_FUNC(pv_native_rdmsr_safe,
+		"1: rdmsr; xor %ecx, %ecx\n"
+		"2:\n"
+		_ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_RDMSR_SAFE, %%ecx),
+		.noinstr.text);
+DEFINE_ASM_FUNC(pv_native_wrmsr_safe,
+		"1: wrmsr; xor %eax, %eax\n"
+		"2:\n"
+		_ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_WRMSR_SAFE, %%eax),
+		.noinstr.text);
 #endif
 
 DEFINE_STATIC_KEY_FALSE(virt_spin_lock_key);
@@ -129,10 +147,10 @@ struct paravirt_patch_template pv_ops = {
 	.cpu.read_cr0		= native_read_cr0,
 	.cpu.write_cr0		= native_write_cr0,
 	.cpu.write_cr4		= native_write_cr4,
-	.cpu.read_msr		= native_read_msr,
-	.cpu.write_msr		= native_write_msr,
-	.cpu.read_msr_safe	= native_read_msr_safe,
-	.cpu.write_msr_safe	= native_write_msr_safe,
+	.cpu.read_msr		= __PV_IS_CALLEE_SAVE(pv_native_rdmsr),
+	.cpu.write_msr		= __PV_IS_CALLEE_SAVE(pv_native_wrmsr),
+	.cpu.read_msr_safe	= __PV_IS_CALLEE_SAVE(pv_native_rdmsr_safe),
+	.cpu.write_msr_safe	= __PV_IS_CALLEE_SAVE(pv_native_wrmsr_safe),
 	.cpu.read_pmc		= native_read_pmc,
 	.cpu.load_tr_desc	= native_load_tr_desc,
 	.cpu.set_ldt		= native_set_ldt,
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 3be38350f044..c279b2bef7eb 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1160,36 +1160,66 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err)
 	}
 }
 
-static int xen_read_msr_safe(u32 msr, u64 *val)
-{
+/*
+ * Prototypes for functions called via PV_CALLEE_SAVE_REGS_THUNK() in order
+ * to avoid warnings with "-Wmissing-prototypes".
+ */
+struct xen_rdmsr_safe_ret {
+	u64 val;
 	int err;
+};
+struct xen_rdmsr_safe_ret xen_read_msr_safe(u32 msr);
+int xen_write_msr_safe(u32 msr, u32 low, u32 high);
+u64 xen_read_msr(u32 msr);
+void xen_write_msr(u32 msr, u32 low, u32 high);
 
-	*val = xen_do_read_msr(msr, &err);
-	return err;
+__visible struct xen_rdmsr_safe_ret xen_read_msr_safe(u32 msr)
+{
+	struct xen_rdmsr_safe_ret ret;
+
+	ret.val = xen_do_read_msr(msr, &ret.err);
+	return ret;
 }
+#define PV_PROLOGUE_MSR_xen_read_msr_safe	"mov %ecx, %edi;"
+#define PV_EPILOGUE_MSR_xen_read_msr_safe	\
+	"mov %edx, %ecx; mov %rax, %rdx; mov %eax, %eax; shr $0x20, %rdx;"
+PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_read_msr_safe);
 
-static int xen_write_msr_safe(u32 msr, u64 val)
+__visible int xen_write_msr_safe(u32 msr, u32 low, u32 high)
 {
 	int err = 0;
 
-	xen_do_write_msr(msr, val, &err);
+	xen_do_write_msr(msr, (u64)high << 32 | low, &err);
 
 	return err;
 }
+#define PV_PROLOGUE_MSR_xen_write_msr_safe	\
+	"mov %ecx, %edi; mov %eax, %esi;"
+#define PV_EPILOGUE_MSR_xen_write_msr_safe
+PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_write_msr_safe);
 
-static u64 xen_read_msr(u32 msr)
+__visible u64 xen_read_msr(u32 msr)
 {
 	int err;
 
 	return xen_do_read_msr(msr, xen_msr_safe ? &err : NULL);
 }
+#define PV_PROLOGUE_MSR_xen_read_msr	"mov %ecx, %edi;"
+#define PV_EPILOGUE_MSR_xen_read_msr	\
+	"mov %rax, %rdx; mov %eax, %eax; shr $0x20, %rdx;"
+PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_read_msr);
 
-static void xen_write_msr(u32 msr, u64 val)
+__visible void xen_write_msr(u32 msr, u32 low, u32 high)
 {
 	int err;
 
-	xen_do_write_msr(msr, val, xen_msr_safe ? &err : NULL);
+	xen_do_write_msr(msr, (u64)high << 32 | low,
+			 xen_msr_safe ? &err : NULL);
 }
+#define PV_PROLOGUE_MSR_xen_write_msr	\
+	"mov %ecx, %edi; mov %eax, %esi;"
+#define PV_EPILOGUE_MSR_xen_write_msr
+PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_write_msr);
 
 /* This is called once we have the cpu_possible_mask */
 void __init xen_setup_vcpu_info_placement(void)
@@ -1225,11 +1255,11 @@ static const typeof(pv_ops) xen_cpu_ops __initconst = {
 
 		.write_cr4 = xen_write_cr4,
 
-		.read_msr = xen_read_msr,
-		.write_msr = xen_write_msr,
+		.read_msr = PV_CALLEE_SAVE(xen_read_msr),
+		.write_msr = PV_CALLEE_SAVE(xen_write_msr),
 
-		.read_msr_safe = xen_read_msr_safe,
-		.write_msr_safe = xen_write_msr_safe,
+		.read_msr_safe = PV_CALLEE_SAVE(xen_read_msr_safe),
+		.write_msr_safe = PV_CALLEE_SAVE(xen_write_msr_safe),
 
 		.read_pmc = xen_read_pmc,
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 09:21:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 09:21:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976933.1364053 (Exim 4.92)
	(envelope-from )
	id 1uCEU0-0003dO-45; Tue, 06 May 2025 09:21:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976933.1364053; Tue, 06 May 2025 09:21: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 1uCEU0-0003dF-19; Tue, 06 May 2025 09:21:00 +0000
Received: by outflank-mailman (input) for mailman id 976933;
 Tue, 06 May 2025 09:20:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uCETz-0002lJ-BN
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 09:20:59 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6bbe9464-2a5b-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 11:20:58 +0200 (CEST)
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 76F8D21222;
 Tue,  6 May 2025 09:20:58 +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 2534F137CF;
 Tue,  6 May 2025 09:20:58 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id Uz6qB3rUGWg4bAAAD6G6ig
 (envelope-from ); Tue, 06 May 2025 09:20: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" 
X-Inumbo-ID: 6bbe9464-2a5b-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1746523258; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3vZ2K2J1ln19F+coajEe0NOzYd5qTlnxqf025hGnVDU=;
	b=KN5RYi3WKDf5r3VtKmNI3YmBwUzGzvePRrlML95vi4X0xhN9peoD1MOJLbxp5vLh1HRu0k
	Q+egWSynCrSzt014lYfd2E9PqTjhVD4ppQzcklbbLLGV3D6E8ObFKQGmNx5Nr1Hz9Sfs/q
	yITmmMV6OT/18+CQ/ixpOIu6S8aXeY8=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1746523258; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3vZ2K2J1ln19F+coajEe0NOzYd5qTlnxqf025hGnVDU=;
	b=KN5RYi3WKDf5r3VtKmNI3YmBwUzGzvePRrlML95vi4X0xhN9peoD1MOJLbxp5vLh1HRu0k
	Q+egWSynCrSzt014lYfd2E9PqTjhVD4ppQzcklbbLLGV3D6E8ObFKQGmNx5Nr1Hz9Sfs/q
	yITmmMV6OT/18+CQ/ixpOIu6S8aXeY8=
From: Juergen Gross 
To: linux-kernel@vger.kernel.org,
	x86@kernel.org
Cc: xin@zytor.com,
	Juergen Gross ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 6/6] x86/msr: reduce number of low level MSR access helpers
Date: Tue,  6 May 2025 11:20:15 +0200
Message-ID: <20250506092015.1849-7-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250506092015.1849-1-jgross@suse.com>
References: <20250506092015.1849-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -6.80
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[11];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

Some MSR access helpers are redundant now, so remove the no longer
needed ones.

At the same time make the native_*_msr_safe() helpers always inline.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/msr.h  | 20 ++++----------------
 arch/x86/xen/enlighten_pv.c |  4 ++--
 2 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 3a94cffb6a3e..0e2ed1604015 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -101,12 +101,7 @@ static __always_inline u64 native_rdmsrq(u32 msr)
 #define native_wrmsrq(msr, val)				\
 	__wrmsrq((msr), (val))
 
-static inline u64 native_read_msr(u32 msr)
-{
-	return __rdmsr(msr);
-}
-
-static inline int native_read_msr_safe(u32 msr, u64 *p)
+static __always_inline int native_read_msr_safe(u32 msr, u64 *p)
 {
 	int err;
 	EAX_EDX_DECLARE_ARGS(val, low, high);
@@ -122,14 +117,7 @@ static inline int native_read_msr_safe(u32 msr, u64 *p)
 	return err;
 }
 
-/* Can be uninlined because referenced by paravirt */
-static inline void notrace native_write_msr(u32 msr, u64 val)
-{
-	native_wrmsrq(msr, val);
-}
-
-/* Can be uninlined because referenced by paravirt */
-static inline int notrace native_write_msr_safe(u32 msr, u64 val)
+static __always_inline int notrace native_write_msr_safe(u32 msr, u64 val)
 {
 	int err;
 
@@ -161,7 +149,7 @@ static inline u64 native_read_pmc(int counter)
 #include 
 static __always_inline u64 read_msr(u32 msr)
 {
-	return native_read_msr(msr);
+	return native_rdmsrq(msr);
 }
 
 static __always_inline int read_msr_safe(u32 msr, u64 *p)
@@ -171,7 +159,7 @@ static __always_inline int read_msr_safe(u32 msr, u64 *p)
 
 static __always_inline void write_msr(u32 msr, u64 val)
 {
-	native_write_msr(msr, val);
+	native_wrmsrq(msr, val);
 }
 
 static __always_inline int write_msr_safe(u32 msr, u64 val)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index c279b2bef7eb..ea3d7d583254 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1097,7 +1097,7 @@ static u64 xen_do_read_msr(u32 msr, int *err)
 	if (err)
 		*err = native_read_msr_safe(msr, &val);
 	else
-		val = native_read_msr(msr);
+		val = native_rdmsrq(msr);
 
 	switch (msr) {
 	case MSR_IA32_APICBASE:
@@ -1156,7 +1156,7 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err)
 		if (err)
 			*err = native_write_msr_safe(msr, val);
 		else
-			native_write_msr(msr, val);
+			native_wrmsrq(msr, val);
 	}
 }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 09:32:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 09:32:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976970.1364062 (Exim 4.92)
	(envelope-from )
	id 1uCEfU-0006eg-5Z; Tue, 06 May 2025 09:32:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976970.1364062; Tue, 06 May 2025 09:32: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 1uCEfU-0006eZ-37; Tue, 06 May 2025 09:32:52 +0000
Received: by outflank-mailman (input) for mailman id 976970;
 Tue, 06 May 2025 09:32:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCEfS-0006eT-JX
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 09:32:50 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0e1092d8-2a5d-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 11:32:40 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-acbb85ce788so10250966b.3
 for ; Tue, 06 May 2025 02:32:40 -0700 (PDT)
Received: from smtpclient.apple ([46.149.103.8])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1895402c7sm662621366b.164.2025.05.06.02.32.39
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 06 May 2025 02:32: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" 
X-Inumbo-ID: 0e1092d8-2a5d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746523960; x=1747128760; darn=lists.xenproject.org;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jvp3MsKGEBlhGL6z+rmvd9Ulc40wGOqRLMcLeinzkDs=;
        b=AuZxH0dyy0Ar+Mu+kz+CS77qPZCi7rSBhK63mh2HDkriFG6lJpt67lQks25PePpylz
         K3mFcLIxqlIsS/XHaOeX4MI7SlV7ku1p6qanHMtIyfl/yMoCsZrv2VOBouYQN6nf8+ru
         mrgAGRN8PzaEpDXYHsbl0FwXZkX9NpGPmmmys=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746523960; x=1747128760;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jvp3MsKGEBlhGL6z+rmvd9Ulc40wGOqRLMcLeinzkDs=;
        b=uByIs7t6KZprBrwIy5y8abY7r94KGxDKaz27Sai+EXVtSJoee0OrwKNnJr297rXQsk
         PQG0ay/YQSt7u5JDcaqODz+w89nJr1K6aOvwmH1s1U4ooRdYnupSjzHRLP4I+fej4q/l
         dSiE2xlrdI1wU8R+uwhw2+DSay8sMv6++FCofjUzCPPRsa4KX1m9GxRO7rwOhMGmL6T7
         50VLdwf9Wi0cK4cqZWG+mUnVmOemAaNdXqJkqXzW489ZnG2DnfNvNl2ss7lufOJ4LGP4
         nYTwRm8BnmwwV+RCLYzjf7ZpudTDna6754b7WR6HYgGPeA+wqAFuZTYINOY9FYFiXJ+j
         jz4Q==
X-Gm-Message-State: AOJu0YwdEnctdl7+ygdYvJ8JrdBx8+QaFW9Ct196R+IbbWyKlrNx8kRA
	Wr/Bh+hsLbXrYiky3mcNujBASMv4JMB346Pr7Mes1Ks8GJiZWCP+NOXdmchTeDI=
X-Gm-Gg: ASbGncv1nbZLOz1JgOI7TLht9ZLh4GmRBaZOI+ktosiscJwa21qN6iWNUmoEF1iTNhR
	gUbFMpdji7/2M6oYMlmWwAbyjhJXA0TaaLWV+4zGmye30ZwIT+L7NpDpLaKS5jQLpoAwtce8rC2
	ReXkNyy34h/xGhPAMRpD80HZYufH3e21lwEmPmuDeo3x3OumQ03SAMV03WOUvq8BhQPVFOMnrPV
	QgsndJNGSJhqTsB4aVdMCbEAJnM1uzI/cCI2xTrywGzX7pbKckjGwXSYwRw0lo6fbHJLkz82VlJ
	MFNAs0+HHnNyJm2eLU2zSwRyG18Np3GtT+ih0cedxjd0f4Of/JsIhsKIFxJfxuBg6TFqWw==
X-Google-Smtp-Source: AGHT+IG3RVyMSlhTv05uiwA4OlXm0wrxoot/dtnfagAG6hyCYP+4Un9BzgMoJ+9zWwsKv7sMcDAZDQ==
X-Received: by 2002:a17:907:c01a:b0:ac7:66fb:6a07 with SMTP id a640c23a62f3a-ad1d44fb59emr213921566b.6.1746523959941;
        Tue, 06 May 2025 02:32:39 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: [PATCH 0/8] xen: cache control improvements
From: Christian Lindig 
In-Reply-To: <20250506083148.34963-1-roger.pau@citrix.com>
Date: Tue, 6 May 2025 10:32:28 +0100
Cc: xen-devel@lists.xenproject.org,
 Jan Beulich ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel ,
 Julien Grall ,
 Stefano Stabellini ,
 Juergen Gross ,
 David Scott ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Edwin Torok 
Content-Transfer-Encoding: quoted-printable
Message-Id: <491870F7-DE91-46E6-AB96-A9A3478EA362@cloud.com>
References: <20250506083148.34963-1-roger.pau@citrix.com>
To: Roger Pau Monne 
X-Mailer: Apple Mail (2.3826.500.181.1.5)

This looks fine from an OCaml perspective, which is my focus. I didn't =
review the logical aspect of this.

=E2=80=94 Christian

Acked-by: Christian Lindig 


> On 6 May 2025, at 09:31, Roger Pau Monne  wrote:
>=20
> Hello,
>=20
> Following series contain some fixes for cache control operations, the
> main focus is to reduce the load on big systems when cache control
> operations are executed.
>=20
> Patches 1-4 are bugfixes, while patches starting from 5 are =
improvements
> to the current code.  Patch 9 is an optimization to avoid having to
> broadcast cache flushes on all pCPUs on x86.
>=20
> Thanks, Roger.
>=20
> Roger Pau Monne (9):
>  x86/pv: fix MMUEXT_FLUSH_CACHE to flush all pCPU caches
>  x86/pv: fix emulation of wb{,no}invd to flush all pCPU caches
>  xen/gnttab: limit cache flush operation to guests allowed cache
>    control
>  x86/gnttab: do not implement GNTTABOP_cache_flush
>  x86/mtrr: use memory_type_changed() in hvm_set_mem_pinned_cacheattr()
>  x86/p2m: limit cache flush in memory_type_changed()
>  xen/x86: rename cache_flush_permitted() to has_arch_io_resources()
>  xen: introduce flag when a domain requires cache control
>  xen/x86: track dirty pCPU caches for a given vCPU
>=20
> docs/man/xl.cfg.5.pod.in            | 10 +++++++
> tools/include/libxl.h               |  7 +++++
> tools/libs/light/libxl_create.c     |  6 ++++
> tools/libs/light/libxl_types.idl    |  3 ++
> tools/ocaml/libs/xc/xenctrl.ml      |  1 +
> tools/ocaml/libs/xc/xenctrl.mli     |  1 +
> tools/xl/xl_parse.c                 |  2 ++
> xen/arch/arm/dom0less-build.c       | 12 ++++++--
> xen/arch/arm/domain.c               |  3 +-
> xen/arch/arm/domain_build.c         |  6 ++++
> xen/arch/x86/domain.c               | 43 +++++++++++++++++++++++++++++
> xen/arch/x86/hvm/hvm.c              |  2 +-
> xen/arch/x86/hvm/mtrr.c             | 29 ++++---------------
> xen/arch/x86/hvm/svm/svm.c          |  6 ++--
> xen/arch/x86/hvm/vmx/vmcs.c         |  3 +-
> xen/arch/x86/hvm/vmx/vmx.c          |  6 ++--
> xen/arch/x86/include/asm/domain.h   |  9 ++++++
> xen/arch/x86/include/asm/flushtlb.h | 15 ----------
> xen/arch/x86/include/asm/iocap.h    | 19 ++-----------
> xen/arch/x86/include/asm/p2m.h      |  2 +-
> xen/arch/x86/mm.c                   | 21 ++++----------
> xen/arch/x86/mm/p2m-ept.c           |  7 +----
> xen/arch/x86/mm/p2m-pod.c           |  4 +--
> xen/arch/x86/mm/p2m.c               | 13 ++++++++-
> xen/arch/x86/pv/emul-priv-op.c      | 19 ++++++-------
> xen/arch/x86/setup.c                |  7 +++++
> xen/common/domain.c                 |  3 +-
> xen/common/grant_table.c            | 11 ++++++++
> xen/common/memory.c                 |  2 +-
> xen/include/asm-generic/iocap.h     |  2 +-
> xen/include/public/domctl.h         |  4 ++-
> xen/include/xen/iocap.h             | 25 ++---------------
> xen/include/xen/sched.h             |  6 ++++
> 33 files changed, 181 insertions(+), 128 deletions(-)
>=20
> --=20
> 2.48.1
>=20



From xen-devel-bounces@lists.xenproject.org Tue May 06 09:56:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 09:56:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976981.1364072 (Exim 4.92)
	(envelope-from )
	id 1uCF2Q-0001kU-V8; Tue, 06 May 2025 09:56:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976981.1364072; Tue, 06 May 2025 09:56:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCF2Q-0001kN-SW; Tue, 06 May 2025 09:56:34 +0000
Received: by outflank-mailman (input) for mailman id 976981;
 Tue, 06 May 2025 09:56:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCF2P-0001kH-Pu
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 09:56:33 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2009::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 62182267-2a60-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 11:56:31 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 PH7PR12MB5733.namprd12.prod.outlook.com (2603:10b6:510:1e0::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Tue, 6 May
 2025 09:56:23 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 09: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" 
X-Inumbo-ID: 62182267-2a60-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vgcvY07ZggBUfXt6J9M9eiRrh6oEKdEmxfWcyxfGW4DThIPHXZCSH6nawrHYma1GbJKXfzLT0/j52x0c9IuFFs8R+GuIfy04XHvd7LkaXrlTLA5T4z8XnG3hWO/EgdksIXPjBAPcBJOh445BWIQSgA6KchehWENCYoq6FRfycZ67VL0nA0J0l8tc2p0dTsFQ6UidYhoprmnT6/SQQusLGOsX46FetWpEZ64RNecuqgM8pMHExYCCZa/O/CB05ODHskRwSYDWbdMPP45oFYhMgykvo3TWvHiq1OQ+h72JaYFZvfxVH2nGWmb5wRd+/FJU2tgsl0yP6kvwAUBqjvKKSA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7Fi5YFBTDWu0nQZVLY0j6+CDbFegIRkOkjS6nhye0l4=;
 b=m++KuVn9Khlf+XKGrap4hfMohQQPcOyRJM8o46cM6Szy+lUhK7SyWrTeSTnXbaU6As9k2WTXKRKMtARydSnZdyMkh/KJhRu4i2NfMsfZnLxS92HQtPaDx5dfRzUOW/o03Jmb+aeNoMgKwig85GCkszGReEN/Py5rSNPzw2x2X3nsVBxPkXYSBSxhrpTuWEMQJzag5k5FnK6MGovWZ2hJotHXPVTL9jfXWOYIJkJJt0SJae1T/GqJ6krSB6FtNPJlRSq8LCaThWqcV0b5gotd+zlf9lsPzhsNDvxOV0TblBE7aPW+obRD0Wcuz/4lJCQzBsGbEevXI4U3vTJM8I0/3g==
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=7Fi5YFBTDWu0nQZVLY0j6+CDbFegIRkOkjS6nhye0l4=;
 b=M90EnsYtFjJGfGJcPgnB7yOBJLe4Rt7cP596dGsikd0Q/HZBnWEmAfsrI4D3aAUuQEHkbNRpn5MSfHKQ2XNehc9Hnc4g292FF4uoVqPrftmIJWW9/HhoieTTohcX6Q6/x80enj+YhlBaFyropF1jvqBVdvDpKZur3hJLuupvI/0=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Anthony PERARD , "Orzel,
 Michal" , Julien Grall , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 03/15] xen/x86: introduce new sub-hypercall to
 propagate CPPC data
Thread-Topic: [PATCH v4 03/15] xen/x86: introduce new sub-hypercall to
 propagate CPPC data
Thread-Index: AQHbrRCmWPNHyarMuUaK4nZ2TXIaALO5UliAgAwsfxA=
Date: Tue, 6 May 2025 09:56:22 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-4-Penny.Zheng@amd.com>
 <2e1de23f-cc79-4d37-8667-0afd07736db3@suse.com>
In-Reply-To: <2e1de23f-cc79-4d37-8667-0afd07736db3@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=c756dc54-ffb3-4a2e-9c0a-fd4cc4d57b01;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-06T09:56:14Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|PH7PR12MB5733:EE_
x-ms-office365-filtering-correlation-id: 4d8edbba-4d3b-42f8-39bd-08dd8c844226
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?blRmWitEYzlwVjVnYVFqcndYdHY4YkI0SFhscmlNQ0JKdWtycXZMakZVRmd0?=
 =?utf-8?B?R0tucURxdFZkTkk4ZEJFdHc5dnZLSlljMnJvTitpQVN3d016eWVRK2NqbVhX?=
 =?utf-8?B?Y0dCOE5KbzYzcnRHV0p6YXoweitCekVXWXlyU3JMc2Z3UGVIYUFWSWVqdWZD?=
 =?utf-8?B?OFNaYlY0NVZ6WkFRRU11NEQ3WDFFdS81aWNZSTNJNVZib3ZtR1d1NTVhdFpr?=
 =?utf-8?B?RjlMaTVnSjRNWE56MURCam1BdmdiQXRPNmtiWnEvcUMwbThUUmdqUTkvN01I?=
 =?utf-8?B?SlVaQm1VU01ZcE1zd3hBMkk0UTBUME56NWc1MTBJM0VwaVI3UXJHM3hxY3Y0?=
 =?utf-8?B?K2x5WXJVNTRYanl5ZDN2ZE9PWmY3czRyT0hqd1k3cFIxNFkyTlFmVWw2aWVv?=
 =?utf-8?B?T1gyU3RUWUdhUHRBOXkxZWd0SGJFTjB3TEJNL0lneGhST3ZyN2Z6aXdlUTJt?=
 =?utf-8?B?Mk9hU0sweG1JZ3dtb3NoSTNVUHRMeFFLUTlZRzJRWENLUkYyZnE5QWNaYWZP?=
 =?utf-8?B?OXZxRXB4S2dXNEdUSEVnN1RaMmRyWm91bUd3RjdhZlNhQTlydkg2UVNZcGRM?=
 =?utf-8?B?LzNDeEpick9HRzdiNmlDNzZVRnVQWDFGd1lWczV0TW05THliUWY4WjFCR01I?=
 =?utf-8?B?aTNNQVJFaG8xcTZ3c09Yc3BSK3F6b04rTzZLRjV6MEZIWW5BdXk0dGZCUzNH?=
 =?utf-8?B?NEZZT09qYXExNDVWQnFyeS85VHNHYWVaRHcwZGdZRUhxZlJjNVF0dWIxNmFN?=
 =?utf-8?B?RjZZY1AwS05wd0w4dCtIU2ZzZFJCVmUzeDdQck9LVGFuTHMzVTRIZGpOdDFS?=
 =?utf-8?B?NzlhQmpiS1QzUDlaNlBGVGhSTjhoSjhON2xQYityZ1c3UGRpZ2xYSUljaHhx?=
 =?utf-8?B?bTdPbXZHSno2MVl1dGhZTVVhTEtoVHFZeEdkcS9uTEY4WFkvS1VFUFo1cmt2?=
 =?utf-8?B?SVVFa2UrcjRxalNQTnU2czE2M0pMaFBUaFdRTVNDVFB4V2dOaWIzUkVmZEpo?=
 =?utf-8?B?d1hZYTU0L3F5S25kTmI0bnZ4UVltYmgrMHNtWW44eFdnakZ5S1hzSlYrRlph?=
 =?utf-8?B?bU8wMUdWTSt4RnBad1FZNXk5MGJGTHZRZUl0cmVCc3hIR0lQTmNsMSs3M1Ba?=
 =?utf-8?B?cWNLbktFUlJqaVNjcmphQXZiMUkyMjNLSlg4ZlBMT0M0TUtSUEU3dCtobmlm?=
 =?utf-8?B?T3FrcHBYK2NKSFpNS1l1bEdhODdEeFExUWh6QkI2SzV2dk81SzBpcTJJNmhu?=
 =?utf-8?B?U25UL2VDb0NDb3lROHB4YkxIM3N6UkpWNzRSUldmZFV2QmRtSjNQWHZQY1Fp?=
 =?utf-8?B?Q3hseXlQU3pQWXp0bXlYSGFXSHpwdVdMMTNabThGaGpLTWdnY3pKeCtQd2JT?=
 =?utf-8?B?aHljSGR5RzVVTVIvTVZEdkFOYlR5SEpnc1ZYZmJraWZrYXBOT0dwZDg1Mm9w?=
 =?utf-8?B?MkJ4SVpCQ0ppWEE4WmpHZS9jT1FoUEN4cVdHSjYrQ0pFZTN0YzBPKzcrdWMw?=
 =?utf-8?B?ZnRvVWRIbm9mc0FpeGtBOWppcHhveEFMY2FqNGhHKzdxdU9CckV3VkVPcktO?=
 =?utf-8?B?WmlYT1FpNjRWeWxlRGFhSDZ4cG01YTVDUk51eitvZWxzT2VabDgyRVU1cnpU?=
 =?utf-8?B?aGNVL0JiYzE0RzQ0UlVodTRYMmFDb1YwZ1RqMmhYVFZpdVlTZ1YrTE15MHYz?=
 =?utf-8?B?azN2ck5NeW82NFo5ekpmTThlcTFTbWNWK05DS05ON04wTnN0WVBWTmZWNC81?=
 =?utf-8?B?QnQxUmxJK2hoNzl5MEptVGRQcC9wZ09pQ0lFN0FzT2hvZ05CSTRGWG9IVzJz?=
 =?utf-8?B?V0JGQmw4N0VERU1mUk9MQXBVRlh6c0Z5RThacW51RGdMbmtuSnpEcHBzdE9p?=
 =?utf-8?B?Zit1aHpxcGVuN09iYXRwWU90bk1sZmhvbElmVDY2dHdjOVBENFdFdmVQZ2tY?=
 =?utf-8?B?UzdoekYwRGZURzNBdWJnQjBtcXIzYzJ1c0QzRnhPMVRhY0NHeVNlSnpxUk1R?=
 =?utf-8?Q?9hYvj+UDJclv42E/rRxWc7Nrkiv6QM=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?eUY1SENBck9qZjc5WlVPVDJJREQ2bVgyZzZCVC9DditLL1pML0pwV0pKSkVr?=
 =?utf-8?B?MitQdlV3NGpHRGlCTXBiUWEzT2NwQXdqUUxCMGNsUFZaRkMyTEdITE4xcXRU?=
 =?utf-8?B?ZlpDeHBnam9jb0lHU0sxS0llMHlBc0xoRlNJUXZ1SHY3d3pnQmFWVWFWT0tK?=
 =?utf-8?B?SHd2UktxMWFZN0ovWW5PRndsbEhkUU9LNDVHeGJrTlNnZGl3MUhLYW1uSU9P?=
 =?utf-8?B?ZE1ST1dYTnRnOEMzYXhJeG5HdGQrOE85TW5iTDNzTldPaWtROXoyN1NIRkdi?=
 =?utf-8?B?Ui9MK1E4bkJKWmtpYVQ0THgxYWh5dGZKV1RFSVVoSDY3NjVmVWs0Smdza093?=
 =?utf-8?B?MGdNcUpvalQ0WUcvaHZBeUxnNEtvOFlLVG96THJ4alVUMXBMWkZITm5QSWpF?=
 =?utf-8?B?SExxNUd0SlpTZ0Z5VE83U0VJekhJT2c3NTZIcy9GanJya0laNTRTdllKaFEx?=
 =?utf-8?B?WjVvRWNEOXZvTXBLbXJiaTg5L3pFRVE3ZEhWNk13Tjl5elJ3MGFoSWF3dG1l?=
 =?utf-8?B?UE1MdTd1UkFGbzdUWWxRR0ROcjFEejlqMkhuVzBwMW5jMDUzQmFPaDc0b2pT?=
 =?utf-8?B?MzVybDdpSHFHQkw1N0dLT0t2SWV3N1hxaHBXRFFzcUREYmhNZzczN2NmMGV4?=
 =?utf-8?B?d2hrZWxwbmRPNXZmQldic0Y2NHFTVXEwNHZrUWt4VEVFSkdlR3lrdVc5VWpH?=
 =?utf-8?B?dUxRdGUwS2tSTjhuaHA2UmFSS1J6bjhVR093ekRaVnRSUmRvSnd0bTZTL1BM?=
 =?utf-8?B?bkdJejNScGlPTlJncXhzS011ZzJsTlNWWEQvaFByUGZFMUJzU3hhM2MxMkZ5?=
 =?utf-8?B?WHJMQTRDMWNFS3NYQlpFZE93Z3ZGODJSTitzWSt5bGZTOW5kRGJCeU1CMjI3?=
 =?utf-8?B?WDhoaTFyRzVOM2pUZTlaazNyRkgyejY0VFNlWFhjYzUvSWtUa3B4RGxHd29F?=
 =?utf-8?B?cU1IWnZ2Nno5b2xuM1lsOEtZODZMWjFaZWNMN0YrSTNaUmtaQklINkdUODhh?=
 =?utf-8?B?VFgyQXIzUDVZckZtaWtpUDdTUC94R21mZ2VGVVN1dVJzUGZycXFROWtjeml5?=
 =?utf-8?B?UW1mWWlpOWdleWhxUUZ4WG5uK2xPc3UweldILzVVQkFEL2dEL21KcDhFOHpt?=
 =?utf-8?B?ZVJLcENxK1dsL2lIOWxobkpmdDg0Y2dLVGVNaGxDbkFlQlk3MC9Fa0NtRmVG?=
 =?utf-8?B?eHJ1ZUVjdmlNTk9TUXVEd0ZMWjJjNFRLV3ZqcmRPNEtrSTJRbWR2Z1Z3c0p1?=
 =?utf-8?B?MzhLT0ZEbWkwQ0N0ODRlMjJ1cEovMEVCYTRHQktnUEpsRjM0U1NXWFZYalJ3?=
 =?utf-8?B?OGFnbmdhQ0JTUk9CS3l4SjVMVnN2dEVqNUtISlhYci9vTXVONXViRGNQV245?=
 =?utf-8?B?Vm5jdTJyUDhUUE9TbDRmL2xQRU5JcGlOYzBqbzl0QmRXamlmSlRsdW5SSUhn?=
 =?utf-8?B?dzd2UDEwZDN1NDh2Y0hNTzlncmpBRzJTaXd4b0ZNUTNzNmFIck81SU00T0RT?=
 =?utf-8?B?NW1FK1hCNjBUYkF0NkhoZWhlVVorSUV0VTNEVDdKNHhpWVdLR3FDVWVhamIx?=
 =?utf-8?B?ZENDNm13RDIyT0tETUtGS09UVVRHSXJvRFE2VEtESTJUclcxOEdHOWlLUXRx?=
 =?utf-8?B?VFBzb295SVZtZVJiN2JUeHpzNUpCMjduS3hDOHk0Zm0xcklQbU5nbG54d1hQ?=
 =?utf-8?B?Tm5sVUdtclE2VGVHb2F2TTdiLzRSd0VRcUcycUEzbmJia0RXa0JTbkxBb2JB?=
 =?utf-8?B?YlNDcEUzbjhMK0RONzV6YTVIZzk5aGdYSFpLT1Mwd2tWTm9MWHNoTHR4M2Zz?=
 =?utf-8?B?MVZSSnRaYnBQVHRpYVhacjh0OFhGRUJYWms2YmZuWFpLZjB1cTR5Z0lvYksv?=
 =?utf-8?B?MTcxSnNJc3hQckRtL05iSGtFU0tMeVlad0dCZGJUYnN6Y2JxSGNPTXdLVkxW?=
 =?utf-8?B?Qmg1aFA0Um5tdi81bkZ3L29ISGdLRTVJdlB5b3FCRVVXNGpjK0JtcGFPaHJz?=
 =?utf-8?B?Zm9WWnpRMTlRdUdHcEQyVHk1T3Q2SVZXeGZVdm4zQUVYaHdBRmNnWlNSdGU1?=
 =?utf-8?B?SnZDaVh1Mnl2WVcxcklyWUN3UjJJRVhTaGNzV0hBNTRzYVMrNFNoL0FvNnV2?=
 =?utf-8?Q?MhIQ=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d8edbba-4d3b-42f8-39bd-08dd8c844226
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2025 09:56:22.9465
 (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: LnqBwga0v8pYuAVsutFk8SNFzOdSRyZb8f/g9JZj3qnmrsFBbYHeWD5iq50T4N9shuNW1zBLaufP1Vjrq87haA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5733

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBNb25kYXksIEFwcmlsIDI4
LCAyMDI1IDExOjU3IFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+
DQo+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4g
PGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVA
Y2l0cml4LmNvbT47DQo+IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEB2YXRlcy50ZWNo
PjsgT3J6ZWwsIE1pY2hhbA0KPiA8TWljaGFsLk9yemVsQGFtZC5jb20+OyBKdWxpZW4gR3JhbGwg
PGp1bGllbkB4ZW4ub3JnPjsgU3RlZmFubyBTdGFiZWxsaW5pDQo+IDxzc3RhYmVsbGluaUBrZXJu
ZWwub3JnPjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBb
UEFUQ0ggdjQgMDMvMTVdIHhlbi94ODY6IGludHJvZHVjZSBuZXcgc3ViLWh5cGVyY2FsbCB0byBw
cm9wYWdhdGUNCj4gQ1BQQyBkYXRhDQo+DQo+IE9uIDE0LjA0LjIwMjUgMDk6NDAsIFBlbm55IFpo
ZW5nIHdyb3RlOg0KPiA+IEBAIC00NTksNiArNDY0LDI2IEBAIHN0cnVjdCB4ZW5fcHJvY2Vzc29y
X3BlcmZvcm1hbmNlIHsgIHR5cGVkZWYNCj4gPiBzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9wZXJmb3Jt
YW5jZSB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlX3Q7DQo+ID4gREVGSU5FX1hFTl9HVUVTVF9I
QU5ETEUoeGVuX3Byb2Nlc3Nvcl9wZXJmb3JtYW5jZV90KTsNCj4gPg0KPiA+ICtzdHJ1Y3QgeGVu
X3Byb2Nlc3Nvcl9jcHBjIHsNCj4gPiArICAgIHVpbnQ4X3QgZmxhZ3M7IC8qIGZsYWcgZm9yIENQ
UEMgc3ViIGluZm8gdHlwZSAqLw0KPiA+ICsgICAgLyoNCj4gPiArICAgICAqIFN1YnNldCBfQ1BD
IGZpZWxkcyB1c2VmdWwgZm9yIENQUEMtY29tcGF0aWJsZSBjcHVmcmVxDQo+ID4gKyAgICAgKiBk
cml2ZXIncyBpbml0aWFsaXphdGlvbg0KPiA+ICsgICAgICovDQo+ID4gKyAgICBzdHJ1Y3Qgew0K
PiA+ICsgICAgICAgIHVpbnQzMl90IGhpZ2hlc3RfcGVyZjsNCj4gPiArICAgICAgICB1aW50MzJf
dCBub21pbmFsX3BlcmY7DQo+ID4gKyAgICAgICAgdWludDMyX3QgbG93ZXN0X25vbmxpbmVhcl9w
ZXJmOw0KPiA+ICsgICAgICAgIHVpbnQzMl90IGxvd2VzdF9wZXJmOw0KPiA+ICsgICAgICAgIHVp
bnQzMl90IGxvd2VzdF9taHo7DQo+ID4gKyAgICAgICAgdWludDMyX3Qgbm9taW5hbF9taHo7DQo+
ID4gKyAgICB9IGNwYzsNCj4gPiArICAgIHN0cnVjdCB4ZW5fcHNkX3BhY2thZ2UgZG9tYWluX2lu
Zm87IC8qIF9QU0QgKi8NCj4NCj4gVGhpcyBiZWluZyBhIG1lbWJlciBvZiB0aGUgbmV3IHR5cGUs
IC4uLg0KPg0KPiA+IC0tLSBhL3hlbi9pbmNsdWRlL3hsYXQubHN0DQo+ID4gKysrIGIveGVuL2lu
Y2x1ZGUveGxhdC5sc3QNCj4gPiBAQCAtMTY4LDYgKzE2OCw3IEBADQo+ID4gICEgIHByb2Nlc3Nv
cl9wZXJmb3JtYW5jZSAgICAgICAgICAgcGxhdGZvcm0uaA0KPiA+ICAhICBwcm9jZXNzb3JfcG93
ZXIgICAgICAgICAgICAgICAgIHBsYXRmb3JtLmgNCj4gPiAgPyAgcHJvY2Vzc29yX3B4ICAgICAg
ICAgICAgICAgICAgICBwbGF0Zm9ybS5oDQo+ID4gKz8gIHByb2Nlc3Nvcl9jcHBjICAgICAgICAg
ICAgICAgICAgcGxhdGZvcm0uaA0KPg0KPiAuLi4gaG93IGNhbiBpdCBiZSA/IGhlcmUgd2hlbiBp
dCdzIC4uLg0KPg0KPiA+ICAhICBwc2RfcGFja2FnZSAgICAgICAgICAgICAgICAgICAgIHBsYXRm
b3JtLmgNCj4NCj4gLi4uICEgaGVyZT8gQW5kIHdpdGggaXQgYmVpbmcgPywgeW91J3JlIGxhY2tp
bmcgYSBwbGFjZSB3aGVyZSB5b3UgaW52b2tlIHRoZSByZXN1bHRpbmcNCj4gY2hlY2tpbmcgbWFj
cm8gKHdoaWNoIEkgYXNzdW1lIHdvdWxkIGNhdXNlIGEgYnVpbGQgZmFpbHVyZSkuDQo+DQo+IEFs
c28gd2hlbiBsYXlpbmcgb3V0IHN0cnVjdCB4ZW5fcHJvY2Vzc29yX2NwcGMsIHBsZWFzZSBhdm9p
ZCB1bm5lY2Vzc2FyeSBnYXBzDQo+IG9yIHRhaWwgcGFkZGluZyAtIGl0IGxvb2tzIGxpa2UgInNo
YXJlZF90eXBlIiB3b3VsZCBiZXR0ZXIgbW92ZSB1cC4gSSB0aGluayBpdCB3b3VsZA0KPiBhbHNv
IGJlIGEgZ29vZCBpZGVhIHRvIG1ha2UgcGFkZGluZyBmaWVsZHMgZXhwbGljaXQsIGFuZCBjaGVj
ayB0aGVtIHRvIGJlIHplcm8uDQo+IFRoaXMgd2F5IHRoZXkgY2FuIGJlIGFzc2lnbmVkIG1lYW5p
bmcgbGF0ZXIgKGlmIG5lZWQNCj4gYmUpIHdpdGhvdXQgYnJlYWtpbmcgYmFja3dhcmRzIGNvbXBh
dGliaWxpdHkuDQo+DQoNClVuZGVyc3Rvb2QsIEknbGwgcmUtY29uc3RydWN0IGludG8gaW5jcmVh
c2luZyBvcmRlciBhbmQgYWRkIGV4cGxpY2l0IHBhZGRpbmc6DQpgYGANCnN0cnVjdCB4ZW5fcHJv
Y2Vzc29yX2NwcGMgew0KICAgIHVpbnQ4X3QgZmxhZ3M7IC8qIGZsYWcgZm9yIENQUEMgc3ViIGlu
Zm8gdHlwZSAqLw0KICAgIHVpbnQ4X3QgcGFkWzNdOyAvKiBwYWRkaW5nIGFuZCBtdXN0IGJlIHpl
cm8gKi8NCiAgICAvKg0KICAgICAqIFN1YnNldCBfQ1BDIGZpZWxkcyB1c2VmdWwgZm9yIENQUEMt
Y29tcGF0aWJsZSBjcHVmcmVxDQogICAgICogZHJpdmVyJ3MgaW5pdGlhbGl6YXRpb24NCiAgICAg
Ki8NCiAgICBzdHJ1Y3Qgew0KICAgICAgICB1aW50MzJfdCBoaWdoZXN0X3BlcmY7DQogICAgICAg
IHVpbnQzMl90IG5vbWluYWxfcGVyZjsNCiAgICAgICAgdWludDMyX3QgbG93ZXN0X25vbmxpbmVh
cl9wZXJmOw0KICAgICAgICB1aW50MzJfdCBsb3dlc3RfcGVyZjsNCiAgICAgICAgdWludDMyX3Qg
bG93ZXN0X21oejsNCiAgICAgICAgdWludDMyX3Qgbm9taW5hbF9taHo7DQogICAgfSBjcGM7DQog
ICAgLyogQ29vcmRpbmF0aW9uIHR5cGUgb2YgdGhpcyBwcm9jZXNzb3IgKi8NCiAgICB1aW50MzJf
dCBzaGFyZWRfdHlwZTsNCiAgICBzdHJ1Y3QgeGVuX3BzZF9wYWNrYWdlIGRvbWFpbl9pbmZvOyAv
KiBfUFNEICovDQp9Ow0KYGBgDQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Tue May 06 10:07:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 10:07:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.976996.1364083 (Exim 4.92)
	(envelope-from )
	id 1uCFCg-0003od-01; Tue, 06 May 2025 10:07:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 976996.1364083; Tue, 06 May 2025 10:07: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 1uCFCf-0003oW-TR; Tue, 06 May 2025 10:07:09 +0000
Received: by outflank-mailman (input) for mailman id 976996;
 Tue, 06 May 2025 10:07:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCFCe-0003mt-57
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 10:07:08 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20604.outbound.protection.outlook.com
 [2a01:111:f403:2417::604])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dad2c602-2a61-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 12:07:03 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SN7PR12MB8129.namprd12.prod.outlook.com (2603:10b6:806:323::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.21; Tue, 6 May
 2025 10:06:57 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%4]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 10: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" 
X-Inumbo-ID: dad2c602-2a61-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ARqVUOdWLPrivwMf70ifvyYym2RUzBtkMUJgHr7b5PIrYkmaZZRgeT4EDhKWEqDPYmAlz1ZqAbYQAHxvlDglIDm4ecxuboX/fKAoWKzPpPKAVlo4OWF9XJIZ8WYEz6G8Xn+yZ3F0Zqs5pkULQfMeLgvnYGK5t/B5BY21FjElXqP4O0tI00I/ih5OLrESsYhVJXE0k2D1STbksS7APQXWlKa0vzCNJi3PjBOuq+uq8nMCiQvAnowY/m3gcepurMGSdMdNRBDjALIn4x+o9yAK+NPykOqQC8J5QY2z4RXyHONfCuRR2bVKKMFnYMRLg0SFNjx7/wuetxqHCcMNwFxXAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fM9T5OT9+XkkhG0vxTmxVbSdLWaDCvy4hAZsABPfPrI=;
 b=lkp4oTshPOywa5hBXDzL2FP8wkeLcm/kjuFD2Lc1yblaR7LXml6OfiCF+DfBQ29yLQDLDk4iw4fjH7JP7ZYE0NCDo1kaa3TT4UcxihEnTn8K/BkQJDZEm3xEST5oGSx3C0jmW/BUYeV4OzQ3OBRvhzG/Hh1CyKbZjT72YMdI3LU4IJXpSNiIiOCMQ2msQKOthVd9+f2Ht+PyuFVQLk7/ONuBmTT6wqXRItdVbMEyzs/v8DMvPX888UU/syO4G5z1+SndIK833FAu8lhZWabGRN0v16Z5FNuyFAjqraQPtYbT5E6edA0Rrh0ZiJNuo61RgK3gePeM9A7K+W+fswWtVg==
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=fM9T5OT9+XkkhG0vxTmxVbSdLWaDCvy4hAZsABPfPrI=;
 b=uYLQRfRmpiaf/LhEV8jntnPvRYICs9ZsYeuLPOXtKeiKlL3lfsrTeiiWBD2Tj0b4gUJ71+Blf4SeppfiJhPlkHLzHtoUNmOhdo4eq2Qrme4GrMOxl4+DqxPTjUURxhiWbr7pJ1oB/qLuvWGAzgVropV2Nn0xDd1YaekBTv3eMG4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <42eab292-f9f6-4bc1-a011-c657544ebaf5@amd.com>
Date: Tue, 6 May 2025 12:06:50 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 6/7] arm/mpu: Provide a constructor for pr_t type
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-7-luca.fancellu@arm.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250429152057.2380536-7-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0100.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:cb::14) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SN7PR12MB8129:EE_
X-MS-Office365-Filtering-Correlation-Id: 70fcb4aa-513a-4de0-f1f2-08dd8c85bc2d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cWtJaytwVlk3UVVwa2ozalJvRDdzQ0JVMWVEeWk3QzZVc00xOHhGdnAwMEJx?=
 =?utf-8?B?VkxLVVBBZ1lqeVRaWVl4azV0RG5ZakdWcFZ5UkliYVlrRThwZlN3UmtJZWx5?=
 =?utf-8?B?WWZ3T2xmNDBtdzc5d2ovSzNqMmtvMERQSVNITTFLeVkwUFQwWE5mdlRKb3Mx?=
 =?utf-8?B?akYwWWlqMmVjQ2RJSTFkc3J5bVMydCtMOVRTK3hWR3o2YXhlaXFBTk95V3RE?=
 =?utf-8?B?K2RIMW5nRDRZd2ExbzdkY3FJdFQxWGUrVHNYem1aZ2VhOUdvME5BL0VKdnlQ?=
 =?utf-8?B?YnB4QnNuOWo5cWFnZGVINHFWK3duaTRkRWNZT25mQkJ5d1RJbzhtcmlJVDVY?=
 =?utf-8?B?Vm1RYjI1ZE5nSG9MenM0UUtPbmc2TEp5aDJNY0ZWYmpSbGViSjRFRnlBZTdz?=
 =?utf-8?B?S1JPcDdSNFJFRnJzcTVVaGcwWGxvNHFieFRoaS95SFd0TWpDeUxaUnMwY3FL?=
 =?utf-8?B?Z2t3ZWxXRlZyK3B1V1JWaHFQaU4yb1o3Z0ZVWkxubGJOS0RmYk00bkgvcDlS?=
 =?utf-8?B?L3FOYjg3dEZRbUVTTHRFRFhDcTJkTTdCZzlGOTJOQzYvcUFLNXQvbFNuRmVO?=
 =?utf-8?B?MTd1SlYrMCtGUUQxc2h1dWd6MHdXZFRsRzNnbWc5OEU5bUpYRDhOblEweGZP?=
 =?utf-8?B?T0RxT2JEdlBod2kzR0dEUWFiUjh5b1JTSXc0VUZYV1lGZmxveFdsNmpuRSs3?=
 =?utf-8?B?ZTNVbEdyeTE2N1l0a1FuTmhuRDJvS3F1SlJHMHJGcnp5c1VBWnBGVDNrQUhs?=
 =?utf-8?B?OXBaT3owT01wKzR5ekJaeXhSOGtLQ0FNa0pjRVBMM0o4V0NTNUJCVGoxUzdS?=
 =?utf-8?B?dFZFaDFZbDBnZmVEamZjcjd4L1J1UHphRTlqOFRYQkVwZ1ZodFgxS3ozMDlR?=
 =?utf-8?B?d2hWNGJUQmkvTjJFMnU3OVpmS0wycDZXS1FscUUrbk90R2JQbldYWEYyaklz?=
 =?utf-8?B?TXF0bzdmN3RUb2Z1Rk5qQzl3UFdkSFg2TGNxMFd4M0lMRjB3ZWlsTjlJM1BM?=
 =?utf-8?B?L3pabm42NDgzNVBQK3VsWUFzd29lcGtSZE9yZnZXamNsNkZqa1Y3NVZHMy94?=
 =?utf-8?B?eTBnaWU4SmJHQ2htR1lBbnA5UUsvNmtHaXBpbExiQWhMTnMwTnZJNmx3ekVs?=
 =?utf-8?B?NGg3R25TZitEcHRFQVJleGVoV3lBQnJOTjB5dkN6NmhFTkdTNXo1U2ZVaXRE?=
 =?utf-8?B?Z3RwT2djYWovVkJjdyt4NndNVWRXUWZwajRhZzZ6amtLK2FGcWtRNU5vSnA1?=
 =?utf-8?B?bUdTZFNvaGlKMGMrS2FlSmZRVEoveStIeFQreEcvTVQ1MzZkUFZ4bmwrK0hX?=
 =?utf-8?B?V2Jva3NhdjNrNGIrVzYxN1lEeWlQRnVHZFVsdEJEOVJ6M051Wk5haWV1OWQr?=
 =?utf-8?B?emVDQkZhTUJydmYzTThNVDdyMkluVGNVb3h3MWRyajR6SzZxYnFXUTJmTW1D?=
 =?utf-8?B?ZnRVSS9SZEN5T09yUGV2UkRPQWhvbVhYVUtucURtd2Rnd1hucFljUFRTRlUr?=
 =?utf-8?B?QVYraVZsZWRFTzRUNXNXYmc5S0VWRStQbTlIMGtiaU95d29ubG0rcWdIck9s?=
 =?utf-8?B?bXFHeThvZThMRXFwWkQwZXhreUdQQ1pXTFBYS0VGekw5N1VFNjA0bkIwbmJC?=
 =?utf-8?B?S3dQSGVLNC9jak5JRzVUYnY3N0o1ODIvTDg3TEVpSEtmUUdwWUNQT25IbXg0?=
 =?utf-8?B?Uk5lYnZTWXc1ZnFJdmViOEx1QXZ2TUQvU2VYWUgreWVWUnk2Z3Z6SDN3bUFz?=
 =?utf-8?B?THFyZXZRaWR3NHJWSjZseWsvbkM4N0dwcnMxSlhybm00cjJHOVFRcmJQTDZY?=
 =?utf-8?B?UkEwczJwZkwvVEkwdEg4VExMY2d6bXVDaTNnZ0Z5aUpVcFVHTGFKL3F0WkR2?=
 =?utf-8?B?V2JUbDhjaGowRkM2L1ZnZmxJR2F4THhXclRncjBjRzZrMVhSUHRQY2lyNE1t?=
 =?utf-8?Q?6ftdDKQxdI4=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?OGh6UXpXNnY2cjVhM3hJeTY0cHlMUUtJK3F6WGhYdTRrMGQyamozakxtM2Zq?=
 =?utf-8?B?dW55YmNGODZmdFp4RGZ1S1ZqOStEaWZ1K1JEbzV6Rk94bzE0L2syYUNrY2tu?=
 =?utf-8?B?Vi9ad1dhYVRlTGl0Ri9GcWI5YWM2NHRGNk1hKzlEMVYrSzZRMnZnY011dnpz?=
 =?utf-8?B?b0U0c0NBOVI5WC9iQmx5eGg0Wk5zczZXdngzaW5ObTIrcTh2ZktnSDhsc3Vt?=
 =?utf-8?B?UWdqT25qeTJ0LzhmVW9pTjVPMm1JOS9TVStlN1p0M0s4YUVlMXh2bFRaKzFo?=
 =?utf-8?B?MUI0WXhPbmlSVzNObHpSVG9QYjRhQTJpc3RTMFZTcXZmU0kyYWppWTRQaC9T?=
 =?utf-8?B?d3NhcXFXdkljL1lqdUxjTXhhSEZOWmFSR0VIWFNwSWR1WThPbWtsZTA1SUly?=
 =?utf-8?B?ZWdYK2NtVGkzYzFzZnA0bER6S014SHdqUHVHNkRoaDFEV0VIOEtDY2w1RWQw?=
 =?utf-8?B?SWVFcHdDcC80NjM4cTM0bk9TQW16VFVrNmIxV2R4U280VDRSaTF6QUkzQkRC?=
 =?utf-8?B?M3orcXV3NlVoZU9ZTEoyd3lNY3d5QVBEbU9RYmh6QWE2MzhSTnNVbXg1NzNr?=
 =?utf-8?B?d1VrcE9aRmR0YS9nRXZiYzNPZ1dhc1luSXNmd1BNb2xVOVB0MzJGckYyUmNs?=
 =?utf-8?B?UVpYREVqakpvTWI0Y0kveWRZOUp5d25mejN0NVlMYVkrdE9KcnR0cU5TWndt?=
 =?utf-8?B?Rk5pTXBROEhrVkVkbHZ4QnRRRDMxbW5SOUZZSmowb1pqTmw3UCs3Vm5BZmNx?=
 =?utf-8?B?cWFpVmZudVYyUkw5RkNMc2pCVFJqQ0NSei8yMFl3R0ZhM3VzMG1kVks4UmR5?=
 =?utf-8?B?Z2k5YmJ3Z0h0czNoYjdySXQ5aStLQXBpTk5rUVlIeVRtUFV4NVFXeWRlcUk0?=
 =?utf-8?B?S3M4aTVLaXlacktMekxLUmF0ZndSK3duaXhueWVsbHBFa2tNZXpMVFBxTVZp?=
 =?utf-8?B?NURUVTlYQ2oyWUZPOUNoTC9DNkRiWEhDSDduTFN0YU93TzN4ZTdoL2pHSVVv?=
 =?utf-8?B?aUw0ODVsekJNM2loWktzUzYxYnlEVGlhbFRkbkduaEpEcUxCRnBMSGZsREsw?=
 =?utf-8?B?ck52aEppTkRKSHd4TE96Rnd0QVdhaXVJTUs5QXlpMWxRd2RHMXJ2dXdVYUJ6?=
 =?utf-8?B?NDRSS1JBZncvUVI4d3FLNmZQc08wdzhFdzBINnliYzBsYUJMZWdBWHpLNTlV?=
 =?utf-8?B?TXBtOFR1d2lqWFh6QjhNNElTQzBVYUlqM3BtdFRsRU9yYk1EeElXNzlLeGRO?=
 =?utf-8?B?Nytad0Z5UlJySzgwNC9oMnRlckVlVW1uUGNFV3d5WEZ3WVhlRVlmV2ZhdHJZ?=
 =?utf-8?B?ZjhlOVdnTDFKQS90MWoySU5KL211NDNiWFliMjJ6ejlUQ2lKMWZnanJRaGR5?=
 =?utf-8?B?ZTZacTYvMXU1NWJ0b2Z2VGVCaGk3WHpRL1RGNERhVGNFRnRoajd3YUxZbzQw?=
 =?utf-8?B?ZDRlOUhJcGtkU1BzdFBqTHY5akUxbWd6Wng5NFFWdXNYbkN0UGJMeHlKc09X?=
 =?utf-8?B?TSt2MTZWOUI1WWJhRHhUUHdMdmI5L3grUXJxcER1Z0RBTmRMcURVdm11YnBX?=
 =?utf-8?B?ZEdjbFJVSm41dkZvYnBXSzQ2VGJ0OUNHNlRhelNvUFQ0UmVNNjNXd05wd0NF?=
 =?utf-8?B?QUluUWNuejlFRHc5cVRjZmJhVmJTUEJqOWY3T3BwbFV2cDh2RDJrOXF2dHcw?=
 =?utf-8?B?VHpxaVViTEczZ1ZWRWdhS3ZMVjRYRWJRRGpNV0ZRaXVlbGlDQzBrNHhGNXdh?=
 =?utf-8?B?SGI1MURvL2w2a3JSVFNvM0Zoem9QNkkwdG1ZYTdPQjNSdVp3NkNFMnBEZVFU?=
 =?utf-8?B?ZlNlWWlzMk1nSmdERENpYXRQbFNkOU90b25pcnBJNjJiTGozS2d2UFhoaW5a?=
 =?utf-8?B?eTFocHJodnYxREhoNTcySWgxbHpvenZ1VU9HOFlaVXI4OFdKbVZ0UkI5UDRi?=
 =?utf-8?B?WWNhRmcweXgzbDVESEVXTDRCNXZpNlcvRU1hbkk5LzBNbThpK2d0a3FpZDJw?=
 =?utf-8?B?cExnMTNpRnd4Vkd4Qks0VldpWlpJclhRajcrOC9jd001OWl4UWhybldZZGkx?=
 =?utf-8?B?VEoxdGUxalo2ajZmSnptQ0RSQklreHJ5aVgreE1rMGU4Nk9zMGcxU0lMK0kv?=
 =?utf-8?Q?Nk6c=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 70fcb4aa-513a-4de0-f1f2-08dd8c85bc2d
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 10:06:57.3982
 (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: NEwNEw7/7kHWMfPj1sHWNwM414rzPyqSwdRiQ16JTHfegXiUdK8Po94yyASEILXu
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8129



On 29/04/2025 17:20, Luca Fancellu wrote:
> Provide a function that creates a pr_t object from a memory
> range and some attributes.
> 
> Signed-off-by: Luca Fancellu 
> ---
> v4 changes:
>  - update helper comments
>  - rename XN_EL2_ENABLED to PRBAR_EL2_XN_ENABLED
>  - protected pr_of_xenaddr() with #ifdef Arm64 until Arm32
>    can build with it
> ---
>  xen/arch/arm/include/asm/arm64/mpu.h | 11 +++++
>  xen/arch/arm/include/asm/mpu.h       |  4 ++
>  xen/arch/arm/include/asm/mpu/mm.h    | 10 ++++
>  xen/arch/arm/mpu/mm.c                | 68 ++++++++++++++++++++++++++++
>  4 files changed, 93 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h
> index b27fccd77550..39233b43a5aa 100644
> --- a/xen/arch/arm/include/asm/arm64/mpu.h
> +++ b/xen/arch/arm/include/asm/arm64/mpu.h
> @@ -3,6 +3,17 @@
>  #ifndef __ARM_ARM64_MPU_H__
>  #define __ARM_ARM64_MPU_H__
>  
> +/*
> + * Excute never.
> + * Stage 1 EL2 translation regime.
> + * XN[1] determines whether execution of the instruction fetched from the MPU
> + * memory region is permitted.
> + * Stage 2 EL1/EL0 translation regime.
> + * XN[0] determines whether execution of the instruction fetched from the MPU
> + * memory region is permitted.
> + */
Why do we need this comment? If any, why do we need EL1 description if the macro
is EL2?

> +#define PRBAR_EL2_XN_ENABLED  0x2
> +
>  #ifndef __ASSEMBLY__
>  
>  /* Protection Region Base Address Register */
> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
> index 0e0a7f05ade9..7b82f10d336b 100644
> --- a/xen/arch/arm/include/asm/mpu.h
> +++ b/xen/arch/arm/include/asm/mpu.h
> @@ -24,6 +24,10 @@
>  #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
>  #define MAX_MPU_REGION_NR       255
>  
> +/* Access permission attributes. */
> +/* Read/Write at EL2, No Access at EL1/EL0. */
> +#define AP_RW_EL2 0x0
This macro and the previous one are used only once (I also checked your full
tree) and cannot be set by the caller. What's the purpose of the macros then?
Why can't we set these values in pr_of_xenaddr() and add comment next to value
there?

> +
>  #ifndef __ASSEMBLY__
>  
>  #ifdef CONFIG_ARM_64
> diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
> index e2235e568e81..296fe74c5d61 100644
> --- a/xen/arch/arm/include/asm/mpu/mm.h
> +++ b/xen/arch/arm/include/asm/mpu/mm.h
> @@ -75,6 +75,16 @@ extern void read_protection_region(pr_t *pr_read, uint8_t sel);
>   */
>  extern void write_protection_region(const pr_t *pr_write, uint8_t sel);
Here and ...

>  
> +/*
> + * Creates a pr_t structure describing a protection region.
> + *
> + * @base: base address as base of the protection region.
> + * @limit: exclusive address as limit of the protection region.
> + * @attr: attribute index for the memory type.
> + * @return: pr_t structure describing a protection region.
> + */
> +extern pr_t pr_of_xenaddr(paddr_t base, paddr_t limit, unsigned int attr_idx);
here. Please don't use extern in prototypes. It's not needed.

> +
>  #endif /* __ARM_MPU_MM_H__ */
>  
>  /*
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index 40ccf99adc94..2e0aeb486ff8 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct page_info *frame_table;
> @@ -151,6 +152,73 @@ void write_protection_region(const pr_t *pr_write, uint8_t sel)
>          BUG(); /* Can't happen */
>      }
>  }
> +
> +pr_t pr_of_xenaddr(paddr_t base, paddr_t limit, unsigned int attr_idx)
> +{
> +    prbar_t prbar;
> +    prlar_t prlar;
> +    pr_t region;
> +
> +    /* Build up value for PRBAR_EL2. */
> +    prbar = (prbar_t) {
> +        .reg = {
> +            .ap = AP_RW_EL2,      /* Read/Write at EL2, no access at EL1/EL0. */
> +            .xn = PRBAR_EL2_XN_ENABLED,   /* No need to execute outside .text */
> +        }};
> +
> +    switch ( attr_idx )
> +    {
> +    case MT_NORMAL_NC:
> +        /*
> +         * ARM ARM: Overlaying the shareability attribute (DDI
> +         * 0406C.b B3-1376 to 1377)
It's a bit odd to provide here the manual for Armv7.
Also, our general advice is to use the latest revision.

> +         *
> +         * A memory region with a resultant memory type attribute of normal,
> +         * and a resultant cacheability attribute of Inner non-cacheable,
> +         * outer non-cacheable, must have a resultant shareability attribute
> +         * of outer shareable, otherwise shareability is UNPREDICTABLE.
> +         *
> +         * On ARMv8 sharability is ignored and explicitly treated as outer
> +         * shareable for normal inner non-cacheable, outer non-cacheable.
> +         */
> +        prbar.reg.sh = LPAE_SH_OUTER;
> +        break;
> +    case MT_DEVICE_nGnRnE:
> +    case MT_DEVICE_nGnRE:
> +        /*
> +         * Shareability is ignored for non-normal memory, Outer is as
> +         * good as anything.
> +         *
> +         * On ARMv8 sharability is ignored and explicitly treated as outer
Does this Armv8 comments make sense? We don't support Armv7 MPU.

> +         * shareable for any device memory type.
> +         */
> +        prbar.reg.sh = LPAE_SH_OUTER;
> +        break;
> +    default:
> +        /* Xen mappings are SMP coherent */
> +        prbar.reg.sh = LPAE_SH_INNER;
AFAIR MISRA C requires every clause to be terminated with break.
That said I don't remember if we accepted this rule...

> +    }
> +
> +    /* Build up value for PRLAR_EL2. */
> +    prlar = (prlar_t) {
> +        .reg = {
> +            .ns = 0,        /* Hyp mode is in secure world */
> +            .ai = attr_idx,
> +            .en = 1,        /* Region enabled */
> +        }};
> +
> +    /* Build up MPU memory region. */
> +    region = (pr_t) {
> +        .prbar = prbar,
> +        .prlar = prlar,
> +    };
> +
> +    /* Set base address and limit address. */
> +    pr_set_base(®ion, base);
> +    pr_set_limit(®ion, limit);
> +
> +    return region;
> +}
>  #endif
>  
>  void __init setup_mm(void)

~Michal



From xen-devel-bounces@lists.xenproject.org Tue May 06 10:15:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 10:15:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977008.1364092 (Exim 4.92)
	(envelope-from )
	id 1uCFKT-0005jN-NY; Tue, 06 May 2025 10:15:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977008.1364092; Tue, 06 May 2025 10:15: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 1uCFKT-0005jG-L4; Tue, 06 May 2025 10:15:13 +0000
Received: by outflank-mailman (input) for mailman id 977008;
 Tue, 06 May 2025 10:15:12 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uCFKS-0005jA-SS
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 10:15:12 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uCFKS-00Cc9R-0i;
 Tue, 06 May 2025 10:15:12 +0000
Received: from [2a02:8012:3a1:0:7157:32ca:2aea:33a3]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uCFKS-00FwLm-05;
 Tue, 06 May 2025 10:15: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=D6GfJJejLuaeHsmXVZVCpGoUnVnF6gmM7bS1JOgbAWw=; b=xyRXcx5Lfk2lNEliuq03ckPaUN
	WZE+xBcjlQ/gJSj+8tttd0+Z/WuaLjTwvVAN7B9JF27F//dFFjI8v+NW96ZLo3hR0ev6YB/8bKAfh
	pYFTDqgrOouj1ByMHu0GMQb6JCB2MFaQasI37jrfU1r+swxaYR1Nx11HIeefa6ypOTRc=;
Message-ID: 
Date: Tue, 6 May 2025 11:15:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/9] xen/gnttab: limit cache flush operation to guests
 allowed cache control
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Stefano Stabellini 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-4-roger.pau@citrix.com>
Content-Language: en-GB
From: Julien Grall 
In-Reply-To: <20250506083148.34963-4-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Roger,

On 06/05/2025 09:31, Roger Pau Monne wrote:
> Whether a domain is allowed to issue cache-control operations is reported
> by the cache_flush_permitted() check.  Introduce such check to limit the
> availability of GNTTABOP_cache_flush to only guests that are granted cache
> control.

Can you outline what's the problem you are trying to solve? Asking, 
because I don't see the problem of allowing any guest calling 
GNTTABOP_cache_flush on Arm from any domains.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue May 06 10:20:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 10:20:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977019.1364103 (Exim 4.92)
	(envelope-from )
	id 1uCFPq-0007GR-9x; Tue, 06 May 2025 10:20:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977019.1364103; Tue, 06 May 2025 10:20:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCFPq-0007GK-7D; Tue, 06 May 2025 10:20:46 +0000
Received: by outflank-mailman (input) for mailman id 977019;
 Tue, 06 May 2025 10:20:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uCFPo-0007GE-T9
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 10:20:44 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uCFPo-00CcIS-02;
 Tue, 06 May 2025 10:20:44 +0000
Received: from [2a02:8012:3a1:0:7157:32ca:2aea:33a3]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uCFPn-00G1ov-2G;
 Tue, 06 May 2025 10:20: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=z1EbbgfKUDdWS8X/RCAcaXdL1nh7DiBzwmIhUd0THD8=; b=43FHNgIEGoPgonOUhZXW3n2Mpp
	it4qGurjr4dC1WnKQxf/S3lMX+3Cq7Da1lyRKZAhovrJDlSnpPv2CE1vhsKzk0FstBcwpRlA3RdkB
	HtWaUKBD1IO6jeUvrhDxhCNueEgDHei55MKDtSH7+q2VkaonKmNHhl9hdvX/YTKGFaMc=;
Message-ID: <035eeb54-e03b-463d-8ed8-b7041505322e@xen.org>
Date: Tue, 6 May 2025 11:20:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 8/9] xen: introduce flag when a domain requires cache
 control
Content-Language: en-GB
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Stefano Stabellini , Juergen Gross
 , Christian Lindig ,
 David Scott , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-9-roger.pau@citrix.com>
From: Julien Grall 
In-Reply-To: <20250506083148.34963-9-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Roger,

On 06/05/2025 09:31, Roger Pau Monne wrote:
> Such flag is added to the domain create hypercall, and a matching option is
> added to xl and libxl to set the flag: `cache_control`.  When the flag is
> set, the domain is allowed the usage of cache control operations.  

Can you clarify whether you are talking about using the hypercall to 
flush the cache or the instructions?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue May 06 10:40:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 10:40:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977030.1364113 (Exim 4.92)
	(envelope-from )
	id 1uCFjG-000293-Rz; Tue, 06 May 2025 10:40:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977030.1364113; Tue, 06 May 2025 10: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 1uCFjG-00028v-OB; Tue, 06 May 2025 10:40:50 +0000
Received: by outflank-mailman (input) for mailman id 977030;
 Tue, 06 May 2025 10:40:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCFjF-00028p-QN
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 10:40:49 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8b677f72-2a66-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 12:40:36 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43cf3192f3bso52129575e9.1
 for ; Tue, 06 May 2025 03:40:36 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099b0fe9dsm13244046f8f.71.2025.05.06.03.40.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 03:40:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8b677f72-2a66-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746528036; x=1747132836; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=I62aSuetZC4Vo7o9CLyiqhHPLmx8Jfdaq3hMQktMJGg=;
        b=RKV5wM6Jbac0l/1iB2V6uaNScGNeVSaAI5xQckF437juCEEaODP19TnEVvWReSNfg7
         84D3Xpdrg/oxQKhkduIR+LWk37AD0bO9NvYlOVALFbT8y/BdhxXN4hiaIc9LvjAArlaj
         iR7gaJTUXqxSTYBR690M9jLiKDrbWkHMhv2cs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746528036; x=1747132836;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=I62aSuetZC4Vo7o9CLyiqhHPLmx8Jfdaq3hMQktMJGg=;
        b=OP9cq0PSZxX51gSbU2al5ryrxCEC1SGNJ/3Zg1S6v4QNjCVjzDacuuR+S77jHOVO+f
         nVdDI+8rxJdPFSo14tEQ6iYtUCXZg1S+AHAnwHstBad2v3DqCb6xxu7l5EZ8ds++vLKF
         3iR8J6S4lY9V9BnsKaurs5g0gsH+WC/vFOsdXcP4UsuKIN2ySsWMxn/ns9vvy5/9BQsR
         ryhVtRvBp65Eq+5fBwzfG3m7e1op4q791rDjd1yoJBdDFhRrAo1l4xbbpgNkpe6Q6SHV
         G9z1M/2nHAuvkSyTklhsOSnfvDBOpjxU45+LHPwzdmkcHx3v6BiSLYVOPwJ7yLbLwYBA
         L76A==
X-Gm-Message-State: AOJu0YzHRORu5PKk+FCSmA01ltvzk0IFovN2NZ2OWbBUfXsDIEfefR6I
	5kLdKyrbRCsqpJAmhndSdrp3XPehdRZd/K4jkFpUvvBSx0IQ051zsQAKTEDJYRg=
X-Gm-Gg: ASbGncvmGJTX64cDY1VR/mdN0H4/jEJnUJK5MqIX1kpuJjLUs1sTGqKDmXVDGS3pjAD
	437LkIaAUlw4Ue3CzWHTcyFAOX2qt1noAEa0cC8K61Reirdo0JQPBtVmBGXR5lWdOW0GMMhkHFw
	4Fclg3Y9HYhJ5X9IlXyIW4Wby29P2svajRTMUBj4luBG0/9iS1OX3EHjUFoWWQcPZ8Fy5F9uoZb
	tNmgUdxOg1gIRVFRaogef8F6vJAOeH4+hZw6aLx2dAdkUmMAoFYW9GHUyKOsJS7t8LvPnaDdANq
	yYOl8Yujs7LLb1/kU+uRIuMypV0Ho8P2zM+DAsAlrjVgsA==
X-Google-Smtp-Source: AGHT+IFiXPN1jr3LP+KnWPdnXYVkO0X1phn4ZVRmJS4H1NiXmyqZJEfBOlFLrfE7/tkubPzsMFehUQ==
X-Received: by 2002:a05:600c:870b:b0:43d:738:4a9 with SMTP id 5b1f17b1804b1-441c494849emr90177905e9.27.1746528035668;
        Tue, 06 May 2025 03:40:35 -0700 (PDT)
Date: Tue, 6 May 2025 12:40:34 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Stefano Stabellini 
Subject: Re: [PATCH 3/9] xen/gnttab: limit cache flush operation to guests
 allowed cache control
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-4-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Tue, May 06, 2025 at 11:15:09AM +0100, Julien Grall wrote:
> Hi Roger,
> 
> On 06/05/2025 09:31, Roger Pau Monne wrote:
> > Whether a domain is allowed to issue cache-control operations is reported
> > by the cache_flush_permitted() check.  Introduce such check to limit the
> > availability of GNTTABOP_cache_flush to only guests that are granted cache
> > control.
> 
> Can you outline what's the problem you are trying to solve? Asking, because
> I don't see the problem of allowing any guest calling GNTTABOP_cache_flush
> on Arm from any domains.

At least on x86 cache flush operations are restricted to guests for
which cache_flush_permitted() returns true.  I've assumed the same
would apply to Arm, since cache_flush_permitted() is also defined
there.  If it's fine to issue cache flush operations from any guests
on ARM, I suggest cache_flush_permitted() should unconditionally
return true then.

The problem on x86 is that it's an expensive operation when done
correctly, as it involves flushing the caches of all pCPUs where the
vCPU has been scheduled.  Note however the implementation of
GNTTABOP_cache_flush is incorrect on x86, and won't work as
expected.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 10:43:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 10:43:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977041.1364122 (Exim 4.92)
	(envelope-from )
	id 1uCFm9-0002u5-7m; Tue, 06 May 2025 10:43:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977041.1364122; Tue, 06 May 2025 10:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCFm9-0002ty-58; Tue, 06 May 2025 10:43:49 +0000
Received: by outflank-mailman (input) for mailman id 977041;
 Tue, 06 May 2025 10:43:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCFm7-0002tr-K3
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 10:43:47 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fd03b27b-2a66-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 12:43:47 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-43cfecdd8b2so35321195e9.2
 for ; Tue, 06 May 2025 03:43:46 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a0b0dffaa1sm1200469f8f.31.2025.05.06.03.43.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 03:43:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fd03b27b-2a66-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746528226; x=1747133026; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=eesApTGBPNVMJiYG4zC+vOLY/uFRoJRoHZ5ler0C+Kw=;
        b=RjvSA92cYORaT3mYRODP+rLOGOorFDNGoFZFZBAtXSJmiz8VMlhBFpZu+0tyNiVTDI
         zxvBRHFttUjUBBdB4Nnoa+B45g3BZm5jRE4o3jfQJ9SOmnlZIb9aYxH6nLHdawW2+xr8
         T+gKML7H/zEK/e41NjQCAdSHbKDlZMQ49xexY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746528226; x=1747133026;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eesApTGBPNVMJiYG4zC+vOLY/uFRoJRoHZ5ler0C+Kw=;
        b=aicPTs4xx5lN+kOUoZYjFS1pqtZny2/n0m9LW4pywLJv5msTDhcJe3v1sU0hRNL4P3
         7ajk/esCC9/5Arm2ffBiMMBmx7TqyRS27UkILswtJezRLksWMSUIzv2JYMWdOCIOgCNZ
         sWjsG1Tric3rSJWYBN3/3N94n2AkLe3DrUT90rTugd09Uhlrg2OHKE1snXccO2qMKi8c
         E/WE/PG7g8tw9pxSCGTyUu9xlJBoMfahimLxDVMZAmodqv8/V65hBce//AsYgCWVRzOt
         ZSbwepqTeUELRJ6A0GcHpYrQPAmAHoeiVWkeCY3SuAtYV+AlKtJKPsBhzR0/SQx5Pb1J
         LVqw==
X-Gm-Message-State: AOJu0YwZpc85StOUgQhYENNbBuPfloc3ZRva1QS6EdbtY5einuBaBqc3
	PsCy+hRo6aIv17GBxUeY+vvsOgLVLemz/g9GKlofV+S8mqnyw70KgRhFjHhfT6A=
X-Gm-Gg: ASbGncs+HdpAGOwu0RCoGSl7SLIiytqWfK97NIXrwWRJD7KeDliWOExrtRjJmExgzZo
	p6sg4bep4iIdhMUSRoBa6a1LprHvU9mif/gfNk+UGat2cBUFq/+f/RrW9KttUPfYkgiwcUuWvnU
	8n+YQGwJEwpG39pNbRcaI3Na8QrxsgdB1LDhFiVRNKmMmI8kXFKrk0+PCxH9jphQojJvWkvEHaI
	FUoC/Yt7riyxZeCI/FJIqhikSmbnss1qBD0ArW0mkgV8GYnkSNwQMDeek71yzM03aFOk7r6obfd
	5+95D1v/XDTDZd+dCAmWok2Xrx0u9g1AWWWvhbr+GO+zlg==
X-Google-Smtp-Source: AGHT+IGNNQQBt/Am8RJkQi++heFe/C3XsHNlKMDymKVlxz/Sf7u0uaxKUx4mkv2+G2kJH9tfz0B7dw==
X-Received: by 2002:a05:6000:4312:b0:3a0:7b07:af9 with SMTP id ffacd0b85a97d-3a09fddf4e0mr8276501f8f.56.1746528226320;
        Tue, 06 May 2025 03:43:46 -0700 (PDT)
Date: Tue, 6 May 2025 12:43:45 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Stefano Stabellini ,
	Juergen Gross ,
	Christian Lindig ,
	David Scott ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: Re: [PATCH 8/9] xen: introduce flag when a domain requires cache
 control
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-9-roger.pau@citrix.com>
 <035eeb54-e03b-463d-8ed8-b7041505322e@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <035eeb54-e03b-463d-8ed8-b7041505322e@xen.org>

On Tue, May 06, 2025 at 11:20:41AM +0100, Julien Grall wrote:
> Hi Roger,
> 
> On 06/05/2025 09:31, Roger Pau Monne wrote:
> > Such flag is added to the domain create hypercall, and a matching option is
> > added to xl and libxl to set the flag: `cache_control`.  When the flag is
> > set, the domain is allowed the usage of cache control operations.
> 
> Can you clarify whether you are talking about using the hypercall to flush
> the cache or the instructions?

On x86 at least: both hypercall and instructions if possible, since
Xen traps cache flush instructions.  Maybe that's different on ARM.
As said on a previous reply I've assumed that cache_flush_permitted()
was also relevant on ARM, but maybe it's not and domains are
unconditionally allowed execution of cache control instructions and
hypercalls.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 11:16:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 11:16:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977055.1364132 (Exim 4.92)
	(envelope-from )
	id 1uCGHY-0007yq-K0; Tue, 06 May 2025 11:16:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977055.1364132; Tue, 06 May 2025 11:16: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 1uCGHY-0007yj-HM; Tue, 06 May 2025 11:16:16 +0000
Received: by outflank-mailman (input) for mailman id 977055;
 Tue, 06 May 2025 11:16:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCGHW-0007yc-DS
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 11:16:14 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7ea4b933-2a6b-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 13:16:02 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a0b135d18eso211014f8f.2
 for ; Tue, 06 May 2025 04:16:02 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099ae0c31sm13532139f8f.10.2025.05.06.04.16.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 04: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" 
X-Inumbo-ID: 7ea4b933-2a6b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746530162; x=1747134962; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=7CSMyQv+DQP+Roh6PLIJOtftCARSzT2JDX/KcCY7xRo=;
        b=RXvX55hzxWFJWTf/NTM7WCgpLSmAEfippNzhvbRflovvVDb8WgAWf1S5ntXW1wY6X8
         9XEQT7BaQWokf3qP6kaNwSY5QyNXEqH1Qm20Chg/9xtqI3mcnxcnIyHZDp0Q7JlaA4iH
         u7jC09wtLtfAi/wxF820avOsG1ftp3fSglO5E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746530162; x=1747134962;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7CSMyQv+DQP+Roh6PLIJOtftCARSzT2JDX/KcCY7xRo=;
        b=RaHV8gMh8YxrPQkFq0ebYUqykjpoLg48vecUhJM/5D2uQCBLZKwFXrbshIIFccyFLH
         m0b8wcIMXGkqVx/vqhbCLbJUDcJJIIfmyiWCn3DII8g3A6OGnzEnYUW3s65Y8rFnsSVX
         +LWQ6fe8lP5i5JyI0/oDEiWR+RGK4YY7L2ateQ1R/MP4vP6MOzHe35vhXSybxe/4t0zG
         eSvV5rZSRQBob9g/RiyujMgBc/K4es7AvgMN4XvTSAJveBmfZkOQveIE8lzhVV7tuO+i
         iqWKl3x53Fbw0j8hOXFIE3FjfOYa7FuEillOM9ohXBzF3PdiBbhP4ziKao7+zD7JV5QP
         W69A==
X-Forwarded-Encrypted: i=1; AJvYcCVLgOhkckv69P4X9vErHo7hMcoYMY6DiA5XBuxHVsL8iqX2/6a7YsBZtBiMbAJYrOWTgKIqtOXpmVM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwXhoUgQDrWyr1vIY4p7Vb1AemPb5M59P1b1ft2bY+M/cXVyCbK
	YCouJ6sbJA2noP8O2N7pmFoEe1zQAQyjMsYpUWb1fofzQeU/OQthDnMDT418Ao0=
X-Gm-Gg: ASbGncuFhCfxgImxrUBRIIgyXGBa/+kJHo8j0y06W7/XnD9TxVkmLRLHj37anJHmgVs
	f4wJAzxI7pO8uJyQOOu4o/K9ekuvB9Cs29FnBiuSGxZ69nSdJB/wVFlQg41Ar0sJJc6szYSxBVd
	wnRZr0gnNMoH9+QVNeBV42pejcrexNCKkEtM0TxYWOY6L7YaxdDSS8j7qV8jQeA9dVm75gue0Rq
	cDBGEgyF6UNjUo64ZaFHkGxvfKlmU4SdYiMvH3uPLBg3r21L0RtKqGL+k1xkyn7gGm1dBpU80Xx
	ZBmDh+S2qamQmV6Jus/tnZISgCyNMjrNa8wEGatkydmCguJV1yXSlgVlvBJ/XbU4Gik5j/6Go/F
	mOXhQtQ==
X-Google-Smtp-Source: AGHT+IH1nMcXETKTUesDeXvaEY8g2+UEhpa6hPYMAri7OG0+JM5C6Tvu/60zzImhUR3CeS8cTm/LgQ==
X-Received: by 2002:adf:cc8b:0:b0:3a0:ad23:8a21 with SMTP id ffacd0b85a97d-3a0ad238a45mr1261546f8f.13.1746530161864;
        Tue, 06 May 2025 04:16:01 -0700 (PDT)
Message-ID: 
Date: Tue, 6 May 2025 12:16:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 9/9] xen/x86: track dirty pCPU caches for a given vCPU
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-10-roger.pau@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: <20250506083148.34963-10-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06/05/2025 9:31 am, Roger Pau Monne wrote:
> When a guest is allowed access to cache control operations such tracking
> prevents having to issue a system-wide cache flush, and rather just flush
> the pCPUs where the vCPU has been scheduled since the last flush.
>
> Note that domain-wide flushes accumulate the dirty caches from all the
> vCPUs, but clearing the vCPU masks will require pausing all vCPUs, which
> seems overkill.  Instead leave the vCPU dirty masks as-is, worse case it
> will result in redundant flushes in further calls.
>
> Signed-off-by: Roger Pau Monné 

I'm afraid this doesn't work.

Unlike TLBs, dirty cacheline can move sideways, e.g. by foreign or grant
mapping, but also naturally because of how cache coherency works.

We need to use the guarantees given to us by the architecture to simply
nop out cache flushes when safe to do so.

Everything else is either a shootdown (clflush/opt/clwb, and doesn't
even trap to Xen), or needs to be a global WB{NO,}INVD.  Partial WBINVDs
are of no value.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 06 11:16:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 11:16:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977058.1364143 (Exim 4.92)
	(envelope-from )
	id 1uCGHx-0008Ni-Ry; Tue, 06 May 2025 11:16:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977058.1364143; Tue, 06 May 2025 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 1uCGHx-0008Nb-OY; Tue, 06 May 2025 11:16:41 +0000
Received: by outflank-mailman (input) for mailman id 977058;
 Tue, 06 May 2025 11:16:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCGHw-0007yc-IX
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 11:16:40 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 945ea082-2a6b-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 13:16:38 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43d04dc73b7so47617525e9.3
 for ; Tue, 06 May 2025 04:16:38 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441b89ee39esm164579905e9.21.2025.05.06.04.16.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 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" 
X-Inumbo-ID: 945ea082-2a6b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746530198; x=1747134998; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=jOz+2FH14WmCp86+v7BdR10VKsnfBPcIlT2o9AYI1j8=;
        b=mlJblhf/ISPfib71GxcIJ/Ouu1JDakxZl2vdxYwDrQvAMXFkznpwsww6y+nfek25gH
         HKMIcp+P5R0QpU8k/xJk0tfTKd8bK0KfA/Eo8fes8+aMVQGRotadcBlwCnKvP5qabU+6
         ZvWi4ctkiA8k3ttGxjxZGS2MeASMC2CH2jKKo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746530198; x=1747134998;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jOz+2FH14WmCp86+v7BdR10VKsnfBPcIlT2o9AYI1j8=;
        b=cFFM3riibQGYsXbYPqh+S8Yvgy2gvkRaZwQN4aRYJ957f1icbCdXJPJc/DCUEgCLnA
         lUYxu/3sQIIQSBCl9LrzRb4OokHsAbuR+bCZ67vaR+89B/7aVaCipBzxMsrYvmypAJBs
         67uhjEGo52mjiK5SoQnJvD9cxVgWYiBizVpEX0B75SYiikGvIZwnNwQYAtlaPJTKMq9g
         qmqS1AVg4qJsv2FuD1emHMbvg04K5JUllvkN3ZARAE7dWudDxFYvYaQ4LtjJFRSieCad
         jstk9gpm8LHr286BzUkKSATCv63PRg0eweV2A+++HnqeTy8K5MPVUrOrfdsNSnmL3ds6
         0I/A==
X-Gm-Message-State: AOJu0YwDrX6/bSBOjioDXj3msdUPAne6NpZdsB9dIz7pGenJOvY4ZRXi
	K+RBWyT32qk/l9JfVXlbwteoGwNa7XEbhJcYEP+nSGUQXvjy45KFfusS1hx6IW8=
X-Gm-Gg: ASbGncsh8ol5fWX2fASB4E8lDhaSIsBdrbY/YSvIR7xAFTM3BgIPBo3JsjrdJFGGFiz
	yXhkdXGJSN1fE0TEchd331/nDCk5/sVi8oLlhryLp8NhWM7Uzqs3Jg6/uVoR/JKVyEf77veA25B
	U47gGSfKNkdmZB3D4WqYwWiuzj6FuW3WSxYxnt7Px/zty7ff/9UO4CovTyAQ8b1XSJnd+sKNIeL
	eQkAisD07kktcVjHVJseW4W9syf7rmhlidfyf51Fl340erKDKuLTfpLZU6pe4+nW0n5kb+iz2+E
	d1CJSJxnyE8UwmJOqOIkeGF+n9MIX2dTr7j3zANT/kNDAw==
X-Google-Smtp-Source: AGHT+IFwT0GKnkfRq942f0gj0qAW9bTOBr4A1kjgbQpkyZViemGMq9+1XksgvswWPdvJYiZGm0Pxig==
X-Received: by 2002:a05:600c:3d8e:b0:43e:a7c9:8d2b with SMTP id 5b1f17b1804b1-441c4919de9mr91549845e9.24.1746530198257;
        Tue, 06 May 2025 04:16:38 -0700 (PDT)
Date: Tue, 6 May 2025 13:16:37 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org,
	Oleksandr Andrushchenko ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Jiqian Chen ,
	Mykyta Poturai 
Subject: Re: [PATCH v20 2/2] vpci: translate virtual PCI bus topology for
 guests
Message-ID: 
References: <20250418185840.335816-1-stewart.hildebrand@amd.com>
 <20250418185840.335816-3-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250418185840.335816-3-stewart.hildebrand@amd.com>

Hello,

Sorry I haven't looked at this before, I was confused with the cover
letter having ARM in the subject and somehow assumed all the code was
ARM related.

On Fri, Apr 18, 2025 at 02:58:37PM -0400, Stewart Hildebrand wrote:
> From: Oleksandr Andrushchenko 
> 
> There are two originators for the PCI configuration space access:
> 1. The domain that owns physical host bridge: MMIO handlers are
> there so we can update vPCI register handlers with the values
> written by the hardware domain, e.g. physical view of the registers
> vs guest's view on the configuration space.
> 2. Guest access to the passed through PCI devices: we need to properly
> map virtual bus topology to the physical one, e.g. pass the configuration
> space access to the corresponding physical devices.
> 
> In vpci_read(), use the access size to create a mask so as to not set
> any bits above the access size when returning an error.

I see this here, and the code below, yet I'm not following why this is
a requirement for the code added here.  It seems like an unrelated
change?

> Signed-off-by: Oleksandr Andrushchenko 
> Signed-off-by: Volodymyr Babchuk 
> Signed-off-by: Stewart Hildebrand 
> ---
> In v20:
> * call translate_virtual_device() from within locked context of
>   vpci_{read,write}
> * update commit message
> In v19:
> * move locking to pre-patch
> In v18:
> * address warning in vpci test suite
> In v17:
> * move lock to inside vpci_translate_virtual_device()
> * acks were previously given for Arm [0] and vPCI [1], but since it was
>   two releases ago and the patch has changed, I didn't pick them up
> 
> [0] https://lore.kernel.org/xen-devel/4afe33f2-72e6-4755-98ce-d7f9da374e90@xen.org/
> [1] https://lore.kernel.org/xen-devel/Zk70udmiriruMt0r@macbook/
> 
> In v15:
> - base on top of ("arm/vpci: honor access size when returning an error")
> In v11:
> - Fixed format issues
> - Added ASSERT_UNREACHABLE() to the dummy implementation of
> vpci_translate_virtual_device()
> - Moved variable in vpci_sbdf_from_gpa(), now it is easier to follow
> the logic in the function
> Since v9:
> - Commend about required lock replaced with ASSERT()
> - Style fixes
> - call to vpci_translate_virtual_device folded into vpci_sbdf_from_gpa
> Since v8:
> - locks moved out of vpci_translate_virtual_device()
> Since v6:
> - add pcidevs locking to vpci_translate_virtual_device
> - update wrt to the new locking scheme
> Since v5:
> - add vpci_translate_virtual_device for #ifndef CONFIG_HAS_VPCI_GUEST_SUPPORT
>   case to simplify ifdefery
> - add ASSERT(!is_hardware_domain(d)); to vpci_translate_virtual_device
> - reset output register on failed virtual SBDF translation
> Since v4:
> - indentation fixes
> - constify struct domain
> - updated commit message
> - updates to the new locking scheme (pdev->vpci_lock)
> Since v3:
> - revisit locking
> - move code to vpci.c
> Since v2:
>  - pass struct domain instead of struct vcpu
>  - constify arguments where possible
>  - gate relevant code with CONFIG_HAS_VPCI_GUEST_SUPPORT
> New in v2
> ---
>  tools/tests/vpci/emul.h |  2 +-
>  xen/arch/arm/vpci.c     |  4 +++
>  xen/drivers/vpci/vpci.c | 73 +++++++++++++++++++++++++++++++++++++----
>  3 files changed, 71 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/tests/vpci/emul.h b/tools/tests/vpci/emul.h
> index da446bba86b4..dd048cffbf9d 100644
> --- a/tools/tests/vpci/emul.h
> +++ b/tools/tests/vpci/emul.h
> @@ -89,7 +89,7 @@ typedef union {
>  
>  #define __hwdom_init
>  
> -#define is_hardware_domain(d) ((void)(d), false)
> +#define is_hardware_domain(d) ((void)(d), true)
>  
>  #define has_vpci(d) true
>  
> diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
> index b63a356bb4a8..618ddb7f6547 100644
> --- a/xen/arch/arm/vpci.c
> +++ b/xen/arch/arm/vpci.c
> @@ -34,6 +34,8 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
>      /* data is needed to prevent a pointer cast on 32bit */
>      unsigned long data;
>  
> +    ASSERT(!bridge == !is_hardware_domain(v->domain));
> +
>      if ( vpci_ecam_read(sbdf, ECAM_REG_OFFSET(info->gpa),
>                          1U << info->dabt.size, &data) )
>      {
> @@ -52,6 +54,8 @@ static int vpci_mmio_write(struct vcpu *v, mmio_info_t *info,
>      struct pci_host_bridge *bridge = p;
>      pci_sbdf_t sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
>  
> +    ASSERT(!bridge == !is_hardware_domain(v->domain));
> +
>      return vpci_ecam_write(sbdf, ECAM_REG_OFFSET(info->gpa),
>                             1U << info->dabt.size, r);
>  }
> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> index 1e6aa5d799b9..fc409f3fc346 100644
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -174,6 +174,41 @@ int vpci_assign_device(struct pci_dev *pdev)
>  }
>  #endif /* __XEN__ */
>  
> +#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
> +/*
> + * Find the physical device which is mapped to the virtual device
> + * and translate virtual SBDF to the physical one.
> + */
> +static const struct pci_dev *translate_virtual_device(const struct domain *d,
> +                                                      pci_sbdf_t *sbdf)
> +{
> +    const struct pci_dev *pdev;
> +
> +    ASSERT(!is_hardware_domain(d));
> +    ASSERT(rw_is_locked(&d->pci_lock));
> +
> +    for_each_pdev ( d, pdev )
> +    {
> +        if ( pdev->vpci && (pdev->vpci->guest_sbdf.sbdf == sbdf->sbdf) )
> +        {
> +            /* Replace guest SBDF with the physical one. */
> +            *sbdf = pdev->sbdf;
> +            return pdev;
> +        }
> +    }
> +
> +    return NULL;
> +}
> +#else
> +static const struct pci_dev *translate_virtual_device(const struct domain *d,
> +                                                      pci_sbdf_t *sbdf)
> +{
> +    ASSERT_UNREACHABLE();
> +
> +    return NULL;
> +}
> +#endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */

Jan's suggestion avoids having duplicate headers, and results in less
code overall:

static const struct pci_dev *translate_virtual_device(const struct domain *d,
                                                      pci_sbdf_t *sbdf)
{
#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
    const struct pci_dev *pdev;
    ...
#else /* !CONFIG_HAS_VPCI_GUEST_SUPPORT */
    ASSERT_UNREACHABLE()
#endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */

    return NULL;
}

I've not overly fuzzed either way, but if changes are required you
might as well change to this form.

>  static int vpci_register_cmp(const struct vpci_register *r1,
>                               const struct vpci_register *r2)
>  {
> @@ -438,7 +473,7 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
>      const struct pci_dev *pdev;
>      const struct vpci_register *r;
>      unsigned int data_offset = 0;
> -    uint32_t data = ~(uint32_t)0;
> +    uint32_t data = 0xffffffffU >> (32 - 8 * size);

This seems kind of unrelated to the rest of the code in the patch,
why is this needed?  Isn't it always fine to return all ones, and let
the caller truncate to the required size?

Otherwise the code in vpci_read_hw() also needs to be adjusted.  And
you can likely use GENMASK(size * 8, 0) as it's easier to read.

>  
>      if ( !size )
>      {
> @@ -453,9 +488,21 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
>       * pci_lock is sufficient.
>       */
>      read_lock(&d->pci_lock);
> -    pdev = pci_get_pdev(d, sbdf);
> -    if ( !pdev && is_hardware_domain(d) )
> -        pdev = pci_get_pdev(dom_xen, sbdf);
> +    if ( is_hardware_domain(d) )
> +    {
> +        pdev = pci_get_pdev(d, sbdf);
> +        if ( !pdev )
> +            pdev = pci_get_pdev(dom_xen, sbdf);
> +    }
> +    else
> +    {
> +        pdev = translate_virtual_device(d, &sbdf);
> +        if ( !pdev )
> +        {
> +            read_unlock(&d->pci_lock);
> +            return data;
> +        }

You don't need this checking here, as the check below will already be
enough AFAICT, iow:

    if ( is_hardware_domain(d) )
    {
        pdev = pci_get_pdev(d, sbdf);
        if ( !pdev )
            pdev = pci_get_pdev(dom_xen, sbdf);
    }
    else
        pdev = translate_virtual_device(d, &sbdf);

    if ( !pdev || !pdev->vpci )
    {
        read_unlock(&d->pci_lock);
        return vpci_read_hw(sbdf, reg, size);
    }

Achieves the same and is more compact by having a single return for
all the possible cases?  Same for the write case below.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 11:21:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 11:21:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977076.1364153 (Exim 4.92)
	(envelope-from )
	id 1uCGMt-0001b1-Dq; Tue, 06 May 2025 11:21:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977076.1364153; Tue, 06 May 2025 11: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 1uCGMt-0001au-An; Tue, 06 May 2025 11:21:47 +0000
Received: by outflank-mailman (input) for mailman id 977076;
 Tue, 06 May 2025 11:21:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCGMr-0001ao-Vc
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 11:21:46 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2613::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4a8ec762-2a6c-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 13:21:44 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AM9PR03MB7505.eurprd03.prod.outlook.com
 (2603:10a6:20b:26a::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Tue, 6 May
 2025 11:21:42 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%6]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 11: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" 
X-Inumbo-ID: 4a8ec762-2a6c-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WjwERvgh0zYWf1BggqY3tir3F9hrXvwIuO9xmObWgVFFHW7I+QA9jpG7SxmNWkzYKUXuBD+uF+H3dKLaNC75uWl20KdYZGPjBcHs0SaIFfb+ZT8UZzC7kefLHu9IIh3VjgflY0GgzW7iPuKhWiWdOK/kCQZy0y+ozffLWK9QISkYFr74VzSqrMA4axjj2GrJN8wdKmRpjqSDbIwRocM5t/VgqDr0XD19iSm8VcWERbq3++ByAlgXDmvhOJkl5YRBxmbi1uVnBRFuvbxH1+LlPprubA+RGk+FRsX6g84jAOoR7buM5E92S0CI0ibvhnPcQkXGwkUN+sYiNA/ffNN9oA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=M45di3iSaRMQXjpi/0MmGxQEPbRVX08J3En+WQrth2A=;
 b=GtrZ9Tn0xt3HUWqzP8f9LDYXEFYPSNVkMr2EuwvV6Wme22FUzpGK5lsbrlRCrkvHh2DjcGmwGr9XZs+iKr10kg75pm9bGIZiHtkKfjTW3c2msT+kGap1X4vn0E6u1WYN/OBUNzwYqSxfTfLTMDrZGWR3qZ0nrhzVYVBtlNTtReTcJUJLk0hq0ZaFpTrqiyrN5f0HODASBSzNRo/XEn9jn+CQBRxD9L0vfE5R12isuXQVl4+LASSjnTISbNelYP6AG7sZ0Coi+pU6GrkDtkEPGOowAXMQZiWzT4pLdVIwZDIebwJAiapjbu8CZNWWmqEZ8lAQDCFxoqVbw3uAfkoIpQ==
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=M45di3iSaRMQXjpi/0MmGxQEPbRVX08J3En+WQrth2A=;
 b=EkmUJlgdIxCqtXgVTOzJnmgSaSQJ362m/WSmCQ+7bZ/syW9YPxhc3Z3IEnE+w8nf5HzgKG7K1xS3704+PP+6KhylPi5NRw9rhlTk9wfLJGTCN39V0ZkCesNRygObOUQsuDtg30eNKBWl2XRIgyET+OAldUZsNt+fMbjiLB8Q38d1VorO7vgS02FkalGVXs6FnWsO82J4FD8gt/7Q/Et9b9OIwH71AYxWpGfOWXhQ2WkaEnPwZWbrREn/Pt2b9msWjp1WXn7+OLgNKbB2OTsIeM+x1/j68kESYV8aRgSRz1DeW8OECYqZIu8v5im7n2s3qOKg6/xm8OrnTM1NFJJvhw==
From: Volodymyr Babchuk 
To: "L, John Preetham (893)" 
CC: "xen-devel@lists.xenproject.org" , Ruslan
 Shymkevych 
Subject: Re: Request for Documentation on Bringing Up Xen on R-Car H3e
 (H3ULCB)
Thread-Topic: Request for Documentation on Bringing Up Xen on R-Car H3e
 (H3ULCB)
Thread-Index: AdtsrjaU74AF3fZpR/+NK9h56D1xZg==
Date: Tue, 6 May 2025 11:21:42 +0000
Message-ID: <87v7qec7cr.fsf@epam.com>
References:
 
	<8734ha2evr.fsf@epam.com>
	
	<87ldv0248u.fsf@epam.com>
	
In-Reply-To:
 
	(John Preetham L.'s message of "Mon, 5 May 2025 04:25:23 +0000")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|AM9PR03MB7505:EE_
x-ms-office365-filtering-correlation-id: a9556a80-dee2-45b0-f97e-08dd8c902d9d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?aNO2k1fg6VLzUgMSYtIvO+X2kMQGsQ4YXRllRMcCmRcZAiaY/p3Mc5MD1O?=
 =?iso-8859-1?Q?bx7SI9HysKpjJt7sbtz1vHlSM7hWcflkRcyDH6BirWLaAYrUvwg9LsXmTo?=
 =?iso-8859-1?Q?+k5WVx6eeR3sGBKKq0RurH5rtBHuuz0XNYiqyuIrb/aGFvmAnVQGOkkTy2?=
 =?iso-8859-1?Q?pkZDxQosPUEZHuCfpPLeBuZnTFcxFVTiELUFrj9wdbIdi1y2s/FkK6Uwah?=
 =?iso-8859-1?Q?utPVMsLoJBK0xgvoRZ72t7JOzB4ilNa2ddb7foDL10rNXQSPWmeQumEd8G?=
 =?iso-8859-1?Q?gKtwzvZYadM4Gp2NMdvdNnb7tkes/NJ9kLOSmEl40lC+LnIp8tY1QGw1x0?=
 =?iso-8859-1?Q?6d9e+Vme90vBfesMXxM0DIPeZx5oKThIPt2jzyEa7dBDVtL4xthNR1P7m7?=
 =?iso-8859-1?Q?0zJzdN9+khumwlVwGUVMt7GeAaA/cVDIp9LhqJtTINEQ7FaIWwPjrrhDDT?=
 =?iso-8859-1?Q?zWl/Q5J10afASMT88hCiQVQcd7AOmVd4MiNjN1o60pWziqX7xmqJOT5mJd?=
 =?iso-8859-1?Q?tvFPPw8ftz/GvxphQpbOKussKIdYWI7pVmc1jR2G8fGvrGKc3z5ksKTCTm?=
 =?iso-8859-1?Q?ZcuzUUXMJZ2TsMZslRjIRAAawaNJgAgmZBo7a/Y/Wa3VQrbvJD/mmBXkbG?=
 =?iso-8859-1?Q?KdCn5JkpmBNgbAXDyl+DHYelanG3yebb/qR9BRQI0LOP+um6xylSIiEYVp?=
 =?iso-8859-1?Q?82A8Yh7IptyQNOUBvh9BQ8cpG/iYrvii0gSwjbqfXSUEoinujjjhnzzONE?=
 =?iso-8859-1?Q?pSI8QsRzncAio4PO/svFApXPe0mj9E7VqoscCoM9z/qvFIF150H8gl1BnS?=
 =?iso-8859-1?Q?NnOpL4Rv4hIvsR5M6eBv+8u+CQwJ9WNVQMHMDba47cFB1FNAYVQun/ZBh/?=
 =?iso-8859-1?Q?BXGbWYlC/kClHBDAWkaUU506RXvh0J97ZuBxxqoINlsFP3SZQHTnT4JTVC?=
 =?iso-8859-1?Q?sg2uRzgVsQ5meRa5iBL/HZWZf8jr8SN8d1QWHaZPU1q/3SyC0xN8Onv99p?=
 =?iso-8859-1?Q?ZPGfL1jFEjnGda2hFZNwtJ1Szd3y3wS3ch+IYw74vgUmbZx4uenPg1lCFM?=
 =?iso-8859-1?Q?XGVVzcEM1JmnAG2BfgpVUsD06XOZDid9jTVY1Y+Zog1SpY76h06n9jz0J4?=
 =?iso-8859-1?Q?s6gnFZx8AByUpnWmb6ieyPQPZhzrT9xKb2aUNBWXCK5v57T6SUisMVSBwb?=
 =?iso-8859-1?Q?1LtvX4BrPMEJ0yKRH6cQkGqbQCPJ3rJutjXVEC+P31f/LUIEJqb0B1v+Ol?=
 =?iso-8859-1?Q?il0gaxbPCTk/ch+fkYWOAfNGpnEfIw6LrIyjldDq4gWb+t644kxULvEev5?=
 =?iso-8859-1?Q?W3kdpXWPBt52TmCzZfkZ7OmGEvBBnq2nRFloKMOG1YdIeNTAtPMzbXYnkK?=
 =?iso-8859-1?Q?fDQwql4KVrkPph89aEO1b9soX4jhp1vYLRgBwI8lp3SupikkXm3GsxcF36?=
 =?iso-8859-1?Q?rNargdyOXimAKGZfOHJ7j+H5I6RMMfWQrSorSyDip0bl/IslDC0wMEXPFp?=
 =?iso-8859-1?Q?o=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?qRNqAe3Z/VE/gBnYb/hCvtvpcCP1yzN+LvP959q9E2eu4opkNdW0zg45m3?=
 =?iso-8859-1?Q?FUl+Th0EoIY6fmA7FY+Of7cEbILZJGmm7xwTnC+NdMH53qa7qrWbfdKk5p?=
 =?iso-8859-1?Q?53KsuZrSIdSGEQAllvgjGeqr2TGNDIR4wivEG6Hwg7uBR2aZvIbgXC/Wck?=
 =?iso-8859-1?Q?tj86wIoqVbFqUgbrs6p6uE2NXQ0Mm0mI4V0uB8ijWKZJCXPagHkVBiBBL8?=
 =?iso-8859-1?Q?es4tk+iWvBrR7RBv/cI524t2/g9IJDT1d0wU7bdU4+jk5QsLjszNNqJk/7?=
 =?iso-8859-1?Q?qVQm5xgV/E1GLhc2RwpMLRJNLU3gZhz25xZbO/vPxcrx3T+Qitfolm6qod?=
 =?iso-8859-1?Q?JeC7T+5Apar14WUJTenV9OnPoc/KSlpjEwYrkqMYVole26yf4lbNB3KXDi?=
 =?iso-8859-1?Q?maRUpPAPj8GzfbzgGbpmhvz1XWYZfVNJpmj5zG7h8ot7uVvTaCe5BKwQao?=
 =?iso-8859-1?Q?3E/2huFy0q3wJrVdwyHrJ/miIKfQ690BcHCpRydQwYknvt/xITUpR9H7Zq?=
 =?iso-8859-1?Q?6yaV76xPmqE0z8Nh68tjllgbCBl9o0DEVUx/3dUsjKzEw2SIrMT6nD7jpY?=
 =?iso-8859-1?Q?PzVCULYaxQqKlE5J3oJpzgl7cL2CjAUGkALYLXwwxEHhoeWADdzSibkiti?=
 =?iso-8859-1?Q?hW6y3F6c3kqrY8Aq9GlhEUbuhGLAg6PKVDFr95xkCXzpYRUJCaDvDOQgnK?=
 =?iso-8859-1?Q?6eaAjr1IWizGHxSt+fwWrHBN16F6cJE8Wz0I8BFe+F3EPkBtXAuA0aupYe?=
 =?iso-8859-1?Q?giEWKdtMF+tKjcTcfvSeBRJctPqjPOYtne6IE4iuvvxaEcyGYfCPg3zL5Q?=
 =?iso-8859-1?Q?+LlQ/rSDQ6PgbSaXtK3MwoJB9dLZU+JAdxP9UEtFlaXjfTQyTrcE9scoVV?=
 =?iso-8859-1?Q?OJvZ2KQwX+dyDFvH3xaG0e8XQsiocvyu31PpdGPafgGDyvSUk+ZuRU2ywP?=
 =?iso-8859-1?Q?hxgedtzOqrr7PHncn/EeL6BpR4m/PpyF/0rk69UTTlfXyCdilElmWtlgtt?=
 =?iso-8859-1?Q?OejrArWrIC6ji2tc/TOAc6KC4sDqsYQdjhtexWxd2tW/LK8zLoo2oLLhPS?=
 =?iso-8859-1?Q?7u4SaZM5x6Hugn/8idY01qO8GZp5rAxyzJJxPFhxDXvip9Z9QwoaswJOQn?=
 =?iso-8859-1?Q?wHeeuzqKaaSczKrHsHjpGKvqXY/HO2H7cvbK0GIZs+0JNG0jo4Ufz6cgKs?=
 =?iso-8859-1?Q?Pu4BxfL1UuUsvlC0/Otk/WI6XktjR3dF+T6im3rvuTGOvqfwaaxfhZkt45?=
 =?iso-8859-1?Q?HF+bTOU8WhUP4hgzoruiLJbBexiZFL6UAX4GQnisUlv6aCgWGFW15qQXp8?=
 =?iso-8859-1?Q?FJM1CXZnL4xtcYT5d3J49EZo+ywdkr9IfX/D50305riDRdxJx8eQDNLgKT?=
 =?iso-8859-1?Q?FsH8lEHYlExyZc7/4iiIgEsniXm1x67vMSCUdKrTrZmTyK+06gdgHQIz4Q?=
 =?iso-8859-1?Q?fI2+PI732mjX39sF5yuN1lfeZtlpp2Q5wp7wTq6Ayr0qahs/shloYidNXl?=
 =?iso-8859-1?Q?5tD1K37jrGIRZ/Vt6+b5enCUnZMfV56L/Mg4rdWKZeUNWYyT1qmTjQZ6e0?=
 =?iso-8859-1?Q?dOQLEhCCWqzAz2axJ184+2Wrrdi4G1jAaMQBz/bNQ1ugrkyTuZvoGWoitV?=
 =?iso-8859-1?Q?fR9jVcX7k20yhkyN01Un5PGAU0bAdrkEFlAg9rAsqN2lJhWkCqp7iKLw?=
 =?iso-8859-1?Q?=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: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a9556a80-dee2-45b0-f97e-08dd8c902d9d
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2025 11:21:42.4938
 (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: rn/SbznHtrbRnYseiqTzwFHVuFzT/sgSe4BHwwc2690TSeKYWejNuuO24bH6d2mgRHnOpezxSk5sy1wQz55DXlnnQ7ZlhIPEQE/YfSjCbWg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB7505


Hi John,

"L, John Preetham (893)"  writes:

> Hi Volodymyr,
>
> Thank you once again for the detailed explanation and the helpful resourc=
es.
>
> With your guidance, I was able to bring up the XEN hypervisor on the R-Ca=
r H3e board successfully. I really appreciate your support.
>

I glad that it worked.

> Now, I'm looking to move forward with bringing up a QNX guest on the
> XEN hypervisor.

If your QNX guest supports arm64 boot protocol (which is defined at [1])
and supports either Xen HVC console or SBSA (pl011-ish) UART - you can just
boot it by providing kernel=3D option in your domain configuration file.

This at least should give you access to guest's serial console, which is
a good starting point to further bring-up.

> Could you please share the procedure or steps you
> recommend for this?

If I'd did this, I'd done this in the following way:

1. Check that QNX kernel image is compatible with aarch64 boot
protocol. Most of projects (Linux kernel, Xen, U-boot, etc) use it and
it become de-facto standard, so probably QNX should support it too. But
if not - you'll need another loader to boot QNX. We have Xen-enabled
U-Boot, by the way.

2. Boot QNX kernel and get serial console working. As I said, - either via
HVC or SBSA. This is crucial, as you need some feedback from your guest
to understand what going on.

3. Boot rest of QNX environment. See what is working, fix things that
don't :) It would be great if QNX supports Xen PV drivers for block
and network devices, otherwise, you'll have to use virtio or
pass-through, which is somewhat more difficult to configure.

> It would also be very helpful if you could provide
> an example Device Tree Source (DTS) and

If you are not doing real device passthrough (and I recommend to
postpone this until you'll get your guest running) - you don't need any
DTS files. Xen toolstack will generate all the required DTS entries
automatically for the given configuration.

> XEN domain configuration (CFG)
> file for the QNX guest, if available.

No, we don't have any. We had experience with QNX guests, but that was
really long time ago and I don't think that any data survived. Anyways,
I recommend checking manual on xl.cfg ([2]).

Please note, that if you want to use SBSA uart, you need to enable it in
your configuration file. It should be vuart =3D "sbsa_uart", I
believe. Also, you'll have to run xl console with additional arguments
to make it access SBSA uart console, not default HVC one.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree=
/Documentation/arch/arm64/booting.rst?h=3Dv6.15-rc5
[2] https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Tue May 06 11:44:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 11:44:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977094.1364163 (Exim 4.92)
	(envelope-from )
	id 1uCGik-0005Lf-A6; Tue, 06 May 2025 11:44:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977094.1364163; Tue, 06 May 2025 11:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCGik-0005LY-7N; Tue, 06 May 2025 11:44:22 +0000
Received: by outflank-mailman (input) for mailman id 977094;
 Tue, 06 May 2025 11:44:21 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uCGii-0005LQ-Uo
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 11:44:20 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uCGii-00Cel4-1J;
 Tue, 06 May 2025 11:44:20 +0000
Received: from [2a02:8012:3a1:0:7157:32ca:2aea:33a3]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uCGii-00HKtH-0a;
 Tue, 06 May 2025 11:44:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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=D3rPs2AkxDjMQf7Y9znqArR1fSXVuekCPjEXbZee/1U=; b=In5Qey0A/ex62MOGgH93hjTJzf
	M1DLbNdD5TDCWs/3JNhMfBgpgwgC736I/NLwXNumeMTA2FCz30JALkY8bZI4KHRQDf7GRT3AmIycU
	5BbdDsM/QZM/8o936YINM+46nupiTfO7U8pSGYLRdz2ogIpY4m2yGHEXr0A6whkWDId8=;
Message-ID: 
Date: Tue, 6 May 2025 12:44:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/7] docs/arm: Document Xen booting protocol on Armv8-R
Content-Language: en-GB
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-2-luca.fancellu@arm.com>
From: Julien Grall 
In-Reply-To: <20250429152057.2380536-2-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 29/04/2025 16:20, Luca Fancellu wrote:
> Document the requirement needed to boot Xen on Armv8-R platforms.
> 
> Signed-off-by: Luca Fancellu 
> ---
> v4 changes:
>   - New patch
> ---
>   docs/misc/arm/booting.txt | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
> index 21ae74837dcc..719af74f1e69 100644
> --- a/docs/misc/arm/booting.txt
> +++ b/docs/misc/arm/booting.txt
> @@ -62,6 +62,14 @@ Xen relies on some settings the firmware has to configure in EL3 before starting
>   
>   * The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1.
>   
> +When Xen runs on Armv8-R, the highest exception level is EL2 and the only
> +available state is secure (S) on Arm64 and non secure (NS) on Arm32, hence the
> +above requirements need to be adjusted to this case:
 > +> +* Xen must be entered in S EL2 mode on Arm64 and in NS EL2 mode 
on Arm32.

I think it would be better to update the line "Xen must be entered in NS 
EL2 mode" to clarify the state for 64-bit Arm.

 > +> +* Xen must be entered with MPU off and data cache disabled 
(SCTLR_EL2.M bit and
> +  SCTLR_EL2.C set to 0).

This line is valid for Armv8-A/Armv7-A when using the Image/zImage protocol.

>   
>   [1] linux/Documentation/arm/booting.rst
>   Latest version: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arch/arm/booting.rst

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue May 06 11:50:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 11:50:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977105.1364173 (Exim 4.92)
	(envelope-from )
	id 1uCGoo-0006u2-UT; Tue, 06 May 2025 11:50:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977105.1364173; Tue, 06 May 2025 11:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCGoo-0006tU-QA; Tue, 06 May 2025 11:50:38 +0000
Received: by outflank-mailman (input) for mailman id 977105;
 Tue, 06 May 2025 11:50:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uCGon-0006rk-6Z
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 11:50:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uCGom-00Cev0-2Q;
 Tue, 06 May 2025 11:50:36 +0000
Received: from [2a02:8012:3a1:0:7157:32ca:2aea:33a3]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uCGom-00HQf8-1u;
 Tue, 06 May 2025 11:50: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=hUm4V1VJtY8bczQ2XY/vIcjHvWnQG7osgCGsS9uiIb4=; b=Wn58r2j2i6E1UQWm5k9nm5GhgR
	ivbfx0qgMp0faHcUScNwNWAW8jq9pvuj3AKOoCwldu5MOOXivpqyUdhLHONSIMKu06jqYPxHtUcM2
	+BeO65qqaqu9V7FAMYIZank+3MzOcmW0r4ucTvOhK/ndZrFST05kuYkCgtXyK21Z0x4Q=;
Message-ID: 
Date: Tue, 6 May 2025 12:50:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 2/7] arm/mpu: Introduce MPU memory region map structure
Content-Language: en-GB
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Penny Zheng ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk , Wei Chen 
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-3-luca.fancellu@arm.com>
From: Julien Grall 
In-Reply-To: <20250429152057.2380536-3-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 29/04/2025 16:20, Luca Fancellu wrote:
> From: Penny Zheng 
> 
> Introduce pr_t typedef which is a structure having the prbar
> and prlar members, each being structured as the registers of
> the aarch64 armv8-r architecture.

Typo: AArch64 Armv8-R

> 
> Signed-off-by: Penny Zheng 
> Signed-off-by: Wei Chen 
> Signed-off-by: Luca Fancellu 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue May 06 12:23:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 12:23:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977121.1364183 (Exim 4.92)
	(envelope-from )
	id 1uCHKB-0003Ge-C9; Tue, 06 May 2025 12:23:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977121.1364183; Tue, 06 May 2025 12: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 1uCHKB-0003GX-8G; Tue, 06 May 2025 12:23:03 +0000
Received: by outflank-mailman (input) for mailman id 977121;
 Tue, 06 May 2025 12:23:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCHKA-0003EX-5P
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 12:23:02 +0000
Received: from mail.actia.se (mail.actia.se [212.181.117.226])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d73b14ad-2a74-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 14:22:56 +0200 (CEST)
Received: from S036ANL.actianordic.se (10.12.31.117) by S036ANL.actianordic.se
 (10.12.31.117) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 May
 2025 14:22:55 +0200
Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by
 S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%3]) with mapi id
 15.01.2507.039; Tue, 6 May 2025 14:22:55 +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" 
X-Inumbo-ID: d73b14ad-2a74-11f0-9ffb-bf95429c2676
From: John Ernberg 
To: Stefano Stabellini 
CC: Juergen Gross , Oleksandr Tyshchenko
	, Catalin Marinas ,
	Andrew Morton , "xen-devel@lists.xenproject.org"
	, "iommu@lists.linux.dev"
	, "linux-kernel@vger.kernel.org"
	, "imx@lists.linux.dev" ,
	Christoph Hellwig 
Subject: Re: [PATCH 2/2] xen: swiotlb: Implement map_resource callback
Thread-Topic: [PATCH 2/2] xen: swiotlb: Implement map_resource callback
Thread-Index: AQHbu1cR+sKkXAZoXEOAUfrcrER157O/dMAAgAX2O4A=
Date: Tue, 6 May 2025 12:22:55 +0000
Message-ID: <75266eb7-66a4-4477-ae8a-cbd1ebbee8db@actia.se>
References: <20250502114043.1968976-1-john.ernberg@actia.se>
 <20250502114043.1968976-3-john.ernberg@actia.se>
 
In-Reply-To: 
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.12.12.35]
x-esetresult: clean, is OK
x-esetid: 37303A2955B14453667060
Content-Type: text/plain; charset="utf-8"
Content-ID: <3E994E23DDFC0E4EB8666504990A79B4@actia.se>
Content-Transfer-Encoding: base64
MIME-Version: 1.0

SGkgU3RlZmFubywNCg0KT24gNS8yLzI1IDc6MjAgUE0sIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90
ZToNCj4gK0NocmlzdG9waA0KPiANCj4gT24gRnJpLCAyIE1heSAyMDI1LCBKb2huIEVybmJlcmcg
d3JvdGU6DQo+PiBOZWVkZWQgYnkgdGhlIGVETUEgdjMgRE1BIGVuZ2luZSBmb3VuZCBpbiBpb21t
dS1sZXNzIFNvQ3Mgc3VjaCBhcyBpTVg4UVhQDQo+PiB0byBiZSBhYmxlIHRvIHBlcmZvcm0gRE1B
IG9wZXJhdGlvbnMgYXMgYSBYZW4gSGFyZHdhcmUgRG9tYWluLCB3aGljaCBuZWVkcw0KPj4gdG8g
YmUgYWJsZSB0byBkbyBETUEgaW4gTU1JTyBzcGFjZS4NCg0KU2VsZi1ub3RlOiBUaGUgYWJvdmUg
cGFydCBvZiB0aGUgY29tbWl0IG1lc3NhZ2UgaXMgYSBkaXNhc3RlciBhbmQgc2hvdWxkIA0KcmVh
ZCBzb21ldGhpbmcgbGlrZS4NCg0KTmVlZGVkIGJ5IFNvQ3Mgd2l0aG91dCBhbiBpb21tdSAoc3Vj
aCBhcyB0aGUgaU1YOFFYUCBhbmQgaXQncyBlRE1BIHYzIA0KZW5naW5lKSB0aGF0IG5lZWQgdG8g
YmUgYWJsZSB0byBwZXJmb3JtIERNQSBvcGVyYXRpb25zIGluIE1NSU8gc3BhY2UuDQoNCj4+DQo+
PiBUaGUgY2FsbGJhY2sgaW1wbGVtZW50YXRpb24gaXMgYmFzaWNhbGx5IHRoZSBzYW1lIGFzIHRo
ZSBvbmUgZm9yIGRpcmVjdA0KPj4gbWFwcGluZyBvZiByZXNvdXJjZXMsIGV4Y2VwdCB0aGlzIGFs
c28gdGFrZXMgaW50byBhY2NvdW50IFhlbiBwYWdlDQo+PiBtYXBwaW5ncy4NCj4+DQo+PiBUaGVy
ZSBpcyBub3RoaW5nIHRvIGRvIGZvciB1bm1hcCwganVzdCBsaWtlIHdpdGggZGlyZWN0LCBzbyB0
aGUgdW5tYXANCj4+IGNhbGxiYWNrIGlzIG5vdCBuZWVkZWQuDQo+Pg0KPj4gU2lnbmVkLW9mZi1i
eTogSm9obiBFcm5iZXJnIDxqb2huLmVybmJlcmdAYWN0aWEuc2U+DQo+Pg0KPj4gLS0tDQo+Pg0K
Pj4gSSBvcmlnaW5hbGx5IGV4cG9ydGVkIGRtYV9kaXJlY3RfbWFwX3Jlc291cmNlKCkgYW5kIHVz
ZWQgdGhhdCB3aGljaA0KPj4gYXBwZWFyZWQgdG8gd29yaywgYnV0IGl0IGZlbHQgbGlrZSBub3Qg
Y2hlY2tpbmcgWGVuIHBhZ2UgbWFwcGluZ3Mgd2Fzbid0DQo+PiBmdWxseSBjb3JyZWN0IGFuZCBJ
IHdlbnQgd2l0aCB0aGlzLiBCdXQgaWYgZG1hX2RpcmVjdF9tYXBfcmVzb3VyY2UoKSBpcw0KPj4g
dGhlIGNvcnJlY3QgYXBwcm9hY2ggaGVyZSB0aGVuIEkgY2FuIHN1Ym1pdCB0aGF0IGlzbnRlYWQu
DQo+PiAtLS0NCj4+ICAgZHJpdmVycy94ZW4vc3dpb3RsYi14ZW4uYyB8IDE1ICsrKysrKysrKysr
KysrKw0KPj4gICAxIGZpbGUgY2hhbmdlZCwgMTUgaW5zZXJ0aW9ucygrKQ0KPj4NCj4+IGRpZmYg
LS1naXQgYS9kcml2ZXJzL3hlbi9zd2lvdGxiLXhlbi5jIGIvZHJpdmVycy94ZW4vc3dpb3RsYi14
ZW4uYw0KPj4gaW5kZXggZWY1NmEyNTAwZWQ2Li4wZjAyZmRkOTEyOGQgMTAwNjQ0DQo+PiAtLS0g
YS9kcml2ZXJzL3hlbi9zd2lvdGxiLXhlbi5jDQo+PiArKysgYi9kcml2ZXJzL3hlbi9zd2lvdGxi
LXhlbi5jDQo+PiBAQCAtMjg1LDYgKzI4NSwyMCBAQCBzdGF0aWMgdm9pZCB4ZW5fc3dpb3RsYl91
bm1hcF9wYWdlKHN0cnVjdCBkZXZpY2UgKmh3ZGV2LCBkbWFfYWRkcl90IGRldl9hZGRyLA0KPj4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXR0cnMsIHBvb2wpOw0K
Pj4gICB9DQo+Pg0KPj4gK3N0YXRpYyBkbWFfYWRkcl90IHhlbl9zd2lvdGxiX21hcF9yZXNvdXJj
ZShzdHJ1Y3QgZGV2aWNlICpkZXYsIHBoeXNfYWRkcl90IHBoeXMsDQo+PiArICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemVfdCBzaXplLCBlbnVtIGRtYV9kYXRhX2Rp
cmVjdGlvbiBkaXIsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHVuc2lnbmVkIGxvbmcgYXR0cnMpDQo+PiArew0KPj4gKyAgICAgZG1hX2FkZHJfdCBkZXZfYWRk
ciA9IHhlbl9waHlzX3RvX2RtYShkZXYsIHBoeXMpOw0KPiANCj4gWWVzLCB3ZSBuZWVkIHRoZSB4
ZW5fcGh5c190b19kbWEgY2FsbCBoZXJlLiBUaGlzIGlzIG9uZSBvZiB0aGUgcmVhc29ucyBJDQo+
IGRvbid0IHRoaW5rIHdlIGNhbiB1c2UgZG1hX2RpcmVjdF9tYXBfcmVzb3VyY2UoKSB0byBpbXBs
ZW1lbnQNCj4gbWFwX3Jlc291cmNlDQo+IA0KPiANCj4+ICsgICAgIEJVR19PTihkaXIgPT0gRE1B
X05PTkUpOw0KPj4gKw0KPj4gKyAgICAgaWYgKCFkbWFfY2FwYWJsZShkZXYsIGRldl9hZGRyLCBz
aXplLCBmYWxzZSkpDQo+PiArICAgICAgICAgICAgIHJldHVybiBETUFfTUFQUElOR19FUlJPUjsN
Cj4gDQo+IEJ1dCBoZXJlIHlvdSBhbHNvIG5lZWQgdG8gY2hlY2sgdGhhdCBwaHlzK3NpemUgZG9l
c24ndCBjcm9zcyBhIHBhZ2UNCj4gYm91bmRhcnkuIFlvdSBuZWVkIHRvIGNhbGwgcmFuZ2Vfc3Ry
YWRkbGVzX3BhZ2VfYm91bmRhcnksIGxpa2Ugd2UgZG8gYXQNCj4gdGhlIGJlZ2lubmluZyBvZiB4
ZW5fc3dpb3RsYl9tYXBfcGFnZS4NCj4gDQo+IElmIGl0IGlzIHBvc3NpYmxlIHRvIGNyb3NzIGEg
cGFnZSBib3VuZGFyeSwgdGhlbiB3ZSBuZWVkIHRvIGJhc2ljYWxseSB0bw0KPiBkbyB0aGUgc2Ft
ZSB0aGluZyBoZXJlIGFzIHdlIGRvIGluIHhlbl9zd2lvdGxiX21hcF9wYWdlIHdoZXJlIHdlIGNo
ZWNrDQo+IGZvcjoNCj4gDQo+ICAgICAgICAgIGlmIChkbWFfY2FwYWJsZShkZXYsIGRldl9hZGRy
LCBzaXplLCB0cnVlKSAmJg0KPiAgICAgICAgICAgICAgIXJhbmdlX3N0cmFkZGxlc19wYWdlX2Jv
dW5kYXJ5KHBoeXMsIHNpemUpICYmDQo+ICAgICAgICAgICAgICAgICAgIXhlbl9hcmNoX25lZWRf
c3dpb3RsYihkZXYsIHBoeXMsIGRldl9hZGRyKSAmJg0KPiAgICAgICAgICAgICAgICAgICFpc19z
d2lvdGxiX2ZvcmNlX2JvdW5jZShkZXYpKQ0KPiAgICAgICAgICAgICAgICAgIGdvdG8gZG9uZTsN
Cj4gDQo+IGlmIGFsbCBpcyB3ZWxsLCB3ZSBnbyB3aXRoIHRoZSBuYXRpdmUgcGF0aCwgb3RoZXJ3
aXNlIHdlIGJvdW5jZSBvbg0KPiBzd2lvdGxiLXhlbi4NCj4gDQoNCkknbGwgcHJlZmFjZSB0aGlz
IHdpdGggdGhhdCBpdCdzIG15IGZpcnN0IGRlZXAgZGl2ZSBpbiBETUEsIHNvIHRoZSANCmZvbGxv
d2luZyBtYXkgZW50aXJlbHkgYmUgbWUgYmVpbmcgc3R1cGlkOg0KDQpJJ20gbm90IHN1cmUgYSBz
dHJhZGRsZXMgcGFnZSBib3VuZGFyeSBwYXRoIG1ha2VzIHNlbnNlLg0KDQpUaGlzIG1hcHBpbmcg
aXMgbm90IGZvciBhIFJBTSBiYWNrZWQgYWRkcmVzcy4gSW4gdGhlIGVETUEgY2FzZSBmb3IgdGhl
IA0KaU1YOFFYUCB0aGUgYHBoeXNgIGNvbWluZyBpbiBoZXJlIGlzIHRoZSBhZGRyZXNzIG9mIGEg
cmVnaXN0ZXIuIEkgY2Fubm90IA0Kc2VlIGhvdyBhIHN3aW90bGIgYm91bmNlIHdvdWxkIGZpeCBh
bnl0aGluZyBpZiB5b3UgZW5kIHVwIHN0cmFkZGxpbmcgYSANCnBhZ2UgYm91bmRhcnkuIEF0IG1v
c3QgSSBjYW4gc2VlIGEgV0FSTl9PTiB3aXRoIGEgRE1BX01BUFBJTkdfRVJST1IgDQpyZXR1cm4g
aWYgc3VjaCBhIGNoZWNrIHdvdWxkIHlpZWxkIHRydWUuDQoNCkxldCdzIHNheSB5b3Ugd2FudCB0
byBkbyBhIERFVl9UT19NRU0gYW5kIGEgY2hlY2sgZGVjaWRlcyB5b3UgbmVlZCB0byANCmJvdW5j
ZSBpdCB5b3UnZCBib3VuY2UgYW4gUlggcmVnaXN0ZXIgYWRkcmVzcy4gSSBjYW5ub3Qgc2VlIGhv
dyB0aGF0IERNQSANCndvdWxkIGV2ZXIgZW5kIHVwIGRvaW5nIHRoZSBleHBlY3RlZCB0aGluZy4N
Cg0KVGhlIGVETUEgZW5naW5lIHdpbGwgbWFuYWdlIHRoZSBSWC9UWCByZWdpc3RlcnMgZm9yIGFu
IElQIGJsb2NrIGFuZCBtb3ZlIA0KdGhlIGRhdGEgYmV0d2VlbiB0aGVtIGFuZCBSQU0sIHdoZXJl
IHRoZSBSQU0gbWVtb3J5IGlzIG1hcHBlZCBzZXBhcmF0ZWx5IA0KYnkgZG1hX21hcF9wYWdlIChh
bmQgZmFtaWx5KS4gQW5kIHRoZXNlIGNhbiBiZSBzd2lvdGxiIGJvdW5jZWQgdmlhIHRoZSANCm1h
cCBwYWdlIGNhbGxiYWNrIHdpdGggbm8gcHJvYmxlbS4NCg0KQmVzdCByZWdhcmRzIC8vIEpvaG4g
RXJuYmVyZw==


From xen-devel-bounces@lists.xenproject.org Tue May 06 12:25:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 12:25:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977131.1364194 (Exim 4.92)
	(envelope-from )
	id 1uCHMc-0003n0-O4; Tue, 06 May 2025 12:25:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977131.1364194; Tue, 06 May 2025 12: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 1uCHMc-0003mt-Jo; Tue, 06 May 2025 12:25:34 +0000
Received: by outflank-mailman (input) for mailman id 977131;
 Tue, 06 May 2025 12:25:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCHMa-0003mj-VY
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 12:25:33 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20608.outbound.protection.outlook.com
 [2a01:111:f403:2612::608])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2fb414f4-2a75-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 14:25:25 +0200 (CEST)
Received: from AM0PR02CA0182.eurprd02.prod.outlook.com (2603:10a6:20b:28e::19)
 by DB3PR08MB8892.eurprd08.prod.outlook.com (2603:10a6:10:43d::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Tue, 6 May
 2025 12:25:22 +0000
Received: from AM4PEPF00027A65.eurprd04.prod.outlook.com
 (2603:10a6:20b:28e:cafe::5) by AM0PR02CA0182.outlook.office365.com
 (2603:10a6:20b:28e::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.29 via Frontend Transport; Tue,
 6 May 2025 12:25:22 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM4PEPF00027A65.mail.protection.outlook.com (10.167.16.86) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.18
 via Frontend Transport; Tue, 6 May 2025 12:25:22 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 AS2PR08MB10084.eurprd08.prod.outlook.com (2603:10a6:20b:648::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Tue, 6 May
 2025 12:24:49 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 12:24: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" 
X-Inumbo-ID: 2fb414f4-2a75-11f0-9ffb-bf95429c2676
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=oblvwEVcl6nHCQ/v25RAPJ8iUm1TZHtkh9Zyrd3T9U6//bLiY4FfKYgoADqi0wrwpEyD4tuIP88iIinP61B9LMPqApEWgHIGyM3ZTcnvFMFkP6A8OuzmA9YNnUtq6n5nb7X2qqAxBsjWdD+0EIwBmFfORLl0Xosz3KL1NqyMyvsM1TqENy0IUX6SY3RCXXC8UGsgaVLvDpNOfHG9XGT51FNhA4/WjmMD9HVptWFjrdIOGKYGDF5PuHyRelN+UkQKz6mynzBupdkATvuqdYMb38gmw7H2FxoNQRnbbMBLNbDT+c6dY6xaGuXqZOejF+ijIajaAai5GXP+GkWfxjo0cg==
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=RXQ13MP1qQOUxa75Dmjwu+oy1XGll8PGOuytf9nVLPc=;
 b=eBlFM23ThWDDLiMP5HfL3knTAu2qIMeUvHc62wduudmkGbqPWrPYrwwPMJ3TG4tA65zsn3lNMavglSyyeOTyeM9QgPLNxyygpXkhBoU48PLXKVlfvWXxOrNO6XFKMDkYhzSWsXYobEgqFbr9R63Yk1WEO8PWbH5sUZvw6JRQLulvGf68TjSjms76BgH1pYgLbZeICKdh+4J8sHNURwZJO7vs1UM7tuJHc0mv8SwDBkI/koLUmLW4ZrnY3JEF/YQal9AgM4sssf8kdOgqGy1fLA46Zyshxt93r9GqybcIDmHIbyoLITjM8pPOiPBScB8ejlkBQklAAFXi9iCgdnzmNA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=xen.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=RXQ13MP1qQOUxa75Dmjwu+oy1XGll8PGOuytf9nVLPc=;
 b=rSvsp0nqZOy9FrMgUzl3yjKarz7NIL/PiqnAT+f0rlRL0+UEPU4dlhKP1eCSorrW862BNmQAHMD1csvS1PDrpZ/eTvfjHAHKCC/Uxr9xxSLZQUPvAVaNgrIeyLdxA4UbTmSo9NaTZpiHMb4PTdZrgAgkS+lyVPwcK7Q1F/N5Mb0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Q6j5Fx8Z41oEw56EiH/o9ZMr2iE30X63e9oo0VO3MIpH18zDDV/BFAbjWtcz31uTGFR/Sit6Ktku3f0cGZKoCn7uCeZ+i3L7TCNmvl6j2fdO2d5/guFXaHu9a2CiXqLGShfxT9Kr1C6PxD9UyyD1cFFo+tavNdu2TclIgPqbdMLDl26uDg463aGfOTluIJZI2GSr+LO+zKixopAN5lgH59eHGvTeFxe+O7HZbys+SrQOnffIiI1Ohrk+C2HTdEEpHwdsW2vceTjSgZNkjXSuntOjcDt3qYv/UEQlkr0tqxeuYJq4dqTGUtTepGHr7dRXpTMddPMf1UJ7aANtt9YpFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RXQ13MP1qQOUxa75Dmjwu+oy1XGll8PGOuytf9nVLPc=;
 b=l1w5Yrrf97WTmn2aXssFgyEJDFWzXmmwBs+v2j8MU+Zu/BQJut8VpyUVVjtyGnAZZtdv5h6SnKLC0OETbmatVmBBVCORW4mLPEac+nQ7aKbd7qfN6Sdsb3+NUZGCZIVWGVyeA26YowsQ3YEyATz5NMgzLsyM8FsTs7yUg+FuB3Ye/hcHGf1U80Tq5rMixkNDYeTxMsciXZbUOrfj129GOUzGtmv0xcobXlaXPXDVh1zmErDF4hHgT5AYdD3xTw6nqm71rVT/5CcvOj1+cTHz1eWCgfIY2yml9k5IhyvhT2rpIF9QYwUccx+EtSGvPOovsBP1kZ6qaZ03tsF8wN9ZDw==
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=RXQ13MP1qQOUxa75Dmjwu+oy1XGll8PGOuytf9nVLPc=;
 b=rSvsp0nqZOy9FrMgUzl3yjKarz7NIL/PiqnAT+f0rlRL0+UEPU4dlhKP1eCSorrW862BNmQAHMD1csvS1PDrpZ/eTvfjHAHKCC/Uxr9xxSLZQUPvAVaNgrIeyLdxA4UbTmSo9NaTZpiHMb4PTdZrgAgkS+lyVPwcK7Q1F/N5Mb0=
From: Luca Fancellu 
To: Julien Grall 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: Re: [PATCH v4 1/7] docs/arm: Document Xen booting protocol on Armv8-R
Thread-Topic: [PATCH v4 1/7] docs/arm: Document Xen booting protocol on
 Armv8-R
Thread-Index: AQHbuRpmN9lJogKQoUiVWa6WakCsQrPFhjEAgAALLQA=
Date: Tue, 6 May 2025 12:24:48 +0000
Message-ID: 
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-2-luca.fancellu@arm.com>
 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|AS2PR08MB10084:EE_|AM4PEPF00027A65:EE_|DB3PR08MB8892:EE_
X-MS-Office365-Filtering-Correlation-Id: 7ecdf117-394b-44a3-d53c-08dd8c991270
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|366016|376014|1800799024|38070700018|13003099007;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?iHcRMeb3rznWu0IE6ikUH0HL6EpmdY22zXXYnBxjSmhAMdURk6a0zZrsstF5?=
 =?us-ascii?Q?q9Nr4Z+7WyCZl2t5mmpktWzYb/FjNBUHAogHbP5lqNWGn+Orhqd+HgHIjnwn?=
 =?us-ascii?Q?BZfcS+n8yzNLxE/yR4KrrbCisk4fADgvlE5bDb8bd4hhoqXiCWbhjm5IYgbR?=
 =?us-ascii?Q?fmOQceavHcs156lXZ3Vc+l9mPnkghZ8kqHGMYD6Wy+INxC/N1eOIobcKyFeX?=
 =?us-ascii?Q?ug6B8ekANFV3mOK6B3l73M8SSH+6fyUFAQU6UxXHbIZTKd3FTSApqHlzjsl+?=
 =?us-ascii?Q?AGZpY3RETLn2RaF99LWDM6lnRd9BCF9K7iqtNIEA9KWYogpWCagvHtixQbE3?=
 =?us-ascii?Q?NjNk2hmkSafWzeIiLjD920btxK5W2QSrqHUDxn1R8kYnIgoixiqJa7sYZEwU?=
 =?us-ascii?Q?Zhgb/TGMMrcKixSN7/4G9HFEVZezTbzHRj4cvrBNaYrCS0RBNwMx9Ag/L32u?=
 =?us-ascii?Q?j8vJhRcUtc/SfKqDSTjsqewXIV0gs0bm5e2acPJBWsHz/6K6MJHMe/NiayaK?=
 =?us-ascii?Q?UrxdXEcEJCkLxE/qfLPjeZEK8RGlovjQv4gjHgMYI8SDbXHVEwmn+u35OJee?=
 =?us-ascii?Q?PW2HGnEqnLa0CWpO60GQCuSmPgSkWKfvxJ19IZTpeeI1x9Rh1yJsAi9PgGR5?=
 =?us-ascii?Q?brc+SDWCXgDMsONeowbcW+Js4OaFn/Bu+9zIxfJG9rHTaWOaHoeWIZNdd57+?=
 =?us-ascii?Q?JtyRIFmK6zQ63I/GT9uqjoEjWFU7erjPNC8vSZEIRiF5PLEH4UwyV0Xv4S/4?=
 =?us-ascii?Q?RXEtt0iwNAe9/pS5HE9og4krCWv9CLHnLDsRzZ0nBDwSDP1vs5AqaH8zrzNC?=
 =?us-ascii?Q?8ALswIBn5WwJnY5xN8ejluhme3vG7S9xQCQEfJpch83p5Xf0LpK+2AHe5fYQ?=
 =?us-ascii?Q?bTxHDxKk+VWjtlhSlhc0PUqIXdzD7gtjtypPezq8GbYrMqRi7bArZ/dIP/1G?=
 =?us-ascii?Q?u8A6AGgK8pJWzyq/R7baiwJfqdxUk6CHdwvj1I9sJcC4w7HMzXdthtAoSzPo?=
 =?us-ascii?Q?dPbC02fF/f/V60l957Xzztu0GPEPtLFeawvvFp7V+K15ZBRVIkUinKkm2t+V?=
 =?us-ascii?Q?IoEsva2Gwyg13t0El88ZDNlGlOFpZaFdg+XfYttKM4DU36jdpVREV905CJk1?=
 =?us-ascii?Q?VXP8y5peGSP1lHdVY1ecLm3Vs3qfGij4oY9iTa8K459A2W4/A9j7wi5QRX92?=
 =?us-ascii?Q?/o0SvUJ7kOmsMYQSzFKr8l2Yd38D2IkXzpCbDm7Sh/R/jWpiZw4ZNe11OEwE?=
 =?us-ascii?Q?y2DkHqJwk5YlYNxU/TjI7lCXqtA3JAW+ibsF1GULguMpE1RPWoVUX1KpIAx2?=
 =?us-ascii?Q?ew80NONup8KYQ5+6MEgjGNBjAQjwzaW9mkszo5gIJHmQwCLIdISEZBnohvlE?=
 =?us-ascii?Q?ZnwWD8lFcFSTCqRVn1lTSf+uSjV3MJBXodKSOhrhXNMVY9LQWXTw3Q+bNTDk?=
 =?us-ascii?Q?OaSAXZSBM1oPbeYNuElm9oigwGzwnYeo6iTa1SyQAL4hNIMyOwoIbUXIZlLO?=
 =?us-ascii?Q?ujvSpZazGQ0Yd3g=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018)(13003099007);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB10084
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM4PEPF00027A65.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	5ebdcbae-f539-4978-82ac-08dd8c98fe7d
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|35042699022|36860700013|14060799003|1800799024|7053199007|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?xNeoardmXDe/DyAtM01UnIFxW9N1n29lsg/teWhUuGNqJooG+lUvo+RJpH5R?=
 =?us-ascii?Q?zDQCrROfvJtugSe+taWU2EMpkDnIqrGh64nsiHntdrJPSr6Q9xtL527JHokE?=
 =?us-ascii?Q?nfoqSi7VBBNZUPmKBHDfvSy3cwROvGCD0HJ9rxnG/ih7pwPW1ZpD+wfDpH6p?=
 =?us-ascii?Q?KlVFZ7GYkrawIq2WWLD4rg1Bibmxq2UdwXnUiiWslY8V5hZVB2T6d5/P9/QW?=
 =?us-ascii?Q?OBrKHrIsp+QCd0b2b14tW8vjstP69EkEWUY0ZEr9MuAUTmKvpdD5khzdtB4n?=
 =?us-ascii?Q?TVUq2rel5dO7JnVP+SOt9K5qT+M5qaQ856B0yJdYz7pUg42fhT2Ci2CTGTHX?=
 =?us-ascii?Q?DRsvJW/XTpv5zmvJZGa16+M9pDwe2i0cl7SumK7ZLYMtUO//AMW7rPfPAbM/?=
 =?us-ascii?Q?PBqK2dIRA0Vl49FORS3ZI9NnU2hVKIHnDc2uJmtbkOZkwCJdDfruD9HGDTfG?=
 =?us-ascii?Q?VTQvFafXDmAZ+OS+F5koEbA87J9dmnEhfhDnhVr0ZbdznUp8b6MLHTbZATIS?=
 =?us-ascii?Q?kiwAHauKIvOelf2httYQVLxGSV3XOjP0ImAF8uRsk9lo45R2/rFRpISmmB8H?=
 =?us-ascii?Q?m4mzSGNwL1zYwBbfLFEX4pcXVyxIRoQ/fA0WkmERjsbrmQTHnhlGQmdxcUx3?=
 =?us-ascii?Q?UiuxxQ12KZBRbIEJaW1CvqIkIWt9xXOYyrIhO+4KY9M/Zv6bF5Yz1/ee4mRk?=
 =?us-ascii?Q?8JdXuHg4Xzkztpu/qe/8jqQFeG+NHz2WVp1Iw/updzoYEKDhrAEnUi7TAseH?=
 =?us-ascii?Q?mBAfykYEv3otxVuAayN2PzTEjr3dY6rUC+Gk3WAEhTkafevMt9j74kVObCza?=
 =?us-ascii?Q?OSSkXxfXY3vPfhl64FxVU/kkcT73iPYCX2V++EWAcQHhDz98BkX2RkRmNh4G?=
 =?us-ascii?Q?dT2/q1VAfRvqlqymDp2LVFCUYV6BheMB6CTgtxtEO4ctBOQ7xJF8MKh4scyo?=
 =?us-ascii?Q?k/X2YoYTAgikkQl64XrMyQeaYYnGx5GRUx7Yg6ANm3JqjPzNsmuhlWqbCTuc?=
 =?us-ascii?Q?qv+1zwt3BjoNSpfb8h2txhd/gDPJ95jSBEO1ECYjgZnz/Yow40SPuz7ScImm?=
 =?us-ascii?Q?xWu6jqi4ojM1aFBVjI81hNgCvdqC86eyE8lz2+d48mK3wsJhROQXGbzonMsY?=
 =?us-ascii?Q?fiAQL46iTD42uazmUtK3q2FauJ8JrCDJ6ni9zkWbwCQvwob2aAvhKBb4vVhl?=
 =?us-ascii?Q?sCwL/cGG3k8r9OTjW5df9RejqIKRMzi1p5v+T8G/1kjg+3spuM6gpB9+9lV2?=
 =?us-ascii?Q?D236RdLCPv6TSLSu+j6r7BT4ZQY6u9I/NmMoQOskNy0RKhm5TPd2a9MrElTR?=
 =?us-ascii?Q?bBB56S2zLg2kGRh/2PV8IwTmRT6bXstb5v+GGUVPQliA0guwlqD4xzyPRJiS?=
 =?us-ascii?Q?+QtCvCFV9SkaCKVB/w8KF1J2/UquU0J65QbdiRN4RKxlT9d6v/YZwt3FnBZq?=
 =?us-ascii?Q?0m6Xmfdd3gmz8WQWCeKpA1NLw6pEDHyRgIGm26QqM9j5yzFzTWkRl81JJZJL?=
 =?us-ascii?Q?nEwzVnmLDT8jfeQ4R0pD+KBpja26sBSBLiGYWqqRHYMF5PRLG5V2y1Xohw?=
 =?us-ascii?Q?=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(35042699022)(36860700013)(14060799003)(1800799024)(7053199007)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 12:25:22.2762
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ecdf117-394b-44a3-d53c-08dd8c991270
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:
	AM4PEPF00027A65.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB8892

Hi Julien,

> On 6 May 2025, at 12:44, Julien Grall  wrote:
>=20
>=20
>=20
> On 29/04/2025 16:20, Luca Fancellu wrote:
>> Document the requirement needed to boot Xen on Armv8-R platforms.
>> Signed-off-by: Luca Fancellu 
>> ---
>> v4 changes:
>>  - New patch
>> ---
>>  docs/misc/arm/booting.txt | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>> diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
>> index 21ae74837dcc..719af74f1e69 100644
>> --- a/docs/misc/arm/booting.txt
>> +++ b/docs/misc/arm/booting.txt
>> @@ -62,6 +62,14 @@ Xen relies on some settings the firmware has to confi=
gure in EL3 before starting
>>    * The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1=
.
>>  +When Xen runs on Armv8-R, the highest exception level is EL2 and the o=
nly
>> +available state is secure (S) on Arm64 and non secure (NS) on Arm32, he=
nce the
>> +above requirements need to be adjusted to this case:
> > +> +* Xen must be entered in S EL2 mode on Arm64 and in NS EL2 mode on =
Arm32.
>=20
> I think it would be better to update the line "Xen must be entered in NS =
EL2 mode" to clarify the state for 64-bit Arm.
>=20
> > +> +* Xen must be entered with MPU off and data cache disabled (SCTLR_E=
L2.M bit and
>> +  SCTLR_EL2.C set to 0).
>=20
> This line is valid for Armv8-A/Armv7-A when using the Image/zImage protoc=
ol.
>=20
>>    [1] linux/Documentation/arm/booting.rst
>>  Latest version: http://git.kernel.org/cgit/linux/kernel/git/torvalds/li=
nux.git/tree/Documentation/arch/arm/booting.rst

Just to be sure to be on the same page, are you suggesting these changes on=
 the original file?

diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
index 21ae74837dcc..c00c651805d7 100644
--- a/docs/misc/arm/booting.txt
+++ b/docs/misc/arm/booting.txt
@@ -58,10 +58,14 @@ Firmware/bootloader requirements
=20
 Xen relies on some settings the firmware has to configure in EL3 before st=
arting Xen.
=20
-* Xen must be entered in NS EL2 mode
+* Xen must be entered in:
+  * Non-Secure EL2 mode for Armv8-A Arm64 and Arm32, Armv8-R Arm32.
+  * Secure EL2 mode for Armv8-R Arm64.
=20
 * The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1.
=20
+* Xen must be entered with MMU/MPU off and data cache disabled (SCTLR_EL2.=
M bit
+  and SCTLR_EL2.C set to 0).
=20
 [1] linux/Documentation/arm/booting.rst
 Latest version: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux=
.git/tree/Documentation/arch/arm/booting.rst

Cheers,
Luca



From xen-devel-bounces@lists.xenproject.org Tue May 06 12:29:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 12:29:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977144.1364213 (Exim 4.92)
	(envelope-from )
	id 1uCHQc-0004cb-FF; Tue, 06 May 2025 12:29:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977144.1364213; Tue, 06 May 2025 12:29: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 1uCHQc-0004cU-Bi; Tue, 06 May 2025 12:29:42 +0000
Received: by outflank-mailman (input) for mailman id 977144;
 Tue, 06 May 2025 12:29:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCHQb-0004X2-0H
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 12:29:41 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c511d387-2a75-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 14:29:35 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a0b291093fso214426f8f.0
 for ; Tue, 06 May 2025 05:29:35 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099ae3ccdsm13677750f8f.38.2025.05.06.05.29.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 05:29: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" 
X-Inumbo-ID: c511d387-2a75-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746534575; x=1747139375; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ri0TWyC/dx2Y2lR9cNpuRp+Af8FuS6meweaINUQtdlU=;
        b=BqiLN2ABOy12yHfy8RtzZXZM2J9XI/h14IEWxera4slxRp7kHNnPXvdGaxVN8Dc4M5
         qB9A5YjhWrfr856m0KXB1vFE48+Bk28fmredpcqz3aOeoy2VGLD5tWeNN9lFS6VQzcZj
         +zyLdWoJczlABzcp4Wo6JfweCpMSq6JPeAolI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746534575; x=1747139375;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ri0TWyC/dx2Y2lR9cNpuRp+Af8FuS6meweaINUQtdlU=;
        b=SM3sq+pOxNNO9LZXIW+PklgFRVIpzEg4aNRP5cfU1n5VicIFfpJdlepyDcu1mbmDn/
         /9gTwTR35CtTJjm+PFNSiihlrIxuOnXH2y7aHAiSIrSicjT0HqJ2FF0knqS9RSP6xFO3
         ZTcA4IzaxyIHaKEVciobXLXDyBVwUp7BCmBuxICz6A8DahTyBZSEfpJwaLbqONuf0fC0
         ncA3aitAbvCwJzBHaUbXB1XqUcbDyuRNqbqMqJK4X83P0j9dAm0kkXw/qgMJbAEtMKtQ
         kbMkK897RZd+OZRa4r1vcyk0Ktje1bgrf8kIp4t+3xF5yWFJTOzL8qz1z+o4GHVr2qVF
         pvmQ==
X-Forwarded-Encrypted: i=1; AJvYcCV9msM7xHic/XgYR5V66EKB3JVli7oR1jcinSPYpD8zqLEI7hYH+OPfqj2Y+OnfMG9Ok007GPd4LCw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxW7yNofXXZ0iNAIRyKeXKnUczQWAaSm/Bm6ZdXQj+gr0mA0rL0
	qzkF79ALawhMysFtS1+5aD5cgU7+VrWhawdIZ8+1PsJBxkwzWUf2zoElvdC1k8c=
X-Gm-Gg: ASbGncvo9rPJKFCZs+bNBUp/1e9FJZo75EQiNtd1wXWXemGC99qdkXQgzjLAmBInq2I
	cg4CZW5kzs8S30v9tjIlRWaQ4MhfegyZdOh4LuiD35udgirFUQRgThXPAUFX3yowjSce6ScWpbV
	cL+884i3PDFWS3lPhdgFP5G1Nozh73uVIV1a4cj+dp5QoKgQlImrON9YW48oFpmp4bq+vIpel26
	s0FngK7LcpNRf08DT6ijMCD1FxiHqjtO2yBXQO8a0a6TIQRfvLlefYeC7g698MeOCgNtWBVVESx
	/WO68dOQhd7MVQtvkaKgYpoV4ka93M0hJ6NQnWZ6hnbjyxql1RLBUB5fHpjy38eLEkJZ1kJTD/B
	HOvuHLBY6nubpto0U
X-Google-Smtp-Source: AGHT+IHeJ2wBA17F+Y0FjU2lgspjn2nWCxmL/AP37ejaiya6SPne1RSviTmJO/DgZt9l0c5W9GueAg==
X-Received: by 2002:a05:6000:43cc:10b0:39c:2673:4f10 with SMTP id ffacd0b85a97d-3a0ab5b3305mr1965724f8f.23.1746534574994;
        Tue, 06 May 2025 05:29:34 -0700 (PDT)
Message-ID: <10538064-1085-4ae4-82f8-0aa9cabcfe23@citrix.com>
Date: Tue, 6 May 2025 13:29:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/cpufeatures: cpuid features for Sierra Forest
To: Kevin Lampis , xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, roger.pau@citrix.com
References: <20250506081456.1572050-1-kevin.lampis@cloud.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: <20250506081456.1572050-1-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06/05/2025 9:13 am, Kevin Lampis wrote:
> Add new cpuid features for Sierra Forest.
>
> Signed-off-by: Kevin Lampis 
> ---
> Changes in v2:
> - change INVD_DISABLE to NO_INVD
> - change UC_LOCK_DISABLE to UC_LOCK_DIS
> - better comment for UIRET_UIF
> - use MCU_ENUM because it's shorter and add better comment
> ---
>  xen/include/public/arch-x86/cpufeatureset.h | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
> index cc6e984a88..089a133519 100644
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -304,13 +304,18 @@ XEN_CPUFEATURE(SM3,          10*32+ 1) /*A  SM3 Instructions */
>  XEN_CPUFEATURE(SM4,          10*32+ 2) /*A  SM4 Instructions */
>  XEN_CPUFEATURE(AVX_VNNI,     10*32+ 4) /*A  AVX-VNNI Instructions */
>  XEN_CPUFEATURE(AVX512_BF16,  10*32+ 5) /*A  AVX512 BFloat16 Instructions */
> +XEN_CPUFEATURE(LASS,         10*32+ 6) /*   Linear Address Space Separation */
>  XEN_CPUFEATURE(CMPCCXADD,    10*32+ 7) /*a  CMPccXADD Instructions */
> +XEN_CPUFEATURE(ARCH_PERF_MON, 10*32+ 8) /*  ArchPerfMonExt */
>  XEN_CPUFEATURE(FZRM,         10*32+10) /*A  Fast Zero-length REP MOVSB */
>  XEN_CPUFEATURE(FSRS,         10*32+11) /*A  Fast Short REP STOSB */
>  XEN_CPUFEATURE(FSRCS,        10*32+12) /*A  Fast Short REP CMPSB/SCASB */
>  XEN_CPUFEATURE(WRMSRNS,      10*32+19) /*S  WRMSR Non-Serialising */
>  XEN_CPUFEATURE(AMX_FP16,     10*32+21) /*   AMX FP16 instruction */
>  XEN_CPUFEATURE(AVX_IFMA,     10*32+23) /*A  AVX-IFMA Instructions */
> +XEN_CPUFEATURE(LAM,          10*32+26) /*   Linear Address Masking */
> +XEN_CPUFEATURE(MSRLIST,      10*32+27) /*   RDMSRLIST/WRMSRLIST/WRMSRNS */

"{RD,WR}MSRLIST instructions"

WRMSRNS is separately enumerated (bit 19).

> +XEN_CPUFEATURE(NO_INVD,      10*32+30) /*   INVD_DISABLE_POST_BIOS_DONE */
>  
>  /* AMD-defined CPU features, CPUID level 0x80000021.eax, word 11 */
>  XEN_CPUFEATURE(NO_NEST_BP,         11*32+ 0) /*A  No Nested Data Breakpoints */
> @@ -340,6 +345,7 @@ XEN_CPUFEATURE(RRSBA_CTRL,         13*32+ 2) /*S  MSR_SPEC_CTRL.RRSBA_DIS_* */
>  XEN_CPUFEATURE(DDP_CTRL,           13*32+ 3) /*   MSR_SPEC_CTRL.DDP_DIS_U */
>  XEN_CPUFEATURE(BHI_CTRL,           13*32+ 4) /*S  MSR_SPEC_CTRL.BHI_DIS_S */
>  XEN_CPUFEATURE(MCDT_NO,            13*32+ 5) /*A  MCDT_NO */
> +XEN_CPUFEATURE(UC_LOCK_DIS,        13*32+ 6) /*   UC-lock disable */
>  
>  /* Intel-defined CPU features, CPUID level 0x00000007:1.ecx, word 14 */
>  
> @@ -349,7 +355,9 @@ XEN_CPUFEATURE(AVX_NE_CONVERT,     15*32+ 5) /*A  AVX-NE-CONVERT Instructions */
>  XEN_CPUFEATURE(AMX_COMPLEX,        15*32+ 8) /*   AMX Complex Instructions */
>  XEN_CPUFEATURE(AVX_VNNI_INT16,     15*32+10) /*A  AVX-VNNI-INT16 Instructions */
>  XEN_CPUFEATURE(PREFETCHI,          15*32+14) /*A  PREFETCHIT{0,1} Instructions */
> +XEN_CPUFEATURE(UIRET_UIF,          15*32+17) /*   UIRET updates UIF */
>  XEN_CPUFEATURE(CET_SSS,            15*32+18) /*   CET Supervisor Shadow Stacks safe to use */
> +XEN_CPUFEATURE(SLSM,               15*32+24) /*   Static Lockstep Mode */
>  
>  /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.eax, word 16 */
>  XEN_CPUFEATURE(RDCL_NO,            16*32+ 0) /*A  No Rogue Data Cache Load (Meltdown) */
> @@ -368,6 +376,7 @@ XEN_CPUFEATURE(DOITM,              16*32+12) /*   Data Operand Invariant Timing
>  XEN_CPUFEATURE(SBDR_SSDP_NO,       16*32+13) /*A  No Shared Buffer Data Read or Sideband Stale Data Propagation */
>  XEN_CPUFEATURE(FBSDP_NO,           16*32+14) /*A  No Fill Buffer Stale Data Propagation */
>  XEN_CPUFEATURE(PSDP_NO,            16*32+15) /*A  No Primary Stale Data Propagation */
> +XEN_CPUFEATURE(MCU_ENUM,           16*32+16) /*   Runtime Microcode Update features */

Thinking about this, I'm tempted to call it MCU_EXT because that's a bit
better than MCU_ENUM.

That, and "MCU_STATUS/ENUM MSRs" as a comment gets the point across, I
think.

>  XEN_CPUFEATURE(FB_CLEAR,           16*32+17) /*!A| Fill Buffers cleared by VERW */
>  XEN_CPUFEATURE(FB_CLEAR_CTRL,      16*32+18) /*   MSR_OPT_CPU_CTRL.FB_CLEAR_DIS */
>  XEN_CPUFEATURE(RRSBA,              16*32+19) /*!  Restricted RSB Alternative */
> @@ -379,6 +388,7 @@ XEN_CPUFEATURE(GDS_CTRL,           16*32+25) /*   MCU_OPT_CTRL.GDS_MIT_{DIS,LOCK
>  XEN_CPUFEATURE(GDS_NO,             16*32+26) /*A  No Gather Data Sampling */
>  XEN_CPUFEATURE(RFDS_NO,            16*32+27) /*A  No Register File Data Sampling */
>  XEN_CPUFEATURE(RFDS_CLEAR,         16*32+28) /*!A| Register File(s) cleared by VERW */
> +XEN_CPUFEATURE(IGN_UMONITOR,       16*32+29) /*   IGN_UMONITOR_SUPPORT */

"MCU_OPT_CTRL.IGN_UMONITOR"

While not strictly SRF, We should include bit 30 too, because its
related and retrofitted onto older CPUs in microcode.  See
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/monitor-umonitor-performance-guidance.html
for full details.

Otherwise, Reviewed-by: Andrew Cooper 

I can fix all on commit.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 06 12:29:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 12:29:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977143.1364202 (Exim 4.92)
	(envelope-from )
	id 1uCHQa-0004Ny-4v; Tue, 06 May 2025 12:29:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977143.1364202; Tue, 06 May 2025 12:29: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 1uCHQa-0004Nr-2R; Tue, 06 May 2025 12:29:40 +0000
Received: by outflank-mailman (input) for mailman id 977143;
 Tue, 06 May 2025 12:29:38 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uCHQY-0004Nl-Ie
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 12:29:38 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uCHQY-00Cg5L-0w;
 Tue, 06 May 2025 12:29:38 +0000
Received: from [2a02:8012:3a1:0:7157:32ca:2aea:33a3]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uCHQY-000QuW-0O;
 Tue, 06 May 2025 12:29: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=Cy5/8twqUfPNbpHxqJlEDdXb+Jj9THtCRDc+J3ZAY9I=; b=0TDOY8WRwEw+Ch/9G990EjK2Y8
	IKaWr4L/c8HR14L5IFI6vv0JYQ/iapO6myVnnZeTRwYq9faZHQ3SUUsHECz6HdEFUkO0OBVC2HJYg
	qdo6NJuGuIOUrdQ3TAQWtxEUHv0NcGa7SqMzrp0Exue7/BPYeHGVWTlmkpPl1mAuorYw=;
Message-ID: 
Date: Tue, 6 May 2025 13:29:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/7] docs/arm: Document Xen booting protocol on Armv8-R
Content-Language: en-GB
To: Luca Fancellu 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-2-luca.fancellu@arm.com>
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 06/05/2025 13:24, Luca Fancellu wrote:
> Hi Julien,

Hi Luca,

> 
>> On 6 May 2025, at 12:44, Julien Grall  wrote:
>>
>>
>>
>> On 29/04/2025 16:20, Luca Fancellu wrote:
>>> Document the requirement needed to boot Xen on Armv8-R platforms.
>>> Signed-off-by: Luca Fancellu 
>>> ---
>>> v4 changes:
>>>   - New patch
>>> ---
>>>   docs/misc/arm/booting.txt | 8 ++++++++
>>>   1 file changed, 8 insertions(+)
>>> diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
>>> index 21ae74837dcc..719af74f1e69 100644
>>> --- a/docs/misc/arm/booting.txt
>>> +++ b/docs/misc/arm/booting.txt
>>> @@ -62,6 +62,14 @@ Xen relies on some settings the firmware has to configure in EL3 before starting
>>>     * The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1.
>>>   +When Xen runs on Armv8-R, the highest exception level is EL2 and the only
>>> +available state is secure (S) on Arm64 and non secure (NS) on Arm32, hence the
>>> +above requirements need to be adjusted to this case:
>>> +> +* Xen must be entered in S EL2 mode on Arm64 and in NS EL2 mode on Arm32.
>>
>> I think it would be better to update the line "Xen must be entered in NS EL2 mode" to clarify the state for 64-bit Arm.
>>
>>> +> +* Xen must be entered with MPU off and data cache disabled (SCTLR_EL2.M bit and
>>> +  SCTLR_EL2.C set to 0).
>>
>> This line is valid for Armv8-A/Armv7-A when using the Image/zImage protocol.
>>
>>>     [1] linux/Documentation/arm/booting.rst
>>>   Latest version: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arch/arm/booting.rst
> 
> Just to be sure to be on the same page, are you suggesting these changes on the original file?

Yes with one tweak.

 > > diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
> index 21ae74837dcc..c00c651805d7 100644
> --- a/docs/misc/arm/booting.txt
> +++ b/docs/misc/arm/booting.txt
> @@ -58,10 +58,14 @@ Firmware/bootloader requirements
>   
>   Xen relies on some settings the firmware has to configure in EL3 before starting Xen.

I think you want to update this sentence to remove the reference to EL3. 
Even on A-profile EL3 is not mandatory (I vaguely remember one of the 
platform I worked on had no EL3).

>   
> -* Xen must be entered in NS EL2 mode
> +* Xen must be entered in:
> +  * Non-Secure EL2 mode for Armv8-A Arm64 and Arm32, Armv8-R Arm32.
> +  * Secure EL2 mode for Armv8-R Arm64.
>   
>   * The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1.

And then here: "When EL3 is supported, ...". This would also cover the 
R-profile change.

Cheers,

>   
> +* Xen must be entered with MMU/MPU off and data cache disabled (SCTLR_EL2.M bit
> +  and SCTLR_EL2.C set to 0).
>   
>   [1] linux/Documentation/arm/booting.rst
>   Latest version: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arch/arm/booting.rst
> 
> Cheers,
> Luca
> 

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue May 06 12:41:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 12:41:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977170.1364223 (Exim 4.92)
	(envelope-from )
	id 1uCHc3-0007y2-E9; Tue, 06 May 2025 12:41:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977170.1364223; Tue, 06 May 2025 12: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 1uCHc3-0007xv-BK; Tue, 06 May 2025 12:41:31 +0000
Received: by outflank-mailman (input) for mailman id 977170;
 Tue, 06 May 2025 12:41:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCHc2-0007xp-4Q
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 12:41:30 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c201::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6e706f72-2a77-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 14:41:29 +0200 (CEST)
Received: from AS4P190CA0018.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:5d0::11)
 by AS8PR08MB9839.eurprd08.prod.outlook.com (2603:10a6:20b:614::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.25; Tue, 6 May
 2025 12:41:26 +0000
Received: from AMS0EPF000001A4.eurprd05.prod.outlook.com
 (2603:10a6:20b:5d0:cafe::ad) by AS4P190CA0018.outlook.office365.com
 (2603:10a6:20b:5d0::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Tue,
 6 May 2025 12:41:26 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF000001A4.mail.protection.outlook.com (10.167.16.229) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.18
 via Frontend Transport; Tue, 6 May 2025 12:41:25 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 GV1PR08MB7915.eurprd08.prod.outlook.com (2603:10a6:150:8d::11) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8678.31; Tue, 6 May 2025 12:40:41 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 12:40: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" 
X-Inumbo-ID: 6e706f72-2a77-11f0-9eb4-5ba50f476ded
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=jFzI+PTumRQIb/e1xLLidEUqFziLDR+E1B3LjE5ccGfuPp38EGTN98pLBze5BiAwBNhHojSNm30cRosR7MhKBSvs77D2Gr7QAU+uQw/6EVyAvI5DGsAz8TPcnt5g69TjcAWBaz8iicjqJauDVsbIbDFi/Ua6YC96lDoust3xYAfme4vSfyx02plRZIazUkIvfpYcDf8R6CSQVMmZFRsgztj/3JzShTM3utBPWN2qA866UwIt6P251/p6m8cjE9N5ORnd3Qvpeori004F+cC2sApGPi3F86uSUIPRkQldHpRbdB+kx4OozW8l3AhvuevxqGGYipJely9jewlsSrjMOg==
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=TqxA7DL/8hKb3eyzF6bkdo41KMSU0BUos4XM8bLohQw=;
 b=Qsow8XggffT2ZiCtNbCYNZ/QBv9pF5r4Mdj+aqChzPWvnqng6SkgWfkzbldNSfoDJisgsaz3+Ku1n71Sz+4ymcRw2Il4uoU1Bw9eVzXzhJUBfwa7cdrSL919pKkhpjvA+VvFjMNgVXtknemH+LtugqYuuddcBQiGfhT6iRWJWq+eb8GCm1VYb+qG/zJqMCllEJ0AUDHZLjkXMTGSeXepkk4p03A9IJWfC/YXazArn8cLCNf9Svj69h6yB0a0icI6VmEPbyXmatLjp9llqAjmgiwTLzvyoLd4QAzdfYzyRs8QM+TY6RM2DwPhVlWkfIm3EDXB9puAbwdd4RkczowAXg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=xen.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=TqxA7DL/8hKb3eyzF6bkdo41KMSU0BUos4XM8bLohQw=;
 b=M3vqSTBfewHRyw+HDNfBydfT/9mHT3SwZmTe7SB+Q+O2KwuXgKQrgaG86y/ZnmQR4185+WwxLnxIj/i59wSnT5S/J2wMpigsM5KL6gJhzPCjzvOlzNo1NYGihC0csKCceMGHJRLlF0vdvLlQJWm2mkvvIYNjqv+QvWIH31nzCyQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JmtQlWW5R3TkbD0pd3TmPPj8eK/QGuKYeTAx+olVFX1IIeO8YBvhTL5M291ZBOLb037FsQA6vIu2A8X8yCDU+CNlWBWBPPyNIZ+tV7ZStIXIAsmfXS9r2N/6V/X9/8WfKVhXxujwhdAMVVchKAdwo47CsiSTzQfvV97C0S3O6BkbsECUsJTlN5Mbuz2Y4+EL1Ni9GALOvLLhkSN4/e5rHoy5cGoX2Mgdy0CWKNtDrS1OsbRNRr8QktcVGr6XD1jYsTliGUejg4bPnzCNMINbvRZ9ojq7rTwQVjqrCJduePY+nAXhmBi2IhJU81J0OYGKamNlxoLZ29xM7/L7rEz0Bg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TqxA7DL/8hKb3eyzF6bkdo41KMSU0BUos4XM8bLohQw=;
 b=f7wH1iNSY6Teb7XKnt8Z/ZAzNGT2g9XCFjcpJWKQVNJNVOu0pMdj14t07BOSi9Sm/AzWLaaggCEHIEutzP3MJS+7pl/PfVXG55L7i4jpZGSspJDnK5YOjB8ibCCIziMTc5JbZhCTEBitqft3Bxu2yYH7cNkNfbNYva5LXCxp0SVWTu4Uef8zaih+QvCfok7hH+YsvxCsYwhwA3zufg3l3370+1wgT1WsOmJiJ74Lr2iWJTQEXD3X24bt+MfoNTRkvpUOvJHPBHZm2jVz7y50e/8KDxWASmw+zlnUe5KLoYzmFi6jqn6O3dvlzJbCrMIdp7SiXuhv+wrEA2v/AoZ0/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=TqxA7DL/8hKb3eyzF6bkdo41KMSU0BUos4XM8bLohQw=;
 b=M3vqSTBfewHRyw+HDNfBydfT/9mHT3SwZmTe7SB+Q+O2KwuXgKQrgaG86y/ZnmQR4185+WwxLnxIj/i59wSnT5S/J2wMpigsM5KL6gJhzPCjzvOlzNo1NYGihC0csKCceMGHJRLlF0vdvLlQJWm2mkvvIYNjqv+QvWIH31nzCyQ=
From: Luca Fancellu 
To: Julien Grall 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Ayan Kumar Halder 
Subject: Re: [PATCH v4 1/7] docs/arm: Document Xen booting protocol on Armv8-R
Thread-Topic: [PATCH v4 1/7] docs/arm: Document Xen booting protocol on
 Armv8-R
Thread-Index: AQHbuRpmN9lJogKQoUiVWa6WakCsQrPFhjEAgAALLQCAAAF7AIAAAvWA
Date: Tue, 6 May 2025 12:40:41 +0000
Message-ID: <2FBFEDB5-C33D-4262-8D1D-C3B3174057DE@arm.com>
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-2-luca.fancellu@arm.com>
 
 
 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|GV1PR08MB7915:EE_|AMS0EPF000001A4:EE_|AS8PR08MB9839:EE_
X-MS-Office365-Filtering-Correlation-Id: 4ccf2d3a-de4e-4908-4537-08dd8c9b50a9
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?Ni0AcWHct4geOTXn5qYGYDKIf/xFcLlJ75ScR5Jg966CFm1dDehP5UF5ok7+?=
 =?us-ascii?Q?V7XUys1jkZGXRHIC0D4pr9HTdDf5z5RL2OcJBlclpvJKwfgazwG+gg4HaUAj?=
 =?us-ascii?Q?Y8etrb1fYC7cWm3+Pc6/EAG8G36QtWQWGGNbhJragc8M8ZhIJUqKuNwH+otj?=
 =?us-ascii?Q?itK0NemxVq1z9D13fVN4i/xa4NnIm81oqZjh/3SQtzpjqiwBy3pqe+J4x+7L?=
 =?us-ascii?Q?FjZ8TeQqD0AZWlqONDzUAEE4I1GZ4JwEUUa7EFMsableQXhBDxLPbFzz4pXf?=
 =?us-ascii?Q?FlB+cmtCRTnwvlpPHLkWu4igKv4NUAoCTOck2yx6bd/YiZ9bByMV4WREkc2d?=
 =?us-ascii?Q?80jjLIkCHjt4j8pMKTlreEm+omF9Ll9Dj/0o1tlB3L1J8IFTxrgAyTN9pkGN?=
 =?us-ascii?Q?Vkpjq1kltD6G4BOHRGwCFLF8V9ATstkiDU2OvMQFv5LNJ1sxssOHKuUVlcpM?=
 =?us-ascii?Q?+AuywB4W7SfMnALitxg1BU2E+b3SaW/bypIG3UU6KZSeG/FHlenQbZiI9h3D?=
 =?us-ascii?Q?2/u/hkMIShCa8/n1kHHoiA1OLfXc+voSvOl51il1ak2Mhqa8UpAfhNrHDZ8l?=
 =?us-ascii?Q?jQUKq3gfdV8o/R8W6MXLPMOM6TP3Wx0huFaeQtBNhogW3YfSKSP1y2Q3nU4A?=
 =?us-ascii?Q?Gl05nzCZkA4953P+JP9oBmnY1pjWa6jPeH+KSrvbE/CjYP2YcvifU0etdZcl?=
 =?us-ascii?Q?+cmGoa2YCb90ncij1PnD/Pk1Yd7zFsYO/MowZhs1PY++rZJo4CAiXRZAx9Ff?=
 =?us-ascii?Q?xttGFzcY0RNuFtyG0ADZdXURNVweh1eSaGhqxBUz6D7EGxbVI+XLGUNnKCBS?=
 =?us-ascii?Q?9ZU6ab+1+rtU8OGSH3NaJpGFRfN10KXH8qczKQIHmNrSfjZD+s00CEoX25n1?=
 =?us-ascii?Q?GdDD4Qb7QtkNihn5cOVHVm+3JG6GXi3qokcS6gZWGCQlgCy1NrLMpoC+NiKV?=
 =?us-ascii?Q?dIdzqs1R2muBzD3rNdmXxvj5pgvYBtMQV02eadrYSLknBb5jYVPdK0FE7Xme?=
 =?us-ascii?Q?RlZAM4xAaKXjpf1l70rHH3EPtQk3n1Alufpr+REALwJ7sTU9NvGxHoXpE5R6?=
 =?us-ascii?Q?qhR9fHRkO0U7nd/BapBw6ADFduujmAq0jtJ1nqGfcI8MmOu7KqQaGwb2Nck+?=
 =?us-ascii?Q?vBm/bsIDE+cybeoCkB/1HbmzpdiqnsPag2git+sCTiibyoQunALLbDdQUrTZ?=
 =?us-ascii?Q?b3q7K92QAxdzsTlwnIWJA0auJPBtuJ9FxBWn7E4zWBaDwu7AvH51+IWV8PqT?=
 =?us-ascii?Q?8D5XRqDFe+Vr9n4dpx3WQi2D6A7mthFRUVH+gSc7h4sQ0Jdzu9/kv904fYEe?=
 =?us-ascii?Q?I2g1ccX//zWBaQwFwptnFQz0tBsbTRGD/ZTxQMi+OuE4bZYvpBlbehnRa9lA?=
 =?us-ascii?Q?AllR3wD6hJ9dKYM0/Wy9HcbapzlWQCDXu67y3yBk8QPvOL8+Y/nHKZ6Awl3w?=
 =?us-ascii?Q?3VbSpwGputc+eCvkEPF0QiCKHWWWYaQxdaRXBnyq1doiLWywYc4Mh6p04lTY?=
 =?us-ascii?Q?Ue2O8U3JmV2QtNA=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <01483794C69DD54BB7A0B935DEE95F10@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB7915
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF000001A4.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	45c29f11-e642-42c3-99a7-08dd8c9b3638
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|35042699022|14060799003|376014|82310400026|36860700013|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?GL+q6M3XjtGKg9CmHcO04wrsqFE9YJL2RT3432o4LOJYHxZXXAOIOQDn6i1g?=
 =?us-ascii?Q?MQXjbIa1jyxTwamaOaWUz2PITlPQzPShzjy03egDhvszq5rbFE0F2XqUSely?=
 =?us-ascii?Q?no5zSt4rg2mN2UJeYpcVC3rHS2artCrg5KLhXg5p/Izz2Z8Hz0gJejkiuDLO?=
 =?us-ascii?Q?OEEOJYJu6XvNuoKduoFK7OZvISNUnE3CdzEQPp8zjOYm7ghZJsaeB+MX8tNH?=
 =?us-ascii?Q?p4BtBkzKaZNZDKhEpCYSKYqjuu0FSyDDe+sJEXcujbSNGGZYHXVzO+vYtNOt?=
 =?us-ascii?Q?5q3mVaPRc6e6D5i2B3woCgyW758PDzGs2sX4UXbjqmwXQ3U+lyi34f0GbTid?=
 =?us-ascii?Q?r7BAvima+J/OR9OkI0yVZIohyS4ioElyx2rwkL2EIzsI31aD0eLP25TCAAVq?=
 =?us-ascii?Q?7hrofi+Gf7cRszHA1X8CD2xwbtaxvSdAxkJbtkCu8KEDKP881Lep09S4ehqb?=
 =?us-ascii?Q?+wqqwb8ZEdHziwhKStoN4ASVTHOzFuZJHnQD96PbcEyzVkbY1eIBdcBWscXM?=
 =?us-ascii?Q?aJKI/8yS28S/e4ZkkhfudqylxLUpEqZQbJ3DenrngmBM12tE/s9/BrzkDDLb?=
 =?us-ascii?Q?ItQa7cbVAl3H32St348mJMDoeBy4KvI8FJn10p8F1BRpgOe6duWll4WYF1sc?=
 =?us-ascii?Q?nl6eGJFsdmU/CpKuH7KBcR4/Kcf3JfI+Zxp8AF4hOw0XbWjFtFg8a/AmzOhO?=
 =?us-ascii?Q?x3A07Pfe7+67JTVxfmT5E6iPWvOo6+0pWUJuqofwzkofajS1rbjhYWXe9svT?=
 =?us-ascii?Q?4tBK6KpjogsrlZBWvAp4Z9haGNH0T+j1QAkl5Rkt1yM86tbA14B+EeiRPRBR?=
 =?us-ascii?Q?yldYQkHn0FZFsMU2nZ5mToiFzPfIgKnNzpXAWpRBudMNXMMagORe5HsxlCLz?=
 =?us-ascii?Q?oTP3sAFtlvjiEwvIyCQspPHCiH6PHw22Kc/WaFKf3q7p7Lek6eXKyLMxQW0r?=
 =?us-ascii?Q?og0R3zzZIGP7jTJGYcttKTLcIYVMydPqcbzIuadNBkwcxFP8AglkUxHzzJCG?=
 =?us-ascii?Q?9CyTva+UhT+jYFZeTQcMhKTg4s2XaXBbWm8YoqNotdnZMoLjfbcFZynTbRW8?=
 =?us-ascii?Q?F/YyRErHN02lHIRv6UeeJX0iNidIPDQ2hpnBBvV8a80LRSLmN2McDfnJhRq2?=
 =?us-ascii?Q?wny34I1VZIOLk3w+sExuQu9iAp1fmfbzwU6kKFI2iKRkX3DyH55W5oq0v1E1?=
 =?us-ascii?Q?Ajwjsc1LQo6lbNDOPXqslOhSPg0FVl2HdS5boaReVI788WFfUQWERITk9g6e?=
 =?us-ascii?Q?d9EG/1nlEsV8UfyhQFiR3+7M1DI54NHkEqDTm/8obyBlddJozrx+tN/FFUlm?=
 =?us-ascii?Q?sI3fqKnFnyJquwM0A8dwKGv6YaLJBY1Ni+6wsapHBJPIPTjk7kTtqXaPB9ub?=
 =?us-ascii?Q?TzuXvL9tkVH16x/2tYR9/CqpJiApEC4eiKRJrLUPWbjsVVsqVQIWm2Bp0tI6?=
 =?us-ascii?Q?kVyRciDrCx2qh9fTy1rsnabFCOTaZ0ZdjilAN1dc08oh38Z0tg813b30ZZCv?=
 =?us-ascii?Q?DeEjxG0rNuhT+DQzpEqXDmbr6Op5BMYVV8KmaFV4+LNHva71UzGoxxQ05Q?=
 =?us-ascii?Q?=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(35042699022)(14060799003)(376014)(82310400026)(36860700013)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 12:41:25.6700
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ccf2d3a-de4e-4908-4537-08dd8c9b50a9
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:
	AMS0EPF000001A4.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9839

Hi Julien,

>> Just to be sure to be on the same page, are you suggesting these changes=
 on the original file?
>=20
> Yes with one tweak.
>=20
> > > diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
>> index 21ae74837dcc..c00c651805d7 100644
>> --- a/docs/misc/arm/booting.txt
>> +++ b/docs/misc/arm/booting.txt
>> @@ -58,10 +58,14 @@ Firmware/bootloader requirements
>>    Xen relies on some settings the firmware has to configure in EL3 befo=
re starting Xen.
>=20
> I think you want to update this sentence to remove the reference to EL3. =
Even on A-profile EL3 is not mandatory (I vaguely remember one of the platf=
orm I worked on had no EL3).
>=20
>>  -* Xen must be entered in NS EL2 mode
>> +* Xen must be entered in:
>> +  * Non-Secure EL2 mode for Armv8-A Arm64 and Arm32, Armv8-R Arm32.
>> +  * Secure EL2 mode for Armv8-R Arm64.
>>    * The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1=
.
>=20
> And then here: "When EL3 is supported, ...". This would also cover the R-=
profile change.
>=20

Thanks for the clarification, @Michal, @Ayan, are you ok if I retain your R=
-by with these changes or
should I drop it?


> Cheers,
>=20
>>  +* Xen must be entered with MMU/MPU off and data cache disabled (SCTLR_=
EL2.M bit
>> +  and SCTLR_EL2.C set to 0).
>>    [1] linux/Documentation/arm/booting.rst
>>  Latest version: http://git.kernel.org/cgit/linux/kernel/git/torvalds/li=
nux.git/tree/Documentation/arch/arm/booting.rst

Cheers,
Luca




From xen-devel-bounces@lists.xenproject.org Tue May 06 12:55:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 12:55:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977182.1364232 (Exim 4.92)
	(envelope-from )
	id 1uCHpl-0001RY-I2; Tue, 06 May 2025 12:55:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977182.1364232; Tue, 06 May 2025 12:55: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 1uCHpl-0001RR-FU; Tue, 06 May 2025 12:55:41 +0000
Received: by outflank-mailman (input) for mailman id 977182;
 Tue, 06 May 2025 12:55:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCHpk-0001RL-Jp
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 12:55:40 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 68f1038d-2a79-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 14:55:39 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43edecbfb46so31614515e9.0
 for ; Tue, 06 May 2025 05:55:39 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441b89d1548sm168976535e9.11.2025.05.06.05.55.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 05:55: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" 
X-Inumbo-ID: 68f1038d-2a79-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746536138; x=1747140938; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=HZgfbALzoCABAruC+RRlWEJ1PqVq8vCQOVyzADj5mcA=;
        b=Yz56ATrhYY3SMqFAEiiGnEnDuX+2rrX8vT2xCUa2Xi1CGsUy3PWFv8Emc7dvLu9F7d
         L7E9aE0DTXIY9/b644CpyOr779Tm4n8RJJOW92Dqc6pYlBnMAwc9X15uqYOsq3fZsoHH
         mG4azmtxxpRvtSCuaa1KxEYPKQF7QsyZachQw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746536138; x=1747140938;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=HZgfbALzoCABAruC+RRlWEJ1PqVq8vCQOVyzADj5mcA=;
        b=eWJ3ak/eZVmexnqN44d7oD0WJzIcg1IuOjBhe6bihyRlvFF3oPH9j/7qlurL71wbrs
         oElz2qb7DImAaxRnUmy6Gg7VKzdzjVivoZ7SO9IfudD6BOVHpyNeAt56R3y/cOlFeK4a
         tZl38TNFylWa2bWS52FS9MiKKo9b2D70cJS7DCKoEBklMgv/HHfuct61ObtDQd/Tt+15
         tfIBhLMQScSR6g8NXyyZwJ7TJLkTf+BLevEBckiJXYCf4Bk7DQuAIFw+WpQAvMZdjp7g
         KBLg3A8rhMrCNQkvuMl34er35MuDhzLECm9aVjUDj+tf8RDc5gLXlDMkWhMRJuH/GjYW
         fMsQ==
X-Gm-Message-State: AOJu0YySTGLpbVfcatCnnULBSD8w+uVt/zsnHOl9NS/n8IRkEag8fXBX
	yemTLr+L7CNj4nsiXSwO0KPx6mxqy1G6K0wb2N7o/OQsivIXOMRGfUQvUgYfP+A=
X-Gm-Gg: ASbGncuDgzmzftUypeeAlU4CI5F7uf8h9n2NB1EalU9WybEHRzPywwiFTF0PIPLwtPh
	Oto9G4MY1F5hr9hgm4A9o73icdWeeXFvlZYUDpK1Hdp2ATCBxPmE/5GD7azKpDFOSP2wNDaiedt
	u0VU8BqJ5+iNqr/UzRQx5H9WQMwBCgN/Ushv1OQFbmhBMW03OfcI1XkuMWWyCtipVJuBpP9SPg5
	p6CGMGi4tIJSrx6ipwBhPsxB+bWn8KrCRlB/KtsgCWmVqpiw6egCTu4VjpyCraG11P7XXPR0lIV
	vwIC/NNk9q3WqtCbSwnMURqgqH2dl4oy/Id95mb8DWGhYr/hWDi1IxVF
X-Google-Smtp-Source: AGHT+IEHuQT7b/1JKUk3ckbw6gxlOBT7qbg7rYqRunu7rBMk/AzuGF4pJrv/kx0O/JkbQ/huF2Iw3A==
X-Received: by 2002:a05:600c:3e17:b0:440:59eb:bfc with SMTP id 5b1f17b1804b1-441d0530c30mr26177135e9.23.1746536138335;
        Tue, 06 May 2025 05:55:38 -0700 (PDT)
Date: Tue, 6 May 2025 14:55:37 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, Jan Beulich 
Subject: Re: [PATCH 9/9] xen/x86: track dirty pCPU caches for a given vCPU
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-10-roger.pau@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, May 06, 2025 at 12:16:00PM +0100, Andrew Cooper wrote:
> On 06/05/2025 9:31 am, Roger Pau Monne wrote:
> > When a guest is allowed access to cache control operations such tracking
> > prevents having to issue a system-wide cache flush, and rather just flush
> > the pCPUs where the vCPU has been scheduled since the last flush.
> >
> > Note that domain-wide flushes accumulate the dirty caches from all the
> > vCPUs, but clearing the vCPU masks will require pausing all vCPUs, which
> > seems overkill.  Instead leave the vCPU dirty masks as-is, worse case it
> > will result in redundant flushes in further calls.
> >
> > Signed-off-by: Roger Pau Monné 
> 
> I'm afraid this doesn't work.
> 
> Unlike TLBs, dirty cacheline can move sideways, e.g. by foreign or grant
> mapping, but also naturally because of how cache coherency works.

Does such sideway moving also imply that local WB{NO,}INVD on native
could be equally bogus?

According to the SDM, cache lines can indeed move between processor
caches, but the memory controller must always snoop such moves and
flush the data to memory:

"Here, the processor with the valid data may pass the data to the
other processors without actually writing it to system memory;
however, it is the responsibility of the memory controller to snoop
this operation and update memory."

So a cache line moving sideways will always be propagated to memory as
part of the move, and hence the data in the previous pCPU cache will
always hit memory.

grants/foreign maps are indeed complex, but sharing non-coherent
across domains seems like a recipe for disaster.  It's maybe mitigated
by doing host-wide cache flushes, but how does the mapping domain know
whether  source domain has possibly dirty caches that need flushing?
IMO it's the source that would need to first flush any cache contents,
and then share the memory.

FWIW, (and not saying this is correct), but KVM uses the same model of
tracking dirty caches, see wbinvd_dirty_mask field in struct
kvm_vcpu_arch.

> We need to use the guarantees given to us by the architecture to simply
> nop out cache flushes when safe to do so.

We already do this when possible AFAICT.

> Everything else is either a shootdown (clflush/opt/clwb, and doesn't
> even trap to Xen), or needs to be a global WB{NO,}INVD.  Partial WBINVDs
> are of no value.

What about on Intel when there's no capability to trap WBINVD?  Xen is
currently flushing the cache of the previous pCPU in case the vCPU has
moved around, see vmx_do_resume().

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 12:56:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 12:56:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977195.1364243 (Exim 4.92)
	(envelope-from )
	id 1uCHqx-00020W-V4; Tue, 06 May 2025 12:56:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977195.1364243; Tue, 06 May 2025 12: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 1uCHqx-00020P-S9; Tue, 06 May 2025 12:56:55 +0000
Received: by outflank-mailman (input) for mailman id 977195;
 Tue, 06 May 2025 12:56:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCHqw-00020J-UZ
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 12:56:55 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170110001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 93272b6c-2a79-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 14:56:50 +0200 (CEST)
Received: from AS4P195CA0001.EURP195.PROD.OUTLOOK.COM (2603:10a6:20b:5e2::8)
 by AM9PR08MB6067.eurprd08.prod.outlook.com (2603:10a6:20b:287::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Tue, 6 May
 2025 12:56:45 +0000
Received: from AMS0EPF00000193.eurprd05.prod.outlook.com
 (2603:10a6:20b:5e2:cafe::13) by AS4P195CA0001.outlook.office365.com
 (2603:10a6:20b:5e2::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Tue,
 6 May 2025 12:56:45 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF00000193.mail.protection.outlook.com (10.167.16.212) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.18
 via Frontend Transport; Tue, 6 May 2025 12:56:44 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 GV1PR08MB8714.eurprd08.prod.outlook.com (2603:10a6:150:83::15) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8699.21; Tue, 6 May 2025 12:56:11 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 12:56: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" 
X-Inumbo-ID: 93272b6c-2a79-11f0-9ffb-bf95429c2676
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=yDIgTw7nsG1vleemABAJrziZmoyeSmGTBFADbhRPsiZ0++xtIKWKMHU9C/geHLvGwyorCmOPsgaZm/ZCamYsIVFcCsKrUiEQHIc+IKZ3r8H5dbvgXTvkZv4Y5RR7TDo3/0FbiEJNPFZ1Fba01JLS0go0idUinhfMoa5lfK/uxaWa7CgVCiI2CPzUerx96fyiW7+/alweU+kBxAtNGTTUFQ/aC2bP5VroNhpjTvoADsTL7HE6ud+Sbx4lovMXQ7IPsYepJw6/x6eapp52nb28qS6MZ1C5hb7ybEXtEISDZ+0/XBLCSB89OhYidxgVBH3b03yJLi7+l/e4AxCOHEEq6Q==
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=KdaGjJ6EHlSDjKNMZrgZ8+8QmMhrREuwfAklL69J/NY=;
 b=vULMrm51t0MMcFVo+iFs0fyVdg6/z6bExj85PuXX8BzDJ9wOnvWzZss2Xj2+tiuraXBFME8J0tv/w74erzK0FX52LTf+uYiLooS+lVx528KxsBv0rG4r+ZUb7Cv9H1V2Acwkisj6WL5Uv2OE7LvC+4sPoNYFLOteImxH6bhdouB8ZMiTjM1eNIgQIlWw0O2LYFFG1xHCgb3Q45PpZuOJ4NdNdZXjXthhbm813CtBakeVcC0SE38TCyh/QUDz9ubxUwKl9qC1W6DslrbuzPI0A9Y/USJkLwKfcwLkUibAXoL1ccb4qW2A6V7LxbbUK/StaE3Jh3KS1qZYcy0/gKCGuQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.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=KdaGjJ6EHlSDjKNMZrgZ8+8QmMhrREuwfAklL69J/NY=;
 b=Z4hDDX4CwMw48/P0ejaYTSr7ZXOPOKVvtmUjbYaUotGgBEXAVwlNPrmt3uEwg/IN5un5+N55hNwFLtJd+pa2n79A0LT/40ZqCA4wQSrINwX/lBBHMOaFESybA02ncwtTiYqMnszF9lhsSV91KyKF6LKz499KoE0URQRxdmi9psU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M5wt/Shst9WqZZi9Iy1BMvwpVIfL/tZs2oqCUJcRv0y0EiBJbLITxSFRPa3a5xbYDSIqk+xfjf0OrSxyNpf6cl4425nDYTTFCz6l+VwFAL6oYwlsMkwJ7q6k0kOTzPa79X2DRDFfZG45ySGKOyr7W0xUjmT0VE+NB2Z5DWiIvD7UUkcyUoFJWtap2rLWu3uq4KThkD7/UEfzyytaDiPPCIGKqdDVe28ly+Ks4f3HwVUmiK1+ToNEKuHTvSIlHrLf43Lt9FuYF9vS2PlBb24+RVgTki1q0o3txeoUlyxGXekldL1Rax/4QWYXne+tOG1gR29x8RaUdFEr9cdx21m4Ug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KdaGjJ6EHlSDjKNMZrgZ8+8QmMhrREuwfAklL69J/NY=;
 b=WUiThnsgLqugeXnwup33Ws9Wxf3vuyIQ4zVBptfnUyL57N8svqodcNrzDlu+6Fx5KPzte3L1rOLfCjlSpbIHZiYFwGXJ1/cCAkeHDARmCeSwaSEg6drRkuQYe7H9ity6LEFUntOrKCG56lk49vSFDqduyBhPBH53tf4DGIJnFE2WgBep5Xb2i7e3y4vAkpgv12kF1r6hJOF+9dCTDthyQGa4Ecynv4yACmUyALEi+WRqNIZllB+tbMoRoi8ahiupBEVji5V9Ecb41FdSXtGeGTZse+x3hJZa33aytZ3Pk5ho5AuXbIi/mdMPAZHAxHU2abOtgnYA/wYuQy/wke93Ig==
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=KdaGjJ6EHlSDjKNMZrgZ8+8QmMhrREuwfAklL69J/NY=;
 b=Z4hDDX4CwMw48/P0ejaYTSr7ZXOPOKVvtmUjbYaUotGgBEXAVwlNPrmt3uEwg/IN5un5+N55hNwFLtJd+pa2n79A0LT/40ZqCA4wQSrINwX/lBBHMOaFESybA02ncwtTiYqMnszF9lhsSV91KyKF6LKz499KoE0URQRxdmi9psU=
From: Luca Fancellu 
To: "Orzel, Michal" 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	
Subject: Re: [PATCH v4 6/7] arm/mpu: Provide a constructor for pr_t type
Thread-Topic: [PATCH v4 6/7] arm/mpu: Provide a constructor for pr_t type
Thread-Index: AQHbuRpqbs0x64sbw06OBQfYV4WEtLPFavYAgAAvLYA=
Date: Tue, 6 May 2025 12:56:11 +0000
Message-ID: <23A4DA59-A279-45ED-B81C-3EEE72B79DE8@arm.com>
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-7-luca.fancellu@arm.com>
 <42eab292-f9f6-4bc1-a011-c657544ebaf5@amd.com>
In-Reply-To: <42eab292-f9f6-4bc1-a011-c657544ebaf5@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|GV1PR08MB8714:EE_|AMS0EPF00000193:EE_|AM9PR08MB6067:EE_
X-MS-Office365-Filtering-Correlation-Id: 91dc7de6-6c7d-4cec-6df8-08dd8c9d7418
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?Y0xpbCtVOVczTmQydWJDTkMySHc5eWZiM0tLVkY1d0F1VEI4SU04TCtzdy9M?=
 =?utf-8?B?bHp3T09weTVXWVovOUhidFNiUkcyS2R1VnJuMVVybVdReGlyY2RtQXRBa3cz?=
 =?utf-8?B?cGVnaFZES2dMV3h3cUZwbGJaUVNzY3M3NWx6T1QzY0M5azR6Rjg4RVZOTHAy?=
 =?utf-8?B?QmxUNzBKQnZTZldnZkpKd1BpMC96cFNqR0hQcXVRTFZyOVFBQktBcHNRTEl1?=
 =?utf-8?B?NVR0ZUxlSW9MT21oTFhTd2lDalYrbm93UXVCNHJWYmFYNEtmNW5ac0w3dHZx?=
 =?utf-8?B?YnJvdnF1SHhOYUtFdnpueE5RZS9WWGhmTnZhZmcxTmVuUnpMYU9xMGFMYThs?=
 =?utf-8?B?amxCVm9CeGt6SmZFZXZneHkvQjFidkVWSG5qT2FnYWtMVlptaW9BVmZDV1BO?=
 =?utf-8?B?SE5WSllXbFh0a2RyV3NkTnhMNW82bGpLTEowU1J0cUZIbWRHcFBTZ1dacXFJ?=
 =?utf-8?B?Ri9NOXJJY3lxK0t2OTE1bUVQSEhjSjNnTEdLV1hWS2RYK1hXQ0xXZFlZU0pV?=
 =?utf-8?B?R2huYlN2TkVSWWtld1ROZzdDZ2RWRERqWVFJWDNFVTJSUWJIbGF2QTZzb0hp?=
 =?utf-8?B?V2M2OVRGblllekRoQnUxeEQxSmdvQm03Q25hOFB5L2xpWUxtOEZrTHRkaWtH?=
 =?utf-8?B?REF0WXdYWnRlL2xsT2Y4WURPMUlmSG5PWHJ3R0VCNm42SVlwVi91YlR5SEE3?=
 =?utf-8?B?aDM5RHVrVUhwSEw0MDZNUlprUnV1T21XK1FjQkV4UWpGYnBvT0NUeDhtcC8x?=
 =?utf-8?B?dDZQR2J6c1ZkSDFaSzBhY0dPR3ArMkhEZ0dZSUphSnI2N1VMazhLWEV6dXlY?=
 =?utf-8?B?TTBnZ0p1NkRZLzRabnNtV29XUGJwMkVCdDgrZHRkRkNEUncvZmVBUGNyM2w5?=
 =?utf-8?B?ajBOdElFTUlJdithMTZqOTkxZ050alZmdG1hWlorRWt6THYvcHQ5dFNUL0NC?=
 =?utf-8?B?YldqZnBFTUJrNlpZVXZ2MmhlSEdCQVhNdXJVeC9NVWRqQkF5UWhiM2ZRbTY2?=
 =?utf-8?B?RmFIK2hqM1JidVNpaHhkR05WTFZNZ1BvTml1aTJaOGFtYXBkaDBScXl6K04x?=
 =?utf-8?B?bmEzYW9tR0JJeFpBOW9QNEdZRjdPZU9Dc0JYTjlhM0kzczNXU0N3VU10NXFT?=
 =?utf-8?B?TG9ubURISlkweUwrcmtWTHVFc3NvakYrQkpvV2VwVzhLUzlNcmxORmF4Q0NL?=
 =?utf-8?B?Z09sMW12VDhHS0pvdCsrQzk4dGhRZ2h4U3VlOVdNVEhhMDlRblpjVVYwV3FI?=
 =?utf-8?B?RGhmRjNsRnJuQjJLUnc0Um92WWZQVmxNbmFtc0xyRk5wSEFiK2tFUWNkaXY1?=
 =?utf-8?B?UjdrOHVoSWVNV3k1R1FvN29hVjE1V2poV285UFVFamd0Z2p6WExRbGgyQ1lm?=
 =?utf-8?B?YjdRUjNkNWJMQVdsQUVweHArTlVVMEFoVWNpU1dINVBUaWhZZWlhZStxR1oz?=
 =?utf-8?B?U1IvdTVpQXNENndvR3UrSjE1MElaSjNpUW5FTkthYmp1NHFEQkRIaTVaRGsy?=
 =?utf-8?B?dlpiMVBXcWdRTEJoUDNUbytaZGFaY0VCQy92dG1IaVNIZ3EwaHE1ZitVelpQ?=
 =?utf-8?B?dEFSVXdUbUpiMDFjOUErUzBuRThhOFc4djJ6S0hjbThvL1hXWWxHWHZ4NDFS?=
 =?utf-8?B?c2wzalRjenVpWFdVODZ5YnJXdHJzVnBUclZsMkU3R3N1MWxCWkRXSlhQSEhr?=
 =?utf-8?B?K1FRUEJIaUlZcXFJOTQ1STRTVEt5ODN3RG1RdnVGVE1qUTd6TUhTblFSWDU2?=
 =?utf-8?B?Nkd0UUhrL3ZUUHB2b0JFeW1IUUtKUXlqM3JxdTFGMWs0VHRwUWowWng3Qm81?=
 =?utf-8?B?RHFFYmMyMU54blBaK3o1bVRMdnF5alVzNTRHUmJqbkdCZ0VVUlVaendxMFp3?=
 =?utf-8?B?ZHhmc2tZYWZXdVhaRTVIeCtkaFF6dW9hMlRBMUt5djM1eFdjMjFycnpQN3Y2?=
 =?utf-8?B?T0hMdStUZndwQSsyTXg4SXZHVHpyVVB0Y2s5RVVmUmZ2c0k5ZXhpbUhYMmJF?=
 =?utf-8?Q?VCWwtiL9/hCIiexGRuRNYvEfdEYYNg=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <3FEA5C432EB33542B9F509C40B343277@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB8714
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF00000193.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	64b6b354-f6d5-41b7-a50b-08dd8c9d6085
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|35042699022|14060799003|376014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?K00ycVV5MTRubW1SZDVrTjlhRmQvVEtkWFpBaGpORW9aRllzQVEvMVJNc3FL?=
 =?utf-8?B?NzJQVzFoUVUyNkdwdm93Q0hReHJQMWZmWjBJQ25BeDd3MkZhdkxhUXJINXhI?=
 =?utf-8?B?VlpVMjRuYVRYeVNnY1U3OUp3d2FUNmhGQ3BwbS9BSWZMMUtxSTJTRWZ5dkE0?=
 =?utf-8?B?cFhHM21mT1UyWEgzUGpYcGhuSFI1MTdVZWl4VzY0ZFo0V0RHRk44NDBvMmNB?=
 =?utf-8?B?clBqQmp3dGU5MjAvSlN6NnBtaW0ybkxiMW1yNWdBbUY4QS82cFJEdGRMSmQ2?=
 =?utf-8?B?WjRJSmE2eXRrYmEzeWlFWStoeVh1NTREcjNTNmpKWEs4YTJuOUUyWEVKUFo1?=
 =?utf-8?B?ZmRhcVVjV3hlRzVxRndJbXV3cmJpUld0WFRMZFFWdnpBZUdjTzNPZmNwWEVZ?=
 =?utf-8?B?ZTQ5YXVWSUhUaEp4L01SOVROV1FvR0tuRnpueU1LcFZuRHNueGpMQW9zRUJ0?=
 =?utf-8?B?WmplRStpeWI0K3c5MnJGcHJ2bmdrZlg3MkI3MVo0djdyNEg4bnNrRWJjak80?=
 =?utf-8?B?bUtIWkNwMzhTTkVCeFdkTk5YRTU2SHg5S1drOUt1dXBIbjhyN3dRdG1TSGNZ?=
 =?utf-8?B?SmpyQ3Q0NkRvUHpXaXJ1WEZ0VEJPRFBRUnN0T0Nja0pGTVltM3lvRmROdFVl?=
 =?utf-8?B?cEdLYWt2dTIxdWZMYUplbThPNWhMTUk1N2NEMjNiNjRWalR5UWlpREE0NlI4?=
 =?utf-8?B?MmJVcmdRMVlsTDFQY3UzalBpOFdYSHdRa0E2TVlTa3ROaVRaZEw2ZnRYZWtG?=
 =?utf-8?B?OU50SEgyNlNyU0t2RmViSjJWQnVieVlNQTFGOHJUUExOM0tjejJpcVVqbWVJ?=
 =?utf-8?B?UTU0WkZJSFdSUXV1NTltYTZNN0t5eDRSMmVZQ0JiYmhhN2pXR0hMc0RPMkV0?=
 =?utf-8?B?OHFzQ3IyZk15TisweEhJNVl0eThKakFtaXRKcjIwdkdmWk5ZdDZZUGtLRnMr?=
 =?utf-8?B?ODlIVnh3M0VhbUdzSGx4bE94aGlydWxQOWtBTmZobmpsemkyY2tBOGhMc3I1?=
 =?utf-8?B?a1NiVEplQnVRME8zRldWRVBseTdFb3h1ZmgxZVlQUjR3LzVGdExDVGNXalhB?=
 =?utf-8?B?aWxpS09zK0E2dUZXZTl1dXdQMkt1ZVFUTHpsbGE1RzJwQXNtcTlWQTlQWU1E?=
 =?utf-8?B?MUIzRTVWUXBrWnJSRi9RZXlNaG5ka2wvZWpwTVJMcnZCcWdCeTZTZ0E1d01n?=
 =?utf-8?B?VlJqNU95WDlVQnoxZkJ1SWFjV0pxOXRCbDQvQzdhcHpUVEtVTEZrR0JFejVr?=
 =?utf-8?B?WS9UWkxzdE1Eb1ZFYUhjVDFMaVdhRVp6NFlPOHBRQ1FuWVgrekV0V3FXdUU1?=
 =?utf-8?B?Q3FUdGx4QUhDUS9DcUdCN082TStEQWVvMzV4ZGtTVS9OMmQxS0grWCtHYkVj?=
 =?utf-8?B?WXJHZnpWUno1aGlRV01rSUxZa0RBMjdjTHVqNmhqeDFQTXR5RmZDTDgvVXlB?=
 =?utf-8?B?TzFrNGFMMUE0dCsrK1dLTHlJZzlSb3NMTThhTXJ1c1FXU0wwT3E3Ty9hWHpM?=
 =?utf-8?B?QjBaNHBvVG53RTFSc3ZYMGtBWDlpYVVMNjdQQU1kL0czeGdLYW15RllTcGpk?=
 =?utf-8?B?MTlMSVRERk15NEt3ZHBPWjlxdGloQitvdlhmZFBBdWxoaTFLcFNFcnNPd0hz?=
 =?utf-8?B?bjBobUNXdTVscDBBZm5IbDRmdkRuMHpwRDFyZDVmaHcxNGtWS25aZHI3VVAz?=
 =?utf-8?B?SUNiMkYyTG1YOUV6Z2txSEVBUjZmejB2ZXlTNS9oOVR2dTQ2Ukw2QzNqWG5H?=
 =?utf-8?B?eGV5bVc5Z3NjTWNVaU1ZK1lEKzhmbldJNk5tRGJ6ekhJY1JjRnVtUGVUcmVQ?=
 =?utf-8?B?M3pKYkJSMjY0dnFKM1BWTjI2ek9rbm81S3Jjc1poV0prc2lSQU1rVmorUHRG?=
 =?utf-8?B?NEVJQlJsL0ZLMVNIVWl3Qy94UXgyYVFuWk5raHQ4OWFPQkdhRHcvZWFSOTVC?=
 =?utf-8?B?b1hQVS9Dd0pKUjlyQ2p6RXZ1Zm9QOWpVK09RbjBxVkdJemMrL29pR1UvMHdq?=
 =?utf-8?B?L1hTYmd0TDVkWktJN2V6aG5zbmlMdW9mcVRzT1pWQ1FaU1BQY24vR0JSOFk1?=
 =?utf-8?Q?ZB0Av+?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(35042699022)(14060799003)(376014)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 12:56:44.1038
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 91dc7de6-6c7d-4cec-6df8-08dd8c9d7418
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:
	AMS0EPF00000193.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6067

SGkgTWljaGFsLA0KDQo+PiANCj4+ICsvKg0KPj4gKyAqIEV4Y3V0ZSBuZXZlci4NCj4+ICsgKiBT
dGFnZSAxIEVMMiB0cmFuc2xhdGlvbiByZWdpbWUuDQo+PiArICogWE5bMV0gZGV0ZXJtaW5lcyB3
aGV0aGVyIGV4ZWN1dGlvbiBvZiB0aGUgaW5zdHJ1Y3Rpb24gZmV0Y2hlZCBmcm9tIHRoZSBNUFUN
Cj4+ICsgKiBtZW1vcnkgcmVnaW9uIGlzIHBlcm1pdHRlZC4NCj4+ICsgKiBTdGFnZSAyIEVMMS9F
TDAgdHJhbnNsYXRpb24gcmVnaW1lLg0KPj4gKyAqIFhOWzBdIGRldGVybWluZXMgd2hldGhlciBl
eGVjdXRpb24gb2YgdGhlIGluc3RydWN0aW9uIGZldGNoZWQgZnJvbSB0aGUgTVBVDQo+PiArICog
bWVtb3J5IHJlZ2lvbiBpcyBwZXJtaXR0ZWQuDQo+PiArICovDQo+IFdoeSBkbyB3ZSBuZWVkIHRo
aXMgY29tbWVudD8gSWYgYW55LCB3aHkgZG8gd2UgbmVlZCBFTDEgZGVzY3JpcHRpb24gaWYgdGhl
IG1hY3JvDQo+IGlzIEVMMj8NCg0KVWhtIHllcyBJIHRoaW5rIEkgY2FuIHJlbW92ZSBhbHRvZ2V0
aGVyIHRoaXMgY29tbWVudA0KDQo+IA0KPj4gKyNkZWZpbmUgUFJCQVJfRUwyX1hOX0VOQUJMRUQg
IDB4Mg0KPj4gKw0KPj4gI2lmbmRlZiBfX0FTU0VNQkxZX18NCj4+IA0KPj4gLyogUHJvdGVjdGlv
biBSZWdpb24gQmFzZSBBZGRyZXNzIFJlZ2lzdGVyICovDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gvYXJtL2luY2x1ZGUvYXNtL21wdS5oIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL21wdS5o
DQo+PiBpbmRleCAwZTBhN2YwNWFkZTkuLjdiODJmMTBkMzM2YiAxMDA2NDQNCj4+IC0tLSBhL3hl
bi9hcmNoL2FybS9pbmNsdWRlL2FzbS9tcHUuaA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1
ZGUvYXNtL21wdS5oDQo+PiBAQCAtMjQsNiArMjQsMTAgQEANCj4+ICNkZWZpbmUgTlVNX01QVV9S
RUdJT05TX01BU0sgICAgKE5VTV9NUFVfUkVHSU9OUyAtIDEpDQo+PiAjZGVmaW5lIE1BWF9NUFVf
UkVHSU9OX05SICAgICAgIDI1NQ0KPj4gDQo+PiArLyogQWNjZXNzIHBlcm1pc3Npb24gYXR0cmli
dXRlcy4gKi8NCj4+ICsvKiBSZWFkL1dyaXRlIGF0IEVMMiwgTm8gQWNjZXNzIGF0IEVMMS9FTDAu
ICovDQo+PiArI2RlZmluZSBBUF9SV19FTDIgMHgwDQo+IFRoaXMgbWFjcm8gYW5kIHRoZSBwcmV2
aW91cyBvbmUgYXJlIHVzZWQgb25seSBvbmNlIChJIGFsc28gY2hlY2tlZCB5b3VyIGZ1bGwNCj4g
dHJlZSkgYW5kIGNhbm5vdCBiZSBzZXQgYnkgdGhlIGNhbGxlci4gV2hhdCdzIHRoZSBwdXJwb3Nl
IG9mIHRoZSBtYWNyb3MgdGhlbj8NCj4gV2h5IGNhbid0IHdlIHNldCB0aGVzZSB2YWx1ZXMgaW4g
cHJfb2ZfeGVuYWRkcigpIGFuZCBhZGQgY29tbWVudCBuZXh0IHRvIHZhbHVlDQo+IHRoZXJlPw0K
DQpTdXJlLCBJ4oCZbGwgZG8gdGhhdA0KDQo+IA0KPj4gKw0KPj4gI2lmbmRlZiBfX0FTU0VNQkxZ
X18NCj4+IA0KPj4gI2lmZGVmIENPTkZJR19BUk1fNjQNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJj
aC9hcm0vaW5jbHVkZS9hc20vbXB1L21tLmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vbXB1
L21tLmgNCj4+IGluZGV4IGUyMjM1ZTU2OGU4MS4uMjk2ZmU3NGM1ZDYxIDEwMDY0NA0KPj4gLS0t
IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL21wdS9tbS5oDQo+PiArKysgYi94ZW4vYXJjaC9h
cm0vaW5jbHVkZS9hc20vbXB1L21tLmgNCj4+IEBAIC03NSw2ICs3NSwxNiBAQCBleHRlcm4gdm9p
ZCByZWFkX3Byb3RlY3Rpb25fcmVnaW9uKHByX3QgKnByX3JlYWQsIHVpbnQ4X3Qgc2VsKTsNCj4+
ICAqLw0KPj4gZXh0ZXJuIHZvaWQgd3JpdGVfcHJvdGVjdGlvbl9yZWdpb24oY29uc3QgcHJfdCAq
cHJfd3JpdGUsIHVpbnQ4X3Qgc2VsKTsNCj4gSGVyZSBhbmQgLi4uDQo+IA0KPj4gDQo+PiArLyoN
Cj4+ICsgKiBDcmVhdGVzIGEgcHJfdCBzdHJ1Y3R1cmUgZGVzY3JpYmluZyBhIHByb3RlY3Rpb24g
cmVnaW9uLg0KPj4gKyAqDQo+PiArICogQGJhc2U6IGJhc2UgYWRkcmVzcyBhcyBiYXNlIG9mIHRo
ZSBwcm90ZWN0aW9uIHJlZ2lvbi4NCj4+ICsgKiBAbGltaXQ6IGV4Y2x1c2l2ZSBhZGRyZXNzIGFz
IGxpbWl0IG9mIHRoZSBwcm90ZWN0aW9uIHJlZ2lvbi4NCj4+ICsgKiBAYXR0cjogYXR0cmlidXRl
IGluZGV4IGZvciB0aGUgbWVtb3J5IHR5cGUuDQo+PiArICogQHJldHVybjogcHJfdCBzdHJ1Y3R1
cmUgZGVzY3JpYmluZyBhIHByb3RlY3Rpb24gcmVnaW9uLg0KPj4gKyAqLw0KPj4gK2V4dGVybiBw
cl90IHByX29mX3hlbmFkZHIocGFkZHJfdCBiYXNlLCBwYWRkcl90IGxpbWl0LCB1bnNpZ25lZCBp
bnQgYXR0cl9pZHgpOw0KPiBoZXJlLiBQbGVhc2UgZG9uJ3QgdXNlIGV4dGVybiBpbiBwcm90b3R5
cGVzLiBJdCdzIG5vdCBuZWVkZWQuDQoNCkkgc2VlIHdlIGhhdmUgYSBtaXhlZCB1c2FnZSBvZiB0
aGlzIGluIGFyY2gvYXJtIGFuZCBpdOKAmXMgbm90IGRvY3VtZW50ZWQgdG8gZG8gb3RoZXJ3aXNl
DQppbiB0aGUgY29kZSBzdHlsZSwgaW4gdGhpcyBjYXNlIEkgd291bGQgcHJlZmVyIHRvIGJlIGV4
cGxpY2l0IHVubGVzcyBpdOKAmXMgYSBzdHJvbmcgb2JqZWN0aW9uIG9uIHlvdXIgc2lkZSwNCmxl
dCBtZSBrbm93Lg0KDQoNCj4+IA0KPj4gK3ByX3QgcHJfb2ZfeGVuYWRkcihwYWRkcl90IGJhc2Us
IHBhZGRyX3QgbGltaXQsIHVuc2lnbmVkIGludCBhdHRyX2lkeCkNCj4+ICt7DQo+PiArICAgIHBy
YmFyX3QgcHJiYXI7DQo+PiArICAgIHBybGFyX3QgcHJsYXI7DQo+PiArICAgIHByX3QgcmVnaW9u
Ow0KPj4gKw0KPj4gKyAgICAvKiBCdWlsZCB1cCB2YWx1ZSBmb3IgUFJCQVJfRUwyLiAqLw0KPj4g
KyAgICBwcmJhciA9IChwcmJhcl90KSB7DQo+PiArICAgICAgICAucmVnID0gew0KPj4gKyAgICAg
ICAgICAgIC5hcCA9IEFQX1JXX0VMMiwgICAgICAvKiBSZWFkL1dyaXRlIGF0IEVMMiwgbm8gYWNj
ZXNzIGF0IEVMMS9FTDAuICovDQo+PiArICAgICAgICAgICAgLnhuID0gUFJCQVJfRUwyX1hOX0VO
QUJMRUQsICAgLyogTm8gbmVlZCB0byBleGVjdXRlIG91dHNpZGUgLnRleHQgKi8NCj4+ICsgICAg
ICAgIH19Ow0KPj4gKw0KPj4gKyAgICBzd2l0Y2ggKCBhdHRyX2lkeCApDQo+PiArICAgIHsNCj4+
ICsgICAgY2FzZSBNVF9OT1JNQUxfTkM6DQo+PiArICAgICAgICAvKg0KPj4gKyAgICAgICAgICog
QVJNIEFSTTogT3ZlcmxheWluZyB0aGUgc2hhcmVhYmlsaXR5IGF0dHJpYnV0ZSAoRERJDQo+PiAr
ICAgICAgICAgKiAwNDA2Qy5iIEIzLTEzNzYgdG8gMTM3NykNCj4gSXQncyBhIGJpdCBvZGQgdG8g
cHJvdmlkZSBoZXJlIHRoZSBtYW51YWwgZm9yIEFybXY3Lg0KPiBBbHNvLCBvdXIgZ2VuZXJhbCBh
ZHZpY2UgaXMgdG8gdXNlIHRoZSBsYXRlc3QgcmV2aXNpb24uDQoNCkkgc3VzcGVjdCB0aGlzIHdh
cyBjb3BpZWQgZnJvbSBtZm5fdG9feGVuX2VudHJ5LCBJ4oCZbGwgdHJ5IHRvIGZpbmQgdGhlIGxh
dGVzdCByZWZlcmVuY2UgdG8gdGhpcy4NCg0KPiANCj4+ICsgICAgICAgICAqDQo+PiArICAgICAg
ICAgKiBBIG1lbW9yeSByZWdpb24gd2l0aCBhIHJlc3VsdGFudCBtZW1vcnkgdHlwZSBhdHRyaWJ1
dGUgb2Ygbm9ybWFsLA0KPj4gKyAgICAgICAgICogYW5kIGEgcmVzdWx0YW50IGNhY2hlYWJpbGl0
eSBhdHRyaWJ1dGUgb2YgSW5uZXIgbm9uLWNhY2hlYWJsZSwNCj4+ICsgICAgICAgICAqIG91dGVy
IG5vbi1jYWNoZWFibGUsIG11c3QgaGF2ZSBhIHJlc3VsdGFudCBzaGFyZWFiaWxpdHkgYXR0cmli
dXRlDQo+PiArICAgICAgICAgKiBvZiBvdXRlciBzaGFyZWFibGUsIG90aGVyd2lzZSBzaGFyZWFi
aWxpdHkgaXMgVU5QUkVESUNUQUJMRS4NCj4+ICsgICAgICAgICAqDQo+PiArICAgICAgICAgKiBP
biBBUk12OCBzaGFyYWJpbGl0eSBpcyBpZ25vcmVkIGFuZCBleHBsaWNpdGx5IHRyZWF0ZWQgYXMg
b3V0ZXINCj4+ICsgICAgICAgICAqIHNoYXJlYWJsZSBmb3Igbm9ybWFsIGlubmVyIG5vbi1jYWNo
ZWFibGUsIG91dGVyIG5vbi1jYWNoZWFibGUuDQo+PiArICAgICAgICAgKi8NCj4+ICsgICAgICAg
IHByYmFyLnJlZy5zaCA9IExQQUVfU0hfT1VURVI7DQo+PiArICAgICAgICBicmVhazsNCj4+ICsg
ICAgY2FzZSBNVF9ERVZJQ0VfbkduUm5FOg0KPj4gKyAgICBjYXNlIE1UX0RFVklDRV9uR25SRToN
Cj4+ICsgICAgICAgIC8qDQo+PiArICAgICAgICAgKiBTaGFyZWFiaWxpdHkgaXMgaWdub3JlZCBm
b3Igbm9uLW5vcm1hbCBtZW1vcnksIE91dGVyIGlzIGFzDQo+PiArICAgICAgICAgKiBnb29kIGFz
IGFueXRoaW5nLg0KPj4gKyAgICAgICAgICoNCj4+ICsgICAgICAgICAqIE9uIEFSTXY4IHNoYXJh
YmlsaXR5IGlzIGlnbm9yZWQgYW5kIGV4cGxpY2l0bHkgdHJlYXRlZCBhcyBvdXRlcg0KPiBEb2Vz
IHRoaXMgQXJtdjggY29tbWVudHMgbWFrZSBzZW5zZT8gV2UgZG9uJ3Qgc3VwcG9ydCBBcm12NyBN
UFUuDQo+IA0KPj4gKyAgICAgICAgICogc2hhcmVhYmxlIGZvciBhbnkgZGV2aWNlIG1lbW9yeSB0
eXBlLg0KPj4gKyAgICAgICAgICovDQo+PiArICAgICAgICBwcmJhci5yZWcuc2ggPSBMUEFFX1NI
X09VVEVSOw0KPj4gKyAgICAgICAgYnJlYWs7DQo+PiArICAgIGRlZmF1bHQ6DQo+PiArICAgICAg
ICAvKiBYZW4gbWFwcGluZ3MgYXJlIFNNUCBjb2hlcmVudCAqLw0KPj4gKyAgICAgICAgcHJiYXIu
cmVnLnNoID0gTFBBRV9TSF9JTk5FUjsNCj4gQUZBSVIgTUlTUkEgQyByZXF1aXJlcyBldmVyeSBj
bGF1c2UgdG8gYmUgdGVybWluYXRlZCB3aXRoIGJyZWFrLg0KPiBUaGF0IHNhaWQgSSBkb24ndCBy
ZW1lbWJlciBpZiB3ZSBhY2NlcHRlZCB0aGlzIHJ1bGUuLi4NCg0KSeKAmWxsIGFkZCBhIGJyZWFr
LCBpdCBkb2VzbuKAmXQgaHVydC4NCg0KQ2hlZXJzLA0KTHVjYQ0KDQo=


From xen-devel-bounces@lists.xenproject.org Tue May 06 13:06:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:06:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977208.1364253 (Exim 4.92)
	(envelope-from )
	id 1uCI09-0003t9-PY; Tue, 06 May 2025 13:06:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977208.1364253; Tue, 06 May 2025 13:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCI09-0003t2-Ml; Tue, 06 May 2025 13:06:25 +0000
Received: by outflank-mailman (input) for mailman id 977208;
 Tue, 06 May 2025 13:06:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCI08-0003sr-F0
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:06:24 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20605.outbound.protection.outlook.com
 [2a01:111:f403:2418::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e53a3229-2a7a-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 15:06:18 +0200 (CEST)
Received: from SJ0PR03CA0162.namprd03.prod.outlook.com (2603:10b6:a03:338::17)
 by PH7PR12MB5733.namprd12.prod.outlook.com (2603:10b6:510:1e0::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Tue, 6 May
 2025 13:06:10 +0000
Received: from CY4PEPF0000EE3C.namprd03.prod.outlook.com
 (2603:10b6:a03:338:cafe::22) by SJ0PR03CA0162.outlook.office365.com
 (2603:10b6:a03:338::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.24 via Frontend Transport; Tue,
 6 May 2025 13:06:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE3C.mail.protection.outlook.com (10.167.242.13) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Tue, 6 May 2025 13:06:09 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 May
 2025 08:06:08 -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" 
X-Inumbo-ID: e53a3229-2a7a-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=g9UpS4O2oJZDBEjkLkae3ZwOvpzH54ltI74exizIyZoz15kWClGWgItOKemYLN8KFx63CnoqvhEmwrRUG88lGbKaaOAhKqk/iLAJmIVev9pY72RJSnzLdlSA17RjNNhsgJZUiJp7m7FnvLrmy2ewnFy8ly+MMxID932EcKPXPzQW1AM9ECJZI4rIittLqOhxV0zpInfv9VYzAvE4vhecgIm/G9a92TCQeb/J3A+zN7gpfD4cJvAnx7s7GqnS8kdlXBzWVh7kEioFUwGmhYHbBOjkERa/zZAQCDwjiPK3LiIgJ1G9IXkBtBRerXsgZnal7kCjCXhtygfzG9+AaRGEjA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WMTfbjbRSRbJSCz/G78wTXTYJLYG82cA7qT9YHesGnM=;
 b=b+1V5oxBvgpgT4E/Eiy8pRVKUP8mNN0/+285+OtlDSCvBR/zdzAfdx/MBiQztYdQrtGGZoPOkH8c48YTRBvpPcTOyS0xS3CDKquBd7MJUZ7A/qygQ6ipJn0xKV2RuMvOeSex0GMs6SRjamdmXgOL0/3F6ggjcktAR8rHP3HSqB3ijj00nMTWO7XDQqWEgGwuEeQDkGTtdzhyTbvUZHu10BocnqcrfXMPMgiOLZmiBqOxQ1PEcfjVvSBurXa62CDFM8xDUByTvkUrpezT9I1eG0SuEg9Ze1toWH8thpBFikLhiQuILhG86m9ViQbYzgr5wzarLvJrAls1H3xBb3mYow==
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=WMTfbjbRSRbJSCz/G78wTXTYJLYG82cA7qT9YHesGnM=;
 b=0gxAUtBYBwAWZLOsF8Z7uJcGJYoVbt4k3ox8HerYAvwQ53x4Zl9i1S+MgOOd1CKHv3TpxXcRGJfwHaBo4X8UdwqUe5eWK3gndXvYCgxRF68/zlPXEIL8f3cRax+E5i5B1JqTlXFOMcAiqxUjLVo8QFuRG8ofvsnIecDYEIfcUzE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 6 May 2025 15:06:06 +0200
Message-ID: 
CC: Andrew Cooper , Juergen Gross
	, Xen-devel 
Subject: Re: Mapping memory into a domain
From: Alejandro Vallejo 
To: Demi Marie Obenour , Xen developer discussion
	
X-Mailer: aerc 0.20.1
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
In-Reply-To: <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE3C:EE_|PH7PR12MB5733:EE_
X-MS-Office365-Filtering-Correlation-Id: 47db2f35-0aac-4075-c269-08dd8c9ec534
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dkRIS2hNSjZJdnFzYXFkeEVPNzZUelo2Y3VIdUhLemk4SVVIbE55YTVKVlc4?=
 =?utf-8?B?M0ovQ2tSZTE1VmllKzdTaEVabHJPTWpFbmZ5SDJ0K0Y1QWdjRElyWDFJUXNm?=
 =?utf-8?B?OWFQNzZlRUdkNUVTZFVXTm5pYTJtL2hvaVNrcFI1eldXdkpnZzMvUVhLeFZk?=
 =?utf-8?B?ZHlHYS9GTmpkYy9IUGtZNzF0MGc4MHZwRDdQbmJlZEg4bElkYkZRbFMxYVNt?=
 =?utf-8?B?VTM2OXRsM256SzlUZkpSREtkaTIwN2VHU1RFNURnajhhZVJUU0M5byttZVZG?=
 =?utf-8?B?b3FEcGE1SmdndjRacVJKR2JMTXYrcy91cHUwS0dwV25NTE9LOTh3OW1rNktm?=
 =?utf-8?B?SHY0cHdiWjBtNFlUMGFhT0FpQjVoSVRvNUJFZGJvVGxnL0ZFZUEySTQ0UUY3?=
 =?utf-8?B?TG0xY0oycE5uTEE1ZzVrbi9MZXFsa0tTUkNkSUJWNnlYbzVKMHRnT0p5b1k5?=
 =?utf-8?B?a2lMQy9jY29NRzZpc2FteWZMVGdjc1QraG4xeGtoaDlvM2lUZjYwQ0tnV1I4?=
 =?utf-8?B?OGRHVUVBTXBhdGVPK0QvbGxwZXFVdDhoUkNINUkxdWtLbHJnUmFyeEJ2Y1lV?=
 =?utf-8?B?bnZVK0VYcnNzZ1drd0lXQXBzaktOOGgzOGUyQmVmL3Z3Nk5OL0t1Y0lkRW5Y?=
 =?utf-8?B?TTJ5LzB2ZE5YdnY2clBpQWg1dDlDUnc1Z1FocDVnZlBzN21BazhaajZNMFZ5?=
 =?utf-8?B?TXhuMHdKajluSTFjcTdSOWQyNGs4K3BOT0QzbzJabzF3RksvU0svU1Q5eTdm?=
 =?utf-8?B?YmFtLytUUnMzUmIwYmpVck14UVdud09QQW5qeUpaaXdqYk9VK3NESTFTcnVK?=
 =?utf-8?B?eTJTamFodm9zcm13QVNxa0wvT2VCVTMyRWxROFprOWU4STBwazR5c3EwbVlq?=
 =?utf-8?B?cE1oRWhSRWdZckk1elZUUjBMT3pZU2FmNVVGcmV0cmgvRVY4UmhGc0RuTGpX?=
 =?utf-8?B?WXlqaEY0WWFrN1dnME1OTU5MbG9lem12NHZETjFvTjJmTCtLQm0zbUt6YkZk?=
 =?utf-8?B?MXdocG9aZzl5dUdFaVFFdy84SGFmNDJqV3RhUUJDZ0lCRUQ3OWh2T2lIRDY0?=
 =?utf-8?B?N0pSdmpReG9EM2FlODhPZmRzNVBDZnVtRHVCVXN4d0VMYnc2dmt0c3pyVkR3?=
 =?utf-8?B?b0E5NnJsNFRPeitBQjZEZk03MFV2ZmRjVCt0ZEIrUVgvOW1PNDJqc0xxa3JK?=
 =?utf-8?B?Y3ZnVlp5dXc0WWZXUXRYL1o5a2NzUVRMR09BTG9QcnYrenQ4Q1JkRCsvQ21S?=
 =?utf-8?B?RnZ1VTBoVFpvSEd2R3NKZFRDM3V2SWJkWWVzU2NEb0hjYVpSZXpDc0JHd2pq?=
 =?utf-8?B?TlhEV25nVzcyUW9WNWdZdEh6TFNrcU1CTlJkQStXVnRCcHhNWnhvUlE5MmhX?=
 =?utf-8?B?dTF4K2phamk0b0ZkeWtTendWN0hxMWxlZVd6Sjh4bXlCWjQzVE0zeTdCVjZj?=
 =?utf-8?B?YTRXVGllcERtRDFUbi83OVpWUzl3L3ZaMzBvdFFhd0Zia3N5cmwyZklQWTJI?=
 =?utf-8?B?aU1KNm9PSGdUaEJaVitYOHpiRllHZnVaTUdPU1dra0RydVM2b1d4bmphYllV?=
 =?utf-8?B?ZTJlZW5WMGNWbEtkVGM2amZFR1J3OVZPendkK1ppV1VISm9qbURYMW5CVEta?=
 =?utf-8?B?eG5zYWFFYStyS25EeFJhcW9wb3RsRmxGMm5XdDY2bnUxYStCdHhTS1ludjMw?=
 =?utf-8?B?bktHSnlsWkNBL3Z5bDNBSWZiT2lMQ1pvU2JtNEM4blVtY0xxdDlvRXJ2ZWxZ?=
 =?utf-8?B?Q1FZUHVFdTNnLzN4ZTJ3eVl4WFVGWWtuWlVoQUczNS90L2xSeDRqL3p5aEJa?=
 =?utf-8?B?MVM3NnFQbmtaQ093aTNKQWdMQTFyYzVsREhRdjVYVFA1Ui9TRjRPNWRpd1dD?=
 =?utf-8?B?ZnZRSmlNd3lqSVdtVHhYOGgrcFhEUFI1M29qKzlKbmsyME5YOFdkUS9Nekp5?=
 =?utf-8?B?d1pzaG5wMTBZY2FndGpEYU5ROUVCYStZa2dhWTZsNWM1c29pOUZocDFDUW44?=
 =?utf-8?B?dHJPOTJmcU5XQ2M0eGh4RkkvVXV2aEY0cERFNHBVNnIza3dsMUlZQk1UUzla?=
 =?utf-8?B?RnFMRXlVSFhBUitzVGd6UGdGYkdRcDNDOWdiZz09?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 13:06:09.6299
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 47db2f35-0aac-4075-c269-08dd8c9ec534
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EE3C.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5733

On Tue May 6, 2025 at 3:02 AM CEST, Demi Marie Obenour wrote:
> On 5/5/25 7:32 AM, Alejandro Vallejo wrote:
>> I suppose this is still about multiplexing the GPU driver the way we
>> last discussed at Xen Summit?
>>=20
>> On Mon May 5, 2025 at 12:51 AM CEST, Demi Marie Obenour wrote:
>>> What are the appropriate Xen internal functions for:
>>>
>>> 1. Turning a PFN into an MFN?
>>> 2. Mapping an MFN into a guest?
>>> 3. Unmapping that MFN from a guest?
>>=20
>> The p2m is the single source of truth about such mappings.
>>=20
>> This is all racy business. You want to keep the p2m lock for the full
>> duration of whatever operation you wish do, or you risk another CPU
>> taking it and pulling the rug under your feet at the most inconvenient
>> time.
>>=20
>> In general all this faff is hidden under way too many layers beneath
>> copy_{to,from}_guest(). Other p2m manipulation high-level constructs
>> that might do interesting things worth looking at may be {map,unmap}_mmi=
o_region()
>>=20
>> Note that not every pfn has an associated mfn. Not even every valid pfn
>> has necessarily an associated mfn (there's pod). And all of this is
>> volatile business in the presence of a baloon driver or vPCI placing
>> mmio windows over guest memory.
>
> Can I check that POD is not in use? =20

Maybe, but now you're reaching exponential complexity considering each
individual knob of the p2m into account.

>
>> In general anything up this alley would need a cohesive pair for
>> map/unmap and a credible plan for concurrency and how it's all handled
>> in conjunction with other bits that touch the p2m.
>
> Is taking the p2m lock for the entire operation a reasonable approach
> for concurrency?  Will this cause too much lock contention?

Maybe. It'd be fine for a page. Likely not so for several GiB if they
aren't already superpages.

>
>>> The first patch I am going to send with this information is a documenta=
tion
>>> patch so that others do not need to figure this out for themselves.
>>> I remember being unsure even after looking through the source code, whi=
ch
>>> is why I am asking here.
>>=20
>> That's not surprising. There's per-arch stuff, per-p2mtype stuff,
>> per-guesttype stuff. Plus madness like on-demand memory. It's no wonder
>> such helpers don't exist and the general manipulations are hard to
>> explain.
>
> Is this a task that is only suitable for someone who has several years
> experience working on Xen, or is it something that would make sense for
> someone who is less experienced?

The p2m is a very complex beast that integrates more features than I
care to count. It requires a lot of prior knowledge. Whoever does it
must know Xen fairly well in many configurations.

The real problem is finding the right primitives that do what you want
without overcomplicating everything else, preserving system security
invariants and have benign (and ideally clear) edge cases.

This was the last email you sent (I think?). Has any of the requirements
changed in any direction?

  https://lore.kernel.org/xen-devel/Z5794ysNE4KDkFuT@itl-email/

Something I'm missing there is how everything works without Xen. That
might help (me, at least) guage what could prove enough to support the
usecase. Are there sequence diagrams anywhere about how this whole thing
works without Xen? I vaguely remember you showing something last year in
Xen Summit in the design session, but my memory isn't that good :)

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Tue May 06 13:25:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:25:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977226.1364263 (Exim 4.92)
	(envelope-from )
	id 1uCIIr-0007Bf-EJ; Tue, 06 May 2025 13:25:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977226.1364263; Tue, 06 May 2025 13:25: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 1uCIIr-0007BY-AW; Tue, 06 May 2025 13:25:45 +0000
Received: by outflank-mailman (input) for mailman id 977226;
 Tue, 06 May 2025 13:25:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCIIq-0007BS-JJ
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:25:44 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20611.outbound.protection.outlook.com
 [2a01:111:f403:2009::611])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9b40fbf8-2a7d-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 15:25:42 +0200 (CEST)
Received: from PH7PR17CA0018.namprd17.prod.outlook.com (2603:10b6:510:324::9)
 by BL3PR12MB6450.namprd12.prod.outlook.com (2603:10b6:208:3b9::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Tue, 6 May
 2025 13:25:34 +0000
Received: from CO1PEPF000044FB.namprd21.prod.outlook.com
 (2603:10b6:510:324:cafe::e8) by PH7PR17CA0018.outlook.office365.com
 (2603:10b6:510:324::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Tue,
 6 May 2025 13:25:34 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CO1PEPF000044FB.mail.protection.outlook.com (10.167.241.201) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8746.3 via Frontend Transport; Tue, 6 May 2025 13:25:34 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 May
 2025 08:25:33 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 May
 2025 08:25:33 -0500
Received: from [172.18.31.235] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 6 May 2025 08:25: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" 
X-Inumbo-ID: 9b40fbf8-2a7d-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MjG+3AjydGwgmZVV3J+yfkJXUX3ZSNp6EyuJ0lqik0Wo4V+6coTSMJmTsD3/sHDgnriXa4uz4RKB2N1kgmGML7OLXy0czhirBJXhRQix//plO8Zmx19c/XVZob1/0rtoDm6nxMVmZTmpFGdpDBWteQgNyf63yJaBaCRrIIXzMMXZxjcyvr/3f7mILUxzzkUMr/gwtV7R3zoxWq5eDmcSUgHkjsdohSqoH244Nl73ON3Hgy5uDEOCT2bYGLKl8gSJYGzx86L39yuRtRlHmrZjgA554/2MDSUFyrUTO9QQG+w1jarjA4w4CeVQXrJqXf5+NtVUOWIhcGsJdAGyU0nbSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wyxoX3FAE1CQMyFUF6hDwdSs5kpJGUO/aKF67GNvgd0=;
 b=cLSzSf8fTHO+222ejSSOY4BeGYzwo2e3FFHJ/AMpJw+rV58SJaRubqo1T3o4WGSNslovy9wxLCG2HXsUTchOj1oTPU0ouWNYjzcE45vZh+VVSS3jBv0MLKuFADK9/ZErOC6DNflmttIblNOqQv9VqeYVOEOl5jmRkYMnFM5Vl7KbR0PTnx4nImwfypgys85ASl5zGl7sCSY+AG8prYi1ilgLmh6mAg4V0H/HguHqZIZwf2fIMc3PI9HvALQIi/FXkhfDaof9KblZ+jH1F6V9HOxtF61z9WLh1MSdBOJps4609ei4ncc7AT+tGbm65EdJAbAJLWQNEeZS89LSYGs2yA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=wyxoX3FAE1CQMyFUF6hDwdSs5kpJGUO/aKF67GNvgd0=;
 b=a3IFoy5GCsgY++63XgbjvSf5Hg173h3wpt+ixsjxlq6ZkO7ACc04g8D1IAbhv1aZHVtHSPNZ7a661mEp8Uh5WuU2oRp9SjCP6auEqcECPo8bUfafvGSjjM6s7+47llrI6XxA0sAmHVSeQozXmUm8pXGYZLih/UG6Nynj9ozOQCU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <63d6ff3c-bed5-4a7f-bd3e-50b99b5a6f4b@amd.com>
Date: Tue, 6 May 2025 09:25:34 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xenbus: Allow PVH dom0 a non-local xenstore
To: Stefano Stabellini 
CC: Juergen Gross , Oleksandr Tyshchenko
	, ,
	
References: <20250503131935.1885-1-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: CO1PEPF000044FB:EE_|BL3PR12MB6450:EE_
X-MS-Office365-Filtering-Correlation-Id: 65f4bd14-cf7d-48c0-3a2c-08dd8ca17b69
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NFc1LytnQWdsRE5MdVJCeUtxd1ltaStpTndRaGtFVC93NjRtaXdWSlVTWFZz?=
 =?utf-8?B?dVpCaHYvSExmUzgvSUZHWkIwdVNubThFbnM3WkFSQTRNcjhWdVFqM2dkN1o5?=
 =?utf-8?B?a0hpUG5sNTZGVndEWnZtNDNOUzExV2M2Q1RGVXo4U3R1aS9aemJvMTUvZTlV?=
 =?utf-8?B?Zkx3V2pMR09pbGdwUFNDQmhjN2l3bkxKZUhxKzVUMUdvRWlSNU10RkRMYkNh?=
 =?utf-8?B?a0tuQXlsbG11ZkE4Vkt5UVdrL2F3M3RXd0s4VEsvRms2Zk5SNHBlclVBK1Y2?=
 =?utf-8?B?TkYyN0FRZmhWbVNSRlY4SXZSR2Q4eDBNaHhETTR5Nzd0NmRUV2lPVGNodGV1?=
 =?utf-8?B?SkVoVGdKMlV6L1F2MFhHa0F2T2pncHVDUWlVVjl1bE9sZ3MwVzcxNFBoOHpL?=
 =?utf-8?B?T3lNRjRBWWdGQjlHbnM5VjFzdDYvMWZlMWliS1dZNkYrUjdkYUtCSWpRb3lF?=
 =?utf-8?B?bjRCNUtvL1RNcHhFY0Y1bWIzclZnTENuMjNKbFVDR1BBaEFmSllKM3hIMUZs?=
 =?utf-8?B?ei8xWVRqTjlPWTVuSkMxemxxakFRQzRCbEd3Vi9PN3lWNXFKbWJTN2hSckF1?=
 =?utf-8?B?ZXhqK3IzbzhEVUhCYzBTenFDVVM0SG8rL2R4Yll3b3pWc1dLMWFlUFp1RC9k?=
 =?utf-8?B?QUVubS9RalZUK01aR2xBWGxjUmlaMms2bUZVN3QyRExobU1EMlpnOHdkNmdX?=
 =?utf-8?B?L2dWZXRFczB0Q3hhRU9hbHhLMjExUG9vUnc0VFdTMHl0QmhjNTlkNktzUXdm?=
 =?utf-8?B?dHJITFRLSnl5Skpsay9rRzV6WTd1dkk5UnJOY29IdWIrOHVSYnl6eWpNMllM?=
 =?utf-8?B?U2RyMTFJT1cyQXl0YTJLV093V1hYdkt3Q3JlcHVreTZKWnJrSkNZSXJIQUN1?=
 =?utf-8?B?S3c1OEhycmhvWHlBaUlSWVUwa0pNRUdUNWZSUmc3K1NLSk0zTS8veGlyQlND?=
 =?utf-8?B?aVAzQXlXa0drb3dpYjJBeUFuVmRLTklnd2Noay9rRWltclJCL251TDE0Zk1R?=
 =?utf-8?B?RnUzWDZyeVprU0lvNzk3SElIT1VmRFZHSE9pNDJSbFJGYXlwYjNhb0VqRGNY?=
 =?utf-8?B?MjBYSnY5T2tCbENuMGJmQTJ1cW96SFBRZFMyNWwxQTMwRyt4RmNIckcyZ1I0?=
 =?utf-8?B?NUcxcFdtL2thMTE2aDduNW5QQVlnQzVDS1VIOUk3VkxQOCt2ZHJkdG5iaVRt?=
 =?utf-8?B?TDB2Ui8zTU1acFZ2Y0V2ZG5vSDlxaFRTQjNpL1FxWm5DRW45ZHpoNEQxT0ZO?=
 =?utf-8?B?Z0p1YTBUb1BUZ3JpQVBTejBBeG1DVzJjbVIrbkpVdVBVd1J5cHZJWFFCQU8z?=
 =?utf-8?B?ekRLLzV4RkJUUEsyRlVabklIMUY3b1h4VGp3Sy96dWxyeTRCU1MydnE3dG5M?=
 =?utf-8?B?R3JVVkZ4cDRha0U5b2U3Z3lkS2g3OXNIaWJJbG5GZ3E3dW9jays1VGpaRkJH?=
 =?utf-8?B?R1JSZlpGVkVBQzRTZjJrbkpSU2k3SkVtVnZ2SUkrNkNzRnNDU3dmRmFRRXB1?=
 =?utf-8?B?Q2dBcjZYbTdhQVhoTWtOcTczYjhxcDBOOU93RE5vZjBjSTBmYkhZeDJYMTVX?=
 =?utf-8?B?RDRVUkw2VnIwYUtVTTFaWW96a0U2YnVxZmhMVlRqZTBIK3drTms4RVYwaWZM?=
 =?utf-8?B?ajdiSEFseG9ZbmQ4aE9uUy9mL093cklENVBwL2lQL1hpa2I2L1R3RjVFMjRu?=
 =?utf-8?B?ZEsvRi8wTGxLZVFOdG1QbWFHNXdEM3BIQStJbmxQb0ZSeDl0dndGVktzRWti?=
 =?utf-8?B?cHJIRWtKeDdJbnU0RjdCTnl5T0pjSFRKYVlMMHZSaUF6MGYyUCtUWnU3VEdR?=
 =?utf-8?B?QkFoTktTd2ZFVGdXdXFjSDRuN044bU9udWxXUUNsNDV6a0ExUDgzYUY1b0lq?=
 =?utf-8?B?QjlyeEZYbmQ4dHcwN3BJT0paSkppbEwvZ0RJZW9iYTVHdHlxNUkzWmRFMW42?=
 =?utf-8?B?bnpGOFZvUUM4SHRLQjJLR3ZEUk9qQ3Bwa1VyOW4vdlpVRHBIWHphOUxINXdp?=
 =?utf-8?B?Qkx6WUtHZEJYeERYR0UzelJzR0M1M2VzSzZqUndmYnVUcGtPbFRwTmdCaVZW?=
 =?utf-8?Q?yPmxA0?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 13:25:34.3133
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 65f4bd14-cf7d-48c0-3a2c-08dd8ca17b69
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000044FB.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6450

On 2025-05-05 16:44, Stefano Stabellini wrote:
> On Sat, 3 May 2025, Jason Andryuk wrote:
>> Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
>> currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
>> xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
>> late init path.
>>
>> Drop the use of xen_initial_domain() and just check for the event
>> channel instead.  This matches the PV case where there is no check for
>> initial domain.
>>
>> Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
>> chance that high bits are set for the 32bit event channel.
>>
>> Signed-off-by: Jason Andryuk 
> 
> Reviewed-by: Stefano Stabellini 

Thanks, Stefano.  But I'm wondering if this might break ARM enhanced 
no-xenstore.

> 
>> ---
>>   drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
>>   1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
>> index 6d32ffb01136..7604f70ee108 100644
>> --- a/drivers/xen/xenbus/xenbus_probe.c
>> +++ b/drivers/xen/xenbus/xenbus_probe.c
>> @@ -966,9 +966,15 @@ static int __init xenbus_init(void)
>>   	if (xen_pv_domain())
>>   		xen_store_domain_type = XS_PV;
>>   	if (xen_hvm_domain())
>> +	{
>>   		xen_store_domain_type = XS_HVM;

ARM would have everything set to XS_HVM...

>> -	if (xen_hvm_domain() && xen_initial_domain())
>> -		xen_store_domain_type = XS_LOCAL;

...and only dom0 set to XS_LOCAL.

>> +		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
>> +		if (err)
>> +			goto out_error;
>> +		xen_store_evtchn = (int)v;
>> +		if (!v)
>> +			xen_store_domain_type = XS_LOCAL;
>> +	}
>>   	if (xen_pv_domain() && !xen_start_info->store_evtchn)
>>   		xen_store_domain_type = XS_LOCAL;
>>   	if (xen_pv_domain() && xen_start_info->store_evtchn)
>> @@ -987,10 +993,6 @@ static int __init xenbus_init(void)
>>   		xen_store_interface = gfn_to_virt(xen_store_gfn);
>>   		break;
>>   	case XS_HVM:
>> -		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
>> -		if (err)
>> -			goto out_error;
>> -		xen_store_evtchn = (int)v;
>>   		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
>>   		if (err)
>>   			goto out_error;
                 /*
                  * Uninitialized hvm_params are zero and return no error.
                  * Although it is theoretically possible to have
                  * HVM_PARAM_STORE_PFN set to zero on purpose, in 
reality it is
                  * not zero when valid. If zero, it means that Xenstore 
hasn't
                  * been properly initialized. Instead of attempting to 
map a
                  * wrong guest physical address return error.
                  *
                  * Also recognize all bits set as an 
invalid/uninitialized value.
                  */
                 if (!v) {
                         err = -ENOENT;
                         goto out_error;
                 }

IIUC, this !v check is for enhanced no-xenstore to end up in XS_UNKNOWN. 
  I'll have to re-work to handle that case.

Regards,
Jason


>> -- 
>> 2.34.1
>>



From xen-devel-bounces@lists.xenproject.org Tue May 06 13:29:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:29:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977237.1364274 (Exim 4.92)
	(envelope-from )
	id 1uCIMu-0007lI-Tq; Tue, 06 May 2025 13:29:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977237.1364274; Tue, 06 May 2025 13:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCIMu-0007lB-Pl; Tue, 06 May 2025 13:29:56 +0000
Received: by outflank-mailman (input) for mailman id 977237;
 Tue, 06 May 2025 13:29:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCIMt-0007l5-OI
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:29:56 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on20615.outbound.protection.outlook.com
 [2a01:111:f403:2614::615])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 313cae17-2a7e-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 15:29:53 +0200 (CEST)
Received: from DUZPR01CA0085.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:46a::17) by AS8PR08MB7372.eurprd08.prod.outlook.com
 (2603:10a6:20b:448::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.29; Tue, 6 May
 2025 13:29:51 +0000
Received: from DU6PEPF0000A7DD.eurprd02.prod.outlook.com
 (2603:10a6:10:46a:cafe::ff) by DUZPR01CA0085.outlook.office365.com
 (2603:10a6:10:46a::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Tue,
 6 May 2025 13:30:03 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DU6PEPF0000A7DD.mail.protection.outlook.com (10.167.8.37) with Microsoft SMTP
 Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.18 via
 Frontend Transport; Tue, 6 May 2025 13:29:51 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 GV1PR08MB7873.eurprd08.prod.outlook.com (2603:10a6:150:5c::22) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8699.24; Tue, 6 May 2025 13:29:18 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 13:29: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" 
X-Inumbo-ID: 313cae17-2a7e-11f0-9eb4-5ba50f476ded
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=BRs8sUHXuh1SsT4ZOaqH4DKBbJ1p9dEdljL1T9bqrYnZjxjxBJdTzCBRnh3jgoh2m3ceQhWf7tUcpX1BMPrKQtVizcc567mdQ3tASineArlCK3nlS6Yr5zXGJqnCp5ywhUNJF+w/B2tHqosxEKvi8+e+YIHu3wNFf/xnGD4jKR892skk5aK/1okqmH4JrqLQ7CWhwhspU0b+rg/GCF1jnLckwtLJkfiBYVVJWZxTbBmLpGsSmyuzjvh1olnItEdmwIQyRoK7S2tPc65QMNLZXZEJDLfgxFX8c+iEd/yY/6cHVy2WH+k31QYfbeGPXqaJbv09TDwpsy/B9xpIr8wezg==
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=pmjY6iGeOun0UzDRJpGpXg+sMePHwJaM54RhWYLTa6g=;
 b=xLnmrq7r9tMWY/vxEVqTqFdWDppYCAIcqFw8JJcucT12yttSafBgj+SPpa0f+tndZeWcsGukY01QKcHBWoOltJdOqP3Opehjv5cicmzRGjD2cQZDV1BYSm3NACR4Zm3It0rfg/Cnlo6V91QcUmtawdQ9HV45VgMiNoCljkoJW4XVwwcQX1hUERHTWykoxTbrxfzYksBoNWaR2QtKjy7HT9TXhowdJlHZ5HpLUt2AMyXor4A83xAV/SqOjeqp9iNvIBW20iCgWFGVC0sxLcJIYoC5o8JCUhbpeZrbE2b6T86xo51uYMFaschaasLHErp+ut0szSl6YqTEeecRArPJ0w==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.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=pmjY6iGeOun0UzDRJpGpXg+sMePHwJaM54RhWYLTa6g=;
 b=ZPEv6a3Ifh/P6o+B/g5BA/sqxZyRGVjdcOdpTpQpMti/dXW0ePPTYC2MNzDy9DZz7bGOCF9PP2xI2ALKoC96/QMWvua/Hs8jEAlr4Q9mFnI5BxQssjyhSYFms6scw61flyDocLADqsYEzQ8ZKovTONLT0TG8du+2uZ9bz4sz+u4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=i40+U+uzm5wmI7a83gsZaVg4IpPoP7oBkmBbX09wH1h/T4q8spQdZAQCt96mmmlQC3p1GwM/j1rV1YV3IhbGl7J2wNDrn2wEvCP34lfSxh1fFh2ZJHeDSHF9JQZOkq42WQiFA+R2Vmg6ERHQcFJZXYT5cyn174G+uh9r6jwttTJA2ydU8b58FW6qpfNcC81ndtZ4g59jXqo107UAh16NxR0+xkqpnB9kEN9a06HELaecrgq2V/xZaW5I6ROipba5TvH6D3U+UEOGPiWmg7FeGIZEU1wt+jnQDJys1RRtnou6MGqdEj5blYDQIkjnbE9e2gT0loZDYVSN+nL+TkI3eg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=pmjY6iGeOun0UzDRJpGpXg+sMePHwJaM54RhWYLTa6g=;
 b=k6q8HA2nNstUkio9Hl3vtz+/jMTZEziNDuU1fFAevuMfvE94if8Fm/CAyuaF/nNC3rP5WWl7u2CTWbBhOIYjJ/vQoYBkBp4xtk9KjoDSB0iPuQCU19TYOQtkdJDQNRvj1wRT0YsClJTXkVKc4S+6GU+5ygXAf6O5DX2scMdRM2Yhrv22A3bXVHQvF/uWP4YTnJKtBfWBsZZ3KjhmXPPw0uYxtg3cKjAsbXTE8paPNt+6hUhoeIXEl8T621WIQ8xNDWJfq0gepU9zsjxiVzN5t4shs64B7M9bapxBh4yOfvdrjPUZLdYdJNBnvBAa5Fx0nIzLTP0eT8FLhBy6xUHe1w==
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=pmjY6iGeOun0UzDRJpGpXg+sMePHwJaM54RhWYLTa6g=;
 b=ZPEv6a3Ifh/P6o+B/g5BA/sqxZyRGVjdcOdpTpQpMti/dXW0ePPTYC2MNzDy9DZz7bGOCF9PP2xI2ALKoC96/QMWvua/Hs8jEAlr4Q9mFnI5BxQssjyhSYFms6scw61flyDocLADqsYEzQ8ZKovTONLT0TG8du+2uZ9bz4sz+u4=
From: Luca Fancellu 
To: "Orzel, Michal" 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	
Subject: Re: [PATCH v4 6/7] arm/mpu: Provide a constructor for pr_t type
Thread-Topic: [PATCH v4 6/7] arm/mpu: Provide a constructor for pr_t type
Thread-Index: AQHbuRpqbs0x64sbw06OBQfYV4WEtLPFavYAgAA4bIA=
Date: Tue, 6 May 2025 13:29:18 +0000
Message-ID: <8B6DB54A-3D2E-4310-B567-8EE4F8472377@arm.com>
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-7-luca.fancellu@arm.com>
 <42eab292-f9f6-4bc1-a011-c657544ebaf5@amd.com>
In-Reply-To: <42eab292-f9f6-4bc1-a011-c657544ebaf5@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|GV1PR08MB7873:EE_|DU6PEPF0000A7DD:EE_|AS8PR08MB7372:EE_
X-MS-Office365-Filtering-Correlation-Id: 9df2b5f1-dcbd-4971-0595-08dd8ca21481
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|1800799024|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?VmFUb0EydHluM0V0QnVBS0NmN2hQTEYrUzJ5YWdoVFNNY0xiOW9Uckp6SXZZ?=
 =?utf-8?B?MkR3dC9MSDcyUDJiNzB5VHVkOTM2aFdHNk9IKzh5LzlRTW9zc3Y3cmk0anlZ?=
 =?utf-8?B?ZkFIVzMxN0hWOG5jcmk1R2VZL2RLV1pLdTIrekIya3Frenp3WDFrN2daNXpH?=
 =?utf-8?B?L3Y5TVk3TzBpcnNyNEs5UFBHbFlnQmNPYnN6T2ZnV1NVWXIvSE45OE1Ga05z?=
 =?utf-8?B?ZDRLcHEwVEZheUZObmRDTURDVWpEZ0dCM0JMNHdGdUlJRCtaVDN3Ty96cXZB?=
 =?utf-8?B?dHlzUU5yYms2RmdpOEZ3bVFxYWpmcStZenRBKzBsN3ZQSDNZTGNTa3NXenBq?=
 =?utf-8?B?azZkZGI4SnN1S2dibGY3WHVVMFdOL0R4OVNLaG9ZeDV3Lys2U0tvOGJHTjRB?=
 =?utf-8?B?SGREbUlmUFdiR3R5Z0ZjMEJja0FTNVVWQTJIclNsTTJWU1pJTGV6bXhYeGJj?=
 =?utf-8?B?UDA4cHM4Q1ZlTEdva0gzOCtJeitVTnhUcWMremlld09vUm1sNEJNdlBNMmUr?=
 =?utf-8?B?MlpRaWN2blhhQjFoL05rMlJSRkNJeUhtMy85bCtVT1EzQlN4OUJlNWE0T2U5?=
 =?utf-8?B?ZXVnOTNhUXNHY2xDdHp2ODlOd25IRE1uYjAvakQ4bm9mYVYzNFU2eU5OSXp6?=
 =?utf-8?B?UjBXMDRZY0h0bFd1U0ttN0V4U2Qya3RxejUwTkI1WjEyMUxsaW1PaVh0QjNn?=
 =?utf-8?B?eUFQQjA5bE5zSFFFendLTVh0SWF0ekZiZUs4QWpzckdSeHE3aGZ0NzBxTWgy?=
 =?utf-8?B?YVZVUkR2M0U1RDJnU2habFBNSGJhODkyVTB3M0wxdkJEclUxWjMvclV5WVhH?=
 =?utf-8?B?Tm5VVi9YOERYNkN6dHZmN01iT3dmNmU2MmpSVDgrZ1oxZ2RBY0VoZFVyZVI0?=
 =?utf-8?B?Q2p6NHR2RjQ0UmZTcHAySXZ5ZGF2Rkw3Yk9jWWNVRmJvbjVacDBYaUpvVFhE?=
 =?utf-8?B?ME9QaExNSXF2VXBRTUZNc3RRbWhUSTZXRTUrdlY1ZlJ5RTdCdGlYSEZLbzdL?=
 =?utf-8?B?Rndnbmp4SXkyR2RDdnJya3lGRy9NYkpJZWFqM01peWEwU3B0aTI2a2xNRW1H?=
 =?utf-8?B?UUZ2RE4wUWJSMWlDTHpWRVdHUnRoT2lYazQvQmU0SjU4Ykg5eldSN3BZMk9Z?=
 =?utf-8?B?RU51S240UVliaWlzQjQ4d3Y3NGN0ZFBQbjZyWGtQVzBQa0ZjOEdISk9HMkF6?=
 =?utf-8?B?YnorRGY4MHl4M3pDd09uU0pyWHhqV04zbjE1ajY5RFAyVWhieDdYZEU0MnA1?=
 =?utf-8?B?Tm85Kzg4dDd4SGdFZ1V1MUNYdklsbnJhSFhxSndINng2MHIxYk4zb2kxRE9M?=
 =?utf-8?B?S1VtNi9wREIyWmR3ZStVL3JvUFdFRXpKWFZlREhNa3o2VjRCMERmeDJsZ1dv?=
 =?utf-8?B?UmJ3bEZ4UUx0MzhuWTM5SnVDSnM1MjE3ZkR3Y2UweVI4ZEU0M2hqWWt4a2VY?=
 =?utf-8?B?Y09WSmN0R2RoMkNvQmV0TVk2SG1nNDhvc01IUkdWT0kvNHhMZTdxT3IyLzhk?=
 =?utf-8?B?cU5MSHMzZi9PM3hQZFBTZ2pveTI5enhZQkVEc1BjZ1dmUUd6Uy9SZ2JjYjhL?=
 =?utf-8?B?REo1bE5kRmVCOVhVMkFETEtHWU5uVFNCZWxzVnMwUXlzOW41N3BlLzZWUUZY?=
 =?utf-8?B?WWhxa2JaUXhWY0F5M3ZsVm4vSFcxWCtFclJPNDNTdUZWNWIvSGswRHdSNlBt?=
 =?utf-8?B?ODByajRPNnJ4SlA2UndCd3FkMVBVQkszZ0RKdnZEUC8yUlJxSzVQMTNjVzNp?=
 =?utf-8?B?cjFkMkx3RnQrNjJpRTdqcitrN3MyOXhjV3EzYm83b3p6Z0RNQzhXRTRCU0pV?=
 =?utf-8?B?Z3NIS2NDc3FQOFpaMzBnMXpsdDRSZmxhaTZoVVQ1SjFTODdkWW45Wm9rOWZj?=
 =?utf-8?B?Yno1Y1BzbEFjTDI1cG1qbVY3SDBvWksxUG5DU21YQW1uUzRwS25EMHBkMVpN?=
 =?utf-8?B?cklwVzVsanoydUhnbWhIV0FCeHA3aVQ0UkMwcTQvTDFMVzFqY0Y3V2NsNG5C?=
 =?utf-8?Q?u1IYQxzcPobYtH8WyEavbXDlm4YHac=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <59E74DDA0F1B9C439B7BD7A14445712D@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB7873
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF0000A7DD.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	b1ef09fa-1fe8-4e55-1f93-08dd8ca200c4
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|14060799003|35042699022|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cERDbEZDZEFrUGdTLzdKZjVUeXM1a0ZoWU9aYjF4WkUwY0hJTm5mRUIvUWRt?=
 =?utf-8?B?V05LcG1ZTFQ0dENIOGI1NEprcWJmRnBWSkxwd3ZnRm56NmFXK0YwbDZDQnc5?=
 =?utf-8?B?ai9ZNCtiS2kzOXlnVjBRdWtmN1BFcnlsNDdJYlZPTGdTeVNVVkdWZDcwd1NP?=
 =?utf-8?B?Qy9TVE5oUW1FNERZVitjY2xVTXEvb3ZJVTRzRmF3aXZaQzJiaXZwdno2a3E0?=
 =?utf-8?B?R2h4SW9vcTB6aU54MVNmRGFGbDhhZmFRam5ncHVqQlFMa0plMVBRRStNSVJy?=
 =?utf-8?B?VnY4NEdLd3RwUDdVbXh2alpiSmNsVWMvZVUxVWN5RW9rbmFwMkRFRHNBem1m?=
 =?utf-8?B?Z0tBQmNTUzg2WnRYZDJzejVUZE1jaENLTjdWWkN1NW5UUHBSVnRpNlMxMklp?=
 =?utf-8?B?YVJoL29XeDFib2JrZDFrcXhidmt0M2NZSWtlZGk3eU5IMkMrZGJrM0NCak5N?=
 =?utf-8?B?YVlwTW0rZUFUWkM2RWZUVXJ3YVNYYjM4YXdsVCsxYmFXZVBLaFRKR1NnbHA4?=
 =?utf-8?B?QnhMUEhMMWZ1VnZtc1BnMXg0WkJFRFI1Wld1emQ2c1pPUXU5YXRBQ2U3NWF3?=
 =?utf-8?B?dkVIbjE3SEtXSm82VXhpTEVCZis0dVRCM1dlY2ljNTZyWUlyRE81aDFYYkla?=
 =?utf-8?B?MUlBL0tVZUs0SnE1MXF5ck43aHFmcmRCVUJ0NzZZRVJzL3VUTjE1eHdYd1JH?=
 =?utf-8?B?TFlNeERISVBKYW9BRm9kd1RrU1RYZVRuRHBjMGlEbDhONXU3aGUzazBUTFBW?=
 =?utf-8?B?VEE4NHlkYWtMS1E5TTU5STdDekdkTWZ0ODFETzJvcStuM05wREQ5TzZ3YnBQ?=
 =?utf-8?B?T1YwS2Q1b3lQSjZMc1pNR2cxSW9TczcxaVg1NjBFemZjbFp3ZTR3YWx5aVNJ?=
 =?utf-8?B?T1dNSWRyQ2NJTmVrSnRQMEViN1dHWCtXQk05a1R1NTZITVhVWDE0OCtuM0Y0?=
 =?utf-8?B?U0ZxTkM1cFZqWGRnTXpaeUpENlBEN0xqVlBtQnU0L1BZejZMNWVOQ0JteHRQ?=
 =?utf-8?B?KzRPQmJNcGN1aEJSSjEwcGFVUW0rV3JiZmR1L20xWmFxb2FtQ0ZVR2xtdEJO?=
 =?utf-8?B?dnJSLy8rZndsR2RZejZzK3llbzFXK012cmFsbXN6bENsNWtYWCtQZzBQYVls?=
 =?utf-8?B?ZlJsSnpjVU5aR1BIbFVtdmhIdkY2MjBOTHhKVmo4bXBRdnZrUUZtUjJJekFP?=
 =?utf-8?B?MlZCV2ZpZnlsYnJ4bjEwZFE5WFhlR1crYlVPK3hEVXZUR1RVamZhNWorZlVz?=
 =?utf-8?B?VmV5ek5zcnp6K2hFczNXcW5wRkVCY3lIRUZ5RzhRUUZwcmVwN1d1L1hqMFp0?=
 =?utf-8?B?TG8yZnZ3MU1zdGFnT09idHZwL3BFTnVwRlhUd0JMdUs3SVNwVjhuUWxCclEr?=
 =?utf-8?B?cStORmcwZXpGSk1kRWpPaFJDK2MwcXU4MkRCT0g1c0xHeGlpSVBvbUxHNU4x?=
 =?utf-8?B?MlkzTlZqdmRGY3JHZnhYQVlmWmpBK3pXUkk2Wm4zOVNwRlBSamUxN1duMkZL?=
 =?utf-8?B?R2VaMmU0OHZLeUJlaU9pS29TbWlwN0xQR1NRaUgxc1JxNXh4Zk9yMmxiNnpX?=
 =?utf-8?B?aVAyeW1USDU0WjYxN09meFdGWDNhRURQR2dDYTVJWXVuVzVheFk4bmxGaTFV?=
 =?utf-8?B?WWhHeThnUlBEOXd1MFc1L2JuRy9RVVp6Wmt2S0JyS0NSL0tDOFRUQ3VrVU9R?=
 =?utf-8?B?ckNOblpNZ1lpSDZveWltYlVhUmd4WTcwMFRMNlFDRDVWTGVvdGVFT3ZKNVdv?=
 =?utf-8?B?ek9hak45WUFXMUVIdnRNNFQxVmxxNmpBZmd0WDlOaFByc1o4V28reEl2NkJ5?=
 =?utf-8?B?bGhwTG8yR3FBcDZLVVhGWlNHT2VXdi9LVjZJOUtpKyt3RHBCd3dPdysyNXV6?=
 =?utf-8?B?THJVeHYyM0twTm8vcTRiZEk4Zk1FOUIyeUVXdE90Snp4dlIzTnVWK3ZMN3Zx?=
 =?utf-8?B?ZnRWZEV3Q3F2cXdhRnVlZEpoQnJIL3FwamtTODNwUER0VkhJNUZRTVhXY1Bl?=
 =?utf-8?B?Rkp3dWZUNUdRaGI4NWJCRHFPT2ErQzV1LzNUNWdzNGEyWXlOSTJjVnlSNWtF?=
 =?utf-8?Q?2WwA3Z?=
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)(36860700013)(376014)(14060799003)(35042699022)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 13:29:51.2087
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9df2b5f1-dcbd-4971-0595-08dd8ca21481
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:
	DU6PEPF0000A7DD.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7372

DQo+PiArICAgIHN3aXRjaCAoIGF0dHJfaWR4ICkNCj4+ICsgICAgew0KPj4gKyAgICBjYXNlIE1U
X05PUk1BTF9OQzoNCj4+ICsgICAgICAgIC8qDQo+PiArICAgICAgICAgKiBBUk0gQVJNOiBPdmVy
bGF5aW5nIHRoZSBzaGFyZWFiaWxpdHkgYXR0cmlidXRlIChEREkNCj4+ICsgICAgICAgICAqIDA0
MDZDLmIgQjMtMTM3NiB0byAxMzc3KQ0KPiBJdCdzIGEgYml0IG9kZCB0byBwcm92aWRlIGhlcmUg
dGhlIG1hbnVhbCBmb3IgQXJtdjcuDQo+IEFsc28sIG91ciBnZW5lcmFsIGFkdmljZSBpcyB0byB1
c2UgdGhlIGxhdGVzdCByZXZpc2lvbi4NCg0KSeKAmW0gdGhpbmtpbmcgYWJvdXQgcmVzdHJ1Y3R1
cmluZyBpbiB0aGlzIHdheToNCg0KICAgIHN3aXRjaCAoIGF0dHJfaWR4ICkNCiAgICB7DQogICAg
LyoNCiAgICAgKiBBUk0gQVJNOiBTaGFyZWFibGUsIElubmVyIFNoYXJlYWJsZSwgYW5kIE91dGVy
IFNoYXJlYWJsZSBOb3JtYWwgbWVtb3J5DQogICAgICogKERESSAwNDg3TC5hIEIyLjEwLjEuMS4x
IE5vdGUgc2VjdGlvbik6DQogICAgICoNCiAgICAgKiBCZWNhdXNlIGFsbCBkYXRhIGFjY2Vzc2Vz
IHRvIE5vbi1jYWNoZWFibGUgbG9jYXRpb25zIGFyZSBkYXRhIGNvaGVyZW50DQogICAgICogdG8g
YWxsIG9ic2VydmVycywgTm9uLWNhY2hlYWJsZSBsb2NhdGlvbnMgYXJlIGFsd2F5cyB0cmVhdGVk
IGFzIE91dGVyDQogICAgICogU2hhcmVhYmxlDQogICAgICoNCiAgICAgKiBBUk0gQVJNOiBEZXZp
Y2UgbWVtb3J5IChEREkgMDQ4N0wuYSBCMi4xMC4yKQ0KICAgICAqDQogICAgICogQWxsIG9mIHRo
ZXNlIG1lbW9yeSB0eXBlcyBoYXZlIHRoZSBmb2xsb3dpbmcgcHJvcGVydGllczoNCiAgICAgKiBb
Li4uXQ0KICAgICAqICAtIERhdGEgYWNjZXNzZXMgdG8gbWVtb3J5IGxvY2F0aW9ucyBhcmUgY29o
ZXJlbnQgZm9yIGFsbCBvYnNlcnZlcnMgaW4NCiAgICAgKiAgICB0aGUgc3lzdGVtLCBhbmQgY29y
cmVzcG9uZGluZ2x5IGFyZSB0cmVhdGVkIGFzIGJlaW5nIE91dGVyIFNoYXJlYWJsZQ0KICAgICAq
Lw0KICAgIGNhc2UgTVRfTk9STUFMX05DOg0KICAgICAgICAvKiBGYWxsIHRocm91Z2ggKi8NCiAg
ICBjYXNlIE1UX0RFVklDRV9uR25SbkU6DQogICAgICAgIC8qIEZhbGwgdGhyb3VnaCAqLw0KICAg
IGNhc2UgTVRfREVWSUNFX25HblJFOg0KICAgICAgICBwcmJhci5yZWcuc2ggPSBMUEFFX1NIX09V
VEVSOw0KICAgICAgICBicmVhazsNCiAgICBkZWZhdWx0Og0KICAgICAgICAvKiBYZW4gbWFwcGlu
Z3MgYXJlIFNNUCBjb2hlcmVudCAqLw0KICAgICAgICBwcmJhci5yZWcuc2ggPSBMUEFFX1NIX0lO
TkVSOw0KICAgICAgICBicmVhazsNCiAgICB9DQoNCndoYXQgZG8geW91IHRoaW5rPyBJdCB3aWxs
IGhhdmUgdGhlIGZhbGwgdGhyb3VnaCBjb21tZW50IGFuZCB3aWxsIGFsc28gZXhwbGFpbiB0aGUg
TFBBRV9TSF9PVVRFUiB2YWx1ZSBzZXQNCmZvciBib3RoIG5vcm1hbCBtZW1vcnkgbmMgYW5kIGRl
dmljZSBtZW1vcnkuDQoNClBsZWFzZSBsZXQgbWUga25vdy4NCg0KQ2hlZXJzLA0KTHVjYQ==


From xen-devel-bounces@lists.xenproject.org Tue May 06 13:30:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:30:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977239.1364282 (Exim 4.92)
	(envelope-from )
	id 1uCIN3-0000HM-3n; Tue, 06 May 2025 13:30:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977239.1364282; Tue, 06 May 2025 13:30: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 1uCIN3-0000GL-0e; Tue, 06 May 2025 13:30:05 +0000
Received: by outflank-mailman (input) for mailman id 977239;
 Tue, 06 May 2025 13:30:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCIN2-0007l5-58
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:30:04 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 37727125-2a7e-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 15:30:03 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43ce70f9afbso49665835e9.0
 for ; Tue, 06 May 2025 06:30:03 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099ae0cafsm13863913f8f.19.2025.05.06.06.30.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 06:30: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" 
X-Inumbo-ID: 37727125-2a7e-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746538203; x=1747143003; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=ONMJPfb5UP5y6Kl3++JQNjAP78w7eZw+RJt1c4Un/qk=;
        b=txYU5XAocljpTeV2yLA2BtbTWRKi3HEOmuTFu4PkVPpQwSq6ue372COZ/k9oJW0tY9
         DRn/xuydGsPUmel8ebPwWdT71i/R2kF+A3H4dwZshkLJ0sYBxZQNcKQ+VxjmV6+0o1li
         moHziYhNBaUngyI/+2oDNMqPv/rzKu7mQeIGQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746538203; x=1747143003;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ONMJPfb5UP5y6Kl3++JQNjAP78w7eZw+RJt1c4Un/qk=;
        b=dvydN6DKiWTSeh1SD4qaIpojQI5MlPVgpkrMynZxx+x+FkGRgG7ZSU3UI9T2Rv4Esf
         e8ciWa5rieQ0eIoUSW6nRfIkKee3cNWelT1SQGcVGC9+0VUS7Dhl1On7eFp2UTkzQn9Q
         CmO15syq2T5+wq/A87IIeYyu9Tflf+epYbSa9Pp3QQ+cxap2A3CCcNJx7133aoZZvkTG
         yTjkFv62GO9v/uvrPX7HIBAZzUe15b5Vblp2kNEmmegE1pxQB6/k1DxF6medsD+LQHCj
         5pj9MLJmDvqHff+yWNlN07uRotL7sGc12ymsL8cU3i+gmTOeYPzPoVrp7KQTyGEMwNb1
         ETtg==
X-Gm-Message-State: AOJu0YxbIy5lBWcHgir88oVFHvpG/d56ulcxFBTvnyrvixDJYgPwJVT6
	2cBHMrNTK14qz5mKwwmqxPDucZTOZptYHu9eaiMHKzKrbZb2nIiKLA+5+0nUJiU=
X-Gm-Gg: ASbGncs7OtOMh2X+i61wzEqAotrVM+htlM8SaDQ20qZ/MJv1VrivLZ9OrHM867OrGB3
	dEGDwCyyTugyEqJxBjITFVpkBHMM4at1V32Wt5FP5qPqQWMUz3z1yw9OaepzxrAxZglu37rf28/
	c6IAB+gJt1i3pHc5InIlJsSN3J1vzVVgYllyH1VXeOheoPyLh/1JOQWyKk0H8bToVzRWP/MPOu0
	oCbvozs02MdMg5dujap1zruxRGyyvG1C2GbOJBBrS5bx70WyLwjJldlzFeKhqYghIfDBZV8m2Wr
	9YNVI8mtDRul+HTBMmm7qZp/QRN/dzOq3U9cvk4f7FEhHA==
X-Google-Smtp-Source: AGHT+IHGZjU6QD78g4RF8L7+HVM0nBOkbPwm5f9mZ4OFfVKiMLGXF1dWjhkh0IJs10SK5sO51RHrFQ==
X-Received: by 2002:a05:600c:3b23:b0:43c:f597:d582 with SMTP id 5b1f17b1804b1-441c48aa2f7mr89030825e9.1.1746538202746;
        Tue, 06 May 2025 06:30:02 -0700 (PDT)
Date: Tue, 6 May 2025 15:30:01 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v3 01/11] vpci/header: Move emulating cap list logic into
 new function
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-2-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250421061903.1542652-2-Jiqian.Chen@amd.com>

On Mon, Apr 21, 2025 at 02:18:53PM +0800, Jiqian Chen wrote:
> No functional changes.
> Follow-on changes will benifit from this.
> 
> Signed-off-by: Jiqian Chen 

Acked-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 13:39:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:39:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977262.1364292 (Exim 4.92)
	(envelope-from )
	id 1uCIWR-0001qV-4j; Tue, 06 May 2025 13:39:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977262.1364292; Tue, 06 May 2025 13:39: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 1uCIWR-0001qO-2B; Tue, 06 May 2025 13:39:47 +0000
Received: by outflank-mailman (input) for mailman id 977262;
 Tue, 06 May 2025 13:39:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCIWQ-0001qI-0E
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:39:46 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8f9a09b4-2a7f-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 15:39:40 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-39129fc51f8so3751523f8f.0
 for ; Tue, 06 May 2025 06:39:40 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a0b3331cb0sm437303f8f.65.2025.05.06.06.39.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 06:39: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" 
X-Inumbo-ID: 8f9a09b4-2a7f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746538780; x=1747143580; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XLvFoTcwz9K5wgfhFJVpd3ZPGknE7d6jx4QLrMIgBkE=;
        b=rMbiI+VeEwbYb+u3keWobY7uHk5JQp5LKBFdoocJhoeqsR8/RG7tOloLWQ8A3rPnRp
         1Gt3FGWczcpVwU+hUbYIU585Y0zd/n42QoxGNQ1r5eN2Ax5YCl1hXU7765FW6JYSkgs3
         /y4wPG6wm+FFfZw/HccfDuxBZHrHpw6q29xOI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746538780; x=1747143580;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XLvFoTcwz9K5wgfhFJVpd3ZPGknE7d6jx4QLrMIgBkE=;
        b=jeHolSlQJlirAoe6sAGxzV40DRdh0kGzQuqHqTRWm6xT5TV9WqwWyTCmxHgljSPzoP
         est1iaZ3tuQtpM4exGypn/7BOjp6YKHCjWHyoJMZ/nzWVa4Nmk0kNvSafyWc2mF5wqJt
         i8GZQXnV7axfjssrpB+sRbD+maNlfu2fY52i4o7yATeEUeCORzcPVUemyTIz+ifuX8DX
         88Sl+dbujA443zxQ+IpMlXgdk5+wMh0f6uA/zJHDXr3W1o+8ApvxTUlTRWNzaUMKRYpW
         2hvZCE/igKMYBWJeiYbOlneYVfdRZiNSiDN31WV1X+4tp26tu0vpIWCyvMxbLCZIngK8
         nLvw==
X-Forwarded-Encrypted: i=1; AJvYcCX5v5xpaUKPBvZvtEP8BZbMvGxSfPqswUB2SeNw3UytKOuqmRMejHn4HA6kq0nPIffdExmTY6KnKNA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwF3sgx1k0TJ3JSmGrYx0jsvn66u+8PuHEiy/It6BOafmSH+9lm
	LFchDp+cOGF2nOAtNrssY2W0Q9ohrsGIlYy0tx1SD7UEac0lsbVmsZm2/aJXbRw=
X-Gm-Gg: ASbGncvZ7kCOdC6rT9heXTaADLmNBTcgaQByBArcTnX/kp5iMmYVJ23HKVm8qh3Oyfz
	R0Eb1Gfzd7PSJ7f6TVK90zdU0h5z1/hTZxWnQhAlpi0WlHWW6KV2ivQv/xQx1N8D/ypePD16Tqf
	NbXuFpqrQU0lDZ4xDnCOCBoLUlchotMh/DsQvpgSO6lxSFON4QQtVngYgCaJWyLHvOo+BBfxIGB
	lVAXFM4PmiXxrZhvBXnzuvOv4gX/XEs9MGgmepXOxBms0MVX2+KNeMcDnoUAkr5GmMzTffulGk3
	88rIJFDK4vMrB7CuoeIv9yw9dt6oAS8e2A9xIJPkTH6OfffUewEPa889iD4GCsnlLzrFhRKC9Nq
	SSbXd5dNBLxRUrjeK
X-Google-Smtp-Source: AGHT+IHQyqAXQ1OnTyy06XTY3gbCqTwHmc1ysVvli+H0tWNHPAsqRbz747vw3dWL3+EvHsS0XfUf8A==
X-Received: by 2002:a05:6000:2a3:b0:3a0:85ad:5ed9 with SMTP id ffacd0b85a97d-3a09fd7a183mr7844198f8f.4.1746538780230;
        Tue, 06 May 2025 06:39:40 -0700 (PDT)
Message-ID: 
Date: Tue, 6 May 2025 14:39:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2] sbat: Add SBAT section to the Xen EFI binary
To: Jan Beulich ,
 Gerald Elder-Vass 
Cc: Frediano Ziglio ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20250501122322.230599-1-gerald.elder-vass@cloud.com>
 <7fa7780d-4dfb-4e87-b65c-c9ce86ad7e67@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: <7fa7780d-4dfb-4e87-b65c-c9ce86ad7e67@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02/05/2025 8:01 am, Jan Beulich wrote:
> On 01.05.2025 14:23, Gerald Elder-Vass wrote:
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -58,6 +58,7 @@ obj-y += percpu.o
>>  obj-y += physdev.o
>>  obj-$(CONFIG_COMPAT) += x86_64/physdev.o
>>  obj-y += psr.o
>> +obj-y += sbat.o
>>  obj-y += setup.o
>>  obj-y += shutdown.o
>>  obj-y += smp.o
> This being x86-specific here without there really being anything x86-specific
> about it - what about Arm?
>
> It being EFI-specific, why put it here rather than in x86/efi/ (and/or, as
> per above, in common/efi/, at least for the source file)?

Having just spent a morning debugging, I've told Gerald to keep it in
x86.   common/efi is an intractable mess and needs turning into a
regular part of the build before this suggestion can be actioned.

~Andrew




From xen-devel-bounces@lists.xenproject.org Tue May 06 13:47:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:47:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977273.1364303 (Exim 4.92)
	(envelope-from )
	id 1uCIdU-0003l4-RW; Tue, 06 May 2025 13:47:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977273.1364303; Tue, 06 May 2025 13:47: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 1uCIdU-0003kx-OH; Tue, 06 May 2025 13:47:04 +0000
Received: by outflank-mailman (input) for mailman id 977273;
 Tue, 06 May 2025 13:47:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCIdS-0003ko-R3
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:47:02 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 968290b6-2a80-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 15:47:01 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43d0618746bso39861325e9.2
 for ; Tue, 06 May 2025 06:47:01 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441b89cc441sm173490225e9.3.2025.05.06.06.47.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 06:47: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" 
X-Inumbo-ID: 968290b6-2a80-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746539221; x=1747144021; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=c0g2iJRiZOVC1jLAzQlPCvbZ1weyKvYSprS/XScBn20=;
        b=pQU0WFimhUQ4ByNKg6rpW9lpZdKbLSZQn47xGkVpWzpqRTIMUB5vV0vi9ekBzgm2/6
         JwDzNoJExb9hfcscJgrXr1wViRP2uR9mwfcV0HF60VhtJ9iFxnrzNl9ftvHX/z33SaFO
         bfGGsufAYj9/2GoGU4wgCaEvEP0edlbhGB+Ak=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746539221; x=1747144021;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=c0g2iJRiZOVC1jLAzQlPCvbZ1weyKvYSprS/XScBn20=;
        b=QZvqrPaiF36y9+dI1eY1Yyv5h4uOUAaymBk2ndkvYro22sewQSPogz6eNmcbNby6sy
         /3IKOvZinlaIMldhJUJMwXjUmV0uqoecMOdF2c4qYz5/dlRDs1CFbdwkjmYppJfcw1wa
         REa9xbs4mV6cJJIH03R99pfKP0tpQhJVLh13DRbhPsEJDaOB1rabYSqgUjWsvEilMi+n
         y4qHWEBZLU1JPzdxmtaocUlAdwmrYbZkOaTVS6Lcj7WkK/P4gAbArj07IV0ElJjMK5Q3
         z+rW+OFqgxTcqkw0BPd8D6I+8O6PxgTaVryO9QlihyG8IrZ54yiS9EXhYpbO0YE+T32B
         0NYg==
X-Gm-Message-State: AOJu0YzFRaPlZiPXkC368fFvSY6myUNUEJ4wSwnlCPBCYsOJXyUf89XS
	vXr+sgq9niBXEeM1r6fDMbfASpy25TNOhCuKCtyOkYxFKf/eHH+VGAL+l6aTc9I=
X-Gm-Gg: ASbGncv7SFrbSM8AUp4GiFc9HgcYePv+RNaQEPlGQwHjLJIdt7e1oI+vmG4JB166tR9
	EstY8VmIrPC8Mvt4OaAWNAM/qmX/mhyIOxBk+JYcc1JFSk6gqAxwbw4umQAyttE3qwzGJW/nT4v
	nl/b2cAnoqaCojL9sXaM45opISgXuxCDhSfnEktHTHxemmZ+zKoOLWVM5yIlHi3KyMr6q69goyR
	YdAs1L8TZnU5SGNWDN8NbWM8DCPRvkV8JyjwLWwmDWMqMp2AchUgUF3PSXucAngZ72s6Htbvszh
	uzWkulIGlJSYhNESe2CIly5HXXphGdaAIdV6d6gxGxlRJA==
X-Google-Smtp-Source: AGHT+IEqKlQtGmUA+l2OGBr4PvF7P+jbTwyWTk4dDphqOjYiPFPf5GTTrTrvLxDMnhv3scbFxFzHXA==
X-Received: by 2002:a05:600c:1d8c:b0:43d:4e9:27f3 with SMTP id 5b1f17b1804b1-441c48bc74fmr107910385e9.9.1746539221359;
        Tue, 06 May 2025 06:47:01 -0700 (PDT)
Date: Tue, 6 May 2025 15:47:00 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v3 03/11] vpci/header: Emulate legacy capability list for
 dom0
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-4-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250421061903.1542652-4-Jiqian.Chen@amd.com>

On Mon, Apr 21, 2025 at 02:18:55PM +0800, Jiqian Chen wrote:
> Current logic of emulating legacy capability list is only for domU.
> So, expand it to emulate for dom0 too. Then it will be easy to hide
> a capability whose initialization fails in a function.
> 
> Signed-off-by: Jiqian Chen 

With the comment from Jan addressed:

Reviewed-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 13:50:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:50:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977283.1364312 (Exim 4.92)
	(envelope-from )
	id 1uCIgv-0005Ge-9d; Tue, 06 May 2025 13:50:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977283.1364312; Tue, 06 May 2025 13:50: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 1uCIgv-0005GX-6h; Tue, 06 May 2025 13:50:37 +0000
Received: by outflank-mailman (input) for mailman id 977283;
 Tue, 06 May 2025 13:50:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCIgu-0005GR-4N
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:50:36 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 15186536-2a81-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 15:50:34 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43edecbfb46so32132155e9.0
 for ; Tue, 06 May 2025 06:50:34 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441b89ee3a9sm168847455e9.23.2025.05.06.06.50.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 06:50:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 15186536-2a81-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746539434; x=1747144234; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=URghD3Lcc9QwR0tT7L5eE8ySaBWMCuH5eIYpXHjjpAY=;
        b=kXb/DHfhSm19AL/pptzpD4Uz/qItCL73YbcJH80S+eBN43P7+NjZbGXNcAgG53BfDP
         2IZ5vlY3DyYKbyPpQyZhDSLr1PyezmKfBBuzCkwU69jpTZfbBvWgyIa3f/PwszpBflL1
         /pK4CtPJSfiSgfP311f6GMRIxrIIumQwUZmRA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746539434; x=1747144234;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=URghD3Lcc9QwR0tT7L5eE8ySaBWMCuH5eIYpXHjjpAY=;
        b=w+Wg7plPcqn3HHWNsLUvIIdJJMdDpbsvFn+augmoAzCKlmqIR1whNajCMxsF0fp69V
         8v5OiNYpza2E1Y0CNiRkz7FHb6pOoXOn+1gChkXV0onvcYL779dVYt/s2d3olh8FCq/5
         TCNxYXLA4LDkyLodLCsaxEku5DJb8tUPPamt8Cx+rmP4V+RICdmiUgBr619PRGa1C6Al
         IiFeqiXyn+WeV2ur2cMrF3aUhjekI9MFRraOYolMm9JCZsNKOfjKhYQb1+d0XKIBtXe5
         hzrG7oQLeg9msQnzHTPfAzhP+sBi3Vy5c3jdHCCz+BMvEW/IKOphIqM25Icwbc4BY2TW
         lT/g==
X-Gm-Message-State: AOJu0YwgKsHaJrfkobv5vfsi+SnVdQmDpJs2uTxiUqsnp44FInViJPQU
	RHciQOtdFRt3QCsSvUQqHc5P++yLioAQEUTFjc9yIESbNseMj7waFvS8OvZgYNjNsr18meAgXrM
	y
X-Gm-Gg: ASbGncsUtii7Hlr9M98YohxsANrohqQZYSEqPMRim9E+z1WCQkAH6nNBs0DIL9rVRn+
	gtOfqoZXeRKUl8/pD0+uvBuBtKqe4Jq7bkMN49xuZBKy/E53EL8wTFbGjFXTbrxGDedQW2xVl1h
	pNpsjrdGP5rQrKpDQ8UP6DuwXxQGmLmGBLxcUOAMEzK7Hg5ycNGxRkpDHDu29dgJVkD7ab4ArJh
	jUo/SEeb1XsqHaf8RwuQ64tv9jMKU/0Cb9BeLP6DqpWvL2s3gIIrR+Y2lPTUIyLHA/D5Myl3BjO
	YEczp5FAQrHZTqphvGs4HV1fH64J8ayzh/rXKj9a+o3upw==
X-Google-Smtp-Source: AGHT+IHxMso9dfraSBaoaPB3rplF38ppFwTOVeU3CMXWsYFTE0owFnuT9DNeXuJznLc+OM1Y49lkNQ==
X-Received: by 2002:a05:600c:a4c:b0:43c:f8fc:f69a with SMTP id 5b1f17b1804b1-441d04f45b7mr31464525e9.4.1746539433783;
        Tue, 06 May 2025 06:50:33 -0700 (PDT)
Date: Tue, 6 May 2025 15:50:32 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v3 03/11] vpci/header: Emulate legacy capability list for
 dom0
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-4-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250421061903.1542652-4-Jiqian.Chen@amd.com>

On Mon, Apr 21, 2025 at 02:18:55PM +0800, Jiqian Chen wrote:
> Current logic of emulating legacy capability list is only for domU.
> So, expand it to emulate for dom0 too. Then it will be easy to hide
> a capability whose initialization fails in a function.
> 
> Signed-off-by: Jiqian Chen 

Sorry, one nit I've noticed while looking at the next patch.

> @@ -786,13 +787,15 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>  
>              next = pci_find_next_cap_ttl(pdev->sbdf,
>                                           pos + PCI_CAP_LIST_NEXT,
> -                                         supported_caps,
> -                                         ARRAY_SIZE(supported_caps), &ttl);
> +                                         caps, n, &ttl);
>  
> -            rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
> -                                   pos + PCI_CAP_LIST_ID, 1, NULL);
> -            if ( rc )
> -                return rc;
> +            if ( !is_hwdom )
> +            {
> +                rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
> +                                       pos + PCI_CAP_LIST_ID, 1, NULL);
> +                if ( rc )
> +                    return rc;
> +            }
>  
>              rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,

For the hardware domain the write handler should be vpci_hw_write8
instead of NULL.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 13:52:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:52:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977293.1364322 (Exim 4.92)
	(envelope-from )
	id 1uCIiJ-0006Ad-JA; Tue, 06 May 2025 13:52:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977293.1364322; Tue, 06 May 2025 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 1uCIiJ-0006AW-GZ; Tue, 06 May 2025 13:52:03 +0000
Received: by outflank-mailman (input) for mailman id 977293;
 Tue, 06 May 2025 13:52:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uCIiI-0006AO-8r
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:52:02 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uCIiH-00CiYm-2O;
 Tue, 06 May 2025 13:52:01 +0000
Received: from [2a02:8012:3a1:0:7157:32ca:2aea:33a3]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uCIiH-001aEP-1f;
 Tue, 06 May 2025 13:52: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=LR6oFWnOrbso5QWX3Jmg1qf7AUc53JJNJlxQe3cQpss=; b=OfQ7PRdweNTWxR0NdPQW7q4RtL
	uBC67kfQcsmZSXfw2RAbCRacA3DVRfex43ASoWguCdvGJzowlbrO+KvgX0ONu6z/jgikn+4LJuNJV
	87OZmWdOaHFR90NUDiLxAcWbGxriNMkE/YrFDIe+IuMI6aWY+qCE/kBNGZmOw9E8IHOg=;
Message-ID: <02fde9e1-7833-4b22-ae56-e42687c1c26a@xen.org>
Date: Tue, 6 May 2025 14:51:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 6/7] arm/mpu: Provide a constructor for pr_t type
Content-Language: en-GB
To: Luca Fancellu ,
 "Orzel, Michal" 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-7-luca.fancellu@arm.com>
 <42eab292-f9f6-4bc1-a011-c657544ebaf5@amd.com>
 <23A4DA59-A279-45ED-B81C-3EEE72B79DE8@arm.com>
From: Julien Grall 
In-Reply-To: <23A4DA59-A279-45ED-B81C-3EEE72B79DE8@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Luca,

On 06/05/2025 13:56, Luca Fancellu wrote:
>>> +/*
>>> + * Creates a pr_t structure describing a protection region.
>>> + *
>>> + * @base: base address as base of the protection region.
>>> + * @limit: exclusive address as limit of the protection region.
>>> + * @attr: attribute index for the memory type.
>>> + * @return: pr_t structure describing a protection region.
>>> + */
>>> +extern pr_t pr_of_xenaddr(paddr_t base, paddr_t limit, unsigned int attr_idx);
>> here. Please don't use extern in prototypes. It's not needed.
> 
> I see we have a mixed usage of this in arch/arm and it’s not documented to do otherwise
> in the code style, in this case I would prefer to be explicit unless it’s a strong objection on your side,
> let me know.

Old Arm code is using "extern". But new code should avoid it for prototypes.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue May 06 13:54:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:54:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977304.1364333 (Exim 4.92)
	(envelope-from )
	id 1uCIkP-0006jX-V4; Tue, 06 May 2025 13:54:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977304.1364333; Tue, 06 May 2025 13:54:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCIkP-0006jQ-SD; Tue, 06 May 2025 13:54:13 +0000
Received: by outflank-mailman (input) for mailman id 977304;
 Tue, 06 May 2025 13:54:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCIkO-0006jK-Np
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:54:12 +0000
Received: from EUR02-DB5-obe.outbound.protection.outlook.com
 (mail-db5eur02on20609.outbound.protection.outlook.com
 [2a01:111:f403:2608::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 961a1979-2a81-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 15:54:10 +0200 (CEST)
Received: from DUZPR01CA0263.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:4b9::11) by PA4PR08MB6317.eurprd08.prod.outlook.com
 (2603:10a6:102:ec::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Tue, 6 May
 2025 13:54:07 +0000
Received: from DB1PEPF000509FC.eurprd03.prod.outlook.com
 (2603:10a6:10:4b9:cafe::13) by DUZPR01CA0263.outlook.office365.com
 (2603:10a6:10:4b9::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Tue,
 6 May 2025 13:54:19 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB1PEPF000509FC.mail.protection.outlook.com (10.167.242.38) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.18
 via Frontend Transport; Tue, 6 May 2025 13:54:05 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 PAWPR08MB10041.eurprd08.prod.outlook.com (2603:10a6:102:34f::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Tue, 6 May
 2025 13:53:33 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8699.026; Tue, 6 May 2025
 13:53: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" 
X-Inumbo-ID: 961a1979-2a81-11f0-9ffb-bf95429c2676
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=GIIvulSqGVjfN0Mpi3khqe7M9wZFDyZGOdkxuhkFp1mqQ6Yy3jyxR0Aw1aNKXbVPxCpdaD8Ry0a5T/2wlALDCTHQYPbtDI1H4xlAFmkIIHlYX3BGVqG7yVILn3676jpLQdMew/l0gh7SQk25pVGwjxdwKWn+j5B2rQhbUlqAYdpcVru1JV2OaI/2NVZ3Sn7v1r0kzLnTlIx5fgyjfSV774qJkR1zpWJeat7ecwhTaiDiSWw5dn1TmfFaWIKu5BHb88UzdqdK/KS4ZxMS/TGgJHITO/6lKK7ZEGmbcYvsf07gtYNjFZLnC0p49yvG1yx2Q0H1heSsK7x/zuHS90iVKQ==
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=axEw20NFGkMJnYlA17fJsOAa6P2He4Wmbs7PedWK16Y=;
 b=kHhFKYdr07KA8S3DElD6ZSMNvll+8Ay6IWwNrvcoik3qUFi6bOSWJ3//bexoV0vw+fKihY6jhq0jyeNbMaAMJ37M/Kkmff50d6YvOLGGykt/LlAbhY5vXkbTukP59Qfom07Nv1LLAjY0Tw8VfGP5gQkpy7lrLim92Hip+8Iv4dmFIZqPm+zvMMiNp1t0c0gn6AA/Pzg3t+FO7jUaNkQ75bpnag4DrtXTYQmLFOLcefH3ouMdm/7igmveSw5J3/I916P460E+feD4wJmPVhZuL7FsApw9ctaHliD2fM0Kx+NYtdh+iI5ML/x/BsAyXFeg0ac3IIBYmN9QU97cf0qw6g==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=xen.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=axEw20NFGkMJnYlA17fJsOAa6P2He4Wmbs7PedWK16Y=;
 b=eKoO6Pg+Vs+VxW33eamL/xgcpibFOEx2Sl7bxXNx6wJoxC3DiD84HCBzwyQCNcmv8rceDFt3kqfMSWOpfT/yEWBUel8H90QeQWSuk/KctsB7eDn5WVUhwlwynlkhKYtX4MdG6V/qBdnbS79kaF4VhVpCNqG0Z1+8ldnazaqYO28=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yD+Wda3vIbQWlvTwfpOpeu1yPMAmXHpKwifGxWDGUqbETcGVTqg/cVCve1vMvkkJW7OYMOqI1ye674mpnu5ln+GwAOXlGhC/JFSgBS+EMT+/9uNOk8No7otsRpDMBYZLMM0lHnAn1TFabV2qtRLP6ZJKDXDs6SAWbZTDtXR9pPSGwZ9tdnzYMmLvpAhvfPvVJEzYxskykeu583ZxGTpWIiSxrlNVRjBk51Vmt81idjZvzYAHb/Vh98/Hhv3cEpr3/Oj9v845E6/s3v9lnw/MYuDpwbiG+FHmAfWwnbsrBHdfbLZ3tlSKeLjsob7mOY/wYGjGZCfqpF4YhG9opi3ERg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=axEw20NFGkMJnYlA17fJsOAa6P2He4Wmbs7PedWK16Y=;
 b=SQ6Tnu/aG0iWLnSguvEO918+Be/TFZjopOGKNGtk4Za8QEaL5sTe/n1jpXxgSSnv2z+39IaMp9K7SoRqAIsY1oK3OT27gfLYgwIQeAP+7WKTOOIJ52OmZNqO6jOmR2JkJdgxfzQlaVSa2FPrAppEAu+zOlE3t0595FGAO3hK9hnTNbj6gDbDRc2Q0V6By2stmkaC0nf3wy4P7zut9ivc6cQmgq3Io+2Y5itM/ZkQp28275NECarNn/Ytvx6B1pfQrah+T8bbeFXsUNQwQZSNSpFPUzAO27ZQFy6L8wBnye9/aAtUdwHA+s8O9LI7mlMDMSD/F3Gjt2KTXRGcxp/gdw==
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=axEw20NFGkMJnYlA17fJsOAa6P2He4Wmbs7PedWK16Y=;
 b=eKoO6Pg+Vs+VxW33eamL/xgcpibFOEx2Sl7bxXNx6wJoxC3DiD84HCBzwyQCNcmv8rceDFt3kqfMSWOpfT/yEWBUel8H90QeQWSuk/KctsB7eDn5WVUhwlwynlkhKYtX4MdG6V/qBdnbS79kaF4VhVpCNqG0Z1+8ldnazaqYO28=
From: Luca Fancellu 
To: Julien Grall 
CC: "Orzel, Michal" , "xen-devel@lists.xenproject.org"
	, Stefano Stabellini
	, Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: Re: [PATCH v4 6/7] arm/mpu: Provide a constructor for pr_t type
Thread-Topic: [PATCH v4 6/7] arm/mpu: Provide a constructor for pr_t type
Thread-Index: AQHbuRpqbs0x64sbw06OBQfYV4WEtLPFavYAgAAvLYCAAA+6gIAAAEwA
Date: Tue, 6 May 2025 13:53:32 +0000
Message-ID: 
References: <20250429152057.2380536-1-luca.fancellu@arm.com>
 <20250429152057.2380536-7-luca.fancellu@arm.com>
 <42eab292-f9f6-4bc1-a011-c657544ebaf5@amd.com>
 <23A4DA59-A279-45ED-B81C-3EEE72B79DE8@arm.com>
 <02fde9e1-7833-4b22-ae56-e42687c1c26a@xen.org>
In-Reply-To: <02fde9e1-7833-4b22-ae56-e42687c1c26a@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|PAWPR08MB10041:EE_|DB1PEPF000509FC:EE_|PA4PR08MB6317:EE_
X-MS-Office365-Filtering-Correlation-Id: c6eb01e6-9012-4ecd-5aac-08dd8ca57731
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|1800799024|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?TkFYb0NuR3dxTXZjZ1g0bGtTZlo2aHNMWVBtalN4VlpSbjJsWndSVENueDIx?=
 =?utf-8?B?eGpOOHF2K1hRMDhoUEZhb2VZYzA1bDZmOUFaWk1jNnNWQlBwVlJoaFY4Mm4r?=
 =?utf-8?B?MjdoWU5WRndEVzBhTGVLK0NxWXBQVzVtZWhOK3BlaElseHBoTDBWaWRsS1BT?=
 =?utf-8?B?UWU1MGJOTHNlMDZPaTBudVRSWXNOQU00RDBScGJqUDJoOHphUWJiR3NiL1I3?=
 =?utf-8?B?bHJPSytTOVJYa0dJR21VMlRmeWVERm9nM0R1R0JnOGdvS3BWTHVOb2txci9p?=
 =?utf-8?B?YkhuRzU4RkZwQUV2aDREZ2NaQitocnJLK3A2SVZvT3psS2orMlp6TW5jV2tT?=
 =?utf-8?B?ZnFFaGRGNHZOWGFNaDdIUXp5MXN2T2ZPSXd3NUZ6dERlR0ZMS0V5VXo5ZlVM?=
 =?utf-8?B?ZGk4WjNBTGEzcHluMExRMkp3RENzcWE5Y1I0ZEV0NFBSU3hJdmNtR0ZqMjJt?=
 =?utf-8?B?ayszS0tJNm5KUUpGNXluSDBYTHFDTmtsTHN5dm83NnFPMHZqQ3lFTnErTEg0?=
 =?utf-8?B?Q2p5bDF0ZmRUNXIrYUl1dTh0T25HRTRxcHFrazE5K3JlZFpsMmM4cVJWNXFx?=
 =?utf-8?B?MUNtbE1wRmdDaHFibzAzbEFjWDBwUEc2MklnOFdmYnFEeUxEa01na1VnSG1m?=
 =?utf-8?B?UmV6THJsaDRTR201SmlSMXZTelJ2bWdMZkdjcDRlM3pOYVZxV0NCUlhrZGpz?=
 =?utf-8?B?Y2VTZmxNMjkyM002NXlQQ01UWFFnclk0a09nRGpUZ3k2UTdvTGxxUURjeDVw?=
 =?utf-8?B?UzRxK2dqQWx0TFN3VE5CUlhsZXNoaFYzU3JCd2JYRll4YVl3VTVrSzFOOEVu?=
 =?utf-8?B?Wmx6cjZkUk92UHcxVkJEMGFBaXR6WFZNTytENmtBelZpVWdjN3RqbW1jZFdG?=
 =?utf-8?B?b1I0cjVyRnVaVTJ3M0txZE5EUDBBU0UwcU41akxRcEpkSjdvV1Rvd24wZS9s?=
 =?utf-8?B?K3lOelJOQmZnTlhxSS9UcGdxR1ZId3dWK0tlUGtIU3dvNmJRMjh1QnV0VG4w?=
 =?utf-8?B?WGlHNUR2YnhOSHlIV3NWZDdaQWljL2syUzAzb2pxRWM5T1ArdXQwRExKUXBj?=
 =?utf-8?B?ZzkzVHJZLzNFMTJJZ3pUeDM0UVVyOWZWRjBWWjRXelhHa0ZtdTJqaFdtZGpS?=
 =?utf-8?B?dnBXZmhjR3F3SGNQZFRSTTlwQ01UaWdJc2dNdG01UDFQODkva2o0MWJ4dFRR?=
 =?utf-8?B?eWZvSTNYYnltRUF4R3U3a1FnLzdoRVRQL2U1QmxYZW4xUFR3eXU3VmpVcHRY?=
 =?utf-8?B?b2Y2SjI3QmY0Tmd0MzRxczhwVW15Q1ZxSWl6Q3JLQVMzY1B5U0hnU2JVMW9w?=
 =?utf-8?B?USswMVo0WldUZFFTd2VuS3F1azR1WHpTZjY2Sk55NUdSMWlIcm4yOFRJeFNa?=
 =?utf-8?B?WU1nY0gwcytHU3BkSFluZ2JLSFAvdEFDT0dWMzk2aTVETldHQWRuWlBKZHph?=
 =?utf-8?B?VVlMTVVoTnR1a2JvdjkrRDVVVFJWMVAvMzBMRmtQaUlzTUpMTEc1VXVIbEE4?=
 =?utf-8?B?alBIZXRoL2FYY2cwL1BhdkZkeTYwazVkRTVORWt3QWt3a09XcjFYMmpCOEY3?=
 =?utf-8?B?TmtZTzNFY0l6SUNydittTzBORlRPM0V3a21yRUtGWUV5QVRTaXFTVGNVbGRz?=
 =?utf-8?B?cjBPVVdlMTRLdjJQTmN1RVBQZVdXZmxXNjFiZ0lzaFFnakxzTUNnNlNwNlph?=
 =?utf-8?B?cldrWm9FYlV0UHVpSmZKWWF3UWtlNm11WWpzeUNlbFBjSzdKY2oxK2VrZTh0?=
 =?utf-8?B?SUtyZG81YjNiVUtPQjhyS2I2WHE2YUNFc1VybGhWRUVzV2NPODI5OGNDeDhW?=
 =?utf-8?B?ZWlla05SN0dvUGVxaTVjRFk5eWFHWksxRG9sa1hzait2WGdDY214dXYycE41?=
 =?utf-8?B?cnhsKzhxdnZjbXF5endBaENibFhRaHY0ZkVwdlAxUzhxS0FaRHRuSWxoWFM0?=
 =?utf-8?B?aFNnR3pNZjZaeGYwb09qZzQ3YlptUzFPbVRUOGIzR3JheCtmc21zYVd0SkFO?=
 =?utf-8?Q?0pqOnzFmpn0MXiCteceCO3L3EMRTrM=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <1503A74184D36347AEA9633580BAD9D7@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB10041
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF000509FC.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	6f9183f1-1e6a-435a-18d7-08dd8ca563ea
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|35042699022|36860700013|14060799003|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UHViQVFSU1RtOXR0RXJRY012WVo4MDZDNWVLcExyMDRpTXMvUkFNZ0hYWVkr?=
 =?utf-8?B?QmF2VThsU3lzdllzMU9hN2R3WTBOMTlTdTQ3a3VZTGRiVnhuNkxJdjZLSUtG?=
 =?utf-8?B?dmVkak51T3lWMFVSTHBBMWYzMjRDR2t0TDlrdnJCMVQyT2J6TldhdHVGVmQ4?=
 =?utf-8?B?eHdzSnFUQnVLTExZdk11bWxENHF5NWFhSURHWlZSUEJPSzZNbXVESnFFYXhH?=
 =?utf-8?B?OUc3TU84SWQ5eUVlUGMrWjdldzZxRFdIaHI5d2kveTJRa2RCVCtuMlo1MFQy?=
 =?utf-8?B?RW5qb0I5Y1VzVVFXaWR5TG5TVktXelpHZjZ1TXlJZEQvb3JzdDdVYVJtWVRO?=
 =?utf-8?B?Rm1jbEJ6ZFltRmpXRHMrWUhVdGQxRzNwQkpZZHViY0Zocml2TjJYWHpPRmRY?=
 =?utf-8?B?OTlSSlpUOHYwOVEybE1Tdi94WFFNWUpZc3lOenhjNVo0dm80ZWJ3c0RqQXpF?=
 =?utf-8?B?VFk3QkFMNnFXeEZGMXhGSzlmOHBFaFpXQXJnc0dPUlRwMWJENlFEOEFvYXoy?=
 =?utf-8?B?MGN0RXYxeEh6ZHIvYXhNbGxqbW5rN2U5V2EyT21RS3FVM2lKeXRKTXV6dXkr?=
 =?utf-8?B?bTBCWFZmOEN2VE5Ld1BZeCswNjNEeDBHdmNnc0lvZjNDdEMxN0NOVnlPWHJZ?=
 =?utf-8?B?RDhWemdGdHpWaWNTekFmaFZIQmFOSUxYMjBlMllKSnFHb3FFWjZ2YVZiNFpV?=
 =?utf-8?B?azlFWnZ2c2R2b0NDRTUyald6RWJwdmZhcDV3YmhRWTR0VGg1TlFTRTluQmVV?=
 =?utf-8?B?REtoWFZKZVpoOHBwTGxzRVA0RHdvV0ZKN2ZVSXdFaS8rWWZQSDVTUXVGN2pj?=
 =?utf-8?B?ZWN4OWQ3dnJSVUs5dHRxbE5HamxxRnZuY0p6ZUdlZkYyOEl4SXFpdXVNMUVV?=
 =?utf-8?B?Uk9JMXhwcVRzY2xVZzVBbkdpV3c2ZU9wcHVvcGxiKzFQUCtoaGJJT0RmQ3Uy?=
 =?utf-8?B?VlIxZDY1RGRyb29ES2RBWTNVN0N4Y295UjRBT1BvUVRzbmJVdFdIdjU3SGxm?=
 =?utf-8?B?OUNrSW8yVVVxL3JYbXFJbDF0bHdmYW8xRjNvREp6b2NIME1EWHJvZXRUSGEv?=
 =?utf-8?B?RUNNNGNPdStMSzRaSFpSU240RzBxdWJ3Y3AxanhTcVFYNjZYb2lUR2ZmK2ps?=
 =?utf-8?B?SDhld0xTaEpFRmhuS3lyejhid3ZzQ1ZkQm1zajZGQ3EzeTgwZzcyN0krdllz?=
 =?utf-8?B?cUpHRW1obUxuOFE1WG1pdXExN21KRG1aRlErSkVBYTIxR05pWUNrZmc2eXpa?=
 =?utf-8?B?S2pGdEV2QW5lNE9HUmtIMjNuMlZUbGgyZldieGhZRGxIeWkzam5PRlc4Z0tZ?=
 =?utf-8?B?Z0F0RWhvVURPbXByb0R3TDFITXMrS2NDTXVqenpsbUNxUDNXMnA4bXFTd0lp?=
 =?utf-8?B?dko1Q3VyR2lRRERuN29DY2FUMHJBV3pMazROTnJrRGRlUm5FYktabDR3N0lq?=
 =?utf-8?B?b2pkWDBqNjhlN0ZRaUN2UVJwd0s1eGxtQVluL3VBZENiQU02dXdwbnhTNXlC?=
 =?utf-8?B?SmRZRjIvOCtHRjhVK0xnc05LSUQvd1dYcW5GeWw4WnFOZnFKWUNpT2ZDeDBt?=
 =?utf-8?B?aUNkeVlXOVI3eHE0N2NBUGtvcWE1UkMySkxsNGowRlp0eU5EbWJPK21YR0k2?=
 =?utf-8?B?WTZIelFuT05lVVIwSWNUcWEyRlUrMlJrRWxJbVM3OWZuOXJOZk9HbkVWRFNW?=
 =?utf-8?B?RGhudjNIcTlUcHVEYlZZSy9uZ3ZCRnhLaTlacFN1eWZlRkpyUkdNc3JnWkdS?=
 =?utf-8?B?eW1wT1dtajBkYkxLU1h5dHl4N0tzWEMyT0FnTC83TEhwK1BmL2dNNE1PNldi?=
 =?utf-8?B?SVdPTWorTFdPcHVBQkNtVFJDUzFZRGVFVVVzZU1mdWNFM1FCNyt1N2ZhNXN5?=
 =?utf-8?B?VGFyNFZ5MGlaVm9wRGZwSjdqWk1GbnNqTStUTlhiYk44UytwVWtta0w4Uld0?=
 =?utf-8?B?L2JEZXoyRXhRbzJJQk5kTzAyQmVCS2k1V2lqOVNDWXFyYUVGNDM0MVpPbnZo?=
 =?utf-8?B?bWNGeDZtRElaazgzMTEvOXg3RGw5TDJpZEN0RmF4QXJpVC9VOThCbmxSREdT?=
 =?utf-8?Q?Lnbx77?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(35042699022)(36860700013)(14060799003)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 13:54:05.2662
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c6eb01e6-9012-4ecd-5aac-08dd8ca57731
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:
	DB1PEPF000509FC.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6317

SGkgSnVsaWVuLA0KDQo+IE9uIDYgTWF5IDIwMjUsIGF0IDE0OjUxLCBKdWxpZW4gR3JhbGwgPGp1
bGllbkB4ZW4ub3JnPiB3cm90ZToNCj4gDQo+IEhpIEx1Y2EsDQo+IA0KPiBPbiAwNi8wNS8yMDI1
IDEzOjU2LCBMdWNhIEZhbmNlbGx1IHdyb3RlOg0KPj4+PiArLyoNCj4+Pj4gKyAqIENyZWF0ZXMg
YSBwcl90IHN0cnVjdHVyZSBkZXNjcmliaW5nIGEgcHJvdGVjdGlvbiByZWdpb24uDQo+Pj4+ICsg
Kg0KPj4+PiArICogQGJhc2U6IGJhc2UgYWRkcmVzcyBhcyBiYXNlIG9mIHRoZSBwcm90ZWN0aW9u
IHJlZ2lvbi4NCj4+Pj4gKyAqIEBsaW1pdDogZXhjbHVzaXZlIGFkZHJlc3MgYXMgbGltaXQgb2Yg
dGhlIHByb3RlY3Rpb24gcmVnaW9uLg0KPj4+PiArICogQGF0dHI6IGF0dHJpYnV0ZSBpbmRleCBm
b3IgdGhlIG1lbW9yeSB0eXBlLg0KPj4+PiArICogQHJldHVybjogcHJfdCBzdHJ1Y3R1cmUgZGVz
Y3JpYmluZyBhIHByb3RlY3Rpb24gcmVnaW9uLg0KPj4+PiArICovDQo+Pj4+ICtleHRlcm4gcHJf
dCBwcl9vZl94ZW5hZGRyKHBhZGRyX3QgYmFzZSwgcGFkZHJfdCBsaW1pdCwgdW5zaWduZWQgaW50
IGF0dHJfaWR4KTsNCj4+PiBoZXJlLiBQbGVhc2UgZG9uJ3QgdXNlIGV4dGVybiBpbiBwcm90b3R5
cGVzLiBJdCdzIG5vdCBuZWVkZWQuDQo+PiBJIHNlZSB3ZSBoYXZlIGEgbWl4ZWQgdXNhZ2Ugb2Yg
dGhpcyBpbiBhcmNoL2FybSBhbmQgaXTigJlzIG5vdCBkb2N1bWVudGVkIHRvIGRvIG90aGVyd2lz
ZQ0KPj4gaW4gdGhlIGNvZGUgc3R5bGUsIGluIHRoaXMgY2FzZSBJIHdvdWxkIHByZWZlciB0byBi
ZSBleHBsaWNpdCB1bmxlc3MgaXTigJlzIGEgc3Ryb25nIG9iamVjdGlvbiBvbiB5b3VyIHNpZGUs
DQo+PiBsZXQgbWUga25vdy4NCj4gDQo+IE9sZCBBcm0gY29kZSBpcyB1c2luZyAiZXh0ZXJuIi4g
QnV0IG5ldyBjb2RlIHNob3VsZCBhdm9pZCBpdCBmb3IgcHJvdG90eXBlcy4NCg0Kb2sgSSBzZWUs
IEnigJlsbCBkcm9wIGl0IHRoZW4uIA0KDQpDaGVlcnMsDQpMdWNhDQoNCg0K


From xen-devel-bounces@lists.xenproject.org Tue May 06 13:57:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:57:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977320.1364343 (Exim 4.92)
	(envelope-from )
	id 1uCInF-0007Mo-E9; Tue, 06 May 2025 13:57:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977320.1364343; Tue, 06 May 2025 13:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCInF-0007Mh-Ay; Tue, 06 May 2025 13:57:09 +0000
Received: by outflank-mailman (input) for mailman id 977320;
 Tue, 06 May 2025 13:57:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCInD-0007Kz-IO
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:57:07 +0000
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [2a00:1450:4864:20::432])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fef31086-2a81-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 15:57:06 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3912fdddf8fso4155909f8f.1
 for ; Tue, 06 May 2025 06:57:06 -0700 (PDT)
Received: from localhost.localdomain (172.74.6.51.dyn.plus.net. [51.6.74.172])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099b170e7sm13503239f8f.86.2025.05.06.06.57.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 06:57: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" 
X-Inumbo-ID: fef31086-2a81-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746539826; x=1747144626; 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;
        bh=oS5Ne5DXGsGr+AaaxvmOawzW3uBF8/+h3VkNJfwE/uY=;
        b=A82E9TI+D+Pbg3ACT665N9129YAH1hp2KcxwJQWvAJq4TdxZonXyBLjnajO2JFzxRu
         Y4I/JvhDO1vuF+rdfROe01AR4PG4SC0zRnf4TsZLobnbcqTubOzd/ZbeJpUS9ImZ6cMF
         LmIbObCCjZPMuuIsz9iSybrMnp7gZ3oKQXfgw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746539826; x=1747144626;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=oS5Ne5DXGsGr+AaaxvmOawzW3uBF8/+h3VkNJfwE/uY=;
        b=H8Ryvx4NF6NtEECRS6C98mcopwGUVkfZ5qbPWC8dHI4X0cX/25jbh4O0VaI42iS5QK
         Mfn/+fHp3zfnBiCMgUDHlGseiDSMu1q72j8wOyAKDgFf5JEw/TjOVtNn+SiGuCinE17t
         vlxw8EZbD3SCS/16+9vD6sB0h/rYGH3SyYitTPqWLsaFEU5k9Qj7N9gmxDJncJqBgLIF
         cjQ42yaiLMvHFyNnGEHoRVgThGN3PRDh7IZI6XVjTiiNGWDwaU88MQrRf0hrbrXgQsZj
         xjdGss548wJTHBmnLYDaKo5EPlkVOKbu6SLa1cAOXRbOih5uNWY6H92LNec/jBN1YA+l
         Iusg==
X-Gm-Message-State: AOJu0Yy6Xi4clC5e7XtUUlBb5oeVcZj6JPCynLtUllbG/KSSca0k6beP
	OR5Mau91kkMbToLkoLPqPOwGI+UwXBaROuLflaK9nCWvSFlHSqv7JG28G8T1pxmLKuQjEUr2fnu
	+Fzc=
X-Gm-Gg: ASbGncvk6hEKW3MK2Wx6ibeBsQOygu3jFG3wg35fX0o4RTQSMDHVoxOV9NtKUcVouEf
	ipAy6wcDvlePR4+NRQPZRhMV5fxsnCbzsOPc0xUFpAYBn/a1y+jeyFTaSZ9DExz3jikC3hzAeXX
	um9kOAfZqsWws6DaQqSxZkxrXm+sFNLqFIeqqkpRSRvdOTfLE5U6avXM5zZgvb44F+ZZQ9G/sm/
	AqN1y/NWoK/hTF0eaoIw2lGD1yL0vePSs7MWtqENSbldXUDpNf2hrXt7aKfkIhPKexyFkiBaZpb
	pXjK2uRnaAfeDnaj23cZDDkC51Mdo0LlH92qmuAKaof06/c6w65swTGyHItlpFdWVRK7jS6QiR+
	qLYrUZw==
X-Google-Smtp-Source: AGHT+IGzszc9/3EBfIS3sHCl4SGT4EZ57L3XoI/LvsAgd2bRy2WU8PnStHg/q1uFk/uEpbIMM8BQZA==
X-Received: by 2002:a5d:59a7:0:b0:3a0:b334:6aab with SMTP id ffacd0b85a97d-3a0b3346d6dmr460785f8f.12.1746539825762;
        Tue, 06 May 2025 06:57:05 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	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/4] Allows Secure Boot for Kexec
Date: Tue,  6 May 2025 14:56:49 +0100
Message-ID: <20250506135655.187014-1-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Using EFI Secure Boot all kernel level code should be signed and
there should be no way to run unchecked code.
For this reason the Kexec interface needs to be changed in order
to allows signature checking.

The purgatory code is included in Xen itself as passing this code
from userspace it's not secure (see patches 2/4 and 3/4).

Ross Lagerwall (4):
  xen/lib: Export additional sha256 functions
  kexec: Include purgatory in Xen
  kexec: Implement new EFI load types
  kexec: Support non-page-aligned kexec segments

 xen/arch/arm/Makefile                 |   1 +
 xen/arch/arm/kexec.c                  |  27 +
 xen/arch/x86/Makefile                 |   2 +
 xen/arch/x86/bzimage.c                |  40 +-
 xen/arch/x86/kexec.c                  | 125 +++++
 xen/arch/x86/purgatory/.gitignore     |   3 +
 xen/arch/x86/purgatory/Makefile       |  64 +++
 xen/arch/x86/purgatory/config.h       |  37 ++
 xen/arch/x86/purgatory/entry64.S      | 108 ++++
 xen/arch/x86/purgatory/purgatory.c    |  59 +++
 xen/arch/x86/purgatory/setup-x86_64.S |  63 +++
 xen/arch/x86/purgatory/stack.S        |  21 +
 xen/common/Kconfig                    |   1 +
 xen/common/kexec.c                    |  33 +-
 xen/common/kimage.c                   | 703 ++++++++++++++++++++++++--
 xen/include/public/kexec.h            |  23 +-
 xen/include/xen/kimage.h              |  57 ++-
 xen/include/xen/sha2.h                |  10 +
 xen/include/xen/x86-linux.h           |  62 +++
 xen/lib/sha2-256.c                    |  16 +-
 20 files changed, 1344 insertions(+), 111 deletions(-)
 create mode 100644 xen/arch/arm/kexec.c
 create mode 100644 xen/arch/x86/kexec.c
 create mode 100644 xen/arch/x86/purgatory/.gitignore
 create mode 100644 xen/arch/x86/purgatory/Makefile
 create mode 100644 xen/arch/x86/purgatory/config.h
 create mode 100644 xen/arch/x86/purgatory/entry64.S
 create mode 100644 xen/arch/x86/purgatory/purgatory.c
 create mode 100644 xen/arch/x86/purgatory/setup-x86_64.S
 create mode 100644 xen/arch/x86/purgatory/stack.S
 create mode 100644 xen/include/xen/x86-linux.h

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 13:57:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:57:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977321.1364347 (Exim 4.92)
	(envelope-from )
	id 1uCInF-0007Oh-Jn; Tue, 06 May 2025 13:57:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977321.1364347; Tue, 06 May 2025 13:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCInF-0007O5-Gn; Tue, 06 May 2025 13:57:09 +0000
Received: by outflank-mailman (input) for mailman id 977321;
 Tue, 06 May 2025 13:57:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCInE-0007Kz-9u
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:57:08 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ffac07aa-2a81-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 15:57:08 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a07a7b517dso3697614f8f.3
 for ; Tue, 06 May 2025 06:57:07 -0700 (PDT)
Received: from localhost.localdomain (172.74.6.51.dyn.plus.net. [51.6.74.172])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099b170e7sm13503239f8f.86.2025.05.06.06.57.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 06:57: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" 
X-Inumbo-ID: ffac07aa-2a81-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746539827; x=1747144627; 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;
        bh=wWG+dt0wyO1enTyXwSRlDk2xHqo7Oq+/vleaC2X1ZwA=;
        b=R2YyHV1qURPWx5gSMgKJ3Ri0BgWEpMAS1yaZCYPI5Pgs7v1GjFENxX1aiS4KTpD6J2
         n/RYqgpzB0+SY22GAQBHTu8rcWmDEUTpPRGGvhFkkADs8V42U/R7AkF4YD1vijbwbCxE
         hQ6tQIKnWHBkq52J23hpSIry+hdWY70kakM/8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746539827; x=1747144627;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=wWG+dt0wyO1enTyXwSRlDk2xHqo7Oq+/vleaC2X1ZwA=;
        b=xGC0MNu0Ls+sziQD1IqN8e9pTGTfPG7bR43Nd8nvLth9VAEgykiXPlCcOAAMu37qAa
         MgiumZGZlnNbKjW9CeXCoB+PtSSa4+fnV0NG+wD/A8oVhFjOfsFXdsYTiMJdXGbj1jz2
         opYWR8xfQCSjtsbWttRRw61WoSI+Sq/jer3yoi5BGbuIEilNoteqDBf55612hY9SCODT
         IHNTh1YWkiF+5RLaMJc7fUYDDt3SpG5C6XnUifTbJy02eiSWylEq9HyLQEng7+r/HT8X
         vXEIjf4bw+0aQgFxsuG3kZoc+DGSMESzpLVxyAPp5BxR2qEH/MLkeYSLXbCTQZh4KWyj
         PJ1g==
X-Gm-Message-State: AOJu0Ywl1YsymUYJ0NA28ff154UlHuog3CeGU4o/JKpm5h46BcfNHF9U
	MhVksXpQVMF93rVEXUKUAuMi+vV+jhBxwEKLVwKtgQPfz4IvgBPZgdOlk+xiSGODqUbWMb3EsHJ
	/+Rk=
X-Gm-Gg: ASbGncsbwm0UnJd3Na5OrElPwoEZXR5l6eAOPRcgoohyxcB6dP/LmkG9Ner0jgxjdJm
	3VzUwlpmnGs+zbh9w5sVtrKbjshGdddTq4qYTnSXY2zwXrY2PIuIO0ByeBtazNW3No8iwjADL1h
	iN0eHxgEjfSBfwtEygA0UXWiOujZPlhRPEsGr8srYpFFkxLPsO5KnD8tmR0JoEqwJuddO0G69ra
	3VJvvjjFH6DS9Q5bvCDJQAKkPAv3VpYYps7og/CduJwOxRVfR8sJY1lOEuvRQ4f+LsyJq1nMTAT
	PLR6vmnB13TaFIv6jqkK6pu1Pv4VGNsYgMca4blulGqfCETSPFvEpzHYdb+2c3p7WWQZw+BOcb5
	3Xzmx5Q==
X-Google-Smtp-Source: AGHT+IHL81vJGNVKRVxyHaIk0RB+9S39F7pqwL25wYoQY3mFV86ajXU0B5bpXDTrHMxFnSIwtM+oxw==
X-Received: by 2002:a05:6000:4282:b0:39d:724f:a8ec with SMTP id ffacd0b85a97d-3a0ac1ff687mr2972154f8f.44.1746539826664;
        Tue, 06 May 2025 06:57:06 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 1/4] xen/lib: Export additional sha256 functions
Date: Tue,  6 May 2025 14:56:50 +0100
Message-ID: <20250506135655.187014-2-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250506135655.187014-1-frediano.ziglio@cloud.com>
References: <20250506135655.187014-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Ross Lagerwall 

In future, some code needs to generate a digest over several separate buffers
so export the necessary functions to do so.

Signed-off-by: Ross Lagerwall 
---
 xen/include/xen/sha2.h | 10 ++++++++++
 xen/lib/sha2-256.c     | 14 ++++----------
 2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
index 47d97fbf01..ea8bad67e4 100644
--- a/xen/include/xen/sha2.h
+++ b/xen/include/xen/sha2.h
@@ -9,6 +9,16 @@
 
 #define SHA2_256_DIGEST_SIZE 32
 
+struct sha2_256_state {
+    uint32_t state[SHA2_256_DIGEST_SIZE / sizeof(uint32_t)];
+    uint8_t buf[64];
+    size_t count; /* Byte count. */
+};
+
+void sha2_256_init(struct sha2_256_state *s);
+void sha2_256_update(struct sha2_256_state *s, const void *msg,
+                     size_t len);
+void sha2_256_final(struct sha2_256_state *s, void *_dst);
 void sha2_256_digest(uint8_t digest[SHA2_256_DIGEST_SIZE],
                      const void *msg, size_t len);
 
diff --git a/xen/lib/sha2-256.c b/xen/lib/sha2-256.c
index 19e8252188..896a257ed9 100644
--- a/xen/lib/sha2-256.c
+++ b/xen/lib/sha2-256.c
@@ -10,12 +10,6 @@
 #include 
 #include 
 
-struct sha2_256_state {
-    uint32_t state[SHA2_256_DIGEST_SIZE / sizeof(uint32_t)];
-    uint8_t buf[64];
-    size_t count; /* Byte count. */
-};
-
 static uint32_t choose(uint32_t x, uint32_t y, uint32_t z)
 {
     return z ^ (x & (y ^ z));
@@ -131,7 +125,7 @@ static void sha2_256_transform(uint32_t *state, const void *_input)
     state[4] += e; state[5] += f; state[6] += g; state[7] += h;
 }
 
-static void sha2_256_init(struct sha2_256_state *s)
+void sha2_256_init(struct sha2_256_state *s)
 {
     *s = (struct sha2_256_state){
         .state = {
@@ -147,8 +141,8 @@ static void sha2_256_init(struct sha2_256_state *s)
     };
 }
 
-static void sha2_256_update(struct sha2_256_state *s, const void *msg,
-                            size_t len)
+void sha2_256_update(struct sha2_256_state *s, const void *msg,
+                     size_t len)
 {
     unsigned int partial = s->count & 63;
 
@@ -177,7 +171,7 @@ static void sha2_256_update(struct sha2_256_state *s, const void *msg,
     memcpy(s->buf + partial, msg, len);
 }
 
-static void sha2_256_final(struct sha2_256_state *s, void *_dst)
+void sha2_256_final(struct sha2_256_state *s, void *_dst)
 {
     uint32_t *dst = _dst;
     unsigned int i, partial = s->count & 63;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 13:57:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 13:57:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977322.1364362 (Exim 4.92)
	(envelope-from )
	id 1uCInH-0007pM-SJ; Tue, 06 May 2025 13:57:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977322.1364362; Tue, 06 May 2025 13:57:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCInH-0007pD-P5; Tue, 06 May 2025 13:57:11 +0000
Received: by outflank-mailman (input) for mailman id 977322;
 Tue, 06 May 2025 13:57:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCInG-0007Kz-Us
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 13:57:11 +0000
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com
 [2a00:1450:4864:20::443])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0147713c-2a82-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 15:57:10 +0200 (CEST)
Received: by mail-wr1-x443.google.com with SMTP id
 ffacd0b85a97d-39ee623fe64so5895509f8f.1
 for ; Tue, 06 May 2025 06:57:10 -0700 (PDT)
Received: from localhost.localdomain (172.74.6.51.dyn.plus.net. [51.6.74.172])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099b170e7sm13503239f8f.86.2025.05.06.06.57.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 06:57: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" 
X-Inumbo-ID: 0147713c-2a82-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746539830; x=1747144630; 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;
        bh=CL/ZVVVxEx78jS9Cw9s8DTLqhKzVHZ6dBkuD0mXe5Pk=;
        b=cDSHgQC2ekmnloLZsoTiQl43+hOrl3hry4IVtEUPYA4hvLUMyvfDUrO6Y+qw6uYfNo
         eAYl+wNCwWDeDZ4Fq5F83oMo/mf2d8J/Nz+7LiJbpHqdMEjVLvMXLvBbdkoFdcfQ/9y5
         WheI8YdRLE10SfIH+NWzOJCHbiIDmVfvzItVE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746539830; x=1747144630;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=CL/ZVVVxEx78jS9Cw9s8DTLqhKzVHZ6dBkuD0mXe5Pk=;
        b=MRRYtbEUaOFjIFx3zwf8HvgxUKoiuDfv4fytFLk+zFRpYMp9cCGQIFG2ATDy/5lTcw
         DmHjIBCXULG04NN13d/4rTj+NpWS8B+E5u08v/0r/HgKFs/eKCHvNpWI5NaaWxs60lA1
         +M3bCG5Cmj+LiTNcKUT8cVaxqMWeDH5gN4m/iJ9wmpQFf/vx0JAAkr9dYRKlTNtRSzQy
         W03QgeH8UPaQAUzo5l3wO69WJuNhs7nac0aikH9rtaEN8q0vI0Wl9ZVWM7pgwB8yIYWD
         3YlY24SG7xhYjwWZeFNdLqP5hqtWSaITrzYiHlyHn0lNrSesxG7JJppwt580040dDeYb
         raBw==
X-Gm-Message-State: AOJu0Yz4po1GcXoOQ+AqViRONr9D8Y0BV5FIPxczOXE/hyiY2eeHXFVz
	1O2At/MsdfxBigFhE80LpeQVvQN3fQvtweE+frvBd93QdogZ3aA23M6jHb2IaSKmlCefbbDFXAf
	6TCHsmw==
X-Gm-Gg: ASbGnctFXg87A/z6tkbgkU7bB+cIELFN8Sk4puogWRGBNJ8+hqmiCIfZDYVhibGl7qb
	2VO3tNsWdAydyrFVs0SksKFcCu003WvvRljKxgDkqG7esAAVbwxfIue0la4MXE9eyz0SEMscIqK
	+IeuhKyD+Pq7Nv6a6/E3vZq0v9/7tAaPMddy6wQAcqXkavAOW9IbVfX7ovucntctKnM9hFtiESO
	5i1LgXHxKO+Ab1hO3evNqUAp7ITRnQFX+WN9WpSndbku6ApjafGXTpbgTACKgUuO1cq0r/s6/1k
	JgvdoOTBtrvlS4mMX5COVyu42VeMplZAEvh6m9mvOgPsMhoV9VPKR3i+UKDVzzkQuiWFllnBbXo
	aj8M5N+43clfW2oMr
X-Google-Smtp-Source: AGHT+IF8dKoeMhDyVbHao4B+r0W3a0et6EqcQbUYB3zAjK8quxkCAJaK69PIlErB/bXTsZPUqjRRjw==
X-Received: by 2002:a05:6000:1a8c:b0:3a0:9de8:8a45 with SMTP id ffacd0b85a97d-3a0ac0ec4f9mr2719358f8f.32.1746539829661;
        Tue, 06 May 2025 06:57:09 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Andrew Cooper 
Subject: [PATCH 4/4] kexec: Support non-page-aligned kexec segments
Date: Tue,  6 May 2025 14:56:53 +0100
Message-ID: <20250506135655.187014-5-frediano.ziglio@cloud.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250506135655.187014-1-frediano.ziglio@cloud.com>
References: <20250506135655.187014-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

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 
---
 xen/common/kexec.c       | 23 +++++++-----
 xen/common/kimage.c      | 81 +++++++++++++++++++++-------------------
 xen/include/xen/kimage.h | 15 +++++++-
 3 files changed, 70 insertions(+), 49 deletions(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 158f8da6fd..a7b3958c74 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -910,7 +910,7 @@ static uint16_t kexec_load_v1_arch(void)
 }
 
 static int kexec_segments_add_segment(unsigned int *nr_segments,
-                                      xen_kexec_segment_t *segments,
+                                      struct kimage_segment *segments,
                                       mfn_t mfn)
 {
     paddr_t maddr = mfn_to_maddr(mfn);
@@ -936,7 +936,7 @@ static int kexec_segments_add_segment(unsigned int *nr_segments,
 
 static int kexec_segments_from_ind_page(mfn_t mfn,
                                         unsigned int *nr_segments,
-                                        xen_kexec_segment_t *segments,
+                                        struct kimage_segment *segments,
                                         bool compat)
 {
     void *page;
@@ -991,7 +991,7 @@ done:
 static int kexec_do_load_v1(xen_kexec_load_v1_t *load, int compat)
 {
     struct kexec_image *kimage = NULL;
-    xen_kexec_segment_t *segments;
+    struct kimage_segment *segments;
     uint16_t arch;
     unsigned int nr_segments = 0;
     mfn_t ind_mfn = maddr_to_mfn(load->image.indirection_page);
@@ -1001,7 +1001,7 @@ static int kexec_do_load_v1(xen_kexec_load_v1_t *load, int compat)
     if ( arch == EM_NONE )
         return -ENOSYS;
 
-    segments = xmalloc_array(xen_kexec_segment_t, KEXEC_SEGMENT_MAX);
+    segments = xmalloc_array(struct kimage_segment, KEXEC_SEGMENT_MAX);
     if ( segments == NULL )
         return -ENOMEM;
 
@@ -1103,9 +1103,10 @@ static int kexec_load_v1_compat(XEN_GUEST_HANDLE_PARAM(void) uarg)
 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;
+    unsigned int i;
 
     if ( copy_from_guest(&load, uarg, 1) )
         return -EFAULT;
@@ -1113,14 +1114,18 @@ 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 ( i = 0; i < load.nr_segments; i++ )
     {
-        ret = -EFAULT;
-        goto error;
+        if ( copy_from_guest_offset((xen_kexec_segment_t *)&segments[i],
+                                    load.segments.h, i, 1) )
+        {
+            ret = -EFAULT;
+            goto error;
+        }
     }
 
     ret = kimage_alloc(&kimage, load.type, load.arch, load.entry_maddr,
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
index 212f5bd068..296febeb09 100644
--- a/xen/common/kimage.c
+++ b/xen/common/kimage.c
@@ -96,7 +96,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;
@@ -119,29 +119,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
@@ -221,7 +198,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);
@@ -229,7 +206,7 @@ static int kimage_normal_alloc(struct kexec_image **rimage, paddr_t entry,
 
 static int do_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;
 
@@ -264,7 +241,7 @@ static int do_kimage_crash_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)
 {
     /* Verify we have a valid entry point */
     if ( (entry < kexec_crash_area.start)
@@ -276,7 +253,7 @@ static int kimage_crash_alloc(struct kexec_image **rimage, paddr_t entry,
 
 static int kimage_crash_alloc_efi(struct kexec_image **rimage, paddr_t entry,
                                   unsigned long nr_segments,
-                                  xen_kexec_segment_t *segments)
+                                  struct kimage_segment *segments)
 {
     return do_kimage_crash_alloc(rimage, entry, nr_segments, segments);
 }
@@ -694,16 +671,18 @@ 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;
+    unsigned int dest_offset;
     paddr_t dest, end;
     int ret;
 
     to_copy = segment->buf_size;
     src_offset = 0;
     dest = segment->dest_maddr;
+    dest_offset = segment->dest_offset;
 
     ret = kimage_set_destination(image, dest);
     if ( ret < 0 )
@@ -718,7 +697,7 @@ static int kimage_load_normal_segment(struct kexec_image *image,
 
         dest_mfn = dest >> PAGE_SHIFT;
 
-        size = min_t(unsigned long, PAGE_SIZE, to_copy);
+        size = min_t(unsigned long, PAGE_SIZE - dest_offset, to_copy);
 
         page = kimage_alloc_page(image, dest);
         if ( !page )
@@ -728,7 +707,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 + dest_offset, segment->buf.h, src_offset, size);
         unmap_domain_page(dest_va);
         if ( ret )
             return -EFAULT;
@@ -736,6 +715,7 @@ static int kimage_load_normal_segment(struct kexec_image *image,
         to_copy -= size;
         src_offset += size;
         dest += PAGE_SIZE;
+        dest_offset = 0;
     }
 
     /* Remainder of the destination should be zeroed. */
@@ -747,7 +727,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
@@ -755,12 +735,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 )
     {
@@ -770,14 +752,16 @@ 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->buf.h,
+        if ( dest_offset )
+            memset(dest_va, 0, dest_offset);
+        ret = copy_from_guest_offset(dest_va + dest_offset, segment->buf.h,
                                      src_offset, schunk);
         memset(dest_va + schunk, 0, dchunk - schunk);
 
@@ -785,17 +769,18 @@ static int kimage_load_crash_segment(struct kexec_image *image,
         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;
 }
 
 static int kimage_load_segment(struct kexec_image *image,
-                               xen_kexec_segment_t *segment)
+                               struct kimage_segment *segment)
 {
     int result = -ENOMEM;
     paddr_t addr;
@@ -826,9 +811,29 @@ static int kimage_load_segment(struct kexec_image *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)
 {
     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 )
     {
diff --git a/xen/include/xen/kimage.h b/xen/include/xen/kimage.h
index 6626058f8b..3099b489b5 100644
--- a/xen/include/xen/kimage.h
+++ b/xen/include/xen/kimage.h
@@ -30,6 +30,17 @@ struct purgatory_info {
     Elf_Shdr *sechdrs;
 };
 
+struct kimage_segment {
+    union {
+        XEN_GUEST_HANDLE(const_void) h;
+        uint64_t _pad;
+    } buf;
+    uint64_t buf_size;
+    uint64_t dest_maddr;
+    uint64_t dest_size;
+    unsigned int dest_offset;
+};
+
 typedef struct xen_kexec_regs {
         uint64_t rax;
         uint64_t rbx;
@@ -55,7 +66,7 @@ struct kexec_image {
     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;
@@ -77,7 +88,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.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 14:05:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 14:05:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977358.1364373 (Exim 4.92)
	(envelope-from )
	id 1uCIvG-0002Ft-OW; Tue, 06 May 2025 14:05:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977358.1364373; Tue, 06 May 2025 14:05: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 1uCIvG-0002Fm-LX; Tue, 06 May 2025 14:05:26 +0000
Received: by outflank-mailman (input) for mailman id 977358;
 Tue, 06 May 2025 14:05:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCIvF-0002Fg-JQ
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 14:05:25 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 27274379-2a83-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 16:05:23 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-441ab63a415so57413905e9.3
 for ; Tue, 06 May 2025 07:05:23 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099ae3cfbsm13583087f8f.40.2025.05.06.07.05.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 07:05: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" 
X-Inumbo-ID: 27274379-2a83-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746540323; x=1747145123; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=PAyJOpVVAN2YTo8d53BgwloaGhKjOkoV66ckmxX0dG8=;
        b=BRq5m5Quufu3XjL46OqhjvmdyJqKSqKThPW5W+F53kCMkjTPPydBp0q/CoSLaf5fbl
         jwB+bl4yiuFcEK3kEaT5/W7rotmEGfo+vVbFVMbGcqz02wn783xIf7+hIgeIpU8CPuhV
         sQj6QrZDDtFcXHgRRoJmmSGbIYrcTCD44c42c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746540323; x=1747145123;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PAyJOpVVAN2YTo8d53BgwloaGhKjOkoV66ckmxX0dG8=;
        b=gT72qJPh/kiQP2S1OcUxg8akfe2wN15o2eMIkhVbnsjqE996GzdUU4e2BTyBG1a/qy
         kxsiEMIwE59m2d+h+Racuehw+xhZxSDYjSnPYxNRgG7hjKUOb2ge2AmqvJZXzWIszTSv
         PIO3imU2/a7hVS+I7rzCKkyB1ZtuBf+yMGX9Csv0lEjCB/PZ872JPhjgl9YQPoUBozN5
         WknMVHiI3oaKteM9ZE5dHCY9aY7Y8lAV8xiGmPsfAI8a41Z6WRlQvscZQ9uLc+Y7a4m3
         pkqiUcvKrBISOSyN3oG1zVYf9jSYA2cUbeCp2Y86Sl+WpOAD/9QYqG2fi+lJaUuRdD3a
         GlvQ==
X-Forwarded-Encrypted: i=1; AJvYcCWgYUl2DXocaaxfMVxakCr8h5HwkCQcEJEsPa+ua2knxg+nnsYxSCJXmIuTSxVWNuNxRJt0TNnAeHU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyiIPHWCrGZRve33tP5yXeM8oBqIIBTVp5z7oPT9Of/fVzj55Kn
	7L6AmOy7+rFE7PqGtNqjnNQzJPFIeF0l4KZOIsNhUlzRObQ1VBeHq+lINPCB7po=
X-Gm-Gg: ASbGncvAG12uD9hIrvNb02tGfosPEIocYIRDqxg2x5qIo5IwKI5mq41TBS45i++4GX0
	vJwb3RAu0qcEL0+yRW1kYTuMYK56cfsBeZb/+du4XTpjWQwXeHeOCvsgj7LR32W2ZZRvyGWrpr7
	1cYfJt1x9Am5yHqVG6wmRiBsix3ip35ezu5c3uYtqWBY34X5wsigXc4QlI+D/91/x9Zt7tuWCsK
	kFFscPS7ogTp9rCdiIFLjbXQzQOWNjkPER8oqSq6YSmL0GyNZzdaSfie/OatNZ6wrREsyejnuAm
	1BkD/+gnM3LrWuWkFO+ktPm4ygyDCm9y0iDCqo/IhAsA4fPgeREMGQ6zNsbEMPaIZisUtpPpuwS
	wzo9jtg==
X-Google-Smtp-Source: AGHT+IGYqC3EfPrsnPM0XuQRMnZCLCCZsvVeH2bFzbMeedDpBydufmcYOQfhj19fV9MfyutbCMOwLw==
X-Received: by 2002:a05:600c:358b:b0:441:b5cb:4f94 with SMTP id 5b1f17b1804b1-441d0fbd5cfmr24821455e9.5.1746540322650;
        Tue, 06 May 2025 07:05:22 -0700 (PDT)
Message-ID: 
Date: Tue, 6 May 2025 15:05:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] xen/lib: Export additional sha256 functions
To: Frediano Ziglio ,
 xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: <20250506135655.187014-1-frediano.ziglio@cloud.com>
 <20250506135655.187014-2-frediano.ziglio@cloud.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: <20250506135655.187014-2-frediano.ziglio@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06/05/2025 2:56 pm, Frediano Ziglio wrote:
> diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
> index 47d97fbf01..ea8bad67e4 100644
> --- a/xen/include/xen/sha2.h
> +++ b/xen/include/xen/sha2.h
> @@ -9,6 +9,16 @@
>  
>  #define SHA2_256_DIGEST_SIZE 32
>  
> +struct sha2_256_state {
> +    uint32_t state[SHA2_256_DIGEST_SIZE / sizeof(uint32_t)];
> +    uint8_t buf[64];
> +    size_t count; /* Byte count. */
> +};
> +
> +void sha2_256_init(struct sha2_256_state *s);
> +void sha2_256_update(struct sha2_256_state *s, const void *msg,
> +                     size_t len);
> +void sha2_256_final(struct sha2_256_state *s, void *_dst);
>  void sha2_256_digest(uint8_t digest[SHA2_256_DIGEST_SIZE],
>                       const void *msg, size_t len);

sha2_256_digest() is unlike the others as it holds sha2_256_state
internally.  I'd suggest having all of the additions below this point,
which group them more nicely.

Can fix on commit.  Otherwise LGTM.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 06 14:12:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 14:12:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977371.1364383 (Exim 4.92)
	(envelope-from )
	id 1uCJ1j-0004AI-EG; Tue, 06 May 2025 14:12:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977371.1364383; Tue, 06 May 2025 14:12:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCJ1j-0004AB-BM; Tue, 06 May 2025 14:12:07 +0000
Received: by outflank-mailman (input) for mailman id 977371;
 Tue, 06 May 2025 14:12:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCJ1h-0004A5-VA
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 14:12:06 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 164583d8-2a84-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 16:12:04 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43d07ca6a80so22948955e9.1
 for ; Tue, 06 May 2025 07:12:04 -0700 (PDT)
Received: from localhost.localdomain
 (cpc92320-cmbg19-2-0-cust1786.5-4.cable.virginm.net. [82.13.70.251])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-441d1266624sm14510405e9.2.2025.05.06.07.12.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 07:12: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" 
X-Inumbo-ID: 164583d8-2a84-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746540724; x=1747145524; 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;
        bh=H8uvLKZXT8Vp9GWlOaZIY/aoJ+NYq9e+xVhtrUg3o9U=;
        b=O8WTKYFKXEXLiD8SNinKBP1U0GMDSxOyuapjaSvX+0QChTLEwsbDTEU07GzA59nakT
         y7IZeEmuoPtG37lPu+OubjHbjeIuIhyPqU0hGeOpK3xPZG2tZvzaR6Z//3WLXci5vmNg
         NbLpyViFSDm2u9T9eBkLg0cAR9SIeJhuUJZ9VNBCKOGVbK7Yx6oHPjOKIHUdDkz87g3Q
         FfLPY0NAR/SKb9I6fzVrUkLuILxu8LJfpyPmerpKrbnUSG03pTkHrYuAxNMRQgtpeU7g
         Dcy2FGYVMWybGX429618zIFCqEECI63v6uUX+4HCqkwRjTeiQ51eYvTkCqEi39/YVAvi
         BnMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746540724; x=1747145524;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=H8uvLKZXT8Vp9GWlOaZIY/aoJ+NYq9e+xVhtrUg3o9U=;
        b=TfJK3Q1K4OCnM1xnjXnJIvWagvzic/2YH0EBx3qqPDw6nc8A4z6LU1SFwg7XqdfHSe
         1clSJE1L8g3fE8lsWLsLUdSqnmHl3yoAIgVCnqevkM6DTx6zegUfw+cxP5AmZA/+SI/w
         HPVwvcA/HB0Dxu+xHdN2Sy4n2+Qy0C6KvgD+nJEwSWz437Sb29SiX2XmPUpe0LZyCIZu
         bnb6wGnM04UNt6pxMSmS/DwH91fl58vYzM8vGAPx6bmjtxDA7h5iJ5DAO571dNGOsxjJ
         6hMdFX5FEsuXtHenDf7wW/oj5Ho1FB3KoKikSUrFEciKAmlN/XW2XuIuRxsj23DboXSU
         rUMA==
X-Forwarded-Encrypted: i=1; AJvYcCU1GAubkwmXk5AjU58Sgi1PTNd5QddaNx2Xor6jr98WGlNsU5R9Y6F7aXqDK+gD+xGioWxOpFCLJpM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyuW7/rSp1HAcWLjYE4yRl1432z9qyUwCNBf0j6oUzhQPWa6kPg
	s8NKFCxbFrUenxfqouxlDFt3Da7arM3PmOZOidAjAQ7WjfgjDuJy
X-Gm-Gg: ASbGncuBSfe/d0cf6Yag4yLs3zDcZoSSezzHd17ECleTI+28enNIy6s1sNSf62VDC0e
	OHuHcVVqaetb/eWO79fc011gC6f6vY36bGcPj8o5248nA+ztiL9brQtcXqojrQ6XnMn6gWV/LNi
	ynlhqJrI6YbemkOCHYSt2ddS79CqfxnxZedmvXJbSIeimwcX/KK2nQsxKHnwjbc97/Yw0uMGYo7
	pxdqlfTCjnkmzv+1zAjqKXPgD7OHKWobCq5sRKsy7BqJWtC6y+jXfGDDAgPHvYEpP3XVhpVBpXM
	KNo3ulNSji+yjozQolehHu983vz9baCEyQMG70NHWi+gWaD5Ns9SVaCNhCMPCu40xgQ04DONva3
	9PEnnAOAT6Cn8WEdDY8NBkTRBbWl73NepFY0oD626je0=
X-Google-Smtp-Source: AGHT+IHAPtErJzs/PpDmC/McmTo1ZR1yyAn4W7biUk0n0KPEpdsjw5oRWVZX/I3wjLVQJPvhu00hbg==
X-Received: by 2002:a05:600c:871b:b0:43d:fa58:8378 with SMTP id 5b1f17b1804b1-441d053bf8dmr35903265e9.33.1746540723921;
        Tue, 06 May 2025 07:12:03 -0700 (PDT)
From: Andrii Sultanov 
X-Google-Original-From: Andrii Sultanov 
To: frediano.ziglio@cloud.com
Cc: Volodymyr_Babchuk@epam.com,
	andrew.cooper3@citrix.com,
	anthony.perard@vates.tech,
	bertrand.marquis@arm.com,
	jbeulich@suse.com,
	julien@xen.org,
	michal.orzel@amd.com,
	roger.pau@citrix.com,
	sstabellini@kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 0/4] Allows Secure Boot for Kexec
Date: Tue,  6 May 2025 15:11:53 +0100
Message-ID: <20250506141153.994534-1-andriy.sultanov@vates.tech>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250506135655.187014-1-frediano.ziglio@cloud.com>
References: <20250506135655.187014-1-frediano.ziglio@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The 2nd and 3rd patches got lost somewhere and do not seem to be shown on lore,
at the very least.


From xen-devel-bounces@lists.xenproject.org Tue May 06 14:14:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 14:14:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977380.1364393 (Exim 4.92)
	(envelope-from )
	id 1uCJ45-0004t4-QO; Tue, 06 May 2025 14:14:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977380.1364393; Tue, 06 May 2025 14: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 1uCJ45-0004sw-Mn; Tue, 06 May 2025 14:14:33 +0000
Received: by outflank-mailman (input) for mailman id 977380;
 Tue, 06 May 2025 14:14:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCJ44-0004sq-HY
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 14:14:32 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6dfa8867-2a84-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 16:14:31 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43d04ea9d9aso26215205e9.3
 for ; Tue, 06 May 2025 07:14:31 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441b2ad78f6sm218721635e9.2.2025.05.06.07.14.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 07:14:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6dfa8867-2a84-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746540871; x=1747145671; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=OZz4YrC1KS2SabAnChJUkqQGGPUK/TePs3MU2l5rXRM=;
        b=bv3QbVoBIY82aPqulHki7N50vEF+XIbkl4rQmZ34e2aiFsHaMnx7wi7+htovnu2CyV
         lGCjAtG0SG7TNbsB7Bcp0evLX9gQ/Rm7/yqEXcs822r9rQsWLxropXOKjsz95t3dcHgo
         9O97r/HK8EdqaecxQqbhGFYB8jVZHx8U3nNbg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746540871; x=1747145671;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=OZz4YrC1KS2SabAnChJUkqQGGPUK/TePs3MU2l5rXRM=;
        b=EfDyZp+b2tRFJGGtOZ8lpuSuj3RuCRXG14vvC0NCdjQtNoQ86yhf0LDjdIMMO5SZN8
         BY3L1W6aJpKo376/S0jiTTVPPjREYf1R+gez77S6TYpQH5gjgVxhb4Pqyv4oMXV2sMIz
         6sR0zN2G9Fd6WqwKZEslJOjrVgk7UlqyzOGGqEE/EvNDNL0dk52doJUd/uhzXgm0B6F/
         WDSGcUOuvvwdr4rXc49kQfBeu2C7vUdSZnf2PCr6o85u9P8X6wX/VY9Kdfw+VBh2dCW+
         lOCbfLfmvG4S/6QJOX+sh2wLSIadpaMx/avJfoweNCKJswX7a3OfYJpZztFh8WHo3ubI
         v0bg==
X-Gm-Message-State: AOJu0YxgNYgyF7t/4zBoKlhr8Gw2cqHYozEFqX1pKfCSuzWrA3neg5Rc
	rbPIqv2YEvJ77V3IOuIc5UVeIC4eFMp9Mv3KHRHSZygoiIEnJm0hANUyfQVj83s=
X-Gm-Gg: ASbGncsbUSIiiepDOF3z9KaC0q4/2tcAf+kHZtgNeB8Z0vpVoDIX6WkH9HU4D5nSkVI
	HwxHcFNp9quWJDn8n/ekR3RBPa71m0qBkGPnzPdrq8NP/sE4taQ/daITV/GviGQek+6fa5vQ2mD
	1dCvXUwyvyjHKukhI1Ir/lNdB1EPrr8stMf4R5xCao+pHRIrSO6Axc+xwryvsY644xfL7SFbvt/
	R/gWaO+8TJ1JljAlu0vdBst3rC/ETBwxLXCyke29qefnYkTV63I1yu+WAxKRta/w894qvUfcNk+
	q2UD9+xVm6SLnhbHWGKONSdMNXHjmLUxT1nzVcciHWZv0A==
X-Google-Smtp-Source: AGHT+IFgIwrgNHbVWIfOS8wlE/K8hEnuiijOz2FqOk4D9ubjD5R9e1uJnQ3MqzPGB+lQKV5DJWgtJA==
X-Received: by 2002:a05:600c:5010:b0:441:bf4e:89c8 with SMTP id 5b1f17b1804b1-441c48b02e1mr112757135e9.3.1746540871314;
        Tue, 06 May 2025 07:14:31 -0700 (PDT)
Date: Tue, 6 May 2025 16:14:30 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v3 04/11] vpci/header: Emulate extended capability list
 for dom0
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-5-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250421061903.1542652-5-Jiqian.Chen@amd.com>

On Mon, Apr 21, 2025 at 02:18:56PM +0800, Jiqian Chen wrote:
> Add a new function to emulate extended capability list for dom0,
> and call it in init_header(). So that it will be easy to hide a
> extended capability whose initialization fails.
> 
> As for the extended capability list of domU, just move the logic
> into above function and keep hiding it for domU.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> ---
> v2->v3 changes:
> * In vpci_init_ext_capability_list(), when domain is domU, directly return after adding a handler(hiding all extended capability for domU).
> * In vpci_init_ext_capability_list(), change condition to be "while ( pos >= 0x100U && ttl-- )" instead of "while ( pos && ttl-- )".
> * Add new function vpci_hw_write32, and pass it to extended capability handler for dom0.
> 
> v1->v2 changes:
> new patch
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/header.c | 36 ++++++++++++++++++++++++++++--------
>  xen/drivers/vpci/vpci.c   |  6 ++++++
>  xen/include/xen/vpci.h    |  2 ++
>  3 files changed, 36 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index c98cd211d9d7..ee94ad8e5037 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -817,6 +817,31 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>                                    PCI_STATUS_RSVDZ_MASK);
>  }
>  
> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
> +{
> +    unsigned int pos = PCI_CFG_SPACE_SIZE, ttl = 480;
> +
> +    if ( !is_hardware_domain(pdev->domain) )
> +        /* Extended capabilities read as zero, write ignore for guest */
> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
> +                                 pos, 4, (void *)0);
> +
> +    while ( pos >= PCI_CFG_SPACE_SIZE && ttl-- )
> +    {
> +        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
> +        int rc;

I'm thinking it might be helpful to avoid setting the handler for the
last capability on the list, or simply for devices that have no
extended capabilities at all:

if ( PCI_EXT_CAP_NEXT(header) >= PCI_CFG_SPACE_SIZE )
{
    int rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
                               pos, 4, (void *)(uintptr_t)header);

    if ( rc )
        return rc;
}

Otherwise on systems with a lot of devices it can be quite wasteful to
set a handler to just return the next capability as 0.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 14:24:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 14:24:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977393.1364403 (Exim 4.92)
	(envelope-from )
	id 1uCJDt-0006yH-LY; Tue, 06 May 2025 14:24:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977393.1364403; Tue, 06 May 2025 14:24: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 1uCJDt-0006yA-IX; Tue, 06 May 2025 14:24:41 +0000
Received: by outflank-mailman (input) for mailman id 977393;
 Tue, 06 May 2025 14:24:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCJDr-0006y4-SR
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 14:24:39 +0000
Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com
 [2607:f8b0:4864:20::549])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d4c9c7db-2a85-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 16:24:34 +0200 (CEST)
Received: by mail-pg1-x549.google.com with SMTP id
 41be03b00d2f7-af2f03fcc95so5676845a12.1
 for ; Tue, 06 May 2025 07:24:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d4c9c7db-2a85-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1746541473; x=1747146273; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=GvQ0P+wUKfaLn/ATwLSuvFKy87onNqdIa1sjwEnWlHA=;
        b=W97w3FdelJF9qHAJtJOy3dE8dui9QHrhWYFE+QtCSymT17lNJsmIoEtfbUklnflV2g
         OYKdiMk/zSyH3NYvDSp8fBhrI+y1os9ioPBbje+uDCNxfMvqYMYWlFA2bv6kB7kaO/a1
         UFQKGvaaqrcuF0IXCG5/QcU5yFQw3Fo8M1QrF/YzIAnQSWtyKmRsqn/IAiaQglvEZbmw
         UP3kdWN4EEe3AY9947up8mlVgXjfZPye7aNKaVbdKHpbTn9rQIZfjggl74xnhQW6zYpz
         lgyDlSsvprgcnoizlj0ty1DfUAI5SxQjFEkorakRJzWQmnusclOPCRV/H9gEhwP8EgaR
         1xLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746541473; x=1747146273;
        h=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;
        bh=GvQ0P+wUKfaLn/ATwLSuvFKy87onNqdIa1sjwEnWlHA=;
        b=MVR7Kk57LeVYS+RmBs7QOxYUho6XYfgY0PdJS056KbbinFKyXXhl5qNa+tS7es1M/3
         j9EKNKUq6XMEYZxF2EaeDRIGXk18KZD7ABN1drrq8qoyVouLpKGAWHLagsS/MCVjimJ4
         5PJ8O8ur6TS3ncwIj93nprbraLE5xK4SzZo5RrXBVUVgFfZs9SxxtigjQ1fFGBzHgifh
         tRw+rBugHpTJS/WOw/7Xtx7w9WGzAp4AZKSXngasTWovGmysIArJbF0hNaeGPT3GfZ2Z
         oorpHJj7aqv9BE87ImeLQdXZcO7tcvpSgLqoMEfYjQ5t24m5ghKey98XOz4RFolWcQNo
         86dw==
X-Forwarded-Encrypted: i=1; AJvYcCXn+pOzphPCDkUVJOHT7zEy7ts2ZqgRc0z9JLI7RfJZ6OuFEgGnpw0umgS0cfmjhG9g92JKT3/x4jE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy77/fPhwlqf/FEGpk610q+U+uhCZInYuMlUYG+e8s5tezJyUaq
	UZh5aSLJN5bCL3EuzFAqac+x12sHw5BJnqSirfkKphjX8J9KNj/3iNNj60jocbJwpq0GqmUrY5u
	AVA==
X-Google-Smtp-Source: AGHT+IG+tb6DAqfEkF2OtffXMj0e0GMqYjoEo/yCNWTnFNMEaweQ67wd6DzOO6xB801yCXPJlU9wA/n2y+w=
X-Received: from pfay24.prod.google.com ([2002:a05:6a00:1818:b0:736:b2a2:5bfe])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:cf42:b0:227:e709:f71
 with SMTP id d9443c01a7336-22e1ea822aemr186821615ad.29.1746541472989; Tue, 06
 May 2025 07:24:32 -0700 (PDT)
Date: Tue, 6 May 2025 07:24:31 -0700
In-Reply-To: <20250506092015.1849-4-jgross@suse.com>
Mime-Version: 1.0
References: <20250506092015.1849-1-jgross@suse.com> <20250506092015.1849-4-jgross@suse.com>
Message-ID: 
Subject: Re: [PATCH 3/6] x86/msr: minimize usage of native_*() msr access functions
From: Sean Christopherson 
To: Juergen Gross 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hyperv@vger.kernel.org, 
	kvm@vger.kernel.org, xin@zytor.com, "K. Y. Srinivasan" , 
	Haiyang Zhang , Wei Liu , 
	Dexuan Cui , Thomas Gleixner , Ingo Molnar , 
	Borislav Petkov , Dave Hansen , 
	"H. Peter Anvin" , Paolo Bonzini , 
	Vitaly Kuznetsov , Boris Ostrovsky , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="us-ascii"

On Tue, May 06, 2025, Juergen Gross wrote:
> In order to prepare for some MSR access function reorg work, switch
> most users of native_{read|write}_msr[_safe]() to the more generic
> rdmsr*()/wrmsr*() variants.
> 
> For now this will have some intermediate performance impact with
> paravirtualization configured when running on bare metal, but this
> is a prereq change for the planned direct inlining of the rdmsr/wrmsr
> instructions with this configuration.

Oh the horror, KVM's probing of errata will be marginally slower :-)

> The main reason for this switch is the planned move of the MSR trace
> function invocation from the native_*() functions to the generic
> rdmsr*()/wrmsr*() variants. Without this switch the users of the
> native_*() functions would lose the related tracing entries.
> 
> Note that the Xen related MSR access functions will not be switched,
> as these will be handled after the move of the trace hooks.
> 
> Signed-off-by: Juergen Gross 
> ---

Acked-by: Sean Christopherson 


From xen-devel-bounces@lists.xenproject.org Tue May 06 14:32:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 14:32:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977404.1364413 (Exim 4.92)
	(envelope-from )
	id 1uCJLX-0000QC-Do; Tue, 06 May 2025 14:32:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977404.1364413; Tue, 06 May 2025 14:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCJLX-0000Q5-AZ; Tue, 06 May 2025 14:32:35 +0000
Received: by outflank-mailman (input) for mailman id 977404;
 Tue, 06 May 2025 14:32:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCJLW-0000Py-7u
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 14:32:34 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f2488428-2a86-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 16:32:33 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5f6222c6c4cso8415912a12.1
 for ; Tue, 06 May 2025 07:32:32 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1894c0356sm711598966b.100.2025.05.06.07.32.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 07:32: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" 
X-Inumbo-ID: f2488428-2a86-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746541952; x=1747146752; 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;
        bh=wX47cjJ7Qc7j9RHMbIazl4f6pXIf8iTrEpBSSWuNjyQ=;
        b=Gg6jg/a6airJAXyxttPaHC4V0UrD0fDWuOlK7laBt7bd3qxRE6mVR2iVl56NIYHBix
         9nFOEIi5CUTem0LerNO9kQoS/wuEGOKz9xKva2VL2V6ucIGPNmFiB7Q86eIH0IINmecN
         ZrpqI6E5EpiKY3mnm39y8kDtk0Rj3twDvy11c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746541952; x=1747146752;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=wX47cjJ7Qc7j9RHMbIazl4f6pXIf8iTrEpBSSWuNjyQ=;
        b=hYkNY/1KQtktrziApZQbBcjTh6OIG0xNuCMRwOFU0WeqdAfUcnjjW2JBmQJ4El0UMk
         hklKhWh2Q7T2GufC1G0eggF4kN3pvG9AksHU1wPLFdizEN+VBZMfDyWvRoWWs/08lvow
         w29ScvNlLzKSawPqQKlLhA6YvssM62YXyqS/Jv9JtHHw/v52WwufkuDYtTidUjZN0CNc
         KSgIIR4MDV7BoPPns6Utu0QIkHHJLpC/1c5OYx8N4vMsFFNYoZQZ0gZUQRH2FvW+Y0m0
         sCl7EwAWFjZONqBmZGmBA+zS/ykQVeMLYjOOcnrV7l+uGc70/HQaaaAdDB5hIzex+/U8
         91Sg==
X-Forwarded-Encrypted: i=1; AJvYcCUaQe/YiBL3DahXjr3x11eXqBHGQOdpQoagVL6ouN32PfZnpugkeEUv6czE1EWZyUwPr/KWZCw35W0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxkZzTDiEyo3zh7Yu6h4tcKqdGyJYd1AXI5YBhk5ZTdhUe17jeR
	tPxN5F429l7Bk5PrQCDIBfVOf6C8zovA9PtSpEqOvUf5lragLuJGLHcCU5zMxuYPVJgM4BRGA6g
	=
X-Gm-Gg: ASbGncs7e9r8lchRgxucUeCGXmtjU9hemoCDmjR/Hwn+xk+xqg2PrmZi2yLPOkCvicV
	VoTxa0rRUzzM/j3uAbyPK4uaG3029rQkJA7DvyCfZOS4z7hZfRfUHmI4aLEEE5rXXZhQYNYl9pm
	aVI/QpsRtw95P/j9LzNu+gLY6AVs5nuQIDzzGoQ0uY4Eh+xP3+UbiTd5cVf8fPH6unr31ho5+HV
	ySWwt9GIFKPnizJUCSP+SiSmq8pbUfVIlgSFtLkrZvi/ifDET2W8gZOudiiRSZGZwzMmapHuwVF
	IpYPtqA7qK3nR8vSgfZ8m3fwpQR0wJfVGTDvwL9FYJgDRbRzq6CJpZlIBMqG+Dj8
X-Google-Smtp-Source: AGHT+IF5U0V92ig7lw9c/he+509NaNxI2WMMl0g29gIXl9BgdyW2TJtIJF3BQ3lf6MpdW9IKQX8Guw==
X-Received: by 2002:a17:907:2d07:b0:ac7:e815:6e12 with SMTP id a640c23a62f3a-ad1a4a09f38mr1091046466b.33.1746541952305;
        Tue, 06 May 2025 07:32:32 -0700 (PDT)
From: Ross Lagerwall 
To: Xen-devel ,
	xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 0/4] LivePatch signing support
Date: Tue,  6 May 2025 15:32:12 +0100
Message-ID: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Live patch signing support was mentioned as future work in the design
document several years ago. This series finally implements support for
it since it is a requirement of Secure Boot to prevent loading unsigned
code into Xen.

Note that this series depends on another patch that has not yet been
merged:
xen/lib: Export additional sha256 functions
https://lists.xenproject.org/archives/html/xen-devel/2025-05/msg00222.html

Jennifer Herbert (1):
  livepatch: Verify livepatch signatures

Kevin Lampis (1):
  livepatch: Embed public key in Xen

Ross Lagerwall (2):
  docs: Introduce live patch signing
  crypto: Add RSA support

 docs/misc/livepatch.pandoc      |  104 +-
 xen/common/Kconfig              |   18 +
 xen/common/Makefile             |    1 +
 xen/common/livepatch.c          |  175 ++++
 xen/common/livepatch_elf.c      |   55 +
 xen/common/mpi.c                | 1724 +++++++++++++++++++++++++++++++
 xen/crypto/Makefile             |   13 +
 xen/crypto/rsa.c                |  194 ++++
 xen/include/xen/livepatch.h     |    5 +
 xen/include/xen/livepatch_elf.h |   18 +
 xen/include/xen/mpi.h           |   63 ++
 xen/include/xen/rsa.h           |   72 ++
 xen/tools/extract-key.py        |   37 +
 13 files changed, 2427 insertions(+), 52 deletions(-)
 create mode 100644 xen/common/mpi.c
 create mode 100644 xen/crypto/rsa.c
 create mode 100644 xen/include/xen/mpi.h
 create mode 100644 xen/include/xen/rsa.h
 create mode 100755 xen/tools/extract-key.py

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 14:32:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 14:32:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977405.1364422 (Exim 4.92)
	(envelope-from )
	id 1uCJLZ-0000eV-Mi; Tue, 06 May 2025 14:32:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977405.1364422; Tue, 06 May 2025 14: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 1uCJLZ-0000eM-K7; Tue, 06 May 2025 14:32:37 +0000
Received: by outflank-mailman (input) for mailman id 977405;
 Tue, 06 May 2025 14:32:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCJLY-0000Q4-Ku
 for xen-devel@lists.xen.org; Tue, 06 May 2025 14:32:36 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f2798a86-2a86-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 16:32:33 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-acec5b99052so1141944866b.1
 for ; Tue, 06 May 2025 07:32:33 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1894c0356sm711598966b.100.2025.05.06.07.32.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 07:32: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" 
X-Inumbo-ID: f2798a86-2a86-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746541952; x=1747146752; darn=lists.xen.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to;
        bh=wX47cjJ7Qc7j9RHMbIazl4f6pXIf8iTrEpBSSWuNjyQ=;
        b=s6aHJnaSUZGrFKzvvYizoBTKdvO1q09g3OUVd57s/bnsve9tOPWeDW2/79yvlMOar/
         NprJN+oHdchNP2qSHR7sumEsPT1YGXgA7BSUwg1E7zhpMLZmgOfTLRWVAf/UwtNMj+Vd
         G1baynVa5p1mribKmFWRwcfmloa/kb6l4LKl8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746541952; x=1747146752;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=wX47cjJ7Qc7j9RHMbIazl4f6pXIf8iTrEpBSSWuNjyQ=;
        b=ElVD5hxd3VblgdnHe5VC2YBqw0hGZTgGQ1TqNGbaCeAkcTiejiS5LMoa0eS9GdUG3p
         NfS6TSnby8n28fZmXQ1OWN6esqMjMbA+S5aRgzGhsgJPFtpycwOGsG1DpiE9EnzJiOhX
         HYULDniQYrygc7nmFYi7d1+RfMJ/6QC1dbUJPFRV1XYgIN8HXMDQps5iWbN9cUEA4ZQa
         RrUwVVvXys1nPXLzRef6yf2AYTOO0FhIxnFO3suWMT2zvHQm2yfKsLFwNNQyeC4oQ77m
         cr0uQ+KlXgyFUdLJo7NksUFpkm7sbqYtxFnGUgOFb5lAWVD4LQRFzGbz4e4LAOC0p7Dx
         tclg==
X-Gm-Message-State: AOJu0YzpEZfjRh4X8D4RgwN65dhSMHChBEgcMaE3YUryKkp75PiAJ86e
	eFoWh5jioTvAnZdC5gL0aSMx5t9ZH7ttxG1EFCKKnm/rhKLRwYUuw6Ne3jF37AfslwF+Fy/dYYk
	=
X-Gm-Gg: ASbGncvu92H++EURLUKHxsA/AAUOLAZ4iF6SOh29f4LAgZDIsXUOGUWau/Fi8572B6U
	LTH8UV+UQY7uL31RZrdi6XqjXYqEn1somA0Ctiv2gNmeY3Ga6jScQGhtZ1aX0mHeskvBiEFeEgo
	zvKn7jdxQ191qcrJSRG2nES5S08x0lYnC4Pm2rpEIWpKNpezOTQ78AtH9JmWLPxUZpzrmHBpmW0
	0+FWKm8iupzfLl/QMypTKNBPeZ5Ih1mwJ/+swec9rnzygMjzHCdGHDInywRCs6rnPel/e1CNpdR
	nlzfnK+DmMUJfFzaeNT7E2odlJKBf6LuSrQVB1jt7FYgSnT6WEAlNCRMmXA/szdW
X-Google-Smtp-Source: AGHT+IF5U0V92ig7lw9c/he+509NaNxI2WMMl0g29gIXl9BgdyW2TJtIJF3BQ3lf6MpdW9IKQX8Guw==
X-Received: by 2002:a17:907:2d07:b0:ac7:e815:6e12 with SMTP id a640c23a62f3a-ad1a4a09f38mr1091046466b.33.1746541952305;
        Tue, 06 May 2025 07:32:32 -0700 (PDT)
From: Ross Lagerwall 
To: Xen-devel ,
	xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 0/4] LivePatch signing support
Date: Tue,  6 May 2025 15:32:12 +0100
Message-ID: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Live patch signing support was mentioned as future work in the design
document several years ago. This series finally implements support for
it since it is a requirement of Secure Boot to prevent loading unsigned
code into Xen.

Note that this series depends on another patch that has not yet been
merged:
xen/lib: Export additional sha256 functions
https://lists.xenproject.org/archives/html/xen-devel/2025-05/msg00222.html

Jennifer Herbert (1):
  livepatch: Verify livepatch signatures

Kevin Lampis (1):
  livepatch: Embed public key in Xen

Ross Lagerwall (2):
  docs: Introduce live patch signing
  crypto: Add RSA support

 docs/misc/livepatch.pandoc      |  104 +-
 xen/common/Kconfig              |   18 +
 xen/common/Makefile             |    1 +
 xen/common/livepatch.c          |  175 ++++
 xen/common/livepatch_elf.c      |   55 +
 xen/common/mpi.c                | 1724 +++++++++++++++++++++++++++++++
 xen/crypto/Makefile             |   13 +
 xen/crypto/rsa.c                |  194 ++++
 xen/include/xen/livepatch.h     |    5 +
 xen/include/xen/livepatch_elf.h |   18 +
 xen/include/xen/mpi.h           |   63 ++
 xen/include/xen/rsa.h           |   72 ++
 xen/tools/extract-key.py        |   37 +
 13 files changed, 2427 insertions(+), 52 deletions(-)
 create mode 100644 xen/common/mpi.c
 create mode 100644 xen/crypto/rsa.c
 create mode 100644 xen/include/xen/mpi.h
 create mode 100644 xen/include/xen/rsa.h
 create mode 100755 xen/tools/extract-key.py

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 14:32:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 14:32:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977410.1364433 (Exim 4.92)
	(envelope-from )
	id 1uCJLp-0001Bw-V5; Tue, 06 May 2025 14:32:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977410.1364433; Tue, 06 May 2025 14:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCJLp-0001Bn-Ro; Tue, 06 May 2025 14:32:53 +0000
Received: by outflank-mailman (input) for mailman id 977410;
 Tue, 06 May 2025 14:32:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCJLo-0000Py-7Y
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 14:32:52 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fd8cce18-2a86-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 16:32:51 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ac3eb3fdd2eso226359866b.0
 for ; Tue, 06 May 2025 07:32:51 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1894c0356sm711598966b.100.2025.05.06.07.32.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 07:32: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" 
X-Inumbo-ID: fd8cce18-2a86-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746541971; x=1747146771; 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;
        bh=bGQj8XO9xK1XWcKjxy5tWwgI9dG4aXp1v1X5ZUMFZno=;
        b=Hm5unEdNknoyiEVsKUFmqE9a9k61o+cZbe7XbYKw+mR7g50LdQwSGYj+GWP4zTThbf
         yrCoMR6wmdKtVOTQGEJVPcOw9zB4eWLLq9o9QYPmQLZiKbM8NaRBaEDl+M0rLs7afj26
         P1I5BHVpoqkAMG7bI3UwdF2fPJLXiAHb0vc6I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746541971; x=1747146771;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=bGQj8XO9xK1XWcKjxy5tWwgI9dG4aXp1v1X5ZUMFZno=;
        b=YZKJuebUHvphP+Bqdm9J5Xnwf62xGgtA3R0aV/pRfQSOIA0jd/1rZW0xsHArND6lQA
         bX7H+XdCA4eqF91Ig18e1gwW6DNUDREvpdg6yoV/qiexX3NCjQvNR53zaj0hal5kpP1e
         Gjf3GCUVyRGBCCycmj8pa9kY9ZX2NO+E6EzbFOLfoMAJUMYWCEE/5JLJlZMpSMTXA2da
         ClX0CWVN12WiZM+Tjc8kvf1DUPAwwOoZ4n2EAk8kqO4d/Ay8PveE4ham8FIT+W02gHD7
         zPNTOa6q70XUxBBUREzcD1aUijDunVwIDd4JEIosog5/E7W4NTjcHLpi61EitAw6K947
         96VA==
X-Forwarded-Encrypted: i=1; AJvYcCVAVWCRwTFyCybE36FPy3LStE5za66LcZ6cumVu9xra0QHDMPl22F0YcQBLUDvJmm4D3T4tg5uW4dw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyXWN/FAGytXEvL0QdlkdrGTq4Ew4mbnRybAk9a34fz8HRmyIgL
	IaEDLPMLv1xqdv3NZuFrcn7HJsg71fcS0/pe5Jg/w6tiv0sXzEvydLNqvKRLOQ==
X-Gm-Gg: ASbGncvEeE7BkouMmri+84/AKqKf/6pUKlM+t6VwJRuqrHzXcYdNUalGpYuIKyii/2X
	iwZADSQOtj0rMIEeF8LViKdQ5B6CmVuN8raOgacz0xZH8S+FiRk48kmb5FgPbqDAyIwEYM/SDOG
	1WDu0mScs/mWcd8sdsklzHNm8I2Yj1NFBznUSJoJTx86ItG46xWDGUwQ9n0jJvgeSkTYynqRD8u
	m2/3rD9DkyFcrEftzokB6jdnMdfP8XmqWDJL/oFdwVmqcapP4G0kcYPJRwAb/LgAt/j3ZI81GTS
	Eri1cNZ1mriQ8Q+VAGLTqRAofB6DWdB9NTlNp9qfHmHVKKXysuH7N/ll0iISgLAn
X-Google-Smtp-Source: AGHT+IGMF0oOg/WWjkkwCL2mmKhmU6bGYpiURlETPFlS+B8s9Ga0O9y4iOwSh+qxOLprOxov9mTd1Q==
X-Received: by 2002:a17:907:94d0:b0:ace:be7c:11da with SMTP id a640c23a62f3a-ad17b5dd7d5mr1554351366b.33.1746541970551;
        Tue, 06 May 2025 07:32:50 -0700 (PDT)
From: Ross Lagerwall 
To: Xen-devel ,
	xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 2/4] crypto: Add RSA support
Date: Tue,  6 May 2025 15:32:14 +0100
Message-ID: <20250506143218.1782603-3-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In preparation for adding support for livepatch signing, add support for
RSA crypto.

The RSA code is extracted from Nettle at tag nettle_3.2_release_20160128
(https://git.lysator.liu.se/nettle/nettle).

The MPI code is extracted from Linux at commit eef0df6a5953 (lib/mpi/*).

Signed-off-by: Ross Lagerwall 
---
 xen/common/Makefile   |    1 +
 xen/common/mpi.c      | 1724 +++++++++++++++++++++++++++++++++++++++++
 xen/crypto/Makefile   |    1 +
 xen/crypto/rsa.c      |  194 +++++
 xen/include/xen/mpi.h |   63 ++
 xen/include/xen/rsa.h |   72 ++
 6 files changed, 2055 insertions(+)
 create mode 100644 xen/common/mpi.c
 create mode 100644 xen/crypto/rsa.c
 create mode 100644 xen/include/xen/mpi.h
 create mode 100644 xen/include/xen/rsa.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f08730563f..ece6548bb072 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-y += memory.o
+obj-y += mpi.o
 obj-y += multicall.o
 obj-y += notifier.o
 obj-$(CONFIG_NUMA) += numa.o
diff --git a/xen/common/mpi.c b/xen/common/mpi.c
new file mode 100644
index 000000000000..e3e3ecd42283
--- /dev/null
+++ b/xen/common/mpi.c
@@ -0,0 +1,1724 @@
+/* mpi-pow.c  -  MPI functions
+ *	Copyright (C) 1994, 1996, 1998, 2000 Free Software Foundation, Inc.
+ *
+ * This file is part of GnuPG.
+ *
+ * GnuPG is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * GnuPG is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ *
+ * Note: This code is heavily based on the GNU MP Library.
+ *	 Actually it's the same code with only minor changes in the
+ *	 way the data is stored; this is to support the abstraction
+ *	 of an optional secure memory allocation which may be used
+ *	 to avoid revealing of sensitive data due to paging etc.
+ *	 The GNU MP Library itself is published under the LGPL;
+ *	 however I decided to publish this code under the plain GPL.
+ *
+ * mpi.c code extracted from linux @ eef0df6a5953, lib/mpi
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_EXTERN_MPI_BITS 16384
+
+/* Define it to a value which is good on most machines.
+ * tested 4, 16, 32 and 64, where 16 gave the best performance when
+ * checking a 768 and a 1024 bit ElGamal signature.
+ * (wk 22.12.97) */
+#define KARATSUBA_THRESHOLD 16
+
+typedef mpi_limb_t *mpi_ptr_t;	/* pointer to a limb */
+typedef int mpi_size_t;		/* (must be a signed type) */
+
+/* Copy N limbs from S to D.  */
+#define MPN_COPY(d, s, n) \
+	do {					\
+		mpi_size_t _i;			\
+		for (_i = 0; _i < (n); _i++)	\
+			(d)[_i] = (s)[_i];	\
+	} while (0)
+
+#define MPN_COPY_DECR(d, s, n) \
+	do {					\
+		mpi_size_t _i;			\
+		for (_i = (n)-1; _i >= 0; _i--) \
+			(d)[_i] = (s)[_i];	\
+	} while (0)
+
+/* Zero N limbs at D */
+#define MPN_ZERO(d, n) \
+	do {					\
+		int  _i;			\
+		for (_i = 0; _i < (n); _i++)	\
+			(d)[_i] = 0;		\
+	} while (0)
+
+#define MPN_NORMALIZE(d, n)  \
+	do {					\
+		while ((n) > 0) {		\
+			if ((d)[(n)-1])		\
+				break;		\
+			(n)--;			\
+		}				\
+	} while (0)
+
+#define MPN_MUL_N_RECURSE(prodp, up, vp, size, tspace)		\
+	do {							\
+		if ((size) < KARATSUBA_THRESHOLD)		\
+			mul_n_basecase(prodp, up, vp, size);	\
+		else						\
+			mul_n(prodp, up, vp, size, tspace);	\
+	} while (0);
+
+#define MPN_SQR_N_RECURSE(prodp, up, size, tspace)		\
+	do {							\
+		if ((size) < KARATSUBA_THRESHOLD)		\
+			mpih_sqr_n_basecase(prodp, up, size);	\
+		else						\
+			mpih_sqr_n(prodp, up, size, tspace);	\
+	} while (0);
+
+#define add_ssaaaa(sh, sl, ah, al, bh, bl) \
+do { \
+	mpi_limb_t __x; \
+	__x = (al) + (bl); \
+	(sh) = (ah) + (bh) + (__x < (al)); \
+	(sl) = __x; \
+} while (0)
+
+#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
+do { \
+	mpi_limb_t __x; \
+	__x = (al) - (bl); \
+	(sh) = (ah) - (bh) - (__x > (al)); \
+	(sl) = __x; \
+} while (0)
+
+#define __ll_B ((mpi_limb_t) 1 << (BITS_PER_MPI_LIMB / 2))
+#define __ll_lowpart(t) ((mpi_limb_t) (t) & (__ll_B - 1))
+#define __ll_highpart(t) ((mpi_limb_t) (t) >> (BITS_PER_MPI_LIMB / 2))
+
+#define umul_ppmm(w1, w0, u, v) \
+do { \
+	mpi_limb_t __x0, __x1, __x2, __x3; \
+	unsigned int __ul, __vl, __uh, __vh; \
+	mpi_limb_t __u = (u), __v = (v); \
+	\
+	__ul = __ll_lowpart(__u); \
+	__uh = __ll_highpart(__u); \
+	__vl = __ll_lowpart(__v); \
+	__vh = __ll_highpart(__v); \
+	\
+	__x0 = (mpi_limb_t) __ul * __vl; \
+	__x1 = (mpi_limb_t) __ul * __vh; \
+	__x2 = (mpi_limb_t) __uh * __vl; \
+	__x3 = (mpi_limb_t) __uh * __vh; \
+	\
+	__x1 += __ll_highpart(__x0);/* this can't give carry */ \
+	__x1 += __x2;		/* but this indeed can */ \
+	if (__x1 < __x2)		/* did we get it? */ \
+	__x3 += __ll_B;		/* yes, add it in the proper pos. */ \
+	\
+	(w1) = __x3 + __ll_highpart(__x1); \
+	(w0) = (__ll_lowpart(__x1) << BITS_PER_MPI_LIMB/2) + __ll_lowpart(__x0); \
+} while (0)
+
+#define udiv_qrnnd(q, r, n1, n0, d) \
+do { \
+	mpi_limb_t __d1, __d0, __q1, __q0, __r1, __r0, __m; \
+	__d1 = __ll_highpart(d); \
+	__d0 = __ll_lowpart(d); \
+	\
+	__r1 = (n1) % __d1; \
+	__q1 = (n1) / __d1; \
+	__m = (mpi_limb_t) __q1 * __d0; \
+	__r1 = __r1 * __ll_B | __ll_highpart(n0); \
+	if (__r1 < __m) { \
+		__q1--, __r1 += (d); \
+		if (__r1 >= (d)) /* i.e. we didn't get carry when adding to __r1 */ \
+		if (__r1 < __m) \
+			__q1--, __r1 += (d); \
+	} \
+	__r1 -= __m; \
+	\
+	__r0 = __r1 % __d1; \
+	__q0 = __r1 / __d1; \
+	__m = (mpi_limb_t) __q0 * __d0; \
+	__r0 = __r0 * __ll_B | __ll_lowpart(n0); \
+	if (__r0 < __m) { \
+		__q0--, __r0 += (d); \
+		if (__r0 >= (d)) \
+			if (__r0 < __m) \
+				__q0--, __r0 += (d); \
+	} \
+	__r0 -= __m; \
+	\
+	(q) = (mpi_limb_t) __q1 * __ll_B | __q0; \
+	(r) = __r0; \
+} while (0)
+
+struct karatsuba_ctx {
+	struct karatsuba_ctx *next;
+	mpi_ptr_t tspace;
+	mpi_size_t tspace_size;
+	mpi_ptr_t tp;
+	mpi_size_t tp_size;
+};
+
+static void mpi_normalize(MPI a);
+static mpi_limb_t mpihelp_submul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			    mpi_size_t s1_size, mpi_limb_t s2_limb);
+static mpi_limb_t mpihelp_divrem(mpi_ptr_t qp, mpi_size_t qextra_limbs,
+			  mpi_ptr_t np, mpi_size_t nsize,
+			  mpi_ptr_t dp, mpi_size_t dsize);
+static mpi_limb_t mpihelp_rshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize,
+			  unsigned cnt);
+static void mpi_assign_limb_space(MPI a, mpi_ptr_t ap, unsigned nlimbs);
+static mpi_ptr_t mpi_alloc_limb_space(unsigned nlimbs);
+static void mpi_free_limb_space(mpi_ptr_t a);
+static mpi_limb_t mpihelp_addmul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			    mpi_size_t s1_size, mpi_limb_t s2_limb);
+static int mpihelp_mul(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t usize,
+		mpi_ptr_t vp, mpi_size_t vsize, mpi_limb_t *_result);
+static mpi_limb_t mpihelp_lshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize,
+			  unsigned cnt);
+static int mpihelp_cmp(mpi_ptr_t op1_ptr, mpi_ptr_t op2_ptr, mpi_size_t size);
+static void mpih_sqr_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size,
+		mpi_ptr_t tspace);
+static mpi_limb_t mpihelp_add_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			 mpi_ptr_t s2_ptr, mpi_size_t size);
+static mpi_limb_t mpihelp_sub_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			 mpi_ptr_t s2_ptr, mpi_size_t size);
+static mpi_limb_t mpihelp_mul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			 mpi_size_t s1_size, mpi_limb_t s2_limb);
+static void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx *ctx);
+static void mpih_sqr_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size);
+static int mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,
+			       mpi_ptr_t up, mpi_size_t usize,
+			       mpi_ptr_t vp, mpi_size_t vsize,
+			       struct karatsuba_ctx *ctx);
+static int mpi_resize(MPI a, unsigned nlimbs);
+
+/**
+ * count_leading_zeros - Count the number of zeros from the MSB back
+ * @x: The value
+ *
+ * Count the number of leading zeros from the MSB going towards the LSB in @x.
+ *
+ * If the MSB of @x is set, the result is 0.
+ * If only the LSB of @x is set, then the result is BITS_PER_LONG-1.
+ * If @x is 0 then the result is BITS_PER_LONG.
+ */
+static inline int count_leading_zeros(unsigned long x)
+{
+	if (sizeof(x) == 4)
+		return BITS_PER_LONG - fls(x);
+	else
+		return BITS_PER_LONG - fls64(x);
+}
+
+static mpi_limb_t
+mpihelp_add_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t x;
+
+	x = *s1_ptr++;
+	s2_limb += x;
+	*res_ptr++ = s2_limb;
+	if (s2_limb < x) {	/* sum is less than the left operand: handle carry */
+		while (--s1_size) {
+			x = *s1_ptr++ + 1;	/* add carry */
+			*res_ptr++ = x;	/* and store */
+			if (x)	/* not 0 (no overflow): we can stop */
+				goto leave;
+		}
+		return 1;	/* return carry (size of s1 to small) */
+	}
+
+leave:
+	if (res_ptr != s1_ptr) {	/* not the same variable */
+		mpi_size_t i;	/* copy the rest */
+		for (i = 0; i < s1_size - 1; i++)
+			res_ptr[i] = s1_ptr[i];
+	}
+	return 0;		/* no carry */
+}
+
+static mpi_limb_t
+mpihelp_sub_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t x;
+
+	x = *s1_ptr++;
+	s2_limb = x - s2_limb;
+	*res_ptr++ = s2_limb;
+	if (s2_limb > x) {
+		while (--s1_size) {
+			x = *s1_ptr++;
+			*res_ptr++ = x - 1;
+			if (x)
+				goto leave;
+		}
+		return 1;
+	}
+
+leave:
+	if (res_ptr != s1_ptr) {
+		mpi_size_t i;
+		for (i = 0; i < s1_size - 1; i++)
+			res_ptr[i] = s1_ptr[i];
+	}
+	return 0;
+}
+
+static mpi_limb_t
+mpihelp_sub(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size,
+	    mpi_ptr_t s2_ptr, mpi_size_t s2_size)
+{
+	mpi_limb_t cy = 0;
+
+	if (s2_size)
+		cy = mpihelp_sub_n(res_ptr, s1_ptr, s2_ptr, s2_size);
+
+	if (s1_size - s2_size)
+		cy = mpihelp_sub_1(res_ptr + s2_size, s1_ptr + s2_size,
+				   s1_size - s2_size, cy);
+	return cy;
+}
+
+static mpi_ptr_t mpi_alloc_limb_space(unsigned nlimbs)
+{
+	size_t len = nlimbs * sizeof(mpi_limb_t);
+
+	if (!len)
+		return NULL;
+
+	return xmalloc_bytes(len);
+}
+
+static void mpi_free_limb_space(mpi_ptr_t a)
+{
+	if (!a)
+		return;
+
+	xfree(a);
+}
+
+/****************
+ * Resize the array of A to NLIMBS. the additional space is cleared
+ * (set to 0) [done by m_realloc()]
+ */
+static int mpi_resize(MPI a, unsigned nlimbs)
+{
+	void *p;
+
+	if (nlimbs <= a->alloced)
+		return 0;	/* no need to do it */
+
+	if (a->d) {
+		p = xmalloc_array(mpi_limb_t, nlimbs);
+		if (!p)
+			return -ENOMEM;
+		memcpy(p, a->d, a->alloced * sizeof(mpi_limb_t));
+		xfree(a->d);
+		a->d = p;
+	} else {
+		a->d = xzalloc_array(mpi_limb_t, nlimbs);
+		if (!a->d)
+			return -ENOMEM;
+	}
+	a->alloced = nlimbs;
+	return 0;
+}
+
+/****************
+ * RES = BASE ^ EXP mod MOD
+ */
+int mpi_powm(MPI res, MPI base, MPI exp, MPI mod)
+{
+	mpi_ptr_t mp_marker = NULL, bp_marker = NULL, ep_marker = NULL;
+	mpi_ptr_t xp_marker = NULL;
+	mpi_ptr_t tspace = NULL;
+	mpi_ptr_t rp, ep, mp, bp;
+	mpi_size_t esize, msize, bsize, rsize;
+	int msign, bsign, rsign;
+	mpi_size_t size;
+	int mod_shift_cnt;
+	int negative_result;
+	int assign_rp = 0;
+	mpi_size_t tsize = 0;	/* to avoid compiler warning */
+	/* fixme: we should check that the warning is void */
+	int rc = -ENOMEM;
+
+	esize = exp->nlimbs;
+	msize = mod->nlimbs;
+	size = 2 * msize;
+	msign = mod->sign;
+
+	rp = res->d;
+	ep = exp->d;
+
+	if (!msize)
+		return -EINVAL;
+
+	if (!esize) {
+		/* Exponent is zero, result is 1 mod MOD, i.e., 1 or 0
+		 * depending on if MOD equals 1.  */
+		rp[0] = 1;
+		res->nlimbs = (msize == 1 && mod->d[0] == 1) ? 0 : 1;
+		res->sign = 0;
+		goto leave;
+	}
+
+	/* Normalize MOD (i.e. make its most significant bit set) as required by
+	 * mpn_divrem.  This will make the intermediate values in the calculation
+	 * slightly larger, but the correct result is obtained after a final
+	 * reduction using the original MOD value.  */
+	mp = mp_marker = mpi_alloc_limb_space(msize);
+	if (!mp)
+		goto enomem;
+	mod_shift_cnt = count_leading_zeros(mod->d[msize - 1]);
+	if (mod_shift_cnt)
+		mpihelp_lshift(mp, mod->d, msize, mod_shift_cnt);
+	else
+		MPN_COPY(mp, mod->d, msize);
+
+	bsize = base->nlimbs;
+	bsign = base->sign;
+	if (bsize > msize) {	/* The base is larger than the module. Reduce it. */
+		/* Allocate (BSIZE + 1) with space for remainder and quotient.
+		 * (The quotient is (bsize - msize + 1) limbs.)  */
+		bp = bp_marker = mpi_alloc_limb_space(bsize + 1);
+		if (!bp)
+			goto enomem;
+		MPN_COPY(bp, base->d, bsize);
+		/* We don't care about the quotient, store it above the remainder,
+		 * at BP + MSIZE.  */
+		mpihelp_divrem(bp + msize, 0, bp, bsize, mp, msize);
+		bsize = msize;
+		/* Canonicalize the base, since we are going to multiply with it
+		 * quite a few times.  */
+		MPN_NORMALIZE(bp, bsize);
+	} else
+		bp = base->d;
+
+	if (!bsize) {
+		res->nlimbs = 0;
+		res->sign = 0;
+		goto leave;
+	}
+
+	if (res->alloced < size) {
+		/* We have to allocate more space for RES.  If any of the input
+		 * parameters are identical to RES, defer deallocation of the old
+		 * space.  */
+		if (rp == ep || rp == mp || rp == bp) {
+			rp = mpi_alloc_limb_space(size);
+			if (!rp)
+				goto enomem;
+			assign_rp = 1;
+		} else {
+			if (mpi_resize(res, size) < 0)
+				goto enomem;
+			rp = res->d;
+		}
+	} else {		/* Make BASE, EXP and MOD not overlap with RES.  */
+		if (rp == bp) {
+			/* RES and BASE are identical.  Allocate temp. space for BASE.  */
+			BUG_ON(bp_marker);
+			bp = bp_marker = mpi_alloc_limb_space(bsize);
+			if (!bp)
+				goto enomem;
+			MPN_COPY(bp, rp, bsize);
+		}
+		if (rp == ep) {
+			/* RES and EXP are identical.  Allocate temp. space for EXP.  */
+			ep = ep_marker = mpi_alloc_limb_space(esize);
+			if (!ep)
+				goto enomem;
+			MPN_COPY(ep, rp, esize);
+		}
+		if (rp == mp) {
+			/* RES and MOD are identical.  Allocate temporary space for MOD. */
+			BUG_ON(mp_marker);
+			mp = mp_marker = mpi_alloc_limb_space(msize);
+			if (!mp)
+				goto enomem;
+			MPN_COPY(mp, rp, msize);
+		}
+	}
+
+	MPN_COPY(rp, bp, bsize);
+	rsize = bsize;
+	rsign = bsign;
+
+	{
+		mpi_size_t i;
+		mpi_ptr_t xp;
+		int c;
+		mpi_limb_t e;
+		mpi_limb_t carry_limb;
+		struct karatsuba_ctx karactx;
+
+		xp = xp_marker = mpi_alloc_limb_space(2 * (msize + 1));
+		if (!xp)
+			goto enomem;
+
+		memset(&karactx, 0, sizeof karactx);
+		negative_result = (ep[0] & 1) && base->sign;
+
+		i = esize - 1;
+		e = ep[i];
+		c = count_leading_zeros(e);
+		e = (e << c) << 1;	/* shift the exp bits to the left, lose msb */
+		c = BITS_PER_MPI_LIMB - 1 - c;
+
+		/* Main loop.
+		 *
+		 * Make the result be pointed to alternately by XP and RP.  This
+		 * helps us avoid block copying, which would otherwise be necessary
+		 * with the overlap restrictions of mpihelp_divmod. With 50% probability
+		 * the result after this loop will be in the area originally pointed
+		 * by RP (==RES->d), and with 50% probability in the area originally
+		 * pointed to by XP.
+		 */
+
+		for (;;) {
+			while (c) {
+				mpi_ptr_t tp;
+				mpi_size_t xsize;
+
+				/*if (mpihelp_mul_n(xp, rp, rp, rsize) < 0) goto enomem */
+				if (rsize < KARATSUBA_THRESHOLD)
+					mpih_sqr_n_basecase(xp, rp, rsize);
+				else {
+					if (!tspace) {
+						tsize = 2 * rsize;
+						tspace =
+						    mpi_alloc_limb_space(tsize);
+						if (!tspace)
+							goto enomem;
+					} else if (tsize < (2 * rsize)) {
+						mpi_free_limb_space(tspace);
+						tsize = 2 * rsize;
+						tspace =
+						    mpi_alloc_limb_space(tsize);
+						if (!tspace)
+							goto enomem;
+					}
+					mpih_sqr_n(xp, rp, rsize, tspace);
+				}
+
+				xsize = 2 * rsize;
+				if (xsize > msize) {
+					mpihelp_divrem(xp + msize, 0, xp, xsize,
+						       mp, msize);
+					xsize = msize;
+				}
+
+				tp = rp;
+				rp = xp;
+				xp = tp;
+				rsize = xsize;
+
+				if ((mpi_limb_signed_t) e < 0) {
+					/*mpihelp_mul( xp, rp, rsize, bp, bsize ); */
+					if (bsize < KARATSUBA_THRESHOLD) {
+						mpi_limb_t tmp;
+						if (mpihelp_mul
+						    (xp, rp, rsize, bp, bsize,
+						     &tmp) < 0)
+							goto enomem;
+					} else {
+						if (mpihelp_mul_karatsuba_case
+						    (xp, rp, rsize, bp, bsize,
+						     &karactx) < 0)
+							goto enomem;
+					}
+
+					xsize = rsize + bsize;
+					if (xsize > msize) {
+						mpihelp_divrem(xp + msize, 0,
+							       xp, xsize, mp,
+							       msize);
+						xsize = msize;
+					}
+
+					tp = rp;
+					rp = xp;
+					xp = tp;
+					rsize = xsize;
+				}
+				e <<= 1;
+				c--;
+			}
+
+			i--;
+			if (i < 0)
+				break;
+			e = ep[i];
+			c = BITS_PER_MPI_LIMB;
+		}
+
+		/* We shifted MOD, the modulo reduction argument, left MOD_SHIFT_CNT
+		 * steps.  Adjust the result by reducing it with the original MOD.
+		 *
+		 * Also make sure the result is put in RES->d (where it already
+		 * might be, see above).
+		 */
+		if (mod_shift_cnt) {
+			carry_limb =
+			    mpihelp_lshift(res->d, rp, rsize, mod_shift_cnt);
+			rp = res->d;
+			if (carry_limb) {
+				rp[rsize] = carry_limb;
+				rsize++;
+			}
+		} else {
+			MPN_COPY(res->d, rp, rsize);
+			rp = res->d;
+		}
+
+		if (rsize >= msize) {
+			mpihelp_divrem(rp + msize, 0, rp, rsize, mp, msize);
+			rsize = msize;
+		}
+
+		/* Remove any leading zero words from the result.  */
+		if (mod_shift_cnt)
+			mpihelp_rshift(rp, rp, rsize, mod_shift_cnt);
+		MPN_NORMALIZE(rp, rsize);
+
+		mpihelp_release_karatsuba_ctx(&karactx);
+	}
+
+	if (negative_result && rsize) {
+		if (mod_shift_cnt)
+			mpihelp_rshift(mp, mp, msize, mod_shift_cnt);
+		mpihelp_sub(rp, mp, msize, rp, rsize);
+		rsize = msize;
+		rsign = msign;
+		MPN_NORMALIZE(rp, rsize);
+	}
+	res->nlimbs = rsize;
+	res->sign = rsign;
+
+leave:
+	rc = 0;
+enomem:
+	if (assign_rp)
+		mpi_assign_limb_space(res, rp, size);
+	if (mp_marker)
+		mpi_free_limb_space(mp_marker);
+	if (bp_marker)
+		mpi_free_limb_space(bp_marker);
+	if (ep_marker)
+		mpi_free_limb_space(ep_marker);
+	if (xp_marker)
+		mpi_free_limb_space(xp_marker);
+	if (tspace)
+		mpi_free_limb_space(tspace);
+	return rc;
+}
+
+/* Multiply the natural numbers u (pointed to by UP) and v (pointed to by VP),
+ * both with SIZE limbs, and store the result at PRODP.  2 * SIZE limbs are
+ * always stored.  Return the most significant limb.
+ *
+ * Argument constraints:
+ * 1. PRODP != UP and PRODP != VP, i.e. the destination
+ *    must be distinct from the multiplier and the multiplicand.
+ *
+ *
+ * Handle simple cases with traditional multiplication.
+ *
+ * This is the most critical code of multiplication.  All multiplies rely
+ * on this, both small and huge.  Small ones arrive here immediately.  Huge
+ * ones arrive here as this is the base case for Karatsuba's recursive
+ * algorithm below.
+ */
+
+static mpi_limb_t
+mul_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_ptr_t vp, mpi_size_t size)
+{
+	mpi_size_t i;
+	mpi_limb_t cy;
+	mpi_limb_t v_limb;
+
+	/* Multiply by the first limb in V separately, as the result can be
+	 * stored (not added) to PROD.  We also avoid a loop for zeroing.  */
+	v_limb = vp[0];
+	if (v_limb <= 1) {
+		if (v_limb == 1)
+			MPN_COPY(prodp, up, size);
+		else
+			MPN_ZERO(prodp, size);
+		cy = 0;
+	} else
+		cy = mpihelp_mul_1(prodp, up, size, v_limb);
+
+	prodp[size] = cy;
+	prodp++;
+
+	/* For each iteration in the outer loop, multiply one limb from
+	 * U with one limb from V, and add it to PROD.  */
+	for (i = 1; i < size; i++) {
+		v_limb = vp[i];
+		if (v_limb <= 1) {
+			cy = 0;
+			if (v_limb == 1)
+				cy = mpihelp_add_n(prodp, prodp, up, size);
+		} else
+			cy = mpihelp_addmul_1(prodp, up, size, v_limb);
+
+		prodp[size] = cy;
+		prodp++;
+	}
+
+	return cy;
+}
+
+static void
+mul_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_ptr_t vp,
+		mpi_size_t size, mpi_ptr_t tspace)
+{
+	if (size & 1) {
+		/* The size is odd, and the code below doesn't handle that.
+		 * Multiply the least significant (size - 1) limbs with a recursive
+		 * call, and handle the most significant limb of S1 and S2
+		 * separately.
+		 * A slightly faster way to do this would be to make the Karatsuba
+		 * code below behave as if the size were even, and let it check for
+		 * odd size in the end.  I.e., in essence move this code to the end.
+		 * Doing so would save us a recursive call, and potentially make the
+		 * stack grow a lot less.
+		 */
+		mpi_size_t esize = size - 1;	/* even size */
+		mpi_limb_t cy_limb;
+
+		MPN_MUL_N_RECURSE(prodp, up, vp, esize, tspace);
+		cy_limb = mpihelp_addmul_1(prodp + esize, up, esize, vp[esize]);
+		prodp[esize + esize] = cy_limb;
+		cy_limb = mpihelp_addmul_1(prodp + esize, vp, size, up[esize]);
+		prodp[esize + size] = cy_limb;
+	} else {
+		/* Anatolij Alekseevich Karatsuba's divide-and-conquer algorithm.
+		 *
+		 * Split U in two pieces, U1 and U0, such that
+		 * U = U0 + U1*(B**n),
+		 * and V in V1 and V0, such that
+		 * V = V0 + V1*(B**n).
+		 *
+		 * UV is then computed recursively using the identity
+		 *
+		 *        2n   n          n                     n
+		 * UV = (B  + B )U V  +  B (U -U )(V -V )  +  (B + 1)U V
+		 *                1 1        1  0   0  1              0 0
+		 *
+		 * Where B = 2**BITS_PER_MP_LIMB.
+		 */
+		mpi_size_t hsize = size >> 1;
+		mpi_limb_t cy;
+		int negflg;
+
+		/* Product H.      ________________  ________________
+		 *                |_____U1 x V1____||____U0 x V0_____|
+		 * Put result in upper part of PROD and pass low part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_MUL_N_RECURSE(prodp + size, up + hsize, vp + hsize, hsize,
+				  tspace);
+
+		/* Product M.      ________________
+		 *                |_(U1-U0)(V0-V1)_|
+		 */
+		if (mpihelp_cmp(up + hsize, up, hsize) >= 0) {
+			mpihelp_sub_n(prodp, up + hsize, up, hsize);
+			negflg = 0;
+		} else {
+			mpihelp_sub_n(prodp, up, up + hsize, hsize);
+			negflg = 1;
+		}
+		if (mpihelp_cmp(vp + hsize, vp, hsize) >= 0) {
+			mpihelp_sub_n(prodp + hsize, vp + hsize, vp, hsize);
+			negflg ^= 1;
+		} else {
+			mpihelp_sub_n(prodp + hsize, vp, vp + hsize, hsize);
+			/* No change of NEGFLG.  */
+		}
+		/* Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_MUL_N_RECURSE(tspace, prodp, prodp + hsize, hsize,
+				  tspace + size);
+
+		/* Add/copy product H. */
+		MPN_COPY(prodp + hsize, prodp + size, hsize);
+		cy = mpihelp_add_n(prodp + size, prodp + size,
+				   prodp + size + hsize, hsize);
+
+		/* Add product M (if NEGFLG M is a negative number) */
+		if (negflg)
+			cy -=
+			    mpihelp_sub_n(prodp + hsize, prodp + hsize, tspace,
+					  size);
+		else
+			cy +=
+			    mpihelp_add_n(prodp + hsize, prodp + hsize, tspace,
+					  size);
+
+		/* Product L.      ________________  ________________
+		 *                |________________||____U0 x V0_____|
+		 * Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_MUL_N_RECURSE(tspace, up, vp, hsize, tspace + size);
+
+		/* Add/copy Product L (twice) */
+
+		cy += mpihelp_add_n(prodp + hsize, prodp + hsize, tspace, size);
+		if (cy)
+			mpihelp_add_1(prodp + hsize + size,
+				      prodp + hsize + size, hsize, cy);
+
+		MPN_COPY(prodp, tspace, hsize);
+		cy = mpihelp_add_n(prodp + hsize, prodp + hsize, tspace + hsize,
+				   hsize);
+		if (cy)
+			mpihelp_add_1(prodp + size, prodp + size, size, 1);
+	}
+}
+
+static void mpih_sqr_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size)
+{
+	mpi_size_t i;
+	mpi_limb_t cy_limb;
+	mpi_limb_t v_limb;
+
+	/* Multiply by the first limb in V separately, as the result can be
+	 * stored (not added) to PROD.  We also avoid a loop for zeroing.  */
+	v_limb = up[0];
+	if (v_limb <= 1) {
+		if (v_limb == 1)
+			MPN_COPY(prodp, up, size);
+		else
+			MPN_ZERO(prodp, size);
+		cy_limb = 0;
+	} else
+		cy_limb = mpihelp_mul_1(prodp, up, size, v_limb);
+
+	prodp[size] = cy_limb;
+	prodp++;
+
+	/* For each iteration in the outer loop, multiply one limb from
+	 * U with one limb from V, and add it to PROD.  */
+	for (i = 1; i < size; i++) {
+		v_limb = up[i];
+		if (v_limb <= 1) {
+			cy_limb = 0;
+			if (v_limb == 1)
+				cy_limb = mpihelp_add_n(prodp, prodp, up, size);
+		} else
+			cy_limb = mpihelp_addmul_1(prodp, up, size, v_limb);
+
+		prodp[size] = cy_limb;
+		prodp++;
+	}
+}
+
+static void
+mpih_sqr_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size, mpi_ptr_t tspace)
+{
+	if (size & 1) {
+		/* The size is odd, and the code below doesn't handle that.
+		 * Multiply the least significant (size - 1) limbs with a recursive
+		 * call, and handle the most significant limb of S1 and S2
+		 * separately.
+		 * A slightly faster way to do this would be to make the Karatsuba
+		 * code below behave as if the size were even, and let it check for
+		 * odd size in the end.  I.e., in essence move this code to the end.
+		 * Doing so would save us a recursive call, and potentially make the
+		 * stack grow a lot less.
+		 */
+		mpi_size_t esize = size - 1;	/* even size */
+		mpi_limb_t cy_limb;
+
+		MPN_SQR_N_RECURSE(prodp, up, esize, tspace);
+		cy_limb = mpihelp_addmul_1(prodp + esize, up, esize, up[esize]);
+		prodp[esize + esize] = cy_limb;
+		cy_limb = mpihelp_addmul_1(prodp + esize, up, size, up[esize]);
+
+		prodp[esize + size] = cy_limb;
+	} else {
+		mpi_size_t hsize = size >> 1;
+		mpi_limb_t cy;
+
+		/* Product H.      ________________  ________________
+		 *                |_____U1 x U1____||____U0 x U0_____|
+		 * Put result in upper part of PROD and pass low part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_SQR_N_RECURSE(prodp + size, up + hsize, hsize, tspace);
+
+		/* Product M.      ________________
+		 *                |_(U1-U0)(U0-U1)_|
+		 */
+		if (mpihelp_cmp(up + hsize, up, hsize) >= 0)
+			mpihelp_sub_n(prodp, up + hsize, up, hsize);
+		else
+			mpihelp_sub_n(prodp, up, up + hsize, hsize);
+
+		/* Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.  */
+		MPN_SQR_N_RECURSE(tspace, prodp, hsize, tspace + size);
+
+		/* Add/copy product H  */
+		MPN_COPY(prodp + hsize, prodp + size, hsize);
+		cy = mpihelp_add_n(prodp + size, prodp + size,
+				   prodp + size + hsize, hsize);
+
+		/* Add product M (if NEGFLG M is a negative number).  */
+		cy -= mpihelp_sub_n(prodp + hsize, prodp + hsize, tspace, size);
+
+		/* Product L.      ________________  ________________
+		 *                |________________||____U0 x U0_____|
+		 * Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.  */
+		MPN_SQR_N_RECURSE(tspace, up, hsize, tspace + size);
+
+		/* Add/copy Product L (twice).  */
+		cy += mpihelp_add_n(prodp + hsize, prodp + hsize, tspace, size);
+		if (cy)
+			mpihelp_add_1(prodp + hsize + size,
+				      prodp + hsize + size, hsize, cy);
+
+		MPN_COPY(prodp, tspace, hsize);
+		cy = mpihelp_add_n(prodp + hsize, prodp + hsize, tspace + hsize,
+				   hsize);
+		if (cy)
+			mpihelp_add_1(prodp + size, prodp + size, size, 1);
+	}
+}
+
+static int
+mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,
+			   mpi_ptr_t up, mpi_size_t usize,
+			   mpi_ptr_t vp, mpi_size_t vsize,
+			   struct karatsuba_ctx *ctx)
+{
+	mpi_limb_t cy;
+
+	if (!ctx->tspace || ctx->tspace_size < vsize) {
+		if (ctx->tspace)
+			mpi_free_limb_space(ctx->tspace);
+		ctx->tspace = mpi_alloc_limb_space(2 * vsize);
+		if (!ctx->tspace)
+			return -ENOMEM;
+		ctx->tspace_size = vsize;
+	}
+
+	MPN_MUL_N_RECURSE(prodp, up, vp, vsize, ctx->tspace);
+
+	prodp += vsize;
+	up += vsize;
+	usize -= vsize;
+	if (usize >= vsize) {
+		if (!ctx->tp || ctx->tp_size < vsize) {
+			if (ctx->tp)
+				mpi_free_limb_space(ctx->tp);
+			ctx->tp = mpi_alloc_limb_space(2 * vsize);
+			if (!ctx->tp) {
+				if (ctx->tspace)
+					mpi_free_limb_space(ctx->tspace);
+				ctx->tspace = NULL;
+				return -ENOMEM;
+			}
+			ctx->tp_size = vsize;
+		}
+
+		do {
+			MPN_MUL_N_RECURSE(ctx->tp, up, vp, vsize, ctx->tspace);
+			cy = mpihelp_add_n(prodp, prodp, ctx->tp, vsize);
+			mpihelp_add_1(prodp + vsize, ctx->tp + vsize, vsize,
+				      cy);
+			prodp += vsize;
+			up += vsize;
+			usize -= vsize;
+		} while (usize >= vsize);
+	}
+
+	if (usize) {
+		if (usize < KARATSUBA_THRESHOLD) {
+			mpi_limb_t tmp;
+			if (mpihelp_mul(ctx->tspace, vp, vsize, up, usize, &tmp)
+			    < 0)
+				return -ENOMEM;
+		} else {
+			if (!ctx->next) {
+				ctx->next = xzalloc(struct karatsuba_ctx);
+				if (!ctx->next)
+					return -ENOMEM;
+			}
+			if (mpihelp_mul_karatsuba_case(ctx->tspace,
+						       vp, vsize,
+						       up, usize,
+						       ctx->next) < 0)
+				return -ENOMEM;
+		}
+
+		cy = mpihelp_add_n(prodp, prodp, ctx->tspace, vsize);
+		mpihelp_add_1(prodp + vsize, ctx->tspace + vsize, usize, cy);
+	}
+
+	return 0;
+}
+
+static void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx *ctx)
+{
+	struct karatsuba_ctx *ctx2;
+
+	if (ctx->tp)
+		mpi_free_limb_space(ctx->tp);
+	if (ctx->tspace)
+		mpi_free_limb_space(ctx->tspace);
+	for (ctx = ctx->next; ctx; ctx = ctx2) {
+		ctx2 = ctx->next;
+		if (ctx->tp)
+			mpi_free_limb_space(ctx->tp);
+		if (ctx->tspace)
+			mpi_free_limb_space(ctx->tspace);
+		xfree(ctx);
+	}
+}
+
+/* Multiply the natural numbers u (pointed to by UP, with USIZE limbs)
+ * and v (pointed to by VP, with VSIZE limbs), and store the result at
+ * PRODP.  USIZE + VSIZE limbs are always stored, but if the input
+ * operands are normalized.  Return the most significant limb of the
+ * result.
+ *
+ * NOTE: The space pointed to by PRODP is overwritten before finished
+ * with U and V, so overlap is an error.
+ *
+ * Argument constraints:
+ * 1. USIZE >= VSIZE.
+ * 2. PRODP != UP and PRODP != VP, i.e. the destination
+ *    must be distinct from the multiplier and the multiplicand.
+ */
+
+static int
+mpihelp_mul(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t usize,
+	    mpi_ptr_t vp, mpi_size_t vsize, mpi_limb_t *_result)
+{
+	mpi_ptr_t prod_endp = prodp + usize + vsize - 1;
+	mpi_limb_t cy;
+	struct karatsuba_ctx ctx;
+
+	if (vsize < KARATSUBA_THRESHOLD) {
+		mpi_size_t i;
+		mpi_limb_t v_limb;
+
+		if (!vsize) {
+			*_result = 0;
+			return 0;
+		}
+
+		/* Multiply by the first limb in V separately, as the result can be
+		 * stored (not added) to PROD.  We also avoid a loop for zeroing.  */
+		v_limb = vp[0];
+		if (v_limb <= 1) {
+			if (v_limb == 1)
+				MPN_COPY(prodp, up, usize);
+			else
+				MPN_ZERO(prodp, usize);
+			cy = 0;
+		} else
+			cy = mpihelp_mul_1(prodp, up, usize, v_limb);
+
+		prodp[usize] = cy;
+		prodp++;
+
+		/* For each iteration in the outer loop, multiply one limb from
+		 * U with one limb from V, and add it to PROD.  */
+		for (i = 1; i < vsize; i++) {
+			v_limb = vp[i];
+			if (v_limb <= 1) {
+				cy = 0;
+				if (v_limb == 1)
+					cy = mpihelp_add_n(prodp, prodp, up,
+							   usize);
+			} else
+				cy = mpihelp_addmul_1(prodp, up, usize, v_limb);
+
+			prodp[usize] = cy;
+			prodp++;
+		}
+
+		*_result = cy;
+		return 0;
+	}
+
+	memset(&ctx, 0, sizeof ctx);
+	if (mpihelp_mul_karatsuba_case(prodp, up, usize, vp, vsize, &ctx) < 0)
+		return -ENOMEM;
+	mpihelp_release_karatsuba_ctx(&ctx);
+	*_result = *prod_endp;
+	return 0;
+}
+
+static mpi_limb_t
+mpihelp_mul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size,
+	      mpi_limb_t s2_limb)
+{
+	mpi_limb_t cy_limb;
+	mpi_size_t j;
+	mpi_limb_t prod_high, prod_low;
+
+	/* The loop counter and index J goes from -S1_SIZE to -1.  This way
+	 * the loop becomes faster.  */
+	j = -s1_size;
+
+	/* Offset the base pointers to compensate for the negative indices.  */
+	s1_ptr -= j;
+	res_ptr -= j;
+
+	cy_limb = 0;
+	do {
+		umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
+		prod_low += cy_limb;
+		cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high;
+		res_ptr[j] = prod_low;
+	} while (++j);
+
+	return cy_limb;
+}
+
+static mpi_limb_t
+mpihelp_add_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_ptr_t s2_ptr, mpi_size_t size)
+{
+	mpi_limb_t x, y, cy;
+	mpi_size_t j;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	   the loop becomes faster.  */
+	j = -size;
+
+	/* Offset the base pointers to compensate for the negative indices. */
+	s1_ptr -= j;
+	s2_ptr -= j;
+	res_ptr -= j;
+
+	cy = 0;
+	do {
+		y = s2_ptr[j];
+		x = s1_ptr[j];
+		y += cy;	/* add previous carry to one addend */
+		cy = y < cy;	/* get out carry from that addition */
+		y += x;		/* add other addend */
+		cy += y < x;	/* get out carry from that add, combine */
+		res_ptr[j] = y;
+	} while (++j);
+
+	return cy;
+}
+
+/* Shift U (pointed to by UP and USIZE digits long) CNT bits to the left
+ * and store the USIZE least significant digits of the result at WP.
+ * Return the bits shifted out from the most significant digit.
+ *
+ * Argument constraints:
+ * 1. 0 < CNT < BITS_PER_MP_LIMB
+ * 2. If the result is to be written over the input, WP must be >= UP.
+ */
+
+static mpi_limb_t
+mpihelp_lshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize, unsigned int cnt)
+{
+	mpi_limb_t high_limb, low_limb;
+	unsigned sh_1, sh_2;
+	mpi_size_t i;
+	mpi_limb_t retval;
+
+	sh_1 = cnt;
+	wp += 1;
+	sh_2 = BITS_PER_MPI_LIMB - sh_1;
+	i = usize - 1;
+	low_limb = up[i];
+	retval = low_limb >> sh_2;
+	high_limb = low_limb;
+	while (--i >= 0) {
+		low_limb = up[i];
+		wp[i] = (high_limb << sh_1) | (low_limb >> sh_2);
+		high_limb = low_limb;
+	}
+	wp[i] = high_limb << sh_1;
+
+	return retval;
+}
+
+static mpi_limb_t
+mpihelp_addmul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+		 mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t cy_limb;
+	mpi_size_t j;
+	mpi_limb_t prod_high, prod_low;
+	mpi_limb_t x;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	 * the loop becomes faster.  */
+	j = -s1_size;
+	res_ptr -= j;
+	s1_ptr -= j;
+
+	cy_limb = 0;
+	do {
+		umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
+
+		prod_low += cy_limb;
+		cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high;
+
+		x = res_ptr[j];
+		prod_low = x + prod_low;
+		cy_limb += prod_low < x ? 1 : 0;
+		res_ptr[j] = prod_low;
+	} while (++j);
+	return cy_limb;
+}
+
+static mpi_limb_t
+mpihelp_sub_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_ptr_t s2_ptr, mpi_size_t size)
+{
+	mpi_limb_t x, y, cy;
+	mpi_size_t j;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	   the loop becomes faster.  */
+	j = -size;
+
+	/* Offset the base pointers to compensate for the negative indices.  */
+	s1_ptr -= j;
+	s2_ptr -= j;
+	res_ptr -= j;
+
+	cy = 0;
+	do {
+		y = s2_ptr[j];
+		x = s1_ptr[j];
+		y += cy;	/* add previous carry to subtrahend */
+		cy = y < cy;	/* get out carry from that addition */
+		y = x - y;	/* main subtract */
+		cy += y > x;	/* get out carry from the subtract, combine */
+		res_ptr[j] = y;
+	} while (++j);
+
+	return cy;
+}
+
+/****************
+ * Compare OP1_PTR/OP1_SIZE with OP2_PTR/OP2_SIZE.
+ * There are no restrictions on the relative sizes of
+ * the two arguments.
+ * Return 1 if OP1 > OP2, 0 if they are equal, and -1 if OP1 < OP2.
+ */
+static int mpihelp_cmp(mpi_ptr_t op1_ptr, mpi_ptr_t op2_ptr, mpi_size_t size)
+{
+	mpi_size_t i;
+	mpi_limb_t op1_word, op2_word;
+
+	for (i = size - 1; i >= 0; i--) {
+		op1_word = op1_ptr[i];
+		op2_word = op2_ptr[i];
+		if (op1_word != op2_word)
+			goto diff;
+	}
+	return 0;
+
+diff:
+	/* This can *not* be simplified to
+	 *   op2_word - op2_word
+	 * since that expression might give signed overflow.  */
+	return (op1_word > op2_word) ? 1 : -1;
+}
+
+static void mpi_assign_limb_space(MPI a, mpi_ptr_t ap, unsigned nlimbs)
+{
+	mpi_free_limb_space(a->d);
+	a->d = ap;
+	a->alloced = nlimbs;
+}
+
+/* Shift U (pointed to by UP and USIZE limbs long) CNT bits to the right
+ * and store the USIZE least significant limbs of the result at WP.
+ * The bits shifted out to the right are returned.
+ *
+ * Argument constraints:
+ * 1. 0 < CNT < BITS_PER_MP_LIMB
+ * 2. If the result is to be written over the input, WP must be <= UP.
+ */
+
+static mpi_limb_t
+mpihelp_rshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize, unsigned cnt)
+{
+	mpi_limb_t high_limb, low_limb;
+	unsigned sh_1, sh_2;
+	mpi_size_t i;
+	mpi_limb_t retval;
+
+	sh_1 = cnt;
+	wp -= 1;
+	sh_2 = BITS_PER_MPI_LIMB - sh_1;
+	high_limb = up[0];
+	retval = high_limb << sh_2;
+	low_limb = high_limb;
+	for (i = 1; i < usize; i++) {
+		high_limb = up[i];
+		wp[i] = (low_limb >> sh_1) | (high_limb << sh_2);
+		low_limb = high_limb;
+	}
+	wp[i] = low_limb >> sh_1;
+
+	return retval;
+}
+
+/* Divide num (NP/NSIZE) by den (DP/DSIZE) and write
+ * the NSIZE-DSIZE least significant quotient limbs at QP
+ * and the DSIZE long remainder at NP.	If QEXTRA_LIMBS is
+ * non-zero, generate that many fraction bits and append them after the
+ * other quotient limbs.
+ * Return the most significant limb of the quotient, this is always 0 or 1.
+ *
+ * Preconditions:
+ * 0. NSIZE >= DSIZE.
+ * 1. The most significant bit of the divisor must be set.
+ * 2. QP must either not overlap with the input operands at all, or
+ *    QP + DSIZE >= NP must hold true.	(This means that it's
+ *    possible to put the quotient in the high part of NUM, right after the
+ *    remainder in NUM.
+ * 3. NSIZE >= DSIZE, even if QEXTRA_LIMBS is non-zero.
+ */
+
+static mpi_limb_t
+mpihelp_divrem(mpi_ptr_t qp, mpi_size_t qextra_limbs,
+	       mpi_ptr_t np, mpi_size_t nsize, mpi_ptr_t dp, mpi_size_t dsize)
+{
+	mpi_limb_t most_significant_q_limb = 0;
+
+	switch (dsize) {
+	case 0:
+		/* We are asked to divide by zero, so go ahead and do it!  (To make
+		   the compiler not remove this statement, return the value.)  */
+		/*
+		 * existing clients of this function have been modified
+		 * not to call it with dsize == 0, so this should not happen
+		 */
+		return 1 / dsize;
+
+	case 1:
+		{
+			mpi_size_t i;
+			mpi_limb_t n1;
+			mpi_limb_t d;
+
+			d = dp[0];
+			n1 = np[nsize - 1];
+
+			if (n1 >= d) {
+				n1 -= d;
+				most_significant_q_limb = 1;
+			}
+
+			qp += qextra_limbs;
+			for (i = nsize - 2; i >= 0; i--)
+				udiv_qrnnd(qp[i], n1, n1, np[i], d);
+			qp -= qextra_limbs;
+
+			for (i = qextra_limbs - 1; i >= 0; i--)
+				udiv_qrnnd(qp[i], n1, n1, 0, d);
+
+			np[0] = n1;
+		}
+		break;
+
+	case 2:
+		{
+			mpi_size_t i;
+			mpi_limb_t n1, n0, n2;
+			mpi_limb_t d1, d0;
+
+			np += nsize - 2;
+			d1 = dp[1];
+			d0 = dp[0];
+			n1 = np[1];
+			n0 = np[0];
+
+			if (n1 >= d1 && (n1 > d1 || n0 >= d0)) {
+				sub_ddmmss(n1, n0, n1, n0, d1, d0);
+				most_significant_q_limb = 1;
+			}
+
+			for (i = qextra_limbs + nsize - 2 - 1; i >= 0; i--) {
+				mpi_limb_t q;
+				mpi_limb_t r;
+
+				if (i >= qextra_limbs)
+					np--;
+				else
+					np[0] = 0;
+
+				if (n1 == d1) {
+					/* Q should be either 111..111 or 111..110.  Need special
+					 * treatment of this rare case as normal division would
+					 * give overflow.  */
+					q = ~(mpi_limb_t) 0;
+
+					r = n0 + d1;
+					if (r < d1) {	/* Carry in the addition? */
+						add_ssaaaa(n1, n0, r - d0,
+							   np[0], 0, d0);
+						qp[i] = q;
+						continue;
+					}
+					n1 = d0 - (d0 != 0 ? 1 : 0);
+					n0 = -d0;
+				} else {
+					udiv_qrnnd(q, r, n1, n0, d1);
+					umul_ppmm(n1, n0, d0, q);
+				}
+
+				n2 = np[0];
+q_test:
+				if (n1 > r || (n1 == r && n0 > n2)) {
+					/* The estimated Q was too large.  */
+					q--;
+					sub_ddmmss(n1, n0, n1, n0, 0, d0);
+					r += d1;
+					if (r >= d1)	/* If not carry, test Q again.  */
+						goto q_test;
+				}
+
+				qp[i] = q;
+				sub_ddmmss(n1, n0, r, n2, n1, n0);
+			}
+			np[1] = n1;
+			np[0] = n0;
+		}
+		break;
+
+	default:
+		{
+			mpi_size_t i;
+			mpi_limb_t dX, d1, n0;
+
+			np += nsize - dsize;
+			dX = dp[dsize - 1];
+			d1 = dp[dsize - 2];
+			n0 = np[dsize - 1];
+
+			if (n0 >= dX) {
+				if (n0 > dX
+				    || mpihelp_cmp(np, dp, dsize - 1) >= 0) {
+					mpihelp_sub_n(np, np, dp, dsize);
+					n0 = np[dsize - 1];
+					most_significant_q_limb = 1;
+				}
+			}
+
+			for (i = qextra_limbs + nsize - dsize - 1; i >= 0; i--) {
+				mpi_limb_t q;
+				mpi_limb_t n1, n2;
+				mpi_limb_t cy_limb;
+
+				if (i >= qextra_limbs) {
+					np--;
+					n2 = np[dsize];
+				} else {
+					n2 = np[dsize - 1];
+					MPN_COPY_DECR(np + 1, np, dsize - 1);
+					np[0] = 0;
+				}
+
+				if (n0 == dX) {
+					/* This might over-estimate q, but it's probably not worth
+					 * the extra code here to find out.  */
+					q = ~(mpi_limb_t) 0;
+				} else {
+					mpi_limb_t r;
+
+					udiv_qrnnd(q, r, n0, np[dsize - 1], dX);
+					umul_ppmm(n1, n0, d1, q);
+
+					while (n1 > r
+					       || (n1 == r
+						   && n0 > np[dsize - 2])) {
+						q--;
+						r += dX;
+						if (r < dX)	/* I.e. "carry in previous addition?" */
+							break;
+						n1 -= n0 < d1;
+						n0 -= d1;
+					}
+				}
+
+				/* Possible optimization: We already have (q * n0) and (1 * n1)
+				 * after the calculation of q.  Taking advantage of that, we
+				 * could make this loop make two iterations less.  */
+				cy_limb = mpihelp_submul_1(np, dp, dsize, q);
+
+				if (n2 != cy_limb) {
+					mpihelp_add_n(np, np, dp, dsize);
+					q--;
+				}
+
+				qp[i] = q;
+				n0 = np[dsize - 1];
+			}
+		}
+	}
+
+	return most_significant_q_limb;
+}
+
+static mpi_limb_t
+mpihelp_submul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+		 mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t cy_limb;
+	mpi_size_t j;
+	mpi_limb_t prod_high, prod_low;
+	mpi_limb_t x;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	 * the loop becomes faster.  */
+	j = -s1_size;
+	res_ptr -= j;
+	s1_ptr -= j;
+
+	cy_limb = 0;
+	do {
+		umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
+
+		prod_low += cy_limb;
+		cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high;
+
+		x = res_ptr[j];
+		prod_low = x - prod_low;
+		cy_limb += prod_low > x ? 1 : 0;
+		res_ptr[j] = prod_low;
+	} while (++j);
+
+	return cy_limb;
+}
+
+/**
+ * mpi_read_raw_data - Read a raw byte stream as a positive integer
+ * @xbuffer: The data to read
+ * @nbytes: The amount of data to read
+ */
+MPI mpi_read_raw_data(const void *xbuffer, size_t nbytes)
+{
+	const uint8_t *buffer = xbuffer;
+	int i, j;
+	unsigned nbits, nlimbs;
+	mpi_limb_t a;
+	MPI val = NULL;
+
+	while (nbytes > 0 && buffer[0] == 0) {
+		buffer++;
+		nbytes--;
+	}
+
+	nbits = nbytes * 8;
+	if (nbits > MAX_EXTERN_MPI_BITS) {
+		printk("MPI: mpi too large (%u bits)\n", nbits);
+		return NULL;
+	}
+	if (nbytes > 0)
+		nbits -= count_leading_zeros(buffer[0]) - (BITS_PER_LONG - 8);
+
+	nlimbs = DIV_ROUND_UP(nbytes, BYTES_PER_MPI_LIMB);
+	val = mpi_alloc(nlimbs);
+	if (!val)
+		return NULL;
+	val->nbits = nbits;
+	val->sign = 0;
+	val->nlimbs = nlimbs;
+
+	if (nbytes > 0) {
+		i = BYTES_PER_MPI_LIMB - nbytes % BYTES_PER_MPI_LIMB;
+		i %= BYTES_PER_MPI_LIMB;
+		for (j = nlimbs; j > 0; j--) {
+			a = 0;
+			for (; i < BYTES_PER_MPI_LIMB; i++) {
+				a <<= 8;
+				a |= *buffer++;
+			}
+			i = 0;
+			val->d[j - 1] = a;
+		}
+	}
+	return val;
+}
+
+/****************
+ * Note:  It was a bad idea to use the number of limbs to allocate
+ *	  because on a alpha the limbs are large but we normally need
+ *	  integers of n bits - So we should chnage this to bits (or bytes).
+ *
+ *	  But mpi_alloc is used in a lot of places :-)
+ */
+MPI mpi_alloc(unsigned nlimbs)
+{
+	MPI a;
+
+	a = xmalloc(struct mpi);
+	if (!a)
+		return a;
+
+	if (nlimbs) {
+		a->d = mpi_alloc_limb_space(nlimbs);
+		if (!a->d) {
+			xfree(a);
+			return NULL;
+		}
+	} else {
+		a->d = NULL;
+	}
+
+	a->alloced = nlimbs;
+	a->nlimbs = 0;
+	a->sign = 0;
+	a->flags = 0;
+	a->nbits = 0;
+	return a;
+}
+
+void mpi_free(MPI a)
+{
+	if (!a)
+		return;
+
+	if (a->flags & 4)
+		xfree(a->d);
+	else
+		mpi_free_limb_space(a->d);
+
+	if (a->flags & ~7)
+		printk("invalid flag value in mpi\n");
+	xfree(a);
+}
+
+int mpi_cmp_ui(MPI u, unsigned long v)
+{
+	mpi_limb_t limb = v;
+
+	mpi_normalize(u);
+	if (!u->nlimbs && !limb)
+		return 0;
+	if (u->sign)
+		return -1;
+	if (u->nlimbs > 1)
+		return 1;
+
+	if (u->d[0] == limb)
+		return 0;
+	else if (u->d[0] > limb)
+		return 1;
+	else
+		return -1;
+}
+
+int mpi_cmp(MPI u, MPI v)
+{
+	mpi_size_t usize, vsize;
+	int cmp;
+
+	mpi_normalize(u);
+	mpi_normalize(v);
+	usize = u->nlimbs;
+	vsize = v->nlimbs;
+	if (!u->sign && v->sign)
+		return 1;
+	if (u->sign && !v->sign)
+		return -1;
+	if (usize != vsize && !u->sign && !v->sign)
+		return usize - vsize;
+	if (usize != vsize && u->sign && v->sign)
+		return vsize - usize;
+	if (!usize)
+		return 0;
+	cmp = mpihelp_cmp(u->d, v->d, usize);
+	if (u->sign)
+		return -cmp;
+	return cmp;
+}
+
+/****************
+ * Sometimes we have MSL (most significant limbs) which are 0;
+ * this is for some reasons not good, so this function removes them.
+ */
+static void mpi_normalize(MPI a)
+{
+	for (; a->nlimbs && !a->d[a->nlimbs - 1]; a->nlimbs--)
+		;
+}
+
+/****************
+ * Return the number of bits in A.
+ */
+unsigned mpi_get_nbits(MPI a)
+{
+	unsigned n;
+
+	mpi_normalize(a);
+
+	if (a->nlimbs) {
+		mpi_limb_t alimb = a->d[a->nlimbs - 1];
+		if (alimb)
+			n = count_leading_zeros(alimb);
+		else
+			n = BITS_PER_MPI_LIMB;
+		n = BITS_PER_MPI_LIMB - n + (a->nlimbs - 1) * BITS_PER_MPI_LIMB;
+	} else
+		n = 0;
+	return n;
+}
+
+int mpi_test_bit(MPI a, unsigned int n)
+{
+	unsigned int limbno, bitno;
+	mpi_limb_t limb;
+
+	limbno = n / BITS_PER_MPI_LIMB;
+	bitno  = n % BITS_PER_MPI_LIMB;
+
+	if (limbno >= a->nlimbs)
+		return 0; /* too far left: this is a 0 */
+	limb = a->d[limbno];
+	return (limb & (((mpi_limb_t)1) << bitno))? 1: 0;
+}
diff --git a/xen/crypto/Makefile b/xen/crypto/Makefile
index db29655333a3..d88374ddf221 100644
--- a/xen/crypto/Makefile
+++ b/xen/crypto/Makefile
@@ -1,2 +1,3 @@
 obj-y += rijndael.o
+obj-y += rsa.o
 obj-y += vmac.o
diff --git a/xen/crypto/rsa.c b/xen/crypto/rsa.c
new file mode 100644
index 000000000000..eff32222fe3b
--- /dev/null
+++ b/xen/crypto/rsa.c
@@ -0,0 +1,194 @@
+/* rsa.c
+
+   The RSA publickey algorithm.
+
+   Copyright (C) 2001 Niels Möller
+
+   This file is part of GNU Nettle.
+
+   GNU Nettle is free software: you can redistribute it and/or
+   modify it under the terms of either:
+
+     * the GNU Lesser General Public License as published by the Free
+       Software Foundation; either version 3 of the License, or (at your
+       option) any later version.
+
+   or
+
+     * the GNU General Public License as published by the Free
+       Software Foundation; either version 2 of the License, or (at your
+       option) any later version.
+
+   or both in parallel, as here.
+
+   GNU Nettle is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received copies of the GNU General Public License and
+   the GNU Lesser General Public License along with this program.  If
+   not, see http://www.gnu.org/licenses/.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void rsa_public_key_init(struct rsa_public_key *key)
+{
+    key->n = NULL;
+    key->e = NULL;
+    key->size = 0;
+}
+
+/*
+ * Computes the size, in octets, of the modulo. Returns 0 if the
+ * modulo is too small to be useful, or otherwise appears invalid.
+ */
+static size_t rsa_check_size(MPI n)
+{
+    /* Round upwards */
+    size_t size;
+
+    /* Even moduli are invalid */
+    if ( mpi_test_bit(n, 0) == 0 )
+        return 0;
+
+    size = (mpi_get_nbits(n) + 7) / 8;
+
+    if ( size < RSA_MINIMUM_N_OCTETS )
+        return 0;
+
+    return size;
+}
+
+int rsa_public_key_prepare(struct rsa_public_key *key)
+{
+    if ( !key->n || !key->e || key->size )
+        return -EINVAL;
+
+    key->size = rsa_check_size(key->n);
+
+    return key->size > 0 ? 0 : -EINVAL;
+}
+
+/*
+ * Formats the PKCS#1 padding, of the form
+ *
+ *   0x00 0x01 0xff ... 0xff 0x00 id ...digest...
+ *
+ * where the 0xff ... 0xff part consists of at least 8 octets. The
+ * total size equals the octet size of n.
+ */
+static uint8_t *pkcs1_signature_prefix(unsigned int key_size, uint8_t *buffer,
+                                       unsigned int id_size, const uint8_t *id,
+                                       unsigned int digest_size)
+{
+    unsigned int j;
+
+    if ( key_size < 11 + id_size + digest_size )
+        return NULL;
+
+    j = key_size - digest_size - id_size;
+
+    memcpy(buffer + j, id, id_size);
+    buffer[0] = 0;
+    buffer[1] = 1;
+    buffer[j - 1] = 0;
+
+    ASSERT(j >= 11);
+    memset(buffer + 2, 0xff, j - 3);
+
+    return buffer + j + id_size;
+}
+
+/*
+ * From RFC 3447, Public-Key Cryptography Standards (PKCS) #1: RSA
+ * Cryptography Specifications Version 2.1.
+ *
+ *     id-sha256    OBJECT IDENTIFIER ::=
+ *       {joint-iso-itu-t(2) country(16) us(840) organization(1)
+ *         gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1}
+ */
+static const uint8_t
+sha256_prefix[] =
+{
+  /* 19 octets prefix, 32 octets hash, total 51 */
+  0x30,      49, /* SEQUENCE */
+    0x30,    13, /* SEQUENCE */
+      0x06,   9, /* OBJECT IDENTIFIER */
+        0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01,
+      0x05,   0, /* NULL */
+    0x04,    32  /* OCTET STRING */
+      /* Here comes the raw hash value */
+};
+
+static int pkcs1_rsa_sha256_encode(MPI *m, size_t key_size,
+                                   struct sha2_256_state *hash)
+{
+    uint8_t *ptr;
+    uint8_t *buf;
+
+    buf = xmalloc_bytes(key_size);
+    if ( !buf )
+        return -ENOMEM;
+
+    ptr = pkcs1_signature_prefix(key_size, buf,
+                                 sizeof(sha256_prefix), sha256_prefix,
+                                 SHA2_256_DIGEST_SIZE);
+    if ( !ptr )
+    {
+        xfree(buf);
+        return -EINVAL;
+    }
+
+    sha2_256_final(hash, ptr);
+    *m = mpi_read_raw_data(buf, key_size);
+    xfree(buf);
+    return 0;
+}
+
+static int rsa_verify(const struct rsa_public_key *key, MPI m, MPI s)
+{
+    int ret;
+    MPI m1;
+
+    /* (1) Validate 0 <= s < n */
+    if ( mpi_cmp_ui(s, 0) < 0 || mpi_cmp(s, key->n) >= 0 )
+        return -EINVAL;
+
+    m1 = mpi_alloc(key->size / BYTES_PER_MPI_LIMB);
+    if ( !m1 )
+        return -ENOMEM;
+
+    /* (2) m = s^e mod n */
+    ret = mpi_powm(m1, s, key->e, key->n);
+    if ( ret )
+        goto out;
+
+    ret = mpi_cmp (m, m1) ? -EINVAL : 0;
+
+out:
+    mpi_free(m1);
+    return ret;
+}
+
+int rsa_sha256_verify(const struct rsa_public_key *key,
+                      struct sha2_256_state *hash, MPI s)
+{
+    int ret;
+    MPI m;
+
+    ret = pkcs1_rsa_sha256_encode(&m, key->size, hash);
+    if ( ret )
+        return ret;
+
+    ret = rsa_verify(key, m, s);
+
+    mpi_free(m);
+
+    return ret;
+}
diff --git a/xen/include/xen/mpi.h b/xen/include/xen/mpi.h
new file mode 100644
index 000000000000..987971b848e8
--- /dev/null
+++ b/xen/include/xen/mpi.h
@@ -0,0 +1,63 @@
+/* mpi.h  -  Multi Precision Integers
+ *        Copyright (C) 1994, 1996, 1998, 1999,
+ *                    2000, 2001 Free Software Foundation, Inc.
+ *
+ * This file is part of GNUPG.
+ *
+ * GNUPG is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * GNUPG is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ *
+ * Note: This code is heavily based on the GNU MP Library.
+ *         Actually it's the same code with only minor changes in the
+ *         way the data is stored; this is to support the abstraction
+ *         of an optional secure memory allocation which may be used
+ *         to avoid revealing of sensitive data due to paging etc.
+ *         The GNU MP Library itself is published under the LGPL;
+ *         however I decided to publish this code under the plain GPL.
+ */
+
+#ifndef MPI_H
+#define MPI_H
+
+#include 
+
+#define BYTES_PER_MPI_LIMB      (BITS_PER_LONG / 8)
+#define BITS_PER_MPI_LIMB       BITS_PER_LONG
+
+typedef unsigned long int mpi_limb_t;
+typedef signed long int mpi_limb_signed_t;
+
+struct mpi {
+    int alloced;        /* array size (# of allocated limbs) */
+    int nlimbs;         /* number of valid limbs */
+    int nbits;          /* the real number of valid bits (info only) */
+    int sign;           /* indicates a negative number */
+    unsigned flags;     /* bit 0: array must be allocated in secure memory space */
+    /* bit 1: not used */
+    /* bit 2: the limb is a pointer to some m_alloced data */
+    mpi_limb_t *d;      /* array with the limbs */
+};
+
+typedef struct mpi *MPI;
+
+MPI mpi_alloc(unsigned nlimbs);
+void mpi_free(MPI a);
+MPI mpi_read_raw_data(const void *xbuffer, size_t nbytes);
+int mpi_powm(MPI res, MPI base, MPI exp, MPI mod);
+int mpi_cmp_ui(MPI u, unsigned long v);
+int mpi_cmp(MPI u, MPI v);
+unsigned mpi_get_nbits(MPI a);
+int mpi_test_bit(MPI a, unsigned int n);
+
+#endif /* MPI_H */
diff --git a/xen/include/xen/rsa.h b/xen/include/xen/rsa.h
new file mode 100644
index 000000000000..13b5ebe9a1e6
--- /dev/null
+++ b/xen/include/xen/rsa.h
@@ -0,0 +1,72 @@
+/* rsa.h
+
+   The RSA publickey algorithm.
+
+   Copyright (C) 2001, 2002 Niels Möller
+
+   This file is part of GNU Nettle.
+
+   GNU Nettle is free software: you can redistribute it and/or
+   modify it under the terms of either:
+
+     * the GNU Lesser General Public License as published by the Free
+       Software Foundation; either version 3 of the License, or (at your
+       option) any later version.
+
+   or
+
+     * the GNU General Public License as published by the Free
+       Software Foundation; either version 2 of the License, or (at your
+       option) any later version.
+
+   or both in parallel, as here.
+
+   GNU Nettle is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received copies of the GNU General Public License and
+   the GNU Lesser General Public License along with this program.  If
+   not, see http://www.gnu.org/licenses/.
+*/
+ 
+#ifndef RSA_H
+#define RSA_H
+
+#include 
+#include 
+#include 
+
+/*
+ * This limit is somewhat arbitrary. Technically, the smallest modulo
+ * which makes sense at all is 15 = 3*5, phi(15) = 8, size 4 bits. But
+ * for ridiculously small keys, not all odd e are possible (e.g., for
+ * 5 bits, the only possible modulo is 3*7 = 21, phi(21) = 12, and e =
+ * 3 don't work). The smallest size that makes sense with pkcs#1, and
+ * which allows RSA encryption of one byte messages, is 12 octets, 89
+ * bits.
+ */
+#define RSA_MINIMUM_N_OCTETS 12
+#define RSA_MINIMUM_N_BITS (8 * RSA_MINIMUM_N_OCTETS - 7)
+
+struct rsa_public_key
+{
+    /*
+     * Size of the modulo, in octets. This is also the size of all
+     * signatures that are created or verified with this key.
+     */
+    size_t size;
+    MPI n; /* Modulo */
+    MPI e; /* Public exponent */
+};
+
+void rsa_public_key_init(struct rsa_public_key *key);
+
+int rsa_public_key_prepare(struct rsa_public_key *key);
+
+int rsa_sha256_verify(const struct rsa_public_key *key,
+                      struct sha2_256_state *hash,
+                      MPI signature);
+
+#endif /* RSA_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 14:32:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 14:32:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977414.1364443 (Exim 4.92)
	(envelope-from )
	id 1uCJLt-0001VW-9x; Tue, 06 May 2025 14:32:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977414.1364443; Tue, 06 May 2025 14: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 1uCJLt-0001VP-6n; Tue, 06 May 2025 14:32:57 +0000
Received: by outflank-mailman (input) for mailman id 977414;
 Tue, 06 May 2025 14:32:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCJLq-0000Q4-Uj
 for xen-devel@lists.xen.org; Tue, 06 May 2025 14:32:55 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fe126ffb-2a86-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 16:32:52 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-acb39c45b4eso913382966b.1
 for ; Tue, 06 May 2025 07:32:52 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1894c0356sm711598966b.100.2025.05.06.07.32.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 07:32: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" 
X-Inumbo-ID: fe126ffb-2a86-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746541972; x=1747146772; darn=lists.xen.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;
        bh=bGQj8XO9xK1XWcKjxy5tWwgI9dG4aXp1v1X5ZUMFZno=;
        b=Vl0mX3TSKT/7OL+HFjYNC0r9F4CsSK1JQFTGP5AoTNzVXn2i3HQ9+yy0AtEoRy90Vq
         USPoh7ZnegZ4nnGbDWnyBHSaH5eDX3jmGtHzsx+82qHCBV/epbRuKPbpcSPCTMu11tlm
         dh7yMq1ARKsJZFgY3ltKyJAhS1HCoBP13gRy4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746541972; x=1747146772;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=bGQj8XO9xK1XWcKjxy5tWwgI9dG4aXp1v1X5ZUMFZno=;
        b=J91cyg3ndL4N15utS5p3yQVQWPVS0yPBgxRDGPLtJSaJWtlHiqn2t427c0Znxe4peb
         MYXKo2W3CkAwe5pT5rFDOirfTXZU8C4gAQq3XjbGrIIiT27zKyCme9g/QyUFETuuJYmV
         eg8QgTH9f/jjjrJVSv+FFAbyNOjBoy/iNZemIuh3fd1Y7GnxL6LpojUH6edDPn96wClz
         0913l6FcdC+h5bAQfadSZ4pNANXyNboYKdwdVPQa9VIB7eoDO/4YBj2jl2NC/TDkbn54
         ZR45NzpqWdAY0Uj+H6/a4VAIhny+Q9KCmNZjS2LhYn5ySQrnF5uatEHkq7w+11ghKwtJ
         Z8yg==
X-Gm-Message-State: AOJu0Ywqm3txb01TB7GfEHLtJZ8AVwPWkx0bbDDGsJvvfFTwJw4W2/9X
	12gVTL0dx53SXms+o+b6FiUW8NwsI0oZ7y2BMs9v9iij6+kRuTUp3GqtU+NzqV3ZR12OczvwHHI
	=
X-Gm-Gg: ASbGncvRmisZPrWZJ/HZNk5ExBblHOy5UGH3myKs4mpL+YP1jk3DAtLPeRN8QnmSYSL
	572LYJmgmrwIqFtp5YTw8Vjeu9I/LZsqlY1MP+cnVPOhXYEIaCXBzAVe0qYKZOgt3Etf/DmOvPe
	xNUAQbH3xwtYFGcs3iN6Jqs9cQeG0/A6OO6QPOuB6gydT2cMo5PCc9Zu9myB4CT7WHVilAdB19F
	lR51sXO6t7L6gh2rkS0mgP01f4rA2Zs6uQZRWFelw1M9EMG6HD/RXobqLPB9wGeVSplQaKkHLfH
	4rZ+XEBwvktMd9L+So44hLdVEmDssi1q1DVCOmZa31N3G/P2icCXGfs2Kg6lmctF
X-Google-Smtp-Source: AGHT+IGMF0oOg/WWjkkwCL2mmKhmU6bGYpiURlETPFlS+B8s9Ga0O9y4iOwSh+qxOLprOxov9mTd1Q==
X-Received: by 2002:a17:907:94d0:b0:ace:be7c:11da with SMTP id a640c23a62f3a-ad17b5dd7d5mr1554351366b.33.1746541970551;
        Tue, 06 May 2025 07:32:50 -0700 (PDT)
From: Ross Lagerwall 
To: Xen-devel ,
	xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 2/4] crypto: Add RSA support
Date: Tue,  6 May 2025 15:32:14 +0100
Message-ID: <20250506143218.1782603-3-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In preparation for adding support for livepatch signing, add support for
RSA crypto.

The RSA code is extracted from Nettle at tag nettle_3.2_release_20160128
(https://git.lysator.liu.se/nettle/nettle).

The MPI code is extracted from Linux at commit eef0df6a5953 (lib/mpi/*).

Signed-off-by: Ross Lagerwall 
---
 xen/common/Makefile   |    1 +
 xen/common/mpi.c      | 1724 +++++++++++++++++++++++++++++++++++++++++
 xen/crypto/Makefile   |    1 +
 xen/crypto/rsa.c      |  194 +++++
 xen/include/xen/mpi.h |   63 ++
 xen/include/xen/rsa.h |   72 ++
 6 files changed, 2055 insertions(+)
 create mode 100644 xen/common/mpi.c
 create mode 100644 xen/crypto/rsa.c
 create mode 100644 xen/include/xen/mpi.h
 create mode 100644 xen/include/xen/rsa.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f08730563f..ece6548bb072 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-y += memory.o
+obj-y += mpi.o
 obj-y += multicall.o
 obj-y += notifier.o
 obj-$(CONFIG_NUMA) += numa.o
diff --git a/xen/common/mpi.c b/xen/common/mpi.c
new file mode 100644
index 000000000000..e3e3ecd42283
--- /dev/null
+++ b/xen/common/mpi.c
@@ -0,0 +1,1724 @@
+/* mpi-pow.c  -  MPI functions
+ *	Copyright (C) 1994, 1996, 1998, 2000 Free Software Foundation, Inc.
+ *
+ * This file is part of GnuPG.
+ *
+ * GnuPG is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * GnuPG is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ *
+ * Note: This code is heavily based on the GNU MP Library.
+ *	 Actually it's the same code with only minor changes in the
+ *	 way the data is stored; this is to support the abstraction
+ *	 of an optional secure memory allocation which may be used
+ *	 to avoid revealing of sensitive data due to paging etc.
+ *	 The GNU MP Library itself is published under the LGPL;
+ *	 however I decided to publish this code under the plain GPL.
+ *
+ * mpi.c code extracted from linux @ eef0df6a5953, lib/mpi
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_EXTERN_MPI_BITS 16384
+
+/* Define it to a value which is good on most machines.
+ * tested 4, 16, 32 and 64, where 16 gave the best performance when
+ * checking a 768 and a 1024 bit ElGamal signature.
+ * (wk 22.12.97) */
+#define KARATSUBA_THRESHOLD 16
+
+typedef mpi_limb_t *mpi_ptr_t;	/* pointer to a limb */
+typedef int mpi_size_t;		/* (must be a signed type) */
+
+/* Copy N limbs from S to D.  */
+#define MPN_COPY(d, s, n) \
+	do {					\
+		mpi_size_t _i;			\
+		for (_i = 0; _i < (n); _i++)	\
+			(d)[_i] = (s)[_i];	\
+	} while (0)
+
+#define MPN_COPY_DECR(d, s, n) \
+	do {					\
+		mpi_size_t _i;			\
+		for (_i = (n)-1; _i >= 0; _i--) \
+			(d)[_i] = (s)[_i];	\
+	} while (0)
+
+/* Zero N limbs at D */
+#define MPN_ZERO(d, n) \
+	do {					\
+		int  _i;			\
+		for (_i = 0; _i < (n); _i++)	\
+			(d)[_i] = 0;		\
+	} while (0)
+
+#define MPN_NORMALIZE(d, n)  \
+	do {					\
+		while ((n) > 0) {		\
+			if ((d)[(n)-1])		\
+				break;		\
+			(n)--;			\
+		}				\
+	} while (0)
+
+#define MPN_MUL_N_RECURSE(prodp, up, vp, size, tspace)		\
+	do {							\
+		if ((size) < KARATSUBA_THRESHOLD)		\
+			mul_n_basecase(prodp, up, vp, size);	\
+		else						\
+			mul_n(prodp, up, vp, size, tspace);	\
+	} while (0);
+
+#define MPN_SQR_N_RECURSE(prodp, up, size, tspace)		\
+	do {							\
+		if ((size) < KARATSUBA_THRESHOLD)		\
+			mpih_sqr_n_basecase(prodp, up, size);	\
+		else						\
+			mpih_sqr_n(prodp, up, size, tspace);	\
+	} while (0);
+
+#define add_ssaaaa(sh, sl, ah, al, bh, bl) \
+do { \
+	mpi_limb_t __x; \
+	__x = (al) + (bl); \
+	(sh) = (ah) + (bh) + (__x < (al)); \
+	(sl) = __x; \
+} while (0)
+
+#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
+do { \
+	mpi_limb_t __x; \
+	__x = (al) - (bl); \
+	(sh) = (ah) - (bh) - (__x > (al)); \
+	(sl) = __x; \
+} while (0)
+
+#define __ll_B ((mpi_limb_t) 1 << (BITS_PER_MPI_LIMB / 2))
+#define __ll_lowpart(t) ((mpi_limb_t) (t) & (__ll_B - 1))
+#define __ll_highpart(t) ((mpi_limb_t) (t) >> (BITS_PER_MPI_LIMB / 2))
+
+#define umul_ppmm(w1, w0, u, v) \
+do { \
+	mpi_limb_t __x0, __x1, __x2, __x3; \
+	unsigned int __ul, __vl, __uh, __vh; \
+	mpi_limb_t __u = (u), __v = (v); \
+	\
+	__ul = __ll_lowpart(__u); \
+	__uh = __ll_highpart(__u); \
+	__vl = __ll_lowpart(__v); \
+	__vh = __ll_highpart(__v); \
+	\
+	__x0 = (mpi_limb_t) __ul * __vl; \
+	__x1 = (mpi_limb_t) __ul * __vh; \
+	__x2 = (mpi_limb_t) __uh * __vl; \
+	__x3 = (mpi_limb_t) __uh * __vh; \
+	\
+	__x1 += __ll_highpart(__x0);/* this can't give carry */ \
+	__x1 += __x2;		/* but this indeed can */ \
+	if (__x1 < __x2)		/* did we get it? */ \
+	__x3 += __ll_B;		/* yes, add it in the proper pos. */ \
+	\
+	(w1) = __x3 + __ll_highpart(__x1); \
+	(w0) = (__ll_lowpart(__x1) << BITS_PER_MPI_LIMB/2) + __ll_lowpart(__x0); \
+} while (0)
+
+#define udiv_qrnnd(q, r, n1, n0, d) \
+do { \
+	mpi_limb_t __d1, __d0, __q1, __q0, __r1, __r0, __m; \
+	__d1 = __ll_highpart(d); \
+	__d0 = __ll_lowpart(d); \
+	\
+	__r1 = (n1) % __d1; \
+	__q1 = (n1) / __d1; \
+	__m = (mpi_limb_t) __q1 * __d0; \
+	__r1 = __r1 * __ll_B | __ll_highpart(n0); \
+	if (__r1 < __m) { \
+		__q1--, __r1 += (d); \
+		if (__r1 >= (d)) /* i.e. we didn't get carry when adding to __r1 */ \
+		if (__r1 < __m) \
+			__q1--, __r1 += (d); \
+	} \
+	__r1 -= __m; \
+	\
+	__r0 = __r1 % __d1; \
+	__q0 = __r1 / __d1; \
+	__m = (mpi_limb_t) __q0 * __d0; \
+	__r0 = __r0 * __ll_B | __ll_lowpart(n0); \
+	if (__r0 < __m) { \
+		__q0--, __r0 += (d); \
+		if (__r0 >= (d)) \
+			if (__r0 < __m) \
+				__q0--, __r0 += (d); \
+	} \
+	__r0 -= __m; \
+	\
+	(q) = (mpi_limb_t) __q1 * __ll_B | __q0; \
+	(r) = __r0; \
+} while (0)
+
+struct karatsuba_ctx {
+	struct karatsuba_ctx *next;
+	mpi_ptr_t tspace;
+	mpi_size_t tspace_size;
+	mpi_ptr_t tp;
+	mpi_size_t tp_size;
+};
+
+static void mpi_normalize(MPI a);
+static mpi_limb_t mpihelp_submul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			    mpi_size_t s1_size, mpi_limb_t s2_limb);
+static mpi_limb_t mpihelp_divrem(mpi_ptr_t qp, mpi_size_t qextra_limbs,
+			  mpi_ptr_t np, mpi_size_t nsize,
+			  mpi_ptr_t dp, mpi_size_t dsize);
+static mpi_limb_t mpihelp_rshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize,
+			  unsigned cnt);
+static void mpi_assign_limb_space(MPI a, mpi_ptr_t ap, unsigned nlimbs);
+static mpi_ptr_t mpi_alloc_limb_space(unsigned nlimbs);
+static void mpi_free_limb_space(mpi_ptr_t a);
+static mpi_limb_t mpihelp_addmul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			    mpi_size_t s1_size, mpi_limb_t s2_limb);
+static int mpihelp_mul(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t usize,
+		mpi_ptr_t vp, mpi_size_t vsize, mpi_limb_t *_result);
+static mpi_limb_t mpihelp_lshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize,
+			  unsigned cnt);
+static int mpihelp_cmp(mpi_ptr_t op1_ptr, mpi_ptr_t op2_ptr, mpi_size_t size);
+static void mpih_sqr_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size,
+		mpi_ptr_t tspace);
+static mpi_limb_t mpihelp_add_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			 mpi_ptr_t s2_ptr, mpi_size_t size);
+static mpi_limb_t mpihelp_sub_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			 mpi_ptr_t s2_ptr, mpi_size_t size);
+static mpi_limb_t mpihelp_mul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			 mpi_size_t s1_size, mpi_limb_t s2_limb);
+static void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx *ctx);
+static void mpih_sqr_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size);
+static int mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,
+			       mpi_ptr_t up, mpi_size_t usize,
+			       mpi_ptr_t vp, mpi_size_t vsize,
+			       struct karatsuba_ctx *ctx);
+static int mpi_resize(MPI a, unsigned nlimbs);
+
+/**
+ * count_leading_zeros - Count the number of zeros from the MSB back
+ * @x: The value
+ *
+ * Count the number of leading zeros from the MSB going towards the LSB in @x.
+ *
+ * If the MSB of @x is set, the result is 0.
+ * If only the LSB of @x is set, then the result is BITS_PER_LONG-1.
+ * If @x is 0 then the result is BITS_PER_LONG.
+ */
+static inline int count_leading_zeros(unsigned long x)
+{
+	if (sizeof(x) == 4)
+		return BITS_PER_LONG - fls(x);
+	else
+		return BITS_PER_LONG - fls64(x);
+}
+
+static mpi_limb_t
+mpihelp_add_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t x;
+
+	x = *s1_ptr++;
+	s2_limb += x;
+	*res_ptr++ = s2_limb;
+	if (s2_limb < x) {	/* sum is less than the left operand: handle carry */
+		while (--s1_size) {
+			x = *s1_ptr++ + 1;	/* add carry */
+			*res_ptr++ = x;	/* and store */
+			if (x)	/* not 0 (no overflow): we can stop */
+				goto leave;
+		}
+		return 1;	/* return carry (size of s1 to small) */
+	}
+
+leave:
+	if (res_ptr != s1_ptr) {	/* not the same variable */
+		mpi_size_t i;	/* copy the rest */
+		for (i = 0; i < s1_size - 1; i++)
+			res_ptr[i] = s1_ptr[i];
+	}
+	return 0;		/* no carry */
+}
+
+static mpi_limb_t
+mpihelp_sub_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t x;
+
+	x = *s1_ptr++;
+	s2_limb = x - s2_limb;
+	*res_ptr++ = s2_limb;
+	if (s2_limb > x) {
+		while (--s1_size) {
+			x = *s1_ptr++;
+			*res_ptr++ = x - 1;
+			if (x)
+				goto leave;
+		}
+		return 1;
+	}
+
+leave:
+	if (res_ptr != s1_ptr) {
+		mpi_size_t i;
+		for (i = 0; i < s1_size - 1; i++)
+			res_ptr[i] = s1_ptr[i];
+	}
+	return 0;
+}
+
+static mpi_limb_t
+mpihelp_sub(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size,
+	    mpi_ptr_t s2_ptr, mpi_size_t s2_size)
+{
+	mpi_limb_t cy = 0;
+
+	if (s2_size)
+		cy = mpihelp_sub_n(res_ptr, s1_ptr, s2_ptr, s2_size);
+
+	if (s1_size - s2_size)
+		cy = mpihelp_sub_1(res_ptr + s2_size, s1_ptr + s2_size,
+				   s1_size - s2_size, cy);
+	return cy;
+}
+
+static mpi_ptr_t mpi_alloc_limb_space(unsigned nlimbs)
+{
+	size_t len = nlimbs * sizeof(mpi_limb_t);
+
+	if (!len)
+		return NULL;
+
+	return xmalloc_bytes(len);
+}
+
+static void mpi_free_limb_space(mpi_ptr_t a)
+{
+	if (!a)
+		return;
+
+	xfree(a);
+}
+
+/****************
+ * Resize the array of A to NLIMBS. the additional space is cleared
+ * (set to 0) [done by m_realloc()]
+ */
+static int mpi_resize(MPI a, unsigned nlimbs)
+{
+	void *p;
+
+	if (nlimbs <= a->alloced)
+		return 0;	/* no need to do it */
+
+	if (a->d) {
+		p = xmalloc_array(mpi_limb_t, nlimbs);
+		if (!p)
+			return -ENOMEM;
+		memcpy(p, a->d, a->alloced * sizeof(mpi_limb_t));
+		xfree(a->d);
+		a->d = p;
+	} else {
+		a->d = xzalloc_array(mpi_limb_t, nlimbs);
+		if (!a->d)
+			return -ENOMEM;
+	}
+	a->alloced = nlimbs;
+	return 0;
+}
+
+/****************
+ * RES = BASE ^ EXP mod MOD
+ */
+int mpi_powm(MPI res, MPI base, MPI exp, MPI mod)
+{
+	mpi_ptr_t mp_marker = NULL, bp_marker = NULL, ep_marker = NULL;
+	mpi_ptr_t xp_marker = NULL;
+	mpi_ptr_t tspace = NULL;
+	mpi_ptr_t rp, ep, mp, bp;
+	mpi_size_t esize, msize, bsize, rsize;
+	int msign, bsign, rsign;
+	mpi_size_t size;
+	int mod_shift_cnt;
+	int negative_result;
+	int assign_rp = 0;
+	mpi_size_t tsize = 0;	/* to avoid compiler warning */
+	/* fixme: we should check that the warning is void */
+	int rc = -ENOMEM;
+
+	esize = exp->nlimbs;
+	msize = mod->nlimbs;
+	size = 2 * msize;
+	msign = mod->sign;
+
+	rp = res->d;
+	ep = exp->d;
+
+	if (!msize)
+		return -EINVAL;
+
+	if (!esize) {
+		/* Exponent is zero, result is 1 mod MOD, i.e., 1 or 0
+		 * depending on if MOD equals 1.  */
+		rp[0] = 1;
+		res->nlimbs = (msize == 1 && mod->d[0] == 1) ? 0 : 1;
+		res->sign = 0;
+		goto leave;
+	}
+
+	/* Normalize MOD (i.e. make its most significant bit set) as required by
+	 * mpn_divrem.  This will make the intermediate values in the calculation
+	 * slightly larger, but the correct result is obtained after a final
+	 * reduction using the original MOD value.  */
+	mp = mp_marker = mpi_alloc_limb_space(msize);
+	if (!mp)
+		goto enomem;
+	mod_shift_cnt = count_leading_zeros(mod->d[msize - 1]);
+	if (mod_shift_cnt)
+		mpihelp_lshift(mp, mod->d, msize, mod_shift_cnt);
+	else
+		MPN_COPY(mp, mod->d, msize);
+
+	bsize = base->nlimbs;
+	bsign = base->sign;
+	if (bsize > msize) {	/* The base is larger than the module. Reduce it. */
+		/* Allocate (BSIZE + 1) with space for remainder and quotient.
+		 * (The quotient is (bsize - msize + 1) limbs.)  */
+		bp = bp_marker = mpi_alloc_limb_space(bsize + 1);
+		if (!bp)
+			goto enomem;
+		MPN_COPY(bp, base->d, bsize);
+		/* We don't care about the quotient, store it above the remainder,
+		 * at BP + MSIZE.  */
+		mpihelp_divrem(bp + msize, 0, bp, bsize, mp, msize);
+		bsize = msize;
+		/* Canonicalize the base, since we are going to multiply with it
+		 * quite a few times.  */
+		MPN_NORMALIZE(bp, bsize);
+	} else
+		bp = base->d;
+
+	if (!bsize) {
+		res->nlimbs = 0;
+		res->sign = 0;
+		goto leave;
+	}
+
+	if (res->alloced < size) {
+		/* We have to allocate more space for RES.  If any of the input
+		 * parameters are identical to RES, defer deallocation of the old
+		 * space.  */
+		if (rp == ep || rp == mp || rp == bp) {
+			rp = mpi_alloc_limb_space(size);
+			if (!rp)
+				goto enomem;
+			assign_rp = 1;
+		} else {
+			if (mpi_resize(res, size) < 0)
+				goto enomem;
+			rp = res->d;
+		}
+	} else {		/* Make BASE, EXP and MOD not overlap with RES.  */
+		if (rp == bp) {
+			/* RES and BASE are identical.  Allocate temp. space for BASE.  */
+			BUG_ON(bp_marker);
+			bp = bp_marker = mpi_alloc_limb_space(bsize);
+			if (!bp)
+				goto enomem;
+			MPN_COPY(bp, rp, bsize);
+		}
+		if (rp == ep) {
+			/* RES and EXP are identical.  Allocate temp. space for EXP.  */
+			ep = ep_marker = mpi_alloc_limb_space(esize);
+			if (!ep)
+				goto enomem;
+			MPN_COPY(ep, rp, esize);
+		}
+		if (rp == mp) {
+			/* RES and MOD are identical.  Allocate temporary space for MOD. */
+			BUG_ON(mp_marker);
+			mp = mp_marker = mpi_alloc_limb_space(msize);
+			if (!mp)
+				goto enomem;
+			MPN_COPY(mp, rp, msize);
+		}
+	}
+
+	MPN_COPY(rp, bp, bsize);
+	rsize = bsize;
+	rsign = bsign;
+
+	{
+		mpi_size_t i;
+		mpi_ptr_t xp;
+		int c;
+		mpi_limb_t e;
+		mpi_limb_t carry_limb;
+		struct karatsuba_ctx karactx;
+
+		xp = xp_marker = mpi_alloc_limb_space(2 * (msize + 1));
+		if (!xp)
+			goto enomem;
+
+		memset(&karactx, 0, sizeof karactx);
+		negative_result = (ep[0] & 1) && base->sign;
+
+		i = esize - 1;
+		e = ep[i];
+		c = count_leading_zeros(e);
+		e = (e << c) << 1;	/* shift the exp bits to the left, lose msb */
+		c = BITS_PER_MPI_LIMB - 1 - c;
+
+		/* Main loop.
+		 *
+		 * Make the result be pointed to alternately by XP and RP.  This
+		 * helps us avoid block copying, which would otherwise be necessary
+		 * with the overlap restrictions of mpihelp_divmod. With 50% probability
+		 * the result after this loop will be in the area originally pointed
+		 * by RP (==RES->d), and with 50% probability in the area originally
+		 * pointed to by XP.
+		 */
+
+		for (;;) {
+			while (c) {
+				mpi_ptr_t tp;
+				mpi_size_t xsize;
+
+				/*if (mpihelp_mul_n(xp, rp, rp, rsize) < 0) goto enomem */
+				if (rsize < KARATSUBA_THRESHOLD)
+					mpih_sqr_n_basecase(xp, rp, rsize);
+				else {
+					if (!tspace) {
+						tsize = 2 * rsize;
+						tspace =
+						    mpi_alloc_limb_space(tsize);
+						if (!tspace)
+							goto enomem;
+					} else if (tsize < (2 * rsize)) {
+						mpi_free_limb_space(tspace);
+						tsize = 2 * rsize;
+						tspace =
+						    mpi_alloc_limb_space(tsize);
+						if (!tspace)
+							goto enomem;
+					}
+					mpih_sqr_n(xp, rp, rsize, tspace);
+				}
+
+				xsize = 2 * rsize;
+				if (xsize > msize) {
+					mpihelp_divrem(xp + msize, 0, xp, xsize,
+						       mp, msize);
+					xsize = msize;
+				}
+
+				tp = rp;
+				rp = xp;
+				xp = tp;
+				rsize = xsize;
+
+				if ((mpi_limb_signed_t) e < 0) {
+					/*mpihelp_mul( xp, rp, rsize, bp, bsize ); */
+					if (bsize < KARATSUBA_THRESHOLD) {
+						mpi_limb_t tmp;
+						if (mpihelp_mul
+						    (xp, rp, rsize, bp, bsize,
+						     &tmp) < 0)
+							goto enomem;
+					} else {
+						if (mpihelp_mul_karatsuba_case
+						    (xp, rp, rsize, bp, bsize,
+						     &karactx) < 0)
+							goto enomem;
+					}
+
+					xsize = rsize + bsize;
+					if (xsize > msize) {
+						mpihelp_divrem(xp + msize, 0,
+							       xp, xsize, mp,
+							       msize);
+						xsize = msize;
+					}
+
+					tp = rp;
+					rp = xp;
+					xp = tp;
+					rsize = xsize;
+				}
+				e <<= 1;
+				c--;
+			}
+
+			i--;
+			if (i < 0)
+				break;
+			e = ep[i];
+			c = BITS_PER_MPI_LIMB;
+		}
+
+		/* We shifted MOD, the modulo reduction argument, left MOD_SHIFT_CNT
+		 * steps.  Adjust the result by reducing it with the original MOD.
+		 *
+		 * Also make sure the result is put in RES->d (where it already
+		 * might be, see above).
+		 */
+		if (mod_shift_cnt) {
+			carry_limb =
+			    mpihelp_lshift(res->d, rp, rsize, mod_shift_cnt);
+			rp = res->d;
+			if (carry_limb) {
+				rp[rsize] = carry_limb;
+				rsize++;
+			}
+		} else {
+			MPN_COPY(res->d, rp, rsize);
+			rp = res->d;
+		}
+
+		if (rsize >= msize) {
+			mpihelp_divrem(rp + msize, 0, rp, rsize, mp, msize);
+			rsize = msize;
+		}
+
+		/* Remove any leading zero words from the result.  */
+		if (mod_shift_cnt)
+			mpihelp_rshift(rp, rp, rsize, mod_shift_cnt);
+		MPN_NORMALIZE(rp, rsize);
+
+		mpihelp_release_karatsuba_ctx(&karactx);
+	}
+
+	if (negative_result && rsize) {
+		if (mod_shift_cnt)
+			mpihelp_rshift(mp, mp, msize, mod_shift_cnt);
+		mpihelp_sub(rp, mp, msize, rp, rsize);
+		rsize = msize;
+		rsign = msign;
+		MPN_NORMALIZE(rp, rsize);
+	}
+	res->nlimbs = rsize;
+	res->sign = rsign;
+
+leave:
+	rc = 0;
+enomem:
+	if (assign_rp)
+		mpi_assign_limb_space(res, rp, size);
+	if (mp_marker)
+		mpi_free_limb_space(mp_marker);
+	if (bp_marker)
+		mpi_free_limb_space(bp_marker);
+	if (ep_marker)
+		mpi_free_limb_space(ep_marker);
+	if (xp_marker)
+		mpi_free_limb_space(xp_marker);
+	if (tspace)
+		mpi_free_limb_space(tspace);
+	return rc;
+}
+
+/* Multiply the natural numbers u (pointed to by UP) and v (pointed to by VP),
+ * both with SIZE limbs, and store the result at PRODP.  2 * SIZE limbs are
+ * always stored.  Return the most significant limb.
+ *
+ * Argument constraints:
+ * 1. PRODP != UP and PRODP != VP, i.e. the destination
+ *    must be distinct from the multiplier and the multiplicand.
+ *
+ *
+ * Handle simple cases with traditional multiplication.
+ *
+ * This is the most critical code of multiplication.  All multiplies rely
+ * on this, both small and huge.  Small ones arrive here immediately.  Huge
+ * ones arrive here as this is the base case for Karatsuba's recursive
+ * algorithm below.
+ */
+
+static mpi_limb_t
+mul_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_ptr_t vp, mpi_size_t size)
+{
+	mpi_size_t i;
+	mpi_limb_t cy;
+	mpi_limb_t v_limb;
+
+	/* Multiply by the first limb in V separately, as the result can be
+	 * stored (not added) to PROD.  We also avoid a loop for zeroing.  */
+	v_limb = vp[0];
+	if (v_limb <= 1) {
+		if (v_limb == 1)
+			MPN_COPY(prodp, up, size);
+		else
+			MPN_ZERO(prodp, size);
+		cy = 0;
+	} else
+		cy = mpihelp_mul_1(prodp, up, size, v_limb);
+
+	prodp[size] = cy;
+	prodp++;
+
+	/* For each iteration in the outer loop, multiply one limb from
+	 * U with one limb from V, and add it to PROD.  */
+	for (i = 1; i < size; i++) {
+		v_limb = vp[i];
+		if (v_limb <= 1) {
+			cy = 0;
+			if (v_limb == 1)
+				cy = mpihelp_add_n(prodp, prodp, up, size);
+		} else
+			cy = mpihelp_addmul_1(prodp, up, size, v_limb);
+
+		prodp[size] = cy;
+		prodp++;
+	}
+
+	return cy;
+}
+
+static void
+mul_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_ptr_t vp,
+		mpi_size_t size, mpi_ptr_t tspace)
+{
+	if (size & 1) {
+		/* The size is odd, and the code below doesn't handle that.
+		 * Multiply the least significant (size - 1) limbs with a recursive
+		 * call, and handle the most significant limb of S1 and S2
+		 * separately.
+		 * A slightly faster way to do this would be to make the Karatsuba
+		 * code below behave as if the size were even, and let it check for
+		 * odd size in the end.  I.e., in essence move this code to the end.
+		 * Doing so would save us a recursive call, and potentially make the
+		 * stack grow a lot less.
+		 */
+		mpi_size_t esize = size - 1;	/* even size */
+		mpi_limb_t cy_limb;
+
+		MPN_MUL_N_RECURSE(prodp, up, vp, esize, tspace);
+		cy_limb = mpihelp_addmul_1(prodp + esize, up, esize, vp[esize]);
+		prodp[esize + esize] = cy_limb;
+		cy_limb = mpihelp_addmul_1(prodp + esize, vp, size, up[esize]);
+		prodp[esize + size] = cy_limb;
+	} else {
+		/* Anatolij Alekseevich Karatsuba's divide-and-conquer algorithm.
+		 *
+		 * Split U in two pieces, U1 and U0, such that
+		 * U = U0 + U1*(B**n),
+		 * and V in V1 and V0, such that
+		 * V = V0 + V1*(B**n).
+		 *
+		 * UV is then computed recursively using the identity
+		 *
+		 *        2n   n          n                     n
+		 * UV = (B  + B )U V  +  B (U -U )(V -V )  +  (B + 1)U V
+		 *                1 1        1  0   0  1              0 0
+		 *
+		 * Where B = 2**BITS_PER_MP_LIMB.
+		 */
+		mpi_size_t hsize = size >> 1;
+		mpi_limb_t cy;
+		int negflg;
+
+		/* Product H.      ________________  ________________
+		 *                |_____U1 x V1____||____U0 x V0_____|
+		 * Put result in upper part of PROD and pass low part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_MUL_N_RECURSE(prodp + size, up + hsize, vp + hsize, hsize,
+				  tspace);
+
+		/* Product M.      ________________
+		 *                |_(U1-U0)(V0-V1)_|
+		 */
+		if (mpihelp_cmp(up + hsize, up, hsize) >= 0) {
+			mpihelp_sub_n(prodp, up + hsize, up, hsize);
+			negflg = 0;
+		} else {
+			mpihelp_sub_n(prodp, up, up + hsize, hsize);
+			negflg = 1;
+		}
+		if (mpihelp_cmp(vp + hsize, vp, hsize) >= 0) {
+			mpihelp_sub_n(prodp + hsize, vp + hsize, vp, hsize);
+			negflg ^= 1;
+		} else {
+			mpihelp_sub_n(prodp + hsize, vp, vp + hsize, hsize);
+			/* No change of NEGFLG.  */
+		}
+		/* Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_MUL_N_RECURSE(tspace, prodp, prodp + hsize, hsize,
+				  tspace + size);
+
+		/* Add/copy product H. */
+		MPN_COPY(prodp + hsize, prodp + size, hsize);
+		cy = mpihelp_add_n(prodp + size, prodp + size,
+				   prodp + size + hsize, hsize);
+
+		/* Add product M (if NEGFLG M is a negative number) */
+		if (negflg)
+			cy -=
+			    mpihelp_sub_n(prodp + hsize, prodp + hsize, tspace,
+					  size);
+		else
+			cy +=
+			    mpihelp_add_n(prodp + hsize, prodp + hsize, tspace,
+					  size);
+
+		/* Product L.      ________________  ________________
+		 *                |________________||____U0 x V0_____|
+		 * Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_MUL_N_RECURSE(tspace, up, vp, hsize, tspace + size);
+
+		/* Add/copy Product L (twice) */
+
+		cy += mpihelp_add_n(prodp + hsize, prodp + hsize, tspace, size);
+		if (cy)
+			mpihelp_add_1(prodp + hsize + size,
+				      prodp + hsize + size, hsize, cy);
+
+		MPN_COPY(prodp, tspace, hsize);
+		cy = mpihelp_add_n(prodp + hsize, prodp + hsize, tspace + hsize,
+				   hsize);
+		if (cy)
+			mpihelp_add_1(prodp + size, prodp + size, size, 1);
+	}
+}
+
+static void mpih_sqr_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size)
+{
+	mpi_size_t i;
+	mpi_limb_t cy_limb;
+	mpi_limb_t v_limb;
+
+	/* Multiply by the first limb in V separately, as the result can be
+	 * stored (not added) to PROD.  We also avoid a loop for zeroing.  */
+	v_limb = up[0];
+	if (v_limb <= 1) {
+		if (v_limb == 1)
+			MPN_COPY(prodp, up, size);
+		else
+			MPN_ZERO(prodp, size);
+		cy_limb = 0;
+	} else
+		cy_limb = mpihelp_mul_1(prodp, up, size, v_limb);
+
+	prodp[size] = cy_limb;
+	prodp++;
+
+	/* For each iteration in the outer loop, multiply one limb from
+	 * U with one limb from V, and add it to PROD.  */
+	for (i = 1; i < size; i++) {
+		v_limb = up[i];
+		if (v_limb <= 1) {
+			cy_limb = 0;
+			if (v_limb == 1)
+				cy_limb = mpihelp_add_n(prodp, prodp, up, size);
+		} else
+			cy_limb = mpihelp_addmul_1(prodp, up, size, v_limb);
+
+		prodp[size] = cy_limb;
+		prodp++;
+	}
+}
+
+static void
+mpih_sqr_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size, mpi_ptr_t tspace)
+{
+	if (size & 1) {
+		/* The size is odd, and the code below doesn't handle that.
+		 * Multiply the least significant (size - 1) limbs with a recursive
+		 * call, and handle the most significant limb of S1 and S2
+		 * separately.
+		 * A slightly faster way to do this would be to make the Karatsuba
+		 * code below behave as if the size were even, and let it check for
+		 * odd size in the end.  I.e., in essence move this code to the end.
+		 * Doing so would save us a recursive call, and potentially make the
+		 * stack grow a lot less.
+		 */
+		mpi_size_t esize = size - 1;	/* even size */
+		mpi_limb_t cy_limb;
+
+		MPN_SQR_N_RECURSE(prodp, up, esize, tspace);
+		cy_limb = mpihelp_addmul_1(prodp + esize, up, esize, up[esize]);
+		prodp[esize + esize] = cy_limb;
+		cy_limb = mpihelp_addmul_1(prodp + esize, up, size, up[esize]);
+
+		prodp[esize + size] = cy_limb;
+	} else {
+		mpi_size_t hsize = size >> 1;
+		mpi_limb_t cy;
+
+		/* Product H.      ________________  ________________
+		 *                |_____U1 x U1____||____U0 x U0_____|
+		 * Put result in upper part of PROD and pass low part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_SQR_N_RECURSE(prodp + size, up + hsize, hsize, tspace);
+
+		/* Product M.      ________________
+		 *                |_(U1-U0)(U0-U1)_|
+		 */
+		if (mpihelp_cmp(up + hsize, up, hsize) >= 0)
+			mpihelp_sub_n(prodp, up + hsize, up, hsize);
+		else
+			mpihelp_sub_n(prodp, up, up + hsize, hsize);
+
+		/* Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.  */
+		MPN_SQR_N_RECURSE(tspace, prodp, hsize, tspace + size);
+
+		/* Add/copy product H  */
+		MPN_COPY(prodp + hsize, prodp + size, hsize);
+		cy = mpihelp_add_n(prodp + size, prodp + size,
+				   prodp + size + hsize, hsize);
+
+		/* Add product M (if NEGFLG M is a negative number).  */
+		cy -= mpihelp_sub_n(prodp + hsize, prodp + hsize, tspace, size);
+
+		/* Product L.      ________________  ________________
+		 *                |________________||____U0 x U0_____|
+		 * Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.  */
+		MPN_SQR_N_RECURSE(tspace, up, hsize, tspace + size);
+
+		/* Add/copy Product L (twice).  */
+		cy += mpihelp_add_n(prodp + hsize, prodp + hsize, tspace, size);
+		if (cy)
+			mpihelp_add_1(prodp + hsize + size,
+				      prodp + hsize + size, hsize, cy);
+
+		MPN_COPY(prodp, tspace, hsize);
+		cy = mpihelp_add_n(prodp + hsize, prodp + hsize, tspace + hsize,
+				   hsize);
+		if (cy)
+			mpihelp_add_1(prodp + size, prodp + size, size, 1);
+	}
+}
+
+static int
+mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,
+			   mpi_ptr_t up, mpi_size_t usize,
+			   mpi_ptr_t vp, mpi_size_t vsize,
+			   struct karatsuba_ctx *ctx)
+{
+	mpi_limb_t cy;
+
+	if (!ctx->tspace || ctx->tspace_size < vsize) {
+		if (ctx->tspace)
+			mpi_free_limb_space(ctx->tspace);
+		ctx->tspace = mpi_alloc_limb_space(2 * vsize);
+		if (!ctx->tspace)
+			return -ENOMEM;
+		ctx->tspace_size = vsize;
+	}
+
+	MPN_MUL_N_RECURSE(prodp, up, vp, vsize, ctx->tspace);
+
+	prodp += vsize;
+	up += vsize;
+	usize -= vsize;
+	if (usize >= vsize) {
+		if (!ctx->tp || ctx->tp_size < vsize) {
+			if (ctx->tp)
+				mpi_free_limb_space(ctx->tp);
+			ctx->tp = mpi_alloc_limb_space(2 * vsize);
+			if (!ctx->tp) {
+				if (ctx->tspace)
+					mpi_free_limb_space(ctx->tspace);
+				ctx->tspace = NULL;
+				return -ENOMEM;
+			}
+			ctx->tp_size = vsize;
+		}
+
+		do {
+			MPN_MUL_N_RECURSE(ctx->tp, up, vp, vsize, ctx->tspace);
+			cy = mpihelp_add_n(prodp, prodp, ctx->tp, vsize);
+			mpihelp_add_1(prodp + vsize, ctx->tp + vsize, vsize,
+				      cy);
+			prodp += vsize;
+			up += vsize;
+			usize -= vsize;
+		} while (usize >= vsize);
+	}
+
+	if (usize) {
+		if (usize < KARATSUBA_THRESHOLD) {
+			mpi_limb_t tmp;
+			if (mpihelp_mul(ctx->tspace, vp, vsize, up, usize, &tmp)
+			    < 0)
+				return -ENOMEM;
+		} else {
+			if (!ctx->next) {
+				ctx->next = xzalloc(struct karatsuba_ctx);
+				if (!ctx->next)
+					return -ENOMEM;
+			}
+			if (mpihelp_mul_karatsuba_case(ctx->tspace,
+						       vp, vsize,
+						       up, usize,
+						       ctx->next) < 0)
+				return -ENOMEM;
+		}
+
+		cy = mpihelp_add_n(prodp, prodp, ctx->tspace, vsize);
+		mpihelp_add_1(prodp + vsize, ctx->tspace + vsize, usize, cy);
+	}
+
+	return 0;
+}
+
+static void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx *ctx)
+{
+	struct karatsuba_ctx *ctx2;
+
+	if (ctx->tp)
+		mpi_free_limb_space(ctx->tp);
+	if (ctx->tspace)
+		mpi_free_limb_space(ctx->tspace);
+	for (ctx = ctx->next; ctx; ctx = ctx2) {
+		ctx2 = ctx->next;
+		if (ctx->tp)
+			mpi_free_limb_space(ctx->tp);
+		if (ctx->tspace)
+			mpi_free_limb_space(ctx->tspace);
+		xfree(ctx);
+	}
+}
+
+/* Multiply the natural numbers u (pointed to by UP, with USIZE limbs)
+ * and v (pointed to by VP, with VSIZE limbs), and store the result at
+ * PRODP.  USIZE + VSIZE limbs are always stored, but if the input
+ * operands are normalized.  Return the most significant limb of the
+ * result.
+ *
+ * NOTE: The space pointed to by PRODP is overwritten before finished
+ * with U and V, so overlap is an error.
+ *
+ * Argument constraints:
+ * 1. USIZE >= VSIZE.
+ * 2. PRODP != UP and PRODP != VP, i.e. the destination
+ *    must be distinct from the multiplier and the multiplicand.
+ */
+
+static int
+mpihelp_mul(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t usize,
+	    mpi_ptr_t vp, mpi_size_t vsize, mpi_limb_t *_result)
+{
+	mpi_ptr_t prod_endp = prodp + usize + vsize - 1;
+	mpi_limb_t cy;
+	struct karatsuba_ctx ctx;
+
+	if (vsize < KARATSUBA_THRESHOLD) {
+		mpi_size_t i;
+		mpi_limb_t v_limb;
+
+		if (!vsize) {
+			*_result = 0;
+			return 0;
+		}
+
+		/* Multiply by the first limb in V separately, as the result can be
+		 * stored (not added) to PROD.  We also avoid a loop for zeroing.  */
+		v_limb = vp[0];
+		if (v_limb <= 1) {
+			if (v_limb == 1)
+				MPN_COPY(prodp, up, usize);
+			else
+				MPN_ZERO(prodp, usize);
+			cy = 0;
+		} else
+			cy = mpihelp_mul_1(prodp, up, usize, v_limb);
+
+		prodp[usize] = cy;
+		prodp++;
+
+		/* For each iteration in the outer loop, multiply one limb from
+		 * U with one limb from V, and add it to PROD.  */
+		for (i = 1; i < vsize; i++) {
+			v_limb = vp[i];
+			if (v_limb <= 1) {
+				cy = 0;
+				if (v_limb == 1)
+					cy = mpihelp_add_n(prodp, prodp, up,
+							   usize);
+			} else
+				cy = mpihelp_addmul_1(prodp, up, usize, v_limb);
+
+			prodp[usize] = cy;
+			prodp++;
+		}
+
+		*_result = cy;
+		return 0;
+	}
+
+	memset(&ctx, 0, sizeof ctx);
+	if (mpihelp_mul_karatsuba_case(prodp, up, usize, vp, vsize, &ctx) < 0)
+		return -ENOMEM;
+	mpihelp_release_karatsuba_ctx(&ctx);
+	*_result = *prod_endp;
+	return 0;
+}
+
+static mpi_limb_t
+mpihelp_mul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size,
+	      mpi_limb_t s2_limb)
+{
+	mpi_limb_t cy_limb;
+	mpi_size_t j;
+	mpi_limb_t prod_high, prod_low;
+
+	/* The loop counter and index J goes from -S1_SIZE to -1.  This way
+	 * the loop becomes faster.  */
+	j = -s1_size;
+
+	/* Offset the base pointers to compensate for the negative indices.  */
+	s1_ptr -= j;
+	res_ptr -= j;
+
+	cy_limb = 0;
+	do {
+		umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
+		prod_low += cy_limb;
+		cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high;
+		res_ptr[j] = prod_low;
+	} while (++j);
+
+	return cy_limb;
+}
+
+static mpi_limb_t
+mpihelp_add_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_ptr_t s2_ptr, mpi_size_t size)
+{
+	mpi_limb_t x, y, cy;
+	mpi_size_t j;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	   the loop becomes faster.  */
+	j = -size;
+
+	/* Offset the base pointers to compensate for the negative indices. */
+	s1_ptr -= j;
+	s2_ptr -= j;
+	res_ptr -= j;
+
+	cy = 0;
+	do {
+		y = s2_ptr[j];
+		x = s1_ptr[j];
+		y += cy;	/* add previous carry to one addend */
+		cy = y < cy;	/* get out carry from that addition */
+		y += x;		/* add other addend */
+		cy += y < x;	/* get out carry from that add, combine */
+		res_ptr[j] = y;
+	} while (++j);
+
+	return cy;
+}
+
+/* Shift U (pointed to by UP and USIZE digits long) CNT bits to the left
+ * and store the USIZE least significant digits of the result at WP.
+ * Return the bits shifted out from the most significant digit.
+ *
+ * Argument constraints:
+ * 1. 0 < CNT < BITS_PER_MP_LIMB
+ * 2. If the result is to be written over the input, WP must be >= UP.
+ */
+
+static mpi_limb_t
+mpihelp_lshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize, unsigned int cnt)
+{
+	mpi_limb_t high_limb, low_limb;
+	unsigned sh_1, sh_2;
+	mpi_size_t i;
+	mpi_limb_t retval;
+
+	sh_1 = cnt;
+	wp += 1;
+	sh_2 = BITS_PER_MPI_LIMB - sh_1;
+	i = usize - 1;
+	low_limb = up[i];
+	retval = low_limb >> sh_2;
+	high_limb = low_limb;
+	while (--i >= 0) {
+		low_limb = up[i];
+		wp[i] = (high_limb << sh_1) | (low_limb >> sh_2);
+		high_limb = low_limb;
+	}
+	wp[i] = high_limb << sh_1;
+
+	return retval;
+}
+
+static mpi_limb_t
+mpihelp_addmul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+		 mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t cy_limb;
+	mpi_size_t j;
+	mpi_limb_t prod_high, prod_low;
+	mpi_limb_t x;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	 * the loop becomes faster.  */
+	j = -s1_size;
+	res_ptr -= j;
+	s1_ptr -= j;
+
+	cy_limb = 0;
+	do {
+		umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
+
+		prod_low += cy_limb;
+		cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high;
+
+		x = res_ptr[j];
+		prod_low = x + prod_low;
+		cy_limb += prod_low < x ? 1 : 0;
+		res_ptr[j] = prod_low;
+	} while (++j);
+	return cy_limb;
+}
+
+static mpi_limb_t
+mpihelp_sub_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_ptr_t s2_ptr, mpi_size_t size)
+{
+	mpi_limb_t x, y, cy;
+	mpi_size_t j;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	   the loop becomes faster.  */
+	j = -size;
+
+	/* Offset the base pointers to compensate for the negative indices.  */
+	s1_ptr -= j;
+	s2_ptr -= j;
+	res_ptr -= j;
+
+	cy = 0;
+	do {
+		y = s2_ptr[j];
+		x = s1_ptr[j];
+		y += cy;	/* add previous carry to subtrahend */
+		cy = y < cy;	/* get out carry from that addition */
+		y = x - y;	/* main subtract */
+		cy += y > x;	/* get out carry from the subtract, combine */
+		res_ptr[j] = y;
+	} while (++j);
+
+	return cy;
+}
+
+/****************
+ * Compare OP1_PTR/OP1_SIZE with OP2_PTR/OP2_SIZE.
+ * There are no restrictions on the relative sizes of
+ * the two arguments.
+ * Return 1 if OP1 > OP2, 0 if they are equal, and -1 if OP1 < OP2.
+ */
+static int mpihelp_cmp(mpi_ptr_t op1_ptr, mpi_ptr_t op2_ptr, mpi_size_t size)
+{
+	mpi_size_t i;
+	mpi_limb_t op1_word, op2_word;
+
+	for (i = size - 1; i >= 0; i--) {
+		op1_word = op1_ptr[i];
+		op2_word = op2_ptr[i];
+		if (op1_word != op2_word)
+			goto diff;
+	}
+	return 0;
+
+diff:
+	/* This can *not* be simplified to
+	 *   op2_word - op2_word
+	 * since that expression might give signed overflow.  */
+	return (op1_word > op2_word) ? 1 : -1;
+}
+
+static void mpi_assign_limb_space(MPI a, mpi_ptr_t ap, unsigned nlimbs)
+{
+	mpi_free_limb_space(a->d);
+	a->d = ap;
+	a->alloced = nlimbs;
+}
+
+/* Shift U (pointed to by UP and USIZE limbs long) CNT bits to the right
+ * and store the USIZE least significant limbs of the result at WP.
+ * The bits shifted out to the right are returned.
+ *
+ * Argument constraints:
+ * 1. 0 < CNT < BITS_PER_MP_LIMB
+ * 2. If the result is to be written over the input, WP must be <= UP.
+ */
+
+static mpi_limb_t
+mpihelp_rshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize, unsigned cnt)
+{
+	mpi_limb_t high_limb, low_limb;
+	unsigned sh_1, sh_2;
+	mpi_size_t i;
+	mpi_limb_t retval;
+
+	sh_1 = cnt;
+	wp -= 1;
+	sh_2 = BITS_PER_MPI_LIMB - sh_1;
+	high_limb = up[0];
+	retval = high_limb << sh_2;
+	low_limb = high_limb;
+	for (i = 1; i < usize; i++) {
+		high_limb = up[i];
+		wp[i] = (low_limb >> sh_1) | (high_limb << sh_2);
+		low_limb = high_limb;
+	}
+	wp[i] = low_limb >> sh_1;
+
+	return retval;
+}
+
+/* Divide num (NP/NSIZE) by den (DP/DSIZE) and write
+ * the NSIZE-DSIZE least significant quotient limbs at QP
+ * and the DSIZE long remainder at NP.	If QEXTRA_LIMBS is
+ * non-zero, generate that many fraction bits and append them after the
+ * other quotient limbs.
+ * Return the most significant limb of the quotient, this is always 0 or 1.
+ *
+ * Preconditions:
+ * 0. NSIZE >= DSIZE.
+ * 1. The most significant bit of the divisor must be set.
+ * 2. QP must either not overlap with the input operands at all, or
+ *    QP + DSIZE >= NP must hold true.	(This means that it's
+ *    possible to put the quotient in the high part of NUM, right after the
+ *    remainder in NUM.
+ * 3. NSIZE >= DSIZE, even if QEXTRA_LIMBS is non-zero.
+ */
+
+static mpi_limb_t
+mpihelp_divrem(mpi_ptr_t qp, mpi_size_t qextra_limbs,
+	       mpi_ptr_t np, mpi_size_t nsize, mpi_ptr_t dp, mpi_size_t dsize)
+{
+	mpi_limb_t most_significant_q_limb = 0;
+
+	switch (dsize) {
+	case 0:
+		/* We are asked to divide by zero, so go ahead and do it!  (To make
+		   the compiler not remove this statement, return the value.)  */
+		/*
+		 * existing clients of this function have been modified
+		 * not to call it with dsize == 0, so this should not happen
+		 */
+		return 1 / dsize;
+
+	case 1:
+		{
+			mpi_size_t i;
+			mpi_limb_t n1;
+			mpi_limb_t d;
+
+			d = dp[0];
+			n1 = np[nsize - 1];
+
+			if (n1 >= d) {
+				n1 -= d;
+				most_significant_q_limb = 1;
+			}
+
+			qp += qextra_limbs;
+			for (i = nsize - 2; i >= 0; i--)
+				udiv_qrnnd(qp[i], n1, n1, np[i], d);
+			qp -= qextra_limbs;
+
+			for (i = qextra_limbs - 1; i >= 0; i--)
+				udiv_qrnnd(qp[i], n1, n1, 0, d);
+
+			np[0] = n1;
+		}
+		break;
+
+	case 2:
+		{
+			mpi_size_t i;
+			mpi_limb_t n1, n0, n2;
+			mpi_limb_t d1, d0;
+
+			np += nsize - 2;
+			d1 = dp[1];
+			d0 = dp[0];
+			n1 = np[1];
+			n0 = np[0];
+
+			if (n1 >= d1 && (n1 > d1 || n0 >= d0)) {
+				sub_ddmmss(n1, n0, n1, n0, d1, d0);
+				most_significant_q_limb = 1;
+			}
+
+			for (i = qextra_limbs + nsize - 2 - 1; i >= 0; i--) {
+				mpi_limb_t q;
+				mpi_limb_t r;
+
+				if (i >= qextra_limbs)
+					np--;
+				else
+					np[0] = 0;
+
+				if (n1 == d1) {
+					/* Q should be either 111..111 or 111..110.  Need special
+					 * treatment of this rare case as normal division would
+					 * give overflow.  */
+					q = ~(mpi_limb_t) 0;
+
+					r = n0 + d1;
+					if (r < d1) {	/* Carry in the addition? */
+						add_ssaaaa(n1, n0, r - d0,
+							   np[0], 0, d0);
+						qp[i] = q;
+						continue;
+					}
+					n1 = d0 - (d0 != 0 ? 1 : 0);
+					n0 = -d0;
+				} else {
+					udiv_qrnnd(q, r, n1, n0, d1);
+					umul_ppmm(n1, n0, d0, q);
+				}
+
+				n2 = np[0];
+q_test:
+				if (n1 > r || (n1 == r && n0 > n2)) {
+					/* The estimated Q was too large.  */
+					q--;
+					sub_ddmmss(n1, n0, n1, n0, 0, d0);
+					r += d1;
+					if (r >= d1)	/* If not carry, test Q again.  */
+						goto q_test;
+				}
+
+				qp[i] = q;
+				sub_ddmmss(n1, n0, r, n2, n1, n0);
+			}
+			np[1] = n1;
+			np[0] = n0;
+		}
+		break;
+
+	default:
+		{
+			mpi_size_t i;
+			mpi_limb_t dX, d1, n0;
+
+			np += nsize - dsize;
+			dX = dp[dsize - 1];
+			d1 = dp[dsize - 2];
+			n0 = np[dsize - 1];
+
+			if (n0 >= dX) {
+				if (n0 > dX
+				    || mpihelp_cmp(np, dp, dsize - 1) >= 0) {
+					mpihelp_sub_n(np, np, dp, dsize);
+					n0 = np[dsize - 1];
+					most_significant_q_limb = 1;
+				}
+			}
+
+			for (i = qextra_limbs + nsize - dsize - 1; i >= 0; i--) {
+				mpi_limb_t q;
+				mpi_limb_t n1, n2;
+				mpi_limb_t cy_limb;
+
+				if (i >= qextra_limbs) {
+					np--;
+					n2 = np[dsize];
+				} else {
+					n2 = np[dsize - 1];
+					MPN_COPY_DECR(np + 1, np, dsize - 1);
+					np[0] = 0;
+				}
+
+				if (n0 == dX) {
+					/* This might over-estimate q, but it's probably not worth
+					 * the extra code here to find out.  */
+					q = ~(mpi_limb_t) 0;
+				} else {
+					mpi_limb_t r;
+
+					udiv_qrnnd(q, r, n0, np[dsize - 1], dX);
+					umul_ppmm(n1, n0, d1, q);
+
+					while (n1 > r
+					       || (n1 == r
+						   && n0 > np[dsize - 2])) {
+						q--;
+						r += dX;
+						if (r < dX)	/* I.e. "carry in previous addition?" */
+							break;
+						n1 -= n0 < d1;
+						n0 -= d1;
+					}
+				}
+
+				/* Possible optimization: We already have (q * n0) and (1 * n1)
+				 * after the calculation of q.  Taking advantage of that, we
+				 * could make this loop make two iterations less.  */
+				cy_limb = mpihelp_submul_1(np, dp, dsize, q);
+
+				if (n2 != cy_limb) {
+					mpihelp_add_n(np, np, dp, dsize);
+					q--;
+				}
+
+				qp[i] = q;
+				n0 = np[dsize - 1];
+			}
+		}
+	}
+
+	return most_significant_q_limb;
+}
+
+static mpi_limb_t
+mpihelp_submul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+		 mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t cy_limb;
+	mpi_size_t j;
+	mpi_limb_t prod_high, prod_low;
+	mpi_limb_t x;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	 * the loop becomes faster.  */
+	j = -s1_size;
+	res_ptr -= j;
+	s1_ptr -= j;
+
+	cy_limb = 0;
+	do {
+		umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
+
+		prod_low += cy_limb;
+		cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high;
+
+		x = res_ptr[j];
+		prod_low = x - prod_low;
+		cy_limb += prod_low > x ? 1 : 0;
+		res_ptr[j] = prod_low;
+	} while (++j);
+
+	return cy_limb;
+}
+
+/**
+ * mpi_read_raw_data - Read a raw byte stream as a positive integer
+ * @xbuffer: The data to read
+ * @nbytes: The amount of data to read
+ */
+MPI mpi_read_raw_data(const void *xbuffer, size_t nbytes)
+{
+	const uint8_t *buffer = xbuffer;
+	int i, j;
+	unsigned nbits, nlimbs;
+	mpi_limb_t a;
+	MPI val = NULL;
+
+	while (nbytes > 0 && buffer[0] == 0) {
+		buffer++;
+		nbytes--;
+	}
+
+	nbits = nbytes * 8;
+	if (nbits > MAX_EXTERN_MPI_BITS) {
+		printk("MPI: mpi too large (%u bits)\n", nbits);
+		return NULL;
+	}
+	if (nbytes > 0)
+		nbits -= count_leading_zeros(buffer[0]) - (BITS_PER_LONG - 8);
+
+	nlimbs = DIV_ROUND_UP(nbytes, BYTES_PER_MPI_LIMB);
+	val = mpi_alloc(nlimbs);
+	if (!val)
+		return NULL;
+	val->nbits = nbits;
+	val->sign = 0;
+	val->nlimbs = nlimbs;
+
+	if (nbytes > 0) {
+		i = BYTES_PER_MPI_LIMB - nbytes % BYTES_PER_MPI_LIMB;
+		i %= BYTES_PER_MPI_LIMB;
+		for (j = nlimbs; j > 0; j--) {
+			a = 0;
+			for (; i < BYTES_PER_MPI_LIMB; i++) {
+				a <<= 8;
+				a |= *buffer++;
+			}
+			i = 0;
+			val->d[j - 1] = a;
+		}
+	}
+	return val;
+}
+
+/****************
+ * Note:  It was a bad idea to use the number of limbs to allocate
+ *	  because on a alpha the limbs are large but we normally need
+ *	  integers of n bits - So we should chnage this to bits (or bytes).
+ *
+ *	  But mpi_alloc is used in a lot of places :-)
+ */
+MPI mpi_alloc(unsigned nlimbs)
+{
+	MPI a;
+
+	a = xmalloc(struct mpi);
+	if (!a)
+		return a;
+
+	if (nlimbs) {
+		a->d = mpi_alloc_limb_space(nlimbs);
+		if (!a->d) {
+			xfree(a);
+			return NULL;
+		}
+	} else {
+		a->d = NULL;
+	}
+
+	a->alloced = nlimbs;
+	a->nlimbs = 0;
+	a->sign = 0;
+	a->flags = 0;
+	a->nbits = 0;
+	return a;
+}
+
+void mpi_free(MPI a)
+{
+	if (!a)
+		return;
+
+	if (a->flags & 4)
+		xfree(a->d);
+	else
+		mpi_free_limb_space(a->d);
+
+	if (a->flags & ~7)
+		printk("invalid flag value in mpi\n");
+	xfree(a);
+}
+
+int mpi_cmp_ui(MPI u, unsigned long v)
+{
+	mpi_limb_t limb = v;
+
+	mpi_normalize(u);
+	if (!u->nlimbs && !limb)
+		return 0;
+	if (u->sign)
+		return -1;
+	if (u->nlimbs > 1)
+		return 1;
+
+	if (u->d[0] == limb)
+		return 0;
+	else if (u->d[0] > limb)
+		return 1;
+	else
+		return -1;
+}
+
+int mpi_cmp(MPI u, MPI v)
+{
+	mpi_size_t usize, vsize;
+	int cmp;
+
+	mpi_normalize(u);
+	mpi_normalize(v);
+	usize = u->nlimbs;
+	vsize = v->nlimbs;
+	if (!u->sign && v->sign)
+		return 1;
+	if (u->sign && !v->sign)
+		return -1;
+	if (usize != vsize && !u->sign && !v->sign)
+		return usize - vsize;
+	if (usize != vsize && u->sign && v->sign)
+		return vsize - usize;
+	if (!usize)
+		return 0;
+	cmp = mpihelp_cmp(u->d, v->d, usize);
+	if (u->sign)
+		return -cmp;
+	return cmp;
+}
+
+/****************
+ * Sometimes we have MSL (most significant limbs) which are 0;
+ * this is for some reasons not good, so this function removes them.
+ */
+static void mpi_normalize(MPI a)
+{
+	for (; a->nlimbs && !a->d[a->nlimbs - 1]; a->nlimbs--)
+		;
+}
+
+/****************
+ * Return the number of bits in A.
+ */
+unsigned mpi_get_nbits(MPI a)
+{
+	unsigned n;
+
+	mpi_normalize(a);
+
+	if (a->nlimbs) {
+		mpi_limb_t alimb = a->d[a->nlimbs - 1];
+		if (alimb)
+			n = count_leading_zeros(alimb);
+		else
+			n = BITS_PER_MPI_LIMB;
+		n = BITS_PER_MPI_LIMB - n + (a->nlimbs - 1) * BITS_PER_MPI_LIMB;
+	} else
+		n = 0;
+	return n;
+}
+
+int mpi_test_bit(MPI a, unsigned int n)
+{
+	unsigned int limbno, bitno;
+	mpi_limb_t limb;
+
+	limbno = n / BITS_PER_MPI_LIMB;
+	bitno  = n % BITS_PER_MPI_LIMB;
+
+	if (limbno >= a->nlimbs)
+		return 0; /* too far left: this is a 0 */
+	limb = a->d[limbno];
+	return (limb & (((mpi_limb_t)1) << bitno))? 1: 0;
+}
diff --git a/xen/crypto/Makefile b/xen/crypto/Makefile
index db29655333a3..d88374ddf221 100644
--- a/xen/crypto/Makefile
+++ b/xen/crypto/Makefile
@@ -1,2 +1,3 @@
 obj-y += rijndael.o
+obj-y += rsa.o
 obj-y += vmac.o
diff --git a/xen/crypto/rsa.c b/xen/crypto/rsa.c
new file mode 100644
index 000000000000..eff32222fe3b
--- /dev/null
+++ b/xen/crypto/rsa.c
@@ -0,0 +1,194 @@
+/* rsa.c
+
+   The RSA publickey algorithm.
+
+   Copyright (C) 2001 Niels Möller
+
+   This file is part of GNU Nettle.
+
+   GNU Nettle is free software: you can redistribute it and/or
+   modify it under the terms of either:
+
+     * the GNU Lesser General Public License as published by the Free
+       Software Foundation; either version 3 of the License, or (at your
+       option) any later version.
+
+   or
+
+     * the GNU General Public License as published by the Free
+       Software Foundation; either version 2 of the License, or (at your
+       option) any later version.
+
+   or both in parallel, as here.
+
+   GNU Nettle is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received copies of the GNU General Public License and
+   the GNU Lesser General Public License along with this program.  If
+   not, see http://www.gnu.org/licenses/.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void rsa_public_key_init(struct rsa_public_key *key)
+{
+    key->n = NULL;
+    key->e = NULL;
+    key->size = 0;
+}
+
+/*
+ * Computes the size, in octets, of the modulo. Returns 0 if the
+ * modulo is too small to be useful, or otherwise appears invalid.
+ */
+static size_t rsa_check_size(MPI n)
+{
+    /* Round upwards */
+    size_t size;
+
+    /* Even moduli are invalid */
+    if ( mpi_test_bit(n, 0) == 0 )
+        return 0;
+
+    size = (mpi_get_nbits(n) + 7) / 8;
+
+    if ( size < RSA_MINIMUM_N_OCTETS )
+        return 0;
+
+    return size;
+}
+
+int rsa_public_key_prepare(struct rsa_public_key *key)
+{
+    if ( !key->n || !key->e || key->size )
+        return -EINVAL;
+
+    key->size = rsa_check_size(key->n);
+
+    return key->size > 0 ? 0 : -EINVAL;
+}
+
+/*
+ * Formats the PKCS#1 padding, of the form
+ *
+ *   0x00 0x01 0xff ... 0xff 0x00 id ...digest...
+ *
+ * where the 0xff ... 0xff part consists of at least 8 octets. The
+ * total size equals the octet size of n.
+ */
+static uint8_t *pkcs1_signature_prefix(unsigned int key_size, uint8_t *buffer,
+                                       unsigned int id_size, const uint8_t *id,
+                                       unsigned int digest_size)
+{
+    unsigned int j;
+
+    if ( key_size < 11 + id_size + digest_size )
+        return NULL;
+
+    j = key_size - digest_size - id_size;
+
+    memcpy(buffer + j, id, id_size);
+    buffer[0] = 0;
+    buffer[1] = 1;
+    buffer[j - 1] = 0;
+
+    ASSERT(j >= 11);
+    memset(buffer + 2, 0xff, j - 3);
+
+    return buffer + j + id_size;
+}
+
+/*
+ * From RFC 3447, Public-Key Cryptography Standards (PKCS) #1: RSA
+ * Cryptography Specifications Version 2.1.
+ *
+ *     id-sha256    OBJECT IDENTIFIER ::=
+ *       {joint-iso-itu-t(2) country(16) us(840) organization(1)
+ *         gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1}
+ */
+static const uint8_t
+sha256_prefix[] =
+{
+  /* 19 octets prefix, 32 octets hash, total 51 */
+  0x30,      49, /* SEQUENCE */
+    0x30,    13, /* SEQUENCE */
+      0x06,   9, /* OBJECT IDENTIFIER */
+        0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01,
+      0x05,   0, /* NULL */
+    0x04,    32  /* OCTET STRING */
+      /* Here comes the raw hash value */
+};
+
+static int pkcs1_rsa_sha256_encode(MPI *m, size_t key_size,
+                                   struct sha2_256_state *hash)
+{
+    uint8_t *ptr;
+    uint8_t *buf;
+
+    buf = xmalloc_bytes(key_size);
+    if ( !buf )
+        return -ENOMEM;
+
+    ptr = pkcs1_signature_prefix(key_size, buf,
+                                 sizeof(sha256_prefix), sha256_prefix,
+                                 SHA2_256_DIGEST_SIZE);
+    if ( !ptr )
+    {
+        xfree(buf);
+        return -EINVAL;
+    }
+
+    sha2_256_final(hash, ptr);
+    *m = mpi_read_raw_data(buf, key_size);
+    xfree(buf);
+    return 0;
+}
+
+static int rsa_verify(const struct rsa_public_key *key, MPI m, MPI s)
+{
+    int ret;
+    MPI m1;
+
+    /* (1) Validate 0 <= s < n */
+    if ( mpi_cmp_ui(s, 0) < 0 || mpi_cmp(s, key->n) >= 0 )
+        return -EINVAL;
+
+    m1 = mpi_alloc(key->size / BYTES_PER_MPI_LIMB);
+    if ( !m1 )
+        return -ENOMEM;
+
+    /* (2) m = s^e mod n */
+    ret = mpi_powm(m1, s, key->e, key->n);
+    if ( ret )
+        goto out;
+
+    ret = mpi_cmp (m, m1) ? -EINVAL : 0;
+
+out:
+    mpi_free(m1);
+    return ret;
+}
+
+int rsa_sha256_verify(const struct rsa_public_key *key,
+                      struct sha2_256_state *hash, MPI s)
+{
+    int ret;
+    MPI m;
+
+    ret = pkcs1_rsa_sha256_encode(&m, key->size, hash);
+    if ( ret )
+        return ret;
+
+    ret = rsa_verify(key, m, s);
+
+    mpi_free(m);
+
+    return ret;
+}
diff --git a/xen/include/xen/mpi.h b/xen/include/xen/mpi.h
new file mode 100644
index 000000000000..987971b848e8
--- /dev/null
+++ b/xen/include/xen/mpi.h
@@ -0,0 +1,63 @@
+/* mpi.h  -  Multi Precision Integers
+ *        Copyright (C) 1994, 1996, 1998, 1999,
+ *                    2000, 2001 Free Software Foundation, Inc.
+ *
+ * This file is part of GNUPG.
+ *
+ * GNUPG is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * GNUPG is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ *
+ * Note: This code is heavily based on the GNU MP Library.
+ *         Actually it's the same code with only minor changes in the
+ *         way the data is stored; this is to support the abstraction
+ *         of an optional secure memory allocation which may be used
+ *         to avoid revealing of sensitive data due to paging etc.
+ *         The GNU MP Library itself is published under the LGPL;
+ *         however I decided to publish this code under the plain GPL.
+ */
+
+#ifndef MPI_H
+#define MPI_H
+
+#include 
+
+#define BYTES_PER_MPI_LIMB      (BITS_PER_LONG / 8)
+#define BITS_PER_MPI_LIMB       BITS_PER_LONG
+
+typedef unsigned long int mpi_limb_t;
+typedef signed long int mpi_limb_signed_t;
+
+struct mpi {
+    int alloced;        /* array size (# of allocated limbs) */
+    int nlimbs;         /* number of valid limbs */
+    int nbits;          /* the real number of valid bits (info only) */
+    int sign;           /* indicates a negative number */
+    unsigned flags;     /* bit 0: array must be allocated in secure memory space */
+    /* bit 1: not used */
+    /* bit 2: the limb is a pointer to some m_alloced data */
+    mpi_limb_t *d;      /* array with the limbs */
+};
+
+typedef struct mpi *MPI;
+
+MPI mpi_alloc(unsigned nlimbs);
+void mpi_free(MPI a);
+MPI mpi_read_raw_data(const void *xbuffer, size_t nbytes);
+int mpi_powm(MPI res, MPI base, MPI exp, MPI mod);
+int mpi_cmp_ui(MPI u, unsigned long v);
+int mpi_cmp(MPI u, MPI v);
+unsigned mpi_get_nbits(MPI a);
+int mpi_test_bit(MPI a, unsigned int n);
+
+#endif /* MPI_H */
diff --git a/xen/include/xen/rsa.h b/xen/include/xen/rsa.h
new file mode 100644
index 000000000000..13b5ebe9a1e6
--- /dev/null
+++ b/xen/include/xen/rsa.h
@@ -0,0 +1,72 @@
+/* rsa.h
+
+   The RSA publickey algorithm.
+
+   Copyright (C) 2001, 2002 Niels Möller
+
+   This file is part of GNU Nettle.
+
+   GNU Nettle is free software: you can redistribute it and/or
+   modify it under the terms of either:
+
+     * the GNU Lesser General Public License as published by the Free
+       Software Foundation; either version 3 of the License, or (at your
+       option) any later version.
+
+   or
+
+     * the GNU General Public License as published by the Free
+       Software Foundation; either version 2 of the License, or (at your
+       option) any later version.
+
+   or both in parallel, as here.
+
+   GNU Nettle is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received copies of the GNU General Public License and
+   the GNU Lesser General Public License along with this program.  If
+   not, see http://www.gnu.org/licenses/.
+*/
+ 
+#ifndef RSA_H
+#define RSA_H
+
+#include 
+#include 
+#include 
+
+/*
+ * This limit is somewhat arbitrary. Technically, the smallest modulo
+ * which makes sense at all is 15 = 3*5, phi(15) = 8, size 4 bits. But
+ * for ridiculously small keys, not all odd e are possible (e.g., for
+ * 5 bits, the only possible modulo is 3*7 = 21, phi(21) = 12, and e =
+ * 3 don't work). The smallest size that makes sense with pkcs#1, and
+ * which allows RSA encryption of one byte messages, is 12 octets, 89
+ * bits.
+ */
+#define RSA_MINIMUM_N_OCTETS 12
+#define RSA_MINIMUM_N_BITS (8 * RSA_MINIMUM_N_OCTETS - 7)
+
+struct rsa_public_key
+{
+    /*
+     * Size of the modulo, in octets. This is also the size of all
+     * signatures that are created or verified with this key.
+     */
+    size_t size;
+    MPI n; /* Modulo */
+    MPI e; /* Public exponent */
+};
+
+void rsa_public_key_init(struct rsa_public_key *key);
+
+int rsa_public_key_prepare(struct rsa_public_key *key);
+
+int rsa_sha256_verify(const struct rsa_public_key *key,
+                      struct sha2_256_state *hash,
+                      MPI signature);
+
+#endif /* RSA_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 14:33:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 14:33:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977421.1364453 (Exim 4.92)
	(envelope-from )
	id 1uCJM0-00020k-PC; Tue, 06 May 2025 14:33:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977421.1364453; Tue, 06 May 2025 14:33: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 1uCJM0-00020a-LD; Tue, 06 May 2025 14:33:04 +0000
Received: by outflank-mailman (input) for mailman id 977421;
 Tue, 06 May 2025 14:33:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCJLz-0000Q4-IR
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 14:33:03 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 03a4f1cf-2a87-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 16:33:02 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5f6c3f7b0b0so11431569a12.0
 for ; Tue, 06 May 2025 07:33:02 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1894c0356sm711598966b.100.2025.05.06.07.33.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 07:33: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" 
X-Inumbo-ID: 03a4f1cf-2a87-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746541981; x=1747146781; 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;
        bh=9eYdqxJiuFt77CPqaijLabp59oslkZaSZ7TfPtEsR98=;
        b=rkNbrQffBdiMgvGY2f+WFpJbBKFrfYAy7E4XOmJVFgCMAJFw+Y9BNTg8g/6PExjV5E
         KEwr8Qbi9Wn83g/tCDjBEfNdEDqSX6wqDOmmhsLRCXMK8zsQqbuHspuPc7GnUNRibVE3
         VJLRMBPrPwd16f90EudU5KQpxRuOCgVeMofzE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746541981; x=1747146781;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=9eYdqxJiuFt77CPqaijLabp59oslkZaSZ7TfPtEsR98=;
        b=S6GzxF7740Ip27dp497wvZvpFYZuMzepBEbL0sUltj+j0/uZ92gum5vQHVQl5ZjlyC
         /o/SU4tk10S9qnFy9Nv0Rgjje2Eh0ITb1T+dpulnZEUNug6KWGaHkoWKoVWYwMpTvNdK
         gKJYYULCwXROkwH9jfbJYl+BbmZ24dEHVRdXXkJn1tzYDXggiGCRGiHTYGUtfhxSQL4l
         HJVQVKcNDEKBgZsGBjWYlZnlLayW+e2BkKqVvwNXsGU2sh3MMprNVK/q9N1w5VJk6CPR
         y6qALzghra+RNNRG7dnyF3BoBWUEclBowFUUME4h+hqs32uu51EiI/dXBpPEoNhDksmg
         Itsg==
X-Forwarded-Encrypted: i=1; AJvYcCWgrotcDVSJqDTc8Fpm0C0INGL9+ximYYTy954uUCLyh/wDCK2JT0iPww/LoRz8Vtnq+rDGqc1TvFg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy0M6eSmBflpkXw0oCBYnNEeGAiyWEnv/mUUOLrcedkyeOrepKn
	SEf1RuhPJtY+0Snfs9qviaeMnynfJbO3rtP0KnneFEgdBV7IAS92othsedLyRw==
X-Gm-Gg: ASbGncvZl0D5Me/wCM9aMW45Yf5k20PD/bqezsrfG6SECHQs8RDIxy/rDyZaHbgtGlr
	VbEFYKIp7dUhqSE6JtxqJYZyq9ckvgjg9bofBiAiZod7R3X0LXrGOQ0z4xPKMM6s2xTOhoAYOvO
	WoQdxh2ykh2B5hATFI1VHr/kQUcKxgUrY1gplLB5TeHNaWzNUS0J+LPGYWPIGrr2Nvoyu+zHk6z
	ImQnSc0PPlkfYfLp8O58oTqtneeuuQPUmfn6PQ9WwU2htbhuCKCOVe/KgNdp1NTDuF43YOCTnUy
	dHxZxDnc+XWARbC4SOmHNtovDmtPsvccbtcWCX/HbaOhPP+w1YfhywyMpdTg4bVE
X-Google-Smtp-Source: AGHT+IEiXGDQDlvPzzGzGCTZWf6cD7XqhHvy9Fd20UQ8ONMR3GNj0HjnJ8ERzNht3teHeTivvJGHcA==
X-Received: by 2002:a17:907:3d8c:b0:acb:4f4a:cbd0 with SMTP id a640c23a62f3a-ad17b5ad337mr1566316466b.14.1746541981299;
        Tue, 06 May 2025 07:33:01 -0700 (PDT)
From: Ross Lagerwall 
To: Xen-devel ,
	xen-devel@lists.xenproject.org
Cc: Kevin Lampis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Ross Lagerwall 
Subject: [PATCH 3/4] livepatch: Embed public key in Xen
Date: Tue,  6 May 2025 15:32:15 +0100
Message-ID: <20250506143218.1782603-4-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Kevin Lampis 

Make it possible to embed a public key in Xen to be used when verifying
live patch payloads. Inclusion of the public key is optional.

To avoid needing to include a DER / X.509 parser in the hypervisor, the
public key is unpacked at build time and included in a form that is
convenient for the hypervisor to consume. This is different approach
from that used by Linux which embeds the entire X.509 certificate and
builds in a parser for it.

A suitable key can be created using openssl:

openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \
    -sha256 -days 3650 -nodes \
    -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out crypto/signing_key.pem

Signed-off-by: Kevin Lampis 
Signed-off-by: Ross Lagerwall 
---
 xen/common/Kconfig       | 18 ++++++++++++++++++
 xen/common/Makefile      |  2 +-
 xen/common/livepatch.c   | 41 ++++++++++++++++++++++++++++++++++++++++
 xen/crypto/Makefile      | 14 +++++++++++++-
 xen/tools/extract-key.py | 37 ++++++++++++++++++++++++++++++++++++
 5 files changed, 110 insertions(+), 2 deletions(-)
 create mode 100755 xen/tools/extract-key.py

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 4bec78c6f267..e3e4fe2f3477 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -481,6 +481,24 @@ config LIVEPATCH
 
 	  If unsure, say Y.
 
+config PAYLOAD_SIGNING
+	bool "Verify signed LivePatch payloads"
+	depends on LIVEPATCH
+	select CRYPTO
+	help
+	  Verify signed LivePatch payloads using an RSA public key built
+	  into the Xen hypervisor. Selecting this option requires a
+	  public key in PEM format to be available for embedding during
+	  the build.
+
+config PAYLOAD_SIG_KEY
+	string "File name of payload signing public key"
+	default "signing_key.pem"
+	depends on PAYLOAD_SIGNING
+	help
+	  The file name of an RSA public key in PEM format to be used for
+	  verifying signed LivePatch payloads.
+
 config FAST_SYMBOL_LOOKUP
 	bool "Fast symbol lookup (bigger binary)"
 	default y
diff --git a/xen/common/Makefile b/xen/common/Makefile
index ece6548bb072..c75cbfa868a0 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-y += memory.o
-obj-y += mpi.o
+obj-$(CONFIG_PAYLOAD_SIGNING) += mpi.o
 obj-y += multicall.o
 obj-y += notifier.o
 obj-$(CONFIG_NUMA) += numa.o
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index be9b7e367553..947d05671b4f 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -73,6 +75,12 @@ static struct livepatch_work livepatch_work;
 static DEFINE_PER_CPU(bool, work_to_do);
 static DEFINE_PER_CPU(struct tasklet, livepatch_tasklet);
 
+#ifdef CONFIG_PAYLOAD_SIGNING
+/* The public key contained with Xen used to verify payload signatures. */
+extern const uint8_t xen_livepatch_key_data[];
+static struct rsa_public_key builtin_payload_key;
+#endif
+
 static int get_name(const struct xen_livepatch_name *name, char *n)
 {
     if ( !name->size || name->size > XEN_LIVEPATCH_NAME_SIZE )
@@ -2287,6 +2295,34 @@ static void cf_check livepatch_printall(unsigned char key)
     spin_unlock(&payload_lock);
 }
 
+#ifdef CONFIG_PAYLOAD_SIGNING
+static int __init load_builtin_payload_key(void)
+{
+    const uint8_t *ptr;
+    uint32_t len;
+
+    rsa_public_key_init(&builtin_payload_key);
+
+    ptr = xen_livepatch_key_data;
+
+    memcpy(&len, ptr, sizeof(len));
+    ptr += sizeof(len);
+    builtin_payload_key.n = mpi_read_raw_data(ptr, len);
+    ptr += len;
+
+    memcpy(&len, ptr, sizeof(len));
+    ptr += sizeof(len);
+    builtin_payload_key.e = mpi_read_raw_data(ptr, len);
+
+    return rsa_public_key_prepare(&builtin_payload_key);
+}
+#else
+static int __init load_builtin_payload_key(void)
+{
+    return 0;
+}
+#endif
+
 static int cf_check cpu_callback(
     struct notifier_block *nfb, unsigned long action, void *hcpu)
 {
@@ -2305,6 +2341,11 @@ static struct notifier_block cpu_nfb = {
 static int __init cf_check livepatch_init(void)
 {
     unsigned int cpu;
+    int err;
+
+    err = load_builtin_payload_key();
+    if (err)
+        return err;
 
     for_each_online_cpu ( cpu )
     {
diff --git a/xen/crypto/Makefile b/xen/crypto/Makefile
index d88374ddf221..e81302d7cd54 100644
--- a/xen/crypto/Makefile
+++ b/xen/crypto/Makefile
@@ -1,3 +1,15 @@
 obj-y += rijndael.o
-obj-y += rsa.o
+obj-$(CONFIG_PAYLOAD_SIGNING) += rsa.o
 obj-y += vmac.o
+
+obj-$(CONFIG_PAYLOAD_SIGNING) += builtin_payload_key.o
+
+ifeq ($(CONFIG_PAYLOAD_SIGNING),y)
+key_path := $(srctree)/crypto/$(patsubst "%",%,$(CONFIG_PAYLOAD_SIG_KEY))
+$(obj)/builtin_payload_key.bin: $(key_path) $(srctree)/tools/extract-key.py
+	$(srctree)/tools/extract-key.py < $< > $@.new
+	$(call move-if-changed,$@.new,$@)
+
+$(obj)/builtin_payload_key.S: $(srctree)/tools/binfile $(obj)/builtin_payload_key.bin FORCE
+	$(call if_changed,binfile,$(obj)/builtin_payload_key.bin xen_livepatch_key_data)
+endif
diff --git a/xen/tools/extract-key.py b/xen/tools/extract-key.py
new file mode 100755
index 000000000000..2980264b757d
--- /dev/null
+++ b/xen/tools/extract-key.py
@@ -0,0 +1,37 @@
+#!/usr/bin/env python3
+
+# SPDX-License-Identifier: GPL-2.0
+
+import binascii
+import struct
+import sys
+import subprocess
+import re
+
+# Decode a certificate into a format suitable for embedding in Xen.
+
+out = subprocess.check_output(['openssl', 'rsa', '-pubin', '-inform', 'PEM',
+                               '-noout', '-text'], stdin=sys.stdin,
+                               universal_newlines=True)
+combined = ''
+for line in out.split('\n'):
+    line = line.rstrip()
+    if line.startswith('    '):
+        combined += line.strip().replace(':', '')
+    match = re.match(r'Exponent: .* \(0x(.*)\)', line)
+    if match:
+        e = match.group(1)
+
+n = combined.lstrip('0')
+if len(n) % 2 == 1:
+    n = '0' + n
+n = binascii.unhexlify(n)
+e = e.lstrip('0')
+if len(e) % 2 == 1:
+    e = '0' + e
+e = binascii.unhexlify(e)
+
+sys.stdout.buffer.write(struct.pack('I', len(n)))
+sys.stdout.buffer.write(n)
+sys.stdout.buffer.write(struct.pack('I', len(e)))
+sys.stdout.buffer.write(e)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 14:33:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 14:33:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977422.1364458 (Exim 4.92)
	(envelope-from )
	id 1uCJM1-00024A-3S; Tue, 06 May 2025 14:33:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977422.1364458; Tue, 06 May 2025 14:33: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 1uCJM0-00023h-VT; Tue, 06 May 2025 14:33:04 +0000
Received: by outflank-mailman (input) for mailman id 977422;
 Tue, 06 May 2025 14:33:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCJLz-0000Q4-Qm
 for xen-devel@lists.xen.org; Tue, 06 May 2025 14:33:03 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 03d7f82e-2a87-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 16:33:02 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ad1d1f57a01so267621066b.2
 for ; Tue, 06 May 2025 07:33:02 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1894c0356sm711598966b.100.2025.05.06.07.33.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 07:33: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" 
X-Inumbo-ID: 03d7f82e-2a87-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746541981; x=1747146781; darn=lists.xen.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;
        bh=9eYdqxJiuFt77CPqaijLabp59oslkZaSZ7TfPtEsR98=;
        b=RG8Tko5AN79qhEwbcEXi2O/naV+30YqIqq//N68nl99Ti1IOE8+YYKc98K9sxzWRrg
         LKU36Zm7qnMwdJGlFt8xQ2LMtqlFqb/LG45MrpclchRLzg6D1HM8ChwjjIDXg9wpKCcV
         CTWPeEuZuJ40XFVBT0m8jrPON5layqLHCa6yA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746541981; x=1747146781;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=9eYdqxJiuFt77CPqaijLabp59oslkZaSZ7TfPtEsR98=;
        b=Ag8QwmyOhfoSAh2Lud0PkZWbuVbIczKxDZPyEOtyr5T+wGFCQ9kleih6X9VrPfdAAd
         zPA8X2zAZ2N+GipUmTZRDpFtVCmORAb3qMt10hmR7phgFscnVoGel4zcUecdo7EPXfyu
         0HYvjaV85t2xE4IiSqbYq5/y86QtqL36VEGKxfiTYNWCnw4xQmdNFU4AXvRHGdQybarq
         zpV63mT0MMPFQm9Ju71gWLUp3f93cV2a45k3Rf2YJsjKWf/6ARtrTq9Td6jFXLvRajtw
         NyaHbQEJTQPIv5ncpG7wWSDTzpT+WNm8mattaOlxfetFD4tA1glO/z1HQMaPr6smo96Q
         7Q6A==
X-Gm-Message-State: AOJu0Yw7qFYDyBwXXRjo65uARfx2DlCWDlkrDeAXWQYF7fS7N3ls1EpW
	LnLWGGzWR1uLGMtreFDlxcbPu6VkWqlTp5WGVmRDRqaqCZ5W6GTZLr53DgONA5sQOBgew9B7YPQ
	=
X-Gm-Gg: ASbGncuP7mizN/bmggUVhSvy47SV/rDiExgTcUH7T1vRQBayYQ8KY13Cayz0RC/SA1A
	/l2mBml2aAIUkz2k1TaQSUy3e5BM8/va0Aj4TEkPIhefxY0fFfdvfao03Z3LG8zVnF8kAqOKa7L
	Hsf/fNtyTqCArFLl6pNS3N6BYkylInxXBS3qYfo2VaDlsjcTPvkizmAM+MeBjcsV9ihj0nW8yhG
	KWDwPhuUePR6WvpYTB7+5nYJc5jvXuFfdLVGSfeUwbmvlH7EHbuRxsIqkRDZy81+W0HpcSQ8bFX
	d1gOMlVxLq6VW3pCI1ksxqwR2ETXBcdvZclPRHWy/plz7G6QsteSEQf0ctGTcsS2
X-Google-Smtp-Source: AGHT+IEiXGDQDlvPzzGzGCTZWf6cD7XqhHvy9Fd20UQ8ONMR3GNj0HjnJ8ERzNht3teHeTivvJGHcA==
X-Received: by 2002:a17:907:3d8c:b0:acb:4f4a:cbd0 with SMTP id a640c23a62f3a-ad17b5ad337mr1566316466b.14.1746541981299;
        Tue, 06 May 2025 07:33:01 -0700 (PDT)
From: Ross Lagerwall 
To: Xen-devel ,
	xen-devel@lists.xenproject.org
Cc: Kevin Lampis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Ross Lagerwall 
Subject: [PATCH 3/4] livepatch: Embed public key in Xen
Date: Tue,  6 May 2025 15:32:15 +0100
Message-ID: <20250506143218.1782603-4-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Kevin Lampis 

Make it possible to embed a public key in Xen to be used when verifying
live patch payloads. Inclusion of the public key is optional.

To avoid needing to include a DER / X.509 parser in the hypervisor, the
public key is unpacked at build time and included in a form that is
convenient for the hypervisor to consume. This is different approach
from that used by Linux which embeds the entire X.509 certificate and
builds in a parser for it.

A suitable key can be created using openssl:

openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \
    -sha256 -days 3650 -nodes \
    -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out crypto/signing_key.pem

Signed-off-by: Kevin Lampis 
Signed-off-by: Ross Lagerwall 
---
 xen/common/Kconfig       | 18 ++++++++++++++++++
 xen/common/Makefile      |  2 +-
 xen/common/livepatch.c   | 41 ++++++++++++++++++++++++++++++++++++++++
 xen/crypto/Makefile      | 14 +++++++++++++-
 xen/tools/extract-key.py | 37 ++++++++++++++++++++++++++++++++++++
 5 files changed, 110 insertions(+), 2 deletions(-)
 create mode 100755 xen/tools/extract-key.py

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 4bec78c6f267..e3e4fe2f3477 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -481,6 +481,24 @@ config LIVEPATCH
 
 	  If unsure, say Y.
 
+config PAYLOAD_SIGNING
+	bool "Verify signed LivePatch payloads"
+	depends on LIVEPATCH
+	select CRYPTO
+	help
+	  Verify signed LivePatch payloads using an RSA public key built
+	  into the Xen hypervisor. Selecting this option requires a
+	  public key in PEM format to be available for embedding during
+	  the build.
+
+config PAYLOAD_SIG_KEY
+	string "File name of payload signing public key"
+	default "signing_key.pem"
+	depends on PAYLOAD_SIGNING
+	help
+	  The file name of an RSA public key in PEM format to be used for
+	  verifying signed LivePatch payloads.
+
 config FAST_SYMBOL_LOOKUP
 	bool "Fast symbol lookup (bigger binary)"
 	default y
diff --git a/xen/common/Makefile b/xen/common/Makefile
index ece6548bb072..c75cbfa868a0 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-y += memory.o
-obj-y += mpi.o
+obj-$(CONFIG_PAYLOAD_SIGNING) += mpi.o
 obj-y += multicall.o
 obj-y += notifier.o
 obj-$(CONFIG_NUMA) += numa.o
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index be9b7e367553..947d05671b4f 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -73,6 +75,12 @@ static struct livepatch_work livepatch_work;
 static DEFINE_PER_CPU(bool, work_to_do);
 static DEFINE_PER_CPU(struct tasklet, livepatch_tasklet);
 
+#ifdef CONFIG_PAYLOAD_SIGNING
+/* The public key contained with Xen used to verify payload signatures. */
+extern const uint8_t xen_livepatch_key_data[];
+static struct rsa_public_key builtin_payload_key;
+#endif
+
 static int get_name(const struct xen_livepatch_name *name, char *n)
 {
     if ( !name->size || name->size > XEN_LIVEPATCH_NAME_SIZE )
@@ -2287,6 +2295,34 @@ static void cf_check livepatch_printall(unsigned char key)
     spin_unlock(&payload_lock);
 }
 
+#ifdef CONFIG_PAYLOAD_SIGNING
+static int __init load_builtin_payload_key(void)
+{
+    const uint8_t *ptr;
+    uint32_t len;
+
+    rsa_public_key_init(&builtin_payload_key);
+
+    ptr = xen_livepatch_key_data;
+
+    memcpy(&len, ptr, sizeof(len));
+    ptr += sizeof(len);
+    builtin_payload_key.n = mpi_read_raw_data(ptr, len);
+    ptr += len;
+
+    memcpy(&len, ptr, sizeof(len));
+    ptr += sizeof(len);
+    builtin_payload_key.e = mpi_read_raw_data(ptr, len);
+
+    return rsa_public_key_prepare(&builtin_payload_key);
+}
+#else
+static int __init load_builtin_payload_key(void)
+{
+    return 0;
+}
+#endif
+
 static int cf_check cpu_callback(
     struct notifier_block *nfb, unsigned long action, void *hcpu)
 {
@@ -2305,6 +2341,11 @@ static struct notifier_block cpu_nfb = {
 static int __init cf_check livepatch_init(void)
 {
     unsigned int cpu;
+    int err;
+
+    err = load_builtin_payload_key();
+    if (err)
+        return err;
 
     for_each_online_cpu ( cpu )
     {
diff --git a/xen/crypto/Makefile b/xen/crypto/Makefile
index d88374ddf221..e81302d7cd54 100644
--- a/xen/crypto/Makefile
+++ b/xen/crypto/Makefile
@@ -1,3 +1,15 @@
 obj-y += rijndael.o
-obj-y += rsa.o
+obj-$(CONFIG_PAYLOAD_SIGNING) += rsa.o
 obj-y += vmac.o
+
+obj-$(CONFIG_PAYLOAD_SIGNING) += builtin_payload_key.o
+
+ifeq ($(CONFIG_PAYLOAD_SIGNING),y)
+key_path := $(srctree)/crypto/$(patsubst "%",%,$(CONFIG_PAYLOAD_SIG_KEY))
+$(obj)/builtin_payload_key.bin: $(key_path) $(srctree)/tools/extract-key.py
+	$(srctree)/tools/extract-key.py < $< > $@.new
+	$(call move-if-changed,$@.new,$@)
+
+$(obj)/builtin_payload_key.S: $(srctree)/tools/binfile $(obj)/builtin_payload_key.bin FORCE
+	$(call if_changed,binfile,$(obj)/builtin_payload_key.bin xen_livepatch_key_data)
+endif
diff --git a/xen/tools/extract-key.py b/xen/tools/extract-key.py
new file mode 100755
index 000000000000..2980264b757d
--- /dev/null
+++ b/xen/tools/extract-key.py
@@ -0,0 +1,37 @@
+#!/usr/bin/env python3
+
+# SPDX-License-Identifier: GPL-2.0
+
+import binascii
+import struct
+import sys
+import subprocess
+import re
+
+# Decode a certificate into a format suitable for embedding in Xen.
+
+out = subprocess.check_output(['openssl', 'rsa', '-pubin', '-inform', 'PEM',
+                               '-noout', '-text'], stdin=sys.stdin,
+                               universal_newlines=True)
+combined = ''
+for line in out.split('\n'):
+    line = line.rstrip()
+    if line.startswith('    '):
+        combined += line.strip().replace(':', '')
+    match = re.match(r'Exponent: .* \(0x(.*)\)', line)
+    if match:
+        e = match.group(1)
+
+n = combined.lstrip('0')
+if len(n) % 2 == 1:
+    n = '0' + n
+n = binascii.unhexlify(n)
+e = e.lstrip('0')
+if len(e) % 2 == 1:
+    e = '0' + e
+e = binascii.unhexlify(e)
+
+sys.stdout.buffer.write(struct.pack('I', len(n)))
+sys.stdout.buffer.write(n)
+sys.stdout.buffer.write(struct.pack('I', len(e)))
+sys.stdout.buffer.write(e)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 14:37:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 14:37:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977450.1364473 (Exim 4.92)
	(envelope-from )
	id 1uCJQ3-0003qk-Nl; Tue, 06 May 2025 14:37:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977450.1364473; Tue, 06 May 2025 14:37:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCJQ3-0003qd-KR; Tue, 06 May 2025 14:37:15 +0000
Received: by outflank-mailman (input) for mailman id 977450;
 Tue, 06 May 2025 14:37:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCJQ2-0003qX-28
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 14:37:14 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 98b594df-2a87-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 16:37:12 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-43d07ca6a80so23137095e9.1
 for ; Tue, 06 May 2025 07:37:12 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099b17260sm14274359f8f.98.2025.05.06.07.37.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 07:37: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" 
X-Inumbo-ID: 98b594df-2a87-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746542231; x=1747147031; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=NaPnOl3C/LCF5BaQ8cp69/hEOJ4YJsEJE/eGJQ0AKkE=;
        b=eMwHD2cOGka8plkRk1hPyKWOjoGQVNAPGHHZeIC8xyr2JC2DLIMHaQAiMfjvsor/CX
         tw2RdAuhJ+uIZRhlFYYQuXgZT+4/MhO2uPtjUcI9hbUz8+sfXCWRlR35WfLLHSmeMMNO
         vaa3PE5l7KdTQbQrrBnvLWJDz2rVIvGBvRR+o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746542231; x=1747147031;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=NaPnOl3C/LCF5BaQ8cp69/hEOJ4YJsEJE/eGJQ0AKkE=;
        b=uTqqJlFcmEWpizO4elVQBLLRYKhXi0f/2wB63dacuqRc3BoYTt6GFSp8qbnxQ70Z+W
         db+b9ITE+fY2pLrCPRMg2mPwz7gJmVo2LrrsFGqgw0y6DtqqN+0DoLVNt9FP75SEgzoy
         B9QegTcTjX1Epo+REwpyfTEjRTlpHGIrNCFKDH9V1RcOCgeoLviI3K/BN/6WWvplf/Lt
         hOd7P9CBFbeaAkXbBqt5Z5tSNxmnLrqinozY5Nw3BOP7nOCBD6iviIPk7zqL5BCm72Dd
         LXuaas2Dp1ymWdkCtCsDuSXq8ass3aQZe1c2yHPKLhuRxfH3IwSbaw6v+vQe0Dtbw81I
         uyVg==
X-Gm-Message-State: AOJu0Yx0EY2CEUWb4T7HN+9r6wPtuXcF9cJPeMBgtgv1qOx3Tk+t91Sn
	wrbug+F8mTz1f1MdNV7wViwtgIQfsoIxBFFKTyE6GdZZCfvn2BgQneH+cZRMeNw=
X-Gm-Gg: ASbGncuzobGO9DmUT76JUulLrhp/tm+xhoq1JEtRfmrQKrLZ/REUwcBUTQ9UzRun2P0
	jdekW2CuJ4CwK9GWuON1vgITxwPgGOdHJ6eTeScNNxUZhOk6GNJr7mqm9Oit2HcstdY3FeyqAfO
	U8nN36grKk64LYrXfhm9gzqdZ/k/WWWVT+F5CzFR8epTqZuUMBEPG3+MBQYLNiS1nlBy41ntoso
	jejZxFI1g67xv5x2bw8IigW4WOj8dRbbsYcQzEY01xXGk6Xtwl43+YB7TX2o2NtJb4XVEuPAsPl
	N9+yF1yXKaWaHYwBr2tMzuaVF9W5em5ZoQKnlEEjaUrP+g==
X-Google-Smtp-Source: AGHT+IEZ2ehwr9IJ+BeqMFt489WJ6ggqJvhgYMqndf5EAezS7pcvZLjvQKOaBVk6I27nKnDZqWo+ig==
X-Received: by 2002:a05:600c:b99:b0:43c:ea1a:720a with SMTP id 5b1f17b1804b1-441d04f458emr28299175e9.1.1746542231411;
        Tue, 06 May 2025 07:37:11 -0700 (PDT)
Date: Tue, 6 May 2025 16:37:10 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v3 05/11] vpci: Refactor REGISTER_VPCI_INIT
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-6-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250421061903.1542652-6-Jiqian.Chen@amd.com>

On Mon, Apr 21, 2025 at 02:18:57PM +0800, Jiqian Chen wrote:
> Refactor REGISTER_VPCI_INIT to contain more capability specific
> information, this is benifit for follow-on changes to hide capability
> which initialization fails.
> 
> What's more, change the definition of init_header() since it is
> not a capability and it is needed for all devices' PCI config space.
> 
> Note:
> Call vpci_make_msix_hole() in the end of init_msix() since the
> change of sequence of init_header() and init_msix().
> The fini hook will be implemented in follow-on changes.

I would maybe add that the cleanup hook is also added in this change,
even if it's still unused.  Further changes will make use of it.

> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> cc: Andrew Cooper 
> cc: Anthony PERARD 
> cc: Michal Orzel 
> cc: Jan Beulich 
> cc: Julien Grall 
> cc: Stefano Stabellini 
> ---
> v2->v3 changes:
> * This is separated from patch "vpci: Hide capability when it fails to initialize" of v2.
> * Delete __maybe_unused attribute of "out" in function vpci_assign_devic().
> * Rename REGISTER_VPCI_EXTEND_CAP to REGISTER_VPCI_EXTENDED_CAP.
> 
> v1->v2 changes:
> * Removed the "priorities" of initializing capabilities since it isn't used anymore.
> * Added new function vpci_capability_mask() and vpci_ext_capability_mask() to remove failed capability from list.
> * Called vpci_make_msix_hole() in the end of init_msix().
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/header.c |  3 +--
>  xen/drivers/vpci/msi.c    |  2 +-
>  xen/drivers/vpci/msix.c   |  8 +++++--
>  xen/drivers/vpci/rebar.c  |  2 +-
>  xen/drivers/vpci/vpci.c   | 48 +++++++++++++++++++++++++++++++--------
>  xen/include/xen/vpci.h    | 28 ++++++++++++++++-------
>  xen/include/xen/xen.lds.h |  2 +-
>  7 files changed, 68 insertions(+), 25 deletions(-)
> 
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index ee94ad8e5037..afe4bcdfcb30 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -842,7 +842,7 @@ static int vpci_init_ext_capability_list(struct pci_dev *pdev)
>      return 0;
>  }
>  
> -static int cf_check init_header(struct pci_dev *pdev)
> +int vpci_init_header(struct pci_dev *pdev)
>  {
>      uint16_t cmd;
>      uint64_t addr, size;
> @@ -1038,7 +1038,6 @@ static int cf_check init_header(struct pci_dev *pdev)
>      pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd);
>      return rc;
>  }
> -REGISTER_VPCI_INIT(init_header, VPCI_PRIORITY_MIDDLE);
>  
>  /*
>   * Local variables:
> diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
> index 66e5a8a116be..ea7dc0c060ea 100644
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -270,7 +270,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
>  
>      return 0;
>  }
> -REGISTER_VPCI_INIT(init_msi, VPCI_PRIORITY_LOW);
> +REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSI, init_msi, NULL);
>  
>  void vpci_dump_msi(void)
>  {
> diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
> index 6bd8c55bb48e..0228ffd9fda9 100644
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -751,9 +751,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
>      pdev->vpci->msix = msix;
>      list_add(&msix->next, &d->arch.hvm.msix_tables);
>  
> -    return 0;
> +    spin_lock(&pdev->vpci->lock);
> +    rc = vpci_make_msix_hole(pdev);
> +    spin_unlock(&pdev->vpci->lock);
> +
> +    return rc;
>  }
> -REGISTER_VPCI_INIT(init_msix, VPCI_PRIORITY_HIGH);
> +REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSIX, init_msix, NULL);
>  
>  /*
>   * Local variables:
> diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
> index 793937449af7..026f8f7972d9 100644
> --- a/xen/drivers/vpci/rebar.c
> +++ b/xen/drivers/vpci/rebar.c
> @@ -118,7 +118,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
>  
>      return 0;
>  }
> -REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
> +REGISTER_VPCI_EXTENDED_CAP(PCI_EXT_CAP_ID_REBAR, init_rebar, NULL);
>  
>  /*
>   * Local variables:
> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> index 3349b98389b8..5474b66668c1 100644
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -36,8 +36,8 @@ struct vpci_register {
>  };
>  
>  #ifdef __XEN__
> -extern vpci_register_init_t *const __start_vpci_array[];
> -extern vpci_register_init_t *const __end_vpci_array[];
> +extern vpci_capability_t *const __start_vpci_array[];
> +extern vpci_capability_t *const __end_vpci_array[];
>  #define NUM_VPCI_INIT (__end_vpci_array - __start_vpci_array)
>  
>  #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
> @@ -83,6 +83,36 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
>  
>  #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>  
> +static int vpci_init_capabilities(struct pci_dev *pdev)
> +{
> +    for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
> +    {
> +        const vpci_capability_t *capability = __start_vpci_array[i];
> +        const unsigned int cap = capability->id;
> +        const bool is_ext = capability->is_ext;
> +        unsigned int pos;
> +        int rc;
> +
> +        if ( !is_hardware_domain(pdev->domain) && is_ext )
> +            continue;
> +
> +        if ( !is_ext )
> +            pos = pci_find_cap_offset(pdev->sbdf, cap);
> +        else
> +            pos = pci_find_ext_capability(pdev->sbdf, cap);
> +
> +        if ( !pos || !capability->init )

Isn't it bogus to have a vpci_capability_t entry with a NULL init
function?

> +            continue;
> +
> +        rc = capability->init(pdev);
> +

I wouldn't add a newline between the function call and checking the
return value, but that's just my taste.

> +        if ( rc )
> +            return rc;
> +    }
> +
> +    return 0;
> +}
> +
>  void vpci_deassign_device(struct pci_dev *pdev)
>  {
>      unsigned int i;
> @@ -128,7 +158,6 @@ void vpci_deassign_device(struct pci_dev *pdev)
>  
>  int vpci_assign_device(struct pci_dev *pdev)
>  {
> -    unsigned int i;
>      const unsigned long *ro_map;
>      int rc = 0;
>  
> @@ -159,14 +188,13 @@ int vpci_assign_device(struct pci_dev *pdev)
>          goto out;
>  #endif
>  
> -    for ( i = 0; i < NUM_VPCI_INIT; i++ )
> -    {
> -        rc = __start_vpci_array[i](pdev);
> -        if ( rc )
> -            break;
> -    }
> +    rc = vpci_init_header(pdev);
> +    if ( rc )
> +        goto out;
> +
> +    rc = vpci_init_capabilities(pdev);
>  
> - out: __maybe_unused;
> + out:
>      if ( rc )
>          vpci_deassign_device(pdev);
>  
> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
> index 9d47b8c1a50e..8e815b418b7d 100644
> --- a/xen/include/xen/vpci.h
> +++ b/xen/include/xen/vpci.h
> @@ -13,11 +13,12 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev, unsigned int reg,
>  typedef void vpci_write_t(const struct pci_dev *pdev, unsigned int reg,
>                            uint32_t val, void *data);
>  
> -typedef int vpci_register_init_t(struct pci_dev *dev);
> -
> -#define VPCI_PRIORITY_HIGH      "1"
> -#define VPCI_PRIORITY_MIDDLE    "5"
> -#define VPCI_PRIORITY_LOW       "9"
> +typedef struct {
> +    unsigned int id;
> +    bool is_ext;
> +    int (*init)(struct pci_dev *pdev);
> +    void (*fini)(struct pci_dev *pdev);
> +} vpci_capability_t;
>  
>  #define VPCI_ECAM_BDF(addr)     (((addr) & 0x0ffff000) >> 12)
>  
> @@ -29,9 +30,20 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
>   */
>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>  
> -#define REGISTER_VPCI_INIT(x, p)                \
> -  static vpci_register_init_t *const x##_entry  \
> -               __used_section(".data.vpci." p) = (x)
> +#define REGISTER_VPCI_CAP(cap, x, y, ext) \

x and y are not very helpful identifier names, better use some more
descriptive naming, init and fini?  Same below.

> +  static vpci_capability_t x##_t = { \
> +        .id = (cap), \
> +        .init = (x), \
> +        .fini = (y), \
> +        .is_ext = (ext), \
> +  }; \
> +  static vpci_capability_t *const x##_entry  \
> +               __used_section(".data.vpci.") = &(x##_t)
> +
> +#define REGISTER_VPCI_LEGACY_CAP(cap, x, y) REGISTER_VPCI_CAP(cap, x, y, false)
> +#define REGISTER_VPCI_EXTENDED_CAP(cap, x, y) REGISTER_VPCI_CAP(cap, x, y, true)
> +
> +int __must_check vpci_init_header(struct pci_dev *pdev);
>  
>  /* Assign vPCI to device by adding handlers. */
>  int __must_check vpci_assign_device(struct pci_dev *pdev);
> diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
> index 16a9b1ba03db..c73222112dd3 100644
> --- a/xen/include/xen/xen.lds.h
> +++ b/xen/include/xen/xen.lds.h
> @@ -187,7 +187,7 @@
>  #define VPCI_ARRAY               \
>         . = ALIGN(POINTER_ALIGN); \
>         __start_vpci_array = .;   \
> -       *(SORT(.data.vpci.*))     \
> +       *(.data.vpci.*)     \

Aside from Jan comment, please keep the '\' aligned with the others on
the block.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 16:00:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:00:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977500.1364483 (Exim 4.92)
	(envelope-from )
	id 1uCKiM-0001GB-KF; Tue, 06 May 2025 16:00:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977500.1364483; Tue, 06 May 2025 16:00:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCKiM-0001G4-HB; Tue, 06 May 2025 16:00:14 +0000
Received: by outflank-mailman (input) for mailman id 977500;
 Tue, 06 May 2025 16:00:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCKiL-0001Fu-SU
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:00:13 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2efd8506-2a93-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:00:08 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-440685d6afcso51526385e9.0
 for ; Tue, 06 May 2025 09:00:08 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441b89d1358sm175278315e9.10.2025.05.06.09.00.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:00: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" 
X-Inumbo-ID: 2efd8506-2a93-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746547208; x=1747152008; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=/j7jbN9Fkwr9tloBRTb3BOtshwMRSAZH4Egv3TbRy5A=;
        b=qR7dkkE3k+SGscuQz11brVPVBWFQ12G7w4fCQCrDjd7VgE0J8FypGCtS1oiQQsnRak
         /KiT8rOo4CNJ4I0uBhhYzbfJeGW6X5ql46/DdpEQu0U0e3v2T3faiwDKvIyl8eaGxb50
         oy8RM6YtNY7avZLj3+Q1c9PgCCUN0KcAR++bs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746547208; x=1747152008;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=/j7jbN9Fkwr9tloBRTb3BOtshwMRSAZH4Egv3TbRy5A=;
        b=q7s2bnLh+EMgbjXxbciaCJlR1WoTeJPfq5RKVLBkd+xPEvib6MvyYYA4XCbJyR4P42
         sdbGilVHFa0YDN5ebO+OqVasWeIX46900eqkIUlzKW5N3c++V/YRcCF3HCvhmOQeJUFi
         r1ZmFkyyao/NXPQVFf0DjGzrrAllVhYeID1cnHPyAWl+XUkmGUoLzENm7faXx9WVUWsc
         koeLE7k58z3i4w2vfAmkf4PSrOqXqOXK3NmYjCAdl5wBgAZkXPzoTOHN9fZD9omLKVLI
         q+QYNAjH3k0rcwtdpE9hRdAk+sTLgQFI2iU7sh+VNHZ5c5JQcOXh8Pm2+NaA/fSiDbYv
         N/ZA==
X-Gm-Message-State: AOJu0YyWhXVKF6QN+6lJ90i87ACuwxmVzAFspcWNuGdNiciJw/XgZR/3
	cFz4P/1pm0sOkazR3hKEGpi06+r9h6xSpzISNH56oF03sAvAktGz+ZHxXjTaZ22lEJikch+X84n
	k
X-Gm-Gg: ASbGncvHiV/eJ3iHUxANA1EeScPFB8TUoS6v3pbnUUruDfNun9n/KhSPvm7ktmdayCk
	kHYlqL+cMwbFD2kc9e09QrzKUvyihD46jMYfbqt96ciOk/2/R7Ed/32Id/bGB6CctBpXxTQvTTo
	aBNIUWbvW+IhysVzxlyKFKZUvAEsVjjGo66dE8yNXl1A7vKcRzBDCem3AXIRQRZv0xnTsMAk9x4
	AbAWqKa6oBOFYsCHuUOdDkTkTJOFPNDkLn/guXr+Dt/nwd9dngQX72tCBefAESfIjlR1fbplqqE
	kWyxUz4lbL2PmrMetoUlsjHew+5L5OJbOiaTCuxMyEhnzbJW/28=
X-Google-Smtp-Source: AGHT+IGRGWJCJKEB71VsBgPTb1RB78m+iduq1PAWQTUa6UqSoBSCG4fWlBlP+mtIx9bbn2hpCJFPew==
X-Received: by 2002:a05:600c:1d8e:b0:43d:fa59:be39 with SMTP id 5b1f17b1804b1-441d054db77mr30886255e9.33.1746547207958;
        Tue, 06 May 2025 09:00:07 -0700 (PDT)
Date: Tue, 6 May 2025 18:00:06 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v3 06/11] vpci: Hide legacy capability when it fails to
 initialize
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-7-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250421061903.1542652-7-Jiqian.Chen@amd.com>

On Mon, Apr 21, 2025 at 02:18:58PM +0800, Jiqian Chen wrote:
> When vpci fails to initialize a legacy capability of device, it just
> return error instead of catching and processing exception. That makes
> the entire device unusable.

I think "catching and processing exception" is a weird terminology to
use when writing C.  It's IMo more accurate to use:

"When vpci fails to initialize a legacy capability of device, it just
returns an error and vPCI gets disabled for the whole device.  That
most likely renders the device unusable, plus possibly causing issues
to Xen itself if guest attempts to program the native MSI or MSI-X
capabilities if present."

> So, add new a function to hide legacy capability when initialization
> fails. And remove the failed legacy capability from the vpci emulated
> legacy capability list.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> ---
> v2->v3 changes:
> * Separated from the last version patch "vpci: Hide capability when it fails to initialize"
> * Whole implementation changed because last version is wrong.
>   This version adds a new helper function vpci_get_register() and uses it to get
>   target handler and previous handler from vpci->handlers, then remove the target.
> 
> v1->v2 changes:
> * Removed the "priorities" of initializing capabilities since it isn't used anymore.
> * Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
>   remove failed capability from list.
> * Called vpci_make_msix_hole() in the end of init_msix().
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/vpci.c | 133 +++++++++++++++++++++++++++++++++-------
>  1 file changed, 112 insertions(+), 21 deletions(-)
> 
> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> index 5474b66668c1..f97c7cc460a0 100644
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -35,6 +35,22 @@ struct vpci_register {
>      uint32_t rsvdz_mask;
>  };
>  
> +static int vpci_register_cmp(const struct vpci_register *r1,
> +                             const struct vpci_register *r2)
> +{
> +    /* Return 0 if registers overlap. */
> +    if ( r1->offset < r2->offset + r2->size &&
> +         r2->offset < r1->offset + r1->size )
> +        return 0;
> +    if ( r1->offset < r2->offset )
> +        return -1;
> +    if ( r1->offset > r2->offset )
> +        return 1;
> +
> +    ASSERT_UNREACHABLE();
> +    return 0;
> +}
> +
>  #ifdef __XEN__
>  extern vpci_capability_t *const __start_vpci_array[];
>  extern vpci_capability_t *const __end_vpci_array[];
> @@ -83,7 +99,91 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
>  
>  #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>  
> -static int vpci_init_capabilities(struct pci_dev *pdev)
> +static struct vpci_register *vpci_get_register(struct vpci *vpci,
> +                                               const unsigned int offset,
> +                                               const unsigned int size)

We don't usually use const attributes for scalar function parameters.

> +{
> +    const struct vpci_register r = { .offset = offset, .size = size };
> +    struct vpci_register *rm;
> +
> +    ASSERT(spin_is_locked(&vpci->lock));
> +    list_for_each_entry ( rm, &vpci->handlers, node )
> +    {
> +        int cmp = vpci_register_cmp(&r, rm);
> +
> +        if ( !cmp && rm->offset == offset && rm->size == size )
> +            return rm;
> +        if ( cmp <= 0 )
> +            break;
> +    }
> +
> +    return NULL;
> +}
> +
> +static struct vpci_register *vpci_get_previous_cap_register
> +                (struct vpci *vpci, const unsigned int offset)

The style preference here would be:

static struct vpci_register *vpci_get_previous_cap_register(
    struct vpci *vpci, unsigned int offset)
{
...

> +{
> +    uint32_t next;
> +    struct vpci_register *r;
> +
> +    if ( offset < 0x40 )

I would possibly add an ASSERT_UNREACHABLE() here, as attempting to
pass an offset below 0x40 is a sign of a bug elsewhere?

> +        return NULL;
> +
> +    r = vpci_get_register(vpci, PCI_CAPABILITY_LIST, 1);
> +    ASSERT(r);
> +
> +    next = (uint32_t)(uintptr_t)r->private;
> +    while ( next >= 0x40 && next != offset )
> +    {
> +        r = vpci_get_register(vpci, next + PCI_CAP_LIST_NEXT, 1);
> +        ASSERT(r);
> +        next = (uint32_t)(uintptr_t)r->private;
> +    }
> +
> +    if ( next < 0x40 )
> +        return NULL;
> +
> +    return r;
> +}
> +
> +static void vpci_capability_mask(struct pci_dev *pdev,

This possibly needs to return an error code, as it can fail, and just
adding ASSERTs all around seems a bit clumsy, plus we might really
want to prevent assigning the device to the domain if
vpci_capability_mask() fails for whatever reason.

> +                                 const unsigned int cap)
> +{
> +    const unsigned int offset = pci_find_cap_offset(pdev->sbdf, cap);
> +    struct vpci_register *prev_next_r, *next_r;
> +    struct vpci *vpci = pdev->vpci;
> +
> +    spin_lock(&vpci->lock);
> +    next_r = vpci_get_register(vpci, offset + PCI_CAP_LIST_NEXT, 1);
> +    if ( !next_r )
> +    {
> +        spin_unlock(&vpci->lock);
> +        return;
> +    }
> +
> +    prev_next_r = vpci_get_previous_cap_register(vpci, offset);
> +    ASSERT(prev_next_r);
> +
> +    prev_next_r->private = next_r->private;
> +
> +    if ( !is_hardware_domain(pdev->domain) )
> +    {
> +        struct vpci_register *id_r =
> +            vpci_get_register(vpci, offset + PCI_CAP_LIST_ID, 1);
> +
> +        ASSERT(id_r);
> +        /* PCI_CAP_LIST_ID register of target capability */
> +        list_del(&id_r->node);
> +        xfree(id_r);

You could use vpci_remove_register() here?

> +    }
> +
> +    /* PCI_CAP_LIST_NEXT register of target capability */
> +    list_del(&next_r->node);
> +    spin_unlock(&vpci->lock);
> +    xfree(next_r);

Here vpci_remove_register() could also be used, but it will involve
searching again for the register to remove, which is a bit pointless.

> +}
> +
> +static void vpci_init_capabilities(struct pci_dev *pdev)
>  {
>      for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
>      {
> @@ -107,10 +207,17 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
>          rc = capability->init(pdev);
>  
>          if ( rc )
> -            return rc;
> +        {
> +            if ( capability->fini )
> +                capability->fini(pdev);
> +
> +            printk(XENLOG_WARNING "%pd %pp: %s cap %u init fail rc=%d, mask it\n",

Best to split to next line:

              printk(XENLOG_WARNING
	             "%pd %pp: %s cap %u init fail rc=%d, mask it\n",

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 16:21:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:21:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977512.1364493 (Exim 4.92)
	(envelope-from )
	id 1uCL3C-0004ru-4h; Tue, 06 May 2025 16:21:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977512.1364493; Tue, 06 May 2025 16: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 1uCL3C-0004rn-1H; Tue, 06 May 2025 16:21:46 +0000
Received: by outflank-mailman (input) for mailman id 977512;
 Tue, 06 May 2025 16:21:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCL3A-0004rg-Po
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:21:44 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 30557302-2a96-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:21:39 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a07a7b4ac7so2679339f8f.2
 for ; Tue, 06 May 2025 09:21:39 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a0b05334e0sm2136442f8f.43.2025.05.06.09.21.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:21: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" 
X-Inumbo-ID: 30557302-2a96-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746548499; x=1747153299; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=NnWhjOjuuBbZCOL886FhNb6Zm1XdyugIsT8chr49ljo=;
        b=XaOZVj07rNnyvSTdAoquZvx+ejxdYS4CS6eF7K/Xe9LgYavXToasMHT+mDLgVuwRCv
         jP7o5jPb+Tc5z8Tdy1j/JsPu0rMEVRewLpyleldZ/6pxRUGgMnk2A3oPlBpBOD2wVJaF
         mC8T5z4e2GjgakhnSt7FgSsSCAgkx29jDs5oE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746548499; x=1747153299;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=NnWhjOjuuBbZCOL886FhNb6Zm1XdyugIsT8chr49ljo=;
        b=BzVruX5/r9JML9/7WvgFGY/EvVsfgqhyXjzmLzlynOLnfJTSnNmiZNPZd4HH4IZxOI
         1YGhi6YKJIzk7I9DuckhSNCBtb8nT6cabJcGeXbfvNgU5bUXBJffQohvYRZt6046+P2g
         KuN8+9tC955Rg1wdx4kPL/emcCZfz4FYCkRGJyNq5QDoUgripEXpl9yGkivJcR+/Abwb
         x0v7tLuGOPNCnTTyBQ6cONJZ8+8EqJo29liL5WaR9dHP3clfeovTiqUIhkXNqbAICMDL
         tzXMrL/ggpmunoJEVqCfBeEMF4HbaEPnXPqvKJWPitUxkJp/FxNNFLYzF+qnrD5shmXu
         WqgQ==
X-Gm-Message-State: AOJu0YyjD3CERnftsfBoM6Lp5v7Znb7ciUwF7d3vRJbmxFIacs4nDs/m
	uqkehV64XvmKa7yRsK9PpyDadrbDEJ4ob/0+HLC7q246Ngv2uuymVMdrLqcj7ms=
X-Gm-Gg: ASbGnctYx4QCB7ff4kj0FIBqgBOtiPTkGblIVN6538RV+myKUD/nPLuGeObOeF5of8b
	w0qf9DjMP4m5f6FZep7WeElPaS50Q60NeyeuN5pmpvu4guPEdqIGW7VhqhUpTvmPcceKz8DfC30
	Yf31qEKC1/rzFPSu5s7a3dBz/t1TDi8UjtYUUzgbmuzidirqK5nF90hxFnXWvWb5UebV/fSLlf3
	b4Os6KsMxQw6Opba9oSYGB5IYfMC96eEE4ILCisV/eRsiF33zzEnPm91VQUIw7BmPdrde3C57Sk
	98akCYI7Bg+GxQ7zxR6yXqDxnlN87BIek4iItiVEcy6qPcOTKJ4=
X-Google-Smtp-Source: AGHT+IFEiTydh7SpgzZNe6gjYDiE7iWWuuKKsBq0GEnluKbQ0gq2IxKiNHXZCuapmmjhy+OXqVHscQ==
X-Received: by 2002:a5d:5f56:0:b0:3a0:85b5:463b with SMTP id ffacd0b85a97d-3a0b4a238f0mr55671f8f.48.1746548498871;
        Tue, 06 May 2025 09:21:38 -0700 (PDT)
Date: Tue, 6 May 2025 18:21:37 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v3 07/11] vpci: Hide extended capability when it fails to
 initialize
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-8-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250421061903.1542652-8-Jiqian.Chen@amd.com>

On Mon, Apr 21, 2025 at 02:18:59PM +0800, Jiqian Chen wrote:
> When vpci fails to initialize a extended capability of device for dom0,
> it just return error instead of catching and processing exception. That
> makes the entire device unusable.
> 
> So, add new a function to hide extended capability when initialization
> fails. And remove the failed extended capability handler from vpci
> extended capability list.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> ---
> v2->v3 changes:
> * Separated from the last version patch "vpci: Hide capability when it fails to initialize".
> * Whole implementation changed because last version is wrong.
>   This version gets target handler and previous handler from vpci->handlers, then remove the target.
> * Note: a case in function vpci_ext_capability_mask() needs to be discussed,
>   because it may change the offset of next capability when the offset of target
>   capability is 0x100U(the first extended capability), my implementation is just to
>   ignore and let hardware to handle the target capability.
> 
> v1->v2 changes:
> * Removed the "priorities" of initializing capabilities since it isn't used anymore.
> * Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
>   remove failed capability from list.
> * Called vpci_make_msix_hole() in the end of init_msix().
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/vpci.c    | 79 ++++++++++++++++++++++++++++++++++++++
>  xen/include/xen/pci_regs.h |  1 +
>  2 files changed, 80 insertions(+)
> 
> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> index f97c7cc460a0..8ff5169bdd18 100644
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -183,6 +183,83 @@ static void vpci_capability_mask(struct pci_dev *pdev,
>      xfree(next_r);
>  }
>  
> +static struct vpci_register *vpci_get_previous_ext_cap_register
> +                (struct vpci *vpci, const unsigned int offset)
> +{
> +    uint32_t header;
> +    unsigned int pos = PCI_CFG_SPACE_SIZE;
> +    struct vpci_register *r;
> +
> +    if ( offset <= PCI_CFG_SPACE_SIZE )
> +        return NULL;
> +
> +    r = vpci_get_register(vpci, pos, 4);
> +    ASSERT(r);
> +
> +    header = (uint32_t)(uintptr_t)r->private;
> +    pos = PCI_EXT_CAP_NEXT(header);
> +    while ( pos > PCI_CFG_SPACE_SIZE && pos != offset )
> +    {
> +        r = vpci_get_register(vpci, pos, 4);
> +        ASSERT(r);
> +        header = (uint32_t)(uintptr_t)r->private;
> +        pos = PCI_EXT_CAP_NEXT(header);
> +    }
> +
> +    if ( pos <= PCI_CFG_SPACE_SIZE )
> +        return NULL;
> +
> +    return r;
> +}
> +
> +static void vpci_ext_capability_mask(struct pci_dev *pdev,
> +                                     const unsigned int cap)
> +{
> +    const unsigned int offset = pci_find_ext_capability(pdev->sbdf, cap);
> +    struct vpci_register *rm, *prev_r;
> +    struct vpci *vpci = pdev->vpci;
> +    uint32_t header, pre_header;

Maybe sanity check that offset is correct?

> +    spin_lock(&vpci->lock);
> +    rm = vpci_get_register(vpci, offset, 4);
> +    if ( !rm )
> +    {
> +        spin_unlock(&vpci->lock);
> +        return;
> +    }
> +
> +    header = (uint32_t)(uintptr_t)rm->private;
> +    if ( offset == PCI_CFG_SPACE_SIZE )
> +    {
> +        if ( PCI_EXT_CAP_NEXT(header) <= PCI_CFG_SPACE_SIZE )
> +            rm->private = (void *)(uintptr_t)0;
> +        else
> +            /*
> +             * Else case needs to remove the capability in position 0x100U and
> +             * moves the next capability to be in position 0x100U, that would
> +             * cause the offset of next capability in vpci different from the
> +             * hardware, then cause error accesses, so just ignore it here and
> +             * hope hardware would handle the capability well.
> +            */
> +            printk(XENLOG_ERR "%pd %pp: ext cap %u is first cap, can't mask it\n",
> +                   pdev->domain, &pdev->sbdf, cap);

In this case, could you maybe replace just the capability ID part of
the header to return 0?  That will likely cause the OS to continue
scanning the list, while ID 0 won't match which any known
capability.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 16:23:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:23:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977522.1364503 (Exim 4.92)
	(envelope-from )
	id 1uCL5J-0005QC-Eq; Tue, 06 May 2025 16:23:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977522.1364503; Tue, 06 May 2025 16:23: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 1uCL5J-0005Q5-C8; Tue, 06 May 2025 16:23:57 +0000
Received: by outflank-mailman (input) for mailman id 977522;
 Tue, 06 May 2025 16:23:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCL5H-0005Pz-L9
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:23:55 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 810252f5-2a96-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:23:54 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ac2bdea5a38so838325766b.0
 for ; Tue, 06 May 2025 09:23:54 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a2b6esm728346966b.42.2025.05.06.09.23.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:23: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" 
X-Inumbo-ID: 810252f5-2a96-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746548634; x=1747153434; 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;
        bh=pX0tE6d9iyJtA57cH8JYgABeCFhCYSub4Ng4AeJsFh4=;
        b=jMFZ4yI9iCXyY7GTD3rM7jwMWotxnbb6cZ5A2z2JqQOGppZJgsVOCN+8BIiO+zlNsQ
         YIfHbgAH2WLdYwrvR8Mia7ee/N9OhDtwWwm6tft3obR1SsMbpIo3758LlT+jR9wKUT1L
         7bPfF5jmKoGwZC2e4StSWOmImQ0/4v6Uak9Sk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746548634; x=1747153434;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=pX0tE6d9iyJtA57cH8JYgABeCFhCYSub4Ng4AeJsFh4=;
        b=e6tReGoQKsUFQNOb50eLWXOyqcpgJ3uuyjrRnQLpBx5SZ95mOHxSDyh08xMJJ4u+u6
         nbmlKCxotGc3DbXcECw6Bj/U87JQ8Vv4MZn+sXpiHH9cDvFFMOVfHQ9Bnf6l2npE66WC
         zn8OkC9APfharKUmR7jUOwpCW/TE/ldgzG+lUEqcCPtgpha4ODwmhJpuZGe1RIRifyi/
         RjhHSfSP/uOzq0VW8XCINXA0VJly8NQqUatWbJeEv/rBEGTnP/XWL5rCE0AT8+XMHy1n
         U1Nw070vYTBub2llOgWP0togojK504xVo87tJT+Y/BjI/QkNMkpOcAV217FIhHH8uRe5
         3Wag==
X-Gm-Message-State: AOJu0YwsWrJ/Ptz3qkUdQbnoMzONWpfdsMnezNEMsASpM5OMMyW0dliJ
	6d2WpVg6Q6GT2P25LMGPuBwD6Eq+Svy/rRKecPXmkD7Vxr/jj2V1G9Z2T2oZReyojgdCu+KCW7x
	B
X-Gm-Gg: ASbGncu9NIH+W88zILaeKwDQsEbwyNvYuPT5a+1FI9c5Y073Quy0Te5nAmiZMolkmP0
	1xKLUtCaH6uJxbEZn47wPy+q1dQu2Do+s8ISaHebv5Ef+t0kt9ujQHiHOMJO01/Cd9pDUKnWQZO
	H9oFRRPNv4FLc0lpb5VVKP7XsVoF8QiaHuUem8xCoQrFeAkHOIEa97rFM7R8c3Kp7O8+plE69MT
	3EfgEi0YwWZk6maNHmaFty0okMdG2/OC6EdNBRUQ2uftQSg+Sj2lHSSL+BwFE4mmmzAMLEnsVLD
	ThkIJDBcu3hX0v3vcUSMskKkAMAB6/48ZPeeKB0R1vQdoYGv0Olvu0EKXw==
X-Google-Smtp-Source: AGHT+IGeFqKlWrGxDGL/AHfXImClFuXG52wLkRmdzmWdGMR2tjxT88U5g3IbeLvHo+uS3ui90aH6Bg==
X-Received: by 2002:a17:907:9717:b0:ac8:1798:c2e7 with SMTP id a640c23a62f3a-ad1e8e34073mr5035166b.41.1746548633619;
        Tue, 06 May 2025 09:23:53 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: Kevin Lampis 
Subject: [PATCH 0/4] Add lockdown mode
Date: Tue,  6 May 2025 17:23:47 +0100
Message-ID: <20250506162347.1676357-1-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add lockdown mode

The intention of lockdown mode is to prevent attacks from a rogue dom0
userspace from compromising the system. Lockdown mode can be controlled by a
Kconfig option and a command-line parameter. It is also enabled automatically
when Secure Boot is enabled and it cannot be disabled in that case.

Ross Lagerwall (3):
  lib: Add strcspn function
  efi: Add a function to check if Secure Boot mode is enabled
  Add lockdown mode

Kevin Lampis (1):
  Disallow most command-line options when lockdown mode is enabled

 xen/arch/arm/domain_build.c           |  4 +--
 xen/arch/x86/acpi/cpu_idle.c          |  2 +-
 xen/arch/x86/cpu/amd.c                |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c         |  2 +-
 xen/arch/x86/cpu/microcode/core.c     |  2 +-
 xen/arch/x86/dom0_build.c             |  4 +--
 xen/arch/x86/hvm/hvm.c                |  2 +-
 xen/arch/x86/irq.c                    |  2 +-
 xen/arch/x86/nmi.c                    |  2 +-
 xen/arch/x86/setup.c                  |  3 +-
 xen/arch/x86/traps.c                  |  2 +-
 xen/arch/x86/x86_64/mmconfig-shared.c |  2 +-
 xen/common/Kconfig                    |  8 +++++
 xen/common/Makefile                   |  1 +
 xen/common/domain.c                   |  2 +-
 xen/common/efi/boot.c                 | 23 ++++++++++++
 xen/common/efi/runtime.c              |  3 ++
 xen/common/kernel.c                   | 13 ++++++-
 xen/common/kexec.c                    |  2 +-
 xen/common/lockdown.c                 | 52 +++++++++++++++++++++++++++
 xen/common/numa.c                     |  2 +-
 xen/common/page_alloc.c               |  2 +-
 xen/common/shutdown.c                 |  2 +-
 xen/drivers/char/console.c            |  2 +-
 xen/drivers/char/ns16550.c            |  4 +--
 xen/drivers/video/vga.c               |  2 +-
 xen/include/xen/efi.h                 |  6 ++++
 xen/include/xen/lockdown.h            |  9 +++++
 xen/include/xen/param.h               | 49 +++++++++++++++++++------
 xen/include/xen/string.h              |  1 +
 xen/lib/Makefile                      |  1 +
 xen/lib/strcspn.c                     | 22 ++++++++++++
 32 files changed, 200 insertions(+), 35 deletions(-)
 create mode 100644 xen/common/lockdown.c
 create mode 100644 xen/include/xen/lockdown.h
 create mode 100644 xen/lib/strcspn.c

-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:24:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:24:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977527.1364514 (Exim 4.92)
	(envelope-from )
	id 1uCL5k-0005rz-Nr; Tue, 06 May 2025 16:24:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977527.1364514; Tue, 06 May 2025 16:24: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 1uCL5k-0005rs-Jp; Tue, 06 May 2025 16:24:24 +0000
Received: by outflank-mailman (input) for mailman id 977527;
 Tue, 06 May 2025 16:24:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCL5j-0005g0-1D
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:24:23 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 90e5cef5-2a96-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:24:21 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ad1e8e2ad6bso2718666b.0
 for ; Tue, 06 May 2025 09:24:21 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189146fc0sm733748266b.19.2025.05.06.09.24.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:24:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 90e5cef5-2a96-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746548660; x=1747153460; 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;
        bh=D6W4oCrqGq7LWMq3BRb8qg3DzAc8pBwP3QkcxnP1CHc=;
        b=VdusNBekmmam6jec4N7kY7DAyjczhKMQtkqXUy95GYJCypxbSUPbypcChuUum9pJb6
         dUhicscKdgo7xZZoHL4Ks6mx/8Q9sqVrPGCSjvmwblWaLvRqYLLGpyVMU59JUQpugyBk
         uflrnWix6SPZJmp01oAxhOOJvLaG3mjh0T7Uo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746548660; x=1747153460;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=D6W4oCrqGq7LWMq3BRb8qg3DzAc8pBwP3QkcxnP1CHc=;
        b=E79V4/J6hvMl0N0LMy72jEXHuhwkgySBPPPvWr8l5aKKvjX4PGQTySsJWKg8l1qmef
         P8e9lKFZGRO0hKK+Au4UE2N+FAppsT/HIyClNBAH3pZJqMpnrWgRQgP7kJEuMI2WjqUm
         NfgV3HsDAi6fGOtkawi5PlSDkKHA60vJTZNYWxDK8NdRBxYwQ5hSJHiP971eX2qFxmjB
         vzHueKvxhP3PMaeokG8q2uZf9lHBUktxO1i64L7+P+8odNW9sDR0ZJF+lcbMBKLSBIGI
         Uop3FGzOjUjttnMHjq8z6OB4g6ycZnWPa559kZup+S9YkBZuTVUeeAPv0/sNDma4fRao
         0MEw==
X-Gm-Message-State: AOJu0Yz1u9js5red6ZR5GvHlK/vnXexX2gGfZRBOkNVJkH9RZZ7plBJn
	45+/xQk+Va8Ac5Ww6GszgHBUG+6152Ez48rb1c0zL1SxYRNiLDqlNfBkV/JLlZ0oqKxVbok/eeu
	0
X-Gm-Gg: ASbGnct14ed3N2yqPq0jIt8KG3c4fNBN3U8Bjhw/i94SJlsLFl3v9l8raeHlpCfkYJd
	cjYX59sKGfP+1vV6X0CM89Kva6hHsR0TKXncNfsCu9bpsRsNSgjM3W9/nFwTS7cXph2MxP6/KYg
	ItETVXzjh7RE8fz6oNDmis5FPrfezNf4kozriie4sqSXBXQbSaRtzPgs6gubDgMAYiOZ0llGJe/
	TfF3s3N4BOvUAp+w2WyXeXwmwkOGRV3KUbiW4le83qAsmthadYiTLjpYyyVwKwhGCe5CUnh3obW
	VOSV9VbFzgaOFB1CU7+azs8hcHz6vS2b8pBDaq5mkTHD/sADfetopJTKyg==
X-Google-Smtp-Source: AGHT+IH/fEZsbFLY7rwMxLyvVvN7eP7Cd6vA9qL9ijxhFj9v24N5lpoRHXaR7tJ1UDM1nu0PySm4SA==
X-Received: by 2002:a17:907:d48f:b0:ac3:853e:4345 with SMTP id a640c23a62f3a-ad1e8dbc85amr4933566b.45.1746548660462;
        Tue, 06 May 2025 09:24:20 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: Kevin Lampis ,
	Ross Lagerwall 
Subject: [PATCH 1/4] lib: Add strcspn function
Date: Tue,  6 May 2025 17:24:20 +0100
Message-ID: <20250506162420.1676377-1-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This will be used by future patches.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Kevin Lampis 
---
 xen/include/xen/string.h |  1 +
 xen/lib/Makefile         |  1 +
 xen/lib/strcspn.c        | 22 ++++++++++++++++++++++
 3 files changed, 24 insertions(+)
 create mode 100644 xen/lib/strcspn.c

diff --git a/xen/include/xen/string.h b/xen/include/xen/string.h
index bd4a8f48e9..70c231b690 100644
--- a/xen/include/xen/string.h
+++ b/xen/include/xen/string.h
@@ -26,6 +26,7 @@ size_t strnlen(const char *s, size_t count);
 char *strpbrk(const char *cs,const char *ct);
 char *strsep(char **s, const char *ct);
 size_t strspn(const char *s, const char *accept);
+size_t strcspn(const char *s, const char *reject);
 
 void *memset(void *s, int c, size_t n);
 void *memcpy(void *dest, const void *src, size_t n);
diff --git a/xen/lib/Makefile b/xen/lib/Makefile
index 76dc86fab0..5ccb1e5241 100644
--- a/xen/lib/Makefile
+++ b/xen/lib/Makefile
@@ -22,6 +22,7 @@ lib-y += sort.o
 lib-y += strcasecmp.o
 lib-y += strchr.o
 lib-y += strcmp.o
+lib-y += strcspn.o
 lib-y += strlcat.o
 lib-y += strlcpy.o
 lib-y += strlen.o
diff --git a/xen/lib/strcspn.c b/xen/lib/strcspn.c
new file mode 100644
index 0000000000..42e3308dac
--- /dev/null
+++ b/xen/lib/strcspn.c
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ *  Copyright (C) 1991, 1992  Linus Torvalds
+ */
+
+#include 
+
+/**
+ * strcspn - Calculate the length of the initial substring of @s which does not contain letters in @reject
+ * @s: The string to be searched
+ * @reject: The string to avoid
+ */
+size_t strcspn(const char *s, const char *reject)
+{
+	const char *p;
+
+	for (p = s; *p != '\0'; ++p) {
+		if (strchr(reject, *p))
+			break;
+	}
+	return p - s;
+}
-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:24:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:24:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977541.1364523 (Exim 4.92)
	(envelope-from )
	id 1uCL6B-0006ON-2M; Tue, 06 May 2025 16:24:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977541.1364523; Tue, 06 May 2025 16:24: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 1uCL6A-0006OG-Us; Tue, 06 May 2025 16:24:50 +0000
Received: by outflank-mailman (input) for mailman id 977541;
 Tue, 06 May 2025 16:24:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCL6A-0005Pz-2M
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:24:50 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a1ccd121-2a96-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:24:49 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-acae7e7587dso947376066b.2
 for ; Tue, 06 May 2025 09:24:49 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189508c83sm731618666b.139.2025.05.06.09.24.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09: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" 
X-Inumbo-ID: a1ccd121-2a96-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746548689; x=1747153489; 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;
        bh=yBOltvQZR3cZ8LO+u+HiQLbhIjuLAqi4VTV7akpp3TI=;
        b=bc6RrH9LX3VoKGbodK26IgVsmlK7nvKc0FvBC0oWdlXGsMBb3yEzKGSPpNSq5efTXb
         bSW6Q80zWfMq3bZg8Rn0aTP5mMysm0mqjurdojsSvvb5cT9FlCfF2TXGdIh39diNf0XP
         6F90jAnIIiVnnHM0TpjgOCxXUajZXrHzmPC2M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746548689; x=1747153489;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=yBOltvQZR3cZ8LO+u+HiQLbhIjuLAqi4VTV7akpp3TI=;
        b=ovzGYv/GlbcxxI026qKDAKzlyyBE8UgNsU86H7UVo//1t9SxmSFJCKB1Cg/ZBNqf4W
         ZoYyu0B5BkdLK1sQHCdarAdF2H4HAQYa22AIkWqufVy0WxTKZ01gmkYFpp/drIqVJsJg
         YiYuO+udQcYTYNTRSJHgVLrGmg/GbZu1UojLY5yYkdEI3bb9goxCvxmgK+pkKyq8VAyj
         CHZ8pXSEE8Lrz3kL8OKEhYvz07WlIE4Sp75oB+D+nKIj2xxI9BK6j+TPQhdsMGOFfpTr
         MvoqoC2V0bZ25EwekPkw6otKUFDGlsQsAeWMF/d8BFfFfqCgdjBNLjqwLMtle/yVZf4j
         ub4A==
X-Gm-Message-State: AOJu0YwRZzUARCn+QT/kO+/ZZRMhudeZXYQmJ//zWCRuODb5otXyp7hW
	f/uqDAwzmHSbqomekRVXDUmvMGw8feGT5i5G+vPAEushChbe066yJlF62agrsvxwzIfPxlY2ba7
	n
X-Gm-Gg: ASbGncuYSHcArR5YSKjXB3mF5/AzmmI8PQ5YmAYaJIbNiCk9FCf1oITDwbKHrzPyz14
	nNlBbnECTMgK3qGLiu8a5bckLqya176slAw3LaF0bIlnYIWCFZ9uBLr8TREsu8EwopZV2b5xWaz
	vH6YinAIsP9Dbh/mrqVIqESfN1LvyPuvaZewQspOnN3xFKy7Wuln+Be9NG8LlgrYgqeWwMdLnML
	TQo5eTozYhxgxYduvtrMWwtAgxPx7sM/3Qr07Q5B5vEqEugeakAnlzCbJWSilgesrRsFen+qXkO
	i/KfL4LvMWX8rYrVbkakdF2Rp6KP4/0Qb2AM+80v1me6ilF0cx4aapmOzMZiy0LK7Kag
X-Google-Smtp-Source: AGHT+IGvktPkRxHyQs1y7N4d3yBLwC2MGZGxVEbzD+fsaLZ5oq0CWl2kTU8NK/BXQs9YWk28kJ2EBg==
X-Received: by 2002:a17:907:7fab:b0:ace:3ede:9d26 with SMTP id a640c23a62f3a-ad1e8d2298amr8868566b.27.1746548688713;
        Tue, 06 May 2025 09:24:48 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: Kevin Lampis ,
	Ross Lagerwall 
Subject: [PATCH 2/4] efi: Add a function to check if Secure Boot mode is enabled
Date: Tue,  6 May 2025 17:24:49 +0100
Message-ID: <20250506162449.1676405-1-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Also cache it to avoid needing to repeatedly ask the firmware.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Kevin Lampis 
---
 xen/common/efi/boot.c    | 23 +++++++++++++++++++++++
 xen/common/efi/runtime.c |  3 +++
 xen/include/xen/efi.h    |  6 ++++++
 3 files changed, 32 insertions(+)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index e39fbc3529..7c528cd5dd 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -870,6 +870,27 @@ static void __init pre_parse(const struct file *file)
                    " last line will be ignored.\r\n");
 }
 
+static void __init init_secure_boot_mode(void)
+{
+    EFI_STATUS status;
+    EFI_GUID gv_uuid = EFI_GLOBAL_VARIABLE;
+    uint8_t data = 0;
+    UINTN size = sizeof(data);
+    UINT32 attr = 0;
+    status = efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &gv_uuid, &attr,
+                                 &size, &data);
+
+    if ( status == EFI_NOT_FOUND ||
+         (status == EFI_SUCCESS &&
+          attr == (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS) &&
+          size == 1 && data == 0) )
+        /* Platform does not support Secure Boot or it's disabled. */
+        efi_secure_boot = false;
+    else
+        /* Everything else play it safe and assume enabled. */
+        efi_secure_boot = true;
+}
+
 static void __init efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 {
     efi_ih = ImageHandle;
@@ -884,6 +905,8 @@ static void __init efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTabl
 
     StdOut = SystemTable->ConOut;
     StdErr = SystemTable->StdErr ?: StdOut;
+
+    init_secure_boot_mode();
 }
 
 static void __init efi_console_set_mode(void)
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 7e1fce291d..b63d21f16c 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -40,6 +40,9 @@ void efi_rs_leave(struct efi_rs_state *state);
 unsigned int __read_mostly efi_num_ct;
 const EFI_CONFIGURATION_TABLE *__read_mostly efi_ct;
 
+#if defined(CONFIG_X86) && !defined(CONFIG_PV_SHIM)
+bool __ro_after_init efi_secure_boot;
+#endif
 unsigned int __read_mostly efi_version;
 unsigned int __read_mostly efi_fw_revision;
 const CHAR16 *__read_mostly efi_fw_vendor;
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 160804e294..ae10ac62d0 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -40,6 +40,12 @@ static inline bool efi_enabled(unsigned int feature)
 }
 #endif
 
+#if defined(CONFIG_X86) && !defined(CONFIG_PV_SHIM)
+extern bool efi_secure_boot;
+#else
+#define efi_secure_boot false
+#endif
+
 void efi_init_memory(void);
 bool efi_boot_mem_unused(unsigned long *start, unsigned long *end);
 bool efi_rs_using_pgtables(void);
-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:29:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:29:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977556.1364534 (Exim 4.92)
	(envelope-from )
	id 1uCLAb-00075b-K7; Tue, 06 May 2025 16:29:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977556.1364534; Tue, 06 May 2025 16:29:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCLAb-00075U-FB; Tue, 06 May 2025 16:29:25 +0000
Received: by outflank-mailman (input) for mailman id 977556;
 Tue, 06 May 2025 16:29:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLAa-00075O-M8
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:29:24 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 447d6efc-2a97-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:29:22 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43cf628cb14so228495e9.1
 for ; Tue, 06 May 2025 09:29:22 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441b2aed5e8sm219314395e9.16.2025.05.06.09.29.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:29: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" 
X-Inumbo-ID: 447d6efc-2a97-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746548962; x=1747153762; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=gLEmCeRhHkfWsc5rFKS7lzRxbqkLvJ9nzlxOV4xFa40=;
        b=uZMO/DNw1XNb+FCnSdXvh0tottZMxb9D4p0bpJ//vqBbYWL2sPZgpLmXdM8Z/dib7T
         y4SZ/Aca04pByDuMphaVGRajoYSKOkbeQhNNusLWdLxH7r7YQ+lgA/dLI1FLIB4Zb08c
         RpElBmma4piZd43jLQ8aHDjdf2q5yCGvuCGq8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746548962; x=1747153762;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=gLEmCeRhHkfWsc5rFKS7lzRxbqkLvJ9nzlxOV4xFa40=;
        b=vAaKHzYSnVnyuhYhef4WtmXFta6py98hhGzyv0pDnHb6K+PpWqOTslr22O6K4rmWWs
         NQ/6P0SCUkKne0ZWmhMLL9ClOciRPSr3e7oC98Wel0CBLPFSPNCak9eYID0ihhJLQee4
         kgOQkWCpddaSuGMQspwODeihMzdxEXCw0hvpRsBmV853iu7QPQFPxEhbEeP+plc4JR1S
         l2T5i6KTIDF6wsc0d0RZDYC1o93j4pq3hDQ8QJEJO8eEMQxIuWfQeja/UXVzWDWHlcWI
         wP3rk2eV8hQN2nwPfBDvK0gPVqhcm8Je+IOh7eY3teUVw3oRxmudSFwgnOL9sG8yTDI8
         sBtw==
X-Gm-Message-State: AOJu0YzJvxT/AfmJypEseZcwEcK4CgMOPuiVVX136QwseUlKhYsgldiA
	7iUyj91qUJwUdIoNnEM5W/3l/QTnObdJjVNjNs8ltxm3EGXC7QBqVslbvr+Yk6M=
X-Gm-Gg: ASbGncsEiaEWKCfTNv1ogmD8h+yf0vJSbXpgyUuFFZhbAiZXArc0j0XjXAaQGmp3bu3
	ebnbqVvEcYS5aQVSQQI6nVR9RO1y1hLDrvqdZaVraxJghf95hgqxBKPvYiJD0ED7acvppCNbNDQ
	6EQPZgQqttMD+sD/xAubGYip5n/tIPQlrIvT2f3xWqq6RjtVM+1ZIS1w5LQE8s2r/pmniEaDJ4c
	AXU5HmQiK3juB4Ji2Ofx1AeBAEg+sKjLpLy9uG5WPCw1mOi6bTeHJCovGkSHx3NRKm4a5U2IcFl
	12ZUzr+P5BxC9h8NUA1gPb4uRqhxcJ4dmSNZywgmmcMzF0l4mxNhgiBC
X-Google-Smtp-Source: AGHT+IFAj+pA4ZSXGfXmmIHdthc3X6R1zWY8RdfnPGnwRrBr46HvSIS2MJb6Y12Q2lCUaJBRzPh5wQ==
X-Received: by 2002:a05:600c:c1c8:20b0:43d:186d:a4bf with SMTP id 5b1f17b1804b1-441d3a91a78mr2650365e9.0.1746548962193;
        Tue, 06 May 2025 09:29:22 -0700 (PDT)
Date: Tue, 6 May 2025 18:29:20 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui ,
	Anthony PERARD 
Subject: Re: [PATCH v3 08/11] vpci: Refactor vpci_remove_register to remove
 matched registers
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-9-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250421061903.1542652-9-Jiqian.Chen@amd.com>

On Mon, Apr 21, 2025 at 02:19:00PM +0800, Jiqian Chen wrote:
> vpci_remove_register() only supports removing a register in a time,
> but the follow-on changes need to remove all registers within a
> range. And vpci_remove_register() is only used for test currently.
> So, refactor it to support removing all matched registers in a
> calling time.
> 
> And it is no matter to remove a non exist register, so remove the
> __must_check prefix.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> cc: Anthony PERARD 
> ---
> v2->v3 changes:
> * Add new check to return error if registers overlap but not inside range.
> 
> v1->v2 changes:
> new patch
> 
> Best regards,
> Jiqian Chen.
> ---
>  tools/tests/vpci/main.c |  4 ++--
>  xen/drivers/vpci/vpci.c | 34 ++++++++++++++++++++--------------
>  xen/include/xen/vpci.h  |  4 ++--
>  3 files changed, 24 insertions(+), 18 deletions(-)
> 
> diff --git a/tools/tests/vpci/main.c b/tools/tests/vpci/main.c
> index 33223db3eb77..ca72877d60cd 100644
> --- a/tools/tests/vpci/main.c
> +++ b/tools/tests/vpci/main.c
> @@ -132,10 +132,10 @@ static void vpci_write32_mask(const struct pci_dev *pdev, unsigned int reg,
>                                    rsvdz_mask))
>  
>  #define VPCI_REMOVE_REG(off, size)                                          \
> -    assert(!vpci_remove_register(test_pdev.vpci, off, size))
> +    assert(!vpci_remove_registers(test_pdev.vpci, off, size))
>  
>  #define VPCI_REMOVE_INVALID_REG(off, size)                                  \
> -    assert(vpci_remove_register(test_pdev.vpci, off, size))
> +    assert(vpci_remove_registers(test_pdev.vpci, off, size))
>  
>  /* Read a 32b register using all possible sizes. */
>  void multiread4_check(unsigned int reg, uint32_t val)
> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> index 8ff5169bdd18..904770628a2a 100644
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -497,34 +497,40 @@ int vpci_add_register_mask(struct vpci *vpci, vpci_read_t *read_handler,
>      return 0;
>  }
>  
> -int vpci_remove_register(struct vpci *vpci, unsigned int offset,
> -                         unsigned int size)
> +int vpci_remove_registers(struct vpci *vpci, unsigned int start,
> +                          unsigned int size)
>  {
> -    const struct vpci_register r = { .offset = offset, .size = size };
>      struct vpci_register *rm;
> +    unsigned int end = start + size;
>  
>      spin_lock(&vpci->lock);
>      list_for_each_entry ( rm, &vpci->handlers, node )

You might want to use list_for_each_entry_safe ( ) so that...

>      {
> -        int cmp = vpci_register_cmp(&r, rm);
> -
> -        /*
> -         * NB: do not use a switch so that we can use break to
> -         * get out of the list loop earlier if required.
> -         */
> -        if ( !cmp && rm->offset == offset && rm->size == size )
> +        /* Remove rm if rm is inside the range. */
> +        if ( rm->offset >= start && rm->offset + rm->size <= end )
>          {
> +            struct vpci_register *prev =
> +                list_entry(rm->node.prev, struct vpci_register, node);

... you don't need to find prev here.

>              list_del(&rm->node);
> -            spin_unlock(&vpci->lock);
>              xfree(rm);
> -            return 0;
> +            rm = prev;
> +            continue;
>          }
> -        if ( cmp <= 0 )
> +
> +        /* Return error if registers overlap but not inside. */
> +        if ( rm->offset + rm->size > start && rm->offset < end )
> +        {
> +            spin_unlock(&vpci->lock);
> +            return -EINVAL;

-ERANGE might be more descriptive here.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 06 16:31:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:31:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977569.1364543 (Exim 4.92)
	(envelope-from )
	id 1uCLCO-0000HS-Tc; Tue, 06 May 2025 16:31:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977569.1364543; Tue, 06 May 2025 16: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 1uCLCO-0000HK-PZ; Tue, 06 May 2025 16:31:16 +0000
Received: by outflank-mailman (input) for mailman id 977569;
 Tue, 06 May 2025 16:31:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCL6Y-0005g0-8i
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:25:14 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id af7c13d8-2a96-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:25:12 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ac2af2f15d1so812228066b.1
 for ; Tue, 06 May 2025 09:25:12 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad18950acb3sm722432666b.156.2025.05.06.09.25.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:25: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" 
X-Inumbo-ID: af7c13d8-2a96-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746548712; x=1747153512; 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;
        bh=p5Nw58u0uqjQ/UJG5g09DLpf6rbXIWW0Z96rbvwd4kE=;
        b=J/ft8P1zydbHmXpuW4rUDYjzsBWVNgiRtKAjXjZc/yQAw+U9pxJQEasfinB8cP3bnE
         Ilv51SEl7KcsZZWnhgu4VkOTnDyxmd/H8wSnvXlAv9bsO/ti6zjEOVS+n+vMBG3aOPit
         8dZctAvCnoiefRgmWpr9ARMU0JXcauc1fNh1w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746548712; x=1747153512;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=p5Nw58u0uqjQ/UJG5g09DLpf6rbXIWW0Z96rbvwd4kE=;
        b=BMLZpb3r3QOphDvh9/8tOB/XymYdZjgDhbsbRUU4uuP66pj8sqFIJh4sUZJ8awEtmu
         PY/AhFqpajbt5LKMl2cF5DTpemidpW7sP4uKkU+sh00Cvi9hGBK3kDc03GolMG1R8gE7
         GAr0T/7/zjqfxGIc9kOwCeLRR3a2d5OdpsNi3qoQKUxPuevJFzg+Ird14PkCVA5732Z+
         sGiRZoOPf446iDtI4m3U6KaFeezM5xl3t7NA+rmgMzhgbjjcXdkjwXjMoFJiV4hoCUS3
         zO0hGa9C8N9bf65Z5LZZar6NVpkjKzBEX6KM8GAa8PcdYzKPjHJHIEMrkQ60G5OFL7VQ
         tFZg==
X-Gm-Message-State: AOJu0YyI15gT2uXlLGRUrb9FOQIR3Vf7+0CH3F6gg6TiQdqgIGgsKzDM
	0I54bJaTjl/4jLVDQltibhn4Sb6PY4sQeOqBQNmVNESsGrgt+toc4JPZ01Yyj+QLvTLuMbUTtrL
	Q
X-Gm-Gg: ASbGncu5lelRYb/3D4GFZeGYE7gtWRL2jkE9M8OB2FRrxVI/2e1Gs23HJ9XTXtCXwgv
	A2YlmdKwFcxE2aYJqwxxhFEsnv/dThoARH9TCJOYF4HctWJmvqstSxWRZqMxgjyw0aXrCFIolSV
	ZrMks03o1mVPrmeK2PcS9U+0EbPImI67jVr9X5apq4GXd/YW9ronPgikPGu9YbwtJm3xGCWn90Z
	lkKe8wMAsrBbPyNIzZfQuMfJmRTfExGJu/QEfXAr57pPQ8B4Z+zrF+bOEVn4EJ7KQKWPIeoOg/9
	sIqyQNUjEDRh2yhJC85nQQZbvcx/CAdWzyUWwR0+dfRdYTYa6yN5LvET0MBmytX2iW8D
X-Google-Smtp-Source: AGHT+IEh6fE7FrZHI2i9KRwNA5Au4dRx8YKZgtEHtBMrDx6LGlen5CbiTRdEUvJKo+z+cR6uFA6E3Q==
X-Received: by 2002:a17:907:cbc3:b0:ad1:91cb:3976 with SMTP id a640c23a62f3a-ad1e8d2ced6mr6739566b.58.1746548711734;
        Tue, 06 May 2025 09:25:11 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: Kevin Lampis ,
	Ross Lagerwall 
Subject: [PATCH 3/4] Add lockdown mode
Date: Tue,  6 May 2025 17:25:10 +0100
Message-ID: <20250506162510.1676425-1-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The intention of lockdown mode is to prevent attacks from a rogue dom0
userspace from compromising the system. Lockdown mode can be controlled by a
Kconfig option and a command-line parameter. It is also enabled automatically
when Secure Boot is enabled and it cannot be disabled in that case.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Kevin Lampis 
---
 xen/arch/x86/setup.c       |  1 +
 xen/common/Kconfig         |  8 ++++++
 xen/common/Makefile        |  1 +
 xen/common/kernel.c        |  3 +++
 xen/common/lockdown.c      | 52 ++++++++++++++++++++++++++++++++++++++
 xen/include/xen/lockdown.h |  9 +++++++
 6 files changed, 74 insertions(+)
 create mode 100644 xen/common/lockdown.c
 create mode 100644 xen/include/xen/lockdown.h

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2518954124..276957c4ed 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 4bec78c6f2..63ff37d046 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -596,4 +596,12 @@ config BUDDY_ALLOCATOR_SIZE
 	  Amount of memory reserved for the buddy allocator to serve Xen heap,
 	  working alongside the colored one.
 
+config LOCKDOWN_DEFAULT
+	bool "Enable lockdown mode by default"
+	default n
+	help
+	  Lockdown mode prevents attacks from a rogue dom0 userspace from
+	  compromising the system. This is automatically enabled when Secure
+	  Boot is enabled.
+
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..b00a8a925a 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC) += kimage.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
+obj-y += lockdown.o
 obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 8b63ca55f1..6658db9514 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -216,6 +216,9 @@ static void __init _cmdline_parse(const char *cmdline)
  */
 void __init cmdline_parse(const char *cmdline)
 {
+    /* Call this early since it affects command-line parsing */
+    lockdown_init(cmdline);
+
     if ( opt_builtin_cmdline[0] )
     {
         printk("Built-in command line: %s\n", opt_builtin_cmdline);
diff --git a/xen/common/lockdown.c b/xen/common/lockdown.c
new file mode 100644
index 0000000000..935911dfd0
--- /dev/null
+++ b/xen/common/lockdown.c
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static bool __ro_after_init lockdown = IS_ENABLED(CONFIG_LOCKDOWN_DEFAULT);
+ignore_param("lockdown");
+
+bool is_locked_down(void)
+{
+    return lockdown;
+}
+
+void __init lockdown_init(const char *cmdline)
+{
+    if ( efi_secure_boot )
+    {
+        printk("Enabling lockdown mode because Secure Boot is enabled\n");
+        lockdown = true;
+    }
+    else
+    {
+        while ( *cmdline )
+        {
+            size_t param_len, name_len;
+            int ret;
+
+            cmdline += strspn(cmdline, " \n\r\t");
+            param_len = strcspn(cmdline, " \n\r\t");
+            name_len = strcspn(cmdline, "= \n\r\t");
+
+            if ( !strncmp(cmdline, "lockdown", max(name_len, strlen("lockdown"))) ||
+                 !strncmp(cmdline, "no-lockdown", max(name_len, strlen("no-lockdown"))) )
+            {
+                ret = parse_boolean("lockdown", cmdline, cmdline + param_len);
+                if ( ret >= 0 )
+                {
+                    lockdown = ret;
+                    printk("Lockdown mode set from command-line\n");
+                    break;
+                }
+            }
+
+            cmdline += param_len;
+        }
+    }
+
+    printk("Lockdown mode is %s\n", lockdown ? "enabled" : "disabled");
+}
diff --git a/xen/include/xen/lockdown.h b/xen/include/xen/lockdown.h
new file mode 100644
index 0000000000..b2baa31caa
--- /dev/null
+++ b/xen/include/xen/lockdown.h
@@ -0,0 +1,9 @@
+#ifndef XEN__LOCKDOWN_H
+#define XEN__LOCKDOWN_H
+
+#include 
+
+bool is_locked_down(void);
+void lockdown_init(const char *cmdline);
+
+#endif /* XEN__LOCKDOWN_H */
-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:37:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:37:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977590.1364552 (Exim 4.92)
	(envelope-from )
	id 1uCLID-0001A9-FS; Tue, 06 May 2025 16:37:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977590.1364552; Tue, 06 May 2025 16:37: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 1uCLID-0001A2-CL; Tue, 06 May 2025 16:37:17 +0000
Received: by outflank-mailman (input) for mailman id 977590;
 Tue, 06 May 2025 16:37:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLIC-00019w-92
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:37:16 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5d9b5395-2a98-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:37:14 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-39c266c1389so4435241f8f.1
 for ; Tue, 06 May 2025 09:37:14 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a0b1ff8453sm1822959f8f.34.2025.05.06.09.37.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 09:37: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" 
X-Inumbo-ID: 5d9b5395-2a98-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746549434; x=1747154234; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=iBQnOG6o2JoKa54f3witE8SkuGiquIWiHkM+EA3gCYM=;
        b=mQ/dM4As+ZkYLjsSiGzp4exvUcth7x76d98pPEtYRTjVUhXaleT+srnRop4AuhGenw
         eSPLJx6QFC51rT4DhYhD3S7+TD7jmr7oz4kr964/586WFha3+cYjG83ZySQHPkAFOS/j
         Nrsod1jlCJ+EVnUOa9jDdJeiN+IwRgsZ+VeUo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746549434; x=1747154234;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=iBQnOG6o2JoKa54f3witE8SkuGiquIWiHkM+EA3gCYM=;
        b=wWqssgEdztaWfp91ElXbNyZzHwgvHWZswZUmHg9y7lNk3Kg0i7NkOwLHd9SF8EtUVS
         CXmkhFnQ1TShjEuGg5qHLOX10ZoF8jdZWGM9iKhTwsvYen922tyE6YF5xqbdGPZER5Sg
         GHzq6yrFhwLWDcVLFT6wBFrqSTX27RF1fLlSwr4HL5InUNoohSQVqQAtHWCCMFTW3YQw
         omwXmN3MaaMzA7MqfE+U81NhPlV/xBK7D6zcko06BI6s4lOMnwwv/YOu1qART2XmUwi5
         zU3hnykq7CErbPTfWxGBIXwQVcb2YFhV+vUOII1AExUjyfDWDUDSWiznKjYkP23vg5WQ
         l1nQ==
X-Forwarded-Encrypted: i=1; AJvYcCVShdBTjk2p98R8k50hZtrmf0IBF/V4Z1oliwwPhhLlE0u2TyZzeCqP6PqDXBc6UIT4XKG6rwiuH4c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx63oPDwSSZRonkRAlKEFEyMLcq1H2AxArDAghH7jzTKC+xLfcn
	ma6Aj03CfhZRL/PJVxjqr58Di4rfOwtPM0QzmY/QK20JWdy40TtznrlKUFAlxKw=
X-Gm-Gg: ASbGncstBHJRSTPceLyg2SsWNzI2gSygbl42mXwPlq9wlDsVTVSU3flD0UFZb1Wx26k
	ws09KXVfoT29IliduFpZIx722kLUF5ihVfBw5z4nMLClGLn/KnrfOci6R2FnRyzyCxjA28d4J4K
	OUGVFIKZulGpMtyF1/zWLbntU1JQGw0Nk0ExP2q3q6vcdP35+Roedp4RbOErFf8S3kN236Ucl5F
	oC6axft2hcSrgLU6+aAXZnkVP1+yr3tCSL5JF2kzjK9YIp+rnfTUAZ5VNPor+GOgVpK8hWk85hf
	eMq3Ue6SKFFzRRPEI8WypnWkckZ+L3ZcOAQT8mR2OdpLGgoo3+xnpfO78iBLYyVTTXMRNfBOSjW
	bmu4WHg==
X-Google-Smtp-Source: AGHT+IHBU7Q+8gbjZ4t/VsXPP1b4iP8uzN6tgSvEXW8vdfXiJTdtRcE011KxXw5yYmUF4x159MxtiA==
X-Received: by 2002:a05:6000:401f:b0:3a0:88b0:b81e with SMTP id ffacd0b85a97d-3a0b4a1917fmr117675f8f.36.1746549433782;
        Tue, 06 May 2025 09:37:13 -0700 (PDT)
Message-ID: <50a2737a-611a-4d83-aee6-de23619b0b6b@citrix.com>
Date: Tue, 6 May 2025 17:37:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] lib: Add strcspn function
To: Kevin Lampis , xen-devel@lists.xenproject.org
Cc: Ross Lagerwall 
References: <20250506162420.1676377-1-kevin.lampis@cloud.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: <20250506162420.1676377-1-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06/05/2025 5:24 pm, Kevin Lampis wrote:
> diff --git a/xen/include/xen/string.h b/xen/include/xen/string.h
> index bd4a8f48e9..70c231b690 100644
> --- a/xen/include/xen/string.h
> +++ b/xen/include/xen/string.h
> @@ -26,6 +26,7 @@ size_t strnlen(const char *s, size_t count);
>  char *strpbrk(const char *cs,const char *ct);
>  char *strsep(char **s, const char *ct);
>  size_t strspn(const char *s, const char *accept);
> +size_t strcspn(const char *s, const char *reject);
>  
>  void *memset(void *s, int c, size_t n);
>  void *memcpy(void *dest, const void *src, size_t n);

Lower down in this file, you also want a define aliasing to
__builtin_strcspn() in the style of the others you'll see.  In turn,
you'll need to...

> diff --git a/xen/lib/strcspn.c b/xen/lib/strcspn.c
> new file mode 100644
> index 0000000000..42e3308dac
> --- /dev/null
> +++ b/xen/lib/strcspn.c
> @@ -0,0 +1,22 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + *  Copyright (C) 1991, 1992  Linus Torvalds
> + */
> +
> +#include 
> +
> +/**
> + * strcspn - Calculate the length of the initial substring of @s which does not contain letters in @reject
> + * @s: The string to be searched
> + * @reject: The string to avoid
> + */
> +size_t strcspn(const char *s, const char *reject)

... write this as "size_t (strcspn)(const ..."

to avoid the macro expansion in this one place.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 06 16:49:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:49:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977606.1364563 (Exim 4.92)
	(envelope-from )
	id 1uCLU8-0003Fv-I9; Tue, 06 May 2025 16:49:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977606.1364563; Tue, 06 May 2025 16:49: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 1uCLU8-0003Fo-FM; Tue, 06 May 2025 16:49:36 +0000
Received: by outflank-mailman (input) for mailman id 977606;
 Tue, 06 May 2025 16:49:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLU7-0003Fi-3T
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:49:35 +0000
Received: from mail137-14.atl71.mandrillapp.com
 (mail137-14.atl71.mandrillapp.com [198.2.137.14])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0ce942c7-2a9a-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:49:25 +0200 (CEST)
Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail137-14.atl71.mandrillapp.com (Mailchimp) with ESMTP id
 4ZsPW01ZkHz705qnc
 for ; Tue,  6 May 2025 16:49:16 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 27e1172defaa4476915b7f165b02826a; Tue, 06 May 2025 16:49: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" 
X-Inumbo-ID: 0ce942c7-2a9a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1746550156; x=1746820156;
	bh=94gLD2TU1RziIJLzd2SkFBfyeSw38UC4+1m8vKkod+s=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=gvSxgsxmUAqSdu50SPG1dOvguybcl5hcgVq5Y8yiKHe1JeZyaoTqKqD2kjAHBp52L
	 Six+6R1WAbTl2PDPDepXgDcIhN6urQctIPtQaxfXrqLq0xZTrzigEdElgWCQm4hLIJ
	 vr9scK2cWjK9QpV5b6Gp39M3DhwhViYS2fIaxIvQJZBrQPNU4PJmU3OHFtWkxdvGzM
	 E9P+xgsUQ7sxNhECxFCJ14w0T+8LO9cysXA5ra74hthgHkFTiCuu4rcoNTvH5i3duu
	 Zbtwrmr/UiGoMtvalIX9MIrcgSdKD1m5O/Y2HHV8IbDzwrrjG/TTSwJNmHYSset8gH
	 NAZ0FnDVB98uw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1746550156; x=1746810656; i=teddy.astie@vates.tech;
	bh=94gLD2TU1RziIJLzd2SkFBfyeSw38UC4+1m8vKkod+s=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=p423RydLrFi3K7uY16uxnU0iJW7Vwn9W5YSNQjUV1QFbAebofG9xXhunvx13zAbxL
	 sdL97jbcVTP/Z4HTWqPfslvT7AkFH8QvwLUBxap/7Hlwju/TbO10QlMDmynPoLoWJF
	 DBEuHFNKcqVL9SbDMCYs/8zYYSss0HoCY4eUBz5qjT0RfdM/jaywtA49rvDUSW3uSQ
	 /vbkQpcclssiVSDEypomd1X2pimv/nWMWOoZyHQONPCj/lV98YYFI0Ibrcz8CRXvyK
	 4BLR+JgNMuZJj+jJYyMtLm1bSPmYbORVxgdSxHSK58ssNsnm3fMkGRIAc56Nl7CotD
	 iUmdKHV+N6XgA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=203/4]=20Add=20lockdown=20mode?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1746550154364
Message-Id: 
To: "Kevin Lampis" , xen-devel@lists.xenproject.org
Cc: "Ross Lagerwall" 
References: <20250506162510.1676425-1-kevin.lampis@cloud.com>
In-Reply-To: <20250506162510.1676425-1-kevin.lampis@cloud.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.27e1172defaa4476915b7f165b02826a?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250506:md
Date: Tue, 06 May 2025 16:49:16 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello Kevin,

Le 06/05/2025 =C3=A0 18:32, Kevin Lampis a =C3=A9crit=C2=A0:
> The intention of lockdown mode is to prevent attacks from a rogue dom0
> userspace from compromising the system. Lockdown mode can be controlled b=
y a
> Kconfig option and a command-line parameter.

What is the effective effect of such mode ? How does it protect the 
hypervisor from Dom0 ?
(I can't find the PATCH 4/4 which seems to give a explanation)

  It is also enabled automatically
> when Secure Boot is enabled and it cannot be disabled in that case.
> 
> Signed-off-by: Ross Lagerwall 
> Signed-off-by: Kevin Lampis 
> ---
>   xen/arch/x86/setup.c       |  1 +
>   xen/common/Kconfig         |  8 ++++++
>   xen/common/Makefile        |  1 +
>   xen/common/kernel.c        |  3 +++
>   xen/common/lockdown.c      | 52 ++++++++++++++++++++++++++++++++++++++
>   xen/include/xen/lockdown.h |  9 +++++++
>   6 files changed, 74 insertions(+)
>   create mode 100644 xen/common/lockdown.c
>   create mode 100644 xen/include/xen/lockdown.h
> 
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 2518954124..276957c4ed 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -15,6 +15,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   #include 
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 4bec78c6f2..63ff37d046 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -596,4 +596,12 @@ config BUDDY_ALLOCATOR_SIZE
>   =09  Amount of memory reserved for the buddy allocator to serve Xen hea=
p,
>   =09  working alongside the colored one.
>   
> +config LOCKDOWN_DEFAULT
> +=09bool "Enable lockdown mode by default"
> +=09default n
> +=09help
> +=09  Lockdown mode prevents attacks from a rogue dom0 userspace from
> +=09  compromising the system. This is automatically enabled when Secure
> +=09  Boot is enabled.
> +
>   endmenu
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 98f0873056..b00a8a925a 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_KEXEC) +=3D kexec.o
>   obj-$(CONFIG_KEXEC) +=3D kimage.o
>   obj-$(CONFIG_LIVEPATCH) +=3D livepatch.o livepatch_elf.o
>   obj-$(CONFIG_LLC_COLORING) +=3D llc-coloring.o
> +obj-y +=3D lockdown.o
>   obj-$(CONFIG_VM_EVENT) +=3D mem_access.o
>   obj-y +=3D memory.o
>   obj-y +=3D multicall.o
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index 8b63ca55f1..6658db9514 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -216,6 +216,9 @@ static void __init _cmdline_parse(const char *cmdline=
)
>    */
>   void __init cmdline_parse(const char *cmdline)
>   {
> +    /* Call this early since it affects command-line parsing */
> +    lockdown_init(cmdline);
> +
>       if ( opt_builtin_cmdline[0] )
>       {
>           printk("Built-in command line: %s\n", opt_builtin_cmdline);
> diff --git a/xen/common/lockdown.c b/xen/common/lockdown.c
> new file mode 100644
> index 0000000000..935911dfd0
> --- /dev/null
> +++ b/xen/common/lockdown.c
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static bool __ro_after_init lockdown =3D IS_ENABLED(CONFIG_LOCKDOWN_DEFA=
ULT);
> +ignore_param("lockdown");
> +
> +bool is_locked_down(void)
> +{
> +    return lockdown;
> +}
> +
> +void __init lockdown_init(const char *cmdline)
> +{
> +    if ( efi_secure_boot )
> +    {
> +        printk("Enabling lockdown mode because Secure Boot is enabled\n"=
);
> +        lockdown =3D true;
> +    }
> +    else
> +    {
> +        while ( *cmdline )
> +        {
> +            size_t param_len, name_len;
> +            int ret;
> +
> +            cmdline +=3D strspn(cmdline, " \n\r\t");
> +            param_len =3D strcspn(cmdline, " \n\r\t");
> +            name_len =3D strcspn(cmdline, "=3D \n\r\t");
> +
> +            if ( !strncmp(cmdline, "lockdown", max(name_len, strlen("loc=
kdown"))) ||
> +                 !strncmp(cmdline, "no-lockdown", max(name_len, strlen("=
no-lockdown"))) )
> +            {
> +                ret =3D parse_boolean("lockdown", cmdline, cmdline + par=
am_len);
> +                if ( ret >=3D 0 )
> +                {
> +                    lockdown =3D ret;
> +                    printk("Lockdown mode set from command-line\n");
> +                    break;
> +                }
> +            }
> +
> +            cmdline +=3D param_len;
> +        }
> +    }
> +
> +    printk("Lockdown mode is %s\n", lockdown ? "enabled" : "disabled");
> +}

With
> Kevin Lampis (1):
>   Disallow most command-line options when lockdown mode is enabled

I am not convinced of the efficiency of being able to toggle lockdown 
(including disabling it) mode from command-line. In case the userland 
can hijack the cmdline, I can't see what would prevent it from setting 
no-lockdown, which will disable the lockdown mode (also overriding 
CONFIG_LOCKDOWN_DEFAULT).

> diff --git a/xen/include/xen/lockdown.h b/xen/include/xen/lockdown.h
> new file mode 100644
> index 0000000000..b2baa31caa
> --- /dev/null
> +++ b/xen/include/xen/lockdown.h
> @@ -0,0 +1,9 @@
> +#ifndef XEN__LOCKDOWN_H
> +#define XEN__LOCKDOWN_H
> +
> +#include 
> +
> +bool is_locked_down(void);
> +void lockdown_init(const char *cmdline);
> +
> +#endif /* XEN__LOCKDOWN_H */

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977618.1364584 (Exim 4.92)
	(envelope-from )
	id 1uCLWS-0005Mu-4Z; Tue, 06 May 2025 16:52:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977618.1364584; Tue, 06 May 2025 16:52: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 1uCLWS-0005Ml-04; Tue, 06 May 2025 16:52:00 +0000
Received: by outflank-mailman (input) for mailman id 977618;
 Tue, 06 May 2025 16:51:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWR-0005Fd-Fh
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:51:59 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6c1f9490-2a9a-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:51:57 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ac2dfdf3c38so1077865766b.3
 for ; Tue, 06 May 2025 09:51:57 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.51.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:51: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" 
X-Inumbo-ID: 6c1f9490-2a9a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550317; x=1747155117; 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;
        bh=UZZenJUioRQGH1T51btvwJarRZwAntnsDHS9Af8zNvk=;
        b=QoN7NUss06UJf7jtNa+HLw9MFZ0uOdEh52HSsSzfF7cVZVlqJGz5srDUOG3lX+cT2Y
         SHIxBgKZHL18zH5B+JUR7lRyNZkqswo1nxLim3WEyQu34rkDSVCjcf3TWffcgmLpSLs1
         +S9VeUIp47b1OF2bDLIk8LKKQpjUZsEw/47rd2Y9zlNSKuj3DGMJGD0Ul4K9HdDlgCKW
         VIZl2JoYzSfoz9SPrcxiF5r2+naEjEyLyG4jA32P7Zhq1OOn9BY4OImWMSHgLZTHM0x7
         i2vXV+OpQk/RwlBZrr5Fw4fdhgYsAHepk348Rw8EqWf8nXBWCiX2hBQZOQmob8/Ayh4G
         W9Cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550317; x=1747155117;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=UZZenJUioRQGH1T51btvwJarRZwAntnsDHS9Af8zNvk=;
        b=Fj0g8m2jcRAfqBGQ+99a3XjkSNGl5kS1LNd57g3tBKXOeQEs07vSQntJFJdDTdV7yb
         zVI2DnCyz6GzFsTl7MTbd5xTz2w2n8O5ed8x06WG0Nkdq0KOxaCwu+xDy/oDNnDVfDa9
         jXlOCfCjUN0hIEgtw+seil5h4tPfumxwlepyye9sj3fhGJH6EFydEm+azXFZ+0VBYKr6
         /93Pq6qWdH/ncMYQ9thCqbNl1SigMBSWtzDgWBvNuAnFkG2IEp0t3uFywzfTw2Vqq8Oo
         J1/HdYbMnPrE6pkFtkvhp6ZifC0B67rAQvakC1ChKD1aiR6SYGCTfQ2W7BWeY1/EGSvz
         9YOg==
X-Gm-Message-State: AOJu0Yy6X5sXuekzjAQ8nSiU7Z116s+VZD6rursmFfDyfCiLyY3fYZg6
	vcrdM+/yTwdcI+WvYq0Xx75KwsJOKTBiYrDDP3XMPQs0togHlLQQo5VE2A==
X-Gm-Gg: ASbGnct5C0y6j1+jNg7w6pw02tUrdAW0G1l/uEIM7YAcStXq/3sqrBR1FgXUAKYVMXs
	C2easMw6FvISpJQRqv2nxkaXWjEMtMoOwVDA0uBrRwMa2gEGVN38UNDS+UZkB/4T9Z45xiy2WZ6
	sWh9vN8BNOSkeGZVMIv96cleY8NeO6GiNg+CvA7KtPg24zOHW9I41c1iw6EdHFgItNeOeAvECRJ
	iibcWkZzqgLFYTJv7QPrvHWFULKq2xrF8IOhLz0G/PxwsutmickG8JODP9hgmWW6UkBpgYXBg5H
	JsWd0QXKl12a9Saf+YgGDUfxp+ikmFfQ3CYFYmClGwE9/tVCEormIsaPTKD06TBmwltDyU5xpy8
	O7PX8gJD3GBDw91kR29bv
X-Google-Smtp-Source: AGHT+IFaSJSNfOEaKtEIxlpAAZoDwVMB3HMLE+EanhY+am3QF4vq/jtENtfjZtIqTKyA8XLs2tXZLQ==
X-Received: by 2002:a17:907:3e23:b0:ace:bead:5ee1 with SMTP id a640c23a62f3a-ad1e8dbc871mr15117066b.42.1746550316402;
        Tue, 06 May 2025 09:51:56 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 01/16] xen/riscv: initialize bitmap to zero in riscv_fill_hwcap_from_isa_string()
Date: Tue,  6 May 2025 18:51:31 +0200
Message-ID: <21efdebac3d1c9797420a8c81fbbd6a06ecc9121.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The this_isa bitmap should be explicitly initialized to zero to avoid
false positives when detecting supported ISA extensions. Without proper
zero-initialization, the bitmap may retain non-zero values from
uninitialized memory, causing Xen to incorrectly assume that certain
extensions are supported.

This change ensures reliable detection of ISA capabilities.

Fixes: 0c2f717eae ("xen/riscv: identify specific ISA supported by cpu")
Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - new patch.
---
 xen/arch/riscv/cpufeature.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
index 5aafab0f49..3246a03624 100644
--- a/xen/arch/riscv/cpufeature.c
+++ b/xen/arch/riscv/cpufeature.c
@@ -405,6 +405,8 @@ static void __init riscv_fill_hwcap_from_isa_string(void)
         const char *isa;
         unsigned long cpuid;
 
+        bitmap_zero(this_isa, RISCV_ISA_EXT_MAX);
+
         if ( !dt_device_type_is_equal(cpu, "cpu") )
             continue;
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977619.1364589 (Exim 4.92)
	(envelope-from )
	id 1uCLWS-0005Q8-FI; Tue, 06 May 2025 16:52:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977619.1364589; Tue, 06 May 2025 16:52: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 1uCLWS-0005Py-8v; Tue, 06 May 2025 16:52:00 +0000
Received: by outflank-mailman (input) for mailman id 977619;
 Tue, 06 May 2025 16:51:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWR-00058E-HQ
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:51:59 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6ce27762-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:51:59 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ac3eb3fdd2eso262713666b.0
 for ; Tue, 06 May 2025 09:51:59 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.51.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:51: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" 
X-Inumbo-ID: 6ce27762-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550318; x=1747155118; 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;
        bh=p8le7vZakEngLNFsWoDo29Hu279LBR8cdaIyUujlRsQ=;
        b=d4PbMPo0sYUKhPtKk9Q6BsPDLD7mbTesm1fipeL7HH4Si+eC0HriH7SIa1+vK2FVj6
         NMAMSIKfWDxMy5RoTg0NA9v3jKo6Z5DCj+u1ZeSRSimJ8ZH4RpTpfr3ZkiIyQO0zYVoA
         PkAA4bQzFWJIDEC+s9axXHHYWQfhh59jtJ9WsbiIWKG4z3AKelvpV85XgLCtlVnCEvez
         QGdu2jwtTdRizvZBGVR1JPUUb7LX0ZCFiTWfbinea2UVjcLffKe3L/PJroJa4Axojnlc
         jYw3mmb+z8v8e+h9MhS4SKu0sgztCHcGic+cEXLI4a4ie2s2zliJiDWi7Rh8BAuvYTay
         GV6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550318; x=1747155118;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=p8le7vZakEngLNFsWoDo29Hu279LBR8cdaIyUujlRsQ=;
        b=KVd9IPmRRMbKs0C8jaartlKqgqUVHvQjknC8xkK4xWFvrVITPBWUDeyBMYKjBhhao3
         w3vfvbD/xNvgyLZeHYAM0UbqS9nddVruZxZsvB+WFgB0cS9G6rRfTyEWCjDF4jgldDfE
         BIYLVoD7M+IjwAhvTZTraqBuSR40gffvuVLvUV9VWDboDiwS+cTPPafNWx0WrdJe8Cd9
         iHzIxOUOuxrgEUwyaSsHEZTakvlYtme49RTUeuHwRAHQXR7NuzFbAXLXOg/kU850Tzo6
         iaJp8NQ8wJC7rbmJYq7+QlhC9eRkrkOGHhsVVL/ytFdGZy6dtLGiQgdpzs14ZCjri2cp
         8hJQ==
X-Gm-Message-State: AOJu0YxNJktn/CMJ8NCe3J32jq2i+CMIdG+OgWfwb3pZcKRsmmUwnjbf
	WrZ8fMX6RFb1EzO2D330l6gIgRduW7qkFl+GJPS8dVg/psV1O3Ok5NNmbw==
X-Gm-Gg: ASbGncvavRPMwt5d4dCsmgrDcroMC5UBGiPya4cGu2qxhsIKx7/+A+8Ofa7fUZXbvk1
	NtTcSvWkCf2/wz76ZxWNnuJbgYMvtWMa78rKXDXo7Z0dyQ/7DZW/l46cyPozm7ujP3KYHos6ENE
	E8e35AT+z2P9wEv0xPqpFclO4Mn4mnDKpADEWHoPWrjkEByA81D/8LXhfwzt3o0h0VvQzgk4FX7
	06rcSGXZ+KeK+vRPRkwhL1rjlAzy+qUVPL+wb1wsxGYWbG09+xWbU6Ydn1nPwpx3vuTOk7GiR5H
	o8bo3TOYRgQ4hqRY0JTR4AStQVvP1H/gNNF5/+4bWDwQkDdhk+A1guRTW/iX+EMUdqZJ8vM9tpI
	fxOMNFUASIg==
X-Google-Smtp-Source: AGHT+IHO/Fo4tlE/KU7nbSnaumhBbp2s/ZDjX7acHYn6sWOydJxlNhuhT1vfDdpqT+aAvZwBra8qdg==
X-Received: by 2002:a17:906:dc8b:b0:ac7:3911:35e6 with SMTP id a640c23a62f3a-ad1e8d0c9b3mr16799266b.58.1746550317709;
        Tue, 06 May 2025 09:51:57 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 02/16] xen/riscv: introduce smp_prepare_boot_cpu()
Date: Tue,  6 May 2025 18:51:32 +0200
Message-ID: <704550ffbb34c94bfe85be928b2fcc0105552e82.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Initialize cpu_{possible, online}_map by using smp_prepare_boot_cpu().

Drop DEFINE_PER_CPU(unsigned int, cpu_id) from stubs.c as this variable isn't
expected to be used in RISC-V at all.

Move declaration of cpu_{possible,online}_map from stubs.c to smpboot.c
as now smpboot.c is now introduced.
Other defintions keep in stubs.c as they are not initialized and not needed, at
the moment.

Drop cpu_present_map as it is enough to have cpu_possible_map. Also, ask
linker to provide symbol for cpu_present_map as common code references it.

Signed-off-by: Oleksii Kurochko 
---
Changes in v2:
 - Add __read_mostly for cpu_online_map.
 - Add __ro_after_init for cpu_possible_map.
 - Drop cpu_present_map and cpumask_copy(&cpu_present_map, &cpu_possible_map);
 - Drop cpumask_clear() for cpu_{possible,online}_map.
 - Ask the linker provide the symbol for cpu_present_map as common code uses
   it.
 - s/smp_clear_cpu_maps/smp_prepare_boot_cpu.
 - Include  in setup.c as smp_prepare_boot_cpu() is declare in that
   header now.
   Also, drop inclusion of asm/smp.h in setup.c asm xen/smp.h has inclusion of
   asm/smp.h.
 - Update the commit message.
---
 xen/arch/riscv/Makefile  |  1 +
 xen/arch/riscv/setup.c   |  4 +++-
 xen/arch/riscv/smpboot.c | 12 ++++++++++++
 xen/arch/riscv/stubs.c   |  6 ------
 xen/arch/riscv/xen.lds.S |  2 ++
 5 files changed, 18 insertions(+), 7 deletions(-)
 create mode 100644 xen/arch/riscv/smpboot.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index d882c57528..f42cf3dfa6 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -10,6 +10,7 @@ obj-y += sbi.o
 obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
+obj-y += smpboot.o
 obj-y += stubs.o
 obj-y += time.o
 obj-y += traps.o
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 4e416f6e44..2a564512d7 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -19,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /* Xen stack for bringing up the first CPU. */
@@ -72,6 +72,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     remove_identity_mapping();
 
+    smp_prepare_boot_cpu();
+
     set_processor_id(0);
 
     set_cpuid_to_hartid(0, bootcpu_id);
diff --git a/xen/arch/riscv/smpboot.c b/xen/arch/riscv/smpboot.c
new file mode 100644
index 0000000000..0371dfa53e
--- /dev/null
+++ b/xen/arch/riscv/smpboot.c
@@ -0,0 +1,12 @@
+#include 
+#include 
+#include 
+
+cpumask_t __read_mostly cpu_online_map;
+cpumask_t __ro_after_init cpu_possible_map;
+
+void __init smp_prepare_boot_cpu(void)
+{
+    cpumask_set_cpu(0, &cpu_possible_map);
+    cpumask_set_cpu(0, &cpu_online_map);
+}
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index 83416d3350..fdcf91054e 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -11,12 +11,6 @@
 
 /* smpboot.c */
 
-cpumask_t cpu_online_map;
-cpumask_t cpu_present_map;
-cpumask_t cpu_possible_map;
-
-/* ID of the PCPU we're running on */
-DEFINE_PER_CPU(unsigned int, cpu_id);
 /* XXX these seem awfully x86ish... */
 /* representing HT siblings of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index 818aa43669..8c3c06de01 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -165,6 +165,8 @@ SECTIONS
     ELF_DETAILS_SECTIONS
 }
 
+PROVIDE(cpu_present_map = cpu_possible_map);
+
 ASSERT(IS_ALIGNED(__bss_start,      POINTER_ALIGN), "__bss_start is misaligned")
 ASSERT(IS_ALIGNED(__bss_end,        POINTER_ALIGN), "__bss_end is misaligned")
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977617.1364573 (Exim 4.92)
	(envelope-from )
	id 1uCLWQ-00058R-TM; Tue, 06 May 2025 16:51:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977617.1364573; Tue, 06 May 2025 16:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCLWQ-00058K-QV; Tue, 06 May 2025 16:51:58 +0000
Received: by outflank-mailman (input) for mailman id 977617;
 Tue, 06 May 2025 16:51:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWP-00058E-Fy
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:51:57 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6b5ab168-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:51:56 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ac2963dc379so858793266b.2
 for ; Tue, 06 May 2025 09:51:56 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.51.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:51: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" 
X-Inumbo-ID: 6b5ab168-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550315; x=1747155115; 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;
        bh=V/RLhiHCsiN1AHTlwEL0kP9rTdEVLgajlHgh0IyFuAo=;
        b=AupZZSeNRKWmo91Fh48hCCyuUJQbsxjbPWx60qlx4y5HnOpKjegJIYjvOqKiyYlMVs
         T5IvMFAo1VJMwympA9TgecH3c7Mh8iW+IejjDKwAWGjgz/+P+x3OJNwxhARmySCkLD4z
         gRujVabPyPwCChfyDSWAA7fMSFPRoaI2+YaRDx7k07mil6BQyhE0IspxL6TKD3+TQ2O/
         SNGcghs7jl49V2KIHmM2CTg9m1zbs+qYhelW/EG0WPQXPFqilVbb+ezpC7rXPaswDL1g
         MbkkflO/lxOtmqdOUwezCyZ1ARVdermqDMpJeXlQnaaxgNWm+s7P3B6wh60ake0fd0Wl
         f7PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550315; x=1747155115;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=V/RLhiHCsiN1AHTlwEL0kP9rTdEVLgajlHgh0IyFuAo=;
        b=qsfKgf87FPdL/pVK9rGgPNyUaFet+CCgo9k+T/e9SR5K1eXEEMzNJ+Bb9B2sa9Z5d9
         HGeHB7xHqJtJR5qtEDlvfUviKrQDn0ONQXdNDS7g0SObgxdl9gwQbeD02JkmqZV5eAqR
         dFtUAKwi4XkgayAtLEFesat4I2oAoXg3lZJE7chm3qlxHX/BbWQiEtsbLh14BCM92J2O
         x8pJE7JD+ImUkfDuHu9OBw7q/4IlN9f2jL3fNvU22jFAEaPy89bWWIdV0M+XxJnDji3h
         C7ssTZDgoWRMq2Xzj+HtIhJcqd2KeMZ2ElC0HV0pOynVkUPFHK7EGf9htZdmB2drgCHZ
         kQGQ==
X-Gm-Message-State: AOJu0YwzQya1TcHaYGuNG7yqyLXPheiMCIIRbS0ZcsistsBSWLRhvzQp
	b/GLAi0S12IAMK8jbkGL35nw8y/GGrSaG/BoG9KwHuchB3Q8i4W4bpu3Qg==
X-Gm-Gg: ASbGncv3WhRUtB80uSFSLNPY8lwqvsTgCXAOEII6JKDW9aZvy30N6jLFSxjLIbMRVLq
	IGfGG0khyZPagzYShu5mVR3FQ0Suz3biJWnXYdkxswnyRh7NkXlbIsqXO3omPpZFF//3IhF8sQZ
	imHSzqBWg4Ffm6GT2FWyG4Kb+CSapnXf6t8crB5z9y6zEWsl249yehxH5tZfRoncPjow7QQdn1j
	haQsc9nOSPE6ekpggKEBU7KDn518y72zWwqo1+sbLOWVWnxEDUy2aG0QAMHVB30dqpfxn2f4lxT
	lWkGdejay0wEyeQ4ZzodUiMHjDG/KZpLIERME82Jzg0b+lMo46dlLTPuyVA42zUouUHWc6WLzka
	4A+TxCmQWKw==
X-Google-Smtp-Source: AGHT+IHiXwKwTWVak5d5rizsrbufwwxhei23r2nUtb12UZhI0brzCDQ3SRr8xWA5EfqmoUcZsUY5eg==
X-Received: by 2002:a17:907:7fa7:b0:ac2:88d5:770b with SMTP id a640c23a62f3a-ad1e8c91ed4mr22334466b.25.1746550314962;
        Tue, 06 May 2025 09:51:54 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Doug Goldstein ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH v2 00/16] riscv: introduce basic UART support and interrupts for hypervisor mode
Date: Tue,  6 May 2025 18:51:30 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The patch series introduces basic UART support (in interrupt mode) and support of
interrupts for hypervisor mode.

To implement this the following has been added:
- APLIC and IMISC initialization.
- Introduce of intc_hw_operations abstraction.
- Introduce some APLIC and IMSIC operations.
- Introduce init_IRQ(), platform_get_irq() and setup_irq() functions.
- Update do_trap() handler to handle IRQ_S_EXT.
- Introduce some other functions such as: get_s_time(), smp_clear_cpu_maps(),
  ioremap().
- Enable UART. 

CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1802596163

---
Changes in v2:
- Split patch [PATCH v1 07/14] xen/riscv: Introduce intc_hw_operations abstraction
  into two:
  - xen/riscv: introduce register_intc_ops() and intc_hw_ops
  - xen/riscv: introduce intc_init() and helpers
  It was needed to be able to merge [PATCH v1 13/14] xen/riscv: initialize interrupt controller
  into the patch where intc_init() is introduced.
- Merge  [PATCH v1 13/14] xen/riscv: initialize interrupt controller to
  xen/riscv: introduce intc_init() and helpers.
- xen/riscv: implement get_s_time() has been merged to staging.
- All other changes please look in specific patch.
---

Oleksii Kurochko (16):
  xen/riscv: initialize bitmap to zero in
    riscv_fill_hwcap_from_isa_string()
  xen/riscv: introduce smp_prepare_boot_cpu()
  xen/riscv: introduce support of Svpbmt extension
  xen/riscv: add ioremap_*() variants using ioremap_attr()
  xen/asm-generic: introduce asm-generic/irq-dt.h
  xen/riscv: introduce init_IRQ()
  xen/riscv: introduce platform_get_irq()
  xen/riscv: dt_processor_cpuid() implementation
  xen/riscv: introduce register_intc_ops() and intc_hw_ops.
  xen/riscv: imsic_init() implementation
  xen/riscv: aplic_init() implementation
  xen/riscv: introduce intc_init() and helpers
  xen/riscv: implementation of aplic and imsic operations
  xen/riscv: add external interrupt handling for hypervisor mode
  xen/riscv: implement setup_irq()
  xen/riscv: add basic UART support

 automation/scripts/qemu-smoke-riscv64.sh |   1 +
 docs/misc/riscv/booting.txt              |   4 +
 xen/arch/arm/include/asm/Makefile        |   1 +
 xen/arch/arm/include/asm/irq.h           |  15 +-
 xen/arch/riscv/Kconfig                   |  15 +
 xen/arch/riscv/Makefile                  |   3 +
 xen/arch/riscv/aplic-priv.h              |  38 +++
 xen/arch/riscv/aplic.c                   | 309 ++++++++++++++++++
 xen/arch/riscv/cpufeature.c              |   4 +
 xen/arch/riscv/imsic.c                   | 390 +++++++++++++++++++++++
 xen/arch/riscv/include/asm/Makefile      |   1 +
 xen/arch/riscv/include/asm/aplic.h       |  73 +++++
 xen/arch/riscv/include/asm/cpufeature.h  |   1 +
 xen/arch/riscv/include/asm/fixmap.h      |   2 +-
 xen/arch/riscv/include/asm/imsic.h       |  84 +++++
 xen/arch/riscv/include/asm/intc.h        |  34 ++
 xen/arch/riscv/include/asm/io.h          |  11 +-
 xen/arch/riscv/include/asm/irq.h         |  16 +
 xen/arch/riscv/include/asm/mm-types.h    |   8 +
 xen/arch/riscv/include/asm/page.h        |  17 +-
 xen/arch/riscv/include/asm/smp.h         |   3 +
 xen/arch/riscv/intc.c                    |  59 ++++
 xen/arch/riscv/irq.c                     | 218 +++++++++++++
 xen/arch/riscv/mm.c                      |  34 ++
 xen/arch/riscv/pt.c                      |  20 +-
 xen/arch/riscv/setup.c                   |  22 +-
 xen/arch/riscv/smpboot.c                 |  78 +++++
 xen/arch/riscv/stubs.c                   |  11 -
 xen/arch/riscv/traps.c                   |  19 ++
 xen/arch/riscv/xen.lds.S                 |   2 +
 xen/drivers/char/Kconfig                 |   3 +-
 xen/include/asm-generic/irq-dt.h         |  21 ++
 32 files changed, 1470 insertions(+), 47 deletions(-)
 create mode 100644 xen/arch/riscv/aplic-priv.h
 create mode 100644 xen/arch/riscv/imsic.c
 create mode 100644 xen/arch/riscv/include/asm/aplic.h
 create mode 100644 xen/arch/riscv/include/asm/imsic.h
 create mode 100644 xen/arch/riscv/include/asm/mm-types.h
 create mode 100644 xen/arch/riscv/irq.c
 create mode 100644 xen/arch/riscv/smpboot.c
 create mode 100644 xen/include/asm-generic/irq-dt.h

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977620.1364603 (Exim 4.92)
	(envelope-from )
	id 1uCLWU-0005s4-Tu; Tue, 06 May 2025 16:52:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977620.1364603; Tue, 06 May 2025 16: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 1uCLWU-0005rx-Q5; Tue, 06 May 2025 16:52:02 +0000
Received: by outflank-mailman (input) for mailman id 977620;
 Tue, 06 May 2025 16:52:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWT-00058E-CI
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:01 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6dfe6228-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:52:00 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5fbe7a65609so301735a12.0
 for ; Tue, 06 May 2025 09:52:00 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.51.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09: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" 
X-Inumbo-ID: 6dfe6228-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550320; x=1747155120; 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;
        bh=0XrJBratYgoxj6lThS/fo/lEJSNWP1w2x9WPIUnkGfE=;
        b=JerN49cI3up5gd8Gs+smgug1o+TLdBXTv9Tu93hp+g3TZdtHJmS4o+gJZcWmbZA/M5
         WHy0maAv8kPJqWkJNzxbHndUnyK8xFwxdZrEOJAzFdAqkBnOodfPdmR7+ZGP+Nwal3RV
         CiOjjI7d8arjm6o2Nj21XjkMFZctdt0wz0HOZ0zIJB/jKPflzE9FkYYF7sr1Z1EdHToy
         P0R5GXofY4ZFqwY1jIUPF8w6QOFqVxwphsEYgnI4E9VN1KjWlFZKpHPnTwcOuY3onKuU
         NGTGbVSV+PkXH+MRgmOi08t6HIalJxG4wIZSKvX5iReeR+pASc6tNazmlexw6UiYvL8A
         VAew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550320; x=1747155120;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=0XrJBratYgoxj6lThS/fo/lEJSNWP1w2x9WPIUnkGfE=;
        b=jO+r/U0+Bzx0bauXDL38v+yo0DlR3XL3ElCQF3bAbEV2ZY9D7MmT1+P9LI3O7R6pmQ
         r3J6sDS/jkYjWKUTVv8kX1c6YwN/VibCBS4UAAqRux9v9/IzA1rPlEgnDG78uzVLbXmd
         tWY5zPxQNzuR+4HCHIbtlwacp/I+le6dupakwhpGHGwcBP+HZQbdmZp8duvR3AXW93pD
         XNpWqYa69qTprVY87fe+v8WZJK45pDlXWBV5qiW4xj7C6nIofECI3407vzcQTg+kZNca
         Liv9L3XGBiAesKucEoePqYfsVkrNXrGvzPRC9zCo9fL+b7TCSnRUDzyG4j/iooRkBkNE
         BacQ==
X-Gm-Message-State: AOJu0YzEQLJvypl4tPci9rjLCmJbDEH+lpZ2Ranlv4MKUzRBe8D7jyrA
	Mi5Eg9HAd3EdAYSRJpOXFkzSzLNUa6JetJ4CjRMGCNAKKJKTY19WjXYT4w==
X-Gm-Gg: ASbGncuvzm0TuYpUaSWqAk95UBOaqtVqwo0vRqmsWtTKnWIrOn4M7ThlqZk34LtKy7+
	SYGWOL1wlM5S6C1Iis5qpK2T4GtH0jpN2ZoyzBDQKCQiAL7LjbnJen6E5RBmoGWHvGLa0zTEJMq
	muq8t6ltgSDQVYEnaIS1iO0MdFGBTeij3a6U9lL41xnFoUTo2j16gV7247puQyCTZV5Mxfjt29n
	7CY0+5AlvBP0cA2od9f83Xr6Ilc35dXX8fQ641QsJNJpO7S1hsXGV8IgySYNKJbld8ivE8zjr0p
	iQbl1SehSP7QoagW9JZeLcog/PT8+gcE58otGx3AEcjrnnWy9MY66vgqjJldwauaIfGEciXWE8X
	Aem8jNpf/RCM8IcF7u0ZQ
X-Google-Smtp-Source: AGHT+IH4sO7YTzYDds+FCB6yWIy+bjWe6wiDQQtSWiaLC3WqXPJ/SXlBYJBWVO6nGknQ6pzedWcEWA==
X-Received: by 2002:a17:907:6b8e:b0:ac7:3323:cfd8 with SMTP id a640c23a62f3a-ad1e8bcf04dmr23506866b.16.1746550320008;
        Tue, 06 May 2025 09:52:00 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 04/16] xen/riscv: add ioremap_*() variants using ioremap_attr()
Date: Tue,  6 May 2025 18:51:34 +0200
Message-ID: <0258c1ac04a73b7d3f9f849507539a329b2998e3.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce ioremap_attr() as a shared helper to implement architecture-specific
ioremap variants:
- ioremap_nocache()
- ioremap_cache()
- ioremap_wc()

These functions use __vmap() internally and apply appropriate memory attributes
for RISC-V.

These functions are implemned not as static inline function or macros as it will
require to include asm/page.h into asm/io.h what will lead to compilation
issue.

Also, remove the unused ioremap_wt() macro from asm/io.h, as write-through
mappings are not expected to be used on RISC-V.

Signed-off-by: Oleksii Kurochko 
---
Changes in v2:
 - Update the commit subject + message.  
 - move out Svpbmt changes to separate patch.
 - Drop #ifdef SVPBMT for ioremap().
 - Redefine ioremap_* in io.h.
 - Introduce ioremap_attr().
---
 xen/arch/riscv/include/asm/io.h | 11 +++--------
 xen/arch/riscv/mm.c             | 34 +++++++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/xen/arch/riscv/include/asm/io.h b/xen/arch/riscv/include/asm/io.h
index 8bab4ffa03..921e334ce1 100644
--- a/xen/arch/riscv/include/asm/io.h
+++ b/xen/arch/riscv/include/asm/io.h
@@ -41,14 +41,9 @@
 #include 
 #include 
 
-/*
- * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
- * change the properties of memory regions.  This should be fixed by the
- * upcoming platform spec.
- */
-#define ioremap_nocache(addr, size) ioremap(addr, size)
-#define ioremap_wc(addr, size) ioremap(addr, size)
-#define ioremap_wt(addr, size) ioremap(addr, size)
+void __iomem *ioremap_nocache(paddr_t start, size_t len);
+void __iomem *ioremap_cache(paddr_t start, size_t len);
+void __iomem *ioremap_wc(paddr_t start, size_t len);
 
 /* Generic IO read/write.  These perform native-endian accesses. */
 static inline void __raw_writeb(uint8_t val, volatile void __iomem *addr)
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index d3ece9f132..c8526dd2ef 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -583,3 +584,36 @@ void *__init arch_vmap_virt_end(void)
 {
     return (void *)(VMAP_VIRT_START + VMAP_VIRT_SIZE);
 }
+
+static void *ioremap_attr(paddr_t start, size_t len, pte_attr_t attributes)
+{
+    mfn_t mfn = _mfn(PFN_DOWN(start));
+    unsigned int offs = start & (PAGE_SIZE - 1);
+    unsigned int nr = PFN_UP(offs + len);
+    void *ptr = __vmap(&mfn, nr, 1, 1, attributes, VMAP_DEFAULT);
+
+    if ( ptr == NULL )
+        return NULL;
+
+    return ptr + offs;
+}
+
+void __iomem *ioremap_nocache(paddr_t start, size_t len)
+{
+    return ioremap_attr(start, len, PAGE_HYPERVISOR_NOCACHE);
+}
+
+void __iomem *ioremap_cache(paddr_t start, size_t len)
+{
+    return ioremap_attr(start, len, PAGE_HYPERVISOR);
+}
+
+void __iomem *ioremap_wc(paddr_t start, size_t len)
+{
+    return ioremap_attr(start, len, PAGE_HYPERVISOR_WC);
+}
+
+void *ioremap(paddr_t pa, size_t len)
+{
+    return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977621.1364606 (Exim 4.92)
	(envelope-from )
	id 1uCLWV-0005v2-4j; Tue, 06 May 2025 16:52:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977621.1364606; Tue, 06 May 2025 16: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 1uCLWV-0005tz-1C; Tue, 06 May 2025 16:52:03 +0000
Received: by outflank-mailman (input) for mailman id 977621;
 Tue, 06 May 2025 16:52:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWT-0005Fd-M9
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:01 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6d7fe31c-2a9a-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:52:00 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-acb615228a4so15460366b.0
 for ; Tue, 06 May 2025 09:52:00 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.51.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09: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" 
X-Inumbo-ID: 6d7fe31c-2a9a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550319; x=1747155119; 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;
        bh=CP/6rOaeZ6U4S6TprvFe/y7WpP4kuiYu4f/W+psScZM=;
        b=Prkyg5Tqmx/wbaQaijdjg8o14QbYPf7RkLQUzgv17WcUaFfmSWh6WuybUUjxHeESWK
         67Kt/eYhlW3/P6oHxbTPk7jKSQlzfTv2ll+pUT0XaZbsnXx44pAhZdLzxtUjUoSQ7AGa
         OLQPY0BzXRWmfuBTJNGCfRusybZdbNviiz0FjJdIhcKr3gMwQBSv10yYJVDSne9Ma3E9
         9fBe2NZpmwDwmNx8gvNHJEvvJ/uefZqzd0gLrx2kSanBjl5fkMLKgSaxTXE5b9+2U7kJ
         VRMkdFxPWJOrhMKhqtb5gxZvrlDj4LPbKoh4zXkktsvqihIgog5Zlcu60lhpbYXwDCMK
         bivw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550319; x=1747155119;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=CP/6rOaeZ6U4S6TprvFe/y7WpP4kuiYu4f/W+psScZM=;
        b=WJhDdEqMhbMkQOT7NHn56j2Ju6s32WZTXohrWBj8XOqbmUMb1DuXAWYwC1M58vzSn4
         2h9bD7peo7fvKXaizlpCIKN9oXbBeuEe8oVO+6y04IV1jHD6SJgtsToErFLIUY/ItXFh
         klED/CRW4qJari0tcl3k1JKJrz9VwJcJiSctbH/BXlYaelZHx7hLLYEXQjfew4yGFW8S
         CF8DOG+MScN5EnnUCyRO/Loe0WQQt8uDrIRg3tN7X9zF048t++F5IU6lZzUjt+9HjwxI
         Zr5IhXIBtrm3n75csNJEvT06SDZd2VCf9pXN/hFevTcTF5WBx7lv98/DRrab7HzNVBx6
         6H8w==
X-Gm-Message-State: AOJu0Yy7WcjGpj5n+SKxAV4wQ6ahsmeBL5lFdgP+CLzWqF/VMyw8bt57
	qyyRxJ2ZWoCj8DNZ7jUXPFeFhSRasNZNx151aXNkTpLs5MFOMJCbDsGb/Q==
X-Gm-Gg: ASbGncurxUrBAHjCSN+7lacz1w8G57DKSbbG67fS+HznweRlzO0eD2/yjBfFxMcZxrD
	+jL43mOUBQUDIspWK3bGffDsEl/NMP6L+jfkr5mJfpTIkI8axnDQbTt8IT6Mp52pQsA9Wj1rCw0
	SVHTMSCNQLxLB2qck3ImRikhK8jyuqgMSoBRwISVKT31VCc1Jbycw6KDfrHMI+Yzqpn6M4sBCrv
	dt9R853HIzXZDI4HQN8dwoFkmOPBW8rW7yFm7o+tRcOJOIbpSQMdVM5KHOw86D2J8ksFoP247zH
	iVSsdsdmEv0UjOzWOphG5us6yzoypwpM8WPe2TlIHnYi7mtbCeqcM9LD6q6XMs768wyD6I7qwRT
	Fp7tgueshdU2bnvT7Ugy+
X-Google-Smtp-Source: AGHT+IGrou4QtyM878xmIkaXrEEYa/uriKDowKj66N3imoG9kdeaqYGWx2lXK2Xm8nYhvxA07gpStg==
X-Received: by 2002:a17:907:3e0f:b0:acb:2050:c105 with SMTP id a640c23a62f3a-ad1e794838fmr44600766b.21.1746550319005;
        Tue, 06 May 2025 09:51:59 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Doug Goldstein ,
	Stefano Stabellini ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis 
Subject: [PATCH v2 03/16] xen/riscv: introduce support of Svpbmt extension
Date: Tue,  6 May 2025 18:51:33 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Svpbmt extension is necessary for chaning the memory type for a page contains
a combination of attributes that indicate the cacheability, idempotency,
and ordering properties for access to that page.

As a part of the patch the following is introduced:
- Svpbmt memory type defintions: PTE_PBMT_{NOCACHE,IO}.
- PAGE_HYPERVISOR_{NOCACHE,WC}.
- RISCV_ISA_EXT_svpbmt and add a check in runtime that Svpbmt is
  supported by platform.
- Update riscv/booting.txt with information about Svpbmt.
- Update logic of pt_update_entry() to take into account PBMT bits.

Use 'unsigned long' for pte_attr_t as PMBT bits are 61 and 62 and it doesn't
fit into 'unsigned int'. Also, update function prototypes which uses
'unsigned int' for flags/attibutes.

Enable Svpbmt for testing in QEMU as Svpmbt is now mandatory for
Xen work.

Signed-off-by: Oleksii Kurochko 
---
Changes in v2:
 - new patch.
---
 automation/scripts/qemu-smoke-riscv64.sh |  1 +
 docs/misc/riscv/booting.txt              |  4 ++++
 xen/arch/riscv/Kconfig                   | 14 ++++++++++++++
 xen/arch/riscv/cpufeature.c              |  2 ++
 xen/arch/riscv/include/asm/cpufeature.h  |  1 +
 xen/arch/riscv/include/asm/fixmap.h      |  2 +-
 xen/arch/riscv/include/asm/mm-types.h    |  8 ++++++++
 xen/arch/riscv/include/asm/page.h        | 17 ++++++++++++++++-
 xen/arch/riscv/pt.c                      | 20 +++++++++++---------
 9 files changed, 58 insertions(+), 11 deletions(-)
 create mode 100644 xen/arch/riscv/include/asm/mm-types.h

diff --git a/automation/scripts/qemu-smoke-riscv64.sh b/automation/scripts/qemu-smoke-riscv64.sh
index b2e112c942..25f9e4190e 100755
--- a/automation/scripts/qemu-smoke-riscv64.sh
+++ b/automation/scripts/qemu-smoke-riscv64.sh
@@ -7,6 +7,7 @@ rm -f smoke.serial
 
 export TEST_CMD="qemu-system-riscv64 \
     -M virt,aia=aplic-imsic \
+    -cpu rv64,svpbmt=on \
     -smp 1 \
     -nographic \
     -m 2g \
diff --git a/docs/misc/riscv/booting.txt b/docs/misc/riscv/booting.txt
index 3a8474a27d..e100bde575 100644
--- a/docs/misc/riscv/booting.txt
+++ b/docs/misc/riscv/booting.txt
@@ -18,3 +18,7 @@ Xen is run:
 - Zihintpause:
   On a system that doesn't have this extension, cpu_relax() should be
   implemented properly.
+- SVPBMT is mandatory to enable changing the memory attributes of a page.
+  For platforms that do not support SVPBMT, it is necessary to introduce a
+  similar mechanism as described in:
+  https://lore.kernel.org/all/20241102000843.1301099-1-samuel.holland@sifive.com/
diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index d882e0a059..60520dab57 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -10,11 +10,25 @@ config RISCV
 config RISCV_64
 	def_bool y
 	select 64BIT
+	select HAS_SVPBMT
 
 config ARCH_DEFCONFIG
 	string
 	default "arch/riscv/configs/tiny64_defconfig"
 
+config HAS_SVPBMT
+	bool
+	depends on RISCV_64
+	help
+	  This config enables usage of Svpbmt ISA-extension ( Supervisor-mode:
+	  page-based memory types).
+
+	  The memory type for a page contains a combination of attributes
+	  that indicate the cacheability, idempotency, and ordering
+	  properties for access to that page.
+
+	  The Svpbmt extension is only available on 64-bit cpus.
+
 menu "Architecture Features"
 
 source "arch/Kconfig"
diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
index 3246a03624..b7d5ec6580 100644
--- a/xen/arch/riscv/cpufeature.c
+++ b/xen/arch/riscv/cpufeature.c
@@ -137,6 +137,7 @@ const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
     RISCV_ISA_EXT_DATA(zbs),
     RISCV_ISA_EXT_DATA(smaia),
     RISCV_ISA_EXT_DATA(ssaia),
+    RISCV_ISA_EXT_DATA(svpbmt),
 };
 
 static const struct riscv_isa_ext_data __initconst required_extensions[] = {
@@ -151,6 +152,7 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = {
     RISCV_ISA_EXT_DATA(zifencei),
     RISCV_ISA_EXT_DATA(zihintpause),
     RISCV_ISA_EXT_DATA(zbb),
+    RISCV_ISA_EXT_DATA(svpbmt),
 };
 
 static bool __init is_lowercase_extension_name(const char *str)
diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h
index 1015b6ee44..768b84b769 100644
--- a/xen/arch/riscv/include/asm/cpufeature.h
+++ b/xen/arch/riscv/include/asm/cpufeature.h
@@ -37,6 +37,7 @@ enum riscv_isa_ext_id {
     RISCV_ISA_EXT_zbs,
     RISCV_ISA_EXT_smaia,
     RISCV_ISA_EXT_ssaia,
+    RISCV_ISA_EXT_svpbmt,
     RISCV_ISA_EXT_MAX
 };
 
diff --git a/xen/arch/riscv/include/asm/fixmap.h b/xen/arch/riscv/include/asm/fixmap.h
index e399a15f53..5990c964aa 100644
--- a/xen/arch/riscv/include/asm/fixmap.h
+++ b/xen/arch/riscv/include/asm/fixmap.h
@@ -33,7 +33,7 @@
 extern pte_t xen_fixmap[];
 
 /* Map a page in a fixmap entry */
-void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags);
+void set_fixmap(unsigned int map, mfn_t mfn, pte_attr_t flags);
 /* Remove a mapping from a fixmap entry */
 void clear_fixmap(unsigned int map);
 
diff --git a/xen/arch/riscv/include/asm/mm-types.h b/xen/arch/riscv/include/asm/mm-types.h
new file mode 100644
index 0000000000..fa512064b8
--- /dev/null
+++ b/xen/arch/riscv/include/asm/mm-types.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef ASM_RISCV_MM_TYPES_H
+#define ASM_RISCV_MM_TYPES_H
+
+typedef unsigned long pte_attr_t;
+
+#endif /* ASM_RISCV_MM_TYPES_H */
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index bf8988f657..2af4823170 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -46,6 +46,8 @@
 #define PAGE_HYPERVISOR_RX          (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE)
 
 #define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
+#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PMBT_IO)
+#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PMBT_NOCACHE)
 
 /*
  * The PTE format does not contain the following bits within itself;
@@ -56,8 +58,21 @@
 #define PTE_SMALL       BIT(10, UL)
 #define PTE_POPULATE    BIT(11, UL)
 
+/*
+ * [62:61] Svpbmt Memory Type definitions:
+ *
+ *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
+ *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
+ *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
+ *  11 - Rsvd   Reserved for future standard use
+ */
+#define PTE_PMBT_NOCACHE    BIT(61, UL)
+#define PTE_PMBT_IO         BIT(62, UL)
+
 #define PTE_ACCESS_MASK (PTE_READABLE | PTE_WRITABLE | PTE_EXECUTABLE)
 
+#define PTE_PBMT_MASK   (PTE_PMBT_NOCACHE | PTE_PMBT_IO)
+
 /* Calculate the offsets into the pagetables for a given VA */
 #define pt_linear_offset(lvl, va)   ((va) >> XEN_PT_LEVEL_SHIFT(lvl))
 
@@ -202,7 +217,7 @@ static inline pte_t read_pte(const pte_t *p)
     return read_atomic(p);
 }
 
-static inline pte_t pte_from_mfn(mfn_t mfn, unsigned int flags)
+static inline pte_t pte_from_mfn(mfn_t mfn, pte_attr_t flags)
 {
     unsigned long pte = (mfn_x(mfn) << PTE_PPN_SHIFT) | flags;
     return (pte_t){ .pte = pte };
diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c
index 918b1b91ab..82c8c73c3e 100644
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -25,7 +25,7 @@ static inline mfn_t get_root_page(void)
  * See the comment about the possible combination of (mfn, flags) in
  * the comment above pt_update().
  */
-static bool pt_check_entry(pte_t entry, mfn_t mfn, unsigned int flags)
+static bool pt_check_entry(pte_t entry, mfn_t mfn, pte_attr_t flags)
 {
     /* Sanity check when modifying an entry. */
     if ( (flags & PTE_VALID) && mfn_eq(mfn, INVALID_MFN) )
@@ -260,7 +260,7 @@ pte_t pt_walk(vaddr_t va, unsigned int *pte_level)
  */
 static int pt_update_entry(mfn_t root, vaddr_t virt,
                            mfn_t mfn, unsigned int *target,
-                           unsigned int flags)
+                           pte_attr_t flags)
 {
     int rc;
     /*
@@ -328,17 +328,19 @@ static int pt_update_entry(mfn_t root, vaddr_t virt,
         pte.pte = 0;
     else
     {
+        const pte_attr_t attrs = PTE_ACCESS_MASK | PTE_PBMT_MASK;
+
         /* We are inserting a mapping => Create new pte. */
         if ( !mfn_eq(mfn, INVALID_MFN) )
             pte = pte_from_mfn(mfn, PTE_VALID);
-        else /* We are updating the permission => Copy the current pte. */
+        else /* We are updating the attributes => Copy the current pte. */
         {
             pte = *ptep;
-            pte.pte &= ~PTE_ACCESS_MASK;
+            pte.pte &= ~attrs;
         }
 
-        /* update permission according to the flags */
-        pte.pte |= (flags & PTE_ACCESS_MASK) | PTE_ACCESSED | PTE_DIRTY;
+        /* Update attributes of PTE according to the flags. */
+        pte.pte |= (flags & attrs) | PTE_ACCESSED | PTE_DIRTY;
     }
 
     write_pte(ptep, pte);
@@ -353,7 +355,7 @@ static int pt_update_entry(mfn_t root, vaddr_t virt,
 
 /* Return the level where mapping should be done */
 static int pt_mapping_level(unsigned long vfn, mfn_t mfn, unsigned long nr,
-                            unsigned int flags)
+                            pte_attr_t flags)
 {
     unsigned int level = 0;
     unsigned long mask;
@@ -407,7 +409,7 @@ static DEFINE_SPINLOCK(pt_lock);
  * inserting will be done.
  */
 static int pt_update(vaddr_t virt, mfn_t mfn,
-                     unsigned long nr_mfns, unsigned int flags)
+                     unsigned long nr_mfns, pte_attr_t flags)
 {
     int rc = 0;
     unsigned long vfn = PFN_DOWN(virt);
@@ -535,7 +537,7 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 }
 
 /* Map a 4k page in a fixmap entry */
-void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags)
+void set_fixmap(unsigned int map, mfn_t mfn, pte_attr_t flags)
 {
     if ( map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL) != 0 )
         BUG();
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977622.1364621 (Exim 4.92)
	(envelope-from )
	id 1uCLWW-0006Kn-Hm; Tue, 06 May 2025 16:52:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977622.1364621; Tue, 06 May 2025 16: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 1uCLWW-0006Jp-EI; Tue, 06 May 2025 16:52:04 +0000
Received: by outflank-mailman (input) for mailman id 977622;
 Tue, 06 May 2025 16:52:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWV-0005Fd-CC
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:03 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6e97b02a-2a9a-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:52:01 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5e5e8274a74so9110650a12.1
 for ; Tue, 06 May 2025 09:52:01 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09: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" 
X-Inumbo-ID: 6e97b02a-2a9a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550321; x=1747155121; 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;
        bh=fyH7+jYUX1HojA9xgArUa6tCu0OjPcD2ug7vub4dMik=;
        b=GENtsU4FRYgUvlOcNdU0wKOW4uzsiaIHUu2TotLCeVh8O/qLEPyKQFA6ZkjvM/57Tz
         YniyiUl+Yd69PMsPOTVlvLl5UQXkEM62BF1i8pIuwtF2dZHb9ExDq8BuCKdybpvexv4Z
         2yQsMo/T0f1iUsxoe4Maox0/nimzfzzuOPxwtKwoqDpI//R71Xx+vjoF/olgWX4Gb4eh
         qPt83Mea0owFaJqMMTbX+liF9QEcY8C8KR3mjKZmcraByaCDdG0vi67jc2T1lgmCEiXV
         v2m4MA4npMOd5dkJswQ/kUdCPVqVN3A5nMqm0ffBbtrN11XfCMeuQF5Ipe5slU5tv5MR
         MEgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550321; x=1747155121;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fyH7+jYUX1HojA9xgArUa6tCu0OjPcD2ug7vub4dMik=;
        b=SEdQdkvKQtSi72nbJyy9TWCg4qhetigczwvXMOsRAEYTrgNdRXavEzNaXLeQDE7ZRJ
         RQQ8AUEt8j/7IdNtwvgR/OvehK44kmGWNL3K6ueUNGDr+VnuxFBM5BWS2h8tSInGJ+P2
         RE1vJ+OqAIqTL7skhU6G8HY4TC9wLZvja+peYp9VweQRDzUgMvRTyfnpOcgDgtq7foTM
         ewlFM0qx6uZ6KRz8xST0BzCakMC0pDokdAtXntFlVZTQDtRnWzDmQ6NsekhCVcLiCPBQ
         vijETvnNlLvBKZBqY/L67hF2nAETz17bzoDeOYiy95ntOGTqZK21/DB/rz64BYT7+XeW
         KX5g==
X-Gm-Message-State: AOJu0YxjoUOgsPO7d7CRnhQeEVt4B7GjykazkMCVEBlYViIYyYyz9Q9Y
	wZYdgTLbIylthd14fDyZIb8gqgQn+n/+bwVF08F2cHKlMOnZ2gCjl8DF7g==
X-Gm-Gg: ASbGncvEs8xfwYRFOSXbT5zwEeBv4MM/WfLL/TdaSVYGe6CyBHejUASLjXORv4RbFzU
	prgbxq0+eVOz2bfAvMm1vVKCSiayeX+5+ISgvZG+32i3ByU9C/W6trSQSmyq1Nxjsu4GQ8CUaFs
	bCIMY4pZkC0ovkyITblPHJptjvyQAhY0oJnNqtopdqftV4xRBu6FoopwlqQw8C2kmcvOucNqaAY
	vX4cypA9vlikse+AHJ3zuED89r00n+l3psSTLBIKKTXubvGuDwgzca+uZAHE72OXX/o9TpTnHr/
	DxuIf+kuf0zVmx+MAyo7PhBczmj4JDmNp1dhknxNliGcuL4P7bvYgJdkt5fWdt23JRDZQ6+iKzj
	Z0L23kx6gjw==
X-Google-Smtp-Source: AGHT+IGGmxCuy3frsT81IH5iVwWAXyfW7soT6GVZbGd9aCkHofw5Csv2YIhMKzuXyZSLhlpIO1JLsQ==
X-Received: by 2002:a17:907:7da5:b0:ac3:48e4:f8bc with SMTP id a640c23a62f3a-ad1e8d54c0dmr14428266b.48.1746550320907;
        Tue, 06 May 2025 09:52:00 -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 v2 05/16] xen/asm-generic: introduce asm-generic/irq-dt.h
Date: Tue,  6 May 2025 18:51:35 +0200
Message-ID: <35c68e57e5348c6610e030890802e967f6be4230.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce defintions of IRQ_TYPE_* which correspond to the Xen internal
representation of the IRQ types and make them the same asthe existing
device tree defintions for convenience.

These defines are going to be re-used, at least, by RISC-V architecture.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - new patch.
---
 xen/arch/arm/include/asm/Makefile |  1 +
 xen/arch/arm/include/asm/irq.h    | 15 +--------------
 xen/include/asm-generic/irq-dt.h  | 21 +++++++++++++++++++++
 3 files changed, 23 insertions(+), 14 deletions(-)
 create mode 100644 xen/include/asm-generic/irq-dt.h

diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile
index 831c914cce..87c8821421 100644
--- a/xen/arch/arm/include/asm/Makefile
+++ b/xen/arch/arm/include/asm/Makefile
@@ -4,6 +4,7 @@ generic-y += device.h
 generic-y += dom0less-build.h
 generic-y += hardirq.h
 generic-y += iocap.h
+generic-y += irq-dt.h
 generic-y += paging.h
 generic-y += percpu.h
 generic-y += random.h
diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h
index 88e060bf29..fce7e42a33 100644
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -4,20 +4,7 @@
 #include 
 #include 
 
-/*
- * These defines correspond to the Xen internal representation of the
- * IRQ types. We choose to make them the same as the existing device
- * tree definitions for convenience.
- */
-#define IRQ_TYPE_NONE           DT_IRQ_TYPE_NONE
-#define IRQ_TYPE_EDGE_RISING    DT_IRQ_TYPE_EDGE_RISING
-#define IRQ_TYPE_EDGE_FALLING   DT_IRQ_TYPE_EDGE_FALLING
-#define IRQ_TYPE_EDGE_BOTH      DT_IRQ_TYPE_EDGE_BOTH 
-#define IRQ_TYPE_LEVEL_HIGH     DT_IRQ_TYPE_LEVEL_HIGH
-#define IRQ_TYPE_LEVEL_LOW      DT_IRQ_TYPE_LEVEL_LOW
-#define IRQ_TYPE_LEVEL_MASK     DT_IRQ_TYPE_LEVEL_MASK
-#define IRQ_TYPE_SENSE_MASK     DT_IRQ_TYPE_SENSE_MASK
-#define IRQ_TYPE_INVALID        DT_IRQ_TYPE_INVALID
+#include 
 
 #define NR_VECTORS 256 /* XXX */
 
diff --git a/xen/include/asm-generic/irq-dt.h b/xen/include/asm-generic/irq-dt.h
new file mode 100644
index 0000000000..5ec46da533
--- /dev/null
+++ b/xen/include/asm-generic/irq-dt.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __ASM_GENERIC_IRQ_DT_H__
+#define __ASM_GENERIC_IRQ_DT_H__
+
+/*
+ * These defines correspond to the Xen internal representation of the
+ * IRQ types. We choose to make them the same as the existing device
+ * tree definitions for convenience.
+ */
+#define IRQ_TYPE_NONE           DT_IRQ_TYPE_NONE
+#define IRQ_TYPE_EDGE_RISING    DT_IRQ_TYPE_EDGE_RISING
+#define IRQ_TYPE_EDGE_FALLING   DT_IRQ_TYPE_EDGE_FALLING
+#define IRQ_TYPE_EDGE_BOTH      DT_IRQ_TYPE_EDGE_BOTH
+#define IRQ_TYPE_LEVEL_HIGH     DT_IRQ_TYPE_LEVEL_HIGH
+#define IRQ_TYPE_LEVEL_LOW      DT_IRQ_TYPE_LEVEL_LOW
+#define IRQ_TYPE_LEVEL_MASK     DT_IRQ_TYPE_LEVEL_MASK
+#define IRQ_TYPE_SENSE_MASK     DT_IRQ_TYPE_SENSE_MASK
+#define IRQ_TYPE_INVALID        DT_IRQ_TYPE_INVALID
+
+#endif /* __ASM_GENERIC_IRQ_DT_H__ */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977623.1364633 (Exim 4.92)
	(envelope-from )
	id 1uCLWY-0006de-5C; Tue, 06 May 2025 16:52:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977623.1364633; Tue, 06 May 2025 16: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 1uCLWX-0006cp-Vu; Tue, 06 May 2025 16:52:05 +0000
Received: by outflank-mailman (input) for mailman id 977623;
 Tue, 06 May 2025 16:52:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWW-00058E-8P
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:04 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6faca94b-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:52:03 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5f6c3f7b0b0so11799413a12.0
 for ; Tue, 06 May 2025 09:52:03 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09: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" 
X-Inumbo-ID: 6faca94b-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550323; x=1747155123; 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;
        bh=sQmSVGxqEnAHeu+UgiQeZLUtUFIRNIGEg4FW26txKNs=;
        b=OSNe/ndfvuDC822lP2dM8YoshI0hRUVFlEkJdsr8tz4mH+OAsqkUgZjLZOUaQGDwPB
         RZKU/DHQ0mBxmURhrbIsQM82QQ35K/CRftGvMTi+6owsKvD2MhJGb+T1XkamIrywJNFy
         f48+jdJbaOMyjBAniykbAEAjvIyDBHkBTQuUQCts9lLscJT+EJTtbEJP8aN34Y9dC6SV
         9sAAnDI+oJNsTJYu3P+5LG0h3jn4l/myb1jbEj+N32wGRcXjwYAg69IyTDcO4HOl0SKO
         /me3y4pc2fJOvnVvcC3UrqwAppJzA2h/yBUSusMlCDGLi3ZEBl1vsbw2/ltSyGFlfeX5
         maMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550323; x=1747155123;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=sQmSVGxqEnAHeu+UgiQeZLUtUFIRNIGEg4FW26txKNs=;
        b=FgVWcDEtnhb638WdTG+XBVDZW4clzJ2izVndl70kEqF0M8aJmWxAZsFzy0dtRmcQV6
         swO7Zw0kRzsTOoctV7+2vCn/aeyIDxUhiaiKEZhwi9F0w3isjekNGqB2pe6l7+v3Jc+E
         Inha7PqXZyiovvL7droXmCPD/GBLBjK5yNFIVxBoOE7fow7uW73UZdecBuYxGegsZrb+
         JShFU+oNaVIE0Ul3JxuVfWhIdagMEH98d5PUoxWFOOiN1y3LyzPUGEfqbXDs4SOx02Gw
         osjO1ZciSxn+e3rwTwxPLvwFMnFVIv8X5QxQzmJtGmd7tgQKTNbk/nYaB/xgFJWtcoXl
         +eYw==
X-Gm-Message-State: AOJu0YzN2xT5M62HNCg1QSc8sdgtFwi/JMupSWcbrsyvQMI5NRcUSOpR
	CCTZxry7x3Ty8H94c1Ap5Nztl16XOIp9L2t8fAWptep101EyKmmxYkXK+g==
X-Gm-Gg: ASbGncv99+BJMt5UfgmQ0pPd75IKcAja5Sd0fCtzTlSwgXAEl811bdFblJfUbP8OrzE
	j6WRaqvvdId70WwbZwk+hf7gs5h0heCDMLvF+Q+NbNermiylVb9mXUc1CfjxVqHTj7LYUssWUjO
	b5CIb5f1B/IuUponO9ySg2blnUKi9y6Mkpg8fs0EfEAhD07fCPMsSwP+GR5gx2P/v4d/2NitzFm
	Su3OSvZHIyWjfUDdpC7oFa5Y6yvcw5KMx198ul3bJC4k3KKNuzuCuFWU3aFaPzydfIUN0GKny7u
	xZMxDhxbz42e5K/J7uAybzwMKsmrMqyrLau7SJTaXxLa3fvm8Igpd4xulgGeWq2Ql5629j90vG5
	avvInGIR9Dap51Y/wFOYj
X-Google-Smtp-Source: AGHT+IEmGcXV6QzEG20w+umThYUL14rC7eZyQsSdWYUQrMcXWQKyWCRp4acrsSIB59X1kJW/UWJMRQ==
X-Received: by 2002:a17:907:8688:b0:ad1:8dd3:a4eb with SMTP id a640c23a62f3a-ad1e8d0d9e5mr16872366b.56.1746550322718;
        Tue, 06 May 2025 09:52:02 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v2 07/16] xen/riscv: introduce platform_get_irq()
Date: Tue,  6 May 2025 18:51:37 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

platform_get_irq() recieves information about device's irq ( type
and irq number ) from device tree node and using this information
update irq descriptor in irq_desc[] array.

Introduce dt_irq_xlate and initialize with aplic_irq_xlate() as
it is used by dt_device_get_irq() which is called by
platform_get_irq().

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - Add cf_check for aplic_irq_xlate().
 - Ident label in irq_set_type().
 - Return proper -E... values for platform_get_irq().
---
 xen/arch/riscv/aplic.c           | 20 +++++++++++++++
 xen/arch/riscv/include/asm/irq.h |  3 +++
 xen/arch/riscv/irq.c             | 42 ++++++++++++++++++++++++++++++++
 3 files changed, 65 insertions(+)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index caba8f8993..10ae81f7ac 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -21,6 +22,23 @@ static struct intc_info __ro_after_init aplic_info = {
     .hw_version = INTC_APLIC,
 };
 
+static int cf_check aplic_irq_xlate(const uint32_t *intspec,
+                                    unsigned int intsize,
+                                    unsigned int *out_hwirq,
+                                    unsigned int *out_type)
+{
+    if ( intsize < 2 )
+        return -EINVAL;
+
+    /* Mapping 1:1 */
+    *out_hwirq = intspec[0];
+
+    if ( out_type )
+        *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
+
+    return 0;
+}
+
 static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 {
     if ( aplic_info.node )
@@ -35,6 +53,8 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     aplic_info.node = node;
 
+    dt_irq_xlate = aplic_irq_xlate;
+
     return 0;
 }
 
diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index f609df466e..6223bbbed5 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -30,6 +30,9 @@ static inline void arch_move_irqs(struct vcpu *v)
     BUG_ON("unimplemented");
 }
 
+struct dt_device_node;
+int platform_get_irq(const struct dt_device_node *device, int index);
+
 void init_IRQ(void);
 
 #endif /* ASM__RISCV__IRQ_H */
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index 26a8556b2c..4c518bbd97 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -7,11 +7,53 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 
 static irq_desc_t irq_desc[NR_IRQS];
 
+static bool irq_validate_new_type(unsigned int curr, unsigned int new)
+{
+    return (curr == IRQ_TYPE_INVALID || curr == new );
+}
+
+static int irq_set_type(unsigned int irq, unsigned int type)
+{
+    unsigned long flags;
+    struct irq_desc *desc = irq_to_desc(irq);
+    int ret = -EBUSY;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    if ( !irq_validate_new_type(desc->arch.type, type) )
+        goto err;
+
+    desc->arch.type = type;
+
+    ret = 0;
+
+ err:
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    return ret;
+}
+
+int platform_get_irq(const struct dt_device_node *device, int index)
+{
+    struct dt_irq dt_irq;
+    int ret;
+
+    if ( (ret = dt_device_get_irq(device, index, &dt_irq)) != 0 )
+        return ret;
+
+    if ( (ret = irq_set_type(dt_irq.irq, dt_irq.type)) != 0 )
+        return ret;
+
+    return dt_irq.irq;
+}
+
 int arch_init_one_irq_desc(struct irq_desc *desc)
 {
     desc->arch.type = IRQ_TYPE_INVALID;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977624.1364637 (Exim 4.92)
	(envelope-from )
	id 1uCLWY-0006hn-Gu; Tue, 06 May 2025 16:52:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977624.1364637; Tue, 06 May 2025 16: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 1uCLWY-0006gW-Aq; Tue, 06 May 2025 16:52:06 +0000
Received: by outflank-mailman (input) for mailman id 977624;
 Tue, 06 May 2025 16:52:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWW-0005Fd-QZ
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:04 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6f4dc4d7-2a9a-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:52:03 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5f4d28d9fd8so8043963a12.3
 for ; Tue, 06 May 2025 09:52:03 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:52: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" 
X-Inumbo-ID: 6f4dc4d7-2a9a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550322; x=1747155122; 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;
        bh=VHCbbRGzj4TST1ZsXheYq6XK3zRbfzwB/XvisLJirH0=;
        b=ag6sWFCV+p+di9Xz75ujonVLLUglMX9kcPcLu/iINlB74xCwanukKOkrW8MknUkg79
         N+fz5be2s1GT2NlbnE2oUK5g+Q1AMlGja968XSqXnuVtWdx9+SZMIccwbpuBDfj1+u1V
         IqdUOTVUWwOWQXvGwK6DzuUOTvubQzUZaedy+59FV0fXE+L0qTwzmbuZDHjpNBoqja1/
         Vy+YNZ5zZUusGGYT5fmE+iCnHjzKke401MU2eCQy+sT7oxMrcYeEVYY67M+GkmUEpbTt
         0N3BuCcF8lge8Kpuw8CbdEfJEfvDlOO55xTKEvwrdaNf6hfgc/6fb9Ji0PkYAiADsR28
         Ld/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550322; x=1747155122;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=VHCbbRGzj4TST1ZsXheYq6XK3zRbfzwB/XvisLJirH0=;
        b=KY9QCKWV2UJyDWV3VrBDBmSMf6tzHBNz6S3q9NANgr9BXeK3CK9xgvLZS2mOxDXi6K
         Emu4/aGqX3dmgv19G52COJPCkCbdugLwUbXH4t4BXkRvTU6NxLwczC91ay5Q7DtP532y
         9h7C0DOELGLHwCtHkhmG+829gTheVVxoU5Eqwxeu/1oJKyS4xKJyTw3S8tkPzy9so/ii
         uDw7PzNulGwvP0teEOafF2niX1K5DarN3Wo5Nbb7za7Qsd8zXmigz2RUVz+WObLBDLrd
         vIJDEIIYYXEpQFGP+ibUUDDjkJxvXkzd7IBrqQE/FvzYFRuf/kTVQVemPlEVrT3LWWtN
         041Q==
X-Gm-Message-State: AOJu0YwtBwu46yLwKfGlGcFJhCEivd2ZAn0snidTkRIheAohxDh9Pro8
	XJ6MIGDFJNptbaEk3v8nR+Mkm4fIsGEuR+k8EjfGIt8z0iz1EkfvXbS17w==
X-Gm-Gg: ASbGncsn/Ht7p+Uk0SP8MQTVOswyR8MDLXG1D31aqgUvO6YtGURMWpJwNmZCB433ZVk
	3uwDN0x4vNt23rZkG5CvcHk1QZBZ9ZJ2zBfHoQIM3Zh7jNtxTlvmGQdw3+E0nn37DaBOlMnxILq
	9LCc7HYb9oTd/VJTpuMu3J25cSPtCkUEwkw/1D+5f1jZIHOJjs6dv4TjnJTWB489/1tBdskj8px
	UHDkQxlAb/7SAKjSlk44NczCdXGSj9usCmFZMjR+d65fGOArZZxTAlo8Z013xQ4i1GJ9LujoBCJ
	vGGdnwMlQzvQ4lbqudfdBZAgQW7vBR9C0RxT4IRznRWnwIPg96Tq6+vHxchYZo5WMCVAFPz9psG
	WaSe3XLNcWg==
X-Google-Smtp-Source: AGHT+IHhSY+w3Z9D7TNCdbEZhWTvpADf4qlmFfIEJoqjGUaK29lnjmPIHlr+7GaSvrY9Z1VrTlwMVg==
X-Received: by 2002:a17:907:874e:b0:ace:cb59:6c4d with SMTP id a640c23a62f3a-ad1e8d545eemr16010866b.43.1746550321861;
        Tue, 06 May 2025 09:52:01 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 06/16] xen/riscv: introduce init_IRQ()
Date: Tue,  6 May 2025 18:51:36 +0200
Message-ID: <2a57200785c710a5203a116bf9a933b4ea12d112.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement init_IRQ() to initalize various IRQs.

Currently, this function initializes the irq_desc[] array,
which stores IRQ descriptors containing various information
about each IRQ, such as the type of hardware handling, whether
the IRQ is disabled, etc.
The initialization is basic at this point and includes setting
IRQ_TYPE_INVALID as the IRQ type, assigning the IRQ number ( which
is just a consequent index of irq_desc[] array ) to
desc->irq, and setting desc->action to NULL.

Additionally, the function init_irq_data() is introduced to
initialize the IRQ descriptors for all IRQs in the system.

Reuse defines of IRQ_TYPE_* from asm-generic/irq-dt.h.

Signed-off-by: Oleksii Kurochko 
---
Changes in v2:
 - Move an introduction of IRQ_TYPE_* defines to the separate patch.
 - Reuse asm-generic/irq-dt.h.
 - Use 'unsigned int' for local irq variable inside init_irq_data().
---
 xen/arch/riscv/Makefile             |  1 +
 xen/arch/riscv/include/asm/Makefile |  1 +
 xen/arch/riscv/include/asm/irq.h    |  7 +++++
 xen/arch/riscv/irq.c                | 45 +++++++++++++++++++++++++++++
 xen/arch/riscv/setup.c              |  3 ++
 xen/arch/riscv/stubs.c              |  5 ----
 6 files changed, 57 insertions(+), 5 deletions(-)
 create mode 100644 xen/arch/riscv/irq.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index f42cf3dfa6..a1c145c506 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -3,6 +3,7 @@ obj-y += cpufeature.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
 obj-y += intc.o
+obj-y += irq.o
 obj-y += mm.o
 obj-y += pt.o
 obj-$(CONFIG_RISCV_64) += riscv64/
diff --git a/xen/arch/riscv/include/asm/Makefile b/xen/arch/riscv/include/asm/Makefile
index c989a7f89b..bfdf186c68 100644
--- a/xen/arch/riscv/include/asm/Makefile
+++ b/xen/arch/riscv/include/asm/Makefile
@@ -5,6 +5,7 @@ generic-y += div64.h
 generic-y += hardirq.h
 generic-y += hypercall.h
 generic-y += iocap.h
+generic-y += irq-dt.h
 generic-y += paging.h
 generic-y += percpu.h
 generic-y += perfc_defn.h
diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 2a48da2651..f609df466e 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -3,6 +3,11 @@
 #define ASM__RISCV__IRQ_H
 
 #include 
+#include 
+
+#include 
+
+#define NR_IRQS 1024
 
 /* TODO */
 #define nr_irqs 0U
@@ -25,6 +30,8 @@ static inline void arch_move_irqs(struct vcpu *v)
     BUG_ON("unimplemented");
 }
 
+void init_IRQ(void);
+
 #endif /* ASM__RISCV__IRQ_H */
 
 /*
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
new file mode 100644
index 0000000000..26a8556b2c
--- /dev/null
+++ b/xen/arch/riscv/irq.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+/*
+ * RISC-V Trap handlers
+ *
+ * Copyright (c) 2024 Vates
+ */
+
+#include 
+#include 
+#include 
+
+static irq_desc_t irq_desc[NR_IRQS];
+
+int arch_init_one_irq_desc(struct irq_desc *desc)
+{
+    desc->arch.type = IRQ_TYPE_INVALID;
+
+    return 0;
+}
+
+static int __init init_irq_data(void)
+{
+    unsigned int irq;
+
+    for ( irq = 0; irq < NR_IRQS; irq++ )
+    {
+        struct irq_desc *desc = irq_to_desc(irq);
+        int rc = init_one_irq_desc(desc);
+
+        if ( rc )
+            return rc;
+
+        desc->irq = irq;
+        desc->action  = NULL;
+    }
+
+    return 0;
+}
+
+void __init init_IRQ(void)
+{
+    if ( init_irq_data() < 0 )
+        panic("initialization of IRQ data failed\n");
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 2a564512d7..82f8839eff 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -127,6 +128,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
         panic("Booting using ACPI isn't supported\n");
     }
 
+    init_IRQ();
+
     riscv_fill_hwcap();
 
     preinit_xen_time();
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index fdcf91054e..e396b67cd3 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -107,11 +107,6 @@ void irq_ack_none(struct irq_desc *desc)
     BUG_ON("unimplemented");
 }
 
-int arch_init_one_irq_desc(struct irq_desc *desc)
-{
-    BUG_ON("unimplemented");
-}
-
 void smp_send_state_dump(unsigned int cpu)
 {
     BUG_ON("unimplemented");
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977626.1364642 (Exim 4.92)
	(envelope-from )
	id 1uCLWZ-0006n6-0L; Tue, 06 May 2025 16:52:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977626.1364642; Tue, 06 May 2025 16: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 1uCLWY-0006lF-Nq; Tue, 06 May 2025 16:52:06 +0000
Received: by outflank-mailman (input) for mailman id 977626;
 Tue, 06 May 2025 16:52:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWX-00058E-8i
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:05 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 70383527-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:52:04 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad1e8e2ad6bso10302866b.0
 for ; Tue, 06 May 2025 09:52:04 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:52:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 70383527-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550324; x=1747155124; 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;
        bh=z/SOhxgkw308OBnI/WK3THzBCPwOXi+kerygsTpNW/c=;
        b=D4NOB6ptEIxC5npJN0Sk9fwO6z/0WMtE/RYMOvzbgeXd+iAkzP8l2xyP8YWYwaFgkW
         H8GMJaJEQ4iddQvRffS52Gc4JzYUsIedTgATvXUtGMi+x3Chr3qeK9YebVIyx2SSUslY
         2q8PEPV7vUnxstz3LONA4/3wvXEqkgadVTHeMBW4Cjs6e3UrVQWdsFZWUU138UW/Rny8
         s9+UcyK6YoxCucFPz8ZOQ5TFgE2Ik/2mzgj4j9rEoYyjLvUj/xNZ8YbCHagF+KCW3dBv
         d6fJYhFLFCNaCD6AHhZuE0JmBo5T0W6zOGceNnde2MkFjcEbhaQW/QrmN8RFl2Q1iEXe
         ow8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550324; x=1747155124;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=z/SOhxgkw308OBnI/WK3THzBCPwOXi+kerygsTpNW/c=;
        b=arRqC/O080TUGHsM8aBTb/ftlJqPoYCP1zgwi82hJBq3WXY7TGSE2NmauzWXa4t6fi
         J534qU5CWhxC1W7gwI2VlkZF9p4gMybYbzJpPdLIha1EtYhVgD5j1R1IU1LFeAXae2BI
         NXiuiaYdv9UD8QqNoARkHeZa18ZEovdd0uthgLf8YjeltBgxNlVMIXV17eVi54flmb3h
         4U/GnHdKvevaEQxFF98CMq9HncasBfFBlXSUZHXKKAHn5bXaT79RMQzURftLkgL/6icr
         y3U+9mSwkOs9zlmD5JM95V3+4TjZcG7ofO8F/00Y5jj7MAen0MaGKjs3r51iIbYLRiVI
         m+6w==
X-Gm-Message-State: AOJu0Yyx34/xt4tpn0L0WsZxGUQ0gZ1LXh6WKpTPN7cqVHSB9A3sEomn
	NCUMh/TB50qGirgMFhbw6C4tsUFpW2L47NgSyCWBdBQSD4d3qZ6GjVPUoA==
X-Gm-Gg: ASbGncsGvQkJ+8U9pVLH5w4rXah0E8fUJLjUmZ5h+ghpN3KKqBxODK/kSTa5k5LrLuW
	q23bay797GPnOy0h9/ke4whGpyF5YpOsYHCdi/Jhueeqp8p9HKXOTgGXvWUx584timmspqMWaMu
	JB7ntrEiTkkmuMrssGPGA4yVGrKrRNKnbu5cVIFGeY3Flt1diLMGPSHfpBmVyQKdj8q3WUNMFUl
	T4dAhAFoePJCDa1gwRJ3i/wlVvthRZDTtRk5sxkHWzUgQXw7QocaTwr6BsqQreMQPDhcTKko1/5
	s7+HJEh6v6cubrJtpg+QL5UFct8s2iB/NTiQdn4dvTZKP+w99KPpaYTlo0bxk9m62rMMwyHyzsy
	JzBw6DwdJUQ==
X-Google-Smtp-Source: AGHT+IF+FS9dHY4GSxXwKN6enokBJRUqaQYv2BAPkxz/tU1ShkpWmC/odJCtGf+4FrCKRACOPu0VRg==
X-Received: by 2002:a17:907:3e9b:b0:aca:a539:be04 with SMTP id a640c23a62f3a-ad1e8c8bfecmr20744966b.4.1746550323669;
        Tue, 06 May 2025 09:52:03 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 08/16] xen/riscv: dt_processor_cpuid() implementation
Date: Tue,  6 May 2025 18:51:38 +0200
Message-ID: <4e4b3a018e8dacbe85cc080d9209e2ba3cdf4330.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implements dt_processor_hartid() to get the hart ID of the given
device tree node and do some checks if CPU is available and given device
tree node has proper riscv,isa property.

As a helper function dt_get_cpuid() is introduced to deal specifically
with reg propery of a CPU device node.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - s/of_get_cpu_hwid()/dt_get_cpu_id().
 - Update prototype of dt_get_cpu_hwid(), use pointer-to-const for cpun arg.
 - Add empty line before last return in dt_get_cpu_hwid().
 - s/riscv_of_processor_hartid/dt_processor_cpuid().
 - Use pointer-to_const for node argument of dt_processor_cpuid().
 - Use for hart_id unsigned long type as according to the spec for RV128
   mhartid register will be 128 bit long.
 - Update commit message and subject.
 - use 'CPU' instead of 'HART'.
 - Drop thread argument of dt_get_cpu_id() (of_get_cpu_hwid) as it is
   expected to be always 0 according to RISC-V's DTS binding.
---
 xen/arch/riscv/include/asm/smp.h |  3 ++
 xen/arch/riscv/smpboot.c         | 66 ++++++++++++++++++++++++++++++++
 2 files changed, 69 insertions(+)

diff --git a/xen/arch/riscv/include/asm/smp.h b/xen/arch/riscv/include/asm/smp.h
index 5e170b57b3..9d846a1338 100644
--- a/xen/arch/riscv/include/asm/smp.h
+++ b/xen/arch/riscv/include/asm/smp.h
@@ -26,6 +26,9 @@ static inline void set_cpuid_to_hartid(unsigned long cpuid,
 
 void setup_tp(unsigned int cpuid);
 
+struct dt_device_node;
+int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid);
+
 #endif
 
 /*
diff --git a/xen/arch/riscv/smpboot.c b/xen/arch/riscv/smpboot.c
index 0371dfa53e..0b00dd0eb2 100644
--- a/xen/arch/riscv/smpboot.c
+++ b/xen/arch/riscv/smpboot.c
@@ -1,5 +1,8 @@
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
 
 cpumask_t __read_mostly cpu_online_map;
@@ -10,3 +13,66 @@ void __init smp_prepare_boot_cpu(void)
     cpumask_set_cpu(0, &cpu_possible_map);
     cpumask_set_cpu(0, &cpu_online_map);
 }
+
+/**
+ * dt_get_cpuid - Get the cpuid from a CPU device node
+ *
+ * @cpun: CPU number(logical index) for which device node is required
+ *
+ * Return: The cpuid for the CPU node or ~0ULL if not found.
+ */
+static unsigned long dt_get_cpuid(const struct dt_device_node *cpun)
+{
+    const __be32 *cell;
+    int ac;
+    uint32_t len;
+
+    ac = dt_n_addr_cells(cpun);
+    cell = dt_get_property(cpun, "reg", &len);
+    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
+        return ~0ULL;
+
+    return dt_read_number(cell, ac);
+}
+
+/*
+ * Returns the cpuid of the given device tree node, or -ENODEV if the node
+ * isn't an enabled and valid RISC-V hart node.
+ */
+int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
+{
+    const char *isa;
+
+    if ( !dt_device_is_compatible(node, "riscv") )
+    {
+        printk("Found incompatible CPU\n");
+        return -ENODEV;
+    }
+
+    *cpuid = dt_get_cpuid(node);
+    if ( *cpuid == ~0UL )
+    {
+        printk("Found CPU without CPU ID\n");
+        return -ENODEV;
+    }
+
+    if ( !dt_device_is_available(node))
+    {
+        printk("CPU with cpuid=%lu is not available\n", *cpuid);
+        return -ENODEV;
+    }
+
+    if ( dt_property_read_string(node, "riscv,isa", &isa) )
+    {
+        printk("CPU with cpuid=%lu has no \"riscv,isa\" property\n", *cpuid);
+        return -ENODEV;
+    }
+
+    if ( isa[0] != 'r' || isa[1] != 'v' )
+    {
+        printk("CPU with cpuid=%lu has an invalid ISA of \"%s\"\n", *cpuid, isa);
+        return -ENODEV;
+    }
+
+    return 0;
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977627.1364656 (Exim 4.92)
	(envelope-from )
	id 1uCLWa-0007Ga-Nl; Tue, 06 May 2025 16:52:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977627.1364656; Tue, 06 May 2025 16: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 1uCLWa-0007D0-DD; Tue, 06 May 2025 16:52:08 +0000
Received: by outflank-mailman (input) for mailman id 977627;
 Tue, 06 May 2025 16:52:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWY-00058E-8n
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:06 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 70c041a5-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:52:05 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ac3eb3fdd2eso262738966b.0
 for ; Tue, 06 May 2025 09:52:05 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:52: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" 
X-Inumbo-ID: 70c041a5-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550325; x=1747155125; 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;
        bh=MagsnbbonM4RCqIwn/oarouHR237rcv9tp4MRYfZzDU=;
        b=jlEIAx19NdoCXVUPoyFwGEv7wp+YcJ3cDwbi5u0UsVnrNwjwWlbz6Uov5nk/ZtGuLA
         dQhYWonH9Gehgmtn/gJYZghdxZcyhd6nX1X++vo/bXYGxfl26vO8ZZwNrKAA5FRRYHGi
         C2NTjocoK1zKp0I0qVleM7P1tC9eDMCnI9v+iFLOZaH9Ei6A6IAI7vSEuBeNmtou7q2C
         Fq8D+GyCxesv1L5cwK6R3VoIvhSCF5WhMLtADyqcirMaa+ZRFAX3B4dx6hEHPCIqYrKI
         5WEDi0X57R0xodwxZGhCZI+SRvCg5zABSHWnrvgAxbWxPOLGXbf61iEDI4HImXeKi49o
         xNvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550325; x=1747155125;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=MagsnbbonM4RCqIwn/oarouHR237rcv9tp4MRYfZzDU=;
        b=kT1Y8Fxyxb+sYh/jVGS6IWlz8PHMN//EIzJjtMUfHyY/1NMBZQMfPuvuXvOV0JhhXi
         BiaxdwzqZ+HOmJKyITkIlz0DbXnhs9ZYncgUIVthhRa7a5SYJEWPVVSi1HOMMCWSJjuU
         1iGz/WgHRZ5UkaPrm78bviOoyE3NM6OfQ8RjgZ/IXLjhMh72cnZopQ/fYe4PqdPZtjK1
         hV03Kxw16B++iyjcYiMVts8eLl8BTCnLdFjV9CiKTTdp2Pl0tKJCi99VN4t5Vd/lmMU7
         YhimZ8NTn8VRExg9ytN/blxld/ZIFHXr9ILtTgl20THzjF19Tj8HE7OcGVRv8tiNYSUI
         0SJg==
X-Gm-Message-State: AOJu0YzFfWGJZ1OCImpPP7Z89ltQNXQxEPDqJhJ68SmEe0xxnuGxTV69
	GN+eZNBvYQJP9MP3e6xRrU/k/IXJBS77Gpt6umxruHFaeemwg/q2De3eNA==
X-Gm-Gg: ASbGncvGN69oDvtKV2cZIEznHQX4yTPRsMas96kaxi3WwmX8GzvBlyMin7qcW90NnQz
	h7zsmRdWPfML7UKaQX+i/z4qkfxgqaEXiX8JRZmMQkjxy6ZpKH5dPyQrKRe4dUgQ+fGsMTli0ac
	FIArWVybTpKiOfaVSrwpya9Jod0aRl2aC1tPNGg73E2luIYAem876EvIu/g4XExkmDT/K6GMmyU
	ipsanLUbRF6XXF1f2godiNsY8aXVIsvKMAUk/OjstAlcPkOiWDDAQrd5IskE9HUoMP9ydUmleWH
	Q7xZvGAELCh8EMtOL8FGp32VHJkfwhsmtRiNtJscOR2sk42NHwyjOmmrc7ZcQRTpwebqEHtVVSo
	NeBfsWA00WQ==
X-Google-Smtp-Source: AGHT+IHXVcgZWqmG8m0i6ryn+QDye6ieZnyr5R5iVbzKSImUtMH6siYhduEiVLati9KAvZAxaemw6Q==
X-Received: by 2002:a17:907:3f9a:b0:ad1:d061:e8b6 with SMTP id a640c23a62f3a-ad1e8bc8d20mr17508666b.21.1746550324581;
        Tue, 06 May 2025 09:52:04 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v2 09/16] xen/riscv: introduce register_intc_ops() and intc_hw_ops.
Date: Tue,  6 May 2025 18:51:39 +0200
Message-ID: <7cd7d3780bb6db45b92c971ff8bcf2634570431f.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce the intc_hw_operations structure to encapsulate interrupt
controller-specific data and operations. This structure includes:
- A pointer to interrupt controller information (`intc_info`)
- Callbacks to initialize the controller and set IRQ type/priority
- A reference to an interupt controller descriptor (`host_irq_type`)
- number of interrupt controller irqs.

Add function register_intc_ops() to mentioned above structure.

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - This patch was part of "xen/riscv: Introduce intc_hw_operations abstraction"
   and splitted to have ability to merge some patches from this patch series
   into one patch.
 - Declare host_irq_type member of intc_hw_operations as pointer-to-const.
 - Moved up forward declaration of irq_desc.
 - Use attribute __init for register_intc_ops().
 - Use attribute __ro_after_init for intc_hw_ops variable.
 - Update prototype of register_intc_ops() because of what mention in the
   previous point.
---
 xen/arch/riscv/include/asm/intc.h | 22 ++++++++++++++++++++++
 xen/arch/riscv/intc.c             |  9 +++++++++
 2 files changed, 31 insertions(+)

diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 52ba196d87..e72d5fd9d3 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -8,6 +8,8 @@
 #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
 #define ASM__RISCV__INTERRUPT_CONTOLLER_H
 
+#include 
+
 enum intc_version {
     INTC_APLIC,
 };
@@ -17,6 +19,26 @@ struct intc_info {
     const struct dt_device_node *node;
 };
 
+struct irq_desc;
+
+struct intc_hw_operations {
+    /* Hold intc hw information */
+    const struct intc_info *info;
+    /* Initialize the intc and the boot CPU */
+    int (*init)(void);
+
+    /* hw_irq_controller to enable/disable/eoi host irq */
+    const hw_irq_controller *host_irq_type;
+
+    /* Set IRQ type */
+    void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
+    /* Set IRQ priority */
+    void (*set_irq_priority)(struct irq_desc *desc, unsigned int priority);
+
+};
+
 void intc_preinit(void);
 
+void register_intc_ops(struct intc_hw_operations *ops);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 4061a3c457..122e7b32b5 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -5,6 +5,15 @@
 #include 
 #include 
 
+#include 
+
+static struct __ro_after_init intc_hw_operations *intc_hw_ops;
+
+void __init register_intc_ops(struct intc_hw_operations *ops)
+{
+    intc_hw_ops = ops;
+}
+
 void __init intc_preinit(void)
 {
     if ( acpi_disabled )
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977630.1364670 (Exim 4.92)
	(envelope-from )
	id 1uCLWc-0007eA-K7; Tue, 06 May 2025 16:52:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977630.1364670; Tue, 06 May 2025 16: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 1uCLWc-0007bF-4q; Tue, 06 May 2025 16:52:10 +0000
Received: by outflank-mailman (input) for mailman id 977630;
 Tue, 06 May 2025 16:52:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWa-00058E-9S
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:08 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 71566546-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:52:06 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-acacb8743a7so11043266b.1
 for ; Tue, 06 May 2025 09:52:06 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09: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" 
X-Inumbo-ID: 71566546-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550326; x=1747155126; 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;
        bh=maZIYenpt/TgC9UOWWJvY9Qazh2LoZdUwAXjgu0Aocs=;
        b=mK2u8zQX+bU2Y/wbgmnMxQklpobGwCtD+VxGVI51DYUCuUO77PR/vZL8EHiEzPcsWI
         3dvU4wy9WzkU3kHFK+L6/S1+h3d03j5kVjPEvunQSj5fDc0DBxbDxcpUH6yrD7+lRQwc
         DMnRlB0Tiu0Fevyh56v+yOVMjpnszhTGgTpzBNujtvUbGvZ3tLmNt81ILPfnOMqScKJi
         g8gBGjjUX2cv3g3Xkq7IZOQbVOVVxQbRZKGQF0EhrEwtgPXjlT9a6mlDVa/mXWOaegtM
         gYiM3EMdiP9D7eK94cs3PGozt+vx+gIhfg1KTumXriHtMeJUWYf4TixoXxwKljlBPWQu
         KxHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550326; x=1747155126;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=maZIYenpt/TgC9UOWWJvY9Qazh2LoZdUwAXjgu0Aocs=;
        b=fDSeQKcsi8Cw5ZJiBko4Q3qFh6gEP0ytKxOLUCHLzDejkC7pFZN7bPTNk9NkHoqhA9
         WDFNmTzocqr62SSRzWGP8m7WOJ26d8cDTGBvoDfb1gRLWHu3ky88FjJf9fO6yR5EItCZ
         Or6PiubCH7eJ3Gxc/+eHegZVC90F9NClWzl28cl7whAvRsCRo8/mku7EszAFovEN2Gur
         +R49DTskHMfJTs/USwvutYdBn3ffb46mfYTyfGMu1fAvqntXLdStk/DiYb6s2VqQJhBX
         cSZxk5naeLAv1jk1IKi7rmZmwg+kz/0yloOx6Rur/qmvAG5HzghhJbuqiWyclBN/Ejvn
         /TzA==
X-Gm-Message-State: AOJu0YzCYUBMUl/WcailxD6/rRMdSUSnrKWSv4DDYFsKlryA9oVEIgxj
	pIC7+El/XQpVqMTvN8CyHUlRfsqnL6MifHHtf8OxJjz+/Q82jpOKgd2WqA==
X-Gm-Gg: ASbGncuurOWnjC1Mwxh8sGKiutGK5zlA3JWglJaXr1LSMRkche2p31g462msWsdwqlS
	psJsgW/0ge/OquoQCMP8Y61mesO8j0sKmuqdy9RyIq4e428g3QbKIUyWc6DAcowMbOLZ/ZPrY2f
	KibLCyUMI8K2KneaisjLPh1MMCM4ht7rLApMdSwy8faD6UfD5f/6eokTW7kAyTBGjwecaoHVBcQ
	VT10QYC4nC8ml5Bh/RbsrCKgTHryv8yseax1fSapZ50paMVlKFleRJj0f4+EmbwxFek5kLGU/w3
	HDKVPYu/vZFKwyMwCnP69u0Dy4Y637F3SFNacglKAkCqmvJEPIyi+baGq7VeeyWi1L8W7iknYgM
	h2E8t0lpZVQ==
X-Google-Smtp-Source: AGHT+IH4c8fyVlUG1/9uOe655VcD6jWKV4hFGibis0LHxfaSmfsFm6d5cT/HapGyiJPpZFECSfaM+Q==
X-Received: by 2002:a17:907:c70c:b0:acb:aa43:e82d with SMTP id a640c23a62f3a-ad1e7c4a0f3mr46544366b.3.1746550325511;
        Tue, 06 May 2025 09:52:05 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v2 10/16] xen/riscv: imsic_init() implementation
Date: Tue,  6 May 2025 18:51:40 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

imsic_init() is introduced to parse device tree node, which has the following
bindings [2], and based on the parsed information update IMSIC configuration
which is stored in imsic_cfg.

The following helpers are introduces for imsic_init() usage:
  - imsic_parse_node() parses IMSIC node from DTS
  - imsic_get_parent_cpuid() returns the hart ( CPU ) ID of the given device
    tree node.

This patch is based on the code from [1].

Since Microchip originally developed imsic.{c,h}, an internal discussion with
them led to the decision to use the MIT license.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/0b1a94f2bc3bb1a81cd26bb75f0bf578f84cb4d4
[2] https://elixir.bootlin.com/linux/v6.12/source/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - Drop years in copyrights.
 - s/riscv_of_processor_hartid/dt_processor_cpuid.
 - s/imsic_get_parent_hartid/imsic_get_parent_cpuid.
   Rename argument hartid to cpuid.
   Make node argument const.
   Return res instead of -EINVAL for the failure case of dt_processor_cpuid().
   Drop local variable hart and use cpuid argument instead.
   Drop useless return res;
 - imsic_parse_node() changes:
   - Make node argument const.
   - Check the return value of dt_property_read_u32() directly instead of
     saving it to rc variable.
   - Update tmp usage, use short form "-=".
   - Update a check (imsic_cfg.nr_ids >= IMSIC_MAX_ID) to (imsic_cfg.nr_ids > IMSIC_MAX_ID)
     as IMSIC_MAX_ID is changed to maximum valid value, not just the firsr out-of-range.
   - Use `rc` to return value instead of explicitly use -EINVAL.
   - Use do {} while() to find number of MMIO register sets.
 - Set IMSIC_MAX_ID to 2047 (maximum possible IRQ number).
 - imsic_init() changes:
   - Use unsigned int in for's expression1.
   - s/xfree/XFEE.
   - Allocate msi and cpus array dynamically.
 - Drop forward declaration before declaration of imsic_get_config() in asm/imsic.h
   as it is not used as parameter type.
 - Align declaration of imisic_init with defintion.
 - s/harts/cpus in imisic_mmios.
   Also, change type from bool harts[NR_CPUS] to unsigned long *cpus.
 - Allocate msi member of imsic_config dynamically to save some memory.
 - Code style fixes.
 - Update the commit message.
---
 xen/arch/riscv/Makefile            |   1 +
 xen/arch/riscv/imsic.c             | 286 +++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/imsic.h |  65 +++++++
 3 files changed, 352 insertions(+)
 create mode 100644 xen/arch/riscv/imsic.c
 create mode 100644 xen/arch/riscv/include/asm/imsic.h

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index a1c145c506..e2b8aa42c8 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -2,6 +2,7 @@ obj-y += aplic.o
 obj-y += cpufeature.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
+obj-y += imsic.o
 obj-y += intc.o
 obj-y += irq.o
 obj-y += mm.o
diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
new file mode 100644
index 0000000000..43d0c92cbd
--- /dev/null
+++ b/xen/arch/riscv/imsic.c
@@ -0,0 +1,286 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/imsic.c
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) Microchip Technology Inc.
+ * (c) Vates
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static struct imsic_config imsic_cfg;
+
+/* Callers aren't expected to changed imsic_cfg so return const. */
+const struct imsic_config *imsic_get_config(void)
+{
+    return &imsic_cfg;
+}
+
+static int __init imsic_get_parent_cpuid(const struct dt_device_node *node,
+                                         unsigned int index,
+                                         unsigned long *cpuid)
+{
+    int res;
+    struct dt_phandle_args args;
+
+    res = dt_parse_phandle_with_args(node, "interrupts-extended",
+                                     "#interrupt-cells", index, &args);
+    if ( !res )
+        res = dt_processor_cpuid(args.np->parent, cpuid);
+
+    return res;
+}
+
+static int imsic_parse_node(const struct dt_device_node *node,
+                            unsigned int *nr_parent_irqs)
+{
+    int rc;
+    unsigned int tmp;
+    paddr_t base_addr;
+
+    /* Find number of parent interrupts */
+    *nr_parent_irqs = dt_number_of_irq(node);
+    if ( !*nr_parent_irqs )
+    {
+        printk(XENLOG_ERR "%s: no parent irqs available\n", node->name);
+        return -ENOENT;
+    }
+
+    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
+                               &imsic_cfg.guest_index_bits) )
+        imsic_cfg.guest_index_bits = 0;
+    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
+    if ( tmp < imsic_cfg.guest_index_bits )
+    {
+        printk(XENLOG_ERR "%s: guest index bits too big\n", node->name);
+        return -ENOENT;
+    }
+
+    /* Find number of HART index bits */
+    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
+                               &imsic_cfg.hart_index_bits) )
+    {
+        /* Assume default value */
+        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
+        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
+            imsic_cfg.hart_index_bits++;
+    }
+    tmp -= imsic_cfg.guest_index_bits;
+    if ( tmp < imsic_cfg.hart_index_bits )
+    {
+        printk(XENLOG_ERR "%s: HART index bits too big\n", node->name);
+        return -ENOENT;
+    }
+
+    /* Find number of group index bits */
+    if ( !dt_property_read_u32(node, "riscv,group-index-bits",
+                               &imsic_cfg.group_index_bits) )
+        imsic_cfg.group_index_bits = 0;
+    tmp -= imsic_cfg.hart_index_bits;
+    if ( tmp < imsic_cfg.group_index_bits )
+    {
+        printk(XENLOG_ERR "%s: group index bits too big\n", node->name);
+        return -ENOENT;
+    }
+
+    /* Find first bit position of group index */
+    tmp = IMSIC_MMIO_PAGE_SHIFT * 2;
+    if ( !dt_property_read_u32(node, "riscv,group-index-shift",
+                               &imsic_cfg.group_index_shift) )
+        imsic_cfg.group_index_shift = tmp;
+    if ( imsic_cfg.group_index_shift < tmp )
+    {
+        printk(XENLOG_ERR "%s: group index shift too small\n", node->name);
+        return -ENOENT;
+    }
+    tmp = imsic_cfg.group_index_bits + imsic_cfg.group_index_shift - 1;
+    if ( tmp >= BITS_PER_LONG )
+    {
+        printk(XENLOG_ERR "%s: group index shift too big\n", node->name);
+        return -EINVAL;
+    }
+
+    /* Find number of interrupt identities */
+    if ( !dt_property_read_u32(node, "riscv,num-ids", &imsic_cfg.nr_ids) )
+    {
+        printk(XENLOG_ERR "%s: number of interrupt identities not found\n",
+               node->name);
+        return -ENOENT;
+    }
+
+    if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) ||
+         (imsic_cfg.nr_ids > IMSIC_MAX_ID) ||
+         ((imsic_cfg.nr_ids & IMSIC_MIN_ID) != IMSIC_MIN_ID) )
+    {
+        printk(XENLOG_ERR "%s: invalid number of interrupt identities\n",
+               node->name);
+        return -EINVAL;
+    }
+
+    /* Compute base address */
+    imsic_cfg.nr_mmios = 0;
+    rc = dt_device_get_address(node, imsic_cfg.nr_mmios, &base_addr, NULL);
+    if ( rc )
+    {
+        printk(XENLOG_ERR "%s: first MMIO resource not found\n", node->name);
+        return rc;
+    }
+
+    imsic_cfg.base_addr = base_addr;
+    imsic_cfg.base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+                           imsic_cfg.hart_index_bits +
+                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+    imsic_cfg.base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                           imsic_cfg.group_index_shift);
+
+    /* Find number of MMIO register sets */
+    do {
+        imsic_cfg.nr_mmios++;
+    } while ( !dt_device_get_address(node, imsic_cfg.nr_mmios, &base_addr, NULL) );
+
+    return 0;
+}
+
+int __init imsic_init(const struct dt_device_node *node)
+{
+    int rc;
+    unsigned long reloff, cpuid;
+    uint32_t nr_parent_irqs, index, nr_handlers = 0;
+    paddr_t base_addr;
+    unsigned int nr_mmios;
+
+    /* Parse IMSIC node */
+    rc = imsic_parse_node(node, &nr_parent_irqs);
+    if ( rc )
+        return rc;
+
+    nr_mmios = imsic_cfg.nr_mmios;
+
+    /* Allocate MMIO resource array */
+    imsic_cfg.mmios = xzalloc_array(struct imsic_mmios, nr_mmios);
+    if ( !imsic_cfg.mmios )
+        return -ENOMEM;
+
+    imsic_cfg.msi = xzalloc_array(struct imsic_msi, nr_parent_irqs);
+    if ( !imsic_cfg.msi )
+        return -ENOMEM;
+
+    /* Check MMIO register sets */
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+    {
+        imsic_cfg.mmios[i].cpus = xzalloc_array(unsigned long,
+                                                BITS_TO_LONGS(nr_parent_irqs));
+        if ( !imsic_cfg.mmios[i].cpus )
+            return -ENOMEM;
+
+        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
+                                   &imsic_cfg.mmios[i].size);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%s:  unable to parse MMIO regset %d\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        base_addr = imsic_cfg.mmios[i].base_addr;
+        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+                     imsic_cfg.hart_index_bits +
+                     IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                     imsic_cfg.group_index_shift);
+        if ( base_addr != imsic_cfg.base_addr )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: address mismatch for regset %d\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+    }
+
+    /* Configure handlers for target CPUs */
+    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
+    {
+        rc = imsic_get_parent_cpuid(node, i, &cpuid);
+        if ( rc )
+        {
+            printk(XENLOG_WARNING "%s: cpu ID for parent irq%d not found\n",
+                   node->name, i);
+            continue;
+        }
+
+        if ( cpuid >= num_possible_cpus() )
+        {
+            printk(XENLOG_WARNING "%s: unsupported cpu ID=%lu for parent irq%d\n",
+                   node->name, cpuid, i);
+            continue;
+        }
+
+        /* Find MMIO location of MSI page */
+        index = nr_mmios;
+        reloff = i * BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ;
+        for ( unsigned int j = 0; nr_mmios; j++ )
+        {
+            if ( reloff < imsic_cfg.mmios[j].size )
+            {
+                index = j;
+                break;
+            }
+
+            /*
+             * MMIO region size may not be aligned to
+             * BIT(global->guest_index_bits) * IMSIC_MMIO_PAGE_SZ
+             * if holes are present.
+             */
+            reloff -= ROUNDUP(imsic_cfg.mmios[j].size,
+                BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ);
+        }
+
+        if ( index >= nr_mmios )
+        {
+            printk(XENLOG_WARNING "%s: MMIO not found for parent irq%d\n",
+                   node->name, i);
+            continue;
+        }
+
+        if ( !IS_ALIGNED(imsic_cfg.msi[cpuid].base_addr + reloff, PAGE_SIZE) )
+        {
+            printk(XENLOG_WARNING "%s: MMIO address 0x%lx is not aligned on a page\n",
+                   node->name, imsic_cfg.msi[cpuid].base_addr + reloff);
+            imsic_cfg.msi[cpuid].offset = 0;
+            imsic_cfg.msi[cpuid].base_addr = 0;
+            continue;
+        }
+
+        bitmap_set(imsic_cfg.mmios[index].cpus, cpuid, 1);
+        imsic_cfg.msi[cpuid].base_addr = imsic_cfg.mmios[index].base_addr;
+        imsic_cfg.msi[cpuid].offset = reloff;
+        nr_handlers++;
+    }
+
+    if ( !nr_handlers )
+    {
+        printk(XENLOG_ERR "%s: No CPU handlers found\n", node->name);
+        rc = -ENODEV;
+        goto imsic_init_err;
+    }
+
+    return 0;
+
+ imsic_init_err:
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+        XFREE(imsic_cfg.mmios[i].cpus);
+    XFREE(imsic_cfg.mmios);
+    XFREE(imsic_cfg.msi);
+
+    return rc;
+}
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
new file mode 100644
index 0000000000..ed51cac780
--- /dev/null
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/imsic.h
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) 2023 Microchip Technology Inc.
+ */
+
+#ifndef ASM__RISCV__IMSIC_H
+#define ASM__RISCV__IMSIC_H
+
+#include 
+
+#define IMSIC_MMIO_PAGE_SHIFT   12
+#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
+
+#define IMSIC_MIN_ID            63
+#define IMSIC_MAX_ID            2047
+
+struct imsic_msi {
+    paddr_t base_addr;
+    unsigned long offset;
+};
+
+struct imsic_mmios {
+    paddr_t base_addr;
+    unsigned long size;
+    unsigned long *cpus;
+};
+
+struct imsic_config {
+    /* base address */
+    paddr_t base_addr;
+
+    /* Bits representing Guest index, HART index, and Group index */
+    unsigned int guest_index_bits;
+    unsigned int hart_index_bits;
+    unsigned int group_index_bits;
+    unsigned int group_index_shift;
+
+    /* imsic phandle */
+    unsigned int phandle;
+
+    /* number of parent irq */
+    unsigned int nr_parent_irqs;
+
+    /* number off interrupt identities */
+    unsigned int nr_ids;
+
+    /* mmios */
+    unsigned int nr_mmios;
+    struct imsic_mmios *mmios;
+
+    /* MSI */
+    struct imsic_msi *msi;
+};
+
+struct dt_device_node;
+int imsic_init(const struct dt_device_node *node);
+
+const struct imsic_config *imsic_get_config(void);
+
+#endif /* ASM__RISCV__IMSIC_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977634.1364683 (Exim 4.92)
	(envelope-from )
	id 1uCLWf-0008Jh-PY; Tue, 06 May 2025 16:52:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977634.1364683; Tue, 06 May 2025 16: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 1uCLWf-0008JA-Kt; Tue, 06 May 2025 16:52:13 +0000
Received: by outflank-mailman (input) for mailman id 977634;
 Tue, 06 May 2025 16:52:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWe-0005Fd-8j
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:12 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 73440c83-2a9a-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:52:09 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ac7bd86f637so10578166b.1
 for ; Tue, 06 May 2025 09:52:09 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09: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" 
X-Inumbo-ID: 73440c83-2a9a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550329; x=1747155129; 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;
        bh=X7bqlD3yclmWFqpbOVCYxhfG+qpphXcgJLBRlpTHTwc=;
        b=eKGWsUnVd+Ex20oQoSDrFW7fhwEW8/GzwJ13goRggxL6z1dod4OExVZcaZO2DfNzlj
         R0Pnt0c2cV5muGXKH3qzG/PzJ6oSBRNxJu6tHBu1f9PSf71LsLsi4v4A38FHz6LUe6j2
         eSZ4svlrZfTrdp+C/rFF4+Jw/raXCAShPgKCCdAR5sMIy9ZXIyqt/Ltxu/hwqKFJWkAx
         eZRvijg7z/nH6DrJPtMohqpDvjpmtmuG1I54bjxi/4BRXrwaK3W6U4gTgLIf+tc2I2GE
         hDpn8AuOzXdo2mGDPgpNVN2DCjEVHnYfboLn5DYUOFjU4QK/GQX29xsp1+6Sibpaox49
         gjbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550329; x=1747155129;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=X7bqlD3yclmWFqpbOVCYxhfG+qpphXcgJLBRlpTHTwc=;
        b=iasI+n2WpwHkCLU+8JcglhuP1t1cfOGmx2cACV7f8TlwiNy70R/qKQJmaweyKKt5rR
         zHg0yR3CnnHDuMKxI52xuOJmHHTqg4rIAy5INScFhTM43kkqKLK2FlQlb+QVL4JyUhv7
         vP6jU0RZ6P36HN19vUTrzfjjXfo18Kd2tzYX64tkJXRtLS4Rwyx3fHBn/OKFAG5Xyeax
         gSVEkrRkxo8AfQNORJIoN+aGs1JmhxvDUrHuuAg0uUwX9B7k/btFglw00nIQJI7TfGJs
         6hjR3yCuYM6FLae/EV4oMdRpIth+4eZGjEfNuESG1rXgG4ujJCQsTSsuY6pbFxF8lJch
         56Iw==
X-Gm-Message-State: AOJu0Yyw7ssVs7aT+/aFUWZAp0soD6Su3oYTK8x1l5tpnq77h20CkGUe
	qOOJX0i94og/J0qhMXfGcaOPw8QRgXPUqixmX6vEf0Lx/fkSKUOlHQqlAg==
X-Gm-Gg: ASbGncu0/5kqTaup4mckqklcOGr2zDAsN9N7M+ON5KjfCLMRQUwcWoJgwRawgBnyBk0
	6atfUfd1hGrBeEwb015qXjqH7kNbUyFmKzN/CqxlYT9J+/jnUiXEKAAdjfDNOzQtAWxAkJ8ImbQ
	94nV2RVY0NuhHeXJ4kWcKphTYZUeGsLJ4JgPVeph0lRAFGvBL15yehXJ9/8szQyok2QPnfF/pxW
	YFQ4XRc52ChW9IjceO8MxUF35tS95QQSx87J4HK6oMtGKdMxgrVVICsPXaLEZTzCItvt8ICVNoq
	yRRk6azggnKhZ9NevllySVQNKTrQrtj7UPnTEL/WkdHG+iQR1jyqqHQBBrks54vSm4sDQ5Ysd0h
	WQyfiEDm2Mg==
X-Google-Smtp-Source: AGHT+IEhOkmb1jx5SbHyCixof/ixiFhHkrZcmMEWR17iWutqxnDffklvb69FO1Cyzua5DT/DhmiwsA==
X-Received: by 2002:a17:907:7d89:b0:ac7:334d:3217 with SMTP id a640c23a62f3a-ad1e78046b4mr52040866b.12.1746550328483;
        Tue, 06 May 2025 09:52:08 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v2 13/16] xen/riscv: implementation of aplic and imsic operations
Date: Tue,  6 May 2025 18:51:43 +0200
Message-ID: <37d309520a0adb8bb3f4e51a985a2d56b669ba9e.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=all
Content-Transfer-Encoding: 8bit

Introduce interrupt controller descriptor for host APLIC to describe
the low-lovel hardare. It includes implementation of the following functions:
 - aplic_irq_startup()
 - aplic_irq_enable()
 - aplic_irq_disable()
 - aplic_set_irq_affinity()

As APLIC is used in MSI mode it requires to enable/disable interrupts not
only for APLIC but also for IMSIC. Thereby for the purpose of
aplic_irq_{enable,disable}() it is introduced imsic_irq_{enable,disable)().

For the purpose of aplic_set_irq_affinity() aplic_get_cpu_from_mask() is
introduced to get hart id.

Also, introduce additional interrupt controller h/w operations and
host_irq_type for APLIC:
 - aplic_host_irq_type

Patch is based on the code from [1].

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - Move imsic_ids_local_delivery() and connected to it parts to the current
   patch to fix compilation issue. Also, add __init for
   imsic_ids_local_delivery().
 - Move introduction of aplic_set_irq_type() and aplic_set_irq_priority()
   to patch [PATCH v1 12/14] xen/riscv: implement setup_irq() where they
   really started to be used.
 - Update the commit message.
 - Drop is_used variable for imsic_cfg and use (aplic.regs->domaincfg & APLIC_DOMAINCFG_DM) instead.
 - Use writel() to write to APLIC regs.
 - Drop aplic_irq_shutdown() and use aplic_irq_disable explicitly.
 - Drop local variable cpu in aplic_get_cpu_from_mask():
   Use cpu_online_map instead of cpu_possible_map.
   Remame possible_mask to mask.
 - Code style fixes.
 - Move spin_lock(&aplic.lock) down before write to the register in aplic_set_irq_affinity.
 - Make aplic_host_irq_type const.
 - imsic_local_eix_update() updates:
   - move unsigned long isel, ireg; to inner loop.
   - Drop unnecessary parentheses.
   - Optimize inner loop of ireg's setting.
 - Drop aplic_irq_ack() and aplic_host_irq_end() as they do nothing.
 - Rename s/hwirq/irq.
 - Add explanatory comment to imsic_irq_enable() about why there is not -1 for IRQ in
   comparison with APLIC's sourcecfg.
 - Use IMSIC_MMIO_PAGE_SHIFT instead of constant 12 in aplic_set_irq_affinity().
 - s/aplic_host_irq_type/aplic_xen_irq_type
 - Drop set/clear of IRQ_DISABLED bit in aplic_{enable,disable}() as guest will always
   first request an interrupt and then only an interrupt will be enabled.
   (for example, in Arm, the physical interrupts would be enabled when the
   interrupt is initially routed. This could lead to problem because the guest
   will usually boot with interrupt disabled.)
---
 xen/arch/riscv/aplic-priv.h        |   4 +
 xen/arch/riscv/aplic.c             | 113 +++++++++++++++++++++++++++++
 xen/arch/riscv/imsic.c             | 104 ++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/aplic.h |   4 +-
 xen/arch/riscv/include/asm/imsic.h |  18 +++++
 5 files changed, 242 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h
index 8a208dba8a..a6cfed4ee0 100644
--- a/xen/arch/riscv/aplic-priv.h
+++ b/xen/arch/riscv/aplic-priv.h
@@ -14,6 +14,7 @@
 #ifndef ASM__RISCV_PRIV_APLIC_H
 #define ASM__RISCV_PRIV_APLIC_H
 
+#include 
 #include 
 
 #include 
@@ -27,6 +28,9 @@ struct aplic_priv {
     /* registers */
     volatile struct aplic_regs *regs;
 
+    /* lock */
+    spinlock_t lock;
+
     /* imsic configuration */
     const struct imsic_config *imsic_cfg;
 };
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 797e5df020..e2bee7ad23 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -23,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define APLIC_DEFAULT_PRIORITY  1
@@ -119,9 +121,118 @@ static int __init cf_check aplic_init(void)
     return 0;
 }
 
+static void aplic_irq_enable(struct irq_desc *desc)
+{
+    unsigned long flags;
+
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    spin_lock_irqsave(&aplic.lock, flags);
+
+    /* Enable interrupt in IMSIC */
+    imsic_irq_enable(desc->irq);
+
+    /* Enable interrupt in APLIC */
+    writel(desc->irq, &aplic.regs->setienum);
+
+    spin_unlock_irqrestore(&aplic.lock, flags);
+}
+
+static void aplic_irq_disable(struct irq_desc *desc)
+{
+    unsigned long flags;
+
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    spin_lock_irqsave(&aplic.lock, flags);
+
+    /* disable interrupt in APLIC */
+    writel(desc->irq, &aplic.regs->clrienum);
+
+    /* disable interrupt in IMSIC */
+    imsic_irq_disable(desc->irq);
+
+    spin_unlock_irqrestore(&aplic.lock, flags);
+}
+
+static unsigned int aplic_irq_startup(struct irq_desc *desc)
+{
+    aplic_irq_enable(desc);
+
+    return 0;
+}
+
+static unsigned int aplic_get_cpu_from_mask(const cpumask_t *cpumask)
+{
+    cpumask_t mask;
+
+    cpumask_and(&mask, cpumask, &cpu_online_map);
+
+    return cpumask_any(&mask);
+}
+
+static void 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;
+
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(!cpumask_empty(mask));
+
+    cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask));
+    hhxw = imsic->group_index_bits;
+    lhxw = imsic->hart_index_bits;
+    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) ;
+
+    spin_lock(&aplic.lock);
+
+    writel(value, &aplic.regs->target[desc->irq - 1]);
+
+    spin_unlock(&aplic.lock);
+}
+
+static const hw_irq_controller aplic_xen_irq_type = {
+    .typename     = "aplic",
+    .startup      = aplic_irq_startup,
+    .shutdown     = aplic_irq_disable,
+    .enable       = aplic_irq_enable,
+    .disable      = aplic_irq_disable,
+    .set_affinity = aplic_set_irq_affinity,
+};
+
 static struct intc_hw_operations __ro_after_init aplic_ops = {
     .info                = &aplic_info,
     .init                = aplic_init,
+    .host_irq_type       = &aplic_xen_irq_type,
 };
 
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
@@ -159,6 +270,8 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     dt_irq_xlate = aplic_irq_xlate;
 
+    spin_lock_init(&aplic.lock);
+
     register_intc_ops(&aplic_ops);
 
     return 0;
diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
index 43d0c92cbd..70316d2e97 100644
--- a/xen/arch/riscv/imsic.c
+++ b/xen/arch/riscv/imsic.c
@@ -9,17 +9,116 @@
  * (c) Vates
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
 
+#define IMSIC_DISABLE_EIDELIVERY    0
+#define IMSIC_ENABLE_EIDELIVERY     1
+#define IMSIC_DISABLE_EITHRESHOLD   1
+#define IMSIC_ENABLE_EITHRESHOLD    0
+
 static struct imsic_config imsic_cfg;
 
+#define imsic_csr_write(c, v)   \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_write(CSR_SIREG, v);    \
+} while (0)
+
+#define imsic_csr_set(c, v)     \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_set(CSR_SIREG, v);      \
+} while (0)
+
+#define imsic_csr_clear(c, v)   \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_clear(CSR_SIREG, v);    \
+} while (0)
+
+void __init imsic_ids_local_delivery(bool enable)
+{
+    if ( enable )
+    {
+        imsic_csr_write(IMSIC_EITHRESHOLD, IMSIC_ENABLE_EITHRESHOLD);
+        imsic_csr_write(IMSIC_EIDELIVERY, IMSIC_ENABLE_EIDELIVERY);
+    }
+    else
+    {
+        imsic_csr_write(IMSIC_EITHRESHOLD, IMSIC_DISABLE_EITHRESHOLD);
+        imsic_csr_write(IMSIC_EIDELIVERY, IMSIC_DISABLE_EIDELIVERY);
+    }
+}
+
+static void imsic_local_eix_update(unsigned long base_id, unsigned long num_id,
+                                   bool pend, bool val)
+{
+    unsigned long id = base_id, last_id = base_id + num_id;
+
+    while ( id < last_id )
+    {
+        unsigned long isel, ireg;
+        unsigned long start_id = id & (__riscv_xlen - 1);
+        unsigned long chunk = __riscv_xlen - start_id;
+        unsigned long count = (last_id - id < chunk) ? last_id - id : chunk;
+
+        isel = id / __riscv_xlen;
+        isel *= __riscv_xlen / IMSIC_EIPx_BITS;
+        isel += pend ? IMSIC_EIP0 : IMSIC_EIE0;
+
+        ireg = GENMASK(start_id + count - 1, start_id);
+
+        id += count;
+
+        if ( val )
+            imsic_csr_set(isel, ireg);
+        else
+            imsic_csr_clear(isel, ireg);
+    }
+}
+
+void imsic_irq_enable(unsigned int irq)
+{
+    unsigned long flags;
+
+    spin_lock_irqsave(&imsic_cfg.lock, flags);
+    /*
+     * There is no irq - 1 here (look at aplic_set_irq_type()) because:
+     * From the spec:
+     *   When an interrupt file supports distinct interrupt identities,
+     *   valid identity numbers are between 1 and inclusive. The identity
+     *   numbers within this range are said to be implemented by the interrupt
+     *   file; numbers outside this range are not implemented. The number zero
+     *   is never a valid interrupt identity.
+     *   ...
+     *   Bit positions in a valid eiek register that don’t correspond to a
+     *   supported interrupt identity (such as bit 0 of eie0) are read-only zeros.
+     *
+     * So in EIx registers interrupt i corresponds to bit i in comparison wiht
+     * APLIC's sourcecfg which starts from 0. (l)
+     */
+    imsic_local_eix_update(irq, 1, false, true);
+    spin_unlock_irqrestore(&imsic_cfg.lock, flags);
+}
+
+void imsic_irq_disable(unsigned int irq)
+{
+    unsigned long flags;
+
+    spin_lock_irqsave(&imsic_cfg.lock, flags);
+    imsic_local_eix_update(irq, 1, false, false);
+    spin_unlock_irqrestore(&imsic_cfg.lock, flags);
+}
+
 /* Callers aren't expected to changed imsic_cfg so return const. */
 const struct imsic_config *imsic_get_config(void)
 {
@@ -274,6 +373,11 @@ int __init imsic_init(const struct dt_device_node *node)
         goto imsic_init_err;
     }
 
+    spin_lock_init(&imsic_cfg.lock);
+
+    /* Enable local interrupt delivery */
+    imsic_ids_local_delivery(true);
+
     return 0;
 
  imsic_init_err:
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index 6221030a68..dc4ccbb9aa 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: MIT */
 
 /*
- * xen/arch/riscv/asm/include/aplic.h
+ * xen/arch/riscv/aplic.h
  *
  * RISC-V Advanced Platform-Level Interrupt Controller support
  *
@@ -18,6 +18,8 @@
 #define APLIC_DOMAINCFG_IE      BIT(8, UL)
 #define APLIC_DOMAINCFG_DM      BIT(2, UL)
 
+#define APLIC_TARGET_HART_IDX_SHIFT 18
+
 struct aplic_regs {
     uint32_t domaincfg;
     uint32_t sourcecfg[1023];
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index ed51cac780..1d6ab4d685 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -11,6 +11,7 @@
 #ifndef ASM__RISCV__IMSIC_H
 #define ASM__RISCV__IMSIC_H
 
+#include 
 #include 
 
 #define IMSIC_MMIO_PAGE_SHIFT   12
@@ -19,6 +20,15 @@
 #define IMSIC_MIN_ID            63
 #define IMSIC_MAX_ID            2047
 
+#define IMSIC_EIDELIVERY        0x70
+
+#define IMSIC_EITHRESHOLD       0x72
+
+#define IMSIC_EIP0              0x80
+#define IMSIC_EIPx_BITS         32
+
+#define IMSIC_EIE0              0xC0
+
 struct imsic_msi {
     paddr_t base_addr;
     unsigned long offset;
@@ -55,6 +65,9 @@ struct imsic_config {
 
     /* MSI */
     struct imsic_msi *msi;
+
+    /* lock */
+    spinlock_t lock;
 };
 
 struct dt_device_node;
@@ -62,4 +75,9 @@ int imsic_init(const struct dt_device_node *node);
 
 const struct imsic_config *imsic_get_config(void);
 
+void imsic_irq_enable(unsigned int hwirq);
+void imsic_irq_disable(unsigned int hwirq);
+
+void imsic_ids_local_delivery(bool enable);
+
 #endif /* ASM__RISCV__IMSIC_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:52:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:52:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977636.1364693 (Exim 4.92)
	(envelope-from )
	id 1uCLWi-0000ML-Ht; Tue, 06 May 2025 16:52:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977636.1364693; Tue, 06 May 2025 16: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 1uCLWi-0000Lz-Bz; Tue, 06 May 2025 16:52:16 +0000
Received: by outflank-mailman (input) for mailman id 977636;
 Tue, 06 May 2025 16:52:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWg-0005Fd-94
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:14 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 74df34d6-2a9a-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 18:52:12 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ac29fd22163so984598966b.3
 for ; Tue, 06 May 2025 09:52:12 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:52:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 74df34d6-2a9a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550332; x=1747155132; 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;
        bh=jcNpMhCfyvA/6mSR/+djGto9U0zKi73zc12A/lkWF+Q=;
        b=lqzKfps9AKcTYZvT507iJOWZrd0H5Q4anncLOxKgcHS/p09QtBSIgwdxxwhGJ9fLfh
         wTlZq0oODHuLCmCTh6taq+4Tesb8GNYsF0qkxDiYwvCl6K/4BBDowAsUj8H/0Rp4ygV0
         LeCKZHEsf/Z7s0gc7IK9eDpXE8sSwzA8xx4urHN3+jjMiw9Gid69nZ8+hg++MBtASJzK
         EEqNVo/qtIPnH/hcfBuO2BWqTRTT5fAt/uBCcQDEPiku34jUOO/RjVXd18uiQGF+l5Tp
         A0M43HUuKbjOzySrqg4NiBLcAFxPug+VyFDc1Buv9lVnNULHXIzJX10DI+Rp7mYRTk7N
         4U0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550332; x=1747155132;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jcNpMhCfyvA/6mSR/+djGto9U0zKi73zc12A/lkWF+Q=;
        b=Yz8Vl5gR/HWHvhl+Wnnd2yQpYiUuj/HDsBQtcmH24R94ykrSG0f+N6fbrLsZzhNY4n
         OxaZ5gZcNjtqfGVAaqXu4eqYq3WBGFRVDFAKscuJI62oOZjpGl1MhvVSs1uqoQmMDeGW
         nLw438V/w8gIkeMeHTt4wK1i5DS7Rg2lAA4kNt/x9oTdsD4z1hdaXT1/S6/PAIUjdF17
         atwd+NTzsR5aVPBdYF7J9cYkNGomoiUlmh9FAlpLsqSV5OPCkuUnLYRJEf5uRYsMTuro
         5KKDI+8h07l5I0MrZaaWwqNvdbnDrftnPSdbdeEej8Vmlp00wr4eGOqLeTnhX7fzSDx6
         ilIw==
X-Gm-Message-State: AOJu0Yway623y1y+FNDAzCJYvR061Eq35HMxfGnLzgXN8c4KLL3eae//
	vFjqv9SWCK1FIE/V+6fAm8w/J38hxchqwqg7p/YAMUnqNOwUtc5WCe+wdw==
X-Gm-Gg: ASbGncuUFpIHcExT4ChNDV7uhE3BAvbA/1CvavhPNv36sC7b+pQb8eCYg5vgvQbLZlF
	negv0JfLLgx7thueIjoDectnmq5jaK2hQj6ryIn3jxcf6GzlwqAeZ0VbXkPrugxStSbp52gqDmK
	7gZJ7x25wiMODs50sMuLBxAQWPP646KEN1f+4gyCS6z6wrEFkPHzujMvzfO/WavEEKEvNs8GLD9
	KiY3saXhE6d+HNdvdPODDxlvHN28OWuDm3cNRx1IBXn2J5+a8eL8U3upNx+IZh7IAuu/Dn1svVA
	viargDEfx/Ys47DY7b9d7ivxu0WiRalKxEzToGLVrXaQi+9rYAEtyiF+mAUVTkg8nq3WbAqTvy0
	wwfhqT+re6g==
X-Google-Smtp-Source: AGHT+IFkxZQBdm9KBB1ZRaoupbLDFikCeyhEmwO7U7RC83JUMy9/iq0OKe0PRmNhijjDxsKR0eAo8w==
X-Received: by 2002:a17:907:7b8d:b0:aca:d6f2:c39e with SMTP id a640c23a62f3a-ad1e8c14806mr16022866b.23.1746550331503;
        Tue, 06 May 2025 09:52:11 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 16/16] xen/riscv: add basic UART support
Date: Tue,  6 May 2025 18:51:46 +0200
Message-ID: <9fbcd17751fb0b7925d622631acb0030ee110465.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Update Kconfig to select GENERIC_UART_INIT for basic UART init ( find a dt node
and call device specific device_init() ).

Drop `default n if RISCV` statement for config HAS_NS16550 as now ns16550 is
ready to be compiled and used by RISC-V. Also, make the config user selectable
for everyone except X86.

Initialize a minimal amount of stuff to have UART and Xen console:
 - Initialize uart by calling uart_init().
 - Initialize Xen console by calling console_init_{pre,post}irq().
 - Initialize timer and its internal lists which are used by
   init_timer() which is called by ns16550_init_postirq(); otherwise
   "Unhandled exception: Store/AMO Page Fault" occurs.
 - Enable local interrupt to recieve an input from UART

Signed-off-by: Oleksii Kurochko 
---
Changes in v2:
 - Drop #include  in setup.c, isn't needed anymore.
 - Drop call of percpu_init_areas() as it was needed when I used polling
   mode for UART,  for this case percpu is used to receive serial port info:
     struct serial_port *port = this_cpu(poll_port);
   So percpu isn't really needed at the current development state.
 - Make HAS_NS16550 user selectable for everyone, except X86.
 - Update the commit message.
---
 xen/arch/riscv/Kconfig   |  1 +
 xen/arch/riscv/setup.c   | 13 +++++++++++++
 xen/drivers/char/Kconfig |  3 +--
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 60520dab57..eb44318dda 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -2,6 +2,7 @@ config RISCV
 	def_bool y
 	select FUNCTION_ALIGNMENT_16B
 	select GENERIC_BUG_FRAME
+	select GENERIC_UART_INIT
 	select HAS_DEVICE_TREE
 	select HAS_PMAP
 	select HAS_UBSAN
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 4f92266224..5c7cd568f0 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -4,12 +4,16 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -136,8 +140,17 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     intc_preinit();
 
+    uart_init();
+    console_init_preirq();
+
     intc_init();
 
+    timer_init();
+
+    local_irq_enable();
+
+    console_init_postirq();
+
     printk("All set up\n");
 
     machine_halt();
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index e6e12bb413..8e49a52c73 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -2,8 +2,7 @@ config GENERIC_UART_INIT
 	bool
 
 config HAS_NS16550
-	bool "NS16550 UART driver" if ARM
-	default n if RISCV
+	bool "NS16550 UART driver" if !X86
 	default y
 	help
 	  This selects the 16550-series UART support. For most systems, say Y.
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 16:56:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 16:56:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977694.1364703 (Exim 4.92)
	(envelope-from )
	id 1uCLaM-0003aN-0c; Tue, 06 May 2025 16:56:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977694.1364703; Tue, 06 May 2025 16:56: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 1uCLaL-0003aG-U2; Tue, 06 May 2025 16:56:01 +0000
Received: by outflank-mailman (input) for mailman id 977694;
 Tue, 06 May 2025 16:56:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLaL-0003a4-A4
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:56:01 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fcb86f3a-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:56:00 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43cef035a3bso38010355e9.1
 for ; Tue, 06 May 2025 09:56:00 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-441b391c42bsm213418805e9.39.2025.05.06.09.55.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 09:55: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" 
X-Inumbo-ID: fcb86f3a-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746550560; x=1747155360; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=f0QPuDckgmBjGtmjN6+ro2L4EL4408HeOivJnI0knug=;
        b=mumb5Drg+xbkgfXoDrDS7JDUBQYSlX4o3BmGSzoK4A4rs0mYZBx3YoxcwlJIHlDBM7
         E+4U7F/sHvvEdI/gz/oMzHAsfPVMMramPSqzIhovB3v0rdwZtbHebILejlohqLPswd1x
         X4umHUMADjn8ej8GHvM7UdKaTrDrAGLQ3Dm0A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550560; x=1747155360;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=f0QPuDckgmBjGtmjN6+ro2L4EL4408HeOivJnI0knug=;
        b=Ws88sj5luLKPc4K+501YRRZh7e9LAgG7rxnOAmZrQTC9r0cZqcqkQ6qJZXKal78SAr
         Xvz/hOwoSWhtrkUhz/hkNIkOZgZFCtCbLl+LMHKm9bOuJZ/8LOy3+1LJQgHBV/FVUA/P
         +fj5FApjSU8N1vAlL3aTCEqJdJei9EYg+AhL+wrTBoXwpZQdlW9HIRg1hhhX66dVBIkS
         rbVt7b7UlbPHm2aKI79IhrdWCOPd0O+eg7mCR1vrD22/5t8JrxIzOhmZU9sdeY3gYC0P
         PKN/2btNqEN+LRWCEIFlCrS7WM9gtG1C38tQRS3YEqnu4u01Orto/vWJuU2A1MIKHfz9
         FYag==
X-Forwarded-Encrypted: i=1; AJvYcCUTggKxxdLgh0DFCT8wK9P7vL8SZJ+2naqalI5x/JSEE1aUdBd595OMgDVVngCkyuf1QSqSMDqUMNA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwBGTqTx7o8PbTYiaZPCWt49E4LeO6gjw4jB3qSvoJKVWEWYWjv
	9TGkjdFTEue7vlFh8LhEMiYCLHzJZQvVndmMtFqqeSZ1omREcauuMLwr7cZ3v6S96SOyccg1Bk9
	C
X-Gm-Gg: ASbGnctAO1g6ZPiwhJHgaCF/6kcMXKf7jB5NcQ+iSCUqKk05Qi8hLTAfFam2cy5Nu6s
	Un1RcQYUhn5ABck6zsXIEn07V3o2iYtGe5m31YXgZMWt5uGMYU40g8nCLIEj0yNJ3w4C3vIQbxP
	eGL3cJCk7lE8BBLnM6/asw78LystqvMJ8ThY211NtLosT5lr9FgcrbYf64Sp2zIdY7EtOIgFvtW
	z/FY/5WZ6NaZdQAK9CGEK4fSy/WqB46BRBa1ztxgfiSTdzXNt/56casDkDOIK3POfkc0cnN23FW
	SJ2kgqLqmD/hvDS9BMGLrLQ+OAtoFyZpFHm94hfWlCzs8HGQvD7n/1GTMbuNhOke4BvTqxSMExg
	gVClezw7MMH1BOBHt
X-Google-Smtp-Source: AGHT+IEWs9FBr+MfhSGpyAnzkxWzwR5cuBv9L7wLnjU62hB26r925f/QCitetRdkbPpj6fQ8R1Lm0g==
X-Received: by 2002:a05:600c:4e09:b0:43d:224:86b5 with SMTP id 5b1f17b1804b1-441c48b0213mr115376295e9.4.1746550559648;
        Tue, 06 May 2025 09:55:59 -0700 (PDT)
Message-ID: 
Date: Tue, 6 May 2025 17:55:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] efi: Add a function to check if Secure Boot mode is
 enabled
To: Kevin Lampis , xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Daniel Smith 
References: <20250506162449.1676405-1-kevin.lampis@cloud.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: <20250506162449.1676405-1-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

CC'ing the EFI maintainers.

On 06/05/2025 5:24 pm, Kevin Lampis wrote:
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index e39fbc3529..7c528cd5dd 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -870,6 +870,27 @@ static void __init pre_parse(const struct file *file)
>                     " last line will be ignored.\r\n");
>  }
>  
> +static void __init init_secure_boot_mode(void)
> +{
> +    EFI_STATUS status;
> +    EFI_GUID gv_uuid = EFI_GLOBAL_VARIABLE;
> +    uint8_t data = 0;
> +    UINTN size = sizeof(data);
> +    UINT32 attr = 0;

Newline between variables and code please.

> +    status = efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &gv_uuid, &attr,
> +                                 &size, &data);
> +
> +    if ( status == EFI_NOT_FOUND ||
> +         (status == EFI_SUCCESS &&
> +          attr == (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS) &&
> +          size == 1 && data == 0) )
> +        /* Platform does not support Secure Boot or it's disabled. */
> +        efi_secure_boot = false;
> +    else
> +        /* Everything else play it safe and assume enabled. */
> +        efi_secure_boot = true;
> +}

I'm not sure this logic does what you want when a weird answer comes
back from GetVariable().

Also, you can't have this be a common function, yet ...

> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
> index 7e1fce291d..b63d21f16c 100644
> --- a/xen/common/efi/runtime.c
> +++ b/xen/common/efi/runtime.c
> @@ -40,6 +40,9 @@ void efi_rs_leave(struct efi_rs_state *state);
>  unsigned int __read_mostly efi_num_ct;
>  const EFI_CONFIGURATION_TABLE *__read_mostly efi_ct;
>  
> +#if defined(CONFIG_X86) && !defined(CONFIG_PV_SHIM)
> +bool __ro_after_init efi_secure_boot;
> +#endif

... this variable exist only on x86.

Also, why adjust it for PV shim?  None of this is even compiled for PV shim.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 06 17:02:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:02:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977742.1364713 (Exim 4.92)
	(envelope-from )
	id 1uCLge-0005jR-L7; Tue, 06 May 2025 17:02:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977742.1364713; Tue, 06 May 2025 17: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 1uCLge-0005jK-IA; Tue, 06 May 2025 17:02:32 +0000
Received: by outflank-mailman (input) for mailman id 977742;
 Tue, 06 May 2025 17:02:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWh-00058E-Ar
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:15 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7450c7d3-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:52:11 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ace98258d4dso866837866b.2
 for ; Tue, 06 May 2025 09:52:11 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:52:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7450c7d3-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550331; x=1747155131; 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;
        bh=74wiABz14bkw2Z/ZaZ483gmJiMxC4gHcocH3VFNYNbQ=;
        b=MBkhhV87eQ6bgaluAlm3NUhVI2I0x3LOURr+fUAZSXLD17RlMNOM0TFE1bLRihbuCj
         /aJDV3M4oBQrdywhmpfGMYfZ7rpZ0YUfYByHjBE9duXEzk4HqMXAi8akTPpavw45d4KB
         qPO1yAXRgCnSBk8nUTlDDXErgBrI1v04d3okFLwpBStC8NNdD4ylEGLGkgILiCeePBsF
         denSCbXPGlDX6vj/TK6FGdY4erhyClBX5B3ZppeeDGxwrcNZa8c08Reys4DgRulyNdna
         1EqhwH9FNDtpuQ7ODoURI68dku4cHNWWN7x47LtAQ5YzxwxRtlgn3x/MrpnJDEGRFfm4
         pCnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550331; x=1747155131;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=74wiABz14bkw2Z/ZaZ483gmJiMxC4gHcocH3VFNYNbQ=;
        b=Fl6vlptdQgRLqYXwNSDxgM4emYHS5vOH1MTc7J/1qTub3EBrJusytrFflP97F7B65F
         b1PV6jEV8DYpUexpfTgRyIhrq3Qwuvhj+GRVlTiKZsOgiaI+BWYNjzZEs/bu/MTmTerC
         l4fhBIJOKZ+KgtwVJlJz2IhD+AL5tETlIe2HUdfxvPv01OlBv4Y6eoyOGe5kzi3CH1lY
         MfEewK0XUMlSmu1JCNc52lJ8/pet+WnL/j491jQnw+etKNLthEY5oKEVvWHaZIJ2Fxwf
         CzRbxiezCiWs9egzQTrHj/ZNfbPHNbBevk7t9fwuWvp/vYiqBL2xRgr6k/pCqDk8PkUm
         Vfdw==
X-Gm-Message-State: AOJu0Yx1YcBH9MXIh7y5g/DHJ98xGq87dzSwWBWFcAS+tSU0IpjxhdfA
	GCDdsL7eaqJQDc+qoHeEeRKe+1QQYNhrDny+kAYb4KQgDoxvKDn6GFUdmg==
X-Gm-Gg: ASbGnctv3poAlvvredZkrlTfCHi1pXcLMlZ+GzmgxEFCXvGiEciMUaEYAW/+uErI56e
	y4lx78mlytoHzQlvbAvmkWkj9nB3nMximrNhfGVbaRaEokoiohMut5IxWeJYqEkUvm6YBTKBbyC
	Hzv0NtU7ERevCIiLmVkJ2nVltKEVLSOmzR/HuTDhLpXUoG2p2dcBBRtJLQaolo/Lavx8gJK5Upu
	QPPZW2N4ojF+LIbPi3UJRszMTk7j3QWgZymh7XG6ZeJk14MzkkjvwcYEj21TxMMIGVwHw5xPe5F
	Hts8oMcDDnlweK0ejGIMmq6UU9xEa/TFyb+28bYCsjrZIeEpmLKwkCn+mky7zA6icfJWLZ9qbHU
	NsP7QM/tgrg==
X-Google-Smtp-Source: AGHT+IFblu95xoNtRnG4Tji7qi8R+0NxWxbkXy0mdy5QOgL2ttB1oJu0kBzpaskg/5IPpBcIaP9wCA==
X-Received: by 2002:a17:907:1c12:b0:ace:3732:8a86 with SMTP id a640c23a62f3a-ad1e8d053a9mr17933666b.41.1746550330549;
        Tue, 06 May 2025 09:52:10 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v2 15/16] xen/riscv: implement setup_irq()
Date: Tue,  6 May 2025 18:51:45 +0200
Message-ID: <6f17bbf0eb6240d7389d389f0973af6fda5cce29.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce support for IRQ setup on RISC-V by implementing setup_irq() and
__setup_irq(), adapted and extended from an initial implementation by [1].

__setup_irq() does the following:
  - Sets up an IRQ action.
  - Validates that shared IRQs have non-NULL `dev_id` and are only used when
    existing handlers allow sharing.
  - Uses smp_wmb() to enforce memory ordering after assigning desc->action
    to ensure visibility before enabling the IRQ.
  - Supports multi-action setups via CONFIG_IRQ_HAS_MULTIPLE_ACTION.

setup_irq() does the following:
  - Converts IRQ number to descriptor and acquires its lock.
  - Rejects registration if the IRQ is already assigned to a guest domain,
    printing an error.
  - Delegates the core setup to __setup_irq().
  - On first-time setup, disables the IRQ, routes it to Xen using
    intc_route_irq_to_xen(), sets default CPU affinity (current CPU),
    calls the handler’s startup routine, and finally enables the IRQ.

irq_set_affinity() invokes set_affinity() callback from the IRQ handler
if present.

Defined IRQ_NO_PRIORITY as default priority used when routing IRQs to Xen.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - Added implenmtation of aplic_set_irq_type() as it is going to be used in
   this commit. And also, update the implementation of it. Make default case
   of switch to do panic().
 - Move all forward declaration up  in asm/irq.h.
 - s/__setup_irq/_setup_irq.
 - Code style fixes.
 - Update commit message.
 - use smp_wmb() instead of smp_mb() in _setup_irq().
 - Drop irq_set_affinity().
 - Use plain C operator instead if {clear,set}_bit() for desc->status as it
   is always used under spinlock().
 - Drop set_bit(_IRQ_DISABLED, &desc->status) in setup_irq() as in the case
   when IRQ is setuped for a first time, desc->status should be already set
   to IRQ_DISABLED in init_one_irq_desc().
----
 xen/arch/riscv/include/asm/irq.h |  2 +
 xen/arch/riscv/irq.c             | 84 ++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+)

diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 1a05c5ff88..d35fac0a86 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -9,6 +9,8 @@
 
 #define NR_IRQS 1024
 
+#define IRQ_NO_PRIORITY 0
+
 /* TODO */
 #define nr_irqs 0U
 #define nr_static_irqs 0
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index 056bdf3ca8..969e22395d 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,6 +59,89 @@ int platform_get_irq(const struct dt_device_node *device, int index)
     return dt_irq.irq;
 }
 
+static int _setup_irq(struct irq_desc *desc, unsigned int irqflags,
+                      struct irqaction *new)
+{
+    bool shared = irqflags & IRQF_SHARED;
+
+    ASSERT(new != NULL);
+
+    /*
+     * Sanity checks:
+     *  - if the IRQ is marked as shared
+     *  - dev_id is not NULL when IRQF_SHARED is set
+     */
+    if ( desc->action != NULL && (!(desc->status & IRQF_SHARED) || !shared) )
+        return -EINVAL;
+    if ( shared && new->dev_id == NULL )
+        return -EINVAL;
+
+    if ( shared )
+        desc->status |= IRQF_SHARED;
+
+#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    new->next = desc->action;
+#endif
+
+    desc->action = new;
+    smp_wmb();
+
+    return 0;
+}
+
+int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new)
+{
+    int rc;
+    unsigned long flags;
+    struct irq_desc *desc = irq_to_desc(irq);
+    bool disabled;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    disabled = (desc->action == NULL);
+
+    if ( desc->status & IRQ_GUEST )
+    {
+        spin_unlock_irqrestore(&desc->lock, flags);
+        /*
+         * TODO: would be nice to have functionality to print which domain owns
+         *       an IRQ.
+         */
+        printk(XENLOG_ERR "ERROR: IRQ %u is already in use by a domain\n", irq);
+        return -EBUSY;
+    }
+
+    rc = _setup_irq(desc, irqflags, new);
+    if ( rc )
+        goto err;
+
+    /* First time the IRQ is setup */
+    if ( disabled )
+    {
+        /* Route interrupt to xen */
+        intc_route_irq_to_xen(desc, IRQ_NO_PRIORITY);
+
+        /*
+         * We don't care for now which CPU will receive the
+         * interrupt.
+         *
+         * TODO: Handle case where IRQ is setup on different CPU than
+         *       the targeted CPU and the priority.
+         */
+        desc->handler->set_affinity(desc, cpumask_of(smp_processor_id()));
+
+        desc->handler->startup(desc);
+
+        /* Enable irq */
+        desc->status &= ~IRQ_DISABLED;
+    }
+
+ err:
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    return rc;
+}
+
 int arch_init_one_irq_desc(struct irq_desc *desc)
 {
     desc->arch.type = IRQ_TYPE_INVALID;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 17:03:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:03:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977759.1364723 (Exim 4.92)
	(envelope-from )
	id 1uCLhE-0006LH-US; Tue, 06 May 2025 17:03:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977759.1364723; Tue, 06 May 2025 17:03: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 1uCLhE-0006LA-QS; Tue, 06 May 2025 17:03:08 +0000
Received: by outflank-mailman (input) for mailman id 977759;
 Tue, 06 May 2025 17:03:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWe-00058E-AW
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:12 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 728915db-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:52:08 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-acb2faa9f55so787367666b.3
 for ; Tue, 06 May 2025 09:52:08 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:52: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" 
X-Inumbo-ID: 728915db-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550328; x=1747155128; 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;
        bh=litmnL1mFXl7IfBQKSAEMuZm2aol2VAzqMHBocuz5Mc=;
        b=Z4FqmW0tjIRvSciGNP8tk6ZOjqVJoL+2mhg/qcnAYkp+OMBsQPs9FlASqcdoHCazEE
         rj84ubeRew0KBDtn/rsgE+BQAwnuEh5RkLKj/ZlGlExDEgQQSmE2FKvNaUqnEYKmD7Ce
         +EEjEM7qYr7cfn+w6OTGLUhSjzDZWMVtDmXo2TRnMTBpOT5REnzEDe3z56iq2KzfXZMM
         NPFsPMqWnYZ6oM/tDutoVbsuEyTo6m42mAsYswFXUbyjz/MTWUyHTdDIZNB2iQrdYsKF
         i3kfa9C1Ci70690uTIdcpDOc3YmkcfvuBF5GnyiJ3oXOXQvVgp9G1/yZc8z8fPe5DDsy
         lYhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550328; x=1747155128;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=litmnL1mFXl7IfBQKSAEMuZm2aol2VAzqMHBocuz5Mc=;
        b=DJSdHOUXYS/Mi2AE/7118fdIKCImGhv8igapB2J5HjAg9cIN4iXnYaKjJJw4sWmhlf
         Yv/zRYTIq9eElLgxykGk0whfG00XA0Q0q6HeXjL/lncHQ7bEYmhe8QRtz2NU5HzG0Tec
         XwGNXzsXsRhyz9kdKNTzYl3pNtn98LYCFJnPXRi7xX7w1Kq3E2lD+w2sNIPwzqErlFGG
         e6R3W+7bTzYxRBT9H4/TzVT3U4fnK3mXSK01k5eni/wzh2IwSsezxusuUSRWNHwnt/Ri
         gxa6LvlSAwM5wJu2NsSMFu3Ur3BpVZ8sx919Xpblud6AqwtjAimhO0ACgiaayzIKu58Z
         jwOw==
X-Gm-Message-State: AOJu0Yyd6n9jM0th0Y8fPqJG1Ya/lHCssa4sHJbwjw8NB02nupHHZdbi
	BSHsLBvkSvLu+Sv84ItVyguwI836hca0BlTv2ytWDwJ/rHYQQDiogng57Q==
X-Gm-Gg: ASbGncv7OrCvXcvxOGpyfu0GA5v3jn5/zIfTiztlmxDKfSBPLhOWREPw9AXA/GfKFKC
	aXmVTW2GvlgGXr3TbUxKGzzMDCBJpE7aELKPaZ77FK0mt6Qjs7l3onfFQw3HkvVAfGY3She4+mq
	y6MWvq8xIKnJaeYtR0/OliriezvECzIzysmebi4LQNngrN+nWJKLeu+D7ROBR5EpFzMoxryFHSt
	itk6lY1jm6OKe7mVZMxAowIk2dSrd41ofOFcZJt1oLGAQE2SwYSttR7OirPdE1p9LNFJKU3vinW
	K2mJtTlYryY5m1Xo+Vcixw7lNhWhnZ91kQq6hrd2RNUqg1RdF5KQeyt3XgTt8T/Jfcc45ld3BH0
	PHjkw4pEqgg==
X-Google-Smtp-Source: AGHT+IG/7pKhrKlFu76s5YoKOB7C8b7ohr5wUls16zb6a/DIy/w5fh/YtTd5UlTyYJLn20+NK7n5bQ==
X-Received: by 2002:a17:907:874e:b0:abf:a387:7e35 with SMTP id a640c23a62f3a-ad1e8d9b55dmr12164566b.53.1746550327492;
        Tue, 06 May 2025 09:52:07 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v2 12/16] xen/riscv: introduce intc_init() and helpers
Date: Tue,  6 May 2025 18:51:42 +0200
Message-ID: <13ce98ce580b6d1a38dcdcd711a6bcf92f4eb0cd.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce intc_init() to initialize the interrupt controller using the
registered hardware ops.
Also add intc_route_irq_to_xen() to route IRQs to Xen, with support for
setting IRQ type and priority via new internal helpers intc_set_irq_type()
and intc_set_irq_priority().

Call intc_init() to do basic initialization steps for APLIC and IMSIC.

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - This patch was part of "xen/riscv: Introduce intc_hw_operations abstraction"
   and splitted to have ability to merge patch "xen/riscv: initialize interrupt
   controller" to the current patch (where intc_init() call is actually
   introduced).
 - Add checks of that callbacks aren't set to NULL in intc_set_irq_priority()
   and intc_set_irq_type().
 - add num_irqs member to struct intc_info as it is used now in
   intc_route_irq_to_xen().
 - Add ASSERT(spin_is_locked(&desc->lock)) to intc_set_irq_priority() in
   the case this function will be called outside intc_route_irq_to_xen().
---
 xen/arch/riscv/include/asm/intc.h |  4 +++
 xen/arch/riscv/intc.c             | 45 +++++++++++++++++++++++++++++++
 xen/arch/riscv/setup.c            |  2 ++
 3 files changed, 51 insertions(+)

diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 2d55d74a2e..45a41147a6 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -44,4 +44,8 @@ void intc_preinit(void);
 
 void register_intc_ops(struct intc_hw_operations *ops);
 
+void intc_init(void);
+
+void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 122e7b32b5..15f358601d 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -1,9 +1,12 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 
@@ -21,3 +24,45 @@ void __init intc_preinit(void)
     else
         panic("ACPI interrupt controller preinit() isn't implemented\n");
 }
+
+void __init intc_init(void)
+{
+    ASSERT(intc_hw_ops);
+
+    if ( intc_hw_ops->init() )
+        panic("Failed to initialize the interrupt controller drivers\n");
+}
+
+/* desc->irq needs to be disabled before calling this function */
+static void intc_set_irq_type(struct irq_desc *desc, unsigned int type)
+{
+    ASSERT(desc->status & IRQ_DISABLED);
+    ASSERT(spin_is_locked(&desc->lock));
+    ASSERT(type != IRQ_TYPE_INVALID);
+    ASSERT(intc_hw_ops);
+
+    if ( intc_hw_ops->set_irq_type )
+        intc_hw_ops->set_irq_type(desc, type);
+}
+
+static void intc_set_irq_priority(struct irq_desc *desc, unsigned int priority)
+{
+    ASSERT(spin_is_locked(&desc->lock));
+    ASSERT(intc_hw_ops);
+
+    if ( intc_hw_ops->set_irq_priority )
+        intc_hw_ops->set_irq_priority(desc, priority);
+}
+
+void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
+{
+    ASSERT(desc->status & IRQ_DISABLED);
+    ASSERT(spin_is_locked(&desc->lock));
+    /* Can't route interrupts that don't exist */
+    ASSERT(intc_hw_ops && desc->irq < intc_hw_ops->info->num_irqs);
+
+    desc->handler = intc_hw_ops->host_irq_type;
+
+    intc_set_irq_type(desc, desc->arch.type);
+    intc_set_irq_priority(desc, priority);
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 82f8839eff..4f92266224 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -136,6 +136,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     intc_preinit();
 
+    intc_init();
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 17:03:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:03:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977771.1364732 (Exim 4.92)
	(envelope-from )
	id 1uCLhc-0006vE-7K; Tue, 06 May 2025 17:03:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977771.1364732; Tue, 06 May 2025 17: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 1uCLhc-0006v7-4m; Tue, 06 May 2025 17:03:32 +0000
Received: by outflank-mailman (input) for mailman id 977771;
 Tue, 06 May 2025 17:03:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWf-00058E-AM
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:13 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 73c51a7d-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:52:10 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5e5c7d6b96fso11138294a12.3
 for ; Tue, 06 May 2025 09:52:10 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:52: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" 
X-Inumbo-ID: 73c51a7d-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550330; x=1747155130; 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;
        bh=P6Bqs4HUZYvlu7+UKZCeflArWZzpdjYXovI0MbCmOOQ=;
        b=TUxILspRiu/N+p+mxbWi5uTmvv9OTkoPYKTf3Bj3b6Qp5bt0QvHBa9bhj3fmEncmhy
         MkXRaXR160BeBP7HlE4tcQgLP7gew4V5PO6RKd13b36GIzKRDr8+MQVM8z3ti3pXhEFT
         dLe0zuPAtlCELS9yBaI+x5epheUq3lVr75k8Im7Ap05eedjGVLCG0gJnGSHbKgEUoVea
         z4BUrAPWnQ5ToJeW+igrNqMFqNOEkqi0Hqe81F3EoHjmjTUWa3QJ9o4KcqUT86jaIVdy
         y/EgyKAnn916WztrhvAkq5J4nep975QndqzRt4T+G2ikNL3DOnWeE5C1PHfzv1jSqi6p
         l+7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550330; x=1747155130;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=P6Bqs4HUZYvlu7+UKZCeflArWZzpdjYXovI0MbCmOOQ=;
        b=Rr7exofxNEb3JKLTQBh/dULoM2TLwtZnJxTpFsWcb+FXsrpTe7piHEKaQBOEN3c+8u
         46l/oxvLBMY9RNWIAFRpBrBsANv5gj+ooux685Hger26c6xPlmHcGusdqRfZpMdiLsNf
         93QhMRUTJw2CTOIjUpYTk5dMg0VnorVUvdP8I1RqweETF/jgKL/d5e0OaA2qtB3aWKgL
         uGn655IH58Tpj7qM9KqX4GFi2gPHXdnjqRIo/PpM3yFWM4DBB2v8kt4IIjLRY/sFHeSc
         ddNSK2+zZi+JApGhEFy4wcHVOtXo7jjMskVuTOCsen9bzRPRGZQDSHolhEjHB2TKpwih
         /m0w==
X-Gm-Message-State: AOJu0YzPF5DlDHjcIXYII4aLlx9zYPWTpL/XQHK1rczTVGP9XN6nwzVz
	pooOCorq4it8uSq/4rB0fnRa480RiIc1/4LVEOEWI++VWIesGg8v5GsFGQ==
X-Gm-Gg: ASbGnctMXlCm+YvdGG9+BzWrNAwARkPesaIV2MOdsWnMFZCKVQooTIOzlgQTrIDMggb
	F2khTJDlVdzYSilAKlzyxhFyWPDXXN3fKWjhBDYFSdHR86+78Et5sihZhHV6Oz+i7AIEjOSXg/7
	sC4gnil/ovpZQSk4ujF4SxFfhpQfuyvjCYl9VfVhfQmngN89cdLcr6FRSAmw87hlSlQ2O11f7df
	qJld/oBz8IvPNb8u3XW1GNFWuG8J7OeQq8wEckI/b2EhQKKx1Uiy2KRSdMYpyLNbMRaJg1XgOLi
	C8LNoBhp9rhoZYpNH9T60UtifrQeuXJ274lZDusbLXTtoXcLu+7eJRVv/Qe4AEgo/O5pf3u3cGw
	+XzkWt0z7QQ==
X-Google-Smtp-Source: AGHT+IGmp6lEcZuOM7EOyfKzzNLgVyhyK3ohwHus5N69zv5PaqpnW7B0bPc6iRwxRjxJgODrKgddtQ==
X-Received: by 2002:a17:907:d87:b0:ad1:8b5c:114b with SMTP id a640c23a62f3a-ad1e8bc3344mr23293766b.18.1746550329573;
        Tue, 06 May 2025 09:52:09 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v2 14/16] xen/riscv: add external interrupt handling for hypervisor mode
Date: Tue,  6 May 2025 18:51:44 +0200
Message-ID: <5688ed044febf734d9c75aa2e6f52affccd3fce9.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=all
Content-Transfer-Encoding: 8bit

Implement functions necessarry to have working external interrupts in
hypervisor mode. The following changes are done:
  - Add a common function intc_handle_external_irq() to call APLIC specific
    function to handle an interrupt.
  - Update do_trap() function to handle IRQ_S_EXT case; add the check to catch
    case when cause of trap is an interrupt.
  - Add handle_interrrupt() member to intc_hw_operations structure.
  - Enable local interrupt delivery for IMSIC by calling of
    imsic_ids_local_delivery() in imsic_init(); additionally introduce helper
    imsic_csr_write() to update IMSIC_EITHRESHOLD and IMSIC_EITHRESHOLD.
  - Enable hypervisor external interrupts.
  - Implement aplic_handler_interrupt() and use it to init ->handle_interrupt
    member of intc_hw_operations for APLIC.
  - Add implementation of do_IRQ() to dispatch the interrupt.

The current patch is based on the code from [1].

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - use BIT() macros instead of 1UL << bit_num in aplic.c.
 - Drop passing of a cause to aplic_handle_interrupt() function. And update
   prototype of handle_interrupt() callback.
 - Drop ASSERT() in intc_handle_external_irqs() as it is useless.
 - Code style fixes.
 - Drop cause argument for intc_handle_external_irqs().
 - Update the commit message: drop words that imsic_ids_local_delivery() is
   implemented in this patch, it is only called.
 - Add cf_check for aplic_handle_interrupt(), aplic_set_irq_type().
 - Move forward declarations in asm/intc.h up.
 - Use plain C operator instead if {clear,set}_bit() for desc->status as it
   is always used under spinlock().
 - use writel() for writing to APLIC's sourcecfg in aplic_set_irq_type().
---
 xen/arch/riscv/aplic.c             | 70 ++++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/aplic.h |  7 +++
 xen/arch/riscv/include/asm/imsic.h |  1 +
 xen/arch/riscv/include/asm/intc.h  |  5 +++
 xen/arch/riscv/include/asm/irq.h   |  6 ++-
 xen/arch/riscv/intc.c              |  5 +++
 xen/arch/riscv/irq.c               | 47 ++++++++++++++++++++
 xen/arch/riscv/traps.c             | 19 ++++++++
 8 files changed, 159 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index e2bee7ad23..ef7fc2562d 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,6 +9,7 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -220,6 +221,70 @@ static void aplic_set_irq_affinity(struct irq_desc *desc, const cpumask_t *mask)
     spin_unlock(&aplic.lock);
 }
 
+static void cf_check aplic_handle_interrupt(struct cpu_user_regs *regs)
+{
+    /* disable to avoid more external interrupts */
+    csr_clear(CSR_SIE, BIT(IRQ_S_EXT, UL));
+
+    /* clear the pending bit */
+    csr_clear(CSR_SIP, BIT(IRQ_S_EXT, UL));
+
+    /* dispatch the interrupt */
+    do_IRQ(regs, csr_swap(CSR_STOPEI, 0) >> TOPI_IID_SHIFT);
+
+    /* enable external interrupts */
+    csr_set(CSR_SIE, BIT(IRQ_S_EXT, UL));
+}
+
+static void cf_check aplic_set_irq_type(struct irq_desc *desc, unsigned int type)
+{
+    /*
+    * Interrupt 0 isn't possible based on the spec:
+    *   Each of an APLIC’s interrupt sources has a fixed unique identity number in the range 1 to N,
+    *   where N is the total number of sources at the APLIC. The number zero is not a valid interrupt
+    *   identity number at an APLIC. The maximum number of interrupt sources an APLIC may support
+    *   is 1023.
+    *
+    * Thereby interrupt 1 will correspond to bit 0 in sourcecfg[] register,
+    * interrupt 2 ->sourcecfg[1] and so on.
+    *
+    * And that is the reason why we need -1.
+    */
+    unsigned int irq_bit = desc->irq - 1;
+
+    spin_lock(&aplic.lock);
+
+    switch(type)
+    {
+    case IRQ_TYPE_EDGE_RISING:
+        writel(APLIC_SOURCECFG_SM_EDGE_RISE, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_EDGE_FALLING:
+        writel(APLIC_SOURCECFG_SM_EDGE_FALL, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_LEVEL_HIGH:
+        writel(APLIC_SOURCECFG_SM_LEVEL_HIGH, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_LEVEL_LOW:
+        writel(APLIC_SOURCECFG_SM_LEVEL_LOW, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_NONE:
+        fallthrough;
+    case IRQ_TYPE_INVALID:
+        writel(APLIC_SOURCECFG_SM_INACTIVE, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    default:
+        panic("%s: APLIC doesnt support IRQ type: 0x%x?\n", __func__, type);
+    }
+
+    spin_unlock(&aplic.lock);
+}
+
 static const hw_irq_controller aplic_xen_irq_type = {
     .typename     = "aplic",
     .startup      = aplic_irq_startup,
@@ -233,6 +298,8 @@ static struct intc_hw_operations __ro_after_init aplic_ops = {
     .info                = &aplic_info,
     .init                = aplic_init,
     .host_irq_type       = &aplic_xen_irq_type,
+    .handle_interrupt    = aplic_handle_interrupt,
+    .set_irq_type        = aplic_set_irq_type,
 };
 
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
@@ -274,6 +341,9 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     register_intc_ops(&aplic_ops);
 
+    /* Enable supervisor external interrupt */
+    csr_set(CSR_SIE, BIT(IRQ_S_EXT, UL));
+
     return 0;
 }
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index dc4ccbb9aa..661d9f294f 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -18,6 +18,13 @@
 #define APLIC_DOMAINCFG_IE      BIT(8, UL)
 #define APLIC_DOMAINCFG_DM      BIT(2, UL)
 
+#define APLIC_SOURCECFG_SM_INACTIVE     0x0
+#define APLIC_SOURCECFG_SM_DETACH       0x1
+#define APLIC_SOURCECFG_SM_EDGE_RISE    0x4
+#define APLIC_SOURCECFG_SM_EDGE_FALL    0x5
+#define APLIC_SOURCECFG_SM_LEVEL_HIGH   0x6
+#define APLIC_SOURCECFG_SM_LEVEL_LOW    0x7
+
 #define APLIC_TARGET_HART_IDX_SHIFT 18
 
 struct aplic_regs {
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index 1d6ab4d685..c765d3d8e4 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -12,6 +12,7 @@
 #define ASM__RISCV__IMSIC_H
 
 #include 
+#include 
 #include 
 
 #define IMSIC_MMIO_PAGE_SHIFT   12
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 45a41147a6..1efa80fff6 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -22,6 +22,7 @@ struct intc_info {
     unsigned int num_irqs;
 };
 
+struct cpu_user_regs;
 struct irq_desc;
 
 struct intc_hw_operations {
@@ -38,6 +39,8 @@ struct intc_hw_operations {
     /* Set IRQ priority */
     void (*set_irq_priority)(struct irq_desc *desc, unsigned int priority);
 
+    /* handle external interrupt */
+    void (*handle_interrupt)(struct cpu_user_regs *regs);
 };
 
 void intc_preinit(void);
@@ -48,4 +51,6 @@ void intc_init(void);
 
 void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
 
+void intc_handle_external_irqs(struct cpu_user_regs *regs);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 6223bbbed5..1a05c5ff88 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -25,16 +25,20 @@ struct arch_irq_desc {
     unsigned int type;
 };
 
+struct cpu_user_regs;
+struct dt_device_node;
+
 static inline void arch_move_irqs(struct vcpu *v)
 {
     BUG_ON("unimplemented");
 }
 
-struct dt_device_node;
 int platform_get_irq(const struct dt_device_node *device, int index);
 
 void init_IRQ(void);
 
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq);
+
 #endif /* ASM__RISCV__IRQ_H */
 
 /*
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 15f358601d..478401cc74 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -54,6 +54,11 @@ static void intc_set_irq_priority(struct irq_desc *desc, unsigned int priority)
         intc_hw_ops->set_irq_priority(desc, priority);
 }
 
+void intc_handle_external_irqs(struct cpu_user_regs *regs)
+{
+    intc_hw_ops->handle_interrupt(regs);
+}
+
 void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
 {
     ASSERT(desc->status & IRQ_DISABLED);
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index 4c518bbd97..056bdf3ca8 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -11,6 +11,10 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
+#include 
 
 static irq_desc_t irq_desc[NR_IRQS];
 
@@ -85,3 +89,46 @@ void __init init_IRQ(void)
     if ( init_irq_data() < 0 )
         panic("initialization of IRQ data failed\n");
 }
+
+/* Dispatch an interrupt */
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action;
+
+    irq_enter();
+
+    spin_lock(&desc->lock);
+
+    if ( desc->handler->ack )
+        desc->handler->ack(desc);
+
+    if ( desc->status & IRQ_DISABLED )
+        goto out;
+
+    desc->status |= IRQ_INPROGRESS;
+
+    action = desc->action;
+
+    spin_unlock_irq(&desc->lock);
+
+#ifndef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    action->handler(irq, action->dev_id);
+#else
+    do {
+        action->handler(irq, action->dev_id);
+        action = action->next;
+    } while ( action );
+#endif /* CONFIG_IRQ_HAS_MULTIPLE_ACTION */
+
+    spin_lock_irq(&desc->lock);
+
+    desc->status &= ~IRQ_INPROGRESS;
+
+ out:
+    if ( desc->handler->end )
+        desc->handler->end(desc);
+
+    spin_unlock(&desc->lock);
+    irq_exit();
+}
diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c
index ea3638a54f..f061004d83 100644
--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -128,6 +129,24 @@ void do_trap(struct cpu_user_regs *cpu_regs)
         }
         fallthrough;
     default:
+        if ( cause & CAUSE_IRQ_FLAG )
+        {
+            /* Handle interrupt */
+            unsigned long icause = cause & ~CAUSE_IRQ_FLAG;
+
+            switch ( icause )
+            {
+            case IRQ_S_EXT:
+                intc_handle_external_irqs(cpu_regs);
+                break;
+
+            default:
+                break;
+            }
+
+            break;
+        }
+
         do_unexpected_trap(cpu_regs);
         break;
     }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 17:03:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:03:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977776.1364743 (Exim 4.92)
	(envelope-from )
	id 1uCLhd-00079g-FU; Tue, 06 May 2025 17:03:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977776.1364743; Tue, 06 May 2025 17:03: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 1uCLhd-00079X-Bq; Tue, 06 May 2025 17:03:33 +0000
Received: by outflank-mailman (input) for mailman id 977776;
 Tue, 06 May 2025 17:03:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLWd-00058E-A5
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:52:11 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 71f6a8f8-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:52:07 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ac2bb7ca40bso1018488766b.3
 for ; Tue, 06 May 2025 09:52:07 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1891a3cb9sm740295366b.60.2025.05.06.09.52.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 09:52: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" 
X-Inumbo-ID: 71f6a8f8-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746550327; x=1747155127; 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;
        bh=ZIRZTc0vLBatCko0zk/UXfbMtR+m+ezQ4Ux4TBsMyjQ=;
        b=Ar0NsDHSl4LX9nmusY/YTa1ITEZJIc4Rz3h76qPk+j/F3A6/oAGsVmMp8RFn9E2muL
         5mCCkTrunm7DsjSnnexzqx7P57Lo0mlbS2vUD4Cla1NcnZYlvEthe46YEsjDR2hBcMs6
         U/uXs/agEBJ7EEnV4tBYYJqLlvfJ2lFKe30oYWQceYYYeP3JV8TM15h403e3WPS/A4oa
         x9LVDAXEU3mP3PdrhssXca1KQPY0tfKjwxdIhZsuTory+82olFcVOnmmj0zp2zJ9zkBE
         Nga9O00DgDQbbFOuYr8N4HkHnlALDvorr8kD1pGOSUYqZeI7bGC/EIsribj0jOWibtAg
         AQ0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746550327; x=1747155127;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ZIRZTc0vLBatCko0zk/UXfbMtR+m+ezQ4Ux4TBsMyjQ=;
        b=R/H+sWQsiuk1wLDmcPbmQB54MWNrmQEqrHNuOs0w6TTZQAzjxgD3OS8twDWRuP4P/G
         8Ulz4sqYIDN8e1mHQQCTX2mnMJGs/S5rVIPui3lpqKsujSFOneCNoMuZkYjMCrwujYoJ
         oeyro1tsC/ZLNw8t1DZk7V3y/MbfDHccxg2pIb4uhLh9ZOC6N01Ai0Q0ZNxa0rRg6e0g
         MGDMCN4jcopSdbAWPN5jk7XPznTyhnJzNQCRBUKJ26/jG/Tz9MVTcX1BpQA13N8errX1
         C9fUOFpDBTtv+Nz5ouXugjd5Jld3o49wKgq0/jSqda88vsRFS+yVgMb7nnwg42aZEebc
         ButA==
X-Gm-Message-State: AOJu0YxXvsDocdrZL+zr3AYhwuUx83I1c7OgmlA7U3kyK4+rABwGKyq+
	IBKLo3UGwC4BEyjY8DTco9wXN66Fc4A13oBIO9DaBvErs+E/X8tC6hx58w==
X-Gm-Gg: ASbGncu2XiwZW1m4nHJhc1Z6y2WKgzB6HMc7SfaS4+WZMYwFmyPDBKl1mLCRGsXXR5X
	FmLThuKtAEEysTMTTnnH58xJrgebYyaKgsJNN3LD4aaG1eL9Z36kSWz4h1foneqzvSMNSCCOFll
	B2UjKw6MfSDmk+vtXItr+mAk3gzmeuLDyII2b3LHORJh+D5sCv8CrZ5gasS2JgSfJGSJ9HcRPyR
	RQbNz2qOspzojG11/9g0GGP2CFjI6lrFtGjOuZ6gn66E4cfFTwq0QKrF3cz58ZhBsVSM8xKxj1w
	7W9Xwomj2mliktBc5V5I1ISg0SeLCbB1pqU1RnG5DcjFXSLhRD3Y0p77acK9ffCVGtPV6vAP+RO
	6zdxsnBIGkpIMuZy3px19
X-Google-Smtp-Source: AGHT+IFL3eXemXbrwhyJqd+wyul2UXQ2sa9GN9ToBu2ZpXUyWxeG/kGZi6BZ3DFnaC4TQOqn9yQOrg==
X-Received: by 2002:a17:907:8d87:b0:ad1:e7f2:b94e with SMTP id a640c23a62f3a-ad1e8bcc880mr23868866b.18.1746550326504;
        Tue, 06 May 2025 09:52:06 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v2 11/16] xen/riscv: aplic_init() implementation
Date: Tue,  6 May 2025 18:51:41 +0200
Message-ID: <9129b10432dfc7ff8ba451842204342171da7dc1.1746530883.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

aplic_init() function does the following few things:
 - checks that IMSIC in device tree node  ( by checking msi-parent property
   in APLIC node ) is present as current one implmenetaion of AIA is
   supported only MSI method.
 - initialize IMSIC based on IMSIC device tree node
 - Read value of APLIC's paddr start/end and size.
 - Map aplic.regs
 - Setup APLIC initial state interrupts (disable all interrupts, set
   interrupt type and default priority, confgifure APLIC domaincfg) by
   calling aplic_init_hw_interrutps().

aplic_init() is based on the code from [1] and [2].

Since Microchip originally developed aplic.c, an internal discussion with
them led to the decision to use the MIT license.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7cfb4bd4748ca268142497ac5c327d2766fb342d
[2] https://gitlab.com/xen-project/people/olkur/xen/-/commit/392a531bfad39bf4656ce8128e004b241b8b3f3e

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - use __ro_after_init for aplic_ops.
 - s/nr_irqs/num_irqs.
 - s/dt_processor_hartid/dt_processor_cpuid.
 - Drop confusing comment in aplic_init_hw_interrupts().
 - Code style fixes.
 - Drop years for Copyright.
 - Revert changes which drop nr_irq define from asm/irq.h,
   it shouldn't be, at least, part of this patch.
 - Drop paddr_enf from struct aplic_regs. It is enough to have pair
   (paddr_start, size).
 - Make  struct aplic_priv of asm/aplic.h private by moving it to
   riscv/aplic-priv.h.
 - Add the comment above the initialization of APLIC's target register.
 - use writel() to access APLIC's registers.
 - use 'unsinged int' for local variable i in aplic_init_hw_interrupts.
 - Add the check that all modes in interrupts-extended property of
   imsic node are equal. And drop rc != EOVERFLOW when interrupts-extended
   property is read.
 - Add cf_check to aplic_init().
 - Fix a cycle of clrie register initialization in aplic_init_hw_interrupts().
   Previous implementation leads to out-of-boundary.
 - Declare member num_irqs in struct intc_info as it is used by APLIC code.
---
 xen/arch/riscv/aplic-priv.h        |  34 +++++++++
 xen/arch/riscv/aplic.c             | 106 +++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/aplic.h |  64 +++++++++++++++++
 xen/arch/riscv/include/asm/intc.h  |   3 +
 4 files changed, 207 insertions(+)
 create mode 100644 xen/arch/riscv/aplic-priv.h
 create mode 100644 xen/arch/riscv/include/asm/aplic.h

diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h
new file mode 100644
index 0000000000..8a208dba8a
--- /dev/null
+++ b/xen/arch/riscv/aplic-priv.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/aplic.h
+ *
+ * Private part of aplic.h header.
+ *
+ * RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ * Copyright (c) Vates.
+ */
+
+#ifndef ASM__RISCV_PRIV_APLIC_H
+#define ASM__RISCV_PRIV_APLIC_H
+
+#include 
+
+#include 
+#include 
+
+struct aplic_priv {
+    /* base physical address and size */
+    paddr_t paddr_start;
+    size_t  size;
+
+    /* registers */
+    volatile struct aplic_regs *regs;
+
+    /* imsic configuration */
+    const struct imsic_config *imsic_cfg;
+};
+
+#endif /* ASM__RISCV_PRIV_APLIC_H */
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 10ae81f7ac..797e5df020 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,19 +9,121 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+
+#include "aplic-priv.h"
 
 #include 
+#include 
 #include 
+#include 
+
+#define APLIC_DEFAULT_PRIORITY  1
+
+static struct aplic_priv aplic;
 
 static struct intc_info __ro_after_init aplic_info = {
     .hw_version = INTC_APLIC,
 };
 
+static void __init aplic_init_hw_interrupts(void)
+{
+    unsigned int i;
+
+    /* Disable all interrupts */
+    for ( i = 0; i < ARRAY_SIZE(aplic.regs->clrie); i++)
+        writel(-1U, &aplic.regs->clrie[i]);
+
+    /* Set interrupt type and default priority for all interrupts */
+    for ( i = 1; i <= aplic_info.num_irqs; i++ )
+    {
+        writel(0, &aplic.regs->sourcecfg[i - 1]);
+        /*
+         * 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.
+         */
+        writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i - 1]);
+    }
+
+    writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg);
+}
+
+static int __init cf_check aplic_init(void)
+{
+    int rc;
+    dt_phandle imsic_phandle;
+    uint32_t irq_range[num_possible_cpus() * 2];
+    const __be32 *prop;
+    uint64_t size, paddr;
+    struct dt_device_node *imsic_node;
+    const struct dt_device_node *node = aplic_info.node;
+
+    /* Check for associated imsic node */
+    rc = dt_property_read_u32(node, "msi-parent", &imsic_phandle);
+    if ( !rc )
+        panic("%s: IDC mode not supported\n", node->full_name);
+
+    imsic_node = dt_find_node_by_phandle(imsic_phandle);
+    if ( !imsic_node )
+        panic("%s: unable to find IMSIC node\n", node->full_name);
+
+    rc = dt_property_read_u32_array(imsic_node, "interrupts-extended",
+                                    irq_range, ARRAY_SIZE(irq_range));
+    if ( rc )
+        panic("%s: unable to find interrupt-extended in %s node\n",
+              __func__, imsic_node->full_name);
+
+    if ( irq_range[1] == IRQ_M_EXT )
+        /* Machine mode imsic node, ignore this aplic node */
+        return 0;
+
+    for ( unsigned int i = 0; i < ARRAY_SIZE(irq_range); i += 2 )
+    {
+        if ( irq_range[i + 1] != irq_range[1] )
+            panic("%s: mode[%d] != %d\n", __func__, i + 1, irq_range[1]);
+    }
+
+    rc = imsic_init(imsic_node);
+    if ( rc )
+        panic("%s: Failded to initialize IMSIC\n", node->full_name);
+
+    /* Find out number of interrupt sources */
+    rc = dt_property_read_u32(node, "riscv,num-sources", &aplic_info.num_irqs);
+    if ( !rc )
+        panic("%s: failed to get number of interrupt sources\n",
+              node->full_name);
+
+    prop = dt_get_property(node, "reg", NULL);
+    dt_get_range(&prop, node, &paddr, &size);
+    if ( !paddr )
+        panic("%s: first MMIO resource not found\n", node->full_name);
+
+    aplic.paddr_start = paddr;
+    aplic.size = size;
+
+    aplic.regs = ioremap(paddr, size);
+    if ( !aplic.regs )
+        panic("%s: unable to map\n", node->full_name);
+
+    /* Setup initial state APLIC interrupts */
+    aplic_init_hw_interrupts();
+
+    return 0;
+}
+
+static struct intc_hw_operations __ro_after_init aplic_ops = {
+    .info                = &aplic_info,
+    .init                = aplic_init,
+};
+
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
                                     unsigned int intsize,
                                     unsigned int *out_hwirq,
@@ -53,8 +155,12 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     aplic_info.node = node;
 
+    aplic.imsic_cfg = imsic_get_config();
+
     dt_irq_xlate = aplic_irq_xlate;
 
+    register_intc_ops(&aplic_ops);
+
     return 0;
 }
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
new file mode 100644
index 0000000000..6221030a68
--- /dev/null
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/asm/include/aplic.h
+ *
+ * RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ */
+
+#ifndef ASM__RISCV__APLIC_H
+#define ASM__RISCV__APLIC_H
+
+#include 
+
+#include 
+
+#define APLIC_DOMAINCFG_IE      BIT(8, UL)
+#define APLIC_DOMAINCFG_DM      BIT(2, UL)
+
+struct aplic_regs {
+    uint32_t domaincfg;
+    uint32_t sourcecfg[1023];
+    uint8_t _reserved1[0xBC0];
+
+    uint32_t mmsiaddrcfg;
+    uint32_t mmsiaddrcfgh;
+    uint32_t smsiaddrcfg;
+    uint32_t smsiaddrcfgh;
+    uint8_t _reserved2[0x30];
+
+    uint32_t setip[32];
+    uint8_t _reserved3[92];
+
+    uint32_t setipnum;
+    uint8_t _reserved4[0x20];
+
+    uint32_t in_clrip[32];
+    uint8_t _reserved5[92];
+
+    uint32_t clripnum;
+    uint8_t _reserved6[32];
+
+    uint32_t setie[32];
+    uint8_t _reserved7[92];
+
+    uint32_t setienum;
+    uint8_t _reserved8[32];
+
+    uint32_t clrie[32];
+    uint8_t _reserved9[92];
+
+    uint32_t clrienum;
+    uint8_t _reserved10[32];
+
+    uint32_t setipnum_le;
+    uint32_t setipnum_be;
+    uint8_t _reserved11[4088];
+
+    uint32_t genmsi;
+    uint32_t target[1023];
+};
+
+#endif /* ASM__RISCV__APLIC_H */
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index e72d5fd9d3..2d55d74a2e 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -17,6 +17,9 @@ enum intc_version {
 struct intc_info {
     enum intc_version hw_version;
     const struct dt_device_node *node;
+
+    /* number of irqs */
+    unsigned int num_irqs;
 };
 
 struct irq_desc;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 17:04:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:04:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977810.1364754 (Exim 4.92)
	(envelope-from )
	id 1uCLiG-0008Dj-Po; Tue, 06 May 2025 17:04:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977810.1364754; Tue, 06 May 2025 17:04: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 1uCLiG-0008Da-Ju; Tue, 06 May 2025 17:04:12 +0000
Received: by outflank-mailman (input) for mailman id 977810;
 Tue, 06 May 2025 17:04:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLY9-00058E-FA
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 16:53:45 +0000
Received: from mail137-14.atl71.mandrillapp.com
 (mail137-14.atl71.mandrillapp.com [198.2.137.14])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a6883d8e-2a9a-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 18:53:44 +0200 (CEST)
Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail137-14.atl71.mandrillapp.com (Mailchimp) with ESMTP id
 4ZsPby2618z7064j4
 for ; Tue,  6 May 2025 16:53:34 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 ded5974a2ff842878c883815f8678456; Tue, 06 May 2025 16:53: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" 
X-Inumbo-ID: a6883d8e-2a9a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1746550414; x=1746820414;
	bh=fItoXDfcJHVJurWCoS7c4R6EdAt4qPJgrbuFX4XZ8VY=;
	h=From:Subject:Message-Id:To:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=ax6he6nssMtjkNV7M9C7mqrOnGgPCpHfooBVrMF1ESw2dSMbnqBN73O3bFlVwc0L/
	 4sTJhTQIGRrYpGLLvymxUBVIo7Uj9C2008bFFvRxQO8L1lt5rq4p4L9th3aof3JWQd
	 +L55Y9SwYVQ5Z62VfnoDgKh0RdI3WXgBCVdzejMfIL+NirAsh/AxqzI4Ty7LfXhtW8
	 Wix2Hx0VY9LCvUf11rr5t0aM90gOJt+uyNqTa/PI5nLGI77fB/NESHqNNPKewtqp2R
	 dMz/wOUBZ7dVdbzkeL43B2J43hrc1lEp83QXXHYLosIV0PbX3YYEOh6oA5pFMqGjbD
	 rq0PYgc+jyEaA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1746550414; x=1746810914; i=teddy.astie@vates.tech;
	bh=fItoXDfcJHVJurWCoS7c4R6EdAt4qPJgrbuFX4XZ8VY=;
	h=From:Subject:Message-Id:To:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=w72qnaYs/AwEmfdPdeyaJvHIczOpkIclV5xghStXGFzhrCE2OZTlsSgP2swbZSmOg
	 HwjsKclfGMHB1rH87G/kXA/bqzGcilhJJfUv8wOIt8WLK2wCxCBpLqwUK2honG2HE7
	 KsEdSx3j6q6aBqDxLcIc1osz7dkgSuUpXE+2mqGIX2u3gWh5PVl5ZK7+IHrKUtIQIJ
	 1gfCJzvbBNscgV1zpV6S+lhGuGhAQDeZoVY9UZf7kA8xpWtti2CLCBroqf1dGPPGjI
	 mnmAtc5Iy9KDRme7PjN9m2eKJBkjwciTKp+0r2lux6O8EcH7GvwOIVxyoduyewjnL6
	 YYxpAD4Z90oEg==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=200/4]=20Add=20lockdown=20mode?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1746550413366
Message-Id: <28b1d569-2f9a-45b7-9e94-09c9c0d73d20@vates.tech>
To: "Kevin Lampis" , xen-devel@lists.xenproject.org
References: <20250506162347.1676357-1-kevin.lampis@cloud.com>
In-Reply-To: <20250506162347.1676357-1-kevin.lampis@cloud.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.ded5974a2ff842878c883815f8678456?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250506:md
Date: Tue, 06 May 2025 16:53:34 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hello Kevin,

> The intention of lockdown mode is to prevent attacks from a rogue dom0
> userspace from compromising the system.

Do we consider Dom0 kernel-space as well (thus Dom0 as a whole), or only 
userland, what about privcmd device (which can issue hypercalls) ?

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Tue May 06 17:14:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:14:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977844.1364762 (Exim 4.92)
	(envelope-from )
	id 1uCLsC-0002V7-Md; Tue, 06 May 2025 17:14:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977844.1364762; Tue, 06 May 2025 17: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 1uCLsC-0002V0-Jq; Tue, 06 May 2025 17:14:28 +0000
Received: by outflank-mailman (input) for mailman id 977844;
 Tue, 06 May 2025 17:14:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLsB-0002Tg-PV
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 17:14:27 +0000
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com
 [2607:f8b0:4864:20::102a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8ebf9602-2a9d-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 19:14:25 +0200 (CEST)
Received: by mail-pj1-x102a.google.com with SMTP id
 98e67ed59e1d1-30820167b47so101587a91.0
 for ; Tue, 06 May 2025 10:14: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" 
X-Inumbo-ID: 8ebf9602-2a9d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746551663; x=1747156463; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eOC5OeBMf7pOLob0OlXd7UldqLr5KECMJZ9sNcHSx0M=;
        b=JQo+SknOpGjaZFywK70s+P1pY12RcQPtTqMPwLr2/jP4Oflq6qgXPqnM4gX8nkGihN
         WAP4w9k5onU0kmXlqIU1F8/M66tydZGuqld3/Q2DVWLsDMhS+mITwOttkmm3kk00Wh7o
         9Y/Pd6zeGRIKcHL2iPmXiz2ZuRHqLIx2XLISw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746551663; x=1747156463;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=eOC5OeBMf7pOLob0OlXd7UldqLr5KECMJZ9sNcHSx0M=;
        b=wv4RCC9IWefiQc4CwP0MzxxFR+x91hu64+BlZ1PTj6Gh/9I9xBFn9FAuxLQCE4PTbG
         F7bt3UfdAWV5N7Uz2CsLsjJUnRczFJnbg/RcSUG4ES2R1AMaIBRdeLnZAone3hyn+5Tq
         s9EhWpNHI+xzt3tR2SJfsNz6qet5ZS8sQtGy2NyvS0YeOYzhcr6xvu9W7fTrIk+sR9+e
         VaVA3VWqi/ca7TBIOhLFPfwrjiAyzgWnLasQymFcjq2Swn6rlE/nEwX95Dv1RSHp7u+d
         prh9hLh/rztFB5o74pog2m/0t02jv8zKn96vUpSQ34pdL6tBTPgjeuVRPNbARhtOEl9s
         EoUQ==
X-Gm-Message-State: AOJu0YwkGyPSCvVpIq2ev62L/BUKcj+Gk+RxIMDvhOPg6sGAWZDg/n2D
	/UtIjAZBvj/sEnavFRmwPeiTnfImu3YSmnZ3e/vmwKlQl+gAZWXsRywzRDmHLdzR6oEFsKRhxQZ
	3cApKdZyHgKRoeVySa9oO4GkHFfxcYEkVR8wEejns1HPkdmIZJKM=
X-Gm-Gg: ASbGncv15Gd1p3l4m+hWGQk5tQ8fHsE+572e4Mzau5Wf+9T1ejbT30GvmyOZnpsaR9K
	Ir5wS+T2A+S30phpgcIhjEK2VGrLTbA4xGMU8BtMdKfqvcP2UM1TY8mAogZ4IfywC/TeH+uhztO
	rkjjBfmcpLDnC8BgoMZWnQ
X-Google-Smtp-Source: AGHT+IHF4sDTqGWBG9rJQ26zlW4WZMGnk2VmRKuDHRiAnPOphDKjLiVS3faXDgu7Y5YsrQIenFRbI1PR7LyW5HvDBLQ=
X-Received: by 2002:a17:90b:554e:b0:2fa:2133:bc87 with SMTP id
 98e67ed59e1d1-30aa87b408bmr828030a91.6.1746551663490; Tue, 06 May 2025
 10:14:23 -0700 (PDT)
MIME-Version: 1.0
References: <20250506162510.1676425-1-kevin.lampis@cloud.com> 
In-Reply-To: 
From: Kevin Lampis 
Date: Tue, 6 May 2025 18:13:59 +0100
X-Gm-Features: ATxdqUHvDCDtD4TRpnRd-qY0jiBiVDDTOTS4VVo9-3muFxug0JGr6uq-Pfk030o
Message-ID: 
Subject: Re: [PATCH 3/4] Add lockdown mode
To: Teddy Astie 
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 6, 2025 at 5:49=E2=80=AFPM Teddy Astie =
 wrote:
> (I can't find the PATCH 4/4)

I apologize. The missing patch will be posted as soon as we can.

> I am not convinced of the efficiency of being able to toggle lockdown
> (including disabling it) mode from command-line.

As you say a malicious userland could hijack the xen command-line arguments=
.
Patch 4 is about ignoring potentially dangerous command line arguments
when lockdown mode is enabled.
It is not about disabling lockdown mode itself. Sorry if the
description was confusing.

>Do we consider Dom0 kernel-space as well (thus Dom0 as a whole)

Dom0 kernel is part of the trusted computing base for Secure Boot so
we don't need to worry about that.

>what about privcmd device (which can issue hypercalls) ?

We do have a solution for securing hypercalls but I believe it will be
part of another patch series.


From xen-devel-bounces@lists.xenproject.org Tue May 06 17:16:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:16:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977859.1364772 (Exim 4.92)
	(envelope-from )
	id 1uCLti-0003IQ-08; Tue, 06 May 2025 17:16:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977859.1364772; Tue, 06 May 2025 17: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 1uCLth-0003IJ-Ti; Tue, 06 May 2025 17:16:01 +0000
Received: by outflank-mailman (input) for mailman id 977859;
 Tue, 06 May 2025 17:16:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLtg-0003I5-KZ
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 17:16:00 +0000
Received: from fout-a5-smtp.messagingengine.com
 (fout-a5-smtp.messagingengine.com [103.168.172.148])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4baaf0a-2a9d-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 19:15:55 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.phl.internal (Postfix) with ESMTP id 4CC3313814D6;
 Tue,  6 May 2025 13:15:54 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Tue, 06 May 2025 13:15:54 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 6 May 2025 13:15: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" 
X-Inumbo-ID: c4baaf0a-2a9d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1746551754;
	 x=1746638154; bh=r3C7Cx71JtnvXS2B9VHdE8tIW7iQ8lSDLZJ61gznPeU=; b=
	jutSPlto6G1CZkPno2H60NBXE1PvGZC3Ks2bwBpUmt0duCsnOFMZlJxPoKlTFTfd
	nHzpJif4pqDrkExlIwPAn7bTJvjKR6ZXU1YkYriG2PgpoLDeCO7KtcaOBrmVoqNP
	F+FIcRnto2Q1duY6Y5C2teNo6+vuNK815VoGh29wDf6gDdn5AVQDiUaLF6Qgj8xB
	BuZGiRGIlSjv8PS2cUgf4RIHL0eYgZJeugOSqC5QZrrN22hFMuRbu+SOuCtvZwif
	NE+S6BO+eYMROt0KSW9EjMjBJiziEvEKMHvFs8zJgVyE/3jkOfLJWXZQLCEb99f8
	o4N1P+4CYa7kfc3SNns2HQ==
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=fm3; t=
	1746551754; x=1746638154; bh=r3C7Cx71JtnvXS2B9VHdE8tIW7iQ8lSDLZJ
	61gznPeU=; b=doCtDDJdj17ewHE6q1oO9kfuRizcDxdMoLKpJ83pnCsBWIH68pI
	urt2vnGtcNN+14IHY5IJ5aJRRVA+rDAxwmYbKeUC1r828UcsGUr7lOCWOno7AqZa
	pT2a6N4AwOHF4FBEi5KObsT+xjUMKQVPmdrO1NurOmQmUIcOWls/Wm+8G6bHBAN0
	NK1/1CkthqPHZGfmAq20Fh0HA+iuYKJU/3LM+iVTJ0IxSoyE44CyJJQEaP8aHewI
	hMYbxXnWsuysajk7b/9Eh8n6TTKqWeQMvGZruJdluDDJCx2X2SNiWCP73Nc46o2p
	5ib4I4ZNo7MPkM8U9vFljgUB/GU6Yk7UMFA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvkeegheehucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepfeeggfekvdffhfdvjefggffgleeitdetfeeifeeigedtgedvie
    elkeeuueejueeknecuffhomhgrihhnpeigvghnphhrohhjvggtthdrohhrghenucevlhhu
    shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkh
    esihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedu
    tddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprhhoshhsrdhlrghgvghrfigrlh
    hlsegtihhtrhhigidrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhs
    rdigvghnrdhorhhgpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnh
    hprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihig
    rdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtg
    homhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghh
    pdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtoh
    epjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopehjuhhlihgvnhesgigv
    nhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 6 May 2025 19:15:49 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Ross Lagerwall 
Cc: Xen-devel , xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 0/4] LivePatch signing support
Message-ID: 
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="YXVRcQecoyfcOYEc"
Content-Disposition: inline
In-Reply-To: <20250506143218.1782603-1-ross.lagerwall@citrix.com>


--YXVRcQecoyfcOYEc
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 6 May 2025 19:15:49 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Ross Lagerwall 
Cc: Xen-devel , xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 0/4] LivePatch signing support

On Tue, May 06, 2025 at 03:32:12PM +0100, Ross Lagerwall wrote:
> Live patch signing support was mentioned as future work in the design
> document several years ago. This series finally implements support for
> it since it is a requirement of Secure Boot to prevent loading unsigned
> code into Xen.
>=20
> Note that this series depends on another patch that has not yet been
> merged:
> xen/lib: Export additional sha256 functions
> https://lists.xenproject.org/archives/html/xen-devel/2025-05/msg00222.html
>=20
> Jennifer Herbert (1):
>   livepatch: Verify livepatch signatures
>=20
> Kevin Lampis (1):
>   livepatch: Embed public key in Xen
>=20
> Ross Lagerwall (2):
>   docs: Introduce live patch signing
>   crypto: Add RSA support

Patches 1 and 4 seems to be lost...

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--YXVRcQecoyfcOYEc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgaQ8YACgkQ24/THMrX
1ywo/Qf/atQOQQW6QhoNBolkdNVltezJOOcRY9duo5eiChUA4nXVPqBaAjrjIOuE
cbjLBvCgAtQD6Vd27+guh7HSmK+pY5TAThLvk5/5wKFWbMhHwcwgfhraiEVmu/Rs
94K+ji4QV1LOovsvUA5jFkDu8YnbDsSNORxVWTOQo5FKdQkFvDV0k4Y3GOJa+r6T
gCzA253bhK/sYh5JR0DB/aZWcrBw/pqfGhBkQgCZSic4dd0XYqNSdYzDCOxuYDDT
tTh9LZTyLm6l6pluEf+b6OG0zXAJEsherix7LPdN4kypdKFLxXhQfXlUvRyc4wHp
AU9U0FHuM8nnPclE5l0tSCL+ug/Xyg==
=JXur
-----END PGP SIGNATURE-----

--YXVRcQecoyfcOYEc--


From xen-devel-bounces@lists.xenproject.org Tue May 06 17:16:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:16:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977860.1364782 (Exim 4.92)
	(envelope-from )
	id 1uCLtp-0003Zi-7J; Tue, 06 May 2025 17:16:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977860.1364782; Tue, 06 May 2025 17: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 1uCLtp-0003Zb-4c; Tue, 06 May 2025 17:16:09 +0000
Received: by outflank-mailman (input) for mailman id 977860;
 Tue, 06 May 2025 17:16:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLtn-0003I5-RF
 for xen-devel@lists.xen.org; Tue, 06 May 2025 17:16:07 +0000
Received: from fout-a5-smtp.messagingengine.com
 (fout-a5-smtp.messagingengine.com [103.168.172.148])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c4c43c99-2a9d-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 19:15:55 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.phl.internal (Postfix) with ESMTP id 4CC3313814D6;
 Tue,  6 May 2025 13:15:54 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Tue, 06 May 2025 13:15:54 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 6 May 2025 13:15: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" 
X-Inumbo-ID: c4c43c99-2a9d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1746551754;
	 x=1746638154; bh=r3C7Cx71JtnvXS2B9VHdE8tIW7iQ8lSDLZJ61gznPeU=; b=
	jutSPlto6G1CZkPno2H60NBXE1PvGZC3Ks2bwBpUmt0duCsnOFMZlJxPoKlTFTfd
	nHzpJif4pqDrkExlIwPAn7bTJvjKR6ZXU1YkYriG2PgpoLDeCO7KtcaOBrmVoqNP
	F+FIcRnto2Q1duY6Y5C2teNo6+vuNK815VoGh29wDf6gDdn5AVQDiUaLF6Qgj8xB
	BuZGiRGIlSjv8PS2cUgf4RIHL0eYgZJeugOSqC5QZrrN22hFMuRbu+SOuCtvZwif
	NE+S6BO+eYMROt0KSW9EjMjBJiziEvEKMHvFs8zJgVyE/3jkOfLJWXZQLCEb99f8
	o4N1P+4CYa7kfc3SNns2HQ==
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=fm3; t=
	1746551754; x=1746638154; bh=r3C7Cx71JtnvXS2B9VHdE8tIW7iQ8lSDLZJ
	61gznPeU=; b=doCtDDJdj17ewHE6q1oO9kfuRizcDxdMoLKpJ83pnCsBWIH68pI
	urt2vnGtcNN+14IHY5IJ5aJRRVA+rDAxwmYbKeUC1r828UcsGUr7lOCWOno7AqZa
	pT2a6N4AwOHF4FBEi5KObsT+xjUMKQVPmdrO1NurOmQmUIcOWls/Wm+8G6bHBAN0
	NK1/1CkthqPHZGfmAq20Fh0HA+iuYKJU/3LM+iVTJ0IxSoyE44CyJJQEaP8aHewI
	hMYbxXnWsuysajk7b/9Eh8n6TTKqWeQMvGZruJdluDDJCx2X2SNiWCP73Nc46o2p
	5ib4I4ZNo7MPkM8U9vFljgUB/GU6Yk7UMFA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvkeegheehucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepfeeggfekvdffhfdvjefggffgleeitdetfeeifeeigedtgedvie
    elkeeuueejueeknecuffhomhgrihhnpeigvghnphhrohhjvggtthdrohhrghenucevlhhu
    shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkh
    esihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedu
    tddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprhhoshhsrdhlrghgvghrfigrlh
    hlsegtihhtrhhigidrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhs
    rdigvghnrdhorhhgpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnh
    hprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihig
    rdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtg
    homhdprhgtphhtthhopegrnhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghh
    pdhrtghpthhtohepmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtoh
    epjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopehjuhhlihgvnhesgigv
    nhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 6 May 2025 19:15:49 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Ross Lagerwall 
Cc: Xen-devel , xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 0/4] LivePatch signing support
Message-ID: 
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="YXVRcQecoyfcOYEc"
Content-Disposition: inline
In-Reply-To: <20250506143218.1782603-1-ross.lagerwall@citrix.com>


--YXVRcQecoyfcOYEc
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 6 May 2025 19:15:49 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Ross Lagerwall 
Cc: Xen-devel , xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH 0/4] LivePatch signing support

On Tue, May 06, 2025 at 03:32:12PM +0100, Ross Lagerwall wrote:
> Live patch signing support was mentioned as future work in the design
> document several years ago. This series finally implements support for
> it since it is a requirement of Secure Boot to prevent loading unsigned
> code into Xen.
>=20
> Note that this series depends on another patch that has not yet been
> merged:
> xen/lib: Export additional sha256 functions
> https://lists.xenproject.org/archives/html/xen-devel/2025-05/msg00222.html
>=20
> Jennifer Herbert (1):
>   livepatch: Verify livepatch signatures
>=20
> Kevin Lampis (1):
>   livepatch: Embed public key in Xen
>=20
> Ross Lagerwall (2):
>   docs: Introduce live patch signing
>   crypto: Add RSA support

Patches 1 and 4 seems to be lost...

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--YXVRcQecoyfcOYEc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgaQ8YACgkQ24/THMrX
1ywo/Qf/atQOQQW6QhoNBolkdNVltezJOOcRY9duo5eiChUA4nXVPqBaAjrjIOuE
cbjLBvCgAtQD6Vd27+guh7HSmK+pY5TAThLvk5/5wKFWbMhHwcwgfhraiEVmu/Rs
94K+ji4QV1LOovsvUA5jFkDu8YnbDsSNORxVWTOQo5FKdQkFvDV0k4Y3GOJa+r6T
gCzA253bhK/sYh5JR0DB/aZWcrBw/pqfGhBkQgCZSic4dd0XYqNSdYzDCOxuYDDT
tTh9LZTyLm6l6pluEf+b6OG0zXAJEsherix7LPdN4kypdKFLxXhQfXlUvRyc4wHp
AU9U0FHuM8nnPclE5l0tSCL+ug/Xyg==
=JXur
-----END PGP SIGNATURE-----

--YXVRcQecoyfcOYEc--


From xen-devel-bounces@lists.xenproject.org Tue May 06 17:16:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:16:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977867.1364792 (Exim 4.92)
	(envelope-from )
	id 1uCLu6-00046u-E0; Tue, 06 May 2025 17:16:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977867.1364792; Tue, 06 May 2025 17:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCLu6-00046n-BU; Tue, 06 May 2025 17:16:26 +0000
Received: by outflank-mailman (input) for mailman id 977867;
 Tue, 06 May 2025 17:16:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLjP-00068s-Ar
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 17:05:23 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4bf75eba-2a9c-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 19:05:22 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5e5e22e6ed2so9356575a12.3
 for ; Tue, 06 May 2025 10:05:22 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1895087d1sm734784366b.128.2025.05.06.10.05.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 10:05:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4bf75eba-2a9c-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746551122; x=1747155922; darn=lists.xenproject.org;
        h=cc:to:subject:from:content-language:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pDa0D1+aR8Ko4O2Nqip7CmD95+rrrCXpgxd1DZMq3A4=;
        b=Q7aLYrezoz9adBIuNsYbO4fBLZ/QLqQtDcrefKOTr/tTWUTrcIbmw/2G53GP23eoZu
         0gxrUY3uSFXSzjjC+3Te2kaPSrE2fiknmdZohPPKxX0IpSTnjsoeyLOu2D/hq659S09P
         uPD1iA3PmNOV1D++Db9ts41hKKmu/SnrHhcLa2aRmMGdRX9XF9zqKNBxE233gw/VZNnK
         uo3Bwd2pKW48xkX7JZGOMBvhej+Frbbdzh4vIX6PLDBsj1V/79PY2/4ILblJK0pQkEEt
         zVFtZ6FEuoPxIn5qPRJZaoOi4eObEHx/N/I3npCLRqoG1nGgUdYbvukND34J8cAWlUQW
         XzEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746551122; x=1747155922;
        h=cc:to:subject:from:content-language:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=pDa0D1+aR8Ko4O2Nqip7CmD95+rrrCXpgxd1DZMq3A4=;
        b=xDYwfplDD8lnRF+/49mLTibNFw9j58Z4qp3vbPj/tNFSnWaKjGqxX8UlfwzuB6IaER
         Ulhz0hTziOPbhuWXWZwbauGv3mhVzYc5/jD/HFY1Ir5u1Eh2EhK91GhBAqfek/Ui3hP1
         7cQ0E15izusJOLjPDuqbXQgZdqY9NEI5+GpvRB8PPe0Fjdh672Z4XOYC18H6RkEKqyCE
         jGdSj5FbjM5g42HngQSKo2JbWqkWQtIVg1Y4RO01cLxVSR4CeqwSX9E9gk2E7fCklfvn
         F1w8XSavoDXPHUeChcp+PKqMyp6pJBhGiWa7EHclH8d5JmuwN4dG6P+IvAybxgtRI0dL
         Um4w==
X-Gm-Message-State: AOJu0YxhsMB+oIvpZIkocFygBjJnPjajPmCfWDAbssfFHmYWOk7nigPy
	K5MJ+Mtx/NM6NlIxWJcPFAWNP1bfZX5yVXrF8XYohGEglCRIcj38cRWMMQ==
X-Gm-Gg: ASbGncuwKWn+ttsq840usHD0HaLUc7bSoTkFjgdvktWgoVR5K/J+02SQqn/apwekSB5
	klyYglHVYQuLTK2rIiCZgVhNBYKmBtBQtFs5NaucP/ZznUoQ4PavaWK7FHF85eXDd/cb/9iH0Jq
	9DdpSlS/r/NliKQOqoxj03emwZxyCASE+d2UwQN+w5XCrqwduxhzEoqpStbiqoWlTckH0769sOb
	19SwFpnDnkeVy7YvYkzcyd5oEvf9YLVd0vIgZclU1SKx2zfpR5ji1v33Ylyi4kmZz+SyxUGAp3/
	WsLe04cKPqz79mjTgUhleDLJSs/4xGP94APgON2nlJMPVqAMbCZrmzH3biKkaNXfiQ6DpsLIiJ+
	yf1O9GOjj56tND/NO
X-Google-Smtp-Source: AGHT+IEVjhy5HF3PwgOBcWMoWA8WYUsi+JV7gB6U0aftrO7QSii4fQf5ik3/xNjNQHIxhLop4oXvXg==
X-Received: by 2002:a17:906:794f:b0:ace:388e:d84a with SMTP id a640c23a62f3a-ad1e8e66735mr18410966b.47.1746551109058;
        Tue, 06 May 2025 10:05:09 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------eFso15EVoD0XLSWwdndnFzyY"
Message-ID: <666e3f49-2f92-4828-8897-8579832bcaa2@gmail.com>
Date: Tue, 6 May 2025 19:05:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
From: Oleksii Kurochko 
Subject: Xen 4.21 release schedule proposal
To: Xen-devel 
Cc: Community Manager ,
 "committers @ xenproject . org" 

This is a multi-part message in MIME format.
--------------eFso15EVoD0XLSWwdndnFzyY
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello everyone,

Following the 8-month release cycle, also taking into account that 4.20
has been released 5 March 2025 and the next "good" month for release should
be November according to:
https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html

Here is suggested schedule:

** Proposed option: Wed Nov 12, 2025 **
  (~ +8 months from Xen 4.20 release)

- Last posting date          Fri Aug 08, 2025 (+15 weeks from now)

Patches adding new features are expected to be posted to the mailing
list by this date, although perhaps not in their final version.

- Feature freeze             Fri Aug 29, 2025 (+3 weeks from Last posting date)

Patches adding new features should be committed by this date.
Straightforward bugfixes may continue to be accepted by maintainers.

- Code freeze                Fri Sep 26, 2025 (+4 weeks from Feature freeze)

Bugfixes only.

- Hard code freeze           Fri Oct 24, 2025 (+3 weeks from Code freeze)

Bugfixes for serious bugs (including regressions), and low-risk fixes only.

- Final commits              Fri Nov 07, 2025 (+2 weeks from Hard code freeze)

Branch off staging-4.20.

- Release                    Wed Nov 12, 2025


Please don't hesitate to provide your feedback.

If there are no objections, I plan to update the Wiki page
Xen_Project_X.YY_Release_Notes to make it easier to find our final schedule
( especially for the people who aren't following xen-devel mailing list ).
As an additional benefit, it will also be accessible via SUPPORT.md (in the
wiki athttps://xenbits.xen.org/docs/unstable-staging/support-matrix.html).

Thanks and have a good week.

Best regards,
  Oleksii

--------------eFso15EVoD0XLSWwdndnFzyY
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  

    
  
  
    
Hello everyone,

Following the 8-month release cycle, also taking into account that 4.20
has been released 5 March 2025 and the next "good" month for release should
be November according to:
https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html

Here is suggested schedule:

** Proposed option: Wed Nov 12, 2025 **
 (~ +8 months from Xen 4.20 release)

- Last posting date          Fri Aug 08, 2025 (+15 weeks from now)

Patches adding new features are expected to be posted to the mailing
list by this date, although perhaps not in their final version.

- Feature freeze             Fri Aug 29, 2025 (+3 weeks from Last posting date)

Patches adding new features should be committed by this date.
Straightforward bugfixes may continue to be accepted by maintainers.

- Code freeze                Fri Sep 26, 2025 (+4 weeks from Feature freeze)

Bugfixes only.

- Hard code freeze           Fri Oct 24, 2025 (+3 weeks from Code freeze)

Bugfixes for serious bugs (including regressions), and low-risk fixes only.

- Final commits              Fri Nov 07, 2025 (+2 weeks from Hard code freeze)

Branch off staging-4.20.

- Release                    Wed Nov 12, 2025


Please don't hesitate to provide your feedback.

If there are no objections, I plan to update the Wiki page
Xen_Project_X.YY_Release_Notes to make it easier to find our final schedule
( especially for the people who aren't following xen-devel mailing list ).
As an additional benefit, it will also be accessible via SUPPORT.md (in the
wiki at https://xenbits.xen.org/docs/unstable-staging/support-matrix.html).

Thanks and have a good week.

Best regards,
 Oleksii


    

  


--------------eFso15EVoD0XLSWwdndnFzyY--


From xen-devel-bounces@lists.xenproject.org Tue May 06 17:17:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:17:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977891.1364803 (Exim 4.92)
	(envelope-from )
	id 1uCLux-00050n-RF; Tue, 06 May 2025 17:17:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977891.1364803; Tue, 06 May 2025 17: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 1uCLux-00050g-O9; Tue, 06 May 2025 17:17:19 +0000
Received: by outflank-mailman (input) for mailman id 977891;
 Tue, 06 May 2025 17:17:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLuw-0003I5-Ks
 for xen-devel@lists.xen.org; Tue, 06 May 2025 17:17:18 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f599a061-2a9d-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 19:17:16 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ac2bdea5a38so848336866b.0
 for ; Tue, 06 May 2025 10:17:16 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099ae0d3csm14060072f8f.3.2025.05.06.10.17.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 10:17:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f599a061-2a9d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746551836; x=1747156636; darn=lists.xen.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/K2DAiP61AzFJhh5IKtXeQcwcXvB3Mgch3kqY1N5EYA=;
        b=Q6WeiJFOwe4prEOwL+hN0hREB5Qo1QbMhdvVRCXfPTYQ950+c8lLmpupCCuQOyy+jU
         VdEiAUnI5K/3bO1be1g4avqGrRYf0f+UCaWOSE0xYA30NgCaY1/bHKhpsZB69X9juX+8
         mXZ/04VsESENkDUHICk0mc0xTDGR86EKkeQMA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746551836; x=1747156636;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/K2DAiP61AzFJhh5IKtXeQcwcXvB3Mgch3kqY1N5EYA=;
        b=i16JNMgHgjPFpRyd2sIY5UYbtymOcDGbGFJxkgtW33g6xoi5r0wCWNNYkHXDoUO4It
         YGjNuavBT4AtV7M24WRk2GJDtQsVBfKD35Smvp8QfF+J8l0K6dNHWn/qMqqnv/Kx2/wH
         pLY6Fy0GK9tsQHpCxvMgfEetomykjlvy2iotkMyeZJPcdEb9AhhSCzknTEHwjXVSvMTj
         BMTjh31PdoTYFfB93NbEocKGMox1r1JUqErYkC6WgCAc66nci98noAGmrWlss0M4G1cw
         zzNTWBMW3fEBF8ZbMjefwW66jpzQ0oKpscOnD1SJ0YWqPLm+UD4sDxcdJQaioyxntryB
         zuVA==
X-Gm-Message-State: AOJu0Yyfw3sNCqOjolwlhlHZNHXinVuQbmtMKOYA/FPz4BByyxcb/5Wh
	B/75T0tfxxaAaWRcTW/WZtAxw4TptoPRJjxmD+Yw8d0N+xhwdRoJ1j1un5slc5hrFv3kFpcqURG
	N
X-Gm-Gg: ASbGncteoQ1MFWferdj/QdJ7o5mTysbFsBmvTjCpD/Me/djgpXJp+Fk4r/j8J7x0vH5
	STTdrWdGxZNdSeJa5EcVCQx+BZ6wVI/QS4XhFfzlukBMkoazLsO0dlMZtln6yoV8xvRmVIPHbK2
	CAziiiVhfrtX46bC8GktTWUj3S7BdmRgSeuApo2QSSDJphSH3OEMZ192CI1ovJ4FOzs80KbMLN/
	Pkju9WMjYYDiz5vdx29N3WNX0fNC+R4k9i0VtpADkZsK36xv+8cXSacAgcjWBjl0//vQ37JUxHK
	RwSVgqRwF7A8a+wvqlAflriAc5vZ90T0S8mETNabduuGMwqpnbGQ1lTUcXRrwQJYJZLd6my3S9f
	/9GzY8xfIk2RfnM9j
X-Google-Smtp-Source: AGHT+IE7WvgW137d9MbIxSGvM3QzFwdjuJR34rRXmb+ey1pdkoGyEw8Azw3cGXJuFkjGHKBcOXB2sQ==
X-Received: by 2002:a05:600d:1a:b0:43c:e70d:44f0 with SMTP id 5b1f17b1804b1-441c4a6741amr95750765e9.19.1746551825773;
        Tue, 06 May 2025 10:17:05 -0700 (PDT)
Message-ID: <16cc1b4b-a817-436e-b1fc-09c3a535db08@citrix.com>
Date: Tue, 6 May 2025 18:17:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/4] LivePatch signing support
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Ross Lagerwall 
Cc: Xen-devel , xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , Stefano Stabellini 
References: <20250506143218.1782603-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06/05/2025 6:15 pm, Marek Marczykowski-Górecki wrote:
> On Tue, May 06, 2025 at 03:32:12PM +0100, Ross Lagerwall wrote:
>> Live patch signing support was mentioned as future work in the design
>> document several years ago. This series finally implements support for
>> it since it is a requirement of Secure Boot to prevent loading unsigned
>> code into Xen.
>>
>> Note that this series depends on another patch that has not yet been
>> merged:
>> xen/lib: Export additional sha256 functions
>> https://lists.xenproject.org/archives/html/xen-devel/2025-05/msg00222.html
>>
>> Jennifer Herbert (1):
>>   livepatch: Verify livepatch signatures
>>
>> Kevin Lampis (1):
>>   livepatch: Embed public key in Xen
>>
>> Ross Lagerwall (2):
>>   docs: Introduce live patch signing
>>   crypto: Add RSA support
> Patches 1 and 4 seems to be lost...

Yes, we're working on that.  (Corporate email fun)

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 06 17:21:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:21:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977902.1364812 (Exim 4.92)
	(envelope-from )
	id 1uCLzI-00076l-AC; Tue, 06 May 2025 17:21:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977902.1364812; Tue, 06 May 2025 17:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCLzI-00076e-7f; Tue, 06 May 2025 17:21:48 +0000
Received: by outflank-mailman (input) for mailman id 977902;
 Tue, 06 May 2025 17:21:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCLuv-0003pq-IX
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 17:17:17 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f5d6c0fa-2a9d-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 19:17:17 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ac25520a289so1006010666b.3
 for ; Tue, 06 May 2025 10:17:17 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099ae0d3csm14060072f8f.3.2025.05.06.10.17.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 10:17:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f5d6c0fa-2a9d-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746551837; x=1747156637; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/K2DAiP61AzFJhh5IKtXeQcwcXvB3Mgch3kqY1N5EYA=;
        b=b0IW4MP8vCmEQb8qb2WM344gJh6Ihu2Hfvn8XXEAoK8Ujce8KyCdaNdVjlCKWLKifZ
         uTOeCXuI1oppVUP0LopAv3PvjmPFjgH1Q48rl4JvJdMYANXNbr+RQbh16GX2Umwa2Pac
         vxRmrOn4Y6L2xq5wF5szwE1D6WhINvgYTitDQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746551837; x=1747156637;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/K2DAiP61AzFJhh5IKtXeQcwcXvB3Mgch3kqY1N5EYA=;
        b=YBcAlSgq72fWyEUPO3U61v2DEZhpnse8Fm194K5q39p4r/TKhDPnEJO+rHx4Ntn++7
         RdhQjeQQuNPwDMwciLul68QNt7ezgCOwRtuiT2q74GvC/N2mjCr0+fxY9TyMwcMV4BdK
         20HBZ1X8w7aa7Q5aK0EyNa9T1FmCSi9SmO76I5KgmkTN5dqUkaB7qxdWX4G9WqgyH1S6
         4tKYYsh1ixAMNyNSpJ+9+g5tMh8dXciVxG9HfS2nr7E8ysxpxvaRWHLjl1dWm0R1OMgv
         dIi1gl7eFLbBNX93P76NyL9sKce38m9fhZGdB57tYukmFhEocId0VltinvbnYcVh6CGl
         8eSA==
X-Forwarded-Encrypted: i=1; AJvYcCU+7U/D/QHq8YuefFpfJtwxZc6uugFz3BIrMsw6FtYKdNeZf8JRQ1h/xmODt5uXQ8SUf/aLzM37WSU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxf+H+E93w+wBV44ImomAcX8RLK7S7cLNgSC21l2b9lIQWtnABu
	U/FBhSQ2jfRiTq/C+Li1pHpxFjVLoB2ogkkJm/PUhKogUzZloE/CPPFr+WB1+ovDHOy+cHEtXlp
	3
X-Gm-Gg: ASbGncu8GLKjL5wX/pumImh+OEXml0LhTLy6gVRtbIPhHVGiiPsQpKw+gz9PCgrDf8v
	Q97HmJWANNacreiEsa0TsZKR9jlXlX4rVHVyavrvQwZfzbtUUidWmx8iNSxUJ8rijsiRlaHQrrr
	6qSRmH4y98bwVMecTZUdKnnMEjV/ZpFZ/Io469AWgOMzbIll6npjXRt6M6x/NKZwaLu3/YVCLqJ
	I9Guw4AvbsEOBuhegPDx0cTlPKahfjXnsLaEkw76hvS1DLtGMDjE3KDCFkqrKBf/ROiVFbhY5Dc
	J5lJF3mGc0S9Y7oe3lHWPfHewLQM4NatJi4rNHkAbG8mmCC30QVBJZ/mnvHQ4dcBz/tKtEBGfnY
	nBNenNg==
X-Google-Smtp-Source: AGHT+IE7WvgW137d9MbIxSGvM3QzFwdjuJR34rRXmb+ey1pdkoGyEw8Azw3cGXJuFkjGHKBcOXB2sQ==
X-Received: by 2002:a05:600d:1a:b0:43c:e70d:44f0 with SMTP id 5b1f17b1804b1-441c4a6741amr95750765e9.19.1746551825773;
        Tue, 06 May 2025 10:17:05 -0700 (PDT)
Message-ID: <16cc1b4b-a817-436e-b1fc-09c3a535db08@citrix.com>
Date: Tue, 6 May 2025 18:17:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/4] LivePatch signing support
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Ross Lagerwall 
Cc: Xen-devel , xen-devel@lists.xenproject.org,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , Stefano Stabellini 
References: <20250506143218.1782603-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06/05/2025 6:15 pm, Marek Marczykowski-Górecki wrote:
> On Tue, May 06, 2025 at 03:32:12PM +0100, Ross Lagerwall wrote:
>> Live patch signing support was mentioned as future work in the design
>> document several years ago. This series finally implements support for
>> it since it is a requirement of Secure Boot to prevent loading unsigned
>> code into Xen.
>>
>> Note that this series depends on another patch that has not yet been
>> merged:
>> xen/lib: Export additional sha256 functions
>> https://lists.xenproject.org/archives/html/xen-devel/2025-05/msg00222.html
>>
>> Jennifer Herbert (1):
>>   livepatch: Verify livepatch signatures
>>
>> Kevin Lampis (1):
>>   livepatch: Embed public key in Xen
>>
>> Ross Lagerwall (2):
>>   docs: Introduce live patch signing
>>   crypto: Add RSA support
> Patches 1 and 4 seems to be lost...

Yes, we're working on that.  (Corporate email fun)

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 06 17:51:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 17:51:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977919.1364824 (Exim 4.92)
	(envelope-from )
	id 1uCMS9-0005H0-Ip; Tue, 06 May 2025 17:51:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977919.1364824; Tue, 06 May 2025 17: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 1uCMS9-0005Gt-E2; Tue, 06 May 2025 17:51:37 +0000
Received: by outflank-mailman (input) for mailman id 977919;
 Tue, 06 May 2025 17:51:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCMS7-0005Fa-SF
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 17:51:35 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bfea1d07-2aa2-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 19:51:34 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ac3eb3fdd2eso274843966b.0
 for ; Tue, 06 May 2025 10:51:34 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad1894c032fsm734079666b.123.2025.05.06.10.51.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 10: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" 
X-Inumbo-ID: bfea1d07-2aa2-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746553893; x=1747158693; darn=lists.xenproject.org;
        h=content-transfer-encoding:subject:from:cc:to:content-language
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nAWYLbzn1+723Y94D+eOLInpPW/dsArCy8vAsFJa6uI=;
        b=hPpvHAhn1/dR95qpFClMuEVwZEbepqJBwpE68pCwJ20V00cAtMS3btUxGahb2LzThZ
         565hv45hBTgUg9Ll1ZmBt1IDmQ38Sim2LbZhJiDILqtRK2M56Czmk30odCCrN+0qjueb
         MeLzqvhTRvDwp+Cjw8bgepJo24r/9J4RoGnAbw0gH01y/qdkVXVi2FbS2hFcZ7N1InMJ
         flRnXswvnqtlBqN2D/tbEMjveSCFLVaLZ8o4Oj1dUETfOPCIsF+X0F1Gl+2Bk2T+abPM
         gDH/vZj6JHi/0+LZLlUTg6kDRyOV3ABHhzmA1hHEzEhLd+dy3Iffc5KVTzTu9k/1cb+G
         eV0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746553893; x=1747158693;
        h=content-transfer-encoding:subject:from:cc:to:content-language
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=nAWYLbzn1+723Y94D+eOLInpPW/dsArCy8vAsFJa6uI=;
        b=lh2XTqbMUiEUN8AqxqacPdeW6g2BEdf2K527+FpaygP7M+mliNMEgADyBoMEmYye6C
         gCxkMYJKU8d0iXsRQrP1q6UTB9+Ska1J5LjftsSwjP5ch/sGzxOePetzYwNYpmcDTJ6j
         65WPkhl/ESbJUMQkh1tT/41TLkcWBn71ASWz6RY+Gxb4jwWqIo9D2Y6iLIPcG4qIHWhE
         KQ9q3CNQd+kilGf3Q6m+SAhgtslzFCGRhmCu0vEw4CAr0jKfRF+pHygUcmE5o7nLJPIk
         l17XO4q/T2aJCeREk+hdzMR/TNFk1yuXRnfSZfu5TSpgw1k45R24OllgIGTAzlaOVaVu
         ++Ag==
X-Gm-Message-State: AOJu0YxngixCvoxAs9LTIGt1amCRo2Km9jqBbJQAIwnfV2p6ucUCWRnO
	ypFwbi5PVxlVEVS8XihpAcoO5xhUh/A2lPc3MoKEGUzcuV+23Eynml9kPp+S
X-Gm-Gg: ASbGncuCt2ayvi4cn6gQmRIoltkCdjLm5tT4wGfTBKmnxZuMmDweKi9fBzrUKoTOjJS
	VlK8ATpR7n5EOeQp7Uune2xidvB7LYe5sTZnfwWvOgbpqTk2JAJPFw8S4cr9fec/5OVlnidfCMw
	bWcE2asILmrxvgMbQJfjx/cKuGZC6ktMrjreSHAhZgtgck0Rbl0reS4USFBriZLO1qOHgZ3xX2m
	XpwycMzVGr8d9NDfk8ze1k3opm0IXWeifRklWXsuAOBYg0cIkKzjg1RdW4ppRyV1F2vLrmSjVbN
	L2DUtQX4YYFwb40+5KU6E2ljZdbXcIY/EgpZEl9gSePBrtjN9SdsPI3EmXnbDVX+U9oq9mCrjA+
	T3rW2dx64HEmYoQo4
X-Google-Smtp-Source: AGHT+IEY+d2D7a/fSHoybyiGHQaCY/PPhhU4ivOIpW2b428UWczSiZI904ofZualI43vAI2NMTDL7g==
X-Received: by 2002:a17:907:94c7:b0:ace:6703:3cd5 with SMTP id a640c23a62f3a-ad1e8bc9451mr36443666b.19.1746553893145;
        Tue, 06 May 2025 10:51:33 -0700 (PDT)
Message-ID: <26aa7922-d5d4-4c26-bab5-cfe298a32f0f@gmail.com>
Date: Tue, 6 May 2025 19:51:31 +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.21 Development Update [March-April]
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello everyone,

This email only tracks big items for xen.git tree. Please reply for 
items you
would like to see in 4.21 so that people have an idea what is going on and
prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

Suggested timeline could be found here:
https://lore.kernel.org/xen-devel/666e3f49-2f92-4828-8897-8579832bcaa2@gmail.com/T/#u

The following items ( the links for them could be found int the list below )
were moved to completed:
   [since 4.20 relese - May 6]:
     * Hypervisor:
       - Move parts of Arm's Dom0less to common code
       - remove libxenctrl usage from xenstored
     * Arm:
       - Enable early bootup of Armv8-R AArch32 systems
     * x86:
       - x86/HVM: emulation (MMIO) improvements
     * RISC-V:
       - RISC-V some preinit calls.
       - Fixes for UBSAN & GCOV support for RISC-V.

Some new items added since 4.20 release:
  * Hypervisor:
    - tools: remove qemu-traditional
    - Physical address hypercall ABI ("HVMv2")
    - xen: Untangle mm.h
    - xen: introduce CONFIG_SYSCTL
    - Add support for exact-node memory claims
    - Several CI cleanups and improvements, plus yet another new runner
  * x86:
    - x86/EFI: prevent write-execute sections
    - x86: Trenchboot Secure Launch DRTM (Xen)
    - Hyperlaunch device tree for dom0 (v6)
    - amd-cppc CPU Performance Scaling Driver (v4)
    - Hyperlaunch domain builder
    - kexec: add kexec support to Mini-OS
    - xen: cache control improvements (should be moved to "Hypervisor"?)
    - x86: generate xen.efi image with no write-execute sections
    - x86/asm: cleanups after toolchain baseline upgrade
  * Arm:
    - Add support for R-Car Gen4 PCI host controller (v4)
    - FF-A VM to VM support (v5)
    - First chunk for Arm R82 and MPU support (v4)
    - ARM split hardware and control domains (v5)
    - MPU mm subsistem skeleton
  * RISC-V:
    - riscv: introduce basic UART support and interrupts for hypervisor 
mode

* Full list of items : *

= Projects =

== Hypervisor ==

* tools: remove qemu-traditional
   - Juergen Gross 
   - 
https://lore.kernel.org/xen-devel/20250429110636.30518-4-jgross@suse.com/

* Physical address hypercall ABI ("HVMv2")
   - Teddy Astie
   - 
https://lore.kernel.org/xen-devel/cover.1744981654.git.teddy.astie@vates.tech/

* xen: Untangle mm.h
   -  Andrew Cooper
   - 
https://lore.kernel.org/xen-devel/20250312174513.4075066-1-andrew.cooper3@citrix.com/

* xen: introduce CONFIG_SYSCTL (v3)
   -  Penny Zheng
   - 
https://lore.kernel.org/xen-devel/20250421073723.3863060-1-Penny.Zheng@amd.com/
   - https://patchew.org/Xen/20250421073723.3863060-1-Penny.Zheng@amd.com/

* Add support for exact-node memory claims
   -  Alejandro Vallejo
   - 
https://lore.kernel.org/xen-devel/20250314172502.53498-1-alejandro.vallejo@cloud.com/
   - 
https://patchew.org/Xen/20250314172502.53498-1-alejandro.vallejo@cloud.com/

* Several CI cleanups and improvements, plus yet another new runner
   - Marek Marczykowski-Górecki
   - 
https://lore.kernel.org/xen-devel/cover.7da1777882774486a13e6f39ff4a2096f6b7901e.1744028549.git-series.marmarek@invisiblethingslab.com/
   - 
https://patchew.org/Xen/cover.7da1777882774486a13e6f39ff4a2096f6b7901e.1744028549.git-series.marmarek@invisiblethingslab.com/

* xen/console: cleanup console input switch logic
   - Denis Mukhin
   - 
https://lore.kernel.org/xen-devel/20250331230508.440198-1-dmukhin@ford.com/

*  Remove the directmap (v5)
   -  Alejandro Vallejo
   - 
https://lore.kernel.org/xen-devel/20250108151822.16030-1-alejandro.vallejo@cloud.com/

*  automation: Refresh the remaining Debian containers (v2)
   -  Javi Merino
   - 
https://lore.kernel.org/xen-devel/cover.1730743077.git.javi.merino@cloud.com/T/#m5d9acb7cf5db3c2be3d6527de14b69b07812314e

*  GRUB: Supporting Secure Boot of xen.gz (v1)
   -  Ross Lagerwall
   - 
https://patchew.org/Xen/20240313150748.791236-1-ross.lagerwall@citrix.com/

*  MSI-X support with qemu in stubdomain, and other related changes (v8)
   -  Marek Marczykowski-Górecki
   - 
https://lore.kernel.org/xen-devel/cover.33fb4385b7dd6c53bda4acf0a9e91748b3d7b1f7.1715313192.git-series.marmarek@invisiblethingslab.com/
   -  Only automation patch left to be reviewed/merged.

*  [RFC] Introduce xenbindgen to autogen hypercall structs (v1)
   -  Alejandro Vallejo
   - 
https://patchew.org/Xen/20241115115200.2824-1-alejandro.vallejo@cloud.com/

*  Introduce NS8250 UART emulator (v2)
   -  Denis Mukhin
   - 
https://patchew.org/Xen/20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com/

=== x86 ===

* x86/EFI: prevent write-execute sections
   - Roger Pau Monne 
   - 
https://lore.kernel.org/xen-devel/20250401130840.72119-1-roger.pau@citrix.com/

* x86: Trenchboot Secure Launch DRTM (Xen)
   - Sergii Dmytruk
   - https://patchew.org/Xen/cover.1745172094.git.sergii.dmytruk@3mdeb.com/
   - 
https://lore.kernel.org/xen-devel/cover.1745172094.git.sergii.dmytruk@3mdeb.com/

* Hyperlaunch device tree for dom0 (v6)
   - Alejandro Vallejo
   - https://patchew.org/Xen/20250429123629.20839-1-agarciav@amd.com/
   - 
https://lore.kernel.org/xen-devel/20250429123629.20839-1-agarciav@amd.com/

* amd-cppc CPU Performance Scaling Driver (v4)
   - Penny Zheng
   - 
https://lore.kernel.org/xen-devel/20250414074056.3696888-1-Penny.Zheng@amd.com/
   - https://patchew.org/Xen/20250414074056.3696888-1-Penny.Zheng@amd.com/

* Hyperlaunch domain builder
   - Daniel P. Smith
   - 
https://patchew.org/Xen/20250419220820.4234-1-dpsmith@apertussolutions.com/

* kexec: add kexec support to Mini-OS
   - Juergen Gross 
   - 
https://lore.kernel.org/xen-devel/20250321092451.17309-1-jgross@suse.com/

* xen: cache control improvements
   - Roger Pau Monne
   - 
https://lore.kernel.org/xen-devel/20250506083148.34963-1-roger.pau@citrix.com/

* x86: generate xen.efi image with no write-execute sections
   - Roger Pau Monne
   - 
https://lore.kernel.org/xen-devel/20250318173547.59475-1-roger.pau@citrix.com/

* x86/asm: cleanups after toolchain baseline upgrade
   - Denis Mukhin
   - 
https://lore.kernel.org/xen-devel/20250403182250.3329498-1-dmukhin@ford.com/

*  Expose consistent topology to guests (v7)
   -  Alejandro Vallejo
   - 
https://patchew.org/Xen/20241021154600.11745-1-alejandro.vallejo@cloud.com/

*  Boot modules for Hyperlaunch (v9)
   -  Daniel P. Smith
   - 
https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolutions.com/

*  Address Space Isolation FPU preparations (v2->v3)
   -  Alejandro Vallejo
   - 
https://patchew.org/Xen/20250110132823.24348-1-alejandro.vallejo@cloud.com/

*  x86/alternatives: Adjust all insn-relative fields (v2)
   -  Andrew Cooper
   - 
https://lore.kernel.org/xen-devel/20241002152725.1841575-1-andrew.cooper3@citrix.com/T/#mac2deaea7e02a343210d61887486433d946ad129

*  x86emul: misc additions (v7)
   -  Jan Beulich
   - https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.com/

*  x86: support AVX10 (v3)
   -  Jan Beulich
   - https://patchew.org/Xen/516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com/

*  VT-d: SATC handling; ATS: tidying (v2)
   -  Jan Beulich
   - https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.com/

*  x86: parallelize AP bring-up during boot (v1)
   -  Krystian Hebel
   - 
https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/

*  x86/spec-ctrl: IBPB improvements (v4)
   -  Jan Beulich
   - https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.com/

*  Move some boot code from assembly to C (v2)
   -  Frediano Ziglio
   - 
https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cloud.com/

*  Hyperlaunch device tree for dom0 (v2 -> v6)
   -  Alejandro Vallejo
   - https://patchew.org/Xen/20250429123629.20839-1-agarciav@amd.com/

*  x86: memcpy() / memset() (non-)ERMS flavors plus fallout (v4)
   -  Jan Beulich
   - https://patchew.org/Xen/14b65231-b83b-43fb-bbcf-dec5c07d285b@suse.com/

*  amd-pstate CPU Performance Scaling Driver (v1)
   -  Penny Zheng
   - https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.com/

* x86/efi: Fix booting when NX is disabled (v1)
   - Andrew Cooper
   - 
https://patchew.org/Xen/20240722101838.3946983-1-andrew.cooper3@citrix.com/

=== ARM ===

* Add support for R-Car Gen4 PCI host controller (v4)
   - Mykyta Poturai
   - 
https://lore.kernel.org/xen-devel/cover.1745402473.git.mykyta_poturai@epam.com/
   - 
https://patchew.org/Xen/cover.1745402473.git.mykyta._5Fpoturai@epam.com/

* FF-A VM to VM support (v5)
   - Bertrand Marquis 
   - 
https://lore.kernel.org/xen-devel/cover.1744787720.git.bertrand.marquis@arm.com/
   - https://patchew.org/Xen/cover.1744787720.git.bertrand.marquis@arm.com/

* First chunk for Arm R82 and MPU support (v4)
   - Luca Fancellu
   - 
https://lore.kernel.org/xen-devel/20250429152057.2380536-1-luca.fancellu@arm.com/
   - https://patchew.org/Xen/20250429152057.2380536-1-luca.fancellu@arm.com/

* ARM split hardware and control domains (v5)
   - Jason Andryuk
   - 
https://lore.kernel.org/xen-devel/20250416212911.410946-1-jason.andryuk@amd.com/
   - https://patchew.org/Xen/20250416212911.410946-1-jason.andryuk@amd.com/

* MPU mm subsistem skeleton
   - Luca Fancellu
   - 
https://lore.kernel.org/xen-devel/20250312135258.1815706-1-luca.fancellu@arm.com/
   - https://patchew.org/Xen/20250312135258.1815706-1-luca.fancellu@arm.com/

*  Add Virtio-PCI for dom0less on ARM (v1)
   -  Edgar E. Iglesias
   - 
https://lore.kernel.org/xen-devel/20240924162359.1390487-1-edgar.iglesias@gmail.com/T/#mfa148991b9408f223a079d4cef610244d5b04c2b
   - 
https://patchew.org/Xen/20240924162359.1390487-1-edgar.iglesias@gmail.com/

*  PCI devices passthrough on Arm, part 3 (v16->v20)
   -  Stewart Hildebrand
   - 
https://patchew.org/Xen/20250418185840.335816-1-stewart.hildebrand@amd.com/
   - 
https://lore.kernel.org/xen-devel/20250418185840.335816-1-stewart.hildebrand@amd.com/
   -  last patch waiting to be merged?

*  DOMCTL-based guest magic region allocation for 11 domUs (v4)
   -  Henry Wang
   - https://patchew.org/Xen/20240409045357.236802-1-xin.wang2@amd.com/

=== RISCV ===

* riscv: introduce basic UART support and interrupts for hypervisor mode 
(v2)
   -  Oleksii Kurochko
   - 
https://lore.kernel.org/xen-devel/cover.1746530883.git.oleksii.kurochko@gmail.com/T/#m9f3affc0f8ded50ab26c0842613b553b56bce782

=== PPC ===

*  Early Boot Allocation on Power (v5)
   -  Shawn Anastasio
   - 
https://lore.kernel.org/xen-devel/cover.1727388925.git.sanastasio@raptorengineering.com/T/#m8cac91a93b56a359fa2d5f08596c4be61dca290d
   - 
https://patchew.org/Xen/cover.1727388925.git.sanastasio@raptorengineering.com/

== Completed ==

=== Hypervisor ===

*  remove libxenctrl usage from xenstored (v8)
   -  Juergen Gross
   - 
https://lore.kernel.org/xen-devel/20250204113407.16839-1-jgross@suse.com/

* xen/config.h: Move BITS_PER_* definitions from asm/config.h to 
xen/config.h
   - Oleksii Kurochko
   - 
https://lore.kernel.org/xen-devel/6b21fb046cf1c8ca760f5ad72fa3cc13b59c4069.1743092485.git.oleksii.kurochko@gmail.com/

* Move parts of Arm's Dom0less to common code
   -  Oleksii Kurochko
   - 
https://patchew.org/Xen/cover.1746468003.git.oleksii.kurochko@gmail.com/
   - 
https://lore.kernel.org/xen-devel/cover.1746468003.git.oleksii.kurochko@gmail.com/T/#t

=== x86 ===

*  x86/HVM: emulation (MMIO) improvements (v3)
   -  Jan Beulich
   - https://patchew.org/Xen/729f7896-55b7-4b5b-a7e9-6eb0420e0b14@suse.com/

=== ARM ===
* Enable early bootup of Armv8-R AArch32 systems
   - Ayan Kumar Halder
   - 
https://lore.kernel.org/xen-devel/20250414164514.588373-1-ayan.kumar.halder@amd.com/
   - 
https://patchew.org/Xen/20250414164514.588373-1-ayan.kumar.halder@amd.com/

=== RISC-V ===

* RISC-V some preinit calls:
   -  Oleksii Kurochko
   - 
https://lore.kernel.org/xen-devel/4ddde60347edf6740fbc69b5739d099616f5b5ff.1743165791.git.oleksii.kurochko@gmail.com/

* Fixes for UBSAN & GCOV support for RISC-V:
   -  Oleksii Kurochko
   - 
https://lore.kernel.org/xen-devel/9fbb5e1389b84bed2e95f99e4c383d0215c7a524.1744889185.git.oleksii.kurochko@gmail.com/

Have a good week!

Best regards,
  Oleksii



From xen-devel-bounces@lists.xenproject.org Tue May 06 18:27:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 18:27:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977942.1364852 (Exim 4.92)
	(envelope-from )
	id 1uCN0V-00038x-L9; Tue, 06 May 2025 18:27:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977942.1364852; Tue, 06 May 2025 18: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 1uCN0V-00038o-Hk; Tue, 06 May 2025 18:27:07 +0000
Received: by outflank-mailman (input) for mailman id 977942;
 Tue, 06 May 2025 18:27:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCN0U-0002gj-N4
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 18:27:06 +0000
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com
 [2a00:1450:4864:20::12b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b1d1047c-2aa7-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 20:26:58 +0200 (CEST)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-54addb5a139so6873808e87.0
 for ; Tue, 06 May 2025 11:26:58 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-320290171e8sm21858681fa.27.2025.05.06.11.26.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 11:26: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" 
X-Inumbo-ID: b1d1047c-2aa7-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746556017; x=1747160817; 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;
        bh=ZTjmb4CVzk7evFGnM7dnHZhUU6iWaPb1DdyvIUz9ueY=;
        b=Zvx7wUL6B/o9kYPFYnRC/yD5YkDV9nnlCWMPnMaYVUXdZF1o8OqC0ToYB/DLM5Y1v3
         buTrIQ66QWvxI0EnW1x2/4MO/9XDQIgsflS4tKGY+5Q0imxUKURL4PZd2gzd2D/YtXfK
         9lQHIkepXKlIhBkx+JIJeArakDNGamXf/b9DoRQU2O4lxB0E6vZgX57ambR4Wd0nz6lM
         /iWlb11WZ/ZZ9kEZhG58WmJpQbwU0oNeDPaSGfV4hmt+PHgKnzgPaBhWc0qvC1rqFMAx
         muAg/q9cO9lvx8KfLGDyJ0wG7d/D/egtbsIeYG5TEcekXnIY77C1JCiraCAZvBf/CYrz
         VaaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746556017; x=1747160817;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ZTjmb4CVzk7evFGnM7dnHZhUU6iWaPb1DdyvIUz9ueY=;
        b=RS7g2Pu8twwhTJkmzPAUjq7sp8iIcH3oXxirgfuYMAhKsY3L2d7ajR0a03GQuYqJZu
         avK5XEjwHHINeVTeeV+fbbwUbeeSWRwRXmnmL9l3UuJvvwxNcM6WprBpKAMI+MEeklWZ
         z5o77ESXBU0e6dso0w6P84+F8abEhOj1DspFhh2Yvc+0nH0Y5OxDKB/rdjq1oeHm0S6o
         dnXtGjbllgAuiQCSylavrR5D7YSkPoEUUDAX7KXMxAtmeAhqwHMlyqwflOB4N6Cuy6vi
         caaGGeGKVAuxN9LclTxe9EXzRO0Dh47fOlzzFhmm8/jqLKeCvW/7rwytthBPMpiFQuFF
         CmIw==
X-Forwarded-Encrypted: i=1; AJvYcCV31eEFSf1l8DdavIqnsKu1hBa2A+cj1dZwl5T7dC5fs1DNZchJXO3bs2+jLZy6zweH9R2pSmtMWb0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YweQV+ORx0imsVn5UG+CE59bZvbNCj1JsJfX6JpaNlJGJbRpjNO
	WLXb/w0RRIrKW4obtPMEqECLROMK0sCx9I5UAXMGlmwjmTvf6JbZ
X-Gm-Gg: ASbGncuaVAAoVbLvvG782E8xoHw96c5S0Lwu2AdrYrqOnVgQ0nlW10c4wmOvgpGEPdA
	+CdgHU5/rutdQpt/AqsGGYPF/sCpZaOOgZwjrXVxFmtvjADNdXzOeJoTkJ5nLWzO3dNkx/8UKR/
	Imfcj6YsPzWuxhQC5Q6sgVXrRDTf8dMkTomLJJeIHYBsarQY/MIqcp2cX1LhgXrAWpYpFS3aL8L
	Y7MQwfDCYznNenW6iz5nruUETonOiBSBMo78TX5+Uit9DJ3U9gpgEdf5PW4NVm41ngaTAVK1qRQ
	Wnu1PN5WbVV9qt/fSosN9R2yGu7KnvrcqFJ7dQEFRV70Mp+5/9Stan23gNZHPEv0601xIsdVCk6
	yPARZ6lTYDtvY
X-Google-Smtp-Source: AGHT+IG0QNxm2H52AYImFQ9/85BOn3rOqRXdlPtH5VEXNMZVVE3v32Bclj57hFQ5Eqpo6lHWEzQxZQ==
X-Received: by 2002:a05:6512:ba8:b0:54a:f757:f8b3 with SMTP id 2adb3069b0e04-54fb92a6b1fmr220316e87.0.1746556017245;
        Tue, 06 May 2025 11:26:57 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	sstabellini@kernel.org,
	anthony@xenproject.org,
	paul@xen.org,
	alex.pentagrid@gmail.com,
	peter.maydell@linaro.org,
	edgar.iglesias@amd.com,
	xen-devel@lists.xenproject.org
Subject: [PULL v1 0/2] xen: mapcache: Fixes
Date: Tue,  6 May 2025 20:26:45 +0200
Message-ID: <20250506182647.302961-1-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

The following changes since commit a9e0c9c0f14e19d23443ac24c8080b4708d2eab8:

  Merge tag 'pull-9p-20250505' of https://github.com/cschoenebeck/qemu into staging (2025-05-05 11:26:59 -0400)

are available in the Git repository at:

  https://gitlab.com/edgar.iglesias/qemu.git tags/edgar/xen-queue-2025-05-06.for-upstream

for you to fetch changes up to 88fb705600a3b612c571efc9f1a6aed923a18dcc:

  xen: mapcache: Split mapcache_grants by ro and rw (2025-05-06 18:39:44 +0200)

----------------------------------------------------------------
Edgars Xen queue

----------------------------------------------------------------
Aleksandr Partanen (1):
      xen: mapcache: Fix finding matching entry

Edgar E. Iglesias (1):
      xen: mapcache: Split mapcache_grants by ro and rw

 hw/xen/xen-mapcache.c | 32 ++++++++++++++++++++++----------
 1 file changed, 22 insertions(+), 10 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 18:27:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 18:27:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977941.1364843 (Exim 4.92)
	(envelope-from )
	id 1uCN0U-0002ui-ER; Tue, 06 May 2025 18:27:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977941.1364843; Tue, 06 May 2025 18:27:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCN0U-0002ub-BE; Tue, 06 May 2025 18:27:06 +0000
Received: by outflank-mailman (input) for mailman id 977941;
 Tue, 06 May 2025 18:27:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCN0U-0002uP-1z
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 18:27:06 +0000
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com
 [2a00:1450:4864:20::235])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b435cadc-2aa7-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 20:27:02 +0200 (CEST)
Received: by mail-lj1-x235.google.com with SMTP id
 38308e7fff4ca-30bfb6ab47cso53911181fa.3
 for ; Tue, 06 May 2025 11:27:02 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3202a89ef11sm20952331fa.81.2025.05.06.11.26.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 11:26:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b435cadc-2aa7-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746556021; x=1747160821; 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;
        bh=zpP4TBaydimBJ+yCxRqJxX0SmD5odScGLmy0sP+rMAs=;
        b=Ag7+s0ebFEaVMcK5P8qDlVyz8AAvT0By8pM04tho9fcqwOrrNWhwBji+VmoVs34nxy
         /uDyJeDh6v26QYRYLfWqeXaNx+eKbvqm8NC1+6apkOzd9Xlqb0JX4cdThTDrDEZ2ny/g
         b1JtcLu4hxln83ltTClQqw49oaiz64BolfADFeRb9vfzbOXGpo8mjW6wrp9t1ja4ey00
         BOxs4CbUnnhMoQSxAe5dNBExrxqfL9Ifpva6gB90AHaMLZgd320mvODRvc48D4dyFanb
         UsvZgOKNqJZe2dWb5mql4zTFuf5q+P2raX0YevnjHiTtcA+/E9lrOGc9RmA1HT9enxju
         2Ipg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746556021; x=1747160821;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=zpP4TBaydimBJ+yCxRqJxX0SmD5odScGLmy0sP+rMAs=;
        b=MhBAnhFqC7EK3sys+Cb7IN9nBESHchjfWNhYVrIGCUILL2K58G+isN7X1iJSoGYRJC
         BhY19ODBOxN6mVVF8owtR0eoBnQtq8UKL+PRkAni7U6Lx7CkZ1hFj+yPzRqYaSbJmqQE
         CkygsRhlIXQIIqOGAInr9iqM7WgjREoRoU89Qk++0zrb96TlSy1rQk/X76YpUfN0Xtdz
         bHZ9JfCd/7ZiaUwk00cPk5CJy7gk80mu8F9cr+SmBsmmLeAbp6EIj3DR++7PUstILPBx
         EeXFK2dz32QbnQdt3+tbD/GJTq6ZR+n2Sh0LyDdSc3NTxMgdxuuR7wYEzyBQt6frjbQh
         o0Lg==
X-Forwarded-Encrypted: i=1; AJvYcCVGN99Hac3kg8pyb3M5t4D9mp90Nq4EcFrOsbMKAjpTya/ZFmHSbKStmkznuyysZogjKMP4hql0x6U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx/LHK1idLRSmxYZldWDHExh8HMVG3zwqPCllkOqwlg4un9c/e0
	i5d5T7T3UYGAdEXqEYZsBuV/ZqPRUXNQzEGEpSXOhQ92VzYLVZOz
X-Gm-Gg: ASbGncs/598SLGG5UkAu+kzLn/0HICdL8n4B6SVJOER3Uq11yGfSdDfTgDSq/T98uS+
	5cNC+F4IC8+Pt2C0QAHN3ANf3T5A6xQngdfwICKrjdL18fh62GVFGXHeaxx+x0su4ZaIy5Kk4Iu
	PH/QADg0wYQg7gg8EPGqYFNzoMBM6sk1I8TCx9DWb9W6r1AIc2U131zrAZ59kxN+nrw25jevGGS
	UPj3TFrnkHJ9ha3sTniCiIb1hteliFdNBF8+P1oDHvxIJ4zDUTVXdHSND80BQdmeaaLiFwtKXEw
	tZigkVMcxT3BJUtudPtoFaooLmWkBaycjec5Jyk9iTJjqJ1rn9zwvEm0CDEcqeaQV15QFclzS0e
	IaJXxQ0nxrmZp7Rpd34Vm2zA=
X-Google-Smtp-Source: AGHT+IHBa9ho1ThyDkNxpwI0/3LxpQeg41uCA79/UXOH2n/099VZv3LAbpb5LyXBZ2fI612cdcWfAw==
X-Received: by 2002:a2e:be1a:0:b0:30b:ed5a:6f3c with SMTP id 38308e7fff4ca-326ad19a978mr314741fa.10.1746556021307;
        Tue, 06 May 2025 11:27:01 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	sstabellini@kernel.org,
	anthony@xenproject.org,
	paul@xen.org,
	alex.pentagrid@gmail.com,
	peter.maydell@linaro.org,
	edgar.iglesias@amd.com,
	xen-devel@lists.xenproject.org,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	"Edgar E. Iglesias" 
Subject: [PULL v1 2/2] xen: mapcache: Split mapcache_grants by ro and rw
Date: Tue,  6 May 2025 20:26:47 +0200
Message-ID: <20250506182647.302961-3-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250506182647.302961-1-edgar.iglesias@gmail.com>
References: <20250506182647.302961-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Today, we don't track write-abiliy in the cache, if a user
requests a readable mapping followed by a writeable mapping
on the same page, the second lookup will incorrectly hit
the readable entry.

Split mapcache_grants by ro and rw access. Grants will now
have separate ways in the cache depending on writeability.

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Edgar E. Iglesias 
---
 hw/xen/xen-mapcache.c | 26 +++++++++++++++++++-------
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c
index 2c8f861fdb..e31d379702 100644
--- a/hw/xen/xen-mapcache.c
+++ b/hw/xen/xen-mapcache.c
@@ -75,7 +75,8 @@ typedef struct MapCache {
 } MapCache;
 
 static MapCache *mapcache;
-static MapCache *mapcache_grants;
+static MapCache *mapcache_grants_ro;
+static MapCache *mapcache_grants_rw;
 static xengnttab_handle *xen_region_gnttabdev;
 
 static inline void mapcache_lock(MapCache *mc)
@@ -176,9 +177,12 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque)
      * Grant mappings must use XC_PAGE_SIZE granularity since we can't
      * map anything beyond the number of pages granted to us.
      */
-    mapcache_grants = xen_map_cache_init_single(f, opaque,
-                                                XC_PAGE_SHIFT,
-                                                max_mcache_size);
+    mapcache_grants_ro = xen_map_cache_init_single(f, opaque,
+                                                   XC_PAGE_SHIFT,
+                                                   max_mcache_size);
+    mapcache_grants_rw = xen_map_cache_init_single(f, opaque,
+                                                   XC_PAGE_SHIFT,
+                                                   max_mcache_size);
 
     setrlimit(RLIMIT_AS, &rlimit_as);
 }
@@ -456,9 +460,13 @@ uint8_t *xen_map_cache(MemoryRegion *mr,
                        bool is_write)
 {
     bool grant = xen_mr_is_grants(mr);
-    MapCache *mc = grant ? mapcache_grants : mapcache;
+    MapCache *mc = mapcache;
     uint8_t *p;
 
+    if (grant) {
+        mc = is_write ? mapcache_grants_rw : mapcache_grants_ro;
+    }
+
     if (grant && !lock) {
         /*
          * Grants are only supported via address_space_map(). Anything
@@ -523,7 +531,10 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
 
     addr = xen_ram_addr_from_mapcache_single(mapcache, ptr);
     if (addr == RAM_ADDR_INVALID) {
-        addr = xen_ram_addr_from_mapcache_single(mapcache_grants, ptr);
+        addr = xen_ram_addr_from_mapcache_single(mapcache_grants_ro, ptr);
+    }
+    if (addr == RAM_ADDR_INVALID) {
+        addr = xen_ram_addr_from_mapcache_single(mapcache_grants_rw, ptr);
     }
 
     return addr;
@@ -626,7 +637,8 @@ static void xen_invalidate_map_cache_entry_single(MapCache *mc, uint8_t *buffer)
 static void xen_invalidate_map_cache_entry_all(uint8_t *buffer)
 {
     xen_invalidate_map_cache_entry_single(mapcache, buffer);
-    xen_invalidate_map_cache_entry_single(mapcache_grants, buffer);
+    xen_invalidate_map_cache_entry_single(mapcache_grants_ro, buffer);
+    xen_invalidate_map_cache_entry_single(mapcache_grants_rw, buffer);
 }
 
 static void xen_invalidate_map_cache_entry_bh(void *opaque)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 18:27:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 18:27:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977940.1364834 (Exim 4.92)
	(envelope-from )
	id 1uCN0R-0002gw-7z; Tue, 06 May 2025 18:27:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977940.1364834; Tue, 06 May 2025 18:27:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCN0R-0002gp-3q; Tue, 06 May 2025 18:27:03 +0000
Received: by outflank-mailman (input) for mailman id 977940;
 Tue, 06 May 2025 18:27:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCN0P-0002gj-Ci
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 18:27:01 +0000
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [2a00:1450:4864:20::12a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b3014f70-2aa7-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 20:27:00 +0200 (CEST)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-549963b5551so6790988e87.2
 for ; Tue, 06 May 2025 11:27:00 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-54ea94ee173sm2093370e87.127.2025.05.06.11.26.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 06 May 2025 11: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" 
X-Inumbo-ID: b3014f70-2aa7-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746556019; x=1747160819; 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;
        bh=ulkQy97n87PM4Cu6oVIfWw2jKyekJRa0XlxEPEhm5IE=;
        b=NcKQrG9o3xfpAHbzg3YPYbbtgPJ0OHUJBu1sluaNzoXLYTKgsllZSBUigZqCU24D4z
         fU4vcyaJObOCaAmCSSi7q/0iBjVpjwQFqcBTI4FsHEiipkfcRN6z588hP4mO1uFM+rjs
         WdybpgL4S1kzNpkonR9j/BCVoXAdb3zp67JHYn4twLmm/UxZxSg42jgwSRUesr8era3I
         79LnB6dmlEwm3cA+Oqo12Bf3jRJrVJV6515Yy5/yukFzD06ImDFLv+ydyCakP4M/5u+3
         1jUJBQSVsFYwnOfh+ODllqIatiA7/sqf+x1JmJcb214ZMKsWlS0Ptv+v6jCICntPS2aX
         4qug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746556019; x=1747160819;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ulkQy97n87PM4Cu6oVIfWw2jKyekJRa0XlxEPEhm5IE=;
        b=HWFCl3GAPw/IFQJRo+mo0VpS0JINGsRmqeVk7TGA6QPBxCM9twBGaEWoALKsNVX8vC
         8yXsrYEt7+YZ5UlYOEcbqkFFPk+4+RpXTa+hzXPaFnEH8/c9x8BQc9s88DvzDCzXU0WK
         i+TdxO6/q9+KXPm9oFAsOeg9Eoh5nZQIVDxOFFMW2ZyalkNxsFjFZtPCNQSXYslSbdV0
         5PHlXq2P1zevf04HUGVJOuMsjRwJW6awpoqHMRiTmdJAWB8P3ALi3cYGjqevK7BLreQT
         +yZtprkkepTY9C5IUAghoFGJo/rHdO54LTi8OIpujt2SW7EOtlN3D0Z14Zycw9eVTbXe
         C/SA==
X-Forwarded-Encrypted: i=1; AJvYcCVLwsrYvSdjutD9XjxSlMO67QGFGJo04JuJ4mm8yCuTwi9BDX9iFYf6Cf6LD4GycgMrQbNEM3OMR9c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxswo14l73huCEGrZRRvQYHdfbMDeznumK81tmEo0mn9rFdnzHL
	+oCUCkRjV24t+tVfLW09Bi+dIGFKEA3UmApu208ZipZ9ni43iZfC
X-Gm-Gg: ASbGnctxtQrtITDM7be510ONn1YcLYAT1vU0NmLKPCqzxC6X1WcHCtSERt1x24+VCid
	vb5vqxw9g0/UO+ps2yRUEUAAmLci1cQTES+X1zVRdCCKENVHOV6QXgDM0jtHgAk1q4uT6VODWGq
	Y/bcd/BKmD1XdinpVUg9Ik5rDvJueJ7IrmD0dlLZQvD35Fg21Gp2+88bzeZrxUylLSdENuXRDJO
	vo4NEw/nxydHxa9UicDsuMc/cE5DGHmJqqrMH3anV50N0WlHG2BUCS/8X02qhCUGQgxzzpYT6Dy
	rRxVwP3VlzqmMRup0pnPZl91Jc27pzE21LAMww8jR4EgXt5VQKNKohTwv22VQy50VDrZ/yF5bDw
	wZGi597Itzx/+
X-Google-Smtp-Source: AGHT+IHzaJIdUGZqVsMqaaLKD2N5KnA7xk6kTtRN63mmTk/vnTIZ/huHbnC5q5MQJQGLHrEoa/muAg==
X-Received: by 2002:a05:6512:20d8:b0:54b:117b:952e with SMTP id 2adb3069b0e04-54fb95ba664mr159760e87.55.1746556019187;
        Tue, 06 May 2025 11:26:59 -0700 (PDT)
From: "Edgar E. Iglesias" 
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	sstabellini@kernel.org,
	anthony@xenproject.org,
	paul@xen.org,
	alex.pentagrid@gmail.com,
	peter.maydell@linaro.org,
	edgar.iglesias@amd.com,
	xen-devel@lists.xenproject.org,
	"Edgar E. Iglesias" 
Subject: [PULL v1 1/2] xen: mapcache: Fix finding matching entry
Date: Tue,  6 May 2025 20:26:46 +0200
Message-ID: <20250506182647.302961-2-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250506182647.302961-1-edgar.iglesias@gmail.com>
References: <20250506182647.302961-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Aleksandr Partanen 

If we have request without lock and hit unlocked or invalid
entry during the search, we remap it immediately,
even if we have matching entry in next entries in bucket.
This leads to duplication of mappings of the same size,
and to possibility of selecting the wrong element
during invalidation and underflow it's entry->lock counter

Signed-off-by: Aleksandr Partanen 
Reviewed-by: Stefano Stabellini 
Reviewed-by: Edgar E. Iglesias 
Signed-off-by: Edgar E. Iglesias 
---
 hw/xen/xen-mapcache.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c
index 698b5c53ed..2c8f861fdb 100644
--- a/hw/xen/xen-mapcache.c
+++ b/hw/xen/xen-mapcache.c
@@ -376,12 +376,12 @@ tryagain:
 
     entry = &mc->entry[address_index % mc->nr_buckets];
 
-    while (entry && (lock || entry->lock) && entry->vaddr_base &&
-            (entry->paddr_index != address_index || entry->size != cache_size ||
+    while (entry && (!entry->vaddr_base ||
+            entry->paddr_index != address_index || entry->size != cache_size ||
              !test_bits(address_offset >> XC_PAGE_SHIFT,
                  test_bit_size >> XC_PAGE_SHIFT,
                  entry->valid_mapping))) {
-        if (!free_entry && !entry->lock) {
+        if (!free_entry && (!entry->lock || !entry->vaddr_base)) {
             free_entry = entry;
             free_pentry = pentry;
         }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 06 19:26:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 19:26:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977974.1364863 (Exim 4.92)
	(envelope-from )
	id 1uCNwE-0004cE-Q0; Tue, 06 May 2025 19:26:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977974.1364863; Tue, 06 May 2025 19:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCNwE-0004c7-ME; Tue, 06 May 2025 19:26:46 +0000
Received: by outflank-mailman (input) for mailman id 977974;
 Tue, 06 May 2025 19:26:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCNwD-0004c1-DL
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 19:26:45 +0000
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com
 [2607:f8b0:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0a0b64fc-2ab0-11f0-9ffb-bf95429c2676;
 Tue, 06 May 2025 21:26:42 +0200 (CEST)
Received: by mail-pf1-x434.google.com with SMTP id
 d2e1a72fcca58-7390d21bb1cso6468870b3a.2
 for ; Tue, 06 May 2025 12:26:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0a0b64fc-2ab0-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746559601; x=1747164401; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sCM8dEgWqYXzV4yuApGstbuTGP9YrkOoeWFczEIDq+M=;
        b=gSOi6n1f+X1tjnBANiaA0mWiFEbvHMmgHVVW7cxr/J8OqknlVi2Csgn+UhPwUIE4c2
         SXRNx4HRKP6Hbxe04HafJwuCnBtZ/xjs/f6wuUn8uJMyup9frUtFpoHLYHzbETsIQoCS
         bhUKBq93Nv7zHGllmAhoLlKEfNhkgttNvNKko=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746559601; x=1747164401;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=sCM8dEgWqYXzV4yuApGstbuTGP9YrkOoeWFczEIDq+M=;
        b=KkXKy9FMVn0k4yIYXHWKt/poRnytCKWT8fJZZN2/VjIV/yQQtVVHdTqEcLe61lcuO4
         wVah5Ntoq5TDZ67jYzJfv5jsR1o02CYBN/KjEejBWfYhMJqGq2N0TAvxd2ul++ES5Yia
         0+aoGXO4A8CC9PaREcWF8IC8nHBfewg9zaeM/wBev2atWTKVFA0FDm3dKHJWf68NAu7H
         DR3QjM4vDzTqf6bk2u8JtO3n/pamHhicrOEIEmGJTzDgOMISUPvxQgaOpdtAAno0wiC8
         NehgPkog7u/kvB4nbn2cDLNOmbtk6+2l0IwmKVukHieBhaYzNLd5gB+7GHNxuNGjWClY
         SG7A==
X-Gm-Message-State: AOJu0Yw+LBKl70wOzArF/jbDqpU6fA6h8pR3KvwfBFWwz31bLKU/rqjL
	SSmE5RlZPOtztnOLPgtn0npXWC5sOIBbSVk4xbDY8kntpcJSww5R8yBD3raSWSyDVVCGdU70K0J
	KKFRF3dcIp00w4JQUD7EU21kvN7WSlXPyRcCzEw==
X-Gm-Gg: ASbGncvWl+ig5jyp662pwoGysxe56hJcrg8BtkaFnhA+sxTxoFICh9eT46t6ziUjAbF
	lQUbyXFs/iIVl2QjLCtxt8qQMka+ihPwO6YwL4qBVBfJgjhn1RyrFH7sBsbo25XyLVozgYQqB+s
	R9py837Fv5h6VnOhszAmIi
X-Google-Smtp-Source: AGHT+IGaEeAHgf3So0om341FKH+GPnlJgDYKRQB8+JxNdcFdPhowuBcuicT+dHcSbHr0ZCR3crN9l5EFFwwmWemhCOU=
X-Received: by 2002:a17:90b:1c05:b0:2fe:68a5:d84b with SMTP id
 98e67ed59e1d1-30aac15f608mr810931a91.1.1746559601298; Tue, 06 May 2025
 12:26:41 -0700 (PDT)
MIME-Version: 1.0
References: <20250506081456.1572050-1-kevin.lampis@cloud.com> <10538064-1085-4ae4-82f8-0aa9cabcfe23@citrix.com>
In-Reply-To: <10538064-1085-4ae4-82f8-0aa9cabcfe23@citrix.com>
From: Kevin Lampis 
Date: Tue, 6 May 2025 20:26:28 +0100
X-Gm-Features: ATxdqUEhcCHTHIr3BU_jUvvfhr2B8Ra1rZED_PuRlZsmw9yvGEbrVobHmzKGIVE
Message-ID: 
Subject: Re: [PATCH v2] x86/cpufeatures: cpuid features for Sierra Forest
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 6, 2025 at 1:29=E2=80=AFPM Andrew Cooper  wrote:
>
> Otherwise, Reviewed-by: Andrew Cooper 
>
> I can fix all on commit.

Ok, thanks.


From xen-devel-bounces@lists.xenproject.org Tue May 06 19:30:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 19:30:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.977983.1364873 (Exim 4.92)
	(envelope-from )
	id 1uCNzX-000668-7Q; Tue, 06 May 2025 19:30:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 977983.1364873; Tue, 06 May 2025 19:30: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 1uCNzX-000661-4W; Tue, 06 May 2025 19:30:11 +0000
Received: by outflank-mailman (input) for mailman id 977983;
 Tue, 06 May 2025 19:30:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCNzV-00065s-Sl
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 19:30:10 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 83a9f970-2ab0-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 21:30:07 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1746559791369575.3431114911938;
 Tue, 6 May 2025 12: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" 
X-Inumbo-ID: 83a9f970-2ab0-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1746559794; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=VL1S4WVwC63Fuhuqhx/mdKweXyWAbKTToJc/2clw6CxmCZb61MCM5oDVVQZdQNdr2kVnx9HaSDaMd0VmxZd/qn20WkyO3vE1fz2/Lspo0i6QOaKTLFUFI7kJ0+AeEyNLjxso6LG72z6OLIojBhV3pfqQleh2sjx3tBgrC0M/Yyo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1746559794; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=vTnvAL4GfSbZ9ZJ+5Y60PvSjRPqoisjqJVBAJeukLo8=; 
	b=R47BwV+4w6So8tM2k23yqs0RMPCPTlsM7pnx9ixQB735VjhGnzPOT42HXrJ84YHsigi0zMVV+ytBzYfI3cJp4UF/UfWfedZMdDO9yUDgfbAJTrIaMrLeYs+PiBiWoOkL7DzPnV7NnuSvl6/50XVuZDXS61amsD3KOXkyk1pYjJI=
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=1746559794;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=vTnvAL4GfSbZ9ZJ+5Y60PvSjRPqoisjqJVBAJeukLo8=;
	b=aMNAJmyxNjzmHBeDazk5S01YbY2YwyY59UwMAQ423KbN9ksfnmTQQB+3s9mIDNK7
	3pUBe96C2/MNoeYKBnn8lDlS4SSFJL5WUmoKL7ejhzmE8w/uXoLertfeSjo9TK/p7VN
	POoGPMnX/xWL2LdLc/TN/14divNYVC9cY1HdK0mA=
Message-ID: 
Date: Tue, 6 May 2025 15:29:50 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 02/12] common/hyperlaunch: introduce the domain builder
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Jason Andryuk , Denis Mukhin ,
 Alejandro Vallejo , xen-devel@lists.xenproject.org
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-3-agarciav@amd.com>
 <9021c878-9605-4d6e-95b8-ab97da186542@apertussolutions.com>
 <29a55d44-c26e-4834-b93b-47cbd98f885e@suse.com>
From: "Daniel P. Smith" 
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: <29a55d44-c26e-4834-b93b-47cbd98f885e@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 5/2/25 03:21, Jan Beulich wrote:
> On 30.04.2025 20:56, Daniel P. Smith wrote:
>> On 4/29/25 08:36, Alejandro Vallejo wrote:
>>> --- a/xen/common/Makefile
>>> +++ b/xen/common/Makefile
>>> @@ -11,6 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
>>>    obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
>>>    obj-$(CONFIG_IOREQ_SERVER) += dm.o
>>>    obj-y += domain.o
>>> +obj-$(CONFIG_DOMAIN_BUILDER) += domain-builder/
>>
>> Please don't do this, use IF_ENABLED in core.c and then hide the
>> unnecessary units in domain-builder/Makefile as I originally had it.
>> This allows for a much easier time incrementally converting the dom0
>> construction path into a generalized domain construction path.
> 
> That is, are you viewing this as a transitional thing only? If the end
> goal is to have it as Alejandro has it above, that may be acceptable
> (even if not nice).

There is/will be shared domain construction code between dom0-only and 
multidomain construction, with it will all living under domain builder. 
So no, the end goal is not what Alejandro just did. The end result will 
be the way I had it, with a different kconfig option to enable/disable 
the multidomain construction path.

v/r,
dps




From xen-devel-bounces@lists.xenproject.org Tue May 06 19:49:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 19:49:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978000.1364882 (Exim 4.92)
	(envelope-from )
	id 1uCOIY-000055-Q7; Tue, 06 May 2025 19:49:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978000.1364882; Tue, 06 May 2025 19: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 1uCOIY-00004v-NZ; Tue, 06 May 2025 19:49:50 +0000
Received: by outflank-mailman (input) for mailman id 978000;
 Tue, 06 May 2025 19:49:49 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uCOIX-0008WU-Il
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 19:49:49 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uCOIX-00CuGf-0X
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 19:49:49 +0000
Received: from mail-vk1-f170.google.com ([209.85.221.170])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uCOIX-004jHi-0G
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 19:49:49 +0000
Received: by mail-vk1-f170.google.com with SMTP id
 71dfb90a1353d-523f1b31cf8so1370051e0c.0
 for ; Tue, 06 May 2025 12:49:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Type:Cc:To:Subject:Message-ID:
	Date:From:In-Reply-To:References:MIME-Version;
	bh=INsAmsR5Kbp6hhkQqLEUa1y4nxrMxIXH1D7gsbuNbnU=; b=s72XBR98m76s7oO4yBF8HY6aZY
	k9ez18IP7kjXkp4Tn6pkOH0Dp5x5weWckeBbduU36O7MM5fG2ayPaCqGhQpHNV2fzfefDcHVs7trw
	19DA404XpQpXQogIPYgb/fMnpVjryusFO4h5Y5wru2Szb6bcaILqRP/ek9OusKLMW/Ow=;
X-Gm-Message-State: AOJu0YxVgRKPawHXlTF4XOHVLYeAB1i9eu1XpVadSnjZMMhI4r8XyAUX
	siaggMyUUri1wR9v3eehygGHeAfHW57p3Rzoah64LZAB2zY6CUHSbUI6CSt1QEA6yJS5d7NMytj
	pWMPsddaiX1rkpaXUdeYqGiGVbFc=
X-Google-Smtp-Source: AGHT+IFiwbusS+6mVNrkAb/Y1o9LwS+3Ook7XqXitaXID89XKMQthVMX38W6SGCICije36rxVP58TR+wrwNKET5H4IE=
X-Received: by 2002:a05:6122:3102:b0:526:2210:5b64 with SMTP id
 71dfb90a1353d-52c37ab4c4amr770785e0c.9.1746560988646; Tue, 06 May 2025
 12:49:48 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Cody Zuschlag 
Date: Tue, 6 May 2025 21:49:37 +0200
X-Gmail-Original-Message-ID: 
X-Gm-Features: ATxdqUF62pBGBHWTGOXvEnRRnUL9ISHI6T5tbYQ84pkw2_faM2fZgkCDdfjVyWs
Message-ID: 
Subject: Re: [ANNOUNCE] [NEW TIME] Call for agenda items for May 7, 2025
 Community Call @ 15:00 UTC
To: xen-devel@lists.xenproject.org
Cc: Tamas K Lengyel , "intel-xen@intel.com" , 
	"daniel.kiper@oracle.com" , Roger Pau Monne , 
	Christopher Clark , Rich Persaud , 
	Kevin Pearson , Juergen Gross , 
	Paul Durrant , Ji John , 
	"robin.randhawa@arm.com" , Artem Mygaiev , 
	Matt Spencer , Stewart Hildebrand , 
	Volodymyr Babchuk , Jeff Kubascik , 
	Stefano Stabellini , Julien Grall , 
	Rian Quinn , "Daniel P. Smith" , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLRG91ZyBHb2xkc3RlaW4=?= , 
	George Dunlap , David Woodhouse , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLQW1pdCBTaGFo?= , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLVmFyYWQgR2F1dGFt?= , 
	Brian Woods , Robert Townley , 
	Bobby Eshleman , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLQ29yZXkgTWlueWFyZA==?= , 
	Olivier Lambert , Andrew Cooper , 
	Ash Wilding , Rahul Singh , 
	=?UTF-8?Q?Piotr_Kr=C3=B3l?= , 
	Brendan Kerrigan , Thierry Laurion , 
	Oleksandr Andrushchenko , 
	Oleksandr Tyshchenko , Scott Davis , 
	Anthony PERARD , Michal Orzel , 
	Marc Ungeschikts , Zhiming Shen , 
	Xenia Ragiadakou , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLSGVucnkgV2FuZw==?= , 
	Samuel Verschelde , Andrei Semenov , 
	Yann Dirson , Bernhard Kaindl , 
	=?UTF-8?B?4oCL4oCL4oCL4oCL4oCL4oCL4oCLTHVjYSBGYW5jZWxsdQ==?= , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Vikram Garhwal , Ayan Kumar Halder , 
	Kelly Choi , Thierry Escande , 
	Guillaume Thouvenin , 
	Andrei Cherechesu , =?UTF-8?B?UmFmYcOrbCBLb29p?= , 
	Mathieu Labourier , 
	Demi Marie Obenour , Cody Zuschlag , 
	Alejandro Vallejo 
Content-Type: multipart/alternative; boundary="0000000000004e9c3706347ceb68"

--0000000000004e9c3706347ceb68
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Reminder for tomorrow=E2=80=99s community call 07 May at 15:00 UTC. See bel=
ow for a
link to the agenda.


Cody Zuschlag
Xen Project - Community Manager


On Mon, Apr 28, 2025 at 17:42 Cody Zuschlag 
wrote:

> Hi everyone,
>
> *IMPORTANT: Due to public holidays in several countries, May's community
> call has been moved to Wednesday, 7 May 2025.*
>
> We=E2=80=99re getting ready for May's Xen Project Community Call on *Wedn=
esday, 7
> May 2025* at *15:00 UTC* (4 pm UK time). We=E2=80=99d love for you to joi=
n. Feel
> free to just observe or jump in! This call is a great opportunity to see
> what the community is working on, align our various efforts, and share
> updates. Everyone is welcome!
>
> *Preparation:*
>
>    - Add any proposed agenda items or missing action items:
>    https://cryptpad.fr/pad/#/2/pad/edit/1cT4oJhJZAnJk9CbAogFYchM/
>    - If any action items have been resolved or are no longer relevant,
>    feel free to remove them from the doc.
>
> *Call Details:*
>
>    - *Date:* Wednesday, 7 May 2025
>    - *Time:* 15:00 UTC (agenda begins at 15:05 UTC)
>       - Find your local timezone here
>       
>    - *Link to Join the Call:* https://meet.jit.si/XenProjectCommunityCall
>
> We plan to open the meeting room at 15:00 UTC, but to allow time for
> switching between meetings and handling any technical issues, we=E2=80=99=
ll
> officially start discussing the agenda at 15:05 UTC.
>
> *Want to be CC=E2=80=99d on future calls?*
>
> Add or remove yourself from our Sign-up Sheet
> .
>
>
> See you next week!
>
>
> Cody Zuschlag
> Xen Project - Community Manager
>

--0000000000004e9c3706347ceb68
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Reminder for tomorrow=E2=80=99s community call 07 May at =
15:00 UTC. See below for a link to the agenda.=C2=A0


Cody Zuschlag
Xen Project -=
 Community Manager


On Mon, Apr 28, 2025 at 17:42 Cody Zuschlag <cody.zuschlag@xenproject.org> wrote:
Hi everyo=
ne,
IMPORTANT: Due to public holidays in several count=
ries, May's community call has been moved to Wednesday, 7 May 2025.=

We=E2=80=99re getting ready for May's Xen Project Communit=
y Call on=C2=A0Wednesday, 7 May 2025=C2=A0at=C2=A015:00 UTC=
=C2=A0(4 pm UK time). We=E2=80=99d love for you to join. Feel free to just =
observe or jump in! This call is a great opportunity to see what the commun=
ity is working on, align our various efforts, and share updates. Everyone i=
s welcome!
Preparation:
Call Details:
We plan to open the=
 meeting room at 15:00 UTC, but to allow time for switching between meeting=
s and handling any technical issues, we=E2=80=99ll officially start discuss=
ing the agenda at 15:05 UTC.
Want to be CC=E2=80=99d on future cal=
ls?
Add or remove yourself from our=C2=A0Sign-up Sheet.
    See you next week!

    =


    Cody Zuschlag
    Xen Project - Communit=
y Manager
    

    

--0000000000004e9c3706347ceb68--


From xen-devel-bounces@lists.xenproject.org Tue May 06 20:45:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 20:45:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978014.1364893 (Exim 4.92)
	(envelope-from )
	id 1uCPA0-0008HC-F4; Tue, 06 May 2025 20:45:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978014.1364893; Tue, 06 May 2025 20:45: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 1uCPA0-0008H5-CP; Tue, 06 May 2025 20:45:04 +0000
Received: by outflank-mailman (input) for mailman id 978014;
 Tue, 06 May 2025 20:45:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCP9z-0008Gz-1s
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 20:45:03 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2412::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f9be76b3-2aba-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 22:45:00 +0200 (CEST)
Received: from BLAPR03CA0086.namprd03.prod.outlook.com (2603:10b6:208:329::31)
 by CY5PR12MB6036.namprd12.prod.outlook.com (2603:10b6:930:2c::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Tue, 6 May
 2025 20:44:52 +0000
Received: from BN3PEPF0000B076.namprd04.prod.outlook.com
 (2603:10b6:208:329:cafe::41) by BLAPR03CA0086.outlook.office365.com
 (2603:10b6:208:329::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.30 via Frontend Transport; Tue,
 6 May 2025 20:44:52 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN3PEPF0000B076.mail.protection.outlook.com (10.167.243.121) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Tue, 6 May 2025 20:44:51 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 May
 2025 15:44:51 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 May
 2025 15:44:51 -0500
Received: from amd-BIRMANPLUS.mshome.net (10.180.168.240) by
 SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 6 May 2025 15:44: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" 
X-Inumbo-ID: f9be76b3-2aba-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=aJrjXxWuuq2A59bZ72Tqu9LmeZ43/Z0oSpEvzYPa7rmKkThK3XP/epGQPR24U1XxLMw3rrsadA4lRA3L0xqd7p2LArdx7scK6Z7nN/qLoeGgZuqcIZMlipmw97X/HBK7YGkhysfYvk4acHC4KooVGzg+saKan21adhDQu4IwCGqO8qUuD4jnmONUyXT0K5XFi1ryewHgK+reNu3sD2WUolDETNHI1PDXjXabebVVhEqEnGUVmb5vEO0mIKSDFDr/lYWsbMsWHlOg3IXaevEiDjXgaxtGL4pq0feq6G1kqfSJKmT599hoAISOWQ4Q4hspeZFTRxIYrDkaReYJR1CFyw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5tH2aBzTLtGyOv5D7f7OeME/gvHNM1uvC6mzTtLdJQE=;
 b=CpyV7sroFdumwDXSmtPHzBSHmm7DwplpqEaBwWs54ed8ykyG3XCYy6U0TIn0ZFlsJPZ6DmZn9oZcl5nD0r8lgpJvDLVmhbhpMJpcEehOZHx5FmL9Kb9B6PCdka02GjKXJlE7+6tVZmf/ACkUm83SzL/nOMQn7+3wh8tzhWWqER4QWxn25l4hbKy/42/+UHagD0TqMt5tk8SbcV0Mfa6IFEYZlrxxjHZmNf26TgF04VWagKoY/IYOBGn262V9HaiRFewTto8HWTuh/llDHCSCC3efVdoq16mwrsEjD4D+jW6PFplDB4YHDV+HDtzFnhJOjt2tSp3KU4FIs1vevcXPVA==
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=5tH2aBzTLtGyOv5D7f7OeME/gvHNM1uvC6mzTtLdJQE=;
 b=D56GcaL05AACcrNACB521xL6fWRlmqSAfX7krICDSHO8grFn0hR3KSach5heMMriZdAI8F23OZrGkHnOIVj95U0gTzcN0e3+7fWuluSR3seP8aMmaLYSyiYlpGyAHsX0NBkUrbG5/jc3R8oefHMGTEUjPCCN+vjr25Lzz4R+uZA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: Juergen Gross , Stefano Stabellini
	, Oleksandr Tyshchenko
	
CC: Jason Andryuk , ,
	
Subject: [PATCH v2] xenbus: Allow PVH dom0 a non-local xenstore
Date: Tue, 6 May 2025 16:44:56 -0400
Message-ID: <20250506204456.5220-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
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B076:EE_|CY5PR12MB6036:EE_
X-MS-Office365-Filtering-Correlation-Id: 054fefcc-122c-473c-6933-08dd8cded9b0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?kq7VJbIXgT0QVpxbz4uqZUDZPrzqKCRkf3HWW0vaFIlRkUNwhI00rKYNOAWZ?=
 =?us-ascii?Q?hCqTyf6mOiUn4uuQ0zkP5DziDGCjltqwjL54ZCnnvaTkHl/KEwnaV9VM8fHT?=
 =?us-ascii?Q?rwdXNCyY+7RI4z0CJXTeU3PsnNSt9gFwXm7llnBZF9esRsKO96pPyKOM4LNu?=
 =?us-ascii?Q?bv9zEX/Hw5/oMgnp4oPz8ys4D5ZrmQ/Azj4x4ep/FIgZrg2vAjwfZUGclJl5?=
 =?us-ascii?Q?H8MGlLOftrBNnoWfSPP48+NS7yci8SwWL/2+7mOoJa+fH7uQq+9YQavQ3RZ7?=
 =?us-ascii?Q?nnsaxjxhg/6tgO+EdXWPf9uKcEfNTDnMrerXuwmueLxLngYOgml2wp6RTu4q?=
 =?us-ascii?Q?TlJA5JMQ2ohH+y4GulHaVw7/VwYey/5o6UPty78zdf1ANzemYrDiC6v9nakV?=
 =?us-ascii?Q?n86Tq07kyYDMPMLOuGe7+lz0/SqpZxoaJoRbOlhLFC/qj+mjst97jJjrS/xl?=
 =?us-ascii?Q?CaEpR/TYOtK9R//cV9yyMYHxhBpRCRwESBL9xBqox/vtK9lfsOJk77ePsYwk?=
 =?us-ascii?Q?IULzCzXZk8uUhrQPuinLmcBXM6FxxNkVYQ5JhbASqPn7n04iabX+KPglaKpg?=
 =?us-ascii?Q?6SCaVJZNGe0qXO7w+mlAxdfssTWOsgt4QjzXRwBytmp+yOkcyclyGwJMncky?=
 =?us-ascii?Q?ZNsDFwMnhSGJNFDwCR47VJm+1BLsIf3aUlzSrOCxXtmgEfLP/LObx0qRkMGq?=
 =?us-ascii?Q?Po4TP2CHGfBr944HtEvkQEjNrOkA4aNRajorLvDCzjZcVlnBmRuIfKMGBsY0?=
 =?us-ascii?Q?uIL/J06m3vKA+K+JF+nq8MQQZ2mAx4RW090zSjAbkmdC2tk0GUCaf6FwyZ/i?=
 =?us-ascii?Q?zWeQRQVkh6Wu/Kmy0SFquTYsFdZAghuUabASxN76hbU6u/iRl+uESPf1sZsn?=
 =?us-ascii?Q?LHrTZdYc225RU3LieR2DxIpHFQ+W4jZ+W5WZO2iZyiSh3Ow9s0m70d8mt6YY?=
 =?us-ascii?Q?AxWLUeCHhskOPHenomR6Pxe5czH0Y7o9SMFri9WOkmSvr267Dzp58wrNrBnV?=
 =?us-ascii?Q?Jb4u1XhS2u0GeowFxdvSQ9oadazb9FAbCXAqO146n3IZqCYrDLD9mxVzsNFw?=
 =?us-ascii?Q?l5LgNiWPmHOSOdnYJZY+KJtf4gZUZq6Jwuw/VFrW5kM9wSLZ2TE3c8roRuZm?=
 =?us-ascii?Q?FmfMkMJEBY1a3vXfXqZIuMV5I/fuUuZZL9OS61pVoFjJQXVvYMmdXMRDVz91?=
 =?us-ascii?Q?2GEb5eKQYgfPHgCc7R3uKCVuonhXLa/FOqwcy930LXJxVGG/eIq5bFg/mvi9?=
 =?us-ascii?Q?Cm4kaDLlVAs+PmNp7U/JydPmaTdFSzsmYNFATZN+hKrYuNots7n0ZUTeef1w?=
 =?us-ascii?Q?l0WD4KuN8qtFIjBr8wmFBLfSjEpbMpD0S3o1SDY0sEIGDZer4dLjAEUb7vaX?=
 =?us-ascii?Q?MvE7yW4TYa/6dr7S8GnQMdC4F0dbXn510YLDl8lfMUDly/Xyh/LH57xJz06V?=
 =?us-ascii?Q?zP94PL/0SvA4RgNYL0Gvmlmy4znpt+DYoJS9ypWdzExwpn2QIgLfjE/FZYWD?=
 =?us-ascii?Q?5SLRz5zt1izzkGo/+XRxl2CJZux1NewJbAJK?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 20:44:51.8897
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 054fefcc-122c-473c-6933-08dd8cded9b0
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B076.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6036

Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late init path.

Ideally we'd drop the use of xen_initial_domain() and just check for the
event channel instead.  However, ARM has a xen,enhanced no-xenstore
mode, where the event channel and PFN would both be 0.  Retain the
xen_initial_domain() check, and use that for an additional check when
the event channel is 0.

Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
chance that high bits are set for the 32bit event channel.

Signed-off-by: Jason Andryuk 
Change-Id: I5506da42e4c6b8e85079fefb2f193c8de17c7437
---
v2:
Re-add xen_initial_domain() check to avoid breaking ARM's xen,enhanced
no-xenstore mode where event channel and PFN are both 0.

 drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 22d3f90ee205..b12cbd9663e3 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -969,9 +969,15 @@ static int __init xenbus_init(void)
 	if (xen_pv_domain())
 		xen_store_domain_type = XS_PV;
 	if (xen_hvm_domain())
+	{
 		xen_store_domain_type = XS_HVM;
-	if (xen_hvm_domain() && xen_initial_domain())
-		xen_store_domain_type = XS_LOCAL;
+		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+		if (err)
+			goto out_error;
+		xen_store_evtchn = (int)v;
+		if (!v && xen_initial_domain())
+			xen_store_domain_type = XS_LOCAL;
+	}
 	if (xen_pv_domain() && !xen_start_info->store_evtchn)
 		xen_store_domain_type = XS_LOCAL;
 	if (xen_pv_domain() && xen_start_info->store_evtchn)
@@ -990,10 +996,6 @@ static int __init xenbus_init(void)
 		xen_store_interface = gfn_to_virt(xen_store_gfn);
 		break;
 	case XS_HVM:
-		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-		if (err)
-			goto out_error;
-		xen_store_evtchn = (int)v;
 		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
 		if (err)
 			goto out_error;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 20:55:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 20:55:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978025.1364903 (Exim 4.92)
	(envelope-from )
	id 1uCPK9-0001cR-CI; Tue, 06 May 2025 20:55:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978025.1364903; Tue, 06 May 2025 20:55: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 1uCPK9-0001cK-9Z; Tue, 06 May 2025 20:55:33 +0000
Received: by outflank-mailman (input) for mailman id 978025;
 Tue, 06 May 2025 20:55:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCPK8-0001c9-Ac
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 20:55:32 +0000
Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com
 [2607:f8b0:4864:20::1129])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 71bd5ebb-2abc-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 22:55:30 +0200 (CEST)
Received: by mail-yw1-x1129.google.com with SMTP id
 00721157ae682-6ff37565154so54278607b3.3; 
 Tue, 06 May 2025 13:55:31 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-708c46cbcc0sm28818677b3.118.2025.05.06.13.55.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 13:55: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" 
X-Inumbo-ID: 71bd5ebb-2abc-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746564930; x=1747169730; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XaQudY3fwgxYRyADZDL8jhCQROjxwSC2Czzwe4219vc=;
        b=IVKiE4UHm+Ngs4zU3opP28wYAuaX9xChoN6v4o3DphyPeeHrk/EAxV7zVsY0flcdU2
         nKJQfjAuWDizFIiaEUZ5JyU99kGkqUDznwCgA4u1zA1AQ4jS6ZZ6hwZOIn5JJHvhvXdZ
         +jw3B6VRNsX/P42MAKDZay0LCWUMfAfw7EGCmJnJaGOZNzBr2Ydyy1INsWuOs1loNnvN
         ECZu901l6vMOcY/4j1ujoJaeSJXOvcplsbZ6dpH3nUi9QwVLpruvDgGp9/SM3fy8CJfE
         +UbH+GP6/A4H0caZgO6y7Gmi7t4G4UtMb9t9b273GJZ2IMd9xeu5Z5Wdvwhm0yLg9y6j
         5VkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746564930; x=1747169730;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=XaQudY3fwgxYRyADZDL8jhCQROjxwSC2Czzwe4219vc=;
        b=fiTDeEioyoWsoE9wHuI+0x2Onco0E1QPzAZGwjTFUYxg+vABagBUtAcKaaJtYFloA3
         llN6HYz/wBzhJdsASHvWD37rAW1JTb0gT7Hyfwg61wyiWXorCySKWkBDNrrgQGgI9XJi
         zdjexpffiX6aBWIsEIbD71HPLh/yJjP77tRISHQ5dHi0euGbnyK1MeesZv3DShA1OueE
         BlZqrMsSFL5MgMnDOHdKcWXOxcPmuuSExphdoB+QBmIquhMOhZInNniY78pjHUvqi9ya
         R7Ga9P1j8Fc490RcP93mVmDJMSXo+jrsUbpjt3wJXr1IOJ3aCWM8aK0KHAaa2qMtoR1X
         dr6g==
X-Forwarded-Encrypted: i=1; AJvYcCUFtJYRJRKRu46wpj7pB5m+sa8gzq35GyZOBuodTpCQA1P+naxkLIFW4VripunNqORU/HHi8++Y3TBZFIgKsetqHA==@lists.xenproject.org, AJvYcCXqOUdFuqmIzpe0DhvcJdk/a1Naoa87bn0gVyG7XP2aeBuR9v8Md6pi7j3G+k/cpGJPlXJicEhnvZz0@lists.xenproject.org
X-Gm-Message-State: AOJu0YyMFDs6h2PKcyqrBISiWcaL7iA+LsqrDYItXlPZVVvK/VdIFJoj
	T2FnMiJAhp5R8UromSMWntpnqONf8oe2iCdm/AyaMnDryf9wVXTh
X-Gm-Gg: ASbGncupMRNSM79lcYZ49lRo8YbJwhHnEG1nTFpghyUvA9APmPBne7ErKC7G7AVs2I4
	wII1SMMDg4KfwsFF92acbdp1IV+TGiBvr67I2BW703fa97ftu/kbiO4duvyi0cFHBOBgKKERcq6
	ysJIEwKTZEZSVvvX1lPYXj0nv3CZrqYUTc/e9NgnijyTkKYdGgDhyv0PIxLn1qnDcGjBZ292p18
	Z1RrbPQNcZrjVXCJnHmCJVszZJiqjx4GZUH0V1WgUj6hoxBlM5HI7yacLFft6m7x4aPit2A4BxK
	p716sm4X8X+tQDNGD91mzL/7cmqsykjBWIbeUHsuJbRV
X-Google-Smtp-Source: AGHT+IHnF0X/mPFrP4DqJbJ/NpZiRDNjVZBqZ4bpOieGpmHhCVTO66fclgRX4H0fg528Otz+Et+x7Q==
X-Received: by 2002:a05:690c:650a:b0:708:39b1:863e with SMTP id 00721157ae682-70a1da8fc05mr15269667b3.15.1746564929630;
        Tue, 06 May 2025 13:55:29 -0700 (PDT)
Message-ID: 
Date: Tue, 6 May 2025 16:56:12 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Alejandro Vallejo ,
 Xen developer discussion 
Cc: Andrew Cooper , Juergen Gross
 , Xen-devel 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: Mapping memory into a domain
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Ug0yZErzvnn2E0ccOh0nm0Pd"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Ug0yZErzvnn2E0ccOh0nm0Pd
Content-Type: multipart/mixed; boundary="------------TSCZeA7Ylj9iMZaXR4OOSF5Y";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Alejandro Vallejo ,
 Xen developer discussion 
Cc: Andrew Cooper , Juergen Gross
 , Xen-devel 
Message-ID: 
Subject: Re: Mapping memory into a domain
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
In-Reply-To: 
Autocrypt-Gossip: 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==

--------------TSCZeA7Ylj9iMZaXR4OOSF5Y
Content-Type: multipart/mixed; boundary="------------71UNXmZ6EkFBsUxqKNQWhGOQ"

--------------71UNXmZ6EkFBsUxqKNQWhGOQ
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/6/25 9:06 AM, Alejandro Vallejo wrote:
> On Tue May 6, 2025 at 3:02 AM CEST, Demi Marie Obenour wrote:
>> On 5/5/25 7:32 AM, Alejandro Vallejo wrote:
>>> I suppose this is still about multiplexing the GPU driver the way we
>>> last discussed at Xen Summit?
>>>
>>> On Mon May 5, 2025 at 12:51 AM CEST, Demi Marie Obenour wrote:
>>>> What are the appropriate Xen internal functions for:
>>>>
>>>> 1. Turning a PFN into an MFN?
>>>> 2. Mapping an MFN into a guest?
>>>> 3. Unmapping that MFN from a guest?
>>>
>>> The p2m is the single source of truth about such mappings.
>>>
>>> This is all racy business. You want to keep the p2m lock for the full=

>>> duration of whatever operation you wish do, or you risk another CPU
>>> taking it and pulling the rug under your feet at the most inconvenien=
t
>>> time.
>>>
>>> In general all this faff is hidden under way too many layers beneath
>>> copy_{to,from}_guest(). Other p2m manipulation high-level constructs
>>> that might do interesting things worth looking at may be {map,unmap}_=
mmio_region()
>>>
>>> Note that not every pfn has an associated mfn. Not even every valid p=
fn
>>> has necessarily an associated mfn (there's pod). And all of this is
>>> volatile business in the presence of a baloon driver or vPCI placing
>>> mmio windows over guest memory.
>>
>> Can I check that POD is not in use? =20
>=20
> Maybe, but now you're reaching exponential complexity considering each
> individual knob of the p2m into account.
>=20
>>
>>> In general anything up this alley would need a cohesive pair for
>>> map/unmap and a credible plan for concurrency and how it's all handle=
d
>>> in conjunction with other bits that touch the p2m.
>>
>> Is taking the p2m lock for the entire operation a reasonable approach
>> for concurrency?  Will this cause too much lock contention?
>=20
> Maybe. It'd be fine for a page. Likely not so for several GiB if they
> aren't already superpages.
>=20
>>
>>>> The first patch I am going to send with this information is a docume=
ntation
>>>> patch so that others do not need to figure this out for themselves.
>>>> I remember being unsure even after looking through the source code, =
which
>>>> is why I am asking here.
>>>
>>> That's not surprising. There's per-arch stuff, per-p2mtype stuff,
>>> per-guesttype stuff. Plus madness like on-demand memory. It's no wond=
er
>>> such helpers don't exist and the general manipulations are hard to
>>> explain.
>>
>> Is this a task that is only suitable for someone who has several years=

>> experience working on Xen, or is it something that would make sense fo=
r
>> someone who is less experienced?
>=20
> The p2m is a very complex beast that integrates more features than I
> care to count. It requires a lot of prior knowledge. Whoever does it
> must know Xen fairly well in many configurations.
>=20
> The real problem is finding the right primitives that do what you want
> without overcomplicating everything else, preserving system security
> invariants and have benign (and ideally clear) edge cases.
>=20
> This was the last email you sent (I think?). Has any of the requirement=
s
> changed in any direction?
>=20
>   https://lore.kernel.org/xen-devel/Z5794ysNE4KDkFuT@itl-email/

Map and Revoke are still needed, with the same requirements as described
in this email.  Steal and Return were needed for GPU shared virtual memor=
y,
but it has been decided to not support this with virtio-GPU, so these
primitives are no longer needed.

> Something I'm missing there is how everything works without Xen. That
> might help (me, at least) guage what could prove enough to support the
> usecase. Are there sequence diagrams anywhere about how this whole thin=
g
> works without Xen? I vaguely remember you showing something last year i=
n
> Xen Summit in the design session, but my memory isn't that good :)

A Linux driver that needs access to userspace memory
pages can get it in two different ways:

1. It can pin the pages using the pin_user_pages family of APIs.
   If these functions succeed, the driver is guaranteed to be able
   to access the pages until it unpins them.  However, this also
   means that the pages cannot be paged out or migrated.  Furthermore,
   file-backed pages cannot be safely pinned, and pinning GPU memory
   isn=E2=80=99t supported.  (At a minimum, it would prevent the pages fr=
om
   migrating from system RAM to VRAM, so all access by a dGPU would
   cross the PCIe bus, which would be very slow.)

2. It can grab the *current* location of the pages and register an
   MMU notifier.  This works for GPU memory and file-backed memory.
   However, when the invalidate_range function of this callback, the
   driver *must* stop all further accesses to the pages.

   The invalidate_range callback is not allowed to block for a long
   period of time.  My understanding is that things like dirty page
   writeback are blocked while the callback is in progress.  My
   understanding is also that the callback is not allowed to fail.
   I believe it can return a retryable error but I don=E2=80=99t think th=
at
   it is allowed to keep failing forever.

   Linux=E2=80=99s grant table driver actually had a bug in this area, wh=
ich
   led to deadlocks.  I fixed that a while back.

KVM implements the second option: it maps pages into the stage-2
page tables (or shadow page tables, if that is chosen) and unmaps
them when the invalidate_range callback is called.  Furthermore,
if a page fault happens while the page is unmapped, KVM will try
to bring the pages back into memory so the guest can access it.

For GPU acceleration via virtio-GPU native contexts to work,
the Xen interface driver needs to do the same thing with GPU
buffers that KVM does: it needs to fault the pages into guest
memory on-demand and revoke access to the pages when the host
kernel demands them back.  There really is no alternative that
I am aware of.  The need to handle guest page faults doesn=E2=80=99t
come from the host kernel, but rather from guest userspace.
It isn=E2=80=99t practical to change guest userspace to remove this
requirement.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------71UNXmZ6EkFBsUxqKNQWhGOQ
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------71UNXmZ6EkFBsUxqKNQWhGOQ--

--------------TSCZeA7Ylj9iMZaXR4OOSF5Y--

--------------Ug0yZErzvnn2E0ccOh0nm0Pd
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgad20ACgkQszaHOrMp
8lOKkBAAmdWylLAdJx4cuxHdliQfF6h++9AfsEEKDASVk28FqnFa7QonCJPpXEnb
1ezThILwsvprAtWE+/CSfoviMayL40+lB6PZfSjY3DAtv1YSp/IMHwPhYM6+XZo9
W8IBnM6tD3PGiuCPY7TpbcfB5hDRTtszhegueDCXCgXABx0ePESfsvfazR9gV56u
CBwuUvCz/UkMZYw/18fT/g2kybrVouIwq0/3iYSQBGTQOgvMzk+8s/C0g8qMVYp8
tXV3AYczxXUbKl6jjo1JhqDW/Zt8vFQJdAnNM2H4T3doDS1VTzmVk04MlQHJRBK9
5LZT3yqimcqThmNabegVg/hLE4IhextA9a3J8fwT8zZUwW5BThjSpKoGqrKwbwK+
lH0Ja8CLgjxT3kXi3p5SOADKoqWcSdk4cRbOra9oWm8Js3F9g9r9fxnyp2oQfW1Y
p22fJAQNaj+NR7t6pkbq1WXPvEohKgkyqDJJmuOWAheiO99FrdDhy3ymTgZ58Wjx
gnRKpMhLeL45cB3NK3pmiE97wQdnCLCWZgeZIgyTXcHIUSR0IEDknrMBH7+TtUje
T89s84BHwDJrWM7LEyirXmvSc9j6TUgpduQCkpxIsIJ7/VNh+NCVzHDbIt9Qmle/
Q2js7icFO5u96nXHc00y4l9OIO/cEtQFQttTTZsKSQVoH5g0cX8=
=Oh+5
-----END PGP SIGNATURE-----

--------------Ug0yZErzvnn2E0ccOh0nm0Pd--


From xen-devel-bounces@lists.xenproject.org Tue May 06 21:09:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 21:09:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978043.1364912 (Exim 4.92)
	(envelope-from )
	id 1uCPXj-0003WS-Jb; Tue, 06 May 2025 21:09:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978043.1364912; Tue, 06 May 2025 21:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCPXj-0003WL-H5; Tue, 06 May 2025 21:09:35 +0000
Received: by outflank-mailman (input) for mailman id 978043;
 Tue, 06 May 2025 21:09:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCPXi-0003WF-Fq
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 21:09:34 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2412::61e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 669ede2d-2abe-11f0-9eb4-5ba50f476ded;
 Tue, 06 May 2025 23:09:32 +0200 (CEST)
Received: from MW4PR04CA0355.namprd04.prod.outlook.com (2603:10b6:303:8a::30)
 by SA1PR12MB8945.namprd12.prod.outlook.com (2603:10b6:806:375::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Tue, 6 May
 2025 21:09:25 +0000
Received: from SJ1PEPF00002321.namprd03.prod.outlook.com
 (2603:10b6:303:8a:cafe::ca) by MW4PR04CA0355.outlook.office365.com
 (2603:10b6:303:8a::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.26 via Frontend Transport; Tue,
 6 May 2025 21:09:25 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00002321.mail.protection.outlook.com (10.167.242.91) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Tue, 6 May 2025 21:09:24 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 May
 2025 16:09:23 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 May
 2025 16:09:23 -0500
Received: from amd-BIRMANPLUS.mshome.net (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 6 May 2025 16:09:22 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 669ede2d-2abe-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JkM98pa5bLac5LeVj+T/abpH51hVU/ad1FMWkzbjhZatvdh2FQ9v7ksZEgSssViDnBuapZkp8Zbx7iT+ANSfS+hRNsZgz30bnOhuPeX4tl0FvRK6JR3rrtLwbFmgRixPV3oVV5lcWAbQ732tbnnpZS5ZDAo1kHyByFkuTqWt/VUhFO5JLdnSLfjJDaNXbBecHvFUad4cVaQK++ORHrulMmFZ03EQo/SUpT/M2e8eiGec6iG9MgpKvxMYzvwJ+nNhvPXdSskkeIuoZI5t1ZPXsQrZXLgP1CMMPWmmosL8UbvNIRXHWCLLaYTrX4kEqY/7bs2QGCAJ5FjmcbMoq8qVTg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LexVX8ApKvljcmQ19kTQlqapvR2rrjJA4xi625UdRDk=;
 b=Mt5kc/zo726CZLgjjKAyhgX+FjX+f1Qlo2xAaIiRj/CTnwFO8BK8QITULfNI3Ei4eOBCUsjnSQ6c3SL68HNBsO0/khay1CNk3z9W4RogJ4dXlmXpDQ81nzmsZCjAtvaB2OdVacDBxXHi7Ovxl8Z2bsBD1n4JWkIQAohXNjA1jM88cYRVqt98QSCqakM21RIBTu99T/L7kw5+j2If4vaCdjlEKW7uSc//hTNxVEgSvtoCTXOJtWIeGOzQqKuqBDwqHV+KCNfAvpMuovae7sYJZjn9RVuWRlM0k5S8u6zqY8G7UpEMd5h0A+5MJmhN7z/uYKBLW9/ftIWcqJ3KdRQ1xQ==
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=LexVX8ApKvljcmQ19kTQlqapvR2rrjJA4xi625UdRDk=;
 b=VuHQH+aTQNiDh1JEIWS1hKYNrsguHV82/Jbrp9GvzIgfhLAsRSxgjZ9qJ2fA5JmGoyekF6YjC9AxwPQaA+YykvxnMc8DwQ7QsAV/Fl9Asfw58l6vb/zfW2bzd+Srv5GNQrw50bfsHQfNe+1YB7i2aVj5xlV7oavZTRmVkwwBDac=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: Juergen Gross , Stefano Stabellini
	, Oleksandr Tyshchenko
	, Boris Ostrovsky 
CC: Jason Andryuk ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
	, ,
	, 
Subject: [PATCH] xenbus: Use kref to track req lifetime
Date: Tue, 6 May 2025 17:09:33 -0400
Message-ID: <20250506210935.5607-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002321:EE_|SA1PR12MB8945:EE_
X-MS-Office365-Filtering-Correlation-Id: 1a3ed70f-39bd-49f0-e110-08dd8ce247af
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eXZQNGtuRnM1bnppMDJ1ZU40SGh2M2ZsNDU5VEVpczQ2eisyNHIwdVVSL1ZY?=
 =?utf-8?B?Y0dOQVZTQUlrU2FaY21GQmg1RXJCb3ZpMExHb0VxbENzMk53RGZHQzNqSnha?=
 =?utf-8?B?N3Z2elVEZCtCOHlrR0lQZXYzb1JjQkFZQnZSdjhwQ1FxTGhEYStMRjhMMjB4?=
 =?utf-8?B?K1dac3cwMld0TWNkOWtrU1FYT1dQUm5RMVlTcmphcG4rQ0h0YjdpZy9Tek1E?=
 =?utf-8?B?dlBVdU1PUTV5aVU3Q3U0eXpDWGd5L0FxU2xnTTQxMytNeHZna1pDNUFqV1E3?=
 =?utf-8?B?Z1hsNUxjb1FPenpSdkw4VllvNFJCLy82Nmk0U2ZtelhJbzFyWGVlVnkwSzFD?=
 =?utf-8?B?aVBpd0YySFVuOUM4U1Q3Ry9ZeTh5NkVwR09JclNUeitvT3dxRTM1cjQrdzh5?=
 =?utf-8?B?TjJSVDcycDlhTTNaNnl2NGdRRndrSW43bm15MVVnUTZuQ20xVFJyYkkwWXVw?=
 =?utf-8?B?ZzhqTTVKb3hrTlg3UHZEVk8wWVE0QWoyS0pqbkVvNnd6dzBGZSs5NjdEbzky?=
 =?utf-8?B?dG5yY0Qxa1JPdW9VSU5rQ1FnTDNTYUhHcW5VYU1GMkZreW92U1N0RGIxSWE2?=
 =?utf-8?B?dzdTYnhCR0lwOG8zSEowUnRoaU8xL2ZDMjRpbExHcHJpTDVBTGU2MmxWWnFH?=
 =?utf-8?B?ejRZS3VoR0Mvd2RPZUlVaEF3YktSKy8xM2R0ejVkYkRoNnFQbFZvQzdtVy9E?=
 =?utf-8?B?cTE0MXB4cW4xWGNEMU5rQ05qMUdmTXRzeEpqUmxnTFRMVVBBMlNHVWE5RlZS?=
 =?utf-8?B?ZGtlZzhvVndmL3IvbFQxV3ZvVmFsOUprRUxnSnE2RUtoWmFHOTZXcVVLR0Ns?=
 =?utf-8?B?ZjZIWTgvTURtREFjRHhJU0lBd1lDVStlaThHYW9xZzRHVVFQSUkweGVLSTNF?=
 =?utf-8?B?MW5YeDJGaWdxQ2JsMGNGK0Nla01UVEp0YjNtY0E2dDdBdFoxenRkUHdBSEdV?=
 =?utf-8?B?NGhDMHlJZDd0MkJrVW5pNHdSYnhQRkhOeSsvZHk5eU9HeThvblNUbGpqcnVK?=
 =?utf-8?B?S282dHZsNWdSRVhTODlHVXl5Qjh0SzJKdS9WYlZMNWYvL2pKd3EvZk8vSlNQ?=
 =?utf-8?B?amtjYmw3bmtjeEJGYkcveDFZNnZ2ZVpCdThCcjZ2T2lFNDFCcDBmT1RLMVFB?=
 =?utf-8?B?S1V4VEwyQW9JV2JoMC81Z1ovdkp3VWJBWVIzNmYzOG1mSkQ4L3JQMGNUQjl4?=
 =?utf-8?B?MUxPZjErUmc3WERHVnVJVGExekYzcmNsM1R4ckxUVldKQmxxcTl3SXRxVlhJ?=
 =?utf-8?B?aks5V0RsSkNVdFY1ZEtzUE5FOWZyODZxN0l4elZGTHF5WDd0TExiMnNkVEhr?=
 =?utf-8?B?Q0RTWG9wYndBelFRL1R3cmxFMVlyeHJTNkEvb2JwcjhYR01JTDNCS3RWVStP?=
 =?utf-8?B?VzlYNU4yTi9ydGxyTkRyMTZWZHdNTmI0dEZjVmlWcmpUUHJwN01PMmhLQmJC?=
 =?utf-8?B?MTRpWVpYYUdOdXFhS1BOVCtTc0xwM29BcjhJd3hNUXRObXYzRWdNcU95ZG5K?=
 =?utf-8?B?RGlPbWxhaGVJeGNXdGZOb2FWekxmdnBYbkY5WllIODFFWUJxa3dDb1B2cXFu?=
 =?utf-8?B?SUZUWGJhOEUwZ2hLcDlXQnpTRUVpdlJPb0pMQmlaY1k1bGc2QWcvTjgxYTZU?=
 =?utf-8?B?a3RHOUJwTUE3N3lVbjVlTDM0ZjNBS2ZqdGVOS09lbjZkUng5L3grV3JTQlRX?=
 =?utf-8?B?UDJlVTZUVmNQTFcxZTBMRGZNUzRhemZZSC9nZzREaUl5MTkzU0M1NWtFc3NW?=
 =?utf-8?B?b01jMnFtb1JrMldoeG02dVRwMHArcjVOZUlEenZrdTA5TW5lM2ZUTE9UTVhT?=
 =?utf-8?B?MThEUEg0VEFIOGhkcWpvUnkrRWFXWWVxdHl2dVhxbjJJNG03bS9aMmJCTkRi?=
 =?utf-8?B?eUlmR291SXV0STVFRlc3VmdEVGI1ZkhGSkFIQUlqT29FNFVqRnVwVHZhVEN5?=
 =?utf-8?B?VktTRnh2dTJmd3dNb1RYY0NGSllmemNFcHRBcjdJc0dQZHgrU1JrRWxnc04w?=
 =?utf-8?B?SFp0L2gyZnl4elZOa05pNjE4L3VJQy9ZWUhrbEU4eHBoTFJlUE53am1IR1Qy?=
 =?utf-8?B?MUtFMFVIN0JiVkNxZlk2SWt2ZEkrVkRHdXhkQT09?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 21:09:24.8239
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a3ed70f-39bd-49f0-e110-08dd8ce247af
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002321.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8945

Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
 
 __wake_up_common_lock+0x82/0xd0
 process_msg+0x18e/0x2f0
 xenbus_thread+0x165/0x1c0

process_msg+0x18e is req->cb(req).  req->cb is set to xs_wake_up(), a
thin wrapper around wake_up(), or xenbus_dev_queue_reply().  It seems
like it was xs_wake_up() in this case.

It seems like req may have woken up the xs_wait_for_reply(), which
kfree()ed the req.  When xenbus_thread resumes, it faults on the zero-ed
data.

Linux Device Drivers 2nd edition states:
"Normally, a wake_up call can cause an immediate reschedule to happen,
meaning that other processes might run before wake_up returns."
... which would match the behaviour observed.

Change to keeping two krefs on each request.  One for the caller, and
one for xenbus_thread.  Each will kref_put() when finished, and the last
will free it.

This use of kref matches the description in
Documentation/core-api/kref.rst

Link: https://lore.kernel.org/xen-devel/ZO0WrR5J0xuwDIxW@mail-itl/
Reported-by: "Marek Marczykowski-Górecki" 
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Cc: stable@vger.kernel.org
Signed-off-by: Jason Andryuk 
---
Kinda RFC-ish as I don't know if it fixes Marek's issue.  This does seem
like the correct approach if we are seeing req free()ed out from under
xenbus_thread.

 drivers/xen/xenbus/xenbus.h              |  2 ++
 drivers/xen/xenbus/xenbus_comms.c        |  9 ++++-----
 drivers/xen/xenbus/xenbus_dev_frontend.c |  2 +-
 drivers/xen/xenbus/xenbus_xs.c           | 18 ++++++++++++++++--
 4 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
index 13821e7e825e..9ac0427724a3 100644
--- a/drivers/xen/xenbus/xenbus.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -77,6 +77,7 @@ enum xb_req_state {
 struct xb_req_data {
 	struct list_head list;
 	wait_queue_head_t wq;
+	struct kref kref;
 	struct xsd_sockmsg msg;
 	uint32_t caller_req_id;
 	enum xsd_sockmsg_type type;
@@ -103,6 +104,7 @@ int xb_init_comms(void);
 void xb_deinit_comms(void);
 int xs_watch_msg(struct xs_watch_event *event);
 void xs_request_exit(struct xb_req_data *req);
+void xs_free_req(struct kref *kref);
 
 int xenbus_match(struct device *_dev, const struct device_driver *_drv);
 int xenbus_dev_probe(struct device *_dev);
diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index e5fda0256feb..82df2da1b880 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -309,8 +309,8 @@ static int process_msg(void)
 			virt_wmb();
 			req->state = xb_req_state_got_reply;
 			req->cb(req);
-		} else
-			kfree(req);
+		}
+		kref_put(&req->kref, xs_free_req);
 	}
 
 	mutex_unlock(&xs_response_mutex);
@@ -386,14 +386,13 @@ static int process_writes(void)
 	state.req->msg.type = XS_ERROR;
 	state.req->err = err;
 	list_del(&state.req->list);
-	if (state.req->state == xb_req_state_aborted)
-		kfree(state.req);
-	else {
+	if (state.req->state != xb_req_state_aborted) {
 		/* write err, then update state */
 		virt_wmb();
 		state.req->state = xb_req_state_got_reply;
 		wake_up(&state.req->wq);
 	}
+	kref_put(&state.req->kref, xs_free_req);
 
 	mutex_unlock(&xb_write_mutex);
 
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
index 46f8916597e5..f5c21ba64df5 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -406,7 +406,7 @@ void xenbus_dev_queue_reply(struct xb_req_data *req)
 	mutex_unlock(&u->reply_mutex);
 
 	kfree(req->body);
-	kfree(req);
+	kref_put(&req->kref, xs_free_req);
 
 	kref_put(&u->kref, xenbus_file_free);
 
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index d32c726f7a12..dcf9182c8451 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -112,6 +112,12 @@ static void xs_suspend_exit(void)
 	wake_up_all(&xs_state_enter_wq);
 }
 
+void xs_free_req(struct kref *kref)
+{
+	struct xb_req_data *req = container_of(kref, struct xb_req_data, kref);
+	kfree(req);
+}
+
 static uint32_t xs_request_enter(struct xb_req_data *req)
 {
 	uint32_t rq_id;
@@ -237,6 +243,12 @@ static void xs_send(struct xb_req_data *req, struct xsd_sockmsg *msg)
 	req->caller_req_id = req->msg.req_id;
 	req->msg.req_id = xs_request_enter(req);
 
+	/*
+	 * Take 2nd ref.  One for this thread, and the second for the
+	 * xenbus_thread.
+	 */
+	kref_get(&req->kref);
+
 	mutex_lock(&xb_write_mutex);
 	list_add_tail(&req->list, &xb_write_list);
 	notify = list_is_singular(&xb_write_list);
@@ -261,8 +273,8 @@ static void *xs_wait_for_reply(struct xb_req_data *req, struct xsd_sockmsg *msg)
 	if (req->state == xb_req_state_queued ||
 	    req->state == xb_req_state_wait_reply)
 		req->state = xb_req_state_aborted;
-	else
-		kfree(req);
+
+	kref_put(&req->kref, xs_free_req);
 	mutex_unlock(&xb_write_mutex);
 
 	return ret;
@@ -291,6 +303,7 @@ int xenbus_dev_request_and_reply(struct xsd_sockmsg *msg, void *par)
 	req->cb = xenbus_dev_queue_reply;
 	req->par = par;
 	req->user_req = true;
+	kref_init(&req->kref);
 
 	xs_send(req, msg);
 
@@ -319,6 +332,7 @@ static void *xs_talkv(struct xenbus_transaction t,
 	req->num_vecs = num_vecs;
 	req->cb = xs_wake_up;
 	req->user_req = false;
+	kref_init(&req->kref);
 
 	msg.req_id = 0;
 	msg.tx_id = t.id;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 06 22:17:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 22:17:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978056.1364922 (Exim 4.92)
	(envelope-from )
	id 1uCQbB-0004O1-B9; Tue, 06 May 2025 22:17:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978056.1364922; Tue, 06 May 2025 22:17: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 1uCQbB-0004Nu-8A; Tue, 06 May 2025 22:17:13 +0000
Received: by outflank-mailman (input) for mailman id 978056;
 Tue, 06 May 2025 22:17:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCQbA-0004No-4E
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 22:17:12 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d5b23358-2ac7-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 00:17:02 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-39c31e4c3e5so3839204f8f.0
 for ; Tue, 06 May 2025 15:17:02 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-441d43cb5e5sm8161145e9.7.2025.05.06.15.17.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 15: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" 
X-Inumbo-ID: d5b23358-2ac7-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746569822; x=1747174622; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=WOLLM1nZ2VFgS6llNyqg6FWUpWb8G4v8eubCWc5XIFQ=;
        b=NTndIjVaGaSSBksUR+5WNwnBMBS+/BURPB/a9TFNYoez/M6dO5Kk6Ga8IRebuFCYHt
         Q0H4zT/Z9QYG5ZDOJepwFkWl9fOLTUapdYTK0YUU96i70TE3HHpfyLMPh/kCx2xVq48r
         CoD/t8YMwVCMvt5zqJAj/O5XQANiLnS3ADo9I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746569822; x=1747174622;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=WOLLM1nZ2VFgS6llNyqg6FWUpWb8G4v8eubCWc5XIFQ=;
        b=IVFGXmvFPNDJDKhIKnf4W58p9JmT+Wg9LFLDUiSmdxQyyf878vuZI5pF421jjT+drb
         alc7Ao3BwEyMcMOgh1gis1XVcy4+6fDHOl56dGwWt43MVZbmXmT2ySUPoAqVEyxn2KTb
         mviXyb0ChPySD2Gs6ZfplibGBqI4sc1Q1m7nxtpgP6fpr465U4/bQ6GvgTduPjloxE7c
         EQXX9gHv3661l1GOSfkY2xpIdyNH2DxjjDZX8a62Gj/+rH+OJZM8Naz1kw9Z6mdLTrMZ
         fWa4E3joYbBWBLZqOX+S5Uz5CHjFLpr1BYtwioej2Brtz6RHKDTHxVfVD72m3y0LqIjS
         xNHw==
X-Forwarded-Encrypted: i=1; AJvYcCUaSIg0eeX/wCiUPIilxZ644TGAVi6mbIYcWQpFwGKWeqAlj8yGukJkOTdazV+8Y/9SWciaU2LCabk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzd7bZ+KpFlGx5wouONKnW9IuW9S6oPTrhGXuT9t6zC0bVD9GTl
	feWvgbsr8nJkVsMvSqDsboTlaBobuv2hT57AsY0uuELK7xMqAhft84FK1ab1U7s=
X-Gm-Gg: ASbGncsi/H0p45J15tVLnPJPV5zxZLUnkWIxyx9gOJWsd+PBaHKePL52HnKC0kim+/+
	z8vgF9ygsK6SRm7hBvBDzVA6vRrOTIuxGOVc62hWwdvNWht4HrjhL40dTXShRMnt/XjfAzcvOBL
	hmzbNylBOeEiVNyr+WBHF2ZgTRkLXQbhBSJ0UGUEGlS65S6O3+3la7Zt81/M1uF9l/Nu+GUNtea
	aMjcOlBQJxoVDd9b8g0lt5WcIJ80NT7cDSqSG/uC9S1ow6W4s1WJssJhWClSZBHFjqzeVVUPEHw
	lo4kUtxt7rcrsVORKp2nt5uA/sVwDKg77ywH9epGotxvjxNTUas+JF761yDODb8k5bjLgie4IZw
	T0PXQp3UvfWkgPECX
X-Google-Smtp-Source: AGHT+IEOlXHPWvrY6jY6PfXrSE0R7h9lROIErZBHwGdvPv16ypp10sJd8KEMtfJV9OLpiY3vCR9ExA==
X-Received: by 2002:a5d:588e:0:b0:391:2f15:c1f4 with SMTP id ffacd0b85a97d-3a0b4a68783mr773759f8f.55.1746569821672;
        Tue, 06 May 2025 15:17:01 -0700 (PDT)
Message-ID: <5698b996-e23d-49f7-af37-645d4784dc67@citrix.com>
Date: Tue, 6 May 2025 23:17:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] xen/lib: Export additional sha256 functions
From: Andrew Cooper 
To: Frediano Ziglio ,
 xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: <20250506135655.187014-1-frediano.ziglio@cloud.com>
 <20250506135655.187014-2-frediano.ziglio@cloud.com>
 
Content-Language: en-GB
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

On 06/05/2025 3:05 pm, Andrew Cooper wrote:
> On 06/05/2025 2:56 pm, Frediano Ziglio wrote:
>> diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
>> index 47d97fbf01..ea8bad67e4 100644
>> --- a/xen/include/xen/sha2.h
>> +++ b/xen/include/xen/sha2.h
>> @@ -9,6 +9,16 @@
>>  
>>  #define SHA2_256_DIGEST_SIZE 32
>>  
>> +struct sha2_256_state {
>> +    uint32_t state[SHA2_256_DIGEST_SIZE / sizeof(uint32_t)];
>> +    uint8_t buf[64];
>> +    size_t count; /* Byte count. */
>> +};
>> +
>> +void sha2_256_init(struct sha2_256_state *s);
>> +void sha2_256_update(struct sha2_256_state *s, const void *msg,
>> +                     size_t len);
>> +void sha2_256_final(struct sha2_256_state *s, void *_dst);
>>  void sha2_256_digest(uint8_t digest[SHA2_256_DIGEST_SIZE],
>>                       const void *msg, size_t len);
> sha2_256_digest() is unlike the others as it holds sha2_256_state
> internally.  I'd suggest having all of the additions below this point,
> which group them more nicely.
>
> Can fix on commit.  Otherwise LGTM.

Not quite.  Now that sha2_256_final() is exported, it should have a
proper type for  _dst.  I've folded:

diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
index 0d55fe640431..cb30e8f8d77c 100644
--- a/xen/include/xen/sha2.h
+++ b/xen/include/xen/sha2.h
@@ -21,6 +21,7 @@ struct sha2_256_state {
 void sha2_256_init(struct sha2_256_state *s);
 void sha2_256_update(struct sha2_256_state *s, const void *msg,
                      size_t len);
-void sha2_256_final(struct sha2_256_state *s, void *_dst);
+void sha2_256_final(struct sha2_256_state *s,
+                    uint8_t digest[SHA2_256_DIGEST_SIZE]);
 
 #endif /* XEN_SHA2_H */
diff --git a/xen/lib/sha2-256.c b/xen/lib/sha2-256.c
index 896a257ed9b7..08ef7011a1c3 100644
--- a/xen/lib/sha2-256.c
+++ b/xen/lib/sha2-256.c
@@ -171,9 +171,9 @@ void sha2_256_update(struct sha2_256_state *s, const
void *msg,
     memcpy(s->buf + partial, msg, len);
 }
 
-void sha2_256_final(struct sha2_256_state *s, void *_dst)
+void sha2_256_final(struct sha2_256_state *s, uint8_t
digest[SHA2_256_DIGEST_SIZE])
 {
-    uint32_t *dst = _dst;
+    uint32_t *dst = (uint32_t *)digest;
     unsigned int i, partial = s->count & 63;
 
     /* Start padding */

in too, which is compatible with the rest of the series too.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 06 23:50:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 23:50:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978074.1364941 (Exim 4.92)
	(envelope-from )
	id 1uCS3g-0008M0-Nd; Tue, 06 May 2025 23:50:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978074.1364941; Tue, 06 May 2025 23:50: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 1uCS3g-0008Lt-Ku; Tue, 06 May 2025 23:50:44 +0000
Received: by outflank-mailman (input) for mailman id 978074;
 Tue, 06 May 2025 23:50:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCS3e-0008H9-Og
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 23:50:42 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e8d0fb82-2ad4-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 01:50:38 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id CED5444113;
 Tue,  6 May 2025 23:50:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5876C4CEE4;
 Tue,  6 May 2025 23:50: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" 
X-Inumbo-ID: e8d0fb82-2ad4-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746575436;
	bh=K2EpZFZm5KmhUkaGNC7dpG3OXzxxMH7yltZGwwMxS2M=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HU9q6mErzeytk8DcWlsZQatn9YR63FLL7AWA6n5+PNC+GxYihjLpwvKGnIXcwvwDU
	 lee5X5I3uXYHoemea/mDaZB5JH/C/cydo3u25nZWCjhNnExzUBtemZQVsGMf78ssKu
	 KbIl8t8vrCStdOnsvbbRtD/dhqzZZksS0eP3H1/NgNr6aE4QTqR0adJ0dzrbYi7EOL
	 a6kTMxnH8sHQYV1ugHQQcRDlzJU713upAbTwfnnZ8yWfhJ454mM4pzigPNKe9bZ6B4
	 7AIW1BM4uaSzKWXmUY14kTbgn1QqC8YfMf7k8mFWLpJxR84zWYoxV9s2GnEqmMJQH/
	 Py6YfMDvDHTYg==
Date: Tue, 6 May 2025 16:50:34 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jason Andryuk 
cc: Stefano Stabellini , 
    Juergen Gross , 
    Oleksandr Tyshchenko , 
    xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xenbus: Allow PVH dom0 a non-local xenstore
In-Reply-To: <63d6ff3c-bed5-4a7f-bd3e-50b99b5a6f4b@amd.com>
Message-ID: 
References: <20250503131935.1885-1-jason.andryuk@amd.com>  <63d6ff3c-bed5-4a7f-bd3e-50b99b5a6f4b@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 6 May 2025, Jason Andryuk wrote:
> On 2025-05-05 16:44, Stefano Stabellini wrote:
> > On Sat, 3 May 2025, Jason Andryuk wrote:
> > > Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
> > > currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
> > > xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
> > > late init path.
> > > 
> > > Drop the use of xen_initial_domain() and just check for the event
> > > channel instead.  This matches the PV case where there is no check for
> > > initial domain.
> > > 
> > > Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
> > > chance that high bits are set for the 32bit event channel.
> > > 
> > > Signed-off-by: Jason Andryuk 
> > 
> > Reviewed-by: Stefano Stabellini 
> 
> Thanks, Stefano.  But I'm wondering if this might break ARM enhanced
> no-xenstore.
> 
> > 
> > > ---
> > >   drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
> > >   1 file changed, 8 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/xen/xenbus/xenbus_probe.c
> > > b/drivers/xen/xenbus/xenbus_probe.c
> > > index 6d32ffb01136..7604f70ee108 100644
> > > --- a/drivers/xen/xenbus/xenbus_probe.c
> > > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > > @@ -966,9 +966,15 @@ static int __init xenbus_init(void)
> > >   	if (xen_pv_domain())
> > >   		xen_store_domain_type = XS_PV;
> > >   	if (xen_hvm_domain())
> > > +	{
> > >   		xen_store_domain_type = XS_HVM;
> 
> ARM would have everything set to XS_HVM...
> 
> > > -	if (xen_hvm_domain() && xen_initial_domain())
> > > -		xen_store_domain_type = XS_LOCAL;
> 
> ...and only dom0 set to XS_LOCAL.
> 
> > > +		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> > > +		if (err)
> > > +			goto out_error;
> > > +		xen_store_evtchn = (int)v;
> > > +		if (!v)
> > > +			xen_store_domain_type = XS_LOCAL;
> > > +	}
> > >   	if (xen_pv_domain() && !xen_start_info->store_evtchn)
> > >   		xen_store_domain_type = XS_LOCAL;
> > >   	if (xen_pv_domain() && xen_start_info->store_evtchn)
> > > @@ -987,10 +993,6 @@ static int __init xenbus_init(void)
> > >   		xen_store_interface = gfn_to_virt(xen_store_gfn);
> > >   		break;
> > >   	case XS_HVM:
> > > -		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> > > -		if (err)
> > > -			goto out_error;
> > > -		xen_store_evtchn = (int)v;
> > >   		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> > >   		if (err)
> > >   			goto out_error;
>                 /*
>                  * Uninitialized hvm_params are zero and return no error.
>                  * Although it is theoretically possible to have
>                  * HVM_PARAM_STORE_PFN set to zero on purpose, in reality it
> is
>                  * not zero when valid. If zero, it means that Xenstore hasn't
>                  * been properly initialized. Instead of attempting to map a
>                  * wrong guest physical address return error.
>                  *
>                  * Also recognize all bits set as an invalid/uninitialized
> value.
>                  */
>                 if (!v) {
>                         err = -ENOENT;
>                         goto out_error;
>                 }
> 
> IIUC, this !v check is for enhanced no-xenstore to end up in XS_UNKNOWN.  I'll
> have to re-work to handle that case.

I was wondering about that when reviewing this patch, because the
removal of this check was the main change introduced I wasn't sure
about. Looking around I (wrongly) convinced myself that removing the
check was OK. Thank you for spotting this on your own.


From xen-devel-bounces@lists.xenproject.org Tue May 06 23:57:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 06 May 2025 23:57:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978090.1364951 (Exim 4.92)
	(envelope-from )
	id 1uCSAB-0000bp-IR; Tue, 06 May 2025 23:57:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978090.1364951; Tue, 06 May 2025 23: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 1uCSAB-0000bi-Et; Tue, 06 May 2025 23:57:27 +0000
Received: by outflank-mailman (input) for mailman id 978090;
 Tue, 06 May 2025 23:57:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCSAA-0000bc-Gk
 for xen-devel@lists.xenproject.org; Tue, 06 May 2025 23:57:26 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id db3e7861-2ad5-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 01:57:25 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 9957261165;
 Tue,  6 May 2025 23:57:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 630FFC4CEE4;
 Tue,  6 May 2025 23:57: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" 
X-Inumbo-ID: db3e7861-2ad5-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746575843;
	bh=yxSEOOrKIkvEzMKukyHAhQPQyFWYQHJ/8Utird1u5bU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=JVYJz8oNyKONT9+TOS6KyHKoWQjF7wfPUuYUryFI+j3cj7KUTD2WcFnIwXu97KDjW
	 3wti9Pkvrm9RPyaLMMR3/kBorRBltIwgDy8FbIKVwa5ce+cGxZGojuJmgwSAe/xhY/
	 q6bmhV6AGQbA08ocA5xJPlbhyFXGn0NjgxqrLmL4LLnX7dHwQhK2JYdwZwZgM89YfU
	 LY3LXL/psSODAFl4P0+DxsBrKQHnQuYLmHEn8zqEvRjKY7p+I6ZDj2B9PtIFaqcyLW
	 o/cLWkYAg4QHE1QeZnhQWUblcEK9x0GuXfuAFRsedb1Oesz/tJthqXgWXMmgjAbzjb
	 ZUSz2W3tbkVSA==
Date: Tue, 6 May 2025 16:57:21 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jason Andryuk 
cc: Juergen Gross , 
    Stefano Stabellini , 
    Oleksandr Tyshchenko , 
    xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] xenbus: Allow PVH dom0 a non-local xenstore
In-Reply-To: <20250506204456.5220-1-jason.andryuk@amd.com>
Message-ID: 
References: <20250506204456.5220-1-jason.andryuk@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 6 May 2025, Jason Andryuk wrote:
> Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
> currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
> xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
> late init path.
> 
> Ideally we'd drop the use of xen_initial_domain() and just check for the
> event channel instead.  However, ARM has a xen,enhanced no-xenstore
> mode, where the event channel and PFN would both be 0.  Retain the
> xen_initial_domain() check, and use that for an additional check when
> the event channel is 0.
> 
> Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
> chance that high bits are set for the 32bit event channel.
> 
> Signed-off-by: Jason Andryuk 
> Change-Id: I5506da42e4c6b8e85079fefb2f193c8de17c7437
> ---
> v2:
> Re-add xen_initial_domain() check to avoid breaking ARM's xen,enhanced
> no-xenstore mode where event channel and PFN are both 0.

Thanks for the catch!

Reviewed-by: Stefano Stabellini 


>  drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index 22d3f90ee205..b12cbd9663e3 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -969,9 +969,15 @@ static int __init xenbus_init(void)
>  	if (xen_pv_domain())
>  		xen_store_domain_type = XS_PV;
>  	if (xen_hvm_domain())
> +	{
>  		xen_store_domain_type = XS_HVM;
> -	if (xen_hvm_domain() && xen_initial_domain())
> -		xen_store_domain_type = XS_LOCAL;
> +		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> +		if (err)
> +			goto out_error;
> +		xen_store_evtchn = (int)v;
> +		if (!v && xen_initial_domain())
> +			xen_store_domain_type = XS_LOCAL;
> +	}
>  	if (xen_pv_domain() && !xen_start_info->store_evtchn)
>  		xen_store_domain_type = XS_LOCAL;
>  	if (xen_pv_domain() && xen_start_info->store_evtchn)
> @@ -990,10 +996,6 @@ static int __init xenbus_init(void)
>  		xen_store_interface = gfn_to_virt(xen_store_gfn);
>  		break;
>  	case XS_HVM:
> -		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> -		if (err)
> -			goto out_error;
> -		xen_store_evtchn = (int)v;
>  		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
>  		if (err)
>  			goto out_error;
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Wed May 07 02:47:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 02:47:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978102.1364960 (Exim 4.92)
	(envelope-from )
	id 1uCUoQ-0004k3-FT; Wed, 07 May 2025 02:47:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978102.1364960; Wed, 07 May 2025 02: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 1uCUoQ-0004jw-CO; Wed, 07 May 2025 02:47:10 +0000
Received: by outflank-mailman (input) for mailman id 978102;
 Wed, 07 May 2025 02:47:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCUoO-0004iI-G6
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 02:47:08 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20628.outbound.protection.outlook.com
 [2a01:111:f403:200a::628])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8d076160-2aed-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 04:47:01 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DM6PR12MB4404.namprd12.prod.outlook.com (2603:10b6:5:2a7::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Wed, 7 May
 2025 02:46:53 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8699.012; Wed, 7 May 2025
 02:46: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" 
X-Inumbo-ID: 8d076160-2aed-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=T6U1cFrCa9ozpoaGC4XOYP1XZAng2uGxHlFUszFlTUneLytR/Jfl0NdNbHatY8wuLKZmDFCWSd7zXyTp/uVYZox6xtHFBGC9UN/PyRlJtn22ZadMvH7URONA/KhB9sbjmuaZ1gUREUH7xVXq4i7uU5M/Gl5zzCY6VQDIzCASs3RcBxCt3VGfuTlOgDVjILdFw1Fj+AR6p0Ejwl9H4fM1KkMhO+Ny6Tigw6TYmtgiLQYxnBS0RhourFdjUZF0SJX5FjxtuC2LkYQXQK1GGCO5mHhlN0ngckagpN3iEh2ATXlt69+mOXdZSdX4G8wuSzcQxkNBCfpRGcI1lPjDXaHIeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+xMpg8qO/OoUMO6S7MPmOMUWW05RqrMsOrkvfCyrpvI=;
 b=aKJ+HtBGAz+vse8b/4Mrf4Ma9KZhlvPKfydxzoGP1miwNW2F86h1WOCKbHroeX8mYE+AKXqHjjeXEoWlOqxJBe/MJAveQlg/gD/SI8JtYXNhoK10bSztwK9lhu6TcIX+Nh1phl5jLdkrnHA+mAp94gMqVrlnrDXP+OQz3EPFgbcQTrJKoo7WZs5qep1PM/VTt7ZFlb1VgQ0eNANjQlpYRpfwI6N/LAH9PWHklZ45+FHWQH7qGQs09tsk1Za0TuD7gS+5r9Iky05Z5IxvDL5CP9Sbo3dLxWeQuerznN6CZqAC4/XZr/s67+kD3WrIYpDkMVkGWgfcSdZ/fQeFcvfyOg==
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=+xMpg8qO/OoUMO6S7MPmOMUWW05RqrMsOrkvfCyrpvI=;
 b=Qk6HY5FcGEpoCvUOadVCD2O4AWZWDfnEemxNTvYWbU5fQ3eIuMm/EKyP+DT4ApldVTwyqXGXNejs2HagTD451HEm1z6qKdtx+HxXt2abWQA7BQSGAlili2qelR4gt5HJGvvDkFBJS3cNWDuF0NWJwSuLW9h+susmopS/a1M3uCk=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v3 03/11] vpci/header: Emulate legacy capability list for
 dom0
Thread-Topic: [PATCH v3 03/11] vpci/header: Emulate legacy capability list for
 dom0
Thread-Index: AQHbsoVY0As/JNC0IkWc2g8aH+9wh7PFtqAAgAFbx4A=
Date: Wed, 7 May 2025 02:46:52 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-4-Jiqian.Chen@amd.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8699.005)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|DM6PR12MB4404:EE_
x-ms-office365-filtering-correlation-id: 54bc5ffb-6f4b-4bea-53f5-08dd8d116c59
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?MFRkNXAxLytRQ3RyZm1TNzJSUTIwbEJ2aytvZXV1MGlPYzg2LzJDd0VycHE4?=
 =?utf-8?B?ejIzaUtQVVVFSTZoS0o4LzdLeW9wM0svbko2MEFOdkkwRHh0SWczREZqWkF0?=
 =?utf-8?B?aXdLb2VETGZ0TFJJQ1I2WDYwQlVNcW5DWXFyT0VjWkN5UzRjcUVMRVczcWh0?=
 =?utf-8?B?YlppaU1BT1VXaUE5OTl0STNIL3NZbHlINE5UbGxORlhXRFc2SWtxOUpRMVFF?=
 =?utf-8?B?VVNlWG0vK0VmU1h3bGt5clJSMzJWcEV3Q0huSWFXaWZ4ajNxVVZCYjRhOFVq?=
 =?utf-8?B?cW04M00wSmhHTm91S3B6aXp1cGJLVm1rNzNZM0Z5YWZlNTVobnlRdGhBSXhS?=
 =?utf-8?B?R3lyRXRlNWo1cHVrcVZlSTNxSm03eGg1ODkzb0JzUHRGQjFiVGtvdHJrdHVL?=
 =?utf-8?B?RDJDTFA1NjZKQm1SODQxSjlRTnhncEJRRnp2cG5EMVgvV013dHc3aERud3N1?=
 =?utf-8?B?MU4yTDlRTmpWNHhIWEoyWGNXS0NYbExOaS9aVithbFpjeExWbVl2TVZVYzBM?=
 =?utf-8?B?cVRFV1BQQ09rbE5iMXNKNjk5RWIwR0xGZ25uQUV6NDlkOXBDNnc0TTIrYUpm?=
 =?utf-8?B?M3NjQnNueUVoZmliV1prZHlpa2cvRTByem95NEhIdDF1L2RtRzA2QjBSSzRQ?=
 =?utf-8?B?ZGloTkNoVVZuQ1h3UTRUMFROZWEvUHF1bisrbnJLQkdtYlA2aUlPTFI4eER0?=
 =?utf-8?B?b0ZzM3dvVXM5OVFnSDlFQ3RYbTF1d2taQ09aTUxaVWVzaWNxcFhPWlBSZXlF?=
 =?utf-8?B?U2REK05uTFpzVUZIUXQrWVM4T1BtZFNTbWpOK2JWeVZCTk02WDZCYTJJZ2RV?=
 =?utf-8?B?VHVkYXhPcTM5YVh3dVY2bDFmL0k2cmZyQ1J0bUU4T1BTNXAzdi9lYWh4YWx1?=
 =?utf-8?B?bXozZGx5dGxkTzNPQkhYRnlTdHB5anFnYUVaaTQyZXQzeEZ4TjRTTVhNSkJa?=
 =?utf-8?B?WG94UXptdGNsUFdSMWVvMkhFci8veit0d1lhekpVU2w1T2ZjZGJ0VkNxbVo1?=
 =?utf-8?B?ZkZrZU5neDltTGdtMy9SeHMvWERzY21ZdStsYVduejhwNnFFODdPN0xoZ2JC?=
 =?utf-8?B?Mk9aL2l5Y3FYbWx6d0FDdkV4d1M4d1ZpVFZLdHF3a00wVk5xSk5mSzlKL0hQ?=
 =?utf-8?B?T0VIcyt4WENwSkxsRnRtem0yczI3b3BzQ1Q5NGt6S0d0R3c2VkY1UmRVbTIz?=
 =?utf-8?B?TFBUVE9nNEp5bDlSSktqQWZXaDBjd1cwMFR3dUprc2EvMFNZd3ZjYkpzYlBr?=
 =?utf-8?B?MjhFVkw0ZlNqb0IwMWJhNTVKQzhrWEJtRlBBVUZ6ZTYzQVRRa3JiZU1DTU9V?=
 =?utf-8?B?Z1RyalNHSlFsUVhWcjlxN3hzZnR6OVNHSEExd3pEVjhhcEVpelI1b09uRlMy?=
 =?utf-8?B?WkxwMEU0eFkyU0F1eHlKeEZ5K0p2VXhMbVBuNVRRRllCSUgyaE13OFZ2S215?=
 =?utf-8?B?ei8rZnNKS3dCNU94SzIyRXZvaUxIM3dqWEpnOXRyNkpSTjZidHoxRzk3MnBG?=
 =?utf-8?B?Zyt6eC9xZGIzT3BYZ05MK2FQV1paRzY5WTRMZVRYVzNka2x6THNUaUl6M3FE?=
 =?utf-8?B?TWp5K2EvOTk0K1ZJZVJKMjJrdldUSyt5N3lVY0o4QjVQRTB5d1YvaTMzc1k5?=
 =?utf-8?B?aVp3N3RZNHhZem1zOU4rSVR4YSs0RDZiVUM3aGp6N2ZDNXFNVW4zVVR3THhB?=
 =?utf-8?B?OC9oY2lmTDZDSG1rNEhsMjA3UWpsaGtFTGt2Ym9QMXdTV0RlbHlzcjhKbUFY?=
 =?utf-8?B?OFJwUEpWMjVPQ2x6eUdoc3BzWWR4RDg4SEFRMXF1TTFjYTdTeXZ3YXVhWHRz?=
 =?utf-8?B?b2FpdUVReEx1VU5IS2lVZWVpMEthWVBSbHV6Z1VRVis0SlloTWxuR1dFTGZy?=
 =?utf-8?B?QkRKM0NQQXFKZEozSzdmb2lKS3BRN09tVUZIMmF1QnpRM0w4d2g5WUd0dGR2?=
 =?utf-8?B?clJGYm4wWjBMUVFEVldnazBUSkwrTi83NGZrNTVZMTRZREJ3YjFPTGtXUEEv?=
 =?utf-8?Q?Z/88I1nK7Jv/5xklBYR0NOD3Gm1fTE=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?ODJUYW9yUVFaUnBjOVE0VmorQ09nZ3JiU2duSlNrOWVYSkZFVURvQjc5bnB0?=
 =?utf-8?B?bi9mNkFEdXB5UE5IOGlrM29hMGhQRk12L1JNQXIxdkZSZmF4OTJ6bEp6RGtV?=
 =?utf-8?B?VE8zeXZnRCtEb2dGckI1NVRNeVZoVldzL0lGR29CMGdEd2ViRWxSaGZCeTBH?=
 =?utf-8?B?RUV1SjRZN3lBd1VKRnNob2kzWXJlZ0pnR3JKbWkzL20remJGM244eC8rcUI5?=
 =?utf-8?B?MW1KdnZyeXMyWXZkNGJUdEUrVEJQNElydllQQjZDRUxCWXJXdkExdW92TGVO?=
 =?utf-8?B?ZzFHWW1vOWZzVnFvbHAvajNkaGt3ajdyOHhBeWlRTGJLYTNKVjVYa09OZ0hX?=
 =?utf-8?B?QmJPVnJqcmJFSjA0aEJESWhZYTBZWTE2Wi9Mck5UM3dxYjk5UEpYZzUzTUQ0?=
 =?utf-8?B?YkhydWhndlNQQmVMMHZPbmV6cHQ2YTdWdlhpY2U3QzE1NC9sc0YwOXRZYjRR?=
 =?utf-8?B?MXRremNZQ1hhbk1Ka0tJK2tOZlhDc0w2U3Y0dG5abTBoVVRSQjRDOXEySjgy?=
 =?utf-8?B?NTFiQnFkRVdtRGxsVGhDYzJzQWYxNUJVS0xveUNubGRaeDFEVVRUeXVrOHdh?=
 =?utf-8?B?VDEzUERXWHU0N3pIZkdhcFcwR0FaamtEeVJVRG9pT3duNi9xSUQvK2xlbnc1?=
 =?utf-8?B?cWFPdVhRREZXZjdpWXpQdEs3dlVGQk5qU3lXdDMxdjFwU1RWZDhGVDdGWGk3?=
 =?utf-8?B?bnRHQmlxYkhNdTRUbmNuUFh2WEtWWSt3WHA5RENmSzlxcEYzZzFzUkZFb1cw?=
 =?utf-8?B?c3hwVk5kVDlpVHdJaGZxdWdaeG5IeFBwMVhHWHFhR0dOanVKMW9aNkV2MkRU?=
 =?utf-8?B?WGl4OGtSSlVzVEM0NXc3QjRhN2ZyR1lxUWRLeWl6QVo0K2FicE5KMFJZMnFw?=
 =?utf-8?B?L3BYT3hxenZ4WnJHeUVNQkROMWhrUGZTVmdJeVFlUmlwc0x0a1NEeHlLWXln?=
 =?utf-8?B?bXU4ZExNaTZsNlZlTTdtWnRlRmh4NVhvQVNMTkxzSi9ZVXphNGQxVDd1T1g2?=
 =?utf-8?B?d0RLcngrcUJkWHg2L3o5cjRPS2IyRDViWFMxcUNnRVplQ1cvMmVzRGgxalBj?=
 =?utf-8?B?MjdNYUthQzJ0Rk5SczhLNVN4ZWFIRHZld0N1WjRvOE0rUnRyVDlqVFZsSzVs?=
 =?utf-8?B?RStFZFRrazFPd0k1NHNOdXJKaWM4ZEExM0E3ZmlGbW5qSEdGYjFnRXFVaGl4?=
 =?utf-8?B?V004VmJrUzZCUWhGMVc1SUZIbS90ZTdvaGlGMnRnQklocExGU0R5R3c2akdh?=
 =?utf-8?B?TUJlTVpzOUlMS1lweTlTRWFVM2I4NTErTm1uS2h3cUpWV3FIU0pOTkF5VG1V?=
 =?utf-8?B?WFd1eGFxNEs0V3NmZXZoVm5RN0RsS2E5cXJ1clBDUmNMZDhQQXJJWUFMaWZi?=
 =?utf-8?B?aU1meTM4b08wWHBTWlhXUEdMS0U0WjVCb0llTFp5RmlKV3dUYXhRUHE5Qy9x?=
 =?utf-8?B?UFlBL3RCM1ZUYUh5MnFGa2QwUXhEWDZSbGd0UHc5a1BWbTV3cWZDNUUyaG5o?=
 =?utf-8?B?NWNMb2IrMWZNVTcyeE00NUFMaTNLOXVUeDhJK1RiSXhxb2xJSkQwTXFHZmcr?=
 =?utf-8?B?WnpiT0dxN1didnZ0Qml2eWI5Vit6azlVZzliZVBYdEJNS1Z2UncwQytIdnNG?=
 =?utf-8?B?aDlzbi8rb3ozS25tZGlBdnovOEpiMkhRWURUYW9lWUF2bzdKZVZUZ2hIVlRV?=
 =?utf-8?B?N1doWTVIancyQ014VENWeitkSGI5TnM1bXRTYlNWRGxXU1RKOVdVcklYQlhk?=
 =?utf-8?B?UExxcE9rMjV5QTR4QUw1a0RJM0hzQ3Q0K09mWVNWZ2VBVUxpTHBsUGlTTElm?=
 =?utf-8?B?NkI5UlpYMkMwaHdnNlhDcnVMeW9PZk5kUE4vMlRicDNWc29Bb0xXZitVeVFE?=
 =?utf-8?B?MmFjMjlxTVpmdDJtOHJJNURLMjBkTEdubStqTWFqa24xMUxaMXlCbml1c2t4?=
 =?utf-8?B?MExuVlhMWVVnSm5paG9wQUlac3ZmYWdKZ1N2czMvZjgyUWllU3c2YzVIRjNE?=
 =?utf-8?B?LzN0YllpY2UzR0UwczJvM2FxUDdIYjUxZUZXSDN1VTlqdXJNczEwZEpTRjBq?=
 =?utf-8?B?SStRZDY3Rk5ETUlkaXhaTm1oWThwWWRwY0g0cVZOdTdiVFlFc1VzaVIyWVV5?=
 =?utf-8?Q?tYfI=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <66265326C4D7624C82B6F82D40214E28@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 54bc5ffb-6f4b-4bea-53f5-08dd8d116c59
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 02:46:52.8059
 (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: f+b3FheMaA7Do/OWthHznVzQwpgntj6uLmKKUkgA1uSk9ft3wHpokpxcTfv1biHive4Flq14veaBALo6Q9ftig==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4404

T24gMjAyNS81LzYgMjE6NTAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgQXBy
IDIxLCAyMDI1IGF0IDAyOjE4OjU1UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gQ3Vy
cmVudCBsb2dpYyBvZiBlbXVsYXRpbmcgbGVnYWN5IGNhcGFiaWxpdHkgbGlzdCBpcyBvbmx5IGZv
ciBkb21VLg0KPj4gU28sIGV4cGFuZCBpdCB0byBlbXVsYXRlIGZvciBkb20wIHRvby4gVGhlbiBp
dCB3aWxsIGJlIGVhc3kgdG8gaGlkZQ0KPj4gYSBjYXBhYmlsaXR5IHdob3NlIGluaXRpYWxpemF0
aW9uIGZhaWxzIGluIGEgZnVuY3Rpb24uDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogSmlxaWFuIENo
ZW4gPEppcWlhbi5DaGVuQGFtZC5jb20+DQo+IA0KPiBTb3JyeSwgb25lIG5pdCBJJ3ZlIG5vdGlj
ZWQgd2hpbGUgbG9va2luZyBhdCB0aGUgbmV4dCBwYXRjaC4NCj4gDQo+PiBAQCAtNzg2LDEzICs3
ODcsMTUgQEAgc3RhdGljIGludCB2cGNpX2luaXRfY2FwYWJpbGl0eV9saXN0KHN0cnVjdCBwY2lf
ZGV2ICpwZGV2KQ0KPj4gIA0KPj4gICAgICAgICAgICAgIG5leHQgPSBwY2lfZmluZF9uZXh0X2Nh
cF90dGwocGRldi0+c2JkZiwNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHBvcyArIFBDSV9DQVBfTElTVF9ORVhULA0KPj4gLSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkX2NhcHMsDQo+PiAtICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBBUlJBWV9TSVpFKHN1cHBvcnRlZF9jYXBzKSwgJnR0
bCk7DQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYXBzLCBu
LCAmdHRsKTsNCj4+ICANCj4+IC0gICAgICAgICAgICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHBk
ZXYtPnZwY2ksIHZwY2lfaHdfcmVhZDgsIE5VTEwsDQpUaGUgc2FtZSBoZXJlLCBOVUxMIC0+IHZw
Y2lfaHdfd3JpdGU4LCBJIHRoaW5rLg0KDQo+PiAtICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBwb3MgKyBQQ0lfQ0FQX0xJU1RfSUQsIDEsIE5VTEwpOw0KPj4gLSAgICAgICAgICAg
IGlmICggcmMgKQ0KPj4gLSAgICAgICAgICAgICAgICByZXR1cm4gcmM7DQo+PiArICAgICAgICAg
ICAgaWYgKCAhaXNfaHdkb20gKQ0KPj4gKyAgICAgICAgICAgIHsNCj4+ICsgICAgICAgICAgICAg
ICAgcmMgPSB2cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2cGNpX2h3X3JlYWQ4LCBOVUxM
LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvcyArIFBDSV9D
QVBfTElTVF9JRCwgMSwgTlVMTCk7DQo+PiArICAgICAgICAgICAgICAgIGlmICggcmMgKQ0KPj4g
KyAgICAgICAgICAgICAgICAgICAgcmV0dXJuIHJjOw0KPj4gKyAgICAgICAgICAgIH0NCj4+ICAN
Cj4+ICAgICAgICAgICAgICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lf
cmVhZF92YWwsIE5VTEwsDQo+IA0KPiBGb3IgdGhlIGhhcmR3YXJlIGRvbWFpbiB0aGUgd3JpdGUg
aGFuZGxlciBzaG91bGQgYmUgdnBjaV9od193cml0ZTgNCj4gaW5zdGVhZCBvZiBOVUxMLg0KT0ss
IEkgdGhpbmsgSSBuZWVkIHRvIGFkZCBkZWZpbml0aW9uIG9mIHZwY2lfaHdfd3JpdGU4Lg0KQnV0
IEkgaGF2ZSBhIHF1ZXN0aW9uLCBpZiBoYXJkd2FyZSBkb21haW4gd3JpdGUgdGhpcyByZWdpc3Rl
ciB0aHJvdWdoIHZwY2lfaHdfd3JpdGU4LA0KdGhlbiB0aGUgIm5leHQgYWRkcmVzcyBkYXRhIiBv
ZiBoYXJkd2FyZSB3aWxsIGJlIGluIGNvbnNpc3RlbnQgd2l0aCB2cGNpLg0KSXMgaXQgZmluZT8g
T3Igc2hvdWxkIEkgdXBkYXRlIHZwY2kncyBjYWNoZT8NCg0KPiANCj4gVGhhbmtzLCBSb2dlci4N
Cg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Wed May 07 02:50:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 02:50:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978112.1364970 (Exim 4.92)
	(envelope-from )
	id 1uCUre-0006BR-Tt; Wed, 07 May 2025 02:50:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978112.1364970; Wed, 07 May 2025 02:50: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 1uCUre-0006BK-RG; Wed, 07 May 2025 02:50:30 +0000
Received: by outflank-mailman (input) for mailman id 978112;
 Wed, 07 May 2025 02:50:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCUrd-0006BC-Ub
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 02:50:29 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20602.outbound.protection.outlook.com
 [2a01:111:f403:2415::602])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 087cf8cc-2aee-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 04:50:28 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SJ1PR12MB6266.namprd12.prod.outlook.com (2603:10b6:a03:457::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Wed, 7 May
 2025 02:50:19 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8699.012; Wed, 7 May 2025
 02:50: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" 
X-Inumbo-ID: 087cf8cc-2aee-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nQft6yhcAAvpAlK8aBfQ+g2eljX+QhigfH/XYjHHeGyzSickQnK8qesxsry/LqAFPYSiBBG4ZQPdg6P77ozYe4RfW11CYOkgLXHmABo7DEAj6o4p9BdAwW5TS7GLVEUiono5w/iFSz0DaQ3fpG3TAdtmSQYpwAThe0lq9dgUdZuB7okym6Zev2bRpDD1VAsM0BWM3CyqKK3ziRtYqfqNcHAkgaUufa615D4smjOIyuL3CGG2HD/zPSGbI6tHgfTsPLrH2WLNZ6704//7jXrb6Fq5HbAtTR6cMgiYKYV/p8XN/MjmWVWy17oU0RUpIeTPYor+Weu6r2JokI4EYuueIA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KhQ+or2CjMpMGn7G1uA69vlG590bZ040e5Cz/LDHhaY=;
 b=iAxQaVhB+q07P2yIBFhpmZwCwVb1WEDwzHYw5LD3VMz/94C0GmbB40x1MHLtae0u8FDkClaFIaD9DsPIhXhyvPnj8OqnTn2PefcoC4YY5Si/c3VRiwLpGfyqjpOPX712r5eWFh+x9bEBsS6dJ9D05zPpGd2V8bSINVTGwhYFwt2UlEI/V8H1AM3+TNg9qdAsLUCWEy0R9DB9pEzDQtY0kDRwxhWMFN+2YbAO6bOvbBhcw1uU4VLtvzNShGdbbvUb9D+OlYSucF5CSu8vMUyZbZt4jrTMM+D1NtyZI49sswrzCFP8A+dpWnJeJdUK4QTV+TPDNIWA8EnISnQNmvE58w==
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=KhQ+or2CjMpMGn7G1uA69vlG590bZ040e5Cz/LDHhaY=;
 b=H5T+GXopw03ZXbrPkZxiYSJ5Dkyyq4uWtHIVwgf/5YWNtvJvmcjEukh6FY6g/cHuBacdMKHGm3OSudFXydEsRKaP3SwQ2fbcDDKo1oII2+Q9hgsRaq4dPZkNnbX0mFOd9mEExKbI+Gy7rlmOLIe+vtqQ1FGxJ4XWQMUazfhV/Io=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v3 03/11] vpci/header: Emulate legacy capability list for
 dom0
Thread-Topic: [PATCH v3 03/11] vpci/header: Emulate legacy capability list for
 dom0
Thread-Index: AQHbsoVY0As/JNC0IkWc2g8aH+9wh7PFtqAAgAFbx4CAAAPaAA==
Date: Wed, 7 May 2025 02:50:19 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-4-Jiqian.Chen@amd.com> 
 
In-Reply-To:
 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8699.005)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SJ1PR12MB6266:EE_
x-ms-office365-filtering-correlation-id: c16f5310-c8d0-4538-2317-08dd8d11e764
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?eklvVHBna1BTV29uZ0pibWl2cVkrNWM2QWVBNHE4WUN3RnptMkZDMXFBL2di?=
 =?utf-8?B?bWNyby9aOXVPUzFTMjl5bW9kVURlMXltaWFvZ3AvUHFmK1c0Zzlqdnh4QUEw?=
 =?utf-8?B?NWhWdVV5blJTa253OHRSVmFBcHdtUFJUSFF5eGptZVdPMjdXS1R3Q3R0R3pk?=
 =?utf-8?B?dHJubGZwbGRNL09NK0h5RWllbGppVG5sK1ZxVDUyTGVCVG5GRGhjQjlKWFRB?=
 =?utf-8?B?Ymx1N0dWa0tnR2VjY1oweWY4MzVFYi9EYWtlUW81YkVKeEhENkZSZTVUV2E0?=
 =?utf-8?B?U0lkbDVGcm44akJLYXlRcGNHNlM1RFNUcnBjeFJ0ZUZMOCtZN2k5QkNGUUpP?=
 =?utf-8?B?YjAxUEpqQ3QxQmhMVUlnNkRCdjJQTjdYNy96YjRqZXpYS3FmUEVVd1NULzRt?=
 =?utf-8?B?VFlXNitFQ3Jicnd1UXZwN1FFaXJTMXJldnJyQ3ZBWnZYUUFBd1d5UW01UEtP?=
 =?utf-8?B?TExjeTIzRTduMVBnaFliNEZTWklrOHU5QUVmZ04xVllHVzgybms4Szg5cERJ?=
 =?utf-8?B?dHVLZ3kvaVVSSVVyeklvOWNZY0dvRTNaVDBvekhFRlpjZlJSYzVCTlNzWHFD?=
 =?utf-8?B?dWdwNHRqUWZiMTlKRDdSVnZpSGZJYkpPWUNUcFgydU9WVlp6aXo3c3J3aVlK?=
 =?utf-8?B?QzRKUGkrOE05Yk9oM1hUdEUzWlowVFZIaFFvRUpreEdDMjQwN3hENytHK21j?=
 =?utf-8?B?RkRnMXFVK3pVSHpCMS9Yd254MEpKSk1LRGpDczBpYW9UdFpyZmI4Q3JZNGRI?=
 =?utf-8?B?TUtJdURwV2VZZGJTN3ZsUk9GWFB3ZzVLeCt3bmpCYW5PRWY4djFmK1NNL1pQ?=
 =?utf-8?B?MXVrcWgwd3hnYjRQUDN3aElSNW5CZytiZWpRbVMyUkVDV3FIRjg0L3BpRFpL?=
 =?utf-8?B?VWZ1NHNKeXkxbUtMQ0t6alBMTitzN24zWlFuQkFLN1FTVkl5M2VlUk1KTEhn?=
 =?utf-8?B?andyVGh3N0tqcEJOVExwYzQrZjFlanFISUUzcytqZkt4dlBjbHRBZVhDdEQ5?=
 =?utf-8?B?OGhYRDRnejRQWVJtMTRhT2wrMzF4cisxUDRqNEtvVjVEM20xcEZuSFhla1Y2?=
 =?utf-8?B?bGluZ21Ia3h3WThZVDgvaUQ5L3Flek5QREJDQ1gxWTNLRGhtWTV0RWNqS0hC?=
 =?utf-8?B?M2FXRW5GM2liNXdEM2lCazlhbnJjZTRKTmN2YURSN2w3bTNDWVIvOWZ6WnJD?=
 =?utf-8?B?Vmt1MXF5YUcyRzl0VEtyN3NyQjRlMUUxK09lUUhtZkxJYW9uZW5vUmNsOW5Q?=
 =?utf-8?B?VGVWaW9GVTZMNmJxQzlYZDgzcWJMYkU5ZGpyekl2ZDc4OW1URTVicEt1RHlD?=
 =?utf-8?B?ajNTRHVVa3FDTkRBTkh1ek1WRzFubkQwUDgzcHVHTzBYL3pEaW1JU2tCV1VV?=
 =?utf-8?B?am5seTNpWno3eW9LcGdOeEdzUEZjRmUxWFg0a2gzeUNCd1h0eUljSXFlMHlU?=
 =?utf-8?B?QmdpV2VBM2tKTE44N0pXQmZsR1hEdElMRmlXT1hCTmRraXFhdmMvQjhna3Ux?=
 =?utf-8?B?b05qS0RrTGhKNG1rWUZwWXoyOEZDcGZuQURPb1NnUUdnTDltNE5uT1kyclRP?=
 =?utf-8?B?TmpsQkp5aTN4S1J5RXE4SmRSemM3SEFPY3cwM2N5QzdKRWg4NExlZlp5UUpy?=
 =?utf-8?B?elo4alJocytQWkErNGZLNzhTVHhhRm4zeWhib0pvRzlFaWNHNTZhdHp0UmdU?=
 =?utf-8?B?SHlwSFQ5a0tzM2w2cjNrc1lucHk1SWJsVk1PeStnaFkyMUVydUR2VW5QL3lq?=
 =?utf-8?B?cWlsM2dpMThMRkpvMnJ0dVFkclJUWFJFMnZHN2hBYUExSHUzODF1YXhqT0NR?=
 =?utf-8?B?VkVaaTZuK1lBV1R0bDFJT1NLVjRMbG1xUmorVFdYb3RxWHl0VnJzU2l3a3M1?=
 =?utf-8?B?YXVIcWVQMmlLQXkwODdIK3R1dWFaWXowTDlVNExwdVN3L0dReTZoMnI1MjdU?=
 =?utf-8?B?azFRNDNiSEEwSnNPMHRiNU1Xczl2WEN2TVR4aUZZUEIyS1pjR09vL2owY1pB?=
 =?utf-8?Q?nJV3J15UW3TMTxlR66xCm63XyDE1z4=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WDEyeEdNT0M1bW80WVdKYW45N0xnV1hpK2JUbmVnbDU2UysxdXkxSUZOc1Er?=
 =?utf-8?B?YnZSVUxueFhkb0lVUnVxZklBNDRCb25aVjJmeWRYak90RG9WaEx5YStBOXhh?=
 =?utf-8?B?K1VTZVdyOUpKWk5QcmxZbVA1NjIzbGlOWWppSGgzZkVTOURIL2lSVUFma0w3?=
 =?utf-8?B?MzRmZWdzUWhEK2NZYnhkWnNjZ0d0NUxGVXA4dTlEc0pIREVaaU1kQ0xTcE5j?=
 =?utf-8?B?TjcvR3lMZXVzZjlDdEVyRTNMbFZxQm5PWm1vSm82dzFkbHVxKzAza0hRNS9x?=
 =?utf-8?B?UFd3NHVCTkcrOHhWUVFjOUNQcUNaOFNDRDl6SVorVGpWcDhycThqby9Vd3NQ?=
 =?utf-8?B?QTdJNjVqQnE5bXlwbGYrRUc3aUErQVVaRHVZTzR2a2M0aEYwQ3FZRnBUVTVs?=
 =?utf-8?B?L3J3Sy9ja3luK0hoS1BKbnhBeExiQW9MR1VlLzM3NkpBcldNYm1HaXpDUWF3?=
 =?utf-8?B?b21GOTNxTDhWMWZrTk5UNGlmQ3ZBK3Z2N3ZISzV0Z3BDN2xmVlBraS90ZWMz?=
 =?utf-8?B?VzNSV081Y3hBdVdPNDVpem1FVzVEdmVhVDVVTU12Zmp4MWQ5bGVNTGdsQ1Ro?=
 =?utf-8?B?MTlneFU3NWhlVTV4K1ZhNUdpdEVHSzVWbTllY1pUS1BxaTBhaGRjUHZkSmRp?=
 =?utf-8?B?UHgvVDV3eVI0YXR5WnRqakpWVkMxTXBjVmdoZE9JWHdnVjhvRU1TY2pIdDAw?=
 =?utf-8?B?NHVReFdDS2lyaUZCckFCYm16NE5uenBad0ZERXdZOTdYRHFDWUt6ZC92OUI1?=
 =?utf-8?B?eXR5cy92TFd2U2hhWDBLd0duVFhzeXZzMUNJSlRFbVl3M0Q0RlBDeFNoRUZY?=
 =?utf-8?B?bzdFOG0yaU5hcjdmOVJ0WXNDa25WZjFoRVlJbHlWR2FmUE9YZ29ZeUw2TTRq?=
 =?utf-8?B?SzlsdDBEbFl1cUhTSVgweEQ0TmVjTk9NWXJadkNtWnQ3cUJ2NnBmZUFtUUFN?=
 =?utf-8?B?UXZ0blBSeTk2Tm8wWjQxVVhaTkllMk82Mml3K0JiZmRDOTVjNEhUZzJoajZz?=
 =?utf-8?B?a1NsTTh3WGJHV05TRWdYbVVPQldjTmltQU1jZk56WkttYkdSa2VOZE1ha3pj?=
 =?utf-8?B?azRZYm9vUjB1YmU3MEF0S0I3V0YvZUREZHpZVWswcWhHK2p0cWZkeHpNQTdB?=
 =?utf-8?B?TGlrQnlpa3N2a1lqQWoxTVgxUjVmSmhETnF4VndNVDQydUxyU2UyMkZIS09s?=
 =?utf-8?B?WXNuVzlXYk55clJsVWZJMmpXOVZFQ0VTTG1xQm5rajhuaE9mUGI5RitRbHlj?=
 =?utf-8?B?SElZR1JxZVg1aDVJYmw0OWV3bGhEcmFRUFFSaGNwTXV6bHp0dUxwV3VoRjJM?=
 =?utf-8?B?UjdKZUdrTjFXQmNUbWJKS1N0Yys3eWV1OVJneFBVVjAxd0RKeWZxYmZVS3hr?=
 =?utf-8?B?QU9WRmQwejdta0UwWlRyQlhicGt4MS96MkxUK2RHV3M4dDdaTkx4SHlQQTlk?=
 =?utf-8?B?d0xpQzFhYVNtcTRJVnBrbncrZDVCUFU1aGl2MWlPOFFQenVHUnlmNmREcnZU?=
 =?utf-8?B?OUdkVDNRYUo3SDBPWHJnNFlKTzVQUzhPMmxVZTQ1cW1RUzU1ZlRZRlpWWG1j?=
 =?utf-8?B?K1hDS3ZuWXAwRVFOQ3VSQUFsYVRzVUpheG1rMGk3bkVVVGVBV0FHYytiRXRC?=
 =?utf-8?B?QjdDRkpFRUVadTNjTE5FYkFuUlBuQlZqdEFmVHRiQmRuRElMVENlVC9pSkhM?=
 =?utf-8?B?L2ZDMysrckFQVlUxS01nTFlhSWJWZUpHbzhqQ2x4OFN1WmRZZ0V0bkVmRDAx?=
 =?utf-8?B?eGpxL09sSy95ejZBaUdqcGFHcHFiTjFqUzBGaEJXZWd3Vk5CRWVwTGxTRUNj?=
 =?utf-8?B?QktvS2NTUlNnTEVJSDJ0V1BId2cvU2RYZVV6ZzJlMkcrajc2Sko5dWsrM2F3?=
 =?utf-8?B?Yy80bnV0Y1hwUTJMYVJkSnJ2MG5IN1VZaVVsOWdJSlpDMGVtYmtnVy8rNjFL?=
 =?utf-8?B?Um1Md2tKWVF2YTliVUVybVBvQkVVSHdvNThOTE9IZUZlaGhmUGNuYWpTR3FL?=
 =?utf-8?B?V1lYKzl2aTdQR0R6azUxZy9oWTEwdWk0Tk12VWhUZWhwYlJ2VmJkM0craTdF?=
 =?utf-8?B?c1RGQW40UmlIUE5zY2JhTTRWUTRRQ1VTM1NXSGhLR3BSTi9tcUNtbXh0akZ0?=
 =?utf-8?Q?9QBA=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <1E874C84B3E4FB4CAD1DDBECCF0EC189@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c16f5310-c8d0-4538-2317-08dd8d11e764
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 02:50:19.2009
 (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: Cy4RyCTkVHtkGVKEEZeyqF+jP5UEeKbgqkNHrcGTpI6ZLrO2l9uj1iNCBZyPMMpCA/U1jrtWePFtoXExmI2dxA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6266

T24gMjAyNS81LzcgMTA6NDYsIENoZW4sIEppcWlhbiB3cm90ZToNCj4gT24gMjAyNS81LzYgMjE6
NTAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+PiBPbiBNb24sIEFwciAyMSwgMjAyNSBhdCAw
MjoxODo1NVBNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+PiBDdXJyZW50IGxvZ2ljIG9m
IGVtdWxhdGluZyBsZWdhY3kgY2FwYWJpbGl0eSBsaXN0IGlzIG9ubHkgZm9yIGRvbVUuDQo+Pj4g
U28sIGV4cGFuZCBpdCB0byBlbXVsYXRlIGZvciBkb20wIHRvby4gVGhlbiBpdCB3aWxsIGJlIGVh
c3kgdG8gaGlkZQ0KPj4+IGEgY2FwYWJpbGl0eSB3aG9zZSBpbml0aWFsaXphdGlvbiBmYWlscyBp
biBhIGZ1bmN0aW9uLg0KPj4+DQo+Pj4gU2lnbmVkLW9mZi1ieTogSmlxaWFuIENoZW4gPEppcWlh
bi5DaGVuQGFtZC5jb20+DQo+Pg0KPj4gU29ycnksIG9uZSBuaXQgSSd2ZSBub3RpY2VkIHdoaWxl
IGxvb2tpbmcgYXQgdGhlIG5leHQgcGF0Y2guDQo+Pg0KPj4+IEBAIC03ODYsMTMgKzc4NywxNSBA
QCBzdGF0aWMgaW50IHZwY2lfaW5pdF9jYXBhYmlsaXR5X2xpc3Qoc3RydWN0IHBjaV9kZXYgKnBk
ZXYpDQo+Pj4gIA0KPj4+ICAgICAgICAgICAgICBuZXh0ID0gcGNpX2ZpbmRfbmV4dF9jYXBfdHRs
KHBkZXYtPnNiZGYsDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgcG9zICsgUENJX0NBUF9MSVNUX05FWFQsDQo+Pj4gLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkX2NhcHMsDQo+Pj4gLSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgQVJSQVlfU0laRShzdXBwb3J0ZWRfY2FwcyksICZ0dGwp
Ow0KPj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhcHMsIG4s
ICZ0dGwpOw0KPj4+ICANCj4+PiAtICAgICAgICAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3Rlcihw
ZGV2LT52cGNpLCB2cGNpX2h3X3JlYWQ4LCBOVUxMLA0KPiBUaGUgc2FtZSBoZXJlLCBOVUxMIC0+
IHZwY2lfaHdfd3JpdGU4LCBJIHRoaW5rLg0KPiANCj4+PiAtICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBwb3MgKyBQQ0lfQ0FQX0xJU1RfSUQsIDEsIE5VTEwpOw0KPj4+IC0gICAg
ICAgICAgICBpZiAoIHJjICkNCj4+PiAtICAgICAgICAgICAgICAgIHJldHVybiByYzsNCj4+PiAr
ICAgICAgICAgICAgaWYgKCAhaXNfaHdkb20gKQ0KPj4+ICsgICAgICAgICAgICB7DQo+Pj4gKyAg
ICAgICAgICAgICAgICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfaHdf
cmVhZDgsIE5VTEwsDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHBvcyArIFBDSV9DQVBfTElTVF9JRCwgMSwgTlVMTCk7DQo+Pj4gKyAgICAgICAgICAgICAgICBp
ZiAoIHJjICkNCj4+PiArICAgICAgICAgICAgICAgICAgICByZXR1cm4gcmM7DQo+Pj4gKyAgICAg
ICAgICAgIH0NCj4+PiAgDQo+Pj4gICAgICAgICAgICAgIHJjID0gdnBjaV9hZGRfcmVnaXN0ZXIo
cGRldi0+dnBjaSwgdnBjaV9yZWFkX3ZhbCwgTlVMTCwNCj4+DQo+PiBGb3IgdGhlIGhhcmR3YXJl
IGRvbWFpbiB0aGUgd3JpdGUgaGFuZGxlciBzaG91bGQgYmUgdnBjaV9od193cml0ZTgNCj4+IGlu
c3RlYWQgb2YgTlVMTC4NCj4gT0ssIEkgdGhpbmsgSSBuZWVkIHRvIGFkZCBkZWZpbml0aW9uIG9m
IHZwY2lfaHdfd3JpdGU4Lg0KPiBCdXQgSSBoYXZlIGEgcXVlc3Rpb24sIGlmIGhhcmR3YXJlIGRv
bWFpbiB3cml0ZSB0aGlzIHJlZ2lzdGVyIHRocm91Z2ggdnBjaV9od193cml0ZTgsDQo+IHRoZW4g
dGhlICJuZXh0IGFkZHJlc3MgZGF0YSIgb2YgaGFyZHdhcmUgd2lsbCBiZSBpbiBjb25zaXN0ZW50
IHdpdGggdnBjaS4NCmJlIGluIGNvbnNpc3RlbnQgd2l0aCAtPiBiZSBpbmNvbnNpc3RlbnQgd2l0
aA0KSSBhbSBzb3JyeS4NCg0KPiBJcyBpdCBmaW5lPyBPciBzaG91bGQgSSB1cGRhdGUgdnBjaSdz
IGNhY2hlPw0KPiANCj4+DQo+PiBUaGFua3MsIFJvZ2VyLg0KPiANCg0KLS0gDQpCZXN0IHJlZ2Fy
ZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Wed May 07 03:05:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 03:05:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978129.1364981 (Exim 4.92)
	(envelope-from )
	id 1uCV69-0008Kb-6U; Wed, 07 May 2025 03:05:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978129.1364981; Wed, 07 May 2025 03: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 1uCV69-0008KU-3u; Wed, 07 May 2025 03:05:29 +0000
Received: by outflank-mailman (input) for mailman id 978129;
 Wed, 07 May 2025 03:05:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCV67-0008KO-Hh
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 03:05:27 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2412::60c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f7be73c-2af0-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 05:05:26 +0200 (CEST)
Received: from DS7PR05CA0027.namprd05.prod.outlook.com (2603:10b6:5:3b9::32)
 by DS0PR12MB8576.namprd12.prod.outlook.com (2603:10b6:8:165::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8632.33; Wed, 7 May
 2025 03:05:15 +0000
Received: from DS3PEPF000099E1.namprd04.prod.outlook.com
 (2603:10b6:5:3b9:cafe::18) by DS7PR05CA0027.outlook.office365.com
 (2603:10b6:5:3b9::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Wed,
 7 May 2025 03:05:15 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS3PEPF000099E1.mail.protection.outlook.com (10.167.17.196) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Wed, 7 May 2025 03:05:15 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 May
 2025 22:05:14 -0500
Received: from [172.31.225.170] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 6 May 2025 22:05: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" 
X-Inumbo-ID: 1f7be73c-2af0-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=o7i+HHccn0r67Kg83M1lWF16AKzB409EQR/gIV/1yBZZFTjl8uFz/s2P7cclKbAJN13PHAc8AB1N9UQjqMNYQxNnia83OHYGc1x/xz5Pvj2U1d/47wn6AMnRP2ymiTAJqnbdP3Woadxb3N3lGU+blVSlltiXYgdUYBd2+5ZHI54RQ5WlcNpCsDhkndsHRE/tuSS1oAhg8p45Di06qGZkv6sFAOR4lV9ZLD3FE4M9Hux4JpjE/ZJJN2Wq6SJDq4qOryW/x1NRe4v9zf7wyabyea7qHNR+YgnH48pth8RZ6qzBNUJtSfcPDjZPpQHPU44djOlVdXRfYYaHiKjCZmRmsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IwyhJFY4vesrDhBtFfHi8Dqt7X4llzuSAR5ElpLhNME=;
 b=EpXxGA5CVaO/4j4w0bk4SJ4HUi+iFsJ1VbSW1o9OIB+JDDBek9O9K3UhqTf1WazPRMr9zUhNnXtAsp9LVJYiB3TBvOaf6BuFDGQzJxjcuUFdB7i7GJLhslpt7Wv3pKWKbCHl13HbwQKjAHxtRrWkf1rYpgYcwtGeFybJ4DvpjmN0nrGk/iT64tvd2vV7sXg8UMkaPE7180EQqUWLQnEiq96L8k0Fzqdx2TNnR2Ppp+Ld/5kBkojxigkDYhM4RQXa3lw1CRj9zDANBNhGzYd/IlB8V8PloZG2ptS00MmG+fRLrsfaALxV6OCoclOLlyMxeGT6lcdd+g93YcCgk23pMg==
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=IwyhJFY4vesrDhBtFfHi8Dqt7X4llzuSAR5ElpLhNME=;
 b=4eCrQsGdkRTqjGS/QqXV360vESxY2QU1Zs60BlSwPx6r4EMrXqoiD9LO03ekNyxU8oGno24Q9zzM05h9R2aIpWqxAEE864464cTgaSg/ZwukPybKQDSrad8hSo9ORtmPSBoaz8pDR6wdoOfIdcPAGkfGYu9DUH5ZK/Go0CPWz3E=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <3693f1ef-e305-4a6b-bb4e-3b842418387f@amd.com>
Date: Tue, 6 May 2025 23:05:13 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v20 2/2] vpci: translate virtual PCI bus topology for
 guests
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
CC: , Oleksandr Andrushchenko
	, Anthony PERARD
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Jiqian Chen , "Mykyta
 Poturai" 
References: <20250418185840.335816-1-stewart.hildebrand@amd.com>
 <20250418185840.335816-3-stewart.hildebrand@amd.com>
 
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB03.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF000099E1:EE_|DS0PR12MB8576:EE_
X-MS-Office365-Filtering-Correlation-Id: e5dcb755-8d0a-414a-f89d-08dd8d13fdb3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SWQvS0J4TERWYjZLbVEvSEJPTnA5VzE4UWlGQTFmb3hBNHBQRmxKV3d5NlBD?=
 =?utf-8?B?WC83ZHVQVlRzUG95bGFZTFNMYUlVbkhxWHRza1V6VzZEd041Q1YxM0NLMVk2?=
 =?utf-8?B?Ukt3cFhNR3RCNWdJVDVCNitrVzJINnZxOW9VU1lSZHQrRC9JVGt1akJhVjcv?=
 =?utf-8?B?VDRRRjdxdjJ2YXRFVTAzSC92MFFDZ1hvTmRHYVBOR3ZRbkl6c3pQR0RaVWFZ?=
 =?utf-8?B?c2ZRTUVEYUtEZ1B1bVNGZGlmSFRSTWlpRFFZYnExa0dUYXhES1U5LzFFUVkw?=
 =?utf-8?B?M0QxVjBzNHh1UFpDcEIzM3kvOEYxMytMQXVXRThpNG05MTZXc0RYeEJzcFA2?=
 =?utf-8?B?c3V4WU11SWlHQURhNTR6VkovVTFXdVJxeUxKUFBsM3E4c2RQWWpoeG5LUTU5?=
 =?utf-8?B?ZmZTSU9TaTRoWFFnSEFzRWp2b1RxZEtLbWViSWQyd1d3bWxsR2cvVE1kLzJN?=
 =?utf-8?B?ak0wVTk5djhqV2l5NWh3ckxrQ1JEdmltdUNtUjZUc0VWYjdtQkt5QzkySVR0?=
 =?utf-8?B?MzRLT2J5VXozbDFOZ0pFTU42TXo4bnJjaVlCVG1LcjRIRkJpQkVsTzVHaWU3?=
 =?utf-8?B?YnNCY0k3WERiZzhSMHArMzdpMzJ3dVhPZVYzakQ1d2RDQ2ttK28vcXo4S09J?=
 =?utf-8?B?NFNhV2xoMlpsdlFMNy9VV2lqcnhtbjNyaEc5UmhtL1BtRnRTbVVZUnJSQ1pH?=
 =?utf-8?B?a3FCTkxVRW5qOE9hNzdvRjRJZVBwOVY3NVd3U0g2WFRlNnhTNmxZZE9MdXdX?=
 =?utf-8?B?L0liemZrRzhqbGR5Mit6K2V3SEZvbmNSbmNBYUQ1VzYwT2Y4K0ZSa3dBd3dN?=
 =?utf-8?B?V2tpUkIwSHhJbkRQR3U5djRjVmF5UmQxT3RFNU1Helg3dmJkWkl1eVVGRXNC?=
 =?utf-8?B?ejJqVXZJWHhKL05JRXI0eHFSYlJsVFJBaS9mQ3F5QkNSejd0c1JGRVpjUEto?=
 =?utf-8?B?VjI1YWhFS3pIRU5yZE8xRjFQdDNMczFmM05DNGtUL0NVY3pCZDl0aExpWU5i?=
 =?utf-8?B?TzNyeXdSZTFHMkJXSnBpaXpDdzNBaWFpQWdWK3J6djkvdGJ0U1VpN2RzWWFu?=
 =?utf-8?B?QnZFZys2RHRtWEs4eDQzL3FtMnpLTzBIZmVEeENlK2htanhnQ2c2dk5CRWZh?=
 =?utf-8?B?OVhKWXZtcnBQT2htL2swQjZZRXF1eVBKQlYvZG4ycmt4aWd4MUxWWEJZR3Vh?=
 =?utf-8?B?U0gxYmZWakRqd1VJWmQ4UWxNNURXOXZXcmJQblpRSCsycHBZbWVxeFFnTHN1?=
 =?utf-8?B?U2crcGJsblEvTU05clo4MXlTSTlFOHRpc2J4MVZqNVBsam02WXVkVXhud0VT?=
 =?utf-8?B?YkE2Snc2TDN6Tk9qWlNFSG40a1JjVFVGUjE3c3Q2TGUxQ3lyZlpRd0Q3dUR2?=
 =?utf-8?B?S254c2F1dEhFNzB0ZStqRDUrRWcyY2pFRDBaSjFLeUU1cHpSUXgyYjN4dGQ4?=
 =?utf-8?B?Vm9LUnJ2YTVwTnJJZUVibUVEL3FNcWl4d0hadVB1M1NlUXZpK1hRd04wL1Zx?=
 =?utf-8?B?dS9GRDJBTU9Md1FwbkYweXU0M1hNUGFmY2g2Rm1YYjZneG42cnJJUmZndEYz?=
 =?utf-8?B?MDRoWGJqRjJpSnZsaysySVRPUjJGaExnWnRNNlo5ckNGYWNSNXdpb3lRRGRN?=
 =?utf-8?B?S1NZVXc0djhjb2NWRUI5MDM2QjhNVkY0VkF5bGRjVUwwYjNHV2dFZmJOeG5t?=
 =?utf-8?B?Z25qOXFuSEl1RytBUmlMbnppVzZ0eTFmZlJRL21Yb2Z4Y0ZqUFpXNE4rUGs2?=
 =?utf-8?B?NkZSMDE2SVNvdHB2UCttRGE4Kyt5U0hGYXVLRDUxU1VraEMwMUl5ci9DcTlq?=
 =?utf-8?B?NDNpbXpCdm8yd25mY2F6a2ZwTjd1VG92S1c2Mmd3REphVVhEUmIwNGw2R0ZS?=
 =?utf-8?B?bm1lUzRpckhYWWw3dmYyZ0o3MVZnUVhobks4UFJHMHAzN0FVSkpuNlgvYnhG?=
 =?utf-8?B?bmtGaVp5NmEwaGlGckNQWTI1N2psY0JISThMNndmOUQ3dkFKdEVLWWVxWlB5?=
 =?utf-8?B?QXFYMlQySlhvRDVWdW1DMGN0QVNOTHhPN0l2MzBzcC8yR284YSsvTDNLRkFo?=
 =?utf-8?B?MWYvQlVEbjBweVZQcjRqdWpHRFZ2MVY1R0FFZz09?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2025 03:05:15.5799
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e5dcb755-8d0a-414a-f89d-08dd8d13fdb3
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF000099E1.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8576

On 5/6/25 07:16, Roger Pau Monné wrote:
> Hello,
> 
> Sorry I haven't looked at this before, I was confused with the cover
> letter having ARM in the subject and somehow assumed all the code was
> ARM related.

No worries, thanks for taking a look.

> On Fri, Apr 18, 2025 at 02:58:37PM -0400, Stewart Hildebrand wrote:
>> From: Oleksandr Andrushchenko 
>>
>> There are two originators for the PCI configuration space access:
>> 1. The domain that owns physical host bridge: MMIO handlers are
>> there so we can update vPCI register handlers with the values
>> written by the hardware domain, e.g. physical view of the registers
>> vs guest's view on the configuration space.
>> 2. Guest access to the passed through PCI devices: we need to properly
>> map virtual bus topology to the physical one, e.g. pass the configuration
>> space access to the corresponding physical devices.
>>
>> In vpci_read(), use the access size to create a mask so as to not set
>> any bits above the access size when returning an error.
> 
> I see this here, and the code below, yet I'm not following why this is
> a requirement for the code added here.  It seems like an unrelated
> change?

See below

>> Signed-off-by: Oleksandr Andrushchenko 
>> Signed-off-by: Volodymyr Babchuk 
>> Signed-off-by: Stewart Hildebrand 
>> ---
>> In v20:
>> * call translate_virtual_device() from within locked context of
>>   vpci_{read,write}
>> * update commit message
>> In v19:
>> * move locking to pre-patch
>> In v18:
>> * address warning in vpci test suite
>> In v17:
>> * move lock to inside vpci_translate_virtual_device()
>> * acks were previously given for Arm [0] and vPCI [1], but since it was
>>   two releases ago and the patch has changed, I didn't pick them up
>>
>> [0] https://lore.kernel.org/xen-devel/4afe33f2-72e6-4755-98ce-d7f9da374e90@xen.org/
>> [1] https://lore.kernel.org/xen-devel/Zk70udmiriruMt0r@macbook/
>>
>> In v15:
>> - base on top of ("arm/vpci: honor access size when returning an error")
>> In v11:
>> - Fixed format issues
>> - Added ASSERT_UNREACHABLE() to the dummy implementation of
>> vpci_translate_virtual_device()
>> - Moved variable in vpci_sbdf_from_gpa(), now it is easier to follow
>> the logic in the function
>> Since v9:
>> - Commend about required lock replaced with ASSERT()
>> - Style fixes
>> - call to vpci_translate_virtual_device folded into vpci_sbdf_from_gpa
>> Since v8:
>> - locks moved out of vpci_translate_virtual_device()
>> Since v6:
>> - add pcidevs locking to vpci_translate_virtual_device
>> - update wrt to the new locking scheme
>> Since v5:
>> - add vpci_translate_virtual_device for #ifndef CONFIG_HAS_VPCI_GUEST_SUPPORT
>>   case to simplify ifdefery
>> - add ASSERT(!is_hardware_domain(d)); to vpci_translate_virtual_device
>> - reset output register on failed virtual SBDF translation
>> Since v4:
>> - indentation fixes
>> - constify struct domain
>> - updated commit message
>> - updates to the new locking scheme (pdev->vpci_lock)
>> Since v3:
>> - revisit locking
>> - move code to vpci.c
>> Since v2:
>>  - pass struct domain instead of struct vcpu
>>  - constify arguments where possible
>>  - gate relevant code with CONFIG_HAS_VPCI_GUEST_SUPPORT
>> New in v2
>> ---
>>  tools/tests/vpci/emul.h |  2 +-
>>  xen/arch/arm/vpci.c     |  4 +++
>>  xen/drivers/vpci/vpci.c | 73 +++++++++++++++++++++++++++++++++++++----
>>  3 files changed, 71 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/tests/vpci/emul.h b/tools/tests/vpci/emul.h
>> index da446bba86b4..dd048cffbf9d 100644
>> --- a/tools/tests/vpci/emul.h
>> +++ b/tools/tests/vpci/emul.h
>> @@ -89,7 +89,7 @@ typedef union {
>>  
>>  #define __hwdom_init
>>  
>> -#define is_hardware_domain(d) ((void)(d), false)
>> +#define is_hardware_domain(d) ((void)(d), true)
>>  
>>  #define has_vpci(d) true
>>  
>> diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
>> index b63a356bb4a8..618ddb7f6547 100644
>> --- a/xen/arch/arm/vpci.c
>> +++ b/xen/arch/arm/vpci.c
>> @@ -34,6 +34,8 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
>>      /* data is needed to prevent a pointer cast on 32bit */
>>      unsigned long data;
>>  
>> +    ASSERT(!bridge == !is_hardware_domain(v->domain));
>> +
>>      if ( vpci_ecam_read(sbdf, ECAM_REG_OFFSET(info->gpa),
>>                          1U << info->dabt.size, &data) )
>>      {
>> @@ -52,6 +54,8 @@ static int vpci_mmio_write(struct vcpu *v, mmio_info_t *info,
>>      struct pci_host_bridge *bridge = p;
>>      pci_sbdf_t sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
>>  
>> +    ASSERT(!bridge == !is_hardware_domain(v->domain));
>> +
>>      return vpci_ecam_write(sbdf, ECAM_REG_OFFSET(info->gpa),
>>                             1U << info->dabt.size, r);
>>  }
>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
>> index 1e6aa5d799b9..fc409f3fc346 100644
>> --- a/xen/drivers/vpci/vpci.c
>> +++ b/xen/drivers/vpci/vpci.c
>> @@ -174,6 +174,41 @@ int vpci_assign_device(struct pci_dev *pdev)
>>  }
>>  #endif /* __XEN__ */
>>  
>> +#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
>> +/*
>> + * Find the physical device which is mapped to the virtual device
>> + * and translate virtual SBDF to the physical one.
>> + */
>> +static const struct pci_dev *translate_virtual_device(const struct domain *d,
>> +                                                      pci_sbdf_t *sbdf)
>> +{
>> +    const struct pci_dev *pdev;
>> +
>> +    ASSERT(!is_hardware_domain(d));
>> +    ASSERT(rw_is_locked(&d->pci_lock));
>> +
>> +    for_each_pdev ( d, pdev )
>> +    {
>> +        if ( pdev->vpci && (pdev->vpci->guest_sbdf.sbdf == sbdf->sbdf) )
>> +        {
>> +            /* Replace guest SBDF with the physical one. */
>> +            *sbdf = pdev->sbdf;
>> +            return pdev;
>> +        }
>> +    }
>> +
>> +    return NULL;
>> +}
>> +#else
>> +static const struct pci_dev *translate_virtual_device(const struct domain *d,
>> +                                                      pci_sbdf_t *sbdf)
>> +{
>> +    ASSERT_UNREACHABLE();
>> +
>> +    return NULL;
>> +}
>> +#endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
> 
> Jan's suggestion avoids having duplicate headers, and results in less
> code overall:
> 
> static const struct pci_dev *translate_virtual_device(const struct domain *d,
>                                                       pci_sbdf_t *sbdf)
> {
> #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
>     const struct pci_dev *pdev;
>     ...
> #else /* !CONFIG_HAS_VPCI_GUEST_SUPPORT */
>     ASSERT_UNREACHABLE()
> #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
> 
>     return NULL;
> }
> 
> I've not overly fuzzed either way, but if changes are required you
> might as well change to this form.

Will do

>>  static int vpci_register_cmp(const struct vpci_register *r1,
>>                               const struct vpci_register *r2)
>>  {
>> @@ -438,7 +473,7 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
>>      const struct pci_dev *pdev;
>>      const struct vpci_register *r;
>>      unsigned int data_offset = 0;
>> -    uint32_t data = ~(uint32_t)0;
>> +    uint32_t data = 0xffffffffU >> (32 - 8 * size);
> 
> This seems kind of unrelated to the rest of the code in the patch,
> why is this needed?  Isn't it always fine to return all ones, and let
> the caller truncate to the required size?
> 
> Otherwise the code in vpci_read_hw() also needs to be adjusted.

On Arm, since 9a5e22b64266 ("xen/arm: check read handler behavior") we
assert that the read handlers don't set any bits above the access size.
I had adjusted data here due to returning it directly from vpci_read()
in the current form of the patch. With your suggestion below we would
only need to adjust vpci_read_hw() (and then data here would not
strictly need adjusting).

> And
> you can likely use GENMASK(size * 8, 0) as it's easier to read.

OK. I'll then also provide a definition for GENMASK in
tools/tests/vpci/emul.h.

>>  
>>      if ( !size )
>>      {
>> @@ -453,9 +488,21 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
>>       * pci_lock is sufficient.
>>       */
>>      read_lock(&d->pci_lock);
>> -    pdev = pci_get_pdev(d, sbdf);
>> -    if ( !pdev && is_hardware_domain(d) )
>> -        pdev = pci_get_pdev(dom_xen, sbdf);
>> +    if ( is_hardware_domain(d) )
>> +    {
>> +        pdev = pci_get_pdev(d, sbdf);
>> +        if ( !pdev )
>> +            pdev = pci_get_pdev(dom_xen, sbdf);
>> +    }
>> +    else
>> +    {
>> +        pdev = translate_virtual_device(d, &sbdf);
>> +        if ( !pdev )
>> +        {
>> +            read_unlock(&d->pci_lock);
>> +            return data;
>> +        }
> 
> You don't need this checking here, as the check below will already be
> enough AFAICT, iow:
> 
>     if ( is_hardware_domain(d) )
>     {
>         pdev = pci_get_pdev(d, sbdf);
>         if ( !pdev )
>             pdev = pci_get_pdev(dom_xen, sbdf);
>     }
>     else
>         pdev = translate_virtual_device(d, &sbdf);
> 
>     if ( !pdev || !pdev->vpci )
>     {
>         read_unlock(&d->pci_lock);
>         return vpci_read_hw(sbdf, reg, size);
>     }
> 
> Achieves the same and is more compact by having a single return for
> all the possible cases?  Same for the write case below.

Seeing as there is a is_hardware_domain check inside vpci_read_hw(),
that is okay. I'll make the adjustment here and in vpci_write.


From xen-devel-bounces@lists.xenproject.org Wed May 07 03:18:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 03:18:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978140.1364990 (Exim 4.92)
	(envelope-from )
	id 1uCVJ5-0001oq-BB; Wed, 07 May 2025 03:18:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978140.1364990; Wed, 07 May 2025 03:18: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 1uCVJ5-0001oj-8Z; Wed, 07 May 2025 03:18:51 +0000
Received: by outflank-mailman (input) for mailman id 978140;
 Wed, 07 May 2025 03:18:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCVJ3-0001ob-Mb
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 03:18:49 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20617.outbound.protection.outlook.com
 [2a01:111:f403:2414::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fc494f36-2af1-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 05:18:46 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 BY5PR12MB4258.namprd12.prod.outlook.com (2603:10b6:a03:20d::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.20; Wed, 7 May
 2025 03:18:35 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Wed, 7 May 2025
 03:18: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" 
X-Inumbo-ID: fc494f36-2af1-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tiR4K+Pk6mUi4DsPrGf96swfCyJSgFLEK+H0anzJ3j2YgDNto1Xf4L1F1O8Apl8ua26oWWGCSoWmWtHfV4CAhNpi+S2gILBzNVdiyd43/CodEyBkCYzO4X1OEWTTCJZBBre2rOhzyEgktNBikJqBWBKWH1nBPUj5LtZ7yEToTs1Mch6gnXkI+DN2Ilh47ZrhBlAkWoX9vSVRN5nyXgxd3lA8y3dJmz0zDN6gqz5j6+A74sZIqBK+RqgRjPHpF/TwFMEPEiSvmy3mCvFDXxFSPJtvQlNsrlsc4Zk0RD2m2cJ4/XvIP7GIe2yF5Gax2s10Ta8HrJ7ZfVzqLeiu3QvqPQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=j4EbJu/FAGSnttB2aaGKs5bKrMdrqPMmiF9bmQQVsJw=;
 b=hAo1xigFWDzkaZuHgudBtkHAdyW7zB1FecUNTxZOy2xxX1EsUGxIUEiVqFfGYvSJFY4t9rS2SNOc1+qo7uFxpj3WzbLABU2m5Ko9ysnc5oV+n60FNPAPQwRAcC2h96S8EKblNMrOLvjD7Z5jZDgzcYP7S8rDV0WjppXCrOeEqeA4TCulyqLOC3adwPHzyY6sQpuot8r85XDQboDJ3KJW95Of9UkRfVkO11lN2XHac7MQQeegJ4MQWpZSIFyVS/c7Gf/etEReWJL4yRBz3tsWDmTtrobgKFvRYRuaeEIbI9WszWSAYQGezJf/FhM4V7wru2U7MqxeypODVf8MfMSNPg==
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=j4EbJu/FAGSnttB2aaGKs5bKrMdrqPMmiF9bmQQVsJw=;
 b=ijBszNwpaR9gkvm2mkhPUUZBZeRuqSP1Z2OWhnN/T6sgd794TXUG04/N72RUVdeAs88DwHamwG3auT02Di7MzwTzLjcYnaWbCm24BQRPbH+KAPirLUlXT6Mw/G/LvCoEac/4dmdVxTttTODjhb03zXuRUfmH43S+zcs5Vrd5f1w=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
Thread-Topic: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
Thread-Index: AQHbrRCkbAdH8T2kS0OlR5huTdSxQbO6ixQAgAATnQCADAI+0A==
Date: Wed, 7 May 2025 03:18:35 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-5-Penny.Zheng@amd.com>
 <2f3702f3-a46b-4161-a890-7aad9bbbcac4@suse.com>
 <889d2b2b-db42-43d2-9da0-dcd130d64d9c@suse.com>
In-Reply-To: <889d2b2b-db42-43d2-9da0-dcd130d64d9c@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=6b72dc6f-99e7-4e0d-865e-c550118b6eb9;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-07T03:18:26Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|BY5PR12MB4258:EE_
x-ms-office365-filtering-correlation-id: e8b6d6f4-9a2c-4953-f5d8-08dd8d15da7b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?S1dIZjMzTmZzTVFoMkM2NlBKYTF5N3lrMnVNVmFQM1BDam4wbkJtbStiUXBm?=
 =?utf-8?B?Mi9Na0xmMlc2QzZZWmJTZGNBMHZ0TUhObG9kbVVZUGdHRXo1MkNZL1d5V0xQ?=
 =?utf-8?B?Q0JBckFaL1dTOWNrT2YzOStEZkFnaHdzV1ZMbm9ubFBsdWtnYTQ3SE5YUWxm?=
 =?utf-8?B?OHU3NC92OXcwYmVha0l2Uk1xTVh5QVZ0N2h2VkVJZXl3MjN6L2Q3WHZCWmUw?=
 =?utf-8?B?TitKbHZZMlRTc1Qycy9XNFRvY1hmaGtJZWJ4aDJveHFnUmIxNFdMVUplV2k4?=
 =?utf-8?B?ckxjVWZrb0lFajhMUnMrcjY3dWZ6RjMwUjdFRmRJWnErVFRmTkFDVWZlVjFB?=
 =?utf-8?B?Q3JtbDdzaWYxVks4NDgyWW5WWCtTNlFTY0pwNzU4VEkxK3F1QmNXN3d4R2lm?=
 =?utf-8?B?MndNR2RRYUpiS1Q2eHIrYXNGOVNaN1NUbzlPZ3QxMnY3TzRXRTVIcDJjU2pV?=
 =?utf-8?B?S0lyVVk5WEZwVjYvRDBpelhuZEwzR0ZGY1N0Q3RoQmlUUm92UExXK2g1UHM2?=
 =?utf-8?B?djRsMkwyY0JOdUgrcnpvY2JjczJGa0t4bE5sby9tVmkzWGVQTEErbXFkSVJ5?=
 =?utf-8?B?RjVFUk16MGppM1Z5Rjd3ZzlybDE5OUhsSGlIdUFoOGpsTlpwTEh1TW9IZUt0?=
 =?utf-8?B?NnRDMjduTlVYRm9mamNwQ2J0VDhDdFhiRkpidFExWGxiT2FhTWF5bnFYaGh4?=
 =?utf-8?B?UDVRdkhNN0h1SUVXZFVXT0xzVkx1N3owaHdRd2pzc2hlQTRMZnVGY1YvNytF?=
 =?utf-8?B?NjhtTk41RmoyOFQ3NUpqRXZrOXg1aGw0d2ZSbUxzNEhnYTNXTVc5MFJJdXky?=
 =?utf-8?B?RDlMeDNMSjFTYXc2NE5iWVQxbGtadkd3ZkJkbktPR2ZGUWxGZXZXcHJkZ2xE?=
 =?utf-8?B?VlNBVXJMY1AwYTdHVXdBbXUwZU51V29KOTFxOFp3Y1h0MXZ6SVRTUUtZOSt5?=
 =?utf-8?B?NmVSQjVkKzcrNWlPYU44ejFxMm5XMU5YSXZoeStpbFJSU0hYV25Lak8rZzZy?=
 =?utf-8?B?djVHZHVqc0JWdCs3Y1JGZ0Q5QVVlQVBrVE1zTUVqOTlydCtUandsZmJRM1dG?=
 =?utf-8?B?Ymd3NE5WT2ZkWHBabmJSRENmRFF4aWlyWjNwa1VwbUUwdnBFVnZ2amRaZkhG?=
 =?utf-8?B?eVZZRmdBRStPd1hCSTNPNTF3QVVGZUtMYzdNVTN5VE5BNytUbFBVc0M1dll5?=
 =?utf-8?B?RzByZzk5NTB4aGxROGs1bmJWYTVjeE5ud0thd082YTY1MEljUnA0ZHQ2RzNn?=
 =?utf-8?B?cTJqUGhSVlFEd1F2YnM3ZCt6OEdjY0VpTzNtUGtEQVdNK1FqSlR3eHRlalc1?=
 =?utf-8?B?dnpaY2NxRkpwajM3c3c1b0VvdHdJRlkvd0ZjN1ZVY2IrRUt3aE9oNW9JZ2dn?=
 =?utf-8?B?aytwVGx0QzN6RWl4NzlnZG11S3IzSUVQbnRwMnFUbEQ4VlBDUWxMcUhrZnQ3?=
 =?utf-8?B?MVUwZG9UUGx1cm9hT0huV3hmT0JFVFd0S3VRZDV0VkpUa2VLRzZOYjNWNk5L?=
 =?utf-8?B?Y0duZWVYVGh5U3RjYmFmY3BQQnN3QThwS3lYMk1Vay9tVVlsQzlCblpKWktk?=
 =?utf-8?B?c0czWTJsV0hmREZLZWlvNFMxaGlaV0xKQm5iQks0aFdQZ0sxejFJcUgxNHRD?=
 =?utf-8?B?WTZFOFZyZWRFVWRvbGhndllBMnZHdkRjNzdDOHg2bTJ4Z1h2dU4zVThJNzZk?=
 =?utf-8?B?WXloRjMyT2hDb1FVWnFhd0IwM0xxdFdlMm12YVkxYVJiUFJYR01kaEFOQmZm?=
 =?utf-8?B?OFZkSTRCNTU4TXpZTVpuRVUyUk1XUHdaVnp6cTlNNlRJUWV1TjBBdllDOEhD?=
 =?utf-8?B?N3BuRmRFQjhKL3pxeWwyUjRqa2p1a2NaNmtpZmUrRS9SSHkvQ2RLaXgzdVFO?=
 =?utf-8?B?SWhRU0VucG1ZU095cjRPcDZMUk9aSFVvcG9GK2hGa2hKSmJsMTllKzFhSEox?=
 =?utf-8?B?d0d5ajlVSDh4eHlaUkFhckxYbmR2VXZhYllqY0pQeDFSNWZuZXVIV2tram5l?=
 =?utf-8?Q?ZYy/0YUsAALPGl+dEx/pGziB9h4N44=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?OXZBcEdiYnp6UDk4Ym00MHlFb0ZrcjE1eTF0UzQ0cGl3OWhlenZzWFkrWWtQ?=
 =?utf-8?B?eUQ0aVoxZC8xM3laWEJKT0xxeHlYVEQxWHZ0WmR3Zm93eWZVSmk0ZExuck5M?=
 =?utf-8?B?ZVJZTVFTbk1CNE9PQml4Q05iZ01XK2hiRlk1RUx2SmgzL3ZMaGRtY2hFa3Jx?=
 =?utf-8?B?eHZIb1dwWXQwTFE0SnVybFJUYXpVVk5MdjRmTEp4emRCVjZsdVFlTVBsSTg5?=
 =?utf-8?B?MDh6NmxxYnpPS2djZ3ZWYXkwZE5QSy9aNzJnQ2tDYS9IZ2hmT1VXYWJsaTVz?=
 =?utf-8?B?MnJiQnlRWFBOMzVzYi8xM3VsZnJMSzk4WlNJc2RBaTIyVG1sYWhUOStHRTBX?=
 =?utf-8?B?Q3FhRzdVbFFOWmNDN1QzNnBSazltVkVWOTFxVHRVa1RlcDVmN1hocXFkTk42?=
 =?utf-8?B?TUVwLzM2em9yL3dadlpXeDBqT3liREdVdi9RZ1NRN1hlUzZzZWw3am52Mncr?=
 =?utf-8?B?dEZObzYzUVpBMFZlVEpXRm5IOGppcDIwVVM4ZXoyQVArdHRNbnpXR1BaSmxZ?=
 =?utf-8?B?UWhQcytNTFpZWDlRdEZwWS9IcDFZZ0lERlVaWWd0SEZXd2E2UTVYcGExVi9p?=
 =?utf-8?B?bHRmQzdVeTlmV1BwejlCeHF6end6UWRrdm42ckJ3OFQ2M3ZMVmNKbzV1UTJz?=
 =?utf-8?B?UndhSWxaUEw3bU5UVllUMGl4dkswc2dWVzdrV1NBUUhIbUtwdzVRZUpkemtK?=
 =?utf-8?B?ZVlrZ0tqUTVMTzcvSVQ3RnM1VVlPNVR2aXp2aGh5QWxTUWtSSm9SYlZwRER0?=
 =?utf-8?B?T01xa2FSeUhEUVRDWTMzUzZ2dFpFS3V0NEVHYWJ2Zm1aZC9SRUYyTk5DM2ZM?=
 =?utf-8?B?TFU5Mng4WGFhVktCeEtwU01aczRUaHdWK2ZVS0lmUzlPZ2gxaVBvUmlRNHJL?=
 =?utf-8?B?M3lhaXQ2M01QR2NoYncrcHMwaVpkRm9vMzI0R05sdnQwSVZ0c2hkWVVJbVhl?=
 =?utf-8?B?dGE5MmpWR1B4cGx3eUZRckorUEtNaEljZFZvbWF2cG9nQ1hSYWpscmV3S2tn?=
 =?utf-8?B?OW80ZHF5azdMZ040UXp2aFRuUlNlSXYyZVNFK011elNmZk5VWE5Qa0NOdkJL?=
 =?utf-8?B?eFpHaFVPZWR4aW1NcmsxNFVLdVNSbnJ0ZnFQYXVWcU1ZUHRRd21KeVpxcTU0?=
 =?utf-8?B?YWcrUGQyQVVoS2dNQTlsQ3pnQ2tpeXg5ZnBRTUNveFV3MmFkZ3Z6UHNYcElr?=
 =?utf-8?B?K0MvczhheURKcmFhNWYwaFFLc0U4UHlETHl1VXZYS0NZdjZYVytIbTFVVkN4?=
 =?utf-8?B?OVJmQmJLaEVHUzFZcDBDSWRuOCtMS0lDdkdVRy9QeDk2cDBKaUN3ZHprMTdQ?=
 =?utf-8?B?NEE5aURnM0c1TUR2TUhTVENCa1JvdkZURW55UmxnRTh6WXRGUStJUXplcHo5?=
 =?utf-8?B?akl0TXhUWEJtZ1NaTUZsT3FrU2FkL2Q2QWRZZ2k5ZUlFa1VLOVBlR2hKNk9C?=
 =?utf-8?B?SlpaOGVBRTZKcHpKMWFMZGYxSzJvN2NWVENjT1JId0FJWDg1Y20xbXU1dUdW?=
 =?utf-8?B?NDJ6ZUp4MXVySDJMTHNPbWI3TUg0dzV1ejgrK3Y2c09Na0lpSWwweDBHODJ2?=
 =?utf-8?B?K1JDZUdiOVJZQVdlYzhaMXN1TE54ZU9OYkluNzBZcE04YndaYjFMc0VIdnQ0?=
 =?utf-8?B?WmpZSmk2M3kvdm0vaFdlSXZyMWRZRjQrb0kzcWlmdVE2RFBnQ2FsSWN1cU0v?=
 =?utf-8?B?WDBTUXNOZm9Dbk81d0REaFlyTEI5WjZZZTBVSVZueUV0VE1HZ3R5cHlHV0RV?=
 =?utf-8?B?TTM2QnFzSklJTlIxYUVCM1g4TlgrZENQVi9najJUUk41VGZ0RWRBTmpDZFJa?=
 =?utf-8?B?aG41NENGRjlxaVhzN2twZnZtRjBXN1BWVjhzekQrM21IQnQ5NGQ2M0JuT2Q3?=
 =?utf-8?B?eGpWbVhGWHZzdGNTSWM4enNPNy9pTTBXSnEzYmRGSEgvazY2SFZqMFJLSlI0?=
 =?utf-8?B?MHMxanZWYk1ib2xQNm81RmJIVUp4aTk5TnRhNFBYN0pnTFpzL3hldFdFYjZR?=
 =?utf-8?B?Wi9VUnBiZFA4RTE0QjN0WnJFQnQ4akRPQmVYRVdyMU1nL2k3a2E5ejdvM09J?=
 =?utf-8?B?K0VSQ0hsZk5KV05mb3BhOVJjL2ttMGpGMkhJMFhpOUdlV3h4RDZxT1FObEc3?=
 =?utf-8?Q?tnDs=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e8b6d6f4-9a2c-4953-f5d8-08dd8d15da7b
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 03:18:35.5590
 (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: dA1lhl7KdRZCKo1Fog6EmZktE6+7tcejRa05AFzusWDsZ3B5DUfhmeuab5fmUJYHGuI1vCU3I4XEHcBNrhVkvg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4258

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAy
OSwgMjAyNSA3OjQ3IFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+
DQo+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IHhlbi1kZXZlbEBsaXN0cy54
ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY0IDA0LzE1XSB4ZW4vY3B1ZnJl
cTogcmVmYWN0b3IgY21kbGluZSAiY3B1ZnJlcT14eHgiDQo+DQo+IE9uIDI5LjA0LjIwMjUgMTI6
MzYsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiA+IE9uIDE0LjA0LjIwMjUgMDk6NDAsIFBlbm55IFpo
ZW5nIHdyb3RlOg0KPiA+PiAtLS0gYS94ZW4vZHJpdmVycy9jcHVmcmVxL2NwdWZyZXEuYw0KPiA+
PiArKysgYi94ZW4vZHJpdmVycy9jcHVmcmVxL2NwdWZyZXEuYw0KPiA+PiBAQCAtNzEsNiArNzEs
NDkgQEAgdW5zaWduZWQgaW50IF9faW5pdGRhdGEgY3B1ZnJlcV94ZW5fY250ID0gMTsNCj4gPj4N
Cj4gPj4gIHN0YXRpYyBpbnQgX19pbml0IGNwdWZyZXFfY21kbGluZV9wYXJzZShjb25zdCBjaGFy
ICpzLCBjb25zdCBjaGFyDQo+ID4+ICplKTsNCj4gPj4NCj4gPj4gK3N0YXRpYyBib29sIF9faW5p
dCBjcHVmcmVxX29wdHNfY29udGFpbihlbnVtIGNwdWZyZXFfeGVuX29wdCBvcHRpb24pDQo+ID4+
ICt7DQo+ID4+ICsgICAgdW5zaWduZWQgaW50IGNvdW50ID0gY3B1ZnJlcV94ZW5fY250Ow0KPiA+
PiArDQo+ID4+ICsgICAgd2hpbGUgKCBjb3VudCApDQo+ID4+ICsgICAgew0KPiA+PiArICAgICAg
ICBpZiAoIGNwdWZyZXFfeGVuX29wdHNbLS1jb3VudF0gPT0gb3B0aW9uICkNCj4gPj4gKyAgICAg
ICAgICAgIHJldHVybiB0cnVlOw0KPiA+PiArICAgIH0NCj4gPj4gKw0KPiA+PiArICAgIHJldHVy
biBmYWxzZTsNCj4gPj4gK30NCj4gPj4gKw0KPiA+PiArc3RhdGljIGludCBfX2luaXQgaGFuZGxl
X2NwdWZyZXFfY21kbGluZShlbnVtIGNwdWZyZXFfeGVuX29wdA0KPiA+PiArb3B0aW9uKSB7DQo+
ID4+ICsgICAgaW50IHJldCA9IDA7DQo+ID4+ICsNCj4gPj4gKyAgICBpZiAoIGNwdWZyZXFfb3B0
c19jb250YWluKG9wdGlvbikgKQ0KPiA+PiArICAgIHsNCj4gPj4gKyAgICAgICAgY29uc3QgY2hh
ciAqY3B1ZnJlcV9vcHRzX3N0cltdID0geyAiQ1BVRlJFUV94ZW4iLA0KPiA+PiArICJDUFVGUkVR
X2h3cCIgfTsNCj4gPg0KPiA+ICAgICAgICAgY29uc3QgY2hhciAqY29uc3QgX19pbml0Y29uc3Ry
ZWwgY3B1ZnJlcV9vcHRzX3N0cltdID0gew0KPiA+ICJDUFVGUkVRX3hlbiIsICJDUFVGUkVRX2h3
cCIgfTsNCj4gPg0KPiA+IChsaW5lIHdyYXBwZWQgc3VpdGFibHksIG9mIGNvdXJzZSkgT3IgbWF5
YmUgZXZlbiBiZXR0ZXINCj4gPg0KPiA+ICAgICAgICAgY29uc3QgY2hhciBfX2luaXRjb25zdCBj
cHVmcmVxX29wdHNfc3RyW11bMTJdID0gew0KPiA+ICJDUFVGUkVRX3hlbiIsICJDUFVGUkVRX2h3
cCIgfTsNCj4gPg0KPiA+IGZvciB0aGUgc3RyaW5nIGxpdGVyYWxzIHRvIGFsc28gZW5kIHVwIGlu
IC5pbml0LnJvZGF0YS4NCj4NCj4gQWN0dWFsbHksIGl0IGRpZG4ndCBldmVuIG9jY3VyIHRvIG1l
IHRoYXQgdGhlcmUgbWlnaHQgYmUgYSAic3RhdGljIiBtaXNzaW5nIGhlcmUsIHRvby4NCg0KU29y
cnksIEkgbWF5IG5lZWQgbW9yZSBleHBsYW5hdGlvbiwgd2hhdCBpcyB0aGUgInN0YXRpYyIgbWlz
c2luZyB5b3UgYXJlIHJlZmVycmluZz8NCg0KPiBQbHVzIEknbSBtaXNzaW5nIGFueSBhcnJhbmdl
bWVudCBmb3IgdGhlIGFycmF5IHNsb3RzIHRvIHJlbWFpbiBpbiBzeW5jIHdpdGggdGhlDQo+IGNv
cnJlc3BvbmRpbmcgZW51bWVyYXRvcnMuIFdpdGggdGhhdCAuLi4NCj4NCg0KVGhhbmtzIGZvciB0
aGUgZGV0YWlsZWQgaW5zdHJ1Y3Rpb25zLCBsZWFybmVkIGFuZCBJJ2xsIGNoYW5nZSBpdCB0bw0K
ICAgICAgICBjb25zdCBjaGFyIF9faW5pdGNvbnN0IGNwdWZyZXFfb3B0c19zdHJbXVs0XSA9IHsg
InhlbiIsICJod3AiIH07DQpBbmQgZm9yIGluIHN5bmMgd2l0aCB0aGUgY29ycmVzcG9uZGluZyBl
bnVtZXJhdG9ycywgbWF5YmUgd2Ugc2hhbGwgYWRkIGNvbW1lbnQgaGVyZSwNCiAgICAgICAgLyog
VGhlIG9yZGVyIG9mIGNwdWZyZXEgc3RyaW5nIGxpdGVyYWwgbXVzdCBiZSBpbiBzeW5jIHdpdGgg
IHRoZSBvcmRlciBpbiAiZW51bSBjcHVmcmVxX3hlbl9vcHQiICovDQoNCj4gPiBXaXRoIGFsbCBv
ZiB0aGUgYWRqdXN0bWVudHM6DQo+ID4gUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGlj
aEBzdXNlLmNvbT4NCj4NCj4gSSdtIHNvcnJ5LCBidXQgSSBuZWVkIHRvIHRha2UgdGhpcyBiYWNr
LiBUaGVyZSBhcmUganVzdCB0b28gbWFueSBpc3N1ZXMuDQo+DQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Wed May 07 03:33:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 03:33:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978155.1365001 (Exim 4.92)
	(envelope-from )
	id 1uCVWl-00053l-J4; Wed, 07 May 2025 03:32:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978155.1365001; Wed, 07 May 2025 03:32: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 1uCVWl-00053e-F9; Wed, 07 May 2025 03:32:59 +0000
Received: by outflank-mailman (input) for mailman id 978155;
 Wed, 07 May 2025 03:32:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCVWj-00053T-Ha
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 03:32:57 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20624.outbound.protection.outlook.com
 [2a01:111:f403:2009::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f64b953c-2af3-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 05:32:55 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by IA1PR12MB6164.namprd12.prod.outlook.com (2603:10b6:208:3e8::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.22; Wed, 7 May
 2025 03:32:47 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8699.012; Wed, 7 May 2025
 03:32: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" 
X-Inumbo-ID: f64b953c-2af3-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gRT3TmSQ6i5Vh81fY6tQ0qWcS5bYCIk+lgnuIB+7KBikNcyjCqPRqS7LBS19q58EX7QJz7xaXtwwPUuKP99vbfDc8ozDGa3W7+vZTOw1FsnJLtJbDtOZNmjMKQRW4QZI/GbXfl81W4lkjffqM1h3jYCmyyCRhUtXYahm0217NFjQQ7Cw7c5H5ALQjPlp4FiXX72/q0EPVEebiRhv7ram9oHJ35TZTDBjBTAoXdj+mP+M/2WL5K/ar7yITGNtG5dQWWNxtMv2Rft7WgVgzBeS5nxuaN9m5Nd5LL/GGe5z6NDRrO1VRE6XREyhVpyPmhGhp13xmYZNLxkg99Zm+M5fPQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=R0klfDFk0oD1mNFMFmYWfGLUMNDOrYjQgES5nwI92hA=;
 b=hs1cmZ/Fqs/yZummmnAcpHjqIcdNFRvAYN6OiEzSQZSW2dDGvalxr840gLV/Pk/WLQ/SrYArJINOxii8d7Q8Yzp+nIgPJ6JL6QgHt6R4UdvC41XlfD+zc3Do1VYePVrIQHheyguojjYr0W/V2NDC5wlvO/8754ewwB47PbPK95h/pyBRixestS+S6REm+9yud7duyKDifUXgktFBRG2+6WojeQ5y0CQ2Dr84arQ32WKQ6/jEl9nylx3dW8jfZIh4fDtNDDOaLGWLcwxLKAM60Zfh/J80zeItQkvuzQbKqX89ZwtqzQKlT5wxbPul1Hg1Ia1IzU3E+O8smFe9cDp0fw==
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=R0klfDFk0oD1mNFMFmYWfGLUMNDOrYjQgES5nwI92hA=;
 b=EI+ibxlSu3ziT4lKRvagaMmGp8Yupq78HmFAY+v98NfAwjQFH1UFxB0LDj0/4xzB6FKhUnBRxWWGRa58D9YDJfNLrIqJr1APnUmeDW6g15H1heGnQmsKHA8HwCGhv3MFfMPmtLaa9117dY4yA5OaDi0nbCpDrDJcoWb+oM6B/rQ=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v3 04/11] vpci/header: Emulate extended capability list
 for dom0
Thread-Topic: [PATCH v3 04/11] vpci/header: Emulate extended capability list
 for dom0
Thread-Index: AQHbsoVY5fFyP0iPLUqWwUIzQgdm1rPFvVIAgAFjzIA=
Date: Wed, 7 May 2025 03:32:47 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-5-Jiqian.Chen@amd.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8699.005)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|IA1PR12MB6164:EE_
x-ms-office365-filtering-correlation-id: 42698237-e66b-4875-029d-08dd8d17d638
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?ei9PMjI0ZHFzczBGVnNXSjM3L3dKMTV5SVp1U2FaRmpyNXVIMjRUbzkxZERz?=
 =?utf-8?B?ZysreTlkUjdDeHhHRTVIenczWEM1UnJUQjJvd1A5dm05YVI3cGpqMUk3SUdq?=
 =?utf-8?B?Z2w1QlFDelpsN2pZY2tQYTlUNHBFa3BrTVRoa2NweGU5dmY0L0xnNjdhc044?=
 =?utf-8?B?Q1c2bFlmM0xndEI1cUZ6M0JnR2FUcFJTY0VFb2tMYlROMzlRZ3R5TzFrR3NV?=
 =?utf-8?B?LzJXdlZERDdlRTZHaTF0ODk0blJIMm5IeHZyaTZUckNLcVNISXZDQ3F5ekhM?=
 =?utf-8?B?Z0dOZ3pHeUt3TkV2RHRmV2xiZ0pJc21yUGd3UWdLUXY5K0Ird21XVHZRL1Vq?=
 =?utf-8?B?TkNtQXhNTDFyeTZlWUpJRmdhT05DYWtjYTBMcDV3cUpoTnNJOEdkYmF4dmww?=
 =?utf-8?B?VG1DTkZnQUtSelNoSnFBR0J1aWhPNURid21DdzNzY0ZBUFR1MkUvZUJLUDBY?=
 =?utf-8?B?OXlBVWRMZ0Faa3pjYzBrMGtRVDdCSzRsSER4VjlqcFpYL2xzVDZhWjNrWTJm?=
 =?utf-8?B?czJKdkFOcWk2VFFTTUxuRTVHMFhiVnhybU1hL0ZhS3l1OE44Zk1EQ3pFVDdh?=
 =?utf-8?B?ekV4YUxIOGo5bDZNNmR0TFJxQkxaNlpzSWlNNnRkNWtuRU9OWS9TcTMxSzQ2?=
 =?utf-8?B?QTFFUTJ4UlRQemN4MXAxc1FISzZBNGVQODUzS2RVckg4VlZaRHpzZWVnWWhL?=
 =?utf-8?B?S25DYlRLSitabjVvV0g0ajFWRllOWEpkY1JuTnc0TERNWE1hRlhDcmlSWmkv?=
 =?utf-8?B?T2VtaEh3YjdRYUxDL2NNQlIyQkpNWXllQXF6ZDZwVzhPalFKbHBtYTZ1amdE?=
 =?utf-8?B?a3VjNWFaRmx1Nk1ZQTlldFZ2NExSVjZaNzF6VS9hTW5OK0Nxb2EyMjl0Uzg1?=
 =?utf-8?B?RXp5ZWpxNHIvOHg1SHJsa3B0cEp0aE9jbWRhV3ZuaW5BL2FVN01oNzBIcU9L?=
 =?utf-8?B?d2NJZTV6OE5IS3Z2dm82cWVTWmRQRmdKdFpOM0xpbURRNHNFSG11R1dmT05G?=
 =?utf-8?B?d1Z0enQzaEt4c3l3RXl1cEtDem51Nm9lSno3T085WlEzaXhsdkttWGF6SUI3?=
 =?utf-8?B?cWFWNmlZYWp1V1lBRDRKa2lXZVJKK1pwbkU0NktFSHR3Tm9VWG54TXNqZE1Z?=
 =?utf-8?B?NEM1ZUxJQkVEMkJhT1ZTSml5ZWtlQjdxdVVhY1ZyekJVM1FPNWRZdWswS1Bn?=
 =?utf-8?B?ZWVTTVNPMk9aRWZWd0NyWEJZZCsrMWpmT0lQZG44bW51MGdnWjJVeGc1eFJu?=
 =?utf-8?B?c3k4ZWx0cmcraE5tUUsyRUlpNmNFNFhMTUFEZUdRdllDV21vY0JuMC9pZzd6?=
 =?utf-8?B?WjU1RGZ5elVGQjRvNnJJLzhRM1hlZTJJV3pZMmk4Q1lEUUlJTWlHaXRwd1lt?=
 =?utf-8?B?VFI4Y0lHb3pJTDcwZnVORUoyQmY3bzdmWHlpdmpyTW1PNFlaOE41TnNkbitY?=
 =?utf-8?B?VG5UNVYxb2h1SjRhWTBKM2FQeTFFS3N2NDB5bmNDc0tnalBXL3JBMXRYQ2hk?=
 =?utf-8?B?cEMybWdMTEl1VVJzR1JPRmxzVndMUkhhem1GclZyKzZYeFVCM29EVnJSaUVL?=
 =?utf-8?B?M3pzUytzV21ISG5XTTJneENlZUxzbytraGVuZ2RacEZOWEZVRnJWdGZrVEx0?=
 =?utf-8?B?NStOTzZDaGY4cUVHWVh5OXpnTEdQYi8yRkl0Z253MURvVDNJVDlrdERtZ0Rt?=
 =?utf-8?B?dDJYZmV3QWlIZnVZVE4ycnNjRzRmTnFZNWRvVEtqS0h4NFJydC9MUzhZUlc4?=
 =?utf-8?B?bkwrV2hzdDRsTWh6V3BVK1hFbkdkZFQxbFQwQ2M4WnV3M1lqWHFGQklaeEpr?=
 =?utf-8?B?cFR5cldueTl0ZTJQYjlwRmo5QTE0bVc5Z1ptcVFZbFZMajUxMHQ4SC8zczd4?=
 =?utf-8?B?YWpmNitrOC9WUVFwOWdyb2lhMGM4WEZVZE9NMzFNcDA5MmJMZ0plYk8wd1BC?=
 =?utf-8?B?T3lnZ1Z6NzBQd0toRmdtWFJwbDlKclV6dWJoYU1sTTNQbUFRUVNZVVNNZC9F?=
 =?utf-8?Q?W3H8XiiMq/YwoeTM/ZOr60mChQTs2I=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?NkFrd2UxT09VcmZrYVhZS1FqK2xrNU16bnpiR2pLdWRGWjdwaktnK0ZhNHdw?=
 =?utf-8?B?UHZhL2k5OENKRnFqMjFyWGlqRVRkY0VkRGNjdjYwa2FzWnd1US9KZ3EwTWgx?=
 =?utf-8?B?WWVTaHNlQndoYSsyQ0FHb1pZRU1hV0lDTUpPYWtETGZsVWhHWERoSUxMVkYr?=
 =?utf-8?B?YW4vd3NrVjloWDZYNDM0NjNGZ2hIc0x4Tk5UK3YxREdtN3BuWmo4bnU1d2hH?=
 =?utf-8?B?aU1SVUthbk5ka0Z3TkprTHJGUFZ4NVlFeXY0SjlyY3pjOFV5SW9xTUdxejNp?=
 =?utf-8?B?VkpDQ0tkcVZnekJ0aWV2KzlGakp1VzhWVFZBTitveUlFemJWV0dFSS9vSTVa?=
 =?utf-8?B?OTBoSHdoSHNBZ2luYm1vWGg5ck44VkR6VnozbkxvUEMyU2dUbXU1RWEyaEhw?=
 =?utf-8?B?eDdsT0FCVFpxcm9qVUdMN21seTFUa29ldFo4N2dmZ0d3aU9SV2hZZFN6M2pt?=
 =?utf-8?B?T2lMYXo5M0FCQUx3citySTlxbTNBN0pnWTc5ZUdhdU02OFBlQUEzdWZOZXZp?=
 =?utf-8?B?dFgrOG5QbHdOb2dkOGF1bHhxT3VjUkZmbGQwaTFqM0I4UHhaVUpQcmY4NnFL?=
 =?utf-8?B?OXhFNkJIZEdoSGpOclR6bS91b005NDJEa3BCZjhQMFpYeEl6Q1FUWG41dWF5?=
 =?utf-8?B?UStqcHBHK2d6dnVyUXJnRko5SHVKSGFrWHJCYTZTZ0VwVXZyZmc1VnNhRmtw?=
 =?utf-8?B?L2VVK1B4cnpFSHo4YzNEUi81NXNtWlFCaVV3M0h6bmVydzhXWThlSG04aGtE?=
 =?utf-8?B?dTlLSlVneUUvY2llenpIU3RCUVVXbHErVnM0NHdLZ25pRnI4Q3VBM29MdlNk?=
 =?utf-8?B?SE1hZE93bmVHWHpjYmJWWkNkVGhzWDlvUEZZZWYrRktvUkFJbzkvZlVHS1Yz?=
 =?utf-8?B?TXpWckdaRm5xSmZCa203NkI3bThDOGdPY3dxWjFGTXpPQ3lYem9xMlU3NnIy?=
 =?utf-8?B?NS9vOUwxcU50ZUFqcTdkM3FzcGxHV1lNc0ZMQnFOMXhSQXRQd0d5TGxzREQw?=
 =?utf-8?B?WDUwdUtWWVFzT2VGUk9Bb2VoY2hGWVI2OTRXTTV6R0VhY1IwK0dsNFQ5bXRo?=
 =?utf-8?B?a3pUemtsWXVtb3JhTHZWRUJTZkl3bjRzdmIzYXUzY1ZLYWt4NUlZZ0IwQnkz?=
 =?utf-8?B?VjFmZHJmbHExVW5ZSjBIbWxaLzBTQ2U3OWE2b2d4ZEk5Wis5UGtaMzlhR3Er?=
 =?utf-8?B?WnJZMk4rSnhIODhFSUJKWkl6S1FybFpWR0g2T0NQcWdPbnhsNHM5VGJFVXNj?=
 =?utf-8?B?TTVEMTFZV3dzZG1pek81VHpxeVA0MFAxQ0hITnlGeTZRMDcwZVpBbnlYK1lV?=
 =?utf-8?B?MThuMGkyM1BmbHl1Unc0b3o0QUVRTElQNkFUZTAyV0FOaTBMVTlwYU1qZHRl?=
 =?utf-8?B?U3JqN3QzSFl2Q0pVdUhnb1hVb3lsUDI4WEphQWhBRFFvWVIxZUxFMTgySHRz?=
 =?utf-8?B?TlBIWVVDbEF0d2xIQWtqNDlwWW8xaWN0cStEVCtEOHl3elN3QkVpQ3FTdm02?=
 =?utf-8?B?bUEwUC9CRndlVVJ0U0ZKTkJ1VlVhcmxBcnora1AyeGQ0dC9ncmRlaUdDUXl2?=
 =?utf-8?B?R0JDOURkWUIvZlpPcHZna3hsNUlIK0JGeUxoN2tiRnc0c1IrSFpZdDVIU0xS?=
 =?utf-8?B?dWRiaysrZUJHRFg2YnhJeFVJQkpScWdjVEliTWFOdzRxaUdQVXhRMC9wZ3p6?=
 =?utf-8?B?RnlOOVBYaTFxeitHM0dMSXVSeXZOVHBTbFRZaHoyT1dzUkZmaklxSWZSbWhu?=
 =?utf-8?B?Ti9WbnowMlBtNjc2emtoalpGUlZOY0pDRSszS01ZQ2w0YTJ2b0kraTI4cXNW?=
 =?utf-8?B?TFdGdDFTV0NQNTdoTGFIb1NkT09xbStITzdFUEZyYWo3TG5HdVdCSldmZTdN?=
 =?utf-8?B?RTdNbzJ1NzdXK1pkZ2VkblpBS3dtaFE0ZUtudEhZeEFuMEp6VmszWkNRbms1?=
 =?utf-8?B?bDJqL2tNdk1WeW1iVnh6eHFwR3NtMzhXbDJpUEg0Q1VoYWVKNXVqYWZEd3p5?=
 =?utf-8?B?U2g3amFENVJWc3dtZVo2SWJaa0NsblhQamo4UTdLaWF3TWdRalplQnp0K3hk?=
 =?utf-8?B?QUplVUs2a05oNTJyZk9IUUxiQlFtRjVjSHBTTTA3RVc0ZEdXWHBnMW5hTzN0?=
 =?utf-8?Q?cF8o=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <79DA249CEB6CC7438EE102ECCAC774A5@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 42698237-e66b-4875-029d-08dd8d17d638
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 03:32:47.3898
 (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: jUW9fiMLEcCBbjuTJ1iIEUxX4ipq/d0r4N+yttQzIJBloQyVPxi4TH0kT6JgLiObnrkHQIrxP/fFRSMfd0UnNA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6164

T24gMjAyNS81LzYgMjI6MTQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgQXBy
IDIxLCAyMDI1IGF0IDAyOjE4OjU2UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gQWRk
IGEgbmV3IGZ1bmN0aW9uIHRvIGVtdWxhdGUgZXh0ZW5kZWQgY2FwYWJpbGl0eSBsaXN0IGZvciBk
b20wLA0KPj4gYW5kIGNhbGwgaXQgaW4gaW5pdF9oZWFkZXIoKS4gU28gdGhhdCBpdCB3aWxsIGJl
IGVhc3kgdG8gaGlkZSBhDQo+PiBleHRlbmRlZCBjYXBhYmlsaXR5IHdob3NlIGluaXRpYWxpemF0
aW9uIGZhaWxzLg0KPj4NCj4+IEFzIGZvciB0aGUgZXh0ZW5kZWQgY2FwYWJpbGl0eSBsaXN0IG9m
IGRvbVUsIGp1c3QgbW92ZSB0aGUgbG9naWMNCj4+IGludG8gYWJvdmUgZnVuY3Rpb24gYW5kIGtl
ZXAgaGlkaW5nIGl0IGZvciBkb21VLg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEppcWlhbiBDaGVu
IDxKaXFpYW4uQ2hlbkBhbWQuY29tPg0KPj4gLS0tDQo+PiBjYzogIlJvZ2VyIFBhdSBNb25uw6ki
IDxyb2dlci5wYXVAY2l0cml4LmNvbT4NCj4+IC0tLQ0KPj4gdjItPnYzIGNoYW5nZXM6DQo+PiAq
IEluIHZwY2lfaW5pdF9leHRfY2FwYWJpbGl0eV9saXN0KCksIHdoZW4gZG9tYWluIGlzIGRvbVUs
IGRpcmVjdGx5IHJldHVybiBhZnRlciBhZGRpbmcgYSBoYW5kbGVyKGhpZGluZyBhbGwgZXh0ZW5k
ZWQgY2FwYWJpbGl0eSBmb3IgZG9tVSkuDQo+PiAqIEluIHZwY2lfaW5pdF9leHRfY2FwYWJpbGl0
eV9saXN0KCksIGNoYW5nZSBjb25kaXRpb24gdG8gYmUgIndoaWxlICggcG9zID49IDB4MTAwVSAm
JiB0dGwtLSApIiBpbnN0ZWFkIG9mICJ3aGlsZSAoIHBvcyAmJiB0dGwtLSApIi4NCj4+ICogQWRk
IG5ldyBmdW5jdGlvbiB2cGNpX2h3X3dyaXRlMzIsIGFuZCBwYXNzIGl0IHRvIGV4dGVuZGVkIGNh
cGFiaWxpdHkgaGFuZGxlciBmb3IgZG9tMC4NCj4+DQo+PiB2MS0+djIgY2hhbmdlczoNCj4+IG5l
dyBwYXRjaA0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+IEppcWlhbiBDaGVuLg0KPj4gLS0tDQo+
PiAgeGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYyB8IDM2ICsrKysrKysrKysrKysrKysrKysrKysr
KysrKystLS0tLS0tLQ0KPj4gIHhlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jICAgfCAgNiArKysrKysN
Cj4+ICB4ZW4vaW5jbHVkZS94ZW4vdnBjaS5oICAgIHwgIDIgKysNCj4+ICAzIGZpbGVzIGNoYW5n
ZWQsIDM2IGluc2VydGlvbnMoKyksIDggZGVsZXRpb25zKC0pDQo+Pg0KPj4gZGlmZiAtLWdpdCBh
L3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMgYi94ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jDQo+
PiBpbmRleCBjOThjZDIxMWQ5ZDcuLmVlOTRhZDhlNTAzNyAxMDA2NDQNCj4+IC0tLSBhL3hlbi9k
cml2ZXJzL3ZwY2kvaGVhZGVyLmMNCj4+ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMN
Cj4+IEBAIC04MTcsNiArODE3LDMxIEBAIHN0YXRpYyBpbnQgdnBjaV9pbml0X2NhcGFiaWxpdHlf
bGlzdChzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgUENJX1NUQVRVU19SU1ZEWl9NQVNLKTsNCj4+ICB9DQo+PiAgDQo+PiArc3RhdGlj
IGludCB2cGNpX2luaXRfZXh0X2NhcGFiaWxpdHlfbGlzdChzdHJ1Y3QgcGNpX2RldiAqcGRldikN
Cj4+ICt7DQo+PiArICAgIHVuc2lnbmVkIGludCBwb3MgPSBQQ0lfQ0ZHX1NQQUNFX1NJWkUsIHR0
bCA9IDQ4MDsNCj4+ICsNCj4+ICsgICAgaWYgKCAhaXNfaGFyZHdhcmVfZG9tYWluKHBkZXYtPmRv
bWFpbikgKQ0KPj4gKyAgICAgICAgLyogRXh0ZW5kZWQgY2FwYWJpbGl0aWVzIHJlYWQgYXMgemVy
bywgd3JpdGUgaWdub3JlIGZvciBndWVzdCAqLw0KPj4gKyAgICAgICAgcmV0dXJuIHZwY2lfYWRk
X3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfcmVhZF92YWwsIE5VTEwsDQo+PiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcG9zLCA0LCAodm9pZCAqKTApOw0KPj4gKw0KPj4gKyAg
ICB3aGlsZSAoIHBvcyA+PSBQQ0lfQ0ZHX1NQQUNFX1NJWkUgJiYgdHRsLS0gKQ0KPj4gKyAgICB7
DQo+PiArICAgICAgICB1aW50MzJfdCBoZWFkZXIgPSBwY2lfY29uZl9yZWFkMzIocGRldi0+c2Jk
ZiwgcG9zKTsNCj4+ICsgICAgICAgIGludCByYzsNCj4gDQo+IEknbSB0aGlua2luZyBpdCBtaWdo
dCBiZSBoZWxwZnVsIHRvIGF2b2lkIHNldHRpbmcgdGhlIGhhbmRsZXIgZm9yIHRoZQ0KPiBsYXN0
IGNhcGFiaWxpdHkgb24gdGhlIGxpc3QsIG9yIHNpbXBseSBmb3IgZGV2aWNlcyB0aGF0IGhhdmUg
bm8NCj4gZXh0ZW5kZWQgY2FwYWJpbGl0aWVzIGF0IGFsbDoNCj4gDQo+IGlmICggUENJX0VYVF9D
QVBfTkVYVChoZWFkZXIpID49IFBDSV9DRkdfU1BBQ0VfU0laRSApDQo+IHsNCj4gICAgIGludCBy
YyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfcmVhZF92YWwsIHZwY2lfaHdf
d3JpdGUzMiwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvcywgNCwgKHZvaWQg
KikodWludHB0cl90KWhlYWRlcik7DQo+IA0KPiAgICAgaWYgKCByYyApDQo+ICAgICAgICAgcmV0
dXJuIHJjOw0KPiB9DQpCdXQgaWYgYWRkaW5nIHRoaXMgY2hlY2ssIHRoZXJlIGlzIGEgcHJvYmxl
bSwgdGhpbmsgYWJvdXQgdGhpcyBzaXR1YXRpb246DQphIGRldmljZSBvbmx5IGhhcyBvbmUgZXh0
ZW5kZWQgY2FwYWJpbGl0eSwgdGhlbiB1bmRlciB5b3VyIGNoZWNrLCBpdCBkb2VzIG5vdCBhZGQg
aGFuZGxlciBmb3IgaXQsDQppZiB0aGUgaW5pdGlhbGl6YXRpb24gb2YgdGhhdCBleHRlbmRlZCBj
YXBhYmlsaXR5IGZhaWxzLCB3ZSBjYW4ndCBoaWRlIGl0IGJ5IHJlbW92aW5nIGhhbmRsZXIgZnJv
bSB2cGNpLg0KSWYgeW91IHdhbnQgdG8gYXZvaWQgYWRkaW5nIGhhbmRsZXIgZm9yIGRldmljZXMg
dGhhdCBoYXZlIG5vIGV4dGVuZGVkIGNhcGFiaWxpdGllcy4NCkkgdGhpbmsgYWRkaW5nIGNoZWNr
DQpJZiAoIGhlYWRlciA9PSAwICkNCiAgICByZXR1cm4gMDsNCmlzIGVub3VnaC4NCg0KPiANCj4g
T3RoZXJ3aXNlIG9uIHN5c3RlbXMgd2l0aCBhIGxvdCBvZiBkZXZpY2VzIGl0IGNhbiBiZSBxdWl0
ZSB3YXN0ZWZ1bCB0bw0KPiBzZXQgYSBoYW5kbGVyIHRvIGp1c3QgcmV0dXJuIHRoZSBuZXh0IGNh
cGFiaWxpdHkgYXMgMC4NCj4gDQo+IFRoYW5rcywgUm9nZXIuDQoNCi0tIA0KQmVzdCByZWdhcmRz
LA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Wed May 07 05:27:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 05:27:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978167.1365011 (Exim 4.92)
	(envelope-from )
	id 1uCXJ5-0002qo-6Q; Wed, 07 May 2025 05:26:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978167.1365011; Wed, 07 May 2025 05: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 1uCXJ5-0002qh-3Y; Wed, 07 May 2025 05:26:59 +0000
Received: by outflank-mailman (input) for mailman id 978167;
 Wed, 07 May 2025 05:26:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCXJ4-0002qb-6A
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 05:26:58 +0000
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com
 [2607:f8b0:4864:20::229])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e43e0d48-2b03-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 07:26:57 +0200 (CEST)
Received: by mail-oi1-x229.google.com with SMTP id
 5614622812f47-40356cb3352so393368b6e.1
 for ; Tue, 06 May 2025 22: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" 
X-Inumbo-ID: e43e0d48-2b03-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746595616; x=1747200416; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4kEUPSgIGA0UabuUj/oK6f2rNgvp4HKyVzvtpIhxZqU=;
        b=h1YhIh2CXPZ7g+2ro7SmFwyOmCAAPbbw9MKqLFVkT6elpVyjsER8DYzIUrjf6M2y0w
         6ND+zm3sBYhPhBfDRr2SLf86Su/Q97cww4y2hFFkajxtc9j/k1SxRVvtmrJt3/YpiyF3
         CHhHeGUxuHBT0FsP2/WQPdZpGRd9UpL/CTZ+E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746595616; x=1747200416;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4kEUPSgIGA0UabuUj/oK6f2rNgvp4HKyVzvtpIhxZqU=;
        b=m4ZArAK5CTS11Supq1hQM6nM96ukJI+dAVBRleAB1g3IS/JlhmXk1acg2WT5XigZSb
         pZnqqHtG/D38Y3G5UkSxHV68TngBfv+2IXX0L5a/ZBI8xAXaauONsmxxbFFjiSY97rEd
         KOmoaNHBdLh1c5MpE+WflssLC+4r+yxY25jONgI9neAEOk1mbE4e+v4uAEZrEqjvMq7w
         jRTXjhP3lEbcT6ymaPlzB2DWQWO6Pc8IOKohHkshoC7on5UMwtxQt0ERaiJapWKDuGym
         0A9n7d9s06zzzJsavLk6fRuFpEkIjw3ryMY/0tFZLL//6OD2Yj1vqAvGL1G2OYK12aIf
         HjjQ==
X-Gm-Message-State: AOJu0YxBC1P+uQxXCblZHBVNSYmgKmZwTlJKEWcf4rpB48V/EOrnFsuj
	g6TB/QO1bFypEZWF35dIgP+9nAV4FyOz8L0c1gwBNfSdmeDlsKjCJwNkvELULRvb6fzyEJ2IAU2
	rSQngYdiDfNjrJ7EDoE/WOoc8RpI0DP60h7gUXpuCdapUHWkqHCU=
X-Gm-Gg: ASbGncsqZdBfCSFmOdwwtar495XA74FYofOuTinp6CYTYx09g03U0F4Ce5QbnPkvI5G
	Grai+DFwvlMEzfH8kTcUjYCmzsemL0+a+kMGv8mJnTsooLekcvycr8wVoQpRHfCtEUDu6kEyuSn
	ATyDLwcSEQGUeXGXWzaZs=
X-Google-Smtp-Source: AGHT+IErBNTxAdyjptbj6DvUZY6tdDRej7dWByUKTPiW5umZhCobMUkWT+MSEEs4jgcAEL/oAWW0gAPRlyFGFH/UAp4=
X-Received: by 2002:a05:6808:1926:b0:3f4:11b3:206b with SMTP id
 5614622812f47-4036eabb9aamr1386237b6e.17.1746595615689; Tue, 06 May 2025
 22:26:55 -0700 (PDT)
MIME-Version: 1.0
References: <20250506135655.187014-1-frediano.ziglio@cloud.com>
 <20250506135655.187014-2-frediano.ziglio@cloud.com> 
 <5698b996-e23d-49f7-af37-645d4784dc67@citrix.com>
In-Reply-To: <5698b996-e23d-49f7-af37-645d4784dc67@citrix.com>
From: Frediano Ziglio 
Date: Wed, 7 May 2025 06:26:44 +0100
X-Gm-Features: ATxdqUFn8NwqX3UC35Il2ow7r5NWLk7fF0j763oN-8W92QyBIe5LKhRmh4RMBIQ
Message-ID: 
Subject: Re: [PATCH 1/4] xen/lib: Export additional sha256 functions
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, Ross Lagerwall , 
	Anthony PERARD , Michal Orzel , 
	Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 6, 2025 at 11:17=E2=80=AFPM Andrew Cooper  wrote:
>
> On 06/05/2025 3:05 pm, Andrew Cooper wrote:
> > On 06/05/2025 2:56 pm, Frediano Ziglio wrote:
> >> diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
> >> index 47d97fbf01..ea8bad67e4 100644
> >> --- a/xen/include/xen/sha2.h
> >> +++ b/xen/include/xen/sha2.h
> >> @@ -9,6 +9,16 @@
> >>
> >>  #define SHA2_256_DIGEST_SIZE 32
> >>
> >> +struct sha2_256_state {
> >> +    uint32_t state[SHA2_256_DIGEST_SIZE / sizeof(uint32_t)];
> >> +    uint8_t buf[64];
> >> +    size_t count; /* Byte count. */
> >> +};
> >> +
> >> +void sha2_256_init(struct sha2_256_state *s);
> >> +void sha2_256_update(struct sha2_256_state *s, const void *msg,
> >> +                     size_t len);
> >> +void sha2_256_final(struct sha2_256_state *s, void *_dst);
> >>  void sha2_256_digest(uint8_t digest[SHA2_256_DIGEST_SIZE],
> >>                       const void *msg, size_t len);
> > sha2_256_digest() is unlike the others as it holds sha2_256_state
> > internally.  I'd suggest having all of the additions below this point,
> > which group them more nicely.
> >
> > Can fix on commit.  Otherwise LGTM.
>
> Not quite.  Now that sha2_256_final() is exported, it should have a
> proper type for  _dst.  I've folded:
>
> diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
> index 0d55fe640431..cb30e8f8d77c 100644
> --- a/xen/include/xen/sha2.h
> +++ b/xen/include/xen/sha2.h
> @@ -21,6 +21,7 @@ struct sha2_256_state {
>  void sha2_256_init(struct sha2_256_state *s);
>  void sha2_256_update(struct sha2_256_state *s, const void *msg,
>                       size_t len);
> -void sha2_256_final(struct sha2_256_state *s, void *_dst);
> +void sha2_256_final(struct sha2_256_state *s,
> +                    uint8_t digest[SHA2_256_DIGEST_SIZE]);
>
>  #endif /* XEN_SHA2_H */
> diff --git a/xen/lib/sha2-256.c b/xen/lib/sha2-256.c
> index 896a257ed9b7..08ef7011a1c3 100644
> --- a/xen/lib/sha2-256.c
> +++ b/xen/lib/sha2-256.c
> @@ -171,9 +171,9 @@ void sha2_256_update(struct sha2_256_state *s, const
> void *msg,
>      memcpy(s->buf + partial, msg, len);
>  }
>
> -void sha2_256_final(struct sha2_256_state *s, void *_dst)
> +void sha2_256_final(struct sha2_256_state *s, uint8_t
> digest[SHA2_256_DIGEST_SIZE])
>  {
> -    uint32_t *dst =3D _dst;
> +    uint32_t *dst =3D (uint32_t *)digest;

That is we are never going to support architectures with unaligned
memory access.

>      unsigned int i, partial =3D s->count & 63;
>
>      /* Start padding */
>
> in too, which is compatible with the rest of the series too.
>
> ~Andrew

I'll send an updated series with these and all the commits (mail server iss=
ues).

Frediano


From xen-devel-bounces@lists.xenproject.org Wed May 07 05:27:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 05:27:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978175.1365021 (Exim 4.92)
	(envelope-from )
	id 1uCXJf-0003L1-EP; Wed, 07 May 2025 05:27:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978175.1365021; Wed, 07 May 2025 05:27: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 1uCXJf-0003Ku-BN; Wed, 07 May 2025 05:27:35 +0000
Received: by outflank-mailman (input) for mailman id 978175;
 Wed, 07 May 2025 05:27:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCXJe-0002qb-1A
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 05:27:34 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20626.outbound.protection.outlook.com
 [2a01:111:f403:2409::626])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f957ce05-2b03-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 07:27:32 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CY3PR12MB9678.namprd12.prod.outlook.com (2603:10b6:930:101::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.25; Wed, 7 May
 2025 05:27:25 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Wed, 7 May 2025
 05:27: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" 
X-Inumbo-ID: f957ce05-2b03-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lQOPxk82f8TLDqFj2UUBuSG0xb73M30omoTL6EZdw/yb7U1IE1EDC6rVWDlnLsQw1WVJrBVHXnXrd/30j+pb/ne2P7UqYIA/lO5GETUyHvT2oveKMVIWGFLsgXw4dKFvZmzifs9lRsYRcvpLzt3nIahVYAnySWCx5jAKVpSLKRFek6C/HKVR4+dVEawPCd+TMHUeLE1lNIvd+J186gzMLWwlCZowm4Az8id8NRpLnWygt2Ub3lbSI/Y4cTrAUMsOlqkTsdJzLsl1RGKYqEZihzZbrVloXC3O6JVs/YpcQbL+3Vl6SAAL83/XfA+t09eFBXh/7yW167oAc2ZBOYXnKQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XF7zXImdY1hbj3LxkfgEZU3aKT8tV5xHPOr87Te/Rzs=;
 b=R9XXJUwci6WDBEAROeqQeVsXp27TaOO4x47kLAUzVqtlm2JPNxoxgbNrKpyQj6PJmVjLf4zLdmUbShivwWoUd3/1cjtuGH3EPOipLDaBXWqaBKuJiIuYboyamghgOuauV6Vf2XMd5JALK9hZ8wGckw7QGk6UPGSPwewWGy5ompSmaZ+NL60dCEnSnkEWodrvkqJiXvX0fTKthWWkNxyW4PofEm0EzRgegTQe0WEBgj9o4ujD6OO0mGP5wqv5q0yw9LZYywXdFfIivWiAZlvJIxZlTWjbbFR+c4EewfY/R+mpeh9r8easglBkHgCJrtDRasl8LOjummbmpTiCPl3pTA==
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=XF7zXImdY1hbj3LxkfgEZU3aKT8tV5xHPOr87Te/Rzs=;
 b=iuUTsgN1+iYxMKQ7D5+VEICcS21feZz32SvRIMREFsaqLT4zzR+YugUz1V07QELyhu9YZRoS+ahbcbqrRAKkKG3dTJiazz0Db6rBlCrgek8oXP/zAR9LTIWCMFYZ9eWAvRTeatkthqVJjP0a1EoJQjbx17mvl8KmzACCjrLj0Qg=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Topic: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Index: AQHbrRCmtZ7pr/knH02upOrsNIOYE7O6sNeAgAvz/ZA=
Date: Wed, 7 May 2025 05:27:24 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-6-Penny.Zheng@amd.com>
 <57a3b2c0-d57d-46e3-b248-0e243f715423@suse.com>
In-Reply-To: <57a3b2c0-d57d-46e3-b248-0e243f715423@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=e5bd0894-797d-44c3-a227-8ec4b52f72c8;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-07T05:27:14Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|CY3PR12MB9678:EE_
x-ms-office365-filtering-correlation-id: fa38bffb-6f9b-4230-071c-08dd8d27d961
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?QVlVb1E4VnlDRDJ2ZlVsOHJCTWZGU0phU25DK2k4UWpROUVoYmJFVzNSQk9F?=
 =?utf-8?B?YVkwekM1S0J3THQ0VFhLc0dISGxjV0VQTGsrT2IyVWNtUjdIRHVYckh4Nm96?=
 =?utf-8?B?dUV0ejFuM1F3OHdBeG9OZzNuSGx5dlpJVWROT0tSVldhUHJLQ2RwZU1UbkFF?=
 =?utf-8?B?MzRmUzZMVjJEc1VsclkwVE4vSXlDSmhJcy9kaGNXNFdZeFZLc1o5ZDdvOEJW?=
 =?utf-8?B?RFUzeEE2N21qM05FSW9DOWxZZjFGMkVPdThNcE9sWml5RXExamxCUVowTDVG?=
 =?utf-8?B?NVlKU2VsdjB2L3BtRFNnbFBUaExHUkdEL3VoeWNpV2dVcjFUMXJHMGdSK0xQ?=
 =?utf-8?B?ZTBzMWZ0cHhUR013cHp5YWhxOVA5Zy9CVmtyTWdvRHJkS2JLdVNwNjByMVox?=
 =?utf-8?B?ZEVUL1BTRFFBS0RtNGRkVi9EdjNZM1QyUWNaV1VFR2QxWjRHbHU1SHd4Wm51?=
 =?utf-8?B?bksrSEJVT01PcytQcFdJb2k1alByWGhBNjhxS0NwT1BHVFpISFBCbStWMStC?=
 =?utf-8?B?UUVjUWpQcTlJNGlJZzBpQjZWbG5JNDdCMUNMUHMzWGl3ajU4RmlqMm1KcEFo?=
 =?utf-8?B?NGZHdndPRGN0cjJnS3ZBblJZZFJZS0lPU0dUL1V2aVgwa25VRnpNVjZBdUNs?=
 =?utf-8?B?d2wxaGVQRHlrbWhVTWI4MW1sUVVKanF0cEZIcUZHbjYrbGdKdVg5YzdYa01q?=
 =?utf-8?B?QUJ3SDFhdGhKaFRtMGxuUXYxYnBYWW1wdk9QdEdBRXZJa1J4blN5QzZpd1VH?=
 =?utf-8?B?eklKWlFjeFhpWjVvdDFjRDR3WW9OVWxNRVdCRCtZS0VlL1F6c3J2L004Zjg3?=
 =?utf-8?B?ZTh6Wnp1QVQ2aCswRytpeThoejc2ckNzMGVyTm5xL1pmTWZ5ZlUzVFVxdkNw?=
 =?utf-8?B?TGN0VkoxRUFUVHZ3UFU4Nk1CZzdoYm5OYXNtRU9RYjVKcnd3eTZTWEpWRCt1?=
 =?utf-8?B?MmVHV3llM0ZNNU9mTmx0dmc2UVEzMytueHV1cTh1eityVlJwQWZtckdhRnND?=
 =?utf-8?B?NVZGaGpJY0JqUVdWdVpIN3BQNXVqOVFvbkxHNFJ0RFpROWE4Z29zMk1tSENs?=
 =?utf-8?B?SG1HR1Z1ZGNUZC9QUjZBVlNNekxxY29haHRsSXhpUVRxVVJVdUY3UVlTU3Br?=
 =?utf-8?B?bzVyeWxHYXdPREYyczl6L291VmV5WDdGNlZkR2N6cFl4czdXQmdHeWUrVlU1?=
 =?utf-8?B?OTlQS0t0aHpsclZXL2JmOEhObnlBRzJkMUhCemJWdXFqMkkwSmlyMnowTlBL?=
 =?utf-8?B?RkhBb2dESVZWalRKaXRQZ3FHaGtVRko4TVlWV0lHMXVVVlh4c0Vyek1QSU9q?=
 =?utf-8?B?a2F6NGVpTnFrUlhVcFZSWjcyS2RjVzJSWVVCUFRYcUR3TGZqNEdJMFJucU1o?=
 =?utf-8?B?VGJzcHVoQURyeTErVndWTWxRaDFqTWpNOHlOOFRiWXJSNFdkK3Bnc2RZRUtE?=
 =?utf-8?B?dGR1SUFiaUt6STFCY3g0MzFGTVBMUElicVF4dU4vaUd2MWVGUG1wOU9kS1Fh?=
 =?utf-8?B?N2J1SDdFdlNGSWRML1pGc1gvaWg1eTdKQWFPQ201aDU3SkV5UG5qTytDQ2Y5?=
 =?utf-8?B?WEMya250QnVnbUZYbnY1ckkzU0Q0dG9SejFrWVZ2QWlJUlI3SVF3cTUxdG1B?=
 =?utf-8?B?MkR5UlVsS3V5NGxROWppZ3BTdTZNdVpkUXMzQlJLZnliNlJrZkJNZTdHc3N0?=
 =?utf-8?B?UC9YZGxZbHlsOUUzeUdVMitlaVBVb0U5WmdBVFFmQkJ2MGY1Z1VJRnRWYVM4?=
 =?utf-8?B?OGppcjBHQXE5VWFGdlNiZWdtZi9sZk5uQy9TZGNzWE1KS1NOV2tVUDIvT3or?=
 =?utf-8?B?Mk5HaW1nZWZsdjRXVm9XMmU2eW8rVmcrQjZFdi9JN2NwbWE2UTVaalU5dEZh?=
 =?utf-8?B?c1lUYlkreUl3RUFkekJEZWJYMk55NVdnbktzWTJ0L0xOdlR1dFRmc2kwY1d2?=
 =?utf-8?B?SEtsUURmWHQ0R1hmR3JqYy9WTzI3eFl4SEVjcmhlL2g4ZUQrZmNVczUwMjYy?=
 =?utf-8?Q?rgwHONku5odTIlHKGikcPmoaxEoE9E=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?cklBQ0sxam5uNVZjQ1V3ZVM0V3ZnV29FQWtDaTRmZzUrZ2FGYUFTRDJ3SFNv?=
 =?utf-8?B?WXZLaUhhU0x1SVQyYlJmUDNpMVk4bTB4eXlFeCtQTDJHcXRvZFVIajY2NzVK?=
 =?utf-8?B?eUxGRkxJcjVUZkNPZkliL0JsWFVWc3UzeXZ3VGZTREdLdlhzUEphSHBIZWd2?=
 =?utf-8?B?d0tUNTlqaGhtMzl3N3hJS1ZKQ21xQ0RFR1puSlo4RFQ0Y0Z1RlBoTmlSZjha?=
 =?utf-8?B?TzRXeUNFZ0NkbnZ6NE9CNkJ1K1JYaXErU0tsNExtM1lQM2ZaeDhWTWpaS2tv?=
 =?utf-8?B?Ri8rQWxVeUhNY3c3NytwTGh4dzlWUHRzMjhmdnZ2czMzL3RreDd3enZXbWRG?=
 =?utf-8?B?S1JLRmJER0JGZE9rQ3VCZXR2NEpDYTFtVG5qNzNleHdtSHkxdm9XblFobTBx?=
 =?utf-8?B?eFpYMGhEdVl6ekx5d09qS0lYd2M1UFpiVWwvWkU5T3VqV3U0WkQxV0ZUQXdt?=
 =?utf-8?B?cnVTMFR4Ky9KMTZEYjY3MDBTR0U3RkpvUVVDRldRNXdLbTJ0V2JGa2VFNmkz?=
 =?utf-8?B?bjBDbjN0Rkp3ZFlKamNNbnBVTEs0NkpnTnNhSHhwYVo3Sytxb0ZsbUVNR3RV?=
 =?utf-8?B?d2tuNVVERFlnbHA5QTdxcXFueVJDZWg2TjRiWjVJendHZnlYaXc0a3hpVWxo?=
 =?utf-8?B?SE5QdjVMUWhycUtlRGlQWDFyMFV4eFJBT3l4S1grc1hmcW1IcnVHRjd3TFhv?=
 =?utf-8?B?YjFwYTVKTW00K1RxdTJTZ3BVTkZ5RVJHZG8wdExnaTBCUjNnVWNvdVdXNEVC?=
 =?utf-8?B?WUhoY0x0cGMwY1lsZjlSdG1vYTA5RlE0cnJnVEVDTkM3UDhmT0FSNWZZOUNu?=
 =?utf-8?B?anFhVitESmlkSHRTRjZEQmdXMjRnV3B2RDFWRnhLN0UxNnlHOHJpSlBzT3JO?=
 =?utf-8?B?RXBPdG1FTnJVZjl2ejMzTmhza01adm96bTJrS1VJS0poalIxVm9sTHVacW9T?=
 =?utf-8?B?U3hMdGZTTUdLdUwrM1M0ZERVOTQyY1JVVjArYlZWa0tHeEYrSVhjRHd2WGpD?=
 =?utf-8?B?VGU4UUk0aE1NUTloZlpUeFZMUERCdU5KUXhSY1RWbnFlZE9uMHNsM0tXZFVn?=
 =?utf-8?B?SDJCY0NWYUNheDBTQXl5QnMwRStzQzQ5Tnk4T1F6dmxRQzdqSFdxTEFtZWJx?=
 =?utf-8?B?MityQ2Q3QTFsaXpIVk5PSjgvcGdYSjFmWTNrVUJENUlsOEl2b2IwZzdZQmIr?=
 =?utf-8?B?V0NmWnlXYmZqWlltUlo3U3MyVkswM2hOT3VuZWQxSzhLWkJaM1MzWmtXSEFL?=
 =?utf-8?B?Y3F6akRCY1RSWXBmNFkwYUV6WGhNUitlUk1VVzN2N0ZFbTZGWGVIQ0xGemEw?=
 =?utf-8?B?TVRmY3FCaW1MZ0ZPSmVLV05NY25VY25pT0RQODYwOEthVDd1VFJWdjJDamM4?=
 =?utf-8?B?ZUc5Z09TRGlFN1VZZG1jNjAxWlpJTWMzVm1NQVZwVVJPODhBVmd1UU5Dcjdx?=
 =?utf-8?B?cFphY1drb3ZUQjZBREd1VE5QUzQyTCtva25pMWJXS1BEaDZ2NWMxTXQ3SEg1?=
 =?utf-8?B?dGF5SkNhSXYzOUYwaHIrQkhvY0JmNVB2b1gwZnBXbzloVUdzMGhRWE9xeGpo?=
 =?utf-8?B?VW55OUhlUEdaNTJXbWZXK2h4b1VoQU1BQXVTMDJaZERQYzNSNmtKOFpPdzRa?=
 =?utf-8?B?YUJxejRFaHp4LzRUMFA1SkRHYjlWNWlNUk92SGJBSzZncmZIWTF5bzhZSFZq?=
 =?utf-8?B?eTRaRzJ2TTJTWWY3WEI0UmxsckpVeDZUckgvM1R5TmZRSTFWUkwrTTZ4RjY0?=
 =?utf-8?B?ejNTbUNPVHc5WENJTWIzT0gxZ3luZmNocXhwWmltZk9ZNmpTNHhXQmNVb2l0?=
 =?utf-8?B?ZXpHbHBqM1h6bUZBNDJkYmdmVTZwWDA5OGcyYlZmSHFUUnB1ckh0YzJCbUNI?=
 =?utf-8?B?NUFIQ1dJcnhjeEF2UEJ1WnVwTGFkQUxhNFcrdCtFV25MNDZralBsSDVHWEs2?=
 =?utf-8?B?ZDBXSlpXWWlkU25CWmYyenErK3ZoVTNXUFFnRXA0TFhraGhaWTJnVlA2VHN3?=
 =?utf-8?B?UU5oTS9TSlZoSmNDL1gzbHFDYldNaUFiNHJyZjB0VTYwdm9SUHY5U0NnSWkx?=
 =?utf-8?B?V3RuRDkrOEpadThRcHRibWdoTFc4T0hVRldFR0dHejh5UEcyZThyY2lQR0R6?=
 =?utf-8?Q?84Qs=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fa38bffb-6f9b-4230-071c-08dd8d27d961
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 05:27:24.6660
 (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: k8nQVuW+SjHB6VSUCoJNjsgmxlXZZYD8JCIAGdXOgLCO8GMn3Zh5qx0HmbmT8TJer11UVWRIEL7lW28+rzHK1w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY3PR12MB9678

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAy
OSwgMjAyNSA4OjUyIFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+
DQo+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4g
PGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJh
cmRAdmF0ZXMudGVjaD47DQo+IE9yemVsLCBNaWNoYWwgPE1pY2hhbC5PcnplbEBhbWQuY29tPjsg
SnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2VyDQo+IFBhdSBNb25uw6kgPHJvZ2Vy
LnBhdUBjaXRyaXguY29tPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwu
b3JnPjsNCj4geGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBb
UEFUQ0ggdjQgMDUvMTVdIHhlbi94ODY6IGludHJvZHVjZSAiY3B1ZnJlcT1hbWQtY3BwYyIgeGVu
DQo+IGNtZGxpbmUNCj4NCj4gT24gMTQuMDQuMjAyNSAwOTo0MCwgUGVubnkgWmhlbmcgd3JvdGU6
DQo+ID4gQEAgLTUxNCw1ICs1MTUsMTYgQEAgYWNwaV9jcHVmcmVxX2RyaXZlciA9IHsNCj4gPg0K
PiA+ICBpbnQgX19pbml0IGFjcGlfY3B1ZnJlcV9yZWdpc3Rlcih2b2lkKSAgew0KPiA+IC0gICAg
cmV0dXJuIGNwdWZyZXFfcmVnaXN0ZXJfZHJpdmVyKCZhY3BpX2NwdWZyZXFfZHJpdmVyKTsNCj4g
PiArICAgIGludCByZXQ7DQo+ID4gKw0KPiA+ICsgICAgcmV0ID0gY3B1ZnJlcV9yZWdpc3Rlcl9k
cml2ZXIoJmFjcGlfY3B1ZnJlcV9kcml2ZXIpOw0KPiA+ICsgICAgaWYgKCByZXQgKQ0KPiA+ICsg
ICAgICAgIHJldHVybiByZXQ7DQo+ID4gKyAgICAvKg0KPiA+ICsgICAgICogQWZ0ZXIgY3B1ZnJl
cSBkcml2ZXIgcmVnaXN0ZXJhdGlvbiwgWEVOX1BST0NFU1NPUl9QTV9DUFBDDQo+ID4gKyAgICAg
KiBhbmQgWEVOX1BST0NFU1NPUl9QTV9QWCBzaGFsbCBiZWNvbWUgZXhjbHVzaXZlIGZsYWdzDQo+
ID4gKyAgICAgKi8NCj4gPiArICAgIHhlbl9wcm9jZXNzb3JfcG1iaXRzICY9IH5YRU5fUFJPQ0VT
U09SX1BNX0NQUEM7DQo+ID4gKw0KPiA+ICsgICAgcmV0dXJuIHJldDsNCj4gPiAgfQ0KPg0KPiBX
aHkgaXMgbm8gc2ltaWxhciBhZGp1c3RtZW50IG5lZWRlZCBpbiBwb3dlcm5vd19yZWdpc3Rlcl9k
cml2ZXIoKT8gSW4gcHJpbmNpcGxlIEkNCj4gd291bGQgaGF2ZSBleHBlY3RlZCB0aGF0IGl0J3Mg
bm90IGVhY2ggaW5kaXZpZHVhbCBkcml2ZXIgd2hpY2ggbmVlZHMgdG8gY2FyZSBhYm91dA0KPiB0
aGlzIGFzcGVjdCwgYnV0IHRoYXQgdGhlIGZyYW1ld29yayBpcyB0YWtpbmcgY2FyZSBvZiB0aGlz
Lg0KPg0KDQpUaGVuIG1heWJlIHdlIHNoYWxsIGFkZCB0aGlzIGhlcmUsIHRvIGV4dHJhY3QgdGhl
IGNvZGVzIGZyb20gZWFjaCBzcGVjaWZpYyBkcml2ZXI6DQpgYGANCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvYWNwaS9jcHVmcmVxL2NwdWZyZXEuYyBiL3hlbi9hcmNoL3g4Ni9hY3BpL2NwdWZy
ZXEvY3B1ZnJlcS5jDQppbmRleCBlYWMxYzEyNWEzLi45Mjc2MjQxMjkxIDEwMDY0NA0KLS0tIGEv
eGVuL2FyY2gveDg2L2FjcGkvY3B1ZnJlcS9jcHVmcmVxLmMNCisrKyBiL3hlbi9hcmNoL3g4Ni9h
Y3BpL2NwdWZyZXEvY3B1ZnJlcS5jDQpAQCAtMTkwLDYgKzE5MCwyNSBAQCBzdGF0aWMgaW50IF9f
aW5pdCBjZl9jaGVjayBjcHVmcmVxX2RyaXZlcl9pbml0KHZvaWQpDQogICAgICAgICAgICAgICAg
IGlmICggcmV0ICE9IC1FTk9ERVYgKQ0KICAgICAgICAgICAgICAgICAgICAgYnJlYWs7DQogICAg
ICAgICAgICAgfQ0KKw0KKyAgICAgICAgICAgIGlmICggIXJldCAmJiBpIDwgY3B1ZnJlcV94ZW5f
Y250ICkNCisgICAgICAgICAgICB7DQorICAgICAgICAgICAgICAgIHN3aXRjaCAoIGNwdWZyZXFf
eGVuX29wdHNbaV0gKQ0KKyAgICAgICAgICAgICAgICB7DQorICAgICAgICAgICAgICAgIGNhc2Ug
Q1BVRlJFUV9hbWRfY3BwYzoNCisgICAgICAgICAgICAgICAgICAgIHhlbl9wcm9jZXNzb3JfcG1i
aXRzICY9IH5YRU5fUFJPQ0VTU09SX1BNX1hFTjsNCisgICAgICAgICAgICAgICAgICAgIGJyZWFr
Ow0KKw0KKyAgICAgICAgICAgICAgICBjYXNlIENQVUZSRVFfeGVuOg0KKyAgICAgICAgICAgICAg
ICAgICAgeGVuX3Byb2Nlc3Nvcl9wbWJpdHMgJj0gflhFTl9QUk9DRVNTT1JfUE1fQ1BQQzsNCisg
ICAgICAgICAgICAgICAgICAgIGJyZWFrOw0KKw0KKyAgICAgICAgICAgICAgICBjYXNlIENQVUZS
RVFfbm9uZToNCisgICAgICAgICAgICAgICAgZGVmYXVsdDoNCisgICAgICAgICAgICAgICAgICAg
IGJyZWFrOw0KKyAgICAgICAgICAgICAgICB9DQorICAgICAgICAgICAgfQ0KKw0KICAgICAgICAg
ICAgIGJyZWFrOw0KICAgICAgICAgfQ0KICAgICB9DQpgYGANCg0KPiA+IEBAIC01NzMsNiArNTc2
LDE0IEBAIHJldF90IGRvX3BsYXRmb3JtX29wKA0KPiA+ICAgICAgICAgIH0NCj4gPg0KPiA+ICAg
ICAgICAgIGNhc2UgWEVOX1BNX0NQUEM6DQo+ID4gKyAgICAgICAgICAgIGlmICggISh4ZW5fcHJv
Y2Vzc29yX3BtYml0cyAmIFhFTl9QUk9DRVNTT1JfUE1fQ1BQQykgKQ0KPiA+ICsgICAgICAgICAg
ICB7DQo+ID4gKyAgICAgICAgICAgICAgICByZXQgPSAtRU9QTk9UU1VQUDsNCj4gPiArICAgICAg
ICAgICAgICAgIGJyZWFrOw0KPiA+ICsgICAgICAgICAgICB9DQo+DQo+IFdoaWxlIGF0IGxlYXN0
IHlvdSBubyBsb25nZXIgdXNlIC1FTk9TWVMgaGVyZSwgSSBxdWVzdGlvbiB0aGlzIGJlaGF2aW9y
LCBpbmNsdWRpbmcNCj4gdGhhdCBmb3IgdGhlIHByZS1leGlzdGluZyBjYXNlczogSG93IGlzIHRo
ZSBjYWxsZXIgc3VwcG9zZWQgdG8ga25vdyB3aGV0aGVyIHRvDQo+IGludm9rZSB0aGlzIHN1Yi1v
cD8gSWdub3JpbmcgZXJyb3JzIGlzIGdlbmVyYWxseSBub3QgYSBnb29kIGlkZWEsIHNvIGl0IHdv
dWxkIGJlDQo+IGJldHRlciBpZiB0aGUgY2FsbGVyIGNvdWxkIGJsaW5kbHkgaXNzdWUgdGhpcyBy
ZXF1ZXN0LCBnZXR0aW5nIGJhY2sgc3VjY2VzcyB1bmxlc3MNCj4gdGhlcmUgcmVhbGx5IHdhcyBh
biBpc3N1ZSB3aXRoIHRoZSBkYXRhIHByb3ZpZGVkLg0KPg0KDQpVbmRlcnN0b29kLg0KSSB3aWxs
IGNoYW5nZSBpdCB0byByZXQgPSAwLiBEbyB5b3UgdGhpbmsgd2Ugc2hhbGwgYWRkIHdhcm5pbmcg
aW5mbyBoZXJlPw0KRG9tMCB3aWxsIHNlbmQgdGhlIENQUEMgZGF0YSB3aGVuZXZlciBpdCBjb3Vs
ZC4gWEVOX1BST0NFU1NPUl9QTV9DUFBDDQppcyBub3Qgc2V0IGNvdWxkIGxhcmdlbHkgYmUgdXNl
cnMgY2hvb3Npbmcgbm90IHRvLiBJbiBzdWNoIGNhc2UsIHNpbGVudGx5IGdldHRpbmcgYmFjayBz
dWNjZXNzDQpzaGFsbCBiZSBlbm91Z2guDQoNCg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Wed May 07 06:00:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 06:00:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978194.1365031 (Exim 4.92)
	(envelope-from )
	id 1uCXpK-0000G4-SY; Wed, 07 May 2025 06:00:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978194.1365031; Wed, 07 May 2025 06:00: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 1uCXpK-0000Fx-Op; Wed, 07 May 2025 06:00:18 +0000
Received: by outflank-mailman (input) for mailman id 978194;
 Wed, 07 May 2025 06:00:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCXpC-0000Fg-OY
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 06:00:11 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2062a.outbound.protection.outlook.com
 [2a01:111:f403:200a::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 826df619-2b08-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 08:00:01 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by IA1PR12MB9030.namprd12.prod.outlook.com (2603:10b6:208:3f2::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Wed, 7 May
 2025 05:59:52 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8699.012; Wed, 7 May 2025
 05:59: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" 
X-Inumbo-ID: 826df619-2b08-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Z8r8s3s1au5XRv8tJ5rejeTJMAEqmmOf2ip7mXBSc7r+ydEZ0WWWkBRm7aXUW7kGhbCYUiyJHmF/tTNi0wTq3nmySSJja2kEdDkqftdUBs4Wac4X3KPHL/lCEyNkV28eSlhJGGzjQ04Juiv3f3QDnxxOkwAv6SSzvzAwFebGgYjGmraN7uolB7nxjYmZg4VtScRJ39nM4zWaX2+/JX7OvGYTHEjBGn8xw1iZk8PSEuKszehnzBZNw3RRJgLsoOEgz5lnspSEItNO3/PJBJycPJQ43LszArUC217WQ5wbOnTq8fPnLVr2zQBZ65mZeKRwrRs+wg8SpcSyWQmCiirtfg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VCaupg/xJkiyUwYGVr0VIuv5dlB6es9eL7IFQUc5Dq0=;
 b=HnauIDasCXSKKRd8nM37a5upEFZDck4IJgyry0Fpuotzzj5LsLYhpH2CG41UIvCFjbw1FRul9kIjn4DFhKbnWWZ/kacOls34WOqja/701Qny8nHiabIOmtfhwEPIQQEU6Dq8bqEqXCkQRNdh+Qc22vnvi/xDr7K9RfXI8LFEdT5VgjmV6YpSdiDXVNDmekDoEmW0aFHjHssz9WI0LBwtIUYHzDkvg0FchkWC6aIjS+b+nM6k5+pK0slr+RzktapVP5tKCPzdf9gwd9be+8ItXzNrf/F4xCeKtsDwSCLItrP5ST4HqLvYL7Vv+hTCar+V9cNHxqIqQ7ORhrTefosiKg==
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=VCaupg/xJkiyUwYGVr0VIuv5dlB6es9eL7IFQUc5Dq0=;
 b=ktoNI++XvQtTV0+38cuDYQ10Ti4udYiEXRSRqwfGMJRmFeoFgsqmd59kbZWtJBsKLDvnHZsBotYJNroBC1/vzWEDO7tUNn8xTwFhDx3e3bgS/FEbrQZo9bC3o5OLtWukdnBBb4yvvWwa8BKmH5sf5YHXJRyqK+3hdeF+GP4U4jY=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , Andrew Cooper , Anthony
 PERARD , "Orzel, Michal" ,
	Jan Beulich , Julien Grall , Stefano
 Stabellini , "Chen, Jiqian" 
Subject: Re: [PATCH v3 05/11] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v3 05/11] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index: AQHbsoVaTdJd8UN3wUOnIdqQLAHMILPFw6cAgAGFDQA=
Date: Wed, 7 May 2025 05:59:52 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-6-Jiqian.Chen@amd.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8699.005)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|IA1PR12MB9030:EE_
x-ms-office365-filtering-correlation-id: 84ddd579-aba5-4ac5-384c-08dd8d2c6225
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?UDBGZ2ZJaUl3clRzUVRvREx5cWFxTGlaK0YvckFMWktSdkhJaTJnRGZYbk9t?=
 =?utf-8?B?V1Rjd094bkZBb2RGdGdVMnY3akkxYU5BM1cvdnZ1Tk1CTXVMUjQvZHFncWV5?=
 =?utf-8?B?M0NucXZzc0dETEZIbEFjeisyTXNaRHdnbHJ0dmY4cXpjR1U4ODd3cmNnZzZk?=
 =?utf-8?B?ejViZ2pkcjJ0enNRMUNUNTI1ZkNmVDZDVFhHUEtwVnFVYjQ2UW9FNXBYQktv?=
 =?utf-8?B?eUVIZ2orVlQvOXhXTmhnbjNJWkZXTlZYWHNOOG4xcmRsZFNFajVaS2IyQzQ0?=
 =?utf-8?B?WXhtQURzNFpzeTFqbTdKaEU4bDBXMFFPazJXK0NyZXl1cVN6WFFvZmNsbERF?=
 =?utf-8?B?STV5NCt0OXpuZ0xxWFdHMVRiUXFsUzBLZzVaVmVNNzU2NFluNkJzdXBwaEdH?=
 =?utf-8?B?dSszaUV6ZzJjekYwQVMvcE5FM3VDSGkxdXc5RjR1MjNWbWREMU45L3pmVzFu?=
 =?utf-8?B?TGNJVUJaaTV1RzBoeW1rSnBKaEZyeGtzV0s4aTVtc0o3NWZLSkhRdDNtSUVW?=
 =?utf-8?B?Z3BpeG1jM051Rm9nVUFUbmhEalVURVVDWmFpUEt6U0JUVmY3ZUhmS0d0THJj?=
 =?utf-8?B?R29QUGc4STZkNExMYkFOQ0l0WUdldXVhVC9oN0oyUkhpdXBGUlMwckRMUW5P?=
 =?utf-8?B?VFBvUGovbWRZMGRNWFZYazJxRStsWWFFNDA2UjhQNzU0RTJkV3hKSFh1OSsx?=
 =?utf-8?B?dU5CKzkrbHdtMVZqWXdzZ0tGTXJOVTh1R1pPdzZET2xCMHV3cStuUnpIRHNL?=
 =?utf-8?B?WVY2a0MvNklrUlhERWR6cDZsVStmVEQvV29kdmgyKzB2Y3BjQnRERXdVelVF?=
 =?utf-8?B?dEtEMCtuOVB3THZBMHA3Z2Z6UGFuZGNEZStMcjNieFp5V3VIa09WU1VkYlJk?=
 =?utf-8?B?WitLOG12aHJMdU9MbmhraXJQNkI3ajB0SUNueHA4RklRcFdsOFg0RXQ2NkVZ?=
 =?utf-8?B?U3hIVkNwNGNRWC9ubENRbk9EZ3dCc1NrV01adG1hcEtMM1AzUzdMb0orWmJI?=
 =?utf-8?B?c0pzdUQ1TDJmQlU2RnNBejVOK28ydGIwVTllSTZsVC9hUldoS2VpRGtLbERk?=
 =?utf-8?B?WjhDd3drVDhwbWVCRHUrZDdvdHVsQTdTcXlLcGtRU2ZvVUhURDEvK1Z1UHlH?=
 =?utf-8?B?djF0eW4xdlQyRDRVeW1DTzZqZWJ1aENuUkJYZ2FjVkptK3JBMDlGaGRxeFBW?=
 =?utf-8?B?ZjNDLzlJemUvZjM2WEwwNzVscktQYTA2VU5FRm12SVdnU2xqR3I1dFRlTlYw?=
 =?utf-8?B?azdOUngxTVJqQlZuMzJscEdCc1BoZTBQN2tQRnZuakRNb2RjQ0w1aWtGUGlz?=
 =?utf-8?B?WXo5djRvK25xaDliZ25iYWwxM3NJcXdsSTZZTW0wWnlpSmNpdjhqMDN0T2Jv?=
 =?utf-8?B?MHgzRGFSNHVqdGQrQmN4Sld5am9KTkxYUUM3b0RvbURUOG8wRzhIRitRRmwv?=
 =?utf-8?B?OWVKdTFKK1VrS1M4V2NxcVBKTXhFZWhqd3U3MUN6TkFmcGp6OXpXN1VtckVW?=
 =?utf-8?B?VkppeVpLN2ZBSFdvMHFGVDg5SGxYczBsaE9ueStHSmlNYU14ZDBPRTRjR3cw?=
 =?utf-8?B?RGxqZGoyYS9ESWk2ZVA0QlFEWVZMUHl4a1g5dVUrODRxc3I4VjV2Z2lkVFUw?=
 =?utf-8?B?UGZFd3E1MWJ5amNPWlY1cmhLNUE5UXlRcU5IUDNaUG1sTGxLUnMwWmNvd0Zh?=
 =?utf-8?B?Z1hHWkJVNFZTRER1OUhFYW1jV3RYRllBdnFOQlpuL2p1dW9xREVoZldJbEkx?=
 =?utf-8?B?c3RpWWVKUlVkSWZhRVlaUjlxRWJlMVR5RzQrKzZCUFcrd2U2R2Z5N2c1TkZy?=
 =?utf-8?B?VndhcHFad3pQbWRtcDV6MjA5enpMVEgwTXhYNlNUQVpBVGxtQWNydmNNOFVo?=
 =?utf-8?B?cEhtTDVYK29maUQwUWpvamlkWEszQU5pVmhWU1YrOGxCMExQOWhWSTFDbWgr?=
 =?utf-8?B?UnpZNVBaSWhmbXRHR0l5aENIV2xMYldEWkQ5YzRTTVdiaXI4UEJNNS9ZR3oz?=
 =?utf-8?Q?Ni9BHNBak2bWPuVagHYgslV2+uPFzY=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?djdPRCszdW1FZ1pIZE1HS0Rva0Zqd0N5UXg3LzhRcWNlT0FFYVJPcWhtbjR3?=
 =?utf-8?B?WFBQandsUWFUY0o4VjQ3SjgvTHQxb2JheXB5c0dqb296Z1hTUk5UQkFIR0pJ?=
 =?utf-8?B?VVJXSzFYTEVUYW93alExRFpZeklTRkw1aGRNNWpQQjZXYmVQbTEzRmRGcGp6?=
 =?utf-8?B?TVdnR1VxSXFTWGllTkl4ZlluY0g5SXdXbENyZFc2SkFzZ2hId1JVM25hNTFY?=
 =?utf-8?B?cUdvRHd3blExZUJhQzhYSHBGMmpBSEhGMWRyMDJNdXNINGh3N2tFdUErM2Ex?=
 =?utf-8?B?anJyeEo1NzJrdEhWZDZXaVB4b01NMFRTM2J5WEsvNXNGOHBWVW1SY2I5YnNQ?=
 =?utf-8?B?NHdZWC8xVFU4OWRDSldKVFh1YllmYW4wenJVdS9mRHRHT1pRV0dqVXNLRmxh?=
 =?utf-8?B?NDVZUWhaN1BDVGFNME05WlE3cktEektqTzU1dWQzMzl4RnhIaEE3Nm9qR2g4?=
 =?utf-8?B?Sm5FL095N3FNUkxYSnpPVUU3TTl5ZW01V2lLN0JqSXY0UDBpbFVzMmc1VHhp?=
 =?utf-8?B?UUdRZTFYY081ZjJmMkMzMHpzblFRamYvK1k1TjZKTnl0VkQrTmpqUExIMWhw?=
 =?utf-8?B?MXFoQjZvZEs2dFMzckdmQW02bzBLY1ZYN3Z2S0E1MDJtQkdUbyt2SDNsb2xD?=
 =?utf-8?B?cWxoOEFta3k4ZzBXTHgwdXNVaFVFOXRhbWczbktkMkxkdWs1cVpvSmNGanFy?=
 =?utf-8?B?Y1BBb2k0REJZclRYb2pNMVdjN1dSby84MVdmdGVsWEhPVTNPemloNlRicmJs?=
 =?utf-8?B?Z2docldXaEpJY1FTT1hSSnhrd3kvT2RBWjlYb3lKZmlqKzdpOHB2cUtlRFVY?=
 =?utf-8?B?aEdXMWNTK2lNQTAzeVUybXRkaDZUUkpQWlVGNEhXajc5bU8wNWpDK1ZGUU04?=
 =?utf-8?B?cHFRTDkwZld0RUxraHN6MFdqbFcvVE5BVTVFc3hYMVQwVW93ZTVVSFFsQ2My?=
 =?utf-8?B?RVhCS2ZzWTdNZnNFWTYyTTRuZFhpc0srSFpxT2UvRi9UM3JqTjl2UVZpS3FI?=
 =?utf-8?B?OThRN1ZCODAxYjIzenhNNDRqK3dmS3lBaVhVSFoxaTJaSElmT1FweGVxczhZ?=
 =?utf-8?B?KzRHMzBySVFjTkUzTVYxWktpS1g0THdaZ0ViTm9vdWFtU09QODhKMExCVUN1?=
 =?utf-8?B?T2RVMkhod2x0MXJDQURVbG82ZHlZcVdJNUFyQ09rSzNwOUxncFVOd0ZLN1FV?=
 =?utf-8?B?ejNTV0pTaDU5SWtEcENsTlhLUXN5MHhoaDhuS2J2YmVRaW9TaXpFWVRiZ1M1?=
 =?utf-8?B?SWtuV1RjVjVYeVgxamxjYXRZYTJjZlpDbFdNbW55Ty9QNUpJcWxqYlNJeGpw?=
 =?utf-8?B?a2V0Ris2aElybzg4UEJ0VmhzdXZGMDg0bVRWSlFUNk5HWmlVZ2xyRjBlKzZL?=
 =?utf-8?B?bXlaQjUzM2NOYUdPaGV0L0xsa0tiK2hoT1phaWw3MGZab0lpZkR1NTBCOEJ2?=
 =?utf-8?B?S01aU3FjMnE3YmIzc3lPL001MGE5YkNlL1p0UDU1V1FITU4rMXErb0RwNnBW?=
 =?utf-8?B?amtMMWpOaUFuV2xMVHdvbjhkRmhRTVFrRTd2Ry9WMmJhVHhWTjBmbnBkZDgx?=
 =?utf-8?B?Y2pHTmFpNk0rT3F0MHdQWkhoekFWUitDZkd6bnFSWG9OTTVGc2M2VW5ZYVpn?=
 =?utf-8?B?eEtWMDRSb05LMGtmMVFFaXRvMnNJeEVsb2RjMjRpbVc4NXF1dXJIQ0Qvc21P?=
 =?utf-8?B?Y3Y4QjIxWGpiK0FFVGp3OHFuWjVlUjU0OTdub3g3ZEZ2Y3hvY2xDYXBodFpx?=
 =?utf-8?B?cS93Y2svZ1REYTNIcldGYzZxTkxSeGVvY3JIWFFxT2hsSXFpUUUxaVh0YlhI?=
 =?utf-8?B?di8yTnJDWFhyWUI5OFAvUDJ0NTJ0TWRwQWlJdXhpTHVYWjJMMzZLN25OVzdv?=
 =?utf-8?B?SWdSSzBOclRkVFVaenlwVnN5dWJCaEZyV3hYcWVoNUloMWpQdE1JZHlQSWkx?=
 =?utf-8?B?eVhEVWVlQk1kc0hQN0lJZWZ0aFFuemREYkdJaUlvbVlHU2VIZllKNm5TcmEw?=
 =?utf-8?B?aFlQVWlKcDloOFZXYXFkT24xNlNuVktINzloR3ZlTW9EWUxDdVRRVExWTVgy?=
 =?utf-8?B?OUtoMHJtMnZQRUtBQ1RyZ2szdCtyWFF1RllhdG9Zd3FrOFQ1MVY4V0x4aHh2?=
 =?utf-8?Q?XJFA=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <14437853D0FB05438C437F018CF9CC23@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 84ddd579-aba5-4ac5-384c-08dd8d2c6225
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 05:59:52.1104
 (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: 9xvlv7ZDNNNzpkABts/tN9m3roqcVToc6GLyvihx+CqFw+Wgjx5j+kPmwbdjJr3eDhRwg8a426p5jGUwV9xwIA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB9030

T24gMjAyNS81LzYgMjI6MzcsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgQXBy
IDIxLCAyMDI1IGF0IDAyOjE4OjU3UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gUmVm
YWN0b3IgUkVHSVNURVJfVlBDSV9JTklUIHRvIGNvbnRhaW4gbW9yZSBjYXBhYmlsaXR5IHNwZWNp
ZmljDQo+PiBpbmZvcm1hdGlvbiwgdGhpcyBpcyBiZW5pZml0IGZvciBmb2xsb3ctb24gY2hhbmdl
cyB0byBoaWRlIGNhcGFiaWxpdHkNCj4+IHdoaWNoIGluaXRpYWxpemF0aW9uIGZhaWxzLg0KPj4N
Cj4+IFdoYXQncyBtb3JlLCBjaGFuZ2UgdGhlIGRlZmluaXRpb24gb2YgaW5pdF9oZWFkZXIoKSBz
aW5jZSBpdCBpcw0KPj4gbm90IGEgY2FwYWJpbGl0eSBhbmQgaXQgaXMgbmVlZGVkIGZvciBhbGwg
ZGV2aWNlcycgUENJIGNvbmZpZyBzcGFjZS4NCj4+DQo+PiBOb3RlOg0KPj4gQ2FsbCB2cGNpX21h
a2VfbXNpeF9ob2xlKCkgaW4gdGhlIGVuZCBvZiBpbml0X21zaXgoKSBzaW5jZSB0aGUNCj4+IGNo
YW5nZSBvZiBzZXF1ZW5jZSBvZiBpbml0X2hlYWRlcigpIGFuZCBpbml0X21zaXgoKS4NCj4+IFRo
ZSBmaW5pIGhvb2sgd2lsbCBiZSBpbXBsZW1lbnRlZCBpbiBmb2xsb3ctb24gY2hhbmdlcy4NCj4g
DQo+IEkgd291bGQgbWF5YmUgYWRkIHRoYXQgdGhlIGNsZWFudXAgaG9vayBpcyBhbHNvIGFkZGVk
IGluIHRoaXMgY2hhbmdlLA0KPiBldmVuIGlmIGl0J3Mgc3RpbGwgdW51c2VkLiAgRnVydGhlciBj
aGFuZ2VzIHdpbGwgbWFrZSB1c2Ugb2YgaXQuDQpEbyB5b3UgbWVhbiBJIG5lZWQgdG8gYWRkIGVt
cHR5IGZpbmlfeCgpIGZ1bmN0aW9uIGZvciBNU0ksIE1TSXgsIFJlYmFyIGluIHRoaXMgcGF0Y2g/
DQpPciBqdXN0IG5lZWQgdG8gYWRkIHRoaXMgc2VudGVuY2UgdG8gdGhlIGNvbW1pdCBtZXNzYWdl
Pw0KDQo+IA0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEppcWlhbiBDaGVuIDxKaXFpYW4uQ2hlbkBh
bWQuY29tPg0KPj4gLS0tDQo+PiBjYzogIlJvZ2VyIFBhdSBNb25uw6kiIDxyb2dlci5wYXVAY2l0
cml4LmNvbT4NCj4+IGNjOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29t
Pg0KPj4gY2M6IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEB2YXRlcy50ZWNoPg0KPj4g
Y2M6IE1pY2hhbCBPcnplbCA8bWljaGFsLm9yemVsQGFtZC5jb20+DQo+PiBjYzogSmFuIEJldWxp
Y2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPj4gY2M6IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5v
cmc+DQo+PiBjYzogU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPg0K
Pj4gLS0tDQo+PiB2Mi0+djMgY2hhbmdlczoNCj4+ICogVGhpcyBpcyBzZXBhcmF0ZWQgZnJvbSBw
YXRjaCAidnBjaTogSGlkZSBjYXBhYmlsaXR5IHdoZW4gaXQgZmFpbHMgdG8gaW5pdGlhbGl6ZSIg
b2YgdjIuDQo+PiAqIERlbGV0ZSBfX21heWJlX3VudXNlZCBhdHRyaWJ1dGUgb2YgIm91dCIgaW4g
ZnVuY3Rpb24gdnBjaV9hc3NpZ25fZGV2aWMoKS4NCj4+ICogUmVuYW1lIFJFR0lTVEVSX1ZQQ0lf
RVhURU5EX0NBUCB0byBSRUdJU1RFUl9WUENJX0VYVEVOREVEX0NBUC4NCj4+DQo+PiB2MS0+djIg
Y2hhbmdlczoNCj4+ICogUmVtb3ZlZCB0aGUgInByaW9yaXRpZXMiIG9mIGluaXRpYWxpemluZyBj
YXBhYmlsaXRpZXMgc2luY2UgaXQgaXNuJ3QgdXNlZCBhbnltb3JlLg0KPj4gKiBBZGRlZCBuZXcg
ZnVuY3Rpb24gdnBjaV9jYXBhYmlsaXR5X21hc2soKSBhbmQgdnBjaV9leHRfY2FwYWJpbGl0eV9t
YXNrKCkgdG8gcmVtb3ZlIGZhaWxlZCBjYXBhYmlsaXR5IGZyb20gbGlzdC4NCj4+ICogQ2FsbGVk
IHZwY2lfbWFrZV9tc2l4X2hvbGUoKSBpbiB0aGUgZW5kIG9mIGluaXRfbXNpeCgpLg0KPj4NCj4+
IEJlc3QgcmVnYXJkcywNCj4+IEppcWlhbiBDaGVuLg0KPj4gLS0tDQo+PiAgeGVuL2RyaXZlcnMv
dnBjaS9oZWFkZXIuYyB8ICAzICstLQ0KPj4gIHhlbi9kcml2ZXJzL3ZwY2kvbXNpLmMgICAgfCAg
MiArLQ0KPj4gIHhlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jICAgfCAgOCArKysrKy0tDQo+PiAgeGVu
L2RyaXZlcnMvdnBjaS9yZWJhci5jICB8ICAyICstDQo+PiAgeGVuL2RyaXZlcnMvdnBjaS92cGNp
LmMgICB8IDQ4ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLQ0KPj4gIHhl
bi9pbmNsdWRlL3hlbi92cGNpLmggICAgfCAyOCArKysrKysrKysrKysrKysrLS0tLS0tLQ0KPj4g
IHhlbi9pbmNsdWRlL3hlbi94ZW4ubGRzLmggfCAgMiArLQ0KPj4gIDcgZmlsZXMgY2hhbmdlZCwg
NjggaW5zZXJ0aW9ucygrKSwgMjUgZGVsZXRpb25zKC0pDQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3hl
bi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMgYi94ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jDQo+PiBp
bmRleCBlZTk0YWQ4ZTUwMzcuLmFmZTRiY2RmY2IzMCAxMDA2NDQNCj4+IC0tLSBhL3hlbi9kcml2
ZXJzL3ZwY2kvaGVhZGVyLmMNCj4+ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMNCj4+
IEBAIC04NDIsNyArODQyLDcgQEAgc3RhdGljIGludCB2cGNpX2luaXRfZXh0X2NhcGFiaWxpdHlf
bGlzdChzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+ICAgICAgcmV0dXJuIDA7DQo+PiAgfQ0KPj4g
IA0KPj4gLXN0YXRpYyBpbnQgY2ZfY2hlY2sgaW5pdF9oZWFkZXIoc3RydWN0IHBjaV9kZXYgKnBk
ZXYpDQo+PiAraW50IHZwY2lfaW5pdF9oZWFkZXIoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAg
ew0KPj4gICAgICB1aW50MTZfdCBjbWQ7DQo+PiAgICAgIHVpbnQ2NF90IGFkZHIsIHNpemU7DQo+
PiBAQCAtMTAzOCw3ICsxMDM4LDYgQEAgc3RhdGljIGludCBjZl9jaGVjayBpbml0X2hlYWRlcihz
dHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+ICAgICAgcGNpX2NvbmZfd3JpdGUxNihwZGV2LT5zYmRm
LCBQQ0lfQ09NTUFORCwgY21kKTsNCj4+ICAgICAgcmV0dXJuIHJjOw0KPj4gIH0NCj4+IC1SRUdJ
U1RFUl9WUENJX0lOSVQoaW5pdF9oZWFkZXIsIFZQQ0lfUFJJT1JJVFlfTUlERExFKTsNCj4+ICAN
Cj4+ICAvKg0KPj4gICAqIExvY2FsIHZhcmlhYmxlczoNCj4+IGRpZmYgLS1naXQgYS94ZW4vZHJp
dmVycy92cGNpL21zaS5jIGIveGVuL2RyaXZlcnMvdnBjaS9tc2kuYw0KPj4gaW5kZXggNjZlNWE4
YTExNmJlLi5lYTdkYzBjMDYwZWEgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL21z
aS5jDQo+PiArKysgYi94ZW4vZHJpdmVycy92cGNpL21zaS5jDQo+PiBAQCAtMjcwLDcgKzI3MCw3
IEBAIHN0YXRpYyBpbnQgY2ZfY2hlY2sgaW5pdF9tc2koc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+
PiAgDQo+PiAgICAgIHJldHVybiAwOw0KPj4gIH0NCj4+IC1SRUdJU1RFUl9WUENJX0lOSVQoaW5p
dF9tc2ksIFZQQ0lfUFJJT1JJVFlfTE9XKTsNCj4+ICtSRUdJU1RFUl9WUENJX0xFR0FDWV9DQVAo
UENJX0NBUF9JRF9NU0ksIGluaXRfbXNpLCBOVUxMKTsNCj4+ICANCj4+ICB2b2lkIHZwY2lfZHVt
cF9tc2kodm9pZCkNCj4+ICB7DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvdnBjaS9tc2l4
LmMgYi94ZW4vZHJpdmVycy92cGNpL21zaXguYw0KPj4gaW5kZXggNmJkOGM1NWJiNDhlLi4wMjI4
ZmZkOWZkYTkgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL21zaXguYw0KPj4gKysr
IGIveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMNCj4+IEBAIC03NTEsOSArNzUxLDEzIEBAIHN0YXRp
YyBpbnQgY2ZfY2hlY2sgaW5pdF9tc2l4KHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4gICAgICBw
ZGV2LT52cGNpLT5tc2l4ID0gbXNpeDsNCj4+ICAgICAgbGlzdF9hZGQoJm1zaXgtPm5leHQsICZk
LT5hcmNoLmh2bS5tc2l4X3RhYmxlcyk7DQo+PiAgDQo+PiAtICAgIHJldHVybiAwOw0KPj4gKyAg
ICBzcGluX2xvY2soJnBkZXYtPnZwY2ktPmxvY2spOw0KPj4gKyAgICByYyA9IHZwY2lfbWFrZV9t
c2l4X2hvbGUocGRldik7DQo+PiArICAgIHNwaW5fdW5sb2NrKCZwZGV2LT52cGNpLT5sb2NrKTsN
Cj4+ICsNCj4+ICsgICAgcmV0dXJuIHJjOw0KPj4gIH0NCj4+IC1SRUdJU1RFUl9WUENJX0lOSVQo
aW5pdF9tc2l4LCBWUENJX1BSSU9SSVRZX0hJR0gpOw0KPj4gK1JFR0lTVEVSX1ZQQ0lfTEVHQUNZ
X0NBUChQQ0lfQ0FQX0lEX01TSVgsIGluaXRfbXNpeCwgTlVMTCk7DQo+PiAgDQo+PiAgLyoNCj4+
ICAgKiBMb2NhbCB2YXJpYWJsZXM6DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvdnBjaS9y
ZWJhci5jIGIveGVuL2RyaXZlcnMvdnBjaS9yZWJhci5jDQo+PiBpbmRleCA3OTM5Mzc0NDlhZjcu
LjAyNmY4Zjc5NzJkOSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9kcml2ZXJzL3ZwY2kvcmViYXIuYw0K
Pj4gKysrIGIveGVuL2RyaXZlcnMvdnBjaS9yZWJhci5jDQo+PiBAQCAtMTE4LDcgKzExOCw3IEBA
IHN0YXRpYyBpbnQgY2ZfY2hlY2sgaW5pdF9yZWJhcihzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+
ICANCj4+ICAgICAgcmV0dXJuIDA7DQo+PiAgfQ0KPj4gLVJFR0lTVEVSX1ZQQ0lfSU5JVChpbml0
X3JlYmFyLCBWUENJX1BSSU9SSVRZX0xPVyk7DQo+PiArUkVHSVNURVJfVlBDSV9FWFRFTkRFRF9D
QVAoUENJX0VYVF9DQVBfSURfUkVCQVIsIGluaXRfcmViYXIsIE5VTEwpOw0KPj4gIA0KPj4gIC8q
DQo+PiAgICogTG9jYWwgdmFyaWFibGVzOg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Zw
Y2kvdnBjaS5jIGIveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMNCj4+IGluZGV4IDMzNDliOTgzODli
OC4uNTQ3NGI2NjY2OGMxIDEwMDY0NA0KPj4gLS0tIGEveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMN
Cj4+ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jDQo+PiBAQCAtMzYsOCArMzYsOCBAQCBz
dHJ1Y3QgdnBjaV9yZWdpc3RlciB7DQo+PiAgfTsNCj4+ICANCj4+ICAjaWZkZWYgX19YRU5fXw0K
Pj4gLWV4dGVybiB2cGNpX3JlZ2lzdGVyX2luaXRfdCAqY29uc3QgX19zdGFydF92cGNpX2FycmF5
W107DQo+PiAtZXh0ZXJuIHZwY2lfcmVnaXN0ZXJfaW5pdF90ICpjb25zdCBfX2VuZF92cGNpX2Fy
cmF5W107DQo+PiArZXh0ZXJuIHZwY2lfY2FwYWJpbGl0eV90ICpjb25zdCBfX3N0YXJ0X3ZwY2lf
YXJyYXlbXTsNCj4+ICtleHRlcm4gdnBjaV9jYXBhYmlsaXR5X3QgKmNvbnN0IF9fZW5kX3ZwY2lf
YXJyYXlbXTsNCj4+ICAjZGVmaW5lIE5VTV9WUENJX0lOSVQgKF9fZW5kX3ZwY2lfYXJyYXkgLSBf
X3N0YXJ0X3ZwY2lfYXJyYXkpDQo+PiAgDQo+PiAgI2lmZGVmIENPTkZJR19IQVNfVlBDSV9HVUVT
VF9TVVBQT1JUDQo+PiBAQCAtODMsNiArODMsMzYgQEAgc3RhdGljIGludCBhc3NpZ25fdmlydHVh
bF9zYmRmKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4gIA0KPj4gICNlbmRpZiAvKiBDT05GSUdf
SEFTX1ZQQ0lfR1VFU1RfU1VQUE9SVCAqLw0KPj4gIA0KPj4gK3N0YXRpYyBpbnQgdnBjaV9pbml0
X2NhcGFiaWxpdGllcyhzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+ICt7DQo+PiArICAgIGZvciAo
IHVuc2lnbmVkIGludCBpID0gMDsgaSA8IE5VTV9WUENJX0lOSVQ7IGkrKyApDQo+PiArICAgIHsN
Cj4+ICsgICAgICAgIGNvbnN0IHZwY2lfY2FwYWJpbGl0eV90ICpjYXBhYmlsaXR5ID0gX19zdGFy
dF92cGNpX2FycmF5W2ldOw0KPj4gKyAgICAgICAgY29uc3QgdW5zaWduZWQgaW50IGNhcCA9IGNh
cGFiaWxpdHktPmlkOw0KPj4gKyAgICAgICAgY29uc3QgYm9vbCBpc19leHQgPSBjYXBhYmlsaXR5
LT5pc19leHQ7DQo+PiArICAgICAgICB1bnNpZ25lZCBpbnQgcG9zOw0KPj4gKyAgICAgICAgaW50
IHJjOw0KPj4gKw0KPj4gKyAgICAgICAgaWYgKCAhaXNfaGFyZHdhcmVfZG9tYWluKHBkZXYtPmRv
bWFpbikgJiYgaXNfZXh0ICkNCj4+ICsgICAgICAgICAgICBjb250aW51ZTsNCj4+ICsNCj4+ICsg
ICAgICAgIGlmICggIWlzX2V4dCApDQo+PiArICAgICAgICAgICAgcG9zID0gcGNpX2ZpbmRfY2Fw
X29mZnNldChwZGV2LT5zYmRmLCBjYXApOw0KPj4gKyAgICAgICAgZWxzZQ0KPj4gKyAgICAgICAg
ICAgIHBvcyA9IHBjaV9maW5kX2V4dF9jYXBhYmlsaXR5KHBkZXYtPnNiZGYsIGNhcCk7DQo+PiAr
DQo+PiArICAgICAgICBpZiAoICFwb3MgfHwgIWNhcGFiaWxpdHktPmluaXQgKQ0KPiANCj4gSXNu
J3QgaXQgYm9ndXMgdG8gaGF2ZSBhIHZwY2lfY2FwYWJpbGl0eV90IGVudHJ5IHdpdGggYSBOVUxM
IGluaXQNCj4gZnVuY3Rpb24/DQpTaW5jZSBJIGRvbid0IGFkZCBmaW5pX3goKSBmdW5jdGlvbiBm
b3IgY2FwYWJpbGl0aWVzIGFuZCBhbHNvIGFkZCBjaGVjayAiaWYgKCBjYXBhYmlsaXR5LT5maW5p
ICkiIGJlbG93LA0Kc28gSSBhZGQgdGhpcyBOVUxMIGNoZWNrIGhlcmUuDQpJIHdpbGwgcmVtb3Zl
IGl0IGlmIHlvdSB0aGluayBpdCBpcyB1bm5lY2Vzc2FyeS4NClNob3VsZCBJIGFsc28gcmVtb3Zl
IHRoZSBOVUxMIGNoZWNrIGZvciBmaW5pPw0KDQo+IA0KPj4gKyAgICAgICAgICAgIGNvbnRpbnVl
Ow0KPj4gKw0KPj4gKyAgICAgICAgcmMgPSBjYXBhYmlsaXR5LT5pbml0KHBkZXYpOw0KPj4gKw0K
PiANCj4gSSB3b3VsZG4ndCBhZGQgYSBuZXdsaW5lIGJldHdlZW4gdGhlIGZ1bmN0aW9uIGNhbGwg
YW5kIGNoZWNraW5nIHRoZQ0KPiByZXR1cm4gdmFsdWUsIGJ1dCB0aGF0J3MganVzdCBteSB0YXN0
ZS4NCldpbGwgZG8uDQo+IA0KPj4gKyAgICAgICAgaWYgKCByYyApDQo+PiArICAgICAgICAgICAg
cmV0dXJuIHJjOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldHVybiAwOw0KPj4gK30NCj4+
ICsNCj4+ICB2b2lkIHZwY2lfZGVhc3NpZ25fZGV2aWNlKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0K
Pj4gIHsNCj4+ICAgICAgdW5zaWduZWQgaW50IGk7DQo+PiBAQCAtMTI4LDcgKzE1OCw2IEBAIHZv
aWQgdnBjaV9kZWFzc2lnbl9kZXZpY2Uoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAgDQo+PiAg
aW50IHZwY2lfYXNzaWduX2RldmljZShzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+ICB7DQo+PiAt
ICAgIHVuc2lnbmVkIGludCBpOw0KPj4gICAgICBjb25zdCB1bnNpZ25lZCBsb25nICpyb19tYXA7
DQo+PiAgICAgIGludCByYyA9IDA7DQo+PiAgDQo+PiBAQCAtMTU5LDE0ICsxODgsMTMgQEAgaW50
IHZwY2lfYXNzaWduX2RldmljZShzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+ICAgICAgICAgIGdv
dG8gb3V0Ow0KPj4gICNlbmRpZg0KPj4gIA0KPj4gLSAgICBmb3IgKCBpID0gMDsgaSA8IE5VTV9W
UENJX0lOSVQ7IGkrKyApDQo+PiAtICAgIHsNCj4+IC0gICAgICAgIHJjID0gX19zdGFydF92cGNp
X2FycmF5W2ldKHBkZXYpOw0KPj4gLSAgICAgICAgaWYgKCByYyApDQo+PiAtICAgICAgICAgICAg
YnJlYWs7DQo+PiAtICAgIH0NCj4+ICsgICAgcmMgPSB2cGNpX2luaXRfaGVhZGVyKHBkZXYpOw0K
Pj4gKyAgICBpZiAoIHJjICkNCj4+ICsgICAgICAgIGdvdG8gb3V0Ow0KPj4gKw0KPj4gKyAgICBy
YyA9IHZwY2lfaW5pdF9jYXBhYmlsaXRpZXMocGRldik7DQo+PiAgDQo+PiAtIG91dDogX19tYXli
ZV91bnVzZWQ7DQo+PiArIG91dDoNCj4+ICAgICAgaWYgKCByYyApDQo+PiAgICAgICAgICB2cGNp
X2RlYXNzaWduX2RldmljZShwZGV2KTsNCj4+ICANCj4+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVk
ZS94ZW4vdnBjaS5oIGIveGVuL2luY2x1ZGUveGVuL3ZwY2kuaA0KPj4gaW5kZXggOWQ0N2I4YzFh
NTBlLi44ZTgxNWI0MThiN2QgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vaW5jbHVkZS94ZW4vdnBjaS5o
DQo+PiArKysgYi94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQo+PiBAQCAtMTMsMTEgKzEzLDEyIEBA
IHR5cGVkZWYgdWludDMyX3QgdnBjaV9yZWFkX3QoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYs
IHVuc2lnbmVkIGludCByZWcsDQo+PiAgdHlwZWRlZiB2b2lkIHZwY2lfd3JpdGVfdChjb25zdCBz
dHJ1Y3QgcGNpX2RldiAqcGRldiwgdW5zaWduZWQgaW50IHJlZywNCj4+ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHVpbnQzMl90IHZhbCwgdm9pZCAqZGF0YSk7DQo+PiAgDQo+PiAtdHlwZWRl
ZiBpbnQgdnBjaV9yZWdpc3Rlcl9pbml0X3Qoc3RydWN0IHBjaV9kZXYgKmRldik7DQo+PiAtDQo+
PiAtI2RlZmluZSBWUENJX1BSSU9SSVRZX0hJR0ggICAgICAiMSINCj4+IC0jZGVmaW5lIFZQQ0lf
UFJJT1JJVFlfTUlERExFICAgICI1Ig0KPj4gLSNkZWZpbmUgVlBDSV9QUklPUklUWV9MT1cgICAg
ICAgIjkiDQo+PiArdHlwZWRlZiBzdHJ1Y3Qgew0KPj4gKyAgICB1bnNpZ25lZCBpbnQgaWQ7DQo+
PiArICAgIGJvb2wgaXNfZXh0Ow0KPj4gKyAgICBpbnQgKCppbml0KShzdHJ1Y3QgcGNpX2RldiAq
cGRldik7DQo+PiArICAgIHZvaWQgKCpmaW5pKShzdHJ1Y3QgcGNpX2RldiAqcGRldik7DQo+PiAr
fSB2cGNpX2NhcGFiaWxpdHlfdDsNCj4+ICANCj4+ICAjZGVmaW5lIFZQQ0lfRUNBTV9CREYoYWRk
cikgICAgICgoKGFkZHIpICYgMHgwZmZmZjAwMCkgPj4gMTIpDQo+PiAgDQo+PiBAQCAtMjksOSAr
MzAsMjAgQEAgdHlwZWRlZiBpbnQgdnBjaV9yZWdpc3Rlcl9pbml0X3Qoc3RydWN0IHBjaV9kZXYg
KmRldik7DQo+PiAgICovDQo+PiAgI2RlZmluZSBWUENJX01BWF9WSVJUX0RFViAgICAgICAoUENJ
X1NMT1QofjApICsgMSkNCj4+ICANCj4+IC0jZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfSU5JVCh4LCBw
KSAgICAgICAgICAgICAgICBcDQo+PiAtICBzdGF0aWMgdnBjaV9yZWdpc3Rlcl9pbml0X3QgKmNv
bnN0IHgjI19lbnRyeSAgXA0KPj4gLSAgICAgICAgICAgICAgIF9fdXNlZF9zZWN0aW9uKCIuZGF0
YS52cGNpLiIgcCkgPSAoeCkNCj4+ICsjZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfQ0FQKGNhcCwgeCwg
eSwgZXh0KSBcDQo+IA0KPiB4IGFuZCB5IGFyZSBub3QgdmVyeSBoZWxwZnVsIGlkZW50aWZpZXIg
bmFtZXMsIGJldHRlciB1c2Ugc29tZSBtb3JlDQo+IGRlc2NyaXB0aXZlIG5hbWluZywgaW5pdCBh
bmQgZmluaT8gIFNhbWUgYmVsb3cuDQppbml0IGFuZCBmaW5pIHNlZW1zIG5vdCBnb29kLiBUaGV5
IGFyZSBjb25mbGljdCB3aXRoIHRoZSBob29rIG5hbWUgb2YgYmVsb3cgdnBjaV9jYXBhYmlsaXR5
X3QuDQpNYXliZSBpbml0X2Z1bmMgYW5kIGZpbmlfZnVuYyA/DQoNCj4gDQo+PiArICBzdGF0aWMg
dnBjaV9jYXBhYmlsaXR5X3QgeCMjX3QgPSB7IFwNCj4+ICsgICAgICAgIC5pZCA9IChjYXApLCBc
DQo+PiArICAgICAgICAuaW5pdCA9ICh4KSwgXA0KPj4gKyAgICAgICAgLmZpbmkgPSAoeSksIFwN
Cj4+ICsgICAgICAgIC5pc19leHQgPSAoZXh0KSwgXA0KPj4gKyAgfTsgXA0KPj4gKyAgc3RhdGlj
IHZwY2lfY2FwYWJpbGl0eV90ICpjb25zdCB4IyNfZW50cnkgIFwNCj4+ICsgICAgICAgICAgICAg
ICBfX3VzZWRfc2VjdGlvbigiLmRhdGEudnBjaS4iKSA9ICYoeCMjX3QpDQo+PiArDQo+PiArI2Rl
ZmluZSBSRUdJU1RFUl9WUENJX0xFR0FDWV9DQVAoY2FwLCB4LCB5KSBSRUdJU1RFUl9WUENJX0NB
UChjYXAsIHgsIHksIGZhbHNlKQ0KPj4gKyNkZWZpbmUgUkVHSVNURVJfVlBDSV9FWFRFTkRFRF9D
QVAoY2FwLCB4LCB5KSBSRUdJU1RFUl9WUENJX0NBUChjYXAsIHgsIHksIHRydWUpDQo+PiArDQo+
PiAraW50IF9fbXVzdF9jaGVjayB2cGNpX2luaXRfaGVhZGVyKHN0cnVjdCBwY2lfZGV2ICpwZGV2
KTsNCj4+ICANCj4+ICAvKiBBc3NpZ24gdlBDSSB0byBkZXZpY2UgYnkgYWRkaW5nIGhhbmRsZXJz
LiAqLw0KPj4gIGludCBfX211c3RfY2hlY2sgdnBjaV9hc3NpZ25fZGV2aWNlKHN0cnVjdCBwY2lf
ZGV2ICpwZGV2KTsNCj4+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4veGVuLmxkcy5oIGIv
eGVuL2luY2x1ZGUveGVuL3hlbi5sZHMuaA0KPj4gaW5kZXggMTZhOWIxYmEwM2RiLi5jNzMyMjIx
MTJkZDMgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vaW5jbHVkZS94ZW4veGVuLmxkcy5oDQo+PiArKysg
Yi94ZW4vaW5jbHVkZS94ZW4veGVuLmxkcy5oDQo+PiBAQCAtMTg3LDcgKzE4Nyw3IEBADQo+PiAg
I2RlZmluZSBWUENJX0FSUkFZICAgICAgICAgICAgICAgXA0KPj4gICAgICAgICAuID0gQUxJR04o
UE9JTlRFUl9BTElHTik7IFwNCj4+ICAgICAgICAgX19zdGFydF92cGNpX2FycmF5ID0gLjsgICBc
DQo+PiAtICAgICAgICooU09SVCguZGF0YS52cGNpLiopKSAgICAgXA0KPj4gKyAgICAgICAqKC5k
YXRhLnZwY2kuKikgICAgIFwNCj4gDQo+IEFzaWRlIGZyb20gSmFuIGNvbW1lbnQsIHBsZWFzZSBr
ZWVwIHRoZSAnXCcgYWxpZ25lZCB3aXRoIHRoZSBvdGhlcnMgb24NCj4gdGhlIGJsb2NrLg0KV2ls
bCBkby4NCg0KPiANCj4gVGhhbmtzLCBSb2dlci4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFp
YW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Wed May 07 06:12:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 06:12:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978205.1365041 (Exim 4.92)
	(envelope-from )
	id 1uCY0z-0002Jv-S8; Wed, 07 May 2025 06:12:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978205.1365041; Wed, 07 May 2025 06:12: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 1uCY0z-0002Jo-Om; Wed, 07 May 2025 06:12:21 +0000
Received: by outflank-mailman (input) for mailman id 978205;
 Wed, 07 May 2025 06:12:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCY0x-0002Je-T6
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 06:12:19 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2062a.outbound.protection.outlook.com
 [2a01:111:f403:2413::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3a063da8-2b0a-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 08:12:18 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CY8PR12MB8066.namprd12.prod.outlook.com (2603:10b6:930:70::5) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8699.26; Wed, 7 May 2025 06:12:11 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Wed, 7 May 2025
 06:12: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" 
X-Inumbo-ID: 3a063da8-2b0a-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=v8BHaQmhg7F64FSbzXe4OGMod+bCuOVYGjpTlbrBMaUz1GN+AVFC8BHG1pyoM9LzEjiJkRUHNJxDaiSDZXVfo8didfYFqpdoeTTs39olSmO+KxufXGKbnTFMWT3RDNuF9Snnngq8Gs85m90lVPh9LXZBdmHqJskWTIWc5uUeJRjRRyFPhboxeEhmnylBTMn/HGhvp0aNe7oJFnY3MHi8qPi50t1Uxn82kCAkNY05k//IFdzU6Jd8L9YumhmahNlxgHX/JlWCyKM+iQQkaIIlEqPYTWgqCKj0kQTc9nD8U7cNySGfyJtGZ4qWYIp+Qflbx/RdnUxGq0yZKs64cc2SpA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qScM/HNPsHuM5fcWLL01+zdYCBxtF8vmW0h8LWyZ78A=;
 b=W0ba6zqJee8YnR1Sor6WmLjRw1ZvYNGlUN83OTelDvo2mcpzcVd0xzT9y/gFzpbNHcsaU/UtvKLvdTPtVN+gY9qG2kkle3IYsKNPMjjDyy7DwzyG4S1KBuYzNGqXSGmaJcK91dDic6vUiiOAPC1n2sCDBmdKIkemhoI2+LtA7cbAQKsbzm0lFketnE3edGnSrENR29Ts/+kCH8GcTK4rzhpPiX7wS9dPzVXbweEv82XF9v/y6RUV1bdCnaey+ExygO36nEVycMDm7m81LVY/Fc/NauIJK15iMOzSTroCIXl1gq94G1kwJ2GiJv3L6mQWwndGchmDcS3vzTdSBtDQTw==
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=qScM/HNPsHuM5fcWLL01+zdYCBxtF8vmW0h8LWyZ78A=;
 b=1Gzn9hDOH6+ck/pmlS2jvpujcDjABK6mQ28YrgNAnpgk1VtGzG/R3QBJFM72VkkqfPOFE0C0dTXb9FKYOxUZMMfNJeAcscCNErEf2tJlJCPl75CB7rQSkEgOPoiLptLN9KmwIiWcRilH3g5POP1Zd+pJzXN90RuGFOiN9pexfK8=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 07/15] xen/cpufreq: fix core frequency calculation for
 AMD Family 1Ah CPUs
Thread-Topic: [PATCH v4 07/15] xen/cpufreq: fix core frequency calculation for
 AMD Family 1Ah CPUs
Thread-Index: AQHbrRCpjadEsJgkvkaYqq8R9zYjVrOn/wMAgB7NzCA=
Date: Wed, 7 May 2025 06:12:11 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-8-Penny.Zheng@amd.com>
 <8b87f6c4-ebc7-4d13-8fe6-a56df6b76523@suse.com>
In-Reply-To: <8b87f6c4-ebc7-4d13-8fe6-a56df6b76523@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=1c164910-7122-49ab-8719-3ada28a77e73;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-07T06:11:40Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|CY8PR12MB8066:EE_
x-ms-office365-filtering-correlation-id: b46ed75d-7fbc-4c6a-84c2-08dd8d2e1ac4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?Sm5mWWE3ejlDbGk2clUrZ2FqMjA0K0o4OCtRSUIvZjNmZ2pNNTFGa2FVOWkx?=
 =?utf-8?B?a1pyTXRUa3RVTjVHMGhPU2lTYjJVQ3d1TzNsT0ppWE5MTld5RW5oanZiM2RO?=
 =?utf-8?B?dFdDZHlwZ3hqeW1FVytzUTloUkxza3VXWGQreUlwa1FQUE45K2dJSFhyQXIy?=
 =?utf-8?B?NFdwUURmZlYzVU13Vm1lMHI4bmZiTCs3NUtBQlk0NW1UT2JxUmFzNGNBR3NR?=
 =?utf-8?B?NU90SzNvM1NuRFUwekJCY3Zia1pHUFJpZnZROVU5UTNWOUh5bi9lbHZGa3o3?=
 =?utf-8?B?aTBYWGRWZXZ5NXFnZXVUUThLUDJicnZJTDVrZjFQdjEvajRoU0ticHNwSExI?=
 =?utf-8?B?Nm9qN0kySll3bTdmcVRuK2Y5VmNGT1B5V0sxcWcrYytOWW1JUU01WVFtNElX?=
 =?utf-8?B?NVltd243TUF2SnhqTzhrdktkQVJBVVN3NHpNd0NoS2FzRmhGeG9zMXhyRmRn?=
 =?utf-8?B?UjZVbEh3QkpMSHhCUVZIS09BNHJucjlrMjRoV21RM3RSc3gxOGhNTFlzdUxl?=
 =?utf-8?B?M1JqYVNBWlZDMThZRldReXp6WHUwS3NudXFzQ2sxcUJFRnp3dDRHRmxmV01O?=
 =?utf-8?B?ZGFkWFlXTHN3L2VHWXVLZ2svZU5aM3VvY3FkY0dVNnE1ellJYVEyNnFDY1ZX?=
 =?utf-8?B?bk1GTTFzSExXUmRMcWhyelJBaS9zTkZBWVlzdEdSNXYrQU5RL1lxbGo5dWh0?=
 =?utf-8?B?d0dmNnQvN2c0N25CUHdUcU0wN0FiYWM2UGc0bkd1NXdnZzAyN3NFRHJKY0Nn?=
 =?utf-8?B?NGIvQkVHM0ZUN0FseGQ0SmVmZkN0cVc2TzBTc2drYWJXMWF0WllJaGVzTlgw?=
 =?utf-8?B?SWRzdnBnRXZ0Y0tGdjVscm4wUmVRRXgrQTdodmVQY1pyVEI0ZXR1VFpzTzUv?=
 =?utf-8?B?NjY5c21aYUMxVHZDZW8rdkplbnlKL3pveE8rdWdxT2c5VTVHcG5URmxtc3o3?=
 =?utf-8?B?azlmZ3pIRm13UVpSY1lnVm9iS0FQb0xhdnZZSU56aTdBbXUxMGNINUszelpL?=
 =?utf-8?B?RGROZlM2Nk4rcEtQR1R0TVFobDZybGhEVFRuV1VXa2xtOUxPTVpVY3hBRUNm?=
 =?utf-8?B?ZVVCSFRHMTVmRWh6YWN5R2pTZlkyazE4bTcyamFleXJXejY1NnBFTkxoZUZK?=
 =?utf-8?B?M2FiR1ZQZDR3UGlkRGFPY3BFdElNZndQcldOUVl0UndwM0lLRWUxWHJ6cUJ4?=
 =?utf-8?B?ZGFNWmhxWEY1MUJ3THZrbmxIYUlZYzBEczVYSTdkS2F3R1dRMGRmeHRBUVVI?=
 =?utf-8?B?ME5OakNCNW9MS2ZtN2Y3a1JiV0wzSXNpTHl4UVd3WjI3M01wM3FnR2ljTGU4?=
 =?utf-8?B?eGxRY3RWbmlNa29YKzJieUd0VE1zQUJZUzZFL1pCS3lsYllTQVRVUDBsZUFF?=
 =?utf-8?B?T3NSMmdaVndCU3NPdldWT2dVckdnM1VDb0JnUzAyNkZmOEt0Rk1iR012SUtD?=
 =?utf-8?B?RXEydmcxcjkxZzdjTXpFTC9TK3NWaXlQWm5wWFBlVGRrdUxSS3l2Zi9oUHNv?=
 =?utf-8?B?NnNjN1JTa0JLRnpDZWpOMzd0b2Q1VTZGNVpaTjRkRTVITCtjc0JxTFo5Rmx2?=
 =?utf-8?B?NjUrL0doOXZqU2RnQmNnZG9OK2hsSFZGMDBKVU5rdHhTWjZGU0JjUnArOUtx?=
 =?utf-8?B?d3h0bURKdVMrLytjTHBQWjV1dU5OZkdFcFlvR0kzNXlLTWU3eFY5T21FeG9R?=
 =?utf-8?B?bnBQN2QrMENVaVZkUTNxSWZnZ1Z5N25hWE9NcWtwdkhWVHBab3lFUW5RL2sv?=
 =?utf-8?B?M04reDVrY0JDbnNrNkRkTWMrSkk5VUl2OHRqMjEydU5RQjhINkEwQXQwZERy?=
 =?utf-8?B?U1FQY1JXMEhzV0MyUW5nQUtwYkVKL3RxN3ZJbk1YOE5SZTUzemxOTW44Q3Ez?=
 =?utf-8?B?WXV4VUpNV1A2bEVtYk4zaEV1c1Z0RzJLZWtNV2JhbzBUM1lYVjEyTWpGcGVZ?=
 =?utf-8?B?OHY3amdQc3h2MDkyZHdHOXJVMTNwbzNkVUkrai8xSzhlT3BjaWRQdEpRRWk4?=
 =?utf-8?Q?P9+tgawparnH0J9AGLbEGoewjvOudw=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?R1ZCQytBZ1BiR1NVMndtQ2lrMngrbzQ3MFJjUmhpTWlFblFWN1JiNE1lVHNU?=
 =?utf-8?B?WUtZNWZhZmtleStVWk1DaCs5em52dm1peVNvUXpobE1TVWwrc0FYeWcrcEZR?=
 =?utf-8?B?UkhDVzdIMDh0SmNPWXU0VlFOcmNlWnE0V1pWbHYvL3puYmJJZk5BYWh3a0Zk?=
 =?utf-8?B?bWlZNGRrSE9SenpnckNhek1IUkxUUmduNXJLQXRlQURSZnFsMkNxTEVOb21i?=
 =?utf-8?B?WThzOW5lQVFhS1RBRkhDQktJbXpaTTl5aVBkTmdEdUZWbklVbkMzU3V5QjA0?=
 =?utf-8?B?S3hUQU40MkpuUHNkTDk5Zi9xcWtVWjc2a2dGVFU3S0JOTWtrU0NFTW9uamRa?=
 =?utf-8?B?NjJSNUs4QytmUG84MnUxbGUyRnBZbVpQUVlqeVpDRkJ4YUl4OFA1MVJsZ0sz?=
 =?utf-8?B?THAvUkgvWUxXd1hIMXpTd21XZXRaMHNRYjNQTU96OGpCQkdOZnJsd0U0TVE2?=
 =?utf-8?B?RXRveURDSDQrQzdNTlZwSjBvUExGVmZ5TU45WmlNdk9TLzZDRkwyMUsyeGdJ?=
 =?utf-8?B?YWN5cVdnL3J2NEZGOS9QNDM0dTEwZ0Eram1sSHNrbGlkbWlBK0VnMWtjNDFk?=
 =?utf-8?B?NXZXdzdSMkE1L2Q0QWRleXI2TFRScnlsSGhqYXBZS2VuY1ZwYXBHT1l3MmZV?=
 =?utf-8?B?dFFsTGUyNFQ2aEQyNDlVZytFMUxhMVdoTkRDS01Ga2hJSjlQU0JZZlFoblor?=
 =?utf-8?B?TVBrdERiWGo2WWhIdE5ZeG03MXJMZVJWbTRMeWdmeS9MRUdLY3NrZk5wT3hM?=
 =?utf-8?B?WkVDV2Z3SU9NWENFRVRMWVg4dFVuSFFZcGxFSEtpelZ5Y3A5VnVUYnVzeWdx?=
 =?utf-8?B?aUZiZmhSQjZQbTZMdWp2UldzRHM3TzJwZGJQRXVWeDJZRDVwcFVUd2E5Sjdq?=
 =?utf-8?B?d3UxVCs0bzBlczVBMWRGRUU0Z1pPNWc5c1ZmcDdSdXRXVSsyU3lCTXJxaklW?=
 =?utf-8?B?VFhla0g4b1dPSk9nYmpoa3Frem9IRXRMT2dNUFdRaDBhNlovbnk5WjFUUTB4?=
 =?utf-8?B?aGc1ZkpBdUl6Z3E2bU90QkFDbUVrZDV1eEg2WE9YdGdxK2xwR0FzK1RVc2ZE?=
 =?utf-8?B?UGlTN0ozUEg3UGJzNGN3MGhUVE93UHRVMVErcXNnQUlkS2dCTHBnQWtiYmZj?=
 =?utf-8?B?b0NJazZsL0Mvc1pYMjEzc2dPdk1UR2hrM0NITWNoc0ZXL1FuWEF3UGZUbXR6?=
 =?utf-8?B?SkJCRWZvSXZDWC93R080MW5TeGhXMm0yRGFFaHh2YVhoWFBIdWZEVFl4ZEdU?=
 =?utf-8?B?cXJGMkd1alpXNDFjMC92M3lHRWxkWFZMVTdKTldnS0JNczlsQk5EODZsdzFS?=
 =?utf-8?B?c0M1VFd1WjdMdjZnMVo1dmt6UzFTVkF5OWJwQnVaVjdQbmFlVHR5ZjBkU2ZT?=
 =?utf-8?B?eGM4aGdxSG5Ham5ITjdVV3VyeXJHVXRWQTNXUUY3cmhrbUxKRktFRjRDTUVh?=
 =?utf-8?B?QU1IUitvdERkdVdBZWllc0RwSms5VFcreVUvbnBySGZWRzhRS3JxdnFycFpC?=
 =?utf-8?B?VnZZTTZidi8rSytTb0FvRHdkSzFNYlVlTU1BbzJKZXlUcHErMTF4YkhVWlpi?=
 =?utf-8?B?UHhxWFpuVjgyTnFiNkF0TkJ0cXBxWUh2bk9MUENNYnFKOW01SkoxU3RlODVh?=
 =?utf-8?B?NU1PQ1NIdjlIcTlhczNZaklSTGZUNW9peGFaam8vNEZZNUJEbXp5UDVhazBS?=
 =?utf-8?B?Qk1sdnJhNVlnNjhMc0ZlMFdXQkc5MDJsMVoyK3R6RWQ1UW9iMEtPTGhLelI3?=
 =?utf-8?B?T1lqcG8raVJocjNQTy9mejROQWxpVGZlamFkVXB2TDJGR203TXUzenlRRnJo?=
 =?utf-8?B?UHNhNktuYmFmWUNIbXZ3VEE1TWRnekdUL0p3THFuYjNvbUMvT2ZvR2VycXRN?=
 =?utf-8?B?K1VWcG43NncwTm00UURrVUgyT1dNaVdmTis5TDZVeEZENXRBYUpNYUwxMERs?=
 =?utf-8?B?U1NJUUVZd2l6RW1WOUtyZHNhMUltUkVUbndrMk9Ta0EzeTZlTGQ1cWs1bXdx?=
 =?utf-8?B?SmJDbldhMTFYVUl5eUVXemZUSjVMcDRNM1JNaE5xZ21tMWEveTJDQjVhMG1F?=
 =?utf-8?B?eXZPOERTKytTMVR2Y1M1TDVwYUpQNmtrcFRBVWlZOWVpNEI4bFhXaXR4TXRt?=
 =?utf-8?Q?I8Dc=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b46ed75d-7fbc-4c6a-84c2-08dd8d2e1ac4
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 06:12:11.3038
 (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: +LDtfUirWbxNRMafFXOyehD1vR0zylTPfzbhbAef5yleROlz+jjYNfMpEhmFmE1ukGmBaiehlBDaRYhNzlzmYA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8066

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwg
MTcsIDIwMjUgMTE6MjMgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNv
bT4NCj4gQ2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0K
PiA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBh
dUBjaXRyaXguY29tPjsgeGVuLQ0KPiBkZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJq
ZWN0OiBSZTogW1BBVENIIHY0IDA3LzE1XSB4ZW4vY3B1ZnJlcTogZml4IGNvcmUgZnJlcXVlbmN5
IGNhbGN1bGF0aW9uIGZvciBBTUQNCj4gRmFtaWx5IDFBaCBDUFVzDQo+DQo+IE9uIDE0LjA0LjIw
MjUgMDk6NDAsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiA+IEFNRCBGYW1pbHkgMUFoIENQVSBuZWVk
cyBhIGRpZmZlcmVudCBDT0YoQ29yZSBPcGVyYXRpbmcgRnJlcXVlbmN5KQ0KPiA+IGZvcm11bGEs
IGR1ZSB0byBhIGNoYW5nZSBpbiB0aGUgUFN0YXRlRGVmIE1TUiBsYXlvdXQgaW4gQU1EIEZhbWls
eSAxQWguDQo+ID4gSW4gQU1EIEZhbWlseSAxQWgsIENvcmUgY3VycmVudCBvcGVyYXRpbmcgZnJl
cXVlbmN5IGluIE1IeiBpcw0KPiA+IGNhbGN1bGF0ZWQgYXMNCj4gPiBmb2xsb3dzOg0KPiA+ICAg
ICBDb3JlQ09GID0gQ29yZTo6WDg2OjpNc3I6OlBTdGF0ZURlZltDcHVGaWRbMTE6MF1dICogNU1I
eg0KPiA+DQo+ID4gV2UgaW50cm9kdWNlIGEgaGVscGVyIGFtZF9wYXJzZV9mcmVxKCkgdG8gcGFy
c2UgY3B1IG1pbi9ub21pbmFsL21heA0KPiA+IGNvcmUgZnJlcXVlbmN5IGZyb20gUHN0YXRlRGVm
IHJlZ2lzdGVyLCB0byByZXBsYWNlIHRoZSBvcmlnaW5hbCBtYWNybyBGUkVRKHYpLg0KPiA+IGFt
ZF9wYXJzZV9mcmVxKCkgaXMgZGVjbGFyZWQgYXMgY29uc3QsIGFzIGl0IG1haW5seSBjb25zaXN0
cyBvZg0KPiA+IG1hdGhlbWF0aWNhbCBjb25wdXRhdGlvbi4NCj4gPg0KPiA+IFNpZ25lZC1vZmYt
Ynk6IFBlbm55IFpoZW5nIDxQZW5ueS5aaGVuZ0BhbWQuY29tPg0KPg0KPiBBcyB0byB0aGUgdGl0
bGU6IEkgZG9uJ3QgdGhpbmsgImZpeCIgaXMgYXBwcm9wcmlhdGUgaGVyZS4gT3IgZWxzZSBJJ2Qg
ZXhwZWN0IGEgRml4ZXM6IHRhZw0KPiB0byBiZSB0aGVyZSwgd2hpY2ggSSB0aGluayB3b3VsZCBi
ZSBoYXJkIGZvciB5b3UgdG8gZmlzaCBvdXQgKGFzIHRoZSBlYXJsaWVyIGNoYW5nZXMNCj4gaGVy
ZSB3ZXJlbid0IGJyb2tlbjsgaW5mb3JtYXRpb24gb24gRmFtMUEgc2ltcGx5IHdhc24ndCBhdmFp
bGFibGUgYXQgdGhlIHRpbWUpLg0KPg0KDQpJIHdpbGwgY2hhbmdlIGl0IHRvICJFeHBhbmQgY29y
ZSBmcmVxdWVuY3kgY2FsY3VsYXRpb24gZm9yIEFNRCBGYW1pbHkgMUFoIENQVXMiLCBvciBhbnkg
YmV0dGVyIHN1Z2dlc3Rpb24/DQoNCj4gPiAtLS0gYS94ZW4vYXJjaC94ODYvY3B1L2FtZC5jDQo+
ID4gKysrIGIveGVuL2FyY2gveDg2L2NwdS9hbWQuYw0KPiA+IEBAIC01NzAsMTIgKzU3MywzNSBA
QCBzdGF0aWMgdm9pZCBhbWRfZ2V0X3RvcG9sb2d5KHN0cnVjdCBjcHVpbmZvX3g4NiAqYykNCj4g
PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDoNCj4gPiBjLT5jcHVfY29yZV9pZCk7ICB9DQo+ID4NCj4gPiArc3RhdGljIHVpbnQ2NF90
IGFtZF9wYXJzZV9mcmVxKHVuc2lnbmVkIGNoYXIgYywgdWludDY0X3QgdmFsdWUpDQo+DQo+IENv
bnNpZGVyaW5nIGhvdyBpdCdzIHVzZWQsIGRvZXMgInZhbHVlIiBuZWVkIHRvIGJlIGFueSB3aWRl
ciB0aGFuIHVuc2lnbmVkIGludD8NCj4gV2hhdCBhYm91dCB0aGUgcmV0dXJuIHR5cGU/DQo+DQoN
ClZhbHVlIGlzIHRoZSB2YWx1ZSBvZiA2NGJpdCBQc3RhdGVEZWYgTVNSLCBhbHRob3VnaCB3ZSBh
cmUgb25seSB1c2luZyB0aGUgbG93ZXIgMzJiaXQgdG8gY2FsY3VsYXRlIGZyZXF1ZW5jeQ0KTWF5
YmUgaXRzIGJldHRlciB0byBsZWF2ZSBpdCBhcyB1aW50NjRfdCA/DQpJJ2xsIGNoYW5nZSB0aGUg
cmV0dXJuIHR5cGUgdG8gdW5zaWduZWQgaW50LCBhbmQgZG8gdGhlIGZvbGxvd2luZyBjaGVjayBh
bnlob3cNCiAgICAgICAgI2RlZmluZSBJTlZBTF9GUkVRX01IWiAgKH4odW5zaWduZWQgaW50KTAp
DQogICAgICAgIGlmICggZnJlcSA+PSBVSU5UX01BWCApDQogICAgICAgICAgICAgICAgcmV0dXJu
IElOVkFMX0ZSRVFfTUhaOw0KICAgICAgICBlbHNlDQogICAgICAgICAgICAgICAgcmV0dXJuICh1
bnNpZ25lZCBpbnQpIGZyZXE7DQoNCj4gSSBhbHNvIHRoaW5rIHRoZSBmaXJzdCBhcmd1bWVudCB3
b3VsZCBiZXR0ZXIgYmUgdW5zaWduZWQgaW50LCBhbmQgd291bGQgYmV0dGVyIGJlDQo+IG5hbWVk
IGUuZy4gImZhbWlseSIuDQo+DQoNClVuZGVyc3Rvb2QNCg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Wed May 07 06:17:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 06:17:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978220.1365051 (Exim 4.92)
	(envelope-from )
	id 1uCY6C-0002yJ-HC; Wed, 07 May 2025 06:17:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978220.1365051; Wed, 07 May 2025 06: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 1uCY6C-0002yC-EE; Wed, 07 May 2025 06:17:44 +0000
Received: by outflank-mailman (input) for mailman id 978220;
 Wed, 07 May 2025 06:17:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCY6C-0002y6-3D
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 06:17:44 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f49268ac-2b0a-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 08:17:30 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43cfa7e7f54so3655045e9.1
 for ; Tue, 06 May 2025 23:17:30 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-441d433e9efsm19444165e9.3.2025.05.06.23.17.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 May 2025 23:17: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" 
X-Inumbo-ID: f49268ac-2b0a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746598650; x=1747203450; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=crHLmg0f4Do3RZv1tlldQ+CfN4wWtZcY35dbZBHB6vI=;
        b=q8nlNhZStKFdx5HetXhukUGfFLdpqiqbiCRYHlz2ErFgNRgxJc53x4vTsHYzpMWN0m
         l6ohxRHcCY4+hBxZFAYNIdgiaV/aiF+ufNJWOCkiR8i84UcnTZ+x7lWQbwSJovV3GzIY
         1evGhy+fHy+o6zCfI3Pci7hsJJwscP10z9shg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746598650; x=1747203450;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=crHLmg0f4Do3RZv1tlldQ+CfN4wWtZcY35dbZBHB6vI=;
        b=NG6nAyPeb10JKbrWZ4VcFNFGEAgm8ZcXkutWiyhk2DSpc7viqxX0macnnaJJr0Nlf1
         W0RrwkKZ5m1130LgDtWNfD67NlCxuZ1Uih314sXP3ekruEqHqCjTxjqCqYU0hKmQ8XWi
         HAe7E7lBjtpmRugWc325m/IN0nfCgH0T6zirqiWd0AqzuEOGPKpucY0jqHTan57Q9a4D
         /+Pcgyn+9SAAd+TRBakxixM4ce/fkCl6WnfChDN076VM1h0y1qq6p+TeA+nWnElm+BbR
         9hu0T1Z7CCCi23Ys7uSWA5UleAroAuQNEiGQF6Z9TFEBQINhjt7GeavgsUU773XO4qlt
         eIsA==
X-Gm-Message-State: AOJu0Yx0cn6PcC5rd8x2xgD2E9NFEeLNW5iJDfW2VN+SUaOohpNHiLHM
	N+lrDdDoxqpmmiNKWsqKd3pS9MIK7yHcP40MZxrAaCwRSHngmPou/3aiXoKYGFs=
X-Gm-Gg: ASbGncsZ23nX1A0o+yYNoK8LPG6nc2k/8FRh8tMJd/pCFaweuKUtcBTpIvz8tswOhvE
	F7+2ER5AaryGE7nKC+XkMquSespDc+qrFZpkSITzPE0D49LeCBCDK87a7hTxe7GuFu8OKuJ6ymn
	HLXKHXUlZZl/cBg+9PUI6oSC+X9Hx0z5pAdEomf+hR4xLEpxcwVZTUsRAVDCymXybrlIvq34yJC
	Yk2fV3QwUw0oNbzccqOT8uq2grKJkHpPPsoXyQt0Wip5Qrw959rn4vc6GOZ5h020glCC+AEiSYx
	0SxlcSyCPCYY8riFdVNcvb7/l5HDL6zqvSeVJf83tA51n748L6AMG+Tsvwc4Fj2LWvRKfkE++G6
	IdqoUQw==
X-Google-Smtp-Source: AGHT+IE9IUeR+OpKATphKydlRFzUsl5DDDRs6tAcjySNjXAr77Fa6H1Qd83FcPAiRWT0iWlSxDrejg==
X-Received: by 2002:a05:600c:46c6:b0:43b:c6a7:ac60 with SMTP id 5b1f17b1804b1-441d44a3706mr11497375e9.10.1746598649537;
        Tue, 06 May 2025 23:17:29 -0700 (PDT)
Message-ID: 
Date: Wed, 7 May 2025 07:17:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] xen/lib: Export additional sha256 functions
To: Frediano Ziglio 
Cc: xen-devel@lists.xenproject.org, Ross Lagerwall
 , Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: <20250506135655.187014-1-frediano.ziglio@cloud.com>
 <20250506135655.187014-2-frediano.ziglio@cloud.com>
 
 <5698b996-e23d-49f7-af37-645d4784dc67@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

On 07/05/2025 6:26 am, Frediano Ziglio wrote:
> On Tue, May 6, 2025 at 11:17 PM Andrew Cooper  wrote:
>> On 06/05/2025 3:05 pm, Andrew Cooper wrote:
>>> On 06/05/2025 2:56 pm, Frediano Ziglio wrote:
>>>> diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
>>>> index 47d97fbf01..ea8bad67e4 100644
>>>> --- a/xen/include/xen/sha2.h
>>>> +++ b/xen/include/xen/sha2.h
>>>> @@ -9,6 +9,16 @@
>>>>
>>>>  #define SHA2_256_DIGEST_SIZE 32
>>>>
>>>> +struct sha2_256_state {
>>>> +    uint32_t state[SHA2_256_DIGEST_SIZE / sizeof(uint32_t)];
>>>> +    uint8_t buf[64];
>>>> +    size_t count; /* Byte count. */
>>>> +};
>>>> +
>>>> +void sha2_256_init(struct sha2_256_state *s);
>>>> +void sha2_256_update(struct sha2_256_state *s, const void *msg,
>>>> +                     size_t len);
>>>> +void sha2_256_final(struct sha2_256_state *s, void *_dst);
>>>>  void sha2_256_digest(uint8_t digest[SHA2_256_DIGEST_SIZE],
>>>>                       const void *msg, size_t len);
>>> sha2_256_digest() is unlike the others as it holds sha2_256_state
>>> internally.  I'd suggest having all of the additions below this point,
>>> which group them more nicely.
>>>
>>> Can fix on commit.  Otherwise LGTM.
>> Not quite.  Now that sha2_256_final() is exported, it should have a
>> proper type for  _dst.  I've folded:
>>
>> diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
>> index 0d55fe640431..cb30e8f8d77c 100644
>> --- a/xen/include/xen/sha2.h
>> +++ b/xen/include/xen/sha2.h
>> @@ -21,6 +21,7 @@ struct sha2_256_state {
>>  void sha2_256_init(struct sha2_256_state *s);
>>  void sha2_256_update(struct sha2_256_state *s, const void *msg,
>>                       size_t len);
>> -void sha2_256_final(struct sha2_256_state *s, void *_dst);
>> +void sha2_256_final(struct sha2_256_state *s,
>> +                    uint8_t digest[SHA2_256_DIGEST_SIZE]);
>>
>>  #endif /* XEN_SHA2_H */
>> diff --git a/xen/lib/sha2-256.c b/xen/lib/sha2-256.c
>> index 896a257ed9b7..08ef7011a1c3 100644
>> --- a/xen/lib/sha2-256.c
>> +++ b/xen/lib/sha2-256.c
>> @@ -171,9 +171,9 @@ void sha2_256_update(struct sha2_256_state *s, const
>> void *msg,
>>      memcpy(s->buf + partial, msg, len);
>>  }
>>
>> -void sha2_256_final(struct sha2_256_state *s, void *_dst)
>> +void sha2_256_final(struct sha2_256_state *s, uint8_t
>> digest[SHA2_256_DIGEST_SIZE])
>>  {
>> -    uint32_t *dst = _dst;
>> +    uint32_t *dst = (uint32_t *)digest;
> That is we are never going to support architectures with unaligned
> memory access.

Note how it's written to.

    /* Store state in digest */
    for ( i = 0; i < 8; i++ )
        put_unaligned_be32(s->state[i], &dst[i]);

It works just fine on misaligned buffers.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 07 06:39:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 06:39:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978231.1365061 (Exim 4.92)
	(envelope-from )
	id 1uCYQj-0006Cf-5d; Wed, 07 May 2025 06:38:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978231.1365061; Wed, 07 May 2025 06:38: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 1uCYQj-0006CY-1l; Wed, 07 May 2025 06:38:57 +0000
Received: by outflank-mailman (input) for mailman id 978231;
 Wed, 07 May 2025 06:38:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCYQh-0006CS-GC
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 06:38:55 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20616.outbound.protection.outlook.com
 [2a01:111:f403:2408::616])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f0ea0ae3-2b0d-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 08:38:53 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by CH2PR12MB4150.namprd12.prod.outlook.com (2603:10b6:610:a6::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Wed, 7 May
 2025 06:38:45 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8699.012; Wed, 7 May 2025
 06:38:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f0ea0ae3-2b0d-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uVWruMlseEladLSKTHa8h4OrXyuGXZw/T3o/WVaixBSZyu3Kox4ZgymjWw7x5fIZ1/WK7oL2cOiB6SEhsNFIuhLvHcR1IROWXRYZpaxFkgx9GKP5X09dkANgc8xPHVEdFicNjUUlnJ9POotZYFfadj1yiFaWLnEwEljXAvnkGNzv9TR6ICySdtFOUi81gB1DQAzMvs4guOCtQI9e1e5WVBvQI1RWiwMFkOsm2SJM5Oqd978TvRkldBEQuf+YxbLA2E3gfdtKf2/Tm5qyIAUYSBoWE9tGclmSPuYEsv1AQqjmdpPoFMOW/xdHY3WtR54m9fNa4LDd2GlOsTov62kh2Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lwkAs43S/m1z911xvuJVlLqjpdYUmRzz39cFacztYhc=;
 b=AAg0osqCtvBTXv6h5rz/x1oJACqZyVbM6TUjo+ASbIoFuvkKDWTsAv1QbpOGr4DXg3T19WL6zCOZsHemA6TzXW/Iu/ugzQw4eUyOagpfOMjxTnOS2He2P69/BmN+2VDB9fxG+dJAmoWXmJWco0kkeNRpRgcVmO4Ifw7R7pZFiLRC2U6Jf40Bbo2Yah1rbNrPXbp2iMWgNbjwYOHJdHzil9Kt3VchuEtRELwenO6u3/6qYo6ZCeQy/ra/mio+WQBOARC7nHIpialcjGr1TCX+XRqbsO7nEcmQARv80bJ5ZKs8Hhys8oIdTkszff5lUmYarfond8FfnEgLou+BGesdng==
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=lwkAs43S/m1z911xvuJVlLqjpdYUmRzz39cFacztYhc=;
 b=Rf3dAVV55gwwRfFfoAHNv1vgtw/11d5Z7Lj6a9XEKBIX2E1X2yf9j+XRCbFbZIkayqyDGz78j1HzzDh/yyWPxqjZBIfr0ATBZ/C72F4rCY7v/5j+gPxZLCsQjgR3vamZp2RX1Bvzysx+T68zX9MWKuXJzeL4rhr+nfdJUvyJi0Q=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v3 06/11] vpci: Hide legacy capability when it fails to
 initialize
Thread-Topic: [PATCH v3 06/11] vpci: Hide legacy capability when it fails to
 initialize
Thread-Index: AQHbsoVckJ4au36tTkiHt4pmnYtEWrPF2tMAgAF6HgA=
Date: Wed, 7 May 2025 06:38:45 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-7-Jiqian.Chen@amd.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8699.005)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|CH2PR12MB4150:EE_
x-ms-office365-filtering-correlation-id: 6909f7ac-91df-43dc-aad5-08dd8d31d0f6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?ajlRVUh0dEtoenJOajZKY0lDN0ZLdFduU0F3S2kxRWVhbnVMUXNmSkpJdFln?=
 =?utf-8?B?Mk1mTU4vVXNHUVR1TW0zenlQN0tidE8vVEY4d3kvNWNUTjBOSjVnV1pIczdZ?=
 =?utf-8?B?Z1BTRkxPSS9ENkhwY0UxTEZ1MmdvNTNSc3lEekI3b1UvZ3hzY3VsbW8rSEpn?=
 =?utf-8?B?WHBQYWYyWjVLWmNRY25sVS9MVmNqTmFpZmJDa3FWSXVpVXpUK085UXlFb1lw?=
 =?utf-8?B?b0hNK0lCUU1TYzFlMDl3MGpXTzR0eDFNQUt2SHdzc3NQTTl1L1NwbUZYL25q?=
 =?utf-8?B?YVZoTTBWTURSSUNpbGJRZDdEVUJqMGlBalp6MGpjMmpIMU9OZ2I4TzE5L3Vq?=
 =?utf-8?B?Z0E2VzJ0VGpvVGpMd0tDQ0NNdXFhVWJDUFBpbWVsQzZGbFZ2elRSa2FBWmZR?=
 =?utf-8?B?VzQyZUZ3L1RaR2NiQWh1ZUhuOURhbERPczdlZERrdDF5cEtndzZxU0tGSDV3?=
 =?utf-8?B?OFd1VGZxWUhkWTVITEZvemt5Y084ZWNZS1E0ODQ2WlpIY29rbzhjK3kxVkp6?=
 =?utf-8?B?YnMvQ0IvSWRVOUhoWnNvVGkrUUFHNFpCQnB3RzR5aXA5Y3NpckVlZlk0VEtH?=
 =?utf-8?B?R0grNDlYZkJZeFZQMkFLN0o3dE80aW9jZ2hFZG5oNTZadlo1UDNHL2hzcHFG?=
 =?utf-8?B?Rld1S2MrbDlSQVJ6OFJoV1g3aTdNY2g3QTl6ZFpYTC9VLzFZNzlFUDlWWXU0?=
 =?utf-8?B?UHNWOFIvbmErYVkwREdBLzZCb0RvUXhqbS8wYnZWSGF5enp3dGxpSVNBYVJZ?=
 =?utf-8?B?Vko2aDJpSFhZWkpxUjBUWitnWmRnQmpnS3RXaitVS0lIYXV2Und0QU15dzk3?=
 =?utf-8?B?bklBd2pmcTQxaCtjakNIMnRpNGR4MU1PUnNaOU04NlpuYzk4TGZrZHV1WHph?=
 =?utf-8?B?ZG5hMHRxaHc2Mm9rdGxPWTNhT0FaLzlOd3Vpb2laTU9LU1pTUWg2aGNadTla?=
 =?utf-8?B?SW1zSEFxMThWcEdDUW84cEd4cjByNE9odHNCT0ZMb1c1QzJsUm9HSDFQdWsr?=
 =?utf-8?B?ektFSzRTdGVrRzdiKzk0RWZlalpKSHJhRmphb3QrcGZnbFAxZTF3M0RlUlAw?=
 =?utf-8?B?Q1h6aUR1ZkRMbWpIUnF6Yk9ienVWbi9OaEprTXh5S1ZiV3A4TURnNDB4UTJF?=
 =?utf-8?B?MGpEeE8wbnN5T1VGNUtpNmR0ZlJLMG9ncVdnYW93aWVYM0E1VXZZZ08wOWts?=
 =?utf-8?B?aHZTNElheUQ1aUZhRDlDWGhzZy8yeFd6TEV4QjhpQTJiMkFTeTgrWjBCOCtm?=
 =?utf-8?B?UTM5cTlxOFBNWFhUUEpxcW1GMHUydXVZbmphSFRRRXFUMFlXcmQ1aG9Jd3Q3?=
 =?utf-8?B?ZGw3TmxWZHdyM3B5dTE2WXhOdDgvSWhYSjFDcVRHWDdTYzRqL0dvQm5qQUhQ?=
 =?utf-8?B?MEpybTNWMC91UGZWeWlnRUhSQk5FdWZ6TldFbS9aOVBwbWl6TkRQR3pNeU9u?=
 =?utf-8?B?L3FDTDlkR2treDFFQjJkL0VuWXk1ejFHZWZTU1VqSWpWWnN1Y3BNT1B1aTJT?=
 =?utf-8?B?R0JDQStwUFZWbkZTTXpGa2lSM1pibmFyMjFZa3VqUEZSTWhkRzBGaGJLWkds?=
 =?utf-8?B?dVkvWHNVVHpvNkJ5dnhvd0hMK1huS0hDVWE0SnVJRm1OWEpPdVU3eVlIRERU?=
 =?utf-8?B?aEMwUVc5RW1FVEpOQWttMll0ZzZmZlR5ZElDVllEQXcxd1A0djd3NHJOcVBs?=
 =?utf-8?B?KzZNUWtrUnFoWGk0YlZ3SW5iMi9KbXVvcVQxUW8yeEtzTU82OW02dkwxRnNW?=
 =?utf-8?B?KzYyWGFqTGh2UzdZMGl0NE1kUzVzTGlDY3lWQnQ0QTR4WVpLRjNMSXJveDNZ?=
 =?utf-8?B?Sy9CRGNQODM0YUV4cExobmZUR2xFaVIyM0VIaFBkRFcwdU8yWFNaRThETVJv?=
 =?utf-8?B?THhYVlBrd0psNjdod2x6OW8veGd3WTh4OERIQnVESC9NVkZsOWcrTG1PSFlz?=
 =?utf-8?B?MDE3RFE0Q3BBSG9xSjJDTmYwdk5uWW1pUEQ1bUV1czg2MG94U2tGbDFHWGZY?=
 =?utf-8?Q?2GhzrZlpDwXEqg9rMn08tBoa1WtuJA=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?RnVjQ2NYNjdGYThqV0hvaU9OdlAyMW9wUGZMR0NtcWdBbzhLTzNzeEJEbUJH?=
 =?utf-8?B?Z3MzMEVMUnp2WVhqT0tUKzl1WXN3UW4wbUNKVUYrV2tIdm9HRUo5SGNnSkJt?=
 =?utf-8?B?MHRsVDRuRFdFV0lFaTlsS2EwbWs2Vk5YTGQxNDl0cy81VHBZaTJ3RzJKMmpZ?=
 =?utf-8?B?eHNNTlhKVzlBMHI0clg4Z2V2aTkwRmNrRjlSYzlwektaWEdrcUhFTXQ2VXV5?=
 =?utf-8?B?eGhGRm9BcWhReGZtZFdsN1BtQ2Nmd2dBdHRjVjlGVzUvcEJXUEpaMWtTYWhG?=
 =?utf-8?B?Ykt1cUl4dlFHQzJqa3o3RDZUb0tIZ0R6NmgvdjBZVHVnVDBBOGpjZ1JQWlNY?=
 =?utf-8?B?SnhJMWxaeGg1ZTBiRXgvTFZHS2JjZithdzNwSFFQRmVsTkRjV1ppUjB2T3JX?=
 =?utf-8?B?SWV4RDlsRDV1ZTJHb0xhbXU2U3JLRS8zSlQySHlQU1FXaC82eHAxMWhtcEZy?=
 =?utf-8?B?MHBrZXcxZjJpaTM5eG1zOGJOUUx2TFd2VnMraTI3b2xLUGJsRENvc3U5N1FY?=
 =?utf-8?B?NDMrdWR5RUd5aFZiVDdtZGMySFppbklaOHpKbjE0MTJDK0p3VWY3UXZtYlRR?=
 =?utf-8?B?NWxvUmtvTEZsUlVENGhMZDJ1S0h4S1JUYWcrR0JJMGV6M1JINm1OQmpsNlB3?=
 =?utf-8?B?bFcwY0hLYXB0eWpJNlB6aHp4TDRFUXc2VmJHU2l2K0I4YjFMZ2t4cTJXVHJr?=
 =?utf-8?B?SEl3am9vVlBvUEZCNGNleWVCL1lzeDBOVG0rb0J0S0ExcFlXUW5hK3BFQTJn?=
 =?utf-8?B?Rng0OW15NnFjWU9uQnpmaWl4TE01eW5YbysxNzJockxkT2lkYkJ4TEVUdWx6?=
 =?utf-8?B?UmxNQ0pWc1E5b3FYUzVJMGZpcnBsUzV6MnZvOURsZWg1TVd4M0xHUHRzS0hM?=
 =?utf-8?B?VjM0dHZBbnZpNnpXNVVOSW1zMFJCcXRLdS93MHAveFh4NDdyMjlrMHp0VVBy?=
 =?utf-8?B?SFpWTzFRL0U4SzhWWHo0V1hYNUJhN0U0VEsxSGd1SFpDZjRkSGtWdDZpenh6?=
 =?utf-8?B?SEsxVWZZbjJDMlNralVyZG41SDFJYUZ2L2V5ekZtdWJ3QkM0NVM0M2l2UGxB?=
 =?utf-8?B?NEFPTDJPbTNRYWo0ZjhqcTBWY00zVDlnMlNjY1pna3gyTjMxclYvODRSbjFa?=
 =?utf-8?B?QzhpQXVTUDU5aHN6L1dkeGZ3VmJBd1pLMjh4MmJtRVlkazBpbXFiZkFTenAw?=
 =?utf-8?B?dkYzbmJnQ3M2dURHdUpreEl2aCt1YmtwUmNXdm9yd1c4TXVnRmYyUmdnL1Zs?=
 =?utf-8?B?QjlkZmp4eDlFMWRNVkZiNmY0MndVZjk1Um53YXRUTHJXcEUzSTc0dytFTjhQ?=
 =?utf-8?B?dWtUQk9rNUNFRTllRWVUbGlSRjR4YndVajFSbUtJV1J1MUkwVFlabldIbTV4?=
 =?utf-8?B?Vk03ZmZGOXZrOXVTOSt5ZHgydm4yT1FNKy9pVmRIMkQ2cGE5a3JmRk5GMFRp?=
 =?utf-8?B?SEVxZkkxbW9NbE83SURPWnVHbUdpenQ3aFVONjRqTC9zVWwwTkROb0FhVThQ?=
 =?utf-8?B?WTN2VWpMb2tPbEoyUzFZMjIvRzkwK2RYWUdjRGw3YU5PZ3hNQm1aWm42Nm16?=
 =?utf-8?B?UnRreEZKQ2lYd1FRblN0YU53dTFTUFk0V3lVTk1UcTBwOUtwZTlHbDZjZkxv?=
 =?utf-8?B?VXdycDRjeExaazRhTnNtQ0QyMFQ0cVNmcXhpalRDeUdlL3hOcTR5YVMxdDBz?=
 =?utf-8?B?SW5EblJ2ckpwV3FFRmdlTzE5YUYwSWk1QWN4ejUxTzlYZExEOEdGNktJcmhw?=
 =?utf-8?B?R21taTcrTFpZNlYweUlINW9DOGtLeHhKUnppSlJRSFFGQXJlUHNlYXVZLzJa?=
 =?utf-8?B?YXkxZVowNmRhRkROQlk3NlJob2dNSytFUDcrc2VidXVSbHQwQXVDVENYeWls?=
 =?utf-8?B?RUZFUTJGT3Z3bFI4OUFwbXpuYytaRUV5ZlN1bmw0TDJqVW8rU3dUdjlZNWxn?=
 =?utf-8?B?eFc2TlM0KzhTb00vUE5RV0o0S29pYTlwMFZTWGNVclVZRE4vVVFlVVY0bTE1?=
 =?utf-8?B?cFRzcFdXM0JlZjNRdE1nNWZDWGNucnlPbGw0azVMY0tKRUEzVXNvNkdqSXJH?=
 =?utf-8?B?WUFwdkVjUm5OSW96cFplYjdYQVNrZk5pK0c0V2VoaTV0SkZxN3k5NFNlRXNt?=
 =?utf-8?Q?TFf0=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <7F63FA3BB7AA1E429AB0DB669D86E361@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6909f7ac-91df-43dc-aad5-08dd8d31d0f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 06:38:45.4878
 (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: uLdqc5U9Ftr0UB0ld7dzY5qkt4zoI5BjwJZcSktAAGOpoPI2VJCHGkToah2+mqbOw/Ly9CZNrD1HZYBCfx9OPQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4150

T24gMjAyNS81LzcgMDA6MDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgQXBy
IDIxLCAyMDI1IGF0IDAyOjE4OjU4UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gV2hl
biB2cGNpIGZhaWxzIHRvIGluaXRpYWxpemUgYSBsZWdhY3kgY2FwYWJpbGl0eSBvZiBkZXZpY2Us
IGl0IGp1c3QNCj4+IHJldHVybiBlcnJvciBpbnN0ZWFkIG9mIGNhdGNoaW5nIGFuZCBwcm9jZXNz
aW5nIGV4Y2VwdGlvbi4gVGhhdCBtYWtlcw0KPj4gdGhlIGVudGlyZSBkZXZpY2UgdW51c2FibGUu
DQo+IA0KPiBJIHRoaW5rICJjYXRjaGluZyBhbmQgcHJvY2Vzc2luZyBleGNlcHRpb24iIGlzIGEg
d2VpcmQgdGVybWlub2xvZ3kgdG8NCj4gdXNlIHdoZW4gd3JpdGluZyBDLiAgSXQncyBJTW8gbW9y
ZSBhY2N1cmF0ZSB0byB1c2U6DQo+IA0KPiAiV2hlbiB2cGNpIGZhaWxzIHRvIGluaXRpYWxpemUg
YSBsZWdhY3kgY2FwYWJpbGl0eSBvZiBkZXZpY2UsIGl0IGp1c3QNCj4gcmV0dXJucyBhbiBlcnJv
ciBhbmQgdlBDSSBnZXRzIGRpc2FibGVkIGZvciB0aGUgd2hvbGUgZGV2aWNlLiAgVGhhdA0KPiBt
b3N0IGxpa2VseSByZW5kZXJzIHRoZSBkZXZpY2UgdW51c2FibGUsIHBsdXMgcG9zc2libHkgY2F1
c2luZyBpc3N1ZXMNCj4gdG8gWGVuIGl0c2VsZiBpZiBndWVzdCBhdHRlbXB0cyB0byBwcm9ncmFt
IHRoZSBuYXRpdmUgTVNJIG9yIE1TSS1YDQo+IGNhcGFiaWxpdGllcyBpZiBwcmVzZW50LiINClRo
YW5rcywgd2lsbCBjaGFuZ2UuDQoNCj4gDQo+PiBTbywgYWRkIG5ldyBhIGZ1bmN0aW9uIHRvIGhp
ZGUgbGVnYWN5IGNhcGFiaWxpdHkgd2hlbiBpbml0aWFsaXphdGlvbg0KPj4gZmFpbHMuIEFuZCBy
ZW1vdmUgdGhlIGZhaWxlZCBsZWdhY3kgY2FwYWJpbGl0eSBmcm9tIHRoZSB2cGNpIGVtdWxhdGVk
DQo+PiBsZWdhY3kgY2FwYWJpbGl0eSBsaXN0Lg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEppcWlh
biBDaGVuIDxKaXFpYW4uQ2hlbkBhbWQuY29tPg0KPj4gLS0tDQo+PiBjYzogIlJvZ2VyIFBhdSBN
b25uw6kiIDxyb2dlci5wYXVAY2l0cml4LmNvbT4NCj4+IC0tLQ0KPj4gdjItPnYzIGNoYW5nZXM6
DQo+PiAqIFNlcGFyYXRlZCBmcm9tIHRoZSBsYXN0IHZlcnNpb24gcGF0Y2ggInZwY2k6IEhpZGUg
Y2FwYWJpbGl0eSB3aGVuIGl0IGZhaWxzIHRvIGluaXRpYWxpemUiDQo+PiAqIFdob2xlIGltcGxl
bWVudGF0aW9uIGNoYW5nZWQgYmVjYXVzZSBsYXN0IHZlcnNpb24gaXMgd3JvbmcuDQo+PiAgIFRo
aXMgdmVyc2lvbiBhZGRzIGEgbmV3IGhlbHBlciBmdW5jdGlvbiB2cGNpX2dldF9yZWdpc3Rlcigp
IGFuZCB1c2VzIGl0IHRvIGdldA0KPj4gICB0YXJnZXQgaGFuZGxlciBhbmQgcHJldmlvdXMgaGFu
ZGxlciBmcm9tIHZwY2ktPmhhbmRsZXJzLCB0aGVuIHJlbW92ZSB0aGUgdGFyZ2V0Lg0KPj4NCj4+
IHYxLT52MiBjaGFuZ2VzOg0KPj4gKiBSZW1vdmVkIHRoZSAicHJpb3JpdGllcyIgb2YgaW5pdGlh
bGl6aW5nIGNhcGFiaWxpdGllcyBzaW5jZSBpdCBpc24ndCB1c2VkIGFueW1vcmUuDQo+PiAqIEFk
ZGVkIG5ldyBmdW5jdGlvbiB2cGNpX2NhcGFiaWxpdHlfbWFzaygpIGFuZCB2cGNpX2V4dF9jYXBh
YmlsaXR5X21hc2soKSB0bw0KPj4gICByZW1vdmUgZmFpbGVkIGNhcGFiaWxpdHkgZnJvbSBsaXN0
Lg0KPj4gKiBDYWxsZWQgdnBjaV9tYWtlX21zaXhfaG9sZSgpIGluIHRoZSBlbmQgb2YgaW5pdF9t
c2l4KCkuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4gSmlxaWFuIENoZW4uDQo+PiAtLS0NCj4+
ICB4ZW4vZHJpdmVycy92cGNpL3ZwY2kuYyB8IDEzMyArKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKystLS0tLS0tDQo+PiAgMSBmaWxlIGNoYW5nZWQsIDExMiBpbnNlcnRpb25zKCspLCAy
MSBkZWxldGlvbnMoLSkNCj4+DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvdnBjaS92cGNp
LmMgYi94ZW4vZHJpdmVycy92cGNpL3ZwY2kuYw0KPj4gaW5kZXggNTQ3NGI2NjY2OGMxLi5mOTdj
N2NjNDYwYTAgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL3ZwY2kuYw0KPj4gKysr
IGIveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMNCj4+IEBAIC0zNSw2ICszNSwyMiBAQCBzdHJ1Y3Qg
dnBjaV9yZWdpc3RlciB7DQo+PiAgICAgIHVpbnQzMl90IHJzdmR6X21hc2s7DQo+PiAgfTsNCj4+
ICANCj4+ICtzdGF0aWMgaW50IHZwY2lfcmVnaXN0ZXJfY21wKGNvbnN0IHN0cnVjdCB2cGNpX3Jl
Z2lzdGVyICpyMSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0cnVj
dCB2cGNpX3JlZ2lzdGVyICpyMikNCj4+ICt7DQo+PiArICAgIC8qIFJldHVybiAwIGlmIHJlZ2lz
dGVycyBvdmVybGFwLiAqLw0KPj4gKyAgICBpZiAoIHIxLT5vZmZzZXQgPCByMi0+b2Zmc2V0ICsg
cjItPnNpemUgJiYNCj4+ICsgICAgICAgICByMi0+b2Zmc2V0IDwgcjEtPm9mZnNldCArIHIxLT5z
aXplICkNCj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4gKyAgICBpZiAoIHIxLT5vZmZzZXQgPCBy
Mi0+b2Zmc2V0ICkNCj4+ICsgICAgICAgIHJldHVybiAtMTsNCj4+ICsgICAgaWYgKCByMS0+b2Zm
c2V0ID4gcjItPm9mZnNldCApDQo+PiArICAgICAgICByZXR1cm4gMTsNCj4+ICsNCj4+ICsgICAg
QVNTRVJUX1VOUkVBQ0hBQkxFKCk7DQo+PiArICAgIHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+
ICAjaWZkZWYgX19YRU5fXw0KPj4gIGV4dGVybiB2cGNpX2NhcGFiaWxpdHlfdCAqY29uc3QgX19z
dGFydF92cGNpX2FycmF5W107DQo+PiAgZXh0ZXJuIHZwY2lfY2FwYWJpbGl0eV90ICpjb25zdCBf
X2VuZF92cGNpX2FycmF5W107DQo+PiBAQCAtODMsNyArOTksOTEgQEAgc3RhdGljIGludCBhc3Np
Z25fdmlydHVhbF9zYmRmKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4gIA0KPj4gICNlbmRpZiAv
KiBDT05GSUdfSEFTX1ZQQ0lfR1VFU1RfU1VQUE9SVCAqLw0KPj4gIA0KPj4gLXN0YXRpYyBpbnQg
dnBjaV9pbml0X2NhcGFiaWxpdGllcyhzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+ICtzdGF0aWMg
c3RydWN0IHZwY2lfcmVnaXN0ZXIgKnZwY2lfZ2V0X3JlZ2lzdGVyKHN0cnVjdCB2cGNpICp2cGNp
LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29u
c3QgdW5zaWduZWQgaW50IG9mZnNldCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGNvbnN0IHVuc2lnbmVkIGludCBzaXplKQ0KPiANCj4gV2UgZG9u
J3QgdXN1YWxseSB1c2UgY29uc3QgYXR0cmlidXRlcyBmb3Igc2NhbGFyIGZ1bmN0aW9uIHBhcmFt
ZXRlcnMuDQo+IA0KPj4gK3sNCj4+ICsgICAgY29uc3Qgc3RydWN0IHZwY2lfcmVnaXN0ZXIgciA9
IHsgLm9mZnNldCA9IG9mZnNldCwgLnNpemUgPSBzaXplIH07DQo+PiArICAgIHN0cnVjdCB2cGNp
X3JlZ2lzdGVyICpybTsNCj4+ICsNCj4+ICsgICAgQVNTRVJUKHNwaW5faXNfbG9ja2VkKCZ2cGNp
LT5sb2NrKSk7DQo+PiArICAgIGxpc3RfZm9yX2VhY2hfZW50cnkgKCBybSwgJnZwY2ktPmhhbmRs
ZXJzLCBub2RlICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgaW50IGNtcCA9IHZwY2lfcmVnaXN0
ZXJfY21wKCZyLCBybSk7DQo+PiArDQo+PiArICAgICAgICBpZiAoICFjbXAgJiYgcm0tPm9mZnNl
dCA9PSBvZmZzZXQgJiYgcm0tPnNpemUgPT0gc2l6ZSApDQo+PiArICAgICAgICAgICAgcmV0dXJu
IHJtOw0KPj4gKyAgICAgICAgaWYgKCBjbXAgPD0gMCApDQo+PiArICAgICAgICAgICAgYnJlYWs7
DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIE5VTEw7DQo+PiArfQ0KPj4gKw0KPj4g
K3N0YXRpYyBzdHJ1Y3QgdnBjaV9yZWdpc3RlciAqdnBjaV9nZXRfcHJldmlvdXNfY2FwX3JlZ2lz
dGVyDQo+PiArICAgICAgICAgICAgICAgIChzdHJ1Y3QgdnBjaSAqdnBjaSwgY29uc3QgdW5zaWdu
ZWQgaW50IG9mZnNldCkNCj4gDQo+IFRoZSBzdHlsZSBwcmVmZXJlbmNlIGhlcmUgd291bGQgYmU6
DQo+IA0KPiBzdGF0aWMgc3RydWN0IHZwY2lfcmVnaXN0ZXIgKnZwY2lfZ2V0X3ByZXZpb3VzX2Nh
cF9yZWdpc3RlcigNCj4gICAgIHN0cnVjdCB2cGNpICp2cGNpLCB1bnNpZ25lZCBpbnQgb2Zmc2V0
KQ0KPiB7DQo+IC4uLg0KPiANCj4+ICt7DQo+PiArICAgIHVpbnQzMl90IG5leHQ7DQo+PiArICAg
IHN0cnVjdCB2cGNpX3JlZ2lzdGVyICpyOw0KPj4gKw0KPj4gKyAgICBpZiAoIG9mZnNldCA8IDB4
NDAgKQ0KPiANCj4gSSB3b3VsZCBwb3NzaWJseSBhZGQgYW4gQVNTRVJUX1VOUkVBQ0hBQkxFKCkg
aGVyZSwgYXMgYXR0ZW1wdGluZyB0bw0KPiBwYXNzIGFuIG9mZnNldCBiZWxvdyAweDQwIGlzIGEg
c2lnbiBvZiBhIGJ1ZyBlbHNld2hlcmU/DQpQcm9iYWJseSB5ZXMsIEkgd2lsbCBhZGQgYW4gQVNT
RVJUX1VOUkVBQ0hBQkxFKCkgaGVyZS4NCg0KPiANCj4+ICsgICAgICAgIHJldHVybiBOVUxMOw0K
Pj4gKw0KPj4gKyAgICByID0gdnBjaV9nZXRfcmVnaXN0ZXIodnBjaSwgUENJX0NBUEFCSUxJVFlf
TElTVCwgMSk7DQo+PiArICAgIEFTU0VSVChyKTsNCj4+ICsNCj4+ICsgICAgbmV4dCA9ICh1aW50
MzJfdCkodWludHB0cl90KXItPnByaXZhdGU7DQo+PiArICAgIHdoaWxlICggbmV4dCA+PSAweDQw
ICYmIG5leHQgIT0gb2Zmc2V0ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgciA9IHZwY2lfZ2V0
X3JlZ2lzdGVyKHZwY2ksIG5leHQgKyBQQ0lfQ0FQX0xJU1RfTkVYVCwgMSk7DQo+PiArICAgICAg
ICBBU1NFUlQocik7DQo+PiArICAgICAgICBuZXh0ID0gKHVpbnQzMl90KSh1aW50cHRyX3Qpci0+
cHJpdmF0ZTsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBpZiAoIG5leHQgPCAweDQwICkNCj4+
ICsgICAgICAgIHJldHVybiBOVUxMOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gcjsNCj4+ICt9DQo+
PiArDQo+PiArc3RhdGljIHZvaWQgdnBjaV9jYXBhYmlsaXR5X21hc2soc3RydWN0IHBjaV9kZXYg
KnBkZXYsDQo+IA0KPiBUaGlzIHBvc3NpYmx5IG5lZWRzIHRvIHJldHVybiBhbiBlcnJvciBjb2Rl
LCBhcyBpdCBjYW4gZmFpbCwgYW5kIGp1c3QNCj4gYWRkaW5nIEFTU0VSVHMgYWxsIGFyb3VuZCBz
ZWVtcyBhIGJpdCBjbHVtc3ksIHBsdXMgd2UgbWlnaHQgcmVhbGx5DQo+IHdhbnQgdG8gcHJldmVu
dCBhc3NpZ25pbmcgdGhlIGRldmljZSB0byB0aGUgZG9tYWluIGlmDQo+IHZwY2lfY2FwYWJpbGl0
eV9tYXNrKCkgZmFpbHMgZm9yIHdoYXRldmVyIHJlYXNvbi4NCk1ha2Ugc2Vuc2UuIFdpbGwgY2hh
bmdlIHRvIHJldHVybiBlcnJvciBpbnN0ZWFkIG9mIEFTU0VSVC4NCg0KPiANCj4+ICsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB1bnNpZ25lZCBpbnQgY2FwKQ0KPj4gK3sN
Cj4+ICsgICAgY29uc3QgdW5zaWduZWQgaW50IG9mZnNldCA9IHBjaV9maW5kX2NhcF9vZmZzZXQo
cGRldi0+c2JkZiwgY2FwKTsNCj4+ICsgICAgc3RydWN0IHZwY2lfcmVnaXN0ZXIgKnByZXZfbmV4
dF9yLCAqbmV4dF9yOw0KPj4gKyAgICBzdHJ1Y3QgdnBjaSAqdnBjaSA9IHBkZXYtPnZwY2k7DQo+
PiArDQo+PiArICAgIHNwaW5fbG9jaygmdnBjaS0+bG9jayk7DQo+PiArICAgIG5leHRfciA9IHZw
Y2lfZ2V0X3JlZ2lzdGVyKHZwY2ksIG9mZnNldCArIFBDSV9DQVBfTElTVF9ORVhULCAxKTsNCj4+
ICsgICAgaWYgKCAhbmV4dF9yICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgc3Bpbl91bmxvY2so
JnZwY2ktPmxvY2spOw0KPj4gKyAgICAgICAgcmV0dXJuOw0KPj4gKyAgICB9DQo+PiArDQo+PiAr
ICAgIHByZXZfbmV4dF9yID0gdnBjaV9nZXRfcHJldmlvdXNfY2FwX3JlZ2lzdGVyKHZwY2ksIG9m
ZnNldCk7DQo+PiArICAgIEFTU0VSVChwcmV2X25leHRfcik7DQo+PiArDQo+PiArICAgIHByZXZf
bmV4dF9yLT5wcml2YXRlID0gbmV4dF9yLT5wcml2YXRlOw0KPj4gKw0KPj4gKyAgICBpZiAoICFp
c19oYXJkd2FyZV9kb21haW4ocGRldi0+ZG9tYWluKSApDQo+PiArICAgIHsNCj4+ICsgICAgICAg
IHN0cnVjdCB2cGNpX3JlZ2lzdGVyICppZF9yID0NCj4+ICsgICAgICAgICAgICB2cGNpX2dldF9y
ZWdpc3Rlcih2cGNpLCBvZmZzZXQgKyBQQ0lfQ0FQX0xJU1RfSUQsIDEpOw0KPj4gKw0KPj4gKyAg
ICAgICAgQVNTRVJUKGlkX3IpOw0KPj4gKyAgICAgICAgLyogUENJX0NBUF9MSVNUX0lEIHJlZ2lz
dGVyIG9mIHRhcmdldCBjYXBhYmlsaXR5ICovDQo+PiArICAgICAgICBsaXN0X2RlbCgmaWRfci0+
bm9kZSk7DQo+PiArICAgICAgICB4ZnJlZShpZF9yKTsNCj4gDQo+IFlvdSBjb3VsZCB1c2UgdnBj
aV9yZW1vdmVfcmVnaXN0ZXIoKSBoZXJlPw0KUmlnaHQuDQoNCj4gDQo+PiArICAgIH0NCj4+ICsN
Cj4+ICsgICAgLyogUENJX0NBUF9MSVNUX05FWFQgcmVnaXN0ZXIgb2YgdGFyZ2V0IGNhcGFiaWxp
dHkgKi8NCj4+ICsgICAgbGlzdF9kZWwoJm5leHRfci0+bm9kZSk7DQo+PiArICAgIHNwaW5fdW5s
b2NrKCZ2cGNpLT5sb2NrKTsNCj4+ICsgICAgeGZyZWUobmV4dF9yKTsNCj4gDQo+IEhlcmUgdnBj
aV9yZW1vdmVfcmVnaXN0ZXIoKSBjb3VsZCBhbHNvIGJlIHVzZWQsIGJ1dCBpdCB3aWxsIGludm9s
dmUNCj4gc2VhcmNoaW5nIGFnYWluIGZvciB0aGUgcmVnaXN0ZXIgdG8gcmVtb3ZlLCB3aGljaCBp
cyBhIGJpdCBwb2ludGxlc3MuDQpZZXMsIHNvIGp1c3Qga2VlcGluZyB0aGluZ3MgaGVyZSBpbnN0
ZWFkIG9mIGNhbGxpbmcgdnBjaV9yZW1vdmVfcmVnaXN0ZXIoKT8NCg0KPiANCj4+ICt9DQo+PiAr
DQo+PiArc3RhdGljIHZvaWQgdnBjaV9pbml0X2NhcGFiaWxpdGllcyhzdHJ1Y3QgcGNpX2RldiAq
cGRldikNCj4+ICB7DQo+PiAgICAgIGZvciAoIHVuc2lnbmVkIGludCBpID0gMDsgaSA8IE5VTV9W
UENJX0lOSVQ7IGkrKyApDQo+PiAgICAgIHsNCj4+IEBAIC0xMDcsMTAgKzIwNywxNyBAQCBzdGF0
aWMgaW50IHZwY2lfaW5pdF9jYXBhYmlsaXRpZXMoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAg
ICAgICAgICByYyA9IGNhcGFiaWxpdHktPmluaXQocGRldik7DQo+PiAgDQo+PiAgICAgICAgICBp
ZiAoIHJjICkNCj4+IC0gICAgICAgICAgICByZXR1cm4gcmM7DQo+PiArICAgICAgICB7DQo+PiAr
ICAgICAgICAgICAgaWYgKCBjYXBhYmlsaXR5LT5maW5pICkNCj4+ICsgICAgICAgICAgICAgICAg
Y2FwYWJpbGl0eS0+ZmluaShwZGV2KTsNCj4+ICsNCj4+ICsgICAgICAgICAgICBwcmludGsoWEVO
TE9HX1dBUk5JTkcgIiVwZCAlcHA6ICVzIGNhcCAldSBpbml0IGZhaWwgcmM9JWQsIG1hc2sgaXRc
biIsDQo+IA0KPiBCZXN0IHRvIHNwbGl0IHRvIG5leHQgbGluZToNCj4gDQo+ICAgICAgICAgICAg
ICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HDQo+IAkgICAgICAgICAgICAgIiVwZCAlcHA6ICVzIGNh
cCAldSBpbml0IGZhaWwgcmM9JWQsIG1hc2sgaXRcbiIsDQo+IA0KPiBUaGFua3MsIFJvZ2VyLg0K
DQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Wed May 07 07:26:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 07:26:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978247.1365071 (Exim 4.92)
	(envelope-from )
	id 1uCZAn-0004hI-I1; Wed, 07 May 2025 07:26:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978247.1365071; Wed, 07 May 2025 07:26:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCZAn-0004hB-Eg; Wed, 07 May 2025 07:26:33 +0000
Received: by outflank-mailman (input) for mailman id 978247;
 Wed, 07 May 2025 07:26:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCZAm-0004h5-7N
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 07:26:32 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2060b.outbound.protection.outlook.com
 [2a01:111:f403:2009::60b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 97ecd3ed-2b14-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 09:26:29 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by BL3PR12MB6404.namprd12.prod.outlook.com (2603:10b6:208:3b4::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.21; Wed, 7 May
 2025 07:26:21 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8699.012; Wed, 7 May 2025
 07:26:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 97ecd3ed-2b14-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vchyJjtoWWRTcFCuKij7AyJMRP7NrkuDMyqOQOzXKr0IwpjA4Xnu632e81Qyp+dLivWaYm5wGJXe+/rm3M8G71htcdfORUQ9HaAxol/pPceBCbhrqYBhYLZWSPtrMOYmrRnoQ9/M3xrNbhGnbnTA6S/X0kJxiY+iG48rIMj+tnBlClxIZNuPXZpkN2OLK2P4TLFO2tiUfx+m5x3BCDRzNwhQ5J6/jw5LpKIsxmP6xF93CutTrtOYUzOYMP64VvQLjldTwBsvW/HWTnmFQ6jSHTPGO5ijA0w5f5EGfZFFGI6UTPcgxHuD+QrLek/RUbMCr/VIG+gKVYaE0PkuCXEaWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6zzPfcQAlF0IvpQv5qBLJEQD5SOS7tHGLQU9VaBR2xo=;
 b=S6SHHM4iBcS2tTHTuN++inJxFfzgj7rgcsMQcjKDYeVffiSyklIiyTBy30rV5Qzt/KzIlYy4XfhsjefuLHubvEEkF20VJWvM2kn73wByjDrstJbBtjxx/u2c0rCvj+mbT5Y8jU/Oi4cdZsYyUWwJcIvZZxIFjWtI9kMi2YVAxBDBKJN5OHbqGrHPsZG9xNcTA03oPKufAG5gGe2lrEs84tlgYrWGLH1rZUPQ49AiqF1hk7AtGtWAp+fmbvLnSGkWoweLPDIBZ4TO2c2TezoarMludt1FB7J2mDAA8BvveairGNDu/FhSFw9AR6yXpxpox2SCyP5v2+eB3YS4xkKQoQ==
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=6zzPfcQAlF0IvpQv5qBLJEQD5SOS7tHGLQU9VaBR2xo=;
 b=H7htOTIZJkI0j1XicaahjbL0f3f5ZjiDwia9fAiNnlW3GWjpePABQuEC9kQf5i9SO5br9woLMvvUVGli/NIY7BU78eVfYCMO4IbM1lENm8+0zAE5imxECGyODgGWaNiiDfe++8idO9JnNh7ZLmgS9mldbTTBtqIfnQIjVbnXteY=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v3 07/11] vpci: Hide extended capability when it fails to
 initialize
Thread-Topic: [PATCH v3 07/11] vpci: Hide extended capability when it fails to
 initialize
Thread-Index: AQHbsoVd9OkTHNIeNk69huFsDqzHMLPF4NaAgAGCYAA=
Date: Wed, 7 May 2025 07:26:21 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-8-Jiqian.Chen@amd.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8699.005)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|BL3PR12MB6404:EE_
x-ms-office365-filtering-correlation-id: 1fa55f8e-5892-4cf6-0ec2-08dd8d387761
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?eDJDR2ZZQVZidU9TVnJPK3k5UTg3dGJuMk04QS8zdmZmZ1FrbDRWQXNEN2Iv?=
 =?utf-8?B?SnYzMjJnOXJFdktyZnc5Tk83QW00aU14MkZJY2ZBUHNIbytZSTBwNTJ5elAy?=
 =?utf-8?B?dk5KUjhYOTZoMjR1YkFzc1dMVE14eEhibHc3eTNtTUIrZ3dENHkvVE1mdXdz?=
 =?utf-8?B?STU3d3lFNUw0THhweDZYeHpUblhJUUhOc2VVZTFaU3NSOWV3UGFTUDFxSE1C?=
 =?utf-8?B?R21jRWR0WVU5V3ZHYUhuTWlYR0I1N3dPa0JvMG9JYUNkcHJJZ200V1NZTEp2?=
 =?utf-8?B?UUx6azRURWMvODVFVmFaVnRKV1RVUkRwM0RKSDV2bHhjYWI1aWlpUjVTMmp2?=
 =?utf-8?B?NkZ4cTFMamRRcTkzdk81cHhEUk5VSGVMMElXWnBxRGU2Q1g5b3VBbDkvTm94?=
 =?utf-8?B?RXJsLzdMWE4raGxhOVI4RmJEMjhKK3g0UmpWWlR2Z3I1bmR5UFlERGx2Qk9C?=
 =?utf-8?B?S01DREEyOVVKQmR4a1dQQjNMWGZRalZmQy9vdmlHbERvKzFBdEZScitrcGtN?=
 =?utf-8?B?OU8xYnRkNXJjZ041ekZWYktzVFJBSVhXb3V0eUthd1h0cGFORXlXVmhuYWVV?=
 =?utf-8?B?QXVUTnovUUkxTnNuY0piZENVWE5KUlVGenlsU2ZhOUx1d2o2ekZKUS9BVTV2?=
 =?utf-8?B?MFoxUXY3ODc4RitxTG9oN2Z1djRxMmhvZ2R6RzJ4MUdXVnV2UVFXc0xTYTND?=
 =?utf-8?B?WEpOcVk2aUtsR1pIWVE1enN5dXpqSFF4RlQ2UUdxemRaUmV4a3ZKWXh1YmR5?=
 =?utf-8?B?ZXcrNTM1ZWtlRUhtallncDE4anZuY21BT0VHeWxjcFVqNU9aV2RJazZTVkJL?=
 =?utf-8?B?UEY2ckF4OFRrVFU2Vms4SlVHckFkUGRZQ0lGTnNLd2JhSkFRY25taUlBYWVJ?=
 =?utf-8?B?aVI0U0x5d254bjBwUmN0aXdVSTNYWnZ0YmlJWmVnUXA3eGdkR1A3ZlpxN3lM?=
 =?utf-8?B?dld3aWsrdDkzelhFTTJQcVE2WHJEc3NzNTFyR1hFR0dtaHU0SEJTeDBoU1Nr?=
 =?utf-8?B?TndRU2N0L2NZRjJGR01kYXFHbSthaG5PQlEwNTBYV0FIMU8yek5LVEtJY2JK?=
 =?utf-8?B?VzVYSXlkMVk4WmNHU0pJcWRuSWVoZ0kvazJ2OE9tcFlFUGRscGhaYkZQNjE1?=
 =?utf-8?B?TXFvUVhJSGJuWXNZUXRlWHNENWdiMDNVK1IyU2JrUm0rU3Bmb1QxWmRmR0ho?=
 =?utf-8?B?RGREY3RjNFc3NUxmRitDQ0pwT0lyKzdFMnpLbXJjT0hMdVYxNnk4cytXQytH?=
 =?utf-8?B?RnZWN2VUKzdCSUN2NndKVmdPWGxBWGdFZDFFNWlBL1VDaHVRM1p5Zk1IWHo5?=
 =?utf-8?B?UlhkZ2wrMjk4NWI1cnNRNlh5SUtyTnRaSWphcFAyVTJFVTAzUnZHMGJqSUpm?=
 =?utf-8?B?Z05YU29tbUN3S1Jjd0E1SFgxdmRMdFRkZ3pzekJKdWlES3JQcGdwbFRodTFp?=
 =?utf-8?B?bnV2Y1V1Y2J1OVdNTWVZYlZMY1V2V0NDVVdqSkRidHdsQVpvUm9EQ3h3b1px?=
 =?utf-8?B?Y0RyeWVCcGlDdmlMOERBbjZLMlBFVEw4eUQwdmwzaGsrYlRVZUxiRzk5U0lR?=
 =?utf-8?B?STRVVlUveFg1NVRaR2RXcDJKaiszdC82cWhqM1RTK0p1bExLb1VybG9SRFVZ?=
 =?utf-8?B?TXBBNDlTUWdSVXVpbXh5TGpDTFBKN3BBQlNKL1ZrSzN0RlpqaVViRGt4UVRW?=
 =?utf-8?B?bkZPZSswVlRGalV5NnMzWVBpelpkUTlZcUVoU2h4QldabWo1aUVhMllvTjNy?=
 =?utf-8?B?YTRjNm44SmVFR1lNblMzcWVKU1ZTdTd1S0tCVHVlSHdOVUt1Mi9ZeVRJb0dY?=
 =?utf-8?B?RnEvcC9jYkdGS1hNVk1ncHc1NXozUld4TWRDVDh0NFRtNGxyS2RpSGUwQXN3?=
 =?utf-8?B?bjRNRVRBTnh1QmV5TFV4MityVHNxMGQ0ODF1WHJOZm1URm5UdEdlMVpTdlQx?=
 =?utf-8?B?Y2YrcXBoUjZ6SEpyRElJNzdsc2N1WmkrdGw0RkRBVUg3Z2tsOTFiL2h2aWg5?=
 =?utf-8?B?SFNnRDZIeUFnPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SnljdGNlNzNlYkZlUHdRMlhDOHc2aEtCaGZnRWRHRnBkNDhydytKUVlvMmlj?=
 =?utf-8?B?RzEyYXdaV2toSEM4KzhWQ3FJSXNVK2FqbEVSTktaYmdFbkZobUdWYWNaMWly?=
 =?utf-8?B?dVYvSWFGdjJoaXJBREx0a0EvZUVJZXEwVjYwMUlYQWFNS2RacnIwTDd6QmFM?=
 =?utf-8?B?ZWh3allKWE9qYUlvbEkrdmptaGp2SndCRkx3OHRhOHhjZGRoTWNRTzAwd05E?=
 =?utf-8?B?RHZ3QTJsQ29iZmR4bFZ4dmx2S3VoSEdKN2o3cHZrancwNzVHTHJETVBFaGtp?=
 =?utf-8?B?K21JK1B4Q2x0dU5DV0QzUmVzcjI1T3dWM2NHcDdTb0NkTUhaQkNTT1ExZ3dW?=
 =?utf-8?B?cFRjZ0hFeTYvNTBMNmlFWkNvY1V6Wk1ZYzNEMlpKelRnUGp6QlVpc0xzUzdq?=
 =?utf-8?B?VUp1c3lkbGZtZG05Z0NOVDBVdzRncng1ZWRCYll4YWVYbVZjSUU0WU9NVlh5?=
 =?utf-8?B?akR0NGJSUWxJcDFNYSt4bDUyQUQrSjZTNDJhZmtITm9jSk9HSmtWblpIejZW?=
 =?utf-8?B?WlJjZU9jeFRlQ1dULzQwdjlsT3k0TFZOL1ZUcmV1aWk2M2JjVjhaMzc1cnVV?=
 =?utf-8?B?WkxPMWs3a0VpS2pPdlhOL0FLV1luMWhLck42WTFNQW5nWVJRTFhxaE1TbXFG?=
 =?utf-8?B?blZwaWQ3Z0xyeFpjV1M0Q05uVlA0TzJUc2F2QUpNL3pHRyt5TzZRQms2eTZy?=
 =?utf-8?B?UDNRMUlNSzFDZVJkb096cWltNnRmaTZhWXFoNnFjbHhhTmNIcFJyNXVxa1R1?=
 =?utf-8?B?ODhkR2U0R25HVkF6T1VpK1VwRjJXZS9VUmVtREYyUk5CSDUzTHVsT0ZHOEN2?=
 =?utf-8?B?SHdINjJPYkpyRjEyd3Q5Y0NmdVpzcnUwVlZWSTFPZ001YTljSjd2VW00Rjh1?=
 =?utf-8?B?aUhqWFd1UVMrTmx3YXFKSjNZWFUrWFFZSzZsQ2FOSGxIR3pSbi9qTSs4NUwx?=
 =?utf-8?B?aTQ0OUdnSFU1QlVJOHBJQzRvdG5pVnV0eW9Vbnd4YU1HNTcwajdzem92ekxX?=
 =?utf-8?B?anpUTTVJV2JlMWVLdHJMOFRTamdseE55MVhVNHRTTTBHWTRjaWdITFk3SGFP?=
 =?utf-8?B?VGQrRXRVQXF3NmVDNUtlMVB3YWpoVWVtbDFnc041MEJ0aEV1V3pIOVlVdEsz?=
 =?utf-8?B?b2xpMWR1a2JheSs2RVdtMk5xbkJlTmF6VUZOZGE2WC9Rd2dyeVJLcVN1THZn?=
 =?utf-8?B?WWM4bVNhTjcrOGNyL0xVMCtVMzErV0ErYzRLZnZjY1c5Rk54K3dpdEFYb0s3?=
 =?utf-8?B?T2tFVGExWXRmR0FYNnNMakY0ZjJrQUY2M0l3UkNRVFNjMGhxR0xCWnUwNTE2?=
 =?utf-8?B?cjEvNmNKOFppMWd6elJRNUI4dWV3RnE1bHB4UFpmNytwZnVJTkdSOXRBRTdj?=
 =?utf-8?B?VzgybmtZOXBZTzdlYWdjNzJTc3lDTzFEWGwwdWdjQWpEakdVeXpSK3ZsTGxB?=
 =?utf-8?B?Z3hxYitnQkpQOFlMYmJoZ0tXNUYyYXVxazNUMFNzR2RoN2VBWnJBdU1IOUQz?=
 =?utf-8?B?MHBSYlIzZ3g5K1hEc1hqUXpYYUlGMmVkSGZnSFNYazRicGlMMGl1YmdOUXlu?=
 =?utf-8?B?M25zQ1o0K2FSRzJVb0RaQ1FLSFhzT25xTmFXWkVtam1tUnpRaUM1b3BhK2xJ?=
 =?utf-8?B?MVFvMHZTSk9KQVlrK0toOFo2RHBuR1V1WXEyd0lFVGFVbGV4cHptSXk1S0pV?=
 =?utf-8?B?TExEYzhhQUxSSjM5VUdwMjNkcGJvUkd6aEhzWDRaWE0wSWp6MVB1bU1rVG1J?=
 =?utf-8?B?Sjg4V2JleWVaZDl0OFduejN5RVgwbG9SS3BHS0x3bFNUSnVoQk9NZVZsam4z?=
 =?utf-8?B?N2hiUGprZkp2Syt0WXhsbGFteXJmVzgwbzcyeEJPMDVUMWxwN1NpRU5YVGJP?=
 =?utf-8?B?YjdlK0NxTk1LSzhGSGw2ampqeVptOG5WY1FicUZWcFlUR2FLMDhTV1Byd08w?=
 =?utf-8?B?NXE5cFJ5TDZmWmhYRXh6TG0walpPdVQ2L1Z4akJZTDQxVlZtTWk4bHc3S2lW?=
 =?utf-8?B?M3JXRm50bXNJZGZCQkI2NlZaRzVLRjR3eW4yU05xeCt1blpzbVdhM0V5RnJj?=
 =?utf-8?B?UEpTeVZreURXNzRzNVVHK3lFTEV2VFFmTnNBQXZjV3dPYzBoRkkrWTRjL2w0?=
 =?utf-8?Q?nGoI=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1fa55f8e-5892-4cf6-0ec2-08dd8d387761
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 07:26:21.6951
 (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: KrOdW+Pd6BRQEgmGPqdL+D1SYqBVDOAkQO5xtbtWK4a7g7KOHNeG3+iXU3qhCC3gRp2VHlAqU4yjyL1XS6V7Jw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6404

T24gMjAyNS81LzcgMDA6MjEsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgQXBy
IDIxLCAyMDI1IGF0IDAyOjE4OjU5UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gV2hl
biB2cGNpIGZhaWxzIHRvIGluaXRpYWxpemUgYSBleHRlbmRlZCBjYXBhYmlsaXR5IG9mIGRldmlj
ZSBmb3IgZG9tMCwNCj4+IGl0IGp1c3QgcmV0dXJuIGVycm9yIGluc3RlYWQgb2YgY2F0Y2hpbmcg
YW5kIHByb2Nlc3NpbmcgZXhjZXB0aW9uLiBUaGF0DQo+PiBtYWtlcyB0aGUgZW50aXJlIGRldmlj
ZSB1bnVzYWJsZS4NCj4+DQo+PiBTbywgYWRkIG5ldyBhIGZ1bmN0aW9uIHRvIGhpZGUgZXh0ZW5k
ZWQgY2FwYWJpbGl0eSB3aGVuIGluaXRpYWxpemF0aW9uDQo+PiBmYWlscy4gQW5kIHJlbW92ZSB0
aGUgZmFpbGVkIGV4dGVuZGVkIGNhcGFiaWxpdHkgaGFuZGxlciBmcm9tIHZwY2kNCj4+IGV4dGVu
ZGVkIGNhcGFiaWxpdHkgbGlzdC4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBKaXFpYW4gQ2hlbiA8
SmlxaWFuLkNoZW5AYW1kLmNvbT4NCj4+IC0tLQ0KPj4gY2M6ICJSb2dlciBQYXUgTW9ubsOpIiA8
cm9nZXIucGF1QGNpdHJpeC5jb20+DQo+PiAtLS0NCj4+IHYyLT52MyBjaGFuZ2VzOg0KPj4gKiBT
ZXBhcmF0ZWQgZnJvbSB0aGUgbGFzdCB2ZXJzaW9uIHBhdGNoICJ2cGNpOiBIaWRlIGNhcGFiaWxp
dHkgd2hlbiBpdCBmYWlscyB0byBpbml0aWFsaXplIi4NCj4+ICogV2hvbGUgaW1wbGVtZW50YXRp
b24gY2hhbmdlZCBiZWNhdXNlIGxhc3QgdmVyc2lvbiBpcyB3cm9uZy4NCj4+ICAgVGhpcyB2ZXJz
aW9uIGdldHMgdGFyZ2V0IGhhbmRsZXIgYW5kIHByZXZpb3VzIGhhbmRsZXIgZnJvbSB2cGNpLT5o
YW5kbGVycywgdGhlbiByZW1vdmUgdGhlIHRhcmdldC4NCj4+ICogTm90ZTogYSBjYXNlIGluIGZ1
bmN0aW9uIHZwY2lfZXh0X2NhcGFiaWxpdHlfbWFzaygpIG5lZWRzIHRvIGJlIGRpc2N1c3NlZCwN
Cj4+ICAgYmVjYXVzZSBpdCBtYXkgY2hhbmdlIHRoZSBvZmZzZXQgb2YgbmV4dCBjYXBhYmlsaXR5
IHdoZW4gdGhlIG9mZnNldCBvZiB0YXJnZXQNCj4+ICAgY2FwYWJpbGl0eSBpcyAweDEwMFUodGhl
IGZpcnN0IGV4dGVuZGVkIGNhcGFiaWxpdHkpLCBteSBpbXBsZW1lbnRhdGlvbiBpcyBqdXN0IHRv
DQo+PiAgIGlnbm9yZSBhbmQgbGV0IGhhcmR3YXJlIHRvIGhhbmRsZSB0aGUgdGFyZ2V0IGNhcGFi
aWxpdHkuDQo+Pg0KPj4gdjEtPnYyIGNoYW5nZXM6DQo+PiAqIFJlbW92ZWQgdGhlICJwcmlvcml0
aWVzIiBvZiBpbml0aWFsaXppbmcgY2FwYWJpbGl0aWVzIHNpbmNlIGl0IGlzbid0IHVzZWQgYW55
bW9yZS4NCj4+ICogQWRkZWQgbmV3IGZ1bmN0aW9uIHZwY2lfY2FwYWJpbGl0eV9tYXNrKCkgYW5k
IHZwY2lfZXh0X2NhcGFiaWxpdHlfbWFzaygpIHRvDQo+PiAgIHJlbW92ZSBmYWlsZWQgY2FwYWJp
bGl0eSBmcm9tIGxpc3QuDQo+PiAqIENhbGxlZCB2cGNpX21ha2VfbXNpeF9ob2xlKCkgaW4gdGhl
IGVuZCBvZiBpbml0X21zaXgoKS4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBKaXFpYW4gQ2hl
bi4NCj4+IC0tLQ0KPj4gIHhlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jICAgIHwgNzkgKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4+ICB4ZW4vaW5jbHVkZS94ZW4vcGNpX3Jl
Z3MuaCB8ICAxICsNCj4+ICAyIGZpbGVzIGNoYW5nZWQsIDgwIGluc2VydGlvbnMoKykNCj4+DQo+
PiBkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvdnBjaS92cGNpLmMgYi94ZW4vZHJpdmVycy92cGNp
L3ZwY2kuYw0KPj4gaW5kZXggZjk3YzdjYzQ2MGEwLi44ZmY1MTY5YmRkMTggMTAwNjQ0DQo+PiAt
LS0gYS94ZW4vZHJpdmVycy92cGNpL3ZwY2kuYw0KPj4gKysrIGIveGVuL2RyaXZlcnMvdnBjaS92
cGNpLmMNCj4+IEBAIC0xODMsNiArMTgzLDgzIEBAIHN0YXRpYyB2b2lkIHZwY2lfY2FwYWJpbGl0
eV9tYXNrKHN0cnVjdCBwY2lfZGV2ICpwZGV2LA0KPj4gICAgICB4ZnJlZShuZXh0X3IpOw0KPj4g
IH0NCj4+ICANCj4+ICtzdGF0aWMgc3RydWN0IHZwY2lfcmVnaXN0ZXIgKnZwY2lfZ2V0X3ByZXZp
b3VzX2V4dF9jYXBfcmVnaXN0ZXINCj4+ICsgICAgICAgICAgICAgICAgKHN0cnVjdCB2cGNpICp2
cGNpLCBjb25zdCB1bnNpZ25lZCBpbnQgb2Zmc2V0KQ0KPj4gK3sNCj4+ICsgICAgdWludDMyX3Qg
aGVhZGVyOw0KPj4gKyAgICB1bnNpZ25lZCBpbnQgcG9zID0gUENJX0NGR19TUEFDRV9TSVpFOw0K
Pj4gKyAgICBzdHJ1Y3QgdnBjaV9yZWdpc3RlciAqcjsNCj4+ICsNCj4+ICsgICAgaWYgKCBvZmZz
ZXQgPD0gUENJX0NGR19TUEFDRV9TSVpFICkNCj4+ICsgICAgICAgIHJldHVybiBOVUxMOw0KPj4g
Kw0KPj4gKyAgICByID0gdnBjaV9nZXRfcmVnaXN0ZXIodnBjaSwgcG9zLCA0KTsNCj4+ICsgICAg
QVNTRVJUKHIpOw0KPj4gKw0KPj4gKyAgICBoZWFkZXIgPSAodWludDMyX3QpKHVpbnRwdHJfdCly
LT5wcml2YXRlOw0KPj4gKyAgICBwb3MgPSBQQ0lfRVhUX0NBUF9ORVhUKGhlYWRlcik7DQo+PiAr
ICAgIHdoaWxlICggcG9zID4gUENJX0NGR19TUEFDRV9TSVpFICYmIHBvcyAhPSBvZmZzZXQgKQ0K
Pj4gKyAgICB7DQo+PiArICAgICAgICByID0gdnBjaV9nZXRfcmVnaXN0ZXIodnBjaSwgcG9zLCA0
KTsNCj4+ICsgICAgICAgIEFTU0VSVChyKTsNCj4+ICsgICAgICAgIGhlYWRlciA9ICh1aW50MzJf
dCkodWludHB0cl90KXItPnByaXZhdGU7DQo+PiArICAgICAgICBwb3MgPSBQQ0lfRVhUX0NBUF9O
RVhUKGhlYWRlcik7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgaWYgKCBwb3MgPD0gUENJX0NG
R19TUEFDRV9TSVpFICkNCj4+ICsgICAgICAgIHJldHVybiBOVUxMOw0KPj4gKw0KPj4gKyAgICBy
ZXR1cm4gcjsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHZvaWQgdnBjaV9leHRfY2FwYWJpbGl0
eV9tYXNrKHN0cnVjdCBwY2lfZGV2ICpwZGV2LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBjb25zdCB1bnNpZ25lZCBpbnQgY2FwKQ0KPj4gK3sNCj4+ICsgICAgY29u
c3QgdW5zaWduZWQgaW50IG9mZnNldCA9IHBjaV9maW5kX2V4dF9jYXBhYmlsaXR5KHBkZXYtPnNi
ZGYsIGNhcCk7DQo+PiArICAgIHN0cnVjdCB2cGNpX3JlZ2lzdGVyICpybSwgKnByZXZfcjsNCj4+
ICsgICAgc3RydWN0IHZwY2kgKnZwY2kgPSBwZGV2LT52cGNpOw0KPj4gKyAgICB1aW50MzJfdCBo
ZWFkZXIsIHByZV9oZWFkZXI7DQo+IA0KPiBNYXliZSBzYW5pdHkgY2hlY2sgdGhhdCBvZmZzZXQg
aXMgY29ycmVjdD8NCldoYXQgZG8geW91IG1lYW4gc2FuaXR5IGNoZWNrPw0KRG8gSSBuZWVkIHRv
IGFkZCBzb21ldGhpbmc/DQoNCj4gDQo+PiArICAgIHNwaW5fbG9jaygmdnBjaS0+bG9jayk7DQo+
PiArICAgIHJtID0gdnBjaV9nZXRfcmVnaXN0ZXIodnBjaSwgb2Zmc2V0LCA0KTsNCj4+ICsgICAg
aWYgKCAhcm0gKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBzcGluX3VubG9jaygmdnBjaS0+bG9j
ayk7DQo+PiArICAgICAgICByZXR1cm47DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgaGVhZGVy
ID0gKHVpbnQzMl90KSh1aW50cHRyX3Qpcm0tPnByaXZhdGU7DQo+PiArICAgIGlmICggb2Zmc2V0
ID09IFBDSV9DRkdfU1BBQ0VfU0laRSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGlmICggUENJ
X0VYVF9DQVBfTkVYVChoZWFkZXIpIDw9IFBDSV9DRkdfU1BBQ0VfU0laRSApDQo+PiArICAgICAg
ICAgICAgcm0tPnByaXZhdGUgPSAodm9pZCAqKSh1aW50cHRyX3QpMDsNCj4+ICsgICAgICAgIGVs
c2UNCj4+ICsgICAgICAgICAgICAvKg0KPj4gKyAgICAgICAgICAgICAqIEVsc2UgY2FzZSBuZWVk
cyB0byByZW1vdmUgdGhlIGNhcGFiaWxpdHkgaW4gcG9zaXRpb24gMHgxMDBVIGFuZA0KPj4gKyAg
ICAgICAgICAgICAqIG1vdmVzIHRoZSBuZXh0IGNhcGFiaWxpdHkgdG8gYmUgaW4gcG9zaXRpb24g
MHgxMDBVLCB0aGF0IHdvdWxkDQo+PiArICAgICAgICAgICAgICogY2F1c2UgdGhlIG9mZnNldCBv
ZiBuZXh0IGNhcGFiaWxpdHkgaW4gdnBjaSBkaWZmZXJlbnQgZnJvbSB0aGUNCj4+ICsgICAgICAg
ICAgICAgKiBoYXJkd2FyZSwgdGhlbiBjYXVzZSBlcnJvciBhY2Nlc3Nlcywgc28ganVzdCBpZ25v
cmUgaXQgaGVyZSBhbmQNCj4+ICsgICAgICAgICAgICAgKiBob3BlIGhhcmR3YXJlIHdvdWxkIGhh
bmRsZSB0aGUgY2FwYWJpbGl0eSB3ZWxsLg0KPj4gKyAgICAgICAgICAgICovDQo+PiArICAgICAg
ICAgICAgcHJpbnRrKFhFTkxPR19FUlIgIiVwZCAlcHA6IGV4dCBjYXAgJXUgaXMgZmlyc3QgY2Fw
LCBjYW4ndCBtYXNrIGl0XG4iLA0KPj4gKyAgICAgICAgICAgICAgICAgICBwZGV2LT5kb21haW4s
ICZwZGV2LT5zYmRmLCBjYXApOw0KPiANCj4gSW4gdGhpcyBjYXNlLCBjb3VsZCB5b3UgbWF5YmUg
cmVwbGFjZSBqdXN0IHRoZSBjYXBhYmlsaXR5IElEIHBhcnQgb2YNCj4gdGhlIGhlYWRlciB0byBy
ZXR1cm4gMD8gIFRoYXQgd2lsbCBsaWtlbHkgY2F1c2UgdGhlIE9TIHRvIGNvbnRpbnVlDQo+IHNj
YW5uaW5nIHRoZSBsaXN0LCB3aGlsZSBJRCAwIHdvbid0IG1hdGNoIHdoaWNoIGFueSBrbm93bg0K
PiBjYXBhYmlsaXR5Lg0KT0ssIHdpbGwgZG8gaW4gbmV4dCB2ZXJzaW9uLg0KDQo+IA0KPiBUaGFu
a3MsIFJvZ2VyLg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Wed May 07 07:45:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 07:45:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978258.1365080 (Exim 4.92)
	(envelope-from )
	id 1uCZSW-0007i6-Th; Wed, 07 May 2025 07:44:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978258.1365080; Wed, 07 May 2025 07:44: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 1uCZSW-0007hz-R8; Wed, 07 May 2025 07:44:52 +0000
Received: by outflank-mailman (input) for mailman id 978258;
 Wed, 07 May 2025 07:44:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCZSU-0007ht-Uk
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 07:44:51 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 272ed6f0-2b17-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 09:44:49 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-39c31e4c3e5so4029544f8f.0
 for ; Wed, 07 May 2025 00:44:49 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099ae834bsm16191367f8f.60.2025.05.07.00.44.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 00:44: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" 
X-Inumbo-ID: 272ed6f0-2b17-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746603888; x=1747208688; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=0gmiiCpwxuueYbDKPa3Xc5A+KGpxSQE5kI4ghDqkk4s=;
        b=Pe/MKpMqTJ/yJyXgEZAHrxglxeoYtPLa54/llUqlsmIzlhgUdoxE4LzeRQqjKt32Oy
         tJFD562vJWkjZHxUbTb5PwqAOn1oIucu+3LrNAtCs8FtvlLZmnZ33lFTUYbmi9D9udE8
         Wyxw5asU6qBZqu8KGGFdS5qbjUISCY9STA3+E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746603888; x=1747208688;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=0gmiiCpwxuueYbDKPa3Xc5A+KGpxSQE5kI4ghDqkk4s=;
        b=AHqZHd66lew8+i6lZPpql9Qw3ZwiAx6urgo8vJqXLDNjlGYzica8S/aJVMNe3AF7JA
         WASyLtqB7C7Q2a4SdSM8FXd+Btt0OzFbiURGE3ZAPAPS6mDrm9vI1yRUqEMCz/kdXGxR
         jULHj9Y/ehqI4GfrtVxdlozGsOxcOlPNYYSNzsWaUjp8Ynvbc0cy3qSBtgyWFr9QsuWM
         2t24L4SV0aJwm77RiLynoG13eMNDpQ7QBZs4kKcpwlwDFIgwxCvjyfMOBup8Kj5EArW6
         jk6rWSsYG3UFi4tOF9zP6woFGhcwPzbCbj09+vN1lGUwW5IXB7JyvkOppGSM7Wc26kuW
         nRwQ==
X-Gm-Message-State: AOJu0YzV97zqGE3GwLK6YkX8MZ8TmsiArRzj9WfKU68bMaL/kF6X8vx6
	TCMJg0RfhFYqLl4/nIhq59/3cyw/L7UINr0KYA75ASJlQ39CuQ7LxyCP1KPF7yI=
X-Gm-Gg: ASbGnctnv8jsHNZruyKHNhYC00xFyoksPEqi/W2jWraZuDBYHE6DLhqY7bYkKkHQshq
	6eZvqdw/10fC/5wun5i0TAhDLcLLIdP2h19N/30YGI1qlEu2+Azb+j4YHiHr7HO8XjkzfAMhz67
	B8LazWG0f2Or13Tlrpiu8xVqS4MdvOYcouU3Yis0cir3eRiPcpBPEI6fztpfvoND3fn7/tHPc03
	H2LSd7KwQEyZ6/ZsikPchmkWjVk2LOfZOm83UZVWDI4R7YUorlfGH1AjFWz+/ScMfTki6MSQ2bQ
	l9OF0eRmVRHxr2TxaUnNObaFZiupeJdNMAFCfxtF8uMDmvX1GoQ=
X-Google-Smtp-Source: AGHT+IFWhboqL8UsZxpyvGYtMnvtp+eDFPiI4G9p7XSJq2+cLoA/6/3+dp21t66YJ/Agix5QIK40Qg==
X-Received: by 2002:adf:cc90:0:b0:3a0:b559:cefa with SMTP id ffacd0b85a97d-3a0b559d02bmr1110124f8f.57.1746603888565;
        Wed, 07 May 2025 00:44:48 -0700 (PDT)
Date: Wed, 7 May 2025 09:44:47 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org,
	Oleksandr Andrushchenko ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Jiqian Chen ,
	Mykyta Poturai 
Subject: Re: [PATCH v20 2/2] vpci: translate virtual PCI bus topology for
 guests
Message-ID: 
References: <20250418185840.335816-1-stewart.hildebrand@amd.com>
 <20250418185840.335816-3-stewart.hildebrand@amd.com>
 
 <3693f1ef-e305-4a6b-bb4e-3b842418387f@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3693f1ef-e305-4a6b-bb4e-3b842418387f@amd.com>

On Tue, May 06, 2025 at 11:05:13PM -0400, Stewart Hildebrand wrote:
> On 5/6/25 07:16, Roger Pau Monné wrote:
> > Hello,
> > 
> > Sorry I haven't looked at this before, I was confused with the cover
> > letter having ARM in the subject and somehow assumed all the code was
> > ARM related.
> 
> No worries, thanks for taking a look.
> 
> > On Fri, Apr 18, 2025 at 02:58:37PM -0400, Stewart Hildebrand wrote:
> >> From: Oleksandr Andrushchenko 
> >>  static int vpci_register_cmp(const struct vpci_register *r1,
> >>                               const struct vpci_register *r2)
> >>  {
> >> @@ -438,7 +473,7 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
> >>      const struct pci_dev *pdev;
> >>      const struct vpci_register *r;
> >>      unsigned int data_offset = 0;
> >> -    uint32_t data = ~(uint32_t)0;
> >> +    uint32_t data = 0xffffffffU >> (32 - 8 * size);
> > 
> > This seems kind of unrelated to the rest of the code in the patch,
> > why is this needed?  Isn't it always fine to return all ones, and let
> > the caller truncate to the required size?
> > 
> > Otherwise the code in vpci_read_hw() also needs to be adjusted.
> 
> On Arm, since 9a5e22b64266 ("xen/arm: check read handler behavior") we
> assert that the read handlers don't set any bits above the access size.

I see.  That kind of diverges from x86 behavior, that AFAICT (see
memcpy() at tail of hvmemul_do_io()) instead truncates the memcpy to
the size of the access.

Maybe it would be better to instead of asserting just truncate the
returned value to the given size, as that would allow to just return
~0 from handlers without having to care about the specific access
size.

> I had adjusted data here due to returning it directly from vpci_read()
> in the current form of the patch. With your suggestion below we would
> only need to adjust vpci_read_hw() (and then data here would not
> strictly need adjusting).

Both returns would need adjusting IMO, and it should have been part of
9a5e22b64266 I think, since that's the commit that introduced the
checking.

> 
> > And
> > you can likely use GENMASK(size * 8, 0) as it's easier to read.
> 
> OK. I'll then also provide a definition for GENMASK in
> tools/tests/vpci/emul.h.
> 
> >>  
> >>      if ( !size )
> >>      {
> >> @@ -453,9 +488,21 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
> >>       * pci_lock is sufficient.
> >>       */
> >>      read_lock(&d->pci_lock);
> >> -    pdev = pci_get_pdev(d, sbdf);
> >> -    if ( !pdev && is_hardware_domain(d) )
> >> -        pdev = pci_get_pdev(dom_xen, sbdf);
> >> +    if ( is_hardware_domain(d) )
> >> +    {
> >> +        pdev = pci_get_pdev(d, sbdf);
> >> +        if ( !pdev )
> >> +            pdev = pci_get_pdev(dom_xen, sbdf);
> >> +    }
> >> +    else
> >> +    {
> >> +        pdev = translate_virtual_device(d, &sbdf);
> >> +        if ( !pdev )
> >> +        {
> >> +            read_unlock(&d->pci_lock);
> >> +            return data;
> >> +        }
> > 
> > You don't need this checking here, as the check below will already be
> > enough AFAICT, iow:
> > 
> >     if ( is_hardware_domain(d) )
> >     {
> >         pdev = pci_get_pdev(d, sbdf);
> >         if ( !pdev )
> >             pdev = pci_get_pdev(dom_xen, sbdf);
> >     }
> >     else
> >         pdev = translate_virtual_device(d, &sbdf);
> > 
> >     if ( !pdev || !pdev->vpci )
> >     {
> >         read_unlock(&d->pci_lock);
> >         return vpci_read_hw(sbdf, reg, size);
> >     }
> > 
> > Achieves the same and is more compact by having a single return for
> > all the possible cases?  Same for the write case below.
> 
> Seeing as there is a is_hardware_domain check inside vpci_read_hw(),
> that is okay. I'll make the adjustment here and in vpci_write.

Yup, vpci_read_hw() is already prepared to handle calls from
!is_hardware_domain() contexts.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 07 07:49:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 07:49:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978269.1365091 (Exim 4.92)
	(envelope-from )
	id 1uCZXA-0008Hl-Ei; Wed, 07 May 2025 07:49:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978269.1365091; Wed, 07 May 2025 07:49: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 1uCZXA-0008He-Bs; Wed, 07 May 2025 07:49:40 +0000
Received: by outflank-mailman (input) for mailman id 978269;
 Wed, 07 May 2025 07:49:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCZX9-0008HW-WC
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 07:49:40 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d40ef93d-2b17-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 09:49:39 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-39c266c1389so4854890f8f.1
 for ; Wed, 07 May 2025 00:49:39 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099b0ff8esm16100973f8f.79.2025.05.07.00.49.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 00:49: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" 
X-Inumbo-ID: d40ef93d-2b17-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746604178; x=1747208978; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=XWt0KM57gedTPq6s9IEoY1RbEhpPIPW/ujLv4pyJ5zo=;
        b=MT0TJXB8qChcioOhk8joCckJKIsegncFSXfmL5PLtFVQVKUh/wOL5F7KptVmQ7HIpN
         efbm3RSTVRULcIeQb9321Uzhqstk6NZdw8SanLCIPjJ8UPy5k2wWr4BIrOQms+qWZI9i
         U1q6V4jK5Q2usLTSGSptqbMLgJ3YlzE19ari8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746604178; x=1747208978;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=XWt0KM57gedTPq6s9IEoY1RbEhpPIPW/ujLv4pyJ5zo=;
        b=mZ0nm0UsDCbAvxpC06PwJeNDy6B2DQGxjYmdPNRYvhP9Nt9qkBNwBHmNfXPVN9lYMs
         9kftOyTETwxTgVJjWdPPQvKphJoIMQ98NPBlitgdH0vHchOZG4lJ5LOiCteylBl7Oz86
         1ASks28lErMIZRTda6luBQVb5pDwhD1Y2lqZOOArExIFuTKF2EXEL4FHteh0YuxQlmsx
         CO5DvM75kPYcY3LKVqeeVkFpaQrINsPQukA1WLZVfhnUF6B5NrW8eh+9YEpX/LTlLVvg
         xv2FxoreA2f3He3O7dQUyCfyRTiJC8G577OqgF4fMO0zjg+gm9CthnR3HvciQEdzmvcD
         slsA==
X-Gm-Message-State: AOJu0Yw7TVptgk7oQ1TbYJXnR0qJGLsMGIXQYt0NUroTheb5fc4Tg1DA
	DEAzVZoUa19+cOkb0ULuAwWitnMNgqK980yBNfCSdl3CbejLv+ynI6qO7vuzRJI=
X-Gm-Gg: ASbGnctOXuhNvUrejuzfsTDKaURn+bNSEcJMwNAgf+odu3/rN6/Ih1pfsfjnjl8fKgU
	GIbxRlaEJ8FraOftmXcEWM/ten/jn+0WBmj+cOtAYqYvk4kWWZuqiLRrRdN7PcRi1Rwa8Ny63Ut
	CsPuSEk05crY90iYc920jdD1Y3ic2C4O32XDTU37P5pRPRKN3CgNiQJm6HToXmGPlmeENm6A20I
	24iftme+o4T9FjuRH5tUH/uTQm8iF5WV5xtLpypaJ3dGRfQoROD4VeDEk/Oxct6ZznB62XfI4v+
	uFOUNO3J7MKHo+t8yv3Pnq2zIhxUNUCj+3c4Q2cQOLtRtVFOWiY=
X-Google-Smtp-Source: AGHT+IHdWbaJf3eoRn53CameljCGVIWiJk6+2ddXr0TJyOExc10S40/dMJhoQT54ArSbjO4ZiAV0Bw==
X-Received: by 2002:a05:6000:4387:b0:3a0:a19f:2f47 with SMTP id ffacd0b85a97d-3a0b4a1be6cmr1877491f8f.42.1746604178551;
        Wed, 07 May 2025 00:49:38 -0700 (PDT)
Date: Wed, 7 May 2025 09:49:37 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v3 03/11] vpci/header: Emulate legacy capability list for
 dom0
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-4-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 07, 2025 at 02:46:52AM +0000, Chen, Jiqian wrote:
> On 2025/5/6 21:50, Roger Pau Monné wrote:
> > On Mon, Apr 21, 2025 at 02:18:55PM +0800, Jiqian Chen wrote:
> >> Current logic of emulating legacy capability list is only for domU.
> >> So, expand it to emulate for dom0 too. Then it will be easy to hide
> >> a capability whose initialization fails in a function.
> >>
> >> Signed-off-by: Jiqian Chen 
> > 
> > Sorry, one nit I've noticed while looking at the next patch.
> > 
> >> @@ -786,13 +787,15 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
> >>  
> >>              next = pci_find_next_cap_ttl(pdev->sbdf,
> >>                                           pos + PCI_CAP_LIST_NEXT,
> >> -                                         supported_caps,
> >> -                                         ARRAY_SIZE(supported_caps), &ttl);
> >> +                                         caps, n, &ttl);
> >>  
> >> -            rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
> The same here, NULL -> vpci_hw_write8, I think.

No, not here, since the PCI_CAP_LIST_ID handler is only added for
non-hardware domains, and in that case we do want to ignore writes to
the register.

> >> -                                   pos + PCI_CAP_LIST_ID, 1, NULL);
> >> -            if ( rc )
> >> -                return rc;
> >> +            if ( !is_hwdom )
> >> +            {
> >> +                rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
> >> +                                       pos + PCI_CAP_LIST_ID, 1, NULL);
> >> +                if ( rc )
> >> +                    return rc;
> >> +            }
> >>  
> >>              rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
> > 
> > For the hardware domain the write handler should be vpci_hw_write8
> > instead of NULL.
> OK, I think I need to add definition of vpci_hw_write8.
> But I have a question, if hardware domain write this register through vpci_hw_write8,
> then the "next address data" of hardware will be in consistent with vpci.
> Is it fine? Or should I update vpci's cache?

According to the spec this field is read-only, so writes should be
ignored.  We allow hardware domain full access because for hardware
domain we aim to trap as little as possible to not diverge behavior
from native, and to allow possible device quirks to work.

It could be conceivable that some vendor has a hidden specific
functionality that somehow triggered by a write to this field.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 07 07:55:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 07:55:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978285.1365105 (Exim 4.92)
	(envelope-from )
	id 1uCZcU-0001gC-4h; Wed, 07 May 2025 07:55:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978285.1365105; Wed, 07 May 2025 07:55:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCZcU-0001g5-1y; Wed, 07 May 2025 07:55:10 +0000
Received: by outflank-mailman (input) for mailman id 978285;
 Wed, 07 May 2025 07:55:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCZcS-0001fs-VG
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 07:55:08 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 95759938-2b18-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 09:55:03 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43cf680d351so3197765e9.0
 for ; Wed, 07 May 2025 00:55:03 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441d433e9b7sm22385345e9.8.2025.05.07.00.55.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 00:55:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 95759938-2b18-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746604503; x=1747209303; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=FGw7I+VwKRsIFghYHwgaG95hNdLHH6DjWwurVpWzM3w=;
        b=Q5DUM0joy2I3wkHqA0BsJu/IDbX7Ixbg6x0dei7OmBQPV6LtkDVkOwDxcRii5iVUUB
         DvKrG95cv7OAPvomx/m94w3UqWXTuUPnfX9h6VWe57ifXeeCQAmIuwzUSvK3+45VcTx4
         kmnP0DMFkRI08kcGtl5A10ZQ1Yfni3g88VPNg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746604503; x=1747209303;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=FGw7I+VwKRsIFghYHwgaG95hNdLHH6DjWwurVpWzM3w=;
        b=gswek/NQAC6GvZ+yVV8oMKodhHnSqvFUn8F2QbM20qLhK4JOluEIRqH814KQldotTB
         v9+sV4o/dHSYvkOhfXDCYy3Za7aeGAjh/nDzUYwdC2byGPylEhtgIfAkEoUZ2+14kGYB
         GC9GRmYLQRNni0krJX+L16ObaIYz2CVb5YN8V3u+uQ9HkyJpS21jbcCnwj+g0xBHFbuJ
         x/YxiatsC56mudxuqJV6XI4ktQ2oTGnHAfpyrF5u5lV2Xm//CtZJwabofztKUKKvL9uj
         3aW6x83z40729pnqKWcRLzt0LcRlJDC1rGl3vW29G+pPZ0Erh73v6A1kc4LYnLsIh0Ko
         bvag==
X-Gm-Message-State: AOJu0YxGq/sJD4cBxPCigrpWdk7UwjyDVHo7dKz4uXho6n0lmflTntQ/
	n84nBCPNdTwbDCznorGmU7MR9szOfEuRrOPs66+U1WU7SSn4ioGpenInAuZ3Lv4=
X-Gm-Gg: ASbGncs/aHZWNVjxWUvMR84hhJTJ9cYCADLfDw1OlVwHI2PgtkFi+w0QxrTg6FaP85A
	qq5RjS57lSpTvmwYxX4amewQvTb/FimcVwM8/fN5YKyoGGF4yrFdG/B2kzfOuA1EFzC8U0tJrjO
	5Sn0G+GarTcZwhZOolKICClqib7L0M/ilsE6jH6wldOjoMo2b1Cqu9klJMUmgFDo3CH5F5UcmQs
	ZFFRgdaMD8Omkfhe6G1XAYmqzJgcxiLgggdcrAhrj4icGXFjaN6mSQ2VxORc3YN0DcMkkg7taXB
	na6O5x5S175OmxJCDfwWGNTp4AY3YBruVT9uyT50RgCAfemsRGU=
X-Google-Smtp-Source: AGHT+IGQR/eBXXKhPbK/ScevO6R78t55OPQUdi0VlhCL96a6Iya/PgH3FUPjn/Nwl0t5QmKldKXG8A==
X-Received: by 2002:a05:6000:2403:b0:39b:f44b:e176 with SMTP id ffacd0b85a97d-3a0b443e083mr1925035f8f.24.1746604503073;
        Wed, 07 May 2025 00:55:03 -0700 (PDT)
Date: Wed, 7 May 2025 09:55:02 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v3 04/11] vpci/header: Emulate extended capability list
 for dom0
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-5-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 07, 2025 at 03:32:47AM +0000, Chen, Jiqian wrote:
> On 2025/5/6 22:14, Roger Pau Monné wrote:
> > On Mon, Apr 21, 2025 at 02:18:56PM +0800, Jiqian Chen wrote:
> >> Add a new function to emulate extended capability list for dom0,
> >> and call it in init_header(). So that it will be easy to hide a
> >> extended capability whose initialization fails.
> >>
> >> As for the extended capability list of domU, just move the logic
> >> into above function and keep hiding it for domU.
> >>
> >> Signed-off-by: Jiqian Chen 
> >> ---
> >> cc: "Roger Pau Monné" 
> >> ---
> >> v2->v3 changes:
> >> * In vpci_init_ext_capability_list(), when domain is domU, directly return after adding a handler(hiding all extended capability for domU).
> >> * In vpci_init_ext_capability_list(), change condition to be "while ( pos >= 0x100U && ttl-- )" instead of "while ( pos && ttl-- )".
> >> * Add new function vpci_hw_write32, and pass it to extended capability handler for dom0.
> >>
> >> v1->v2 changes:
> >> new patch
> >>
> >> Best regards,
> >> Jiqian Chen.
> >> ---
> >>  xen/drivers/vpci/header.c | 36 ++++++++++++++++++++++++++++--------
> >>  xen/drivers/vpci/vpci.c   |  6 ++++++
> >>  xen/include/xen/vpci.h    |  2 ++
> >>  3 files changed, 36 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> >> index c98cd211d9d7..ee94ad8e5037 100644
> >> --- a/xen/drivers/vpci/header.c
> >> +++ b/xen/drivers/vpci/header.c
> >> @@ -817,6 +817,31 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
> >>                                    PCI_STATUS_RSVDZ_MASK);
> >>  }
> >>  
> >> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
> >> +{
> >> +    unsigned int pos = PCI_CFG_SPACE_SIZE, ttl = 480;
> >> +
> >> +    if ( !is_hardware_domain(pdev->domain) )
> >> +        /* Extended capabilities read as zero, write ignore for guest */
> >> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
> >> +                                 pos, 4, (void *)0);
> >> +
> >> +    while ( pos >= PCI_CFG_SPACE_SIZE && ttl-- )
> >> +    {
> >> +        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
> >> +        int rc;
> > 
> > I'm thinking it might be helpful to avoid setting the handler for the
> > last capability on the list, or simply for devices that have no
> > extended capabilities at all:
> > 
> > if ( PCI_EXT_CAP_NEXT(header) >= PCI_CFG_SPACE_SIZE )
> > {
> >     int rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
> >                                pos, 4, (void *)(uintptr_t)header);
> > 
> >     if ( rc )
> >         return rc;
> > }
> But if adding this check, there is a problem, think about this situation:
> a device only has one extended capability, then under your check, it does not add handler for it,
> if the initialization of that extended capability fails, we can't hide it by removing handler from vpci.
> If you want to avoid adding handler for devices that have no extended capabilities.
> I think adding check
> If ( header == 0 )
>     return 0;
> is enough.

Hm, yes, extended PCI capabilities don't have a start pointer like
legacy ones, so masking the initial capability (as you have discovered)
is not easy.  I agree with checking whether the initial header == 0
and then not adding any handler at all.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 07 08:04:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 08:04:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978298.1365119 (Exim 4.92)
	(envelope-from )
	id 1uCZlo-00048s-3m; Wed, 07 May 2025 08:04:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978298.1365119; Wed, 07 May 2025 08:04: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 1uCZlo-00048l-0T; Wed, 07 May 2025 08:04:48 +0000
Received: by outflank-mailman (input) for mailman id 978298;
 Wed, 07 May 2025 08:04:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCZlm-00048d-7T
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 08:04:46 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id efba24f0-2b19-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 10:04:44 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-39ee57c0b8cso5906632f8f.0
 for ; Wed, 07 May 2025 01:04:44 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099b0f16fsm16052173f8f.77.2025.05.07.01.04.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 01:04: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" 
X-Inumbo-ID: efba24f0-2b19-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746605084; x=1747209884; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=cxzprP6gkGIbezDhaJj0alDNN4WQ8wE/+kfvmmzcHkg=;
        b=OFEIVk5Ry3aZ0Wk+r2uQB9WSY/EIt42ALjkc+rA9i8aSHOM9IizW6b2RaumRCZ1xxP
         JK9YxSkQrrtCOahOuwOzye5huXdE/SCzZNz+dpAjVI9MOpZdqJGSYljVdMRFUWUgWy5c
         pluzEHuglR5FZOg2lQqobb5WPFq/HvMh3isjM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746605084; x=1747209884;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=cxzprP6gkGIbezDhaJj0alDNN4WQ8wE/+kfvmmzcHkg=;
        b=FPtjMMBvINb2BY4LleK6Dpj5SvuXa5QXz1obqYitr1nlc/DDAlmw1aylkn1DpbiLlE
         vAaVksEVxV06egQUsHSE4URMKG5UHAtc9QcTutx/DGoCUyP6doHhspLWGQkClY0+7pU3
         0rmETiXs0EMDbU0PDAj2TbCtDBOTBTRRL9YT+2J76gWLF3GtfbAzLMh965UTaOVwftH1
         rNCQ2Ynf5mobHPAy0FUsmZObJZE+OCKNg2LyS9cJvRmehfBMYKu0DiN0K7vSIEEWRQGs
         hdEDs0tg0TN1KfebnyWW0bqgPr1VyycHnzVNlp2TzTZ8XY+8Pa023sqsSDLAggCx9EIK
         nxLg==
X-Gm-Message-State: AOJu0YwRcA57jzHW9pYVuvoWof5gTBjc8EfNxeKvYoGKS1KxbTMxB0C0
	nK8MR6Fl2lfWx/SKBJVaWHh4bwjNozRAPj70EUfy8JWz2rdQ84V4kJFf2dnrTg0=
X-Gm-Gg: ASbGnctON32OIAwlmt4FQLp59g+VxtfvtlINCQqyUR4Kx7pTknq46+1qoLLkjL0MZKJ
	M2XXMG24zjzuN4NFMJ+vczGP7on0WF3eBxce8011GVb/06gQn95XXjfNjX2k8d/EjtNz1toI0mg
	0HsHSrxBRafkqSUpgig/OT5W9HeNJ/3LmKemKB1CRVXYskF9jYdf3q8SJRl9MehOpnXaK5cngF0
	DXf7dM0R7wNGYS7Z6cZEGjuRKYr9uVz+O8+JTMEjMZ6ANsLqihpnww95y5yiLxQcuGNu5YQ2oPB
	DvWCWC6NMOomA0fb1SbXqOYvMHm9xiRwbdiHbuXUF9AsxYHlSJeyl1LB
X-Google-Smtp-Source: AGHT+IGwooqK4kcOIomOvV6m2CAwLcH6DN9PvpG+QX8TLRCoYxg8mCP5nNeGs1RE9vjg6Bo4nbVX2Q==
X-Received: by 2002:a05:6000:1447:b0:39c:1f0e:95af with SMTP id ffacd0b85a97d-3a0b4997fd0mr1833768f8f.3.1746605083880;
        Wed, 07 May 2025 01:04:43 -0700 (PDT)
Date: Wed, 7 May 2025 10:04:42 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	"Huang, Ray" ,
	Andrew Cooper ,
	Anthony PERARD ,
	"Orzel, Michal" ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v3 05/11] vpci: Refactor REGISTER_VPCI_INIT
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-6-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 07, 2025 at 05:59:52AM +0000, Chen, Jiqian wrote:
> On 2025/5/6 22:37, Roger Pau Monné wrote:
> > On Mon, Apr 21, 2025 at 02:18:57PM +0800, Jiqian Chen wrote:
> >> Refactor REGISTER_VPCI_INIT to contain more capability specific
> >> information, this is benifit for follow-on changes to hide capability
> >> which initialization fails.
> >>
> >> What's more, change the definition of init_header() since it is
> >> not a capability and it is needed for all devices' PCI config space.
> >>
> >> Note:
> >> Call vpci_make_msix_hole() in the end of init_msix() since the
> >> change of sequence of init_header() and init_msix().
> >> The fini hook will be implemented in follow-on changes.
> > 
> > I would maybe add that the cleanup hook is also added in this change,
> > even if it's still unused.  Further changes will make use of it.
> Do you mean I need to add empty fini_x() function for MSI, MSIx, Rebar in this patch?
> Or just need to add this sentence to the commit message?

Oh, no, sorry if it wasn't clear, I meant just adding the sentence to
the commit message.

> > 
> >>
> >> Signed-off-by: Jiqian Chen 
> >> ---
> >> cc: "Roger Pau Monné" 
> >> cc: Andrew Cooper 
> >> cc: Anthony PERARD 
> >> cc: Michal Orzel 
> >> cc: Jan Beulich 
> >> cc: Julien Grall 
> >> cc: Stefano Stabellini 
> >> ---
> >> v2->v3 changes:
> >> * This is separated from patch "vpci: Hide capability when it fails to initialize" of v2.
> >> * Delete __maybe_unused attribute of "out" in function vpci_assign_devic().
> >> * Rename REGISTER_VPCI_EXTEND_CAP to REGISTER_VPCI_EXTENDED_CAP.
> >>
> >> v1->v2 changes:
> >> * Removed the "priorities" of initializing capabilities since it isn't used anymore.
> >> * Added new function vpci_capability_mask() and vpci_ext_capability_mask() to remove failed capability from list.
> >> * Called vpci_make_msix_hole() in the end of init_msix().
> >>
> >> Best regards,
> >> Jiqian Chen.
> >> ---
> >>  xen/drivers/vpci/header.c |  3 +--
> >>  xen/drivers/vpci/msi.c    |  2 +-
> >>  xen/drivers/vpci/msix.c   |  8 +++++--
> >>  xen/drivers/vpci/rebar.c  |  2 +-
> >>  xen/drivers/vpci/vpci.c   | 48 +++++++++++++++++++++++++++++++--------
> >>  xen/include/xen/vpci.h    | 28 ++++++++++++++++-------
> >>  xen/include/xen/xen.lds.h |  2 +-
> >>  7 files changed, 68 insertions(+), 25 deletions(-)
> >>
> >> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> >> index ee94ad8e5037..afe4bcdfcb30 100644
> >> --- a/xen/drivers/vpci/header.c
> >> +++ b/xen/drivers/vpci/header.c
> >> @@ -842,7 +842,7 @@ static int vpci_init_ext_capability_list(struct pci_dev *pdev)
> >>      return 0;
> >>  }
> >>  
> >> -static int cf_check init_header(struct pci_dev *pdev)
> >> +int vpci_init_header(struct pci_dev *pdev)
> >>  {
> >>      uint16_t cmd;
> >>      uint64_t addr, size;
> >> @@ -1038,7 +1038,6 @@ static int cf_check init_header(struct pci_dev *pdev)
> >>      pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd);
> >>      return rc;
> >>  }
> >> -REGISTER_VPCI_INIT(init_header, VPCI_PRIORITY_MIDDLE);
> >>  
> >>  /*
> >>   * Local variables:
> >> diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
> >> index 66e5a8a116be..ea7dc0c060ea 100644
> >> --- a/xen/drivers/vpci/msi.c
> >> +++ b/xen/drivers/vpci/msi.c
> >> @@ -270,7 +270,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
> >>  
> >>      return 0;
> >>  }
> >> -REGISTER_VPCI_INIT(init_msi, VPCI_PRIORITY_LOW);
> >> +REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSI, init_msi, NULL);
> >>  
> >>  void vpci_dump_msi(void)
> >>  {
> >> diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
> >> index 6bd8c55bb48e..0228ffd9fda9 100644
> >> --- a/xen/drivers/vpci/msix.c
> >> +++ b/xen/drivers/vpci/msix.c
> >> @@ -751,9 +751,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
> >>      pdev->vpci->msix = msix;
> >>      list_add(&msix->next, &d->arch.hvm.msix_tables);
> >>  
> >> -    return 0;
> >> +    spin_lock(&pdev->vpci->lock);
> >> +    rc = vpci_make_msix_hole(pdev);
> >> +    spin_unlock(&pdev->vpci->lock);
> >> +
> >> +    return rc;
> >>  }
> >> -REGISTER_VPCI_INIT(init_msix, VPCI_PRIORITY_HIGH);
> >> +REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSIX, init_msix, NULL);
> >>  
> >>  /*
> >>   * Local variables:
> >> diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
> >> index 793937449af7..026f8f7972d9 100644
> >> --- a/xen/drivers/vpci/rebar.c
> >> +++ b/xen/drivers/vpci/rebar.c
> >> @@ -118,7 +118,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
> >>  
> >>      return 0;
> >>  }
> >> -REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
> >> +REGISTER_VPCI_EXTENDED_CAP(PCI_EXT_CAP_ID_REBAR, init_rebar, NULL);
> >>  
> >>  /*
> >>   * Local variables:
> >> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> >> index 3349b98389b8..5474b66668c1 100644
> >> --- a/xen/drivers/vpci/vpci.c
> >> +++ b/xen/drivers/vpci/vpci.c
> >> @@ -36,8 +36,8 @@ struct vpci_register {
> >>  };
> >>  
> >>  #ifdef __XEN__
> >> -extern vpci_register_init_t *const __start_vpci_array[];
> >> -extern vpci_register_init_t *const __end_vpci_array[];
> >> +extern vpci_capability_t *const __start_vpci_array[];
> >> +extern vpci_capability_t *const __end_vpci_array[];
> >>  #define NUM_VPCI_INIT (__end_vpci_array - __start_vpci_array)
> >>  
> >>  #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
> >> @@ -83,6 +83,36 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
> >>  
> >>  #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
> >>  
> >> +static int vpci_init_capabilities(struct pci_dev *pdev)
> >> +{
> >> +    for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
> >> +    {
> >> +        const vpci_capability_t *capability = __start_vpci_array[i];
> >> +        const unsigned int cap = capability->id;
> >> +        const bool is_ext = capability->is_ext;
> >> +        unsigned int pos;
> >> +        int rc;
> >> +
> >> +        if ( !is_hardware_domain(pdev->domain) && is_ext )
> >> +            continue;
> >> +
> >> +        if ( !is_ext )
> >> +            pos = pci_find_cap_offset(pdev->sbdf, cap);
> >> +        else
> >> +            pos = pci_find_ext_capability(pdev->sbdf, cap);
> >> +
> >> +        if ( !pos || !capability->init )
> > 
> > Isn't it bogus to have a vpci_capability_t entry with a NULL init
> > function?
> Since I don't add fini_x() function for capabilities and also add check "if ( capability->fini )" below,
> so I add this NULL check here.
> I will remove it if you think it is unnecessary.
> Should I also remove the NULL check for fini?

I think `fini` is fine to be NULL, but I don't see a case for `init`
being NULL?

Maybe I'm missing some use-case, but I expect capabilities will always
need some kind of initialization (iow: setting up handlers) otherwise
it's just a no-op.

> >> +        if ( rc )
> >> +            return rc;
> >> +    }
> >> +
> >> +    return 0;
> >> +}
> >> +
> >>  void vpci_deassign_device(struct pci_dev *pdev)
> >>  {
> >>      unsigned int i;
> >> @@ -128,7 +158,6 @@ void vpci_deassign_device(struct pci_dev *pdev)
> >>  
> >>  int vpci_assign_device(struct pci_dev *pdev)
> >>  {
> >> -    unsigned int i;
> >>      const unsigned long *ro_map;
> >>      int rc = 0;
> >>  
> >> @@ -159,14 +188,13 @@ int vpci_assign_device(struct pci_dev *pdev)
> >>          goto out;
> >>  #endif
> >>  
> >> -    for ( i = 0; i < NUM_VPCI_INIT; i++ )
> >> -    {
> >> -        rc = __start_vpci_array[i](pdev);
> >> -        if ( rc )
> >> -            break;
> >> -    }
> >> +    rc = vpci_init_header(pdev);
> >> +    if ( rc )
> >> +        goto out;
> >> +
> >> +    rc = vpci_init_capabilities(pdev);
> >>  
> >> - out: __maybe_unused;
> >> + out:
> >>      if ( rc )
> >>          vpci_deassign_device(pdev);
> >>  
> >> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
> >> index 9d47b8c1a50e..8e815b418b7d 100644
> >> --- a/xen/include/xen/vpci.h
> >> +++ b/xen/include/xen/vpci.h
> >> @@ -13,11 +13,12 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev, unsigned int reg,
> >>  typedef void vpci_write_t(const struct pci_dev *pdev, unsigned int reg,
> >>                            uint32_t val, void *data);
> >>  
> >> -typedef int vpci_register_init_t(struct pci_dev *dev);
> >> -
> >> -#define VPCI_PRIORITY_HIGH      "1"
> >> -#define VPCI_PRIORITY_MIDDLE    "5"
> >> -#define VPCI_PRIORITY_LOW       "9"
> >> +typedef struct {
> >> +    unsigned int id;
> >> +    bool is_ext;
> >> +    int (*init)(struct pci_dev *pdev);
> >> +    void (*fini)(struct pci_dev *pdev);
> >> +} vpci_capability_t;
> >>  
> >>  #define VPCI_ECAM_BDF(addr)     (((addr) & 0x0ffff000) >> 12)
> >>  
> >> @@ -29,9 +30,20 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
> >>   */
> >>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
> >>  
> >> -#define REGISTER_VPCI_INIT(x, p)                \
> >> -  static vpci_register_init_t *const x##_entry  \
> >> -               __used_section(".data.vpci." p) = (x)
> >> +#define REGISTER_VPCI_CAP(cap, x, y, ext) \
> > 
> > x and y are not very helpful identifier names, better use some more
> > descriptive naming, init and fini?  Same below.
> init and fini seems not good. They are conflict with the hook name of below vpci_capability_t.
> Maybe init_func and fini_func ?

Oh, I see.  Can I recommend to name fields init and destroy or cleanup
(instead of fini), and then use finit and fdestroy/fclean as macro
parameters?

I don't think it's common in Xen to name cleanup functions 'fini'.  I
understand this is a question of taste, it's mostly for coherence with
the rest of the code base.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 07 08:07:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 08:07:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978308.1365128 (Exim 4.92)
	(envelope-from )
	id 1uCZoF-0004gz-F6; Wed, 07 May 2025 08:07:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978308.1365128; Wed, 07 May 2025 08:07: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 1uCZoF-0004gs-Cb; Wed, 07 May 2025 08:07:19 +0000
Received: by outflank-mailman (input) for mailman id 978308;
 Wed, 07 May 2025 08:07:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCZoE-0004gh-2I
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 08:07:18 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4ab4f4d9-2b1a-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 10:07:17 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a0af41faa5so797835f8f.2
 for ; Wed, 07 May 2025 01:07:17 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099b0f09dsm16235239f8f.63.2025.05.07.01.07.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 01:07: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" 
X-Inumbo-ID: 4ab4f4d9-2b1a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746605237; x=1747210037; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=r0LTDaA3ljtlXW+nKR4kuaHTdtxYzvsEP3eLi6r9UJE=;
        b=bRYNNqW0z3Am3+rjSzbvsm9A0eS1hrzUjwhHHFwWmoYi30pJqOrkT/pBs4nYhj1G04
         A6VB9nqff/CVuzgcXveAWYS2F3AA5LjGRn5TsFGsmRu2gvMKawmJ5kIeoUmP6S8wDbcn
         wupcNCniJdX7KNNkBxjq1B+PAD5MQJ+xuOe+4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746605237; x=1747210037;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=r0LTDaA3ljtlXW+nKR4kuaHTdtxYzvsEP3eLi6r9UJE=;
        b=rDj9+7ZNcenEUmn1zTdFLHphc6aLOrCTWn7eaM6gakA+m6/PPoDNvGlHMAaA3X/Ufv
         pF3C0nxYieQ1bO42K8ptZAbnQrZukNGXJVtndVPn2n/JC4/SqMIT2uEjDc3iAkDi21dc
         DCc77qOB0D7ia28Xmrw4Mryhsxgpf08CBzYmy+AHCk1OOSt4fKoMGPK1z5UHlNxaKmqF
         fN605oJWq7z1ZqdBwrnHgiNRu1M18kbyx1XRyePrZzYPNrxRDgXrKMJvrQP7JuAR2fFL
         5iwzxXdVJ//UGf5tyQaX0B/qR5owrKsBjccu1FKB8ZzIA8yhCq4Q9hwutVaq6EQbymTX
         ZFGg==
X-Gm-Message-State: AOJu0YzPN+1Lvmp9De2sm660604tFj1j7jar7/jS7/V6Cjs03MGSc93o
	ZDXJsyxzLG4NDGfASZRPe4JMrY6RcvKvr6LepjTarDw1N3mlQAg0U8v2X76OfnSGccFbCo96RiZ
	O
X-Gm-Gg: ASbGncvGjVQ2Q/PNsla3A35n+XV30I5QmQ1as7hwx3YyRVB3U4hxQFaBpNh4J3MPSsb
	5lzJoQCV43/INpbDipfmlRGJNJYmCzVGOfjFJ2wG40PjamK81TaHd2U38pqP7kEzi7eqhMglP3W
	o+wmpw//ifQ/yUhw/oycFf6Ne9rHDV/Opu+CBNUo+I+5eoPpqOavgtc5vlLATyjSO4+L4YgSFbN
	rDDh106fzWa2Ta0q4CzzvuadhqfSKO18ceZCPIN7O4NXDoCbxrhGLYAddGOgyT/Ervhm40CQIwn
	s0yWIuQ7FY6p7rEn7Zgs4GeWjOasJTlwFnCwzzsUHTUNUA==
X-Google-Smtp-Source: AGHT+IHPfTnHxnDNqcSmJiTJpz1NyZfKz+SEnAHHkUv77kysGNB+h071CopvpjHWL7HDUBRvyd7kaQ==
X-Received: by 2002:a05:6000:220e:b0:3a0:7a8f:db22 with SMTP id ffacd0b85a97d-3a0b4a2368emr1845285f8f.24.1746605236583;
        Wed, 07 May 2025 01:07:16 -0700 (PDT)
Date: Wed, 7 May 2025 10:07:15 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v3 06/11] vpci: Hide legacy capability when it fails to
 initialize
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-7-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 07, 2025 at 06:38:45AM +0000, Chen, Jiqian wrote:
> On 2025/5/7 00:00, Roger Pau Monné wrote:
> > On Mon, Apr 21, 2025 at 02:18:58PM +0800, Jiqian Chen wrote:
> >> +    }
> >> +
> >> +    /* PCI_CAP_LIST_NEXT register of target capability */
> >> +    list_del(&next_r->node);
> >> +    spin_unlock(&vpci->lock);
> >> +    xfree(next_r);
> > 
> > Here vpci_remove_register() could also be used, but it will involve
> > searching again for the register to remove, which is a bit pointless.
> Yes, so just keeping things here instead of calling vpci_remove_register()?

I would add a small comment that we avoid calling
vpci_remove_register() to not have to redo the register search.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 07 08:09:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 08:09:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978319.1365139 (Exim 4.92)
	(envelope-from )
	id 1uCZq4-0005Dp-RI; Wed, 07 May 2025 08:09:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978319.1365139; Wed, 07 May 2025 08:09: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 1uCZq4-0005Di-Of; Wed, 07 May 2025 08:09:12 +0000
Received: by outflank-mailman (input) for mailman id 978319;
 Wed, 07 May 2025 08:09:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCZq3-0005Dc-4y
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 08:09:11 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8d130a8d-2b1a-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 10:09:09 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3912d2c89ecso5303232f8f.2
 for ; Wed, 07 May 2025 01:09:08 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a0b25159c9sm3557976f8f.50.2025.05.07.01.09.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 01:09:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8d130a8d-2b1a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746605348; x=1747210148; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=mr9cHPpBeOVrRjWEx9eh5wDObTB+wWqTvL3lB1Z2C2Q=;
        b=ERNLRr+xjt2cFrspjclYDE5Y/2RQbx5ohUfJKU/RX3hZrYw26vCInrmmzpx7aqhlDn
         jNBxuBYVxL28Ef5WkA6Q44fEeLJ5aAnBhkd+VuxoWXO3F3X+HG29zZtH/s3Lae6C+0f1
         XB6z07Wd95qQobnMmnYK04LXDmpbgDiINJDsE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746605348; x=1747210148;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=mr9cHPpBeOVrRjWEx9eh5wDObTB+wWqTvL3lB1Z2C2Q=;
        b=FpHB2fXofAUnI1i4QnqEkyChgohK9mHSv4tnr/MU1mLBnXqMnkwz3MdTWze1VloMas
         SFh6llbwaQSgYafJDKbidtw20qP04Hu02zMwAxCGjKipE6Kmwu/x3Yfd3FfYRgS9hArN
         d0zEq+SRdBYL7gJZQWO9b7i+MfUESc4GrTSLSP7c3YMu29F2KjoIzUh7irMizBWaVeF7
         BZutYVb7WzO7T0Y+TRTWvVF8HtrhFNFBqkKThHb4biCYWnZZmcQ4SlRbCORHYN9Eb8zG
         0Tf6byN3bHPZaBV4ljHCE7vfNfxaYiwB+gO2YlByujZSJnL1Lp1ern7fPWRs2kmfRDqV
         lI9g==
X-Gm-Message-State: AOJu0YwtrQP8J7+rGRyG6qpJrY6wmQcIdx3/PWuLCR+hzXlZHkRy0lq0
	+i8NjB8o3Mvu1N63jfOzqmEG7N5XaBhkMO5rHogVsW5Ml6p/1RB+rz9UY/lcXyQ=
X-Gm-Gg: ASbGncu6wjinVthBc48a76nEHmzSktJGvZhJG1lldfo15zks5EhjhWAE/EPnhlv1I6x
	InCDmftLg2/9hyGMyrjZZCMrDihN5RpxJa+8jxXBdmdvUq07dqb2AA68J+6u2wegAIVjwn91i5h
	qTaUCCGl+gbRd/yI6ovIMe3FjooTV17pvgSIlqctL5sGCy2frBcnl85v/weTJ9mAeGvUcb8qaBn
	FB+LQe/SWae+nQO44btdSqxGYK6y/hnj8oCx5GBKYqqDoYtUjewgXLeoftyvIo5VP6hGMuF0p/M
	Fhzkb5EvXnzccjWV3wJ8eIOwca2ZECiVBxGmoWKtUuP1yQ==
X-Google-Smtp-Source: AGHT+IGNHjWo9lPh2tqYGivfR+Mw/nKyQz4tam4WzmDq+jhhwO7bOV65qrdqsGGqUbld0QcVIztBag==
X-Received: by 2002:a05:6000:144d:b0:39e:cc5e:147 with SMTP id ffacd0b85a97d-3a0b4a102edmr2037574f8f.55.1746605348031;
        Wed, 07 May 2025 01:09:08 -0700 (PDT)
Date: Wed, 7 May 2025 10:09:07 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v3 07/11] vpci: Hide extended capability when it fails to
 initialize
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-8-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 07, 2025 at 07:26:21AM +0000, Chen, Jiqian wrote:
> On 2025/5/7 00:21, Roger Pau Monné wrote:
> > On Mon, Apr 21, 2025 at 02:18:59PM +0800, Jiqian Chen wrote:
> >> When vpci fails to initialize a extended capability of device for dom0,
> >> it just return error instead of catching and processing exception. That
> >> makes the entire device unusable.
> >>
> >> So, add new a function to hide extended capability when initialization
> >> fails. And remove the failed extended capability handler from vpci
> >> extended capability list.
> >>
> >> Signed-off-by: Jiqian Chen 
> >> ---
> >> cc: "Roger Pau Monné" 
> >> ---
> >> v2->v3 changes:
> >> * Separated from the last version patch "vpci: Hide capability when it fails to initialize".
> >> * Whole implementation changed because last version is wrong.
> >>   This version gets target handler and previous handler from vpci->handlers, then remove the target.
> >> * Note: a case in function vpci_ext_capability_mask() needs to be discussed,
> >>   because it may change the offset of next capability when the offset of target
> >>   capability is 0x100U(the first extended capability), my implementation is just to
> >>   ignore and let hardware to handle the target capability.
> >>
> >> v1->v2 changes:
> >> * Removed the "priorities" of initializing capabilities since it isn't used anymore.
> >> * Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
> >>   remove failed capability from list.
> >> * Called vpci_make_msix_hole() in the end of init_msix().
> >>
> >> Best regards,
> >> Jiqian Chen.
> >> ---
> >>  xen/drivers/vpci/vpci.c    | 79 ++++++++++++++++++++++++++++++++++++++
> >>  xen/include/xen/pci_regs.h |  1 +
> >>  2 files changed, 80 insertions(+)
> >>
> >> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> >> index f97c7cc460a0..8ff5169bdd18 100644
> >> --- a/xen/drivers/vpci/vpci.c
> >> +++ b/xen/drivers/vpci/vpci.c
> >> @@ -183,6 +183,83 @@ static void vpci_capability_mask(struct pci_dev *pdev,
> >>      xfree(next_r);
> >>  }
> >>  
> >> +static struct vpci_register *vpci_get_previous_ext_cap_register
> >> +                (struct vpci *vpci, const unsigned int offset)
> >> +{
> >> +    uint32_t header;
> >> +    unsigned int pos = PCI_CFG_SPACE_SIZE;
> >> +    struct vpci_register *r;
> >> +
> >> +    if ( offset <= PCI_CFG_SPACE_SIZE )
> >> +        return NULL;
> >> +
> >> +    r = vpci_get_register(vpci, pos, 4);
> >> +    ASSERT(r);
> >> +
> >> +    header = (uint32_t)(uintptr_t)r->private;
> >> +    pos = PCI_EXT_CAP_NEXT(header);
> >> +    while ( pos > PCI_CFG_SPACE_SIZE && pos != offset )
> >> +    {
> >> +        r = vpci_get_register(vpci, pos, 4);
> >> +        ASSERT(r);
> >> +        header = (uint32_t)(uintptr_t)r->private;
> >> +        pos = PCI_EXT_CAP_NEXT(header);
> >> +    }
> >> +
> >> +    if ( pos <= PCI_CFG_SPACE_SIZE )
> >> +        return NULL;
> >> +
> >> +    return r;
> >> +}
> >> +
> >> +static void vpci_ext_capability_mask(struct pci_dev *pdev,
> >> +                                     const unsigned int cap)
> >> +{
> >> +    const unsigned int offset = pci_find_ext_capability(pdev->sbdf, cap);
> >> +    struct vpci_register *rm, *prev_r;
> >> +    struct vpci *vpci = pdev->vpci;
> >> +    uint32_t header, pre_header;
> > 
> > Maybe sanity check that offset is correct?
> What do you mean sanity check?
> Do I need to add something?

I would probably do something like:

if ( !offset )
{
    ASSERT_UNREACHABLE();
    return;
}

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 07 08:14:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 08:14:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978335.1365149 (Exim 4.92)
	(envelope-from )
	id 1uCZum-0007CH-FN; Wed, 07 May 2025 08:14:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978335.1365149; Wed, 07 May 2025 08: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 1uCZum-0007CA-Ca; Wed, 07 May 2025 08:14:04 +0000
Received: by outflank-mailman (input) for mailman id 978335;
 Wed, 07 May 2025 08:14:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCZul-0007C4-Ak
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 08:14:03 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2405::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3b1b074a-2b1b-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 10:14:01 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by CYYPR12MB8653.namprd12.prod.outlook.com (2603:10b6:930:c5::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Wed, 7 May
 2025 08:13:54 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8699.012; Wed, 7 May 2025
 08:13: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" 
X-Inumbo-ID: 3b1b074a-2b1b-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Rzvn+A2CIHyRhu0BZzY52viEjBX3Zf9cye4+wz9AmUvSKoNOURZvS2k62nehqYIGo0eEiNExbZks87zVflSsziRzrZk+FdShvyoIowNJJie1qJvuS51SCr8y2BGlIoEM/NVF2vRY7+bl5nyw0t5G9lhk92LiZhsP0ycAYvun47JVmcJgjNe9m+GtTCmnfhu1lC9OMYHoMVidVeVxo2VERLv4Gyrg5kLmTVP8wh7N/EtiQKZ7LtVJE0ZJETtxaaSfpzSBziMNhclmva+moQVRlmmaawy31SnVcYU+kStWx+cHU/hr+d2CfCDPocm44y636UayuQM3n70HFNVztwwekg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jrBokqMYpA3NvfilMAsyyTgelG4EMTE+Eff8kRUArF4=;
 b=obUD1R69KRsQLmLyyXjUhYtZ9EM1TAkR9f8AQgnFQmF/LvWOSf1gTSMQDB6AsNCa/MdlqpyVt9nV8104VpBv8vCa3LvuC09NTP07GEYdwDOyBzmIwUw7jh5HfJsBuwqTy7c9qPfInhZ5S2IpvBDMeWqMqd/vHtw8kO7EbCpjNE98mPUI2zEpKiQvZqr9gaL4lA5cS5R+qizT2JlsOEiCnTNLUeUvQWOFY9ZoITEvuj52NbzM6FcMYEBjoeXb5hvg1lQkno1AM/oKEj3pbPa5+8Qt0xY7B6o7ZlP5MnA1zclUEBr89WDyy3JWBP1f9cQnAv+KkbJYuCH1CDHCdCLQqw==
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=jrBokqMYpA3NvfilMAsyyTgelG4EMTE+Eff8kRUArF4=;
 b=wY6vhwvM7FcJXXoVoKPZ4jGpD4ksIs6WxYe5zAOdUcNdCgi2cX/SyskIMJgFWMAzwesSKtiakxsDxJIvFSi7lt1ke5o/0G2DpFmZ2ZJ9+R/k38fI6+MOe11rD3V6M0y39BTuksHOJ8vhnY0Nyiy2sYGn3Fl4qLC+vb+Qvdf6Ugw=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v3 03/11] vpci/header: Emulate legacy capability list for
 dom0
Thread-Topic: [PATCH v3 03/11] vpci/header: Emulate legacy capability list for
 dom0
Thread-Index: AQHbsoVY0As/JNC0IkWc2g8aH+9wh7PFtqAAgAFbx4D//9G3gIAAjICA
Date: Wed, 7 May 2025 08:13:54 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-4-Jiqian.Chen@amd.com> 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8699.005)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|CYYPR12MB8653:EE_
x-ms-office365-filtering-correlation-id: 540c147b-b72e-459a-ca80-08dd8d3f1bb9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?RnQvMHBHbmF1d0FYbCtYRUlWUXFYSURyeFNCZUxpV0tqWVNhS3FlUjJmSlgy?=
 =?utf-8?B?WllUK0V5bEx1cjAxbWFWK290WGxQUEUzTStZUHFtWlZFZloxa1pjQmdEZk5F?=
 =?utf-8?B?ZTRzRk9rVHFyVDUrS1pVQVVxNXpheHJkL3M3ZnMzcGZuWCsrcGRDM1JjL2ww?=
 =?utf-8?B?YVNkSStsSU5VRUw0cVFyTzJWQVBUZzJOa0VMckNOWmNSeEhXQWk4bEJQZ01X?=
 =?utf-8?B?K0lmMVNFV3ZITklRY21MdnZ5SXpwMHI2UmFWaEZPMGV2ZHN4MWc5czFUTVdL?=
 =?utf-8?B?YU5hT01FaVdCSWdpMjRFRG5mazZicVFoOFFKcUNIaHlSQUU4cmtzQ2s3L0x0?=
 =?utf-8?B?RHhtbndBL3I2MlpialpXTWRqUVF6SExNNlFaamVkSllnNGg3RG41UUdPSFJR?=
 =?utf-8?B?ZlBIUGcwbnNQOFgram5WMFFkSm90VmZNNU5Rd0JPUGdvYXo5RG51QTZaLzFJ?=
 =?utf-8?B?VmpsemQ4RFhyTGxIRVN0V2N4Z1grV2hrZ0M5My84UExRcXNiT1hCMGZTeW54?=
 =?utf-8?B?SW1SYnUzaHlLL1ludldmTlR0MlkzRjkxK1F4U2crM3FrL0ZvUG1Ia1NsRnk4?=
 =?utf-8?B?bFFieGJKclJhV3JhUTlUbkIzWXo3U3ZDaENMSUVkTll0RWxnYlhJVlMvSnJq?=
 =?utf-8?B?L0VOMzRsVmZKQUlyNDdEUlZ6SS93dzYxdmRwNlVGV0RrSSt5YkNya3FXYjJH?=
 =?utf-8?B?OVhzUlpoRW9UVXlBd0c3MG1RZlhMSW1UK2hiQUpraXQ0UTF0ZlcvQjdlYUR4?=
 =?utf-8?B?MHZyMGFya2xhY2pmOFFBS0tWeGxZMmlyemFMbXE4TDFEOW56cjFycTQ4RzN1?=
 =?utf-8?B?enQzZVkxa0J5bnh4Ty8zU3lNVS95bWhBSlFIUXppZkZHYmRHRmJlVGRhRjhv?=
 =?utf-8?B?azJlZTVDMThRaHQ5a1ZjWFQxN0gwSW5zQTFyUWp6WjdSM0h2R0tqTzZSaStU?=
 =?utf-8?B?RkN6MGhBSWZWMHNLbnlzaXlKYllEWkhicjNiSmttaTEydmxoZkluWlFaVzF1?=
 =?utf-8?B?aGlEVEFReGFZbGZUMnNTTDVLVmczRlIvbjl1SWltSW1tM080UkZFWnNraVNG?=
 =?utf-8?B?cGxnYTBrOS92UnFhOTZhbE9mb1RROS84OEFONThyU29EdkVvdHFiQXR1TFB3?=
 =?utf-8?B?eXljSytzQWlqcGJpZUJxYzNrV0NUN3M2aElhcnJpeC9oYVRyZEVnNnlVZVRV?=
 =?utf-8?B?VnB3U2o2OG9VK0x3MFhxOXZDNFNnSDRYTWZFVHN5ZmQ2MVlWVGFBdnBBT1dl?=
 =?utf-8?B?ZytzZ051OGtpRHdod1ZoZjlHWGtnWUk0ZjNqM1ozOCtvY3RaUXpKQy9qRDBt?=
 =?utf-8?B?UU42ZjZjTnpxbEp4dkFSeHVEeXdoa1NiNDFTSnZ1ZHloOGFBVFJpTHN0Mlda?=
 =?utf-8?B?TlZOdThBemNUSzNPUnBHUXlrVnRrbE1XU3VtaHVLZFpKY2dBeDVpa3ZrQUlU?=
 =?utf-8?B?OG4xcjEzNFJ6NHgzOHZpWWNDU3UxSTA0eWh2QzRiSE9ReWpZSmRKOUR5OUk5?=
 =?utf-8?B?R2JrWEJDNUYvbm56cDJHNTM3bzBheURGSHdMd2x2bjYyb3pZSTRDNkNjU3JN?=
 =?utf-8?B?Y1lvMEF6RzFuOS9qZzBxYjJaTkh2YU9TN092MThnWDJDZXk3U0VaRFB1RnNY?=
 =?utf-8?B?WU1jNTYvUkhZS25zcVJSTU5EcmxYTEZGdHpPVldodmk2dzhPQ2ZZbnBTZUNi?=
 =?utf-8?B?MWVBVFJsRVpYbmVsTHZWYXFDejdwUlZNbEUvY3k1YXd5ajFrQkpla1lFNXU1?=
 =?utf-8?B?WXNxY01XclhDNnNZSlJxc3NBc2FWVzMwMjVMejhiRWxZWTA3V0FERTdWTjE3?=
 =?utf-8?B?MHFKem9haEZ3akpRTDI4VWx2MVJ4SGt2Y2NNaGwzVzQ5VXFiWkwrRi83bThO?=
 =?utf-8?B?aVM3cjNzTC9WVkIvQ2RaS3psMThack9oa2NRZU5uNTZUeFRzN3RHVWxmTkI4?=
 =?utf-8?B?MUYwbTJCM1hnU1hLckRUbkViUjVvaTRJbWxZOTlzTGtGUlNEUndyanJ3ZFdM?=
 =?utf-8?Q?HxFCPT9LgRcIW+sDy5cd0g4ysDTWmY=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Z0VzSXlGVThheDR3UEg1ZzJsRnEyRXhSV0xUaU9iYlJxd2xqbXZ5ZDdZN3Fa?=
 =?utf-8?B?VHk0OGV6bnhiM1ZCY0srODlReDI4aStpYklHUVJmQXU2cFdDdXdGUDJJYzZu?=
 =?utf-8?B?dm83UVpnOGg2MFFaYlFXN2tscTJIemdqRzFpTzRCY29ZS1k1TWJnOEF5bE1w?=
 =?utf-8?B?bTFGaHJKUTVRZVdoUUEvUHMvdTUvTnZNUXEyVjVTajhsQi9qQWpKN0QxUlg4?=
 =?utf-8?B?NXlLMURjMXMrd216RDlYU0JhMkJZWGZjckN1MkRCY2kxdUVEZ3VQVklNd29M?=
 =?utf-8?B?bm15bUdBR2NQOWNCUkRPU1FTK2pKSU10MHVTazhQNytuSkJ3cDh3Nzh3bldW?=
 =?utf-8?B?RTZGZnl1R2ZHU2UxMjVUcTA2RWQ2djJQeUZCTDN3RFR3akJJektXQk5SYkNU?=
 =?utf-8?B?eWx3Mko4WEptN05UcXNnZmZsM1lpOUhrT0pJVFJtUmIrM2pXOGFWZVROeEJH?=
 =?utf-8?B?dGRDbE5sQSsydXJ0VUVtdExIQTlHQmZlWmdlZ2JGUjlINzNVaDhHb1FaYnlT?=
 =?utf-8?B?TGZGaHdQcWFFYUtTSFMrRjVhZ2RaN25mQmNWeDJIUkl5ZU1ia1E4UlR6Vkg1?=
 =?utf-8?B?RmY1bG50YzMydms5SkdJbEl3bmt2bTh2OUQ1aVZsQlRTTEo3Y296VmJSends?=
 =?utf-8?B?L2piVlRySU0xOExEenVFcDdzMVUvbGVlcFllQ1E5UGJ6R2RIVDkrVGxBL3Ro?=
 =?utf-8?B?R0VEbldNRkwzZXUwMGVBVW9IbndFUUxQYWxOVkw1RDdrWjBVaWVYUEVLN1Ur?=
 =?utf-8?B?YXcvS2VVM3ZWdU9DeCtZbjltTkVQczV5Q01ySlZjbWswRDNIL1JEcGNiMlo0?=
 =?utf-8?B?MDM1VDJGTkpWeVh6akJlMFo2UGtjT20zZFFKZTB4cGkwUU43SU83eUFVdSt1?=
 =?utf-8?B?RXZGWlhhSnpjY3o5M2IrV0tlMS9sWnRLOU1vYWlOSCtuaEV1ZGJMdENmTy8r?=
 =?utf-8?B?VWtSMnN5RkwvTjJ1SEtTZVhvTlN2aUtqNE5WaVZhQ2hwbysvWm5sRncwUjJr?=
 =?utf-8?B?Y091Skt4UUNFNk5tS21MVHJBcnhHT3BnN1FzRFMwSTRZYk9hSkprclRFTmxp?=
 =?utf-8?B?dHhxWmN6RmIxakRCekpIZTJxWVVwZXNLNHY4NUNYZ05vcUFnMVgxMzVob0s0?=
 =?utf-8?B?SSszU3Z1NEd1Z2pUaU9vcDZRcC9EWDVQbWJIenVtL1lDdHB3ZTQwVGhTb2NM?=
 =?utf-8?B?NTZWZnpIRGxVVnVQOGh1c3YyempudUROWTJPaExsRmRuaGJaZDBwOWpRV1lW?=
 =?utf-8?B?YzdXc0NLWGtxYlhsNHFkOFB4STZYSm5OR01CN1hmZDZHMUQ5R0prRkkyMWJw?=
 =?utf-8?B?L3JLOFcrZTRDcDVjZDQ0OVI4UnNzc2VIeUR2b1BKNFUrbDFsenBUdFQxdXJL?=
 =?utf-8?B?NkRnQjVnQjRhNTdQcnMvTjJacHRVTjdqREtlQ3d3MkV6Y1U1eFU1Q3d5TitK?=
 =?utf-8?B?R2VtTnh6WGo4ZHYvRk1EUWVVZ251ZVY3TGg1ZzlDamtTMDdZVHVRY0N4ODVP?=
 =?utf-8?B?MVFDbHZLdUdkZkR6aVZDMkI0elRKa0hBTDYxRWFUa0IwckhZTWQ0d1ZZbXkx?=
 =?utf-8?B?ZjdaSmpVc0o1Z3ZjMHk2RkExWTdVYUtMK2d1V0dpaVl4d01SZ1pjSURjWE8w?=
 =?utf-8?B?d2p2OU9HMzEycW1YL3JVczN3a1pPajNwT0lQVEtqcE5teFVRNEZ1blBDOUtY?=
 =?utf-8?B?MW50SUF1d2ltMkhyZ0xrT2k1djltSVJHZndJTlhvalYyTFAzQWhaaUxtTEh1?=
 =?utf-8?B?SDFFOStIb3pPRXF3RFlIZXkvRUVkKzV6dGhOT3VrMlgvYkhsNms2d1lLR3kw?=
 =?utf-8?B?d3BVa3dmOTl0NzhsZGd0RWZqSkJjR201MFZNSEFHc013MjEySFlIejFCWnNZ?=
 =?utf-8?B?V0N5My9VV29GZVkvU1FFaDZHb25JY0Q4MHZCU1hSd095c3RyZm5yc2dIL2ZZ?=
 =?utf-8?B?VmxzellMQjB1R0hGMzYxRDdrKzBWVDVoc0RJZjJBZTJuakdPeHJEWUMvaHdX?=
 =?utf-8?B?aWw2T0NmZ2tFQ0ovZXh4UHBsL1R0NE5yWHlGR2tMeHZzN3pIbXZSajJEM1ln?=
 =?utf-8?B?R3Y0Q3RkOW5lUFljbEhjaVA3eTcrTCt0bno5Z1p3RzFYN1luc0g0bTcvM3Yw?=
 =?utf-8?Q?HpU4=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 540c147b-b72e-459a-ca80-08dd8d3f1bb9
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 08:13:54.3637
 (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: zc8fJHSG3WjbdI5h9cbZj2m3U4FGNNBA1xlMryNuH+JREiUc9vu3GsLRvdOgRHE8zjZFqfDDOhFJuidoGYemZQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8653

T24gMjAyNS81LzcgMTU6NDksIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIFdlZCwgTWF5
IDA3LCAyMDI1IGF0IDAyOjQ2OjUyQU0gKzAwMDAsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+IE9u
IDIwMjUvNS82IDIxOjUwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPj4+IE9uIE1vbiwgQXBy
IDIxLCAyMDI1IGF0IDAyOjE4OjU1UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4+PiBD
dXJyZW50IGxvZ2ljIG9mIGVtdWxhdGluZyBsZWdhY3kgY2FwYWJpbGl0eSBsaXN0IGlzIG9ubHkg
Zm9yIGRvbVUuDQo+Pj4+IFNvLCBleHBhbmQgaXQgdG8gZW11bGF0ZSBmb3IgZG9tMCB0b28uIFRo
ZW4gaXQgd2lsbCBiZSBlYXN5IHRvIGhpZGUNCj4+Pj4gYSBjYXBhYmlsaXR5IHdob3NlIGluaXRp
YWxpemF0aW9uIGZhaWxzIGluIGEgZnVuY3Rpb24uDQo+Pj4+DQo+Pj4+IFNpZ25lZC1vZmYtYnk6
IEppcWlhbiBDaGVuIDxKaXFpYW4uQ2hlbkBhbWQuY29tPg0KPj4+DQo+Pj4gU29ycnksIG9uZSBu
aXQgSSd2ZSBub3RpY2VkIHdoaWxlIGxvb2tpbmcgYXQgdGhlIG5leHQgcGF0Y2guDQo+Pj4NCj4+
Pj4gQEAgLTc4NiwxMyArNzg3LDE1IEBAIHN0YXRpYyBpbnQgdnBjaV9pbml0X2NhcGFiaWxpdHlf
bGlzdChzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+Pj4gIA0KPj4+PiAgICAgICAgICAgICAgbmV4
dCA9IHBjaV9maW5kX25leHRfY2FwX3R0bChwZGV2LT5zYmRmLA0KPj4+PiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwb3MgKyBQQ0lfQ0FQX0xJU1RfTkVYVCwNCj4+
Pj4gLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkX2Nh
cHMsDQo+Pj4+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFSUkFZ
X1NJWkUoc3VwcG9ydGVkX2NhcHMpLCAmdHRsKTsNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgY2FwcywgbiwgJnR0bCk7DQo+Pj4+ICANCj4+Pj4gLSAgICAg
ICAgICAgIHJjID0gdnBjaV9hZGRfcmVnaXN0ZXIocGRldi0+dnBjaSwgdnBjaV9od19yZWFkOCwg
TlVMTCwNCj4+IFRoZSBzYW1lIGhlcmUsIE5VTEwgLT4gdnBjaV9od193cml0ZTgsIEkgdGhpbmsu
DQo+IA0KPiBObywgbm90IGhlcmUsIHNpbmNlIHRoZSBQQ0lfQ0FQX0xJU1RfSUQgaGFuZGxlciBp
cyBvbmx5IGFkZGVkIGZvcg0KPiBub24taGFyZHdhcmUgZG9tYWlucywgYW5kIGluIHRoYXQgY2Fz
ZSB3ZSBkbyB3YW50IHRvIGlnbm9yZSB3cml0ZXMgdG8NCj4gdGhlIHJlZ2lzdGVyLg0KT2gsIEkg
d3JpdGUgdGhlIHdyb25nIHBsYWNlLiBJIG1lYW4gdGhlIGNvZGVzIHRvIGFkZCBoYW5kbGVyIGZv
ciBQQ0lfQ0FQQUJJTElUWV9MSVNUIHdoZW4gaGFyZHdhcmUgZG9tYWluLg0KDQo+IA0KPj4+PiAt
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwb3MgKyBQQ0lfQ0FQX0xJU1RfSUQs
IDEsIE5VTEwpOw0KPj4+PiAtICAgICAgICAgICAgaWYgKCByYyApDQo+Pj4+IC0gICAgICAgICAg
ICAgICAgcmV0dXJuIHJjOw0KPj4+PiArICAgICAgICAgICAgaWYgKCAhaXNfaHdkb20gKQ0KPj4+
PiArICAgICAgICAgICAgew0KPj4+PiArICAgICAgICAgICAgICAgIHJjID0gdnBjaV9hZGRfcmVn
aXN0ZXIocGRldi0+dnBjaSwgdnBjaV9od19yZWFkOCwgTlVMTCwNCj4+Pj4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvcyArIFBDSV9DQVBfTElTVF9JRCwgMSwgTlVM
TCk7DQo+Pj4+ICsgICAgICAgICAgICAgICAgaWYgKCByYyApDQo+Pj4+ICsgICAgICAgICAgICAg
ICAgICAgIHJldHVybiByYzsNCj4+Pj4gKyAgICAgICAgICAgIH0NCj4+Pj4gIA0KPj4+PiAgICAg
ICAgICAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2cGNpX3JlYWRfdmFs
LCBOVUxMLA0KPj4+DQo+Pj4gRm9yIHRoZSBoYXJkd2FyZSBkb21haW4gdGhlIHdyaXRlIGhhbmRs
ZXIgc2hvdWxkIGJlIHZwY2lfaHdfd3JpdGU4DQo+Pj4gaW5zdGVhZCBvZiBOVUxMLg0KPj4gT0ss
IEkgdGhpbmsgSSBuZWVkIHRvIGFkZCBkZWZpbml0aW9uIG9mIHZwY2lfaHdfd3JpdGU4Lg0KPj4g
QnV0IEkgaGF2ZSBhIHF1ZXN0aW9uLCBpZiBoYXJkd2FyZSBkb21haW4gd3JpdGUgdGhpcyByZWdp
c3RlciB0aHJvdWdoIHZwY2lfaHdfd3JpdGU4LA0KPj4gdGhlbiB0aGUgIm5leHQgYWRkcmVzcyBk
YXRhIiBvZiBoYXJkd2FyZSB3aWxsIGJlIGluIGNvbnNpc3RlbnQgd2l0aCB2cGNpLg0KPj4gSXMg
aXQgZmluZT8gT3Igc2hvdWxkIEkgdXBkYXRlIHZwY2kncyBjYWNoZT8NCj4gDQo+IEFjY29yZGlu
ZyB0byB0aGUgc3BlYyB0aGlzIGZpZWxkIGlzIHJlYWQtb25seSwgc28gd3JpdGVzIHNob3VsZCBi
ZQ0KPiBpZ25vcmVkLiAgV2UgYWxsb3cgaGFyZHdhcmUgZG9tYWluIGZ1bGwgYWNjZXNzIGJlY2F1
c2UgZm9yIGhhcmR3YXJlDQo+IGRvbWFpbiB3ZSBhaW0gdG8gdHJhcCBhcyBsaXR0bGUgYXMgcG9z
c2libGUgdG8gbm90IGRpdmVyZ2UgYmVoYXZpb3INCj4gZnJvbSBuYXRpdmUsIGFuZCB0byBhbGxv
dyBwb3NzaWJsZSBkZXZpY2UgcXVpcmtzIHRvIHdvcmsuDQo+IA0KPiBJdCBjb3VsZCBiZSBjb25j
ZWl2YWJsZSB0aGF0IHNvbWUgdmVuZG9yIGhhcyBhIGhpZGRlbiBzcGVjaWZpYw0KPiBmdW5jdGlv
bmFsaXR5IHRoYXQgc29tZWhvdyB0cmlnZ2VyZWQgYnkgYSB3cml0ZSB0byB0aGlzIGZpZWxkLg0K
R290IGl0Lg0KDQo+IA0KPiBSZWdhcmRzLCBSb2dlci4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpK
aXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Wed May 07 08:23:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 08:23:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978346.1365158 (Exim 4.92)
	(envelope-from )
	id 1uCa4B-0000jn-8a; Wed, 07 May 2025 08:23:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978346.1365158; Wed, 07 May 2025 08: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 1uCa4B-0000jg-60; Wed, 07 May 2025 08:23:47 +0000
Received: by outflank-mailman (input) for mailman id 978346;
 Wed, 07 May 2025 08:23:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCa49-0000jX-Fk
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 08:23:45 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2415::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 95b1e80d-2b1c-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 10:23:43 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by CY8PR12MB7148.namprd12.prod.outlook.com (2603:10b6:930:5c::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Wed, 7 May
 2025 08:23:33 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8699.012; Wed, 7 May 2025
 08:23: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" 
X-Inumbo-ID: 95b1e80d-2b1c-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VmcRAZXGCPXi1O/j7Jv2APu7InjTjRSOCQmuTU/I3dyCm3ksxZMGkjC/GM0eAjLrxwwFiHviXr54fLKeu/oNC3pcbKyMJ9LpJ0xBnT39tlCh5R/dEjw+WhdGJjK9k+5jvNFKqZhsVxBwee44ftcCJUT1qHpuyWLiE8Bq7U8cgF3dX7/AFkoU4Wx9X8majroNIRvCUFqOjCPccfN3CpJLYfY/tWq04MuI9lcO5XtPRLM9BKkGwVbi1wLA7zhjWA0TsfMqGkzTMICd6op/eMYv0ScFdltKaaHyQQWFFS3ZFIC2Hbr0iCBK0uZevLZSl9lmI235lydAhhjt4QFws8UX4A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gJz+KNr4Z0BgcgfYez3DfAnWIh3q8h0/eL6abuPzapM=;
 b=X8m2UP+o4DE4Lt6xivbyG+P+UXXLwC0Pp+1+Yu4dkoo7A8NAhJ0Xpjn9zZtNLnVEwhzU7/OLQy8Dd+UlzmnRgBrS8sMVaxK6wtplxRUSKVt+gfUoaPJ8feM6+8dPy0Nigq8yvnIdJxgRDp8pJifUf7vaivsjK2ybDiLUKnxJbLHiCOfBUOSoluWpTAQsEw9ZXjBX+TDJCCkq7cM0dGQY5NvD1jWORh/Kjh3DHbP+MlN6ikHZk2FfrjZcGNjuWAAZ+WEpg0ptMVAIRTv5anAr/qUvg2NOo0ODljBN9VTo2y2JMD5YcXYXY6JFTImx12ce49TVeSXgnM2rfRSfNhd35g==
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=gJz+KNr4Z0BgcgfYez3DfAnWIh3q8h0/eL6abuPzapM=;
 b=qdlEd5qPEoS7DHk3XITdBogZdhcfFxfa21YVM0jDvWsHVR28GsplrkPC7PWXeY8nHGVbSsCoZas7gwwyXJa2k/LwrWBn5kguT9GeuBbtROP+UPCDQuBxEzXmrnvnMp4sAhNFeM1ZCRbTdYNAGPWbFb+GBqq6DPG8GhF2xSmKXNE=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , Andrew Cooper , Anthony
 PERARD , "Orzel, Michal" ,
	Jan Beulich , Julien Grall , Stefano
 Stabellini , "Chen, Jiqian" 
Subject: Re: [PATCH v3 05/11] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v3 05/11] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index: AQHbsoVaTdJd8UN3wUOnIdqQLAHMILPFw6cAgAGFDQD//5+hAIAAii+A
Date: Wed, 7 May 2025 08:23:33 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-6-Jiqian.Chen@amd.com> 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8699.005)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|CY8PR12MB7148:EE_
x-ms-office365-filtering-correlation-id: 2bf87b20-7add-4057-aa92-08dd8d407504
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?Z2Jlc29aRnRqVTYxQUJWOFJaaE96bGlhbEJMZWh0M0JUNXdZSE9xNUd4M25o?=
 =?utf-8?B?L0NDaXEzLzE1cmVSZW1RYnhyT29WZHNtR3dhN3dpbmgreDRjK2JBR3kyMUkz?=
 =?utf-8?B?NlcxUERMN0RIdmhmMHI4QWRrT1VFVjBveXBkeGp4TmxBSGx5ZmMrbmFhWGo3?=
 =?utf-8?B?SFh4TGJ5SWR3UEpYWVpyRDBzSGhxWGtZSllJUXZQNFBHMTZsRmtYRkxNUDkv?=
 =?utf-8?B?dDh0NUpsWWpTckFCQStBS1AycFVGcVlUMGw4MWVEcklrUy92Uit2YWVzakgw?=
 =?utf-8?B?U3oxU1FiRU9wSi9pU3JjWGdwWnpJYTFnclNlRmFVNFdGQlF1VjVmYWNaSGE0?=
 =?utf-8?B?NkllWDZ1TEVING10bTFhbFZJUXJ2YThkV0RjMmxjVkoxY0ZSU1ZvTC9tNDIy?=
 =?utf-8?B?dVhaRWNMaWNXcnVRSnYwYWhrVmdCYStZSEhzL3hsT1RjWStrVHZPUlNKb1Y5?=
 =?utf-8?B?dk1LdEJrTFR4VHFGMVFxZkRXTGJXMlFzWS9SbW9lbWFPZ3Y1R2N2dE9DK2or?=
 =?utf-8?B?TnBWKzdSQlRzL0FDYzdhQS93eW1NdVlwenJObHhQQlo1SDY4MUJYRWlRTjl0?=
 =?utf-8?B?T3JUdDFQVWJlNURPYVZPNjBDeUxQbGxJbTRPVVZoR3gwemdWTEU4L2g5cnkv?=
 =?utf-8?B?cU9zdlc0MGlpNEFuTDdlUG9oYTNkSlkyY3ZDaWJ2eG91ZEl1WHBLWllkVmtE?=
 =?utf-8?B?RVZWTHp6aDBZYzFjbmlqSHF0WHJYSmF2dFFMZjhCeXVwL0YxUWNId0VZbnps?=
 =?utf-8?B?VWVmNkdUODltaG9HMlEzZk9najB4WHQ2dk1oRjNrSjVCUnFHSm1NRFdsTUsz?=
 =?utf-8?B?Q1BkNUI1UmNZd3pvcUJhZEgvTWRmTS9xSFZuT2xtaVlMNUxoZUxpUm5kRkg2?=
 =?utf-8?B?SGlMNDdSVkNwS2xJeVphK1lrUWVxRzJDNHVnaE9TclR1a2ZQeVcvOXV1V1k0?=
 =?utf-8?B?SUVnOFhOdjl2U01hQjNBMS91c2JUS2ljTzlwYzZqRkg2SCs2MHVMZ29tRUdB?=
 =?utf-8?B?UG41Tjc5UFBlSG9sQkFKUzl3aWd4RVpsOHpRaWZUb2wyZkZYNkQzWjZOT0VW?=
 =?utf-8?B?YVRWek1UR29vbEQwaUp3dmZtb25WUVFKVjJmMEk3NEhwYUl3eEVnbXRieUtk?=
 =?utf-8?B?Z0ZQdEdXbHVtcG0yL3R4WWdJbnRITFFhOWR2WHZMU1ltWEgybnlWK3FKbExJ?=
 =?utf-8?B?Y2N4QVQ0bTN0SlVWRXhKeFgvL3UxOWx1UFM0dGpkWnhkRTJhaXVSaGxJSjNE?=
 =?utf-8?B?NncyRmpKaTdzTWhQVHJFMWhlS3g2SHZsSEJGTXB1c2JZNi8yRVRTQ3c3aHV2?=
 =?utf-8?B?Y3JkQ2Qyc29OYjlRTzd5T2FZMXZMTWc0VG1pRzgvdDg1Q2lYWndRN2R4UENl?=
 =?utf-8?B?MEVMcDRJd0x1SmhqVHRqTzNJYy9PYW1HTk1BN0JJbXg4V2MwcDNreHpoU0NK?=
 =?utf-8?B?OUF0SGdDODdLTGZGUzV6aDZweU1rQk1EOVU5WjVLMU5ISUYzMFE2TkFMNTI1?=
 =?utf-8?B?cC9YTWZTTEgvRloxeTBhNWNPTmRuaGV4YXhxMzlIUDg4RzN6dnAxdEFBZnZu?=
 =?utf-8?B?eVB5WHN5L0Y1L0w2YXJFeWxQSXhIY0NKTWlQNlAwbFFCenlvYnhsNytEajRz?=
 =?utf-8?B?SXVvUHAwaUNzUVdyYkJ5aG0ranN2L1FCT3ZodVZmc090UUwrL1FqaUFPT0Jp?=
 =?utf-8?B?d0xFdlh2aEtMYW9JNTJJTDBKeU9oTG5JdFJ0QXN4TUZBWWJqRkNjcWhvbEpo?=
 =?utf-8?B?bG0vbDFyWEtjZXRmOU9VOXpHLzA1LzFkNVFLMldXNTBXQWFCMXE0Qk82Zmk5?=
 =?utf-8?B?RXhKUGtUQmxtVzM0Wi9ISk5lMzFGWHpJOTllK2V1aUhZMHVhZFZwbXlHc0hi?=
 =?utf-8?B?bkliK2RxVkdST1lxNnZrNVdJQi9rR1VyNDNWNktaYnV3TzRUQWJKUGMrYkhi?=
 =?utf-8?B?S3h1UVdOQnRTWndVYlhaOW4rY0ttNzZCMVdBdVdlV1kyNXM0SUZUekh1cXZa?=
 =?utf-8?Q?XXTLAyAcoXJnGmLqMOEeNVDUUBXyHU=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VUF5VkZhbHFoNFRDQTFaUDhTZ0hpSGhjWEJ6a1ljdG0zejNKcWR4Sjhxbitj?=
 =?utf-8?B?MDJTdjdaYjNROCtXbEdvZXArOE5NQVQxRjBpbjdpYU1mK0ZISnFlR1FtZjA0?=
 =?utf-8?B?bUplNktFUWNrelRGb3o5T3c3UTdRRGczS1A0cGoydE1iYUVlNzhNTURVZ2t2?=
 =?utf-8?B?Qm1CNmZkR21pRW5MejU1dk9TSWRlZ282ZGZuYm5SZzFGeGQvN0JpcDBqUG1Z?=
 =?utf-8?B?K09XWVdOR2ZkZC83eWkzSDBnOVhZRU1CZVpwUHlhRWJ6VU5DM0Z1clFaK25n?=
 =?utf-8?B?d1UreURiNFQyMUdlUUFuRVNpWWFlVnZaSXEydldpbFhZNys1em1tQnZNYStl?=
 =?utf-8?B?eStqV29zMnZMcU1rTWw0NExzcXh6YTBiVUVIaTdkR0FtWEhQemQrY25DVFg2?=
 =?utf-8?B?dE9LU3JLT2tLc284TTB2MFBMWHk5OHorWjREUGRLTWNaVVY1R1BHaVdNSi8y?=
 =?utf-8?B?cTdoUi9BY1BmYU1FcHZ1dG1VRzhoUVdHanIvSEVmS0FKWmNpdWNKSzVzZjY5?=
 =?utf-8?B?Vm5FVEErTWZOYmViYnVRdXdUemY4QTI2T1JvcllwdGZrUGtkL1BCWnVYS3BM?=
 =?utf-8?B?SGZxbFJHdmVNbkVlN21xcm4yaWlscXZZZUV0eWNIM2ZjTnliVS9Rc1dmWTdO?=
 =?utf-8?B?S0lQUTNmSFlhejk1VzcrdUxVdlFMOHIxL1VnbkN0SSsya0lPRnNuVkM5YnBX?=
 =?utf-8?B?bFkvcGtVM3BiZlB1a3NBRVlSMHN2UGlzT2VwY09FYXdhUWxyTUp5WVJRdjhG?=
 =?utf-8?B?NzZRSExyMVA2ZnFvakJyK0R5U0wrbVNxTU5MRGJJWjQyczVUZkczcFNCR3pM?=
 =?utf-8?B?WWF5KzZQeGFweE1VSExsOTlITWdjRE9hdHZrZmVPTXVzaTdoTDlETVlHYlBW?=
 =?utf-8?B?V0RLelpUaXVxL3kvQUFxSlBlSnRXWU93M0tET3VVSDBrVHczOWVPdHVzN21C?=
 =?utf-8?B?TDQ0ZFVzaFdHQ3JMN0F1cGNKaXg0dmdseGFTVlBENFVUVmo4eXZpMG5tMnFl?=
 =?utf-8?B?bjRlSER3UWFlSU9nS1hrR0J0THhnRTBWL3RCS0pOVTdxcVBDVVVLNElEWDRS?=
 =?utf-8?B?SVFrOU9xSXJJWGh0MHQvT1lxcFBPNERqY0xueHNwMTlMTXlpRGEzSE1YbGk1?=
 =?utf-8?B?Vlo0dWg3MFhwMVV5ZTEvV1c1U05nc0pRbFNFd2g1cndCeUwrbGNNNXAyYWVx?=
 =?utf-8?B?bVAvVHBwUTdrN0FSaEcrbWVxV0hPODhLRnh6VTIzNHlOVlJ5UTl3Q3lkWitT?=
 =?utf-8?B?aHZLSG1oZGwzYzhpcjJSY1FxU0cxTi9IVS9Tc2FjYU5LZjdCN3JZK0g5bXk1?=
 =?utf-8?B?OUh6VEVxQ1BMeWVWdHFKUy9GRXRwckNjQnN1dm9oMVJHVElickJwUnNqY3Ix?=
 =?utf-8?B?QU96cHdXcFFmRzRQNWpUakl1YlVGSzNrd2pZdlFqck5jZjFSdjU0dGxIMEh3?=
 =?utf-8?B?Ynp1a0lxTFpGZ242ZDBWODBOUUVrNUJXYzh4WW4rVnZqd0JackR2RGd0RExI?=
 =?utf-8?B?TlFuTW03MWtzV2hIcnN5eDcvNHNGUGdicG16VzladmhwODdPZ0hOS0ZCVlJF?=
 =?utf-8?B?TkN3Y01kdjdjcVNhWTRkY2hxYXJvNnhuUUVaeVFYSmpnb3RyNlRxaHl3TGZJ?=
 =?utf-8?B?SXNhcml5eDI4eG5KRnorV0MwdHl6Wlcwcms5WXJmR1psZm5HaGRqQlhZdzBm?=
 =?utf-8?B?VXB6Vk00N2drLzZKL0h6WjdvYUZnQUNDN2R5UnY3OTJValdkaDhzVk92K2Qy?=
 =?utf-8?B?VEZOUUJoNTVHNVRHS01ueTdGNXJ1YmNCQVpRMjE3Vzl2UnluTEV4eElzWUZU?=
 =?utf-8?B?ekZVWUNLbHl5Y3RrL2RaYUdneGZGc3V4L0NNZFcza1R1blpjRUF6TnI5QlF2?=
 =?utf-8?B?NzNKME8wd3U5TyswcW9yNVo0dUh4VjV0R0FnU2RhU1VXNHlLRFZkcjdUYTVJ?=
 =?utf-8?B?aEJBQUs1Q1NCd2d1cXdBUFltc2dUZWNRSldBMGkrMjI0MTlheGVtbGNpNVlm?=
 =?utf-8?B?ZDFSOG96SGMySkdQMzI5cndNcVpQK3pvZU9aZSt3a21RT0JOS2hvNS9FTHk5?=
 =?utf-8?B?bW42NkxEM2xnYk8rcHZHdFFBbFZya2d1ai9IL3pUcjRlSjFVclNiOUljYUNo?=
 =?utf-8?Q?oqB4=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <006322F6C330844CA84A800F5A732045@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2bf87b20-7add-4057-aa92-08dd8d407504
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 08:23:33.6796
 (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: R1Df61iMTyOQZScgzymgNAr4y7faFWr6+6LsIKdySsqstxekrBj57M3YqtBaDX059028129zwP8NlyH49O/L/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7148

T24gMjAyNS81LzcgMTY6MDQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIFdlZCwgTWF5
IDA3LCAyMDI1IGF0IDA1OjU5OjUyQU0gKzAwMDAsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+IE9u
IDIwMjUvNS82IDIyOjM3LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPj4+IE9uIE1vbiwgQXBy
IDIxLCAyMDI1IGF0IDAyOjE4OjU3UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4+Pg0K
Pj4+PiArICAgICAgICBpZiAoICFpc19leHQgKQ0KPj4+PiArICAgICAgICAgICAgcG9zID0gcGNp
X2ZpbmRfY2FwX29mZnNldChwZGV2LT5zYmRmLCBjYXApOw0KPj4+PiArICAgICAgICBlbHNlDQo+
Pj4+ICsgICAgICAgICAgICBwb3MgPSBwY2lfZmluZF9leHRfY2FwYWJpbGl0eShwZGV2LT5zYmRm
LCBjYXApOw0KPj4+PiArDQo+Pj4+ICsgICAgICAgIGlmICggIXBvcyB8fCAhY2FwYWJpbGl0eS0+
aW5pdCApDQo+Pj4NCj4+PiBJc24ndCBpdCBib2d1cyB0byBoYXZlIGEgdnBjaV9jYXBhYmlsaXR5
X3QgZW50cnkgd2l0aCBhIE5VTEwgaW5pdA0KPj4+IGZ1bmN0aW9uPw0KPj4gU2luY2UgSSBkb24n
dCBhZGQgZmluaV94KCkgZnVuY3Rpb24gZm9yIGNhcGFiaWxpdGllcyBhbmQgYWxzbyBhZGQgY2hl
Y2sgImlmICggY2FwYWJpbGl0eS0+ZmluaSApIiBiZWxvdywNCj4+IHNvIEkgYWRkIHRoaXMgTlVM
TCBjaGVjayBoZXJlLg0KPj4gSSB3aWxsIHJlbW92ZSBpdCBpZiB5b3UgdGhpbmsgaXQgaXMgdW5u
ZWNlc3NhcnkuDQo+PiBTaG91bGQgSSBhbHNvIHJlbW92ZSB0aGUgTlVMTCBjaGVjayBmb3IgZmlu
aT8NCj4gDQo+IEkgdGhpbmsgYGZpbmlgIGlzIGZpbmUgdG8gYmUgTlVMTCwgYnV0IEkgZG9uJ3Qg
c2VlIGEgY2FzZSBmb3IgYGluaXRgDQo+IGJlaW5nIE5VTEw/DQo+IA0KPiBNYXliZSBJJ20gbWlz
c2luZyBzb21lIHVzZS1jYXNlLCBidXQgSSBleHBlY3QgY2FwYWJpbGl0aWVzIHdpbGwgYWx3YXlz
DQo+IG5lZWQgc29tZSBraW5kIG9mIGluaXRpYWxpemF0aW9uIChpb3c6IHNldHRpbmcgdXAgaGFu
ZGxlcnMpIG90aGVyd2lzZQ0KPiBpdCdzIGp1c3QgYSBuby1vcC4NCkdvdCBpdC4gSSB3aWxsIGp1
c3QgcmVtb3ZlIHRoZSBjaGVjayBvZiBpbml0Lg0KDQo+IA0KPj4+PiArICAgICAgICBpZiAoIHJj
ICkNCj4+Pj4gKyAgICAgICAgICAgIHJldHVybiByYzsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+
Pj4gKyAgICByZXR1cm4gMDsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiAgdm9pZCB2cGNpX2RlYXNz
aWduX2RldmljZShzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+Pj4gIHsNCj4+Pj4gICAgICB1bnNp
Z25lZCBpbnQgaTsNCj4+Pj4gQEAgLTEyOCw3ICsxNTgsNiBAQCB2b2lkIHZwY2lfZGVhc3NpZ25f
ZGV2aWNlKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4+PiAgDQo+Pj4+ICBpbnQgdnBjaV9hc3Np
Z25fZGV2aWNlKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4+PiAgew0KPj4+PiAtICAgIHVuc2ln
bmVkIGludCBpOw0KPj4+PiAgICAgIGNvbnN0IHVuc2lnbmVkIGxvbmcgKnJvX21hcDsNCj4+Pj4g
ICAgICBpbnQgcmMgPSAwOw0KPj4+PiAgDQo+Pj4+IEBAIC0xNTksMTQgKzE4OCwxMyBAQCBpbnQg
dnBjaV9hc3NpZ25fZGV2aWNlKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4+PiAgICAgICAgICBn
b3RvIG91dDsNCj4+Pj4gICNlbmRpZg0KPj4+PiAgDQo+Pj4+IC0gICAgZm9yICggaSA9IDA7IGkg
PCBOVU1fVlBDSV9JTklUOyBpKysgKQ0KPj4+PiAtICAgIHsNCj4+Pj4gLSAgICAgICAgcmMgPSBf
X3N0YXJ0X3ZwY2lfYXJyYXlbaV0ocGRldik7DQo+Pj4+IC0gICAgICAgIGlmICggcmMgKQ0KPj4+
PiAtICAgICAgICAgICAgYnJlYWs7DQo+Pj4+IC0gICAgfQ0KPj4+PiArICAgIHJjID0gdnBjaV9p
bml0X2hlYWRlcihwZGV2KTsNCj4+Pj4gKyAgICBpZiAoIHJjICkNCj4+Pj4gKyAgICAgICAgZ290
byBvdXQ7DQo+Pj4+ICsNCj4+Pj4gKyAgICByYyA9IHZwY2lfaW5pdF9jYXBhYmlsaXRpZXMocGRl
dik7DQo+Pj4+ICANCj4+Pj4gLSBvdXQ6IF9fbWF5YmVfdW51c2VkOw0KPj4+PiArIG91dDoNCj4+
Pj4gICAgICBpZiAoIHJjICkNCj4+Pj4gICAgICAgICAgdnBjaV9kZWFzc2lnbl9kZXZpY2UocGRl
dik7DQo+Pj4+ICANCj4+Pj4gZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi92cGNpLmggYi94
ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQo+Pj4+IGluZGV4IDlkNDdiOGMxYTUwZS4uOGU4MTViNDE4
YjdkIDEwMDY0NA0KPj4+PiAtLS0gYS94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQo+Pj4+ICsrKyBi
L3hlbi9pbmNsdWRlL3hlbi92cGNpLmgNCj4+Pj4gQEAgLTEzLDExICsxMywxMiBAQCB0eXBlZGVm
IHVpbnQzMl90IHZwY2lfcmVhZF90KGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1bnNpZ25l
ZCBpbnQgcmVnLA0KPj4+PiAgdHlwZWRlZiB2b2lkIHZwY2lfd3JpdGVfdChjb25zdCBzdHJ1Y3Qg
cGNpX2RldiAqcGRldiwgdW5zaWduZWQgaW50IHJlZywNCj4+Pj4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdWludDMyX3QgdmFsLCB2b2lkICpkYXRhKTsNCj4+Pj4gIA0KPj4+PiAtdHlwZWRl
ZiBpbnQgdnBjaV9yZWdpc3Rlcl9pbml0X3Qoc3RydWN0IHBjaV9kZXYgKmRldik7DQo+Pj4+IC0N
Cj4+Pj4gLSNkZWZpbmUgVlBDSV9QUklPUklUWV9ISUdIICAgICAgIjEiDQo+Pj4+IC0jZGVmaW5l
IFZQQ0lfUFJJT1JJVFlfTUlERExFICAgICI1Ig0KPj4+PiAtI2RlZmluZSBWUENJX1BSSU9SSVRZ
X0xPVyAgICAgICAiOSINCj4+Pj4gK3R5cGVkZWYgc3RydWN0IHsNCj4+Pj4gKyAgICB1bnNpZ25l
ZCBpbnQgaWQ7DQo+Pj4+ICsgICAgYm9vbCBpc19leHQ7DQo+Pj4+ICsgICAgaW50ICgqaW5pdCko
c3RydWN0IHBjaV9kZXYgKnBkZXYpOw0KPj4+PiArICAgIHZvaWQgKCpmaW5pKShzdHJ1Y3QgcGNp
X2RldiAqcGRldik7DQo+Pj4+ICt9IHZwY2lfY2FwYWJpbGl0eV90Ow0KPj4+PiAgDQo+Pj4+ICAj
ZGVmaW5lIFZQQ0lfRUNBTV9CREYoYWRkcikgICAgICgoKGFkZHIpICYgMHgwZmZmZjAwMCkgPj4g
MTIpDQo+Pj4+ICANCj4+Pj4gQEAgLTI5LDkgKzMwLDIwIEBAIHR5cGVkZWYgaW50IHZwY2lfcmVn
aXN0ZXJfaW5pdF90KHN0cnVjdCBwY2lfZGV2ICpkZXYpOw0KPj4+PiAgICovDQo+Pj4+ICAjZGVm
aW5lIFZQQ0lfTUFYX1ZJUlRfREVWICAgICAgIChQQ0lfU0xPVCh+MCkgKyAxKQ0KPj4+PiAgDQo+
Pj4+IC0jZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfSU5JVCh4LCBwKSAgICAgICAgICAgICAgICBcDQo+
Pj4+IC0gIHN0YXRpYyB2cGNpX3JlZ2lzdGVyX2luaXRfdCAqY29uc3QgeCMjX2VudHJ5ICBcDQo+
Pj4+IC0gICAgICAgICAgICAgICBfX3VzZWRfc2VjdGlvbigiLmRhdGEudnBjaS4iIHApID0gKHgp
DQo+Pj4+ICsjZGVmaW5lIFJFR0lTVEVSX1ZQQ0lfQ0FQKGNhcCwgeCwgeSwgZXh0KSBcDQo+Pj4N
Cj4+PiB4IGFuZCB5IGFyZSBub3QgdmVyeSBoZWxwZnVsIGlkZW50aWZpZXIgbmFtZXMsIGJldHRl
ciB1c2Ugc29tZSBtb3JlDQo+Pj4gZGVzY3JpcHRpdmUgbmFtaW5nLCBpbml0IGFuZCBmaW5pPyAg
U2FtZSBiZWxvdy4NCj4+IGluaXQgYW5kIGZpbmkgc2VlbXMgbm90IGdvb2QuIFRoZXkgYXJlIGNv
bmZsaWN0IHdpdGggdGhlIGhvb2sgbmFtZSBvZiBiZWxvdyB2cGNpX2NhcGFiaWxpdHlfdC4NCj4+
IE1heWJlIGluaXRfZnVuYyBhbmQgZmluaV9mdW5jID8NCj4gDQo+IE9oLCBJIHNlZS4gIENhbiBJ
IHJlY29tbWVuZCB0byBuYW1lIGZpZWxkcyBpbml0IGFuZCBkZXN0cm95IG9yIGNsZWFudXANCj4g
KGluc3RlYWQgb2YgZmluaSksIGFuZCB0aGVuIHVzZSBmaW5pdCBhbmQgZmRlc3Ryb3kvZmNsZWFu
IGFzIG1hY3JvDQo+IHBhcmFtZXRlcnM/DQo+IA0KPiBJIGRvbid0IHRoaW5rIGl0J3MgY29tbW9u
IGluIFhlbiB0byBuYW1lIGNsZWFudXAgZnVuY3Rpb25zICdmaW5pJy4gIEkNCj4gdW5kZXJzdGFu
ZCB0aGlzIGlzIGEgcXVlc3Rpb24gb2YgdGFzdGUsIGl0J3MgbW9zdGx5IGZvciBjb2hlcmVuY2Ug
d2l0aA0KPiB0aGUgcmVzdCBvZiB0aGUgY29kZSBiYXNlLg0KT0ssIHdpbGwgY2hhbmdlIHRvICJp
bml0ICAgIGNsZWFudXAiIGFuZCAiZmluaXQgICAgIGZjbGVhbiINCg0KPiANCj4gVGhhbmtzLCBS
b2dlci4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Wed May 07 08:50:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 08:50:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978364.1365170 (Exim 4.92)
	(envelope-from )
	id 1uCaTW-0004CX-As; Wed, 07 May 2025 08:49:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978364.1365170; Wed, 07 May 2025 08: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 1uCaTW-0004CQ-65; Wed, 07 May 2025 08:49:58 +0000
Received: by outflank-mailman (input) for mailman id 978364;
 Wed, 07 May 2025 08:49:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCaTU-0004CK-Ly
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 08:49:56 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20624.outbound.protection.outlook.com
 [2a01:111:f403:2418::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3ea67684-2b20-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 10:49:55 +0200 (CEST)
Received: from PH7PR12MB5854.namprd12.prod.outlook.com (2603:10b6:510:1d5::20)
 by BY5PR12MB4243.namprd12.prod.outlook.com (2603:10b6:a03:20f::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Wed, 7 May
 2025 08:49:47 +0000
Received: from PH7PR12MB5854.namprd12.prod.outlook.com
 ([fe80::bd58:fa72:e622:dd76]) by PH7PR12MB5854.namprd12.prod.outlook.com
 ([fe80::bd58:fa72:e622:dd76%6]) with mapi id 15.20.8699.026; Wed, 7 May 2025
 08:49: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" 
X-Inumbo-ID: 3ea67684-2b20-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=g4/lHclWUrfFajmIKWg8embTS4IcHXTwvF0hLkJl1vQm/VSs9j0aofIiiEEVaFMH28jUdtXovlSqQ1oaZ5eknhq86TJLUhTozx3KEHrDr/KCHiUkpci8uVPQ2vLGsynyrVdc/t5EmyOeoZDLGxqiHAgBBnDHcAHCSBPhdbPSzEQcrz/5hY4gwwstsYM5qNiQQypb8GpbUvO0ZR0tJNe2+ew790rAB2AMAtLm0lxPcc/zkxFecxTANTTVMM2Kw0HMDWShaGukbya1VwNQfNlIhwxxD8RhE6XF5P4bnvlFxR2CEAQ8cmyBlWz2k81FkJgCnaKK17SOe3kPjcGY+qoBhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Iim4TzIPNNlnuFVtofeZlQ0kuFDBdiBMQmrS36HSZa8=;
 b=lK+/poYpwfoyWde2Us4BZ3V8asd/j4flFvvMYIsYmhvXwou6rj3jiAvua7GbFv6TpRi+WmXm04F3B+qYFdfCFE7W/dt3Li4Rib7FmnfZM3C1kNWTLZWTrJZm/NhaANLiICbiCzpBuMJEOr3w4js4g+ttH7MzKA4ZvhnTuKPMwPxyegdgZFJ1jHDXBKlqQTsdGhrwMGiwb/BSVZbr0a7dNdKs/vPbBnCNhSiZt63pe2mqb2OlDxdMp3yKl4a53lJuoTUl7p2mADhRi1w3pOp9gurpalPDPPluhfGZNW57fGujl4JymT+o34EfW05AqVK0SueUTYMH3LBTsg/3tjihcA==
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=Iim4TzIPNNlnuFVtofeZlQ0kuFDBdiBMQmrS36HSZa8=;
 b=PbPj17dT5k172pwAneufQgLdjsI2HnQzxZV1qHBdmSMTjAOnlfpr5areRnAj89/XT/uiWYO7HbwBD1MO/xrAoPLO64ppiDKKinYH6jyb8+Pj5NWTb/ojeShhom6pHQiTBuio/vJLZg2XzRSOcgyconzg/MTfrtBsCeW6OBYj7Go=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v3 07/11] vpci: Hide extended capability when it fails to
 initialize
Thread-Topic: [PATCH v3 07/11] vpci: Hide extended capability when it fails to
 initialize
Thread-Index: AQHbsoVd9OkTHNIeNk69huFsDqzHMLPF4NaAgAGCYAD//4ZbgIAAkPkA
Date: Wed, 7 May 2025 08:49:46 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-8-Jiqian.Chen@amd.com> 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8699.005)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH7PR12MB5854:EE_|BY5PR12MB4243:EE_
x-ms-office365-filtering-correlation-id: 57643e17-c9ef-44ac-f316-08dd8d441ecf
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?ZXZxZ3Y3K3NrWExJOGl6Y2w5NWdvRFJxenpORTh4V0FkZzdWOVMrOXhOZGtT?=
 =?utf-8?B?L3pjTXQzYldYZU9QNyt4c3pOYTA1ZGFiWjByQm9YSTBPZFhSVjgrMmhTaDdw?=
 =?utf-8?B?eUpoT21rc2ZBY0k0MXBnVk9vbVJ6Y0xmbG5YZTJRb0crYk5SNlY2WElvVzY1?=
 =?utf-8?B?azA1K3R6QTMvSU9kd1JWZlRPaHpyTHNXYTROSnE1RVFNYTNJeDkvcnVMQmJI?=
 =?utf-8?B?NGV5cFVlR2VxVjE3ekNFeE5FLzUzSGc2SFNZWlFNcmROQ2dQc0RobnZOVTdo?=
 =?utf-8?B?Z2xUQzNTUDJzM3RCS29sd1pQcWR5dnQ3Mko0WUZoWE11cWMreVhJV1U3b3BU?=
 =?utf-8?B?Q0FxYU1zV2lVT3grV2xhNUJQQ25SYkVTajdTS0lPQ3BtTWtlQTFlcHpESkow?=
 =?utf-8?B?aFhpVjZsZGtoWmZCaWdvajI1Q2ppeElVWkRXVnpiZlA3ejZqcEVjNlFhYjRH?=
 =?utf-8?B?blAxWnBsMnQzMDZ3Z0dJaEFFLzhaSFBpSkVyUEVOVkN6ZTNTMGNxSnRVeDA1?=
 =?utf-8?B?b2pKQkppci9TbVdjOVR0akRMcXBNdkN0KzYvUXdIakdmNVB2WStzNEI5b2JD?=
 =?utf-8?B?SEZPT1AybUpFdEVkUElZcWhNcEI2U2ZLVDhDbWt6aGxnaDhFdlZzVHZUenE5?=
 =?utf-8?B?V2xYbk9KSmZTdkFxQWNiam1pekc1cnlYblE2UzA1eU9HWk9LKzQ1QWJtOFl2?=
 =?utf-8?B?ZDAyTHExV3hwa1RQTFo0UGlhUlZ4b0VneVZHSDBscWNlL2FwdzY0c2VMWmxD?=
 =?utf-8?B?V25LbFZoZWVNRXU2RmFjMktjK3p4d2NacnJ5YS9BL0orTHZOYUg1UkN5M0xS?=
 =?utf-8?B?TU1mS00ydzdzWEJTOXVCeXhwZERqVXZXbXhzcDJQRVVtYmtRT3hFNERXVlor?=
 =?utf-8?B?U1hGUDNXdjdJdVlDM1BVZFZmdGlhdTNkdkNLRDFGTWQ2UjAvUThTVUkvRmVD?=
 =?utf-8?B?ZTB2bTRER2JBZzNkTndkRGtWcFRDbmhWT3BodWZRdFJFMG5Ca29WZEJOWnlV?=
 =?utf-8?B?SElmUWp2MXBBZlBOS1BVS04yNEVjVHkxYXQ2UURaSmY2T3pKK3VHakVzbTZa?=
 =?utf-8?B?dXpqVnRybVIzb3ptaUYxbE5uakYzWFNBTktoNE1CMldKMTg3dWtUR1VHY1Zi?=
 =?utf-8?B?Q2tvL2ZKd1ZlWUx1Rm5VWURramJNSHdmVC9FRjBRY1JnYkljMGpCaHUyV3g2?=
 =?utf-8?B?WS8xOUUwTE50Zys3dTM0WUswOW1iK0JBbjIvUHFYeFB4TW5lNHE0QTE1L3h0?=
 =?utf-8?B?QU9yNGVzR0dvbVpqSlcwbE95bUEyZHlkT3E2aWd2SkhMVHExVGtaZlU0QnNs?=
 =?utf-8?B?dFJFeHEvWEpYQ291SU5qcENsTG9qSjB4UHl2bytOWnVSZFFWSHpLanFiN3hG?=
 =?utf-8?B?d2tvTmRsZWNNdWpoVkNHVWN0cFA0Rjgvb2Jvczk5UjMzdDVCUVVvdG02RTBR?=
 =?utf-8?B?SXlQbWRjajE2eFlDSksvaUtPQlllZENGKy96cHpBZWNQMnI4VFBjRTlBMXhj?=
 =?utf-8?B?L2lpdXAvcTdqbTVFOWVlb1E0TWJkMHZyV0RIT04ySzh6bnpXeE1ERzJ1MDdK?=
 =?utf-8?B?OCtCYmlMMGNRTVN1Tlp0RkpZWlVldlU3U3F3NDlBY253SzN4S0tWeEptSjZX?=
 =?utf-8?B?SU1OY3p2WEh1b2xucmdCOC9EVVRQc3VNeUp0ZjJIdmNDWmVPZ21sSGtoQk5S?=
 =?utf-8?B?Z2JaK2ZGb1Z6ZzExc3Y5UjFkYnhxSVVzN2RKellvQzJ0V0pMOEJ2RzR4RGQ3?=
 =?utf-8?B?U2d1OC9FaDRxVnozdVQ3ZHcySlRWQy96c2o0S3htNzNRNWF5SWZpaWNKU2s5?=
 =?utf-8?B?MTg2YWVHWllSVFBvZmpiZnRFdVNYWUdjaDZzZ3lNOFB2cjd4ZVoweEczZXF0?=
 =?utf-8?B?SHpuZllJUHplSWJzamp6SFJIK0x2bkxZQ3NLZDBVVld5VWwwUjFFMXUzYWcr?=
 =?utf-8?B?OWh1V1FsT3A1Vkp2TUZza1JJS2N3Nk9NYWhHdXZ5TVJCYjFsQ3drbSt6bXB1?=
 =?utf-8?B?UFdHVnp5aG1nPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5854.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Q0s4bVFhWnFvU2dNMHIxbVZqSEdldXpENGVIeWZCTkkrTWVuZjBEZTZqV0ho?=
 =?utf-8?B?TlVwVkhUUVJ3eW5FQnhpVnN5L2t3NGc5bVdvcVdKWlA0cGVzN2F4MlUzR1Nt?=
 =?utf-8?B?SHF4QUZjcDV6V2VPRXZRcGc2RER2TEUzcVV6U21RS0xTS1RRbm9vYWpLWEJp?=
 =?utf-8?B?cm9HbTdKYThzODMranQvbDYyQjg2RWJtN0x2WHV2RWhQem1wT29TUno4WmJC?=
 =?utf-8?B?c2JLY2ZEaXR0M3VUeDBOajAwTlRzUlQ1Y0JsSmFGOG1ienJySGdnd1dHVmVu?=
 =?utf-8?B?TUxIWEc4cHBnNEhiSUNRdnlSMTExa2lhbnRDNHJTbTQxWXpaWVZ1YmlpZWVH?=
 =?utf-8?B?cjlvTDZhNjVRYVpheWlEbFllUmJkUHd2aXJ4MlhTcTRPZnYyTWFXTFJrNVVh?=
 =?utf-8?B?Nk91YnhESVV4NTBtS3BUMlVSM2ZPek11bFFqK2JiYldCTElmRTdKd0g2cDZE?=
 =?utf-8?B?eXJ0RWpyNkw4MWgvTVI5S2cxanhScDlEWDgxVjFnMmRHSFp3aCtzSTZzOWF2?=
 =?utf-8?B?dHI3V3lHdHg0UzZWYnN5VWNZaXJyb2d4Qm1yelNoZ3d3aTBKT0I0b3VWekZI?=
 =?utf-8?B?VDZjYXhucld4S0RkTW5xN2M3ZmdzV0pZeE1JZG0vVURoNUltSWJCa3NTbUE4?=
 =?utf-8?B?L0MvVmlGc1gzMGx5c1hHeUlnV1BpS1F6dGZ4OGdvc3RLcVBXMktoZHZZVGUx?=
 =?utf-8?B?ODhKSC8yVHZRRlhUQW9FeFVyUFhWVlFySmJYa2NEckpTSUJ0Vy9IbUJlYkZJ?=
 =?utf-8?B?VFlEQVhKZkF6WnpnVEFPS2ZUTU5CZ0JycnFKS2NoQ3gwZ0pNSHVTL2U1Z0d2?=
 =?utf-8?B?OUpGTnBReGVqcTMzT3lab3lZNVoxRmNwU1h6ZUw4b2NZWmErVVJ4TTZOL0pk?=
 =?utf-8?B?VWJIRkNWRHNYRXVSMWY2Vm1KaWNheGMzUWg1RVRkVjZmc00wV2Z1UGpwc1Y5?=
 =?utf-8?B?eEtZVTU5UUtzQmR4Yk56eUJucG5vUE1aYWZadXpMMUdrWnJodVNkYzcweVVG?=
 =?utf-8?B?Q05zTDN2NWRWWWJ1VG1aOSt6UUVMSThvcGJ3c3J6SGM3aW5iMDlCL0h0d0F1?=
 =?utf-8?B?ZXFQdkNjZ0pZNTcyaEN1d3ZTY2lJSlJFL0xuQWZXeERHaFByZmo3dmEva2Vt?=
 =?utf-8?B?QXBLTnpGQmYwR1BRNk1iNVh1bmkvdVg2eTZDT3llUjF1aVQxcXAwbnN3Z3FL?=
 =?utf-8?B?d0FRd0YyQzh6SFJoZzVxejEwbGo3S1IxVDZFUjlCaDRxM3hPc0JCcks3ZDlU?=
 =?utf-8?B?SFNUMnhTYm5QYkdOSmNiWHAwRTVCUVBnSk4rMFg4WlMxWWdZcHRWc05nMmZm?=
 =?utf-8?B?VnFNSEMzK0o0U0d1MGN2Y2JvQmo3bW9DOFZDVUNBaCtIaWhWV0xzRzNWSkNI?=
 =?utf-8?B?MVJVNVVVRi9Rd3hYL2R0b1hITFhwZGYvaEZObUhQOHdyMG1GZU9KbENkSnBv?=
 =?utf-8?B?aTExOERRRFlDNkZUNlBKNGl4UGdPZ3dMUk1HV1JLeVNBYjRON0Q0cU5xRUpy?=
 =?utf-8?B?Vm8xNEVrU3BUU0FBZUVkMjJEdGxWQWRyT01iWDVYSzBqMHorQzZnM3loUXVE?=
 =?utf-8?B?ZitJUDc3Wk1jV1poZEU3SnY5Ly9hTDhCQnYwS1d1LzJpMHFiYjBJbW9TUVZD?=
 =?utf-8?B?Ri9xNWEzdTNYMGFnbXJNOW8zZGFRUzl5RHNHT2xIQktTbWEreStOVWtCUjBQ?=
 =?utf-8?B?Y3RYVmh4Zk0zVUFvQlF3ZzltNTZQa2pGOENQb3VSRnRlQ05LV3ZyK2pMU0gr?=
 =?utf-8?B?MUh1QklheGpUL1R4S2dFeEtFS3FkTjJNMXM2b3NuUFNOUk1MRWZsckVUVkZP?=
 =?utf-8?B?bmV5OGtIUDJLdlI2NFdjcVZFOXJQbk5jdmdZUGd0aFJPMFR6alFaeSt1TTdC?=
 =?utf-8?B?YTBjbzVheW9XcjNXdUs2SXY2aTg2M2l6eHQ1Zm1QYWcza1RibU5jenMxdU9M?=
 =?utf-8?B?TFRGYm1QZ3YzMk9qYWdFbXJsa0thZDA5TkhUSE12TjNFRUU2YTZsbUFTQnVi?=
 =?utf-8?B?bjhBbFRrNEEvcThWRnJXNk9CRkIrQTZYM0JuMW12VGQyVnQzN1UrMHVCL3cw?=
 =?utf-8?B?SkszQXpoYWxPeTFBY2UzSkpveldSa3pKWnVRdUVvT1RLeFdVWVU3V1N0dndU?=
 =?utf-8?Q?ewB8=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3AC9AC1BAA1ED44EB6560AD055BFA898@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5854.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 57643e17-c9ef-44ac-f316-08dd8d441ecf
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 08:49:47.0361
 (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: 6zYImc0Gnv4pdPkAR43gXOboBgKhlXhe7jt9eUpr9nI6EbZS3lcomg/2Dh91fQCAz85YRj52dRyPogR5quwaDQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4243

T24gMjAyNS81LzcgMTY6MDksIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIFdlZCwgTWF5
IDA3LCAyMDI1IGF0IDA3OjI2OjIxQU0gKzAwMDAsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+IE9u
IDIwMjUvNS83IDAwOjIxLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPj4+IE9uIE1vbiwgQXBy
IDIxLCAyMDI1IGF0IDAyOjE4OjU5UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4+PiBX
aGVuIHZwY2kgZmFpbHMgdG8gaW5pdGlhbGl6ZSBhIGV4dGVuZGVkIGNhcGFiaWxpdHkgb2YgZGV2
aWNlIGZvciBkb20wLA0KPj4+PiBpdCBqdXN0IHJldHVybiBlcnJvciBpbnN0ZWFkIG9mIGNhdGNo
aW5nIGFuZCBwcm9jZXNzaW5nIGV4Y2VwdGlvbi4gVGhhdA0KPj4+PiBtYWtlcyB0aGUgZW50aXJl
IGRldmljZSB1bnVzYWJsZS4NCj4+Pj4NCj4+Pj4gU28sIGFkZCBuZXcgYSBmdW5jdGlvbiB0byBo
aWRlIGV4dGVuZGVkIGNhcGFiaWxpdHkgd2hlbiBpbml0aWFsaXphdGlvbg0KPj4+PiBmYWlscy4g
QW5kIHJlbW92ZSB0aGUgZmFpbGVkIGV4dGVuZGVkIGNhcGFiaWxpdHkgaGFuZGxlciBmcm9tIHZw
Y2kNCj4+Pj4gZXh0ZW5kZWQgY2FwYWJpbGl0eSBsaXN0Lg0KPj4+Pg0KPj4+PiBTaWduZWQtb2Zm
LWJ5OiBKaXFpYW4gQ2hlbiA8SmlxaWFuLkNoZW5AYW1kLmNvbT4NCj4+Pj4gLS0tDQo+Pj4+IGNj
OiAiUm9nZXIgUGF1IE1vbm7DqSIgPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KPj4+PiAtLS0NCj4+
Pj4gdjItPnYzIGNoYW5nZXM6DQo+Pj4+ICogU2VwYXJhdGVkIGZyb20gdGhlIGxhc3QgdmVyc2lv
biBwYXRjaCAidnBjaTogSGlkZSBjYXBhYmlsaXR5IHdoZW4gaXQgZmFpbHMgdG8gaW5pdGlhbGl6
ZSIuDQo+Pj4+ICogV2hvbGUgaW1wbGVtZW50YXRpb24gY2hhbmdlZCBiZWNhdXNlIGxhc3QgdmVy
c2lvbiBpcyB3cm9uZy4NCj4+Pj4gICBUaGlzIHZlcnNpb24gZ2V0cyB0YXJnZXQgaGFuZGxlciBh
bmQgcHJldmlvdXMgaGFuZGxlciBmcm9tIHZwY2ktPmhhbmRsZXJzLCB0aGVuIHJlbW92ZSB0aGUg
dGFyZ2V0Lg0KPj4+PiAqIE5vdGU6IGEgY2FzZSBpbiBmdW5jdGlvbiB2cGNpX2V4dF9jYXBhYmls
aXR5X21hc2soKSBuZWVkcyB0byBiZSBkaXNjdXNzZWQsDQo+Pj4+ICAgYmVjYXVzZSBpdCBtYXkg
Y2hhbmdlIHRoZSBvZmZzZXQgb2YgbmV4dCBjYXBhYmlsaXR5IHdoZW4gdGhlIG9mZnNldCBvZiB0
YXJnZXQNCj4+Pj4gICBjYXBhYmlsaXR5IGlzIDB4MTAwVSh0aGUgZmlyc3QgZXh0ZW5kZWQgY2Fw
YWJpbGl0eSksIG15IGltcGxlbWVudGF0aW9uIGlzIGp1c3QgdG8NCj4+Pj4gICBpZ25vcmUgYW5k
IGxldCBoYXJkd2FyZSB0byBoYW5kbGUgdGhlIHRhcmdldCBjYXBhYmlsaXR5Lg0KPj4+Pg0KPj4+
PiB2MS0+djIgY2hhbmdlczoNCj4+Pj4gKiBSZW1vdmVkIHRoZSAicHJpb3JpdGllcyIgb2YgaW5p
dGlhbGl6aW5nIGNhcGFiaWxpdGllcyBzaW5jZSBpdCBpc24ndCB1c2VkIGFueW1vcmUuDQo+Pj4+
ICogQWRkZWQgbmV3IGZ1bmN0aW9uIHZwY2lfY2FwYWJpbGl0eV9tYXNrKCkgYW5kIHZwY2lfZXh0
X2NhcGFiaWxpdHlfbWFzaygpIHRvDQo+Pj4+ICAgcmVtb3ZlIGZhaWxlZCBjYXBhYmlsaXR5IGZy
b20gbGlzdC4NCj4+Pj4gKiBDYWxsZWQgdnBjaV9tYWtlX21zaXhfaG9sZSgpIGluIHRoZSBlbmQg
b2YgaW5pdF9tc2l4KCkuDQo+Pj4+DQo+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4gSmlxaWFuIENo
ZW4uDQo+Pj4+IC0tLQ0KPj4+PiAgeGVuL2RyaXZlcnMvdnBjaS92cGNpLmMgICAgfCA3OSArKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KPj4+PiAgeGVuL2luY2x1ZGUveGVu
L3BjaV9yZWdzLmggfCAgMSArDQo+Pj4+ICAyIGZpbGVzIGNoYW5nZWQsIDgwIGluc2VydGlvbnMo
KykNCj4+Pj4NCj4+Pj4gZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jIGIveGVu
L2RyaXZlcnMvdnBjaS92cGNpLmMNCj4+Pj4gaW5kZXggZjk3YzdjYzQ2MGEwLi44ZmY1MTY5YmRk
MTggMTAwNjQ0DQo+Pj4+IC0tLSBhL3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jDQo+Pj4+ICsrKyBi
L3hlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jDQo+Pj4+IEBAIC0xODMsNiArMTgzLDgzIEBAIHN0YXRp
YyB2b2lkIHZwY2lfY2FwYWJpbGl0eV9tYXNrKHN0cnVjdCBwY2lfZGV2ICpwZGV2LA0KPj4+PiAg
ICAgIHhmcmVlKG5leHRfcik7DQo+Pj4+ICB9DQo+Pj4+ICANCj4+Pj4gK3N0YXRpYyBzdHJ1Y3Qg
dnBjaV9yZWdpc3RlciAqdnBjaV9nZXRfcHJldmlvdXNfZXh0X2NhcF9yZWdpc3Rlcg0KPj4+PiAr
ICAgICAgICAgICAgICAgIChzdHJ1Y3QgdnBjaSAqdnBjaSwgY29uc3QgdW5zaWduZWQgaW50IG9m
ZnNldCkNCj4+Pj4gK3sNCj4+Pj4gKyAgICB1aW50MzJfdCBoZWFkZXI7DQo+Pj4+ICsgICAgdW5z
aWduZWQgaW50IHBvcyA9IFBDSV9DRkdfU1BBQ0VfU0laRTsNCj4+Pj4gKyAgICBzdHJ1Y3QgdnBj
aV9yZWdpc3RlciAqcjsNCj4+Pj4gKw0KPj4+PiArICAgIGlmICggb2Zmc2V0IDw9IFBDSV9DRkdf
U1BBQ0VfU0laRSApDQo+Pj4+ICsgICAgICAgIHJldHVybiBOVUxMOw0KPj4+PiArDQo+Pj4+ICsg
ICAgciA9IHZwY2lfZ2V0X3JlZ2lzdGVyKHZwY2ksIHBvcywgNCk7DQo+Pj4+ICsgICAgQVNTRVJU
KHIpOw0KPj4+PiArDQo+Pj4+ICsgICAgaGVhZGVyID0gKHVpbnQzMl90KSh1aW50cHRyX3Qpci0+
cHJpdmF0ZTsNCj4+Pj4gKyAgICBwb3MgPSBQQ0lfRVhUX0NBUF9ORVhUKGhlYWRlcik7DQo+Pj4+
ICsgICAgd2hpbGUgKCBwb3MgPiBQQ0lfQ0ZHX1NQQUNFX1NJWkUgJiYgcG9zICE9IG9mZnNldCAp
DQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICByID0gdnBjaV9nZXRfcmVnaXN0ZXIodnBjaSwg
cG9zLCA0KTsNCj4+Pj4gKyAgICAgICAgQVNTRVJUKHIpOw0KPj4+PiArICAgICAgICBoZWFkZXIg
PSAodWludDMyX3QpKHVpbnRwdHJfdClyLT5wcml2YXRlOw0KPj4+PiArICAgICAgICBwb3MgPSBQ
Q0lfRVhUX0NBUF9ORVhUKGhlYWRlcik7DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAg
aWYgKCBwb3MgPD0gUENJX0NGR19TUEFDRV9TSVpFICkNCj4+Pj4gKyAgICAgICAgcmV0dXJuIE5V
TEw7DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXR1cm4gcjsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiAr
c3RhdGljIHZvaWQgdnBjaV9leHRfY2FwYWJpbGl0eV9tYXNrKHN0cnVjdCBwY2lfZGV2ICpwZGV2
LA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHVuc2ln
bmVkIGludCBjYXApDQo+Pj4+ICt7DQo+Pj4+ICsgICAgY29uc3QgdW5zaWduZWQgaW50IG9mZnNl
dCA9IHBjaV9maW5kX2V4dF9jYXBhYmlsaXR5KHBkZXYtPnNiZGYsIGNhcCk7DQo+Pj4+ICsgICAg
c3RydWN0IHZwY2lfcmVnaXN0ZXIgKnJtLCAqcHJldl9yOw0KPj4+PiArICAgIHN0cnVjdCB2cGNp
ICp2cGNpID0gcGRldi0+dnBjaTsNCj4+Pj4gKyAgICB1aW50MzJfdCBoZWFkZXIsIHByZV9oZWFk
ZXI7DQo+Pj4NCj4+PiBNYXliZSBzYW5pdHkgY2hlY2sgdGhhdCBvZmZzZXQgaXMgY29ycmVjdD8N
Cj4+IFdoYXQgZG8geW91IG1lYW4gc2FuaXR5IGNoZWNrPw0KPj4gRG8gSSBuZWVkIHRvIGFkZCBz
b21ldGhpbmc/DQo+IA0KPiBJIHdvdWxkIHByb2JhYmx5IGRvIHNvbWV0aGluZyBsaWtlOg0KPiAN
Cj4gaWYgKCAhb2Zmc2V0ICkNCj4gew0KPiAgICAgQVNTRVJUX1VOUkVBQ0hBQkxFKCk7DQo+ICAg
ICByZXR1cm47DQo+IH0NCkhvdyBhYm91dCBhZGRpbmcgY2hlY2s/DQoNCiAgICBpZiAoIG9mZnNl
dCA8IFBDSV9DRkdfU1BBQ0VfU0laRSApDQogICAgew0KICAgICAgICBBU1NFUlRfVU5SRUFDSEFC
TEUoKTsNCiAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQogICAgfQ0KDQpEbyBJIG5lZWQgdG8gYWRk
IHNpbWlsYXIgY2hlY2sgaW4gdnBjaV9jYXBhYmlsaXR5X21hc2soKT8NCg0KPiANCj4gVGhhbmtz
LCBSb2dlci4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Wed May 07 09:05:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 09:05:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978379.1365179 (Exim 4.92)
	(envelope-from )
	id 1uCaii-0007TW-J6; Wed, 07 May 2025 09:05:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978379.1365179; Wed, 07 May 2025 09: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 1uCaii-0007TP-GG; Wed, 07 May 2025 09:05:40 +0000
Received: by outflank-mailman (input) for mailman id 978379;
 Wed, 07 May 2025 09:05:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCaih-0007TI-R4
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 09:05:39 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6ef1d567-2b22-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 11:05:34 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-39c0dfba946so5536977f8f.3
 for ; Wed, 07 May 2025 02:05:34 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099ae0cd6sm16118351f8f.5.2025.05.07.02.05.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 02: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" 
X-Inumbo-ID: 6ef1d567-2b22-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746608733; x=1747213533; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=gjmEDZhNPW31cGpCRagy/48bySkSEmiZ9p0xXlJXBK4=;
        b=n1A1g5d6DxLueq5ij53W8NpJMftXqHl2ppn9Yc8Jsd3D3HXmvL0QLnau1HVjdQWhwy
         kiT7fqvPphpHXuT14n26g4JUo6NWmg1ASPNXGKt/e+uI+yvPCyICIVaOQRvlFtVo3fKq
         ZZp7nds8CjgqgMbpJwGKSrD5a1xvhMHRW2kNY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746608733; x=1747213533;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=gjmEDZhNPW31cGpCRagy/48bySkSEmiZ9p0xXlJXBK4=;
        b=IOQ6xJHw8LAe1//A65LRVjx4n1nJFwJ4udezpoTHWuDvU8M7fjRXFO+RRGpuyDd4Ee
         m/dvdhgn/WsSCoU+aOAvGuNoJ3oD/8vB8QKdsu0fXNaRBrvTeCoGPTKH0QPsoiU6Ng+L
         iME0T5Ikfstdw0vgiNLE26rOdx7aCxKqDjd4AlmiJ9U7A0MXI1SPdI5Uv+c6U860mlN9
         R9ne+NOHslbP7cLVG1TpjH37/HeMVUENgRtn5GV5NNkwGMeNiscODDUlq0JdCfHvSCJ4
         J1cxDzY5xR9fYH94iYkrkzlMLJC0e69kDYP7mL3/4zxMzLcVId6urhgKrbcZMrv3QIUG
         oVIA==
X-Gm-Message-State: AOJu0Yx00AriKYaV/WT4pLyMlYYQXOLlRKHq2PFhnJjN6I6RrPJhjyvk
	nW3yiUilgweXM3QNzcyXh7SloqIlKHVXz3iNzgyMIor1ENKiPWlnKmBakAVcaXQ=
X-Gm-Gg: ASbGncuSPTxGPWq3GXJaf25n3WkHvkTvgr6JELkLeGxZ7h5rQczR2daTXNtts1yLI8J
	HeCaS9+yfZbXYjJRNHI7TZdYMyeh9Kl7D445NgzqeesHCwX0CKPZcDOuKfOCEZpEAJ7q1+wflmC
	xmautFGL1JPWODL6oxMi3Ut/MYJCpsbkbCoHbKzodXvchylGKKdEgrt7uEyYaO3yTa4uoFpimSa
	o5gqJ7hA4XI7SSQHpdo8j+P95S34yxsk3PmcEGq0mim2qtyCsTmaqtWDVKNbYI94F4Kj2dHH4BU
	n1OVnOLEsUi16MVXPGFJmmKcVAjFR5MWqUlXRUxWctl1og==
X-Google-Smtp-Source: AGHT+IFIYyGpBz2rQQyxyUKoSjfoZVJmbcQCxIqGZMo8+jaAKHym8vfogaVmY6b51zMU0v0WuMTvBg==
X-Received: by 2002:a05:6000:2ab:b0:39d:724f:a8cd with SMTP id ffacd0b85a97d-3a0b4a24475mr2057783f8f.35.1746608733409;
        Wed, 07 May 2025 02:05:33 -0700 (PDT)
Date: Wed, 7 May 2025 11:05:32 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v3 07/11] vpci: Hide extended capability when it fails to
 initialize
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-8-Jiqian.Chen@amd.com>
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 07, 2025 at 08:49:46AM +0000, Chen, Jiqian wrote:
> On 2025/5/7 16:09, Roger Pau Monné wrote:
> > On Wed, May 07, 2025 at 07:26:21AM +0000, Chen, Jiqian wrote:
> >> On 2025/5/7 00:21, Roger Pau Monné wrote:
> >>> On Mon, Apr 21, 2025 at 02:18:59PM +0800, Jiqian Chen wrote:
> >>>> When vpci fails to initialize a extended capability of device for dom0,
> >>>> it just return error instead of catching and processing exception. That
> >>>> makes the entire device unusable.
> >>>>
> >>>> So, add new a function to hide extended capability when initialization
> >>>> fails. And remove the failed extended capability handler from vpci
> >>>> extended capability list.
> >>>>
> >>>> Signed-off-by: Jiqian Chen 
> >>>> ---
> >>>> cc: "Roger Pau Monné" 
> >>>> ---
> >>>> v2->v3 changes:
> >>>> * Separated from the last version patch "vpci: Hide capability when it fails to initialize".
> >>>> * Whole implementation changed because last version is wrong.
> >>>>   This version gets target handler and previous handler from vpci->handlers, then remove the target.
> >>>> * Note: a case in function vpci_ext_capability_mask() needs to be discussed,
> >>>>   because it may change the offset of next capability when the offset of target
> >>>>   capability is 0x100U(the first extended capability), my implementation is just to
> >>>>   ignore and let hardware to handle the target capability.
> >>>>
> >>>> v1->v2 changes:
> >>>> * Removed the "priorities" of initializing capabilities since it isn't used anymore.
> >>>> * Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
> >>>>   remove failed capability from list.
> >>>> * Called vpci_make_msix_hole() in the end of init_msix().
> >>>>
> >>>> Best regards,
> >>>> Jiqian Chen.
> >>>> ---
> >>>>  xen/drivers/vpci/vpci.c    | 79 ++++++++++++++++++++++++++++++++++++++
> >>>>  xen/include/xen/pci_regs.h |  1 +
> >>>>  2 files changed, 80 insertions(+)
> >>>>
> >>>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> >>>> index f97c7cc460a0..8ff5169bdd18 100644
> >>>> --- a/xen/drivers/vpci/vpci.c
> >>>> +++ b/xen/drivers/vpci/vpci.c
> >>>> @@ -183,6 +183,83 @@ static void vpci_capability_mask(struct pci_dev *pdev,
> >>>>      xfree(next_r);
> >>>>  }
> >>>>  
> >>>> +static struct vpci_register *vpci_get_previous_ext_cap_register
> >>>> +                (struct vpci *vpci, const unsigned int offset)
> >>>> +{
> >>>> +    uint32_t header;
> >>>> +    unsigned int pos = PCI_CFG_SPACE_SIZE;
> >>>> +    struct vpci_register *r;
> >>>> +
> >>>> +    if ( offset <= PCI_CFG_SPACE_SIZE )
> >>>> +        return NULL;
> >>>> +
> >>>> +    r = vpci_get_register(vpci, pos, 4);
> >>>> +    ASSERT(r);
> >>>> +
> >>>> +    header = (uint32_t)(uintptr_t)r->private;
> >>>> +    pos = PCI_EXT_CAP_NEXT(header);
> >>>> +    while ( pos > PCI_CFG_SPACE_SIZE && pos != offset )
> >>>> +    {
> >>>> +        r = vpci_get_register(vpci, pos, 4);
> >>>> +        ASSERT(r);
> >>>> +        header = (uint32_t)(uintptr_t)r->private;
> >>>> +        pos = PCI_EXT_CAP_NEXT(header);
> >>>> +    }
> >>>> +
> >>>> +    if ( pos <= PCI_CFG_SPACE_SIZE )
> >>>> +        return NULL;
> >>>> +
> >>>> +    return r;
> >>>> +}
> >>>> +
> >>>> +static void vpci_ext_capability_mask(struct pci_dev *pdev,
> >>>> +                                     const unsigned int cap)
> >>>> +{
> >>>> +    const unsigned int offset = pci_find_ext_capability(pdev->sbdf, cap);
> >>>> +    struct vpci_register *rm, *prev_r;
> >>>> +    struct vpci *vpci = pdev->vpci;
> >>>> +    uint32_t header, pre_header;
> >>>
> >>> Maybe sanity check that offset is correct?
> >> What do you mean sanity check?
> >> Do I need to add something?
> > 
> > I would probably do something like:
> > 
> > if ( !offset )
> > {
> >     ASSERT_UNREACHABLE();
> >     return;
> > }
> How about adding check?
> 
>     if ( offset < PCI_CFG_SPACE_SIZE )
>     {
>         ASSERT_UNREACHABLE();
>         return -EINVAL;
>     }

That would work also, however note that pci_find_ext_capability()
should only return 0 if the capability is not found, and other callers
already assume that != 0 implies a valid position.  I will simply
check !offset as that's inline with all the other checks Xen does for
return values of pci_find_ext_capability().

> Do I need to add similar check in vpci_capability_mask()?

Possibly - seems like I didn't comment on that one, sorry.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 07 09:19:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 09:19:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978390.1365190 (Exim 4.92)
	(envelope-from )
	id 1uCaw4-0000wS-NO; Wed, 07 May 2025 09:19:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978390.1365190; Wed, 07 May 2025 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 1uCaw4-0000wL-JP; Wed, 07 May 2025 09:19:28 +0000
Received: by outflank-mailman (input) for mailman id 978390;
 Wed, 07 May 2025 09:19:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCaw3-0000wF-Jk
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 09:19:27 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2062b.outbound.protection.outlook.com
 [2a01:111:f403:200a::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5b758a57-2b24-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 11:19:21 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 BY5PR12MB4243.namprd12.prod.outlook.com (2603:10b6:a03:20f::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Wed, 7 May
 2025 09:19:13 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Wed, 7 May 2025
 09:19: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" 
X-Inumbo-ID: 5b758a57-2b24-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eZuCAr0ZYvR9InAzCG8m/B35zjGHIb5p//tDEY4pBo90CCwtgNIbevVQKwru+ZtTrAYvsL1s+7iWyhJdEOtG8ipQDQjH3dzHc4p28laUdv+aBpA0vEG45TbVN14s44XVopc1Z/Uz9xTAAeX45BlLzx9Iw3eh3P6CKQUrQJU4gY61VUT+F6JuO95NJ0tNxnPCDSvkHm4gFO1XZfFEqSjYA9AeY4Agvzn37F3Rj1lkLH2Ks3UAly8DSYAbu6W7PhHHTLVYPZsAE5yG2RhtjFdXpm63N6K6tWsdMQFYq62WjbAN1hjs/F9NAljLGbcWfkzXztgBsrFTiGqbrE4eQTc1ug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XelD2B4pXLO/pscd3ozgXouGCQgqJpN16QfhWbtxGSs=;
 b=rOQRr6d1HibGWh1sFGK1TTkWe3J6Rw2GLvQcnxjRW/XVcWSvsndMRNpq2nsIvP5tjA+fnSiJbpic2K1RKGQpTbnQ6luEmSWTdpHxsD1up0hsqxcCdi7tCvVZRLjxD89t47MHt05IAINJsfObhhAYzENiDtZ2IaqaZgxT04CTiWQvgBpU3LyUB9THFUygZhQuXy3Bepqmr1FGDgajs35KqRmBfyb1BxGzfMmkqMAvcn3I0//tn/EdheV6JbgwlpsaYk8ckcNa+nGcWUjUzvZj9Ecs90p9tDz4fgFkhedoubtWtLzosAR3oN+JvjH78LFU3YMWPVuB64qY0dYE5KI2kA==
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=XelD2B4pXLO/pscd3ozgXouGCQgqJpN16QfhWbtxGSs=;
 b=YmhVaZQTLJspqVo36P0Be4/gl4EYIIdP8IzwktzVrZZgYDNiWg3pUThgbHFj7ZYJjSLRf4t8yynOn68D69hbzOEUOLX2Yi+iHR12pA0Bw3bXTaiOd7Gyv1RI8Esnb/8e0SMcwlfndx6ZskBNJ4fEsHbiRuOY3IZ6EUNY9VW5uJE=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 09/15] xen/x86: introduce a new amd cppc driver for
 cpufreq scaling
Thread-Topic: [PATCH v4 09/15] xen/x86: introduce a new amd cppc driver for
 cpufreq scaling
Thread-Index: AQHbrRCsgX0DHfsxBEGtMOCcDZZeSLO6zAoAgAwkvoA=
Date: Wed, 7 May 2025 09:19:13 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-10-Penny.Zheng@amd.com>
 <448d6036-09ad-4505-800d-47606e8a3274@suse.com>
In-Reply-To: <448d6036-09ad-4505-800d-47606e8a3274@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=2e500a0c-1fb0-47c4-85e0-2cb5a0521676;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-07T09:19:04Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|BY5PR12MB4243:EE_
x-ms-office365-filtering-correlation-id: 766b0b1a-6001-4c56-ada5-08dd8d483b8e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?TXJVQ1c3S2szeXM2N096dlNFTnlJZTdNOGJjVDBmSk9OVmUyZHJBYUR2WGVB?=
 =?utf-8?B?Qk1zUDJIckwwWW05cEF1SnZqSk91WVZjcG9SbGwzeWtxNi9xc0cwblNVRmdU?=
 =?utf-8?B?V3JCUm1aQ3lGQWxxejhjUGRET2ltaDlKL2NXamgxd2s4YWRCZitaY1VQc3k4?=
 =?utf-8?B?c2N2NklsWk4wUjRsRlV6bHF5dDdrMklSd0JxWnlQeUNhWlpFU205L3Y0ZUNi?=
 =?utf-8?B?amo4c2t3VDRROHBIditZaDB3MG9qeS94YXp0dEhNaWlqcXpxSFVXYUpqVnhF?=
 =?utf-8?B?Uzh5OEZ1SDlySHpwL1o1Sm1xQU5McUxJL3VPSjlvNHVja1BFOEVBQys0ZTFQ?=
 =?utf-8?B?cyt2OHdhb2FMbnBZaVpsaWNUS1NzbEw2Vm1aaDhSTzB6Zk1UV0R5VVRha2Yx?=
 =?utf-8?B?YkVLRmlZUnRVTENCUi9rdkJLTTAzNlA4cGsyckZxbmViYkUxdjdKTVBNdWtx?=
 =?utf-8?B?N1hZL05yL0dIRnVJemJ1MnZDdVF6M0dncWQyeG40NXZDVXp6REU3aGxOSTF2?=
 =?utf-8?B?UjBOMEpTZmkxSXUrMzV0Uk9mSndESkY3d2ZkcmpNdlRzVmtjQ3JjVCtreE5D?=
 =?utf-8?B?a24vYzZJWmthNHppZjRJZkN6eXlQa29EejhvN1kyZXdkVU8vbzdadkdnY2Na?=
 =?utf-8?B?NmxkanVqcElkcTVNd2txeklNVzVsM2hycFgvMmpnODBWby82NHF6OElrdEdt?=
 =?utf-8?B?SEJXRlJtcjlXT2diK29oUEJrQmhqSzBOM1lERC84eTlwWEN5ZFBVVUlocG9T?=
 =?utf-8?B?eEtDeWkvenF0aHNSTDVyZER6L2FIaFJaMXVpT3ZrdTdUTlhTeGppbzJMV1BS?=
 =?utf-8?B?Nk44QjV5UmlYUnJaY1N3czhyeVJhMVdHSThpNC9jTzVuT1RjWmIwdXllVDdM?=
 =?utf-8?B?ZkM1V1VocEU5dTFSdWszeFM4VlVOc2VQK1ozWjhuRVIwK3c4d1A0NnR3eDJ1?=
 =?utf-8?B?OTBRQWtRU1JXOHhXSHVsVEV0RU5lSUNYNSsvaGNadGtKMDRhRGE1MHZHaUdX?=
 =?utf-8?B?czhKTEI4ZkJMV0xTbW1YWExaOUMxUmJwN1hVM3dzZWp1OWVGTERpa0FUdDNK?=
 =?utf-8?B?YjdEVHU5Wkxlc1FTT3o4aEVlQk1RMWdFRHh2bU0vbm9zKzlvTnB1VjhnVGVV?=
 =?utf-8?B?WEpkVEN5blFkNzQyWHVtTFNoeFZySWFZSk5rUUJqRUIwQXNKWXJVUHJvWVMy?=
 =?utf-8?B?SWpYTDhrbWNOT1dNSFdiempsV1VHS1pocGxqQlpmNUlYRjU5RTJlU3lJZ2JX?=
 =?utf-8?B?UUFlczdkZHE5eG5YL0dvY2dHRElIcUlueDJJZnBBbkVQWXpNOUVOSElNaVZv?=
 =?utf-8?B?cUtEVVJnL0dqdTRnWXVYODBoWWxVYWRGSVFZOWtvRG96MzhzMnZrMmZ0bnIw?=
 =?utf-8?B?ck1kZllyQmEwaXY4emRWbEc3K2sxWUUxdk4wMDB5YW5qc1VsUm5nS1g2Skhl?=
 =?utf-8?B?TXlhYjR3S01KWUVuUFJPbEZBSjRaSkxwdWtObWxROFRsN1R6OFB0YldPL1Ru?=
 =?utf-8?B?cThvMjRPcktRampnNkp1NTlxNVVxMU9qQ0lMUVdrMkNwQTlseGRLTDJPYUxa?=
 =?utf-8?B?bHNob1Zubkt3N0V0RzlkZEs2ZmZUZnlsVDFNMlc4Z0hsMU1teHZyK05WQklv?=
 =?utf-8?B?U2tOR3luMVl4a3hRZ0Z0a0Fka2FwYXQ5bkJwanR6cTZFQ3NpWENoQXhlTTE5?=
 =?utf-8?B?MzU0ajkvQXY1eGNIL1VYMzU2a3JtRDZEbU5VM0xoTFBBTlkrU25wb2RvNDB1?=
 =?utf-8?B?VGJjREdvVE5HcGV6cXo3ZEtNcDk3aW5aZDNlcEVzL1NWMUF1bE5oTzJuK3R2?=
 =?utf-8?B?MGxNM2FHSk1DN3YxaStZdGJlaVIzN1VvaC9SVjdPdGxFOENYUkx1SUpNaEhB?=
 =?utf-8?B?cjJaODZlTDdtUE9MTWNNMDZ0WW5WVmZnYXBLVkhmSGRhMEdCNENGek9tRUtI?=
 =?utf-8?B?Nmh0S2ZhcHJ6UFNYanBCYWhzUlZsODJWMkMyUjE4SW5SbDhwY2ZRTE1naytU?=
 =?utf-8?Q?AEFQVEuwj1f8B9nEdoy7g8JdZdG/ec=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?NmdFT1A2Si9HT2RheEtyU2RwVzM5MWdoR2g5cUNIaEJ3ZHVVSTZSSTl1ZGFE?=
 =?utf-8?B?NGNMeElWNE8vOXpBR2dEY096dHV2YVNmWkNZZE5mOEFoZ2daNDRTZWNPWFV0?=
 =?utf-8?B?K09zbW92YWZ6Zi9qbEJrS1BrNER5d1YvdENPcytoVHMwRWRrQ2M0eE9nR2ZW?=
 =?utf-8?B?YXpOWmswQTd3bzJvSW55WndoT1l6ZmdFejhkYkhMWnhvRHU4SjJGbDJJYmNS?=
 =?utf-8?B?K1R0dCtUVHZFQTBncU1mUTRJZ1k2dnZBU0Y0QUVwSXYzMHBHajRQR3lQUXcx?=
 =?utf-8?B?N3BzenpzNHArWkZVTE9xK01obFpjODZvTWZlZ3lrNHNVQzdPMDlTTnhkZnhl?=
 =?utf-8?B?RlpTbWlTTFJiSVlqa3h3a2phM2FQSWhvN1dBb1RCUFJOQ3REdCtCL01PYVNh?=
 =?utf-8?B?SVVEYXZLSnFnY0t5NHJjREJkNTQ1bFRXTWFQYlZFZWR4VmRsN09sYnhscWZx?=
 =?utf-8?B?NlhlZVY2M29Belo5d3NWaGZQcExmTEhTa1daZDZNWlA0anBKTHU3ckRHY2pH?=
 =?utf-8?B?cC9SR09FeDNOUXdFKzBvZ0pyTWt4cFRGMm1WcEs5S3hNdXBTeG9wYkdkbTM3?=
 =?utf-8?B?c3ZvRWdQQTQyNjl5SGRMK25uNjNDSXB5Znd0NU1KbzN2dUx0UzlrTHVRYXVH?=
 =?utf-8?B?MlVneFFLbngvTEtzcldvT20vcU95T3RYaUc0ZU55a0tKRVp6N3BBbHFtV0tk?=
 =?utf-8?B?VDVneXNDTnZzRXROc1c2Tk5BVXdubTJYSmQvYlJRZlRCMmRGVWZtRGhEZHFk?=
 =?utf-8?B?emxkQXdOY1A3aHJiNzFGb3hJVGhsb1pSdXkzUk9YOUJjM3MrSFJnaEw2aXRk?=
 =?utf-8?B?REo5OHBNY29La2d2Y1ZTVnBOOEszc3RZcHVybmtFTW1MbEYwSnRoeE53bEZF?=
 =?utf-8?B?amFHL2dhdGRvdUQ0bS9SWlRVVjVHWmNmN0trOXFxK0Jvd2lxWTZnM0hBZFpH?=
 =?utf-8?B?SkM0TnhjSzlIbDFOVmtSQjN6OGhuZHJoSlloNnNtREhZcmRXZ3padTVpR0tQ?=
 =?utf-8?B?NlQwY1JkNjNCZXpYNEYwUDBNR0k2cXBsaXhMa1lhSWpwMDlEWkhZRjVPMkM2?=
 =?utf-8?B?bGtBRUdzYU9Nblp1OUI2dGg1RjJBY3k3MG1scGtHaEs2ODczSFlXK0NZSzRL?=
 =?utf-8?B?MlFFakV3Q1lRbHJXNnh1eXpXNGdEdHhWUXR0Tk5ud2FFMzZCZjRoeURCbWVV?=
 =?utf-8?B?NGpINFdYN2ZFU1RxUTczUEhUb2RCejNIMEk4VXlXQ2gzZjVoUjhuVXlKcmxC?=
 =?utf-8?B?VUZHK1FvZ0FaMnJQaHpSNEVSM1JKN2FXRlcyNXZ3MmJDem1DMkRwWndCZEdP?=
 =?utf-8?B?a3FpUlA5bXc3Z1R1dmJKbGFxZ0JyUmRNaVpqZlFHY0Nia1h1UnBpNzdYT0NR?=
 =?utf-8?B?Tk53WlMxMHArMExkWHBOU1YrMVp0YWtqTWNSOXo1TUFwemo5aFM5aVJWS050?=
 =?utf-8?B?d1BVdFdFMnhTZzA3SXVqS0duTmowSlVkbmZpNWIvQllxUllvWUdrUEZLNXZK?=
 =?utf-8?B?b3hDVC9PNHJtamxvVnpvdUFNRWFnMDM0S3RmblNDZVRYV2JrTmJ2ZHpRYlN0?=
 =?utf-8?B?QTJ3TldOUGZqSlc0T1VkYTNQV0txb3VMM29rSFNsdjU3T2wxdjdZbWtCNVlN?=
 =?utf-8?B?UjVkZmF4dDUzM0ZEZjQ5NW15Qkd5cFZpZ0RJQ2xvRGlxTjlPTVI0WTVITjRH?=
 =?utf-8?B?NkIxa0lSL0kweGNLZDBaMTlNVmltT0RueVlOSEppalVXeTE5Rlg0U3ZMOTM3?=
 =?utf-8?B?bG1YUTRkbmltYk8rL1NIT0krRzBMenFnL2pWdXV1NEVCNzNVdUlCcXA3N00y?=
 =?utf-8?B?cmoxdkt5b1NqVHhDS3YxZWovMXJFcHcwWWdmUXBRWU5WenY4a2tVT3dnYUFL?=
 =?utf-8?B?RjRxa0pkZlAvRTRHbmdFKzBZK1h6QlV1bVRyVEF2cGVRU1QzREFkRmkyTWFH?=
 =?utf-8?B?T21tWStnT3lsYytBckFTazdUelVuejhuUFdFNkp5TVcrUWloV2NsdXJSRDF2?=
 =?utf-8?B?TEVxQkN0SXc2RWlaZDRXeHo2eDJtSHFYOTBPcGhMR3M5bnFPR0F4NlllM1A1?=
 =?utf-8?B?UFVoYitXSmd2QWUvR3NXMkJIQ2tvejFxWS9pcmxHa3pDRmdGNWtjM0kyU2ht?=
 =?utf-8?Q?YKnM=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 766b0b1a-6001-4c56-ada5-08dd8d483b8e
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 09:19:13.2537
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: D/J7IqeXfJr6UvkGh9LpK3sRIUwuErAKzrNchZV5hNqhzUDXyMgQjO4xw4jigce+iwWYKuKNO2EoikogO6D3bQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4243

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAy
OSwgMjAyNSAxMDoyOSBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29t
Pg0KPiBDYzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbmRyZXcgQ29vcGVyDQo+
IDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPjsgUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+OyB4ZW4tDQo+IGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1Ympl
Y3Q6IFJlOiBbUEFUQ0ggdjQgMDkvMTVdIHhlbi94ODY6IGludHJvZHVjZSBhIG5ldyBhbWQgY3Bw
YyBkcml2ZXIgZm9yDQo+IGNwdWZyZXEgc2NhbGluZw0KPg0KPiBPbiAxNC4wNC4yMDI1IDA5OjQw
LCBQZW5ueSBaaGVuZyB3cm90ZToNCj4gPiAtLS0gYS94ZW4vYXJjaC94ODYvYWNwaS9jcHVmcmVx
L2FtZC1jcHBjLmMNCj4gPiArKysgYi94ZW4vYXJjaC94ODYvYWNwaS9jcHVmcmVxL2FtZC1jcHBj
LmMNCj4gPiArLyoNCj4gPiArICogSWYgQ1BQQyBsb3dlc3RfZnJlcSBhbmQgbm9taW5hbF9mcmVx
IHJlZ2lzdGVycyBhcmUgZXhwb3NlZCB0aGVuIHdlDQo+ID4gK2Nhbg0KPiA+ICsgKiB1c2UgdGhl
bSB0byBjb252ZXJ0IHBlcmYgdG8gZnJlcSBhbmQgdmljZSB2ZXJzYS4gVGhlIGNvbnZlcnNpb24g
aXMNCj4gPiArICogZXh0cmFwb2xhdGVkIGFzIGFuIGxpbmVhciBmdW5jdGlvbiBwYXNzaW5nIGJ5
IHRoZSAyIHBvaW50czoNCj4gPiArICogIC0gKExvdyBwZXJmLCBMb3cgZnJlcSkNCj4gPiArICog
IC0gKE5vbWluYWwgcGVyZiwgTm9taW5hbCBmcmVxKQ0KPiA+ICsgKi8NCj4gPiArc3RhdGljIGlu
dCBhbWRfY3BwY19raHpfdG9fcGVyZihjb25zdCBzdHJ1Y3QgYW1kX2NwcGNfZHJ2X2RhdGEgKmRh
dGEsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IGZy
ZXEsIHVpbnQ4X3QgKnBlcmYpIHsNCj4gPiArICAgIGNvbnN0IHN0cnVjdCB4ZW5fcHJvY2Vzc29y
X2NwcGMgKmNwcGNfZGF0YSA9IGRhdGEtPmNwcGNfZGF0YTsNCj4gPiArICAgIHVpbnQ2NF90IG11
bCwgZGl2Ow0KPiA+ICsgICAgaW50IG9mZnNldCA9IDAsIHJlczsNCj4gPiArDQo+ID4gKyAgICBp
ZiAoIGZyZXEgPT0gKGNwcGNfZGF0YS0+Y3BjLm5vbWluYWxfbWh6ICogMTAwMCkgKQ0KPg0KPiBJ
J20gcHJldHR5IHN1cmUgSSBjb21tZW50ZWQgb24gdGhpcyBiZWZvcmU6IFRoZSBleHByZXNzaW9u
IGhlcmUgX3N1Z2dlc3RzXyB0aGF0DQo+ICJmcmVxIiBpcyBpbiBrSHosIGJ1dCB0aGF0J3Mgbm90
IGJlaW5nIG1hZGUgZXhwbGljaXQgYW55d2hlcmUuDQo+DQoNClNvcnJ5LCBJIG1heSBvdmVybG9v
aywgYW5kIEknbGwgYmUgbW9yZSBjYXJlZnVsLg0KSSBoYXZlIGNsYXJpZmllZCBpdCBpbiB0aGUg
ZnVuY3Rpb24gdGl0bGUsIGFuZCBtYXliZSBpdCdzIG5vdCBlbm91Z2guIEknbGwgY2hhbmdlIHRo
ZSBwYXJhbWV0ZXINCm5hbWUgZnJvbSAiZnJlcSIgdG8gImZyZXFfa2h6IiB0byBiZSBtb3JlIGV4
cGxpY2l0Lg0KDQo+ID4gKyAgICB7DQo+ID4gKyAgICAgICAgKnBlcmYgPSBkYXRhLT5jYXBzLm5v
bWluYWxfcGVyZjsNCj4gPiArICAgICAgICByZXR1cm4gMDsNCj4gPiArICAgIH0NCj4gPiArDQo+
ID4gKyAgICBpZiAoIGZyZXEgPT0gKGNwcGNfZGF0YS0+Y3BjLmxvd2VzdF9taHogKiAxMDAwKSAp
DQo+ID4gKyAgICB7DQo+ID4gKyAgICAgICAgKnBlcmYgPSBkYXRhLT5jYXBzLmxvd2VzdF9wZXJm
Ow0KPiA+ICsgICAgICAgIHJldHVybiAwOw0KPiA+ICsgICAgfQ0KPg0KPiBIb3cgbGlrZWx5IGlz
IGl0IHRoYXQgdGhlc2UgdHdvIGVhcmx5IHJldHVybiBwYXRocyBhcmUgdGFrZW4sIHdoZW4gdGhl
IGluY29taW5nDQo+ICJmcmVxIiBpcyAyNSBvciA1IE1IeiBncmFudWxhcj8gSU9XIC0gaXMgaXQg
cmVsZXZhbnQgdG8gc2hvcnRjdXQgdGhlc2UgdHdvIGNhc2VzPw0KPg0KDQpTb3JyeSwgSSBtYXkg
bm90IHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbiBoZXJlLg0KQW5zd2VyaW5nICIgSG93IGxpa2Vs
eSBpcyBpdCB0aGF0IHRoZXNlIHR3byBlYXJseSByZXR1cm4gcGF0aHMgYXJlIHRha2VuICINCkl0
J3MgcmFyZSBpZy4uLi4gbWF5YmUgKm9uZGVtYW5kKiBnb3Zlcm5vciB3aWxsIGZyZXF1ZW50bHkg
Z2l2ZSBmcmVxdWVuY3kgYXJvdW5kIG5vbWluYWwgZnJlcXVlbmN5LA0KYnV0IHRoZSBleGFjdCB2
YWx1ZSBpcyByYXJlIGlnLg0KSSdtIGNvbmZ1c2VkIGFib3V0ICIgd2hlbiB0aGUgaW5jb21pbmcg
ICJmcmVxIiBpcyAyNSBvciA1IE1IeiBncmFudWxhciAiLg0KQXJlIHdlIHRhbGtpbmcgYWJvdXQg
aXMgaXQgd29ydGh5IHRvIGhhdmUgdGhlc2UgdHdvIGVhcmx5IHJldHVybiBwYXRocyBjb25zaWRl
cmluZyBpdCBpcyByYXJlbHkgdGFrZW4NCg0KPiA+ICsgICAgaWYgKCBjcHBjX2RhdGEtPmNwYy5s
b3dlc3RfbWh6ICYmIGNwcGNfZGF0YS0+Y3BjLm5vbWluYWxfbWh6ICYmDQo+ID4gKyAgICAgICAg
IGNwcGNfZGF0YS0+Y3BjLmxvd2VzdF9taHogPCBjcHBjX2RhdGEtPmNwYy5ub21pbmFsX21oeiAp
DQo+DQo+IEFsb25nIHRoZSBsaW5lcyBvZiBhIGNvbW1lbnQgb24gYW4gZWFybGllciBwYXRjaCwg
dGhlIG1pZGRsZSBwYXJ0IG9mIHRoZSBjb25kaXRpb24NCj4gaGVyZSBpcyByZWR1bmRhbnQgd2l0
aCB0aGUgM3JkIG9uZS4gQWxzbywgZG9uJ3QgeW91IGNoZWNrIHRoaXMgcmVsYXRpb24gYWxyZWFk
eQ0KPiBkdXJpbmcgaW5pdD8gSU9XIGlzbid0IGl0IHRoZSAzcmQgcGFydCB3aGljaCBjYW4gYmUg
ZHJvcHBlZD8NCj4NCg0KWWVzLCB5b3UncmUgcmlnaHQuIEkndmUgY2hlY2tlZCBpdCBpbiBzZXRf
Y3BwY19wbWluZm8oKSBhbHJlYWR5IGFuZCBvbmx5IGdhdmUgd2FybmluZ3MgdGhlcmUuDQpJIHNo
YWxsIGRlbGV0ZSB0aGUgY2hlY2sgaGVyZSwgYW5kIGJlc2lkZXMgZ2l2aW5nIHdhcm5pbmcgbWVz
c2FnZSBkdXJpbmcgaW5pdCwgaWYgdmFsdWVzIGFyZQ0KaW52YWxpZCwgaW5zdGVhZCBvZiBzdG9y
aW5nIGludmFsaWQgdmFsdWVzLCB3ZSBzaGFsbCBzZXQgY3BwY19kYXRhLT5jcGMubG93ZXN0X21o
eiAvIGNwcGNfZGF0YS0+Y3BjLm5vbWluYWxfbWh6IHRoZW0NCnplcm8uLi4gVGhlbiB3aGVyZXZl
ciB3ZSBhcmUgdHJ5aW5nIHRvIHVzZSB0aGVtLCBsaWtlIGhlcmUsIG5vbi16ZXJvIHZhbHVlcyBl
bnN1cmVzIHZhbGlkIHZhbHVlcy4NCg0KPiA+ICtzdGF0aWMgaW50IGFtZF9nZXRfbWF4X2ZyZXEo
Y29uc3Qgc3RydWN0IGFtZF9jcHBjX2Rydl9kYXRhICpkYXRhLA0KPiA+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdW5zaWduZWQgaW50ICptYXhfZnJlcSkgew0KPiA+ICsgICAgdW5zaWdu
ZWQgaW50IG5vbV9mcmVxID0gMCwgYm9vc3RfcmF0aW87DQo+ID4gKyAgICBpbnQgcmVzOw0KPiA+
ICsNCj4gPiArICAgIHJlcyA9IGFtZF9nZXRfbG93ZXN0X29yX25vbWluYWxfZnJlcShkYXRhLA0K
PiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRhdGEtPmNwcGNf
ZGF0YS0+Y3BjLm5vbWluYWxfbWh6LA0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGRhdGEtPmNhcHMubm9taW5hbF9wZXJmLA0KPiA+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZub21fZnJlcSk7DQo+ID4gKyAgICBpZiAoIHJl
cyApDQo+ID4gKyAgICAgICAgcmV0dXJuIHJlczsNCj4gPiArDQo+ID4gKyAgICBib29zdF9yYXRp
byA9ICh1bnNpZ25lZCBpbnQpKGRhdGEtPmNhcHMuaGlnaGVzdF9wZXJmIC8NCj4gPiArICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgZGF0YS0+Y2Fwcy5ub21pbmFsX3BlcmYpOw0KPg0K
PiBJIG1heSBoYXZlIHNlZW4gbG9naWMgZW5zdXJpbmcgbm9taW5hbF9wZXJmIGlzbid0IDAsIHNv
IHRoYXQgcGFydCBtYXkgYmUgZmluZS4gV2hhdA0KPiBndWFyYW50ZWVzIHRoaXMgZGl2aXNpb24g
dG8geWllbGQgYSBwb3NpdGl2ZSB2YWx1ZSwgdGhvdWdoPw0KPiBJZiBpdCB5aWVsZHMgemVybyAo
c2F5IDB4ZmYgLyAweDgwKSwgLi4uDQo+DQoNCkkgdGhpbmsgbWF5YmUgeW91IHdlcmUgc2F5aW5n
IDB4ODAvMHhmZiB0byB5aWVsZCB6ZXJvIHZhbHVlLiBGb3IgdGhhdCwgd2UgY2hlY2tlZCB0aGF0
IGhpZ2hlc3RfcGVyZg0KbXVzdCBub3QgYmUgc21hbGxlciB0aGFuIG5vbWluYWxfcGVyZiBkdXJp
bmcgaW5pdCwgc2VlIC4uLg0KDQo+ID4gKyAgICAqbWF4X2ZyZXEgPSBub21fZnJlcSAqIGJvb3N0
X3JhdGlvOw0KPg0KPiAuLi4gemVybyB3aWxsIGJlIHJlcG9ydGVkIGJhY2sgaGVyZS4gSSB0aGlu
ayB5b3Ugd2FudCB0byBzY2FsZSB0aGUgY2FsY3VsYXRpb25zIGhlcmUgdG8NCj4gYXZvaWQgc3Vj
aC4NCj4NCj4gPiArc3RhdGljIHZvaWQgY2ZfY2hlY2sgYW1kX2NwcGNfaW5pdF9tc3JzKHZvaWQg
KmluZm8pIHsNCj4gPiArICAgIHN0cnVjdCBjcHVmcmVxX3BvbGljeSAqcG9saWN5ID0gaW5mbzsN
Cj4gPiArICAgIHN0cnVjdCBhbWRfY3BwY19kcnZfZGF0YSAqZGF0YSA9IHRoaXNfY3B1KGFtZF9j
cHBjX2Rydl9kYXRhKTsNCj4gPiArICAgIHVpbnQ2NF90IHZhbDsNCj4gPiArICAgIHVuc2lnbmVk
IGludCBtaW5fZnJlcSA9IDAsIG5vbWluYWxfZnJlcSA9IDAsIG1heF9mcmVxOw0KPiA+ICsNCj4g
PiArICAgIC8qIFBhY2thZ2UgbGV2ZWwgTVNSICovDQo+ID4gKyAgICByZG1zcmwoTVNSX0FNRF9D
UFBDX0VOQUJMRSwgdmFsKTsNCj4gPiArICAgIC8qDQo+ID4gKyAgICAgKiBPbmx5IHdoZW4gRW5h
YmxlIGJpdCBpcyBvbiwgdGhlIGhhcmR3YXJlIHdpbGwgY2FsY3VsYXRlIHRoZSBwcm9jZXNzb3Li
gJlzDQo+ID4gKyAgICAgKiBwZXJmb3JtYW5jZSBjYXBhYmlsaXRpZXMgYW5kIGluaXRpYWxpemUg
dGhlIHBlcmZvcm1hbmNlIGxldmVsIGZpZWxkcyBpbg0KPiA+ICsgICAgICogdGhlIENQUEMgY2Fw
YWJpbGl0eSByZWdpc3RlcnMuDQo+ID4gKyAgICAgKi8NCj4gPiArICAgIGlmICggISh2YWwgJiBB
TURfQ1BQQ19FTkFCTEUpICkNCj4gPiArICAgIHsNCj4gPiArICAgICAgICB2YWwgfD0gQU1EX0NQ
UENfRU5BQkxFOw0KPiA+ICsgICAgICAgIHdybXNybChNU1JfQU1EX0NQUENfRU5BQkxFLCB2YWwp
Ow0KPiA+ICsgICAgfQ0KPiA+ICsNCj4gPiArICAgIHJkbXNybChNU1JfQU1EX0NQUENfQ0FQMSwg
ZGF0YS0+Y2Fwcy5yYXcpOw0KPiA+ICsNCj4gPiArICAgIGlmICggZGF0YS0+Y2Fwcy5oaWdoZXN0
X3BlcmYgPT0gMCB8fCBkYXRhLT5jYXBzLmxvd2VzdF9wZXJmID09IDAgfHwNCj4gPiArICAgICAg
ICAgZGF0YS0+Y2Fwcy5ub21pbmFsX3BlcmYgPT0gMCB8fCBkYXRhLT5jYXBzLmxvd2VzdF9ub25s
aW5lYXJfcGVyZiA9PSAwIHx8DQo+ID4gKyAgICAgICAgIGRhdGEtPmNhcHMubG93ZXN0X3BlcmYg
PiBkYXRhLT5jYXBzLmxvd2VzdF9ub25saW5lYXJfcGVyZiB8fA0KPg0KPiBTYW1lIHF1ZXN0aW9u
IGFzIGFza2VkIGVsc2V3aGVyZSAtIHdoZXJlIGlzIHRoaXMgcmVsYXRpb24gc3BlY2lmaWVkPw0K
Pg0KPiA+ICsgICAgICAgICBkYXRhLT5jYXBzLmxvd2VzdF9ub25saW5lYXJfcGVyZiA+IGRhdGEt
PmNhcHMubm9taW5hbF9wZXJmIHx8DQo+ID4gKyAgICAgICAgIGRhdGEtPmNhcHMubm9taW5hbF9w
ZXJmID4gZGF0YS0+Y2Fwcy5oaWdoZXN0X3BlcmYgKQ0KDQpoZXJlIC4uLg0KDQo+DQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Wed May 07 09:28:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 09:28:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978405.1365199 (Exim 4.92)
	(envelope-from )
	id 1uCb4H-0002ro-II; Wed, 07 May 2025 09:27:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978405.1365199; Wed, 07 May 2025 09: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 1uCb4H-0002rh-F7; Wed, 07 May 2025 09:27:57 +0000
Received: by outflank-mailman (input) for mailman id 978405;
 Wed, 07 May 2025 09:27:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uCb4G-0002rb-JB
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 09:27:56 +0000
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com
 [2a00:1450:4864:20::342])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8c00fcca-2b25-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 11:27:51 +0200 (CEST)
Received: by mail-wm1-x342.google.com with SMTP id
 5b1f17b1804b1-43edb40f357so34934685e9.0
 for ; Wed, 07 May 2025 02:27:51 -0700 (PDT)
Received: from ?IPV6:2003:e5:870f:e000:6c64:75fd:2c51:3fef?
 (p200300e5870fe0006c6475fd2c513fef.dip0.t-ipconnect.de.
 [2003:e5:870f:e000:6c64:75fd:2c51:3fef])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-441d4346610sm25539295e9.12.2025.05.07.02.27.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 07 May 2025 02:27: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" 
X-Inumbo-ID: 8c00fcca-2b25-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1746610071; x=1747214871; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=/7Rxas92BPow8CCQK6Akkp9y9PbzBCNbZtrPFFZNBRw=;
        b=MLZ7nsv7jZgNIHLFeWuGIsWEgDiLbO+v8iMuDv06nhtvP0UFj//6sUgV5xwRoO84Yw
         HwUbYZ+3DTWRoIh5bqqyE3C+Xv+gZvH9ftl2yFm2FDyVnmikGrkS4yheddWv/T9VPHzQ
         tOtmVYIfTi+dddmne47fpzrxLyxPh7dd5k/pWTuZ4qv5szPSKWVKwIsjLHDIrSa7QI4I
         ZLlMnEhyCCW7PRu2Bg8ivyARsVwfOQsDSoh9BztR1MhxqzcAXrEEGhe0zKmZK7IFFqdo
         kl0T+McXFvKqFKSY0EJZjGMbZmmu8ZVQLwPzLTxAmtiIY3LEnsAoXZgwEEwezDyXcf3j
         VTRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746610071; x=1747214871;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=/7Rxas92BPow8CCQK6Akkp9y9PbzBCNbZtrPFFZNBRw=;
        b=QwpDD8wBHMP1CVbJUDO6vohdZalH3piy8GQjheiIZCrisWxwYrOm8MT1hEavYIptbA
         8EWRajL9CxQ+LYAze2orF9YMuBxkD5rqLD0vV9FihVXouwT/ycuBt0i+NtOL4tYBZDQd
         4eZTJcMW74yz9tUdKcMlke8kgL9nSaCe5eYd7imE6goFSB4wgglO33tUkVUetSm0lUJP
         0AMKgB5l3suc7mOiPgkHH9OoAwL7MUk/TaW3ev4PYqCxbkw93jOQnmPds57Vcri1hoyg
         AhXX4FHJ77iwVRM6vYuoyjcCS+qY+kiMGcfGxc8rUSz02nzEv41ZyfzVi0dIg9haLaAj
         auNw==
X-Forwarded-Encrypted: i=1; AJvYcCXpfnH6baWvp7jQDezwlwwv53LE7+2z9xFEiF21WBygCiyoYAsfjj2caSWxgNOGwWEgjorncXEsnOs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQXOXhMnyQHNo+Mq6qvKXJ0fL3Fb1ID65wfmTjzouFlt+EHvaI
	wYUowVAPsKl6oeCZXKLl+xQHjSJTqchOIgGhKAPQlhoyoUlUMphUfnqRzp0xr5Y=
X-Gm-Gg: ASbGnct8TLoZ9s63fpAC9S0jpWGW9/LGLaDSq0DgFud+KMl/fc6DX4ViBdQLyJ58JLI
	+cFbcNFr61WAmg3wgoirEkOdjDQEXokH1syRcRvbcv6mIWf8fq8CpdabrMP8uS/qKcwsAPtX5Ky
	LoIxisHhchn2L3NktmolB6UkhZL/mdZskNH4BaC5Q9zwFOrN7xIFpqrofu9i1v35k8sNzBLby5d
	tgBo4OrKG786lEQaOZm8D/g0nrdu4N3fjOVMJw/af8nGkhh807LKERxWAmtbpLVk2wcmCEsCHcn
	zIcS/6iapG0PUSl7alRQ2xm8KbltLlIM3s3vsAz8NpPucoNrbywQLome0Bd6X3bgiU3n0VErIo5
	ExUkqnZhG/QrWy4/ZbKJEHSIGPrkkaafFGHycFEdrjklP4l3js/5es2sU6ii4bVzEpw==
X-Google-Smtp-Source: AGHT+IEO2XwDKF9o6Oc090Xz7Bur9+xTqXH0/t3wjlLvKXCABgqDGrh0wv0zPNgyrnZs2uoTBApJ4w==
X-Received: by 2002:a05:600c:8509:b0:43d:7413:cb3f with SMTP id 5b1f17b1804b1-441d44bb42fmr20812755e9.5.1746610070651;
        Wed, 07 May 2025 02:27:50 -0700 (PDT)
Message-ID: <6b17cb41-a4f1-4055-966a-54301493085c@suse.com>
Date: Wed, 7 May 2025 11:27:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xenbus: Use kref to track req lifetime
To: Jason Andryuk ,
 Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 Boris Ostrovsky 
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , stable@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
References: <20250506210935.5607-1-jason.andryuk@amd.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: <20250506210935.5607-1-jason.andryuk@amd.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------BYVYvOo0duQSKcgQ58Xfi0h7"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------BYVYvOo0duQSKcgQ58Xfi0h7
Content-Type: multipart/mixed; boundary="------------uH2EgFtkE3tRqY5rjAkv0UyF";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jason Andryuk ,
 Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 Boris Ostrovsky 
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , stable@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Message-ID: <6b17cb41-a4f1-4055-966a-54301493085c@suse.com>
Subject: Re: [PATCH] xenbus: Use kref to track req lifetime
References: <20250506210935.5607-1-jason.andryuk@amd.com>
In-Reply-To: <20250506210935.5607-1-jason.andryuk@amd.com>

--------------uH2EgFtkE3tRqY5rjAkv0UyF
Content-Type: multipart/mixed; boundary="------------QBRdb9fKfSWP8XEJG0WYgM7B"

--------------QBRdb9fKfSWP8XEJG0WYgM7B
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDYuMDUuMjUgMjM6MDksIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IE1hcmVrIHJlcG9y
dGVkIHNlZWluZyBhIE5VTEwgcG9pbnRlciBmYXVsdCBpbiB0aGUgeGVuYnVzX3RocmVhZA0K
PiBjYWxsc3RhY2s6DQo+IEJVRzoga2VybmVsIE5VTEwgcG9pbnRlciBkZXJlZmVyZW5jZSwg
YWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMA0KPiBSSVA6IGUwMzA6X193YWtlX3VwX2NvbW1v
bisweDRjLzB4MTgwDQo+IENhbGwgVHJhY2U6DQo+ICAgPFRBU0s+DQo+ICAgX193YWtlX3Vw
X2NvbW1vbl9sb2NrKzB4ODIvMHhkMA0KPiAgIHByb2Nlc3NfbXNnKzB4MThlLzB4MmYwDQo+
ICAgeGVuYnVzX3RocmVhZCsweDE2NS8weDFjMA0KPiANCj4gcHJvY2Vzc19tc2crMHgxOGUg
aXMgcmVxLT5jYihyZXEpLiAgcmVxLT5jYiBpcyBzZXQgdG8geHNfd2FrZV91cCgpLCBhDQo+
IHRoaW4gd3JhcHBlciBhcm91bmQgd2FrZV91cCgpLCBvciB4ZW5idXNfZGV2X3F1ZXVlX3Jl
cGx5KCkuICBJdCBzZWVtcw0KPiBsaWtlIGl0IHdhcyB4c193YWtlX3VwKCkgaW4gdGhpcyBj
YXNlLg0KPiANCj4gSXQgc2VlbXMgbGlrZSByZXEgbWF5IGhhdmUgd29rZW4gdXAgdGhlIHhz
X3dhaXRfZm9yX3JlcGx5KCksIHdoaWNoDQo+IGtmcmVlKCllZCB0aGUgcmVxLiAgV2hlbiB4
ZW5idXNfdGhyZWFkIHJlc3VtZXMsIGl0IGZhdWx0cyBvbiB0aGUgemVyby1lZA0KPiBkYXRh
Lg0KPiANCj4gTGludXggRGV2aWNlIERyaXZlcnMgMm5kIGVkaXRpb24gc3RhdGVzOg0KPiAi
Tm9ybWFsbHksIGEgd2FrZV91cCBjYWxsIGNhbiBjYXVzZSBhbiBpbW1lZGlhdGUgcmVzY2hl
ZHVsZSB0byBoYXBwZW4sDQo+IG1lYW5pbmcgdGhhdCBvdGhlciBwcm9jZXNzZXMgbWlnaHQg
cnVuIGJlZm9yZSB3YWtlX3VwIHJldHVybnMuIg0KPiAuLi4gd2hpY2ggd291bGQgbWF0Y2gg
dGhlIGJlaGF2aW91ciBvYnNlcnZlZC4NCj4gDQo+IENoYW5nZSB0byBrZWVwaW5nIHR3byBr
cmVmcyBvbiBlYWNoIHJlcXVlc3QuICBPbmUgZm9yIHRoZSBjYWxsZXIsIGFuZA0KPiBvbmUg
Zm9yIHhlbmJ1c190aHJlYWQuICBFYWNoIHdpbGwga3JlZl9wdXQoKSB3aGVuIGZpbmlzaGVk
LCBhbmQgdGhlIGxhc3QNCj4gd2lsbCBmcmVlIGl0Lg0KPiANCj4gVGhpcyB1c2Ugb2Yga3Jl
ZiBtYXRjaGVzIHRoZSBkZXNjcmlwdGlvbiBpbg0KPiBEb2N1bWVudGF0aW9uL2NvcmUtYXBp
L2tyZWYucnN0DQo+IA0KPiBMaW5rOiBodHRwczovL2xvcmUua2VybmVsLm9yZy94ZW4tZGV2
ZWwvWk8wV3JSNUoweHV3REl4V0BtYWlsLWl0bC8NCj4gUmVwb3J0ZWQtYnk6ICJNYXJlayBN
YXJjenlrb3dza2ktR8OzcmVja2kiIDxtYXJtYXJla0BpbnZpc2libGV0aGluZ3NsYWIuY29t
Pg0KPiBGaXhlczogZmQ4YWE5MDk1YTk1ICgieGVuOiBvcHRpbWl6ZSB4ZW5idXMgZHJpdmVy
IGZvciBtdWx0aXBsZSBjb25jdXJyZW50IHhlbnN0b3JlIGFjY2Vzc2VzIikNCj4gQ2M6IHN0
YWJsZUB2Z2VyLmtlcm5lbC5vcmcNCj4gU2lnbmVkLW9mZi1ieTogSmFzb24gQW5kcnl1ayA8
amFzb24uYW5kcnl1a0BhbWQuY29tPg0KDQpSZXZpZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8
amdyb3NzQHN1c2UuY29tPg0KDQo+IC0tLQ0KPiBLaW5kYSBSRkMtaXNoIGFzIEkgZG9uJ3Qg
a25vdyBpZiBpdCBmaXhlcyBNYXJlaydzIGlzc3VlLiAgVGhpcyBkb2VzIHNlZW0NCj4gbGlr
ZSB0aGUgY29ycmVjdCBhcHByb2FjaCBpZiB3ZSBhcmUgc2VlaW5nIHJlcSBmcmVlKCllZCBv
dXQgZnJvbSB1bmRlcg0KPiB4ZW5idXNfdGhyZWFkLg0KDQpJIHRoaW5rIHlvdXIgYW5hbHlz
aXMgaXMgY29ycmVjdC4gV2hlbiB3cml0aW5nIHRoaXMgY29kZSBJIGRpZG4ndCB0aGluaw0K
b2Ygd2FrZV91cCgpIG5lZWRpbmcgdG8gYWNjZXNzIHJlcS0+d3EgX2FmdGVyXyBoYXZpbmcg
d29rZW4gdXAgdGhlIHdhaXRlci4NCg0KDQpKdWVyZ2VuDQo=
--------------QBRdb9fKfSWP8XEJG0WYgM7B
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-----

--------------QBRdb9fKfSWP8XEJG0WYgM7B--

--------------uH2EgFtkE3tRqY5rjAkv0UyF--

--------------BYVYvOo0duQSKcgQ58Xfi0h7
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/Ey8FAmgbJ5UFAwAAAAAACgkQsN6d1ii/Ey9I
1AgAlSB2VBehdIvGVZwVJ1pjADKMNLEnQOBTsZTaQqS4qDUT8Cg/XrYx1rMorabHC7BlwK2bIqay
vQI0ztjYwRUf0qqFaFLb9PkbL6NtBa8Tpl3f/xzgmHHq2OuFNt5t1g9OSsBIEuhZ4TeqDosF6Fb2
BAq620NC7wRFwsbO6bRydv5kWknf5w8HZb0kQsiTEIlgpVMJyNrj51aBnvCMQUyC35tREy2nwx6W
wZhaQntVX8tprB1BM9EVsliOJnrIiXTovw3qkFgoElnWEB1jWRpdu+ZGTz198N59lq6r3AZ6nY6g
5X9eWV/FPsn4INGDSi02UyFVAzOgNvfLtxkDP/JILg==
=eyAD
-----END PGP SIGNATURE-----

--------------BYVYvOo0duQSKcgQ58Xfi0h7--


From xen-devel-bounces@lists.xenproject.org Wed May 07 09:43:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 09:43:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978416.1365208 (Exim 4.92)
	(envelope-from )
	id 1uCbJ1-00062m-NO; Wed, 07 May 2025 09:43:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978416.1365208; Wed, 07 May 2025 09:43:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCbJ1-00062f-Kf; Wed, 07 May 2025 09:43:11 +0000
Received: by outflank-mailman (input) for mailman id 978416;
 Wed, 07 May 2025 09:43:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCbJ0-00062T-EY
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 09:43:10 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aebd44e4-2b27-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 11:43:08 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43d2d952eb1so37993595e9.1
 for ; Wed, 07 May 2025 02:43:08 -0700 (PDT)
Received: from localhost.localdomain (172.74.6.51.dyn.plus.net. [51.6.74.172])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099b16f00sm16051290f8f.84.2025.05.07.02.43.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 02:43: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" 
X-Inumbo-ID: aebd44e4-2b27-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746610988; x=1747215788; 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;
        bh=Mcjy7e7bDp34ojMNL7zLdM48GMDWY9lrNewxJNow70E=;
        b=cmgir/aWK01BlT89N5N6aIGbTLNATWrIxbg0Ru9f/LuaSHtmPOSfqXcs+dT4EyojEg
         bOq1R6r0pZqNJTp2/DWTDDPp8mTcw0ip+6QC6UTPvV1DTMB9bdLG02x0paqRFs7+ZHZw
         NtNfptcv/m6o+RtQjhgLRjc8WsRxOYDjSpZIuaV5wZD6V96wYf/vWfLlIy3zlgZeePwW
         b5WsXzvVXoj7tUN3zkrwxbV2Y2OnOIAsYKKLOSY08QwBTjRnj5NxYwl7eefajW1ZfMju
         sOc11F4orWI433HvL9aAMEeWlECiOBQ8dSHeJhKa45OF1ujUjHrUaKJHT54Ph2ihJ6HN
         A/Og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746610988; x=1747215788;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Mcjy7e7bDp34ojMNL7zLdM48GMDWY9lrNewxJNow70E=;
        b=AZyNv28OmtboqnxVL6Wl8S2UF0eb7ePtTvtuPEbT18I2i5936injf9mxvk6eFdT2tS
         gJSmo0ukEQFLRdXDGVMalrvXAQeg+p90MgOgC7L8e1ETOYmOjRi5zB8sDOWIV0aPem4f
         n0UILWeNHWhxvXI+Imur7gM008f4ndd11TzALMUfVu/EjetBe8AI4aRVvOUDCkev1D4r
         3hOpK2NdWAk2euMzQmWnMvRm6avJyeREoVDM6VSBno1vIbJjN5jWF7LFfey/leO67u/R
         kNYmVM2Cot/utvNMFv6n5x09TMu5Y7Q1n30PH2U16jV+z3/Ri80swD4p8Lc7FY4ORjMY
         EsGg==
X-Gm-Message-State: AOJu0YyK1S01G4DrD3I+PX/IzwyCt3Wq+iSkEry8MSAK1qDEnYOuUnT1
	mjCufYcGwoPzNxJ0GqOObKn5gOKCP+uAOKctq/e+f3FQ4Tgzy0w8nkuGPUCZiNA=
X-Gm-Gg: ASbGncuGud8Vj6yzMBFE/RqzIwq7Ve7+0t10/Pek9PIWLNyZB7xcD3IzI/8cefpX9OJ
	7XiDTyG46+4qR1lvoXSUkYZ531bcwAa71+SKE0c6/lxe/XetlvsUCsbxlb5BbeoDc1CDCquNOz4
	O8+8R85l5VP5KGfXj3Vjb3DTPYQhU+FugGB0afCLgqUxqTlMx2z7TDmqq5JpUVgLoyi/yt4iFU6
	pm678V5Y9Q7MxRZqr7FaPdDmsJ7uqkOnn0pSzsf+abnNX6VAu2vVHVNpEOUhccwzqXnBPLac0jE
	XTCBSawptkFJyTYwdYSGxmanfdW9xL2O6CDedSk/bk1T5FwSFctdcUJ/4bFbIw7hSSDjLjd1vXj
	uCDUiAZs=
X-Google-Smtp-Source: AGHT+IFzn5UTKFzX+vZDU43NrBMaQzRcmi1RY7efAUZNXBnx/Ax15A5oUiw4J6MIUqESewW415PoXA==
X-Received: by 2002:a05:600c:6487:b0:43d:94:2d1e with SMTP id 5b1f17b1804b1-441d44c2c61mr20890295e9.13.1746610987496;
        Wed, 07 May 2025 02:43:07 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
	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 v2 0/4] Allows Secure Boot for Kexec
Date: Wed,  7 May 2025 10:42:45 +0100
Message-ID: <20250507094253.10395-1-freddy77@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Frediano Ziglio 

Using EFI Secure Boot all kernel level code should be signed and
there should be no way to run unchecked code.
For this reason the Kexec interface needs to be changed in order
to allows signature checking.

The purgatory code is included in Xen itself as passing this code
from userspace it's not secure (see patches 2/4 and 3/4).

Changes since v1:
- update copyright lines;
- better sha2 declarations.

Ross Lagerwall (4):
  xen/lib: Export additional sha256 functions
  kexec: Include purgatory in Xen
  kexec: Implement new EFI load types
  kexec: Support non-page-aligned kexec segments

 xen/arch/arm/Makefile                 |   1 +
 xen/arch/arm/kexec.c                  |  27 +
 xen/arch/x86/Makefile                 |   2 +
 xen/arch/x86/bzimage.c                |  40 +-
 xen/arch/x86/kexec.c                  | 125 +++++
 xen/arch/x86/purgatory/.gitignore     |   3 +
 xen/arch/x86/purgatory/Makefile       |  64 +++
 xen/arch/x86/purgatory/config.h       |  37 ++
 xen/arch/x86/purgatory/entry64.S      | 108 ++++
 xen/arch/x86/purgatory/purgatory.c    |  59 +++
 xen/arch/x86/purgatory/setup-x86_64.S |  63 +++
 xen/arch/x86/purgatory/stack.S        |  21 +
 xen/common/Kconfig                    |   1 +
 xen/common/kexec.c                    |  33 +-
 xen/common/kimage.c                   | 703 ++++++++++++++++++++++++--
 xen/include/public/kexec.h            |  23 +-
 xen/include/xen/kimage.h              |  57 ++-
 xen/include/xen/sha2.h                |  12 +
 xen/include/xen/x86-linux.h           |  62 +++
 xen/lib/sha2-256.c                    |  19 +-
 20 files changed, 1348 insertions(+), 112 deletions(-)
 create mode 100644 xen/arch/arm/kexec.c
 create mode 100644 xen/arch/x86/kexec.c
 create mode 100644 xen/arch/x86/purgatory/.gitignore
 create mode 100644 xen/arch/x86/purgatory/Makefile
 create mode 100644 xen/arch/x86/purgatory/config.h
 create mode 100644 xen/arch/x86/purgatory/entry64.S
 create mode 100644 xen/arch/x86/purgatory/purgatory.c
 create mode 100644 xen/arch/x86/purgatory/setup-x86_64.S
 create mode 100644 xen/arch/x86/purgatory/stack.S
 create mode 100644 xen/include/xen/x86-linux.h

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed May 07 09:43:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 09:43:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978418.1365229 (Exim 4.92)
	(envelope-from )
	id 1uCbJ5-0006V0-52; Wed, 07 May 2025 09:43:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978418.1365229; Wed, 07 May 2025 09:43:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCbJ5-0006Ur-1b; Wed, 07 May 2025 09:43:15 +0000
Received: by outflank-mailman (input) for mailman id 978418;
 Wed, 07 May 2025 09:43:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCbJ2-00062T-SK
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 09:43:12 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b04d5aec-2b27-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 11:43:11 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-43edecbfb46so38224605e9.0
 for ; Wed, 07 May 2025 02:43:11 -0700 (PDT)
Received: from localhost.localdomain (172.74.6.51.dyn.plus.net. [51.6.74.172])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099b16f00sm16051290f8f.84.2025.05.07.02.43.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 02: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" 
X-Inumbo-ID: b04d5aec-2b27-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746610990; x=1747215790; 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;
        bh=Oe/MYIRtB4rlJzUi92AgVF2o13CiBT7GoXGbiEvmSqY=;
        b=CeiKakjF0bHVxKkAH6G2Fu0zmOjxXdp6gxBmbTeDdPrpANN0dy1x8M51AU79invQkz
         G2aOEE/IV+Fwjd78XDJnJOcwrYNkxzIEO03eufw+ITSmtTocKuu5n5229Y+9YsVNWPFP
         d7jHsgR10DXpNqWPqKqcFqeJXPIDFteGPLzUlfRrYAw/vCj58uHq53NJW2eXL5fS7jwI
         EHhl+UH6BaZIDoUVg5snZhJMc74jIH3R6Z/42AsMl+hlAKudzauo3UMUzaIlztexYJz/
         lc4CMW5+ssQr9GW5H5bQRIxJ44iExkS3uWwFFbkm6ueXOhce3Z/Bv7JgVSnvAipv7y8l
         vlJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746610990; x=1747215790;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Oe/MYIRtB4rlJzUi92AgVF2o13CiBT7GoXGbiEvmSqY=;
        b=FCHgupVt+eSLS8hD3DlhfskG6PC0yJCYc7VZtu/tG14cBXCUSg/xMTp0b3ZumYEYl5
         GJUc65vik3zPmD/XW/LhS5acfwV64EumLCVEaIhN+G8TUtbsvoXTHf9EbA2/85+6BE5B
         Gzo1Hb5ElRJzIxRlt6LbDc0JMA6SyzHVIwgbBsyYVE1nNfZ+zeUEZbxWpEp91i5G/HEL
         6Pjr5NZ5psNBlEO09Rq88yskOe6Hrn1nqpGkkgwCcoY61rfTXmrR2Dcob8yuvuvksR/S
         UkZxOYHfTkUJOtXhLYwx2eR/lLP3O5aF8/mPgVOu4Mggf7AnlhGgxrklx8VdHIVCqZJ8
         FBKg==
X-Gm-Message-State: AOJu0YzFYD+dO+BfRTZXC/P6Gq8BSlXhJN5w8TPV2NC4wSqlrO/riKN7
	94pVfjtm0SjG//wh5giFBP/Tavxf3hgm95v9fw+qtIWlKJ0ZO/5nGeC+HefV4kQ=
X-Gm-Gg: ASbGncvaFcJ5/a832DqTCM6oqT5LWsLAFso6jhaCDz99MN3Eq7uMRiYxsU5t6DfBseH
	uD4dahR6cl5qAL84JwcLxTfQYymaQWKnVXP/5z7v0wsx3Pc3QZNj40IxARDNMjo4QXaOWcTfwtI
	0apevf+PtiR3qsuQGcbA6T2UoN7Wt6lIkm7jg4YEcDmHXHsFU/Dq3EOA5UeInxIcjt3xQIYXGVt
	vOq6v+g0Gd54jXpiVhD3KSuIweg4d46ycXmLWIaTpM5+irwT4nkb4IYFouddZe/6fyJiJgBqUQk
	fqZurXVXR6rLUB+Vx6l/2l+evOhf2zHOyGfAl+wgv5WWaKGsuVzvRbWXAiFmQvSV43X/KTRZ
X-Google-Smtp-Source: AGHT+IHX2EGNIBKnFFgCqJpTyBEHK31aOzzismyK3ci2pQZLueaBc2npHo9DOYf2wTY4GpKQsusXmg==
X-Received: by 2002:a05:600c:a409:b0:441:d4e8:76cd with SMTP id 5b1f17b1804b1-441d4e877e1mr15195655e9.29.1746610990080;
        Wed, 07 May 2025 02:43:10 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 2/4] kexec: Include purgatory in Xen
Date: Wed,  7 May 2025 10:42:47 +0100
Message-ID: <20250507094253.10395-3-freddy77@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250507094253.10395-1-freddy77@gmail.com>
References: <20250507094253.10395-1-freddy77@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Ross Lagerwall 

Purgatory is a binary that runs between two kernels during kexec. When Secure
Boot is enabled, it should be signed and verified before being loaded and
executed.

Currently, purgatory is built as part of kexec-tools and dynamically modified
before being loaded. This prevents signing it at build time. To fix this, build
purgatory as a separate object in Xen and modify it at load time in Xen itself.
This is the same approach used by Linux.

No behavioural change with this patch other than the puratory binary being
included in Xen.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/x86/Makefile                 |   1 +
 xen/arch/x86/purgatory/.gitignore     |   3 +
 xen/arch/x86/purgatory/Makefile       |  64 +++++++++++++++
 xen/arch/x86/purgatory/config.h       |  37 +++++++++
 xen/arch/x86/purgatory/entry64.S      | 108 ++++++++++++++++++++++++++
 xen/arch/x86/purgatory/purgatory.c    |  59 ++++++++++++++
 xen/arch/x86/purgatory/setup-x86_64.S |  63 +++++++++++++++
 xen/arch/x86/purgatory/stack.S        |  21 +++++
 xen/lib/sha2-256.c                    |   2 +-
 9 files changed, 357 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/x86/purgatory/.gitignore
 create mode 100644 xen/arch/x86/purgatory/Makefile
 create mode 100644 xen/arch/x86/purgatory/config.h
 create mode 100644 xen/arch/x86/purgatory/entry64.S
 create mode 100644 xen/arch/x86/purgatory/purgatory.c
 create mode 100644 xen/arch/x86/purgatory/setup-x86_64.S
 create mode 100644 xen/arch/x86/purgatory/stack.S

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index c2f1dcf301..b3ee871ba1 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -1,6 +1,7 @@
 obj-y += acpi/
 obj-y += boot/
 obj-y += cpu/
+obj-$(CONFIG_KEXEC) += purgatory/
 obj-y += efi/
 obj-y += genapic/
 obj-$(CONFIG_GUEST) += guest/
diff --git a/xen/arch/x86/purgatory/.gitignore b/xen/arch/x86/purgatory/.gitignore
new file mode 100644
index 0000000000..9353e3ff26
--- /dev/null
+++ b/xen/arch/x86/purgatory/.gitignore
@@ -0,0 +1,3 @@
+purgatory.chk
+kexec-purgatory.S
+purgatory.ro
diff --git a/xen/arch/x86/purgatory/Makefile b/xen/arch/x86/purgatory/Makefile
new file mode 100644
index 0000000000..211264e4da
--- /dev/null
+++ b/xen/arch/x86/purgatory/Makefile
@@ -0,0 +1,64 @@
+cc_common_flags = -Wall -Os -g0                                \
+                    -nostdinc                                  \
+                    -mcmodel=large                             \
+                    -fno-builtin                               \
+                    -ffreestanding                             \
+                    -fno-zero-initialized-in-bss               \
+                    -fno-stack-protector                       \
+                    -fno-PIC                                   \
+                    -fno-PIE                                   \
+                    -fno-tree-vectorize                        \
+                    -D__XEN__                                  \
+                    -D__PURGATORY__                            \
+                    -include $(srctree)/include/xen/config.h   \
+                    -I$(srctree)/$(src)                        \
+                    -I$(objtree)/include                       \
+                    -I$(srctree)/include                       \
+                    -I$(objtree)/arch/x86/include              \
+                    -I$(srctree)/arch/x86/include              \
+                    -I$(objtree)/arch/x86/include/generated
+
+cmd_cc_purg = $(CC) $(cc_common_flags)               \
+                  -c $< -o $@
+
+cmd_cc_as_purg = $(CC) $(cc_common_flags)            \
+		     -D__ASSEMBLY__                  \
+                     -c $< -o $@
+
+cmd_ld_purg = $(LD) --no-undefined               \
+                -z nodefaultlib                  \
+                -z noexecstack                   \
+                -e purgatory_start               \
+                -S $(real-prereqs) -o $@
+
+cmd_ldr_purg = $(cmd_ld_purg) -r
+
+purgatory-y := purgatory.o stack.o setup-x86_64.o sha2-256.o entry64.o memcmp.o
+PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
+
+$(obj)/%.o: $(src)/%.c $(src)/config.h
+	$(call if_changed,cc_purg)
+
+$(obj)/%.o: $(src)/%.S $(src)/config.h
+	$(call if_changed,cc_as_purg)
+
+$(obj)/sha2-256.o: $(srctree)/lib/sha2-256.c $(src)/config.h
+	$(call if_changed,cc_purg)
+
+$(obj)/memcmp.o: $(srctree)/lib/memcmp.c $(src)/config.h
+	$(call if_changed,cc_purg)
+
+$(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
+		$(call if_changed,ldr_purg)
+
+$(obj)/purgatory.chk: $(obj)/purgatory.ro FORCE
+		$(call if_changed,ld_purg)
+
+$(obj)/kexec-purgatory.o: $(obj)/purgatory.ro $(obj)/purgatory.chk
+
+$(obj)/kexec-purgatory.S: $(srctree)/tools/binfile FORCE
+	$(call if_changed,binfile,$(obj)/purgatory.ro kexec_purgatory)
+
+targets += kexec-purgatory.S
+
+obj-y += kexec-purgatory.o
diff --git a/xen/arch/x86/purgatory/config.h b/xen/arch/x86/purgatory/config.h
new file mode 100644
index 0000000000..f1f9f41aad
--- /dev/null
+++ b/xen/arch/x86/purgatory/config.h
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ *
+ * Copyright (C) 2025  Cloud Software Group Inc.
+ */
+
+#ifndef __PURGATORY_CONFIG_H__
+#define __PURGATORY_CONFIG_H__
+
+#define BALIGN(size) .balign size
+
+#undef ENTRY
+#define ENTRY(name)         \
+    name:
+
+#define END(name)           \
+    name##_end:
+
+#undef GLOBAL
+#define GLOBAL(name)        \
+    .globl name;            \
+    ENTRY(name)
+
+#define GLOBAL_END(name)    \
+    .globl name##_end;      \
+    END(name)
+
+#define SYM_T_DATA 1
+
+#define ASM_INT(name, val)  \
+    .type name, SYM_T_DATA; \
+    BALIGN(4);              \
+    .hidden name;           \
+    GLOBAL(name)            \
+    .long (val);            \
+    .size name, . - name
+
+#endif // __PURGATORY_CONFIG_H__
diff --git a/xen/arch/x86/purgatory/entry64.S b/xen/arch/x86/purgatory/entry64.S
new file mode 100644
index 0000000000..7256cb6a91
--- /dev/null
+++ b/xen/arch/x86/purgatory/entry64.S
@@ -0,0 +1,108 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2003,2004  Eric Biederman (ebiederm@xmission.com)
+ * Copyright (C) 2014  Red Hat Inc.
+ * Copyright (C) 2025  Cloud Software Group Inc.
+
+ * Author(s): Vivek Goyal 
+ *
+ * This code has been adapted from kexec-tools and Linux.
+ */
+
+#include "config.h"
+
+    .text
+    .code64
+
+BALIGN(16)
+GLOBAL(entry64)
+    /* Setup a gdt that should be preserved */
+    lgdt gdt(%rip)
+
+    /* load the data segments */
+    movl    $0x18, %eax     /* data segment */
+    movl    %eax, %ds
+    movl    %eax, %es
+    movl    %eax, %ss
+    movl    %eax, %fs
+    movl    %eax, %gs
+
+    /* Setup new stack */
+    leaq    stack_init(%rip), %rsp
+    pushq   $0x10 /* CS */
+    leaq    new_cs_exit(%rip), %rax
+    pushq   %rax
+    lretq
+ENTRY(new_cs_exit)
+
+    /* Load the registers */
+    movq    rax(%rip), %rax
+    movq    rbx(%rip), %rbx
+    movq    rcx(%rip), %rcx
+    movq    rdx(%rip), %rdx
+    movq    rsi(%rip), %rsi
+    movq    rdi(%rip), %rdi
+    movq    rsp(%rip), %rsp
+    movq    rbp(%rip), %rbp
+    movq    r8(%rip), %r8
+    movq    r9(%rip), %r9
+    movq    r10(%rip), %r10
+    movq    r11(%rip), %r11
+    movq    r12(%rip), %r12
+    movq    r13(%rip), %r13
+    movq    r14(%rip), %r14
+    movq    r15(%rip), %r15
+
+    /* Jump to the new code... */
+    jmpq    *rip(%rip)
+END(entry64)
+
+    .section ".rodata"
+
+BALIGN(4)
+GLOBAL(entry64_regs)
+rax:    .quad 0x0
+rbx:    .quad 0x0
+rcx:    .quad 0x0
+rdx:    .quad 0x0
+rsi:    .quad 0x0
+rdi:    .quad 0x0
+rsp:    .quad 0x0
+rbp:    .quad 0x0
+r8:     .quad 0x0
+r9:     .quad 0x0
+r10:    .quad 0x0
+r11:    .quad 0x0
+r12:    .quad 0x0
+r13:    .quad 0x0
+r14:    .quad 0x0
+r15:    .quad 0x0
+rip:    .quad 0x0
+END(entry64_regs)
+    .size entry64_regs, entry64_regs_end - entry64_regs
+
+    /* GDT */
+    .section ".rodata"
+
+BALIGN(16)
+ENTRY(gdt)
+    /*
+     * 0x00 unusable segment
+     * 0x08 unused
+     * so use them as gdt ptr
+     */
+    .word gdt_end - gdt - 1
+    .quad gdt
+    .word 0, 0, 0
+
+    /* 0x10 4GB flat code segment */
+    .word 0xFFFF, 0x0000, 0x9A00, 0x00AF
+
+    /* 0x18 4GB flat data segment */
+    .word 0xFFFF, 0x0000, 0x9200, 0x00CF
+END(gdt)
+
+ENTRY(stack)
+    .quad   0, 0
+END(stack)
+ENTRY(stack_init)
diff --git a/xen/arch/x86/purgatory/purgatory.c b/xen/arch/x86/purgatory/purgatory.c
new file mode 100644
index 0000000000..8b9a3cdb11
--- /dev/null
+++ b/xen/arch/x86/purgatory/purgatory.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * purgatory: Runs between two kernels
+ *
+ * Copyright (C) 2014 Red Hat Inc.
+ * Copyright (C) 2025  Cloud Software Group Inc.
+ *
+ * Author:
+ *       Vivek Goyal 
+ *
+ * This code has been imported from kexec-tools.
+ */
+
+#include 
+#include 
+
+struct sha256_region {
+    uint64_t start;
+    uint64_t len;
+};
+
+typedef uint8_t sha256_digest_t[SHA2_256_DIGEST_SIZE];
+
+#define SHA256_REGIONS 16
+
+struct sha256_region sha256_regions[SHA256_REGIONS] = {};
+sha256_digest_t sha256_digest = { };
+
+int verify_sha256_digest(void)
+{
+    struct sha256_region *ptr, *end;
+    sha256_digest_t digest;
+    struct sha2_256_state ctx;
+    sha2_256_init(&ctx);
+    end = &sha256_regions[sizeof(sha256_regions) / sizeof(sha256_regions[0])];
+
+    for ( ptr = sha256_regions; ptr < end; ptr++ )
+        sha2_256_update(&ctx, (uint8_t *)((uintptr_t)ptr->start), ptr->len);
+
+    sha2_256_final(&ctx, digest);
+
+    if ( memcmp(digest, sha256_digest, sizeof(digest)) != 0 )
+        return 1;
+
+    return 0;
+}
+
+void purgatory(void)
+{
+    int ret;
+
+    ret = verify_sha256_digest();
+    if ( ret )
+    {
+        /* loop forever */
+        for ( ; ; )
+            ;
+    }
+}
diff --git a/xen/arch/x86/purgatory/setup-x86_64.S b/xen/arch/x86/purgatory/setup-x86_64.S
new file mode 100644
index 0000000000..c36be25656
--- /dev/null
+++ b/xen/arch/x86/purgatory/setup-x86_64.S
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * purgatory:  setup code
+ *
+ * Copyright (C) 2003,2004  Eric Biederman (ebiederm@xmission.com)
+ * Copyright (C) 2014  Red Hat Inc.
+ * Copyright (C) 2025  Cloud Software Group Inc.
+ *
+ * This code has been adapted from kexec-tools and Linux.
+ */
+
+#include "config.h"
+
+    .text
+    .code64
+
+BALIGN(16)
+GLOBAL(purgatory_start)
+
+    /* Load a gdt so I know what the segment registers are */
+    lgdt    gdt(%rip)
+
+    /* load the data segments */
+    movl    $0x18, %eax /* data segment */
+    movl    %eax, %ds
+    movl    %eax, %es
+    movl    %eax, %ss
+    movl    %eax, %fs
+    movl    %eax, %gs
+
+    /* Setup a stack */
+    leaq    lstack_end(%rip), %rsp
+
+    /* Call the C code */
+    call purgatory
+    jmp entry64
+END(purgatory_start)
+
+    .section ".rodata"
+
+BALIGN(16)
+ENTRY(gdt)
+    /* 0x00 unusable segment
+     * 0x08 unused
+     * so use them as the gdt ptr
+     */
+    .word   gdt_end - gdt - 1
+    .quad   gdt
+    .word   0, 0, 0
+
+    /* 0x10 4GB flat code segment */
+    .word   0xFFFF, 0x0000, 0x9A00, 0x00AF
+
+    /* 0x18 4GB flat data segment */
+    .word   0xFFFF, 0x0000, 0x9200, 0x00CF
+END(gdt)
+
+    .bss
+
+BALIGN(4096)
+ENTRY(lstack)
+    .skip 4096
+END(lstack)
diff --git a/xen/arch/x86/purgatory/stack.S b/xen/arch/x86/purgatory/stack.S
new file mode 100644
index 0000000000..6ac7685cd5
--- /dev/null
+++ b/xen/arch/x86/purgatory/stack.S
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * purgatory:  stack
+ *
+ * Copyright (C) 2014 Red Hat Inc.
+ * Copyright (C) 2025 Cloud Software Group Inc.
+ *
+ *	This code has been adapted from kexec-tools and Linux.
+ */
+
+#include "config.h"
+
+	/* A stack for the loaded kernel.
+	 * Separate and in the data section so it can be prepopulated.
+	 */
+	.data
+
+BALIGN(4096)
+GLOBAL(stack)
+	.skip 4096
+GLOBAL_END(stack)
diff --git a/xen/lib/sha2-256.c b/xen/lib/sha2-256.c
index e55e297eff..09c033f97f 100644
--- a/xen/lib/sha2-256.c
+++ b/xen/lib/sha2-256.c
@@ -209,7 +209,7 @@ void sha2_256_digest(uint8_t digest[SHA2_256_DIGEST_SIZE],
     sha2_256_final(&s, digest);
 }
 
-#ifdef CONFIG_SELF_TESTS
+#if defined(CONFIG_SELF_TESTS) && !defined(__PURGATORY__)
 
 #include 
 #include 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed May 07 09:43:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 09:43:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978417.1365218 (Exim 4.92)
	(envelope-from )
	id 1uCbJ2-0006GM-UK; Wed, 07 May 2025 09:43:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978417.1365218; Wed, 07 May 2025 09: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 1uCbJ2-0006GF-RG; Wed, 07 May 2025 09:43:12 +0000
Received: by outflank-mailman (input) for mailman id 978417;
 Wed, 07 May 2025 09:43:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCbJ1-00062U-7Z
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 09:43:11 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id af60407f-2b27-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 11:43:09 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a0b135d18eso777822f8f.2
 for ; Wed, 07 May 2025 02:43:09 -0700 (PDT)
Received: from localhost.localdomain (172.74.6.51.dyn.plus.net. [51.6.74.172])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099b16f00sm16051290f8f.84.2025.05.07.02.43.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 02:43: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" 
X-Inumbo-ID: af60407f-2b27-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746610989; x=1747215789; 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;
        bh=O8Y83zKrsmgv8ZOMTDE8RmHuDTLf5jyr/esqnFH6tRs=;
        b=GhkmmV1dXqOFpSej9FTnu88VIvy79fMJ/RhGfd60Hvz4zmB5XKsNSRBr8tNlF048iG
         m2iLBSaKIfQtoXJWvjY3Qtka+pTIqYod7zbnZu+ilnjjHrn5HV1ShQvgzDnHBahDZGP+
         hiOvTfxqL6PO3aLeojFpzE95nJ68X3kIaN78bxDP308VsXZcJMhetmsqTv63xWbX4+10
         8hNFXaOvBWptEPC//Dd01Rh1EtdDHnpXHUVlROk2MEEjSSGeW4JO/W23C2wbfbFOVALW
         naSjzuqPm6AtZCdwbBSrwltVXPUGUCTmHWuS2z3ttqjHZKjlNg3mLRGFEueJPQqpz1LP
         PNUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746610989; x=1747215789;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=O8Y83zKrsmgv8ZOMTDE8RmHuDTLf5jyr/esqnFH6tRs=;
        b=sZPJJOqGLPsLKffVAgVhotEqbIw6uwoDo8ZdZrvZhx4ZIwXK+XGTonWIV3j/I2nYeq
         8o+065Yomc/fbTusmMSFfYfHu62HEmWb0YbkA/AcgJDmXOeYcDWr08tGqauXwEbE4TdX
         BtoX7cm3ySYjTzO4mlgR0/2oCTJf4idWZZwzRyEvceSNQVtlE8MDskboHRyU4JcX72/4
         7H2GwKbsHPf1ixEPlAV/nTJIaKjiuQ36LhSMiVklD5MBhTMQHyiC9u5zP2RA/SocSIeJ
         +rd7gdAabqM/zSD7YQqw51TfNvwNVe4o+pabzH/vTduC4HFX8d9PwDq85d5aavKf9xk0
         AKsA==
X-Gm-Message-State: AOJu0YweIQLgBTEaJYWNu7Ge1R5xogfG79Tr+rggT4m55CgSmfEKRr4U
	Qowmrkr9oNZ2YcURH3oofNl26tYBkctP4ewQ59liosvCpPZvasuw2H86rHFrnNg=
X-Gm-Gg: ASbGncuSGaSiu5sbPo1PoomVy+fjP1fl27jzux0b5XFqg8MLZu9zKNnvKcdUyqYUcDR
	NFsqdVi5MpVFpz8wgoNodu8KnXs7I9AIau/CUSWgHO7eMveDvJLVrGn6a4+WNL0t0XVQxTjmIXX
	q5k8o07X4d62aEXIOUQShyQa0F9FPoNtcq0tLyjzXvVlXYbl3vQGpGyZromyNUaQG2yphm1qX7l
	x3cRRv4LhiUw2e6ZFjdq3FB0hyRXZoQqlKIxKMf1T8l21hlUR5ugs7ZDp70zc3IAM88jXWHYxPp
	Oh6t0Gw+gcR52Be4bUoYoL7VzCEHq9ZRdps7EJpyuLQX93BsEsDA31OBRwho5CGcnICUOfiW
X-Google-Smtp-Source: AGHT+IGCSM81Wqk/bepwSce6eX56XNmXveWuiq4VMa3x/g4flpfQF2He/n7rzyqGSoi4dGTtSTqLVQ==
X-Received: by 2002:a05:6000:401f:b0:391:10c5:d1a9 with SMTP id ffacd0b85a97d-3a0b4a18f10mr2203929f8f.31.1746610988677;
        Wed, 07 May 2025 02:43:08 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 1/4] xen/lib: Export additional sha256 functions
Date: Wed,  7 May 2025 10:42:46 +0100
Message-ID: <20250507094253.10395-2-freddy77@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250507094253.10395-1-freddy77@gmail.com>
References: <20250507094253.10395-1-freddy77@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Ross Lagerwall 

In future, some code needs to generate a digest over several separate buffers
so export the necessary functions to do so.

Signed-off-by: Ross Lagerwall 
---
 xen/include/xen/sha2.h | 12 ++++++++++++
 xen/lib/sha2-256.c     | 17 ++++++-----------
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
index 47d97fbf01..cb30e8f8d7 100644
--- a/xen/include/xen/sha2.h
+++ b/xen/include/xen/sha2.h
@@ -12,4 +12,16 @@
 void sha2_256_digest(uint8_t digest[SHA2_256_DIGEST_SIZE],
                      const void *msg, size_t len);
 
+struct sha2_256_state {
+    uint32_t state[SHA2_256_DIGEST_SIZE / sizeof(uint32_t)];
+    uint8_t buf[64];
+    size_t count; /* Byte count. */
+};
+
+void sha2_256_init(struct sha2_256_state *s);
+void sha2_256_update(struct sha2_256_state *s, const void *msg,
+                     size_t len);
+void sha2_256_final(struct sha2_256_state *s,
+                    uint8_t digest[SHA2_256_DIGEST_SIZE]);
+
 #endif /* XEN_SHA2_H */
diff --git a/xen/lib/sha2-256.c b/xen/lib/sha2-256.c
index 19e8252188..e55e297eff 100644
--- a/xen/lib/sha2-256.c
+++ b/xen/lib/sha2-256.c
@@ -10,12 +10,6 @@
 #include 
 #include 
 
-struct sha2_256_state {
-    uint32_t state[SHA2_256_DIGEST_SIZE / sizeof(uint32_t)];
-    uint8_t buf[64];
-    size_t count; /* Byte count. */
-};
-
 static uint32_t choose(uint32_t x, uint32_t y, uint32_t z)
 {
     return z ^ (x & (y ^ z));
@@ -131,7 +125,7 @@ static void sha2_256_transform(uint32_t *state, const void *_input)
     state[4] += e; state[5] += f; state[6] += g; state[7] += h;
 }
 
-static void sha2_256_init(struct sha2_256_state *s)
+void sha2_256_init(struct sha2_256_state *s)
 {
     *s = (struct sha2_256_state){
         .state = {
@@ -147,8 +141,8 @@ static void sha2_256_init(struct sha2_256_state *s)
     };
 }
 
-static void sha2_256_update(struct sha2_256_state *s, const void *msg,
-                            size_t len)
+void sha2_256_update(struct sha2_256_state *s, const void *msg,
+                     size_t len)
 {
     unsigned int partial = s->count & 63;
 
@@ -177,9 +171,10 @@ static void sha2_256_update(struct sha2_256_state *s, const void *msg,
     memcpy(s->buf + partial, msg, len);
 }
 
-static void sha2_256_final(struct sha2_256_state *s, void *_dst)
+void sha2_256_final(struct sha2_256_state *s,
+                    uint8_t digest[SHA2_256_DIGEST_SIZE])
 {
-    uint32_t *dst = _dst;
+    uint32_t *dst = (uint32_t *)digest;
     unsigned int i, partial = s->count & 63;
 
     /* Start padding */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed May 07 09:43:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 09:43:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978419.1365239 (Exim 4.92)
	(envelope-from )
	id 1uCbJ6-0006kp-K2; Wed, 07 May 2025 09:43:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978419.1365239; Wed, 07 May 2025 09: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 1uCbJ6-0006kg-Fe; Wed, 07 May 2025 09:43:16 +0000
Received: by outflank-mailman (input) for mailman id 978419;
 Wed, 07 May 2025 09:43:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCbJ4-00062T-OT
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 09:43:14 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b132f369-2b27-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 11:43:12 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-39c1ef4ae3aso467418f8f.1
 for ; Wed, 07 May 2025 02:43:12 -0700 (PDT)
Received: from localhost.localdomain (172.74.6.51.dyn.plus.net. [51.6.74.172])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099b16f00sm16051290f8f.84.2025.05.07.02.43.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 02:43: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" 
X-Inumbo-ID: b132f369-2b27-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746610992; x=1747215792; 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;
        bh=GvgGQEXxmwdDOq95Q9FxVo61JDyQYafFqqrzIkZ3gxA=;
        b=GJUr5YVICfDhbq8NYkdyET4oegEDXH7eSo9zI9dnFl7pZAb4F68qD/vXSEb2L/0KTy
         hkhWbVs/RObjs5QdSbHjHzbOUa0YKJ53C/0VOA321KXRXFq5TUCJnxiTtyFGBcXyd8Ay
         ThxENbMAA3yp0o9XJqLRw7Wd7eZKKDJFVFCHU7w3KcWI4iZPo0SOTHiU5LQxLlTgyEQX
         3tcl767J6cNXaGLIFULQfpYWRK1RrwrSMXmDWbICaMPkRiuhgj87rIC1Qec+Se8kmp5k
         jcDXQpmA3IHYGDQUq064Yby7r54E2wqfnW1LCh8jvhVgwd7uGQZaGgyjwsJaNlsGR8nw
         4Ong==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746610992; x=1747215792;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GvgGQEXxmwdDOq95Q9FxVo61JDyQYafFqqrzIkZ3gxA=;
        b=qXdUOJDQ3YYCxpVXS85CLsHL33vYRPrrVCBgzHicXAI8AQSjPnCYVxoQo2D/1PXRbI
         EQwswBHh7c1fdi6lU1D2EB8crLGskXb2YRRBWBRaYMU8vOdQFEylqo0MkPmSkUXOENzg
         OT3ulniwDGONNuorGLNWd/ui5UabthCTn6AboccxSoHV5hh0/sfTsUpbfAv84v8svD7L
         4ZXU3sFYzwMOP2UHQ5WdHsaPILTT4NZUyLGStUMVlB/bUdpg+QX5Rgrhbr+iIcZDcfiB
         V1+NEfcl6FXctIBcmcPSDYSK1FT84C51AjGs7pAqpSdYREWrqbQqAgmACV/OlzNMAlOH
         UHRQ==
X-Gm-Message-State: AOJu0YxAh7qopIC92o70V929Lef03LtvyqQcbD8l1tYk3W1vB9xy89r9
	1WeTNv7xRHoEbZPUbdcgu2EkUViaNXQSP6zSRK0Q/meKKPmQ0j8lNT7FUz85NGY=
X-Gm-Gg: ASbGncvA3+Q8rRzAfrUes+tTXyUc7h7gplBHKdtBc8zOc1tWRUH3c0hly5DKsMUJu6p
	jgdO4haYXuoJgLziLq5iiyxVxqRJXnjiHS2oW5kqhvzMlIUsuXHuaTkW1A0WMyMcrKrf4IDuH1I
	8FAx2SmnKy1nkx7v0HfVunFyS7eRey6nVfFxVQEphs2W30pZZUeVgq2skIbid2sPWQAsarCBGvG
	sIUl2KVykSsGRk1DDG8iBjVCfG+rwXPSYOQS+xyl4TG4D6affQxZxp8mMaQbnWKmaZ2DL34d+ur
	zokA+9fi+Pl43UKUoKdq4kw0h+QFdJhs/zLNeDLY5hKTvhFZZArmIRg9QoaZGH5/mJmFBmAb
X-Google-Smtp-Source: AGHT+IG03r2HP1/gVZCiODuvJ0+xqiZYzO8vzfAdMNoeAaGrDhDDyDdYFGV8qSz1Qjj4fx9nzwU9/w==
X-Received: by 2002:a5d:5885:0:b0:3a0:9dda:c2e2 with SMTP id ffacd0b85a97d-3a0b53eb0b8mr2170979f8f.22.1746610991521;
        Wed, 07 May 2025 02:43:11 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Gerald Elder-Vass 
Subject: [PATCH v2 3/4] kexec: Implement new EFI load types
Date: Wed,  7 May 2025 10:42:48 +0100
Message-ID: <20250507094253.10395-4-freddy77@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250507094253.10395-1-freddy77@gmail.com>
References: <20250507094253.10395-1-freddy77@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Ross Lagerwall 

Add two new EFI load types for kexec. These load types are suitable for use
when Secure Boot is enabled.

When these load types are used, the caller should not pass purgatory as one of
the kexec segments. Instead, Xen will prepare and supply purgatory itself.

Preparing purgatory involves loading it, applying relocations, and calculating
and embedding the checksums of the segments.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Gerald Elder-Vass 
---
 xen/arch/arm/Makefile       |   1 +
 xen/arch/arm/kexec.c        |  27 ++
 xen/arch/x86/Makefile       |   1 +
 xen/arch/x86/bzimage.c      |  40 +--
 xen/arch/x86/kexec.c        | 125 +++++++
 xen/common/Kconfig          |   1 +
 xen/common/kexec.c          |  10 +
 xen/common/kimage.c         | 632 +++++++++++++++++++++++++++++++++++-
 xen/include/public/kexec.h  |  23 +-
 xen/include/xen/kimage.h    |  42 +++
 xen/include/xen/x86-linux.h |  62 ++++
 11 files changed, 908 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/arm/kexec.c
 create mode 100644 xen/arch/x86/kexec.c
 create mode 100644 xen/include/xen/x86-linux.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 129a109d6e..0e652d9594 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -36,6 +36,7 @@ obj-y += io.o
 obj-$(CONFIG_IOREQ_SERVER) += ioreq.o
 obj-y += irq.o
 obj-y += kernel.init.o
+obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_VM_EVENT) += mem_access.o
diff --git a/xen/arch/arm/kexec.c b/xen/arch/arm/kexec.c
new file mode 100644
index 0000000000..f8847e16e0
--- /dev/null
+++ b/xen/arch/arm/kexec.c
@@ -0,0 +1,27 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-only
+ * Copyright (c) 2025, Cloud Software Group
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
+                                     Elf_Shdr *section, const Elf_Shdr *relsec,
+                                     const Elf_Shdr *symtabsec)
+{
+    return -ENOSYS;
+}
+
+
+/*
+ * 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/x86/Makefile b/xen/arch/x86/Makefile
index b3ee871ba1..6b11364150 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -42,6 +42,7 @@ obj-y += hypercall.o
 obj-y += i387.o
 obj-y += i8259.o
 obj-y += io_apic.o
+obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_LIVEPATCH) += alternative.o livepatch.o
 obj-y += msi.o
 obj-y += msr.o
diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c
index 66f648f311..f4d5b584cb 100644
--- a/xen/arch/x86/bzimage.c
+++ b/xen/arch/x86/bzimage.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static __init unsigned long output_length(void *image, unsigned long image_len)
@@ -13,45 +14,6 @@ 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)
 {
     if ( len < sizeof(struct setup_header) )
diff --git a/xen/arch/x86/kexec.c b/xen/arch/x86/kexec.c
new file mode 100644
index 0000000000..5ce70af06d
--- /dev/null
+++ b/xen/arch/x86/kexec.c
@@ -0,0 +1,125 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-only
+ * Copyright (c) 2025, Cloud Software Group
+ *
+ * Parts have been derived from Linux's arch/x86/kernel/machine_kexec_64.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
+                                     Elf_Shdr *section, const Elf_Shdr *relsec,
+                                     const Elf_Shdr *symtabsec)
+{
+    unsigned int i;
+    Elf64_Rela *rel;
+    Elf64_Sym *sym;
+    void *location;
+    unsigned long address, sec_base, value;
+    const char *strtab, *name, *shstrtab;
+    const Elf_Shdr *sechdrs;
+    const Elf_Ehdr *ehdr = (const Elf_Ehdr *)kexec_purgatory;
+
+    /* String & section header string table */
+    sechdrs = (void *)ehdr + ehdr->e_shoff;
+    strtab = (char *)ehdr + sechdrs[symtabsec->sh_link].sh_offset;
+    shstrtab = (char *)ehdr + sechdrs[ehdr->e_shstrndx].sh_offset;
+
+    rel = (void *)ehdr + relsec->sh_offset;
+
+    dprintk(XENLOG_DEBUG, "Applying relocate section %s to %u\n",
+            shstrtab + relsec->sh_name, relsec->sh_info);
+
+    for ( i = 0; i < relsec->sh_size / sizeof(*rel); i++) {
+
+        /*
+         * rel[i].r_offset contains byte offset from beginning
+         * of section to the storage unit affected.
+         *
+         * This is location to update. This is temporary buffer
+         * where section is currently loaded. This will finally be
+         * loaded to a different address later, pointed to by
+         * ->sh_addr. kimage_purgatory_move takes care of moving it
+         */
+        location = pi->buffer;
+        location += section->sh_offset;
+        location += rel[i].r_offset;
+
+        /* Final address of the location */
+        address = section->sh_addr + rel[i].r_offset;
+
+        /*
+         * rel[i].r_info contains information about symbol table index
+         * w.r.t which relocation must be made and type of relocation
+         * to apply. ELF64_R_SYM() and ELF64_R_TYPE() macros get
+         * these respectively.
+         */
+        sym = (void *)ehdr + symtabsec->sh_offset;
+        sym += ELF64_R_SYM(rel[i].r_info);
+
+        if ( sym->st_name )
+            name = strtab + sym->st_name;
+        else
+            name = shstrtab + sechdrs[sym->st_shndx].sh_name;
+
+        dprintk(XENLOG_DEBUG, "Symbol: %s info: %02x shndx: %02x value=%lx size: %lx\n",
+                name, sym->st_info, sym->st_shndx, sym->st_value,
+                sym->st_size);
+
+        if ( sym->st_shndx == SHN_UNDEF ) {
+            printk("Undefined symbol: %s\n", name);
+            return -ENOEXEC;
+        }
+
+        if ( sym->st_shndx == SHN_COMMON ) {
+            printk("symbol '%s' in common section\n", name);
+            return -ENOEXEC;
+        }
+
+        if ( sym->st_shndx == SHN_ABS )
+            sec_base = 0;
+        else if ( sym->st_shndx >= ehdr->e_shnum ) {
+            printk("Invalid section %d for symbol %s\n",
+                    sym->st_shndx, name);
+            return -ENOEXEC;
+        } else
+            sec_base = pi->sechdrs[sym->st_shndx].sh_addr;
+
+        value = sym->st_value;
+        value += sec_base;
+        value += rel[i].r_addend;
+
+        switch ( ELF64_R_TYPE(rel[i].r_info) ) {
+            case R_X86_64_NONE:
+                break;
+            case R_X86_64_64:
+                *(u64 *)location = value;
+                break;
+            case R_X86_64_PC32:
+            case R_X86_64_PLT32:
+                value -= (u64)address;
+                *(u32 *)location = value;
+                break;
+            default:
+                printk("Unknown rela relocation: %lu\n",
+                        ELF64_R_TYPE(rel[i].r_info));
+                return -ENOEXEC;
+        }
+    }
+
+    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/common/Kconfig b/xen/common/Kconfig
index 4bec78c6f2..674c2bace1 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -318,6 +318,7 @@ config KEXEC
 	bool "kexec support"
 	default y
 	depends on HAS_KEXEC
+	select CRYPTO
 	help
 	  Allows a running Xen hypervisor to be replaced with another OS
 	  without rebooting. This is primarily used to execute a crash
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 84fe8c3597..158f8da6fd 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -1132,6 +1132,16 @@ static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg)
     if ( ret < 0 )
         goto error;
 
+    if ( load.type == KEXEC_TYPE_DEFAULT_EFI ||
+         load.type == KEXEC_TYPE_CRASH_EFI )
+    {
+        ret = kimage_setup_purgatory(kimage, load.parameters);
+        if (ret)
+            return ret;
+    }
+
+    kimage_terminate(kimage);
+
     ret = kexec_load_slot(kimage);
     if ( ret < 0 )
         goto error;
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
index 9961eac187..212f5bd068 100644
--- a/xen/common/kimage.c
+++ b/xen/common/kimage.c
@@ -19,10 +19,23 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
+#define KIMAGE_SHA256_REGIONS 16
+
+typedef struct
+{
+    uint64_t start;
+    uint64_t len;
+}
+sha256_region_t;
+
 /*
  * When kexec transitions to the new kernel there is a one-to-one
  * mapping between physical and virtual addresses.  On processors
@@ -214,17 +227,12 @@ 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,
-                              xen_kexec_segment_t *segments)
+static int do_kimage_crash_alloc(struct kexec_image **rimage, paddr_t entry,
+                                 unsigned long nr_segments,
+                                 xen_kexec_segment_t *segments)
 {
     unsigned long i;
 
-    /* Verify we have a valid entry point */
-    if ( (entry < kexec_crash_area.start)
-         || (entry > kexec_crash_area.start + kexec_crash_area.size))
-        return -EADDRNOTAVAIL;
-
     /*
      * Verify we have good destination addresses.  Normally
      * the caller is responsible for making certain we don't
@@ -254,6 +262,25 @@ static int kimage_crash_alloc(struct kexec_image **rimage, paddr_t entry,
                            KEXEC_TYPE_CRASH);
 }
 
+static int kimage_crash_alloc(struct kexec_image **rimage, paddr_t entry,
+                              unsigned long nr_segments,
+                              xen_kexec_segment_t *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);
+}
+
+static int kimage_crash_alloc_efi(struct kexec_image **rimage, paddr_t entry,
+                                  unsigned long nr_segments,
+                                  xen_kexec_segment_t *segments)
+{
+    return do_kimage_crash_alloc(rimage, entry, nr_segments, segments);
+}
+
 static int kimage_is_destination_range(struct kexec_image *image,
                                        paddr_t start,
                                        paddr_t end)
@@ -476,7 +503,7 @@ static void kimage_free_extra_pages(struct kexec_image *image)
     kimage_free_page_list(&image->unusable_pages);
 }
 
-static void kimage_terminate(struct kexec_image *image)
+void kimage_terminate(struct kexec_image *image)
 {
     kimage_entry_t *entries;
 
@@ -542,6 +569,8 @@ void kimage_free(struct kexec_image *image)
     kimage_free_all_entries(image);
     kimage_free_page_list(&image->control_pages);
     xfree(image->segments);
+    xfree(image->pi.buffer);
+    xfree(image->pi.sechdrs);
     xfree(image);
 }
 
@@ -748,7 +777,8 @@ 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->buf.h,
+                                     src_offset, schunk);
         memset(dest_va + schunk, 0, dchunk - schunk);
 
         unmap_domain_page(dest_va);
@@ -764,7 +794,8 @@ 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,
+                               xen_kexec_segment_t *segment)
 {
     int result = -ENOMEM;
     paddr_t addr;
@@ -802,11 +833,16 @@ int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch,
     switch( type )
     {
     case KEXEC_TYPE_DEFAULT:
+    case KEXEC_TYPE_DEFAULT_EFI:
         result = kimage_normal_alloc(rimage, entry_maddr, nr_segments, segment);
         break;
     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;
@@ -829,7 +865,6 @@ int kimage_load_segments(struct kexec_image *image)
         if ( result < 0 )
             return result;
     }
-    kimage_terminate(image);
     return 0;
 }
 
@@ -938,6 +973,579 @@ done:
     return ret;
 }
 
+static int kimage_purgatory_alloc(struct kexec_image *image)
+{
+    const Elf_Ehdr *ehdr = (const Elf_Ehdr *)kexec_purgatory;
+    const Elf_Shdr *sechdrs;
+    unsigned long bss_align;
+    unsigned long bss_sz;
+    unsigned long align;
+    int i;
+    struct purgatory_info *pi = &image->pi;
+
+    dprintk(XENLOG_DEBUG, "purgatory_alloc 0x%lx 0x%lx %u\n",
+            (unsigned long)kexec_purgatory, (unsigned long)ehdr,
+            kexec_purgatory_size);
+
+    sechdrs = (void *)ehdr + ehdr->e_shoff;
+    pi->buf_align = bss_align = 1;
+    pi->bufsz = bss_sz = 0;
+
+    for ( i = 0; i < ehdr->e_shnum; i++ ) {
+        if ( !(sechdrs[i].sh_flags & SHF_ALLOC) )
+            continue;
+
+        align = sechdrs[i].sh_addralign;
+        if ( sechdrs[i].sh_type != SHT_NOBITS ) {
+            if ( pi->buf_align < align )
+                pi->buf_align = align;
+            pi->bufsz = ROUNDUP(pi->bufsz, align);
+            pi->bufsz += sechdrs[i].sh_size;
+        } else {
+            if ( bss_align < align )
+                bss_align = align;
+            bss_sz = ROUNDUP(bss_sz, align);
+            bss_sz += sechdrs[i].sh_size;
+        }
+    }
+    pi->bufsz = ROUNDUP(pi->bufsz, bss_align);
+    pi->memsz = pi->bufsz + bss_sz;
+    if ( pi->buf_align < bss_align )
+        pi->buf_align = bss_align;
+
+    pi->buffer = xzalloc_bytes(pi->bufsz);
+    if ( !pi->buffer )
+        return -ENOMEM;
+
+    return 0;
+}
+
+static int kimage_purgatory_copy(struct kexec_image *image)
+{
+    unsigned long bss_addr;
+    unsigned long offset;
+    unsigned long align;
+    size_t sechdrs_size;
+    Elf_Shdr *sechdrs;
+    int i;
+    struct purgatory_info *pi = &image->pi;
+    const Elf_Ehdr *ehdr = (const Elf_Ehdr *)kexec_purgatory;
+    const char *shstrtab;
+
+    /*
+     * The section headers in kexec_purgatory are read-only. In order to
+     * have them modifiable make a temporary copy.
+     */
+    sechdrs_size = sizeof(Elf_Shdr) * ehdr->e_shnum;
+    sechdrs = xmalloc_bytes(sechdrs_size);
+    if ( !sechdrs )
+        return -ENOMEM;
+
+    memcpy(sechdrs, (void *)ehdr + ehdr->e_shoff, sechdrs_size);
+    pi->sechdrs = sechdrs;
+
+    shstrtab = (char *)ehdr + sechdrs[ehdr->e_shstrndx].sh_offset;
+
+    offset = 0;
+    bss_addr = pi->dest + pi->bufsz;
+    image->entry_maddr = ehdr->e_entry;
+
+    for ( i = 0; i < ehdr->e_shnum; i++ ) {
+        if ( !(sechdrs[i].sh_flags & SHF_ALLOC) )
+            continue;
+
+        align = sechdrs[i].sh_addralign;
+        if ( sechdrs[i].sh_type == SHT_NOBITS ) {
+            bss_addr = ROUNDUP(bss_addr, align);
+            sechdrs[i].sh_addr = bss_addr;
+            bss_addr += sechdrs[i].sh_size;
+            continue;
+        }
+
+        offset = ROUNDUP(offset, align);
+
+        if ( sechdrs[i].sh_flags & SHF_EXECINSTR &&
+                ehdr->e_entry >= sechdrs[i].sh_addr &&
+                ehdr->e_entry < (sechdrs[i].sh_addr + sechdrs[i].sh_size) ) {
+            BUG_ON(image->entry_maddr != ehdr->e_entry);
+            image->entry_maddr -= sechdrs[i].sh_addr;
+            image->entry_maddr += pi->dest + offset;
+        }
+
+        memcpy(pi->buffer + offset,
+               (void *)ehdr + sechdrs[i].sh_offset,
+               sechdrs[i].sh_size);
+
+        sechdrs[i].sh_addr = pi->dest + offset;
+        sechdrs[i].sh_offset = offset;
+        offset += sechdrs[i].sh_size;
+
+        dprintk(XENLOG_DEBUG, "Load %s at 0x%08lx\n",
+                shstrtab + sechdrs[i].sh_name, sechdrs[i].sh_addr);
+    }
+
+    dprintk(XENLOG_DEBUG, "image entry maddr 0x%lx\n", image->entry_maddr);
+
+    return 0;
+}
+
+static int kimage_purgatory_apply_relocations(struct kexec_image *image)
+{
+    const Elf_Ehdr *ehdr = (const Elf_Ehdr *)kexec_purgatory;
+    int i, ret;
+    struct purgatory_info *pi = &image->pi;
+    const Elf_Shdr *sechdrs;
+
+    sechdrs = (void *)ehdr + ehdr->e_shoff;
+
+    for ( i = 0; i < ehdr->e_shnum; i++ ) {
+        const Elf_Shdr *relsec;
+        const Elf_Shdr *symtab;
+        Elf_Shdr *section;
+
+        relsec = sechdrs + i;
+
+        if ( relsec->sh_type != SHT_RELA &&
+                relsec->sh_type != SHT_REL )
+            continue;
+
+        /*
+         * For section of type SHT_RELA/SHT_REL,
+         * ->sh_link contains section header index of associated
+         * symbol table. And ->sh_info contains section header
+         * index of section to which relocations apply.
+         */
+        if ( relsec->sh_info >= ehdr->e_shnum ||
+                relsec->sh_link >= ehdr->e_shnum )
+            return -ENOEXEC;
+
+        section = pi->sechdrs + relsec->sh_info;
+        symtab = sechdrs + relsec->sh_link;
+
+        if ( !(section->sh_flags & SHF_ALLOC) )
+            continue;
+
+        /*
+         * symtab->sh_link contain section header index of associated
+         * string table.
+         */
+        if ( symtab->sh_link >= ehdr->e_shnum )
+            /* Invalid section number? */
+            continue;
+
+        /*
+         * Respective architecture needs to provide support for applying
+         * relocations of type SHT_RELA.
+         */
+        if ( relsec->sh_type == SHT_RELA )
+            ret = arch_kexec_apply_relocations_add(pi, section,
+                    relsec, symtab);
+        else if ( relsec->sh_type == SHT_REL )
+            ret = -ENOEXEC;
+        if ( ret )
+            return ret;
+    }
+
+    return 0;
+}
+
+static const Elf_Sym *kimage_purgatory_find_symbol(const char *name)
+{
+    const Elf_Shdr *sechdrs;
+    const Elf_Ehdr *ehdr = (const Elf_Ehdr *)kexec_purgatory;
+    const Elf_Sym *syms;
+    const char *strtab;
+    int i, k;
+
+    sechdrs = (void *)ehdr + ehdr->e_shoff;
+
+    for ( i = 0; i < ehdr->e_shnum; i++ ) {
+        if ( sechdrs[i].sh_type != SHT_SYMTAB )
+            continue;
+
+        if ( sechdrs[i].sh_link >= ehdr->e_shnum )
+            /* Invalid strtab section number */
+            continue;
+
+        strtab = (void *)ehdr + sechdrs[sechdrs[i].sh_link].sh_offset;
+        syms = (void *)ehdr + sechdrs[i].sh_offset;
+
+        /* Go through symbols for a match */
+        for ( k = 0; k < sechdrs[i].sh_size/sizeof(Elf_Sym); k++ ) {
+            if ( ELF_ST_BIND(syms[k].st_info) != STB_GLOBAL )
+                continue;
+
+            if ( strcmp(strtab + syms[k].st_name, name) != 0 )
+                continue;
+
+            if ( syms[k].st_shndx == SHN_UNDEF ||
+                    syms[k].st_shndx >= ehdr->e_shnum ) {
+                printk("Symbol: %s has bad section index %d.\n",
+                        name, syms[k].st_shndx);
+                return NULL;
+            }
+
+            /* Found the symbol we are looking for */
+            return &syms[k];
+        }
+    }
+
+    return NULL;
+}
+
+static int kimage_purgatory_get_symbol_addr(struct kexec_image *image,
+                                            const char *name, void **addr)
+{
+    struct purgatory_info *pi = &image->pi;
+    const Elf_Sym *sym;
+    Elf_Shdr *sechdr;
+
+    sym = kimage_purgatory_find_symbol(name);
+    if ( !sym )
+        return -EINVAL;
+
+    sechdr = &pi->sechdrs[sym->st_shndx];
+
+    /*
+     * Update addr with the address where symbol will finally be loaded after
+     * kimage_purgatory_move()
+     */
+    *addr = (void *)(sechdr->sh_addr + sym->st_value);
+    return 0;
+}
+
+/*
+ * Get or set value of a symbol. If "get_value" is true, symbol value is
+ * returned in buf otherwise symbol value is set based on value in buf.
+ */
+static int kimage_purgatory_get_set_symbol(struct kexec_image *image, const char *name,
+				   void *buf, unsigned int size, bool get_value)
+{
+    struct purgatory_info *pi = &image->pi;
+    const Elf_Sym *sym;
+    Elf_Shdr *sec;
+    char *sym_buf;
+
+    sym = kimage_purgatory_find_symbol(name);
+    if ( !sym )
+        return -EINVAL;
+
+    if ( sym->st_size != size ) {
+        printk("symbol %s size mismatch: expected %lu actual %u\n",
+                name, (unsigned long)sym->st_size, size);
+        return -EINVAL;
+    }
+
+    sec = pi->sechdrs + sym->st_shndx;
+
+    if ( sec->sh_type == SHT_NOBITS ) {
+        printk("symbol %s is in a bss section. Cannot %s\n", name,
+                get_value ? "get" : "set");
+        return -EINVAL;
+    }
+
+    sym_buf = (char *)pi->buffer + sec->sh_offset + sym->st_value;
+
+    if ( get_value )
+        memcpy((void *)buf, sym_buf, size);
+    else
+        memcpy((void *)sym_buf, buf, size);
+
+    return 0;
+}
+
+static int kimage_purgatory_find_hole(struct kexec_image *image)
+{
+    paddr_t hole_start, hole_end, mstart, mend;
+    struct purgatory_info *pi = &image->pi;
+    unsigned long i;
+
+    pi->dest = 0;
+    hole_start = PAGE_ALIGN(image->next_crash_page);
+    hole_end = hole_start + pi->memsz;
+    while ( hole_end <= kexec_crash_area.start + kexec_crash_area.size )
+    {
+        /* See if the hole overlaps any of the segments. */
+        for ( i = 0; i < image->nr_segments; i++ )
+        {
+            mstart = image->segments[i].dest_maddr;
+            mend   = mstart + image->segments[i].dest_size;
+            if ( (hole_end > mstart) && (hole_start < mend) )
+            {
+                /* Advance the hole to the end of the segment. */
+                hole_start = PAGE_ALIGN(mend);
+                hole_end = hole_start + pi->memsz;
+                break;
+            }
+        }
+
+        /* If the hole doesn't overlap any segments I have found my hole! */
+        if ( i == image->nr_segments &&
+             hole_end <= kexec_crash_area.start + kexec_crash_area.size )
+        {
+            pi->dest = hole_start;
+            image->next_crash_page = PAGE_ALIGN(hole_end);
+            break;
+        }
+    }
+
+    return pi->dest;
+}
+
+/* Load purgatory as an ELF binary and relocate it. */
+static int kimage_load_purgatory_image(struct kexec_image *image)
+{
+    int ret;
+
+    ret = kimage_purgatory_alloc(image);
+    if ( ret )
+        return ret;
+
+    ret = kimage_purgatory_find_hole(image);
+    if ( !ret )
+        return -ENOMEM;
+
+    ret = kimage_purgatory_copy(image);
+    if ( ret )
+        return ret;
+
+    ret = kimage_purgatory_apply_relocations(image);
+    if ( ret )
+        return ret;
+
+    return 0;
+}
+
+/*
+ * Update the loaded purgatory with the digest and locations of the segments.
+ */
+static int kimage_purgatory_calc_one_digest(struct sha2_256_state *ctx,
+                                            struct kimage_segment *segment)
+{
+    paddr_t dest;
+    unsigned long sbytes;
+    unsigned int dest_offset;
+    int ret = 0;
+
+    sbytes = segment->buf_size;
+    dest = segment->dest_maddr + segment->dest_offset;
+    dest_offset = segment->dest_offset;
+
+    while ( sbytes )
+    {
+        unsigned long dest_mfn;
+        void *dest_va;
+        size_t schunk, dchunk;
+
+        dest_mfn = dest >> PAGE_SHIFT;
+
+        dchunk = PAGE_SIZE - dest_offset;
+        schunk = min(dchunk, sbytes);
+
+        dest_va = map_domain_page(_mfn(dest_mfn));
+        if ( !dest_va )
+            return -EINVAL;
+
+        sha2_256_update(ctx, dest_va + dest_offset, schunk);
+
+        unmap_domain_page(dest_va);
+        if ( ret )
+            return -EFAULT;
+
+        sbytes -= schunk;
+        dest += dchunk;
+        dest_offset = 0;
+    }
+    return 0;
+}
+
+static int kimage_purgatory_calc_digest(struct kexec_image *image)
+{
+    int ret;
+    sha256_region_t regions[KIMAGE_SHA256_REGIONS] = {{0}};
+    struct sha2_256_state ctx;
+    uint8_t digest[SHA2_256_DIGEST_SIZE];
+    unsigned int s;
+
+    if ( image->nr_segments > KIMAGE_SHA256_REGIONS )
+    {
+        dprintk(XENLOG_DEBUG, "More segments than allocated SHA256 regions\n");
+        return -E2BIG;
+    }
+
+
+    sha2_256_init(&ctx);
+
+    for ( s = 0; s < image->nr_segments; s++ ) {
+        ret = kimage_purgatory_calc_one_digest(&ctx, &image->segments[s]);
+        if ( ret )
+            return ret;
+
+        regions[s].start = image->segments[s].dest_maddr +
+                           image->segments[s].dest_offset;
+        regions[s].len = image->segments[s].buf_size;
+    }
+
+    sha2_256_final(&ctx, digest);
+
+    ret = kimage_purgatory_get_set_symbol(image, "sha256_regions",
+                                          regions, sizeof(regions), 0);
+    if ( ret )
+        return ret;
+
+    ret = kimage_purgatory_get_set_symbol(image, "sha256_digest",
+                                          &digest, sizeof(digest), 0);
+    if ( ret )
+        return ret;
+
+    return 0;
+}
+
+/*
+ * 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
+static uint64_t kimage_find_kernel_entry_maddr(struct kexec_image *image)
+{
+    uint64_t alignment_addr;
+    uint32_t alignment;
+    unsigned long dest_mfn;
+    void *dest_va;
+
+    alignment_addr = image->segments[KERNEL_SEGMENT_IDX].dest_maddr +
+                         image->segments[KERNEL_SEGMENT_IDX].dest_offset +
+                         offsetof(struct setup_header, kernel_alignment);
+
+    dest_mfn = alignment_addr >> PAGE_SHIFT;
+    dest_va = map_domain_page(_mfn(dest_mfn));
+    if ( !dest_va )
+        return -EINVAL;
+
+    alignment = *((uint32_t *) ((uint8_t *) dest_va +
+                                                PAGE_OFFSET(alignment_addr)));
+
+    unmap_domain_page(dest_va);
+
+    /*
+     * Ensure the kernel alignment is a valid LOAD_PHYSICAL_ADDR,
+     * which ranges from 0x200000 (2MiB) to 0x1000000 (16Mib) on 64-bit systems
+     * as defined in the kernel x86 Kconfig
+     */
+    if ( alignment % 0x200000 != 0 ||
+         alignment < 0x200000 ||
+         alignment > 0x1000000 )
+        return -EINVAL;
+
+    return ROUNDUP(image->segments[KERNEL_SEGMENT_IDX].dest_maddr +
+                       image->segments[KERNEL_SEGMENT_IDX].dest_offset,
+                   alignment) +
+                   0x200;
+}
+
+/*
+ * Configure purgatory with the register values that will be set before jumping
+ * into the new kernel.
+ */
+static int kimage_purgatory_set_register_block(struct kexec_image *image, uint64_t parameters)
+{
+    int ret;
+    uint64_t rip;
+    void *stack;
+
+    rip = kimage_find_kernel_entry_maddr(image);
+    if ( rip < 0 )
+        return -EINVAL;
+
+    ret = kimage_purgatory_get_symbol_addr(image, "stack_end", &stack);
+    BUG_ON(ret < 0);
+
+    /* Clear the registers */
+    memset(&image->regs, 0, sizeof(image->regs));
+
+    image->regs.rsp = (uint64_t)stack;
+    image->regs.rsi = parameters;  // Kernel parameters
+    image->regs.rip = rip;
+
+    return kimage_purgatory_get_set_symbol(image, "entry64_regs",
+                                           &image->regs, sizeof(image->regs),
+                                           0);
+}
+
+/*
+ * Move the loaded purgatory into its final destination as an additional kimage
+ * segment.
+ */
+static int kimage_purgatory_move(struct kexec_image *image)
+{
+    struct purgatory_info *pi = &image->pi;
+    paddr_t dest;
+    unsigned long sbytes;
+    unsigned long src_offset = 0;
+    int result = 0;
+    paddr_t addr;
+
+    sbytes = pi->bufsz;
+    dest = pi->dest;
+
+    while ( dest < (pi->dest + pi->memsz) )
+    {
+        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));
+        if ( !dest_va )
+            return -EINVAL;
+
+        memcpy(dest_va, pi->buffer + src_offset, schunk);
+        memset(dest_va + schunk, 0, dchunk - schunk);
+
+        unmap_domain_page(dest_va);
+
+        sbytes -= schunk;
+        dest += dchunk;
+        src_offset += schunk;
+    }
+
+    for ( addr = pi->dest & PAGE_MASK;
+          addr < pi->dest + pi->memsz; addr += PAGE_SIZE ) {
+        result = machine_kexec_add_page(image, addr, addr);
+        if ( result < 0 )
+            break;
+    }
+
+    return result;
+}
+
+int kimage_setup_purgatory(struct kexec_image *image, uint64_t parameters)
+{
+    int ret;
+
+    ret = kimage_load_purgatory_image(image);
+    if ( ret )
+        return ret;
+
+    ret = kimage_purgatory_calc_digest(image);
+    if ( ret )
+        return ret;
+
+    ret = kimage_purgatory_set_register_block(image, parameters);
+    if ( ret )
+        return ret;
+
+    ret = kimage_purgatory_move(image);
+    if ( ret )
+        return ret;
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/public/kexec.h b/xen/include/public/kexec.h
index 40d79e936b..9bc94c6fd6 100644
--- a/xen/include/public/kexec.h
+++ b/xen/include/public/kexec.h
@@ -56,15 +56,24 @@
 /*
  * Kexec supports two types of operation:
  * - kexec into a regular kernel, very similar to a standard reboot
- *   - KEXEC_TYPE_DEFAULT is used to specify this type
+ *   - KEXEC_TYPE_DEFAULT or KEXEC_TYPE_DEFAULT_EFI are used to specify
+ *     this type
+ *   - in case of KEXEC_TYPE_DEFAULT_EFI the first segment will
+ *     point to full kernel to load and entry point will point to
+ *     parameters
  * - 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
+ *   - see above for differences between KEXEC_TYPE_CRASH and
+ *     KEXEC_TYPE_CRASH_EFI
  *   - 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_DEFAULT     0
+#define KEXEC_TYPE_CRASH       1
+#define KEXEC_TYPE_DEFAULT_EFI 2
+#define KEXEC_TYPE_CRASH_EFI   3
 
 
 /* The kexec implementation for Xen allows the user to load two
@@ -195,7 +204,11 @@ 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;
+    };
 } 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 348f07f5c8..6626058f8b 100644
--- a/xen/include/xen/kimage.h
+++ b/xen/include/xen/kimage.h
@@ -11,12 +11,45 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #define KEXEC_SEGMENT_MAX 16
 
+extern const char kexec_purgatory[];
+extern const unsigned int kexec_purgatory_size;
+
 typedef paddr_t kimage_entry_t;
 
+struct purgatory_info {
+    uint64_t dest;
+    void *buffer;
+    uint64_t bufsz;
+    uint64_t memsz;
+    uint64_t buf_align;
+    Elf_Shdr *sechdrs;
+};
+
+typedef struct xen_kexec_regs {
+        uint64_t rax;
+        uint64_t rbx;
+        uint64_t rcx;
+        uint64_t rdx;
+        uint64_t rsi;
+        uint64_t rdi;
+        uint64_t rsp;
+        uint64_t rbp;
+        uint64_t r8;
+        uint64_t r9;
+        uint64_t r10;
+        uint64_t r11;
+        uint64_t r12;
+        uint64_t r13;
+        uint64_t r14;
+        uint64_t r15;
+        uint64_t rip;
+} xen_kexec_regs_t;
+
 struct kexec_image {
     uint8_t type;
     uint16_t arch;
@@ -37,6 +70,9 @@ struct kexec_image {
 
     /* Address of next control page to allocate for crash kernels. */
     paddr_t next_crash_page;
+
+    struct purgatory_info pi;
+    xen_kexec_regs_t regs;
 };
 
 int kimage_alloc(struct kexec_image **rimage, uint8_t type, uint16_t arch,
@@ -52,6 +88,12 @@ 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);
+int kimage_setup_purgatory(struct kexec_image *image, uint64_t parameters);
+void kimage_terminate(struct kexec_image *image);
+
+int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
+                                     Elf_Shdr *section, const Elf_Shdr *relsec,
+                                     const Elf_Shdr *symtabsec);
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/xen/include/xen/x86-linux.h b/xen/include/xen/x86-linux.h
new file mode 100644
index 0000000000..940d830323
--- /dev/null
+++ b/xen/include/xen/x86-linux.h
@@ -0,0 +1,62 @@
+/*
+ * This file was extracted from x86-linux.h in kexec-tools
+ *
+ * Copyright (C) 2003-2010  Eric Biederman (ebiederm@xmission.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation (version 2 of the License).
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef X86_LINUX_H
+#define X86_LINUX_H
+
+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;
+};
+
+#endif /* X86_LINUX_H */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed May 07 09:43:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 09:43:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978420.1365246 (Exim 4.92)
	(envelope-from )
	id 1uCbJ7-0006oY-2i; Wed, 07 May 2025 09:43:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978420.1365246; Wed, 07 May 2025 09: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 1uCbJ6-0006nn-Ol; Wed, 07 May 2025 09:43:16 +0000
Received: by outflank-mailman (input) for mailman id 978420;
 Wed, 07 May 2025 09:43:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCbJ5-00062T-Fy
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 09:43:15 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b1dda231-2b27-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 11:43:13 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43cfebc343dso45150755e9.2
 for ; Wed, 07 May 2025 02:43:13 -0700 (PDT)
Received: from localhost.localdomain (172.74.6.51.dyn.plus.net. [51.6.74.172])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a099b16f00sm16051290f8f.84.2025.05.07.02.43.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 02:43:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b1dda231-2b27-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746610993; x=1747215793; 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;
        bh=CL/ZVVVxEx78jS9Cw9s8DTLqhKzVHZ6dBkuD0mXe5Pk=;
        b=EtCFLM3H5hV+FgUdAJ2uLQhOp+lCrRFzszRvJqNIzCEPZe+PdWbe1bsYra4e7T7dM9
         r4j2PKTFehYclm13Xa69B6jQ3QKaeSdhZwx6H0gVAGh96witL9DiXdL0P/nsxcfi9vTX
         A8NUzbDXaULe2hzvG3/lSopIa0YVDvN4pyRiencZ0NhKPiVEyGRNYRusvdwNESiJOoVJ
         wEq9Ks9ebB2Hn/JqWkxqx1yAPwnir1QsLu+G2zZFimdwilvK1G/TAnPYLDfaWTnhl6LY
         cyeTNnXlYWtCyBYN+DLV6hEiB7JI663sBxpvR5AltXjsxTTY0NqOTW1bGHupVD44rF+M
         9D6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746610993; x=1747215793;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=CL/ZVVVxEx78jS9Cw9s8DTLqhKzVHZ6dBkuD0mXe5Pk=;
        b=C3rHXFbeZ248FRVL+kp7XpXkep/IpWefkSaCYApsxjzRqgwG010p9no0w4edxS4l45
         tXiyNQT/fQr3zIVmdlZDpVb+GRabCh8ceDiro41Gz4aYfhp4bV8JURsDP+k/LM2AYTzG
         K1//HPWFrGovszO9Buyq7lctB+WP4RRYyy3nhwpI1dICneADvm8wpY/PKT0uBuOsYjRP
         rQyCJ86pJHGJSCFy4coXaHAvIxVojHRl5/L65etKkYhGjAKQNXz9swJl2SvgVt4SjA6V
         34QKnLoEUsozMpSCnsAwMhG0gxncoBDKeTaOV4JhuaGRHnP7fwR9v/p1sqmnFXt7FKJL
         +J+g==
X-Gm-Message-State: AOJu0Yzb2e8XRtQF0wB28ApTpt2JB5VJM26t+xt9W98dqZ/5+Q6Oy9YE
	40P+H+0du11hVRix5DtXjML/XVzSQXP6FrxqL1fRqVHW2MYY/d07rdS582XobA0=
X-Gm-Gg: ASbGncs5dx9MlVqWFDNAgb89LQORlEuYEdqBWmjZ4nhfUCB2xrjfO2FFrk29KoKeB09
	h9qzsCYXLIq9i5xlhhtWpLv6aWamMwzIY+PLM94PATxxIQ2Tv4b8XAwx87V+SwbcGLJbbTM38Yx
	4pgBbGBAf/UwhKG8LczSUZbNjl41e+5I9gTlMh/E/eV5XrR1GFmVimse2eV+y82XNsDuSEvfNR8
	tOXLQOCBvuwNWOp8nQltnCSJLV1jJVyy1eIijrCoF7PeZeHtqIMcq2qRxymGye1gZ+8nbEoqO+u
	tzWkP6Iy99WZvWvTZSsy5jIQoFiwr9zbUW0pMGAI1z37pyiVmxwS3f2B2EKSETCEU7ttUIosx2d
	EpgWq/UY=
X-Google-Smtp-Source: AGHT+IFnh7HIuyj9gVufq4X9Yg9+nJEUrlpMCQNzd042cCEhvk4KRLaC+BeppB1APVtjXQo8/3PvhQ==
X-Received: by 2002:a05:600c:3f0d:b0:441:d228:1fe5 with SMTP id 5b1f17b1804b1-441d44e5896mr13778825e9.33.1746610992804;
        Wed, 07 May 2025 02:43:12 -0700 (PDT)
From: Frediano Ziglio 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Andrew Cooper 
Subject: [PATCH v2 4/4] kexec: Support non-page-aligned kexec segments
Date: Wed,  7 May 2025 10:42:49 +0100
Message-ID: <20250507094253.10395-5-freddy77@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250507094253.10395-1-freddy77@gmail.com>
References: <20250507094253.10395-1-freddy77@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

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 
---
 xen/common/kexec.c       | 23 +++++++-----
 xen/common/kimage.c      | 81 +++++++++++++++++++++-------------------
 xen/include/xen/kimage.h | 15 +++++++-
 3 files changed, 70 insertions(+), 49 deletions(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 158f8da6fd..a7b3958c74 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -910,7 +910,7 @@ static uint16_t kexec_load_v1_arch(void)
 }
 
 static int kexec_segments_add_segment(unsigned int *nr_segments,
-                                      xen_kexec_segment_t *segments,
+                                      struct kimage_segment *segments,
                                       mfn_t mfn)
 {
     paddr_t maddr = mfn_to_maddr(mfn);
@@ -936,7 +936,7 @@ static int kexec_segments_add_segment(unsigned int *nr_segments,
 
 static int kexec_segments_from_ind_page(mfn_t mfn,
                                         unsigned int *nr_segments,
-                                        xen_kexec_segment_t *segments,
+                                        struct kimage_segment *segments,
                                         bool compat)
 {
     void *page;
@@ -991,7 +991,7 @@ done:
 static int kexec_do_load_v1(xen_kexec_load_v1_t *load, int compat)
 {
     struct kexec_image *kimage = NULL;
-    xen_kexec_segment_t *segments;
+    struct kimage_segment *segments;
     uint16_t arch;
     unsigned int nr_segments = 0;
     mfn_t ind_mfn = maddr_to_mfn(load->image.indirection_page);
@@ -1001,7 +1001,7 @@ static int kexec_do_load_v1(xen_kexec_load_v1_t *load, int compat)
     if ( arch == EM_NONE )
         return -ENOSYS;
 
-    segments = xmalloc_array(xen_kexec_segment_t, KEXEC_SEGMENT_MAX);
+    segments = xmalloc_array(struct kimage_segment, KEXEC_SEGMENT_MAX);
     if ( segments == NULL )
         return -ENOMEM;
 
@@ -1103,9 +1103,10 @@ static int kexec_load_v1_compat(XEN_GUEST_HANDLE_PARAM(void) uarg)
 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;
+    unsigned int i;
 
     if ( copy_from_guest(&load, uarg, 1) )
         return -EFAULT;
@@ -1113,14 +1114,18 @@ 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 ( i = 0; i < load.nr_segments; i++ )
     {
-        ret = -EFAULT;
-        goto error;
+        if ( copy_from_guest_offset((xen_kexec_segment_t *)&segments[i],
+                                    load.segments.h, i, 1) )
+        {
+            ret = -EFAULT;
+            goto error;
+        }
     }
 
     ret = kimage_alloc(&kimage, load.type, load.arch, load.entry_maddr,
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
index 212f5bd068..296febeb09 100644
--- a/xen/common/kimage.c
+++ b/xen/common/kimage.c
@@ -96,7 +96,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;
@@ -119,29 +119,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
@@ -221,7 +198,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);
@@ -229,7 +206,7 @@ static int kimage_normal_alloc(struct kexec_image **rimage, paddr_t entry,
 
 static int do_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;
 
@@ -264,7 +241,7 @@ static int do_kimage_crash_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)
 {
     /* Verify we have a valid entry point */
     if ( (entry < kexec_crash_area.start)
@@ -276,7 +253,7 @@ static int kimage_crash_alloc(struct kexec_image **rimage, paddr_t entry,
 
 static int kimage_crash_alloc_efi(struct kexec_image **rimage, paddr_t entry,
                                   unsigned long nr_segments,
-                                  xen_kexec_segment_t *segments)
+                                  struct kimage_segment *segments)
 {
     return do_kimage_crash_alloc(rimage, entry, nr_segments, segments);
 }
@@ -694,16 +671,18 @@ 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;
+    unsigned int dest_offset;
     paddr_t dest, end;
     int ret;
 
     to_copy = segment->buf_size;
     src_offset = 0;
     dest = segment->dest_maddr;
+    dest_offset = segment->dest_offset;
 
     ret = kimage_set_destination(image, dest);
     if ( ret < 0 )
@@ -718,7 +697,7 @@ static int kimage_load_normal_segment(struct kexec_image *image,
 
         dest_mfn = dest >> PAGE_SHIFT;
 
-        size = min_t(unsigned long, PAGE_SIZE, to_copy);
+        size = min_t(unsigned long, PAGE_SIZE - dest_offset, to_copy);
 
         page = kimage_alloc_page(image, dest);
         if ( !page )
@@ -728,7 +707,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 + dest_offset, segment->buf.h, src_offset, size);
         unmap_domain_page(dest_va);
         if ( ret )
             return -EFAULT;
@@ -736,6 +715,7 @@ static int kimage_load_normal_segment(struct kexec_image *image,
         to_copy -= size;
         src_offset += size;
         dest += PAGE_SIZE;
+        dest_offset = 0;
     }
 
     /* Remainder of the destination should be zeroed. */
@@ -747,7 +727,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
@@ -755,12 +735,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 )
     {
@@ -770,14 +752,16 @@ 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->buf.h,
+        if ( dest_offset )
+            memset(dest_va, 0, dest_offset);
+        ret = copy_from_guest_offset(dest_va + dest_offset, segment->buf.h,
                                      src_offset, schunk);
         memset(dest_va + schunk, 0, dchunk - schunk);
 
@@ -785,17 +769,18 @@ static int kimage_load_crash_segment(struct kexec_image *image,
         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;
 }
 
 static int kimage_load_segment(struct kexec_image *image,
-                               xen_kexec_segment_t *segment)
+                               struct kimage_segment *segment)
 {
     int result = -ENOMEM;
     paddr_t addr;
@@ -826,9 +811,29 @@ static int kimage_load_segment(struct kexec_image *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)
 {
     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 )
     {
diff --git a/xen/include/xen/kimage.h b/xen/include/xen/kimage.h
index 6626058f8b..3099b489b5 100644
--- a/xen/include/xen/kimage.h
+++ b/xen/include/xen/kimage.h
@@ -30,6 +30,17 @@ struct purgatory_info {
     Elf_Shdr *sechdrs;
 };
 
+struct kimage_segment {
+    union {
+        XEN_GUEST_HANDLE(const_void) h;
+        uint64_t _pad;
+    } buf;
+    uint64_t buf_size;
+    uint64_t dest_maddr;
+    uint64_t dest_size;
+    unsigned int dest_offset;
+};
+
 typedef struct xen_kexec_regs {
         uint64_t rax;
         uint64_t rbx;
@@ -55,7 +66,7 @@ struct kexec_image {
     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;
@@ -77,7 +88,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.43.0



From xen-devel-bounces@lists.xenproject.org Wed May 07 09:54:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 09:54:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978481.1365279 (Exim 4.92)
	(envelope-from )
	id 1uCbTe-0002H8-PA; Wed, 07 May 2025 09:54:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978481.1365279; Wed, 07 May 2025 09:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCbTe-0002H1-Li; Wed, 07 May 2025 09:54:10 +0000
Received: by outflank-mailman (input) for mailman id 978481;
 Wed, 07 May 2025 09:54:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCbTd-0001ot-NB
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 09:54:09 +0000
Received: from PA4PR04CU001.outbound.protection.outlook.com
 (mail-francecentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c20a::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 384c5fbe-2b29-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 11:54:08 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DB9PR03MB9758.eurprd03.prod.outlook.com
 (2603:10a6:10:453::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Wed, 7 May
 2025 09:54:03 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%6]) with mapi id 15.20.8699.026; Wed, 7 May 2025
 09:54: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" 
X-Inumbo-ID: 384c5fbe-2b29-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QM2hhhnU0LWOpFKr82omAXXtWWkifdiqTl6UwLiQY3OZi8NUihAzGSvELvAGGMl4gXF1iU8Hsai1vofuxh7dskanmZwEPzd1VVTiEonaeBL6KdqxNoDGeExk16kkMxD1wg8tyMyukWdsVXdyUoSraoQERvBiWRV5w+SY737SdIHdt9qF0slkZ2AXfeSY4Tykr7IXaatgPS4Od+am4n9bz/0dqT+4dcHjuE3Nl0Jk6ZSHcx0w4hQ7NdCmt/pufGnb0sxfovQtvl88n+XNcSbJxBQd/I8+H4lUMpZdrmysJw1W1oF9gVUvgc4yoCDGJsAkJ4OAUk9YveKJTlkdMOBIog==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=r92ZDh65UNlU18AVSDhGnjWjZLGQfIAHc6+eCdWBjoA=;
 b=e6LUpNqSS85NdL3gAXdA2sZ0Lhr3c68nhF7kiTS+9YCwfYVVtiyFjrKPt6wObDQG3nuuXNB+apfI0OA3K2gy2UW2W0h9lOj1KjmI7WJQtTgcKAPSH3Bd3HzCv2NNK8qQcQVbMoRuypGeHPh4fGmubLM6mBJu5hAU7JYvgv1+1AWoL7YHP8wXi7HoTj1FcCAoW9e+zw0cynwcScSPSoHDDz5lsjnLDmWN+iVf/cWhAM2OTjxjYu6TM7nI4YdFC6yTbVuyKf8rn928ciABg5r4QV4CwCGdPj1BbBaAweSNhpf3/eZxAzIFcOSH717lB4vIPyBs5kcIatvDsxa2XSasVw==
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=r92ZDh65UNlU18AVSDhGnjWjZLGQfIAHc6+eCdWBjoA=;
 b=EcC8H067aLfxGV9Amv8e7CS+aau5kjBc1DMzZhku3DytCUEMMpR9Yo4ccszORm6YTGYM8QXmVJZeWTtVgzXjBxhuykAIEEDm/bxdwP5Nvg6ut8WPLjM5grnaGyH/7VrjR5Y1IABPFysYCo4pHOPb/aamlxYqCn5mYoKjubQZPKG7nYydY/rAdu/8km1I4zhsCDfOtxTUVEu+eIhxSVGsMqKrdFEFA4EBsZE2b5nsRd0johORk5vWCUzqlaV3PYxlxI63oy5EUGGKDVaCa6HJ5NbaB9NWo1YM9+JOZ1AS0R045j9x/ogHdUkdg8tWigkYGV2auz9q1kkhYlxca8p4OA==
From: Volodymyr Babchuk 
To: "xen-devel@lists.xenproject.org" 
CC: Volodymyr Babchuk , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini , Bertrand
 Marquis , Volodymyr Babchuk
	, Dario Faggioli , Juergen
 Gross , George Dunlap 
Subject: [RFC PATCH v3 1/2] xen: add libafl-qemu fuzzer support
Thread-Topic: [RFC PATCH v3 1/2] xen: add libafl-qemu fuzzer support
Thread-Index: AQHbvzX0CPd+DUDhAUOdIQPEjXmDVg==
Date: Wed, 7 May 2025 09:53:59 +0000
Message-ID: <20250507095338.735228-2-volodymyr_babchuk@epam.com>
References: <20250507095338.735228-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20250507095338.735228-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.48.1
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DB9PR03MB9758:EE_
x-ms-office365-filtering-correlation-id: 19f95e5d-cc55-4404-bc73-08dd8d4d198c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?Zc/joKO0eZ7Nq6j1JNpltmbTENDbXTQS1Rue3SCMJ4B18MfBGKncdkOYxW?=
 =?iso-8859-1?Q?1cfHQueNOkucK026CEQhjPNWWJbfsGTyUhyOjcU+qdq48uB9nR/srdSAUA?=
 =?iso-8859-1?Q?MdJ2R6bdCAA68TEz4/xyzA28kWodmVdhe0EsG0xyzLQADRykiQs1TPqGTB?=
 =?iso-8859-1?Q?kFTdJpBSe1GG8r/cA1SEXc9CpLjT5cAWkc8aHoqu4wDro1TbnAJwAulf2S?=
 =?iso-8859-1?Q?0nRxRP0+NRPreY4zK2kaopoHmAKMRU5FqLaK2RlVhsR1y1wz32OsW6SO9I?=
 =?iso-8859-1?Q?WHOY9/4g5AVKyZcF5u0RG+OfCbjs8+cTAzFhw1MajpIKYk2ARWoUYgPaam?=
 =?iso-8859-1?Q?y66hSStJN6u2q63nMMSzHVD35XtEeA7tdNRzsEeUpQ0MCmDAIqxASLjmfc?=
 =?iso-8859-1?Q?+uKJ0m2fhSO5rFR8x6wz4Wq8X7VoUChuzb5SnQNDvkyJ508MBT9fXw5dI0?=
 =?iso-8859-1?Q?n5Q4fTmzODEI0nPz+WUHDqD+RL/rbtGQLb4O0WM7B0qQJs0wOefGpfe9fl?=
 =?iso-8859-1?Q?41f9qJjQdlQVhlnTiJnqQWofrfSo+ZT8/wm/LZMn6t/d8DHbAq6v1a+R6z?=
 =?iso-8859-1?Q?2hZsjshhDmgVl2mPoQz5b4+VevpFGBpcAd2qCHk81UCAo856Nc04cc2zNz?=
 =?iso-8859-1?Q?z+tgCHCNfR7/CeQkeUAJo1KnQM5+h9EESFsyQhYxpVi75xpjmNZfExVozq?=
 =?iso-8859-1?Q?ZgX2L21048ZaP0r7lLpVzM6dsnksOfeRJkD4mQMU/6LOhz+kUfClSok8FA?=
 =?iso-8859-1?Q?7D+nM1y7Gxcn9+UxvrY04TuWOAeWhC62wYbFv+yeTpVt8Xtp1I/mQE+Fg3?=
 =?iso-8859-1?Q?9e2+0b9EKOyOkhbL2+Ewc64lzZhVd0B6HNIBwZNTFGf0dWFaayTqQzwzwY?=
 =?iso-8859-1?Q?2w3IMORaXavOpsddIyMMtJfbhWU9nIeI/VDNwmd8Pbwmp/o9c1FOs5AWP/?=
 =?iso-8859-1?Q?2lhwnyHq2gBQkwRJ7wrPbbgl9XiKjXngrOVFesdKNbAXvuwzlU+jmGcJfO?=
 =?iso-8859-1?Q?T7MXdbrkwVJTEnNsDAIK1YoienFq+Q54zqq8d3fTYhF6wIpoDqm9EHpzZp?=
 =?iso-8859-1?Q?2CW91+74cg1Nxv/MWSvOXHjQs915h3rDH5C6yJVbodTcNP8KUjh80oQ5Lx?=
 =?iso-8859-1?Q?ENHakD4zwLdzXPBqFmpDV9/fVOfU80KgRWc09+ueGrpWLCkgV5C31RIZS+?=
 =?iso-8859-1?Q?PiFQbzzSGYRY61paSSf3owmUtAcdyG/EaC8ZFMjlK4Wcc/OCGoccC0JTGa?=
 =?iso-8859-1?Q?xz5Fb0SHkWJ7ssqorfluZVpAUMgm+W6BpzE3uoAS0tZeP9uEsx7trfBmsy?=
 =?iso-8859-1?Q?omHBu/NTl62NsTr6IEDvnMJF9zWizWib5bnl0kxcps3F9Z6Q4eVkjO9jg7?=
 =?iso-8859-1?Q?fCm4CXBDhBAUmi7c4nwZwMAWUC+o//w+IXdw9lvr+5yfVZFBbAk+4BaRIP?=
 =?iso-8859-1?Q?lkVh9vdjZvtgiEpa4WHu4jCp9a9cKiBJf5j42hD1oujnrVuUXiImc6ctep?=
 =?iso-8859-1?Q?e2MGjeW6ubnje0vmkXaDKT91ScxWKdprppmX3gO9w8QDyQuYZxCRJkq/5C?=
 =?iso-8859-1?Q?oEQGu3k=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?b+ppHc4/a02L7U1CR/TRCRu/4rrpWhqNYpn1/BfNInNhnXhbtEG3FsFC0N?=
 =?iso-8859-1?Q?k2D64R1r6YXlFiqPza8pg/73E9wFfHu0IFpbs69cqzb80L+JGrFmjMBcWQ?=
 =?iso-8859-1?Q?3Rs7GERIT3BvHT78TpKloebvD0QTmjv86fPq4Ah33RLz5VkbZP/9NfdUWr?=
 =?iso-8859-1?Q?ET4jh8yfXMlEiMONf+VKuNxf06h2T+Zpxs+661DdV92pQz1K/ITQdJ/UCr?=
 =?iso-8859-1?Q?QtI9eNYU1ZFIGGp+SkeSQyUludk87QqP2ACO+Tsc9MmxKipU2kaLc9TCy0?=
 =?iso-8859-1?Q?KOpXssXmOn6Y6G4d06Si1uc/CG55a833LHEF94XwftluzOQkBp9REfdlab?=
 =?iso-8859-1?Q?4gkbbQcG8DejjIWHLl0HJqfisyFJ7PH67Gy1q7prytpwxGsao4DkxG9103?=
 =?iso-8859-1?Q?M9UIap51Aa5b5sOuxdWp0tDyTKELpp0mTKDbHbbCKOypggigrqIV0Pw1PD?=
 =?iso-8859-1?Q?pdpYMka2+PiglgX01Lp2wPS/S6ZGpunJp0b0c4OQLtCqFegGYloYD+vS6G?=
 =?iso-8859-1?Q?UBlWQuOFOuxmb8JC7pf1k+5yGuOFXQqSXJEPkeagBt0PN24UnNmu+Szb1v?=
 =?iso-8859-1?Q?B3rIlibbYWjWsIzKxEtc6hr3POdliS2l7PppA6TO20vNyorWFvTIwzOJ+S?=
 =?iso-8859-1?Q?zJBx3fap8p4AgvRYgr6FYU44i6/KjpX4XulvU4W10P3l8xhu1Bo5dQi2V8?=
 =?iso-8859-1?Q?2ISkeSDL5slihR4zflcEgjXZikk9vqiCSESApCWig5hykIBuDa2HVdgHLz?=
 =?iso-8859-1?Q?fVR1rkQ3Pz0N5FJd88gaYYL/083yWBbPE/HzMZC8ivCzTC+LgVOzi7gZll?=
 =?iso-8859-1?Q?DSK7Vw12AylaOHi9YZgGz95GOR59Zuz6uyOdcdhc6WA9vIg1JPM8Vkb2o9?=
 =?iso-8859-1?Q?PFAAGJTTb7tzUA3e2+givSBS5BLQnMWD9NC/PRh4p90XjuhiQI5FFtIm/1?=
 =?iso-8859-1?Q?b5xJoNLn/KBm6bf4lhCya9UWzLzo7tJetksYhozVMDBPSeKjBgLOI97oi9?=
 =?iso-8859-1?Q?GhuWAEC0FERXnuZfyGGhiCrRMqHdni9/dvy2wOFE0fLVBswzIKcqBOc+Ka?=
 =?iso-8859-1?Q?agYl76MS0qXlPjDSv+/dCKkOlioklK7XMALPUnJFyV3vCBuGqz3ZdOpcM9?=
 =?iso-8859-1?Q?I0tTN7kaMNTsEjhBx5Fw/6WJfNCnPz9ZmmkN5S+Qur1lU9s25UeOCJdSHI?=
 =?iso-8859-1?Q?7641hWOfkP5JxQOlPwbOHQA4NSYbp3onIfBKHhYUaj+9shPqMcUPlhs8Ur?=
 =?iso-8859-1?Q?qCeamKTe6l3iEeSNelaSLDQ74cTxKJ8ZdA3BHUjS5zuarBEGPrEy9D+geq?=
 =?iso-8859-1?Q?mQFnDee8n9Z46Gr4Bp4bSwH1L4Sw1V0VY9eW2ZSJonklQAT7O8rMfkSS6l?=
 =?iso-8859-1?Q?X/YwdYqCmxJNPV6+cAYnf9RsbfGBEBPfOH1JE/k4LIBjW4l9LaqSIqqHJI?=
 =?iso-8859-1?Q?bPSOx4nGyiRP9M5Yw+ljWFs8JAi9kc7pthfludCNKDyo8pyLg6fwxqZNmB?=
 =?iso-8859-1?Q?/kzgyIyNu3ePaLYXUr3/c6epcd1kRDENqgF3ZW3CdvO1IqViPHyTghovsP?=
 =?iso-8859-1?Q?Wlgp3d/+F5gJkgyi3EuWbiCnudpVr5YODt9EAM/7BA0muT3oIBJOxxXyCN?=
 =?iso-8859-1?Q?uE7SqQijiNb/nlJzSODIu8P/IZ9xWKkmO2vMrj7WdNZ+/IsVwljTLoJw?=
 =?iso-8859-1?Q?=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: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 19f95e5d-cc55-4404-bc73-08dd8d4d198c
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 09:53:59.0708
 (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: pagvCWWVGk+ZpTNQ1FM7l8nz+N4IKI6E9tPOOAvcvNvfgug5gnnTD8uSgxaX12QSPpS4hF8Q3z5CizJg1/j/E8QYBHPqai48Tb8ANqyyVkI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9758

LibAFL, which is a part of AFL++ project is a instrument that allows
us to perform fuzzing on beremetal code (Xen hypervisor in this case)
using QEMU as an emulator. It employs QEMU's ability to create
snapshots to run many tests relatively quickly: system state is saved
right before executing a new test and restored after the test is
finished.

This patch adds all necessary plumbing to run aarch64 build of Xen
inside that LibAFL-QEMU fuzzer. While, most of the code is in common
section and can be used by any supported architecture, final calls to
LibAFL-QEMU are arch-specific and were tested only on aarch64 for
now. But LibAFL-QEMU itself supports many different architectures,
including x86_64 and riscv.

>From the Xen perspective we need to do following things:

1. Able to communicate with LibAFL-QEMU fuzzer. This is done by
executing special opcodes, that only LibAFL-QEMU can handle.

2. Use interface from p.1 to tell the fuzzer about code Xen section,
so fuzzer know which part of code to track and gather coverage data.

3. Report fuzzer about crash. This is done in panic() function.

4. Prevent test harness from shooting itself in knee.

Right now test harness is an external component, because we want to
test external Xen interfaces, but it is possible to fuzz internal code
if we want to.

Test harness is implemented XTF-based test-case(s). As test harness
can issue hypercall that shuts itself down, KConfig option
CONFIG_FUZZER_PASS_BLOCKING was added. It basically tells
fuzzer that test was completed successfully if Dom0 tries to shut
itself (or the whole machine) down.

Signed-off-by: Volodymyr Babchuk 

---

Changes in v3:

 - Added fuzzer.h
 - Kconfig entries were reworked to be more generic and support
   other fuzzers in the future
 - Moved all the code into common area, as there is nothing
   arch-specific in it
 - Created arch-specific header file form ARM
 - Removed not used definitions in libafl-qemu.h
 - Removed not used functions from libafl-qemu.c
 - Folded libafl-qemu-defs.h into libafl-qemu.h as we don't
   need two separate headers
 - Aligned code with xen coding style
 - Added SPDX identifiers with MIT license to libafl-* files
---
 docs/hypervisor-guide/fuzzing.rst      | 91 ++++++++++++++++++++++++++
 xen/arch/arm/Kconfig.debug             | 37 +++++++++++
 xen/arch/arm/include/asm/libafl-qemu.h | 48 ++++++++++++++
 xen/arch/arm/psci.c                    |  5 ++
 xen/common/Makefile                    |  1 +
 xen/common/domain.c                    |  3 +
 xen/common/libafl-qemu.c               | 80 ++++++++++++++++++++++
 xen/common/sched/core.c                |  6 ++
 xen/common/shutdown.c                  |  3 +
 xen/drivers/char/console.c             |  3 +
 xen/include/xen/fuzzer.h               | 52 +++++++++++++++
 xen/include/xen/libafl-qemu.h          | 63 ++++++++++++++++++
 12 files changed, 392 insertions(+)
 create mode 100644 docs/hypervisor-guide/fuzzing.rst
 create mode 100644 xen/arch/arm/include/asm/libafl-qemu.h
 create mode 100644 xen/common/libafl-qemu.c
 create mode 100644 xen/include/xen/fuzzer.h
 create mode 100644 xen/include/xen/libafl-qemu.h

diff --git a/docs/hypervisor-guide/fuzzing.rst b/docs/hypervisor-guide/fuzz=
ing.rst
new file mode 100644
index 0000000000..895d858edc
--- /dev/null
+++ b/docs/hypervisor-guide/fuzzing.rst
@@ -0,0 +1,91 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Fuzzing
+=3D=3D=3D=3D=3D=3D=3D
+
+It is possible to use LibAFL-QEMU for fuzzing hypervisor. Right now
+only aarch64 is supported and only hypercall fuzzing is enabled in the
+test harness, but there are plans to add vGIC interface fuzzing, PSCI
+fuzzing and vPL011 fuzzing as well.
+
+
+Principle of operation
+----------------------
+
+LibAFL-QEMU is a part of American Fuzzy lop plus plus (AKA AFL++)
+project. It uses special build of QEMU, that allows to fuzz baremetal
+software like Xen hypervisor or Linux kernel. Basic idea is that we
+have software under test (Xen hypervisor in our case) and a test
+harness application. Test harness uses special protocol to communicate
+with LibAFL outside of QEMU to get input data and report test
+result. LibAFL monitors which branches are taken by Xen and mutates
+input data in attempt to discover new code paths that eventually can
+lead to a crash or other unintended behavior.
+
+LibAFL uses QEMU's `snapshot` feature to run multiple test without
+restarting the whole system every time. This speeds up fuzzing process
+greatly.
+
+So, to try Xen fuzzing we need three components: LibAFL-based fuzzer,
+test harness and Xen itself.
+
+Building Xen for fuzzing with LibAFL-QEMU
+-----------------------------------------
+
+Xen hypervisor should be built with these three options::
+
+  CONFIG_FUZZING=3Dy
+  CONFIG_FUZZER_LIBAFL_QEMU=3Dy
+  CONFIG_FUZZER_PASS_BLOCKING=3Dy
+
+Building LibAFL-QEMU based fuzzer
+---------------------------------
+
+Fuzzer is written in Rust, so you need Rust toolchain and `cargo` tool
+in your system. Please refer to your distro documentation on how to
+obtain them.
+
+Once Rust is ready, fetch and build the fuzzer::
+
+  # git clone https://github.com/xen-troops/xen-fuzzer-rs
+  # cd xen-fuzzer-rs
+  # cargo build
+
+Building test harness
+---------------------
+
+We need to make low-level actions, like issuing random hypercalls, so
+for test harness we use special build of XTF (Xen Testing Framework).
+You can build XTF manually, or let fuzzer to do this::
+
+  # cargo make build_xtf
+
+This fill download and build XTF for ARM.
+
+Running the fuzzer
+------------------
+
+Please refer to README.md that comes with the fuzzer, but the most
+versatile way is to run it like this::
+
+  # target/debug/xen_fuzzer -t 3600 /path/to/xen \
+      target/xtf/tests/arm-vgic-fuzzer/test-mmu64le-arm-vgic-fuzzer
+
+(assuming that you built XTF with `cargo make build_xtf`)
+
+Any inputs that led to crashes will be found in `crashes` directory.
+
+You can replay a crash with `-r` option::
+
+  # target/debug/xen_fuzzer -r crashes/0195e4fc65828c17 run \
+      /path/to/xen \
+      /path/to/harness
+
+
+Fuzzer will return non-zero error code if it encountered any crashes.
+
+TODOs
+-----
+
+ - Add x86 support.
+ - Implement fuzzing of other external hypervisor interfaces.
diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
index 5a03b220ac..1a51c5d221 100644
--- a/xen/arch/arm/Kconfig.debug
+++ b/xen/arch/arm/Kconfig.debug
@@ -190,3 +190,40 @@ config EARLY_PRINTK_INC
 	default "debug-mvebu.inc" if EARLY_UART_MVEBU
 	default "debug-pl011.inc" if EARLY_UART_PL011
 	default "debug-scif.inc" if EARLY_UART_SCIF
+
+config FUZZING
+       bool "Build Xen for fuzzing"
+       help
+          Enable this option only if you are going to run the hypervisor
+	  inside a fuzzer. Do not try to run run Xen built with this option
+	  on any real hardware, because it will likely crash during boot.
+
+choice FUZZER
+       depends on FUZZING
+       prompt "Fuzzer"
+
+config FUZZER_LIBAFL_QEMU
+	depends on ARM_64
+	bool "LibAFL-QEMU"
+	help
+	  This option enables support for LibAFL-QEMU fuzzer. Choose this
+	  option only when you are going to run hypervisor inside LibAFL-QEMU.
+	  Xen will report code section to LibAFL and will report about
+	  crash when it panics.
+
+endchoice
+
+config FUZZER_PASS_BLOCKING
+	depends on FUZZING
+	bool "Fuzzing: Report any attempt to suspend/destroy a domain as a succes=
s"
+	help
+	  When fuzzing hypercalls, a fuzzer might make Xen to do something
+	  that prevents from returning to the caller: reboot or turn off the
+	  machine, block calling vCPU, crash a domain, etc. Depending on
+	  fuzzing goal this may be a valid behavior, but as control is not
+	  returned to the fuzzing harness, it can't tell the fuzzer about
+	  success. With this option enabled, Xen will do this by itself.
+
+          Enable this option only if fuzzing attempt can lead to a
+	  correct stop, like when fuzzing hypercalls or PSCI.
+
diff --git a/xen/arch/arm/include/asm/libafl-qemu.h b/xen/arch/arm/include/=
asm/libafl-qemu.h
new file mode 100644
index 0000000000..9b87eafca9
--- /dev/null
+++ b/xen/arch/arm/include/asm/libafl-qemu.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Arch-specific portions of LibAFL-QEMU interface
+ */
+#ifndef __ASM_ARM_LIBAFL_QEMU_H
+#define __ASM_ARM_LIBAFL_QEMU_H
+
+#define LIBAFL_DEFINE_FUNCTIONS(name, opcode)                           \
+    libafl_word _libafl_##name##_call0(                                 \
+        libafl_word action) {                                           \
+        register unsigned long r0 ASM_REG(0) =3D action;                  =
\
+        __asm__ volatile (                                              \
+            ".word " XSTRINGIFY(opcode) "\n"                            \
+            : "+r"(r0)                                                  \
+            :                                                           \
+            : "memory"                                                  \
+            );                                                          \
+        return r0;                                                      \
+    }                                                                   \
+                                                                        \
+    libafl_word _libafl_##name##_call1(                                 \
+        libafl_word action, libafl_word arg1) {                         \
+        register unsigned long r0 ASM_REG(0) =3D action;                  =
\
+        register unsigned long r1 ASM_REG(1) =3D arg1;                    =
\
+        __asm__ volatile (                                              \
+            ".word " XSTRINGIFY(opcode) "\n"                            \
+            : "+r"(r0)                                                  \
+            : "r"(r1)                                                   \
+            : "memory"                                                  \
+            );                                                          \
+        return r0;                                                      \
+    }                                                                   \
+                                                                        \
+    libafl_word _libafl_##name##_call2(                                 \
+        libafl_word action, libafl_word arg1, libafl_word arg2) {       \
+        register unsigned long r0 ASM_REG(0) =3D action;                  =
\
+        register unsigned long r1 ASM_REG(1) =3D arg1;                    =
\
+        register unsigned long r2 ASM_REG(2) =3D arg2;                    =
\
+        __asm__ volatile (                                              \
+            ".word " XSTRINGIFY(opcode) "\n"                            \
+            : "+r"(r0)                                                  \
+            : "r"(r1), "r"(r2)                                          \
+            : "memory"                                                  \
+            );                                                          \
+        return r0;                                                      \
+    }
+
+#endif
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index b6860a7760..43253b3f71 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -10,6 +10,7 @@
=20
=20
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -62,12 +63,16 @@ void call_psci_cpu_off(void)
=20
 void call_psci_system_off(void)
 {
+    fuzzer_on_block();
+
     if ( psci_ver > PSCI_VERSION(0, 1) )
         arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL);
 }
=20
 void call_psci_system_reset(void)
 {
+    fuzzer_on_block();
+
     if ( psci_ver > PSCI_VERSION(0, 1) )
         arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL);
 }
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..f2fbf54911 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -78,6 +78,7 @@ extra-y :=3D symbols-dummy.o
 obj-$(CONFIG_COVERAGE) +=3D coverage/
 obj-y +=3D sched/
 obj-$(CONFIG_UBSAN) +=3D ubsan/
+obj-$(CONFIG_FUZZER_LIBAFL_QEMU) +=3D libafl-qemu.o
=20
 obj-$(CONFIG_NEEDS_LIBELF) +=3D libelf/
 obj-$(CONFIG_LIBFDT) +=3D libfdt/
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..e63a80c26e 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -5,6 +5,7 @@
  */
=20
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1317,6 +1318,8 @@ int domain_shutdown(struct domain *d, u8 reason)
=20
     spin_unlock(&d->shutdown_lock);
=20
+    fuzzer_on_block();
+
     return 0;
 }
=20
diff --git a/xen/common/libafl-qemu.c b/xen/common/libafl-qemu.c
new file mode 100644
index 0000000000..a09a2931c6
--- /dev/null
+++ b/xen/common/libafl-qemu.c
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: MIT */
+/*
+  This file is based on libafl_qemu_impl.h, libafl_qemu_qemu_arch.h
+  and libafl_qemu_defs.h from LibAFL project.
+*/
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Generates sync exit functions */
+LIBAFL_DEFINE_FUNCTIONS(sync_exit, LIBAFL_SYNC_EXIT_OPCODE)
+
+    void libafl_qemu_end(enum LibaflQemuEndStatus status)
+{
+    _libafl_sync_exit_call1(LIBAFL_QEMU_COMMAND_END, status);
+}
+
+void libafl_qemu_internal_error(void)
+{
+    _libafl_sync_exit_call0(LIBAFL_QEMU_COMMAND_INTERNAL_ERROR);
+}
+
+void lqprintf(const char *fmt, ...)
+{
+    static DEFINE_SPINLOCK(lock);
+    static char buffer[LIBAFL_QEMU_PRINTF_MAX_SIZE] =3D {0};
+    va_list args;
+    int res;
+
+    spin_lock(&lock);
+
+    va_start(args, fmt);
+    res =3D vsnprintf(buffer, LIBAFL_QEMU_PRINTF_MAX_SIZE, fmt, args);
+    va_end(args);
+
+    if ( res >=3D LIBAFL_QEMU_PRINTF_MAX_SIZE )
+    {
+        /* buffer is not big enough, either recompile the target with more=
 */
+        /* space or print less things */
+        libafl_qemu_internal_error();
+    }
+
+    _libafl_sync_exit_call2(LIBAFL_QEMU_COMMAND_LQPRINTF,
+                            (libafl_word)buffer, res);
+    spin_unlock(&lock);
+}
+
+void libafl_qemu_trace_vaddr_range(libafl_word start,
+                                   libafl_word end)
+{
+    _libafl_sync_exit_call2(LIBAFL_QEMU_COMMAND_VADDR_FILTER_ALLOW, start,=
 end);
+}
+
+static int init_afl(void)
+{
+    vaddr_t xen_text_start =3D (vaddr_t)_stext;
+    vaddr_t xen_text_end =3D (vaddr_t)_etext;
+
+    lqprintf("Telling AFL about code section: %lx - %lx\n", xen_text_start=
,
+             xen_text_end);
+
+    libafl_qemu_trace_vaddr_range(xen_text_start, xen_text_end);
+
+    return 0;
+}
+
+__initcall(init_afl);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 9043414290..b109a8de44 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -16,6 +16,7 @@
 #ifndef COMPAT
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1429,6 +1430,8 @@ void vcpu_block(void)
         TRACE_TIME(TRC_SCHED_BLOCK, v->domain->domain_id, v->vcpu_id);
         raise_softirq(SCHEDULE_SOFTIRQ);
     }
+
+    fuzzer_on_block();
 }
=20
 static void vcpu_block_enable_events(void)
@@ -1502,6 +1505,8 @@ static long do_poll(const struct sched_poll *sched_po=
ll)
     TRACE_TIME(TRC_SCHED_BLOCK, d->domain_id, v->vcpu_id);
     raise_softirq(SCHEDULE_SOFTIRQ);
=20
+    fuzzer_on_block();
+
     return 0;
=20
  out:
@@ -1529,6 +1534,7 @@ long vcpu_yield(void)
=20
     TRACE_TIME(TRC_SCHED_YIELD, current->domain->domain_id, current->vcpu_=
id);
     raise_softirq(SCHEDULE_SOFTIRQ);
+
     return 0;
 }
=20
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index c47341b977..8e82678626 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,8 @@ static void noreturn reboot_or_halt(void)
=20
 void hwdom_shutdown(unsigned char reason)
 {
+    fuzzer_on_block();
+
     switch ( reason )
     {
     case SHUTDOWN_poweroff:
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c3150fbdb7..45048351d5 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1289,6 +1290,8 @@ void panic(const char *fmt, ...)
=20
     kexec_crash(CRASHREASON_PANIC);
=20
+    fuzzer_crash();
+
     if ( opt_noreboot )
         machine_halt();
     else
diff --git a/xen/include/xen/fuzzer.h b/xen/include/xen/fuzzer.h
new file mode 100644
index 0000000000..852917fe50
--- /dev/null
+++ b/xen/include/xen/fuzzer.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef XEN__FUZZER_H
+#define XEN__FUZZER_H
+
+#include 
+
+#ifdef CONFIG_FUZZER_LIBAFL_QEMU
+#include 
+#endif
+
+/* Unconditional failure */
+static always_inline void fuzzer_crash(void)
+{
+#ifdef CONFIG_FUZZER_LIBAFL_QEMU
+    libafl_qemu_end(LIBAFL_QEMU_END_CRASH);
+#endif
+}
+
+/* Unconditional success */
+static always_inline void fuzzer_success(void)
+{
+#ifdef CONFIG_FUZZER_LIBAFL_QEMU
+    libafl_qemu_end(LIBAFL_QEMU_END_OK);
+#endif
+}
+
+/*
+ * Conditional success
+ *
+ * Sometimes a fuzzer might make Xen to do something that prevents
+ * from returning to the caller: reboot or turn off the machine, block
+ * calling vCPU, crash a domain, etc. Depending on fuzzing goal this
+ * may be a valid behavior, but as control is not returned to the
+ * fuzzing harness, it can't tell the fuzzer about success, so we need
+ * to do this ourselves.
+ */
+static always_inline void fuzzer_on_block(void)
+{
+#ifdef CONFIG_FUZZER_PASS_BLOCKING
+    fuzzer_success();
+#endif
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/libafl-qemu.h b/xen/include/xen/libafl-qemu.h
new file mode 100644
index 0000000000..f3b32adeca
--- /dev/null
+++ b/xen/include/xen/libafl-qemu.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: MIT */
+#ifndef __XEN_LIBAFL_QEMU_H
+#define __XEN_LIBAFL_QEMU_H
+
+#include 
+#define LIBAFL_QEMU_PRINTF_MAX_SIZE 4096
+
+#define LIBAFL_STRINGIFY(s) #s
+#define XSTRINGIFY(s) LIBAFL_STRINGIFY(s)
+
+#define LIBAFL_SYNC_EXIT_OPCODE 0x66f23a0f
+
+typedef enum LibaflQemuCommand
+{
+  LIBAFL_QEMU_COMMAND_START_VIRT =3D 0,
+  LIBAFL_QEMU_COMMAND_START_PHYS =3D 1,
+  LIBAFL_QEMU_COMMAND_INPUT_VIRT =3D 2,
+  LIBAFL_QEMU_COMMAND_INPUT_PHYS =3D 3,
+  LIBAFL_QEMU_COMMAND_END =3D 4,
+  LIBAFL_QEMU_COMMAND_SAVE =3D 5,
+  LIBAFL_QEMU_COMMAND_LOAD =3D 6,
+  LIBAFL_QEMU_COMMAND_VERSION =3D 7,
+  LIBAFL_QEMU_COMMAND_VADDR_FILTER_ALLOW =3D 8,
+  LIBAFL_QEMU_COMMAND_INTERNAL_ERROR =3D 9,
+  LIBAFL_QEMU_COMMAND_LQPRINTF =3D 10,
+  LIBAFL_QEMU_COMMAND_TEST =3D 11,
+} LibaflExit;
+
+typedef uint64_t libafl_word;
+
+/**
+ * LibAFL QEMU header file.
+ *
+ * This file is a portable header file used to build target harnesses more
+ * conveniently. Its main purpose is to generate ready-to-use calls to
+ * communicate with the fuzzer. The list of commands is available at the b=
ottom
+ * of this file. The rest mostly consists of macros generating the code us=
ed by
+ * the commands.
+ */
+
+enum LibaflQemuEndStatus
+{
+  LIBAFL_QEMU_END_UNKNOWN =3D 0,
+  LIBAFL_QEMU_END_OK =3D 1,
+  LIBAFL_QEMU_END_CRASH =3D 2,
+};
+
+void libafl_qemu_end(enum LibaflQemuEndStatus status);
+
+void libafl_qemu_internal_error(void);
+
+void __attribute__((format(printf, 1, 2))) lqprintf(const char *fmt, ...);
+
+void libafl_qemu_trace_vaddr_range(libafl_word start, libafl_word end);
+
+static always_inline void libafl_qemu_success_on_block(void)
+{
+#ifdef CONFIG_LIBAFL_QEMU_FUZZER_PASS_BLOCKING
+    libafl_qemu_end(LIBAFL_QEMU_END_OK);
+#endif
+}
+
+#endif
--=20
2.48.1


From xen-devel-bounces@lists.xenproject.org Wed May 07 09:54:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 09:54:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978480.1365265 (Exim 4.92)
	(envelope-from )
	id 1uCbTd-0001sL-CS; Wed, 07 May 2025 09:54:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978480.1365265; Wed, 07 May 2025 09: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 1uCbTd-0001sE-8L; Wed, 07 May 2025 09:54:09 +0000
Received: by outflank-mailman (input) for mailman id 978480;
 Wed, 07 May 2025 09:54:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCbTc-0001ot-Kc
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 09:54:08 +0000
Received: from PA4PR04CU001.outbound.protection.outlook.com
 (mail-francecentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c20a::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 37d7500b-2b29-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 11:54:08 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DB9PR03MB9758.eurprd03.prod.outlook.com
 (2603:10a6:10:453::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Wed, 7 May
 2025 09:54:04 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%6]) with mapi id 15.20.8699.026; Wed, 7 May 2025
 09:54: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" 
X-Inumbo-ID: 37d7500b-2b29-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=k+TfH2WvxBU9zIjWbjHpwrysohK17VGiTwN4w8/vNFSqLe8g4cIBHVJqmYTP72rIZMhbJzFfAL9QlZdBMDn5O0eYCLBwOIxHHuHGYuQ9EDBIsgwuk3fUDwFvtyUtU/dRBwJ2PH8pG8fgiZcmg2om9nMI7txfVz4VMn3joUMvjkHE0FvA3xAJ0UmA315Z6OgPOhwELdPk+B39lTdWG04nqBNPjcpdWR4U+BAinIjRtmPmRcp0itbm7E0iG+fFYwyWGctDOADuJSkU0HI8hlud6ZE7+ydH1UFUx/1Mfo3UyCXKhkVSThPvU15WVuRz3cAdLYjU0/YaDo7AcROxfTD5Lw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zrgxLnq+1M27/FdxfIrcQlXl+0orAj7TnE3PgbZ7Cq4=;
 b=N1qY03Z1XNIBfox+fcWYAUBd2cm+U1EBkRURnkiN/hf03n+X8O5HloaFj4kkKWyY9KlEx64vn4Ao7IqhfGrGpHE6X1r5VkER4IQeJAg+4yFdc6zBJuew6T+uGistWxuVvEUJizOSCWmA9Y9J6cyaFYVakKPebIvWbeyDC34GtSXGrK/9zzFEcsBcAQUiFOTm8U9Ff+Ms9yz3X7xcH1sdRP7KO1ZVgSJw793ryJBnQtlUAyxXieAmoXvS7OomHTVuZ7N+FJNl9C8glXmKce+L8N9MbbfYSMZa8HtZa6iocQv3esHoWch2MEqttWSg2MskWCkHK7DoTreIjd4Ua3gYWg==
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=zrgxLnq+1M27/FdxfIrcQlXl+0orAj7TnE3PgbZ7Cq4=;
 b=SF8kKXUjDCeAeXD77DQuthn4q+g4uLiQAoBt3U5H0PO3vFj8aB5k+8zFsmpx40BQZyYh4RGCyrkXZSfQF5kxiCnJxmDsckzrNnDoDESL9ECvhJfQFvELCvODkQGo0yi6C1WWUc3zcJjEAjx3tS94XvBI9ibYjZyGbyFbZ0PAjxxvh9Wy+7ajZ7DIlRnTMesP6wFTdcCz59FwT3C7ZR9QKhAbTqghf7lk00mVQl593pZOCQapLF1TvoUUPwhpRkrPa2fXhmFMG6ZdI02aLVbXQNLxcYcPXXNIYRrOSGj/7oratFzS/T0JHjhHeMw9uWIgaSPEO3ujPNosrO+pp/TMTg==
From: Volodymyr Babchuk 
To: "xen-devel@lists.xenproject.org" 
CC: Volodymyr Babchuk , Doug Goldstein
	, Stefano Stabellini 
Subject: [RFC PATCH v3 2/2] ci: enable fuzzing for arm64
Thread-Topic: [RFC PATCH v3 2/2] ci: enable fuzzing for arm64
Thread-Index: AQHbvzX0DP4RwWsFtkCwrnnT9nV/Vg==
Date: Wed, 7 May 2025 09:53:59 +0000
Message-ID: <20250507095338.735228-3-volodymyr_babchuk@epam.com>
References: <20250507095338.735228-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20250507095338.735228-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.48.1
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DB9PR03MB9758:EE_
x-ms-office365-filtering-correlation-id: e660225e-bb95-4451-2ede-08dd8d4d19d8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?tOP918BPqxIgCrNFZb34sfST1Bc84Xoq9p0gAuK9oCPzAjZ8eq1IBScJ9A?=
 =?iso-8859-1?Q?YQkQCnqKNquMrcUBHX+RrVhzIps4j6sfLkMOx8/FU+/yGbj36hxnutGSd+?=
 =?iso-8859-1?Q?Jq3hGgb/tMVHzMbhTjOVyvzmVfzjaxv3uSMmsPCFrWgwNy8qEEAaSunDSk?=
 =?iso-8859-1?Q?O1dga3KcKV1ORIiZXk47UfZa9ll6McvTxCWAIui52wCTuLJ/Co6ygrYDmZ?=
 =?iso-8859-1?Q?Dd5mEXSiAeSgtiIQaRZEkJVSD6slS7UTrvhttuMv1HkWtZKZ8hUg+yuGpm?=
 =?iso-8859-1?Q?D6oDzJnCxM6mVEqCJH4UwbRVQ5GgDHiXp+X5V7yM6qBeLh0/xBMjr6v8t9?=
 =?iso-8859-1?Q?esus7YdVlOqbBQYDMM5lcJ0+QtxzWQQxoyUasxibgJ0hOEC3GjoqAPJRDs?=
 =?iso-8859-1?Q?Hh5BLcbXD8XHknbDnwDzy/gKep20J9LfikfYS9fBLcEv+pmFXX4fnhhkVp?=
 =?iso-8859-1?Q?jTSQPLAXGi8pMLFcuEbdc9+AUZdnZMrcRpQPK7Ts4T57UraR0Ksflsz2XS?=
 =?iso-8859-1?Q?vJWWcNA9zajUXvv+UCSZ0iiT/56gu6kFZeKTCqK/cwyvM9aMl9C7jaul94?=
 =?iso-8859-1?Q?E9VPE/I3Iphjd5gI12OIFbQYD+BYN4Xu2fBNYau6LYU3WQPSv1lZNylVl0?=
 =?iso-8859-1?Q?FoorBuhfh4/8aZ5K/wj5bsRlWB57s8kaOGF+k/T6PCZtuO+6NKltRZUKn6?=
 =?iso-8859-1?Q?eui7rtAV76RbY86vLQ1Lgfd1gRXr3xhMRMlVfcX3K7J7XH8+fa558h4pOS?=
 =?iso-8859-1?Q?m1y8+r7kTJthUCWaMbqyw50EfpMPMsyz96BolHuMEoDiM22WujVbasn2qj?=
 =?iso-8859-1?Q?UjALs+EH58qT3vJVftmAY+Z+I+ZRShUnZyuF+zniPqUVt78bLIP7MBAEoG?=
 =?iso-8859-1?Q?fRzcfgWfQqdfV8JHiviwT73Mmxde7H9FMU3c07CT+F471mD1/CwJfdQJ6f?=
 =?iso-8859-1?Q?SWTUeC8rcb5Ef6cP4TYgPlNYQVAYk4VlOb/QN2y0oRNdp4Ck5EcV3vxtMo?=
 =?iso-8859-1?Q?REyz689KfFPhudhDCEcGZ+cXwLqJzm8DbL4wjJAKl2ttrRrghR9fF3CjXB?=
 =?iso-8859-1?Q?uNwVz+gdTIi/Xr3ZWEfBkI2/m3vuuNjwvZq+DPCUfPfjNutDGv6wz3WljK?=
 =?iso-8859-1?Q?GaRrhqefy1CH451ogFMc5N8UW+ERIFsJmZyc7HH7W4SmW4OFPSfMSMSRpF?=
 =?iso-8859-1?Q?zmYdgdMMJVzB7uIu+LKUzyMBFEZzEomBk9z08N/uva+3Rtr7s6WjvliaiI?=
 =?iso-8859-1?Q?RmRX8HpD6spD461tKJScse16M+nNlVo42OpsDsMGyYdJu8Ck4mqLszU1WV?=
 =?iso-8859-1?Q?Ne7JpDDGDvTL+vateCJ6gYesIxFacK7KwkpY2jMz7pDiNVcmDs6+/6JFjG?=
 =?iso-8859-1?Q?Ds76DOfFYGMNRl+JDZxHloBuI3xqYV/OQckovP/cgAXyckMnakQ48HvWVn?=
 =?iso-8859-1?Q?JAl8uv77j4Vz/4kohwnHHwLwHs2FjdM3bFvJT/XIBhDg07J/SA2qoM59qb?=
 =?iso-8859-1?Q?QlU5buDezh8+We2fTTxee7fixBTfmCsB8kg+dcDY3jXw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?fRlIpoNV7jYmLxLAuVPS3H9yQU/oonA4a1xsc9E8Ne/k6ZBCHDr1VL5bjf?=
 =?iso-8859-1?Q?hx4jH8uNJrEK9WAWo4UNi5Y39cmkTunAIEUW0y23MgMjOCbHAMFOE23Rjt?=
 =?iso-8859-1?Q?B/WZsPrBav9a5duJ+hmrWNzXOTGDn/krsmVkkV+n738RjW6nNjDBf+Ir6B?=
 =?iso-8859-1?Q?yU2iX/T3NhEWgdqxStoK1g5DbiiLgKEVMnnhkZxaBgaG85lLhdhfabXm6r?=
 =?iso-8859-1?Q?KD3bLd3YyB8UTPn2lAEw90vh19jJ2VO6HXoQnzx9gYvRi1N1/ctW3fKjuc?=
 =?iso-8859-1?Q?VjJLlrFdoSS89v+4ijyFIuoFECdH0HaCeDqj+5sbzefoA5RYo7OPcxMrwV?=
 =?iso-8859-1?Q?UE9jbH6wSJX1OjnC5eryi3N44qtXpuckbMRRJFPoTfMcpKQur1tKc55eE1?=
 =?iso-8859-1?Q?ObA0rTpCAUPbTOg7J/Ecc7HyACcHvk3wvjLP0gkWWyvcmOHsql3dpwR4AO?=
 =?iso-8859-1?Q?XD1vxNqwgbbMLFlS0rVw5CwQyb7PAFBCLYJMRcb8LsPGFm7GqJu3gr8yI6?=
 =?iso-8859-1?Q?zDq/CGgtp2u/jte7QT0RtDVrNfmoQ5XENcajhyCrZLFQu9UC0Cy+pgZcXI?=
 =?iso-8859-1?Q?rFADFEMSOgtxFkwR72HdKL/SX6ctBSFaNoiG/Qm1ZFP9qlzbdL93b0gEux?=
 =?iso-8859-1?Q?Rkk1rjjj/uk/HoR+1d+hpC+xanLO9DLg1P5qRcXJghq949nStya86q7Urq?=
 =?iso-8859-1?Q?jQp4zzxC72thZ8ub47gC50stkLvNlJsYv+sErkkPhx6ln8hw9eO3jjEMOx?=
 =?iso-8859-1?Q?Z8Qt9tUafBGdEXMR6l0/fnvfdptdHWTYVEdw+f20eKC1qOvB9PY3QS1022?=
 =?iso-8859-1?Q?HaKHTs9WV75Ux9BSzwC4aYHleEOoEsG+9uNQyxs/gr1RlTX6nXS1Jzusun?=
 =?iso-8859-1?Q?N3feOHyuxlUzV4ppEovOej7HpqdsldBk6fNTtAXwiqOI/bu7a8FRxlL4aC?=
 =?iso-8859-1?Q?3H6n+fg/MugU9h+soPiuTL/7z1hsd7mnhdvwaUuZIGxBcga1VJ+cayKAq7?=
 =?iso-8859-1?Q?nU+n4Y3tbXbiyjimaxTCmzrzjeNumpGV5WPjxYIylfX4pE6rKfAFsZYQgT?=
 =?iso-8859-1?Q?b7YtpvOIifTjRtKqdMmfw9lwYT2xwv9daRAlry4wwgGOjWtjW2toJceAFP?=
 =?iso-8859-1?Q?uimvbVX1pn6ul0qH5ay8LXDrWyB82q/MgRdjvWwkot7ujyxdbZxPpwXKmE?=
 =?iso-8859-1?Q?FGeviE5mt1d3FdldVA8rb2iVauHWUcOOMlW2UT3wvV19ERq74R9k+O13Bv?=
 =?iso-8859-1?Q?+Gf4cPV0cCfJDmRiHpKBCkGao22yvki8m7OduHfMtps6I3idRXM0beAjbP?=
 =?iso-8859-1?Q?MgdZ1XbDcsKMDAEH6JtwD0ynFFiRUAb8bRIEo25fM2Wc5hCOfTPesQwO2+?=
 =?iso-8859-1?Q?66nEZC1FMqVTcyDWqP6D9b0/R13Bf4Nc+wytNmRGz7AN0OBNcgLIvq5HCx?=
 =?iso-8859-1?Q?XcD0NDLYU05hRYnIJVsjJBLStFexuZwWAdEJjF9mkbgMwNAz9OviJ7oWlM?=
 =?iso-8859-1?Q?CyGwuexKHA154DsEAg/0MnISVLjRB3gyEoe50mBd2MHPlMIt6F3djhEDNZ?=
 =?iso-8859-1?Q?RqHSBVgpO+2ytwdWBSLXrPDretCd0aFCdeEyhbN3AC/ht5rOrVZM50wJC6?=
 =?iso-8859-1?Q?tE0qeCQI997VeXySwud35UM8k8jTUOdXYr8ezGkuCkpmC+ZpSirTe9oA?=
 =?iso-8859-1?Q?=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: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e660225e-bb95-4451-2ede-08dd8d4d19d8
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 09:53:59.5086
 (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: Q2HOYe3d3aylT+9UPv2kseogI44xiLxjbHG+jaH5mYVWK54KubggD1H+WupUVF/WvDWcqoFYKLNKAsBCinexa231hARm1UlJwHLa3qxdGOQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9758

Add new alpine-based build that enables LibAFL-based fuzzer.

Use this new build to run two fuzzing sessions: hypercall fuzzing and
gicv2 fuzzing. Currently, this is all the fuzzing modes supported by
xen fuzzer. Every fuzzing session will run approximately 10 minutes.

Fuzzing session will provide fuzzer log and any crash input data as
artifacts. This crash data can be used later to replay the input to
reproduce the crash.

Signed-off-by: Volodymyr Babchuk 

---

This patch is demonstration on how xen fuzzer can be integrated in
CI. With this setup, it can serve as smoke test, because 10 minute
fuzzing session is not enough. While there is no strict rule on now
long fuzzing session should run, most widely accepted time is 24
hours. This will require additional rules (weekly tests?) and separate
runners (probably).

Right now this patch uses docker container build by me that is hosted
on docker hub. Of course, in the final version, this container should
hosted together with other Xen CI containers.

Also, that container is built based on xen-fuzzer-rs project that is
also hosted on Xen-Troops GitHub repo, along with custom XTF
fork. These components also should be moved to gitlab/xen.
---
 automation/gitlab-ci/build.yaml | 11 +++++++++++
 automation/gitlab-ci/test.yaml  | 34 +++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.y=
aml
index ab5211f77e..6fc11fffe6 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -407,12 +407,23 @@ alpine-3.18-gcc-arm64:
     CONTAINER: alpine:3.18-arm64v8
=20
 alpine-3.18-gcc-debug-arm64:
+  extends: .gcc-arm64-build-debug
+  variables:
+    CONTAINER: alpine:3.18-arm64v8
+    EXTRA_XEN_CONFIG: |
+      CONFIG_UBSAN=3Dy
+      CONFIG_UBSAN_FATAL=3D
+
+alpine-3.18-gcc-fuzzing-arm64:
   extends: .gcc-arm64-build-debug
   variables:
     CONTAINER: alpine:3.18-arm64v8
     EXTRA_XEN_CONFIG: |
       CONFIG_UBSAN=3Dy
       CONFIG_UBSAN_FATAL=3Dy
+      CONFIG_FUZZING=3Dy
+      CONFIG_FUZZER_LIBAFL_QEMU=3Dy
+      CONFIG_FUZZER_PASS_BLOCKING=3Dy
=20
 alpine-3.18-gcc-arm64-randconfig:
   extends: .gcc-arm64-build
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yam=
l
index a603d4039a..bb8670026f 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -197,6 +197,30 @@
   tags:
     - qubes-hw11
=20
+.fuzzer-arm:
+  stage: test
+  image: xentroops/xen-fuzzer:v1
+  variables:
+    HARNESS: hypercall
+    FUZZING_TIME: 600
+  rules:
+  - if: $SELECTED_JOBS_ONLY && $CI_JOB_NAME =3D~ $SELECTED_JOBS_ONLY
+  - if: $SELECTED_JOBS_ONLY
+    when: never
+  - when: on_success
+  script:
+    - cd /root/
+    - ./xen_fuzzer -t ${FUZZING_TIME} run ${CI_PROJECT_DIR}/binaries/xen t=
est-mmu64le-arm-${HARNESS}-fuzzer 2>&1 | tee ${CI_PROJECT_DIR}/fuzzer-${HAR=
NESS}.log
+  after_script:
+    - cd ${CI_PROJECT_DIR}
+    - mv /root/crashes .
+  artifacts:
+    paths:
+      - fuzzer-${HARNESS}.log
+      - crashes/
+  needs:
+    - alpine-3.18-gcc-fuzzing-arm64
+
 # Test jobs
 build-each-commit-gcc:
   extends: .test-jobs-common
@@ -704,3 +728,13 @@ qemu-smoke-ppc64le-powernv9-gcc:
     - ./automation/scripts/qemu-smoke-ppc64le.sh powernv9 2>&1 | tee ${LOG=
FILE}
   needs:
     - debian-12-ppc64le-gcc-debug
+
+arm-hypercall-fuzzer:
+  extends: .fuzzer-arm
+  variables:
+    HARNESS: hypercall
+
+arm-vgic-fuzzer:
+  extends: .fuzzer-arm
+  variables:
+    HARNESS: vgic
--=20
2.48.1


From xen-devel-bounces@lists.xenproject.org Wed May 07 09:54:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 09:54:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978479.1365259 (Exim 4.92)
	(envelope-from )
	id 1uCbTd-0001pB-4a; Wed, 07 May 2025 09:54:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978479.1365259; Wed, 07 May 2025 09: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 1uCbTd-0001p4-1O; Wed, 07 May 2025 09:54:09 +0000
Received: by outflank-mailman (input) for mailman id 978479;
 Wed, 07 May 2025 09:54:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCbTb-0001ot-ON
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 09:54:07 +0000
Received: from PA4PR04CU001.outbound.protection.outlook.com
 (mail-francecentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c20a::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 36b692af-2b29-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 11:54:06 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DB9PR03MB9758.eurprd03.prod.outlook.com
 (2603:10a6:10:453::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Wed, 7 May
 2025 09:53:58 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%6]) with mapi id 15.20.8699.026; Wed, 7 May 2025
 09:53: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" 
X-Inumbo-ID: 36b692af-2b29-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LRZHv+kAANNHnWFXNPoDY6cS54+2/Kju7I+Oj8IxB13WC5sydsAdU1cpLv/r+YX+hztbZLHba0bEt9tNzvIIYDxczBGPf123zLVLyNU7K0+n1NPHSQMvnASavln490uX0jMb8YtdoiZIVboj7o4DN6Cpi2wkHHWFKApEyE5SKdLc1WsKT0Ss+0nBLk8l27jz9Q4r6nl/Ab540+G57L0Trmhv9T2ifUDmYJOqk1ulZGJvTomCCKydADQeeI9N2QT90KEWktSc174wpNfQfP0ZBIJ+/YTS7qzB0UUNdUB6WtigHJ3Ue3uAzEj4BoyZcOj1zgdMDRjyypDtwq5s7E5DpA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ImhYg9dkirrA85PgTSSSHIR76WDXQMdG46XAZVEQQSk=;
 b=RylLK4KaYfKTn0cN7mZ2quujjEeZpY1d/tBgfhAH5UcBLqJjrRoYAwi1pm7teIYyj+5gGs/N7B8sNFzd2jcioZkymphrr/OPizXsMWvTqx+WouusEk7j9tR5EJKNSdjB7WeMCjSrdnElyKWNGaDl2jPSXzYo/p/vgSDszhJZ7Shu7wOYKzTAZ95V+z9Vc3zYQnzJtbCtvHpQkQtRrk0YsVq0gC7wMPqIZ1w4dKeycuhO8quPzhHmNMmx8cEf7YPz8ENWYinLZEx+IvDoc1gRCxZpjXV5eUc5SRikHqVi+GBL8ffVZEN/S28OIqwoWSCLT2mrGNnUIiuIbsrvQHu78A==
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=ImhYg9dkirrA85PgTSSSHIR76WDXQMdG46XAZVEQQSk=;
 b=fDJCOTiEa8Q5g0Yk5z+34oiFKIr8TLR5xb8EtSLc45BnN+0M+CaO/s5fHpxDHWZITDJ906IwOPn+Z0T477ua9M617uS7r8QuaK979ZBM/3wAWvo1sBf/w+drgQePPz4/ZvsOByRrUIH0yivE1te1Lq7BJab/GR/G9sIugCWNqtvjUVBRmljy2PV9SoRFJ3Twr5WXXxZw+SJygGfVfzJjvJSWKMMFSO1J6e28cecH9GvYEMbP/YmdlCMERytd26zSN043TAsj91Z9lx0gFdfi7+bEH8TVxDgsX4aa7qzRkt86T8q2Fn5+zBidX9FlDdnCor2NPM/6ZvGE49EmRpeN1w==
From: Volodymyr Babchuk 
To: "xen-devel@lists.xenproject.org" 
CC: Volodymyr Babchuk , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini , Bertrand
 Marquis , Volodymyr Babchuk
	, Dario Faggioli , Juergen
 Gross , George Dunlap , Doug Goldstein
	
Subject: [RFC PATCH v3 0/2] xen: add libalf fuzzing support
Thread-Topic: [RFC PATCH v3 0/2] xen: add libalf fuzzing support
Thread-Index: AQHbvzXz/i9afaO75kKXSCRcBU5Yag==
Date: Wed, 7 May 2025 09:53:58 +0000
Message-ID: <20250507095338.735228-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.48.1
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|DB9PR03MB9758:EE_
x-ms-office365-filtering-correlation-id: 5a926501-e77c-464a-007c-08dd8d4d1676
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?kfUEH+kVTuPM0e7sAZEQIorlJmGgwwJVOgZJQc+Td5LvXILbow6I9O+JFm?=
 =?iso-8859-1?Q?CyQmCvGZ69vESK1w71se7m0mwdPBhMZ6eRDL8nanX7sQHWn8oZGKmUbMid?=
 =?iso-8859-1?Q?NUmPdOjdTrtrYRDtoTWyMfMHMO2QV43nsSEHXge0FBAa5zUWCr2+1BIbgI?=
 =?iso-8859-1?Q?MGAJp5Yr0ozLFBuYd0Ii+ljamFVEpa5fkD85tVRRVwUvSNHGSVTNpXobI4?=
 =?iso-8859-1?Q?i7kYTQ6s14UoudKO61kzblCiiPCOMoSGdtyUWHLFWnuyQGtiBcmMWeXLzs?=
 =?iso-8859-1?Q?4ZoCRNC0wLLCxCuHkKclvfz97coZ7y/1R7zCT1XR3M+t6ujTT5YZfsd/6J?=
 =?iso-8859-1?Q?HsFEQMo8XXaxbngTTev8u1PqzAFCEIbkk/5EGbUi+pA1Cv5YLDQn+JZFWL?=
 =?iso-8859-1?Q?pgf+fH0Wuk8SQ9/x50zVeSkDOvZAgL7U9KrwGlifOTQmD4KCOEWhALLFEF?=
 =?iso-8859-1?Q?fBsxbXE+i58JIvL2JY6JmV/3fBXJV3JtQm1MEQ3ZdtUF6jyXU1Lz5iQazF?=
 =?iso-8859-1?Q?UQZN6AaTFPVMvMMPoOaWjP4P5ws8V2x9nUhgwRPud5y69jklWIKle0BiQE?=
 =?iso-8859-1?Q?IfcDf8GL/bRH3l1q3vQ9/6TVTf0mm7Mf66KGFeXrXgdR/vYFnGyntBd6AM?=
 =?iso-8859-1?Q?2HAb47HOUV1oXM9SuQthup1vk+rJar2Tmnnc7WDnNnvZqaKQinIhAvN2g/?=
 =?iso-8859-1?Q?XuJi3oKhF9yebiVFoTRjoIuP5d07cwPgGOIXhMdyUhXDkgCGCoVw3viwsg?=
 =?iso-8859-1?Q?ZCdsr2VjDn13vmIX+Dm/K5cWcRrhQ9BckfEhuzVrzfFu2PQjXll5+2tehY?=
 =?iso-8859-1?Q?0IFtrcUyaXSEDVo8wbzKFTV93XrWvbePMEdOX3i/XA0Xf3dj54cfAHmr7b?=
 =?iso-8859-1?Q?MW1nqhcEeLzTvi0rkLapumngRe2rx3MUtox3DxrCDghCYqnk4FcYS4aapo?=
 =?iso-8859-1?Q?X6LxhUNCfNwqmLfNhmyZ2Gy680WTta5tObk4MMibbkkEnLjjirdkKXnwHl?=
 =?iso-8859-1?Q?kdenqwP5eq/sydzfu55iCH62ma2XJYBjR4KigmsrfXNZ9ozqgWw/QdkTs+?=
 =?iso-8859-1?Q?gd7Ry1yPSMYgh3BODThHYrPK+1ueJfh/fe34NSOz03O/vRUg+U+Oo7KAYW?=
 =?iso-8859-1?Q?IbbkVrNvipKwF38LDdPffrewam7VprO2Cw+UMyK6zLL/aVU6c+VR3YzSqV?=
 =?iso-8859-1?Q?u4DbpDd90CMUZKXZvckIHkddTwEmUmoyCLnEAKqBqJ1kFMdMe571sY9NIa?=
 =?iso-8859-1?Q?aNhR3C7pnDCtCn8ezS7NTiDwE6o+cuo38sNalqmh+qq41WuaCthzzOc3cq?=
 =?iso-8859-1?Q?BZAP5BdhYagOQj5irQYDdZlIdJe/q4a0pJ5aZw2HN6wmvlUJCIzS78bjN/?=
 =?iso-8859-1?Q?9VHhQwY/4fnnsxmtiuFf7aHBvKv2q/svrWWFSnOaz9wIARn2NKWt16z9Wu?=
 =?iso-8859-1?Q?J/z/fbf4VS6+42r88F1ycjU43q5+ctlPQI9oF1T72R61kNrtYrYOprgtVC?=
 =?iso-8859-1?Q?vgPE+kbeB5Fm6Tv894JPFfLlPOPmHOJ0VcKHb9FAnXUfe0npnifm4jGEgy?=
 =?iso-8859-1?Q?c3Z2Gkw=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?OZaxUoT82NqASv/ZVHk9VrDo3a4ihDC7JD9FbSGDytIxQaKlzvvgLXGyUR?=
 =?iso-8859-1?Q?ufv021JlndbgxHS3fJM9f1BPl9EOSzuT9hMT9+ImIk0cjxRXtkPbG5OkNe?=
 =?iso-8859-1?Q?dsKfcX6bs+ywaTznjlJAKKTmQgV3JuNp3nFq9xYfb+HSjZHWyGoG0esH11?=
 =?iso-8859-1?Q?3IgB4eAfmvQg9RWsW/sfHN8L4OUdSiloqFcH/lfeBReyPoAzr+sukBzKqn?=
 =?iso-8859-1?Q?jJQLgBleHSR5+ovkk/2JaMvSnchh7bkeQphE8D70XxTVdzfKjdCfIXc7n4?=
 =?iso-8859-1?Q?ZDR435wkq4H8GtCvYEU6hspuK86cpICZ5rO4KgEici8eQhn88f9wKo/KOS?=
 =?iso-8859-1?Q?WxbCHftFzT2DOleeBOOVXdGdHnOTqcobmqI3zItsnb0lo7wP1GbtUdoBkw?=
 =?iso-8859-1?Q?h6UKkYi48yUxiXp+ehYm03wasMV7/a2Femwl4XPrTtX4JzITeXQIucUhEv?=
 =?iso-8859-1?Q?8a0J58eEHMvmglAzK040oTPIQqBO5FbOP1oDFPZvinTruLk9fwKwZRSJdg?=
 =?iso-8859-1?Q?Fn/3h1OVirldPuxxpL5FNSb5qQYh+mKTVWuzrwiXD7IIQ6XDE7B5xxFNtd?=
 =?iso-8859-1?Q?sqmKmOI+Z4hHwPWAK4cR3HpnNmfvAawyQ5LnDTAKHk28hrH68QVn2QCw5e?=
 =?iso-8859-1?Q?pGxAKSnYEA6qa0kBz59OaDvxAAwDds7NrxT4LNBFLukxYsC6IHGhlN0wBd?=
 =?iso-8859-1?Q?vzYWfvnIxeK45sZlYnNlJiuk5brp80fJz3ij+HGVjy/iixIAec7wKUvF9Q?=
 =?iso-8859-1?Q?sozoOj8FPZ47FDiI8BSY+52iNhAJrT82U+hct26yiuykmSSvh15rM25xDQ?=
 =?iso-8859-1?Q?6J/PMWFpfzwlYs8fU9pYcioNUXUjGoRepthrl1bkLVg059dHCM/PTu4tTx?=
 =?iso-8859-1?Q?BNJ/IgGF4CAOhXz1LILhaV9YvKWFT18xtAOPCec9u+zRpU64tL9C6D45zo?=
 =?iso-8859-1?Q?h+XtRz7u/m33rJVfxIDcLkxZUYVVFl9LgN9l3BF4bho7gwB0GnZ1d3iJAO?=
 =?iso-8859-1?Q?XL0NzVuY5zYP/mGmPCx4FlS03XmtaWmA0mCMKm5fldifLBtJMKohwf0N3h?=
 =?iso-8859-1?Q?50D57yhUv0wBARJnZN9s+xa0hnaQVlynW59Pq2I90ctxrhKknd8bMqmGur?=
 =?iso-8859-1?Q?vC9ye8+b5uYcPpZLHkYowuPBjwGP+AMhQy9yFnOJ62ajy8LqUgTA9cSAE4?=
 =?iso-8859-1?Q?Crs9oiOIDbSn0QtXTXYkxYCi12D3CmHB8KBMMYWYk9TTqzpJyyqtqq3Z0d?=
 =?iso-8859-1?Q?O2SPyXC52/sAOMi30oJHnLR7rJHYgR7OAffQp9ymeTtIHkaRZWx7bt4V/0?=
 =?iso-8859-1?Q?61soDB6TTLL2mRlmsL2vkYnl/iimQuX4B2lHZTcTp6kddJhGMf8zyU/eJy?=
 =?iso-8859-1?Q?nj/whdX7DAPZajeZreSRgcHdJrvMkA6LOEa5Ip+ZmqAJ9Rc2ig88u+O8WZ?=
 =?iso-8859-1?Q?QTqIXIw7nRuQIucPYb6+aslKt/6jjXvtv7qxWdw9312IO1zZRlvQWLpXF4?=
 =?iso-8859-1?Q?vGr0CuQAortnxyU0INSNEnhU2ljeB3tGo3su9Nafjm4JljGUSeP5ITDiED?=
 =?iso-8859-1?Q?rkJTrFeqYyKzp1tIptZaNTzd/+tqoVRQIT+He89Vid8Csw7iOwHQ46+2LE?=
 =?iso-8859-1?Q?DkUWlyb1CkFwK/Yvm498IFKr717J2HvSdKG5UqlvEUY3Po8qOKPTu9Tw?=
 =?iso-8859-1?Q?=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: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a926501-e77c-464a-007c-08dd8d4d1676
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2025 09:53:58.4956
 (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: 3JZUIPhT7Nasm4//Ds8lAS8AuwbnUhnZ5XUwCcl8tEyg/zUCOpc/XEhFTJuIaK1BYy6x4KJPIW9DSGBS8w8IM+M4MG0Oy7MYkQ3O1btNgzc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9758

It is possible to use LibAFL with LibAFL-QEMU to fuzz different
baremetal programs, including Xen hypervisor. This small series
tries to add minimal (but extenable) support for fuzzing.

changes in v3:
 - Added patch with experimental CI integration
 - Severely reworked the main patch (see notes in the patch itself)

Volodymyr Babchuk (2):
  xen: add libafl-qemu fuzzer support
  ci: enable fuzzing for arm64

 automation/gitlab-ci/build.yaml        | 11 ++++
 automation/gitlab-ci/test.yaml         | 34 ++++++++++
 docs/hypervisor-guide/fuzzing.rst      | 91 ++++++++++++++++++++++++++
 xen/arch/arm/Kconfig.debug             | 37 +++++++++++
 xen/arch/arm/include/asm/libafl-qemu.h | 48 ++++++++++++++
 xen/arch/arm/psci.c                    |  5 ++
 xen/common/Makefile                    |  1 +
 xen/common/domain.c                    |  3 +
 xen/common/libafl-qemu.c               | 80 ++++++++++++++++++++++
 xen/common/sched/core.c                |  6 ++
 xen/common/shutdown.c                  |  3 +
 xen/drivers/char/console.c             |  3 +
 xen/include/xen/fuzzer.h               | 52 +++++++++++++++
 xen/include/xen/libafl-qemu.h          | 63 ++++++++++++++++++
 14 files changed, 437 insertions(+)
 create mode 100644 docs/hypervisor-guide/fuzzing.rst
 create mode 100644 xen/arch/arm/include/asm/libafl-qemu.h
 create mode 100644 xen/common/libafl-qemu.c
 create mode 100644 xen/include/xen/fuzzer.h
 create mode 100644 xen/include/xen/libafl-qemu.h

--=20
2.48.1


From xen-devel-bounces@lists.xenproject.org Wed May 07 12:39:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 12:39:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978526.1365289 (Exim 4.92)
	(envelope-from )
	id 1uCe3L-0007gd-QT; Wed, 07 May 2025 12:39:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978526.1365289; Wed, 07 May 2025 12:39: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 1uCe3L-0007gW-NV; Wed, 07 May 2025 12:39:11 +0000
Received: by outflank-mailman (input) for mailman id 978526;
 Wed, 07 May 2025 12:39:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCe3J-0007gQ-LV
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 12:39:09 +0000
Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com
 [2001:4860:4864:20::30])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 441bae4d-2b40-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 14:39:07 +0200 (CEST)
Received: by mail-oa1-x30.google.com with SMTP id
 586e51a60fabf-2db2149ffceso1334322fac.1
 for ; Wed, 07 May 2025 05:39: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" 
X-Inumbo-ID: 441bae4d-2b40-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746621546; x=1747226346; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KpjdhL78iSIW03cbbeqHZioOgFfIe9yl9I8S9n9w4NY=;
        b=LHQAz8hPGErC/i+CgDFiTPDcQtpJAjD3rPVegC6A6tfmp3WlHfkRCLMfNIcg9YG5o1
         eLrGOYOW/w+DK9VSROdPdtb3IJsswZn/BUL2IYvPlXK36BG7dYpshIf7qOM/qLU4qrZm
         cen7Qo0bgc0f6ICA5TXt4gOLxMIZX7VfDIv2E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746621546; x=1747226346;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=KpjdhL78iSIW03cbbeqHZioOgFfIe9yl9I8S9n9w4NY=;
        b=jcHOFNN3xBkKphQ5XHEuD9O6oftQKy5IAZpXShY5Vlv/R3ddLpa+/PYFAEONimDRj+
         9iO3nUjJSe4cMdL6lvVzCMDlsuiWNR1ym7vSEIpdnQBZJiQBiObahGzvxWOqF35M9Vtq
         GgaJET11UJEVWU44tH/utj9Fq5n0DSz1wGQsofzJPz9sCsBgXVRuTg3cvY7EeeV2BXhR
         1qxIZDiHNYLNPbtn+pJ575jjh/RAcyIJksIAvTWZzuH8IwI6tuxI8iiGw9VaayzC+AFZ
         url5k8L6nBK+WBN7gq++Ypn3W/EhQRlFdDQrFU0hKsszmgEzFfDcRzdpOxpjXRVEhxPF
         93RQ==
X-Forwarded-Encrypted: i=1; AJvYcCVNJPqA3OuYyNcWzFjURPj6eURUGCHeYA7vTDPmu1c7cXRAjwx0kzHj7cO8L4qs9x6pcgqzINw7ONw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwJVc8MBeies87ttckY4Y2uigO2ddpQxFNFHWhBKSRqu4+byuyo
	KyrN+zbFdgXg83F0mEzn0nziJDwfk9WJaSlu/kAO5otbk6IvZXmBnpzGYQRBveloDmqOXxU2g8k
	zcIDWM2MEIM7UMyNVLlqeM7qw5nwKEfkA0G9S
X-Gm-Gg: ASbGncvj/YlGnA2urWH3ViuhTuRf1ou/u1HQYImOZS5PN5L1eam04UAs3jcvUB1YqMm
	0qXHEM37dBHiTSwhxNkziiiWV8SSw3Iub4g1j9qwZnAUfNemcb2tNRF3JSkSOYCAoocv+RvAv5c
	4ilCZq34YFblH41ZGaWvGD
X-Google-Smtp-Source: AGHT+IFB5LHG8tUkt7iEcplPmRfD1V6EGYpymUFJzCNhAixnumTkdCfBK1YyPJNMoEO54jaSjemTO9Y+UzfDDJXnvNc=
X-Received: by 2002:a05:6871:7402:b0:2c2:b85b:71ff with SMTP id
 586e51a60fabf-2db5bda883amr1678847fac.8.1746621546212; Wed, 07 May 2025
 05:39:06 -0700 (PDT)
MIME-Version: 1.0
References: <20250506162449.1676405-1-kevin.lampis@cloud.com> 
In-Reply-To: 
From: Ross Lagerwall 
Date: Wed, 7 May 2025 13:38:55 +0100
X-Gm-Features: ATxdqUH0hnskP9ui_siHPSkzgKeBauyiP8BqZwcJhkVgHZU3MPbvUsoNylBM1Js
Message-ID: 
Subject: Re: [PATCH 2/4] efi: Add a function to check if Secure Boot mode is enabled
To: Andrew Cooper 
Cc: Kevin Lampis , xen-devel@lists.xenproject.org, 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Daniel Smith 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 6, 2025 at 5:56=E2=80=AFPM Andrew Cooper  wrote:
>
> CC'ing the EFI maintainers.
>
> On 06/05/2025 5:24 pm, Kevin Lampis wrote:
> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > index e39fbc3529..7c528cd5dd 100644
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -870,6 +870,27 @@ static void __init pre_parse(const struct file *fi=
le)
> >                     " last line will be ignored.\r\n");
> >  }
> >
> > +static void __init init_secure_boot_mode(void)
> > +{
> > +    EFI_STATUS status;
> > +    EFI_GUID gv_uuid =3D EFI_GLOBAL_VARIABLE;
> > +    uint8_t data =3D 0;
> > +    UINTN size =3D sizeof(data);
> > +    UINT32 attr =3D 0;
>
> Newline between variables and code please.
>
> > +    status =3D efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &gv_uuid, =
&attr,
> > +                                 &size, &data);
> > +
> > +    if ( status =3D=3D EFI_NOT_FOUND ||
> > +         (status =3D=3D EFI_SUCCESS &&
> > +          attr =3D=3D (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_=
RUNTIME_ACCESS) &&
> > +          size =3D=3D 1 && data =3D=3D 0) )
> > +        /* Platform does not support Secure Boot or it's disabled. */
> > +        efi_secure_boot =3D false;
> > +    else
> > +        /* Everything else play it safe and assume enabled. */
> > +        efi_secure_boot =3D true;
> > +}
>
> I'm not sure this logic does what you want when a weird answer comes
> back from GetVariable().

What specific case do you think is handled incorrectly here?

Ross


From xen-devel-bounces@lists.xenproject.org Wed May 07 12:58:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 12:58:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978539.1365304 (Exim 4.92)
	(envelope-from )
	id 1uCeMK-0002FO-D5; Wed, 07 May 2025 12:58:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978539.1365304; Wed, 07 May 2025 12: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 1uCeMK-0002FH-8p; Wed, 07 May 2025 12:58:48 +0000
Received: by outflank-mailman (input) for mailman id 978539;
 Wed, 07 May 2025 12:58:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uCeMJ-0002DK-8K
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 12:58:47 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 00bdff47-2b43-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 14:58:42 +0200 (CEST)
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 446441F449;
 Wed,  7 May 2025 12:58: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 1D45813882;
 Wed,  7 May 2025 12:58: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 rj0xBQFZG2hXOwAAD6G6ig
 (envelope-from ); Wed, 07 May 2025 12:58: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" 
X-Inumbo-ID: 00bdff47-2b43-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1746622721; 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=k5Uls9ZZa7Eov+ZryOPU8nHBjfUEKIAHW2KciQ26+UE=;
	b=jVtRNKrmJAvMoPd1CtiXRd8iozAREhf5WO08DMWkQvy8J4/RUT+7FSXCBfFISjiUuivFQl
	ojo8Rar4jzq8wD0qIjX/47GSRmun1A9Qx84g2R/5o/59FoJVtvU3AezL0AWsENRyysOLJx
	4v6Acat4o9d6W7CJfzfMNwxmnVfh1Fg=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1746622721; 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=k5Uls9ZZa7Eov+ZryOPU8nHBjfUEKIAHW2KciQ26+UE=;
	b=jVtRNKrmJAvMoPd1CtiXRd8iozAREhf5WO08DMWkQvy8J4/RUT+7FSXCBfFISjiUuivFQl
	ojo8Rar4jzq8wD0qIjX/47GSRmun1A9Qx84g2R/5o/59FoJVtvU3AezL0AWsENRyysOLJx
	4v6Acat4o9d6W7CJfzfMNwxmnVfh1Fg=
Message-ID: <25fce343-d18c-46b5-ac68-5ba4c1335df9@suse.com>
Date: Wed, 7 May 2025 14:58:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [MINI-OS PATCH 00/12] kexec: add kexec support to Mini-OS
To: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org
References: <20250321092451.17309-1-jgross@suse.com>
Content-Language: en-US
From: Juergen Gross 
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20250321092451.17309-1-jgross@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------9t1pxHRHl1XxBzO4BxzU8OQl"
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-4.20 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	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_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	HAS_ATTACHMENT(0.00)[]
X-Spam-Score: -4.20

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------9t1pxHRHl1XxBzO4BxzU8OQl
Content-Type: multipart/mixed; boundary="------------1nuSvqvc0jIZgwarDdAcook4";
 protected-headers="v1"
From: Juergen Gross 
To: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org
Message-ID: <25fce343-d18c-46b5-ac68-5ba4c1335df9@suse.com>
Subject: Re: [MINI-OS PATCH 00/12] kexec: add kexec support to Mini-OS
References: <20250321092451.17309-1-jgross@suse.com>
In-Reply-To: <20250321092451.17309-1-jgross@suse.com>

--------------1nuSvqvc0jIZgwarDdAcook4
Content-Type: multipart/mixed; boundary="------------CYFil5ptbogTSG3FLtieNw0r"

--------------CYFil5ptbogTSG3FLtieNw0r
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

UGluZz8NCg0KT24gMjEuMDMuMjUgMTA6MjQsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+IEFk
ZCBiYXNpYyBrZXhlYyBzdXBwb3J0IHRvIE1pbmktT1MgZm9yIHJ1bm5pbmcgaW4geDg2IFBW
SCBtb2RlLg0KPiANCj4gV2l0aCB0aGlzIHNlcmllcyBhcHBsaWVkIGl0IGlzIHBvc3NpYmxl
IHRvIGFjdGl2YXRlIGFub3RoZXIga2VybmVsDQo+IGZyb20gd2l0aGluIE1pbmktT1MuDQo+
IA0KPiBSaWdodCBub3cgbm8gWGVuIHJlbGF0ZWQgdGVhcmRvd24gaXMgZG9uZSAoc28gbm8g
cmVzZXQgb2YgZ3JhbnQgdGFibGUsDQo+IGV2ZW50IGNoYW5uZWxzLCBQViBkZXZpY2VzKS4g
VGhlc2Ugc2hvdWxkIGJlIGFkZGVkIHZpYSBrZXhlYyBjYWxsYmFja3MNCj4gd2hpY2ggYXJl
IGFkZGVkIGFzIGEgZnJhbWV3b3JrLg0KPiANCj4gVGhpcyBpcyBhIG1ham9yIGJ1aWxkaW5n
IGJsb2NrIGZvciBzdXBwb3J0IG9mIFhlbnN0b3JlLXN0dWJkb20gbGl2ZQ0KPiB1cGRhdGUg
KGluIGZhY3QgSSd2ZSB0ZXN0ZWQgdGhlIGtleGVjIHBhdGggdG8gd29yayB1c2luZyB0aGUg
UFZIDQo+IHZhcmlhbnQgb2YgWGVuc3RvcmUtc3R1YmRvbSkuDQo+IA0KPiBKdWVyZ2VuIEdy
b3NzICgxMik6DQo+ICAgIGFkZCBrZXhlYyBmcmFtZXdvcmsNCj4gICAgTWluaS1PUzogYWRk
IGZpbmFsIGtleGVjIHN0YWdlDQo+ICAgIG1pbmktb3M6IGFkZCBlbGYuaA0KPiAgICBtaW5p
LW9zOiBhbmFseXplIG5ldyBrZXJuZWwgZm9yIGtleGVjDQo+ICAgIG1pbmktb3M6IGtleGVj
OiBmaW5hbGl6ZSBwYXJhbWV0ZXIgbG9jYXRpb24gYW5kIHNpemUNCj4gICAgbWluaS1vczog
cmVzZXJ2ZSBtZW1vcnkgYmVsb3cgYm91bmRhcnkNCj4gICAgbWluaS1vczoga2V4ZWM6IGJ1
aWxkIHBhcmFtZXRlcnMgZm9yIG5ldyBrZXJuZWwNCj4gICAgbWluaS1vczoga2V4ZWM6IG1v
dmUgdXNlZCBwYWdlcyBhd2F5IGZvciBuZXcga2VybmVsDQo+ICAgIE1pbmktT1M6IG1tOiBj
aGFuZ2Ugc2V0X3JlYWRvbmx5KCkgdG8gY2hhbmdlX3JlYWRvbmx5KCkNCj4gICAgTWluaS1P
Uzoga2V4ZWM6IHN3aXRjaCByZWFkLW9ubHkgYXJlYSB0byBiZSB3cml0YWJsZSBhZ2Fpbg0K
PiAgICBtaW5pLW9zOiBrZXhlYzogYWRkIGtleGVjIGNhbGxiYWNrIGZ1bmN0aW9uYWxpdHkN
Cj4gICAgbWluaS1vczoga2V4ZWM6IGRvIHRoZSBmaW5hbCBrZXhlYyBzdGVwDQo+IA0KPiAg
IENvbmZpZy5tayAgICAgICAgICAgICAgICAgIHwgICAxICsNCj4gICBNYWtlZmlsZSAgICAg
ICAgICAgICAgICAgICB8ICAgMSArDQo+ICAgYXJjaC94ODYva2V4ZWMuYyAgICAgICAgICAg
fCAyNzMgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4gICBhcmNoL3g4Ni9taW5p
b3MteDg2Lmxkcy5TICB8ICAxNiArKw0KPiAgIGFyY2gveDg2L21tLmMgICAgICAgICAgICAg
IHwgMjM4ICsrKysrKysrKysrKysrKysrKysrLS0tLS0tDQo+ICAgYXJjaC94ODYvdGVzdGJ1
aWxkL2FsbC1ubyAgfCAgIDEgKw0KPiAgIGFyY2gveDg2L3Rlc3RidWlsZC9hbGwteWVzIHwg
ICAyICsNCj4gICBhcmNoL3g4Ni90ZXN0YnVpbGQva2V4ZWMgICB8ICAgNCArDQo+ICAgYXJj
aC94ODYveDg2X2h2bS5TICAgICAgICAgfCAgNDYgKysrKysNCj4gICBpbmNsdWRlL2VsZi5o
ICAgICAgICAgICAgICB8IDM0MCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrDQo+ICAgaW5jbHVkZS9rZXhlYy5oICAgICAgICAgICAgfCAgNjMgKysrKysrKw0KPiAg
IGluY2x1ZGUvbW0uaCAgICAgICAgICAgICAgIHwgICA4ICsNCj4gICBpbmNsdWRlL3g4Ni9v
cy5oICAgICAgICAgICB8ICAgNSArDQo+ICAga2V4ZWMuYyAgICAgICAgICAgICAgICAgICAg
fCAyNTMgKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+ICAgbW0uYyAgICAgICAgICAg
ICAgICAgICAgICAgfCAgODkgKysrKysrKysrLQ0KPiAgIDE1IGZpbGVzIGNoYW5nZWQsIDEy
ODkgaW5zZXJ0aW9ucygrKSwgNTEgZGVsZXRpb25zKC0pDQo+ICAgY3JlYXRlIG1vZGUgMTAw
NjQ0IGFyY2gveDg2L2tleGVjLmMNCj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgYXJjaC94ODYv
dGVzdGJ1aWxkL2tleGVjDQo+ICAgY3JlYXRlIG1vZGUgMTAwNjQ0IGluY2x1ZGUvZWxmLmgN
Cj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgaW5jbHVkZS9rZXhlYy5oDQo+ICAgY3JlYXRlIG1v
ZGUgMTAwNjQ0IGtleGVjLmMNCj4gDQoNCg==
--------------CYFil5ptbogTSG3FLtieNw0r
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-----

--------------CYFil5ptbogTSG3FLtieNw0r--

--------------1nuSvqvc0jIZgwarDdAcook4--

--------------9t1pxHRHl1XxBzO4BxzU8OQl
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/Ey8FAmgbWQAFAwAAAAAACgkQsN6d1ii/Ey9S
UQf9ESMFpK2vy7i6gIXSwBc6KQcqKgjuvyQUmLmSEM6yIsNrRlIuQjofjbpkDlCvTwViMtWRjMoi
SEA5PLU4NEBUMC6QRgS/Zz/Vigy0J3m4QYefoLAXu6FJaoKw1+w1MEf5wL6WRg+JcRDgwTkhdMz7
xAcaJEGeXBTw7u6Zbk38gT5kuzoubltCvmrv12Qgwb1QJoZYnXeMcrEny2pnIWkJ5kPGw8bVksfv
aTUCVUCE8AykpWRCEbNAXTRfcY6egoQms2T8Bcqo8fXWj410msS3mBFHZQLhNVv1ovKZceEUPEoN
xjPFVyYXD9SK80g/Y5L37mUVyY2MGKyFNSPWQ1L6Kg==
=H4l7
-----END PGP SIGNATURE-----

--------------9t1pxHRHl1XxBzO4BxzU8OQl--


From xen-devel-bounces@lists.xenproject.org Wed May 07 13:29:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 13:29:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978562.1365313 (Exim 4.92)
	(envelope-from )
	id 1uCepb-0006ao-HW; Wed, 07 May 2025 13:29:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978562.1365313; Wed, 07 May 2025 13: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 1uCepb-0006ah-DY; Wed, 07 May 2025 13:29:03 +0000
Received: by outflank-mailman (input) for mailman id 978562;
 Wed, 07 May 2025 13:29:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCepa-0006ab-Cv
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 13:29:02 +0000
Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com
 [2607:f8b0:4864:20::c2b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3c4cf5d0-2b47-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 15:29:01 +0200 (CEST)
Received: by mail-oo1-xc2b.google.com with SMTP id
 006d021491bc7-601a8b6c133so505815eaf.1
 for ; Wed, 07 May 2025 06:29: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" 
X-Inumbo-ID: 3c4cf5d0-2b47-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746624540; x=1747229340; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=07TUMPgaM14DSDMu/4lHBTiHAaMECtwkVV8+0qNHetE=;
        b=hknMqDDhGsOqjNbBc8c53Ya0bQceZGXs86eazGxQQoAronMg4wki9IKEjUOybxbqzz
         E5dJs4j36Wa9Jiuxbf0ACMNUy+1oYIEyUrneACGOmQ/BG1+yNOJkJzPXscERvNkyovxl
         //wo36h8+/vrbQ6dxqSx2ojDiDyskM8betu4c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746624540; x=1747229340;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=07TUMPgaM14DSDMu/4lHBTiHAaMECtwkVV8+0qNHetE=;
        b=Couac4u/8onwGlirYHkvctqJMuFvCoxX9Vjjncyf8qDvrH3TGFfSrMOYqyvlEJ871f
         wMbzqW8SuIvc8F02uUS2wgIWzpVm0xefr2B9koU8xx+DPBZHxBeoaX20w2neeIUH74D1
         4Hd7RdxmxYM4LxshVX6QPMCdwULwE/ZuXdYO4H/027Wvwfg3JAI23zpgnk/ltB9JEunQ
         jFFQMy/QN/Z89DDOK209aYSk2qH070rlbUVXedaN7Wqx+1/IT7kJRxdqBLWRLwZwLU9N
         HRJ3tRbvhFSBKoQ3+06FIB9ALEgMBB+XYTD0scCw8VWxytvn54ZN3zGsuIsws/73UkO7
         eSRQ==
X-Forwarded-Encrypted: i=1; AJvYcCWZKAU47oWUaxJzAfc7GK495O1CNAHT4OCZfipK60eXtSeEetfsKNEW3Brr/nIb7DMVxkMVRxVn+D4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxfiWw3aUtkQJT3XjOAOjHwbUGUHAmTMCKkSQDUD4mcr8QBtFXY
	PF62i/CjaYC6rY7BqL0qtubbiHV1Kv52ulrZB+TxBGw5uW2P+wXpak5Bdj5KnvLBkX33azBRt1D
	wS3HTubF+Gu1h9KePqPIkn3tV+K42yntdgNW9Pg==
X-Gm-Gg: ASbGncvpoYGuhnU79w/GtweXDsu/smcU3VA9+5qly1GcYL0NAz+n//uDCqLU9l1uTsr
	AVj1xChHVdapFTBVsTBSTCNOebpNsjtQ7NsgcA9o4tY/LiSWbQjBhrNtcCBbvvedTsvDzFKC96b
	eYnGmwr3hghKi9D2zRihXXtl9U0+1405IN
X-Google-Smtp-Source: AGHT+IHVyy07eeqOAOpvnaxG3XjvSYlxj6V9DZTvhA5SckZglosrdlC8RHS5CM6SrFGoEMk+A4rKb5rDXqGilT3vodM=
X-Received: by 2002:a4a:ca18:0:b0:607:de46:fa94 with SMTP id
 006d021491bc7-60828322836mr2397008eaf.4.1746624539704; Wed, 07 May 2025
 06:28:59 -0700 (PDT)
MIME-Version: 1.0
References: <20250506162449.1676405-1-kevin.lampis@cloud.com> 
In-Reply-To: 
From: Frediano Ziglio 
Date: Wed, 7 May 2025 14:28:48 +0100
X-Gm-Features: ATxdqUHseC44rgafBnlr6a_7ETNqkIKHRdbSIoVdG-gc2aoYeku4DtYcNIv0MhA
Message-ID: 
Subject: Re: [PATCH 2/4] efi: Add a function to check if Secure Boot mode is enabled
To: Andrew Cooper 
Cc: Kevin Lampis , xen-devel@lists.xenproject.org, 
	Ross Lagerwall , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Daniel Smith 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 6, 2025 at 5:56=E2=80=AFPM Andrew Cooper  wrote:
>
> CC'ing the EFI maintainers.
>
> On 06/05/2025 5:24 pm, Kevin Lampis wrote:
> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > index e39fbc3529..7c528cd5dd 100644
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -870,6 +870,27 @@ static void __init pre_parse(const struct file *fi=
le)
> >                     " last line will be ignored.\r\n");
> >  }
> >
> > +static void __init init_secure_boot_mode(void)
> > +{
> > +    EFI_STATUS status;
> > +    EFI_GUID gv_uuid =3D EFI_GLOBAL_VARIABLE;
> > +    uint8_t data =3D 0;
> > +    UINTN size =3D sizeof(data);
> > +    UINT32 attr =3D 0;
>
> Newline between variables and code please.
>
> > +    status =3D efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &gv_uuid, =
&attr,
> > +                                 &size, &data);
> > +
> > +    if ( status =3D=3D EFI_NOT_FOUND ||
> > +         (status =3D=3D EFI_SUCCESS &&
> > +          attr =3D=3D (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_=
RUNTIME_ACCESS) &&
> > +          size =3D=3D 1 && data =3D=3D 0) )
> > +        /* Platform does not support Secure Boot or it's disabled. */
> > +        efi_secure_boot =3D false;
> > +    else
> > +        /* Everything else play it safe and assume enabled. */
> > +        efi_secure_boot =3D true;
> > +}
>
> I'm not sure this logic does what you want when a weird answer comes
> back from GetVariable().
>
> Also, you can't have this be a common function, yet ...
>
> > diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
> > index 7e1fce291d..b63d21f16c 100644
> > --- a/xen/common/efi/runtime.c
> > +++ b/xen/common/efi/runtime.c
> > @@ -40,6 +40,9 @@ void efi_rs_leave(struct efi_rs_state *state);
> >  unsigned int __read_mostly efi_num_ct;
> >  const EFI_CONFIGURATION_TABLE *__read_mostly efi_ct;
> >
> > +#if defined(CONFIG_X86) && !defined(CONFIG_PV_SHIM)
> > +bool __ro_after_init efi_secure_boot;
> > +#endif
>
> ... this variable exist only on x86.
>

On a more high level. Is secure boot specific to x86? I think it's
generic so it should be compiled also for ARM or any EFI enabled
architectures.

> Also, why adjust it for PV shim?  None of this is even compiled for PV sh=
im.
>
> ~Andrew
>

Frediano


From xen-devel-bounces@lists.xenproject.org Wed May 07 13:39:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 13:39:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978573.1365323 (Exim 4.92)
	(envelope-from )
	id 1uCezN-0008Qd-Cm; Wed, 07 May 2025 13:39:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978573.1365323; Wed, 07 May 2025 13:39: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 1uCezN-0008QW-A0; Wed, 07 May 2025 13:39:09 +0000
Received: by outflank-mailman (input) for mailman id 978573;
 Wed, 07 May 2025 13:39:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCezM-0008QQ-DZ
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 13:39:08 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2409::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a201aa43-2b48-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 15:39:00 +0200 (CEST)
Received: from SJ0PR03CA0256.namprd03.prod.outlook.com (2603:10b6:a03:3a0::21)
 by CY5PR12MB6228.namprd12.prod.outlook.com (2603:10b6:930:20::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.20; Wed, 7 May
 2025 13:38:53 +0000
Received: from SJ5PEPF000001EF.namprd05.prod.outlook.com
 (2603:10b6:a03:3a0:cafe::36) by SJ0PR03CA0256.outlook.office365.com
 (2603:10b6:a03:3a0::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.30 via Frontend Transport; Wed,
 7 May 2025 13:38:53 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001EF.mail.protection.outlook.com (10.167.242.203) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Wed, 7 May 2025 13:38:53 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 7 May
 2025 08:38:52 -0500
Received: from [172.31.225.170] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 7 May 2025 08:38:51 -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" 
X-Inumbo-ID: a201aa43-2b48-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yyjDWiZH860BBiOmELfuX47Dtos3uKKODPEhs9HRRMfQGpEsGCxUqwPwheMnfMKlTR4PU+fRX+RLQtgeCtt8jN+ovz1KiEAsFsOGFrMKgJd20hsFxBeL+OcE1BltABKwmoXoBehG9O5YNAzOD2xL1idYTafgbQ7ZjOjzbVRAFwduNf8a5T+14CPAVnNk1TCZ2TC7HWOBFaFcaVka+307/c+y4fMKWt+QpyYAQiN1dEGix/9j/KAtnL43tkZ8vSnSvvAvar/d8qBeZcfN2Pj0OoOFaipkyRVmu0I/EjwhUy9VzS5oV9sYOtfE5Fkzsil3lVO/KDbk9lBOJOm/wQ+Ybg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Dv6AQ4QXC8dCddli8pQTVhC+lsx3Xe6H6OA6nUMfc/I=;
 b=pLNi/lv8dJvta5x3mkGUp/sXYhsTv4iFKMYR6W+dAkGZzrSEpHvzIVgRSsCHcmH1vDCvIkLjiqkScyN4LfWscVMNAaVoRAZGcA3o+yK+Y6IYt9lwMNKeScbiExs1KIEbSDCtsdJF329Ml5VU/ufPpyMwlvIv26i7NHZ/9Fj708KwSbCIYwfRN2gHPmKPFC5zg6qvTYRp3PmEW4dsfYsHqY/LcqL2JgDn849dmZEODOMQyZxH7Bk2VNipaCzl+xAre08zqnwXmI7GOnCCBKaVXQeZ9g96et19qwdQrrJJAiDi8cHy1v1at4VcBP6w85fgBUfsykV9mvfCQPbtpfl3jw==
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=Dv6AQ4QXC8dCddli8pQTVhC+lsx3Xe6H6OA6nUMfc/I=;
 b=FzdRiY6Tg7Wy1lrgdpEI2teSIanLym0QJFIsUW0u3ftkhfmZHg1gQAAo9xwDiyf7PbHmPaLn8clLUgzLtFSwWjUvjlxPMJ2jah/qLyvHsY2J71wAZLbgWVrgucqwyyFY6URicWpS5QXzlXwy41GAJAX8AnYmNnRUS5X306y2vaQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Wed, 7 May 2025 09:38:51 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v20 2/2] vpci: translate virtual PCI bus topology for
 guests
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall
	
CC: , Oleksandr Andrushchenko
	, Anthony PERARD
	, Stefano Stabellini ,
	Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	Jiqian Chen , Mykyta Poturai 
References: <20250418185840.335816-1-stewart.hildebrand@amd.com>
 <20250418185840.335816-3-stewart.hildebrand@amd.com>
  <3693f1ef-e305-4a6b-bb4e-3b842418387f@amd.com>
 
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001EF:EE_|CY5PR12MB6228:EE_
X-MS-Office365-Filtering-Correlation-Id: c6259779-2786-408c-fad5-08dd8d6c824e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|376014|1800799024|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?L2dtWStOeDVrT2hWRjNGT1c5R2dGSjJJWGVqc08wN0dFT0NwcTRKaTF0eHly?=
 =?utf-8?B?ZllRd0x0OGoyM3p1S08ranhsTzVZZ3dGWHovMlBxekhhUlU3K3RRNk5SWjVU?=
 =?utf-8?B?aGM2cmFVWVRmWW1aVEIrekpJdnF4clh0dXFxYWM2U1Roa1JJZklhb0cyeXMw?=
 =?utf-8?B?dlNVZFdBMURqQWp3QVBPSDJTTzFuMVRnMHo3ZndsZ2FwUFhEOG8rVDNpQ2Ew?=
 =?utf-8?B?MXZ0dzdwUVMydjU3SVoyU25BQktiYjBUejV3R2ZuWjVqUmhYcnpST1hqMVpK?=
 =?utf-8?B?S0xEU1VnSkZqR3RBTXBWQS90ZmJDR0xxckJQOUNsbHhkd3d1UzRBeGxVUDRN?=
 =?utf-8?B?Y3NxQlZuK0FIelFZTytkbG5GVWZ4UFVLaVFzbHVzc3V1bkdLNDQ5cGdxQitN?=
 =?utf-8?B?NjJwaGI0citRSGVqcUkwVE9RcXhzZ2tNUkFaclNrUVNrdzR4T0h6alRDVVVJ?=
 =?utf-8?B?NUVaeUZmK3pJa1ZRV1gxVzFvQysrbCtUNCswYm5SQXZlSS9yak9XTG41REs2?=
 =?utf-8?B?QWczUlJNWjdkUzNoYVM1bVcwT29WUzZ6UWgrejl3OERwZit5QUs4cWpBc01a?=
 =?utf-8?B?Y0R3ZzY5WGxCY05za3RWdUIzSnRSZ251SGpCSUpTRHRyZGRYUEcrOGlOT3hG?=
 =?utf-8?B?YXhJVXg5UStMdkZMdW5KMU83YUpqVUl3S3dYQm9pMzVMaEw3b0lXS0d2R014?=
 =?utf-8?B?U1krRldlOUxyOVozcDhNYVVldHFCYm9zRm1UZWEzOTRBVW1VUmY4eUNhM0Vo?=
 =?utf-8?B?TGF6bVRIaWRWWFBYdkI2ZGhnbXRzVGprako1UER3cmtRV2FVWXp4OGxBVXJs?=
 =?utf-8?B?QjVkaGxkUUwxajRNYTBhTXZIaCtLd0o3RXlZWjdhUmwwL1E0T2l1RDh4NHgr?=
 =?utf-8?B?Y1ltUWU3d1U2QndFMTBXRlJldy9DZlpLbUh0L1dOS0lsT1Bibng3STArMERN?=
 =?utf-8?B?OTRLdkI4ZFY0ZUdya0c0OFl6SFVhRUMwRXhhLzRhcGFwWFFlMWhSKzloNGZs?=
 =?utf-8?B?dmJMYWprS2h2S245OCs1RWdLK3RQWGR0U2JLVkdHWm5LU2xaYXMwdXRmSmhG?=
 =?utf-8?B?ZlRCNSt2cjNjSXQwMTl5ZkZLc1NydzVqOG0xdHJwc0JQWTZVa3hVZ2l6K3ov?=
 =?utf-8?B?c3NQL1liRjgwL1AyUTJVZGZUdm1BR3FEb1FSc09YbTNFL0swNDFva29yeW1z?=
 =?utf-8?B?VnBrQjZtZGM1eVZlaHVDTzN1Yi9laEVFa00wUXJqQmpudzVPV2xNQW5QZWtX?=
 =?utf-8?B?dVNJRzRvYmVtR3AwWSt4V01SUzFnK1NXMzlWS1ZDWmVyR1FtcVplMW9GYlhz?=
 =?utf-8?B?ZUsweFE4WDVoeTMxYk9OSmlRN0lOc0xKZldxZmFQUnZteVFZRC8vS1YvbW9R?=
 =?utf-8?B?aEpMMGJFU0x5djBnM0w1UTB0bHgySDdpaG9XM2xmckhaeGFvdERVbTY2T1Ni?=
 =?utf-8?B?dHhjekZKT25KVUtGUjJUMWNPdlBsNEZOQ1ZTQ1RMSklLKy8vMnZmM2t4aXRw?=
 =?utf-8?B?S1Aydm1EYnpMYjYzVWhZTFIvU1VYdXZrZXlRb1A2VkxoNlBKcDA1VlRxZkxP?=
 =?utf-8?B?L1FzU053QktYMWFsajFLZnNIa0hkQXdYQkNvWkdXN0VYYUJZNnhyVnltZnZY?=
 =?utf-8?B?TDZPU2Qrc3dpRVhSRUxpWkdnNHNUMGZobm41aUNuV1VKd2FNa1VUa2ZSejY2?=
 =?utf-8?B?Mit4cndKaGk4NXBEYW9SUks2UVpNQzJ4RUpmbWhSTEJUYTBaaXpKNlc0d1Rt?=
 =?utf-8?B?d29aQW0wTjdOQndXdHc0SE1ETUV1OGlIT05kQWdWb2pxR0oxN09FQnlpSG11?=
 =?utf-8?B?d3R1RGRrWDdVZTZxSkZ0d1ZTdit4ckJZMDBuNWl2YVo0SDlVZCtONXdqU3Rh?=
 =?utf-8?B?QlFoVk9CV2QrcWxkZ1JRS3NSWE5mNnMramNHbDVqTCtYd25FWGRWQzRxdDBr?=
 =?utf-8?B?azFBb0o3U2JsRFJNTGdBblpqUXlQczcvalFWV09FSG9uVDREM0RtUmlzOUd0?=
 =?utf-8?Q?Xs/WQiOi07zbrep1ImugdYxMZcvvXM=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(376014)(1800799024)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2025 13:38:53.7273
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c6259779-2786-408c-fad5-08dd8d6c824e
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001EF.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6228

On 5/7/25 03:44, Roger Pau Monné wrote:
> On Tue, May 06, 2025 at 11:05:13PM -0400, Stewart Hildebrand wrote:
>> On 5/6/25 07:16, Roger Pau Monné wrote:
>>> On Fri, Apr 18, 2025 at 02:58:37PM -0400, Stewart Hildebrand wrote:
>>>> From: Oleksandr Andrushchenko 
>>>>  static int vpci_register_cmp(const struct vpci_register *r1,
>>>>                               const struct vpci_register *r2)
>>>>  {
>>>> @@ -438,7 +473,7 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
>>>>      const struct pci_dev *pdev;
>>>>      const struct vpci_register *r;
>>>>      unsigned int data_offset = 0;
>>>> -    uint32_t data = ~(uint32_t)0;
>>>> +    uint32_t data = 0xffffffffU >> (32 - 8 * size);
>>>
>>> This seems kind of unrelated to the rest of the code in the patch,
>>> why is this needed?  Isn't it always fine to return all ones, and let
>>> the caller truncate to the required size?
>>>
>>> Otherwise the code in vpci_read_hw() also needs to be adjusted.
>>
>> On Arm, since 9a5e22b64266 ("xen/arm: check read handler behavior") we
>> assert that the read handlers don't set any bits above the access size.
> 
> I see.  That kind of diverges from x86 behavior, that AFAICT (see
> memcpy() at tail of hvmemul_do_io()) instead truncates the memcpy to
> the size of the access.
> 
> Maybe it would be better to instead of asserting just truncate the
> returned value to the given size, as that would allow to just return
> ~0 from handlers without having to care about the specific access
> size.

The impression I get from [0] is that that on Arm, there's no benefit to
performing truncation in xen/arch/arm/io.c. Doing so would needlessly
affect other Arm internal read handlers (e.g. vGIC). For vPCI
specifically, however, we could potentially perform truncation in
xen/arch/arm/vpci.c. So I guess it's a question of whether we want to
give special treatment to vPCI compared to all other read handlers on
Arm?

>> I had adjusted data here due to returning it directly from vpci_read()
>> in the current form of the patch. With your suggestion below we would
>> only need to adjust vpci_read_hw() (and then data here would not
>> strictly need adjusting).
> 
> Both returns would need adjusting IMO,

OK

> and it should have been part of
> 9a5e22b64266 I think, since that's the commit that introduced the
> checking.

If we proceed with adjusting vpci_read() and vpci_read_hw(): are you OK
with these adjustments included in this patch, or would you prefer them
being split into a pre-patch?

[0] https://lore.kernel.org/xen-devel/20240522225927.77398-1-stewart.hildebrand@amd.com/T/#t


From xen-devel-bounces@lists.xenproject.org Wed May 07 13:55:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 13:55:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978588.1365333 (Exim 4.92)
	(envelope-from )
	id 1uCfEi-0003UE-OY; Wed, 07 May 2025 13:55:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978588.1365333; Wed, 07 May 2025 13:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCfEi-0003U7-LW; Wed, 07 May 2025 13:55:00 +0000
Received: by outflank-mailman (input) for mailman id 978588;
 Wed, 07 May 2025 13:54:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCfEh-0003U1-4V
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 13:54:59 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dc8e9fe6-2b4a-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 15:54:57 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ac345bd8e13so1140700966b.0
 for ; Wed, 07 May 2025 06:54:57 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad18914736asm909458966b.7.2025.05.07.06.54.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 06:54:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dc8e9fe6-2b4a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746626097; x=1747230897; 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;
        bh=SwaPZyAnjoHYhBUmn95ZOFgAJvghEGtWVGqurf6VpnQ=;
        b=dGDZ+9/ibanT6I0GB1rWg0HGBe0tAJcYAbLLv6ZLGdCViesfY6SwAULcgPKIY0IhOG
         hxVauNSDRjUJTcs4fSTrMU61lyzmaG0dhoqgM1QC84QGNYvLTtMKUXRPy9bvEkHEXlas
         RYIrQV0vxOmhWPuPdeekQkIkTNNEUYJQmpl64=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746626097; x=1747230897;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=SwaPZyAnjoHYhBUmn95ZOFgAJvghEGtWVGqurf6VpnQ=;
        b=TXETJ9XyQbFicYArVms3xKlTFPE74zNmiqWzcD3rEWIqy8MGZWEMUj7w73x7FybdWC
         0CLUDgCM1JljLKAl2vC3jH7L2ma+7KuEGEMdx1MP7/rNmptTXETuFn6Lzd3bHfLiPUQO
         N7UZptU7TS4Ec3fOEvfVb42vJH0p20+lVc+wOS3bXzAWhA9ui1Ct2WGeCepl0FnQuAdP
         z5pV5EpGTLHru0iqya08dIbCtgcdPDjUEuHVQ6q4kg9Jvtv8FtqtWYvRuLeseu/IsEUz
         5aHqbCGfyp/+nybkBbGYA4S99TngtqokWr+tdGO4Lw8KbSjVkx7TjSRWdO7JSvUomslM
         Db+Q==
X-Gm-Message-State: AOJu0YzJcTaz9IkFn3tlEY/tZFqWwyg+8Pm6x/fNVMwUb8ie0d/50Xqq
	+eXY9b+Y7tKCXnw1wx/mNGcGCnrc/QNM+82wE/xg2bJy7RsmvPhL7P4p/8ZSPxPO7J9R37NLVYQ
	i3nA=
X-Gm-Gg: ASbGnctppx932rOCUNPRXaKbjCx/YKNRLA1g+JmHo+1mHHCXr/6EhmmPxTmPpTv7kLa
	YfyZtFrYNmeeJqsNOV5fSnYn9s7QJpcGsib0vX8VeGpDKgZmmahM2RZInFmfxoWQNOLE5MCXgde
	4AOKyYh91zG0PiSl/AMy1EDCo8+gM4wiLGQHhrXs1FOfBRGgyI07h6DKH/ybyaCZJ1LLkmv7O+N
	5gHtW6DjWXVdqJdsUVYyzq4aG9ndE44WQXMcLgh7fJ3Nc99IEn+Ef7PWeqTHFHZE3jfguEhFLwg
	ou6FRAvfI9L7Rs4Va4HkikNs5OCjIM3yhRP28KV+2V7Jx79y97L7deXFH3dWJYGC
X-Google-Smtp-Source: AGHT+IHDsgfC6imVRFvS4ReHyEKErElDxS8xVHXZ8ZsY1xjnidVV2nHOUSsZtm0lAKPiUg9gADDY7A==
X-Received: by 2002:a17:907:d507:b0:acb:39bb:f880 with SMTP id a640c23a62f3a-ad1e8d2c8cfmr379747666b.54.1746626097045;
        Wed, 07 May 2025 06:54:57 -0700 (PDT)
From: Gerald Elder-Vass 
To: xen-devel@lists.xenproject.org
Cc: dpsmith@apertussolutions.com,
	marmarek@invisiblethingslab.com,
	Gerald Elder-Vass ,
	Frediano Ziglio ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH v3] sbat: Add SBAT section to the Xen EFI binary
Date: Wed,  7 May 2025 13:54:42 +0000
Message-ID: <20250507135442.3439237-1-gerald.elder-vass@cloud.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

SBAT is a revocation scheme for UEFI SecureBoot, and is mandated by Microsoft
for signing.

The SBAT section provides a way for the binary to declare a generation
id for its upstream source and any vendor changes applied. A compatible
loader can then revoke vulnerable binaries by generation, using the
binary's declared generation id(s) to determine if it is safe to load.

More information about SBAT is available here:
https://github.com/rhboot/shim/blob/main/SBAT.md

Vendors should append a custom line onto sbat.csv(.in) with their vendor
specific sbat data.

Populate the SBAT section in the Xen binary by using the information
in xen/arch/xs86/efi/sbat.sbat

Signed-off-by: Gerald Elder-Vass 
Signed-off-by: Frediano Ziglio 
Tested-by: Gerald Elder-Vass 
---
Changed since v2:
 * Moved sbat files and rules to arch/x86/efi
 * Updated sbat rule to reuse existing objcopy command

Changed since v1:
 * Updated commit message to explain why SBAT is needed
 * Renamed sbat_data.o rule to sbat.o
 * Moved sbat.o rule into alphabetical order
 * Removed xen specific entry from sbat.csv (and rule for auto filling version)
   - The alternative of adding a "customise me" line would result in more
     overhead for anyone else building Xen, regardless of UEFI SecureBoot usage

diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 24dfecfad184..75aa35870a9a 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -6,11 +6,17 @@ cmd_objcopy_o_ihex = $(OBJCOPY) -I ihex -O binary $< $@
 $(obj)/%.o: $(src)/%.ihex FORCE
 	$(call if_changed,objcopy_o_ihex)
 
+$(obj)/sbat.o: OBJCOPYFLAGS := -I binary -O elf64-x86-64 --rename-section .data=.sbat,readonly,data,contents
+$(obj)/sbat.o: $(src)/sbat.sbat FORCE
+	$(call if_changed,objcopy)
+
 $(obj)/boot.init.o: $(obj)/buildid.o
 
 $(call cc-option-add,cflags-stack-boundary,CC,-mpreferred-stack-boundary=4)
 $(addprefix $(obj)/,$(EFIOBJ-y)): CFLAGS_stack_boundary := $(cflags-stack-boundary)
 
+EFIOBJ-y += sbat.o
+
 obj-y := common-stub.o stub.o
 obj-$(XEN_BUILD_EFI) := $(filter-out %.init.o,$(EFIOBJ-y))
 obj-bin-$(XEN_BUILD_EFI) := $(filter %.init.o,$(EFIOBJ-y))
diff --git a/xen/arch/x86/efi/sbat.sbat b/xen/arch/x86/efi/sbat.sbat
new file mode 100644
index 000000000000..1f262b5f038b
--- /dev/null
+++ b/xen/arch/x86/efi/sbat.sbat
@@ -0,0 +1 @@
+sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 9a1dfe1b340a..e6405941e1b7 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -343,6 +343,8 @@ SECTIONS
     *(.reloc)
     __base_relocs_end = .;
   }
+
+  .sbat (NOLOAD) : { *(.sbat) }
 #elif defined(XEN_BUILD_EFI)
   /*
    * Due to the way EFI support is currently implemented, these two symbols


From xen-devel-bounces@lists.xenproject.org Wed May 07 14:16:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 14:16:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978600.1365342 (Exim 4.92)
	(envelope-from )
	id 1uCfZN-0006am-D0; Wed, 07 May 2025 14:16:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978600.1365342; Wed, 07 May 2025 14:16: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 1uCfZN-0006af-A7; Wed, 07 May 2025 14:16:21 +0000
Received: by outflank-mailman (input) for mailman id 978600;
 Wed, 07 May 2025 14:16:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCfZL-0006aX-9B
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 14:16:19 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2408::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d61b14fe-2b4d-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 16:16:17 +0200 (CEST)
Received: from SJ0PR13CA0233.namprd13.prod.outlook.com (2603:10b6:a03:2c1::28)
 by CY8PR12MB8265.namprd12.prod.outlook.com (2603:10b6:930:72::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Wed, 7 May
 2025 14:16:05 +0000
Received: from SA2PEPF000015C6.namprd03.prod.outlook.com
 (2603:10b6:a03:2c1:cafe::ac) by SJ0PR13CA0233.outlook.office365.com
 (2603:10b6:a03:2c1::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.19 via Frontend Transport; Wed,
 7 May 2025 14:16:05 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SA2PEPF000015C6.mail.protection.outlook.com (10.167.241.196) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Wed, 7 May 2025 14:16:05 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 7 May
 2025 09:16:04 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 7 May
 2025 09:16:03 -0500
Received: from [172.18.31.235] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 7 May 2025 09:16: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" 
X-Inumbo-ID: d61b14fe-2b4d-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TyNUR+rcMnB+nOxbNkngNhvQcn1zTDbHg/VjNLdPzbarGylPj83x81hNgHajFj/qHeCyyEKUpm3e8NbPQFklrA0FwZU6qImnNk4kWwbS/eYVZ3eluofnKJYOPvrVuuXVHvsXZKTSiswdeN1fdEgVTZGvvVEwKEg/2eG0aqAaZA4vQc0U77QztUgMA8PD2p1jEKLi6/6FQkCeO/BkCrL2/ZpLau6g8to00hoUpo7flLIYXPC1XOGuCnfZksCeuxvnxAAgxN3m2IH2Amic3BUVGVKvxiX6Va8z9D+ztQ/aWir/CH/f97dy52p9n4a1omHPh3OCW80rrStLmyWkdEgOaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uXJ8CCsNS1QaMcsfn0m+y5P6NyFMLI02JABXfdkwrY0=;
 b=JhW+UrIwO1H2jKbXvGi0HjIbxPplNl4f1l++FACt8Lk8W/0huqkY5REk98ZtKdZ4BskdOp9t4mQ0/jjElrZfi7tZAojKZyzkDRWAtyXNJ9RIcy1KU9GQZZHD+oXwTdwCEK1TAwUw3wdjze4jjKIbN8JXm2/pWGngVA0fuQJRTrI8V4qcxMTrMEzc9uZWGDtaQyEJa/u5xdUsZDadQ2Vo0Yx8P15Q4fzA3pPjLx/OhzRjHGT4UTwYVFHolhPxdwC/Yb9Mhl69Dwusk29yix8j3CBeDr8reotrbSFvYp3kBzLO+V1dPj1AWc3MrIM89WAOihcQLmDCHLmw3fbdtkA2yg==
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=uXJ8CCsNS1QaMcsfn0m+y5P6NyFMLI02JABXfdkwrY0=;
 b=NLKDcr3KGA9jkafoNrvDy7iLmh9RE6JWfDqjw43hbUzIWxOoDG4ZyU+nnGqItQ4O1kPLt7ZcT2qf4VnFADIyPjwhsfQ38t2UJGjpKx5GK9ayL3pjEb35XBPw+eysvKMjA6/wZsDSi9o9yvDHDPZF3nACRYZVPw4WegOvkBhO6/c=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <6452909d-94f8-4df3-87fc-d8ee0bdba01a@amd.com>
Date: Wed, 7 May 2025 10:16:03 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xenbus: Use kref to track req lifetime
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Stefano Stabellini
	, Oleksandr Tyshchenko
	, Boris Ostrovsky 
CC: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
	, ,
	, 
References: <20250506210935.5607-1-jason.andryuk@amd.com>
 <6b17cb41-a4f1-4055-966a-54301493085c@suse.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <6b17cb41-a4f1-4055-966a-54301493085c@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF000015C6:EE_|CY8PR12MB8265:EE_
X-MS-Office365-Filtering-Correlation-Id: 782e647a-322d-42aa-67f2-08dd8d71b468
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026|13003099007|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cGJnMnZ5S1dOeS9tMkhrcTA0WVBVS2xReHV5SXNwcTJCYXNpcHlEZ0tpY0p3?=
 =?utf-8?B?ZkExMlhGeWJidlpOQS8rNmNsWjM3WUdaWitQVXpUUndQZG45MkdsVnd4Vlgw?=
 =?utf-8?B?TGt6NXhLMEJEQ3hwamFlc01Jd0dXTTJ5Um5LM2xxQkhuMFBiUGY1QXJyWnho?=
 =?utf-8?B?bXpqZnowaFUyUmtLUmlkY1lPREFHNnluM2lwZGRtQVd3NGFaZjYvRmM4Z1VY?=
 =?utf-8?B?bEk4RXU3bjBNU2dKOUlFYUV4SWdmOEE0TjR2RTF4YVNZT2ltNm5ITi9SODhi?=
 =?utf-8?B?N09lWGhIV0lpREVwRWY5NC92THNwMWtTUFoxMUtEQ25kenZ4dkJSM25MRFlC?=
 =?utf-8?B?QTVwTXBFNG5YRk9HSVFLditTRGhnL3p0NFZxQzJLRmFyT0Ixc0MzdHptSkxp?=
 =?utf-8?B?bTZnOUNHOWFEdEVVUjU1aDAvY2tqNDZKaTJUbHBMTXh5ZzhFNXJ1Ry9Odytr?=
 =?utf-8?B?R3p0TmpQeWpXdVlPckgzM1BMT3JMQTlIbGVMUVRjNXdaK3JPS09JdS9VQVlp?=
 =?utf-8?B?YmJoKzBiQ09pcGNlUzE0M2RaQkFRcy83ek1nbGNxbE5qRHZyMm90aXJJSEVK?=
 =?utf-8?B?ZjFvQ05RRktGRGhYK0N0MzdGVGNIV0VwRlQ1ZDdrT0NGQ3VIT2o5Wm8yQ0s4?=
 =?utf-8?B?L2M4OTJQZzQyRlJleUNlN2p2cjA5WGFJdnNjQ09FRTUxcDB4b05jSTdZZkNp?=
 =?utf-8?B?VXUrbmlaVm90YUxtZkxDN2psMUNNWFBBTnhRckwzbmxHRXVDV2ppWHpiZk1n?=
 =?utf-8?B?dm81a1hrdjljeVQvYzh6d2xNUnUzNmxhMEdxekwycDhjUEVmNStZTnJwa2tV?=
 =?utf-8?B?NWpRNlBnSk5TVUFVQis3MHZGR09tMnozWWdKNXJ6ZUMwTTdtMmhoRU1ya3NF?=
 =?utf-8?B?bHhkWGpPSENGaVdIYWV0QThrZmp3dFNhNG82alhmQTYrRDdQUC9VZm9OUlo1?=
 =?utf-8?B?V3dXd2svSGpvNjNmWERLNlBsMGxYWUdyQlpYZmNnamxRamxCeGsrQlZNNW5U?=
 =?utf-8?B?eXJHalNSVmtOWGQ5SnRDenBMRGlkaGdLTzh5THFPK0VCUmZFT21IZWJvQ3VB?=
 =?utf-8?B?T2lkdE5abzZ3Nm1ZcmN6ek8ycVFMTjEyMCtYUk5DS2tYY0xVU2lqbmFRYnlm?=
 =?utf-8?B?alRwckFhZ1hNWEZZQXNzM0szY2VQM01LN1NhVUtTbGdJcmgwN1ZZQ2RBMWZ2?=
 =?utf-8?B?V1pOaHN5b21kc2daejNVcHVkWTh2U3RTWmxHbVFSTlFscUEvT0RhSllqTk9K?=
 =?utf-8?B?LzNTZjVhY0cwTFJlNktvSVJMNmpzUnlJWk1DZ0ZxZzFSaTQ1bGFBRDgwYWh0?=
 =?utf-8?B?WHBISEhVVlhienk5Y1ZOU2hwTjV6dlA5aTZyTThYNzU5S1JiQTZCekIwWHVC?=
 =?utf-8?B?ZnNJZEpSRjIzYmhPTkJJNXdhVW83VVcrRnBCRFF1NTBOaWpBSEUrMUxtdEx5?=
 =?utf-8?B?Ukg4WUVVMUtidko5K3JyZXYxVHIrSkhBUjd6ZmJsR3FuMnlNNmFFUzN2VW96?=
 =?utf-8?B?MGJUcDhobjBhNW11ZTFraFNZdTBMSTlPRmh5Sm03L0c0T1NSQWhTZmluUVVW?=
 =?utf-8?B?TUJJVVNDcVJrcFFva0U5MWVNVEpjOTB5RjRLQmE0QytkY2M3QStFN1hRTkR5?=
 =?utf-8?B?L2NhNW9nKzNiU3dnbFRVRDdqRlNCelJkWDRDTkFWNWJSSUlKOFFuRUxyNVE5?=
 =?utf-8?B?NjVZcTczNjVWUUdKeVBVdkt1NFNSYWYrU2FEQXMzSnJHN2taL092bno3SnI0?=
 =?utf-8?B?YU1iaXg0UU42QVpJWUZ5T3hNbXJyRGZnWW1kOWZxVUlnUVZDYVFQVERmbEJL?=
 =?utf-8?B?U21jWVF2RXc3Y1ExcUluTXFjU3JZQm1VZUJsZHNScjdVZkl5UUowNjFGeisy?=
 =?utf-8?B?V21QZ2dBZUZ6T2Raa1czZTJNTnJRQklCbnRiZ1BKMDdHNEp1L2dYTWFHRmlM?=
 =?utf-8?B?aWhOZ2VqcTFkVEJTZEtIVE4waHJwVVhISnhjMENLZ3VSeTk3OUcwaHlCNnI4?=
 =?utf-8?B?bFJnWGUrYTVlaHR1QW4xdFpNaWtieUpzcEh0TTIrUGsrbEpqRStmemxDR1h3?=
 =?utf-8?B?OHVFbElzUC9UTkdTcWFvU3puM3lGeEFOVkRaQT09?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026)(13003099007)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2025 14:16:05.3321
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 782e647a-322d-42aa-67f2-08dd8d71b468
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF000015C6.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8265

On 2025-05-07 05:27, Jürgen Groß wrote:
> On 06.05.25 23:09, Jason Andryuk wrote:
>> Marek reported seeing a NULL pointer fault in the xenbus_thread
>> callstack:
>> BUG: kernel NULL pointer dereference, address: 0000000000000000
>> RIP: e030:__wake_up_common+0x4c/0x180
>> Call Trace:
>>   
>>   __wake_up_common_lock+0x82/0xd0
>>   process_msg+0x18e/0x2f0
>>   xenbus_thread+0x165/0x1c0
>>
>> process_msg+0x18e is req->cb(req).  req->cb is set to xs_wake_up(), a
>> thin wrapper around wake_up(), or xenbus_dev_queue_reply().  It seems
>> like it was xs_wake_up() in this case.
>>
>> It seems like req may have woken up the xs_wait_for_reply(), which
>> kfree()ed the req.  When xenbus_thread resumes, it faults on the zero-ed
>> data.
>>
>> Linux Device Drivers 2nd edition states:
>> "Normally, a wake_up call can cause an immediate reschedule to happen,
>> meaning that other processes might run before wake_up returns."
>> ... which would match the behaviour observed.
>>
>> Change to keeping two krefs on each request.  One for the caller, and
>> one for xenbus_thread.  Each will kref_put() when finished, and the last
>> will free it.
>>
>> This use of kref matches the description in
>> Documentation/core-api/kref.rst
>>
>> Link: https://lore.kernel.org/xen-devel/ZO0WrR5J0xuwDIxW@mail-itl/
>> Reported-by: "Marek Marczykowski-Górecki" 
>> 
>> Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple 
>> concurrent xenstore accesses")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Jason Andryuk 
> 
> Reviewed-by: Juergen Gross 

Thanks

>> ---
>> Kinda RFC-ish as I don't know if it fixes Marek's issue.  This does seem
>> like the correct approach if we are seeing req free()ed out from under
>> xenbus_thread.
> 
> I think your analysis is correct. When writing this code I didn't think
> of wake_up() needing to access req->wq _after_ having woken up the waiter.

Yes, this was tricky.

One other thing that makes me think this is correct.  If this is the 
same underlying issue: 
https://lore.kernel.org/xen-devel/Z_lJTyVipJJEpWg2@mail-itl/

The failure is in the unlock:

pvqspinlock: lock 0xffff8881029af110 has corrupted value 0x0!
WARNING: CPU: 1 PID: 118 at kernel/locking/qspinlock_paravirt.h:504 
__pv_queued_spin_unlock_slowpath+0xdc/0x120

Which makes me think the req was fine entering wake_up(), and it's only 
found to be corrupt on the way out.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Wed May 07 14:37:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 14:37:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978614.1365353 (Exim 4.92)
	(envelope-from )
	id 1uCfty-0001E8-0m; Wed, 07 May 2025 14:37:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978614.1365353; Wed, 07 May 2025 14:37:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCftx-0001E1-UK; Wed, 07 May 2025 14:37:37 +0000
Received: by outflank-mailman (input) for mailman id 978614;
 Wed, 07 May 2025 14:37:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCftx-0001Dv-9F
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 14:37:37 +0000
Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com
 [2001:4860:4864:20::2b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d12b3d3e-2b50-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 16:37:36 +0200 (CEST)
Received: by mail-oa1-x2b.google.com with SMTP id
 586e51a60fabf-2c76a1b574cso2241643fac.2
 for ; Wed, 07 May 2025 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" 
X-Inumbo-ID: d12b3d3e-2b50-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746628655; x=1747233455; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fgIQEVUnnc1TwalORp+iBCiiXf+u3UhcepqcCanzIH4=;
        b=fXxjqs+qpT1cyZHpyOx7J/LiwI+cEdtgpDKl3EBy6Xg5nZDYqedMPIrY3LXQO12ZWi
         oSc4Rv9w9z38dbuZ6ro3/Yzr0JwfMivX8bzNtBhdupCci44SGpip6oBkRQQB3Y2NPv1Z
         1SIZttDsEIIuD9FYJGrvfWjbmG4w/c3PFDR0g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746628655; x=1747233455;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fgIQEVUnnc1TwalORp+iBCiiXf+u3UhcepqcCanzIH4=;
        b=EbMTsOnh6l7MMFguZSRGYdD5DeVRnr8GNbX9ihL5aP/oEDgWZ9Kesja//cEayA86/3
         +o8VIiPJv4oGtoXKWW4kFzXFMsll24PfII4S4gDXXNyEi7q5fF2O6oJYbqZqKLJSrULc
         9+3kFwQ5sup1l4a5rrXR4vW3u6fDJOnyWiU90rJOBEQ13ZwUj7h21RT8dAnukM4QKaoh
         GXNArUSu9Rg6aOI2+LQPwdOukKNXld/MwmH0QtWUkRzzmnqVOFCgSHJ7+J1+9zBp7CkY
         6pzGIFwVTFIPXJMtJPsua0iI14a8tqZ9TcCEdb6y3qhBiDrJ97Ocl8KmeN2JhrYVe0nH
         dUqA==
X-Gm-Message-State: AOJu0YymWvu9LxfFW+ktGdiqiXFhrON3irSeQJ2ptapka0nlxjxfGmf+
	4ABG/g8Xm75ia9HXSrNhpLq9KbaxkeGlvzWZP4HaVZjzmXVy7hxvaJYNDNnc0PeedwKz4D920So
	51q8wR0GVaBex655HCmSCuKCWvQ+6oPvVYILLv2GUN5ojbraGyg==
X-Gm-Gg: ASbGncuCyp0cPn+bAeLps0/Tzt9fQQYTQdH+deWFGZFOKeq+/svCG+YG3AxryroaWfx
	ti+p7leY0YKr1CbppLr+lnPc8v2P9X61uvmfqH6lM0NAw2B8Q0BW7s13kFRB+KhnQTMxl0bQsl6
	G7NJWnNjIFrz5NxW/NR6t7
X-Google-Smtp-Source: AGHT+IE2LkKNCLfc5wHykOxGIYIL07/uXriNcUawN/gFIvwQGQLDD0XZAqUM6q7o9aZvqNPAHREX10P6ue/QvB13zN0=
X-Received: by 2002:a05:6870:c69c:b0:2d6:2a40:fbe7 with SMTP id
 586e51a60fabf-2db5bd62c30mr2293275fac.6.1746628655211; Wed, 07 May 2025
 07:37:35 -0700 (PDT)
MIME-Version: 1.0
References: <20250417103000.827661-1-ross.lagerwall@citrix.com> <37065e8d-33c2-4e6e-8c2c-f4f8a9cd3ce1@suse.com>
In-Reply-To: <37065e8d-33c2-4e6e-8c2c-f4f8a9cd3ce1@suse.com>
From: Ross Lagerwall 
Date: Wed, 7 May 2025 15:37:24 +0100
X-Gm-Features: ATxdqUH0mS3Jl05RuCqCmpqiD5mxoGBwwQHMOmXZIjykU5qu2kQJ6cUhDwz7HkE
Message-ID: 
Subject: Re: [PATCH] x86/pmstat: Check size of PMSTAT_get_pxstat buffers
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 17, 2025 at 2:23=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 17.04.2025 12:30, Ross Lagerwall wrote:
> > --- a/xen/drivers/acpi/pmstat.c
> > +++ b/xen/drivers/acpi/pmstat.c
> > @@ -104,6 +104,14 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *o=
p)
> >          cpufreq_residency_update(op->cpuid, pxpt->u.cur);
> >
> >          ct =3D pmpt->perf.state_count;
> > +
> > +        if ( op->u.getpx.total < ct )
> > +        {
> > +            spin_unlock(cpufreq_statistic_lock);
> > +            ret =3D -ENOSPC;
> > +            break;
> > +        }
>
> Simply producing an error is not an option imo. See pmstat_get_cx_stat()'=
s
> behavior. Imo the calculation of ct wants to become
>
>         ct =3D min(pmpt->perf.state_count, op->u.getpx.total);
>
> yet then the copying of the 2-dim array of data becomes more complicated
> when ct < pmpt->perf.state_count. An option may be to document that this
> array is copied only when the buffer is large enough.

Another option would be for the caller to explicitly pass in both array siz=
es
and Xen can copy as much as fits since in either case there would need to b=
e a
way for Xen to return how much it has (separately) copied for both arrays. =
Does
that make sense?

>
> Furthermore I think it would be a good idea to also amend the public head=
er
> with IN/OUT annotations for the fields which are input and output (also f=
or
> the Cx part, ideally).

Sure.

>
> And then - doesn't xc_pm_get_pxstat() have a similar issue?
>

Indeed, I can send a patch for that.

Ross


From xen-devel-bounces@lists.xenproject.org Wed May 07 14:46:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 14:46:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978625.1365363 (Exim 4.92)
	(envelope-from )
	id 1uCg2B-0002zX-QF; Wed, 07 May 2025 14:46:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978625.1365363; Wed, 07 May 2025 14:46: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 1uCg2B-0002zQ-MU; Wed, 07 May 2025 14:46:07 +0000
Received: by outflank-mailman (input) for mailman id 978625;
 Wed, 07 May 2025 14:46:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCg2A-0002zK-7P
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 14:46:06 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ff096c73-2b51-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 16:46:02 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5f624291db6so10662241a12.3
 for ; Wed, 07 May 2025 07:46:02 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5fa777c8afbsm9946688a12.28.2025.05.07.07.46.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 07:46: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" 
X-Inumbo-ID: ff096c73-2b51-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746629161; x=1747233961; 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;
        bh=9fm8GvBKyefl643EIoUMiwdToE8v/dTaREVxXV3Hhr4=;
        b=guuYvli8JRYacTj0fqZkM2iUs2ID1a4MSdEDtoSUEDEmFr3Xkme0abmRUOdvdJVhJw
         pYh9vIDuLUvw1AchtazYc05DlzKQKsU/lMPcHkdJY+1fwvJDBRi50lprZi5I6ZsfnkEX
         ny2R4aU23y6OISCQaYeTWkaH3XL3fzCBlRR9k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746629161; x=1747233961;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=9fm8GvBKyefl643EIoUMiwdToE8v/dTaREVxXV3Hhr4=;
        b=nkIT1X6P6tZFHhnc3ZHzLRwG/aAWIBZnWpBotsQ3VW3h4XBjGE6A9vseABRmlq+rmt
         u9+Fi0OwbUW7F4Y9ObcQBTWdV+KF3D7oH30H8KQbq6qCEjgJgsef8PkwJvmJkMoBahwh
         cn0ii6FrIzVZGZ+deVtgUOP/O3SFMs3Gs6gMplf0/7oUtVof37ZoghVOVxZOGQCirW3l
         RmT86h+ICIIjZXj0Ge0rxJZTLBJc6XHyVONpIWbxYfVdpxy4PCmPEKFLb1tdd7FWSc/d
         ki90fTVG6PgZd6W0ItGl/lmWnKkhYztUUv+nP9XDvytjYugPIxobVWRetLjdQPDJklvv
         o+pQ==
X-Gm-Message-State: AOJu0YzVFX8NMa3QSWlWXn/BZrqiWODb5F6+E9wwHUc4zGFH8/6Vyads
	I7+5PWOWt7Iqp+NAfeZPI30pWPwTSLfBjQKaHgzKV2KxxG2Tq+rAjrZ6EmbQEueDd4x40lprkXs
	k
X-Gm-Gg: ASbGncuCJ7I2Dtwq98FLtLqsOuc7Ncny7xfuLmA6FauEYHtoI4REg1u2H9QPRmNFhPQ
	NrsOX8GjNtEcPB79LqzQUwDLbGUvBu7ffdtkKOp9fdyXzEfoI1GE2fYVzmt/aF93hiF2dtRey03
	IEumMzVEmlEr4KvjAzDa7mVyFa2GYm0pxMvN/gm0EmVz/6CdvmhF21gXdQ/sna1uZnBWCxy9rXr
	sDscqwom1ahGetv6HcqtPTl+DoqMcNI592pLZ3ztvTr4wrXIt/f4Lx52my9XyhHcyRPHe2DfMca
	X4JthnvVKsR1pSR/EkHqdshMSW6Bfse2vmWF5kvi0+9bJDJzmrXFavdogQ==
X-Google-Smtp-Source: AGHT+IFtbJluCTeQl0bQOCI1n1/entZBGGWQobFJkxMQHzTI03UxDUZQY1CRSYteVw0LBBeTM7SOow==
X-Received: by 2002:a05:6402:440b:b0:5fb:1fbd:e3ad with SMTP id 4fb4d7f45d1cf-5fbe9dfb8ddmr3446786a12.13.1746629161034;
        Wed, 07 May 2025 07:46:01 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	Ross Lagerwall ,
	Kevin Lampis 
Subject: [PATCH v2] lib: Add strcspn function
Date: Wed,  7 May 2025 15:45:00 +0100
Message-ID: <20250507144515.1704100-1-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
In-Reply-To: <50a2737a-611a-4d83-aee6-de23619b0b6b@citrix.com>
References: <50a2737a-611a-4d83-aee6-de23619b0b6b@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Ross Lagerwall 

This will be used by future patches.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Kevin Lampis 
---
Changes in v2:
- Add alias to __builtin_strcspn
---
 xen/include/xen/string.h |  5 +++++
 xen/lib/Makefile         |  1 +
 xen/lib/strcspn.c        | 22 ++++++++++++++++++++++
 3 files changed, 28 insertions(+)
 create mode 100644 xen/lib/strcspn.c

diff --git a/xen/include/xen/string.h b/xen/include/xen/string.h
index bd4a8f48e9..0ad65303da 100644
--- a/xen/include/xen/string.h
+++ b/xen/include/xen/string.h
@@ -26,6 +26,7 @@ size_t strnlen(const char *s, size_t count);
 char *strpbrk(const char *cs,const char *ct);
 char *strsep(char **s, const char *ct);
 size_t strspn(const char *s, const char *accept);
+size_t strcspn(const char *s, const char *reject);
 
 void *memset(void *s, int c, size_t n);
 void *memcpy(void *dest, const void *src, size_t n);
@@ -68,6 +69,10 @@ void *memchr_inv(const void *s, int c, size_t n);
 #define strlen(s1) __builtin_strlen(s1)
 #endif
 
+#ifndef __HAVE_ARCH_STRCSPN
+#define strcspn(s, r) __builtin_strcspn(s, r)
+#endif
+
 #ifndef __HAVE_ARCH_MEMSET
 #define memset(s, c, n) __builtin_memset(s, c, n)
 #endif
diff --git a/xen/lib/Makefile b/xen/lib/Makefile
index 76dc86fab0..5ccb1e5241 100644
--- a/xen/lib/Makefile
+++ b/xen/lib/Makefile
@@ -22,6 +22,7 @@ lib-y += sort.o
 lib-y += strcasecmp.o
 lib-y += strchr.o
 lib-y += strcmp.o
+lib-y += strcspn.o
 lib-y += strlcat.o
 lib-y += strlcpy.o
 lib-y += strlen.o
diff --git a/xen/lib/strcspn.c b/xen/lib/strcspn.c
new file mode 100644
index 0000000000..d572931f54
--- /dev/null
+++ b/xen/lib/strcspn.c
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ *  Copyright (C) 1991, 1992  Linus Torvalds
+ */
+
+#include 
+
+/**
+ * strcspn - Calculate the length of the initial substring of @s which does not contain letters in @reject
+ * @s: The string to be searched
+ * @reject: The string to avoid
+ */
+size_t (strcspn)(const char *s, const char *reject)
+{
+       const char *p;
+
+       for (p = s; *p != '\0'; ++p) {
+               if (strchr(reject, *p))
+                       break;
+       }
+       return p - s;
+}
-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Wed May 07 16:36:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 16:36:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978685.1365492 (Exim 4.92)
	(envelope-from )
	id 1uChl0-00023L-IF; Wed, 07 May 2025 16:36:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978685.1365492; Wed, 07 May 2025 16:36:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uChl0-00023C-Fl; Wed, 07 May 2025 16:36:30 +0000
Received: by outflank-mailman (input) for mailman id 978685;
 Wed, 07 May 2025 16:36:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uChkw-00022u-Gg
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 16:36:28 +0000
Received: from postout2.mail.lrz.de (postout2.mail.lrz.de
 [2001:4ca0:0:103::81bb:ff8a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 678b87d0-2b61-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 18:36:20 +0200 (CEST)
Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1])
 by postout2.mail.lrz.de (Postfix) with ESMTP id 4Zt19b4rqLzyVT;
 Wed,  7 May 2025 18:36:19 +0200 (CEST)
Received: from postout2.mail.lrz.de ([127.0.0.1])
 by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavis, port 20024)
 with LMTP id CZEc8HSAboKw; Wed,  7 May 2025 18:36:18 +0200 (CEST)
Received: from [IPV6:2a09:80c0:192:0:1a32:faf8:4a92:5176] (unknown
 [IPv6:2a09:80c0:192:0:1a32:faf8:4a92:5176])
 (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 postout2.mail.lrz.de (Postfix) with ESMTPSA id 4Zt19Z3R7RzyW6;
 Wed,  7 May 2025 18:36: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" 
X-Inumbo-ID: 678b87d0-2b61-11f0-9ffb-bf95429c2676
Authentication-Results: postout.lrz.de (amavis); dkim=pass (2048-bit key)
 reason="pass (just generated, assumed good)" header.d=tum.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tum.de; h=
	content-transfer-encoding:content-type:content-type:in-reply-to
	:from:from:content-language:references:subject:subject
	:user-agent:mime-version:date:date:message-id:received:received;
	 s=tu-postout21; t=1746635778; bh=rMTiElN/AF1fB/6uRBfuCtNtyx4lm1
	x0wHJXW+k9zL0=; b=lx2eFH5IfViNfFD8O9cb0DpoWID4hx2PEVqHQoqY5faNUN
	S2R81a90W78TyybFqdTn5W4e99zQx94jkEfbUmoZatArMBufiWUNNdma7cqQo5vb
	7k2ziPn08zrjB5B0qxNGo8jHNveiBzupiQ/+4e3gpULdtvM7+uK+oWnk9ZQgysNU
	Zx+X0qOnUCX2HGmT6ys8/w0c0YQLFwYumackprw4Xhd08fVb1i7EewhAlU7teA4i
	qlcJ2ZYQiDiYDLkgYm7+17AYtBKZaQaUY3z32eS2Il3hJUIRr0nMCX/0s4MN0797
	B3gGBnIiIluRTmADj3JzWzuE/IYAkWGzdpyvbBTA==
X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de
X-Spam-Flag: NO
X-Spam-Score: -2.871
X-Spam-Level:
X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5
 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DMARC_ADKIM_RELAXED=0.001,
 DMARC_ASPF_RELAXED=0.001, DMARC_POLICY_NONE=0.001, LRZ_DMARC_FAIL=0.001,
 LRZ_DMARC_FAIL_NONE=0.001, LRZ_DMARC_POLICY=0.001, LRZ_DMARC_TUM_FAIL=0.001,
 LRZ_DMARC_TUM_REJECT=3.5, LRZ_DMARC_TUM_REJECT_PO=-3.5,
 LRZ_ENVFROM_FROM_MATCH=0.001, LRZ_ENVFROM_TUM_S=0.001,
 LRZ_FROM_ENVFROM_ALIGNED_STRICT=0.001, LRZ_FROM_HAS_A=0.001,
 LRZ_FROM_HAS_AAAA=0.001, LRZ_FROM_HAS_MDOM=0.001, LRZ_FROM_HAS_MX=0.001,
 LRZ_FROM_HOSTED_DOMAIN=0.001, LRZ_FROM_NAME_IN_ADDR=0.001,
 LRZ_FROM_PHRASE=0.001, LRZ_FROM_PRE_SUR=0.001, LRZ_FROM_PRE_SUR_PHRASE=0.001,
 LRZ_FROM_TUM_S=0.001, LRZ_HAS_CLANG=0.001, LRZ_HAS_CT=0.001,
 LRZ_HAS_IN_REPLY_TO=0.001, LRZ_HAS_MIME_VERSION=0.001, LRZ_HAS_SPF=0.001,
 LRZ_MSGID_HL8_3HL4_HL12=0.001, LRZ_MSGID_MOZ=0.001, LRZ_SUBJ_FW_RE=0.001,
 LRZ_UA_MOZ=0.001] autolearn=no autolearn_force=no
Message-ID: 
Date: Wed, 7 May 2025 18:36:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Assert in x86_emulate_wrapper triggerable by HVM domain
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org
References: 
 <26f9b5dd-2201-4dd7-bf26-863a9b114b62@suse.com>
Content-Language: en-US
From: Manuel Andreas 
Autocrypt: addr=manuel.andreas@tum.de; keydata=
 xjMEY9Zx/RYJKwYBBAHaRw8BAQdALWzRzW9a74DX4l6i8VzXGvv72Vz0qfvj9s7bjBD905nN
 Jk1hbnVlbCBBbmRyZWFzIDxtYW51ZWwuYW5kcmVhc0B0dW0uZGU+wokEExYIADEWIQQuSfNX
 11QV6exAUmOqZGwY4LuingUCY9Zx/QIbAwQLCQgHBRUICQoLBRYCAwEAAAoJEKpkbBjgu6Ke
 McQBAPyP530S365I50I5rM2XjH5Hr9YcUQATD5dusZJMDgejAP9T/wUurwQSuRfm1rK8cNcf
 w4wP3+PLvL+J+kuVku93CM44BGPWcf0SCisGAQQBl1UBBQEBB0AmCAf31tLBD5tvtdZ0XX1B
 yGLUAxhgmFskGyPhY8wOKQMBCAfCeAQYFggAIBYhBC5J81fXVBXp7EBSY6pkbBjgu6KeBQJj
 1nH9AhsMAAoJEKpkbBjgu6Kej6YA/RvJdXMjsD5csifolLw53KX0/ElM22SvaGym1+KiiVND
 AQDy+y+bCXI+J713/AwLBsDxTEXmP7Cp49ZqbAu83NnpBQ==
In-Reply-To: <26f9b5dd-2201-4dd7-bf26-863a9b114b62@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 4/16/25 15:52, Jan Beulich wrote:

> On 15.04.2025 23:52, Manuel Andreas wrote:
>> my fuzzing infrastructure discovered that an assert in
>> x86_emulate_wrapper is able to be triggered by an HVM domain executing a
>> specially crafted repeating movs instruction.
>>
>> Specifically, if the emulation of the rep movs instruction triggers an
>> exception (e.g. by accessing invalid memory after some amount of
>> iterations), the emulation will be halted at that point.
>> However, the instruction manual requires that _some_ register state
>> (namely the updated value of rcx) shall be commited, whereas the
>> instruction pointer needs to be rolled back to point to the address of
>> the instruction itself. The assert checks for the latter. Problematic is
>> the fact that for these type of repeating instructions, Xen seems to
>> eventually just commit all register state when it encounters an exception:
> If my analysis is correct, none of this matters here; the core emulator
> is working correctly. Hence also why the in-tree fuzzer wouldn't have
> caught it. Would you please give the patch a try that I just sent, with
> Cc to you (sorry, the list archive didn't pick it up yet, hence no link)?
>
> Jan
Sorry about the late reply, just got around to applying your patch a few 
days ago.

I verified that the provided XTF test does not trigger the assert anymore.
Moreover, I fuzzed the patched version for a few days and the bug (or 
possibly newly introduced ones) did not pop up, so I believe the root 
cause was fixed correctly.

Best,
Manuel



From xen-devel-bounces@lists.xenproject.org Wed May 07 16:39:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 16:39:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978695.1365503 (Exim 4.92)
	(envelope-from )
	id 1uChnc-0002hX-Ud; Wed, 07 May 2025 16:39:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978695.1365503; Wed, 07 May 2025 16: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 1uChnc-0002hQ-Rm; Wed, 07 May 2025 16:39:12 +0000
Received: by outflank-mailman (input) for mailman id 978695;
 Wed, 07 May 2025 16:39:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uChnb-0002hK-IL
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 16:39:11 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ccb545b7-2b61-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 18:39:09 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ace98258d4dso323966b.2
 for ; Wed, 07 May 2025 09:39:09 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad189508af1sm941267566b.147.2025.05.07.09.39.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 09:39: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" 
X-Inumbo-ID: ccb545b7-2b61-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746635949; x=1747240749; 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;
        bh=pj3WIJKwSUiFTNa+6cJxVnMD8JH3cpCY8YhiAIwxJRo=;
        b=RStDcI2vWzrq8X8MYf9WPfrJOB7dOmVcx42Af/LHFaa17yCeQZuB5lb5PRHLHIbcb3
         bf1x5fucgKcjEVbLgdgXi74nV29Mi4iKNUHtQ96c9UgIqvMxT/yILOnMqLp/fIiTodzN
         ZW0pS7j8n+1XcvdIGwR04KWJoG+nKX1D6idDo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746635949; x=1747240749;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=pj3WIJKwSUiFTNa+6cJxVnMD8JH3cpCY8YhiAIwxJRo=;
        b=XRWoB3GLB8uI+MKn44hgeR4vgNjYJn71F3KfaFFnhbWF5YSvStHZRUpkRugTZ1j7gG
         m0xV69oeZM8g1sF1tbFpdyzNJHy//wNZM3eFDV+LAv+F+NhrEjBmqB4t6w6ZB5TpSvtp
         FlSxbC+a38qbB5rybCakYXioisOePaOi7cHYvEg0Xoajf9WNRu3PhKsmEQXof5d71HVJ
         ip/WeNtSqso1Bf5mj1xOEK00TKb4UFrWqffnCOjdPCBV0GoHsJNbXo5tLBQyOTIsCdt7
         8ReBTvGra4ew23pZFgqOKeZ5EkYD3GSg+km5sr9cSZ+v7S0+UbhfVvol6SUoAcvsrmHX
         BGEA==
X-Gm-Message-State: AOJu0YyqydVCRdM3HEKV98eOqlFNoKx5qsw+370GHX6IB5wXkO8C4HD5
	6yLuFFlGt02QL912czQnRY8xJbSxPto1ABYiMIh21jS1q+tNA7X97GcLoDvAB91hciAYnRwbm40
	=
X-Gm-Gg: ASbGncsQ9XS86EHIShtrAZSwHoy3eVEmjpHeVxIFcsJSXvVMmS6M5UoLnZLeUmF0ubA
	UxpRsy13Ne74CTtQv/PqFsaGCSC86ephdowFPkz62o29KYwqjRhgiXuIxsDGv1Y+TQTCFaTGnNo
	Nw6LXOZuVhaE4bOLyNfWmZ3rRKGBpSqDZvzCVl6baufdLAfY3G2XhDvLNqoyQbgWEO9P33aeBzs
	Zzbp0qafSjoxgnUTBKa4P0bmGbYYQkonSOtPhXoIW2QImBYfRjnKnCrc56xq5qYKeIRJGpfpdIv
	HTtbNAppR3nABlu1BcEU59tfR6t7X2TBa5EuNMqnVIKcWhO7khG7n1snScbskWfw
X-Google-Smtp-Source: AGHT+IF8J0XdvD8QU/maG8TaKcsWM2RLbJDzLr6ZhL3MOc8ZzEtuAAg1uCd4pMl20/YIIskSNQh3pA==
X-Received: by 2002:a17:906:d54a:b0:ac7:3918:50f3 with SMTP id a640c23a62f3a-ad1e8d4098fmr389730866b.58.1746635948610;
        Wed, 07 May 2025 09:39:08 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Kevin Lampis ,
	Anthony PERARD ,
	Juergen Gross ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Ross Lagerwall 
Subject: [PATCH] livepatch: Pass buffer size to list sysctl
Date: Wed,  7 May 2025 17:38:59 +0100
Message-ID: <20250507163859.354711-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Kevin Lampis 

The livepatch list sysctl writes metadata into a buffer provided by the
caller. The caller is expected to allocate an appropriately sized buffer
but this is racy and may result in Xen writing beyond the end of the
buffer should the metadata size change.

The name buffer is expected to be an array of elements with size
XEN_LIVEPATCH_NAME_SIZE to avoid this kind of race but the xen-livepatch
tool allocates only as many bytes as needed, therefore encountering the
same potential race condition.

Fix both these issues by requiring the caller to pass in the size of the
name and metadata buffers and then not writing beyond the allocated
size.

The sysctl interface version is bumped due to the change in semantics of
the fields.

Signed-off-by: Kevin Lampis 
Signed-off-by: Ross Lagerwall 
---
 tools/libs/ctrl/xc_misc.c   |  3 +++
 xen/common/livepatch.c      | 22 +++++++++++++++++-----
 xen/include/public/sysctl.h | 12 ++++++++----
 3 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/tools/libs/ctrl/xc_misc.c b/tools/libs/ctrl/xc_misc.c
index 6a60216bda03..33e87bac2868 100644
--- a/tools/libs/ctrl/xc_misc.c
+++ b/tools/libs/ctrl/xc_misc.c
@@ -867,6 +867,9 @@ int xc_livepatch_list(xc_interface *xch, const unsigned int max,
         set_xen_guest_handle(sysctl.u.livepatch.u.list.metadata, metadata);
         set_xen_guest_handle(sysctl.u.livepatch.u.list.metadata_len, metadata_len);
 
+        sysctl.u.livepatch.u.list.name_total_size = name_sz;
+        sysctl.u.livepatch.u.list.metadata_total_size = metadata_sz;
+
         rc = do_sysctl(xch, &sysctl);
         /*
          * From here on we MUST call xc_hypercall_bounce. If rc < 0 we
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index be9b7e367553..72ef22bea5d2 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1311,11 +1311,10 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
         return -EINVAL;
     }
 
-    list->name_total_size = 0;
-    list->metadata_total_size = 0;
     if ( list->nr )
     {
         size_t name_offset = 0, metadata_offset = 0;
+        uint32_t name_total_copied = 0, metadata_total_copied = 0;
 
         list_for_each_entry( data, &payload_list, list )
         {
@@ -1328,10 +1327,14 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
             status.rc = data->rc;
 
             name_len = strlen(data->name) + 1;
-            list->name_total_size += name_len;
-
             metadata_len = data->metadata.len;
-            list->metadata_total_size += metadata_len;
+
+            if ( ((uint64_t)name_total_copied + name_len) > list->name_total_size ||
+                 ((uint64_t)metadata_total_copied + metadata_len) > list->metadata_total_size )
+            {
+                rc = -ENOMEM;
+                break;
+            }
 
             if ( !guest_handle_subrange_okay(list->name, name_offset,
                                              name_offset + name_len - 1) ||
@@ -1355,6 +1358,9 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
                 break;
             }
 
+            name_total_copied += name_len;
+            metadata_total_copied += metadata_len;
+
             idx++;
             name_offset += name_len;
             metadata_offset += metadata_len;
@@ -1362,9 +1368,15 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
             if ( (idx >= list->nr) || hypercall_preempt_check() )
                 break;
         }
+
+        list->name_total_size = name_total_copied;
+        list->metadata_total_size = metadata_total_copied;
     }
     else
     {
+        list->name_total_size = 0;
+        list->metadata_total_size = 0;
+
         list_for_each_entry( data, &payload_list, list )
         {
             list->name_total_size += strlen(data->name) + 1;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index b0fec271d36f..9eca72865b87 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -26,9 +26,9 @@
  * (e.g. adding semantics to 0-checked input fields or data to zeroed output
  * fields) don't require a change of the version.
  *
- * Last version bump: Xen 4.17
+ * Last version bump: Xen 4.21
  */
-#define XEN_SYSCTL_INTERFACE_VERSION 0x00000015
+#define XEN_SYSCTL_INTERFACE_VERSION 0x00000016
 
 /*
  * Read console content from Xen buffer ring.
@@ -1101,8 +1101,12 @@ struct xen_sysctl_livepatch_list {
                                                amount of payloads and version.
                                                OUT: How many payloads left. */
     uint32_t pad;                           /* IN: Must be zero. */
-    uint32_t name_total_size;               /* OUT: Total size of all transfer names */
-    uint32_t metadata_total_size;           /* OUT: Total size of all transfer metadata */
+    uint32_t name_total_size;               /* IN: Size of name buffer
+                                               OUT: Total size of transferred
+                                               names */
+    uint32_t metadata_total_size;           /* IN: Size of metadata buffer
+                                               OUT: Total size of transferred
+                                               metadata */
     XEN_GUEST_HANDLE_64(xen_livepatch_status_t) status;  /* OUT. Must have enough
                                                space allocate for nr of them. */
     XEN_GUEST_HANDLE_64(char) name;         /* OUT: Array of names. Each member
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 07 17:21:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 17:21:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978747.1365633 (Exim 4.92)
	(envelope-from )
	id 1uCiSJ-0002Je-4v; Wed, 07 May 2025 17:21:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978747.1365633; Wed, 07 May 2025 17:21: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 1uCiSJ-0002JX-2B; Wed, 07 May 2025 17:21:15 +0000
Received: by outflank-mailman (input) for mailman id 978747;
 Wed, 07 May 2025 17:21:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCiSG-0002JR-R4
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 17:21:13 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20626.outbound.protection.outlook.com
 [2a01:111:f403:2408::626])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a8ee2a66-2b67-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 19:21:07 +0200 (CEST)
Received: from MN2PR19CA0057.namprd19.prod.outlook.com (2603:10b6:208:19b::34)
 by SN7PR12MB6791.namprd12.prod.outlook.com (2603:10b6:806:268::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Wed, 7 May
 2025 17:20:57 +0000
Received: from BN2PEPF00004FC0.namprd04.prod.outlook.com
 (2603:10b6:208:19b:cafe::53) by MN2PR19CA0057.outlook.office365.com
 (2603:10b6:208:19b::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.24 via Frontend Transport; Wed,
 7 May 2025 17:20:57 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF00004FC0.mail.protection.outlook.com (10.167.243.186) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Wed, 7 May 2025 17:20:57 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 7 May
 2025 12:20:56 -0500
Received: from [172.31.225.170] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 7 May 2025 12:20: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" 
X-Inumbo-ID: a8ee2a66-2b67-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kGuF53uvTm4NRvdJ47Aw27N+L0eVsei9Pvkp7hYu699cFFR/X2di2JX7qS+5rfxuwEM8k9JGAkhTgqsfFwstqIu+om0AlV8inlOK3aN+4kdJPg3nwkvxFYVVmkvaFTTf85o3B3PmC6bmBphAiRQeJIN+yo+DGsQE8DVOg6btYur1ojzIdzbnocAqatqCNPvyoqO6OFX8oaJgIIw/Jjtw3ltJ7UyYzv3cZUROSRZ48G3++2miy9y9ywWT4dV4ShQk7zeEEOPqMmPy9PpFXzMHY8V3DcaVrR59T23szrlfg50iClUydXZ4dQrzQpBdLM+YyRNWsp9gcTEBwzF8L2/QEw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/7zwlzDxVFWMIVz5N7rfByd0iCOg+5LUZzc8IQnhdOE=;
 b=SjAN45j6i3Z4o5rvT6Ce8+9Sl0GSpOHmAZAFe9MZDM6aOGdjG51ti5i+sCJ8n+bBRyVmAMLkbwjqUEJ91V5o7tU8euGFnFd4rhvaLc2sgWltISXJgvW23sgmQnNABC2GnsDjaBToc02but/fFBIHoYtNSLLNkMSYx1vgA2OtgqTzRgkTB4jUHkSFXHRbgj1iM1DU7Tdv8CPwEw8rrZuFz52MtrGWmuQogiCrBDE+2+dOLSwUfI2uPNPuOxEgKnpip6TFHjTElyTlC1FrGJhK4k+mfZ5oDKWx+1mcDfeLlBd0NN9CMaH1CWQWx2merbQqthR0W6ZZ/pzrWlp2P72y5w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/7zwlzDxVFWMIVz5N7rfByd0iCOg+5LUZzc8IQnhdOE=;
 b=ZZlHcQ6gHp/n33JPDUi2sxPmbGr66VlbZxx0O/hCylY2HJAt5J1Bx+zd6OeBarnSuLZyJv0UDdZ+DNirxbocqkQ2j6YxhDehPXBRk1aMh9fmOnGzL5qZTJHHCyiGsnQFAdgQwnUJm8c7WXtxWNm2s4yX1WANwAOKhHf9ew9XalI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Wed, 7 May 2025 13:20:56 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] xen/arm: exclude xen,reg{-cacheable} from domU
 extended regions
To: Stefano Stabellini 
CC: , Julien Grall , "Bertrand
 Marquis" , Michal Orzel ,
	Volodymyr Babchuk 
References: <20250505025631.207529-1-stewart.hildebrand@amd.com>
 <20250505025631.207529-6-stewart.hildebrand@amd.com>
 
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF00004FC0:EE_|SN7PR12MB6791:EE_
X-MS-Office365-Filtering-Correlation-Id: d5b33acc-76ff-4f14-c0cd-08dd8d8b87b0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?M0FiQkMvcVp6ak8vRGFsMmVpazU4ZncwVlNEOUtSK00xVmYvdUtBbk1MU3dx?=
 =?utf-8?B?c0JvNlpBNVVpZXZNemk2MmZMUUFSOHpoVlFRV0pNdmtBL29NK1VZbTREeVpq?=
 =?utf-8?B?UVZUMGZjUnE5emQzRnFMUXJFUmFuVjJTWkI4Qm9CVXZxN2p5anpoZ3lPZnZ6?=
 =?utf-8?B?ZXlYTGw0bkIvSjB2NGEwVXZjcE55STVRa29UR3VqcCtTbmtGME5KRjlab1NR?=
 =?utf-8?B?eHViL00zTyt4QlZmdkptTVZTcHFlSnNubjRJQTEvM01JR2xpbUQ0YmtFYm9S?=
 =?utf-8?B?b1RYMXR1aTltdWdkTjZDWDZHRjhRMS9SbFZDZm1QNlROMk5MRHdKZ2VhNkxy?=
 =?utf-8?B?Q1EwZVRJbXlRVnRaSHJhaTNYbTMzYUNQNFBLUFhGdkJZZCswNkVEdE4zbmNC?=
 =?utf-8?B?cU1kZGQ5djVPQk9XUmdFcUhBdno3SnRpSDg5cC9nSVBURkxrSUxDb1gwSmJm?=
 =?utf-8?B?NU80ZUZvTjJ6Yk9mdE5vR2RKY09SNGxiS3gzeG5oZWdxbGZ4SjJQYk5vZDJM?=
 =?utf-8?B?VEV4Ym1iRXZxU0ZUd1pFODlPTHNDamhhRllsdGNWZEtDRi9obXB2bGMxMWZK?=
 =?utf-8?B?QmF4OTBxSkxtREhNNWJOcWE3cE1JcG9oNmJ4eE5DVUVSSUNtUlVSVWVWVms4?=
 =?utf-8?B?bG9NNkFlcWxoRGExSTNMWHV6cUZKZmZjeE0xdVFJZVR3QmNIcXpKVUJmZXYr?=
 =?utf-8?B?NEc3aVVFbEhYV0JyVERQMFJKQnd3Q2NYWlFleTcxTEZXSllpVmZJbUk1bGRS?=
 =?utf-8?B?NENrdm5PRlZFc1p2L0dUYWZFUkRYNnVrZC9UaS9MM0RKQ0RmUVhmQ0Z6cmpY?=
 =?utf-8?B?eFkvTXdzZSt4dTRKODJlKzVmTExqUWlOb2FNWDkvOGF1VGxuMXZDbnhZeTZq?=
 =?utf-8?B?UkNnZW02NHFJSFN6YTFnYjE2aU15eW85dG5YTEpPbkJYMkxyU1NHTFB2RzUw?=
 =?utf-8?B?bWNGTzcra3VRdGhBVzB3bDBlMW5SSyt5OG9PN0lrbllzeXpFbTNzaVlRYVk5?=
 =?utf-8?B?SkIyclRRNUFlR2FUOVlneEh1d1UyRkJmY3F2clQzV2xnaHgveW93Q1hZNU8y?=
 =?utf-8?B?RHVjd0FtWkZXSmlRSzJ0d2FJTW5KMklSOHdzanFZNDRub1FuRi9jalAxaXR1?=
 =?utf-8?B?cmFqb3NmNVJTOWdjbTJGc0xTRmN1NGxtRUFCL1BwVjlnMjlFUWxSQS9aQjBp?=
 =?utf-8?B?ajFESC9tM3FTb0pQNXZkK0J3UHRGRUYzVVRNb1o2VmovYmdMVXBtMFA4QWh6?=
 =?utf-8?B?QVNhUm9US3lZaEpnOHl6TkJwTnhjUVJJejMrNWlQbUdaZ2FJaG1yTzdjTVRU?=
 =?utf-8?B?OUtwamR0a1FQVUFyVndaS3pXVWFCbnhESDJZb3hWMFVrWUw0bkEvU0VWTHJp?=
 =?utf-8?B?dUhySmlML0hId3BJOVplQitXRnpDQm1Fa0Y2eXZ3WllyTnlRY3ZXTVd2WXNN?=
 =?utf-8?B?dzcwQUU5NVhDVjVVUkc5WkVMN0xLMEtLOThmTzBjZ1paZHQrNFdFQzBjZkU4?=
 =?utf-8?B?MTlnZklQTEpOYzlwNFNLVlhEanNiYkh6L0VMVExxNld5MGtTeEdUb0kyWWVj?=
 =?utf-8?B?Y01oU2RGZkNuRWZTRzdqUGZoMVNiNmMwbFJ1dml5eUg3a2tVcHdmL0E0WGV6?=
 =?utf-8?B?dUIrN2xuK2VRRjRCYnN6dkRKWE03SGEwcFR6SVNMSHgydmFZTDJmejh4aXda?=
 =?utf-8?B?aG1Jb2QyeUNrcW1KbHZtQ01sT0Z2RmpUSUZvZHVCWkZUMXBpWTV6eUozUGdq?=
 =?utf-8?B?NGdRd0RYZUNRbW9sYzQ5Q3RlQnliMXIyaWtmdW9SZWlJcGovR05JK0xYV3VG?=
 =?utf-8?B?aExneDhCWVJXbjMwNzlLaTVwWTNRS1cvL2d5U0psempHNzF4SmtiSGtKdmNk?=
 =?utf-8?B?R2N0RExQUVIzcWhuRG8ySEFhdEQ5YmdxZG5HelJ1SHJEd0swQWcxRVlQbkVH?=
 =?utf-8?B?Ri93enN3SjlZQ0pYYlRTK2NPbkYra0g0d1FQQmhQa0JMYVNLUkRzTXExeDlX?=
 =?utf-8?B?NmhQblp2Ulo0aXFUL0tGY2FVb1lwclV1L09ObjdqNkppbWMrcDllOWF5TWY5?=
 =?utf-8?Q?2Cx2RO?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2025 17:20:57.2521
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d5b33acc-76ff-4f14-c0cd-08dd8d8b87b0
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF00004FC0.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6791

On 5/5/25 19:31, Stefano Stabellini wrote:
> On Sun, 4 May 2025, Stewart Hildebrand wrote:
>> When a device is passed through to a dom0less domU, the
>> xen,reg{-cacheable} ranges may overlap with the extended regions. Remove
>> xen,reg{-cacheable} from extended regions.
> 
> There is no reg-cacheable upstream, the commit message should avoid
> mentioning it

I'll fix

>> Signed-off-by: Stewart Hildebrand 
>> ---
>> Not sure if we need a Fixes: tag, but if we do:
>> Fixes: 2a2447757b3c ("xen/arm: implement domU extended regions")
>>
>> I investigated an alternate approach of parsing the partial device tree
>> again to scan for xen,reg{-cacheable} properties, but it resulted in
>> quite a lot of code duplication. Adding a rangeset pointer to "struct
>> kernel_info" has a much smaller diffstat, and then we avoid the need to
>> parse the partial device tree a second time.
>>
>> I discovered this issue when booting a dom0less domU with a device
>> passed through. Partial device tree excerpt:
>>
>>     passthrough {
>>         ...  ...
>>
>>         axi_uart16550_0: serial@a0001000 {
>>             clocks = <&uart_fixed_clk>;
>>             compatible = "ns16550a";
>>             interrupt-parent = <&gic>;
>>             interrupts = <0 89 4>;
>>             reg = <0x0 0xa0001000 0x0 0x1000>;
>>             reg-shift = <2>;
>>
>>             xen,reg = <0x0 0xa0001000 0x00 0x1000 0x0 0xa0001000>;
>>             xen,path = "/amba_pl@0/serial@a0000000";
>>             xen,force-assign-without-iommu;
>>         };
>>     };
>>
>> The domU was assigned an extended region overlapping with MMIO of the
>> passed through device:
>>
>> (XEN) d1: extended region 0: 0xa0000000->0x100000000
>> (XEN) d1: extended region 1: 0x200000000->0xf000000000
>>
>> The domU panicked when attempting to initialize the device:
>>
>> [    3.490068] a0001000.serial: ttyS0 at MMIO 0xa0001000 (irq = 15, base_baud = 6249375) is a 16550A
>> [    3.498843] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
>> [    3.498853] Mem abort info:
>> [    3.498855]   ESR = 0x0000000096000044
>> [    3.498859]   EC = 0x25: DABT (current EL), IL = 32 bits
>> [    3.498864]   SET = 0, FnV = 0
>> [    3.498867]   EA = 0, S1PTW = 0
>> [    3.498870]   FSC = 0x04: level 0 translation fault
>> [    3.498874] Data abort info:
>> [    3.498876]   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
>> [    3.498879]   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
>> [    3.498884]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
>> [    3.498888] [0000000000000010] user address but active_mm is swapper
>> [    3.498894] Internal error: Oops: 0000000096000044 [#1] SMP
>> [    3.498899] Modules linked in:
>> [    3.498908] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.10-stew #1
>> [    3.498917] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> [    3.498924] pc : mem_serial_out+0x18/0x20
>> [    3.498936] lr : serial8250_do_set_mctrl+0x6c/0xc0
>> [    3.498943] sp : ffff800081bab6d0
>> [    3.498946] x29: ffff800081bab6d0 x28: ffff8000815e0dc8 x27: ffff000001c29c60
>> [    3.498957] x26: 0000000000000000 x25: ffff00000347b900 x24: ffff000005504c00
>> [    3.498968] x23: ffff00000347b800 x22: 0000000000000000 x21: ffff800081b69d78
>> [    3.498978] x20: ffff800081b69d78 x19: 0000000000000000 x18: ffffffffffffffff
>> [    3.498989] x17: 3d20647561625f65 x16: 736162202c353120 x15: 3d20717269282030
>> [    3.498999] x14: 3030313030306178 x13: ffff800081a21ff0 x12: 00000000000007fe
>> [    3.499010] x11: 00000000000002aa x10: ffff800081a4dff0 x9 : ffff800081a21ff0
>> [    3.499020] x8 : 00000000fffff7ff x7 : ffff800081a4dff0 x6 : 0000000000000008
>> [    3.499030] x5 : 0000000000000000 x4 : ffff800080797584 x3 : 0000000000000002
>> [    3.499040] x2 : 0000000000000000 x1 : 0000000000000010 x0 : 0000000000000000
>> [    3.499050] Call trace:
>> [    3.499053]  mem_serial_out+0x18/0x20
>> [    3.499059]  serial8250_set_mctrl+0x34/0x40
>> [    3.499065]  serial_core_register_port+0x534/0x7dc
>> [    3.499075]  serial_ctrl_register_port+0x10/0x1c
>> [    3.499084]  uart_add_one_port+0x10/0x1c
>> [    3.499092]  serial8250_register_8250_port+0x308/0x4c0
>> [    3.499102]  of_platform_serial_probe+0x2c4/0x48c
>> [    3.499110]  platform_probe+0x68/0xdc
>> [    3.499120]  really_probe+0xbc/0x298
>> [    3.499128]  __driver_probe_device+0x78/0x12c
>> [    3.499135]  driver_probe_device+0xdc/0x160
>> [    3.499142]  __driver_attach+0x94/0x19c
>> [    3.499149]  bus_for_each_dev+0x74/0xd0
>> [    3.499155]  driver_attach+0x24/0x30
>> [    3.499162]  bus_add_driver+0xe4/0x208
>> [    3.499168]  driver_register+0x60/0x128
>> [    3.499176]  __platform_driver_register+0x24/0x30
>> [    3.499184]  of_platform_serial_driver_init+0x1c/0x28
>> [    3.499192]  do_one_initcall+0x6c/0x1b0
>> [    3.499199]  kernel_init_freeable+0x178/0x258
>> [    3.499209]  kernel_init+0x20/0x1d0
>> [    3.499218]  ret_from_fork+0x10/0x20
>> [    3.499228] Code: f9400800 1ac32021 8b21c001 d50332bf (39000022)
>> [    3.499233] ---[ end trace 0000000000000000 ]---
>> [    3.499237] note: swapper/0[1] exited with irqs disabled
>> [    3.499247] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>> [    3.499251] SMP: stopping secondary CPUs
>> [    3.499284] Kernel Offset: disabled
>> [    3.499286] CPU features: 0x00,00000080,00200000,0200420b
>> [    3.499292] Memory Limit: none
>> [    3.792412] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>> ---
>>  xen/arch/arm/dom0less-build.c     | 19 ++++++++++++++++++-
>>  xen/arch/arm/domain_build.c       | 13 ++++++++++++-
>>  xen/arch/arm/include/asm/kernel.h |  1 +
>>  3 files changed, 31 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
>> index a356fc94fc4d..23178a801818 100644
>> --- a/xen/arch/arm/dom0less-build.c
>> +++ b/xen/arch/arm/dom0less-build.c
>> @@ -274,6 +274,14 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>>      int res;
>>      paddr_t mstart, size, gstart;
>>  
>> +    if ( !kinfo->xen_reg_assigned )
>> +    {
>> +        kinfo->xen_reg_assigned = rangeset_new(NULL, NULL, 0);
>> +
>> +        if ( !kinfo->xen_reg_assigned )
>> +            return -ENOMEM;
>> +    }
>> +
>>      /* xen,reg specifies where to map the MMIO region */
>>      cell = (const __be32 *)xen_reg->data;
>>      len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
>> @@ -315,6 +323,11 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>>                     mstart, gstart);
>>              return -EFAULT;
>>          }
>> +
>> +        res = rangeset_add_range(kinfo->xen_reg_assigned, PFN_DOWN(gstart),
>> +                                 PFN_DOWN(gstart + size - 1));
>> +        if ( res )
>> +            return res;
>>      }
>>  
>>      /*
>> @@ -1006,7 +1019,11 @@ static int __init construct_domU(struct domain *d,
>>  
>>      domain_vcpu_affinity(d, node);
>>  
>> -    return alloc_xenstore_params(&kinfo);
>> +    rc = alloc_xenstore_params(&kinfo);
>> +
>> +    rangeset_destroy(kinfo.xen_reg_assigned);
>> +
>> +    return rc;
>>  }
>>  
>>  void __init create_domUs(void)
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 3dcdd7a8c46f..da7c7c000f1f 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1296,6 +1296,13 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>>      if ( res )
>>          goto out;
>>  
>> +    if ( kinfo->xen_reg_assigned )
>> +    {
>> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
>> +        if ( res )
>> +            goto out;
>> +    }
>> +
>>      res = rangeset_report_ranges(mem_holes, 0,
>>                                   PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
>>                                   add_ext_regions, ext_regions);
>> @@ -2329,7 +2336,11 @@ static int __init construct_dom0(struct domain *d)
>>      if ( rc < 0 )
>>          return rc;
>>  
>> -    return construct_hwdom(&kinfo, NULL);
>> +    rc = construct_hwdom(&kinfo, NULL);
>> +
>> +    rangeset_destroy(kinfo.xen_reg_assigned);
> 
> handle_passthrough_prop is never called for the hardware domain

I'll drop this call to rangeset_destroy

>> +    return rc;
>>  }
>>  
>>  int __init construct_hwdom(struct kernel_info *kinfo,
>> diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
>> index bdc96f4c18eb..b3c2d50e1e3d 100644
>> --- a/xen/arch/arm/include/asm/kernel.h
>> +++ b/xen/arch/arm/include/asm/kernel.h
>> @@ -50,6 +50,7 @@ struct kernel_info {
>>  #ifdef CONFIG_STATIC_SHM
>>      struct shared_meminfo shm_mem;
>>  #endif
>> +    struct rangeset *xen_reg_assigned;
>>  
>>      /* kernel entry point */
>>      paddr_t entry;
>> -- 
>> 2.49.0
>>



From xen-devel-bounces@lists.xenproject.org Wed May 07 17:39:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 17:39:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978762.1365642 (Exim 4.92)
	(envelope-from )
	id 1uCijb-0004Fk-Mc; Wed, 07 May 2025 17:39:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978762.1365642; Wed, 07 May 2025 17:39: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 1uCijb-0004Fd-Jo; Wed, 07 May 2025 17:39:07 +0000
Received: by outflank-mailman (input) for mailman id 978762;
 Wed, 07 May 2025 17:39:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCija-0004FX-OW
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 17:39:06 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2b5e20e8-2b6a-11f0-9ffb-bf95429c2676;
 Wed, 07 May 2025 19:39:04 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43cfebc343dso900605e9.2
 for ; Wed, 07 May 2025 10:39:04 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442cd34bbf6sm8028495e9.17.2025.05.07.10.39.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 10:39:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2b5e20e8-2b6a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746639544; x=1747244344; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=l/tgRvNnN4dj5OAA3PiLmvZIo6ZwEQWR1JUck2gajrc=;
        b=UFj7TIrlkFRZJpSwFTwkV3tqTrG2MWWxgtAh2idkuYV4MGyqrjdnt2pUIQQpv+lfni
         r4CnD2hOAnkz434U/ffdEPP/Eb7Oiz08Bz1C69xiE1IQ4IEUVeUkn/3UBJ4Ff/cxH6A7
         qdg8CcPFghFYnCmmquqmyVSAkJZOAW1Celcsc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746639544; x=1747244344;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=l/tgRvNnN4dj5OAA3PiLmvZIo6ZwEQWR1JUck2gajrc=;
        b=o/zEYp5slchb/ZM/UqjMsxa59m2Xx6rFWyHYMo7ReENY84qhBInsqsFUCdiC7lHNmJ
         E2wjJ/YF/hsvId+dT7ztIkP+eHA9yAGve9o4a0CKb0/CajT0P4dmAfKVWnGexIHGWmvR
         59rxorgrVoCLHUJ3N8WCAUuVr9WcgRtiePbf0JFwLlfLz2BjMH56BZKUwnBr3c/Aec7f
         SSKyqRmYW/PQLFxHXuqVwBJl74Y4T5mAyL0J8ChyJuTfrBTy+MWi1kGvv1KIcJq9HDaf
         2G12TifeTxFSc6wq13JMEFT74TrP/UYasknFr+7oVtPZq+YrmYjJp+h1SKvsHijBQcbp
         IiKg==
X-Forwarded-Encrypted: i=1; AJvYcCWG4eROLRLt0qBVBNFwxUamzXY70k+/clrhFZCPMOVDCJ5v84J4XtPI0mkeATf/wvCAU9h4T5C2QoA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz3D+g2YkxO/ycI56TlFaKNTZ4/SrNAZ3JPayeBJp+SYgmhhf/b
	xcW328GC8vp8Bhgc2PNgGlIaYCzbvvC73CxD3NUTJq6DUv3meqQ0Uk4H6nCiZXE=
X-Gm-Gg: ASbGncufLppjNFMUFwoahRTW5u/aiBRoq5nV9DQdlNt4S1FiNPPFFAo1LT0KNrabtx+
	zx0sIVZ3+tji3pzB0RXqzaj44/PkxUAaaUTsw/5VFxk26p9fISlP+ryrVtbbIU+09rxzayxggUR
	G8jGfAGfazyxveGHhlMO7dg90AqJY/USLgslzNFxyg59PWzegjStx9JozZW3+V0dJ6S5e44olyd
	6t3+aifjTu/ZLFvr/2lJzH2K9gV7EStM0UCRP/yz0HgrdU6CwiNvYJ4aDO+HctGEoQK+8QFwrwK
	kJiwH5GxzBV36TeawbdhzGJ5YHbeyv4wHk+NwaUp4F08vQ==
X-Google-Smtp-Source: AGHT+IEgJDEOC/u6Db9S8vBGlIrtrweq2z3IngpE+bOG6o1P2S+EHdM9J3kXDIpjhVqdugpgYX213w==
X-Received: by 2002:a05:600c:8216:b0:441:d43d:4f68 with SMTP id 5b1f17b1804b1-441d44c8c30mr43306465e9.15.1746639543632;
        Wed, 07 May 2025 10:39:03 -0700 (PDT)
Date: Wed, 7 May 2025 19:39:02 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Demi Marie Obenour 
Cc: Alejandro Vallejo ,
	Xen developer discussion ,
	Andrew Cooper ,
	Juergen Gross ,
	Xen-devel 
Subject: Re: Mapping memory into a domain
Message-ID: 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, May 06, 2025 at 04:56:12PM -0400, Demi Marie Obenour wrote:
> On 5/6/25 9:06 AM, Alejandro Vallejo wrote:
> > On Tue May 6, 2025 at 3:02 AM CEST, Demi Marie Obenour wrote:
> >> On 5/5/25 7:32 AM, Alejandro Vallejo wrote:
> >>> I suppose this is still about multiplexing the GPU driver the way we
> >>> last discussed at Xen Summit?
> >>>
> >>> On Mon May 5, 2025 at 12:51 AM CEST, Demi Marie Obenour wrote:
> >>>> What are the appropriate Xen internal functions for:
> >>>>
> >>>> 1. Turning a PFN into an MFN?
> >>>> 2. Mapping an MFN into a guest?
> >>>> 3. Unmapping that MFN from a guest?
> >>>
> >>> The p2m is the single source of truth about such mappings.
> >>>
> >>> This is all racy business. You want to keep the p2m lock for the full
> >>> duration of whatever operation you wish do, or you risk another CPU
> >>> taking it and pulling the rug under your feet at the most inconvenient
> >>> time.
> >>>
> >>> In general all this faff is hidden under way too many layers beneath
> >>> copy_{to,from}_guest(). Other p2m manipulation high-level constructs
> >>> that might do interesting things worth looking at may be {map,unmap}_mmio_region()
> >>>
> >>> Note that not every pfn has an associated mfn. Not even every valid pfn
> >>> has necessarily an associated mfn (there's pod). And all of this is
> >>> volatile business in the presence of a baloon driver or vPCI placing
> >>> mmio windows over guest memory.
> >>
> >> Can I check that POD is not in use?  
> > 
> > Maybe, but now you're reaching exponential complexity considering each
> > individual knob of the p2m into account.
> > 
> >>
> >>> In general anything up this alley would need a cohesive pair for
> >>> map/unmap and a credible plan for concurrency and how it's all handled
> >>> in conjunction with other bits that touch the p2m.
> >>
> >> Is taking the p2m lock for the entire operation a reasonable approach
> >> for concurrency?  Will this cause too much lock contention?
> > 
> > Maybe. It'd be fine for a page. Likely not so for several GiB if they
> > aren't already superpages.
> > 
> >>
> >>>> The first patch I am going to send with this information is a documentation
> >>>> patch so that others do not need to figure this out for themselves.
> >>>> I remember being unsure even after looking through the source code, which
> >>>> is why I am asking here.
> >>>
> >>> That's not surprising. There's per-arch stuff, per-p2mtype stuff,
> >>> per-guesttype stuff. Plus madness like on-demand memory. It's no wonder
> >>> such helpers don't exist and the general manipulations are hard to
> >>> explain.
> >>
> >> Is this a task that is only suitable for someone who has several years
> >> experience working on Xen, or is it something that would make sense for
> >> someone who is less experienced?
> > 
> > The p2m is a very complex beast that integrates more features than I
> > care to count. It requires a lot of prior knowledge. Whoever does it
> > must know Xen fairly well in many configurations.
> > 
> > The real problem is finding the right primitives that do what you want
> > without overcomplicating everything else, preserving system security
> > invariants and have benign (and ideally clear) edge cases.
> > 
> > This was the last email you sent (I think?). Has any of the requirements
> > changed in any direction?
> > 
> >   https://lore.kernel.org/xen-devel/Z5794ysNE4KDkFuT@itl-email/
> 
> Map and Revoke are still needed, with the same requirements as described
> in this email.  Steal and Return were needed for GPU shared virtual memory,
> but it has been decided to not support this with virtio-GPU, so these
> primitives are no longer needed.
> 
> > Something I'm missing there is how everything works without Xen. That
> > might help (me, at least) guage what could prove enough to support the
> > usecase. Are there sequence diagrams anywhere about how this whole thing
> > works without Xen? I vaguely remember you showing something last year in
> > Xen Summit in the design session, but my memory isn't that good :)

Hello,

Sorry, possibly replying a bit out of context here.

Since I will mention this in several places: p2m is the second stage
page-tables used by Xen for PVH and HVM guests.  A p2m violation is
the equivalent of a page-fault for guest p2m accesses.

> A Linux driver that needs access to userspace memory
> pages can get it in two different ways:
> 
> 1. It can pin the pages using the pin_user_pages family of APIs.
>    If these functions succeed, the driver is guaranteed to be able
>    to access the pages until it unpins them.  However, this also
>    means that the pages cannot be paged out or migrated.  Furthermore,
>    file-backed pages cannot be safely pinned, and pinning GPU memory
>    isn’t supported.  (At a minimum, it would prevent the pages from
>    migrating from system RAM to VRAM, so all access by a dGPU would
>    cross the PCIe bus, which would be very slow.)

>From a Xen p2m this is all fine - Xen will never remove pages from the
p2m unless it's requested to.  So the pining, while needed on the Linux
side, doesn't need to be propagated to Xen I would think.

> 
> 2. It can grab the *current* location of the pages and register an
>    MMU notifier.  This works for GPU memory and file-backed memory.
>    However, when the invalidate_range function of this callback, the
>    driver *must* stop all further accesses to the pages.
> 
>    The invalidate_range callback is not allowed to block for a long
>    period of time.  My understanding is that things like dirty page
>    writeback are blocked while the callback is in progress.  My
>    understanding is also that the callback is not allowed to fail.
>    I believe it can return a retryable error but I don’t think that
>    it is allowed to keep failing forever.
> 
>    Linux’s grant table driver actually had a bug in this area, which
>    led to deadlocks.  I fixed that a while back.
> 
> KVM implements the second option: it maps pages into the stage-2
> page tables (or shadow page tables, if that is chosen) and unmaps
> them when the invalidate_range callback is called.

I assume this map and unmap is done by the host as a result of some
guest action?

> Furthermore,
> if a page fault happens while the page is unmapped, KVM will try
> to bring the pages back into memory so the guest can access it.

You could likely handle this in Xen in the following way:

 - A device model will get p2m violations forwarded, as it's the same
   model that's used to handle emulation of device MMIO.  You will
   need to register an ioreq server to request those faults to be
   forwarded, I think the hardware domain kernel will handle those?

 - Allow ioreqs to signal to Xen that a guest operation must be
   retried.  IOW: resume guest execution without advancing the IP.

I think this last bit is the one that will require changes to Xen, so
that you can add a type of ioreq reply that implies a retry from the
guest context.

> For GPU acceleration via virtio-GPU native contexts to work,
> the Xen interface driver needs to do the same thing with GPU
> buffers that KVM does: it needs to fault the pages into guest
> memory on-demand and revoke access to the pages when the host
> kernel demands them back.  There really is no alternative that
> I am aware of.  The need to handle guest page faults doesn’t
> come from the host kernel, but rather from guest userspace.

I'm a bit confused with this last sentence, the "page faults"
mentioned here are p2m violations I think?

Hope this makes some sense.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 07 17:44:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 17:44:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978774.1365652 (Exim 4.92)
	(envelope-from )
	id 1uCipA-0005zZ-8I; Wed, 07 May 2025 17:44:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978774.1365652; Wed, 07 May 2025 17:44: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 1uCipA-0005zS-5d; Wed, 07 May 2025 17:44:52 +0000
Received: by outflank-mailman (input) for mailman id 978774;
 Wed, 07 May 2025 17:44:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCip9-0005zM-Gm
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 17:44:51 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f9b4b960-2b6a-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 19:44:50 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43cfe574976so1051705e9.1
 for ; Wed, 07 May 2025 10:44:50 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442cd33331bsm8034595e9.14.2025.05.07.10.44.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 10:44: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" 
X-Inumbo-ID: f9b4b960-2b6a-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746639890; x=1747244690; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=yyiVLi+bqwfWp97V8f32HPvB5AMqHZCesJ+YUCWwvfc=;
        b=PdOyeksEonFp31wOek3QV/asu4ZZKrNdiZQYu++p9c//OqNkj/akrkblacWqKWcUw7
         FhQVPkZyJ/PCKcNKPSGpFEGywx9KpmVbSbzAbokNZCg1DDdsnw5TQlxgV6ADSPEfsS5q
         RAXhu00Vb9iBQuaTRrr8AKm1IE4OCw0qX+Gn0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746639890; x=1747244690;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=yyiVLi+bqwfWp97V8f32HPvB5AMqHZCesJ+YUCWwvfc=;
        b=NhFXM4LyN4tkq9Qas2AQ9l0RLIB8oDGoO0d6RS3DwyoMnJoeUYsRp6yvHIpsxEC8hn
         XRzGNmUeVb6iKsS2q4F2PVD7Asl/3uO0GIhEuTIsi+B6c2fDML8Hy8K7EIvGgbVye5fa
         yuvUTvnrSXK73tJZS5JumhpZLU5KcbuCuq7561TCsNEzdjZ/sAw+3nRng2M1cLeesYz7
         cPLiFXborZEaz8shNaJMmCv6ch9qGMUIQp+fzjlt7gp8ElsfI5v2zUtM6Aus25j78oLp
         zdTLMHVwHK2vBZqdnh/YgyFpVtUsGkf5oSaI0XgylD8M9d5uzcBSXQU4a1uhp7TF1Ymi
         FYIA==
X-Forwarded-Encrypted: i=1; AJvYcCVgBJey4mODsieoee6Fu8KWK30kXQ1wsFi78FCmxjvoOppM9RdHkLh2O/WvrEYiraBQdJ38xCxsiOw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwSv9VX5+br67vt3T/NrUHKFoIUFzJmOhxRd+Rq7M2lMJWW65+6
	jUD1vA0YPxFXNPRSJpuLrXBM9rQuEq/WKCXUgQ+SuCsdafj5GMXRoaD9KhjwNz8=
X-Gm-Gg: ASbGncvtY3anP50daFFVW6uPYh5bp1QyjPt1fn5igW/Z3R1RXYeuVWzvdyNBh7pUex0
	xMuG597cHPjxlVgt9e94oD5urm0r+4oMOOQuMrga2A4gd3YBra65fFa6YS39LhCk5KucqYDx6LQ
	LCJHXcbtcCnNahqRsQX2ejV4Yjga1i38fZRLoORsaQlqqdNCq17c/R9O3En2FVQbVIlGrf8KIYW
	aSghDF78HJYu3jFZufj0XDBH/6Q7SBoqSh00Z858n34nxgwrsjPhl6d97ohyVc951ZCayBbtDqv
	Py3XTCBZKbkECpr8KUmRdkjSEZo7lV5QYZstVDWfswcnIg==
X-Google-Smtp-Source: AGHT+IE0xGs1odZQxpMXLISUXQGestLALpbY4lcNnbePKKNXgeGP9EmSyMkoKANL9gpodt3g3PlgCg==
X-Received: by 2002:a05:600c:3ba1:b0:441:d446:b636 with SMTP id 5b1f17b1804b1-441d44e479dmr39431615e9.27.1746639889964;
        Wed, 07 May 2025 10:44:49 -0700 (PDT)
Date: Wed, 7 May 2025 19:44:48 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: Julien Grall , xen-devel@lists.xenproject.org,
	Oleksandr Andrushchenko ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Jiqian Chen ,
	Mykyta Poturai 
Subject: Re: [PATCH v20 2/2] vpci: translate virtual PCI bus topology for
 guests
Message-ID: 
References: <20250418185840.335816-1-stewart.hildebrand@amd.com>
 <20250418185840.335816-3-stewart.hildebrand@amd.com>
 
 <3693f1ef-e305-4a6b-bb4e-3b842418387f@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 07, 2025 at 09:38:51AM -0400, Stewart Hildebrand wrote:
> On 5/7/25 03:44, Roger Pau Monné wrote:
> > On Tue, May 06, 2025 at 11:05:13PM -0400, Stewart Hildebrand wrote:
> >> On 5/6/25 07:16, Roger Pau Monné wrote:
> >>> On Fri, Apr 18, 2025 at 02:58:37PM -0400, Stewart Hildebrand wrote:
> >>>> From: Oleksandr Andrushchenko 
> >>>>  static int vpci_register_cmp(const struct vpci_register *r1,
> >>>>                               const struct vpci_register *r2)
> >>>>  {
> >>>> @@ -438,7 +473,7 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
> >>>>      const struct pci_dev *pdev;
> >>>>      const struct vpci_register *r;
> >>>>      unsigned int data_offset = 0;
> >>>> -    uint32_t data = ~(uint32_t)0;
> >>>> +    uint32_t data = 0xffffffffU >> (32 - 8 * size);
> >>>
> >>> This seems kind of unrelated to the rest of the code in the patch,
> >>> why is this needed?  Isn't it always fine to return all ones, and let
> >>> the caller truncate to the required size?
> >>>
> >>> Otherwise the code in vpci_read_hw() also needs to be adjusted.
> >>
> >> On Arm, since 9a5e22b64266 ("xen/arm: check read handler behavior") we
> >> assert that the read handlers don't set any bits above the access size.
> > 
> > I see.  That kind of diverges from x86 behavior, that AFAICT (see
> > memcpy() at tail of hvmemul_do_io()) instead truncates the memcpy to
> > the size of the access.
> > 
> > Maybe it would be better to instead of asserting just truncate the
> > returned value to the given size, as that would allow to just return
> > ~0 from handlers without having to care about the specific access
> > size.
> 
> The impression I get from [0] is that that on Arm, there's no benefit to
> performing truncation in xen/arch/arm/io.c. Doing so would needlessly
> affect other Arm internal read handlers (e.g. vGIC).

But isn't this truncation desirable in order to avoid possibly setting
bits outside of the access size?

> For vPCI
> specifically, however, we could potentially perform truncation in
> xen/arch/arm/vpci.c. So I guess it's a question of whether we want to
> give special treatment to vPCI compared to all other read handlers on
> Arm?

I would think doing the truncation uniformly for all reads would be
better, as we then ensure the value propagated to the registers always
matches the access size?

I'm not expert on ARM, but it seems cumbersome to force this to all
internal handlers, instead of just truncating the value in a single
place.

> >> I had adjusted data here due to returning it directly from vpci_read()
> >> in the current form of the patch. With your suggestion below we would
> >> only need to adjust vpci_read_hw() (and then data here would not
> >> strictly need adjusting).
> > 
> > Both returns would need adjusting IMO,
> 
> OK
> 
> > and it should have been part of
> > 9a5e22b64266 I think, since that's the commit that introduced the
> > checking.
> 
> If we proceed with adjusting vpci_read() and vpci_read_hw(): are you OK
> with these adjustments included in this patch, or would you prefer them
> being split into a pre-patch?

Ideally it should be a separate patch with a "Fixes:" tag that points
to the patch that added the ASSERT().  As I think the current vPCI code is
kind of broken without that truncation on ARM?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 07 20:20:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 20:20:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978813.1365663 (Exim 4.92)
	(envelope-from )
	id 1uClFY-0000oP-Jj; Wed, 07 May 2025 20:20:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978813.1365663; Wed, 07 May 2025 20:20: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 1uClFY-0000oI-Ge; Wed, 07 May 2025 20:20:16 +0000
Received: by outflank-mailman (input) for mailman id 978813;
 Wed, 07 May 2025 20:20:15 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uClFX-0000oC-Bn
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 20:20:15 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uClFW-00FFju-30;
 Wed, 07 May 2025 20:20:14 +0000
Received: from [2a02:8012:3a1:0:c9b5:a95:fe54:4681]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uClFW-004sYh-26;
 Wed, 07 May 2025 20:20: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=ARMWzLav3jB4dx6trLgEyVdyoz4nQsU0LPXorHA/phg=; b=kKDCSSTSIZH1IyDzuRbQPJFPYN
	XUumWDFxVM9FF7DeBwjndHTGqs4ydz8u5jc3yG8Z85B7w9DaTmuQWTUMTfTsihNCTVSM3IOvSGBQR
	XP+fpSgCMRIsFSx1jnDuYB/XbVHweTg6v10oVKURVvyDSLHBuleegjNSdEYhbcJetFUw=;
Message-ID: <084a2708-f6e0-497d-9fd7-59408ddad6df@xen.org>
Date: Wed, 7 May 2025 21:20:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/7] arm/mpu: Introduce MPU memory mapping flags
Content-Language: en-GB
To: Luca Fancellu 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250411145655.140667-1-luca.fancellu@arm.com>
 <20250411145655.140667-6-luca.fancellu@arm.com>
 <64f32855-e33d-4d89-9066-e63f0f1cce94@xen.org>
 <4E014B93-3CFC-4FAD-B177-6B61A4996B7D@arm.com>
From: Julien Grall 
In-Reply-To: <4E014B93-3CFC-4FAD-B177-6B61A4996B7D@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 16/04/2025 17:52, Luca Fancellu wrote:
> Hi Julien,

Hi Luca,

Sorry for the late answer.

> 
>> On 14 Apr 2025, at 12:48, Julien Grall  wrote:
>>
>> Hi Luca,
>>
>> On 11/04/2025 23:56, Luca Fancellu wrote:
>>> Introduce the MPU memory mapping flags in asm/page.h.
>>> Signed-off-by: Luca Fancellu 
>>> ---
>>>   xen/arch/arm/include/asm/page.h | 25 +++++++++++++++++++++++++
>>>   1 file changed, 25 insertions(+)
>>> diff --git a/xen/arch/arm/include/asm/page.h b/xen/arch/arm/include/asm/page.h
>>> index 69f817d1e68a..22f7d2c6cb30 100644
>>> --- a/xen/arch/arm/include/asm/page.h
>>> +++ b/xen/arch/arm/include/asm/page.h
>>> @@ -62,6 +62,7 @@
>>>     #define MAIRVAL (MAIR1VAL << 32 | MAIR0VAL)
>>>   +#ifdef CONFIG_MMU
>>>   /*
>>>    * Layout of the flags used for updating the hypervisor page tables
>>>    *
>>> @@ -90,6 +91,30 @@
>>>   #define _PAGE_CONTIG_BIT    8
>>>   #define _PAGE_CONTIG        (1U << _PAGE_CONTIG_BIT)
>>>   +#else /* !CONFIG_MMU */
>>> +
>>> +/*
>>> + * Layout of the flags used for updating MPU memory region attributes
>>> + * [0:2] Memory attribute Index
>>> + * [3:4] Execute Never
>>> + * [5:6] Access Permission
>>
>> I am rather confused why we are splitting Execute Never from the Access Permission. I guess you tried to match the HW, but it also means we need to duplicate a lot of define between the MMU and MPU code.
>>
>> Instead, I would rather try to re-use the existing ones and ignore the ones we don't need (e.g. BLOCK_BIT and CONTIG).
> 
> I’m having a bit of trouble understanding the MMU part:
> 
> /*
> * Layout of the flags used for updating the hypervisor page tables
> *
> * [0:2] Memory Attribute Index
> * [3:4] Permission flags
> * [5] Page present
> * [6] Only populate page tables
> * [7] Superpage mappings is allowed
> * [8] Set contiguous bit (internal flag)
> */
> #define PAGE_AI_MASK(x) ((x) & 0x7U)
> 
> #define _PAGE_XN_BIT 3
> #define _PAGE_RO_BIT 4
> #define _PAGE_XN (1U << _PAGE_XN_BIT)
> #define _PAGE_RO (1U << _PAGE_RO_BIT)
> #define PAGE_XN_MASK(x) (((x) >> _PAGE_XN_BIT) & 0x1U)
> #define PAGE_RO_MASK(x) (((x) >> _PAGE_RO_BIT) & 0x1U)
> 
> I can see on the MMU basically AP[1] means RO or not, AP[0] means XN or not, from the arm spec
> (verison L.a, D8.4.2.1.1 Stage 2 data accesses using Direct permissions) I can see stage 2 AP[1:0] is:
>   - 00: no access
>   - 01: RO
>   - 10: WO
>   - 11: RW

This is describing the stage-2 S2AP field. Whereas the flags above are 
only used for EL2 stage-1. So you want to look at the table
Table D8-62. That said...

> 
> So:
>   - 00: read-only is zero and execution is allowed
>   - 01: read-only is zero and execution is not allowed
>   - 10: read-only is one (??), execution is allowed
>   - 11: read-only is one (??), execution is not allowed

... part of flags doesn't directly correspond to AP. Instead, we 
individually set AP[2] (called ro for Xen), AP[1] is RES1 (as we have 
only one exception level). And then 'xn' is set separately.

See mfn_to_xen_entry() and xen_pt_update_entry():

         /* Set permission */
         pte.pt.ro = PAGE_RO_MASK(flags);
         pte.pt.xn = PAGE_XN_MASK(flags);

Let me know if it makes sense.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 07 21:18:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 21:18:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978827.1365672 (Exim 4.92)
	(envelope-from )
	id 1uCm9e-0007Wi-Kk; Wed, 07 May 2025 21:18:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978827.1365672; Wed, 07 May 2025 21: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 1uCm9e-0007Wb-Hw; Wed, 07 May 2025 21:18:14 +0000
Received: by outflank-mailman (input) for mailman id 978827;
 Wed, 07 May 2025 21:18:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCm9d-0007WV-AK
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 21:18:13 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2418::61e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c6238b91-2b88-11f0-9eb4-5ba50f476ded;
 Wed, 07 May 2025 23:18:09 +0200 (CEST)
Received: from BYAPR07CA0101.namprd07.prod.outlook.com (2603:10b6:a03:12b::42)
 by CH3PR12MB8657.namprd12.prod.outlook.com (2603:10b6:610:172::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Wed, 7 May
 2025 21:18:00 +0000
Received: from SJ5PEPF000001D5.namprd05.prod.outlook.com
 (2603:10b6:a03:12b:cafe::81) by BYAPR07CA0101.outlook.office365.com
 (2603:10b6:a03:12b::42) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.29 via Frontend Transport; Wed,
 7 May 2025 21:18:00 +0000
Received: from SATLEXMB03.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_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Wed, 7 May 2025 21:18:00 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 7 May
 2025 16:17:59 -0500
Received: from [172.31.225.170] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 7 May 2025 16:17: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" 
X-Inumbo-ID: c6238b91-2b88-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gDDHWkTLTrkGc3ektELJ5P/F0mXymp7YAs0q1IQmHgP20WPY6dkaXAW0k+7hSKXvYdJDIg4WTQ6IqvAh0oCzyxT3pF+hGbB8oymc+ikfSAYWpz4pM5E0ZOUZ9ModTHWDoYrTExWUshkb4WlLoGbrB0WSvUQn/cGOwR6Ny8ujjqbn1DRIvoGUAeOduokl+2yq1ys1Wyj+4evlwaLNabG+IoSNnuUEU14YPN9IeVBaXe++Y0jB15fh8YVt7DN3ZflaIf5yzNIF53ZepH4U+iKj/smSSW8L/J8Ka2s3aPlpSNptzHvo58b/ABxnKAfjTNQD5OyuwwSq0zvPzYXkQ2nC9w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nEJJfgVNEXP58Hz375A3LbpVOdQlQpOr8EdhETwuh6g=;
 b=ceEwTTeNhM9gM9G/AHJ4C4L1+E1tvQ7XhPApjKEuKkBmLvg7qxiNmj/d3Ex5wuH+Iq64sJO471/kvGHECgJxqUUNZvA+dN7cEb7GlWDc9KKwlEFp947KTRFrbkrTzaxxDxEPegPTibBde322KUtscaG+BB5Vqod3mzhnkVR3mevOweyOncZda1/r61muevCOm0Oq+EUx/LD9Yy6IlGedcp6ix1279+NQdTk3gD9Yp5tXwpxVy/QkAWKftEmiIdCQYJD6Q9FcEudAfvQ9Fy3yBZRc7raz9U8HS8bKkxpvoI3Xy3zncKuScVPtFMbLQLmzduEun9S2u5ZePDTIuBdtLQ==
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=nEJJfgVNEXP58Hz375A3LbpVOdQlQpOr8EdhETwuh6g=;
 b=QO1oxQWovA6uA7gRBBJ7NFUYVvnNYRLz/EGRHL4XR7d8R8urSuEyHdqy40/0irJ3sSU0doABLqVsRGVU58bn2uqW3jQo+HLKoaELBvFxOdzFgupm611SL+VBeff/LNjJMXL9a4J0t3J/wpZ9CyJwRuQWMfk6Gf7UxCfvrM0BvAA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <47ee8b59-7b6a-4248-a4bd-f5be9f00f562@amd.com>
Date: Wed, 7 May 2025 17:17:58 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v20 2/2] vpci: translate virtual PCI bus topology for
 guests
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
CC: Julien Grall , ,
	"Oleksandr Andrushchenko" , Anthony PERARD
	, Stefano Stabellini ,
	Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	Jiqian Chen , Mykyta Poturai 
References: <20250418185840.335816-1-stewart.hildebrand@amd.com>
 <20250418185840.335816-3-stewart.hildebrand@amd.com>
  <3693f1ef-e305-4a6b-bb4e-3b842418387f@amd.com>
  
 
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB03.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D5:EE_|CH3PR12MB8657:EE_
X-MS-Office365-Filtering-Correlation-Id: bf1c0a03-e399-477b-5b34-08dd8daca53b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|376014|1800799024|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Mkd4cmtHdElMTSthbHVtK0YzZktCZjRnOHNyYjF0VFpZd3ZiVXp6dVBCQjZ6?=
 =?utf-8?B?d2F2aVB6bTgwQ0F4WmlpNTUweU1qTFhQUUN4QmMzMlBuWkVrOUFUUGJUUVAx?=
 =?utf-8?B?UG5tWEE1SnhIYzBPNktOMDNpR1J3T3Jhd2FHbkZpT3RIcWhBYXpRVjErY0JW?=
 =?utf-8?B?OXcvc3U5YXVGTWhVWktITEtOOE1DK3lyYzdyN2JNczlEV0xrVmtmUjAyK1Rt?=
 =?utf-8?B?VlhMUE1jdUZxaVpjeGRLalhzemtOUS8zNGNXUXlaOGdtMC8rTW1nTU50S05V?=
 =?utf-8?B?OExzNFMvZzlzSEprZUt1MUxGSmtLZUZRYkt4bkNaL3ZGSUpvTjQ1Ly83c2pr?=
 =?utf-8?B?YVEvVkUzZzNFTkY2K2gxMUp3RU0xSFAySkRGOEhUeHU4WWcwUFpWWGp6eVpM?=
 =?utf-8?B?UXliUXkzd2xqSDVkNWpkaXEvUmVjeGNPSmtScUUvVjY5bmdQQ0RqdXVQem1p?=
 =?utf-8?B?bnRlSlJzcFE3QmVSR1dwWkgyYllabEFDU1ltc3N5dm51bTNkK3QrcE1ZV1J4?=
 =?utf-8?B?cjU2cVd2WUpuWWtScTlQVjJja2FNVTZEMXNkVmxVYS9PZXJaN2x2REF3SmN4?=
 =?utf-8?B?cjBEaE91UHYrYU05K2ltaWdhT1hBQUhiSWlOVUNNSEE5SWQ5QTJuVFJDWk5T?=
 =?utf-8?B?Tmd0MG9sdVFqWDNSWnYwcXVVWHRadTNBMnU2WDV6ZXVsTDdGZ0E1c1NNQ1F1?=
 =?utf-8?B?bFh0eUErek1zWnJ5bVpVNWExTXRHMU51dUNaRmxnUHppWDQ2a1c0VmJ3UDNU?=
 =?utf-8?B?cnBhY1pJeC9KSlQ0dGxCeXE2RGdZdE1GTmtFZXBtdTh5akhiNE5pbkQrRURn?=
 =?utf-8?B?RXhOYTlMUEg5cFhMYVdCZkZ2WkI3MVVPNmpSL3o3V1hiSTBwYzBYUmFNOVQw?=
 =?utf-8?B?TTBUbEV3Qm9wUVJQUnFjWlVFd01LbmxpUGUzN0wwbnEwa0tDL1FadU9rTlM4?=
 =?utf-8?B?M1dwRjhodHkrcHhra2l0eEpWaEkvOEF2MlNpbWZUcGI2TUxkaUV5c2RSOGx1?=
 =?utf-8?B?RlVFc1ZwaDdHNzVtOW42cGlob0F2UW1kSDNOdTJsS2ZPcGttMFduUVA4ZnNF?=
 =?utf-8?B?dUNLSVFWbE9QNXArUmRuNmc1NG5ZS2IyL01PS002cEw3MkYzbGJnZTZPQStZ?=
 =?utf-8?B?MEVVaC9HYzdRbjQ5WE0xbTFxd2ZJNTJKbFF4TUs5V3VBQlFOc1h0MlBQRkpq?=
 =?utf-8?B?Vi8xTXd5b2d3bU9WWG1LdUdNdmRZU3BpamZQK1ViQnpzdEIxa0NiOU8wallF?=
 =?utf-8?B?R0l3N3ZrYWY3bHlGQjMvTG1OZmErYmtkNTJRcklTaGhQTlJoZkk5SlJmR1Qw?=
 =?utf-8?B?SXdsMUxoQTNzd2NNYnJKSnY5WFY4VWszaGM3c2FrdEJLY1pMNHJPWGRDT1Js?=
 =?utf-8?B?dTRlY0E4eHREWkVOd3pjVDYyd1hrRzB5Q2VhL3lvUHU0c0FleTV2UHlPTVZ5?=
 =?utf-8?B?eHd6b3pvZEYxVXd3MGlPdzIwT1Q5d0x2cUhGSDVDbWhBRGJ1NXl0bEFVNHl6?=
 =?utf-8?B?UWRGNE9TUW9RSGx2R0c2ckZaYmVBOTQvMFBoNGl5dUY4ZDFwUFVubzUrbkJU?=
 =?utf-8?B?SjFrR2s5ZTM4VlJuOFdZTkF5UDk4VWI2VFVhdE12WGM5MXFCTTVPMWplMG1W?=
 =?utf-8?B?T0hGNHFEZWNyMW1BMENobFo4ZnVNd1hpOEVWZ3JaS2IvV09DdERwbGZ2RlVl?=
 =?utf-8?B?eVk1NWVmcHdwVzd3ZW1UYXpNUXQzRTZHdXc5TzVyVzFQTTl6cXd3SlQ2blFT?=
 =?utf-8?B?RzBDS1dwa1dzOWNTNStkYitNcTBiTlkzZngvZ1JZb3k3a2xuTGw3OVVjbjIv?=
 =?utf-8?B?VVc0VzJWWERiUEZzbHhjWUcrOWNkTWhkbTlYZitVY2FGcjRFYTFmK3V2VENH?=
 =?utf-8?B?OVhQalhadGh0cWc5Q2g2UXpybFNEY1JIWjVjN3hHWXBSQytEblhiVFBaSys1?=
 =?utf-8?B?VEFKSE82aEZ5TUhycXdIVHYyYk4zY0RkaStDSmhjZGZSK05VVEN0RGZVSHZJ?=
 =?utf-8?Q?J1uC3itKQIMiomIQHhnDUUFUR+Of1k=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(376014)(1800799024)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2025 21:18:00.1086
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bf1c0a03-e399-477b-5b34-08dd8daca53b
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=[SATLEXMB03.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: CH3PR12MB8657

On 5/7/25 13:44, Roger Pau Monné wrote:
> On Wed, May 07, 2025 at 09:38:51AM -0400, Stewart Hildebrand wrote:
>> On 5/7/25 03:44, Roger Pau Monné wrote:
>>> On Tue, May 06, 2025 at 11:05:13PM -0400, Stewart Hildebrand wrote:
>>>> On 5/6/25 07:16, Roger Pau Monné wrote:
>>>>> On Fri, Apr 18, 2025 at 02:58:37PM -0400, Stewart Hildebrand wrote:
>>>>>> From: Oleksandr Andrushchenko 
>>>>>>  static int vpci_register_cmp(const struct vpci_register *r1,
>>>>>>                               const struct vpci_register *r2)
>>>>>>  {
>>>>>> @@ -438,7 +473,7 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
>>>>>>      const struct pci_dev *pdev;
>>>>>>      const struct vpci_register *r;
>>>>>>      unsigned int data_offset = 0;
>>>>>> -    uint32_t data = ~(uint32_t)0;
>>>>>> +    uint32_t data = 0xffffffffU >> (32 - 8 * size);
>>>>>
>>>>> This seems kind of unrelated to the rest of the code in the patch,
>>>>> why is this needed?  Isn't it always fine to return all ones, and let
>>>>> the caller truncate to the required size?
>>>>>
>>>>> Otherwise the code in vpci_read_hw() also needs to be adjusted.
>>>>
>>>> On Arm, since 9a5e22b64266 ("xen/arm: check read handler behavior") we
>>>> assert that the read handlers don't set any bits above the access size.
>>>
>>> I see.  That kind of diverges from x86 behavior, that AFAICT (see
>>> memcpy() at tail of hvmemul_do_io()) instead truncates the memcpy to
>>> the size of the access.
>>>
>>> Maybe it would be better to instead of asserting just truncate the
>>> returned value to the given size, as that would allow to just return
>>> ~0 from handlers without having to care about the specific access
>>> size.
>>
>> The impression I get from [0] is that that on Arm, there's no benefit to
>> performing truncation in xen/arch/arm/io.c. Doing so would needlessly
>> affect other Arm internal read handlers (e.g. vGIC).
> 
> But isn't this truncation desirable in order to avoid possibly setting
> bits outside of the access size?

On Arm we expect the read handlers to have the bits above the access
size zeroed. If a read handler sets bits above the access size, it could
indicate a bug in the read handler. As a reminder, this was already
discussed at [0] and a patch was already committed 9a5e22b64266
("xen/arm: check read handler behavior"). Perhaps we could both keep the
ASSERT (for debug builds) and perform truncation (for release builds) in
xen/arch/arm/io.c:handle_read(), but that's patch for another day.

[0] https://lore.kernel.org/xen-devel/20240522225927.77398-1-stewart.hildebrand@amd.com/T/#t

>> For vPCI
>> specifically, however, we could potentially perform truncation in
>> xen/arch/arm/vpci.c. So I guess it's a question of whether we want to
>> give special treatment to vPCI compared to all other read handlers on
>> Arm?
> 
> I would think doing the truncation uniformly for all reads would be
> better, as we then ensure the value propagated to the registers always
> matches the access size?
> 
> I'm not expert on ARM, but it seems cumbersome to force this to all
> internal handlers, instead of just truncating the value in a single
> place.

To move this forward, I suggest performing this truncation in
xen/arch/arm/vpci.c:vpci_mmio_read(). This will be a single place to
perform truncation for Arm vPCI, and will not affect other Arm internal
mmio handlers.


From xen-devel-bounces@lists.xenproject.org Wed May 07 22:47:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 22:47:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978860.1365693 (Exim 4.92)
	(envelope-from )
	id 1uCnXo-0002M6-2g; Wed, 07 May 2025 22:47:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978860.1365693; Wed, 07 May 2025 22:47: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 1uCnXn-0002Lz-Vg; Wed, 07 May 2025 22:47:15 +0000
Received: by outflank-mailman (input) for mailman id 978860;
 Wed, 07 May 2025 22:47:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCnXm-00027q-JU
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 22:47:14 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2416::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 369ed8ad-2b95-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 00:47:12 +0200 (CEST)
Received: from MW4PR04CA0281.namprd04.prod.outlook.com (2603:10b6:303:89::16)
 by MW6PR12MB9018.namprd12.prod.outlook.com (2603:10b6:303:241::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Wed, 7 May
 2025 22:47:00 +0000
Received: from MWH0EPF000971E4.namprd02.prod.outlook.com
 (2603:10b6:303:89:cafe::79) by MW4PR04CA0281.outlook.office365.com
 (2603:10b6:303:89::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.32 via Frontend Transport; Wed,
 7 May 2025 22:47:00 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000971E4.mail.protection.outlook.com (10.167.243.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Wed, 7 May 2025 22:46:59 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 7 May
 2025 17:46:58 -0500
Received: from xsjstefanos51.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend
 Transport; Wed, 7 May 2025 17:46: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" 
X-Inumbo-ID: 369ed8ad-2b95-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=D+lxbHcTN0tQnvxPin5mebs7QJV73W7GqjyqL28/QZfoQHXbT/xaSIw8MHs9cVV1KuYEi+X1PvYHOtO4BS0bNBnHDw5LCegXNhg4iUoH0DQalbhU3K7mPwQNvx1bBrZWp252lF08EbkW9/eLVibcWTnhgWxQLs2Rcn+huUafcrIr4z7f1JLX1DiBa5og5e2MtNzwlCPUf/tXjvwDnXAlfEaV7/xs0lfJ5O06tA4NwjwT8j7nc+kqmbXnjxXsSF8E/3Xko5RuYlCpwA6yC1LKjSLY9Ppc8fCMnp0XqWZk5yplO4UZqoswg4k8U2lbTyDoQ2c8UssnIlEp8AqGG5Q1MA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6mFAi4zYRUkBuhbz9pnZdU9K7CsFcZrta7WY6BXIQCE=;
 b=H3cZ8XRucGENSuyxpXXPUuD0Ghk8SJP72ocvOLcf/IGvGpmPExjEmNLOqnG31p9iw0fkTmnWcHf2r5wtWkhSnWiJsE3e+Mzo+Rv6TPSvat2AW1DapnF89ysgcptiIeHRd3Oz/ygbFSO3AFrA8Ug/dXDBlMv6yvofzqVmjHsQQWsIoqhuLAU9t5bk51ROTI5Rh4qdoTPlzC3caggmeMJWPTLILKx1qWjjMx9G5T7Y54uRqQ+MYkvAvYzLE+F7D/k1NCSrp0d09pVVUmEPkpgCmoytM4ZPNjnsDNkDZ4SXIVYGNMf8/m9caHJM/5sD7xVhCf+tHuTW5dhOzx+JC92gxw==
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=6mFAi4zYRUkBuhbz9pnZdU9K7CsFcZrta7WY6BXIQCE=;
 b=Ep0PGq2zTclxeRcF41CsCGmjgeqkccPQNVh/GZBd8zqdjtY3HwoZC0AsH60pgGPvx4ZPWu34cmUlkOov5CeV4VL6KRp4m0mDP20Gc2FwR6Ss24e/p1Y5Ot0FEYtPVnT5Tx3NnwzTIV8HopycU/LDUmaRosl+jVG9q9TMQwaHEjU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: 
To: 
CC: Nicola Vetrini , Victor Lira
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel ,
	"Jan Beulich" , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Federico Serafini
	, Bertrand Marquis 
Subject: [PATCH v1 1/2] x86: x86_emulate: address violation of MISRA C Rule 13.2
Date: Wed, 7 May 2025 15:46:39 -0700
Message-ID: <77f9c4cabe607ce4024013c604bc790fb629d322.1746657135.git.victorm.lira@amd.com>
X-Mailer: git-send-email 2.47.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB04.amd.com: victorm.lira@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000971E4:EE_|MW6PR12MB9018:EE_
X-MS-Office365-Filtering-Correlation-Id: 75777940-4063-49b3-cf23-08dd8db913df
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|7416014|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?elozb1hJYkY1Z1Y3Nm5RMWJiZk4wNHIyR1dzak9PZlA0V3FJa3ZkQitRT2p3?=
 =?utf-8?B?bzd0VzdPOE1yRVRoeEo4Vm1TNE9aYUs1NWhTSUVSV01JQ2lDR2xHSDJabTg1?=
 =?utf-8?B?SlFOcjZSRDVsVkJxdFhXNHJlZjRSczk0WU1lekhVaVBsNFpOY2wzZjBVNHJy?=
 =?utf-8?B?MG5DN0wxQWJRQXMwaEszc3EwZDdKK3RUSFZqZHBrak9jcHgzaTNwcWN2d3Nj?=
 =?utf-8?B?L3lvUHBPSGw4NXVtMXhxTDk2L1A5S2psYXNjajRVc3R5YVNYOVdzckxzN0JX?=
 =?utf-8?B?TnBmT3dSZ3loeUEvS3Mya3B6MCsyUG8vZ2cveU9jRlRoU3VJcmtFc1hvL1hi?=
 =?utf-8?B?Q1JpbzBpZnhncGpvbWt0Vk1xaFVEMmlZTk45ZjJsMXBlZ0N2Z0d1RXhrZVBP?=
 =?utf-8?B?K3J6VmhVU1h1dzFJVWVUcXRPRi9ObkM1eWhLUXdSZXV5RmNkMDcrYUxmVjBI?=
 =?utf-8?B?dUlhcFkyUjQxQjVUT3RaQmFUOTJQOG13ekhRM3V5TFFlRXRjenY5dCtoQ2Vs?=
 =?utf-8?B?L3YxVUJFQ3BiSnZvRTlaUFh2dmo4alJyMXlGQUszVzF4b3dDQTl2VjFpcktW?=
 =?utf-8?B?MXFCSmx6aytCT241dk5nRVBPZytCaUoxRFVRLzNhMmdLTjVHRFNwdFJPUm41?=
 =?utf-8?B?bVJnczlXV1kzeTZsNVdsSkkxN0o1bjFEdldXSUlmTnQ5TjJpbUlxbkVTTVRz?=
 =?utf-8?B?SkpLYlZnU1JaMnFXTVZCSWFKQ2F6OGRiQ2t1T29mK3ZWM0pzTXVoTzhNZTI1?=
 =?utf-8?B?S1M5WG9ZdjU1RW16RmJ3QkFES08vSG1OL1ZTcldRWUlURlZFOGNveXMrdDZP?=
 =?utf-8?B?QXJtek4vTE1KWXk1Z3VsUlI0T3dDR2VMU25HeW1WeXJMMXJuT2dPRTFFTDVE?=
 =?utf-8?B?eFV0YWhjRlpFR3Y4Zlkxa1RMdlplakxqaFRzZHBya1VNWG1mSlAyUDlIV1F2?=
 =?utf-8?B?QVpJYTJjN2ZhTjlhM2lPcy9Md3ZPRGd2SzJBYlVHVmR4d21FRDdGb1JiaEJy?=
 =?utf-8?B?TXJyZDdpZk1xQzBpNVhmRVhNTTFrZDg0Y0NVMzhsR2ZmTlhFVjI1UkNzME56?=
 =?utf-8?B?R1ZkREtZOTZJMVFMSXhGbjRxODZSTDc0OUcwbG4yaXZDY3hYbmRpOEdnbE5y?=
 =?utf-8?B?cEQyWnE5QjFMMWhqeFk1czBNdWYxZFlKRFRTZU1ORW9CY1N1MU4rK0U0L0lF?=
 =?utf-8?B?RXN0WnJLb3hZZ2Y4b1ZUbnN3a2l6R2ZDeFh4RDZXaFlNWnZmWW9IamJlL3J6?=
 =?utf-8?B?OUZHZjRWamFtMVRvZnZhSkdQTnB0anROUkREYjI5NkZ0aUlxaVl4UWZ3SUxa?=
 =?utf-8?B?V2pmbHhZUzdqa2Y2d3FFa1NXYnhyQ2VVS0lqUWlyamVJbWNocTZZd1Zvb042?=
 =?utf-8?B?MTZtT3o1eDdEY2h2UVNkOE5ObkI1ZitPOEJwQTVzTTU2SU1yM0RLUDgvS255?=
 =?utf-8?B?OTc3VXF4b2F5ZmxlOU9YUmtpV3RENUF1ZFZtdDNiYW5jd2QwZWtSVUVBNGw5?=
 =?utf-8?B?b3AxNXZzeW5pMk04VmNKcHRJa2JmU2JTaDJlbU9VSXZDNlk2Y3ZaaGFJZXVV?=
 =?utf-8?B?cTZwKzN2eFNTKzJGTEt2Mkljb2xvekJ4bXc4UkRiUjYvL0s0ZG5Qc3NaQkV3?=
 =?utf-8?B?NVMvSzA4V3hrdncwUDBMZk4zSlRMc0NrTWtVaGdsYk9udXFxM2IvVG1vQnZH?=
 =?utf-8?B?SkEwYXpvbVg4cnc3RisyNDhCUXFNOVJjYkxXeUgxcHpzUzZ5K2phYlBhVE9X?=
 =?utf-8?B?RFRpK252T2pFd3drM3cvMmV3ak5nb2hrWWdoWkM4Y3lOVC93UmR2QTRTYm1i?=
 =?utf-8?B?b01lR0k0U01pL2JmbzBRZVFnM1F3a0JBOXl1V1UrOXpEb3BDNnlhZGx1ZUxS?=
 =?utf-8?B?QU1KSDZPb2pvQlNXblZsWnl5b2pjSUc4M2JTRkg5V3BZNTIrZEJvRzI1RElO?=
 =?utf-8?B?Z1JqQnBNY3BtQ0Z6QXozTWZmSG82SnBFSnVldG0zRVhCcERPWXdoZHNmUnRn?=
 =?utf-8?B?L0M0WnlNa0RTUGw4Ty9LS3FMUmRpSXZ6Vy93bzgrUFhDdC8xTGdLNjZKRUND?=
 =?utf-8?Q?jZEuZI?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(7416014)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2025 22:46:59.6926
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 75777940-4063-49b3-cf23-08dd8db913df
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000971E4.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB9018

From: Nicola Vetrini 

Rule 13.2 states: "The value of an expression and its persistent
side effects shall be the same under all permitted evaluation orders".

The full expansion of macro "commit_far_branch" contains an assignment to
variable "rc", which is also assigned to the result of the GNU statement
expression which "commit_far_branch" expands to.

To avoid any dependence on the order of evaluation, the latter assignment
is moved inside the macro.

Signed-off-by: Nicola Vetrini 
Signed-off-by: Victor Lira 
---
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Roger Pau Monné 
Cc: Stefano Stabellini 
Cc: Nicola Vetrini 
Cc: Federico Serafini 
Cc: Bertrand Marquis 
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index 8e14ebb35b..7108fe7b30 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -337,7 +337,7 @@ do {                                                                    \
     validate_far_branch(cs, newip);                                     \
     _regs.r(ip) = (newip);                                              \
     singlestep = _regs.eflags & X86_EFLAGS_TF;                          \
-    ops->write_segment(x86_seg_cs, cs, ctxt);                           \
+    rc = ops->write_segment(x86_seg_cs, cs, ctxt);                      \
 })

 int x86emul_get_fpu(
@@ -2382,7 +2382,7 @@ x86_emulate(
              (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + src.val),
                               &src.val, op_bytes, ctxt, ops)) ||
              (rc = load_seg(x86_seg_cs, src.val, 1, &cs, ctxt, ops)) ||
-             (rc = commit_far_branch(&cs, dst.val)) )
+             commit_far_branch(&cs, dst.val) )
             goto done;
         break;

@@ -2438,7 +2438,7 @@ x86_emulate(
         _regs.eflags &= mask;
         _regs.eflags |= (eflags & ~mask) | X86_EFLAGS_MBS;
         if ( (rc = load_seg(x86_seg_cs, sel, 1, &cs, ctxt, ops)) ||
-             (rc = commit_far_branch(&cs, (uint32_t)eip)) )
+             commit_far_branch(&cs, (uint32_t)eip) )
             goto done;
         break;
     }
@@ -2557,7 +2557,7 @@ x86_emulate(
         ASSERT(!mode_64bit());
     far_jmp:
         if ( (rc = load_seg(x86_seg_cs, imm2, 0, &cs, ctxt, ops)) ||
-             (rc = commit_far_branch(&cs, imm1)) )
+             commit_far_branch(&cs, imm1) )
             goto done;
         break;

--
2.47.0


From xen-devel-bounces@lists.xenproject.org Wed May 07 22:47:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 22:47:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978859.1365683 (Exim 4.92)
	(envelope-from )
	id 1uCnXl-000283-Qx; Wed, 07 May 2025 22:47:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978859.1365683; Wed, 07 May 2025 22:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCnXl-00027w-O9; Wed, 07 May 2025 22:47:13 +0000
Received: by outflank-mailman (input) for mailman id 978859;
 Wed, 07 May 2025 22:47:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCnXk-00027q-HD
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 22:47:12 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2414::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3396a786-2b95-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 00:47:07 +0200 (CEST)
Received: from MW4PR04CA0300.namprd04.prod.outlook.com (2603:10b6:303:89::35)
 by MN0PR12MB5906.namprd12.prod.outlook.com (2603:10b6:208:37a::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Wed, 7 May
 2025 22:47:01 +0000
Received: from MWH0EPF000971E4.namprd02.prod.outlook.com
 (2603:10b6:303:89:cafe::f0) by MW4PR04CA0300.outlook.office365.com
 (2603:10b6:303:89::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.31 via Frontend Transport; Wed,
 7 May 2025 22:47:01 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000971E4.mail.protection.outlook.com (10.167.243.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Wed, 7 May 2025 22:47:00 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 7 May
 2025 17:47:00 -0500
Received: from xsjstefanos51.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend
 Transport; Wed, 7 May 2025 17:46:59 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3396a786-2b95-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jcbApUvtbgwqD43yVdf+Dd5YV8ztzgpvefJW4/eOQ05uieWdwst4oAvc1V8mJH5uFeDm9tkFprst+7Q30f0P5e6LSDs6fzMB71+o1VW1AQjPPEIg6NNTg7ivp4a10HhtVZDPOodbRGtiCJ6tIqWvY1qqzKD6psa+tw67URFCZ9sX4/ziwwojxGJtO7+9nOzakvMosD3qzIvSdvEjabDQGz+WAWheV8+OU26PTPiLTeMEIDcFRb0onqFiSoLQQhP4a1stRHyBgBU3yfP9ldl+/5BybBsmdcG8RK7B6kOn/JNqxjdWRw9RjCmmeFByAuBZFxt18nFJIvWk9JGCiup7Og==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9h1zJoppazSV/QiQJBgP0elD4xcBB4mfIivoo79ocI0=;
 b=IQEUVCUYNA3kRRY89cnn6x0YvicrwIG/6KLNHNixafe13A1Y2Yyc8ypsKptb3f/jn2m5N8VOAly3iy0tOQtSF2Fvm4X3BLZGzhqK60rA12hPZmrCb2wMLOr3qqzufYWCR25GWY5Pf6OvwvpHEQ+Qe9z9SRyGWf8Uadi66IfhlfQQYZ8vpNfnltaDDuITd2/wzSdaBfEJ9cuMFuAbiwm+bdZUBwBsE24YlxAVjrPi8LMWG6AXvST/M7yrszGbGkBE26P6T03TIhkE0rZ4JpNw8l3TPsD1UMarbff2uwfAWzjDs068De3TB2G3ltDEsuGcrQe2n37e5Imc1iX05FwxjQ==
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=9h1zJoppazSV/QiQJBgP0elD4xcBB4mfIivoo79ocI0=;
 b=hFC1MAPbVv/5K7kNaJLfGuDaXWuoVW85dGmP9o+DguVigMYVwKq5FaViYkmxHMKyVIXPjYFCbbrxgjVi6L7T6GVMUVyJff65lg4Bd31vEh/TUyD1KcB2rRF0ZYYdy9QcF1CMwJZkxi0uRGUpVPhoZHuFYUDOjlZSx1RpxpTXi0M=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: 
To: 
CC: Federico Serafini , Victor Lira
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel ,
	"Jan Beulich" , Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Nicola Vetrini
	, Bertrand Marquis 
Subject: [PATCH v1 2/2] automation/eclair: tag Rule 13.2 as clean
Date: Wed, 7 May 2025 15:46:40 -0700
Message-ID: 
X-Mailer: git-send-email 2.47.0
In-Reply-To: <77f9c4cabe607ce4024013c604bc790fb629d322.1746657135.git.victorm.lira@amd.com>
References: <77f9c4cabe607ce4024013c604bc790fb629d322.1746657135.git.victorm.lira@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB04.amd.com: victorm.lira@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000971E4:EE_|MN0PR12MB5906:EE_
X-MS-Office365-Filtering-Correlation-Id: 80bf0b4a-fd3d-4aa7-9547-08dd8db9148f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bUpDNDc3L2lFSDRiczFPZXBXMEhQUXp4SkhVVVpXZTdZZmRZMlJkNWxiMThx?=
 =?utf-8?B?MzBGSWk0ejA1OG5KZCtIVkZVV0pMY0ErWFJCVHZEcCs4MWhnS2hBRUNJMkx0?=
 =?utf-8?B?UlJPNmg4Y1doVlZKcWcxRThiSEtwcDlYTytlUE5XbExLbDJGNXJDcG1DcCtY?=
 =?utf-8?B?VVlGcytsZzY1UFFtcklwK2xueXdUREFRMWV5VzJvd09vNlQrNml1QTk1TS9w?=
 =?utf-8?B?ek0xTHFiNTNmNlQ2MmMwam1zaVFyT3pjQ3FJNGp6Q2J3OWJkZExWZlVycmd1?=
 =?utf-8?B?WGF6REJHRHZnNkZveTZwL0lRSkh0ajU3RWYrMExQbGU1Wm56b2RYeXdXdHdw?=
 =?utf-8?B?YWZDMmhySHlQRW5KMGI3cUhPVCszNFJUQzlmRVdDWVlqNGJhdm5PaU1GSStS?=
 =?utf-8?B?bWlNUml2aUNQWjhzL2pjaUpuL0RENFZ3UEhqbFo3VlY5NVFtWHpIdkxKSXNz?=
 =?utf-8?B?bmtWZjNGSnZSMGhKRG1ycDg1T1hLaVA3WGl2T3hDdjNWNmF5cFNLSlE2WXZC?=
 =?utf-8?B?RDF2bTFJd1gwbzRzYU9KZkhJSWp4QXdicWJXaXlZaDdVU0w3anBZUnp4eXVo?=
 =?utf-8?B?RUw0cG40aDNlYmRsb1JLd0pHQnEwNE5kSElDSzJEKzNIeU1hN2NPdm1BcGU3?=
 =?utf-8?B?amFKTmVQWHFWNG1XTGpvNjZUODJLQ2x1NWtmaUNSYVpBK04vSnpwTmxRMGhW?=
 =?utf-8?B?R3JERkZGMnVGbFJCVVYyL3grQWRnaEdzNmlzQ3EvVURZUmlWeC91aWY0WTNB?=
 =?utf-8?B?K2JXcnZtQzd5ZmFFa0cyNEF2L254KzVlSGxQQm15clZ4aXl6N1lId2NPTStC?=
 =?utf-8?B?OFhYZWdEektqcEpMbS83ckRlaVNrdFRyR2lLcUtUaVVVNjA3QWoreW0rVzZH?=
 =?utf-8?B?RWowN3RJeVRYdlZlcUpNV3RJWmNNSXFVRkw5clpUYzRzZjUyMTRDR1RvYWZT?=
 =?utf-8?B?VS9CazJGMmhKWFRjdnpUWjZDeERkakU4alBHM25GQk53My9KaTVYd1F2SWhi?=
 =?utf-8?B?N1RXb3plWm9qeFA5NE9RbldxQytXMlpMWjU4MDJJRitoak5STGV5TVBKRzhY?=
 =?utf-8?B?eDdIVGFJcmxkQkp2VDhFbCtNcjVjU2M2YzE4OEY1QndqL0tnT1FnZlpEMk4x?=
 =?utf-8?B?UlY2Z1J0Z1VSSkE0KzZkU0FtN0RIQ3lsdnA2VjkyWFNsMmJKaE1EblJUallr?=
 =?utf-8?B?YjZ6RFdMWUFoUW1KMFkydFdUbllBYUhNbkVwY1JJSlJhck9OZkJhNVBEU0Vz?=
 =?utf-8?B?dzVocXlqdllGOC9td2liUGQ3RUtmZnlQS2Eva1kwV0ZIYld3T2ljbHpXbUc3?=
 =?utf-8?B?SmdrbTRXdnNwRWpDeHg4RWNISllxNWNtbTZFRE9pNTgvYVhKaU94MGVxZW50?=
 =?utf-8?B?cHlNbmo2VVJEdGxxbWhnQ21tQ1RqTDlhWkMwTnkrU0hJSEJIQjVOWFNlYi94?=
 =?utf-8?B?K2xZSDNPOHc1Yk9kRmhhdXVSZmJ4OHRtRklEdFpsMGRySTF6eTB6S05XMSt4?=
 =?utf-8?B?NDZOMlRsTlFyNTJkaDY0K0dRMjZIZTAzbFl1TmVCT3g5eU9JS2RTZTJBS2dE?=
 =?utf-8?B?MkN6K0swSytlU3NjVGJDbjQxYzBqZGY4eWkzbkMvRDRPVmVWbXZQZGlMSzBH?=
 =?utf-8?B?dEl5bnB2ZGVDZ3pieGl6TWQzM0c5RVRYRzVKQlVtWXdOUmg4WDJLZ2g1R2Zm?=
 =?utf-8?B?M205WDVpcDZweFdPbGtVK0JVQlJsdmREbldJdzAweDNzRTBucmVsVHg5eVdU?=
 =?utf-8?B?Zk5ub3Fpd0gwYmtWOWhEcHE3cWFrMXdCbkVUQjl2eWMzUWoxY0c3NmkyTjkv?=
 =?utf-8?B?ZmZTQ3NsVkRzT3Y5K04vdEE0VUhtbGFvRllLY3I3NThqMEZHNDNmMUNYM3BH?=
 =?utf-8?B?TXlaUHJaN2dVSi9xWUV5cGFrOGpqQ1NiYk5TTDROcmcwSCtSejVmOHJDbGFw?=
 =?utf-8?B?dThGdDVCeDFhcDhLREhNQ21KczBHOWpwcmxmMkd6Q2JQa3VFUjlxd0IxUzR5?=
 =?utf-8?B?TXlPVC9PbkxjSE9XUUJzMXNPRlliVVBEVEZCYmV1OE1MQ1J5OHVrRXR6LzVw?=
 =?utf-8?Q?/w63sd?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2025 22:47:00.8442
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 80bf0b4a-fd3d-4aa7-9547-08dd8db9148f
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000971E4.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5906

From: Federico Serafini 

Update ECLAIR configuration to consider Rule 13.2 as clean so as to
avoid regressions.

Signed-off-by: Federico Serafini 
Signed-off-by: Victor Lira 
---
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Roger Pau Monné 
Cc: Stefano Stabellini 
Cc: Nicola Vetrini 
Cc: Federico Serafini 
Cc: Bertrand Marquis 
---
 automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index 1d078d8905..c958d3ed59 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -63,6 +63,7 @@ MC3A2.R11.6||
 MC3A2.R11.7||
 MC3A2.R11.9||
 MC3A2.R12.5||
+MC3A2.R13.2||
 MC3A2.R13.6||
 MC3A2.R14.1||
 MC3A2.R14.3||
--
2.47.0


From xen-devel-bounces@lists.xenproject.org Wed May 07 23:02:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 23:02:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978881.1365703 (Exim 4.92)
	(envelope-from )
	id 1uCnmR-0005ca-AO; Wed, 07 May 2025 23:02:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978881.1365703; Wed, 07 May 2025 23: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 1uCnmR-0005cT-7a; Wed, 07 May 2025 23:02:23 +0000
Received: by outflank-mailman (input) for mailman id 978881;
 Wed, 07 May 2025 23:02:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCnmQ-0005cN-AK
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 23:02:22 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 51321e96-2b97-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 01:02:16 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id CD6665C465D;
 Wed,  7 May 2025 22:59:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A9F6C4CEE2;
 Wed,  7 May 2025 23:02: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" 
X-Inumbo-ID: 51321e96-2b97-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746658933;
	bh=cvA0hU8fRMdH3DNXGdnJMKTk0d4FGdmMHYBwW5VuKXM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Up8Yc0Ta3SGyGm0R26tYopUQJnzTzuceV56ruNcr691y20uKDI+STnBJNb3jrS0+u
	 X9ywPheN6WK2bllOm/zQO6SJHd5/1wATc9BXkIWDlSTm63JyDyOtqEfsN0sERBwhTi
	 ndYzvDpJer8LZOfTWUYLKSxA/NG7hOaCFEt6NhfWKGCqXFOqqcUJp9IuhDljrp+Qlx
	 hNyqakAbTGFBuetZyOXk66+OVSw7S52T3uVMmJ0F9S97nnWC9q3TGllvueemYH2X/e
	 8SVca7VAtN9sEbDV8iPKh7BEnL4tN9lxVGF69MSnxoYAQ61uI2Ot28xY+TM6MvIPMV
	 ZOmNtxEb3iZBQ==
Date: Wed, 7 May 2025 16:02:11 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
cc: Stefano Stabellini , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Jan Beulich , 
    "Ragiadakou, Xenia" , 
    Andrew Cooper , jason.andryuk@amd.com, 
    agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
In-Reply-To: 
Message-ID: 
References:  <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>   
  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1460966867-1746576173=:3879245"
Content-ID: 

  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-1460966867-1746576173=:3879245
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Tue, 6 May 2025, Roger Pau Monné wrote:
> On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
> > On Mon, 5 May 2025, Roger Pau Monné wrote:
> > > On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> > > > On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
> > > > > On Mon, 28 Apr 2025, Jan Beulich wrote:
> > > > > > On 25.04.2025 22:19, Stefano Stabellini wrote:
> > > > > > > From: Xenia Ragiadakou 
> > > > > > > 
> > > > > > > Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> > > > > > > addresses to firmware or co-processors not behind an IOMMU.
> > > > > > 
> > > > > > I definitely don't understand the firmware part: It's subject to the
> > > > > > same transparent P2M translations as the rest of the VM; it's just
> > > > > > another piece of software running there.
> > > > > > 
> > > > > > "Co-processors not behind an IOMMU" is also interesting; a more
> > > > > > concrete scenario might be nice, yet I realize you may be limited in
> > > > > > what you're allowed to say.
> > > > > 
> > > > > Sure. On AMD x86 platforms there is a co-processor called PSP running
> > > > > TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionally to
> > > > > pass addresses to it.  See drivers/tee/amdtee/ and
> > > > > include/linux/psp-tee.h in Linux.
> > > > 
> > > > We had (have?) similar issue with amdgpu (for integrated graphics) - it
> > > > uses PSP for loading its firmware. With PV dom0 there is a workaround as
> > > > dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, but I
> > > > expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's
> > > > the one I used for debugging this issue).
> > > 
> > > That's ugly, and problematic when used in conjunction with AMD-SEV.
> > > 
> > > I wonder if Xen could emulate/mediate some parts of the PSP for dom0
> > > to use, while allowing Xen to be the sole owner of the device.  Having
> > > both Xen and dom0 use it (for different purposes) seems like asking
> > > for trouble.  But I also have no idea how complex the PSP interface
> > > is, neither whether it would be feasible to emulate the
> > > interfaces/registers needed for firmware loading.
> > 
> > Let me take a step back from the PSP for a moment. I am not opposed to a
> > PSP mediator in Xen, but I want to emphasize that the issue is more
> > general and extends well beyond the PSP.
> > 
> > In my years working in embedded systems, I have consistently seen cases
> > where Dom0 needs to communicate with something that does not go through
> > the IOMMU. This could be due to special firmware on a co-processor, a
> > hardware erratum that prevents proper IOMMU usage, or a high-bandwidth
> > device that technically supports the IOMMU but performs poorly unless
> > the IOMMU is disabled. All of these are real-world examples that I have
> > seen personally.
> 
> I wouldn't be surprised, classic PV dom0 avoided those issues because
> it was dealing directly with host addresses (mfns), but that's not the
> case with PVH dom0.

Yeah


> > In my opinion, we definitely need a solution like this patch for Dom0
> > PVH to function correctly in all scenarios.
> 
> I'm not opposed to having such interface available for PVH hardware
> domains.  I find it ugly, but I don't see much other way to deal with
> those kind of "devices".  Xen mediating accesses for each one of them
> is unlikely to be doable.
> 
> How do you hook this exchange interface into Linux to differentiate
> which drivers need to use mfns when interacting with the hardware?

In the specific case we have at hands the driver is in Linux userspace
and is specially-written for our use case. It is not generic, so we
don't have this problem. But your question is valid.

In Linux, the issue is hidden behind drivers/xen/swiotlb-xen.c and
xen_arch_need_swiotlb. There are a few options:
- force swiotlb bounce for everything on the problematic SoC
- edit xen_arch_need_swiotlb to return true for the problematic device
- introduce a kernel command line option to specify which device
  xen_arch_need_swiotlb should return true for
- introduce an ACPI table with the relevant info
--8323329-1460966867-1746576173=:3879245--


From xen-devel-bounces@lists.xenproject.org Wed May 07 23:09:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 07 May 2025 23:09:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978896.1365714 (Exim 4.92)
	(envelope-from )
	id 1uCntF-0006HT-4v; Wed, 07 May 2025 23:09:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978896.1365714; Wed, 07 May 2025 23:09: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 1uCntE-0006HM-Vu; Wed, 07 May 2025 23:09:24 +0000
Received: by outflank-mailman (input) for mailman id 978896;
 Wed, 07 May 2025 23:09:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCntD-0006HG-5b
 for xen-devel@lists.xenproject.org; Wed, 07 May 2025 23:09:23 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4e700266-2b98-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 01:09:21 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id D4B245C47D8;
 Wed,  7 May 2025 23:07:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4150CC4CEE2;
 Wed,  7 May 2025 23:09: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" 
X-Inumbo-ID: 4e700266-2b98-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746659358;
	bh=if38SdnC0AJjNobF5sj+Z+diQFRQsDZaQWTmcM3J0z0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=bVUT35wFQvPLtu0LytwChJj8OCMGL50uKSUkAw/N299dum2gMqiUCpyl5S06wAMwP
	 LCEdm1qGVJNMvc0xia9kjE1XilBbXfDOpHCsU+MT0fvQXnKV30xtuGljLYyec6KmdU
	 oULJXb2Q7uBOQcET4vHAELvnYz0czULBYVtQ6q33A3B4HtESvwX2yIvtSGq/aN99sv
	 nupLajSjMLfm3Xb5VyTkcRwbKAkT+w97QNGWS/Nsk9lDPzNTbaXKMCQbpExRU3KOvb
	 aFIvTIa68tC4XysVp57S5ddzdoZm1eOBI+/yvxN/Snhy0o+j9u8OrcZTJ8DARIVDKk
	 8PdOrgh3+9ShA==
Date: Wed, 7 May 2025 16:09:15 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: John Ernberg 
cc: Stefano Stabellini , 
    Juergen Gross , 
    Oleksandr Tyshchenko , 
    Catalin Marinas , 
    Andrew Morton , 
    "xen-devel@lists.xenproject.org" , 
    "iommu@lists.linux.dev" , 
    "linux-kernel@vger.kernel.org" , 
    "imx@lists.linux.dev" , 
    Christoph Hellwig 
Subject: Re: [PATCH 2/2] xen: swiotlb: Implement map_resource callback
In-Reply-To: <75266eb7-66a4-4477-ae8a-cbd1ebbee8db@actia.se>
Message-ID: 
References: <20250502114043.1968976-1-john.ernberg@actia.se> <20250502114043.1968976-3-john.ernberg@actia.se>  <75266eb7-66a4-4477-ae8a-cbd1ebbee8db@actia.se>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 6 May 2025, John Ernberg wrote:
> Hi Stefano,
> 
> On 5/2/25 7:20 PM, Stefano Stabellini wrote:
> > +Christoph
> > 
> > On Fri, 2 May 2025, John Ernberg wrote:
> >> Needed by the eDMA v3 DMA engine found in iommu-less SoCs such as iMX8QXP
> >> to be able to perform DMA operations as a Xen Hardware Domain, which needs
> >> to be able to do DMA in MMIO space.
> 
> Self-note: The above part of the commit message is a disaster and should 
> read something like.
> 
> Needed by SoCs without an iommu (such as the iMX8QXP and it's eDMA v3 
> engine) that need to be able to perform DMA operations in MMIO space.
> 
> >>
> >> The callback implementation is basically the same as the one for direct
> >> mapping of resources, except this also takes into account Xen page
> >> mappings.
> >>
> >> There is nothing to do for unmap, just like with direct, so the unmap
> >> callback is not needed.
> >>
> >> Signed-off-by: John Ernberg 
> >>
> >> ---
> >>
> >> I originally exported dma_direct_map_resource() and used that which
> >> appeared to work, but it felt like not checking Xen page mappings wasn't
> >> fully correct and I went with this. But if dma_direct_map_resource() is
> >> the correct approach here then I can submit that isntead.
> >> ---
> >>   drivers/xen/swiotlb-xen.c | 15 +++++++++++++++
> >>   1 file changed, 15 insertions(+)
> >>
> >> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> >> index ef56a2500ed6..0f02fdd9128d 100644
> >> --- a/drivers/xen/swiotlb-xen.c
> >> +++ b/drivers/xen/swiotlb-xen.c
> >> @@ -285,6 +285,20 @@ static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
> >>                                           attrs, pool);
> >>   }
> >>
> >> +static dma_addr_t xen_swiotlb_map_resource(struct device *dev, phys_addr_t phys,
> >> +                                        size_t size, enum dma_data_direction dir,
> >> +                                        unsigned long attrs)
> >> +{
> >> +     dma_addr_t dev_addr = xen_phys_to_dma(dev, phys);
> > 
> > Yes, we need the xen_phys_to_dma call here. This is one of the reasons I
> > don't think we can use dma_direct_map_resource() to implement
> > map_resource
> > 
> > 
> >> +     BUG_ON(dir == DMA_NONE);
> >> +
> >> +     if (!dma_capable(dev, dev_addr, size, false))
> >> +             return DMA_MAPPING_ERROR;
> > 
> > But here you also need to check that phys+size doesn't cross a page
> > boundary. You need to call range_straddles_page_boundary, like we do at
> > the beginning of xen_swiotlb_map_page.
> > 
> > If it is possible to cross a page boundary, then we need to basically to
> > do the same thing here as we do in xen_swiotlb_map_page where we check
> > for:
> > 
> >          if (dma_capable(dev, dev_addr, size, true) &&
> >              !range_straddles_page_boundary(phys, size) &&
> >                  !xen_arch_need_swiotlb(dev, phys, dev_addr) &&
> >                  !is_swiotlb_force_bounce(dev))
> >                  goto done;
> > 
> > if all is well, we go with the native path, otherwise we bounce on
> > swiotlb-xen.
> > 
> 
> I'll preface this with that it's my first deep dive in DMA, so the 
> following may entirely be me being stupid:
> 
> I'm not sure a straddles page boundary path makes sense.
> 
> This mapping is not for a RAM backed address. In the eDMA case for the 
> iMX8QXP the `phys` coming in here is the address of a register.

Ok, this information is important :-)

I am not certain whether the map_resource interface can only be called
for MMIO addresses or if it can also be called for RAM-backed addresses
with a size > PAGE_SIZE. In the latter case, we could run into the issue
I was describing.


> I cannot see how a swiotlb bounce would fix anything if you end up
> straddling a page boundary. At most I can see a WARN_ON with a
> DMA_MAPPING_ERROR return if such a check would yield true.
> 
> Let's say you want to do a DEV_TO_MEM and a check decides you need to 
> bounce it you'd bounce an RX register address. I cannot see how that DMA 
> would ever end up doing the expected thing.
> 
> The eDMA engine will manage the RX/TX registers for an IP block and move 
> the data between them and RAM, where the RAM memory is mapped separately 
> by dma_map_page (and family). And these can be swiotlb bounced via the 
> map page callback with no problem.

OK thanks for the explanation. Like I wrote above, if we are guaranteed
that map_resource cannot be called for RAM-backed addresses or size is
less than PAGE_SIZE, then your patch is good as-is. If there are no such
guarantees, then we'll have to think a bit more about it.


From xen-devel-bounces@lists.xenproject.org Thu May 08 00:35:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 00:35:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978916.1365723 (Exim 4.92)
	(envelope-from )
	id 1uCpEZ-0001wH-7H; Thu, 08 May 2025 00:35:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978916.1365723; Thu, 08 May 2025 00:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCpEZ-0001wA-4a; Thu, 08 May 2025 00:35:31 +0000
Received: by outflank-mailman (input) for mailman id 978916;
 Thu, 08 May 2025 00:35:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCpEX-0001vz-IH
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 00:35:29 +0000
Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com
 [2607:f8b0:4864:20::112e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 550c9948-2ba4-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 02:35:25 +0200 (CEST)
Received: by mail-yw1-x112e.google.com with SMTP id
 00721157ae682-70a1f2eb39aso4392877b3.1; 
 Wed, 07 May 2025 17:35:25 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-708c4033a6bsm36684457b3.38.2025.05.07.17.35.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 07 May 2025 17: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" 
X-Inumbo-ID: 550c9948-2ba4-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746664524; x=1747269324; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=vqgILTBuNZ92MTaWUZUKoVUvNKIoUgitriayMBXxJnY=;
        b=MiCN96sNOB7CTVTWcG3ocgbRWzoOv9/IBhqp8J6vpAOmE725lgNrtNXBgA59psYWkn
         YMsdaDpE9L1M8vPbEexvHMnuUVYoGE6KkH4uuafBWednTtoC+7+LBhkxTaeL3O39pRJZ
         EUr12pMoPwDYKSu3Y8vw4oL5IcXCuDwesWHnb32uv1K7v0hERinVPcIQB47tVEhWrUhd
         XIWh4N2Yy4Kza7xDs3rUJ41v18IOTTa7tjoM+Fbf+zzc9um0IcVorLpoIP5v0AfcJoZf
         PWO1K7epUBq8/KYJPf+A9KoKI7HpYwoVMnVMjJEgStCZ2/nU9OD5dGGWQczV6BUq1y5E
         0JPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746664524; x=1747269324;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=vqgILTBuNZ92MTaWUZUKoVUvNKIoUgitriayMBXxJnY=;
        b=FIcFqxcNSdbhXUugQLo3nGpTiXwF3gkwPQ2EXMGdnqzyY2iWmpiATY/3KmdR3ydYSF
         7raMiKc3/6qd/aB0NEDrdmmxNT3fmqoV1OD/LoQtU/PfPV/2zhytSLMblrb+Cq0q1oRT
         n6OcYnsALLqTt0GqhdPMKmUBJYKyRTlEGLGo25OxGm1ZMZUOXIS0aMuUrIrzvYUzjmYN
         W1f51NdRicQct4XKYvTuPX22tkjwVWZ6UsqdYPXBI3/jfuq2UXCevhqu/padQNU2QwZW
         p5M3DzQRt7M/EfxN3yIUpYcTy5Wij9I9ITdgTx58KZSwsVIOvtmOW4OWYpS/zziv/MqF
         WH+A==
X-Forwarded-Encrypted: i=1; AJvYcCUL/LmDQIRPAVKcmsv0lnasgObA1m4BpwLGzGTdtKUbkdKERmD48doEDcUf1ZDdcPLQLQm2IFVxEkt9@lists.xenproject.org, AJvYcCUYmP3TWTowpQA7C3Wdj1sUax5skhZZgN5aX5tZDTA/32G0jSqaVv/PG6i94Z3PjLiZmlgUpuh1DZD5st2fji0RxA==@lists.xenproject.org
X-Gm-Message-State: AOJu0YzZarLymPMUbdreXXzh3oH6bZCKoFKVjezsn/GxWxPuze2Tp5ih
	OGKkngTfclxnFACL3ATstJwyIRa9gl4GscqbtSuOFOVkxYIMIo3r
X-Gm-Gg: ASbGncsh+bushfdULsBlkFsAYxeSQFUJAK9BgOP1bygF3nzvwCReDRH5I8vTOZ8T1vD
	kW7rT6UQE0Ow1b/lWiep0j4h050mCiWog9HV7UltZZu8QqZvTFz6IZueVGYn2TuHLHyASOCIL2z
	BVVKrpz6zaVW8C06TTm6CVmyf2Vk1nYZt5tl6FbaM9QxV6hqc62wY5rgVkn3f5iQjFZPjswGIPw
	hsUqJQn0iMI0BwzgmwVqr42roms4UKZUnodSGqlSzzzdiNBlulkBBSZt3L4h8Yx09kMj5uGSjZF
	oDn9MCLV1DqWF5t1Vud8ro85/W7hYutzh9Gogb6y0VYy
X-Google-Smtp-Source: AGHT+IH3h3kigEOWpW+U6B0wCUSlj2wXM5ya1FfxbQloy86LrwAZIv5/+vm72P3fiOWLnFeN+TOdXA==
X-Received: by 2002:a05:690c:6e04:b0:6fb:9280:5bf4 with SMTP id 00721157ae682-70a2d0b88c4mr25120117b3.30.1746664524281;
        Wed, 07 May 2025 17:35:24 -0700 (PDT)
Message-ID: <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
Date: Wed, 7 May 2025 20:36:07 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Alejandro Vallejo ,
 Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: Mapping memory into a domain
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------jZh02mgO1Sk5uXpK0bKp8M0b"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------jZh02mgO1Sk5uXpK0bKp8M0b
Content-Type: multipart/mixed; boundary="------------mTB0iSoy00QVuaogUq7f8rpG";
 protected-headers="v1"
From: Demi Marie Obenour 
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Alejandro Vallejo ,
 Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
Message-ID: <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
Subject: Re: Mapping memory into a domain
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
In-Reply-To: 
Autocrypt-Gossip: 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==

--------------mTB0iSoy00QVuaogUq7f8rpG
Content-Type: multipart/mixed; boundary="------------uiq0Y0n0wai0mPFTwLF4Oe06"

--------------uiq0Y0n0wai0mPFTwLF4Oe06
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/7/25 1:39 PM, Roger Pau Monn=C3=A9 wrote:
> On Tue, May 06, 2025 at 04:56:12PM -0400, Demi Marie Obenour wrote:
>> On 5/6/25 9:06 AM, Alejandro Vallejo wrote:
>>> On Tue May 6, 2025 at 3:02 AM CEST, Demi Marie Obenour wrote:
>>>> On 5/5/25 7:32 AM, Alejandro Vallejo wrote:
>>>>> I suppose this is still about multiplexing the GPU driver the way w=
e
>>>>> last discussed at Xen Summit?
>>>>>
>>>>> On Mon May 5, 2025 at 12:51 AM CEST, Demi Marie Obenour wrote:
>>>>>> What are the appropriate Xen internal functions for:
>>>>>>
>>>>>> 1. Turning a PFN into an MFN?
>>>>>> 2. Mapping an MFN into a guest?
>>>>>> 3. Unmapping that MFN from a guest?
>>>>>
>>>>> The p2m is the single source of truth about such mappings.
>>>>>
>>>>> This is all racy business. You want to keep the p2m lock for the fu=
ll
>>>>> duration of whatever operation you wish do, or you risk another CPU=

>>>>> taking it and pulling the rug under your feet at the most inconveni=
ent
>>>>> time.
>>>>>
>>>>> In general all this faff is hidden under way too many layers beneat=
h
>>>>> copy_{to,from}_guest(). Other p2m manipulation high-level construct=
s
>>>>> that might do interesting things worth looking at may be {map,unmap=
}_mmio_region()
>>>>>
>>>>> Note that not every pfn has an associated mfn. Not even every valid=
 pfn
>>>>> has necessarily an associated mfn (there's pod). And all of this is=

>>>>> volatile business in the presence of a baloon driver or vPCI placin=
g
>>>>> mmio windows over guest memory.
>>>>
>>>> Can I check that POD is not in use? =20
>>>
>>> Maybe, but now you're reaching exponential complexity considering eac=
h
>>> individual knob of the p2m into account.
>>>
>>>>
>>>>> In general anything up this alley would need a cohesive pair for
>>>>> map/unmap and a credible plan for concurrency and how it's all hand=
led
>>>>> in conjunction with other bits that touch the p2m.
>>>>
>>>> Is taking the p2m lock for the entire operation a reasonable approac=
h
>>>> for concurrency?  Will this cause too much lock contention?
>>>
>>> Maybe. It'd be fine for a page. Likely not so for several GiB if they=

>>> aren't already superpages.
>>>
>>>>
>>>>>> The first patch I am going to send with this information is a docu=
mentation
>>>>>> patch so that others do not need to figure this out for themselves=
=2E
>>>>>> I remember being unsure even after looking through the source code=
, which
>>>>>> is why I am asking here.
>>>>>
>>>>> That's not surprising. There's per-arch stuff, per-p2mtype stuff,
>>>>> per-guesttype stuff. Plus madness like on-demand memory. It's no wo=
nder
>>>>> such helpers don't exist and the general manipulations are hard to
>>>>> explain.
>>>>
>>>> Is this a task that is only suitable for someone who has several yea=
rs
>>>> experience working on Xen, or is it something that would make sense =
for
>>>> someone who is less experienced?
>>>
>>> The p2m is a very complex beast that integrates more features than I
>>> care to count. It requires a lot of prior knowledge. Whoever does it
>>> must know Xen fairly well in many configurations.
>>>
>>> The real problem is finding the right primitives that do what you wan=
t
>>> without overcomplicating everything else, preserving system security
>>> invariants and have benign (and ideally clear) edge cases.
>>>
>>> This was the last email you sent (I think?). Has any of the requireme=
nts
>>> changed in any direction?
>>>
>>>   https://lore.kernel.org/xen-devel/Z5794ysNE4KDkFuT@itl-email/
>>
>> Map and Revoke are still needed, with the same requirements as describ=
ed
>> in this email.  Steal and Return were needed for GPU shared virtual me=
mory,
>> but it has been decided to not support this with virtio-GPU, so these
>> primitives are no longer needed.
>>
>>> Something I'm missing there is how everything works without Xen. That=

>>> might help (me, at least) guage what could prove enough to support th=
e
>>> usecase. Are there sequence diagrams anywhere about how this whole th=
ing
>>> works without Xen? I vaguely remember you showing something last year=
 in
>>> Xen Summit in the design session, but my memory isn't that good :)
>=20
> Hello,
>=20
> Sorry, possibly replying a bit out of context here.
>=20
> Since I will mention this in several places: p2m is the second stage
> page-tables used by Xen for PVH and HVM guests.  A p2m violation is
> the equivalent of a page-fault for guest p2m accesses.
>=20
>> A Linux driver that needs access to userspace memory
>> pages can get it in two different ways:
>>
>> 1. It can pin the pages using the pin_user_pages family of APIs.
>>    If these functions succeed, the driver is guaranteed to be able
>>    to access the pages until it unpins them.  However, this also
>>    means that the pages cannot be paged out or migrated.  Furthermore,=

>>    file-backed pages cannot be safely pinned, and pinning GPU memory
>>    isn=E2=80=99t supported.  (At a minimum, it would prevent the pages=
 from
>>    migrating from system RAM to VRAM, so all access by a dGPU would
>>    cross the PCIe bus, which would be very slow.)
>=20
> From a Xen p2m this is all fine - Xen will never remove pages from the
> p2m unless it's requested to.  So the pining, while needed on the Linux=

> side, doesn't need to be propagated to Xen I would think.

If pinning were enough things would be simple, but sadly it=E2=80=99s not=
=2E

>> 2. It can grab the *current* location of the pages and register an
>>    MMU notifier.  This works for GPU memory and file-backed memory.
>>    However, when the invalidate_range function of this callback, the
>>    driver *must* stop all further accesses to the pages.
>>
>>    The invalidate_range callback is not allowed to block for a long
>>    period of time.  My understanding is that things like dirty page
>>    writeback are blocked while the callback is in progress.  My
>>    understanding is also that the callback is not allowed to fail.
>>    I believe it can return a retryable error but I don=E2=80=99t think=
 that
>>    it is allowed to keep failing forever.
>>
>>    Linux=E2=80=99s grant table driver actually had a bug in this area,=
 which
>>    led to deadlocks.  I fixed that a while back.
>>
>> KVM implements the second option: it maps pages into the stage-2
>> page tables (or shadow page tables, if that is chosen) and unmaps
>> them when the invalidate_range callback is called.
>=20
> I assume this map and unmap is done by the host as a result of some
> guest action?

Unmapping can happen at any time for any or no reason.  Semantically,
it would be correct to only map the pages in response to a p2m violation,=

but for performance it might be better to map the pages eagerly instead.

>> Furthermore,
>> if a page fault happens while the page is unmapped, KVM will try
>> to bring the pages back into memory so the guest can access it.
>=20
> You could likely handle this in Xen in the following way:
>=20
>  - A device model will get p2m violations forwarded, as it's the same
>    model that's used to handle emulation of device MMIO.  You will
>    need to register an ioreq server to request those faults to be
>    forwarded, I think the hardware domain kernel will handle those?
>=20
>  - Allow ioreqs to signal to Xen that a guest operation must be
>    retried.  IOW: resume guest execution without advancing the IP.
>=20
> I think this last bit is the one that will require changes to Xen, so
> that you can add a type of ioreq reply that implies a retry from the
> guest context.
I=E2=80=99m not actually sure if this is needed, though it would be nice.=
  It
might be possible for Xen to instead emulate the current instruction and
continue, with the ioreq server just returning the current value of the
pages.  What I=E2=80=99m more concerned about is being able to provide a =
page
into the p2m so that the *next* access doesn=E2=80=99t fault, and being a=
ble
to remove that page from the p2m so that the next access *does* fault.

Are there any hypercalls that can be used for these operations right
now?  If not, which Xen functions would one use to implement them?
Some notes:

- The p2m might need to be made to point to a PCI BAR or system RAM.
  The guest kernel and host userspace don=E2=80=99t know which, and in an=
y
  case don=E2=80=99t need to care.  The host kernel knows, but I don=E2=80=
=99t know
  if the information is exposed to the Xen driver.

- If the p2m needs to point to system RAM, the RAM will be memory
  that belongs to the backend.

- If the p2m needs to point to a PCI BAR, it will initially need
  to point to a real PCI device that is owned by the backend.

- The switch from =E2=80=9Cemulated MMIO=E2=80=9D to =E2=80=9CMMIO or rea=
l RAM=E2=80=9D needs to
  be atomic from the guest=E2=80=99s perspective.

>> For GPU acceleration via virtio-GPU native contexts to work,
>> the Xen interface driver needs to do the same thing with GPU
>> buffers that KVM does: it needs to fault the pages into guest
>> memory on-demand and revoke access to the pages when the host
>> kernel demands them back.  There really is no alternative that
>> I am aware of.  The need to handle guest page faults doesn=E2=80=99t
>> come from the host kernel, but rather from guest userspace.
>=20
> I'm a bit confused with this last sentence, the "page faults"
> mentioned here are p2m violations I think?

Yes, they are.

> Hope this makes some sense.

It does.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------uiq0Y0n0wai0mPFTwLF4Oe06
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------uiq0Y0n0wai0mPFTwLF4Oe06--

--------------mTB0iSoy00QVuaogUq7f8rpG--

--------------jZh02mgO1Sk5uXpK0bKp8M0b
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgb/HgACgkQszaHOrMp
8lNQRw//TrqI0F97k8eSHn1as5K2nA9oRLwmhDU9/zNCaZ+83kg4wylx159RWV2W
uvqAxOeGiCmRVF8/pqxu+KBnslDo434mtPDE5x55cyJVkCUtfcMRHZNdgKw6BZ+Z
/s82wDPqDUgvkdDCKGGOs+MVvC2IPdsms2ZRfSG60KIeEG15q8wKMxLqUOS4bIkw
xkAo6B2EaUYrVWhLMvgIzByxDdDb9flcvnrNT+vNMl4wqAouGm3PlfObqBOGqRAU
aA3pYraXuFC/SDLYpKsnE4BA8uZO6kD/4uU8GJ2bEFaN5+zGbaW9LrZ2I3ryHCby
03VU8+7EcSjF0X6xmlnvWrL1XWSnrm1JyIjoONf45a0Z6/ieOtjLA5FRABm/kd3K
WNZWjzOorDNJ9jl5IkeVd+roA1FVNDsALP2DoB2/d84zcD3Zwh2M/CrcT/mqMdOG
ol629RXkUtC7mUWu/UQ0jXNqka4ewJkcnOFoKBYiH/dV1z7tX/TvjKya3Tes2YVR
IkC0qsWMVTWMajvqvACieLTY1qQzT6ElGlZusZwsx6lLgpP7TTcREu9XFyH0QS08
c+y6Uvgq83L91Eyr7Uy3PDeDqcQdijJEPG4GL6qKN4FaVu/P7e8CGKcxKj4fXPyW
PdwA0yAqosvBVWN7riZLK/1EMA4a7g8mDA6XTd+1VYxPm4AEUDs=
=Otnn
-----END PGP SIGNATURE-----

--------------jZh02mgO1Sk5uXpK0bKp8M0b--


From xen-devel-bounces@lists.xenproject.org Thu May 08 04:15:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 04:15:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978967.1365733 (Exim 4.92)
	(envelope-from )
	id 1uCsel-0003U3-R5; Thu, 08 May 2025 04:14:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978967.1365733; Thu, 08 May 2025 04:14: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 1uCsel-0003Tw-OT; Thu, 08 May 2025 04:14:47 +0000
Received: by outflank-mailman (input) for mailman id 978967;
 Thu, 08 May 2025 04:14:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCsej-0003Tm-C0
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 04:14:46 +0000
Received: from bombadil.infradead.org (bombadil.infradead.org
 [2607:7c80:54:3::133])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f7246e4c-2bc2-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 06:14:43 +0200 (CEST)
Received: from hch by bombadil.infradead.org with local (Exim 4.98.2 #2 (Red
 Hat Linux)) id 1uCsea-0000000HGrC-1ecu;
 Thu, 08 May 2025 04:14: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" 
X-Inumbo-ID: f7246e4c-2bc2-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version
	:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=41y5a2fmLpkUVnjUrs+3spKKdWGJe+CFaj83hBx9tto=; b=il6E3u2hODnTYTdHGLvese8c4k
	moZHoVqHVx9Mv3WchvyW0oJ9k2NMXgY+5X9tjKFn7cA9vt21hz7oDJW7uw+PrrxehnVWvrK004O68
	bJ4+p3xV5IPwiv3dGKLczXIM4GPVqkBYvjUScsbDBcGBHg2oLTcs4N2xDXtIq+ZSSmkv4h+jE8Gmb
	cqrLDED7/LnE4h9Yt8IilMzCzlDps8RAVHzWoTPO/AzxKfR4dp8rS2f6w6zOEZ2tYNjGBarV+gnyl
	oCaJvmyAKhjtT+SuVOPqH3ZLM1fJ5Mt2yysevzIoCkfDmMs3PpP69DckYB5Sw/pwLSyRNMQHPpcyW
	OWLzkU0A==;
Date: Wed, 7 May 2025 21:14:36 -0700
From: Christoph Hellwig 
To: Stefano Stabellini 
Cc: John Ernberg , Juergen Gross ,
	Oleksandr Tyshchenko ,
	Catalin Marinas ,
	Andrew Morton ,
	"xen-devel@lists.xenproject.org" ,
	"iommu@lists.linux.dev" ,
	"linux-kernel@vger.kernel.org" ,
	"imx@lists.linux.dev" ,
	Christoph Hellwig 
Subject: Re: [PATCH 2/2] xen: swiotlb: Implement map_resource callback
Message-ID: 
References: <20250502114043.1968976-1-john.ernberg@actia.se>
 <20250502114043.1968976-3-john.ernberg@actia.se>
 
 <75266eb7-66a4-4477-ae8a-cbd1ebbee8db@actia.se>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-SRS-Rewrite: SMTP reverse-path rewritten from  by bombadil.infradead.org. See http://www.infradead.org/rpr.html

On Wed, May 07, 2025 at 04:09:15PM -0700, Stefano Stabellini wrote:
> > This mapping is not for a RAM backed address. In the eDMA case for the 
> > iMX8QXP the `phys` coming in here is the address of a register.
> 
> Ok, this information is important :-)
> 
> I am not certain whether the map_resource interface can only be called
> for MMIO addresses or if it can also be called for RAM-backed addresses
> with a size > PAGE_SIZE. In the latter case, we could run into the issue
> I was describing.

map_resource is intended for MMIO regions, although those could be >
PAGE_SIZE.  It must not be called on RAM.



From xen-devel-bounces@lists.xenproject.org Thu May 08 06:20:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 06:20:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.978991.1365742 (Exim 4.92)
	(envelope-from )
	id 1uCucO-0002zc-B5; Thu, 08 May 2025 06:20:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 978991.1365742; Thu, 08 May 2025 06: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 1uCucO-0002zV-8W; Thu, 08 May 2025 06:20:28 +0000
Received: by outflank-mailman (input) for mailman id 978991;
 Thu, 08 May 2025 06:20:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCucM-0002zO-GW
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 06:20:26 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 86ca7521-2bd4-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 08:20:24 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43cec5cd73bso3397015e9.3
 for ; Wed, 07 May 2025 23:20:24 -0700 (PDT)
Received: from localhost ([196.207.164.177])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442cd331281sm24790075e9.15.2025.05.07.23.20.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 07 May 2025 23: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" 
X-Inumbo-ID: 86ca7521-2bd4-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1746685224; x=1747290024; darn=lists.xenproject.org;
        h=content-disposition:mime-version:message-id:subject:cc:to:from:date
         :from:to:cc:subject:date:message-id:reply-to;
        bh=erP9N5irA1Qn4rtwySzPgfrOs/l9lOODRxSitTYyXXo=;
        b=JqX73l3xnz4P6NrflpsMfeYmitFmcTHx8cuMiczgNkIdoVFlTPasrGmvo7KSnpOOv3
         nnGeOq//Mo0GMYvj6iU9FalUQNtWqwqmRJDuvVv5UBebRoejLSfQyoxzt7+tIne8K6Nw
         TG/XZDFKNlKJJcl16inbKIB7AkUCc0bi+7WBA2ouoilKExKQsndHHDPY1EfuDwjHyQkJ
         u9rIAALAnuu2gxHIXyIFYx/5DfFVuFu6GTE0C3iIFWasqqbs9NQzgcHk4rwbeUgIiwvx
         O8BbLRE8aFlZTKn1UQYZuorezY2s18nDtFF72adVMGhPk7YqAK7RDO/EYbIvJUlyoo7H
         Wl8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746685224; x=1747290024;
        h=content-disposition:mime-version:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=erP9N5irA1Qn4rtwySzPgfrOs/l9lOODRxSitTYyXXo=;
        b=QtGFYPSUT+lHx4naSLFG6apOWLHWfCN7zqtxj92LYxij94IbCGhQq0k4U5cQ6w4BVG
         wKvZRDOwcRJcNozQPSRqbmBsWjeTPmILQamV1OidSx/84cUnVzOc60i2T/nIy2+Z/8Z6
         FcSQ6v+sB6enuWCO3qHzWeIS2zMN0tzKCINcxHGYlqjam5UDmkYsiPR7grfkWlBfhjo6
         VR/3DSPW3RoSddyZBHpiu/6HF4fYRJ/0H32k8oZ5t1vQxtsEep0E0b0W43CzHhTV3wV+
         DNdcVJQMHJ+8ixIF3VbXFOUe1VkjTMBBivYJ2pI/Esecgw+PLLL+toWIvfNFP2XSBmOG
         cSDQ==
X-Gm-Message-State: AOJu0Ywh59Jr6LKEsSKKzZx4DHLD8vPCHl12Vlzg0pZorl3epYB6Ta2D
	MAd/ij3DDruh7RsAMgi49uXNAhb1tWpLjG7Nw/F5ExvyKBAgjlyh2Zs3gS56Tbvo5xNrkUBlGI4
	8
X-Gm-Gg: ASbGnct0Jc72/g5r9vhZB6XyDHW6OMdNmiXRp9L1So0dcA1Ys/ibW9ZyTHDu8I1Ao42
	9FE+h7tRB+SKhj6kv8oxaDr0v99FzE8YCM3VU4j97dOyUiUW80b5l1bPsqSK1AafhHDhgf/wodg
	OsDB0Xr7XUeZ/GuiBsVhWYJaumP1OA9hrWFqf34PoThtBebGVZpT6Yll2e7tKSDJQzPMyU0iT9F
	U9hOVvF62oMw5frJeLDrtqOh6v4kJbgVkdvTQEKAvKcxTUOfVy3CJPKHx2eyKdBzlzCy6ylVEs/
	IpnJRsyENzVpQX7AY2Am6IofuKtAmNSSy79sB89FD4kiLg==
X-Google-Smtp-Source: AGHT+IHo8NnLYyInT7/v8s7jzqlUhT5bNQvADa53LAavwKI6cC2BBKGtm3E5BcvLUbGxeJwnQ4G6SA==
X-Received: by 2002:a05:600c:3b11:b0:43d:526:e0ce with SMTP id 5b1f17b1804b1-442d095337emr12392365e9.21.1746685223859;
        Wed, 07 May 2025 23:20:23 -0700 (PDT)
Date: Thu, 8 May 2025 09:20:19 +0300
From: Dan Carpenter 
To: Xin Li 
Cc: xen-devel@lists.xenproject.org
Subject: [bug report] x86/xen/msr: Remove calling
 native_{read,write}_msr{,_safe}() in pmu_msr_{read,write}()
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello Xin Li (Intel),

Commit 0cb6f4128a7d ("x86/xen/msr: Remove calling
native_{read,write}_msr{,_safe}() in pmu_msr_{read,write}()") from
Apr 27, 2025 (linux-next), leads to the following Smatch static
checker warning:

	arch/x86/xen/enlighten_pv.c:1168 xen_read_msr_safe()
	error: uninitialized symbol 'err'.

arch/x86/xen/enlighten_pv.c
    1163 static int xen_read_msr_safe(u32 msr, u64 *val)
    1164 {
    1165         int err;
    1166 
    1167         *val = xen_do_read_msr(msr, &err);
                                              ^^^
The first return in xen_do_read_msr() doesn't set *err.

--> 1168         return err;
    1169 }

regards,
dan carpenter


From xen-devel-bounces@lists.xenproject.org Thu May 08 06:57:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 06:57:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979014.1365754 (Exim 4.92)
	(envelope-from )
	id 1uCvBv-0007Zw-0J; Thu, 08 May 2025 06:57:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979014.1365754; Thu, 08 May 2025 06: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 1uCvBu-0007Zp-S9; Thu, 08 May 2025 06:57:10 +0000
Received: by outflank-mailman (input) for mailman id 979014;
 Thu, 08 May 2025 06:57:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCvBt-0007Yw-Kk
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 06:57:09 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20627.outbound.protection.outlook.com
 [2a01:111:f403:2009::627])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a7b5a440-2bd9-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 08:57:07 +0200 (CEST)
Received: from DM4PR12MB5277.namprd12.prod.outlook.com (2603:10b6:5:390::7) by
 BL4PR12MB9506.namprd12.prod.outlook.com (2603:10b6:208:590::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.20; Thu, 8 May
 2025 06:57:03 +0000
Received: from DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e]) by DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e%3]) with mapi id 15.20.8699.026; Thu, 8 May 2025
 06:57:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a7b5a440-2bd9-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xeespZwsHXly5dvdO5PYQLOKT6iVfQ5ua2XQ4NVOppXGSUEZK3CHdOF06zzDBAvA+rtOnvR9OfEecHA4YRejJqc8ieds9A1DY26lYpvN7F/0I1MO9cDFabJNP/xSpj57qX3ZQVjaD7Z1t0FRF80Cb4rURAzZjhQqnR94aDF8g+S0gbfwHW97ykPDaIT6SnixuL8XBEN538S0wTIgopHOrcGDpoCsth8hqdt6LxdXlyqVBC/Du3bxLhsU/np2eXDcvV6IVhDRL6+agKP22JLw0zV3qgp3bdUo/tYSGQOlJyAvDEbmczLbnbmjRXeW52PQz0aAZlqngn2Ox18TOY+hWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+fkPwAMOp4RrlCimDfX482BQVD3/fdFEG27YxMCYuPc=;
 b=QBTtJbRh4+NyE5Bvu+GolnvS4KkHOcjp42X+7VKf9jX7MbO+npM+ylK1pNxJbXoA/8QuOx6vamWy4y54kC/nDB1Kqgp7LEl4TNqs3CZwzy9TzGi3d9UXKCHOSqbWPb6MBwCltrZS1JxBX9n1cdYk8dlKjy7Jr00RdL1aiOjk2xtqy9FRUTqyaOgUcSl1+Jxc6/gZEo4fhdqFNFw5nCnPyLdfT2dLqmIhGnJdJUNmfD3kQJhr/WXGqslAiOYCiHN0JBVWP3Hb/k/6fA7V6URLlPdupx0pN1PEWGBU7qdzvpQw1Gmuu2ns4/OGvjtT2Afv9NNR+xp9kd1ZYAW8xfcXFg==
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=+fkPwAMOp4RrlCimDfX482BQVD3/fdFEG27YxMCYuPc=;
 b=qkPS3WCBjI1R3HgDSfpBfLy2cAfkEZECdlEp3xtZDg4xny5fvkfwiEaHEZB3fOs/02csePXBShAznPgYtCuYVeq0tIiAPPF6luxBHlTAR98EI1MymvYjfGrSwp3Dd7fu5dXXsdN3JCcclpNlZi9sw0DTKwZAQtkf1oL+hi/gnX4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <7ad1dde2-0af3-4a8c-a67e-3eafdea5822f@amd.com>
Date: Thu, 8 May 2025 08:56:59 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] xen/arm: fix math in add_hwdom_free_regions
From: "Orzel, Michal" 
To: Stewart Hildebrand ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250505025631.207529-1-stewart.hildebrand@amd.com>
 <20250505025631.207529-3-stewart.hildebrand@amd.com>
 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0027.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:c9::8) To DM4PR12MB5277.namprd12.prod.outlook.com
 (2603:10b6:5:390::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR12MB5277:EE_|BL4PR12MB9506:EE_
X-MS-Office365-Filtering-Correlation-Id: a419b740-61a2-4de6-d33a-08dd8dfd8988
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RExqeG1GanFpL2x0cTZ4dW1ZekVkTzFablZlWjlQUjRmOG1LY0h0d1k4azM1?=
 =?utf-8?B?dFNZQm1vbVZMVk5mRStQWUNmTy9BdW8yNEFpOElBZEpPOXBUakNNbXZrcFVJ?=
 =?utf-8?B?Z3VCbTJvNUs5WktyUUc4QnF3QTVRYXd1YnJiWFRabGNwdkN4enpjNmFrTkFM?=
 =?utf-8?B?Ry9VQ1dpcXZRaEJudU9HcFN4S216OEhHSTJGOTVMOC9hY0N4MHpkVnVjR2cx?=
 =?utf-8?B?Nmg3b1hzb1hob0Ftbnk3RTFZYjNHK0RrcWJURk52czhVYjVGZ0VEK3VDU0I1?=
 =?utf-8?B?WkFjeDBXZms3L0VBZStNeCtCejM0bUIySWVjRkZFM3l1V3A2TjRXQ1RqdVhk?=
 =?utf-8?B?SkZMM3Roc3lUYTdSdUdvSzNFMUppcFpIRkFXYzRkUndxVytnSE1UcDNIWnhi?=
 =?utf-8?B?RXZjTmJMTnFwSzJCbndJVEdPSm93U04wUGYxbSttUDI1WTVCY1hRNkhUMW5X?=
 =?utf-8?B?NnpxMEpJTExFYllMN3Y3amdZMDc4bVJDcUVqMCtpVEZ0NTJwYU9Ma0E4SlpR?=
 =?utf-8?B?TWxaYzdWckNiRllkOXI0VDBhLzZrbGJrU3hlcnBxbmVRSkdJRmNBRTI1OHNQ?=
 =?utf-8?B?ZFl3N2cyYlhVc1NYNGs0bVBYNmFncUFiUVViRUF3c1pYK2RIRHhGZDk2ZUhW?=
 =?utf-8?B?UWRpU1ZyL2JjY0U2U3gvZlY4T1p4RkR6bDBJOWw2UTF0UVVNNnlsSThjajBN?=
 =?utf-8?B?Vk81Y3UzVnEwclM0b2s2Z3A3Vm5KTVBjcFF4R1dnaTJ6ZU9tVjRjaWl6WGl3?=
 =?utf-8?B?M3dJY0RLS1lMU2FiTCtoRFBib1U0SHcyRmF0dzR6U09LRmR6NmtRRnBYQTFl?=
 =?utf-8?B?UFRLbWpkSkNsUm5vbFcxdFh5UnM3cHhGNVZzY0NWRVRYZHRRcTlXQUU2cmxH?=
 =?utf-8?B?dHVtNWYzcXNmVU9rY0hncmxSeUtST21wNmN1ZDVlMk5Dd1ZGTjhBTlMyRm9t?=
 =?utf-8?B?VVIwTHQ2MFJtT1dpNGR5QmRROTNrbjhoZXI5dS9jbkcyK2U5MW5rUW1zby9l?=
 =?utf-8?B?eTZzZE9Mb3dsc0dwb3hoM3dQVWo0VXMwdHBndTFGT0NqTU5POFoyVXVtQ0Nm?=
 =?utf-8?B?ZVVZcU5NSlhjU2ZqRXI0VEdFaWFQa1JuUWwwazNWVkNTdVUvbTJvcUlRUlhn?=
 =?utf-8?B?ZjlSZzNuaGhicldqKzVYUVd1Q0hPTnAxWFl4YXgxSlllN0JsYmtjZ0JaNmFp?=
 =?utf-8?B?M010dHdpVEFQRjN2N3Jhc3YwTnZ4eFVKMGpKRjZaN0RkOC9YVjUyayt1NnFu?=
 =?utf-8?B?dTJoRG50NHd4c3R5S3oyaDJzQUNiYzZxY3RSaTcxV05PYXQ1M1Z5NXdLcEhV?=
 =?utf-8?B?dWFvaGtiM2pJb3hSM2tqUjJabjNwSjdPa2F1dXczTk5jTzgyZ3ovcWlJQUlY?=
 =?utf-8?B?ZTVQdkhZRi82end4amFBMzd2VlEzVGduSlZoQmZtYVZ3MExzQXJSTkJFUG1B?=
 =?utf-8?B?c3I5SlBON1lyMlIyTTNObUVsVEluR0NVMVNSSVJ6NDY1ZmNybUpVYjduVHNW?=
 =?utf-8?B?S05hMlNFeUxUVUgvT2kwT2dkcDlKMlBiMVRRZ2NNQVZtUFJ4cDVtTWpZZXBs?=
 =?utf-8?B?RkhER09xMGpFV3pyQUdqMlZRc3JWeWI5YlpBTFBvOTVaWlNGaXBhNlNVaTZV?=
 =?utf-8?B?d0dNdVE2SkZDalBPYkpKdUtzb2RHNDYzRVI5NnhHQkdLMVp4aFFnb081Qjdn?=
 =?utf-8?B?R0YwTXI0TXFYQUkwTzk3bm9GT2xlN0d6TFFSUHVLNis3UWF2OHBCek84dmxq?=
 =?utf-8?B?K3JhL0VTRDcydkFGeGVSa2FaRGt1VlY3SmlpNVVIR1FoRnZvdWJEdTZPYk01?=
 =?utf-8?B?NTZrMDJ0VGthVGJ4QTdCTlk1bjhqMUFidWhTSEFwYittMk1lcWpKQzI2dVg1?=
 =?utf-8?B?VVJweVB0aU5SM0U4VVJldkZqdlBKTHB5SHhYb0hEVFIzS0Mvb2NhTEdBdFRk?=
 =?utf-8?Q?xh7v+iqP84Q=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5277.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?RWlsemNrejFKRmRGdjVOZjR3dFFNa3czamRPem9MOEpIV2dGMEdSWTcwY3BQ?=
 =?utf-8?B?cXNOZWFRYndzV3VKaUtCM0JUdTAwOU5kbU4wcGR3cTZBaEVlUzlEYlRyaDk2?=
 =?utf-8?B?SmNkYlpIaXZoTTZ3c1RQUHNrU21WK21VMVBVVnd2OXc4TGI0NmJZcHVLNUVz?=
 =?utf-8?B?MHRHd1V5NDhsY25mZHNmVUhCU3JwYk9qRk04Vk1FVWNrZk5QaTZld3k5MlZM?=
 =?utf-8?B?NXpyN1ZVUU40V0J1ZWpFc011ZFNHOVlwNldKV1hHQ21IRHBSVTQ0bjVZZ0FO?=
 =?utf-8?B?aXBZUVhtWmlTc3d1Zlh6MlBMY1BPYy9CTmZJZmZXRzViSFNwK2VPTUhpMTRO?=
 =?utf-8?B?OS9HVW5iOWNQVDhmYkQxbnFqcVhPYnprRE5LRlc0WEh3eE84eE5xb05nbWd6?=
 =?utf-8?B?NWpmNjdKTnEyeUR3QkYwZkd3N0N2OUpadWVIWG9GRDVLaytJRld2eEV6NWQ3?=
 =?utf-8?B?ZisrbEp0SzV2TDl4bHA0bG14cHc0YXBEOFRURXBvUVFqcXd0RzE5YWJ1RjY3?=
 =?utf-8?B?aUJYY1pUK2phajY2MExDZER1S0g3U2JiSElzQ3pSS1gzYVhCM2xrcGFrZzV2?=
 =?utf-8?B?REphVG12c3NTNTdMZUFEMUsvMWhPZG90MTl1SE52a2t6VDY3cjJnMithaEZ0?=
 =?utf-8?B?ZEpqNFpwYUVhaWw4WTRpZyttWDJrM2V1dUJ3L0NoaW9rMk1ML21sNzlHRmZP?=
 =?utf-8?B?TnNZZkVaUlV5VCswUmRWNFFsWWhBcnV0MVo4YUhteVVQMlRkV1A0SkFnYlNz?=
 =?utf-8?B?alBYdzJqa3NTbGQvMHNtQjVneHhCSU9rbjFyNXJaMW9tTzRkdWhhWVpLd2p4?=
 =?utf-8?B?UU5Xcm8yZjdvYlB4ZElUNElzSlZnSEdoOExsL3pLYmpGTlVJSmlOZzVoSlIv?=
 =?utf-8?B?MEE2R0F4SlhSQ0VMbjhYajlud0ljeFpVZjNXT3ovSDJYWjBodmY2M016N2xV?=
 =?utf-8?B?RkN0eDRSaHZ2bmkrN0dPSVdSOXhKT20xYnI4YmlxaXg5YmtIbWdhc01aa3RP?=
 =?utf-8?B?cHlySS83NHkwSWVFTVU5azB0LytJV1Rob1BUQXNDYS9rMUlBWTE5Wnh4NkVw?=
 =?utf-8?B?N09OVzhlUkd2TFpuMzRZYzhKZkZCRDFqTVlIK0ViVXZ3M2JsempNZUZ3a0hI?=
 =?utf-8?B?OFYvK0xSejVtdnh5RTViWmUvc0NVbDM2eXJERDZsdXpLaW1zSU91NFo1WUNU?=
 =?utf-8?B?Y2FHcG5iTE55aTNUYjJONXM0MUpDNk10RURJK2pMdFpWZGU3cFJDbS92ZkJo?=
 =?utf-8?B?dXhudjhkUmxPT3pHdnh5UnFwOWJTZEd6Y1A4NFhseWtpWlB6dzVkMWVrWEl4?=
 =?utf-8?B?TTN5YjlPQmZZZSs1VFFRV0NLRUU4MVJVeFZMV1BZZ0t1MDgyWnZ1ZWhLTWRZ?=
 =?utf-8?B?ZFpoOG9Ed0h0WEhyU2hWa1N0Y091ZytmcXdXQkxva1luWkhYbE1kaXBienBq?=
 =?utf-8?B?SUsrR1hrSEdWMlZEWnZNNi8wVkVNTnF4eFQxU2FaYzhzLzl0YkRrNzFnV2NS?=
 =?utf-8?B?TXBpV3RWcXQxMEhNSjNteWl6b0hlNDZac21YQzNuVmhPL1piaC8zYkhjclhE?=
 =?utf-8?B?WUpySTN3TUVzY3ZVaWFHOFNaODJhVHZUMzRXbnA0RDBqN0pWTVlmdk9TMXg4?=
 =?utf-8?B?aEhtM1RKWlUxMDJaR011NUJPQ1paV3lnTDUxVVYzTXV3SWpQdFlCUGl1M3RP?=
 =?utf-8?B?QU5zOFFHUFRvTDFqWFVRVWt3dEd0K25xTys1MHdRemYybkEySS9FT3o5eTJi?=
 =?utf-8?B?L1VMeVFzbjVhRGtGWFczZ003Tk8zMzRGT2VUekZ0bE9GMWJZNVJBVDkzNVNZ?=
 =?utf-8?B?T2M3dFc0SEMzcVFIQ3VFcStUVTJHbVBtdlZLUmk5dldBakRZZ3dLbnVhdGYx?=
 =?utf-8?B?aVVSVHNya1lIN2wwbmo2L09uVzlkbERTTEFNQk5zT2VjemtwOXVXK0JmMTV1?=
 =?utf-8?B?eFcrRDBRYjNkcDBrdFcrMUc3WnRyN284OVI2cjV3WnpLdDJoejh5UWVTK1BC?=
 =?utf-8?B?Y0dMMFpvL29PczIrODl6eGs1M3dwMUVrUyt0UExjd1Iveit5bE16S2RuWlNa?=
 =?utf-8?B?b3ZDNDZVeDRyNGtYbGRRYnNyVjZIai9BT2lEYkZoc2I1MVdIK0lKQldkT0Rk?=
 =?utf-8?Q?h7aK+Va3lZxyilGCZ9UvRQ6oc?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a419b740-61a2-4de6-d33a-08dd8dfd8988
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5277.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 06:57:03.2745
 (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: 1YCLiueqXu4YyleddC96eBD48cJwKYvTmPRnEwzaYt+4k6L8mjCKQdHcp/wu2IWI
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR12MB9506



On 05/05/2025 09:52, Orzel, Michal wrote:
> 
> 
> On 05/05/2025 04:56, Stewart Hildebrand wrote:
>> Erroneous logic was duplicated from add_ext_regions() into
>> add_hwdom_free_regions(). Frame numbers are converted to addresses, but
>> the end address (e) is rounded down to page size alignment. The logic to
>> calculate the size assumes e points to the last address, not page,
>> effectively leading to the region size being erroneously calculated to
>> be 2M smaller than the actual size of the region.
>>
>> Fix by adding 1 to the frame number before converting back to address.
>>
>> Fixes: 02975cc38389 ("xen/arm: permit non direct-mapped Dom0 construction")
>> Signed-off-by: Stewart Hildebrand 
> Acked-by: Michal Orzel 

I wanted to commit your fixes but rebase is required after recent dom0less code
movement. Please do.

~Michal



From xen-devel-bounces@lists.xenproject.org Thu May 08 07:53:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 07:53:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979034.1365763 (Exim 4.92)
	(envelope-from )
	id 1uCw3m-0006zq-SI; Thu, 08 May 2025 07:52:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979034.1365763; Thu, 08 May 2025 07: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 1uCw3m-0006zj-OG; Thu, 08 May 2025 07:52:50 +0000
Received: by outflank-mailman (input) for mailman id 979034;
 Thu, 08 May 2025 07:52:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCw3l-0006zc-N7
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 07:52:49 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6f75b134-2be1-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 09:52:48 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43cfe63c592so6093335e9.2
 for ; Thu, 08 May 2025 00:52:48 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442cd38179csm27202985e9.39.2025.05.08.00.52.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 08 May 2025 00:52: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" 
X-Inumbo-ID: 6f75b134-2be1-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746690768; x=1747295568; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=f3PrLJDUYUU3YfJ9W2ToLgnF6ou64u7VpIA85WA5OSo=;
        b=LkW3dooyNNxkd4T7bopthrKm7f2IaQRFg4FxnZEr1aB+Rz8ga2VfP7ysaf8b+5yfr1
         0L9LkL/uaFy+/4CSbn58nB3q7AfoBpghp7Vr3zOP2n/zW0Z8dN+gjS7OHKwEE5rmDnqK
         eeHqF9kWjuOzPw7JNnLFxjTHJqFJZLYBBLtuI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746690768; x=1747295568;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=f3PrLJDUYUU3YfJ9W2ToLgnF6ou64u7VpIA85WA5OSo=;
        b=b/rckqBy95/mfhOMjeTF3PGNbfngd+7xAModPAhUwu6ig7hvq8yUhuktAR3aaJ/Yum
         b1krpxXlfoiB9D9j/d94AYHzN+8oeM8EMJ8XEh9Xxw3AsIDkbtxCE57KtE8Rn90hsQXd
         cSwI9P4Yp34ck8Qi839ktWZf1FU7qcAJQaj6dcWhSzq0OgNySMgyEDzu2jTPOn6qBBm8
         lX+eol777Km2EkE0YQkFx9gnfuYN4dHHVQoQHLvn2p9sJtX2A9N4btF5w4FM7CCUZcub
         Xg8iGdpO3PfvxTEdGNS46DU/+vb02WekxCmtpb9y7utVnfYX9D58xNdSMkhcqnb5j/5w
         Gjig==
X-Forwarded-Encrypted: i=1; AJvYcCWrIHWY1As+J+jeObT1NVLzaYRzOHdB4gf2573jrfSdJW3l1XRe9VLQunwl+DYpkJncYRWBLa1HGdM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx3lzu9oQqrora6IVk/t1nDzXPq/HVNsv8j1Sp8u5YiLqsD37Qz
	a2IyxZ8fTwYasUIIJrsGSZ+ZeJUEalURuM9FwAs/fWf4XNH9ChEtT2dzfzyL6jA=
X-Gm-Gg: ASbGncu8i/jttQ7yaIkSgPYk2QRrnxT/Xvz9Sm9I0oRgesNtsaf2qmb1nr/Kga6wl4s
	++qgPKK49eZFHM4voKXphJS5Q7wgqXNvQaYfFbRvR8yCJb2GtMQPZdkRAFr/ZoWczsDdLkd+ubs
	7Br/0PEr7pzThllWOut4UmMZfhnc0paxBEANcdCfzDYwN1o7+RB4RINMqdaZpxt9SD49H8UBOfQ
	ZfikVGnmNZ/UIB8qquM+vrXc/ZjpmDuy79/KWMMr8VyGlHGrx9yV5FNOGhmUX6XgwQiojkyfxdC
	BMfraP5JFbX6axwyfozNKG95XSR9JvJo4CiQvMOkVHThCA==
X-Google-Smtp-Source: AGHT+IFC1DyF4d+X5J3BxbLb2CnYYX+Er6gtoQAzdbxu7TwNyk7ObTMx4o7w8u4j2nPP9eRdM+vWUQ==
X-Received: by 2002:a05:600c:83c4:b0:43c:fad6:fa5a with SMTP id 5b1f17b1804b1-442d033f8cemr19606855e9.24.1746690767933;
        Thu, 08 May 2025 00:52:47 -0700 (PDT)
Date: Thu, 8 May 2025 09:52:46 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Demi Marie Obenour 
Cc: Alejandro Vallejo ,
	Xen developer discussion ,
	Andrew Cooper ,
	Juergen Gross ,
	Xen-devel 
Subject: Re: Mapping memory into a domain
Message-ID: 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>

On Wed, May 07, 2025 at 08:36:07PM -0400, Demi Marie Obenour wrote:
> On 5/7/25 1:39 PM, Roger Pau Monné wrote:
> > On Tue, May 06, 2025 at 04:56:12PM -0400, Demi Marie Obenour wrote:
> >> On 5/6/25 9:06 AM, Alejandro Vallejo wrote:
> >>> On Tue May 6, 2025 at 3:02 AM CEST, Demi Marie Obenour wrote:
> >>>> On 5/5/25 7:32 AM, Alejandro Vallejo wrote:
> >>>>> I suppose this is still about multiplexing the GPU driver the way we
> >>>>> last discussed at Xen Summit?
> >>>>>
> >>>>> On Mon May 5, 2025 at 12:51 AM CEST, Demi Marie Obenour wrote:
> >>>>>> What are the appropriate Xen internal functions for:
> >>>>>>
> >>>>>> 1. Turning a PFN into an MFN?
> >>>>>> 2. Mapping an MFN into a guest?
> >>>>>> 3. Unmapping that MFN from a guest?
> >>>>>
> >>>>> The p2m is the single source of truth about such mappings.
> >>>>>
> >>>>> This is all racy business. You want to keep the p2m lock for the full
> >>>>> duration of whatever operation you wish do, or you risk another CPU
> >>>>> taking it and pulling the rug under your feet at the most inconvenient
> >>>>> time.
> >>>>>
> >>>>> In general all this faff is hidden under way too many layers beneath
> >>>>> copy_{to,from}_guest(). Other p2m manipulation high-level constructs
> >>>>> that might do interesting things worth looking at may be {map,unmap}_mmio_region()
> >>>>>
> >>>>> Note that not every pfn has an associated mfn. Not even every valid pfn
> >>>>> has necessarily an associated mfn (there's pod). And all of this is
> >>>>> volatile business in the presence of a baloon driver or vPCI placing
> >>>>> mmio windows over guest memory.
> >>>>
> >>>> Can I check that POD is not in use?  
> >>>
> >>> Maybe, but now you're reaching exponential complexity considering each
> >>> individual knob of the p2m into account.
> >>>
> >>>>
> >>>>> In general anything up this alley would need a cohesive pair for
> >>>>> map/unmap and a credible plan for concurrency and how it's all handled
> >>>>> in conjunction with other bits that touch the p2m.
> >>>>
> >>>> Is taking the p2m lock for the entire operation a reasonable approach
> >>>> for concurrency?  Will this cause too much lock contention?
> >>>
> >>> Maybe. It'd be fine for a page. Likely not so for several GiB if they
> >>> aren't already superpages.
> >>>
> >>>>
> >>>>>> The first patch I am going to send with this information is a documentation
> >>>>>> patch so that others do not need to figure this out for themselves.
> >>>>>> I remember being unsure even after looking through the source code, which
> >>>>>> is why I am asking here.
> >>>>>
> >>>>> That's not surprising. There's per-arch stuff, per-p2mtype stuff,
> >>>>> per-guesttype stuff. Plus madness like on-demand memory. It's no wonder
> >>>>> such helpers don't exist and the general manipulations are hard to
> >>>>> explain.
> >>>>
> >>>> Is this a task that is only suitable for someone who has several years
> >>>> experience working on Xen, or is it something that would make sense for
> >>>> someone who is less experienced?
> >>>
> >>> The p2m is a very complex beast that integrates more features than I
> >>> care to count. It requires a lot of prior knowledge. Whoever does it
> >>> must know Xen fairly well in many configurations.
> >>>
> >>> The real problem is finding the right primitives that do what you want
> >>> without overcomplicating everything else, preserving system security
> >>> invariants and have benign (and ideally clear) edge cases.
> >>>
> >>> This was the last email you sent (I think?). Has any of the requirements
> >>> changed in any direction?
> >>>
> >>>   https://lore.kernel.org/xen-devel/Z5794ysNE4KDkFuT@itl-email/
> >>
> >> Map and Revoke are still needed, with the same requirements as described
> >> in this email.  Steal and Return were needed for GPU shared virtual memory,
> >> but it has been decided to not support this with virtio-GPU, so these
> >> primitives are no longer needed.
> >>
> >>> Something I'm missing there is how everything works without Xen. That
> >>> might help (me, at least) guage what could prove enough to support the
> >>> usecase. Are there sequence diagrams anywhere about how this whole thing
> >>> works without Xen? I vaguely remember you showing something last year in
> >>> Xen Summit in the design session, but my memory isn't that good :)
> > 
> > Hello,
> > 
> > Sorry, possibly replying a bit out of context here.
> > 
> > Since I will mention this in several places: p2m is the second stage
> > page-tables used by Xen for PVH and HVM guests.  A p2m violation is
> > the equivalent of a page-fault for guest p2m accesses.
> > 
> >> A Linux driver that needs access to userspace memory
> >> pages can get it in two different ways:
> >>
> >> 1. It can pin the pages using the pin_user_pages family of APIs.
> >>    If these functions succeed, the driver is guaranteed to be able
> >>    to access the pages until it unpins them.  However, this also
> >>    means that the pages cannot be paged out or migrated.  Furthermore,
> >>    file-backed pages cannot be safely pinned, and pinning GPU memory
> >>    isn’t supported.  (At a minimum, it would prevent the pages from
> >>    migrating from system RAM to VRAM, so all access by a dGPU would
> >>    cross the PCIe bus, which would be very slow.)
> > 
> > From a Xen p2m this is all fine - Xen will never remove pages from the
> > p2m unless it's requested to.  So the pining, while needed on the Linux
> > side, doesn't need to be propagated to Xen I would think.
> 
> If pinning were enough things would be simple, but sadly it’s not.
> 
> >> 2. It can grab the *current* location of the pages and register an
> >>    MMU notifier.  This works for GPU memory and file-backed memory.
> >>    However, when the invalidate_range function of this callback, the
> >>    driver *must* stop all further accesses to the pages.
> >>
> >>    The invalidate_range callback is not allowed to block for a long
> >>    period of time.  My understanding is that things like dirty page
> >>    writeback are blocked while the callback is in progress.  My
> >>    understanding is also that the callback is not allowed to fail.
> >>    I believe it can return a retryable error but I don’t think that
> >>    it is allowed to keep failing forever.
> >>
> >>    Linux’s grant table driver actually had a bug in this area, which
> >>    led to deadlocks.  I fixed that a while back.
> >>
> >> KVM implements the second option: it maps pages into the stage-2
> >> page tables (or shadow page tables, if that is chosen) and unmaps
> >> them when the invalidate_range callback is called.
> > 
> > I assume this map and unmap is done by the host as a result of some
> > guest action?
> 
> Unmapping can happen at any time for any or no reason.  Semantically,
> it would be correct to only map the pages in response to a p2m violation,
> but for performance it might be better to map the pages eagerly instead.

That's an implementation detail, you can certainly map the pages
eagerly, or even map multiple contiguous pages as a result of a single
p2m violation.

I would focus on making a functioning prototype first, performance
comes afterwards.

> >> Furthermore,
> >> if a page fault happens while the page is unmapped, KVM will try
> >> to bring the pages back into memory so the guest can access it.
> > 
> > You could likely handle this in Xen in the following way:
> > 
> >  - A device model will get p2m violations forwarded, as it's the same
> >    model that's used to handle emulation of device MMIO.  You will
> >    need to register an ioreq server to request those faults to be
> >    forwarded, I think the hardware domain kernel will handle those?
> > 
> >  - Allow ioreqs to signal to Xen that a guest operation must be
> >    retried.  IOW: resume guest execution without advancing the IP.
> > 
> > I think this last bit is the one that will require changes to Xen, so
> > that you can add a type of ioreq reply that implies a retry from the
> > guest context.
> I’m not actually sure if this is needed, though it would be nice.  It
> might be possible for Xen to instead emulate the current instruction and
> continue, with the ioreq server just returning the current value of the
> pages.

You can, indeed, but it's cumbersome?  You might have to map the page
in the context of the entity that implements the ioreq server to
access the data.  Allowing retries would be more generic, and reduce
the code in the ioreq server handler, that would only map the page
to the guest p2m and request a retry.

> What I’m more concerned about is being able to provide a page
> into the p2m so that the *next* access doesn’t fault, and being able
> to remove that page from the p2m so that the next access *does* fault.

Maybe I'm not getting the question right, all Xen modifications to the
p2m take immediate effect.  By the time a XEN_DOMCTL_memory_mapping
hypercall returns the operation would have taken effect.

> Are there any hypercalls that can be used for these operations right
> now?

With some trickery you could likely use XEN_DOMCTL_memory_mapping to
add and remove those pages.  You will need calls to
XEN_DOMCTL_iomem_permission beforehand so that you grant the receiving
domain permissions to access those (and of course the granting domain
needs to have full access to them).

This is no ideal if mapping RAM pages, AFAICT there are no strict
checks that the added page is not RAM, but still you will need to
handle RAM pages as IOMEM so and grant them using
XEN_DOMCTL_iomem_permission which is not great.  Also note that this
is a domctl, so not stable.  It might however be enough for a
prototype.

Long term I think we want to expand XENMEM_add_to_physmap{,_batch} to
handle this use-case.

> If not, which Xen functions would one use to implement them?
> Some notes:
> 
> - The p2m might need to be made to point to a PCI BAR or system RAM.
>   The guest kernel and host userspace don’t know which, and in any
>   case don’t need to care.  The host kernel knows, but I don’t know
>   if the information is exposed to the Xen driver.

Hm, as said above, while you could possible handle RAM as IOMEM, it
has the slight inconvenience of having to add such RAM pages to the
d->iomem_caps rangeset for XEN_DOMCTL_memory_mapping to succeed.

>From a guest PoV, it doesn't matter if the underlying page is RAM or
MMIO, as long as it's mapped in the p2m.

> 
> - If the p2m needs to point to system RAM, the RAM will be memory
>   that belongs to the backend.
> 
> - If the p2m needs to point to a PCI BAR, it will initially need
>   to point to a real PCI device that is owned by the backend.

As long as you give the destination domain access to the page using
XEN_DOMCTL_iomem_permission prior to the XEN_DOMCTL_memory_mapping
call it should work.

How does this work for device DMA accesses?  If the device is assigned
to the backend domain (and thus using the backend domain IOMMU context
entry and page-tables) DMA accesses cannot be done against guest
provided addresses, there needs to be some kind of translation layer
that filters commands?

My initial recommendation would be to look into what you can do with
the existing XEN_DOMCTL_iomem_permission and XEN_DOMCTL_memory_mapping
hypercalls.

> - The switch from “emulated MMIO” to “MMIO or real RAM” needs to
>   be atomic from the guest’s perspective.

Updates of p2m PTEs are always atomic.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 08 08:33:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 08:33:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979057.1365773 (Exim 4.92)
	(envelope-from )
	id 1uCwgf-0004fj-Qq; Thu, 08 May 2025 08:33:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979057.1365773; Thu, 08 May 2025 08:33:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCwgf-0004fc-Nl; Thu, 08 May 2025 08:33:01 +0000
Received: by outflank-mailman (input) for mailman id 979057;
 Thu, 08 May 2025 08:33:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCwge-0004fW-9l
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 08:33:00 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0b2c620f-2be7-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 10:32:58 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43ce71582e9so4606555e9.1
 for ; Thu, 08 May 2025 01:32:57 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-441d15e211asm67356785e9.1.2025.05.08.01.32.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 08 May 2025 01:32: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" 
X-Inumbo-ID: 0b2c620f-2be7-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746693177; x=1747297977; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=7NH6Wu4VjYQjNA6A0nR0ihgWpbNXXm1I3htBfJJdz8M=;
        b=frfC8oDwMZFt98JcxcNoK0Yh+DbzN/mK1ZEOxaIy9v0wKypLFlDSGdgCEsn/qfR55S
         lTOsUKXAJMNKiXoxudXekWsj6YqpBlnqOnBD8bf81O2w5L0KDhhzuUwUpVPquIZhe3lE
         GDsHSPp3vBFoZfqZl8jMCTU7rI2T9xzkYed0Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746693177; x=1747297977;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7NH6Wu4VjYQjNA6A0nR0ihgWpbNXXm1I3htBfJJdz8M=;
        b=JnmO+7+XYK1Wk+gNjzUNYtq6DvYMM99QzTVyNaBgqf0RbA7Gr7pir4eMDKL8QAGiPQ
         oXfhRirar6lxFRavQHpBlTkaQjk46zPNhBBF6o4DAfFd5nLRjQM+bjsOWyAXT3x1e35z
         ZIZbaqqY2gwM1Je1b21Wue3lGPyfQRXN7qspamgAuiBoMzHSz/OIYpjx/pGdmuJ6nsBy
         tuH6MXDnxlOdCkOVs9/ycOAAtKgdNgTh0RqDo2uQcvPlrGLWo/Yt/uyGGWbQXXneFg/l
         5RPEm28EDbFmm7roW5hGlrIP96UasehYClsPWiEzDXOnLj/Tk0TdZQG423ePItyLYQll
         59YA==
X-Forwarded-Encrypted: i=1; AJvYcCX8e5V9rS2mjdCiJm0t7jBvcwOTcSda84V628Z9lJbTbLpPwwaleBxJTpVjgp5PqdIwkFRdu7hayBU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxMVcWI5v1RswIgmPbii2b6kWLcCq8EzBGj2CXUnvoPrZBXGAYF
	2xEq1YrNQwkMhm24xlQZRMFWMnJ97oSFye4sasuBg3VZi3jSDBgbDo6CVfnDjtw=
X-Gm-Gg: ASbGncvaFeCR40CGWh0C0o3EgluYnJZ64dTXg2ANf7gMra57/WIbbhYgJZqwmUMoHCO
	+yHBXAGGeqAzVXBZJZCaXv3ABPlVhlUXeRqRiHWP2JRtAfjkFGtVuVDy7zixv+zD+OkZev6+k82
	R2wcrePNd56il/f0xSSGjniaJ4dQND77EY4oG9i5mcdVaO1e2C5SCFNrjGrgZFO0hvDnO606ule
	yGEprlIhW6avP/jYXPCpQnsJXoNMi23zdKGo8rBs+1L+jLTdP76N54Zd6/pUVMl2IZ03Zlukb8C
	/K9p6QGxP8SnZI1b7JF4GIBR78KRFcjq8S9s05KfKjHRxQ==
X-Google-Smtp-Source: AGHT+IEBVwcrEcZ+cvB6BdsrjTxGYf9IEerIrEjRWj3BP2GJl5HFjQx1chAbZ19ZttRXmKI4bqie7A==
X-Received: by 2002:a05:600c:c0d0:b0:43d:77c5:9c1a with SMTP id 5b1f17b1804b1-442d046e76emr21956505e9.4.1746693176804;
        Thu, 08 May 2025 01:32:56 -0700 (PDT)
Date: Thu, 8 May 2025 10:32:55 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: Julien Grall , xen-devel@lists.xenproject.org,
	Oleksandr Andrushchenko ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Jiqian Chen ,
	Mykyta Poturai 
Subject: Re: [PATCH v20 2/2] vpci: translate virtual PCI bus topology for
 guests
Message-ID: 
References: <20250418185840.335816-1-stewart.hildebrand@amd.com>
 <20250418185840.335816-3-stewart.hildebrand@amd.com>
 
 <3693f1ef-e305-4a6b-bb4e-3b842418387f@amd.com>
 
 
 
 <47ee8b59-7b6a-4248-a4bd-f5be9f00f562@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <47ee8b59-7b6a-4248-a4bd-f5be9f00f562@amd.com>

On Wed, May 07, 2025 at 05:17:58PM -0400, Stewart Hildebrand wrote:
> On 5/7/25 13:44, Roger Pau Monné wrote:
> > On Wed, May 07, 2025 at 09:38:51AM -0400, Stewart Hildebrand wrote:
> >> On 5/7/25 03:44, Roger Pau Monné wrote:
> >>> On Tue, May 06, 2025 at 11:05:13PM -0400, Stewart Hildebrand wrote:
> >>>> On 5/6/25 07:16, Roger Pau Monné wrote:
> >>>>> On Fri, Apr 18, 2025 at 02:58:37PM -0400, Stewart Hildebrand wrote:
> >>>>>> From: Oleksandr Andrushchenko 
> >>>>>>  static int vpci_register_cmp(const struct vpci_register *r1,
> >>>>>>                               const struct vpci_register *r2)
> >>>>>>  {
> >>>>>> @@ -438,7 +473,7 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
> >>>>>>      const struct pci_dev *pdev;
> >>>>>>      const struct vpci_register *r;
> >>>>>>      unsigned int data_offset = 0;
> >>>>>> -    uint32_t data = ~(uint32_t)0;
> >>>>>> +    uint32_t data = 0xffffffffU >> (32 - 8 * size);
> >>>>>
> >>>>> This seems kind of unrelated to the rest of the code in the patch,
> >>>>> why is this needed?  Isn't it always fine to return all ones, and let
> >>>>> the caller truncate to the required size?
> >>>>>
> >>>>> Otherwise the code in vpci_read_hw() also needs to be adjusted.
> >>>>
> >>>> On Arm, since 9a5e22b64266 ("xen/arm: check read handler behavior") we
> >>>> assert that the read handlers don't set any bits above the access size.
> >>>
> >>> I see.  That kind of diverges from x86 behavior, that AFAICT (see
> >>> memcpy() at tail of hvmemul_do_io()) instead truncates the memcpy to
> >>> the size of the access.
> >>>
> >>> Maybe it would be better to instead of asserting just truncate the
> >>> returned value to the given size, as that would allow to just return
> >>> ~0 from handlers without having to care about the specific access
> >>> size.
> >>
> >> The impression I get from [0] is that that on Arm, there's no benefit to
> >> performing truncation in xen/arch/arm/io.c. Doing so would needlessly
> >> affect other Arm internal read handlers (e.g. vGIC).
> > 
> > But isn't this truncation desirable in order to avoid possibly setting
> > bits outside of the access size?
> 
> On Arm we expect the read handlers to have the bits above the access
> size zeroed. If a read handler sets bits above the access size, it could
> indicate a bug in the read handler. As a reminder, this was already
> discussed at [0] and a patch was already committed 9a5e22b64266
> ("xen/arm: check read handler behavior"). Perhaps we could both keep the
> ASSERT (for debug builds) and perform truncation (for release builds) in
> xen/arch/arm/io.c:handle_read(), but that's patch for another day.
> 
> [0] https://lore.kernel.org/xen-devel/20240522225927.77398-1-stewart.hildebrand@amd.com/T/#t

Oh, I see.  I already expressed concerns on that thread about forcing
the truncation to be done by handler implementations vs truncating in
a generic place ahead of propagating to the registers.

My main concern is when returning ~0, as it seems cumbersome to have
to truncate that, and I think we do blindly return ~0 on more than one
x86 IO handler.

> >> For vPCI
> >> specifically, however, we could potentially perform truncation in
> >> xen/arch/arm/vpci.c. So I guess it's a question of whether we want to
> >> give special treatment to vPCI compared to all other read handlers on
> >> Arm?
> > 
> > I would think doing the truncation uniformly for all reads would be
> > better, as we then ensure the value propagated to the registers always
> > matches the access size?
> > 
> > I'm not expert on ARM, but it seems cumbersome to force this to all
> > internal handlers, instead of just truncating the value in a single
> > place.
> 
> To move this forward, I suggest performing this truncation in
> xen/arch/arm/vpci.c:vpci_mmio_read(). This will be a single place to
> perform truncation for Arm vPCI, and will not affect other Arm internal
> mmio handlers.

You already have the mask there, so it should be easy to do:

*r = data & invalid;

To truncate the value.  Could you send that as a separate patch with a
Fixes tag?

Thanks, I'm sorry for not realizing about this before.

Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 08 08:52:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 08:52:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979078.1365783 (Exim 4.92)
	(envelope-from )
	id 1uCwz6-0007el-88; Thu, 08 May 2025 08:52:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979078.1365783; Thu, 08 May 2025 08: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 1uCwz6-0007ee-53; Thu, 08 May 2025 08:52:04 +0000
Received: by outflank-mailman (input) for mailman id 979078;
 Thu, 08 May 2025 08:52:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCwz4-0007eW-Ha
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 08:52:02 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b51f6410-2be9-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 10:52:01 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-39ee5a5bb66so484316f8f.3
 for ; Thu, 08 May 2025 01:52:01 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a0b5b0d349sm4778301f8f.30.2025.05.08.01.52.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 08 May 2025 01: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" 
X-Inumbo-ID: b51f6410-2be9-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746694321; x=1747299121; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jzREn0+PSLkNcr/0qXEMCvQkKBRdoXjk3um8+tlfi2c=;
        b=tZtNpaOMCfUX8zsTpJJjJh4rLG84STjQQi70SsD72DrgkJdm+BCLh3oOcGYui3wN/1
         KxSJbmV/U//Hy1DiwM0qy+WqpdduGBcZ0HOK2aco70RU+phmGJwjUJfpWYtph5XuGIFa
         hsDbAH1S5rqV9mBHEthMFHaQWlDsEiaocjYJE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746694321; x=1747299121;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jzREn0+PSLkNcr/0qXEMCvQkKBRdoXjk3um8+tlfi2c=;
        b=fV86kthoDHWQAo3K7xLsjMhMBAjiAE9pGYYWFx4gTBg8pjG4BdHoZv0lcWgYR+y69R
         Hi46D1aU1uDTFAt2GwvSUYeKVOHwRi+qA7OCdCDRkt5Kx/7huNvbIXWJR3Ug+mJS+d6A
         Lt8xaMnfUPHLL+tI3EeZGlaiOvp9mh6drY3yHp7cCNGuEhJOai73Qni8/e82xC8guBXS
         ixEnleujJKwJxpfWyWCwiTI6rP+ThETFslKbzuoeD1N6QO4MaSO6dRvc2KgORYPc5nl7
         /prG/OmQ8J0uB6Q2fv9F2vCO023AN8LLr3V7coARTWFSB6RVuomuVROQbgmYXak83gW6
         mNfQ==
X-Forwarded-Encrypted: i=1; AJvYcCU+OGqwS7kQX/jNOuomCoGGghr5C1+OwlDsLb8XB4kw3K8dFMEtPhoduo1hjWUwtCLqPqGZn8Ib6sY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwaHHdM5bozr8WTryLkj9t0jTQKVs0DMZeCbBfFnDUmKWsCE32X
	gQPGPjCbhJMtH5j1eHkleGx/szfgvKfRoQL70umIGl9sb3pWa8m7eq1mbWVVyjk=
X-Gm-Gg: ASbGncu7kAcd3Ea3e8aZeFdsMq9N0Rk+rAJVqISoiHvdos3P4lFtJftYJmQCXBC+Men
	AwX6IxarLf6BnT6T/fdJrfjCgLCLeaxPzEQzdOlEMsGlYSadMIV87xLIeo1tGZ/i/aEYG39rPjD
	vBEo6Db8CdPTgZWDXb1A7b5mItDzII+ObRxRYFPd0mrXlLVWjPItwL/H4XWWQgIpvPbcWDeTsEO
	xK76gD1yvTpFPVRk3dRPJZtyP/UbD2uoIuqJnaBfnyrjXVTdvNAO6vxmy7V5pDIPgJX/4Cj7ClB
	dMYIgM5/MUGciE9RQtoFqun59e4Az/ByRa/x5BlM5ozvJgSbAVikygz0JgnOsJUOxGURwnW5+jR
	tQhD/nQ==
X-Google-Smtp-Source: AGHT+IG8CVIk7eiO3SnDhDYFPi4wTu8w0HiUsXVqIPM+0v4gcSyr7C3GpVxFsu7QHRoGfnvSnS803Q==
X-Received: by 2002:a05:6000:ec6:b0:3a0:b4fa:e594 with SMTP id ffacd0b85a97d-3a0b4fae636mr4734235f8f.33.1746694321026;
        Thu, 08 May 2025 01:52:01 -0700 (PDT)
Message-ID: <94652153-99fe-47d8-84d5-cbf2865ad6e0@citrix.com>
Date: Thu, 8 May 2025 09:51:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3] sbat: Add SBAT section to the Xen EFI binary
To: Gerald Elder-Vass ,
 xen-devel@lists.xenproject.org
Cc: dpsmith@apertussolutions.com, marmarek@invisiblethingslab.com,
 Frediano Ziglio , Jan Beulich
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250507135442.3439237-1-gerald.elder-vass@cloud.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: <20250507135442.3439237-1-gerald.elder-vass@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07/05/2025 2:54 pm, Gerald Elder-Vass wrote:
> diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
> index 24dfecfad184..75aa35870a9a 100644
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -6,11 +6,17 @@ cmd_objcopy_o_ihex = $(OBJCOPY) -I ihex -O binary $< $@
>  $(obj)/%.o: $(src)/%.ihex FORCE
>  	$(call if_changed,objcopy_o_ihex)
>  
> +$(obj)/sbat.o: OBJCOPYFLAGS := -I binary -O elf64-x86-64 --rename-section .data=.sbat,readonly,data,contents
> +$(obj)/sbat.o: $(src)/sbat.sbat FORCE
> +	$(call if_changed,objcopy)
> +

Doing a build locally with this, I've found two issues.  One is:

> ld: warning: arch/x86/efi/sbat.o: missing .note.GNU-stack section implies executable stack
> ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
> ld: warning: arch/x86/efi/built_in.o: requires executable stack (because the .note.GNU-stack section is executable)
> ld: warning: arch/x86/built_in.o: requires executable stack (because the .note.GNU-stack section is executable)
> ld: warning: prelink.o: requires executable stack (because the .note.GNU-stack section is executable)
> ld: warning: prelink.o: requires executable stack (because the .note.GNU-stack section is executable)
> ld: warning: prelink.o: requires executable stack (because the .note.GNU-stack section is executable)

which isn't a terribly good look on a "higher security" feature.  The
easiest way to fix this is:

$(obj)/sbat.o: OBJCOPYFLAGS := -I binary -O elf64-x86-64 \
        --rename-section .data=.sbat,readonly,data,contents \
        --add-section .note.GNU-stack=/dev/null

to add the required section.



>  $(obj)/boot.init.o: $(obj)/buildid.o
>  
>  $(call cc-option-add,cflags-stack-boundary,CC,-mpreferred-stack-boundary=4)
>  $(addprefix $(obj)/,$(EFIOBJ-y)): CFLAGS_stack_boundary := $(cflags-stack-boundary)
>  
> +EFIOBJ-y += sbat.o

Also,

> ld: warning: orphan section `.sbat' from `prelink.o' being placed in section `.sbat'

This is because sbat.o is getting linked into the non-EFI build of Xen too.

I'm less sure how to go about fixing this.  There's no nice way I can
see of of getting sbat.o only in the EFI build.  The other option is to
discard it for the ELF build.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu May 08 09:10:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 09:10:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979091.1365793 (Exim 4.92)
	(envelope-from )
	id 1uCxGU-0001Mt-LS; Thu, 08 May 2025 09:10:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979091.1365793; Thu, 08 May 2025 09: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 1uCxGU-0001MH-IF; Thu, 08 May 2025 09:10:02 +0000
Received: by outflank-mailman (input) for mailman id 979091;
 Thu, 08 May 2025 09:10:01 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uCxGT-0001A0-BB
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 09:10:01 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uCxGS-00HEPn-39;
 Thu, 08 May 2025 09:10:00 +0000
Received: from [2a02:8012:3a1:0:463:6943:9e59:fb6a]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uCxGS-008tjr-2G;
 Thu, 08 May 2025 09:10: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=vfRRyw0qdZFdT9DSzbietHI+ijxHfe3kBhKAJ4oazgI=; b=fZPRb33yC3nBeznYt7X3WOkqPZ
	LqEfIH62zUWQSY+lx/HP8+smHpAQGKLMHMOlcwT4JdlNCi6UxGxWnBDGDv27WaQ8lKCsv6al27Rr1
	uMWV8ZAzVg1kiNl+P/96iuscfKLTeQfHXg6bocxbgyaKVGLRyE/OUPpeSYfN1QqBs4Ig=;
Message-ID: 
Date: Thu, 8 May 2025 10:09:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] device-tree: Add missing SPDX identifiers and EMACS
 comment blocks
Content-Language: en-GB
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis 
References: <20250506080752.23307-1-michal.orzel@amd.com>
From: Julien Grall 
In-Reply-To: <20250506080752.23307-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 06/05/2025 09:07, Michal Orzel wrote:
> Use the same license as the files from which the code originated during
> recent code movements. Take the opportunity to add SPDX identifier for
> device-tree.c and remove the license text.
> 
> Signed-off-by: Michal Orzel 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu May 08 09:12:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 09:12:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979100.1365802 (Exim 4.92)
	(envelope-from )
	id 1uCxJ1-0002rp-24; Thu, 08 May 2025 09:12:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979100.1365802; Thu, 08 May 2025 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 1uCxJ0-0002ri-Vb; Thu, 08 May 2025 09:12:38 +0000
Received: by outflank-mailman (input) for mailman id 979100;
 Thu, 08 May 2025 09:12:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCxJ0-0002rc-Ar
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 09:12:38 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 94c502f3-2bec-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 11:12:35 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-440685d6afcso8551565e9.0
 for ; Thu, 08 May 2025 02:12:35 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a0b0dffaa1sm7640390f8f.31.2025.05.08.02.12.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 08 May 2025 02: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" 
X-Inumbo-ID: 94c502f3-2bec-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746695555; x=1747300355; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=0tTzO1n509S/7TZQBMtgevWvsDffCoLbD3fYFzoPqUQ=;
        b=ZvVFb8XlkiJX4AVrr8hLiNBko8vDENxa47DWcdqTqbtM9aJMs6x5mPIHrxKye1OIdz
         BDofec9HXHszrITbZBQoaE2rSeuS8ADDLEVdN44OGyRSV7XMwjPEJ1s0Cy/lZHIgkVLK
         Hz50mP65Afqq23Dy+a+Rm0V0yCxBJjxBPMquc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746695555; x=1747300355;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=0tTzO1n509S/7TZQBMtgevWvsDffCoLbD3fYFzoPqUQ=;
        b=OAaWQc7SDzYmbUdPoEvq2k0s4AcpF9Jvk/ScS63MAejwkA2jex7Utsc0REJeerwtDF
         d5jcDxjsQjMXfeq8iUZCGY7RKW3BMQPJw/MfbXDok/esIdQeXgAD7vZYKWE/GCxL6LFn
         hdobZZ/3Nd3VyS0rqSmnJ8HdIdHrgEZZoIuZS3h0AjxFIA56N+4YYKFyg41zX00YPFa4
         d0pfQWXTpyxKq+u7PdetVLREbmskvGwCY9qYYqbbaWqn85YQVLaC1eJNNVplA8fsc+CR
         rc1WJGFeQckjzJllBpS2aiXy2ISBbyJAl66aPAOWdgbmPGRZOLZ0H/Saau4RjS6/RtwN
         aOTg==
X-Forwarded-Encrypted: i=1; AJvYcCUh387JcuGBcx0zyEWcbH64N5b8v41StorHzv8TXiPlg5lr99bsjAPPg9BHnQJqdzubzco6dw2GLcQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywi8zIntQaMueTtkTb/gNZL5+Y43Ob0whShFNPTneMoO5H18M02
	Twoh8g514i/O9tEevZLhkcLTi0oznFf6FVNA+jpF/ePznjY7IONrpyCitiDtiIg=
X-Gm-Gg: ASbGncuW3CExOWP0HV0HtM/yePVcRWjB6Dgwr7BXSbGdM2CItljUpdX/Qc5PSLQqxz1
	r8fZ2Zno1UGe0bm8RF48M//mhXk+B73y0XPdaRlZgO1y1tW3wWIRi7XTmt9Z3CT159U8tk1xK5K
	J/K/UMxuywjh7+6yO6L1cuQa3pnqXVZr0WM9Zkumw64IOS6zLUwGpevH8QCm8ogXcbiBPoKejIR
	mvQQne+nwRCdwzKb6AyTaClT1ZLKsuic9fPrW0oXn7QZ/ReXsFdrLbQX6+c98JlbsGk0Sb7kT5j
	m2aaf+IM80fcqwgRILhv4GQvbV6IuTLrqMg3fNbIUw/RGfp7Rn/2yG8T
X-Google-Smtp-Source: AGHT+IEAbrIMXyDqEmQc6BJDtPUEVbovYPpPbaFNNIxNfDcgvYJvEgqYWCsK0lHZdO85NS8do7mMzw==
X-Received: by 2002:a05:600c:1d08:b0:43c:fffc:7855 with SMTP id 5b1f17b1804b1-441d44c7d8cmr60332035e9.15.1746695555168;
        Thu, 08 May 2025 02:12:35 -0700 (PDT)
Date: Thu, 8 May 2025 11:12:34 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stefano Stabellini 
Cc: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	Jan Beulich ,
	"Ragiadakou, Xenia" ,
	Andrew Cooper , jason.andryuk@amd.com,
	agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
Message-ID: 
References: 
 <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>
 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
> On Tue, 6 May 2025, Roger Pau Monné wrote:
> > On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
> > > On Mon, 5 May 2025, Roger Pau Monné wrote:
> > > > On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> > > > > On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
> > > > > > On Mon, 28 Apr 2025, Jan Beulich wrote:
> > > > > > > On 25.04.2025 22:19, Stefano Stabellini wrote:
> > > > > > > > From: Xenia Ragiadakou 
> > > > > > > > 
> > > > > > > > Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> > > > > > > > addresses to firmware or co-processors not behind an IOMMU.
> > > > > > > 
> > > > > > > I definitely don't understand the firmware part: It's subject to the
> > > > > > > same transparent P2M translations as the rest of the VM; it's just
> > > > > > > another piece of software running there.
> > > > > > > 
> > > > > > > "Co-processors not behind an IOMMU" is also interesting; a more
> > > > > > > concrete scenario might be nice, yet I realize you may be limited in
> > > > > > > what you're allowed to say.
> > > > > > 
> > > > > > Sure. On AMD x86 platforms there is a co-processor called PSP running
> > > > > > TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionally to
> > > > > > pass addresses to it.  See drivers/tee/amdtee/ and
> > > > > > include/linux/psp-tee.h in Linux.
> > > > > 
> > > > > We had (have?) similar issue with amdgpu (for integrated graphics) - it
> > > > > uses PSP for loading its firmware. With PV dom0 there is a workaround as
> > > > > dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, but I
> > > > > expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's
> > > > > the one I used for debugging this issue).
> > > > 
> > > > That's ugly, and problematic when used in conjunction with AMD-SEV.
> > > > 
> > > > I wonder if Xen could emulate/mediate some parts of the PSP for dom0
> > > > to use, while allowing Xen to be the sole owner of the device.  Having
> > > > both Xen and dom0 use it (for different purposes) seems like asking
> > > > for trouble.  But I also have no idea how complex the PSP interface
> > > > is, neither whether it would be feasible to emulate the
> > > > interfaces/registers needed for firmware loading.
> > > 
> > > Let me take a step back from the PSP for a moment. I am not opposed to a
> > > PSP mediator in Xen, but I want to emphasize that the issue is more
> > > general and extends well beyond the PSP.
> > > 
> > > In my years working in embedded systems, I have consistently seen cases
> > > where Dom0 needs to communicate with something that does not go through
> > > the IOMMU. This could be due to special firmware on a co-processor, a
> > > hardware erratum that prevents proper IOMMU usage, or a high-bandwidth
> > > device that technically supports the IOMMU but performs poorly unless
> > > the IOMMU is disabled. All of these are real-world examples that I have
> > > seen personally.
> > 
> > I wouldn't be surprised, classic PV dom0 avoided those issues because
> > it was dealing directly with host addresses (mfns), but that's not the
> > case with PVH dom0.
> 
> Yeah
> 
> 
> > > In my opinion, we definitely need a solution like this patch for Dom0
> > > PVH to function correctly in all scenarios.
> > 
> > I'm not opposed to having such interface available for PVH hardware
> > domains.  I find it ugly, but I don't see much other way to deal with
> > those kind of "devices".  Xen mediating accesses for each one of them
> > is unlikely to be doable.
> > 
> > How do you hook this exchange interface into Linux to differentiate
> > which drivers need to use mfns when interacting with the hardware?
> 
> In the specific case we have at hands the driver is in Linux userspace
> and is specially-written for our use case. It is not generic, so we
> don't have this problem. But your question is valid.

Oh, so you then have some kind of ioctl interface that does the memory
exchange and bouncing inside of the kernel on behalf of the user-space
side I would think?

> In Linux, the issue is hidden behind drivers/xen/swiotlb-xen.c and
> xen_arch_need_swiotlb. There are a few options:
> - force swiotlb bounce for everything on the problematic SoC
> - edit xen_arch_need_swiotlb to return true for the problematic device
> - introduce a kernel command line option to specify which device
>   xen_arch_need_swiotlb should return true for

Isn't it a bit misleading to use the swiotlb for this purpose?  Won't
this usage of the swiotlb (to bounce from gfns to mfns) create issues
if there's any devices that have a DMA physical address limitation and
also needs to use the swiotlb while being behind the IOMMU?

> - introduce an ACPI table with the relevant info

Hm, best option might be an ACPI table so that Xen can signal to the
hardware domain whether communication with the device must be done
using mfns, or if accesses are mediated and hence can be done using
gfns?

It's a bit cumbersome however to have to resort to an ACPI table just
for this.  Not sure whether we could expand one of the existing tables
already under Xen control (STAO?) to contain this information.  It all
looks a bit ad-hoc.

I think we need some kind of list of devices that are not behind the
IOMMU, but I have no idea what URI to use to identify those.  I assume
the PSP doesn't have a PCI SBDF (as it's not on the PCI bus?).  Maybe
by ACPI path?

Or maybe it's fine to always communicate with those non-translated
devices using MFNs, and even if we later add some kind of PSP
mediation (so that both Xen and dom0 can use it), accesses by dom0
will still be assumed to be using MFNs, and thus need no translation.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 08 09:17:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 09:17:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979116.1365812 (Exim 4.92)
	(envelope-from )
	id 1uCxNC-0003Ug-LG; Thu, 08 May 2025 09:16:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979116.1365812; Thu, 08 May 2025 09: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 1uCxNC-0003UZ-IW; Thu, 08 May 2025 09:16:58 +0000
Received: by outflank-mailman (input) for mailman id 979116;
 Thu, 08 May 2025 09:16:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCxNB-0003UT-7J
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 09:16:57 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20613.outbound.protection.outlook.com
 [2a01:111:f403:2412::613])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2ecd68b5-2bed-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 11:16:55 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by IA0PR12MB8745.namprd12.prod.outlook.com (2603:10b6:208:48d::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.20; Thu, 8 May
 2025 09:16:50 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8722.020; Thu, 8 May 2025
 09:16: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" 
X-Inumbo-ID: 2ecd68b5-2bed-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HmpHCqE5HWReDcnCubkbsV1HVjJl1ux2vRRn0/osbJ0k45MmtDzhyCCJagEGwz2437HBw+4wO+j33Lx9utPlmsDImG5bL0A6XtKh3OhFENmC5G2mL58Q6Drs82FLLT1tf5/eEdSDJJWKVNXdAFFGGNNmbYvPoh7hnvqgDr8MjgGyROOlyFFhKb4zI/9/DXg9hpWRmv4DdscBCKaP1LV377pteBAEA4RAy7JL0NKuFHBmTITIB5oZnydbn2WL38Em/hpNUJDyljHqceTSnbedCO4v7xX5GPwMxqhX+voGLKfQoMh6/Mwqa25xcEd+pUb+qu1D0e7IEZVCptqRo4870Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+h2FORUlvcPIlretBNSWEat6brs4D4xB3UI9dgNI70c=;
 b=IHGDG1axrLyiEmMthb4ucj+3nAWJsx1yCL6Hr09Ri2y+VEwmHcBuzTr/HG+Zz3e2sjO6tsmObIJr93d7LuAcQEB8fnYDngmun/GWWhb+Xij6pMEWjcfgWHlPPVMefcjf1VB9SVQjzGq2D9x9GQlilGAXucz3ltPE3hNRVnpgU3EiPL5l8r8K7Ra5k03hv3MBAcj206B2nO6UFGOUD7Dg96oHjoCgVBlUO1A7Qe6vKYkro2TZzlXsWs0UUyxTqMRgFTY0dSS+byqNM/okVBKqbqgxTFxO1nTRc7BxUqPlGJgcWsIu3UE6WEepNPtBMcQBVA/HPp9jZOYaObFUu7BIVg==
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=+h2FORUlvcPIlretBNSWEat6brs4D4xB3UI9dgNI70c=;
 b=jddZJfm3rjOMxgtUltDw8rn0QcbkvAGQokORrtBS+gon0cneAZDqygdIBkcEf6Wd040R87m5F+IW+X3bFRwtyVF8MWygXCD8AVt23zX83BMDUXdxq6XSiLSvSNkxJ4B39ElJ9fWIclRt634jz9lWqy23erkCiWFGh2zxBFPyf8Q=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	, "Chen, Jiqian" 
Subject: Re: [PATCH v3 07/11] vpci: Hide extended capability when it fails to
 initialize
Thread-Topic: [PATCH v3 07/11] vpci: Hide extended capability when it fails to
 initialize
Thread-Index: AQHbsoVd9OkTHNIeNk69huFsDqzHMLOv3AoAgBk3cgA=
Date: Thu, 8 May 2025 09:16:49 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-8-Jiqian.Chen@amd.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8722.017)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|IA0PR12MB8745:EE_
x-ms-office365-filtering-correlation-id: 77e10879-539a-42b6-40d3-08dd8e111091
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?L1hsRytzZ2pFUHdYcGkycGFpQ2gySkQ3WnFZZG1HT2M4TlhlaHZLNHpOMFlO?=
 =?utf-8?B?eUh4ck8zbWpzTyt6SnpTYWZYUS9MZFBBL2U2YWs3VlVTbTg5cnRUa0M2NkNx?=
 =?utf-8?B?WHJlV2ZFTG4vclk3L21FeGo4UjFtdTVNQXhtK3NUKzNrL0JmanRmc2FlQWJO?=
 =?utf-8?B?bXllT2szWkRqY3h2cC9RQVh3bjF3K1NIQjE2TUpLN0hwTngvOFZEVUtvRFBJ?=
 =?utf-8?B?MEd3TldoZmFuL2hoYnh4ME9Hd0pTcVI1QmV1MGlrRFpLL2pmRzJOTzVXeGw3?=
 =?utf-8?B?MUVXektWZWt2bUZVQjdwbnhhaENXa2JaUUEzTmNmRUE1MjNXcnFveFdPenNG?=
 =?utf-8?B?bElwQ1dMc0c0bFNiN1F1Y1g3aFErbmVlcDdvNjNGbUFyVC9HT1ZoMk1FVjhJ?=
 =?utf-8?B?QklmQWpQZVN5Y0x2ZFF5bElhZURPeUFkNHh6OWdmN0F0aDJzVVRvQWdtWUJJ?=
 =?utf-8?B?RlhjQkxxbHl6cUx6TW9kK0NQSElOTGpwU1gwVkQ2QmlOenRSMVdzcVg3TzlK?=
 =?utf-8?B?dk40OTJtSlJjRkVGUEVQZGNOc3R0SDZuQXVKSDRXT2VCZGJZNlF2MFdjaDFU?=
 =?utf-8?B?aHBzY0RYVjNGeWd4b0NteGp2d3RTVUt6eGVDV1c2Qm9BTll0SGRlMFE4djNR?=
 =?utf-8?B?cFVzQW9iVFM3S2xsaDdSbythSlNRSTJGRDlFZGRaRUg1aFFZenBPck51R1VD?=
 =?utf-8?B?NXFyYjV3WFU3YzUxR3Q3T0JXbCtmYjRGSnIxUGZxckErUldFeG94MWNKdWVK?=
 =?utf-8?B?MlBlajdBZnE2WW9vTmI5WmlLNFpoclFDMVB4YUFtNmFWUlFJS0Z6V3pJN0cy?=
 =?utf-8?B?QVcvMDBUbEFCTWs2ZjVobFpJdk1IOS8rVWEyQ2dTMGNXRVZ2Q00zZkR3dW90?=
 =?utf-8?B?R1A0OWVGcXk3d3ZtZjlWMFlCZzdlT1haazdpUU9ORC80ZUkvSjJaNldKSkJE?=
 =?utf-8?B?cWtLNjZ2V0JLcHh1RHNGVDFsWnZNOGhJZGZCOUJBV1ljUzRlakZOUUF6SUZ0?=
 =?utf-8?B?NGwyNHpaWG53cmxiRmNiSGM1UTh6azdkbVQwd3ZOWjYyTnpCM1E5T1hOOFlW?=
 =?utf-8?B?T0hRVUpSMks3VlAvK0NRdUlyZHpoK0l1Sk9nSjF5UllyNTVEVHFhU2VCOHNh?=
 =?utf-8?B?SVFaOXcrTUdUbThod1dZeUNPOUNSTk5mb2NMUDl0a2dCelc5OXhTaFNENWJ3?=
 =?utf-8?B?Rzc4MFNpaEZ1dzVCZlNhN1lqK085TWNXV1YyTnVSc1FDZzV0dFFqT0NDcERp?=
 =?utf-8?B?bVQ2bDRiZTVmMUFmcWRtWGh5U09uT0xHOHhRbmhnYllvSitGMCs1MDRCS1dN?=
 =?utf-8?B?UFRWVFg5bWEzK1FkeXBiUlFTM3EyTVJna0w2Y056Qm43eUNuYjlDK1NmeGY4?=
 =?utf-8?B?bklPWE1HeW9ZM3hyRm91VlRWcEpRbU81cmI0RFhYQXBlTllPbDNlUjF6RDFo?=
 =?utf-8?B?TTRGTDVzaW44TUNTNC9qL2sreW1PQ3QyYUl3SHBVQ0VlSUs2Y215dlBTVlFs?=
 =?utf-8?B?MllyOGdCWUJ1VGQ0NFcySTZhamxocEduYUprR1NFa21kWTd0RnN0RWtncmIy?=
 =?utf-8?B?Q3NucjdJM0d0ajYxZDQxRlY0bkVhRGlKclVPcXJ0U05iaVNMWStIdXU5ai81?=
 =?utf-8?B?VXgrSGhadG1lZFJlM2htKzgzcENlU0VNZGpKU25TZTRoTlQ5UGR1dnJtK3Rk?=
 =?utf-8?B?amM0dEVaK2dCUUtzeW5lMG5RQXRyaklzamZBR2RKNGc5SEl3WllDZXR4OHYv?=
 =?utf-8?B?SnB0emlKUEl3MGJ2UkFmMFhXVDVUbCtHRXgzK0IrbjRBcE1IZHFxTHN6TjR2?=
 =?utf-8?B?b3JMRkt2RDBJMzNla1Bpazlla1Y1Q2M5dldEN01vODF1WERzaVU1cERlRTYv?=
 =?utf-8?B?STVGZ1VsRzVXR3dGR1FKZnpuS1NqZFNuaGdDT1JsQmpJbUVneVV5Z3ZsSmNJ?=
 =?utf-8?B?Wkw4a1VTUTQzcGUvUWlCV3Q2RWVFMU5GVURPb2wxeVl6Wk1yUXdOdlRVSmdI?=
 =?utf-8?Q?+xWh5ivowRbjv3N8ihe/9v5UNTKvnU=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?b04xd0R1elh6YXlrckx0aU0yVTNxaXY5d3hRWE03NXdIU1lYKyt1ZmQrdXhq?=
 =?utf-8?B?T2NjRVBLM1NvSU1jQW9INFpOMkY1MVZuaWh0YXR5WU1VaGMra1dLZVo4ZlV2?=
 =?utf-8?B?MHdYcHBpRHRWbElDajNISnJOeFRUaTY0cHgvSnlzYVNTRFRjSmYxdmVJZDVy?=
 =?utf-8?B?aHc5R1VENEI0R2ViOENpTDhsSnJGOTAwd1pYRmMrRGY2T1BoUUFrMW83QTN6?=
 =?utf-8?B?eWxuajF4bi9ROUcrUTJhRHMwQkdGYTFmdTJKZ0p1b2ZvWnpHdzJ5NDhHalRr?=
 =?utf-8?B?TWs0ZU95ZzVkUzlKUkZ0SFFqdU5Nd3FMYmVWTTBER1dhS2RKVDZkTkpoOFFn?=
 =?utf-8?B?TXc5OFptcGc4RlczazI0MjBGQVp0TUV3TlJ2cE1Lb3RESk01MlU3TW5sR0FF?=
 =?utf-8?B?dTVkc2FkOGhVMkJieUtnamVXQ29JcHNrOS9XZjBuOHdHdDl4QlA2VWNqMlEr?=
 =?utf-8?B?Y3A5SktqNDFCR29yVXc0dVZNWHRvSi9GYUd5cDlqT2U0eG45WmVVMFEvTy9T?=
 =?utf-8?B?ZGg1RmU4SnQvdHdBY0xDNnBjYXpmUkdOVlpIQzBkL3Q3UThwdkp5MENIcWxp?=
 =?utf-8?B?OUg3eTArRjh2Z3JwdVllNlZKd29Nc1BaZFBVS2xBR2JkQWdseTJmQTJCa2kz?=
 =?utf-8?B?ODZUbGpYYjlibmcrRHYrK25WN2gxRWJ0elluUUs5OXc4YTJxcDA3eXBmN3Q2?=
 =?utf-8?B?dGF6eWhndVdHNmh3Y1JRNjBoUjlTeXdMUHljcDNvclZxRS9yQnhjWUpTZHls?=
 =?utf-8?B?Y2NRRkVrdG1IN0RINlBYZXA4QWpOajhLQmJQN0VkWmNPRXhEMG0rSU5ZWm9W?=
 =?utf-8?B?QTdGTVh6M0sxQ09udmhDdkcxYkhiU3BpWkdVRUhrSlE1TmpNczBQaEwrSGNO?=
 =?utf-8?B?NWxlWWZzNHJ4TStrbDRvQndsbzAvSWRBK3M4c2dyMFljemVsWVE3ZnVQbHZk?=
 =?utf-8?B?bmx2dHVubzFzT3I3RE1mMldmNGFEem1RSUJjcExTKzNUV0QyNzhVV09ZT2E5?=
 =?utf-8?B?ZWQ4UDc2d1ZmMUZob2NJbmNJa3dGWGthN05RcWpqbWd6QkdTUnFXRWtzZVNy?=
 =?utf-8?B?azJiNm9VWG1lWXM5aldLekJDY0lRaWZ4QjBwR2Y5WmVYZ0xDRTVISEFHVlNt?=
 =?utf-8?B?K01RRXc2MERkS3ZrWW1SbzBLMmY0dUpkODF2cFNKMGIrNHA4Y2ZCM3FHYVRi?=
 =?utf-8?B?eDFxUjcxeFNoWHZkck9uQkJDemV5SHRkZnpsWDdka0FLSWRZcFEvM29hQXVT?=
 =?utf-8?B?d2NpU0p3VGg1RlptZll5cjJ6ZWVJOUl1TkFXNkU5TGtSRnlHOXU4ekxKUnVa?=
 =?utf-8?B?RlpCVUJSTENObWlvMVd6ZU5pdWd4cml4UkVTbmhvdVg0WnVPTzBlLzVyUXpu?=
 =?utf-8?B?VkQ3S285cnJYVUlDay9sYTZCSGFwNHc1T1FWTWg4YlZMek8wZm9CWVlIZHV6?=
 =?utf-8?B?VCs4cGdNSytwRHJQRUJkOWJRQkw1bGYvaGV5dFppNGJEYTZRV3E2WkR2YlRn?=
 =?utf-8?B?c3NSZ0Z5QmJiN3hMOEdrQlpJRGNTQmJ0T2pFdnUrRE1sRGIzQ1lVaUc5OWZD?=
 =?utf-8?B?YVdhNHRqamV3N05QRENSZXk5aVh6dllCeW1XMy9kb1dRZHB2RTNBTElUUlNZ?=
 =?utf-8?B?MG9LWUNJcWR4cGdVcXhxWGIwNWwxT0dvY3A3Nk5aR0l3V3NVNTByYkQ4K3JB?=
 =?utf-8?B?Y1M4WUtGbkpPQ1VGZGdlVEhQdGwwSmU4NHJQc0VBbjlSWmtGK0t2RERxMHdm?=
 =?utf-8?B?OHYzRkFheVkyQ0VjOStSSUZOWjhHV0dhV0FxMnB5dkdERGlTRzYzdGFpWHdj?=
 =?utf-8?B?bFI3N01KY2xPTFA4eVgzSW1pNjJzUjJReEw1N21IcHVGTm0zaTcyNWtPT0hC?=
 =?utf-8?B?RTdlRTJ5L09hYzVGYUVQc1FsNjB3VXNEYjRCS2loenJCNmRhQjhraGdodHNJ?=
 =?utf-8?B?M2sxaVM2WktUKzY5NGJGcmpUVWZhUWRRQkNqNmVQejRCYU5XcDZNN2gxTFJ2?=
 =?utf-8?B?REExYXZWaGltZHlDL3VvRnBLK0tCM2MwNURBTzlMSWRhajVxZDArb3p3OE9r?=
 =?utf-8?B?NTFObWNKeE5DNUlLbmlKS2x5b2I1TWdPcUQzRzZZRGFjVVFzaUdNeVZRamFN?=
 =?utf-8?Q?q15c=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 77e10879-539a-42b6-40d3-08dd8e111091
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2025 09:16:49.9655
 (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: XZfszncdCnpNkykCmYDp7eqF65lAdxx8s9k7G+IredD+dKfisKj5661EKsWV3RtEmPaRdIG61nQ4EnrolouITQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8745

T24gMjAyNS80LzIzIDAwOjA2LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjEuMDQuMjAyNSAw
ODoxOCwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiAtLS0gYS94ZW4vaW5jbHVkZS94ZW4vcGNpX3Jl
Z3MuaA0KPj4gKysrIGIveGVuL2luY2x1ZGUveGVuL3BjaV9yZWdzLmgNCj4+IEBAIC00NDksNiAr
NDQ5LDcgQEANCj4+ICAjZGVmaW5lIFBDSV9FWFRfQ0FQX0lEKGhlYWRlcikJCSgoaGVhZGVyKSAm
IDB4MDAwMGZmZmYpDQo+PiAgI2RlZmluZSBQQ0lfRVhUX0NBUF9WRVIoaGVhZGVyKQkJKCgoaGVh
ZGVyKSA+PiAxNikgJiAweGYpDQo+PiAgI2RlZmluZSBQQ0lfRVhUX0NBUF9ORVhUKGhlYWRlcikJ
KCgoaGVhZGVyKSA+PiAyMCkgJiAweGZmYykNCj4+ICsjZGVmaW5lIFBDSV9FWFRfQ0FQX05FWFRf
TUFTSwkJMHhGRkMwMDAwMFUNCj4gDQo+IFRvIGF2b2lkIGludHJvZHVjaW5nIHJlZHVuZGFuY3ks
IGltbyB0aGlzIGFkZGl0aW9uIGNhbGxzIGZvcg0KPiANCj4gI2RlZmluZSBQQ0lfRVhUX0NBUF9O
RVhUKGhlYWRlcikJTUFTS19FWFRSKGhlYWRlciwgUENJX0VYVF9DQVBfTkVYVF9NQVNLKQ0KV2hl
biBJIHRlc3RlZCB0aGlzIGxvY2FsbHksIEkgZW5jb3VudGVyZWQgZXJyb3JzOiBldmVyeSBuZXh0
IHBvc2l0aW9uIGFkZHJlc3MgbG9zcyB0d28gYml0cyB6ZXJvLg0KVGhlIG5leHQgcmVnaXN0ZXIg
aGFzIDEyIGJpdHMsIGFjY29yZGluZyB0byBQQ0kgc3BlYywgdGhlIGJvdHRvbSB0d28gYml0cyBh
cmUgcmVzZXJ2ZWQgemVybywNCnNvICIjZGVmaW5lIFBDSV9FWFRfQ0FQX05FWFRfTUFTSyAweEZG
QzAwMDAwVSIgaXMgZmluZSwNCmJ1dCBpZiBjaGFuZ2UgdGhpcyAiI2RlZmluZSBQQ0lfRVhUX0NB
UF9ORVhUKGhlYWRlcikgTUFTS19FWFRSKGhlYWRlciwgUENJX0VYVF9DQVBfTkVYVF9NQVNLKSIs
DQpJIG5lZWQgdG8gY2hhbmdlIFBDSV9FWFRfQ0FQX05FWFRfTUFTSyB0byBiZSAweEZGRjAwMDAw
VSwgaXMgaXQgZmluZT8NCg0KPiANCj4gbm93Lg0KPiANCj4gSmFuDQoNCi0tIA0KQmVzdCByZWdh
cmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Thu May 08 09:39:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 09:39:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979127.1365823 (Exim 4.92)
	(envelope-from )
	id 1uCxic-0006iT-Ak; Thu, 08 May 2025 09:39:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979127.1365823; Thu, 08 May 2025 09:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCxic-0006iM-7n; Thu, 08 May 2025 09:39:06 +0000
Received: by outflank-mailman (input) for mailman id 979127;
 Thu, 08 May 2025 09:39:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCxib-0006iA-8C
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 09:39:05 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4705909d-2bf0-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 11:39:03 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-441d1ed82dbso6954085e9.0
 for ; Thu, 08 May 2025 02:39:03 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a0b1e8e8d8sm7486647f8f.33.2025.05.08.02.39.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 08 May 2025 02:39: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" 
X-Inumbo-ID: 4705909d-2bf0-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746697143; x=1747301943; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=k7zPBllM2SlFbl2BIom7VfF5dqUW8z6qXYYDQj57i9s=;
        b=rNEdZoPT2kvxwd96/sWQc7/OIWJgPVhXlu+c26uxnrIBFDoRH+Jyd2mlhEmf5xxynv
         DyEekBNY3uBLeEQ6nfkqRpMxa4kJ6AizKCODODWTXjCn1AMogUBvjkfbllXkqCC+U08L
         B+b/emfp+bNnIvCB9AvORV8cgfZCGN3VNyKLY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746697143; x=1747301943;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=k7zPBllM2SlFbl2BIom7VfF5dqUW8z6qXYYDQj57i9s=;
        b=T2BzPHCzL31aqkgQi0i5TuKnYpqmRya3mMbsKtOM3OV8J4FWBKw019IA7u34jdOvL9
         5df5faNZLtnKQamdxuXXBkFSQ2W09jU7F4+YpEDlMm67WV2pkekhRTGCyISSJd66rN+1
         iovca6HdM2LH+HjevREPCOkU7A9PNJpbhbwg/18A+hivtJ/yh+fn/SEO46jq6rXmi2hT
         xR4An67HZMirSIrtlaLxLoeytJDKIgCZWVkFAMQ0C3M+5h2V9972GOjgZ/C5iTSC08T6
         0Fg9kQAb+lK2M7nCn5pTwP5LQuKX93HdKN5toLcjf4VPfqH+xYo00McGhMHiO4CMdlFV
         A9DQ==
X-Gm-Message-State: AOJu0YyTRHXjqhFIq61pb7y1tYVkcsxFXAGW322LoNB9cuE5Ad5P2sk3
	SpKjlfLZfBe3no0bKaEOtYa6X9KbKGa2i2Ih91QyVGHtiQMvhApFAxBSS0bb1RDgo0EOicSXlOO
	T
X-Gm-Gg: ASbGncvPoFeUHy5z8bQHzoTeCeI1XBnFrxQuzW7BJlcdVd5zXLH6irWajBKKhuu/f3A
	5etvsaaq8jbQ4u6tKrPgRhKkaY0CmNqEUHetGsmYkRyiYXHCmazEaHXm8MohuNN2Ly3F6x3BMhZ
	xmRyYdWK6LTd+Puli4tCzOrVJGCuZBryWPhXT9DpUKCt2ymYj2Q4k3I3BSZxmNg8s/Rjml2A7Za
	WEOi7D0ceintxQeff6Poxa7uCkluXUK1GOnB9xKCCvxAO+09QWX6uW0icFePl0ZuNjTuoLvkMAH
	vl9XGYBQUtjGtwzF/Nz/QwuMs6QziFI3P2YtS5gOc9GdHw==
X-Google-Smtp-Source: AGHT+IHrHUEPwakUdEDcvfpfbIomDrlQykf5nQAxJOzRyZKSrLx9LFFFH9Jws5LMqDDx9nZZ8rvA1g==
X-Received: by 2002:a05:600c:a44:b0:440:6852:5b31 with SMTP id 5b1f17b1804b1-441d44c3395mr60715665e9.10.1746697142749;
        Thu, 08 May 2025 02:39:02 -0700 (PDT)
Date: Thu, 8 May 2025 11:39:01 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v3 09/11] vpci/rebar: Remove registers when init_rebar()
 fails
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-10-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250421061903.1542652-10-Jiqian.Chen@amd.com>

On Mon, Apr 21, 2025 at 02:19:01PM +0800, Jiqian Chen wrote:
> When init_rebar() fails, the previous new changes will hide Rebar
> capability, it can't rely on vpci_deassign_device() to remove all
> Rebar related registers anymore, those registers must be removed
> fini_rebar().
> 
> To do that, call vpci_remove_registers() to remove all possible
> registered registers.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> ---
> v2->v3 changes:
> * Use fini_rebar() to remove all register instead of in the failure path of init_rebar();
> 
> v1->v2 changes:
> * Called vpci_remove_registers() to remove all possible registered registers instead of using a array to record all registered register.
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/rebar.c | 35 ++++++++++++++++++++++++-----------
>  1 file changed, 24 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
> index 026f8f7972d9..325090afb0f8 100644
> --- a/xen/drivers/vpci/rebar.c
> +++ b/xen/drivers/vpci/rebar.c
> @@ -49,6 +49,26 @@ static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
>      bar->guest_addr = bar->addr;
>  }
>  
> +static void fini_rebar(struct pci_dev *pdev)
> +{
> +    uint32_t ctrl;
> +    unsigned int nbars;
> +    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
> +                                                        PCI_EXT_CAP_ID_REBAR);
> +
> +    if ( !rebar_offset || !is_hardware_domain(pdev->domain) )

Maybe add an ASSERT_UNREACHABLE() here?  I don't think we are expected
to get into the cleanup function for the capability if it's not
present, or if the owner of the device is not the hardware domain.

> +        return;
> +
> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
> +    /*
> +     * Remove all possible registered registers except header.
> +     * Header register will be removed in mask function.
> +     */
> +    vpci_remove_registers(pdev->vpci, rebar_offset + PCI_REBAR_CAP(0),
> +                          PCI_REBAR_CTRL(nbars - 1));
> +}
> +
>  static int cf_check init_rebar(struct pci_dev *pdev)
>  {
>      uint32_t ctrl;
> @@ -80,7 +100,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
>          {
>              printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
>                     pdev->domain, &pdev->sbdf, index);
> -            continue;
> +            return -EINVAL;

-E2BIG might be better here.  In general I try to avoid using EINVAL,
as it's a catch all that makes differentiating error later on harder.

>          }
>  
>          bar = &pdev->vpci->header.bars[index];
> @@ -88,7 +108,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
>          {
>              printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
>                     pdev->domain, &pdev->sbdf, index);
> -            continue;
> +            return -EINVAL;

Maybe -EDOM here?  -ENXIO or EIO might also be appropriate.

Overall looks good.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 08 09:43:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 09:43:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979138.1365833 (Exim 4.92)
	(envelope-from )
	id 1uCxmf-0008TA-QU; Thu, 08 May 2025 09:43:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979138.1365833; Thu, 08 May 2025 09: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 1uCxmf-0008T3-Mr; Thu, 08 May 2025 09:43:17 +0000
Received: by outflank-mailman (input) for mailman id 979138;
 Thu, 08 May 2025 09:43:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCxmd-0008Sx-U4
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 09:43:15 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dd22bf5c-2bf0-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 11:43:15 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43cfba466b2so8556715e9.3
 for ; Thu, 08 May 2025 02:43:15 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a0b7fc0f41sm3214151f8f.74.2025.05.08.02.43.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 08 May 2025 02:43: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" 
X-Inumbo-ID: dd22bf5c-2bf0-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746697395; x=1747302195; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=g7XJZtX7d2fBhCQyjmnC3NIGfpgEqEEMYg24s+N/lO0=;
        b=ejm6OK63YJw9+F6nDuBxfOq7yONKzc2N4kuzpY/rC10OX+kfPkmsRWNe2vxjzGnnJE
         TvrQiVwW1UZ+01ny2IMupYh0Y+H+Vfbb0gFUARSNIRksljaCJMZ0QXbYn9JaXln4i6gQ
         CrR7wb+WdigX/338KGElG0XcSY7dGPK2FyHxo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746697395; x=1747302195;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=g7XJZtX7d2fBhCQyjmnC3NIGfpgEqEEMYg24s+N/lO0=;
        b=uVDaHRbIveZUG5f7TEl8Oi1rHG3iyDhbHH2YV/Z5d2wbh12TxhlM3JHsGi5mnM/bd0
         z09IVsWPEiHlLyv7uUDbtfSQy0FwJX29v6zOjvJcw1ANxXY0DmuCxdYGiCGowaKY+Ioa
         M+yGMfYiuNxYLKt3sFidROQ+p1kjexoFR9/ExSIZRFKn6TvwHBF3EhiU6wO8MIX82TQT
         fkWI54zT/I+r6X0xMTSeVyR3pXdRPzjLMDveI/YsjQunG7bds8bLPKvEgHGnyR/Y6jNW
         ImsTixxQybGVSZAbFd5QQmbszLIcbXbu6Wb46sI/AHeZ1nzTmwulWxTp2gnOgHq9nE6R
         U1+w==
X-Forwarded-Encrypted: i=1; AJvYcCVDhBrtbPwyBYXM6J4urdEvISdMgLCXbF7o1dNw4+YgB1yR10CZ7PCdXr60PF2PvkVXq7SxEsqZQ/M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwjrJdcLrrMWWRk65gy8odMowN19Qu4ar1XeQV23paUoLY9aPrg
	xDk/FsN1aw/mAMaB0RcdzQCabwKxL/5J+5XlEIQtov1X4QE5ghVWu1R65OAYNvI=
X-Gm-Gg: ASbGncsb58+sCGGmdZKRir3eE8U3J88AYeonv8e94DMYVEFBo45cNKZLkChLTasUM8J
	tnrTfBlmPtCe98DyMF3UEjaJO7prJdUWnaHPBThhT3Z1MxnPqLD9pg8UZBDsZ/F9ED+UwwUiA7r
	3jtk/c94lKPsYPO4QDXx1ZKreaJh4yDdQG2NYUoU9N8sQacXLgS6cmu4OCpQN0zriVvmFKPFzQU
	Bdzbbxb/qGufekttIe6ncXM6AUYEDnqraURMC1LuDuY71FvaLD9UHkWthoFymK47zfZkX/a1ZjA
	6KYrOUtaXQvdFAnr07z5xMNdDyT6YJ92kpObDM1AtP1gg17iPXrObOmAiQSE6uviPMZ+W8O7lGa
	KAsa59w==
X-Google-Smtp-Source: AGHT+IFA01GxMlFDu/gLMDoqYtB9BrskE+3+TATZV+DCqF7GSNJkW1lA5yPWHsEnbHlwIHRmGTA3LA==
X-Received: by 2002:a05:6000:4312:b0:3a0:ac3f:cdb3 with SMTP id ffacd0b85a97d-3a0b4a1cc14mr6265004f8f.22.1746697394705;
        Thu, 08 May 2025 02:43:14 -0700 (PDT)
Message-ID: <1aefa7da-7f90-4163-b9bb-78b9f98099bd@citrix.com>
Date: Thu, 8 May 2025 10:43:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] lib: Add strcspn function
To: Kevin Lampis , xen-devel@lists.xenproject.org
Cc: Ross Lagerwall 
References: <50a2737a-611a-4d83-aee6-de23619b0b6b@citrix.com>
 <20250507144515.1704100-1-kevin.lampis@cloud.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: <20250507144515.1704100-1-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07/05/2025 3:45 pm, Kevin Lampis wrote:
> From: Ross Lagerwall 
>
> This will be used by future patches.
>
> Signed-off-by: Ross Lagerwall 
> Signed-off-by: Kevin Lampis 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Thu May 08 09:47:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 09:47:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979150.1365844 (Exim 4.92)
	(envelope-from )
	id 1uCxqQ-0000cK-9F; Thu, 08 May 2025 09:47:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979150.1365844; Thu, 08 May 2025 09: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 1uCxqQ-0000cD-5L; Thu, 08 May 2025 09:47:10 +0000
Received: by outflank-mailman (input) for mailman id 979150;
 Thu, 08 May 2025 09:47:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCxqO-0000bL-TY
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 09:47:08 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 68024267-2bf1-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 11:47:08 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43d07ca6a80so3457525e9.1
 for ; Thu, 08 May 2025 02:47:08 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099ae3bc0sm20099131f8f.35.2025.05.08.02.47.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 08 May 2025 02: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" 
X-Inumbo-ID: 68024267-2bf1-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746697627; x=1747302427; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=L3xZk/rILM/7PDy0v9j5+YFn7jSJIp7QohOXIDNIcow=;
        b=KwHGSLMWSG/93aVLe+kZkAnnuWpqVwHf++D7CQJBPtyxMb3HewVakbIA1oiylveCRr
         IeJLRLve0xYMeKUYa/4ah0nnzENlKy1hh9hJXiY83Ig9GTjewHMfzi3bqsbb7VAeoyaG
         VheJTK1be/wPo6vSI6ZMiWIBrjAPTNDLE6nKw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746697627; x=1747302427;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=L3xZk/rILM/7PDy0v9j5+YFn7jSJIp7QohOXIDNIcow=;
        b=qBaPEK3vozDRiDY/j89QQ8CjycDOOYeq3ycGJHL2l6g5PyWLy4NDtbH4mwHoi1e4oi
         YioufCRPU2CYlPvgbuoK1bKkgiWScutv89xmljcbDTM3CfVZf7MVUtTOhfnJy1hG8Dd+
         0Qt4Ai3OwgGajkKUe1FzHFH+IuwqR/8izauqAFINj0iEuBh9l0YmGazoXXuZbr5hboqI
         ta8m/gSA9DLBv/kUKNxv6axNRMd53mD6tfKY3qEMxxLbbB4Un0nCaOZ1BmbD0cvRQkw7
         Wlz6UNZwz++YlTClt3ltY6plhTiAEZUfgWJix1xBhp0wBPQSUlYnsUw7yiOrP1gTI/Kd
         0hQw==
X-Forwarded-Encrypted: i=1; AJvYcCXwjrNJLY9h9mCX3jujJE6IP0UCVD26ufftpOpUGkE+iL5p97B36pqud4gImgidlmsuN3oqVj6rVDM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw3BrpaCu/ExEK9ym37REybJuqql+oVBsozDgkiXl/cJ41OA9HS
	ANCl+HksQTy3MW9s6sWXiG1Ra/RYh+keQyNYlBP7d2q3yX96lMhW2PJuMnVrLtE=
X-Gm-Gg: ASbGncvxj7mUTDPI9dx9dMiVF2m4941TFhrnLlNcr8DvSfnK0MpKF1llQSs5Y1Lk8xn
	cA370iDRb1P410EYQyixnZWPzuXie8VY/n5ygmSOdIeoHwaKfRD10N2LbPjf7yLs2HdgxoAgUYX
	klq/oBc6mhS9ecLOoC6h3Rmg48/Bwh/VC73tSe4eNflmCiX21ekj70PmJF5i8EuRsQ1nApDnKAv
	HqE9raT6D027et7kyyxa8TkWP5Pthw6MlBuovm4uV23r1NYJxseZ8/OIwDZVmzgbkU8mwQ4Vpkh
	MP9nngtZILc+ZfbqRASnuPsaQWaXE2xT8ZcoBgbuejKcbQ==
X-Google-Smtp-Source: AGHT+IEYjWHSrdH6LOH9Ne5hPipacuHqdkm8/QDz/4y6RvMjCwMqVnn/qkHjPOVrqiMJJpgvZATSNw==
X-Received: by 2002:a05:600c:8716:b0:441:b3eb:570a with SMTP id 5b1f17b1804b1-441d44bbf09mr58850545e9.2.1746697627636;
        Thu, 08 May 2025 02:47:07 -0700 (PDT)
Date: Thu, 8 May 2025 11:47:06 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: Jan Beulich , "Huang, Ray" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v3 07/11] vpci: Hide extended capability when it fails to
 initialize
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-8-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Thu, May 08, 2025 at 09:16:49AM +0000, Chen, Jiqian wrote:
> On 2025/4/23 00:06, Jan Beulich wrote:
> > On 21.04.2025 08:18, Jiqian Chen wrote:
> >> --- a/xen/include/xen/pci_regs.h
> >> +++ b/xen/include/xen/pci_regs.h
> >> @@ -449,6 +449,7 @@
> >>  #define PCI_EXT_CAP_ID(header)		((header) & 0x0000ffff)
> >>  #define PCI_EXT_CAP_VER(header)		(((header) >> 16) & 0xf)
> >>  #define PCI_EXT_CAP_NEXT(header)	(((header) >> 20) & 0xffc)
> >> +#define PCI_EXT_CAP_NEXT_MASK		0xFFC00000U
> > 
> > To avoid introducing redundancy, imo this addition calls for
> > 
> > #define PCI_EXT_CAP_NEXT(header)	MASK_EXTR(header, PCI_EXT_CAP_NEXT_MASK)
> When I tested this locally, I encountered errors: every next position address loss two bits zero.
> The next register has 12 bits, according to PCI spec, the bottom two bits are reserved zero,
> so "#define PCI_EXT_CAP_NEXT_MASK 0xFFC00000U" is fine,
> but if change this "#define PCI_EXT_CAP_NEXT(header) MASK_EXTR(header, PCI_EXT_CAP_NEXT_MASK)",
> I need to change PCI_EXT_CAP_NEXT_MASK to be 0xFFF00000U, is it fine?

Oh, I see.  You might want to do:

#define PCI_EXT_CAP_NEXT_MASK		0xFFF00000U
/* Bottom two bits of next capability position are reserved. */
#define PCI_EXT_CAP_NEXT(header)	(MASK_EXTR(header,
					           PCI_EXT_CAP_NEXT_MASK)
					 & 0xFFCU)

The spec says:

"The bottom 2 bits of this offset are Reserved and must be implemented
as 00b although software must mask them to allow for future uses of
these bits."

So we need to make sure they are masked.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 08 09:57:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 09:57:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979167.1365852 (Exim 4.92)
	(envelope-from )
	id 1uCy01-0002YA-5m; Thu, 08 May 2025 09:57:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979167.1365852; Thu, 08 May 2025 09:57: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 1uCy01-0002Y3-2s; Thu, 08 May 2025 09:57:05 +0000
Received: by outflank-mailman (input) for mailman id 979167;
 Thu, 08 May 2025 09:57:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCxzz-0002Xu-KA
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 09:57:03 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ca5670be-2bf2-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 11:57:02 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-441d1ed82faso4998625e9.0
 for ; Thu, 08 May 2025 02:57:02 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442cd3aeb26sm31854645e9.29.2025.05.08.02.57.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 08 May 2025 02:57: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" 
X-Inumbo-ID: ca5670be-2bf2-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746698222; x=1747303022; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=9J6AapbB5p8N5JWDeXHjhdLLqIsTHgOEjGtuldf41eE=;
        b=m2Gq7Mr1yd/LCGeB8rW4bJtcznF8+ds2IRE8EygyEfK0188KwDPCv3qVrK8rCtH0zZ
         4gtA+s1zOtf5/WSxIi9YJJfAOphSa5tzBrc2eE+8nY516xVIaC62gbobr+mF77IZQMtp
         SFZo/mROkwu98Ll1Queplfpdj4TS4QqDo6TnM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746698222; x=1747303022;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=9J6AapbB5p8N5JWDeXHjhdLLqIsTHgOEjGtuldf41eE=;
        b=Q/KGkvgXbpRHhEzki7zJHUPd5qL+ygf3qp7L6fir9rLlx0UqjXlLsE6Y0dkhc1yUIY
         NeRNDf3lhq3kqmCMDzkIUG8iUyrwZ/IpFA6hNCOHu0ZQpBSPhtSNUsLQVIprmz//iz2j
         M1VDh0cBTlL2NqWYt4Duo61xKJva4W658G3Js90+YlzpWxsmHX1l8bDJHOp4463zOvlx
         poUmJp+3B+At3gcDImznTUdygPTRZajxpplyMga5gcXL7wO/3lKwgtERLiQ6xsA8crpR
         7wVy5K0J+TtBiDUAboFKMvms0vLoTkmOwXgqWM6DaERvohbM2O6Y/+QP3/cpTJzw++Na
         dBww==
X-Gm-Message-State: AOJu0YxUmfmPqMp1BpJCRiSzwWIjBXNIPrBA4CP4XI4GWBBaYt5L1Z0F
	DW+iYzCgnCrH64aBa1UOF/2zf5FcIadjyRhpP9ehgD9eHWNjIVyPOr0QKJdHZnhv6twDRSINh9k
	7
X-Gm-Gg: ASbGncv6dB5nPq/n/oSBO1svsuslUsy5HHtdnYVdk8H50CHHuErAX4o21Ln/RUcKPgW
	HJrdOq7qURToidsgJbmot8qHDyAAUIjZGWkaDk649WobDPhqBWbDUOhqDPLZiJV+UsfXFWAJ79S
	jJmGV5wvXo1XVPshPa8xIrTxHD1SLv/jt3Vg6a7xGbVqkMwheza4vEsW6szTw1sS7GpsOoZufa0
	2ZJ5vuz8PmUjmgcu2Xlc0LnB3Lx70gYBiLWJSHslAH85xHyXcAhGpzh751+W1nKXFl74+3IIvZJ
	GV5geIG3/n4T4wCs5GGoa5dF97sxvdlrzCm5B1FPCch0uw==
X-Google-Smtp-Source: AGHT+IFFDzCXLJ4mIqALaM/bWqd/AxEMPWtd+Ja0S/+1NXtvXDYhfo5KF4zy5V1sXbhwy03p5rTIZw==
X-Received: by 2002:a05:600c:154e:b0:43c:ef13:7e5e with SMTP id 5b1f17b1804b1-441d44dd248mr48529085e9.26.1746698222056;
        Thu, 08 May 2025 02:57:02 -0700 (PDT)
Date: Thu, 8 May 2025 11:57:00 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v3 10/11] vpci/msi: Free MSI resources when init_msi()
 fails
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-11-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250421061903.1542652-11-Jiqian.Chen@amd.com>

On Mon, Apr 21, 2025 at 02:19:02PM +0800, Jiqian Chen wrote:
> When init_msi() fails, the previous new changes will hide MSI
> capability, it can't rely on vpci_deassign_device() to remove
> all MSI related resources anymore, those resources must be
> cleaned up in failure path of init_msi.
> 
> To do that, add a new function to free MSI resources.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> ---
> v2->v3 changes:
> * Remove all fail path, and use fini_msi() hook instead.
> * Change the method to calculating the size of msi registers.
> 
> v1->v2 changes:
> * Added a new function fini_msi to free all MSI resources instead of using an array to record registered registers.
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/msi.c | 28 +++++++++++++++++++++++++++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
> index ea7dc0c060ea..18b06b789827 100644
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -193,6 +193,32 @@ static void cf_check mask_write(
>      msi->mask = val;
>  }
>  
> +static void fini_msi(struct pci_dev *pdev)
> +{
> +    unsigned int end, size;
> +    struct vpci *vpci = pdev->vpci;
> +    const unsigned int msi_pos = pdev->msi_pos;
> +
> +    if ( !msi_pos || !vpci->msi )
> +        return;
> +
> +    if ( vpci->msi->masking )
> +        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
> +    else
> +        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
> +
> +    size = end - msi_control_reg(msi_pos);
> +
> +    /*
> +     * Remove all possible registered registers except capability ID
> +     * register if guest and next capability pointer register, which
> +     * will be removed in mask function.

The above text seems very convoluted.  I prefer re-using the same
comment that you had in the ReBAR cleanup helper:

    /*
     * Remove all possible registered registers except header.
     * Header register will be removed in mask function.
     */

> +     */
> +    vpci_remove_registers(vpci, msi_control_reg(msi_pos), size);
> +    xfree(vpci->msi);
> +    vpci->msi = NULL;

XFREE(vpci->msi);

Will be more compact.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 08 10:04:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 10:04:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979178.1365863 (Exim 4.92)
	(envelope-from )
	id 1uCy6u-0004YA-Qh; Thu, 08 May 2025 10:04:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979178.1365863; Thu, 08 May 2025 10:04: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 1uCy6u-0004Y3-Nv; Thu, 08 May 2025 10:04:12 +0000
Received: by outflank-mailman (input) for mailman id 979178;
 Thu, 08 May 2025 10:04:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCy6t-0004Xx-IP
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 10:04:11 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c97a3c15-2bf3-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 12:04:10 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a0b308856fso523389f8f.2
 for ; Thu, 08 May 2025 03:04:10 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a099ae3bc0sm20145797f8f.35.2025.05.08.03.04.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 08 May 2025 03:04: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" 
X-Inumbo-ID: c97a3c15-2bf3-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746698650; x=1747303450; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=kgXgZ0DXWJxaajJr81bMwa02w9aWXCTuR1n0s3IJLJM=;
        b=epo+Fx7pciLQoZjisRqKodbnRBx5d9Rfh57krckhYyAk8+Kwnf/LqnLSIb7ag/VcEh
         HVRXu+CwjGAUJ+91vC+GWVm6ng6B2uMWrRxeKupvIrnbnbGS2XFlHBst1JaXGUztFNiN
         W25QVq8FRk9ySBryuoeAXLHL3+7u4Skv9YQtY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746698650; x=1747303450;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=kgXgZ0DXWJxaajJr81bMwa02w9aWXCTuR1n0s3IJLJM=;
        b=ic7OBh8qWq4zjkcLoydildnuJGQqAUz6+JTcy04qXBlD17k57qTr+bcQGa+UCqFZ4I
         gZrvbhA9o1b+Y5scK7o/Ys5kOTKCQSBJ05PBAtZGNJ1boc3tqwA6JzZGSG+k1pD/yP/T
         FaTgg5IM17Fy3wNqP+ODyJzIeq5zTV9dXN/ry2gpWGjmvxagvqn5hCquF1uI/q239Q7s
         OCPZ40/hCYxsZdjheNRS6xeifg+212ym0MNKaUBlyyijHRqCWUQcA/kvGsnToSS4CV/8
         X23vEHkXvZPuapV2hXrImdLeVQmjM7BMfH6cu5xAWMB5b/zNZiMqBrO0H4xcSCc5vxGs
         GNLQ==
X-Gm-Message-State: AOJu0Yzf3hXGQBR7tSnY2YvxjbBMKBcmkjrYRHYNoITqUlkbfbZKorEe
	WsoSv4guGMiW/34Exqris9KUbvhgGcLqfqvVVcWzO6bmBbn80re49+k/hJULTxI=
X-Gm-Gg: ASbGncvn1t0qGSQyDU0nfRxNKEIixww023jttKTtjNpr3FfwJvsxhz1UAQ3Rmf/qG5n
	oosQKbhZYsLUs9K5W+Kw1tpHjuxeXa7OiFZKwvzVhINH/ND1r2scFEhdODs/U6SbR7btKYk+zZq
	KAtV1JzG/7CkYMHumC8QNM2+94P1LzxbOqsxKnc1E5/WiyNtXIeq7WqAv1hOYLR6X3X+y0EZuva
	TxjUGMS0PdqOBGwYN84CtIVPS84HhbyB/W+fZZiTnsKkTK7WAjaK/sgR8Mupxr2D29phql+0v6L
	DoFyJiamayAO+EeWchLQJE+rQ7/lduVe0lENB57uGhbkUg==
X-Google-Smtp-Source: AGHT+IGbDQ0/Wqwhd5EVuJhdT5BBr1UIYsMnp09zDFBU75xIjLjjGqNZWe2xVrNHBJIO8y8vYdLTKQ==
X-Received: by 2002:a5d:5c84:0:b0:391:2932:e67b with SMTP id ffacd0b85a97d-3a0ba0b6da1mr1729572f8f.35.1746698650094;
        Thu, 08 May 2025 03:04:10 -0700 (PDT)
Date: Thu, 8 May 2025 12:04:08 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v3 11/11] vpci/msix: Add function to clean MSIX resources
Message-ID: 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-12-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250421061903.1542652-12-Jiqian.Chen@amd.com>

On Mon, Apr 21, 2025 at 02:19:03PM +0800, Jiqian Chen wrote:
> When init_msix() fails, it needs to clean all MSIX resources.
> So, add a new function to do that.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> ---
> v2->v3 changes:
> * Remove unnecessary clean operations in fini_msix().
> 
> v1->v2 changes:
> new patch.
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/msix.c | 21 ++++++++++++++++++++-
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
> index 0228ffd9fda9..e322c260f6bc 100644
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -703,6 +703,25 @@ int vpci_make_msix_hole(const struct pci_dev *pdev)
>      return 0;
>  }
>  
> +static void fini_msix(struct pci_dev *pdev)
> +{
> +    struct vpci *vpci = pdev->vpci;
> +    unsigned int msix_pos = pdev->msix_pos;
> +
> +    if ( !msix_pos || !vpci->msix )

That's not fully correct here.  See how in init_msix() vpci->msix is
set at the tail of the function, after having added the register
handlers.

I think you instead want:

if ( !msix_pos )
    return;

vpci_remove_registers(vpci, msix_control_reg(msix_pos), 2);

if ( !(vpci->msix )
    return;

list_del(&vpci->msix->next);
...

> +        return;
> +
> +    list_del(&vpci->msix->next);
> +
> +    for ( unsigned int i = 0; i < ARRAY_SIZE(vpci->msix->table); i++ )
> +        if ( vpci->msix->table[i] )
> +            iounmap(vpci->msix->table[i]);
> +

Since you have added to all previous cleanup functions, do you also
need a comment here to mention the capability header is not handled?

TBH I'm not sure whether that's relevant in the context here (and
other cleanup functions), as the capability header traps are not added
by the REGISTER_VPCI_{LEGACY,EXTENDED}_CAP() init hooks either, so it
would seem asymmetric for the cleanup hook to attempt to remove those
in the first place.

> +    vpci_remove_registers(vpci, msix_control_reg(msix_pos), 2);
> +    xfree(vpci->msix);
> +    vpci->msix = NULL;

XFREE();

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 08 10:14:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 10:14:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979189.1365873 (Exim 4.92)
	(envelope-from )
	id 1uCyGo-0006WL-NU; Thu, 08 May 2025 10:14:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979189.1365873; Thu, 08 May 2025 10:14: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 1uCyGo-0006WE-JO; Thu, 08 May 2025 10:14:26 +0000
Received: by outflank-mailman (input) for mailman id 979189;
 Thu, 08 May 2025 10:14:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCyGn-0006W8-GB
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 10:14:25 +0000
Received: from postout2.mail.lrz.de (postout2.mail.lrz.de [129.187.255.138])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 36406a01-2bf5-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 12:14:22 +0200 (CEST)
Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1])
 by postout2.mail.lrz.de (Postfix) with ESMTP id 4ZtSfQ1ZQtzyWc;
 Thu,  8 May 2025 12:14:22 +0200 (CEST)
Received: from postout2.mail.lrz.de ([127.0.0.1])
 by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavis, port 20024)
 with LMTP id r0FHAHq9VYBJ; Thu,  8 May 2025 12:14:21 +0200 (CEST)
Received: from [IPV6:2a02:2455:1858:e00::d608] (unknown
 [IPv6:2a02:2455:1858:e00::d608])
 (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 postout2.mail.lrz.de (Postfix) with ESMTPSA id 4ZtSfP25y4zyWl;
 Thu,  8 May 2025 12:14: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" 
X-Inumbo-ID: 36406a01-2bf5-11f0-9ffb-bf95429c2676
Authentication-Results: postout.lrz.de (amavis); dkim=pass (2048-bit key)
 reason="pass (just generated, assumed good)" header.d=tum.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tum.de; h=
	content-transfer-encoding:content-type:content-type:in-reply-to
	:from:from:content-language:references:subject:subject
	:user-agent:mime-version:date:date:message-id:received:received;
	 s=tu-postout21; t=1746699261; bh=liP4PbPOtNNkjDuk3bWk3eoiLOyQ5H
	ogb0b7Qou/5bI=; b=mfXt9nhVV+W3iICsmoraTX3+aEnueroK0NDVmPkW9hKxSJ
	ouSz6GTVIgj95WLOjhz/opiJbZy7YmpIQEF2DDNcHGl0/GX+o9KHfHqaEF6bG1vQ
	wJsvCbBdKf+0kmzFNC5tzhnyJ4Qkrxz4D93nwGw2oKx6vDwfsZgX7tJowborffJ/
	wbzypR1pzk4w1FzwBkFimhuldckn3TBYDJOHe8bp4df3tLEfcjMiLR+/l5UmYaOo
	+eUGX1wqu29haAjQ5uuEM612pd8ZROPk4ijEWcITV/XndsXORirwY2lh/4LxNnX6
	RJevg6g8SrtyxSjZvY8XeOxiJuYPx54Zt0h9xL8Q==
X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de
X-Spam-Flag: NO
X-Spam-Score: -2.871
X-Spam-Level:
X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5
 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DMARC_ADKIM_RELAXED=0.001,
 DMARC_ASPF_RELAXED=0.001, DMARC_POLICY_NONE=0.001, LRZ_DMARC_FAIL=0.001,
 LRZ_DMARC_FAIL_NONE=0.001, LRZ_DMARC_POLICY=0.001, LRZ_DMARC_TUM_FAIL=0.001,
 LRZ_DMARC_TUM_REJECT=3.5, LRZ_DMARC_TUM_REJECT_PO=-3.5,
 LRZ_ENVFROM_FROM_MATCH=0.001, LRZ_ENVFROM_TUM_S=0.001,
 LRZ_FROM_ENVFROM_ALIGNED_STRICT=0.001, LRZ_FROM_HAS_A=0.001,
 LRZ_FROM_HAS_AAAA=0.001, LRZ_FROM_HAS_MDOM=0.001, LRZ_FROM_HAS_MX=0.001,
 LRZ_FROM_HOSTED_DOMAIN=0.001, LRZ_FROM_NAME_IN_ADDR=0.001,
 LRZ_FROM_PHRASE=0.001, LRZ_FROM_PRE_SUR=0.001, LRZ_FROM_PRE_SUR_PHRASE=0.001,
 LRZ_FROM_TUM_S=0.001, LRZ_HAS_CLANG=0.001, LRZ_HAS_CT=0.001,
 LRZ_HAS_IN_REPLY_TO=0.001, LRZ_HAS_MIME_VERSION=0.001, LRZ_HAS_SPF=0.001,
 LRZ_MSGID_HL8_3HL4_HL12=0.001, LRZ_MSGID_MOZ=0.001, LRZ_SUBJ_FW_RE=0.001,
 LRZ_UA_MOZ=0.001] autolearn=no autolearn_force=no
Message-ID: <59883357-a9e2-408e-a53f-f8f1ed23bbbc@tum.de>
Date: Thu, 8 May 2025 12:14:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: UBSan bug in real mode fpu emulation
To: Jan Beulich , Andrew Cooper 
Cc: Fabian Specht , xen-devel@lists.xenproject.org
References: 
 <7e3b941d-ec4e-4158-8844-a3cf236c8d4d@citrix.com>
 
 <659665fc-e938-4c2d-9707-b44f637bb6fb@citrix.com>
 
Content-Language: en-US
From: Manuel Andreas 
Autocrypt: addr=manuel.andreas@tum.de; keydata=
 xjMEY9Zx/RYJKwYBBAHaRw8BAQdALWzRzW9a74DX4l6i8VzXGvv72Vz0qfvj9s7bjBD905nN
 Jk1hbnVlbCBBbmRyZWFzIDxtYW51ZWwuYW5kcmVhc0B0dW0uZGU+wokEExYIADEWIQQuSfNX
 11QV6exAUmOqZGwY4LuingUCY9Zx/QIbAwQLCQgHBRUICQoLBRYCAwEAAAoJEKpkbBjgu6Ke
 McQBAPyP530S365I50I5rM2XjH5Hr9YcUQATD5dusZJMDgejAP9T/wUurwQSuRfm1rK8cNcf
 w4wP3+PLvL+J+kuVku93CM44BGPWcf0SCisGAQQBl1UBBQEBB0AmCAf31tLBD5tvtdZ0XX1B
 yGLUAxhgmFskGyPhY8wOKQMBCAfCeAQYFggAIBYhBC5J81fXVBXp7EBSY6pkbBjgu6KeBQJj
 1nH9AhsMAAoJEKpkbBjgu6Kej6YA/RvJdXMjsD5csifolLw53KX0/ElM22SvaGym1+KiiVND
 AQDy+y+bCXI+J713/AwLBsDxTEXmP7Cp49ZqbAu83NnpBQ==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 4/25/25 11:11, Jan Beulich wrote:
> On 24.04.2025 16:04, Andrew Cooper wrote:
>> I have a sneaking suspicion that this is sufficient:
>>
>> diff --git a/xen/arch/x86/x86_emulate/private.h
>> b/xen/arch/x86/x86_emulate/private.h
>> index 30be59547032..9f3d6f0e5357 100644
>> --- a/xen/arch/x86/x86_emulate/private.h
>> +++ b/xen/arch/x86/x86_emulate/private.h
>> @@ -385,9 +385,9 @@ struct x87_env16 {
>>       union {
>>           struct {
>>               uint16_t fip_lo;
>> -            uint16_t fop:11, :1, fip_hi:4;
>> +            uint32_t fop:11, :1, fip_hi:4;
>>               uint16_t fdp_lo;
>> -            uint16_t :12, fdp_hi:4;
>> +            uint32_t :12, fdp_hi:4;
>>           } real;
>>           struct {
>>               uint16_t fip;
>>
>>
>> The problem is that a uint16_t bitfield promotes into int.  A base type
>> of uint32_t should cause the bitfield to promote into unsigned int directly.
> I fear that's not gcc's way of thinking. In fact, the other involved structure
> already uses bitfields with uint32_t base type, and the issue was reported
> there nevertheless. Having known only compilers which respect declared type of
> bitfields, I was rather surprised by gcc not doing so when I first started
> using it on not exactly trivial code. Just to learn that they are free to do
> so. Looks like I never dared to submit a patch I've been carrying to optionally
> alter that behavior.

So I took some time to play around with this and you're definitely right 
about GCC not respecting the declared type. Even in the struct 
`x87_env32`, where the types are already declared as `uint32_t`, GCC 
will just pick `short unsigned int` as the type for a 16-bit wide 
bit-field. As such, in the offending left-shift expression the bit-field 
will be promoted to an `int`, thereby causing the observed UB.
I could not find a way to make GCC actually pick a correctly sized 
unsigned type in this context, without also modifying the width of the 
bit-field. So I'm relatively sure the only way to fix this is to 
properly adjust the usages of these bit-fields (as was suggested 
previously).

For completeness sake I also checked how Clang deals with this issue and 
the UB manifests in the same manner.
What's worse is that I didn't find any proper documentation on this 
behavior for neither GCC or Clang. If you have anything I would be very 
interested to know.

Best,
Manuel



From xen-devel-bounces@lists.xenproject.org Thu May 08 10:29:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 10:29:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979200.1365882 (Exim 4.92)
	(envelope-from )
	id 1uCyV0-0000B3-RM; Thu, 08 May 2025 10:29:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979200.1365882; Thu, 08 May 2025 10:29: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 1uCyV0-0000Aw-Nx; Thu, 08 May 2025 10:29:06 +0000
Received: by outflank-mailman (input) for mailman id 979200;
 Thu, 08 May 2025 10:29:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCyUy-0000Aj-IH
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 10:29:04 +0000
Received: from fout-b4-smtp.messagingengine.com
 (fout-b4-smtp.messagingengine.com [202.12.124.147])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41c67117-2bf7-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 12:29:02 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.stl.internal (Postfix) with ESMTP id 2071E11401B9;
 Thu,  8 May 2025 06:29:00 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Thu, 08 May 2025 06:29:00 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 8 May 2025 06:28:58 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 41c67117-2bf7-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1746700139;
	 x=1746786539; bh=zTnJAKnVmugWDU/7gsiDLpmqBYOpP8RWjjl6jZhpgP0=; b=
	AAUX2p1svV+Owjvnh48cM0Iy7iEsktpPNTE4lr5a++QOarGmjDgiQFsBhE3HgRnU
	mtHHEd4RmSs5gTWmVRVfiDkVzuHy9s2F60qABfeaD7yoc+UvYiEHO+WuWYoUweeT
	9HDYT5wDobB+zmHbRZS2X7oYTXTqjfdcrD8GCdFbs6D/xy+r02C1cIeaz7Mnkezz
	Xu4IHWoLAiRFkCNy4wK2wTid1jyQmNUbm1HAM7SdIAh80IxWwU46VXhjYuKFw0cr
	P696edczgg/xabiLzwOXJ2ooyLqvQYO//9hDZ60wz92a5iUl5QQ4Q1Ghk3gmspxD
	p047az1d3engYMFTLlvpfQ==
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=fm3; t=
	1746700139; x=1746786539; bh=zTnJAKnVmugWDU/7gsiDLpmqBYOpP8RWjjl
	6jZhpgP0=; b=hWfniIno93YMJ5l8AVValRVJnLCwUqJmoouFf3b3TaYhVMN7GCY
	NHux40bxHLj6a1fh+xUmxp47GK/Qa6tWAvA7k8BRMEACUh7VOOidlvaGsUEO6hmz
	Ozc+nJ4nnwKcAmT6pIJj7yX81vf4Zm/JLRA1rHKs+i5xK65N3PDiqveZaUC2J+AM
	84P0KOLaloend2eYSF2w/DxQlW5lkEDDVIxPVmNcO0GWMb7cTJWbKc5zdaghk394
	iFn3VW44gqdxL9abg9fhdRK9+5VSiL0nI+/g9CRAOWhznNal/ya63n6hbSZsSk19
	bAFab1CrtKjKRHbmSza1DYEQvu1DmTBjGlg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvkeelhedtucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettd
    dvgeeuteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf
    rhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
    dpnhgspghrtghpthhtohepkedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprhho
    ghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepshhsthgrsggvlhhlih
    hniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdr
    tghomhdprhgtphhtthhopeigvghnihgrrdhrrghgihgruggrkhhouhesrghmugdrtghomh
    dprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhr
    tghpthhtohepjhgrshhonhdrrghnughrhihukhesrghmugdrtghomhdprhgtphhtthhope
    grghgrrhgtihgrvhesrghmugdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehl
    ihhsthhsrdigvghnphhrohhjvggtthdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 8 May 2025 12:28:55 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: Stefano Stabellini ,
	Jan Beulich ,
	"Ragiadakou, Xenia" ,
	Andrew Cooper , jason.andryuk@amd.com,
	agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
Message-ID: 
References: 
 <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>
 
 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ABOHH0mrIZmZQ+dy"
Content-Disposition: inline
In-Reply-To: 


--ABOHH0mrIZmZQ+dy
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 May 2025 12:28:55 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: Stefano Stabellini ,
	Jan Beulich ,
	"Ragiadakou, Xenia" ,
	Andrew Cooper , jason.andryuk@amd.com,
	agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange

On Thu, May 08, 2025 at 11:12:34AM +0200, Roger Pau Monn=C3=A9 wrote:
> On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
> > On Tue, 6 May 2025, Roger Pau Monn=C3=A9 wrote:
> > > On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
> > > > On Mon, 5 May 2025, Roger Pau Monn=C3=A9 wrote:
> > > > > On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-G=C3=
=B3recki wrote:
> > > > > > On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wr=
ote:
> > > > > > > On Mon, 28 Apr 2025, Jan Beulich wrote:
> > > > > > > > On 25.04.2025 22:19, Stefano Stabellini wrote:
> > > > > > > > > From: Xenia Ragiadakou 
> > > > > > > > >=20
> > > > > > > > > Dom0 PVH might need XENMEM_exchange when passing contiguo=
us memory
> > > > > > > > > addresses to firmware or co-processors not behind an IOMM=
U.
> > > > > > > >=20
> > > > > > > > I definitely don't understand the firmware part: It's subje=
ct to the
> > > > > > > > same transparent P2M translations as the rest of the VM; it=
's just
> > > > > > > > another piece of software running there.
> > > > > > > >=20
> > > > > > > > "Co-processors not behind an IOMMU" is also interesting; a =
more
> > > > > > > > concrete scenario might be nice, yet I realize you may be l=
imited in
> > > > > > > > what you're allowed to say.
> > > > > > >=20
> > > > > > > Sure. On AMD x86 platforms there is a co-processor called PSP=
 running
> > > > > > > TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occa=
sionally to
> > > > > > > pass addresses to it.  See drivers/tee/amdtee/ and
> > > > > > > include/linux/psp-tee.h in Linux.
> > > > > >=20
> > > > > > We had (have?) similar issue with amdgpu (for integrated graphi=
cs) - it
> > > > > > uses PSP for loading its firmware. With PV dom0 there is a work=
around as
> > > > > > dom0 kinda knows MFN. I haven't tried PVH dom0 on such system y=
et, but I
> > > > > > expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, an=
d it's
> > > > > > the one I used for debugging this issue).
> > > > >=20
> > > > > That's ugly, and problematic when used in conjunction with AMD-SE=
V.
> > > > >=20
> > > > > I wonder if Xen could emulate/mediate some parts of the PSP for d=
om0
> > > > > to use, while allowing Xen to be the sole owner of the device.  H=
aving
> > > > > both Xen and dom0 use it (for different purposes) seems like aski=
ng
> > > > > for trouble.  But I also have no idea how complex the PSP interfa=
ce
> > > > > is, neither whether it would be feasible to emulate the
> > > > > interfaces/registers needed for firmware loading.
> > > >=20
> > > > Let me take a step back from the PSP for a moment. I am not opposed=
 to a
> > > > PSP mediator in Xen, but I want to emphasize that the issue is more
> > > > general and extends well beyond the PSP.
> > > >=20
> > > > In my years working in embedded systems, I have consistently seen c=
ases
> > > > where Dom0 needs to communicate with something that does not go thr=
ough
> > > > the IOMMU. This could be due to special firmware on a co-processor,=
 a
> > > > hardware erratum that prevents proper IOMMU usage, or a high-bandwi=
dth
> > > > device that technically supports the IOMMU but performs poorly unle=
ss
> > > > the IOMMU is disabled. All of these are real-world examples that I =
have
> > > > seen personally.
> > >=20
> > > I wouldn't be surprised, classic PV dom0 avoided those issues because
> > > it was dealing directly with host addresses (mfns), but that's not the
> > > case with PVH dom0.
> >=20
> > Yeah
> >=20
> >=20
> > > > In my opinion, we definitely need a solution like this patch for Do=
m0
> > > > PVH to function correctly in all scenarios.
> > >=20
> > > I'm not opposed to having such interface available for PVH hardware
> > > domains.  I find it ugly, but I don't see much other way to deal with
> > > those kind of "devices".  Xen mediating accesses for each one of them
> > > is unlikely to be doable.
> > >=20
> > > How do you hook this exchange interface into Linux to differentiate
> > > which drivers need to use mfns when interacting with the hardware?
> >=20
> > In the specific case we have at hands the driver is in Linux userspace
> > and is specially-written for our use case. It is not generic, so we
> > don't have this problem. But your question is valid.
>=20
> Oh, so you then have some kind of ioctl interface that does the memory
> exchange and bouncing inside of the kernel on behalf of the user-space
> side I would think?
>=20
> > In Linux, the issue is hidden behind drivers/xen/swiotlb-xen.c and
> > xen_arch_need_swiotlb. There are a few options:
> > - force swiotlb bounce for everything on the problematic SoC
> > - edit xen_arch_need_swiotlb to return true for the problematic device
> > - introduce a kernel command line option to specify which device
> >   xen_arch_need_swiotlb should return true for
>=20
> Isn't it a bit misleading to use the swiotlb for this purpose?  Won't
> this usage of the swiotlb (to bounce from gfns to mfns) create issues
> if there's any devices that have a DMA physical address limitation and
> also needs to use the swiotlb while being behind the IOMMU?
>=20
> > - introduce an ACPI table with the relevant info
>=20
> Hm, best option might be an ACPI table so that Xen can signal to the
> hardware domain whether communication with the device must be done
> using mfns, or if accesses are mediated and hence can be done using
> gfns?

How does it work on native when some devices are not behind IOMMU? Is it
signaled via an ACPI table? It feels like it's a similar (although not
the same) situation here.

> It's a bit cumbersome however to have to resort to an ACPI table just
> for this.  Not sure whether we could expand one of the existing tables
> already under Xen control (STAO?) to contain this information.  It all
> looks a bit ad-hoc.
>=20
> I think we need some kind of list of devices that are not behind the
> IOMMU, but I have no idea what URI to use to identify those.  I assume
> the PSP doesn't have a PCI SBDF (as it's not on the PCI bus?).  Maybe
> by ACPI path?

It is actually on the PCI bus:
05:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Fa=
mily 17h (Models 10h-1fh) Platform Security Processor [1022:15df]

> Or maybe it's fine to always communicate with those non-translated
> devices using MFNs, and even if we later add some kind of PSP
> mediation (so that both Xen and dom0 can use it), accesses by dom0
> will still be assumed to be using MFNs, and thus need no translation.

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--ABOHH0mrIZmZQ+dy
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgch2gACgkQ24/THMrX
1yzXWgf/SD849DhBcI1QvGVgMphcSPKam4vimDZ4fHjgiVfvTaBsy+ogFOj7b3Py
vwPcPdudPkTCGMHs59Qyg392Zm3Cp0Ux69yoG9JAeieciG6d4sFfZNl/tYVDxggF
ER/cB1wxt7FXkEgOCRCe1KgahnomjwnKz2AHobhZ4DGIqDCGDuUb0TBBZG/s7ogI
zied4+5vT2KwiXLOv68U7PTc5V6p6FZLIe1kCZqN6LHT6UfUhZrYNTRrXmB1D/oP
EyOQeF4WjzaolW6hdWQZdFrIDzL+7OYhSuE8W5Pwmt6cFMPuDtpycnijeg5+VTMe
RjPF3KRokxricIkD66MUFUJZ2BjUHg==
=1I/k
-----END PGP SIGNATURE-----

--ABOHH0mrIZmZQ+dy--


From xen-devel-bounces@lists.xenproject.org Thu May 08 10:30:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 10:30:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979215.1365893 (Exim 4.92)
	(envelope-from )
	id 1uCyWn-0001vP-9F; Thu, 08 May 2025 10:30:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979215.1365893; Thu, 08 May 2025 10: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 1uCyWn-0001vI-6H; Thu, 08 May 2025 10:30:57 +0000
Received: by outflank-mailman (input) for mailman id 979215;
 Thu, 08 May 2025 10:30:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCyWm-0001eT-3W
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 10:30:56 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2412::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8567a668-2bf7-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 12:30:54 +0200 (CEST)
Received: from BN9PR03CA0939.namprd03.prod.outlook.com (2603:10b6:408:108::14)
 by DM4PR12MB6613.namprd12.prod.outlook.com (2603:10b6:8:b8::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.23; Thu, 8 May
 2025 10:30:45 +0000
Received: from BN2PEPF000044A8.namprd04.prod.outlook.com
 (2603:10b6:408:108:cafe::cd) by BN9PR03CA0939.outlook.office365.com
 (2603:10b6:408:108::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.27 via Frontend Transport; Thu,
 8 May 2025 10:30:45 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A8.mail.protection.outlook.com (10.167.243.102) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 10:30:44 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 05:30:44 -0500
Received: from [172.31.225.170] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 05:30: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" 
X-Inumbo-ID: 8567a668-2bf7-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=r4vfXdsQIfxuq/rshKULyinpA/oo2BGojJvHy+dj2ZRXwrqAoaHrpoYTCSM8Kw+fZXFFr5NRVut42mFTqkI7SSbwzCbzXLHHXkYACwJNYQuHD7ZHSV+QcNrg++ZBRTRXAWks4Zs0oCIqWu61XClJZ2GFZ8b+T37SPaiYA8tyc0VUU90551vfHzEY5E+MPiT8OeaYhqlCDv11nHcAtc8pTsQCwWXFrVW+VMPfj4FrRd4HLlqSAvG534KXSDQ2K3/7gNqZas+CCcyUR8DPWISdPzIF8egZIHyh2QLfv9pRUL2ji7V9wlpsj48u97f0t6xEMqjpNdgVWR+h5OIGBx8vdA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0MXaUm47bYx3+3m1ziqPITat1wED23CHBObq9T6YqLA=;
 b=ajuv4oaYYEo5G5QanV1ahoXsN9JSSqYTsKQmTuy6+6wNyQ24IfUuYKJ8cCPXEeJemj9hYfzqueF6E9Q0yBh7edObfR20c8Sm/8ob6tTgwAH/WfrsvixOTdsEaKc3xFC5yYQacVOcnPzKja4RXDSYgknnsgiqfQNxlmwTyRnvggBw/t2/+FVNkaS1+On1MZtsSdGZtm/uwwwSDLDOvR/OK1xpjNym2SkxMT5jYonkFoSPwmaGnwTrzKzPMrjqROIbdrQTwMxPnJu+1G6EC2XUzRZkDKGMKf0qTB6H6dspm3X03ac9qT+3VNd5NeuB/JoX/KPLrZ0BpgXDydrATASu3w==
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=0MXaUm47bYx3+3m1ziqPITat1wED23CHBObq9T6YqLA=;
 b=RyNXMMlfxYG1ckNHnPD8Kv8ZLCK+9+5unpljCimtgEM8tB6LAGgvZstj09aCG8+coIXEkmd0fBz34IIZwJ1keVIHHhWSkC9eYfOEHuGk27gx5qoLUCrL4nO6soXBAcR9cVF7PfFYZeKmGJOZlzJfi7fiUDt5t1+aCrO/hozzBKU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <309dc9f0-3938-4b84-b772-e0044763f52a@amd.com>
Date: Thu, 8 May 2025 06:30:43 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] xen/arm: fix math in add_hwdom_free_regions
To: "Orzel, Michal" , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , "Volodymyr
 Babchuk" 
References: <20250505025631.207529-1-stewart.hildebrand@amd.com>
 <20250505025631.207529-3-stewart.hildebrand@amd.com>
 
 <7ad1dde2-0af3-4a8c-a67e-3eafdea5822f@amd.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <7ad1dde2-0af3-4a8c-a67e-3eafdea5822f@amd.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A8:EE_|DM4PR12MB6613:EE_
X-MS-Office365-Filtering-Correlation-Id: 100e0cfd-1353-4dc6-316a-08dd8e1b63e2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ckp3aGF4WUl3M3RnWG9Ra0FPT1JXaWRCeXpFOXFmRm9SZkJaNHdtMFBNaE10?=
 =?utf-8?B?MWVZZDVITVZlN01VRFhFam1IRHIwdkx3VzJ0OC9QQzJTeDZxUXRXbDFYVFZI?=
 =?utf-8?B?YnRxZi93TzdKZXdqZ0xabDZYbXp3WFRQM1orcERSU3ZxaDM1elFMOTZVOFYx?=
 =?utf-8?B?cWtVWTJaeUZCNXVLT09xWGFGZ1NTSzNzdURjSTM4QVJvVE91aGlIbjBaVmxu?=
 =?utf-8?B?V2l5K01JNkNHbDk2UlRNQVRCdjI4cnlKbGFuSVVoQW5wR1k4MDNrQWNXcnpE?=
 =?utf-8?B?elBXemhuUGRtQUdsZjhzV0pUUm1qVGJ2N1J6VDh1akxFQUF4dkU5SlhYSCtC?=
 =?utf-8?B?RFpJM1hhZTdPQ2gzL3VBaVY4WU1GU0ZWRXI5SDROeGlzNVhZWlNPa1hoYnpl?=
 =?utf-8?B?WFpnenQ0UFhka0YvMnRUTk1ZUURMc1pBaStYQ1hrM2lud1hWNkxZTWxiQVpK?=
 =?utf-8?B?SDZuZUs5bnQ4OVZ2R1JKSHJFckZYZzBlcGpzOFIxL0RzYisvV1AvVWhsNFJR?=
 =?utf-8?B?TEIvSFlkTy9kRnJucEVsSG0yWXc2aVVqWlhodUh4c0t0SXJvbEJwckJXdlgz?=
 =?utf-8?B?VWV2MERoZll3c1hObEVvWnorbW8zM1RtTHBhelliRUppVHpUaHZkMDJBV3hQ?=
 =?utf-8?B?ckljSVlBNk93Rld2R3hVWUJHeVgxcG5BYjQ3Y2NvaWxDU2kwdDdhVHVISlZY?=
 =?utf-8?B?NGJRZ2IxcTNwZzlUM2xidGF5RDRhcnBMVW9OQ3lFTk85U1F6dVhpQ29Ydllj?=
 =?utf-8?B?WHBPK0tDVFNjbnpDTlBYdmFtTEVuckdsU0ZRZGM2Z29ybStjTVFxV0lvWlo2?=
 =?utf-8?B?UzI4ZmFmWm5kUE9JdEpPUU0vNXRUeEJaSXNJSHF5S0FsOGlzSzdJWkUzVHZS?=
 =?utf-8?B?VWpnRE1qZDMwd3drSGZyTnR6Q3JYV3Y5b1dJN2NmR1Z4dFRPQk44SDlYK2lM?=
 =?utf-8?B?NGQzRVJYWm1rZzVRRmlDcnRhL2ZvcFIrNDhJbndyZXBsbkllYys4Nk1CM2Jn?=
 =?utf-8?B?YS9UWTIzYmt1NjlrWWg4QkpsYXJhRm1DeVNRdFFHbWk2RFhDWTNJZlFUaCs1?=
 =?utf-8?B?ZmVhdDNWeHlXT3QwUVowVUNuYkFZR3ZVVTFQL0JyNFRQa3lCYjRHbHY0SE9M?=
 =?utf-8?B?SUxxQjJqVGNkT2k5TUhTdG1GU0VJamF0Z2pjcWtBU05mdFF2N0xzenBjaHhP?=
 =?utf-8?B?YnBDSlRIZkVNbjlHVHI3eWJockhBRkdZdEtndmt4OEVFbFBKeCtFdDByTW1s?=
 =?utf-8?B?TnkrYkVQbXB4cHJJbmlGcUNtNnY2QWtBVWYvQnV6N0lxeFUvRDhaMzA2K3Zl?=
 =?utf-8?B?MEx2S2ZkS2VrSStabE5CdEFwd3prUFBmL1lRK2xjUjBzY25PSXBOek9HaDI2?=
 =?utf-8?B?b1YyUndwNmt0bVRONWFJbDMrMVdkSmhRODRFNG9CQU1rQlp4YS9RUW16NFBN?=
 =?utf-8?B?MDBQUEwremkyL1FuUlJ3UUZJb0hsMVRJd0dyMk12WWd2dlR2MkoybXFwaVRM?=
 =?utf-8?B?c3B5eDFzK0JyOW92bWJwK3dGUzRiR2FKOXVEUldvQkdRQkZDcFl2K0prZWk2?=
 =?utf-8?B?YnBlMnk1NVZ0QWxvd253OXNvNVdxK0ZoWm9WbWxUQXkvNk1Rb1h5RDJpMmM1?=
 =?utf-8?B?VXY4S3NXMExSckhBKzhTbWVOTVlwQXNiWVd5bjRXaGc5ZWUxUXhPejdjYThm?=
 =?utf-8?B?Q1lKYVp0SjRBMlBIY1ZTeWdGMmQ3OGYyUTBtdEJpRE4xY0FxVDlUSEtWOE9u?=
 =?utf-8?B?ZEIrdm5MVGtJY0hpT1phMFBQVUZVaUUyNUdOQ1l5cm1OR2ZtWUlKTERVZ0Fu?=
 =?utf-8?B?cmxNQ0tONWJmU0Vha3Npa0gxNldCOVhZVi9vajJUeno3aUwzQWF3MWZTa0Fn?=
 =?utf-8?B?OUlrMnUxeWZJYWlBcnVOZkFGR242clhlalRiaFkwZTZSYTZaNDJyWHFVV0R1?=
 =?utf-8?B?NFd1MzZLbWVqZTd0NkxVNGpUQlROem9obWQ3a2lybmEvRFVQcWc5QWRkdFFL?=
 =?utf-8?B?RDBlSmQ2SnVWaHpJdjQraFpWUGRZWjA3aGN5RWZIbEV4UlkvaUZ4ZkJxSzMy?=
 =?utf-8?Q?yHCHEJ?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 10:30:44.7030
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 100e0cfd-1353-4dc6-316a-08dd8e1b63e2
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A8.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6613

On 5/8/25 02:56, Orzel, Michal wrote:
> On 05/05/2025 09:52, Orzel, Michal wrote:
>>
>>
>> On 05/05/2025 04:56, Stewart Hildebrand wrote:
>>> Erroneous logic was duplicated from add_ext_regions() into
>>> add_hwdom_free_regions(). Frame numbers are converted to addresses, but
>>> the end address (e) is rounded down to page size alignment. The logic to
>>> calculate the size assumes e points to the last address, not page,
>>> effectively leading to the region size being erroneously calculated to
>>> be 2M smaller than the actual size of the region.
>>>
>>> Fix by adding 1 to the frame number before converting back to address.
>>>
>>> Fixes: 02975cc38389 ("xen/arm: permit non direct-mapped Dom0 construction")
>>> Signed-off-by: Stewart Hildebrand 
>> Acked-by: Michal Orzel 
> 
> I wanted to commit your fixes but rebase is required after recent dom0less code
> movement. Please do.

Yes, I have already rebased locally. I'll send later today. Is it okay
to keep your A-b tag?


From xen-devel-bounces@lists.xenproject.org Thu May 08 10:31:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 10:31:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979222.1365903 (Exim 4.92)
	(envelope-from )
	id 1uCyXX-0002Xh-Ik; Thu, 08 May 2025 10:31:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979222.1365903; Thu, 08 May 2025 10:31: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 1uCyXX-0002Xa-G6; Thu, 08 May 2025 10:31:43 +0000
Received: by outflank-mailman (input) for mailman id 979222;
 Thu, 08 May 2025 10:31:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCyXW-0001eT-58
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 10:31:42 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2416::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a0068604-2bf7-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 12:31:40 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CH2PR12MB4230.namprd12.prod.outlook.com (2603:10b6:610:aa::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.21; Thu, 8 May
 2025 10:31:30 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8722.021; Thu, 8 May 2025
 10:31: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" 
X-Inumbo-ID: a0068604-2bf7-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=REzgv6u9G2RNQtZYZzF59zOklK2IMaqcC0LQVSb/XiaO8sSI+VDBJS++2gzMPQdBusPCUJjZon7QNr9Nu/xGvDHAbxs7B6rq0mOAE90vW2Qh77vrym/9b1R/llQ3syjwj05V1Tn3iZaZUbpzv4TguK607VYQIXxF4WEwtKMsN2Hli//FE+xY/cgm904atlhyh/T5GGnvKjVC5V4uwtvtvdoY3yi1p0LjtsbqPdtN20lpEOHqyGlLJs9aMtXLyRvY50olAaBLOGaBj4Oj9Is7tmI41EFZY/qbOFF7uDEDL5q4lWQzrTjpES1u39mL7KH4GFqTH2jtjzxz744dNZuteQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BLJSAeSEkFj08J/5xstB9W4q1+Zy/X/z15JAixrIQSo=;
 b=kHUCRCzFgS5zpWFeJXQBE8x1CM4Kg3/4OOqKp6JcnEpLNweG0i0X60KayohOsi0qIdRGTBcD+WN/gxmCdPzBS0cCHYDh1Hz00SlMdwW0MpOWG/LvXUdYzMSYVihXTAR/66G2yh/OT6z+QABmNjuPHgfQOmv0xjrKQWPXyzDoI/5nWOdLwDTaFuSpZ6TqKY0ST9C1irBi3fyEwg1EW8UfJJgCtcM2vsuRia/KdY522EN3G9S7HRAcXRkwSNYPEd6HgMiUqcLzhAeCf3GYdTgO+KpXsIUnWYh3KwU+465l/ksLgJGm6lZgzffmnvVkOcQ8wmfTWsM9QF5uGfV29uex+g==
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=BLJSAeSEkFj08J/5xstB9W4q1+Zy/X/z15JAixrIQSo=;
 b=3nyQm0zl488BqNbmqskgfjVmawFwcYArxLKNSY6cW8yIlC++Lq+bwE6RUF8MpJLdWzMj611Q+3oa5FwBBTabvQ3wuYKiZqmqhEPYjXLibcfOAILkZ6iadj9xXYNuIOouyKuDF5+6zyfRM82iU/cG0Q2Ix8lozGW9k0PJLoEN7d8=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Thu, 8 May 2025 12:31:25 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] xen/arm: fix math in add_hwdom_free_regions
To: Stewart Hildebrand ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250505025631.207529-1-stewart.hildebrand@amd.com>
 <20250505025631.207529-3-stewart.hildebrand@amd.com>
 
 <7ad1dde2-0af3-4a8c-a67e-3eafdea5822f@amd.com>
 <309dc9f0-3938-4b84-b772-e0044763f52a@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <309dc9f0-3938-4b84-b772-e0044763f52a@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR3P281CA0061.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:4b::9) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CH2PR12MB4230:EE_
X-MS-Office365-Filtering-Correlation-Id: aee61445-d58e-4bc3-b458-08dd8e1b7f02
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dWkzTW9wc3FNNlBHUlJqWWNYcGtHK0tWdkEvUk1uUUdpaEFxOWxaYmJ2bWhQ?=
 =?utf-8?B?aVp0cit1T3Z2M1lTZ0VTUEVROC94dXNlOG1QZURubExXZWp5UzVIZXhqTUJ2?=
 =?utf-8?B?OGhWZ1lRcDR2Qkp6WXNUUk5HTFgzSzB4RHZtWHZ5cGFCelAzbzNQSVRhckx5?=
 =?utf-8?B?bTAvdDNTQmtUTlN4MTIvSXdXUmJMbnVHRU5KSEZ1S09udDA5RFBZN1ZJQjVP?=
 =?utf-8?B?UDVValFvMDExdEx6S05ZRFE4UFFUNVN4TCtkVmt5dDhzQUpmU0ZGb2hQQ2ZI?=
 =?utf-8?B?TUtIMHBQS0VzNzNwQlE3N0dNaXRQUW1IZStyVC9NbnV0bENCSGtrdEFrMmla?=
 =?utf-8?B?M2d0NFA3TjFpME1DaTJ1U2k5SDBmV3BIb2Y4YjlQYnQ5dkZQdHhjWjkyWVdP?=
 =?utf-8?B?VnBVbVBBMmo5bWlQaWlCdVp5ZkFydkxXblZVQ2ZPckV6MjdwSmdyN2c4ODZJ?=
 =?utf-8?B?NjEvQjJ0MHI3ejRQb00xSEc2bHlPaTVQTkt4a2VxRGdEcSt5bFYvMHJaMlZC?=
 =?utf-8?B?K2RjUEhRWHFjd2pCUm1iWndKRVpXYm9SWnN4bEp6UURuYVdvNTEvRkVmcGdz?=
 =?utf-8?B?Um9LdndLQTVmR3ZLaC9VZnFlVytoN2YzT3hidUVKVEdjNlBFUVJNQTVLOUI1?=
 =?utf-8?B?WDZRYUdLTnlHbjRaV2NZcGo3N3VNQWpiWmF5QjZtUmhkMm1OSURGdXR4YUJN?=
 =?utf-8?B?NDEyMEh3S0lQc3dDR2d1K0tlMlE5WUV0WGNDSW1YR2tRWVY1R3Jyc3F0TnZ5?=
 =?utf-8?B?SW1JSTd5RkJQSks4WVBxRFBUcERCakNrdktYUitwaXRkZHpjbkRIN2lzWVIx?=
 =?utf-8?B?dndUaUQ5V08yQ0pyTWdrUnlKd2hzaTlHSHVoVTNVUzY4bHRZcWR2b2FLS0sw?=
 =?utf-8?B?SDRNN0x6T1NBUmlDREY1WjJSeDd4OSt4aEU5d01lTmJIZUJ4K0dnejhsUENu?=
 =?utf-8?B?TnRvNGJiQnJiNjloazd6cThSZ28wTDNzQXVZR1FjcUNFbHNlU1lXUkVvd2ww?=
 =?utf-8?B?c2ExZmdKTURRSUIyb2tJNDY2WHFxSGcwNktoSm81dURsUVh4Rm0wQzNxNlRJ?=
 =?utf-8?B?b1RoM0I5NFhMcFJMUHh1Ti9qTkUrbWtPSkRHY2RVR0NEMVY0dGZ1UTZFa1ln?=
 =?utf-8?B?VFBwbXB1YmVLSzA0MTNoL21iTGRBTW9WVTkrTHVXSmtIUlB0UHJDakVaMDRu?=
 =?utf-8?B?NmE2TmJjblFYdUc5akdnbW9qbExHUW84bFZkMy8wTjFxeVZTcmErZmE1YTNu?=
 =?utf-8?B?cUlLOWxndjMwU2d0U1U1TzI4c1NVbHJDQjdYeGJYNVovV09ZVXhrd1BZU1FY?=
 =?utf-8?B?eFdVYmlXYVZaeWltdWtPOEtBM2hvS0tseHNCOVdleU5aeUZTWktJTVd5UUp1?=
 =?utf-8?B?SThPWllzeUJkNk9ybWpRMytsanQ1RWw3U0dCbUFHYnROaHdGVVR3RFNiYnVz?=
 =?utf-8?B?SzF4SWlPVnFkNzQ1VHFGUnRMV1VTMDRGbnExa2NYS2s3WEM3bUpTdlZOMi9J?=
 =?utf-8?B?ZGNBQlgxb0Z4aWh5cWFlSml4cUxibFJ6UTBrbVpzcU1BSVdMNTdnSVhEQTZa?=
 =?utf-8?B?T3RXbFdmZ1JUZ2U4a21ldzlpSFJHM2JtczYrdEtQajF4bUdONlZNZ0VwOXpy?=
 =?utf-8?B?NnVkMnRvVW8rUDhVTFBVZWptTDR3Ui90WnlqcEY3TkN2RlpoYUNBTXdYUHU1?=
 =?utf-8?B?STNQT0VZMHN4bkVNSVgySFJsRkF0M1kwZE81R3dPeU1wWThLSmtiU1VvUXJF?=
 =?utf-8?B?bitNZjFOMzZLaFZIU05yRy9TdWlJaXRkMlZzRkFHcVNYVFBZaW9LbW1oSFdk?=
 =?utf-8?B?Tk5aaFVIK2FjcXFsbmRtUE9BVllMaDZEZlRDU2JZRDR1bHY1Y1dYaWZOV1g5?=
 =?utf-8?B?VTVucU9NYThTRlNaY3c0R1RaVEIycVpDSUZQMHA4bDVUeE1OZTNJNktQa0RK?=
 =?utf-8?Q?Yh2eJSFHZjw=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NzRlL1YvbFhuQzIwSS9ZZStvNVNwcEpxMVdBRmNwM0dib3g4VmlSZGlQL0hv?=
 =?utf-8?B?cEpobmpqc3V3RzRHKzArY0V1ZlkvU0JTeHRXemlkcFFkZ3pKVVFUL1dBRGRW?=
 =?utf-8?B?NkNoRWM5OFg4YUNNVnR3R29KU1dBU2JVUGswaEtzekVBNVhyRFRYSHI1UkNB?=
 =?utf-8?B?ODVER1UydTc2QkI5ZE1OcDlaaFlTVWJTd29kOG5yVE8xeHV6V3FkUlpDRklm?=
 =?utf-8?B?R2NseXdMYkdhVDE3U3RJWHZhQ0I5THcxdkU0ck5GV3phUGgzRUs5R052dCtW?=
 =?utf-8?B?a3dnRHR5djQzTEZ2VXVKY3VsUVkyRUdwYUgzeURpTDMrVC9KZ2ZFSnhMc1M3?=
 =?utf-8?B?UzVOOG00OUYySmhVRGhDcU0wdnVzSHRmelI0L2NieC9uVzgzU3NROG40cG1z?=
 =?utf-8?B?Z0R0TzQ5NVh0dHRDUCtmRURNWk9tckFnb3FrUGhqNEYwMFFrQ2wvSjFtQlUx?=
 =?utf-8?B?UFl3S1pQaUVweUx6SGsxSERkeWlldWU1dCsrSUZIYXd6dUFJTGxiZEY2Y2Q5?=
 =?utf-8?B?YXg0VzVkMXdsWGtBUDRod0wwc2x3MlJKRmxpemFTNTluWG9RdzdUSlgycStj?=
 =?utf-8?B?Vzhwc2FGVXNUYVB3RXFxbzVVNEtQSXFNSk80bzZvSmx2Y2ltcytrUkhZclNC?=
 =?utf-8?B?Z2QvMGVVaFZUckxlTVpaMjd4RzNlS0paek5LS0lSUTFicVNOdVl2dy80Wjc0?=
 =?utf-8?B?SEdaZEVyT0tHWmkwY1JZVWhhb1RzU2FxT3NkMDllU1dOZ05rT0xoMU90VFVl?=
 =?utf-8?B?WkxXSENPVklBZklsU29zdmZmTmF6UkRkdnpMT0NQN1RKZVJtM1gwcVN2Nkhm?=
 =?utf-8?B?K3pKSmhPU0RpbGgvZ1JzQlNzcE0zNyttbmdydmNtVHNIcHdYVlRVR3lWWkFL?=
 =?utf-8?B?OERHZVVEb2tRR0ZpOG9UUkxhSTJmYzZZNGFoTE9lYnZ3R1EveW1OMXUrcGor?=
 =?utf-8?B?WkRPVkxRK2hKWmxacmRhWkJyNzRnejJyZ0V5ODFiOGpCWjI5bDV3ZmJMYlVY?=
 =?utf-8?B?OElUZkJnajVHNlg1bVV4Qi9Tc0duSTV2aDE3WEhLZUo4WnNVWWkzV0NmM0pl?=
 =?utf-8?B?UGV6WUE3MDJVRldmMkNOQXRyTXpEa2YxbTY2R0RnMnVsbzlXS3NneEZ0bmVn?=
 =?utf-8?B?b01BSVhtdysvVi95d3lweGtnV3Nod2RrRHlkRWxydmx1UXhpeU13anZOMFJp?=
 =?utf-8?B?aEFaYjNZY2tzalNlL3VSOThpNTRsazBhalBVMFFkYWFTZUszS2UrWmVaVmt0?=
 =?utf-8?B?ZkNkbEF6ZnhxQ09ybkJIMXFFbWVURzdxMUhqOEFhaDArSExFTEZHNmVzSVA4?=
 =?utf-8?B?eGs3azVJY1BpeFA0Z1VwQnpIY0cvZlBvZ0tFSnF5dnNrMGVobjc2K1dBTFBr?=
 =?utf-8?B?cTFXTU1Vd0FlZ3E4REkrbVFmaTBjVVo0Mi9KbVJqaHhSdENFazBTTU9LZnUy?=
 =?utf-8?B?cERKcjByTmdFY05KSG5VdUxDcG5WZktrRWV4aEtwZWlFd1ZNMUtZa3NuNXVz?=
 =?utf-8?B?WFVneEJpQWppTCs0NkZoZUtOeHozRlpoVHBQZXBJaDRUMitZVGwzWFN1YXlE?=
 =?utf-8?B?eW5ndG9WMWhTRjlTQ0x0U2s1ZVRYaWJDblZtUEx5eDBOTGpDeDlibkI1MXNU?=
 =?utf-8?B?RjhCdE95dktYWEFBamdTSVhGQkh3MVRTTm41clJSYi9DV3ZsNFBOMkM2SHkv?=
 =?utf-8?B?YUI4VldFQ2U0UDB3UkE1K1BGR1JsMC95ZllINGpxU3UrazZaN3d0N1JJNnVN?=
 =?utf-8?B?NkVHZGtPRzZnRFBuRTdwSyt5eExST2FwQmkrK2tMalNTQXB2WHFEYXpCVytH?=
 =?utf-8?B?SmRJSGZ1VitmbFk4TlJFQmxQVzNWL24zRDAvMXkwSEdPWmxIbGwya0JRbk5t?=
 =?utf-8?B?QkREa3N4UlY2U2lxaW8vejNnMGhHam1QRXZQNUNNeEZWMzdidVNwSk1JY3BV?=
 =?utf-8?B?bnNyQ3NpeU5xRm9tVjdXZTRlRkJyT0w4ZHJMNXR2UzZQWFJ6Vm5CTGNtdDls?=
 =?utf-8?B?Z00zYUNuYmdiNFZDT2orOEhEcHd0NDVjNmdBaVlFcXYxb1ZOL29ERHFsRmxM?=
 =?utf-8?B?YVhiMnNXcFhtUU1OT1BaYmdlMjgxUXRoQ0tRY0VxZUo4WHgrbkx3cndGdXl2?=
 =?utf-8?Q?2c+k=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aee61445-d58e-4bc3-b458-08dd8e1b7f02
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 10:31:30.5446
 (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: c4Cn+OknnJryY9xNP39AfY2RxvzEm3RDFgfXEWhLvveou05E3lVWUhHzC/NWAC96
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4230



On 08/05/2025 12:30, Stewart Hildebrand wrote:
> On 5/8/25 02:56, Orzel, Michal wrote:
>> On 05/05/2025 09:52, Orzel, Michal wrote:
>>>
>>>
>>> On 05/05/2025 04:56, Stewart Hildebrand wrote:
>>>> Erroneous logic was duplicated from add_ext_regions() into
>>>> add_hwdom_free_regions(). Frame numbers are converted to addresses, but
>>>> the end address (e) is rounded down to page size alignment. The logic to
>>>> calculate the size assumes e points to the last address, not page,
>>>> effectively leading to the region size being erroneously calculated to
>>>> be 2M smaller than the actual size of the region.
>>>>
>>>> Fix by adding 1 to the frame number before converting back to address.
>>>>
>>>> Fixes: 02975cc38389 ("xen/arm: permit non direct-mapped Dom0 construction")
>>>> Signed-off-by: Stewart Hildebrand 
>>> Acked-by: Michal Orzel 
>>
>> I wanted to commit your fixes but rebase is required after recent dom0less code
>> movement. Please do.
> 
> Yes, I have already rebased locally. I'll send later today. Is it okay
> to keep your A-b tag?
Yes, of course.

~Michal



From xen-devel-bounces@lists.xenproject.org Thu May 08 10:31:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 10:31:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979224.1365913 (Exim 4.92)
	(envelope-from )
	id 1uCyXc-0002nY-QY; Thu, 08 May 2025 10:31:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979224.1365913; Thu, 08 May 2025 10:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uCyXc-0002nR-NE; Thu, 08 May 2025 10:31:48 +0000
Received: by outflank-mailman (input) for mailman id 979224;
 Thu, 08 May 2025 10:31:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCyXb-0001eT-9B
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 10:31:47 +0000
Received: from fout-b5-smtp.messagingengine.com
 (fout-b5-smtp.messagingengine.com [202.12.124.148])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a3554a4c-2bf7-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 12:31:45 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.stl.internal (Postfix) with ESMTP id 29D461140106;
 Thu,  8 May 2025 06:31:44 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Thu, 08 May 2025 06:31:44 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 8 May 2025 06:31: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" 
X-Inumbo-ID: a3554a4c-2bf7-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1746700304;
	 x=1746786704; bh=B0EPi84e7/VOCLlVJjqRSlFSmdqIi5vIcf35n7RzJuA=; b=
	nnhyMd0hUn5ekRRg3omIx4/mbuhbQYkaazgagz3j/DsUc1HymXl7+utqhosQf39w
	R7SciCSE0IorjGU3pcV4PQE7eWJ3OtGpMrgQKH5tboHJSWjbvIVS5ENk72WFNfXQ
	Ww+CRvF8jMVoBoI/8SOoRPF4I4w5vpcYJhif6m/17NA1U/QHLgEHfH5DeMS+swf3
	FiTwOWMX2rsdeKJXBmZxZnLDzDw57nbLxzPE4n3ZCvXwBJFNxROZqZUIEEGVGihv
	ZZy5JMbc5+R3EfKX7Z9RzU5/nyrHVaF+wmvEg6CPVi0jn4crPHYMAdw8PNIBaqXW
	PBJGjIcAMMDS5SLrCFmu4g==
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=fm3; t=
	1746700304; x=1746786704; bh=B0EPi84e7/VOCLlVJjqRSlFSmdqIi5vIcf3
	5n7RzJuA=; b=gyYoF+Tou/ktqpN7Gp8leheQauo9rRMMZ18ISMy/y+Fxehegy43
	U5o4q9X+j3PttZEIlAAw3Bt2z4NTo9f/aCybVGJX6ykDSsk/g/0yJ9MnxUWG7/GK
	4CsICoSpoLlQCucDeaO94eQM2Flk19DCRm0djJ9dJznKM11w9S8R6ooyHR3ULRwJ
	LPG70bymZNrVZIjp1hg7V1OWYsnXvvNWcy4uJsfNo6Age0Z4frlBfmIdvCnMMnEn
	HYEKDbn09RKLrKdvmIfA4QmRRV+oBsYEP8ljr8a8QHVthylaWl0ApU1TBSuISx3Q
	3woZb1CuM8xYXdqjzzhBe+4ABkNnfkveUAg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvkeelhedtucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettd
    dvgeeuteefjedunecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhf
    rhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
    dpnhgspghrtghpthhtohepjedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprghn
    ughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopehgvghrrg
    hlugdrvghluggvrhdqvhgrshhssegtlhhouhgurdgtohhmpdhrtghpthhtohepgigvnhdq
    uggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepug
    hpshhmihhthhesrghpvghrthhushhsohhluhhtihhonhhsrdgtohhmpdhrtghpthhtohep
    fhhrvgguihgrnhhordiiihhglhhiohestghlohhuugdrtghomhdprhgtphhtthhopehjsg
    gvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtoheprhhoghgvrhdrphgruhestghi
    thhrihigrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 8 May 2025 12:31:40 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Gerald Elder-Vass ,
	xen-devel@lists.xenproject.org, dpsmith@apertussolutions.com,
	Frediano Ziglio ,
	Jan Beulich ,
	Roger Pau =?utf-8?B?TW9ubsOp?= 
Subject: Re: [XEN PATCH v3] sbat: Add SBAT section to the Xen EFI binary
Message-ID: 
References: <20250507135442.3439237-1-gerald.elder-vass@cloud.com>
 <94652153-99fe-47d8-84d5-cbf2865ad6e0@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="aBxSmMj0cUHPezIt"
Content-Disposition: inline
In-Reply-To: <94652153-99fe-47d8-84d5-cbf2865ad6e0@citrix.com>


--aBxSmMj0cUHPezIt
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 May 2025 12:31:40 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Gerald Elder-Vass ,
	xen-devel@lists.xenproject.org, dpsmith@apertussolutions.com,
	Frediano Ziglio ,
	Jan Beulich ,
	Roger Pau =?utf-8?B?TW9ubsOp?= 
Subject: Re: [XEN PATCH v3] sbat: Add SBAT section to the Xen EFI binary

On Thu, May 08, 2025 at 09:51:59AM +0100, Andrew Cooper wrote:
> Also,
>=20
> > ld: warning: orphan section `.sbat' from `prelink.o' being placed in se=
ction `.sbat'
>=20
> This is because sbat.o is getting linked into the non-EFI build of Xen to=
o.
>=20
> I'm less sure how to go about fixing this.=C2=A0 There's no nice way I can
> see of of getting sbat.o only in the EFI build.=C2=A0 The other option is=
 to
> discard it for the ELF build.

This is kinda related to my question on Matrix - is multiboot2 binary
also supposed to (eventually) support UEFI SB?

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--aBxSmMj0cUHPezIt
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgciAwACgkQ24/THMrX
1yz82wf/dEl9brIiYv4zkUEO1g/4ynmWxF28rTb6iXlZ42vIocPDPUSOmF9xIpwv
i+5EdjS9oWnBBxCzA+pX+bQ0ipDRBFF+qnbMqPwDOoh4Dno90FaFxqyBZzAR8XCv
9QPDhUGogs+9pBuw4fond8jeudDylICpi/zHDo/+9S5yym8py8ZfG63Nh36DlwG3
zBxIDP/WaLSaXVRSFoMaT7QaE1DujD6p4M+8v63KY08bE045C0Zk5pS8Q06KzEXf
FWvdbiT1Nk8MqHorXj5vrgB/5tO57Z5lHmLLO+PyGy29M6LzAQPhQmeDO0RfdiC1
AZID4Y1xcMJpTffe3u2XYbNHg3qj5g==
=wY4t
-----END PGP SIGNATURE-----

--aBxSmMj0cUHPezIt--


From xen-devel-bounces@lists.xenproject.org Thu May 08 10:34:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 10:34:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979249.1365923 (Exim 4.92)
	(envelope-from )
	id 1uCyac-0003kR-Ce; Thu, 08 May 2025 10:34:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979249.1365923; Thu, 08 May 2025 10: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 1uCyac-0003kK-8i; Thu, 08 May 2025 10:34:54 +0000
Received: by outflank-mailman (input) for mailman id 979249;
 Thu, 08 May 2025 10:34:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCyaa-0003k2-BD
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 10:34:52 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20617.outbound.protection.outlook.com
 [2a01:111:f403:2413::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 11b8ab6b-2bf8-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 12:34:49 +0200 (CEST)
Received: from MW4PR04CA0197.namprd04.prod.outlook.com (2603:10b6:303:86::22)
 by DS0PR12MB7725.namprd12.prod.outlook.com (2603:10b6:8:136::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.21; Thu, 8 May
 2025 10:34:42 +0000
Received: from SJ5PEPF000001D7.namprd05.prod.outlook.com
 (2603:10b6:303:86:cafe::a5) by MW4PR04CA0197.outlook.office365.com
 (2603:10b6:303:86::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.31 via Frontend Transport; Thu,
 8 May 2025 10:34:41 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001D7.mail.protection.outlook.com (10.167.242.59) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 10:34:41 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 05:34:40 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 05:34:40 -0500
Received: from [172.31.225.170] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 05:34: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" 
X-Inumbo-ID: 11b8ab6b-2bf8-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PZAy30jCbunrvrgW0ozYWResiItqkdAgmTql1WgyCA0tRIKqxdLw0XBw1hJwtbckQdze49eFJeDf0Iwp0mCJeT3cc+1W7DwB/3vRcsomCjv5zRiUBuQpVa5cia1SCje4Y0XeJVX7fjLKTbyuiMl7o4O6/4pbTyk8DtgVU9J36jqf9WgxdwfidOHlHRejSNynZ3EHkZ5PDklFr8ZofTJmHesygf7wTL6z8AcUCgRGsl8cQ3XfAvr51ETWliio4yslFLOGIX12VsuUiKY8p6fsUlkFrLTboy4RPzUjYkzc9hYqBdPyQH+arluD0/jSDAUXzfV15N679lSbu3vkuD8Itg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=i12JiDrnO37DYnmXkyBbAwamtQar5VJ2G6xuK0rQwYQ=;
 b=IT9GstKHAiVAcT7Omp7JaVVifSHbtAB5OjU2tAGqmdL8ROpoDTFoQjsj9rC7+uGUEcfLQPP1jBg5B4hbwOUv8SBNjskZczNsiWiGvpA773Iz8eMYArxBWjdQD4Wd4gmOxI51ukH4gVrCf0pjUq2ggduVieh7HLZ1DMSJUVWJ4R/0t5oeUDmiz/vh2FMQcUdwQffoOUqgGS9bRA95Oz9f3VTas0mHgsHGRAdr7I2LwQB3eSh44PrfKKG8YF7ssz72/VrFe2oZ34iqeq6lqnq9ER5UsahzCzXYFsP/jWOlAYl9kCKAXjdi3BfQ/Bze6Ib6/v5M619bMvu12k//eClTYA==
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=i12JiDrnO37DYnmXkyBbAwamtQar5VJ2G6xuK0rQwYQ=;
 b=TgRMVw3MUWPbD+GZ8j0wzWe1ilvyxakJX3aydbpTB4ujJkRc0Y+A62kegpPmMyz3LbuOXOindjr1G2q6fb6kiYMVzMXPmWvn1z227/BBBNT21poLQng4YXldxvL+A9d1gG9ZG6L4hdDj9Wk51NT5ugL/OgMU05MAUqO9tWAZwAs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Thu, 8 May 2025 06:34:38 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v20 2/2] vpci: translate virtual PCI bus topology for
 guests
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
CC: Julien Grall , , Oleksandr
 Andrushchenko , Anthony PERARD
	, Stefano Stabellini ,
	Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	Jiqian Chen , Mykyta Poturai 
References: <20250418185840.335816-1-stewart.hildebrand@amd.com>
 <20250418185840.335816-3-stewart.hildebrand@amd.com>
  <3693f1ef-e305-4a6b-bb4e-3b842418387f@amd.com>
  
  <47ee8b59-7b6a-4248-a4bd-f5be9f00f562@amd.com>
 
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D7:EE_|DS0PR12MB7725:EE_
X-MS-Office365-Filtering-Correlation-Id: ab3c1fbf-13c9-4c56-c814-08dd8e1bf0fa
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OHVMaXk0YVVDU2RhaDIyc3ZNSjZYVjE0TnNkQ3ZiU3JyNmluWXpqV1R6Tm96?=
 =?utf-8?B?UExINVJyTk9QU2didHk4NEE4SzlyUy9wWHBDVFRhRzVzZHJVWWVNcGIyM1lS?=
 =?utf-8?B?eW1JOVlQYkEwVU1MV1dIbVJxM0ZlRU1zVzEyaW5ZK25nRVdoWVZudWxEK1pE?=
 =?utf-8?B?WDZPWFJ3L2tDeGh3TURDYUVzZUZia0t6ZnVJdVN5YTl5NDhTYUFraFBwUmUy?=
 =?utf-8?B?aDR2RnBUVzl5WWtnbzQxSUtYQUpjanF6djBaY09XenpMbFVVYU91dVZXaEFL?=
 =?utf-8?B?aGZMSkJKZGh0T1dkK25oY0lKUkh4aFRvTVNjc1JaNUpqb0VjbUdPZElVdXBF?=
 =?utf-8?B?ZlpuYjgxSjhoZnpwZnl5Tm1JZDFRWG9wOVNRaHpoRVhNUFZZM1hwYkc4QlA4?=
 =?utf-8?B?MUlFWmJGUjZuOGRtYzIyUWphODhRVGp1YVQyVEtZSkZTazV0YU1pbGt6cXZR?=
 =?utf-8?B?cFF1ekhLNU1NUGxSem5ycm94MG1ERXlMTGRtV0xGUUpKdUYwRFVvTEorZWd5?=
 =?utf-8?B?bVByWjdvL1A2TFVMVUtmWG9mV2RrNExoakFMc1piT280eEVibnovOERlT0R6?=
 =?utf-8?B?OU9JTnRlQjJyRm80Qi9ydTRkK2FhSi95QklSL0RnTHY0Y2d2cHpEem1hbkZv?=
 =?utf-8?B?YWlUckNPVE5hZUQvb0d4ZHlVekI3OVVwSGlvOUpPNEUyY0NDRDhrdkZPTmdD?=
 =?utf-8?B?VmhhdmlQR1hkbFVQV0tETjl0elEyeFZLVVNVNEdaUEpWN2Q4d0JsMHcwTXZq?=
 =?utf-8?B?MFF3OW1NeWhpRnJZa1lKU1BtTzQwOTZoMlV0NkRraWl1UGdHS3hkN2RXdkk5?=
 =?utf-8?B?b1lUMnp0eWEzU0k1cGh6UDBGUG1YUzNHeTFUa2N4dEZRdTBwdC8vbUZlb1da?=
 =?utf-8?B?SWJxeENFMGFiVW5odkRNTjhtRld4cXA3TXFyYjFIRmVvck1ZWU5qWVNDcCtj?=
 =?utf-8?B?eEJlRE42OEdYVEt1dGY5OU4zRGRrK1o0UCsxa1BZOHh2N0lIeTBxSlV4NVVP?=
 =?utf-8?B?S2dOcTRQTUVyQmNrVmtXZzgyNkRWNjRwZ090ZkxETjgvRGdUMnNnS29kdFd2?=
 =?utf-8?B?ZVFSVWd2amtWd2REUGJqQkdhaHRLdG9tM2QwN0FBbURwcnhFZFhVT0t4QUNX?=
 =?utf-8?B?OWFDYUpBTzRCazJaV3o3djRjaURQaGNqaGZ6MjVheU13dHFEL3hjM3ZoYkVL?=
 =?utf-8?B?aXVWY2R2bVFrb0doVlhTS1FxYUUydFEzUk0zOHBFSE1iV2xWWWZSeUtEcmFj?=
 =?utf-8?B?czVhaHg2amdXSko2cHVCckNrV3Z4TWZ5bG12bmVML3QrdzltK0hobE0rOE1R?=
 =?utf-8?B?TDFYWDBHSTNRWmZyN1FMc3o4WWVUaEUzN1JKRlBlVnlnSW5HcXZ5RjJuT3NO?=
 =?utf-8?B?aGpKUE1PSUNrZ256UU5GVFNMYmdSaEplcFlzY3VpanFmdVRGKzVQaE5JY0c5?=
 =?utf-8?B?YzdKcWdoV3lYNEtoMHZ1NEJCclVWTXc0NVlKaFl2R1orU0h3cUNRVkM5RkxW?=
 =?utf-8?B?YzBCdUFIWnhmR1VFS1JmYzIrSDZEL2lOQS95VTNCelkxZkdDaWNwVmNSZENV?=
 =?utf-8?B?N2pLL0dlMjRMSkw1b21mYWxydzZxekphSkVtWnZEakg4MmxkWDJCeUI5eXhR?=
 =?utf-8?B?U2tJelN1N3Q4QzRzaUhxZDNhVUI2dVRSN2FMTlh5VG1LMW8zUThlclFHT1ZU?=
 =?utf-8?B?cFZQcEFzd3FyZElIbE12azZjZ1E2UE9tUE9Ic1NxUHdvQ213Z2owbGNJcFNa?=
 =?utf-8?B?T3NkNXR5ZGMxWVd4NU9VNStPeFdrQkk2d1FiNGhRWU43bWxhSVliNU1aTkJZ?=
 =?utf-8?B?Q3BuTUVNUmRBM0pNQTN5K0JjRWNKdFJqNW5PdUg4U1Rtbnc5YVVMMk9HTmZI?=
 =?utf-8?B?RlBYa1VucnZRd3VhbHJiSFZpQlVQQTdyZEt4b2E3TDEzdXE2WjFGclY4WGhT?=
 =?utf-8?B?VDgrZzZSZ2I0T3puQnZkbUc1bVpDSCtITm1RQ2ZGY3hZMVZ5b04ybGZ2bnk5?=
 =?utf-8?Q?7XUnloQtp5Qa8vkJV08aNCR6hzj3H4=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 10:34:41.3283
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ab3c1fbf-13c9-4c56-c814-08dd8e1bf0fa
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001D7.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7725

On 5/8/25 04:32, Roger Pau Monné wrote:
> On Wed, May 07, 2025 at 05:17:58PM -0400, Stewart Hildebrand wrote:
>> On 5/7/25 13:44, Roger Pau Monné wrote:
>>> On Wed, May 07, 2025 at 09:38:51AM -0400, Stewart Hildebrand wrote:
>>>> On 5/7/25 03:44, Roger Pau Monné wrote:
>>>>> On Tue, May 06, 2025 at 11:05:13PM -0400, Stewart Hildebrand wrote:
>>>>>> On 5/6/25 07:16, Roger Pau Monné wrote:
>>>>>>> On Fri, Apr 18, 2025 at 02:58:37PM -0400, Stewart Hildebrand wrote:
>>>>>>>> From: Oleksandr Andrushchenko 
>>>>>>>>  static int vpci_register_cmp(const struct vpci_register *r1,
>>>>>>>>                               const struct vpci_register *r2)
>>>>>>>>  {
>>>>>>>> @@ -438,7 +473,7 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
>>>>>>>>      const struct pci_dev *pdev;
>>>>>>>>      const struct vpci_register *r;
>>>>>>>>      unsigned int data_offset = 0;
>>>>>>>> -    uint32_t data = ~(uint32_t)0;
>>>>>>>> +    uint32_t data = 0xffffffffU >> (32 - 8 * size);
>>>>>>>
>>>>>>> This seems kind of unrelated to the rest of the code in the patch,
>>>>>>> why is this needed?  Isn't it always fine to return all ones, and let
>>>>>>> the caller truncate to the required size?
>>>>>>>
>>>>>>> Otherwise the code in vpci_read_hw() also needs to be adjusted.
>>>>>>
>>>>>> On Arm, since 9a5e22b64266 ("xen/arm: check read handler behavior") we
>>>>>> assert that the read handlers don't set any bits above the access size.
>>>>>
>>>>> I see.  That kind of diverges from x86 behavior, that AFAICT (see
>>>>> memcpy() at tail of hvmemul_do_io()) instead truncates the memcpy to
>>>>> the size of the access.
>>>>>
>>>>> Maybe it would be better to instead of asserting just truncate the
>>>>> returned value to the given size, as that would allow to just return
>>>>> ~0 from handlers without having to care about the specific access
>>>>> size.
>>>>
>>>> The impression I get from [0] is that that on Arm, there's no benefit to
>>>> performing truncation in xen/arch/arm/io.c. Doing so would needlessly
>>>> affect other Arm internal read handlers (e.g. vGIC).
>>>
>>> But isn't this truncation desirable in order to avoid possibly setting
>>> bits outside of the access size?
>>
>> On Arm we expect the read handlers to have the bits above the access
>> size zeroed. If a read handler sets bits above the access size, it could
>> indicate a bug in the read handler. As a reminder, this was already
>> discussed at [0] and a patch was already committed 9a5e22b64266
>> ("xen/arm: check read handler behavior"). Perhaps we could both keep the
>> ASSERT (for debug builds) and perform truncation (for release builds) in
>> xen/arch/arm/io.c:handle_read(), but that's patch for another day.
>>
>> [0] https://lore.kernel.org/xen-devel/20240522225927.77398-1-stewart.hildebrand@amd.com/T/#t
> 
> Oh, I see.  I already expressed concerns on that thread about forcing
> the truncation to be done by handler implementations vs truncating in
> a generic place ahead of propagating to the registers.
> 
> My main concern is when returning ~0, as it seems cumbersome to have
> to truncate that, and I think we do blindly return ~0 on more than one
> x86 IO handler.
> 
>>>> For vPCI
>>>> specifically, however, we could potentially perform truncation in
>>>> xen/arch/arm/vpci.c. So I guess it's a question of whether we want to
>>>> give special treatment to vPCI compared to all other read handlers on
>>>> Arm?
>>>
>>> I would think doing the truncation uniformly for all reads would be
>>> better, as we then ensure the value propagated to the registers always
>>> matches the access size?
>>>
>>> I'm not expert on ARM, but it seems cumbersome to force this to all
>>> internal handlers, instead of just truncating the value in a single
>>> place.
>>
>> To move this forward, I suggest performing this truncation in
>> xen/arch/arm/vpci.c:vpci_mmio_read(). This will be a single place to
>> perform truncation for Arm vPCI, and will not affect other Arm internal
>> mmio handlers.
> 
> You already have the mask there, so it should be easy to do:
> 
> *r = data & invalid;
> 
> To truncate the value.  Could you send that as a separate patch with a
> Fixes tag?

Yes, will do


From xen-devel-bounces@lists.xenproject.org Thu May 08 10:46:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 10:46:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979268.1365943 (Exim 4.92)
	(envelope-from )
	id 1uCylo-00062Q-Js; Thu, 08 May 2025 10:46:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979268.1365943; Thu, 08 May 2025 10:46: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 1uCylo-00062H-H0; Thu, 08 May 2025 10:46:28 +0000
Received: by outflank-mailman (input) for mailman id 979268;
 Thu, 08 May 2025 10:46:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCyln-00061s-5y
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 10:46:27 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20629.outbound.protection.outlook.com
 [2a01:111:f403:2417::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id afeb5920-2bf9-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 12:46:26 +0200 (CEST)
Received: from BN9PR03CA0299.namprd03.prod.outlook.com (2603:10b6:408:f5::34)
 by PH7PR12MB6883.namprd12.prod.outlook.com (2603:10b6:510:1b9::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.27; Thu, 8 May
 2025 10:46:20 +0000
Received: from BL6PEPF0001AB4C.namprd04.prod.outlook.com
 (2603:10b6:408:f5:cafe::c6) by BN9PR03CA0299.outlook.office365.com
 (2603:10b6:408:f5::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.30 via Frontend Transport; Thu,
 8 May 2025 10:46:20 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB4C.mail.protection.outlook.com (10.167.242.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 10:46:19 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 05:46:19 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 05:46:18 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 05:46:17 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: afeb5920-2bf9-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=r86qIHyF+WcwebDZD7IK01fIMh4zZQ12C67Z5w9CFwo5BOa2kcIdsGAOOPSdh/cXHq9jQccS3dartLeycQbD3eG0rX/ECU+eYvnVAffXDoWlHQqI1v+RwhFaj6jQ71nG7I/ApKT9hqUnf6fWNKmhdLCakh1JJ1R+n2Ru0xjFK0vwyytRgk4J/FB2e+eTDUZ6jArLXrk6wSz9QwXI45d0y5QVp4jFqPuSknknmAapt9l/ld5sMWD7D9C2IvdL2Of/muGbbuV+TMaoPTLXuoxUaeDBsngUK9ec297yA+zeKveOmWRDVog3yeQ1rYBepBpglGjShBPw92u/29rSQVRIqQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=pYTYGm7TjGTCoufqxQwgoqyUeE4OFG8EYrCyN+3Hwuk=;
 b=BUFaZEXR1gSG1MUw/8YnfoBJFGN9usaanAjoIsXIyQ+xeIQ3fJNQoS/+EmWFwiQvpX4fdpWSSCrwKGVxrwU0a3rVBRUKCtCiHbYYZ2eCbrxg1w+PILwi4DgtkT46ev5TQTp/6Clgpkvy4n5npNDOpvFI+08TGRnBSiAi2r2cs5rD4/fTrFCr322BuIyFZKBCPPV48U7XC3J/A2e6RdRVOIYnJ8m7N41dzsrPooGP4Gk6eIcHg2EBVUAOp0k2PLK7WXgFanf0SGj8sFIDU0q9rCJMj61Khb5MLpEhIwmZ6d+0pEfQAw1elFd2bjSiF4gM1LmX7iYfyyXlcqP0S6hmeg==
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=pYTYGm7TjGTCoufqxQwgoqyUeE4OFG8EYrCyN+3Hwuk=;
 b=WxunnU6jjUscLyQ4LAZpx5NGrTGNirAVMH2lhmAmsvOSFbhtIFw+w+EqFc2FOCcVxu5fA9kMKKKrUoFbUwTsPTvQPk0dwKesQAjWZXgdo4xVPbFnbguwIv4lcZ1QSmByVf075uku8kRq3Bc7DlfMRiyPV/ppSEuI4BJWc5iYHBg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v21 1/2] arm/vpci: mask off upper bits in vPCI read mmio handler
Date: Thu, 8 May 2025 06:46:06 -0400
Message-ID: <20250508104608.531079-2-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250508104608.531079-1-stewart.hildebrand@amd.com>
References: <20250508104608.531079-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB4C:EE_|PH7PR12MB6883:EE_
X-MS-Office365-Filtering-Correlation-Id: 1f24d0ea-9f16-49f0-b48f-08dd8e1d9120
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?8zNQKmvEsdArCG2wNvUTAdiCOEZtxYMFnOGH5sDjI5ksTQ0IfgiqJn0oDg/m?=
 =?us-ascii?Q?1777oJQgC2fqDjjW8lQxAVOCciRK5AmYqHgUZAqIUgGWSXb8NSu+7VZLYIY9?=
 =?us-ascii?Q?dDmzHvXhqss02bQ3hAub0iQ9YHhfcWNabag5UwX1IV2V4731qlkRPHl44llv?=
 =?us-ascii?Q?FYvGBq0bVTrsRenEbGxNXroBfdtzoLTYpHGgytqFo35Y4ZxAb6tyQFrd+aN1?=
 =?us-ascii?Q?dyIiw4f38+WZKgNAVYr6sXyEyVJQs15fxiza4brzSQsMw+MJY5wQB697j/Qk?=
 =?us-ascii?Q?FEiVtj5cOE0QOas7Ehy+qhJiZ8QTbVi9WdWnhV7Eh7aPXTs5i+IafRYO8upp?=
 =?us-ascii?Q?cEkIi24takGbg21O+jqsTfwdA3EZDJaQxZIz4vNQfTzFH5Lcp6AGfjD+S6oU?=
 =?us-ascii?Q?CGeID49+9IPJHlMhvlnSvYmR7IZWCJpwigATx/rc1COAWqTdHH1/9cisMvYR?=
 =?us-ascii?Q?MTr0K3YyIuUf1XaGsb99JaqGTwI64vzYpl/0floQZRpvglAPsDALAbAd74B/?=
 =?us-ascii?Q?2qZWB/GS6vvMay19GBunv33R+lVX/Gis0EKG7s78uiuFJFYBrU6UYHFbTnBl?=
 =?us-ascii?Q?jRfRqgm+PJddbws3prw/UB8BkWrc+bjc8xf1ScyZjfGyUnUzrvy+lnyaHNdm?=
 =?us-ascii?Q?NQdk8jnSKV08UPh62o3e+5fY+4C1YBUbUUc9sYrRpbD0PVAyf0hhR3CO87X7?=
 =?us-ascii?Q?CWzgr39Ng5/hQH9WGGDkIWkox5NEBGI66YzazvKIp9RB3rPKzQ9wE3HpGIuU?=
 =?us-ascii?Q?wR5zDP9IAx8odmVm21tHDXLXky56TeZtgk72ceWRhmJGhlPIJ0Cq85KfKeAN?=
 =?us-ascii?Q?sLOjcSiw6PZ+sYDDzfXCtcd2LYbazVnVaj2+WNVW0zZQIyS0BH8ifq1twf/a?=
 =?us-ascii?Q?vU2yUr1EN2TPniuRJkMaYgMow/Xr0Yz5fCZcf3tT5eEh8/oeky4hf6AjB4IV?=
 =?us-ascii?Q?DUNeOJ2qZ/1A44dtnBZ8kLBxTxv/7HwzH8FyXwD0FKOSzFcZV/NWeINDUWyA?=
 =?us-ascii?Q?J+62WRcH5Jr0ZAh3CedKJ1wYEYrqmhEauNJfPX4A3Na6mz00TPBgOn9e9kb5?=
 =?us-ascii?Q?mddQGgLPUfoWWzD9umWi2IRtm2/D8iuhD1ZJKpQ5BmXfwE6biZy3Vuk1fSnL?=
 =?us-ascii?Q?3PpN4EXEvz4MTmRSbEMuxbnJAS2UGbpGuSGE/s+VT1y4CAe+T8Zq7IaWbDWO?=
 =?us-ascii?Q?3fuLVlinzHr+0qM6Ow9xVZvR+uz+S0M+1FHdX9o21lQgoIuivpvC73IaaDan?=
 =?us-ascii?Q?irSOYJOx+Tj8b7XeGx4XxyPXfhyiSL3yrgDiErLyf6C8/OU9APX9yAOTIWts?=
 =?us-ascii?Q?GBX2hobw7n4X+h9MFoy1dqMVPNFRCQqCc+PilzAzn3+w7ezIXe+/XAc5w7NO?=
 =?us-ascii?Q?Ag+NeHhcbHipnO6VUXQqKBoCFBoeHVts6nMnFuNJRY+iWJNV4en6BzJK5z6V?=
 =?us-ascii?Q?5csok+u3KcC5bTQspxjPOfAN6+Sl8pIkL0BZx+rKXr+hXJYIwon5bNu0sVDs?=
 =?us-ascii?Q?8BfeHCCZn6FuEQJw1QMRcgoZ8WWKAzMRhHrK?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 10:46:19.6062
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f24d0ea-9f16-49f0-b48f-08dd8e1d9120
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF0001AB4C.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6883

On Arm, we expect read handlers to have the bits above the access size
zeroed. vPCI read handlers may return all 1s. Mask off the bits above
the access size.

Fixes: 9a5e22b64266 ("xen/arm: check read handler behavior")
Signed-off-by: Stewart Hildebrand 
---
 xen/arch/arm/vpci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
index b63a356bb4a8..3a3ff5d0812c 100644
--- a/xen/arch/arm/vpci.c
+++ b/xen/arch/arm/vpci.c
@@ -37,7 +37,7 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
     if ( vpci_ecam_read(sbdf, ECAM_REG_OFFSET(info->gpa),
                         1U << info->dabt.size, &data) )
     {
-        *r = data;
+        *r = data & invalid;
         return 1;
     }
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 08 10:46:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 10:46:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979267.1365933 (Exim 4.92)
	(envelope-from )
	id 1uCylk-0005oC-C8; Thu, 08 May 2025 10:46:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979267.1365933; Thu, 08 May 2025 10: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 1uCylk-0005o5-9B; Thu, 08 May 2025 10:46:24 +0000
Received: by outflank-mailman (input) for mailman id 979267;
 Thu, 08 May 2025 10:46:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCylj-0005ny-2u
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 10:46:23 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20609.outbound.protection.outlook.com
 [2a01:111:f403:2405::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id acc55900-2bf9-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 12:46:20 +0200 (CEST)
Received: from BL1PR13CA0439.namprd13.prod.outlook.com (2603:10b6:208:2c3::24)
 by DS7PR12MB8419.namprd12.prod.outlook.com (2603:10b6:8:e9::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Thu, 8 May
 2025 10:46:11 +0000
Received: from BL6PEPF0001AB4B.namprd04.prod.outlook.com
 (2603:10b6:208:2c3:cafe::40) by BL1PR13CA0439.outlook.office365.com
 (2603:10b6:208:2c3::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.19 via Frontend Transport; Thu,
 8 May 2025 10:46:11 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB4B.mail.protection.outlook.com (10.167.242.69) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 10:46:11 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 05:46:10 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 05:46: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" 
X-Inumbo-ID: acc55900-2bf9-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=maFqqtC+7liCX1VQ/HW7S00juE0jWdaUBBXMypuGBL+XnNINlOGtMjwlYVIzMpCoK/jzDgJBnyMYJuUZU+9a6LhLmOwH9x4rFYFqmj7ssShG9iIslqleq/k58gmZB7+LhpT8eStYe3KcgboXkQqC2H8hsS1C/fi9iBqihREe94s5IVocYRAMagAXQ9dNL1+odhJkq8rwwrzdp4z83qH8FtXtEfWaFwaedbfNx3I1erN6/zCNVWOVCnqtH83gKHitNpn7C6EPdWaexuQEd7jLt4tDFCgNXkmrqfLGl8GEIfpvBt6ej1b1wBtUuyJxwpaejiknwABUORpIzW2R6nCj1g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zjhxUYigasu2Vr7pmkoEjJuoL8GkNXfVq3z6mzHd+so=;
 b=u8nmjNW3WtMiztz1+FkrB/vCmPjedYgbzlNB9aeyJ4AjSVZ+DK6IAwBE5QZQNcePdx1WJyMuv08ZpLU6ck+NQn1VETyy7X1/C5XDPSdy8H7xHs3oVr+lqV/J6KqrUgMsxLahJdAcn1jOCo1qu6/+ecWxrrFG7YPi/6ocTOBjAs38oeUewbamp/hewdI1AO/t7JvH9xdZ6+U0AIkNXh4+iSlodX75KsZ48ndcBzgwKrL1XM9xgEE1bb+7+rZ+72l1jIr5gyE5zN930kBzJZ3bxf/yUZ5UjXAe3j6uUZVOUv/STtyV/YphQeVjRdMy/WonGT3OyC7nmjRnUTBjOXNFNA==
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=zjhxUYigasu2Vr7pmkoEjJuoL8GkNXfVq3z6mzHd+so=;
 b=DZUr+jdsxiNzIQfthwjyDl1oBoIwrR07kzeBXcSGL3T82mzr9VgmHskj7pky2/HSqzsJZbAgSKpKplT2bzKmjCDDXPZkMC4lR6a4gO94LXtMvL57Dqk6Opx3uopj1wcAaM9+b4AiQGylQbf9ef6mvUxSlHmgqmwsJ5UDpJA/JYc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Anthony PERARD , "Jiqian
 Chen" , Mykyta Poturai 
Subject: [PATCH v21 0/2] PCI devices passthrough on Arm, part 3
Date: Thu, 8 May 2025 06:46:05 -0400
Message-ID: <20250508104608.531079-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB4B:EE_|DS7PR12MB8419:EE_
X-MS-Office365-Filtering-Correlation-Id: b70363d8-2627-4675-eaba-08dd8e1d8c06
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?1tqacg/l6JR8zuqrjhZjgPyDJYIEeCDqADe7HVz2XoJIDQ7BvPNMnhB9JWCZ?=
 =?us-ascii?Q?URnyYJz+FZftjmsGYzQj3qaiClCt7xgBGaI7KE0YltVa3WECPEei7KWlu1Hi?=
 =?us-ascii?Q?PYbVot2e9noDyYEgcRCm9tNiomR+r1Rw0ACtyt+PCj1z6Six/d2VMO4wHq77?=
 =?us-ascii?Q?z7mZFr0o+fPjnwHsYyx1ly1KAkB9Fqu0LZ9Hw21mcuXZaw0RpBTegl7rsHif?=
 =?us-ascii?Q?O9Sqm+HZ0xee4jGD9ksmgW7vkj3ebSABExt+vxxDmK6oC3YOLSmFykXJPoWK?=
 =?us-ascii?Q?n2gfzZ0zAG8Gx8zvo0EngjeS8nB4CTfwj5ozpvPGi+1Yt7hMgQDfw5PpbmLE?=
 =?us-ascii?Q?8uYBtKTzTpxuB/uQ4BrEpYo29CJV7iBYlqKcXO3VzmC6WM36OzmiqUbqWI3q?=
 =?us-ascii?Q?MffLZsWPrBPPbNSc8uP0ohhZ9sOe0sXTpJt8i20Vm621y5zOriOclxJEvgV/?=
 =?us-ascii?Q?Z+ERQODQHrdePn05DMyt4QZfDstNGQiCXKvfngYx7bPfyUUsbRQ+Wa00LZYf?=
 =?us-ascii?Q?IUdwiKPaKPN18rg/UZ8PJ6Be6JGig8Br7ieNYkpBgDsuIgs4w0jyvQhT/Os/?=
 =?us-ascii?Q?4LmGGpOa3IAjg8IiUpCyu+n2GFmSfQL96W49VoS+jrIk+5C8cQC4uOHVrbFQ?=
 =?us-ascii?Q?Cj478R08CdwF4qQfviCrvGORJY2Ge9rjNkwm49tAUKuOrfB8ZGaYVkA805Oq?=
 =?us-ascii?Q?LWVoq7OIAbprCwb2KX7RK4jDetI36F5ktXnR0zTS/LJa6XCUsU36mJ4AIeEK?=
 =?us-ascii?Q?PLiGN2NGSuD4d6AOM9DeBfzINBk9JJYh/3FyRdpfDkwc+nzDiSbGFqmSjMmK?=
 =?us-ascii?Q?0AaybOh8EiwTFTTJKU3+sQuduL+eFLba6Yy/BHwBqPyYJ56642KIHRd7+jjw?=
 =?us-ascii?Q?5obzFd4kDdmyjNpYVtK6rqpLUvqT5cT0b0QPjt/uzdLXq/vxuUKGEZneNVqj?=
 =?us-ascii?Q?AYPqual41FqMr6iThEd3Sfz/c7ArCocwg+0JQI8bRJnDakjl7LmmYzad4Nnz?=
 =?us-ascii?Q?OWvg3VCqLTvgtZdy0PGWIi9bnGMQXK/MG6CsMuCgnhq6C9Jd/i5yjHUBRjbx?=
 =?us-ascii?Q?HQMxdB2jNR7uIH8cjkeIZDxoVN1R1bfkKLdObVHd51VjiwqozJsqVmnpj/u5?=
 =?us-ascii?Q?kvlv7RpJ7BTOwRKL50FcuMhGmvqJihO0V5fIdcOgp5EHnB7+ncb7slUI2K5p?=
 =?us-ascii?Q?Th1VWNXirowM7p1eGc5p9eR2xTxDmCu8oAh47Ru1PrmvHRbriCcIPf/aANBw?=
 =?us-ascii?Q?+eftzDBpWYD46mSfZgqb+z8Son18zJOLE8HzGRl+TOCRTLGVT71Bvl52Uq7E?=
 =?us-ascii?Q?dWUjHXIPAIUh0+SF73cSHFE94beLoRgl/T0YzRmzD46UvQC478rCcVYxXufE?=
 =?us-ascii?Q?Wd4Z+Og1pI54P7y2V0OxZFNpmr2zAFUGZMYzUT22dNe/aL1tq4KvYOjklx05?=
 =?us-ascii?Q?Dk9DizZxB/nw8rvF7h61sje/nnLX6pg2XLHHjxf8Mr79F9tfmK3lkjIN8DZK?=
 =?us-ascii?Q?IPLc3y7vOdEqWdsnOMni7L+Y1nkEMZ7Up0d5?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 10:46:11.0487
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b70363d8-2627-4675-eaba-08dd8e1d8c06
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF0001AB4B.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB8419

This is next version of vPCI rework. Aim of this series is to prepare
ground for introducing PCI support on ARM platform.

in v21:
* drop ("xen/arm: check read handler behavior") as it was committed
* add ("arm/vpci: mask off upper bits in vPCI read mmio handler")

in v20:
 - drop ("vpci: acquire d->pci_lock in I/O handlers") as it was
   unnecessary

in v19:
 - ("xen/arm: check read handler behavior") is ready to be committed
 - add ("vpci: acquire d->pci_lock in I/O handlers")

in v18:
 - address warning in vpci test suite

in v17:
 - add ("xen/arm: check read handler behavior")
 - drop ("xen/arm: account IO handlers for emulated PCI MSI-X") as it
   should wait for future work
 - drop committed patches

in v16:
 - minor updates - see individual patches

in v15:
 - reorder so ("arm/vpci: honor access size when returning an error")
   comes first

in v14:
 - drop first 9 patches as they were committed
 - updated ("vpci/header: emulate PCI_COMMAND register for guests")

in v13:
 - drop ("xen/arm: vpci: permit access to guest vpci space") as it was
   unnecessary

in v12:
 - I (Stewart) coordinated with Volodomyr to send this whole series. So,
   add my (Stewart) Signed-off-by to all patches.
 - The biggest change is to re-work the PCI_COMMAND register patch.
   Additional feedback has also been addressed - see individual patches.
 - Drop ("pci: msi: pass pdev to pci_enable_msi() function") and
   ("pci: introduce per-domain PCI rwlock") as they were committed
 - Rename ("rangeset: add rangeset_empty() function")
       to ("rangeset: add rangeset_purge() function")
 - Rename ("vpci/header: rework exit path in init_bars")
       to ("vpci/header: rework exit path in init_header()")

in v11:
 - Added my (Volodymyr) Signed-off-by tag to all patches
 - Patch "vpci/header: emulate PCI_COMMAND register for guests" is in
   intermediate state, because it was agreed to rework it once Stewart's
   series on register handling are in.
 - Addressed comments, please see patch descriptions for details.

in v10:

 - Removed patch ("xen/arm: vpci: check guest range"), proper fix
   for the issue is part of ("vpci/header: emulate PCI_COMMAND
   register for guests")
 - Removed patch ("pci/header: reset the command register when adding
   devices")
 - Added patch ("rangeset: add rangeset_empty() function") because
   this function is needed in ("vpci/header: handle p2m range sets
   per BAR")
 - Added ("vpci/header: handle p2m range sets per BAR") which addressed
   an issue discovered by Andrii Chepurnyi during virtio integration
 - Added ("pci: msi: pass pdev to pci_enable_msi() function"), which is
   prereq for ("pci: introduce per-domain PCI rwlock")
 - Fixed "Since v9/v8/... " comments in changelogs to reduce confusion.
   I left "Since" entries for older versions, because they were added
   by original author of the patches.

in v9:

v9 includes addressed commentes from a previous one. Also it
introduces a couple patches from Stewart. This patches are related to
vPCI use on ARM. Patch "vpci/header: rework exit path in init_bars"
was factored-out from "vpci/header: handle p2m range sets per BAR".

in v8:

The biggest change from previous, mistakenly named, v7 series is how
locking is implemented. Instead of d->vpci_rwlock we introduce
d->pci_lock which has broader scope, as it protects not only domain's
vpci state, but domain's list of PCI devices as well.

As we discussed in IRC with Roger, it is not feasible to rework all
the existing code to use the new lock right away. It was agreed that
any write access to d->pdev_list will be protected by **both**
d->pci_lock in write mode and pcidevs_lock(). Read access on other
hand should be protected by either d->pci_lock in read mode or
pcidevs_lock(). It is expected that existing code will use
pcidevs_lock() and new users will use new rw lock. Of course, this
does not mean that new users shall not use pcidevs_lock() when it is
appropriate.

Changes from previous versions are described in each separate patch.

Oleksandr Andrushchenko (1):
  vpci: translate virtual PCI bus topology for guests

Stewart Hildebrand (1):
  arm/vpci: mask off upper bits in vPCI read mmio handler

 tools/tests/vpci/emul.h |  2 +-
 xen/arch/arm/vpci.c     |  6 ++++-
 xen/drivers/vpci/vpci.c | 53 ++++++++++++++++++++++++++++++++++++-----
 3 files changed, 53 insertions(+), 8 deletions(-)


base-commit: aea52ce607fe716acc56ad89f07e1513c89018eb
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 08 10:46:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 10:46:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979272.1365953 (Exim 4.92)
	(envelope-from )
	id 1uCym2-0006Rq-12; Thu, 08 May 2025 10:46:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979272.1365953; Thu, 08 May 2025 10:46: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 1uCym1-0006Rj-Ss; Thu, 08 May 2025 10:46:41 +0000
Received: by outflank-mailman (input) for mailman id 979272;
 Thu, 08 May 2025 10:46:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCym0-00061s-Ll
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 10:46:40 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20622.outbound.protection.outlook.com
 [2a01:111:f403:2414::622])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b8d2b17b-2bf9-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 12:46:39 +0200 (CEST)
Received: from BL0PR02CA0069.namprd02.prod.outlook.com (2603:10b6:207:3d::46)
 by SN7PR12MB8028.namprd12.prod.outlook.com (2603:10b6:806:341::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Thu, 8 May
 2025 10:46:33 +0000
Received: from BL6PEPF0001AB4F.namprd04.prod.outlook.com
 (2603:10b6:207:3d:cafe::d8) by BL0PR02CA0069.outlook.office365.com
 (2603:10b6:207:3d::46) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.30 via Frontend Transport; Thu,
 8 May 2025 10:46:33 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB4F.mail.protection.outlook.com (10.167.242.73) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 10:46:32 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 05:46:32 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 05:46:32 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 05:46: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" 
X-Inumbo-ID: b8d2b17b-2bf9-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vPW8arZwYrz9tYcIY/dStTCDrRL37gGH2MhgcV4bWZvCaM04K96wC8SgrBgwdn38bKSyyjHSCcT+oJcwmReusKxUBn6s+VTkMTl1+asbyxeINybBM3WBsgEloqusigBQHT3hYNmVin6tZsaKBvtatJvn8Mu69jLKld8b2TAp02WPGI7MLerzcZyQfCkPimyC11dSlcD63m5C7F58w49sciJeQiGyfALqT5nwyvPuC8RiJy+fQ/IZIA5mD38jBwGxZVG67+dHLHOaxlnrN3D++ue/8XfGDtx8wo9ZA0mnbO5tbNE3xKUbygCXtoJRP56cj/mBEtfJbQvmj9jarQlMUQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=07oonBGuyFDrFTpIXfAPomqVLfYtNQTC2ByuuwV+kOM=;
 b=FDkX3O/M5EshUjWBRXzcBa+hCXpbkzyzeCtqld0t9WfpBemaFa/SB42pmJd2tAFWHDDx9Tm2lkxadgoyG1WiHTGoRn7SIQg1hq0HULHeApn8Zpc8O5Y5ZihZ9vo4PUWevXTG8mtOTB4pYH+H9UFLeRjVikxzdcH2LwLJun9SR5QGwNBDGFwRTz1c1TM4O5imMFKXjjGvC6yiJo1DQ7TTSrqUXmJVNSAJ40IL4u21tkiKdIAkMudC4O239lbih2sGqOOLvm+urhVu0yI8Hfl4HQK7kd8jpnjVzT1DDSDrdTuifvMJy0asxEsE0e32zQHgJGLXE/IV23ayPd+G8jebAQ==
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=07oonBGuyFDrFTpIXfAPomqVLfYtNQTC2ByuuwV+kOM=;
 b=zRxy2ejl0meWOqlq4QXh5klNduUjkyBmxvHjjE+bgjvOYuBvdQHzEgtPz+Q43ilSimjU/0F2PLXj2falBRDRQzX32dbBrszH/hAj7lqdr8LsmXF2K8SSmWFxyZ0MQnnSq43bvW6HWW8R4LKe1iidLXbL4yyME6jr8zOpDeuN6XM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Oleksandr Andrushchenko ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stewart
 Hildebrand" , Anthony PERARD
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Michal Orzel , Volodymyr Babchuk
	, Jiqian Chen , "Mykyta
 Poturai" , Volodymyr Babchuk
	
Subject: [PATCH v21 2/2] vpci: translate virtual PCI bus topology for guests
Date: Thu, 8 May 2025 06:46:07 -0400
Message-ID: <20250508104608.531079-3-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250508104608.531079-1-stewart.hildebrand@amd.com>
References: <20250508104608.531079-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB4F:EE_|SN7PR12MB8028:EE_
X-MS-Office365-Filtering-Correlation-Id: b2c16bb7-9bf9-4f5e-8afe-08dd8e1d98fe
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?r78BNYUWb05AiWcxnduacsgo60yqCD1li1gbqD/Z+9b4rkCzYQUeJl4IjL9p?=
 =?us-ascii?Q?AH5uXS3YRBxjvxDAJ/s4zB55ASYEcmMqcMHsLu1nmDeqRDQe8fIzbMEbw6w2?=
 =?us-ascii?Q?G3BUvrxgt/G45hFoWP/sdmGJQqhX7MbTpHnkp5mazN24WBiqcVDVFEXnNeME?=
 =?us-ascii?Q?jtrRFkKKSQ+lZUYA/41JXNZU6kSBwhgZjqYnLzFuTEkxl1YUal1xYMKcb0O0?=
 =?us-ascii?Q?pMhZeFa8RZQhLpAtLDpaKjF4NcIJdvviTpzPLyLAqLMhwkKfQzUPg7ivsodj?=
 =?us-ascii?Q?EH8GvNcKg6cHHpibgmvSt7Z2gkiWM5u60QYC8nsoThmi6V61AJIdX7DJSNtE?=
 =?us-ascii?Q?3zGD/gkRc0ZFiRD3iYcVTkiLexF78Vy72vPtQ1PG39i1OnNNwp42y4EQD0O5?=
 =?us-ascii?Q?jdcQL6CvCMvxzV+BAq9X3DV+mSBAfjCiLq1OusQOWkW3TeX+LbIws3Hxd9XP?=
 =?us-ascii?Q?GPiVRWIrmVeYazP3KNeqhr7SUpiHLDeVwV8hw/3wW/XxYQqjYJInuJqtD8uf?=
 =?us-ascii?Q?o9cJlYBxZeXv1lU0Ge5rXDe3lbSHErthjZMHLbeLw0Li8S7LU2/5k9xsNKjh?=
 =?us-ascii?Q?aFTjlT/ckd04m3nyRtmtFLzTlFQQ7fKPkTAeNqCQP6WIwHtnqgIyAliNaLLk?=
 =?us-ascii?Q?j0TDK3I9v5xPfcedOPUfQSjIMT06T2hpE2xY1+4GNlD+aXnccmzVUBlTJAr2?=
 =?us-ascii?Q?+J/sVJgWHDOvwK6s4HzDJa5i0NtK37eWWxKwTodtn4oIP7WwSY4EP0l4KtzS?=
 =?us-ascii?Q?3E3Rkz+mrnidL8Bypv/9SWT2JYJMcpAQUjumT9CJz88fDQPcnuwxfL7FiJS0?=
 =?us-ascii?Q?jTUDTNPO0Gvy/QWtw3bs7Prz2+anAX5LirPL/tKhsWo/k3TVybFAt7BfEm3g?=
 =?us-ascii?Q?tmzVKk2AuX6Z5u1D2yKtyexRnc5PgNYGskKglTlrp98Cpr4j0K/DYP6mcRP3?=
 =?us-ascii?Q?uiJfRp7Zuiwd8jyrscxXaTUsh1YXY3Szk6W7sEiQuZIx7XYdzC+8CS9cwnih?=
 =?us-ascii?Q?po+etFq8AjlngN//NYFOMvLKcEsivB/4GGwvrX9uCpzCLrJfmnE1wKyzReyo?=
 =?us-ascii?Q?5bLT/6UO35BIJSPg3KzwfC7OmmQ+qE0XdDjnxMGUSpA4ek+pAjhQARkeLOYL?=
 =?us-ascii?Q?2BaubmfaTMHdKK3RP6XwWIOoBQ/H0HjWaWIg//vXzDEFZZq7Jz/i/w/jPFeH?=
 =?us-ascii?Q?SIWa1cX936yAYRWjx9oNwz57vjKcgAMi091kB5Irr0eyGyH9PKxidxg1R1S8?=
 =?us-ascii?Q?GeqU8gy8PGY5FBiRd8sIPuCA+iFBYxomnoPKqtoeAue3DWa82TGpdq3VuC1Y?=
 =?us-ascii?Q?fRJs8QHJWURhJOoGzqcuzRoa4FhLq0ErwUi//F+IretcpohBtKVdMpjTPXKB?=
 =?us-ascii?Q?Q87hlilfW+q9gA4bES4DcWycm5KqkI2VyR409e7wNbUI0RzsNFLWnZKgrcOW?=
 =?us-ascii?Q?+KfmORxijWOCKpfj1vZnkOIdCWBe6Boin5XT+p++0AuKYS6EBpvU1SfRIlLv?=
 =?us-ascii?Q?HnquCeulsZaLZTNvGyT0AtqXT8GIk3bYqYT0yhJcs7vB9a5Wkbs3PDTo3Q?=
 =?us-ascii?Q?=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 10:46:32.8038
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b2c16bb7-9bf9-4f5e-8afe-08dd8e1d98fe
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF0001AB4F.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8028

From: Oleksandr Andrushchenko 

There are two originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs guest's view on the configuration space.
2. Guest access to the passed through PCI devices: we need to properly
map virtual bus topology to the physical one, e.g. pass the configuration
space access to the corresponding physical devices.

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Volodymyr Babchuk 
Signed-off-by: Stewart Hildebrand 
---
In v21:
* adjust #ifdef
* remove redundant return path
In v20:
* call translate_virtual_device() from within locked context of
  vpci_{read,write}
* update commit message
In v19:
* move locking to pre-patch
In v18:
* address warning in vpci test suite
In v17:
* move lock to inside vpci_translate_virtual_device()
* acks were previously given for Arm [0] and vPCI [1], but since it was
  two releases ago and the patch has changed, I didn't pick them up

[0] https://lore.kernel.org/xen-devel/4afe33f2-72e6-4755-98ce-d7f9da374e90@xen.org/
[1] https://lore.kernel.org/xen-devel/Zk70udmiriruMt0r@macbook/

In v15:
- base on top of ("arm/vpci: honor access size when returning an error")
In v11:
- Fixed format issues
- Added ASSERT_UNREACHABLE() to the dummy implementation of
vpci_translate_virtual_device()
- Moved variable in vpci_sbdf_from_gpa(), now it is easier to follow
the logic in the function
Since v9:
- Commend about required lock replaced with ASSERT()
- Style fixes
- call to vpci_translate_virtual_device folded into vpci_sbdf_from_gpa
Since v8:
- locks moved out of vpci_translate_virtual_device()
Since v6:
- add pcidevs locking to vpci_translate_virtual_device
- update wrt to the new locking scheme
Since v5:
- add vpci_translate_virtual_device for #ifndef CONFIG_HAS_VPCI_GUEST_SUPPORT
  case to simplify ifdefery
- add ASSERT(!is_hardware_domain(d)); to vpci_translate_virtual_device
- reset output register on failed virtual SBDF translation
Since v4:
- indentation fixes
- constify struct domain
- updated commit message
- updates to the new locking scheme (pdev->vpci_lock)
Since v3:
- revisit locking
- move code to vpci.c
Since v2:
 - pass struct domain instead of struct vcpu
 - constify arguments where possible
 - gate relevant code with CONFIG_HAS_VPCI_GUEST_SUPPORT
New in v2
---
 tools/tests/vpci/emul.h |  2 +-
 xen/arch/arm/vpci.c     |  4 ++++
 xen/drivers/vpci/vpci.c | 53 ++++++++++++++++++++++++++++++++++++-----
 3 files changed, 52 insertions(+), 7 deletions(-)

diff --git a/tools/tests/vpci/emul.h b/tools/tests/vpci/emul.h
index da446bba86b4..dd048cffbf9d 100644
--- a/tools/tests/vpci/emul.h
+++ b/tools/tests/vpci/emul.h
@@ -89,7 +89,7 @@ typedef union {
 
 #define __hwdom_init
 
-#define is_hardware_domain(d) ((void)(d), false)
+#define is_hardware_domain(d) ((void)(d), true)
 
 #define has_vpci(d) true
 
diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
index 3a3ff5d0812c..0ce11ffcc508 100644
--- a/xen/arch/arm/vpci.c
+++ b/xen/arch/arm/vpci.c
@@ -34,6 +34,8 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
     /* data is needed to prevent a pointer cast on 32bit */
     unsigned long data;
 
+    ASSERT(!bridge == !is_hardware_domain(v->domain));
+
     if ( vpci_ecam_read(sbdf, ECAM_REG_OFFSET(info->gpa),
                         1U << info->dabt.size, &data) )
     {
@@ -52,6 +54,8 @@ static int vpci_mmio_write(struct vcpu *v, mmio_info_t *info,
     struct pci_host_bridge *bridge = p;
     pci_sbdf_t sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
 
+    ASSERT(!bridge == !is_hardware_domain(v->domain));
+
     return vpci_ecam_write(sbdf, ECAM_REG_OFFSET(info->gpa),
                            1U << info->dabt.size, r);
 }
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 1e6aa5d799b9..d2f0f97e0a04 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -174,6 +174,35 @@ int vpci_assign_device(struct pci_dev *pdev)
 }
 #endif /* __XEN__ */
 
+/*
+ * Find the physical device which is mapped to the virtual device
+ * and translate virtual SBDF to the physical one.
+ */
+static const struct pci_dev *translate_virtual_device(const struct domain *d,
+                                                      pci_sbdf_t *sbdf)
+{
+#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
+    const struct pci_dev *pdev;
+
+    ASSERT(!is_hardware_domain(d));
+    ASSERT(rw_is_locked(&d->pci_lock));
+
+    for_each_pdev ( d, pdev )
+    {
+        if ( pdev->vpci && (pdev->vpci->guest_sbdf.sbdf == sbdf->sbdf) )
+        {
+            /* Replace guest SBDF with the physical one. */
+            *sbdf = pdev->sbdf;
+            return pdev;
+        }
+    }
+#else /* !CONFIG_HAS_VPCI_GUEST_SUPPORT */
+    ASSERT_UNREACHABLE();
+#endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
+
+    return NULL;
+}
+
 static int vpci_register_cmp(const struct vpci_register *r1,
                              const struct vpci_register *r2)
 {
@@ -453,9 +482,15 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
      * pci_lock is sufficient.
      */
     read_lock(&d->pci_lock);
-    pdev = pci_get_pdev(d, sbdf);
-    if ( !pdev && is_hardware_domain(d) )
-        pdev = pci_get_pdev(dom_xen, sbdf);
+    if ( is_hardware_domain(d) )
+    {
+        pdev = pci_get_pdev(d, sbdf);
+        if ( !pdev )
+            pdev = pci_get_pdev(dom_xen, sbdf);
+    }
+    else
+        pdev = translate_virtual_device(d, &sbdf);
+
     if ( !pdev || !pdev->vpci )
     {
         read_unlock(&d->pci_lock);
@@ -571,9 +606,15 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg, unsigned int size,
      * are modifying BARs, so there is a room for improvement.
      */
     write_lock(&d->pci_lock);
-    pdev = pci_get_pdev(d, sbdf);
-    if ( !pdev && is_hardware_domain(d) )
-        pdev = pci_get_pdev(dom_xen, sbdf);
+    if ( is_hardware_domain(d) )
+    {
+        pdev = pci_get_pdev(d, sbdf);
+        if ( !pdev )
+            pdev = pci_get_pdev(dom_xen, sbdf);
+    }
+    else
+        pdev = translate_virtual_device(d, &sbdf);
+
     if ( !pdev || !pdev->vpci )
     {
         /* Ignore writes to read-only devices, which have no ->vpci. */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 08 10:46:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 10:46:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979276.1365962 (Exim 4.92)
	(envelope-from )
	id 1uCym9-0006ri-8X; Thu, 08 May 2025 10:46:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979276.1365962; Thu, 08 May 2025 10: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 1uCym9-0006rZ-5P; Thu, 08 May 2025 10:46:49 +0000
Received: by outflank-mailman (input) for mailman id 979276;
 Thu, 08 May 2025 10:46:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCym7-0005ny-J9
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 10:46:47 +0000
Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com
 [2607:f8b0:4864:20::c2b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bb85bcfe-2bf9-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 12:46:44 +0200 (CEST)
Received: by mail-oo1-xc2b.google.com with SMTP id
 006d021491bc7-60658e1fedfso417936eaf.2
 for ; Thu, 08 May 2025 03:46: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" 
X-Inumbo-ID: bb85bcfe-2bf9-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746701203; x=1747306003; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3GsdE/Bq9Qb2SH6Pu+1TyU9AWhTTfQaYciHoKdNdm+w=;
        b=D/54ZGz0dtP1NEZ4zGptEoCUFUPczmdZM2+UeGgOm37sR2iulcA0MobYUUzMFWNabl
         SWNubNz+E/FnaSFOmko0r+yCsCJtLkhgPjyyYx/DvEwwLQx/u9HzlIVtk6h0tUlHx5BS
         PijmJmTyIfZZuAiyzfC0deafaF8w5zBpc7FO8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746701203; x=1747306003;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=3GsdE/Bq9Qb2SH6Pu+1TyU9AWhTTfQaYciHoKdNdm+w=;
        b=Cwoss065UMwZwvF8iZxA4D/f1fYVvWEFQCywA7xm/OtaTYrG7Y32zn1SQ3mPyeySZE
         RYe26Iyrt9Nk0mjpsH+TkkLiplOqPAtRlMbMaY2KkQcEYZU4iOzMdvHvf9kBMJnzbGvk
         Qrujct4RhjFtVS0XZp9c1EM7G4pTa6jDnsjWH9QrlqlE+O90SGxvtfEeDOAZCYMC/jrO
         o+V2a5ubBwFufxx1c7wjog08VgbVbYlYnD+JjgsqgNnB+gMzF9P0Za4uxOtkIvbfXZtw
         5D3jNX1dqPjnDWoO9Gat/S3nzj7R7xKVtunIjnROwdDcHZrx1qy3csLG4/RvLNKoliKG
         rjug==
X-Forwarded-Encrypted: i=1; AJvYcCUpOIAG+mo9XSnPsFi4EiqYHr7x3tSl3xGyzXQimj7BDpRksNUCBDcoPLzCSjgU78sPWDnNBvMgp+M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxXWJ+wDr4V6AF8LBKp8sbUJsjKaivKEvz1ev+jlCYArd4NIPiN
	HyXTbH9MQlijZMU/+krhY8oCvpIT9y1gEguwpBpdKyh6ezTiyuUS2fwcGGGip+fRsHSv2myTEdd
	8qWwR4r09/5x3D0qwBlQDBNhChmOha7JYPuCSUQ==
X-Gm-Gg: ASbGncvdGyWzJKmjtjfnij10X7QtIQ/kdC353kiBrYn9KmesP7ZB1d4KbTtOvwcB7Ei
	FLNFVfAEiCbBt0iupjxKpFl4PtBREdPoUQUCeAPTm2X5a62guf6+M7gUsDDR4kI/PZK1OTU+i7b
	zxf42XLltLGbsgqEVLM2B6kw==
X-Google-Smtp-Source: AGHT+IG5CojiMPqD+3LVaJqhX4dtC3cXYVTVgeGvgS8NfJTP8fbQ4itZWI/sDWYzXkemwRRsGAr0qvss0d8Qa9KqyBA=
X-Received: by 2002:a05:6820:4c85:b0:606:462:5d1a with SMTP id
 006d021491bc7-60828c9a2ecmr4149264eaf.2.1746701203595; Thu, 08 May 2025
 03:46:43 -0700 (PDT)
MIME-Version: 1.0
References: <20250507135442.3439237-1-gerald.elder-vass@cloud.com> <94652153-99fe-47d8-84d5-cbf2865ad6e0@citrix.com>
In-Reply-To: <94652153-99fe-47d8-84d5-cbf2865ad6e0@citrix.com>
From: Frediano Ziglio 
Date: Thu, 8 May 2025 11:46:32 +0100
X-Gm-Features: ATxdqUFiSRuNSL6F40f6ViwbMKTWTLLcwzB3iXhIwG1lEVVVv2jXGRQtcBAXRbw
Message-ID: 
Subject: Re: [XEN PATCH v3] sbat: Add SBAT section to the Xen EFI binary
To: Andrew Cooper 
Cc: Gerald Elder-Vass , xen-devel@lists.xenproject.org, 
	dpsmith@apertussolutions.com, marmarek@invisiblethingslab.com, 
	Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 8, 2025 at 9:52=E2=80=AFAM Andrew Cooper  wrote:
>
> On 07/05/2025 2:54 pm, Gerald Elder-Vass wrote:
> > diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
> > index 24dfecfad184..75aa35870a9a 100644
> > --- a/xen/arch/x86/efi/Makefile
> > +++ b/xen/arch/x86/efi/Makefile
> > @@ -6,11 +6,17 @@ cmd_objcopy_o_ihex =3D $(OBJCOPY) -I ihex -O binary $=
< $@
> >  $(obj)/%.o: $(src)/%.ihex FORCE
> >       $(call if_changed,objcopy_o_ihex)
> >
> > +$(obj)/sbat.o: OBJCOPYFLAGS :=3D -I binary -O elf64-x86-64 --rename-se=
ction .data=3D.sbat,readonly,data,contents
> > +$(obj)/sbat.o: $(src)/sbat.sbat FORCE
> > +     $(call if_changed,objcopy)
> > +
>
> Doing a build locally with this, I've found two issues.  One is:
>
> > ld: warning: arch/x86/efi/sbat.o: missing .note.GNU-stack section impli=
es executable stack
> > ld: NOTE: This behaviour is deprecated and will be removed in a future =
version of the linker
> > ld: warning: arch/x86/efi/built_in.o: requires executable stack (becaus=
e the .note.GNU-stack section is executable)
> > ld: warning: arch/x86/built_in.o: requires executable stack (because th=
e .note.GNU-stack section is executable)
> > ld: warning: prelink.o: requires executable stack (because the .note.GN=
U-stack section is executable)
> > ld: warning: prelink.o: requires executable stack (because the .note.GN=
U-stack section is executable)
> > ld: warning: prelink.o: requires executable stack (because the .note.GN=
U-stack section is executable)
>
> which isn't a terribly good look on a "higher security" feature.  The
> easiest way to fix this is:
>
> $(obj)/sbat.o: OBJCOPYFLAGS :=3D -I binary -O elf64-x86-64 \
>         --rename-section .data=3D.sbat,readonly,data,contents \
>         --add-section .note.GNU-stack=3D/dev/null
>
> to add the required section.
>
>
>
> >  $(obj)/boot.init.o: $(obj)/buildid.o
> >
> >  $(call cc-option-add,cflags-stack-boundary,CC,-mpreferred-stack-bounda=
ry=3D4)
> >  $(addprefix $(obj)/,$(EFIOBJ-y)): CFLAGS_stack_boundary :=3D $(cflags-=
stack-boundary)
> >
> > +EFIOBJ-y +=3D sbat.o
>
> Also,
>
> > ld: warning: orphan section `.sbat' from `prelink.o' being placed in se=
ction `.sbat'
>
> This is because sbat.o is getting linked into the non-EFI build of Xen to=
o.
>
> I'm less sure how to go about fixing this.  There's no nice way I can
> see of of getting sbat.o only in the EFI build.  The other option is to
> discard it for the ELF build.
>

I don't see the point of having this section in the ELF file, it's
used only when in PE by secure boot.
It should not be hard to add it to the disard list. Specifically in
xen/include/xen/xen.lds.h file look at DISCARD_SECTIONS and
DISCARD_EFI_SECTIONS definitions (I think just add .sbat to the
DISCARD_EFI_SECTIONS list if EFI is not defined).

Frediano


From xen-devel-bounces@lists.xenproject.org Thu May 08 11:55:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 11:55:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979329.1365973 (Exim 4.92)
	(envelope-from )
	id 1uCzqt-0001A9-Tl; Thu, 08 May 2025 11:55:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979329.1365973; Thu, 08 May 2025 11:55: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 1uCzqt-0001A2-R7; Thu, 08 May 2025 11:55:47 +0000
Received: by outflank-mailman (input) for mailman id 979329;
 Thu, 08 May 2025 11:55:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uCzqt-00019w-5z
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 11:55:47 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5fd84597-2c03-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 13:55:45 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-43cf06eabdaso9316885e9.2
 for ; Thu, 08 May 2025 04:55:45 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442cd34bc2esm34854895e9.20.2025.05.08.04.55.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 08 May 2025 04:55:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5fd84597-2c03-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746705345; x=1747310145; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zvOGoDTtz8Vw6TGGlISgXM95xWmNwx05kmoiJxwkvkc=;
        b=kFzDxzPitvsFZfttmTTFHAda8i3xd565n7uBdyAfjRnTR5gZa/8kAkl+erjk2lqWoN
         ebHW2OWNsN8wSyFNDgWh3rBJYMv+7mL7CbNkdSTKxnPGAmmjNNPvQ5dSNM/SzwbQeoqv
         RnbphUpMWT5FTgjR0mJW3tBtYOJQDAdU3QXSc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746705345; x=1747310145;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zvOGoDTtz8Vw6TGGlISgXM95xWmNwx05kmoiJxwkvkc=;
        b=OaCFBspMLHc7+K1j7vdkW7Swr3RaM6WuVzTN1wO9VDK/rdQvEN4g8I76WWAj+BmFP8
         L9/0lPFo0TPZBdXL0/ZysOM1EVpFca4PsBC0GS0Zm1iCa/mv5O1vvUlHn1G9fiqWiTU7
         qOz1DNSQ0XvjciPItxmpalEgn20x+m5hxtOqfQekDmsvGhpdBiZr7t6TPAVSryxz2q92
         jxZqa0r+g31WCuWfITbiITIBWGHQBhBQuOlP5FNdv+eHUt50oNFojQOO9UnIdv0X35Qj
         ls19DF/uchf/MZUVU8xlTz7SdsAw7/rvIZ5YTfOb1qt5blbdnuW/RE2kd7PBVKHlnLmu
         ztsQ==
X-Forwarded-Encrypted: i=1; AJvYcCVB+MVxqjdzmJl4GI8PNRzQiyX8YW44a5OfIjH59fEMp4N7CD0krNedt7cugxfWm7hMdmFDQ82rNRc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy3eQxSNiSimgbgtdP+ohLtvYWDEknteEZMqrC5aQFTSm7eQogA
	XZ1CKTTCVwj2QAAIHznMN8dCUfUp6clQAWqH89ALl+21OD8vxWkCzCeYMj1FXlQ=
X-Gm-Gg: ASbGncuSyHB7FaHgbbZx5OsXcW1u/yHDGiDkzD5x1+s3579AYOCnkGkDNAUwkmrWa3S
	2sfBm8jfUsuTvEfj3DjNlR5a++AgYennL3/Wv3VIceYexnaI+qJ8qDCeGBZdO072TTNaN3psOSi
	kyMiiVb8uRLs+c+MP/Nz0ST4fzuwdo2kye9BP5iahKPCpo3bd9a6e8A56DsOntIOUwmardo7ZU5
	rE13bYE7MVhmzBsUEh4UcYmGMsJESZ5Jah3Qsx45TqWh1wuCIo5/PNknvRLxVPoXSsO5HmnO3a+
	KMoe9QfYvx+0GVIeXjmhm49Qlo4IcP51yol7CTTNl1o5bYaG3Xo0z6Bbi7vt/7dLbXCECkDtOoa
	ffs/taaXxktJsgoES
X-Google-Smtp-Source: AGHT+IES8YljOE6v2sC3P+OmZhc0Ypbn0NKoc5fUy/GJgycJX5BxuADcQVjMkwjNYmzcAtIXC3Ilpg==
X-Received: by 2002:a05:600c:3ca1:b0:43c:ec28:d31b with SMTP id 5b1f17b1804b1-441d44c457emr70009825e9.10.1746705344849;
        Thu, 08 May 2025 04:55:44 -0700 (PDT)
Message-ID: 
Date: Thu, 8 May 2025 12:55:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3] sbat: Add SBAT section to the Xen EFI binary
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Gerald Elder-Vass ,
 xen-devel@lists.xenproject.org, dpsmith@apertussolutions.com,
 Frediano Ziglio , Jan Beulich
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250507135442.3439237-1-gerald.elder-vass@cloud.com>
 <94652153-99fe-47d8-84d5-cbf2865ad6e0@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

On 08/05/2025 11:31 am, Marek Marczykowski-Górecki wrote:
> On Thu, May 08, 2025 at 09:51:59AM +0100, Andrew Cooper wrote:
>> Also,
>>
>>> ld: warning: orphan section `.sbat' from `prelink.o' being placed in section `.sbat'
>> This is because sbat.o is getting linked into the non-EFI build of Xen too.
>>
>> I'm less sure how to go about fixing this.  There's no nice way I can
>> see of of getting sbat.o only in the EFI build.  The other option is to
>> discard it for the ELF build.
> This is kinda related to my question on Matrix - is multiboot2 binary
> also supposed to (eventually) support UEFI SB?

This is mixing two things.

Xen is either an ELF binary (ultimately zipped, so xen.gz) or is an EFI
binary (xen.efi).

Both of these binaries currently have an MB2 header.  This was by
accident, as xen.efi is a strict superset of the ELF build.

AIUI, SBAT only makes sense to exist in the EFI binary.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu May 08 12:28:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 12:28:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979347.1365984 (Exim 4.92)
	(envelope-from )
	id 1uD0Mf-0005ez-EP; Thu, 08 May 2025 12:28:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979347.1365984; Thu, 08 May 2025 12: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 1uD0Mf-0005es-9y; Thu, 08 May 2025 12:28:37 +0000
Received: by outflank-mailman (input) for mailman id 979347;
 Thu, 08 May 2025 12:28:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD0Md-0005em-V4
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 12:28:36 +0000
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com
 [2607:f8b0:4864:20::331])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f4b371e9-2c07-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 14:28:33 +0200 (CEST)
Received: by mail-ot1-x331.google.com with SMTP id
 46e09a7af769-7311a8bb581so704331a34.0
 for ; Thu, 08 May 2025 05: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" 
X-Inumbo-ID: f4b371e9-2c07-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746707312; x=1747312112; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=44T5OMorfHOKCGvj4mHS3mPDbc4n6JdYUOwE7sy2fIU=;
        b=bFv0ABbaK27kAg39pqNPXheNC+QMzGlXd5l7x1g27Wb5QLORm/U6kJGgt5tIBCAadV
         Pdqj6EOB8cz2FZ1yQrhMA3GKz2j7q5lpALGtiMsRABoeXEQG3AO4xoBRal/Gae6A9y5d
         x2MtrdJldYBzUJFLdo5jImNvEdwoDOlNGBYfk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746707312; x=1747312112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=44T5OMorfHOKCGvj4mHS3mPDbc4n6JdYUOwE7sy2fIU=;
        b=ZKPrtmWXz77Lg4G1WWiKjk6cSv0sJlv5oiinSjAy0q133zGyw4fhdNZbpAnc7A+VBk
         r5klPwYK3EaSot5BLa4Pl70JCyGshCft4erhYfOSbw4iCuBa2fx8J0xVcVJIw7KjE8Df
         lj0sza4ZW+C55Lps/eXiL2obl7Y2w6IifLOXQkriajoqrjUDqlg37T36c3LOFqPr8Psa
         o4C1fAGqZOrrh4mk9n/fYsUcDGCFkE8v28N+0CRrWY6YQckaR9ZVDAkC9qoRVW2c3X5C
         YCWa2c2yHrT+GtnYwt+oxFBKcsmsQ4UeP6qjbrE6zufjWH8BlbR7k91m35d95aSnAIMn
         JZXw==
X-Forwarded-Encrypted: i=1; AJvYcCU3VqsatyDmNnxqA46NzHgkiQNQiqPJXz2LEVnLG5zPR/n9QigQrp4M3/mbFzu+WvfDKoaZ4qB57pA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwZcyRneE27UpTA2YAjrH9o6HG64PblBuFAE37yW1LscxU059rv
	wDQjzUBqvtJl3WS7Tn06QmNHQQmYQRnUNqtnYeB0jqwtKXRXsMf9IcADJq8JVynCxkG/AHcqMqu
	VJmACyOQQwes0MHMXYUUlKBd4jAUN0tJ2gQiUKg==
X-Gm-Gg: ASbGncsK9cjJiiZC+Gz3p8cowF64JMPBMMT1d9wjwik7wCDV9KzmkAycaO2mm804P5U
	0NCIk9P1L7zoPow7YMrZmrmhxqQosNJZb2uaBNlrDcCwM5Tvket+lN0ML3ytwrjS2Mdgrr75PpI
	GzGsfPe9XO1EGmgXkvo3xF
X-Google-Smtp-Source: AGHT+IGSiMqAtNAruJHbQVd7nu7e/91PwpKHqnP9ppQ5oUuBTJuVd5dTtRKzC8ZIcNaXvufWtnlcU6LdjAwqZs0CzJs=
X-Received: by 2002:a05:6808:2016:b0:3f7:d16c:e283 with SMTP id
 5614622812f47-40377f23863mr1841973b6e.11.1746707312496; Thu, 08 May 2025
 05:28:32 -0700 (PDT)
MIME-Version: 1.0
References: <20250507135442.3439237-1-gerald.elder-vass@cloud.com>
 <94652153-99fe-47d8-84d5-cbf2865ad6e0@citrix.com>  
In-Reply-To: 
From: Frediano Ziglio 
Date: Thu, 8 May 2025 13:28:21 +0100
X-Gm-Features: ATxdqUFvfG0HOIyyKJXIqb5i3nRLTGXnv4GTo0SD429EKKfCTA25xnVtcDt0JvI
Message-ID: 
Subject: Re: [XEN PATCH v3] sbat: Add SBAT section to the Xen EFI binary
To: Andrew Cooper 
Cc: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Gerald Elder-Vass , xen-devel@lists.xenproject.org, 
	dpsmith@apertussolutions.com, Jan Beulich , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 8, 2025 at 12:55=E2=80=AFPM Andrew Cooper  wrote:
>
> On 08/05/2025 11:31 am, Marek Marczykowski-G=C3=B3recki wrote:
> > On Thu, May 08, 2025 at 09:51:59AM +0100, Andrew Cooper wrote:
> >> Also,
> >>
> >>> ld: warning: orphan section `.sbat' from `prelink.o' being placed in =
section `.sbat'
> >> This is because sbat.o is getting linked into the non-EFI build of Xen=
 too.
> >>
> >> I'm less sure how to go about fixing this.  There's no nice way I can
> >> see of of getting sbat.o only in the EFI build.  The other option is t=
o
> >> discard it for the ELF build.
> > This is kinda related to my question on Matrix - is multiboot2 binary
> > also supposed to (eventually) support UEFI SB?
>
> This is mixing two things.
>
> Xen is either an ELF binary (ultimately zipped, so xen.gz) or is an EFI
> binary (xen.efi).
>
> Both of these binaries currently have an MB2 header.  This was by
> accident, as xen.efi is a strict superset of the ELF build.
>

We are planning to use multiboot2 booting. The reason is the way we
want some parameters (like command line) to be passed. We are going to
use grub2.

> AIUI, SBAT only makes sense to exist in the EFI binary.
>
> ~Andrew

Frediano


From xen-devel-bounces@lists.xenproject.org Thu May 08 12:44:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 12:44:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979360.1365993 (Exim 4.92)
	(envelope-from )
	id 1uD0bV-0000Dd-Js; Thu, 08 May 2025 12:43:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979360.1365993; Thu, 08 May 2025 12: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 1uD0bV-0000DW-HA; Thu, 08 May 2025 12:43:57 +0000
Received: by outflank-mailman (input) for mailman id 979360;
 Thu, 08 May 2025 12:43:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD0bU-0000DA-3M
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 12:43:56 +0000
Received: from fout-b6-smtp.messagingengine.com
 (fout-b6-smtp.messagingengine.com [202.12.124.149])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1885c8eb-2c0a-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 14:43:53 +0200 (CEST)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfout.stl.internal (Postfix) with ESMTP id 7B3FC11400E9;
 Thu,  8 May 2025 08:43:51 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-04.internal (MEProxy); Thu, 08 May 2025 08:43:51 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 8 May 2025 08:43:49 -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" 
X-Inumbo-ID: 1885c8eb-2c0a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1746708231;
	 x=1746794631; bh=VjAzjMR97l41RykYlGvw8f0ThPA/qmCei8qGQl+8pio=; b=
	lX7SQr98W4Xx4E/2GUR/N02URW0jvy5TOPr4vG59Xzy0eYPIrRwj1Co3kXGe78y0
	rwzLJq5IKRSxJ12jP1miMl4XTy9y3NaSmbXqo1ChZdG1MDYFnRFkgqvW9oYM31sB
	/fvBSCHOguB2FxNaxXCw/Y0pk2S3vIiDn4m00PjdtD0+tfiVsU/dxksEaKuM0AiN
	nqwzewsq08koC5AsLR3I5C7IHjVKo6GYqtijSD88fa8Po2LBmYpqKBjxfD+R0Wq5
	3+cvJ3Uem2OkM+puW+mPIQR10jfW23HGwwVPhVY8+mNzjb61FmDtnUWWbFAgAEJ/
	ac2DBl+LAY2qhDWGhWkVnQ==
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=fm3; t=
	1746708231; x=1746794631; bh=VjAzjMR97l41RykYlGvw8f0ThPA/qmCei8q
	GQl+8pio=; b=FVlMEe6+x6f3rGrEen0UL95QqBwNYtbFVTYO6sON9mpRMiRBjQj
	PhjM5fqDM9PxR3QyQ/9Zu0o7MOflTZYwxCIhCR4429AteNoVaB2POEgl9/vlgHjh
	pIvpCOClv+ivGbvjDBscHAMYTTH0hqvo82RSoFB7rxbEXMmZnYyGdri5imnMkzNw
	UU4WB2J1dzqjQ6aLS49vbsEB3bUNaDCvr5tRmipopKk42VRBieZX2+kOWEZCIiBn
	uOr5P+Oz6EDaaKFUYQvLbq01sf/mUj89eWvauw6Fmc+UExL9sd9GrkGo/xFyauhM
	XNcsq+Y+wV4E1/A1IWLtw3qDTtYkSdBrUwg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvkeeljeejucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepieeluddvkeejueekhfffteegfeeiffefjeejvdeijedvgfejhe
    etuddvkeffudeinecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghr
    ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvh
    hishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeejpdhmohgu
    vgepshhmthhpohhuthdprhgtphhtthhopehfrhgvughirghnohdriihighhlihhosegtlh
    houhgurdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhi
    gidrtghomhdprhgtphhtthhopehgvghrrghlugdrvghluggvrhdqvhgrshhssegtlhhouh
    gurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhho
    jhgvtghtrdhorhhgpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhsohhluh
    htihhonhhsrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdp
    rhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 8 May 2025 14:43:47 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: Andrew Cooper ,
	Gerald Elder-Vass ,
	xen-devel@lists.xenproject.org, dpsmith@apertussolutions.com,
	Jan Beulich ,
	Roger Pau =?utf-8?B?TW9ubsOp?= 
Subject: Re: [XEN PATCH v3] sbat: Add SBAT section to the Xen EFI binary
Message-ID: 
References: <20250507135442.3439237-1-gerald.elder-vass@cloud.com>
 <94652153-99fe-47d8-84d5-cbf2865ad6e0@citrix.com>
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="yxgSmfUD35M1RgN/"
Content-Disposition: inline
In-Reply-To: 


--yxgSmfUD35M1RgN/
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 May 2025 14:43:47 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Frediano Ziglio 
Cc: Andrew Cooper ,
	Gerald Elder-Vass ,
	xen-devel@lists.xenproject.org, dpsmith@apertussolutions.com,
	Jan Beulich ,
	Roger Pau =?utf-8?B?TW9ubsOp?= 
Subject: Re: [XEN PATCH v3] sbat: Add SBAT section to the Xen EFI binary

On Thu, May 08, 2025 at 01:28:21PM +0100, Frediano Ziglio wrote:
> On Thu, May 8, 2025 at 12:55=E2=80=AFPM Andrew Cooper  wrote:
> >
> > On 08/05/2025 11:31 am, Marek Marczykowski-G=C3=B3recki wrote:
> > > On Thu, May 08, 2025 at 09:51:59AM +0100, Andrew Cooper wrote:
> > >> Also,
> > >>
> > >>> ld: warning: orphan section `.sbat' from `prelink.o' being placed i=
n section `.sbat'
> > >> This is because sbat.o is getting linked into the non-EFI build of X=
en too.
> > >>
> > >> I'm less sure how to go about fixing this.  There's no nice way I can
> > >> see of of getting sbat.o only in the EFI build.  The other option is=
 to
> > >> discard it for the ELF build.
> > > This is kinda related to my question on Matrix - is multiboot2 binary
> > > also supposed to (eventually) support UEFI SB?
> >
> > This is mixing two things.
> >
> > Xen is either an ELF binary (ultimately zipped, so xen.gz) or is an EFI
> > binary (xen.efi).
> >
> > Both of these binaries currently have an MB2 header.  This was by
> > accident, as xen.efi is a strict superset of the ELF build.
> >
>=20
> We are planning to use multiboot2 booting. The reason is the way we
> want some parameters (like command line) to be passed. We are going to
> use grub2.

Which means that multiboot2 binary needs to be signed somehow, and for
MS to be happy, needs to include SBAT too.

Relevant series:
https://lore.kernel.org/xen-devel/20240328151106.1451104-1-ross.lagerwall@c=
itrix.com/
I don't recall seeing v3 posted.

And relevant grub series:
https://lore.kernel.org/xen-devel/20240328151302.1451158-1-ross.lagerwall@c=
itrix.com/

> > AIUI, SBAT only makes sense to exist in the EFI binary.
> >
> > ~Andrew
>=20
> Frediano

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--yxgSmfUD35M1RgN/
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgcpwMACgkQ24/THMrX
1ywMNwf/dyVtXhaDhhtskdBux0HZK5GmacoEjGfekF9ePCu1+hho6blFtlOMcLGb
ojzq6w4rhOPFGlvMOqnzbBpwNJUZd3rczOApTFeG4xownH3QDjLmwoUofM/Cm/2q
QBstivZjrg2/6s6KRJRQO2cqXqg5UaTFLt6loDfMJG15TUsIYtDxR/nJ4R1OS7i2
Wl9QD+jg1HpH6hOa6o5aeYZ9xMJN/Ej5TesrIqB+WbyQ0Ojq4r6fENZVbprkP7TL
uKd5U0hUyaq+J7PecWYNZ5TwE5u3YLxqO0MNDfYFzHD4iciH5kgytwoPEkDnVZiH
Io0f/7o2ecK44mGHHyM/Ba0Q5BRPhA==
=Sdn9
-----END PGP SIGNATURE-----

--yxgSmfUD35M1RgN/--


From xen-devel-bounces@lists.xenproject.org Thu May 08 13:21:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 13:21:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979385.1366027 (Exim 4.92)
	(envelope-from )
	id 1uD1Bg-0006BK-Uk; Thu, 08 May 2025 13:21:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979385.1366027; Thu, 08 May 2025 13: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 1uD1Bg-0006BD-R0; Thu, 08 May 2025 13:21:20 +0000
Received: by outflank-mailman (input) for mailman id 979385;
 Thu, 08 May 2025 13:21:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD1Bf-0005gg-KU
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 13:21:19 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2407::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 52862c0a-2c0f-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 15:21:18 +0200 (CEST)
Received: from BYAPR08CA0017.namprd08.prod.outlook.com (2603:10b6:a03:100::30)
 by DM4PR12MB5988.namprd12.prod.outlook.com (2603:10b6:8:6b::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.21; Thu, 8 May
 2025 13:21:08 +0000
Received: from SJ1PEPF00002323.namprd03.prod.outlook.com
 (2603:10b6:a03:100:cafe::b9) by BYAPR08CA0017.outlook.office365.com
 (2603:10b6:a03:100::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.29 via Frontend Transport; Thu,
 8 May 2025 13:21:07 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00002323.mail.protection.outlook.com (10.167.242.85) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 13:21:06 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 08:21:05 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 08:21: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" 
X-Inumbo-ID: 52862c0a-2c0f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ogK46fMNF/5T7TVjIfBzK0mhJwOz3Mn+baTQbFJ4ZdHw24W9G5Xlc+mLAk2khCdKtPdnFaT4UTYPbY/mOYqmxstlyMq0rVsvY4TIJ3SH0+nMab2pjXxF4QusP94RmsYo0dmU2yRo7iUyjvzt7z9IwmOPAlgem+a6seShpNBaBbVEC0K7+o2OPXbw6Jd5ZvDn24qjaONq+HO//Pvp/9L3vQhwIXPfoOu4uRbzx83B4ovg7px70hH7dIWhVo/yOfJC/B8iqPPo2vs3e+Kq9e3+Gyu7Xvnd8sbtw+SHyM/lRD1IFcCyzEeFCMopAfAPfaYpdU2LIT3HUfhkkiYhCj+/bA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PS22mzhff6xyNXazuoc1lhnF/LmLLmyfr0SuzpVE+S0=;
 b=Cyy5qzrzxBzLcoThoY+ypwvxcVgq0IkdUN1VKbjtRVp6jaLh8mxbYRy2N4Adf0N4uot9jecQJTAd04AQ7shav/tWcyCIRQHTb0JAG41iWiEYIvFCncJd0c6TIJ/abGns+5CmsfQ6jmF00ADhiw3WWZfvTJT7YAE4O8hjbJJgXh0FnAjToUaE0ojae2HTcZSBYtHkdEVeJhHdb9lYHa4PlbU7v1xoFYCNjKP/yFs4XUbx/E1tICxDrdLaLvnUlj8puGzOg/nbgB1XBIgl07TR2n2VVdyIo5Xwtuer4lwRvxS9xtS6IFX+CbgU+HhwdKexL0oY3Gw8wARGQRtrAJ0dxw==
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=PS22mzhff6xyNXazuoc1lhnF/LmLLmyfr0SuzpVE+S0=;
 b=ms0Xa7ZubwlHasDo/L4IEEtWvrHVSb4w85aSvWmqfgMR/aaeM6PoE4kMOPJXkan+CKlpt4uAfvJp4THaak5WUbrnKlnTcbh0vwUhVKs2ea++Uw5/yb8iM71ElX0VEVfEjYDz24sQ7+jkgsNErFyWNCQcRAFl+1pYlwx8P0ckheA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: [PATCH v2 2/6] xen/arm: fix math in add_hwdom_free_regions
Date: Thu, 8 May 2025 09:20:31 -0400
Message-ID: <20250508132040.532898-3-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250508132040.532898-1-stewart.hildebrand@amd.com>
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002323:EE_|DM4PR12MB5988:EE_
X-MS-Office365-Filtering-Correlation-Id: a8e7f5fa-fb8a-404f-d2a5-08dd8e33308d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?E58DZ5mYoEqNu+dpugWcbN3B7AN53NiABV1qebW3UIn4GiF/kAUTDB08UwpA?=
 =?us-ascii?Q?q2yX1rc26D2R+YzXUzk0qO2xT50WQ6htlghQ6NG5Dwn/j3WrDk9u6teKoPYZ?=
 =?us-ascii?Q?nTSg7BsrF73YmmZPZmRv3XdRyW3Kk2THxExn7xoT8UdLJN4yqPTv8ok8mSd+?=
 =?us-ascii?Q?7/nevI8c4nfkKpfCOMttLzf/uXs2u3A7eoHsm3WNyKGqw3HKgL/2B/kHNRtf?=
 =?us-ascii?Q?Fk0r87F+gS7tgbtGz4md0GMHyaoSxgZMe4n6FtnFCejw13sl+9+ZOd+HOHaj?=
 =?us-ascii?Q?XCWGyKEWn4e2xLogLG6NXXszadKuk2dYTDCvBvIkp9cYytKTlbyFVbFBmQOA?=
 =?us-ascii?Q?Qm1Bhi76X6rJBiqYGfgUrtEbP6xgJzURdOOSzQAmzdnNs9XE5cBKyV8lzppK?=
 =?us-ascii?Q?tRnIeQfzgRu/qll2PgAnVh+yaAQuQvuKfCfUwrdkrewHiKxBEP4M0vn/UEak?=
 =?us-ascii?Q?l7wH5saBM/99FEQKlcyX0PzIS6eEgPLbxiSlB/7kbtTHH5ynXbPT5xFipzRn?=
 =?us-ascii?Q?6XBwNp2aR5XzzDOamYULjAqkGRg6bVeoWwVThOyYNVW8CL8bxQw/1VG7Jbq1?=
 =?us-ascii?Q?BjcjyneXwqYx4Idvno8h6z3Gr8bfSkMbhjLWgXm8J3y2IvSNprK1sdtv3mec?=
 =?us-ascii?Q?gdqYNSrbPCLfgQq4orhkJIu+Vg859axb6z29rvVb1QOxVrIq+j32Wb+clhVx?=
 =?us-ascii?Q?4TSYu1lmaJStMDMaxA/VV7Jo7bjohpolRRHko9gl46n9QjBq7W4PcN4lTVGS?=
 =?us-ascii?Q?WvPerrIkp4eoaSNz3S1IqZsXHAVpZc82vQs0z3X7Zi52t/9AUZDUe41qSGkG?=
 =?us-ascii?Q?5jwH47kpvn7DHOhDwpMkrsumwcV+Y+9vkuSzTSwhDug4jROnA2F/YM41EG/r?=
 =?us-ascii?Q?jLKPgT1uyzkpewTpJrt2NITo66PPxXo+qQERfuP/tQ2o54fSWxYR9xKpCy4Z?=
 =?us-ascii?Q?kddRhlPLOBv0DRtuITf/2f3dLPRkoCQhmM/DylLE3U/JixJM3PxZWDpYGvBh?=
 =?us-ascii?Q?TekMjGzRljkRJsEMtv6L8U5WJLf9xYSyCCyZ6BrDuB+a1r0UOUnkBjTcHLlU?=
 =?us-ascii?Q?iA9M1k8if4vcjhcZvvab2iq40ACzk0k10SY0TnsJURvybrinm7vfdgv3BzSh?=
 =?us-ascii?Q?d2QsH3AzyNUjo/QXphyubUupH9xPg49E3BFbFjf5cDfP674MMGDygl77ffU+?=
 =?us-ascii?Q?xOgLs+o4BfxgcnaF1WfmTy1tTkqODxYLzGrjufHA0ZSkdvrQnO2+OUGIyCdc?=
 =?us-ascii?Q?4bE/G5fOQmJ/hAIF5TWidnXtbiwsYQ8bRxtyFyi/fF27wIT2H76nanapdMx1?=
 =?us-ascii?Q?+8QuVj7NmF4UTD0na/AR7f3/C7MJ9D8+JG2b94+VRihbMzqI284y45T17BOQ?=
 =?us-ascii?Q?2Ac5KKYBRhEj+63UcClTVTK31wjBfPaIoSC3yMW77w0AUBqyOzxUmUd630UF?=
 =?us-ascii?Q?EAYezenpZzJxg2a8IqIZpAQiYhuTpBxX0+xIr5LJGz02Xc/P9NlK0eITo4rr?=
 =?us-ascii?Q?lCxxdoBEsCAF/E+WzzxJQVYx9gzwmzkIXPDz?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 13:21:06.4143
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a8e7f5fa-fb8a-404f-d2a5-08dd8e33308d
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002323.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5988

Erroneous logic was duplicated from add_ext_regions() into
add_hwdom_free_regions(). Frame numbers are converted to addresses, but
the end address (e) is rounded down to page size alignment. The logic to
calculate the size assumes e points to the last address, not page,
effectively leading to the region size being erroneously calculated to
be 2M smaller than the actual size of the region.

Fix by adding 1 to the frame number before converting back to address.

Fixes: 02975cc38389 ("xen/arm: permit non direct-mapped Dom0 construction")
Signed-off-by: Stewart Hildebrand 
Acked-by: Michal Orzel 
---
v1->v2:
* add Michal's A-b
* rebase
---
 xen/common/device-tree/domain-build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 762b63e2b00a..9556af43e019 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -109,7 +109,7 @@ static int __init add_hwdom_free_regions(unsigned long s_gfn,
     struct membanks *free_regions = data;
     paddr_t start, size;
     paddr_t s = pfn_to_paddr(s_gfn);
-    paddr_t e = pfn_to_paddr(e_gfn);
+    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
     unsigned int i, j;
 
     if ( free_regions->nr_banks >= free_regions->max_banks )
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 08 13:21:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 13:21:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979383.1366007 (Exim 4.92)
	(envelope-from )
	id 1uD1BZ-0005gs-B3; Thu, 08 May 2025 13:21:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979383.1366007; Thu, 08 May 2025 13:21: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 1uD1BZ-0005gh-82; Thu, 08 May 2025 13:21:13 +0000
Received: by outflank-mailman (input) for mailman id 979383;
 Thu, 08 May 2025 13:21:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD1BX-0005gY-C1
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 13:21:11 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20628.outbound.protection.outlook.com
 [2a01:111:f403:2416::628])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4d33e15d-2c0f-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 15:21:10 +0200 (CEST)
Received: from SJ0PR03CA0252.namprd03.prod.outlook.com (2603:10b6:a03:3a0::17)
 by CH3PR12MB7594.namprd12.prod.outlook.com (2603:10b6:610:140::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.23; Thu, 8 May
 2025 13:21:01 +0000
Received: from SJ1PEPF00002327.namprd03.prod.outlook.com
 (2603:10b6:a03:3a0:cafe::ab) by SJ0PR03CA0252.outlook.office365.com
 (2603:10b6:a03:3a0::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.32 via Frontend Transport; Thu,
 8 May 2025 13:21:00 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00002327.mail.protection.outlook.com (10.167.242.90) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 13:20:59 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 08:20:58 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 08:20:58 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 08:20: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" 
X-Inumbo-ID: 4d33e15d-2c0f-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=AKzW80P4B1t+/bw5zbhVe8ZOQ5nPsTCRR4KxnZx1Q4L4Zo9EUTarEp6IZtkrUAD16lyD/OY6cUwCRuovFtMTZZAXLHIThsLrrWGrVDnIgiYRHulA3f8rETcueD4BXgV6nPsmJs4qu3r6+fNAttWIS6AncnH8i/A/ZS74mlRd67K+I25CfWkJCWnuIhgXea8SfnAVPKrxFAYUhVf1CG7e3RWEv9/Ln7l1a4oCWRCIMdoEGgupVKRi0qJX+2VQ4h7Mi4/z/9+wMJH7/2eASeF52b4FcYf/d4jA9/ITLV9Szw5et62waVOHx0wvI55TNptuQaVzoMEHjalhpeG/CmmeSw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ebr89cmmGKzjaVd2xUcU9bNIqcI96l1VlD/ym5sCsJw=;
 b=R6GDDdgUUQZZnJyBnuYYj7av3BmETVPnV0mdqXvU7my/k0IEuBAt0TE8wyJ+eGWrnqTliySyamh7UgzBzEyfHHGI6qe09xkp0wwH1l8ZySbIatko3AgEC2rJStPugDVniZummKDmBpE7/lqiMMfiA4kE64YM+E0fZkaP5M813huCw44W4+G05/R8gonbVkQlNLZveKP0pmGEuRkwyDfnpF3CGktzNIDB3m519gqc2u+rDi8Uiy1B5L2OqxCD+ZAT6p8SHybNV7VfKDwLNp1/UwkhWAK8htjACOB7hGNDQQG5HQKxfyfxGbG8TbK8vwY1eQ8ZO08ywdN+O2v+rcgRdA==
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=Ebr89cmmGKzjaVd2xUcU9bNIqcI96l1VlD/ym5sCsJw=;
 b=oBV3KE3KVVW/omjVU8giP0DbYQXihp4KlZQrlbRt+I3p4BG7y3XeO5gwV8jhGBWhn4DlxZap1DyjAQggkscJsBgVfJYsa5Y0GtmeeIEQSTSaaEmO7s6zwpoAj6RcIst+o/+fqQ9oOVWLCNs3BtJFPQ7nsgDhGzWQlFtY8KdCd0I=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Ayan Kumar Halder
	
Subject: [PATCH v2 1/6] xen/arm: fix math in add_ext_regions
Date: Thu, 8 May 2025 09:20:30 -0400
Message-ID: <20250508132040.532898-2-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250508132040.532898-1-stewart.hildebrand@amd.com>
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002327:EE_|CH3PR12MB7594:EE_
X-MS-Office365-Filtering-Correlation-Id: 8c62be5e-7b55-4a63-004a-08dd8e332c78
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?TBXwOH0TqOueMZ6yrTGaXj5XbCnOf32tbfE+4IBfNYhf4wzzY3J3uPmu3baZ?=
 =?us-ascii?Q?IKOEBH23ppCsAyfudXC7fGLc3eSyVJongVhHgcisrqNFGI67YMSwr2rIyNZJ?=
 =?us-ascii?Q?C6cn1tf6PhK/Hku610IsVI7jLrD8YNNqNpgaupcyXq15U7JlkugE2oMkC+Sh?=
 =?us-ascii?Q?Dc3JJk82eRf8H4/C3hpBXXVPaWr67XqjXb/pK6HJcGbHPjUC8H4CGm28zNww?=
 =?us-ascii?Q?QIVORKyKYfy8oqDt4I8lJj5unmSQOXNOfJBC+BLqTk35sALeVSXXd2Ej826M?=
 =?us-ascii?Q?EmTDZ4H9zYROJYvr5vtQuV71PetZrE5Q1jbJefIuo+SDMZHK6A39on5Qga3q?=
 =?us-ascii?Q?YSqR96p+SmmZxTvM2+Z1YlMrvbRxo8mHE610U4XFWBoU9o5LrAS2F+RHhJ1v?=
 =?us-ascii?Q?dbmzC0UvR1ex1chbIYDBwZeLM3rwwim5IR7clyY0QLdXdhoL5IPfVfFFxJt6?=
 =?us-ascii?Q?7nelyN/fxpvN1PiuTR71FQrf/9HUT/LmcZy3r/5fnuhXNaWK743xf2nd/Wcq?=
 =?us-ascii?Q?VoqhIB7OBC06aSZdovfGXFv0gH+wI73BQ4ameJZkP99182gFWF9oqtNRbMgq?=
 =?us-ascii?Q?wFc+6gMN/77CCUVnpxAtLvZTkLMYzH8lLu4RY+s4WZaHQZre1tnEGZCI6kQ2?=
 =?us-ascii?Q?bDNWqqba0m2dp+XNpuR86vEAZmxNaWPKC+5QUgrBvl4kzv3jDiXzlAZqjOn1?=
 =?us-ascii?Q?Qg/M3WWWfTHtcAnrw6NFlYQxmGawcm55o7FXJJ7pVtlSVbH8RRNoDESq83ci?=
 =?us-ascii?Q?ZLYC7eRzC5zmGlYW/INQ5U9VfRRrld9KVvAzSAYzB5uiBSmPqEE2WfeDWfeM?=
 =?us-ascii?Q?OQ84vPDGW0Qh7egJVrvD/AsBgMvkUfJlaxyrBW9SXAETStS2Xjiif57Ex1vl?=
 =?us-ascii?Q?zMey4roFmgQ+EpcNmAZ5oO3caltMcw2kJ1IuO93UPvDObejI+7KplOmCHLgD?=
 =?us-ascii?Q?93XUFW+pV+K8J5sghE6YUIgrgYIqgY5Fih5Nwd/sY3R1wiS5h0g1VIi/lm2d?=
 =?us-ascii?Q?HxEtRPyThXq3Ue28pLPqtUAWIQBJCWGIBUgpCz+w2t+s48yC6rsjgMM0V8vr?=
 =?us-ascii?Q?mx0EXKVO/B579RpSX2VFydvlBGZmCeTthZDC4FVeOyF1cCL/xmlbiFJAxzbs?=
 =?us-ascii?Q?feUhmqsGBwGplICB7oh58PEc/Bb2CIkW8koA5ReJKqxIMQyRO15fppreQIfk?=
 =?us-ascii?Q?u8uR4rK/tywk08VzeVjq1wEmUvzzb6nWZo6KkeqDRG5X9zHtGAjs5BVRIzor?=
 =?us-ascii?Q?onTqwWVbO3LNeaAVH8eC2vSGSFk0neosUyHnM78ARMCt2HT6tXPtyGWjVXJw?=
 =?us-ascii?Q?XQrI4cOqVtm92ScjCifdSu/meqCqE7+IQPhw/PODezfz/rJ8mWCZc3yDmu9F?=
 =?us-ascii?Q?aEMo3r42yV6mZEt0zQqiNRQLJAI/vYRBX3zpuyXswy2xgTLfEIa25mNMeNen?=
 =?us-ascii?Q?d3Acqmdol1kc75zfXVMUx7o4+6mj9Yin5VZjSFc6/72uK/3l85Xpkem64xDJ?=
 =?us-ascii?Q?SyDXGUdeYM9ocX1f1N/Oqy/Aa8cqQP0I5oVA?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 13:20:59.5555
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8c62be5e-7b55-4a63-004a-08dd8e332c78
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002327.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7594

In commit f37a59813979, the arguments to add_ext_regions() were switched
from addresses to frame numbers. add_ext_regions() converts the frame
numbers back to addresses, but the end address (e) is rounded down to
page size alignment. The logic to calculate the size assumes e points to
the last address, not page, effectively leading to the region size being
erroneously calculated to be 2M smaller than the actual size of the
region.

Fix by adding 1 to the frame number before converting back to address.

Fixes: f37a59813979 ("xen/arm: domain_build: Track unallocated pages using the frame number")
Signed-off-by: Stewart Hildebrand 
Acked-by: Michal Orzel 
---
v1->v2:
* add Michal's A-b
---
 xen/arch/arm/domain_build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index df29619c4007..2f2b021dec3e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -761,7 +761,7 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
     struct membanks *ext_regions = data;
     paddr_t start, size;
     paddr_t s = pfn_to_paddr(s_gfn);
-    paddr_t e = pfn_to_paddr(e_gfn);
+    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
 
     if ( ext_regions->nr_banks >= ext_regions->max_banks )
         return 0;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 08 13:21:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 13:21:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979384.1366017 (Exim 4.92)
	(envelope-from )
	id 1uD1Ba-0005uU-Hn; Thu, 08 May 2025 13:21:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979384.1366017; Thu, 08 May 2025 13: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 1uD1Ba-0005uN-F4; Thu, 08 May 2025 13:21:14 +0000
Received: by outflank-mailman (input) for mailman id 979384;
 Thu, 08 May 2025 13:21:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD1BZ-0005gg-7F
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 13:21:13 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20625.outbound.protection.outlook.com
 [2a01:111:f403:2412::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 494e5ffc-2c0f-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 15:21:03 +0200 (CEST)
Received: from DM6PR14CA0059.namprd14.prod.outlook.com (2603:10b6:5:18f::36)
 by MN0PR12MB6296.namprd12.prod.outlook.com (2603:10b6:208:3d3::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.23; Thu, 8 May
 2025 13:20:52 +0000
Received: from DS3PEPF0000C37D.namprd04.prod.outlook.com
 (2603:10b6:5:18f:cafe::4d) by DM6PR14CA0059.outlook.office365.com
 (2603:10b6:5:18f::36) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.31 via Frontend Transport; Thu,
 8 May 2025 13:20:52 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS3PEPF0000C37D.mail.protection.outlook.com (10.167.23.7) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 13:20:51 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 08:20:51 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 08:20:50 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 08:20: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" 
X-Inumbo-ID: 494e5ffc-2c0f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hX0ev1GOEQhqFgOqJ2VoWhni9IQLpcuMqhX4nyGVw041PI0M0xz1+cI8V1WZO82RIAixvB9B0+Tgsv70HCLoLTyngEVYOjqnjjNjFCjmjLCPFXlxs6TNjhKhc4F1K3l6mdF9rfbZ7BJvM38fh1l57MnPSfU55jD//R2efU3AHv1OC3pQXWXHrlsV52sXD2PlLPJBcROde6E2hFWdcNjhuMywUQw62R9xDqEnem6vX64dajSW8TMrh3e8zaDkTzLDp1+x5rON8zD4BeXH7LcTLJQXvnQ/UaUNy1DZ+sAtsrUp9AjdJXoNenKx3Bk9uOrqNGFf8l88k5nSzTm16mFYpA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=E2LhpbDNYFys0x5LXtoAlj+1uW+UqGZLvwi+0rSZyiE=;
 b=k/lZrJ+04vX4z3EQJvf1zcZKgZvysLrLjtHg2NecJkUAuCsKOFb6osMgIU99eOCGFK8+ffRqLZdqtA8DvvCSpi+kGIRh0wiTU2wU+tz4392pQM93KPPLdyFVQj2GKH8afMiw7R96Ghd/Lov6MsXe2nfFFWBCuFuJYi3Tse6NRcDFFLid/0j4QEU/QGKVLAGKxOJW7PKH1bkQHxj/LUEKokx3OUlWNd9/kRRLLngRTk8vNpbLpRyT54Cv5aWc6yAfNwM5ZHHLnPpkpFNSqlKZgS2ZayshAxGFphilUE72azJIQcAOylC89hMGRan0D5pdVQi/i8gRtIiUCqltvUEnYw==
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=E2LhpbDNYFys0x5LXtoAlj+1uW+UqGZLvwi+0rSZyiE=;
 b=jRZ5vp91xj5aWfPB3yOeXsDg3uC4mPfq02C7iu6Mjnd1O+KiV3PEN7tK8GHswcFw4kAiMK02BnOfoYs2EuqnXfLSlZrZzqolsTr/SKO/mTb2VpJvE8qqQ8H+WM0usoBU6TubGb3kWoZam7o0AIASEqx2nv7Agz335JAsEl2uzFM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Juergen Gross , Ayan Kumar Halder
	, Oleksandr Tyshchenko
	
Subject: [PATCH v2 0/6] arm: extended regions fixes
Date: Thu, 8 May 2025 09:20:29 -0400
Message-ID: <20250508132040.532898-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF0000C37D:EE_|MN0PR12MB6296:EE_
X-MS-Office365-Filtering-Correlation-Id: 4be7dd49-b4b6-42da-1117-08dd8e3327ba
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014|7416014|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?0JcyCKs7Iru8WtgP4WytWRoRsQnNrnnJBbQP7aYcXdcTxBUAuHtrA2lLA4Vm?=
 =?us-ascii?Q?OOmIL5V3wS2V0+2iKVWxOlFb3xgC1fAD5CuYu5k6NJNFGGcdxIVCP/OBCtAQ?=
 =?us-ascii?Q?NZWT0SZHAjhAg45l5mKLisl8ZF5p7QNhToOeOjme1aXdBxJn7R+5eA4UpOty?=
 =?us-ascii?Q?UEdUycFATup0BC0bOQ5VrLEBnpakV9mtuTh7Mz/rtQrtMgrk0rfeuOe7i/Li?=
 =?us-ascii?Q?frFu6+yKGmOcLnapELieM/WgcdUXvl90ilX/lKJWZC9t5yWB5r9ydBGwRpfn?=
 =?us-ascii?Q?/i0W+34ZzEuiNI5402H+MZLFMhhyQIJwb0lpd5lwSzDIyrySNTZjOr3QY8sb?=
 =?us-ascii?Q?+DKxbIK5hMMUB2nwJopeQApr78vDi9J1cHg8161Hf7UBaohs7NiepPetSxaU?=
 =?us-ascii?Q?crlrFKZE8D/dJU3Lf60JvukGzMQgld3v9WJnYEnu/URYfrMqyqsAUAQHVOf7?=
 =?us-ascii?Q?+4kVYTbnEcZygIkTfeZqNndtU5NGKVLGMMzICU843U7LAy1lnxBTM8WR+UdB?=
 =?us-ascii?Q?9HN3/mzrulHfptjiVbJrK+yuy7Qb/qVN8BURonXvxmIWVpDq4v654oxT6jEE?=
 =?us-ascii?Q?IoXYJA+68YGu+2Oe9IvVi4lddyoQinwO0eCW6UAECLN4h97nG4fBILPXvZj5?=
 =?us-ascii?Q?0p46ikNeTHJIgZ/1z6yGsAmrXlAHnbs4ZcGMF1x2LaKa+MWMOuVkHqPciaIv?=
 =?us-ascii?Q?ztjECjHpP0+80TnBmstbROg84PyaqiV6Z+hcON2YjIpuflbvEVpRGCbDglXt?=
 =?us-ascii?Q?/HK5PaCCWi1Ik7qX/YYlSXxV2AH113XybI5cCXxGpbvAx7xPmzgtd0Y+oOzw?=
 =?us-ascii?Q?wGly0RAB/wKJeWrgsuSZW/xlrXMQ4xM5Aa9W1fMB2KdKC7vYEJ11J9hAK4dZ?=
 =?us-ascii?Q?AGfLn3U9DzZvTN+Pj93cC9rccjlHELCPZIGiTYCfV3LjOydJe2GNdxkdDNU7?=
 =?us-ascii?Q?Cvw33KAEhXO4qAUH2163klIuyksXCgDfvxM4Q6ta8qNDj35r2XbJdSU8VTZV?=
 =?us-ascii?Q?pKcTGoQqQVWZz5rtpJa7sYFmPAibW1kSXagbv+MFRzSyWYrtC0HGWTgfhFWn?=
 =?us-ascii?Q?OngKlsybNT3Wra2eKSjlSdpvm7nR2rhKtKaRc/yyi+y9lp3YBNlDGW9DjvPL?=
 =?us-ascii?Q?w9Tumn/chFO7bVmmAC766GEs6Ji+7bu7BWfZQ1g5lC1ViR46mevKTQ8D5ABN?=
 =?us-ascii?Q?MerFlcTIq6cJ4rd3GkzOXZBaWaE/KSEsck5Z2MvnOm04hhF10zKIKILq7czy?=
 =?us-ascii?Q?d4vLYnX29GOhif0MjG8EsnF95XX4xM8YQeVIUjke5UXnSEYcFE/5+rxibm8J?=
 =?us-ascii?Q?nGr+XEVtxRqlscrQkfymACtxjpabfeD0PV2ye7UNO8HuldzcYhQBbwJ4xO2x?=
 =?us-ascii?Q?g+FcsNhsy4EPHL5jL9iV6W3qL5ylPzLbAlB+HnVlte0LbIekqIwQ/9+wLRru?=
 =?us-ascii?Q?QIB+iuH/BFN6TYFyiPqYBaEATO3AqdlwcfF6bPO/qPbU6IQj9fTV/09XvwEg?=
 =?us-ascii?Q?QvKYrB0M6molHjNgB609c11NvIAAkKMBJNCQcyvdsAXDV0DNWHJ89Y0fFQ?=
 =?us-ascii?Q?=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014)(7416014)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 13:20:51.6647
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4be7dd49-b4b6-42da-1117-08dd8e3327ba
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF0000C37D.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6296

v2 pipeline: https://gitlab.com/xen-project/people/stewarthildebrand/xen/-/pipelines/1807189300

v1->v2:
* rebase
* address feedback

Stewart Hildebrand (6):
  xen/arm: fix math in add_ext_regions
  xen/arm: fix math in add_hwdom_free_regions
  xen/arm: switch find_domU_holes to rangesets
  rangeset: introduce rangeset_subtract
  xen/arm: exclude xen,reg from domU extended regions
  tools/arm: exclude iomem from domU extended regions

 tools/libs/light/libxl_arm.c            | 118 ++++++++++++++++++++----
 xen/arch/arm/domain_build.c             |  55 ++++++++---
 xen/arch/arm/include/asm/static-shmem.h |   9 --
 xen/arch/arm/static-shmem.c             |  65 -------------
 xen/common/device-tree/dom0less-build.c |  19 +++-
 xen/common/device-tree/domain-build.c   |   2 +-
 xen/common/rangeset.c                   |  12 +++
 xen/include/xen/fdt-kernel.h            |   1 +
 xen/include/xen/rangeset.h              |   3 +
 9 files changed, 177 insertions(+), 107 deletions(-)


base-commit: ed9488a0d155562cc4f1c9a1c38031579a347cf4
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 08 13:21:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 13:21:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979388.1366036 (Exim 4.92)
	(envelope-from )
	id 1uD1Bn-0006XM-5p; Thu, 08 May 2025 13:21:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979388.1366036; Thu, 08 May 2025 13:21: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 1uD1Bn-0006XF-30; Thu, 08 May 2025 13:21:27 +0000
Received: by outflank-mailman (input) for mailman id 979388;
 Thu, 08 May 2025 13:21:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD1Bm-0005gg-6D
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 13:21:26 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20630.outbound.protection.outlook.com
 [2a01:111:f403:2412::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 555ebded-2c0f-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 15:21:23 +0200 (CEST)
Received: from BYAPR08CA0009.namprd08.prod.outlook.com (2603:10b6:a03:100::22)
 by SJ5PPF28EF61683.namprd12.prod.outlook.com
 (2603:10b6:a0f:fc02::98e) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Thu, 8 May
 2025 13:21:13 +0000
Received: from SJ1PEPF00002323.namprd03.prod.outlook.com
 (2603:10b6:a03:100:cafe::bc) by BYAPR08CA0009.outlook.office365.com
 (2603:10b6:a03:100::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.32 via Frontend Transport; Thu,
 8 May 2025 13:21:13 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00002323.mail.protection.outlook.com (10.167.242.85) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 13:21:13 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 08:21:12 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 08:21: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" 
X-Inumbo-ID: 555ebded-2c0f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gYSZY/IaWV1JmK2nvjWIcKYTOX1umU5ouK+cCenZrgyd9XLLlr44oU7U9UUKEk2g2/X1mIfmrL3Q9LegyBwFhSAXdllNsiwl3HWD0Yq7SFQyN9RHSDPJLHBlE5TsoMdMZzXQUGYWcWRGyAxDz3gtI/wiuYDjJXgztgDykbO26/3oNNX67om6SNhqp572wyiy8ptt4FZpdFroZEuNT7m2stpQXTOk3WXVUHKgFO27Eg2qWNZrUPlUTECBiPMudJCYlb7Oxn7lIZ3w4eWi8y1M3RPKfhwCfXoWgqyrxVAxeYmGi+6mJem5XZi0lCvAiUizC5o2rXJJ1RfN8wB5OosLdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=s98qA+3lKzwYOBQMdaI/VMDUPTm2nFYBtd/o5egu+bU=;
 b=faqfcsseKWdg4QWxnJ4rd5jVoSnohmxHqm+8MN0qNOSxTjewo/ATvEjWNxeOOlacQ7xALIhFoVVi9bt8oAzd9f/fJf7EK46GbdmQBAu2lITtfBjoxQ8WRjhU1FhoBnB4Q11VHXj9b0ilVQi3/5XtQA3sK05n4zDW0SNj7cmOuK3EqvWU+2V6sNRB0siUrkWlrlup7zdSs6Kb+WN00qMJcW8uG9VgFPNiGBZKYFhIOnBTMdDkoA5JVuIzQSdJzvBHeM2cz5c8JzvoG70C1n2RzCZGQg9/XpyHtIPaHxAruzEQIkyqHO9H80SsCK1IqAnEMcOGsVxzVv+OpiknEh+/vw==
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=s98qA+3lKzwYOBQMdaI/VMDUPTm2nFYBtd/o5egu+bU=;
 b=kp3pMFaGj1gmBZ89EW7aEF02uA+jzBs30w3yjwuJxxLgbYHsaeqrAEewoRJaG9n5rM9X0l147LTbxBiMHcqYWbaj9uq49gNZlID+rDVS8/f47Z7VuYjDkovI8mntmbZkXrkNoLHWXyZoc5jgDsBqM/QlA83qTXrD18t4Mcr5ESg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" 
Subject: [PATCH v2 3/6] xen/arm: switch find_domU_holes to rangesets
Date: Thu, 8 May 2025 09:20:32 -0400
Message-ID: <20250508132040.532898-4-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250508132040.532898-1-stewart.hildebrand@amd.com>
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002323:EE_|SJ5PPF28EF61683:EE_
X-MS-Office365-Filtering-Correlation-Id: 869a1447-e7e2-42a9-ca06-08dd8e3334d6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?naOKwUJ/J8MOtg/MKPER9fJbyjQklQ8X5hsMEJcobXMTzKmI9MnGBt4avzBd?=
 =?us-ascii?Q?He4C5KMeqJDBQtgv9b89DVpEl9WRN4qqFIcm+Ebk7pBp8LsXYM3SEIOebp9f?=
 =?us-ascii?Q?AupqZPEzDD0o22QSB9+bFDNYZk1FMW6N2PzgRbG6z2yFKqwywNqcdVeTctK7?=
 =?us-ascii?Q?NmJzbgSJbCjJUE4oNP7pPQVNv3bixP6ppTZp44uwzUM97SrdpdMm+ay2VW/C?=
 =?us-ascii?Q?5tVWrhvD1b1tXcmlTxhPvujeAmJEPB5RQJBhZHUhVcEc6gmdyMqJHHywZNrK?=
 =?us-ascii?Q?VkyAyRsd5vGJsefOw0zlrxvjTkBV7wP3O0xTcy6JnYUS//MhRpUVdoSTSFTx?=
 =?us-ascii?Q?+7cv9vPoVOsJpD7UFKDbbHkUGrll8fwpkKJOD7idhl1uIU1ZmACyjG1dEwcO?=
 =?us-ascii?Q?eMkD29vL2uBtw/lbbvVtXL/mZHrLv0+06JPGlZSxqUTMCNrDYs3/7zXmuzue?=
 =?us-ascii?Q?DbdF/X/UihBnj6pBykbIw+KpwWJUyXLluUV7WPOJBioVAdVtZ8x1/b2r3IxS?=
 =?us-ascii?Q?VuRSlHTNlGzKKbIZ+r1b1t01SXYmyVTuZOqblZCh++m02x1agspvAnYGIPAD?=
 =?us-ascii?Q?2/5PD7cyD3tysyWrdfSOB3mYgJVh0sXqoNjcfihAPsEaC+T0CuQ+37z/zMnO?=
 =?us-ascii?Q?SqPZOfNmPbpOxK9Tyyc9bOfWqQE+0jPNbzcVy2eYWm7JD45DgEIs+ZaO9DV1?=
 =?us-ascii?Q?SOeedEt4lI/g5wkpcoLbc3OS9tEq0D2FaPOgZHtwon/gKyc67AGtu84KlkGQ?=
 =?us-ascii?Q?YNMFHRKbAvLQ4gmjEIQY2dhYeYJP2FL/abcUaCHmRu8h29kgoQQpcpOPicZN?=
 =?us-ascii?Q?8yYv887sYvJAb2c4yJeqdJEx68o1Y1RHfVYSfhWLykBMz8iWy86mTSEYFWKz?=
 =?us-ascii?Q?3WYsCtUyKE+3nV7jz8G2JRVwUNO8slqMs8eSYBf/vhYFCaPPXWA9SCiRFTOT?=
 =?us-ascii?Q?m2xHrUOmawQY7dTiYndq49IjgcWBi6B78+s5xVqJ5bZ4UPjVilmygOoLq7ob?=
 =?us-ascii?Q?Cmlx7Iq0neHU15CReXriQPwn6m6Tv58QtqqoDnmfsWwEi3tNvPbfcc3pAvH3?=
 =?us-ascii?Q?x0B3tmpKFvH5F5ykMrEj8eCh8hTGyzhTcMwfnLVvr1kv+Aj81927uNooxvXN?=
 =?us-ascii?Q?YE9em5k4GE1ISU/ELx9NKnge3a5SKqLzpaddqn9BKynRToYnBGhzly9AUE4w?=
 =?us-ascii?Q?sFXEW2xPTf/ZOzGm7twKEOsVUNLyoTexYoTSwzNq+LoasMLKepIYXnR4VfcE?=
 =?us-ascii?Q?E8jmNK93u+usselNeo61ueL4RwKtQVVobCsFW+2ph8WfgD8+PXIF/qBxWVt3?=
 =?us-ascii?Q?Ep/oWOuP09k57AeJWweWEUaSRKuFIWhka7z5BzV8uiefozjD498TmfqHbO1e?=
 =?us-ascii?Q?M8e6Vjj8+XUvfcfmChPo2nnyhMxzkZi3P9fWDdx8okYE7ht1E+Pio40UgWGl?=
 =?us-ascii?Q?ZIvebXc+xjV57YHrDHj53ksr9U69blQPWG5TwuPQ2FGk4OiBWM2k+cSfnLzG?=
 =?us-ascii?Q?sMddWsfOWVx6Ha7fu2du1c03BXl/4RAOkclM?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 13:21:13.6015
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 869a1447-e7e2-42a9-ca06-08dd8e3334d6
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002323.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF28EF61683

remove_shm_holes_for_domU() is unnecessarily complex: it re-creates the
extended regions from scratch.

Move the rangeset into find_domU_holes() and create the extended regions
only once. This makes is simpler to further manipulate the rangeset for
removing other regions.

Remove now-unused remove_shm_holes_for_domU().

Signed-off-by: Stewart Hildebrand 
Reviewed-by: Stefano Stabellini 
---
v1->v2:
* add Stefano's R-b
---
 xen/arch/arm/domain_build.c             | 46 ++++++++++++-----
 xen/arch/arm/include/asm/static-shmem.h |  9 ----
 xen/arch/arm/static-shmem.c             | 65 -------------------------
 3 files changed, 35 insertions(+), 85 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2f2b021dec3e..05a77a4f92c6 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -933,34 +933,58 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
                                   struct membanks *ext_regions)
 {
     unsigned int i;
-    uint64_t bankend;
     const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
     const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
     const struct membanks *kinfo_mem = kernel_info_get_mem_const(kinfo);
-    int res = -ENOENT;
+    struct rangeset *mem_holes;
+    int res;
+
+    mem_holes = rangeset_new(NULL, NULL, 0);
+    if ( !mem_holes )
+        return -ENOMEM;
 
     for ( i = 0; i < GUEST_RAM_BANKS; i++ )
     {
-        struct membank *ext_bank = &(ext_regions->bank[ext_regions->nr_banks]);
+        uint64_t bankend, start, size = 0;
 
-        ext_bank->start = ROUNDUP(bankbase[i] + kinfo_mem->bank[i].size, SZ_2M);
+        start = ROUNDUP(bankbase[i] + kinfo_mem->bank[i].size, SZ_2M);
 
         bankend = ~0ULL >> (64 - p2m_ipa_bits);
         bankend = min(bankend, bankbase[i] + banksize[i] - 1);
-        if ( bankend > ext_bank->start )
-            ext_bank->size = bankend - ext_bank->start + 1;
+
+        if ( bankend > start )
+            size = bankend - start + 1;
 
         /* 64MB is the minimum size of an extended region */
-        if ( ext_bank->size < MB(64) )
+        if ( size < MB(64) )
             continue;
-        ext_regions->nr_banks++;
-        res = 0;
+
+        res = rangeset_add_range(mem_holes, PFN_DOWN(start), PFN_DOWN(bankend));
+        if ( res )
+        {
+            printk(XENLOG_ERR "Failed to add: %#"PRIx64"->%#"PRIx64"\n",
+                   start, start + size - 1);
+            goto out;
+        }
     }
 
+    /* Remove static shared memory regions */
+    res = remove_shm_from_rangeset(kinfo, mem_holes);
     if ( res )
-        return res;
+        goto out;
+
+    res = rangeset_report_ranges(mem_holes, 0,
+                                 PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
+                                 add_ext_regions, ext_regions);
+    if ( res )
+        ext_regions->nr_banks = 0;
+    else if ( !ext_regions->nr_banks )
+        res = -ENOENT;
 
-    return remove_shm_holes_for_domU(kinfo, ext_regions);
+ out:
+    rangeset_destroy(mem_holes);
+
+    return res;
 }
 
 static int __init find_host_extended_regions(const struct kernel_info *kinfo,
diff --git a/xen/arch/arm/include/asm/static-shmem.h b/xen/arch/arm/include/asm/static-shmem.h
index 4034cec32f87..6a4c33cca8c2 100644
--- a/xen/arch/arm/include/asm/static-shmem.h
+++ b/xen/arch/arm/include/asm/static-shmem.h
@@ -27,9 +27,6 @@ void init_sharedmem_pages(void);
 int remove_shm_from_rangeset(const struct kernel_info *kinfo,
                              struct rangeset *rangeset);
 
-int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
-                              struct membanks *ext_regions);
-
 int make_shm_resv_memory_node(const struct kernel_info *kinfo, int addrcells,
                               int sizecells);
 
@@ -73,12 +70,6 @@ static inline int remove_shm_from_rangeset(const struct kernel_info *kinfo,
     return 0;
 }
 
-static inline int remove_shm_holes_for_domU(const struct kernel_info *kinfo,
-                                            struct membanks *ext_regions)
-{
-    return 0;
-}
-
 static inline int make_shm_resv_memory_node(const struct kernel_info *kinfo,
                                             int addrcells, int sizecells)
 {
diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
index 1f8441d92046..32ec6d4bc69f 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/arch/arm/static-shmem.c
@@ -822,71 +822,6 @@ int __init remove_shm_from_rangeset(const struct kernel_info *kinfo,
     return 0;
 }
 
-int __init remove_shm_holes_for_domU(const struct kernel_info *kinfo,
-                                     struct membanks *ext_regions)
-{
-    const struct membanks *shm_mem = kernel_info_get_shm_mem_const(kinfo);
-    struct rangeset *guest_holes;
-    unsigned int i;
-    paddr_t start;
-    paddr_t end;
-    int res;
-
-    /* No static shared memory region. */
-    if ( shm_mem->nr_banks == 0 )
-        return 0;
-
-    dt_dprintk("Remove static shared memory holes from extended regions of DomU\n");
-
-    guest_holes = rangeset_new(NULL, NULL, 0);
-    if ( !guest_holes )
-        return -ENOMEM;
-
-    /* Copy extended regions sets into the rangeset */
-    for ( i = 0; i < ext_regions->nr_banks; i++ )
-    {
-        start = ext_regions->bank[i].start;
-        end = start + ext_regions->bank[i].size;
-
-        res = rangeset_add_range(guest_holes, PFN_DOWN(start),
-                                 PFN_DOWN(end - 1));
-        if ( res )
-        {
-            printk(XENLOG_ERR
-                   "Failed to add: %#"PRIpaddr"->%#"PRIpaddr", error: %d\n",
-                   start, end, res);
-            goto out;
-        }
-    }
-
-    /* Remove static shared memory regions */
-    res = remove_shm_from_rangeset(kinfo, guest_holes);
-    if ( res )
-        goto out;
-
-    /*
-     * Take the interval of memory starting from the first extended region bank
-     * start address and ending to the end of the last extended region bank.
-     */
-    i = ext_regions->nr_banks - 1;
-    start = ext_regions->bank[0].start;
-    end = ext_regions->bank[i].start + ext_regions->bank[i].size - 1;
-
-    /* Reset original extended regions to hold new value */
-    ext_regions->nr_banks = 0;
-    res = rangeset_report_ranges(guest_holes, PFN_DOWN(start), PFN_DOWN(end),
-                                 add_ext_regions, ext_regions);
-    if ( res )
-        ext_regions->nr_banks = 0;
-    else if ( !ext_regions->nr_banks )
-        res = -ENOENT;
-
- out:
-    rangeset_destroy(guest_holes);
-
-    return res;
-}
-
 void __init shm_mem_node_fill_reg_range(const struct kernel_info *kinfo,
                                         __be32 *reg, int *nr_cells,
                                         int addrcells, int sizecells)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 08 13:21:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 13:21:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979391.1366047 (Exim 4.92)
	(envelope-from )
	id 1uD1Bt-0006y8-FG; Thu, 08 May 2025 13:21:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979391.1366047; Thu, 08 May 2025 13: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 1uD1Bt-0006xz-C8; Thu, 08 May 2025 13:21:33 +0000
Received: by outflank-mailman (input) for mailman id 979391;
 Thu, 08 May 2025 13:21:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD1Br-0005gY-FM
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 13:21:31 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2415::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5a0fe31f-2c0f-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 15:21:30 +0200 (CEST)
Received: from CH0PR13CA0041.namprd13.prod.outlook.com (2603:10b6:610:b2::16)
 by PH0PR12MB7861.namprd12.prod.outlook.com (2603:10b6:510:26e::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.25; Thu, 8 May
 2025 13:21:22 +0000
Received: from DS3PEPF0000C37F.namprd04.prod.outlook.com
 (2603:10b6:610:b2:cafe::bf) by CH0PR13CA0041.outlook.office365.com
 (2603:10b6:610:b2::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.24 via Frontend Transport; Thu,
 8 May 2025 13:21:22 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS3PEPF0000C37F.mail.protection.outlook.com (10.167.23.9) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 13:21:21 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 08:21:21 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 08:21:20 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 08:21: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" 
X-Inumbo-ID: 5a0fe31f-2c0f-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QivDNAi660V+JVq6wiiyJu65xyw//QBuS0CM0s775D4ap5o5XA+UnBHrHq3ZQYIEIWgQIATc3G3jDs04Ng7AyUrF5qDxJnjNJFPQDglRLGUIYF9phV9zOSgG9UzIySTJg3wIjMkaabim+ywuTrXcVc7NVbsx05ukhVPDjzrkz33N++/SCC9XOp9xBl7y+RtKS+3u+e0/YlCuoU0ohavL2FasPxf/uyrrA7sEkiHB7WhKIVoeQkrAyz5JxH4ezDY2aZe2gD4k+Fe0EXnBmrvp4Jh6vEopBoHEjP+XpUIbsnbR2ilt8p2GgSiRtXkQscsG3VsBl79PzufImql+8uJLFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=J7QqFU341kNEQ1CkVHUs9vf850fY7Y4Ivh8PGVOXOpI=;
 b=eE7oH9/eKJ4JJ4OyFa6EqKHGFKxXs1PqcG1qDhCNBHkW0GPjHX+I7bjk6k2hTaLKRLLGkh0wZSOa91HzNOFYoWYqj/Q4GHze7PPL1ozrFDEqa4RiVpwJ3LCn2ooW8w6UfLRI0wU/+XBYSCz+wY/LHBH7+oTi5ucC+l2rVRoD7ccoUyXRpUbeciXBnKsx3VcF2Vcht/GtJMLOogrowvrJox31JZZWVOS7yXuI8iqaYrLWLBjgoyq/cvuWvVJBRdU4JmUQWW4OZ7V7mAXA8QtABImGMcVP4pgXSivY01jkkPjZXOGE7tWCqVJc/QGK+qqt0X2HhUQBWqP8ZLUrYWsFDA==
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=J7QqFU341kNEQ1CkVHUs9vf850fY7Y4Ivh8PGVOXOpI=;
 b=mnp49ONcDUihTvyHWcA+e/2VxdGZmpJETyRKuvvENHViXsoVrfA8g4fn8qIwazibmuR2MQYymmJ8xdVzPfW7KBcrqTV14OS29G6bizLkoQ2hCdPiPanA2dATGGTKbQRAiO5g8/0BcKYGzxanVF0yfzJDnOKB/utsAl9rF7pWGFA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v2 4/6] rangeset: introduce rangeset_subtract
Date: Thu, 8 May 2025 09:20:33 -0400
Message-ID: <20250508132040.532898-5-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250508132040.532898-1-stewart.hildebrand@amd.com>
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF0000C37F:EE_|PH0PR12MB7861:EE_
X-MS-Office365-Filtering-Correlation-Id: 8511870a-95e9-4046-2f0f-08dd8e333994
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?ZbInkedcqu5genAzw129cRYQRS51zzv3DFu5gj6FY39je0tC+PuuDl4ccaxT?=
 =?us-ascii?Q?AuG2PE6HHzvyCNzBsMCR3O4pOe2NiwBNNZM4hFvMyvmW2FSp11Av7RbQBju4?=
 =?us-ascii?Q?5vzJplBIsZoJADjevLToJi91cQbQoc6ZdILb8MhiCV/MGOfUEz1IfbvGeOLh?=
 =?us-ascii?Q?2+2rDu09lnXJLrNtWpuagP05h5TjJ55r0Tpn+ABdWCiw7npAcChrsuc5TGb8?=
 =?us-ascii?Q?hISmmoZFXc1EFkr6JL/LeCJLcv/S4vm0x2jwC2zDKTWJX9q7DmbVb2bYjhA7?=
 =?us-ascii?Q?y1mhSrt63HiwZ1Z1RNBGn6/4BznK6c19GcLABPCrVsvdY2G2NR0jc/7N6oC5?=
 =?us-ascii?Q?W0cY98oEoW0P1xA7JU0xEDQ+tfYOtDKSsqN9b6d4CHyTqJsxxZLp+z2tlnE3?=
 =?us-ascii?Q?23GUv7ro5jYyj8ZgxFoM6cwPMMoe8gAwig6V4FcHyUeRUj/nOtPqkGVevdm6?=
 =?us-ascii?Q?SHTMIOvIL4rVysHT2tY1XOOaZzGSNVzuzjhxGKACvmIt97elOzNbIUfAX4OB?=
 =?us-ascii?Q?CGSV/ShypZ9pErNWrup/YlEHZaz6XVqsYQWVJK3ZqXrh4/83O1/rEy5GI01F?=
 =?us-ascii?Q?jBQRDgXQx8LRtzM4jLCwiZ/3zVRKXfdd4z86C6dqBUmKrWcRbEpu2O+8fxDb?=
 =?us-ascii?Q?JXiYe09TPc4tpzC639WCJNGfx0N4aGXDTpfGZ3J/MfJZrQx/w4DHrEgaxlH4?=
 =?us-ascii?Q?yJvGBOazkRAC0jPHbEqPiNXc5oHbpjusau2xnWkD9dbJsqaYuXWtUvAEBPPV?=
 =?us-ascii?Q?GiWsyJ97IKMLTPWGjnDRr+DFWcZZroYzUMFlt5TIo4u+gKI2RvkdC9rEARad?=
 =?us-ascii?Q?vYkgG1lMzl6nbQ4ToDoqUJ3hPUQKS18hDr8hMfAXgP3Gzcm/SsR+x4MwDyz+?=
 =?us-ascii?Q?pgjVDdkdjSlDPdi0K87k3P92K/2nWOoGQxUVKcoUmW7bOqAOqBiZa+kyW0n7?=
 =?us-ascii?Q?9LGxMjkhjcndIhY3K1hThiPw/0fB2sefiv9/iO/VKqZgx9jftWhfmU2t8U4S?=
 =?us-ascii?Q?3jXWvy2+eyZ6joS1CH4BrdRJJqSR81OstkHZkA4hso857BOrBbuf+BEJrTg7?=
 =?us-ascii?Q?9j/BjYX1tKQjL0LM6niESsQ3cBdHB0ROzBuBIBdyi1sGEC56Zdg9btR0WI5l?=
 =?us-ascii?Q?FbXTOH9cjPVBMg+Kv5z7ZIbnTHYo8UKqSOI4aNuVPyGS1MOGFhvtzTfdVCN4?=
 =?us-ascii?Q?faCP+GBOf8KL/Ue5iS+zroCw0nQNxV70p/KDb+SOK+oQ8lj3OeRTxsjom/mu?=
 =?us-ascii?Q?wURqQbya9wQNQZvNFRbXZ+Lv8XUGwMJk9ltaiUdwf+zTNx3vrJxOeEIkpDZ4?=
 =?us-ascii?Q?nxsm9dOTU2EeVrk1jCymbObzz38+YuTgtZlrhO5Dl35UgFwW8JJKDuwmAxRx?=
 =?us-ascii?Q?s81tZOOw5UseDt6fqdAx325QnEgpIr7vjpIR/UqHkAKNAxBK2kMhICTmoh4b?=
 =?us-ascii?Q?yS5cCvSKkvXCO3qJFMww5a+fSBqLhnxpong6ExgG5VnTpckZ///YdNE39ejF?=
 =?us-ascii?Q?TpChSIU6cNS/41j6QbOxipqchs7cL7CCbYQH?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 13:21:21.6197
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8511870a-95e9-4046-2f0f-08dd8e333994
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF0000C37F.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7861

Introduce rangeset_subtract() to remove regions in r2 from r1.

Signed-off-by: Stewart Hildebrand 
---
v1->v2:
* no change
---
 xen/common/rangeset.c      | 12 ++++++++++++
 xen/include/xen/rangeset.h |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index e75871039087..b9e8912fb1c3 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -397,6 +397,18 @@ int rangeset_merge(struct rangeset *r1, struct rangeset *r2)
     return rangeset_report_ranges(r2, 0, ~0UL, merge, r1);
 }
 
+static int cf_check subtract(unsigned long s, unsigned long e, void *data)
+{
+    struct rangeset *r = data;
+
+    return rangeset_remove_range(r, s, e);
+}
+
+int rangeset_subtract(struct rangeset *r1, struct rangeset *r2)
+{
+    return rangeset_report_ranges(r2, 0, ~0UL, subtract, r1);
+}
+
 int rangeset_add_singleton(
     struct rangeset *r, unsigned long s)
 {
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index 96c918082501..817505badf6f 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -85,6 +85,9 @@ int rangeset_consume_ranges(struct rangeset *r,
 /* Merge rangeset r2 into rangeset r1. */
 int __must_check rangeset_merge(struct rangeset *r1, struct rangeset *r2);
 
+/* Subtract rangeset r2 from rangeset r1. */
+int __must_check rangeset_subtract(struct rangeset *r1, struct rangeset *r2);
+
 /* Add/remove/query a single number. */
 int __must_check rangeset_add_singleton(
     struct rangeset *r, unsigned long s);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 08 13:21:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 13:21:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979401.1366057 (Exim 4.92)
	(envelope-from )
	id 1uD1C0-0007VI-Tb; Thu, 08 May 2025 13:21:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979401.1366057; Thu, 08 May 2025 13: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 1uD1C0-0007V9-Po; Thu, 08 May 2025 13:21:40 +0000
Received: by outflank-mailman (input) for mailman id 979401;
 Thu, 08 May 2025 13:21:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD1Bz-0005gY-EW
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 13:21:39 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20625.outbound.protection.outlook.com
 [2a01:111:f403:2409::625])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ea6bc96-2c0f-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 15:21:38 +0200 (CEST)
Received: from BY1P220CA0012.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59d::8)
 by SJ5PPF01781787B.namprd12.prod.outlook.com (2603:10b6:a0f:fc02::986) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.29; Thu, 8 May
 2025 13:21:30 +0000
Received: from SJ1PEPF00002322.namprd03.prod.outlook.com
 (2603:10b6:a03:59d:cafe::af) by BY1P220CA0012.outlook.office365.com
 (2603:10b6:a03:59d::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.23 via Frontend Transport; Thu,
 8 May 2025 13:21:30 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00002322.mail.protection.outlook.com (10.167.242.84) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 13:21:29 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 08:21:28 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 08:21: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" 
X-Inumbo-ID: 5ea6bc96-2c0f-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EYvVicEHsYdxjt3lgkDtzjrds35spwBOKnvu2/nY9UMyeqZe44CvRxpAH08GmOmfAjmhY1RCLEmcBmiIPMc4muGOz/pAjh2Cda+7v8u/rY9llZxI4i+cOlbeJIHB6uP9jNT56MPc+xYDBcidZ1QQ6cNGX6XMSZlrLGXLU4jLln2CKABZQaJv9HGfrK4B/OPXNCQdEF5yUQvKl4wILdr2EmuIoND70BefGNjUBiZhCVybTpc97D2R5muNlFL4AMde2l+d/2ujyXIffQtH/5FL9OrisCSZ9NKDp+cxZMr5e3bSBIR8gXklbC3nNVrt0sf9k+OLbpAL1tA7ar7366Ib3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mf45CPfSF8ad4+bAErKDjNmMPQ65zTOctdwv0MmR6s0=;
 b=CU9V2WlpNdfx3VBOMcp5RtNS14froWAWfyyJ4s/mXlDWusx9/mRKrQV6IJLqlQjy3g20//kQB4FtIOuhXbH+Nsm15WrG7VjmlU/5iSKpgXQ9gzdlnY5pblDy5nTiWXVNRg8AwLh/nF4IxkbUJtmzWlHGPFE+lROVhXWGjPPFdmuTK13Y5N0jZBnHQTkuPf5ejoqOrUv8Ha+GSEDMdXBsebibVtnUnY3GK5E6+crEouyl2qhiI0BxD8a5mWaAGmXPgT4fAWZ3kPuA0rXgYD1fTaal2bHZ7lUlUjkjhvkRql8pfP6QcBY/ZPUxEVRLl54nYXy0jYQyAO2grP47IrgBxw==
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=mf45CPfSF8ad4+bAErKDjNmMPQ65zTOctdwv0MmR6s0=;
 b=vvW0j2OrWjrSEBX+vqu6aU25aTlAPcVAhTAgyEX3ZNfiKb8W2WftvlBCgZmuRiverVj81oRyTqLimAKqmidaTH2Qf49JZ4J+NtGDGm4HUS+z17gjVvjF1kn9cj4td7Y4+MhoQKLUkllW8GAdLx96LDiQerDqLCaqLX19tan2sJ8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , 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 v2 5/6] xen/arm: exclude xen,reg from domU extended regions
Date: Thu, 8 May 2025 09:20:34 -0400
Message-ID: <20250508132040.532898-6-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250508132040.532898-1-stewart.hildebrand@amd.com>
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002322:EE_|SJ5PPF01781787B:EE_
X-MS-Office365-Filtering-Correlation-Id: a132f9db-69e7-4b85-bed0-08dd8e333e8c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?bKAsi3iAwhD8QB5o0zm3ICZFra3kNtOM3gRLsC8OuKu6ums44ToodvrQ6JC9?=
 =?us-ascii?Q?VQRp+8vhHG+m5DceU/QCX3COKtFt1i+lcDl7FcHiF4qaU0cl4FgZfBxMIf2z?=
 =?us-ascii?Q?de1/Q3Gw9bOHTD7hb5CdnA0FHzHKo+gOVRV4GQnjEiV7nUZu6APK1xytwcXD?=
 =?us-ascii?Q?WkSCnE/WB3mDuBak3boNAi4EIjpW2VDfPIi+tXTvnMmxdGDJLeeYJJehmeUY?=
 =?us-ascii?Q?fkJO9IV6mksx2SO7/B82/NYYpZ5KsInqbrN72WbrumQ3bPVn+RpaqFdOkBjN?=
 =?us-ascii?Q?eMsgnvwyOcV6xb9eqewkvF1ZrE29C4ftD7sLNS6q9cQ9tD+OBpL5nBRvnYet?=
 =?us-ascii?Q?PrUXI4r5nXURyZe27pizwek1bJ7jhyKVMdl2WMznlrJ45Fyei++Ucojmwyn+?=
 =?us-ascii?Q?+EbaDhX/Ihq1/naisIPJqqcMJO4XWeV5BP9isGmu+WeaUn1BRbo0FbWVpVAH?=
 =?us-ascii?Q?q1aeIt84J3ATLgKzrmbfgD0lbIr4dH6sRh1ccuf9B3sqfzHCHGCgeNY1JspF?=
 =?us-ascii?Q?frMR+JF1R0lMObeNUZQ71wCbKTGJErMu7ux5Sbr4cHEZ3ELJk+Mx1QPFpVkc?=
 =?us-ascii?Q?n4fVrZLO8phFhsvPfgr3jcwnO0vEDPqZ9cSmqj5wneWDdFi0h/yx8LhgIIbQ?=
 =?us-ascii?Q?sjvf4sFE5cSj4hg4j47WxaqQCwvAQtncL9wnO9efNqiartedAaQipTi2FEkv?=
 =?us-ascii?Q?Sgy1myyvmD5H1pHJAdt/4ZgLRS6Bu1VIo1/3bCh2ZIIKocdDMfCiLadYbd0G?=
 =?us-ascii?Q?Oy5DYwnjDkViLpdvGGzxtqxVYH0qPdYSqdcgaljQYUpPdwibGajvn4hjayzV?=
 =?us-ascii?Q?L4HRE4NSCg6uDvfU7m3feoJOugYF2ixngJK52mkM63+y0bJ2CbruFz1VROE9?=
 =?us-ascii?Q?p3BdaAa9m2UaYJslNMKKjjtNVwC0BQb/n9CgM8tUEpS3wot4Q4+hzAB+iva+?=
 =?us-ascii?Q?vC+bQn9GD6bsRpZfvXbbU+bRQhIunY3QM6GB4jS9DOz17jmi3aCzR/UhJ1rt?=
 =?us-ascii?Q?CcFQLjfgxwQmEdBxRj4VqL3IHeHtZXDtzgo+gMXCE/BO0Ekq6yawhHuf19wT?=
 =?us-ascii?Q?7DVbPizKiTBlAnXWGKYqDBhLsO/zA9oWbD12qA/woTmPe6SWxkKAuDM2QJVu?=
 =?us-ascii?Q?YTyPVsqlSTdoQg5x5zGjRClK6hqhZO1vKxokND2nOspwADl9SpDzFfO1f3HS?=
 =?us-ascii?Q?pwPfLeC0x5lQ3RM01OWM1CLl5HXTHOatDBcNhuNXJBhzj3a1enK8WwCsldsQ?=
 =?us-ascii?Q?w98hX6OD1zK0qVpuh2U3cGBxbKalG/8l5VPV8UPC5rOXbxfvK1dBnUZWzTKO?=
 =?us-ascii?Q?7uADAx5rDegI2bTp/zgkuQ59NSWEPQAJrqZGbGRDDVJT7ztCW9uuxtPEKTlH?=
 =?us-ascii?Q?/lrP9Z6g0vzwtzMoxU5Ng/Zc5wsEJQviSrefLFpV1j6+zmdY0OZmIysjBZrF?=
 =?us-ascii?Q?knmA6N7hOSndq8a/BzT71v07hizXFHErQ/CReK4ucZ+sv+fv28SESwfN1ZsL?=
 =?us-ascii?Q?a3aT4dXne5VaQn7ONqUoihAET9YWKEgDME9M?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 13:21:29.8950
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a132f9db-69e7-4b85-bed0-08dd8e333e8c
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002322.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF01781787B

When a device is passed through to a dom0less domU, the xen,reg ranges
may overlap with the extended regions. Remove xen,reg from extended
regions.

Signed-off-by: Stewart Hildebrand 
---
Not sure if we need a Fixes: tag, but if we do:
Fixes: 2a2447757b3c ("xen/arm: implement domU extended regions")

v1->v2:
* adjust commit message to not mention xen,reg-cacheable
* don't call rangeset_destroy() in construct_dom0()
* rebase

I investigated an alternate approach of parsing the partial device tree
again to scan for xen,reg properties, but it resulted in quite a lot of
code duplication. Adding a rangeset pointer to "struct kernel_info" has
a much smaller diffstat, and then we avoid the need to parse the partial
device tree a second time.

I discovered this issue when booting a dom0less domU with a device
passed through. Partial device tree excerpt:

    passthrough {
        ...  ...

        axi_uart16550_0: serial@a0001000 {
            clocks = <&uart_fixed_clk>;
            compatible = "ns16550a";
            interrupt-parent = <&gic>;
            interrupts = <0 89 4>;
            reg = <0x0 0xa0001000 0x0 0x1000>;
            reg-shift = <2>;

            xen,reg = <0x0 0xa0001000 0x00 0x1000 0x0 0xa0001000>;
            xen,path = "/amba_pl@0/serial@a0000000";
            xen,force-assign-without-iommu;
        };
    };

The domU was assigned an extended region overlapping with MMIO of the
passed through device:

(XEN) d1: extended region 0: 0xa0000000->0x100000000
(XEN) d1: extended region 1: 0x200000000->0xf000000000

The domU panicked when attempting to initialize the device:

[    3.490068] a0001000.serial: ttyS0 at MMIO 0xa0001000 (irq = 15, base_baud = 6249375) is a 16550A
[    3.498843] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
[    3.498853] Mem abort info:
[    3.498855]   ESR = 0x0000000096000044
[    3.498859]   EC = 0x25: DABT (current EL), IL = 32 bits
[    3.498864]   SET = 0, FnV = 0
[    3.498867]   EA = 0, S1PTW = 0
[    3.498870]   FSC = 0x04: level 0 translation fault
[    3.498874] Data abort info:
[    3.498876]   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
[    3.498879]   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
[    3.498884]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    3.498888] [0000000000000010] user address but active_mm is swapper
[    3.498894] Internal error: Oops: 0000000096000044 [#1] SMP
[    3.498899] Modules linked in:
[    3.498908] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.10-stew #1
[    3.498917] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    3.498924] pc : mem_serial_out+0x18/0x20
[    3.498936] lr : serial8250_do_set_mctrl+0x6c/0xc0
[    3.498943] sp : ffff800081bab6d0
[    3.498946] x29: ffff800081bab6d0 x28: ffff8000815e0dc8 x27: ffff000001c29c60
[    3.498957] x26: 0000000000000000 x25: ffff00000347b900 x24: ffff000005504c00
[    3.498968] x23: ffff00000347b800 x22: 0000000000000000 x21: ffff800081b69d78
[    3.498978] x20: ffff800081b69d78 x19: 0000000000000000 x18: ffffffffffffffff
[    3.498989] x17: 3d20647561625f65 x16: 736162202c353120 x15: 3d20717269282030
[    3.498999] x14: 3030313030306178 x13: ffff800081a21ff0 x12: 00000000000007fe
[    3.499010] x11: 00000000000002aa x10: ffff800081a4dff0 x9 : ffff800081a21ff0
[    3.499020] x8 : 00000000fffff7ff x7 : ffff800081a4dff0 x6 : 0000000000000008
[    3.499030] x5 : 0000000000000000 x4 : ffff800080797584 x3 : 0000000000000002
[    3.499040] x2 : 0000000000000000 x1 : 0000000000000010 x0 : 0000000000000000
[    3.499050] Call trace:
[    3.499053]  mem_serial_out+0x18/0x20
[    3.499059]  serial8250_set_mctrl+0x34/0x40
[    3.499065]  serial_core_register_port+0x534/0x7dc
[    3.499075]  serial_ctrl_register_port+0x10/0x1c
[    3.499084]  uart_add_one_port+0x10/0x1c
[    3.499092]  serial8250_register_8250_port+0x308/0x4c0
[    3.499102]  of_platform_serial_probe+0x2c4/0x48c
[    3.499110]  platform_probe+0x68/0xdc
[    3.499120]  really_probe+0xbc/0x298
[    3.499128]  __driver_probe_device+0x78/0x12c
[    3.499135]  driver_probe_device+0xdc/0x160
[    3.499142]  __driver_attach+0x94/0x19c
[    3.499149]  bus_for_each_dev+0x74/0xd0
[    3.499155]  driver_attach+0x24/0x30
[    3.499162]  bus_add_driver+0xe4/0x208
[    3.499168]  driver_register+0x60/0x128
[    3.499176]  __platform_driver_register+0x24/0x30
[    3.499184]  of_platform_serial_driver_init+0x1c/0x28
[    3.499192]  do_one_initcall+0x6c/0x1b0
[    3.499199]  kernel_init_freeable+0x178/0x258
[    3.499209]  kernel_init+0x20/0x1d0
[    3.499218]  ret_from_fork+0x10/0x20
[    3.499228] Code: f9400800 1ac32021 8b21c001 d50332bf (39000022)
[    3.499233] ---[ end trace 0000000000000000 ]---
[    3.499237] note: swapper/0[1] exited with irqs disabled
[    3.499247] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    3.499251] SMP: stopping secondary CPUs
[    3.499284] Kernel Offset: disabled
[    3.499286] CPU features: 0x00,00000080,00200000,0200420b
[    3.499292] Memory Limit: none
[    3.792412] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
---
 xen/arch/arm/domain_build.c             |  7 +++++++
 xen/common/device-tree/dom0less-build.c | 19 ++++++++++++++++++-
 xen/include/xen/fdt-kernel.h            |  1 +
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 05a77a4f92c6..b189a7cfae9f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -973,6 +973,13 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
     if ( res )
         goto out;
 
+    if ( kinfo->xen_reg_assigned )
+    {
+        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
+        if ( res )
+            goto out;
+    }
+
     res = rangeset_report_ranges(mem_holes, 0,
                                  PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
                                  add_ext_regions, ext_regions);
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 4aa36c8ef33f..2c56f13771ab 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -146,6 +146,14 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
     int res;
     paddr_t mstart, size, gstart;
 
+    if ( !kinfo->xen_reg_assigned )
+    {
+        kinfo->xen_reg_assigned = rangeset_new(NULL, NULL, 0);
+
+        if ( !kinfo->xen_reg_assigned )
+            return -ENOMEM;
+    }
+
     /* xen,reg specifies where to map the MMIO region */
     cell = (const __be32 *)xen_reg->data;
     len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
@@ -187,6 +195,11 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
                    mstart, gstart);
             return -EFAULT;
         }
+
+        res = rangeset_add_range(kinfo->xen_reg_assigned, PFN_DOWN(gstart),
+                                 PFN_DOWN(gstart + size - 1));
+        if ( res )
+            return res;
     }
 
     /*
@@ -814,7 +827,11 @@ static int __init construct_domU(struct domain *d,
 
     domain_vcpu_affinity(d, node);
 
-    return alloc_xenstore_params(&kinfo);
+    rc = alloc_xenstore_params(&kinfo);
+
+    rangeset_destroy(kinfo.xen_reg_assigned);
+
+    return rc;
 }
 
 void __init create_domUs(void)
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 7a6cd67c22f1..1939c3ebf7dc 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -24,6 +24,7 @@ struct kernel_info {
 #ifdef CONFIG_STATIC_SHM
     struct shared_meminfo shm_mem;
 #endif
+    struct rangeset *xen_reg_assigned;
 
     /* kernel entry point */
     paddr_t entry;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 08 13:32:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 13:32:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979449.1366067 (Exim 4.92)
	(envelope-from )
	id 1uD1M3-0001v6-SU; Thu, 08 May 2025 13:32:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979449.1366067; Thu, 08 May 2025 13: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 1uD1M3-0001uu-No; Thu, 08 May 2025 13:32:03 +0000
Received: by outflank-mailman (input) for mailman id 979449;
 Thu, 08 May 2025 13:32:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD1C7-0005gg-GA
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 13:21:47 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2409::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 62f85110-2c0f-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 15:21:45 +0200 (CEST)
Received: from DM6PR21CA0019.namprd21.prod.outlook.com (2603:10b6:5:174::29)
 by PH7PR12MB7162.namprd12.prod.outlook.com (2603:10b6:510:201::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.39; Thu, 8 May
 2025 13:21:38 +0000
Received: from DS3PEPF0000C37E.namprd04.prod.outlook.com
 (2603:10b6:5:174:cafe::65) by DM6PR21CA0019.outlook.office365.com
 (2603:10b6:5:174::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.5 via Frontend Transport; Thu, 8
 May 2025 13:21:37 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS3PEPF0000C37E.mail.protection.outlook.com (10.167.23.8) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 8 May 2025 13:21:37 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 08:21:36 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 May
 2025 08:21:36 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 8 May 2025 08:21: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" 
X-Inumbo-ID: 62f85110-2c0f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lqohRbcxRLwd473pEt09JjDS0dEQmSt93Td4nlMey/hyza/Ke+9YNATRbmPV+/F/fhaNLKy5O2DYJIL3lMDGml9UngFaZqJRnA8W/vkoYsAo9VqRGiHCY9/YIRSN3ES8xDL1UZxS/eHHe3typhh+/VLnE4xzGOAb/brZCGL5RE8wAU2xe7VOazEUIMVz5mnHlmQg0Jt5oxQf9Q0jRDUoAkepFV5ImCKJw0gU+wFigSfC3lDZKq7OtHcW6DiTP/+BmS5vop++cyCROCAw25Ed6rCmqcK9aEuckx5zkptijM9J//mRAF7tHnBwvtml7zfvNYxJTV9AeTQQbAMappcdpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=yv0aMNinUzwZLRqD5eOkzeUkgE+Ciartx/yFqrABJLc=;
 b=thfQdILzQPpJGmWWbjsVQ2vM6KEucnR7ZW9t276lDkK50aYxd332ZtDS+H0cYUH/cLiCLNe8l83tOT5qoa4RW0uCXXsTkr9BvqDHFIuBeTcAxl1PHSG1AxpH4enTwLVnY8i4iSwYwprOoFBJDa82SzZAdCdx00CToSMSWUr9UMdRv6zjrlQWzthdr1E4xFhlJG8aBfsFhfXvU9jvihKPgNBSTX+Ws08EDw/Myj+A4i1DFmy9yRYXbPBpT3NGfpz/8e/GYeTBk+Ae/djFCSvzgh0n42TBPmA+B8WGl1W/1Y7Dd/vxCecGClck1Pdr1FhcC6+ZZycj/VNLnNzlp+h8tA==
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=yv0aMNinUzwZLRqD5eOkzeUkgE+Ciartx/yFqrABJLc=;
 b=aVDJCLEu1+qeR+TQTNa3rINmf9aWaOsmmJcOZLVgn9poDrX6jYYDpZEcf5OItiTfD+Kbcwk0pYsFEVBb/4NBEjK77xdf09+UtyX3xRVdh1UT3lDooFwaYiiZpCI5N4qYIr+GbizBqQbGDwVyYJTNBcLGyStl1tdX6TwNEn6FnsI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Anthony PERARD
	, Juergen Gross 
Subject: [PATCH v2 6/6] tools/arm: exclude iomem from domU extended regions
Date: Thu, 8 May 2025 09:20:35 -0400
Message-ID: <20250508132040.532898-7-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250508132040.532898-1-stewart.hildebrand@amd.com>
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF0000C37E:EE_|PH7PR12MB7162:EE_
X-MS-Office365-Filtering-Correlation-Id: 48ad42c7-53f5-4d26-cb49-08dd8e3342ee
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?4wn4ENDV+UDzYdh9V/+IYwfU9Zv2SpWycpPtSSzHKtjjWEELugfZAcLS2Imp?=
 =?us-ascii?Q?UmpuxGC3fzK1ka4kTMarOtMnZHfWBf0CBtyqAz/psAFwVjnkZnEvYAuLtSVA?=
 =?us-ascii?Q?uH0Ox+nyNyUxZB6BBuQI7hKPoXeZfwaeMgi0oXoZxrg6jwSuZ7lj678kXMvm?=
 =?us-ascii?Q?BDUJE6EYhZ+1UzCk8e7VSjMXbodzr1r6+MJbs0jwP76apF2ApzUTLzxBONof?=
 =?us-ascii?Q?eeWSZ5gkFCJ4Qpzst2i31hGq1GeoC97Uo8lWCLclTXeBtnvqYzryjfUi6sIH?=
 =?us-ascii?Q?Sy4nE5Vnzpc39UmG/N1ml8g5nomzk+ioihQctyCPrik01KEBCaiEFHnrGrHf?=
 =?us-ascii?Q?T+m412NP5cEWjnCmaSHUYX3RdVECcAhn4oOv5LKX85+MnqN3d1w3lwsVJ7zt?=
 =?us-ascii?Q?hxcsNBRMwumhUVoiG2/a/Oq0WcmD5zpZuAWlL6Vqs+u/ujh2Ed6wEFg6xIw6?=
 =?us-ascii?Q?hEK4yNJpsCo9qDG85iunKVwCPsAeWH571wLSwQTl+Yb2t7LLb2QVlAjQGRgX?=
 =?us-ascii?Q?O6lieJOBYSgV4ICM+FXi4tDRZC1VRCWG4k0lfysw051o5P8wLLgHv97xQAMk?=
 =?us-ascii?Q?OvSt0nnNHW3POc9eiRpL+USQD2MDMYIJGbAoBP2cK3rVz2hy6YYMMHlZARU7?=
 =?us-ascii?Q?vatDoFdSgkH3iUvjVLdCbcCbasMRXg136gkyPDDFjRjlqk324hk/6cmIt+CU?=
 =?us-ascii?Q?DiCOwrm1NXtpZzyZvgZOr0kweiAMFHw00GR6VzEYGO7lEx/kr1MW6i1VG25z?=
 =?us-ascii?Q?pUbb6Prl+uNfs93TpcLXELxoLO/EaUZKotVDtTy2h8e0uDyzfYy6axktfqsd?=
 =?us-ascii?Q?lFn1e9iTKum4Qjqz+jq+iKShgnJkKYdbd/JLV//QKVk1ikE+gWOshqEvewqS?=
 =?us-ascii?Q?SbQHS4KqKl/7JNeYwn3fJH7l3MPXdvHF0TJeFR9XCsuYb60/rXA4ZIt743MP?=
 =?us-ascii?Q?kL7npVgB9hhgaUtc2uxWqG03gX5qeEzK/eyr36gejCXevWn27hsHfJbl3zJ7?=
 =?us-ascii?Q?OBzX4sojIAcEf1AfIG5vOw3zs4+xDDiDZShegnsCzu74TRCVlyfz3eZV1s6j?=
 =?us-ascii?Q?sUuNzA1VPbIA/PRvof9TKCriYFGKuFlCAf0hfDdiySDNQNKay+yTaC1wpdTN?=
 =?us-ascii?Q?bywj1cNFGv+CqjpgB3LBJiUu/mI02Xr7Q6I3vmg2FEtCDrS/Qucqq9WAWhFh?=
 =?us-ascii?Q?xRkQPbrHSrsfnY60cKBKIuhDXvzZ+Pf01kiUm5Pu8MMOjz758Xwr8xz1uaYO?=
 =?us-ascii?Q?OgWYZzhONCpvudcGzjaz7KP8asZO/CTi4HGLNI1bfU9VVZf+2uFZL9OnnXHj?=
 =?us-ascii?Q?aUM4LR9bpt8uIA5AtL81L0fMv3rv+g1zzpYNmb6u50eyCFU/l+WWm9IFiy0y?=
 =?us-ascii?Q?VfgBmj0n5wil2cZxCj5ZAHRwcm13+OeIBHzEgqO4U64rjGn5IiDaE/y/gq6a?=
 =?us-ascii?Q?uEUCXiNlwwW6EbTdYu00ZuAJ2DgeSoKbvtqfpMKALDbO7+6j927VknCJuqpI?=
 =?us-ascii?Q?AOl+pyIRVJvHVInRdV0Bej8i4SYMajjhSJ0d?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2025 13:21:37.3157
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 48ad42c7-53f5-4d26-cb49-08dd8e3342ee
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF0000C37E.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7162

When a device is passed through to a xl domU, the iomem ranges may
overlap with the extended regions. Remove iomem from extended regions.

Signed-off-by: Stewart Hildebrand 
---
Not sure if we need a Fixes: tag, but if we do:
Fixes: 57f87857dc2d ("libxl/arm: Add handling of extended regions for DomU")

v1->v2:
* no change
---
 tools/libs/light/libxl_arm.c | 118 +++++++++++++++++++++++++++++------
 1 file changed, 99 insertions(+), 19 deletions(-)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 75c811053c7c..8ae16a1726fc 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -798,6 +798,8 @@ static int make_timer_node(libxl__gc *gc, void *fdt,
     return 0;
 }
 
+#define MAX_NR_EXT_REGIONS   256
+
 static int make_hypervisor_node(libxl__gc *gc, void *fdt,
                                 const libxl_version_info *vers)
 {
@@ -821,7 +823,7 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
      */
     res = fdt_property_reg_placeholder(gc, fdt, GUEST_ROOT_ADDRESS_CELLS,
                                        GUEST_ROOT_SIZE_CELLS,
-                                       GUEST_RAM_BANKS + 1);
+                                       MAX_NR_EXT_REGIONS + 1);
     if (res) return res;
 
     /*
@@ -1517,17 +1519,29 @@ static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname,
 
 #define EXT_REGION_MIN_SIZE   xen_mk_ullong(0x0004000000) /* 64MB */
 
-static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
+static int compare_iomem(const void *a, const void *b)
+{
+    const libxl_iomem_range *x = a, *y = b;
+
+    if (x->gfn < y->gfn)
+        return -1;
+    if (x->gfn > y->gfn)
+        return 1;
+    return 0;
+}
+
+static int finalize_hypervisor_node(libxl__gc *gc,
+                                    libxl_domain_build_info *b_info,
+                                    struct xc_dom_image *dom)
 {
     void *fdt = dom->devicetree_blob;
-    uint64_t region_size[GUEST_RAM_BANKS] = {0}, region_base[GUEST_RAM_BANKS],
-        bankend[GUEST_RAM_BANKS];
+    uint64_t region_base[MAX_NR_EXT_REGIONS], region_size[MAX_NR_EXT_REGIONS];
     uint32_t regs[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) *
-                  (GUEST_RAM_BANKS + 1)];
+                  (MAX_NR_EXT_REGIONS + 1)];
     be32 *cells = ®s[0];
     const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
     const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
-    unsigned int i, len, nr_regions = 0;
+    unsigned int i, j, len, nr_regions = 0;
     libxl_dominfo info;
     int offset, rc;
 
@@ -1542,20 +1556,90 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
     if (info.gpaddr_bits > 64)
         return ERROR_INVAL;
 
+    qsort(b_info->iomem, b_info->num_iomem, sizeof(libxl_iomem_range),
+          compare_iomem);
+
     /*
      * Try to allocate separate 2MB-aligned extended regions from the first
      * and second RAM banks taking into the account the maximum supported
      * guest physical address space size and the amount of memory assigned
      * to the guest.
      */
-    for (i = 0; i < GUEST_RAM_BANKS; i++) {
-        region_base[i] = bankbase[i] +
+    for (i = 0; i < GUEST_RAM_BANKS && nr_regions < MAX_NR_EXT_REGIONS; i++) {
+        struct {
+            uint64_t start;
+            uint64_t end; /* inclusive */
+        } unallocated;
+        uint64_t size = 0;
+
+        unallocated.start = bankbase[i] +
             ALIGN_UP_TO_2MB((uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT);
 
-        bankend[i] = ~0ULL >> (64 - info.gpaddr_bits);
-        bankend[i] = min(bankend[i], bankbase[i] + banksize[i] - 1);
-        if (bankend[i] > region_base[i])
-            region_size[i] = bankend[i] - region_base[i] + 1;
+        unallocated.end = ~0ULL >> (64 - info.gpaddr_bits);
+        unallocated.end = min(unallocated.end, bankbase[i] + banksize[i] - 1);
+
+        if (unallocated.end > unallocated.start)
+            size = unallocated.end - unallocated.start + 1;
+
+        if (size < EXT_REGION_MIN_SIZE)
+            continue;
+
+        /* Exclude iomem */
+        for (j = 0; j < b_info->num_iomem && nr_regions < MAX_NR_EXT_REGIONS;
+             j++) {
+            struct {
+                uint64_t start;
+                uint64_t end; /* inclusive */
+            } iomem;
+
+            iomem.start = b_info->iomem[j].gfn << XC_PAGE_SHIFT;
+            iomem.end = ((b_info->iomem[j].gfn + b_info->iomem[j].number)
+                         << XC_PAGE_SHIFT) - 1;
+
+            if (iomem.end >= unallocated.start
+                && iomem.start <= unallocated.end) {
+
+                if (iomem.start <= unallocated.start) {
+                    unallocated.start = iomem.end + 1;
+
+                    if (iomem.end >= unallocated.end)
+                        /* Complete overlap, discard unallocated region */
+                        break;
+
+                    /* Beginning overlap */
+                    continue;
+                }
+
+                if (iomem.start > unallocated.start) {
+                    assert(unallocated.end > unallocated.start);
+                    size = iomem.start - unallocated.start;
+
+                    if (size >= EXT_REGION_MIN_SIZE) {
+                        region_base[nr_regions] = unallocated.start;
+                        region_size[nr_regions] = size;
+                        nr_regions++;
+                    }
+
+                    unallocated.start = iomem.end + 1;
+
+                    if (iomem.end >= unallocated.end)
+                        /* End overlap, discard remaining unallocated region */
+                        break;
+                }
+            }
+        }
+
+        if (unallocated.end > unallocated.start
+            && nr_regions < MAX_NR_EXT_REGIONS)
+        {
+            size = unallocated.end - unallocated.start + 1;
+
+            if (size >= EXT_REGION_MIN_SIZE) {
+                region_base[nr_regions] = unallocated.start;
+                region_size[nr_regions] = size;
+                nr_regions++;
+            }
+        }
     }
 
     /*
@@ -1565,16 +1649,12 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
     set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
               GUEST_GNTTAB_BASE, GUEST_GNTTAB_SIZE);
 
-    for (i = 0; i < GUEST_RAM_BANKS; i++) {
-        if (region_size[i] < EXT_REGION_MIN_SIZE)
-            continue;
-
+    for (i = 0; i < nr_regions; i++) {
         LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"",
-            nr_regions, region_base[i], region_base[i] + region_size[i]);
+            i, region_base[i], region_base[i] + region_size[i]);
 
         set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
                   region_base[i], region_size[i]);
-        nr_regions++;
     }
 
     if (!nr_regions)
@@ -1626,7 +1706,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
 
     }
 
-    res = finalize_hypervisor_node(gc, dom);
+    res = finalize_hypervisor_node(gc, &d_config->b_info, dom);
     if (res)
         return res;
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 08 14:51:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 14:51:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979480.1366080 (Exim 4.92)
	(envelope-from )
	id 1uD2aR-0004oF-DY; Thu, 08 May 2025 14:50:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979480.1366080; Thu, 08 May 2025 14: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 1uD2aR-0004o8-Am; Thu, 08 May 2025 14:50:59 +0000
Received: by outflank-mailman (input) for mailman id 979480;
 Thu, 08 May 2025 14:50:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD2aP-0004nj-H3
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 14:50:57 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d8710715-2c1b-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 16:50:55 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ace94273f0dso224936966b.3
 for ; Thu, 08 May 2025 07:50:55 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad1891e980bsm1082773266b.76.2025.05.08.07.50.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 08 May 2025 07:50:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d8710715-2c1b-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746715855; x=1747320655; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=+HBTqfZR6NgZG35K7mvp1+0cDkzEQonUk7EnQP6X5Rc=;
        b=ONkhpWC1JYfHK259RBkoAsFyFLS27YkCT1mF5KVrX8iq8bLIVST3RnbABYqn92xVsn
         apMILovqBmS4bjAngpYOihpLMEskA9yYKvSyZ/hB4wZEELOgpXQAgWcke+LNVlZT/UZT
         e4L92jqL4sSeHu/Quw68ZyHsofKGNfDCcQVwE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746715855; x=1747320655;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+HBTqfZR6NgZG35K7mvp1+0cDkzEQonUk7EnQP6X5Rc=;
        b=UpPwRQrN4PaZd3q3MjLzFUpBohrGKGthSCHGARfuJviDcOEPulwDl84AIe4HZDQlIz
         HZ6P0QXU6Bt586z8+VGZ9FUhUKOzu/O/KspJWhmz3n48o4+GNCy7AOeozF3PZ4ZQuXRS
         cYTyiiS8CFyeoEVD0RUtNCgxXDpBL/Fxsgt6fuUyP8HnvBVwoe2/RFEcSswHc3rBcWdv
         R44TVVf/2I8uYIEfeNEehnW/SScBh0PFuNsV+OoyUvK+uU5XfGrLh3ATkr/EUzkELYJ3
         8N+n2tHvH6TT2q9cYKNDu8XBPpevTQdQDpWhdB7Ip+UIwiF3vnjhdmODMirIJmcCbxMm
         66lA==
X-Gm-Message-State: AOJu0YxzCMt8qhuuv+9vbSNp0VRk0Gryj9a902HceQzuNS7W4JYqJZDw
	rKNU28xK8V+L5JOhVbkQxdk7gEzPpSwW4/EexbzG/AF0Y4RcpfAj4Cee3p/5ocA=
X-Gm-Gg: ASbGncsaXhMpj1YyEFgbzXzT5oPTO/9LWwoB2pYeOjg405rI25FTnCnEWAp6yvAAFF3
	RQx9r1u53WMZdsp8E45oenCxr4HU1aRA6QyqLTAXDggyg0sOUskka8x0FgYx7hF8sjn/D1I8GlV
	E/hO/VIVpetVi2r+g9emHjLeHBHWi5oJ+0Bvaa84pWYcdk8d0KSNPmfhsaHOICxriHStOFUWpKk
	OQFJ/iOTNVJdLpG6ZsrRlvqBieyAF/vst6rITAs9/IqBd7ZArIBanNGc8l8+DnmiiJkmUR+5k63
	ybc2R+VU/6B+igp2tTnJZQb5QlCGmvrcQfLFUzkQTkxpuDGZfcHnTbUY
X-Google-Smtp-Source: AGHT+IHVteMDKEbgiX2m/l1kNbOGwyh/EehWfvJIEnkd6Qqaw/eelrg0fDGX+aNUXltFRVI+OqOZ6w==
X-Received: by 2002:a17:907:7246:b0:ace:68a5:ec50 with SMTP id a640c23a62f3a-ad1fe8e7fcemr297285866b.45.1746715854131;
        Thu, 08 May 2025 07:50:54 -0700 (PDT)
Date: Thu, 8 May 2025 16:50:52 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org, Kevin Lampis ,
	Anthony PERARD ,
	Juergen Gross ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH] livepatch: Pass buffer size to list sysctl
Message-ID: 
References: <20250507163859.354711-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250507163859.354711-1-ross.lagerwall@citrix.com>

On Wed, May 07, 2025 at 05:38:59PM +0100, Ross Lagerwall wrote:
> From: Kevin Lampis 
> 
> The livepatch list sysctl writes metadata into a buffer provided by the
> caller. The caller is expected to allocate an appropriately sized buffer
> but this is racy and may result in Xen writing beyond the end of the
> buffer should the metadata size change.
> 
> The name buffer is expected to be an array of elements with size
> XEN_LIVEPATCH_NAME_SIZE to avoid this kind of race but the xen-livepatch
> tool allocates only as many bytes as needed, therefore encountering the
> same potential race condition.
> 
> Fix both these issues by requiring the caller to pass in the size of the
> name and metadata buffers and then not writing beyond the allocated
> size.
> 
> The sysctl interface version is bumped due to the change in semantics of
> the fields.
> 
> Signed-off-by: Kevin Lampis 
> Signed-off-by: Ross Lagerwall 
> ---
>  tools/libs/ctrl/xc_misc.c   |  3 +++
>  xen/common/livepatch.c      | 22 +++++++++++++++++-----
>  xen/include/public/sysctl.h | 12 ++++++++----
>  3 files changed, 28 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/libs/ctrl/xc_misc.c b/tools/libs/ctrl/xc_misc.c
> index 6a60216bda03..33e87bac2868 100644
> --- a/tools/libs/ctrl/xc_misc.c
> +++ b/tools/libs/ctrl/xc_misc.c
> @@ -867,6 +867,9 @@ int xc_livepatch_list(xc_interface *xch, const unsigned int max,
>          set_xen_guest_handle(sysctl.u.livepatch.u.list.metadata, metadata);
>          set_xen_guest_handle(sysctl.u.livepatch.u.list.metadata_len, metadata_len);
>  
> +        sysctl.u.livepatch.u.list.name_total_size = name_sz;
> +        sysctl.u.livepatch.u.list.metadata_total_size = metadata_sz;
> +
>          rc = do_sysctl(xch, &sysctl);
>          /*
>           * From here on we MUST call xc_hypercall_bounce. If rc < 0 we
> diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
> index be9b7e367553..72ef22bea5d2 100644
> --- a/xen/common/livepatch.c
> +++ b/xen/common/livepatch.c
> @@ -1311,11 +1311,10 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
>          return -EINVAL;
>      }
>  
> -    list->name_total_size = 0;
> -    list->metadata_total_size = 0;
>      if ( list->nr )
>      {
>          size_t name_offset = 0, metadata_offset = 0;
> +        uint32_t name_total_copied = 0, metadata_total_copied = 0;
>  
>          list_for_each_entry( data, &payload_list, list )
>          {
> @@ -1328,10 +1327,14 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
>              status.rc = data->rc;
>  
>              name_len = strlen(data->name) + 1;
> -            list->name_total_size += name_len;
> -
>              metadata_len = data->metadata.len;
> -            list->metadata_total_size += metadata_len;
> +
> +            if ( ((uint64_t)name_total_copied + name_len) > list->name_total_size ||
> +                 ((uint64_t)metadata_total_copied + metadata_len) > list->metadata_total_size )

I would define name_total_copied and metadata_total_copied as size_t,
and then avoid doing the cast to uint64_t here.

Also please adjust line length to 80 characters max.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 08 15:22:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 15:22:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979502.1366091 (Exim 4.92)
	(envelope-from )
	id 1uD34R-0000g1-Kr; Thu, 08 May 2025 15:21:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979502.1366091; Thu, 08 May 2025 15:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uD34R-0000fu-Hg; Thu, 08 May 2025 15:21:59 +0000
Received: by outflank-mailman (input) for mailman id 979502;
 Thu, 08 May 2025 15:21:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD34P-0000fY-NX
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 15:21:57 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2a7b7888-2c20-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 17:21:52 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 589CE60008;
 Thu,  8 May 2025 15:21:50 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F907C4CEE7;
 Thu,  8 May 2025 15: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" 
X-Inumbo-ID: 2a7b7888-2c20-11f0-9ffb-bf95429c2676
Date: Thu, 8 May 2025 16:21:45 +0100
From: Catalin Marinas 
To: John Ernberg 
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Andrew Morton ,
	"xen-devel@lists.xenproject.org" ,
	"iommu@lists.linux.dev" ,
	"linux-kernel@vger.kernel.org" ,
	"imx@lists.linux.dev" ,
	"stable@kernel.org" 
Subject: Re: [PATCH 1/2] xen: swiotlb: Use swiotlb bouncing if kmalloc
 allocation demands it
Message-ID: 
References: <20250502114043.1968976-1-john.ernberg@actia.se>
 <20250502114043.1968976-2-john.ernberg@actia.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250502114043.1968976-2-john.ernberg@actia.se>

On Fri, May 02, 2025 at 11:40:55AM +0000, John Ernberg wrote:
> Xen swiotlb support was missed when the patch set starting with
> 4ab5f8ec7d71 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from
> ARCH_DMA_MINALIGN") was merged.
> 
> When running Xen on iMX8QXP, a SoC without IOMMU, the effect was that USB
> transfers ended up corrupted when there was more than one URB inflight at
> the same time.
> 
> Add a call to dma_kmalloc_needs_bounce() to make sure that allocations too
> small for DMA get bounced via swiotlb.
> 
> Closes: https://lore.kernel.org/linux-usb/ab2776f0-b838-4cf6-a12a-c208eb6aad59@actia.se/
> Fixes: 4ab5f8ec7d71 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN")
> Cc: stable@kernel.org # v6.5+
> Signed-off-by: John Ernberg 
> 
> ---
> 
> It's impossible to pick an exact fixes tag since this driver was missed
> in the flagged patch set. I picked one I felt gave a decent enough picture
> for someone coming across this later.

All the above patches went in at the same time in 6.5, so it probably
doesn't matter. In theory, you could add:

Fixes: 370645f41e6e ("dma-mapping: force bouncing if the kmalloc() size is not cache-line-aligned")
Cc:  # 6.5.x

as that's when dma_kmalloc_needs_bounce() was added (a few commits after
the "decouple ARCH_KMALLOC_MINALIGN..." one). However, actual problems
started to appear with commit 9382bc44b5f5 ("arm64: allow kmalloc()
caches aligned to the smaller cache_line_size()") which makes
ARCH_KMALLOC_MINALIGN equal 8 on arm64.

> ---
>  drivers/xen/swiotlb-xen.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 1f65795cf5d7..ef56a2500ed6 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -217,6 +217,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
>  	 * buffering it.
>  	 */
>  	if (dma_capable(dev, dev_addr, size, true) &&
> +	    !dma_kmalloc_needs_bounce(dev, size, dir) &&
>  	    !range_straddles_page_boundary(phys, size) &&
>  		!xen_arch_need_swiotlb(dev, phys, dev_addr) &&
>  		!is_swiotlb_force_bounce(dev))

Reviewed-by: Catalin Marinas 


From xen-devel-bounces@lists.xenproject.org Thu May 08 16:04:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 16:04:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979516.1366101 (Exim 4.92)
	(envelope-from )
	id 1uD3is-0006ch-Jp; Thu, 08 May 2025 16:03:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979516.1366101; Thu, 08 May 2025 16:03: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 1uD3is-0006ca-H7; Thu, 08 May 2025 16:03:46 +0000
Received: by outflank-mailman (input) for mailman id 979516;
 Thu, 08 May 2025 16:03:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD3ir-0006cT-Oi
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 16:03:45 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0206b3fa-2c26-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 18:03:40 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43cfdc2c8c9so5732745e9.2
 for ; Thu, 08 May 2025 09:03:40 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442cd350cebsm41331215e9.17.2025.05.08.09.03.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 08 May 2025 09:03: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" 
X-Inumbo-ID: 0206b3fa-2c26-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746720220; x=1747325020; 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;
        bh=mD1Fttxwc1KIw4cAsVczbb+IYoS9N4VRg6BR85MLJbA=;
        b=DUV2S7ChSofO7NKX9tooClTXrZ9u2GYltOCLGMSQhLCKvgK0RlWOH/UtTv2I91XgIW
         iasOoVXow+6vpHDfPTYNF/yVc+OQvkFjSBRsrfiil8msLTS6wFcQ2M2o72o3skRGmbN4
         4GfwTK+AMsaZ1QMeSfuC6ImmFNj8vFIBZZbng=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746720220; x=1747325020;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=mD1Fttxwc1KIw4cAsVczbb+IYoS9N4VRg6BR85MLJbA=;
        b=LC0zsK5gsIeeHSCs4fmMNCE6lLOcOGBof+qo976yabnuVa+sIu59XuHEg3/Xncq4rQ
         lmj3hSPZd7LlcNHrQBCkqqnkR6R7Dn9O286aDSLK2Rhu0JofW5sAYG0fw9dQo7RHnD6b
         7MKZdYlSs6kmqSwD8uqUo6FATrKfj/Ou7XxKAFH0wTyHVilbcTfjft/hs0g2zqvtA0z7
         pL0axJjn9hppe+OKxjIlO9jzlTW8g7LCg/9/BLEnUrGMuzb8+k3pAHEOb9JBSGiFHnKs
         p+9OQpzwd8EVMeXlKY0QS5zpCastOpt3WF+uiz7Csy/ELnc1/+rhJJ21Mt7JYylE+tDA
         3hxg==
X-Gm-Message-State: AOJu0YyX9rEZU9XpCNYpW7VgBcyo53SLlIqnBZIMOy6Rn7b5x64KcDhA
	CyhAKN+rAGpxsK+tl2ItgT7BIWjCKJVxBX7oOdToQBZj9THLUEj1SgdfqK2sEM/YXXIOgx5GhJU
	x
X-Gm-Gg: ASbGnctdtn2zTIS8YgbC58wO7Yj21nEArVaql78muYBKQ7uiDZTJ9glWhIZpkpYGR1/
	dIWWa1kqv2Kz0qn7MPH6GSQCl/7qma/pft0OuyG176dYaGa7u/R5dArDc4ZdEUKMAFmzHqgUReI
	Zgr3+q5TwJi0kbu1a+HyJByWuhnGRa/oP/NdL9HbrASWcrozK1oxiCwT4Y+6R1im+us9HtK8nPt
	dr4jK+BhJ2XdAZT17yGsigJlH4mpVhZ8lpfKLshIDOEqg4t2ZIyR63wLRo9/41TurQnPCM6sw+s
	BCI2tzA9VogdOQLwaBW2KaMO8BfoyI3rzuJHXAL4pd5/+sPs3vPVpGnUGhmm9Q0lHow4iHMKml+
	b89vuesQTGXF1yw==
X-Google-Smtp-Source: AGHT+IEKgWW3n5ZojGeTjoQzvcvOOc/DDSnpHeGPPoSC171eFZW2twbVhVK6A2XKithxs61cA0mF5w==
X-Received: by 2002:a05:600c:820a:b0:43c:f0ae:da7 with SMTP id 5b1f17b1804b1-441d44bb7f4mr74411555e9.7.1746720219417;
        Thu, 08 May 2025 09:03:39 -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/Kconfig: Improve help test for speculative options
Date: Thu,  8 May 2025 17:03:36 +0100
Message-Id: <20250508160336.2232152-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

The text for CONFIG_INDIRECT_THUNK isn't really correct, and was already stale
by the time speculative vulnerabilities hit the headlines in 2018.  It is
specifically an out-of-line-ing mechansim, and repoline is one of several
safety sequences used.

Some of this boilerplate has been copied into all other options, and isn't
interesting for the target audience given that they're all in a "Speculative
Hardning" menu.

Reword it to be more concise.

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 

CONFIG_SPECULATIVE_HARDEN_BRANCH really ought to be named
CONFIG_SPECULATIVE_HARDEN_CONDITIONAL, but this would be a (minor) functional
change.
---
 xen/common/Kconfig | 51 +++++++++-------------------------------------
 1 file changed, 10 insertions(+), 41 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 4bec78c6f267..03ef6d87abc0 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -162,29 +162,21 @@ config STATIC_MEMORY
 menu "Speculative hardening"
 
 config INDIRECT_THUNK
-	bool "Speculative Branch Target Injection Protection"
+	bool "Out-of-line Indirect Call/Jumps"
 	depends on CC_HAS_INDIRECT_THUNK
 	default y
 	help
-	  Contemporary processors may use speculative execution as a
-	  performance optimisation, but this can potentially be abused by an
-	  attacker to leak data via speculative sidechannels.
+	  Compile Xen with out-of-line indirect call and jumps.
 
-	  One source of data leakage is via branch target injection.
-
-	  When enabled, indirect branches are implemented using a new construct
-	  called "retpoline" that prevents speculation.
+	  This allows Xen to mitigate a variety of speculative vulnerabilities
+	  by choosing a hardware-dependent instruction sequence to implement
+	  (e.g. function pointers) safely.  "Retpoline" is one such sequence.
 
 config SPECULATIVE_HARDEN_ARRAY
 	bool "Speculative Array Hardening"
 	default y
 	help
-	  Contemporary processors may use speculative execution as a
-	  performance optimisation, but this can potentially be abused by an
-	  attacker to leak data via speculative sidechannels.
-
-	  One source of data leakage is via speculative out-of-bounds array
-	  accesses.
+	  Compile Xen with extra hardening for some array accesses.
 
 	  When enabled, specific array accesses which have been deemed liable
 	  to be speculatively abused will be hardened to avoid out-of-bounds
@@ -193,19 +185,12 @@ config SPECULATIVE_HARDEN_ARRAY
 	  This is a best-effort mitigation.  There are no guarantees that all
 	  areas of code open to abuse have been hardened.
 
-	  If unsure, say Y.
-
 config SPECULATIVE_HARDEN_BRANCH
 	bool "Speculative Branch Hardening"
 	default y
 	depends on X86
-        help
-	  Contemporary processors may use speculative execution as a
-	  performance optimisation, but this can potentially be abused by an
-	  attacker to leak data via speculative sidechannels.
-
-	  One source of misbehaviour is by executing the wrong basic block
-	  following a conditional jump.
+	help
+	  Compile Xen with extra hardening for some conditional branches.
 
 	  When enabled, specific conditions which have been deemed liable to
 	  be speculatively abused will be hardened to avoid entering the wrong
@@ -216,43 +201,27 @@ config SPECULATIVE_HARDEN_BRANCH
 	  optimisations in the compiler haven't subverted the attempts to
 	  harden.
 
-	  If unsure, say Y.
-
 config SPECULATIVE_HARDEN_GUEST_ACCESS
 	bool "Speculative PV Guest Memory Access Hardening"
 	default y
 	depends on PV
 	help
-	  Contemporary processors may use speculative execution as a
-	  performance optimisation, but this can potentially be abused by an
-	  attacker to leak data via speculative sidechannels.
-
-	  One source of data leakage is via speculative accesses to hypervisor
-	  memory through guest controlled values used to access guest memory.
+	  Compile Xen with extra hardening for PV guest memory access.
 
 	  When enabled, code paths accessing PV guest memory will have guest
 	  controlled addresses massaged such that memory accesses through them
 	  won't touch hypervisor address space.
 
-	  If unsure, say Y.
-
 config SPECULATIVE_HARDEN_LOCK
 	bool "Speculative lock context hardening"
 	default y
 	depends on X86
 	help
-	  Contemporary processors may use speculative execution as a
-	  performance optimisation, but this can potentially be abused by an
-	  attacker to leak data via speculative sidechannels.
-
-	  One source of data leakage is via speculative accesses to lock
-	  critical regions.
+	  Compile Xen with extra hardening for locked regions.
 
 	  This option is disabled by default at run time, and needs to be
 	  enabled on the command line.
 
-	  If unsure, say Y.
-
 endmenu
 
 menu "Other hardening"

base-commit: aea52ce607fe716acc56ad89f07e1513c89018eb
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 08 17:02:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 17:02:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979533.1366110 (Exim 4.92)
	(envelope-from )
	id 1uD4dJ-0006SD-KI; Thu, 08 May 2025 17:02:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979533.1366110; Thu, 08 May 2025 17: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 1uD4dJ-0006S6-Hb; Thu, 08 May 2025 17:02:05 +0000
Received: by outflank-mailman (input) for mailman id 979533;
 Thu, 08 May 2025 17:02:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD4dH-0006Rv-V5
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 17:02:03 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 28a6385e-2c2e-11f0-9ffb-bf95429c2676;
 Thu, 08 May 2025 19:02:01 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ac345bd8e13so167543466b.0
 for ; Thu, 08 May 2025 10:02:01 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197be6d7sm11669266b.157.2025.05.08.10.01.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 08 May 2025 10:01: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" 
X-Inumbo-ID: 28a6385e-2c2e-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746723720; x=1747328520; 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;
        bh=svV216COIFgHM/2K92/3WYhrsgYMfWGjXZ9ca1Af6v0=;
        b=NMyG/gyIlm3n+NpFFQOYySIFPy4d+GkZnGyz6MiWiow7tY+U8FiBAGNMbOIbu1DERc
         cvdRg8oXP2U2H4/8GZsrfZcNF15ptmIQSWsb4Wq2xEwV7NyFoRxAvRMwzs2sWvb5ztH4
         C/OdPT92tz8y5L4JswA+dXz6bQlSlNWK2eV6E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746723720; x=1747328520;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=svV216COIFgHM/2K92/3WYhrsgYMfWGjXZ9ca1Af6v0=;
        b=iVReZbLNCpnJ5DCwo2vHVwJ5je9LZqjNvlt832SF/6TTOc7a65x6h/E656nSR/nLfP
         Wly1AqLihEG1Ijz08Uok75kOMZpx3wVuAMJHYA+Y9f5e+yA7EBLQdZ9Ryed97rlvGNrK
         qDPTQulxCvcVBeIZCqcowGOqUY+pjw43XbSJ/QmoLKDeDVwB5OatCfA8FaDIOG7kL0VR
         +QYEPN9z2G/dGpey2y6oo5wIie1i9in0ZYyO4SIM4/xqM1vDEKo4b4bGQsx7xso1lezr
         t0JU49PJDmFaexRHp2Ke0vJJV9jrtCXXdg34/r9dfoqPo5mltNlD2AawXel4fRMSalyH
         mFEQ==
X-Gm-Message-State: AOJu0Yy2S5rP+9rI6bAuNA55zjvcJqHA/jeA0YbeU/TRE1MS4q+tZlzi
	hkoUbZTvpmtMg0JiSCqgZd8rCIK6+/6jOlfROD0PHAyHLcQsHURzH5VNaThrrQmbo9m661dy6Ho
	=
X-Gm-Gg: ASbGncv8GW81Rjl33cAItQOnd89D/EKhy5jxCoeh/s2EK9VkEhYJanT0u5H1ACb+Vfx
	Z9x+imfFO5eKI8xEOL8gZd2yXYwqB6d8g2HpxKKbVCPkhNjLf4kYeTqxM7wdTxwdKxhjMIHu+t+
	X55EtrgLDJ51pTrSBdGUbSfelDQYrynEYr3y46lgX6HvYu9EQUp3nXzUK+tQdZOBDrd0cqA8dqn
	b+FoiNj/s3zzyNI1G8MaBHH/nqHAe+quqExAOrML7ONsNpK++5/D5J4wQXlV54nDOmLYbsDeuJa
	yaciqbvVeMyp0EnI1e8lXJHmHB6VQyxIXMaU6Y70xv4lX1uh6H050o6yBYgFXZ1p
X-Google-Smtp-Source: AGHT+IHGemGNy+Yzyuspx8Nc/iVVq/FO96sw/M2WjuMroEh4CB4QyLlfMjGB0ELXvKT3AjvCUGh4Xw==
X-Received: by 2002:a17:907:6a13:b0:ace:6f45:b5c6 with SMTP id a640c23a62f3a-ad218edd00cmr48084366b.22.1746723719996;
        Thu, 08 May 2025 10:01:59 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Kevin Lampis ,
	Anthony PERARD ,
	Juergen Gross ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Ross Lagerwall 
Subject: [PATCH v2] livepatch: Pass buffer size to list sysctl
Date: Thu,  8 May 2025 18:01:56 +0100
Message-ID: <20250508170156.558291-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Kevin Lampis 

The livepatch list sysctl writes metadata into a buffer provided by the
caller. The caller is expected to allocate an appropriately sized buffer
but this is racy and may result in Xen writing beyond the end of the
buffer should the metadata size change.

The name buffer is expected to be an array of elements with size
XEN_LIVEPATCH_NAME_SIZE to avoid this kind of race but the xen-livepatch
tool allocates only as many bytes as needed, therefore encountering the
same potential race condition.

Fix both these issues by requiring the caller to pass in the size of the
name and metadata buffers and then not writing beyond the allocated
size.

The sysctl interface version is bumped due to the change in semantics of
the fields.

Signed-off-by: Kevin Lampis 
Signed-off-by: Ross Lagerwall 
---

In v2:

Change type to size_t and fix line length.

 tools/libs/ctrl/xc_misc.c   |  3 +++
 xen/common/livepatch.c      | 23 ++++++++++++++++++-----
 xen/include/public/sysctl.h | 12 ++++++++----
 3 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/tools/libs/ctrl/xc_misc.c b/tools/libs/ctrl/xc_misc.c
index 6a60216bda03..33e87bac2868 100644
--- a/tools/libs/ctrl/xc_misc.c
+++ b/tools/libs/ctrl/xc_misc.c
@@ -867,6 +867,9 @@ int xc_livepatch_list(xc_interface *xch, const unsigned int max,
         set_xen_guest_handle(sysctl.u.livepatch.u.list.metadata, metadata);
         set_xen_guest_handle(sysctl.u.livepatch.u.list.metadata_len, metadata_len);
 
+        sysctl.u.livepatch.u.list.name_total_size = name_sz;
+        sysctl.u.livepatch.u.list.metadata_total_size = metadata_sz;
+
         rc = do_sysctl(xch, &sysctl);
         /*
          * From here on we MUST call xc_hypercall_bounce. If rc < 0 we
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index be9b7e367553..fc250c338da9 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1311,11 +1311,10 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
         return -EINVAL;
     }
 
-    list->name_total_size = 0;
-    list->metadata_total_size = 0;
     if ( list->nr )
     {
         size_t name_offset = 0, metadata_offset = 0;
+        size_t name_total_copied = 0, metadata_total_copied = 0;
 
         list_for_each_entry( data, &payload_list, list )
         {
@@ -1328,10 +1327,15 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
             status.rc = data->rc;
 
             name_len = strlen(data->name) + 1;
-            list->name_total_size += name_len;
-
             metadata_len = data->metadata.len;
-            list->metadata_total_size += metadata_len;
+
+            if ( (name_total_copied + name_len) > list->name_total_size ||
+                 (metadata_total_copied + metadata_len) >
+                 list->metadata_total_size )
+            {
+                rc = -ENOMEM;
+                break;
+            }
 
             if ( !guest_handle_subrange_okay(list->name, name_offset,
                                              name_offset + name_len - 1) ||
@@ -1355,6 +1359,9 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
                 break;
             }
 
+            name_total_copied += name_len;
+            metadata_total_copied += metadata_len;
+
             idx++;
             name_offset += name_len;
             metadata_offset += metadata_len;
@@ -1362,9 +1369,15 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
             if ( (idx >= list->nr) || hypercall_preempt_check() )
                 break;
         }
+
+        list->name_total_size = name_total_copied;
+        list->metadata_total_size = metadata_total_copied;
     }
     else
     {
+        list->name_total_size = 0;
+        list->metadata_total_size = 0;
+
         list_for_each_entry( data, &payload_list, list )
         {
             list->name_total_size += strlen(data->name) + 1;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index b0fec271d36f..9eca72865b87 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -26,9 +26,9 @@
  * (e.g. adding semantics to 0-checked input fields or data to zeroed output
  * fields) don't require a change of the version.
  *
- * Last version bump: Xen 4.17
+ * Last version bump: Xen 4.21
  */
-#define XEN_SYSCTL_INTERFACE_VERSION 0x00000015
+#define XEN_SYSCTL_INTERFACE_VERSION 0x00000016
 
 /*
  * Read console content from Xen buffer ring.
@@ -1101,8 +1101,12 @@ struct xen_sysctl_livepatch_list {
                                                amount of payloads and version.
                                                OUT: How many payloads left. */
     uint32_t pad;                           /* IN: Must be zero. */
-    uint32_t name_total_size;               /* OUT: Total size of all transfer names */
-    uint32_t metadata_total_size;           /* OUT: Total size of all transfer metadata */
+    uint32_t name_total_size;               /* IN: Size of name buffer
+                                               OUT: Total size of transferred
+                                               names */
+    uint32_t metadata_total_size;           /* IN: Size of metadata buffer
+                                               OUT: Total size of transferred
+                                               metadata */
     XEN_GUEST_HANDLE_64(xen_livepatch_status_t) status;  /* OUT. Must have enough
                                                space allocate for nr of them. */
     XEN_GUEST_HANDLE_64(char) name;         /* OUT: Array of names. Each member
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 08 20:18:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 20:18:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979581.1366122 (Exim 4.92)
	(envelope-from )
	id 1uD7ha-0005OL-Qe; Thu, 08 May 2025 20:18:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979581.1366122; Thu, 08 May 2025 20:18: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 1uD7ha-0005OE-ML; Thu, 08 May 2025 20:18:42 +0000
Received: by outflank-mailman (input) for mailman id 979581;
 Thu, 08 May 2025 20:18:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD7hZ-0005O8-5Y
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 20:18:41 +0000
Received: from fout-b3-smtp.messagingengine.com
 (fout-b3-smtp.messagingengine.com [202.12.124.146])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a02caff2-2c49-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 22:18:39 +0200 (CEST)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfout.stl.internal (Postfix) with ESMTP id 22AC31140113;
 Thu,  8 May 2025 16:18:37 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Thu, 08 May 2025 16:18:37 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 8 May 2025 16:18:35 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a02caff2-2c49-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1746735516;
	 x=1746821916; bh=wZArqTjX+Eurv0Dg2HLUKLKT6iFfH7o4KhILEFsOljQ=; b=
	Q8FUVZjPNpJ/FzRuhxRBClb0f67nvWwOxsgWk464ePTbMUvdbNaWH4bpkwIRcf0Q
	2Rpjwa6xsRndSFNDvGXyx+52WLteIHu5Po+6EQTxQAIqJv5WmqfyzgeTUenRcyy3
	Ln4iq8kXIGfuk6o1kHMrTudvYmN+aiTkh0OxWcn9E+ZNCvvhJRCSCf8QlyVOraFU
	npY7oQYqQAP2Z7NeENfHOFpxL2nd8XgrpYK40cBUNp7lIkeUWFo/ePh2Eoo14cNU
	oMx1PRvstTIlLcrwL3m+kCjRLXRPx5ZDNpHLAgd+gpFJ3XSidPtGNvKF9DX5ipzq
	XM2yCKD0BJqkGrZEAMGenw==
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=fm3; t=
	1746735516; x=1746821916; bh=wZArqTjX+Eurv0Dg2HLUKLKT6iFfH7o4KhI
	LEFsOljQ=; b=jccUf1CUoeM6UEb4wTf0VBNfTcmD4D47LyEkDRUhFUrfq0bgRai
	zDrKS3+pBWUeUOjByBw69gp+4dtbM/IFZhtGT4DDYt9UdiYM8TfzPEj9bNMpHfrS
	kEaKrj/Q4OFiIIjUsR4M6DBwZQhwVVkc6fZIcYRHMpc6jEOFokAnarU/t3EPVvG3
	Trtub5jjvQuJ3Z5PZ0vFcnrkFndviqYPZNWuKBANFFs7Wdh4iLR3SrR2SEzNbuQG
	I0/31CbLO4AaS31I3IRW0E9SYUxZJGWhLr6X/SOT+0e2Ba0wreieC5KCm0f+3zhM
	7O8PNcE5w/dK48uPE9CeiCsfEJqH9Ry36zw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvledtieekucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepieeluddvkeejueekhfffteegfeeiffefjeejvdeijedvgfejhe
    etuddvkeffudeinecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghr
    ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvh
    hishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeekpdhmohgu
    vgepshhmthhpohhuthdprhgtphhtthhopehjrghsohhnrdgrnhgurhihuhhksegrmhgurd
    gtohhmpdhrtghpthhtohepjhhgrhhoshhssehsuhhsvgdrtghomhdprhgtphhtthhopehs
    shhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhopeholhgvkhhsrg
    hnughrpghthihshhgthhgvnhhkohesvghprghmrdgtohhmpdhrtghpthhtohepsghorhhi
    shdrohhsthhrohhvshhkhiesohhrrggtlhgvrdgtohhmpdhrtghpthhtohepshhtrggslh
    gvsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtohepgigvnhdquggvvhgvlhes
    lhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheplhhinhhugidqkh
    gvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 8 May 2025 22:18:32 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jason Andryuk 
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Boris Ostrovsky ,
	stable@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xenbus: Use kref to track req lifetime
Message-ID: 
References: <20250506210935.5607-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="qkJiPgqLCT4AW8qo"
Content-Disposition: inline
In-Reply-To: <20250506210935.5607-1-jason.andryuk@amd.com>


--qkJiPgqLCT4AW8qo
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 May 2025 22:18:32 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jason Andryuk 
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Boris Ostrovsky ,
	stable@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xenbus: Use kref to track req lifetime

On Tue, May 06, 2025 at 05:09:33PM -0400, Jason Andryuk wrote:
> Marek reported seeing a NULL pointer fault in the xenbus_thread
> callstack:
> BUG: kernel NULL pointer dereference, address: 0000000000000000
> RIP: e030:__wake_up_common+0x4c/0x180
> Call Trace:
>  
>  __wake_up_common_lock+0x82/0xd0
>  process_msg+0x18e/0x2f0
>  xenbus_thread+0x165/0x1c0
>=20
> process_msg+0x18e is req->cb(req).  req->cb is set to xs_wake_up(), a
> thin wrapper around wake_up(), or xenbus_dev_queue_reply().  It seems
> like it was xs_wake_up() in this case.
>=20
> It seems like req may have woken up the xs_wait_for_reply(), which
> kfree()ed the req.  When xenbus_thread resumes, it faults on the zero-ed
> data.
>=20
> Linux Device Drivers 2nd edition states:
> "Normally, a wake_up call can cause an immediate reschedule to happen,
> meaning that other processes might run before wake_up returns."
> ... which would match the behaviour observed.
>=20
> Change to keeping two krefs on each request.  One for the caller, and
> one for xenbus_thread.  Each will kref_put() when finished, and the last
> will free it.
>=20
> This use of kref matches the description in
> Documentation/core-api/kref.rst
>=20
> Link: https://lore.kernel.org/xen-devel/ZO0WrR5J0xuwDIxW@mail-itl/
> Reported-by: "Marek Marczykowski-G=C3=B3recki" 
> Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent=
 xenstore accesses")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jason Andryuk 
> ---
> Kinda RFC-ish as I don't know if it fixes Marek's issue.  This does seem
> like the correct approach if we are seeing req free()ed out from under
> xenbus_thread.

Thanks for the patch! I don't have easy way to test if it definitely
fixes the issues (due to poor reproduction rate), but it looks very
likely. I did run it through our CI and at least there it didn't crash
(but again, it doesn't happen often).

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--qkJiPgqLCT4AW8qo
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgdEZkACgkQ24/THMrX
1yz5FAgAhQUkBLIS6ba26NE9OtI7whD/OKYYKBosqmstTcpUark0KVM6gkGx/JNN
g7NFpvp/LeozFs+J/Ol27sqhCdUIFoFo4OGL31gR9riNimt2xG7xOfmv09376fjo
3UbYN0R9tXzr56c3jL2y2k1fNi4+K0udX6eYKz8YsLytYvt+TrUGVFAPl2HqC09Y
uMQaRfwGVq53kcfHDO7HAcP9Xi/Igc4ucyZ5fNk9RzlDAFK2VktYF3OcsLT3sZcs
dEkMZA3uAJl+PSCcMmQ7WwmyF06sYllkeGmMQ2dQL/OAWICUCfr7jv24Sh0m7kTx
abAMG7wNfu45kMbQtkK3yehIOllexQ==
=mAy6
-----END PGP SIGNATURE-----

--qkJiPgqLCT4AW8qo--


From xen-devel-bounces@lists.xenproject.org Thu May 08 20:44:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 20:44:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979597.1366130 (Exim 4.92)
	(envelope-from )
	id 1uD86l-0001FC-Lc; Thu, 08 May 2025 20:44:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979597.1366130; Thu, 08 May 2025 20: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 1uD86l-0001F5-Iy; Thu, 08 May 2025 20:44:43 +0000
Received: by outflank-mailman (input) for mailman id 979597;
 Thu, 08 May 2025 20:44:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uD86j-0001Ez-Hg
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 20:44:41 +0000
Received: from fout-b3-smtp.messagingengine.com
 (fout-b3-smtp.messagingengine.com [202.12.124.146])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 42d3b70c-2c4d-11f0-9eb4-5ba50f476ded;
 Thu, 08 May 2025 22:44:40 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.stl.internal (Postfix) with ESMTP id E02D811400E7
 for ; Thu,  8 May 2025 16:44:38 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Thu, 08 May 2025 16:44:38 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Thu, 8 May 2025 16:44:38 -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" 
X-Inumbo-ID: 42d3b70c-2c4d-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:content-type:content-type:date:date
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to; s=fm3; t=1746737078; x=1746823478; bh=PwO9USl0xy
	1bpjtdKoVFUG++naPzLOfDRLfYMGngNmc=; b=lS1uU+ckU1zNw1KhWCh+1tblRc
	Qpuk5vZyBvHhzzluUfI1cjCEP2PW30PMvTGp0Sa7lJbQMbOi/ydASrjB3aFpwKGW
	YahjAGYnVaU0vLgnxGuVmiaLLYrgTzUKb+VdAdkiU1qZm3tLADlLiAPRdqztJRhL
	bGhA1sW49bKgHeVve0EVr7uufNI2TtudlieYEV0mrs36Oj6bkzdVM9Sv781SBWk9
	6wyRvsFQxf9ZHKLJmCQBcUvZXdtoIuPaO8Ya0XfYFmIhLnpVr85cMcj25nVOQSRJ
	4WIrzNKrPUJN9XceYU5vV8Ie6wxupDfQRWAAxhWr/NkZXGWpQcBGkNMQaW7Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:message-id
	:mime-version:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1746737078; x=
	1746823478; bh=PwO9USl0xy1bpjtdKoVFUG++naPzLOfDRLfYMGngNmc=; b=B
	v9xCxTDF5pCOwVoG5tXwbwNO9/gbzxGHUmeBpsTghXZFGYgOFEFUOa4l2lldGnVH
	WgwFtyv6797ot96Qi3oAlyPqTp8cn6OHUsn/NkrpiieXd0PA/bdvOe/wc4xlmMEZ
	p2jzAhNTtvxpcxbVENsNgz9S+AK4FBkAgIRoH2PON2IC33j7aGHMpBOmlqz38FeP
	cGuRoYuBQHNKR413Gg3Go/v2lpD+SMt9mzoR7Do3qnFmKES9kzJoA5huLYJFR2jE
	oY5So///srr4B7r03EucoHMz4Y2ScdDDKPU9tuipygJFqhDFbXhKVWHJhsYvzv+c
	pXd7o9jB7G4ptMlTZeSUA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvledtjeefucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhf
    fvuffkgggtugesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhho
    fihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhih
    hnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepieffjeeuheeghfeutefftdeu
    fefhieethfehveehteefgfeuudelffefffehledvnecuffhomhgrihhnpehgihhtlhgrsg
    drtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
    pehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsg
    gprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeigvghnqdgu
    vghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 8 May 2025 22:44:36 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Subject: Issues on Zen4 (hw12) runner
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ltRkEotGNvk1artC"
Content-Disposition: inline


--ltRkEotGNvk1artC
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 May 2025 22:44:36 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Subject: Issues on Zen4 (hw12) runner

Hi,

I wanted to post another revision of the series adding hw12 runner,
hoping that all known issues are fixed now, but unfortunately there is
still something broken. I've rebased my series on top of staging
(ed9488a0d) and got this pipeline:

https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1807819142
(note due to some added debugging, some tests are incorrectly marked as
success even if they failed...)

1. USB ethernet doesn't work on PVH dom0: https://gitlab.com/xen-project/pe=
ople/marmarek/xen/-/jobs/9978694739
There supposed to be an USB ethernet device connected to the USB
controller at c3:00.4. In the PV dom0 case it's detected as:

    [    3.911555] usb 7-1.4: new high-speed USB device number 3 using xhci=
_hcd
    [    4.004201] usb 7-1.4: New USB device found, idVendor=3D0bda, idProd=
uct=3D8153, bcdDevice=3D30.00
    [    4.004675] usb 7-1.4: New USB device strings: Mfr=3D1, Product=3D2,=
 SerialNumber=3D6
    [    4.005079] usb 7-1.4: Product: USB 10/100/1000 LAN
    [    4.005349] usb 7-1.4: Manufacturer: Realtek
    [    4.005599] usb 7-1.4: SerialNumber: 684D35

But it's not there on PVH. The USB controller itself is detected, just
not device(s) connected to it. This applies to other controllers too
(there should be about 3 or 4 other USB devices - none of them show up).

2. There is a bunch of "unhandled memory read" errors during PVH dom0
startup: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/99786947=
39

    (XEN) [    4.026323] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory r=
ead from 0xfedc0020 size 1
    (XEN) [    4.026789] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory r=
ead from 0xfedc0021 size 1
    (XEN) [    4.027247] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory r=
ead from 0xfedc0020 size 1
    (XEN) [    4.027671] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory r=
ead from 0xfedc0021 size 1
    ...

This repeats several times. Could be related to the USB issue above?

There is also, likely related:

    (XEN) [    5.002036] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 24=
84: unsupported address 0
    (XEN) [    5.002365] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 24=
84: unsupported address 0
    (XEN) [    5.002693] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 24=
84: unsupported address 0

3. Sometimes it fails to print anything on the console, like here: https://=
gitlab.com/xen-project/people/marmarek/xen/-/jobs/9977761447
This is likely some boot issue before Xen starts (possibly the power button
is pressed to early). Anyway, I need to fix it before adding the runner.

4. There is a bunch of unknown MSR accesses, but that's likely to be
expected. For example:

    (XEN) [    6.010446] arch/x86/pv/emul-priv-op.c:1017:d0v11 RDMSR 0xc001=
02b0 unimplemented
    (XEN) [    6.010798] arch/x86/pv/emul-priv-op.c:1017:d0v0 RDMSR 0xc0010=
2b1 unimplemented


--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--ltRkEotGNvk1artC
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgdF7QACgkQ24/THMrX
1yy3vwf9G9Sct9lMHrIo/6pOKT3O4XD5Z0SSO+ye+TlUT3RyRa1Lj75xg6D3tjId
1RJA5iUe49GJgOMM23r55YhaXif0NEfFveCwNzj3MYGdpjpT6bPfoKl9hoaI51Ak
h21+D2XKH6nekWALUSLX6pI0Hm+S3eR9OFsbh1w/ASl78zdYv6qkdePElwPecrPl
XCJ86ipNcgk2Pc/hiD4F4h9SXUeevUDUr1Ozd0CWFGWVPx7vTfofFTQiQlZdWvrx
7jXq59GAH1XjeF0ZwsKU0EXfCMmg4BF94klRprC5ZMFgDeZqdhWix/BbpLNR3KG+
9X7lyxy5wvBlEtpeu8PqL4ixAUvIzg==
=xQa+
-----END PGP SIGNATURE-----

--ltRkEotGNvk1artC--


From xen-devel-bounces@lists.xenproject.org Thu May 08 23:15:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 23:15:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979628.1366141 (Exim 4.92)
	(envelope-from )
	id 1uDAS9-000365-J1; Thu, 08 May 2025 23:14:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979628.1366141; Thu, 08 May 2025 23: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 1uDAS9-00035y-GF; Thu, 08 May 2025 23:14:57 +0000
Received: by outflank-mailman (input) for mailman id 979628;
 Thu, 08 May 2025 23:14:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDAS8-00035s-KZ
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 23:14:56 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3fb04f68-2c62-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 01:14:54 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id CE8E949E37;
 Thu,  8 May 2025 23:14:52 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58903C4CEE7;
 Thu,  8 May 2025 23: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" 
X-Inumbo-ID: 3fb04f68-2c62-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746746092;
	bh=b/rZbBu/kd8miGQyME180cFglbDpC6omgZiTM3EgZvE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=muucR9EJAc7m4NJf2H9VIUt1waSHNztv2dI0HxkkiYDyNzgZ20+vhc/hLIi7SplRQ
	 G/ZPN5ry52zgZV+Vy47H0TIG4563fxjhHcXUBYyAYxlAjqhbcgRqxvlyD1DGFPaAjH
	 nETZt1r3fGNF266oTJ4K9isd8g//Ojqy5xKqH8OqZtCMOzhr+KtQ31IFHTQp9E02u3
	 2MtaMfiq0j0cxwK5ApE6IbFR6GxooQJ6iLlPTNt9NXt8sjoFhsphLeZFhltN1du7CH
	 cj74y0Cb8lHczM05duqYh5D9W4mwdas5K17oxFuno1yqYfSgDDRfCE3lht3rlTwQH8
	 BPK+YOn1pH/qw==
Date: Thu, 8 May 2025 16:14:49 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Christoph Hellwig 
cc: Stefano Stabellini , 
    John Ernberg , Juergen Gross , 
    Oleksandr Tyshchenko , 
    Catalin Marinas , 
    Andrew Morton , 
    "xen-devel@lists.xenproject.org" , 
    "iommu@lists.linux.dev" , 
    "linux-kernel@vger.kernel.org" , 
    "imx@lists.linux.dev" 
Subject: Re: [PATCH 2/2] xen: swiotlb: Implement map_resource callback
In-Reply-To: 
Message-ID: 
References: <20250502114043.1968976-1-john.ernberg@actia.se> <20250502114043.1968976-3-john.ernberg@actia.se>  <75266eb7-66a4-4477-ae8a-cbd1ebbee8db@actia.se>
  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 7 May 2025, Christoph Hellwig wrote:
> On Wed, May 07, 2025 at 04:09:15PM -0700, Stefano Stabellini wrote:
> > > This mapping is not for a RAM backed address. In the eDMA case for the 
> > > iMX8QXP the `phys` coming in here is the address of a register.
> > 
> > Ok, this information is important :-)
> > 
> > I am not certain whether the map_resource interface can only be called
> > for MMIO addresses or if it can also be called for RAM-backed addresses
> > with a size > PAGE_SIZE. In the latter case, we could run into the issue
> > I was describing.
> 
> map_resource is intended for MMIO regions, although those could be >
> PAGE_SIZE.  It must not be called on RAM.

In that case, John, you can just use dma_direct_map_resource().

That's because MMIO regions:
- are 1:1 mapped on ARM
- are 1:1 mapped on x86 for PV Dom0
- might not be 1:1 mapped on x86 for PVH Dom0, but in this case we rely
  on the IOMMU to do address translation

In none of these cases xen_phys_to_dma would give us any interesting
results.  It would be the same as calling phys_to_dma.


From xen-devel-bounces@lists.xenproject.org Thu May 08 23:25:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 23:25:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979638.1366150 (Exim 4.92)
	(envelope-from )
	id 1uDAcT-0004gp-FY; Thu, 08 May 2025 23:25:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979638.1366150; Thu, 08 May 2025 23:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDAcT-0004gi-Cu; Thu, 08 May 2025 23:25:37 +0000
Received: by outflank-mailman (input) for mailman id 979638;
 Thu, 08 May 2025 23:25:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDAcS-0004gc-Dc
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 23:25:36 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bc8bc007-2c63-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 01:25:34 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 22E2E5C63DA;
 Thu,  8 May 2025 23:23:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 990CDC4CEE7;
 Thu,  8 May 2025 23:25: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" 
X-Inumbo-ID: bc8bc007-2c63-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746746731;
	bh=r8gXRssEaAyfxC1TpdaNO8FKnyszIuhhky1+cCoj8iQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=rm42/+cmShmdAolVPFtwryRW3tA4AnTciZWEpQSGajppIjRLrnCqKlQrq8f6x8n+L
	 4jF1ta4DzT/9NZ+VCvPnOT2cpY2KR/5pK+vy//z1JzNxmUmRrhLvU2aUBahGu/XwiE
	 ++M6hro/K59VZrlXuvp7JQiEUfg9YynQrJJztCgIKgF6Ub3vuB2SkGTnmqYPw7Pqn0
	 +sRWBujFNjBIuXrmNZH15iOY3Qf14WqH2FKaVqCgi98JfSAjgpeQXLZxeNNDSyd+KI
	 h7uWnxbjCHBYkSOS0lSdVgD3/n6xcZk7H0YT3BeWnS8o+0lVfSdnZzHfbMmh5ySYfh
	 P3bMnP+aF7OzA==
Date: Thu, 8 May 2025 16:25:28 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
cc: Stefano Stabellini , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Jan Beulich , 
    "Ragiadakou, Xenia" , 
    Andrew Cooper , jason.andryuk@amd.com, 
    agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
In-Reply-To: 
Message-ID: 
References:  <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>   
    
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1244094392-1746746327=:3879245"
Content-ID: 

  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-1244094392-1746746327=:3879245
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Thu, 8 May 2025, Roger Pau Monné wrote:
> On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
> > On Tue, 6 May 2025, Roger Pau Monné wrote:
> > > On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
> > > > On Mon, 5 May 2025, Roger Pau Monné wrote:
> > > > > On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> > > > > > On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
> > > > > > > On Mon, 28 Apr 2025, Jan Beulich wrote:
> > > > > > > > On 25.04.2025 22:19, Stefano Stabellini wrote:
> > > > > > > > > From: Xenia Ragiadakou 
> > > > > > > > > 
> > > > > > > > > Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> > > > > > > > > addresses to firmware or co-processors not behind an IOMMU.
> > > > > > > > 
> > > > > > > > I definitely don't understand the firmware part: It's subject to the
> > > > > > > > same transparent P2M translations as the rest of the VM; it's just
> > > > > > > > another piece of software running there.
> > > > > > > > 
> > > > > > > > "Co-processors not behind an IOMMU" is also interesting; a more
> > > > > > > > concrete scenario might be nice, yet I realize you may be limited in
> > > > > > > > what you're allowed to say.
> > > > > > > 
> > > > > > > Sure. On AMD x86 platforms there is a co-processor called PSP running
> > > > > > > TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionally to
> > > > > > > pass addresses to it.  See drivers/tee/amdtee/ and
> > > > > > > include/linux/psp-tee.h in Linux.
> > > > > > 
> > > > > > We had (have?) similar issue with amdgpu (for integrated graphics) - it
> > > > > > uses PSP for loading its firmware. With PV dom0 there is a workaround as
> > > > > > dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, but I
> > > > > > expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's
> > > > > > the one I used for debugging this issue).
> > > > > 
> > > > > That's ugly, and problematic when used in conjunction with AMD-SEV.
> > > > > 
> > > > > I wonder if Xen could emulate/mediate some parts of the PSP for dom0
> > > > > to use, while allowing Xen to be the sole owner of the device.  Having
> > > > > both Xen and dom0 use it (for different purposes) seems like asking
> > > > > for trouble.  But I also have no idea how complex the PSP interface
> > > > > is, neither whether it would be feasible to emulate the
> > > > > interfaces/registers needed for firmware loading.
> > > > 
> > > > Let me take a step back from the PSP for a moment. I am not opposed to a
> > > > PSP mediator in Xen, but I want to emphasize that the issue is more
> > > > general and extends well beyond the PSP.
> > > > 
> > > > In my years working in embedded systems, I have consistently seen cases
> > > > where Dom0 needs to communicate with something that does not go through
> > > > the IOMMU. This could be due to special firmware on a co-processor, a
> > > > hardware erratum that prevents proper IOMMU usage, or a high-bandwidth
> > > > device that technically supports the IOMMU but performs poorly unless
> > > > the IOMMU is disabled. All of these are real-world examples that I have
> > > > seen personally.
> > > 
> > > I wouldn't be surprised, classic PV dom0 avoided those issues because
> > > it was dealing directly with host addresses (mfns), but that's not the
> > > case with PVH dom0.
> > 
> > Yeah
> > 
> > 
> > > > In my opinion, we definitely need a solution like this patch for Dom0
> > > > PVH to function correctly in all scenarios.
> > > 
> > > I'm not opposed to having such interface available for PVH hardware
> > > domains.  I find it ugly, but I don't see much other way to deal with
> > > those kind of "devices".  Xen mediating accesses for each one of them
> > > is unlikely to be doable.
> > > 
> > > How do you hook this exchange interface into Linux to differentiate
> > > which drivers need to use mfns when interacting with the hardware?
> > 
> > In the specific case we have at hands the driver is in Linux userspace
> > and is specially-written for our use case. It is not generic, so we
> > don't have this problem. But your question is valid.
> 
> Oh, so you then have some kind of ioctl interface that does the memory
> exchange and bouncing inside of the kernel on behalf of the user-space
> side I would think?

I am not sure... Xenia might know more than me here.


> > In Linux, the issue is hidden behind drivers/xen/swiotlb-xen.c and
> > xen_arch_need_swiotlb. There are a few options:
> > - force swiotlb bounce for everything on the problematic SoC
> > - edit xen_arch_need_swiotlb to return true for the problematic device
> > - introduce a kernel command line option to specify which device
> >   xen_arch_need_swiotlb should return true for
> 
> Isn't it a bit misleading to use the swiotlb for this purpose?  Won't
> this usage of the swiotlb (to bounce from gfns to mfns) create issues
> if there's any devices that have a DMA physical address limitation and
> also needs to use the swiotlb while being behind the IOMMU?

When I wrote swiotlb, I meant swiotlb-xen (drivers/xen/swiotlb-xen.c).
We have been using it exactly for this kind of address translations so
far. It can also deal with cases where genuine bouncing needs to happen.


> > - introduce an ACPI table with the relevant info
> 
> Hm, best option might be an ACPI table so that Xen can signal to the
> hardware domain whether communication with the device must be done
> using mfns, or if accesses are mediated and hence can be done using
> gfns?

Yeah


> It's a bit cumbersome however to have to resort to an ACPI table just
> for this.  Not sure whether we could expand one of the existing tables
> already under Xen control (STAO?) to contain this information.  It all
> looks a bit ad-hoc.
> 
> I think we need some kind of list of devices that are not behind the
> IOMMU, but I have no idea what URI to use to identify those.  I assume
> the PSP doesn't have a PCI SBDF (as it's not on the PCI bus?).  Maybe
> by ACPI path?

Yes, we have a similar issue with the STAO table in terms of which
identifiers to use. STAO uses: "A list of ACPI strings, where each
string is the full path name in the ACPI namespace of the device"


> Or maybe it's fine to always communicate with those non-translated
> devices using MFNs, and even if we later add some kind of PSP
> mediation (so that both Xen and dom0 can use it), accesses by dom0
> will still be assumed to be using MFNs, and thus need no translation.

I think it is easy to enable/disable GFN/MFN for a device like PSP. We
can communicate to Linux in many ways this change in behavior.
--8323329-1244094392-1746746327=:3879245--


From xen-devel-bounces@lists.xenproject.org Thu May 08 23:28:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 23:28:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979653.1366161 (Exim 4.92)
	(envelope-from )
	id 1uDAfN-0005JW-0o; Thu, 08 May 2025 23:28:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979653.1366161; Thu, 08 May 2025 23: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 1uDAfM-0005JP-U0; Thu, 08 May 2025 23:28:36 +0000
Received: by outflank-mailman (input) for mailman id 979653;
 Thu, 08 May 2025 23:28:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDAfL-0005JJ-Im
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 23:28:35 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 282a252c-2c64-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 01:28:34 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 8CA10A4E2BD;
 Thu,  8 May 2025 23:28:32 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD24FC4CEE7;
 Thu,  8 May 2025 23:28: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" 
X-Inumbo-ID: 282a252c-2c64-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746746912;
	bh=Vg6cN5pfI6Y+lpc133cxHERBv6bpN7iNionBjfwpZfc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=UB2RloDkwM8rimcP5E+U3iCYulg8iOg3KP/Vr5zn3WkdVIK9ahbrV+k8R/3keiTbA
	 gvgbPHFciybDH+IakF2CU0bxSfnF5EPBlzHTfWdlIWl5zlDQUTh3SUVaPbST7cmYbI
	 AQ1YSbJqB9bibnlHLsRGF7F5tP24sXWGfqLiazKXsDDqO8jTDlbU+nXX14W2EraMdN
	 WWNjzRR0ocxRqgJvLr79lYZDRX8Lm4Sz2pd7pBRL8Q5A1ybiDkqrgKbXoXOSzrhqJC
	 c2sVZefjYdBTQ7vfStt8U2Rg2sqQA/PDNe0pQxCyfbKQQb94OyZ5nCLZAINq72AJ3i
	 npE9Mb07KCEEw==
Date: Thu, 8 May 2025 16:28:29 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Jan Beulich , 
    "Ragiadakou, Xenia" , 
    Andrew Cooper , jason.andryuk@amd.com, 
    agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
In-Reply-To: 
Message-ID: 
References:  <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>   
     
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1739614822-1746746911=:3879245"

  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-1739614822-1746746911=:3879245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 8 May 2025, Marek Marczykowski-Górecki wrote:
> On Thu, May 08, 2025 at 11:12:34AM +0200, Roger Pau Monné wrote:
> > On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
> > > On Tue, 6 May 2025, Roger Pau Monné wrote:
> > > > On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
> > > > > On Mon, 5 May 2025, Roger Pau Monné wrote:
> > > > > > On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> > > > > > > On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
> > > > > > > > On Mon, 28 Apr 2025, Jan Beulich wrote:
> > > > > > > > > On 25.04.2025 22:19, Stefano Stabellini wrote:
> > > > > > > > > > From: Xenia Ragiadakou 
> > > > > > > > > > 
> > > > > > > > > > Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> > > > > > > > > > addresses to firmware or co-processors not behind an IOMMU.
> > > > > > > > > 
> > > > > > > > > I definitely don't understand the firmware part: It's subject to the
> > > > > > > > > same transparent P2M translations as the rest of the VM; it's just
> > > > > > > > > another piece of software running there.
> > > > > > > > > 
> > > > > > > > > "Co-processors not behind an IOMMU" is also interesting; a more
> > > > > > > > > concrete scenario might be nice, yet I realize you may be limited in
> > > > > > > > > what you're allowed to say.
> > > > > > > > 
> > > > > > > > Sure. On AMD x86 platforms there is a co-processor called PSP running
> > > > > > > > TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionally to
> > > > > > > > pass addresses to it.  See drivers/tee/amdtee/ and
> > > > > > > > include/linux/psp-tee.h in Linux.
> > > > > > > 
> > > > > > > We had (have?) similar issue with amdgpu (for integrated graphics) - it
> > > > > > > uses PSP for loading its firmware. With PV dom0 there is a workaround as
> > > > > > > dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, but I
> > > > > > > expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's
> > > > > > > the one I used for debugging this issue).
> > > > > > 
> > > > > > That's ugly, and problematic when used in conjunction with AMD-SEV.
> > > > > > 
> > > > > > I wonder if Xen could emulate/mediate some parts of the PSP for dom0
> > > > > > to use, while allowing Xen to be the sole owner of the device.  Having
> > > > > > both Xen and dom0 use it (for different purposes) seems like asking
> > > > > > for trouble.  But I also have no idea how complex the PSP interface
> > > > > > is, neither whether it would be feasible to emulate the
> > > > > > interfaces/registers needed for firmware loading.
> > > > > 
> > > > > Let me take a step back from the PSP for a moment. I am not opposed to a
> > > > > PSP mediator in Xen, but I want to emphasize that the issue is more
> > > > > general and extends well beyond the PSP.
> > > > > 
> > > > > In my years working in embedded systems, I have consistently seen cases
> > > > > where Dom0 needs to communicate with something that does not go through
> > > > > the IOMMU. This could be due to special firmware on a co-processor, a
> > > > > hardware erratum that prevents proper IOMMU usage, or a high-bandwidth
> > > > > device that technically supports the IOMMU but performs poorly unless
> > > > > the IOMMU is disabled. All of these are real-world examples that I have
> > > > > seen personally.
> > > > 
> > > > I wouldn't be surprised, classic PV dom0 avoided those issues because
> > > > it was dealing directly with host addresses (mfns), but that's not the
> > > > case with PVH dom0.
> > > 
> > > Yeah
> > > 
> > > 
> > > > > In my opinion, we definitely need a solution like this patch for Dom0
> > > > > PVH to function correctly in all scenarios.
> > > > 
> > > > I'm not opposed to having such interface available for PVH hardware
> > > > domains.  I find it ugly, but I don't see much other way to deal with
> > > > those kind of "devices".  Xen mediating accesses for each one of them
> > > > is unlikely to be doable.
> > > > 
> > > > How do you hook this exchange interface into Linux to differentiate
> > > > which drivers need to use mfns when interacting with the hardware?
> > > 
> > > In the specific case we have at hands the driver is in Linux userspace
> > > and is specially-written for our use case. It is not generic, so we
> > > don't have this problem. But your question is valid.
> > 
> > Oh, so you then have some kind of ioctl interface that does the memory
> > exchange and bouncing inside of the kernel on behalf of the user-space
> > side I would think?
> > 
> > > In Linux, the issue is hidden behind drivers/xen/swiotlb-xen.c and
> > > xen_arch_need_swiotlb. There are a few options:
> > > - force swiotlb bounce for everything on the problematic SoC
> > > - edit xen_arch_need_swiotlb to return true for the problematic device
> > > - introduce a kernel command line option to specify which device
> > >   xen_arch_need_swiotlb should return true for
> > 
> > Isn't it a bit misleading to use the swiotlb for this purpose?  Won't
> > this usage of the swiotlb (to bounce from gfns to mfns) create issues
> > if there's any devices that have a DMA physical address limitation and
> > also needs to use the swiotlb while being behind the IOMMU?
> > 
> > > - introduce an ACPI table with the relevant info
> > 
> > Hm, best option might be an ACPI table so that Xen can signal to the
> > hardware domain whether communication with the device must be done
> > using mfns, or if accesses are mediated and hence can be done using
> > gfns?
> 
> How does it work on native when some devices are not behind IOMMU? Is it
> signaled via an ACPI table? It feels like it's a similar (although not
> the same) situation here.

The ACPI AMD IVRS table should have this information, but we cannot use
the IVRS table for the guest.

Sometimes this kind of information for platform devices (e.g. GPIO, i2c)
is not reported at all.
--8323329-1739614822-1746746911=:3879245--


From xen-devel-bounces@lists.xenproject.org Thu May 08 23:40:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 23:40:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979667.1366170 (Exim 4.92)
	(envelope-from )
	id 1uDAqX-0007w8-W9; Thu, 08 May 2025 23:40:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979667.1366170; Thu, 08 May 2025 23:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDAqX-0007w1-Te; Thu, 08 May 2025 23:40:09 +0000
Received: by outflank-mailman (input) for mailman id 979667;
 Thu, 08 May 2025 23:40:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDAqW-0007vv-M8
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 23:40:08 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c30d66d6-2c65-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 01:40:03 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 87E745C64F1;
 Thu,  8 May 2025 23:37:44 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24035C4CEE7;
 Thu,  8 May 2025 23:40: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" 
X-Inumbo-ID: c30d66d6-2c65-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746747601;
	bh=mZxVjGpeSSpFLUdqkfS8uq9d2sBJk5V9W2sj3YRjbsQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=nmWQYDDV33llq5/hzdJbYU83g66ERcuU1WGWZtl3UMoOpwgJfPIxI0X9rlrWb89vu
	 TSGgxfYmHMTsU6bqCGUZjiyMznHAQIv+LBW2+HV0XTGltUYIrmwNdcSj8h7Ppo3OJg
	 blOI9eJ8/gcwHb3htCEBfTar5gKxeFo45s17PMrXatMwLRv5t8Au51n5k1rFlnw2n7
	 rypE7YOmIlovxbZ5QX7Yzw9bsXsICkJY31fSkz9LKoAuDhS57uoVb/koSnZR84fo8I
	 /b7RUoVzEMsUPbHd7gMXI8jXYAL0IQkVKJjnupv7QqAs9mUR+5mWEoF66/seuItPEm
	 OXGbPELyIahEQ==
Date: Thu, 8 May 2025 16:39:58 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stewart Hildebrand 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v2 5/6] xen/arm: exclude xen,reg from domU extended
 regions
In-Reply-To: <20250508132040.532898-6-stewart.hildebrand@amd.com>
Message-ID: 
References: <20250508132040.532898-1-stewart.hildebrand@amd.com> <20250508132040.532898-6-stewart.hildebrand@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 8 May 2025, Stewart Hildebrand wrote:
> When a device is passed through to a dom0less domU, the xen,reg ranges
> may overlap with the extended regions. Remove xen,reg from extended
> regions.
> 
> Signed-off-by: Stewart Hildebrand 

Reviewed-by: Stefano Stabellini 


> ---
> Not sure if we need a Fixes: tag, but if we do:
> Fixes: 2a2447757b3c ("xen/arm: implement domU extended regions")
> 
> v1->v2:
> * adjust commit message to not mention xen,reg-cacheable
> * don't call rangeset_destroy() in construct_dom0()
> * rebase
> 
> I investigated an alternate approach of parsing the partial device tree
> again to scan for xen,reg properties, but it resulted in quite a lot of
> code duplication. Adding a rangeset pointer to "struct kernel_info" has
> a much smaller diffstat, and then we avoid the need to parse the partial
> device tree a second time.
> 
> I discovered this issue when booting a dom0less domU with a device
> passed through. Partial device tree excerpt:
> 
>     passthrough {
>         ...  ...
> 
>         axi_uart16550_0: serial@a0001000 {
>             clocks = <&uart_fixed_clk>;
>             compatible = "ns16550a";
>             interrupt-parent = <&gic>;
>             interrupts = <0 89 4>;
>             reg = <0x0 0xa0001000 0x0 0x1000>;
>             reg-shift = <2>;
> 
>             xen,reg = <0x0 0xa0001000 0x00 0x1000 0x0 0xa0001000>;
>             xen,path = "/amba_pl@0/serial@a0000000";
>             xen,force-assign-without-iommu;
>         };
>     };
> 
> The domU was assigned an extended region overlapping with MMIO of the
> passed through device:
> 
> (XEN) d1: extended region 0: 0xa0000000->0x100000000
> (XEN) d1: extended region 1: 0x200000000->0xf000000000
> 
> The domU panicked when attempting to initialize the device:
> 
> [    3.490068] a0001000.serial: ttyS0 at MMIO 0xa0001000 (irq = 15, base_baud = 6249375) is a 16550A
> [    3.498843] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
> [    3.498853] Mem abort info:
> [    3.498855]   ESR = 0x0000000096000044
> [    3.498859]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    3.498864]   SET = 0, FnV = 0
> [    3.498867]   EA = 0, S1PTW = 0
> [    3.498870]   FSC = 0x04: level 0 translation fault
> [    3.498874] Data abort info:
> [    3.498876]   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
> [    3.498879]   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
> [    3.498884]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [    3.498888] [0000000000000010] user address but active_mm is swapper
> [    3.498894] Internal error: Oops: 0000000096000044 [#1] SMP
> [    3.498899] Modules linked in:
> [    3.498908] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.10-stew #1
> [    3.498917] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [    3.498924] pc : mem_serial_out+0x18/0x20
> [    3.498936] lr : serial8250_do_set_mctrl+0x6c/0xc0
> [    3.498943] sp : ffff800081bab6d0
> [    3.498946] x29: ffff800081bab6d0 x28: ffff8000815e0dc8 x27: ffff000001c29c60
> [    3.498957] x26: 0000000000000000 x25: ffff00000347b900 x24: ffff000005504c00
> [    3.498968] x23: ffff00000347b800 x22: 0000000000000000 x21: ffff800081b69d78
> [    3.498978] x20: ffff800081b69d78 x19: 0000000000000000 x18: ffffffffffffffff
> [    3.498989] x17: 3d20647561625f65 x16: 736162202c353120 x15: 3d20717269282030
> [    3.498999] x14: 3030313030306178 x13: ffff800081a21ff0 x12: 00000000000007fe
> [    3.499010] x11: 00000000000002aa x10: ffff800081a4dff0 x9 : ffff800081a21ff0
> [    3.499020] x8 : 00000000fffff7ff x7 : ffff800081a4dff0 x6 : 0000000000000008
> [    3.499030] x5 : 0000000000000000 x4 : ffff800080797584 x3 : 0000000000000002
> [    3.499040] x2 : 0000000000000000 x1 : 0000000000000010 x0 : 0000000000000000
> [    3.499050] Call trace:
> [    3.499053]  mem_serial_out+0x18/0x20
> [    3.499059]  serial8250_set_mctrl+0x34/0x40
> [    3.499065]  serial_core_register_port+0x534/0x7dc
> [    3.499075]  serial_ctrl_register_port+0x10/0x1c
> [    3.499084]  uart_add_one_port+0x10/0x1c
> [    3.499092]  serial8250_register_8250_port+0x308/0x4c0
> [    3.499102]  of_platform_serial_probe+0x2c4/0x48c
> [    3.499110]  platform_probe+0x68/0xdc
> [    3.499120]  really_probe+0xbc/0x298
> [    3.499128]  __driver_probe_device+0x78/0x12c
> [    3.499135]  driver_probe_device+0xdc/0x160
> [    3.499142]  __driver_attach+0x94/0x19c
> [    3.499149]  bus_for_each_dev+0x74/0xd0
> [    3.499155]  driver_attach+0x24/0x30
> [    3.499162]  bus_add_driver+0xe4/0x208
> [    3.499168]  driver_register+0x60/0x128
> [    3.499176]  __platform_driver_register+0x24/0x30
> [    3.499184]  of_platform_serial_driver_init+0x1c/0x28
> [    3.499192]  do_one_initcall+0x6c/0x1b0
> [    3.499199]  kernel_init_freeable+0x178/0x258
> [    3.499209]  kernel_init+0x20/0x1d0
> [    3.499218]  ret_from_fork+0x10/0x20
> [    3.499228] Code: f9400800 1ac32021 8b21c001 d50332bf (39000022)
> [    3.499233] ---[ end trace 0000000000000000 ]---
> [    3.499237] note: swapper/0[1] exited with irqs disabled
> [    3.499247] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [    3.499251] SMP: stopping secondary CPUs
> [    3.499284] Kernel Offset: disabled
> [    3.499286] CPU features: 0x00,00000080,00200000,0200420b
> [    3.499292] Memory Limit: none
> [    3.792412] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> ---
>  xen/arch/arm/domain_build.c             |  7 +++++++
>  xen/common/device-tree/dom0less-build.c | 19 ++++++++++++++++++-
>  xen/include/xen/fdt-kernel.h            |  1 +
>  3 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 05a77a4f92c6..b189a7cfae9f 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -973,6 +973,13 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>      if ( res )
>          goto out;
>  
> +    if ( kinfo->xen_reg_assigned )
> +    {
> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
> +        if ( res )
> +            goto out;
> +    }
> +
>      res = rangeset_report_ranges(mem_holes, 0,
>                                   PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
>                                   add_ext_regions, ext_regions);
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 4aa36c8ef33f..2c56f13771ab 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -146,6 +146,14 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>      int res;
>      paddr_t mstart, size, gstart;
>  
> +    if ( !kinfo->xen_reg_assigned )
> +    {
> +        kinfo->xen_reg_assigned = rangeset_new(NULL, NULL, 0);
> +
> +        if ( !kinfo->xen_reg_assigned )
> +            return -ENOMEM;
> +    }
> +
>      /* xen,reg specifies where to map the MMIO region */
>      cell = (const __be32 *)xen_reg->data;
>      len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
> @@ -187,6 +195,11 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>                     mstart, gstart);
>              return -EFAULT;
>          }
> +
> +        res = rangeset_add_range(kinfo->xen_reg_assigned, PFN_DOWN(gstart),
> +                                 PFN_DOWN(gstart + size - 1));
> +        if ( res )
> +            return res;
>      }
>  
>      /*
> @@ -814,7 +827,11 @@ static int __init construct_domU(struct domain *d,
>  
>      domain_vcpu_affinity(d, node);
>  
> -    return alloc_xenstore_params(&kinfo);
> +    rc = alloc_xenstore_params(&kinfo);
> +
> +    rangeset_destroy(kinfo.xen_reg_assigned);
> +
> +    return rc;
>  }
>  
>  void __init create_domUs(void)
> diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
> index 7a6cd67c22f1..1939c3ebf7dc 100644
> --- a/xen/include/xen/fdt-kernel.h
> +++ b/xen/include/xen/fdt-kernel.h
> @@ -24,6 +24,7 @@ struct kernel_info {
>  #ifdef CONFIG_STATIC_SHM
>      struct shared_meminfo shm_mem;
>  #endif
> +    struct rangeset *xen_reg_assigned;
>  
>      /* kernel entry point */
>      paddr_t entry;
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Thu May 08 23:42:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 23:42:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979677.1366181 (Exim 4.92)
	(envelope-from )
	id 1uDAsy-0000Be-C9; Thu, 08 May 2025 23:42:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979677.1366181; Thu, 08 May 2025 23: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 1uDAsy-0000BX-9G; Thu, 08 May 2025 23:42:40 +0000
Received: by outflank-mailman (input) for mailman id 979677;
 Thu, 08 May 2025 23:42:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDAsx-0000BR-3O
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 23:42:39 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1ec7a9b7-2c66-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 01:42:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id BDEF05C6517;
 Thu,  8 May 2025 23:40:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AEEE4C4CEE7;
 Thu,  8 May 2025 23:42: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" 
X-Inumbo-ID: 1ec7a9b7-2c66-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746747755;
	bh=vb4rarApPBdMsl51Tbw/q6cRzN6NxmQK8XthNMMLJag=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=LIbI92Ow5GjRRHL7n1i0b6V4ftkNZGRgLxsb+2htDd4IyQuU3jINUQuKQ4DPRcZhm
	 ibFlwddPknw6a6EGsOGD38qUFRDVEaG6fgDj0mF4uyGmb65SCcvqNkxhNxp9VBouP9
	 jzy/TsC18CBpeGVi42WiLtCPFGYfLmqDTGyqpUKHwl3L0zgxsOpDQVNPNYOT8nc8Hf
	 W0VfHQ+VkpqQfOahlyDoffTU0b2VjOUb7q3w4YWAgA4tC5Q1UxYRvI/jJMg+vHYPbk
	 mMk73q3GiBMMXeYL6y3gF3S9K9Jw9CP0tg43zpSmD9bxoC38UNy0EeINO89n6gor2r
	 DD9i1XnxFpdkw==
Date: Thu, 8 May 2025 16:42:33 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stewart Hildebrand 
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 
Subject: Re: [PATCH v2 4/6] rangeset: introduce rangeset_subtract
In-Reply-To: <20250508132040.532898-5-stewart.hildebrand@amd.com>
Message-ID: 
References: <20250508132040.532898-1-stewart.hildebrand@amd.com> <20250508132040.532898-5-stewart.hildebrand@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 8 May 2025, Stewart Hildebrand wrote:
> Introduce rangeset_subtract() to remove regions in r2 from r1.
> 
> Signed-off-by: Stewart Hildebrand 

Reviewed-by: Stefano Stabellini 

> ---
> v1->v2:
> * no change
> ---
>  xen/common/rangeset.c      | 12 ++++++++++++
>  xen/include/xen/rangeset.h |  3 +++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
> index e75871039087..b9e8912fb1c3 100644
> --- a/xen/common/rangeset.c
> +++ b/xen/common/rangeset.c
> @@ -397,6 +397,18 @@ int rangeset_merge(struct rangeset *r1, struct rangeset *r2)
>      return rangeset_report_ranges(r2, 0, ~0UL, merge, r1);
>  }
>  
> +static int cf_check subtract(unsigned long s, unsigned long e, void *data)
> +{
> +    struct rangeset *r = data;
> +
> +    return rangeset_remove_range(r, s, e);
> +}
> +
> +int rangeset_subtract(struct rangeset *r1, struct rangeset *r2)
> +{
> +    return rangeset_report_ranges(r2, 0, ~0UL, subtract, r1);
> +}
> +
>  int rangeset_add_singleton(
>      struct rangeset *r, unsigned long s)
>  {
> diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
> index 96c918082501..817505badf6f 100644
> --- a/xen/include/xen/rangeset.h
> +++ b/xen/include/xen/rangeset.h
> @@ -85,6 +85,9 @@ int rangeset_consume_ranges(struct rangeset *r,
>  /* Merge rangeset r2 into rangeset r1. */
>  int __must_check rangeset_merge(struct rangeset *r1, struct rangeset *r2);
>  
> +/* Subtract rangeset r2 from rangeset r1. */
> +int __must_check rangeset_subtract(struct rangeset *r1, struct rangeset *r2);
> +
>  /* Add/remove/query a single number. */
>  int __must_check rangeset_add_singleton(
>      struct rangeset *r, unsigned long s);
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Thu May 08 23:47:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 23:47:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979689.1366190 (Exim 4.92)
	(envelope-from )
	id 1uDAxC-0000kp-Rk; Thu, 08 May 2025 23:47:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979689.1366190; Thu, 08 May 2025 23:47: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 1uDAxC-0000ki-P4; Thu, 08 May 2025 23:47:02 +0000
Received: by outflank-mailman (input) for mailman id 979689;
 Thu, 08 May 2025 23:47:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDAxB-0000kc-JT
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 23:47:01 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b621b356-2c66-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 01:46:51 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 4ACEB5C6505;
 Thu,  8 May 2025 23:44:32 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA759C4CEE7;
 Thu,  8 May 2025 23:46: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" 
X-Inumbo-ID: b621b356-2c66-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746748009;
	bh=C8aqJuHxwhg7FIyDnFyEGsRNUZFnHznz67AsY9oG4vw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HDVqaqL5mFZQCpyL16IffFsqEZ3sx6AgckS5d2AZ0/KfAGDDh2W70qln9289AJo5Z
	 SaOJvHlhrt1O3aatlHbc+kO+b30OdquqY0NzSIzogcKmdJd12Dz9DEnU3hfFHEg9FA
	 sFs91P/KWRiQj3Tk19Vvmm8HuxtkYd/3ihKSM25hWsoBIqUW1t9M9q+JLEaHP6fzko
	 gAkc2YjlTSzbbT8FuJNwFnV8sQdQ2CR1Or7Lzz//VnPeSkJvnu/n54g4tLRJ6EIyra
	 bzMQnHTRtR4AcacR89oa3jQegWIQKO/PldrH6ZPm9JCrrD5FBR37gh+YrK00CP1Xe7
	 J9c5XYaxqyqag==
Date: Thu, 8 May 2025 16:46:46 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Victor Lira 
cc: xen-devel@lists.xenproject.org, 
    Federico Serafini , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Nicola Vetrini , 
    Bertrand Marquis 
Subject: Re: [PATCH v1 2/2] automation/eclair: tag Rule 13.2 as clean
In-Reply-To: 
Message-ID: 
References: <77f9c4cabe607ce4024013c604bc790fb629d322.1746657135.git.victorm.lira@amd.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2121932376-1746748009=:3879245"

  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-2121932376-1746748009=:3879245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 7 May 2025, victorm.lira@amd.com wrote:
> From: Federico Serafini 
> 
> Update ECLAIR configuration to consider Rule 13.2 as clean so as to
> avoid regressions.
> 
> Signed-off-by: Federico Serafini 
> Signed-off-by: Victor Lira 

Assuming the other patch is accepted:

Acked-by: Stefano Stabellini 

> ---
> Cc: Andrew Cooper 
> Cc: Anthony PERARD 
> Cc: Michal Orzel 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Roger Pau Monné 
> Cc: Stefano Stabellini 
> Cc: Nicola Vetrini 
> Cc: Federico Serafini 
> Cc: Bertrand Marquis 
> ---
>  automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
> index 1d078d8905..c958d3ed59 100644
> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> @@ -63,6 +63,7 @@ MC3A2.R11.6||
>  MC3A2.R11.7||
>  MC3A2.R11.9||
>  MC3A2.R12.5||
> +MC3A2.R13.2||
>  MC3A2.R13.6||
>  MC3A2.R14.1||
>  MC3A2.R14.3||
> --
> 2.47.0
> 
--8323329-2121932376-1746748009=:3879245--


From xen-devel-bounces@lists.xenproject.org Thu May 08 23:59:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 08 May 2025 23:59:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979709.1366220 (Exim 4.92)
	(envelope-from )
	id 1uDB9d-0002pi-8d; Thu, 08 May 2025 23:59:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979709.1366220; Thu, 08 May 2025 23: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 1uDB9d-0002pb-5m; Thu, 08 May 2025 23:59:53 +0000
Received: by outflank-mailman (input) for mailman id 979709;
 Thu, 08 May 2025 23:59:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDB9b-0002pV-Nv
 for xen-devel@lists.xenproject.org; Thu, 08 May 2025 23:59:51 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8651526c-2c68-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 01:59:49 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 075075C649F;
 Thu,  8 May 2025 23:57:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89A45C4CEE7;
 Thu,  8 May 2025 23:59: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" 
X-Inumbo-ID: 8651526c-2c68-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746748787;
	bh=Aknd8eRQpMp0mMrUvf/eC7cDHLqD5XkNFJEYp8NtRVQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=BFdudM18c3ogVxYD3PhVTCmmyNv5bo3mWMR1xVXdsY8WfqIAslKsmJr0t/Bm15gsY
	 bpXhCIfHv8X9UtV1vUHBmhfp/KD/M7/pbVW2jBv16JXVwbbs/fqUhlPS15Q6AqAzD/
	 oCCN9PDX1LoTYsfkUmgnnIpP6gQfNnOCPhUixX0Rii2ubdix4rr44wmwrDpSAV7eDD
	 t9nqeoFi7+okJCqbG6dX1UgEUScnjLwSgM3FF0VB6vE/NNe7Ev1u47L8LZ0Bz0aiIh
	 R6uGsuJg55JkQxLe4o2etCnfQBHHjjLZcGbCgGLaZ9GmHzfAKqLLsaDUVvL6+kaAOM
	 gV3SJKbjciB+Q==
Date: Thu, 8 May 2025 16:59:45 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Victor Lira 
cc: xen-devel@lists.xenproject.org, 
    Nicola Vetrini , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Federico Serafini , 
    Bertrand Marquis 
Subject: Re: [PATCH v1 1/2] x86: x86_emulate: address violation of MISRA C
 Rule 13.2
In-Reply-To: <77f9c4cabe607ce4024013c604bc790fb629d322.1746657135.git.victorm.lira@amd.com>
Message-ID: 
References: <77f9c4cabe607ce4024013c604bc790fb629d322.1746657135.git.victorm.lira@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-823193177-1746748787=:3879245"

  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-823193177-1746748787=:3879245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 7 May 2025, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
> 
> Rule 13.2 states: "The value of an expression and its persistent
> side effects shall be the same under all permitted evaluation orders".
> 
> The full expansion of macro "commit_far_branch" contains an assignment to
> variable "rc", which is also assigned to the result of the GNU statement
> expression which "commit_far_branch" expands to.
> 
> To avoid any dependence on the order of evaluation, the latter assignment
> is moved inside the macro.
> 
> Signed-off-by: Nicola Vetrini 
> Signed-off-by: Victor Lira 

Reviewed-by: Stefano Stabellini 


> ---
> Cc: Andrew Cooper 
> Cc: Anthony PERARD 
> Cc: Michal Orzel 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Roger Pau Monné 
> Cc: Stefano Stabellini 
> Cc: Nicola Vetrini 
> Cc: Federico Serafini 
> Cc: Bertrand Marquis 
> ---
>  xen/arch/x86/x86_emulate/x86_emulate.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
> index 8e14ebb35b..7108fe7b30 100644
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -337,7 +337,7 @@ do {                                                                    \
>      validate_far_branch(cs, newip);                                     \
>      _regs.r(ip) = (newip);                                              \
>      singlestep = _regs.eflags & X86_EFLAGS_TF;                          \
> -    ops->write_segment(x86_seg_cs, cs, ctxt);                           \
> +    rc = ops->write_segment(x86_seg_cs, cs, ctxt);                      \
>  })
> 
>  int x86emul_get_fpu(
> @@ -2382,7 +2382,7 @@ x86_emulate(
>               (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + src.val),
>                                &src.val, op_bytes, ctxt, ops)) ||
>               (rc = load_seg(x86_seg_cs, src.val, 1, &cs, ctxt, ops)) ||
> -             (rc = commit_far_branch(&cs, dst.val)) )
> +             commit_far_branch(&cs, dst.val) )
>              goto done;
>          break;
> 
> @@ -2438,7 +2438,7 @@ x86_emulate(
>          _regs.eflags &= mask;
>          _regs.eflags |= (eflags & ~mask) | X86_EFLAGS_MBS;
>          if ( (rc = load_seg(x86_seg_cs, sel, 1, &cs, ctxt, ops)) ||
> -             (rc = commit_far_branch(&cs, (uint32_t)eip)) )
> +             commit_far_branch(&cs, (uint32_t)eip) )
>              goto done;
>          break;
>      }
> @@ -2557,7 +2557,7 @@ x86_emulate(
>          ASSERT(!mode_64bit());
>      far_jmp:
>          if ( (rc = load_seg(x86_seg_cs, imm2, 0, &cs, ctxt, ops)) ||
> -             (rc = commit_far_branch(&cs, imm1)) )
> +             commit_far_branch(&cs, imm1) )
>              goto done;
>          break;
> 
> --
> 2.47.0
> 
--8323329-823193177-1746748787=:3879245--


From xen-devel-bounces@lists.xenproject.org Fri May 09 03:14:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 03:14:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979741.1366251 (Exim 4.92)
	(envelope-from )
	id 1uDEC1-0000P7-Il; Fri, 09 May 2025 03:14:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979741.1366251; Fri, 09 May 2025 03: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 1uDEC1-0000Oz-EE; Fri, 09 May 2025 03:14:33 +0000
Received: by outflank-mailman (input) for mailman id 979741;
 Fri, 09 May 2025 03:14:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDEBz-0000Os-RB
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 03:14:31 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2412::61b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b626edf1-2c83-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 05:14:27 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH2PR12MB9519.namprd12.prod.outlook.com (2603:10b6:610:27c::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.23; Fri, 9 May
 2025 03:14:18 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Fri, 9 May 2025
 03: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" 
X-Inumbo-ID: b626edf1-2c83-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HIBuRKbNgnchziu9arHKtbMBcvRg+LSHv2bHXMjLiRvDLc2AncvaAy8OhvCVuDgdA4bgyG7L2UjIbEeq5wtCQb6q3E2xe0mMX+TMm7raS39CbyYpMoDpwh7Qjt9fiMbYq0dnHTfFnxOOH2G3/eTFGx5ZXHS4YSPgfGlG908kowhLZzPm+BsLIIBAXdFLd0Xg8Lcfdy/h2s+KNSBlNhF7+FsPNT32BLJF7d3dyB+eF2oBrLVkGeAKYI22GgaaE9SYDJguKvR2G/Fz5hIB/pYiDs2RASsww03w+KDWKmUcKN//k9JWg50UnqsQbzAf0hC9HbKMSDFCxjM3onJmtfy6sA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2r/yog852ogEyjKEGCoySg2Zspyw8WgHf0Xvi/lWea8=;
 b=QnrbKuLsicYycuCebpWaGNPmZjohV2uoUwLqRk09ItK49udruBebKvh08oGMMXc2KNjjDQDQVgaR9aREIllkMqXeJQBjpETEdhd7nr/bxTnFFAntjvQWgU28oxOgqLpgrl81qXJdfqOJVarJ3r0xZAw56+bMQ9knllcx/vIxRxuqBvGP03jUNPdV6BVe/Eckld8muHPhSDvi/muSmNT1iuoOoBfYRu6NMPMqKTGUlhe3936wNlck9Nvzi4JvdlyRDw71PpNqKfaVrOb67iOVAp930cUBE8Bf8xhiHpxOoIP3MsI3HZtHQ2y/nTMbThYkO1v1Q+dmi5UXNgSVyt8g/g==
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=2r/yog852ogEyjKEGCoySg2Zspyw8WgHf0Xvi/lWea8=;
 b=hvMeXXb9wTNMmBkUhyP6u0cScTLLU4PusWQPLO++qOuf5zSOyCL+wGRB6Ed6ZOSao8mMu/uLAvBTvmjpieFAXYVDwjDn3HDMd61xumoK3UW9Vo8uS1YxnZgywaJqSGocBKofTnP7dx8Y+p3cqM4IJzWZG+cNLHFJ4MUeIFQ7WxY=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 11/15] xen/x86: implement EPP support for the amd-cppc
 driver in active mode
Thread-Topic: [PATCH v4 11/15] xen/x86: implement EPP support for the amd-cppc
 driver in active mode
Thread-Index: AQHbrRCuGuHP44zrR0KG5VY9cm/pkLO68EcAgA7Q8sA=
Date: Fri, 9 May 2025 03:14:17 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-12-Penny.Zheng@amd.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_ActionId=e4682b6a-0079-47aa-899c-5b67ef962cba;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_ContentBits=0;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_Enabled=true;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_Method=Privileged;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_Name=Published
 AMD
 Product;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_SetDate=2025-05-09T03:14:07Z;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|CH2PR12MB9519:EE_
x-ms-office365-filtering-correlation-id: 3720e022-3ba4-4d8d-e2b5-08dd8ea795b2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?YUhxOFdMSmM5YzJPV09oQ1dmTWdEUXV4TGtWakh3dUdqSGp5UW04cFVhaWFT?=
 =?utf-8?B?R0VubUZLdU11WHk0eWhydVg5a0xDMGFoNFdkMTdFMGtHUEJ3endId1J5VEM0?=
 =?utf-8?B?Z2g0VVZqSnhOU0lBaEJxc21GTHI3NGZMSENCT0RWNGhLaGxyNzJWa1ZpMEdx?=
 =?utf-8?B?NStvQk12N1BFREJXSXdZZ3ZSQlgvZnQrUFV6UGtRTDU4SkFUb3VnOFQ2OXk1?=
 =?utf-8?B?NkhPN2RjYmhTSXN1L3NCakh1WTNKcmVNVW5qdG15V3hwY1BZSDNzVUs3bnIx?=
 =?utf-8?B?dFRpdFd4blp5eUJhRjAreW5oR3BFOXdIUUhUUnZ6a0lXMWZEVHpKYlIwWEdM?=
 =?utf-8?B?b0pReFltN1hhbTJ2ZUZ2VGt3akROYTdXZm9nQVhBNHBXZzhYLzdCS3FleVgy?=
 =?utf-8?B?a2JScVRpNEl5UnVFdFVaQTFqb1o2QkFmVTVRdXg0THIydmsxRUdobFpTTzAx?=
 =?utf-8?B?MnB3UFZHZGRKTjdXUUFTaWZ1WFpNWTJCSnhXbFQvRHc3aCtYcXR6TGJCVS95?=
 =?utf-8?B?TmczeThIKzkxVmtuMkJWd0tyVUVYQktNZE9HN2E3dkw0WkExM09KMTJLNjU0?=
 =?utf-8?B?ZTZ6ZFp1MGJ1dmJ3QlFrWHlSNUlWTmdPODBYY3FPeFNLUkt6T2FMSmIrb0Jp?=
 =?utf-8?B?cmVFOGhwTm5seVBiM0t6M0dNN1kvalgwN1RtRytjRjl0RVRMMVk5SWhGbGRl?=
 =?utf-8?B?VExBRDFLVzBrMEc1WDVRN0s1RFFFbGV3UjNTbjdwVElmcHdSNytuZkkxS2lh?=
 =?utf-8?B?cmFiVHhxK2JrcENzYmRZRGRZc3lUS3gvZnVjM1VLN1N1NHN2dWFxQVpSYkFW?=
 =?utf-8?B?THZueGZjb2lHWlhRR1hBTWZOZHZoSkRKZkkxNE9WVGpWNmV2OFlpcEZsK3U5?=
 =?utf-8?B?WldTd3FTb3lkU2NDLzk1QmcyNHhrYmNJNnFqckxTNlpMSlZSRnAvdFl1Y0hB?=
 =?utf-8?B?WEhDUkIxR0oyWCtWQzFkdXJXZFpZeXl1OXhLUnZ3VytuTmNMeTd0WTY3Tm9i?=
 =?utf-8?B?K3k5OG5na3Q2dEdwMkdEUTRHTmpxWWpnUWF1amFpMk1hYno5MlhzUjMvLy8y?=
 =?utf-8?B?R1ZBUUhhcThhWS9YRFJIc1NOVi9Zdm9PcHJhSkZ2QlBoUStvdzRNN3ZyZzRt?=
 =?utf-8?B?Ymw0UjJmUDI3eWM2TGJZdUNLd2VKT2dqNjFYZXlFelRUZjB5eHBmV01XazdZ?=
 =?utf-8?B?ZTZqWUN4bHJYUWorWTl5d0lEMkRrTTZRUUVKYTFXYzJtcUJrb2doVHdmWVJt?=
 =?utf-8?B?MUx1czBXM0N4ek9tVmJLckQzdFI2L0lHbHJicHhkVWY1QkNtSytCclhWekdx?=
 =?utf-8?B?KzhBN2tFcXpUbVNNTTZpZFlIdHh3eDFaU091dmlWbnNCQktOUlRJdjJCeWpC?=
 =?utf-8?B?WTNQR01vcVkxZnNuNzBmcnFuMXRsaXZ3UEoramoxVFB3RU5RTktuZDRVR0Ur?=
 =?utf-8?B?eEhJT0RteU1BNFRhMGxTWGo2MlNOVXNoZSs5a3U0R1dKa1gyRk5yc2FyVmp2?=
 =?utf-8?B?ZUh0clRXMENwcE1ZODlkeHFxQWR6cHZUbGZuMnpBNFl4bVRwQmJuL2xBUkht?=
 =?utf-8?B?UmJYZ05ibFd1VUo4b2RrS0NjN0RtNHFWaWk5N2ZWNXhkcDhhZHBxL1hnNm9S?=
 =?utf-8?B?Q2dudDIxMStieXp3SDU5USt3WUdBMWw3cVlzVkpORDFHTlVkMUNsTFc5dnBZ?=
 =?utf-8?B?S05rRTR1WnU3OXBMNThKVGxMVFJ6a1hqMUJvUHdjOXNWZ1kvd1kyVDhqVGFB?=
 =?utf-8?B?Zkt1U0RHZE1OQ0E2Y3pRQ1NDaFZFcDhWcUV6YkhkVitXNkdrYVVrazEvNGZm?=
 =?utf-8?B?M2UwWStwUGZDVTJ3NTV3MTArZDhYUDJaam1mekZWMVRDemI4ZSszRFVRUnRO?=
 =?utf-8?B?RnRZYkQrcGdKMDNiQmpHbTk1S0dLb0xmU3RXVnpaNjRQNFRNUEN3RkFSS2xQ?=
 =?utf-8?B?ZzZTZEthUHNmSENjMU05cFJPbDlWdFhIaHhlVllZcGxPa3NMOWRLTWl4ekFq?=
 =?utf-8?Q?atA8Lv4wITs75jHAUIyxrEzCXosgAE=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SUpTbFJxZ3dQSSt3bjZrV1hFWlBHL2RMUXZ3a2c4blhML2hzd1lyc3ZiTzli?=
 =?utf-8?B?YnZXMHY3NFdLeDM2aTA2REk0eDZXZTZPZkV4TGg1Y05jYWx3NnpiL3JGZnds?=
 =?utf-8?B?d3NRQXp6WGFnZ3AxbjBmOXRtanZNSHNaMlI5aUJFWG5YeThOV3ZNY0F1NEx4?=
 =?utf-8?B?UHZqUHZDN2NpeVdJbXNkWXhYdko3Y0lqd3REenhOblEyMFUrTkJZQUdEbHU4?=
 =?utf-8?B?dk1PRFAycmRQTUg2TnlIdVBMbXBSOUN3R1o1OE9LUE1hMC8rb21Td1VJTUtK?=
 =?utf-8?B?clhEd2Y0RFpZTDNEY2xvTkpONlpoa2xRU3hQalRzVzFnbGV2aGUwd3Nwcnpm?=
 =?utf-8?B?Y2MyajhPL2RjSHk1RkNOMXBZNWpaQURMaXBVWTNuUWR1LzFqcnQ3ek40MGVS?=
 =?utf-8?B?eTJacGZ4c2ZsQWgyUGNHR0ZHWWsxMW1jbjd1QVhUa0g0Rks4Z0NxSWxiL1Nj?=
 =?utf-8?B?UEQ3MUJNZmRXLzhhbWgyWDhHRnBJYlZvelZOSWhYQzJCS2RMUkZOUGYzaTJC?=
 =?utf-8?B?Qko2dmxramVoQ3kzalIrcXQrN25vbG55TnpTclAzTkx1OTJYZGRQRHpsMTEr?=
 =?utf-8?B?MjUvSWlCOHJmY2JvbHBJL1p3a0lpc0FKbk51czZFNjN0aWl6Nk4vVEt4eENT?=
 =?utf-8?B?aWY4dGVmMi9yVVpjc3ZzR215dTh3QkxVR1gwNGxkRWk0VjRVenV0NkFFcHI2?=
 =?utf-8?B?ZUgvNmhtWkFYWitBVnhnb2k5WVJRd3FLelU2Q29SOXBsYldWT3VqZ2VnOUdG?=
 =?utf-8?B?UWR3RkQrd1YzME1RZ1AvbFA4dWJiaElRUXJzTTlsZ3MyQ2twTGdaWlVNUUd2?=
 =?utf-8?B?RVRlMDE2WHkxWGpGQWdMd1FMVTI4cGNFZHFKcU10WmNHTXUvRlNVUS9RNEN5?=
 =?utf-8?B?NDg2elVzd2VJWWVLbEkwSFNDU2N3WWdHTnR0TW9nenM5TGw5clBuMXgxdFRG?=
 =?utf-8?B?cTF6d01lblViSGpoWEoyNW5SNE50aTBXVVBUTHF1ZzhsbDk5SHFhZ1dnRVZz?=
 =?utf-8?B?allYVHI3RFAyNm0xQlRIR1NFdHRnNVdxdEYvRGQzYjNvNC9VTzBreUppbkE1?=
 =?utf-8?B?dHRKbVlodDI3THlUdjdUTnZKZ3hyV2sxUmY3eWhtaEtFQ3Z4MjNqNW9JYzlB?=
 =?utf-8?B?NE5ReGtPUWoyV2ZwYnVWcnN0SVZSeXlwQVdNTHN5Y1JZV2JqZzBORHJIbnJh?=
 =?utf-8?B?YnVRcnhjM1k0NmQ5cTdyNFYyNmNlS29GNkx0TWl5TEkyWHozOElCRGVxM2M0?=
 =?utf-8?B?OG1vSXF6WWxGS3QyajlpRzdOVC8wMTV4bTRJNUUrRFlXbFVZcDZGMHY3UGl1?=
 =?utf-8?B?a3UvK29temYyMGNVbzIxemZXQTZHL01ZakVtdGZtL3F0RktQMXJrdEl4a0F5?=
 =?utf-8?B?T0NkKzZnelZMNUdRMjhjVEJZMFRBaFlBZlZRdFR6STl5Q0tWSzR4R2s0cTRD?=
 =?utf-8?B?ZFVITDFZckxHNCtiUnhYK1V1Zk0vdDFieXZDUG5ZSm5xbExSWHlJbzFVbzN1?=
 =?utf-8?B?QTZHSmRkVUVwRG9sdFVwMklzZStHaDlLV09VRTQvRnJ0bnZOUGljZmpqRGQ1?=
 =?utf-8?B?YW1NRjFCT0FUMG1BL2d5WFdPSExib2hjMFYwQkxHTi82WVNqNEJHN0h4KzAr?=
 =?utf-8?B?N2tKNHRmeXlKakdUeHNFYWJ6YXk5Nm5nM3luTGZHUUdyNWhPYlR0N0wzTHJ4?=
 =?utf-8?B?R253a1o5TTNPbFZuaWNERGdyZTQyWWtKWTVHSElweWxXTkovNU92ZWFycWlL?=
 =?utf-8?B?VWpnZVBDa1FRNkY2azBGbWc4V1liQVoyMHRPbmhoK1pXektYUDdFN0JvYWNK?=
 =?utf-8?B?RDhsaUNSbkR5dkNMWFJpOFpnSU1RTUQxVExsMCt3NE4yUzJvNmliRFpHV0dD?=
 =?utf-8?B?L3UzWXVROWxCblNZU0pUUHh4VVJYSU1KRytzMG1kaVozL0JxOVpwczNUV09O?=
 =?utf-8?B?NlJRMlZ1bTNyYVgxVWlqTVI5Uk5VVFJ6RGNTazVtUHdvTU4wNERUODlpU2o0?=
 =?utf-8?B?MVZkV3A2dHFXRWkrWjBlRjJyYzZTM3VRb0dleTRjUXlvWFN6VHQ4SUM2cDNm?=
 =?utf-8?B?SFZLdWlDWlQwMlBpSnJPbEhKMTBlYlQweHZnODU1K2MvYnRYSmdNcmdybkJT?=
 =?utf-8?Q?rJvw=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3720e022-3ba4-4d8d-e2b5-08dd8ea795b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2025 03:14:17.8396
 (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: ImHnWjeVXR/NE3l3BhH2jlXorV4JU0VEezG+/F6ds+npWi7DB+etyikzsEWbg+aOsmVaqvgafG1Oxlikgurf+A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB9519

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmls
IDMwLCAyMDI1IDEyOjM5IEFNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5j
b20+DQo+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXIN
Cj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRCA8YW50aG9ueS5w
ZXJhcmRAdmF0ZXMudGVjaD47DQo+IE9yemVsLCBNaWNoYWwgPE1pY2hhbC5PcnplbEBhbWQuY29t
PjsgSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2VyDQo+IFBhdSBNb25uw6kgPHJv
Z2VyLnBhdUBjaXRyaXguY29tPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJu
ZWwub3JnPjsNCj4geGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJl
OiBbUEFUQ0ggdjQgMTEvMTVdIHhlbi94ODY6IGltcGxlbWVudCBFUFAgc3VwcG9ydCBmb3IgdGhl
IGFtZC1jcHBjDQo+IGRyaXZlciBpbiBhY3RpdmUgbW9kZQ0KPg0KPiBPbiAxNC4wNC4yMDI1IDA5
OjQwLCBQZW5ueSBaaGVuZyB3cm90ZToNCj4gPiBAQCAtNDM0LDEyICs0NjQsODIgQEAgc3RhdGlj
IGludCBjZl9jaGVjaw0KPiA+IGFtZF9jcHBjX2NwdWZyZXFfY3B1X2luaXQoc3RydWN0IGNwdWZy
ZXFfcG9saWN5ICpwb2xpY3kpDQo+ID4NCj4gPiAgICAgIGFtZF9jcHBjX2Jvb3N0X2luaXQocG9s
aWN5LCBkYXRhKTsNCj4gPg0KPiA+ICsgICAgcmV0dXJuIDA7DQo+ID4gK30NCj4gPiArDQo+ID4g
K3N0YXRpYyBpbnQgY2ZfY2hlY2sgYW1kX2NwcGNfY3B1ZnJlcV9jcHVfaW5pdChzdHJ1Y3QgY3B1
ZnJlcV9wb2xpY3kNCj4gPiArKnBvbGljeSkgew0KPiA+ICsgICAgaW50IHJldDsNCj4gPiArDQo+
ID4gKyAgICByZXQgPSBhbWRfY3BwY19jcHVmcmVxX2luaXRfcGVyZihwb2xpY3kpOw0KPiA+ICsg
ICAgaWYgKCByZXQgKQ0KPiA+ICsgICAgICAgIHJldHVybiByZXQ7DQo+ID4gKw0KPiA+ICAgICAg
YW1kX2NwcGNfdmVyYm9zZShwb2xpY3ktPmNwdSwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAg
IkNQVSBpbml0aWFsaXplZCB3aXRoIGFtZC1jcHBjIHBhc3NpdmUgbW9kZVxuIik7DQo+ID4NCj4g
PiAgICAgIHJldHVybiAwOw0KPiA+ICB9DQo+ID4NCj4gPiArc3RhdGljIGludCBjZl9jaGVjayBh
bWRfY3BwY19lcHBfY3B1X2luaXQoc3RydWN0IGNwdWZyZXFfcG9saWN5DQo+ID4gKypwb2xpY3kp
IHsNCj4gPiArICAgIGludCByZXQ7DQo+ID4gKw0KPiA+ICsgICAgcmV0ID0gYW1kX2NwcGNfY3B1
ZnJlcV9pbml0X3BlcmYocG9saWN5KTsNCj4gPiArICAgIGlmICggcmV0ICkNCj4gPiArICAgICAg
ICByZXR1cm4gcmV0Ow0KPiA+ICsNCj4gPiArICAgIHBvbGljeS0+cG9saWN5ID0gY3B1ZnJlcV9w
b2xpY3lfZnJvbV9nb3Zlcm5vcihwb2xpY3ktPmdvdmVybm9yKTsNCj4NCj4gVGhpcyBpcyB0aGUg
aW5pdCBwYXJ0LCB3aGljaCBpcyBmaW5lLiBXaGF0IGlmIHRoZSBnb3Zlcm5vciBpcyBiZWluZyBj
aGFuZ2VkLCB0aG91Z2g/DQo+IFRoZSBzdHJ1Y3QgZmllbGQgaXMgbmV3LCBhbmQgdGhlcmUncyBu
byBvdGhlciBwbGFjZSBJIGNhbiBzcG90IHdoZXJlIGl0IHdvdWxkIGJlDQo+IGFkanVzdGVkLg0K
Pg0KDQpZZXMsIEkndmUgbWlzc2VkIHRoZSBwYXJ0IHRoYXQgdXNlciBjaGFuZ2luZyBnb3Zlcm5v
ciB0aHJvdWdoICJ4ZW5wbSBzZXQtc2NhbGluZy1nb3Zlcm5vciINCkknbGwgYWRkIGEgbmV3IGNv
bW1pdCB0byBmaXgNCg0KPg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Fri May 09 04:52:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 04:52:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979759.1366261 (Exim 4.92)
	(envelope-from )
	id 1uDFiM-0003E7-5Q; Fri, 09 May 2025 04:52:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979759.1366261; Fri, 09 May 2025 04: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 1uDFiM-0003E0-2Q; Fri, 09 May 2025 04:52:02 +0000
Received: by outflank-mailman (input) for mailman id 979759;
 Fri, 09 May 2025 04:52:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDFiK-0003Dp-H8
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 04:52:00 +0000
Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com
 [2607:f8b0:4864:20::1132])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 531a3ff9-2c91-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 06:51:53 +0200 (CEST)
Received: by mail-yw1-x1132.google.com with SMTP id
 00721157ae682-70a35432c21so11796677b3.0; 
 Thu, 08 May 2025 21:51:53 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-70a3d9ec4e6sm3964487b3.95.2025.05.08.21.51.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 08 May 2025 21:51: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" 
X-Inumbo-ID: 531a3ff9-2c91-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746766312; x=1747371112; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=DYVVwNV/rBOmGTfp+DHX6WAdh7n1L1q/MEI16uRebkM=;
        b=ZzSs4SgZV1q06JdSXLnUDMrPw9Lz91sPoWqaWdkrc12zFGdOeeuDpaplGXSYDjCDUa
         zGbRlw8N8lRlpE1qtTVJlVf5BfW6eylFuSW1xAmNkd17El6UdGcH1Hs2nVRV4kcFszPA
         NXnwpIYhQD0bB6c9aZchv/ghq7FNypjfDjLdEGO8BhcleN933j/U0hxbmdM9fazONPz8
         kxy28QpXFJ3zcYqhl1utJOfa8wmPXC8u2s/aLhz2XqZ2TuExG/HcBwHmpxb4rvseq5Zz
         mpAlbSEQA3GIfcj+EPllfm1Cjyzjo6Qs2mhSrc0VYBLcUjKvObz355SyYc2bDzLOk4qt
         tbbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746766312; x=1747371112;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=DYVVwNV/rBOmGTfp+DHX6WAdh7n1L1q/MEI16uRebkM=;
        b=Shhszq/phjJZzgAebsIE8d1unhsZbV0ql/Jq3alMNYHQFphnp0QfrbIKgBj4g3h3up
         UJesNPK8kaFnYCtH6TRIoAUOZo4U9hnZn94IABkLoTXK8rIRerjfqJ5tiUATqxYZtubb
         drZsGGKfFAcCa7wvqzdjNzD+tdriAZ4n92kgEg1/NBi5qAbgPr3JTjta5Q5HLgrKvOJA
         gjX9WK/+Jbv25siJ1DyONZdWTXduXlMPlw7sOTNxd/PELF/OWFSotSIYl61ZLUKVp3sG
         qc/gllJFNWbuRBt2WLjVnE1qXGe2JjLZONw1Zt5BwA3Ceh0i0JXf8CTZ3BzilfBkuiM4
         n0cg==
X-Forwarded-Encrypted: i=1; AJvYcCVFXJFGODclEzWDZ2X03maKhUqat5xTX3q1G2Y0mVshQOMFMQZvsMEnQ/Gf2KWY/56HMhA06GsUIOiPFtEw/n2OuA==@lists.xenproject.org, AJvYcCVWBCLYu+JlugjC5QosSOPUlpLTgYuJJRGJarEzTVAxTQsNpITORi04oHf0qNQIJlxtEPvhnayuALp5@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy9Aor/jVJwEFHswUVLtWOYoOAviquP8JlMNv7RDK1pNp6qrTye
	sXnm61Lp11MWZJVvQWwMRYsEOMkydIvgLQal3/q1MaTjuNoD7Txh
X-Gm-Gg: ASbGnctwE/D8xTNUwBEGtdLFZ6m35nvscVNOhVy77KVa/VSpotntBLq4v99X2LkUdPv
	bM1IFTXjkr6LW4tbj3S3ew/vo/x8mAEgBAnGZ66p/DEw3C/oCMK4va7KOXYrMuhYvpWXGsBJB2W
	uVFzxls4J5usnKZ2eOFGMWQqIHw9NfegBcbhuEuf1rBS7M1+/czePfkzKhB+2WdMD0e18u7xOKY
	PndvJaPbAb9EYOWd5tc9GmdGd1tpzoHm3FQhsXcongdkFASGIVu/Zo7NNc8MeZQBnSXoi2usRdi
	Pw6esc5cHlCu0EF4r5ipBg6ntGtejgRQyFFBMspiD3zg
X-Google-Smtp-Source: AGHT+IFNN+w/zLbsPTSq+jWtBLyJEiL7LR8EvcR00Hn2A+A3YiUykcdPY/WVw9l8XeFRdibuPcJFyQ==
X-Received: by 2002:a05:690c:fd3:b0:703:b5ae:987e with SMTP id 00721157ae682-70a3f9eab6amr30917567b3.2.1746766311775;
        Thu, 08 May 2025 21:51:51 -0700 (PDT)
Message-ID: 
Date: Fri, 9 May 2025 00:52:28 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xenia Ragiadakou ,
 Stefano Stabellini 
Cc: Alejandro Vallejo ,
 Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: Mapping memory into a domain
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------0J501F4yNtHBTLbtY7AqHWmY"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------0J501F4yNtHBTLbtY7AqHWmY
Content-Type: multipart/mixed; boundary="------------cq2pLCqOCBKNgEhclUilQvE2";
 protected-headers="v1"
From: Demi Marie Obenour 
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xenia Ragiadakou ,
 Stefano Stabellini 
Cc: Alejandro Vallejo ,
 Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
Message-ID: 
Subject: Re: Mapping memory into a domain
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
In-Reply-To: 
Autocrypt-Gossip: 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==

--------------cq2pLCqOCBKNgEhclUilQvE2
Content-Type: multipart/mixed; boundary="------------nvqOraiAUlImmzT6HAh2PVHM"

--------------nvqOraiAUlImmzT6HAh2PVHM
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/8/25 3:52 AM, Roger Pau Monn=C3=A9 wrote:
> On Wed, May 07, 2025 at 08:36:07PM -0400, Demi Marie Obenour wrote:
>> On 5/7/25 1:39 PM, Roger Pau Monn=C3=A9 wrote:
>>> On Tue, May 06, 2025 at 04:56:12PM -0400, Demi Marie Obenour wrote:
>>>> On 5/6/25 9:06 AM, Alejandro Vallejo wrote:
>>>>> On Tue May 6, 2025 at 3:02 AM CEST, Demi Marie Obenour wrote:
>>>>>> On 5/5/25 7:32 AM, Alejandro Vallejo wrote:
>>>>>>> I suppose this is still about multiplexing the GPU driver the way=
 we
>>>>>>> last discussed at Xen Summit?
>>>>>>>
>>>>>>> On Mon May 5, 2025 at 12:51 AM CEST, Demi Marie Obenour wrote:
>>>>>>>> What are the appropriate Xen internal functions for:
>>>>>>>>
>>>>>>>> 1. Turning a PFN into an MFN?
>>>>>>>> 2. Mapping an MFN into a guest?
>>>>>>>> 3. Unmapping that MFN from a guest?
>>>>>>>
>>>>>>> The p2m is the single source of truth about such mappings.
>>>>>>>
>>>>>>> This is all racy business. You want to keep the p2m lock for the =
full
>>>>>>> duration of whatever operation you wish do, or you risk another C=
PU
>>>>>>> taking it and pulling the rug under your feet at the most inconve=
nient
>>>>>>> time.
>>>>>>>
>>>>>>> In general all this faff is hidden under way too many layers bene=
ath
>>>>>>> copy_{to,from}_guest(). Other p2m manipulation high-level constru=
cts
>>>>>>> that might do interesting things worth looking at may be {map,unm=
ap}_mmio_region()
>>>>>>>
>>>>>>> Note that not every pfn has an associated mfn. Not even every val=
id pfn
>>>>>>> has necessarily an associated mfn (there's pod). And all of this =
is
>>>>>>> volatile business in the presence of a baloon driver or vPCI plac=
ing
>>>>>>> mmio windows over guest memory.
>>>>>>
>>>>>> Can I check that POD is not in use? =20
>>>>>
>>>>> Maybe, but now you're reaching exponential complexity considering e=
ach
>>>>> individual knob of the p2m into account.
>>>>>
>>>>>>
>>>>>>> In general anything up this alley would need a cohesive pair for
>>>>>>> map/unmap and a credible plan for concurrency and how it's all ha=
ndled
>>>>>>> in conjunction with other bits that touch the p2m.
>>>>>>
>>>>>> Is taking the p2m lock for the entire operation a reasonable appro=
ach
>>>>>> for concurrency?  Will this cause too much lock contention?
>>>>>
>>>>> Maybe. It'd be fine for a page. Likely not so for several GiB if th=
ey
>>>>> aren't already superpages.
>>>>>
>>>>>>
>>>>>>>> The first patch I am going to send with this information is a do=
cumentation
>>>>>>>> patch so that others do not need to figure this out for themselv=
es.
>>>>>>>> I remember being unsure even after looking through the source co=
de, which
>>>>>>>> is why I am asking here.
>>>>>>>
>>>>>>> That's not surprising. There's per-arch stuff, per-p2mtype stuff,=

>>>>>>> per-guesttype stuff. Plus madness like on-demand memory. It's no =
wonder
>>>>>>> such helpers don't exist and the general manipulations are hard t=
o
>>>>>>> explain.
>>>>>>
>>>>>> Is this a task that is only suitable for someone who has several y=
ears
>>>>>> experience working on Xen, or is it something that would make sens=
e for
>>>>>> someone who is less experienced?
>>>>>
>>>>> The p2m is a very complex beast that integrates more features than =
I
>>>>> care to count. It requires a lot of prior knowledge. Whoever does i=
t
>>>>> must know Xen fairly well in many configurations.
>>>>>
>>>>> The real problem is finding the right primitives that do what you w=
ant
>>>>> without overcomplicating everything else, preserving system securit=
y
>>>>> invariants and have benign (and ideally clear) edge cases.
>>>>>
>>>>> This was the last email you sent (I think?). Has any of the require=
ments
>>>>> changed in any direction?
>>>>>
>>>>>   https://lore.kernel.org/xen-devel/Z5794ysNE4KDkFuT@itl-email/
>>>>
>>>> Map and Revoke are still needed, with the same requirements as descr=
ibed
>>>> in this email.  Steal and Return were needed for GPU shared virtual =
memory,
>>>> but it has been decided to not support this with virtio-GPU, so thes=
e
>>>> primitives are no longer needed.
>>>>
>>>>> Something I'm missing there is how everything works without Xen. Th=
at
>>>>> might help (me, at least) guage what could prove enough to support =
the
>>>>> usecase. Are there sequence diagrams anywhere about how this whole =
thing
>>>>> works without Xen? I vaguely remember you showing something last ye=
ar in
>>>>> Xen Summit in the design session, but my memory isn't that good :)
>>>
>>> Hello,
>>>
>>> Sorry, possibly replying a bit out of context here.
>>>
>>> Since I will mention this in several places: p2m is the second stage
>>> page-tables used by Xen for PVH and HVM guests.  A p2m violation is
>>> the equivalent of a page-fault for guest p2m accesses.
>>>
>>>> A Linux driver that needs access to userspace memory
>>>> pages can get it in two different ways:
>>>>
>>>> 1. It can pin the pages using the pin_user_pages family of APIs.
>>>>    If these functions succeed, the driver is guaranteed to be able
>>>>    to access the pages until it unpins them.  However, this also
>>>>    means that the pages cannot be paged out or migrated.  Furthermor=
e,
>>>>    file-backed pages cannot be safely pinned, and pinning GPU memory=

>>>>    isn=E2=80=99t supported.  (At a minimum, it would prevent the pag=
es from
>>>>    migrating from system RAM to VRAM, so all access by a dGPU would
>>>>    cross the PCIe bus, which would be very slow.)
>>>
>>> From a Xen p2m this is all fine - Xen will never remove pages from th=
e
>>> p2m unless it's requested to.  So the pining, while needed on the Lin=
ux
>>> side, doesn't need to be propagated to Xen I would think.
>>
>> If pinning were enough things would be simple, but sadly it=E2=80=99s =
not.
>>
>>>> 2. It can grab the *current* location of the pages and register an
>>>>    MMU notifier.  This works for GPU memory and file-backed memory.
>>>>    However, when the invalidate_range function of this callback, the=

>>>>    driver *must* stop all further accesses to the pages.
>>>>
>>>>    The invalidate_range callback is not allowed to block for a long
>>>>    period of time.  My understanding is that things like dirty page
>>>>    writeback are blocked while the callback is in progress.  My
>>>>    understanding is also that the callback is not allowed to fail.
>>>>    I believe it can return a retryable error but I don=E2=80=99t thi=
nk that
>>>>    it is allowed to keep failing forever.
>>>>
>>>>    Linux=E2=80=99s grant table driver actually had a bug in this are=
a, which
>>>>    led to deadlocks.  I fixed that a while back.
>>>>
>>>> KVM implements the second option: it maps pages into the stage-2
>>>> page tables (or shadow page tables, if that is chosen) and unmaps
>>>> them when the invalidate_range callback is called.
>>>
>>> I assume this map and unmap is done by the host as a result of some
>>> guest action?
>>
>> Unmapping can happen at any time for any or no reason.  Semantically,
>> it would be correct to only map the pages in response to a p2m violati=
on,
>> but for performance it might be better to map the pages eagerly instea=
d.
>=20
> That's an implementation detail, you can certainly map the pages
> eagerly, or even map multiple contiguous pages as a result of a single
> p2m violation.
>=20
> I would focus on making a functioning prototype first, performance
> comes afterwards.

Makes sense.

>>>> Furthermore,
>>>> if a page fault happens while the page is unmapped, KVM will try
>>>> to bring the pages back into memory so the guest can access it.
>>>
>>> You could likely handle this in Xen in the following way:
>>>
>>>  - A device model will get p2m violations forwarded, as it's the same=

>>>    model that's used to handle emulation of device MMIO.  You will
>>>    need to register an ioreq server to request those faults to be
>>>    forwarded, I think the hardware domain kernel will handle those?
>>>
>>>  - Allow ioreqs to signal to Xen that a guest operation must be
>>>    retried.  IOW: resume guest execution without advancing the IP.
>>>
>>> I think this last bit is the one that will require changes to Xen, so=

>>> that you can add a type of ioreq reply that implies a retry from the
>>> guest context.
>> I=E2=80=99m not actually sure if this is needed, though it would be ni=
ce.  It
>> might be possible for Xen to instead emulate the current instruction a=
nd
>> continue, with the ioreq server just returning the current value of th=
e
>> pages.
>=20
> You can, indeed, but it's cumbersome?  You might have to map the page
> in the context of the entity that implements the ioreq server to
> access the data.  Allowing retries would be more generic, and reduce
> the code in the ioreq server handler, that would only map the page
> to the guest p2m and request a retry.

Yeah, it is cumbersome indeed.

>> What I=E2=80=99m more concerned about is being able to provide a page
>> into the p2m so that the *next* access doesn=E2=80=99t fault, and bein=
g able
>> to remove that page from the p2m so that the next access *does* fault.=

>=20
> Maybe I'm not getting the question right, all Xen modifications to the
> p2m take immediate effect.  By the time a XEN_DOMCTL_memory_mapping
> hypercall returns the operation would have taken effect.

Ah, that makes sense.  When revoking access, can XEN_DOMCTL_iomem_permiss=
ion
and XEN_DOMCTL_memory_mapping fail even if the parameters are correct and=

the caller has enough permissions, or will they always succeed?

>> Are there any hypercalls that can be used for these operations right
>> now?
>=20
> With some trickery you could likely use XEN_DOMCTL_memory_mapping to
> add and remove those pages.  You will need calls to
> XEN_DOMCTL_iomem_permission beforehand so that you grant the receiving
> domain permissions to access those (and of course the granting domain
> needs to have full access to them).
>=20
> This is no ideal if mapping RAM pages, AFAICT there are no strict
> checks that the added page is not RAM, but still you will need to
> handle RAM pages as IOMEM so and grant them using
> XEN_DOMCTL_iomem_permission which is not great.  Also note that this
> is a domctl, so not stable.  It might however be enough for a
> prototype.

Unfortunately this won=E2=80=99t work if the backend is a PVH domain, as =
a PVH
domain doesn=E2=80=99t know its own MFNs.  It also won=E2=80=99t work for=
 deprivileged
backends because XEN_DOMCTL_iomem_permission is subject to XSA-77.

> Long term I think we want to expand XENMEM_add_to_physmap{,_batch} to
> handle this use-case.

That would indeed be better.

>> If not, which Xen functions would one use to implement them?
>> Some notes:
>>
>> - The p2m might need to be made to point to a PCI BAR or system RAM.
>>   The guest kernel and host userspace don=E2=80=99t know which, and in=
 any
>>   case don=E2=80=99t need to care.  The host kernel knows, but I don=E2=
=80=99t know
>>   if the information is exposed to the Xen driver.
>=20
> Hm, as said above, while you could possible handle RAM as IOMEM, it
> has the slight inconvenience of having to add such RAM pages to the
> d->iomem_caps rangeset for XEN_DOMCTL_memory_mapping to succeed.
>=20
> From a guest PoV, it doesn't matter if the underlying page is RAM or
> MMIO, as long as it's mapped in the p2m.

Understood, thanks!

>> - If the p2m needs to point to system RAM, the RAM will be memory
>>   that belongs to the backend.
>>
>> - If the p2m needs to point to a PCI BAR, it will initially need
>>   to point to a real PCI device that is owned by the backend.
>=20
> As long as you give the destination domain access to the page using
> XEN_DOMCTL_iomem_permission prior to the XEN_DOMCTL_memory_mapping
> call it should work.
>=20
> How does this work for device DMA accesses?  If the device is assigned
> to the backend domain (and thus using the backend domain IOMMU context
> entry and page-tables) DMA accesses cannot be done against guest
> provided addresses, there needs to be some kind of translation layer
> that filters commands?

Thankfully, this is handled by the backend.

> My initial recommendation would be to look into what you can do with
> the existing XEN_DOMCTL_iomem_permission and XEN_DOMCTL_memory_mapping
> hypercalls.

I think this would be suitable for a prototype but not for production.

>> - The switch from =E2=80=9Cemulated MMIO=E2=80=9D to =E2=80=9CMMIO or =
real RAM=E2=80=9D needs to
>>   be atomic from the guest=E2=80=99s perspective.
>=20
> Updates of p2m PTEs are always atomic.
That=E2=80=99s good.

Xenia, would it be possible for AMD to post whatever has been
implemented so far?  I think this would help a lot, even if it
is incomplete.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------nvqOraiAUlImmzT6HAh2PVHM
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------nvqOraiAUlImmzT6HAh2PVHM--

--------------cq2pLCqOCBKNgEhclUilQvE2--

--------------0J501F4yNtHBTLbtY7AqHWmY
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgdihUACgkQszaHOrMp
8lOyHA//X03qV4z2Vi71RG4/DzyeuBxlp+C7G93CWCRbgCDZX0AJAwcjOKGZZVze
wvU38FEzRCjyLVfQlA/XX5N/IihIcMLycuQu1uf6iql/aFaN9390050FEAMJJRl8
TjEhYDeESHxY9mE66QLbQ790Cb1BmbZKKkbq0FNSjk4GVxHFutOC8GQOv6bBWDc9
tqj4qnmxOj+v6/NB2hQaJLo98JRhZBE1tXJxUMLc9HQqhmzkZBQRl4ftj7OeXyxe
+5akcV6NkEvYu6R/PKLpPgCwm3Wf8azbJg4FoD7JU99TNZ+qKV7Ywqqo5l88t5xM
H4vZlnnwx77bEhP03diYbsrNz5jvLg8ujG9itJFD6z+aR0v15mwdgzu1DRZ3Z/+n
QAJ7fF5C+NLQHHzD5aOuR+aSlZXypnlIGzEWJcbeAAnePFn/w4zow+kUswBndhkf
j/lwr8NtQ7OkI3cqtTFljK6zJ4HIruH91AeuCOck7E+92G/y3lKfZlBuxZY0rcgY
ks9wj57SpaxK/qz2X7dy3TPkikHuF1Dxjd9hT80FjP5zxvtkjSYQxvcreRL7hkpv
klBWzuOH/fEoBiRQ7yNW5DwxAIb0jpaataXrbStCxd9keILGT1o3FhPHsFW6iaDe
wjG02QqGllGKU54QMhNN04F99YaBelW4YYYEqi3RJxGMOpI9qaY=
=Cz+T
-----END PGP SIGNATURE-----

--------------0J501F4yNtHBTLbtY7AqHWmY--


From xen-devel-bounces@lists.xenproject.org Fri May 09 05:27:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 05:27:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979773.1366271 (Exim 4.92)
	(envelope-from )
	id 1uDGGZ-0007pz-Qn; Fri, 09 May 2025 05:27:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979773.1366271; Fri, 09 May 2025 05:27: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 1uDGGZ-0007ps-NF; Fri, 09 May 2025 05:27:23 +0000
Received: by outflank-mailman (input) for mailman id 979773;
 Fri, 09 May 2025 05:27:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDGGX-0007pi-Aw
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 05:27:21 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2412::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 42cd7074-2c96-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 07:27:14 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by PH8PR12MB7255.namprd12.prod.outlook.com (2603:10b6:510:224::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Fri, 9 May
 2025 05:27:03 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8722.020; Fri, 9 May 2025
 05:27: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" 
X-Inumbo-ID: 42cd7074-2c96-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OoY+OaSXKbqL/PapIJLtwXQfu/tkgzwZfj+vVM7pMoCT+0Iu3ylAS2sp/SNNk6lAO+bDEzbNYDw2bzOH5GpQldTFzAtDnISCGFSqQLWCl5XHab1ec/xwJ3zRFvBuyAMhNDRHmYYk+5V2n5njLWvYwb0sH13rk7eqKXUbZJ6BmhLmdxAFZTg9Gkc5EmE9oBHFhMuI3j1Uf+Otc1evQmdBLFXMj9D0fKLB4hoLb7s95qKCEEJH+0EH/y6Ga1M9bnOHbb1Gm7PTQNrYjCsrcyaOw/LeZzGp70uOo59wa5cV4gVFas/PJgttmhc5DUcpqTtU6yu84aE9A7jvUTLnD5MRww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YjyZaWpR24+2z4/rJih/V4C6vN9fQU2HDqrvqFnp5rE=;
 b=p+nI6rB10+bYiqo2EtSohGmmuE+1gLdO78CvdShxEM8aPDGBTU8BmRd3lY6kE18+4qn+tVWS9+mFSb5rOlhax6coVg2AbJP6IgrtkMhegv/ZETE9YfU3lULExCnSnc9PP+PiSOFxAms3k2GsnHW35vBQZXPu6UnBs261MJB2nKbwDOAlgM5UXvwAlyUYofmxkkUIbEBep4LCnRrQdl+dII9cIX5Vopaow19KS63F+THP2Tx/N18+qiZUF8BwpM6zlNcIzXedrIiBOo0xgdlPK9xRuhFwdzAVu1NEh0IxyxiFJb+KjjLvihN/ARQHbuLVlRPpqJy7kUFsHMTC4I/U1Q==
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=YjyZaWpR24+2z4/rJih/V4C6vN9fQU2HDqrvqFnp5rE=;
 b=hjUljAIwl5xvW5AjJi0TXaXJcy4vm+VnWZ3MBzW0syFP9eetlndg3pzVOYNaboTOs5PagCHjyGbfqyh6edbJquqkphfBBFtspsrtxNW1xDJYWsiUT9hfeVV56lXZQ8BUGT2SIoBk1LiA5AwQwLNrwaRpJ5pvSBINZ4c/B8ROkvA=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v3 09/11] vpci/rebar: Remove registers when init_rebar()
 fails
Thread-Topic: [PATCH v3 09/11] vpci/rebar: Remove registers when init_rebar()
 fails
Thread-Index: AQHbsoVe6F65c/dHgEykZ9ogXltmkLPIlQSAgAHRRYA=
Date: Fri, 9 May 2025 05:27:03 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-10-Jiqian.Chen@amd.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8722.017)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|PH8PR12MB7255:EE_
x-ms-office365-filtering-correlation-id: 794fa715-3fdb-4af2-cf92-08dd8eba215c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?TlJORXlMYjg3MnhiRlZLbGZpWC9EM2QxaHd1NjhYSlB2clpHaTBWd0xvVFFH?=
 =?utf-8?B?RnpsKzlyaFVoTVk1dWpDZm5LVnlHVUFIdjNWeDZWb2Z6dzBYWXMraVZSTFF5?=
 =?utf-8?B?VVd5Yyt2Q2pWdnphM0U3c3RTYS9Wc2k3QjVlcVNHVUZzUVVlZVRvakZTeGg4?=
 =?utf-8?B?SC9lRmdYQStrajFhNS83bnovck5tWTFVRWg5bzVickpKOE9TTk1RV1pXa0ly?=
 =?utf-8?B?K09uNjRPaFNlamVsSGpkUWVDcFdUYksyYzZtK01lTHVVZ0c4WFBCYTdvb0M5?=
 =?utf-8?B?Mk1BMlM4TU4ydW1sTS9GSEIzN3hzd2RJaWFsQWtPS1NMeGsyMU9JZUZ5QzE0?=
 =?utf-8?B?cUdQMVZVQW5RcGRBVGRlbWM2SWxZaGNlbEJCY3M2TzFhclFoTVlwelU4S0lN?=
 =?utf-8?B?SFZHekhyVjNpa290Y01tY3N0S2FwelcxWngxRm82WmRlTng1YkRRZ0Z1TjZw?=
 =?utf-8?B?amh6K1VmTnFwcFNVZGxHS2dCZ2UrUVdlL3BIY1E0Ni85eHU5L3cxQUxwODZU?=
 =?utf-8?B?RGRFM055ZzA4cWVrUWQzN2pQa0FQRkFtNVlhM2JVNlhlRGxYWkZ6UUJUMm9h?=
 =?utf-8?B?ODNaemdOd1VnUTU2OWxVVGUxTlB6OTNOTHZacXRBZUVBWFhaZWNrUXJNQmZV?=
 =?utf-8?B?WVFPbWtaeG5FNStRYWJJNWxoMlRSUHpOVDY2Tm1ZY1VPcTNlMzBUWU5ma2hw?=
 =?utf-8?B?aXdYM1BVLzlBMEY2ajQ4Q21ObTJPOUE1V2ZraWxQMFVSRUorU1dBNGZZcVNN?=
 =?utf-8?B?a2cydkEzZGZ2Vi90bzRBekUxdW5OMTl6SW1CQVN4MVpGNG5NZ092MjdqdFlm?=
 =?utf-8?B?TXMxaGdHckk5VGcway9CajZXaGF6anJDYjhMUkh5RytnN09lNzl4cm50VXlI?=
 =?utf-8?B?V25nSU5Sd2RrU1lBbmo3dWNzcnEyd3N1YlZDOWRrYUxSU2ZDVlQva2JScUVH?=
 =?utf-8?B?NkxRTHBnOXRyWU4vNkkrdmR4T2tydXVZWjZWcHFPRHNNbmtpQ2RKK2dMemNK?=
 =?utf-8?B?TWY4cFZhTEc4Y2U3V1BoRHJIZFlRc0EvbnBHT0lRYk0zNCtXNDJsTCtCSUov?=
 =?utf-8?B?aDVNbFRlQ2ZUU3B3VVAzajBHL0tQVW82REFmL3ZFWUQ2NVpGWUhpMGIvQmpD?=
 =?utf-8?B?dmVxak1PWUlHc1J1QmtySjdMeEk0OWk2YkR4Z1gwSWs0dGsybHhRTDJjc3Vv?=
 =?utf-8?B?bC9rUUtEOXQ4Zi9tQ0ZLVXdTdGVTaC9za3l1V1d2RTBvblM5dU9QSWNHSmxE?=
 =?utf-8?B?bWtyVWM1bWY4YzN0NURRcUJXU1BHTHNOMUZhYXNQYXBnNWtXY0g0K3VFSXN0?=
 =?utf-8?B?blk4emZzTmVTVFlVZlBpYkFsT0ZNdVNaa1BsNytTWXVkS1pzaGJhaTloY0Vi?=
 =?utf-8?B?Qk83b092VGFST3NsVGZlN0pWWXN0LzhpN1RFeTZBYWtFb3I5azM2YzNPUHl3?=
 =?utf-8?B?dkhFckdMcU9qSUF3NHhVVGVGeHN3ODVTUmpRRVJIbGRIaWtwVU5wSUlUQnhF?=
 =?utf-8?B?aWprWE9xS0pMR2VySDNYUEJnUi92dXJuaEk4b2RiSzc2Z3hFa1lUYzlQZGgx?=
 =?utf-8?B?cjljVUg5T3cxdmhXbGxPK0lLSXFRYkpoY3NCVHdZQ0dCUnExVlVnY3BKK2tz?=
 =?utf-8?B?ZDNxVUp3OWxFMGJoQ2JwM1k0djh5YkZzbGhQOUpYUm0wV0JPNzNlQm9jbzhm?=
 =?utf-8?B?Tm9EdVZlZnB3bm1KNllpbko2L1lLMEdCUG55VGkrN2RtamswemhVeU9tb2ZX?=
 =?utf-8?B?WEErMUlFWW1TZ05Oby9DOGprRmk2VDFDR2UwUXZOUVZqMDZSa1RpR01aMVJh?=
 =?utf-8?B?cjFsbHRNOUkvUk9JYlowQXVmRHM3b3hEdWZ4a0lEbDNNTEUrTVB1SjVLSnFl?=
 =?utf-8?B?QVFla2dnamVwbGI4eGZ3Q0JJWjJCa0RCQ20waXg1OFpJTkZwNDZWaXhEdXRw?=
 =?utf-8?B?MTA3bHpRR0pEbDNGQndHeUV5aVFiQVRoOTFDdzV0Z1RBMnFaSXVLZlIydDRS?=
 =?utf-8?B?Njl5TE9uRTF3PT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SUNkeVdPTlI0cFlRUDhXNkFLZ2JDTFlCb2E5K1RMSDdoM2FqWmFZUkRZeEVm?=
 =?utf-8?B?akFESDl0dGxHT0V5VDB5UUhMUG9ZRFJyeGRlK2JqeXc3VC8velZZRWF1dVlU?=
 =?utf-8?B?NzJTMlpjZE5JMDQ3eitvYVNmdjBuaXF4M0F2UEczbnJyckVKd1pNS3VZSnFa?=
 =?utf-8?B?SWY0TWMyWEtlRjA5MDRCemZSRlo3cEhOUmxHa2JHY2MxK1FUVWZoTC9ISjF4?=
 =?utf-8?B?UGNubnBwRGlITktaSFpDTy9qM2NET1RKVkFYT0NLNXBKekkwL01JaG1WTHFw?=
 =?utf-8?B?Tno5NjE5aXpvNlNVVjJxYUtIa0VMS1FOL2ZaeFlmS1h0SGpLSitnOWhLNkti?=
 =?utf-8?B?SFF3TWVQT1Y2WlpUWmJHTnZSQURPV1piS1V0aGcxcDJjcGN2M1dqVi82VWxG?=
 =?utf-8?B?SllWZHRaalpzQU5BQnV4QS9VK3BESXhhWjNxdkwreis4ZVVDUW1JQ0UvQ05L?=
 =?utf-8?B?bGI0TjZmVlZCVlh4TXBzUS94ZXpCQmQwaDRaZ1RBd0NydjhwdHpkakJTZDhR?=
 =?utf-8?B?Ujdnd0s5L0UydkZhUVdXL21nVmpGK2JlVWtWS0QvVzdUUUorZVk0d2IxTDJC?=
 =?utf-8?B?dHIzWGlpdzhrRXVXSXlJYmw1aWM0Z1I0Nm5xQmxHNytzRkF4QnBUTmVya1Fa?=
 =?utf-8?B?NURIMXMvRUU4dk5qZFdxMlNrdzk5azMwTW1NbVQ1NGs5dXNpWUhnUUQ3R3JM?=
 =?utf-8?B?WTFFWXpKdFlrZFl2ZHNmSU9sY2E0OTZEeUZCK2lSVmhEZitQR0pFTlJBYzFz?=
 =?utf-8?B?YjB2TXBCd3B0V3hhditJdmwvaVphRmlqcXJpYWVtY3VEUUg3Q3ZjZ1ErRk5M?=
 =?utf-8?B?VzJKRDNZOWN2M0YxUTlGRXB3UmgwUUloZXcrVkUwK2srVGdVRjVNc2gzeHh6?=
 =?utf-8?B?Q3g3ZGk2VmVxaUJkcVVFZEtUVVIzdnNkUnRvaEROanlZN3dhcW5YbElVaFRa?=
 =?utf-8?B?YitvMXFMbENvZUQvWnU2QWcwYS83RjlDbjRsK09OMytpOW5FQXJUQ0VGbEVp?=
 =?utf-8?B?cjJlNEtJOWVhb1pIaHk2TmtsbWZzT0dDMHZHR1FjYUs5WTEweXdNMnZPTVg0?=
 =?utf-8?B?ODA1NXlGMWFRbWdCdnpSdFY2SDRjOTFiSEg5VHZkbmJaOWlRRDFSOGZlQkh2?=
 =?utf-8?B?d0RHYmRyR1ZDQkg0NTRldlBsemxIYng4Rk85TktoSlJXTUEwME9JRmZ4YmF5?=
 =?utf-8?B?Z0JzNFBNRHpaRHArdEtybnpST2lhVjZ3V0NUaG5iMG9QQ1dBd0F2Y3VNZ2Vs?=
 =?utf-8?B?Qllzai9BYlN4MnZxYjBVTjBrZUIrdVFDUk9qN1J4aEVzYmdNZjEya1pzbTI2?=
 =?utf-8?B?NXVQQ2NmdUw0K0diWnd1TkU4TkpWRHY5ck5QRzQ0cUlydDhMc1B6VktRTWlT?=
 =?utf-8?B?MkNFVXBMOEdCU1lkbTVsY0ZueXJqRytLclI5Sm5GdVdjcDIvQi9ZV0hkNjlH?=
 =?utf-8?B?MDY1MXZwb2hHMm05THhPMkVyN3VRWGFXTTVZRU96aVlYS0VaM0U0OUFFMlBm?=
 =?utf-8?B?Y241UFNkZUxsbHFQbDJ0YktMbFM2K3dpWVNVWnA2WU1SOXQ3bGRXamE5UktF?=
 =?utf-8?B?S0R4YnZyakRJT0tOcEpPMzBqUE4yTE1jMUM4UVN3bE94ZDJEWGpGc0p4UytL?=
 =?utf-8?B?VWpjc0YxOXorS214VnRLclFNckYwNGJscnRlNUJaZUtsOTNkMC96MlAxMmln?=
 =?utf-8?B?d1FYYXp0TTVSWTk0MWNOSWZFbUR0YWdVTmhPOTdpUlNVaklYdUZlRVRyRVN3?=
 =?utf-8?B?a1VHeEdaMnkyT3U4b2p2WlZKa1dnZENHcGdNM09jMmcwbWRZQUtIK0JjOWgw?=
 =?utf-8?B?Ump4cWwzQVJIR0JyV05uSlV0S1RoeEdKTXJVTUVpQ0p0WFZZUVBWbndmQm83?=
 =?utf-8?B?a0N4ODZpMW1wNHF6Z0YvU0ZobWxxSFhzcFlhZ25FWVVyTG8vakhueTh2Ylhp?=
 =?utf-8?B?b2pDWkt0TFQzcmNvL3JnbUgvRGs3UFFOckhSSTg2bGFFTHhDeStKdVRHSlRt?=
 =?utf-8?B?bzJ2VEkweHRBSjA1L2hLbjR5NTJIU1NwcGYrUDNtRmpHaHV4VFIzTmI3T0d5?=
 =?utf-8?B?dFVha1ovMmJEOHpLaFZFbDBweVFYQ1QrdE0zMmZvRnc5eXpEM0JJbm00TnBH?=
 =?utf-8?Q?ZrXc=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <5D494CB2B2834A48BD3E756E22EE05BE@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 794fa715-3fdb-4af2-cf92-08dd8eba215c
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2025 05:27:03.1052
 (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: LNJo7WbHKut6KXiEcX5igNxGffcFXFzGpBLHyASYOfBx0LuE/fjb/iLOb5g93AwDILdjT4+1OvC1u4WMs6+5gA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7255

T24gMjAyNS81LzggMTc6MzksIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgQXBy
IDIxLCAyMDI1IGF0IDAyOjE5OjAxUE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gV2hl
biBpbml0X3JlYmFyKCkgZmFpbHMsIHRoZSBwcmV2aW91cyBuZXcgY2hhbmdlcyB3aWxsIGhpZGUg
UmViYXINCj4+IGNhcGFiaWxpdHksIGl0IGNhbid0IHJlbHkgb24gdnBjaV9kZWFzc2lnbl9kZXZp
Y2UoKSB0byByZW1vdmUgYWxsDQo+PiBSZWJhciByZWxhdGVkIHJlZ2lzdGVycyBhbnltb3JlLCB0
aG9zZSByZWdpc3RlcnMgbXVzdCBiZSByZW1vdmVkDQo+PiBmaW5pX3JlYmFyKCkuDQo+Pg0KPj4g
VG8gZG8gdGhhdCwgY2FsbCB2cGNpX3JlbW92ZV9yZWdpc3RlcnMoKSB0byByZW1vdmUgYWxsIHBv
c3NpYmxlDQo+PiByZWdpc3RlcmVkIHJlZ2lzdGVycy4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBK
aXFpYW4gQ2hlbiA8SmlxaWFuLkNoZW5AYW1kLmNvbT4NCj4+IC0tLQ0KPj4gY2M6ICJSb2dlciBQ
YXUgTW9ubsOpIiA8cm9nZXIucGF1QGNpdHJpeC5jb20+DQo+PiAtLS0NCj4+IHYyLT52MyBjaGFu
Z2VzOg0KPj4gKiBVc2UgZmluaV9yZWJhcigpIHRvIHJlbW92ZSBhbGwgcmVnaXN0ZXIgaW5zdGVh
ZCBvZiBpbiB0aGUgZmFpbHVyZSBwYXRoIG9mIGluaXRfcmViYXIoKTsNCj4+DQo+PiB2MS0+djIg
Y2hhbmdlczoNCj4+ICogQ2FsbGVkIHZwY2lfcmVtb3ZlX3JlZ2lzdGVycygpIHRvIHJlbW92ZSBh
bGwgcG9zc2libGUgcmVnaXN0ZXJlZCByZWdpc3RlcnMgaW5zdGVhZCBvZiB1c2luZyBhIGFycmF5
IHRvIHJlY29yZCBhbGwgcmVnaXN0ZXJlZCByZWdpc3Rlci4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMs
DQo+PiBKaXFpYW4gQ2hlbi4NCj4+IC0tLQ0KPj4gIHhlbi9kcml2ZXJzL3ZwY2kvcmViYXIuYyB8
IDM1ICsrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tDQo+PiAgMSBmaWxlIGNoYW5n
ZWQsIDI0IGluc2VydGlvbnMoKyksIDExIGRlbGV0aW9ucygtKQ0KPj4NCj4+IGRpZmYgLS1naXQg
YS94ZW4vZHJpdmVycy92cGNpL3JlYmFyLmMgYi94ZW4vZHJpdmVycy92cGNpL3JlYmFyLmMNCj4+
IGluZGV4IDAyNmY4Zjc5NzJkOS4uMzI1MDkwYWZiMGY4IDEwMDY0NA0KPj4gLS0tIGEveGVuL2Ry
aXZlcnMvdnBjaS9yZWJhci5jDQo+PiArKysgYi94ZW4vZHJpdmVycy92cGNpL3JlYmFyLmMNCj4+
IEBAIC00OSw2ICs0OSwyNiBAQCBzdGF0aWMgdm9pZCBjZl9jaGVjayByZWJhcl9jdHJsX3dyaXRl
KGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LA0KPj4gICAgICBiYXItPmd1ZXN0X2FkZHIgPSBi
YXItPmFkZHI7DQo+PiAgfQ0KPj4gIA0KPj4gK3N0YXRpYyB2b2lkIGZpbmlfcmViYXIoc3RydWN0
IHBjaV9kZXYgKnBkZXYpDQpCeSB0aGUgd2F5LCBJIHdpbGwgcmVuYW1lIHRoaXMgdG8gYmUgY2xl
YW51cF9yZWJhciBzaW5jZSB0aGUgaG9vayBuYW1lIHdpbGwgYmUgY2hhbmdlZCBpbiBuZXh0IHZl
cnNpb24uDQoNCj4+ICt7DQo+PiArICAgIHVpbnQzMl90IGN0cmw7DQo+PiArICAgIHVuc2lnbmVk
IGludCBuYmFyczsNCj4+ICsgICAgdW5zaWduZWQgaW50IHJlYmFyX29mZnNldCA9IHBjaV9maW5k
X2V4dF9jYXBhYmlsaXR5KHBkZXYtPnNiZGYsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQQ0lfRVhUX0NBUF9JRF9SRUJBUik7DQo+
PiArDQo+PiArICAgIGlmICggIXJlYmFyX29mZnNldCB8fCAhaXNfaGFyZHdhcmVfZG9tYWluKHBk
ZXYtPmRvbWFpbikgKQ0KPiANCj4gTWF5YmUgYWRkIGFuIEFTU0VSVF9VTlJFQUNIQUJMRSgpIGhl
cmU/ICBJIGRvbid0IHRoaW5rIHdlIGFyZSBleHBlY3RlZA0KPiB0byBnZXQgaW50byB0aGUgY2xl
YW51cCBmdW5jdGlvbiBmb3IgdGhlIGNhcGFiaWxpdHkgaWYgaXQncyBub3QNCj4gcHJlc2VudCwg
b3IgaWYgdGhlIG93bmVyIG9mIHRoZSBkZXZpY2UgaXMgbm90IHRoZSBoYXJkd2FyZSBkb21haW4u
DQpZZXMsIHdlIGRvbid0IGV4cGVjdCB0aGF0Lg0KV2lsbCBhZGQgYW4gQVNTRVJUX1VOUkVBQ0hB
QkxFKCkgaGVyZSBpbiBuZXh0IHZlcnNpb24uDQoNCj4gDQo+PiArICAgICAgICByZXR1cm47DQo+
PiArDQo+PiArICAgIGN0cmwgPSBwY2lfY29uZl9yZWFkMzIocGRldi0+c2JkZiwgcmViYXJfb2Zm
c2V0ICsgUENJX1JFQkFSX0NUUkwoMCkpOw0KPj4gKyAgICBuYmFycyA9IE1BU0tfRVhUUihjdHJs
LCBQQ0lfUkVCQVJfQ1RSTF9OQkFSX01BU0spOw0KPj4gKyAgICAvKg0KPj4gKyAgICAgKiBSZW1v
dmUgYWxsIHBvc3NpYmxlIHJlZ2lzdGVyZWQgcmVnaXN0ZXJzIGV4Y2VwdCBoZWFkZXIuDQo+PiAr
ICAgICAqIEhlYWRlciByZWdpc3RlciB3aWxsIGJlIHJlbW92ZWQgaW4gbWFzayBmdW5jdGlvbi4N
Cj4+ICsgICAgICovDQo+PiArICAgIHZwY2lfcmVtb3ZlX3JlZ2lzdGVycyhwZGV2LT52cGNpLCBy
ZWJhcl9vZmZzZXQgKyBQQ0lfUkVCQVJfQ0FQKDApLA0KPj4gKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgUENJX1JFQkFSX0NUUkwobmJhcnMgLSAxKSk7DQo+PiArfQ0KPj4gKw0KPj4gIHN0YXRp
YyBpbnQgY2ZfY2hlY2sgaW5pdF9yZWJhcihzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+ICB7DQo+
PiAgICAgIHVpbnQzMl90IGN0cmw7DQo+PiBAQCAtODAsNyArMTAwLDcgQEAgc3RhdGljIGludCBj
Zl9jaGVjayBpbml0X3JlYmFyKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4gICAgICAgICAgew0K
Pj4gICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICIlcGQgJXBwOiB0b28gYmlnIEJBUiBu
dW1iZXIgJXUgaW4gUkVCQVJfQ1RSTFxuIiwNCj4+ICAgICAgICAgICAgICAgICAgICAgcGRldi0+
ZG9tYWluLCAmcGRldi0+c2JkZiwgaW5kZXgpOw0KPj4gLSAgICAgICAgICAgIGNvbnRpbnVlOw0K
Pj4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPiANCj4gLUUyQklHIG1pZ2h0IGJlIGJl
dHRlciBoZXJlLiAgSW4gZ2VuZXJhbCBJIHRyeSB0byBhdm9pZCB1c2luZyBFSU5WQUwsDQo+IGFz
IGl0J3MgYSBjYXRjaCBhbGwgdGhhdCBtYWtlcyBkaWZmZXJlbnRpYXRpbmcgZXJyb3IgbGF0ZXIg
b24gaGFyZGVyLg0KR290IGl0LCB3aWxsIGNoYW5nZS4NCg0KPiANCj4+ICAgICAgICAgIH0NCj4+
ICANCj4+ICAgICAgICAgIGJhciA9ICZwZGV2LT52cGNpLT5oZWFkZXIuYmFyc1tpbmRleF07DQo+
PiBAQCAtODgsNyArMTA4LDcgQEAgc3RhdGljIGludCBjZl9jaGVjayBpbml0X3JlYmFyKHN0cnVj
dCBwY2lfZGV2ICpwZGV2KQ0KPj4gICAgICAgICAgew0KPj4gICAgICAgICAgICAgIHByaW50ayhY
RU5MT0dfRVJSICIlcGQgJXBwOiBCQVIldSBpcyBub3QgaW4gbWVtb3J5IHNwYWNlXG4iLA0KPj4g
ICAgICAgICAgICAgICAgICAgICBwZGV2LT5kb21haW4sICZwZGV2LT5zYmRmLCBpbmRleCk7DQo+
PiAtICAgICAgICAgICAgY29udGludWU7DQo+PiArICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7
DQo+IA0KPiBNYXliZSAtRURPTSBoZXJlPyAgLUVOWElPIG9yIEVJTyBtaWdodCBhbHNvIGJlIGFw
cHJvcHJpYXRlLg0KV2lsbCBjaGFuZ2UgdG8gLUVOWElPLCBpdCBzZWVtcyBtb3JlIHN1aXRhYmxl
Lg0KVGhhbmtzLg0KDQo+IA0KPiBPdmVyYWxsIGxvb2tzIGdvb2QuDQo+IA0KPiBUaGFua3MsIFJv
Z2VyLg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Fri May 09 05:46:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 05:46:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979782.1366280 (Exim 4.92)
	(envelope-from )
	id 1uDGYp-0002F7-85; Fri, 09 May 2025 05:46:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979782.1366280; Fri, 09 May 2025 05: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 1uDGYp-0002F0-5L; Fri, 09 May 2025 05:46:15 +0000
Received: by outflank-mailman (input) for mailman id 979782;
 Fri, 09 May 2025 05:46:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDGYn-0002Eu-VS
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 05:46:13 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20610.outbound.protection.outlook.com
 [2a01:111:f403:2408::610])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e49092f5-2c98-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 07:46:03 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by IA0PPF6483BC7EA.namprd12.prod.outlook.com
 (2603:10b6:20f:fc04::bcf) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.33; Fri, 9 May
 2025 05:45:59 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8722.020; Fri, 9 May 2025
 05: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" 
X-Inumbo-ID: e49092f5-2c98-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OXk0u0ay5sDz6sZ1BKGXFldl2JJGTaU408hF6g8Zgcx3UK4NBtUYlzuB+GZPHm1oWtI17HDRUCey6msvWKTzBWEoGi4oaGXmXqFR1krhx/a8LZFVIB7eKk+zEZsBOrDjcErbGnJcjIbDXbHrmhkp4uck8mvygmYtUOQzuiuR3vNBJ1AwkuyK17HAOsc38HswOt/qkUTQj2CPCdq3wASyjuk4wG8Pfjf1VdOFGbnxij+bwJ7jYPbzzBXMVAI9/TZu4n6fSeOlfvnrp7dt64b3f8F3tqyeAFdvgbvZBm+l2QvLLXI0qsVh377Rxdi1iR1ISkgUZRGJcjstKEu4acGXTg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=k0eJs5DZ88QhJuWTTVWXJg24qGD9FWw4Jq+krkdRndQ=;
 b=UnFLIXUONlV1797qyFN9VPof3bVRKY21Xx92MSnGIlNEmPMlY5UXy/2cs1WUTIC4dJE7tadM7ovumQDLYHkVbb0N9hWtmMde7uDSlxzd17QC9BouqadlYCMdgsme6vi/GvM6q0iI3RayzpVFjQaEEn5pqi2AB9/gp/UNAHMENW5M99xJEmtmO11yin7rLrI2FdTyHWGERKg295Xpq2Yk0VM8ng2tYPhgXA+yqIAhs7b0EbkCNTAJxEnX6orNApczwdfVic9zNbCNtDZ346uhInjqU9XjtODK7GG/yIB1RNt/tAH0R5pQYDyKSnDS/nlnnv7Sue5e5ER5iCb7SX1pTA==
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=k0eJs5DZ88QhJuWTTVWXJg24qGD9FWw4Jq+krkdRndQ=;
 b=YKcne18Eh5wvWHvfu9lsjGojO+WkrCKecJk8OYZoAUFj9lyrXwtT/1PQO7F/LxEgmwAimuJ4nNYOqpWMOoJLz/e1NjQ1rajvr6OBbmcF93tdDih/D4NTf4a+/Cu5C5DY+i6EGyMoEvYYss8r4s1sW5HQXNiX+rut1as5cKkjWVE=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v3 11/11] vpci/msix: Add function to clean MSIX resources
Thread-Topic: [PATCH v3 11/11] vpci/msix: Add function to clean MSIX resources
Thread-Index: AQHbsoVgBiJKDhaKgU2icFKPtN29BrPInAgAgAHPIQA=
Date: Fri, 9 May 2025 05:45:58 +0000
Message-ID:
 
References: <20250421061903.1542652-1-Jiqian.Chen@amd.com>
 <20250421061903.1542652-12-Jiqian.Chen@amd.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8722.017)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|IA0PPF6483BC7EA:EE_
x-ms-office365-filtering-correlation-id: a3d30d42-d381-42cf-7d93-08dd8ebcc656
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?eHhMRm4wUUpnNkxEcytRTGZaZGNyK2ZXbG5zRndaWUYyZXpTL280Tk1YczVW?=
 =?utf-8?B?aEg2RTZDenc0YzBjTFdGQW5HVnRKVkxPN1FiZ2R0aFM1MWk5WVhmTWoyOG9J?=
 =?utf-8?B?VVErNmxNWWFKT2tkejloL25oY3czRUhFTmI4ZldUSisvZXVySUExSmNHalBo?=
 =?utf-8?B?QzBVY01aeXhxRERJTk1OS2p5ZVVTVHc2Z2pxZ3pGeFVKOUVwRHJzWEM2UGc2?=
 =?utf-8?B?NjVVb2lNa2piakdZTEdkY3VjSFVwT3RiQzJIS3dJTEVBeTcxZHc1S2ZVZFpo?=
 =?utf-8?B?Y3JhbDJ1WS9PWTRTekRHNDA1VjY3TFlhMUZJTTg5SC90d3BQc2d3N09Jd3hm?=
 =?utf-8?B?alMwU0tDM1VBRmNOOXc3SnNnQWhuWnNUZFV0Y3NWcDdXWmFaT29hNHROUjlo?=
 =?utf-8?B?UXlEMkFSUFg0amtJbDNlbDFIV2FuL1RvNmx6RldoK0orcE03citFMmhNWWwy?=
 =?utf-8?B?b0dWRFY1QmlJSFllZjNDL3htSGQxNzEraXZRMFlRNWdTTEtvWXV0TjlUMGtC?=
 =?utf-8?B?VEkraWJyanFEVnkxckZOOEtnSkNmMi8yTmRnZjZZVGVmdUpiaG1LZHN3L0dO?=
 =?utf-8?B?b0kzdzVqMGdJeTgrd0JQZ29kdVJ3YzRDR3JLckg0ckErUW5oc0p5WExIdDFM?=
 =?utf-8?B?SSt1bVJHUHJTZHVCZGUzZnVnZ1FzYjNBbmJOVGtMQnVncDB4SWNUY3pucUxB?=
 =?utf-8?B?bDVlOTVzMDVtM2NuTlBENGgxUHJXZ3Y2TFBuNk8yWGk0TnQ2U2FaQXZIZkoy?=
 =?utf-8?B?SmxrN21HVXVLQnl3RGxNQVlqVVBxWjJoWXRKSGdwVUVBSDVjd0MrekM4Smtr?=
 =?utf-8?B?Z3pBTElhR3JEYTFQN1k3cUlWMzhNVGJCRkQ5MkhWSU4vZHQyeUpvdWxxZyth?=
 =?utf-8?B?NjV3UFpYUGdQT1N3bXF3SlVibkVlZVJmZFo2ZWtkTVkzNUR6U2M4N2JzSCs1?=
 =?utf-8?B?L3hFdmlQVy91d2w0WjF2WlA4UmlqTUNwamtHckw1Z0N4ZENPM2Y2ck85R3M0?=
 =?utf-8?B?TTZxYnE4ZlhtTmhOcXcxTlFsU2xNSXdWcjV1eVY5djRBeWFIbWp5WGJ3Q1NB?=
 =?utf-8?B?czdEK2M1elFmdlpmNU9BS3RQY1p6bG9JR3FGZjJUVDBJenphVEZsUDFHem5l?=
 =?utf-8?B?Rkd3V01semlkbnhWVTFXUnRpamV6U2MxWDF4S1FJWlFkZnJBaGdxNnJkMWZm?=
 =?utf-8?B?YUl3ZWtmaTY2NEtqSVYydGFRM2RkZHAwVVIxY3hOK045SnBNZkd0ZkFCZVM1?=
 =?utf-8?B?UzhKRE1jYTdPRkJRN3hIOGRjNHo3aTBDcklJVDdRR21CcFhhYmVwQzl4em1Q?=
 =?utf-8?B?M2NrMEYzVUlBYkNIQ0FRUTBoSDJSaTRGSlFoczRCYlJtaGdrSml6eE5oYi9G?=
 =?utf-8?B?enJiS01hUGN0RHhXeEdaT05YNENhV09WTUlCTG8rRDJ6Y2xWcDBwV01YNVhF?=
 =?utf-8?B?UEk3WkJIeGVLQVhWNDJPMHpKcWEzenBuTnoyamtVZnVsc0FlbVgwZHFqYS9r?=
 =?utf-8?B?SU0wT2FMV2VsbVhvOXlWckVxVUczVzNVYXFCTDZkNmhEYnk1bk1LTTUzUG1p?=
 =?utf-8?B?clVLVXQzL2V5K1I1emZHNG4wWWM0RnVYRThLYmVJWFNoZGt0ME10MTI4cGxD?=
 =?utf-8?B?QmxVUlpuekxTREo0a0pXWHRXR0dZK1VuaDc3VXI0VzEwcThZd1kvNmRibFBG?=
 =?utf-8?B?UUcwYTJVRUdNU1o1Tmc4b1Z6OEI3Tkg5VnhSV1hXWUFIM085MnpOSUVnRnU2?=
 =?utf-8?B?Z1lvM29QaFk5ZVFaNGZ0allzcWFvRUVrWEpVZ1gwZUQ4cFFWellHcDhVLzA5?=
 =?utf-8?B?UDVNT0hCc05yQU9BMHErYnZSSFhHLy9IbXUxdUVLb0Z2TnM3SkYrVEtCdW9O?=
 =?utf-8?B?VU1mQWorNUFxc29nRVB0b2MyZlRrZC9wMWRqZ1dvVTVNSmNzZ3c4R0Rka1dS?=
 =?utf-8?B?RGdGTmVCSm5jRjV1M1J3L0dWakg3aFJOejVKU3J5dEtTNDZ3REVwNStuVngr?=
 =?utf-8?Q?6HCdbvLu7zE0vmGy6vziu7D/nb3w6s=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?bStldS8yU0g3blBKWFJ1VzU4THQ5anVCNGtHTGFLVmdlbmpyajk5bEZNNkJ0?=
 =?utf-8?B?aGwzbUlBRHEvUzkrWlBZbHhlaXpFdjhZSldEVENVeWxHOUkvWklVdzNjeXo5?=
 =?utf-8?B?cjRLMGFOVlE1cFlORXpXNXgwZGRtMW01WUVvRkJjZXRYSkZCTnBpRkMrLzVX?=
 =?utf-8?B?aDk0eU5LaXVNTUlvU25LNjRrNkpaK0R1cytuVExycGZkQk9mTDZ1OElGOVdJ?=
 =?utf-8?B?V2YwSVZmY2FNTHdqcnduUldxelliSzFaUm5zMGtKUVVoQUZkSjkvNm1zK3ly?=
 =?utf-8?B?QjZHY05oNGt3VkdzdUFCTlRTYTE1SDN6VmFVNXBGT1lnZkwzem0wRGhBQU9r?=
 =?utf-8?B?MDR3QjFDa0lMOUp0b2kzMFRVeEk5L3p5bDJQMVhRVUF3ZDFMcU1CSnZtclFn?=
 =?utf-8?B?bG0zQ3ZZcTZRRmVReStSTkF6YW9HZkhxSGhuaEVTN210Unl0NnhscVJnNng1?=
 =?utf-8?B?bGFIMGYybC82S2ZmZE9zanhmSFMvZk16aWdwSTd3L0psb0pmLytYeU9NNzNu?=
 =?utf-8?B?SlgzRVVhU2RUYS9iZ1BwQXVTSHVtbTVXSjRBaVVQeTdQdnRpRk1wckZYdlJM?=
 =?utf-8?B?djdkMTBhUy9hTmJPUkQyZHZGTE5DRlZLTzNiUlN1NUl5ZjZiaktBVEVmODlZ?=
 =?utf-8?B?MFpPMjJoaW1oNWFwbExWc29jYktZcndVOVZzY3EvM0RLbUlLWWgxUTdXM0Zt?=
 =?utf-8?B?ZkljWUdOb2VMRTlYTWZ6azZLRnl5ZFpydWNiK1Z6dkZDaUFzNUhNa0duMmJU?=
 =?utf-8?B?a1lzWWQ1VzRuQURYRkJhakN6RkFvSU1FbnpSRURMNWwvejhiaEhHWmp2ZEdN?=
 =?utf-8?B?ZWlmMWFPa1VrcklMYUlkNGplSVJWNjdFUGtJbDVRKzB4ODlMRElZZ25PU3VB?=
 =?utf-8?B?d05UVThJUVQxczhJOUNyb1g5RzN6eEdNaHVCZXk2L1FvQ0pEb0VSUGRPOTh0?=
 =?utf-8?B?T1BBS2x3NXExOVM1QkREbDdoK3NIQ1NtOGMzMUVZQ241RVY2bVVtdUYxQXJ1?=
 =?utf-8?B?OURwMXZZQVJTMU1ORTZlUThyNXRNa0Ntc1JPRThua1ZGaktMTlhhZVpUcmx0?=
 =?utf-8?B?TDZ6YURlL2RNc2NUWnZDSjZrb1hYMWdIM2RxQTV0aTZTRmJQWGdGc2dxWjZO?=
 =?utf-8?B?c3BPSUtQNWI1UEZLQ2JOUm1VV2hqQnZUaEkyc1VERGtYbUhpVVpvZHRqdXpq?=
 =?utf-8?B?YUFZUjZsVTROaFJ0ZUkwWkNSdDM5WEhreWVJK2hzZ2lSU2o4KzR0N0xPallL?=
 =?utf-8?B?b1lCY3VyNmYzaEMrTG5hRSswQVJzQk44OVZQdFFJVy8wTkVFeE5QZW5KN0Yy?=
 =?utf-8?B?SWg3NUc3bnM1MFcrQ0E1YjhzcUVWejBmVkpVaktaVEdQTWtMVCtubWpjVEda?=
 =?utf-8?B?S1kvMnc0Wkw1Q1hzRy9yN2x0bzlXNlpwVWQwR0pnVlk3aGF4dC9wN3lzUCtz?=
 =?utf-8?B?MmNnNnZWRlFOV2R4Y2lLcWNDb09POXhVLzVjK283V2RETlR1bitVTXVFK0JG?=
 =?utf-8?B?RkY2akVZSnA3aEVGbjJwUzdNelpYZXBhb3E4L0JQeGNjS04xRkNLMEp6YVpk?=
 =?utf-8?B?MEUvUStQdzhMazdBcC9vQ09EMm5uNXdOLys2SHZZZ0hveUx1WXNBQW5IaE9K?=
 =?utf-8?B?NzNDSVl0Nnp1UVJiOHpWdGdjWnpsbGx6eElRUndEcnpxWUdVYXJNZDk2SVBZ?=
 =?utf-8?B?Nm5aRkpHV211Q01IZEpZWDdZN0VZdDZ6K0szdXh0bE1EZHZkblJybnJ6NDV5?=
 =?utf-8?B?QjU2d3dFNXVHdFhNQUUxWFdkYlRMS0RHTGxicWJucDN1YnpSMVBhckY1aXVj?=
 =?utf-8?B?d2tySzZtbVlaTHpSMlRmTUFRd1haQkxFTk9GZ0tGMkFCcTdtdlFzMVFTMzFR?=
 =?utf-8?B?S2I3WlNYSmVMaTNERStNemhHOElSTTB4MXpwR2ZESGtzRkdoTTgzWEFFcnBJ?=
 =?utf-8?B?N1Q0cXlFbzc0RVY1NGxKVFZBZ2grQk1ZMFZGRG8zRUhoNE1yVE90dzkwQTlv?=
 =?utf-8?B?WWlxbUMybGlOWmpEU3JRWHBLWkpIei9pb00wOE5VeWQxRlBaLzd5MUt3Qyty?=
 =?utf-8?B?MVYxZXhTcnRKVDc5dDRiVnltSTArM3JpS2lSaUJhZGdEZEpDOWIrZ2t3bVJi?=
 =?utf-8?Q?0AJA=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <01411F09E0568340BDAB9CCA473C70B3@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a3d30d42-d381-42cf-7d93-08dd8ebcc656
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2025 05:45:58.8776
 (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: XUqcQ0ZJlvOyWN/QgG+DsOJGz3YmF1ByNQNfQeVhM0efwQbkOUKuyrizWEMofqtdfpxeVKFn5WZpjJXxYIhxuw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF6483BC7EA

T24gMjAyNS81LzggMTg6MDQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIE1vbiwgQXBy
IDIxLCAyMDI1IGF0IDAyOjE5OjAzUE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gV2hl
biBpbml0X21zaXgoKSBmYWlscywgaXQgbmVlZHMgdG8gY2xlYW4gYWxsIE1TSVggcmVzb3VyY2Vz
Lg0KPj4gU28sIGFkZCBhIG5ldyBmdW5jdGlvbiB0byBkbyB0aGF0Lg0KPj4NCj4+IFNpZ25lZC1v
ZmYtYnk6IEppcWlhbiBDaGVuIDxKaXFpYW4uQ2hlbkBhbWQuY29tPg0KPj4gLS0tDQo+PiBjYzog
IlJvZ2VyIFBhdSBNb25uw6kiIDxyb2dlci5wYXVAY2l0cml4LmNvbT4NCj4+IC0tLQ0KPj4gdjIt
PnYzIGNoYW5nZXM6DQo+PiAqIFJlbW92ZSB1bm5lY2Vzc2FyeSBjbGVhbiBvcGVyYXRpb25zIGlu
IGZpbmlfbXNpeCgpLg0KPj4NCj4+IHYxLT52MiBjaGFuZ2VzOg0KPj4gbmV3IHBhdGNoLg0KPj4N
Cj4+IEJlc3QgcmVnYXJkcywNCj4+IEppcWlhbiBDaGVuLg0KPj4gLS0tDQo+PiAgeGVuL2RyaXZl
cnMvdnBjaS9tc2l4LmMgfCAyMSArKysrKysrKysrKysrKysrKysrKy0NCj4+ICAxIGZpbGUgY2hh
bmdlZCwgMjAgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPj4NCj4+IGRpZmYgLS1naXQg
YS94ZW4vZHJpdmVycy92cGNpL21zaXguYyBiL3hlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jDQo+PiBp
bmRleCAwMjI4ZmZkOWZkYTkuLmUzMjJjMjYwZjZiYyAxMDA2NDQNCj4+IC0tLSBhL3hlbi9kcml2
ZXJzL3ZwY2kvbXNpeC5jDQo+PiArKysgYi94ZW4vZHJpdmVycy92cGNpL21zaXguYw0KPj4gQEAg
LTcwMyw2ICs3MDMsMjUgQEAgaW50IHZwY2lfbWFrZV9tc2l4X2hvbGUoY29uc3Qgc3RydWN0IHBj
aV9kZXYgKnBkZXYpDQo+PiAgICAgIHJldHVybiAwOw0KPj4gIH0NCj4+ICANCj4+ICtzdGF0aWMg
dm9pZCBmaW5pX21zaXgoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiArew0KPj4gKyAgICBzdHJ1
Y3QgdnBjaSAqdnBjaSA9IHBkZXYtPnZwY2k7DQo+PiArICAgIHVuc2lnbmVkIGludCBtc2l4X3Bv
cyA9IHBkZXYtPm1zaXhfcG9zOw0KPj4gKw0KPj4gKyAgICBpZiAoICFtc2l4X3BvcyB8fCAhdnBj
aS0+bXNpeCApDQo+IA0KPiBUaGF0J3Mgbm90IGZ1bGx5IGNvcnJlY3QgaGVyZS4gIFNlZSBob3cg
aW4gaW5pdF9tc2l4KCkgdnBjaS0+bXNpeCBpcw0KPiBzZXQgYXQgdGhlIHRhaWwgb2YgdGhlIGZ1
bmN0aW9uLCBhZnRlciBoYXZpbmcgYWRkZWQgdGhlIHJlZ2lzdGVyDQo+IGhhbmRsZXJzLg0KVGhh
bmtzISBZb3UgYXJlIG1vcmUgbWV0aWN1bG91cy4gSSBkaWRuJ3Qgbm90aWNlIHRoYXQuDQpXaWxs
IGNoYW5nZSBpbiBuZXh0IHZlcnNpb24uDQoNCj4gDQo+IEkgdGhpbmsgeW91IGluc3RlYWQgd2Fu
dDoNCj4gDQo+IGlmICggIW1zaXhfcG9zICkNCj4gICAgIHJldHVybjsNCj4gDQo+IHZwY2lfcmVt
b3ZlX3JlZ2lzdGVycyh2cGNpLCBtc2l4X2NvbnRyb2xfcmVnKG1zaXhfcG9zKSwgMik7DQo+IA0K
PiBpZiAoICEodnBjaS0+bXNpeCApDQo+ICAgICByZXR1cm47DQo+IA0KPiBsaXN0X2RlbCgmdnBj
aS0+bXNpeC0+bmV4dCk7DQo+IC4uLg0KPiANCj4+ICsgICAgICAgIHJldHVybjsNCj4+ICsNCj4+
ICsgICAgbGlzdF9kZWwoJnZwY2ktPm1zaXgtPm5leHQpOw0KPj4gKw0KPj4gKyAgICBmb3IgKCB1
bnNpZ25lZCBpbnQgaSA9IDA7IGkgPCBBUlJBWV9TSVpFKHZwY2ktPm1zaXgtPnRhYmxlKTsgaSsr
ICkNCj4+ICsgICAgICAgIGlmICggdnBjaS0+bXNpeC0+dGFibGVbaV0gKQ0KPj4gKyAgICAgICAg
ICAgIGlvdW5tYXAodnBjaS0+bXNpeC0+dGFibGVbaV0pOw0KPj4gKw0KPiANCj4gU2luY2UgeW91
IGhhdmUgYWRkZWQgdG8gYWxsIHByZXZpb3VzIGNsZWFudXAgZnVuY3Rpb25zLCBkbyB5b3UgYWxz
bw0KPiBuZWVkIGEgY29tbWVudCBoZXJlIHRvIG1lbnRpb24gdGhlIGNhcGFiaWxpdHkgaGVhZGVy
IGlzIG5vdCBoYW5kbGVkPw0KPiANCj4gVEJIIEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoYXQncyBy
ZWxldmFudCBpbiB0aGUgY29udGV4dCBoZXJlIChhbmQNCj4gb3RoZXIgY2xlYW51cCBmdW5jdGlv
bnMpLCBhcyB0aGUgY2FwYWJpbGl0eSBoZWFkZXIgdHJhcHMgYXJlIG5vdCBhZGRlZA0KPiBieSB0
aGUgUkVHSVNURVJfVlBDSV97TEVHQUNZLEVYVEVOREVEfV9DQVAoKSBpbml0IGhvb2tzIGVpdGhl
ciwgc28gaXQNCj4gd291bGQgc2VlbSBhc3ltbWV0cmljIGZvciB0aGUgY2xlYW51cCBob29rIHRv
IGF0dGVtcHQgdG8gcmVtb3ZlIHRob3NlDQo+IGluIHRoZSBmaXJzdCBwbGFjZS4NCkluZGVlZCwg
eW91IGFyZSByaWdodC4NCkZvciBzeW1tZXRyeSBjb25zaXN0ZW5jeSwgSSBzaG91bGQgbm90IGhh
dmUgdG8gYWRkIHRoZXNlIGNvbW1lbnRzLg0KSSB3aWxsIHJlbW92ZSB0aGVtIGZvciBNU0kgYW5k
IFJlYmFyIGluIG5leHQgdmVyc2lvbi4NCg0KPiANCj4+ICsgICAgdnBjaV9yZW1vdmVfcmVnaXN0
ZXJzKHZwY2ksIG1zaXhfY29udHJvbF9yZWcobXNpeF9wb3MpLCAyKTsNCj4+ICsgICAgeGZyZWUo
dnBjaS0+bXNpeCk7DQo+PiArICAgIHZwY2ktPm1zaXggPSBOVUxMOw0KPiANCj4gWEZSRUUoKTsN
Cj4gDQo+IFRoYW5rcywgUm9nZXIuDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4u
DQo=


From xen-devel-bounces@lists.xenproject.org Fri May 09 06:37:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 06:37:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979799.1366295 (Exim 4.92)
	(envelope-from )
	id 1uDHM8-0000Fs-3o; Fri, 09 May 2025 06:37:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979799.1366295; Fri, 09 May 2025 06:37:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDHM8-0000Fl-0p; Fri, 09 May 2025 06:37:12 +0000
Received: by outflank-mailman (input) for mailman id 979799;
 Fri, 09 May 2025 06:37:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDHM6-0000Di-Av
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 06:37:10 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20610.outbound.protection.outlook.com
 [2a01:111:f403:2413::610])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 03f044e8-2ca0-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 08:37:02 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH2PR12MB4184.namprd12.prod.outlook.com (2603:10b6:610:a7::9) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8722.24; Fri, 9 May 2025 06:36:53 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Fri, 9 May 2025
 06:36: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" 
X-Inumbo-ID: 03f044e8-2ca0-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=W2q8bOd3sGP1ZVVwaXNA8baht9aiim6Yr7PtGI0N2wXG8BuqNrTAWVKVckC/jPAc3PDDEkjEP1GY8xCvPraU7VjFfZvT3Vn9jDa/HdU3Nq0irAZmNRpTGXSvFJeu9VWgJczjtC6NK5ztSBAxKNcPI91PxA7SDS//IlYHuLRO1lexZsWmR51jAXApa+fkR4a0cfZn6+oZ4+dh9e39827Ugzvbt3KZU9AlDjQk31z8mgcX2SQwuHemlZDmXb1x5n4G1bS/iaSLRq+5pxnGJRn/Wu2gggyOhljGk6/ae/d/L7kZ/coneGDtgmiWX8S6mnsDHllI8o/f72ebMvp3ff78Pw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hd10w4jlfwI4deCty2vaPhalV31ZNZ5V6MfJegapS/o=;
 b=UcPrKdKfHw67xHC1XywGWKxG5b5JszedhZpn9muYSJ+UiTbLU/SZeO8X4mkOERs4O5hCUF5lzdjx0xSqWiRZhXHWCji8riMDd4xIs47gxjAQTFStdpJECsguxcQ1LLSBwQc6yjlVq1ngML+EnZ9DWKtZAygmXytgxVfjofZ3RWXWQwU9evKL7rPYcJsnOwjRJ3LbsrgeoYan2LMPKZn8JdPWu5LeXrtgyPRR1Xu33XtY5y/0v4oGXFNjIs/8gk0F5vZefNXCVqhILq2xhTy5myZ6lBjpN4YdCdCjWK4p6le2dX745zai+alOsODHpDUCOxdz9JabpktUZa/o3nwFfA==
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=hd10w4jlfwI4deCty2vaPhalV31ZNZ5V6MfJegapS/o=;
 b=L86OqjEci9e9NsQgWMP68vHfLfjrL8YjL3uBo+HtvQwEhwv50eCritmb+eiPOK1k1Gp1qu1z9Lk12mlLbBT20PlwYct6ji4fGKfMl6clCtGNcXJVX6R5ETxL4MSMDmBnP45WPlw78hP8lweK7HIyMtIkmpJoGhGB1qyWugB9B24=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Anthony PERARD
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 12/15] tools/xenpm: Print CPPC parameters for amd-cppc
 driver
Thread-Topic: [PATCH v4 12/15] tools/xenpm: Print CPPC parameters for amd-cppc
 driver
Thread-Index: AQHbrRCuBHJz/5ZpqUqHhc0gdq6hGrO8VLYAgA1zbxA=
Date: Fri, 9 May 2025 06:36:53 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-13-Penny.Zheng@amd.com>
 <63b3b016-551c-4201-a3b3-db19b27ea649@suse.com>
In-Reply-To: <63b3b016-551c-4201-a3b3-db19b27ea649@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=60030911-e914-41fa-8d24-07a684a6c104;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-09T06:36:45Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|CH2PR12MB4184:EE_
x-ms-office365-filtering-correlation-id: 9542a5b7-3408-458b-b2a2-08dd8ec3e321
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?cVc4SU1zdjUzOFFmMWFCRFMrcE56QUZEN1MrNzZNZWQxNWgrZE51MHBJRit6?=
 =?utf-8?B?anlLQWpRK0NlN2NDQlFPSEFvaXJVUURlOGduTnB1dnZEOHRXWUF5TE1wdU95?=
 =?utf-8?B?Y0h1RFZRQ0h1TytPZERjeW9BQlVteVRaZ2VUamlBVDQxM1JFQmVhWGRuMnZ0?=
 =?utf-8?B?N1ErbC93eXBHcFlFeE51dUExR2hqazZORHl0RnVMbkdVMk9CblBHQjNEUnhp?=
 =?utf-8?B?enZDNXF3N21uUlpjODN0NWFOdjhTY2pVY2hFVzhSUERrRmR1bjhIa210aTVR?=
 =?utf-8?B?WGVIZy9oa05GVktVazI3b1JaSzdKUDFyTGN2KzVoZHFUUUlRQ3p5WDVkeDB1?=
 =?utf-8?B?SmR4MzVHMEt1TU04WW12WFA5YmlqekF1VXVtbDJuUmhGWlRKVDNiRG5vd0cy?=
 =?utf-8?B?emhKMXRRUVZTTzdGTGY3QzFyMVpCY29WWi9iYUxKVmVoSloycjk4Mm0xUU5l?=
 =?utf-8?B?Y0hWSE1VeTVCZUlYK2FhN2d3UHdjTFFMNG15ZlBqZjl6V3ZGaE5ESmtCKzhW?=
 =?utf-8?B?KzhsYms1aHBsQVFENGhSTE5xS0t2TmxyZ3ErcU5TSFFUL3BnbTJQUjQ2ZnVq?=
 =?utf-8?B?WHArQmRUWmQvaFhMMDl0RTdyV1pYdFBFRUpoaStGKzNzZDNCQ2krMUJSMlV3?=
 =?utf-8?B?U3RjWXJJbGFhaU42aGhRazI1MjQvc2o0aEx4K1NHaFNYQzNRY1pNZG5keEI2?=
 =?utf-8?B?QUJWVUYyWVEzUytENHF6TVJkdkxlY2RDekN3MSs2QW5iS2szV0pWUSt2NFF3?=
 =?utf-8?B?cDJiUyt4dTVvMUdCSVRRUWNDVlFsZzBHRkZNSHVNeGYwbUJadXRzckM5Z2RJ?=
 =?utf-8?B?Z0xyc2U3ekxJSXR0UTg1VmdCR3hkUjBWYWl3a2dONXBrTTZyTDlDM1l4VHg1?=
 =?utf-8?B?UWFkSFpPS0VLTHh3UkZ1NTVFY3VpditBNGxvY1NRM3RTa3UxVjNQUWxWY2ZK?=
 =?utf-8?B?RWh6cmFqNXNzSTZsVjVBTG1jNXR2cmVVclJtNEdDay9wbndBL01VUjNrRnFG?=
 =?utf-8?B?RURlMm03YXhSUHhoaVYvSUlLNWJOYjl0bmdiZlFlSmZJUmF3RFViT2RMRVZJ?=
 =?utf-8?B?VUJiSmFlWlVrY3JrVlYyckVjU3dVOWcxS1hDS2h3UXp0Y200WWQ2WUQvOHp3?=
 =?utf-8?B?R2hDVUNrdFFDRjNhL1RYbGlVa0NUSDhubUx2VDV6cHkzNGV3Z1FiemJPb2Qz?=
 =?utf-8?B?cHBUVlVZZW9GYkJGaXAyczc1Q0xFdEZOSDRJNStabk1vUTkzcVhQcEhlaVg5?=
 =?utf-8?B?QkY2Y1BuaHh1UGFzWHl5UnNBbFBBMUVOTEZtaDBTU0wyV3BzMHNSbE5ueE9h?=
 =?utf-8?B?U3IzeXFSWnM4cjZUdlU1Rmk4QTJ0OXVhVElqVVZVZDgwdzFCdS8zSzY4YTJ1?=
 =?utf-8?B?OFV4MEQxTUdFdGlCRFRORG9LZzlkOXVoanlFVWs3SThGdkJHbEo3M3FpbFI2?=
 =?utf-8?B?Nkh0bTBXUWZnL0JzaWUxQm9wY0l4TmU0QU1ERy92VmFiT0xpbklFUGJScEZj?=
 =?utf-8?B?VVVLVWJzdWQ0aWpCdy9ydFJyVEpna21nWGdOdENuQmdZSjZodnQ2M3YxOEx5?=
 =?utf-8?B?di9qYlBPSlpkdXBhbzRSaTFHTlljODBnYitpNE5xZ2k5TkJyWS9kRUVQZENv?=
 =?utf-8?B?N2oyTjVnRG4veVdCTGJRa3N4MG9BVkdYcUw3VjJnVENzdkI5OHJWNm9palNF?=
 =?utf-8?B?Ukw1SDFqOEY3NUVXd2NnQmUvNGxQcUtzZURLK3RNaG9GalFPNkp1YnRUMURn?=
 =?utf-8?B?K3lYcVV2d0FkMW9SWHk4eVJXd2tVa2oxTkpQei82L3FsVTBOenJTa0tYb2g3?=
 =?utf-8?B?TGlPRzJGU0JIeXU1UUJiY1BaOHlUZ0IzUnQ0cjAwc3B3amxGTUg2TldZcXFZ?=
 =?utf-8?B?QnpmRmlFUjhPZGRmSzZHY0Z6TUtFOUxtQk13cjdwRmNpdjNZOWc0eW9PQXow?=
 =?utf-8?B?U2hRbFF0dlNqOHdLNnBSSk1wREp5K0txelY3eVJZeHZGcDR0eXA2RXp1SGxq?=
 =?utf-8?Q?IYAGCdpE6GCTx5CPTw6Zn6lCiiC1a8=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VmNmS3ovRmJ4ZTRDRm9tVU9wMCtxaU8zUUo2cWpKbEpkNnYwY3B5VGR4NVE0?=
 =?utf-8?B?UE15NmV1M1hDMFNkUFVmbU9kS09wR0xCMkJFUWZnT055K0hCSjRwdExEUnM3?=
 =?utf-8?B?UlRhdWRENnJNcHhudUF3NDUyT1BWVW5DSHk3YnZOa3VHMThJdUNLT1dVOXNT?=
 =?utf-8?B?bGpaTEF1TFJxWnB4b0JaQnFUcDRVeTNFNjdtTXNDd0hiODhRdndSV2JSVnhH?=
 =?utf-8?B?bkhJVHdEbDlWalZuY3dPWWg2bGpFNHkzM1dvTThITm5Ua2ZmMVk2Z0twVEha?=
 =?utf-8?B?UTBLVFhLRWIvZEZkajRQZFB1VDhvc0drMk5JYXhScVNtY2pDNXQrenRwOFBN?=
 =?utf-8?B?bnpCN2lGdlpucTdMQ1lmOXNvY013NlFFSjhiR0E1ZnhYMEFZMlkzNjY4b2Z4?=
 =?utf-8?B?MndUNjkyMmsxSWNJdlNYWSt3c09rMitSMGRYSitBNVAvRnBCYzJoaU1pWXFI?=
 =?utf-8?B?NENEWWdsVGg3d2JtTWJYQkRRODFDYk9TU2xtVytPZE5KdjFaN2hQSU1CaExp?=
 =?utf-8?B?eUw5eWp6L2pXZ3o0RzFHVXFFZUxTOG5kYlhEUVU4T0Nib0JZMm1OUnVqc0lw?=
 =?utf-8?B?SUYxd3ZNYllVS1BOMUZYRUx2aE5vVjBubzFIUVRpSzJDUENHU3hQaEFxVllt?=
 =?utf-8?B?RlU1Q29hbm1pSkZCVnN4WHV2Y29vSDJKVG5NcjNTN1pPci95czdUdUxMeUht?=
 =?utf-8?B?TU5aSVo5OExXZXV3MzcwcmJyUjhsYlRjZ0NvSWQ0aGo1c0M0c2gvYmtMcndO?=
 =?utf-8?B?TXhSWHlMMWtCQTQzRDFlNk5Zam83V1kyb1BqU2lHVGhxaVA1djduREZwQncv?=
 =?utf-8?B?aGp0R3NGYVViOVNadVVjS1FJa29GUk9kQ3h6WHVDOG81U2JzaG9md21VZjNh?=
 =?utf-8?B?Z01QQkpiUEZYa1MzZDVYUVpqSTNoNHlBamJjRDZLSzNtOFQ3aEhsK2JGcUQy?=
 =?utf-8?B?d3Y1MHRPdHNPbUhFR0h3YkIwRVcrOGlTRU1sa2M3NWxwVjBHYkxoeDg0N2py?=
 =?utf-8?B?eDVITUxRYlEzYzEvM004YWlyWGhBL0EyaDBSdDF2RU1qNEU1aGhWVnBOUEZG?=
 =?utf-8?B?NU1NR05TWnlHWTNtVmVXdXJQQlZNVGEyQVd6ZnlzSnhsTURYNElxZGhManVy?=
 =?utf-8?B?NG9oSXllb3NyMVJBSE5mN2FucjVLWHlLZlFJTHYrRGM2OXA0b0kyb2VwUStJ?=
 =?utf-8?B?MkEzai9RRGQ2YXpNUktIWWgvSjM2OC9wdE04SjluYnpPY3E4WHh1QXZSRWQ4?=
 =?utf-8?B?OFVtVVJMRmorY3B0K3plcHhDakF0TnpTTitMR3k3RXN3RWJiSStINlVRSjI1?=
 =?utf-8?B?WXo5ajlhVFFwNEVxWXNZa2R3aWlsM2ZXc1RRSnVBa2FxeStaQnpGaGFnSDRV?=
 =?utf-8?B?bVVrWitmNnNuYjROMjJabHZybzN6M01XdEhpaTY1N2J0akI2V2gzdG02SFBw?=
 =?utf-8?B?Y0dkUm91NFhpV3NNWFQrOEVsMmxmSGpJRFlHZSswb01CWmdkV0t4bk1vcFhY?=
 =?utf-8?B?K1VFZU9PZU9yL1cvVm42alU0aTFPaVJWdmsxWUNiSTF3aThBenJWL1dyeDVP?=
 =?utf-8?B?VGJvOURycWEzaDdOclk2TUs5ZVQzN0dJL1JCTFNXNnZNZU94anVMK1ViQWR1?=
 =?utf-8?B?SitDN0ZvalhoS1hqbzRlblRadzV2RzNDRGFibUpBVmlJMGpLZ1pMVXY3WFJZ?=
 =?utf-8?B?ZDdoc1R1TlVyMllBYzBpYktxVEQyVHNnWkpEMDQ2b1diOXQrMkhKTFN5Sys4?=
 =?utf-8?B?cUloT3VzOXV2M3hzRk5sRzJmWUxQSkxFSGtrQUo4UzFUU01VNDNDU1c2Z3VP?=
 =?utf-8?B?WkNBQWNoOUZzd2xlSjlvTFEyZ0EvaG1NMDJXbG5vanpWanoxckQxNVBxcFVy?=
 =?utf-8?B?Z25sQSs1ZFN0elUzVDdEOGF2aTIzN0VTQWlkS1llaGxKNFBsVTU5UkYzU2F4?=
 =?utf-8?B?NWZCSHR2ZUgvUzNET2kxS3hSMTNqZ3d4RW4za3ZpdjFhK2J0dVNXNW9CNk5E?=
 =?utf-8?B?My9Ebk8wRWVZamgwcFRFYW1Od0hFK003dGFudnFXSHhVVGZXQjZQNU5jNTJv?=
 =?utf-8?B?eW9XcFpIWWFES3EzemhoZTZFMjZNT2J5eDJJQ1RSaGIyVjB0TGYzQkpYZHNK?=
 =?utf-8?Q?F4VU=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9542a5b7-3408-458b-b2a2-08dd8ec3e321
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2025 06:36:53.6272
 (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: absYz3HT1JJUUV8U4pZ7erfhFI7ThKBhnKZfqtvCX79iE1M45Wgsep6hyH7GqB8PkAIFQbatI8dEuOo1sBvyzw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4184

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmls
IDMwLCAyMDI1IDk6NTUgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNv
bT4NCj4gQ2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW50aG9ueSBQRVJBUkQN
Cj4gPGFudGhvbnkucGVyYXJkQHZhdGVzLnRlY2g+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVj
dC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NCAxMi8xNV0gdG9vbHMveGVucG06IFByaW50
IENQUEMgcGFyYW1ldGVycyBmb3IgYW1kLWNwcGMNCj4gZHJpdmVyDQo+DQo+IE9uIDE0LjA0LjIw
MjUgMDk6NDAsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiA+IEhXUCwgYW1kLWNwcGMsIGFtZC1jcHBj
LWVwcCBhcmUgYWxsIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBBQ1BJIENQUEMNCj4gPiAoQ29sbGFi
b3JhdGl2ZSBQcm9jZXNzb3IgUGVyZm9ybWFjZSBDb250cm9sKSwgc28gd2UgaW50cm9kdWNlDQo+
ID4gY3BwY19tb2RlIGZsYWcgdG8gcHJpbnQgQ1BQQy1yZWxhdGVkIHBhcmEuDQo+ID4NCj4gPiBB
bmQgSFdQIGFuZCBhbWQtY3BwYy1lcHAgYXJlIGJvdGggZ292ZXJub3ItbGVzcyBkcml2ZXIsIHNv
IHdlDQo+ID4gaW50cm9kdWNlIGh3X2F1dG8gZmxhZyB0byBieXBhc3MgZ292ZXJub3ItcmVsYXRl
ZCBwcmludC4NCj4NCj4gQnV0IGluIHRoZSBFUFAgZHJpdmVyIHlvdSB1c2UgdGhlIGluZm9ybWF0
aW9uIHdoaWNoIGdvdmVybm9yIGlzIGFjdGl2ZS4NCj4NCg0KV2Ugd2FudCB0byBoYXZlIGEgb25l
LW9uZSBtYXBwaW5nIGJldHdlZW4gZ292ZXJub3IgYW5kIGVwcCB2YWx1ZSwgc3VjaCBhcywNCklm
IHVzZXJzIGNob29zZSBwZXJmb3JtYW5jZSBnb3Zlcm5vciwgbm8gbWF0dGVyIHZpYSAieGVucG0i
IG9yIGNtZGxpbmUsIHVzZXJzIHdhbnQgbWF4aW11bSBwZXJmb3JtYW5jZSwNCldlIHNldCBlcHAg
d2l0aCAwIHRvIG1lZXQgdGhlIGV4cGVjdGF0aW9uLg0KQW5kIGlmIHVzZXJzIGNob29zZSBwb3dl
cnNhdmUgZ292ZXJub3IsIHVzZXJzIHdhbnQgdGhlIGxlYXN0IHBvd2VyIGNvbnN1bXB0aW9uLCB0
aGVuIHdlIHNoYWxsIHNldA0KZXBwIHdpdGggMjU1IHRvIG1lZXQgdGhlIGV4cGVjdGF0aW9uLg0K
T25kZW1hbmQgaXMgYSB0cmlja3kgcGFydCwgaG1tbW0sIEkgZG9uJ3Qga25vdyB3aGljaCB2YWx1
ZSBpcyBzdWl0YWJsZSBmb3IgaXQsIHRoZSBtZWRpdW0gb25lPyBTbyBJIG5lZ2xlY3QgaXQgaW4g
dGhlIGZpcnN0IHBsYWNlDQpJJ2xsIGFkZCBhYm92ZSBleHBsYW5hdGlvbiBpbiBjb21taXQgd2hp
Y2ggaW50cm9kdWNlcyBDUFVGUkVRX1BPTElDWV9QT1dFUlNBVkUvUEVSRk9STUFOQ0UNCg0KPiA+
IC0tLSBhL3Rvb2xzL21pc2MveGVucG0uYw0KPiA+ICsrKyBiL3Rvb2xzL21pc2MveGVucG0uYw0K
PiA+IEBAIC03OTAsOSArNzkwLDE4IEBAIHN0YXRpYyB1bnNpZ25lZCBpbnQNCj4gPiBjYWxjdWxh
dGVfYWN0aXZpdHlfd2luZG93KGNvbnN0IHhjX2NwcGNfcGFyYV90ICpjcHBjLA0KPiA+ICAvKiBw
cmludCBvdXQgcGFyYW1ldGVycyBhYm91dCBjcHUgZnJlcXVlbmN5ICovICBzdGF0aWMgdm9pZA0K
PiA+IHByaW50X2NwdWZyZXFfcGFyYShpbnQgY3B1aWQsIHN0cnVjdCB4Y19nZXRfY3B1ZnJlcV9w
YXJhICpwX2NwdWZyZXEpDQo+ID4gew0KPiA+IC0gICAgYm9vbCBod3AgPSBzdHJjbXAocF9jcHVm
cmVxLT5zY2FsaW5nX2RyaXZlciwgWEVOX0hXUF9EUklWRVJfTkFNRSkNCj4gPT0gMDsNCj4gPiAr
ICAgIGJvb2wgY3BwY19tb2RlID0gZmFsc2UsIGh3X2F1dG8gPSBmYWxzZTsNCj4gPiAgICAgIGlu
dCBpOw0KPiA+DQo+ID4gKyAgICBpZiAoICFzdHJjbXAocF9jcHVmcmVxLT5zY2FsaW5nX2RyaXZl
ciwgWEVOX0hXUF9EUklWRVJfTkFNRSkgfHwNCj4gPiArICAgICAgICAgIXN0cmNtcChwX2NwdWZy
ZXEtPnNjYWxpbmdfZHJpdmVyLCBYRU5fQU1EX0NQUENfRFJJVkVSX05BTUUpIHx8DQo+ID4gKyAg
ICAgICAgICFzdHJjbXAocF9jcHVmcmVxLT5zY2FsaW5nX2RyaXZlciwNCj4gWEVOX0FNRF9DUFBD
X0VQUF9EUklWRVJfTkFNRSkgKQ0KPiA+ICsgICAgICAgIGNwcGNfbW9kZSA9IHRydWU7DQo+ID4g
Kw0KPiA+ICsgICAgaWYgKCAhc3RyY21wKHBfY3B1ZnJlcS0+c2NhbGluZ19kcml2ZXIsIFhFTl9I
V1BfRFJJVkVSX05BTUUpIHx8DQo+ID4gKyAgICAgICAgICFzdHJjbXAocF9jcHVmcmVxLT5zY2Fs
aW5nX2RyaXZlciwNCj4gWEVOX0FNRF9DUFBDX0VQUF9EUklWRVJfTkFNRSkgKQ0KPiA+ICsgICAg
ICAgIGh3X2F1dG8gPSB0cnVlOw0KPg0KPiBQbGVhc2UgYXZvaWQgZG9pbmcgdGhlIHNhbWUgc3Ry
Y21wKClzIHR3aWNlLiBUaGVyZSBhcmUgc2V2ZXJhbCB3YXlzIGhvdyB0bywgc28NCj4gSSdtIG5v
dCBnb2luZyB0byBtYWtlIGEgcGFydGljdWxhciBzdWdnZXN0aW9uLg0KPg0KDQpNYXliZSB3ZSBz
aGFsbCB1c2Ugc3dpdGNoLWNhc2UoKSB0byByZXBsYWNlIHRoZSBzYW1lIHN0cmNtcCgpcw0KU2lu
Y2UgaXQncyBub3QgZWFzeSB0byBzd2l0Y2gtY2FzZSgpIHN0cmluZyB2YWx1ZSwgSSBoYWQgYSBk
cmFmdCBpZGVhIHRvIGluY2x1ZGUgYW4gbmV3IGVudHJ5IGluICJzdHJ1Y3QgeGVuX2NwcGNfcGFy
YSIsDQpTZWU6DQpgYGANCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9wdWJsaWMvc3lzY3RsLmgg
Yi94ZW4vaW5jbHVkZS9wdWJsaWMvc3lzY3RsLmgNCmluZGV4IGZhNDMxZmQ5ODMuLmI4NzJmMWI2
NmEgMTAwNjQ0DQotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvc3lzY3RsLmgNCisrKyBiL3hlbi9p
bmNsdWRlL3B1YmxpYy9zeXNjdGwuaA0KQEAgLTMwOCw2ICszMDgsMTAgQEAgc3RydWN0IHhlbl9v
bmRlbWFuZCB7DQoNCiBzdHJ1Y3QgeGVuX2NwcGNfcGFyYSB7DQogICAgIC8qIE9VVCAqLw0KKyNk
ZWZpbmUgWEVOX1NZU0NUTF9DUFBDX1ZFTkRPUl9IV1AgICAgICAxDQorI2RlZmluZSBYRU5fU1lT
Q1RMX0NQUENfVkVORE9SX0FNRCAgICAgIDINCisjZGVmaW5lIFhFTl9TWVNDVExfQ1BQQ19WRU5E
T1JfQU1EX0VQUCAgMw0KKyAgICB1aW50OF90IHZlbmRvcjsNCiAgICAgLyogYWN0aXZpdHlfd2lu
ZG93IHN1cHBvcnRlZCBpZiBzZXQgKi8NCiAjZGVmaW5lIFhFTl9TWVNDVExfQ1BQQ19GRUFUX0FD
VF9XSU5ET1cgICgxIDw8IDApDQogICAgIHVpbnQzMl90IGZlYXR1cmVzOyAvKiBiaXQgZmxhZ3Mg
Zm9yIGZlYXR1cmVzICovDQoNCmBgYA0KQSBuZXcgdmVuZG9yIGZpbGVkIGluIHN0cnVjdCB4ZW5f
Y3BwY19wYXJhIGNvdWxkIGhlbHAgdXMgZGlmZmVyIHRoZSB1bmRlcmx5aW5nIGltcGxlbWVudGF0
aW9uLg0KT3IgYW55IGJldHRlciBzdWdnZXN0aW9ucz8NCg0KPiA+IEBAIC04MDAsNyArODA5LDcg
QEAgc3RhdGljIHZvaWQgcHJpbnRfY3B1ZnJlcV9wYXJhKGludCBjcHVpZCwgc3RydWN0DQo+IHhj
X2dldF9jcHVmcmVxX3BhcmEgKnBfY3B1ZnJlcSkNCj4gPiAgICAgICAgICBwcmludGYoIiAlZCIs
IHBfY3B1ZnJlcS0+YWZmZWN0ZWRfY3B1c1tpXSk7DQo+ID4gICAgICBwcmludGYoIlxuIik7DQo+
ID4NCj4gPiAtICAgIGlmICggaHdwICkNCj4gPiArICAgIGlmICggaHdfYXV0byApDQo+ID4gICAg
ICAgICAgcHJpbnRmKCJjcHVpbmZvIGZyZXF1ZW5jeSAgICA6IGJhc2UgWyUiUFJJdTMyIl0gbWF4
IFslIlBSSXUzMiJdXG4iLA0KPiA+ICAgICAgICAgICAgICAgICBwX2NwdWZyZXEtPmNwdWluZm9f
bWluX2ZyZXEsDQo+ID4gICAgICAgICAgICAgICAgIHBfY3B1ZnJlcS0+Y3B1aW5mb19tYXhfZnJl
cSk7DQo+ID4gLS0tIGEveGVuL2RyaXZlcnMvYWNwaS9wbXN0YXQuYw0KPiA+ICsrKyBiL3hlbi9k
cml2ZXJzL2FjcGkvcG1zdGF0LmMNCj4gPiBAQCAtMjAxLDcgKzIwMSw3IEBAIHN0YXRpYyBpbnQg
Z2V0X2NwdWZyZXFfcGFyYShzdHJ1Y3QgeGVuX3N5c2N0bF9wbV9vcA0KPiAqb3ApDQo+ID4gICAg
ICBwbXB0ID0gcHJvY2Vzc29yX3BtaW5mb1tvcC0+Y3B1aWRdOw0KPiA+ICAgICAgcG9saWN5ID0g
cGVyX2NwdShjcHVmcmVxX2NwdV9wb2xpY3ksIG9wLT5jcHVpZCk7DQo+ID4NCj4gPiAtICAgIGlm
ICggIXBtcHQgfHwgIXBtcHQtPnBlcmYuc3RhdGVzIHx8DQo+ID4gKyAgICBpZiAoICFwbXB0IHx8
ICgocG1wdC0+aW5pdCAmIFhFTl9QWF9JTklUKSAmJiAhcG1wdC0+cGVyZi5zdGF0ZXMpDQo+ID4g
KyB8fA0KPiA+ICAgICAgICAgICAhcG9saWN5IHx8ICFwb2xpY3ktPmdvdmVybm9yICkNCj4gPiAg
ICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4NCj4gVGhpcyBsb29rcyBxdWVzdGlvbmFibGUgYWxs
IG9uIGl0cyBvd24uIFdoZXJlIGlzIGl0IHRoYXQgLT5wZXJmLnN0YXRlcyBhbGxvY2F0aW9uIGlz
DQo+IGJlaW5nIGF2b2lkZWQ/IEkgZmlyc3QgdGhvdWdodCBpdCBtaWdodCBiZSBwYXRjaCAwNiB3
aGljaCBpcyByZWxhdGVkLCBidXQgdGhhdCBkb2Vzbid0DQo+IGxvb2sgdG8gYmUgaXQuIEluIGFu
eSBldmVudCBmdXJ0aGVyIGRvd24gZnJvbSBoZXJlIHRoZXJlIGlzDQo+DQoNCi0+cGVyZi5zdGF0
ZXMgaXMgYWxsb2NhdGVkIGluIHNldF9weF9wbWluZm8oKQ0KSXQgaXMgYSBweC1zcGVjaWZpYyBm
dW5jdGlvbi4NCg0KPiAgICAgZm9yICggaSA9IDA7IGkgPCBvcC0+dS5nZXRfcGFyYS5mcmVxX251
bTsgaSsrICkNCj4gICAgICAgICBkYXRhW2ldID0gcG1wdC0+cGVyZi5zdGF0ZXNbaV0uY29yZV9m
cmVxdWVuY3kgKiAxMDAwOw0KPg0KPiBpLmUuIGFuIGFjY2VzcyB0byB0aGUgYXJyYXkgc29sZWx5
IGJhc2VkIG9uIGh5cGVyY2FsbCBpbnB1dC4NCj4NCg0KSSdsbCBndWFyZCBpdCB3aXRoIHBtcHQt
PmluaXQgJiBYRU5fUFhfSU5JVCB0b28NCg0KPiBCb3RoIHRoaXMgYW5kIC4uLg0KPg0KPiA+IEBA
IC00NjEsOSArNDYxLDEwIEBAIGludCBkb19wbV9vcChzdHJ1Y3QgeGVuX3N5c2N0bF9wbV9vcCAq
b3ApDQo+ID4gICAgICBzd2l0Y2ggKCBvcC0+Y21kICYgUE1fUEFSQV9DQVRFR09SWV9NQVNLICkN
Cj4gPiAgICAgIHsNCj4gPiAgICAgIGNhc2UgQ1BVRlJFUV9QQVJBOg0KPiA+IC0gICAgICAgIGlm
ICggISh4ZW5fcHJvY2Vzc29yX3BtYml0cyAmIFhFTl9QUk9DRVNTT1JfUE1fUFgpICkNCj4gPiAr
ICAgICAgICBpZiAoICEoeGVuX3Byb2Nlc3Nvcl9wbWJpdHMgJiAoWEVOX1BST0NFU1NPUl9QTV9Q
WCB8DQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFhFTl9QUk9D
RVNTT1JfUE1fQ1BQQykpICkNCj4gPiAgICAgICAgICAgICAgcmV0dXJuIC1FTk9ERVY7DQo+ID4g
LSAgICAgICAgaWYgKCAhcG1wdCB8fCAhKHBtcHQtPmluaXQgJiBYRU5fUFhfSU5JVCkgKQ0KPiA+
ICsgICAgICAgIGlmICggIXBtcHQgfHwgIShwbXB0LT5pbml0ICYgKFhFTl9QWF9JTklUIHwgWEVO
X0NQUENfSU5JVCkpICkNCj4gPiAgICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+ID4gICAg
ICAgICAgYnJlYWs7DQo+ID4gICAgICB9DQo+DQo+IC4uLiB0aGlzIGh1bmsgYWxzbyBsb29rIGFz
IGlmIHRoZXkgd291bGQgYmVsb25nIChwYXJ0bHk/KSBpbiBtYXliZSBwYXRjaCAwMz8NCj4gRXZl
biBtb3JlIHNvIGFzIHBlciB0aGUgdGl0bGUgdGhpcyBpcyBzb2xlbHkgYSB0b29sIHN0YWNrICh4
ZW5wbSkgY2hhbmdlLg0KPg0KDQpUcnVlLCBJIHNoYWxsIG1vdmUgdGhlbSB0byAwMywgdG8gbGV0
IHRoaXMgY29tbWl0IGJlaW5nIHNvbGVseSBhIHRvb2wgc3RhY2sgKHhlbnBtKSBjaGFuZ2UNCj4g
SmFuDQo=


From xen-devel-bounces@lists.xenproject.org Fri May 09 06:55:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 06:55:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979808.1366305 (Exim 4.92)
	(envelope-from )
	id 1uDHda-0002vf-HA; Fri, 09 May 2025 06:55:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979808.1366305; Fri, 09 May 2025 06: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 1uDHda-0002vY-DH; Fri, 09 May 2025 06:55:14 +0000
Received: by outflank-mailman (input) for mailman id 979808;
 Fri, 09 May 2025 06:55:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDHdZ-0002vS-5V
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 06:55:13 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2009::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8bfd1ec0-2ca2-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 08:55:11 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SA1PR12MB5640.namprd12.prod.outlook.com (2603:10b6:806:23e::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.19; Fri, 9 May
 2025 06:54:47 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8722.021; Fri, 9 May 2025
 06:54: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" 
X-Inumbo-ID: 8bfd1ec0-2ca2-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dLTb3CUZnaLrG53uAimt1PC7nAF0eStSzKA5GMb5CBt/scLsnBh3nOvlQEs7ZsQxcBZwzQi3Ujj90zDmu56fZY3HV8u+lrRiSPEe3oSXi/rV2b6smEJ7HbeFsNsWN/d5pFQx8vKdZDFIFuSChht1qChecag8RRb1vmriJutR+8Z1ZLsdliwT+8S0hl4jVzJpZy7wjfsSgAdlB9v7mTzu7ri4me5FDcFzH8q5jvUrxmV/pM32Z2JdjdQbjbMd2qREWMjsDO6s9X+NqLNqJ5sJd7RTfckBiwKXlEG5P6FH9FxyaPrad6avSSWTcgGpyA81+80yUWa2hgd/2I47efcXLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WM4/BbTKRObY7yBOBEXzESKHwCuU7WnJu6KhkyapCHw=;
 b=dO7km+1zw5S9D0FQk3ycryknIl9NXAyIbVKJR+IeCcszGb12A6KhhjWVta9qa7L2EqgEXKM7pP8TgNHVf0acVuJ6P3TAghk9fa3ywaf7rPB78n2oBg9SUOZBqbOmbH4Docd4uWv8HciMnaYEa4uja4qgZqG18Twy2M3DbBqPJJHNgq3WWYX7VYl8+9c64Na3OaIKqWJRlce9uqEBwMIV4gx3k5ONkwoN+6kUvCMfdaBym2x2k67rMnGvsP/WjyrtIuSJF2/p6HN5Z6lKRIXcZzYypVxhIN5oYIacLwccpIa8ZODnUqjTqctzzCpzbx00aHZzZJKWg2Gtu8mxEV37+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=WM4/BbTKRObY7yBOBEXzESKHwCuU7WnJu6KhkyapCHw=;
 b=stDCxG7VdLKIcKyW7t79Fy2tekUCUH7H9+eeXv81TojvDAaGaN7PKq3/mdiC9y3rmxnpKAoqEK9JTGPV8/w1UuMWRiG2pJqsLL/S78oBlHdR5KyEkRHQGvJLGiUh+8APTTNmDsBds7AsqKgcuw140tVkuYDnB3i+xlwIf4nx0F4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <3caa25d7-9faf-4099-a0a2-f7014c01e1ce@amd.com>
Date: Fri, 9 May 2025 08:54:43 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/6] xen/arm: exclude xen,reg from domU extended
 regions
To: Stewart Hildebrand ,
 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: <20250508132040.532898-1-stewart.hildebrand@amd.com>
 <20250508132040.532898-6-stewart.hildebrand@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250508132040.532898-6-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0323.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:eb::6) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SA1PR12MB5640:EE_
X-MS-Office365-Filtering-Correlation-Id: 7a2d0848-f7a5-429b-37ee-08dd8ec662bf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eW1iS0ZHcTIyMUdzWTBsYUlncWU4WTNtcmFUV0oyUUNDR1QzbGw4VFpDWDhZ?=
 =?utf-8?B?bHVTUEtwRG9rM1RjWkdFUXU5Lzdya0pjdVFUOUxvOFJERHFDTGJpUUJaODNq?=
 =?utf-8?B?bFZqTVE2TFVySW1qdnUxR1IwQ0tCMFp6SzJUNnA1RlVvR2RnL3k4MXJ4WGFL?=
 =?utf-8?B?SGhKNGRHVkswdFptUVFDL2VEODRUS1RhUS81TjdsU0huN3A1WlRUMDkvZ0Vz?=
 =?utf-8?B?T2hPMS8zd3ZVaEtaSGpjWVFKKzd4RDVMYXZHeTE4cUtSWU5BTnYxTXQxVFJG?=
 =?utf-8?B?bk5kVnRERVRpUnhINktmaUdPQlg5UFUvZHA3Rm1VVFR0ZGpYUElxZncvMzhY?=
 =?utf-8?B?R3dIM3RCRFVqVjRVZEk5WU96RWpEa2IxR1dBS0h6dm1YNVBUUFpSSjNjM0xn?=
 =?utf-8?B?R2d4NXU5WGlwOFpndHI5WExnelV4bFZuZzBmY1RsQS9pQnNET1lTU0lDRUhC?=
 =?utf-8?B?UTFnK3hRYisxcDNJdS80c1ZHYWFocVNyYXdHTUI0R2JnQUhjbW5UZlBHQVVO?=
 =?utf-8?B?OHk3ZHAydzhmcVVydEtaZ0RYYjQ5MEl3ZzM1TVZKMGxKTkYwWFV4R0JTS2to?=
 =?utf-8?B?NlE0VGxFOFdhNHNwUjk1cXZBYXkrc1hRbWV1c0FrY01kZ051UnY4d2ZmSVFQ?=
 =?utf-8?B?eUc2eW9ieFo5L1FIVVh1MHM2TVNIMXo2SmdrcWI5QlJNZFRJMVJvMjdkTGQx?=
 =?utf-8?B?RFlRcTdEQlRaODFiRXpoU3NpUDJyN1ZtREFMc0svcC9VZ2oyVWxHclFDK2N5?=
 =?utf-8?B?Q003SnRQZ3pOTFEwZllXL0UwWGJIdmZzRXlxZGQ0R2QzQ3oxOEtqVlhKc3Z6?=
 =?utf-8?B?UDc1Rjk3Z3FMZjNDVmZyYWtYR3pmYWpzOTBocTNNWE1JYlpzOTF6cEdFMWNM?=
 =?utf-8?B?M21tTG5VV09PMUY4TW1Bc3JyUGwwc2VDL1Y1VmlCS0FMQlhnU2kzWmlka1FK?=
 =?utf-8?B?ZXVUbSs3ME8xTExJeG1BWFN3MFYyRDVkWjV3eEw0QnVwYmtIdk54N09Maklo?=
 =?utf-8?B?QXl6V1pBUFNTWThkTHkvNzhZZEc4SlMzY041N2hvemdxS1dvQ2tqRGgwbVpF?=
 =?utf-8?B?azIvMS9YTzNpTEpxMXgvUU42aTRoKzJJUXV1M2UwQlFoR1R6RVNGVDR1MGR3?=
 =?utf-8?B?cC9tVitjOTZqcUtOMzFjZjhvMnpBRElaWWRBWlE5aVlNTWUxeXpWckp6Vit6?=
 =?utf-8?B?aEhza25ZdVhLcGNWUU1QK1NlSjFldnJRMnJQbzRxQk14d0dDNjRwTHpiaHRG?=
 =?utf-8?B?NGVNWk9yZXF1R2hMMjR1Y25aUGdPNDVDcW11K2dLVXJsVDBLZFkrTTNaM2Jx?=
 =?utf-8?B?MVpWOFllYkFxdnNPR1pRSVZPcE80MkZwTFEveHZkVDFka01IOFphOUFvV1hR?=
 =?utf-8?B?RWJpK0s0S3FncHpvMUFaSXowb3ZsTURVTllNejZ6K3NNMHZhNElUcTNya2xB?=
 =?utf-8?B?UFFlODZoaVM4NDM4Q3c5QmFLc1YycC9SbEFROFB6cUJqN2tCRlFjdUlmaHVr?=
 =?utf-8?B?SWNlL003SElCT3NDRFNva1l1UmR0QmJ1L2c3ZTlxa29uYU5rTERrdXphN0pz?=
 =?utf-8?B?ZUt3MS9XRkI5S1VlWlJmcFV3dHByeTVnL0IreWs2RlJaMThYMDQ0c0ZFbmlk?=
 =?utf-8?B?ZUdxaTFGT0RWTHdaUGJhMFdFU2ZVS1ZpVEYrTWZNWkFqTitvVXFnaUFJbXNz?=
 =?utf-8?B?V2x5ZVdLMVYzUHJ2eGpsWVQvQ3oxZVNUQzBnQmwwcFFyVU0xVXBiOEtQSWdl?=
 =?utf-8?B?aFJYY3VFMWZ4d3NrcG04V29iTk1qazRyUlNDN0xhMjB0NDRFZlhDL3NEdFBG?=
 =?utf-8?B?QXFHZkJteEgvbUg0aWFVUkNoUVRuRHVqTnNTS0RUQ0tpaUQrOGwyOFZaZktQ?=
 =?utf-8?B?MmtMZ3grR0NMMlUzVFpTU3VUakZhRFhCU085TWJNWExqVUNyM3Z1MFl0RmY2?=
 =?utf-8?Q?n2piAheqyaY=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZVBOY04ycEhQcUhheC84NGJNeE1iMFRVWGtuNWtWbmlScVpSekZxNzlKKzBY?=
 =?utf-8?B?MGUxMEVRTVRTTmM0YVZQdExuRGwxK29XRDU2R2ROdTAvMUYxVEFJRVNaQnF1?=
 =?utf-8?B?V0VWSXRLNmt3OWVYbkdxNVRiWlNzQ05LQ3h4QzYvZFhVc3Nlakh3K1JLdTBF?=
 =?utf-8?B?aGpCbCs4a3A1MTJUU1dnZDkzNk15bW5jWTdoakJiZGU1d29uWTJNanZGbUxW?=
 =?utf-8?B?QWxBcmVTUkpmWXRHRnpKSjJXeDc2S0RrbWdlVjk0RWhkdWJUZWRlTXozWXBi?=
 =?utf-8?B?cEVrUkc5VlhxckVvQ0czODRZaUc1b2pPdkUxUzJGb21aaUcyR3VOUTA1WWZz?=
 =?utf-8?B?emNlVXhpREQ5alhRWWFLcW92Z1dsWHpiYzIzY2dkKy9HVFY4VFdMeUlXMlY0?=
 =?utf-8?B?VmVxNk4rcStlWkxpQk5PVmsrcFVrbi9VRmI5VUZCb0g2MHVGUW5HQ0xpT2Ny?=
 =?utf-8?B?dll3Sjg3enNzWnY4U0pxMjBINmdyVFFmS1lNc1JRWmtCRFVHUlNMNVpNOEg5?=
 =?utf-8?B?eVE5Rk1vdkQ0dHJTQW9BbzljVXRCNFhXWUNTbFNLQmRJKzJ1QkFvOWZJVmtX?=
 =?utf-8?B?RVc1NFFmcVpOclJIa0N2bFFQYzVPbURpVTJ5NnRodldvditzWXhFT3ZLRUpK?=
 =?utf-8?B?SHVZUDkxUlpldTRFQStWMnB0ODEzSXNvaWc2L2t5RjRwc0tLQVBUWmZkaVNE?=
 =?utf-8?B?K1NWQ0tTTmZleEhEQStFQ1BwdXNBdE1wbVdTN2NKZnhHbUhaUmNyZ2U0eGZ6?=
 =?utf-8?B?NmFURUd1MUpIZE83L01ERzgrYTU2bG5FZmFvdmZIaTRGYURsanlvWSt1VjZ2?=
 =?utf-8?B?RXY4R0dUZzlrNFhTdnljNHozZ0lXUk5jTnBJc1JKNjNZbWtMaW9qM1J6N3Ny?=
 =?utf-8?B?S2hBZlFrSnl1SytSUGlPa0Q3N08zdUh3YU1Gd3JoczlvSit5Si9lL0t5dVZs?=
 =?utf-8?B?eEFhdlo5dDZwTXFVV0t3V0daQWFPRUxpWmFkU0hMSmpYUUdMR0FOV29IVFl3?=
 =?utf-8?B?dURERFpKWS9qTWI2bG5nYmJ5RDFXZTAvS0xkT3p1bmtqYlRvcmdMdkh6dlBF?=
 =?utf-8?B?ZmpoTFVFOEdZTE51UHNmWnRxRGNLZzB0VHp3c2hXTmVEZm1Rb1RPeE42eSts?=
 =?utf-8?B?ai8rRnorU1FoSUZFaFE4UHdLMmJBN0tEeDhBQkw5eGdWMWNtYXdiM0JpVmJR?=
 =?utf-8?B?aHovTUpLNHN0eGw4Wnk5OEhIWm1LamhYRCswNDNRbkdSRkhrQUhYbVpqZzdJ?=
 =?utf-8?B?enNVK3RqNG9zcVJPcUZqOXF0Ym1ibmRManhMRlF1akdwMldOZUxQcXI2YWtH?=
 =?utf-8?B?N1F0czJkVklSamJxUTV5NHJJOFRoKzUyVUhyTW5zUGk5bHFrd2FlNFUwTnNN?=
 =?utf-8?B?amlSNk1yUWNkZ3FoY0FqK0RBSEFBNXJwSWs1bmxVOEJsWktQZzJUQ01FVHhO?=
 =?utf-8?B?YWV4VE1wTUE2ajlZTGM4K1VKcjN3WDhxakpRMnBmUFdXSHdWajNVSWN0Zy80?=
 =?utf-8?B?MUVoRzZ3QnkxbFRDUENsVkZ0b3BEakZMb0xFeStYSlM4NGUzditCdHhLVDFK?=
 =?utf-8?B?OEhRL1NnV2IzUFlsVEpIM0lFS3NwSWJMMUlMY29OUmtWVjQvd1pEaWkrbGpT?=
 =?utf-8?B?QmxlRVAyeXhZd0lFcHd0amR5ZFhESGE3ODdld3Z4RHUrWmorNkdnRENISC9o?=
 =?utf-8?B?SU43MlZiazNtc0hZU2xPbVFQam53bExEL2tjcVdWckN0UFI3d3dJL2hjOGZ6?=
 =?utf-8?B?V0kyR0toMFpGVGYyRXV0akloUlhJdzdtYm9CQ1F0TVh5N1Y5a0ZqVFUvZjhl?=
 =?utf-8?B?WHovMjhDejlVblFWM0MxUnhTUXlueXVHc08vK3JHby9IOG9POWx2MTFLbFdL?=
 =?utf-8?B?V0xnVkFtbHh0RlJBajBmNW9USFRmYWdZWU5sc3EwQUxKRnNHRUdIOTBkTTgz?=
 =?utf-8?B?UkFReENoZTREWjhta2dXVWpLc3FPSGh3WjRSck5XdGlnT2dxZE01cVNFOW1q?=
 =?utf-8?B?Skd3MklXVUg2UnhwUVNPNzl5ZUVhZkFnb3JNVnVqYzZZUmtsUk45UzdXL0hK?=
 =?utf-8?B?SGoyR2I3UllFaGREbXQwVGFrRStZczJRdDNZWVRndnBVWjQvWEdSQVhmSlFK?=
 =?utf-8?Q?kInc=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7a2d0848-f7a5-429b-37ee-08dd8ec662bf
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 06:54:47.0132
 (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: U++yGcF67cK6u694tNPraViKh/BqAKTD1CJHvnhr22526/nZIs9K6lJ/ZTIjzAoj
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB5640



On 08/05/2025 15:20, Stewart Hildebrand wrote:
> When a device is passed through to a dom0less domU, the xen,reg ranges
> may overlap with the extended regions. Remove xen,reg from extended
> regions.
> 
> Signed-off-by: Stewart Hildebrand 
> ---
> Not sure if we need a Fixes: tag, but if we do:
> Fixes: 2a2447757b3c ("xen/arm: implement domU extended regions")
> 
> v1->v2:
> * adjust commit message to not mention xen,reg-cacheable
> * don't call rangeset_destroy() in construct_dom0()
> * rebase
> 
> I investigated an alternate approach of parsing the partial device tree
> again to scan for xen,reg properties, but it resulted in quite a lot of
> code duplication. Adding a rangeset pointer to "struct kernel_info" has
> a much smaller diffstat, and then we avoid the need to parse the partial
> device tree a second time.
> 
> I discovered this issue when booting a dom0less domU with a device
> passed through. Partial device tree excerpt:
> 
>     passthrough {
>         ...  ...
> 
>         axi_uart16550_0: serial@a0001000 {
>             clocks = <&uart_fixed_clk>;
>             compatible = "ns16550a";
>             interrupt-parent = <&gic>;
>             interrupts = <0 89 4>;
>             reg = <0x0 0xa0001000 0x0 0x1000>;
>             reg-shift = <2>;
> 
>             xen,reg = <0x0 0xa0001000 0x00 0x1000 0x0 0xa0001000>;
>             xen,path = "/amba_pl@0/serial@a0000000";
>             xen,force-assign-without-iommu;
>         };
>     };
> 
> The domU was assigned an extended region overlapping with MMIO of the
> passed through device:
> 
> (XEN) d1: extended region 0: 0xa0000000->0x100000000
> (XEN) d1: extended region 1: 0x200000000->0xf000000000
> 
> The domU panicked when attempting to initialize the device:
> 
> [    3.490068] a0001000.serial: ttyS0 at MMIO 0xa0001000 (irq = 15, base_baud = 6249375) is a 16550A
> [    3.498843] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
> [    3.498853] Mem abort info:
> [    3.498855]   ESR = 0x0000000096000044
> [    3.498859]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    3.498864]   SET = 0, FnV = 0
> [    3.498867]   EA = 0, S1PTW = 0
> [    3.498870]   FSC = 0x04: level 0 translation fault
> [    3.498874] Data abort info:
> [    3.498876]   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
> [    3.498879]   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
> [    3.498884]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [    3.498888] [0000000000000010] user address but active_mm is swapper
> [    3.498894] Internal error: Oops: 0000000096000044 [#1] SMP
> [    3.498899] Modules linked in:
> [    3.498908] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.10-stew #1
> [    3.498917] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [    3.498924] pc : mem_serial_out+0x18/0x20
> [    3.498936] lr : serial8250_do_set_mctrl+0x6c/0xc0
> [    3.498943] sp : ffff800081bab6d0
> [    3.498946] x29: ffff800081bab6d0 x28: ffff8000815e0dc8 x27: ffff000001c29c60
> [    3.498957] x26: 0000000000000000 x25: ffff00000347b900 x24: ffff000005504c00
> [    3.498968] x23: ffff00000347b800 x22: 0000000000000000 x21: ffff800081b69d78
> [    3.498978] x20: ffff800081b69d78 x19: 0000000000000000 x18: ffffffffffffffff
> [    3.498989] x17: 3d20647561625f65 x16: 736162202c353120 x15: 3d20717269282030
> [    3.498999] x14: 3030313030306178 x13: ffff800081a21ff0 x12: 00000000000007fe
> [    3.499010] x11: 00000000000002aa x10: ffff800081a4dff0 x9 : ffff800081a21ff0
> [    3.499020] x8 : 00000000fffff7ff x7 : ffff800081a4dff0 x6 : 0000000000000008
> [    3.499030] x5 : 0000000000000000 x4 : ffff800080797584 x3 : 0000000000000002
> [    3.499040] x2 : 0000000000000000 x1 : 0000000000000010 x0 : 0000000000000000
> [    3.499050] Call trace:
> [    3.499053]  mem_serial_out+0x18/0x20
> [    3.499059]  serial8250_set_mctrl+0x34/0x40
> [    3.499065]  serial_core_register_port+0x534/0x7dc
> [    3.499075]  serial_ctrl_register_port+0x10/0x1c
> [    3.499084]  uart_add_one_port+0x10/0x1c
> [    3.499092]  serial8250_register_8250_port+0x308/0x4c0
> [    3.499102]  of_platform_serial_probe+0x2c4/0x48c
> [    3.499110]  platform_probe+0x68/0xdc
> [    3.499120]  really_probe+0xbc/0x298
> [    3.499128]  __driver_probe_device+0x78/0x12c
> [    3.499135]  driver_probe_device+0xdc/0x160
> [    3.499142]  __driver_attach+0x94/0x19c
> [    3.499149]  bus_for_each_dev+0x74/0xd0
> [    3.499155]  driver_attach+0x24/0x30
> [    3.499162]  bus_add_driver+0xe4/0x208
> [    3.499168]  driver_register+0x60/0x128
> [    3.499176]  __platform_driver_register+0x24/0x30
> [    3.499184]  of_platform_serial_driver_init+0x1c/0x28
> [    3.499192]  do_one_initcall+0x6c/0x1b0
> [    3.499199]  kernel_init_freeable+0x178/0x258
> [    3.499209]  kernel_init+0x20/0x1d0
> [    3.499218]  ret_from_fork+0x10/0x20
> [    3.499228] Code: f9400800 1ac32021 8b21c001 d50332bf (39000022)
> [    3.499233] ---[ end trace 0000000000000000 ]---
> [    3.499237] note: swapper/0[1] exited with irqs disabled
> [    3.499247] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [    3.499251] SMP: stopping secondary CPUs
> [    3.499284] Kernel Offset: disabled
> [    3.499286] CPU features: 0x00,00000080,00200000,0200420b
> [    3.499292] Memory Limit: none
> [    3.792412] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> ---
>  xen/arch/arm/domain_build.c             |  7 +++++++
>  xen/common/device-tree/dom0less-build.c | 19 ++++++++++++++++++-
>  xen/include/xen/fdt-kernel.h            |  1 +
>  3 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 05a77a4f92c6..b189a7cfae9f 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -973,6 +973,13 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>      if ( res )
>          goto out;
>  
> +    if ( kinfo->xen_reg_assigned )
> +    {
> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
> +        if ( res )
> +            goto out;
> +    }
> +
>      res = rangeset_report_ranges(mem_holes, 0,
>                                   PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
>                                   add_ext_regions, ext_regions);
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 4aa36c8ef33f..2c56f13771ab 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -146,6 +146,14 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>      int res;
>      paddr_t mstart, size, gstart;
>  
> +    if ( !kinfo->xen_reg_assigned )
> +    {
> +        kinfo->xen_reg_assigned = rangeset_new(NULL, NULL, 0);
> +
> +        if ( !kinfo->xen_reg_assigned )
> +            return -ENOMEM;
> +    }
> +
>      /* xen,reg specifies where to map the MMIO region */
>      cell = (const __be32 *)xen_reg->data;
>      len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
> @@ -187,6 +195,11 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>                     mstart, gstart);
>              return -EFAULT;
>          }
> +
> +        res = rangeset_add_range(kinfo->xen_reg_assigned, PFN_DOWN(gstart),
> +                                 PFN_DOWN(gstart + size - 1));
> +        if ( res )
> +            return res;
>      }
>  
>      /*
> @@ -814,7 +827,11 @@ static int __init construct_domU(struct domain *d,
>  
>      domain_vcpu_affinity(d, node);
>  
> -    return alloc_xenstore_params(&kinfo);
> +    rc = alloc_xenstore_params(&kinfo);
> +
> +    rangeset_destroy(kinfo.xen_reg_assigned);
> +
> +    return rc;
>  }
>  
>  void __init create_domUs(void)
> diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
> index 7a6cd67c22f1..1939c3ebf7dc 100644
> --- a/xen/include/xen/fdt-kernel.h
> +++ b/xen/include/xen/fdt-kernel.h
> @@ -24,6 +24,7 @@ struct kernel_info {
>  #ifdef CONFIG_STATIC_SHM
>      struct shared_meminfo shm_mem;
>  #endif
> +    struct rangeset *xen_reg_assigned;
The purpose of your newly introduced xen_reg_assigned is to keep track of these
ranges so that we can remove them from extended regions. The concept of extended
regions exists only for Arm today. Therefore I'm not sure why making all these
common i.e. entry in struct, rangeset allocation, etc. The other aspect is that
extended regions may be disabled by the user and you would still allocate
rangeset and add xen,reg to it for no purpose - i.e. dead code.

Also, what about direct-mapped domUs? We don't seem to take xen,reg into account
there.

P.S.
After recent dom0less code movement there are some issues that I reported to
Oleksii. Long story short, we shouldn't be making the code common (e.g. static
mem, shmem, domain type) that is implemented for now only for one arch. If the
need arises in the future, the feature code together with callers can be moved
to common. At the moment, we have some features being in arch specific
directories but callers in common code and #ifdef-ed (making the stubs
unreachable). That's not great.

~Michal



From xen-devel-bounces@lists.xenproject.org Fri May 09 07:48:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 07:48:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979824.1366319 (Exim 4.92)
	(envelope-from )
	id 1uDISl-0000rT-CB; Fri, 09 May 2025 07:48:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979824.1366319; Fri, 09 May 2025 07:48: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 1uDISl-0000rM-9Y; Fri, 09 May 2025 07:48:07 +0000
Received: by outflank-mailman (input) for mailman id 979824;
 Fri, 09 May 2025 07:48:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDISk-0000rG-P1
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 07:48:06 +0000
Received: from mail.actia.se (mail.actia.se [212.181.117.226])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f0aee21e-2ca9-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 09:48:04 +0200 (CEST)
Received: from S036ANL.actianordic.se (10.12.31.117) by S036ANL.actianordic.se
 (10.12.31.117) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 09:48:04 +0200
Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by
 S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%3]) with mapi id
 15.01.2507.039; Fri, 9 May 2025 09:48:04 +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" 
X-Inumbo-ID: f0aee21e-2ca9-11f0-9eb4-5ba50f476ded
From: John Ernberg 
To: Stefano Stabellini , Christoph Hellwig
	
CC: Juergen Gross , Oleksandr Tyshchenko
	, Catalin Marinas ,
	Andrew Morton , "xen-devel@lists.xenproject.org"
	, "iommu@lists.linux.dev"
	, "linux-kernel@vger.kernel.org"
	, "imx@lists.linux.dev" 
Subject: Re: [PATCH 2/2] xen: swiotlb: Implement map_resource callback
Thread-Topic: [PATCH 2/2] xen: swiotlb: Implement map_resource callback
Thread-Index: AQHbu1cR+sKkXAZoXEOAUfrcrER157O/dMAAgAX2O4CAAkbqgIAAVVAAgAE+k4CAAI9lgA==
Date: Fri, 9 May 2025 07:48:03 +0000
Message-ID: 
References: <20250502114043.1968976-1-john.ernberg@actia.se>
 <20250502114043.1968976-3-john.ernberg@actia.se>
 
 <75266eb7-66a4-4477-ae8a-cbd1ebbee8db@actia.se>
 
 
 
In-Reply-To: 
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.12.12.35]
x-esetresult: clean, is OK
x-esetid: 37303A2955B14453667D66
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0

SGkgU3RlZmFubywNCg0KT24gNS85LzI1IDE6MTQgQU0sIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90
ZToNCj4gT24gV2VkLCA3IE1heSAyMDI1LCBDaHJpc3RvcGggSGVsbHdpZyB3cm90ZToNCj4+IE9u
IFdlZCwgTWF5IDA3LCAyMDI1IGF0IDA0OjA5OjE1UE0gLTA3MDAsIFN0ZWZhbm8gU3RhYmVsbGlu
aSB3cm90ZToNCj4+Pj4gVGhpcyBtYXBwaW5nIGlzIG5vdCBmb3IgYSBSQU0gYmFja2VkIGFkZHJl
c3MuIEluIHRoZSBlRE1BIGNhc2UgZm9yIHRoZQ0KPj4+PiBpTVg4UVhQIHRoZSBgcGh5c2AgY29t
aW5nIGluIGhlcmUgaXMgdGhlIGFkZHJlc3Mgb2YgYSByZWdpc3Rlci4NCj4+Pg0KPj4+IE9rLCB0
aGlzIGluZm9ybWF0aW9uIGlzIGltcG9ydGFudCA6LSkNCj4+Pg0KPj4+IEkgYW0gbm90IGNlcnRh
aW4gd2hldGhlciB0aGUgbWFwX3Jlc291cmNlIGludGVyZmFjZSBjYW4gb25seSBiZSBjYWxsZWQN
Cj4+PiBmb3IgTU1JTyBhZGRyZXNzZXMgb3IgaWYgaXQgY2FuIGFsc28gYmUgY2FsbGVkIGZvciBS
QU0tYmFja2VkIGFkZHJlc3Nlcw0KPj4+IHdpdGggYSBzaXplID4gUEFHRV9TSVpFLiBJbiB0aGUg
bGF0dGVyIGNhc2UsIHdlIGNvdWxkIHJ1biBpbnRvIHRoZSBpc3N1ZQ0KPj4+IEkgd2FzIGRlc2Ny
aWJpbmcuDQo+Pg0KPj4gbWFwX3Jlc291cmNlIGlzIGludGVuZGVkIGZvciBNTUlPIHJlZ2lvbnMs
IGFsdGhvdWdoIHRob3NlIGNvdWxkIGJlID4NCj4+IFBBR0VfU0laRS4gIEl0IG11c3Qgbm90IGJl
IGNhbGxlZCBvbiBSQU0uDQo+IA0KPiBJbiB0aGF0IGNhc2UsIEpvaG4sIHlvdSBjYW4ganVzdCB1
c2UgZG1hX2RpcmVjdF9tYXBfcmVzb3VyY2UoKS4NCj4gDQo+IFRoYXQncyBiZWNhdXNlIE1NSU8g
cmVnaW9uczoNCj4gLSBhcmUgMToxIG1hcHBlZCBvbiBBUk0NCj4gLSBhcmUgMToxIG1hcHBlZCBv
biB4ODYgZm9yIFBWIERvbTANCj4gLSBtaWdodCBub3QgYmUgMToxIG1hcHBlZCBvbiB4ODYgZm9y
IFBWSCBEb20wLCBidXQgaW4gdGhpcyBjYXNlIHdlIHJlbHkNCj4gICAgb24gdGhlIElPTU1VIHRv
IGRvIGFkZHJlc3MgdHJhbnNsYXRpb24NCj4gDQo+IEluIG5vbmUgb2YgdGhlc2UgY2FzZXMgeGVu
X3BoeXNfdG9fZG1hIHdvdWxkIGdpdmUgdXMgYW55IGludGVyZXN0aW5nDQo+IHJlc3VsdHMuICBJ
dCB3b3VsZCBiZSB0aGUgc2FtZSBhcyBjYWxsaW5nIHBoeXNfdG9fZG1hLg0KDQpUaGFuayB5b3Ug
Zm9yIGV4cGxhaW5pbmcuIEkgd2lsbCBzcGluIGEgVjIgaW5jb3Jwb3JhdGluZyB0aGlzLg0KVGhh
bmtzISAvLyBKb2huIEVybmJlcmcNCg==


From xen-devel-bounces@lists.xenproject.org Fri May 09 08:14:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 08:14:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979834.1366329 (Exim 4.92)
	(envelope-from )
	id 1uDIsa-00058b-EL; Fri, 09 May 2025 08:14:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979834.1366329; Fri, 09 May 2025 08:14: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 1uDIsa-00058U-BM; Fri, 09 May 2025 08:14:48 +0000
Received: by outflank-mailman (input) for mailman id 979834;
 Fri, 09 May 2025 08:14:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDIsY-00058M-KM
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 08:14:46 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aa05264e-2cad-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 10:14:44 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43cebe06e9eso13341605e9.3
 for ; Fri, 09 May 2025 01:14:44 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442d685869csm21378855e9.26.2025.05.09.01.14.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 01:14: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" 
X-Inumbo-ID: aa05264e-2cad-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746778484; x=1747383284; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=MJADe6r/awdzbcEHbrD3YiMYwf392PpKrvKEy6T5pJM=;
        b=SmoK6W0vvBV1Yh6YIc+/SWuFJTqjVMAKpy+CTZTGkKDPq/jVlwn+c9BVIXa7TSp8ik
         OrZ63O2QNSX0FI1XZPNJEzwNIJXmj72K7AxcQFF/3VWUAiH15ddPQbHu5r/Tox3aZjsQ
         gKRiAZS0hgNM2ZvC4ZcizuYOOb+uAn/0l8YoA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746778484; x=1747383284;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=MJADe6r/awdzbcEHbrD3YiMYwf392PpKrvKEy6T5pJM=;
        b=vxuADkZ9fsK/ss8n2D0GFlF5OuSuIWRgVmZjnKh0NilmespjhLQstjwhO43td8KrHl
         EoQrn6O6wIyrQMXEOTn/IINghCs8rKDBcQkDMZU0xAPpLjDqWkpaBaFThjSBFeiRED22
         nRAcowMiXjrefr23FDh24x2O188ssEMmjVfn8tx4j+uvJ9F7TlgEFNmAQ2vJII4geZxq
         BGno+CpHHzfC4h6SB4HN6Zt6tQvdVrTCWAIl7bz45hb2flskj1DtUFtTJZbKI5TZSIRK
         91v8tfzFDichNZ0Xj9ZChngy78el3dTOiXLJX87l+VPPra58kovdn/BAniRNzZpncYxB
         fqmw==
X-Gm-Message-State: AOJu0YwJ/7ZHP0Pmt7RAFrdREr+PX5beX1IkqtpucFbEyCsKFAVFHI3j
	etP6rirGPErolUB3BJjWTpjQMhWrTDUaDv/onofU1V4Whwe5gcsQqupdgaqB8rs=
X-Gm-Gg: ASbGnctKJWjJRRC78sMZR6K36cmEm8nMeKcTrB/2HpEck01EjqmXJILZ/6ZuPmd96TZ
	nQ6GNQ9OFMyjhVcbF/KpDPcSZplls2yl4bmvNvVuH869Fg2azuK28gNE/nhOGp+hPekQ3zM+Oe+
	Gpkx18/XP1c0hCBZ2x59UV7tUtCykkiGChY61vcdqLMRGK9FQsKi4JBjnvPiv0prTozLmo6mzb7
	1E52rP/JyVL5JIRpwXOhYJqM+iI+dGtcYaxs5B5wiXheRHdAP1U4d5JXN4E9vWvc5DhvkOY9aRu
	PzSVoNL0cNRQipTPzO65sbmtai2aEUoASO5qCnYU2yllu5tMYOk=
X-Google-Smtp-Source: AGHT+IHeldYERH+o1TKXoKlhO6RqPy8emk/Eu9kghB7A5gJMWKKAW8OTvha65s1rZTM8rW/Jh5E9Ug==
X-Received: by 2002:a05:600c:8217:b0:43d:b3:f95 with SMTP id 5b1f17b1804b1-442d6ddebafmr14092475e9.28.1746778483708;
        Fri, 09 May 2025 01:14:43 -0700 (PDT)
Date: Fri, 9 May 2025 10:14:42 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH] xen/Kconfig: Improve help test for speculative options
Message-ID: 
References: <20250508160336.2232152-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: <20250508160336.2232152-1-andrew.cooper3@citrix.com>

On Thu, May 08, 2025 at 05:03:36PM +0100, Andrew Cooper wrote:
> The text for CONFIG_INDIRECT_THUNK isn't really correct, and was already stale
> by the time speculative vulnerabilities hit the headlines in 2018.  It is
> specifically an out-of-line-ing mechansim, and repoline is one of several
> safety sequences used.
> 
> Some of this boilerplate has been copied into all other options, and isn't
> interesting for the target audience given that they're all in a "Speculative
> Hardning" menu.
> 
> Reword it to be more concise.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Roger Pau Monné 

You are the expert on those things :).

> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monné 
> CC: Stefano Stabellini 
> 
> CONFIG_SPECULATIVE_HARDEN_BRANCH really ought to be named
> CONFIG_SPECULATIVE_HARDEN_CONDITIONAL, but this would be a (minor) functional
> change.

I don't have a strong opinion either way TBH.  Would you maybe like to
rename the menu visible text to "Speculative Conditional Branch Hardening"?

> ---
>  xen/common/Kconfig | 51 +++++++++-------------------------------------
>  1 file changed, 10 insertions(+), 41 deletions(-)
> 
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 4bec78c6f267..03ef6d87abc0 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -162,29 +162,21 @@ config STATIC_MEMORY
>  menu "Speculative hardening"
>  
>  config INDIRECT_THUNK
> -	bool "Speculative Branch Target Injection Protection"
> +	bool "Out-of-line Indirect Call/Jumps"
>  	depends on CC_HAS_INDIRECT_THUNK
>  	default y
>  	help
> -	  Contemporary processors may use speculative execution as a
> -	  performance optimisation, but this can potentially be abused by an
> -	  attacker to leak data via speculative sidechannels.

It would be nice if this boilerplate text could be made the "help" of
the top level menu entry, but that's not possible with Kconfig.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 09 08:19:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 08:19:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979842.1366339 (Exim 4.92)
	(envelope-from )
	id 1uDIwq-0005iF-Un; Fri, 09 May 2025 08:19:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979842.1366339; Fri, 09 May 2025 08:19: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 1uDIwq-0005i8-S2; Fri, 09 May 2025 08:19:12 +0000
Received: by outflank-mailman (input) for mailman id 979842;
 Fri, 09 May 2025 08:19:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uDIwp-0005i2-Du
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 08:19:11 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 44a13235-2cae-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 10:19:05 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 5498IM5Q087553
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Fri, 9 May 2025 01:18:25 -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" 
X-Inumbo-ID: 44a13235-2cae-11f0-9ffb-bf95429c2676
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 5498IM5Q087553
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1746778708;
	bh=h8xQ3dgrnLnpM7heAICu789e0KZ7o9GKFoLnqD2Ak6M=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=H06izGtqodA/ZhRkaC/Y9J6N3nu/0IPTNamUaGK0yzrLzta0+wqLYOzV79Kjzmeaw
	 cCu154HR3BnmtEEeqUenT1B2DovOmTGm9kDXJOkx1qY8+A16Bt0hDRBo9TzZCBzzkF
	 wNmI0pMmY1/uf5kgDHNiUVLGhlXM8MJyu+UB7SJb7RujLcpVwjNKEqVnD/G390uBVW
	 OEqb7d6mxryKHALG9MSIIa/gTeoxSRMKrH5PB8/oROFTZTT4bvEpg80rKOadov8R3P
	 dl2j9BfmQV09b0WqlslSTOAprseR9/ATMNjETxQH9yHJi9UemV6cVEkq2Kaeaq6Shw
	 D5DNZgL06ka8w==
Message-ID: <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
Date: Fri, 9 May 2025 01:18:22 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
To: Juergen Gross , linux-kernel@vger.kernel.org,
        x86@kernel.org, virtualization@lists.linux.dev
Cc: Ajay Kaher ,
        Alexey Makhalov ,
        Broadcom internal kernel review list
 ,
        Thomas Gleixner
 , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        "H. Peter Anvin" ,
        Boris Ostrovsky ,
        xen-devel@lists.xenproject.org
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
Content-Language: en-US
From: Xin Li 
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: <20250506092015.1849-6-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 5/6/2025 2:20 AM, Juergen Gross wrote:
> Instead of having callback functions for rdmsr/wrmsr on native, switch
> to inline the respective instructions directly in order to avoid
> overhead with the call interface.

To me, this is a beneficial addition to the existing pvops MSR code.

> 
> This requires to use the instruction interfaces for rdmsr/wrmsr
> emulation when running as a Xen PV guest.
> 
> In order to prepare support for the immediate forms of RDMSR and WRMSR
> when not running as a Xen PV guest, use the RDMSR and WRMSR
> instructions as the fallback case instead of ALT_CALL_INSTR.

I'm trying to evaluate how to add the immediate form MSR instructions
on top of this patch set.  And I'm close to get it done.

> 
> Note that in the Xen PV case the RDMSR/WRMSR patching must not happen
> even as an intermediate step, as this would clobber the indirect call
> information needed when patching in the direct call for the Xen case.

Good point!


Deciding whether to retain the pvops MSR API is the responsibility of
the x86 maintainers, who are the ones experiencing the challenges of 
maintaining the code.

tglx said @https://lore.kernel.org/lkml/87y1h81ht4.ffs@tglx/:

 > I fundamentaly hate adding this to the PV infrastructure. We don't
 > want more PV ops, quite the contrary.

That is the reason I took a different direction, i.e., removing the
pvops MSR APIs.  But if your approach is cleaner, they may prefer it.

> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index a463c747c780..df10b0e4f7b8 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -175,24 +175,72 @@ static inline void __write_cr4(unsigned long x)
>   	PVOP_VCALL1(cpu.write_cr4, x);
>   }
>   
> -static inline u64 paravirt_read_msr(u32 msr)
> +static __always_inline u64 paravirt_read_msr(u32 msr)
>   {
> -	return PVOP_CALL1(u64, cpu.read_msr, msr);
> +	EAX_EDX_DECLARE_ARGS(val, low, high);

This is under CONFIG_PARAVIRT_XXL, thus CONFIG_XEN_PV and CONFIG_X86_64,
therefore we don't need to consider 32-bit at all, no?

> +
> +	PVOP_TEST_NULL(cpu.read_msr);
> +	asm volatile("1: "ALTERNATIVE_2(PARAVIRT_CALL,
> +					"rdmsr", ALT_NOT_XEN,
> +					ALT_CALL_INSTR, ALT_XENPV_CALL)
> +		     "2:\n"
> +		     _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_RDMSR)
> +		     : EAX_EDX_RET(val, low, high), ASM_CALL_CONSTRAINT
> +		     : paravirt_ptr(cpu.read_msr), "c" (msr));
> +
> +	return EAX_EDX_VAL(val, low, high);
>   }
>   
> -static inline void paravirt_write_msr(u32 msr, u64 val)
> +static __always_inline void paravirt_write_msr(u32 msr, u64 val)
>   {
> -	PVOP_VCALL2(cpu.write_msr, msr, val);
> +	PVOP_TEST_NULL(cpu.write_msr);
> +	asm volatile("1: "ALTERNATIVE_2(PARAVIRT_CALL,
> +					"wrmsr", ALT_NOT_XEN,
> +					ALT_CALL_INSTR, ALT_XENPV_CALL)
> +		      "2:\n"
> +		      _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_WRMSR)
> +		      : ASM_CALL_CONSTRAINT
> +		      : paravirt_ptr(cpu.write_msr),
> +			  "c" (msr), "a" ((u32)val), "d" ((u32)(val >> 32))
> +		      : "memory");
>   }
>   
> -static inline int paravirt_read_msr_safe(u32 msr, u64 *val)
> +static __always_inline int paravirt_read_msr_safe(u32 msr, u64 *p)
>   {
> -	return PVOP_CALL2(int, cpu.read_msr_safe, msr, val);
> +	int err;
> +	EAX_EDX_DECLARE_ARGS(val, low, high);
> +
> +	PVOP_TEST_NULL(cpu.read_msr_safe);
> +	asm volatile("1: "ALTERNATIVE_2(PARAVIRT_CALL,
> +					"rdmsr; xor %[err],%[err]", ALT_NOT_XEN,
> +					ALT_CALL_INSTR, ALT_XENPV_CALL)
> +		     "2:\n"
> +		     _ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_RDMSR_SAFE, %[err])
> +		     : [err] "=c" (err), EAX_EDX_RET(val, low, high),
> +		       ASM_CALL_CONSTRAINT
> +		     : paravirt_ptr(cpu.read_msr_safe), "0" (msr));
> +
> +	*p = EAX_EDX_VAL(val, low, high);
> +
> +	return err;
>   }
>   
> -static inline int paravirt_write_msr_safe(u32 msr, u64 val)
> +static __always_inline int paravirt_write_msr_safe(u32 msr, u64 val)
>   {
> -	return PVOP_CALL2(int, cpu.write_msr_safe, msr, val);
> +	int err;
> +
> +	PVOP_TEST_NULL(cpu.write_msr_safe);
> +	asm volatile("1: "ALTERNATIVE_2(PARAVIRT_CALL,
> +					"wrmsr; xor %[err],%[err]", ALT_NOT_XEN,
> +					ALT_CALL_INSTR, ALT_XENPV_CALL)
> +		     "2:\n"
> +		     _ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_WRMSR_SAFE, %[err])
> +		     : [err] "=a" (err), ASM_CALL_CONSTRAINT
> +		     : paravirt_ptr(cpu.write_msr_safe),
> +		       "c" (msr), "0" ((u32)val), "d" ((u32)(val >> 32))
> +		     : "memory");
> +
> +	return err;
>   }
>   
>   static __always_inline u64 read_msr(u32 msr)
> @@ -573,27 +621,43 @@ bool __raw_callee_save___native_vcpu_is_preempted(long cpu);
>   #define PV_SAVE_ALL_CALLER_REGS		"pushl %ecx;"
>   #define PV_RESTORE_ALL_CALLER_REGS	"popl  %ecx;"
>   #else
> +/* save and restore caller-save registers, except %rax, %rcx and %rdx. */
> +#define PV_SAVE_COMMON_CALLER_REGS	\
> +	"push %rsi;"			\
> +	"push %rdi;"			\
> +	"push %r8;"			\
> +	"push %r9;"			\
> +	"push %r10;"			\
> +	"push %r11;"

Add an empty line please, easier to read.

> +#define PV_RESTORE_COMMON_CALLER_REGS	\
> +	"pop %r11;"			\
> +	"pop %r10;"			\
> +	"pop %r9;"			\
> +	"pop %r8;"			\
> +	"pop %rdi;"			\
> +	"pop %rsi;"
> +
> +#define PV_PROLOGUE_MSR(func)		\
> +	PV_SAVE_COMMON_CALLER_REGS	\
> +	PV_PROLOGUE_MSR_##func

Ditto.  And the following similar cases.

> +#define PV_EPILOGUE_MSR(func)		\
> +	PV_EPILOGUE_MSR_##func		\
> +	PV_RESTORE_COMMON_CALLER_REGS
> +
>   /* save and restore all caller-save registers, except return value */
>   #define PV_SAVE_ALL_CALLER_REGS						\
>   	"push %rcx;"							\
>   	"push %rdx;"							\
> -	"push %rsi;"							\
> -	"push %rdi;"							\
> -	"push %r8;"							\
> -	"push %r9;"							\
> -	"push %r10;"							\
> -	"push %r11;"
> +	PV_SAVE_COMMON_CALLER_REGS
>   #define PV_RESTORE_ALL_CALLER_REGS					\
> -	"pop %r11;"							\
> -	"pop %r10;"							\
> -	"pop %r9;"							\
> -	"pop %r8;"							\
> -	"pop %rdi;"							\
> -	"pop %rsi;"							\
> +	PV_RESTORE_COMMON_CALLER_REGS					\
>   	"pop %rdx;"							\
>   	"pop %rcx;"
>   #endif
>   
> +#define PV_PROLOGUE_ALL(func)	PV_SAVE_ALL_CALLER_REGS
> +#define PV_EPILOGUE_ALL(func)	PV_RESTORE_ALL_CALLER_REGS
> +
>   /*
>    * Generate a thunk around a function which saves all caller-save
>    * registers except for the return value.  This allows C functions to
> @@ -607,7 +671,7 @@ bool __raw_callee_save___native_vcpu_is_preempted(long cpu);
>    * functions.
>    */
>   #define PV_THUNK_NAME(func) "__raw_callee_save_" #func
> -#define __PV_CALLEE_SAVE_REGS_THUNK(func, section)			\
> +#define __PV_CALLEE_SAVE_REGS_THUNK(func, section, helper)		\
>   	extern typeof(func) __raw_callee_save_##func;			\
>   									\
>   	asm(".pushsection " section ", \"ax\";"				\
> @@ -617,16 +681,18 @@ bool __raw_callee_save___native_vcpu_is_preempted(long cpu);
>   	    PV_THUNK_NAME(func) ":"					\
>   	    ASM_ENDBR							\
>   	    FRAME_BEGIN							\
> -	    PV_SAVE_ALL_CALLER_REGS					\
> +	    PV_PROLOGUE_##helper(func)					\
>   	    "call " #func ";"						\
> -	    PV_RESTORE_ALL_CALLER_REGS					\
> +	    PV_EPILOGUE_##helper(func)					\
>   	    FRAME_END							\
>   	    ASM_RET							\
>   	    ".size " PV_THUNK_NAME(func) ", .-" PV_THUNK_NAME(func) ";"	\
>   	    ".popsection")
>   
>   #define PV_CALLEE_SAVE_REGS_THUNK(func)			\
> -	__PV_CALLEE_SAVE_REGS_THUNK(func, ".text")
> +	__PV_CALLEE_SAVE_REGS_THUNK(func, ".text", ALL)
> +#define PV_CALLEE_SAVE_REGS_MSR_THUNK(func)		\
> +	__PV_CALLEE_SAVE_REGS_THUNK(func, ".text", MSR)
>   
>   /* Get a reference to a callee-save function */
>   #define PV_CALLEE_SAVE(func)						\
> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> index b08b9d3122d6..f7f879319e90 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -91,15 +91,15 @@ struct pv_cpu_ops {
>   		      unsigned int *ecx, unsigned int *edx);
>   
>   	/* Unsafe MSR operations.  These will warn or panic on failure. */
> -	u64 (*read_msr)(u32 msr);
> -	void (*write_msr)(u32 msr, u64 val);
> +	struct paravirt_callee_save read_msr;
> +	struct paravirt_callee_save write_msr;
>   
>   	/*
>   	 * Safe MSR operations.
>   	 * Returns 0 or -EIO.
>   	 */
> -	int (*read_msr_safe)(u32 msr, u64 *val);
> -	int (*write_msr_safe)(u32 msr, u64 val);
> +	struct paravirt_callee_save read_msr_safe;
> +	struct paravirt_callee_save write_msr_safe;
>   
>   	u64 (*read_pmc)(int counter);
>   
> @@ -520,6 +520,10 @@ unsigned long pv_native_save_fl(void);
>   void pv_native_irq_disable(void);
>   void pv_native_irq_enable(void);
>   unsigned long pv_native_read_cr2(void);
> +void pv_native_rdmsr(void);
> +void pv_native_wrmsr(void);
> +void pv_native_rdmsr_safe(void);
> +void pv_native_wrmsr_safe(void);
>   #endif
>   
>   #define paravirt_nop	((void *)nop_func)
> @@ -527,6 +531,7 @@ unsigned long pv_native_read_cr2(void);
>   #endif	/* __ASSEMBLER__ */
>   
>   #define ALT_NOT_XEN	ALT_NOT(X86_FEATURE_XENPV)
> +#define ALT_XENPV_CALL	ALT_DIRECT_CALL(X86_FEATURE_XENPV)
>   
>   #endif  /* CONFIG_PARAVIRT */
>   #endif	/* _ASM_X86_PARAVIRT_TYPES_H */
> diff --git a/arch/x86/include/asm/qspinlock_paravirt.h b/arch/x86/include/asm/qspinlock_paravirt.h
> index 0a985784be9b..0351acb5a143 100644
> --- a/arch/x86/include/asm/qspinlock_paravirt.h
> +++ b/arch/x86/include/asm/qspinlock_paravirt.h
> @@ -14,7 +14,8 @@ void __lockfunc __pv_queued_spin_unlock_slowpath(struct qspinlock *lock, u8 lock
>    */
>   #ifdef CONFIG_64BIT
>   
> -__PV_CALLEE_SAVE_REGS_THUNK(__pv_queued_spin_unlock_slowpath, ".spinlock.text");
> +__PV_CALLEE_SAVE_REGS_THUNK(__pv_queued_spin_unlock_slowpath, ".spinlock.text",
> +			    ALL);
>   #define __pv_queued_spin_unlock	__pv_queued_spin_unlock
>   
>   /*
> @@ -61,7 +62,7 @@ DEFINE_ASM_FUNC(__raw_callee_save___pv_queued_spin_unlock,
>   #else /* CONFIG_64BIT */
>   
>   extern void __lockfunc __pv_queued_spin_unlock(struct qspinlock *lock);
> -__PV_CALLEE_SAVE_REGS_THUNK(__pv_queued_spin_unlock, ".spinlock.text");
> +__PV_CALLEE_SAVE_REGS_THUNK(__pv_queued_spin_unlock, ".spinlock.text", ALL);
>   
>   #endif /* CONFIG_64BIT */
>   #endif
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index 015bf298434f..ff7d7fdae360 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -50,6 +50,24 @@ DEFINE_ASM_FUNC(pv_native_save_fl, "pushf; pop %rax", .noinstr.text);
>   DEFINE_ASM_FUNC(pv_native_irq_disable, "cli", .noinstr.text);
>   DEFINE_ASM_FUNC(pv_native_irq_enable, "sti", .noinstr.text);
>   DEFINE_ASM_FUNC(pv_native_read_cr2, "mov %cr2, %rax", .noinstr.text);
> +DEFINE_ASM_FUNC(pv_native_rdmsr,
> +		"1: rdmsr\n"
> +		"2:\n"
> +		_ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_RDMSR), .noinstr.text);
> +DEFINE_ASM_FUNC(pv_native_wrmsr,
> +		"1: wrmsr\n"
> +		"2:\n"
> +		_ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_WRMSR), .noinstr.text);
> +DEFINE_ASM_FUNC(pv_native_rdmsr_safe,
> +		"1: rdmsr; xor %ecx, %ecx\n"
> +		"2:\n"
> +		_ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_RDMSR_SAFE, %%ecx),
> +		.noinstr.text);
> +DEFINE_ASM_FUNC(pv_native_wrmsr_safe,
> +		"1: wrmsr; xor %eax, %eax\n"
> +		"2:\n"
> +		_ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_WRMSR_SAFE, %%eax),
> +		.noinstr.text);
>   #endif
>   
>   DEFINE_STATIC_KEY_FALSE(virt_spin_lock_key);
> @@ -129,10 +147,10 @@ struct paravirt_patch_template pv_ops = {
>   	.cpu.read_cr0		= native_read_cr0,
>   	.cpu.write_cr0		= native_write_cr0,
>   	.cpu.write_cr4		= native_write_cr4,
> -	.cpu.read_msr		= native_read_msr,
> -	.cpu.write_msr		= native_write_msr,
> -	.cpu.read_msr_safe	= native_read_msr_safe,
> -	.cpu.write_msr_safe	= native_write_msr_safe,
> +	.cpu.read_msr		= __PV_IS_CALLEE_SAVE(pv_native_rdmsr),
> +	.cpu.write_msr		= __PV_IS_CALLEE_SAVE(pv_native_wrmsr),
> +	.cpu.read_msr_safe	= __PV_IS_CALLEE_SAVE(pv_native_rdmsr_safe),
> +	.cpu.write_msr_safe	= __PV_IS_CALLEE_SAVE(pv_native_wrmsr_safe),
>   	.cpu.read_pmc		= native_read_pmc,
>   	.cpu.load_tr_desc	= native_load_tr_desc,
>   	.cpu.set_ldt		= native_set_ldt,
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 3be38350f044..c279b2bef7eb 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -1160,36 +1160,66 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err)
>   	}
>   }
>   
> -static int xen_read_msr_safe(u32 msr, u64 *val)
> -{
> +/*
> + * Prototypes for functions called via PV_CALLEE_SAVE_REGS_THUNK() in order
> + * to avoid warnings with "-Wmissing-prototypes".
> + */
> +struct xen_rdmsr_safe_ret {
> +	u64 val;
>   	int err;
> +};
> +struct xen_rdmsr_safe_ret xen_read_msr_safe(u32 msr);
> +int xen_write_msr_safe(u32 msr, u32 low, u32 high);
> +u64 xen_read_msr(u32 msr);
> +void xen_write_msr(u32 msr, u32 low, u32 high);
>   
> -	*val = xen_do_read_msr(msr, &err);
> -	return err;
> +__visible struct xen_rdmsr_safe_ret xen_read_msr_safe(u32 msr)
> +{
> +	struct xen_rdmsr_safe_ret ret;

struct xen_rdmsr_safe_ret ret = { 0, 0 };

Because the 'err' member may not be set in xen_do_read_msr().

> +
> +	ret.val = xen_do_read_msr(msr, &ret.err);
> +	return ret;
>   }
> +#define PV_PROLOGUE_MSR_xen_read_msr_safe	"mov %ecx, %edi;"
> +#define PV_EPILOGUE_MSR_xen_read_msr_safe	\
> +	"mov %edx, %ecx; mov %rax, %rdx; mov %eax, %eax; shr $0x20, %rdx;"
> +PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_read_msr_safe);
>   
> -static int xen_write_msr_safe(u32 msr, u64 val)
> +__visible int xen_write_msr_safe(u32 msr, u32 low, u32 high)

I think we can avoid splitting this u64 into two u32.

>   {
>   	int err = 0;
>   
> -	xen_do_write_msr(msr, val, &err);
> +	xen_do_write_msr(msr, (u64)high << 32 | low, &err);
>   
>   	return err;
>   }
> +#define PV_PROLOGUE_MSR_xen_write_msr_safe	\
> +	"mov %ecx, %edi; mov %eax, %esi;"
> +#define PV_EPILOGUE_MSR_xen_write_msr_safe
> +PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_write_msr_safe);
>   
> -static u64 xen_read_msr(u32 msr)
> +__visible u64 xen_read_msr(u32 msr)
>   {
>   	int err;
>   
>   	return xen_do_read_msr(msr, xen_msr_safe ? &err : NULL);
>   }
> +#define PV_PROLOGUE_MSR_xen_read_msr	"mov %ecx, %edi;"
> +#define PV_EPILOGUE_MSR_xen_read_msr	\
> +	"mov %rax, %rdx; mov %eax, %eax; shr $0x20, %rdx;"
> +PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_read_msr);
>   
> -static void xen_write_msr(u32 msr, u64 val)
> +__visible void xen_write_msr(u32 msr, u32 low, u32 high)

Ditto.

>   {
>   	int err;
>   
> -	xen_do_write_msr(msr, val, xen_msr_safe ? &err : NULL);
> +	xen_do_write_msr(msr, (u64)high << 32 | low,
> +			 xen_msr_safe ? &err : NULL);
>   }
> +#define PV_PROLOGUE_MSR_xen_write_msr	\
> +	"mov %ecx, %edi; mov %eax, %esi;"
> +#define PV_EPILOGUE_MSR_xen_write_msr
> +PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_write_msr);
>   
>   /* This is called once we have the cpu_possible_mask */
>   void __init xen_setup_vcpu_info_placement(void)


From xen-devel-bounces@lists.xenproject.org Fri May 09 08:32:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 08:32:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979855.1366349 (Exim 4.92)
	(envelope-from )
	id 1uDJ9r-0008Vo-61; Fri, 09 May 2025 08:32:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979855.1366349; Fri, 09 May 2025 08:32: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 1uDJ9r-0008Vh-2B; Fri, 09 May 2025 08:32:39 +0000
Received: by outflank-mailman (input) for mailman id 979855;
 Fri, 09 May 2025 08:32:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJ9q-0008Vb-Aa
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 08:32:38 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 29c565ba-2cb0-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 10:32:37 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a0ebf39427so1072328f8f.3
 for ; Fri, 09 May 2025 01:32:37 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442d67df501sm21428095e9.12.2025.05.09.01.32.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 01:32: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" 
X-Inumbo-ID: 29c565ba-2cb0-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746779557; x=1747384357; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Vl9QXZhP2PtHOKqfwTNonRH4d4XLqAkjriB6+g4TTq4=;
        b=u6rsmKFIzZx1ETuMSNP5g/bUD1NNwnoa8vWfMhsE59jyrHsABpI8oMZfN+ciw2Edr7
         FITAaQHKgYSc4Gem+fgrQcZdX+nHJZipITxO1Sq1EjhFJjaZFhRd8Q9sb9y0t0sT07/K
         sp2t2eEvdeMvmCv0UR8wDfHzxTUs4/bVM82X8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746779557; x=1747384357;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Vl9QXZhP2PtHOKqfwTNonRH4d4XLqAkjriB6+g4TTq4=;
        b=ZDgoxFUIPCCWAep//HPE9suSHmXDnWbYRzIwiFKe7Vl2UttJP/SfhB94WJcHI8kFeV
         ejJLAUVvU+KDFR6loK8d2V3bu5Uxjs4iislx9rGX2skco21/Dzfw4h474bRzdWz47zEy
         1NPhuC3u1kkimRIUlx5I9eA3xxpzO/n/pU2+K63CdhtbaQXlJ3NTs0zG1E55MXqQszkj
         wnqEdZXTCEkXmbBoaIDUuWc+2ZbOqTFOK9Lk05iN5vn61PVjBlHlyqC1qoElJM33xpcA
         4lg9v/TIzjfNTpon1M732imlAfSnzcWgIOYxtY3By2Ra7zQjD23ep3Ul1UI+lPxF/lw9
         oi7g==
X-Forwarded-Encrypted: i=1; AJvYcCUPFKzTlU1wws8I+7qH8bJZ/ZocyIuFD2/ZEmag3fjNb6cJuXXMxvrNpJvAMZHAUdMkuMwoTZfw9kY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywbtxlg7W19yCww+QljaaSkq7UGDHDk+B1oMV3rD6B0x1jVP8xF
	EFl0bYQGr6mn6Jy9mKfiBV4VjYVM3g/zSviu+2uFFPzHA30l6R5ARw1uc/K0dw4=
X-Gm-Gg: ASbGnctcU62B55AvMk6/OC6wltoVn45s3A6NREucFsP6V2pAjcmM2OuOWL3ZoAPKkxY
	HABgx1nnLTE/yCkGeoPFOCKups4I5oV2l91lHgjLYRhDHf0eQEpz1NMHoni3aniqlyFTP5snemZ
	VAma2dtZ93mlAHAoKT1H9qfh4Vt4qJ/HcvlX/ihAVjeJ6JvzQxuSlGLoIrNJ9J7UbJuEvIwl8BF
	SP6sXN0Q3wsfWPqkX2thGCkFdTJjueDQoXa5NeYhWxLrF5UzExVUT1qyMGwG/zGXyHAqcX5kX2W
	JExNZmMqA8BmS0F0bt4Itetn4QpY3gW1BRFQgY+gGQuuEkOIuki/Kx3U5eHUJg==
X-Google-Smtp-Source: AGHT+IHOoLpYrA8FkyKDRGOSMF/mmTMy24sLAc297FwPjjfP9gSHfxathBrMwLTPDHN+KO85GFYSBg==
X-Received: by 2002:a05:6000:40e1:b0:3a1:1c39:37c with SMTP id ffacd0b85a97d-3a1f64ae6f8mr2081020f8f.58.1746779556815;
        Fri, 09 May 2025 01:32:36 -0700 (PDT)
Date: Fri, 9 May 2025 10:32:35 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stefano Stabellini 
Cc: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	Jan Beulich ,
	"Ragiadakou, Xenia" ,
	Andrew Cooper , jason.andryuk@amd.com,
	agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
Message-ID: 
References: 
 <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>
 
 
 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, May 08, 2025 at 04:25:28PM -0700, Stefano Stabellini wrote:
> On Thu, 8 May 2025, Roger Pau Monné wrote:
> > On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
> > > On Tue, 6 May 2025, Roger Pau Monné wrote:
> > > > On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
> > > > > On Mon, 5 May 2025, Roger Pau Monné wrote:
> > > > > > On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> > > > > > > On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
> > > > > > > > On Mon, 28 Apr 2025, Jan Beulich wrote:
> > > > > > > > > On 25.04.2025 22:19, Stefano Stabellini wrote:
> > > > > > > > > > From: Xenia Ragiadakou 
> > > > > > > > > > 
> > > > > > > > > > Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> > > > > > > > > > addresses to firmware or co-processors not behind an IOMMU.
> > > > > > > > > 
> > > > > > > > > I definitely don't understand the firmware part: It's subject to the
> > > > > > > > > same transparent P2M translations as the rest of the VM; it's just
> > > > > > > > > another piece of software running there.
> > > > > > > > > 
> > > > > > > > > "Co-processors not behind an IOMMU" is also interesting; a more
> > > > > > > > > concrete scenario might be nice, yet I realize you may be limited in
> > > > > > > > > what you're allowed to say.
> > > > > > > > 
> > > > > > > > Sure. On AMD x86 platforms there is a co-processor called PSP running
> > > > > > > > TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionally to
> > > > > > > > pass addresses to it.  See drivers/tee/amdtee/ and
> > > > > > > > include/linux/psp-tee.h in Linux.
> > > > > > > 
> > > > > > > We had (have?) similar issue with amdgpu (for integrated graphics) - it
> > > > > > > uses PSP for loading its firmware. With PV dom0 there is a workaround as
> > > > > > > dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, but I
> > > > > > > expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's
> > > > > > > the one I used for debugging this issue).
> > > > > > 
> > > > > > That's ugly, and problematic when used in conjunction with AMD-SEV.
> > > > > > 
> > > > > > I wonder if Xen could emulate/mediate some parts of the PSP for dom0
> > > > > > to use, while allowing Xen to be the sole owner of the device.  Having
> > > > > > both Xen and dom0 use it (for different purposes) seems like asking
> > > > > > for trouble.  But I also have no idea how complex the PSP interface
> > > > > > is, neither whether it would be feasible to emulate the
> > > > > > interfaces/registers needed for firmware loading.
> > > > > 
> > > > > Let me take a step back from the PSP for a moment. I am not opposed to a
> > > > > PSP mediator in Xen, but I want to emphasize that the issue is more
> > > > > general and extends well beyond the PSP.
> > > > > 
> > > > > In my years working in embedded systems, I have consistently seen cases
> > > > > where Dom0 needs to communicate with something that does not go through
> > > > > the IOMMU. This could be due to special firmware on a co-processor, a
> > > > > hardware erratum that prevents proper IOMMU usage, or a high-bandwidth
> > > > > device that technically supports the IOMMU but performs poorly unless
> > > > > the IOMMU is disabled. All of these are real-world examples that I have
> > > > > seen personally.
> > > > 
> > > > I wouldn't be surprised, classic PV dom0 avoided those issues because
> > > > it was dealing directly with host addresses (mfns), but that's not the
> > > > case with PVH dom0.
> > > 
> > > Yeah
> > > 
> > > 
> > > > > In my opinion, we definitely need a solution like this patch for Dom0
> > > > > PVH to function correctly in all scenarios.
> > > > 
> > > > I'm not opposed to having such interface available for PVH hardware
> > > > domains.  I find it ugly, but I don't see much other way to deal with
> > > > those kind of "devices".  Xen mediating accesses for each one of them
> > > > is unlikely to be doable.
> > > > 
> > > > How do you hook this exchange interface into Linux to differentiate
> > > > which drivers need to use mfns when interacting with the hardware?
> > > 
> > > In the specific case we have at hands the driver is in Linux userspace
> > > and is specially-written for our use case. It is not generic, so we
> > > don't have this problem. But your question is valid.
> > 
> > Oh, so you then have some kind of ioctl interface that does the memory
> > exchange and bouncing inside of the kernel on behalf of the user-space
> > side I would think?
> 
> I am not sure... Xenia might know more than me here.

One further question I have regarding this approach: have you
considered just populating an empty p2m space with contiguous physical
memory instead of exchanging an existing area?  That would increase
dom0 memory usage, but would prevent super page shattering in the p2m.
You could use a dom0_mem=X,max:X+Y command line option, where Y
would be your extra room for swiotlb-xen bouncing usage.

XENMEM_increase_reservation documentation notes such hypercall already
returns the base MFN of the allocated page (see comment in
xen_memory_reservation struct declaration).

> > > In Linux, the issue is hidden behind drivers/xen/swiotlb-xen.c and
> > > xen_arch_need_swiotlb. There are a few options:
> > > - force swiotlb bounce for everything on the problematic SoC
> > > - edit xen_arch_need_swiotlb to return true for the problematic device
> > > - introduce a kernel command line option to specify which device
> > >   xen_arch_need_swiotlb should return true for
> > 
> > Isn't it a bit misleading to use the swiotlb for this purpose?  Won't
> > this usage of the swiotlb (to bounce from gfns to mfns) create issues
> > if there's any devices that have a DMA physical address limitation and
> > also needs to use the swiotlb while being behind the IOMMU?
> 
> When I wrote swiotlb, I meant swiotlb-xen (drivers/xen/swiotlb-xen.c).
> We have been using it exactly for this kind of address translations so
> far. It can also deal with cases where genuine bouncing needs to happen.

Oh, I see.  I've assumed you meant the generic Linux swiotlb.

So you have repurposed swiotlb-xen to be used on PVH for this purpose.
I think (currently?) swiotlb-xen is unconditionally disabled for
HVM/PVH guests?

> > > - introduce an ACPI table with the relevant info
> > 
> > Hm, best option might be an ACPI table so that Xen can signal to the
> > hardware domain whether communication with the device must be done
> > using mfns, or if accesses are mediated and hence can be done using
> > gfns?
> 
> Yeah
> 
> 
> > It's a bit cumbersome however to have to resort to an ACPI table just
> > for this.  Not sure whether we could expand one of the existing tables
> > already under Xen control (STAO?) to contain this information.  It all
> > looks a bit ad-hoc.
> > 
> > I think we need some kind of list of devices that are not behind the
> > IOMMU, but I have no idea what URI to use to identify those.  I assume
> > the PSP doesn't have a PCI SBDF (as it's not on the PCI bus?).  Maybe
> > by ACPI path?
> 
> Yes, we have a similar issue with the STAO table in terms of which
> identifiers to use. STAO uses: "A list of ACPI strings, where each
> string is the full path name in the ACPI namespace of the device"
> 
> 
> > Or maybe it's fine to always communicate with those non-translated
> > devices using MFNs, and even if we later add some kind of PSP
> > mediation (so that both Xen and dom0 can use it), accesses by dom0
> > will still be assumed to be using MFNs, and thus need no translation.
> 
> I think it is easy to enable/disable GFN/MFN for a device like PSP. We
> can communicate to Linux in many ways this change in behavior.

In fact my biggest concern with the PSP explicitly is not so much the
usage of MFN/GFNs, I think it would be fine for the hardware domain to
unconditionally use MFNs for interactions with the device.

I worry how are we going to reconcile both Xen and the hardware domain
having to use the device, as I have no idea how complex the interface
is, so no idea how much code we would need to add to Xen to mediate a
external domain accesses.  Anyway, that's a question for later really.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 09 08:53:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 08:53:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979864.1366359 (Exim 4.92)
	(envelope-from )
	id 1uDJU8-0002va-O7; Fri, 09 May 2025 08:53:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979864.1366359; Fri, 09 May 2025 08:53: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 1uDJU8-0002vT-LB; Fri, 09 May 2025 08:53:36 +0000
Received: by outflank-mailman (input) for mailman id 979864;
 Fri, 09 May 2025 08:53:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJU7-0002vN-Mf
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 08:53:35 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 167f31fd-2cb3-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 10:53:33 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-43cf257158fso12135475e9.2
 for ; Fri, 09 May 2025 01:53:33 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a1f5a4cc2esm2608437f8f.90.2025.05.09.01.53.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 01:53: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" 
X-Inumbo-ID: 167f31fd-2cb3-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746780813; x=1747385613; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=FeHJ+5duaoOXuLNSG7JYnGnc3BvwUMlD8pqjJhdAsmI=;
        b=GLnVjiL6F3Pg2mm127awdcDTHBvYFIpo7YSVzHCZpSb6XP5qKABFeyOa1GaI7CfMzu
         UOrnbCi5+cAeLhcktuwMEGKlsTq5h0EvRZ7ET8KIVQxgy2kumwJ/TMSzZP5EDFIWdvKt
         4WFgq8FNxn1e5rx9bkQM2pZvG63phX6XRm3yo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746780813; x=1747385613;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=FeHJ+5duaoOXuLNSG7JYnGnc3BvwUMlD8pqjJhdAsmI=;
        b=MpTpTA29nEkr3iYfU3nExazu95RnuU3xCL2CSt8NqxICihpQwq/6A1cIDjOIBk+YDl
         vlMKi83/twyiUJEIBfr388/DBJ8MO3Al9Uti6BNd+jew/Dp02dtZyeqjVziyXMUV8xh6
         +TLKUKlFMeID5kA+rcJVKK9a9g2BvVfhmKZTAubBYsMd8GxYNL2/IN0nN/44vX3rC6xS
         /IJ1GSYgSeFeq/JZspRH62pK95+N4vlcsPZ6Klow3q06RU+3S0hzr6dbTkNrscdgulFG
         HSBDdmzZPMMlJOQbnwi2k5cCpqC12nx1Ss7qa+Wnx85e6rhBcVzC7jCCspvBv0JUfiZz
         sPVw==
X-Forwarded-Encrypted: i=1; AJvYcCVIe00vElLBUfRr7/NayttBpn/xnstMACKgESeiN+gDmoU9xeTRPpoEe31gy2ahNXkQSh3fwVbSvzA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx1A+eO8aTWYWIp7rpW2xe//0jIm/SuW3AxbeDs+mBY/YLVpM66
	Kqwkh0z0M1TmlytoQ2QoC2a5hO9g5KdB2SL4TGTYsLSXIAKuPtisiegs8LWdz2g=
X-Gm-Gg: ASbGncvQ5KVdHajqOOuMV6VLJoIXlFQAGtJO2LCUh9YOa0Szf64zg6Rt3pCO5Cui4UH
	NgLudN4y1KwJmmVFgek3Y1By0vW9rQK98KFO3XuMa4JmbI8/Us4k4bYY+PmQdbzVNeltJONw+Ti
	E8rZ7981k6K1Y+Ne8KGB0SRwqgHroHU336li36Ki4/GNZKzmk4gPpA6gNVS+ZvxRVWkZS11+1tT
	HjkD4lx5kr26HvlG7HiLYUGqLwC/o8uLiga2Oos72YMHJ13pTub5452RXTTNkZ1LZ+8KjPGPn5A
	8Cqa+XDPhG8TxB+vKDac0ri8GK9Adav3XEbztKKyIXJrmVjDvZswGztY
X-Google-Smtp-Source: AGHT+IEfBkk8+Thr9UsmUcJiEGjSJh3YIPTjfONmG7mUHZ4NeTKVvva3PIgVOVDHe9F777Jrc5y/Ow==
X-Received: by 2002:a05:600c:3587:b0:440:59eb:bfc with SMTP id 5b1f17b1804b1-442d6dd2378mr15367705e9.23.1746780812972;
        Fri, 09 May 2025 01:53:32 -0700 (PDT)
Date: Fri, 9 May 2025 10:53:31 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Demi Marie Obenour 
Cc: Xenia Ragiadakou ,
	Stefano Stabellini ,
	Alejandro Vallejo ,
	Xen developer discussion ,
	Andrew Cooper ,
	Juergen Gross ,
	Xen-devel 
Subject: Re: Mapping memory into a domain
Message-ID: 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Fri, May 09, 2025 at 12:52:28AM -0400, Demi Marie Obenour wrote:
> On 5/8/25 3:52 AM, Roger Pau Monné wrote:
> > On Wed, May 07, 2025 at 08:36:07PM -0400, Demi Marie Obenour wrote:
> >> On 5/7/25 1:39 PM, Roger Pau Monné wrote:
> >>> On Tue, May 06, 2025 at 04:56:12PM -0400, Demi Marie Obenour wrote:
> >>>> On 5/6/25 9:06 AM, Alejandro Vallejo wrote:
> >>>>> On Tue May 6, 2025 at 3:02 AM CEST, Demi Marie Obenour wrote:
> >>>>>> On 5/5/25 7:32 AM, Alejandro Vallejo wrote:
> >>>>>>> I suppose this is still about multiplexing the GPU driver the way we
> >>>>>>> last discussed at Xen Summit?
> >>>>>>>
> >>>>>>> On Mon May 5, 2025 at 12:51 AM CEST, Demi Marie Obenour wrote:
> >>>>>>>> What are the appropriate Xen internal functions for:
> >>>>>>>>
> >>>>>>>> 1. Turning a PFN into an MFN?
> >>>>>>>> 2. Mapping an MFN into a guest?
> >>>>>>>> 3. Unmapping that MFN from a guest?
> >>>>>>>
> >>>>>>> The p2m is the single source of truth about such mappings.
> >>>>>>>
> >>>>>>> This is all racy business. You want to keep the p2m lock for the full
> >>>>>>> duration of whatever operation you wish do, or you risk another CPU
> >>>>>>> taking it and pulling the rug under your feet at the most inconvenient
> >>>>>>> time.
> >>>>>>>
> >>>>>>> In general all this faff is hidden under way too many layers beneath
> >>>>>>> copy_{to,from}_guest(). Other p2m manipulation high-level constructs
> >>>>>>> that might do interesting things worth looking at may be {map,unmap}_mmio_region()
> >>>>>>>
> >>>>>>> Note that not every pfn has an associated mfn. Not even every valid pfn
> >>>>>>> has necessarily an associated mfn (there's pod). And all of this is
> >>>>>>> volatile business in the presence of a baloon driver or vPCI placing
> >>>>>>> mmio windows over guest memory.
> >>>>>>
> >>>>>> Can I check that POD is not in use?  
> >>>>>
> >>>>> Maybe, but now you're reaching exponential complexity considering each
> >>>>> individual knob of the p2m into account.
> >>>>>
> >>>>>>
> >>>>>>> In general anything up this alley would need a cohesive pair for
> >>>>>>> map/unmap and a credible plan for concurrency and how it's all handled
> >>>>>>> in conjunction with other bits that touch the p2m.
> >>>>>>
> >>>>>> Is taking the p2m lock for the entire operation a reasonable approach
> >>>>>> for concurrency?  Will this cause too much lock contention?
> >>>>>
> >>>>> Maybe. It'd be fine for a page. Likely not so for several GiB if they
> >>>>> aren't already superpages.
> >>>>>
> >>>>>>
> >>>>>>>> The first patch I am going to send with this information is a documentation
> >>>>>>>> patch so that others do not need to figure this out for themselves.
> >>>>>>>> I remember being unsure even after looking through the source code, which
> >>>>>>>> is why I am asking here.
> >>>>>>>
> >>>>>>> That's not surprising. There's per-arch stuff, per-p2mtype stuff,
> >>>>>>> per-guesttype stuff. Plus madness like on-demand memory. It's no wonder
> >>>>>>> such helpers don't exist and the general manipulations are hard to
> >>>>>>> explain.
> >>>>>>
> >>>>>> Is this a task that is only suitable for someone who has several years
> >>>>>> experience working on Xen, or is it something that would make sense for
> >>>>>> someone who is less experienced?
> >>>>>
> >>>>> The p2m is a very complex beast that integrates more features than I
> >>>>> care to count. It requires a lot of prior knowledge. Whoever does it
> >>>>> must know Xen fairly well in many configurations.
> >>>>>
> >>>>> The real problem is finding the right primitives that do what you want
> >>>>> without overcomplicating everything else, preserving system security
> >>>>> invariants and have benign (and ideally clear) edge cases.
> >>>>>
> >>>>> This was the last email you sent (I think?). Has any of the requirements
> >>>>> changed in any direction?
> >>>>>
> >>>>>   https://lore.kernel.org/xen-devel/Z5794ysNE4KDkFuT@itl-email/
> >>>>
> >>>> Map and Revoke are still needed, with the same requirements as described
> >>>> in this email.  Steal and Return were needed for GPU shared virtual memory,
> >>>> but it has been decided to not support this with virtio-GPU, so these
> >>>> primitives are no longer needed.
> >>>>
> >>>>> Something I'm missing there is how everything works without Xen. That
> >>>>> might help (me, at least) guage what could prove enough to support the
> >>>>> usecase. Are there sequence diagrams anywhere about how this whole thing
> >>>>> works without Xen? I vaguely remember you showing something last year in
> >>>>> Xen Summit in the design session, but my memory isn't that good :)
> >>>
> >>> Hello,
> >>>
> >>> Sorry, possibly replying a bit out of context here.
> >>>
> >>> Since I will mention this in several places: p2m is the second stage
> >>> page-tables used by Xen for PVH and HVM guests.  A p2m violation is
> >>> the equivalent of a page-fault for guest p2m accesses.
> >>>
> >>>> A Linux driver that needs access to userspace memory
> >>>> pages can get it in two different ways:
> >>>>
> >>>> 1. It can pin the pages using the pin_user_pages family of APIs.
> >>>>    If these functions succeed, the driver is guaranteed to be able
> >>>>    to access the pages until it unpins them.  However, this also
> >>>>    means that the pages cannot be paged out or migrated.  Furthermore,
> >>>>    file-backed pages cannot be safely pinned, and pinning GPU memory
> >>>>    isn’t supported.  (At a minimum, it would prevent the pages from
> >>>>    migrating from system RAM to VRAM, so all access by a dGPU would
> >>>>    cross the PCIe bus, which would be very slow.)
> >>>
> >>> From a Xen p2m this is all fine - Xen will never remove pages from the
> >>> p2m unless it's requested to.  So the pining, while needed on the Linux
> >>> side, doesn't need to be propagated to Xen I would think.
> >>
> >> If pinning were enough things would be simple, but sadly it’s not.
> >>
> >>>> 2. It can grab the *current* location of the pages and register an
> >>>>    MMU notifier.  This works for GPU memory and file-backed memory.
> >>>>    However, when the invalidate_range function of this callback, the
> >>>>    driver *must* stop all further accesses to the pages.
> >>>>
> >>>>    The invalidate_range callback is not allowed to block for a long
> >>>>    period of time.  My understanding is that things like dirty page
> >>>>    writeback are blocked while the callback is in progress.  My
> >>>>    understanding is also that the callback is not allowed to fail.
> >>>>    I believe it can return a retryable error but I don’t think that
> >>>>    it is allowed to keep failing forever.
> >>>>
> >>>>    Linux’s grant table driver actually had a bug in this area, which
> >>>>    led to deadlocks.  I fixed that a while back.
> >>>>
> >>>> KVM implements the second option: it maps pages into the stage-2
> >>>> page tables (or shadow page tables, if that is chosen) and unmaps
> >>>> them when the invalidate_range callback is called.
> >>>
> >>> I assume this map and unmap is done by the host as a result of some
> >>> guest action?
> >>
> >> Unmapping can happen at any time for any or no reason.  Semantically,
> >> it would be correct to only map the pages in response to a p2m violation,
> >> but for performance it might be better to map the pages eagerly instead.
> > 
> > That's an implementation detail, you can certainly map the pages
> > eagerly, or even map multiple contiguous pages as a result of a single
> > p2m violation.
> > 
> > I would focus on making a functioning prototype first, performance
> > comes afterwards.
> 
> Makes sense.
> 
> >>>> Furthermore,
> >>>> if a page fault happens while the page is unmapped, KVM will try
> >>>> to bring the pages back into memory so the guest can access it.
> >>>
> >>> You could likely handle this in Xen in the following way:
> >>>
> >>>  - A device model will get p2m violations forwarded, as it's the same
> >>>    model that's used to handle emulation of device MMIO.  You will
> >>>    need to register an ioreq server to request those faults to be
> >>>    forwarded, I think the hardware domain kernel will handle those?
> >>>
> >>>  - Allow ioreqs to signal to Xen that a guest operation must be
> >>>    retried.  IOW: resume guest execution without advancing the IP.
> >>>
> >>> I think this last bit is the one that will require changes to Xen, so
> >>> that you can add a type of ioreq reply that implies a retry from the
> >>> guest context.
> >> I’m not actually sure if this is needed, though it would be nice.  It
> >> might be possible for Xen to instead emulate the current instruction and
> >> continue, with the ioreq server just returning the current value of the
> >> pages.
> > 
> > You can, indeed, but it's cumbersome?  You might have to map the page
> > in the context of the entity that implements the ioreq server to
> > access the data.  Allowing retries would be more generic, and reduce
> > the code in the ioreq server handler, that would only map the page
> > to the guest p2m and request a retry.
> 
> Yeah, it is cumbersome indeed.
> 
> >> What I’m more concerned about is being able to provide a page
> >> into the p2m so that the *next* access doesn’t fault, and being able
> >> to remove that page from the p2m so that the next access *does* fault.
> > 
> > Maybe I'm not getting the question right, all Xen modifications to the
> > p2m take immediate effect.  By the time a XEN_DOMCTL_memory_mapping
> > hypercall returns the operation would have taken effect.
> 
> Ah, that makes sense.  When revoking access, can XEN_DOMCTL_iomem_permission
> and XEN_DOMCTL_memory_mapping fail even if the parameters are correct and
> the caller has enough permissions, or will they always succeed?

They can fail, but not for a guest induced reason.

For example XEN_DOMCTL_iomem_permission manipulates a rangeset and
revoking access might require a range to be split, and hence memory
allocated.  That allocation of memory can fail, but that's not under
guest control.

> >> Are there any hypercalls that can be used for these operations right
> >> now?
> > 
> > With some trickery you could likely use XEN_DOMCTL_memory_mapping to
> > add and remove those pages.  You will need calls to
> > XEN_DOMCTL_iomem_permission beforehand so that you grant the receiving
> > domain permissions to access those (and of course the granting domain
> > needs to have full access to them).
> > 
> > This is no ideal if mapping RAM pages, AFAICT there are no strict
> > checks that the added page is not RAM, but still you will need to
> > handle RAM pages as IOMEM so and grant them using
> > XEN_DOMCTL_iomem_permission which is not great.  Also note that this
> > is a domctl, so not stable.  It might however be enough for a
> > prototype.
> 
> Unfortunately this won’t work if the backend is a PVH domain, as a PVH
> domain doesn’t know its own MFNs.  It also won’t work for deprivileged
> backends because XEN_DOMCTL_iomem_permission is subject to XSA-77.

Hm, I think solving this will be complicated using a single hypercall,
because you have to deal with both MMIO and RAM, which are
traditionally handled differently in Xen, also when mapped in the
p2m.

You could possibly use XENMEM_add_to_physmap_batch to create a foreign
mapping in a remote guest p2m when mapping RAM, and
XEN_DOMCTL_memory_mapping when mapping IOMEM.  But that requires the
emulator/mediator to know when it's attempting to map RAM or IOMEM
(which I think you wanted to avoid?)

Otherwise a new XENMEM_add_to_physmap{,_batch} `phys_map_space` option
needs to be added to cater for your requirements.

> > Long term I think we want to expand XENMEM_add_to_physmap{,_batch} to
> > handle this use-case.
> 
> That would indeed be better.
> 
> >> If not, which Xen functions would one use to implement them?
> >> Some notes:
> >>
> >> - The p2m might need to be made to point to a PCI BAR or system RAM.
> >>   The guest kernel and host userspace don’t know which, and in any
> >>   case don’t need to care.  The host kernel knows, but I don’t know
> >>   if the information is exposed to the Xen driver.
> > 
> > Hm, as said above, while you could possible handle RAM as IOMEM, it
> > has the slight inconvenience of having to add such RAM pages to the
> > d->iomem_caps rangeset for XEN_DOMCTL_memory_mapping to succeed.
> > 
> > From a guest PoV, it doesn't matter if the underlying page is RAM or
> > MMIO, as long as it's mapped in the p2m.
> 
> Understood, thanks!
> 
> >> - If the p2m needs to point to system RAM, the RAM will be memory
> >>   that belongs to the backend.
> >>
> >> - If the p2m needs to point to a PCI BAR, it will initially need
> >>   to point to a real PCI device that is owned by the backend.
> > 
> > As long as you give the destination domain access to the page using
> > XEN_DOMCTL_iomem_permission prior to the XEN_DOMCTL_memory_mapping
> > call it should work.
> > 
> > How does this work for device DMA accesses?  If the device is assigned
> > to the backend domain (and thus using the backend domain IOMMU context
> > entry and page-tables) DMA accesses cannot be done against guest
> > provided addresses, there needs to be some kind of translation layer
> > that filters commands?
> 
> Thankfully, this is handled by the backend.

Oh, I see.  So the device IOMMU context is always set to the hardware
domain one, and the emulator handles all the translation required?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 09 09:06:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:06:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979878.1366369 (Exim 4.92)
	(envelope-from )
	id 1uDJgJ-0004l9-UG; Fri, 09 May 2025 09:06:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979878.1366369; Fri, 09 May 2025 09: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 1uDJgJ-0004l2-QU; Fri, 09 May 2025 09:06:11 +0000
Received: by outflank-mailman (input) for mailman id 979878;
 Fri, 09 May 2025 09:06:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJgI-0004kr-4M
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:06:10 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20609.outbound.protection.outlook.com
 [2a01:111:f403:200a::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d63cf922-2cb4-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 11:06:06 +0200 (CEST)
Received: from BYAPR02CA0022.namprd02.prod.outlook.com (2603:10b6:a02:ee::35)
 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.20.8699.26; Fri, 9 May
 2025 09:06:00 +0000
Received: from CO1PEPF000042AE.namprd03.prod.outlook.com
 (2603:10b6:a02:ee:cafe::e4) by BYAPR02CA0022.outlook.office365.com
 (2603:10b6:a02:ee::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Fri,
 9 May 2025 09:06:00 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042AE.mail.protection.outlook.com (10.167.243.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:06:00 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:05: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" 
X-Inumbo-ID: d63cf922-2cb4-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mpjgCUah6SJz9CDNT6s/5v0R70ticXW+RRUvBaJMKUVsx0EJpAWZbabZyqyf7qtuyGEK1uKYFixL3NFAoR9zdwAGbSxfYp75pDgo5nE5+nD30FFtrRY1e/aMNk6L3JQNWRdJekip58J36MSuw2B2vglaxrtz84yFe5HcQVDRKVBQwPrHAAPi0kudZxV6CEabS2ihmggbbg5ZVaEjjASZnrDaclYWUI8OMqcLxpsB/pyhr9dHf+0u/DnyCkZAZzcBdYURI+NKGG3JHjrZW/HXl83SwzTJKKKvHDAaGMz1tsShH5ELZHhSdl2JfRuX+fJ6QH6bNqWVUGrwxxdvSyXyJA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=HDlCKerLbhNJ+aVeqVuglnHIG3S+ds+aZHU7MpSbFRw=;
 b=o3FhzyN/pIQ6kS4IBqYItVB6K9h/oTYA2UmLFlOgO6YWPXZz5QQhGMey03NuS6VBn1xR/sB0el2bUSZy4wOFQeC8HBxfogpolk2mvLPT1VZ5cz9w0KR2KjquwVEyculBMVP7dwkPJCG5i8k6V5ZeHJamimTQ+xzupvi0VwbGqlDwWcfpLIXEM6hMnpX1Nca3eNaEzm1kmp0vCaQ3Eq3H/gVUcseriZ3LWeYiLvh79/cF+HRHY0T3v314d6tsNbctn+bp26vjulCAzpmRDTYCt/vEvXXfj7ZAQ7neBtKd2nvLTyi9FqAKNwkPT9NGKsvK+UaI4NR5EOuieBvXaBA+Zg==
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=HDlCKerLbhNJ+aVeqVuglnHIG3S+ds+aZHU7MpSbFRw=;
 b=DKTvk9X3hIaEl10lu1AQQhIwmslNVeSNB3sZ6ArWOp73YX0YAGhgx6ZUmEM9wQE4BjpzBsP0v3d5o3LcMnSz+QNLeB0yAePhRJSUvQwipKS6VyrWaxxiV0sgPh5D2hbylhNjtQC6rKUtah83CLKY+iICOx50z8WKeUtKAw5blT4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v4 01/10] vpci/header: Move emulating cap list logic into new function
Date: Fri, 9 May 2025 17:05:33 +0800
Message-ID: <20250509090542.2199676-2-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AE:EE_|CH3PR12MB8755:EE_
X-MS-Office365-Filtering-Correlation-Id: e66e7973-69f5-4385-d4f9-08dd8ed8b7f5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?STIyVU9xMGZnSWhWU3pqZlJHOTQyUjVvazhpU09JUHNRVnU5RzZkcVB2NGxw?=
 =?utf-8?B?SkU0WVUyc0F2RThXby9PU1NWdVplRGhMaFVnOVo5M3owOWFXOGdvbzRQdUtD?=
 =?utf-8?B?NGt6MDIyRm91MWRwUXdFb0VoeDA1anBhS0lPYktRMzhJSUp1eTk0cmpwajVN?=
 =?utf-8?B?Q09uYkU0S3d3RSt6S3IwdHpLeG9JT0lpYlNFeTM4Mk9TckFudU8wRXZjbnhm?=
 =?utf-8?B?Q2lJSGlCVDVjSEd4dWF0YU44U2lSQnlWQ2NJNjl4S09pQzNTQnJDYldyKys3?=
 =?utf-8?B?Y094SGxJYysyTDRvNG1OTWxSQzM0akl0UGdpU0xmUHRPOUFWNHRER01ubGp0?=
 =?utf-8?B?c2I0UW1zMEtubFg2NmZyd0VBYUlMYnFFazd1WTdmWXFlejFkSUVCSnVrdFBW?=
 =?utf-8?B?QklLYUpiMVpJWll1T01GdGo5cm5rZll3SGY5N1VCUVdNaEtqUFdTMklUdkEy?=
 =?utf-8?B?N3RRK1pSVWF0blN4MmhQcjZjd0pHVUlOK3AyenNxVXJFeGNHWm5ZTXFvcVAy?=
 =?utf-8?B?K0FZcytwaTFQcUZoV1BrVmNtSG56KzBIVFZsVW5HVHpYNkVMKzFEZ2hnRlVi?=
 =?utf-8?B?V0NlY1pxcVRsQi9DVHZVWk84ai9RWXhFdStoTDRuNndDcUt6WkdJaWVXV21N?=
 =?utf-8?B?eHgyUG9CdDJ6Mmg4OXhFZVFzNjRxMGZINk54SERXUVh5MFRFalMwZVBWbDN2?=
 =?utf-8?B?OE1QRzh5R3NYZXhYWkdKdXNDb3o4eUI2M2J5ZllndGhTY1IxaTNaakFhbGVv?=
 =?utf-8?B?cmlqYm5CU3VmZ0E2WWpkL25oOTRlTFNoZUxhY2RpRVJzNkFIb3d6VTJOVXJB?=
 =?utf-8?B?RVVBcGJmZHNlQm10UjBqNjdJQkJUNWc5a0xxa0wyYlBPZFArRHRaT1orTXJG?=
 =?utf-8?B?SGpUYXhLMFB0cDZkWGtsV21rc1V0MUlEdWE0RVNNK3BScXArZmdHTlBCeDJi?=
 =?utf-8?B?T050aWVQYUFrT3VHK3AvSkRhUkYwVlFKbU5vUTRWSndsczNXN2xyN1pqTVRn?=
 =?utf-8?B?SU91VVhxNGtUWDVFR3hkZ2NVbjluUDNvTFlZbWtqQ09DR09nUUpFa3hPOENS?=
 =?utf-8?B?M1R6b2doS2ZTV3haZ0xSSkV3TEdvaVNzMmtUZ0tEdnRsY3ZGdFJ5ZlZveFpZ?=
 =?utf-8?B?QVlleW1acWRZNzRDZDhkY2VVRWlNbHBaUUlMYXhlSWtsU0VEWUZ4MWJueUgz?=
 =?utf-8?B?RGFrbEhrc2gyekJvOEg3SUxqeWwxUUEyN3pxYlRQSDV2bC9aR21SeFlOaHF2?=
 =?utf-8?B?NE1peGhuSWVSWG5mMlUzU2k2R21xSUJEY1RMdDYvOEVIVHN6NThYOHloZ004?=
 =?utf-8?B?Z2I3SWhseDZCbnVEeG5hNWFTWUVWS3VLQURHM3Z1ZVpxbENpU0VQZXRERmNx?=
 =?utf-8?B?d3I5MmNqNHQ0RGhDQks1OVlCK2pvenJ6OFVmdUgyd1VFVW9RKy82SjFlblBq?=
 =?utf-8?B?SEZxWHZUZmFubEpwbFcydmpmTkxqZXFFb1IwcW8wVUhpTTQyNCtaVXJmT2l1?=
 =?utf-8?B?SXIzMjRGRlF1QWtvRUp5dWNDWng2MXZNNUZNOGcwNTJvZzR3dnA3VTRjaVB1?=
 =?utf-8?B?cXY4UE96eUVWdUVLQzFWK2NDcWNMeFN6andHRFdrK3FxUGtKNXB6Zy9ReDlQ?=
 =?utf-8?B?SGxRcVl4TE9jbEFESHoyQkR2TW5ZZFluZDlmUUJsaGhWT24wTjBaSjYvVy9G?=
 =?utf-8?B?bkJiVVZpdTJrZlNhMUMwaklhWEFjUGEvZTVKKzVhZUpIOUtaeDlKRHBsbnBY?=
 =?utf-8?B?WU9lb2VTc3FKd214WUxOdEsrRU92eWIrNk5kdGcwOTZOSGVITjFIUk1WTzVK?=
 =?utf-8?B?b2ZQSm03U0RXaWp1M29iL1lnN2xEbVBHTC9MbjAyYUJhSHU4bDdhLzNJTkNP?=
 =?utf-8?B?c1FLd1NSMkhJdkdFWjJyRjgzVVRVQW9KS08wNWhNMWM3V09TVkgzMTNVck9z?=
 =?utf-8?B?L3V0MzVFK1F1V3pKV2ZnbFhPVEZNdDFaalJRZlZ6dFR2KzNWRWwvb0hJVkhC?=
 =?utf-8?B?bGNML0VaWFdFNVdTY1ZQYTlCZG5ORjNTVEM5SVd2S2hjLzJ5Z0lQVnVxQ3RC?=
 =?utf-8?Q?PFSInW?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:06:00.5523
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e66e7973-69f5-4385-d4f9-08dd8ed8b7f5
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AE.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8755

No functional changes.
Follow-on changes will benifit from this.

Signed-off-by: Jiqian Chen 
Acked-by: Roger Pau Monné 
---
cc: "Roger Pau Monné" 
---
v3->v4 changes:
* Add Acked-by of Roger.

v2->v3 changes:
new patch.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/header.c | 138 ++++++++++++++++++++------------------
 1 file changed, 73 insertions(+), 65 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index ef6c965c081c..3e9b44454b43 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -745,6 +745,75 @@ static int bar_add_rangeset(const struct pci_dev *pdev, struct vpci_bar *bar,
     return !bar->mem ? -ENOMEM : 0;
 }
 
+static int vpci_init_capability_list(struct pci_dev *pdev)
+{
+    int rc;
+    bool mask_cap_list = false;
+
+    if ( !is_hardware_domain(pdev->domain) &&
+         pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
+    {
+        /* Only expose capabilities to the guest that vPCI can handle. */
+        unsigned int next, ttl = 48;
+        static const unsigned int supported_caps[] = {
+            PCI_CAP_ID_MSI,
+            PCI_CAP_ID_MSIX,
+        };
+
+        next = pci_find_next_cap_ttl(pdev->sbdf, PCI_CAPABILITY_LIST,
+                                     supported_caps,
+                                     ARRAY_SIZE(supported_caps), &ttl);
+
+        rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
+                               PCI_CAPABILITY_LIST, 1,
+                               (void *)(uintptr_t)next);
+        if ( rc )
+            return rc;
+
+        next &= ~3;
+
+        if ( !next )
+            /*
+             * If we don't have any supported capabilities to expose to the
+             * guest, mask the PCI_STATUS_CAP_LIST bit in the status
+             * register.
+             */
+            mask_cap_list = true;
+
+        while ( next && ttl )
+        {
+            unsigned int pos = next;
+
+            next = pci_find_next_cap_ttl(pdev->sbdf,
+                                         pos + PCI_CAP_LIST_NEXT,
+                                         supported_caps,
+                                         ARRAY_SIZE(supported_caps), &ttl);
+
+            rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
+                                   pos + PCI_CAP_LIST_ID, 1, NULL);
+            if ( rc )
+                return rc;
+
+            rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
+                                   pos + PCI_CAP_LIST_NEXT, 1,
+                                   (void *)(uintptr_t)next);
+            if ( rc )
+                return rc;
+
+            next &= ~3;
+        }
+    }
+
+    /* Utilize rsvdp_mask to hide PCI_STATUS_CAP_LIST from the guest. */
+    return vpci_add_register_mask(pdev->vpci, vpci_hw_read16, vpci_hw_write16,
+                                  PCI_STATUS, 2, NULL,
+                                  PCI_STATUS_RO_MASK &
+                                    ~(mask_cap_list ? PCI_STATUS_CAP_LIST : 0),
+                                  PCI_STATUS_RW1C_MASK,
+                                  mask_cap_list ? PCI_STATUS_CAP_LIST : 0,
+                                  PCI_STATUS_RSVDZ_MASK);
+}
+
 static int cf_check init_header(struct pci_dev *pdev)
 {
     uint16_t cmd;
@@ -753,7 +822,6 @@ static int cf_check init_header(struct pci_dev *pdev)
     struct vpci_header *header = &pdev->vpci->header;
     struct vpci_bar *bars = header->bars;
     int rc;
-    bool mask_cap_list = false;
     bool is_hwdom = is_hardware_domain(pdev->domain);
 
     ASSERT(rw_is_write_locked(&pdev->domain->pci_lock));
@@ -794,61 +862,12 @@ static int cf_check init_header(struct pci_dev *pdev)
     if ( rc )
         return rc;
 
+    rc = vpci_init_capability_list(pdev);
+    if ( rc )
+        return rc;
+
     if ( !is_hwdom )
     {
-        if ( pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
-        {
-            /* Only expose capabilities to the guest that vPCI can handle. */
-            unsigned int next, ttl = 48;
-            static const unsigned int supported_caps[] = {
-                PCI_CAP_ID_MSI,
-                PCI_CAP_ID_MSIX,
-            };
-
-            next = pci_find_next_cap_ttl(pdev->sbdf, PCI_CAPABILITY_LIST,
-                                         supported_caps,
-                                         ARRAY_SIZE(supported_caps), &ttl);
-
-            rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
-                                   PCI_CAPABILITY_LIST, 1,
-                                   (void *)(uintptr_t)next);
-            if ( rc )
-                return rc;
-
-            next &= ~3;
-
-            if ( !next )
-                /*
-                 * If we don't have any supported capabilities to expose to the
-                 * guest, mask the PCI_STATUS_CAP_LIST bit in the status
-                 * register.
-                 */
-                mask_cap_list = true;
-
-            while ( next && ttl )
-            {
-                unsigned int pos = next;
-
-                next = pci_find_next_cap_ttl(pdev->sbdf,
-                                             pos + PCI_CAP_LIST_NEXT,
-                                             supported_caps,
-                                             ARRAY_SIZE(supported_caps), &ttl);
-
-                rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
-                                       pos + PCI_CAP_LIST_ID, 1, NULL);
-                if ( rc )
-                    return rc;
-
-                rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
-                                       pos + PCI_CAP_LIST_NEXT, 1,
-                                       (void *)(uintptr_t)next);
-                if ( rc )
-                    return rc;
-
-                next &= ~3;
-            }
-        }
-
         /* Extended capabilities read as zero, write ignore */
         rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL, 0x100, 4,
                                (void *)0);
@@ -856,17 +875,6 @@ static int cf_check init_header(struct pci_dev *pdev)
             return rc;
     }
 
-    /* Utilize rsvdp_mask to hide PCI_STATUS_CAP_LIST from the guest. */
-    rc = vpci_add_register_mask(pdev->vpci, vpci_hw_read16, vpci_hw_write16,
-                                PCI_STATUS, 2, NULL,
-                                PCI_STATUS_RO_MASK &
-                                    ~(mask_cap_list ? PCI_STATUS_CAP_LIST : 0),
-                                PCI_STATUS_RW1C_MASK,
-                                mask_cap_list ? PCI_STATUS_CAP_LIST : 0,
-                                PCI_STATUS_RSVDZ_MASK);
-    if ( rc )
-        return rc;
-
     if ( pdev->ignore_bars )
         return 0;
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 09:06:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:06:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979879.1366374 (Exim 4.92)
	(envelope-from )
	id 1uDJgK-0004n3-4e; Fri, 09 May 2025 09:06:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979879.1366374; Fri, 09 May 2025 09:06: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 1uDJgK-0004mb-0V; Fri, 09 May 2025 09:06:12 +0000
Received: by outflank-mailman (input) for mailman id 979879;
 Fri, 09 May 2025 09:06:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJgI-0004kr-Q9
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:06:10 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20609.outbound.protection.outlook.com
 [2a01:111:f403:2415::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d7d46c30-2cb4-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 11:06:08 +0200 (CEST)
Received: from BYAPR02CA0008.namprd02.prod.outlook.com (2603:10b6:a02:ee::21)
 by DS0PR12MB8814.namprd12.prod.outlook.com (2603:10b6:8:14e::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Fri, 9 May
 2025 09:06:05 +0000
Received: from CO1PEPF000042AE.namprd03.prod.outlook.com
 (2603:10b6:a02:ee:cafe::11) by BYAPR02CA0008.outlook.office365.com
 (2603:10b6:a02:ee::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.29 via Frontend Transport; Fri,
 9 May 2025 09:06:05 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042AE.mail.protection.outlook.com (10.167.243.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:06:04 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:06:01 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d7d46c30-2cb4-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Zl5LkB4KxWBeLENqY4BIWSY10rDPE2C1d3xO8QGQWqtuXoCaG9qA/HPVyajrp/TxcWYplTdJFNi9WzA2iMmGVUW62Kksl/5JQlwwu/g7RMiXiOtuIfr+zfZvLoaKjjoBA/12kC6SnJLFdUfSlz0SlO4z9v/EWDBd7KS1zAeJjIXheUP3QJHLlElwmXjWfmJlSYZuqOvoCnDl/mO5QsJZLKnyPH7oYMTM+RI3ogdYE3Q5bBxexzm8D5hmSBZvuob1SaHsnfVUZjZUG7HAIHAj5EET+sQl3JwY/GVoQx2nqmqy7WiMOVIfnkElf4M8KG5Ti19IK/T7Sx3ILPGAVSecdQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fQdXx3HTsPNm2JgJIQeGrl1G1KZnmDGgfP+bzS4sBUg=;
 b=G0m1gWq3zywiySYVPyaJP4vzdTgmqc9zx9jJXucruusK9HCYRVLP6fg8Y0fBQuLXFTDqWJwbV0v7x2vyfnZLXztB3xeDaA0KmnlkyKHe/xGH2TduvT924M9m3P21B3YmWp4l29a2xEcE3VOneWY6vVJfBdcpmP51UHObdzqAgHyivEB3XhOR35dL3z/BDV9dmvrB3xynjw0WCN0w0kpi31IHOrXStcaRDQPRuuQt89YwI+Zyv+1Nkh/x4KjHrEQPnuCSifosgcaPXIYvDVll+hC41/TrzjiqPGSYVyoNY7PXVE4Z54CXPqrvBONgLd1BqJIp2LcnDdVpAWUAMcslSQ==
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=fQdXx3HTsPNm2JgJIQeGrl1G1KZnmDGgfP+bzS4sBUg=;
 b=IF/vify+7pmic5h77JH6xo0lJEU3DsZTQmhM0SHZfVbNaIDgSzZwqga7CScs+g/In2lU4Xscq+0/6WPD6mlFhT+BIvjIXec0tcHdLxIie6GdpwRzHSlIaqnWY531g54/QOanOcsAuNTQJGWykZT9LU9VdasTmWPwbDomMjHZFD0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v4 03/10] vpci/header: Emulate extended capability list for dom0
Date: Fri, 9 May 2025 17:05:35 +0800
Message-ID: <20250509090542.2199676-4-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AE:EE_|DS0PR12MB8814:EE_
X-MS-Office365-Filtering-Correlation-Id: 74841d00-2f72-4a1a-20ba-08dd8ed8ba83
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cXJLUlFPb20zNlI4SWhhZktWNXhxcy9WeVMwRVR0K3VwSFJ4ckFPNFlDeW5Z?=
 =?utf-8?B?c0xEK2J6TEpUbnBZMkxlWTBrSGZ1bERKZXArMnQ2aXBnU3ZTUTNLdThnQmxC?=
 =?utf-8?B?WUFzNHpGeS9jckdnL3dZbTVzbStoSFBRZmV3azhNQ2pDKzFxREQyKzVPOGRo?=
 =?utf-8?B?SitLczk3MjRKbHJ4YW54OGZZVDU4YnFhb1U4TmpGQnFSWUJud2phNWswT29y?=
 =?utf-8?B?eWZpZzZSeFM5blZDeWxqamdYT2kzNXA1eGxKaFEvODBtRCt4blpyQTU3YTVO?=
 =?utf-8?B?SXpRbkpoWHdqRVRKbXpxV1BYUS8zdy9aS0paWnEvRHRONjZNNmJGWEZEbXp4?=
 =?utf-8?B?d05DQTJOTHMxZG5Od3p3NSs3VE91R0Z4bFJyRUpRS3Bodit3OHBmWWdmSWtl?=
 =?utf-8?B?VkZub0lSZk5kTUFUWUJMSW5lVlhQMnZFVm1vUlUyYkhCdEwxNkRGVm13YUtF?=
 =?utf-8?B?TDZNVGlScVg2V0p2VnlnZllEZXZvYmFRYUJrZldXL2thQnU1aGtrTm1XYjFk?=
 =?utf-8?B?bkZXMmJtR29wQ0NUbzRnaTY5eGVsMmNoZzBwUTRTR3QwZHZ4VmtpSlFFdUlW?=
 =?utf-8?B?TlZZMGxkbTRIRWhWZ1hVUEJiYkhIRUIrd2JpbnlJV0RrOEQxcGJ4VGxFREhR?=
 =?utf-8?B?YVhDOElCS2JVYUQ1RkE0V1Qzc0V0a2hUR253cjlFamVZSVQyN0tydjkrWGYy?=
 =?utf-8?B?K3E3SGRzODZTaWdLYzRSc211S0VsRUlkWWVWOGwyYWM0d0puL0tnN0t5dlVC?=
 =?utf-8?B?alY0NWRQRHlKdERwNWNibjhrNktYL3pMYm5jRzdjSWsxdmYzQzk0WE05azll?=
 =?utf-8?B?NTl4bENHOGR1azBXcklyTnI5VUVka2RwVktjVWhyaU5jT0N0SHB1NWpsQmtu?=
 =?utf-8?B?MG81T1dKRUk1L1ZOZ0lLeGt2TEFBa2gwTmZGVjBGS3dGSjh3YUJUd2szZXFi?=
 =?utf-8?B?b3VjUzdHUGthTG5aL2JEeFVtWHV5SDQ1TWJwUCtTY3o5ZU5SdE0rRm9vaTFt?=
 =?utf-8?B?M3U3czlxWmFaNmlPc0xwaGpVTWVPS20wZTV2T1VkVHdyOFk1dmlPSmdHNmp1?=
 =?utf-8?B?Q0RUcjR0L0pQQTFrNlJDR1g4b1NHL0VNcXdXVzUzcWp1RmVQbWFIQU5TRTJS?=
 =?utf-8?B?Q3B2eVZzQVdEeUNzSkNpN0pIdXpOa1lyTVd4REVNeFAzMDdqcUhncmNwNWpH?=
 =?utf-8?B?c3RkUzJEMWdQLzE5dUIzbEVLeENaN0xJcHcxMnFxRGVvamcxamJtaE1lMS9T?=
 =?utf-8?B?a0JKSFZ6WWxKTy8wRG5SUjRyNFpRWFdTV3BiNmVOdlZ1QW0wRlZUNVlabzNh?=
 =?utf-8?B?dml2WTU3Mkp3cTh4T1ZzMXp4UVNjdEpieUd6WUhQK0xiYVRKR04wd3NNZzFO?=
 =?utf-8?B?V0tlczdCdGNpNmJBVGhwbWdtU2F1eDFNbm92UzZXVVFMak5kTFN2KzJIeUxP?=
 =?utf-8?B?TmpNLzFGT2dJb0YzUkQ0WU1sS254d1NOY1JaemVSSXpFY3M1STJDVjRLUGM5?=
 =?utf-8?B?ODI3eEZBamtjcTJSNC9BTHU3b0VsaDR5elU3WEZKajc0MUszNFNHeERrNGVm?=
 =?utf-8?B?UUlxeGxTaG9LVytIQStYOGVvNjR5akdSSnQra1VQME9vR0V6bGdtTUgrMnJa?=
 =?utf-8?B?bGR5M05zTUlBUDZ3N3ZTM3lPZ3FRK1M3WHNhdkxDVUdoWnNPYXRYRzBINDd6?=
 =?utf-8?B?ZGdqZUk1ai9QTTNmNUVZVHlDMVVsK05BT25xYVlLVVdSV21Sd2pTVEphTTlu?=
 =?utf-8?B?aEtDWHJVL3RqTVV1RHRWL3J1K3p2VkJFOVVEclRndlZHaE9Rd09MRWJUTk8y?=
 =?utf-8?B?TkdCQ3VQRm5iN1hKSmhDNnhHSnJXWUZ1ekN0dlFpQXRFUXREb2UrbnFrUzhq?=
 =?utf-8?B?YUxrREt5NlhVMjROMXFORmZOR0xleDRicEVwcGZVejFha2xrekdWUFdjVFZB?=
 =?utf-8?B?cDJ4alN4b2VCeGhPQVhzOXVoVTVDWmZnV1BsamxLU0FuR0VzMWpkSUFUMUJ0?=
 =?utf-8?B?OTNraHJkcmM4azlYdEpsQ0ZMSG5Denh6bHlaeFZ5Qk0rU0lmeExqNFFYUk0r?=
 =?utf-8?Q?s8lxgj?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:06:04.8336
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 74841d00-2f72-4a1a-20ba-08dd8ed8ba83
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AE.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8814

Add a new function to emulate extended capability list for dom0,
and call it in init_header(). So that it will be easy to hide a
extended capability whose initialization fails.

As for the extended capability list of domU, just move the logic
into above function and keep hiding it for domU.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v3->v4 changes:
* Add check "if ( !header )   return 0;" to avoid adding handler for
  device that has no extended capabilities.

v2->v3 changes:
* In vpci_init_ext_capability_list(), when domain is domU, directly return after adding a handler(hiding all extended capability for domU).
* In vpci_init_ext_capability_list(), change condition to be "while ( pos >= 0x100U && ttl-- )" instead of "while ( pos && ttl-- )".
* Add new function vpci_hw_write32, and pass it to extended capability handler for dom0.

v1->v2 changes:
new patch

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/header.c | 39 +++++++++++++++++++++++++++++++--------
 xen/drivers/vpci/vpci.c   |  6 ++++++
 xen/include/xen/vpci.h    |  2 ++
 3 files changed, 39 insertions(+), 8 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index a06c518c506c..2915c801adeb 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -827,6 +827,34 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
                                                  PCI_STATUS_RSVDZ_MASK);
 }
 
+static int vpci_init_ext_capability_list(struct pci_dev *pdev)
+{
+    unsigned int pos = PCI_CFG_SPACE_SIZE, ttl = 480;
+
+    if ( !is_hardware_domain(pdev->domain) )
+        /* Extended capabilities read as zero, write ignore for guest */
+        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
+                                 pos, 4, (void *)0);
+
+    while ( pos >= PCI_CFG_SPACE_SIZE && ttl-- )
+    {
+        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
+        int rc;
+
+        if ( !header )
+            return 0;
+
+        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
+                               pos, 4, (void *)(uintptr_t)header);
+        if ( rc )
+            return rc;
+
+        pos = PCI_EXT_CAP_NEXT(header);
+    }
+
+    return 0;
+}
+
 static int cf_check init_header(struct pci_dev *pdev)
 {
     uint16_t cmd;
@@ -879,14 +907,9 @@ static int cf_check init_header(struct pci_dev *pdev)
     if ( rc )
         return rc;
 
-    if ( !is_hwdom )
-    {
-        /* Extended capabilities read as zero, write ignore */
-        rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL, 0x100, 4,
-                               (void *)0);
-        if ( rc )
-            return rc;
-    }
+    rc = vpci_init_ext_capability_list(pdev);
+    if ( rc )
+        return rc;
 
     if ( pdev->ignore_bars )
         return 0;
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index cf3326a966d0..2022b61ea7b6 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -238,6 +238,12 @@ void cf_check vpci_hw_write16(
     pci_conf_write16(pdev->sbdf, reg, val);
 }
 
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
+{
+    pci_conf_write32(pdev->sbdf, reg, val);
+}
+
 int vpci_add_register_mask(struct vpci *vpci, vpci_read_t *read_handler,
                            vpci_write_t *write_handler, unsigned int offset,
                            unsigned int size, void *data, uint32_t ro_mask,
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index fc8d5b470b0b..61d16cc8b897 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -80,6 +80,8 @@ void cf_check vpci_hw_write8(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 void cf_check vpci_hw_write16(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 
 /*
  * Check for pending vPCI operations on this vcpu. Returns true if the vcpu
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 09:06:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:06:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979880.1366389 (Exim 4.92)
	(envelope-from )
	id 1uDJgO-0005Ew-BU; Fri, 09 May 2025 09:06:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979880.1366389; Fri, 09 May 2025 09: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 1uDJgO-0005Ep-6W; Fri, 09 May 2025 09:06:16 +0000
Received: by outflank-mailman (input) for mailman id 979880;
 Fri, 09 May 2025 09:06:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJgM-0004kr-0y
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:06:14 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:2409::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id db2b6bb5-2cb4-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 11:06:13 +0200 (CEST)
Received: from BYAPR02CA0009.namprd02.prod.outlook.com (2603:10b6:a02:ee::22)
 by CY8PR12MB8216.namprd12.prod.outlook.com (2603:10b6:930:78::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Fri, 9 May
 2025 09:06:08 +0000
Received: from CO1PEPF000042AE.namprd03.prod.outlook.com
 (2603:10b6:a02:ee:cafe::23) by BYAPR02CA0009.outlook.office365.com
 (2603:10b6:a02:ee::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.30 via Frontend Transport; Fri,
 9 May 2025 09:06:07 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042AE.mail.protection.outlook.com (10.167.243.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:06:07 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:06: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" 
X-Inumbo-ID: db2b6bb5-2cb4-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NTkJuZ3X5HAPNNSiGF5IWqKVj0vquD2ntxFZK3L6ePfs+gblLMrBc/PpgHw1LiYJV9GeLMYHHJ2o4XVx8YupqB007SG5VcNDuVlrQVxHM2xFwEUMc4XN5Xl8obXEwtSiCgJrjHCOhlrlBwy3kjPFp5d2Jq+3f1RXV3QbjStqg6TkXzGVC0i2aUHcuROVCzsuFIpJRoXTaqmKnIz3ZsSiUL4xIf4sHK/vP6lCbGYtTYNkX8ZU89xwpVIsGbD6ic6sSIAbDKKe6KP8EzYucNk35j2YFdAG04iVDkODDtH8QY73q5j0cpnMokfAyzxlKk38x+eFKwBL/I3AK2pAxb4Teg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3lURpKzTdDIzNS2eA3PDwf7XbZTHriapbBVD/3Q0erc=;
 b=YzCk3OvATCbj1g34enXQWJmruXOc+0I9yKWK3QxrNCsW1+sDtilGdxY4WzcgCIDgWLqtdwNk2J+7IBnw/loYYf40ENHIY1dEcRHN21oLfE1am9Gi/zFqJ9edsyFAiE+gVYNCnWvGCR6sZZsOV4z/P0j0z4LP2fkPZfYrGs6gAtFQX49GyFptP2BoDdW1cl2R0e1iEm9K0IewnNl0nndMquXbPT0PEGJey5S7HBawRPQ4ciDdTk6LYtQjf8+qPSOWQPtSZeT3dsPJLNdsbdPZ169mB3fUQqdxSfpQHhhv999IS2Vbx+eUjifvUOlQMivbCRuPOgiEqYI/F5nCjXd0Jw==
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=3lURpKzTdDIzNS2eA3PDwf7XbZTHriapbBVD/3Q0erc=;
 b=5hQAYJVJlSEF1YTwwBG+B6O/zvpgQ5BxBZrgJizSeXjWSjNTTs/6R+EI9hEuciFhiV7eCTSrx5VeWQhus8jxibmlYreMNGLM1C7Qi7H8UhCj55YegLr05k5DukMZcXSIlIeFkoQ8VZdAnF8ftzk+/HcVBJGg08Dk3eqQ69OFpqA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v4 05/10] vpci: Hide legacy capability when it fails to initialize
Date: Fri, 9 May 2025 17:05:37 +0800
Message-ID: <20250509090542.2199676-6-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AE:EE_|CY8PR12MB8216:EE_
X-MS-Office365-Filtering-Correlation-Id: 161f6f34-fa8b-4e1e-24a7-08dd8ed8bc41
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bkNrbEhWY3IveW0rUEg3eGJ6SGoraVFBZUYvOWFvLzVkc0t0QTBlOGRQakM5?=
 =?utf-8?B?SElxS2tGWTBaK0J5RHBpbkU1cFVueVg3MVFMM25sQ3l5d2xqODdvS1diZksx?=
 =?utf-8?B?Qk9DQmhKTjU4ZmlaSFRLcmhabHlmSStidlpFNCtscWZQUDhhNTNTb3ROcFg1?=
 =?utf-8?B?am0zN2NOSTBNNkZGaUM4eUhmSXByOS9hbjN1RXExdGM0MVBjMS9ub29vV0N4?=
 =?utf-8?B?UzlBUU9DUWdFblZ3dnlqYXl4NTNhRTlOL0NLb21VQWhzTURUSkxsMG1EUk5j?=
 =?utf-8?B?UWZqM1hPZzUvUFVhOWZaZTJ2QklhTUM4cmRHN2RJUGpDV0IzK0NQZXVJVTZG?=
 =?utf-8?B?SlZpSndDUzNzSWhiZitsTG0wOHZ5S01HTlRNZzVHS2h0UGNuUm93b0sxUVZO?=
 =?utf-8?B?WldYR0xQMzlZVVh1TGlWRzd5c3U5NUxkeVp4bCtCNWxIMFlTcGR1YU1KRFB5?=
 =?utf-8?B?NWozL0lieFQ5L3FHbXlKN0kzNjlyaUhYaXhVN24vdE1PMTFES0ZsL3BGOEVI?=
 =?utf-8?B?TlhUbVMvK2I5bzY0OXExbFVnaHlPWjhSYmo1VG9DL00zQ0wrY0F6cTV2dGk0?=
 =?utf-8?B?S0J5bUdjbU1oTTFLV1hyd2NFNWdHTUo0aWFlVzk1YWx2MUZXUXRCUlA4QTBi?=
 =?utf-8?B?RXh2TEY5YlZ3VDJVcjc1RU1ZK0VzMSsxbUNlMU9lenZheHRkV3hCNmlNQ2hn?=
 =?utf-8?B?MmJCUUtLaXdiaWpFOUVSUGdhbUhIM05RWEk4Wm9WQzlNK0lYQkE3SjRHd1Na?=
 =?utf-8?B?bzlzWEIyNHZaczhIOWJjdFpwQVRKWEJBUVluNVRVMVRORHRrYmxpdUdOcmlF?=
 =?utf-8?B?K20wR1BEdGFIc1I0Yzh1cTA3Mld6NXpDQzF1N2xRZmR6VnRHcHpJY0dKY2Iw?=
 =?utf-8?B?a1ZtSGt2TmYvcGNpcmNRamc4eCt2MDlncm5zN0kyZ3ZKcnUyZFkvUmlLTzlO?=
 =?utf-8?B?dGhkd0tMV1I4SXhYMEY4Z3B4elhFMjFPMGgxWHA0TjNKTmQySmdzNHdvUVZL?=
 =?utf-8?B?bHJHUi92Rno4cDBwU1VtMWF1ZWEvTjJab1RSUE05eVlVVU9jcjRpdXN0NkN2?=
 =?utf-8?B?NGU1UVpiTWtEVTdzemhVNWRGZWZwMVQ4ZzN1SStyUDJFOWFLcUlFbkRHcVRm?=
 =?utf-8?B?ZDVvZ2ZHTTdCanFEVyt6bTh2cElkSENxQ1pWblg2U2JuRGNCTHVrUW9xbHpp?=
 =?utf-8?B?aUYraXFRcFZmRURVaE8zM1JnQS9JQjNZalk0dmRFVDNSYzZyZFpwVGZqWXRz?=
 =?utf-8?B?QURIZCttTW1BUXJKNUVyUDFGYldUQitETzhhdFZIWDZZZmlISWQyeWE4MFE4?=
 =?utf-8?B?KzRXdXZBUlJsMnplWmlkSmtTWUkrcG9COGV2WFE0cjgvNStvM2V4SmVoVE5l?=
 =?utf-8?B?cXdRWDRVcy9YYkhieEFHT2REYzNzVk5CQVE2QitTa0M4TVJUcDdIbU4wclB3?=
 =?utf-8?B?bjVUV25wbFoveVpQNlhVbU1Yc2xzYmZxWUdiRHNaQlo0N214eTBOdTFBN3oy?=
 =?utf-8?B?L29HQkIvRjdxN1FRdTI1V05RazdZQnpWMVhnaHkvQjNDeWhXRVcwLzBJVFRr?=
 =?utf-8?B?NkNycGdLU3lFN2ZVODIyM0FjSHRxR055UHJHTzdNWlcrU054MzQ5MlFpcFJz?=
 =?utf-8?B?WFdSbnA4d0VxOG9Jb3l3R3dqVWo1QUVwaVNjb2RZRXlQZVcySmZkUmsvV1Fm?=
 =?utf-8?B?Ti9sbnFTZUFDYUxiRklSWFIvaTlMdEVHSHhPRHhyR1JjRmI4TU04M1Fqa3Rz?=
 =?utf-8?B?cmg5cmp3dSt2dFJ6ZE13NWkzdFV2ZTdNWk91VlNNYkdYVFNqdUJTVUFxYk4x?=
 =?utf-8?B?bDNCQWRoWFJ0a3d6MHB3T0RaNEZVL0xTYjNFMXkzTytUT3RtVXBrWGtTa1Mr?=
 =?utf-8?B?cmxUMkdsYjMyVTlmdVErdWd1QmtHTU1mdWtVQkpWRU5uOUs5eDI4YXlGSngz?=
 =?utf-8?B?VVd2eDNKUEFMR3pxdDZZNnQzV29UUW8yK3FBaDZocU45NXFlb2MwbTlheFBv?=
 =?utf-8?B?OFlOTzlHUzh1bTdZYldwNkhNK3RabnJRNGgwbzhrb2JPVTJpMFhVc0pUQjFk?=
 =?utf-8?Q?RQukgV?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:06:07.7555
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 161f6f34-fa8b-4e1e-24a7-08dd8ed8bc41
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AE.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8216

When vpci fails to initialize a legacy capability of device, it just
returns an error and vPCI gets disabled for the whole device.  That
most likely renders the device unusable, plus possibly causing issues
to Xen itself if guest attempts to program the native MSI or MSI-X
capabilities if present.

So, add new function to hide legacy capability when initialization
fails. And remove the failed legacy capability from the vpci emulated
legacy capability list.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v3->v4 changes:
* Modify the commit message.
* In function vpci_get_previous_cap_register(), add an ASSERT_UNREACHABLE() if offset below 0x40.
* Modify vpci_capability_mask() to return error instead of using ASSERT.
* Use vpci_remove_register to remove PCI_CAP_LIST_ID register instead of open code.
* Add check "if ( !offset )" in vpci_capability_mask().

v2->v3 changes:
* Separated from the last version patch "vpci: Hide capability when it fails to initialize"
* Whole implementation changed because last version is wrong.
  This version adds a new helper function vpci_get_register() and uses it to get
  target handler and previous handler from vpci->handlers, then remove the target.

v1->v2 changes:
* Removed the "priorities" of initializing capabilities since it isn't used anymore.
* Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
  remove failed capability from list.
* Called vpci_make_msix_hole() in the end of init_msix().

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/vpci.c | 142 +++++++++++++++++++++++++++++++++++-----
 1 file changed, 125 insertions(+), 17 deletions(-)

diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index f03e1a8eebc0..e1d4e9aa9b88 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -35,6 +35,22 @@ struct vpci_register {
     uint32_t rsvdz_mask;
 };
 
+static int vpci_register_cmp(const struct vpci_register *r1,
+                             const struct vpci_register *r2)
+{
+    /* Return 0 if registers overlap. */
+    if ( r1->offset < r2->offset + r2->size &&
+         r2->offset < r1->offset + r1->size )
+        return 0;
+    if ( r1->offset < r2->offset )
+        return -1;
+    if ( r1->offset > r2->offset )
+        return 1;
+
+    ASSERT_UNREACHABLE();
+    return 0;
+}
+
 #ifdef __XEN__
 extern vpci_capability_t *const __start_vpci_array[];
 extern vpci_capability_t *const __end_vpci_array[];
@@ -83,6 +99,100 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
 
 #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
 
+static struct vpci_register *vpci_get_register(struct vpci *vpci,
+                                               unsigned int offset,
+                                               unsigned int size)
+{
+    const struct vpci_register r = { .offset = offset, .size = size };
+    struct vpci_register *rm;
+
+    ASSERT(spin_is_locked(&vpci->lock));
+    list_for_each_entry ( rm, &vpci->handlers, node )
+    {
+        int cmp = vpci_register_cmp(&r, rm);
+
+        if ( !cmp && rm->offset == offset && rm->size == size )
+            return rm;
+        if ( cmp <= 0 )
+            break;
+    }
+
+    return NULL;
+}
+
+static struct vpci_register *vpci_get_previous_cap_register(
+    struct vpci *vpci, unsigned int offset)
+{
+    uint32_t next;
+    struct vpci_register *r;
+
+    if ( offset < 0x40 )
+    {
+        ASSERT_UNREACHABLE();
+        return NULL;
+    }
+
+    r = vpci_get_register(vpci, PCI_CAPABILITY_LIST, 1);
+    if ( !r )
+        return NULL;
+
+    next = (uint32_t)(uintptr_t)r->private;
+    while ( next >= 0x40 && next != offset )
+    {
+        r = vpci_get_register(vpci, next + PCI_CAP_LIST_NEXT, 1);
+        if ( !r )
+            return NULL;
+        next = (uint32_t)(uintptr_t)r->private;
+    }
+
+    if ( next < 0x40 )
+        return NULL;
+
+    return r;
+}
+
+static int vpci_capability_mask(struct pci_dev *pdev, unsigned int cap)
+{
+    const unsigned int offset = pci_find_cap_offset(pdev->sbdf, cap);
+    struct vpci_register *prev_next_r, *next_r;
+    struct vpci *vpci = pdev->vpci;
+
+    if ( !offset )
+    {
+        ASSERT_UNREACHABLE();
+        return 0;
+    }
+
+    spin_lock(&vpci->lock);
+    next_r = vpci_get_register(vpci, offset + PCI_CAP_LIST_NEXT, 1);
+    if ( !next_r )
+    {
+        spin_unlock(&vpci->lock);
+        return -ENODEV;
+    }
+
+    prev_next_r = vpci_get_previous_cap_register(vpci, offset);
+    if ( !prev_next_r )
+    {
+        spin_unlock(&vpci->lock);
+        return -ENODEV;
+    }
+
+    prev_next_r->private = next_r->private;
+    /*
+     * Not calling vpci_remove_register() here is to avoid redoing
+     * the register search
+     */
+    list_del(&next_r->node);
+    spin_unlock(&vpci->lock);
+    xfree(next_r);
+
+    if ( !is_hardware_domain(pdev->domain) )
+        return vpci_remove_register(vpci, offset + PCI_CAP_LIST_ID, 1);
+
+    return 0;
+}
+
 static int vpci_init_capabilities(struct pci_dev *pdev)
 {
     for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
@@ -106,7 +216,21 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
 
         rc = capability->init(pdev);
         if ( rc )
-            return rc;
+        {
+            if ( capability->cleanup )
+                capability->cleanup(pdev);
+
+            printk(XENLOG_WARNING
+                   "%pd %pp: %s cap %u init fail rc=%d, mask it\n",
+                   pdev->domain, &pdev->sbdf,
+                   is_ext ? "extended" : "legacy", cap, rc);
+            if ( !is_ext )
+            {
+                rc = vpci_capability_mask(pdev, cap);
+                if ( rc )
+                    return rc;
+            }
+        }
     }
 
     return 0;
@@ -201,22 +325,6 @@ int vpci_assign_device(struct pci_dev *pdev)
 }
 #endif /* __XEN__ */
 
-static int vpci_register_cmp(const struct vpci_register *r1,
-                             const struct vpci_register *r2)
-{
-    /* Return 0 if registers overlap. */
-    if ( r1->offset < r2->offset + r2->size &&
-         r2->offset < r1->offset + r1->size )
-        return 0;
-    if ( r1->offset < r2->offset )
-        return -1;
-    if ( r1->offset > r2->offset )
-        return 1;
-
-    ASSERT_UNREACHABLE();
-    return 0;
-}
-
 /* Dummy hooks, writes are ignored, reads return 1's */
 static uint32_t cf_check vpci_ignored_read(
     const struct pci_dev *pdev, unsigned int reg, void *data)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 09:06:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:06:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979881.1366395 (Exim 4.92)
	(envelope-from )
	id 1uDJgO-0005IR-Ou; Fri, 09 May 2025 09:06:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979881.1366395; Fri, 09 May 2025 09: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 1uDJgO-0005HY-Fx; Fri, 09 May 2025 09:06:16 +0000
Received: by outflank-mailman (input) for mailman id 979881;
 Fri, 09 May 2025 09:06:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJgN-0004kr-0z
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:06:15 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2409::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id db2678fc-2cb4-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 11:06:14 +0200 (CEST)
Received: from BYAPR02CA0029.namprd02.prod.outlook.com (2603:10b6:a02:ee::42)
 by PH8PR12MB6796.namprd12.prod.outlook.com (2603:10b6:510:1c7::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.21; Fri, 9 May
 2025 09:06:07 +0000
Received: from CO1PEPF000042AE.namprd03.prod.outlook.com
 (2603:10b6:a02:ee:cafe::99) by BYAPR02CA0029.outlook.office365.com
 (2603:10b6:a02:ee::42) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.33 via Frontend Transport; Fri,
 9 May 2025 09:06:07 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042AE.mail.protection.outlook.com (10.167.243.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:06:06 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:06: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" 
X-Inumbo-ID: db2678fc-2cb4-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uRUoU7ePpLk1KsgzAz6ANHdNsxqxr7EXBGCSDRxEA9ZZQXjkqcXf548/IrfFkiq88lL8FbUQ1XmKoJbdVzWPQvRism0hp8b8n6Z5zFUY4cyKY6zjdA1KBbZW9o6+LSXjMwYsW0mB6f2YT8hSCaXuBzCl7gJqElHDKnp6Gx43AadTgU0NjVBET3U0sCdOO/gIh6ji+tKCt+Sv+a6bYhkhgvK2rtFjpTMDTjfVR/AQ3AK+42260vYjv6A8656M9NWrt0BjZnpbL/4a7X4c1i0DGSbUZeFm77bNQJBkrVWBhkRB+WiDi/st4X42gWW0Pvcalc+U8Y/eNsalsNQMOfCYLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KMW/1vCFD6116SzFGwR5Z8wmoiH7OylpThQIjgPoCaY=;
 b=orqvDK3De4WisxLSmKmZtE0cuBF5pG1tipUTMRK4acTJfxgDnzNNTC2U4nxQNBHYzETAJmhoxPCyUUjDEsnnHx+UiEIv9jYYzzc5+dmk6qw4OV5yFlOGuiP5IUoEkgyCFN330FaBRUxkDAAe0IJe8DRIJRg717mX9tHMjltfi17A/5eFfqfW3PtgOXPsjC8ESekA/omR5/mjq4Pgc8L9lAIylD70yO+4H6xe94Faoe44MRGHydFLh8ST3sv3r5avE3XcbtNX64XCHxHe+TVKwpoKCUXL7N7gsAF13QfeMQ0ldoHRRcjnDL4YxbFwaihzFWfQMYyk78iEU0ciGkEa3g==
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=KMW/1vCFD6116SzFGwR5Z8wmoiH7OylpThQIjgPoCaY=;
 b=oJL0bWLM96fUPAeSZP6yjFv879+8rR+1gwXT9ee8scvhUep3+KABCLaaV9qbjiGZ9gDuoh1Zq9v1ITIxQ9M+trDBlPIuXRMbSGb0AyMqxJtH9B72Qg2oErpiPoiy6VUmmFY9OE2wnClN9Cixrz3h4yb9ZPA6NjCXkBIUZ3JDGZg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v4 04/10] vpci: Refactor REGISTER_VPCI_INIT
Date: Fri, 9 May 2025 17:05:36 +0800
Message-ID: <20250509090542.2199676-5-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AE:EE_|PH8PR12MB6796:EE_
X-MS-Office365-Filtering-Correlation-Id: 937fdc0f-0fd0-4a8a-6826-08dd8ed8bbbb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZVZJbDFYSkV3dWptcXZqd2xTdURuSnVIeEVXbWlJYzVkWXNaK0xVNDRmdHFy?=
 =?utf-8?B?LzZ2TnNtM2ZJZkpSNUxYRE5HSUJhcTl5cXY0bmpXaWZZY25yNTlyM2Jid2No?=
 =?utf-8?B?cFhkRm1XMnllSmJvVWNTS2htV1ZUS3VsY0NWOVdNNU1OeUZzMjRlSllTYUcw?=
 =?utf-8?B?Q2VCbWo0MFlXMjEwM2V4clorVHJoNHJabFZ6TnRqeGdaOGVWSVppRjBnWkRZ?=
 =?utf-8?B?Z1dFb1o1MGowSnlzVy9XbUN2bUdoN1luZjFTNGpsNmhUeks3UHAxc2h1VFp3?=
 =?utf-8?B?UXFvQjVsbkMvaE5LVmlvZmgxOUJqeUdrWmF4ancyUCs4VTFjeDVDS01Lclp1?=
 =?utf-8?B?VCtVQmxOLzBua3VjUUlNc1ZmVWZpNElzdEtzNnMyTWlDV3lLMFNPYUdiSkxL?=
 =?utf-8?B?V2RJY3ZyVlB4TVVKSURVZENyMHg5b05WVlRBSEZkNlVaV3J3ckpJdGlGb2Yy?=
 =?utf-8?B?QXBrYTJhUE5TR0ZQVG15aC9BaG1veDlBMEE2MjNpZUEvMExuVFpKd2s4TFhl?=
 =?utf-8?B?L2t5dzJDUTVwN285cGxSSjlmbDcrSGRPUVZ2cUFDMFpub3BITTR0cGhjcStH?=
 =?utf-8?B?aHVQQWJaQUtvL29vTFB3bnFUTEZFeUQ2Sm90QUNVMFJBRWJTQlRSckx1dVZY?=
 =?utf-8?B?WlpXWERMV0JkTE1XTkFsM0ZYKy9QT3BXSzFhcEgxYkxmOUkwVDUxSThvcHZC?=
 =?utf-8?B?SDkwbDFrRHJpNTBPYmFSQ2dBUjJtUFF2SUJFYUpzTFlUcmNWUTliOWRlWURh?=
 =?utf-8?B?L3ZRK1lkenU1VVdOdnJHTmZXSVlwTWU2cXZrSHRLejNsdmJaSUV2VE9ZNmpB?=
 =?utf-8?B?Z2tYbGtWZ1NhMGZNSTRtT2QxbEJmOXFSK1F3QjUwNkVtbjNqUE9tNmdXWHhn?=
 =?utf-8?B?VmxBLzlhbzJiOSthTk1BRHZyd2hVL05kWFowQ014eHdSSGRqN0hMNEplY3pV?=
 =?utf-8?B?NFphSTdlTVROakxYZTJjdTdlOWplTXRwRHppTFFveUdiOG5yVk8yWFJ2akl6?=
 =?utf-8?B?UGJORGtYMTBWd3g0eURDY1BhMUc1NHpjMTk3UysrclUxMnRMdkF4anJmYm95?=
 =?utf-8?B?VENKUFc1ZUtnb1JBS0NSYTFyRy9rVG1uLzYvWFowM3h0YmF5ZXJIeS9FS2Zl?=
 =?utf-8?B?a3prS25SODVZbVpvbXB3NE1YSjE3aHp5bE1hUmJNRVVkeFBJOWJJay9RWGRX?=
 =?utf-8?B?NXZWMHZjWDFtNjF1UkQ5TEcvQ2gwNlJvVUpjTEM3RjBkd3M0UVNyS091SHRN?=
 =?utf-8?B?K0VodzIyK0hmS24xYWVXMGlrWldVQjZCeVFvYUt2bFUxRnRDQXBaUDl4Tyt4?=
 =?utf-8?B?SmVTZGJqcEVwUGl5Rnk0U0F6RWphQnJwWGE4dU9pL2xsSnFUbjIraXE5STJS?=
 =?utf-8?B?ZEV0NXF3cCt1SjVnVG9JclpiZHMrTXVKNitYbTkvRkFjb3BBNmx6c1VYeGpv?=
 =?utf-8?B?dUJJT3hvQnl2bFlhNVJSY3ZQZU1pNnYwUDdhU09MTzM5c25TdlRzRGhZWDhr?=
 =?utf-8?B?QWFaVWJISHdXY0hHWWdubThSK2N1aE0ralQwd1VKMS9sRWtta1FJaWFIQ3B0?=
 =?utf-8?B?dnBPMm1uSWxLdUxaOW12T2Z0Tlg1VHBSeTB1NDk0dzQ3MVBXSjlOWTRUS1J4?=
 =?utf-8?B?U2pMVS9NQjhoakxIWnQySnFhOVZkelFnOG9OVUpPcm15MXRBdTJoQ1hrRUNI?=
 =?utf-8?B?aDZsWXRCMXRKbFVFMlJxenA1MEZ4VGNRN2w3TUZtUjNjalBkRDBWMFV5TU0w?=
 =?utf-8?B?OXpGR1RqWjVyQUNHcUZCZCt0M1hIYktHbHZVc1lQbjBRUzVRdDBZelN4Q09H?=
 =?utf-8?B?L2hpQWVmNGxIM1JzalUwNVRIKzNDc2FXYlRYdTA3SjlVemd3Z3o5WjFjZkpn?=
 =?utf-8?B?WXBPMm5oclRWZTJUUWpRTytWWi8zci9EV1JQQVlqVjEwdy9zZjUvSTZ0RGx4?=
 =?utf-8?B?dWhjVkhZZjd1VTlNc2g0cU1Ia1pjdFE4dUtQR3MwNi9ITXlSeHBvcTJOa2hq?=
 =?utf-8?B?T05mR1JQeERieTh3bUFET042V0hEQnBJVllqS2paQ0gxakNjSHBhZG1XZTla?=
 =?utf-8?Q?mwai74?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:06:06.8803
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 937fdc0f-0fd0-4a8a-6826-08dd8ed8bbbb
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AE.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6796

Refactor REGISTER_VPCI_INIT to contain more capability specific
information, this is benefit for follow-on changes to hide capability
when initialization fails.

What's more, change the definition of init_header() since it is
not a capability and it is needed for all devices' PCI config space.

After refactor, the "priority" of initializing capabilities isn't
needed anymore, so delete its related codes.

Note:
Call vpci_make_msix_hole() in the end of init_msix() since the change
of sequence of init_header() and init_msix().

The cleanup hook is also added in this change, even if it's still
unused. Further changes will make use of it.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
cc: Andrew Cooper 
cc: Anthony PERARD 
cc: Michal Orzel 
cc: Jan Beulich 
cc: Julien Grall 
cc: Stefano Stabellini 
---
v3->v4 changes
* Delete the useless trailing dot of section ".data.vpci".
* Add description about priority since this patch removes the initializing priority of capabilities and priority is not needed anymore.
* Change the hook name from fini to cleanup.
* Change the name x and y to be finit and fclean.
* Remove the unnecessary check "!capability->init"

v2->v3 changes:
* This is separated from patch "vpci: Hide capability when it fails to initialize" of v2.
* Delete __maybe_unused attribute of "out" in function vpci_assign_devic().
* Rename REGISTER_VPCI_EXTEND_CAP to REGISTER_VPCI_EXTENDED_CAP.

v1->v2 changes:
* Removed the "priorities" of initializing capabilities since it isn't used anymore.
* Added new function vpci_capability_mask() and vpci_ext_capability_mask() to remove failed capability from list.
* Called vpci_make_msix_hole() in the end of init_msix().

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/header.c |  3 +--
 xen/drivers/vpci/msi.c    |  2 +-
 xen/drivers/vpci/msix.c   |  8 +++++--
 xen/drivers/vpci/rebar.c  |  2 +-
 xen/drivers/vpci/vpci.c   | 47 ++++++++++++++++++++++++++++++---------
 xen/include/xen/vpci.h    | 30 ++++++++++++++++++-------
 xen/include/xen/xen.lds.h |  2 +-
 7 files changed, 69 insertions(+), 25 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 2915c801adeb..9373d1b8be0d 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -855,7 +855,7 @@ static int vpci_init_ext_capability_list(struct pci_dev *pdev)
     return 0;
 }
 
-static int cf_check init_header(struct pci_dev *pdev)
+int vpci_init_header(struct pci_dev *pdev)
 {
     uint16_t cmd;
     uint64_t addr, size;
@@ -1051,7 +1051,6 @@ static int cf_check init_header(struct pci_dev *pdev)
     pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd);
     return rc;
 }
-REGISTER_VPCI_INIT(init_header, VPCI_PRIORITY_MIDDLE);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index 66e5a8a116be..ea7dc0c060ea 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -270,7 +270,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_INIT(init_msi, VPCI_PRIORITY_LOW);
+REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSI, init_msi, NULL);
 
 void vpci_dump_msi(void)
 {
diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 74211301ba10..f8ce89b8b32f 100644
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -703,9 +703,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
     pdev->vpci->msix = msix;
     list_add(&msix->next, &d->arch.hvm.msix_tables);
 
-    return 0;
+    spin_lock(&pdev->vpci->lock);
+    rc = vpci_make_msix_hole(pdev);
+    spin_unlock(&pdev->vpci->lock);
+
+    return rc;
 }
-REGISTER_VPCI_INIT(init_msix, VPCI_PRIORITY_HIGH);
+REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSIX, init_msix, NULL);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
index 793937449af7..026f8f7972d9 100644
--- a/xen/drivers/vpci/rebar.c
+++ b/xen/drivers/vpci/rebar.c
@@ -118,7 +118,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
+REGISTER_VPCI_EXTENDED_CAP(PCI_EXT_CAP_ID_REBAR, init_rebar, NULL);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 2022b61ea7b6..f03e1a8eebc0 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -36,8 +36,8 @@ struct vpci_register {
 };
 
 #ifdef __XEN__
-extern vpci_register_init_t *const __start_vpci_array[];
-extern vpci_register_init_t *const __end_vpci_array[];
+extern vpci_capability_t *const __start_vpci_array[];
+extern vpci_capability_t *const __end_vpci_array[];
 #define NUM_VPCI_INIT (__end_vpci_array - __start_vpci_array)
 
 #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
@@ -83,6 +83,35 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
 
 #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
 
+static int vpci_init_capabilities(struct pci_dev *pdev)
+{
+    for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
+    {
+        const vpci_capability_t *capability = __start_vpci_array[i];
+        const unsigned int cap = capability->id;
+        const bool is_ext = capability->is_ext;
+        unsigned int pos;
+        int rc;
+
+        if ( !is_hardware_domain(pdev->domain) && is_ext )
+            continue;
+
+        if ( !is_ext )
+            pos = pci_find_cap_offset(pdev->sbdf, cap);
+        else
+            pos = pci_find_ext_capability(pdev->sbdf, cap);
+
+        if ( !pos )
+            continue;
+
+        rc = capability->init(pdev);
+        if ( rc )
+            return rc;
+    }
+
+    return 0;
+}
+
 void vpci_deassign_device(struct pci_dev *pdev)
 {
     unsigned int i;
@@ -128,7 +157,6 @@ void vpci_deassign_device(struct pci_dev *pdev)
 
 int vpci_assign_device(struct pci_dev *pdev)
 {
-    unsigned int i;
     const unsigned long *ro_map;
     int rc = 0;
 
@@ -159,14 +187,13 @@ int vpci_assign_device(struct pci_dev *pdev)
         goto out;
 #endif
 
-    for ( i = 0; i < NUM_VPCI_INIT; i++ )
-    {
-        rc = __start_vpci_array[i](pdev);
-        if ( rc )
-            break;
-    }
+    rc = vpci_init_header(pdev);
+    if ( rc )
+        goto out;
+
+    rc = vpci_init_capabilities(pdev);
 
- out: __maybe_unused;
+ out:
     if ( rc )
         vpci_deassign_device(pdev);
 
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 61d16cc8b897..7d4274e178ee 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -13,11 +13,12 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev, unsigned int reg,
 typedef void vpci_write_t(const struct pci_dev *pdev, unsigned int reg,
                           uint32_t val, void *data);
 
-typedef int vpci_register_init_t(struct pci_dev *dev);
-
-#define VPCI_PRIORITY_HIGH      "1"
-#define VPCI_PRIORITY_MIDDLE    "5"
-#define VPCI_PRIORITY_LOW       "9"
+typedef struct {
+    unsigned int id;
+    bool is_ext;
+    int (*init)(struct pci_dev *pdev);
+    void (*cleanup)(struct pci_dev *pdev);
+} vpci_capability_t;
 
 #define VPCI_ECAM_BDF(addr)     (((addr) & 0x0ffff000) >> 12)
 
@@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
  */
 #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
 
-#define REGISTER_VPCI_INIT(x, p)                \
-  static vpci_register_init_t *const x##_entry  \
-               __used_section(".data.vpci." p) = (x)
+#define REGISTER_VPCI_CAP(cap, finit, fclean, ext) \
+  static vpci_capability_t finit##_t = { \
+        .id = (cap), \
+        .init = (finit), \
+        .cleanup = (fclean), \
+        .is_ext = (ext), \
+  }; \
+  static vpci_capability_t *const finit##_entry  \
+               __used_section(".data.vpci") = &finit##_t
+
+#define REGISTER_VPCI_LEGACY_CAP(cap, finit, fclean) \
+                REGISTER_VPCI_CAP(cap, finit, fclean, false)
+#define REGISTER_VPCI_EXTENDED_CAP(cap, finit, fclean) \
+                REGISTER_VPCI_CAP(cap, finit, fclean, true)
+
+int __must_check vpci_init_header(struct pci_dev *pdev);
 
 /* Assign vPCI to device by adding handlers. */
 int __must_check vpci_assign_device(struct pci_dev *pdev);
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index 793d0e11450c..84ec506b00da 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -188,7 +188,7 @@
 #define VPCI_ARRAY               \
        . = ALIGN(POINTER_ALIGN); \
        __start_vpci_array = .;   \
-       *(SORT(.data.vpci.*))     \
+       *(.data.vpci)             \
        __end_vpci_array = .;
 #else
 #define VPCI_ARRAY
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 09:06:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:06:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979882.1366403 (Exim 4.92)
	(envelope-from )
	id 1uDJgP-0005Sb-8t; Fri, 09 May 2025 09:06:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979882.1366403; Fri, 09 May 2025 09:06: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 1uDJgP-0005Qu-0S; Fri, 09 May 2025 09:06:17 +0000
Received: by outflank-mailman (input) for mailman id 979882;
 Fri, 09 May 2025 09:06:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJgO-0004kr-1E
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:06:16 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20607.outbound.protection.outlook.com
 [2a01:111:f403:2415::607])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id db7844b9-2cb4-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 11:06:14 +0200 (CEST)
Received: from BYAPR02CA0006.namprd02.prod.outlook.com (2603:10b6:a02:ee::19)
 by CH3PR12MB9194.namprd12.prod.outlook.com (2603:10b6:610:19f::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.23; Fri, 9 May
 2025 09:06:09 +0000
Received: from CO1PEPF000042AE.namprd03.prod.outlook.com (2603:10b6:a02:ee::4)
 by BYAPR02CA0006.outlook.office365.com (2603:10b6:a02:ee::19) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20
 via Frontend Transport; Fri, 9 May 2025 09:06:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042AE.mail.protection.outlook.com (10.167.243.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:06:09 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:06: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" 
X-Inumbo-ID: db7844b9-2cb4-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EEpoZ/dSZji/WW+SrbqHy3SyTh+LnAI+Y9eUX2JmMRhLOxtrM/+uwa84bD4hqsktHJRwzpLM/vTFdwSw6flQyQ++h4UmDP498GqdT9Scbqk1p1dBbRNt8Iid2BQ8/22HmOZXb53Nl6VJNfv5Jqcnskug+eMWP4Keed5NRLHTg2BKWFYgf/EzHCMvpG3rc2/bPfcirSyvQo2+blDo1v8cSMdweR8qL6LcroK3NzciuuLOCvQNBmiQ5oXnL1o9GLbrRukkRfzeZ+Rc2+EVIy8Gj3wqD1TQqf/nc22QBAFY+ORToQmloLpUCe4vv6ZL/qr2VXZwzL9lSK98ZrYtZwBO0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZfFOB0Mnzec6rTpJsTgNXsMjGaiorSO7uuWfsMiLw/o=;
 b=VYbLT4guAcGya/GK25qmZ/S8+EoLcBN9sROJ0PSa0rWgltdGP+3zrdcYoty8hC1eT5b/5oJB2+tko3Qs4Y1isyvFYimuCP/AM13VK6bNIAq66jJ2LoGOawe+B6uu43330n9Ont8TgV6mOLsNh7CKzzoyDDrUh59TwabrmCxgsvgWl5YaSV0z8CiWBItRt2blfp7OBPMpJQLNkMGtki1gBNWjQzLXTTGQLCoDNUC10LUlodD4Zyk0cNmIrywQstAQ+bCeA9vJbxcxWiNKCaChIAVrkD566/L58To/LiuX9GEmI256D34koAeDTFOGwl4sQvSaasKyrDzAxKYAK6XiiA==
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=ZfFOB0Mnzec6rTpJsTgNXsMjGaiorSO7uuWfsMiLw/o=;
 b=g9JEw3nBEmotFoR44sR7ToOHoUs5rbKaFe95T0TFPvum+3+J5IUyv5wC/b4yoz8R1ltBOQxDNLUBwg/pyFsAwqH0R6KeajdbHuEl+qID5UIkytt5Jma4E8voPMshYMcqEBIB4Xqf559/FNrKeUE+Xo3HCkIw/wFWfibG84XnR+A=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v4 06/10] vpci: Hide extended capability when it fails to initialize
Date: Fri, 9 May 2025 17:05:38 +0800
Message-ID: <20250509090542.2199676-7-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AE:EE_|CH3PR12MB9194:EE_
X-MS-Office365-Filtering-Correlation-Id: 5a5928e1-0bfd-4a64-60ae-08dd8ed8bd3b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WlpaTHRqZ1JPQlZzbEpJSXBhSHJFeHdKTVB1SlRuS1RpcUNxVENYMmF0bjVN?=
 =?utf-8?B?SmNvSnVHMVc5WWRLYlZTc3M4MlNuaG8zVjdIT1ZmRlhiWU9oL0QzVHA1dkRa?=
 =?utf-8?B?NENoMjJxS3NHRi8xMGZxcmlCbXVqV0RTam1kbUlaUGxCVEJCSEJJUU1EQ2VS?=
 =?utf-8?B?WE9qZi91RjFxWU9mc3hRUWhWenh2clo5dmd2WHRvVElKcjhyY2JCRmxyNU5O?=
 =?utf-8?B?NFB0SFBLZWhtSHhXNUZXRFV1dXg0WnJlV0hBK2NUaVZGZmxlMnREdG1mYnRk?=
 =?utf-8?B?SW90YUh6MUVvRmI3cVhlUDNBOGFjTTRQUzZjbVc2WFJ2YXJtWDhVM1Frdm9t?=
 =?utf-8?B?dnpCRjdBTk1KZVNmcDliZmRPdzgzRDM2ZzF5L0xUUUpOaVJqUHZNWUovYnNO?=
 =?utf-8?B?ZytDRnZwMVdqU2lwUFJ1VS9FbUJOaTIwUEs1d1FSc3dMOUhDeHZqekRTNFdZ?=
 =?utf-8?B?MmtTZTZMSlQwWkFBTnFzSXNtYkxXSkFwK0M2OXFhUW90UXEwRC83bUZyc3hw?=
 =?utf-8?B?NVZNTXgyaXA4SHd6ZGNiZUxLaTE5a1dRRjVIZmgvZjhLVmpDaTVjbnpCbGdh?=
 =?utf-8?B?K3dnU3hFMDVsVm10V0hUZS9pUXRmemp6ZDdYVzlCdm1tN2xkeHNmd0lmQkx6?=
 =?utf-8?B?Y0xLUm4xMFZDTVIyZ3ZmZE85UUpaQW9OMDFTb3dHQlRqanFWS2poaXFZcDgv?=
 =?utf-8?B?bS8wZmEvTzF6S09ZT3IvV2NIanpZVnA3QVpRRHd1RTdkV2hBQzlBeVpBdzZZ?=
 =?utf-8?B?ZU9ZK09OT2ZxY0Q1ZHlObUpCc1NQTS9WcVcvbE1oM0NEMTVtT0Z2cXNDdURT?=
 =?utf-8?B?ZlQ4N01aTXBPZDJFaVpWeDJnaUhUSlp5Q3Y0c0JMOE5pWDRkeUc3YUVrdGhR?=
 =?utf-8?B?N1VrZjdMZTRDNGtkTUVYaElSdzhHOStKK0ZUQ2RLdWJockRUQmVwQW1ib0Va?=
 =?utf-8?B?L1J4Y1c5dWc1R0ppODJXYjc0OGZ2VVNDaXl3eitMQTdZVzlTRytGT0k4QTdY?=
 =?utf-8?B?YzdpTVZwVkh6M2lvNU1pMDdkUDRSczljdUplbElNM3REei9qc1YxV2pxVStm?=
 =?utf-8?B?Z3Brby9qejBaanlsMnFjQTBMMHZEcW5MZlZ4cE4rOHRxSkdWYWYwRXQwOTlU?=
 =?utf-8?B?aEJXdTBBTkFEeHhSSjNoM1JtN0xHQmptTmFBcjVTSXdRV3YxaWtHTks5anNx?=
 =?utf-8?B?eDZaK1hZYXV0TGlMNXowSy94cTlhUmhiR0UrS0RSYXBUUVU2RzQ5M1BpLzND?=
 =?utf-8?B?TWt0MFp0RWczRWpLRmxvZGwyaE8vU2F5L1U0RlhuNzlZNmxweEQzTTF6cmVa?=
 =?utf-8?B?WncvSmFYUEpwSTA3WGYwNFl1bDJVYTJzWnUwdzRnbDdHamFtcHhOdXBmRlhF?=
 =?utf-8?B?N0d6YTR2WnlCVUxEMTRRNHhtVzZ0ZDE3NVFCL2pKcXJWbEMxbHA4dE5UOGx6?=
 =?utf-8?B?RE1OU0xOOHV2T1JieXIzdHJGQVRrdEY4eFBYRWJTMU5haDd6OFJhSTdCbHd0?=
 =?utf-8?B?cDQxUDJPYUhxTjhxaEphaUFnY1lHT1pEMENiMlpSMXZySENCU245aUVTOTNy?=
 =?utf-8?B?eVZNelVQdW1zN1FoNGdiZXdyOFo4OStocE5weXpTNm1xVG9URFdGQUt5dEdU?=
 =?utf-8?B?aVptNzJkd1phNHFHSUVFQklucVNVOUVuUUhnV2d1djZFc1JYQ2g3S25wUFBk?=
 =?utf-8?B?cEZ4RTkzVHVtM3NhYytPd3dvam9zYjFkWDNZM3ZLc3g5UHNadk42SGxKSkJx?=
 =?utf-8?B?U0s3QmZScXBUeHlrZ28vRDF3SlI3ejBkaWliNzdaRGo1WGlwbzZ0RXBzNjZv?=
 =?utf-8?B?ZFhPL1RJbUFSU0pERmU0SllJN21KYzhvKzhCWlNmYnVFaXYrVEF5ZFZ6c1A5?=
 =?utf-8?B?NUozK05RK29pa3BUdkp3clMvTmZsdm1rVW52SWk4UkFldkVJcFI1Rjl5SG5a?=
 =?utf-8?B?VEdpM29Ob0gvVkRMNVk4NWJsUEl5TTRONkhsWitHYUNjN2NUN213Z3Qxck1Z?=
 =?utf-8?B?bFdWbjhXUXplUi9RQmhXMUhjMmd0UG8zZ2d6WlhiQ2xmdlZweVhkZXVQU1pZ?=
 =?utf-8?Q?FYdLcA?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:06:09.3959
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a5928e1-0bfd-4a64-60ae-08dd8ed8bd3b
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AE.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9194

When vpci fails to initialize a extended capability of device, it
just returns an error and vPCI gets disabled for the whole device.

So, add function to hide extended capability when initialization
fails. And remove the failed extended capability handler from vpci
extended capability list.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v3->v4 changes:
* Change definition of PCI_EXT_CAP_NEXT to be "#define PCI_EXT_CAP_NEXT(header) (MASK_EXTR(header, PCI_EXT_CAP_NEXT_MASK) & 0xFFCU)" to avoid redundancy.
* Modify the commit message.
* Change vpci_ext_capability_mask() to return error instead of using ASSERT.
* Set the capability ID part to be zero when we need to hide the capability of position 0x100U.
* Add check "if ( !offset )" in vpci_ext_capability_mask().

v2->v3 changes:
* Separated from the last version patch "vpci: Hide capability when it fails to initialize".
* Whole implementation changed because last version is wrong.
  This version gets target handler and previous handler from vpci->handlers, then remove the target.
* Note: a case in function vpci_ext_capability_mask() needs to be discussed,
  because it may change the offset of next capability when the offset of target
  capability is 0x100U(the first extended capability), my implementation is just to
  ignore and let hardware to handle the target capability.

v1->v2 changes:
* Removed the "priorities" of initializing capabilities since it isn't used anymore.
* Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
  remove failed capability from list.
* Called vpci_make_msix_hole() in the end of init_msix().

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/vpci.c    | 100 +++++++++++++++++++++++++++++++++++--
 xen/include/xen/pci_regs.h |   5 +-
 2 files changed, 100 insertions(+), 5 deletions(-)

diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index e1d4e9aa9b88..76d663753e7b 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -193,6 +193,98 @@ static int vpci_capability_mask(struct pci_dev *pdev, unsigned int cap)
     return 0;
 }
 
+static struct vpci_register *vpci_get_previous_ext_cap_register(
+    struct vpci *vpci, unsigned int offset)
+{
+    uint32_t header;
+    unsigned int pos = PCI_CFG_SPACE_SIZE;
+    struct vpci_register *r;
+
+    if ( offset <= PCI_CFG_SPACE_SIZE )
+    {
+        ASSERT_UNREACHABLE();
+        return NULL;
+    }
+
+    r = vpci_get_register(vpci, pos, 4);
+    if ( !r )
+        return NULL;
+
+    header = (uint32_t)(uintptr_t)r->private;
+    pos = PCI_EXT_CAP_NEXT(header);
+    while ( pos > PCI_CFG_SPACE_SIZE && pos != offset )
+    {
+        r = vpci_get_register(vpci, pos, 4);
+        if ( !r )
+            return NULL;
+        header = (uint32_t)(uintptr_t)r->private;
+        pos = PCI_EXT_CAP_NEXT(header);
+    }
+
+    if ( pos <= PCI_CFG_SPACE_SIZE )
+        return NULL;
+
+    return r;
+}
+
+static int vpci_ext_capability_mask(struct pci_dev *pdev, unsigned int cap)
+{
+    const unsigned int offset = pci_find_ext_capability(pdev->sbdf, cap);
+    struct vpci_register *rm, *prev_r;
+    struct vpci *vpci = pdev->vpci;
+    uint32_t header, pre_header;
+
+    if ( !offset )
+    {
+        ASSERT_UNREACHABLE();
+        return 0;
+    }
+
+    spin_lock(&vpci->lock);
+    rm = vpci_get_register(vpci, offset, 4);
+    if ( !rm )
+    {
+        spin_unlock(&vpci->lock);
+        return -ENODEV;
+    }
+
+    header = (uint32_t)(uintptr_t)rm->private;
+    if ( offset == PCI_CFG_SPACE_SIZE )
+    {
+        if ( PCI_EXT_CAP_NEXT(header) <= PCI_CFG_SPACE_SIZE )
+            rm->private = (void *)(uintptr_t)0;
+        else
+            /*
+             * If this case removes target capability of position 0x100U, then
+             * it needs to move the next capability to be in position 0x100U,
+             * that would cause the offset of next capability in vpci different
+             * from the hardware, then cause error accesses, so here chooses to
+             * set the capability ID part to be zero.
+             */
+            rm->private = (void *)(uintptr_t)(header &
+                                              ~PCI_EXT_CAP_ID(header));
+
+        spin_unlock(&vpci->lock);
+        return 0;
+    }
+
+    prev_r = vpci_get_previous_ext_cap_register(vpci, offset);
+    if ( !prev_r )
+    {
+        spin_unlock(&vpci->lock);
+        return -ENODEV;
+    }
+
+    pre_header = (uint32_t)(uintptr_t)prev_r->private;
+    prev_r->private = (void *)(uintptr_t)((pre_header &
+                                           ~PCI_EXT_CAP_NEXT_MASK) |
+                                          (header & PCI_EXT_CAP_NEXT_MASK));
+    list_del(&rm->node);
+    spin_unlock(&vpci->lock);
+    xfree(rm);
+    return 0;
+}
+
 static int vpci_init_capabilities(struct pci_dev *pdev)
 {
     for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
@@ -225,11 +317,11 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
                    pdev->domain, &pdev->sbdf,
                    is_ext ? "extended" : "legacy", cap, rc);
             if ( !is_ext )
-            {
                 rc = vpci_capability_mask(pdev, cap);
-                if ( rc )
-                    return rc;
-            }
+            else
+                rc = vpci_ext_capability_mask(pdev, cap);
+            if ( rc )
+                return rc;
         }
     }
 
diff --git a/xen/include/xen/pci_regs.h b/xen/include/xen/pci_regs.h
index 27b4f44eedf3..e62bf72ab3d3 100644
--- a/xen/include/xen/pci_regs.h
+++ b/xen/include/xen/pci_regs.h
@@ -448,7 +448,10 @@
 /* Extended Capabilities (PCI-X 2.0 and Express) */
 #define PCI_EXT_CAP_ID(header)		((header) & 0x0000ffff)
 #define PCI_EXT_CAP_VER(header)		(((header) >> 16) & 0xf)
-#define PCI_EXT_CAP_NEXT(header)	(((header) >> 20) & 0xffc)
+#define PCI_EXT_CAP_NEXT_MASK		0xFFF00000U
+/* Bottom two bits of next capability position are reserved. */
+#define PCI_EXT_CAP_NEXT(header) \
+    (MASK_EXTR(header, PCI_EXT_CAP_NEXT_MASK) & 0xFFCU)
 
 #define PCI_EXT_CAP_ID_ERR	1
 #define PCI_EXT_CAP_ID_VC	2
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 09:06:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:06:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979883.1366419 (Exim 4.92)
	(envelope-from )
	id 1uDJgR-0005zS-HY; Fri, 09 May 2025 09:06:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979883.1366419; Fri, 09 May 2025 09: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 1uDJgR-0005zI-Di; Fri, 09 May 2025 09:06:19 +0000
Received: by outflank-mailman (input) for mailman id 979883;
 Fri, 09 May 2025 09:06:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJgP-0005aH-Pi
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:06:17 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20605.outbound.protection.outlook.com
 [2a01:111:f403:2415::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dbfeb54d-2cb4-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 11:06:15 +0200 (CEST)
Received: from BYAPR05CA0030.namprd05.prod.outlook.com (2603:10b6:a03:c0::43)
 by SJ0PR12MB6709.namprd12.prod.outlook.com (2603:10b6:a03:44a::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.21; Fri, 9 May
 2025 09:06:12 +0000
Received: from CO1PEPF000042A7.namprd03.prod.outlook.com
 (2603:10b6:a03:c0:cafe::83) by BYAPR05CA0030.outlook.office365.com
 (2603:10b6:a03:c0::43) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.18 via Frontend Transport; Fri,
 9 May 2025 09:06:11 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042A7.mail.protection.outlook.com (10.167.243.36) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:06:11 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:06: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" 
X-Inumbo-ID: dbfeb54d-2cb4-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eRqA53s60BaB7utvC4ithQGNPwdHp65elNJPBVgy2ZtOVqoPTpZgzD6dfP4eguGi2JoL09RQpq0qDh4qHbxT/ewKZaRD4cpgsHGdxfmrRwtglF1LNM/pcRy2KdH4eviWdXCfWAuoaPfOFNykWMa5sUiL9uJ5aAT+5ajbFfEW/xy4ITc/oW/ibIgugsdrT2K3gmM0TLobhkDFLboneX7lP+3vYnVrkkI/9RiRGPLEYZcYZEvk9TcX/MBpBP3QxqrMBdQxoS7PKeatpkDHTMrTSisq3e9Ji3dFqaLtTxpxUtERCR+pHsYLQm2F8F70UhXosgAlgl97VUYlV2c1LNigmA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=p6G7DJ7nIDNTyKDlrjUtQimi6DsZE3vULZcx6kuZrv4=;
 b=VhYz7nWnIHg71+u9tPkEQWyJm/zdQLMdHjqX7FL6MG6qeTnLml3f/TfropiWwyLRqayWzcKSUU8xh5kFnNlGCy2Gw1j8f2sdncJBTNWVDIAFy4DPgKMlq/NYbhxt4qyBfxb8T479UDtVTJC/4RGsBdM+91g0L5X0K8DYjOleGSe4ULCRhP7IGkyC+2+ZxihbaXsue0pcDvvOftSARHBkAvTGeIrbxxtRRptzSxnCKYIJwSZTgusfEpen8UBRn7Cy0jmusiKx3o6RsTJIOtVBiem2o8e/YOTHLm/FzRu5QcVb0mFcEblCbU36xUfYdoWwjqnkEr0fNxoGx0fBFCZrHw==
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=p6G7DJ7nIDNTyKDlrjUtQimi6DsZE3vULZcx6kuZrv4=;
 b=zQsQd6DpBvm8ghD5pUGGY54HEt4skN5iUgNWphaKZ/mYJm55nRtAeux5xaFbUzKIzCB9/0p+etpg2II6DdN9PYbwbihrispwh+IuePwArFD/SDxq2r9WXUcX5OAjiCclXbOUAZEQgFqI7GfE9sbgatPwufksRwEZgbH/XFD19bw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	
Subject: [PATCH v4 07/10] vpci: Refactor vpci_remove_register to remove matched registers
Date: Fri, 9 May 2025 17:05:39 +0800
Message-ID: <20250509090542.2199676-8-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042A7:EE_|SJ0PR12MB6709:EE_
X-MS-Office365-Filtering-Correlation-Id: 06864198-1481-4caa-8782-08dd8ed8be81
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dEVndzdqRXkwd1JlVGFtSWNEUDZBVnU3a01rWE9QY1ZwM3FSWXB3QlFnK1BL?=
 =?utf-8?B?eThmVFNGYzRSM0dya3Z5K0haa2pBN1huTXRacVgzL0JUMEkzRWdodXYrVXQw?=
 =?utf-8?B?RWhRcVhFaWJFS2ROQ29GYzZ6L1grS1BjRE9sR2p4NVZ3QVMxMXk0dXJkaEdE?=
 =?utf-8?B?MnNSZUNrWWQ1ZkV2USticE9Gb3ZkSFBuNU1tcmVaUEoxTi9VdEFraG9Ob2hs?=
 =?utf-8?B?T25sTjRhOWw4VkZ3Uk9IN0doSFFsSXNUaG5pd0VvRGxOQmVHLzJlT0xzVzgw?=
 =?utf-8?B?cnFQbzVMTDN2b2xnZUdFekJWT0laZ1gyVlJ5QXhQQXVuTEdXZjhrNjREZUdR?=
 =?utf-8?B?U0pORzFLZ0VhZmswMVRmUlpvRzFNa2RDWmNibG5YWHk4elZEVUdTbUNUd1JF?=
 =?utf-8?B?OVdrb3RGMU10Nm9mREh2VVVSczVvdGg2ZnFwWUdJZDJuc2liZjJCVCswM2Yz?=
 =?utf-8?B?dkp4MEwyOEk2YWJENUR2NHJmK2RXY3RpQUM5enZUL3pHT2ZkWlpBRWFxZWtx?=
 =?utf-8?B?UVRleW5OdE1FOHluZktSbk5IWjdCcUZRemhkTHdKQWtXSWJIWnIyM2lrcmQy?=
 =?utf-8?B?WmxaVnlTaG9kYWI3YzY3UjhoU3R3Nk9GQkdWODRhMXMzaG95UGQ0eFhCd01E?=
 =?utf-8?B?QlJRNHdmUHZsdVo2U2l2d0pSdVZOb3pmQmlOTEUrWUhPRUJXdFlqZmtNOUIx?=
 =?utf-8?B?a0czdDZHV0lURFdNWTFCR000NDFIZStSRjJwZ2xhUmVtRzd1a1pXNlM3VndY?=
 =?utf-8?B?cjR6ZjRiSC9KTjZIT1VlTFh6QkQ2Z1ZWcitrVXp4bExjTzBORnI2Ni9VSGV4?=
 =?utf-8?B?TWppWWZDYmxCUUlFUkFVVllsZDRHMmdIa2JhNXEwRUlpNHZDQkJ3UzMyV2VE?=
 =?utf-8?B?SDFNSW5sZ00xaWlJVFlXVzdJNzJ4dlQzQTRhdFRpSHd4dTZ3UnEvaHhWdzFD?=
 =?utf-8?B?Mlg1VmZ0V2VJcWpDME9wR0tucTRtRnhka2hJeCtabSt6TDJIYjc1UTBhNS9w?=
 =?utf-8?B?Y2dZT2JUNlJwN2RScURUZGh3T3pKYk5icjZGZ3dwNGJXK0JteENsa203aUJV?=
 =?utf-8?B?WG5RZ3Vja0JVL00zYkY2RlovOUt0VFlRdENsbjJRQjJFODkxci9aQm5maGlE?=
 =?utf-8?B?TzRZbVNHRWhpc0FJRHZnMTcwV2huUzJHR1ZYSGdVclBLL0R3bWRZakxCMktU?=
 =?utf-8?B?VjV5d1l1TDNsRjdwSGhJcDFzNDhoY0lhaklHMlhaU210YzFoSzZhN0EzTGpR?=
 =?utf-8?B?bGtSZHFYK2lDQ2dpcDNiazFnZkpOMUJtam5hRHJFWkhkNE9pWHdrWm5ENFdv?=
 =?utf-8?B?N1Z2b3VmUmhCTWsxd1FhWkVPQW9sb3FjaHV1RnAvRDhwQUxUTUppUGF1Zjll?=
 =?utf-8?B?dVU3OXJweWtoQjVEUmY3OTNMc1pGK2MvYlZiR0xvZ1pQb2ViTlU1WEVhcjFz?=
 =?utf-8?B?T3FCL2E3SUY1NXgzNkVoa3dDMWM5eEhEVFg4Uk1JUDlBbHRCNmp6aFBaRDhm?=
 =?utf-8?B?Y0ZYZVVSbTQwNDk5U05EUzVxTWlWZXdZV0FQUjY1NHhYS1dhQWhGUndjQzN2?=
 =?utf-8?B?d3VISnJ6TnlHV0xMR3FhOVhCUXAvQlNBQVhvanVzdStMSWhpakRoZXptUmRV?=
 =?utf-8?B?OUk4U3R3VFZIMTI4eVpPUkltZ3JQSVgrQmVKbGRNQWVpYTFsWlVQR2NSVFdh?=
 =?utf-8?B?Mi9CK1k4MkVFNElhMFBJOGVhK0hENUVNOU5SUnR1N1lSYWp0UmZhZjl5aXZH?=
 =?utf-8?B?b3FiM01NOE9XNlRvOGZaSExpcDF3TXI2R29XOTR2RGZya1Y1dGd1OUlFTkJo?=
 =?utf-8?B?aFVTRWJZTzAzR2FwNFNUSGRIRzdRRENIN3N1Z3JDbldaNWtaODdXY2FzVE96?=
 =?utf-8?B?OW1EOElqbjZFQW44eHBuNGhKeHVabVJPNGxRRjhqTjlydEhqY1A2dHc1ZVFH?=
 =?utf-8?B?aVJEQndCMWU5M2ptYndIMmE3elRUdHlYdTJUNkdmTWlMNzRzU2p3eGkvYjZk?=
 =?utf-8?B?QnRkaUpMZy9Cd1dZY1IwRm9mcnlQS202OC9sK0Irck1jM2x0OEF2UHVndXI5?=
 =?utf-8?Q?q7m7Wp?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:06:11.5334
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 06864198-1481-4caa-8782-08dd8ed8be81
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042A7.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6709

vpci_remove_register() only supports removing a register in a time,
but the follow-on changes need to remove all registers within a range.
So, refactor it to support removing all matched registers in a calling
time.

And it is no matter to remove a non exist register, so remove the
__must_check prefix.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
cc: Anthony PERARD 
---
v3->v4 changes:
* Use list_for_each_entry_safe instead of list_for_each_entry.
* Return ERANGE if overlap.

v2->v3 changes:
* Add new check to return error if registers overlap but not inside range.

v1->v2 changes:
new patch

Best regards,
Jiqian Chen.
---
 tools/tests/vpci/main.c |  4 ++--
 xen/drivers/vpci/vpci.c | 38 ++++++++++++++++++++------------------
 xen/include/xen/vpci.h  |  4 ++--
 3 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/tools/tests/vpci/main.c b/tools/tests/vpci/main.c
index 33223db3eb77..ca72877d60cd 100644
--- a/tools/tests/vpci/main.c
+++ b/tools/tests/vpci/main.c
@@ -132,10 +132,10 @@ static void vpci_write32_mask(const struct pci_dev *pdev, unsigned int reg,
                                   rsvdz_mask))
 
 #define VPCI_REMOVE_REG(off, size)                                          \
-    assert(!vpci_remove_register(test_pdev.vpci, off, size))
+    assert(!vpci_remove_registers(test_pdev.vpci, off, size))
 
 #define VPCI_REMOVE_INVALID_REG(off, size)                                  \
-    assert(vpci_remove_register(test_pdev.vpci, off, size))
+    assert(vpci_remove_registers(test_pdev.vpci, off, size))
 
 /* Read a 32b register using all possible sizes. */
 void multiread4_check(unsigned int reg, uint32_t val)
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 76d663753e7b..ae39a0436284 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -180,7 +180,7 @@ static int vpci_capability_mask(struct pci_dev *pdev, unsigned int cap)
 
     prev_next_r->private = next_r->private;
     /*
-     * Not calling vpci_remove_register() here is to avoid redoing
+     * Not calling vpci_remove_registers() here is to avoid redoing
      * the register search
      */
     list_del(&next_r->node);
@@ -188,7 +188,7 @@ static int vpci_capability_mask(struct pci_dev *pdev, unsigned int cap)
     xfree(next_r);
 
     if ( !is_hardware_domain(pdev->domain) )
-        return vpci_remove_register(vpci, offset + PCI_CAP_LIST_ID, 1);
+        return vpci_remove_registers(vpci, offset + PCI_CAP_LIST_ID, 1);
 
     return 0;
 }
@@ -532,34 +532,36 @@ int vpci_add_register_mask(struct vpci *vpci, vpci_read_t *read_handler,
     return 0;
 }
 
-int vpci_remove_register(struct vpci *vpci, unsigned int offset,
-                         unsigned int size)
+int vpci_remove_registers(struct vpci *vpci, unsigned int start,
+                          unsigned int size)
 {
-    const struct vpci_register r = { .offset = offset, .size = size };
-    struct vpci_register *rm;
+    struct vpci_register *rm, *tmp;
+    unsigned int end = start + size;
 
     spin_lock(&vpci->lock);
-    list_for_each_entry ( rm, &vpci->handlers, node )
+    list_for_each_entry_safe ( rm, tmp, &vpci->handlers, node )
     {
-        int cmp = vpci_register_cmp(&r, rm);
-
-        /*
-         * NB: do not use a switch so that we can use break to
-         * get out of the list loop earlier if required.
-         */
-        if ( !cmp && rm->offset == offset && rm->size == size )
+        /* Remove rm if rm is inside the range. */
+        if ( rm->offset >= start && rm->offset + rm->size <= end )
         {
             list_del(&rm->node);
-            spin_unlock(&vpci->lock);
             xfree(rm);
-            return 0;
+            continue;
         }
-        if ( cmp <= 0 )
+
+        /* Return error if registers overlap but not inside. */
+        if ( rm->offset + rm->size > start && rm->offset < end )
+        {
+            spin_unlock(&vpci->lock);
+            return -ERANGE;
+        }
+
+        if ( start < rm->offset )
             break;
     }
     spin_unlock(&vpci->lock);
 
-    return -ENOENT;
+    return 0;
 }
 
 /* Wrappers for performing reads/writes to the underlying hardware. */
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 7d4274e178ee..346006438fe4 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -71,8 +71,8 @@ static inline int __must_check vpci_add_register(struct vpci *vpci,
                                   size, data, 0, 0, 0, 0);
 }
 
-int __must_check vpci_remove_register(struct vpci *vpci, unsigned int offset,
-                                      unsigned int size);
+int vpci_remove_registers(struct vpci *vpci, unsigned int start,
+                          unsigned int size);
 
 /* Generic read/write handlers for the PCI config space. */
 uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 09:06:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:06:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979884.1366422 (Exim 4.92)
	(envelope-from )
	id 1uDJgR-00063Z-SK; Fri, 09 May 2025 09:06:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979884.1366422; Fri, 09 May 2025 09: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 1uDJgR-00062l-ON; Fri, 09 May 2025 09:06:19 +0000
Received: by outflank-mailman (input) for mailman id 979884;
 Fri, 09 May 2025 09:06:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJgR-0005aH-3Q
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:06:19 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2414::61b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dd1782aa-2cb4-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 11:06:17 +0200 (CEST)
Received: from BYAPR05CA0006.namprd05.prod.outlook.com (2603:10b6:a03:c0::19)
 by CYYPR12MB8870.namprd12.prod.outlook.com (2603:10b6:930:bb::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.23; Fri, 9 May
 2025 09:06:13 +0000
Received: from CO1PEPF000042A7.namprd03.prod.outlook.com
 (2603:10b6:a03:c0:cafe::92) by BYAPR05CA0006.outlook.office365.com
 (2603:10b6:a03:c0::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.18 via Frontend Transport; Fri,
 9 May 2025 09:06:13 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042A7.mail.protection.outlook.com (10.167.243.36) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:06:13 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:06: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" 
X-Inumbo-ID: dd1782aa-2cb4-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=d2Www8yJ4WMsXQUU/jASbhYGgn7DgoaUVlpm+PYn0S/xtKJr1Z4Qt1fOXg068ZAhgSuEdGHaYEq/Jm2bF/Ckdn5dipHlreHI2Mp9f5KxTKzVr77oc+Y8Z4QWnOE7TfFoEUoV6Ih33nDNIOtC5BmcApgViisiN3jf+cmTCSSmZGZ1UxNZbk/mK9jhV6XElBjexkSXiMNbWbXNZC4VA+SrY00DXmeihdhKyFbWGECCFS8mpZEs8QTW1a1RcRkj7wiyWpMKz5XcmwlAS8p1wa6chzYR84nhrbkqvUg7dbGobPT1aQ1JMd/sC429pLkk5rXQZLayxD3OgZAkXRzoakkbOw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kw2cLNMP7nhnjjRXLpH9cMEC0XjcDzuavgW2fNomNPA=;
 b=jx9Pjxr3OJUOKECmg6dgFnHBtjq4Mq5qGgjQFsx8BmzTk6Cu6uroLAbKS/BVKDr8PXw8eGV90hZBsq46UQsD8DiLAAI9AWw6u0vG5+xA2DLXnzYq3lx4vRuNM1N0KvY/iinVw41vpIPGsXlZ1iShpAeCPjT6By+0hD24aESODykmvSq+jvTQK9lnunLc0PjrQMzGyR3gGhUa/Pp/9gnL53oMFAhDRG857j6aXLzeNnWqzqmOe4zrGTv1KlMXyoR16rH0E3HVCid5vIGQrT31xXqZlqC6VqctBUG2iwQz753U5H0OW9aV3oFQYZO18GrsJYURuG6AH5kbidaEpqaRng==
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=kw2cLNMP7nhnjjRXLpH9cMEC0XjcDzuavgW2fNomNPA=;
 b=Fp6rq3MO7vjLUlR/eCqzDNvRV6E+hCwMTQ42g/Pr5tiX33iJ6gKEym7CYUDA3rfjX+av2fW/fiY6vWYhnQiYi9OFk2U/1gTno3Mj0T/nMaaL38seQDj+Gem/2BvKHvsjMC0z+iyIdcXbewAZODs8Cli0CyMQ2sSW96Nb09ctSDk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v4 08/10] vpci/rebar: Remove registers when init_rebar() fails
Date: Fri, 9 May 2025 17:05:40 +0800
Message-ID: <20250509090542.2199676-9-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042A7:EE_|CYYPR12MB8870:EE_
X-MS-Office365-Filtering-Correlation-Id: 5c988534-49de-418e-a206-08dd8ed8bf90
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WE0xaVhGWUlDZnZUVXM1Z1lReHhTM29VMFFzdU1ZTTQ4M1psMFN1S1dRdnNK?=
 =?utf-8?B?OFcrMVJ1dGJ0UTdDdGJxOThVSU5ZWG1ZTVUyVHJtZmVKeHdQdzVQZzd6aFN0?=
 =?utf-8?B?VHBiMTVML08wMVZXVTMrWWdkZ1VZeDFaNG9Nai9lQU83dkFxd2RKNXdaOFFF?=
 =?utf-8?B?WWNSOGZzRmtVL1NNWUNJR1RQc3FhUDlIcFkwanJHY2h4enZNeS9XSDlaWE55?=
 =?utf-8?B?dFZyQ0MvaGwxU1NUK0tNb0xMYnlOcW9BVVZzRVlheUJuYy9EWkgzaE9YMmtL?=
 =?utf-8?B?bTNkTG1peFdTL3JyK2tXTkhMbWtoQ2NzWXZjUDd0US80YTdmakV3aVpqTjM3?=
 =?utf-8?B?OENVTFR4UHdBY0ZiRnBDaUtjcEFCK1kzLzBJY2tHOGgvZ0s5UmJzZTVtb2dr?=
 =?utf-8?B?YzJJZHkwbVZTbVNXb3A3WW84OUFSOXdxYlhWbmNXeWJNdnovL1U0S1VCY2Ey?=
 =?utf-8?B?eThCMWJjUFNITi83TzFuVFRGb0pGNU9nZ3BiOXR0aWpqQTdIQUVydEFZdU9O?=
 =?utf-8?B?ZXZ1MkxWM3BkZG5YTnZjOUVNeThxTDhOSjkyMzJNZEl6Vzk0eEhiYzJyLy8z?=
 =?utf-8?B?d25nbWcxTHJpYm54T25CY1BVRkQwdXQrdFhtRTIvTmUvRlZKWHhFeVlqajIx?=
 =?utf-8?B?YU5yNlpOYWhHWE5ZdklCUkVWY3ZhM1RqWVVtUTNoZ3Y4ZXIwbzYxV0hXS2ZM?=
 =?utf-8?B?SjJJcWd4NVI2YUM3cEk2dVphWjgxVVRkN3lEdWRrMk5ScFlWa0h2Uy85RFhx?=
 =?utf-8?B?Qk0zcWlFQVhVeUpIWHRHa1RtMS9MOFhlbDVBL2c5RVpqK1ZaTjBvSy9NNjNP?=
 =?utf-8?B?YUZzdzIzSkE4dHN2dWxHQ2pkeE1VM0JVWXZWbnNmcCszZjB6TFR2Ui94clNy?=
 =?utf-8?B?UnFWKzZ4QWFWQ056VHE2NVlqREIydkIyUDV1dkhNcmxrSkpMNXNQa3d4SjBl?=
 =?utf-8?B?VVNHZUFVdkJrQ1RiOW9yOHYwczBORjdETlUzM3N4T0xSSkM5WEVnMWFrNm5U?=
 =?utf-8?B?NEZleFc4cnd0TXBIcnNDd1BoK1NLOHRMdVlpSDlrS1I0bjFRUzcySVlHNDZh?=
 =?utf-8?B?Z3phTXl5QTkrQ24wSVNnblovYUNZaEpCdE1lTUpZbnFOb1ZwNDQ1ZEZlZkQv?=
 =?utf-8?B?WkFvWUdxaW4rS1pncHlRV2tYOVk1Q2s0K1ZCT1cyNFJJRUFMRXh1L041OEVC?=
 =?utf-8?B?bXlYeW5sRWp2a3JKaFlHckM3cUdTKytsckJteEluM1J2NXl2RWxnR1lSUnNT?=
 =?utf-8?B?YXIzMGUvL001a1BkK3FaMnJ3NmVVUFdwWTNDY2ljTm9GTlRYOEZhZGZUVXN4?=
 =?utf-8?B?VURYZm5ZU01iSHpNK0tPSHRaU0l3TTNLK3RlaFQ4UW83MlBkaFFDUHJNNUhL?=
 =?utf-8?B?aEhURE5nUVNXbUlYa1FQVDRvMXhRV2NPc3J1d2tpanFLVkU4Zlp2bE9HMEFu?=
 =?utf-8?B?R2dYYnRDb1FSUHBYMjdKai94MHFleVIvajh6RHVXYS84S2MwOGkyZVpEZzNo?=
 =?utf-8?B?U2NLQk1TVkdtK3phZlVwblUrMk0xRThkU0UvRVh2TDErYVdocGNneGJFVXIy?=
 =?utf-8?B?VDQxTVpFbUtqV1hvTVhHY2FqZnBKSjNOOWd0NE5oMnFVUDZscHA3T29ZbWpm?=
 =?utf-8?B?UTJUWmc1c09QWFZHRXUxM3RYbnZneEduMEJPbHJ0d3RWTUhFYS9SZXZmM1pF?=
 =?utf-8?B?eFBXajZld2h4SVFpN0Zjd0dPdnhyQlFmajVjVFVIclVFOFBJUkJZQzhFK1Z4?=
 =?utf-8?B?dHZEZUtlSDNuVXBQdW9pbzlRT3BjbHVZQThNWUlLazFsV0Q5V0dHNkNCUnZh?=
 =?utf-8?B?RDRyMUVNaWcyeTZHTStFaFNXbEl3TlBReXZvbU4xSnBMYk5hdVI5OXQ4NTNo?=
 =?utf-8?B?T01JNG1pU2VSU2owNVRiMjZaM0x5NGxKL1F2czdzUHN3M0MyK3RUejFLSW1X?=
 =?utf-8?B?VU5RMVc3cjZsTnIxczkrWjdQRVBndmhsRlljcWVLQjZYYnIyQ1VQbE45Nktl?=
 =?utf-8?B?NXhnek5xUzNON01hVmFhN1VFSmM2ekduRXBVM2IwY3VkcGthajNIUC95eHA2?=
 =?utf-8?Q?bgQ61C?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:06:13.3104
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c988534-49de-418e-a206-08dd8ed8bf90
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042A7.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8870

When init_rebar() fails, the previous new changes will hide Rebar
capability, it can't rely on vpci_deassign_device() to remove all
Rebar related registers anymore, those registers must be removed
in cleanup function of Rebar.

To do that, call vpci_remove_registers() to remove all possible
registered registers.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v3->v4 changes:
* Change function name from fini_rebar() to cleanup_rebar().
* Change the error number to be E2BIG and ENXIO in init_rebar().

v2->v3 changes:
* Use fini_rebar() to remove all register instead of in the failure path of init_rebar();

v1->v2 changes:
* Called vpci_remove_registers() to remove all possible registered registers instead of using a array to record all registered register.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/rebar.c | 35 ++++++++++++++++++++++++-----------
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
index 026f8f7972d9..d2d8a8915afb 100644
--- a/xen/drivers/vpci/rebar.c
+++ b/xen/drivers/vpci/rebar.c
@@ -49,6 +49,26 @@ static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
     bar->guest_addr = bar->addr;
 }
 
+static void cleanup_rebar(struct pci_dev *pdev)
+{
+    uint32_t ctrl;
+    unsigned int nbars;
+    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
+                                                        PCI_EXT_CAP_ID_REBAR);
+
+    if ( !rebar_offset || !is_hardware_domain(pdev->domain) )
+    {
+        ASSERT_UNREACHABLE();
+        return;
+    }
+
+    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
+    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
+
+    vpci_remove_registers(pdev->vpci, rebar_offset + PCI_REBAR_CAP(0),
+                          PCI_REBAR_CTRL(nbars - 1));
+}
+
 static int cf_check init_rebar(struct pci_dev *pdev)
 {
     uint32_t ctrl;
@@ -80,7 +100,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
         {
             printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
                    pdev->domain, &pdev->sbdf, index);
-            continue;
+            return -E2BIG;
         }
 
         bar = &pdev->vpci->header.bars[index];
@@ -88,7 +108,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
         {
             printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
                    pdev->domain, &pdev->sbdf, index);
-            continue;
+            return -ENXIO;
         }
 
         rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
@@ -97,14 +117,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
         {
             printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CTRL rc=%d\n",
                    pdev->domain, &pdev->sbdf, index, rc);
-            /*
-             * Ideally we would hide the ReBar capability on error, but code
-             * for doing so still needs to be written. Use continue instead
-             * to keep any already setup register hooks, as returning an
-             * error will cause the hardware domain to get unmediated access
-             * to all device registers.
-             */
-            continue;
+            return rc;
         }
 
         bar->resizable_sizes =
@@ -118,7 +131,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_EXTENDED_CAP(PCI_EXT_CAP_ID_REBAR, init_rebar, NULL);
+REGISTER_VPCI_EXTENDED_CAP(PCI_EXT_CAP_ID_REBAR, init_rebar, cleanup_rebar);
 
 /*
  * Local variables:
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 09:06:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:06:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979886.1366439 (Exim 4.92)
	(envelope-from )
	id 1uDJgU-0006XL-4f; Fri, 09 May 2025 09:06:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979886.1366439; Fri, 09 May 2025 09: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 1uDJgU-0006X4-01; Fri, 09 May 2025 09:06:22 +0000
Received: by outflank-mailman (input) for mailman id 979886;
 Fri, 09 May 2025 09:06:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJgS-0004kr-FB
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:06:20 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2412::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d738852e-2cb4-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 11:06:08 +0200 (CEST)
Received: from BYAPR02CA0010.namprd02.prod.outlook.com (2603:10b6:a02:ee::23)
 by SA0PR12MB4480.namprd12.prod.outlook.com (2603:10b6:806:99::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.32; Fri, 9 May
 2025 09:06:04 +0000
Received: from CO1PEPF000042AE.namprd03.prod.outlook.com
 (2603:10b6:a02:ee:cafe::1b) by BYAPR02CA0010.outlook.office365.com
 (2603:10b6:a02:ee::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.33 via Frontend Transport; Fri,
 9 May 2025 09:06:04 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042AE.mail.protection.outlook.com (10.167.243.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:06:03 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:06:00 -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" 
X-Inumbo-ID: d738852e-2cb4-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ARDYW6aXFnoa416ArgjiLP5vAS/RFfkU7+kGE9HDNEbMjyt6Dvjy++Bk18QgDxhVcqdJXWk2BeApCpWcNXs6OmqLZ16WA5i4wIzy/hkLrRbDs7aoYVUVrnpmYEfatfIFcfrmGzuxewAgCGV4S04ooQHXywYAD7iENTgGLPiduc8wZvkq3Px/y3HlYl6T9stgn99tSsY8pA7vMdrE/W/5fDVLUN/QSiybA4cIeXNVHxpcbmwMAi0AlHpdcgQjcdERf5vafPpNzYcwZqESOew2Hxgu4X5dA6lrc9+Y9YTitilvf6XWybk/lERnFdHlPrdr6Fjh5BpbngE1Ku60g0GHjQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bg+0e6v6ZFzpaKXGPFx7D1MKdC9fhdRzQ7vBrXA6o+k=;
 b=iHm/Cyg/vSD0p2No3l/+9bF5/dqEjVuRS4d2pyQpMsSdqAqPVrieMJjAIw7vmKisSuE6lckS1f1Hesoy0H7/rRZQUWW9TMUdQkgSX7pIUOK0hHgTVK8x0PbcWC0BYtsejzoJ3LtxeAnaVSFZJ33P3ENChu+HrlTmppcPH9ebfWYD5A3ZTObEomnmvqwebVQpZb2h/ushaIoQfsNb5A4CanF88lomqtw9InIZpjpt8Kq8UAaxX2t2T0a79VEfVk1pXDxQDTMvHlFLGEevgivoGtOrgMFsJwM928tU6GyqUmnLYImal4QDpTPXV+29wUSvCIwLq/JUBPxLOGB6E8q2DQ==
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=bg+0e6v6ZFzpaKXGPFx7D1MKdC9fhdRzQ7vBrXA6o+k=;
 b=xX8VQZ8n5MiRWWP6ss7Zf38oKM7ifFk38/IgAYC3VmZf64YCHNKm/hlpqNniVfhO9X9hsc8REZiPjJlmm2ZZitV9nsNp8N2BcnRZtK9JRgjbMlyUvum8iQfxk69iuTud7Fj7F0oLdWcdGiM6a4jNAWvCfnKc2PEI2lJazvO5q6A=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v4 02/10] vpci/header: Emulate legacy capability list for dom0
Date: Fri, 9 May 2025 17:05:34 +0800
Message-ID: <20250509090542.2199676-3-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AE:EE_|SA0PR12MB4480:EE_
X-MS-Office365-Filtering-Correlation-Id: bf61a3c4-18af-4595-ebd8-08dd8ed8b9ec
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OGpObmYzNzRLMndYZWp1NVRFZnRwTzdYV2tGWXNibDBJRVh0WloydDg5V0pU?=
 =?utf-8?B?Q0N2NTJUVFhDa0dMZksyODlLSjNPTGpCREZ4WjNBalpiUjI3MVNFZ1dCOGEy?=
 =?utf-8?B?cFBpR1dQMnFjVGNQS2dGV0NjbVBvb3AxZDdEUE9aUC8zdHpjWnIwRDZ4cWN1?=
 =?utf-8?B?YmtOcU84cFkvRlhTNmIyMHdFQTFRZGZzYzd4TTZBbnMwRmkrcWVMYXljZ1RC?=
 =?utf-8?B?L3ozU3I0am9HNXVqdmdhSXNTRFZDekJmYXA4cHphd2F5WTdRNnkzbzdPRW45?=
 =?utf-8?B?RDhPNE8vS0VmRVh4bENXalFxVmtJWmp1MllGYnFJR0luSVdyVkdnOFNMUE5p?=
 =?utf-8?B?eStoUFgvQkEvRExhN1JSNStQWXJtbGlPQ1c3NXdUejIzNm51Y2ovK1VRWGEr?=
 =?utf-8?B?cEtEWWlkNVd2RnBpQ3lTVFdjd0FBdTNYc1dCY0cvVkp1Nm1nRXpTeUt4WWY2?=
 =?utf-8?B?QWczWWVJd0JONy9kcVBrRUpkcVY5b25LUlRxeXF6ZGI5Yy9rMjRaOW1ubWlR?=
 =?utf-8?B?QXQyUFdJdFhwK1ZUazhoQTRmc2djcm1SZlMzSkRhQm9vOHF4Z2FqRWt5OEc1?=
 =?utf-8?B?SXZYcEt2VXFEVXRZSUlqOHAvdDJlekFrMUZBNkFLc2E0ZGdJbkljOVZ2WEh3?=
 =?utf-8?B?Qy9LcHlWeTA4NEx6REVYVUVXdWhWTnFoNDZ5T3BVOUNsREFZRmNWc3oyWkxT?=
 =?utf-8?B?TDl1N0F1OStFaUllOVNIeXpCNGN2cmlIR1JKSmxsTWUvUGRaUlFBbU1RRXB5?=
 =?utf-8?B?VTIwdGxpNlJSdkVYR0M2WWFDRms4T283cG5yNHVIdjkrQmxtQ3dNTHVrSVpY?=
 =?utf-8?B?b3hXdk92TFlKbjZWSmRMZEU3RzUyWWJLaFgvS285QUdVUW05SUVTTjYvOWFO?=
 =?utf-8?B?bUlLUlRaYzRzNk5zYWFHVnBYZXNpV1JzVkNvOUtzcFQxWmdXdmhQY09GQjg5?=
 =?utf-8?B?MURLVjFMdHIwUVM2RFU3WXZCL1F3UVRUUENpSGhCeEVhUVZmbjExOGJqS1pq?=
 =?utf-8?B?YkRKUWJJNzJTQWN1bUJTejlzSzRrYnE3RGdXMmNJQTJEQVNtZkpPS25UVlht?=
 =?utf-8?B?STBkNkd3Z3ZEaHgzTy9PaERmWmJaejE4VkZqWU0wK04wMldieURlZ3hVM3Qv?=
 =?utf-8?B?dUp6Y2ViTVcrMXlzOStxeExORTYvR1BSYU9SRVBOTGhLekgyZWo3Q2prbWt2?=
 =?utf-8?B?TXJ0cFNhRjY3T1pZcGE5ZENhd2pLVm1kakJ0RlN2N1VQVGVqTDVJQlgySUx3?=
 =?utf-8?B?U0ZLYVQ1bGFsL2lRdEtSay9qUkRaMDMwZlRNNzQ2aWsxUjl2aURIRVZPSjdT?=
 =?utf-8?B?YXg3YkdiRlJCZU5RWkV6UFU0WGFpdXJFMUw3T3dXUFlnVGFuNnNZeE5WZHBL?=
 =?utf-8?B?R3BZelVzK1hkQmpjdk1oaHlHVU9lQ2pSTnZWRGRRcTY0a2ZJOEpvWDlsRlVC?=
 =?utf-8?B?c0RTOTJ3N3NvVEUxZ0h0Z1MyODNvd1pDSDB1aVJSbi8rc2FmVFFYMlI3RWsr?=
 =?utf-8?B?WGRrR1lyd1JKeUtGdjVSdVhWQVZTcmZrUm5GN3V0T3JDUkhDVmZPNG50QVFK?=
 =?utf-8?B?ai8vR05sQ3VKajBJTVVmOCs2NW10aUJWajV1U0xIUWlHajFoSlpEV1h6clNH?=
 =?utf-8?B?MDBPK2RnbjhPQld3amltT1JuMUJvK25Lc3Bmc05wRVh3eUIwNXJLZks4SGhk?=
 =?utf-8?B?dEFKVXZmWUpWTkRINzEwNWIrQ09RMDh6dVB6NE0zVDFuTW5pMm5GbFVLQk9U?=
 =?utf-8?B?WkJOZmVSRFVWWVBXVXpSTzFFMmRBYVNmYUdZMkxWNkY2bTNLb0EyVHo0WnhD?=
 =?utf-8?B?bWkxUnlza0NMWlg4Nmc3U2pJZy94MWJCTzdjM1hlNVhzaEFKVUo3OExWZGdz?=
 =?utf-8?B?TTJrcDFzSnJXYkN2bHhvYVdCOFU0WkRETTdVUmpsazhZblU3L1NYYlFsM0lZ?=
 =?utf-8?B?akZLZWFaajBNNmJRV0NnWDZCTHVjTEYvMWlVM0doalMrME9ZWE9ybTlKN2F4?=
 =?utf-8?B?R2kzU2haVGFPYlF6OWdGdHNKM0JJUVBBbDlsd3VpY0JFOXA1aU8rckJEQ0s1?=
 =?utf-8?Q?cpYoFo?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:06:03.8493
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bf61a3c4-18af-4595-ebd8-08dd8ed8b9ec
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AE.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4480

Current logic of emulating legacy capability list is only for domU.
So, expand it to emulate for dom0 too. Then it will be easy to hide
a capability whose initialization fails in a function.

And restrict adding PCI_STATUS register only for domU since dom0
has no limitation to access that register.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v3->v4 changes:
* Also pass supported_caps to pci_find_next_cap_ttl() for dom0 since the n is zero when dom0,
  and add a comment to explain it.
* Restrict adding PCI_STATUS register only for domU since dom0 has no limitation to access that register.
* For dom0 register handler, set vpci_hw_write8 to it instead of NULL.

v2->v3 changes:
* Not to add handler of PCI_CAP_LIST_ID when domain is dom0.

v1->v2 changes:
new patch.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/header.c | 53 ++++++++++++++++++++++++---------------
 xen/drivers/vpci/vpci.c   |  6 +++++
 xen/include/xen/vpci.h    |  2 ++
 3 files changed, 41 insertions(+), 20 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 3e9b44454b43..a06c518c506c 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -749,9 +749,9 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
 {
     int rc;
     bool mask_cap_list = false;
+    bool is_hwdom = is_hardware_domain(pdev->domain);
 
-    if ( !is_hardware_domain(pdev->domain) &&
-         pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
+    if ( pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
     {
         /* Only expose capabilities to the guest that vPCI can handle. */
         unsigned int next, ttl = 48;
@@ -759,12 +759,18 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
             PCI_CAP_ID_MSI,
             PCI_CAP_ID_MSIX,
         };
+        /*
+         * For dom0, we should expose all capabilities instead of a fixed
+         * capabilities array, so setting n to 0 here is to get the next
+         * capability position directly in pci_find_next_cap_ttl.
+         */
+        const unsigned int n = is_hwdom ? 0 : ARRAY_SIZE(supported_caps);
 
         next = pci_find_next_cap_ttl(pdev->sbdf, PCI_CAPABILITY_LIST,
-                                     supported_caps,
-                                     ARRAY_SIZE(supported_caps), &ttl);
+                                     supported_caps, n, &ttl);
 
-        rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
+        rc = vpci_add_register(pdev->vpci, vpci_read_val,
+                               is_hwdom ? vpci_hw_write8 : NULL,
                                PCI_CAPABILITY_LIST, 1,
                                (void *)(uintptr_t)next);
         if ( rc )
@@ -772,7 +778,7 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
 
         next &= ~3;
 
-        if ( !next )
+        if ( !next && !is_hwdom )
             /*
              * If we don't have any supported capabilities to expose to the
              * guest, mask the PCI_STATUS_CAP_LIST bit in the status
@@ -786,15 +792,18 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
 
             next = pci_find_next_cap_ttl(pdev->sbdf,
                                          pos + PCI_CAP_LIST_NEXT,
-                                         supported_caps,
-                                         ARRAY_SIZE(supported_caps), &ttl);
+                                         supported_caps, n, &ttl);
 
-            rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
-                                   pos + PCI_CAP_LIST_ID, 1, NULL);
-            if ( rc )
-                return rc;
+            if ( !is_hwdom )
+            {
+                rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
+                                       pos + PCI_CAP_LIST_ID, 1, NULL);
+                if ( rc )
+                    return rc;
+            }
 
-            rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
+            rc = vpci_add_register(pdev->vpci, vpci_read_val,
+                                   is_hwdom ? vpci_hw_write8 : NULL,
                                    pos + PCI_CAP_LIST_NEXT, 1,
                                    (void *)(uintptr_t)next);
             if ( rc )
@@ -805,13 +814,17 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
     }
 
     /* Utilize rsvdp_mask to hide PCI_STATUS_CAP_LIST from the guest. */
-    return vpci_add_register_mask(pdev->vpci, vpci_hw_read16, vpci_hw_write16,
-                                  PCI_STATUS, 2, NULL,
-                                  PCI_STATUS_RO_MASK &
-                                    ~(mask_cap_list ? PCI_STATUS_CAP_LIST : 0),
-                                  PCI_STATUS_RW1C_MASK,
-                                  mask_cap_list ? PCI_STATUS_CAP_LIST : 0,
-                                  PCI_STATUS_RSVDZ_MASK);
+    return is_hwdom ? 0 : vpci_add_register_mask(pdev->vpci, vpci_hw_read16,
+                                                 vpci_hw_write16, PCI_STATUS,
+                                                 2, NULL,
+                                                 PCI_STATUS_RO_MASK &
+                                                    ~(mask_cap_list ?
+                                                        PCI_STATUS_CAP_LIST :
+                                                        0),
+                                                 PCI_STATUS_RW1C_MASK,
+                                                 mask_cap_list ?
+                                                    PCI_STATUS_CAP_LIST : 0,
+                                                 PCI_STATUS_RSVDZ_MASK);
 }
 
 static int cf_check init_header(struct pci_dev *pdev)
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 1e6aa5d799b9..cf3326a966d0 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -226,6 +226,12 @@ uint32_t cf_check vpci_hw_read32(
     return pci_conf_read32(pdev->sbdf, reg);
 }
 
+void cf_check vpci_hw_write8(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
+{
+    pci_conf_write8(pdev->sbdf, reg, val);
+}
+
 void cf_check vpci_hw_write16(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
 {
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 475981cb8155..fc8d5b470b0b 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -76,6 +76,8 @@ uint32_t cf_check vpci_hw_read16(
     const struct pci_dev *pdev, unsigned int reg, void *data);
 uint32_t cf_check vpci_hw_read32(
     const struct pci_dev *pdev, unsigned int reg, void *data);
+void cf_check vpci_hw_write8(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 void cf_check vpci_hw_write16(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 09:06:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:06:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979887.1366443 (Exim 4.92)
	(envelope-from )
	id 1uDJgU-0006b4-Il; Fri, 09 May 2025 09:06:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979887.1366443; Fri, 09 May 2025 09: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 1uDJgU-0006a2-Cl; Fri, 09 May 2025 09:06:22 +0000
Received: by outflank-mailman (input) for mailman id 979887;
 Fri, 09 May 2025 09:06:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJgS-0005aH-Lz
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:06:20 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on2062a.outbound.protection.outlook.com
 [2a01:111:f403:240a::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d5e34582-2cb4-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 11:06:06 +0200 (CEST)
Received: from BYAPR02CA0015.namprd02.prod.outlook.com (2603:10b6:a02:ee::28)
 by DS7PR12MB9475.namprd12.prod.outlook.com (2603:10b6:8:251::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.21; Fri, 9 May
 2025 09:06:00 +0000
Received: from CO1PEPF000042AE.namprd03.prod.outlook.com
 (2603:10b6:a02:ee:cafe::cc) by BYAPR02CA0015.outlook.office365.com
 (2603:10b6:a02:ee::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.32 via Frontend Transport; Fri,
 9 May 2025 09:05:59 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042AE.mail.protection.outlook.com (10.167.243.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:05:59 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:05: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" 
X-Inumbo-ID: d5e34582-2cb4-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WQZ0WGYD0WxXwDNaRj840xpbhaIkI1gREaxBetFfQk55HTFIlX2xZyRfB2iwd/zmLRhwXLfD+OLLHyAKKCZHosSyEtu6D7rewiAq8hEMLIyM0T0Q5xR0Zg7oR+f8ZdnV0AYCu8AkrZKxCm6qfe9O00Xk8FEx2ZmFhs5VL3ulh7doabPeCnEzZ/kKbhTmdMvVVA7MwoNkqkW4H0NLKyBPp75GKC0BL+cPQrFKSUnx/N0pgAE0ry3qw3STGsEKC3sx0QNb2qYe9IY8gWKikUu4A70WwhH+0qLqoHiro12//DNziIOZZ3zOrnt53/IOCOmbVsZhphIZXQZQUpOldhqIJw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IKEZfc0Hl5KutLU/QCUMGLc/60ikEPSZNHL0u43mgsU=;
 b=sL6xfL8If+Ov/jERbEpSiH8a++LNqKVOLFnYCHDNZfrx0dPtvAxVXYocNZdLKMGHvrOeoxnNLKfvaSrXO9/S9BbMJE6b3tmGTqS5rTdmNC0eWgNOYhvIHbZL5fQM7fnBWOf1o7ZV3dcERihQEQx9f9/v6GEjt6/4ZfzUHVoozVAL2Zft21O0ZLL5VUpC0cetzz59qSg04zqaB8ntucaoxt0Qrhx7j6ZhW8dRW7GM0mF9ROD62MjzHYK3bnoIC4nsNsWG82Y2o5+UAjBMpxbm5LwMLtdQOOpU28ZD+KCLyADrRpkpqLx15jFtjEQUrns30aP+bvIYC17qNGat67edBQ==
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=IKEZfc0Hl5KutLU/QCUMGLc/60ikEPSZNHL0u43mgsU=;
 b=vbt2tC3oEEs6ySEkTR1KTHRDjsbzXJf6fF5H4saVoYFmLYsgayyJd53AvmiiZi1sx0QCU/upwmKm820Hkkqo5EexvRMpqVILoEJgA6113vNTKCTqZGqjBKT2GQQTdcUWef3nnrRzyv0q28cTAvn0VihHaiQJ7e504WcAeBEwivs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen , "Andrew
 Cooper" , Anthony PERARD
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" 
Subject: [PATCH v4 00/10] Support hiding capability when its initialization fails
Date: Fri, 9 May 2025 17:05:32 +0800
Message-ID: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AE:EE_|DS7PR12MB9475:EE_
X-MS-Office365-Filtering-Correlation-Id: 24f593ca-0d79-4a60-fac4-08dd8ed8b709
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VHVWdGJERTQ1VG5lRlhQVGV4dDFjRUVhTlBMOVBMV0JwM1N2Mk0rUnRWNzkv?=
 =?utf-8?B?M2pXOU9Rb2JIZFRFN0xiOVRmcnR3MzhzQjYvaHhSNzB5YXlobWdNbkRIVnRF?=
 =?utf-8?B?RVpFeSttMlBNR1B5cVFjREhvdHNZNjNRZEpGQ0JRQUtMYUtFSGNyQTNjVlFq?=
 =?utf-8?B?dFNpM0tPYVdiVThZNUlZTnorQWdOaisxTWZ6TVh0VzRnUUJFZmV6cXJWdm9K?=
 =?utf-8?B?OXMzTkE0bVAyaHVpM3NMRlo4Y2NEaEZzZFUwT1dCV1dJb25KQ1hXTk10TlVm?=
 =?utf-8?B?eFcxeUxWTzNvaWc1c0hMZ1ZYM1FINUJLVjhBNnovNUdHTWJGQWN5SUY2T0ZJ?=
 =?utf-8?B?SDArQnhncWc0ZTIwaHBCTWZ3bUxoSWpZTkx0TUFCWEFvbzNMZk5IdUNxSkFP?=
 =?utf-8?B?bnZjU1NxN0s0eTRPQTd2UXFFc2FXNWhZbmJjZE1RY0FVcjEwdmlmL1dVTTJT?=
 =?utf-8?B?OEFZQXA1OURjWFIyWGdhSGx2SStleWFZcFUrV3puNDVtUllaTzdSV0FNdFg4?=
 =?utf-8?B?MERWbVU2SFR0d2tNNUlibjR0dHNzK0d1dndOUWFYNHBpUFg3Q2FxNWNMcVVZ?=
 =?utf-8?B?djFQT1pVL3pOS0tZTUNaek0zaHdtWXZOR0M0Q2tIUnBRbWNaQ2twVkNINEVv?=
 =?utf-8?B?VHlZODNqL1JtQXlJR1M5cW9vVVJHaFlVV0NJeFpKbDJieTVNMmJRWjZSY3hk?=
 =?utf-8?B?dEZGYmcxZkdoM3gxK0RlZGpkTTlhMUE1dGkrT0pBbUIxbjNXOVcxVTU1ZzFD?=
 =?utf-8?B?eFRhSmJwc0lpb0NwUStCZGVCUG5ITlhaTXg0bTlJS1h4UzRkSEFuS3BYRU8r?=
 =?utf-8?B?Y2tqYzVQekFhZkNreFVqZlh5Z3JGS0tHaEhPMzF3clVjbEFDeDdSVFlrMEF4?=
 =?utf-8?B?d1RWVUw0WnpydTdzUzJURkxpRGNlNEhmekFuQmsreXo2NzE4OGs3V25hcDFX?=
 =?utf-8?B?MFV0WmNJWHNweVdhMHFid3EvR2pTczNyd1VrdXkvbmdST09lcjhrR1ZncjU3?=
 =?utf-8?B?RWpjdUErUjFqdVlwUW9OSVBPeXEya0pwK2thS1IvTjEyWjNqdW9LQlJYQ2tG?=
 =?utf-8?B?cDFNKzhBNE1IYmdQNzEySXEzTEVmL1JvUzhkcTQ0WWtkNVA0OGQrbS8wNkNE?=
 =?utf-8?B?VjFNcWg5dTEreUZhZ0pIR3RDWTFXNndFNEs0bzk4UnRKZjI5cm52T3I3SEVU?=
 =?utf-8?B?SDlSTklWQUFFNkJwMmdSV3FvK1lZTHB5WVVpZ1ArZ1FLVmRWdDU3OHZEbjdL?=
 =?utf-8?B?RWc4WFlpYmJhRXR4MjFEZm4vY3BPUHh2NUx0QW5yZm93Q3JsRkVvKy9PTXRz?=
 =?utf-8?B?b2UvWXVoR21vZVU3ZERPWW9ET0V2bFU2MXd5Z2ZYNXM0MERqNkVrYytVZU04?=
 =?utf-8?B?NkVYZnpJalhjZDdCcXd1QUxORHNOR2p4cUI5dXJZWTIvWkFCWERmZGlPak5E?=
 =?utf-8?B?Q0d1SUtCemNiMloyYnVjcjVOcHNoVjRCRGpRZ2FGa1pNdkJWYjNxVFN5QUc2?=
 =?utf-8?B?eGxEc2Z3YVVDL1RXNXlTYU9pVmFaUFoyY0pUMlhjZmJwWk5HekFUdmZuTXlH?=
 =?utf-8?B?b3paL3JuOTM0SnVXaGZVTDdXMWdYazA5QmFpUXg4WnJaSDJodlBBUWxBcW41?=
 =?utf-8?B?WmhNQW1FdWZlTW03bUJYaGxTNE1CRGRpMXpJVnd2UUQxKzJ1UlgvcFo0KzQ3?=
 =?utf-8?B?d3JRTUw3QnJvSGlaS21VaVIyUHR6R2l6Q3VzSnRudHpiVjZ5cWhjeGd3MGdt?=
 =?utf-8?B?Zk9kUGh0SlcwR0hFY1o2VGRHYjJBWW1YYlgwZ0lJSXFCdmVXYXdTN09pL3JS?=
 =?utf-8?B?Q0I2RE5TaThKV3hlT2JlS1ZqZ3Nocm1KRFQzaG9ZSWlxV08wYnhjMjZqaDds?=
 =?utf-8?B?ZFYzSm1ubi83b1F0cklaOVJnYzRIMzFBSUhDZXlCWDB3dTY0ZmttQ3I4YlFl?=
 =?utf-8?B?bEJaWkJkSnFXZWlqMk1DcE5QdHlpdWsrNWgrRmVZWE1URm50bURWNkEwc2tP?=
 =?utf-8?B?UG1JOTU3L2YwNEZnd3U0YVFQZlFEU21LcjMzSkxlOGhwaitITmRSK1p6OHBG?=
 =?utf-8?Q?kVxfrf?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:05:59.0054
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 24f593ca-0d79-4a60-fac4-08dd8ed8b709
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AE.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB9475

Hi,

This series is to
emulate legacy and extended capability list for dom0, including patch #1, #2, #3.
hide legacy and extended capability when its initialization fails, including patch #4, #5, #6.
remove all related registers and other resources when initializing capability fails, including patch #7, #8, #9, #10.

Best regards,
Jiqian Chen.
---
cc: Andrew Cooper 
cc: Anthony PERARD 
cc: Michal Orzel 
cc: Jan Beulich 
cc: Julien Grall 
cc: "Roger Pau Monné" 
cc: Stefano Stabellini 
---
Jiqian Chen (10):
  vpci/header: Move emulating cap list logic into new function
  vpci/header: Emulate legacy capability list for dom0
  vpci/header: Emulate extended capability list for dom0
  vpci: Refactor REGISTER_VPCI_INIT
  vpci: Hide legacy capability when it fails to initialize
  vpci: Hide extended capability when it fails to initialize
  vpci: Refactor vpci_remove_register to remove matched registers
  vpci/rebar: Remove registers when init_rebar() fails
  vpci/msi: Free MSI resources when init_msi() fails
  vpci/msix: Add function to clean MSIX resources

 tools/tests/vpci/main.c    |   4 +-
 xen/drivers/vpci/header.c  | 187 +++++++++++++--------
 xen/drivers/vpci/msi.c     |  22 ++-
 xen/drivers/vpci/msix.c    |  29 +++-
 xen/drivers/vpci/rebar.c   |  35 ++--
 xen/drivers/vpci/vpci.c    | 325 ++++++++++++++++++++++++++++++++-----
 xen/include/xen/pci_regs.h |   5 +-
 xen/include/xen/vpci.h     |  38 +++--
 xen/include/xen/xen.lds.h  |   2 +-
 9 files changed, 505 insertions(+), 142 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 09:06:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:06:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979888.1366449 (Exim 4.92)
	(envelope-from )
	id 1uDJgV-0006gj-6z; Fri, 09 May 2025 09:06:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979888.1366449; Fri, 09 May 2025 09:06: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 1uDJgU-0006fO-R3; Fri, 09 May 2025 09:06:22 +0000
Received: by outflank-mailman (input) for mailman id 979888;
 Fri, 09 May 2025 09:06:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJgS-0005aH-Sv
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:06:20 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20613.outbound.protection.outlook.com
 [2a01:111:f403:2414::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id deaa7858-2cb4-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 11:06:19 +0200 (CEST)
Received: from BYAPR05CA0022.namprd05.prod.outlook.com (2603:10b6:a03:c0::35)
 by DS0PR12MB8527.namprd12.prod.outlook.com (2603:10b6:8:161::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.21; Fri, 9 May
 2025 09:06:15 +0000
Received: from CO1PEPF000042A7.namprd03.prod.outlook.com
 (2603:10b6:a03:c0:cafe::10) by BYAPR05CA0022.outlook.office365.com
 (2603:10b6:a03:c0::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.19 via Frontend Transport; Fri,
 9 May 2025 09:06:14 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042A7.mail.protection.outlook.com (10.167.243.36) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:06:14 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:06: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" 
X-Inumbo-ID: deaa7858-2cb4-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Lh9ZlZWDKHfC9LpTCSW+OPzOb2Q11dOXwdRBlLM+jPI0JLibYy7Su0snmS5BfKUNKPt+eMquqrd+OJaNUYTpHTPJwu7krrLJQO7aX+zGEUQekfJA0Rnem+KwXdY9n+0X6PPyFcxDoDttrgnRdxMiAAL36UwTO7197D97+YRNNmT8STxVi1/xHJQIB4aRRllg63ivRNmRvK+6uXNCu4XAznY+ISnl0lnp2EMk0rHZHsvvIoASCd13aXZlGQf1HCn76Nv+77kR8dNlYA064Pm6UcpRdm0PzaFtN1JUhQcRsUxRRoES5OZ+0RWGOPSNfhP6AFpdi6FAnoMM1U0jQRdZCg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5q/P05OCr3LuuJ/sC5ThFqMV3Dv4cNcqJlZkmAW4d8w=;
 b=CBTvCPuYXStqtB5Vmok/lI0xKSL3OtMwcb5v5CNXxM18Q7VD8qbBXhNl+Fwdl9IDC6wNNKaq0e41g7Otd1qyOyyiT1J4irrNq8q6hlP4EI6wKDoFf3NDGR1WH2WLIDbIJ1Ffzqv/Qyl6PhW5vapU+cSmBKZIsoM41NzAfKVcVfn05+A7Yi+qVUee8IquYQRFyX3sPtpwtuEYhktZhCmQHyhRLfgYPbPS+FSB8/cP21NIxx3DRQ87ixhmEqSYCXIohcIkUrWnIckUg9zsZaY7OFqNjy9Terh0mUpvoo/TyB6KLXwcSh7zNfub0Px7cjiRxoEfMqt34dTRIm6ttHyoJw==
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=5q/P05OCr3LuuJ/sC5ThFqMV3Dv4cNcqJlZkmAW4d8w=;
 b=fBTa/e2ksRxctYAXnnBbt1v9IlzzPuABgVROkpQwpPxJSR0/KcoUpgyI2Hf6LLp6pU4PEPatlS21uBHzG8hrLgy+0yufdP+Lay4f3u2Br3b/d0jNQRbynguOnjCdRh1SY5fiStpqo8cOMxHBV2ajnIVhCDytVTwSCjxUbFmrB74=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi() fails
Date: Fri, 9 May 2025 17:05:41 +0800
Message-ID: <20250509090542.2199676-10-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042A7:EE_|DS0PR12MB8527:EE_
X-MS-Office365-Filtering-Correlation-Id: 6dfc291c-ed67-4f51-54fc-08dd8ed8c06b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UnJuV0d2eFQ1U0hUbmNUdUtONHp0QTUzWmRSeWRTUFJESWtVTU96NDVxVGhs?=
 =?utf-8?B?UGJKUVZOVVE1VUhqL0Z0SnJiS2JIVnh2UGxsTTBGTjVvSDZ5eVpGU1kvOUJh?=
 =?utf-8?B?NytPWGxFTVVjU3IzOVVKNnRnQjdWNmZCd1BZcXNLZFRBZUtCQmlyVDMyZEll?=
 =?utf-8?B?RWFrNTY2ZnRnMHdoNUFLQ2dhNW91SmswcGQyakh2SUtZQTFIZHRYMVMrN2o3?=
 =?utf-8?B?Q1JodncyUmVOZ042cmdRNkxwczlvZEZFcEQ5NDlJRkE0WWsvcURLOUE3NHNO?=
 =?utf-8?B?VFJRbDRDbWZYWlhTTmovcGNKNGhncitPSUU4NXVOWkJzZjY1K0xOWGpDclY0?=
 =?utf-8?B?anhFYXBJZU9udnBYdlY1RkJvTHJSSzRwMHVlalQvdTFRcHJsdlVub3NzRngv?=
 =?utf-8?B?U0RnM0NoSGlaNUkvdWQrd2d4cjh4S1N0RTlicHF3OTZEVVd6OUEyaHlTdHJp?=
 =?utf-8?B?TEpQSEpHeTAxc3ZyZUIzczEwMVJEandNNW5rMC9iM2NtV2FGUHhEbDZxV2JT?=
 =?utf-8?B?S1RmYjE4VDBIOGJiUXFxOWVLOXhWRDJjTHZaU1QxSkdWQ0NaRHZFd0lUNVZK?=
 =?utf-8?B?WEd0QlBYc1d0ZXhyeVBJSUF0R1lGRzB3STJJYmxVSkt1OVFTS09jZW9QaXpQ?=
 =?utf-8?B?YWN6MC9RWU13M0ZmT2RxUmMzYWtqUlBNUUhZWmtkUXRnREhpdm1rQ2lzeEgx?=
 =?utf-8?B?R0MrM1NSb2pyT0RkZWh0SkVpNVBnSnlLTFVrSmRYbDBvQnl2NEVBNCtXVitL?=
 =?utf-8?B?ZjZ2bnQ2cW9mV3NOM0pxZlp5YlprRkZ6WGh0UnFXOWo3SkdPNzlHb3VyWExX?=
 =?utf-8?B?Z05GQzNqbDc4cXlkZU9uY1dvUiswZkJBQWdhZXlzUDZORzB4bjJVQ1I3QmZ3?=
 =?utf-8?B?SFMzeE5ZRFdQWE12YXJEbDNscHBNOGh1NjR0QWJGZHh6cTFlS3hobUJCdS85?=
 =?utf-8?B?WFNoc2JlN2ZvVHM0R1Q0NUtzWGU5ZTdJV1FtZVhzZkRER25BSlVtMCt1eitL?=
 =?utf-8?B?WE9tV0s4YVlXMEhtblpVeFdqcWhmNG5UdW1Ca0dxL3dVU1BIbDNmd3pONGFt?=
 =?utf-8?B?U25CRmVRbGcxRXhEemY2UXUzTlRzM1ZuZVNnV0lIS2h4dGI0R3ZKSVBYdzhG?=
 =?utf-8?B?K3pTaXFlY2NnVTJVdkJIVzZGZEEyMEZ5VjhQQlVHZVdwMHhVcUVXUngyU1hK?=
 =?utf-8?B?RmtKZm9HZm9KSDF0VzFvNVY5YW9wNDhNMWgvMlZ3eEw0dWc4WDBPWFhYWW54?=
 =?utf-8?B?bGNJVXBNQmN3UHFJb0t4MFFDcWhBRjdreTVGQzAva2ZWb2w5aCtIaGl0dGJn?=
 =?utf-8?B?TE9XU0JoMTRtUmxHKzVJMzBvVzAyWWgrYzhHL3Ftc01WeCsvVTFFekp2SGpD?=
 =?utf-8?B?Nm4yc2pibW9iWXBtZEl4MjdvMHZTTkRpVzN1aXdQSEtHcU5yZVJkSlhPRHcx?=
 =?utf-8?B?NmxvTzloenk1Yks1M0lvN0UvOUVNSXVJTXg1VExZRVJVTnVmN2ovdzNVY21Q?=
 =?utf-8?B?V29DZlI0dXUxN2M3dGlXMGpUd3RtaUIyYUFaZGdFK25MWVJuazhObmJ4dTlP?=
 =?utf-8?B?ZHpYcUREWHAzZzRGaWhBd1BPYUVZRmVURWZ0WGNJUXAxaWk2cThGQTMwK0ts?=
 =?utf-8?B?WDhzNVdYVURTeE1FNTBSa3l2NDNLcFNVSGJGazhCSGpBa0tSSHhQR1puMHpX?=
 =?utf-8?B?Q0lyYXNCVXJjSzN3ODdvQVg4UWJVZlRGZWwwSGJFaUdZQkVoekFNWUVDanBW?=
 =?utf-8?B?RW9yOVlVcFBUZDJsVkR5OVU3NXNFSlZKMmVSTnpsQ1prdjd4MDRrVEdibXdz?=
 =?utf-8?B?bnR1YkRVTGc2VzVsVUtYamZWMHZ5cElnVFZwVWNrWURycFNFMEN5MmdRMDNp?=
 =?utf-8?B?ZlNwWWVWVGpBb0RabnUvOFBZRUhKMkZDLzhBSUFwRVgvaC9qOTNSZWc4bE56?=
 =?utf-8?B?SzRLSHY2VnBiNnVTL2tnREliaTFsd1diOHJBbUZDS29zbEF2a3ZqUVVjVlNC?=
 =?utf-8?B?WU95VHkrb1NqbjdVcUhDSThLWFg1V2ZxSFVvZWEweFNTa28wclVmZGt2dzFE?=
 =?utf-8?Q?6vk3cb?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:06:14.7440
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6dfc291c-ed67-4f51-54fc-08dd8ed8c06b
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042A7.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8527

When init_msi() fails, the previous new changes will hide MSI
capability, it can't rely on vpci_deassign_device() to remove
all MSI related resources anymore, those resources must be
removed in cleanup function of MSI.

To do that, add a new function to free MSI resources.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v3->v4 changes:
* Change function name from fini_msi() to cleanup_msi().
* Remove unnecessary comment.
* Change to use XFREE to free vpci->msi.

v2->v3 changes:
* Remove all fail path, and use fini_msi() hook instead.
* Change the method to calculating the size of msi registers.

v1->v2 changes:
* Added a new function fini_msi to free all MSI resources instead of using an array to record registered registers.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/msi.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index ea7dc0c060ea..306da49bd3ec 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -193,6 +193,26 @@ static void cf_check mask_write(
     msi->mask = val;
 }
 
+static void cleanup_msi(struct pci_dev *pdev)
+{
+    unsigned int end, size;
+    struct vpci *vpci = pdev->vpci;
+    const unsigned int msi_pos = pdev->msi_pos;
+
+    if ( !msi_pos || !vpci->msi )
+        return;
+
+    if ( vpci->msi->masking )
+        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
+    else
+        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
+
+    size = end - msi_control_reg(msi_pos);
+
+    vpci_remove_registers(vpci, msi_control_reg(msi_pos), size);
+    XFREE(vpci->msi);
+}
+
 static int cf_check init_msi(struct pci_dev *pdev)
 {
     unsigned int pos = pdev->msi_pos;
@@ -270,7 +290,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSI, init_msi, NULL);
+REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSI, init_msi, cleanup_msi);
 
 void vpci_dump_msi(void)
 {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 09:06:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:06:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979892.1366468 (Exim 4.92)
	(envelope-from )
	id 1uDJgX-0007R4-Su; Fri, 09 May 2025 09:06:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979892.1366468; Fri, 09 May 2025 09:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDJgX-0007QZ-Ob; Fri, 09 May 2025 09:06:25 +0000
Received: by outflank-mailman (input) for mailman id 979892;
 Fri, 09 May 2025 09:06:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDJgV-0005aH-W4
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:06:23 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2412::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dfd2aba2-2cb4-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 11:06:22 +0200 (CEST)
Received: from BYAPR07CA0079.namprd07.prod.outlook.com (2603:10b6:a03:12b::20)
 by SA5PPF530AE3851.namprd12.prod.outlook.com
 (2603:10b6:80f:fc04::8c9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8655.36; Fri, 9 May
 2025 09:06:17 +0000
Received: from CO1PEPF000042A8.namprd03.prod.outlook.com
 (2603:10b6:a03:12b:cafe::6e) by BYAPR07CA0079.outlook.office365.com
 (2603:10b6:a03:12b::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.29 via Frontend Transport; Fri,
 9 May 2025 09:06:17 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042A8.mail.protection.outlook.com (10.167.243.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:06:16 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:06: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" 
X-Inumbo-ID: dfd2aba2-2cb4-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hDEZQJj+tsXW/ncUe5HsNHj3twmqoXXT0cIj2NTcXMJaWRuidIK8dB86GTT2sdxJj+ez/iAJB5CW3rM/xw+jc7lsgdhjXmcxFM1AaePk0ujq71K7d6TLwJw+1qv2ZUby3mcPUbQLRd95gprZhOl7VVGoLBU7f6khFyeExMXoPjJ+xpF306ouVR3NvCDtG6LKzsEDTDl23Lho+Leiqf0nx8OcakmQ2BARiR7E5N/yOpKdqtJCnq7jdfV7zWQT5feRBSUAJOvbH8M7fI8qpdjycMT1XWE/LdLAKvJ/neFWVjdI8lPwiV0FuNrZ/3Ok3bsbt6gD95iOkrbBe9uMWQJWtw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jxsqy2OG0XoDfK1Z06/jOcTFbFyd2+TnRkp4DczGZ1o=;
 b=RJwvhocb+CJoTK+jqShcwdh9I5itTKTXvawclxBKTcvj8n0tJA0FvFuk6pdHXAOgjCEQjJubJJIe0jGG9NiQGjL7F6LszXBwoWsxuqHDx5cWUKFO76FkDJSVe0zgsUamvsWhYlOZz76yAV32oOIQN2+Pc8g8YW727EJVvpcn3BOdqM6bOe3E5EocHC0WLnBiLbG1xBsiV+aTK2N51xNmXkfqYFMvACWEoAZb17EUtSvHmJ7lMpZj86cGa+Hq9aHoKVxu7ImGVrh/IFUPUScyLIfk7PQ6pbicIGa4ZnI+UuMAkR3hwIy6AMP3DT6tzzEgjBUAvhgDNVU8V9rc+VvUfw==
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=jxsqy2OG0XoDfK1Z06/jOcTFbFyd2+TnRkp4DczGZ1o=;
 b=AUSN+vmdriWxn8E/dWGHTwx7yY+VOvE7mXY4jd+35jBLGIXqRYmaMga+0jxB3z6eofZUDLo+y51vz/mbB4cSbGWf7xGG1m9BOcNaJ2FgR8F+Z8WDEBkv1csmuTRg34GX3tA47+uHuzi/XJ7D3LB6PUACATzjx1mxdYDdNi9n4M8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v4 10/10] vpci/msix: Add function to clean MSIX resources
Date: Fri, 9 May 2025 17:05:42 +0800
Message-ID: <20250509090542.2199676-11-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042A8:EE_|SA5PPF530AE3851:EE_
X-MS-Office365-Filtering-Correlation-Id: b9274c70-b773-46f3-0c79-08dd8ed8c171
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZENSK1pYTnVBbWlZVXJyS2RheTVOVm53T2d2ZE9Ob1UzbUJ1ZHB2VTUwejVV?=
 =?utf-8?B?dFRwSW9ISkdNTFZFM2djL0QxYmtzNWdLek1KaEtiZE15MHNmUWN3dEFMTTJ0?=
 =?utf-8?B?NjhmVElhK1lEazhnZXhkbmRSS1JlT1c3enZoS2ZiWWhKL29MQlY1bXh1OUc3?=
 =?utf-8?B?L1ptT0lNOUQwa2V6TkMvUitBRXgrK1pqQkdyYktqRitnei9wdnJZZGFubGZL?=
 =?utf-8?B?dXpLc1FEQUNSOXFVSVN3VzF2dHJPY2lEOGt6UVlJN3JjZ2x2anV4MkZaajJ4?=
 =?utf-8?B?QWt3akhKWjErSnIvcnlyT0lzeGtqNk01bVZmQlZDaWJnTGRBdUVCYWdOZ1Z0?=
 =?utf-8?B?WW5xcWQrVUpPajB0RHg4K0xmVksrbmVqTWhCSzRGZkRtTFh1L01GbHptejAw?=
 =?utf-8?B?bGU3T1lVbzVWNVQ1T2h3NEZyUkpDejJBdG9zSnQzWVcvYm9vUDVYUjBYV2NI?=
 =?utf-8?B?eHNiSlFsSllBTVhnRzFkdmlNazJMRXhsZUlpR2lNeDRsVDBSM0VEenc2TFdD?=
 =?utf-8?B?a3Y0VWdTelBUL3lCTGtmelBISVFrdmRqZnFvNUxUeGgwZlZWdGUrdEY1QmxQ?=
 =?utf-8?B?VUZLREtTSnozYklkQTFNMUhSVmJoTlF2TEZxUHNYNlRCZVdSendmVi8wUXor?=
 =?utf-8?B?anZIMFFpSlVqU2ZIU29FSkxLYVZxMGloZTg0ZGxCVTg1MHdTQ0FOTTJXYlFM?=
 =?utf-8?B?MFpsSmY2NS9QaWFtVjE1Z2FmMHRKMWVkdXY1NG90elB5WE05VFBmcHBqTlBH?=
 =?utf-8?B?VTNYS1pUUjdZcFVFNURtSUlwMzNrc0szejhlZGVkUlpHS0ltTklpeVRQekdB?=
 =?utf-8?B?OUt1QklDUHB5WU9FOWhoZUFjL0wrMlZoK3JacTByVmpwN2taZ0tHRUFoVnpE?=
 =?utf-8?B?L042bUw5SHVSYUF4SjRZQ0luU2x6RXlQbUFEMFVvQTYwR0dPWGUvU216UTVy?=
 =?utf-8?B?amhma2xleHQwZytVeXRndXZCaG5pdmxuL0RpcC9RVEZmcTV5QUttMnVDUk5G?=
 =?utf-8?B?UDNkRUNYcnpMUWpjYjViaVVrRFZTdzlFRktVcmNSajFqVEFoQjhHM1h6U3VR?=
 =?utf-8?B?aXJjNkFubG9KbVI5eWp3cDAya293eU5aTGFlRjBXZC9lSFg4QlZXb1E1ZU9p?=
 =?utf-8?B?bmpqSW8zZFgxVlFmUXZHZFRIaklsZmRPNWNSUUlVN2hub0JqU0ZZVjQxNnNP?=
 =?utf-8?B?M1ZxR2tTdTFVdGYxenJNMFEvcDVWNk52ZE5TZTZONnppQ2k3aUF1WDhkQ0JZ?=
 =?utf-8?B?Uy9qYnEzK0JiV1MwS080V3grVGtFdGNxZjFwRmdJSkF3NFY5eXUxRHNqNWU1?=
 =?utf-8?B?b1MzZmlFR0RrcUtvYXp4QUFGSVg1SUo0K0xmdnhITm1ncXBidGMrQlN2YjRD?=
 =?utf-8?B?SjdMeEhidUFXVGh4bDNRUW91dXFLTTdvQ1FDRVI1bW0zRXZuSnYzMTc3Rld5?=
 =?utf-8?B?OTNXeXZidlNzSkV1dXhuT3pzaE5xaXppS1R3TlhySEM3UGxnUWtBYytPcXY3?=
 =?utf-8?B?ZjVnYThoeXhUVkJRUjVzdjBtZGk3TUZGTjFHQkxhS0M1cE9MVmZhUXRwejRM?=
 =?utf-8?B?c1M1WVdxczJ5NCtoZDFyejNtaGgrUEpTQTh6TXNEUDVkRE1SSVJoNkU5TEl0?=
 =?utf-8?B?RVh2YTZ5SFdjcC9YTDIyb1pmZHVxQm5pa0pOSWk5THpFZmpEMHNOaGdyQXhT?=
 =?utf-8?B?cHREWWlNSFZpemM0RnI5di9iNWdPYlZWQkdESUNyK0V4RXd3SnVxemVjUmdB?=
 =?utf-8?B?eVF6c0them9NaWNjUG9SdjY2OTlTS0xTbEovdEU4Y1FvQjZOTDMrakNzaDVP?=
 =?utf-8?B?QndqQWs1eXVWQkhkd2Z3NUpLUzRJTitxU2lvb2huczNvYjlWajlRcVd0U0pW?=
 =?utf-8?B?dFoxdlRzOUV3M2FPYmNaa2NNZU03SDV6aVhaNlRhcjBIM29GY0xtUlFqVlNk?=
 =?utf-8?B?NVY5cVdwRDVzTkJzMHB5VmZQdUlMNUZxUFVYVzFwUWdUVis1aWY2NlVpbU5j?=
 =?utf-8?B?SWZrZ3V6bkh2QW9vQjhUSG41TldLVE1nTlI0di9mVHl5Vm8vS2dIaytmbUtm?=
 =?utf-8?Q?v1pu03?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:06:16.4579
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b9274c70-b773-46f3-0c79-08dd8ed8c171
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042A8.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PPF530AE3851

When init_msix() fails, it needs to clean all MSIX resources.
So, add a new function to do that.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v3->v4 changes:
* Change function name from fini_msix() to cleanup_msix().
* Change to use XFREE to free vpci->msix.
* In cleanup function, change the sequence of check and remove action according to init_msix().

v2->v3 changes:
* Remove unnecessary clean operations in fini_msix().

v1->v2 changes:
new patch.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/msix.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index f8ce89b8b32f..b80491ed32bf 100644
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -655,6 +655,27 @@ int vpci_make_msix_hole(const struct pci_dev *pdev)
     return 0;
 }
 
+static void cleanup_msix(struct pci_dev *pdev)
+{
+    struct vpci *vpci = pdev->vpci;
+    unsigned int msix_pos = pdev->msix_pos;
+
+    if ( !msix_pos )
+        return;
+
+    vpci_remove_registers(vpci, msix_control_reg(msix_pos), 2);
+
+    if ( !vpci->msix )
+        return;
+
+    for ( unsigned int i = 0; i < ARRAY_SIZE(vpci->msix->table); i++ )
+        if ( vpci->msix->table[i] )
+            iounmap(vpci->msix->table[i]);
+
+    list_del(&vpci->msix->next);
+    XFREE(vpci->msix);
+}
+
 static int cf_check init_msix(struct pci_dev *pdev)
 {
     struct domain *d = pdev->domain;
@@ -709,7 +730,7 @@ static int cf_check init_msix(struct pci_dev *pdev)
 
     return rc;
 }
-REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSIX, init_msix, NULL);
+REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSIX, init_msix, cleanup_msix);
 
 /*
  * Local variables:
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 09:31:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:31:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.979993.1366479 (Exim 4.92)
	(envelope-from )
	id 1uDK57-0006cX-4t; Fri, 09 May 2025 09:31:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 979993.1366479; Fri, 09 May 2025 09: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 1uDK57-0006cQ-29; Fri, 09 May 2025 09:31:49 +0000
Received: by outflank-mailman (input) for mailman id 979993;
 Fri, 09 May 2025 09:31:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDK55-0006cK-C4
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:31:47 +0000
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com
 [2607:f8b0:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6a19a9ea-2cb8-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 11:31:42 +0200 (CEST)
Received: by mail-pg1-x52b.google.com with SMTP id
 41be03b00d2f7-b200178c011so1263990a12.3
 for ; Fri, 09 May 2025 02:31:42 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-22fc7546a09sm13317925ad.9.2025.05.09.02.31.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 02:31: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" 
X-Inumbo-ID: 6a19a9ea-2cb8-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746783101; x=1747387901; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=QbGqDK74WFhvNDyVgy+vdd9sc2MXt4tWVR9or+eFH0g=;
        b=iOEgInnZ2A5+NSVZw4wMH1rMJ5nU3XUiDfnHg5SLSuJqkcH7Ra3lXVekgxxDHFE3LG
         X0xjUZ1iljbrT02MLQJv4ruCD1Sp9Cot2B2tzORwmEGEgwjfVXuiVNwAhlttoKHynmBU
         ucHxjKPnyferUxPGiDkbkp0xyBUQiv4eAP/0A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746783101; x=1747387901;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=QbGqDK74WFhvNDyVgy+vdd9sc2MXt4tWVR9or+eFH0g=;
        b=M3qf+UKuhb5X+ojqGz07sv1pXiHPKSkGjoF0Zh44dGIKU//DAhSxKGBq8L38rYlGF4
         WPYbjcuWnQ43wz4B5snr+Y5okLtuKvRjyVSVT9gxQXXSr99cne1q0vuW+UeySI92xfx5
         PoB7E0OcCuCfU8T9nWMSPsZ9TEiJO+IRER0FJzQPbfUrm4J4c4pUUqqpIPSM5IKCfTgQ
         pixpPqSIh+znpaFJ1Iqyg17nigKIy6Q7vyWiwyNmddfRHzYFJbU0Y/xiNdr5dAtKvM6j
         4/SqabVWpy7yCkkCl9102KU0ww5bzRUAArmWccILhFbpHHPDomsfq1EYj37duQuRH4v9
         ywxA==
X-Gm-Message-State: AOJu0YzwXMTZkqEk4BF9NQ9G+QYgV8AQxv4Lq5ldF1+3D4JlXAvU7MoH
	7m7b578oGm9avP3W484d9QCo2X6/4WS+sZiuAJbgJmB0HhTf4EMiFB44Rhd9c7M=
X-Gm-Gg: ASbGncu03APg31qTreXLY4OtFU8oEbJ3Oz2KPtgsDy1kiQsa0TVGt4ji0dUGx2IqwF9
	jA+emwYBCelhClj6vt/4nj0huhyN4DDowjuwlBrt/ktvXptQHQkYR2B6Ey9UAzLl44cHDxz/mYz
	T8nUKvI3tzyrm93gtMbB/1Pvbcghkn33652oHG37DQ7Gfob0dvr4NnBmpWYouyyWs+pi2UMi0zX
	Un+h72SvG+WzOYblJ3Qoy+8wHgS9NoAzSJeFt7jdI4o7hQaegi5JzLVfk3E6M9Bwj/kFkRd6Ou9
	RArnf9l+k7dPjsljxlHyug4Pik5AiVwxAfkr4S5B14IXwEWJL5Up39GN
X-Google-Smtp-Source: AGHT+IFdcGSdxmIPUcRPk93A6dYeyzKCfFuJZh7brYMlrcvS1mPwgv0DBJxdWStjeXnjm+MfX8OmIQ==
X-Received: by 2002:a17:902:ced0:b0:223:f9a4:3fa8 with SMTP id d9443c01a7336-22fc8b35b38mr42658415ad.19.1746783100681;
        Fri, 09 May 2025 02:31:40 -0700 (PDT)
Date: Fri, 9 May 2025 11:31:35 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org,
	Oleksandr Andrushchenko ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Jiqian Chen ,
	Mykyta Poturai 
Subject: Re: [PATCH v21 2/2] vpci: translate virtual PCI bus topology for
 guests
Message-ID: 
References: <20250508104608.531079-1-stewart.hildebrand@amd.com>
 <20250508104608.531079-3-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250508104608.531079-3-stewart.hildebrand@amd.com>

On Thu, May 08, 2025 at 06:46:07AM -0400, Stewart Hildebrand wrote:
> From: Oleksandr Andrushchenko 
> 
> There are two originators for the PCI configuration space access:
> 1. The domain that owns physical host bridge: MMIO handlers are
> there so we can update vPCI register handlers with the values
> written by the hardware domain, e.g. physical view of the registers
> vs guest's view on the configuration space.
> 2. Guest access to the passed through PCI devices: we need to properly
> map virtual bus topology to the physical one, e.g. pass the configuration
> space access to the corresponding physical devices.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> Signed-off-by: Volodymyr Babchuk 
> Signed-off-by: Stewart Hildebrand 

Reviewed-by: Roger Pau Monné 

There's the addition of the ASSERTs in vpci_mmio_{read,write}() which
could do with an ARM maintainer Ack/RB.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 09 09:39:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:39:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980001.1366488 (Exim 4.92)
	(envelope-from )
	id 1uDKC6-0007R2-R4; Fri, 09 May 2025 09:39:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980001.1366488; Fri, 09 May 2025 09:39:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDKC6-0007Qv-OY; Fri, 09 May 2025 09:39:02 +0000
Received: by outflank-mailman (input) for mailman id 980001;
 Fri, 09 May 2025 09:39:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDKC5-0007Qp-3c
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:39:01 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6f8fad48-2cb9-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 11:39:00 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad21a5466f6so136999166b.1
 for ; Fri, 09 May 2025 02:39:00 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad219346383sm123039166b.47.2025.05.09.02.38.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 02:38: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" 
X-Inumbo-ID: 6f8fad48-2cb9-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746783539; x=1747388339; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=mp32gjzgRrenuo0NKCc9+RfLjre+EXyM2hz1nmonf40=;
        b=CxpT/1GcAmbqi1ADXPsOWEQXSOxiQFyRcmF7Tdqqs7SQWqgd38oRTXKcPCPEJSLLtc
         7CPjuTH3c71ID9PY8uSo+XkHUbR27r4GDRx7eEtZw9svMrK42Xl6GYR2HPIC8hKejsT9
         Wg0T7NGj81TSnA6jTaZkaZYXVn5ND4BT7cjAY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746783539; x=1747388339;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=mp32gjzgRrenuo0NKCc9+RfLjre+EXyM2hz1nmonf40=;
        b=UddBMpFHwnNzwHG6JaLUjLi018TD5qgzGLwoBByRKxQYGQU2uSaWcYqZDGE5HWcbDG
         HoXBXhxCNCJkNtbbVHCHMoFS1S+Sf3X+3EjNVx/Onf3p36loNYRxxh/gTfIp5/ymV4Uq
         53WUCh3VYyoGVXT0JkAUAvdnvgoYWFqGttd4xOOChY4SJmu5NKC3FkkXsSosE33Vxh2K
         TsRs+gcHgMr3EqXfGufma+Q9zgVE9Pqcg8MYd9qSb2BcvnXw/HAc6LpVFMuRA5bkhdRM
         ZN1jm5g659ZW31HNkp2e5tvd74N9BzO2docpFL9Hbou+aYQwUImD61iBWZV4HOUh8Ff3
         icOw==
X-Gm-Message-State: AOJu0Yw1jb1mG+ehHa2l+WDzJZw6mFNxiXEmW6+hdamddUBLnlfz+xmt
	o/81AJ4ih6D12XBKvu/SiMX8ZdzzoPJKkhAH6wllfpIl7bbkYwbWwG03ZFHDUsE=
X-Gm-Gg: ASbGncuHmn1VhLL3o6WM+JesneTsRxVnuyxwltUF4gs8mzbPL6xdpS3EExsuUgKz5E4
	VewUFDtir3tPGyDAaqt7uvysaXtKFSEAvDf+DVG4FCqdXBtilVYa7LhP+hG0ttmeR8cNEHIHJnI
	6WIQWUKknqUUTcL7GAetQsbK/CiLXFS2Yg3ZlWPOAnF4X47U/wOEj4mcTKxaIs2fCVKohSsySck
	pqn4Ik4Zp+fDr4VL6iai17heKdT+92N6G9SOZcSganMDby6ZBbngg4cX350kPNrw1yZRrVOxg76
	vAB8xKhvr6Yvi2ZrIGnQfTuHPNKKh/AWJjc8evGyi0KGMv7NBfQ=
X-Google-Smtp-Source: AGHT+IFsdfPxrXYe4mwZ0RP563glGM73ygUXV3Txf6Pj+yIu3vhBQygYd8zwN41xL9Caq//dLt2Hug==
X-Received: by 2002:a17:906:ba85:b0:aca:d29e:53f1 with SMTP id a640c23a62f3a-ad21b1cbf9cmr261272466b.12.1746783539444;
        Fri, 09 May 2025 02:38:59 -0700 (PDT)
Date: Fri, 9 May 2025 11:38:58 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org, Kevin Lampis ,
	Anthony PERARD ,
	Juergen Gross ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2] livepatch: Pass buffer size to list sysctl
Message-ID: 
References: <20250508170156.558291-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: <20250508170156.558291-1-ross.lagerwall@citrix.com>

On Thu, May 08, 2025 at 06:01:56PM +0100, Ross Lagerwall wrote:
> From: Kevin Lampis 
> 
> The livepatch list sysctl writes metadata into a buffer provided by the
> caller. The caller is expected to allocate an appropriately sized buffer
> but this is racy and may result in Xen writing beyond the end of the
> buffer should the metadata size change.
> 
> The name buffer is expected to be an array of elements with size
> XEN_LIVEPATCH_NAME_SIZE to avoid this kind of race but the xen-livepatch
> tool allocates only as many bytes as needed, therefore encountering the
> same potential race condition.
> 
> Fix both these issues by requiring the caller to pass in the size of the
> name and metadata buffers and then not writing beyond the allocated
> size.
> 
> The sysctl interface version is bumped due to the change in semantics of
> the fields.

I would be tempted to add:

Fixes: b145b4a39c13 ('livepatch: Handle arbitrary size names with the list operation')
Fixes: 5083e0ff939d ('livepatch: Add metadata runtime retrieval mechanism')

As the current approach can easily lead to buffer overruns in guest
memory, as Xen doesn't know the size.

> 
> Signed-off-by: Kevin Lampis 
> Signed-off-by: Ross Lagerwall 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 09 09:42:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:42:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980009.1366499 (Exim 4.92)
	(envelope-from )
	id 1uDKFA-0000se-8Q; Fri, 09 May 2025 09:42:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980009.1366499; Fri, 09 May 2025 09:42: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 1uDKFA-0000sX-5A; Fri, 09 May 2025 09:42:12 +0000
Received: by outflank-mailman (input) for mailman id 980009;
 Fri, 09 May 2025 09:42:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDKF7-0000sB-Ny
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:42:09 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2061a.outbound.protection.outlook.com
 [2a01:111:f403:200a::61a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id df9ad671-2cb9-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 11:42:08 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 BY5PR12MB4258.namprd12.prod.outlook.com (2603:10b6:a03:20d::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.20; Fri, 9 May
 2025 09:42:03 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8699.026; Fri, 9 May 2025
 09:42: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" 
X-Inumbo-ID: df9ad671-2cb9-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=t5vL3n2upgPyXr1n6t7U2hGKnSglVzW8MyPtmzApCZS76F6dpFNx144NySG34T17C2s3U6B8IHjj+PY8D5N4T3xfMPSieZ8nYxPwFYJ9GG4RhiZX/fmedj/PIR+yBkQQ7xOTDFrbyIJ4sB1ejsVpd+XYTD7Hw+bFHFhaQvbZ3r/KeJv1L2d37eozWmCf9ikSxZ07zR1XaRAb6MeK2CFEZC26hMMHZUJPPtzlpz4+cwPr/rbEdnGnq4zc1Tlk3QQ8MUvrWneW2qO8SERSmkAH2AnCOCFUgEQJhJczzhoyOzu3jdVH/geqBX/mLUppKBHKmb529h1JAFw85PJhYNnwDA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fYSwX0z5vHJ7EBrQ+cgJhSYFa1CQdP9Dpe5U7d9W0EM=;
 b=FVfJOpd7WknYeoqUP9M3+UXosCTUQlj+L0Dz7bm8ywdqVsaBKpsLMqykpBRKQsfpRBYDqRBHpxoILuGJsLHHiG1kl+lpTEGBricdeuAhTfLr1yo7BP+6Hyl5TjcwPKzKt6AZpB0P6YM+umRqkIO6VxdjXYM00rALzQ8N4Nio6RztdLShhXXai0nHVC7g/d3EczupYhe7Vo5K3grk6Q3DwZquOJj5q+T4cv3ko0s0YgZrWX/B+iyEw9sRrC2/+PMTTjFdXlIory5HWaUAQGfFX4zFG9HP2WGyo4bWlmpckkfsERUsozTFzAp/0S68UO2bKCy8giki3Hu30cf07yBOgQ==
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=fYSwX0z5vHJ7EBrQ+cgJhSYFa1CQdP9Dpe5U7d9W0EM=;
 b=BTz9FHBPDC43axwq8QMG1SRkDnf9l+GPqw2xqIZtdibvJWFAboBlXENyVgLtFFhPDWstCePn0j8RFGWeWH3k08b7rHQ0ckm8Zl5adlMxneOeXTtEPPCWktVKkyIHDNCOrFSpg14kUooGv1gahSaOVJMD2DdPrr8bAjUj2vm2F4w=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Anthony PERARD
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 14/15] tools/xenpm: remove px_cap dependency check for
 average frequency
Thread-Topic: [PATCH v4 14/15] tools/xenpm: remove px_cap dependency check for
 average frequency
Thread-Index: AQHbrRCwc1yeGpZzL0W02M9xuQGFIrO8Yf+AgA3L4uA=
Date: Fri, 9 May 2025 09:42:03 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-15-Penny.Zheng@amd.com>
 <0bc47af9-ea09-40ba-8a81-933a10b58435@suse.com>
In-Reply-To: <0bc47af9-ea09-40ba-8a81-933a10b58435@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=3c63a98c-63b4-450e-a222-8b4287b10989;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-09T09:41:56Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|BY5PR12MB4258:EE_
x-ms-office365-filtering-correlation-id: 7e29bc7f-1170-47df-e775-08dd8eddc0fc
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?R3pOZDl4UlJqS3ZVa2dUcUQrWS80Q3JXRVN3Uk9XV3dQSkxjdzY4OFJ4YTlL?=
 =?utf-8?B?VXYyWEhUR2tSdDVmbnVQWFEydU5wVHpHdVM3aURod2hBb3Nsa2VvdVRTUGp1?=
 =?utf-8?B?QThrTDdHSkl0WGZUWTMvK0ZFWG1UTmNKZDU5R3dIWWR4K3dLUU9uTktpWDFR?=
 =?utf-8?B?ZE5oWkVaVno0blRFMTQzVDFkaFp0ZlVyUlJxL296T2N1WEg4WDJ4SllrYTY2?=
 =?utf-8?B?ZTFKUWVHaGt3OUR6cUtRVmlTaEhRbHhBMlhUZnRQSkZjRzZpRmhaTHpQV3ZI?=
 =?utf-8?B?OWZwN3RlSlp1V1cza3orcUFSTjJOc0FtV1JvQUJHbEgrZlVETW1FL25naDNY?=
 =?utf-8?B?WkcvUHIyZXJtelFCTnFWcVVheENpc3dlYUsvZlNvckM1RkJjZFczNGgzR2ZS?=
 =?utf-8?B?VFlXczFkQld2WHFlejMxZVNsUjYzQlJiOWpLazlwMW0waVI1UnZVK2dSYWpp?=
 =?utf-8?B?VkFGMklDbkRadWd2U3hFcTdiU1d0Y2VScTlBalZnQmZkZVNnTVpPUmtBVExy?=
 =?utf-8?B?cHl2dkZpKzdjdHdObzFTazBPOHdpLzVZaUxnTmdjZ3g1dVpLRk1EbjJOb2pS?=
 =?utf-8?B?YmZ2WnFKNTJGQUFnV2Y1WnowQ1doTXo2U2kxVjBNRmsxSTRmWTVUSlNqTFBY?=
 =?utf-8?B?UkswZlJGamJTSFp5a2FQcU5zeVAycG1IMzFXU0Y1Vkx3M2RiWUVjU2VIdE94?=
 =?utf-8?B?MkRwdzJqcC9NT1ZKZnhSQ295eHJEcXpJTlN6TlgxOHh1M1FndTdSODI4Y3dn?=
 =?utf-8?B?TGhFTjFYWW1DdEhHcTd5cHozQUVtNURVbWVXL2ZkNTYyU0FHeit1SG5FRTRt?=
 =?utf-8?B?VnFldm9tZDJmRnZvMWN1KzF5Y0swWWtXOEcrcE41UzNBNE1Jd0pxaE1nUjhj?=
 =?utf-8?B?bzdmZENXM0wrZXpzSC9zRlJ0dXlrNEMyUU5ud1NiMjFUVllrVzVxa1NqVWZw?=
 =?utf-8?B?ek83bFNoR2JBYzVWVnkyMG9lNStmSy9jZHZld3ZqMWVYbFpUYlpPQnVmMU0v?=
 =?utf-8?B?REpSTUV0V0NzZWRlb1NFaXJBSnFYT1RiMFFpU3BHTHNVS09wYkdWQ2VPRElK?=
 =?utf-8?B?cC93dGhIT3FCWFczU0s3WFI2R3haSWNDUjJOdVR6NTFhVkN5L1pIeEQ3Z1ZO?=
 =?utf-8?B?N1JHSVNZN2RpYWtzTWFwWlR0QWxUTGExek1YU3JrQ2xrOGh5R21aM0x3Zzd5?=
 =?utf-8?B?TDhjb0RWVHhGK0g4MzJtczhvQ0FvZ25mWTV0Q3lCQlBFNEpSYTd0VUNIakhY?=
 =?utf-8?B?eTVTQ01GLzRieUZiTzdWaXVqclpuRit1cytydFBqc253NndXV2ZnRFhFd29n?=
 =?utf-8?B?Z29VL2k5bFF1UFVUNjNQRkpoVFZNYjd5UFFnNjBHNU4zTXdrTlZ3ZXY2cTJZ?=
 =?utf-8?B?M2owUDFnV3Y1bHpXOWdpVkR5M2k3VmRqLzRoMkY4MW4rTzlpK2RiWDFSTUpu?=
 =?utf-8?B?VjZvbDV0OFQzUlNnRDBrUEtHUm5BTWFXSHVIc3NUditwZ0FTMUxQK25pWGRS?=
 =?utf-8?B?ZVVLbDNhNGQrMFRXWXBBcXRyZ0kvY1EvM2hoaDNyeFhaV1I2cFJoZGxOUjJl?=
 =?utf-8?B?RWNaK0xpSDBNdVFTOEFENGJtQkdXUFd0bjVhQVBjM1lnK3RvbWpkc3AvL2Ja?=
 =?utf-8?B?eXlZVk8vSEVqUkZZdzdhWEVieXN2MEJ0aHhhVUVCK0E5ZCtUMUhKdWUxOGFj?=
 =?utf-8?B?WnN0M2FITzdoSlhpS08zLytYczRMck5vTHM0K0NuMXB4VGh1OFZlazFkUWhD?=
 =?utf-8?B?NEpJdUtBMktIYXJIWUdlbWdJak1iRVBPZXUvQUU3MnA1d1ZLVU9sZXRWNUl3?=
 =?utf-8?B?Mzl0ajFyVVA5ejMwaWhUaVZrMklVQkVJQU1LVFdaZUR1TDJ6QnpHYmcyMk03?=
 =?utf-8?B?cnErZEx1UGE1SFI5NFVHa0ZaU2JtMFdjS0tYbTFwR3hLeEhEM0xNNlBKdG53?=
 =?utf-8?B?T0RHdEQxMStZOWlaSFFtWFhZZTNFc3RYTlpIWXJuMG0xbUxIVUQ2bmlwaGYv?=
 =?utf-8?Q?moupbBar37R5qBgBMEZgoso/9FIhNI=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MnNWVGN0ZFFLVVo5ZGN4aXYxZWJsSnlMSHdiU0FwQkhJUnlIQTJ2ZWIvb0I1?=
 =?utf-8?B?dzAzaVBwMGtMOGFMemdtbnpUam4yQUU1aVhVMmRwVWNpaW05T3dFWmg3RW8y?=
 =?utf-8?B?enE0Um5ZNUhPR3ZiN3MrR2lmeG8vUjVKdkRiQnR5akdxamwvT3U3eDdSdzM1?=
 =?utf-8?B?RmZ5S0lHS0xtMWFiclArMjNQdi94V0U1cGtJTEVHUWNaMThtQ0JSb09Gektk?=
 =?utf-8?B?VHVDTTVFekdOOTh0bG5RNHZIUHhKbjZ6aEpoQVNUNkhRVlo1RHcrY2xTTnVw?=
 =?utf-8?B?cThWK2dRcHdjWGpXaHZMUGhwTkROTDh0c3FodzFrVng5ajJmRWpZdzlQTjkv?=
 =?utf-8?B?NmZpbXVvNDVvbTdxODhobHRZTU9iQ2h5SjRoYUdiQlQ4bGI2RDd3KzZQYlBH?=
 =?utf-8?B?US92d2hIOEdISWhmMWF3U3VaMVFUNEczZnJybi9YMllJVjgyVHZsMGNoMWRs?=
 =?utf-8?B?Zmh3U0RsbXFDdXV5N1lZa1FPNm91c0NBc25mQ0dUY05EVytoNzVSUE1qdWpD?=
 =?utf-8?B?enBSOU1EbEtyUTE4eTJuTmNvYnRMRkg4Z1lVbDg2dkJjb2JJSGdVZmJHUndC?=
 =?utf-8?B?SE90WGpiN1BTQXRaYStBTWlDaXJVK1ZIbjcwVUpkUmYzVzROQ3VBZFJNZy9s?=
 =?utf-8?B?eCtPcHY2SUZSRG9lYlp5a2ppNFRMMFZqNkN2bkJMZmQwU0JIUzhNSDc2KzUv?=
 =?utf-8?B?ckZJZkdXL0tQOXNuaWc5Nkd0TlBkTThGOEl1ZVhISEN4ZkRxYS9ibGNmRWU1?=
 =?utf-8?B?TUU1L2dUYmZpZU9PazhnMXJFTDZlc2N3eFBhV1loMEM0dnNVR1ZOTlRCNVBj?=
 =?utf-8?B?V0llajN5RXd1Z1JSWFMvSkkxa3U5NGNjUmh4cmdJTnFRVHNVOG1nb2cwRVRP?=
 =?utf-8?B?T3pBSmdQdzNWOFJuU3UxdHl1NmpaRXpJcFhzdzR4c3IrLzBwV05tOUFzbkZB?=
 =?utf-8?B?ZW5RcldZV2dweW1sY3J4Y3ZRNjFnYVdIRm55MHM4eU5OZTh2dXpJemtxV2hP?=
 =?utf-8?B?ZEtqVmR4OVF1bkxXS3BoSjNGcTUyc2JueThhSU4vWHc1Q3NjUjU1YlFheHZ1?=
 =?utf-8?B?YmVCZStLQ1dSNjdoNDUxWGpBUm9Ka1p3WFh3NW5HMlh4Qk9BNnFjVEtSd01X?=
 =?utf-8?B?ZGpIdGlYckttMThiVUg5TUFuNkV3TUp6bzZIYnFJVFZNUWk2TE5VU1lMbkhE?=
 =?utf-8?B?NmJyU21ocE13dzRxODdTZlB5YXg3ZzY1dURNUXMvaWdWc3QwR0hxeUlpZnBa?=
 =?utf-8?B?WHNIckVhc3VNTmw0TUlCRUJPSkZhVUo2Y0MyckVNMmVKdXd0R3VHNXAwSkow?=
 =?utf-8?B?YzlVak5HZ0NERjlRRmlyM204clZIRm9wKzBUZzI3anJkajBSUEJlWGRtcUx4?=
 =?utf-8?B?RmdadEIvMVFUdGsydDBaQU5DRWUrQ3VyY3Iwa1lwUUxNMUFIbnQ2VUNzWmQx?=
 =?utf-8?B?aS9nSmNzaHhrQ0pIL2RmVjN5TnMxZXNIazR6bGFQRWE1c0dBWWcwNTNyb3RM?=
 =?utf-8?B?THFJUFlraFRaZTNWM0pmVEtvQmNmV0RiNnlBNHh6c2w4ZnE5SnFNNHhnU0p1?=
 =?utf-8?B?cFdENWlMOURhWG52VFdKUWxwWFRtNER2MW5BN0ViVURiRkRmdnNoZTZENk9M?=
 =?utf-8?B?YlFCSGNUU3A2cnduQzhJakd6WXlNOS83NmtmTWh3NE9KS1VGWkcvZHZTejBJ?=
 =?utf-8?B?WFFoenJmVVVTTnJ0cEZNS0NoTVJ3dUcxaG9FL3V3dlV1R2p3dHRnSDV5SHMr?=
 =?utf-8?B?Tm5kQXFrUUQ0VGsxdUlTTlRCcjFhOWJtSnBkK3BhTmRKMDRhdEh0MmFpU0Rh?=
 =?utf-8?B?clJmeVNjcDNPVzlrbU1QTkJGZU4yYnVVb0lOY1ZzbG0rQUdFaEJZSEt6UGls?=
 =?utf-8?B?THVSRldTKzhtdjRvVmRuc2pQQXg0WG9WNnM0K05DNnNiQ2hYUUY5OG1oWXB6?=
 =?utf-8?B?eFYrM1JXTTRrN2o4cVovL1lSZHZtUlZQM2kzS0tBeFY5SUNTRXFKVm9JWWdV?=
 =?utf-8?B?UUljakowY2tWaUJOU0lTTjE5UEhYbTh1c3cvLzhZb1djM1k1eEZTbmp1bldt?=
 =?utf-8?B?ZUxIMnI0N3lBaElyczRuVWdVaTJHNlh2aGlhbEdpMnhGYm5jM1VQL2w0bHpM?=
 =?utf-8?Q?rkOA=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e29bc7f-1170-47df-e775-08dd8eddc0fc
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2025 09:42:03.3096
 (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: /1MHRbnf7BxS2XZxh27Tcw2AiJGLJnwv2xR+ccKs7dHgOUYFmby0hL0iApEpUubvCjUDq2kq/ZFKcZNSmiP+NA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4258

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmls
IDMwLCAyMDI1IDEwOjQyIFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5j
b20+DQo+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFudGhvbnkgUEVSQVJE
DQo+IDxhbnRob255LnBlcmFyZEB2YXRlcy50ZWNoPjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2pl
Y3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjQgMTQvMTVdIHRvb2xzL3hlbnBtOiByZW1v
dmUgcHhfY2FwIGRlcGVuZGVuY3kgY2hlY2sNCj4gZm9yIGF2ZXJhZ2UgZnJlcXVlbmN5DQo+DQo+
IE9uIDE0LjA0LjIwMjUgMDk6NDAsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiA+IEluIGB4ZW5wbSBz
dGFydGAgY29tbWFuZCwgdGhlIG1vbml0b3Igb2YgYXZlcmFnZSBmcmVxdWVuY3kgc2hhbGwgbm90
DQo+ID4gZGVwZW5kIG9uIHRoZSBleGlzdGVuY2Ugb2YgbGVnYWN5IFAtc3RhdGVzLCBzbyByZW1v
dmluZyAicHhfY2FwIg0KPiA+IGRlcGVuZGFuY3kgY2hlY2suDQo+DQo+IFdlbGwsIHllcywgSSBh
Z3JlZSB0aGVyZS4gQnV0IGNhbiB5b3UgZXhwbGFpbiB0byBtZSB3aGF0IHRoZSBmaWxlIHNjb3Bl
ICJhdmdmcmVxIiBpcw0KPiBnb29kIGZvcj8gU2hvdWxkbid0IHdlIGdvIGZhcnRoZXIgYW5kIHRp
ZHkgdGhpbmdzIG1vcmUgdGhvcm91Z2hseT8gTXVjaCBsaWtlDQo+IHNob3dfY3B1ZnJlcV9ieV9j
cHVpZCgpLCB3ZSBjb3VsZCBjYWxsDQo+IGdldF9hdmdmcmVxX2J5X2NwdWlkKCkgcmlnaHQgYmVm
b3JlIHByaW50aW5nLiAoSXQgZXNjYXBlcyBtZSBhbHRvZ2V0aGVyIHdoeQ0KPiBzdGFydF9nYXRo
ZXJfZnVuYygpIHdvdWxkIHByZS1maWxsIHRoZSBhcnJheS4gVW5saWtlIGN4c3RhdF9zdGFydFtd
IGFuZCBweHN0YXRfc3RhcnRbXQ0KPiB0aGF0J3Mgbm90IGluY3JlbWVudGFsbHkgb3IgZGlmZmVy
ZW50aWFsbHkgdXNlZCBkYXRhLikNCj4NCg0KUmlnaHQsIEkgdGhpbmsgYXZnZnJlcVtdIHNoYWxs
IGJlIGp1c3QgbGlrZSBjeHN0YXRfc3RhcnRbXSBhbmQgcHhzdGF0X3N0YXJ0W10sIGdldHRpbmcg
cHJlLWZpbGxlZCBpbg0Kc3RhcnRfZ2F0aGVyX2Z1bmMoKSB0b28sIG1heWJlIHdlIGRvbid0IG5l
ZWQgYSBhdmdmcmVxX3N0YXJ0W10gdG8gYWN0dWFsbHkgcmVjb3JkIHRoZSBudW1iZXJzLg0KV2hh
dCB3ZSBhY2hpZXZlIHRoZXJlIGlzIHRoYXQgaW4gZ2V0X21lc3N1cmVkX3BlcmYoKSwgd2UgY291
bGQgbGV0IHBlcl9jcHUodXNyX3BlcmZfcGFpciwgY3B1KQ0Kc2F2ZSBBUEVSRi9NUEVSRiB2YWx1
ZSBhdCAgc3RhcnRfZ2F0aGVyX2Z1bmMoKSBwb2ludC4NCg0KVGhlbiwgbGF0ZXIsIGluIHNpZ25h
bF9pbnRfaGFuZGxlcigpLCBydW5uaW5nIGdldF9hdmdmcmVxX2J5X2NwdWlkKCkgYWdhaW4gY291
bGQgYWN0dWFsbHkgbGV0IGdldF9tZXNzdXJlZF9wZXJmKCkNCmNhbGN1bGF0ZSBBUEVSRi9NUEVS
RiBpbmNyZW1lbnRhdGlvbiBoYXBwZW5lZCBiZXR3ZWVuIGB4ZW5wbSBzdGFydGAgZHVyYXRpb24u
IFJpZ2h0IG5vdywgd2UgYXJlDQpjYWxjdWxhdGluZyBpbmNyZW1lbnRhdGlvbiBiZXR3ZWVuIGJv
b3QgdGltZSwgb3IgbGFzdCBgeGVucG0gc3RhcnRgIGNvbW1hbmQgdGlsbCBub3cNCg0KPiBEb2lu
ZyB0aGF0IHdvdWxkIG1ha2UgeWV0IG1vcmUgb2J2aW91cyB0aGF0IHRoZSBweF9jYXAgcGFydCBv
ZiB0aGUgY29uZGl0aW9uIHdhcw0KPiBib2d1cyBwcmVzdW1hYmx5IGZyb20gdGhlIHZlcnkgc3Rh
cnQuIChJJ20gZnVydGhlciBpbmNsaW5lZCB0byBzYXkgdGhhdCB0aGlzIGNoYW5nZQ0KPiBzaG91
bGQgYWxzbyBoYXZlIGEgRml4ZXM6IHRhZy4pDQo+DQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Fri May 09 09:47:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:47:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980019.1366509 (Exim 4.92)
	(envelope-from )
	id 1uDKKb-0001Si-RY; Fri, 09 May 2025 09:47:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980019.1366509; Fri, 09 May 2025 09:47: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 1uDKKb-0001Sb-Oe; Fri, 09 May 2025 09:47:49 +0000
Received: by outflank-mailman (input) for mailman id 980019;
 Fri, 09 May 2025 09:47:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDKKa-0001SQ-Ip
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:47:48 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20615.outbound.protection.outlook.com
 [2a01:111:f403:2414::615])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a952b6b6-2cba-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 11:47:47 +0200 (CEST)
Received: from DM6PR21CA0003.namprd21.prod.outlook.com (2603:10b6:5:174::13)
 by MN2PR12MB4285.namprd12.prod.outlook.com (2603:10b6:208:1d7::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.24; Fri, 9 May
 2025 09:47:42 +0000
Received: from CY4PEPF0000EE33.namprd05.prod.outlook.com
 (2603:10b6:5:174:cafe::29) by DM6PR21CA0003.outlook.office365.com
 (2603:10b6:5:174::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.5 via Frontend Transport; Fri, 9
 May 2025 09:47:41 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE33.mail.protection.outlook.com (10.167.242.39) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 09:47:41 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 04:47: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" 
X-Inumbo-ID: a952b6b6-2cba-11f0-9eb4-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VWumzrbMMy5Lz3B9FAAb5YIhOT1g8MbW9kCjMGwCTVM4PA723JqxhGBq+69Ze2mlbLarea27xZwUHPF4ciWfeUJTyjSjeKfs9U0H/CqOW5rvOS0mfRoOJncXseFF/3TqMlHm3i8g3r0GpfxkpggoRPZCrpIaxltYyDL4LFEsSCXv2P58sE95hKr/wxi/Wgz/tSDscbyFqvngDP7dDY0OkkgMjRlO/jZIzmlccs6CE0JL1iIN4YNnHgHp9Oi74eBnFyBn5CkA/AVhWiREjEIWj+/NYBL8Z1mspnoKT+iRgJakEz50ILQS5iqf7Y+tFwthRh5m/kPukwmIhqyrKMAKfw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fP5/BJn2vVayGmthZ/RT7iF/lo9PSwS3SPqq2i68XMA=;
 b=noZ3ecnwAi7ZrhK5MHwnCQOzojenTX7h0nvAY/otK/dppR9pnFv4MEZ9ukyV8fMWMN098ndUoY2U6cSqjEyveSfQOMen/bhqdcB1T4YdWwRmKe7FavDrDXPyYuQCMSdmbQ6U6sUjWaHOwX1DkxHwxhfxq4mg09RP2Tk6OJsKptxtD/Krmimz/oORZDB4Sn2jnakwqafsU2hwG4qqz49D/aqKFnhoPQIxeTtIw0teSDALsELBiR+2wR2/r8BWpwc9x5ouwBp33nkjRkug6RwPEWdu9TY44/LOpkA79l6BlPTm8BodBUj8jKw6RressrYfNy9fdj2huoDeuUTcMWjxTw==
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=fP5/BJn2vVayGmthZ/RT7iF/lo9PSwS3SPqq2i68XMA=;
 b=mAgVmPn355enMN4/PA6xO0g6cxqOD/peu90ZsN2clQekuuzSU7sEWc+s37DNI4gl8IZaZGvClDScS/EIWcmt6lZDSJBMsJ5ZM1YhH8oQWeE7XBEjdUbyAUZ76ZCAJKRQzkafKM/po5nwCf8GsZ/EyvWrfcbTXtspbPrC1mPprkQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 9 May 2025 11:47:36 +0200
Message-ID: 
CC: Xen developer discussion , Andrew Cooper
	, Juergen Gross , Xen-devel
	
Subject: Re: Mapping memory into a domain
From: Alejandro Vallejo 
To: Demi Marie Obenour ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Xenia Ragiadakou
	, Stefano Stabellini 
X-Mailer: aerc 0.20.1
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
In-Reply-To: 
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE33:EE_|MN2PR12MB4285:EE_
X-MS-Office365-Filtering-Correlation-Id: 12051eac-3919-4d39-bf99-08dd8ede8ac1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UXBsRWx5QTZDWjZiWHhURXl2Z0Z1clhuUUgwTnhJRnYzV0Zyd3NoU1dKWXFI?=
 =?utf-8?B?Smo3YVBsYUhnVmc5cDRDcmZlQWExSGhIRnVVQUh4eWVVRFk3RWdZZG5MZ05x?=
 =?utf-8?B?b1JXOWpaZStkTHRza0l4S0ZuV1NndlZrQlUyNjQ1Y08wTFZINnlYVlJmMmMr?=
 =?utf-8?B?ME1SQzR0UnQya0p1MTVkakgrU1FycFdRUXlrZG9IN2FxRUlNUFVScldlbEJF?=
 =?utf-8?B?cVIwM2tia2hGWnhDeDJRT1YzTXp1bWJxcFFOZVZ4VFVQNVQ3VXd5bHNpVmNT?=
 =?utf-8?B?QmdPUFBTYWwwWlk0RnJjSFVQTWdxc1QrYitPQzJSWm9sTU5pYjVEMEE5Ky9K?=
 =?utf-8?B?UFpHVjlNdWRRZDBKZ2FhemhmWGRydGRiREJtbTRlSWxpY3M4Rk11S21ZcmFu?=
 =?utf-8?B?Y1oxSkw3eXdrUDJYZ2JjY1g2Z0RvQm82UXB1Zkt3dm1hMy95VHFFemI3NFFt?=
 =?utf-8?B?ZnR3VUwvdDU3SzI0MDFZK3JNOWRNbXpuSDRVbWhKK1JoWXV5Rkdjay9pU3A0?=
 =?utf-8?B?SThYT3BQeWx3bE9KdkU3UllLZVJkMHptNHpVTzNnSlFmckVEdWNVY01qL0lo?=
 =?utf-8?B?R0dvN1RGZ1FqK3dDT1dwUDBQdUc3dWVjMUlFRTJwNUxuNFF0Qy96MXV6WEUw?=
 =?utf-8?B?SW9hRFlCbER2a0NLQ3BtaWJXT3hITEtOVDFaVDVWdEJrWlNTOGRIU0R5YW1S?=
 =?utf-8?B?TUN1QXh2OUNLVUFDSUhpeXZhblNGUnZOS0xJT1k2WWQ5OXpUVnFoRnoyQjdX?=
 =?utf-8?B?ZVN5TEIyOUpRVlRUcThkQUQ0cG55UEt6cDZVc0JYVWZ4SEo4SlBkSnQydkg4?=
 =?utf-8?B?WlFpOE9NbnFiamhSeW9UMUxZKysxNFVUQ3dVMW1hZnJlMVZaU2xHaEYvZnFk?=
 =?utf-8?B?TUtxOGVyQnoySDdQNUU5S2xsRFlqdkxjaXQybEFGbk1PN1hYMFJNN1pJWW9S?=
 =?utf-8?B?aE1tck9Vd0JxV0ZoSjYxdyt0Z21XVC85TXpKei9SYjUxZkhsamJHT1Bzc2cz?=
 =?utf-8?B?NlpGZVJTUWtHVXFIbTVJRlNyRFphN29KbHdpWlcrSHMxY3pPZ3J3emhNMlUv?=
 =?utf-8?B?Z3MvVFB1S3VnYms1THhYZnBBd3lZN3B1SDVlblUrWlpNdmhXRVk5V291STgv?=
 =?utf-8?B?Z2hqUDFKcnBUNjRlVXp3RldFWjVvU2JBVVhrMEVyQ0p0a3JPUVJSblNwdk5n?=
 =?utf-8?B?RUVXRGJCSW5Da3Y3Yk5KampKcEh1dzBkb01nWUVXSExmMjhHQkpaZ3J5aVox?=
 =?utf-8?B?aHMwVGczVTZGazBHWTNZc2Y4THJEakpzSGxpUnU2L3ROZTFoczFiQmlEdHNi?=
 =?utf-8?B?T0daMGNoWVlXaDA2ck1KQmNPSzRoSHd3SVBjQmNWdHhzNVo4QlJNcEFJMnQ1?=
 =?utf-8?B?TFdQeENKcFc2NzlHSy84eXdjS21uckZLaHpiN2g0ZkV6U1JTTFlxb056bGFW?=
 =?utf-8?B?S1NIeERoWFFTdjZ6NHVvREhNcjMzbjdiWC9kREJleVh0WlVoVEFSbzBVZ0lZ?=
 =?utf-8?B?V3JiakdoNHVFa0Z5ZlFHeEdCTktQcUdZREVyTkNlL05kRHVFRTJXMjE1emcv?=
 =?utf-8?B?cklnSU13aExSZHppVnhNUTlxSGd1Qk9neCsweUR3ZWR1S3M2NUNPL0xKTStV?=
 =?utf-8?B?Zkh2aE5mR1BVWkdaZUpwVTVEUktaaE5PWHJKd2FFV2FMWUxKcGt0M2taQzBT?=
 =?utf-8?B?akwwSlVzTVUvbVRhckkwWUUzZTlkNTJSbTQzSjREb2VyS2ZyM2g5YkNpUkNL?=
 =?utf-8?B?OHJoL3d3SVc1aUpuNjYyYTQwZ0pmbS9nYWdQQU9tbGpsSThDeG9uSXR6bXhs?=
 =?utf-8?B?dkkxZkpiMzl5bHlCa2RtcHNpblFhV25UU0tVQW9wUHU5RW1xemY1ZlBvQUlP?=
 =?utf-8?B?RkRyNFRwZlNRVHRjSVFFZGZBWWlJT3VveTdTZDNVNjEvdUhmTGErbnA4ZnR3?=
 =?utf-8?B?NjFBditReEtMcDJkT0crOHVKVEZiRnR1bFF6WmJKd0doMENNZTVPR1BsRG1n?=
 =?utf-8?B?dk83ejVBZHNDMEJUaHpXZjgzaGdVQ21GWHZ0bFZkNGY0Nmo1ZTZsd2lmeXo5?=
 =?utf-8?Q?yqgtid?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 09:47:41.7403
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 12051eac-3919-4d39-bf99-08dd8ede8ac1
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EE33.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4285

>>>>> A Linux driver that needs access to userspace memory
>>>>> pages can get it in two different ways:
>>>>>
>>>>> 1. It can pin the pages using the pin_user_pages family of APIs.
>>>>>    If these functions succeed, the driver is guaranteed to be able
>>>>>    to access the pages until it unpins them.  However, this also
>>>>>    means that the pages cannot be paged out or migrated.  Furthermore=
,
>>>>>    file-backed pages cannot be safely pinned, and pinning GPU memory
>>>>>    isn=E2=80=99t supported.  (At a minimum, it would prevent the page=
s from
>>>>>    migrating from system RAM to VRAM, so all access by a dGPU would
>>>>>    cross the PCIe bus, which would be very slow.)
>>>>
>>>> From a Xen p2m this is all fine - Xen will never remove pages from the
>>>> p2m unless it's requested to.  So the pining, while needed on the Linu=
x
>>>> side, doesn't need to be propagated to Xen I would think.

It might still be helpful to have the concept of pinning to avoid them
being evicted for other reasons (ballooning?). I don't think it'd be
sane to allow returning to Xen a page that a domain ever shared with a
device.

re: being requested. Are there real promises from Xen to that effect? I
could make a hypervisor oversubscribing on memory that swaps non-IOVA
mem in and out to disk, moving it around all the time and it would be
compliant with the current behaviour AIUI, but it wouldn't work with
this scheme, because the mfn's would be off more often than not.

>>>
>>> If pinning were enough things would be simple, but sadly it=E2=80=99s n=
ot.
>>>
>>>>> 2. It can grab the *current* location of the pages and register an
>>>>>    MMU notifier.  This works for GPU memory and file-backed memory.
>>>>>    However, when the invalidate_range function of this callback, the
>>>>>    driver *must* stop all further accesses to the pages.
>>>>>
>>>>>    The invalidate_range callback is not allowed to block for a long
>>>>>    period of time.  My understanding is that things like dirty page
>>>>>    writeback are blocked while the callback is in progress.  My
>>>>>    understanding is also that the callback is not allowed to fail.
>>>>>    I believe it can return a retryable error but I don=E2=80=99t thin=
k that
>>>>>    it is allowed to keep failing forever.
>>>>>
>>>>>    Linux=E2=80=99s grant table driver actually had a bug in this area=
, which
>>>>>    led to deadlocks.  I fixed that a while back.
>>>>>
>>>>> KVM implements the second option: it maps pages into the stage-2
>>>>> page tables (or shadow page tables, if that is chosen) and unmaps
>>>>> them when the invalidate_range callback is called.

I'm still lost as to what is where, who initiates what and what the end
goal is. Is this about using userspace memory in dom0, and THEN sharing
that with guests for as long as its live? And make enough magic so the
guests don't notice the transitionary period in which there may not be
any memory?

Or is this about using domU memory for the driver living in dom0?

Or is this about something else entirely?

For my own education. Is the following sequence diagram remotely accurate?

dom0                              domU
 |                                  |
 |---+                              |
 |   | use gfn3 in the driver       |
 |   | (mapped on user thread)      |
 |<--+                              |
 |                                  |
 |  map mfn(gfn3) in domU BAR       |
 |--------------------------------->|
 |                              +---|
 |              happily use BAR |   |
 |                              +-->|
 |---+                              |
 |   | mmu notifier for gfn3        |
 |   | (invalidate_range)           |
 |<--+                              |
 |                                  |
 |  unmap mfn(gfn3)                 |
 |--------------------------------->| <--- Plus some means to making guest=
=20
 |---+                          +---|      vCPUs pause on access.
 |   | reclaim gfn3    block on |   |
 |<--+                 access   |   |
 |                              |   |
 |---+                          |   |
 |   | use gfn7 in the driver   |   |
 |   | (mapped on user thread)  |   |
 |<--+                          |   |
 |                              |   |
 |  map mfn(gfn7) in domU BAR   |   |
 |------------------------------+-->| <--- Unpause blocked domU vCPUs
 |                                  |

>>> - The switch from =E2=80=9Cemulated MMIO=E2=80=9D to =E2=80=9CMMIO or r=
eal RAM=E2=80=9D needs to
>>>   be atomic from the guest=E2=80=99s perspective.
>>=20
>> Updates of p2m PTEs are always atomic.
> That=E2=80=99s good.

Updates to a single PTE are atomic, sure. But mapping/unmapping sizes
not congruent with a whole superpage size (i.e: 256 KiB, more than a
page, less than a superpage) wouldn't be, as far as the guest is
concerned.

But if my understanding above is correct maybe it doesn't matter? It
only needs to be atomic wrt the hypercall that requests it, so that the
gfn is never reused while the guest p2m still holds that mfn.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri May 09 09:50:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 09:50:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980032.1366519 (Exim 4.92)
	(envelope-from )
	id 1uDKMi-00022w-B1; Fri, 09 May 2025 09:50:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980032.1366519; Fri, 09 May 2025 09:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDKMi-00022p-7J; Fri, 09 May 2025 09:50:00 +0000
Received: by outflank-mailman (input) for mailman id 980032;
 Fri, 09 May 2025 09:49:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDKMg-00022c-I8
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 09:49:58 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f7a232a2-2cba-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 11:49:58 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43cf680d351so17242685e9.0
 for ; Fri, 09 May 2025 02:49:57 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f5a2d2ffsm2728434f8f.66.2025.05.09.02.49.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 02:49:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f7a232a2-2cba-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746784197; x=1747388997; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=nzvbxjWCS0bq4DYfefGSPkiapTF0LxCWSipqGE8AtWQ=;
        b=qjnLB6Zn21jBS3qBM/ig6FwUhm5Q0Gmc/UidRGNUqDm5BNbc3ZFFgC0n4aN4Eg5Low
         VkTSgU2ZqgbmIEXIfLaMlgWWeKZ3OcZvF5+UBiLW1xBXZmO+/6VpvqF6OzcYmiOumg4t
         NdZlNeT4qARtJk/fovHik/5RqwMyFioiH8TlQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746784197; x=1747388997;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nzvbxjWCS0bq4DYfefGSPkiapTF0LxCWSipqGE8AtWQ=;
        b=oO72qBmyPv0hyO0seN08e4oUrzArHkrffLPXBvW+day5xCOBIWgyrihMNOAAbCt4FN
         1Ge98MvF9DPw+ATYIRcPfDklwM0WGCkw/2/eoyu0HYmru9JGG62gKaWlqkxkl4rHT90M
         kBmVMIH+A8yFRHrTWH2qRYB9kbO07kVPNAzVGs9gHGvbO0uHbKp5MMXjRTepUtllOm8H
         6tmcu7825hswmtGtOiykC7JDy0Fxa2ywIfiS+lcBv0mdRsJ0jS6L0IQWswbjgaC8cML0
         kkdWGTyUXtPcoF/lkCmKBgRvoc+uJCd3QrSdqSs0nPj858uKlYrB4zj4bjASS95iTQOI
         UtZQ==
X-Gm-Message-State: AOJu0YxOoy1Da1Y0IOUENovE3B3Z+ypwAofL3UQ+LcIzcM+WHhrf26wZ
	gWhoIRfIqpsvc1Mz7WQtYK+wtY6r79WSUPDRbsiLS/983t8/xDZypySQ9FFnjpw=
X-Gm-Gg: ASbGncv+cLfeAqlSViGcQt9+fYy90N5UMA46dGSc0MjTgb9yPoOqBUBzH5HcyjqHU7D
	FVpjPC4TfpHks0mDiL40epoUxk8gRJ26wagmnE2/st039gPxa5KOeqQlILK3r57rJ+zxgQfTO5w
	+A5mQV9Gt00SXaq/vYNYdgfSnF8oo6d3iVJ9psT3mER8IrezvGAJp24T765TNV3mKJ0NxhbKrlr
	q9opyJd9tw7tXuUAOTK8GdvyoRobjk245d8a/3Iw19+Oi5MtvqfMajB5p3KElZoiHo7knbbKmTJ
	6KLCBICPDypWB4Nfky2+5NPKhNAFnVeCzK7AjfdbSKxt/FjOvAhmqrqto689VcJ8X5UvMV0xXFZ
	ZT0/+Fw==
X-Google-Smtp-Source: AGHT+IG0sjDYdeR4inxYK4Cfik9it5dKDO8mVFLsoI5VT0f4AoV7jCB79T+xZOuibhh4GiMW/KTprA==
X-Received: by 2002:a5d:64e2:0:b0:3a1:d06c:4e5c with SMTP id ffacd0b85a97d-3a1d06c4ee3mr3330521f8f.26.1746784197253;
        Fri, 09 May 2025 02:49:57 -0700 (PDT)
Message-ID: <91b5d36c-4eac-4167-a778-923dc39c02be@citrix.com>
Date: Fri, 9 May 2025 10:49:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/Kconfig: Improve help test for speculative options
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , Stefano Stabellini 
References: <20250508160336.2232152-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

On 09/05/2025 9:14 am, Roger Pau Monné wrote:
> On Thu, May 08, 2025 at 05:03:36PM +0100, Andrew Cooper wrote:
>> The text for CONFIG_INDIRECT_THUNK isn't really correct, and was already stale
>> by the time speculative vulnerabilities hit the headlines in 2018.  It is
>> specifically an out-of-line-ing mechansim, and repoline is one of several
>> safety sequences used.
>>
>> Some of this boilerplate has been copied into all other options, and isn't
>> interesting for the target audience given that they're all in a "Speculative
>> Hardning" menu.
>>
>> Reword it to be more concise.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper 
> Acked-by: Roger Pau Monné 
>
> You are the expert on those things :).
>
>> ---
>> CC: Anthony PERARD 
>> CC: Michal Orzel 
>> CC: Jan Beulich 
>> CC: Julien Grall 
>> CC: Roger Pau Monné 
>> CC: Stefano Stabellini 
>>
>> CONFIG_SPECULATIVE_HARDEN_BRANCH really ought to be named
>> CONFIG_SPECULATIVE_HARDEN_CONDITIONAL, but this would be a (minor) functional
>> change.
> I don't have a strong opinion either way TBH.  Would you maybe like to
> rename the menu visible text to "Speculative Conditional Branch Hardening"?

Hmm yeah, that's better than nothing.

>
>> ---
>>  xen/common/Kconfig | 51 +++++++++-------------------------------------
>>  1 file changed, 10 insertions(+), 41 deletions(-)
>>
>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>> index 4bec78c6f267..03ef6d87abc0 100644
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -162,29 +162,21 @@ config STATIC_MEMORY
>>  menu "Speculative hardening"
>>  
>>  config INDIRECT_THUNK
>> -	bool "Speculative Branch Target Injection Protection"
>> +	bool "Out-of-line Indirect Call/Jumps"
>>  	depends on CC_HAS_INDIRECT_THUNK
>>  	default y
>>  	help
>> -	  Contemporary processors may use speculative execution as a
>> -	  performance optimisation, but this can potentially be abused by an
>> -	  attacker to leak data via speculative sidechannels.
> It would be nice if this boilerplate text could be made the "help" of
> the top level menu entry, but that's not possible with Kconfig.

When speculation was entirely new, something needed to introduce it (not
that I think this was great to start with), but nowadays any all
developers/sysadmins/distro-packagers will be aware of it.

Or, if they're not aware, a paragraph like this isn't going to help them.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 09 10:50:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 10:50:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980055.1366532 (Exim 4.92)
	(envelope-from )
	id 1uDLIu-0002r5-GX; Fri, 09 May 2025 10:50:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980055.1366532; Fri, 09 May 2025 10:50: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 1uDLIu-0002qy-Dd; Fri, 09 May 2025 10:50:08 +0000
Received: by outflank-mailman (input) for mailman id 980055;
 Fri, 09 May 2025 10:50:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDLIt-0002qs-1P
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 10:50:07 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5e01014d-2cc3-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 12:50:05 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43cf257158fso12967255e9.2
 for ; Fri, 09 May 2025 03:50:05 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a1f58f2961sm2855610f8f.45.2025.05.09.03.50.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 03:50:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5e01014d-2cc3-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746787805; x=1747392605; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=FjIqqJel1+4NNYYXuRdtjsXhMEIDc9qYF/U8D65cpog=;
        b=ONlCtr8y2tC8EhzJrzrVl4nlo6KjEFC0cKp8joPDodYNkwmT7S9b941mcjw4C1ukWK
         iHC5c0cVw3ZRbJiO+4lQNVZhhJmXrThMrjhp95VVn8Oh3+0gZr31mQSwiQOJ/FD6eYP3
         x7LYa8aE0TSoNzXM4h5Nwwa/y0hVDhvUPFric=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746787805; x=1747392605;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=FjIqqJel1+4NNYYXuRdtjsXhMEIDc9qYF/U8D65cpog=;
        b=B4keBgBJJPVcv7H7bikJ4/Wc4vQYtV+GsLmka7kNKRa920K+Z5/8PdZOqvD6vgdf+E
         3AxeUx4CFunJTo0rUkZvTXMYhlp7XLN+fOhvGPfZJeRvIB+UjSIvbRzdB6ScylVlVivu
         9Xterj6haoUToDBjCDT2hKfOE5oyfe2MwcWLXoCxbD+P8oIboPF9m80j26qtMckOCdRr
         guyhNC3+I5fWKTV+CXcKmDxwaMIQpmU258+SWOuff+wswmuSVHN+0tro501a6ICaPJ3l
         RPDptNLtMaYpYDMSZxpL+KVbJByrqT184pSW2kRlgApo5hXp8v9mmNmvA92K4dktK/wx
         litw==
X-Forwarded-Encrypted: i=1; AJvYcCXtxvSKNdLykFnhR7ZMRRtcyUvx7yvfKXlzgRj2aaJBZDXp0fy32RHzvUVIO7Mb4Xp7CbserQlQKJ4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwbV4gFeEd8Yaotlw9oNVMhNlXbxj/22/ZYTU4W9tRsf5Qy6GWV
	hV5ItIQsterdvBEW1uvRqGLqleHptf0fp5u+MHgkFBquuDH0dv00hTleid4BiS8=
X-Gm-Gg: ASbGncuLwd042uxhiIuCPkL2G9addrIF+BrIVUCaVTtUF7Tr5760F+bLRthYvCk8W1m
	d2cu2YtDTVO3NqzwMZlB26jiw+WQotA295M448oycX5rNDPSGpqdFT1bdbp5fw7M1RfADI3ea0l
	4BkJAWPRHJHidA/SNjVOjzWCxhxVQ35Wr2E4hquELMaw0viVN2z3u5fQpfLA2jc+y1hBbmmLbOB
	JRBZzibyN23nRG4Tz+dP4sA5TN22R8NuEekRy9ObcZivdv8F7JVQLhFPAoHp5Z3TKhqBtlBFz+b
	uX2MfV8iTW9d0ppBztsoBxQQ5+LwXuyco9nE1E/AoM88wA==
X-Google-Smtp-Source: AGHT+IGyHMp5LBetRR3pOIoQzV/u48nYBSP967mk/UeC22N94UEMO60s/S34SR3X9zqHAen9HNO+mQ==
X-Received: by 2002:a05:6000:200d:b0:3a0:be75:1bb1 with SMTP id ffacd0b85a97d-3a1f647ffe8mr2023809f8f.42.1746787805007;
        Fri, 09 May 2025 03:50:05 -0700 (PDT)
Date: Fri, 9 May 2025 12:50:00 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Alejandro Vallejo 
Cc: Demi Marie Obenour ,
	Xenia Ragiadakou ,
	Stefano Stabellini ,
	Xen developer discussion ,
	Andrew Cooper ,
	Juergen Gross ,
	Xen-devel 
Subject: Re: Mapping memory into a domain
Message-ID: 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Fri, May 09, 2025 at 11:47:36AM +0200, Alejandro Vallejo wrote:
> >>>>> A Linux driver that needs access to userspace memory
> >>>>> pages can get it in two different ways:
> >>>>>
> >>>>> 1. It can pin the pages using the pin_user_pages family of APIs.
> >>>>>    If these functions succeed, the driver is guaranteed to be able
> >>>>>    to access the pages until it unpins them.  However, this also
> >>>>>    means that the pages cannot be paged out or migrated.  Furthermore,
> >>>>>    file-backed pages cannot be safely pinned, and pinning GPU memory
> >>>>>    isn’t supported.  (At a minimum, it would prevent the pages from
> >>>>>    migrating from system RAM to VRAM, so all access by a dGPU would
> >>>>>    cross the PCIe bus, which would be very slow.)
> >>>>
> >>>> From a Xen p2m this is all fine - Xen will never remove pages from the
> >>>> p2m unless it's requested to.  So the pining, while needed on the Linux
> >>>> side, doesn't need to be propagated to Xen I would think.
> 
> It might still be helpful to have the concept of pinning to avoid them
> being evicted for other reasons (ballooning?). I don't think it'd be
> sane to allow returning to Xen a page that a domain ever shared with a
> device.

If mapped using the p2m_mmio_direct type in the p2m a domain won't be
able to balloon them out.  It would also be misguided for a guest
kernel to attempt to balloon out memory that I presume will be inside
of a PCI device BAR from the guest point of view.

> re: being requested. Are there real promises from Xen to that effect? I
> could make a hypervisor oversubscribing on memory that swaps non-IOVA
> mem in and out to disk, moving it around all the time and it would be
> compliant with the current behaviour AIUI, but it wouldn't work with
> this scheme, because the mfn's would be off more often than not.

Even if Xen supported domain memory swapping, that could never be used
with domains that have devices attached, as it's not possible to fixup
the p2m on IOMMU fault and retry the access.

Not sure you could even move mfns around, as you would need an atomic
way to copy the previous page contents and set the PTE to point to the
new page.

Unless you want to get into a (IMO) complicated scheme where the
domain notifies the hypervisor which ranges are being used for device
DMA accesses (and thus requires guest kernel changes), I think
swapping of guest memory when there are assigned devices is a no-go.

Xen has (or had? as I never actually seen it being used) a mechanism
to swap domain memory to a dom0 file (see tools/xenpaging.c).  However
more than one provider had mentioned to me that one feature they
particularly preferred of Xen over KVM is that it would never swap
guest memory.  Not sure if that's still the case, but some struggled
to prevent KVM from swapping guest memory, and got complains of
slowness from their tenants.

For the purposes of getting a prototype I would suggest that you
assume p2m memory cannot be randomly swapped out, unless requested by
either the guest or the control domain.

> >>>
> >>> If pinning were enough things would be simple, but sadly it’s not.
> >>>
> >>>>> 2. It can grab the *current* location of the pages and register an
> >>>>>    MMU notifier.  This works for GPU memory and file-backed memory.
> >>>>>    However, when the invalidate_range function of this callback, the
> >>>>>    driver *must* stop all further accesses to the pages.
> >>>>>
> >>>>>    The invalidate_range callback is not allowed to block for a long
> >>>>>    period of time.  My understanding is that things like dirty page
> >>>>>    writeback are blocked while the callback is in progress.  My
> >>>>>    understanding is also that the callback is not allowed to fail.
> >>>>>    I believe it can return a retryable error but I don’t think that
> >>>>>    it is allowed to keep failing forever.
> >>>>>
> >>>>>    Linux’s grant table driver actually had a bug in this area, which
> >>>>>    led to deadlocks.  I fixed that a while back.
> >>>>>
> >>>>> KVM implements the second option: it maps pages into the stage-2
> >>>>> page tables (or shadow page tables, if that is chosen) and unmaps
> >>>>> them when the invalidate_range callback is called.
> 
> I'm still lost as to what is where, who initiates what and what the end
> goal is. Is this about using userspace memory in dom0, and THEN sharing
> that with guests for as long as its live? And make enough magic so the
> guests don't notice the transitionary period in which there may not be
> any memory?
> 
> Or is this about using domU memory for the driver living in dom0?
> 
> Or is this about something else entirely?
> 
> For my own education. Is the following sequence diagram remotely accurate?
> 
> dom0                              domU
>  |                                  |
>  |---+                              |
>  |   | use gfn3 in the driver       |
>  |   | (mapped on user thread)      |
>  |<--+                              |
>  |                                  |
>  |  map mfn(gfn3) in domU BAR       |
>  |--------------------------------->|
>  |                              +---|
>  |              happily use BAR |   |
>  |                              +-->|
>  |---+                              |
>  |   | mmu notifier for gfn3        |
>  |   | (invalidate_range)           |
>  |<--+                              |
>  |                                  |
>  |  unmap mfn(gfn3)                 |
>  |--------------------------------->| <--- Plus some means to making guest 
>  |---+                          +---|      vCPUs pause on access.
>  |   | reclaim gfn3    block on |   |
>  |<--+                 access   |   |
>  |                              |   |
>  |---+                          |   |
>  |   | use gfn7 in the driver   |   |
>  |   | (mapped on user thread)  |   |
>  |<--+                          |   |
>  |                              |   |
>  |  map mfn(gfn7) in domU BAR   |   |
>  |------------------------------+-->| <--- Unpause blocked domU vCPUs

The guest vCPU will already pause on access if there's a p2m
violation, until the ioreq has completed and the vCPU execution can
resume.  That's in control of the ioreq server that handles the
request.

I don't know about the dom0 user-space part, but that's possibly of no
concern for the implementation side in Xen?

My understanding of the actions needed from the Xen side is:

 1. Map either RAM owned by the hardware domain or an MMIO page into
    a domain p2m.
 2. Remove entries from a domain p2m.
 3. Handle p2m violations resulting from guest accesses, using 1. and
    force a guest access retry (or emulate the access).

1. Can possibly be done with XEN_DOMCTL_memory_mapping and
XENMEM_add_to_physmap_batch, but as I understood it it's not ideal.
Demi would like a way to use the same hypercall to map either RAM or
IOMEM into a domain p2m.

2. What hypercall to use depends on how the memory is mapped.

3. ioreq servers will already get requests for accesses to unmapped
regions they have registered for.  If the access is to be retried we
need to expand ioreq interface a bit to handle this case.  Adding a
new ioreq state like STATE_IORESP_RETRY might be enough?  Maybe I'm
being naive though.

>  |                                  |
> 
> >>> - The switch from “emulated MMIO” to “MMIO or real RAM” needs to
> >>>   be atomic from the guest’s perspective.
> >> 
> >> Updates of p2m PTEs are always atomic.
> > That’s good.
> 
> Updates to a single PTE are atomic, sure. But mapping/unmapping sizes
> not congruent with a whole superpage size (i.e: 256 KiB, more than a
> page, less than a superpage) wouldn't be, as far as the guest is
> concerned.

I've assumed the question was towards PTE updates, as to whether
PTE entries where always consistent.

> But if my understanding above is correct maybe it doesn't matter? It
> only needs to be atomic wrt the hypercall that requests it, so that the
> gfn is never reused while the guest p2m still holds that mfn.

I think it only matters that the PTE is always consistent, either
mapped or unmapped (and thus generate an ioreq request on access when
unmapped).

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 09 11:25:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 11:25:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980065.1366543 (Exim 4.92)
	(envelope-from )
	id 1uDLqh-0006tU-Ur; Fri, 09 May 2025 11:25:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980065.1366543; Fri, 09 May 2025 11:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDLqh-0006tN-SF; Fri, 09 May 2025 11:25:03 +0000
Received: by outflank-mailman (input) for mailman id 980065;
 Fri, 09 May 2025 11:25:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDLqg-0006tC-1D
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 11:25:02 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20611.outbound.protection.outlook.com
 [2a01:111:f403:240a::611])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3bdf88c1-2cc8-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 13:24:57 +0200 (CEST)
Received: from DM6PR14CA0039.namprd14.prod.outlook.com (2603:10b6:5:18f::16)
 by PH0PR12MB7813.namprd12.prod.outlook.com (2603:10b6:510:286::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Fri, 9 May
 2025 11:24:51 +0000
Received: from DS3PEPF000099D5.namprd04.prod.outlook.com
 (2603:10b6:5:18f:cafe::62) by DM6PR14CA0039.outlook.office365.com
 (2603:10b6:5:18f::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.31 via Frontend Transport; Fri,
 9 May 2025 11:24:51 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS3PEPF000099D5.mail.protection.outlook.com (10.167.17.6) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 11:24:50 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 06:24:50 -0500
Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via
 Frontend Transport; Fri, 9 May 2025 06:24: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" 
X-Inumbo-ID: 3bdf88c1-2cc8-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lyWvZSoNUoMHKijHcMhnfh6pF48IqNXKvXudn/wqdHloom3Qf42Yey1VUsH1sgBabfOGFSZ7XkYZMuEj9lNWtcwrpb4PCj3dwJBKgvk/T/Fr8nu0OAmu5dXq0+SqZwW0FnxxMT1LNF95A4b38ka78yUKa0v7BIgxROQzL1qcOCNJxkcdAlSZ6ugpDjpLvD1Gd0s/hFCVOJ6u3aJi31G4TIj4gjEoJ/98bLa52ILx5sTgGCMIJKKLO6++URAgDPhg35CRLy4SVZUm3HStr5AKaOKSDYG3QXymhbOX8VdJNUASlWEgLs/Tdr8O34cr7vdgNptzUNVOEI4OrTcU/gD8ig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fZyp0GNbJksOPcIWZWqmgu1NYPhso8bddmHyo8chcVc=;
 b=ajEXH7STkKuxaI0ImID0AqFe7aCCa+nPMuJgOBwnHhn7kBaL0NA5zeGKcS70V3Yxo8fo0rGTxSbRU3oBOjR6hLkKjzVUR064WoTaG+SQEMpAqI3x74y566EnlrC7V48yrRVL2zZZFdtIPNuw3hatpftzoDRHLadDrJ6W5wGTSO0OX+y1gXMPdrSa7IEAVcc01RU2Lm0J9VG0ho6DYCGgHW9ZU4MHriuLm/IexxpUloTNkPY6Buq708TpV35a0kEkg2u9wGT1VWBUjvrxuRr0KDsTgRXdBl8K/fmYCtX+Mo9EgI4M86FRc4aG/cK+fQhRuU7nm3jOzA8LjV+w4045ug==
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=fZyp0GNbJksOPcIWZWqmgu1NYPhso8bddmHyo8chcVc=;
 b=CCOSC0JXarWFWwS6SRRlnSRQnyYlJDqaNGKKhbiuJFqJp/dW9gQXY4gJk8PT+Ozq4YUO44we+6nCMQgSmolgAxoehvf+BKquLV7ja9ZSLPHGj0zx06o/tIWc0YEIOQY15tu+mOAiWRUEHq/N4VnS4f3lska3FOk5eAUqRho4M3A=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Ayan Kumar Halder 
To: 
CC: Ayan Kumar Halder , Stefano Stabellini
	, Bertrand Marquis ,
	"Michal Orzel" , Artem Mygaiev 
Subject: [PATCH v3 1/2] docs: fusa: Define the requirements for XEN_VERSION hypercall.
Date: Fri, 9 May 2025 12:24:46 +0100
Message-ID: <20250509112447.2931909-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
Received-SPF: None (SATLEXMB03.amd.com: ayan.kumar.halder@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF000099D5:EE_|PH0PR12MB7813:EE_
X-MS-Office365-Filtering-Correlation-Id: 6cfaa00c-ae04-4366-594d-08dd8eec1d30
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?LIwssxKMsxOlYLzl/8H3LJ3GCLVVGhEhuea47TodAIAipk1fLq2aSVjOMfKr?=
 =?us-ascii?Q?iQaK+73rlhXL460lJaWjIcRPzVIwAK8tnbz6GU9KBZnJi3MFr4UKpBKIMCDQ?=
 =?us-ascii?Q?vtgyYlWUNZYLQ+m4v76Y0mOq5GBpAfy95Fzpw46HVOXackm1awKkUghBm4V8?=
 =?us-ascii?Q?sxcy8G1bHC7SEm063iXWNaiWaBFcAAGiI/0+b+b06v33khOLOYMLgs2lMrvg?=
 =?us-ascii?Q?sTaEUuo8ofOjXf5pXylrnn8/4FA/xdzFMWgkMpPgBMsJfWRVld0VtiBA4pmr?=
 =?us-ascii?Q?bxRIGmpeo1OLL1Gv9aq265Kv2OMQkKW3lAlN21rUPx0sRnXrPbxwB3W8OeWR?=
 =?us-ascii?Q?/wabbS96AGiFPn95mg7PPuyWbT5VCg1Y55DH8BlHSCE4jlA2UXyWulq7h8oc?=
 =?us-ascii?Q?KIaSkhTg+GVpTXpYCvuOxJUk1++G/d8pug7KOf6YcqBwYHxBgc8XaLWzeYdG?=
 =?us-ascii?Q?mhWcQQ8cULSnzNUBCoT96FOIYz4gI4F0TynhkNlAozUkMEo60cuRe3/xdzYg?=
 =?us-ascii?Q?q2sPd4/9KJqVkhBO+sZm0M7lrk+QHFd0bvb+aHdGtjJAkP8LDjhX64UUfHIN?=
 =?us-ascii?Q?A/tZgUdPPKPlF8VyX/OgI/CvR2NbniiZOT+fRGhUFE2q8DuFDzCKqmiJU2DH?=
 =?us-ascii?Q?0zNhFCc2C2wnRsr8dd7ZXbuQJgHKj4L+jsqUDNoomCjK4JEiEkJ9HAw4SdKV?=
 =?us-ascii?Q?nO25mzzHcoUuxTCVZg3f0FODJp9YegmoePiH6sNpzXOJjRBN0CvITyGemBwM?=
 =?us-ascii?Q?6PVqm768I9bfP06NALO6VAQwYtEdoDTAZPS4wbujzNAUkAgVxeysbbFnfyu4?=
 =?us-ascii?Q?Vq1ZN8YdEGwppl4PusF5htZukNppRLsgIpvszxVCDTsJb9sxvU6MlBADWsfB?=
 =?us-ascii?Q?C5UDPKA7y4yG6CdIci8oulhkeUaX8W9EJTssweNkTuik8OSysG5si15BmEjS?=
 =?us-ascii?Q?2HO3TNGVhNPB0Y1fjAv8M4Lw9y5v0PWJ0w0pPGBEX7s4ksv1jYfW43U4jsN4?=
 =?us-ascii?Q?WR1nQpXr+bjgaxR+2rApPuUQmSOQ4ccqhelBrfXzMdKkfz8v3zBY1JkubrF6?=
 =?us-ascii?Q?wyM+EYDHOms4BaBgbUIhcXZHguWGrFxy5DJYEhELhJCfQpLMLOkrLK0fHbYP?=
 =?us-ascii?Q?dKUwKWSqCQsX1GYo+KtW8o2YptVXqvvwOuqsJYPdSh9W1ZyHzUGwyNl3BMPk?=
 =?us-ascii?Q?F21E+Y4Csq/a6n6ZZcohcrhdesmm5lwmqmlAYkAookIe6cMgDyaaAhUdV2Gk?=
 =?us-ascii?Q?NgeCJecuBuomfeHRXCDYcQRavb/IDbaTMPM0cRpej6Hz/ds85PxUxfWFhWCv?=
 =?us-ascii?Q?lX52+Ee99+iaOBrrxQPXtvI/Q4zKqiOqsfGsQfIWX2Ehnq7NLnn6K7EeTmQ7?=
 =?us-ascii?Q?GtEKFWaBCD4SaGmQZAMEDTE+3Rf4qf4nFkN89YkrPZhtKl434KHpuB5ews6k?=
 =?us-ascii?Q?bm86VRDnGGpOLRIx1rd4h2wZ4ZD8vQgfnPTaZHpj4AiK2xGp9pwwRYxi+2VG?=
 =?us-ascii?Q?gJwpzf7edl9Bppy5gqhGO3JFTF9QVYtAjdUe?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 11:24:50.8821
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6cfaa00c-ae04-4366-594d-08dd8eec1d30
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF000099D5.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7813

Define the requirements which are common for all the commands for XEN_VERSION
hypercall.

Signed-off-by: Ayan Kumar Halder 
---
Changes from -

v1 - 1. Fixed `XenProd~version_hyp_ret_val~1` requirement as Xen does not return
0 for success in all the cases.
2. Reworded the requirements so as to write them from Xen's perspective (not
domain's perspective).

v2 - 1. Specified the register details.
2. Specified the type of buffer. 

 .../fusa/reqs/design-reqs/arm64/hypercall.rst | 58 +++++++++++++++++++
 docs/fusa/reqs/index.rst                      |  2 +
 docs/fusa/reqs/market-reqs/reqs.rst           | 16 +++++
 .../reqs/product-reqs/version_hypercall.rst   | 43 ++++++++++++++
 4 files changed, 119 insertions(+)
 create mode 100644 docs/fusa/reqs/design-reqs/arm64/hypercall.rst
 create mode 100644 docs/fusa/reqs/product-reqs/version_hypercall.rst

diff --git a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
new file mode 100644
index 0000000000..f00b0b00f9
--- /dev/null
+++ b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
@@ -0,0 +1,58 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Hypercall
+=========
+
+Instruction
+-----------
+
+`XenSwdgn~arm64_hyp_instr~1`
+
+Description:
+Xen shall treat domain hypercall exception as hypercall requests.
+
+Rationale:
+
+Comments:
+Hypercall is one of the communication mechanism between Xen and domains.
+Domains use hypercalls for various requests to Xen.
+Domains use 'hvc #0xEA1' instruction to invoke hypercalls.
+
+Covers:
+ - `XenProd~version_hyp_first_param~1`
+ - `XenProd~version_hyp_second_param~1`
+
+Parameters
+----------
+
+`XenSwdgn~arm64_hyp_param~1`
+
+Description:
+Xen shall use the first five cpu core registers to obtain the arguments for
+domain hypercall requests.
+
+Rationale:
+
+Comments:
+Xen shall read the first register for the first argument, second register for
+the second argument and so on.
+
+Covers:
+ - `XenProd~version_hyp_first_param~1`
+ - `XenProd~version_hyp_second_param~1`
+
+Hypercall number
+----------------
+
+`XenSwdgn~arm64_hyp_num~1`
+
+Description:
+Xen shall read x16 to obtain the hypercall number.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_first_param~1`
+ - `XenProd~version_hyp_second_param~1`
diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
index 1088a51d52..d8683edce7 100644
--- a/docs/fusa/reqs/index.rst
+++ b/docs/fusa/reqs/index.rst
@@ -10,5 +10,7 @@ Requirements documentation
    market-reqs/reqs
    product-reqs/reqs
    product-reqs/arm64/reqs
+   product-reqs/version_hypercall
    design-reqs/arm64/generic-timer
    design-reqs/arm64/sbsa-uart
+   design-reqs/arm64/hypercall
diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-reqs/reqs.rst
index 2d297ecc13..0e29fe5362 100644
--- a/docs/fusa/reqs/market-reqs/reqs.rst
+++ b/docs/fusa/reqs/market-reqs/reqs.rst
@@ -79,3 +79,19 @@ Comments:
 
 Needs:
  - XenProd
+
+Version hypercall
+-----------------
+
+`XenMkt~version_hypercall~1`
+
+Description:
+Xen shall provide an interface for the domains to retrieve Xen's version, type
+and compilation information.
+
+Rationale:
+
+Comments:
+
+Needs:
+ - XenProd
diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fusa/reqs/product-reqs/version_hypercall.rst
new file mode 100644
index 0000000000..400d51bbeb
--- /dev/null
+++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
@@ -0,0 +1,43 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Version hypercall
+=================
+
+First Parameter
+---------------
+
+`XenProd~version_hyp_first_param~1`
+
+Description:
+Xen shall treat the first argument (as an integer) to denote the command number
+for the hypercall.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
+
+Second Parameter
+----------------
+
+`XenProd~version_hyp_second_param~1`
+
+Description:
+Xen shall treat the second argument as a virtual address (mapped as Normal
+Inner Write-Back Outer Write-Back Inner-Shareable) to buffer in domain's
+memory.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 11:25:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 11:25:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980066.1366548 (Exim 4.92)
	(envelope-from )
	id 1uDLqi-0006wf-6I; Fri, 09 May 2025 11:25:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980066.1366548; Fri, 09 May 2025 11: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 1uDLqi-0006vm-1u; Fri, 09 May 2025 11:25:04 +0000
Received: by outflank-mailman (input) for mailman id 980066;
 Fri, 09 May 2025 11:25:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDLqg-0006tC-DL
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 11:25:02 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2413::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3bd4cf2f-2cc8-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 13:24:57 +0200 (CEST)
Received: from BL1PR13CA0337.namprd13.prod.outlook.com (2603:10b6:208:2c6::12)
 by BL1PR12MB5875.namprd12.prod.outlook.com (2603:10b6:208:397::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.20; Fri, 9 May
 2025 11:24:53 +0000
Received: from BL6PEPF0002256F.namprd02.prod.outlook.com
 (2603:10b6:208:2c6:cafe::2) by BL1PR13CA0337.outlook.office365.com
 (2603:10b6:208:2c6::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.19 via Frontend Transport; Fri,
 9 May 2025 11:24:53 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0002256F.mail.protection.outlook.com (10.167.249.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Fri, 9 May 2025 11:24:52 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 06:24:52 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 9 May
 2025 06:24:52 -0500
Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via
 Frontend Transport; Fri, 9 May 2025 06:24:51 -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" 
X-Inumbo-ID: 3bd4cf2f-2cc8-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=N/NME4193/5d7h3wMVrYSyoUtjN8PR6I4gCaGfBvTFO7+FFu+bMp8bTkd/5SGFKWqvphG7OiI+6FaQQIxYY0AopJli6Ak8L9XLicuwpMU1f/FgzCzfawkP6VD931REITpp5r6QRwl7jzMVJHvZ6zL9lriCulZv9NuEvBs/Wuh+uIQXDlh+Kzjq4W9Jt8vH3LFslX3cUrC9cqD8Bvd6Erx2QZEwDmHth1dTrbuIm0BihXUkCDkhPKDtQf8oHfPquLs34YwV8jRqdfXc4u8tWA30ZRnaRzqx16LumybeV9xP+HpPyoSH6wSFo6NPhclBa1bMIU2fBfOJyUCiz0+Rpfjg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WVKkUdt3hcJ9rnBcdLqTXtvfvnvp3XTzvanHy9lyaYo=;
 b=HcrTDJqTd5KXfSRZjBEqvDKqBgr2lDTLbop8besQYinv+2qAG35AEomWv4kT3iFBP5b7xhsEjyT7guf5GrjA3HTYAlQHnumNF9aQtig5bYcNoAgpcu1LEuha5ocfFdJqpEy+RZupc8gTOz+8UwUoJCM0N+lEZ9C/SW9paqyXH2vW1MKhio/MEnkwFxS3QfLCy9PsKjDG8lVEwsHFEwzVXLhRGfnp5bvOyESGS3cmg5lYaKEZGRO/avEzE9Et7ZnvoVgfTjyWkqi1paWRAx3J0VypZlm3CcBX3ZWNp1Wa1gLxtVLx+SNVh0KPDYhuqPUeMHIXxhpj5LLRFQTlUJVvvA==
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=WVKkUdt3hcJ9rnBcdLqTXtvfvnvp3XTzvanHy9lyaYo=;
 b=ak3Hl/Q2uGHTqWQFfa5PMrf1hxAAyFBarFZRoVa7FH0c2Nv5vi1YdlrBk1pIxTx5qtnysQ6pW1YGOPlTYogOX6LHgzL9tn61K2XK31nrGo+bZpTAZ7xMeW7ecmj8R3iJP+Dj73mBjahQ/Emmz9jxpoSc4ELZZh7ctFD2mVQBo9w=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Ayan Kumar Halder 
To: 
CC: Ayan Kumar Halder , Stefano Stabellini
	, Bertrand Marquis , Michal
 Orzel , Artem Mygaiev 
Subject: [PATCH v3 2/2] docs: fusa: Add the requirements for few commands of XEN_VERSION
Date: Fri, 9 May 2025 12:24:47 +0100
Message-ID: <20250509112447.2931909-2-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250509112447.2931909-1-ayan.kumar.halder@amd.com>
References: <20250509112447.2931909-1-ayan.kumar.halder@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0002256F:EE_|BL1PR12MB5875:EE_
X-MS-Office365-Filtering-Correlation-Id: 9b74b037-3dfb-4102-7cd8-08dd8eec1e59
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Ejn6ht6DRUd//9e75Gg4tWuPhk/JYTRE5ejFNssW8HcBmw1m2QyVPdnhHPfe?=
 =?us-ascii?Q?b49I2bkEIftJEoRlAiCUiFhQplUo2Nc7Hw1IOe/DhgifcvqI970OWrz/L9+G?=
 =?us-ascii?Q?nQ3rQ0TAnmxirBCtp7lgWFwK1rmb0RzLH2NlQJEalCIOe8c024hNEE0gH1dc?=
 =?us-ascii?Q?bXGbBlOLw3BbwFjs+BqYFLtmidbEtwD+NmSqCPt13uoZ3iNynC70ei2Avo6w?=
 =?us-ascii?Q?zyhXMbVfX/NlP9Ts+NTk94Ot83/8hc0veTKyvskDj3Ef6nBIM37si4+/1D7Q?=
 =?us-ascii?Q?jgeMVgT4VbP+9y0V7ZLxFdPRlw5UT8wK16GgVUD6oZQwVdFSTe6o29BiwYEY?=
 =?us-ascii?Q?zwrF4Ve2h/B16tsDfXQ6NQ4EMlsKxIiQfehnM41vEELfwH+Zsx2fXVeVckTL?=
 =?us-ascii?Q?vq1KmFqWJCBGykRNXfyHSXmMQvKt+WXjugrK5rhASi88kMkSuIug+y+lG/QK?=
 =?us-ascii?Q?PvHxZVljamSnDWgDvfZjk4f7kpY2amy3hq2mEVKB2jAEHv9vPuw1OiT6q71b?=
 =?us-ascii?Q?nBwkBYO22bk2cuBQ2NRPxYSKuwEbl61r2gkMB3gvi7ticEFePX7q/s3e9U2R?=
 =?us-ascii?Q?pmv9eAgDQmNFKZkpQHGVRO0Tpc6J5/6CEuaTIqZ4jyan3Yu+9/wg5IX5OZQI?=
 =?us-ascii?Q?AdGlgdKm4U1KyHQo8PCK0Hg3ElIi7l8tJ6KHiOHa+0u7vAQGzJZKvtu3X7KI?=
 =?us-ascii?Q?YaFwovcAfA0R4GlgC7Aq4fn3M9pXqymVtA4iXBxIlt6o3XgddiXvrXCVFfpX?=
 =?us-ascii?Q?ZEc3LGtD+pHXSMNFgtnvmfB3ugvBc8h4DNf2IOwvqXIM+xiOBFK5YKWmVNqd?=
 =?us-ascii?Q?9rk7mR0Utt/Gkepjkh16+lzVGRbR19rA672IMl4wWn15Cb41o2WAjr3ZiD16?=
 =?us-ascii?Q?+ntGTWcyb4xEt2f06Z/v39+chNXrFJc/BV4Xo9l6TaC1cVBIcQmxdOK0W9D9?=
 =?us-ascii?Q?9YqCTPmldL+n9GHudJ7/FQtkcU7L1podrOakqILguFERhwynftHL3UZdZQQi?=
 =?us-ascii?Q?AJ9YqxEDpmD6/aNYLVEkwZ1AE9PQ7gtQqSGKgA9W1t2PPTmwyCLPZOnjudG+?=
 =?us-ascii?Q?2MTC8AjtOSoZ6S/583kthbJKX/htaTpmPMzn1vwzLYXhHlJGhSgnA/Y9LNEi?=
 =?us-ascii?Q?8QO3C3Q7t7wSs4f/W3PQOzAwHcpevpF9H6qa+RDQmL9V3EIGXYrJaANOV3Xq?=
 =?us-ascii?Q?ZqYcNDEpr4Ic2bQQ1hX/iz9lwCIPfAsJRVROE+zvACh346NpE7f5WHG8l0+Q?=
 =?us-ascii?Q?qx57E9hRvIqMi46P5Lin3cnJNPgkrOUQrs54oVfWURB56woafThbhssflwf0?=
 =?us-ascii?Q?xJN/FJs7bfUXvnWJMoR5SOTfVvnTHCLQ4BLCbHZhIyqB9JgZzhiSXNz8xG4v?=
 =?us-ascii?Q?BnPjShvTqwFKbntu0EVfjo3jDIpKsTxdh/NXy9+2nJreHnSiHug9F6dnvIa5?=
 =?us-ascii?Q?A6IiIMwg2XmeDWDfiwumHt7jucc84qEa2oeGGuwaZbdaomxkjI5yPw=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2025 11:24:52.8634
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b74b037-3dfb-4102-7cd8-08dd8eec1e59
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF0002256F.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5875

Define requirements for specific commands.

Signed-off-by: Ayan Kumar Halder 
---
Changes from -

v1 - 1. Reworded the requirement so as to avoid mentioining variable names
or hardcoded strings. Otherwise, one would need to change the requirement
each time the code changes.

v2 - 1. Moved few changes to previous patch.

 .../fusa/reqs/design-reqs/arm64/hypercall.rst | 15 ++++
 .../design-reqs/arm64/version_hypercall.rst   | 34 ++++++++
 .../reqs/design-reqs/version_hypercall.rst    | 82 ++++++++++++++++++
 docs/fusa/reqs/index.rst                      |  3 +
 docs/fusa/reqs/product-reqs/hypercall.rst     | 20 +++++
 .../reqs/product-reqs/version_hypercall.rst   | 83 +++++++++++++++++++
 6 files changed, 237 insertions(+)
 create mode 100644 docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
 create mode 100644 docs/fusa/reqs/design-reqs/version_hypercall.rst
 create mode 100644 docs/fusa/reqs/product-reqs/hypercall.rst

diff --git a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
index f00b0b00f9..f58a9d50aa 100644
--- a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
+++ b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
@@ -56,3 +56,18 @@ Comments:
 Covers:
  - `XenProd~version_hyp_first_param~1`
  - `XenProd~version_hyp_second_param~1`
+
+Return value
+------------
+
+`XenSwdgn~arm64_ret_val~1`
+
+Description:
+Xen shall store the return value in first cpu core register.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~hyp_err_ret_val~1`
diff --git a/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
new file mode 100644
index 0000000000..3aa12ea2c2
--- /dev/null
+++ b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
@@ -0,0 +1,34 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Capabilities
+------------
+
+`XenSwdgn~arm64_capabilities~1`
+
+Description:
+Xen shall have an internal constant string to denote that the cpu is running
+in arm64 mode.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_capabilities_cmd~1`
+
+Capabilities AArch32
+--------------------
+
+`XenSwdgn~arm64_capabilities_aarch32~1`
+
+Description:
+Xen shall have a internal constant string to denote that the cpu is running in
+arm32 mode.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_capabilities_cmd~1`
+
diff --git a/docs/fusa/reqs/design-reqs/version_hypercall.rst b/docs/fusa/reqs/design-reqs/version_hypercall.rst
new file mode 100644
index 0000000000..aac5896965
--- /dev/null
+++ b/docs/fusa/reqs/design-reqs/version_hypercall.rst
@@ -0,0 +1,82 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Version
+-------
+
+`XenSwdgn~version~1`
+
+Description:
+Xen shall have a internal constant (XEN_VERSION) storing the version number
+coming from the Makefile.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_version_cmd~1`
+
+Subversion
+----------
+
+`XenSwdgn~subversion~1`
+
+Description:
+Xen shall have a internal constant (XEN_SUBVERSION) storing the sub version
+number coming from the Makefile.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_version_cmd~1`
+
+Error copying buffer
+--------------------
+
+`XenSwdgn~error_copy_buffer~1`
+
+Description:
+Xen shall return -EFAULT if it is not able to copy data to domain's buffer.
+
+Rationale:
+-EFAULT is one of the error code defined in
+http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/errno.h.
+
+Comments:
+
+Covers:
+ - `XenProd~hyp_err_ret_val~1`
+
+Extraversion
+------------
+
+`XenSwdgn~extraversion~1`
+
+Description:
+Xen shall have a internal constant (XEN_EXTRAVERSION) storing the extraversion
+coming from the build environment.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_extraversion_cmd~1`
+
+Changeset
+---------
+
+`XenSwdgn~changeset~1`
+
+Description:
+Xen shall have a internal constant string (XEN_CHANGESET) storing the date,
+time and git hash of the last change made to Xen's codebase.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenProd~version_hyp_changeset_cmd~1`
diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
index d8683edce7..de19b0cda2 100644
--- a/docs/fusa/reqs/index.rst
+++ b/docs/fusa/reqs/index.rst
@@ -11,6 +11,9 @@ Requirements documentation
    product-reqs/reqs
    product-reqs/arm64/reqs
    product-reqs/version_hypercall
+   product-reqs/hypercall
    design-reqs/arm64/generic-timer
    design-reqs/arm64/sbsa-uart
    design-reqs/arm64/hypercall
+   design-reqs/arm64/version_hypercall
+   design-reqs/version_hypercall
diff --git a/docs/fusa/reqs/product-reqs/hypercall.rst b/docs/fusa/reqs/product-reqs/hypercall.rst
new file mode 100644
index 0000000000..b57b9acde8
--- /dev/null
+++ b/docs/fusa/reqs/product-reqs/hypercall.rst
@@ -0,0 +1,20 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Error Return Value
+------------------
+
+`XenProd~hyp_err_ret_val~1`
+
+Description:
+In case the hypercall fails, Xen shall return one of the error codes defined
+in http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/errno.h.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fusa/reqs/product-reqs/version_hypercall.rst
index 400d51bbeb..2ef1c4f9ca 100644
--- a/docs/fusa/reqs/product-reqs/version_hypercall.rst
+++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
@@ -41,3 +41,86 @@ Covers:
 
 Needs:
  - XenSwdgn
+
+Version command
+---------------
+
+`XenProd~version_hyp_version_cmd~1`
+
+Description:
+Xen shall provide a command (num 0) for  hypercall (num 17) to retrieve Xen's
+version in the domain's register 0.
+
+Rationale:
+
+Comments:
+Xen version is composed of major and minor number.
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
+
+Extraversion command
+--------------------
+
+`XenProd~version_hyp_extraversion_cmd~1`
+
+Description:
+Xen shall provide a command (num 1) for hypercall (num 17) to copy its
+extraversion in the domain's buffer.
+
+Rationale:
+
+Comments:
+Xen's extra version consists of a string passed with 'XEN_VENDORVERSION' command
+line parameter while building Xen.
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
+
+Capabilities command
+--------------------
+
+`XenProd~version_hyp_capabilities_cmd~1`
+
+Description:
+Xen shall provide a command (num 3) for hypercall (num 17) to copy its
+capabilities to the domain's buffer.
+
+Rationale:
+
+Comments:
+Capabilities related information is represented by char[1024].
+For Arm64, the capabilities should contain "xen-3.0-aarch64" string.
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
+
+Changeset command
+-----------------
+
+`XenProd~version_hyp_changeset_cmd~1`
+
+Description:
+Xen shall provide a command (num 4) for hypercall (num 17) to copy changeset
+to the domain's buffer.
+
+Rationale:
+
+Comments:
+Changeset is string denoting the date, time and git hash of the last change
+made to Xen's codebase.
+
+Covers:
+ - `XenMkt~version_hypercall~1`
+
+Needs:
+ - XenSwdgn
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri May 09 15:05:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 15:05:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980101.1366571 (Exim 4.92)
	(envelope-from )
	id 1uDPHc-0007ME-36; Fri, 09 May 2025 15:05:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980101.1366571; Fri, 09 May 2025 15:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDPHb-0007M7-W1; Fri, 09 May 2025 15:05:03 +0000
Received: by outflank-mailman (input) for mailman id 980101;
 Fri, 09 May 2025 15:05:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDPHa-0007M1-TJ
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 15:05:02 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f33883bb-2ce6-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 17:04:48 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43cf3192f3bso21914005e9.1
 for ; Fri, 09 May 2025 08:04:48 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f57ddfbesm3567684f8f.10.2025.05.09.08.04.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 08:04: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" 
X-Inumbo-ID: f33883bb-2ce6-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746803088; x=1747407888; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3Pp05axnEvIXhS9aw/LAwTaf5wYKSoDVSSbRDg50040=;
        b=Y785sNF7Xj92ghiisOrsobnZnvEONqz4KV/gRBV7lfJzwXj5UdKmmy2UGHXC/RLwKY
         NW46CY7gL8Q2zNVf9CqbDn44OiHmj1DVoJwJmvOPm5qJKk40KAqGVdRoW5AIU+6lWIaw
         4r9i2/NSAnnmqdKL4vDgbwFxnTCqhKpsCI6dg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746803088; x=1747407888;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3Pp05axnEvIXhS9aw/LAwTaf5wYKSoDVSSbRDg50040=;
        b=TNB0dOo9nP18tmNTRQ+4jpkkDLuWFoajhZgRDbjrt84mJQBF9hQNGO3TMl5T3so2jb
         n94V79M+cowDMbtrWoFZl5o92KcySE+Hvxw+WFql60kP+NMjRlQLb6aBSN42brzS+/dR
         9l88Q4a/qtQhnePTKhQJfRRjDTPaZo/TN7NY4ltX3uKvJiGCwGsxhg/SSSWoTVm0ZtHQ
         DbKStdhc7nCPCcWKg3jJf4ljtOLB/Pq0G3Z7Dp5UOFDJk3uImMK5LJ3z0UPGIJoTjtGZ
         4JbFqRB/cFiJh6pUXznvuUsKsdh7Q223qNO2TWrahS4BEJ9O7Ff4YBktYCbiqNka7VIn
         vCAQ==
X-Forwarded-Encrypted: i=1; AJvYcCWXa/Dw0kCYxiXfc49XvJQXM0Q7EVqVU6qT/lxikEf4Rq93XUl1NZ/VSGZ/Zik8SIIQWEh8Otl9vaw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyu/DEsAGObW7ad2TGucVkjoGcGftp1B0BdUPAccgi7RM9LVxcx
	mE8qaHy4uazmFBkJHPMsvvXBHWcTqPxbcfMNXoo9S42RBN89sBaaFQ+RiNsgebY=
X-Gm-Gg: ASbGncvt1HOYRS59xQEFlIOmuwHpXhPP3tYNK3SX7yVXu4tsk6D6yLjvrMB0BNg5UtC
	cNChsWbgQ2NDvsSfyOI7CUyw2908jshPH+FQsHf2AySng3jSxBMC/zIiqW8MHJqGSvq1rIsybc/
	ZntQnt0ey6KyaCwpXsOExjBrrP4Tl9eYDhrMH2mUV7X08g3+2GH+zM5J9S2+aVesDn1wK1QLZHi
	f193BSzYyH783khYtVi8Q7dSw+bvJ3vhgKNauUYG5y3pxsa9tpmbiJhz2a5UApmLRDekXqnLgIo
	Xfj9JXZCexY8IRIY6VnqLpoX8FhLW13KiCH3/Pi5Wy+3AnfoXy/W5g5ppBkwSAugeQkyrPyRhRz
	ygZGHnA==
X-Google-Smtp-Source: AGHT+IFbapsardf1+monZzUDobM3q/zFDCXxMT5SK/hfWNfP5ocX3lPsjlpBSfKsDFGlFdDc/bLP2A==
X-Received: by 2002:a05:6000:178e:b0:391:4889:5045 with SMTP id ffacd0b85a97d-3a1f649be24mr2759578f8f.36.1746803087685;
        Fri, 09 May 2025 08:04:47 -0700 (PDT)
Message-ID: 
Date: Fri, 9 May 2025 16:04:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/4] Allows Secure Boot for Kexec
To: Frediano Ziglio , xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250507094253.10395-1-freddy77@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: <20250507094253.10395-1-freddy77@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07/05/2025 10:42 am, Frediano Ziglio wrote:
> Ross Lagerwall (4):
>   xen/lib: Export additional sha256 functions
>   kexec: Include purgatory in Xen
>   kexec: Implement new EFI load types
>   kexec: Support non-page-aligned kexec segments

I realise a lot of this is coming from kexec-tools and/or Linux, but it
looks very very mad.

>From patch 1, we're embedding this in Xen:

xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
-rw-r--r-- 1 andrew andrew 30K May  9 15:24 purgatory.ro

yet -Wa,--strip-local-absolute alone halves the size:

xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
-rw-r--r-- 1 andrew andrew 17K May  9 15:25 purgatory.ro

Looking at purgatory itself, we enter at purgatory_start, load a local
GDT, set up a local stack, call into C for the hashing (and nothing
else), then jmp to entry64...

... which loads a (different) local GDT, (different) local stack, loads
the GPRs and then jumps into the new kernel.

Combined with kexec_reloc(), that's 3x we change GDT and stack in
several hundred instructions.


Looking further at patch 2, we only set up 3 GPRs; %rip, %rsp and %rdi
pointing the parameter block.

Patch 2 also contains an a large amount of EFI-editing logic (all
vulnerable to XSA-25), which AFAICT exists only because purgatory is
built non-PIC and wants relocating.  I can't see any external
references, or anything that couldn't be resolved at link time for a PIC
build.


There are two things which purgatory does which Xen doesn't currently
cater for:

1) Setting up the GPRs in that manner
2) The digest checks

#1 is very easy to fix and can probably even be done on the current ABI
(older Kexecs using purgatory won't care), and #2 ought to be easy too
by extending machine_kexec().  We can do the digest checks
unconditionally (it's a sensible check irrespective).

I think that removes the majority of this series, with no loss in
functionality?

Given that we're leaving the signature check to the dom0 kernel (which
is TCB and therefore can in the UEFI-SB model), we just might be able to
get away without any hypercall changes at all?

Thoughts?

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 09 15:06:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 15:06:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980108.1366581 (Exim 4.92)
	(envelope-from )
	id 1uDPJQ-0007qM-E7; Fri, 09 May 2025 15:06:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980108.1366581; Fri, 09 May 2025 15: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 1uDPJQ-0007qF-Av; Fri, 09 May 2025 15:06:56 +0000
Received: by outflank-mailman (input) for mailman id 980108;
 Fri, 09 May 2025 15:06:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDPJO-0007q3-LY
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 15:06:54 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3dd721bd-2ce7-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 17:06:53 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-43d04ea9d9aso12346625e9.3
 for ; Fri, 09 May 2025 08:06:53 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f57ddd5esm3481753f8f.6.2025.05.09.08.06.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 08:06: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" 
X-Inumbo-ID: 3dd721bd-2ce7-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746803213; x=1747408013; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=woMqZGKCr5yftOBKrZ28Zuc7Gp/g1ahjYQi4FND/Frw=;
        b=Z/g8tZQ+SNH6orImE5LZsde+ERR1Np7be7DPunVAzxDax9wGMU9LFyp+QiPwzKSagc
         VoGosYSl8ZXWTRp/ShRwJ69JlWcTkB8CJQ8HbUqQY/pbBGRDT12W38Z69/Q0GcRNibkf
         wWSAT6rPeT3Q2NaFWLMKKG8JRU1TY9OEQdKto=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746803213; x=1747408013;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=woMqZGKCr5yftOBKrZ28Zuc7Gp/g1ahjYQi4FND/Frw=;
        b=d43hZ6XO1K4U2r9uubtQk+SFeasvxZH+mPTHbvGruD7G8QEE5An4tVulkMt+ekkKtF
         StNTbFJ3Q7zg/FsiQyBKROPZMMHiqCfrAVBDK0Ik6lExJVIxx5oRKj06xax2V8ys2Qgv
         FD2SPUGfJhoEyr1fhxpgL5Vh/Z3Rwzusm808Q25gdEQd3oE0RhXRHLaFIRBdBFMz6BsH
         E3orIUOnF//fm20CXEEi6n4XEiRi+WRe+KLRD1uhZin8arQI0CUYXMeiLCOH8+j/8tVp
         rhc2Uj02+qbb06VXfK6r0EfjSrmlCxIhNKWUTMWZq100TB1hp3uwiZTkMrwZCtp6qE/Z
         Kjbg==
X-Forwarded-Encrypted: i=1; AJvYcCW4G+moeQQkfmJ01aERNL6ciZ5AwqeGz85RRNG76zWT8NT2JPvzXqtdVydhQXs/f1gEtiqxLS5YqeU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxtGDb1Qam1AxF44GWHj+/LZBuKD7mSvuLF6jYS3HRxmMlmAeZk
	EU0q6TdQx/HvQ2Br0ZMzBX0XMMO2Z7qIRV9K78YQ9dVS8e0HWqxmaUaRM3m92AA=
X-Gm-Gg: ASbGnctfadXv4VGdTm7cSp8VYAIf9x6DphuitrOqLgoj8Vavc2+jbBi3jCnebW2M6aB
	Co3P1DP7pD4R3N3/dooDJdEfuLQHpPP7VZwh+rfqXcWJ73KyeejRSKvBEe97VlmiiFnY3SwiO5k
	OPxPHMOm+07DYjbKnejwDMYIygi1u4F/HEhjgvQl6ASt1SJR7MAHQPfuOahXzeBrR6DMLB6RH/I
	fR6wL2cyA6FL5OGEsafAnZo33xdQwkNMMUuhcjRS8OeQtQ5pU/DMS1vWk6xO7mLEaUMVX0GiaDL
	DhQaCYggmmjyoTj9MEBSyEuXKbY/hT18uSGZ71gFIrGHLu0V1qDNqCb+dbJUjqqBechOZsjp3Ss
	H6NZFtA==
X-Google-Smtp-Source: AGHT+IHV5QYRzhy5eiFa9DOlj09Sqt/BL+AHbIY9cP46TPmZS1co0Ul5f9vJsRcsRZXjHRGuMjagwA==
X-Received: by 2002:a05:6000:4020:b0:3a1:2df6:822c with SMTP id ffacd0b85a97d-3a1f64898dbmr3259912f8f.31.1746803213021;
        Fri, 09 May 2025 08:06:53 -0700 (PDT)
Message-ID: 
Date: Fri, 9 May 2025 16:06:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/4] Allows Secure Boot for Kexec
From: Andrew Cooper 
To: Frediano Ziglio , xen-devel@lists.xenproject.org
Cc: Frediano Ziglio ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250507094253.10395-1-freddy77@gmail.com>
 
Content-Language: en-GB
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

On 09/05/2025 4:04 pm, Andrew Cooper wrote:
> On 07/05/2025 10:42 am, Frediano Ziglio wrote:
>> Ross Lagerwall (4):
>>   xen/lib: Export additional sha256 functions
>>   kexec: Include purgatory in Xen
>>   kexec: Implement new EFI load types
>>   kexec: Support non-page-aligned kexec segments
> I realise a lot of this is coming from kexec-tools and/or Linux, but it
> looks very very mad.
>
> From patch 1, we're embedding this in Xen:
>
> xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
> -rw-r--r-- 1 andrew andrew 30K May  9 15:24 purgatory.ro
>
> yet -Wa,--strip-local-absolute alone halves the size:
>
> xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
> -rw-r--r-- 1 andrew andrew 17K May  9 15:25 purgatory.ro
>
> Looking at purgatory itself, we enter at purgatory_start, load a local
> GDT, set up a local stack, call into C for the hashing (and nothing
> else), then jmp to entry64...
>
> ... which loads a (different) local GDT, (different) local stack, loads
> the GPRs and then jumps into the new kernel.
>
> Combined with kexec_reloc(), that's 3x we change GDT and stack in
> several hundred instructions.
>
>
> Looking further at patch 2, we only set up 3 GPRs; %rip, %rsp and %rdi
> pointing the parameter block.
>
> Patch 2 also contains an a large amount of EFI-editing logic (all
> vulnerable to XSA-25), which AFAICT exists only because purgatory is
> built non-PIC and wants relocating.  I can't see any external
> references, or anything that couldn't be resolved at link time for a PIC
> build.
>
>
> There are two things which purgatory does which Xen doesn't currently
> cater for:
>
> 1) Setting up the GPRs in that manner
> 2) The digest checks
>
> #1 is very easy to fix and can probably even be done on the current ABI
> (older Kexecs using purgatory won't care), and #2 ought to be easy too
> by extending machine_kexec().  We can do the digest checks
> unconditionally (it's a sensible check irrespective).
>
> I think that removes the majority of this series, with no loss in
> functionality?
>
> Given that we're leaving the signature check to the dom0 kernel (which
> is TCB and therefore can in the UEFI-SB model), we just might be able to
> get away without any hypercall changes at all?
>
> Thoughts?

Sorry, one extra thing.  By doing the digest check in machine_kexec(),
we can also inform the user that the kexec kernel looks corrupt, and we
won't be entering it.  (And probably try to reboot rather than hanging too.)

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 09 15:34:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 15:34:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980121.1366591 (Exim 4.92)
	(envelope-from )
	id 1uDPk6-0003QM-Cn; Fri, 09 May 2025 15:34:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980121.1366591; Fri, 09 May 2025 15:34: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 1uDPk6-0003QF-9p; Fri, 09 May 2025 15:34:30 +0000
Received: by outflank-mailman (input) for mailman id 980121;
 Fri, 09 May 2025 15:34:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDPk4-0003Q9-UG
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 15:34:28 +0000
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com
 [2607:f8b0:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 16198178-2ceb-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 17:34:25 +0200 (CEST)
Received: by mail-ot1-x32e.google.com with SMTP id
 46e09a7af769-72c13802133so683860a34.3
 for ; Fri, 09 May 2025 08:34: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" 
X-Inumbo-ID: 16198178-2ceb-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1746804864; x=1747409664; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EEb3n+AnLRJh3/D+uWgQdzBFV3lozOyknEcM+qmfC40=;
        b=OJm7RC80qdB57+oaAytogKEuiywPbsiJgvF7CjCdhqQoPOQfxIJn0hDd2zf87cej3n
         UA4NDf7BuYW2/NnbBNSanEIIlZaAaSwuD1f+0QLEweb3M1pr4eAwydZyrIKkH1OT/F4F
         giC4jAoSk1+/sI37odG+v033bCWhGAA5pkSLg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746804864; x=1747409664;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=EEb3n+AnLRJh3/D+uWgQdzBFV3lozOyknEcM+qmfC40=;
        b=HigCbx0CY6tcWe0HLqxvEWZakjUNWzAwj2l7nTNCdBWNr32UKiUP0OkoWFI7pppUgQ
         C5Y9AsfIXYMyjrxPZkmWCmhST9rdJ38liQOfnQXgvHvxQ0ufO3cMw00qCTqCE7N12UzJ
         Ad1ioZKXRi6U2f7pMFP85YyMZ18cKogjek/TbUAGbW87FWMI/adP4WUjXrwRjYAfGFRW
         8iky7ngsvubLoZuqGso5ivaQxNDqANmNwmIKpfw/1+WAlbGdFaIxih0qhc/lboDhDj6l
         rCKupS06+adkK3MXqeCFgJqcOXihPAcbTjhvWvy/01X8GmTo1Albl0rX4ySsK+v3cNMi
         LUnA==
X-Forwarded-Encrypted: i=1; AJvYcCWKAQOFWuiL/DOfZozV6a73415E85lHRjgtGZDJy99RJnRpG/36A1oLD4msbE57FGizkCk4vwbbHnU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGTIXH3KAe6tJwsL7yFxHZ0Ztqs01QQuFI++jmJOCSrSZ32oLr
	rm8JQyMTbM1xm3d/9BlVIanUkbpFCNNcw6GED1GdnrZVDk7t/4QS/bCBtOxL6X6QTVlP5h0rYfQ
	N8eA+a4UFZODjG3+nR0Hq5vRZrqYrPHyose6LHw==
X-Gm-Gg: ASbGncuGUvq24BlJ/d/3nybcpxDRcz6DhPNUff6RKoZAA3IxmUDKTgcU2uoeP0p5JfG
	n9yQunYc/9UDg1ab/2a8Njtx45ORTUX3c4PSdD7TGfbgNuNdCtUXQ0FWqf81hwEwhrafaO5wHfb
	wtOv9m8m35c2y3VbmUPFHghEi/MtC/iwGI
X-Google-Smtp-Source: AGHT+IHeQdLtNOQ0e3W+KHtAC5pD03nl+BrpjpMv+Jn/hPZuJcZw/cgVDJsYeblGE/Af41IItKci5svVHx6fFvAGsEA=
X-Received: by 2002:a05:6830:4127:b0:72b:9316:d593 with SMTP id
 46e09a7af769-732269cc9c1mr2411873a34.7.1746804864009; Fri, 09 May 2025
 08:34:24 -0700 (PDT)
MIME-Version: 1.0
References: <20250507094253.10395-1-freddy77@gmail.com> 
In-Reply-To: 
From: Frediano Ziglio 
Date: Fri, 9 May 2025 16:34:01 +0100
X-Gm-Features: AX0GCFtNpHaCMt2EMxl8gFIe31mfkGmwbhLO0tBPSs-4fwLOly57VNo-8dD-y2U
Message-ID: 
Subject: Re: [PATCH v2 0/4] Allows Secure Boot for Kexec
To: Andrew Cooper 
Cc: Frediano Ziglio , xen-devel@lists.xenproject.org, 
	Anthony PERARD , Michal Orzel , 
	Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , Bertrand Marquis , 
	Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 9, 2025 at 4:04=E2=80=AFPM Andrew Cooper  wrote:
>
> On 07/05/2025 10:42 am, Frediano Ziglio wrote:
> > Ross Lagerwall (4):
> >   xen/lib: Export additional sha256 functions
> >   kexec: Include purgatory in Xen
> >   kexec: Implement new EFI load types
> >   kexec: Support non-page-aligned kexec segments
>
> I realise a lot of this is coming from kexec-tools and/or Linux, but it
> looks very very mad.
>
> From patch 1, we're embedding this in Xen:
>
> xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
> -rw-r--r-- 1 andrew andrew 30K May  9 15:24 purgatory.ro
>
> yet -Wa,--strip-local-absolute alone halves the size:
>
> xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
> -rw-r--r-- 1 andrew andrew 17K May  9 15:25 purgatory.ro
>
> Looking at purgatory itself, we enter at purgatory_start, load a local
> GDT, set up a local stack, call into C for the hashing (and nothing
> else), then jmp to entry64...
>
> ... which loads a (different) local GDT, (different) local stack, loads
> the GPRs and then jumps into the new kernel.
>
> Combined with kexec_reloc(), that's 3x we change GDT and stack in
> several hundred instructions.
>
>
> Looking further at patch 2, we only set up 3 GPRs; %rip, %rsp and %rdi
> pointing the parameter block.
>
> Patch 2 also contains an a large amount of EFI-editing logic (all
> vulnerable to XSA-25), which AFAICT exists only because purgatory is
> built non-PIC and wants relocating.  I can't see any external
> references, or anything that couldn't be resolved at link time for a PIC
> build.
>
>
> There are two things which purgatory does which Xen doesn't currently
> cater for:
>
> 1) Setting up the GPRs in that manner
> 2) The digest checks
>
> #1 is very easy to fix and can probably even be done on the current ABI
> (older Kexecs using purgatory won't care), and #2 ought to be easy too
> by extending machine_kexec().  We can do the digest checks
> unconditionally (it's a sensible check irrespective).
>

I think the problem of #2 is that doing in the purgatory avoids
problems like possible memory corruptions. For instance if the host is
crashing due to some corruption it could not always be possible to
boot the saved kernel.

> I think that removes the majority of this series, with no loss in
> functionality?
>
> Given that we're leaving the signature check to the dom0 kernel (which
> is TCB and therefore can in the UEFI-SB model), we just might be able to
> get away without any hypercall changes at all?
>

Yes and no. The user space could not provide the purgatory. But if the
kernel is providing it, preventing the user space to send it, I
suppose it can be done. At this point however the question is how to
change the interface provided to userspace for doing it. It could make
sense to have the changes in xen/include/public/kexec.h and let the
kernel do the rest.

> Thoughts?
>
> ~Andrew

Frediano


From xen-devel-bounces@lists.xenproject.org Fri May 09 15:58:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 15:58:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980133.1366632 (Exim 4.92)
	(envelope-from )
	id 1uDQ6q-000713-Uq; Fri, 09 May 2025 15:58:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980133.1366632; Fri, 09 May 2025 15: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 1uDQ6q-00070A-Os; Fri, 09 May 2025 15:58:00 +0000
Received: by outflank-mailman (input) for mailman id 980133;
 Fri, 09 May 2025 15:57:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQ6p-0006Kr-4V
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 15:57:59 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 60070bda-2cee-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 17:57:57 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ac289147833so449334566b.2
 for ; Fri, 09 May 2025 08:57:57 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad21947a88fsm168723766b.81.2025.05.09.08.57.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 08:57: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" 
X-Inumbo-ID: 60070bda-2cee-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746806277; x=1747411077; 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;
        bh=9qPEUHjjXJvBKQ7mRTvnDll4njWE6oo2euZAX0DbEXY=;
        b=NJR8pfusbLPVHo1U6TOp/55/mCzdfKKVV5oxu4bfJ0Q3bHLe+05v9v4Qpy4hv2U9mr
         MA3wPsEc7++v9pRgPBUC/GGNzjigXz/5kw2chwp+Wkj2LXozsbvt1oP4gGecuPoNwDaJ
         QU/OzvCM9b9FJDu/uygpow4cJA5ZuR4fR8aillF8We199XNAaJZK81GPG7iyPeuwrA13
         rPZYKmzqgzRxmUblfzkadzdWZ8g/RJnf/9ZGPfaiFsFHuXmaptB/1NFSfUav7ZIekuVw
         thV+yWnkHg7FeQns8GmKi9W7kJWE/UWb7HVPiYB7iFgsdjnwZisdh913lVc5zNotLJ0l
         jm8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746806277; x=1747411077;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=9qPEUHjjXJvBKQ7mRTvnDll4njWE6oo2euZAX0DbEXY=;
        b=psfi4voXS5KqJ7YlJLSlmGqsj7I2aLjDtZYeagSAtWpmeAapOBBfsTZq5mt8g7xyYS
         3d7P9EJaCofGCwCbDjan++MG0IhwsOVjWheg24nncc/oju0CjNAKPePww0yWm4i8UfHh
         +uqQqYXeqNKmHOOQnUacKuuz8rQoZxhZGgFqh4hLqGgO1TlNffRmMOnlWTrGjCPCdYRc
         lJWx7g5n5uofb3Ckwg1EKU+WdY0xzh4r5irX48lDTPtrQ30QSckoxX8/Y8kwFcIk8Tf1
         6wsszH2NPafZTylOeLS9LFezwZapgdwQY/XqKgZurXUtQdJJ4bI5vnOhl9q4uVFhshRl
         +Lxg==
X-Gm-Message-State: AOJu0YxcGLZrq1npD/ueXQ5x2iRtm6Po3QOvnjPV1/Jk5+w8zGHUlWiI
	gbPz0IrXdhfEJas/cKLFFMVDf16uMKSPB+45HvTZYCllbg/hi+RseYU97Q==
X-Gm-Gg: ASbGncswzt0N3DWcQIDqu4cufTEgBtWrOMDZxVFafU3WJ4R5ZVY0F/arEeSj0q+EMZw
	uBNYxOWgkfJhprzxK58P1Eve3pyZsDgVjFumnVYk+3IHYMkX01EDOi84eZ3MmEIvQ7YqSX14alm
	UxlchbaEDm1BnIILjHrLqBc0InOAyysYTqDPNVbBx6W4Ara0wfv1HSswNHQ4CFTKlNTstPY2L7u
	xrc/K5u20cAczpjCMlWM2Kl2pAYSz+zSThNkVXcb099z8UMmCyG/VKz662V6lZxV9YtGjol3hX5
	nI2qXDecc7o37aI+citMwROJADBvSXYW8SferzvV5UOo9QYpNtT710ejpCWqM8Vp0jH9McY5nA2
	iW7xRsiZ/gg==
X-Google-Smtp-Source: AGHT+IEqkl5G4yO2sCosJUhojhdkwAJQn7oPU8PxLl4K6nQhDCF7PIykc2HWxZhHQb84HyhPIHTZ1w==
X-Received: by 2002:a17:907:3f25:b0:ace:6a25:f56a with SMTP id a640c23a62f3a-ad218f835acmr472320166b.29.1746806276295;
        Fri, 09 May 2025 08:57:56 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m initialization
Date: Fri,  9 May 2025 17:57:47 +0200
Message-ID: <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce the following things:
- p2m_domain structure which describe per p2m-table state.
- Update arch_domain structure with the mentioned above structure.
- p2m_get_hostp2m() to recieve domain's p2m structure.
- Introudce p2m_write_lock() and p2m_is_write_locked().
- p2m_init() to initalize p2m:
  - allocate p2m table by using of p2m_alloc_table().
  - initialize lock premitive necessary to protect updates to the p2m.
- Introduce the following functions to implement p2m_alloc_table():
  - p2m_allocate_root() to allocate p2m root table by using another introduced
    helpers p2m_get_clean_page() and clear_and_clean_page().
  - introduce p2m_force_tlb_flush_sync() to flush TLBs after p2m table
    allocation before being used. (it isn't necessary at the current stage of
    development but could be useful once the VMID is marked unused, a new domain
    can reuse the VMID for its own. If the TLB is not flushed, entries can
    contain wrong translation.)
- Implement maddr_to_page() and page_to_maddr().

Signed-off-by: Oleksii Kurochko 
---
 xen/arch/riscv/Makefile             |   1 +
 xen/arch/riscv/include/asm/domain.h |   6 +
 xen/arch/riscv/include/asm/mm.h     |   4 +
 xen/arch/riscv/include/asm/p2m.h    |  76 +++++++++++++
 xen/arch/riscv/p2m.c                | 168 ++++++++++++++++++++++++++++
 5 files changed, 255 insertions(+)
 create mode 100644 xen/arch/riscv/p2m.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index d882c57528..87c5e7e7f2 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -5,6 +5,7 @@ obj-y += entry.o
 obj-y += intc.o
 obj-y += mm.o
 obj-y += pt.o
+obj-y += p2m.o
 obj-$(CONFIG_RISCV_64) += riscv64/
 obj-y += sbi.o
 obj-y += setup.o
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index c3d965a559..48be90a395 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -5,6 +5,8 @@
 #include 
 #include 
 
+#include 
+
 struct hvm_domain
 {
     uint64_t              params[HVM_NR_PARAMS];
@@ -16,8 +18,12 @@ struct arch_vcpu_io {
 struct arch_vcpu {
 };
 
+
 struct arch_domain {
     struct hvm_domain hvm;
+
+    struct p2m_domain p2m;
+
 };
 
 #include 
diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 01bbd92a06..972ec45448 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -149,6 +149,10 @@ extern struct page_info *frametable_virt_start;
 #define mfn_to_page(mfn)    (frametable_virt_start + mfn_x(mfn))
 #define page_to_mfn(pg)     _mfn((pg) - frametable_virt_start)
 
+/* Convert between machine addresses and page-info structures. */
+#define maddr_to_page(ma) mfn_to_page(maddr_to_mfn(ma))
+#define page_to_maddr(pg) (mfn_to_maddr(page_to_mfn(pg)))
+
 static inline void *page_to_virt(const struct page_info *pg)
 {
     return mfn_to_virt(mfn_x(page_to_mfn(pg)));
diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 28f57a74f2..8b46210768 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -3,11 +3,73 @@
 #define ASM__RISCV__P2M_H
 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 
 #define paddr_bits PADDR_BITS
 
+/* Get host p2m table */
+#define p2m_get_hostp2m(d) (&(d)->arch.p2m)
+
+/* Per-p2m-table state */
+struct p2m_domain {
+    /*
+     * Lock that protects updates to the p2m.
+     */
+    rwlock_t lock;
+
+    /* Page containing root p2m table */
+    struct page_info *root;
+
+    /* Pages used to construct the p2m */
+    struct page_list_head pages;
+
+    /* Address Translation Table for the p2m */
+    paddr_t hgatp;
+
+    /*
+     * P2M updates may required TLBs to be flushed (invalidated).
+     *
+     * Flushes may be deferred by setting 'need_flush' and then flushing
+     * when the p2m write lock is released.
+     *
+     * If an immediate flush is required (e.g, if a super page is
+     * shattered), call p2m_tlb_flush_sync().
+     */
+    bool need_flush;
+
+    /* Indicate if it is required to clean the cache when writing an entry */
+    bool clean_pte;
+
+    struct radix_tree_root p2m_type;
+
+    /*
+     * Default P2M access type for each page in the the domain: new pages,
+     * swapped in pages, cleared pages, and pages that are ambiguously
+     * retyped get this access type.  See definition of p2m_access_t.
+     */
+    p2m_access_t default_access;
+
+    /* Highest guest frame that's ever been mapped in the p2m */
+    gfn_t max_mapped_gfn;
+
+    /*
+     * Lowest mapped gfn in the p2m. When releasing mapped gfn's in a
+     * preemptible manner this is update to track recall where to
+     * resume the search. Apart from during teardown this can only
+     * decrease.
+     */
+    gfn_t lowest_mapped_gfn;
+
+    /* Back pointer to domain */
+    struct domain *domain;
+};
+
 /*
  * List of possible type for each page in the p2m entry.
  * The number of available bit per page in the pte for this purpose is 2 bits.
@@ -93,6 +155,20 @@ static inline void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
     /* Not supported on RISCV. */
 }
 
+int p2m_init(struct domain *d);
+
+static inline void p2m_write_lock(struct p2m_domain *p2m)
+{
+    write_lock(&p2m->lock);
+}
+
+void p2m_write_unlock(struct p2m_domain *p2m);
+
+static inline int p2m_is_write_locked(struct p2m_domain *p2m)
+{
+    return rw_is_write_locked(&p2m->lock);
+}
+
 #endif /* ASM__RISCV__P2M_H */
 
 /*
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
new file mode 100644
index 0000000000..ad4beef8f9
--- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,168 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/*
+ * Force a synchronous P2M TLB flush.
+ *
+ * Must be called with the p2m lock held.
+ *
+ * TODO: add support of flushing TLB connected to VMID.
+ */
+static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
+{
+    ASSERT(p2m_is_write_locked(p2m));
+
+    /*
+     * TODO: shouldn't be this flush done for each physical CPU?
+     *       If yes, then SBI call sbi_remote_hfence_gvma() could
+     *       be used for that.
+     */
+#if defined(__riscv_hh) || defined(__riscv_h)
+    asm volatile ( "hfence.gvma" ::: "memory" );
+#else
+    asm volatile ( ".insn r 0x73, 0x0, 0x31, x0, x0, x0" ::: "memory" );
+#endif
+
+    p2m->need_flush = false;
+}
+
+static void p2m_tlb_flush_sync(struct p2m_domain *p2m)
+{
+    if ( p2m->need_flush )
+        p2m_force_tlb_flush_sync(p2m);
+}
+
+/* Unlock the flush and do a P2M TLB flush if necessary */
+void p2m_write_unlock(struct p2m_domain *p2m)
+{
+    /*
+     * The final flush is done with the P2M write lock taken to avoid
+     * someone else modifying the P2M wbefore the TLB invalidation has
+     * completed.
+     */
+    p2m_tlb_flush_sync(p2m);
+
+    write_unlock(&p2m->lock);
+}
+
+static void clear_and_clean_page(struct page_info *page)
+{
+    void *p = __map_domain_page(page);
+
+    clear_page(p);
+    unmap_domain_page(p);
+}
+
+static struct page_info *p2m_get_clean_page(struct domain *d)
+{
+    struct page_info *page;
+
+    /*
+     * As mentioned in the Priviliged Architecture Spec (version 20240411)
+     * As explained in Section 18.5.1, for the paged virtual-memory schemes
+     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
+     * and must be aligned to a 16-KiB boundary.
+     */
+    page = alloc_domheap_pages(NULL, 2, 0);
+    if ( page == NULL )
+        return NULL;
+
+    clear_and_clean_page(page);
+
+    return page;
+}
+
+static struct page_info *p2m_allocate_root(struct domain *d)
+{
+    return p2m_get_clean_page(d);
+}
+
+static unsigned long hgatp_from_page_info(struct page_info *page_info)
+{
+    unsigned long ppn;
+    unsigned long hgatp_mode;
+
+    ppn = PFN_DOWN(page_to_maddr(page_info)) & HGATP_PPN;
+
+    /* ASID (VMID) not supported yet */
+
+#if RV_STAGE1_MODE == SATP_MODE_SV39
+    hgatp_mode = HGATP_MODE_SV39X4;
+#elif RV_STAGE1_MODE == SATP_MODE_SV48
+    hgatp_mode = HGATP_MODE_SV48X4;
+#else
+    #error "add HGATP_MODE"
+#endif
+
+    return ppn | (hgatp_mode << HGATP_MODE_SHIFT);
+}
+
+static int p2m_alloc_table(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    p2m->root = p2m_allocate_root(d);
+    if ( !p2m->root )
+        return -ENOMEM;
+
+    p2m->hgatp = hgatp_from_page_info(p2m->root);
+
+    /*
+     * Make sure that all TLBs corresponding to the new VMID are flushed
+     * before using it.
+     */
+    p2m_write_lock(p2m);
+    p2m_force_tlb_flush_sync(p2m);
+    p2m_write_unlock(p2m);
+
+    return 0;
+}
+
+int p2m_init(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int rc;
+
+    rwlock_init(&p2m->lock);
+    INIT_PAGE_LIST_HEAD(&p2m->pages);
+
+    p2m->max_mapped_gfn = _gfn(0);
+    p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
+
+    p2m->default_access = p2m_access_rwx;
+
+    radix_tree_init(&p2m->p2m_type);
+
+#ifdef CONFIG_HAS_PASSTHROUGH
+    /*
+     * Some IOMMUs don't support coherent PT walk. When the p2m is
+     * shared with the CPU, Xen has to make sure that the PT changes have
+     * reached the memory
+     */
+    p2m->clean_pte = is_iommu_enabled(d) &&
+        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
+#else
+    p2m->clean_pte = true;
+#endif
+
+    /*
+     * "Trivial" initialisation is now complete.  Set the backpointer so
+     * p2m_teardown() and friends know to do something.
+     */
+    p2m->domain = d;
+
+    rc = p2m_alloc_table(d);
+    if ( rc )
+        return rc;
+
+    return 0;
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 09 15:58:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 15:58:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980132.1366616 (Exim 4.92)
	(envelope-from )
	id 1uDQ6p-0006cC-O9; Fri, 09 May 2025 15:57:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980132.1366616; Fri, 09 May 2025 15: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 1uDQ6p-0006bR-II; Fri, 09 May 2025 15:57:59 +0000
Received: by outflank-mailman (input) for mailman id 980132;
 Fri, 09 May 2025 15:57:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQ6o-0006Ks-I8
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 15:57:58 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 606da725-2cee-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 17:57:58 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ac2bdea5a38so319445966b.0
 for ; Fri, 09 May 2025 08:57:58 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad21947a88fsm168723766b.81.2025.05.09.08.57.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 08:57: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" 
X-Inumbo-ID: 606da725-2cee-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746806277; x=1747411077; 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;
        bh=BkyJj8JMdl89i28EMMlSrA84WkLEbjMJQGptj7C/v9o=;
        b=ROHZY7iD6eLB1YvJsSjN1FlPp+i+GAifBDunrKkxZwkLQzbObNnGryBSHNNyf9JQYg
         7N+fUyCumBrcF/YQDKxJXTbf2osNLlFCrgYSbGsXjiPJ2o1G+3golQBoNp2sjZP5/v7Z
         K9lWaV1lwhji+XwALmMwz/03Mz3hFx1CWX39FMUwtnGVf7sA0LBKRmBp5f8vFTlf7Jq7
         lQ2s23GsUVwNsxZJK548vQO0Y+9DF6aqrZxaVGkKHdpRbsjr+vDWgazhzcf/Id90awAf
         gl4RmeqbUmL8c4+iidmiQxmQQjWYkxs7PuwwCfPlVoYEwb6tj2mZzH1HCNqYXdHLD7ub
         PtQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746806277; x=1747411077;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=BkyJj8JMdl89i28EMMlSrA84WkLEbjMJQGptj7C/v9o=;
        b=wPya54FSZheyJqxoNBlogLtzLXh8BAXb9KrbKAMHbFDQMTY8suo4RBUpG5bqjMFrv8
         PDTo54iI5Py0yrCZZrh0BE54Px/pmNhTvvLpaj+buXNrfK+4KBeMRXEMq072ZaI+Bxdl
         cmh0acAueQZ8UUjQAbvRHY6IfjhwtLlePdEYAO4bRmd5iz1mLuYcz9fD5VIdgkCCq8Wg
         8uFEO3UCw6avz2otLklBegxAa9sxvpsrLmXVMDauhXncJ+ZhNKC/5ys1Mz525fOSVM9K
         /2TcG1UvOp3AhqAOg7HuaE9RoZLSRzjaJmu1UucSnwfKuLLBxrQqrXz8LlSiVySXsqKW
         dymQ==
X-Gm-Message-State: AOJu0Yxa4MSWl+NGM7opo6E9x4X908L8Ce7r/fIpM6jaMbhXdknk7S0g
	Cgih7dnQ87+aSneGeDyNY9hZXyRxDxZkd3ZnMeHWhBFNxtayCLljW1DOWw==
X-Gm-Gg: ASbGncuOC0/mVdOtGUeVU/Ms3LmXvjPUHuvhmadzL1UyHdocumLZ1VjoilhTK37LZww
	piU/4eoZORE+KhKy6PeomGj6u9sO1ltA22wC7qdITNjB9FbMo6YjRDF++Wx6bJ2Lea8Twv0tB8a
	VPBHUCmsF0AnmV3ObBmGCoGJfpIEFqdzo36xqVO0kXQqchnR8LBZoOPww8qyX1aLOflJsFuSUqZ
	9elhn22qbzMD6aGkomq46oSD2HjM15FpxoJuk3LZg+VTpkWzyDOcJGciwNE1uaOhyqaqf50jDM2
	dOwImgKymAHc4Ee9u1khSdVD5g3Mmjp7Y9VREVUJ3znPpl8ZuykaHpC+AgIktHiI++7+Xuu5Y6I
	e0PpT8xSv5w==
X-Google-Smtp-Source: AGHT+IH2KDBjkqrz5qKTDnd4fSpMppBunhRIHx5Oe0d2MojyO8oAXPs58wrRDSzFPOPEVmcPgMQKbw==
X-Received: by 2002:a17:907:8749:b0:acb:b900:2bca with SMTP id a640c23a62f3a-ad218810026mr399148566b.0.1746806277166;
        Fri, 09 May 2025 08:57:57 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v1 3/6] xen/riscv: construct the P2M pages pool for guests
Date: Fri,  9 May 2025 17:57:48 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement p2m_set_allocation() to construct p2m pages pool for guests
based on required number of pages.

This is implemented by:
- Adding a `struct paging_domain` which contains a freelist, a
  counter variable and a spinlock to `struct arch_domain` to
  indicate the free p2m pages and the number of p2m total pages in
  the p2m pages pool.
- Adding a helper `p2m_set_allocation` to set the p2m pages pool
  size. This helper should be called before allocating memory for
  a guest and is called from domain_p2m_set_allocation(), the latter
  is a part of common dom0less code.

Signed-off-by: Oleksii Kurochko 
---
 xen/arch/riscv/include/asm/domain.h | 10 +++++
 xen/arch/riscv/p2m.c                | 67 +++++++++++++++++++++++++++++
 2 files changed, 77 insertions(+)

diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index 48be90a395..b818127f9f 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -2,6 +2,8 @@
 #ifndef ASM__RISCV__DOMAIN_H
 #define ASM__RISCV__DOMAIN_H
 
+#include 
+#include 
 #include 
 #include 
 
@@ -18,12 +20,20 @@ struct arch_vcpu_io {
 struct arch_vcpu {
 };
 
+struct paging_domain {
+    spinlock_t lock;
+    /* Free P2M pages from the pre-allocated P2M pool */
+    struct page_list_head p2m_freelist;
+    /* Number of pages from the pre-allocated P2M pool */
+    unsigned long p2m_total_pages;
+};
 
 struct arch_domain {
     struct hvm_domain hvm;
 
     struct p2m_domain p2m;
 
+    struct paging_domain paging;
 };
 
 #include 
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index ad4beef8f9..a890870391 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -1,4 +1,12 @@
 #include 
+/*
+ * Because of general_preempt_check() from xen/sched.h which uses
+ * local_events_need_delivery() but latter is declared in .
+ * Thereby it is needed to icnlude  here before xen/sched.h.
+ *
+ * Shouldn't be xen/event.h be included in ?
+ */
+#include 
 #include 
 #include 
 #include 
@@ -133,7 +141,9 @@ int p2m_init(struct domain *d)
     int rc;
 
     rwlock_init(&p2m->lock);
+    spin_lock_init(&d->arch.paging.lock);
     INIT_PAGE_LIST_HEAD(&p2m->pages);
+    INIT_PAGE_LIST_HEAD(&d->arch.paging.p2m_freelist);
 
     p2m->max_mapped_gfn = _gfn(0);
     p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
@@ -166,3 +176,60 @@ int p2m_init(struct domain *d)
 
     return 0;
 }
+
+/*
+ * Set the pool of pages to the required number of pages.
+ * Returns 0 for success, non-zero for failure.
+ * Call with d->arch.paging.lock held.
+ */
+int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
+{
+    struct page_info *pg;
+
+    ASSERT(spin_is_locked(&d->arch.paging.lock));
+
+    for ( ; ; )
+    {
+        if ( d->arch.paging.p2m_total_pages < pages )
+        {
+            /* Need to allocate more memory from domheap */
+            pg = alloc_domheap_page(d, MEMF_no_owner);
+            if ( pg == NULL )
+            {
+                printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
+                return -ENOMEM;
+            }
+            ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
+                d->arch.paging.p2m_total_pages + 1;
+            page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
+        }
+        else if ( d->arch.paging.p2m_total_pages > pages )
+        {
+            /* Need to return memory to domheap */
+            pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
+            if( pg )
+            {
+                ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
+                    d->arch.paging.p2m_total_pages - 1;
+                free_domheap_page(pg);
+            }
+            else
+            {
+                printk(XENLOG_ERR
+                       "Failed to free P2M pages, P2M freelist is empty.\n");
+                return -ENOMEM;
+            }
+        }
+        else
+            break;
+
+        /* Check to see if we need to yield and try again */
+        if ( preempted && general_preempt_check() )
+        {
+            *preempted = true;
+            return -ERESTART;
+        }
+    }
+
+    return 0;
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 09 15:58:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 15:58:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980134.1366641 (Exim 4.92)
	(envelope-from )
	id 1uDQ6s-0007GQ-4w; Fri, 09 May 2025 15:58:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980134.1366641; Fri, 09 May 2025 15:58: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 1uDQ6s-0007G5-0F; Fri, 09 May 2025 15:58:02 +0000
Received: by outflank-mailman (input) for mailman id 980134;
 Fri, 09 May 2025 15:58:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQ6q-0006Kr-FZ
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 15:58:00 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 60f862b0-2cee-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 17:57:59 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ad21c5d9db2so186701566b.3
 for ; Fri, 09 May 2025 08:57:59 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad21947a88fsm168723766b.81.2025.05.09.08.57.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 08:57: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" 
X-Inumbo-ID: 60f862b0-2cee-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746806278; x=1747411078; 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;
        bh=FfyWuQ4iu9CwNTdoqFztyN900xmaX3FB22gI8y2dLpQ=;
        b=NiOfBa6ya945tQhqCGIBJB6IqwftdZdmJi5VAYOeU/52mmZSqtNqYGB1YmrZ6FIgxT
         XQIw7gEIpJOUaCClpx+kkbzu1y8XlYUabNU3mq6lz4y6FPBcu8vjdVbG4YdnIxnW1yyi
         DpH5a9n15LWOlVLhj7XlTQQYdx/+9uF+5Qgohbe0JWWBAVYtmd7GBMJSlswm73pb9/bb
         19Lrh+DThFk4DnMCtIVfsagC5dK1q9N3x1Iz+LDSPxljggJchnXvLIGWi67Z1ZPr+niy
         n6khDvTgzv9qcWTx+1dqftmRL1TyDPoCA9feS6iJauYTc6HdXXr2T8bbbXjTP9f53uit
         DfiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746806278; x=1747411078;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=FfyWuQ4iu9CwNTdoqFztyN900xmaX3FB22gI8y2dLpQ=;
        b=rKikHooUpa0WVQnc2zV2FK8JDLlJxqsKrwXe88+934Pz6s6vDLdsXwv8srmrcNUFHe
         BXsMIHKQsNkMyFXQHjz0Pgcp2bdhCK/23cZSJYf6Uj+4hBXNmMoxCaL3fd6LNe2QkQZ1
         tgrHA8w+zK7thXcHg9jpyJ4YeI/j3BzP5NeXzS2zcVrS4bp9q1YgUVCbF4N9HhPKWL5b
         UHxmkzaj7L/nu/YwFprE6VnCGzNS89Gv2CK3uBQnpDg9fN9vJ9FsRkTCpHEDjSRppaKW
         is2suZLbfWKuHTH5jRZfF9p6KbjkTOZIlTSt2ZX/Bx9WOVHf2biHM418KGiZa4vze2Do
         Gmcg==
X-Gm-Message-State: AOJu0Ywo8FfL62how0fq9wD2NQXZ2nG5AjbNfJv4xthp8XM75tmZR338
	yLN9N4J8qLZSLmK4I2/WvCSab96qi/ngkyuj+T/696LBorboaueJPxS0Xg==
X-Gm-Gg: ASbGncu1MsdzZAw1xwVi1GBsCKg/nvl0INLKX6JCQyigqW5KMjw/LeXI6KH0P0/KhI5
	fAPNdUmMPg7VIsq2aERsSrsW+DfZVltyOJsPj580HNOZcHvvPAiJ3Lixd3uE/eckA9bmvQHCMF6
	sDyqWJdSUNpnLmvWtc1rsdK78J32rZrtnqE/npnMZKXRTEU+DXgSOv2DE/B0Ps3zmamLp5petn5
	he6XhjzMj1ZwjtmrRUOohMQEaLQD8hJxSl9np+KJr8ic/Yy/TEBEgbdX0dy7PaWbUnKDFpB8Nuz
	+oEk+kY6Wjmc9flPGsPwBnVprKGC9a/oAAyBnpDYEz21rmWX92IoadLR1mZZ0e10Fc7gSa2ygrO
	6o4YcSQE8xA==
X-Google-Smtp-Source: AGHT+IEfeVBVYJzYmzNbx/z6SpZCUL6U5Os43OZl7uaC4Z8CqbdCnxdjXNSDtKwUey0Mt4UBCkT09A==
X-Received: by 2002:a17:907:6e92:b0:aca:e2d9:41f with SMTP id a640c23a62f3a-ad21934e52fmr342928466b.60.1746806278167;
        Fri, 09 May 2025 08:57:58 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v1 4/6] xen/riscv: define pt_t and pt_walk_t structures
Date: Fri,  9 May 2025 17:57:49 +0200
Message-ID: <9f822cfaa058167982c85b3ca3f722881552a75e.1746805907.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Refactor pte_t to be a union which hold page table entry plus
pt_t and pt_walk_t structures to simpilfy p2m functions.

Also, introduce some helpers which are using pt_walk_t.

Signed-off-by: Oleksii Kurochko 
---
 xen/arch/riscv/include/asm/page.h | 54 ++++++++++++++++++++++++++++++-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 2af4823170..cb3dea309c 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -99,15 +99,67 @@
 
 #endif
 
-/* Page Table entry */
 typedef struct {
+    unsigned long v:1;
+    unsigned long r:1;
+    unsigned long w:1;
+    unsigned long x:1;
+    unsigned long u:1;
+    unsigned long g:1;
+    unsigned long a:1;
+    unsigned long d:1;
+    unsigned long rsw:2;
+#if RV_STAGE1_MODE == SATP_MODE_SV39
+    unsigned long ppn0:9;
+    unsigned long ppn1:9;
+    unsigned long ppn2:26;
+    unsigned long rsw2:7;
+    unsigned long pbmt:2;
+    unsigned long n:1;
+#elif RV_STAGE1_MODE == SATP_MODE_SV48
+    unsigned long ppn0:9;
+    unsigned long ppn1:9;
+    unsigned long ppn2:9;
+    unsigned long ppn3:17;
+    unsigned long rsw2:7;
+    unsigned long pbmt:2;
+    unsigned long n:1;
+#else
+#error "Add proper bits for SATP_MODE"
+#endif
+} pt_t;
+
+typedef struct {
+    unsigned long rsw:10;
+#if RV_STAGE1_MODE == SATP_MODE_SV39 || RV_STAGE1_MODE == SATP_MODE_SV48
+    unsigned long ppn: 44;
+#else
+#error "Add proper bits for SATP_MODE"
+#endif
+    unsigned long rsw2:10;
+} pt_walk_t;
+
+/* Page Table entry */
+typedef union {
 #ifdef CONFIG_RISCV_64
     uint64_t pte;
 #else
     uint32_t pte;
 #endif
+    pt_t bits;
+    pt_walk_t walk;
 } pte_t;
 
+static inline void pte_set_mfn(pte_t *pte, mfn_t mfn)
+{
+    pte->walk.ppn = mfn_x(mfn);
+}
+
+static inline mfn_t pte_get_mfn(pte_t pte)
+{
+    return _mfn(pte.walk.ppn);
+}
+
 static inline pte_t paddr_to_pte(paddr_t paddr,
                                  unsigned int permissions)
 {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 09 15:58:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 15:58:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980131.1366610 (Exim 4.92)
	(envelope-from )
	id 1uDQ6p-0006Z7-Dl; Fri, 09 May 2025 15:57:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980131.1366610; Fri, 09 May 2025 15: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 1uDQ6p-0006Z0-AR; Fri, 09 May 2025 15:57:59 +0000
Received: by outflank-mailman (input) for mailman id 980131;
 Fri, 09 May 2025 15:57:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQ6n-0006Ks-NV
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 15:57:57 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5f4d529d-2cee-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 17:57:56 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ad1d1f57a01so423943366b.2
 for ; Fri, 09 May 2025 08:57:56 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad21947a88fsm168723766b.81.2025.05.09.08.57.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 08:57: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" 
X-Inumbo-ID: 5f4d529d-2cee-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746806275; x=1747411075; 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;
        bh=bhgIiPK3XPnML7n+ScrJv7EOoTzBz2z0Tz9e4QcGSKw=;
        b=aaQPhSTKeqSVAFe4IYlOEYb5ywHAP17SH4HBFu9t1XZUUZK147ZdLu8uW6Jv7gvsa8
         uK6h0YA1BuOHH94auZwHe2OvYuH2tqazNOrFDWj8c6n6nQMV4PV62TGMx+uCCok/JXHh
         75m8RtMVAxxO8v7mp+HHaKHdEMN85KKhfhfaQswUtV34V/sXjXNcEHsaMRfrtAi2DB7k
         1QWsyzq1x/so21SvGQbHe6k4t1kWaVGaR14gz8p8wy834akuYPn5ndP6U8oRpNfNfHJo
         9cqyhAtz09TQ5n7GJklk+v1yEJKSK3GHih5+z0eSFFxqw7dipKDgW9MjeH4tcjaV1CrD
         o2jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746806275; x=1747411075;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=bhgIiPK3XPnML7n+ScrJv7EOoTzBz2z0Tz9e4QcGSKw=;
        b=JxObH6+urhHW7wxEgS77CX45rum6SXJ5JyRf3kFb7jbClqueKs9+oc7nwgTxy24ecg
         RXSCHmzK9v7MiBepGLesAZtuyT0O0QojgDIT7QKRJHHoUVgEPxMdzB07PeLEY7HG38Hh
         +N0JwOAw8QG4MS3OjYDKF6/hrkAYesXpjBFs7POzDnFOfoqcy+SZl+IlH+DVtgijVr76
         omBj7NDswHDstk3dHZTF+cZWctxiOi8/Vwnfn37ZvQsS62RzMFHD9aFgwwQuFfAkk+t1
         JrG/ukKZidh+UGVqi+2vV9fNFcYY5SCeQtwHalt8SfjVNCQbS3LdJ7UY3e4yEo6HQjVf
         hRLg==
X-Gm-Message-State: AOJu0YyfqD2sAT2VsAoDbjNBuIXkcCKAp9nyEzygQtcv+YipZOs6NFv8
	IHs8Q/CZ2qDZk2sfu+e+gYdDD/oJA9OoNsCzP5N5eTAH1KpMlO8JA7bL2g==
X-Gm-Gg: ASbGncswyv4Gs+Y8K32j7/YVwbI7C2nmdtebZl8X5CANZk+NrS/69kd40qUAyPm+/OF
	DIGBTT+gPgwwa98jmYEdSIkmBUW5Wt/ZOW6A8qL0H43sqpaXHB5VuTqbzYFLhFtM1Ky5A1t5tek
	YFetK02yxZE1b8DX519ttGBKNjPCXCrkstEV4260+Pn4tPM6fupGKsDDXpN3Xa+PNS3TfwzkmVT
	tzFEO3/GJ01iiI740u1/oOwZBCljnIAEjZaT2+boEH7Byufzvr6A8E6mdeY3P/S8KU5gZ/Lukw6
	Z9OREHK5MnQf+C53uYF68Bm7c3bHd4sJFV3yhuMYCUzJAXDz5JRPcRqBi24Uc9iMYNFOhrb9WQ1
	DuGkf5fbCuQ==
X-Google-Smtp-Source: AGHT+IGZ6zGvWzpoPLeEZf/9t/LcakqbMgpK4ZOsvGcXqc0SMLlpfVJZS8ugrMmTXcN7eRqKEeFTFA==
X-Received: by 2002:a17:907:8b8a:b0:ace:c416:4231 with SMTP id a640c23a62f3a-ad218e92f99mr413658566b.12.1746806275236;
        Fri, 09 May 2025 08:57:55 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v1 1/6] xen/riscv: add inclusion of xen/bitops.h to asm/cmpxchg.h
Date: Fri,  9 May 2025 17:57:46 +0200
Message-ID: <876ca1a5dcf7523657ed722f588824f6d8bfb171.1746805907.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add inclusion of xen/bitops.h to asm/cmpxchg.h to avoid compilation issues
connected to GENMASK() which is used inside asm/cmpxchg.h.

Signed-off-by: Oleksii Kurochko 
---
This patch should go first; otherwise one of the further patches of this
patch series could face a compilation issue.
---
 xen/arch/riscv/include/asm/cmpxchg.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/riscv/include/asm/cmpxchg.h b/xen/arch/riscv/include/asm/cmpxchg.h
index 7d7c89b6fa..d47ebaffce 100644
--- a/xen/arch/riscv/include/asm/cmpxchg.h
+++ b/xen/arch/riscv/include/asm/cmpxchg.h
@@ -4,6 +4,7 @@
 #ifndef ASM__RISCV__CMPXCHG_H
 #define ASM__RISCV__CMPXCHG_H
 
+#include 
 #include 
 #include 
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 09 15:58:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 15:58:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980135.1366646 (Exim 4.92)
	(envelope-from )
	id 1uDQ6s-0007JD-Dz; Fri, 09 May 2025 15:58:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980135.1366646; Fri, 09 May 2025 15:58: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 1uDQ6s-0007Ht-7n; Fri, 09 May 2025 15:58:02 +0000
Received: by outflank-mailman (input) for mailman id 980135;
 Fri, 09 May 2025 15:58:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQ6q-0006Ks-I7
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 15:58:00 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 61a4a4f8-2cee-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 17:58:00 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-acb2faa9f55so288884466b.3
 for ; Fri, 09 May 2025 08:58:00 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad21947a88fsm168723766b.81.2025.05.09.08.57.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 08:57: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" 
X-Inumbo-ID: 61a4a4f8-2cee-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746806279; x=1747411079; 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;
        bh=jPNXFitrsuhjSLUmzL7Et58soUtc/i4BVkSK0TPuQwk=;
        b=FHetQPJsczhh94HI7lWHd4tbL1gzKKg5DulRWGvUkgbE+fC5HJL78J0GiYWhVtu7nI
         6J5MxYgh6/ERf1ngrCIdHYyTPDWvGdLrcoxWizcXeDgbGGVVzW1PBh00s7kw+5eBUnIC
         GL0yLdhDVKOoAEMA77KOL8nxWdF73fvGrkABOGGM9TjxiOItLPjkJJ/g3MtYj0q6ap4H
         DhiBZ0VZBfeNuLZa6i63Wo/o5gIIaOD6CKK7Qh1/yrbQSyIBGYOSMgPL2sPDKzTcQYMr
         KEnRPsJl05qqotVb1I9ATjpyqpJ4HfBs6Q2f936uqULQQfU/QEoFjg72XC31GOUVFKZo
         +LLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746806279; x=1747411079;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jPNXFitrsuhjSLUmzL7Et58soUtc/i4BVkSK0TPuQwk=;
        b=Rsd6I1nxVtjMqtOnCzicP2bLlNLtKtD4sn+t/ya2PpLuyeo2H0S0vSBQrOeu7NB90F
         aCuRu1EStOQ2Uk4pfoxp5ABDroW+2WeAlORQSV4Jpaz71q/I769B9Ka8r1Q59Yb4lSFW
         HnsU3RdFOW4vJ125ZWr6y6GfoBv+zY0t5t0rBkikDlgV9Zmh1xphlCq1SdNWur4DQLiN
         MzTsDoRPTLmQ07ahQtsUUvxeqbssH3pxeoOozLlgDL+0VuNgNfMa1kyJAuuQKzx+E7nL
         qQLNakJB1tQR1Bpxb/IzIoKKv0ga6/w+AevgWriLqRLv+ugd1HG7nTvfg2HqYvkTMJn3
         OGRg==
X-Gm-Message-State: AOJu0YwheeMdfoOr7/7pxpAnrf1lAKP6X8HWF3InU1aWW/lwK/nlhPIZ
	iTFNOufIL8Q+T2uVauUTk9G7pdGHMYovjKcG9NgQEM83a2CsIdDYwZjxSg==
X-Gm-Gg: ASbGncuwRMNm2pqxQ2jc6Hr47wPSR5OsioncFWCzV/EF5Lc5+tQmaBwz34tsWMfYlLu
	1aBzGHxHKed9C5KTITvLu7YiDtuHQQyrRtgVGKzKyyMDAg80kSZ9cAY94SVLpnq/1T0IhcxCJzP
	ZBAoD95v1nRnkeDPC253yGBvmI2rsWmQmo+VqIS+ip47WS2YUjQ7P3M+YWXOfCgorjQvKKXXJsr
	Hpx+VQpxagdDhxp7zq39aLGvunXYWbla1ZUwlIjZBs15f2w2xDz9rDKJyVHpN0knZKdPNS8Hd8u
	WNdtpQRkenKq6Kx3KwyjPJVRb53XoxN6txdKcOQVyceYqLwP9uU3RCRNVwK80DmaNFxG8fLCOIP
	ganAwmpsrWQ==
X-Google-Smtp-Source: AGHT+IGnvTq5n8Z2jmUY1+XRaqKd//HxTDg/6NfENTi3CHxhZgJ2aardnE0X2gAcTDFPFE8GwVaBgg==
X-Received: by 2002:a17:907:9486:b0:ace:d8d1:a46d with SMTP id a640c23a62f3a-ad218fa889amr361493566b.30.1746806279251;
        Fri, 09 May 2025 08:57:59 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v1 5/6] xen/riscv: add new p2m types and helper macros for type classification
Date: Fri,  9 May 2025 17:57:50 +0200
Message-ID: <52861198c7c363c4b0caf818345f4ffbec056337.1746805907.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

- Extended p2m_type_t with additional types: p2m_ram_ro, p2m_mmio_direct_dev,
  p2m_map_foreign_{rw,ro}, p2m_grant_map_{rw,ro}.
- Added macros to classify memory types: P2M_RAM_TYPES, P2M_GRANT_TYPES,
  P2M_FOREIGN_TYPES.
- Introduced helper predicates: p2m_is_ram(), p2m_is_foreign(),
  p2m_is_any_ram().

Signed-off-by: Oleksii Kurochko 
---
 xen/arch/riscv/include/asm/p2m.h | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 8b46210768..0fcfec7f03 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -80,8 +80,36 @@ struct p2m_domain {
 typedef enum {
     p2m_invalid = 0,    /* Nothing mapped here */
     p2m_ram_rw,         /* Normal read/write domain RAM */
+    p2m_ram_ro,         /* Read-only; writes are silently dropped */
+    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
+    p2m_map_foreign_rw, /* Read/write RAM pages from foreign domain */
+    p2m_map_foreign_ro, /* Read-only RAM pages from foreign domain */
+    p2m_grant_map_rw,   /* Read/write grant mapping */
+    p2m_grant_map_ro,   /* Read-only grant mapping */
 } p2m_type_t;
 
+/* We use bitmaps and mask to handle groups of types */
+#define p2m_to_mask(t_) BIT(t_, UL)
+
+/* RAM types, which map to real machine frames */
+#define P2M_RAM_TYPES (p2m_to_mask(p2m_ram_rw) | \
+                       p2m_to_mask(p2m_ram_ro))
+
+/* Grant mapping types, which map to a real frame in another VM */
+#define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw) | \
+                         p2m_to_mask(p2m_grant_map_ro))
+
+/* Foreign mappings types */
+#define P2M_FOREIGN_TYPES (p2m_to_mask(p2m_map_foreign_rw) | \
+                           p2m_to_mask(p2m_map_foreign_ro))
+
+/* Useful predicates */
+#define p2m_is_ram(t_) (p2m_to_mask(t_) & P2M_RAM_TYPES)
+#define p2m_is_foreign(t_) (p2m_to_mask(t_) & P2M_FOREIGN_TYPES)
+#define p2m_is_any_ram(t_) (p2m_to_mask(t_) & \
+                            (P2M_RAM_TYPES | P2M_GRANT_TYPES | \
+                             P2M_FOREIGN_TYPES))
+
 #include 
 
 static inline int get_page_and_type(struct page_info *page,
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 09 15:58:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 15:58:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980130.1366600 (Exim 4.92)
	(envelope-from )
	id 1uDQ6o-0006LA-3Z; Fri, 09 May 2025 15:57:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980130.1366600; Fri, 09 May 2025 15:57: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 1uDQ6o-0006L3-13; Fri, 09 May 2025 15:57:58 +0000
Received: by outflank-mailman (input) for mailman id 980130;
 Fri, 09 May 2025 15:57:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQ6n-0006Kr-7I
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 15:57:57 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5eac162d-2cee-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 17:57:55 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5fbf52aad74so5314699a12.1
 for ; Fri, 09 May 2025 08:57:55 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad21947a88fsm168723766b.81.2025.05.09.08.57.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 08:57:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5eac162d-2cee-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746806274; x=1747411074; 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;
        bh=hdBFaBjxY+qxq8rNUwVC/SGZ98nsiyPPDeD8bqV1Wcg=;
        b=S243LQ4Kxz0mlNLo3peXJ3pI17QlImY+CoSP2NbaAYNEGZvAMN6eT6LqryjnTFdvgi
         EL/m9wQ4B2oRVS4ldWQR34Li/TqZXKF9v1EWFyliG5JbQAUxEFsaoCzIkH5qPWFudLLc
         Aki5eojX1k5CcANa6On1vVALKny9yS0r1oFwezoZw8das7BgvJ57WKqzMemglRB9wn3N
         ij/xNKvniVH1imJoLcqhr7L4EvzAxZb3sTnYsSSX93Lw0nAC2DX5CZhJKUofteE6iOPw
         ZvJx4kVBZ146TMXsICjbRMNe75U1PwIi28k/2B1ONeDzaGWW93QXl4ZJbSG3EE2VdUjS
         Kgjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746806274; x=1747411074;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=hdBFaBjxY+qxq8rNUwVC/SGZ98nsiyPPDeD8bqV1Wcg=;
        b=d3R74QURJRfRDEWru8DBpgoMFEIEzWn2Ln6OBzlLEcNOPvLunqzbUL+CpzHvE8HL3z
         5SXsEsBnAazfoLdJBzpgv6Ow5KLbNzHHeLlNgtGYiK+/7+bUJorMfak696UKqEST5idI
         UwHxCwV/+xRK2JfHgryuXbkYF4xACrVlKwR1WBQA6I7tugMc5u7F7mtOpzl9mLGjlGgD
         NqLwCFCWJMGqgXqaeJUH/pQbqa9ijk5wOzqQwHIVwzWo3NL/0ZfsQcvhCj5HsnquAKsB
         BWTiFPzd1pmqtroskmBKBDicaOIYkboUbvqz/3Ucwrn3cACmubuW+plKqJKglLjop9o/
         Jx2w==
X-Gm-Message-State: AOJu0Yz0SPgXpBtKzBVOBHuLJu/0TaKsKHm3PnJMlsp0WF7d+xt9h4eQ
	5/niVojGbQ2b7aS3laq35yqS2PycxiWtJH6ydypOGZfNuvmxpw7krJy+Eg==
X-Gm-Gg: ASbGnct7Hp6l1Ngw4JwHTLa6mOuv5L3v4qEbqj6g6+u35fziFkGLtBckY+WEODSujLI
	+re3lA2rHba0FulvFibRjnedYubihVEPd6FSAF0AqD/3Q7+Vgo8q44uAHoa6D3W1ndZq+eO1NEM
	2LFErCSH909gZVYep1GBwWG541LMe6/U5v9Diqlh6Dz9uNB/PTCIwe2WaUM/oFsty4s2Pp3WY8B
	S5hdXp0nMjBjVe1yoIDJlKlFbYqxitfIlvpXmOqRm+OxurA/yg5F/tUZenxU/C+NPZOZot9Gndw
	1UIKPdEYDkOfyNqJp02geK0bNl+ErBDUYtLV6bCr8mspGcv7UJ/QlVUr59/cq8Femwi7GAJX7xn
	EhiysJ5JdxQ==
X-Google-Smtp-Source: AGHT+IEWPkUQh+9oHAHNqG7J7e7AmMoN35jhSt+vKN6nZqmfHf50OPMROWUxr/gEw3OTC8Q1bCM1Rg==
X-Received: by 2002:a17:907:1c92:b0:ac7:b231:9554 with SMTP id a640c23a62f3a-ad21b196510mr365556366b.11.1746806274109;
        Fri, 09 May 2025 08:57:54 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v1 0/6] xen/riscv: introduce p2m functionality
Date: Fri,  9 May 2025 17:57:45 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

In this patch series are introduced necessary functions to build and manage
RISC-V guest page tables and MMIO/RAM mappings.

This patch series is based on the patch [1]:
  https://lore.kernel.org/xen-devel/da9273c20dc7ac1c131322e38a8cef361dfd86a9.1746530883.git.oleksii.kurochko@gmail.com/T/#u

Oleksii Kurochko (6):
  xen/riscv: add inclusion of xen/bitops.h to asm/cmpxchg.h
  xen/riscv: introduce things necessary for p2m initialization
  xen/riscv: construct the P2M pages pool for guests
  xen/riscv: define pt_t and pt_walk_t structures
  xen/riscv: add new p2m types and helper macros for type classification
  xen/riscv: implement p2m mapping functionality

 xen/arch/riscv/Makefile              |    1 +
 xen/arch/riscv/include/asm/cmpxchg.h |    1 +
 xen/arch/riscv/include/asm/domain.h  |   16 +
 xen/arch/riscv/include/asm/mm.h      |   36 +-
 xen/arch/riscv/include/asm/p2m.h     |  121 ++-
 xen/arch/riscv/include/asm/page.h    |   65 +-
 xen/arch/riscv/p2m.c                 | 1015 ++++++++++++++++++++++++++
 7 files changed, 1243 insertions(+), 12 deletions(-)
 create mode 100644 xen/arch/riscv/p2m.c

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 09 15:58:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 15:58:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980136.1366661 (Exim 4.92)
	(envelope-from )
	id 1uDQ6u-0007k8-0H; Fri, 09 May 2025 15:58:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980136.1366661; Fri, 09 May 2025 15:58: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 1uDQ6t-0007j9-Nn; Fri, 09 May 2025 15:58:03 +0000
Received: by outflank-mailman (input) for mailman id 980136;
 Fri, 09 May 2025 15:58:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQ6s-0006Ks-Ar
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 15:58:02 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 626e0f93-2cee-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 17:58:01 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ac2ab99e16eso450199566b.0
 for ; Fri, 09 May 2025 08:58:01 -0700 (PDT)
Received: from fedora.. (user-109-243-69-225.play-internet.pl.
 [109.243.69.225]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad21947a88fsm168723766b.81.2025.05.09.08.57.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 08:57: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" 
X-Inumbo-ID: 626e0f93-2cee-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746806281; x=1747411081; 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;
        bh=fggvTYSwOTWplurf3s3S6bhydsxGV/TZFhAArb8TvRo=;
        b=QHt7T9vOpEWWNdoL4q0sPa0nh2MSlBb2mGXhPGqDHbQ5zHoZ+oWuyCO2pO+q9wAJn5
         yQOxR59igIdgEKXs4NuXk8X6uClmUzqUzMTky3lFczXd/o4MYVHEDb3Yv1UcVzGnwpGt
         hWEcScj2FpAjfEvp95yZ0UhCFRg0MIvRd8CCEGAiLMOYM13cia8UkNseR3LbDsqL6N+g
         PaFO5tqIOup3CSMOJnwRWK5RR//XD+VxATlmaqYRtL6ea1LSiTd8f7ADmHQIrebh6zcL
         W8G9tIjarxBQhE1JVYDAgbLhye8minV16x7MB1KfhmUY8BSvrtSe/aUZH5Cv+F1xJIWw
         DTNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746806281; x=1747411081;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fggvTYSwOTWplurf3s3S6bhydsxGV/TZFhAArb8TvRo=;
        b=XZiYj/gOqpxMWv/AXTFVWcwfRz1XM1/dIvR9OnWWf1zVFesFF4q6WQWpHx68+Zo/aN
         qxpCoQx5+uKEZHjWnYpwDxsHOgd31l4eQ12NAgMeXihUhu9ZsZleOs8+bHoAIO3Igy44
         VZaBIdGqhHCLSl8VBOBcGHM6CDPYfsiiR9CTcWpIgChOLu3jDOF4C7aoecskjSW4L+vQ
         6LS52ynW5Ml6239g7b1fy9NGEgUdVcnWow3DW4aYYdhAYDS/Itnp8OeBI+SbUB6bmFA9
         FyST+Qs4YXnS0RFM0LJ1J20H01tY4kvxPhTcOkJbF1nZIzNP+Jm+neNE2DbAeHnZJ8Ag
         o51w==
X-Gm-Message-State: AOJu0YyFrfLWQ0zg3o9jIHUQGvCC2BK+WXe8qDTWt/cv3wdHIJ0NgMk6
	b+JpTWXX611/MKovmhubxOhWKQGrUH2G7L+EL+0WNv6QtjVJ22MfYYaYBg==
X-Gm-Gg: ASbGncsPLmwYo/AuwVNLbbk19f6lBu64l71sMiRDM76szxyXiOzapbc/ugDlMHXKjoT
	BciI8p3jShA++TH/vSq6YAk99bq7Xagg4PCwpHraJI/J5EVsRE1jv6Mn+UWs92tsNs78uzXMG0O
	nZIy+WZpW/xTz+lSc+s83G3hvEHKizqgEW/uLhdShZeEHCRzQq96RbjtZvKF8BaV49oJOL0DZKR
	iA1pE8wXb5vqUEHBpD1y4kpn/5+5Y0VSs00M8yG5teLCZsxGWpv408hr4fjKaJ4qqUEAAlCAQ7Q
	CsILpS3PFDSqnFTmjKnMbIwOKUkfTej1U6+7vZwFWbrYojYUPQ808dCajhY46tERJaXLUVUHqtz
	NzRegr7Sm0w==
X-Google-Smtp-Source: AGHT+IERO9vfGg9X90kgPsdY4amzJgxeoNXm8QvJJwy506pTVmqWxyWlwT+eJtke7o4974rMf/304g==
X-Received: by 2002:a17:907:7da2:b0:ad1:f880:5796 with SMTP id a640c23a62f3a-ad21901c802mr436898466b.33.1746806280319;
        Fri, 09 May 2025 08:58:00 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v1 6/6] xen/riscv: implement p2m mapping functionality
Date: Fri,  9 May 2025 17:57:51 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

These utilities are needed for building and managing RISC-V guest page
tables and MMIO mappings by using functions map_regions_p2mt() and
guest_physmap_add_entry().

To implement p2m mapping functionality the following is introduced:
- Define P2M root level/order and entry count.
- Introdude radix type for p2m types as it isn't enough free bits in pte
  and the helpers (p2m_type_radix_{get,set}()) to deal with them.
- Introduce p2m_is_*() helpers() as  pte_is_*() helpers are checking
  the valid bit set in the PTE but we have to check p2m_type instead
  (look at the comment above p2m_is_valid() for some details).
- Introduce helper to set p2m's pte permission: p2m_set_permissions().
- Introduce helper to create p2m entry based on mfn, p2m_type_t and
  p2m_access_t.
- Introduce helper to generate table entry with correct attributes:
  page_to_p2m_table().
- Introduce p2m page allocation function: p2m_alloc_page().
- Introduce functions to write/remove p2m's entries: p2m_{write,remove}_pte().
- Introduce function to allocate p2m table: p2m_create_table().
- Introduce functions used to free p2m entry.
- Introduce function for table walking: p2m_next_level().
- Introduce function to insert an entry in the p2m (p2m_set_entry()).
- Introduce superpage splitting: p2m_split_superpage()).
- Introduce page table type defines (PGT_{none,writable_page}, etc).

Signed-off-by: Oleksii Kurochko 
---
 xen/arch/riscv/include/asm/mm.h   |  32 +-
 xen/arch/riscv/include/asm/p2m.h  |  17 +-
 xen/arch/riscv/include/asm/page.h |  11 +
 xen/arch/riscv/p2m.c              | 780 ++++++++++++++++++++++++++++++
 4 files changed, 829 insertions(+), 11 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 972ec45448..c1e4519839 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 extern vaddr_t directmap_virt_start;
@@ -229,9 +230,21 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
 #define PGT_writable_page PG_mask(1, 1)  /* has writable mappings?         */
 #define PGT_type_mask     PG_mask(1, 1)  /* Bits 31 or 63.                 */
 
-/* Count of uses of this frame as its current type. */
-#define PGT_count_width   PG_shift(2)
-#define PGT_count_mask    ((1UL << PGT_count_width) - 1)
+ /* 9-bit count of uses of this frame as its current type. */
+#define PGT_count_mask    PG_mask(0x3FF, 10)
+
+/*
+ * Sv32 has 22-bit GFN. Sv{39, 48, 57} have 44-bit GFN.
+ * Thereby we can use for `type_info` 10 bits for all modes, having the same
+ * amount of bits for `type_info` for all MMU modes let us avoid introducing
+ * an extra #ifdef to that header:
+ *   if we go with maximum possible bits for count on each configuration
+ *   we would need to have a set of PGT_count_* and PGT_gfn_*).
+ */
+#define PGT_gfn_width     PG_shift(10)
+#define PGT_gfn_mask      (BIT(PGT_gfn_width, UL) - 1)
+
+#define PGT_INVALID_XENHEAP_GFN   _gfn(PGT_gfn_mask)
 
 /*
  * Page needs to be scrubbed. Since this bit can only be set on a page that is
@@ -283,6 +296,19 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr)
 
 #define PFN_ORDER(pg) ((pg)->v.free.order)
 
+static inline void page_set_xenheap_gfn(struct page_info *p, gfn_t gfn)
+{
+    gfn_t gfn_ = gfn_eq(gfn, INVALID_GFN) ? PGT_INVALID_XENHEAP_GFN : gfn;
+    unsigned long x, nx, y = p->u.inuse.type_info;
+
+    ASSERT(is_xen_heap_page(p));
+
+    do {
+        x = y;
+        nx = (x & ~PGT_gfn_mask) | gfn_x(gfn_);
+    } while ( (y = cmpxchg(&p->u.inuse.type_info, x, nx)) != x );
+}
+
 extern unsigned char cpu0_boot_stack[];
 
 void setup_initial_pagetables(void);
diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
index 0fcfec7f03..9f4633501f 100644
--- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -9,8 +9,13 @@
 #include 
 #include 
 
+#include 
 #include 
 
+#define P2M_ROOT_LEVEL  HYP_PT_ROOT_LEVEL
+#define P2M_ROOT_ORDER  XEN_PT_LEVEL_ORDER(P2M_ROOT_LEVEL)
+#define P2M_ROOT_PAGES  (1U << P2M_ROOT_ORDER)
+
 #define paddr_bits PADDR_BITS
 
 /* Get host p2m table */
@@ -145,14 +150,10 @@ static inline int guest_physmap_mark_populate_on_demand(struct domain *d,
     return -EOPNOTSUPP;
 }
 
-static inline int guest_physmap_add_entry(struct domain *d,
-                                          gfn_t gfn, mfn_t mfn,
-                                          unsigned long page_order,
-                                          p2m_type_t t)
-{
-    BUG_ON("unimplemented");
-    return -EINVAL;
-}
+int guest_physmap_add_entry(struct domain *d,
+                            gfn_t gfn, mfn_t mfn,
+                            unsigned long page_order,
+                            p2m_type_t t);
 
 /* Untyped version for RAM only, for compatibility */
 static inline int __must_check
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index cb3dea309c..a5c6f5140d 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -22,6 +22,7 @@
 #define XEN_PT_LEVEL_SIZE(lvl)      (_AT(paddr_t, 1) << XEN_PT_LEVEL_SHIFT(lvl))
 #define XEN_PT_LEVEL_MAP_MASK(lvl)  (~(XEN_PT_LEVEL_SIZE(lvl) - 1))
 #define XEN_PT_LEVEL_MASK(lvl)      (VPN_MASK << XEN_PT_LEVEL_SHIFT(lvl))
+#define XEN_PT_ENTRIES              (_AT(unsigned int, 1) << PAGETABLE_ORDER)
 
 /*
  * PTE format:
@@ -69,10 +70,20 @@
 #define PTE_PMBT_NOCACHE    BIT(61, UL)
 #define PTE_PMBT_IO         BIT(62, UL)
 
+enum pmbt_type_t {
+    pbmt_pma,
+    pbmt_nc,
+    pbmt_io,
+    pbmt_rsvd,
+    pbmt_max,
+};
+
 #define PTE_ACCESS_MASK (PTE_READABLE | PTE_WRITABLE | PTE_EXECUTABLE)
 
 #define PTE_PBMT_MASK   (PTE_PMBT_NOCACHE | PTE_PMBT_IO)
 
+#define P2M_CLEAR_PERM(p2m_pte) ((p2m_pte).pte & ~PTE_ACCESS_MASK)
+
 /* Calculate the offsets into the pagetables for a given VA */
 #define pt_linear_offset(lvl, va)   ((va) >> XEN_PT_LEVEL_SHIFT(lvl))
 
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index a890870391..84cb3d28af 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -135,6 +135,37 @@ static int p2m_alloc_table(struct domain *d)
     return 0;
 }
 
+static p2m_type_t p2m_type_radix_get(struct p2m_domain *p2m, pte_t pte)
+{
+    void *ptr;
+
+    ptr = radix_tree_lookup(&p2m->p2m_type, pte.pte);
+
+    if ( !ptr )
+        return p2m_invalid;
+
+    return radix_tree_ptr_to_int(ptr);
+}
+
+static int p2m_type_radix_set(struct p2m_domain *p2m, pte_t pte, p2m_type_t t)
+{
+    int rc;
+
+    rc = radix_tree_insert(&p2m->p2m_type, pte.pte,
+                           radix_tree_int_to_ptr(t));
+    if ( rc == -EEXIST )
+    {
+        /* If a setting already exists, change it to the new one */
+        radix_tree_replace_slot(
+            radix_tree_lookup_slot(
+                &p2m->p2m_type, pte.pte),
+            radix_tree_int_to_ptr(t));
+        rc = 0;
+    }
+
+    return rc;
+}
+
 int p2m_init(struct domain *d)
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -233,3 +264,752 @@ int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
 
     return 0;
 }
+
+/*
+ * Find and map the root page table. The caller is responsible for
+ * unmapping the table.
+ *
+ * The function will return NULL if the offset of the root table is
+ * invalid.
+ */
+static pte_t *p2m_get_root_pointer(struct p2m_domain *p2m, gfn_t gfn)
+{
+    unsigned long root_table;
+
+    root_table = gfn_x(gfn) >> XEN_PT_LEVEL_ORDER(P2M_ROOT_LEVEL);
+    if ( root_table >= P2M_ROOT_PAGES )
+        return NULL;
+
+    return __map_domain_page(p2m->root + root_table);
+}
+
+/*
+ * In the case of the P2M, the valid bit is used for other purpose. Use
+ * the type to check whether an entry is valid.
+ */
+static inline bool p2m_is_valid(struct p2m_domain *p2m, pte_t pte)
+{
+    return p2m_type_radix_get(p2m, pte) != p2m_invalid;
+}
+
+/*
+ * pte_is_* helpers are checking the valid bit set in the
+ * PTE but we have to check p2m_type instead (look at the comment above
+ * p2m_is_valid())
+ * Provide our own overlay to check the valid bit.
+ */
+static inline bool p2m_is_mapping(struct p2m_domain *p2m, pte_t pte)
+{
+    return p2m_is_valid(p2m, pte) && (pte.pte & PTE_ACCESS_MASK);
+}
+
+static inline bool p2m_is_superpage(struct p2m_domain *p2m, pte_t pte,
+                                    unsigned int level)
+{
+    return p2m_is_valid(p2m, pte) && (pte.pte & PTE_ACCESS_MASK) &&
+           (level > 0);
+}
+
+static void p2m_set_permission(pte_t *e, p2m_type_t t, p2m_access_t a)
+{
+    /* First apply type permissions */
+    switch ( t )
+    {
+    case p2m_ram_rw:
+        e->bits.r = 1;
+        e->bits.w = 1;
+        e->bits.x = 1;
+
+        break;
+
+    case p2m_mmio_direct_dev:
+        e->bits.r = 1;
+        e->bits.w = 1;
+        e->bits.x = 0;
+        break;
+
+    case p2m_invalid:
+        e->bits.r = 0;
+        e->bits.w = 0;
+        e->bits.x = 0;
+        break;
+
+    default:
+        BUG();
+        break;
+    }
+
+    /* Then restrict with access permissions */
+    switch ( a )
+    {
+    case p2m_access_rwx:
+        break;
+    case p2m_access_wx:
+        e->bits.r = 0;
+        break;
+    case p2m_access_rw:
+        e->bits.x = 0;
+        break;
+    case p2m_access_w:
+        e->bits.r = 0;
+        e->bits.x = 0;
+        break;
+    case p2m_access_rx:
+    case p2m_access_rx2rw:
+        e->bits.w = 0;
+        break;
+    case p2m_access_x:
+        e->bits.r = 0;
+        e->bits.w = 0;
+        break;
+    case p2m_access_r:
+        e->bits.w = 0;
+        e->bits.x = 0;
+        break;
+    case p2m_access_n:
+    case p2m_access_n2rwx:
+        e->bits.r = 0;
+        e->bits.w = 0;
+        e->bits.x = 0;
+        break;
+    default:
+        BUG();
+        break;
+    }
+}
+
+static pte_t p2m_entry_from_mfn(struct p2m_domain *p2m, mfn_t mfn, p2m_type_t t, p2m_access_t a)
+{
+    pte_t e = (pte_t) {
+        .bits.v = 1,
+    };
+
+    switch ( t )
+    {
+    case p2m_mmio_direct_dev:
+        e.bits.pbmt = pbmt_io;
+        break;
+
+    default:
+        e.bits.pbmt = pbmt_pma;
+        break;
+    }
+
+    p2m_set_permission(&e, t, a);
+
+    ASSERT(!(mfn_to_maddr(mfn) & ~PADDR_MASK));
+
+    pte_set_mfn(&e, mfn);
+
+    BUG_ON(p2m_type_radix_set(p2m, e, t));
+
+    return e;
+}
+
+/* Generate table entry with correct attributes. */
+static pte_t page_to_p2m_table(struct p2m_domain *p2m, struct page_info *page)
+{
+    /*
+     * Since this function generates a table entry, according to "Encoding
+     * of PTE R/W/X fields," the entry's r, w, and x fields must be set to 0
+     * to point to the next level of the page table.
+     * Therefore, to ensure that an entry is a page table entry,
+     * `p2m_access_n2rwx` is passed to `mfn_to_p2m_entry()` as the access value,
+     * which overrides whatever was passed as `p2m_type_t` and guarantees that
+     * the entry is a page table entry by setting r = w = x = 0.
+     */
+    return p2m_entry_from_mfn(p2m, page_to_mfn(page), p2m_ram_rw, p2m_access_n2rwx);
+}
+
+static struct page_info *p2m_alloc_page(struct domain *d)
+{
+    struct page_info *pg;
+
+    /*
+     * For hardware domain, there should be no limit in the number of pages that
+     * can be allocated, so that the kernel may take advantage of the extended
+     * regions. Hence, allocate p2m pages for hardware domains from heap.
+     */
+    if ( is_hardware_domain(d) )
+    {
+        pg = alloc_domheap_page(d, MEMF_no_owner);
+        if ( pg == NULL )
+            printk(XENLOG_G_ERR "Failed to allocate P2M pages for hwdom.\n");
+    }
+    else
+    {
+        spin_lock(&d->arch.paging.lock);
+        pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
+        spin_unlock(&d->arch.paging.lock);
+    }
+
+    return pg;
+}
+
+static inline void p2m_write_pte(pte_t *p, pte_t pte, bool clean_pte)
+{
+    write_pte(p, pte);
+    if ( clean_pte )
+        clean_dcache_va_range(p, sizeof(*p));
+}
+
+static inline void p2m_remove_pte(pte_t *p, bool clean_pte)
+{
+    pte_t pte;
+
+    memset(&pte, 0x00, sizeof(pte));
+    p2m_write_pte(p, pte, clean_pte);
+}
+
+/* Allocate a new page table page and hook it in via the given entry. */
+static int p2m_create_table(struct p2m_domain *p2m, pte_t *entry)
+{
+    struct page_info *page;
+    pte_t *p;
+
+    ASSERT(!p2m_is_valid(p2m, *entry));
+
+    page = p2m_alloc_page(p2m->domain);
+    if ( page == NULL )
+        return -ENOMEM;
+
+    page_list_add(page, &p2m->pages);
+
+    p = __map_domain_page(page);
+    clear_page(p);
+
+    unmap_domain_page(p);
+
+    p2m_write_pte(entry, page_to_p2m_table(p2m, page), p2m->clean_pte);
+
+    return 0;
+}
+
+#define GUEST_TABLE_MAP_NONE 0
+#define GUEST_TABLE_MAP_NOMEM 1
+#define GUEST_TABLE_SUPER_PAGE 2
+#define GUEST_TABLE_NORMAL 3
+
+/*
+ * Take the currently mapped table, find the corresponding GFN entry,
+ * and map the next table, if available. The previous table will be
+ * unmapped if the next level was mapped (e.g GUEST_TABLE_NORMAL
+ * returned).
+ *
+ * `alloc_tbl` parameter indicates whether intermediate tables should
+ * be allocated when not present.
+ *
+ * Return values:
+ *  GUEST_TABLE_MAP_NONE: a table allocation isn't permitted.
+ *  GUEST_TABLE_MAP_NOMEM: allocating a new page failed.
+ *  GUEST_TABLE_SUPER_PAGE: next level or leaf mapped normally.
+ *  GUEST_TABLE_NORMAL: The next entry points to a superpage.
+ */
+static int p2m_next_level(struct p2m_domain *p2m, bool alloc_tbl,
+                          unsigned int level, pte_t **table,
+                          unsigned int offset)
+{
+    pte_t *entry;
+    int ret;
+    mfn_t mfn;
+
+    entry = *table + offset;
+
+    if ( !p2m_is_valid(p2m, *entry) )
+    {
+        if ( !alloc_tbl )
+            return GUEST_TABLE_MAP_NONE;
+
+        ret = p2m_create_table(p2m, entry);
+        if ( ret )
+            return GUEST_TABLE_MAP_NOMEM;
+    }
+
+    /* The function p2m_next_level() is never called at the last level */
+    ASSERT(level != 0);
+    if ( p2m_is_mapping(p2m, *entry) )
+        return GUEST_TABLE_SUPER_PAGE;
+
+    mfn = mfn_from_pte(*entry);
+
+    unmap_domain_page(*table);
+    *table = map_domain_page(mfn);
+
+    return GUEST_TABLE_NORMAL;
+}
+
+static bool p2m_split_superpage(struct p2m_domain *p2m, pte_t *entry,
+                                unsigned int level, unsigned int target,
+                                const unsigned int *offsets)
+{
+    struct page_info *page;
+    unsigned int i;
+    pte_t pte, *table;
+    bool rv = true;
+
+    /* Convenience aliases */
+    mfn_t mfn = pte_get_mfn(*entry);
+    unsigned int next_level = level - 1;
+    unsigned int level_order = XEN_PT_LEVEL_ORDER(next_level);
+
+    /*
+     * This should only be called with target != level and the entry is
+     * a superpage.
+     */
+    ASSERT(level > target);
+    ASSERT(p2m_is_superpage(p2m, *entry, level));
+
+    page = p2m_alloc_page(p2m->domain);
+    if ( !page )
+        return false;
+
+    page_list_add(page, &p2m->pages);
+    table = __map_domain_page(page);
+
+    /*
+     * We are either splitting a first level 1G page into 512 second level
+     * 2M pages, or a second level 2M page into 512 third level 4K pages.
+     */
+    for ( i = 0; i < XEN_PT_ENTRIES; i++ )
+    {
+        pte_t *new_entry = table + i;
+
+        /*
+         * Use the content of the superpage entry and override
+         * the necessary fields. So the correct permission are kept.
+         */
+        pte = *entry;
+        pte_set_mfn(&pte, mfn_add(mfn, i << level_order));
+
+        write_pte(new_entry, pte);
+    }
+
+    /*
+     * Shatter superpage in the page to the level we want to make the
+     * changes.
+     * This is done outside the loop to avoid checking the offset to
+     * know whether the entry should be shattered for every entry.
+     */
+    if ( next_level != target )
+        rv = p2m_split_superpage(p2m, table + offsets[next_level],
+                                 level - 1, target, offsets);
+
+    /* TODO: why it is necessary to have clean here? Not somewhere in the caller */
+    if ( p2m->clean_pte )
+        clean_dcache_va_range(table, PAGE_SIZE);
+
+    unmap_domain_page(table);
+
+    /*
+     * Even if we failed, we should install the newly allocated PTE
+     * entry. The caller will be in charge to free the sub-tree.
+     */
+    p2m_write_pte(entry, page_to_p2m_table(p2m, page), p2m->clean_pte);
+
+    return rv;
+}
+
+static void p2m_put_foreign_page(struct page_info *pg)
+{
+    /*
+     * It's safe to do the put_page here because page_alloc will
+     * flush the TLBs if the page is reallocated before the end of
+     * this loop.
+     */
+    put_page(pg);
+}
+
+/* Put any references on the single 4K page referenced by mfn. */
+static void p2m_put_4k_page(mfn_t mfn, p2m_type_t type)
+{
+    /* TODO: Handle other p2m types */
+    if ( p2m_is_foreign(type) )
+    {
+        ASSERT(mfn_valid(mfn));
+        p2m_put_foreign_page(mfn_to_page(mfn));
+    }
+    /* Detect the xenheap page and mark the stored GFN as invalid. */
+    else if ( p2m_is_ram(type) && is_xen_heap_mfn(mfn) )
+        page_set_xenheap_gfn(mfn_to_page(mfn), INVALID_GFN);
+}
+
+/* Put any references on the superpage referenced by mfn. */
+static void p2m_put_2m_superpage(mfn_t mfn, p2m_type_t type)
+{
+    struct page_info *pg;
+    unsigned int i;
+
+    /*
+     * TODO: Handle other p2m types, but be aware that any changes to handle
+     * different types should require an update on the relinquish code to handle
+     * preemption.
+     */
+    if ( !p2m_is_foreign(type) )
+        return;
+
+    ASSERT(mfn_valid(mfn));
+
+    pg = mfn_to_page(mfn);
+
+    for ( i = 0; i < XEN_PT_ENTRIES; i++, pg++ )
+        p2m_put_foreign_page(pg);
+}
+
+/* Put any references on the page referenced by pte. */
+static void p2m_put_page(struct p2m_domain *p2m, const pte_t pte,
+                         unsigned int level)
+{
+    mfn_t mfn = pte_get_mfn(pte);
+    p2m_type_t p2m_type = p2m_type_radix_get(p2m, pte);
+
+    ASSERT(p2m_is_valid(p2m, pte));
+
+    /*
+     * TODO: Currently we don't handle level 2 super-page, Xen is not
+     * preemptible and therefore some work is needed to handle such
+     * superpages, for which at some point Xen might end up freeing memory
+     * and therefore for such a big mapping it could end up in a very long
+     * operation.
+     */
+    if ( level == 1 )
+        return p2m_put_2m_superpage(mfn, p2m_type);
+    else if ( level == 0 )
+        return p2m_put_4k_page(mfn, p2m_type);
+}
+
+static void p2m_free_page(struct domain *d, struct page_info *pg)
+{
+    if ( is_hardware_domain(d) )
+        free_domheap_page(pg);
+    else
+    {
+        spin_lock(&d->arch.paging.lock);
+        page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
+        spin_unlock(&d->arch.paging.lock);
+    }
+}
+
+/* Free pte sub-tree behind an entry */
+static void p2m_free_entry(struct p2m_domain *p2m,
+                           pte_t entry, unsigned int level)
+{
+    unsigned int i;
+    pte_t *table;
+    mfn_t mfn;
+    struct page_info *pg;
+
+    /* Nothing to do if the entry is invalid. */
+    if ( !p2m_is_valid(p2m, entry) )
+        return;
+
+    if ( p2m_is_superpage(p2m, entry, level) || (level == 0) )
+    {
+#ifdef CONFIG_IOREQ_SERVER
+        /*
+         * If this gets called then either the entry was replaced by an entry
+         * with a different base (valid case) or the shattering of a superpage
+         * has failed (error case).
+         * So, at worst, the spurious mapcache invalidation might be sent.
+         */
+        if ( p2m_is_ram( p2m_type_radix_get(p2m, entry)) &&
+             domain_has_ioreq_server(p2m->domain) )
+            ioreq_request_mapcache_invalidate(p2m->domain);
+#endif
+
+        p2m_put_page(p2m, entry, level);
+
+        return;
+    }
+
+    table = map_domain_page(pte_get_mfn(entry));
+    for ( i = 0; i < XEN_PT_ENTRIES; i++ )
+        p2m_free_entry(p2m, *(table + i), level - 1);
+
+    unmap_domain_page(table);
+
+    /*
+     * Make sure all the references in the TLB have been removed before
+     * freing the intermediate page table.
+     * XXX: Should we defer the free of the page table to avoid the
+     * flush?
+     */
+    p2m_tlb_flush_sync(p2m);
+
+    mfn = pte_get_mfn(entry);
+    ASSERT(mfn_valid(mfn));
+
+    pg = mfn_to_page(mfn);
+
+    page_list_del(pg, &p2m->pages);
+    p2m_free_page(p2m->domain, pg);
+}
+
+/*
+ * Insert an entry in the p2m. This should be called with a mapping
+ * equal to a page/superpage.
+ */
+static int __p2m_set_entry(struct p2m_domain *p2m,
+                           gfn_t sgfn,
+                           unsigned int page_order,
+                           mfn_t smfn,
+                           p2m_type_t t,
+                           p2m_access_t a)
+{
+    unsigned int level;
+    unsigned int target = page_order / PAGETABLE_ORDER;
+    pte_t *entry, *table, orig_pte;
+    int rc;
+    /* A mapping is removed if the MFN is invalid. */
+    bool removing_mapping = mfn_eq(smfn, INVALID_MFN);
+    DECLARE_OFFSETS(offsets, gfn_to_gaddr(sgfn));
+
+    ASSERT(p2m_is_write_locked(p2m));
+
+    /*
+     * Check if the level target is valid: we only support
+     * 4K - 2M - 1G mapping.
+     */
+    ASSERT(target <= 2);
+
+    table = p2m_get_root_pointer(p2m, sgfn);
+    if ( !table )
+        return -EINVAL;
+
+    for ( level = P2M_ROOT_LEVEL; level > target; level-- )
+    {
+        /*
+         * Don't try to allocate intermediate page table if the mapping
+         * is about to be removed.
+         */
+        rc = p2m_next_level(p2m, !removing_mapping,
+                            level, &table, offsets[level]);
+        if ( (rc == GUEST_TABLE_MAP_NONE) || (rc == GUEST_TABLE_MAP_NOMEM) )
+        {
+            /*
+             * We are here because p2m_next_level has failed to map
+             * the intermediate page table (e.g the table does not exist
+             * and they p2m tree is read-only). It is a valid case
+             * when removing a mapping as it may not exist in the
+             * page table. In this case, just ignore it.
+             */
+            rc = removing_mapping ?  0 : -ENOENT;
+            goto out;
+        }
+        else if ( rc != GUEST_TABLE_NORMAL )
+            break;
+    }
+
+    entry = table + offsets[level];
+
+    /*
+     * If we are here with level > target, we must be at a leaf node,
+     * and we need to break up the superpage.
+     */
+    if ( level > target )
+    {
+        /* We need to split the original page. */
+        pte_t split_pte = *entry;
+
+        ASSERT(p2m_is_superpage(p2m, *entry, level));
+
+        if ( !p2m_split_superpage(p2m, &split_pte, level, target, offsets) )
+        {
+            /* Free the allocated sub-tree */
+            p2m_free_entry(p2m, split_pte, level);
+
+            rc = -ENOMEM;
+            goto out;
+        }
+
+        /* Follow the break-before-sequence to update the entry. */
+        p2m_remove_pte(entry, p2m->clean_pte);
+        p2m_force_tlb_flush_sync(p2m);
+
+        p2m_write_pte(entry, split_pte, p2m->clean_pte);
+
+        /* Then move to the level we want to make real changes */
+        for ( ; level < target; level++ )
+        {
+            rc = p2m_next_level(p2m, true, level, &table, offsets[level]);
+
+            /*
+             * The entry should be found and either be a table
+             * or a superpage if level 0 is not targeted
+             */
+            ASSERT(rc == GUEST_TABLE_NORMAL ||
+                   (rc == GUEST_TABLE_SUPER_PAGE && target > 0));
+        }
+
+        entry = table + offsets[level];
+    }
+
+    /*
+     * We should always be there with the correct level because
+     * all the intermediate tables have been installed if necessary.
+     */
+    ASSERT(level == target);
+
+    orig_pte = *entry;
+
+    /*
+     * The access type should always be p2m_access_rwx when the mapping
+     * is removed.
+     */
+    ASSERT(!mfn_eq(INVALID_MFN, smfn) || (a == p2m_access_rwx));
+
+    /*
+     * Always remove the entry in order to follow the break-before-make
+     * sequence when updating the translation table.
+     */
+    if ( pte_is_valid(orig_pte) || removing_mapping )
+        p2m_remove_pte(entry, p2m->clean_pte);
+
+    if ( removing_mapping )
+        /* Flush can be deferred if the entry is removed */
+        p2m->need_flush |= !!pte_is_valid(orig_pte);
+    else
+    {
+        pte_t pte = p2m_entry_from_mfn(p2m, smfn, t, a);
+
+        /*
+         * It is necessary to flush the TLB before writing the new entry
+         * to keep coherency when the previous entry was valid.
+         *
+         * Although, it could be defered when only the permissions are
+         * changed (e.g in case of memaccess).
+         */
+        if ( pte_is_valid(orig_pte) )
+        {
+            if ( P2M_CLEAR_PERM(pte) != P2M_CLEAR_PERM(orig_pte) )
+                p2m_force_tlb_flush_sync(p2m);
+            else
+                p2m->need_flush = true;
+        }
+
+        p2m_write_pte(entry, pte, p2m->clean_pte);
+
+        p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn,
+                                      gfn_add(sgfn, (1UL << page_order) - 1));
+        p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, sgfn);
+    }
+
+#ifdef CONFIG_HAS_PASSTHROUGH
+    if ( is_iommu_enabled(p2m->domain) &&
+         (pte_is_valid(orig_pte) || pte_is_valid(*entry)) )
+    {
+        unsigned int flush_flags = 0;
+
+        if ( pte_is_valid(orig_pte) )
+            flush_flags |= IOMMU_FLUSHF_modified;
+        if ( pte_is_valid(*entry) )
+            flush_flags |= IOMMU_FLUSHF_added;
+
+        rc = iommu_iotlb_flush(p2m->domain, _dfn(gfn_x(sgfn)),
+                               1UL << page_order, flush_flags);
+    }
+    else
+#endif
+        rc = 0;
+
+    /*
+     * Free the entry only if the original pte was valid and the base
+     * is different (to avoid freeing when permission is changed).
+     */
+    if ( p2m_is_valid(p2m, orig_pte) &&
+         !mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte)) )
+        p2m_free_entry(p2m, orig_pte, level);
+
+out:
+    unmap_domain_page(table);
+
+    return rc;
+}
+
+int p2m_set_entry(struct p2m_domain *p2m,
+                  gfn_t sgfn,
+                  unsigned long nr,
+                  mfn_t smfn,
+                  p2m_type_t t,
+                  p2m_access_t a)
+{
+    int rc = 0;
+
+    /*
+     * Any reference taken by the P2M mappings (e.g. foreign mapping) will
+     * be dropped in relinquish_p2m_mapping(). As the P2M will still
+     * be accessible after, we need to prevent mapping to be added when the
+     * domain is dying.
+     */
+    if ( unlikely(p2m->domain->is_dying) )
+        return -ENOMEM;
+
+    while ( nr )
+    {
+        unsigned long mask;
+        unsigned long order = 0;
+        /* 1gb, 2mb, 4k mappings are supported */
+        unsigned int i = ( P2M_ROOT_LEVEL > 2 ) ? 2 : P2M_ROOT_LEVEL;
+
+        /*
+         * Don't take into account the MFN when removing mapping (i.e
+         * MFN_INVALID) to calculate the correct target order.
+         *
+         * XXX: Support superpage mappings if nr is not aligned to a
+         * superpage size.
+         */
+        mask = !mfn_eq(smfn, INVALID_MFN) ? mfn_x(smfn) : 0;
+        mask |= gfn_x(sgfn) | nr;
+
+        for ( ; i != 0; i-- )
+        {
+            if ( !(mask & (BIT(XEN_PT_LEVEL_ORDER(i), UL) - 1)) )
+            {
+                    order = XEN_PT_LEVEL_ORDER(i);
+                    break;
+            }
+        }
+
+        rc = __p2m_set_entry(p2m, sgfn, order, smfn, t, a);
+        if ( rc )
+            break;
+
+        sgfn = gfn_add(sgfn, (1 << order));
+        if ( !mfn_eq(smfn, INVALID_MFN) )
+           smfn = mfn_add(smfn, (1 << order));
+
+        nr -= (1 << order);
+    }
+
+    return rc;
+}
+
+static int p2m_insert_mapping(struct domain *d, gfn_t start_gfn,
+                              unsigned long nr, mfn_t mfn, p2m_type_t t)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int rc;
+
+    p2m_write_lock(p2m);
+    rc = p2m_set_entry(p2m, start_gfn, nr, mfn, t, p2m->default_access);
+    p2m_write_unlock(p2m);
+
+    return rc;
+}
+
+int map_regions_p2mt(struct domain *d,
+                     gfn_t gfn,
+                     unsigned long nr,
+                     mfn_t mfn,
+                     p2m_type_t p2mt)
+{
+    return p2m_insert_mapping(d, gfn, nr, mfn, p2mt);
+}
+
+int guest_physmap_add_entry(struct domain *d,
+                            gfn_t gfn,
+                            mfn_t mfn,
+                            unsigned long page_order,
+                            p2m_type_t t)
+{
+    return p2m_insert_mapping(d, gfn, (1 << page_order), mfn, t);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 09 16:00:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 16:00:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980176.1366671 (Exim 4.92)
	(envelope-from )
	id 1uDQ8x-0002yY-HQ; Fri, 09 May 2025 16:00:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980176.1366671; Fri, 09 May 2025 16:00: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 1uDQ8x-0002yR-E0; Fri, 09 May 2025 16:00:11 +0000
Received: by outflank-mailman (input) for mailman id 980176;
 Fri, 09 May 2025 16:00:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQ8w-0002yI-3m
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 16:00:10 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ae87a847-2cee-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 18:00:09 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-43ce70f9afbso24099385e9.0
 for ; Fri, 09 May 2025 09:00:09 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442d67d74c0sm34066805e9.3.2025.05.09.09.00.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 09:00: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" 
X-Inumbo-ID: ae87a847-2cee-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746806408; x=1747411208; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tMn6+fuiwGgksToBwVufjtRLsjgsl32mgBns5CI+TlY=;
        b=oqOsf9vcPs/QrPQ73MFmrV0mOWEEMgr7seA2Lz1qA64kOTS+KSKOqDVhqHKQAdMO3K
         OIafDUYDcen+qEMX01lsAZbhBefZmxamJMiVKuoEeC0ucDSmTqlOW+JvidksxZluNpdg
         vNS2pVc5fHGrAtnVd8sW3MUtLO5hMTSwD8t1c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746806408; x=1747411208;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tMn6+fuiwGgksToBwVufjtRLsjgsl32mgBns5CI+TlY=;
        b=WRKo5Oq2pPumJjz0/SYSH9Niw9uL0KDMa4sJAijc/ic49f+RqD3QlQiRhtJc3v7rXx
         AH8mooZNiNtPsHgt+MVSxN/J9shGrvcaW+WsI3JmSGoY826h5HOCkeJjxQ0NLLpuL5AE
         97dbPcPmCKd4NT9Rji2Wd/p4efH1KLaN+emnaLjpZAWmprP8noVME6zuvusJnd0FeHHm
         omHMpPNtqwtDSpe3M25F7NOulUROKocU07JW+oZmVBKD16NZmeT5yoMS07ypqkMlp2jZ
         aUoY9toSlE5hBU74toirBxF0stn4yUw4+DFDWKzb5151qDGlid68lM6UrBRZ0/nVPlXQ
         bSjA==
X-Forwarded-Encrypted: i=1; AJvYcCWUJWBgZi1/HiwVL78mKhLEfla+BJRCTta3tm4gwWfFQldMhTiUVn0bsamarRh9q28IlymRQV+rHxY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwR7wlb2EHN62wYzwaROLypX5GQAPcOR65pJNsWQ828yzB7eoAN
	ehCmvyZvrQxAOUKOGGbxKKLqE2Ba7YuVcPh6dhrdfmRe5hyQq2h+LUvARuI7uvs=
X-Gm-Gg: ASbGncthtkylZHkZRVCYOym4pPPlIiDTWTv5VXBZ4YhH7tclgIosCacNWpuXQ71s0Im
	yGVUfVQb+MtNthfwlIdZoggErDYMZMiL37evM9Uz4kmVZ+ix+vPCWkgKIfMYJEIt5gFUWdttgGY
	pYz2Ci9I57ghVT2auHhujrFyjqryK/ezw3AxvpHFHg6fxNq92r4VoeLw6Ayxp3/vlN4qIAmnZ5t
	SAf/2Wffk/XgJNEWlBPQl72u5B8aGMcAla/1OKIdtT9+vAF4OyhYpbRrDtaNAonUv15Vg9R5m0j
	UxsTHHglvAcDeigG2PUBG96UxaW2YOSzhkzp8ivSJb5ke1lTJumChriBIfaogorDJRn/w3AvjTL
	vEmnrBg==
X-Google-Smtp-Source: AGHT+IHjVQfDLc2idwzhQsSNfI3zWzVcZxuw12wHYj/0SIW8O5CFLWZVsr0apCrmsdZ3iInZI2rPrQ==
X-Received: by 2002:a05:600c:3b0c:b0:43d:160:cd9e with SMTP id 5b1f17b1804b1-442d6d4faf3mr37208365e9.17.1746806408492;
        Fri, 09 May 2025 09:00:08 -0700 (PDT)
Message-ID: <70fcfc7d-1562-41fc-b536-4558fe25d231@citrix.com>
Date: Fri, 9 May 2025 17:00:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/6] xen/riscv: add inclusion of xen/bitops.h to
 asm/cmpxchg.h
To: Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: 
 <876ca1a5dcf7523657ed722f588824f6d8bfb171.1746805907.git.oleksii.kurochko@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: <876ca1a5dcf7523657ed722f588824f6d8bfb171.1746805907.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09/05/2025 4:57 pm, Oleksii Kurochko wrote:
> Add inclusion of xen/bitops.h to asm/cmpxchg.h to avoid compilation issues
> connected to GENMASK() which is used inside asm/cmpxchg.h.
>
> Signed-off-by: Oleksii Kurochko 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Fri May 09 16:14:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 16:14:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980215.1366681 (Exim 4.92)
	(envelope-from )
	id 1uDQMz-0005hf-M0; Fri, 09 May 2025 16:14:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980215.1366681; Fri, 09 May 2025 16:14: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 1uDQMz-0005hY-JK; Fri, 09 May 2025 16:14:41 +0000
Received: by outflank-mailman (input) for mailman id 980215;
 Fri, 09 May 2025 16:14:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQMy-0005hM-NX
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 16:14:40 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b4cf4280-2cf0-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 18:14:38 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-43cf628cb14so23936625e9.1
 for ; Fri, 09 May 2025 09:14:38 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f58ec98dsm3658098f8f.25.2025.05.09.09.14.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 09:14:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b4cf4280-2cf0-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746807278; x=1747412078; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=w9KhlxihKBcpctm46Qfx1HSfYTtqhDb8K/RQu8cFu3I=;
        b=TBfkDZSFKCAnGNtHWpoVbB+joBYxn9eKYXqRTyLtgER0YBoHR9TVuRjSHxNeLNEnaH
         5N53792CMYccPCMqUvAcrK93KDm2zff2UHQ1qD2XOwS3w0M4l87iLAqYwx0DlEmx/v3Z
         8iVVHD9Dlpe6v4tgeOIO+H2EGJYC9drREvEnA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746807278; x=1747412078;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=w9KhlxihKBcpctm46Qfx1HSfYTtqhDb8K/RQu8cFu3I=;
        b=bXS8WjdQpsGwmOAT/H/qB5SsFOk2lG42+Nt16CtvteCyT8nGc2JDKlNGCmDNKJn+5p
         9i4wlb7MXo7eGA8KxxXwBxJQuW8HEIq8MRsYvscAdzRDKCe4gekugMossaeLhK5jemMd
         rKefdJrSO0ugyHfbcbdAwqQCZnk7HPxB3ToIjay/KpAW5slr3YC/ULw4SsitH2vBGGU2
         ngY72D92oolvpN1Icbm4YkuYPbjdHJT9hJ0MPynp1rZZRLIDcMJC00P3v8ir5bHyfL1H
         ElcXyh8Dk1CR1/jiQ2yNL/jdbxuZk+KPklCo2A5Zp45wdFneoT9kG3rslJ5npU73T3U3
         98jA==
X-Forwarded-Encrypted: i=1; AJvYcCVOx1LzNbxZ866/FyK+2SFzJProdyHMS8xgAL6g3bPDcBQpti8QrwEuW+Hi4KiXfmfkqiuR7RAPGWI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyqqYN78Tuvvd8HZ2FR6u+4r9DCN07vZPimM7aRNmKj26YsQlUP
	ztXvI2NplMXjmg+3lCx4EvZRZoPOwNHby/5rudhYyKhPMYKfsnuaETpP/SaG6ZQ=
X-Gm-Gg: ASbGncuHaqEcd9uxrYhlbLGSjLZM++unTptyEPyY4ngRDNwTfE81OvB+DYNW2P/3TpL
	Z+nYlFUafKiVntLxoCCR/kKDcTUiNBeAKzxUcZaIyLWgRf4jqyJubfwprn6oJXDtDc6KdFK67Nz
	T6rQ3AxxivaY6dUOfVZoyL6FDTJCbtZ4X05Y+iXZJGubT3yZ8k0YWHgk9QyGiqNXQjUjMsXLHRE
	QBM+KyQk4+JNGFFWsCEvwmdDMNHCGs8jmwmAkz81wEQJJOzoG5fQdApIpyoGDqonZUXzJNUuv9a
	bOhmLHJSQ9t7vs4GtVSeptDRKSuG3pCs6VDesEcggSC9pUkFJTu8hwKcQqZ1O3lmBB10bxzhy7R
	GuTbmwQ==
X-Google-Smtp-Source: AGHT+IEsNj96Iroq0w9Ijl33CXf57djYDniySN+2kycTcj4Prjhezv9/VsJB03qzvuIsIdjbo1td7g==
X-Received: by 2002:a05:6000:1882:b0:3a1:f563:a057 with SMTP id ffacd0b85a97d-3a1f563a104mr4490246f8f.18.1746807278035;
        Fri, 09 May 2025 09:14:38 -0700 (PDT)
Message-ID: <70186bd9-20b6-48a2-9dd0-25cdc30e81f0@citrix.com>
Date: Fri, 9 May 2025 17:14:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m
 initialization
To: Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: 
 <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@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: <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09/05/2025 4:57 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h
> index 28f57a74f2..8b46210768 100644
> --- a/xen/arch/riscv/include/asm/p2m.h
> +++ b/xen/arch/riscv/include/asm/p2m.h
> @@ -3,11 +3,73 @@
>  #define ASM__RISCV__P2M_H
>  
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

We're phasing out the inclusion of xen/types.h for complex headers like
this, as it's pulled in by almost all dependencies.

> diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
> new file mode 100644
> index 0000000000..ad4beef8f9
> --- /dev/null
> +++ b/xen/arch/riscv/p2m.c
> @@ -0,0 +1,168 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +/*
> + * Force a synchronous P2M TLB flush.
> + *
> + * Must be called with the p2m lock held.
> + *
> + * TODO: add support of flushing TLB connected to VMID.
> + */
> +static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
> +{
> +    ASSERT(p2m_is_write_locked(p2m));
> +
> +    /*
> +     * TODO: shouldn't be this flush done for each physical CPU?
> +     *       If yes, then SBI call sbi_remote_hfence_gvma() could
> +     *       be used for that.
> +     */
> +#if defined(__riscv_hh) || defined(__riscv_h)
> +    asm volatile ( "hfence.gvma" ::: "memory" );
> +#else
> +    asm volatile ( ".insn r 0x73, 0x0, 0x31, x0, x0, x0" ::: "memory" );
> +#endif

TLB flushing needs to happen for each pCPU which potentially has cached
a mapping.

In other arches, this is tracked by d->dirty_cpumask which is the bitmap
of pCPUs where this domain is scheduled.

CPUs need to flush their TLBs before removing themselves from
d->dirty_cpumask, which is typically done during context switch, but it
means that to flush the P2M, you only need to IPI a subset of CPUs.


> +
> +    p2m->need_flush = false;
> +}
> +
> +static void p2m_tlb_flush_sync(struct p2m_domain *p2m)
> +{
> +    if ( p2m->need_flush )
> +        p2m_force_tlb_flush_sync(p2m);
> +}
> +
> +/* Unlock the flush and do a P2M TLB flush if necessary */
> +void p2m_write_unlock(struct p2m_domain *p2m)
> +{
> +    /*
> +     * The final flush is done with the P2M write lock taken to avoid
> +     * someone else modifying the P2M wbefore the TLB invalidation has
> +     * completed.
> +     */
> +    p2m_tlb_flush_sync(p2m);
> +
> +    write_unlock(&p2m->lock);
> +}
> +
> +static void clear_and_clean_page(struct page_info *page)
> +{
> +    void *p = __map_domain_page(page);
> +
> +    clear_page(p);
> +    unmap_domain_page(p);
> +}
> +
> +static struct page_info *p2m_get_clean_page(struct domain *d)
> +{
> +    struct page_info *page;
> +
> +    /*
> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
> +     * As explained in Section 18.5.1, for the paged virtual-memory schemes
> +     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
> +     * and must be aligned to a 16-KiB boundary.
> +     */
> +    page = alloc_domheap_pages(NULL, 2, 0);
> +    if ( page == NULL )
> +        return NULL;
> +
> +    clear_and_clean_page(page);

You appear to have allocated 4 pages, but only zeroed one.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 09 16:18:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 16:18:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980225.1366691 (Exim 4.92)
	(envelope-from )
	id 1uDQR7-0006Gq-5H; Fri, 09 May 2025 16:18:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980225.1366691; Fri, 09 May 2025 16:18: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 1uDQR7-0006Gj-2M; Fri, 09 May 2025 16:18:57 +0000
Received: by outflank-mailman (input) for mailman id 980225;
 Fri, 09 May 2025 16:18:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQR6-0006Gd-66
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 16:18:56 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4dafddab-2cf1-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 18:18:55 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ac3b12e8518so461367766b.0
 for ; Fri, 09 May 2025 09:18:55 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197463edsm171155266b.105.2025.05.09.09.18.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 09:18: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" 
X-Inumbo-ID: 4dafddab-2cf1-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746807534; x=1747412334; 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;
        bh=CQp/dECIkzIFiolzpT72X9wuTH17rT3cBg1gE2cfj5s=;
        b=WOP3JfvUpJDube1XTndd2ZVol1A8ZpFpErYBN6i2lCJthl4Vlfqg7LXg+KWCwyQj2w
         a5m3Q3TRVl9HRIgfTPf6DjpKTbThfgCbMe9lXbhJtg4DOM4IpOC1SfchYydzV5wXZGlH
         jOYmfI9OP9wFnHpK7Y1HKXJolgEk1nvE6riZs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746807534; x=1747412334;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=CQp/dECIkzIFiolzpT72X9wuTH17rT3cBg1gE2cfj5s=;
        b=S4DNPTxzSRbpDHrvTAvRzwyan7h2s8izQTjER/eZtd2gyMfgT4qD0bkRJrkgQS0axW
         cu0SEbPwf1UTM0VX97/y5D64x+2/f7OvH2zV2vRJm+R7gVsc6hNRLIvF0YY1HJs+yIX0
         u+M7w/qgsv7KZYb3ZGbpQRMOA2qhs0s1bViDgkOR3GX5czM0wndUi23Dgv7Xz97q8eft
         YWnG+4AJdIw4GOEcuzxATwoLrAcUDjMRmsD9qps1fm2t73WrwqNyBuHHsE7YCRkQxG+d
         kYBfnYBfBRXoPEantXH99KK9wZiPDQlKHiopDN1K+eaejO4/X3ocnppuZ9VUqQqNhXse
         xUJg==
X-Gm-Message-State: AOJu0YzeAAhIHghL5L+a82EIaxn2iWgLkKFgo9pUJrPGYG+jCxhpMmRF
	msWywJgjrNuP0jmUeqoXpo+itTesPBpPnnpvlVZczmBbHDaqaO+Sc8HcOA8N7l5scAbC10mSPOw
	=
X-Gm-Gg: ASbGncubtcFberrXoQd2EiJQzGpgjhVSkJ8D4ISlq3tdSfFGriMazOOJFkqvWMaQcsi
	jRSDHIX5RcOI6nOH6rXuEZm61yUvTX0g36ri6XYLUUUxQahxJwKyc4aEK0nFM0PcuNMq99nxndD
	G3dB3zz5XUeSy/gd29yV61TDPCJm+MgLbHV3b7NRa3WWv3nBqN6Hu59/41QSyYIOYRTfFWjkvZq
	PzCs6vI6vLW04H030WZGlGv6k33Gl9cpgMszwrjEuGoSuL3DdDhaxVlFgvRmMBf0/V9sLBWzxcp
	gv3FFXRQztFmkkLeh+1bkCkY9xMkfO3QsJcDhWuUru+AfgOfDZMiDMtWvD0D2nDGz18tRUC0Qds
	=
X-Google-Smtp-Source: AGHT+IFeFh0zbvzD87+1cpjr/b8zShG/gnOAdP5Syn5KzgmAtHV2xFsIb3qXc7NRFrsESHnTs2oHEw==
X-Received: by 2002:a17:906:6b91:b0:ad2:1f65:8562 with SMTP id a640c23a62f3a-ad21f658724mr219650466b.14.1746807534186;
        Fri, 09 May 2025 09:18:54 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 1/4] docs: Introduce live patch signing
Date: Fri,  9 May 2025 17:18:46 +0100
Message-ID: <20250509161846.45851-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Remove a never-implemented description of live patch signing from the
TODO section and document signing as implemented by the following
patches.

Signed-off-by: Ross Lagerwall 
---
 docs/misc/livepatch.pandoc | 104 ++++++++++++++++++-------------------
 1 file changed, 52 insertions(+), 52 deletions(-)

diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
index 04dd5ed7b271..66141586b605 100644
--- a/docs/misc/livepatch.pandoc
+++ b/docs/misc/livepatch.pandoc
@@ -917,6 +917,58 @@ The normal sequence of events is to:
  3. *XEN_SYSCTL_LIVEPATCH_ACTION* with *LIVEPATCH_ACTION_APPLY* to apply the patch.
  4. *XEN_SYSCTL_LIVEPATCH_GET* to check the `->rc`. If in *-XEN_EAGAIN* spin. If zero exit with success.
 
+## Signature Checking
+
+While loading live patches would generally be restricted to a privileged
+process in dom0, in certain cases signature checking in Xen may be required.
+For example, when Secure Boot is enabled live patches need to be verified
+before being loaded.
+
+Xen live patches are ELF binaries but there is no standardized mechanism for
+signing ELF binaries. One approach used by Linux is to append a signature to
+the end of the binary, outside of the ELF container. While this works, it tends
+to be fragile since tools that handle ELF binaries do not correctly handle the
+signature. Instead, the approach taken here is to use an ELF note for the
+signature.
+
+The ELF note section name shall be `.note.Xen.signature` with note name `Xen`
+and type `0`.
+
+The note data shall contain a header followed by the signature data:
+
+    #define SIGNATURE_SUPPORTED_VERION 1
+    #define SIGNATURE_ALGORITHM_RSA 0
+    #define SIGNATURE_HASH_SHA256 0
+    struct payload_signature {
+        uint16_t version;
+        uint8_t algo;        /* Public-key crypto algorithm */
+        uint8_t hash;        /* Digest algorithm */
+        uint32_t sig_len;    /* Length of signature data */
+    };
+
+To sign a live patch:
+
+1) Add a new note section with a populated payload signature and zeroed out
+   signature.
+2) Generate a detached signature over the entire binary.
+3) Fill in the signature in the note section.
+
+During live patch load, Xen shall verify the signature using the following
+steps:
+
+1) Copy the signature out of the note section.
+2) Zero the signature.
+3) Generate a detached signature over the entire binary.
+4) Compare against the signature from (1).
+
+Initially, to avoid including DER / X.509 parsing of certificates, handling
+chains, etc. Xen shall verify signatures against a compiled in RSA key in
+exponent/modulus form. However, it may be extended in future to support other
+types of signatures and key types.
+
+Support of signatures in Xen and in live patches is optional. However, certain
+features such as Secure Boot may require live patches to be signed.
+
 
 ## Addendum
 
@@ -1178,58 +1230,6 @@ the function itself.
 Similar considerations are true to a lesser extent for \__FILE__, but it
 could be argued that file renaming should be done outside of hotpatches.
 
-## Signature checking requirements.
-
-The signature checking requires that the layout of the data in memory
-**MUST** be same for signature to be verified. This means that the payload
-data layout in ELF format **MUST** match what the hypervisor would be
-expecting such that it can properly do signature verification.
-
-The signature is based on the all of the payloads continuously laid out
-in memory. The signature is to be appended at the end of the ELF payload
-prefixed with the string '`~Module signature appended~\n`', followed by
-an signature header then followed by the signature, key identifier, and signers
-name.
-
-Specifically the signature header would be:
-
-    #define PKEY_ALGO_DSA       0
-    #define PKEY_ALGO_RSA       1
-
-    #define PKEY_ID_PGP         0 /* OpenPGP generated key ID */
-    #define PKEY_ID_X509        1 /* X.509 arbitrary subjectKeyIdentifier */
-
-    #define HASH_ALGO_MD4          0
-    #define HASH_ALGO_MD5          1
-    #define HASH_ALGO_SHA1         2
-    #define HASH_ALGO_RIPE_MD_160  3
-    #define HASH_ALGO_SHA256       4
-    #define HASH_ALGO_SHA384       5
-    #define HASH_ALGO_SHA512       6
-    #define HASH_ALGO_SHA224       7
-    #define HASH_ALGO_RIPE_MD_128  8
-    #define HASH_ALGO_RIPE_MD_256  9
-    #define HASH_ALGO_RIPE_MD_320 10
-    #define HASH_ALGO_WP_256      11
-    #define HASH_ALGO_WP_384      12
-    #define HASH_ALGO_WP_512      13
-    #define HASH_ALGO_TGR_128     14
-    #define HASH_ALGO_TGR_160     15
-    #define HASH_ALGO_TGR_192     16
-
-    struct elf_payload_signature {
-	    u8	algo;		/* Public-key crypto algorithm PKEY_ALGO_*. */
-	    u8	hash;		/* Digest algorithm: HASH_ALGO_*. */
-	    u8	id_type;	/* Key identifier type PKEY_ID*. */
-	    u8	signer_len;	/* Length of signer's name */
-	    u8	key_id_len;	/* Length of key identifier */
-	    u8	__pad[3];
-	    __be32	sig_len;	/* Length of signature data */
-    };
-
-(Note that this has been borrowed from Linux module signature code.).
-
-
 ### .bss and .data sections.
 
 In place patching writable data is not suitable as it is unclear what should be done
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 09 16:20:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 16:20:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980234.1366700 (Exim 4.92)
	(envelope-from )
	id 1uDQSc-0007iQ-Fk; Fri, 09 May 2025 16:20:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980234.1366700; Fri, 09 May 2025 16:20: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 1uDQSc-0007iJ-D1; Fri, 09 May 2025 16:20:30 +0000
Received: by outflank-mailman (input) for mailman id 980234;
 Fri, 09 May 2025 16:20:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQSb-0007iD-FD
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 16:20:29 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 85792ee8-2cf1-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 18:20:28 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5fbfa0a7d2cso3894639a12.1
 for ; Fri, 09 May 2025 09:20:28 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad21934de87sm171631166b.74.2025.05.09.09.20.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 09:20: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" 
X-Inumbo-ID: 85792ee8-2cf1-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746807628; x=1747412428; 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;
        bh=F/h+K9CEtvQx2D7M8j4k6bSPS6DyqWmWkp0jPmeHtdI=;
        b=fPc/HuYW00vSiUb8DCdI+r8gmxm9MofkzL8rb9B2FKZD/3zsUSXfRks9ayugxcjGGN
         /zzb4lTfmjbsguUc+8WE3DMW9/sN+3x1YPzV2GAY746EjAa37OhX6AgvEMG+qJ8IG9KD
         zKCTZzFMkcPPH445tJGfmWYqr5ccrYhsNQWwc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746807628; x=1747412428;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=F/h+K9CEtvQx2D7M8j4k6bSPS6DyqWmWkp0jPmeHtdI=;
        b=qP0WHo6etUdK3vCAyQ8qgr+Z8isCaHEyUhQ+LzlOYDaer7eqAGbr0L7f/y2Ygao+C9
         8ua0LolZE25SGcoRTqVZrqIFgI6hTYmxVXzGIs0PxpAlwzSougtnO1qmbisXTD+xpvaG
         eCs8gJkmECuYSYoVwT7v6VCrNV2Vs5IdVJW+h058Nkgco/TBM3uf+EZQ0GCkIEL6j9jj
         HFQXM9JpPMpdcjRZI3t4Gd1l/7EQ7AYROkle6Tb+bu4hRlxycZ+baVa2VyiS54ULdPbc
         2UmOx7VjeotOjHL5B3yjoTQuVZIU44KcHocu3Jhn5vDchMLQdxH8Wa6QFA1yCzhf2PCX
         HINQ==
X-Gm-Message-State: AOJu0YzWx3HmXG3kZEGARLoykYXdEBOy/pXaBJSbarKUw4KnN7JGk1/e
	jCOuzC1j/+T1BHf7Zd8IJqZSqwdi0YNOkBmdZJVKbqOpKcD8TrZ72eVCQLEs/OILvXUspuHqivU
	=
X-Gm-Gg: ASbGncvDsq8S55BY/5LzhXE80cNcivNyl7otaqbQr0H/ywnr1Pvj9JWUOHX8rBiTP5p
	LGRDRPlLgJLGsg76wSoiZttmlwnZvC9shRGPswVwVqmElas9syNvrwR1lxe4X3RPcGjT8zQZmuA
	OfXgeULnOQSbTPWAyhn0Xj6U9YbYTd6Frh2z+Lf0JJPJcg8yqqkxjUs4+cAagi8V0DNDwNqsG26
	FZtJ3yi9yueLE5qhN+Q7hx6b0hlMNO2s9Vr3/7Whz/zZtkhvm70P3AtZOZ2TDqUBs5noUShxYbn
	HCWej0rwLzE3wzEglrNMMnzCDFU8UUnku823hnO/UJO0K1Swz01q38c9uSkVmxWoVmGWFHzsFXk
	=
X-Google-Smtp-Source: AGHT+IFdxgMF1hWlw7F8AdxydqCoeJDiOqkj3myWL0NwNW0Guhy93AI+I59zq4XemUrcQMG84YIQVA==
X-Received: by 2002:a17:906:6a88:b0:ad2:1d12:fd68 with SMTP id a640c23a62f3a-ad21d1301c2mr259337066b.48.1746807627750;
        Fri, 09 May 2025 09:20:27 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Jennifer Herbert ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Ross Lagerwall 
Subject: [PATCH 4/4] livepatch: Verify livepatch signatures
Date: Fri,  9 May 2025 17:20:16 +0100
Message-ID: <20250509162016.45931-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Jennifer Herbert 

Verify livepatch signatures against the embedded public key in Xen.
Failing to verify does not prevent the livepatch from being loaded.
In future, this will be changed for certain cases (e.g. when Secure Boot
is enabled).

Signed-off-by: Jennifer Herbert 
Signed-off-by: Ross Lagerwall 
---
 xen/common/livepatch.c          | 134 ++++++++++++++++++++++++++++++++
 xen/common/livepatch_elf.c      |  55 +++++++++++++
 xen/include/xen/livepatch.h     |   5 ++
 xen/include/xen/livepatch_elf.h |  18 +++++
 4 files changed, 212 insertions(+)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 947d05671b4f..dd3532b7bbee 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -81,6 +81,9 @@ extern const uint8_t xen_livepatch_key_data[];
 static struct rsa_public_key builtin_payload_key;
 #endif
 
+static int check_signature(const struct livepatch_elf *elf, void *raw,
+                           size_t size);
+
 static int get_name(const struct xen_livepatch_name *name, char *n)
 {
     if ( !name->size || name->size > XEN_LIVEPATCH_NAME_SIZE )
@@ -1164,6 +1167,8 @@ static int load_payload_data(struct payload *payload, void *raw, size_t len)
     if ( rc )
        goto out;
 
+    check_signature(&elf, raw, len);
+
     rc = move_payload(payload, &elf);
     if ( rc )
         goto out;
@@ -1204,6 +1209,135 @@ static int load_payload_data(struct payload *payload, void *raw, size_t len)
     return rc;
 }
 
+#ifdef CONFIG_PAYLOAD_SIGNING
+
+#define MAX_SIG_NOTE_SIZE 1024
+
+struct payload_signature {
+    uint16_t version;
+    uint8_t algo;        /* Public-key crypto algorithm */
+    uint8_t hash;        /* Digest algorithm */
+    uint32_t sig_len;    /* Length of signature data */
+};
+
+static int check_rsa_sha256_signature(void *data, size_t datalen,
+                                      void *sig, uint32_t siglen)
+{
+    struct sha2_256_state hash;
+    MPI s;
+    int rc;
+
+    s = mpi_read_raw_data(sig, siglen);
+    if ( !s )
+    {
+        printk(XENLOG_ERR LIVEPATCH "Failed to mpi_read_raw_data\n");
+        return -ENOMEM;
+    }
+
+    sha2_256_init(&hash);
+    sha2_256_update(&hash, data, datalen);
+
+    rc = rsa_sha256_verify(&builtin_payload_key, &hash, s);
+    if ( rc )
+        printk(XENLOG_ERR LIVEPATCH "rsa_sha256_verify failed: %d\n", rc);
+
+    mpi_free(s);
+
+    return rc;
+}
+
+static int check_signature(const struct livepatch_elf *elf, void *raw,
+                           size_t size)
+{
+    static const char notename[] = "Xen";
+    struct payload_signature *siginfo;
+    livepatch_elf_note note;
+    size_t nsize;
+    int rc;
+
+    rc = livepatch_elf_note_by_names(elf, ELF_XEN_SIGNATURE, notename, 0,
+                                     ¬e);
+    if ( rc )
+    {
+        dprintk(XENLOG_DEBUG, LIVEPATCH "%s: Signature not present\n",
+                elf->name);
+        return rc;
+    }
+
+    /* We expect only one signature, find a second is an error! */
+    rc = livepatch_elf_next_note_by_name(notename, 0, ¬e);
+    if ( rc != -ENOENT )
+    {
+        if ( rc )
+        {
+            printk(XENLOG_ERR LIVEPATCH
+                   "Error while checking for notes! err = %d\n", rc);
+            return rc;
+        }
+        else
+        {
+            printk(XENLOG_ERR LIVEPATCH
+                   "Error, found second signature note! There can be only one!\n");
+            return -EINVAL;
+        }
+    }
+
+    nsize = note.size;
+    if ( nsize <= sizeof(*siginfo) || nsize >= MAX_SIG_NOTE_SIZE )
+    {
+        printk(XENLOG_ERR LIVEPATCH "Invalid signature note size: %zu\n",
+               nsize);
+        return -EINVAL;
+    }
+
+    siginfo = xmalloc_bytes(nsize);
+    if ( !siginfo )
+        return -ENOMEM;
+
+    memcpy(siginfo, note.data, nsize);
+
+    if ( siginfo->version != SIGNATURE_SUPPORTED_VERION )
+    {
+       printk(XENLOG_ERR LIVEPATCH "Bad signature version %u\n", siginfo->version);
+       rc = -EINVAL;
+       goto out;
+    }
+
+    if ( siginfo->sig_len == 0 ||
+         nsize - sizeof(*siginfo) < siginfo->sig_len )
+    {
+       printk(XENLOG_ERR LIVEPATCH
+              "Payload signature size bad. ns=%zu si=%u\n",
+              nsize, siginfo->sig_len);
+       rc = -EINVAL;
+       goto out;
+    }
+
+    if ( siginfo->algo != SIGNATURE_ALGORITHM_RSA ||
+         siginfo->hash != SIGNATURE_HASH_SHA256 )
+    {
+        printk(XENLOG_ERR LIVEPATCH "Bad payload signature: v:%u, a:%u, h:%u\n",
+               siginfo->version, siginfo->algo, siginfo->hash);
+        rc = -EINVAL;
+        goto out;
+    }
+
+    /* Remove signature from data, as can't be verified with it. */
+    memset((void *)note.data + sizeof(*siginfo), 0, siginfo->sig_len);
+    rc = check_rsa_sha256_signature(raw, size, siginfo + 1, siginfo->sig_len);
+
+out:
+    xfree(siginfo);
+    return rc;
+}
+#else
+static int check_signature(const struct livepatch_elf *elf, void *raw,
+                           size_t size)
+{
+    return -EINVAL;
+}
+#endif
+
 static int livepatch_upload(struct xen_sysctl_livepatch_upload *upload)
 {
     struct payload *data, *found;
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index 25ce1bd5a0ad..b27c4524611d 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -23,6 +23,61 @@ livepatch_elf_sec_by_name(const struct livepatch_elf *elf,
     return NULL;
 }
 
+int livepatch_elf_note_by_names(const struct livepatch_elf *elf,
+                                const char *sec_name, const char *note_name,
+                                const unsigned int type,
+                                livepatch_elf_note *note)
+{
+     const struct livepatch_elf_sec *sec = livepatch_elf_sec_by_name(elf,
+                                                                     sec_name);
+     if ( !sec )
+           return -ENOENT;
+
+     note->end = sec->addr + sec->sec->sh_size;
+     note->next = sec->addr;
+
+     return livepatch_elf_next_note_by_name(note_name, type, note);
+}
+
+int livepatch_elf_next_note_by_name(const char *note_name,
+                                    const unsigned int type,
+                                    livepatch_elf_note *note)
+{
+     const Elf_Note *pkd_note = note->next;
+     size_t notenamelen = strlen(note_name) + 1;
+     size_t note_hd_size;
+     size_t note_size;
+     size_t remaining;
+
+     while ( (void *)pkd_note < note->end )
+     {
+
+         remaining = note->end - (void *)pkd_note;
+         if ( remaining < sizeof(livepatch_elf_note) )
+             return -EINVAL;
+
+         note_hd_size = sizeof(Elf_Note) + ((pkd_note->namesz + 3) & ~0x3);
+         note_size = note_hd_size + ((pkd_note->descsz + 3) & ~0x3);
+         if ( remaining < note_size )
+             return -EINVAL;
+
+         if ( notenamelen == pkd_note->namesz &&
+              !memcmp(note_name, (const void *) pkd_note + sizeof(Elf_Note),
+                      notenamelen) &&
+              (type == -1 || pkd_note->type == type) )
+         {
+             note->size = pkd_note->descsz;
+             note->type = pkd_note->type;
+             note->data = (void *)pkd_note + note_hd_size;
+             note->next = (void *)pkd_note + note_size;
+             return 0;
+         }
+         pkd_note = (void *)pkd_note + note_size;
+     }
+
+     return -ENOENT;
+}
+
 static int elf_verify_strtab(const struct livepatch_elf_sec *sec)
 {
     const Elf_Shdr *s;
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index d074a5bebecc..23bef334d24f 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -38,6 +38,7 @@ struct xen_sysctl_livepatch_op;
 #define ELF_LIVEPATCH_DEPENDS     ".livepatch.depends"
 #define ELF_LIVEPATCH_XEN_DEPENDS ".livepatch.xen_depends"
 #define ELF_BUILD_ID_NOTE         ".note.gnu.build-id"
+#define ELF_XEN_SIGNATURE         ".note.Xen.signature"
 #define ELF_LIVEPATCH_LOAD_HOOKS      ".livepatch.hooks.load"
 #define ELF_LIVEPATCH_UNLOAD_HOOKS    ".livepatch.hooks.unload"
 #define ELF_LIVEPATCH_PREAPPLY_HOOK   ".livepatch.hooks.preapply"
@@ -49,6 +50,10 @@ struct xen_sysctl_livepatch_op;
 /* Arbitrary limit for payload size and .bss section size. */
 #define LIVEPATCH_MAX_SIZE     MB(2)
 
+#define SIGNATURE_SUPPORTED_VERION 1
+#define SIGNATURE_ALGORITHM_RSA 0
+#define SIGNATURE_HASH_SHA256 0
+
 struct livepatch_symbol {
     const char *name;
     unsigned long value;
diff --git a/xen/include/xen/livepatch_elf.h b/xen/include/xen/livepatch_elf.h
index 842111e14518..04611bac410e 100644
--- a/xen/include/xen/livepatch_elf.h
+++ b/xen/include/xen/livepatch_elf.h
@@ -39,6 +39,16 @@ struct livepatch_elf {
     unsigned int symtab_idx;
 };
 
+typedef struct {
+    uint32_t size;                       /* Note size */
+    uint32_t type;                       /* Note type */
+    const void *data;                    /* Pointer to note */
+
+    /* Private */
+    const Elf_Note *next;
+    const void *end;
+} livepatch_elf_note;
+
 const struct livepatch_elf_sec *
 livepatch_elf_sec_by_name(const struct livepatch_elf *elf,
                           const char *name);
@@ -48,6 +58,14 @@ void livepatch_elf_free(struct livepatch_elf *elf);
 int livepatch_elf_resolve_symbols(struct livepatch_elf *elf);
 int livepatch_elf_perform_relocs(struct livepatch_elf *elf);
 
+int livepatch_elf_note_by_names(const struct livepatch_elf *elf,
+                                const char *sec_name, const char *note_name,
+                                const unsigned int type,
+                                livepatch_elf_note *note);
+int livepatch_elf_next_note_by_name(const char *note_name,
+                                    const unsigned int type,
+                                    livepatch_elf_note *note);
+
 static inline bool livepatch_elf_ignore_section(const Elf_Shdr *sec)
 {
     return !(sec->sh_flags & SHF_ALLOC);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 09 16:32:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 16:32:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980249.1366711 (Exim 4.92)
	(envelope-from )
	id 1uDQe7-0001fq-KQ; Fri, 09 May 2025 16:32:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980249.1366711; Fri, 09 May 2025 16:32: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 1uDQe7-0001fj-Gh; Fri, 09 May 2025 16:32:23 +0000
Received: by outflank-mailman (input) for mailman id 980249;
 Fri, 09 May 2025 16:32:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQe5-0001fR-Hz
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 16:32:21 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2cf6fefa-2cf3-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 18:32:19 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-442ccf0e1b3so24440045e9.3
 for ; Fri, 09 May 2025 09:32:19 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f58ecb46sm3790069f8f.30.2025.05.09.09.32.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 09:32: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" 
X-Inumbo-ID: 2cf6fefa-2cf3-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746808338; x=1747413138; 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;
        bh=ROHO2f0QCmXC07+ZMsEuiruPA5mpfSKk5CWbkg5bBDE=;
        b=NCzM5G7IHWw5Ja8FpRHtZZ5Wfvi6qaQ5jIModyWMpKQb71cVYBT+IIEAGDFP8p5pwy
         vfgwc1noBpzi1WosbGupjg6DjvZEO/Lot/6JNhIxflPKvJQrj6bhaCGkj70VAEX9js0T
         4YZnpuHamCL8MFEF2GHLrWJ2mzJBV+4JmnSdA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746808338; x=1747413138;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ROHO2f0QCmXC07+ZMsEuiruPA5mpfSKk5CWbkg5bBDE=;
        b=vdQtD/GpiGwACw4cuWveEeiuxTHvqomg/ji1p+ZgkHGk+zYlt8Y5LvwaGt2reKMLCi
         YnEq+GWuW+zdzhwnQG4La7OC6lOvhaiBGHUC/fSOuT646X41F0XwVcA5yMO6++MdnQBa
         v5OC2trVJ6lhzle3NHK8PkyR1IOhSEq44+2E1OIdafPGg0L7bq0bLBWCEBnpWgOaevQT
         FTp1Iw9HF5OjMWZzmXDj5LcgyXXx8i4SNxek/wTcCq4pfP92yDuJS21htsqxBnt1n2w4
         +eDP+hFVtqkC0RwDlR7wllYDuLXQuRFzMR5Cb5L3G6WRoP+oUelQ9CMkOLTH+IAJygMG
         KKcw==
X-Gm-Message-State: AOJu0YyTB4428xRpgVHaPRlMwtzDzFg4TJ4RKS44ZLBxU/s78Ho5mWH4
	zIQUJhnyJIT5UvCEyhpkelt2++B6sC8b0V6sanZjMPjT1DCFfJ4fgdXisEIeOSGFlMLGK6NUWRn
	r
X-Gm-Gg: ASbGnctMmZdfGr0fJLMWUN9zNR0TptWIOwDWxYixwEJ3fXPH1ZXvJXWaS2wMjfca+7d
	VTjxL8bTPeuDOi7uHR//c1aPkG3UGEJU4S4PUYhyMYyobARM1Xa72f9r/qn1quoVrd8hulv1F1J
	UzPouhmlHqcMBgvUY2EnAMOfNXlYqtDwJQmExtwi4KehCAoBOXAUZE3/pgy5wdiA8kGVNQ3vRh0
	VtYKqaO9SiLX0xCyUL5L2QoIuSLcYUHnf4fg/T4wLCw0yS1F5xF0tJ2gQtN3NuRXnKcXzNrxmVW
	yTw8iPV3xKeEQEuSutl/gzF8S05UB5kfz4tUheGmgA1KpDq/h5i70IH62Jab9w+Kg9EQG9Vhh/H
	ATzq251wQ/XComA==
X-Google-Smtp-Source: AGHT+IGLX+lnRXCiVy5f1WlMgI/nXk7GoIPxwhZx0XmuyhZr4oXjX5NR99nmp6IjIpflQcwAxsVJfg==
X-Received: by 2002:a05:600c:3b0e:b0:43c:f6b0:e807 with SMTP id 5b1f17b1804b1-442d6ddea12mr36479785e9.31.1746808338433;
        Fri, 09 May 2025 09:32:18 -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 ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	Ross Lagerwall 
Subject: [PATCH v2 0/3] xen: Header fixes
Date: Fri,  9 May 2025 17:32:09 +0100
Message-Id: <20250509163212.2948359-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

Split out of "[PATCH 0/8] xen: Untangle mm.h"

https://lore.kernel.org/xen-devel/20250312174513.4075066-1-andrew.cooper3@citrix.com/

Andrew Cooper (3):
  xen/elfstructs: Include xen/types.h
  xen/livepatch: Fix include hierarchy
  xen: Sort includes

 xen/arch/arm/arm32/livepatch.c  |  1 -
 xen/arch/arm/arm64/livepatch.c  |  1 -
 xen/arch/arm/livepatch.c        |  1 -
 xen/arch/arm/mmu/setup.c        |  2 +-
 xen/arch/x86/alternative.c      | 12 ++++++------
 xen/arch/x86/livepatch.c        |  9 ++++-----
 xen/common/memory.c             |  4 +++-
 xen/common/page_alloc.c         |  5 ++---
 xen/include/xen/elfstructs.h    |  8 +++++++-
 xen/include/xen/livepatch.h     | 10 +++++-----
 xen/include/xen/livepatch_elf.h |  1 -
 xen/include/xen/mm.h            |  6 +++---
 xen/include/xen/version.h       |  1 -
 13 files changed, 31 insertions(+), 30 deletions(-)

-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri May 09 16:32:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 16:32:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980251.1366723 (Exim 4.92)
	(envelope-from )
	id 1uDQe8-0001lJ-5f; Fri, 09 May 2025 16:32:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980251.1366723; Fri, 09 May 2025 16:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDQe7-0001jg-Ur; Fri, 09 May 2025 16:32:23 +0000
Received: by outflank-mailman (input) for mailman id 980251;
 Fri, 09 May 2025 16:32:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQe6-0001fR-7L
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 16:32:22 +0000
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com
 [2a00:1450:4864:20::42a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2d730218-2cf3-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 18:32:20 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a0b7fbdde7so2047296f8f.2
 for ; Fri, 09 May 2025 09:32:20 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f58ecb46sm3790069f8f.30.2025.05.09.09.32.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 09:32: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" 
X-Inumbo-ID: 2d730218-2cf3-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746808339; x=1747413139; 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;
        bh=Uj6rfH1i3XcyxsQoQ74OA6E4STBRj/hMndAunES5dfs=;
        b=DnXFDBJ69KKbZ0j21DMhaNt20PrO0WjrB8dwwTjt6WAYckw7I7srlFiSuRDMuFzaek
         g0f6SLMXoHL7foAcKQWrD/ygopxlePssLY7QlrIxWJhIjctpuCNEllwUs/5CQRaBg2oC
         0LbHuO9HVWGPDO+9sQQj1vTql45vo1T/7zIQA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746808339; x=1747413139;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Uj6rfH1i3XcyxsQoQ74OA6E4STBRj/hMndAunES5dfs=;
        b=K7izd/B83m43vwC9+lhmgH19GTLvcXBaCUqT9Nmqwxa0Rlie2OYvAHVEJb5FszSlmC
         CjLBHFZWQId6JeI2aYk2/BYNKP4umar+wFXUgb2Mk/ch4sZAlHBrl+DX0iBVGM5CGaqu
         vZpC9vCRw6YRz5I915o81ObMoiOOZ7ldcbOTLvZJRuGrLj1lS4Hd8MwdvO3plkqb/LaW
         r54BFHPadDBFH85JdYeO4GXjEPxChqveLqA+apu2YCPP+xovDWuzzl2X94ZB1WbN0Q2K
         BYXVUQ9jfDiMjcoYO2OFD0G+d7bd3kK0EGd8tg4Z9QpbLhyi2KxHp7ef2qkOM00FY3lQ
         euNg==
X-Gm-Message-State: AOJu0Yy7HWWdIBTeoNm5ONksLbmFyyxHcFgfd28DNMhvwliVyyqTty6Z
	QzjOrKvz95iMpz98IXn4haMTlpwT5uS+z+lohcjXZhX6kKBM755510yHKauIvdvhQZC0Wf6nRY0
	B
X-Gm-Gg: ASbGnctpZaLLX2kdk9Md57XOvvFV6VaJpNEqdZCMz+ym5qpHKPzMFjE+Z+cMWFJyaPh
	Hacy9gnwYIGuVj0F9h95fxMruoyMFgm2/32JD3Oon+gScxFa2mEA019PhnU/sOKEx9r7Pmj6j6Z
	6BS0LJsxGNbaX/CN2UDSBWVxY5iVqGr1/8pVE4TI7coS9ZVveZ+sxDaJyx6dGZ7S+LrD+sDqGmL
	3fyIzeTu109ideNqrfIXON+C/DK8LTZdhKOxjBjcRJ5pRU521ZV2ZbSIgBPXLeNwr9EYEilPGl1
	/XP4NID3AurTKRKrVNhaZAiFsk4VqcKNtfz05UVjLP6Sua6Ywi4/kEtyaYGzrn4/+uyX+ZP96KQ
	+qyuRNWuNEC1PYg==
X-Google-Smtp-Source: AGHT+IH3Z38Rocwpp+dGJAJ8JcleA2f+AdZVLNkSuF3mEpA1/A4xYZVt3i6ya5jaCgnAUPzV9Mf9Qw==
X-Received: by 2002:a5d:588b:0:b0:39c:dfa:d33e with SMTP id ffacd0b85a97d-3a1f643ba3emr3805411f8f.23.1746808339322;
        Fri, 09 May 2025 09:32:19 -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 ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	Ross Lagerwall 
Subject: [PATCH v2 1/3] xen/elfstructs: Include xen/types.h
Date: Fri,  9 May 2025 17:32:10 +0100
Message-Id: <20250509163212.2948359-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250509163212.2948359-1-andrew.cooper3@citrix.com>
References: <20250509163212.2948359-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

elfstructs.h needs the stdint.h types.  Two headers arrange this manually, but
elf.h and livepatch.h do not, which breaks source files whose headers are
properly sorted.

elfstructs.h is used by tools too, so use stdint directly outside of Xen.

Clean up trailing whitespace.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: Ross Lagerwall 

v2:
 * Include stdint outside of Xen.
---
 xen/include/xen/elfstructs.h    | 8 +++++++-
 xen/include/xen/livepatch_elf.h | 1 -
 xen/include/xen/version.h       | 1 -
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/include/xen/elfstructs.h b/xen/include/xen/elfstructs.h
index eb6b87a823a8..0ca86cd6ac4d 100644
--- a/xen/include/xen/elfstructs.h
+++ b/xen/include/xen/elfstructs.h
@@ -26,6 +26,12 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#ifdef __XEN__
+#include 
+#else
+#include 
+#endif
+
 typedef uint32_t	Elf32_Addr;	/* Unsigned program address */
 typedef uint32_t	Elf32_Off;	/* Unsigned file offset */
 typedef uint16_t	Elf32_Half;	/* Unsigned medium integer */
@@ -45,7 +51,7 @@ typedef uint64_t	Elf64_Xword;
 
 /*
  * e_ident[] identification indexes
- * See http://www.caldera.com/developers/gabi/2000-07-17/ch4.eheader.html 
+ * See http://www.caldera.com/developers/gabi/2000-07-17/ch4.eheader.html
  */
 #define EI_MAG0		0		/* file ID */
 #define EI_MAG1		1		/* file ID */
diff --git a/xen/include/xen/livepatch_elf.h b/xen/include/xen/livepatch_elf.h
index 842111e14518..a8aafecd34b1 100644
--- a/xen/include/xen/livepatch_elf.h
+++ b/xen/include/xen/livepatch_elf.h
@@ -5,7 +5,6 @@
 #ifndef __XEN_LIVEPATCH_ELF_H__
 #define __XEN_LIVEPATCH_ELF_H__
 
-#include 
 #include 
 
 /* The following describes an Elf file as consumed by Xen Live Patch. */
diff --git a/xen/include/xen/version.h b/xen/include/xen/version.h
index 4856ad1b446d..bc69ec9fb029 100644
--- a/xen/include/xen/version.h
+++ b/xen/include/xen/version.h
@@ -1,7 +1,6 @@
 #ifndef __XEN_VERSION_H__
 #define __XEN_VERSION_H__
 
-#include 
 #include 
 
 const char *xen_compile_date(void);
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri May 09 16:32:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 16:32:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980250.1366717 (Exim 4.92)
	(envelope-from )
	id 1uDQe7-0001j5-UJ; Fri, 09 May 2025 16:32:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980250.1366717; Fri, 09 May 2025 16:32: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 1uDQe7-0001hZ-Mf; Fri, 09 May 2025 16:32:23 +0000
Received: by outflank-mailman (input) for mailman id 980250;
 Fri, 09 May 2025 16:32:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQe5-0001fS-Uh
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 16:32:21 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2e05b200-2cf3-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 18:32:21 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a1fb18420aso544125f8f.1
 for ; Fri, 09 May 2025 09:32:21 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f58ecb46sm3790069f8f.30.2025.05.09.09.32.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 09:32: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" 
X-Inumbo-ID: 2e05b200-2cf3-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746808340; x=1747413140; 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;
        bh=tFM0Y+gqadqzp0ENY31mMAUk5m2pUiR3mi691rrtM+k=;
        b=lZ/dpJzBgkMVeDeQdUtBozlLtP64syKgtay9nq6eDcH9HgbwamN8BHsNmaBuv+WgE8
         xKkLEBrbLHlp5kWlHfAgIfdxsz9DYCRkMcQsclKPcdblIoq836rZAUpQagR3Z++HDn9+
         0hQ+4qS0dY9N+QPOQSUQEfo9Bvs3cKFxHvL8U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746808340; x=1747413140;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=tFM0Y+gqadqzp0ENY31mMAUk5m2pUiR3mi691rrtM+k=;
        b=mTCqOOclrK9e26Br/dabDS0otbzZSF4EzKQ1mG9fLWV04Q11ErhhYHK9G0cwInu23n
         IHrUwbDMq/XrFVZI1/DMi2vA84ujFD8AfDvYfT/zuA3zpk3Ii08fGBPp3FrXwYC3fFeT
         j6LupXY9WqXrQtfMWwrU2MeNOeOul7WHpjisK4P+FGDMYcE2TAfUuwrTFY+DdrRsg6xt
         owBtgnr+D3zGuCw9XcPXRryKrzE4jU/AAyq4WGSAvGohjKp07oKabBcilEYIJdpq8kxL
         y0TcTeBBRg+w7U4qTC/AS5nZT7+xIlfWeqFy8t4I+dUU6r3ubWRcvNUviT3vIoLZ8MA5
         Ji2Q==
X-Gm-Message-State: AOJu0Yx33lMskSwj6mtFvmhdk0vixgzvqLKu47vKRhfaBzTnU9Z6Bs5U
	6samGcDyS2p2v+uhXBXgeLg6tEv4sQEZq31I7mor4to+/3/33T3St/G7N1VbKc+XbUAnUnRDPVf
	L
X-Gm-Gg: ASbGnctsru9qGh5a/1DClfRut3XaQ8E4y+XCPPA49mpsFDKZJ4mRgcvp/bMsMxFkVXp
	59GIFMvg2y4wTb5rvMVmAXfawL3PHf9kybki8M4uRZhU0vEkuJl3xinuP0bwmDfo0GKFGPXveP3
	82GCivcNGWhJPYLNJIzedd2oZbdMRJdw4quM1kYtL6II+T9oJhmqtxEbVpPFrOoVfk1V5dKWqQB
	PWtAWkovfsyy0wnpfTaE3f7gunqttYlS4fYEfSqRTqXHP5MzWFbi2C5KBsN/omrq8p6aPAuQe2+
	SFYpvqK2WwE7UzB40b1UInfyE3ps+vI84m+fu06ShszkQ/xTneOsEe12l66xiBGDi/ORXaa9EGm
	5ihR4vjr8iytiWr2Uc3Zfq9mW
X-Google-Smtp-Source: AGHT+IEqpvqY6582XcpA4QoHaFF9RITN5vO2tcxP+51EaANNWJAgY2M9NmV5yf3g9aG70LBWTdSPOA==
X-Received: by 2002:a05:6000:e07:b0:3a1:f561:6894 with SMTP id ffacd0b85a97d-3a1f649aa9amr2723924f8f.44.1746808340249;
        Fri, 09 May 2025 09:32:20 -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 ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	Ross Lagerwall 
Subject: [PATCH v2 2/3] xen/livepatch: Fix include hierarchy
Date: Fri,  9 May 2025 17:32:11 +0100
Message-Id: <20250509163212.2948359-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250509163212.2948359-1-andrew.cooper3@citrix.com>
References: <20250509163212.2948359-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

xen/livepatch.h includes public/sysctl.h twice, which can be deduplicated, and
includes asm/livepatch.h meaning that each livepatch.c does not need to
include both.

Comment the #else and #endif cases to aid legibility.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: Ross Lagerwall 
---
 xen/arch/arm/arm32/livepatch.c |  1 -
 xen/arch/arm/arm64/livepatch.c |  1 -
 xen/arch/arm/livepatch.c       |  1 -
 xen/arch/x86/livepatch.c       |  1 -
 xen/include/xen/livepatch.h    | 10 +++++-----
 5 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 134d07a175bb..8541c71d6e2e 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -9,7 +9,6 @@
 #include 
 
 #include 
-#include 
 
 void arch_livepatch_apply(const struct livepatch_func *func,
                           struct livepatch_fstate *state)
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index e135bd5bf99a..39159ba8b5bf 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -13,7 +13,6 @@
 
 #include 
 #include 
-#include 
 
 void arch_livepatch_apply(const struct livepatch_func *func,
                           struct livepatch_fstate *state)
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 3805b2974663..2fbb7bce60bb 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -11,7 +11,6 @@
 #include 
 
 #include 
-#include 
 
 /* Override macros from asm/page.h to make them work with mfn_t */
 #undef virt_to_mfn
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index be40f625d206..bdca355dc6cc 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 static bool has_active_waitqueue(const struct vm_event_domain *ved)
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index d074a5bebecc..c1e76ef55404 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -14,12 +14,14 @@ struct xen_sysctl_livepatch_op;
 #include 
 #include  /* For -ENOSYS or -EOVERFLOW */
 
-#include  /* For LIVEPATCH_OPAQUE_SIZE */
+#include 
 
 #ifdef CONFIG_LIVEPATCH
 
 #include 
 
+#include 
+
 /*
  * We use alternative and exception table code - which by default are __init
  * only, however we need them during runtime. These macros allows us to build
@@ -93,8 +95,6 @@ int arch_livepatch_secure(const void *va, unsigned int pages, enum va_type types
 
 void arch_livepatch_init(void);
 
-#include  /* For struct livepatch_func. */
-#include 
 int arch_livepatch_verify_func(const struct livepatch_func *func);
 
 static inline
@@ -143,7 +143,7 @@ struct payload;
 int revert_payload(struct payload *data);
 void revert_payload_tail(struct payload *data);
 
-#else
+#else /* !CONFIG_LIVEPATCH */
 
 /*
  * If not compiling with Live Patch certain functionality should stay as
@@ -165,7 +165,7 @@ static inline bool is_patch(const void *addr)
 {
     return 0;
 }
-#endif /* CONFIG_LIVEPATCH */
+#endif /* !CONFIG_LIVEPATCH */
 
 #endif /* __XEN_LIVEPATCH_H__ */
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri May 09 16:32:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 16:32:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980252.1366742 (Exim 4.92)
	(envelope-from )
	id 1uDQe9-0002KY-DT; Fri, 09 May 2025 16:32:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980252.1366742; Fri, 09 May 2025 16: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 1uDQe9-0002KI-7V; Fri, 09 May 2025 16:32:25 +0000
Received: by outflank-mailman (input) for mailman id 980252;
 Fri, 09 May 2025 16:32:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDQe7-0001fR-Lm
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 16:32:23 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2eaaec2d-2cf3-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 18:32:22 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a1fa0d8884so505530f8f.3
 for ; Fri, 09 May 2025 09:32:22 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f58ecb46sm3790069f8f.30.2025.05.09.09.32.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 09:32: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" 
X-Inumbo-ID: 2eaaec2d-2cf3-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746808341; x=1747413141; 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;
        bh=IAXP9jNKNZBQcjh+QziOUIyrdCODDG8+CjfV4+CNhS0=;
        b=VRx04bEY45W020o8rSwE37xoi/LmCKlhvaCG2VV5UtWPcCoPyeeqAGcWKM5xI+Gjqb
         pxzNk7SGcqnltq9Nkv7sXsWEOMW5E23CfQvrgvSC7xJy73569cwaZeePfImYSMi4PZzv
         RY6ul0IEREOVsLQWh7ZWhhPVDaNrvFsEjNBIU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746808341; x=1747413141;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=IAXP9jNKNZBQcjh+QziOUIyrdCODDG8+CjfV4+CNhS0=;
        b=UNydKjzBhtoFGe5u5dtlV2F2E82hBHFTrIvUxy2U3ZPZj78XR1GV0nSOchEIKjT61v
         eHw3u9zRXJct6d79vXYj64gf2DOipyIswk8JEY05nLshn7u0v6Mnuz6PENCaLJId70Jt
         7vDvrnC1aRBT+VhTMO8kjws0tRwTqWaYzkCMdlQTleOsyeXORyRXZe5bQhn2l6Rz4ccy
         8h5+zw3TJBe9HvszJxdYRtYf7kdM9OUYAhTqT6kG5GWZS6M3Impot7uUpSRxsKROW1uG
         5CZNx5ve3CxIfmlFYz0QpTMNSQvyG2s3rz+FH731SKm5eYTHZ0u1W6g0ysKJPPefQ1Ng
         EhZg==
X-Gm-Message-State: AOJu0Yz0HkJ39V19F2AReQByXoqZGWi5ep8dIiEnqmNYlorvrQ5d1GnE
	H09bVDRB7to737UP8AeXC304f2wpkkliL0AWpYaLSFXFy0XPjCkdzMwLLK8FqJRemK/TcaSN8Ei
	U
X-Gm-Gg: ASbGncu+C7M8FkpWbmZdg66k2Bc3cvzVpyk3/K09JWVQRq67TntXp+b/g1s20+hp644
	/It94XnlTNcnKKJ/r+MXfCme4OmhR6kkJ6q2T25rjbTI6Iect6FJs19GdlypE5kVTzVZp9Ocv8U
	sWphU8Xsp2oHE/CdQsd7HHWmfdc5Q3u7FMVnJBHUokZdjgJQmlwQpoCstC8zXy7gtvOfWkCXMfk
	pJ3NWPECly7I9SJto7vgzqi84tbmvcSeM3hjMZImB9D409TJfHrUVFc9nNlwch+Ru1/cCvbEnqS
	QNcLUmmKhOPcPhjfWhmTfsKGwvOvBG2WJ7NcsRsB0aWWbw63SMXSe9d5RnCtDfADgDzyt+J+2Nf
	Wi1/HQDsyygY8eg==
X-Google-Smtp-Source: AGHT+IG1SRocew/woE3uS+KwwlFuShOVr+D6+gAoal7pb1bgIp8zpx4UNcPkC37nC/tBic4cfQ1i1Q==
X-Received: by 2002:a5d:64cd:0:b0:3a0:b550:ded4 with SMTP id ffacd0b85a97d-3a1f6437188mr3688417f8f.13.1746808341315;
        Fri, 09 May 2025 09:32:21 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Oleksii Kurochko ,
	Shawn Anastasio 
Subject: [PATCH v2 3/3] xen: Sort includes
Date: Fri,  9 May 2025 17:32:12 +0100
Message-Id: <20250509163212.2948359-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250509163212.2948359-1-andrew.cooper3@citrix.com>
References: <20250509163212.2948359-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

... needing later adjustment.  Drop types.h when it's clearly not needed.

No functional change.

Signed-off-by: Andrew Cooper 
Acked-by: Jan Beulich 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
---
 xen/arch/arm/mmu/setup.c   |  2 +-
 xen/arch/x86/alternative.c | 12 ++++++------
 xen/arch/x86/livepatch.c   |  8 ++++----
 xen/common/memory.c        |  4 +++-
 xen/common/page_alloc.c    |  5 ++---
 xen/include/xen/mm.h       |  6 +++---
 6 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 30afe9778194..f6119ccacf15 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -12,8 +12,8 @@
 #include 
 #include 
 
-#include 
 #include 
+#include 
 
 /* Override macros from asm/page.h to make them work with mfn_t */
 #undef mfn_to_virt
diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index 43b009888c02..03669e9d8e8a 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -4,18 +4,18 @@
  */
 
 #include 
-#include 
+#include 
+#include 
+
+#include 
 #include 
 #include 
+#include 
+#include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 #define MAX_PATCH_LEN (255-1)
 
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index bdca355dc6cc..5158e91f7e6e 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -5,14 +5,14 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
-#include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8ca4e1a8425b..61a94b23abae 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -25,12 +25,14 @@
 #include 
 #include 
 #include 
-#include 
+
 #include 
 #include 
 #include 
 #include 
+
 #include 
+
 #include 
 
 #ifdef CONFIG_X86
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index bd4538c28d82..8f891d12dbf0 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -133,7 +133,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -144,14 +143,14 @@
 #include 
 #include 
 
-#include 
 #include 
+#include 
 
 #ifdef CONFIG_X86
 #include 
 #include 
-#include  /* for highmem_start only */
 #include 
+#include 
 #else
 #define p2m_pod_offline_or_broken_hit(pg) 0
 #define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg)
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index e89942b87d1e..78cbb977dd04 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -63,12 +63,12 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
+#include 
+
 #include 
 
 struct page_info;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri May 09 17:40:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 17:40:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980302.1366755 (Exim 4.92)
	(envelope-from )
	id 1uDRhi-00049n-6z; Fri, 09 May 2025 17:40:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980302.1366755; Fri, 09 May 2025 17: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 1uDRhi-00049g-3x; Fri, 09 May 2025 17:40:10 +0000
Received: by outflank-mailman (input) for mailman id 980302;
 Fri, 09 May 2025 17:40:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDRhg-00049a-It
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 17:40:08 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a57708db-2cfc-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 19:40:07 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a0b6aa08e5so2085606f8f.1
 for ; Fri, 09 May 2025 10:40:07 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f5a4d0dbsm3813015f8f.88.2025.05.09.10.40.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 10:40: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" 
X-Inumbo-ID: a57708db-2cfc-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746812406; x=1747417206; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/ufqjMjjGLDcX/y6Ny6XzzQY7VtN6IoO8mdowiNXBhc=;
        b=iGV34uGaVTi8UuDCFd0plaC7iwERVYySwF+Y7vDzQHoJ5aFyLmfcN2VsrQbXm9QMog
         wZUsKI0kzrUtAQ0udDIBf8PxKyuYxFBaG4hLMcxy1y+AgI1BTcRWOCujnga5nvEE41EK
         rS/tTwJJvgS9xQmg0k25BV1auAqzNjfLxNnyw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746812406; x=1747417206;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/ufqjMjjGLDcX/y6Ny6XzzQY7VtN6IoO8mdowiNXBhc=;
        b=K1OPUwn9m3vWRIgqTVQHZq/y4UfoWWqrfaPZtM86gLRJ+r8c9ifn3dnYIky5LbWTip
         3pcm+4J0/qzNldyN0drLvgp9YhnzQoRjCWukH4HAe5JfMJ7yOZ6AH1Z2pSvFT8JHidBy
         VW1Ozx2lXlyNIZ583xXhU057Ef1tMpuiFfH9qt+/9NRdiDa+EIav5yEvzkIcWsl3gm+o
         P66mWQxPViHH5Vz3yFHFbHNnSRucKUZJL+FlYSLknvOwFxf0krdVmHtg6GJgOagaJ1lI
         Sb+ctfnEN1bMv/4GNZFJIzVRdhX4YAatq6iffsWDMf+o+aUbje5j8B3Y1JPOjIaRKrRp
         i+jA==
X-Forwarded-Encrypted: i=1; AJvYcCXwKzTH0rb2W2Z+x3owYJUaqaOZL4zz5+c73d5O/5Q8nP8UWSFV4jilF5VXYPZUY8PJWshJawEm1MA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzKfKDtQT+4L3kZnuO8MJwRyMQ6dHZWo7LQC72w8rvG1ovyqqoz
	bSHgQM9hk6GMs33DqNnJqnx81WRfVgU7KhnlOLPtw5BMM3trod9xOLiHD5ADRck=
X-Gm-Gg: ASbGncti+iOO2u9eeuMm6yf2iXiZY8bt5v3Bb05nXqThlILwA7vqUkr1cHqnS1itdRz
	nF5TAx091Sd0E4Afcpau64iPeVmzhwaxde2AUvNNhtyOYzkhgJt+nVsJf/5M5azQgvBuIQH74Ej
	OIhM5gKaMIOMFHJNVQky98TrUgHZKYfLozzlyXGgESJaywvCihybiOwG/lqGq0xaPKcUPQBpyrP
	16ktdQj25MZo+DsvgQSbc4yqYQMZvMnrQBWuDaW9pR0VJRlLsfdyTAp2KLPoYdgG1fZNGo0I2Ez
	V5BWam/en9erZEWuuj1wZvzGCXEoT3z3xZ40SHjoyB89E1eRSPj+EzPl2mojbj8kpbhdeZphqXr
	OKkCwZA==
X-Google-Smtp-Source: AGHT+IGpzR3UIvediz0n3JTh8bTmafordVL/oLFjXDkwr+7iCGoGND6lrzbu67k0NCMWUUGDEOAOEg==
X-Received: by 2002:a5d:64ac:0:b0:38d:ba8e:7327 with SMTP id ffacd0b85a97d-3a1f6a1af23mr3091439f8f.8.1746812406265;
        Fri, 09 May 2025 10:40:06 -0700 (PDT)
Message-ID: <16fa3d79-7963-4334-a587-5cc289cfd693@citrix.com>
Date: Fri, 9 May 2025 18:40:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/4] Allows Secure Boot for Kexec
To: Frediano Ziglio 
Cc: Frediano Ziglio , xen-devel@lists.xenproject.org,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250507094253.10395-1-freddy77@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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 09/05/2025 4:34 pm, Frediano Ziglio wrote:
> On Fri, May 9, 2025 at 4:04 PM Andrew Cooper  wrote:
>> On 07/05/2025 10:42 am, Frediano Ziglio wrote:
>>> Ross Lagerwall (4):
>>>   xen/lib: Export additional sha256 functions
>>>   kexec: Include purgatory in Xen
>>>   kexec: Implement new EFI load types
>>>   kexec: Support non-page-aligned kexec segments
>> I realise a lot of this is coming from kexec-tools and/or Linux, but it
>> looks very very mad.
>>
>> From patch 1, we're embedding this in Xen:
>>
>> xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
>> -rw-r--r-- 1 andrew andrew 30K May  9 15:24 purgatory.ro
>>
>> yet -Wa,--strip-local-absolute alone halves the size:
>>
>> xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
>> -rw-r--r-- 1 andrew andrew 17K May  9 15:25 purgatory.ro
>>
>> Looking at purgatory itself, we enter at purgatory_start, load a local
>> GDT, set up a local stack, call into C for the hashing (and nothing
>> else), then jmp to entry64...
>>
>> ... which loads a (different) local GDT, (different) local stack, loads
>> the GPRs and then jumps into the new kernel.
>>
>> Combined with kexec_reloc(), that's 3x we change GDT and stack in
>> several hundred instructions.
>>
>>
>> Looking further at patch 2, we only set up 3 GPRs; %rip, %rsp and %rdi
>> pointing the parameter block.
>>
>> Patch 2 also contains an a large amount of EFI-editing logic (all
>> vulnerable to XSA-25), which AFAICT exists only because purgatory is
>> built non-PIC and wants relocating.  I can't see any external
>> references, or anything that couldn't be resolved at link time for a PIC
>> build.
>>
>>
>> There are two things which purgatory does which Xen doesn't currently
>> cater for:
>>
>> 1) Setting up the GPRs in that manner
>> 2) The digest checks
>>
>> #1 is very easy to fix and can probably even be done on the current ABI
>> (older Kexecs using purgatory won't care), and #2 ought to be easy too
>> by extending machine_kexec().  We can do the digest checks
>> unconditionally (it's a sensible check irrespective).
>>
> I think the problem of #2 is that doing in the purgatory avoids
> problems like possible memory corruptions. For instance if the host is
> crashing due to some corruption it could not always be possible to
> boot the saved kernel.

It doesn't really matter if Xen does the digest check right at the point
of exiting, or purgatory does it moments later.

If there's memory corruption anywhere on this path, we're not making it
into the crash kernel whomever does the digest check.

Crashing is a best-effort exercise; it's never guaranteed to be successful.
>> I think that removes the majority of this series, with no loss in
>> functionality?
>>
>> Given that we're leaving the signature check to the dom0 kernel (which
>> is TCB and therefore can in the UEFI-SB model), we just might be able to
>> get away without any hypercall changes at all?
>>
> Yes and no. The user space could not provide the purgatory. But if the
> kernel is providing it, preventing the user space to send it, I
> suppose it can be done. At this point however the question is how to
> change the interface provided to userspace for doing it. It could make
> sense to have the changes in xen/include/public/kexec.h and let the
> kernel do the rest.

I'm not really suggesting any change in userpsace/dom0 kernel.  I'm
suggesting "we don't need a purgatory blob at all given two simple
changes in Xen."

This in turn means (I think) we can drop all the ELF relocation logic.

I'm unsure whether we need new hypercall subopts or not.  Even if we do,
I think the result can still be more simple than currently presented.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 09 18:13:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 18:13:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980314.1366764 (Exim 4.92)
	(envelope-from )
	id 1uDSEJ-0008GJ-LL; Fri, 09 May 2025 18:13:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980314.1366764; Fri, 09 May 2025 18:13: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 1uDSEJ-0008GC-IP; Fri, 09 May 2025 18:13:51 +0000
Received: by outflank-mailman (input) for mailman id 980314;
 Fri, 09 May 2025 18:13:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDSEI-0008Fz-IU
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 18:13:50 +0000
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com
 [2607:f8b0:4864:20::1136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 575c2a77-2d01-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 20:13:44 +0200 (CEST)
Received: by mail-yw1-x1136.google.com with SMTP id
 00721157ae682-70a15eda369so26583977b3.3; 
 Fri, 09 May 2025 11:13:44 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-70a3d9ed372sm6744797b3.96.2025.05.09.11.13.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 11:13:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 575c2a77-2d01-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746814423; x=1747419223; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5mt4ZkZblI1GuhrjNM/VCqG5Yg5B1oJzdx/kJOsUzYg=;
        b=Qde/Mz8t8/yg2IPb9JIIgSe0GL04gAfpyWrdKfwtknHXwsyGByw5AROCM+gpTy6g+i
         GEVvHMf7Z4VReCDSmt9Kf0yfsiGnDfpfDRzHbkY+wh/z+KduxS8tu2qnylm5weisnyVf
         M4T7+RgVJeXayfGyHE2eWIievj+w/3zQ61S3xPmoGgHrdywWUvGMlsPducl0ZPjFuU91
         tAh/k1s2KBr2kMieX3/YTbo2bbWkCcz86Vvk5oZcGG3t/Zgbe5ws9fWS4Qjmnz3ODwPy
         9eU6yfG+NXfp+A502gajTK1tdUPrxJW0T6xw6bvBzQYdcc/y36z+4ALNg2WIcUJcMgbk
         JuJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746814423; x=1747419223;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=5mt4ZkZblI1GuhrjNM/VCqG5Yg5B1oJzdx/kJOsUzYg=;
        b=SMKwfRSC3Mgcw+JrnLYXI7bU5DW03cZoYI3vF3u8gbmzTh/RG3IohPVGw+IGDgHPzR
         2qYOY2Pwnp62g1ZANhqJJDAp95wqzPziJ8WWNqdacc0EuL8T1EB+jV9Q+tDtnJVm1VnK
         U62pJ1wyUEEAkwLgNzgMi83/IkMJAi4oSiXeWk7alKwFgmlmQozTiL3o/6FOfN7nFAt3
         q+ebgR4S2XXrUEZmRhpm4I2Q8sJ4p4mwC0xgOd/LW7cfcCvqtlOa6F8BjOxImcBSuErt
         rZLbAFOA5+2nYSghemJ1IO6NUgjbNhdNB/92t+XoC/HjrsFlX3GgskaK+PZv5p+hkQ8S
         ie6Q==
X-Forwarded-Encrypted: i=1; AJvYcCVOhdz1JAEBGFKQaiGqEqWJpo0XmpFyMRmjMFmRHX9ZOErbRuz4uVZOU5m2asGlCvJz0V8nacCA3BJUEz3QUjg0/w==@lists.xenproject.org
X-Gm-Message-State: AOJu0YyTLaUcZyMaCb13a6IjAaQalW5jl0d3HIfmbQwQ24xbcVpQmya7
	CeOSOZXRb09kCHcH0eHx7HqhQ5f/OHgmlz1i34PLyoCzMApsHvbm
X-Gm-Gg: ASbGnctm0msiuFc2SuWjK3lH/h3UuWEa/7lo/TTr4225/2nXqTUwPK+Mpf9Bte81fD9
	w0cZ5Iafimdd7tp8OaheeOsOiKY5cUYXRL8c9Ay/sy3uUCw+hGJba7oTINZRSmTAtu3FpqT2O4Y
	aW4zF2QTQdweqcs0WJWid02S8MP4vBph5XKpqT58fnnu11dhdSgZLnhbJ0oly9m3sHHsRwVFMCm
	LnumQ3fbSAPzMG1VzrgyuIFvKa16WSCjmBolCPkAcb4zit1aBXRgK4HWXPFZZUrlojXeuZ+k0ab
	4n0vzbKSPJz66wqKcbihhnrbMpzC2QE5L3tJsw4ex012
X-Google-Smtp-Source: AGHT+IEkqfIPGLoMEPeZciQ80EWxEFk5p55qyuSyuqCGNjGGnorNaLDmBMW0PWVI3FOT2rTJ2pxCjg==
X-Received: by 2002:a05:690c:6c93:b0:708:183d:ce0e with SMTP id 00721157ae682-70a3fa18005mr73955197b3.16.1746814422586;
        Fri, 09 May 2025 11:13:42 -0700 (PDT)
Message-ID: <6b3087cc-e474-42b2-a777-1d66b0d4cbda@gmail.com>
Date: Fri, 9 May 2025 14:14:27 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Alejandro Vallejo ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xenia Ragiadakou ,
 Stefano Stabellini 
Cc: Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: Mapping memory into a domain
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------CqreNhBax561L2nJkgdGpHix"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------CqreNhBax561L2nJkgdGpHix
Content-Type: multipart/mixed; boundary="------------TENJrm0RoStW7wGZmTCt8Fbe";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Alejandro Vallejo ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xenia Ragiadakou ,
 Stefano Stabellini 
Cc: Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
Message-ID: <6b3087cc-e474-42b2-a777-1d66b0d4cbda@gmail.com>
Subject: Re: Mapping memory into a domain
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
 
In-Reply-To: 
Autocrypt-Gossip: 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==

--------------TENJrm0RoStW7wGZmTCt8Fbe
Content-Type: multipart/mixed; boundary="------------zD4bfoOZSI3Mtlg08ny0FMaB"

--------------zD4bfoOZSI3Mtlg08ny0FMaB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/9/25 5:47 AM, Alejandro Vallejo wrote:
>>>>>> 2. It can grab the *current* location of the pages and register an=

>>>>>>    MMU notifier.  This works for GPU memory and file-backed memory=
=2E
>>>>>>    However, when the invalidate_range function of this callback, t=
he
>>>>>>    driver *must* stop all further accesses to the pages.
>>>>>>
>>>>>>    The invalidate_range callback is not allowed to block for a lon=
g
>>>>>>    period of time.  My understanding is that things like dirty pag=
e
>>>>>>    writeback are blocked while the callback is in progress.  My
>>>>>>    understanding is also that the callback is not allowed to fail.=

>>>>>>    I believe it can return a retryable error but I don=E2=80=99t t=
hink that
>>>>>>    it is allowed to keep failing forever.
>>>>>>
>>>>>>    Linux=E2=80=99s grant table driver actually had a bug in this a=
rea, which
>>>>>>    led to deadlocks.  I fixed that a while back.
>>>>>>
>>>>>> KVM implements the second option: it maps pages into the stage-2
>>>>>> page tables (or shadow page tables, if that is chosen) and unmaps
>>>>>> them when the invalidate_range callback is called.
>=20
> I'm still lost as to what is where, who initiates what and what the end=

> goal is. Is this about using userspace memory in dom0, and THEN sharing=

> that with guests for as long as its live? And make enough magic so the
> guests don't notice the transitionary period in which there may not be
> any memory?
>=20
> Or is this about using domU memory for the driver living in dom0?
>=20
> Or is this about something else entirely?
>=20
> For my own education. Is the following sequence diagram remotely accura=
te?
>=20
> dom0                              domU
>  |                                  |
>  |---+                              |
>  |   | use gfn3 in the driver       |
>  |   | (mapped on user thread)      |
>  |<--+                              |
>  |                                  |
>  |  map mfn(gfn3) in domU BAR       |
>  |--------------------------------->|
>  |                              +---|
>  |              happily use BAR |   |
>  |                              +-->|
>  |---+                              |
>  |   | mmu notifier for gfn3        |
>  |   | (invalidate_range)           |
>  |<--+                              |
>  |                                  |
>  |  unmap mfn(gfn3)                 |
>  |--------------------------------->| <--- Plus some means to making gu=
est=20
>  |---+                          +---|      vCPUs pause on access.
>  |   | reclaim gfn3    block on |   |
>  |<--+                 access   |   |
>  |                              |   |
>  |---+                          |   |
>  |   | use gfn7 in the driver   |   |
>  |   | (mapped on user thread)  |   |
>  |<--+                          |   |
>  |                              |   |
>  |  map mfn(gfn7) in domU BAR   |   |
>  |------------------------------+-->| <--- Unpause blocked domU vCPUs
>  |                                  |

I believe this is accurate, yes.

>>>> - The switch from =E2=80=9Cemulated MMIO=E2=80=9D to =E2=80=9CMMIO o=
r real RAM=E2=80=9D needs to
>>>>   be atomic from the guest=E2=80=99s perspective.
>>>
>>> Updates of p2m PTEs are always atomic.
>> That=E2=80=99s good.
>=20
> Updates to a single PTE are atomic, sure. But mapping/unmapping sizes
> not congruent with a whole superpage size (i.e: 256 KiB, more than a
> page, less than a superpage) wouldn't be, as far as the guest is
> concerned.
>=20
> But if my understanding above is correct maybe it doesn't matter? It
> only needs to be atomic wrt the hypercall that requests it, so that the=

> gfn is never reused while the guest p2m still holds that mfn.

I believe you are correct.  The only requirement is that the guest behave=
s
correctly if its page faults race against what is happening in the backen=
d
domain.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------zD4bfoOZSI3Mtlg08ny0FMaB
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------zD4bfoOZSI3Mtlg08ny0FMaB--

--------------TENJrm0RoStW7wGZmTCt8Fbe--

--------------CqreNhBax561L2nJkgdGpHix
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgeRgQACgkQszaHOrMp
8lN5chAAh5G6rAdoCcb9gHqKHquiJVzT30QehcLd2oJNLzD1uc0LDiZepkXo2lmC
CvH3Jom17G1lfibMDbGaOKaypdi6PRghrYrIxMSbMRCCtMdlVDTupU5dZ1uEYSjJ
8k3b0mIQZxsvgFqwVieKWVqZk4Gm944aDMo8IFh0eNN9jS1jpZLMvYazCmruyOGB
OGUYWTKunLhXijZEYEGesqpq3i4ccvIaFAMdW+xjSvrRcZHlB72ysjrXddj/BLEs
i7s9ATSawCFEkw8zY0JKHI0QruibYBZMM5VXi1vDy3v+0jIwFKzH+loSj2F4lCdU
OsXV/B4/fQJM8CBs6b1z72dU0vZLfRRNWzFn6c/jhIY0npCxhXib1K+pLin+WGSJ
WdHKnfDohdOzfqyJNXvCGm0rG0Mxl0kHdRMxRUuf3+GN7S1+jxHZ37rxVuR+DR0Y
zi8bFVkOrGbw17sI4S5uPzI91jUkdriNYnr7v26yXCjGi6Igm2Brfl8/DF51MOip
Thl1/PXaPTCJPWllRxZr10rSx4Tu/iNe2xBbFqeWxcIij/0YnNzvdutaTdGUehR+
mv3mYhBldGmLM0PWaeizoPIVG3K3cJrgOTwRC+Ue5dYGI/SJFFLNQKcPkceEN1Q1
T+IRyNMf6jgFIzexW2tsHPyHxlUg7Emr7sWV5Fr6KFHJI3udWb4=
=MwMR
-----END PGP SIGNATURE-----

--------------CqreNhBax561L2nJkgdGpHix--


From xen-devel-bounces@lists.xenproject.org Fri May 09 18:21:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 18:21:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980329.1366774 (Exim 4.92)
	(envelope-from )
	id 1uDSLU-0001ZA-FO; Fri, 09 May 2025 18:21:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980329.1366774; Fri, 09 May 2025 18: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 1uDSLU-0001Z3-C9; Fri, 09 May 2025 18:21:16 +0000
Received: by outflank-mailman (input) for mailman id 980329;
 Fri, 09 May 2025 18:21:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDSLT-0001YZ-Eu
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 18:21:15 +0000
Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com
 [2607:f8b0:4864:20::1131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 635f23b8-2d02-11f0-9eb4-5ba50f476ded;
 Fri, 09 May 2025 20:21:13 +0200 (CEST)
Received: by mail-yw1-x1131.google.com with SMTP id
 00721157ae682-7091d7244e8so24517387b3.3; 
 Fri, 09 May 2025 11:21:13 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-70a3d8b5f02sm6903137b3.40.2025.05.09.11.21.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 11: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" 
X-Inumbo-ID: 635f23b8-2d02-11f0-9eb4-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746814872; x=1747419672; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4zntexxrtXbGpTr0IqtCk77DyvW9plnkfX84H0ipa94=;
        b=IIZyrHZWD2/hDrPwai/KWi9/HISPbEcnzKsFukyGui8o7nJ43GAj+40k6tfJxglNEz
         v5iWFhaQ5D9jIA/z7rHEQQ/UW3A6i3TxCR8GS597n5OBU/tXxkkLULXFN/j3fgP3Pf7T
         Uza+eW62lwrLcjAaGvOkZtX9VwJn4+0A9K5gC23GcG3BG/g7V36SijooCFTbH+fcsupT
         cy6qaxM4fVMBtuLn14YSE5u6qvu98wRkhIQOBxkv0y07P+wtBDF+XkYP0wbOneMQlJyc
         +EYJoT8HDhyhxEAF4mp331YoQn8RsiIQYGgZvndP3xkbN9XWxOroaFAWMTJy/OaFtEUL
         UpVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746814872; x=1747419672;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=4zntexxrtXbGpTr0IqtCk77DyvW9plnkfX84H0ipa94=;
        b=CsrQFeksRQ6tD0hjZJwLZpNt5Du8KghjC1mdytR3g8SbFT657koDtueiLQs9JzsSDf
         EEG4j4LtJDM9Jn2epbCfUI5lX50zrve9Y5Kpd+a1L2nS6v2n1Zq0tFf2NVyd2onqJgXj
         DHfQUfLfQpAki+ZdPaaUTNSpsD/xEOHXb/U9T92uBm/gC1fgqe9l6Qd+F4TR9ufH7Avm
         E6kkTNEZ7nvhFHnv1fPEXUEjv+8fQv5PnPaPj5W7wTC1EXf1e6WSErePfPUTuoss933o
         kxXa+tfLic24zkLlYbuxl//lFldUeUwdAKB8bFfqNjCJRquqChLpgB46B62xgk+Fq0p2
         Kc1A==
X-Forwarded-Encrypted: i=1; AJvYcCU0mc6fNkrjZU8SrVU1JHr7Gw0hpzKjZtc5tjAnvX848R0AFnLUaMoCVytrRDZipkJ8oiwtg/MZz7MbK9mQ89W5bw==@lists.xenproject.org, AJvYcCWWks0bRWWN9exPuKdNIdRIMhwZ9+A2REl5ifKrI6/feWoXcNJhn/DvVnLf41A3+HMsM0C3ccLX36Kc@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6CCLbgn+e4I2vc9KHNLwure82ZlPpM9is8SP1obNNU1kncUto
	mQs19heDTPfH5LzIWAdbhuUiARsKOkt9SEVDRqdtCk60i86jT4hP
X-Gm-Gg: ASbGncvB9XzrbFLAy0C0QqTZ6wLfw04moqfFzHBPjjQpy3QqwdfBrgbagWyjSIuyNsu
	P3KvoZYD3Kc8yZDYiLv2VCAr3+VoWafqJ8mYtbDEn1zATIKHm0/B6E8QTVJH86YSAk/ltcN3teM
	zgv7D2hw6l50ALtP8QlTTIOAfZoDZOxCjJUXMla8eeW353txAEUJ1911zRDh8p/bLPC3Kc8kHW3
	kwjuBloutXLCPxjaod193mcPaQHoHt4jhaF7MBv0YJ1Mw+1wnVA50kbfKR/sBOd6FaJqLNkp2QR
	4NtyUo46U8opI9kLX1VDIsL+V4gGYeArew2J3Yjw6axWAKC+dDs2uvo=
X-Google-Smtp-Source: AGHT+IEVsyM6X3IrOQru5hGqsmstAlL2AaflPi/HB4Jiv7oZZWGZRYTglSAxu4m6CCDbcmJEfM6K4Q==
X-Received: by 2002:a05:690c:708d:b0:709:1405:5311 with SMTP id 00721157ae682-70a3f872c98mr59076917b3.0.1746814872105;
        Fri, 09 May 2025 11:21:12 -0700 (PDT)
Message-ID: 
Date: Fri, 9 May 2025 14:21:57 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo 
Cc: Xenia Ragiadakou ,
 Stefano Stabellini ,
 Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
  
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: Mapping memory into a domain
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------mmEGf3cXJ3YhKA4aWHKQ0WFS"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------mmEGf3cXJ3YhKA4aWHKQ0WFS
Content-Type: multipart/mixed; boundary="------------594XE7K068CkFPjoQ0OSmnV0";
 protected-headers="v1"
From: Demi Marie Obenour 
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alejandro Vallejo 
Cc: Xenia Ragiadakou ,
 Stefano Stabellini ,
 Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
Message-ID: 
Subject: Re: Mapping memory into a domain
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
  
In-Reply-To: 
Autocrypt-Gossip: 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==

--------------594XE7K068CkFPjoQ0OSmnV0
Content-Type: multipart/mixed; boundary="------------BmcfzFNLdI0dHm9vE8MzCBbZ"

--------------BmcfzFNLdI0dHm9vE8MzCBbZ
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/9/25 6:50 AM, Roger Pau Monn=C3=A9 wrote:
> On Fri, May 09, 2025 at 11:47:36AM +0200, Alejandro Vallejo wrote:
>>>>>>> A Linux driver that needs access to userspace memory
>>>>>>> pages can get it in two different ways:
>>>>>>>
>>>>>>> 1. It can pin the pages using the pin_user_pages family of APIs.
>>>>>>>    If these functions succeed, the driver is guaranteed to be abl=
e
>>>>>>>    to access the pages until it unpins them.  However, this also
>>>>>>>    means that the pages cannot be paged out or migrated.  Further=
more,
>>>>>>>    file-backed pages cannot be safely pinned, and pinning GPU mem=
ory
>>>>>>>    isn=E2=80=99t supported.  (At a minimum, it would prevent the =
pages from
>>>>>>>    migrating from system RAM to VRAM, so all access by a dGPU wou=
ld
>>>>>>>    cross the PCIe bus, which would be very slow.)
>>>>>>
>>>>>> From a Xen p2m this is all fine - Xen will never remove pages from=
 the
>>>>>> p2m unless it's requested to.  So the pining, while needed on the =
Linux
>>>>>> side, doesn't need to be propagated to Xen I would think.
>>
>> It might still be helpful to have the concept of pinning to avoid them=

>> being evicted for other reasons (ballooning?). I don't think it'd be
>> sane to allow returning to Xen a page that a domain ever shared with a=

>> device.
>=20
> If mapped using the p2m_mmio_direct type in the p2m a domain won't be
> able to balloon them out.  It would also be misguided for a guest
> kernel to attempt to balloon out memory that I presume will be inside
> of a PCI device BAR from the guest point of view.

Indeed it will be inside a BAR.

>> re: being requested. Are there real promises from Xen to that effect? =
I
>> could make a hypervisor oversubscribing on memory that swaps non-IOVA
>> mem in and out to disk, moving it around all the time and it would be
>> compliant with the current behaviour AIUI, but it wouldn't work with
>> this scheme, because the mfn's would be off more often than not.
>=20
> Even if Xen supported domain memory swapping, that could never be used
> with domains that have devices attached, as it's not possible to fixup
> the p2m on IOMMU fault and retry the access.
>=20
> Not sure you could even move mfns around, as you would need an atomic
> way to copy the previous page contents and set the PTE to point to the
> new page.
>=20
> Unless you want to get into a (IMO) complicated scheme where the
> domain notifies the hypervisor which ranges are being used for device
> DMA accesses (and thus requires guest kernel changes), I think
> swapping of guest memory when there are assigned devices is a no-go.
>=20
> Xen has (or had? as I never actually seen it being used) a mechanism
> to swap domain memory to a dom0 file (see tools/xenpaging.c).  However
> more than one provider had mentioned to me that one feature they
> particularly preferred of Xen over KVM is that it would never swap
> guest memory.  Not sure if that's still the case, but some struggled
> to prevent KVM from swapping guest memory, and got complains of
> slowness from their tenants.
>=20
> For the purposes of getting a prototype I would suggest that you
> assume p2m memory cannot be randomly swapped out, unless requested by
> either the guest or the control domain.

The API being discussed here needs to support frontends that have
assigned PCI devices, but the pages should never be mapped into
the frontend domain=E2=80=99s IOMMU context.  If the frontend tries to
DMA into one of these pages it=E2=80=99s a frontend bug.

>>>>> If pinning were enough things would be simple, but sadly it=E2=80=99=
s not.
>>>>>
>>>>>>> 2. It can grab the *current* location of the pages and register a=
n
>>>>>>>    MMU notifier.  This works for GPU memory and file-backed memor=
y.
>>>>>>>    However, when the invalidate_range function of this callback, =
the
>>>>>>>    driver *must* stop all further accesses to the pages.
>>>>>>>
>>>>>>>    The invalidate_range callback is not allowed to block for a lo=
ng
>>>>>>>    period of time.  My understanding is that things like dirty pa=
ge
>>>>>>>    writeback are blocked while the callback is in progress.  My
>>>>>>>    understanding is also that the callback is not allowed to fail=
=2E
>>>>>>>    I believe it can return a retryable error but I don=E2=80=99t =
think that
>>>>>>>    it is allowed to keep failing forever.
>>>>>>>
>>>>>>>    Linux=E2=80=99s grant table driver actually had a bug in this =
area, which
>>>>>>>    led to deadlocks.  I fixed that a while back.
>>>>>>>
>>>>>>> KVM implements the second option: it maps pages into the stage-2
>>>>>>> page tables (or shadow page tables, if that is chosen) and unmaps=

>>>>>>> them when the invalidate_range callback is called.
>>
>> I'm still lost as to what is where, who initiates what and what the en=
d
>> goal is. Is this about using userspace memory in dom0, and THEN sharin=
g
>> that with guests for as long as its live? And make enough magic so the=

>> guests don't notice the transitionary period in which there may not be=

>> any memory?
>>
>> Or is this about using domU memory for the driver living in dom0?
>>
>> Or is this about something else entirely?
>>
>> For my own education. Is the following sequence diagram remotely accur=
ate?
>>
>> dom0                              domU
>>  |                                  |
>>  |---+                              |
>>  |   | use gfn3 in the driver       |
>>  |   | (mapped on user thread)      |
>>  |<--+                              |
>>  |                                  |
>>  |  map mfn(gfn3) in domU BAR       |
>>  |--------------------------------->|
>>  |                              +---|
>>  |              happily use BAR |   |
>>  |                              +-->|
>>  |---+                              |
>>  |   | mmu notifier for gfn3        |
>>  |   | (invalidate_range)           |
>>  |<--+                              |
>>  |                                  |
>>  |  unmap mfn(gfn3)                 |
>>  |--------------------------------->| <--- Plus some means to making g=
uest=20
>>  |---+                          +---|      vCPUs pause on access.
>>  |   | reclaim gfn3    block on |   |
>>  |<--+                 access   |   |
>>  |                              |   |
>>  |---+                          |   |
>>  |   | use gfn7 in the driver   |   |
>>  |   | (mapped on user thread)  |   |
>>  |<--+                          |   |
>>  |                              |   |
>>  |  map mfn(gfn7) in domU BAR   |   |
>>  |------------------------------+-->| <--- Unpause blocked domU vCPUs
>=20
> The guest vCPU will already pause on access if there's a p2m
> violation, until the ioreq has completed and the vCPU execution can
> resume.  That's in control of the ioreq server that handles the
> request.
>=20
> I don't know about the dom0 user-space part, but that's possibly of no
> concern for the implementation side in Xen?

I believe so, yes.

> My understanding of the actions needed from the Xen side is:
>=20
>  1. Map either RAM owned by the hardware domain or an MMIO page into
>     a domain p2m.
>  2. Remove entries from a domain p2m.
>  3. Handle p2m violations resulting from guest accesses, using 1. and
>     force a guest access retry (or emulate the access).
>=20
> 1. Can possibly be done with XEN_DOMCTL_memory_mapping and
> XENMEM_add_to_physmap_batch, but as I understood it it's not ideal.
> Demi would like a way to use the same hypercall to map either RAM or
> IOMEM into a domain p2m.

Indeed so, and also the backend domain might be a driver domain instead
of the hardware domain.  It needs to have privilege over the frontend,
but it should not need privilege over the whole system.

> 2. What hypercall to use depends on how the memory is mapped.
>=20
> 3. ioreq servers will already get requests for accesses to unmapped
> regions they have registered for.  If the access is to be retried we
> need to expand ioreq interface a bit to handle this case.  Adding a
> new ioreq state like STATE_IORESP_RETRY might be enough?  Maybe I'm
> being naive though.

This is where an implementation in a real userspace emulator would
be very useful, to ensure that the API being implemented is actually
usable in practice.

>>>>> - The switch from =E2=80=9Cemulated MMIO=E2=80=9D to =E2=80=9CMMIO =
or real RAM=E2=80=9D needs to
>>>>>   be atomic from the guest=E2=80=99s perspective.
>>>>
>>>> Updates of p2m PTEs are always atomic.
>>> That=E2=80=99s good.
>>
>> Updates to a single PTE are atomic, sure. But mapping/unmapping sizes
>> not congruent with a whole superpage size (i.e: 256 KiB, more than a
>> page, less than a superpage) wouldn't be, as far as the guest is
>> concerned.
>=20
> I've assumed the question was towards PTE updates, as to whether
> PTE entries where always consistent.
>=20
>> But if my understanding above is correct maybe it doesn't matter? It
>> only needs to be atomic wrt the hypercall that requests it, so that th=
e
>> gfn is never reused while the guest p2m still holds that mfn.
>=20
> I think it only matters that the PTE is always consistent, either
> mapped or unmapped (and thus generate an ioreq request on access when
> unmapped).
You are correct.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------BmcfzFNLdI0dHm9vE8MzCBbZ
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------BmcfzFNLdI0dHm9vE8MzCBbZ--

--------------594XE7K068CkFPjoQ0OSmnV0--

--------------mmEGf3cXJ3YhKA4aWHKQ0WFS
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgeR8YACgkQszaHOrMp
8lNy4Q//bDBOBVqy979AokZ3OzDlS1RLWu8cviF4QxcvcW1d0PZA6RRQppGYizgZ
LywUjHCCB1c0mFg9ss5lOz+TuDWmh94J5qyfPRqSFyGPKCPILeoR4LuKNpg7UQAe
evGPOHxsyKRKEtJwvKuxaU3BgdBWBWWMa5NkOdlRb/hBm1efefeKdXOw9QYm8vUM
uQ+6B93jX9YMqTaZR4s/bmRYnmKwQ7FNegDLAWFbMyV0YHBLeKRDkqS8XHb4oPgW
wqUbpV04fUouvThSgaUnFLxZSNIZWS7fhbvT3TrHsY8M2Y98NHQeCetw6Tz4/JAP
jsrvDgb0uxmg78//WxwKfCgOzr0S0NtOTS6AgZHqmyoAfUqCwj6m4qZMWWlOV/j5
kIAZrqPnxkXLsZdSfagMz4cHyWsLU7enwTdAqyUt5alGCG9h7WapKpoqWt4JwPga
OySmok6+JkqjAKZ4xG27txvp6Eykpe/g3PoFjKlmahzjRVMXlipTl24fH4Rx3LTu
NEdwAfoodtnimlaOxQprkOw+a88Vv1D+XTHSpud6HKu+61CbaMBUNaVwrLSvkmcq
teT28YcZM+9IAiuhBWOorZo+V/RtkXcRmXy75LAOmbJCO++Xj8HSThpSxSap+d9Z
ygeOslHFc0wF0zC56e1Uxze5lJsl35DuiSjeD5b6lJdUSTjBXdU=
=p1Ht
-----END PGP SIGNATURE-----

--------------mmEGf3cXJ3YhKA4aWHKQ0WFS--


From xen-devel-bounces@lists.xenproject.org Fri May 09 18:29:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 18:29:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980338.1366784 (Exim 4.92)
	(envelope-from )
	id 1uDSTM-0002Bv-6e; Fri, 09 May 2025 18:29:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980338.1366784; Fri, 09 May 2025 18:29: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 1uDSTM-0002Bo-3q; Fri, 09 May 2025 18:29:24 +0000
Received: by outflank-mailman (input) for mailman id 980338;
 Fri, 09 May 2025 18:29:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDSTL-0002Bd-4E
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 18:29:23 +0000
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com
 [2607:f8b0:4864:20::b2d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 852277ba-2d03-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 20:29:19 +0200 (CEST)
Received: by mail-yb1-xb2d.google.com with SMTP id
 3f1490d57ef6-e733e25bfc7so2489611276.3; 
 Fri, 09 May 2025 11:29:19 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 3f1490d57ef6-e78fd4480e7sm662434276.7.2025.05.09.11.29.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 11:29: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" 
X-Inumbo-ID: 852277ba-2d03-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746815358; x=1747420158; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ddpdl6P19DyGPh9AM2PoOfRexY84/fwwCTxcUJ0MLoI=;
        b=Um6uE+Ve9RFyPsJn8apCUl71HsFxTcq0hqhlURP4NHTGcZbAIT/8/YbfjVG47iHjWK
         y1ZIvHl8xzEO4XN8WgFrRVIjfOBVvuZuE8vTUPy3+6E0VbJjQSlCqjGluK/5X6YciX2L
         1KgUvYGEkyKId+FEQclrYysBICox9UM9ObIuK+IjNDzyzlCLzTUF/CeOOZyCWK9H59TX
         XVjbGSTuO1olFAJGlTJDbmbosVjHQe+tKWRrxA6KfSgV3cTvAo+2ZL+otZZdmG/BOPPt
         I0B6DUq/CyFDlKB3xFktjyy61ORDvPqyuZs6xT8vIqRmUzZhH58Y+4EUlMibsoBITv+j
         UX+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746815358; x=1747420158;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=ddpdl6P19DyGPh9AM2PoOfRexY84/fwwCTxcUJ0MLoI=;
        b=Ma3FDa9XwSbgmanaTQJGbZp1WMtNcA5c/bsSLUsZSehppWGR1xUMSFG13SaLq8DsxH
         Pbos/UffWiPXBeF6YFDJZsvBaD9los5tPPfbAGyJUU2MK4XqaVGTERLuGTpmEHJwMKmx
         XVVr7ZRUq2+aXageUUXFPq46pulsfScdGmWBqSoDYurca+Zq76IAD5gfH8gDIoTL9ThT
         Qq0W12hMxvbOcFT5yHEoZ67DQMZRkOleJuMpXsdP8nwrKHu20ioCEp7dOSrnGXpo2Ruz
         FW71qW5QaBUX6cXqU9LasPhi1rYbQEjSiWpjAaDw2EYikmQTVE5pMTIJmiSvnQqm/23i
         eS0w==
X-Forwarded-Encrypted: i=1; AJvYcCWJ7CSYDa+H3Wwm6WRF+dOEmpXZyXNk0VgeXu9qj8x1WNcI3kxwbyEXYAoHe9y4L2VD3h/OIEFtS574GdbgieArTg==@lists.xenproject.org
X-Gm-Message-State: AOJu0YzwT2PReKdlz97r8ccTTm+ZMi0HWqYf3Hl/Mxdv0enCHTc/jAWP
	O0Q3oFB/XWBFI5q2djZOFXV4F/9vn4S0+DHbZ3/c5+oRrz5DK/OMReamwVRf
X-Gm-Gg: ASbGncusFFxB3cAI7ljipSlQlRiUT2fbv9Pujs6GyEEGAB3k2MQHy+hcYZ0JTf652bt
	sYaoQsMTbss3BMGbABzuvwtMmo6sHF2naEHpydPMiCeA3R5vyUH3pKlNYieeMO7d35bpCdGVnCr
	ACpyvjvvg9xjKqSdQDVK2xNAKau52O7pV28FlBKnSPzX0ac30EVIr9UbahYH9b5olZ81uy0AtHc
	YfrsFFafQZi4jIFkrf/WCektrFBeaMnchTotUjpEqnupIlSMMMQvqy25C5+4dxRxBRZhWxnE21T
	tOERujR0VP0W6kbV0TEhOv6NNpC35tZ+1Ajov98PDtUbQPaQxpSQvIw=
X-Google-Smtp-Source: AGHT+IGUFXf3c2GGNwUxL7joXA0AcVLWidDvGqDyjWOTQmrXGtP5EeeJjem7sU4xh84TWmTlpG8Ciw==
X-Received: by 2002:a05:6902:2708:b0:e78:f00e:882f with SMTP id 3f1490d57ef6-e78fdcd59c3mr6117751276.25.1746815358172;
        Fri, 09 May 2025 11:29:18 -0700 (PDT)
Message-ID: <4eedf533-493c-497e-a9a3-55a8c3a015ba@gmail.com>
Date: Fri, 9 May 2025 14:30:01 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Alejandro Vallejo ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xenia Ragiadakou ,
 Stefano Stabellini 
Cc: Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: Mapping memory into a domain
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------DrPY0QcYqVlmivEVxLRIndc0"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------DrPY0QcYqVlmivEVxLRIndc0
Content-Type: multipart/mixed; boundary="------------onXR0Ub3cBF4WnaNrm5ecFJg";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Alejandro Vallejo ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xenia Ragiadakou ,
 Stefano Stabellini 
Cc: Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
Message-ID: <4eedf533-493c-497e-a9a3-55a8c3a015ba@gmail.com>
Subject: Re: Mapping memory into a domain
References: <82772686-edcd-41e4-b81c-f6b3ded30901@gmail.com>
 
 <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
 
In-Reply-To: 
Autocrypt-Gossip: 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==

--------------onXR0Ub3cBF4WnaNrm5ecFJg
Content-Type: multipart/mixed; boundary="------------YpK2eUlpZN6RbIwMzuTCLyik"

--------------YpK2eUlpZN6RbIwMzuTCLyik
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/9/25 5:47 AM, Alejandro Vallejo wrote:
>>>>>> A Linux driver that needs access to userspace memory
>>>>>> pages can get it in two different ways:
>>>>>>
>>>>>> 1. It can pin the pages using the pin_user_pages family of APIs.
>>>>>>    If these functions succeed, the driver is guaranteed to be able=

>>>>>>    to access the pages until it unpins them.  However, this also
>>>>>>    means that the pages cannot be paged out or migrated.  Furtherm=
ore,
>>>>>>    file-backed pages cannot be safely pinned, and pinning GPU memo=
ry
>>>>>>    isn=E2=80=99t supported.  (At a minimum, it would prevent the p=
ages from
>>>>>>    migrating from system RAM to VRAM, so all access by a dGPU woul=
d
>>>>>>    cross the PCIe bus, which would be very slow.)
>>>>>
>>>>> From a Xen p2m this is all fine - Xen will never remove pages from =
the
>>>>> p2m unless it's requested to.  So the pining, while needed on the L=
inux
>>>>> side, doesn't need to be propagated to Xen I would think.
>=20
> It might still be helpful to have the concept of pinning to avoid them
> being evicted for other reasons (ballooning?). I don't think it'd be
> sane to allow returning to Xen a page that a domain ever shared with a
> device.

Memory mapped into a domain using this API must not be mapped into the
IOMMU contexts of any devices assigned to the frontend.  This ensures
that the backend unexpectedly reclaiming the memory doesn=E2=80=99t cause=

problems, even if the frontend has an assigned PCI device.  If the
frontend tries to perform DMA from a different PCI device into memory
mapped into a domain using this API, it=E2=80=99s a frontend bug and the =
IOMMU
must block the access.

>>>> If pinning were enough things would be simple, but sadly it=E2=80=99=
s not.
>>>>
>>>>>> 2. It can grab the *current* location of the pages and register an=

>>>>>>    MMU notifier.  This works for GPU memory and file-backed memory=
=2E
>>>>>>    However, when the invalidate_range function of this callback, t=
he
>>>>>>    driver *must* stop all further accesses to the pages.
>>>>>>
>>>>>>    The invalidate_range callback is not allowed to block for a lon=
g
>>>>>>    period of time.  My understanding is that things like dirty pag=
e
>>>>>>    writeback are blocked while the callback is in progress.  My
>>>>>>    understanding is also that the callback is not allowed to fail.=

>>>>>>    I believe it can return a retryable error but I don=E2=80=99t t=
hink that
>>>>>>    it is allowed to keep failing forever.
>>>>>>
>>>>>>    Linux=E2=80=99s grant table driver actually had a bug in this a=
rea, which
>>>>>>    led to deadlocks.  I fixed that a while back.
>>>>>>
>>>>>> KVM implements the second option: it maps pages into the stage-2
>>>>>> page tables (or shadow page tables, if that is chosen) and unmaps
>>>>>> them when the invalidate_range callback is called.
>=20
> I'm still lost as to what is where, who initiates what and what the end=

> goal is. Is this about using userspace memory in dom0, and THEN sharing=

> that with guests for as long as its live? And make enough magic so the
> guests don't notice the transitionary period in which there may not be
> any memory?

It is exactly about this, except that the backend domain can be any domai=
n
that is privileged over the frontend domain, rather than only dom0 or the=

hardware domain.

> Or is this about using domU memory for the driver living in dom0?

Unfortunately no.  This would be a better fit to how Xen is designed,
but it isn=E2=80=99t compatible with Linux=E2=80=99s memory management re=
quirements.

> Or is this about something else entirely?
>=20
> For my own education. Is the following sequence diagram remotely accura=
te?
>=20
> dom0                              domU
>  |                                  |
>  |---+                              |
>  |   | use gfn3 in the driver       |
>  |   | (mapped on user thread)      |
>  |<--+                              |
>  |                                  |
>  |  map mfn(gfn3) in domU BAR       |
>  |--------------------------------->|
>  |                              +---|
>  |              happily use BAR |   |
>  |                              +-->|
>  |---+                              |
>  |   | mmu notifier for gfn3        |
>  |   | (invalidate_range)           |
>  |<--+                              |
>  |                                  |
>  |  unmap mfn(gfn3)                 |
>  |--------------------------------->| <--- Plus some means to making gu=
est=20
>  |---+                          +---|      vCPUs pause on access.
>  |   | reclaim gfn3    block on |   |
>  |<--+                 access   |   |
>  |                              |   |
>  |---+                          |   |
>  |   | use gfn7 in the driver   |   |
>  |   | (mapped on user thread)  |   |
>  |<--+                          |   |
>  |                              |   |
>  |  map mfn(gfn7) in domU BAR   |   |
>  |------------------------------+-->| <--- Unpause blocked domU vCPUs
>  |                                  |

This diagram is accurate.

>>>> - The switch from =E2=80=9Cemulated MMIO=E2=80=9D to =E2=80=9CMMIO o=
r real RAM=E2=80=9D needs to
>>>>   be atomic from the guest=E2=80=99s perspective.
>>>
>>> Updates of p2m PTEs are always atomic.
>> That=E2=80=99s good.
>=20
> Updates to a single PTE are atomic, sure. But mapping/unmapping sizes
> not congruent with a whole superpage size (i.e: 256 KiB, more than a
> page, less than a superpage) wouldn't be, as far as the guest is
> concerned.
>=20
> But if my understanding above is correct maybe it doesn't matter? It
> only needs to be atomic wrt the hypercall that requests it, so that the=

> gfn is never reused while the guest p2m still holds that mfn.
Correct.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------YpK2eUlpZN6RbIwMzuTCLyik
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------YpK2eUlpZN6RbIwMzuTCLyik--

--------------onXR0Ub3cBF4WnaNrm5ecFJg--

--------------DrPY0QcYqVlmivEVxLRIndc0
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgeSaoACgkQszaHOrMp
8lPhiw/9Fux74W4Bjg9NWiGtXGBqpe7qkeVGCXeWZ6oKghya9ag1Y7X0hdtODPdH
/FLrKUQZCgTCfCYIU8D4dJLGzdWc9rv301aq3HMswmSKOQL7cs4LuGQ5LEV8iDxX
cEh/c4meATvDjL672HhDtYAOsF/S2UR13ibubuGRbV0xmorXFwrkgu9MUrAwuQIq
9QlkF8NVKYZtDIzR2BQ+df75O5JLWZZafe80vxR4/xIkq7x9J13Ug3tCWEzf8cW8
mE+vSIXArz9oszpMPJg0MdEcqxlbX+MXLhrtyuW/P9DumSiN2veUQj846Cu3vUz+
kVocSO5eWyVO53pFMsTUXT1otF3UHHmvIeWf9mRLbQIAmEqwiPldMo+yom70NazF
AHR1O7wd5fftTl28RQP8OHR23Gt5afixW9UG1FTT7WAhkcVEuIHrhQfZUyAPV0Db
ovJibbTrXmoP3fAVlNAA9xnguPUVwrF+HdMIMbnN6ToHyCwWmcvP4ci05BMM2YVv
Rh714s+3MTvPy9FuNXk2zE6x4czZlsfki8AU2qIoy+BnKNmjNKkVkm08SVNKGLFb
UgKhXSslIRZDLAzxVye81jnfZS6tig2IZHTu3ELch6LGxi00M7vPj0yQzAmrLbIZ
7h8sXwzlUWYjXXukaOMx0e4jEmNZTLZNgMJVQQjtHo0g8Xvb3as=
=suJu
-----END PGP SIGNATURE-----

--------------DrPY0QcYqVlmivEVxLRIndc0--


From xen-devel-bounces@lists.xenproject.org Fri May 09 20:58:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 20:58:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980355.1366794 (Exim 4.92)
	(envelope-from )
	id 1uDUnK-0003Gu-8v; Fri, 09 May 2025 20:58:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980355.1366794; Fri, 09 May 2025 20:58: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 1uDUnK-0003Gn-6J; Fri, 09 May 2025 20:58:10 +0000
Received: by outflank-mailman (input) for mailman id 980355;
 Fri, 09 May 2025 20:58:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDUnJ-0003Gh-JG
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 20:58:09 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4e13a683-2d18-11f0-9eb5-5ba50f476ded;
 Fri, 09 May 2025 22:58:06 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 8C3AAA4D44C;
 Fri,  9 May 2025 20:58:05 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19196C4CEE4;
 Fri,  9 May 2025 20:58: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" 
X-Inumbo-ID: 4e13a683-2d18-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746824285;
	bh=89GvoYV+xgetI0H6k01GKNKKZHz8+LxBhTfaHALHDi8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=jTvoXFFCEuGyyjVqb4y7vs12GEpYD1NRBG+A8ISVV7MynLtuJyN/4awPCL9nS46ZX
	 mMBjJR/eBmkTeccuCVyQqfQt3lBx3sk4KJKN2c34QMpyPaDxq+NVBgYFmRb3m1D1B+
	 yBMhGks1AnSiAKLH+xNZvIvVHukZ5NUBAMrd6BxsWb8gLIR4KoATvYv5G79IrTCfiQ
	 jPwlGZTeRM0MrTfj1Ac6MgR8nh+ZAM4yWGHBs+xmNTgefDw339SixqNYN5+JKDTlKa
	 SwB4lO+i8OxEA0qHdJjSVq6C7n53+2VZFTwJ97bhjsDt9RK+TQZ4btbuIU5gqrXusJ
	 dapyEMoM2IVTQ==
Date: Fri, 9 May 2025 13:58:02 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stewart Hildebrand 
cc: xen-devel@lists.xenproject.org, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk 
Subject: Re: [PATCH v21 1/2] arm/vpci: mask off upper bits in vPCI read mmio
 handler
In-Reply-To: <20250508104608.531079-2-stewart.hildebrand@amd.com>
Message-ID: 
References: <20250508104608.531079-1-stewart.hildebrand@amd.com> <20250508104608.531079-2-stewart.hildebrand@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 8 May 2025, Stewart Hildebrand wrote:
> On Arm, we expect read handlers to have the bits above the access size
> zeroed. vPCI read handlers may return all 1s. Mask off the bits above
> the access size.
> 
> Fixes: 9a5e22b64266 ("xen/arm: check read handler behavior")
> Signed-off-by: Stewart Hildebrand 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/vpci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
> index b63a356bb4a8..3a3ff5d0812c 100644
> --- a/xen/arch/arm/vpci.c
> +++ b/xen/arch/arm/vpci.c
> @@ -37,7 +37,7 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
>      if ( vpci_ecam_read(sbdf, ECAM_REG_OFFSET(info->gpa),
>                          1U << info->dabt.size, &data) )
>      {
> -        *r = data;
> +        *r = data & invalid;
>          return 1;
>      }
>  
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Fri May 09 20:58:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 20:58:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980357.1366805 (Exim 4.92)
	(envelope-from )
	id 1uDUnc-0003aZ-Gd; Fri, 09 May 2025 20:58:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980357.1366805; Fri, 09 May 2025 20:58: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 1uDUnc-0003aS-Cy; Fri, 09 May 2025 20:58:28 +0000
Received: by outflank-mailman (input) for mailman id 980357;
 Fri, 09 May 2025 20:58:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDUnb-0003WD-9I
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 20:58:27 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 58e758b4-2d18-11f0-9ffb-bf95429c2676;
 Fri, 09 May 2025 22:58:25 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id EF5CB5C6FC1;
 Fri,  9 May 2025 20:56:05 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72EBFC4CEE4;
 Fri,  9 May 2025 20:58: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" 
X-Inumbo-ID: 58e758b4-2d18-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746824302;
	bh=u2AWSetSUJhmNlXEH4dSW8wBTn5jC6BHIXmV000zeG4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=uq8+iXX4ScflS/6+388EIRegAAde8w+ii4f6tysBLk17s1tDHuKUlC9KSgw706RMd
	 I+aC4YUBCY8KH+AAeqN/l5qVxY0LeMBcdXvKhSDkBevDaMcUFUDB9mZ+bDAV6wmumD
	 9uzbZbMKBqP/7I/4Fm8cyIdqo7rb4kIGb33QEGAPPtyu4xPuNrnKwDgNuIPedKYF0w
	 ENqXpnD4n3b1UwUFRCEe/Oaia21xI2U7pNJe+JaVvJtJ/+npaoY54WXm+vU+3tif7u
	 M8VuDjeiOAeResXkrksj1fFFR35WuUIX8AsB9/yTLfQYcfav2/ePzn1SnZqXhnRTJ+
	 nyyW+sR7EpZ+A==
Date: Fri, 9 May 2025 13:58:20 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
cc: Stewart Hildebrand , 
    xen-devel@lists.xenproject.org, 
    Oleksandr Andrushchenko , 
    Anthony PERARD , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Jiqian Chen , 
    Mykyta Poturai 
Subject: Re: [PATCH v21 2/2] vpci: translate virtual PCI bus topology for
 guests
In-Reply-To: 
Message-ID: 
References: <20250508104608.531079-1-stewart.hildebrand@amd.com> <20250508104608.531079-3-stewart.hildebrand@amd.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-287068339-1746824302=:3879245"

  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-287068339-1746824302=:3879245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Fri, 9 May 2025, Roger Pau Monné wrote:
> On Thu, May 08, 2025 at 06:46:07AM -0400, Stewart Hildebrand wrote:
> > From: Oleksandr Andrushchenko 
> > 
> > There are two originators for the PCI configuration space access:
> > 1. The domain that owns physical host bridge: MMIO handlers are
> > there so we can update vPCI register handlers with the values
> > written by the hardware domain, e.g. physical view of the registers
> > vs guest's view on the configuration space.
> > 2. Guest access to the passed through PCI devices: we need to properly
> > map virtual bus topology to the physical one, e.g. pass the configuration
> > space access to the corresponding physical devices.
> > 
> > Signed-off-by: Oleksandr Andrushchenko 
> > Signed-off-by: Volodymyr Babchuk 
> > Signed-off-by: Stewart Hildebrand 
> 
> Reviewed-by: Roger Pau Monné 
> 
> There's the addition of the ASSERTs in vpci_mmio_{read,write}() which
> could do with an ARM maintainer Ack/RB.

Acked-by: Stefano Stabellini 
--8323329-287068339-1746824302=:3879245--


From xen-devel-bounces@lists.xenproject.org Fri May 09 21:10:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 21:10:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980372.1366815 (Exim 4.92)
	(envelope-from )
	id 1uDUyy-0006SB-Fi; Fri, 09 May 2025 21:10:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980372.1366815; Fri, 09 May 2025 21:10:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDUyy-0006S4-Cv; Fri, 09 May 2025 21:10:12 +0000
Received: by outflank-mailman (input) for mailman id 980372;
 Fri, 09 May 2025 21:10:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDUyx-0006Ry-3D
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 21:10:11 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fc113438-2d19-11f0-9eb5-5ba50f476ded;
 Fri, 09 May 2025 23:10:08 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 538505C6FF6;
 Fri,  9 May 2025 21:07:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14B30C4CEE4;
 Fri,  9 May 2025 21:10: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" 
X-Inumbo-ID: fc113438-2d19-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746825006;
	bh=idsBBhAVa5QMgXWnobflcd9UeqklW0cEqyi0997GeN8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=hfYVMTfB/AietnqZOhR4vYe88hpfHZLVbcVUu8M62q5//2nhFL3kd5svFZilIBH+6
	 i3oY21+2mcfgFQhPtH+meRRcXlQ98FREghHlX4mR6ZIRkLgy+oGmsYC3Z3s0r01ZWg
	 9VDw5pVmR8njmpSo1pOVLq9hkHCBdnFSIX2n0lFYUltyi18aQMLtTB3G1DwZhTJKmj
	 l5V7duoWCMyMNti5rig9ey7XABjiXdUNfvhLebYK+oFTt6P7doxr+HK7KDVW/1VF3K
	 HSp41y0rNRm8BOydnP5XgAFhca5Xqvi2KUohzb1uR3A9pHinYxCpppwpIJbXHOy+4U
	 VHnYNSUraoAdA==
Date: Fri, 9 May 2025 14:10:03 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
cc: Stefano Stabellini , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Jan Beulich , 
    "Ragiadakou, Xenia" , 
    Andrew Cooper , jason.andryuk@amd.com, 
    agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
In-Reply-To: 
Message-ID: 
References:  <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>   
     
 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1557855939-1746824621=:3879245"
Content-ID: 

  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-1557855939-1746824621=:3879245
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Fri, 9 May 2025, Roger Pau Monné wrote:
> On Thu, May 08, 2025 at 04:25:28PM -0700, Stefano Stabellini wrote:
> > On Thu, 8 May 2025, Roger Pau Monné wrote:
> > > On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
> > > > On Tue, 6 May 2025, Roger Pau Monné wrote:
> > > > > On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
> > > > > > On Mon, 5 May 2025, Roger Pau Monné wrote:
> > > > > > > On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> > > > > > > > On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
> > > > > > > > > On Mon, 28 Apr 2025, Jan Beulich wrote:
> > > > > > > > > > On 25.04.2025 22:19, Stefano Stabellini wrote:
> > > > > > > > > > > From: Xenia Ragiadakou 
> > > > > > > > > > > 
> > > > > > > > > > > Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> > > > > > > > > > > addresses to firmware or co-processors not behind an IOMMU.
> > > > > > > > > > 
> > > > > > > > > > I definitely don't understand the firmware part: It's subject to the
> > > > > > > > > > same transparent P2M translations as the rest of the VM; it's just
> > > > > > > > > > another piece of software running there.
> > > > > > > > > > 
> > > > > > > > > > "Co-processors not behind an IOMMU" is also interesting; a more
> > > > > > > > > > concrete scenario might be nice, yet I realize you may be limited in
> > > > > > > > > > what you're allowed to say.
> > > > > > > > > 
> > > > > > > > > Sure. On AMD x86 platforms there is a co-processor called PSP running
> > > > > > > > > TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionally to
> > > > > > > > > pass addresses to it.  See drivers/tee/amdtee/ and
> > > > > > > > > include/linux/psp-tee.h in Linux.
> > > > > > > > 
> > > > > > > > We had (have?) similar issue with amdgpu (for integrated graphics) - it
> > > > > > > > uses PSP for loading its firmware. With PV dom0 there is a workaround as
> > > > > > > > dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, but I
> > > > > > > > expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's
> > > > > > > > the one I used for debugging this issue).
> > > > > > > 
> > > > > > > That's ugly, and problematic when used in conjunction with AMD-SEV.
> > > > > > > 
> > > > > > > I wonder if Xen could emulate/mediate some parts of the PSP for dom0
> > > > > > > to use, while allowing Xen to be the sole owner of the device.  Having
> > > > > > > both Xen and dom0 use it (for different purposes) seems like asking
> > > > > > > for trouble.  But I also have no idea how complex the PSP interface
> > > > > > > is, neither whether it would be feasible to emulate the
> > > > > > > interfaces/registers needed for firmware loading.
> > > > > > 
> > > > > > Let me take a step back from the PSP for a moment. I am not opposed to a
> > > > > > PSP mediator in Xen, but I want to emphasize that the issue is more
> > > > > > general and extends well beyond the PSP.
> > > > > > 
> > > > > > In my years working in embedded systems, I have consistently seen cases
> > > > > > where Dom0 needs to communicate with something that does not go through
> > > > > > the IOMMU. This could be due to special firmware on a co-processor, a
> > > > > > hardware erratum that prevents proper IOMMU usage, or a high-bandwidth
> > > > > > device that technically supports the IOMMU but performs poorly unless
> > > > > > the IOMMU is disabled. All of these are real-world examples that I have
> > > > > > seen personally.
> > > > > 
> > > > > I wouldn't be surprised, classic PV dom0 avoided those issues because
> > > > > it was dealing directly with host addresses (mfns), but that's not the
> > > > > case with PVH dom0.
> > > > 
> > > > Yeah
> > > > 
> > > > 
> > > > > > In my opinion, we definitely need a solution like this patch for Dom0
> > > > > > PVH to function correctly in all scenarios.
> > > > > 
> > > > > I'm not opposed to having such interface available for PVH hardware
> > > > > domains.  I find it ugly, but I don't see much other way to deal with
> > > > > those kind of "devices".  Xen mediating accesses for each one of them
> > > > > is unlikely to be doable.
> > > > > 
> > > > > How do you hook this exchange interface into Linux to differentiate
> > > > > which drivers need to use mfns when interacting with the hardware?
> > > > 
> > > > In the specific case we have at hands the driver is in Linux userspace
> > > > and is specially-written for our use case. It is not generic, so we
> > > > don't have this problem. But your question is valid.
> > > 
> > > Oh, so you then have some kind of ioctl interface that does the memory
> > > exchange and bouncing inside of the kernel on behalf of the user-space
> > > side I would think?
> > 
> > I am not sure... Xenia might know more than me here.
> 
> One further question I have regarding this approach: have you
> considered just populating an empty p2m space with contiguous physical
> memory instead of exchanging an existing area?  That would increase
> dom0 memory usage, but would prevent super page shattering in the p2m.
> You could use a dom0_mem=X,max:X+Y command line option, where Y
> would be your extra room for swiotlb-xen bouncing usage.
> 
> XENMEM_increase_reservation documentation notes such hypercall already
> returns the base MFN of the allocated page (see comment in
> xen_memory_reservation struct declaration).
 
XENMEM_exchange is the way it has been implemented traditionally in
Linux swiotlb-xen (it has been years). But your idea is good.

Another, more drastic, idea would be to attempt to map Dom0 PVH memory
1:1 at domain creation time like we do on ARM. If not all of it, as much
as possible. That would resolve the problem very efficiently. We could
communicate to Dom0 PVH the range that is 1:1 in one of the initial data
structures, and that would be the end of it.


> > > > In Linux, the issue is hidden behind drivers/xen/swiotlb-xen.c and
> > > > xen_arch_need_swiotlb. There are a few options:
> > > > - force swiotlb bounce for everything on the problematic SoC
> > > > - edit xen_arch_need_swiotlb to return true for the problematic device
> > > > - introduce a kernel command line option to specify which device
> > > >   xen_arch_need_swiotlb should return true for
> > > 
> > > Isn't it a bit misleading to use the swiotlb for this purpose?  Won't
> > > this usage of the swiotlb (to bounce from gfns to mfns) create issues
> > > if there's any devices that have a DMA physical address limitation and
> > > also needs to use the swiotlb while being behind the IOMMU?
> > 
> > When I wrote swiotlb, I meant swiotlb-xen (drivers/xen/swiotlb-xen.c).
> > We have been using it exactly for this kind of address translations so
> > far. It can also deal with cases where genuine bouncing needs to happen.
> 
> Oh, I see.  I've assumed you meant the generic Linux swiotlb.
> 
> So you have repurposed swiotlb-xen to be used on PVH for this purpose.
> I think (currently?) swiotlb-xen is unconditionally disabled for
> HVM/PVH guests?

Yes, I have repurposed swiotlb-xen for something similar this years ago
on ARM. I was planning to do the same for PVH x86. Today, swiotlb-xen is
used for ARM Dom0, which as you know is HVM/PVH from Linux point of view.


> > > > - introduce an ACPI table with the relevant info
> > > 
> > > Hm, best option might be an ACPI table so that Xen can signal to the
> > > hardware domain whether communication with the device must be done
> > > using mfns, or if accesses are mediated and hence can be done using
> > > gfns?
> > 
> > Yeah
> > 
> > 
> > > It's a bit cumbersome however to have to resort to an ACPI table just
> > > for this.  Not sure whether we could expand one of the existing tables
> > > already under Xen control (STAO?) to contain this information.  It all
> > > looks a bit ad-hoc.
> > > 
> > > I think we need some kind of list of devices that are not behind the
> > > IOMMU, but I have no idea what URI to use to identify those.  I assume
> > > the PSP doesn't have a PCI SBDF (as it's not on the PCI bus?).  Maybe
> > > by ACPI path?
> > 
> > Yes, we have a similar issue with the STAO table in terms of which
> > identifiers to use. STAO uses: "A list of ACPI strings, where each
> > string is the full path name in the ACPI namespace of the device"
> > 
> > 
> > > Or maybe it's fine to always communicate with those non-translated
> > > devices using MFNs, and even if we later add some kind of PSP
> > > mediation (so that both Xen and dom0 can use it), accesses by dom0
> > > will still be assumed to be using MFNs, and thus need no translation.
> > 
> > I think it is easy to enable/disable GFN/MFN for a device like PSP. We
> > can communicate to Linux in many ways this change in behavior.
> 
> In fact my biggest concern with the PSP explicitly is not so much the
> usage of MFN/GFNs, I think it would be fine for the hardware domain to
> unconditionally use MFNs for interactions with the device.
> 
> I worry how are we going to reconcile both Xen and the hardware domain
> having to use the device, as I have no idea how complex the interface
> is, so no idea how much code we would need to add to Xen to mediate a
> external domain accesses.
>
> Anyway, that's a question for later really.

Agreed
--8323329-1557855939-1746824621=:3879245--


From xen-devel-bounces@lists.xenproject.org Fri May 09 21:49:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 21:49:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980385.1366841 (Exim 4.92)
	(envelope-from )
	id 1uDVbH-0002ao-Dm; Fri, 09 May 2025 21:49:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980385.1366841; Fri, 09 May 2025 21: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 1uDVbH-0002ah-B4; Fri, 09 May 2025 21:49:47 +0000
Received: by outflank-mailman (input) for mailman id 980385;
 Fri, 09 May 2025 21:49:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDVbF-0002ab-PV
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 21:49:45 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 837951b9-2d1f-11f0-9eb5-5ba50f476ded;
 Fri, 09 May 2025 23:49:43 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 707854410B;
 Fri,  9 May 2025 21:49:41 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02004C4CEE4;
 Fri,  9 May 2025 21:49: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" 
X-Inumbo-ID: 837951b9-2d1f-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746827381;
	bh=SiJ264L76W+iNGxah+QR+bqOGeUBSZ7lji/MNG6Rk4w=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=uYAhK1H/3ajc/630iBxlSZwFpfs7YQjH28MoAy/PNXdDe5ceNI2Ycnxt1dn+GTZ7d
	 Q3lsLH2TxYfYHz+IrJ3qB14PQJo3sJspgtFfVNbI8W2CuG4oyBhBZo1LP2UragiUPj
	 05tToUJo/K4GRvFE3hrbtcl3cCcwJhJZC4jMwKYPF//w+q7XKUk9iIZy2B6/5BbqAG
	 M+Q4oMqDgbf7hrL7a1JZuLFLOXpo9VdqQytFBt5g+A+xD4/yEJFMVJhJlxUAT4iNI7
	 afH+/8ACTMWKfAKZI6z5+xaLPzbvrXLxWPccl6Lm0FzuU4aNnm+LbWIiQpfIhxEwsf
	 i5CWn2npgfs4Q==
Date: Fri, 9 May 2025 21:49:39 +0000
From: Wei Liu 
To: Juergen Gross 
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xin@zytor.com,
	"K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu , Dexuan Cui ,
	Thomas Gleixner ,
	Ingo Molnar , Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Sean Christopherson ,
	Boris Ostrovsky ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 3/6] x86/msr: minimize usage of native_*() msr access
 functions
Message-ID: 
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-4-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250506092015.1849-4-jgross@suse.com>

On Tue, May 06, 2025 at 11:20:12AM +0200, Juergen Gross wrote:
> In order to prepare for some MSR access function reorg work, switch
> most users of native_{read|write}_msr[_safe]() to the more generic
> rdmsr*()/wrmsr*() variants.
> 
> For now this will have some intermediate performance impact with
> paravirtualization configured when running on bare metal, but this
> is a prereq change for the planned direct inlining of the rdmsr/wrmsr
> instructions with this configuration.
> 
> The main reason for this switch is the planned move of the MSR trace
> function invocation from the native_*() functions to the generic
> rdmsr*()/wrmsr*() variants. Without this switch the users of the
> native_*() functions would lose the related tracing entries.
> 
> Note that the Xen related MSR access functions will not be switched,
> as these will be handled after the move of the trace hooks.
> 
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/hyperv/ivm.c      |  2 +-

Acked-by: Wei Liu 

> 
> diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c
> index 09a165a3c41e..fe177a6be581 100644
> --- a/arch/x86/hyperv/ivm.c
> +++ b/arch/x86/hyperv/ivm.c
> @@ -319,7 +319,7 @@ int hv_snp_boot_ap(u32 cpu, unsigned long start_ip)
>  	asm volatile("movl %%ds, %%eax;" : "=a" (vmsa->ds.selector));
>  	hv_populate_vmcb_seg(vmsa->ds, vmsa->gdtr.base);
>  
> -	vmsa->efer = native_read_msr(MSR_EFER);
> +	rdmsrq(MSR_EFER, vmsa->efer);
>  


From xen-devel-bounces@lists.xenproject.org Fri May 09 21:51:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 21:51:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980391.1366850 (Exim 4.92)
	(envelope-from )
	id 1uDVcv-0004AJ-OH; Fri, 09 May 2025 21:51:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980391.1366850; Fri, 09 May 2025 21:51: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 1uDVcv-0004AC-LX; Fri, 09 May 2025 21:51:29 +0000
Received: by outflank-mailman (input) for mailman id 980391;
 Fri, 09 May 2025 21:51:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDVct-0004A0-IL
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 21:51:27 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c17bd3b3-2d1f-11f0-9eb5-5ba50f476ded;
 Fri, 09 May 2025 23:51:26 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-43d2d952eb1so18553275e9.1
 for ; Fri, 09 May 2025 14:51:26 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f5a4c5f6sm4386885f8f.86.2025.05.09.14.51.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 14:51: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" 
X-Inumbo-ID: c17bd3b3-2d1f-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746827485; x=1747432285; 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;
        bh=puyW2vkhTBPYGEa87nOJrRiLle3OdvNnxy1k/upDuFI=;
        b=qO6BsFgxOjvOOyUulKUIxdPEpleYpX7lpzvLVnlCj/ZPDsUCCEORpoXS/foSMtnbjH
         okIMbvsbAyieKsxErvbKD69pHVPMsCGybkTM/FcyEzCiJhF8iyrEivnS+6LW5I9EOqbv
         IrLUa0Xn6MGgx6qwgWBxuO1PyIskahf+Fhl3E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746827485; x=1747432285;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=puyW2vkhTBPYGEa87nOJrRiLle3OdvNnxy1k/upDuFI=;
        b=HrOVPr+RpHBL5dVY9V4yn6nVBV07UEDma+Yvwdj9xhNM1grMNiP+vDCbAg6tZjSFVL
         irs5b7yZnbl+aYkyIv3iQSr36Q9Gxkr2KwelqNHbvbHGzP7e4HIvd3jWNh/+nCmXL+Af
         g8yhuXuRPgUl+heLXZGJ/9iVSveddqoSkWDgNrAerILH8onmgwyqemVUEwXL2VR4dQ4k
         KGqEMcg/OgoYPSeTx97LMcg2mUWa1di+UfE5Cdr4A99rKQ9bY8SB7OeYO3hPghXRN2G5
         5+ahsjthXYKPPrMImIdPYUUVKxv8w82n3HyG1EaheepfPrsIM+CV2vVo4uFo3C11KRrQ
         Xngg==
X-Gm-Message-State: AOJu0YzgkY1fTjswdKJCNiUkEPVCkpKXYVmlyNyLTSK8U2QUm7jnPP3Z
	k3o5otzjHz++SdmPIFKuyFqX6XPms5xwZovb+xTLVbqJMrZXKz8wejHlCid5q+k+ZWybiUIza8A
	U
X-Gm-Gg: ASbGncuh1Z9BHK5fo3eAJRu16xiD87hmVQnCzdA7FMBbKR5X/reQkdk11EzqJi+HLJ3
	wLDltmp/WdMs2rVeOLEpDxcTkEkO16CRpqm/HF02wd8ySh0ICdc5wEABsaepaiHWL4VlZkO6+Tv
	6+bn5i4Vz9lRczlRAA1rj/VhBizC3DvE1dcX7mX7ewrZyX6GNFRB65KtT283pYrz02zPefzzDx9
	ALHLh3/uht2HMDUHs64guJlWxrju/5M2c2RVon8Ckoeq8/rbpiHThOSbdE/i6wDnI8D/LoOryVR
	WusuKK9j2uIY5/ZsNludGaWmCoSrA8ZlBOfNISFVkcZdE6tA/MAxWnpHORRaPWYCtkIQ77x/UgF
	MO3IVycz1MOlAKV3Qv76kUUx1ROpoytJ8QmU=
X-Google-Smtp-Source: AGHT+IHSbScHGB5tXvZEV6VUDzOsA9Fjb7Cc9PWIahWMLacRESeyabumfm3cTQPt6cX16xV6iEVR2Q==
X-Received: by 2002:a05:600c:510b:b0:442:e03b:58a9 with SMTP id 5b1f17b1804b1-442e03b59aamr578235e9.25.1746827485492;
        Fri, 09 May 2025 14:51:25 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH TEST-ARTEFACTS] Drop legacy jobs
Date: Fri,  9 May 2025 22:51:23 +0100
Message-Id: <20250509215123.2953401-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

The CI improvements have been backported to all Xen branches.

Remove the transitionary tar/cpio parameter in scripts/alpine-rootfs.sh

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Stefano Stabellini 
CC: Marek Marczykowski-Górecki 
---
 .gitlab-ci.yml               | 27 +---------------
 scripts/alpine-rootfs.sh     | 23 ++++---------
 scripts/x86_64-argo-linux.sh | 63 ------------------------------------
 3 files changed, 8 insertions(+), 105 deletions(-)
 delete mode 100755 scripts/x86_64-argo-linux.sh

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index dcf76db6ec62..2e1aad800b95 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -52,7 +52,7 @@ linux-6.6.86-arm64:
 alpine-3.18-x86_64-rootfs:
   extends: .x86_64-artifacts
   script:
-    - ./scripts/alpine-rootfs.sh cpio
+    - ./scripts/alpine-rootfs.sh
   variables:
     CONTAINER: alpine:3.18-x86_64-base
 
@@ -67,28 +67,3 @@ linux-6.6.56-x86_64:
 microcode-x86:
   extends: .x86_64-artifacts
   script: ./scripts/x86-microcode.sh
-
-#
-# The jobs below here are legacy and being phased out.
-#
-x86_64-kernel-linux-6.6.56:
-  extends: .x86_64-artifacts
-  script: ./scripts/build-linux.sh
-  variables:
-    LINUX_VERSION: 6.6.56
-
-x86_64-rootfs-alpine-3.18:
-  extends: .x86_64-artifacts
-  script:
-    - ./scripts/alpine-rootfs.sh tar
-  variables:
-    CONTAINER: alpine:3.18-x86_64-base
-
-x86_64-argo-linux-6.6.56:
-  extends: .x86_64-artifacts
-  script:
-    - . scripts/x86_64-argo-linux.sh
-  variables:
-    LINUX_VERSION: 6.6.56
-    ARGO_SHA: "705a7a8a624b42e13e655d3042059b8a85cdf6a3"
-    ARGOEXEC_SHA: "d900429f6640acc6f68a3d3a4c945d7da60625d8"
diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
index 13d39e8846e7..c304e2ebfbd9 100755
--- a/scripts/alpine-rootfs.sh
+++ b/scripts/alpine-rootfs.sh
@@ -77,20 +77,11 @@ passwd -d "root" root
 
 # Create rootfs
 cd /
-case $1 in
-    cpio)
-        {
-            PATHS="bin etc home init lib mnt opt root sbin srv usr var"
-            find $PATHS -print0
-            echo -ne "dev\0proc\0run\0sys\0"
-        } | cpio -0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"
+{
+    PATHS="bin etc home init lib mnt opt root sbin srv usr var"
+    find $PATHS -print0
+    echo -ne "dev\0proc\0run\0sys\0"
+} | cpio -0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"
 
-        # Print the contents for the build log
-        zcat "${COPYDIR}/rootfs.cpio.gz" | cpio -tv
-        ;;
-
-    tar)
-        PATHS="bin dev etc home init lib mnt opt root sbin usr var"
-        tar cvzf "${COPYDIR}/initrd.tar.gz" $PATHS
-        ;;
-esac
+# Print the contents for the build log
+zcat "${COPYDIR}/rootfs.cpio.gz" | cpio -tv
diff --git a/scripts/x86_64-argo-linux.sh b/scripts/x86_64-argo-linux.sh
deleted file mode 100755
index a110a3378192..000000000000
--- a/scripts/x86_64-argo-linux.sh
+++ /dev/null
@@ -1,63 +0,0 @@
-#!/usr/bin/env bash
-
-if test -z "${LINUX_VERSION}"
-then
-    >&2 echo "LINUX_VERSION must be set"; exit 1
-fi
-
-set -ex -o pipefail
-
-BUILDDIR="${PWD}"
-COPYDIR="${BUILDDIR}/binaries/"
-
-# Prepare Linux sources
-curl -fsSLO \
-    https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-"${LINUX_VERSION}".tar.xz
-tar xJf linux-"${LINUX_VERSION}".tar.xz
-cd linux-"${LINUX_VERSION}"
-make ARCH=x86 defconfig
-make ARCH=x86 xen.config
-./scripts/config --enable BRIDGE
-./scripts/config --enable IGC
-./scripts/config --enable TUN
-cp .config .config.orig
-cat .config.orig \
-    | grep 'XEN' \
-    | grep '=m' \
-    | sed 's/=m/=y/g' \
-    >> .config
-make ARCH=x86 olddefconfig
-make ARCH=x86 modules_prepare
-
-# Build Linux kernel module for Xen Argo
-cd "${BUILDDIR}"
-git clone \
-    --depth=1 --branch=master \
-    https://github.com/OpenXT/linux-xen-argo.git
-git -C "${BUILDDIR}/linux-xen-argo" switch --detach "${ARGO_SHA}"
-make -C "linux-${LINUX_VERSION}" M="${BUILDDIR}/linux-xen-argo/argo-linux" \
-    CFLAGS_MODULE="-Wno-error" KBUILD_MODPOST_WARN=1
-cp "linux-xen-argo/argo-linux/xen-argo.ko" "${COPYDIR}/xen-argo.ko"
-
-# Build Linux libargo shared library, applying fixes to build in Alpine Linux
-cd "${BUILDDIR}/linux-xen-argo/libargo"
-sed -i "s|AM_INIT_AUTOMAKE|AC_CONFIG_AUX_DIR(.)\nAM_INIT_AUTOMAKE|" configure.ac
-sed -i "s/__SOCKADDR_COMMON (sxenargo_)/sa_family_t sxenargo_family/" src/libargo.h
-sed -i "s/__SOCKADDR_COMMON_SIZE/(sizeof (unsigned short int))/" src/libargo.h
-autoreconf --install
-./configure --prefix="${COPYDIR}" CPPFLAGS="-I${PWD}/../argo-linux/include"
-make
-make install
-
-# Build Linux user program, modifying for xilinx argo test
-cd "${BUILDDIR}"
-wget "https://raw.githubusercontent.com/OpenXT/xenclient-oe/${ARGOEXEC_SHA}/\
-recipes-openxt/argo-exec/argo-exec/argo-exec.c"
-sed -i "s|#include ||" argo-exec.c
-sed -i "s|ret = shuffle(s, fds\[0\], fds\[1\]);|ret = shuffle(s, 0, 1);|" \
-    argo-exec.c
-gcc -I"${BUILDDIR}/linux-xen-argo/libargo/src" \
-    -I"${BUILDDIR}/linux-xen-argo/argo-linux/include" \
-    -L"${COPYDIR}/lib/" \
-    -o argo-exec argo-exec.c -largo
-cp argo-exec "${COPYDIR}"

base-commit: 683a1f67a82e8ea151c818d74a50522ca2e67236
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri May 09 21:52:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 21:52:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980401.1366861 (Exim 4.92)
	(envelope-from )
	id 1uDVdg-0004lM-5H; Fri, 09 May 2025 21:52:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980401.1366861; Fri, 09 May 2025 21: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 1uDVdg-0004lF-1g; Fri, 09 May 2025 21:52:16 +0000
Received: by outflank-mailman (input) for mailman id 980401;
 Fri, 09 May 2025 21:52:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDVdf-0004A0-DH
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 21:52:15 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dde6cb1b-2d1f-11f0-9eb5-5ba50f476ded;
 Fri, 09 May 2025 23:52:14 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 262CC61120;
 Fri,  9 May 2025 21:52:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37DDCC4CEE4;
 Fri,  9 May 2025 21: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" 
X-Inumbo-ID: dde6cb1b-2d1f-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746827532;
	bh=4cDagZ6co7gf9XQXmHVQAuwDyhBCdZTU2fVWqGbBjVU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=shKQJaPpCpIYt5tN+oFsdnsr4mZliX7iwkSgEEcO27UFYVfutwkOL04pjQTpczykG
	 omZAstfpcBQpqsesHARupPvZEcv8lwpllUL9lU1jPuKpdgDNn9Gp+kmYwgpGEP9+Xn
	 SlObGPzcEUmBEIJ1ew3GUVWfBXRh7yLOAiTAg6jFEtw/p5aiViTIu6VLgaOsxq/kNV
	 1ZFvnDsv3RuEpQwM3OebDPc1eNSEOWfIBkwbi6gB7VW14gDyp6OZYK2tH9Akvwn7HA
	 YyLCv4J29+7kyWO24lA/p+VRGTNK/8xE5hbHpu6SkNeOMpX4DhuWHWKom5fAiDiRzQ
	 nzSkRJ2kx9PMw==
Date: Fri, 9 May 2025 14:52:10 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Volodymyr Babchuk 
cc: "xen-devel@lists.xenproject.org" , 
    Doug Goldstein , 
    Stefano Stabellini 
Subject: Re: [RFC PATCH v3 2/2] ci: enable fuzzing for arm64
In-Reply-To: <20250507095338.735228-3-volodymyr_babchuk@epam.com>
Message-ID: 
References: <20250507095338.735228-1-volodymyr_babchuk@epam.com> <20250507095338.735228-3-volodymyr_babchuk@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 7 May 2025, Volodymyr Babchuk wrote:
> Add new alpine-based build that enables LibAFL-based fuzzer.
> 
> Use this new build to run two fuzzing sessions: hypercall fuzzing and
> gicv2 fuzzing. Currently, this is all the fuzzing modes supported by
> xen fuzzer. Every fuzzing session will run approximately 10 minutes.
> 
> Fuzzing session will provide fuzzer log and any crash input data as
> artifacts. This crash data can be used later to replay the input to
> reproduce the crash.
> 
> Signed-off-by: Volodymyr Babchuk 
> 
> ---
> 
> This patch is demonstration on how xen fuzzer can be integrated in
> CI. With this setup, it can serve as smoke test, because 10 minute
> fuzzing session is not enough. While there is no strict rule on now
> long fuzzing session should run, most widely accepted time is 24
> hours. This will require additional rules (weekly tests?) and separate
> runners (probably).

Thank you, this is great as a smoke test. It serves as documentation on
how to run this too.

Yes, it could be a weekly test in the weekend or even better simply
manually triggered.

We need to investigate what is the longest time we can run this without
break Gitlab.


> Right now this patch uses docker container build by me that is hosted
> on docker hub. Of course, in the final version, this container should
> hosted together with other Xen CI containers.

Yes, agreed


> Also, that container is built based on xen-fuzzer-rs project that is
> also hosted on Xen-Troops GitHub repo, along with custom XTF
> fork. These components also should be moved to gitlab/xen.

Agreed as well


> ---
>  automation/gitlab-ci/build.yaml | 11 +++++++++++
>  automation/gitlab-ci/test.yaml  | 34 +++++++++++++++++++++++++++++++++
>  2 files changed, 45 insertions(+)
> 
> diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
> index ab5211f77e..6fc11fffe6 100644
> --- a/automation/gitlab-ci/build.yaml
> +++ b/automation/gitlab-ci/build.yaml
> @@ -407,12 +407,23 @@ alpine-3.18-gcc-arm64:
>      CONTAINER: alpine:3.18-arm64v8
>  
>  alpine-3.18-gcc-debug-arm64:
> +  extends: .gcc-arm64-build-debug
> +  variables:
> +    CONTAINER: alpine:3.18-arm64v8
> +    EXTRA_XEN_CONFIG: |
> +      CONFIG_UBSAN=y
> +      CONFIG_UBSAN_FATAL=

The diff is strange and I might be wrong, but it looks like this should
be CONFIG_UBSAN_FATAL=y


> +alpine-3.18-gcc-fuzzing-arm64:
>    extends: .gcc-arm64-build-debug
>    variables:
>      CONTAINER: alpine:3.18-arm64v8
>      EXTRA_XEN_CONFIG: |
>        CONFIG_UBSAN=y
>        CONFIG_UBSAN_FATAL=y
> +      CONFIG_FUZZING=y
> +      CONFIG_FUZZER_LIBAFL_QEMU=y
> +      CONFIG_FUZZER_PASS_BLOCKING=y
>  
>  alpine-3.18-gcc-arm64-randconfig:
>    extends: .gcc-arm64-build
> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
> index a603d4039a..bb8670026f 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -197,6 +197,30 @@
>    tags:
>      - qubes-hw11
>  
> +.fuzzer-arm:
> +  stage: test
> +  image: xentroops/xen-fuzzer:v1
> +  variables:
> +    HARNESS: hypercall
> +    FUZZING_TIME: 600
> +  rules:
> +  - if: $SELECTED_JOBS_ONLY && $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY
> +  - if: $SELECTED_JOBS_ONLY
> +    when: never
> +  - when: on_success
> +  script:
> +    - cd /root/
> +    - ./xen_fuzzer -t ${FUZZING_TIME} run ${CI_PROJECT_DIR}/binaries/xen test-mmu64le-arm-${HARNESS}-fuzzer 2>&1 | tee ${CI_PROJECT_DIR}/fuzzer-${HARNESS}.log

Can you run it from outside the directory, like this?

/root/xen_fuzzer -t ...


> +  after_script:
> +    - cd ${CI_PROJECT_DIR}
> +    - mv /root/crashes .

Also here you could probably do:

mv /root/crashes ${CI_PROJECT_DIR}


> +  artifacts:
> +    paths:
> +      - fuzzer-${HARNESS}.log
> +      - crashes/
> +  needs:
> +    - alpine-3.18-gcc-fuzzing-arm64
> +
>  # Test jobs
>  build-each-commit-gcc:
>    extends: .test-jobs-common
> @@ -704,3 +728,13 @@ qemu-smoke-ppc64le-powernv9-gcc:
>      - ./automation/scripts/qemu-smoke-ppc64le.sh powernv9 2>&1 | tee ${LOGFILE}
>    needs:
>      - debian-12-ppc64le-gcc-debug
> +
> +arm-hypercall-fuzzer:
> +  extends: .fuzzer-arm
> +  variables:
> +    HARNESS: hypercall
> +
> +arm-vgic-fuzzer:
> +  extends: .fuzzer-arm
> +  variables:
> +    HARNESS: vgic
> -- 
> 2.48.1
> 


From xen-devel-bounces@lists.xenproject.org Fri May 09 22:10:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 22:10:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980416.1366871 (Exim 4.92)
	(envelope-from )
	id 1uDVvO-0007dz-I8; Fri, 09 May 2025 22:10:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980416.1366871; Fri, 09 May 2025 22:10: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 1uDVvO-0007ds-FH; Fri, 09 May 2025 22:10:34 +0000
Received: by outflank-mailman (input) for mailman id 980416;
 Fri, 09 May 2025 22:10:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDVvN-0007dm-PW
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 22:10:33 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6b349ad0-2d22-11f0-9eb5-5ba50f476ded;
 Sat, 10 May 2025 00:10:31 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 32DAE438D9;
 Fri,  9 May 2025 22:10:29 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F9C1C4CEE4;
 Fri,  9 May 2025 22:10: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" 
X-Inumbo-ID: 6b349ad0-2d22-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746828629;
	bh=e+zIEXJWrAGkodXVb5WtJFAcpJfvauZZ0f5YxUeAGcM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=XzQfbX1Nox8QlkSbFr444aJKNOOZdMrU+0mnuyBR4KJMmQD/Ipa4JzRg4qvwdOBWg
	 bj7Cm+oiGVwuX+mB2pDDbUdeFFy3qbQGHtjHZlTu6G9ICdpMlySmBwNBH2QS2xk8+E
	 yqdafqZfjCQNxiFUYbV2nr0LIYWrAETAOqtFf7jypgTW0+w5tLCQ6WzSIyDkH+Djjn
	 DIryNVShK0ZPG+gx7LGS56y9hYmNsGhoXlMUQ8YvoiHqWDlPA0o9RxUHyEpR6+zhhX
	 OkEhehWqCEJdVIZeNQ2gCrM5pbxOO7xEeawmUvc9XCjR/Rl1QFGlRDu9LASVQn4MBc
	 mVEtzkVfY408w==
Date: Fri, 9 May 2025 15:10:26 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Xen-devel , 
    Anthony PERARD , 
    Stefano Stabellini , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH TEST-ARTEFACTS] Drop legacy jobs
In-Reply-To: <20250509215123.2953401-1-andrew.cooper3@citrix.com>
Message-ID: 
References: <20250509215123.2953401-1-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-913195864-1746828628=:3879245"

  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-913195864-1746828628=:3879245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Fri, 9 May 2025, Andrew Cooper wrote:
> The CI improvements have been backported to all Xen branches.
> 
> Remove the transitionary tar/cpio parameter in scripts/alpine-rootfs.sh
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Anthony PERARD 
> CC: Stefano Stabellini 
> CC: Marek Marczykowski-Górecki 
> ---
>  .gitlab-ci.yml               | 27 +---------------
>  scripts/alpine-rootfs.sh     | 23 ++++---------
>  scripts/x86_64-argo-linux.sh | 63 ------------------------------------
>  3 files changed, 8 insertions(+), 105 deletions(-)
>  delete mode 100755 scripts/x86_64-argo-linux.sh
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index dcf76db6ec62..2e1aad800b95 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -52,7 +52,7 @@ linux-6.6.86-arm64:
>  alpine-3.18-x86_64-rootfs:
>    extends: .x86_64-artifacts
>    script:
> -    - ./scripts/alpine-rootfs.sh cpio
> +    - ./scripts/alpine-rootfs.sh
>    variables:
>      CONTAINER: alpine:3.18-x86_64-base

There is one survivor just above:

alpine-3.18-arm64-rootfs:
  extends: .arm64-artifacts
  script:
    - ./scripts/alpine-rootfs.sh cpio
  variables:
    CONTAINER: alpine:3.18-arm64-base


Makes sense to fix it as well?

Everything else looks fine



> @@ -67,28 +67,3 @@ linux-6.6.56-x86_64:
>  microcode-x86:
>    extends: .x86_64-artifacts
>    script: ./scripts/x86-microcode.sh
> -
> -#
> -# The jobs below here are legacy and being phased out.
> -#
> -x86_64-kernel-linux-6.6.56:
> -  extends: .x86_64-artifacts
> -  script: ./scripts/build-linux.sh
> -  variables:
> -    LINUX_VERSION: 6.6.56
> -
> -x86_64-rootfs-alpine-3.18:
> -  extends: .x86_64-artifacts
> -  script:
> -    - ./scripts/alpine-rootfs.sh tar
> -  variables:
> -    CONTAINER: alpine:3.18-x86_64-base
> -
> -x86_64-argo-linux-6.6.56:
> -  extends: .x86_64-artifacts
> -  script:
> -    - . scripts/x86_64-argo-linux.sh
> -  variables:
> -    LINUX_VERSION: 6.6.56
> -    ARGO_SHA: "705a7a8a624b42e13e655d3042059b8a85cdf6a3"
> -    ARGOEXEC_SHA: "d900429f6640acc6f68a3d3a4c945d7da60625d8"
> diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
> index 13d39e8846e7..c304e2ebfbd9 100755
> --- a/scripts/alpine-rootfs.sh
> +++ b/scripts/alpine-rootfs.sh
> @@ -77,20 +77,11 @@ passwd -d "root" root
>  
>  # Create rootfs
>  cd /
> -case $1 in
> -    cpio)
> -        {
> -            PATHS="bin etc home init lib mnt opt root sbin srv usr var"
> -            find $PATHS -print0
> -            echo -ne "dev\0proc\0run\0sys\0"
> -        } | cpio -0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"
> +{
> +    PATHS="bin etc home init lib mnt opt root sbin srv usr var"
> +    find $PATHS -print0
> +    echo -ne "dev\0proc\0run\0sys\0"
> +} | cpio -0 -H newc -o | gzip > "${COPYDIR}/rootfs.cpio.gz"
>  
> -        # Print the contents for the build log
> -        zcat "${COPYDIR}/rootfs.cpio.gz" | cpio -tv
> -        ;;
> -
> -    tar)
> -        PATHS="bin dev etc home init lib mnt opt root sbin usr var"
> -        tar cvzf "${COPYDIR}/initrd.tar.gz" $PATHS
> -        ;;
> -esac
> +# Print the contents for the build log
> +zcat "${COPYDIR}/rootfs.cpio.gz" | cpio -tv
> diff --git a/scripts/x86_64-argo-linux.sh b/scripts/x86_64-argo-linux.sh
> deleted file mode 100755
> index a110a3378192..000000000000
> --- a/scripts/x86_64-argo-linux.sh
> +++ /dev/null
> @@ -1,63 +0,0 @@
> -#!/usr/bin/env bash
> -
> -if test -z "${LINUX_VERSION}"
> -then
> -    >&2 echo "LINUX_VERSION must be set"; exit 1
> -fi
> -
> -set -ex -o pipefail
> -
> -BUILDDIR="${PWD}"
> -COPYDIR="${BUILDDIR}/binaries/"
> -
> -# Prepare Linux sources
> -curl -fsSLO \
> -    https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-"${LINUX_VERSION}".tar.xz
> -tar xJf linux-"${LINUX_VERSION}".tar.xz
> -cd linux-"${LINUX_VERSION}"
> -make ARCH=x86 defconfig
> -make ARCH=x86 xen.config
> -./scripts/config --enable BRIDGE
> -./scripts/config --enable IGC
> -./scripts/config --enable TUN
> -cp .config .config.orig
> -cat .config.orig \
> -    | grep 'XEN' \
> -    | grep '=m' \
> -    | sed 's/=m/=y/g' \
> -    >> .config
> -make ARCH=x86 olddefconfig
> -make ARCH=x86 modules_prepare
> -
> -# Build Linux kernel module for Xen Argo
> -cd "${BUILDDIR}"
> -git clone \
> -    --depth=1 --branch=master \
> -    https://github.com/OpenXT/linux-xen-argo.git
> -git -C "${BUILDDIR}/linux-xen-argo" switch --detach "${ARGO_SHA}"
> -make -C "linux-${LINUX_VERSION}" M="${BUILDDIR}/linux-xen-argo/argo-linux" \
> -    CFLAGS_MODULE="-Wno-error" KBUILD_MODPOST_WARN=1
> -cp "linux-xen-argo/argo-linux/xen-argo.ko" "${COPYDIR}/xen-argo.ko"
> -
> -# Build Linux libargo shared library, applying fixes to build in Alpine Linux
> -cd "${BUILDDIR}/linux-xen-argo/libargo"
> -sed -i "s|AM_INIT_AUTOMAKE|AC_CONFIG_AUX_DIR(.)\nAM_INIT_AUTOMAKE|" configure.ac
> -sed -i "s/__SOCKADDR_COMMON (sxenargo_)/sa_family_t sxenargo_family/" src/libargo.h
> -sed -i "s/__SOCKADDR_COMMON_SIZE/(sizeof (unsigned short int))/" src/libargo.h
> -autoreconf --install
> -./configure --prefix="${COPYDIR}" CPPFLAGS="-I${PWD}/../argo-linux/include"
> -make
> -make install
> -
> -# Build Linux user program, modifying for xilinx argo test
> -cd "${BUILDDIR}"
> -wget "https://raw.githubusercontent.com/OpenXT/xenclient-oe/${ARGOEXEC_SHA}/\
> -recipes-openxt/argo-exec/argo-exec/argo-exec.c"
> -sed -i "s|#include ||" argo-exec.c
> -sed -i "s|ret = shuffle(s, fds\[0\], fds\[1\]);|ret = shuffle(s, 0, 1);|" \
> -    argo-exec.c
> -gcc -I"${BUILDDIR}/linux-xen-argo/libargo/src" \
> -    -I"${BUILDDIR}/linux-xen-argo/argo-linux/include" \
> -    -L"${COPYDIR}/lib/" \
> -    -o argo-exec argo-exec.c -largo
> -cp argo-exec "${COPYDIR}"
> 
> base-commit: 683a1f67a82e8ea151c818d74a50522ca2e67236
> -- 
> 2.39.5
> 
--8323329-913195864-1746828628=:3879245--


From xen-devel-bounces@lists.xenproject.org Fri May 09 22:12:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 22:12:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980423.1366881 (Exim 4.92)
	(envelope-from )
	id 1uDVwo-00088m-TS; Fri, 09 May 2025 22:12:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980423.1366881; Fri, 09 May 2025 22:12: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 1uDVwo-00088f-Pt; Fri, 09 May 2025 22:12:02 +0000
Received: by outflank-mailman (input) for mailman id 980423;
 Fri, 09 May 2025 22:12:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDVwn-00088W-MQ
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 22:12:01 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a157fd39-2d22-11f0-9eb5-5ba50f476ded;
 Sat, 10 May 2025 00:12:00 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43cec5cd73bso17255855e9.3
 for ; Fri, 09 May 2025 15:12:00 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f58f296csm4442452f8f.47.2025.05.09.15.11.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 15:11: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" 
X-Inumbo-ID: a157fd39-2d22-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746828720; x=1747433520; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9TPRPubuQA3V/Wf8DEBzDpVpE/QZ3qffycdvVbRaPMI=;
        b=CCF56/GN7WHR81ahwe5AqiseiXm8z0CDH9Kq1okH5ZOA+gOEzD3ZPCbXggKA2PsJaJ
         JnpwscCJYqN5XQbosSPuDkEKeC5/X6COM5UfPw4GGwdkJqNhjlWTAOCu0jzUzPsOhZgB
         CDiKXWTOOMnxzHoMcXTFtY4E2O2PG4EFQpXEc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746828720; x=1747433520;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9TPRPubuQA3V/Wf8DEBzDpVpE/QZ3qffycdvVbRaPMI=;
        b=EXr5SvFyIKZeZCdTMD7qg5wEidG3inPDzOPsm5F1YJ60HxZNnFgqMc7Z7LP/DWmN7n
         V1lBcMyW3Y84O1DJ1UG7rBajPXhlZtWA2o3litoMH3zah0PJMIdaYOM5B2/CrdqfSvD3
         d7f549Uk5Ms8bA7I+I35nXSeY7bBUoU9Z9RAJjZp/IwzPGTLug+1+BkoCC9UM1zHHXWM
         EzuxMnV/ePk6UF9n0HWZf1cK088XzAgKVO1xV27YLdGosLR5sy0yJXnuIWyIE2X6Tb0J
         0iP5MQThB2tB1P9uJ74STNe6e4R7o82KzWdC5IoIAc+8yC6ITYCtmPGSE7Vcped4wH89
         /gAg==
X-Gm-Message-State: AOJu0YzGwLe8Bc8s6dfewlzHouuZkHC+II2s54m5Pi1BEYuX7wbWAp6G
	eDyspocv6F/FEpjdMhr4Ng/3wZK4ExYZDurc1mh4nE8onUJ8Ja/n0tW8z7YxIVecUlCIZgxrzZv
	y
X-Gm-Gg: ASbGncvVfpHgcwH/lQtxBOS6V0u3Ac4Y5nypGDLWPkBdnaHkhBonME3wrD3bayxxQRO
	WQ7mh3Q0ULs/VpfwEKO32d3vdwGUdCvYzwPKwxcNY0P/AP5kVx8RjNv8DhJbHL5JDnfrbcAvcc1
	a1z2TB+DU2c7bi9pdT5hD8/xgKxSUcLD670FoKn4kj9GMUPeTb3LZPHgbM6dY9VjmXMaUPfp+ST
	PSTx9VXjoXiWYhjxOAKJ5pPhZGh5+0STlyJEHvHftqFN+aBRvowryxp99krriOSrnA/az/GpXxJ
	Zq3AcrMQYPlLXUYJQMUoQ1DSPSDH1alIJ+eru76E6zFDgaFHon0xoHBx3lnRnyZ0Y9/FeBx/Se3
	lgLuAQYyV8QYpM2l9
X-Google-Smtp-Source: AGHT+IEdysVTdqkE/2q4IZewCoNeDBcEV7CA0ThS+Mv4datWFuvrk0bh/mlbCmV2o3sNcXVYBQJVQw==
X-Received: by 2002:a05:6000:3113:b0:3a0:b308:8427 with SMTP id ffacd0b85a97d-3a1f6482d31mr4257844f8f.37.1746828720315;
        Fri, 09 May 2025 15:12:00 -0700 (PDT)
Message-ID: 
Date: Fri, 9 May 2025 23:11:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH TEST-ARTEFACTS] Drop legacy jobs
To: Stefano Stabellini 
Cc: Xen-devel ,
 Anthony PERARD ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
References: <20250509215123.2953401-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

On 09/05/2025 11:10 pm, Stefano Stabellini wrote:
> On Fri, 9 May 2025, Andrew Cooper wrote:
>> The CI improvements have been backported to all Xen branches.
>>
>> Remove the transitionary tar/cpio parameter in scripts/alpine-rootfs.sh
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Anthony PERARD 
>> CC: Stefano Stabellini 
>> CC: Marek Marczykowski-Górecki 
>> ---
>>  .gitlab-ci.yml               | 27 +---------------
>>  scripts/alpine-rootfs.sh     | 23 ++++---------
>>  scripts/x86_64-argo-linux.sh | 63 ------------------------------------
>>  3 files changed, 8 insertions(+), 105 deletions(-)
>>  delete mode 100755 scripts/x86_64-argo-linux.sh
>>
>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>> index dcf76db6ec62..2e1aad800b95 100644
>> --- a/.gitlab-ci.yml
>> +++ b/.gitlab-ci.yml
>> @@ -52,7 +52,7 @@ linux-6.6.86-arm64:
>>  alpine-3.18-x86_64-rootfs:
>>    extends: .x86_64-artifacts
>>    script:
>> -    - ./scripts/alpine-rootfs.sh cpio
>> +    - ./scripts/alpine-rootfs.sh
>>    variables:
>>      CONTAINER: alpine:3.18-x86_64-base
> There is one survivor just above:
>
> alpine-3.18-arm64-rootfs:
>   extends: .arm64-artifacts
>   script:
>     - ./scripts/alpine-rootfs.sh cpio
>   variables:
>     CONTAINER: alpine:3.18-arm64-base
>
>
> Makes sense to fix it as well?

Yeah, that wants to be dropped too.  (It happens to be a nop.)

Fixed up locally.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 09 22:15:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 22:15:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980433.1366891 (Exim 4.92)
	(envelope-from )
	id 1uDW0F-0000YO-BM; Fri, 09 May 2025 22:15:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980433.1366891; Fri, 09 May 2025 22: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 1uDW0F-0000YG-7S; Fri, 09 May 2025 22:15:35 +0000
Received: by outflank-mailman (input) for mailman id 980433;
 Fri, 09 May 2025 22:15:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDW0D-0000We-MI
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 22:15:33 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1c9a6419-2d23-11f0-9ffb-bf95429c2676;
 Sat, 10 May 2025 00:15:28 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 7A85C5C7062;
 Fri,  9 May 2025 22:13:09 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9319C4CEE4;
 Fri,  9 May 2025 22:15: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" 
X-Inumbo-ID: 1c9a6419-2d23-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746828926;
	bh=e8kb9IkMVIJV0XkJJnVYKBVSrbE3PE9bH504Cm+jTsQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=HH5xor1zG86YkbkqAxIoqGrZrqIsS4/nOZHNMUgZaHSgi1guHpMNd0mv/CCezdLwZ
	 uHcWWWeQgeS11ayx1ljxTNFjvxasvrpYHDhDTwlVDX0gMSgSlDLMaVmI+g43FDAurr
	 pHzL8Ja3H3U3pfB+OVpajVees++BwzGMDxkbT5VvoazE6UCDUnsDAnd6+pKruw3dS4
	 8E9Scj1pymGt5ZNOAyclGEgwNYXgHHtoiPv6wMIApj3Kd+GkiW2WMNKDVRByWoFT5S
	 IHjw1ssdTCbFHfNjaWNy5vL1r12OrMfH4fBz65RGrx03SypNaNnKLCWaHvL4rS+64W
	 oGoPUO+CFf7tw==
Date: Fri, 9 May 2025 15:15:24 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Stefano Stabellini , 
    Xen-devel , 
    Anthony PERARD , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH TEST-ARTEFACTS] Drop legacy jobs
In-Reply-To: 
Message-ID: 
References: <20250509215123.2953401-1-andrew.cooper3@citrix.com>  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1820674848-1746828926=:3879245"

  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-1820674848-1746828926=:3879245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Fri, 9 May 2025, Andrew Cooper wrote:
> On 09/05/2025 11:10 pm, Stefano Stabellini wrote:
> > On Fri, 9 May 2025, Andrew Cooper wrote:
> >> The CI improvements have been backported to all Xen branches.
> >>
> >> Remove the transitionary tar/cpio parameter in scripts/alpine-rootfs.sh
> >>
> >> Signed-off-by: Andrew Cooper 
> >> ---
> >> CC: Anthony PERARD 
> >> CC: Stefano Stabellini 
> >> CC: Marek Marczykowski-Górecki 
> >> ---
> >>  .gitlab-ci.yml               | 27 +---------------
> >>  scripts/alpine-rootfs.sh     | 23 ++++---------
> >>  scripts/x86_64-argo-linux.sh | 63 ------------------------------------
> >>  3 files changed, 8 insertions(+), 105 deletions(-)
> >>  delete mode 100755 scripts/x86_64-argo-linux.sh
> >>
> >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> >> index dcf76db6ec62..2e1aad800b95 100644
> >> --- a/.gitlab-ci.yml
> >> +++ b/.gitlab-ci.yml
> >> @@ -52,7 +52,7 @@ linux-6.6.86-arm64:
> >>  alpine-3.18-x86_64-rootfs:
> >>    extends: .x86_64-artifacts
> >>    script:
> >> -    - ./scripts/alpine-rootfs.sh cpio
> >> +    - ./scripts/alpine-rootfs.sh
> >>    variables:
> >>      CONTAINER: alpine:3.18-x86_64-base
> > There is one survivor just above:
> >
> > alpine-3.18-arm64-rootfs:
> >   extends: .arm64-artifacts
> >   script:
> >     - ./scripts/alpine-rootfs.sh cpio
> >   variables:
> >     CONTAINER: alpine:3.18-arm64-base
> >
> >
> > Makes sense to fix it as well?
> 
> Yeah, that wants to be dropped too.  (It happens to be a nop.)
> 
> Fixed up locally.

Reviewed-by: Stefano Stabellini 
--8323329-1820674848-1746828926=:3879245--


From xen-devel-bounces@lists.xenproject.org Fri May 09 22:16:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 22:16:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980445.1366900 (Exim 4.92)
	(envelope-from )
	id 1uDW1A-00018Y-ND; Fri, 09 May 2025 22:16:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980445.1366900; Fri, 09 May 2025 22: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 1uDW1A-00018R-Kk; Fri, 09 May 2025 22:16:32 +0000
Received: by outflank-mailman (input) for mailman id 980445;
 Fri, 09 May 2025 22:16:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDW1A-0000We-6A
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 22:16:32 +0000
Received: from mail187-10.suw11.mandrillapp.com
 (mail187-10.suw11.mandrillapp.com [198.2.187.10])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3f8c0a6a-2d23-11f0-9ffb-bf95429c2676;
 Sat, 10 May 2025 00:16:27 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-10.suw11.mandrillapp.com (Mailchimp) with ESMTP id
 4ZvNd54FJ6z5QkLg3
 for ; Fri,  9 May 2025 22:16:25 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 3226c0e946ab49dfb8d82f95890561d3; Fri, 09 May 2025 22:16: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" 
X-Inumbo-ID: 3f8c0a6a-2d23-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1746828985; x=1747098985;
	bh=OXsoqPwyut9I+YFQikpK6g6RfD5Cgj76YWmrM/Yc3gI=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=pgIEIgMBZIa7uQEilLYAxhZY6YFl9aW1MyUZGJb1rfsyNzRfLK/DIsyRlRWwaiYfe
	 XMQnZBrjCMSjw3aD74p5EUYytDmy323/0+SohfAMeujnV7nA8QDgRqtTb02hok4qN0
	 /zxbq5RNYFQnE+btpUuWk/fmMlzrL6CQjeEQbxtWMDfKwj6y2rKUI0RsMVWgNve4O3
	 ezboqig7TKV6uh1jS7mk1L2MJtea3+v49yrW3YS4SbokR1RSJGTtoD4VelycZAj5MW
	 DQozc6oSHjc4iY5z71S+y6GbRi3uIfy/QiGu9qyoJpZXZzJs3A3LuysRJ5ThgvEoMO
	 QY/lOxqXUonVg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1746828985; x=1747089485; i=teddy.astie@vates.tech;
	bh=OXsoqPwyut9I+YFQikpK6g6RfD5Cgj76YWmrM/Yc3gI=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=bvEMRYf3riY++iA5uqnoEp74RlAMv7L5w9Ekk7Klkg8EmQFblSSwZ1pbcImskLaPj
	 NTN8g9iHX1T8Y7+qVMf9CupZ/d9J9Hv0U3la+3FPVsYj+ZET/zJ+SAGik8prk/awbE
	 ZriEuFR8wcM5Ml3UspTGSpzG4+YFACBKmgbTeye90izqU3U7jL+Nbcwucur/rsi+Ga
	 dsvqDBeRlJ+jJmn2pZEOoKfDbhxgrVFPE+x3vhdI20CNn7cxtu/lOi4yl7byj4LORT
	 gzir7P/kxEQXgN0FdbOKyQLx/8hinzqoYnfWgCHni3bro6qzMFsw/Wht3gay386jOF
	 7RZW1DgbjCQpg==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH]=20xen/x86:=20allow=20Dom0=20PVH=20to=20call=20XENMEM=5Fexchange?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1746828983691
Message-Id: 
To: "Stefano Stabellini" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Cc: "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" , "Jan Beulich" , "Ragiadakou, Xenia" , "Andrew Cooper" , jason.andryuk@amd.com, agarciav@amd.com, xen-devel@lists.xenproject.org
References:  <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>          
In-Reply-To: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.3226c0e946ab49dfb8d82f95890561d3?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250509:md
Date: Fri, 09 May 2025 22:16:25 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 09/05/2025 =C3=A0 23:13, Stefano Stabellini a =C3=A9crit=C2=A0:
> On Fri, 9 May 2025, Roger Pau Monn=C3=A9 wrote:
>> On Thu, May 08, 2025 at 04:25:28PM -0700, Stefano Stabellini wrote:
>>> On Thu, 8 May 2025, Roger Pau Monn=C3=A9 wrote:
>>>> On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
>>>>> On Tue, 6 May 2025, Roger Pau Monn=C3=A9 wrote:
>>>>>> On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
>>>>>>> On Mon, 5 May 2025, Roger Pau Monn=C3=A9 wrote:
>>>>>>>> On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-G=C3=
=B3recki wrote:
>>>>>>>>> On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrot=
e:
>>>>>>>>>> On Mon, 28 Apr 2025, Jan Beulich wrote:
>>>>>>>>>>> On 25.04.2025 22:19, Stefano Stabellini wrote:
>>>>>>>>>>>> From: Xenia Ragiadakou 
>>>>>>>>>>>>
>>>>>>>>>>>> Dom0 PVH might need XENMEM_exchange when passing contiguous me=
mory
>>>>>>>>>>>> addresses to firmware or co-processors not behind an IOMMU.
>>>>>>>>>>>
>>>>>>>>>>> I definitely don't understand the firmware part: It's subject t=
o the
>>>>>>>>>>> same transparent P2M translations as the rest of the VM; it's j=
ust
>>>>>>>>>>> another piece of software running there.
>>>>>>>>>>>
>>>>>>>>>>> "Co-processors not behind an IOMMU" is also interesting; a more
>>>>>>>>>>> concrete scenario might be nice, yet I realize you may be limit=
ed in
>>>>>>>>>>> what you're allowed to say.
>>>>>>>>>>
>>>>>>>>>> Sure. On AMD x86 platforms there is a co-processor called PSP ru=
nning
>>>>>>>>>> TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasio=
nally to
>>>>>>>>>> pass addresses to it.  See drivers/tee/amdtee/ and
>>>>>>>>>> include/linux/psp-tee.h in Linux.
>>>>>>>>>
>>>>>>>>> We had (have?) similar issue with amdgpu (for integrated graphics=
) - it
>>>>>>>>> uses PSP for loading its firmware. With PV dom0 there is a workar=
ound as
>>>>>>>>> dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet=
, but I
>>>>>>>>> expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and =
it's
>>>>>>>>> the one I used for debugging this issue).
>>>>>>>>
>>>>>>>> That's ugly, and problematic when used in conjunction with AMD-SEV=
.
>>>>>>>>
>>>>>>>> I wonder if Xen could emulate/mediate some parts of the PSP for do=
m0
>>>>>>>> to use, while allowing Xen to be the sole owner of the device.  Ha=
ving
>>>>>>>> both Xen and dom0 use it (for different purposes) seems like askin=
g
>>>>>>>> for trouble.  But I also have no idea how complex the PSP interfac=
e
>>>>>>>> is, neither whether it would be feasible to emulate the
>>>>>>>> interfaces/registers needed for firmware loading.
>>>>>>>
>>>>>>> Let me take a step back from the PSP for a moment. I am not opposed=
 to a
>>>>>>> PSP mediator in Xen, but I want to emphasize that the issue is more
>>>>>>> general and extends well beyond the PSP.
>>>>>>>
>>>>>>> In my years working in embedded systems, I have consistently seen c=
ases
>>>>>>> where Dom0 needs to communicate with something that does not go thr=
ough
>>>>>>> the IOMMU. This could be due to special firmware on a co-processor,=
 a
>>>>>>> hardware erratum that prevents proper IOMMU usage, or a high-bandwi=
dth
>>>>>>> device that technically supports the IOMMU but performs poorly unle=
ss
>>>>>>> the IOMMU is disabled. All of these are real-world examples that I =
have
>>>>>>> seen personally.
>>>>>>
>>>>>> I wouldn't be surprised, classic PV dom0 avoided those issues becaus=
e
>>>>>> it was dealing directly with host addresses (mfns), but that's not t=
he
>>>>>> case with PVH dom0.
>>>>>
>>>>> Yeah
>>>>>
>>>>>
>>>>>>> In my opinion, we definitely need a solution like this patch for Do=
m0
>>>>>>> PVH to function correctly in all scenarios.
>>>>>>
>>>>>> I'm not opposed to having such interface available for PVH hardware
>>>>>> domains.  I find it ugly, but I don't see much other way to deal wit=
h
>>>>>> those kind of "devices".  Xen mediating accesses for each one of the=
m
>>>>>> is unlikely to be doable.
>>>>>>
>>>>>> How do you hook this exchange interface into Linux to differentiate
>>>>>> which drivers need to use mfns when interacting with the hardware?
>>>>>
>>>>> In the specific case we have at hands the driver is in Linux userspac=
e
>>>>> and is specially-written for our use case. It is not generic, so we
>>>>> don't have this problem. But your question is valid.
>>>>
>>>> Oh, so you then have some kind of ioctl interface that does the memory
>>>> exchange and bouncing inside of the kernel on behalf of the user-space
>>>> side I would think?
>>>
>>> I am not sure... Xenia might know more than me here.
>>
>> One further question I have regarding this approach: have you
>> considered just populating an empty p2m space with contiguous physical
>> memory instead of exchanging an existing area?  That would increase
>> dom0 memory usage, but would prevent super page shattering in the p2m.
>> You could use a dom0_mem=3DX,max:X+Y command line option, where Y
>> would be your extra room for swiotlb-xen bouncing usage.
>>
>> XENMEM_increase_reservation documentation notes such hypercall already
>> returns the base MFN of the allocated page (see comment in
>> xen_memory_reservation struct declaration).
>   
> XENMEM_exchange is the way it has been implemented traditionally in
> Linux swiotlb-xen (it has been years). But your idea is good.
> 
> Another, more drastic, idea would be to attempt to map Dom0 PVH memory
> 1:1 at domain creation time like we do on ARM. If not all of it, as much
> as possible. That would resolve the problem very efficiently. We could
> communicate to Dom0 PVH the range that is 1:1 in one of the initial data
> structures, and that would be the end of it.
> 

Could that be done by introducing a "fake" reserved region in advance 
(IVMD?) ? Such region are usually mapped to the domain 1:1 in addition 
to be coherent on the IOMMU side (so it doesn't break in case the PSP 
gets IOMMU-aware).

Teddy


 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Fri May 09 22:28:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 22:28:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980456.1366911 (Exim 4.92)
	(envelope-from )
	id 1uDWD1-0003Ac-OH; Fri, 09 May 2025 22:28:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980456.1366911; Fri, 09 May 2025 22: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 1uDWD1-0003AV-Li; Fri, 09 May 2025 22:28:47 +0000
Received: by outflank-mailman (input) for mailman id 980456;
 Fri, 09 May 2025 22:28:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDWD0-0003AP-If
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 22:28:46 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f7d5a1fc-2d24-11f0-9eb5-5ba50f476ded;
 Sat, 10 May 2025 00:28:45 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43cebe06e9eso19009125e9.3
 for ; Fri, 09 May 2025 15:28:45 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442cd32f24fsm83663935e9.16.2025.05.09.15.28.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 15: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" 
X-Inumbo-ID: f7d5a1fc-2d24-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746829724; x=1747434524; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=q6Mv2KUNJ1pEFAJxliR+wXXJ2uTuxdCYPeUE7WHu20E=;
        b=TEqzcS9vd5hfb8SjcUfPUtrORd87ljdH7kz4dc2ZdQFG/oA4oD1vHCWo7ELaUJ1NWb
         /avxvO5EVkGfCGOZTrnQNuM6yAM6sv5HNoFbW9YB9p9dZnM9Lf57VQ/+CzkoN6tFlF2M
         xUP5jmkYG6pzZ1wzHOF7VC3L8N4rz4FIAJwrw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746829724; x=1747434524;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=q6Mv2KUNJ1pEFAJxliR+wXXJ2uTuxdCYPeUE7WHu20E=;
        b=V8EXVP2oGd7iCmTlmY3+UU97156fzNlkDMS/HBXTIaWCkgkLooBc2aMowrKttwM1Ik
         cUfktS61hekK87s77A9HJdyS0lXAxhvdBc+sIErdtNUyLrEVYuc2LIw95JMJ2S92ewch
         T0deQotL5iNhSeH43cWCxBYn57ngbia6hw1LOy1YN81bQZ2jr/H6q8jN2Hk3QHAiXndy
         2Y+Z7IiIRFI7bBBGqam4rmvLQg2qkk892YKWhBdZtfpfnm2X23r3DJPFjAQPC+Z3HlZH
         Wodmy73KyJdHYm5MDsYZ8h2nvbba9tKFXWKUwXSxf3iPGvAG21DUSkg9PpvGX5Ikoize
         8Irw==
X-Gm-Message-State: AOJu0YyQuzi5vF5Me4X9hlxutmJ2gA53dSkMAUV+OxqrUcCiESTZhF0M
	F+j6baoPc7niWm1ReeCIkD+GZeHJiA+MQ0CsU5boyx6VqUDLWKHEZNHuEXCIhz8=
X-Gm-Gg: ASbGncv7hVvnHU/T7izhvrFtsda5Ha3wHlYspPL+5PB1uGUKrt0HUe7t5AS27mm6j/Z
	JMAPDxaAcCgC6ku1kukNdddiAuHJH8StHEdRgRJcZzL+kUzH1ydPGG/oj1/HfRL1cRXDQew7kB3
	S9IZIfd8f2C0y6o/zUx8AliINJFWRYf8GQiAPXMkynMAYyPmrOf/Z40EHzOOB+tb2jPlMzYiXhr
	t43MAcUoj2I6x10/6QckmJ1eQogElptFi1oo/2xLibFriGqR9t/uKJ8fYmlYD1OvtDBhtp9+v4l
	uITw0nUr42JsHugpZbCanamVrtKlz14Ur4NX7tH/Bqax9EXxe23+lTCxkFyXaVUvBile2qFEC1R
	wLsD04a/DOwfvXdfFpbXFRzLGhtw=
X-Google-Smtp-Source: AGHT+IFN3xO/KhMKZUHcxpXbrpXezOjFti6lE4V+tAC6aU7badc5rhgXG02hmj5P6BBVPRFw/p6aSg==
X-Received: by 2002:a05:600c:4e45:b0:43b:cd0d:9466 with SMTP id 5b1f17b1804b1-442d6d44b3cmr44554575e9.9.1746829724392;
        Fri, 09 May 2025 15:28:44 -0700 (PDT)
Message-ID: <863d49fc-22a2-4bf3-880d-5da331c73f8a@citrix.com>
Date: Fri, 9 May 2025 23:28:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] x86: x86_emulate: address violations of MISRA C
 Rule 19.1
To: Stefano Stabellini ,
 Victor Lira 
Cc: xen-devel@lists.xenproject.org,
 Nicola Vetrini ,
 Federico Serafini ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Bertrand Marquis 
References: <20250502233535.3532279-1-victorm.lira@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

On 06/05/2025 12:12 am, Stefano Stabellini wrote:
> On Fri, 2 May 2025, victorm.lira@amd.com wrote:
>> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
>> index 8e14ebb35b..d678855238 100644
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -527,8 +527,8 @@ static inline void put_loop_count(
>>          if ( !amd_like(ctxt) && mode_64bit() && ad_bytes == 4 )         \
>>          {                                                               \
>>              _regs.r(cx) = 0;                                            \
>> -            if ( extend_si ) _regs.r(si) = _regs.esi;                   \
>> -            if ( extend_di ) _regs.r(di) = _regs.edi;                   \
>> +            if ( extend_si ) _regs.r(si) = (uint32_t)_regs.r(si);        \
>> +            if ( extend_di ) _regs.r(di) = (uint32_t)_regs.r(di);        \
> NIT: code style, alignment of the \
>
> Can be fixed on commit.
>
> Reviewed-by: Stefano Stabellini 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Fri May 09 22:31:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 22:31:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980464.1366920 (Exim 4.92)
	(envelope-from )
	id 1uDWFn-0004uR-4O; Fri, 09 May 2025 22:31:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980464.1366920; Fri, 09 May 2025 22: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 1uDWFn-0004uK-1m; Fri, 09 May 2025 22:31:39 +0000
Received: by outflank-mailman (input) for mailman id 980464;
 Fri, 09 May 2025 22:31:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDWFm-0004u7-1K
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 22:31:38 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5d5e2015-2d25-11f0-9eb5-5ba50f476ded;
 Sat, 10 May 2025 00:31:36 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id E5F895C5CAD;
 Fri,  9 May 2025 22:29:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F2D9C4CEE4;
 Fri,  9 May 2025 22:31:31 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5d5e2015-2d25-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746829893;
	bh=0Pt9nZxXcScPcGeqUrFnklHojl2K6y2m0eP0rZcRxdI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Xf0mNRyVrMvTDI5luU471JpIY/suiK7ZwCgnK4DZJePfc0gtfNHKWjb37tgB9/pVv
	 dKYW4Qn/PeJw/IeczT0UrendbvsERiMBiZo6lu3Fey0dQqs1nHc08KFX8vLePCb+Eb
	 /YkOyLMNwgFp+hLJ10BoMGD6poFq6JHyzIxQG+nurbP1JARCQcjWnQZxj6Z2KaIC3F
	 8zE6XZ35iy6vc+RTeqUV1JZzU3KwdwCvllj08K75jxnU1E/ZnzV5ymWMY7Fykzu07C
	 8eJs1yxVH05nXVSfDqna4oG2SwzTyLjcsmbkuMYzLCD3KLFqji5QPPFRMgDzFYZKFQ
	 ca7Hc79lUJFKg==
Date: Fri, 9 May 2025 15:31:29 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Teddy Astie 
cc: Stefano Stabellini , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , 
    Jan Beulich , 
    "Ragiadakou, Xenia" , 
    Andrew Cooper , jason.andryuk@amd.com, 
    agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
In-Reply-To: 
Message-ID: 
References:  <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>   
     
   
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1480880107-1746829403=:3879245"
Content-ID: 

  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-1480880107-1746829403=:3879245
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Fri, 9 May 2025, Teddy Astie wrote:
> Le 09/05/2025 à 23:13, Stefano Stabellini a écrit :
> > On Fri, 9 May 2025, Roger Pau Monné wrote:
> >> On Thu, May 08, 2025 at 04:25:28PM -0700, Stefano Stabellini wrote:
> >>> On Thu, 8 May 2025, Roger Pau Monné wrote:
> >>>> On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
> >>>>> On Tue, 6 May 2025, Roger Pau Monné wrote:
> >>>>>> On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
> >>>>>>> On Mon, 5 May 2025, Roger Pau Monné wrote:
> >>>>>>>> On Mon, May 05, 2025 at 12:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> >>>>>>>>> On Mon, Apr 28, 2025 at 01:00:01PM -0700, Stefano Stabellini wrote:
> >>>>>>>>>> On Mon, 28 Apr 2025, Jan Beulich wrote:
> >>>>>>>>>>> On 25.04.2025 22:19, Stefano Stabellini wrote:
> >>>>>>>>>>>> From: Xenia Ragiadakou 
> >>>>>>>>>>>>
> >>>>>>>>>>>> Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> >>>>>>>>>>>> addresses to firmware or co-processors not behind an IOMMU.
> >>>>>>>>>>>
> >>>>>>>>>>> I definitely don't understand the firmware part: It's subject to the
> >>>>>>>>>>> same transparent P2M translations as the rest of the VM; it's just
> >>>>>>>>>>> another piece of software running there.
> >>>>>>>>>>>
> >>>>>>>>>>> "Co-processors not behind an IOMMU" is also interesting; a more
> >>>>>>>>>>> concrete scenario might be nice, yet I realize you may be limited in
> >>>>>>>>>>> what you're allowed to say.
> >>>>>>>>>>
> >>>>>>>>>> Sure. On AMD x86 platforms there is a co-processor called PSP running
> >>>>>>>>>> TEE firmware. The PSP is not behind an IOMMU. Dom0 needs occasionally to
> >>>>>>>>>> pass addresses to it.  See drivers/tee/amdtee/ and
> >>>>>>>>>> include/linux/psp-tee.h in Linux.
> >>>>>>>>>
> >>>>>>>>> We had (have?) similar issue with amdgpu (for integrated graphics) - it
> >>>>>>>>> uses PSP for loading its firmware. With PV dom0 there is a workaround as
> >>>>>>>>> dom0 kinda knows MFN. I haven't tried PVH dom0 on such system yet, but I
> >>>>>>>>> expect troubles (BTW, hw1 aka zen2 gitlab runner has amdgpu, and it's
> >>>>>>>>> the one I used for debugging this issue).
> >>>>>>>>
> >>>>>>>> That's ugly, and problematic when used in conjunction with AMD-SEV.
> >>>>>>>>
> >>>>>>>> I wonder if Xen could emulate/mediate some parts of the PSP for dom0
> >>>>>>>> to use, while allowing Xen to be the sole owner of the device.  Having
> >>>>>>>> both Xen and dom0 use it (for different purposes) seems like asking
> >>>>>>>> for trouble.  But I also have no idea how complex the PSP interface
> >>>>>>>> is, neither whether it would be feasible to emulate the
> >>>>>>>> interfaces/registers needed for firmware loading.
> >>>>>>>
> >>>>>>> Let me take a step back from the PSP for a moment. I am not opposed to a
> >>>>>>> PSP mediator in Xen, but I want to emphasize that the issue is more
> >>>>>>> general and extends well beyond the PSP.
> >>>>>>>
> >>>>>>> In my years working in embedded systems, I have consistently seen cases
> >>>>>>> where Dom0 needs to communicate with something that does not go through
> >>>>>>> the IOMMU. This could be due to special firmware on a co-processor, a
> >>>>>>> hardware erratum that prevents proper IOMMU usage, or a high-bandwidth
> >>>>>>> device that technically supports the IOMMU but performs poorly unless
> >>>>>>> the IOMMU is disabled. All of these are real-world examples that I have
> >>>>>>> seen personally.
> >>>>>>
> >>>>>> I wouldn't be surprised, classic PV dom0 avoided those issues because
> >>>>>> it was dealing directly with host addresses (mfns), but that's not the
> >>>>>> case with PVH dom0.
> >>>>>
> >>>>> Yeah
> >>>>>
> >>>>>
> >>>>>>> In my opinion, we definitely need a solution like this patch for Dom0
> >>>>>>> PVH to function correctly in all scenarios.
> >>>>>>
> >>>>>> I'm not opposed to having such interface available for PVH hardware
> >>>>>> domains.  I find it ugly, but I don't see much other way to deal with
> >>>>>> those kind of "devices".  Xen mediating accesses for each one of them
> >>>>>> is unlikely to be doable.
> >>>>>>
> >>>>>> How do you hook this exchange interface into Linux to differentiate
> >>>>>> which drivers need to use mfns when interacting with the hardware?
> >>>>>
> >>>>> In the specific case we have at hands the driver is in Linux userspace
> >>>>> and is specially-written for our use case. It is not generic, so we
> >>>>> don't have this problem. But your question is valid.
> >>>>
> >>>> Oh, so you then have some kind of ioctl interface that does the memory
> >>>> exchange and bouncing inside of the kernel on behalf of the user-space
> >>>> side I would think?
> >>>
> >>> I am not sure... Xenia might know more than me here.
> >>
> >> One further question I have regarding this approach: have you
> >> considered just populating an empty p2m space with contiguous physical
> >> memory instead of exchanging an existing area?  That would increase
> >> dom0 memory usage, but would prevent super page shattering in the p2m.
> >> You could use a dom0_mem=X,max:X+Y command line option, where Y
> >> would be your extra room for swiotlb-xen bouncing usage.
> >>
> >> XENMEM_increase_reservation documentation notes such hypercall already
> >> returns the base MFN of the allocated page (see comment in
> >> xen_memory_reservation struct declaration).
> >
> > XENMEM_exchange is the way it has been implemented traditionally in
> > Linux swiotlb-xen (it has been years). But your idea is good.
> >
> > Another, more drastic, idea would be to attempt to map Dom0 PVH memory
> > 1:1 at domain creation time like we do on ARM. If not all of it, as much
> > as possible. That would resolve the problem very efficiently. We could
> > communicate to Dom0 PVH the range that is 1:1 in one of the initial data
> > structures, and that would be the end of it.
> >
> 
> Could that be done by introducing a "fake" reserved region in advance
> (IVMD?) ? Such region are usually mapped to the domain 1:1 in addition
> to be coherent on the IOMMU side (so it doesn't break in case the PSP
> gets IOMMU-aware).

It doesn't have to be an "official" reserved-memory region (in the sense
of Documentation/devicetree/bindings/reserved-memory/) or exposed via
IVMD.

The memory that ends up mapped 1:1 in Dom0 PVH will be good memory which
could be used for all the regular stuff. If it is not a tiny amount, we
could let Linux (or other OS) do as they please with it.

It is only important for swiotlb-xen to know which one is the 1:1 range
so that it can manage bouncing (or not) over it.

If the 1:1 region is tiny, possibly due to memory allocation constraints
or other reasons, then yes, it makes sense to mark it as reserved
memory as you suggested, which we would do with a /reserved-memory node
if this was device tree system.
--8323329-1480880107-1746829403=:3879245--


From xen-devel-bounces@lists.xenproject.org Fri May 09 22:52:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 22:52:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980479.1366930 (Exim 4.92)
	(envelope-from )
	id 1uDWZu-0008Ag-RK; Fri, 09 May 2025 22:52:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980479.1366930; Fri, 09 May 2025 22:52: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 1uDWZu-0008AZ-Oh; Fri, 09 May 2025 22:52:26 +0000
Received: by outflank-mailman (input) for mailman id 980479;
 Fri, 09 May 2025 22:52:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDWZt-0008AT-Bt
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 22:52:25 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 42d466d4-2d28-11f0-9ffb-bf95429c2676;
 Sat, 10 May 2025 00:52:19 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 74AA8629F9;
 Fri,  9 May 2025 22:52:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 629BCC4CEE4;
 Fri,  9 May 2025 22:52: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" 
X-Inumbo-ID: 42d466d4-2d28-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746831138;
	bh=l6wl/aVoDG0TYZAH5JTusoihTfz7hbpN55vdut+Xm1g=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=L4UHUC12bf5oxaJGFiogBBvY3k3B5Q/cpAC/F8fLM0CU2Oc8vF0uQGeEz+DLkM8YF
	 TSkgeJ+PYczmcT6ZhNZSGnvZ21nSifu+CEUNv2QeHwrFOrwVBk/zFCApszKwqIF325
	 CT1yZn2JhEGXZvrgeeH1VUNwSmSxYNeUKms3sXYsSjrESjRu8wKvsB10YefcSw9MNC
	 neIdJ2u7vmYVN4GoVKwu0ASesHHvxyA7UTsRuwaZtVj3KVyh0qJFw4DSx0oJnmBLde
	 4jh29joi6m7q8oNXvb8cvTabTDo4bwf/27Mg+7xgUsw3B5gMljpQUK0oPtakR1eCh4
	 wSbTi8s1AKzhg==
Date: Fri, 9 May 2025 15:52:14 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Volodymyr Babchuk 
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 , 
    Bertrand Marquis , 
    Dario Faggioli , Juergen Gross , 
    George Dunlap 
Subject: Re: [RFC PATCH v3 1/2] xen: add libafl-qemu fuzzer support
In-Reply-To: <20250507095338.735228-2-volodymyr_babchuk@epam.com>
Message-ID: 
References: <20250507095338.735228-1-volodymyr_babchuk@epam.com> <20250507095338.735228-2-volodymyr_babchuk@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 7 May 2025, Volodymyr Babchuk wrote:
> LibAFL, which is a part of AFL++ project is a instrument that allows
> us to perform fuzzing on beremetal code (Xen hypervisor in this case)
> using QEMU as an emulator. It employs QEMU's ability to create
> snapshots to run many tests relatively quickly: system state is saved
> right before executing a new test and restored after the test is
> finished.
> 
> This patch adds all necessary plumbing to run aarch64 build of Xen
> inside that LibAFL-QEMU fuzzer. While, most of the code is in common
> section and can be used by any supported architecture, final calls to
> LibAFL-QEMU are arch-specific and were tested only on aarch64 for
> now. But LibAFL-QEMU itself supports many different architectures,
> including x86_64 and riscv.
> 
> >From the Xen perspective we need to do following things:
> 
> 1. Able to communicate with LibAFL-QEMU fuzzer. This is done by
> executing special opcodes, that only LibAFL-QEMU can handle.
> 
> 2. Use interface from p.1 to tell the fuzzer about code Xen section,
> so fuzzer know which part of code to track and gather coverage data.
> 
> 3. Report fuzzer about crash. This is done in panic() function.
> 
> 4. Prevent test harness from shooting itself in knee.
> 
> Right now test harness is an external component, because we want to
> test external Xen interfaces, but it is possible to fuzz internal code
> if we want to.
> 
> Test harness is implemented XTF-based test-case(s). As test harness
> can issue hypercall that shuts itself down, KConfig option
> CONFIG_FUZZER_PASS_BLOCKING was added. It basically tells
> fuzzer that test was completed successfully if Dom0 tries to shut
> itself (or the whole machine) down.
> 
> Signed-off-by: Volodymyr Babchuk 

The patch looks much better than before. Only a couple of very minor
comments that could be even fixed on commit. See below.

With those fixed:

Reviewed-by: Stefano Stabellini 


> ---
> 
> Changes in v3:
> 
>  - Added fuzzer.h
>  - Kconfig entries were reworked to be more generic and support
>    other fuzzers in the future
>  - Moved all the code into common area, as there is nothing
>    arch-specific in it
>  - Created arch-specific header file form ARM
>  - Removed not used definitions in libafl-qemu.h
>  - Removed not used functions from libafl-qemu.c
>  - Folded libafl-qemu-defs.h into libafl-qemu.h as we don't
>    need two separate headers
>  - Aligned code with xen coding style
>  - Added SPDX identifiers with MIT license to libafl-* files
> ---
>  docs/hypervisor-guide/fuzzing.rst      | 91 ++++++++++++++++++++++++++
>  xen/arch/arm/Kconfig.debug             | 37 +++++++++++
>  xen/arch/arm/include/asm/libafl-qemu.h | 48 ++++++++++++++
>  xen/arch/arm/psci.c                    |  5 ++
>  xen/common/Makefile                    |  1 +
>  xen/common/domain.c                    |  3 +
>  xen/common/libafl-qemu.c               | 80 ++++++++++++++++++++++
>  xen/common/sched/core.c                |  6 ++
>  xen/common/shutdown.c                  |  3 +
>  xen/drivers/char/console.c             |  3 +
>  xen/include/xen/fuzzer.h               | 52 +++++++++++++++
>  xen/include/xen/libafl-qemu.h          | 63 ++++++++++++++++++
>  12 files changed, 392 insertions(+)
>  create mode 100644 docs/hypervisor-guide/fuzzing.rst
>  create mode 100644 xen/arch/arm/include/asm/libafl-qemu.h
>  create mode 100644 xen/common/libafl-qemu.c
>  create mode 100644 xen/include/xen/fuzzer.h
>  create mode 100644 xen/include/xen/libafl-qemu.h
> 
> diff --git a/docs/hypervisor-guide/fuzzing.rst b/docs/hypervisor-guide/fuzzing.rst
> new file mode 100644
> index 0000000000..895d858edc
> --- /dev/null
> +++ b/docs/hypervisor-guide/fuzzing.rst
> @@ -0,0 +1,91 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Fuzzing
> +=======
> +
> +It is possible to use LibAFL-QEMU for fuzzing hypervisor. Right now
> +only aarch64 is supported and only hypercall fuzzing is enabled in the
> +test harness, but there are plans to add vGIC interface fuzzing, PSCI
> +fuzzing and vPL011 fuzzing as well.
> +
> +
> +Principle of operation
> +----------------------
> +
> +LibAFL-QEMU is a part of American Fuzzy lop plus plus (AKA AFL++)
> +project. It uses special build of QEMU, that allows to fuzz baremetal
> +software like Xen hypervisor or Linux kernel. Basic idea is that we
> +have software under test (Xen hypervisor in our case) and a test
> +harness application. Test harness uses special protocol to communicate
> +with LibAFL outside of QEMU to get input data and report test
> +result. LibAFL monitors which branches are taken by Xen and mutates
> +input data in attempt to discover new code paths that eventually can
> +lead to a crash or other unintended behavior.
> +
> +LibAFL uses QEMU's `snapshot` feature to run multiple test without
> +restarting the whole system every time. This speeds up fuzzing process
> +greatly.
> +
> +So, to try Xen fuzzing we need three components: LibAFL-based fuzzer,
> +test harness and Xen itself.
> +
> +Building Xen for fuzzing with LibAFL-QEMU
> +-----------------------------------------
> +
> +Xen hypervisor should be built with these three options::
> +
> +  CONFIG_FUZZING=y
> +  CONFIG_FUZZER_LIBAFL_QEMU=y
> +  CONFIG_FUZZER_PASS_BLOCKING=y
> +
> +Building LibAFL-QEMU based fuzzer
> +---------------------------------
> +
> +Fuzzer is written in Rust, so you need Rust toolchain and `cargo` tool
> +in your system. Please refer to your distro documentation on how to
> +obtain them.
> +
> +Once Rust is ready, fetch and build the fuzzer::
> +
> +  # git clone https://github.com/xen-troops/xen-fuzzer-rs
> +  # cd xen-fuzzer-rs
> +  # cargo build
> +
> +Building test harness
> +---------------------
> +
> +We need to make low-level actions, like issuing random hypercalls, so
> +for test harness we use special build of XTF (Xen Testing Framework).
> +You can build XTF manually, or let fuzzer to do this::
> +
> +  # cargo make build_xtf
> +
> +This fill download and build XTF for ARM.
> +
> +Running the fuzzer
> +------------------
> +
> +Please refer to README.md that comes with the fuzzer, but the most
> +versatile way is to run it like this::
> +
> +  # target/debug/xen_fuzzer -t 3600 /path/to/xen \
> +      target/xtf/tests/arm-vgic-fuzzer/test-mmu64le-arm-vgic-fuzzer
> +
> +(assuming that you built XTF with `cargo make build_xtf`)
> +
> +Any inputs that led to crashes will be found in `crashes` directory.
> +
> +You can replay a crash with `-r` option::
> +
> +  # target/debug/xen_fuzzer -r crashes/0195e4fc65828c17 run \
> +      /path/to/xen \
> +      /path/to/harness
> +
> +
> +Fuzzer will return non-zero error code if it encountered any crashes.
> +
> +TODOs
> +-----
> +
> + - Add x86 support.
> + - Implement fuzzing of other external hypervisor interfaces.
> diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
> index 5a03b220ac..1a51c5d221 100644
> --- a/xen/arch/arm/Kconfig.debug
> +++ b/xen/arch/arm/Kconfig.debug
> @@ -190,3 +190,40 @@ config EARLY_PRINTK_INC
>  	default "debug-mvebu.inc" if EARLY_UART_MVEBU
>  	default "debug-pl011.inc" if EARLY_UART_PL011
>  	default "debug-scif.inc" if EARLY_UART_SCIF
> +
> +config FUZZING
> +       bool "Build Xen for fuzzing"
> +       help
> +          Enable this option only if you are going to run the hypervisor
> +	  inside a fuzzer. Do not try to run run Xen built with this option
> +	  on any real hardware, because it will likely crash during boot.
> +
> +choice FUZZER
> +       depends on FUZZING
> +       prompt "Fuzzer"
> +
> +config FUZZER_LIBAFL_QEMU
> +	depends on ARM_64
> +	bool "LibAFL-QEMU"
> +	help
> +	  This option enables support for LibAFL-QEMU fuzzer. Choose this
> +	  option only when you are going to run hypervisor inside LibAFL-QEMU.
> +	  Xen will report code section to LibAFL and will report about
> +	  crash when it panics.
> +
> +endchoice
> +
> +config FUZZER_PASS_BLOCKING
> +	depends on FUZZING
> +	bool "Fuzzing: Report any attempt to suspend/destroy a domain as a success"
> +	help
> +	  When fuzzing hypercalls, a fuzzer might make Xen to do something
> +	  that prevents from returning to the caller: reboot or turn off the
> +	  machine, block calling vCPU, crash a domain, etc. Depending on
> +	  fuzzing goal this may be a valid behavior, but as control is not
> +	  returned to the fuzzing harness, it can't tell the fuzzer about
> +	  success. With this option enabled, Xen will do this by itself.
> +
> +          Enable this option only if fuzzing attempt can lead to a
> +	  correct stop, like when fuzzing hypercalls or PSCI.


We have a mix of tabs and spaces here


> diff --git a/xen/arch/arm/include/asm/libafl-qemu.h b/xen/arch/arm/include/asm/libafl-qemu.h
> new file mode 100644
> index 0000000000..9b87eafca9
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/libafl-qemu.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Arch-specific portions of LibAFL-QEMU interface
> + */
> +#ifndef __ASM_ARM_LIBAFL_QEMU_H
> +#define __ASM_ARM_LIBAFL_QEMU_H
> +
> +#define LIBAFL_DEFINE_FUNCTIONS(name, opcode)                           \
> +    libafl_word _libafl_##name##_call0(                                 \
> +        libafl_word action) {                                           \
> +        register unsigned long r0 ASM_REG(0) = action;                  \
> +        __asm__ volatile (                                              \
> +            ".word " XSTRINGIFY(opcode) "\n"                            \
> +            : "+r"(r0)                                                  \
> +            :                                                           \
> +            : "memory"                                                  \
> +            );                                                          \
> +        return r0;                                                      \
> +    }                                                                   \
> +                                                                        \
> +    libafl_word _libafl_##name##_call1(                                 \
> +        libafl_word action, libafl_word arg1) {                         \
> +        register unsigned long r0 ASM_REG(0) = action;                  \
> +        register unsigned long r1 ASM_REG(1) = arg1;                    \
> +        __asm__ volatile (                                              \
> +            ".word " XSTRINGIFY(opcode) "\n"                            \
> +            : "+r"(r0)                                                  \
> +            : "r"(r1)                                                   \
> +            : "memory"                                                  \
> +            );                                                          \
> +        return r0;                                                      \
> +    }                                                                   \
> +                                                                        \
> +    libafl_word _libafl_##name##_call2(                                 \
> +        libafl_word action, libafl_word arg1, libafl_word arg2) {       \
> +        register unsigned long r0 ASM_REG(0) = action;                  \
> +        register unsigned long r1 ASM_REG(1) = arg1;                    \
> +        register unsigned long r2 ASM_REG(2) = arg2;                    \
> +        __asm__ volatile (                                              \
> +            ".word " XSTRINGIFY(opcode) "\n"                            \
> +            : "+r"(r0)                                                  \
> +            : "r"(r1), "r"(r2)                                          \
> +            : "memory"                                                  \
> +            );                                                          \
> +        return r0;                                                      \
> +    }
> +
> +#endif
> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> index b6860a7760..43253b3f71 100644
> --- a/xen/arch/arm/psci.c
> +++ b/xen/arch/arm/psci.c
> @@ -10,6 +10,7 @@
>  
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -62,12 +63,16 @@ void call_psci_cpu_off(void)
>  
>  void call_psci_system_off(void)
>  {
> +    fuzzer_on_block();
> +
>      if ( psci_ver > PSCI_VERSION(0, 1) )
>          arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL);
>  }
>  
>  void call_psci_system_reset(void)
>  {
> +    fuzzer_on_block();
> +
>      if ( psci_ver > PSCI_VERSION(0, 1) )
>          arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL);
>  }
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 98f0873056..f2fbf54911 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -78,6 +78,7 @@ extra-y := symbols-dummy.o
>  obj-$(CONFIG_COVERAGE) += coverage/
>  obj-y += sched/
>  obj-$(CONFIG_UBSAN) += ubsan/
> +obj-$(CONFIG_FUZZER_LIBAFL_QEMU) += libafl-qemu.o
>  
>  obj-$(CONFIG_NEEDS_LIBELF) += libelf/
>  obj-$(CONFIG_LIBFDT) += libfdt/
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index abf1969e60..e63a80c26e 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -5,6 +5,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1317,6 +1318,8 @@ int domain_shutdown(struct domain *d, u8 reason)
>  
>      spin_unlock(&d->shutdown_lock);
>  
> +    fuzzer_on_block();
> +
>      return 0;
>  }
>  
> diff --git a/xen/common/libafl-qemu.c b/xen/common/libafl-qemu.c
> new file mode 100644
> index 0000000000..a09a2931c6
> --- /dev/null
> +++ b/xen/common/libafl-qemu.c
> @@ -0,0 +1,80 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> +  This file is based on libafl_qemu_impl.h, libafl_qemu_qemu_arch.h
> +  and libafl_qemu_defs.h from LibAFL project.
> +*/
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Generates sync exit functions */
> +LIBAFL_DEFINE_FUNCTIONS(sync_exit, LIBAFL_SYNC_EXIT_OPCODE)
> +
> +    void libafl_qemu_end(enum LibaflQemuEndStatus status)
> +{
> +    _libafl_sync_exit_call1(LIBAFL_QEMU_COMMAND_END, status);
> +}
> +
> +void libafl_qemu_internal_error(void)
> +{
> +    _libafl_sync_exit_call0(LIBAFL_QEMU_COMMAND_INTERNAL_ERROR);
> +}
> +
> +void lqprintf(const char *fmt, ...)
> +{
> +    static DEFINE_SPINLOCK(lock);
> +    static char buffer[LIBAFL_QEMU_PRINTF_MAX_SIZE] = {0};
> +    va_list args;
> +    int res;
> +
> +    spin_lock(&lock);
> +
> +    va_start(args, fmt);
> +    res = vsnprintf(buffer, LIBAFL_QEMU_PRINTF_MAX_SIZE, fmt, args);
> +    va_end(args);
> +
> +    if ( res >= LIBAFL_QEMU_PRINTF_MAX_SIZE )
> +    {
> +        /* buffer is not big enough, either recompile the target with more */
> +        /* space or print less things */
> +        libafl_qemu_internal_error();
> +    }
> +
> +    _libafl_sync_exit_call2(LIBAFL_QEMU_COMMAND_LQPRINTF,
> +                            (libafl_word)buffer, res);
> +    spin_unlock(&lock);
> +}
> +
> +void libafl_qemu_trace_vaddr_range(libafl_word start,
> +                                   libafl_word end)
> +{
> +    _libafl_sync_exit_call2(LIBAFL_QEMU_COMMAND_VADDR_FILTER_ALLOW, start, end);
> +}
> +
> +static int init_afl(void)
> +{
> +    vaddr_t xen_text_start = (vaddr_t)_stext;
> +    vaddr_t xen_text_end = (vaddr_t)_etext;
> +
> +    lqprintf("Telling AFL about code section: %lx - %lx\n", xen_text_start,
> +             xen_text_end);
> +
> +    libafl_qemu_trace_vaddr_range(xen_text_start, xen_text_end);
> +
> +    return 0;
> +}
> +
> +__initcall(init_afl);
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> +
> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
> index 9043414290..b109a8de44 100644
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -16,6 +16,7 @@
>  #ifndef COMPAT
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1429,6 +1430,8 @@ void vcpu_block(void)
>          TRACE_TIME(TRC_SCHED_BLOCK, v->domain->domain_id, v->vcpu_id);
>          raise_softirq(SCHEDULE_SOFTIRQ);
>      }
> +
> +    fuzzer_on_block();
>  }
>  
>  static void vcpu_block_enable_events(void)
> @@ -1502,6 +1505,8 @@ static long do_poll(const struct sched_poll *sched_poll)
>      TRACE_TIME(TRC_SCHED_BLOCK, d->domain_id, v->vcpu_id);
>      raise_softirq(SCHEDULE_SOFTIRQ);
>  
> +    fuzzer_on_block();
> +
>      return 0;
>  
>   out:
> @@ -1529,6 +1534,7 @@ long vcpu_yield(void)
>  
>      TRACE_TIME(TRC_SCHED_YIELD, current->domain->domain_id, current->vcpu_id);
>      raise_softirq(SCHEDULE_SOFTIRQ);
> +
>      return 0;
>  }

Spurious change


> diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
> index c47341b977..8e82678626 100644
> --- a/xen/common/shutdown.c
> +++ b/xen/common/shutdown.c
> @@ -1,5 +1,6 @@
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -32,6 +33,8 @@ static void noreturn reboot_or_halt(void)
>  
>  void hwdom_shutdown(unsigned char reason)
>  {
> +    fuzzer_on_block();
> +
>      switch ( reason )
>      {
>      case SHUTDOWN_poweroff:
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index c3150fbdb7..45048351d5 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1289,6 +1290,8 @@ void panic(const char *fmt, ...)
>  
>      kexec_crash(CRASHREASON_PANIC);
>  
> +    fuzzer_crash();
> +
>      if ( opt_noreboot )
>          machine_halt();
>      else
> diff --git a/xen/include/xen/fuzzer.h b/xen/include/xen/fuzzer.h
> new file mode 100644
> index 0000000000..852917fe50
> --- /dev/null
> +++ b/xen/include/xen/fuzzer.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef XEN__FUZZER_H
> +#define XEN__FUZZER_H
> +
> +#include 
> +
> +#ifdef CONFIG_FUZZER_LIBAFL_QEMU
> +#include 
> +#endif
> +
> +/* Unconditional failure */
> +static always_inline void fuzzer_crash(void)
> +{
> +#ifdef CONFIG_FUZZER_LIBAFL_QEMU
> +    libafl_qemu_end(LIBAFL_QEMU_END_CRASH);
> +#endif
> +}
> +
> +/* Unconditional success */
> +static always_inline void fuzzer_success(void)
> +{
> +#ifdef CONFIG_FUZZER_LIBAFL_QEMU
> +    libafl_qemu_end(LIBAFL_QEMU_END_OK);
> +#endif
> +}
> +
> +/*
> + * Conditional success
> + *
> + * Sometimes a fuzzer might make Xen to do something that prevents
> + * from returning to the caller: reboot or turn off the machine, block
> + * calling vCPU, crash a domain, etc. Depending on fuzzing goal this
> + * may be a valid behavior, but as control is not returned to the
> + * fuzzing harness, it can't tell the fuzzer about success, so we need
> + * to do this ourselves.
> + */
> +static always_inline void fuzzer_on_block(void)
> +{
> +#ifdef CONFIG_FUZZER_PASS_BLOCKING
> +    fuzzer_success();
> +#endif
> +}
> +
> +#endif
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/include/xen/libafl-qemu.h b/xen/include/xen/libafl-qemu.h
> new file mode 100644
> index 0000000000..f3b32adeca
> --- /dev/null
> +++ b/xen/include/xen/libafl-qemu.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: MIT */
> +#ifndef __XEN_LIBAFL_QEMU_H
> +#define __XEN_LIBAFL_QEMU_H
> +
> +#include 
> +#define LIBAFL_QEMU_PRINTF_MAX_SIZE 4096
> +
> +#define LIBAFL_STRINGIFY(s) #s
> +#define XSTRINGIFY(s) LIBAFL_STRINGIFY(s)
> +
> +#define LIBAFL_SYNC_EXIT_OPCODE 0x66f23a0f
> +
> +typedef enum LibaflQemuCommand
> +{
> +  LIBAFL_QEMU_COMMAND_START_VIRT = 0,
> +  LIBAFL_QEMU_COMMAND_START_PHYS = 1,
> +  LIBAFL_QEMU_COMMAND_INPUT_VIRT = 2,
> +  LIBAFL_QEMU_COMMAND_INPUT_PHYS = 3,
> +  LIBAFL_QEMU_COMMAND_END = 4,
> +  LIBAFL_QEMU_COMMAND_SAVE = 5,
> +  LIBAFL_QEMU_COMMAND_LOAD = 6,
> +  LIBAFL_QEMU_COMMAND_VERSION = 7,
> +  LIBAFL_QEMU_COMMAND_VADDR_FILTER_ALLOW = 8,
> +  LIBAFL_QEMU_COMMAND_INTERNAL_ERROR = 9,
> +  LIBAFL_QEMU_COMMAND_LQPRINTF = 10,
> +  LIBAFL_QEMU_COMMAND_TEST = 11,
> +} LibaflExit;
> +
> +typedef uint64_t libafl_word;
> +
> +/**
> + * LibAFL QEMU header file.
> + *
> + * This file is a portable header file used to build target harnesses more
> + * conveniently. Its main purpose is to generate ready-to-use calls to
> + * communicate with the fuzzer. The list of commands is available at the bottom
> + * of this file. The rest mostly consists of macros generating the code used by
> + * the commands.
> + */
> +
> +enum LibaflQemuEndStatus
> +{
> +  LIBAFL_QEMU_END_UNKNOWN = 0,
> +  LIBAFL_QEMU_END_OK = 1,
> +  LIBAFL_QEMU_END_CRASH = 2,
> +};
> +
> +void libafl_qemu_end(enum LibaflQemuEndStatus status);
> +
> +void libafl_qemu_internal_error(void);
> +
> +void __attribute__((format(printf, 1, 2))) lqprintf(const char *fmt, ...);
> +
> +void libafl_qemu_trace_vaddr_range(libafl_word start, libafl_word end);
> +
> +static always_inline void libafl_qemu_success_on_block(void)
> +{
> +#ifdef CONFIG_LIBAFL_QEMU_FUZZER_PASS_BLOCKING
> +    libafl_qemu_end(LIBAFL_QEMU_END_OK);
> +#endif
> +}
> +
> +#endif
> -- 
> 2.48.1
> 


From xen-devel-bounces@lists.xenproject.org Fri May 09 23:28:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 23:28:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980516.1367052 (Exim 4.92)
	(envelope-from )
	id 1uDX8a-0005Cx-Fe; Fri, 09 May 2025 23:28:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980516.1367052; Fri, 09 May 2025 23:28: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 1uDX8a-0005Cq-D6; Fri, 09 May 2025 23:28:16 +0000
Received: by outflank-mailman (input) for mailman id 980516;
 Fri, 09 May 2025 23:28:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDX8Z-0005Ci-7e
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 23:28:15 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 45c22edb-2d2d-11f0-9eb5-5ba50f476ded;
 Sat, 10 May 2025 01:28:12 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id EFF00629F5;
 Fri,  9 May 2025 23:28:10 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 254A6C4CEE4;
 Fri,  9 May 2025 23:28: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" 
X-Inumbo-ID: 45c22edb-2d2d-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746833290;
	bh=dgXlK7y214YIzcU4dKTD5XN3coMYXHMT5wpKw/OIWaw=;
	h=Date:From:To:cc:Subject:From;
	b=bKNzrn3fedWTt3IC62YzNoBmWNCYF+p6087SZ6cK4IG+GlMQO9i6D+E4jiBWrjMP0
	 JyvehB9U6VSNRq/e814LT6tZzHYKc8AXbpW7/UJgMC+B6f2sdaGtL0ozqnfAzOBx+f
	 j6hDNuqbgbvKasOIHnlA6uAB0owDkhcOr1pmHn1oOATGxN8cW7zGO4mJ96Az4Tvpnf
	 p6hg2tv89HVl1faP3Wo6VqP2hNt3mDmx2LOtKNs64OE0mzlfDzp21dYHWL6doPJ9Ad
	 iuBoN7HPHvknM/8pLScOeACQgpQoIERe9Fo4tEMzunLMng/4jJO/hu8LgZDJY6+3nq
	 RriFFx65IdtIQ==
Date: Fri, 9 May 2025 16:28:07 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: Nicola Vetrini , 
    Victor Lira , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Federico Serafini , 
    Bertrand Marquis 
Subject: [PATCH v2 1/2] xen/page_alloc: address violation of Rule 14.3
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; CHARSET=US-ASCII
Content-ID: 

From: Federico Serafini 

MISRA C Rule 14.3 states that "Controlling expressions shall not be
invariant".

Change the #define to static inline to resolve the violation.

Signed-off-by: Federico Serafini 
Signed-off-by: Victor Lira 

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index bd4538c28d..9ee1506703 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2005,7 +2005,10 @@ static unsigned long __initdata buddy_alloc_size =
     MB(CONFIG_BUDDY_ALLOCATOR_SIZE);
 size_param("buddy-alloc-size", buddy_alloc_size);
 #else
-#define domain_num_llc_colors(d) 0
+static inline unsigned int domain_num_llc_colors(const struct domain *d)
+{
+    return 0;
+}
 #define domain_llc_color(d, i)   0
 #endif
 


From xen-devel-bounces@lists.xenproject.org Fri May 09 23:38:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 23:38:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980526.1367062 (Exim 4.92)
	(envelope-from )
	id 1uDXIm-0006zI-BJ; Fri, 09 May 2025 23:38:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980526.1367062; Fri, 09 May 2025 23: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 1uDXIm-0006zB-8i; Fri, 09 May 2025 23:38:48 +0000
Received: by outflank-mailman (input) for mailman id 980526;
 Fri, 09 May 2025 23:38:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDXIk-0006z4-UZ
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 23:38:46 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bc5c07a0-2d2e-11f0-9ffb-bf95429c2676;
 Sat, 10 May 2025 01:38:40 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-43d0359b1fcso18088115e9.0
 for ; Fri, 09 May 2025 16:38:40 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442cd32f1eesm87934365e9.9.2025.05.09.16.38.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 16:38: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" 
X-Inumbo-ID: bc5c07a0-2d2e-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746833919; x=1747438719; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tfGnq1EXhocFdfUvXVBlX/+XWHR2QoNlSJ/ODH5dDRw=;
        b=MONgoIgsvbZjJRcTPEa14RBA5bLJvtnProbHTB28yt3CVUHp5+TEM751/0ReA7HZtB
         oLtErpt9wc+K29C67+PjDEmPtzslJ8DXqNKxWyiOZRmrDH1vHYhUeboTmq93nbppvadP
         s2E17wq7hOOkYFw94C/KIZ5zhq6rdpUG6FK4w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746833919; x=1747438719;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tfGnq1EXhocFdfUvXVBlX/+XWHR2QoNlSJ/ODH5dDRw=;
        b=g4khFxzr0MaCGd0gHe0D8+y+Eb4V6lYh7Uv/jqkdflDEMCosW9ZymVXsmEH7vZytVe
         DTMAVzT/T3b9U2NGr2nx4wq6bBvjAifvDYNq7VWSsnTD4qV9m7dJLctUCWdXNoVLQtZU
         EhO04xwmEGXdUuVtu5Y6UVkmVP/vWxb0StONvGcm2iZv7VYQ7kWgvozVYj0Y2g9pFj/a
         Iql04hguMNCEx3Te0qcPBz/DIfiK48TME063Q9rzgR5bKDYF3q2/8jBv105EuNt38EQf
         QSorPRBLOag+YQkLx3p+anlkZ46qvCa1+frEa38zTOgJIjrnjNDhvPw+MU5RPMnbB2nX
         9AoQ==
X-Forwarded-Encrypted: i=1; AJvYcCVps4ZRQAOH/8SzKrwhcJ1FRy00mfU+QVXc2ZhRHJ3buOxKGCNV6uLGlZiSOtofPhrZZMzmooWYaZE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxzGX72KFzuAph6z4Aq3MVqzllmLoOznSQZt/2IjJmE6uLe9Lfs
	+Czp47imv1E6Dyb+t+rEK63j9M9AZDU7zxUs6scMvg6WWL7p9UTnRugkrn1BQ7g=
X-Gm-Gg: ASbGncv+0A2z9CuQncM1mCjOvhyJZZn3XSB3YtZlajYlLlic9YUMQ+fbjFc3jO7ShnY
	E4i8iZkcnaK+BqE7iPC7oq/XVTs7FYccGrKd3cQnwfLXB+Mij7nHYG0FswQoZWe+wCdXZDnpoyR
	PwIsrXbbZytf7fP7L2ujL03MmiRrRuvYm/2suWwjzjXyiqhaWkgZk5mt030aUxVf76zaHAoYq6v
	SW5arN3hKrto0zEiucgrcAptXQu3OspGtl60bhfdTBIrXdgKwZ1/iJO0IgiNWn1ZSCkyXGrm7KZ
	M22K6Hz72TcnOpbBLTU6t6KJuHKC+zUsK0MAv1mNIv1hqV88P1eYUytSHfpP3HodCXx4dcTyaBU
	GCvmD6IuIbkbwt5Sn
X-Google-Smtp-Source: AGHT+IEae2MPb76Clvr5W2iymYTJ2TXc5olW/Q2ckKztkPuDK+9S/uDttDbkbOmUiRg8CFyQHP6Wxw==
X-Received: by 2002:a05:600c:a54:b0:43d:16a0:d98d with SMTP id 5b1f17b1804b1-442dc7a876bmr10479485e9.15.1746833919613;
        Fri, 09 May 2025 16:38:39 -0700 (PDT)
Message-ID: <8300d8e8-3f0b-4f88-913b-8970233362e4@citrix.com>
Date: Sat, 10 May 2025 00:38:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/page_alloc: address violation of Rule 14.3
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: Nicola Vetrini ,
 Victor Lira ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Federico Serafini ,
 Bertrand Marquis 
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

On 10/05/2025 12:28 am, Stefano Stabellini wrote:
> From: Federico Serafini 
>
> MISRA C Rule 14.3 states that "Controlling expressions shall not be
> invariant".
>
> Change the #define to static inline to resolve the violation.
>
> Signed-off-by: Federico Serafini 
> Signed-off-by: Victor Lira 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Fri May 09 23:46:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 09 May 2025 23:46:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980538.1367073 (Exim 4.92)
	(envelope-from )
	id 1uDXQH-0000Le-5J; Fri, 09 May 2025 23:46:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980538.1367073; Fri, 09 May 2025 23: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 1uDXQH-0000LX-1w; Fri, 09 May 2025 23:46:33 +0000
Received: by outflank-mailman (input) for mailman id 980538;
 Fri, 09 May 2025 23:46:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDXQF-0000LR-Qy
 for xen-devel@lists.xenproject.org; Fri, 09 May 2025 23:46:31 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d4fef3b3-2d2f-11f0-9eb5-5ba50f476ded;
 Sat, 10 May 2025 01:46:31 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43ce70f9afbso27539065e9.0
 for ; Fri, 09 May 2025 16:46:31 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442cd3b7e7fsm86866955e9.39.2025.05.09.16.46.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 09 May 2025 16: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" 
X-Inumbo-ID: d4fef3b3-2d2f-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746834390; x=1747439190; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AzTEoxE9eD7tVfQPW14WwTZ0Djka5W2LriqmxdoQyfg=;
        b=SqSD4FITkaXHxZ2+WF+Av1rJjMCn2mXM9EEPmkEW/u4CNtORLEhsTdrFzr07PWboWU
         4SX0vcWeT3F1IXceaPE9h2u4SByNcsK+HfTFRLNsGW66kp/5Y+seVqcQg5M/OphWv4/a
         6A91UY2XNHxMRsm2gUQLuu0QjqIGkUGyDKtt4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746834390; x=1747439190;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AzTEoxE9eD7tVfQPW14WwTZ0Djka5W2LriqmxdoQyfg=;
        b=Cy9mVqU+OWfQZ8+8chNM0NNJSbtIoWiLNdqjTpkrV26XGyJx09YkAn4HuFOaDEIrkh
         iNgjkAYuIZBryjMFYWtYOzVBYudh0ltzORZxjDuu/QhZWuHp4HkqLVsCAc5wvVpMh5QD
         H4xhb3pvu/6DRN88MFWc74wJN+KFnmUliDtIYyJaeqp0ugJHVC/lw0XsZ5gkEG1uaPaL
         qf+ZJywS/vHSGNTTDecbvLTVbF071HRSJgMECs8zmnhWWfuOVtkOxVb2Z0nzEGszbmIr
         VrjsNtvXhWbkZYKdIzJwuxSlEVohx05nn7pQYOzhr4V5ehdK+2buwoivVV8DKW7g0ZNG
         tNpA==
X-Forwarded-Encrypted: i=1; AJvYcCUFTquaXDkeweYX7o7Zftwo6HgQWejGI8GWSgpPLl9zt0hjobytRdRS3TN9gOIStVuq3PvVwdzxTCE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YziqSb4aSCcZKf5QIqQRgGu1y/lkFp4c5sy0wT3gGzPmgte6KCp
	hciyUauKoaxok68Od8s+k0OiX7j0mJteWNN4NNRN2h/EvS38k7qNv4Pd+v/AQpk=
X-Gm-Gg: ASbGncuwXabEOwvCqK6Jl/DtI0uLxXlJ+uxUBeHu25n+4WeiKFXnJuKDTCiB45rc0V6
	cplG7Wsez8wEQv+tp/3cjPpT3V2/TD7TwzJU/FN0ED1Da4EugKvSMKMGl7LKjAlt9XSpBtqi10i
	lomMMMgDFKY+Z+1wr7hwrdiNCq783Jh1MAI4o/Qck/g4GwBhatVJHEFxRWOocIhPPcRH0eNq+vk
	OMa00pVyms8EMsWLD9YSWo/6u2DTwyLBMolNG5k6Q60T7SWG4I6AvODOOSvUv1D1bcUfADsJyUQ
	xy0z0k5ufYFxYvrrjyRitjHx5MsZ/lxbTygPAOm7a7eaNF1RVw1o3nuuFPC0/NNZ/qhFlX8i9bW
	v7RBOjwhPQ8HXlbVE8tZumdukUGI=
X-Google-Smtp-Source: AGHT+IGwM6KhKJEJ1+Tt7faTOPl6uXUm9FjGeX2Dpg3CwrlFV8sfdAxRYP9iV6wEuaUwt+ESzWy6Jw==
X-Received: by 2002:a05:600c:6487:b0:43c:e70d:44f0 with SMTP id 5b1f17b1804b1-442d6d516efmr48458015e9.19.1746834390394;
        Fri, 09 May 2025 16:46:30 -0700 (PDT)
Message-ID: <82b13a72-5b14-4e3c-ad98-fff1e13308ab@citrix.com>
Date: Sat, 10 May 2025 00:46:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/2] x86: x86_emulate: address violation of MISRA C
 Rule 13.2
To: victorm.lira@amd.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini 
Cc: Nicola Vetrini ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Federico Serafini ,
 Bertrand Marquis 
References: <77f9c4cabe607ce4024013c604bc790fb629d322.1746657135.git.victorm.lira@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: <77f9c4cabe607ce4024013c604bc790fb629d322.1746657135.git.victorm.lira@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07/05/2025 11:46 pm, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
>
> Rule 13.2 states: "The value of an expression and its persistent
> side effects shall be the same under all permitted evaluation orders".
>
> The full expansion of macro "commit_far_branch" contains an assignment to
> variable "rc", which is also assigned to the result of the GNU statement
> expression which "commit_far_branch" expands to.
>
> To avoid any dependence on the order of evaluation, the latter assignment
> is moved inside the macro.

The (mostly expanded) and reformatted expression is:

> if ( (rc = load_seg(x86_seg_cs, src.val, 1, &cs, ctxt, ops)) ||
>      (rc = ({
>              ({
>                  if ( sizeof(dst.val) <= 4 )
>                  {
>                      do {
>                          if ( __builtin_expect(!!(!(!ctxt->lma)),0) )
>                              ASSERT();
>                      } while ( 0 );
>                      ({
>                          if ( ((dst.val) > (&cs)->limit) )
>                          {
>                              x86_emul_hw_exception(13, mkec(13, 0, 0), ctxt);
>                              rc = 2;
>                              goto done;
>                          }
>                      });
>                  }
>                  else
>                      ({
>                          if ( (ctxt->lma && (&cs)->l
>                                ? !(((long)(dst.val) >> 47) == ((long)(dst.val) >> 63))
>                                : (dst.val) > (&cs)->limit) )
>                          {
>                              x86_emul_hw_exception(13, mkec(13, 0, 0), ctxt);
>                              rc = 2;
>                              goto done;
>                          }
>                      });
>              });
>              _regs.rip = (dst.val);
>              singlestep = _regs.eflags & 0x00000100;
>              ops->write_segment(x86_seg_cs, &cs, ctxt);
>          })) )

And I can't identify anywhere where there is an ambiguous order of
evaluation.

The problem with this patch is that, while the existing logic is not
exactly great, ...

> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
> index 8e14ebb35b..7108fe7b30 100644
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -337,7 +337,7 @@ do {                                                                    \
>      validate_far_branch(cs, newip);                                     \
>      _regs.r(ip) = (newip);                                              \
>      singlestep = _regs.eflags & X86_EFLAGS_TF;                          \
> -    ops->write_segment(x86_seg_cs, cs, ctxt);                           \
> +    rc = ops->write_segment(x86_seg_cs, cs, ctxt);                      \
>  })
>
>  int x86emul_get_fpu(
> @@ -2382,7 +2382,7 @@ x86_emulate(
>               (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + src.val),
>                                &src.val, op_bytes, ctxt, ops)) ||
>               (rc = load_seg(x86_seg_cs, src.val, 1, &cs, ctxt, ops)) ||
> -             (rc = commit_far_branch(&cs, dst.val)) )
> +             commit_far_branch(&cs, dst.val) )
>              goto done;

... this is breaking a visual layout pattern where you can always see
the update to rc beside the "goto done".

This code is complicated enough without making it harder.

One option which might work is this:

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 3350303f8634..dab4373ece1e 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -333,12 +333,14 @@ do
{                                                                    \
                               : (ip) > (cs)->limit, X86_EXC_GP, 0);     \
 })
 
-#define commit_far_branch(cs, newip) ({                                 \
-    validate_far_branch(cs, newip);                                     \
-    _regs.r(ip) = (newip);                                              \
-    singlestep = _regs.eflags & X86_EFLAGS_TF;                          \
-    ops->write_segment(x86_seg_cs, cs, ctxt);                           \
-})
+#define commit_far_branch(cs, newip) (                                  \
+        ({                                                              \
+            validate_far_branch(cs, newip);                             \
+            _regs.r(ip) = (newip);                                      \
+            singlestep = _regs.eflags & X86_EFLAGS_TF;                  \
+        }),                                                             \
+        ops->write_segment(x86_seg_cs, cs, ctxt)                        \
+    )
 
 int x86emul_get_fpu(
     enum x86_emulate_fpu_type type,


This rearranges commit_far_branch() to use the comma operator, but
maintains the previous property that it's still overall an assignment to rc.

However, I don't have much confidence that Eclair is going to like it more.

~Andrew


From xen-devel-bounces@lists.xenproject.org Sat May 10 00:03:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 May 2025 00:03:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980547.1367083 (Exim 4.92)
	(envelope-from )
	id 1uDXgX-0003wo-B8; Sat, 10 May 2025 00:03:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980547.1367083; Sat, 10 May 2025 00:03: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 1uDXgX-0003wh-84; Sat, 10 May 2025 00:03:21 +0000
Received: by outflank-mailman (input) for mailman id 980547;
 Sat, 10 May 2025 00:03:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDXgV-0003wb-PV
 for xen-devel@lists.xenproject.org; Sat, 10 May 2025 00:03:19 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2ba27880-2d32-11f0-9eb5-5ba50f476ded;
 Sat, 10 May 2025 02:03:17 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 25FD55C5434;
 Sat, 10 May 2025 00:00:57 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85BDDC4CEED;
 Sat, 10 May 2025 00:03: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" 
X-Inumbo-ID: 2ba27880-2d32-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746835394;
	bh=apxLBoPSgiWknjoB+6ASLhkhAwSY/vTIVv34g3VfLRA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=jPZ9k3/3Klnj5wliuifJfU4TjvGT7HLY7qoPfyNTOPmAkKYYmGPSskBG8nFnZdI8v
	 /4mNSvkQBsTvDe8ipvsXu3/fSX9sTAZeUusGB6yqr3JnvwIYtKjs7ARth3BngkOO/X
	 7ly+TZHntFuPG79lUGuxwKRj8JQ/k7n6gfhlCiRtf60oCBfFEh+7z6lYNZo3e4+KBV
	 2EEl/LpmgnmzCAN6YM1DthANXAq1kFdOwOADmd2vbiNAbU4/Jo2mjM5FFSVaCDmJRu
	 yXOYrFEnvDu51Mco5SAIdQJzzBl2hUnhv/LGLpm0FiMBXcXgw1cyls9Yo4+WN6rqQC
	 37RkJCGd3mW9Q==
Date: Fri, 9 May 2025 17:03:11 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: victorm.lira@amd.com, xen-devel@lists.xenproject.org, 
    Stefano Stabellini , 
    Nicola Vetrini , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Federico Serafini , 
    Bertrand Marquis 
Subject: Re: [PATCH v1 1/2] x86: x86_emulate: address violation of MISRA C
 Rule 13.2
In-Reply-To: <82b13a72-5b14-4e3c-ad98-fff1e13308ab@citrix.com>
Message-ID: 
References: <77f9c4cabe607ce4024013c604bc790fb629d322.1746657135.git.victorm.lira@amd.com> <82b13a72-5b14-4e3c-ad98-fff1e13308ab@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-251233205-1746835393=:3879245"

  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-251233205-1746835393=:3879245
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Sat, 10 May 2025, Andrew Cooper wrote:
> On 07/05/2025 11:46 pm, victorm.lira@amd.com wrote:
> > From: Nicola Vetrini 
> >
> > Rule 13.2 states: "The value of an expression and its persistent
> > side effects shall be the same under all permitted evaluation orders".
> >
> > The full expansion of macro "commit_far_branch" contains an assignment to
> > variable "rc", which is also assigned to the result of the GNU statement
> > expression which "commit_far_branch" expands to.
> >
> > To avoid any dependence on the order of evaluation, the latter assignment
> > is moved inside the macro.
> 
> The (mostly expanded) and reformatted expression is:
> 
> > if ( (rc = load_seg(x86_seg_cs, src.val, 1, &cs, ctxt, ops)) ||
> >      (rc = ({
> >              ({
> >                  if ( sizeof(dst.val) <= 4 )
> >                  {
> >                      do {
> >                          if ( __builtin_expect(!!(!(!ctxt->lma)),0) )
> >                              ASSERT();
> >                      } while ( 0 );
> >                      ({
> >                          if ( ((dst.val) > (&cs)->limit) )
> >                          {
> >                              x86_emul_hw_exception(13, mkec(13, 0, 0), ctxt);
> >                              rc = 2;
> >                              goto done;
> >                          }
> >                      });
> >                  }
> >                  else
> >                      ({
> >                          if ( (ctxt->lma && (&cs)->l
> >                                ? !(((long)(dst.val) >> 47) == ((long)(dst.val) >> 63))
> >                                : (dst.val) > (&cs)->limit) )
> >                          {
> >                              x86_emul_hw_exception(13, mkec(13, 0, 0), ctxt);
> >                              rc = 2;
> >                              goto done;
> >                          }
> >                      });
> >              });
> >              _regs.rip = (dst.val);
> >              singlestep = _regs.eflags & 0x00000100;
> >              ops->write_segment(x86_seg_cs, &cs, ctxt);
> >          })) )
> 
> And I can't identify anywhere where there is an ambiguous order of
> evaluation.
> 
> The problem with this patch is that, while the existing logic is not
> exactly great, ...
> 
> > diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
> > index 8e14ebb35b..7108fe7b30 100644
> > --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> > @@ -337,7 +337,7 @@ do {                                                                    \
> >      validate_far_branch(cs, newip);                                     \
> >      _regs.r(ip) = (newip);                                              \
> >      singlestep = _regs.eflags & X86_EFLAGS_TF;                          \
> > -    ops->write_segment(x86_seg_cs, cs, ctxt);                           \
> > +    rc = ops->write_segment(x86_seg_cs, cs, ctxt);                      \
> >  })
> >
> >  int x86emul_get_fpu(
> > @@ -2382,7 +2382,7 @@ x86_emulate(
> >               (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + src.val),
> >                                &src.val, op_bytes, ctxt, ops)) ||
> >               (rc = load_seg(x86_seg_cs, src.val, 1, &cs, ctxt, ops)) ||
> > -             (rc = commit_far_branch(&cs, dst.val)) )
> > +             commit_far_branch(&cs, dst.val) )
> >              goto done;
> 
> ... this is breaking a visual layout pattern where you can always see
> the update to rc beside the "goto done".
> 
> This code is complicated enough without making it harder.
> 
> One option which might work is this:
> 
> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
> b/xen/arch/x86/x86_emulate/x86_emulate.c
> index 3350303f8634..dab4373ece1e 100644
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -333,12 +333,14 @@ do
> {                                                                    \
>                                : (ip) > (cs)->limit, X86_EXC_GP, 0);     \
>  })
>  
> -#define commit_far_branch(cs, newip) ({                                 \
> -    validate_far_branch(cs, newip);                                     \
> -    _regs.r(ip) = (newip);                                              \
> -    singlestep = _regs.eflags & X86_EFLAGS_TF;                          \
> -    ops->write_segment(x86_seg_cs, cs, ctxt);                           \
> -})
> +#define commit_far_branch(cs, newip) (                                  \
> +        ({                                                              \
> +            validate_far_branch(cs, newip);                             \
> +            _regs.r(ip) = (newip);                                      \
> +            singlestep = _regs.eflags & X86_EFLAGS_TF;                  \
> +        }),                                                             \
> +        ops->write_segment(x86_seg_cs, cs, ctxt)                        \
> +    )
>  
>  int x86emul_get_fpu(
>      enum x86_emulate_fpu_type type,
> 
> 
> This rearranges commit_far_branch() to use the comma operator, but
> maintains the previous property that it's still overall an assignment to rc.
> 
> However, I don't have much confidence that Eclair is going to like it more.

Eclair likes it:

Reviewed-by: Stefano Stabellini 
--8323329-251233205-1746835393=:3879245--


From xen-devel-bounces@lists.xenproject.org Sat May 10 00:19:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 May 2025 00:19:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980556.1367092 (Exim 4.92)
	(envelope-from )
	id 1uDXvb-0005ih-Hz; Sat, 10 May 2025 00:18:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980556.1367092; Sat, 10 May 2025 00:18:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDXvb-0005ia-FM; Sat, 10 May 2025 00:18:55 +0000
Received: by outflank-mailman (input) for mailman id 980556;
 Sat, 10 May 2025 00:18:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDXva-0005iU-Dp
 for xen-devel@lists.xenproject.org; Sat, 10 May 2025 00:18:54 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5a68d50f-2d34-11f0-9eb5-5ba50f476ded;
 Sat, 10 May 2025 02:18:52 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a1d8c0966fso1331966f8f.1
 for ; Fri, 09 May 2025 17:18:52 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f58f33b5sm4815178f8f.54.2025.05.09.17.18.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 May 2025 17:18: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" 
X-Inumbo-ID: 5a68d50f-2d34-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746836332; x=1747441132; 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;
        bh=WpsUSj92KqDrKgsNySV/kwZnYdiagcD3GXuPXffrzeA=;
        b=UiufKp+DdsTKa+VGCp2iBAPr79VzQ7gHAnzRKtaAGiezwWAq0oAUK4OjQYD4yTAyHJ
         z/IQJSmXtrORDhVPL70JVaWobcDMkiqQRGh1QK340RDgm/uPTPBcG+ivyOSr3a1dex31
         5G/+116P+H9EscLyseWux8Qm3j7FqdBdF0wtY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746836332; x=1747441132;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=WpsUSj92KqDrKgsNySV/kwZnYdiagcD3GXuPXffrzeA=;
        b=pXZ/iNzOJn4NvAvmJOkt4k/MCQ92MGxlduAczJYG+QgB9wiphzvJX370r+KgqLECCS
         8DyXRuvDPtkZsfAL0YPF7LJ1cD8uSrpqnj+0RcUgNoMYWZaDcIesiXkfhuwzDWUpBZwV
         GwUb8MIAcgHbHroqZYh1wjqCw7dYkkPdTg/NECMk13gR7E57G7bPujfUgHplRNIOkitr
         xOJ0nB0q3qxJ2UQEY01TuOSvE9P7RO0RjrK5xAaWKj/RzNXMqRxXbU/twfdZqumyCNOa
         10AbyETL8BWsyH82k/LlVXW7NoZqKd6mtEyhowkor3/nK87dLrSQJfOpS2lM8sEQad0k
         n2SQ==
X-Gm-Message-State: AOJu0YzSAyHOnGNqjRVF06MwA8Twb2Wp0ZQe1PN6u86NqB7914Nz8Jyw
	qZSXxTEUQS12rqNf2kE0CF9SbFY315IVUv0HQXIqpB0UmwzHSIoqoJmNFn1Pl/64FYsNkI/Yfnf
	S
X-Gm-Gg: ASbGncvmV+iuM0QLp693+nDnZpxfxDAxLBE4LQuL+Srwu8kec7dytT+qz67GvXcW+u5
	q6IYl4GLrrVyDaREm/a5HTyJ+htczthL5op78QuGitm1O3NLPkrlEnjbyX8FUSQxylaxz+7bAog
	TznmY40wun8a6ebxUHL+IKMp7ameO/OLWQaeWN2FMkxeJrUnWohTtLuhw+TPDMS5bBA43EYDXyc
	Q4A0JpRGi2c9zLthfpWstdF7F5/WpkAeaZ5qO+/bTtZAyBb0irXhl0wrtjMCOpB+TbV5zfGwUuL
	sCh0XJCazrR7f7akO8omYMsIxblONK46q61g8yOuLd7SPPBDAY8rxejemdxMFRCbCO2z9Nq6yES
	Cp01Cg9gzZliphuOsgizerllz
X-Google-Smtp-Source: AGHT+IHWB7vCxOxRF+vH9VPWcZs/ZlaJZU2ELk53LgETMksHk2Ux/CQSUJCmcGuO/aBH/aY5tp13eQ==
X-Received: by 2002:a05:6000:4007:b0:3a0:9f4c:ca85 with SMTP id ffacd0b85a97d-3a0b99078a9mr8014264f8f.10.1746836332012;
        Fri, 09 May 2025 17:18:52 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Nicola Vetrini ,
	Stefano Stabellini 
Subject: [PATCH] x86/emul: Work around MISRA R13.2 complaint
Date: Sat, 10 May 2025 01:18:48 +0100
Message-Id: <20250510001848.2993380-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Rule 13.2 states: "The value of an expression and its persistent side effects
shall be the same under all permitted evaluation orders".

Eclair complains about a Rule 13.2 violations because validate_far_branch()
assigns to rc, and the entirety of commit_far_branch() is also assigned to rc.

I'm unsure that the complaint is accurate, but rewriting commit_far_branch()
to use the comma operator seems to make Eclair happy.

Reported-by: Nicola Vetrini 
Signed-off-by: Andrew Cooper 
Reviewed-by: Stefano Stabellini 
---
CC: Stefano Stabellini 
CC: Nicola Vetrini 
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index 8e14ebb35b0e..6ee64cb85987 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -333,12 +333,14 @@ do {                                                                    \
                               : (ip) > (cs)->limit, X86_EXC_GP, 0);     \
 })
 
-#define commit_far_branch(cs, newip) ({                                 \
-    validate_far_branch(cs, newip);                                     \
-    _regs.r(ip) = (newip);                                              \
-    singlestep = _regs.eflags & X86_EFLAGS_TF;                          \
-    ops->write_segment(x86_seg_cs, cs, ctxt);                           \
-})
+#define commit_far_branch(cs, newip) (                                  \
+        ({                                                              \
+            validate_far_branch(cs, newip);                             \
+            _regs.r(ip) = (newip);                                      \
+            singlestep = _regs.eflags & X86_EFLAGS_TF;                  \
+        }),                                                             \
+        ops->write_segment(x86_seg_cs, cs, ctxt)                        \
+    )
 
 int x86emul_get_fpu(
     enum x86_emulate_fpu_type type,

base-commit: 9b3a02e66f058ebd77db6628e3144352857bdf2b
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Sat May 10 06:03:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 May 2025 06:03:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980610.1367239 (Exim 4.92)
	(envelope-from )
	id 1uDdIP-00054V-Ov; Sat, 10 May 2025 06:02:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980610.1367239; Sat, 10 May 2025 06:02: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 1uDdIP-00054N-Kf; Sat, 10 May 2025 06:02:49 +0000
Received: by outflank-mailman (input) for mailman id 980610;
 Sat, 10 May 2025 06:02:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uDdIN-00054F-Rk
 for xen-devel@lists.xenproject.org; Sat, 10 May 2025 06:02:47 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6246604d-2d64-11f0-9ffb-bf95429c2676;
 Sat, 10 May 2025 08:02:41 +0200 (CEST)
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 857641F397;
 Sat, 10 May 2025 06:02: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 4F8A1136A5;
 Sat, 10 May 2025 06:02: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 PQZQEQDsHmjhMgAAD6G6ig
 (envelope-from ); Sat, 10 May 2025 06:02: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" 
X-Inumbo-ID: 6246604d-2d64-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1746856960; 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=5x0FrLrT9arD78nhtjUiXkm3MxmtAVjf5jKghGKlN54=;
	b=B0yilAF3iYnqGKxHn3iBP5eDc7zGo5ks3Fq6A7wtKy09l/DrrFLRmEunhCyEadEbkuh/ZE
	hqwRBLuuYfLVKiESDAoPmzocev/mYt97xsXIj1cw02maWwsvxlJ3iOJ7KgHwfWdp4Th54H
	MvoqfcdJsYfQH90L+SgJj3Ca4WzDnUg=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=B0yilAF3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1746856960; 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=5x0FrLrT9arD78nhtjUiXkm3MxmtAVjf5jKghGKlN54=;
	b=B0yilAF3iYnqGKxHn3iBP5eDc7zGo5ks3Fq6A7wtKy09l/DrrFLRmEunhCyEadEbkuh/ZE
	hqwRBLuuYfLVKiESDAoPmzocev/mYt97xsXIj1cw02maWwsvxlJ3iOJ7KgHwfWdp4Th54H
	MvoqfcdJsYfQH90L+SgJj3Ca4WzDnUg=
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 v6.15-rc6
Date: Sat, 10 May 2025 08:02:39 +0200
Message-ID: <20250510060239.18894-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Rspamd-Queue-Id: 857641F397
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level: 
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)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	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];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:dkim];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Action: no action

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.15a-rc6-tag

xen: branch for v6.15-rc6

It contains the following patches:

- A fix for the xenbus driver allowing to use a PVH Dom0 with Xenstore
  running in another domain.

- A fix for the xenbus driver addressing a rare race condition resulting
  in NULL dereferences and other problems.

- A fix for the xen-swiotlb driver fixing a problem seen on Arm platforms.

Thanks.

Juergen

 drivers/xen/swiotlb-xen.c                |  1 +
 drivers/xen/xenbus/xenbus.h              |  2 ++
 drivers/xen/xenbus/xenbus_comms.c        |  9 ++++-----
 drivers/xen/xenbus/xenbus_dev_frontend.c |  2 +-
 drivers/xen/xenbus/xenbus_probe.c        | 14 ++++++++------
 drivers/xen/xenbus/xenbus_xs.c           | 18 ++++++++++++++++--
 6 files changed, 32 insertions(+), 14 deletions(-)

Jason Andryuk (2):
      xenbus: Allow PVH dom0 a non-local xenstore
      xenbus: Use kref to track req lifetime

John Ernberg (1):
      xen: swiotlb: Use swiotlb bouncing if kmalloc allocation demands it


From xen-devel-bounces@lists.xenproject.org Sat May 10 13:13:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 May 2025 13:13:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980653.1367273 (Exim 4.92)
	(envelope-from )
	id 1uDk0e-0004MM-Vc; Sat, 10 May 2025 13:12:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980653.1367273; Sat, 10 May 2025 13:12: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 1uDk0e-0004ME-QD; Sat, 10 May 2025 13:12:56 +0000
Received: by outflank-mailman (input) for mailman id 980653;
 Sat, 10 May 2025 13:12:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDk0d-0004M7-3Z
 for xen-devel@lists.xenproject.org; Sat, 10 May 2025 13:12:55 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 78772278-2da0-11f0-9eb5-5ba50f476ded;
 Sat, 10 May 2025 15:12:48 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-43ede096d73so20325585e9.2
 for ; Sat, 10 May 2025 06:12:48 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f58ec98dsm6300589f8f.25.2025.05.10.06.12.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 10 May 2025 06:12: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" 
X-Inumbo-ID: 78772278-2da0-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1746882768; x=1747487568; 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;
        bh=uClM/AYIN3dAwhC3WC9ieVOoIB+XXfbidPOvm+A7PpY=;
        b=tFIeWCIx4ZwvaIoSfEriyn2mOrFIozZSplkNRw2o7Rt+xeb7narOa+ad1UVzeoTw1y
         RbtYS4lh9+2dOst7COnnlMIthJHOHZj0F6NaWqjsA6asg9hvrWVuO+zi0gf+Qfx52qLK
         gEGw4kQ6oXy0ZQkB64NFKJCNq6WZrxMq/v6jM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746882768; x=1747487568;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=uClM/AYIN3dAwhC3WC9ieVOoIB+XXfbidPOvm+A7PpY=;
        b=CDRthvb1LwiiX4LamHpXz/C09Z6orZQWlh/xgE2zFybkoep1x6NB1Pg0xiy52uGhNq
         Ccb1LtK/1r250SU3duXSWZ94bBTpC6gIg0N5XOIi+VY1JjhJD1c/R3l8LqXmF9BCWjId
         619lHauxd43255IY9q5x2UdrtkvnkN3r401XA1mvAfTBjoIUmkR8h+ZkfEJquLYs+AMQ
         LFViWn2M2wXBgXboIiDiINwpytk2n4EjRce1O+LNdBun+RYfQn0UqRavax49R72hCEM1
         /LT0PHoaDmwX9o78vkME3VCRyXqprkEY78dZIcNbYGMeLlZfEzbD6ZDmEx5Cxn/b9+KE
         v0qA==
X-Gm-Message-State: AOJu0YysVU3eh+0DDIw0nRWo88eg575ObyfsYeeVLWTU3oG9RzlLFwtR
	o9SNpOWlFTDGmngaI7flGlT9YC39caV58CJBAs5dDW7oKC7ZstuNWNc7J4hMR/aiJpIrmlmdPuI
	j
X-Gm-Gg: ASbGnctM5zDsPKgjfxHSXufX7muiIVgFmrTeAUPpJB512GFD2oTacx0jN0c7rayeKZU
	4wpw4CAsG1mz+ZzcYgouMSnmFKdOajXNp6j/PD4LMd4Bu1XNMmKn3GvwH/SztXb4/C7bKSoVIi5
	fy6cYvAjGh1m3qFKfj/zVbIWUGZ5q8YpS0MjE3/eBTuHfULGEwVR8OELbol2FzdYAc/k0C0WwrT
	6d13K1uj61FzuAUdCGJBgn/Ssm02mO2WObyEcvZRwlUPsHezpvndPR4WI5vuBwd4GwfodN/cM8f
	GmDWCw3Afr5mKBeLJfOvRqi6jR2kR5oUWwOfb2aPzZuAUYaQ7he1vguHr2HbPbFdWTmITEBn364
	slCjCPjYcYu7G3i1Hcxvo4s4U
X-Google-Smtp-Source: AGHT+IGbsP5ut1PKHLOsau2UBH2PFiNxAdsbXV8uaQX5DoaOmgqlbYAQD6lXSN1m/Rqa/XT8HUbBDw==
X-Received: by 2002:a05:6000:1a8c:b0:3a0:ad33:c1b3 with SMTP id ffacd0b85a97d-3a1f6422047mr5810515f8f.3.1746882768068;
        Sat, 10 May 2025 06:12:48 -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/bitmap: Drop unused headers
Date: Sat, 10 May 2025 14:12:45 +0100
Message-Id: <20250510131245.3062123-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

Nothing in bitmap.h uses lib.h.  Reduce to just macros.h and string.h.  Drop
types.h while at it, as it comes in through bitops.h

cpumask.h and nodemask.h only include kernel.h to get container_of().  Move it
into macros.h where it belongs.

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/1810741296

v2:
 * Rebase by a year.
 * Move container_of() too.
---
 xen/include/xen/bitmap.h   |  4 ++--
 xen/include/xen/cpumask.h  |  1 -
 xen/include/xen/kernel.h   | 12 ------------
 xen/include/xen/macros.h   | 13 +++++++++++++
 xen/include/xen/nodemask.h |  1 -
 5 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/xen/include/xen/bitmap.h b/xen/include/xen/bitmap.h
index b5e9cdd3db86..79b2cd171595 100644
--- a/xen/include/xen/bitmap.h
+++ b/xen/include/xen/bitmap.h
@@ -3,9 +3,9 @@
 
 #ifndef __ASSEMBLY__
 
-#include 
-#include 
 #include 
+#include 
+#include 
 
 /*
  * bitmaps provide bit arrays that consume one or more unsigned
diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
index b713bb69a9cb..a7715dfa0308 100644
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -57,7 +57,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 typedef struct cpumask{ DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index c5b6cc977772..378f21c247a6 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -8,18 +8,6 @@
 #include 
 #include 
 
-/**
- * container_of - cast a member of a structure out to the containing structure
- *
- * @ptr:	the pointer to the member.
- * @type:	the type of the container struct this is embedded in.
- * @member:	the name of the member within the struct.
- *
- */
-#define container_of(ptr, type, member) ({                      \
-        typeof_field(type, member) *__mptr = (ptr);             \
-        (type *)( (char *)__mptr - offsetof(type,member) );})
-
 /**
  * __struct_group() - Create a mirrored named and anonyomous struct
  *
diff --git a/xen/include/xen/macros.h b/xen/include/xen/macros.h
index cd528fbdb127..58affb1588c5 100644
--- a/xen/include/xen/macros.h
+++ b/xen/include/xen/macros.h
@@ -102,6 +102,19 @@
  */
 #define sizeof_field(type, member) sizeof(((type *)NULL)->member)
 
+/**
+ * container_of - cast a member of a structure out to the containing structure
+ *
+ * @ptr:	the pointer to the member.
+ * @type:	the type of the container struct this is embedded in.
+ * @member:	the name of the member within the struct.
+ */
+#define container_of(ptr, type, member)                         \
+    ({                                                          \
+        typeof_field(type, member) *__mptr = (ptr);             \
+        (type *)((void *)__mptr - offsetof(type, member));      \
+    })
+
 /* Cast an arbitrary integer to a pointer. */
 #define _p(x) ((void *)(unsigned long)(x))
 
diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h
index 1dd6c7458e77..60d6455feb8b 100644
--- a/xen/include/xen/nodemask.h
+++ b/xen/include/xen/nodemask.h
@@ -53,7 +53,6 @@
  * for_each_online_node(node)		for-loop node over node_online_map
  */
 
-#include 
 #include 
 #include 
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Sat May 10 16:04:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 May 2025 16:04:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980680.1367286 (Exim 4.92)
	(envelope-from )
	id 1uDmgG-0007oE-IE; Sat, 10 May 2025 16:04:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980680.1367286; Sat, 10 May 2025 16: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 1uDmgG-0007o7-FP; Sat, 10 May 2025 16:04:04 +0000
Received: by outflank-mailman (input) for mailman id 980680;
 Sat, 10 May 2025 16:04:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDmgF-0007o1-Q8
 for xen-devel@lists.xenproject.org; Sat, 10 May 2025 16:04:03 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12olkn20812.outbound.protection.outlook.com
 [2a01:111:f403:2c17::812])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 61c2f2af-2db8-11f0-9ffb-bf95429c2676;
 Sat, 10 May 2025 18:04:00 +0200 (CEST)
Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23)
 by CO6PR02MB8804.namprd02.prod.outlook.com (2603:10b6:303:143::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.24; Sat, 10 May
 2025 16:03:55 +0000
Received: from SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::cedd:1e64:8f61:b9df]) by SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::cedd:1e64:8f61:b9df%3]) with mapi id 15.20.8722.027; Sat, 10 May 2025
 16:03: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" 
X-Inumbo-ID: 61c2f2af-2db8-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=P5JHj/EfutujMkhdbOHhj+B1g+qkZhYOOYCQjO9oPaBdlGBPNikBzvG8JXS66T/UoCHVrcuf+7aSkFKIXnaumV2wnnESVVUxmsqfU3aMBfu1peVuf4dsvt4bnoqRurME2v5+szEGNdok39cbk7grE7TnaF9Xya8dB+cddIPSaYO5DHYtRCs25lp+e4qTJMcg8hCoKbBQ2WU/wKVbgAy0o0r95jOdbvNmPf/Pw+72AZ/JJUXkZe1hlhIScFNkYdmgGt7VLQB+Ttcdh/bT6hcZxSaR/Hhpj0Ur7JmLwWFu+X5Cblq610m8+tf2xcqDGMmOmuGbo+nZcWIp4iOIeqDLFw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Tjs5AmFLgTWYdxmohOlPee4q0M1+ZDvdtNJL9cCkKtM=;
 b=lWwOxaiqOZURx41hKG8Q14Q1iyJ8Mj5gaKWPtK18m4JzlBe0N99f/GIgG8AvbskqrpHfnQSTx4eXFEEVzA9S5OW3Oh8B4qNtzVfLav7WFUllH6SyOlDVfUaAdWSV+AoxDRnDMOdkA32WuYlSUWG70jL+Fvp3h8hYUdnFuBdPmM0ZVnkID8v1uFg4j6zViXuJH2NydJDPQwuWoHYsIf6ZLVSI+ERcAU3niCNang3rS4D9DZuAt7vV/iM5IuAq10kJ8sc0JoPExfm7edSCUaXXsxMAOyOrm0ea1XiIVn6CI0zYYTToO+uvBCQSWwgKGUkvxgDX7wHJyvD5OH0+d3+XpA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Tjs5AmFLgTWYdxmohOlPee4q0M1+ZDvdtNJL9cCkKtM=;
 b=pYcGDj0iTkVy3A6I43utBkwj+Pxm5ifuYtYnEHBNkRj+iNji0CN4GZI2qX2H65XrCSTs0esX7mAClNWL/CaPmfUsdxMLZ77rlK4aAYpmPgVJvEPrLNgMpEmVLg7WyvrqJ+GYtMla96mbhZ6ke8zI3ytnc+8H30Gnb3QSiBi/yAVsSACKUac7TEPzeATYJHz/spRNecmMlVCKNUlfnFVgo2RWpGi2GNl7cjuZFwRM4QarahMgi74s/cMsmRHEl57TShoc3Y098MsfngUcpkeoRo5tolCs8rwjHVe/6TiHo1idmV/yUrUNLbMtMkIfyNlQJv0pVUDQusRnzHAy/Hx2uQ==
From: Michael Kelley 
To: Juergen Gross , "linux-kernel@vger.kernel.org"
	, "x86@kernel.org" ,
	"linux-coco@lists.linux.dev" ,
	"kvm@vger.kernel.org" , "linux-hyperv@vger.kernel.org"
	, "virtualization@lists.linux.dev"
	
CC: "xin@zytor.com" , "Kirill A. Shutemov"
	, Dave Hansen ,
	Thomas Gleixner , Ingo Molnar ,
	Borislav Petkov , "H. Peter Anvin" , Sean
 Christopherson , Paolo Bonzini , "K.
 Y. Srinivasan" , Haiyang Zhang ,
	Wei Liu , Dexuan Cui , Vitaly
 Kuznetsov , Boris Ostrovsky
	, "xen-devel@lists.xenproject.org"
	, Ajay Kaher ,
	Alexey Makhalov , Broadcom internal kernel
 review list 
Subject: RE: [PATCH 0/6] x86/msr: let paravirt inline rdmsr/wrmsr instructions
Thread-Topic: [PATCH 0/6] x86/msr: let paravirt inline rdmsr/wrmsr
 instructions
Thread-Index: AQHbvmhEFeeiouIdcUmtZAu/e2cRwrPMDIRg
Date: Sat, 10 May 2025 16:03:54 +0000
Message-ID:
 
References: <20250506092015.1849-1-jgross@suse.com>
In-Reply-To: <20250506092015.1849-1-jgross@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|CO6PR02MB8804:EE_
x-ms-office365-filtering-correlation-id: fff4f73c-6843-4351-b608-08dd8fdc43b7
x-microsoft-antispam:
 BCL:0;ARA:14566002|461199028|8022599003|8060799009|19110799006|8062599006|15080799009|440099028|3412199025|102099032;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?vW/JLr2XhErjr0LSZjs/AQhpI6vRqhTp9yJZTyoS+c5uI1i+63qphDxRJoWG?=
 =?us-ascii?Q?8qo5H9CnZkNQiIb5INZn4mMtOjgIU3m3DPkK8TuWxWzExJeW9yuW9zmET1f5?=
 =?us-ascii?Q?Wf2IoIA6pbaH+PBj9UwFqWaTVVxabv4BntupXgTCCYPXtf4VhEjTlTX/1amU?=
 =?us-ascii?Q?rnJ73hdJd14DtLXNMGsB8Mt5Ui0y9SpZThcjWk8s4Nvsahm+PqGEacEfZ7/R?=
 =?us-ascii?Q?uJqhXM3csG2B493OaQ9HuZWakrUTRF1vYQANEntKaoruA1q905zYN8csIIM3?=
 =?us-ascii?Q?eW4LsmXYmO2J0GndJ6plBwVDtqApG9HNQO4q32A/hWOmNxByj6frXDlhLPlB?=
 =?us-ascii?Q?+WmFWP2Ui1/r3on6DZkxdEm00fJ9XOaDq0BZ872jc0bveyJwOtrjZY3Q5ugo?=
 =?us-ascii?Q?eff3l0fL44zrfbLnwEXqsU3i/0zEk4FtiwaN0RcC2Kb27O3Bu3B7XXrI8M/h?=
 =?us-ascii?Q?6BtzqMuv2HHS8H1PaU24eNrMuv8wiwCebwoh67/woEZYOtyVYhdtLanuVgh5?=
 =?us-ascii?Q?TKJvY3OvwJPe3hWFS7R9Lc4rD6WQcor7KZrtZGBlert9vzsfQaME9HtCrl0c?=
 =?us-ascii?Q?/Bhpjf32KXYAaCK1CBpOuOqBukkqhpIzvGFhqaMvEN+sv/8mmCH4HCCcInQK?=
 =?us-ascii?Q?Rl3QlJVF2b7mX1SJHEmmVcKkY0M7WXsQ04/m8mdEJof+GmH74T5tCItPSxbJ?=
 =?us-ascii?Q?+QZ/+AJmouNROpsYT4lfzBCHEY/InvUbSZmyrWqoM5ZpkJBr5fjCHlDv8A51?=
 =?us-ascii?Q?dVqNpVXXu0vYgdIQwvdMP/U5jIUEg+G4Vrr/UV7eP07dYjlgCDMeftVlXfJP?=
 =?us-ascii?Q?K1JoDey7uiQTct4iuR3BSZ1rD3xBeKMkaSTlQ17nneC2oEysrSXXefdDrcfS?=
 =?us-ascii?Q?gSVtUdJyL4LSXqkzljU2XiaRt2aKb8Ce6oLGC4UU2x2TkeoiUpD17E/Y0zQi?=
 =?us-ascii?Q?io6LZQLEV7sZZycrHSeklbu7CKg2r7OyvtXSKqh8JuhFJB6s+bnIxdbYyRhS?=
 =?us-ascii?Q?+ttahkmZuhcRwBRKIT/9HyJ8QwslgX5dtN0FD6JkMB12E2hSBe5AYRdYvwNs?=
 =?us-ascii?Q?YYivGUzChRP6mTUpvOZlEiq5+FQ9M5VBCt/wXCwb/C+4dY5WhsA=3D?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?wCl/61ooYViviLAx3f755R653/M30G6YIHnuI9Vh+zJQrQZskXgQYyOimGBl?=
 =?us-ascii?Q?SmDpMIU6NsqbDoT2PHdntrCZ5EMVjfS9NmUlXEikH95icX7CNjcbhRLgtJhS?=
 =?us-ascii?Q?VmfMQ2jgFwbucT2rfufJAMFiMQnjXtjW63jcZKojlrH42SeUZMHS+iigAD8r?=
 =?us-ascii?Q?2E6P2JBBExaU81q+MF3ScYG80YHf3jfljBl2MN30YpiwXpOY+vI99HLud87q?=
 =?us-ascii?Q?1iOvShu+5VVH3U6z4LckreUUYA/CE7aicyqo112RT6o/mqRd3MAGRPtDbISp?=
 =?us-ascii?Q?Cu7AgzqibHUU1pASe+H5YM2DTl6J3n/KKpfJ1ytQkcx251yU+tDx37yftoGe?=
 =?us-ascii?Q?XiVR+bgVVmy+NgWlkUtij4WxVP1V/TZW+dhWu05xdirtODoTwfX6hzj1iHm3?=
 =?us-ascii?Q?MxtNrumTZHNzMwbQX9Gy1tU6aIfacZ9/a2VLjqIQn4TUPuAZd2gk1mTG0Qiy?=
 =?us-ascii?Q?7tW9Mxm7DXIODDkCVR/JM7ktGFyHU65iVOKGyii8b+HBTfqZRaVnjsESsacR?=
 =?us-ascii?Q?Xa1G3uznk75VEiL8pj2ZRXa8PlIBh5xBihbHr0Rn2thP6i8KzJrC1EpStNK5?=
 =?us-ascii?Q?pJ7/u9eRbGINvbXPTmugsBSgpkOMWnorPRUq66Los9fPPwytEuUvQXZNEvzJ?=
 =?us-ascii?Q?3v33fk7WQAz49DPFWLdHu8CELoMCdnckQopYtUfIBMk2HY4e+FGdlCa4MEzi?=
 =?us-ascii?Q?6XYUMDC+8+/JMx88EDJgTQLB4B4WBF6sneKqYMTa495nNIFePqy5jXu00RUt?=
 =?us-ascii?Q?pQxL7ULRP6HD0uBqPBrit9sMy3v13XvcUHpjRJxcd38tNg+Fw0rs9Y9sUKsh?=
 =?us-ascii?Q?XNL6KXih45YVwf14F3D1Oi8hB7hn3XXV+daBNiBLbzSWAUTMfU9Ohh39B086?=
 =?us-ascii?Q?FGO36TzKxhaHBQaLRW4GLVOUibK7sdccK/KX7xPQnP7Tnq8RwxZ8dk7whe2C?=
 =?us-ascii?Q?L2/JqrUVQjFRUSOk3CC1UYXppKQgubhnsA6H0NK7NpNkyh2Fx20gvUY5GSyf?=
 =?us-ascii?Q?95Wk2RNdYtpj9pYuWlcvYnsSg4/rrb+jtis3YqRemrtBozP+JohxuGh1gZN8?=
 =?us-ascii?Q?QhJ4yBY4gr0dO+sXAYKNX7wIQuvhDU0tSDMvvQKPGfKABKpg+jqCwsdrGTwW?=
 =?us-ascii?Q?5s54TRNoTI0Mv1mxYhKixEP+aqb+2tMBvlFAlioDWiUfhmscQvFBkamy3Kyy?=
 =?us-ascii?Q?b+j5WbOqP6Y0g6c/lSCJQF4upo2B6HJTbCUO/uvX/ya2DsIU6cIWz5QClSw?=
 =?us-ascii?Q?=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: fff4f73c-6843-4351-b608-08dd8fdc43b7
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2025 16:03:54.8149
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB8804

From: Juergen Gross  Sent: Tuesday, May 6, 2025 2:20 AM
>=20
> When building a kernel with CONFIG_PARAVIRT_XXL the paravirt
> infrastructure will always use functions for reading or writing MSRs,
> even when running on bare metal.
>=20
> Switch to inline RDMSR/WRMSR instructions in this case, reducing the
> paravirt overhead.
>=20
> In order to make this less intrusive, some further reorganization of
> the MSR access helpers is done in the first 4 patches.
>=20
> This series has been tested to work with Xen PV and on bare metal.

I've tested in SEV-SNP and TDX guests with paravisor on Hyper-V. Basic
smoke test showed no issues.

Tested-by: Michael Kelley 

>=20
> There has been another approach by Xin Li, which used dedicated #ifdef
> and removing the MSR related paravirt hooks instead of just modifying
> the paravirt code generation.
>=20
> Please note that I haven't included the use of WRMSRNS or the
> immediate forms of WRMSR and RDMSR, because I wanted to get some
> feedback on my approach first. Enhancing paravirt for those cases
> is not very complicated, as the main base is already prepared for
> that enhancement.
>=20
> This series is based on the x86/msr branch of the tip tree.
>=20
> Juergen Gross (6):
>   coco/tdx: Rename MSR access helpers
>   x86/kvm: Rename the KVM private read_msr() function
>   x86/msr: minimize usage of native_*() msr access functions
>   x86/msr: Move MSR trace calls one function level up
>   x86/paravirt: Switch MSR access pv_ops functions to instruction
>     interfaces
>   x86/msr: reduce number of low level MSR access helpers
>=20
>  arch/x86/coco/tdx/tdx.c                   |   8 +-
>  arch/x86/hyperv/ivm.c                     |   2 +-
>  arch/x86/include/asm/kvm_host.h           |   2 +-
>  arch/x86/include/asm/msr.h                | 116 ++++++++++-------
>  arch/x86/include/asm/paravirt.h           | 152 ++++++++++++++--------
>  arch/x86/include/asm/paravirt_types.h     |  13 +-
>  arch/x86/include/asm/qspinlock_paravirt.h |   5 +-
>  arch/x86/kernel/kvmclock.c                |   2 +-
>  arch/x86/kernel/paravirt.c                |  26 +++-
>  arch/x86/kvm/svm/svm.c                    |  16 +--
>  arch/x86/kvm/vmx/vmx.c                    |   4 +-
>  arch/x86/xen/enlighten_pv.c               |  60 ++++++---
>  arch/x86/xen/pmu.c                        |   4 +-
>  13 files changed, 262 insertions(+), 148 deletions(-)
>=20
> --
> 2.43.0
>=20



From xen-devel-bounces@lists.xenproject.org Sat May 10 16:28:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 May 2025 16:28:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980690.1367297 (Exim 4.92)
	(envelope-from )
	id 1uDn3q-0002Fk-Db; Sat, 10 May 2025 16:28:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980690.1367297; Sat, 10 May 2025 16:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDn3q-0002Fd-9g; Sat, 10 May 2025 16:28:26 +0000
Received: by outflank-mailman (input) for mailman id 980690;
 Sat, 10 May 2025 16:28:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDn3p-0002FW-LF
 for xen-devel@lists.xenproject.org; Sat, 10 May 2025 16:28:25 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c86a62cb-2dbb-11f0-9ffb-bf95429c2676;
 Sat, 10 May 2025 18:28:20 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id D40D3A4BD86;
 Sat, 10 May 2025 16:28:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7923AC4CEE2;
 Sat, 10 May 2025 16:28:18 +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
 EAE8C3822D42; Sat, 10 May 2025 16:28: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" 
X-Inumbo-ID: c86a62cb-2dbb-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1746894498;
	bh=R4+pyvED4JPWaKKZNPWCeKPn1xFDJDCAuUXhwp+6kZ0=;
	h=Subject:From:In-Reply-To:References:Date:To:Cc:From;
	b=VfDUI3vyfbRoiK68I7/X7BAioQ7uZpKBJ0OOJ2Tn73eNCkLK36TteA6MhyPNGks1K
	 GDpK9UhlojkAlZzYmGnOKKrs5g84GxcJSu9S2NTjOX9U++WRHDdN5kcAoUVSSGpuJB
	 INeMT2ThmfnXRdKr1J3DIXiEylmG8pHCtrlcntS/Y1FpyavxQ2zj6DYE64l+m1VLnm
	 X9dwji2PchlpWwlGnFODccK9PrXPu/KMkglmlob+qSWZJyEr3ceBZxldQ7Pf2qfzxX
	 p5qLavK/LfDByJfzPLCFehtQhKKVfvaA+4rWi0oh9oHQ9bMcM6etzs0PF6m8rtFmvp
	 y4rqs4TRvSXjw==
Subject: Re: [GIT PULL] xen: branch for v6.15-rc6
From: pr-tracker-bot@kernel.org
In-Reply-To: <20250510060239.18894-1-jgross@suse.com>
References: <20250510060239.18894-1-jgross@suse.com>
X-PR-Tracked-List-Id: Xen developer discussion 
X-PR-Tracked-Message-Id: <20250510060239.18894-1-jgross@suse.com>
X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.15a-rc6-tag
X-PR-Tracked-Commit-Id: 1f0304dfd9d217c2f8b04a9ef4b3258a66eedd27
X-PR-Merge-Tree: torvalds/linux.git
X-PR-Merge-Refname: refs/heads/master
X-PR-Merge-Commit-Id: 86c019597cd4e0fc90dfa9ebba9282b2d122c187
Message-Id: <174689453659.4001425.18085781507262219952.pr-tracker-bot@kernel.org>
Date: Sat, 10 May 2025 16:28:56 +0000
To: Juergen Gross 
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org

The pull request you sent on Sat, 10 May 2025 08:02:39 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.15a-rc6-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/86c019597cd4e0fc90dfa9ebba9282b2d122c187

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From xen-devel-bounces@lists.xenproject.org Sat May 10 18:37:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 10 May 2025 18:37:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980704.1367307 (Exim 4.92)
	(envelope-from )
	id 1uDp4k-0000pj-Sm; Sat, 10 May 2025 18:37:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980704.1367307; Sat, 10 May 2025 18:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uDp4k-0000pc-Px; Sat, 10 May 2025 18:37:30 +0000
Received: by outflank-mailman (input) for mailman id 980704;
 Sat, 10 May 2025 18:37:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uDp4k-0000pW-9F
 for xen-devel@lists.xenproject.org; Sat, 10 May 2025 18:37:30 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d18f1a14-2dcd-11f0-9eb5-5ba50f476ded;
 Sat, 10 May 2025 20:37:28 +0200 (CEST)
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-462-RsyE8OITNZmsNK-Eh3G34g-1; Sat,
 10 May 2025 14:37:23 -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 E7B83180035E; Sat, 10 May 2025 18:37:20 +0000 (UTC)
Received: from localhost (unknown [10.2.16.39])
 by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id D9D9F19560B0; Sat, 10 May 2025 18:37: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" 
X-Inumbo-ID: d18f1a14-2dcd-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1746902245;
	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=ZwFEh6TeQ/8H51vJTIhIozvJpz7tQ/a2+PVeDJq/CUE=;
	b=EuQ8k/Grf/wlVdNrFxAk3n3XD8EyLxd6owovfgcJlXKQpBiRHbP8/XdAkXWe5o3FT4QjeS
	sAaf6RJGMQrA1TUuG2xmiOy70ilOum+JiaRqd/FbqitjG/FtGxxznEPxfVTzS94l27l7WY
	aUYW5wVN0U99CNVTF0LgCuHLnXHo/PQ=
X-MC-Unique: RsyE8OITNZmsNK-Eh3G34g-1
X-Mimecast-MFC-AGG-ID: RsyE8OITNZmsNK-Eh3G34g_1746902241
Date: Sat, 10 May 2025 14:35:30 -0400
From: Stefan Hajnoczi 
To: "Edgar E. Iglesias" 
Cc: qemu-devel@nongnu.org, qemu-stable@nongnu.org, sstabellini@kernel.org,
	anthony@xenproject.org, paul@xen.org, alex.pentagrid@gmail.com,
	peter.maydell@linaro.org, edgar.iglesias@amd.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PULL v1 0/2] xen: mapcache: Fixes
Message-ID: <20250510183530.GA116869@fedora>
References: <20250506182647.302961-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="/i3kukPHmWcJP39C"
Content-Disposition: inline
In-Reply-To: <20250506182647.302961-1-edgar.iglesias@gmail.com>
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12


--/i3kukPHmWcJP39C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/10.1 for any user-visible changes.

--/i3kukPHmWcJP39C
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmgfnHEACgkQnKSrs4Gr
c8j8tggAvnRrQweJgUw6K7reSq12P9b9XzUcjumibOgBBolATBPlplHyEtE9ACvB
NRsd6Bs/yfcCpKc8elPDC0jhrWC/Ii9d/a7xOLpSJpb4X6Jvmvl2LIC2IYmbMQ7x
zJGZuKSQ39p8RqpHQbS8Lc7vM83susWIiV6o6N0ErjvCUbQ/0h5iCCd4t0GPszWE
tT/7YXlCnpdR/S4e7E9W51+JKdD+r+rgFayQjvZb+oJZaMkB3u6laSeGkbicsWh4
JgDmRN6jagWI03mSTK111WVYR40uXtKVxEKCHxCMQzE3YLzGvFcS567KLMuRLfIQ
oWxSrz3tDIpJLDUdKz31VOHzLm6y/Q==
=+iw6
-----END PGP SIGNATURE-----

--/i3kukPHmWcJP39C--



From xen-devel-bounces@lists.xenproject.org Mon May 12 07:15:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 07:15:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980925.1367317 (Exim 4.92)
	(envelope-from )
	id 1uENNF-0007na-Sa; Mon, 12 May 2025 07:14:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980925.1367317; Mon, 12 May 2025 07:14: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 1uENNF-0007nT-Pm; Mon, 12 May 2025 07:14:53 +0000
Received: by outflank-mailman (input) for mailman id 980925;
 Mon, 12 May 2025 07:14:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uENNE-0007nN-I3
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 07:14:52 +0000
Received: from mail.actia.se (mail.actia.se [212.181.117.226])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cb8028dd-2f00-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 09:14:51 +0200 (CEST)
Received: from S036ANL.actianordic.se (10.12.31.117) by S035ANL.actianordic.se
 (10.12.31.116) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 12 May
 2025 09:14:50 +0200
Received: from S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69]) by
 S036ANL.actianordic.se ([fe80::e13e:1feb:4ea6:ec69%3]) with mapi id
 15.01.2507.039; Mon, 12 May 2025 09:14:50 +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" 
X-Inumbo-ID: cb8028dd-2f00-11f0-9eb5-5ba50f476ded
From: John Ernberg 
To: Juergen Gross , Stefano Stabellini
	
CC: Oleksandr Tyshchenko ,
	"xen-devel@lists.xenproject.org" ,
	"iommu@lists.linux.dev" ,
	"linux-kernel@vger.kernel.org" , "Christoph
 Hellwig" , "imx@lists.linux.dev" ,
	John Ernberg 
Subject: [PATCH v2] xen: swiotlb: Wire up map_resource callback
Thread-Topic: [PATCH v2] xen: swiotlb: Wire up map_resource callback
Thread-Index: AQHbww2MQ91Fme3GEU6/lmK+Crf+Dw==
Date: Mon, 12 May 2025 07:14:50 +0000
Message-ID: <20250512071440.3726697-1-john.ernberg@actia.se>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.49.0
x-originating-ip: [10.12.12.35]
x-esetresult: clean, is OK
x-esetid: 37303A2956B14453617466
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

When running Xen on iMX8QXP, an Arm SoC without IOMMU, DMA performed via
its eDMA v3 DMA engine fail with a mapping error.

The eDMA performs DMA between RAM and MMIO space, and it's the MMIO side
that cannot be mapped.

MMIO->RAM DMA access cannot be bounce buffered if it would straddle a page
boundary and on Xen the MMIO space is 1:1 mapped for Arm, and x86 PV Dom0.
Cases where MMIO space is not 1:1 mapped, such as x86 PVH Dom0, requires an
IOMMU present to deal with the mapping.

Considering the above the map_resource callback can just be wired to the
existing dma_direct_map_resource() function.

There is nothing to do for unmap so the unmap callback is not needed.

Signed-off-by: John Ernberg 

---

v2:
 - Just use dma_direct_map_resource() directly (Stefano Stabellini)
 - Incorporate some of the discussion and explanations from v1 into the
    commit message (Stefano, Christoph)
 - General English improvements in the commit message.
 - Just this patch now, 1/2 in the previous set was applied

v1: (series) https://lore.kernel.org/xen-devel/20250502114043.1968976-1-joh=
n.ernberg@actia.se/
---
 drivers/xen/swiotlb-xen.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ef56a2500ed6..da1a7d3d377c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -426,4 +426,5 @@ const struct dma_map_ops xen_swiotlb_dma_ops =3D {
 	.alloc_pages_op =3D dma_common_alloc_pages,
 	.free_pages =3D dma_common_free_pages,
 	.max_mapping_size =3D swiotlb_max_mapping_size,
+	.map_resource =3D dma_direct_map_resource,
 };
--=20
2.49.0


From xen-devel-bounces@lists.xenproject.org Mon May 12 08:08:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 08:08:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980940.1367327 (Exim 4.92)
	(envelope-from )
	id 1uEOCt-00065j-NU; Mon, 12 May 2025 08:08:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980940.1367327; Mon, 12 May 2025 08:08: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 1uEOCt-00065c-Jv; Mon, 12 May 2025 08:08:15 +0000
Received: by outflank-mailman (input) for mailman id 980940;
 Mon, 12 May 2025 08:08:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEOCs-00065W-4n
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 08:08:14 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3f49e62e-2f08-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 10:08:11 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a0ac853894so3567929f8f.3
 for ; Mon, 12 May 2025 01:08:11 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a1f5a4cc39sm11447688f8f.100.2025.05.12.01.08.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 01:08:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3f49e62e-2f08-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747037291; x=1747642091; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=PlmK4WNStIboXdhqJDf/RX8TH0la3/vvkcIZZ91ZyUM=;
        b=MF28zU7RXpKbhuQi6xFgzskBCytvDWvZcYaJAaaVil2a+NrcTWmu4p6SAOi3Uu7z0N
         BafnpH//0aEPCfp2qoLInPdOGV+gkF33nxNO+DJTr7pw5wiS5njrjvEIWPfLy/4rfk+V
         LoiDLUGlT5ZHNCgxYlxFWT+OYw5AEX6Dg/w8I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747037291; x=1747642091;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=PlmK4WNStIboXdhqJDf/RX8TH0la3/vvkcIZZ91ZyUM=;
        b=luzNqjL2rAsv8huP/R8up1DALyrLBCI8XStPfXB2drbWtFPsmMeUh5kFYShpQstgix
         gZM/ur9qFPNcvdyY7DCRnXeXAZKA6/OQVd4AyBrf+Ofp+7lhry30blxKhYHLXYfzFclQ
         Gegn7A8sNjyVVMLFqNQr6cFWKrrQQMPljxJZ9WoZKxN+LV6fKnzB86o21wyfI331Bwxq
         nnmYbyvLWlYAM+Ewsq1rR13V+R6vicrV7mHcwP3IumH9jOcG5L9rOhF5qDEsK6yMQ9Tw
         ILgAIfXKn8K8bhaYBW926mUDhsJPafwesspn3VROfFiAyEySfltbSTTjQHd08+wFtSZW
         BJUg==
X-Forwarded-Encrypted: i=1; AJvYcCXHZkFoZUq2BypNfO3kmXzA27EfwIUinGIg2unnLjKp8ydRI8NBg4ujCY05mouKnu7gDb7u2yMq3qQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzf0g2NdWnEXCaPm+Po2GF7x0xtps164wbohvi/7KvMIeKD4NYU
	E3HI9Yx18ftYEq/P1WQ7EBGNi/Op0gstAnpAjwLxHT19a21lM/18TSljDc8FiIk=
X-Gm-Gg: ASbGncvdorACfyHgzye77wSTXF8Fv9L0/8ztCCcaqUskfAKqU0s3NcbyV6rPvAeWnPB
	SmUd7MzpZXxocRCf7vfHm/rA4lfYqlbYOmsMFpE+tH2vz8B9fsPgzsz35mqWjwJhkOiPHHSWcqq
	fBSNFBdZdPy2r8WTJssHCiFrDx3WeHsSBmp+bBuic522ZsydtoRKzxJZf+ymvxNR3Q4QKRYYEDw
	3stStYx2S/P+6iUkwdHH4YYc020078ZcCbIuL2WtffCoSRdrZ7Z643dlBWynTHARhXevzr/p+hE
	tk9ryMvlljqbJsEfzg01onvgFCmBieJ6esClFuWBJBUlWxL+oLMwtDvGqA5643wkdqg=
X-Google-Smtp-Source: AGHT+IGzCyMkiwj/YP3LbD00WNG2RXenmrMQDoFsmqIS/jo8Fv0b7RVc57IknBJA0AH3gkC7/cdyfg==
X-Received: by 2002:a05:6000:2289:b0:391:3406:b4e2 with SMTP id ffacd0b85a97d-3a1f64ab40emr8303236f8f.49.1747037291070;
        Mon, 12 May 2025 01:08:11 -0700 (PDT)
Date: Mon, 12 May 2025 10:08:09 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Demi Marie Obenour 
Cc: Alejandro Vallejo ,
	Xenia Ragiadakou ,
	Stefano Stabellini ,
	Xen developer discussion ,
	Andrew Cooper ,
	Juergen Gross ,
	Xen-devel 
Subject: Re: Mapping memory into a domain
Message-ID: 
References: <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Fri, May 09, 2025 at 02:21:57PM -0400, Demi Marie Obenour wrote:
> On 5/9/25 6:50 AM, Roger Pau Monné wrote:
> > On Fri, May 09, 2025 at 11:47:36AM +0200, Alejandro Vallejo wrote:
> >>>>>>> A Linux driver that needs access to userspace memory
> >>>>>>> pages can get it in two different ways:
> >>>>>>>
> >>>>>>> 1. It can pin the pages using the pin_user_pages family of APIs.
> >>>>>>>    If these functions succeed, the driver is guaranteed to be able
> >>>>>>>    to access the pages until it unpins them.  However, this also
> >>>>>>>    means that the pages cannot be paged out or migrated.  Furthermore,
> >>>>>>>    file-backed pages cannot be safely pinned, and pinning GPU memory
> >>>>>>>    isn’t supported.  (At a minimum, it would prevent the pages from
> >>>>>>>    migrating from system RAM to VRAM, so all access by a dGPU would
> >>>>>>>    cross the PCIe bus, which would be very slow.)
> >>>>>>
> >>>>>> From a Xen p2m this is all fine - Xen will never remove pages from the
> >>>>>> p2m unless it's requested to.  So the pining, while needed on the Linux
> >>>>>> side, doesn't need to be propagated to Xen I would think.
> >>
> >> It might still be helpful to have the concept of pinning to avoid them
> >> being evicted for other reasons (ballooning?). I don't think it'd be
> >> sane to allow returning to Xen a page that a domain ever shared with a
> >> device.
> > 
> > If mapped using the p2m_mmio_direct type in the p2m a domain won't be
> > able to balloon them out.  It would also be misguided for a guest
> > kernel to attempt to balloon out memory that I presume will be inside
> > of a PCI device BAR from the guest point of view.
> 
> Indeed it will be inside a BAR.
> 
> >> re: being requested. Are there real promises from Xen to that effect? I
> >> could make a hypervisor oversubscribing on memory that swaps non-IOVA
> >> mem in and out to disk, moving it around all the time and it would be
> >> compliant with the current behaviour AIUI, but it wouldn't work with
> >> this scheme, because the mfn's would be off more often than not.
> > 
> > Even if Xen supported domain memory swapping, that could never be used
> > with domains that have devices attached, as it's not possible to fixup
> > the p2m on IOMMU fault and retry the access.
> > 
> > Not sure you could even move mfns around, as you would need an atomic
> > way to copy the previous page contents and set the PTE to point to the
> > new page.
> > 
> > Unless you want to get into a (IMO) complicated scheme where the
> > domain notifies the hypervisor which ranges are being used for device
> > DMA accesses (and thus requires guest kernel changes), I think
> > swapping of guest memory when there are assigned devices is a no-go.
> > 
> > Xen has (or had? as I never actually seen it being used) a mechanism
> > to swap domain memory to a dom0 file (see tools/xenpaging.c).  However
> > more than one provider had mentioned to me that one feature they
> > particularly preferred of Xen over KVM is that it would never swap
> > guest memory.  Not sure if that's still the case, but some struggled
> > to prevent KVM from swapping guest memory, and got complains of
> > slowness from their tenants.
> > 
> > For the purposes of getting a prototype I would suggest that you
> > assume p2m memory cannot be randomly swapped out, unless requested by
> > either the guest or the control domain.
> 
> The API being discussed here needs to support frontends that have
> assigned PCI devices, but the pages should never be mapped into
> the frontend domain’s IOMMU context.  If the frontend tries to
> DMA into one of these pages it’s a frontend bug.

That's a detail I didn't get from your previous description.  If
memory is not to be added to the IOMMU page-tables you will need an
extra flag or similar to signal this, as by default all memory added
to a guest p2m is also added to the IOMMU page-tables.  And when using
shared page-tables between the IOMMU and the CPU there's no way to add
mappings to the CPU only.

Do you really need such mappings to be added only to the p2m, and not
the IOMMU page-tables?  I don't think the pages "should never be
mapped", but rather "don't need to be mapped" as the implementation
won't support DMA accesses (iow: "never" is too strong in this
context).  IMO it is fine if for an initial prototype the pages are
also added to the IOMMU page-tables, and later you can add a flag (or
a new hypercall) that strictly only adds pages to the p2m and not the
IOMMU page-tables, it's likely to also be a good performance
improvement.

> >>>>> If pinning were enough things would be simple, but sadly it’s not.
> >>>>>
> >>>>>>> 2. It can grab the *current* location of the pages and register an
> >>>>>>>    MMU notifier.  This works for GPU memory and file-backed memory.
> >>>>>>>    However, when the invalidate_range function of this callback, the
> >>>>>>>    driver *must* stop all further accesses to the pages.
> >>>>>>>
> >>>>>>>    The invalidate_range callback is not allowed to block for a long
> >>>>>>>    period of time.  My understanding is that things like dirty page
> >>>>>>>    writeback are blocked while the callback is in progress.  My
> >>>>>>>    understanding is also that the callback is not allowed to fail.
> >>>>>>>    I believe it can return a retryable error but I don’t think that
> >>>>>>>    it is allowed to keep failing forever.
> >>>>>>>
> >>>>>>>    Linux’s grant table driver actually had a bug in this area, which
> >>>>>>>    led to deadlocks.  I fixed that a while back.
> >>>>>>>
> >>>>>>> KVM implements the second option: it maps pages into the stage-2
> >>>>>>> page tables (or shadow page tables, if that is chosen) and unmaps
> >>>>>>> them when the invalidate_range callback is called.
> >>
> >> I'm still lost as to what is where, who initiates what and what the end
> >> goal is. Is this about using userspace memory in dom0, and THEN sharing
> >> that with guests for as long as its live? And make enough magic so the
> >> guests don't notice the transitionary period in which there may not be
> >> any memory?
> >>
> >> Or is this about using domU memory for the driver living in dom0?
> >>
> >> Or is this about something else entirely?
> >>
> >> For my own education. Is the following sequence diagram remotely accurate?
> >>
> >> dom0                              domU
> >>  |                                  |
> >>  |---+                              |
> >>  |   | use gfn3 in the driver       |
> >>  |   | (mapped on user thread)      |
> >>  |<--+                              |
> >>  |                                  |
> >>  |  map mfn(gfn3) in domU BAR       |
> >>  |--------------------------------->|
> >>  |                              +---|
> >>  |              happily use BAR |   |
> >>  |                              +-->|
> >>  |---+                              |
> >>  |   | mmu notifier for gfn3        |
> >>  |   | (invalidate_range)           |
> >>  |<--+                              |
> >>  |                                  |
> >>  |  unmap mfn(gfn3)                 |
> >>  |--------------------------------->| <--- Plus some means to making guest 
> >>  |---+                          +---|      vCPUs pause on access.
> >>  |   | reclaim gfn3    block on |   |
> >>  |<--+                 access   |   |
> >>  |                              |   |
> >>  |---+                          |   |
> >>  |   | use gfn7 in the driver   |   |
> >>  |   | (mapped on user thread)  |   |
> >>  |<--+                          |   |
> >>  |                              |   |
> >>  |  map mfn(gfn7) in domU BAR   |   |
> >>  |------------------------------+-->| <--- Unpause blocked domU vCPUs
> > 
> > The guest vCPU will already pause on access if there's a p2m
> > violation, until the ioreq has completed and the vCPU execution can
> > resume.  That's in control of the ioreq server that handles the
> > request.
> > 
> > I don't know about the dom0 user-space part, but that's possibly of no
> > concern for the implementation side in Xen?
> 
> I believe so, yes.
> 
> > My understanding of the actions needed from the Xen side is:
> > 
> >  1. Map either RAM owned by the hardware domain or an MMIO page into
> >     a domain p2m.
> >  2. Remove entries from a domain p2m.
> >  3. Handle p2m violations resulting from guest accesses, using 1. and
> >     force a guest access retry (or emulate the access).
> > 
> > 1. Can possibly be done with XEN_DOMCTL_memory_mapping and
> > XENMEM_add_to_physmap_batch, but as I understood it it's not ideal.
> > Demi would like a way to use the same hypercall to map either RAM or
> > IOMEM into a domain p2m.
> 
> Indeed so, and also the backend domain might be a driver domain instead
> of the hardware domain.  It needs to have privilege over the frontend,
> but it should not need privilege over the whole system.

This can all be arranged for, I wouldn't get bugged down on this
details initially.

> > 2. What hypercall to use depends on how the memory is mapped.
> > 
> > 3. ioreq servers will already get requests for accesses to unmapped
> > regions they have registered for.  If the access is to be retried we
> > need to expand ioreq interface a bit to handle this case.  Adding a
> > new ioreq state like STATE_IORESP_RETRY might be enough?  Maybe I'm
> > being naive though.
> 
> This is where an implementation in a real userspace emulator would
> be very useful, to ensure that the API being implemented is actually
> usable in practice.

My suggestion for adding a "retry" response type to the ioreq
interface was so that your ioreq model implementation would be
simpler.  However if that's more hassle for you, I would initially map
and emulate the access, as that would also be correct and shouldn't
require any changes to the ioreq interface.  It can always be expanded
later to support a map and retry model.

AFAICT, from the ongoing discussion above, the only uncertainty is
which hypercall(s) to use to map either MMIO or RAM into a guest p2m.
I wouldn't invest a huge amount of time into prototyping something
very complex, and rather get a very simple hypercall implemented that
fits your needs.  You could likely make a frankenhypercall based on the
implementations of XEN_DOMCTL_memory_mapping and
XENMEM_add_to_physmap, so that you can get a prototype working.

I think at this point it's important to get a functional prototype, so
that we know exactly the requirements of the interfaces that you need.
I wouldn't bother to design a detailed interface until we know exactly
that such interface is suitable for your goals, and to that end we
need a prototype with whatever you can glue together.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 12 08:12:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 08:12:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980950.1367338 (Exim 4.92)
	(envelope-from )
	id 1uEOHE-0007bU-7N; Mon, 12 May 2025 08:12:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980950.1367338; Mon, 12 May 2025 08:12: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 1uEOHE-0007bN-3T; Mon, 12 May 2025 08:12:44 +0000
Received: by outflank-mailman (input) for mailman id 980950;
 Mon, 12 May 2025 08:12:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uEOHD-0007bH-9S
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 08:12:43 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uEOHC-0046GR-2R;
 Mon, 12 May 2025 08:12:42 +0000
Received: from [2a02:8012:3a1:0:e418:e534:35e5:729f]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uEOHC-00HBB7-16;
 Mon, 12 May 2025 08:12: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=wMhMM3mFYIBgz1H0tcaMRxSBgo0nSNRZ2Pqjuhy1X5U=; b=MSUAKWBosAg7rV2hHbdsReOfFX
	5MIg+/gYFffWAQHmGMOxZkiPkelE30tEYi/SAz+JpmKi01wVLlWlfJoQjvcHFBnwHZbTJwAAWhhGN
	2fcbnqrbLB8+Kh0R76h+ktrQqmGnLrWSFDI3n/20pyw4HSs6PYmp1a+ogM/xvrXp8Rqk=;
Message-ID: <97909432-2199-4d57-98bf-3aaa373a46bf@xen.org>
Date: Mon, 12 May 2025 09:12:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/bitmap: Drop unused headers
To: Andrew Cooper ,
 Xen-devel 
Cc: Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: <20250510131245.3062123-1-andrew.cooper3@citrix.com>
Content-Language: en-GB
From: Julien Grall 
In-Reply-To: <20250510131245.3062123-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Andrew,

On 10/05/2025 14:12, Andrew Cooper wrote:
> Nothing in bitmap.h uses lib.h.  Reduce to just macros.h and string.h.  Drop
> types.h while at it, as it comes in through bitops.h
> 
> cpumask.h and nodemask.h only include kernel.h to get container_of().  Move it
> into macros.h where it belongs.

The wording implies that container_of() will be moved as-is (barring 
coding style). However...

[...]

> -/**
> - * container_of - cast a member of a structure out to the containing structure
> - *
> - * @ptr:	the pointer to the member.
> - * @type:	the type of the container struct this is embedded in.
> - * @member:	the name of the member within the struct.
> - *
> - */
> -#define container_of(ptr, type, member) ({                      \
> -        typeof_field(type, member) *__mptr = (ptr);             \
> -        (type *)( (char *)__mptr - offsetof(type,member) );})
> -

I see the cast was switch from "char *" to ...

>   /**
>    * __struct_group() - Create a mirrored named and anonyomous struct
>    *
> diff --git a/xen/include/xen/macros.h b/xen/include/xen/macros.h
> index cd528fbdb127..58affb1588c5 100644
> --- a/xen/include/xen/macros.h
> +++ b/xen/include/xen/macros.h
> @@ -102,6 +102,19 @@
>    */
>   #define sizeof_field(type, member) sizeof(((type *)NULL)->member)
>   
> +/**
> + * container_of - cast a member of a structure out to the containing structure
> + *
> + * @ptr:	the pointer to the member.
> + * @type:	the type of the container struct this is embedded in.
> + * @member:	the name of the member within the struct.
> + */
> +#define container_of(ptr, type, member)                         \
> +    ({                                                          \
> +        typeof_field(type, member) *__mptr = (ptr);             \
> +        (type *)((void *)__mptr - offsetof(type, member));      \

... "void *". AFAICT, this is doesn't change anything. However, I think 
it is worth mentioning in the commit message to show this was intended.

With that:

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon May 12 08:46:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 08:46:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980960.1367346 (Exim 4.92)
	(envelope-from )
	id 1uEOnv-0003Qr-H8; Mon, 12 May 2025 08:46:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980960.1367346; Mon, 12 May 2025 08:46: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 1uEOnv-0003Qk-EH; Mon, 12 May 2025 08:46:31 +0000
Received: by outflank-mailman (input) for mailman id 980960;
 Mon, 12 May 2025 08:46:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEOnu-0003Qd-32
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 08:46:30 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 97630ad3-2f0d-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 10:46:28 +0200 (CEST)
Received: from terminus.zytor.com (terminus.zytor.com
 [IPv6:2607:7c80:54:3:0:0:0:136]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54C8jqc71586901
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Mon, 12 May 2025 01:46:02 -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" 
X-Inumbo-ID: 97630ad3-2f0d-11f0-9eb5-5ba50f476ded
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54C8jqc71586901
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747039563;
	bh=SJyp7okD30HInZ1fgTptAjmwrX1aqps8vhA1kdAJWhk=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Wqu4jU+G5jmxtcMoxZU7xxTMdvYR6zp4VYJGyttTpRKojR4aUWkuBntnRPy95mMNP
	 TdZY/WjcOubxB+VWkDSGvR2bQ2PxqfaD5oWLx5oeN+NwmwkfwQIUZulba428YPa6+d
	 a4AmbXGRcZ1fxkw8DveEBEf6vdK9sioL+MwfJHOFQAN6ndlCoGnFJkOa79chbmM/8k
	 1WrQiT23ytcFJl83Qmf/PRSdkQRCO12iTFRgpvQMjzhTN1Kupv6cOH9+fDYRg2byiA
	 tWnUdW/sgtBWnr7GH/hZQsLfWNgCHqZh3Zuo+gLz+y09m/2TX32FcNb1vZHCeyNmv1
	 7DFsocyxduIZw==
From: "Xin Li (Intel)" 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org
Cc: tglx@linutronix.de, mingo@kernel.org, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
        rafael@kernel.org, lenb@kernel.org
Subject: [PATCH v1 3/3] x86/msr: Convert a native_wrmsr() use to native_wrmsrq()
Date: Mon, 12 May 2025 01:45:52 -0700
Message-ID: <20250512084552.1586883-4-xin@zytor.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250512084552.1586883-1-xin@zytor.com>
References: <20250512084552.1586883-1-xin@zytor.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
conversions when a u64 MSR value is splitted into two u32.

Signed-off-by: Xin Li (Intel) 
---
 arch/x86/coco/sev/core.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index ff82151f7718..b3ce6fc8b62d 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -282,12 +282,7 @@ static inline u64 sev_es_rd_ghcb_msr(void)
 
 static __always_inline void sev_es_wr_ghcb_msr(u64 val)
 {
-	u32 low, high;
-
-	low  = (u32)(val);
-	high = (u32)(val >> 32);
-
-	native_wrmsr(MSR_AMD64_SEV_ES_GHCB, low, high);
+	native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, val);
 }
 
 static int vc_fetch_insn_kernel(struct es_em_ctxt *ctxt,
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 08:46:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 08:46:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980961.1367357 (Exim 4.92)
	(envelope-from )
	id 1uEOnw-0003eW-OK; Mon, 12 May 2025 08:46:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980961.1367357; Mon, 12 May 2025 08:46: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 1uEOnw-0003eP-L5; Mon, 12 May 2025 08:46:32 +0000
Received: by outflank-mailman (input) for mailman id 980961;
 Mon, 12 May 2025 08:46:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEOnw-0003Qj-2f
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 08:46:32 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 970efc9c-2f0d-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 10:46:28 +0200 (CEST)
Received: from terminus.zytor.com (terminus.zytor.com
 [IPv6:2607:7c80:54:3:0:0:0:136]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54C8jqc41586901
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Mon, 12 May 2025 01:45: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" 
X-Inumbo-ID: 970efc9c-2f0d-11f0-9ffb-bf95429c2676
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54C8jqc41586901
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747039560;
	bh=7a7DioSZkOkbzgFBLNF+1MMN8PbvCPClN1vs7CkMDT4=;
	h=From:To:Cc:Subject:Date:From;
	b=g9yE1SUIh+a4/A07fhKWcikSvZS/B1o32tMs/ljMYpKNDM5Mzs8/5CLXUUzW+O2d9
	 anFCSIGiPm6lXib7pAMPfKu9y7K6kCM65jPzDHqpFTNgaiVUrnm8LLASk4DkkPleFV
	 KXWcQs4YY0htPPFfCvcSwzJaxgP0bip3uPvcLW58ILxilulgaXhzoJ3fH7rYGNjr2W
	 Jti+nP3nWugH5PAeH7DXNtt/R17RvC/pPhDLA2a7XbxaimpeGRXO4LZHZhIhz24/d8
	 76LsC0rfGbo5S8nmx6unBRR1HHW9iyGvQiDbgcMLTqL2t+jkloEdlVTsyQg+vtg+z7
	 TwX8Nrssqf2bQ==
From: "Xin Li (Intel)" 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org
Cc: tglx@linutronix.de, mingo@kernel.org, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
        rafael@kernel.org, lenb@kernel.org
Subject: [PATCH v1 0/3] MSR fixes and cleanups after last round of MSR cleanups
Date: Mon, 12 May 2025 01:45:49 -0700
Message-ID: <20250512084552.1586883-1-xin@zytor.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

These patches:

1) remove a superfluous inclusion of  accidently added to
   drivers/acpi/processor_throttling.c in commit:

     efef7f184f2e ("x86/msr: Add explicit includes of ").

2) Fix uninitialized symbol 'err' introduced by:

     d815da84fdd0 ("x86/msr: Change the function type of native_read_msr_safe()").

3) Convert a native_wrmsr() use to native_wrmsrq() in
   arch/x86/coco/sev/core.c.


Xin Li (Intel) (3):
  x86/msr: Remove a superfluous inclusion of 
  x86/xen/msr: Fix uninitialized symbol 'err'
  x86/msr: Convert a native_wrmsr() use to native_wrmsrq()

 arch/x86/coco/sev/core.c            | 7 +------
 arch/x86/xen/enlighten_pv.c         | 5 ++++-
 drivers/acpi/processor_throttling.c | 1 -
 3 files changed, 5 insertions(+), 8 deletions(-)


base-commit: 9cf78722003178b09c409df9aafe9d79e5b9a74e
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 08:46:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 08:46:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980962.1367367 (Exim 4.92)
	(envelope-from )
	id 1uEOny-0003sO-33; Mon, 12 May 2025 08:46:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980962.1367367; Mon, 12 May 2025 08: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 1uEOnx-0003sG-W0; Mon, 12 May 2025 08:46:33 +0000
Received: by outflank-mailman (input) for mailman id 980962;
 Mon, 12 May 2025 08:46:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEOnw-0003Qj-9c
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 08:46:32 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 970edf60-2f0d-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 10:46:28 +0200 (CEST)
Received: from terminus.zytor.com (terminus.zytor.com
 [IPv6:2607:7c80:54:3:0:0:0:136]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54C8jqc51586901
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Mon, 12 May 2025 01:46:00 -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" 
X-Inumbo-ID: 970edf60-2f0d-11f0-9ffb-bf95429c2676
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54C8jqc51586901
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747039561;
	bh=irTR9cBZ/bUuJJE/VFD2XvoxgAwJuCqUqRaQbxDTnhM=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=VcTDFlAMSO7tiJedpeu3nDD6gS5DKigxV5zB3FuQKYZuCYrH0Lnq6AyaDavtFxQ+5
	 ivDulsoeXhp5fga7oMz3GqsLoQUCH7YHtAGOBPydV4CeUV1qfkYmG4WfTZ17vkHC8X
	 RH3QbWUsZGXrV8DJbo7Rs8XEeCcGNJQYuntOy9EF5GEngLsIAzmYPxRn2BDdyqkMbx
	 w3IxvetoI01oDeyxtBGKYR7xymh7giIgJSqj4+DupWNwLFA0keD5peqp4UGQ3ZbuxD
	 Id5FCpC5mxUpyYR4tLAS4sui06LZxoaL6E9/ixZj6OIz3pKprWQZgCloVU3I3ImoLP
	 o3GbZYpLKgr/g==
From: "Xin Li (Intel)" 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org
Cc: tglx@linutronix.de, mingo@kernel.org, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
        rafael@kernel.org, lenb@kernel.org
Subject: [PATCH v1 1/3] x86/msr: Remove a superfluous inclusion of 
Date: Mon, 12 May 2025 01:45:50 -0700
Message-ID: <20250512084552.1586883-2-xin@zytor.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250512084552.1586883-1-xin@zytor.com>
References: <20250512084552.1586883-1-xin@zytor.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The following commit:

  efef7f184f2e ("x86/msr: Add explicit includes of ")

added a superfluous inclusion of  to

  drivers/acpi/processor_throttling.c.

Remove it.

Signed-off-by: Xin Li (Intel) 
---
 drivers/acpi/processor_throttling.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/acpi/processor_throttling.c b/drivers/acpi/processor_throttling.c
index ecd7fe256153..d1541a386fbc 100644
--- a/drivers/acpi/processor_throttling.c
+++ b/drivers/acpi/processor_throttling.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #ifdef CONFIG_X86
 #include 
 #endif
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 08:46:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 08:46:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980965.1367377 (Exim 4.92)
	(envelope-from )
	id 1uEOo9-0004GM-Ay; Mon, 12 May 2025 08:46:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980965.1367377; Mon, 12 May 2025 08: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 1uEOo9-0004GF-6x; Mon, 12 May 2025 08:46:45 +0000
Received: by outflank-mailman (input) for mailman id 980965;
 Mon, 12 May 2025 08:46:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEOo7-0003Qj-Fz
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 08:46:43 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 970f45be-2f0d-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 10:46:28 +0200 (CEST)
Received: from terminus.zytor.com (terminus.zytor.com
 [IPv6:2607:7c80:54:3:0:0:0:136]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54C8jqc61586901
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Mon, 12 May 2025 01:46:01 -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" 
X-Inumbo-ID: 970f45be-2f0d-11f0-9ffb-bf95429c2676
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54C8jqc61586901
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747039562;
	bh=r60JlXTos4KUiP7BNV4Mubm1J2LcZX1eO8iTOKbeekU=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=bmWYvnwxTU0pVJW4u5KvyhR8cTc1ILbP2oLLV6/74QxSidvlgisrmNIxqhqDAWxKZ
	 TfRpxdQFxnaY6yhrR7m4LAqjzS1vvDMK3xmikiuu/o0qUX54thQc2j1Gjq2HQ4VNwr
	 rQKjxAF2qcQOahokDI2/tvLM1hf8YVHZ+abqqiF51/1wliz8hXeqPJdAFOMveLB42B
	 DSKDUbp1sv3q/sTl5Z8xcEzVErSlNqGYT1F1PLCScIypX4jxPqjgttEGM9q3tH7Gdv
	 i3o5hUvLakD4MvXrM6mRnnF2KzfqtpiDMAQ8pAj28Y0O3oXTU0l3ue3PDx/tGmMrY1
	 Snn6b8NY550AQ==
From: "Xin Li (Intel)" 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org
Cc: tglx@linutronix.de, mingo@kernel.org, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
        rafael@kernel.org, lenb@kernel.org
Subject: [PATCH v1 2/3] x86/xen/msr: Fix uninitialized symbol 'err'
Date: Mon, 12 May 2025 01:45:51 -0700
Message-ID: <20250512084552.1586883-3-xin@zytor.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250512084552.1586883-1-xin@zytor.com>
References: <20250512084552.1586883-1-xin@zytor.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

xen_read_msr_safe() currently passes an uninitialized argument err to
xen_do_read_msr().  But as xen_do_read_msr() may not set the argument,
xen_read_msr_safe() could return err with an unpredictable value.

To ensure correctness, initialize err to 0 (representing success)
in xen_read_msr_safe().

Because xen_read_msr_safe() is essentially a wrapper of xen_do_read_msr(),
the latter should be responsible for initializing the value of *err to 0.
Thus initialize *err to 0 in xen_do_read_msr().

Fixes: 502ad6e5a619 ("x86/msr: Change the function type of native_read_msr_safe()")
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/xen-devel/aBxNI_Q0-MhtBSZG@stanley.mountain/
Signed-off-by: Xin Li (Intel) 
---
 arch/x86/xen/enlighten_pv.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 3be38350f044..01f1d441347e 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1091,6 +1091,9 @@ static u64 xen_do_read_msr(u32 msr, int *err)
 {
 	u64 val = 0;	/* Avoid uninitialized value for safe variant. */
 
+	if (err)
+		*err = 0;
+
 	if (pmu_msr_chk_emulated(msr, &val, true))
 		return val;
 
@@ -1162,7 +1165,7 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err)
 
 static int xen_read_msr_safe(u32 msr, u64 *val)
 {
-	int err;
+	int err = 0;
 
 	*val = xen_do_read_msr(msr, &err);
 	return err;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 08:51:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 08:51:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.980999.1367387 (Exim 4.92)
	(envelope-from )
	id 1uEOsl-0006os-S7; Mon, 12 May 2025 08:51:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 980999.1367387; Mon, 12 May 2025 08: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 1uEOsl-0006ol-Oz; Mon, 12 May 2025 08:51:31 +0000
Received: by outflank-mailman (input) for mailman id 980999;
 Mon, 12 May 2025 08:51:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEOsj-0006of-QW
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 08:51:29 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4b2ed8bf-2f0e-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 10:51:28 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a0b6aa08e5so3203546f8f.1
 for ; Mon, 12 May 2025 01:51:28 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a1f57ddde0sm11948406f8f.14.2025.05.12.01.51.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 01: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" 
X-Inumbo-ID: 4b2ed8bf-2f0e-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747039888; x=1747644688; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=w+8VsMx1A6PALaLwxoqX9exAOB+OCjVIV9AcXHRBbsk=;
        b=MoUVrKQDx1sC+R1T18+hbvtWuwVi6aJDEwdiL89gyVNzOFJLeEc1X8EvrNSrhz/LAO
         EvSiYzvKLvlhafzXwQT8Dgth2jEGgsjdwd6pXc93/p/Qij+I3tvQr/xPahwGyWvHk1Dx
         rZBZ9iQgsOZX7A9b6+kl4My/2FO8WRY8tHy7I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747039888; x=1747644688;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=w+8VsMx1A6PALaLwxoqX9exAOB+OCjVIV9AcXHRBbsk=;
        b=TxROqL5EqUbR+Nt1sMs8nJS/KmcPTnkugx9MUytAcoKwngm35pTZMZp6Pn7irRkrT0
         mC43+pjJuKnLXinb9DVp86r2aCeaA28Enw1bv4XEGFftB+nWCuHd26mXHQ1SvDA7vQ0u
         nVVfRnRFOnZyJrWlo3x6YzMvyVu9LAw/ADWhOEFJw3Lok6MnVz77fY4mvts09FL2rP70
         R13Wr6ctCfrEZHJ+xhFKDDt+CHc3Zl5sNPWxtCe8/gcCyt/zglwVPf5HHKAxHoI6novV
         HsVmnaq1e5rfSca41Nbto8I7DQX3SwykpNaANzmWPcRZ+0PqL4TQiENrprniQ+SzuKq+
         +sNw==
X-Forwarded-Encrypted: i=1; AJvYcCVzi0rvN5CBscSpO67kSXImjlbT9ZRKdhWLV7iQGEgueC+JJCo/wT/sBGXv3BHdESSjA7pllCzXP0o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwogYN3+Okp3hA8TVZn4RjD8SeWDs+g13EMsxKGS0SpJ4kY9vBd
	EJEFwKwwQJn0gM54iDlk3RaXhwR/uWRW2sv/EvncYxpe/UJPMQRfdzbz3NLfpMY=
X-Gm-Gg: ASbGncvfVLfMj7y7zHyWqbvgzZdmi0tbpk9vvO2Yc6SDatI0hD9HMlLJ11LANlf1rVV
	qAw3qIYT/57IPoQl3NxbeYbHVFfaWamKXJTj+yHGmQPNn42ThnwKbiDRlpLRpRG1HevXtdl7IiW
	Loonn9oldtdu8AgwNXq+u61sCvyfLs6IQSq5DMgKRI/eNXqtex04DvnI4JHmjQTNZh9FuvJ3QSp
	3B++e4pZqey7yvZ07IGpZoDq/HvofTEzXZ9ZSSgbQUsL3DJbg6QvOl1PJJUgEskyYZxCsWrFWYq
	JYzDZBz7paSco4ntbPnY9SMV/lJhEJvn55/2+7oSr7B8ZmlO3C/iplvRoL6rbxQo+Yw=
X-Google-Smtp-Source: AGHT+IGduMx3R+abJ2DJo81rdfNiZyuT7A/Y5aChpgG8psm5aFomnhQNNJEehNSdhkau3DWplYEhHg==
X-Received: by 2002:a05:6000:2cd:b0:3a0:8020:8aed with SMTP id ffacd0b85a97d-3a1f6c9c3bbmr10213741f8f.21.1747039888051;
        Mon, 12 May 2025 01:51:28 -0700 (PDT)
Date: Mon, 12 May 2025 10:51:26 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stefano Stabellini 
Cc: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	Jan Beulich ,
	"Ragiadakou, Xenia" ,
	Andrew Cooper , jason.andryuk@amd.com,
	agarciav@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
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 Fri, May 09, 2025 at 02:10:03PM -0700, Stefano Stabellini wrote:
> On Fri, 9 May 2025, Roger Pau Monné wrote:
> > On Thu, May 08, 2025 at 04:25:28PM -0700, Stefano Stabellini wrote:
> > > On Thu, 8 May 2025, Roger Pau Monné wrote:
> > > > On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
> > > > > On Tue, 6 May 2025, Roger Pau Monné wrote:
> > > > > > On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
> > > > > > > In my opinion, we definitely need a solution like this patch for Dom0
> > > > > > > PVH to function correctly in all scenarios.
> > > > > > 
> > > > > > I'm not opposed to having such interface available for PVH hardware
> > > > > > domains.  I find it ugly, but I don't see much other way to deal with
> > > > > > those kind of "devices".  Xen mediating accesses for each one of them
> > > > > > is unlikely to be doable.
> > > > > > 
> > > > > > How do you hook this exchange interface into Linux to differentiate
> > > > > > which drivers need to use mfns when interacting with the hardware?
> > > > > 
> > > > > In the specific case we have at hands the driver is in Linux userspace
> > > > > and is specially-written for our use case. It is not generic, so we
> > > > > don't have this problem. But your question is valid.
> > > > 
> > > > Oh, so you then have some kind of ioctl interface that does the memory
> > > > exchange and bouncing inside of the kernel on behalf of the user-space
> > > > side I would think?
> > > 
> > > I am not sure... Xenia might know more than me here.
> > 
> > One further question I have regarding this approach: have you
> > considered just populating an empty p2m space with contiguous physical
> > memory instead of exchanging an existing area?  That would increase
> > dom0 memory usage, but would prevent super page shattering in the p2m.
> > You could use a dom0_mem=X,max:X+Y command line option, where Y
> > would be your extra room for swiotlb-xen bouncing usage.
> > 
> > XENMEM_increase_reservation documentation notes such hypercall already
> > returns the base MFN of the allocated page (see comment in
> > xen_memory_reservation struct declaration).
>  
> XENMEM_exchange is the way it has been implemented traditionally in
> Linux swiotlb-xen (it has been years). But your idea is good.
> 
> Another, more drastic, idea would be to attempt to map Dom0 PVH memory
> 1:1 at domain creation time like we do on ARM. If not all of it, as much
> as possible. That would resolve the problem very efficiently. We could
> communicate to Dom0 PVH the range that is 1:1 in one of the initial data
> structures, and that would be the end of it.

Yes, I wonder however whether attempting this would result in a
fair amount of page-shattering if we need to cater for pages in-use by
Xen that cannot be identity mapped.

Maybe a middle ground: on the Xen command line the admin specifies
the amount of contiguous identity mapped memory required, and Xen
attempts to allocate and identity map it on dom0 p2m?

It would be nice to signal such regions on the memory map itself.
Sadly I don't see a way to do it using the UEFI memory map format.
There's a "EFI_MEMORY_ISA_MASK" region in the attribute field, but I
don't think we can hijack this for Xen purposes.  There's also a 32bit
padding field in EFI_MEMORY_DESCRIPTOR after the type field, but using
that is possibly risky going forward?  I don't think UEFI can
repurpose that padding easily, but we might not want to bet on that.

We also have the need to signal which regions are safe to use as
foreign/grant mapping scratch space, so it would be good to use an
interface that can be expanded.  IOW: have a way to add extra Xen
specific attributes to memory regions.

Anyway, for the patch at hand: I see no reason to prevent
XENMEM_exchange usage. I think it's maybe not the best option because
of the super-page shattering consequences, but I assume you already
have a working solution based on this.

> > > > > In Linux, the issue is hidden behind drivers/xen/swiotlb-xen.c and
> > > > > xen_arch_need_swiotlb. There are a few options:
> > > > > - force swiotlb bounce for everything on the problematic SoC
> > > > > - edit xen_arch_need_swiotlb to return true for the problematic device
> > > > > - introduce a kernel command line option to specify which device
> > > > >   xen_arch_need_swiotlb should return true for
> > > > 
> > > > Isn't it a bit misleading to use the swiotlb for this purpose?  Won't
> > > > this usage of the swiotlb (to bounce from gfns to mfns) create issues
> > > > if there's any devices that have a DMA physical address limitation and
> > > > also needs to use the swiotlb while being behind the IOMMU?
> > > 
> > > When I wrote swiotlb, I meant swiotlb-xen (drivers/xen/swiotlb-xen.c).
> > > We have been using it exactly for this kind of address translations so
> > > far. It can also deal with cases where genuine bouncing needs to happen.
> > 
> > Oh, I see.  I've assumed you meant the generic Linux swiotlb.
> > 
> > So you have repurposed swiotlb-xen to be used on PVH for this purpose.
> > I think (currently?) swiotlb-xen is unconditionally disabled for
> > HVM/PVH guests?
> 
> Yes, I have repurposed swiotlb-xen for something similar this years ago
> on ARM. I was planning to do the same for PVH x86. Today, swiotlb-xen is
> used for ARM Dom0, which as you know is HVM/PVH from Linux point of view.

Sounds good, no objection from my side.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 12 08:54:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 08:54:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981009.1367397 (Exim 4.92)
	(envelope-from )
	id 1uEOw1-0007MB-9B; Mon, 12 May 2025 08:54:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981009.1367397; Mon, 12 May 2025 08: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 1uEOw1-0007M4-6E; Mon, 12 May 2025 08:54:53 +0000
Received: by outflank-mailman (input) for mailman id 981009;
 Mon, 12 May 2025 08:54:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEOw0-0007Ly-OQ
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 08:54:52 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c4441a32-2f0e-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 10:54:51 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5fbeadf2275so7242212a12.2
 for ; Mon, 12 May 2025 01:54: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
 4fb4d7f45d1cf-5fc9d700e92sm5362880a12.55.2025.05.12.01.54.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 01:54: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" 
X-Inumbo-ID: c4441a32-2f0e-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747040091; x=1747644891; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=+ryrX3zt0PUxJueZ1oYUQ6/2efPjKt5e/3zSd0pUc2I=;
        b=d8p8cdN2+7jfe3OUIR0L8VzP/217Np3CdG3QVDty2/4+nhJY4HiyIK/zJsg/n757oO
         qGPIwJ0GjxjX19Km1OoTicWMBmx7otRzEpzaKCgY4tDfnSAXpDDT+XWeTrTSWBWz8W1/
         1eRh2ryz/kyiYN0e/F0gvWC2/FemrhE0EQXoe+bhSfJHdTg2XLU7crTtE2cps/pffaEK
         FXnlXH3hlBFamZEoXYXaxMacPpsT2xn9X47ZOnAHw0qPUW2KS1qg1N1OqiqPHOlyh1pf
         1/sx8XOOWmEQJdI3pG4i4miCj2VEuSyz8uxYFo51tLZsYcRFJteng+7JAmxobTmPPz6n
         JOnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747040091; x=1747644891;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=+ryrX3zt0PUxJueZ1oYUQ6/2efPjKt5e/3zSd0pUc2I=;
        b=CewnvNgDE5fZlonYi8QL582E8k2iobtVqt8V+RAEBHMC4yY18l052bZKz3C+Sc8jpk
         WmH/NmuSmx/aFLGLwejE7O9OD8niWzBabpZ2VZ4bHw9+h7Ua0DA35pnsh8sP+XJxNm1l
         qZ6+BQ+A40geJHU510Yx7dJCkFKH0hXNfodDo2zA3MS9oO44L2jfQqiptas1pOhuGM3O
         q+8kH55qVHbgC4y9Fbp1O86uUzK2cxZQRNBKlVQjeSO+Tprbh3Anlbp4FUDmijo8Rszl
         d7Ia+wwgX1xTTBCqX5f7yFJeoDVmjyhYNI7RESIdgeGWAkKToOV1K2lQVPbc92doa5wp
         K43g==
X-Gm-Message-State: AOJu0YzMC3Qy0syis8vhfFTqcwW1seDLeC9QDc3y4dVcwflHNeub8jtO
	g60AyqZjJcA28B1n6OK+JYHoheTEPQf+WHQ2HX0W+9vYMVygFWqMUbROkYRkyIY2swikj58TW6k
	=
X-Gm-Gg: ASbGncvllnYx2rdDvz8odIdkxYiAB8cC9FTLPRqSX4APP+JE3uqonugg/Y6hHI4MoDr
	w29ribwzMUH7rIqh/nioL5GLFSjuIozLKq35O7cz464XCXLasaw1BVKQBcDYoFJfWKk62AWBtZ9
	sUGF3Ui6hSCAgTG+hxO7j5WVjaGo0wTUiPJq5ofJElgYhrr44DIQyXPAOjBK0TSb8rznUiFx09m
	PupBQyT9HsWp++1Lg59Deu/VJcW04pBCtXYCEtxJIQDh6Uqd72rZNOLH6XrkDVHLo1KODU4xhDS
	N/23ltbKOKWd2yaPZxn+l0HXoyEYU8ueR4ypOGJrggt+UbsNKXjkAwVdxLU2BWpdfgepmKqIogL
	2zVPBRvmHKh1Z++QaaUUgHNhSDBJkFCuLw3D0L0KlHwzRQZo=
X-Google-Smtp-Source: AGHT+IG+9WV8lTzbX9x3V9RdTH8qyM7DZ+6BR+Ti9FGRjanhdWwBb0mHuShZ9dGDNaW2gsDtu+w8gw==
X-Received: by 2002:a05:6402:90c:b0:5fb:868b:5a59 with SMTP id 4fb4d7f45d1cf-5fca081b48dmr10712644a12.32.1747040091313;
        Mon, 12 May 2025 01:54:51 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 10:54:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Request for patch to fix boot loop issue in Xen 4.17.6
To: Ngamia Djabiri Julie 
References: 
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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.05.2025 16:02, Ngamia Djabiri Julie wrote:
> Dear Xen developers,
> 
> I would like to ask if the following fix can also be included in Xen 4.17.6 (and eventually in the Xen versions after 4.17.6 that don't have the fix) :
> 
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=dd05d265b8abda4cc7206b29cd71b77fb46658bf
> 
> This bug causes a boot loop in nested virtualization environments (for instance nested environments that use VMware Workstation), making Xen unable to start. It was introduced in version 4.17.3 and the fix has already be included in 4.19(.2) and 4.20(.0) and woud be planned to be included in Xen 4.18.6 in the coming weeks.
> 
> Even though Xen 4.17 is in security-only support, this is an issue that blocks testing and usage for users and projects such as Alpine Linux.

I fear I don't view this severe enough an issue to break the security-only
status of that branch. People concerned ought to simply update to a branch
where the bug was fixed. Or the distro could include a backport.

The underlying consideration being that once we start making exceptions,
more exceptions will be asked for, along the lines of ...

> I am a student using Xen in a nested setup for Virtal Machine Introspection (VMI), and including this fix in 4.17.6 would really help avoid these problems for others in a similar case.

... what you say here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 09:02:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 09:02:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981018.1367407 (Exim 4.92)
	(envelope-from )
	id 1uEP3F-0000sb-2p; Mon, 12 May 2025 09:02:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981018.1367407; Mon, 12 May 2025 09: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 1uEP3E-0000sU-Ux; Mon, 12 May 2025 09:02:20 +0000
Received: by outflank-mailman (input) for mailman id 981018;
 Mon, 12 May 2025 09:02:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEP3D-0000sO-S5
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 09:02:20 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cdde3c0b-2f0f-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 11:02:17 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5fc7edf00b2so5767330a12.2
 for ; Mon, 12 May 2025 02:02:17 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5fd29adb7absm2045572a12.32.2025.05.12.02.02.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 02:02: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" 
X-Inumbo-ID: cdde3c0b-2f0f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747040536; x=1747645336; 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;
        bh=yN5yu45Sx9N3uJwjmW+3tVTSQQfJPYLSsmcXKIDbcxo=;
        b=fB7gl9sO+W5PBHEbhDRxnWsjiKctW7AtOe2RKH1o5AiRk3B49Ixmxp+gq9c+yrzh5E
         RYpf8KnLRAAB6TJx6w/q1e5xJ348IqPRDCEdXKkphG9gQOnViYGl+Yn9Gtw9c5BT+dyp
         C96QVJ2r2G+ytDmHOQ1rd7qj/gDex+VZNv1Rk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747040536; x=1747645336;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=yN5yu45Sx9N3uJwjmW+3tVTSQQfJPYLSsmcXKIDbcxo=;
        b=izDDaR4sJUEi4qZucgHryBxbL8u+TXNCSRyiF6kGg8pJOURNR2tEkOca5LdS6bexPS
         M10bDU1i6i6dcHi5Hq0giOCK0rv4yJlAKK8d4qgBSvcO/njeEmDhNvwoHpe3dJCBBHuh
         RXvDgvu9uqiPzXJ/x7ra+a6dDnG5uKCDPAZaJjIj8xWoaMNgWlOo3QN+YAs23oqD9TjA
         i93RbllRZIJ527AXxY5CKRvXMLlQhKqWk7T3b/ni3W8kTdJiSi+Js0t9LywX0X6e4EwP
         YOI71F5GxGQJbWru7INadslSdoM8WCM0aBJ2+waCGUo8hC59Y4fjEx1ZHhLTQjmuwihz
         /1EQ==
X-Gm-Message-State: AOJu0Yyk9A23YU/pi1jcOwtWlcDU8rAL1CNY2j3PVjNK0iqOTQpFJEMb
	WzU7U7ODEh4S8rWpHsbc2a9/aH1Rr2HbJ8Riog4CPZC3mFbbSiyZPEDHMDoUdc0FhHZ5Eby4Fd+
	n
X-Gm-Gg: ASbGncsbl5VuLvnMCIe/64ExejB0BfqzPUky494wAggH+SMnUveyYpSZMasgK7TbIp1
	vS5UbmPWaaEBbFhvXz91tUxwUbwnQzfo28vbP3msoBU9BfX0/t1XnyL1RC+tD0Bb2UHxPoMRo/O
	TXjE+30lE3IwU5EV+oH8y2WXqZofI0SwdkC8dcwxjNm1DSbzTuFOcuL5o3WE0k5TYVx1O5GUwYk
	F/Wik32Ru/67KEoD8jJxyK5UzRMop2f06J6VDPBKVSeSsj1N9kq7ODuUTJt8iqIElafCQiupPut
	bEm6Ue4Tf6nnKC/KwJfZdiYRucDLUxQYl2bf7KPSQRiIdIwM27qpGBSs1Hmhhpk6e6re
X-Google-Smtp-Source: AGHT+IHheQsadyUnmBbj8VlxVQDotIbnDc7IA4/FSfP1/UuHVX9zu/D/VHNsfbg+zTTEsQ0mbELPrA==
X-Received: by 2002:a05:6402:2115:b0:5fd:1c90:e5d5 with SMTP id 4fb4d7f45d1cf-5fd1c90e7a1mr5359213a12.20.1747040535994;
        Mon, 12 May 2025 02:02:15 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: Kevin Lampis 
Subject: [PATCH 4/4] Disallow most command-line options when lockdown mode is enabled
Date: Mon, 12 May 2025 10:02:10 +0100
Message-ID: <20250512090210.1718623-1-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
In-Reply-To: <20250506162347.1676357-1-kevin.lampis@cloud.com>
References: <20250506162347.1676357-1-kevin.lampis@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

A subset of command-line parameters that are specifically safe to use
when lockdown mode is enabled are annotated as such.

Signed-off-by: Kevin Lampis 
---
 xen/arch/arm/domain_build.c           |  4 +--
 xen/arch/x86/acpi/cpu_idle.c          |  2 +-
 xen/arch/x86/cpu/amd.c                |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c         |  2 +-
 xen/arch/x86/cpu/microcode/core.c     |  2 +-
 xen/arch/x86/dom0_build.c             |  4 +--
 xen/arch/x86/hvm/hvm.c                |  2 +-
 xen/arch/x86/irq.c                    |  2 +-
 xen/arch/x86/nmi.c                    |  2 +-
 xen/arch/x86/setup.c                  |  2 +-
 xen/arch/x86/traps.c                  |  2 +-
 xen/arch/x86/x86_64/mmconfig-shared.c |  2 +-
 xen/common/domain.c                   |  2 +-
 xen/common/kernel.c                   | 10 +++++-
 xen/common/kexec.c                    |  2 +-
 xen/common/numa.c                     |  2 +-
 xen/common/page_alloc.c               |  2 +-
 xen/common/shutdown.c                 |  2 +-
 xen/drivers/char/console.c            |  2 +-
 xen/drivers/char/ns16550.c            |  4 +--
 xen/drivers/video/vga.c               |  2 +-
 xen/include/xen/param.h               | 49 +++++++++++++++++++++------
 22 files changed, 70 insertions(+), 35 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index df29619c40..8ff1af3787 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -41,7 +41,7 @@
 #include 
 
 static unsigned int __initdata opt_dom0_max_vcpus;
-integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+integer_secure_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 /*
  * If true, the extended regions support is enabled for dom0 and
@@ -61,7 +61,7 @@ static int __init parse_dom0_mem(const char *s)
 
     return *s ? -EINVAL : 0;
 }
-custom_param("dom0_mem", parse_dom0_mem);
+custom_secure_param("dom0_mem", parse_dom0_mem);
 
 int __init parse_arch_dom0_param(const char *s, const char *e)
 {
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 1dbf15b01e..431fd0c997 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -113,7 +113,7 @@ static int __init cf_check parse_cstate(const char *s)
         max_csubstate = simple_strtoul(s + 1, NULL, 0);
     return 0;
 }
-custom_param("max_cstate", parse_cstate);
+custom_secure_param("max_cstate", parse_cstate);
 
 static bool __read_mostly local_apic_timer_c2_ok;
 boolean_param("lapic_timer_c2_ok", local_apic_timer_c2_ok);
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 37d67dd15c..c36351c968 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -47,7 +47,7 @@ integer_param("cpuid_mask_thermal_ecx", opt_cpuid_mask_thermal_ecx);
 
 /* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */
 int8_t __read_mostly opt_allow_unsafe;
-boolean_param("allow_unsafe", opt_allow_unsafe);
+boolean_secure_param("allow_unsafe", opt_allow_unsafe);
 
 /* Signal whether the ACPI C1E quirk is required. */
 bool __read_mostly amd_acpi_c1e_quirk;
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 1c348e557d..a229af6fd3 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -31,7 +31,7 @@
 #include "vmce.h"
 
 bool __read_mostly opt_mce = true;
-boolean_param("mce", opt_mce);
+boolean_secure_param("mce", opt_mce);
 bool __read_mostly mce_broadcast;
 bool is_mc_panic;
 DEFINE_PER_CPU_READ_MOSTLY(unsigned int, nr_mce_banks);
diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 34a94cd25b..b5b7304ae7 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -160,7 +160,7 @@ static int __init cf_check parse_ucode(const char *s)
 
     return rc;
 }
-custom_param("ucode", parse_ucode);
+custom_secure_param("ucode", parse_ucode);
 
 static struct microcode_ops __ro_after_init ucode_ops;
 
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0b467fd4a4..6d42acb661 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -142,7 +142,7 @@ static int __init cf_check parse_dom0_mem(const char *s)
 
     return s[-1] ? -EINVAL : ret;
 }
-custom_param("dom0_mem", parse_dom0_mem);
+custom_secure_param("dom0_mem", parse_dom0_mem);
 
 static unsigned int __initdata opt_dom0_max_vcpus_min = 1;
 static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX;
@@ -164,7 +164,7 @@ static int __init cf_check parse_dom0_max_vcpus(const char *s)
 
     return *s ? -EINVAL : 0;
 }
-custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
+custom_secure_param("dom0_max_vcpus", parse_dom0_max_vcpus);
 
 static __initdata unsigned int dom0_nr_pxms;
 static __initdata unsigned int dom0_pxms[MAX_NUMNODES] =
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4cb2e13046..97afb274fe 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -87,7 +87,7 @@ unsigned long __section(".bss.page_aligned") __aligned(PAGE_SIZE)
 
 /* Xen command-line option to enable HAP */
 static bool __initdata opt_hap_enabled = true;
-boolean_param("hap", opt_hap_enabled);
+boolean_secure_param("hap", opt_hap_enabled);
 
 #ifndef opt_hvm_fep
 /* Permit use of the Forced Emulation Prefix in HVM guests */
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 38ac0823d7..453bdb9910 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -34,7 +34,7 @@
 
 /* opt_noirqbalance: If true, software IRQ balancing/affinity is disabled. */
 bool __read_mostly opt_noirqbalance;
-boolean_param("noirqbalance", opt_noirqbalance);
+boolean_secure_param("noirqbalance", opt_noirqbalance);
 
 unsigned int __read_mostly nr_irqs_gsi = NR_ISA_IRQS;
 unsigned int __read_mostly nr_irqs;
diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 9793fa2316..3735f22e88 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -73,7 +73,7 @@ static int __init cf_check parse_watchdog(const char *s)
 
     return 0;
 }
-custom_param("watchdog", parse_watchdog);
+custom_secure_param("watchdog", parse_watchdog);
 
 /* opt_watchdog_timeout: Number of seconds to wait before panic. */
 static unsigned int opt_watchdog_timeout = 5;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 276957c4ed..1018cdb771 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -70,7 +70,7 @@
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool __initdata opt_nosmp;
-boolean_param("nosmp", opt_nosmp);
+boolean_secure_param("nosmp", opt_nosmp);
 
 /* maxcpus: maximum number of CPUs to activate. */
 static unsigned int __initdata max_cpus;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 25e0d5777e..1af67d2256 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -86,7 +86,7 @@ static char __read_mostly opt_nmi[10] = "dom0";
 #else
 static char __read_mostly opt_nmi[10] = "fatal";
 #endif
-string_param("nmi", opt_nmi);
+string_secure_param("nmi", opt_nmi);
 
 DEFINE_PER_CPU(uint64_t, efer);
 static DEFINE_PER_CPU(unsigned long, last_extable_addr);
diff --git a/xen/arch/x86/x86_64/mmconfig-shared.c b/xen/arch/x86/x86_64/mmconfig-shared.c
index f1a3d42c5b..80cdca7d77 100644
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -60,7 +60,7 @@ static int __init cf_check parse_mmcfg(const char *s)
 
     return rc;
 }
-custom_param("mmcfg", parse_mmcfg);
+custom_secure_param("mmcfg", parse_mmcfg);
 
 static const char *__init cf_check pci_mmcfg_e7520(void)
 {
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..c95988c067 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -55,7 +55,7 @@ unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
 
 /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */
 bool opt_dom0_vcpus_pin;
-boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
+boolean_secure_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
 
 /* Protect updates/reads (resp.) of domain_list and domain_hash. */
 DEFINE_SPINLOCK(domlist_update_lock);
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 6658db9514..eaa509f317 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -135,9 +137,15 @@ static int parse_params(const char *cmdline, const struct kernel_param *start,
                 }
                 continue;
             }
+            found = true;
+
+            if ( !param->is_lockdown_safe && is_locked_down() )
+            {
+              printk("Ignoring unsafe cmdline option %s in lockdown mode\n", param->name);
+              break;
+            }
 
             rctmp = 0;
-            found = true;
             switch ( param->type )
             {
             case OPT_STR:
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 84fe8c3597..790839657d 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -189,7 +189,7 @@ static int __init cf_check parse_crashkernel(const char *str)
 
     return rc;
 }
-custom_param("crashkernel", parse_crashkernel);
+custom_secure_param("crashkernel", parse_crashkernel);
 
 /* Parse command lines in the format:
  *
diff --git a/xen/common/numa.c b/xen/common/numa.c
index ad75955a16..c4981f2ff1 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -687,7 +687,7 @@ static int __init cf_check numa_setup(const char *opt)
 
     return 0;
 }
-custom_param("numa", numa_setup);
+custom_secure_param("numa", numa_setup);
 
 static void cf_check dump_numa(unsigned char key)
 {
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index bd4538c28d..5f26e242c2 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -235,7 +235,7 @@ static int __init cf_check parse_bootscrub_param(const char *s)
 
     return 0;
 }
-custom_param("bootscrub", parse_bootscrub_param);
+custom_secure_param("bootscrub", parse_bootscrub_param);
 
 /*
  * bootscrub_chunk -> Amount of bytes to scrub lockstep on non-SMT CPUs
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index c47341b977..231de1454a 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -13,7 +13,7 @@
 
 /* opt_noreboot: If true, machine will need manual reset on error. */
 bool __ro_after_init opt_noreboot;
-boolean_param("noreboot", opt_noreboot);
+boolean_secure_param("noreboot", opt_noreboot);
 
 static void noreturn reboot_or_halt(void)
 {
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c3150fbdb7..45a35903fe 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -43,7 +43,7 @@
 
 /* console: comma-separated list of console outputs. */
 static char __initdata opt_console[30] = OPT_CONSOLE_STR;
-string_param("console", opt_console);
+string_secure_param("console", opt_console);
 
 /* conswitch: a character pair controlling console switching. */
 /* Char 1: CTRL+ is used to switch console input between Xen and DOM0 */
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index eaeb0e09d0..fae509cbd8 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1390,8 +1390,8 @@ static void enable_exar_enhanced_bits(const struct ns16550 *uart)
  */
 static char __initdata opt_com1[128] = "";
 static char __initdata opt_com2[128] = "";
-string_param("com1", opt_com1);
-string_param("com2", opt_com2);
+string_secure_param("com1", opt_com1);
+string_secure_param("com2", opt_com2);
 
 enum serial_param_type {
     baud_rate,
diff --git a/xen/drivers/video/vga.c b/xen/drivers/video/vga.c
index b577b24619..abc6e56aa3 100644
--- a/xen/drivers/video/vga.c
+++ b/xen/drivers/video/vga.c
@@ -48,7 +48,7 @@ void (*video_puts)(const char *s, size_t nr) = vga_noop_puts;
  * control of the console to domain 0.
  */
 static char __initdata opt_vga[30] = "";
-string_param("vga", opt_vga);
+string_secure_param("vga", opt_vga);
 
 /* VGA text-mode definitions. */
 static unsigned int columns, lines;
diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h
index 1bdbab34ab..31e7326d88 100644
--- a/xen/include/xen/param.h
+++ b/xen/include/xen/param.h
@@ -25,6 +25,7 @@ struct kernel_param {
         void *var;
         int (*func)(const char *s);
     } par;
+    bool is_lockdown_safe;
 };
 
 /* Maximum length of a single parameter string. */
@@ -44,46 +45,72 @@ extern const struct kernel_param __setup_start[], __setup_end[];
 #define _TEMP_NAME(base, line) __TEMP_NAME(base, line)
 #define TEMP_NAME(base) _TEMP_NAME(base, __LINE__)
 
-#define custom_param(_name, _var) \
+#define custom_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_CUSTOM, \
-          .par.func = (_var) }
-#define boolean_param(_name, _var) \
+          .par.func = (_var), \
+          .is_lockdown_safe = (_sec) }
+#define custom_param(_name, _var) \
+    custom_param_(_name, _var, false)
+#define custom_secure_param(_name, _var) \
+    custom_param_(_name, _var, true)
+#define boolean_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_BOOL, \
           .len = sizeof(_var) + \
                  BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
-          .par.var = &(_var) }
-#define integer_param(_name, _var) \
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define boolean_param(_name, _var) \
+    boolean_param_(_name, _var, false)
+#define boolean_secure_param(_name, _var) \
+    boolean_param_(_name, _var, true)
+#define integer_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_UINT, \
           .len = sizeof(_var), \
-          .par.var = &(_var) }
-#define size_param(_name, _var) \
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define integer_param(_name, _var) \
+    integer_param_(_name, _var, false)
+#define integer_secure_param(_name, _var) \
+    integer_param_(_name, _var, true)
+#define size_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_SIZE, \
           .len = sizeof(_var), \
-          .par.var = &(_var) }
-#define string_param(_name, _var) \
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define size_param(_name, _var) \
+    size_param_(_name, _var, false)
+#define size_secure_param(_name, _var) \
+    size_param_(_name, _var, true)
+#define string_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_STR, \
           .len = sizeof(_var), \
-          .par.var = &(_var) }
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define string_param(_name, _var) \
+  string_param_(_name, _var, false)
+#define string_secure_param(_name, _var) \
+  string_param_(_name, _var, true)
 #define ignore_param(_name)                 \
     __setup_str TEMP_NAME(__setup_str_ign)[] = (_name);  \
     __kparam TEMP_NAME(__setup_ign) =                    \
         { .name = TEMP_NAME(__setup_str_ign),            \
-          .type = OPT_IGNORE }
+          .type = OPT_IGNORE,                            \
+          .is_lockdown_safe = true }
 
 #ifdef CONFIG_HYPFS
 
-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 09:14:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 09:14:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981031.1367416 (Exim 4.92)
	(envelope-from )
	id 1uEPEd-0002qh-45; Mon, 12 May 2025 09:14:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981031.1367416; Mon, 12 May 2025 09:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEPEd-0002qa-1X; Mon, 12 May 2025 09:14:07 +0000
Received: by outflank-mailman (input) for mailman id 981031;
 Mon, 12 May 2025 09:14:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEPEb-0002qU-J4
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 09:14:05 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 730f128c-2f11-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 11:14:04 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5f7ec0e4978so94407a12.1
 for ; Mon, 12 May 2025 02:14: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
 4fb4d7f45d1cf-5fe943484e6sm876934a12.24.2025.05.12.02.14.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 02:14: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" 
X-Inumbo-ID: 730f128c-2f11-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747041243; x=1747646043; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4c1GrDbSXgB72qeN8UrJP66xKQdIF/Qr+phQ+gqlv0k=;
        b=ctVenXGvL4/B2i2voFpbdBJPk+oHtczgBwRHEtUNFAgagGiRKhJQGtxCGmrR/TcGDz
         pNcfkFQ4oE/dDpgqwidsD7tDqctcQ1XQ3kLe2bwMkzXxtb1AUiElXIZnZozRoMXAQOdZ
         k5W3H8p2HGwy2LofbflkvB2ngsupZSLDHQ2pvc5J9adjKOt8UHNMMrTmqysjr1x7ZJHx
         3gGG3yIr2RMZCxjtcQARopm2Ekh1fkFoY0mZpFg5P33FkkIdFLiJzekyEfidP1/DEGz/
         v3fkrij1ItAFdKfZhsSrunDRonu6AdvoqMWoCh8T0IewLk0lPr14t/nNYeRGPuPuuh1i
         ydPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747041243; x=1747646043;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4c1GrDbSXgB72qeN8UrJP66xKQdIF/Qr+phQ+gqlv0k=;
        b=qfOevqlwiN9T2XSqayy/uue2sQya8679aLIDjEBzvmH97uo9Cm8x3nMK4uv/HLXQjP
         QMFb4bY5E+9e/FLnwBCeEnUnrgUWKgFxucHjnV+gMqVOtSXF34CLi8Obv7OBO+O/KtFl
         NZ5b9wjIgzQZQHyssZ+YI8TAcsBjQ8NwsyTDFxrwElhpqpkv1XuccBM7yZAx7Cl22aX2
         WBx+AjGFIWJFiTxtpd7/5sqq/AFxhES48OQ6ultStrJCS4G+a73AUFrTHWDVl8VCMTQ8
         hpgoRtD+m/CIFYRuDqujUd85qaMyhDgW/2XUwU1LkCn3UaGu9MLc6UDbCptUS675Lw35
         KFGQ==
X-Forwarded-Encrypted: i=1; AJvYcCXLNEF+MJVjBI/pwjSKEhrW9YuDrW/iYPKoGraSOodPxl8U+znFdGylaRWOegdIFXxVk23k2ClnFvA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywu2BO0JiHtU2o5G5+OZBfr7o2J06Wkqn3A2N8G58G6EjCsqOB/
	EqiBiS6lJW09FP/ulTHYH4aVnhxfyQvuizr/94h9dnS2NDsDMvuEHibigNUJGQ==
X-Gm-Gg: ASbGncuSfqOMAAs0BEBr5lW1ajkqJTs3Qt+p8GCdOLhgpAMtBU2rQ+fO8dePXyt9mNL
	V6UEfX44kNfvE/zJhIsMl3gvY8lIs+XKGT0JgOm5CTl7tH6eGH7AqlYzt7GShjjXAhC7U4Ww0vG
	R0yJCZ3FK3BbsfRZgc0U2U9yoeI9ECq4EaqVgrA3KE+YVDgILPUdoUbxMP/y/LKbOT6Z/lobHTj
	MFNHNuEZsT2BVmmB+VdaUuIqW02b8YCD4V96+380p7kfLmErBLHLUNK5ago8pMZhC/a4IA3g2p7
	bYyJhtfsGqM9Ch4E/44LomC3KyElK0e3GyQCeLJbMBW0kwCgzWELhj/xOZEuT/rgXdIR437CmuX
	GdKW/iQe+Tg8s8cv5TlgrI2ZyTQHDWmxoYrjA
X-Google-Smtp-Source: AGHT+IE18TZshNNsvq9zIZfNo173KX3nov+MisGnA1oe3hqD8symAjmY/JBNqVw84E/3ucMouB6TzA==
X-Received: by 2002:a05:6402:2b91:b0:5fc:6f12:b5db with SMTP id 4fb4d7f45d1cf-5fca0759ae1mr9307543a12.11.1747041243507;
        Mon, 12 May 2025 02:14:03 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 11:14:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
To: Stefano Stabellini 
Cc: Jason Andryuk ,
 "Ragiadakou, Xenia" ,
 Andrew Cooper , agarciav@amd.com,
 xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: 
 <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@suse.com>
 
 <06b66971-d8db-456f-8e83-a20ff7df8f5e@suse.com>
 
 <59bfc389-66c8-4d0f-92e3-c0079a807374@suse.com>
 
 
 <3e7b4b20-0127-4db2-806d-f142547f275a@amd.com>
 <773170d1-d8ba-4ba7-90b0-df0d160d8ba8@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

On 02.05.2025 18:49, Stefano Stabellini wrote:
> On Fri, 2 May 2025, Jan Beulich wrote:
>> On 01.05.2025 15:44, Jason Andryuk wrote:
>>> On 2025-04-30 20:19, Stefano Stabellini wrote:
>>>> On Wed, 30 Apr 2025, Roger Pau Monné wrote:
>>>>> On Wed, Apr 30, 2025 at 08:27:55AM +0200, Jan Beulich wrote:
>>>>>> On 29.04.2025 23:52, Stefano Stabellini wrote:
>>>>>>> On Tue, 29 Apr 2025, Jan Beulich wrote:
>>>>>>>> On 28.04.2025 22:00, Stefano Stabellini wrote:
>>>>>>>>> On Mon, 28 Apr 2025, Jan Beulich wrote:
>>>>>>>>>> On 25.04.2025 22:19, Stefano Stabellini wrote:
>>>
>>>>>>>>>>> --- a/xen/common/memory.c
>>>>>>>>>>> +++ b/xen/common/memory.c
>>>>>>>>>>> @@ -794,7 +794,7 @@ static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
>>>>>>>>>>>               rc = guest_physmap_add_page(d, _gfn(gpfn), mfn,
>>>>>>>>>>>                                           exch.out.extent_order) ?: rc;
>>>>>>>>>>>   
>>>>>>>>>>> -            if ( !paging_mode_translate(d) &&
>>>>>>>>>>> +            if ( (!paging_mode_translate(d) || is_hardware_domain(d)) &&
>>>>>>>>>>>                    __copy_mfn_to_guest_offset(exch.out.extent_start,
>>>>>>>>>>>                                               (i << out_chunk_order) + j,
>>>>>>>>>>>                                               mfn) )
>>>>>>>>>>
>>>>>>>>>> Wait, no: A PVH domain (Dom0 or not) can't very well make use of MFNs, can
>>>>>>>>>> it?
>>>>>>>>>
>>>>>>>>> One way or another Dom0 PVH needs to know the MFN to pass it to the
>>>>>>>>> co-processor.
>>>>>>>>
>>>>>>>> I see. That's pretty odd, though. I'm then further concerned of the order of
>>>>>>>> the chunks. At present we're rather lax, in permitting PVH and PV Dom0 the
>>>>>>>> same upper bound. With both CPU and I/O side translation there is, in
>>>>>>>> principle, no reason to permit any kind of contiguity. Of course there's a
>>>>>>>> performance aspect, but that hardly matters in the specific case here. Yet at
>>>>>>>> the same time, once we expose MFNs, contiguity will start mattering as soon
>>>>>>>> as any piece of memory needs to be larger than PAGE_SIZE. Which means it will
>>>>>>>> make tightening of the presently lax handling prone to regressions in this
>>>>>>>> new behavior you're introducing. What chunk size does the PSP driver require?
>>>>>>>
>>>>>>> I don't know. The memory returned by XENMEM_exchange is contiguous,
>>>>>>> right? Are you worried that Xen cannot allocate the requested amount of
>>>>>>> memory contiguously?
>>>
>>> In the case I looked at, it is 8 pages.  The driver defines a ring of 32 
>>> * 1k entries.  I'm not sure if there are other paths or device versions 
>>> where it might differ.
>>
>> As per this ...
>>
>>>>>> That would be Dom0's problem then. But really for a translated guest the
>>>>>> exchanged chunks being contiguous shouldn't matter, correctness-wise. That is,
>>>>>> within Xen, rather than failing a request, we could choose to retry using
>>>>>> discontiguous chunks (contiguous only in GFN space). Such an (afaict)
>>>>>> otherwise correct change would break your use case, as it would invalidate the
>>>>>> MFN information passed back. (This fallback approach would similarly apply to
>>>>>> other related mem-ops. It's just that during domain creation the tool stack
>>>>>> has its own fallback, so it may not be of much use right now.)
>>>>>
>>>>> I think the description in the public header needs to be expanded to
>>>>> specify what the XENMEM_exchange does for translated guests, and
>>>>> clearly write down that the underlying MFNs for the exchanged region
>>>>> will be contiguous.  Possibly a new XENMEMF_ flag needs to be added to
>>>>> request contiguous physical memory for the new range.
>>>>>
>>>>> Sadly this also has the side effect of quite likely shattering
>>>>> superpages for dom0 EPT/NPT, which will result in decreased dom0
>>>>> performance.
>>>
>>> Yes, this appears to happen as memory_exchange seems to always replace 
>>> the pages.  I tested returning the existing MFNs if they are already 
>>> contiguous since that was sufficient for this driver.  It worked, but it 
>>> was messy.  A big loop to copy in the GFN array and check contiguity 
>>> which duplicated much of the real loop.
>>
>> ... there may not be a need for the output range to be contiguous? In which
>> case - wouldn't a simple "give me the MFN for this GFN" hypercall do? I seem
>> to vaguely recall that we even had one, long ago; it was purged because of
>> it violating the "no MFNs exposed" principle (and because it not having had
>> any use [anymore]). XENMEM_translate_gpfn_list looks like is what I mean;
>> see commit 2d2f7977a052.
> 
> Unfortunately I don't think that would work because I am pretty sure
> that the PSP needs a consecutive range. In other words, I think the
> output needs to be contiguous.

Hmm, higher up (context) you said "ring of 32 * 1k entries". That reads like
independent 1k areas, and hence no need for contiguity.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 09:24:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 09:24:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981041.1367427 (Exim 4.92)
	(envelope-from )
	id 1uEPOd-0004jm-2J; Mon, 12 May 2025 09:24:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981041.1367427; Mon, 12 May 2025 09:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEPOc-0004jf-VV; Mon, 12 May 2025 09:24:26 +0000
Received: by outflank-mailman (input) for mailman id 981041;
 Mon, 12 May 2025 09:24:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEPOb-0004jZ-1B
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 09:24:25 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e3e2aa90-2f12-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 11:24:22 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5fbda5a8561so5872820a12.2
 for ; Mon, 12 May 2025 02:24: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
 4fb4d7f45d1cf-5fd29f9fdc2sm2036895a12.4.2025.05.12.02.24.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 02:24: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" 
X-Inumbo-ID: e3e2aa90-2f12-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747041862; x=1747646662; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=aZX8ZeUBO8WpYhmUCA3bGFQmzit9vYkyxZVFva7jk7E=;
        b=R2iVphm3HpDsbSRmLaqNcIAapSzwa6gSgN0H5l6QnvpbH7yl5WEeCx4ARJeJpVp2/T
         I7yGdeMA79ty8TvK/muvrh/wlj4ZGiZDspZ+Q7xSuweTct581HOdLWkjhpZMuN8z8Ter
         aOpq/L8S4y2lnaVtwQXUsoRtSsciYn69jLOhfu0XWciyyRH6LP0Vm2k7r9WjF/m8HllV
         6VK0F4ReQBVoKQALYHxFSVahEVsOLj7lS5SZyJjwCtuaUkN3gejXcf3Sdae8ovBonPSd
         MWbW648okTU3IUJZAinr/DGBjSiGn3roDCFAHCoCUGUesyPpI0z0JGLtrEMp4KZ20X/4
         WoGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747041862; x=1747646662;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aZX8ZeUBO8WpYhmUCA3bGFQmzit9vYkyxZVFva7jk7E=;
        b=iLK7HO7I3m42y44wOiIgWNG/67U4AsNvWUTpbAMLYKa4iGDKbj5etw4tyeE1TgQk0Q
         vBTPznes/wjDoXoXYlF6jbqp8F0jQlyP73cBHAZAkqRUAbi4NeKDJqtdW+9LNNZ2m7Oe
         A4gi1AYbLFIThXx7gY4PZuDDefNbsoULrF8C5q0VI2vsse4FboY1nsUIIXjdZPo2hHGe
         IDRwDfaxKOOqiSUQNoZSEM5LVcECRBL4/jq7QUl4oussSUd75H9fahcVsHobujqM1a3l
         84NQ3FuNeGd7Qv1qgwM+Go+/Hon0nTkGytCUrDOhseQ0S0C/jmH663LD26RZLFaSyK/7
         PLiQ==
X-Forwarded-Encrypted: i=1; AJvYcCUw0u5wIRLYYbgTwrhUmr2epQLx5oSOt0b/nIfC1IwxHTk16uXrZzh0w12iKJtO1Ti5DLUuY88rl2Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzvuFD971AAXLyZyD6ugbUBp+fSqPePB/WP2zYWKPI/FPiR+N68
	4K/wS8IZ8MoItSL2SuZ7lHUHULxUbQ9kgtHdnuGcYpFW1Nw6qc/BRIDQ6RYXoA==
X-Gm-Gg: ASbGncvRjB0QewdQ+aT2ffsuJEjtD0PHPuaS6tZfyh8nbFt1+EhCF4UonRxDXHO2PeT
	/G3eFzS/r7QeRhfbHauF3WXxm3CKrYIyFlMmWCcjngZ+tQv0MvpnoPOzCwDKR3Kib+o/OXW5Ye2
	ebQHb0ywlF+4W8Ccvj6SUy7egS/u6AhRpaKq2DDziR6g+BQSO2WtATgx7kSD640JPJLlklHKgv4
	3O7Kl8pW3GcHLnl5Tt5zbMpAmA3M0dfdwTBx2moeUcz4a6QapcimakKniWniwKBY0r2OW2LFHjB
	G3WeZG15rf5V7iAvkAjuK9SfJkK20ezDpZNADjKMmO9mIEVQvzPV5J/FpqfAqXUH0XGyXWMs4QJ
	UQRhRHRW9KbsNZbT303b3NUqkYGN5nWxqgflZ
X-Google-Smtp-Source: AGHT+IHNKOlGGgyfeTfCDondG8n3Gvjn233PoX8B/5uZls2gRBLiWbrvMECybZ0C/VOAQmUTb6PLag==
X-Received: by 2002:a05:6402:c4d:b0:5fd:10fe:9f97 with SMTP id 4fb4d7f45d1cf-5fd10fea20fmr6508523a12.28.1747041862307;
        Mon, 12 May 2025 02:24:22 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 11:24:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 "Ragiadakou, Xenia" ,
 Andrew Cooper , jason.andryuk@amd.com,
 agarciav@amd.com, xen-devel@lists.xenproject.org,
 Stefano Stabellini 
References: 
 <19d9aec4-c21a-47a9-9c58-6bfcadbd22e0@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

On 09.05.2025 10:32, Roger Pau Monné wrote:
> On Thu, May 08, 2025 at 04:25:28PM -0700, Stefano Stabellini wrote:
>> On Thu, 8 May 2025, Roger Pau Monné wrote:
>>> On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
>>>> On Tue, 6 May 2025, Roger Pau Monné wrote:
>>>>> On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
>>>>>> In my opinion, we definitely need a solution like this patch for Dom0
>>>>>> PVH to function correctly in all scenarios.
>>>>>
>>>>> I'm not opposed to having such interface available for PVH hardware
>>>>> domains.  I find it ugly, but I don't see much other way to deal with
>>>>> those kind of "devices".  Xen mediating accesses for each one of them
>>>>> is unlikely to be doable.
>>>>>
>>>>> How do you hook this exchange interface into Linux to differentiate
>>>>> which drivers need to use mfns when interacting with the hardware?
>>>>
>>>> In the specific case we have at hands the driver is in Linux userspace
>>>> and is specially-written for our use case. It is not generic, so we
>>>> don't have this problem. But your question is valid.
>>>
>>> Oh, so you then have some kind of ioctl interface that does the memory
>>> exchange and bouncing inside of the kernel on behalf of the user-space
>>> side I would think?
>>
>> I am not sure... Xenia might know more than me here.
> 
> One further question I have regarding this approach: have you
> considered just populating an empty p2m space with contiguous physical
> memory instead of exchanging an existing area?  That would increase
> dom0 memory usage, but would prevent super page shattering in the p2m.
> You could use a dom0_mem=X,max:X+Y command line option, where Y
> would be your extra room for swiotlb-xen bouncing usage.
> 
> XENMEM_increase_reservation documentation notes such hypercall already
> returns the base MFN of the allocated page (see comment in
> xen_memory_reservation struct declaration).

Except that this looks to be stale. At the bottom of increase_reservation()
we have:

        if ( !paging_mode_translate(d) &&
             !guest_handle_is_null(a->extent_list) )
        {
            mfn_t mfn = page_to_mfn(page);

            if ( unlikely(__copy_mfn_to_guest_offset(a->extent_list, i, mfn)) )
                goto out;
        }

Consistent with us not exposing MFNs elsewhere as well, except for PV.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 09:24:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 09:24:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981044.1367437 (Exim 4.92)
	(envelope-from )
	id 1uEPOx-00053t-8d; Mon, 12 May 2025 09:24:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981044.1367437; Mon, 12 May 2025 09: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 1uEPOx-00053m-65; Mon, 12 May 2025 09:24:47 +0000
Received: by outflank-mailman (input) for mailman id 981044;
 Mon, 12 May 2025 09:24:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEPOw-0004jZ-0d
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 09:24:46 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f0c26652-2f12-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 11:24:44 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad24b7e0331so188597766b.0
 for ; Mon, 12 May 2025 02:24:44 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad21985858asm595144466b.176.2025.05.12.02.24.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 02: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" 
X-Inumbo-ID: f0c26652-2f12-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747041884; x=1747646684; darn=lists.xenproject.org;
        h=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;
        bh=r9qugMwnRVX+qcsYC3JfFHNgzHHnGrz9+0ecOMYkWLA=;
        b=AX2mUIU4YMA2Yy3NUL3c9q8pzmFN2osd+r2Bb0s13+jGnRW74KjrtHMsltsgnyHhNe
         jgPPVtpMQQCYh8zBb3gfL9XKaJmA+gDJn88Lr2jUJiv3AvAC+wkdwQl81mI8gnBi0k1D
         hJD7dOPXagQAkD2nWgVSeG0z0LyHlRe70iUdOIaDN/lQZJhIMmgpsk2m1KigcLl1C8Ee
         JFIfRGuzUKJEtLRqoEeQCnwPawZij21j1DNU3waiRD37UUdnSxpNvTDy+ZuKj/Z6ow5z
         /I/Zp5JH6zZS2B3vOOBe9uDb5eFIAqKVLSBISHg2uUoZ7LL0Yyx9YBBS3idfrJic0Whw
         BOrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747041884; x=1747646684;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=r9qugMwnRVX+qcsYC3JfFHNgzHHnGrz9+0ecOMYkWLA=;
        b=SWeHeoQ1E+DNyiLtYd00KCgYPIMXA3BgML9Okf8aGdeFIVO9oJzmXpwVnbnboj/Wyf
         wE7btsXYRbfxk1cZ+MzuU/TayThKp6ebEhuwEihgRD020/pbfyAJErq6DNoe4GDCxOHP
         U7Ge7gk0G2zow00COFoOUJzZlKqoc6pL2JU7/nh5mQT3r0wbjFB6Thyh7weSLKrE36gb
         KXKAvv8goY8MUAHu3LUES2LXFhPZ5fdOy3ZmNB7Y/v1hJMsPrVMiKAGJfluFcuK+5y8d
         LBWPmtAkiNvNXqbNHFvGDd8l1olzA4OR4i3grA8rfvJ38hjZep91OOu6Lt2om+euZJMw
         HosQ==
X-Forwarded-Encrypted: i=1; AJvYcCWKuHB+DI2ZGZHsUdl0gD+2MgMuaq0Jak07n4MNTL4mBiphaYhZgj3WHAkSNNORBNewFes3/ob1x5U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwVknet4KSZqspFwyssJ3bwfDY8BRjWdfz/fwtkBzhQ7SPJ0S4u
	qbN4wfdcpWUYKCZHLrACT4kiSsPC8G8ixUlFDGNeJpJb+iTJUw2E
X-Gm-Gg: ASbGncuK2J4iR+WHad7R45JWWXYP1Dbapi/bVoNPou8EyIf0dqfS/seFyKroggj3XNQ
	f8z1L0avlC0zD0PCHWEzxGp5NLMSXdAKUgw8/pmWEc9PPWXYsjVCLgKovGNeVPzFBOWvzn8HelJ
	ycPYStLTYETipCjxrx1z3RtO3erGfUJ7dDS9cwiqOfdU6+X+TjUND2rwJGEYPyw4zfDLVqBbr7C
	3YGeSNP6vTvIKPfa5Hl6bWJxAOR8wRPqzUB48TEsTRRyqctryef7yRvu0JkGegVsr0KUwBv/2nJ
	FYfP/to9BdoXe7r7ugPTWWhC4mZNv/LXwlH5xpix8JMxuCMp2wyU5DSZfr1gWz9iRjUidkpv0Ds
	Y9mJDvD9wfpSihunLICyfl3C/
X-Google-Smtp-Source: AGHT+IE7fMnWzb0Qy9nz6fIVPdtrJztEhsel9pp2k58OsAli7qhhM4HLrWGvaUEvDfq6TDttp/sADQ==
X-Received: by 2002:a17:907:6d28:b0:ad2:500c:16c1 with SMTP id a640c23a62f3a-ad2500c2ademr383309266b.35.1747041883347;
        Mon, 12 May 2025 02:24:43 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------TjKqzAerYX0cDZ1Qo0v2QFZR"
Message-ID: 
Date: Mon, 12 May 2025 11:24:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m
 initialization
To: Andrew Cooper , xen-devel@lists.xenproject.org
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: 
 <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
 <70186bd9-20b6-48a2-9dd0-25cdc30e81f0@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <70186bd9-20b6-48a2-9dd0-25cdc30e81f0@citrix.com>

This is a multi-part message in MIME format.
--------------TjKqzAerYX0cDZ1Qo0v2QFZR
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/9/25 6:14 PM, Andrew Cooper wrote:
> On 09/05/2025 4:57 pm, Oleksii Kurochko wrote:
>> diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
>> new file mode 100644
>> index 0000000000..ad4beef8f9
>> --- /dev/null
>> +++ b/xen/arch/riscv/p2m.c
>> @@ -0,0 +1,168 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +/*
>> + * Force a synchronous P2M TLB flush.
>> + *
>> + * Must be called with the p2m lock held.
>> + *
>> + * TODO: add support of flushing TLB connected to VMID.
>> + */
>> +static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
>> +{
>> +    ASSERT(p2m_is_write_locked(p2m));
>> +
>> +    /*
>> +     * TODO: shouldn't be this flush done for each physical CPU?
>> +     *       If yes, then SBI call sbi_remote_hfence_gvma() could
>> +     *       be used for that.
>> +     */
>> +#if defined(__riscv_hh) || defined(__riscv_h)
>> +    asm volatile ( "hfence.gvma" ::: "memory" );
>> +#else
>> +    asm volatile ( ".insn r 0x73, 0x0, 0x31, x0, x0, x0" ::: "memory" );
>> +#endif
> TLB flushing needs to happen for each pCPU which potentially has cached
> a mapping.
>
> In other arches, this is tracked by d->dirty_cpumask which is the bitmap
> of pCPUs where this domain is scheduled.

I could only find usage of|d->dirty_cpumask| in x86 and common code (grant
tables) for flushing the TLB. However, it seems that|d->dirty_cpumask| is
not set anywhere for ARM. Is it sufficient to set a bit in|d->dirty_cpumask|
in|startup_cpu_idle_loop()|?

In addition, it’s also necessary to set and clear bits in|d->dirty_cpumask|
during|context_switch|, correct? Set it before switching from the previous
domain, and clear it after switching to the new domain?

Also, when a bit is set in|d->dirty_cpumask|, the|v->processor| value is also
stored in|v->dirty_cpu|. Is this needed to track which processor is
currently being used for the vCPU?

> CPUs need to flush their TLBs before removing themselves from
> d->dirty_cpumask, which is typically done during context switch, but it
> means that to flush the P2M, you only need to IPI a subset of CPUs.

I can't find where the P2M flush happens for x86/ARM. Could you please point me
to where it is handled?

Also, I found guest_flush_tlb_mask() for x86. I assume that it is x86 specific
and generally it is enough to have only flush_tlb_mask(), right?

Thanks in advance for the answers.

~ Oleksii

--------------TjKqzAerYX0cDZ1Qo0v2QFZR
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    

    
    
    
    
    On 5/9/25 6:14 PM, Andrew Cooper wrote:
    
    
    
    
    
      
    On 09/05/2025 4:57 pm, Oleksii Kurochko wrote:

    
      
    
        
    diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
new file mode 100644
index 0000000000..ad4beef8f9
--- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,168 @@
+#include <xen/domain_page.h>
+#include <xen/iommu.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/pfn.h>
+#include <xen/rwlock.h>
+#include <xen/sched.h>
+#include <xen/spinlock.h>
+
+#include <asm/page.h>
+#include <asm/p2m.h>
+
+/*
+ * Force a synchronous P2M TLB flush.
+ *
+ * Must be called with the p2m lock held.
+ *
+ * TODO: add support of flushing TLB connected to VMID.
+ */
+static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
+{
+    ASSERT(p2m_is_write_locked(p2m));
+
+    /*
+     * TODO: shouldn't be this flush done for each physical CPU?
+     *       If yes, then SBI call sbi_remote_hfence_gvma() could
+     *       be used for that.
+     */
+#if defined(__riscv_hh) || defined(__riscv_h)
+    asm volatile ( "hfence.gvma" ::: "memory" );
+#else
+    asm volatile ( ".insn r 0x73, 0x0, 0x31, x0, x0, x0" ::: "memory" );
+#endif

    
      
    
      
    TLB flushing needs to happen for each pCPU which potentially has cached
a mapping.

In other arches, this is tracked by d->dirty_cpumask which is the bitmap
of pCPUs where this domain is scheduled.
    
    
    
    
    I could only find usage of d->dirty_cpumask in x86 and common code (grant
tables) for flushing the TLB. However, it seems that d->dirty_cpumask is
not set anywhere for ARM. Is it sufficient to set a bit in d->dirty_cpumask
in startup_cpu_idle_loop()?
    
    
    In addition, it’s also necessary to set and clear bits in d->dirty_cpumask
during context_switch, correct? Set it before switching from the previous
domain, and clear it after switching to the new domain?
    
    
    Also, when a bit is set in d->dirty_cpumask, the v->processor value is also
stored in v->dirty_cpu. Is this needed to track which processor is
currently being used for the vCPU?
    
    
    
      
    CPUs need to flush their TLBs before removing themselves from
d->dirty_cpumask, which is typically done during context switch, but it
means that to flush the P2M, you only need to IPI a subset of CPUs.
    
    
    
    
    I can't find where the P2M flush happens for x86/ARM. Could you please point me
to where it is handled?

Also, I found guest_flush_tlb_mask() for x86. I assume that it is x86 specific
and generally it is enough to have only flush_tlb_mask(), right?

Thanks in advance for the answers.

    
    
    ~ Oleksii

    
  


--------------TjKqzAerYX0cDZ1Qo0v2QFZR--


From xen-devel-bounces@lists.xenproject.org Mon May 12 09:33:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 09:33:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981063.1367448 (Exim 4.92)
	(envelope-from )
	id 1uEPXa-0007C2-8y; Mon, 12 May 2025 09:33:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981063.1367448; Mon, 12 May 2025 09:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEPXa-0007Bv-3q; Mon, 12 May 2025 09:33:42 +0000
Received: by outflank-mailman (input) for mailman id 981063;
 Mon, 12 May 2025 09:33:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEPXY-0007Bp-Tp
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 09:33:40 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2a87b79d-2f14-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 11:33:30 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5f63ac6ef0fso77360a12.1
 for ; Mon, 12 May 2025 02:33:30 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5fe43357d45sm1697733a12.54.2025.05.12.02.33.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 02:33: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" 
X-Inumbo-ID: 2a87b79d-2f14-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747042410; x=1747647210; darn=lists.xenproject.org;
        h=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;
        bh=0ln4VS6DP23i5PPDPc9eIW9sj98gvcZ5kmyUqXZJHQw=;
        b=Y4P8EEJzwgIabhsQydAy5Rap736NxzKJBKrpctMlExqins/N6cR5gCc0EuvXl97JnQ
         IsQ0SPs42mFo54ZC/sBgkAmSuv6zgxtvkzgGWsa5a7ZKcLSt9AHr7l+yoislZ6hQ/FU+
         9bsrgO7eLMVAAr+5NNH+I6GAmUmx3MJ6PUrmQ3iPYIss3HvZAWFQqQN3RSdYDfrcf0JW
         zvK+cA1AlRZXZuOOLKFMQXiSJR8/xqCW9pPrn1sBz+4rtYaKNzyUmD2AMCJh4jLhZwI3
         b/ZGrT6YH2X720CAy/zZe+Z8f7KMbluEL9rNyYy/ePstO1LAIsoqRcAZLm+VJSgZ879q
         OlEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747042410; x=1747647210;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=0ln4VS6DP23i5PPDPc9eIW9sj98gvcZ5kmyUqXZJHQw=;
        b=go1OXlsOdgpbX0iFS3DEVmgUaUYgqr3hILyJbDvyChjOZWRR68eVDltqTXcuJsvZyv
         mDRkI2Yz47j16ycBLhnnJCasOz9jFKTQRHwida23ux43SxUamWZI/dE8mXJ4Om75EQ68
         mBqtCRKXDdMPLQdJdW5kuZNL2/9GBUgEoJlHvt4HLDcpg3k+8RkhOS7/SOjUmRy3IEqN
         D4tVdVXHmS7laARN2g5YvsC9b9MtAosfd9QLgtB/8AzOoujr7ToKzvs++TPb7gOXugqY
         i+s0pUbtGGlx18OAYIlx+j2ZfE6OWPEUfN+Mey5OSS6WdqV47cAEmqrUWVh+oyqXvsqX
         kqSQ==
X-Forwarded-Encrypted: i=1; AJvYcCUkoOI0VWJ5LNyPkCHWkefqaknpByStRS/yKZGonxqPqoqK7h3eOcTeCz84bpbcR92i3pZoWA3fYEc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxqBosy7YEOdjtjh3hAQIsEyEVUAau1istkfc4SAYMWUpihOeBb
	7QHt/xa3Qi/Hwt4xjXj4WngnGnVixgbJaqR0k5dzk8avMQctHIE8
X-Gm-Gg: ASbGncvIyF23H7jEUW1/k8nssNA4nV/SMd6r1G+ptTOXYjb4dyuxONcibeuJGIMtffS
	LBcp6KP9iW5Qp0DYuwMfnd56AYXYVnOVctRNvMROcz8QkirrAFFk85yYTVEwyWJIbH1hFTY8fEf
	P7JAC1J8be4Cwu7OlKUk2rIj5CUkXaBVgQ7XtMAu5jjXZBRO9lQJQREbIW4Jcmk+PXboxT7eXgC
	myoOBsLYgQpQ8+3+SdUe6JiWBZQdWfp3SAdkzLCrtIg5GhXpu0yEitMZNMfgESDc5lzk3wUc/Oh
	8y0XuKbYyl3Dplxx228+VazqeNYPQ+ZvjMU5TEOZh//0TqGYRKgSwX280Cti9qqZ7Q/GTYYxJze
	d+JW/Y57PbnxuVyZUqDqxXNTk
X-Google-Smtp-Source: AGHT+IG0EDu/7Ch8JdgS5A9imZV1onvlMNgrzOXTVC3oCUw/B2X1nXdQ8L/dXjFr0e6jF2RWYBkXuQ==
X-Received: by 2002:a05:6402:1ecd:b0:5fa:bb9d:9677 with SMTP id 4fb4d7f45d1cf-5fca1619c99mr8926539a12.11.1747042409932;
        Mon, 12 May 2025 02:33:29 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------BRwNd3NIEZU91JKGntAS0xEt"
Message-ID: <7aa60d22-b2c6-4e11-bb40-c5d6d66a6182@gmail.com>
Date: Mon, 12 May 2025 11:33:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m
 initialization
From: Oleksii Kurochko 
To: Andrew Cooper , xen-devel@lists.xenproject.org
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: 
 <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
 <70186bd9-20b6-48a2-9dd0-25cdc30e81f0@citrix.com>
 
Content-Language: en-US
In-Reply-To: 

This is a multi-part message in MIME format.
--------------BRwNd3NIEZU91JKGntAS0xEt
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/12/25 11:24 AM, Oleksii Kurochko wrote:
>
>
> On 5/9/25 6:14 PM, Andrew Cooper wrote:
>> On 09/05/2025 4:57 pm, Oleksii Kurochko wrote:
>>> diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
>>> new file mode 100644
>>> index 0000000000..ad4beef8f9
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/p2m.c
>>> @@ -0,0 +1,168 @@
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +/*
>>> + * Force a synchronous P2M TLB flush.
>>> + *
>>> + * Must be called with the p2m lock held.
>>> + *
>>> + * TODO: add support of flushing TLB connected to VMID.
>>> + */
>>> +static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
>>> +{
>>> +    ASSERT(p2m_is_write_locked(p2m));
>>> +
>>> +    /*
>>> +     * TODO: shouldn't be this flush done for each physical CPU?
>>> +     *       If yes, then SBI call sbi_remote_hfence_gvma() could
>>> +     *       be used for that.
>>> +     */
>>> +#if defined(__riscv_hh) || defined(__riscv_h)
>>> +    asm volatile ( "hfence.gvma" ::: "memory" );
>>> +#else
>>> +    asm volatile ( ".insn r 0x73, 0x0, 0x31, x0, x0, x0" ::: "memory" );
>>> +#endif
>> TLB flushing needs to happen for each pCPU which potentially has cached
>> a mapping.
>>
>> In other arches, this is tracked by d->dirty_cpumask which is the bitmap
>> of pCPUs where this domain is scheduled.
> I could only find usage of|d->dirty_cpumask| in x86 and common code (grant
> tables) for flushing the TLB. However, it seems that|d->dirty_cpumask| is
> not set anywhere for ARM. Is it sufficient to set a bit in|d->dirty_cpumask|
> in|startup_cpu_idle_loop()|?

And one more thing.
If|d->dirty_cpumask| is empty (for example, on p2m initialization stage) then
p2m TLB flush could be skipped at all, right?

~ Oleksii

> In addition, it’s also necessary to set and clear bits in|d->dirty_cpumask|
> during|context_switch|, correct? Set it before switching from the previous
> domain, and clear it after switching to the new domain?
> Also, when a bit is set in|d->dirty_cpumask|, the|v->processor| value is also
> stored in|v->dirty_cpu|. Is this needed to track which processor is
> currently being used for the vCPU?
>> CPUs need to flush their TLBs before removing themselves from
>> d->dirty_cpumask, which is typically done during context switch, but it
>> means that to flush the P2M, you only need to IPI a subset of CPUs.
> I can't find where the P2M flush happens for x86/ARM. Could you please point me
> to where it is handled?
>
> Also, I found guest_flush_tlb_mask() for x86. I assume that it is x86 specific
> and generally it is enough to have only flush_tlb_mask(), right?
>
> Thanks in advance for the answers.
> ~ Oleksii
--------------BRwNd3NIEZU91JKGntAS0xEt
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    

    
    
    
    
    On 5/12/25 11:24 AM, Oleksii Kurochko
      wrote:
    
    
    
    
    
      
      

    
      
    
      
    On 5/9/25 6:14 PM, Andrew Cooper
        wrote:
    
      
    
      
    
        
    On 09/05/2025 4:57 pm, Oleksii Kurochko wrote:

    
        
    
          
    diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
new file mode 100644
index 0000000000..ad4beef8f9
--- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,168 @@
+#include <xen/domain_page.h>
+#include <xen/iommu.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/pfn.h>
+#include <xen/rwlock.h>
+#include <xen/sched.h>
+#include <xen/spinlock.h>
+
+#include <asm/page.h>
+#include <asm/p2m.h>
+
+/*
+ * Force a synchronous P2M TLB flush.
+ *
+ * Must be called with the p2m lock held.
+ *
+ * TODO: add support of flushing TLB connected to VMID.
+ */
+static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
+{
+    ASSERT(p2m_is_write_locked(p2m));
+
+    /*
+     * TODO: shouldn't be this flush done for each physical CPU?
+     *       If yes, then SBI call sbi_remote_hfence_gvma() could
+     *       be used for that.
+     */
+#if defined(__riscv_hh) || defined(__riscv_h)
+    asm volatile ( "hfence.gvma" ::: "memory" );
+#else
+    asm volatile ( ".insn r 0x73, 0x0, 0x31, x0, x0, x0" ::: "memory" );
+#endif

    
        
    
        
    TLB flushing needs to happen for each pCPU which potentially has cached
a mapping.

In other arches, this is tracked by d->dirty_cpumask which is the bitmap
of pCPUs where this domain is scheduled.
    
      
    
      
    I could only find usage of d->dirty_cpumask in x86 and common code (grant
tables) for flushing the TLB. However, it seems that d->dirty_cpumask is
not set anywhere for ARM. Is it sufficient to set a bit in d->dirty_cpumask
in startup_cpu_idle_loop()?
    
    
    
    
    And one more thing.
If d->dirty_cpumask is empty (for example, on p2m initialization stage) then
p2m TLB flush could be skipped at all, right?

~ Oleksii

    
    
    
      
    In addition, it’s also necessary to set and clear bits in d->dirty_cpumask
during context_switch, correct? Set it before switching from the previous
domain, and clear it after switching to the new domain?
    
      
    Also, when a bit is set in d->dirty_cpumask, the v->processor value is also
stored in v->dirty_cpu. Is this needed to track which processor is
currently being used for the vCPU?
    
      
    
        
    CPUs need to flush their TLBs before removing themselves from
d->dirty_cpumask, which is typically done during context switch, but it
means that to flush the P2M, you only need to IPI a subset of CPUs.
    
      
    
      
    I can't find where the P2M flush happens for x86/ARM. Could you please point me
to where it is handled?

Also, I found guest_flush_tlb_mask() for x86. I assume that it is x86 specific
and generally it is enough to have only flush_tlb_mask(), right?

Thanks in advance for the answers.

    
      
    ~ Oleksii

    
    
    
  


--------------BRwNd3NIEZU91JKGntAS0xEt--


From xen-devel-bounces@lists.xenproject.org Mon May 12 09:43:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 09:43:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981072.1367457 (Exim 4.92)
	(envelope-from )
	id 1uEPhH-0000ck-43; Mon, 12 May 2025 09:43:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981072.1367457; Mon, 12 May 2025 09:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEPhH-0000cc-0Y; Mon, 12 May 2025 09:43:43 +0000
Received: by outflank-mailman (input) for mailman id 981072;
 Mon, 12 May 2025 09:43:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEPhF-0000cW-Gn
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 09:43:41 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 953f27c1-2f15-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 11:43:39 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ad23db02350so314900466b.1
 for ; Mon, 12 May 2025 02:43: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
 a640c23a62f3a-ad2417f2341sm319056866b.19.2025.05.12.02.43.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 02:43: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" 
X-Inumbo-ID: 953f27c1-2f15-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747043019; x=1747647819; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CArXeoVkfSTjrHO91BI3DtDiZgfxPGCnLmt7jUBicWc=;
        b=QdOOir8EsvtQJn+IODdPl35zYk7L9tUVCsBnu9BsxYsR7nzn/oX7Np6CJf2swU/KAo
         F2G465oaNNjlZBJS2SbHbFDCAnRZVX9c4N8rf1fIpOah2J/feZ9mv5QBArM10hTU5Txb
         7OfaKXv7kTmDQ7swYJF9GICD19AwmTnxRDv/K3QE2fzzyj8SN7HB8h5yieiZCeRrsHqw
         s1Ao4/rzu4sAJxEsJrgX2e9eeFDr0pjlyFaEWbW3yzQKnDlbMjS1AX7hHX1axgtKnt3w
         QpHEBQ581Vlq/Gt7n/EZpIkORprchXvmwCNJaK6/lP3r+/Zvp9OSvX0oasfqBhCVrLHD
         lVSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747043019; x=1747647819;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CArXeoVkfSTjrHO91BI3DtDiZgfxPGCnLmt7jUBicWc=;
        b=ITvu2K1b+3xceWeL5sZO3+YNEtyOu2zVNTYwxjr3VLI6q17SETddwF0B6LJSs1z/TT
         0k6xmj8PjTxQBh3Z8Z8NbyNlfRrr1ZuY/u4Socr162UZIfboWO+dVE9fbmysRxITxUN9
         DqNkHFUZhZr0X9Qm9Xh6juhwpa4ZxuhiidBqW6Wzoe/HwCT5S/yIKSuNjTp4tZ2jBgpK
         xG/beH2Q6fIveiXHdeyBUyKtIkkmqKA2ErrE21s3iiZJMeRgHX/iexDq3bAzx1qLiEu0
         KvoRozz6+8KrETEujMYsbEhFp6RVg6P9Vf8suBQMzZAevXqjD+niKI51ek89uvtDX5IG
         rVYw==
X-Gm-Message-State: AOJu0YxPBfS7+HjPpOfl/+YJQFBoXynUphqhurfRd5eIuQDnLg2D6NTc
	HcWuwPtPGd2Hc7feY4DERSXPGc4E6yT7zVeLpaNfTz0RTj5KeKFTeGmnhSmapg==
X-Gm-Gg: ASbGncs7maJEb3IyNDk2q1EStinjxj904pjYPH8HfOJl162DqWg2isJKJHThQgoOa3d
	c3XWnpxsR1FiwgWjZAx3EDSPmsNT1DoXtlSKhnFvkVY3m89yl/38KPB+hEY3p9xEVhNQFSr1DGW
	h9802QueVJlTzHyX0kjZ9k9sXn+4Fs681CuaeaUnjDvyq89iFrYzhS6svwKLQBJ/pvMnF1cyy5o
	o2gyLWygstoeu3mhjeGNds/6syEx2H6BWYdLER5ur3+4MQ/dcnrq6IwBCX6oWIo2KJn8gNRDDux
	xohGycmlTpFWr/W3CU57KfNvaZKC7VUk2DEx0Z+nJ4Tj9+slKkilB+DZiZTfVEWF2FLD4s6PWHe
	IIuftUsbR01BAaJs7Co6vZi0S/AfuU0OKwR/R3bqC7gtoynY=
X-Google-Smtp-Source: AGHT+IHAZjCcvNc7r6A8B2zlm6U2APdg32Z1I9lQCvneTa3qjJoO8d/CH89nO8khnthh1yzWWeZ+Nw==
X-Received: by 2002:a17:907:8b95:b0:ad2:4b0c:ee8c with SMTP id a640c23a62f3a-ad24b0cf5a5mr422369266b.35.1747043018925;
        Mon, 12 May 2025 02:43:38 -0700 (PDT)
Message-ID: <381841d2-08af-46cf-9647-6ef16eeaba21@suse.com>
Date: Mon, 12 May 2025 11:43:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/pmstat: Check size of PMSTAT_get_pxstat buffers
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org
References: <20250417103000.827661-1-ross.lagerwall@citrix.com>
 <37065e8d-33c2-4e6e-8c2c-f4f8a9cd3ce1@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

On 07.05.2025 16:37, Ross Lagerwall wrote:
> On Thu, Apr 17, 2025 at 2:23 PM Jan Beulich  wrote:
>>
>> On 17.04.2025 12:30, Ross Lagerwall wrote:
>>> --- a/xen/drivers/acpi/pmstat.c
>>> +++ b/xen/drivers/acpi/pmstat.c
>>> @@ -104,6 +104,14 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
>>>          cpufreq_residency_update(op->cpuid, pxpt->u.cur);
>>>
>>>          ct = pmpt->perf.state_count;
>>> +
>>> +        if ( op->u.getpx.total < ct )
>>> +        {
>>> +            spin_unlock(cpufreq_statistic_lock);
>>> +            ret = -ENOSPC;
>>> +            break;
>>> +        }
>>
>> Simply producing an error is not an option imo. See pmstat_get_cx_stat()'s
>> behavior. Imo the calculation of ct wants to become
>>
>>         ct = min(pmpt->perf.state_count, op->u.getpx.total);
>>
>> yet then the copying of the 2-dim array of data becomes more complicated
>> when ct < pmpt->perf.state_count. An option may be to document that this
>> array is copied only when the buffer is large enough.
> 
> Another option would be for the caller to explicitly pass in both array sizes
> and Xen can copy as much as fits since in either case there would need to be a
> way for Xen to return how much it has (separately) copied for both arrays. Does
> that make sense?

May be an option, but would require adjustments to the interface itself.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 09:47:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 09:47:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981081.1367467 (Exim 4.92)
	(envelope-from )
	id 1uEPks-0001Ba-Hv; Mon, 12 May 2025 09:47:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981081.1367467; Mon, 12 May 2025 09: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 1uEPks-0001BT-ET; Mon, 12 May 2025 09:47:26 +0000
Received: by outflank-mailman (input) for mailman id 981081;
 Mon, 12 May 2025 09:47:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEPkr-0001BN-36
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 09:47:25 +0000
Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com
 [2001:4860:4864:20::2c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1a61dbbe-2f16-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 11:47:23 +0200 (CEST)
Received: by mail-oa1-x2c.google.com with SMTP id
 586e51a60fabf-2c769da02b0so4108247fac.3
 for ; Mon, 12 May 2025 02: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" 
X-Inumbo-ID: 1a61dbbe-2f16-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747043242; x=1747648042; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=h25lVqn72bj1XF2ohwpw077vyNok8RC37a4R1zyg5V4=;
        b=uRjTvabIzIoXzj3oy+AWHLkRNmVUPO4ZxVI0Uvfv5UrUd2Os4e/NlnUWQNFO3peGeg
         IYnPb9/OV5O5U/0S786mJdHMZ7gce+mO/AyM0bVFcKluKQgy0vhhvHrVXklxMSdZ+VLW
         H7v4E6tvAZHpCdeyZgbOerl8g+mma7B7ws6YI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747043242; x=1747648042;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=h25lVqn72bj1XF2ohwpw077vyNok8RC37a4R1zyg5V4=;
        b=W4om1uTZyypWjG/8a0fDM2V3UmZ+Ska5ygdoyEZu90X6RvMudmwdSu27MML+KcpMKn
         /Gs9v3Rne5NRRkNDS0xHVcfXCvvVo0Ww4oKNnvi11ATculAvbEC7FGXmM2yFc/D9sdd5
         I/qlvXTtuqyFQ2+bHLSsCSSXAMdRFGJ74+EV7kYXCIYkKoD5cHdNDszCUQNuk721WHeg
         ppidGs1IW9xUkCvtR3AWtuwgvcKAIh+qiK3EqspSg0KqlyRZt3Jo9CNrVHnyBA8/D0j5
         pJ0SpN4RAW6syhwGuSWhE8bGpgVne2dsatXcOOqFmzs379gFgfWOLmyNGImbqYGFECC7
         y4kg==
X-Gm-Message-State: AOJu0Yy5ndBxhFJNus10SDevB30ecWtmhmT4M2OLxKqMxjoCAExt5ihv
	GiXTsZqUiPJllFOPR9eDWYeZhOcE+5+pv9uQ1ptjzSAK9UrkRNEY/f+WWruEWMobpFaFUYX4vKz
	9fmALS1sV58FzQLWWaQXsZ6rc61yPtcq80tbx
X-Gm-Gg: ASbGnct/5LRRQJYJPOFr78rUoeGXnKGnw83bIBBn6CbAkjFNL8XbQU7225vEPXdM5+d
	hQ5CbRkDXntm/AtTOHrd0UDLWTmbiLa9YjcS58k1/1hTRMFNv1Mcu1roe8EZ+WjNCXLoHlNNtQS
	Uwfx2P7Gjd7DU8KjjVdwDWWNpl3OPm9wA=
X-Google-Smtp-Source: AGHT+IEGQexJLUUTPg9It44iQEnX4e1HpdGfDrAry2sLoy5emLTnzP/OSbgjnn0TS+qSAznC6VPfyBLIk2Tu3RcP2FE=
X-Received: by 2002:a05:6870:56a3:b0:2b8:f595:2374 with SMTP id
 586e51a60fabf-2dba456b938mr7505081fac.36.1747043242040; Mon, 12 May 2025
 02:47:22 -0700 (PDT)
MIME-Version: 1.0
References: <20250509163212.2948359-1-andrew.cooper3@citrix.com> <20250509163212.2948359-2-andrew.cooper3@citrix.com>
In-Reply-To: <20250509163212.2948359-2-andrew.cooper3@citrix.com>
From: Ross Lagerwall 
Date: Mon, 12 May 2025 10:47:11 +0100
X-Gm-Features: AX0GCFuOzBon7X8D6TaKYDLknTSlCe4NTEx7ATLagIh6KvGoVPqjNlzSMuxgvSE
Message-ID: 
Subject: Re: [PATCH v2 1/3] xen/elfstructs: Include xen/types.h
To: Andrew Cooper 
Cc: Xen-devel , 
	Anthony PERARD , Michal Orzel , 
	Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , Volodymyr Babchuk , 
	Bertrand Marquis , Oleksii Kurochko , 
	Shawn Anastasio 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 9, 2025 at 5:32=E2=80=AFPM Andrew Cooper  wrote:
>
> elfstructs.h needs the stdint.h types.  Two headers arrange this manually=
, but
> elf.h and livepatch.h do not, which breaks source files whose headers are
> properly sorted.
>
> elfstructs.h is used by tools too, so use stdint directly outside of Xen.
>
> Clean up trailing whitespace.
>
> Signed-off-by: Andrew Cooper 

Reviewed-by: Ross Lagerwall 


From xen-devel-bounces@lists.xenproject.org Mon May 12 09:51:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 09:51:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981091.1367477 (Exim 4.92)
	(envelope-from )
	id 1uEPoy-00034c-1p; Mon, 12 May 2025 09:51:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981091.1367477; Mon, 12 May 2025 09:51: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 1uEPox-00034V-UW; Mon, 12 May 2025 09:51:39 +0000
Received: by outflank-mailman (input) for mailman id 981091;
 Mon, 12 May 2025 09:51:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEPow-00034N-EK
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 09:51:38 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b22a128e-2f16-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 11:51:37 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5fc7edf00b2so5821359a12.2
 for ; Mon, 12 May 2025 02:51: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
 4fb4d7f45d1cf-5fc9cc5022dsm5567033a12.45.2025.05.12.02.51.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 02:51: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" 
X-Inumbo-ID: b22a128e-2f16-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747043497; x=1747648297; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zMU5lEUqSSOJeAR+XRiSwtI82z7Gp9nCdLB/I58XvSk=;
        b=WDz3Vsl+tFpxAqLkXDo/SeEMv3vztJVt3DfcuPrwestVa8p+ec4VLeIJ6SqPKLj/xb
         LLVJbJZWzRKSmgVZ8SM8y2qPtLr7u9k8kHCNNTLeh2Dz7CF2q+5CFqqrQL5l1qj+r4ir
         F+i9jWoOPulfpQqdTNcSQlm5KUFKoHNaUwko8GWhgpK7YbNmWeCxIyurlKajHa9vfL8Z
         QrbVGQuvQIE64yPDDBi46xYC8xq676Gd9gTLvOlra8rldSzQ27bdSSOoT1865SSq1LA9
         98adjdZWeBjEsGwNRUrE2E52PKiDS+a1blOJQ2MAg+QBsT7a7xdgM5SFkV79G1Rfyizi
         VZsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747043497; x=1747648297;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zMU5lEUqSSOJeAR+XRiSwtI82z7Gp9nCdLB/I58XvSk=;
        b=l+pFcsMZYjXTSz/BAB3vbq7+mmCOmIDLkzqwPlkG+xnHX2mS9A10dweG/gqh2phhgP
         MjqJXRFAynpQDB2lNKrXZHq7cIYAnG4Of84ebQnhw/Qahvyah+MLrSSz5kWG9OLndHBd
         QrHDmlcmvmSWf4H3sxYcj/ow9qDJZfbsWWeJE0kVgHqSXpmFdOy1VwvoheiG6eHkfJSj
         XUc2XGgSIp5lzQ37Mnbkdm9QwN9lt2puby71IdhabT0OC7l7AHFVBfu2kyjh+YBNXSw0
         4x9At67Ee2GkpEBOSWysVRonhM7CW1m3WhIlDJYyrMK0Y/mEgR1weXSVu6tlMVrUeC/x
         XRPg==
X-Forwarded-Encrypted: i=1; AJvYcCWI11Omt6faKI0Eyai+OXUt81BmYu2GOLOZMpKPqaqPw5to1/hTB2dfUNUHDwsAEC6caTZdL20MReg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YynJnEPiBm+RJRJXioQxfwVieMcQiZxmWybOHvY7oSUfADozKaE
	Fly/Zw5sQwvZ+hhr4WN87wAyNJd+zzg6IWKTfIENFkwHZVqpUYdPUSHL5ausfQ==
X-Gm-Gg: ASbGncvE6HKSWnjkL0gKLcucMsCqkE47Rl53hsDDTFPzHF83SDh5m8OU1c1SP5f8wl1
	wBWyeohNErhwNqWOBC3Ubqrne3H7JyBTZuHBzm6drHTePc/Gcl/kot2xDv19n32ng4BfblsU/oV
	BnI35F+XqIwmkfHszv4hRSy5g8iOUybOS6QEkr8Pkam9ZhpMShVmqYkyY1D6qP1guKGim1D7MHc
	Za4lSxWAlXRUP9AkpORSppAcuw/6IW0yGfFZ8l0kP/U9QMOS7POzu/Ig6ToeLC8BLl5J+7nbU/X
	n+nI8MUYzG2JNBIy202q0MM+4VKMZI2gRm6Hb6b9HzC09F/Wq7MoLVZnkQJ2GuKf9KN1abUX2RX
	jyQxb8eQMSIvrEkEJ9pu06mJY9sqs4keOYF1A
X-Google-Smtp-Source: AGHT+IELQcBELOUrCWn5bATjs8Tao0Pn8hZ6D7mO4bcr6nQDPByYlu6Y8b2sjd8hCHhOdolnYluezA==
X-Received: by 2002:a05:6402:1d54:b0:5fd:dbf7:b6e0 with SMTP id 4fb4d7f45d1cf-5fddbf7b9a8mr3371589a12.30.1747043496836;
        Mon, 12 May 2025 02:51:36 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 11:51:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] livepatch: Pass buffer size to list sysctl
To: Ross Lagerwall 
Cc: Kevin Lampis ,
 Anthony PERARD , Juergen Gross ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250508170156.558291-1-ross.lagerwall@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250508170156.558291-1-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.05.2025 19:01, Ross Lagerwall wrote:
> @@ -1328,10 +1327,15 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
>              status.rc = data->rc;
>  
>              name_len = strlen(data->name) + 1;
> -            list->name_total_size += name_len;
> -
>              metadata_len = data->metadata.len;
> -            list->metadata_total_size += metadata_len;
> +
> +            if ( (name_total_copied + name_len) > list->name_total_size ||
> +                 (metadata_total_copied + metadata_len) >
> +                 list->metadata_total_size )
> +            {
> +                rc = -ENOMEM;

-ENOBUFS or maybe -ENOSPC, but certainly not -ENOMEM.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 09:54:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 09:54:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981103.1367487 (Exim 4.92)
	(envelope-from )
	id 1uEPs3-0003fp-Iu; Mon, 12 May 2025 09:54:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981103.1367487; Mon, 12 May 2025 09:54: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 1uEPs3-0003fi-FF; Mon, 12 May 2025 09:54:51 +0000
Received: by outflank-mailman (input) for mailman id 981103;
 Mon, 12 May 2025 09:54:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEPs2-0003fa-JB
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 09:54:50 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 24ce5e74-2f17-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 11:54:49 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5fbfdf7d353so5577603a12.0
 for ; Mon, 12 May 2025 02:54:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5fe7fb0ac1asm1472731a12.7.2025.05.12.02.54.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 02: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" 
X-Inumbo-ID: 24ce5e74-2f17-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747043689; x=1747648489; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=JJR8nGXcvBL+82rNXCyAqA/QDBq6m+sH970tnT9G51s=;
        b=OgC/oygp1voEcuPejR4rLtyyauFzdm7OjhJ+JoYY/H+ZWalqMXGSV9P7g7p+bxuFpT
         ou0L2KPfzRORxk2Mtx/JllqXX5RpBD8drBUJe5hugeUcyeciV6/kh3fmCC6hFx+AjcAJ
         P1fZX2c+idrY68AbD6A6eySTpmo6OKdQsQwdiP2xRUMUg2CPzKLKdzg+4rh61IfsYiOi
         7YKuHlyr61KEyJ16t4MJJ5htDcD7ElANUs/vcaR/996/GMN1zcyHz5J26yZahApoyePS
         ZsdhsCSJrw5mLqmLCl5frQw1HP01oAYou8k4Mgt1uYKd1aD+ps798ltcvIIk1cOy+DJk
         RxEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747043689; x=1747648489;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JJR8nGXcvBL+82rNXCyAqA/QDBq6m+sH970tnT9G51s=;
        b=fu8m/uoz4PkzUVkESJS7I8HmMliJ5HqtDgFNBCK3l46c5DlDM2UqCCkodTNtsfK1AQ
         0X80IY64PSizzWxLrYImPeIlrGaz71odlyD0HGJzPlx8O2qvYUH7604XqMMH2XO3mO0Z
         BCUZOkVFvXUtTJ27GM+YcjDHZ5mxSRpahC1k0BbOa/l3eO23k6Om/MGLql+dEi1mTkeM
         qRfizlVR/kHc6dats7/ChDacffOpkvOHymewgtdAnUUPiySL1WmNlMhQyIwSGDhlZ89e
         smJfsV+pQaOZmzTsWfTN7C0SK1AEHqbc+4hb+nVfo1UhCN4qxcjWxEr5u3PwFEPDAeah
         DM9A==
X-Forwarded-Encrypted: i=1; AJvYcCWqB8/Ui2kKc7J4u4JkcpNHPMRc5Hu1nICQM7ddzqqK/bGw9VCmQzznN0oYhCe0crvcEtoqa/QWoLY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yygi4edQTXof/qP5CO5PJUrwnJDMEbWQx4uASGz/3XGi7ZalMOE
	bT2A/sag8GumDzqSiEB0wYm7z/XbN7ZbpamaGyEYwQwfdif3lPcQbdUdknJ1Ng==
X-Gm-Gg: ASbGncuq+DX1P3IlwInscF7iZCUVIZPprip29fXOOdiG0u1ciqTQeOgyYVTOlfUVD9v
	uYMZiVbtCUqO/BY9GiTsMYpg0n4hizclij/M/96p7+zi+TgLeZg1DkCNXBzKIhhTWLE+5ZRT0nq
	u7eh0Ux+EoXqL2jF327ZREJ4ICLe48tf9BkGh9rJKDs8Qmo9NfGasr5ZbwmYRE+nb0UVbTL6R6R
	IusYPxFbH/wihQfT3yX05m/2umHnwcAzl9QVUEsYOOjJfWJRBorAxbdKtTb+8fKj+SoqWoE9CNZ
	Nf6/O0rhQ4NjThooay60AverHlRd+if4CubotuZwmuyqxxHpYbLipMhN366MJ2yD/jHoo9QdKYt
	jv+mvZr63xmONO3h6VnzlaZgvAEMUTG4EJxWyu18CS9tEYIs=
X-Google-Smtp-Source: AGHT+IHqg7jA3wOXDZTdY5HYs6pVHQYGls6jLDS9rtCpCAOZXYhRXa0/RyH329p7uNkpe0b07+hfBA==
X-Received: by 2002:a05:6402:3582:b0:5f4:370d:96bc with SMTP id 4fb4d7f45d1cf-5fca07423c9mr9594035a12.2.1747043689164;
        Mon, 12 May 2025 02:54:49 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 11:54:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] x86: x86_emulate: address violations of MISRA C
 Rule 19.1
To: victorm.lira@amd.com
Cc: Nicola Vetrini ,
 Federico Serafini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis , xen-devel@lists.xenproject.org
References: <68d30d0b-1f85-4480-a2e1-0c9c5effb49b@amd.com>
 <20250502234917.3533514-1-victorm.lira@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: <20250502234917.3533514-1-victorm.lira@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.05.2025 01:49, victorm.lira@amd.com wrote:
> From: Nicola Vetrini 
> 
> Rule 19.1 states: "An object shall not be assigned or copied
> to an overlapping object". In the function like macro "get_rep_prefix",
> one member of a union is assigned the value of another member. Reading from one
> member and writing to the other violates the rule, while not causing Undefined
> Behavior due to their relative sizes. Instead, use casts combined with exactly
> overlapping accesses to address violations.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini 
> Signed-off-by: Federico Serafini 
> Signed-off-by: Victor Lira 

Reviewed-by: Jan Beulich 
albeit strictly speaking the description covers only ...

> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -527,8 +527,8 @@ static inline void put_loop_count(
>          if ( !amd_like(ctxt) && mode_64bit() && ad_bytes == 4 )         \
>          {                                                               \
>              _regs.r(cx) = 0;                                            \
> -            if ( extend_si ) _regs.r(si) = _regs.esi;                   \
> -            if ( extend_di ) _regs.r(di) = _regs.edi;                   \
> +            if ( extend_si ) _regs.r(si) = (uint32_t)_regs.r(si);        \
> +            if ( extend_di ) _regs.r(di) = (uint32_t)_regs.r(di);        \
>          }                                                               \
>          goto complete_insn;                                             \
>      }                                                                   \

... this hunk, but not ...

> @@ -2029,7 +2029,7 @@ x86_emulate(
>          switch ( op_bytes )
>          {
>          case 2: _regs.ax = (int8_t)_regs.ax; break; /* cbw */
> -        case 4: _regs.r(ax) = (uint32_t)(int16_t)_regs.ax; break; /* cwde */
> +        case 4: _regs.r(ax) = (uint32_t)(int16_t)_regs.r(ax); break; /* cwde */
>          case 8: _regs.r(ax) = (int32_t)_regs.r(ax); break; /* cdqe */
>          }
>          break;

... this one.

Also the padding of the backslashes ought to be adjusted, which I guess I'll
do while committing.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 09:56:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 09:56:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981111.1367497 (Exim 4.92)
	(envelope-from )
	id 1uEPtG-0004B2-SY; Mon, 12 May 2025 09:56:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981111.1367497; Mon, 12 May 2025 09:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEPtG-0004Av-PX; Mon, 12 May 2025 09:56:06 +0000
Received: by outflank-mailman (input) for mailman id 981111;
 Mon, 12 May 2025 09:56:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEPtF-0004Ap-QJ
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 09:56:05 +0000
Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com
 [2607:f8b0:4864:20::c2e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5146cd3a-2f17-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 11:56:05 +0200 (CEST)
Received: by mail-oo1-xc2e.google.com with SMTP id
 006d021491bc7-603f54a6cb5so2332959eaf.0
 for ; Mon, 12 May 2025 02:56:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5146cd3a-2f17-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747043763; x=1747648563; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Ru514p0VU8A70el8Z9O0WCBmp8aRtUjyz+oOmk0Y9Aw=;
        b=a6X31EL2A6DYUcWjdro25K+6sEtAuFPzAE48QGe1DIJcgmm5qMG1UhQ1MiOY0vyRUR
         aH+FIHQSU63yKQGFdh8ULbtXaFd55c5faTRqxit7/0FpLQIqLEwDjIAfjVe6tCJKykpd
         tuYe/Sree7BLI5BjshXFNoHhWPsHFwWznZbPM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747043763; x=1747648563;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Ru514p0VU8A70el8Z9O0WCBmp8aRtUjyz+oOmk0Y9Aw=;
        b=P0Au4YqtmkwA4ZIZKiS4fPguKAMarkrXakhqDuJ+hL9unt7WsMDlMl0fO8SEDmYLLv
         UK1Qm0y2hQiAqYpaXih6y6y+8aPU0Zfawammwn47+hp9sQZhlM27QnxEmY93DUKqN7BY
         kpxt0EEhoTm5NwNmuRdcdPeRPREZYXSydLzwWb60izGl2vYkU3Uc2ZzUGrnahxe4P4sS
         E8sM9fDBT/GEZwrzzfKQYnQ0200LxIbgK/vsR2klYpVjvZu9U3QoOFLQnchF00wa2fVq
         Htd8QnBq35kqUIqPZ9SccL0yqr2rZHMx2E+mIwfOpbxf6Z1Osx4MhqtE3ZDaM58j+VRi
         vlRA==
X-Gm-Message-State: AOJu0Yw/4qbC8ON+PWUFeU80y/uh/7qVB8rb+x+7bkjjScNPaaWEf92l
	lcsyUBFe5F3jHMaD+qCo9M+2bBbLmt6hURP836mM97SxyS9bVijBwo/9J3WI2HeBdAqH+MI538h
	Rj00l0wT6W6lTJcBNnimLj0EpO6j21moNKWI2
X-Gm-Gg: ASbGncsAoAf2tu0iBLEdwDwaKx0Cmstv2PqoMfQrMvLUBxGh6POevT03SFizraaddlT
	8KAsVncSuj3KPnnCfXpJOLsp7Tl5/L0jymhdBlzuc5aU9qpEYFqRiFeNdNMXTa/4uT7OtvoCRxZ
	XPPNXCeTJ2W4V4Mpn8Fv+5RNTdNE4fdaIDJyaLq1e6Dg==
X-Google-Smtp-Source: AGHT+IGgnaQJrJ33wsUSr8N3nzACdLB5RGAlbYC6WvOLtp7OUk4Yjli3/WSfJGLCe71HxNTH9f6HAMUgpM5f5sqIh9Y=
X-Received: by 2002:a05:6820:199a:b0:607:e15c:be07 with SMTP id
 006d021491bc7-6084c121a75mr7874360eaf.7.1747043763622; Mon, 12 May 2025
 02:56:03 -0700 (PDT)
MIME-Version: 1.0
References: <20250509163212.2948359-1-andrew.cooper3@citrix.com> <20250509163212.2948359-3-andrew.cooper3@citrix.com>
In-Reply-To: <20250509163212.2948359-3-andrew.cooper3@citrix.com>
From: Ross Lagerwall 
Date: Mon, 12 May 2025 10:55:52 +0100
X-Gm-Features: AX0GCFumObTO8T8ils2Fhg6RNBFLRU3PQMUZK3t6KADOyE_RXpoYZLGjmwsO1X0
Message-ID: 
Subject: Re: [PATCH v2 2/3] xen/livepatch: Fix include hierarchy
To: Andrew Cooper 
Cc: Xen-devel , 
	Anthony PERARD , Michal Orzel , 
	Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , Volodymyr Babchuk , 
	Bertrand Marquis , Oleksii Kurochko , 
	Shawn Anastasio 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 9, 2025 at 5:32=E2=80=AFPM Andrew Cooper  wrote:
>
> xen/livepatch.h includes public/sysctl.h twice, which can be deduplicated=
, and
> includes asm/livepatch.h meaning that each livepatch.c does not need to
> include both.
>
> Comment the #else and #endif cases to aid legibility.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monn=C3=A9 
> CC: Stefano Stabellini 
> CC: Volodymyr Babchuk 
> CC: Bertrand Marquis 
> CC: Oleksii Kurochko 
> CC: Shawn Anastasio 
> CC: Ross Lagerwall 
> ---
>  xen/arch/arm/arm32/livepatch.c |  1 -
>  xen/arch/arm/arm64/livepatch.c |  1 -
>  xen/arch/arm/livepatch.c       |  1 -
>  xen/arch/x86/livepatch.c       |  1 -
>  xen/include/xen/livepatch.h    | 10 +++++-----
>  5 files changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatc=
h.c
> index 134d07a175bb..8541c71d6e2e 100644
> --- a/xen/arch/arm/arm32/livepatch.c
> +++ b/xen/arch/arm/arm32/livepatch.c
> @@ -9,7 +9,6 @@
>  #include 
>
>  #include 
> -#include 
>
>  void arch_livepatch_apply(const struct livepatch_func *func,
>                            struct livepatch_fstate *state)
> diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatc=
h.c
> index e135bd5bf99a..39159ba8b5bf 100644
> --- a/xen/arch/arm/arm64/livepatch.c
> +++ b/xen/arch/arm/arm64/livepatch.c
> @@ -13,7 +13,6 @@
>
>  #include 
>  #include 
> -#include 
>
>  void arch_livepatch_apply(const struct livepatch_func *func,
>                            struct livepatch_fstate *state)
> diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
> index 3805b2974663..2fbb7bce60bb 100644
> --- a/xen/arch/arm/livepatch.c
> +++ b/xen/arch/arm/livepatch.c
> @@ -11,7 +11,6 @@
>  #include 
>
>  #include 
> -#include 
>
>  /* Override macros from asm/page.h to make them work with mfn_t */
>  #undef virt_to_mfn
> diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
> index be40f625d206..bdca355dc6cc 100644
> --- a/xen/arch/x86/livepatch.c
> +++ b/xen/arch/x86/livepatch.c
> @@ -17,7 +17,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>
>  static bool has_active_waitqueue(const struct vm_event_domain *ved)
> diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
> index d074a5bebecc..c1e76ef55404 100644
> --- a/xen/include/xen/livepatch.h
> +++ b/xen/include/xen/livepatch.h
> @@ -14,12 +14,14 @@ struct xen_sysctl_livepatch_op;
>  #include 
>  #include  /* For -ENOSYS or -EOVERFLOW */
>
> -#include  /* For LIVEPATCH_OPAQUE_SIZE */
> +#include 
>
>  #ifdef CONFIG_LIVEPATCH
>

Shouldn't the inclusion of sysctl.h be inside CONFIG_LIVEPATCH?

There is already a forward declaration for xen_sysctl_livepatch_op
which should cover the !CONFIG_LIVEPATCH side of things.

Ross


From xen-devel-bounces@lists.xenproject.org Mon May 12 09:58:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 09:58:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981120.1367506 (Exim 4.92)
	(envelope-from )
	id 1uEPvJ-0004k3-61; Mon, 12 May 2025 09:58:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981120.1367506; Mon, 12 May 2025 09:58: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 1uEPvJ-0004jw-34; Mon, 12 May 2025 09:58:13 +0000
Received: by outflank-mailman (input) for mailman id 981120;
 Mon, 12 May 2025 09:58:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEPvH-0004jq-Gp
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 09:58:11 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9bf62f9a-2f17-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 11:58:09 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5fc5bc05f99so8135211a12.3
 for ; Mon, 12 May 2025 02:58: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
 4fb4d7f45d1cf-5fc9cc4f240sm5487623a12.33.2025.05.12.02.58.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 02:58: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" 
X-Inumbo-ID: 9bf62f9a-2f17-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747043889; x=1747648689; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=y4MR3mRtHrBWNG5MKpQtUUeCHWbtPAyEinULCkGPeCM=;
        b=FOe/pXGtXYM/rtJunP+SvKimXifmEHB5PXFxGvPBWarg0XSv295BxPhC1e5kNZUGXt
         q2XMhqWMApomL/kC7z/RR4cP0P49ac/p/3RxQUS15k/P5T+jes29fks0SGx5vzQGnW+H
         jII+SChgEhw7XSb+jQDLQ4A+KcUo6MLttx8koFAEWYDZqd2KtJ3L+eSvCJbFyNSxZ9kp
         3Ix22eSxNh60Qr5t2wbJr0GT6PTYjplz0/wTgKzhFmgnEoNIteeedIdvREz2MSU/PsA5
         W4bqHF9lpwuIT97ApvePwbtHH2wW/7HNe+7ok7LgtynbqMX5nxdM4GHfYjwLtzPTWE4g
         f7Jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747043889; x=1747648689;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=y4MR3mRtHrBWNG5MKpQtUUeCHWbtPAyEinULCkGPeCM=;
        b=RgvfMvUwt3AHb16jEjCA8NfXpO/8vYLPSrZOSpmTmKIAF4pjpYp8DNJOuf09a8zJaE
         nJQiS47o7EUQUl+nY0ms1mDfmZCWb8nqkrk1xUavcCqJVcnToRVebBx/Eu/aBM6WXZpB
         fU3n8EinvuezgzdI4z5kDbImiBdnsZzMZKQOKGTyGiciOS49LnHr0ac2gTFP/iE/u7x8
         h4NaO2qGWHwV0/xC0zzZEy89RBW8kSdSr0A1wuDaFktC0fL4QM7QSP4YhpjSrjhfAPq+
         Z+HiNx7lvKebLUpaQzaIRk838uJHipsYcBkxlkvMJGb60MR2gK5f1zCRA0UeDUEDlrhA
         pMig==
X-Forwarded-Encrypted: i=1; AJvYcCXQp7CskPzL2ZHMgar5ogkI7iekFTGw3T6hi6//1B73kJ99go1R00jX326rtNERylnPmnt3JOTFxiE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxQtV0YpUYmwBJnwZC+1evFP9Kc0fRoYxC7MK4Co6EaShPN/m+Z
	dEdm7euj3VNFuoCKE3cuYTtljtTCraK31TaFgbxobPJpa23Y4v9mR1go9wp5Dw==
X-Gm-Gg: ASbGncvQTZN1Obsn4wMfO9v0qX3CFd2HQH9Mg1kF+iKzbdOPBsOuDJJ1BpaIF3EATtC
	V2KNKjQ7kdpVW9CYyzATz5X5a17DRp/zKogcK6s1rZfxj7yPkOo7Ne6m5gLmlD5YBZKEoGVxiJn
	yyXtLewZ2Bm1eFV+9gMX8B+Tmo8FdtbjeqyrD5bWWOoZ2jnNyqZInOlyHLsTHTsQu8ve5G+gh9Y
	3zzxdntj9pBbPo5meRZhvZQm5KnUfHDuwDw/qViOwmKKZ7p1GkmrvLJ85llOSxEz9xpgKGES/GY
	Ma4Gf4nlI8fRVlEBDGuqRQ05WurzFWRIk1LNSG4RuXJRoD5jTryeFFA/dJaWjLrtBpnYBLLJzFr
	S3k28EplSNoJQAhJt7ZZh6NzgD9LgsxLZtvUJFfjedEvHS/4=
X-Google-Smtp-Source: AGHT+IE6KJHUSgr7n0CwHUQUMdPbqv8zagAHExJD2n4ZSLO+Nh7AuXZ+xg7Z1kyfARcPNQKIcS0nkQ==
X-Received: by 2002:a17:907:cf46:b0:ad2:4b93:1205 with SMTP id a640c23a62f3a-ad24b9313cdmr431548166b.41.1747043889158;
        Mon, 12 May 2025 02:58:09 -0700 (PDT)
Message-ID: <0befe246-17cb-4e5c-811d-10a649c86729@suse.com>
Date: Mon, 12 May 2025 11:58:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/3] xen/console: cleanup conring management
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250504181423.2302345-1-dmukhin@ford.com>
 <20250504181423.2302345-2-dmukhin@ford.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: <20250504181423.2302345-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.05.2025 20:14, dmkhn@proton.me wrote:
> @@ -334,6 +344,9 @@ static void conring_puts(const char *str, size_t len)
>  
>      if ( conringp - conringc > conring_size )
>          conringc = conringp - conring_size;
> +
> +    if ( notify )
> +        tasklet_schedule(&conring_tasklet);
>  }

Just to re-state my earlier concern: I'm not convinced this belongs in a
function named "puts".

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:01:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:01:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981129.1367516 (Exim 4.92)
	(envelope-from )
	id 1uEPyV-0006kb-Jk; Mon, 12 May 2025 10:01:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981129.1367516; Mon, 12 May 2025 10: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 1uEPyV-0006kU-Ga; Mon, 12 May 2025 10:01:31 +0000
Received: by outflank-mailman (input) for mailman id 981129;
 Mon, 12 May 2025 10:01:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEPyU-0006kO-01
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:01:30 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1229c687-2f18-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 12:01:28 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad238c68b35so370004366b.1
 for ; Mon, 12 May 2025 03:01: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
 a640c23a62f3a-ad22f16271esm449859566b.103.2025.05.12.03.01.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03:01: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" 
X-Inumbo-ID: 1229c687-2f18-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747044087; x=1747648887; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=7eYMI+U6ZtMCOHreDEjup5mxhVO3mWqxrAvjpfknON8=;
        b=R7YxMroxjaHb+ie3OjNgcTo/W3z/sOfZMf1Mf7bIogwYTHPzaMIRr4nTm0KC/Mi44x
         fjojlEl4M4e3HO02NWmYcBwdkIO7Ngo2FTvRKXyOYz/33x2ZGnsSUwtMnClmO2GWbjh5
         CVXp104l3+e7P/BPgqshCFolrf8P/Z39doEUcamvTCYZALJWFlgaNFNZOmdpGYHadRTx
         HGoxcCU/8s/YXfaZe3mGL7+YpHAcW9YvOMjPTHGZMIHmxSohG1r1QL7IrkOktQ5wEEpy
         VYZcAyVs+5eaaQSUExMnP7uH13500RunPQ/T7GgGoDTnbKfpsDzUlHlNu06U7pehLfc9
         IErA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747044087; x=1747648887;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=7eYMI+U6ZtMCOHreDEjup5mxhVO3mWqxrAvjpfknON8=;
        b=xRjOiUxg+/JeXkd7l6ZMs4gRBAQXiVws0JFEP91S8roIq6QX6xPsp+Vx8ldHIhENAc
         eq0UdJRIKfNxk6VuNJiZKzoGgj4Jlx4NXJ6TvJHwPC/Pl+bGlIW5k6aFu+vqOottpI6p
         sGj6x7Y/CVFj10cbHjTvo9X/tD8nRerCBgGTEtuXYKIEjsxetqu4KNG8+xA55ikoYaW+
         SzfGNaID5aAj3IJnXomg/g1cib/NxagVoBuNWkHAQYs9F1oiqptGU6vzjgEOPmWMioyv
         FcQZsW/pun0fUwtTVZzao12cRy2+MIVNXvAxSCgO42zzavyEuyEE3vguQBZClER3MRng
         dazA==
X-Gm-Message-State: AOJu0YwMj/NjKYX+hLqB5oHwytPByjIf3WHH3dENgSPtLEBVDsq70KuU
	u6DNDrY21fVyTJBxwAMNiljsNag3FFwyLFPuOa0Y++VXLHmsBKNtzAkOmIKfrtyPPq8qEcU6jEM
	=
X-Gm-Gg: ASbGncuzbxpjBu7hGlMp6ZlaYAtUL+d13/eW/1BoNJ73khIMBODYvsk1rvvrCyUO/LF
	S1PvYGq4ruDx2DnroGAQkQgILxxP59dyqF+vVmmxheX6vM4YG1vKfTyD5eeyWLE579lRKB+55OJ
	VvUNPFDmnMeluswJxM88BEYelaxBX7iHkqahM9150z3ni9lFzvVbshGdi3SIvzDIpN6abYBhhKR
	0QyaGbzLhpJuCNMiBBKhbdg+54USOWXPGpHCADpdLsJPYjIH7QPUfytU+zGpK5K+OYjps8CSYS2
	m9F2A6V3JVTcb4JFFLn8sfrqHeI4hkeDPW8NhAouQmoxVC4eS7rN/JyGb4/cfcQrWwm2Tw0uYk0
	zGQYAiqjNtcTzSSoHqzxQ0+Dhx8jna6Td/ueP
X-Google-Smtp-Source: AGHT+IFFVbLPTdVb6oEG7MIPByXWkEzPFkhX4MEq4zQYRmGloNeQkXZcbqxiLNdFlc5stmb8douxaw==
X-Received: by 2002:a17:907:7fa6:b0:ad2:40f4:c251 with SMTP id a640c23a62f3a-ad240f4cad2mr649827666b.35.1747044087371;
        Mon, 12 May 2025 03:01:27 -0700 (PDT)
Message-ID: <57f4b57d-9382-4844-b29c-19f678642fa5@suse.com>
Date: Mon, 12 May 2025 12:01:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Issues on Zen4 (hw12) runner
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

On 08.05.2025 22:44, Marek Marczykowski-Górecki wrote:
> Hi,
> 
> I wanted to post another revision of the series adding hw12 runner,
> hoping that all known issues are fixed now, but unfortunately there is
> still something broken. I've rebased my series on top of staging
> (ed9488a0d) and got this pipeline:
> 
> https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1807819142
> (note due to some added debugging, some tests are incorrectly marked as
> success even if they failed...)
> 
> 1. USB ethernet doesn't work on PVH dom0: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739
> There supposed to be an USB ethernet device connected to the USB
> controller at c3:00.4. In the PV dom0 case it's detected as:
> 
>     [    3.911555] usb 7-1.4: new high-speed USB device number 3 using xhci_hcd
>     [    4.004201] usb 7-1.4: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
>     [    4.004675] usb 7-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
>     [    4.005079] usb 7-1.4: Product: USB 10/100/1000 LAN
>     [    4.005349] usb 7-1.4: Manufacturer: Realtek
>     [    4.005599] usb 7-1.4: SerialNumber: 684D35
> 
> But it's not there on PVH. The USB controller itself is detected, just
> not device(s) connected to it. This applies to other controllers too
> (there should be about 3 or 4 other USB devices - none of them show up).
> 
> 2. There is a bunch of "unhandled memory read" errors during PVH dom0
> startup: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739
> 
>     (XEN) [    4.026323] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0020 size 1
>     (XEN) [    4.026789] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0021 size 1
>     (XEN) [    4.027247] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0020 size 1
>     (XEN) [    4.027671] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0021 size 1
>     ...
> 
> This repeats several times. Could be related to the USB issue above?

Yes.

> There is also, likely related:
> 
>     (XEN) [    5.002036] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 2484: unsupported address 0
>     (XEN) [    5.002365] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 2484: unsupported address 0
>     (XEN) [    5.002693] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 2484: unsupported address 0

Not very likely - these are (sadly) normal to see when MSIs are being turned
off by the kernel.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:11:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:11:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981142.1367526 (Exim 4.92)
	(envelope-from )
	id 1uEQ8A-0000K9-Hy; Mon, 12 May 2025 10:11:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981142.1367526; Mon, 12 May 2025 10:11: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 1uEQ8A-0000K2-FT; Mon, 12 May 2025 10:11:30 +0000
Received: by outflank-mailman (input) for mailman id 981142;
 Mon, 12 May 2025 10:11:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEQ89-0000Jw-7D
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:11:29 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 775cf145-2f19-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 12:11:27 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5f4d0da2d2cso8023936a12.3
 for ; Mon, 12 May 2025 03:11: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
 a640c23a62f3a-ad219341d50sm605612866b.67.2025.05.12.03.11.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03: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" 
X-Inumbo-ID: 775cf145-2f19-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747044687; x=1747649487; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=PTrE+vs0DOehU0Z66/Y/RLnJByJiyzgoYdPLSY5fUWg=;
        b=D8LdD+YV2bc7A+6p3ToCt3x7PDUy/pZn8uLKXK0Lhl9cTgziMgJboCajsE1IVQI3fd
         Bkj2sY/oUtuJVASeuj2OlND4+/kNMCs946YJ+NgOrhVv5QDrqMhMr0yZO9oJwJ8A852e
         4/LVBoqPsA3KWMtNEA8K9kKU/0SdF+fkSLrezc2dP7utTwuqFM48yqhC4hp1uUA13mJX
         rxl/eoZmM52V+ZnqiHsLMp+CExS+xmat8mN7eEroAoIiYMCGVOSMb0KXxtAvi7MMNvUk
         Q/OERLhyTlgZ8GV4rDnHXmDOglXl+kaXSZPTlsytS/TgDFrLS5CEfUX630i+EgzWd4KF
         Rj6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747044687; x=1747649487;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PTrE+vs0DOehU0Z66/Y/RLnJByJiyzgoYdPLSY5fUWg=;
        b=mKiL+0IPC/IIb7BJa02flW8J6SQYzEHD+vxhw9k6FLVoFPoJk7acxAkFFek8Lug7bO
         Svo3diljyQH26HUut6baqhpsaG3ReD6fx54wgeUB7vTsRyxZ/yOKsEpi5eC7kTVAW4f9
         HdLy6X5pX1fuzFznsTCxOUtSr8nKTHVozYe6hsba9kdXeGhsMu4q48n8Y7VgpLjP1mbr
         4JPkExvFmKm6Z6eiheeJO+xPFPwy/62YX7BIB2zA990mZMtUUq2L9p5IPtyCvD4HPU1t
         LqozKPh8PTGx0khZsDxkUuCZTnxG9REXI4nb/0XjL/xfX83v7m3us9m49S1Sq1ncGZM3
         COFw==
X-Forwarded-Encrypted: i=1; AJvYcCWypgKrhDa2qSwTdRHyIL1cIanFbO6lNSLuEmlsc/1vKFodju7h6TUH/rekguTdEq26gd/o8TTDXFA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxlZCTeJk7GpUJ4/OPqhD4wVXAuKF6PO4tn0ej8yUDDXeYhwvqq
	pwBSb5Y8tNhZoTeqHRdEHhq/hHsaXwOkU2VNqibKCV4fkaWvoz6a2c9Y/JbyIQ==
X-Gm-Gg: ASbGncv0akRvg/3TQ2sDV5NJkv/p+rqBnY1toP6w7l8BEat3EdEqNvMtiHBr1gwuO9U
	i+RASiaYd1Ei8r64XEclnW7wFzK/ky3aFVVQKgS8XBhxDyLYyePdCJDj/7P2dJJ4op7fQtnZmcr
	DeP4/XEkeV7SsLhLqCkwaNaq4jO8mG+yLadUxIAO+wq8bIYV/Ui40CknjhOFS64EUKMD3y+iWV7
	Nbrzy+X1PRQjN+bRkhYveU0yzvBmnvXdNUp0QmgGZEJvLKLuA/MVGatBJ0emd4+uIBmsAdGEfAu
	yBNz5uHWf8c0NspYXJIWOKONkDHFObdainfOPcNToJLtMKN38hMVr9W74iT9MI/k6kWUB8g+B6g
	2jxPfiQBDZ8En9cH1APHCBNFLlaI+I2gWpKhMv+xr+Q4dVr0=
X-Google-Smtp-Source: AGHT+IFNdhv2H60dSEZXp87d9U2M84Y86kktv3xZiC7nQ1YQpgpathtF21rYvK5HI1JgzZmdzQVdrw==
X-Received: by 2002:a17:906:3b91:b0:ad2:23b6:149c with SMTP id a640c23a62f3a-ad223b61518mr852509666b.43.1747044686721;
        Mon, 12 May 2025 03:11:26 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 12:11:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/emul: Work around MISRA R13.2 complaint
To: Andrew Cooper 
Cc: Nicola Vetrini ,
 Stefano Stabellini ,
 Xen-devel 
References: <20250510001848.2993380-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: <20250510001848.2993380-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.05.2025 02:18, Andrew Cooper wrote:
> Rule 13.2 states: "The value of an expression and its persistent side effects
> shall be the same under all permitted evaluation orders".
> 
> Eclair complains about a Rule 13.2 violations because validate_far_branch()
> assigns to rc,

Followed by "goto", i.e. not taking the path to ...

> and the entirety of commit_far_branch() is also assigned to rc.

... that assignment. This pretty clearly looks like a tool shortcoming to
me, and I think it would be a good idea to ...

> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -333,12 +333,14 @@ do {                                                                    \
>                                : (ip) > (cs)->limit, X86_EXC_GP, 0);     \
>  })
>  
> -#define commit_far_branch(cs, newip) ({                                 \
> -    validate_far_branch(cs, newip);                                     \
> -    _regs.r(ip) = (newip);                                              \
> -    singlestep = _regs.eflags & X86_EFLAGS_TF;                          \
> -    ops->write_segment(x86_seg_cs, cs, ctxt);                           \
> -})
> +#define commit_far_branch(cs, newip) (                                  \
> +        ({                                                              \
> +            validate_far_branch(cs, newip);                             \
> +            _regs.r(ip) = (newip);                                      \
> +            singlestep = _regs.eflags & X86_EFLAGS_TF;                  \
> +        }),                                                             \
> +        ops->write_segment(x86_seg_cs, cs, ctxt)                        \
> +    )

... add a brief comment here clarifying why this odd a statement is used.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:25:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:25:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981151.1367537 (Exim 4.92)
	(envelope-from )
	id 1uEQLg-0002Fv-NE; Mon, 12 May 2025 10:25:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981151.1367537; Mon, 12 May 2025 10: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 1uEQLg-0002Fo-Kg; Mon, 12 May 2025 10:25:28 +0000
Received: by outflank-mailman (input) for mailman id 981151;
 Mon, 12 May 2025 10:25:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEQLf-0002Fh-Ez
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:25:27 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6b6e5e7c-2f1b-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 12:25:26 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5fd1f7f8b25so2506662a12.0
 for ; Mon, 12 May 2025 03:25: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
 a640c23a62f3a-ad24121e992sm327922666b.14.2025.05.12.03.25.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03:25:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6b6e5e7c-2f1b-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747045525; x=1747650325; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NM8bzkKpsuFwaLNDR+E7rPkOz8jqY5vVcfgKM8JJMVE=;
        b=NpJKc5IqL6PEF3LePtdHLlKAdk5nhbWFAAah3iYOxFmkTvco5Qo9sIxfH1SF/5tezJ
         lESzS+f9bS20lvcuG9sdla8eNMOwvWNp5xCHSOl1hMRuYEHHCkjsfmfpGoQzquyqpR4u
         VhnyPy7EvFdIAMaQRre82DPFxegStx5Qa2YGlVcTzczurWbHfKrSK7u17+GHbR9cFjeN
         TAi5Y+7X0RKdULV9y1NgoYbSF1zV4oGvN70pEbRFuuxqVi3nYgVQhA7fOkxKw7/qSuCd
         mPPYFJ2v7x6KIJyQdQsY3w9yBHNo8qpZaU+1VbKeMSokzy7z5NTIYUAELjOa6N3u0JXN
         MLYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747045525; x=1747650325;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NM8bzkKpsuFwaLNDR+E7rPkOz8jqY5vVcfgKM8JJMVE=;
        b=K9gXrVQtFOdvOYSZjtF1QkAnJs7xioJRa9tKny6cji24U9HPTFm3t+yJhWmTdhjpwh
         5+0OxRRRaNf8pjsKUqRrazHqGg9UMndZ0xHC7/ozqK0pJr8XEWLjCAsyZc3dILbKi9Bg
         rzOmgLgbKdG4IeyOA4oJ01uR0Oe0yo5ttOp544fa03C64oHW7V6OuK+HYhF8FR4ad75b
         hCY8+5ECXWFQxezqs9Z/g0o3XkcCo4qiIu8Zma9yot6T9JyKCuR1B++xv/5jXM62rlds
         f6TULOsnVPlr8LPrGTi5SGDNMIPASBUEKkkkUn3HkuE720gMtnDkdiJf3RZwCzjA6hPW
         eFQg==
X-Forwarded-Encrypted: i=1; AJvYcCWqnGrtE664wVnqKuxEnknDkGz8XUtHDeTkxyDkFoKa2HR9JoSBFj44LsVVXzwKpBMEwrJU4ZEzP+c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzhs3+cKOw9dRNL4894tQQDXI9oqDilvhnQEtVnl29Rj4FEmBoA
	qL+xcoa1qj9IRNOaCL3uvpdzlPQAJjZH/mmwPshfOLULZNipAaRpSCRhD2lJag==
X-Gm-Gg: ASbGnctfuSyFbVk1HJEyulY4LsdjelLJKeHUDojOtpU6dV/MbHyDoOfC4g5+zNvkajX
	+gsj3YRpa1KW33wXk+YGOssxbytne5sz7jjVw6QCapWwHVhoMZXAtr/hkz+z9Ui45PYmwtsqW9F
	CgkObsIEU5xdvl1zW8S7y7hiMteTmZk9qbJsO07kQu7ohBVEjFDQLzW4AQ6/YEu2mpAQlMlFvDQ
	+DX+1M4ZFnL/EysIPyhb8n8fpW2cHuO9sfWbHiLPIrkBNZ9DX+7EJCvRYjGHnXWNWwaDCjMgYd9
	LyNKs5HnNTv13CggFOhHYwKU4a9kfYcelQ1KQrfMG8rbBjHpp4ZDXMm4okABiCzIAWc4wAuBzGD
	DZEqh4fWtol2tsPhzzaW9ehdUAS/x8Tm/xgHrsZCOgzGQ17E=
X-Google-Smtp-Source: AGHT+IGIl5DyfL795X/2KS194TiJGhbYkDn1WtNj4eULi/EB+8Grymt7+jF+BaN5mn23qaYaXxHAgw==
X-Received: by 2002:a17:907:6b8e:b0:ac7:cdbb:bf4a with SMTP id a640c23a62f3a-ad218ea82e1mr1248340666b.1.1747045525660;
        Mon, 12 May 2025 03:25:25 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 12:25:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/4] Allows Secure Boot for Kexec
To: Frediano Ziglio 
Cc: Frediano Ziglio ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: <20250507094253.10395-1-freddy77@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: <20250507094253.10395-1-freddy77@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.05.2025 11:42, Frediano Ziglio wrote:
> From: Frediano Ziglio 
> 
> Using EFI Secure Boot all kernel level code should be signed and
> there should be no way to run unchecked code.
> For this reason the Kexec interface needs to be changed in order
> to allows signature checking.
> 
> The purgatory code is included in Xen itself as passing this code
> from userspace it's not secure (see patches 2/4 and 3/4).
> 
> Changes since v1:
> - update copyright lines;
> - better sha2 declarations.
> 
> Ross Lagerwall (4):
>   xen/lib: Export additional sha256 functions
>   kexec: Include purgatory in Xen
>   kexec: Implement new EFI load types
>   kexec: Support non-page-aligned kexec segments

As a general remark: You're sending all of these patches on Ross' behalf, yet
none of them has your own S-o-b. It is my understanding that strictly speaking
we wouldn't be permitted to take such patches.

Jan



From xen-devel-bounces@lists.xenproject.org Mon May 12 10:26:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:26:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981157.1367547 (Exim 4.92)
	(envelope-from )
	id 1uEQMO-0002kS-VS; Mon, 12 May 2025 10:26:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981157.1367547; Mon, 12 May 2025 10:26: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 1uEQMO-0002kL-Sn; Mon, 12 May 2025 10:26:12 +0000
Received: by outflank-mailman (input) for mailman id 981157;
 Mon, 12 May 2025 10:26:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEQMN-0002Fh-M6
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:26:11 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8642c65a-2f1b-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 12:26:11 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5fd32c133ccso1581111a12.0
 for ; Mon, 12 May 2025 03:26:11 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 4fb4d7f45d1cf-5fc9d70d8casm5471243a12.66.2025.05.12.03.26.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 03:26: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" 
X-Inumbo-ID: 8642c65a-2f1b-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747045571; x=1747650371; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=6ywf0azExOO5Doi1XVTmAOt0kUjtWQbeNjCZ7lEvoB4=;
        b=Y1WT02Mf4VE1v08HCQ5fPJoP2U2vmxtor8iSfmRAcI81ut4HZH662y2g4nUrO1YBFu
         g9afhAZbkFrIAqAE8WzXn/AXC9DnQ3yEbgUSllC2xgATMmZ0zp+diBPHLEvTBRvRIZjV
         o9pzuQjG3OPbWl8EFj7WpN61T0sAZb0IcNrWA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747045571; x=1747650371;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=6ywf0azExOO5Doi1XVTmAOt0kUjtWQbeNjCZ7lEvoB4=;
        b=A8dKGymdSZ9LqxzdgvfvBqkSPTbjwGgE7Przd3P7z87UhfSnsTO+coDDHCewV6ADAM
         bHFbNdXxFeZe939Ca3epu6npAoNLkY+1mO6r+PpVWZwGBkqAJ2uxuITUeCuYb85T+23m
         e+0Vph1YpzFiAq+rw9rpkwUkT4z5nvgb2rbEoKtOefzFj4XwWXlyFhI4dik4dD/eRAl/
         Zyhh5hJfu877KrNg0xuXr9LALLpyBDMDOkONI+G5hJh6AUo4qM7tIZkJnQie+DQTuO5K
         Fx4e9T8FRdri6f+FNvvYNExk1gzZl8U04NFWS94BOA5U42SueLc5e1Dj6BpTd0lc5GEb
         Ps6Q==
X-Gm-Message-State: AOJu0Yzyl6rwkAYclV5pNxanmKuy/wzofq1nxIWs02liiCMtp9tqKw12
	Gw88NIrOcOiMhjZXvJeLHecqTo/LPHYf8Lkb92ZuzDbp48qNh8V2c6UKL5rDnRVkYonDHlq7FYW
	q
X-Gm-Gg: ASbGncsZ8X8AJd/BQ5WAJzDRai3aoB+4lii4KmD3dWlaIJqSzmMi9zJ9hw9GlscG6Zr
	1x2097SzQhY0j0dXYXMDMsYOGX+OftLNwFgntOJzT11xoL2y3T09Y59f3pFX9RYPBZY1lWY+8+g
	F8nChmjEOZpgeeZXON4TbM5fSfDrs1FByENDsp/7+uupAlIG2gh8y9H2UyFEeTDsC2lhaDnAmco
	qbrNxxe1xJB6G79+p8bS31NDhieF9QlFcnsjirQ8Dwm5/5xAeWw5m3SGgnyv4TQeTn78Z6HNrvz
	XE6+wmK32asqxKu5NLyPWBKbLXX7IgKh6zsRTQVZMxRCMtRQDZGN/hMZ
X-Google-Smtp-Source: AGHT+IHIeO5g2riRZCFJSa2cKXYQWd14SmsECC1BeBlZHq5s/G8KOqrcq9wdV95c3naQG/llcUX0EA==
X-Received: by 2002:a05:6402:370d:b0:5fc:d2d2:193d with SMTP id 4fb4d7f45d1cf-5fcd2d252e6mr6668958a12.15.1747045570460;
        Mon, 12 May 2025 03:26:10 -0700 (PDT)
Date: Mon, 12 May 2025 12:26:09 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner
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 Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-Górecki wrote:
> Hi,
> 
> I wanted to post another revision of the series adding hw12 runner,
> hoping that all known issues are fixed now, but unfortunately there is
> still something broken. I've rebased my series on top of staging
> (ed9488a0d) and got this pipeline:
> 
> https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1807819142
> (note due to some added debugging, some tests are incorrectly marked as
> success even if they failed...)
> 
> 1. USB ethernet doesn't work on PVH dom0: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739
> There supposed to be an USB ethernet device connected to the USB
> controller at c3:00.4. In the PV dom0 case it's detected as:
> 
>     [    3.911555] usb 7-1.4: new high-speed USB device number 3 using xhci_hcd
>     [    4.004201] usb 7-1.4: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
>     [    4.004675] usb 7-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
>     [    4.005079] usb 7-1.4: Product: USB 10/100/1000 LAN
>     [    4.005349] usb 7-1.4: Manufacturer: Realtek
>     [    4.005599] usb 7-1.4: SerialNumber: 684D35
> 
> But it's not there on PVH. The USB controller itself is detected, just
> not device(s) connected to it. This applies to other controllers too
> (there should be about 3 or 4 other USB devices - none of them show up).
> 
> 2. There is a bunch of "unhandled memory read" errors during PVH dom0
> startup: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739
> 
>     (XEN) [    4.026323] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0020 size 1
>     (XEN) [    4.026789] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0021 size 1
>     (XEN) [    4.027247] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0020 size 1
>     (XEN) [    4.027671] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0021 size 1
>     ...
> 
> This repeats several times. Could be related to the USB issue above?

Can you try with dom0=pf-fixup?  Those unhandled accesses might be the
cause of the USB issues.

> There is also, likely related:
> 
>     (XEN) [    5.002036] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 2484: unsupported address 0
>     (XEN) [    5.002365] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 2484: unsupported address 0
>     (XEN) [    5.002693] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 2484: unsupported address 0

Is this at shutdown? (doesn't look like by the timestamps).  There are
cases where Linux zeroes the MSR entries while the capability is still
enabled, and that results in those messages.  They are usually benign.

> 
> 3. Sometimes it fails to print anything on the console, like here: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9977761447
> This is likely some boot issue before Xen starts (possibly the power button
> is pressed to early). Anyway, I need to fix it before adding the runner.

That needs further debug, I'm afraid I can't provide much suggestions.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:28:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:28:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981166.1367557 (Exim 4.92)
	(envelope-from )
	id 1uEQOB-0003JD-9A; Mon, 12 May 2025 10:28:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981166.1367557; Mon, 12 May 2025 10: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 1uEQOB-0003J6-69; Mon, 12 May 2025 10:28:03 +0000
Received: by outflank-mailman (input) for mailman id 981166;
 Mon, 12 May 2025 10:28:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEQOA-0003Iy-IQ
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:28:02 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c77a8601-2f1b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 12:28:00 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5fcc96b6a64so4116620a12.0
 for ; Mon, 12 May 2025 03:28: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
 a640c23a62f3a-ad2290a4cc2sm489535466b.183.2025.05.12.03.27.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03: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" 
X-Inumbo-ID: c77a8601-2f1b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747045680; x=1747650480; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=XX/SpC7l0v7XOnAbPzQ+K7NcMeRRtuqI9xd7Z7SsYXw=;
        b=SpTcJRuT1MkvFmUWAi4GcgaUibvUcVosCeb8hoX23zo7xrX5pb55bBV00wYFPMfDP+
         RXW8fiYtvtpzNxLyBpvxO9xveOmlIrj9HOkpdroZ/nf9mw9dXRA1RoRme4MkJZ/ZD8hL
         J9q/XoDhbwT4p0BSyIRl0A6WMFT8Xrb7+DRrkUZd0/eeyXA9YaQEH0a5FNtRcFTl/JrT
         vmYEORrzSZ5cyz0/4YmxJ361Kju05FiUOW2jDmWO0g/Xl3xgWqnGDSAN7k/dmINOk3po
         MqweqW09q5w3OE9cFNXk7c7n0Z81qszv39CDt8YiQzoaz/j1W+RK6QgPTUvzBuaHs+2e
         OUCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747045680; x=1747650480;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=XX/SpC7l0v7XOnAbPzQ+K7NcMeRRtuqI9xd7Z7SsYXw=;
        b=WAdnsrBZaM9Cd6FFAQ8h7e0sn5x3v7bZPkt+kyUFnlmfodRHuQ8UdBhymadRk5Q6Sn
         jBTXjnQyE/drPQ5vLSOmwyV0fmybR+Vf7lqsvm9gHdZr8dmSjpnQdz+N4738MxCCdOHT
         0ThdJNAY2BgLLMwClVgVbvYdeJFU39KpfK+JcFdE03udLgNyPOeHDRXBoBX4XgBEqDbN
         FrW+iupMjLJce+78TuZWPsEDpwcR3dG1N/3EVAThvOr3szmvum1yI02jaN7sBV9LK9Ny
         bVK9BxIuJEf3Z8CTOzduwXIYzbpWD9u2ARV4NwSURdfemZSCmxE1+3Qx86YlM4LV6UlO
         9v1w==
X-Gm-Message-State: AOJu0Yx1Sx9lQkTeoFwy49epDgd257VAGH3CclVnn8HK4myhEUNtUjHz
	lvSEK0E1iMgJGkKw2Af4Tx7r0FSqEb0VzWkiGyQ2MxZOysDTCOO+2TvrJApFlg==
X-Gm-Gg: ASbGnctJ9MftppiyFZXqCmCfxXxa58h+oE+x7ASH/00doYgUdIcKEmDh19jwXOIFAa7
	EBN/rRTDTPL2NRDzpmDsbnqwac8ZQXgKoIoIw80Ip9bw3YOHIbZbWxSMWqPQS3aQKGVrl1gR0Tj
	OGymfqxJhOHbCRQpdPiCpb7F6+cLc/jfUJwC9Z6XS0pZA7S8wqEZzGa2JAHZQFpPvhxruzi9vHL
	LDg5tLnbKyCXLZrjYsk2iYl0Jud06ab4Jo705ZXshTXHt/tIFjdII+7d3tm5IpToET1RD6bAeq0
	rY1XixspWYMTGvoxIH+LHgTDdwfQihpgVquUODd0l+UQJHTdZ0lifEHMqZaWDptOXuCWaLUbea9
	ghG6aj9WOAAL7w4MPi9ZO2DaAWPn1P/jDQIpr
X-Google-Smtp-Source: AGHT+IEfB73BdWUqScASbDsnPJRt6WdGZOSlC3Fv2mZugg7J7wYjBzdBZbmmQu3zkuNjQZ6K00jh0A==
X-Received: by 2002:a17:907:9810:b0:ad2:4144:2329 with SMTP id a640c23a62f3a-ad2414424e5mr633210566b.7.1747045680042;
        Mon, 12 May 2025 03:28:00 -0700 (PDT)
Message-ID: <10454237-2ada-4972-8e31-8ae21a6d6d22@suse.com>
Date: Mon, 12 May 2025 12:27:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/4] Add lockdown mode
To: Kevin Lampis 
References: <20250506162347.1676357-1-kevin.lampis@cloud.com>
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250506162347.1676357-1-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:23, Kevin Lampis wrote:
> Add lockdown mode
> 
> The intention of lockdown mode is to prevent attacks from a rogue dom0
> userspace from compromising the system. Lockdown mode can be controlled by a
> Kconfig option and a command-line parameter. It is also enabled automatically
> when Secure Boot is enabled and it cannot be disabled in that case.
> 
> Ross Lagerwall (3):
>   lib: Add strcspn function
>   efi: Add a function to check if Secure Boot mode is enabled
>   Add lockdown mode
> 
> Kevin Lampis (1):
>   Disallow most command-line options when lockdown mode is enabled

Returning from vacation, this series is a mess in my inbox (and also on
https://lists.xen.org/archives/html/xen-devel/2025-05/threads.html): Only
patch 4 is properly threaded. Please can you see about adjusting your
mail configuration?

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:28:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:28:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981175.1367566 (Exim 4.92)
	(envelope-from )
	id 1uEQOw-0003oE-I6; Mon, 12 May 2025 10:28:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981175.1367566; Mon, 12 May 2025 10: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 1uEQOw-0003o5-ET; Mon, 12 May 2025 10:28:50 +0000
Received: by outflank-mailman (input) for mailman id 981175;
 Mon, 12 May 2025 10:28:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEQOv-0003nz-87
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:28:49 +0000
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com
 [2607:f8b0:4864:20::233])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e2a94fb6-2f1b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 12:28:47 +0200 (CEST)
Received: by mail-oi1-x233.google.com with SMTP id
 5614622812f47-400fa6eafa9so2966800b6e.1
 for ; Mon, 12 May 2025 03: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" 
X-Inumbo-ID: e2a94fb6-2f1b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747045725; x=1747650525; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/XtbFrKz68AqwrIR8yQqRG98LYiZ3G4Jd1hdWbauKbU=;
        b=abtTiI+2oegqdqak22zF/kmuwq2WntyQh9GfMytWYU26bE71vM4Vu/6aM7K6ktaAVr
         kvXY/f/13VBGpTD6G1HcDIW7ziCb478G3sqRCkjYeKuIdf/psD1r2zAI8QZFuepw6h2O
         cDYmxsXg4KtvBBzCVo/5Mt/ic7vKjBrFYcru0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747045725; x=1747650525;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=/XtbFrKz68AqwrIR8yQqRG98LYiZ3G4Jd1hdWbauKbU=;
        b=eI3PVN1KNFII9hjUwPNpI0Z+HNzsL0F/PmCrV4iLw7aflCpAqmAvknlJ4anv/oz46m
         ea/F+6Dl0GV4MSItU8GTlh+sEXaXuWRWIJd34vtF/16x+vSPQIw0anBoMuHITy5q5JgW
         a2aFMjkt7XtbCxcemdFeGyLh8yNGcxT6nh+Fk+Cot7Fg2tyWchhbrskmN/UBOCriab3V
         d5WP2IOxHl5f4i50rELEnoNTcGniJdHhMvrkZcIIXLNeeht/x6AIwBv+7He7ihOmVOZ9
         uLFKiqVBUTJBo9Vd34+7V62EWrVVSoO+/LYsnuyo1ufu8Djoci3lvYi1dHAArflg1XTc
         ZAYA==
X-Forwarded-Encrypted: i=1; AJvYcCXF62ajW3nv4k+cry56D/nfQ1zKpyBbiaLb/Z9WJAMKAcTRMgAX00v7QRaNn7t4pO2Os8uSzG6RYSE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx5I1I0ZCFSlJmQqYOYLmR5Z7UC+zfZ3OK2BCCFCFca00WJQibn
	zreWeGcmjronh+JtCpUwHDmdx6nat8pmlBbV1LAvDw43xb0Y8Ub3QNsHrTV0thwSQD2R25eZmxa
	+PVSebu6PnEgdgPoYze9x462raC6qjtOhYp2JaQ==
X-Gm-Gg: ASbGnctLqnYkUS7BK9z1hBf38hmWshZpkYEQTFW6D6DjRkdzR3SgQctV6tNkPe/dRW5
	UTesgKYOPlh7Zh/4nnLKxb9zd8qbHSuGnN4joZlj1s72taaY2J/5dJ3Pf8IEo2Rczmyt7OXLfPa
	4BKv04mSEiuU6bLaf0gvDT8Zw/b+5yB8FF
X-Google-Smtp-Source: AGHT+IFFzu1ORYqSIozHZ3xuVTtZI83Oufch5vo7KWoUfwttPKBfoUPsyBxHX8RQgDTU0T4feH2qmc0i8QigLnnaRHM=
X-Received: by 2002:a05:6808:f14:b0:403:34b3:c986 with SMTP id
 5614622812f47-4037fe51d2emr8017117b6e.17.1747045725561; Mon, 12 May 2025
 03:28:45 -0700 (PDT)
MIME-Version: 1.0
References: <20250507094253.10395-1-freddy77@gmail.com> 
  <16fa3d79-7963-4334-a587-5cc289cfd693@citrix.com>
In-Reply-To: <16fa3d79-7963-4334-a587-5cc289cfd693@citrix.com>
From: Frediano Ziglio 
Date: Mon, 12 May 2025 11:28:34 +0100
X-Gm-Features: AX0GCFuWJfs8umPHia4GQaYwbcR7v0ED4R-F_frzpnSe2DqAv59YCt6K2LAZYaQ
Message-ID: 
Subject: Re: [PATCH v2 0/4] Allows Secure Boot for Kexec
To: Andrew Cooper 
Cc: Frediano Ziglio , xen-devel@lists.xenproject.org, 
	Anthony PERARD , Michal Orzel , 
	Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , Bertrand Marquis , 
	Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 9, 2025 at 6:40=E2=80=AFPM Andrew Cooper  wrote:
>
> On 09/05/2025 4:34 pm, Frediano Ziglio wrote:
> > On Fri, May 9, 2025 at 4:04=E2=80=AFPM Andrew Cooper  wrote:
> >> On 07/05/2025 10:42 am, Frediano Ziglio wrote:
> >>> Ross Lagerwall (4):
> >>>   xen/lib: Export additional sha256 functions
> >>>   kexec: Include purgatory in Xen
> >>>   kexec: Implement new EFI load types
> >>>   kexec: Support non-page-aligned kexec segments
> >> I realise a lot of this is coming from kexec-tools and/or Linux, but i=
t
> >> looks very very mad.
> >>
> >> From patch 1, we're embedding this in Xen:
> >>
> >> xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
> >> -rw-r--r-- 1 andrew andrew 30K May  9 15:24 purgatory.ro
> >>
> >> yet -Wa,--strip-local-absolute alone halves the size:
> >>
> >> xen.git/xen/arch/x86/purgatory$ ls -lah purgatory.ro
> >> -rw-r--r-- 1 andrew andrew 17K May  9 15:25 purgatory.ro
> >>
> >> Looking at purgatory itself, we enter at purgatory_start, load a local
> >> GDT, set up a local stack, call into C for the hashing (and nothing
> >> else), then jmp to entry64...
> >>
> >> ... which loads a (different) local GDT, (different) local stack, load=
s
> >> the GPRs and then jumps into the new kernel.
> >>
> >> Combined with kexec_reloc(), that's 3x we change GDT and stack in
> >> several hundred instructions.
> >>
> >>
> >> Looking further at patch 2, we only set up 3 GPRs; %rip, %rsp and %rdi
> >> pointing the parameter block.
> >>
> >> Patch 2 also contains an a large amount of EFI-editing logic (all
> >> vulnerable to XSA-25), which AFAICT exists only because purgatory is
> >> built non-PIC and wants relocating.  I can't see any external
> >> references, or anything that couldn't be resolved at link time for a P=
IC
> >> build.
> >>
> >>
> >> There are two things which purgatory does which Xen doesn't currently
> >> cater for:
> >>
> >> 1) Setting up the GPRs in that manner
> >> 2) The digest checks
> >>
> >> #1 is very easy to fix and can probably even be done on the current AB=
I
> >> (older Kexecs using purgatory won't care), and #2 ought to be easy too
> >> by extending machine_kexec().  We can do the digest checks
> >> unconditionally (it's a sensible check irrespective).
> >>
> > I think the problem of #2 is that doing in the purgatory avoids
> > problems like possible memory corruptions. For instance if the host is
> > crashing due to some corruption it could not always be possible to
> > boot the saved kernel.
>
> It doesn't really matter if Xen does the digest check right at the point
> of exiting, or purgatory does it moments later.
>
> If there's memory corruption anywhere on this path, we're not making it
> into the crash kernel whomever does the digest check.
>
> Crashing is a best-effort exercise; it's never guaranteed to be successfu=
l.
> >> I think that removes the majority of this series, with no loss in
> >> functionality?
> >>
> >> Given that we're leaving the signature check to the dom0 kernel (which
> >> is TCB and therefore can in the UEFI-SB model), we just might be able =
to
> >> get away without any hypercall changes at all?
> >>
> > Yes and no. The user space could not provide the purgatory. But if the
> > kernel is providing it, preventing the user space to send it, I
> > suppose it can be done. At this point however the question is how to
> > change the interface provided to userspace for doing it. It could make
> > sense to have the changes in xen/include/public/kexec.h and let the
> > kernel do the rest.
>
> I'm not really suggesting any change in userpsace/dom0 kernel.  I'm
> suggesting "we don't need a purgatory blob at all given two simple
> changes in Xen."
>

Maybe it was not clear from my previous comment. A change to the
userspace interface is needed. One reason is the mentioned purgatory,
it cannot be provided by userspace. The other reason is checking the
signature, the kernel should be passed verbatim in order to check it.

Which specific 2 changes are you referring to?

Given that the kernel already does the signature, having the kernel
providing the purgatory too would be sensible.

> This in turn means (I think) we can drop all the ELF relocation logic.
>
> I'm unsure whether we need new hypercall subopts or not.  Even if we do,
> I think the result can still be more simple than currently presented.
>
> ~Andrew

Possibly the Xen interface could stay the same. Still, as explained
above, a userspace change is needed.

Frediano


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:30:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:30:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981188.1367577 (Exim 4.92)
	(envelope-from )
	id 1uEQQb-0005KH-0d; Mon, 12 May 2025 10:30:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981188.1367577; Mon, 12 May 2025 10: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 1uEQQa-0005KA-U3; Mon, 12 May 2025 10:30:32 +0000
Received: by outflank-mailman (input) for mailman id 981188;
 Mon, 12 May 2025 10:30:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEQQZ-0005Jz-Pj
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:30:31 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 204d40e2-2f1c-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 12:30:29 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5fbee322ddaso7989555a12.0
 for ; Mon, 12 May 2025 03:30: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
 a640c23a62f3a-ad22ba81523sm478522766b.65.2025.05.12.03.30.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03:30: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" 
X-Inumbo-ID: 204d40e2-2f1c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747045829; x=1747650629; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=qxBFwOrE2bnSFKACUIjLu8C6mPVqsvcsDc3vKP6l4JQ=;
        b=TKBcd/BofoRQqPKYQax8ObS3Zs7BeDZ1Rk6ggFt2Xnf+YizMEK1fnKnbGR3x8BV5xW
         gq6Eyq8H7D1eA0xhTg11hKtBE7p5evtypLxnVSj09XZNuSQi4doEcBzOel78+HmZ0tY6
         3LWVVWFPr56fZPVzRyEG1U78j8o79B8CkaJPsAJ3m/z7/VBpSAjnmlVdR4m25cDhB4IP
         UmEZ4081a+zNhiI2d4/7K6OYiqAZDZbfM6NcPBv30eftOKgA1oXXmNu9ePAockS1+abq
         CmBzPooPBAtSv8fbM6GKnHaSaaQLiNuakV/rNG9X4SU4vaQUufMqGINuGytBuL70Fvvz
         gILA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747045829; x=1747650629;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qxBFwOrE2bnSFKACUIjLu8C6mPVqsvcsDc3vKP6l4JQ=;
        b=cr/7gs5lirXx+w9pVTg65UigObLEoxj565BYmSFtO1RX6Vr2hvbKVWptLbxxZqLHRn
         JXzm390lY5PNo6DXiG0EMrLhwRY8cuhV2mIahh5Tbdl9h230Y+4sl1tikWkioMApmb66
         WJL8s2hEPzMmWlupEYRjSOucxkGpYJFgpVf2MO28E3X/ZQ8/uXHZqzzdU8RHpGwGYjBC
         FTUfwcof9LGAxtGcq75eTSgt9e9LN/bSRUZm/R80EYs+OwgBBSXXfBK1E8+MaT6GbkoR
         YkcwHBRQtL1zUVBeU3seSHhrKH34ndDZZpTprjodPU/I7Aihs2QpXeWFtCg9aLjQHEtg
         ApdA==
X-Forwarded-Encrypted: i=1; AJvYcCX/wQ7kBwffCzzq2HDd3cALFXZ+lUH2AOHkxV4piGDIfZa5u9wK8vxB3b304QJP8pWMVt+JFK5HVZc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzWFvk0HM0gyLC6xdObu1t8RRXxp1kMNWUSJCGnQiQRqp/Su4uJ
	p3y0HkG1HApzUK3FEmmHLeoLsS2IVGMuMOXz9Gi5AbJ4JxlyeYZTdPHaH2XEgw==
X-Gm-Gg: ASbGncumUiuVNgrkfAOQzowbsGLAbA5N8apg1o5Z+Xzf7IdPoHb/GZ/6tB4XGb1jud1
	o3oF76165NPkBjT4hStuFHQMUCrqBrkv8FuX3zOcZNLI63qNYVv9N8y1u3z+Vk2+U7Z5nQV5A03
	us2yDE9jjBs9h8jqLkWCQRM16CoTrZrWdrXueuRjJwU5vJ4pVGpEFL0KeyZa8otsA9c2N1LiEbo
	E45IHdsOKqebAIkcsUTgDrXShve8m9NxNjH9LnHLp8POmQYxCGsRIZhzmEfAigSZZHk/pjmSANR
	HpOE0nW9+qLChXHraKLtCrRpaOKt27QKRDp3rkyzDoc0XtI5Rxs8HTgWdPKoM5iMtLaGEq8aKcj
	FpwqjwyGqk9M/Ak5/Td7wPIHGcwNknXM6Jh+h
X-Google-Smtp-Source: AGHT+IEFhd3UjbTYJ/Bd2wL/ThC6R1aIHc3vdHsEwy75zqIimtXwY1sbYG8rBsvuVjcKe7Qkw0AXzw==
X-Received: by 2002:a17:907:94cb:b0:ad2:47e7:3f39 with SMTP id a640c23a62f3a-ad247e741c2mr541274166b.54.1747045829081;
        Mon, 12 May 2025 03:30:29 -0700 (PDT)
Message-ID: <0bb898cb-b68b-4b38-b142-a057b3f2b856@suse.com>
Date: Mon, 12 May 2025 12:30:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] xen/lib: Export additional sha256 functions
To: Andrew Cooper ,
 Frediano Ziglio ,
 Ross Lagerwall 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250506135655.187014-1-frediano.ziglio@cloud.com>
 <20250506135655.187014-2-frediano.ziglio@cloud.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

On 06.05.2025 16:05, Andrew Cooper wrote:
> On 06/05/2025 2:56 pm, Frediano Ziglio wrote:
>> diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
>> index 47d97fbf01..ea8bad67e4 100644
>> --- a/xen/include/xen/sha2.h
>> +++ b/xen/include/xen/sha2.h
>> @@ -9,6 +9,16 @@
>>  
>>  #define SHA2_256_DIGEST_SIZE 32
>>  
>> +struct sha2_256_state {
>> +    uint32_t state[SHA2_256_DIGEST_SIZE / sizeof(uint32_t)];
>> +    uint8_t buf[64];
>> +    size_t count; /* Byte count. */
>> +};
>> +
>> +void sha2_256_init(struct sha2_256_state *s);
>> +void sha2_256_update(struct sha2_256_state *s, const void *msg,
>> +                     size_t len);
>> +void sha2_256_final(struct sha2_256_state *s, void *_dst);
>>  void sha2_256_digest(uint8_t digest[SHA2_256_DIGEST_SIZE],
>>                       const void *msg, size_t len);
> 
> sha2_256_digest() is unlike the others as it holds sha2_256_state
> internally.  I'd suggest having all of the additions below this point,
> which group them more nicely.
> 
> Can fix on commit.  Otherwise LGTM.

I notice this was committed, but isn't this introducing new Misra
violations (extern functions without external callers)?

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:32:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:32:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981197.1367586 (Exim 4.92)
	(envelope-from )
	id 1uEQSb-0006L5-AZ; Mon, 12 May 2025 10:32:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981197.1367586; Mon, 12 May 2025 10: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 1uEQSb-0006Ky-7p; Mon, 12 May 2025 10:32:37 +0000
Received: by outflank-mailman (input) for mailman id 981197;
 Mon, 12 May 2025 10:32:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEQSZ-0006Kq-KH
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:32:35 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6a4797a2-2f1c-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 12:32:33 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ad2440926adso232092466b.1
 for ; Mon, 12 May 2025 03:32: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
 a640c23a62f3a-ad2197bd432sm591146466b.129.2025.05.12.03.32.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03:32: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" 
X-Inumbo-ID: 6a4797a2-2f1c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747045953; x=1747650753; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GJbhpxkf3ajSrDGzznvlJI+SxDkvgHXqyvATii9gm3M=;
        b=g87TbXgmgpLtbFwRgTkB28DwftUP79tV6w4eu3lni7wiTLvAIzg6a64zMARjR35gK1
         NoigRMkkGAniMb/O5GeRycqk6DbwYEDctP65rMn/xbEtSHXTGZeGj6LlrMzAVBvVRw8Q
         tvD4zSW09FX7OeytNq8bOpAPjIDj4NVg3SPdTPj7ULwUELx3AtK6393FC6oav1K7sDA9
         u0bhxOkA251c65OBZgsQ0bnySq2bzwBjuQ1Ka9TvQwNxNoXOLTOmQKmoJ2iZnDU0Hs4t
         Ingx1SqRRA+sLxLoaJTgejcNXFr61yXcht3lQ5/S60LddiCMMD8DAvMqG8aZnR9ukhy+
         cMDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747045953; x=1747650753;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GJbhpxkf3ajSrDGzznvlJI+SxDkvgHXqyvATii9gm3M=;
        b=vpJYZhacIrqrMkDW2rqO0sfKZfbs+23z0rZZ456EIM+hzMc+cKL8H0wv+d09Zb7iSz
         h8S/pY99fodeoErdPblZWtpUsnZA+KtJyNobgJj1oPcoa9t2bBdtosEOiE0CJ8/ho2Z4
         bB80RwtoX/0EHslzex85KAm6M3dc/NfOrN1LTtLjgq272MkuG1fquJADAjmYxQqSBxqs
         QTjPu//V6JtFa6Qie/aHdgfbxxrubggdUSdp+o86WagDAC+Qfov1MVZjj+K/mQbsewtY
         S5/8gNwj6q2L0Gis+zPCPNskGZpm89Q/qkskM1CcgRAU7YD4PDAagCNfWrvPFQotI/Bf
         PAQw==
X-Gm-Message-State: AOJu0YxL2Sd1J49DKo7m/BZxrWt0q5f5ee8LfITzdeW+pcCjcc9bmw1j
	oi08a7d58f+ZPKk13Amzwk21tWZC7IvnQyVLpLixrdrY5+XOZg+ddygjynE/qg==
X-Gm-Gg: ASbGnctmjUnh4xC+7RtUCmSPCLClRO4IE3S1OIeIvtq9LzrcnHDMr1Ok5LTAnt98IyE
	bo1NhT7AxM8Y6+WJrgnKGhpsnbhNeZK1A2gWt9hlCbvyPIwkKwHE98htCuO6FXPdsdKKOWLeioH
	l5Tq2QQgsXQ8/Su8wqcyvSfDPkiF+KDyyy8yUPpLAtIkEVtp+duXHL7cRuhNAwfCBp9IcMvZSzv
	dCz3afog1kZeY/AlQt3haBWmd+vJsqfxLjhwR1bWE64LNDLCoAlr2Rvx6hq+SVfQp99pcHGwuq1
	w28+miWQpA5fMybk4+3pJUBtH+XVvKESbEftizx6vwTs7CPQWdDYo+D6Fo6bWNuqy5p/gIkWcQJ
	uKGDlsCSMHdSlGaGnqRvAYOHXNmOnuGk5zEMs
X-Google-Smtp-Source: AGHT+IHQTqH8s9Nx5x6BNxhk9D5wki9EK8zVdMoRuE+eDnCoX5fZGhyRl5gsezockGzTj5HF4sjtWw==
X-Received: by 2002:a17:907:72ca:b0:ad2:3d34:e2a4 with SMTP id a640c23a62f3a-ad23d350ffbmr693850366b.30.1747045953235;
        Mon, 12 May 2025 03:32:33 -0700 (PDT)
Message-ID: <99937f20-a6e8-4bd5-afcf-8f57c925eca4@suse.com>
Date: Mon, 12 May 2025 12:32:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] lib: Add strcspn function
To: Andrew Cooper ,
 Kevin Lampis ,
 Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org,
 "consulting@bugseng.com" 
References: <50a2737a-611a-4d83-aee6-de23619b0b6b@citrix.com>
 <20250507144515.1704100-1-kevin.lampis@cloud.com>
 <1aefa7da-7f90-4163-b9bb-78b9f98099bd@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: <1aefa7da-7f90-4163-b9bb-78b9f98099bd@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.05.2025 11:43, Andrew Cooper wrote:
> On 07/05/2025 3:45 pm, Kevin Lampis wrote:
>> From: Ross Lagerwall 
>>
>> This will be used by future patches.
>>
>> Signed-off-by: Ross Lagerwall 
>> Signed-off-by: Kevin Lampis 
> 
> Reviewed-by: Andrew Cooper 

Like for the sha256 change - isn't this introducing a new Misra violation
until a caller appears? Or are we deeming this okay here (unlike in the
sha256 case) because the CU will only be included in the final image if a
caller actually exists?

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:35:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:35:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981206.1367597 (Exim 4.92)
	(envelope-from )
	id 1uEQVj-0006sn-O0; Mon, 12 May 2025 10:35:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981206.1367597; Mon, 12 May 2025 10:35:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEQVj-0006sg-LJ; Mon, 12 May 2025 10:35:51 +0000
Received: by outflank-mailman (input) for mailman id 981206;
 Mon, 12 May 2025 10:35:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEQVi-0006sa-Ma
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:35:50 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id de5fefe6-2f1c-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 12:35:48 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad216a5a59cso454326466b.3
 for ; Mon, 12 May 2025 03:35: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
 a640c23a62f3a-ad22ba47376sm476427566b.53.2025.05.12.03.35.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03:35: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" 
X-Inumbo-ID: de5fefe6-2f1c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747046148; x=1747650948; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/TQxKoDRpi2LmoDIwPG42ja98rh9/A6V3O+YYXOfXc4=;
        b=TNbsiFTOKtsfdygvbQOhX4LFTcdfiKLXOJwUmtgK9+rO9852brWzE9TljYWV47DY/F
         k/LlGN7ueaILvr7DISToKKdh/7R/Y0Lzjz21x5t/3w55qhw6QizHhoux8AlKZzCi1hOe
         Z/pToN+0syf0EUp4X7imckTChQ+kruq1bppbAT+tD4a//7Obrm8cuPO4GrGaQR5dGwIR
         U2KHnQYKxeZE3ywu3/TnAIs1K2BpdDkkH2F4o3IDwnLd7qaoN4Uj3ZxAXPebbH3vu3ry
         LokD0oOI32xnn/QIFnYn0+6orGzrQanj7C+F0MS0a3DZiuHfjb51kKJe7YhE5WdnpCHX
         +/MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747046148; x=1747650948;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/TQxKoDRpi2LmoDIwPG42ja98rh9/A6V3O+YYXOfXc4=;
        b=LJ4qvGKgt5FlQdny9YFyKM8cPmcleGYpEWK/cAtJE4ILp12iYabmF3AHBv5aO+vFGD
         DOvXlk3nEu1w6J71xkqgST0TMuHAF/0h/k5mRKjrhSbyGWLa5DEMmoM10h2ORaIcU4dh
         LmsHa4osR/H+GZ38Ju9WXG+OLDmw4r86Go2/lzYl5gG5lop2bYhPJgVOIw4tmIg01iAS
         Un0YGmkdxTKHU1/m/yZjci1gakb/UI7h7ce0H+SSXwRW1V8c1/paSDDN1r61ZKU3nL+j
         Rp9xQVLl5xZQLYcTP02UHLOmixC18x3eIgs+eYQDMkGUYVdoP2oTfskrXcimM56Om1qB
         Jewg==
X-Forwarded-Encrypted: i=1; AJvYcCWbkfJXEhDY9oTyI6K/3SiMOluRGp31nvuNSLeU1p1LG9H15X9sirIUsuOzG6sIWWsL0acDnXO1++o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYXp6nFnebHUj79TE/Ek9ORhUWFpexLCnzO37QkvfoeUrUd42u
	Xb6g831MqH06q5Ll1Nj8tmmH4IdnkxdEGFCAdDg1/nqNncz8GdHW+huxZ8d1xrkoVDteh4F+Xgs
	=
X-Gm-Gg: ASbGncsOlZNizeqzbaeyMNV5MLKi+81NmZxjhkrMUz0htNI81PlH151TeNjz/+LmT8h
	1sJOdkBHu7W7bQWCASPN26+kfAOeiopPUQR9kdFS7/U3ZQ77TxKv2o+Oitpyc+EaAqo9qTWRTBo
	829M1Gfrw8jgNFxMri9DVK0MmCLx+DqTFE61wCSZFr0PVWX30dOzVaR+KcPkw3krVyv5IHfXoEu
	sVpQo33zbbKX/+TJwVYf8kVPShIzoVbhOZKKWSoVdDNBJFr8nQIZp7W7hHbCW9eqe0L5sj7Y02U
	Y2Kw7vqEV84ENb5oES4EAzmQ/7p2NVc/GTXDK7bjAic1+a/7MVf+74ehjV6vo84jnAXXyzA2q43
	FyZ1ROg+IGE6ZAg9Vk41vwm0zK2vY+KKv5vdqVTLypWxqWpo=
X-Google-Smtp-Source: AGHT+IHJNi7M6wNvfj9jogqHyBDe742zT4P16y/6DSjsYArkTmyDoexsaE/+oPaHHq9kD5FMpXxK8w==
X-Received: by 2002:a17:907:6a13:b0:acb:6746:8769 with SMTP id a640c23a62f3a-ad218f48713mr1223416466b.18.1747046147995;
        Mon, 12 May 2025 03:35:47 -0700 (PDT)
Message-ID: <35e372a2-3ec8-415a-a594-201b8b0d8bd6@suse.com>
Date: Mon, 12 May 2025 12:35:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] efi: Add a function to check if Secure Boot mode is
 enabled
To: Andrew Cooper ,
 Kevin Lampis ,
 Ross Lagerwall 
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Daniel Smith , xen-devel@lists.xenproject.org
References: <20250506162449.1676405-1-kevin.lampis@cloud.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

On 06.05.2025 18:55, Andrew Cooper wrote:
> On 06/05/2025 5:24 pm, Kevin Lampis wrote:
>> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
>> index e39fbc3529..7c528cd5dd 100644
>> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -870,6 +870,27 @@ static void __init pre_parse(const struct file *file)
>>                     " last line will be ignored.\r\n");
>>  }
>>  
>> +static void __init init_secure_boot_mode(void)
>> +{
>> +    EFI_STATUS status;
>> +    EFI_GUID gv_uuid = EFI_GLOBAL_VARIABLE;
>> +    uint8_t data = 0;
>> +    UINTN size = sizeof(data);
>> +    UINT32 attr = 0;
> 
> Newline between variables and code please.
> 
>> +    status = efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &gv_uuid, &attr,
>> +                                 &size, &data);
>> +
>> +    if ( status == EFI_NOT_FOUND ||
>> +         (status == EFI_SUCCESS &&
>> +          attr == (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS) &&
>> +          size == 1 && data == 0) )
>> +        /* Platform does not support Secure Boot or it's disabled. */
>> +        efi_secure_boot = false;
>> +    else
>> +        /* Everything else play it safe and assume enabled. */
>> +        efi_secure_boot = true;
>> +}
> 
> I'm not sure this logic does what you want when a weird answer comes
> back from GetVariable().
> 
> Also, you can't have this be a common function, yet ...
> 
>> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
>> index 7e1fce291d..b63d21f16c 100644
>> --- a/xen/common/efi/runtime.c
>> +++ b/xen/common/efi/runtime.c
>> @@ -40,6 +40,9 @@ void efi_rs_leave(struct efi_rs_state *state);
>>  unsigned int __read_mostly efi_num_ct;
>>  const EFI_CONFIGURATION_TABLE *__read_mostly efi_ct;
>>  
>> +#if defined(CONFIG_X86) && !defined(CONFIG_PV_SHIM)
>> +bool __ro_after_init efi_secure_boot;
>> +#endif
> 
> ... this variable exist only on x86.
> 
> Also, why adjust it for PV shim?  None of this is even compiled for PV shim.

For shim it might be (and a proper variable is needed in that case); for
shim-exclusive it shouldn't be.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:39:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:39:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981215.1367607 (Exim 4.92)
	(envelope-from )
	id 1uEQZK-0007Rs-7c; Mon, 12 May 2025 10:39:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981215.1367607; Mon, 12 May 2025 10: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 1uEQZK-0007Rj-3r; Mon, 12 May 2025 10:39:34 +0000
Received: by outflank-mailman (input) for mailman id 981215;
 Mon, 12 May 2025 10:39:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEQZJ-0007Rb-CQ
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:39:33 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 63d10dcf-2f1d-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 12:39:32 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad4ce8cc3c1so14697166b.2
 for ; Mon, 12 May 2025 03:39: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
 a640c23a62f3a-ad24677c9e1sm276342666b.88.2025.05.12.03.39.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03: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" 
X-Inumbo-ID: 63d10dcf-2f1d-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747046372; x=1747651172; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=exQPuTht+GSMr0VIsjWW4944+BjRY/yJqL7kMbH5fUA=;
        b=K4XAbBm36ocj6mbW7IQ2fmqLUJRQc+tbb3KZdPLfuOkB7vglAucEnJvPmxow+1ShsK
         X4nBNdebhWntHFsP7wqJLdQOGE2zg0p4wNZ/gbdx3K6zpf+phsMDHEnjpou4AhmOHYke
         6FkE2bUOQxGbueCJXFH9VyD92jvj2hfy+A5O+E39GSxDXLW9LcZ5p501ILRMQSNMNUhk
         DBOQDqLNrGQhx/83QOtmmKqxn1dlNBYdzKwqyXOWfAqtVkIa5cUaQUe9wCPqbvYsIm0n
         32BBCADzP8QZFCIoYK9fvDP0KudLS1AX7T62VKodIp7K9o72MN74WwGwJjAjuj7EirIB
         P+2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747046372; x=1747651172;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=exQPuTht+GSMr0VIsjWW4944+BjRY/yJqL7kMbH5fUA=;
        b=vcgEZ/uID0yKhxyuKjYlcE06i6u1nx5473PSP+7IZwBTLfJugOz4bZ3Og7xlPTHCqC
         7WHrh0u2ajfTxN1rnAP3d+CimWFQgd/Kz+snwn1M0BrYfY2918YMUR6qa8HIH0SuFiPA
         eD5E95rKnXr+u9VO5PZsvmEb+xusAvEwLu6JfPDFf4RvajmkCzr9pFIXk85iZyVOp5W/
         A2ja1KR3S+F7tS5XWG+VM2VMhPEAZwMihN81aLukWPaHhN+FXJ3o1bJ/lJW1O5G6nUqK
         VebkbPfz3/kSJ68O6vy3Us2w3n4p2SbD6HokU0HHu2o6/kMSOcA23Zow4Eadu79yTW6h
         Vviw==
X-Gm-Message-State: AOJu0Yznn8errjQDGTquyvgQPB9TYo5PJkprNrNHk7QwUz4hXpLTs6g6
	rZFUOEEln+shMzM/s0OtMbnzgFnUMkPlLNIbqPUiiGNT+d14fU/ftlTXqfymcQ==
X-Gm-Gg: ASbGncuuT7tRWgY7DL9mdyE6izfYFn6ol2N2shXx6Q4XXuo9iYvJVxxvvaqfZfwl1c5
	3pPJJMlSPKfWC4fNo/w1AItBhQXIGrCXgX2EucfelbzYv8BJMrunrvVhqbdy4DT4ObK8NQnEhgS
	u+C1nWIFXuSVw0vHLWRbWdJNLBx8VugGOoGFu8U1YCmK4rBL68kRSfxM/O7Fvs+QdKBWw6LXVq0
	zJKGgOafQBXS3AmZ+ULRpp/W+c2PB/myKLChhWKDjTSxgo0EynIzgTmFlAoc1g5WVCkA1Vd3car
	GrKk/uT7UbKfwFNi7bnJ/193I+FRA/leXZNRTjQrIXE8P8xWQAftR0LhWS5L6bKhU3uoMl9eReR
	bHpPme7sFIcKfSXX+xnEiYp9wZh2vKGiUDGqWQVr9p3wof4g=
X-Google-Smtp-Source: AGHT+IEzdbnj11R17qz2QklyYPqNgpN0+nOeDC9+0zzbNDnF4Sf6TfpFgS716le9FoIJxlKAy9RFIw==
X-Received: by 2002:a17:907:97d0:b0:ad2:595d:dd2d with SMTP id a640c23a62f3a-ad2595de071mr203214166b.44.1747046371830;
        Mon, 12 May 2025 03:39:31 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 12:39:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] Add lockdown mode
To: Kevin Lampis ,
 Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org
References: <20250506162510.1676425-1-kevin.lampis@cloud.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: <20250506162510.1676425-1-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:25, Kevin Lampis wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -216,6 +216,9 @@ static void __init _cmdline_parse(const char *cmdline)
>   */
>  void __init cmdline_parse(const char *cmdline)
>  {
> +    /* Call this early since it affects command-line parsing */
> +    lockdown_init(cmdline);

I can't spot the effect the comment mentions anywhere in this patch. Is the
description perhaps lacking some detail? It's rather odd after all to see ...

> --- /dev/null
> +++ b/xen/common/lockdown.c
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static bool __ro_after_init lockdown = IS_ENABLED(CONFIG_LOCKDOWN_DEFAULT);
> +ignore_param("lockdown");
> +
> +bool is_locked_down(void)
> +{
> +    return lockdown;
> +}
> +
> +void __init lockdown_init(const char *cmdline)
> +{
> +    if ( efi_secure_boot )
> +    {
> +        printk("Enabling lockdown mode because Secure Boot is enabled\n");
> +        lockdown = true;
> +    }
> +    else
> +    {
> +        while ( *cmdline )
> +        {
> +            size_t param_len, name_len;
> +            int ret;
> +
> +            cmdline += strspn(cmdline, " \n\r\t");
> +            param_len = strcspn(cmdline, " \n\r\t");
> +            name_len = strcspn(cmdline, "= \n\r\t");

... such custom token splitting ahead of normal command line handling.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:39:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:39:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981219.1367618 (Exim 4.92)
	(envelope-from )
	id 1uEQZc-0007ov-Ke; Mon, 12 May 2025 10:39:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981219.1367618; Mon, 12 May 2025 10: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 1uEQZc-0007om-Ft; Mon, 12 May 2025 10:39:52 +0000
Received: by outflank-mailman (input) for mailman id 981219;
 Mon, 12 May 2025 10:39:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEQZa-0007nL-VC
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:39:51 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6df410e2-2f1d-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 12:39:49 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad216a5a59cso454971566b.3
 for ; Mon, 12 May 2025 03:39:49 -0700 (PDT)
Received: from eddie5.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2192c83d9sm601141866b.28.2025.05.12.03.39.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 03:39: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" 
X-Inumbo-ID: 6df410e2-2f1d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747046389; x=1747651189; 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;
        bh=AZc5LtYl4BmVK65ksI2W32npsbKVS6L8xz5bNRK6Omk=;
        b=IWlb/5HzTTm4r74s1AozhIFAH1UW8h+PieIKI9+LT6m35C6k1gIuM2wHrM2DUqPS1+
         mhvJ87JGa/93ptj1e0dCIODUxYwhEJwBB4SO0/0UM3f2M/mF7rgndZK6SJzdrM73O5EI
         ezfnE1dy/+LuaInleXwSPGqpD9Ski0/ntI1Fg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747046389; x=1747651189;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=AZc5LtYl4BmVK65ksI2W32npsbKVS6L8xz5bNRK6Omk=;
        b=YfSFO5j3qK5zcgv45KM3TjyqM9ytNzgZAJ+wJ2FXQaTAeViekRxlunB5h4SNKk/cR6
         BQKAJ2Gj5IsFgiBu2dYLOJ12EKc9EY5kuotuBhSygF5ObAjpMmHjpVbPX6Pbo+DoS8kc
         W8ChUZBJXb4PqWH17ordhX0A/Ft60sCBbcwd5XDF+pABD4ubCxxjEwytbvEv1aXeW96l
         nn2esG3aRfasiyJZ2fsFec72tReiZ57aR5N1mzJzkWk0eFCTX4zD17ecaTnsak87sh0y
         9KKAR+G0KkvUxeYOdj3xomWKSF2jfrCpN1ZbDBDqrGewpYawIHQXdSG5ZY951oNyHyav
         sJGQ==
X-Gm-Message-State: AOJu0YwqKI6ob+21v65QBTD+q4XGP/wej0xxI8G8+wKHd091Cm63Krez
	T+rNGuBxw1d6gb6gjvDwrNQxwSJKV3TG98r7yhX5vtxVtN9v/ElCEEQkwg+TAt8E8ofeN9aWVlE
	d2rc=
X-Gm-Gg: ASbGncu4lWytiMWB97pkBrx3+rIilNHBDJoRN/siHIIQYCQkznyO2sJAUkPjMSkrFJn
	YHgQJLZmkEWkQtJg5MFkQfO1F3OyxBHRHaY24iYGSgegLjttgWkEeecSiTk3NP1fMtE+S5SFSm2
	p9dbsAVa/bxwxJeevhbKHcNEDkp4ZdlSFbN3U3tFNsAgE3sMkVdCuHLldE+E2SR0zoCVNgIoM3f
	/KVfHBMweixrzQ4VMDHwmPwx6yMqosLLZpZr/b2HeSzSQHmSRfGR0DHDRFvKLmsgfADEU8CHiUA
	BtknyljyvaDT8cyQO2GM9W/opmHyRmFtMAZ5oOKDnurgdF3GIH0u4tJXjQIYqt670Jpjt058ORQ
	=
X-Google-Smtp-Source: AGHT+IFAcKScBC4Mu4IhxE7Rdt/G3/sCgNspG9WxLbqThubtdn86RX25W42OY5W1GcTtjuZCBNiYsQ==
X-Received: by 2002:a17:907:2da1:b0:ad2:3f21:a0a1 with SMTP id a640c23a62f3a-ad23f21b350mr530556466b.37.1747046388608;
        Mon, 12 May 2025 03:39:48 -0700 (PDT)
From: Gerald Elder-Vass 
To: xen-devel@lists.xenproject.org
Cc: marmarek@invisiblethingslab.com,
	dpsmith@apertussolutions.com,
	Gerald Elder-Vass ,
	Frediano Ziglio ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [XEN PATCH v4] sbat: Add SBAT section to the Xen EFI binary
Date: Mon, 12 May 2025 10:39:42 +0000
Message-ID: <20250512103942.173136-1-gerald.elder-vass@cloud.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

SBAT is a revocation scheme for UEFI SecureBoot, and is mandated by Microsoft
for signing.

The SBAT section provides a way for the binary to declare a generation
id for its upstream source and any vendor changes applied. A compatible
loader can then revoke vulnerable binaries by generation, using the
binary's declared generation id(s) to determine if it is safe to load.

More information about SBAT is available here:
https://github.com/rhboot/shim/blob/main/SBAT.md

Vendors should append a custom line onto sbat.csv(.in) with their vendor
specific sbat data.

Populate the SBAT section in the Xen binary by using the information
in xen/arch/xs86/efi/sbat.sbat

Signed-off-by: Gerald Elder-Vass 
Signed-off-by: Frediano Ziglio 
Tested-by: Gerald Elder-Vass 
---
Changed since v3:
 * Rebased patch onto 'staging' branch
 * Included an empty .note.GNU-stack section to sbat.o to fix linker warning
 * Discard .sbat section from ELF (non-EFI) build

Changed since v2:
 * Moved sbat files and rules to arch/x86/efi
 * Updated sbat rule to reuse existing objcopy command

Changed since v1:
 * Updated commit message to explain why SBAT is needed
 * Renamed sbat_data.o rule to sbat.o
 * Moved sbat.o rule into alphabetical order
 * Removed xen specific entry from sbat.csv (and rule for auto filling version)
   - The alternative of adding a "customise me" line would result in more
     overhead for anyone else building Xen, regardless of UEFI SecureBoot usage

diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index c6678652fc98..530a76dc4f42 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -6,11 +6,19 @@ cmd_objcopy_o_ihex = $(OBJCOPY) -I ihex -O binary $< $@
 $(obj)/%.o: $(src)/%.ihex FORCE
 	$(call if_changed,objcopy_o_ihex)
 
+$(obj)/sbat.o: OBJCOPYFLAGS := -I binary -O elf64-x86-64 \
+	--rename-section .data=.sbat,readonly,data,contents \
+	--add-section .note.GNU-stack=/dev/null
+$(obj)/sbat.o: $(src)/sbat.sbat FORCE
+	$(call if_changed,objcopy)
+
 $(obj)/boot.init.o: $(obj)/buildid.o
 
 $(call cc-option-add,cflags-stack-boundary,CC,-mpreferred-stack-boundary=4)
 $(addprefix $(obj)/,$(EFIOBJ-y) mbi2.init.o): CFLAGS_stack_boundary := $(cflags-stack-boundary)
 
+EFIOBJ-y += sbat.o
+
 obj-y := common-stub.o stub.o
 obj-$(XEN_BUILD_EFI) := $(filter-out %.init.o,$(EFIOBJ-y))
 obj-bin-$(XEN_BUILD_EFI) := $(filter %.init.o,$(EFIOBJ-y))
diff --git a/xen/arch/x86/efi/sbat.sbat b/xen/arch/x86/efi/sbat.sbat
new file mode 100644
index 000000000000..1f262b5f038b
--- /dev/null
+++ b/xen/arch/x86/efi/sbat.sbat
@@ -0,0 +1 @@
+sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 53bafc98a536..a9240fa51a5e 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -343,6 +343,8 @@ SECTIONS
     *(.reloc)
     __base_relocs_end = .;
   }
+
+  .sbat (NOLOAD) : { *(.sbat) }
 #elif defined(XEN_BUILD_EFI)
   /*
    * Due to the way EFI support is currently implemented, these two symbols
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index 793d0e11450c..725ecae11893 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -99,7 +99,8 @@
        *(.comment.*) \
        *(.note.*)
 #else
-#define DISCARD_EFI_SECTIONS
+#define DISCARD_EFI_SECTIONS \
+       *(.sbat)
 #endif
 
 /* Sections to be discarded. */


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:41:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:41:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981235.1367627 (Exim 4.92)
	(envelope-from )
	id 1uEQal-0001Ho-S5; Mon, 12 May 2025 10:41:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981235.1367627; Mon, 12 May 2025 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 1uEQal-0001Hh-PD; Mon, 12 May 2025 10:41:03 +0000
Received: by outflank-mailman (input) for mailman id 981235;
 Mon, 12 May 2025 10:41:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEQaj-0000zV-Nd
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:41:01 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 981e1aee-2f1d-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 12:41:00 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad2414a412dso244188666b.0
 for ; Mon, 12 May 2025 03:41: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
 a640c23a62f3a-ad219348762sm609488866b.69.2025.05.12.03.40.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03:40: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" 
X-Inumbo-ID: 981e1aee-2f1d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747046460; x=1747651260; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=2zfYaxISaj+yDKSdksgMUbW9zDUBJHWIipBVoHndYs0=;
        b=NZrXDdnWkJQEP+Z7g7/XMfNkVPAxgOoskXoIXEspBmJD6TFCdX1VW4QH1iBOXVhODk
         ftrb3BCw/t32ndHMavkb1sI9sqSMcApcMIu4E0QjmRupcsLpMbxJGtcciaiv813DwdsV
         0APyAles8vWozodfrxuGEc5r47KwrTtjuxlP59rvTBiHQ9ru93B8stmzHCra8fYe3Nds
         ETodPWlIMmtwfTm2mjCWl9T8+yd1VqcAh3DVMp165JlKeD7g+p4Ep01H8+4ZBxmngThM
         yCiv+uHVtBuSq4kLaZLJu7XFDlyU6v/StvwtNqdgRRyh8I2y12bxYVtwZe4U6YrCbhkg
         1dhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747046460; x=1747651260;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=2zfYaxISaj+yDKSdksgMUbW9zDUBJHWIipBVoHndYs0=;
        b=ttaT7mBotoDgDvqmKEGTL4LVuFziUUvU4s/ggIu921qTf7LOQ/rNzDP9YAWIzOTjPw
         tpIfR7RUH9JkBCAPuiMKiTitAbL/ud9IvRxQNSjNVhr5WkVHDzNCebMVp9OlxGzkYv5u
         C6IolM+Wgx50X8O1bZrGp0IxrcUHQDTjwu0ex/YM2l4rELXQmK0dAWQMRSOexqEYe1Hq
         j+SGvA6oF8xbfgBwwqRmWgBXUHaTz15eM4Dnv/XrlhwS1snBg8z7PrV0Vw22MChCeMgE
         P0GNk+OzwqAcAly1w+ryOvr3pnk+Em4wO6/bVc59PkfrtPlV2dYmu3xmFx7sJoDG3Vru
         wGfA==
X-Gm-Message-State: AOJu0Ywb0jUs/qko+kuCCxo8eTK1DduqvMKVO0u7tme7UGiNgsdWC/F+
	+bo0vuoEACYbrSnM82KiJTYcqsc7kK7I64H9T3rQ+k8j9O2BvrzUJswz+i94BPkHjJFNHXKaEIg
	=
X-Gm-Gg: ASbGnctHLenSEiobd1UR70ktmisN5Mgi1s2L68Tdc38IuJ4wWbEPIUQuq2irxYDYwNZ
	/IL9blbfFUZVDA9mCZtq5iywM96dBUFo1mcE517lRy7FhwaI1BTaRsgL7Y+eKL+URPB6jLSUQ+U
	pPj+52IhZcEsIkA4yzkj2AD6UHEpSOJoPmMw9V4DbBbV0BLzm+HY35CAFJRqflHwWo8wkN0T8dX
	aW3OSnhbBQ2GOaneTieZ6bahgap17+SBaDEbydWaGarY3wq4GG56WteBLFPo6zod1DepCqpsx9c
	qXxp92IqVIAkjcto4SeQtFxwjj/LftGtDsTmvhJTtGQMzGfr8pSgLKfWkS8owZuScrsBnE3muVJ
	xjy0WGMuIdhqLM2QFdDS+pTU/4JJizcIiXT1a
X-Google-Smtp-Source: AGHT+IEscQrgnYLbyxIlixdwMoZb/6ttgq6DUpidVMZ48V3/y8jCqOvY2oHKfX1kqmjv40zTRbAdhw==
X-Received: by 2002:a17:907:e918:b0:ace:9d35:6987 with SMTP id a640c23a62f3a-ad218ea5b7dmr1138581066b.3.1747046459676;
        Mon, 12 May 2025 03:40:59 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 12:40:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] Disallow most command-line options when lockdown mode
 is enabled
To: Kevin Lampis 
References: <20250506162347.1676357-1-kevin.lampis@cloud.com>
 <20250512090210.1718623-1-kevin.lampis@cloud.com>
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250512090210.1718623-1-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.05.2025 11:02, Kevin Lampis wrote:
> A subset of command-line parameters that are specifically safe to use
> when lockdown mode is enabled are annotated as such.

You want to go into more detail here, specifically to describe the criteria
of "specifically safe". The command line doc may also want updating.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:50:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:50:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981245.1367637 (Exim 4.92)
	(envelope-from )
	id 1uEQjz-0003B1-N2; Mon, 12 May 2025 10:50:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981245.1367637; Mon, 12 May 2025 10:50:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEQjz-0003Ar-KQ; Mon, 12 May 2025 10:50:35 +0000
Received: by outflank-mailman (input) for mailman id 981245;
 Mon, 12 May 2025 10:50:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEQjz-0003Al-9r
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:50:35 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ecbbf5ae-2f1e-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 12:50:31 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5fcaff7274bso4859050a12.2
 for ; Mon, 12 May 2025 03:50: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
 4fb4d7f45d1cf-5fc9d73fdd0sm5563952a12.81.2025.05.12.03.50.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03:50:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ecbbf5ae-2f1e-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747047031; x=1747651831; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=WNOwQrQJ14uBBj+k/RnMLT9hO+/IJT7VGUvGaoFWIrI=;
        b=SNwyrAoE1hyoHdyOKML7O0n9LR7xibpuI07wYA8hp4d34VnWNRzlMr+4LDYUmbPrn2
         oiGofynu1mwna8FjdpmrELEdmfh+3gRngOcvsn8PswpcuFt+VQ0Ykr2oOODbbjCEb7qs
         QRNOshoRtcRlQlN/Uas1hy03sSIJvRwBat+BeQg9+qTgF3a+o7Cf/mQC3duqOgAlRk1/
         qrEO0jNt8DLhxQAiyg1SeGpHwBU2eSMhqbQljZoXrBo+x2UKkyCfFhwO2nvrDm1JCLaW
         E/qGuJBWugJTYEPSyS9RufQGukCfwVGX6YmeYGFM26gjxn+Jooi+7bOcP/d8sH0Xv1bd
         vcwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747047031; x=1747651831;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WNOwQrQJ14uBBj+k/RnMLT9hO+/IJT7VGUvGaoFWIrI=;
        b=bmg+Xwa2xxt5jGWHnRvuevrUD6P/q+H/bYn/0rSlG0CjuVMZraKiPioy1AtTZHDqeN
         4EmlRx4J7IOfoUrRVrrXw2Jqv9nQB9N1pEPhN3FVA6XRA+NW1lHqZ0Tb5emd8dxMtoJt
         Et/7noGFryhcer3IiMonbA2Yq3O05sTq3eFAOu592vPV9kEMKJ5NjD/+qW0agvgDj7QY
         dbW6IDLwIECeYHSDiXyB2c6X18hPvlrE3uResZHjURiSxC44Sti7vAskGD0baUwvwKci
         r7PUTDc6YRfbu0zyM3e0OE9H1zt+r8wW7MvVmWIxoVnJdjDfJmxQMWPrxc7mQ+Sg82gz
         Vm3w==
X-Forwarded-Encrypted: i=1; AJvYcCUy+Z0KplN5RC9DuFV+el5Uw1a0FlA3vnVKU+lD3d+rrVgJbAVXEodcQOggOMq/AQd4ARmaDpeOE9Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxy2+jCid8lpooUBnX69o8jK6gbAGo2BmTmJAflwIa3iuzd9ZUV
	wCrD0UaLWyxl7+tDzmgQgQR7af1SAQYw5UixtMXHffit40vzukY03CRiM8WCFw==
X-Gm-Gg: ASbGncsorX28hXYkXHYvKp5o+aY+8n0RT/Qq+aI+n3rgSX2Vfni9px16Zc25Q5vWYa4
	13xNMoq6GCrsb/TJFrrdyoQ3y4g/5UZdmDj2kS/CAA+o6Rgj8sW02K1jciEo0/ejEoHZyukY+Qn
	Dq10xRCvIm37o/coiXW94Xl4k1daKy9KJZeL6ntedi7CkgB1AoONmOS6IQMpbI7W4dLwKtVJsKl
	UR8To1ze1+1A31GRuxkYvEh3WlfvNXWAp6bbIB3UB96y+IKKQhqCK9WI/+D3LFZAcmJeWMvkjlE
	P5GRfMm11jPZ3eCCMwHf7UjSj3IW6Ni4TJPMvA/bm0pCTdNpEWr9dELgVkj8mqyWLpE5PEHKW94
	8IICSTUslXb5uXQ/UrxMN5Oujnxs73jNX1NjH
X-Google-Smtp-Source: AGHT+IECvw8pgmhSxPsfVyanFdXvc6giN0nPQdBy4KAjwqVAAhaf55cdVO4sXRn4aEK8eCrozmlOjg==
X-Received: by 2002:a05:6402:90d:b0:5fc:3f48:a673 with SMTP id 4fb4d7f45d1cf-5fca07314a4mr9693065a12.2.1747047031136;
        Mon, 12 May 2025 03:50:31 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 12:50:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3] sbat: Add SBAT section to the Xen EFI binary
To: Andrew Cooper ,
 Gerald Elder-Vass 
Cc: dpsmith@apertussolutions.com, marmarek@invisiblethingslab.com,
 Frediano Ziglio ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250507135442.3439237-1-gerald.elder-vass@cloud.com>
 <94652153-99fe-47d8-84d5-cbf2865ad6e0@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: <94652153-99fe-47d8-84d5-cbf2865ad6e0@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 08.05.2025 10:51, Andrew Cooper wrote:
> On 07/05/2025 2:54 pm, Gerald Elder-Vass wrote:
> Also,
> 
>> ld: warning: orphan section `.sbat' from `prelink.o' being placed in section `.sbat'
> 
> This is because sbat.o is getting linked into the non-EFI build of Xen too.
> 
> I'm less sure how to go about fixing this.  There's no nice way I can
> see of of getting sbat.o only in the EFI build.  The other option is to
> discard it for the ELF build.

We already link $(note_file) into just xen.efi; I'm pretty sure the same could
be done for this new object.

Jan



From xen-devel-bounces@lists.xenproject.org Mon May 12 10:54:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:54:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981253.1367647 (Exim 4.92)
	(envelope-from )
	id 1uEQnt-0003ou-7q; Mon, 12 May 2025 10:54:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981253.1367647; Mon, 12 May 2025 10: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 1uEQnt-0003on-47; Mon, 12 May 2025 10:54:37 +0000
Received: by outflank-mailman (input) for mailman id 981253;
 Mon, 12 May 2025 10:54:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEQns-0003oe-G9
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:54:36 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7e2c073a-2f1f-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 12:54:35 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5fbeadf2275so7444148a12.2
 for ; Mon, 12 May 2025 03:54:35 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 4fb4d7f45d1cf-5fc9cc526b2sm5875413a12.47.2025.05.12.03.54.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 03:54: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" 
X-Inumbo-ID: 7e2c073a-2f1f-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747047275; x=1747652075; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=BBN0CuMjU4DtF7OMUkUGG2u3SbW+xbKSkKjd0jqssQc=;
        b=fUGe4XxCQsxPtX/Uq8gMXRlmauPUwjfoStr21uL1eNHuqakybW728tNMqp4URX/gGR
         cixHnIxsD2XwvcjXGJF/Ib4KiJtEW3CCNtZct91T97X6vnqESpavxKoO0Q+RLSzO0Phy
         2BpYviQ8JfqSYxKzcIFtGQO74RmZCZknhWQ5k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747047275; x=1747652075;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BBN0CuMjU4DtF7OMUkUGG2u3SbW+xbKSkKjd0jqssQc=;
        b=qG7BXVDnaz2gL3c3dEWIrWBAmtcQpEFCBYWpIlefD9wyTbW7lK4v+jQ8xzuf440xrQ
         3ZpW5NWZa5/wQ59jTOop2HM9CJPmVjGRRpVL5Wrixa45ZBmTfzFiH+XEs4w2+LdFv+Lg
         puug4W5balTOUpT9NXKgbS152oTIJ8VZI8MrKeocclj1DiozaJwPsUeFba/2O+FcN9cw
         6XMTQ9AATMAg3/yj3A3p2evzFDTwEcMzD1gAZd/ZA9CsniH01ALj65fvpDvPg89XT25a
         i6D/HdJ8ILB62pES3XhK4Y9U/r6JRQ75nJANEYLObFTk0xZTJQf24uegTnE4ubpiHcrW
         XDCQ==
X-Forwarded-Encrypted: i=1; AJvYcCUM6at0YjhmnQ/HJqbm/XZmisrXqWF94dtqczWXsGZnUFDjrrx9F5Ij+sluu4M2TVvz+qZEbS8ShKo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwdNwzS3p92GqwtJjwCGvCHU6l67lE3q6zgOd7dZ2NOm4uwamTL
	upHApSCuEnzOzWYyQYHF2DhZ1Ay1SB2nq5aHJYk23TwXmXZ7WxqcPUg3lB76QlI=
X-Gm-Gg: ASbGncs7Z0kG+Ytbrgjs6PpDEuELhqYsXaoGA82+KQfwpryAEqbCLqtrupslBVGf7oA
	SedV2AM8gFB6jI+SKKe5OXYTe79zXMydZwYjTRpvjtDROziVlyiaOID8C3Yeqz3o7ppgw2q7Q0r
	YvZ4Pns9b//YuRLESi9Ql12F2EFFUENXrWKePW15TvbvMODlFDWd0Gjszc7NiAedG/GfkMl/oTX
	3wEf81c5t6F0Xd/SPfKq1c3AvTfRbUD7qMkN4WMOckkT65d7EFErT3IgX1m9Ndj0CkpcPQ/wkdA
	96tGwTJdnOsqgj163YHloQjRMSKTL4NWYBr9aRVHxiLKqRZoFhaVT3pFonyzFWD1VVk=
X-Google-Smtp-Source: AGHT+IHD2f77ywL3B21GRApmHpRsawiGU9swwnPdlDwO+YT5CRYiXzQkQCkfV2nqVNieOouXYb3bvQ==
X-Received: by 2002:a05:6402:51c9:b0:5fd:1972:7fac with SMTP id 4fb4d7f45d1cf-5fd197298d5mr5888634a12.3.1747047275038;
        Mon, 12 May 2025 03:54:35 -0700 (PDT)
Date: Mon, 12 May 2025 12:54:33 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Ross Lagerwall ,
	Kevin Lampis ,
	Anthony PERARD ,
	Juergen Gross ,
	Andrew Cooper ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] livepatch: Pass buffer size to list sysctl
Message-ID: 
References: <20250508170156.558291-1-ross.lagerwall@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Mon, May 12, 2025 at 11:51:35AM +0200, Jan Beulich wrote:
> On 08.05.2025 19:01, Ross Lagerwall wrote:
> > @@ -1328,10 +1327,15 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
> >              status.rc = data->rc;
> >  
> >              name_len = strlen(data->name) + 1;
> > -            list->name_total_size += name_len;
> > -
> >              metadata_len = data->metadata.len;
> > -            list->metadata_total_size += metadata_len;
> > +
> > +            if ( (name_total_copied + name_len) > list->name_total_size ||
> > +                 (metadata_total_copied + metadata_len) >
> > +                 list->metadata_total_size )
> > +            {
> > +                rc = -ENOMEM;
> 
> -ENOBUFS or maybe -ENOSPC, but certainly not -ENOMEM.

Jan, are you fine if I replace with -ENOBUFS on commit?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:58:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:58:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981261.1367657 (Exim 4.92)
	(envelope-from )
	id 1uEQrT-0004iQ-Ll; Mon, 12 May 2025 10:58:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981261.1367657; Mon, 12 May 2025 10: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 1uEQrT-0004iJ-IT; Mon, 12 May 2025 10:58:19 +0000
Received: by outflank-mailman (input) for mailman id 981261;
 Mon, 12 May 2025 10:58:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEQrS-0004iD-Kj
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:58:18 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 01d10449-2f20-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 12:58:16 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad24b7e0331so203978466b.0
 for ; Mon, 12 May 2025 03:58: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
 4fb4d7f45d1cf-5fc9d7016b4sm5606383a12.49.2025.05.12.03.58.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03:58: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" 
X-Inumbo-ID: 01d10449-2f20-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747047496; x=1747652296; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sU8IqMrzuksqrF54Hs2THJoM1tfZUvrHJnHHfcY8zM8=;
        b=BDImeEIhbsSdwL/5wSvDPEsStMMnQYw3UrJWi3mVtDEpMTHz3DZGvsSFhNBVmdribl
         nWw84d4N3MRjCVK5XHCcxEm8eYP8haImqcJ6HTuvtXjcwGS9OHTxUrmWVrANVLnwP2Ah
         xCqhqMRCyH+lWaCnLu6Aj/h/evcuiL/gfIsvQkjImtHgRdccQIGkPgad6Stq+0nN6x7p
         ERWF5TVGWNxj4m+t1oSNK3J28MH0oLle+UNpeamKKloKGZJHB/EaoG5ykIQ5F18gh6Lb
         WXsYT7oIudbePeN+Igof375iyqkMDjx+0GrTj6kpoNq+uuYW184WnoQ37CHuoBoOqK7h
         HuCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747047496; x=1747652296;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sU8IqMrzuksqrF54Hs2THJoM1tfZUvrHJnHHfcY8zM8=;
        b=YWu+XJ1XiO6TAyN7F08kLsDKJ8fn/xLA2AS2P5cvixgJ79Ry46vlEKw2/hM8PqF9Jq
         sOsecpyByuRKAnIUF1U2ukmP3tU5i14TrIeWQqWWOlAgnWxNOMnplCkRy9OtnERE9TJF
         oy8ORIAa+mdAx8MQ8pKpjUqLAuro59Qs/ntD1WwfICP0ErFNn9N5xoqJJfXQpxi7w35Q
         QO//Mho7xPTBeXxSHrKKHQyPDiAml8Yqm5g6sEmg43ghldinTqEj3MfZ/E4IXIuXdMMe
         z5zz4w8AsxyNFIRdDYPc6u4KN6R1tQt9ru5U63h8dLZVd9DvKuWGYnkL2O48iH04/8ep
         BN3A==
X-Forwarded-Encrypted: i=1; AJvYcCWAGhMWw9cUDkY/9n6Lf7SvHssl3o6GuhX1bfPn3+G5tF/xXjpta8bSC/4X5xHywxCnpfEkOgkeZCE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxwIe5CClLm54s9Ixk8WyDpZ2aqdmoZzDqNcBwMRcs+NDmKkkRB
	M8poQFdQ1eYEgoli3y95IockbxX8u0cqYXDTgznJ45Gb3R2/rqN+vUbpjIYA7Q==
X-Gm-Gg: ASbGncvNITtPIid1jTxo3IzwoveMBEVv3LwvT3EbP4pRwc3lyI4uKCo4CiLIoEtpPkp
	9sRo7T0kK7gxkBp+nLJ9RFw2R9jOZDy0FBrJeCk7nN2lSYiwaqHBOuS4LrMN1ow0ohyD3MMBn53
	m9+EvSdYY99g7abciFtjdzHc35RQBQsvUoabF3uAxvdjnlcuTMq2UyRf6GL+0gW0shH0JYE7IMT
	DubuMTpfLWX6aTeSWt9SVXrToKlW2oe109Emqx8AndWYeEvpVJrj9CkTw6SiXsDKsIdXgv2R7U5
	xYNsvyya69L3qQTlYUDXjq5v9J5lVD74oROGIasJeFqXLnZM/D91oLBR7E7kewAYqa9008ZtxqY
	iZH0Ymv/Wh9CUnMULKdKX6ccDogHpa8zcdMaC
X-Google-Smtp-Source: AGHT+IGw+L61ZHJpkaQr/+fzTChmU6aS5hpeTKheQEP2Tenw4Il53V2FslNlS8todAATczkzE4Es8Q==
X-Received: by 2002:a17:907:72d0:b0:ace:6d5b:e785 with SMTP id a640c23a62f3a-ad2192b6b17mr1133728266b.47.1747047495965;
        Mon, 12 May 2025 03:58:15 -0700 (PDT)
Message-ID: <18f73078-c512-416b-9406-c76f8db178eb@suse.com>
Date: Mon, 12 May 2025 12:58:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/Kconfig: Improve help test for speculative options
To: Andrew Cooper 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Xen-devel 
References: <20250508160336.2232152-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: <20250508160336.2232152-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 08.05.2025 18:03, Andrew Cooper wrote:
> The text for CONFIG_INDIRECT_THUNK isn't really correct, and was already stale
> by the time speculative vulnerabilities hit the headlines in 2018.  It is
> specifically an out-of-line-ing mechansim, and repoline is one of several
> safety sequences used.
> 
> Some of this boilerplate has been copied into all other options, and isn't
> interesting for the target audience given that they're all in a "Speculative
> Hardning" menu.
> 
> Reword it to be more concise.
> 
> 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 
> 
> CONFIG_SPECULATIVE_HARDEN_BRANCH really ought to be named
> CONFIG_SPECULATIVE_HARDEN_CONDITIONAL, but this would be a (minor) functional
> change.

Hmm, so you're suggesting all the straight-line speculation changes then ought
to be conditional upon a separate, new Kconfig control? So far I've keyed them
all to this one.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 10:58:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 10:58:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981265.1367666 (Exim 4.92)
	(envelope-from )
	id 1uEQrw-00059j-0p; Mon, 12 May 2025 10:58:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981265.1367666; Mon, 12 May 2025 10:58:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEQrv-00059c-UZ; Mon, 12 May 2025 10:58:47 +0000
Received: by outflank-mailman (input) for mailman id 981265;
 Mon, 12 May 2025 10:58:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEQru-00058c-3U
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 10:58:46 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1316e348-2f20-11f0-9eb5-5ba50f476ded;
 Mon, 12 May 2025 12:58:45 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5faaddb09feso8583489a12.2
 for ; Mon, 12 May 2025 03:58: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
 4fb4d7f45d1cf-5fc9d710549sm5523822a12.76.2025.05.12.03.58.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 03:58: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" 
X-Inumbo-ID: 1316e348-2f20-11f0-9eb5-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747047525; x=1747652325; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=PIr9ru3uBaMG5TqjteH4QmSYT4w5JsZLcfPm/fOk++Y=;
        b=Yzpe/ZvGpARolD/0PfcqrFU29EBiyWIXu01hQxsymC6RF9sf6AduMmTroLC68giIhW
         BsKmL1cRr+Xz1So5GyOXhnIJ5b9fwuBwtxJvJXOS4xCMdvFM/CrV9m1JNGRdqKrFPavi
         YnaATKhNne37Yz7QrSKGS+fej3aKPJpVvWZiMQXqkElDku71FNyT6PjQrVCVgs6HIY66
         JoY2PPtVhb/JtK0MJy17CE+DKjIEEDffg8/AHTfNTOu7RKEvy07iMH4Evkp0pIRDGhA3
         76WLVL2GDYHVNHIbvPuPsF2+a9X88QsYVUE01VG0MwmzniCZfKqLPaPDOgP1N4cK4cd/
         DaSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747047525; x=1747652325;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PIr9ru3uBaMG5TqjteH4QmSYT4w5JsZLcfPm/fOk++Y=;
        b=KZReElTsnsTfRhRy2sZcQLyepq+pph03l1iaiio+pesdf4Kw2vgPLuTjin6owaLcv6
         oO0JGFaCNx1GIgvoxL2sOLfLFMCTS8mtUPX162BsB6/+RCsh6ifmbuJvEeiWxkyKoXqP
         29+u/Z43fMNCHc46WyWCyvPkz7uEDn8cl5QlLsRtW9BQEUvABsdWQJHG+ypX0t8k32Wn
         shPALbZZqcIOpRcU4NRln7S2GuTpRdSoYuWyB8ogJfrgzuQ3doPxjC9uG1B7gehAvHj0
         nzIl0lRIjORomg/26YJNclt5i9cH5Fdak7vFxZG5L8aW78EGMNAEULI9omNqf8kjZOTt
         F5Bw==
X-Forwarded-Encrypted: i=1; AJvYcCXAIDPA6ixNAefxUQfNknNA2C5IPTVvPlCyD04Slb4xy1y6d3rOzvcpAuWocvLa34fsEXADlt9Uxb0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxvKEsKhOuThEp0muFA5l2j6kobeP0YD6l/t8dB9S9RlQXKHNjz
	pmU2CGzag1pQaVGjjaUknges17gNqGoZDsdJvMYfRaBgVunAKvpTjoEDKMg9a8h1ZMjGgZpGR6E
	=
X-Gm-Gg: ASbGncv1rF95GaNuj6FHm8wvC9Ac+ioRMyFNAMSS8szQjWZBNxyP4VicCh6YYSLHH/S
	aziuQJzFQMpkL/2Xphk1InhyEmzzx4N4JloqSysDvFf8xDNmXYhCFf0C23GAQEw07nwPm8cWUEf
	Qqx5VyZMADmfO63JVFP7bt2rXQm7qtKKkxJ/KQr+MG0KNdUct03UtRvbzMV/ealtNnLnAjIxl8Z
	6d1/flwz2NJrdq3tcd6Re+UDNodXF3WA9HpAoZqbuEmiaWYugCY6QrnwxjB9maNIKjyzSL9DpSC
	6XaFwqn93lmZLugdPgbrph3GEttYfE6jdhINFJIK/YpSxd0LWWnTjCTWiwrfW++DzWuhrGhMt25
	47Mc3erC1kerzxLDZqCPUAU4/f9SBuhGGnd5q
X-Google-Smtp-Source: AGHT+IEkAcNh92M4Dvid3pqmtdIwiS4lraMB5PUWsD9Cmz2OBessHJEOrniS35MJOtJjOmIGvWy3rA==
X-Received: by 2002:a05:6402:3507:b0:5f6:c638:c72d with SMTP id 4fb4d7f45d1cf-5fca0730831mr11703568a12.7.1747047524989;
        Mon, 12 May 2025 03:58:44 -0700 (PDT)
Message-ID: <4b492493-5390-4759-98f9-859fe43bb7e0@suse.com>
Date: Mon, 12 May 2025 12:58:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] livepatch: Pass buffer size to list sysctl
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Ross Lagerwall ,
 Kevin Lampis ,
 Anthony PERARD , Juergen Gross ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250508170156.558291-1-ross.lagerwall@citrix.com>
 
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12.05.2025 12:54, Roger Pau Monné wrote:
> On Mon, May 12, 2025 at 11:51:35AM +0200, Jan Beulich wrote:
>> On 08.05.2025 19:01, Ross Lagerwall wrote:
>>> @@ -1328,10 +1327,15 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
>>>              status.rc = data->rc;
>>>  
>>>              name_len = strlen(data->name) + 1;
>>> -            list->name_total_size += name_len;
>>> -
>>>              metadata_len = data->metadata.len;
>>> -            list->metadata_total_size += metadata_len;
>>> +
>>> +            if ( (name_total_copied + name_len) > list->name_total_size ||
>>> +                 (metadata_total_copied + metadata_len) >
>>> +                 list->metadata_total_size )
>>> +            {
>>> +                rc = -ENOMEM;
>>
>> -ENOBUFS or maybe -ENOSPC, but certainly not -ENOMEM.
> 
> Jan, are you fine if I replace with -ENOBUFS on commit?

Yes.

Jan



From xen-devel-bounces@lists.xenproject.org Mon May 12 11:20:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 11:20:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981281.1367677 (Exim 4.92)
	(envelope-from )
	id 1uERDD-0001Hw-ON; Mon, 12 May 2025 11:20:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981281.1367677; Mon, 12 May 2025 11: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 1uERDD-0001Hp-LK; Mon, 12 May 2025 11:20:47 +0000
Received: by outflank-mailman (input) for mailman id 981281;
 Mon, 12 May 2025 11:20:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uERDC-0001Hj-0o
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 11:20:46 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 24b6df67-2f23-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 13:20:43 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a1fb17a9beso1600917f8f.3
 for ; Mon, 12 May 2025 04:20:43 -0700 (PDT)
Received: from ?IPV6:2003:e5:8712:700:7979:a587:7535:c0a5?
 (p200300e5871207007979a5877535c0a5.dip0.t-ipconnect.de.
 [2003:e5:8712:700:7979:a587:7535:c0a5])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f5a4d21esm12322274f8f.99.2025.05.12.04.20.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 04:20: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" 
X-Inumbo-ID: 24b6df67-2f23-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747048843; x=1747653643; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=kr7HiQDWhppypLc5R1TknrWXdxASKd1D4Avu6evpKDM=;
        b=IVltvkV8EgFtopciz9pgzYlGv+cHRGZS0CYlQBbpd0tLsefI1z7Kni/3ggPFMWKEdA
         a/YWPsGFygRBgfqRxm6QL6wp8xphooST1uKmucVhBlOntN+gI8zTmwmrNEmoO609Q3SW
         P74yLO7Ep2SYFycZVTJDga4Asctwev+XHyu9zKCQoUYkJk39GNgdDEFV2VCj2HwkeFnn
         Qk3hiDXIT1fBpzo4gsIzTdSzC2NQp3uE8GlTyc9C9SkiOGfnehQ6X4YlC0VEgQud/6K8
         KribcI1pyqPD7W+mYCnZ4af5mQhvyvs3Ay3xwJL57bp+hR/suvfA/nw12qTT4+2E0Lbe
         EXCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747048843; x=1747653643;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=kr7HiQDWhppypLc5R1TknrWXdxASKd1D4Avu6evpKDM=;
        b=MzgQWB1mvZ82JfJLy+QY0uAOb0agKNIL8+QdL7Rr9m/wn8OtMU7ACLXbCTX9vr/bpD
         OBP0Q+INmM5XpX3IQPFc2C88OWSZuoPE4rg2nAwhgIpMGpSrmC11Jg7nfBIa6KI6G13L
         A5nB9iPRJGd18LAEgi73OfIXuaPBoV0ghtbPDi+tCLt2eauP0uupX5aCH8XXWYiixmij
         URQu53wdSz8nph2RT5ZO6LHZfPkqZZA2dTMS01ityT7qHkFFxFfe+RSJujQjwK9+r8nD
         0Kre8/v3liGEs3TCa/fB/Yg0+REPS6OCLvfl9HvZPm1xsT+itbhNHnhG/5YjxM3U1Kcw
         R/4g==
X-Forwarded-Encrypted: i=1; AJvYcCXjKeFkf76tPtolgj69ITpyMjahCsJhOknurwXXIY0FQa+/XllHgN76h4xBsmYK7lUdLbKCieHcY/U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzR5uxtUYusHfQBAzh46WDedL+DM87IVqDUhD8sjEKpGRnrf3zF
	eFUEfzbk+dyRt7BA/PNzcjJcKit9bLFkDOzmH5xNSLkSDdHX2b7cPIPIaSTMTN0=
X-Gm-Gg: ASbGnctwj1S3zxOxj6zAQT8lU2kMxIjzBkGh8TWeioHTRa+yH5Aaa88w9XOJpCJYh/v
	JD+mxyEfMYk2bp9GBmC479CARO247Lji6uE7Tz1rMLD5DG9d6HM+NpQxEQiXvqZ7hAkCIQIOSmw
	SyW2js2eJ+R4BbyZrW/EKCh5ruc2cJCL6TCBPTMYY9P7d7OqOanOghZw08P5o0UN97tzvSrikdO
	aosuQeuvJGcHU4QJ/wOZIKXBIXUt4MNDOeSJFaAFnSx0L5NwlN9rbyciKJh1tJGxnJf4d497IaX
	iC0UTZm6HVvZpfOWWflZqbh9Bw7vrZu3rqe0IuvqZeYWN2nYxr7pPNlWbsoHEKei/B4SITZHrIA
	Xl6TnwnnNlOO0BaTlFwRoUSWMGX46VqdwACArzQP7AQSdU2odT5EHrsFtQsidg/NaxFavv12imw
	==
X-Google-Smtp-Source: AGHT+IEMGkvWdh30v6AzbRDKtJ5QyDYqj0+h1d6dUZuhQa+J63MVJ5ByPlRc3BdcWVwZi5D6EkqFSg==
X-Received: by 2002:a05:6000:3113:b0:39e:e3fa:a66b with SMTP id ffacd0b85a97d-3a1f6445d7dmr10714250f8f.34.1747048842869;
        Mon, 12 May 2025 04:20:42 -0700 (PDT)
Message-ID: <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
Date: Mon, 12 May 2025 13:20:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
To: Xin Li , linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev
Cc: Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 , Thomas Gleixner
 , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky , xen-devel@lists.xenproject.org
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.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: <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------xUHWlNj9eo72qDdlI6FcdrVq"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------xUHWlNj9eo72qDdlI6FcdrVq
Content-Type: multipart/mixed; boundary="------------a0ybUBCT40lur4qpzFe426ln";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Xin Li , linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev
Cc: Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 , Thomas Gleixner
 , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky , xen-devel@lists.xenproject.org
Message-ID: <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
In-Reply-To: <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>

--------------a0ybUBCT40lur4qpzFe426ln
Content-Type: multipart/mixed; boundary="------------duqhFBg0pMv7DTJhelp99NN2"

--------------duqhFBg0pMv7DTJhelp99NN2
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDkuMDUuMjUgMTA6MTgsIFhpbiBMaSB3cm90ZToNCj4gT24gNS82LzIwMjUgMjoyMCBB
TSwgSnVlcmdlbiBHcm9zcyB3cm90ZToNCj4+IEluc3RlYWQgb2YgaGF2aW5nIGNhbGxiYWNr
IGZ1bmN0aW9ucyBmb3IgcmRtc3Ivd3Jtc3Igb24gbmF0aXZlLCBzd2l0Y2gNCj4+IHRvIGlu
bGluZSB0aGUgcmVzcGVjdGl2ZSBpbnN0cnVjdGlvbnMgZGlyZWN0bHkgaW4gb3JkZXIgdG8g
YXZvaWQNCj4+IG92ZXJoZWFkIHdpdGggdGhlIGNhbGwgaW50ZXJmYWNlLg0KPiANCj4gVG8g
bWUsIHRoaXMgaXMgYSBiZW5lZmljaWFsIGFkZGl0aW9uIHRvIHRoZSBleGlzdGluZyBwdm9w
cyBNU1IgY29kZS4NCj4gDQo+Pg0KPj4gVGhpcyByZXF1aXJlcyB0byB1c2UgdGhlIGluc3Ry
dWN0aW9uIGludGVyZmFjZXMgZm9yIHJkbXNyL3dybXNyDQo+PiBlbXVsYXRpb24gd2hlbiBy
dW5uaW5nIGFzIGEgWGVuIFBWIGd1ZXN0Lg0KPj4NCj4+IEluIG9yZGVyIHRvIHByZXBhcmUg
c3VwcG9ydCBmb3IgdGhlIGltbWVkaWF0ZSBmb3JtcyBvZiBSRE1TUiBhbmQgV1JNU1INCj4+
IHdoZW4gbm90IHJ1bm5pbmcgYXMgYSBYZW4gUFYgZ3Vlc3QsIHVzZSB0aGUgUkRNU1IgYW5k
IFdSTVNSDQo+PiBpbnN0cnVjdGlvbnMgYXMgdGhlIGZhbGxiYWNrIGNhc2UgaW5zdGVhZCBv
ZiBBTFRfQ0FMTF9JTlNUUi4NCj4gDQo+IEknbSB0cnlpbmcgdG8gZXZhbHVhdGUgaG93IHRv
IGFkZCB0aGUgaW1tZWRpYXRlIGZvcm0gTVNSIGluc3RydWN0aW9ucw0KPiBvbiB0b3Agb2Yg
dGhpcyBwYXRjaCBzZXQuwqAgQW5kIEknbSBjbG9zZSB0byBnZXQgaXQgZG9uZS4NCg0KVGhl
cmUgaXMgc29tZXRoaW5nIHRvIGNvbnNpZGVyIHdoZW4gcnVubmluZyBhcyBhIFhlbiBQViBn
dWVzdCwgLi4uDQoNCj4gDQo+Pg0KPj4gTm90ZSB0aGF0IGluIHRoZSBYZW4gUFYgY2FzZSB0
aGUgUkRNU1IvV1JNU1IgcGF0Y2hpbmcgbXVzdCBub3QgaGFwcGVuDQo+PiBldmVuIGFzIGFu
IGludGVybWVkaWF0ZSBzdGVwLCBhcyB0aGlzIHdvdWxkIGNsb2JiZXIgdGhlIGluZGlyZWN0
IGNhbGwNCj4+IGluZm9ybWF0aW9uIG5lZWRlZCB3aGVuIHBhdGNoaW5nIGluIHRoZSBkaXJl
Y3QgY2FsbCBmb3IgdGhlIFhlbiBjYXNlLg0KPiANCj4gR29vZCBwb2ludCENCg0KLi4uIGFz
IHRoaXMgc3RpbGwgbmVlZHMgdG8gYmUgdHJ1ZS4NCg0KVGhlcmUgYXJlIDIgZGlmZmVyZW50
IHdheXMgdG8gZGVhbCB3aXRoIHRoaXM6DQoNCjEuIFdoZW4gcnVubmluZyBhcyBhIFhlbiBQ
ViBndWVzdCBkaXNhYmxlIFg4Nl9GRUFUVVJFX1dSTVNSTlMgYW5kDQogICAgQVNNX1dSTVNS
TlNfSU1NIChlLmcuIGluIHhlbl9pbml0X2NhcGFiaWxpdGllcygpKS4NCg0KMi4gQnVmZmVy
IHRoZSBvcmlnaW5hbCBpbnN0cnVjdGlvbiBiZWZvcmUgcGF0Y2hpbmcgaW4gYXBwbHlfYWx0
ZXJuYXRpdmVzKCkNCiAgICBpbiBvcmRlciB0byBhdm9pZCB0aGUgc2VxdWVuY2UgbGltaXRh
dGlvbiBhYm92ZSAoc2VlIGF0dGFjaGVkIHBhdGNoKS4NCg0KPiBEZWNpZGluZyB3aGV0aGVy
IHRvIHJldGFpbiB0aGUgcHZvcHMgTVNSIEFQSSBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YN
Cj4gdGhlIHg4NiBtYWludGFpbmVycywgd2hvIGFyZSB0aGUgb25lcyBleHBlcmllbmNpbmcg
dGhlIGNoYWxsZW5nZXMgb2YgbWFpbnRhaW5pbmcgDQo+IHRoZSBjb2RlLg0KDQpXZWxsLCBJ
J20gdGhlIFBWIG9wcyBtYWludGFpbmVyLCBzbyBpdCBpcyBiYXNpY2FsbHkgbWUgd2hvIG5l
ZWRzIHRvIGRlYWwNCndpdGggdGhpcy4gT1RPSCBJIGRvIHVuZGVyc3RhbmQgdGhhdCBkaWFn
bm9zaXMgb2YgcHJvYmxlbXMgd2l0aCBQViBvcHMgaXMNCm1vcmUgY29tcGxpY2F0ZWQgdGhh
biB3aXRob3V0Lg0KDQo+IA0KPiB0Z2x4IHNhaWQgQGh0dHBzOi8vbG9yZS5rZXJuZWwub3Jn
L2xrbWwvODd5MWg4MWh0NC5mZnNAdGdseC86DQo+IA0KPiAgPiBJIGZ1bmRhbWVudGFseSBo
YXRlIGFkZGluZyB0aGlzIHRvIHRoZSBQViBpbmZyYXN0cnVjdHVyZS4gV2UgZG9uJ3QNCj4g
ID4gd2FudCBtb3JlIFBWIG9wcywgcXVpdGUgdGhlIGNvbnRyYXJ5Lg0KPiANCj4gVGhhdCBp
cyB0aGUgcmVhc29uIEkgdG9vayBhIGRpZmZlcmVudCBkaXJlY3Rpb24sIGkuZS4sIHJlbW92
aW5nIHRoZQ0KPiBwdm9wcyBNU1IgQVBJcy7CoCBCdXQgaWYgeW91ciBhcHByb2FjaCBpcyBj
bGVhbmVyLCB0aGV5IG1heSBwcmVmZXIgaXQuDQoNCkluIHRoZSBlbmQgaXQgaXNuJ3QgYWRk
aW5nIGFkZGl0aW9uYWwgUFYgb3BzIGludGVyZmFjZXMuIEl0IGlzIG1vZGlmeWluZw0KZXhp
c3Rpbmcgb25lcy4NCg0KPiANCj4+IGRpZmYgLS1naXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9wYXJhdmlydC5oIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnQuaA0KPj4gaW5k
ZXggYTQ2M2M3NDdjNzgwLi5kZjEwYjBlNGY3YjggMTAwNjQ0DQo+PiAtLS0gYS9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9wYXJhdmlydC5oDQo+PiArKysgYi9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9wYXJhdmlydC5oDQo+PiBAQCAtMTc1LDI0ICsxNzUsNzIgQEAgc3RhdGljIGlubGluZSB2
b2lkIF9fd3JpdGVfY3I0KHVuc2lnbmVkIGxvbmcgeCkNCj4+IMKgwqDCoMKgwqAgUFZPUF9W
Q0FMTDEoY3B1LndyaXRlX2NyNCwgeCk7DQo+PiDCoCB9DQo+PiAtc3RhdGljIGlubGluZSB1
NjQgcGFyYXZpcnRfcmVhZF9tc3IodTMyIG1zcikNCj4+ICtzdGF0aWMgX19hbHdheXNfaW5s
aW5lIHU2NCBwYXJhdmlydF9yZWFkX21zcih1MzIgbXNyKQ0KPj4gwqAgew0KPj4gLcKgwqDC
oCByZXR1cm4gUFZPUF9DQUxMMSh1NjQsIGNwdS5yZWFkX21zciwgbXNyKTsNCj4+ICvCoMKg
wqAgRUFYX0VEWF9ERUNMQVJFX0FSR1ModmFsLCBsb3csIGhpZ2gpOw0KPiANCj4gVGhpcyBp
cyB1bmRlciBDT05GSUdfUEFSQVZJUlRfWFhMLCB0aHVzIENPTkZJR19YRU5fUFYgYW5kIENP
TkZJR19YODZfNjQsDQo+IHRoZXJlZm9yZSB3ZSBkb24ndCBuZWVkIHRvIGNvbnNpZGVyIDMy
LWJpdCBhdCBhbGwsIG5vPw0KDQpSaWdodC4gT1RPSCB0aGUgbWFjcm9zIGFyZSB0aGVyZSwg
c28gd2h5IG5vdCB1c2UgdGhlbT8NCg0KSW4gdGhlIGVuZCBJJ20gZmluZSB0byBvcGVuIGNv
ZGUgdGhlIDY0LWJpdCBjYXNlIGhlcmUuDQoNCj4gDQo+PiArDQo+PiArwqDCoMKgIFBWT1Bf
VEVTVF9OVUxMKGNwdS5yZWFkX21zcik7DQo+PiArwqDCoMKgIGFzbSB2b2xhdGlsZSgiMTog
IkFMVEVSTkFUSVZFXzIoUEFSQVZJUlRfQ0FMTCwNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCAicmRtc3IiLCBBTFRfTk9UX1hFTiwNCj4+ICvCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBBTFRfQ0FMTF9JTlNUUiwgQUxUX1hF
TlBWX0NBTEwpDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICIyOlxuIg0KPj4gK8Kg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBfQVNNX0VYVEFCTEVfVFlQRSgxYiwgMmIsIEVYX1RZ
UEVfUkRNU1IpDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogRUFYX0VEWF9SRVQo
dmFsLCBsb3csIGhpZ2gpLCBBU01fQ0FMTF9DT05TVFJBSU5UDQo+PiArwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIDogcGFyYXZpcnRfcHRyKGNwdS5yZWFkX21zciksICJjIiAobXNyKSk7
DQo+PiArDQo+PiArwqDCoMKgIHJldHVybiBFQVhfRURYX1ZBTCh2YWwsIGxvdywgaGlnaCk7
DQo+PiDCoCB9DQo+PiAtc3RhdGljIGlubGluZSB2b2lkIHBhcmF2aXJ0X3dyaXRlX21zcih1
MzIgbXNyLCB1NjQgdmFsKQ0KPj4gK3N0YXRpYyBfX2Fsd2F5c19pbmxpbmUgdm9pZCBwYXJh
dmlydF93cml0ZV9tc3IodTMyIG1zciwgdTY0IHZhbCkNCj4+IMKgIHsNCj4+IC3CoMKgwqAg
UFZPUF9WQ0FMTDIoY3B1LndyaXRlX21zciwgbXNyLCB2YWwpOw0KPj4gK8KgwqDCoCBQVk9Q
X1RFU1RfTlVMTChjcHUud3JpdGVfbXNyKTsNCj4+ICvCoMKgwqAgYXNtIHZvbGF0aWxlKCIx
OiAiQUxURVJOQVRJVkVfMihQQVJBVklSVF9DQUxMLA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgICJ3cm1zciIsIEFMVF9OT1RfWEVOLA0KPj4gK8KgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEFMVF9DQUxMX0lOU1RSLCBBTFRf
WEVOUFZfQ0FMTCkNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAiMjpcbiINCj4+
ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBfQVNNX0VYVEFCTEVfVFlQRSgxYiwgMmIs
IEVYX1RZUEVfV1JNU1IpDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgOiBBU01f
Q0FMTF9DT05TVFJBSU5UDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgOiBwYXJh
dmlydF9wdHIoY3B1LndyaXRlX21zciksDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgImMiIChtc3IpLCAiYSIgKCh1MzIpdmFsKSwgImQiICgodTMyKSh2YWwgPj4gMzIpKQ0K
Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogIm1lbW9yeSIpOw0KPj4gwqAgfQ0K
Pj4gLXN0YXRpYyBpbmxpbmUgaW50IHBhcmF2aXJ0X3JlYWRfbXNyX3NhZmUodTMyIG1zciwg
dTY0ICp2YWwpDQo+PiArc3RhdGljIF9fYWx3YXlzX2lubGluZSBpbnQgcGFyYXZpcnRfcmVh
ZF9tc3Jfc2FmZSh1MzIgbXNyLCB1NjQgKnApDQo+PiDCoCB7DQo+PiAtwqDCoMKgIHJldHVy
biBQVk9QX0NBTEwyKGludCwgY3B1LnJlYWRfbXNyX3NhZmUsIG1zciwgdmFsKTsNCj4+ICvC
oMKgwqAgaW50IGVycjsNCj4+ICvCoMKgwqAgRUFYX0VEWF9ERUNMQVJFX0FSR1ModmFsLCBs
b3csIGhpZ2gpOw0KPj4gKw0KPj4gK8KgwqDCoCBQVk9QX1RFU1RfTlVMTChjcHUucmVhZF9t
c3Jfc2FmZSk7DQo+PiArwqDCoMKgIGFzbSB2b2xhdGlsZSgiMTogIkFMVEVSTkFUSVZFXzIo
UEFSQVZJUlRfQ0FMTCwNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCAicmRtc3I7IHhvciAlW2Vycl0sJVtlcnJdIiwgQUxUX05PVF9YRU4sDQo+PiArwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQUxUX0NBTExfSU5TVFIsIEFM
VF9YRU5QVl9DQUxMKQ0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAiMjpcbiINCj4+
ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgX0FTTV9FWFRBQkxFX1RZUEVfUkVHKDFiLCAy
YiwgRVhfVFlQRV9SRE1TUl9TQUZFLCAlW2Vycl0pDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIDogW2Vycl0gIj1jIiAoZXJyKSwgRUFYX0VEWF9SRVQodmFsLCBsb3csIGhpZ2gp
LA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQVNNX0NBTExfQ09OU1RSQUlO
VA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IHBhcmF2aXJ0X3B0cihjcHUucmVh
ZF9tc3Jfc2FmZSksICIwIiAobXNyKSk7DQo+PiArDQo+PiArwqDCoMKgICpwID0gRUFYX0VE
WF9WQUwodmFsLCBsb3csIGhpZ2gpOw0KPj4gKw0KPj4gK8KgwqDCoCByZXR1cm4gZXJyOw0K
Pj4gwqAgfQ0KPj4gLXN0YXRpYyBpbmxpbmUgaW50IHBhcmF2aXJ0X3dyaXRlX21zcl9zYWZl
KHUzMiBtc3IsIHU2NCB2YWwpDQo+PiArc3RhdGljIF9fYWx3YXlzX2lubGluZSBpbnQgcGFy
YXZpcnRfd3JpdGVfbXNyX3NhZmUodTMyIG1zciwgdTY0IHZhbCkNCj4+IMKgIHsNCj4+IC3C
oMKgwqAgcmV0dXJuIFBWT1BfQ0FMTDIoaW50LCBjcHUud3JpdGVfbXNyX3NhZmUsIG1zciwg
dmFsKTsNCj4+ICvCoMKgwqAgaW50IGVycjsNCj4+ICsNCj4+ICvCoMKgwqAgUFZPUF9URVNU
X05VTEwoY3B1LndyaXRlX21zcl9zYWZlKTsNCj4+ICvCoMKgwqAgYXNtIHZvbGF0aWxlKCIx
OiAiQUxURVJOQVRJVkVfMihQQVJBVklSVF9DQUxMLA0KPj4gK8KgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgICJ3cm1zcjsgeG9yICVbZXJyXSwlW2Vycl0iLCBBTFRf
Tk9UX1hFTiwNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBB
TFRfQ0FMTF9JTlNUUiwgQUxUX1hFTlBWX0NBTEwpDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgICIyOlxuIg0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBfQVNNX0VYVEFC
TEVfVFlQRV9SRUcoMWIsIDJiLCBFWF9UWVBFX1dSTVNSX1NBRkUsICVbZXJyXSkNCj4+ICvC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgOiBbZXJyXSAiPWEiIChlcnIpLCBBU01fQ0FMTF9D
T05TVFJBSU5UDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogcGFyYXZpcnRfcHRy
KGNwdS53cml0ZV9tc3Jfc2FmZSksDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCAiYyIgKG1zciksICIwIiAoKHUzMil2YWwpLCAiZCIgKCh1MzIpKHZhbCA+PiAzMikpDQo+
PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogIm1lbW9yeSIpOw0KPj4gKw0KPj4gK8Kg
wqDCoCByZXR1cm4gZXJyOw0KPj4gwqAgfQ0KPj4gwqAgc3RhdGljIF9fYWx3YXlzX2lubGlu
ZSB1NjQgcmVhZF9tc3IodTMyIG1zcikNCj4+IEBAIC01NzMsMjcgKzYyMSw0MyBAQCBib29s
IF9fcmF3X2NhbGxlZV9zYXZlX19fbmF0aXZlX3ZjcHVfaXNfcHJlZW1wdGVkKGxvbmcgDQo+
PiBjcHUpOw0KPj4gwqAgI2RlZmluZSBQVl9TQVZFX0FMTF9DQUxMRVJfUkVHU8KgwqDCoMKg
wqDCoMKgICJwdXNobCAlZWN4OyINCj4+IMKgICNkZWZpbmUgUFZfUkVTVE9SRV9BTExfQ0FM
TEVSX1JFR1PCoMKgwqAgInBvcGzCoCAlZWN4OyINCj4+IMKgICNlbHNlDQo+PiArLyogc2F2
ZSBhbmQgcmVzdG9yZSBjYWxsZXItc2F2ZSByZWdpc3RlcnMsIGV4Y2VwdCAlcmF4LCAlcmN4
IGFuZCAlcmR4LiAqLw0KPj4gKyNkZWZpbmUgUFZfU0FWRV9DT01NT05fQ0FMTEVSX1JFR1PC
oMKgwqAgXA0KPj4gK8KgwqDCoCAicHVzaCAlcnNpOyLCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IFwNCj4+ICvCoMKgwqAgInB1c2ggJXJkaTsiwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+
PiArwqDCoMKgICJwdXNoICVyODsiwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+PiArwqDC
oMKgICJwdXNoICVyOTsiwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+PiArwqDCoMKgICJw
dXNoICVyMTA7IsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4gK8KgwqDCoCAicHVzaCAl
cjExOyINCj4gDQo+IEFkZCBhbiBlbXB0eSBsaW5lIHBsZWFzZSwgZWFzaWVyIHRvIHJlYWQu
DQoNCk9rYXkgKHNhbWUgYmVsb3cpLg0KDQo+IA0KPj4gKyNkZWZpbmUgUFZfUkVTVE9SRV9D
T01NT05fQ0FMTEVSX1JFR1PCoMKgwqAgXA0KPj4gK8KgwqDCoCAicG9wICVyMTE7IsKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4gK8KgwqDCoCAicG9wICVyMTA7IsKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgXA0KPj4gK8KgwqDCoCAicG9wICVyOTsiwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCBcDQo+PiArwqDCoMKgICJwb3AgJXI4OyLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwN
Cj4+ICvCoMKgwqAgInBvcCAlcmRpOyLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+ICvC
oMKgwqAgInBvcCAlcnNpOyINCj4+ICsNCj4+ICsjZGVmaW5lIFBWX1BST0xPR1VFX01TUihm
dW5jKcKgwqDCoMKgwqDCoMKgIFwNCj4+ICvCoMKgwqAgUFZfU0FWRV9DT01NT05fQ0FMTEVS
X1JFR1PCoMKgwqAgXA0KPj4gK8KgwqDCoCBQVl9QUk9MT0dVRV9NU1JfIyNmdW5jDQo+IA0K
PiBEaXR0by7CoCBBbmQgdGhlIGZvbGxvd2luZyBzaW1pbGFyIGNhc2VzLg0KPiANCj4+ICsj
ZGVmaW5lIFBWX0VQSUxPR1VFX01TUihmdW5jKcKgwqDCoMKgwqDCoMKgIFwNCj4+ICvCoMKg
wqAgUFZfRVBJTE9HVUVfTVNSXyMjZnVuY8KgwqDCoMKgwqDCoMKgIFwNCj4+ICvCoMKgwqAg
UFZfUkVTVE9SRV9DT01NT05fQ0FMTEVSX1JFR1MNCj4+ICsNCj4+IMKgIC8qIHNhdmUgYW5k
IHJlc3RvcmUgYWxsIGNhbGxlci1zYXZlIHJlZ2lzdGVycywgZXhjZXB0IHJldHVybiB2YWx1
ZSAqLw0KPj4gwqAgI2RlZmluZSBQVl9TQVZFX0FMTF9DQUxMRVJfUkVHU8KgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4gwqDCoMKgwqDCoCAi
cHVzaCAlcmN4OyLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgXA0KPj4gwqDCoMKgwqDCoCAicHVzaCAlcmR4OyLCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4gLcKgwqDC
oCAicHVzaCAlcnNpOyLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgXA0KPj4gLcKgwqDCoCAicHVzaCAlcmRpOyLCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4gLcKgwqDC
oCAicHVzaCAlcjg7IsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCBcDQo+PiAtwqDCoMKgICJwdXNoICVyOTsiwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+IC3CoMKgwqAg
InB1c2ggJXIxMDsiwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIFwNCj4+IC3CoMKgwqAgInB1c2ggJXIxMTsiDQo+PiArwqDCoMKgIFBW
X1NBVkVfQ09NTU9OX0NBTExFUl9SRUdTDQo+PiDCoCAjZGVmaW5lIFBWX1JFU1RPUkVfQUxM
X0NBTExFUl9SRUdTwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0K
Pj4gLcKgwqDCoCAicG9wICVyMTE7IsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+PiAtwqDCoMKgICJwb3AgJXIxMDsiwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+
IC3CoMKgwqAgInBvcCAlcjk7IsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+PiAtwqDCoMKgICJwb3AgJXI4OyLCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4gLcKg
wqDCoCAicG9wICVyZGk7IsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCBcDQo+PiAtwqDCoMKgICJwb3AgJXJzaTsiwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+ICvCoMKg
wqAgUFZfUkVTVE9SRV9DT01NT05fQ0FMTEVSX1JFR1PCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCBcDQo+PiDCoMKgwqDCoMKgICJwb3AgJXJkeDsiwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+IMKg
wqDCoMKgwqAgInBvcCAlcmN4OyINCj4+IMKgICNlbmRpZg0KPj4gKyNkZWZpbmUgUFZfUFJP
TE9HVUVfQUxMKGZ1bmMpwqDCoMKgIFBWX1NBVkVfQUxMX0NBTExFUl9SRUdTDQo+PiArI2Rl
ZmluZSBQVl9FUElMT0dVRV9BTEwoZnVuYynCoMKgwqAgUFZfUkVTVE9SRV9BTExfQ0FMTEVS
X1JFR1MNCj4+ICsNCj4+IMKgIC8qDQo+PiDCoMKgICogR2VuZXJhdGUgYSB0aHVuayBhcm91
bmQgYSBmdW5jdGlvbiB3aGljaCBzYXZlcyBhbGwgY2FsbGVyLXNhdmUNCj4+IMKgwqAgKiBy
ZWdpc3RlcnMgZXhjZXB0IGZvciB0aGUgcmV0dXJuIHZhbHVlLsKgIFRoaXMgYWxsb3dzIEMg
ZnVuY3Rpb25zIHRvDQo+PiBAQCAtNjA3LDcgKzY3MSw3IEBAIGJvb2wgX19yYXdfY2FsbGVl
X3NhdmVfX19uYXRpdmVfdmNwdV9pc19wcmVlbXB0ZWQobG9uZyBjcHUpOw0KPj4gwqDCoCAq
IGZ1bmN0aW9ucy4NCj4+IMKgwqAgKi8NCj4+IMKgICNkZWZpbmUgUFZfVEhVTktfTkFNRShm
dW5jKSAiX19yYXdfY2FsbGVlX3NhdmVfIiAjZnVuYw0KPj4gLSNkZWZpbmUgX19QVl9DQUxM
RUVfU0FWRV9SRUdTX1RIVU5LKGZ1bmMsIHNlY3Rpb24pwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCBcDQo+PiArI2RlZmluZSBfX1BWX0NBTExFRV9TQVZFX1JFR1NfVEhVTksoZnVuYywgc2Vj
dGlvbiwgaGVscGVyKcKgwqDCoMKgwqDCoMKgIFwNCj4+IMKgwqDCoMKgwqAgZXh0ZXJuIHR5
cGVvZihmdW5jKSBfX3Jhd19jYWxsZWVfc2F2ZV8jI2Z1bmM7wqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCBcDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+PiDCoMKgwqDCoMKgIGFzbSgi
LnB1c2hzZWN0aW9uICIgc2VjdGlvbiAiLCBcImF4XCI7IsKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCBcDQo+PiBAQCAtNjE3LDE2ICs2ODEsMTggQEAgYm9vbCBfX3Jhd19jYWxs
ZWVfc2F2ZV9fX25hdGl2ZV92Y3B1X2lzX3ByZWVtcHRlZChsb25nIA0KPj4gY3B1KTsNCj4+
IMKgwqDCoMKgwqDCoMKgwqDCoCBQVl9USFVOS19OQU1FKGZ1bmMpICI6IsKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBB
U01fRU5EQlLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgXA0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIEZSQU1FX0JFR0lOwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+IC3C
oMKgwqDCoMKgwqDCoCBQVl9TQVZFX0FMTF9DQUxMRVJfUkVHU8KgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+ICvCoMKgwqDCoMKgwqDCoCBQVl9QUk9MT0dV
RV8jI2hlbHBlcihmdW5jKcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IFwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCAiY2FsbCAiICNmdW5jICI7IsKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4gLcKgwqDCoMKgwqDC
oMKgIFBWX1JFU1RPUkVfQUxMX0NBTExFUl9SRUdTwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgXA0KPj4gK8KgwqDCoMKgwqDCoMKgIFBWX0VQSUxPR1VFXyMjaGVs
cGVyKGZ1bmMpwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4g
wqDCoMKgwqDCoMKgwqDCoMKgIEZSQU1FX0VORMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAg
QVNNX1JFVMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCBcDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgIi5zaXplICIgUFZfVEhVTktfTkFN
RShmdW5jKSAiLCAuLSIgUFZfVEhVTktfTkFNRShmdW5jKSAiOyLCoMKgwqAgXA0KPj4gwqDC
oMKgwqDCoMKgwqDCoMKgICIucG9wc2VjdGlvbiIpDQo+PiDCoCAjZGVmaW5lIFBWX0NBTExF
RV9TQVZFX1JFR1NfVEhVTksoZnVuYynCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+IC3C
oMKgwqAgX19QVl9DQUxMRUVfU0FWRV9SRUdTX1RIVU5LKGZ1bmMsICIudGV4dCIpDQo+PiAr
wqDCoMKgIF9fUFZfQ0FMTEVFX1NBVkVfUkVHU19USFVOSyhmdW5jLCAiLnRleHQiLCBBTEwp
DQo+PiArI2RlZmluZSBQVl9DQUxMRUVfU0FWRV9SRUdTX01TUl9USFVOSyhmdW5jKcKgwqDC
oMKgwqDCoMKgIFwNCj4+ICvCoMKgwqAgX19QVl9DQUxMRUVfU0FWRV9SRUdTX1RIVU5LKGZ1
bmMsICIudGV4dCIsIE1TUikNCj4+IMKgIC8qIEdldCBhIHJlZmVyZW5jZSB0byBhIGNhbGxl
ZS1zYXZlIGZ1bmN0aW9uICovDQo+PiDCoCAjZGVmaW5lIFBWX0NBTExFRV9TQVZFKGZ1bmMp
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+PiBk
aWZmIC0tZ2l0IGEvYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnRfdHlwZXMuaCBiL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtLyANCj4+IHBhcmF2aXJ0X3R5cGVzLmgNCj4+IGluZGV4IGIw
OGI5ZDMxMjJkNi4uZjdmODc5MzE5ZTkwIDEwMDY0NA0KPj4gLS0tIGEvYXJjaC94ODYvaW5j
bHVkZS9hc20vcGFyYXZpcnRfdHlwZXMuaA0KPj4gKysrIGIvYXJjaC94ODYvaW5jbHVkZS9h
c20vcGFyYXZpcnRfdHlwZXMuaA0KPj4gQEAgLTkxLDE1ICs5MSwxNSBAQCBzdHJ1Y3QgcHZf
Y3B1X29wcyB7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdW5zaWduZWQg
aW50ICplY3gsIHVuc2lnbmVkIGludCAqZWR4KTsNCj4+IMKgwqDCoMKgwqAgLyogVW5zYWZl
IE1TUiBvcGVyYXRpb25zLsKgIFRoZXNlIHdpbGwgd2FybiBvciBwYW5pYyBvbiBmYWlsdXJl
LiAqLw0KPj4gLcKgwqDCoCB1NjQgKCpyZWFkX21zcikodTMyIG1zcik7DQo+PiAtwqDCoMKg
IHZvaWQgKCp3cml0ZV9tc3IpKHUzMiBtc3IsIHU2NCB2YWwpOw0KPj4gK8KgwqDCoCBzdHJ1
Y3QgcGFyYXZpcnRfY2FsbGVlX3NhdmUgcmVhZF9tc3I7DQo+PiArwqDCoMKgIHN0cnVjdCBw
YXJhdmlydF9jYWxsZWVfc2F2ZSB3cml0ZV9tc3I7DQo+PiDCoMKgwqDCoMKgIC8qDQo+PiDC
oMKgwqDCoMKgwqAgKiBTYWZlIE1TUiBvcGVyYXRpb25zLg0KPj4gwqDCoMKgwqDCoMKgICog
UmV0dXJucyAwIG9yIC1FSU8uDQo+PiDCoMKgwqDCoMKgwqAgKi8NCj4+IC3CoMKgwqAgaW50
ICgqcmVhZF9tc3Jfc2FmZSkodTMyIG1zciwgdTY0ICp2YWwpOw0KPj4gLcKgwqDCoCBpbnQg
KCp3cml0ZV9tc3Jfc2FmZSkodTMyIG1zciwgdTY0IHZhbCk7DQo+PiArwqDCoMKgIHN0cnVj
dCBwYXJhdmlydF9jYWxsZWVfc2F2ZSByZWFkX21zcl9zYWZlOw0KPj4gK8KgwqDCoCBzdHJ1
Y3QgcGFyYXZpcnRfY2FsbGVlX3NhdmUgd3JpdGVfbXNyX3NhZmU7DQo+PiDCoMKgwqDCoMKg
IHU2NCAoKnJlYWRfcG1jKShpbnQgY291bnRlcik7DQo+PiBAQCAtNTIwLDYgKzUyMCwxMCBA
QCB1bnNpZ25lZCBsb25nIHB2X25hdGl2ZV9zYXZlX2ZsKHZvaWQpOw0KPj4gwqAgdm9pZCBw
dl9uYXRpdmVfaXJxX2Rpc2FibGUodm9pZCk7DQo+PiDCoCB2b2lkIHB2X25hdGl2ZV9pcnFf
ZW5hYmxlKHZvaWQpOw0KPj4gwqAgdW5zaWduZWQgbG9uZyBwdl9uYXRpdmVfcmVhZF9jcjIo
dm9pZCk7DQo+PiArdm9pZCBwdl9uYXRpdmVfcmRtc3Iodm9pZCk7DQo+PiArdm9pZCBwdl9u
YXRpdmVfd3Jtc3Iodm9pZCk7DQo+PiArdm9pZCBwdl9uYXRpdmVfcmRtc3Jfc2FmZSh2b2lk
KTsNCj4+ICt2b2lkIHB2X25hdGl2ZV93cm1zcl9zYWZlKHZvaWQpOw0KPj4gwqAgI2VuZGlm
DQo+PiDCoCAjZGVmaW5lIHBhcmF2aXJ0X25vcMKgwqDCoCAoKHZvaWQgKilub3BfZnVuYykN
Cj4+IEBAIC01MjcsNiArNTMxLDcgQEAgdW5zaWduZWQgbG9uZyBwdl9uYXRpdmVfcmVhZF9j
cjIodm9pZCk7DQo+PiDCoCAjZW5kaWbCoMKgwqAgLyogX19BU1NFTUJMRVJfXyAqLw0KPj4g
wqAgI2RlZmluZSBBTFRfTk9UX1hFTsKgwqDCoCBBTFRfTk9UKFg4Nl9GRUFUVVJFX1hFTlBW
KQ0KPj4gKyNkZWZpbmUgQUxUX1hFTlBWX0NBTEzCoMKgwqAgQUxUX0RJUkVDVF9DQUxMKFg4
Nl9GRUFUVVJFX1hFTlBWKQ0KPj4gwqAgI2VuZGlmwqAgLyogQ09ORklHX1BBUkFWSVJUICov
DQo+PiDCoCAjZW5kaWbCoMKgwqAgLyogX0FTTV9YODZfUEFSQVZJUlRfVFlQRVNfSCAqLw0K
Pj4gZGlmZiAtLWdpdCBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3FzcGlubG9ja19wYXJhdmly
dC5oIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vIA0KPj4gcXNwaW5sb2NrX3BhcmF2aXJ0LmgN
Cj4+IGluZGV4IDBhOTg1Nzg0YmU5Yi4uMDM1MWFjYjVhMTQzIDEwMDY0NA0KPj4gLS0tIGEv
YXJjaC94ODYvaW5jbHVkZS9hc20vcXNwaW5sb2NrX3BhcmF2aXJ0LmgNCj4+ICsrKyBiL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL3FzcGlubG9ja19wYXJhdmlydC5oDQo+PiBAQCAtMTQsNyAr
MTQsOCBAQCB2b2lkIF9fbG9ja2Z1bmMgX19wdl9xdWV1ZWRfc3Bpbl91bmxvY2tfc2xvd3Bh
dGgoc3RydWN0IA0KPj4gcXNwaW5sb2NrICpsb2NrLCB1OCBsb2NrDQo+PiDCoMKgICovDQo+
PiDCoCAjaWZkZWYgQ09ORklHXzY0QklUDQo+PiAtX19QVl9DQUxMRUVfU0FWRV9SRUdTX1RI
VU5LKF9fcHZfcXVldWVkX3NwaW5fdW5sb2NrX3Nsb3dwYXRoLCAiLnNwaW5sb2NrLnRleHQi
KTsNCj4+ICtfX1BWX0NBTExFRV9TQVZFX1JFR1NfVEhVTksoX19wdl9xdWV1ZWRfc3Bpbl91
bmxvY2tfc2xvd3BhdGgsICIuc3BpbmxvY2sudGV4dCIsDQo+PiArwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgIEFMTCk7DQo+PiDCoCAjZGVmaW5lIF9fcHZfcXVldWVkX3NwaW5f
dW5sb2NrwqDCoMKgIF9fcHZfcXVldWVkX3NwaW5fdW5sb2NrDQo+PiDCoCAvKg0KPj4gQEAg
LTYxLDcgKzYyLDcgQEAgREVGSU5FX0FTTV9GVU5DKF9fcmF3X2NhbGxlZV9zYXZlX19fcHZf
cXVldWVkX3NwaW5fdW5sb2NrLA0KPj4gwqAgI2Vsc2UgLyogQ09ORklHXzY0QklUICovDQo+
PiDCoCBleHRlcm4gdm9pZCBfX2xvY2tmdW5jIF9fcHZfcXVldWVkX3NwaW5fdW5sb2NrKHN0
cnVjdCBxc3BpbmxvY2sgKmxvY2spOw0KPj4gLV9fUFZfQ0FMTEVFX1NBVkVfUkVHU19USFVO
SyhfX3B2X3F1ZXVlZF9zcGluX3VubG9jaywgIi5zcGlubG9jay50ZXh0Iik7DQo+PiArX19Q
Vl9DQUxMRUVfU0FWRV9SRUdTX1RIVU5LKF9fcHZfcXVldWVkX3NwaW5fdW5sb2NrLCAiLnNw
aW5sb2NrLnRleHQiLCBBTEwpOw0KPj4gwqAgI2VuZGlmIC8qIENPTkZJR182NEJJVCAqLw0K
Pj4gwqAgI2VuZGlmDQo+PiBkaWZmIC0tZ2l0IGEvYXJjaC94ODYva2VybmVsL3BhcmF2aXJ0
LmMgYi9hcmNoL3g4Ni9rZXJuZWwvcGFyYXZpcnQuYw0KPj4gaW5kZXggMDE1YmYyOTg0MzRm
Li5mZjdkN2ZkYWUzNjAgMTAwNjQ0DQo+PiAtLS0gYS9hcmNoL3g4Ni9rZXJuZWwvcGFyYXZp
cnQuYw0KPj4gKysrIGIvYXJjaC94ODYva2VybmVsL3BhcmF2aXJ0LmMNCj4+IEBAIC01MCw2
ICs1MCwyNCBAQCBERUZJTkVfQVNNX0ZVTkMocHZfbmF0aXZlX3NhdmVfZmwsICJwdXNoZjsg
cG9wIA0KPj4gJXJheCIsIC5ub2luc3RyLnRleHQpOw0KPj4gwqAgREVGSU5FX0FTTV9GVU5D
KHB2X25hdGl2ZV9pcnFfZGlzYWJsZSwgImNsaSIsIC5ub2luc3RyLnRleHQpOw0KPj4gwqAg
REVGSU5FX0FTTV9GVU5DKHB2X25hdGl2ZV9pcnFfZW5hYmxlLCAic3RpIiwgLm5vaW5zdHIu
dGV4dCk7DQo+PiDCoCBERUZJTkVfQVNNX0ZVTkMocHZfbmF0aXZlX3JlYWRfY3IyLCAibW92
ICVjcjIsICVyYXgiLCAubm9pbnN0ci50ZXh0KTsNCj4+ICtERUZJTkVfQVNNX0ZVTkMocHZf
bmF0aXZlX3JkbXNyLA0KPj4gK8KgwqDCoMKgwqDCoMKgICIxOiByZG1zclxuIg0KPj4gK8Kg
wqDCoMKgwqDCoMKgICIyOlxuIg0KPj4gK8KgwqDCoMKgwqDCoMKgIF9BU01fRVhUQUJMRV9U
WVBFKDFiLCAyYiwgRVhfVFlQRV9SRE1TUiksIC5ub2luc3RyLnRleHQpOw0KPj4gK0RFRklO
RV9BU01fRlVOQyhwdl9uYXRpdmVfd3Jtc3IsDQo+PiArwqDCoMKgwqDCoMKgwqAgIjE6IHdy
bXNyXG4iDQo+PiArwqDCoMKgwqDCoMKgwqAgIjI6XG4iDQo+PiArwqDCoMKgwqDCoMKgwqAg
X0FTTV9FWFRBQkxFX1RZUEUoMWIsIDJiLCBFWF9UWVBFX1dSTVNSKSwgLm5vaW5zdHIudGV4
dCk7DQo+PiArREVGSU5FX0FTTV9GVU5DKHB2X25hdGl2ZV9yZG1zcl9zYWZlLA0KPj4gK8Kg
wqDCoMKgwqDCoMKgICIxOiByZG1zcjsgeG9yICVlY3gsICVlY3hcbiINCj4+ICvCoMKgwqDC
oMKgwqDCoCAiMjpcbiINCj4+ICvCoMKgwqDCoMKgwqDCoCBfQVNNX0VYVEFCTEVfVFlQRV9S
RUcoMWIsIDJiLCBFWF9UWVBFX1JETVNSX1NBRkUsICUlZWN4KSwNCj4+ICvCoMKgwqDCoMKg
wqDCoCAubm9pbnN0ci50ZXh0KTsNCj4+ICtERUZJTkVfQVNNX0ZVTkMocHZfbmF0aXZlX3dy
bXNyX3NhZmUsDQo+PiArwqDCoMKgwqDCoMKgwqAgIjE6IHdybXNyOyB4b3IgJWVheCwgJWVh
eFxuIg0KPj4gK8KgwqDCoMKgwqDCoMKgICIyOlxuIg0KPj4gK8KgwqDCoMKgwqDCoMKgIF9B
U01fRVhUQUJMRV9UWVBFX1JFRygxYiwgMmIsIEVYX1RZUEVfV1JNU1JfU0FGRSwgJSVlYXgp
LA0KPj4gK8KgwqDCoMKgwqDCoMKgIC5ub2luc3RyLnRleHQpOw0KPj4gwqAgI2VuZGlmDQo+
PiDCoCBERUZJTkVfU1RBVElDX0tFWV9GQUxTRSh2aXJ0X3NwaW5fbG9ja19rZXkpOw0KPj4g
QEAgLTEyOSwxMCArMTQ3LDEwIEBAIHN0cnVjdCBwYXJhdmlydF9wYXRjaF90ZW1wbGF0ZSBw
dl9vcHMgPSB7DQo+PiDCoMKgwqDCoMKgIC5jcHUucmVhZF9jcjDCoMKgwqDCoMKgwqDCoCA9
IG5hdGl2ZV9yZWFkX2NyMCwNCj4+IMKgwqDCoMKgwqAgLmNwdS53cml0ZV9jcjDCoMKgwqDC
oMKgwqDCoCA9IG5hdGl2ZV93cml0ZV9jcjAsDQo+PiDCoMKgwqDCoMKgIC5jcHUud3JpdGVf
Y3I0wqDCoMKgwqDCoMKgwqAgPSBuYXRpdmVfd3JpdGVfY3I0LA0KPj4gLcKgwqDCoCAuY3B1
LnJlYWRfbXNywqDCoMKgwqDCoMKgwqAgPSBuYXRpdmVfcmVhZF9tc3IsDQo+PiAtwqDCoMKg
IC5jcHUud3JpdGVfbXNywqDCoMKgwqDCoMKgwqAgPSBuYXRpdmVfd3JpdGVfbXNyLA0KPj4g
LcKgwqDCoCAuY3B1LnJlYWRfbXNyX3NhZmXCoMKgwqAgPSBuYXRpdmVfcmVhZF9tc3Jfc2Fm
ZSwNCj4+IC3CoMKgwqAgLmNwdS53cml0ZV9tc3Jfc2FmZcKgwqDCoCA9IG5hdGl2ZV93cml0
ZV9tc3Jfc2FmZSwNCj4+ICvCoMKgwqAgLmNwdS5yZWFkX21zcsKgwqDCoMKgwqDCoMKgID0g
X19QVl9JU19DQUxMRUVfU0FWRShwdl9uYXRpdmVfcmRtc3IpLA0KPj4gK8KgwqDCoCAuY3B1
LndyaXRlX21zcsKgwqDCoMKgwqDCoMKgID0gX19QVl9JU19DQUxMRUVfU0FWRShwdl9uYXRp
dmVfd3Jtc3IpLA0KPj4gK8KgwqDCoCAuY3B1LnJlYWRfbXNyX3NhZmXCoMKgwqAgPSBfX1BW
X0lTX0NBTExFRV9TQVZFKHB2X25hdGl2ZV9yZG1zcl9zYWZlKSwNCj4+ICvCoMKgwqAgLmNw
dS53cml0ZV9tc3Jfc2FmZcKgwqDCoCA9IF9fUFZfSVNfQ0FMTEVFX1NBVkUocHZfbmF0aXZl
X3dybXNyX3NhZmUpLA0KPj4gwqDCoMKgwqDCoCAuY3B1LnJlYWRfcG1jwqDCoMKgwqDCoMKg
wqAgPSBuYXRpdmVfcmVhZF9wbWMsDQo+PiDCoMKgwqDCoMKgIC5jcHUubG9hZF90cl9kZXNj
wqDCoMKgID0gbmF0aXZlX2xvYWRfdHJfZGVzYywNCj4+IMKgwqDCoMKgwqAgLmNwdS5zZXRf
bGR0wqDCoMKgwqDCoMKgwqAgPSBuYXRpdmVfc2V0X2xkdCwNCj4+IGRpZmYgLS1naXQgYS9h
cmNoL3g4Ni94ZW4vZW5saWdodGVuX3B2LmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuX3B2
LmMNCj4+IGluZGV4IDNiZTM4MzUwZjA0NC4uYzI3OWIyYmVmN2ViIDEwMDY0NA0KPj4gLS0t
IGEvYXJjaC94ODYveGVuL2VubGlnaHRlbl9wdi5jDQo+PiArKysgYi9hcmNoL3g4Ni94ZW4v
ZW5saWdodGVuX3B2LmMNCj4+IEBAIC0xMTYwLDM2ICsxMTYwLDY2IEBAIHN0YXRpYyB2b2lk
IHhlbl9kb193cml0ZV9tc3IodTMyIG1zciwgdTY0IHZhbCwgaW50ICplcnIpDQo+PiDCoMKg
wqDCoMKgIH0NCj4+IMKgIH0NCj4+IC1zdGF0aWMgaW50IHhlbl9yZWFkX21zcl9zYWZlKHUz
MiBtc3IsIHU2NCAqdmFsKQ0KPj4gLXsNCj4+ICsvKg0KPj4gKyAqIFByb3RvdHlwZXMgZm9y
IGZ1bmN0aW9ucyBjYWxsZWQgdmlhIFBWX0NBTExFRV9TQVZFX1JFR1NfVEhVTksoKSBpbiBv
cmRlcg0KPj4gKyAqIHRvIGF2b2lkIHdhcm5pbmdzIHdpdGggIi1XbWlzc2luZy1wcm90b3R5
cGVzIi4NCj4+ICsgKi8NCj4+ICtzdHJ1Y3QgeGVuX3JkbXNyX3NhZmVfcmV0IHsNCj4+ICvC
oMKgwqAgdTY0IHZhbDsNCj4+IMKgwqDCoMKgwqAgaW50IGVycjsNCj4+ICt9Ow0KPj4gK3N0
cnVjdCB4ZW5fcmRtc3Jfc2FmZV9yZXQgeGVuX3JlYWRfbXNyX3NhZmUodTMyIG1zcik7DQo+
PiAraW50IHhlbl93cml0ZV9tc3Jfc2FmZSh1MzIgbXNyLCB1MzIgbG93LCB1MzIgaGlnaCk7
DQo+PiArdTY0IHhlbl9yZWFkX21zcih1MzIgbXNyKTsNCj4+ICt2b2lkIHhlbl93cml0ZV9t
c3IodTMyIG1zciwgdTMyIGxvdywgdTMyIGhpZ2gpOw0KPj4gLcKgwqDCoCAqdmFsID0geGVu
X2RvX3JlYWRfbXNyKG1zciwgJmVycik7DQo+PiAtwqDCoMKgIHJldHVybiBlcnI7DQo+PiAr
X192aXNpYmxlIHN0cnVjdCB4ZW5fcmRtc3Jfc2FmZV9yZXQgeGVuX3JlYWRfbXNyX3NhZmUo
dTMyIG1zcikNCj4+ICt7DQo+PiArwqDCoMKgIHN0cnVjdCB4ZW5fcmRtc3Jfc2FmZV9yZXQg
cmV0Ow0KPiANCj4gc3RydWN0IHhlbl9yZG1zcl9zYWZlX3JldCByZXQgPSB7IDAsIDAgfTsN
Cj4gDQo+IEJlY2F1c2UgdGhlICdlcnInIG1lbWJlciBtYXkgbm90IGJlIHNldCBpbiB4ZW5f
ZG9fcmVhZF9tc3IoKS4NCg0KUmlnaHQuDQoNCj4gDQo+PiArDQo+PiArwqDCoMKgIHJldC52
YWwgPSB4ZW5fZG9fcmVhZF9tc3IobXNyLCAmcmV0LmVycik7DQo+PiArwqDCoMKgIHJldHVy
biByZXQ7DQo+PiDCoCB9DQo+PiArI2RlZmluZSBQVl9QUk9MT0dVRV9NU1JfeGVuX3JlYWRf
bXNyX3NhZmXCoMKgwqAgIm1vdiAlZWN4LCAlZWRpOyINCj4+ICsjZGVmaW5lIFBWX0VQSUxP
R1VFX01TUl94ZW5fcmVhZF9tc3Jfc2FmZcKgwqDCoCBcDQo+PiArwqDCoMKgICJtb3YgJWVk
eCwgJWVjeDsgbW92ICVyYXgsICVyZHg7IG1vdiAlZWF4LCAlZWF4OyBzaHIgJDB4MjAsICVy
ZHg7Ig0KPj4gK1BWX0NBTExFRV9TQVZFX1JFR1NfTVNSX1RIVU5LKHhlbl9yZWFkX21zcl9z
YWZlKTsNCj4+IC1zdGF0aWMgaW50IHhlbl93cml0ZV9tc3Jfc2FmZSh1MzIgbXNyLCB1NjQg
dmFsKQ0KPj4gK19fdmlzaWJsZSBpbnQgeGVuX3dyaXRlX21zcl9zYWZlKHUzMiBtc3IsIHUz
MiBsb3csIHUzMiBoaWdoKQ0KPiANCj4gSSB0aGluayB3ZSBjYW4gYXZvaWQgc3BsaXR0aW5n
IHRoaXMgdTY0IGludG8gdHdvIHUzMi4NCg0KVGhpcyBpcyByZWxhdGVkIHRvIHRoZSBuYXRp
dmUgV1JNU1IgaW50ZXJmYWNlLiBUaGUgV1JNU1IgbmVlZHMgdG8gYmUNCmFibGUgdG8gYmUg
cmVwbGFjZWQgYnkgdGhlIGNhbGwgb2YgdGhlIFhlbiBzcGVjaWZpYyBmdW5jdGlvbi4NCg0K
SSBjb3VsZCBoYW5kbGUgdGhpcyBpbiB0aGUgcHJvbG9ndWUgaGVscGVycywgYnV0IEknZCBw
cmVmZXIgdG8ga2VlcA0KdGhvc2UgaGVscGVycyBhcyBzbWFsbCBhcyBwb3NzaWJsZS4NCg0K
PiANCj4+IMKgIHsNCj4+IMKgwqDCoMKgwqAgaW50IGVyciA9IDA7DQo+PiAtwqDCoMKgIHhl
bl9kb193cml0ZV9tc3IobXNyLCB2YWwsICZlcnIpOw0KPj4gK8KgwqDCoCB4ZW5fZG9fd3Jp
dGVfbXNyKG1zciwgKHU2NCloaWdoIDw8IDMyIHwgbG93LCAmZXJyKTsNCj4+IMKgwqDCoMKg
wqAgcmV0dXJuIGVycjsNCj4+IMKgIH0NCj4+ICsjZGVmaW5lIFBWX1BST0xPR1VFX01TUl94
ZW5fd3JpdGVfbXNyX3NhZmXCoMKgwqAgXA0KPj4gK8KgwqDCoCAibW92ICVlY3gsICVlZGk7
IG1vdiAlZWF4LCAlZXNpOyINCj4+ICsjZGVmaW5lIFBWX0VQSUxPR1VFX01TUl94ZW5fd3Jp
dGVfbXNyX3NhZmUNCj4+ICtQVl9DQUxMRUVfU0FWRV9SRUdTX01TUl9USFVOSyh4ZW5fd3Jp
dGVfbXNyX3NhZmUpOw0KPj4gLXN0YXRpYyB1NjQgeGVuX3JlYWRfbXNyKHUzMiBtc3IpDQo+
PiArX192aXNpYmxlIHU2NCB4ZW5fcmVhZF9tc3IodTMyIG1zcikNCj4+IMKgIHsNCj4+IMKg
wqDCoMKgwqAgaW50IGVycjsNCj4+IMKgwqDCoMKgwqAgcmV0dXJuIHhlbl9kb19yZWFkX21z
cihtc3IsIHhlbl9tc3Jfc2FmZSA/ICZlcnIgOiBOVUxMKTsNCj4+IMKgIH0NCj4+ICsjZGVm
aW5lIFBWX1BST0xPR1VFX01TUl94ZW5fcmVhZF9tc3LCoMKgwqAgIm1vdiAlZWN4LCAlZWRp
OyINCj4+ICsjZGVmaW5lIFBWX0VQSUxPR1VFX01TUl94ZW5fcmVhZF9tc3LCoMKgwqAgXA0K
Pj4gK8KgwqDCoCAibW92ICVyYXgsICVyZHg7IG1vdiAlZWF4LCAlZWF4OyBzaHIgJDB4MjAs
ICVyZHg7Ig0KPj4gK1BWX0NBTExFRV9TQVZFX1JFR1NfTVNSX1RIVU5LKHhlbl9yZWFkX21z
cik7DQo+PiAtc3RhdGljIHZvaWQgeGVuX3dyaXRlX21zcih1MzIgbXNyLCB1NjQgdmFsKQ0K
Pj4gK19fdmlzaWJsZSB2b2lkIHhlbl93cml0ZV9tc3IodTMyIG1zciwgdTMyIGxvdywgdTMy
IGhpZ2gpDQo+IA0KPiBEaXR0by4NCg0KU2VlIGFib3ZlLg0KDQo+IA0KPj4gwqAgew0KPj4g
wqDCoMKgwqDCoCBpbnQgZXJyOw0KPj4gLcKgwqDCoCB4ZW5fZG9fd3JpdGVfbXNyKG1zciwg
dmFsLCB4ZW5fbXNyX3NhZmUgPyAmZXJyIDogTlVMTCk7DQo+PiArwqDCoMKgIHhlbl9kb193
cml0ZV9tc3IobXNyLCAodTY0KWhpZ2ggPDwgMzIgfCBsb3csDQo+PiArwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIHhlbl9tc3Jfc2FmZSA/ICZlcnIgOiBOVUxMKTsNCj4+IMKgIH0NCj4+
ICsjZGVmaW5lIFBWX1BST0xPR1VFX01TUl94ZW5fd3JpdGVfbXNywqDCoMKgIFwNCj4+ICvC
oMKgwqAgIm1vdiAlZWN4LCAlZWRpOyBtb3YgJWVheCwgJWVzaTsiDQo+PiArI2RlZmluZSBQ
Vl9FUElMT0dVRV9NU1JfeGVuX3dyaXRlX21zcg0KPj4gK1BWX0NBTExFRV9TQVZFX1JFR1Nf
TVNSX1RIVU5LKHhlbl93cml0ZV9tc3IpOw0KPj4gwqAgLyogVGhpcyBpcyBjYWxsZWQgb25j
ZSB3ZSBoYXZlIHRoZSBjcHVfcG9zc2libGVfbWFzayAqLw0KPj4gwqAgdm9pZCBfX2luaXQg
eGVuX3NldHVwX3ZjcHVfaW5mb19wbGFjZW1lbnQodm9pZCkNCg0KDQpKdWVyZ2VuDQo=
--------------duqhFBg0pMv7DTJhelp99NN2
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-----

--------------duqhFBg0pMv7DTJhelp99NN2--

--------------a0ybUBCT40lur4qpzFe426ln--

--------------xUHWlNj9eo72qDdlI6FcdrVq
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/Ey8FAmgh2YkFAwAAAAAACgkQsN6d1ii/Ey/A
Nwf8CrrTEFqq1w7UYU3GEkVHOFYmAIUYHV9E7HFE1xdGCxTH7MEV5arhYTmqmNtWwzjNN5Mv6sjL
7mqSvWi38wNV02lnvdFLQ0P8fC9dgcVDesZC+jhQGVa0JqOkz5NISJXgrD1FsDRNC2TWTgp4Z4Kw
S2a6FAtQ49IiYfrzGZP0VixoplH8DWm7Kcro2jzHVp8Ux1fSxYFjNSUwSu52vsjUc97ifkUgb+9c
SiGP+clXzF6vGZ3D9rkab6fJDViK+06HedykwQZRydHx8vLP2OuGMVvGQN4AmXIBh1y8GNr65r9W
kdOxZ3mAhc5tsfXWFQmxt7LKofOqenCUjpuAFpzFXw==
=0OkC
-----END PGP SIGNATURE-----

--------------xUHWlNj9eo72qDdlI6FcdrVq--


From xen-devel-bounces@lists.xenproject.org Mon May 12 11:24:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 11:24:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981294.1367687 (Exim 4.92)
	(envelope-from )
	id 1uERH1-00023s-D0; Mon, 12 May 2025 11:24:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981294.1367687; Mon, 12 May 2025 11:24:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uERH1-00023l-AA; Mon, 12 May 2025 11:24:43 +0000
Received: by outflank-mailman (input) for mailman id 981294;
 Mon, 12 May 2025 11:24:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uERH0-00023f-DH
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 11:24:42 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b1b31ba4-2f23-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 13:24:40 +0200 (CEST)
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 E022421187;
 Mon, 12 May 2025 11:24:38 +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 5A86D137D2;
 Mon, 12 May 2025 11:24:38 +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 tg7FE3baIWi/bAAAD6G6ig
 (envelope-from ); Mon, 12 May 2025 11: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" 
X-Inumbo-ID: b1b31ba4-2f23-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1747049079; 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=ui7mqcr9hvFnd1B9uz1qipVuFbpnFm90KghQSLPhAAs=;
	b=eldbzMCPtM62TPENB17p0s6wvJyRQ6ojhkFbtE8LZ6oQs4hfazUq+nhyAPDuWV4ka4OM98
	0tLnAm6hhtH8I2MqXkCCwrEwnGEngk0YbMEVCIouaAfYBcpc/GxIK7ZyxsoQnNkQFvHsuQ
	ytXK8AuD5IZdnC+mPxdM35FEpW7+0O4=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1747049078; 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=ui7mqcr9hvFnd1B9uz1qipVuFbpnFm90KghQSLPhAAs=;
	b=eGpsyQnsmPKrgIp87DeDdsVFtzoV90iH0Fx2Felje7xasGMdpV7rvanG3GzLxkbOVkGO6E
	QJoX5df3LReKGHbeSC+HMEKP9RGyNuHgqJZAc9Y2RTzJGRI3YigbwYMUOZsJlQhrrsySTY
	KfUmQWpeleJFZp5wzWJ8PEvCpRSkfl8=
Message-ID: 
Date: Mon, 12 May 2025 13:24:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
From: Juergen Gross 
To: Xin Li , linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev
Cc: Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 , Thomas Gleixner
 , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky , xen-devel@lists.xenproject.org
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
Content-Language: en-US
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: <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------cmlXY6sTu0icBS3IID1Pum54"
X-Spam-Flag: NO
X-Spam-Score: -5.20
X-Spam-Level: 
X-Spamd-Result: default: False [-5.20 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain,text/x-patch];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:+,5:~,6:~];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[14];
	MID_RHS_MATCH_FROM(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_DN_SOME(0.00)[];
	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,suse.com:mid];
	HAS_ATTACHMENT(0.00)[]

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------cmlXY6sTu0icBS3IID1Pum54
Content-Type: multipart/mixed; boundary="------------FQpVx09W26fNIC7HeaTTIYft";
 protected-headers="v1"
From: Juergen Gross 
To: Xin Li , linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev
Cc: Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 , Thomas Gleixner
 , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky , xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
In-Reply-To: <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>

--------------FQpVx09W26fNIC7HeaTTIYft
Content-Type: multipart/mixed; boundary="------------8gPqDNrCU3txf0i5KlVP6wo8"

--------------8gPqDNrCU3txf0i5KlVP6wo8
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

Tm93IHdpdGggdGhlIG1lbnRpb25lZCBwYXRjaCByZWFsbHkgYXR0YWNoZWQuIDotKQ0KDQpP
biAxMi4wNS4yNSAxMzoyMCwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4gT24gMDkuMDUuMjUg
MTA6MTgsIFhpbiBMaSB3cm90ZToNCj4+IE9uIDUvNi8yMDI1IDI6MjAgQU0sIEp1ZXJnZW4g
R3Jvc3Mgd3JvdGU6DQo+Pj4gSW5zdGVhZCBvZiBoYXZpbmcgY2FsbGJhY2sgZnVuY3Rpb25z
IGZvciByZG1zci93cm1zciBvbiBuYXRpdmUsIHN3aXRjaA0KPj4+IHRvIGlubGluZSB0aGUg
cmVzcGVjdGl2ZSBpbnN0cnVjdGlvbnMgZGlyZWN0bHkgaW4gb3JkZXIgdG8gYXZvaWQNCj4+
PiBvdmVyaGVhZCB3aXRoIHRoZSBjYWxsIGludGVyZmFjZS4NCj4+DQo+PiBUbyBtZSwgdGhp
cyBpcyBhIGJlbmVmaWNpYWwgYWRkaXRpb24gdG8gdGhlIGV4aXN0aW5nIHB2b3BzIE1TUiBj
b2RlLg0KPj4NCj4+Pg0KPj4+IFRoaXMgcmVxdWlyZXMgdG8gdXNlIHRoZSBpbnN0cnVjdGlv
biBpbnRlcmZhY2VzIGZvciByZG1zci93cm1zcg0KPj4+IGVtdWxhdGlvbiB3aGVuIHJ1bm5p
bmcgYXMgYSBYZW4gUFYgZ3Vlc3QuDQo+Pj4NCj4+PiBJbiBvcmRlciB0byBwcmVwYXJlIHN1
cHBvcnQgZm9yIHRoZSBpbW1lZGlhdGUgZm9ybXMgb2YgUkRNU1IgYW5kIFdSTVNSDQo+Pj4g
d2hlbiBub3QgcnVubmluZyBhcyBhIFhlbiBQViBndWVzdCwgdXNlIHRoZSBSRE1TUiBhbmQg
V1JNU1INCj4+PiBpbnN0cnVjdGlvbnMgYXMgdGhlIGZhbGxiYWNrIGNhc2UgaW5zdGVhZCBv
ZiBBTFRfQ0FMTF9JTlNUUi4NCj4+DQo+PiBJJ20gdHJ5aW5nIHRvIGV2YWx1YXRlIGhvdyB0
byBhZGQgdGhlIGltbWVkaWF0ZSBmb3JtIE1TUiBpbnN0cnVjdGlvbnMNCj4+IG9uIHRvcCBv
ZiB0aGlzIHBhdGNoIHNldC7CoCBBbmQgSSdtIGNsb3NlIHRvIGdldCBpdCBkb25lLg0KPiAN
Cj4gVGhlcmUgaXMgc29tZXRoaW5nIHRvIGNvbnNpZGVyIHdoZW4gcnVubmluZyBhcyBhIFhl
biBQViBndWVzdCwgLi4uDQo+IA0KPj4NCj4+Pg0KPj4+IE5vdGUgdGhhdCBpbiB0aGUgWGVu
IFBWIGNhc2UgdGhlIFJETVNSL1dSTVNSIHBhdGNoaW5nIG11c3Qgbm90IGhhcHBlbg0KPj4+
IGV2ZW4gYXMgYW4gaW50ZXJtZWRpYXRlIHN0ZXAsIGFzIHRoaXMgd291bGQgY2xvYmJlciB0
aGUgaW5kaXJlY3QgY2FsbA0KPj4+IGluZm9ybWF0aW9uIG5lZWRlZCB3aGVuIHBhdGNoaW5n
IGluIHRoZSBkaXJlY3QgY2FsbCBmb3IgdGhlIFhlbiBjYXNlLg0KPj4NCj4+IEdvb2QgcG9p
bnQhDQo+IA0KPiAuLi4gYXMgdGhpcyBzdGlsbCBuZWVkcyB0byBiZSB0cnVlLg0KPiANCj4g
VGhlcmUgYXJlIDIgZGlmZmVyZW50IHdheXMgdG8gZGVhbCB3aXRoIHRoaXM6DQo+IA0KPiAx
LiBXaGVuIHJ1bm5pbmcgYXMgYSBYZW4gUFYgZ3Vlc3QgZGlzYWJsZSBYODZfRkVBVFVSRV9X
Uk1TUk5TIGFuZA0KPiAgwqDCoCBBU01fV1JNU1JOU19JTU0gKGUuZy4gaW4geGVuX2luaXRf
Y2FwYWJpbGl0aWVzKCkpLg0KPiANCj4gMi4gQnVmZmVyIHRoZSBvcmlnaW5hbCBpbnN0cnVj
dGlvbiBiZWZvcmUgcGF0Y2hpbmcgaW4gYXBwbHlfYWx0ZXJuYXRpdmVzKCkNCj4gIMKgwqAg
aW4gb3JkZXIgdG8gYXZvaWQgdGhlIHNlcXVlbmNlIGxpbWl0YXRpb24gYWJvdmUgKHNlZSBh
dHRhY2hlZCBwYXRjaCkuDQo+IA0KPj4gRGVjaWRpbmcgd2hldGhlciB0byByZXRhaW4gdGhl
IHB2b3BzIE1TUiBBUEkgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mDQo+PiB0aGUgeDg2IG1h
aW50YWluZXJzLCB3aG8gYXJlIHRoZSBvbmVzIGV4cGVyaWVuY2luZyB0aGUgY2hhbGxlbmdl
cyBvZiANCj4+IG1haW50YWluaW5nIHRoZSBjb2RlLg0KPiANCj4gV2VsbCwgSSdtIHRoZSBQ
ViBvcHMgbWFpbnRhaW5lciwgc28gaXQgaXMgYmFzaWNhbGx5IG1lIHdobyBuZWVkcyB0byBk
ZWFsDQo+IHdpdGggdGhpcy4gT1RPSCBJIGRvIHVuZGVyc3RhbmQgdGhhdCBkaWFnbm9zaXMg
b2YgcHJvYmxlbXMgd2l0aCBQViBvcHMgaXMNCj4gbW9yZSBjb21wbGljYXRlZCB0aGFuIHdp
dGhvdXQuDQo+IA0KPj4NCj4+IHRnbHggc2FpZCBAaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcv
bGttbC84N3kxaDgxaHQ0LmZmc0B0Z2x4LzoNCj4+DQo+PiDCoD4gSSBmdW5kYW1lbnRhbHkg
aGF0ZSBhZGRpbmcgdGhpcyB0byB0aGUgUFYgaW5mcmFzdHJ1Y3R1cmUuIFdlIGRvbid0DQo+
PiDCoD4gd2FudCBtb3JlIFBWIG9wcywgcXVpdGUgdGhlIGNvbnRyYXJ5Lg0KPj4NCj4+IFRo
YXQgaXMgdGhlIHJlYXNvbiBJIHRvb2sgYSBkaWZmZXJlbnQgZGlyZWN0aW9uLCBpLmUuLCBy
ZW1vdmluZyB0aGUNCj4+IHB2b3BzIE1TUiBBUElzLsKgIEJ1dCBpZiB5b3VyIGFwcHJvYWNo
IGlzIGNsZWFuZXIsIHRoZXkgbWF5IHByZWZlciBpdC4NCj4gDQo+IEluIHRoZSBlbmQgaXQg
aXNuJ3QgYWRkaW5nIGFkZGl0aW9uYWwgUFYgb3BzIGludGVyZmFjZXMuIEl0IGlzIG1vZGlm
eWluZw0KPiBleGlzdGluZyBvbmVzLg0KPiANCj4+DQo+Pj4gZGlmZiAtLWdpdCBhL2FyY2gv
eDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0LmggYi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wYXJh
dmlydC5oDQo+Pj4gaW5kZXggYTQ2M2M3NDdjNzgwLi5kZjEwYjBlNGY3YjggMTAwNjQ0DQo+
Pj4gLS0tIGEvYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnQuaA0KPj4+ICsrKyBiL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0LmgNCj4+PiBAQCAtMTc1LDI0ICsxNzUsNzIg
QEAgc3RhdGljIGlubGluZSB2b2lkIF9fd3JpdGVfY3I0KHVuc2lnbmVkIGxvbmcgeCkNCj4+
PiDCoMKgwqDCoMKgIFBWT1BfVkNBTEwxKGNwdS53cml0ZV9jcjQsIHgpOw0KPj4+IMKgIH0N
Cj4+PiAtc3RhdGljIGlubGluZSB1NjQgcGFyYXZpcnRfcmVhZF9tc3IodTMyIG1zcikNCj4+
PiArc3RhdGljIF9fYWx3YXlzX2lubGluZSB1NjQgcGFyYXZpcnRfcmVhZF9tc3IodTMyIG1z
cikNCj4+PiDCoCB7DQo+Pj4gLcKgwqDCoCByZXR1cm4gUFZPUF9DQUxMMSh1NjQsIGNwdS5y
ZWFkX21zciwgbXNyKTsNCj4+PiArwqDCoMKgIEVBWF9FRFhfREVDTEFSRV9BUkdTKHZhbCwg
bG93LCBoaWdoKTsNCj4+DQo+PiBUaGlzIGlzIHVuZGVyIENPTkZJR19QQVJBVklSVF9YWEws
IHRodXMgQ09ORklHX1hFTl9QViBhbmQgQ09ORklHX1g4Nl82NCwNCj4+IHRoZXJlZm9yZSB3
ZSBkb24ndCBuZWVkIHRvIGNvbnNpZGVyIDMyLWJpdCBhdCBhbGwsIG5vPw0KPiANCj4gUmln
aHQuIE9UT0ggdGhlIG1hY3JvcyBhcmUgdGhlcmUsIHNvIHdoeSBub3QgdXNlIHRoZW0/DQo+
IA0KPiBJbiB0aGUgZW5kIEknbSBmaW5lIHRvIG9wZW4gY29kZSB0aGUgNjQtYml0IGNhc2Ug
aGVyZS4NCj4gDQo+Pg0KPj4+ICsNCj4+PiArwqDCoMKgIFBWT1BfVEVTVF9OVUxMKGNwdS5y
ZWFkX21zcik7DQo+Pj4gK8KgwqDCoCBhc20gdm9sYXRpbGUoIjE6ICJBTFRFUk5BVElWRV8y
KFBBUkFWSVJUX0NBTEwsDQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgICJyZG1zciIsIEFMVF9OT1RfWEVOLA0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCBBTFRfQ0FMTF9JTlNUUiwgQUxUX1hFTlBWX0NBTEwpDQo+
Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAiMjpcbiINCj4+PiArwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIF9BU01fRVhUQUJMRV9UWVBFKDFiLCAyYiwgRVhfVFlQRV9SRE1TUikN
Cj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogRUFYX0VEWF9SRVQodmFsLCBsb3cs
IGhpZ2gpLCBBU01fQ0FMTF9DT05TVFJBSU5UDQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCA6IHBhcmF2aXJ0X3B0cihjcHUucmVhZF9tc3IpLCAiYyIgKG1zcikpOw0KPj4+ICsN
Cj4+PiArwqDCoMKgIHJldHVybiBFQVhfRURYX1ZBTCh2YWwsIGxvdywgaGlnaCk7DQo+Pj4g
wqAgfQ0KPj4+IC1zdGF0aWMgaW5saW5lIHZvaWQgcGFyYXZpcnRfd3JpdGVfbXNyKHUzMiBt
c3IsIHU2NCB2YWwpDQo+Pj4gK3N0YXRpYyBfX2Fsd2F5c19pbmxpbmUgdm9pZCBwYXJhdmly
dF93cml0ZV9tc3IodTMyIG1zciwgdTY0IHZhbCkNCj4+PiDCoCB7DQo+Pj4gLcKgwqDCoCBQ
Vk9QX1ZDQUxMMihjcHUud3JpdGVfbXNyLCBtc3IsIHZhbCk7DQo+Pj4gK8KgwqDCoCBQVk9Q
X1RFU1RfTlVMTChjcHUud3JpdGVfbXNyKTsNCj4+PiArwqDCoMKgIGFzbSB2b2xhdGlsZSgi
MTogIkFMVEVSTkFUSVZFXzIoUEFSQVZJUlRfQ0FMTCwNCj4+PiArwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIndybXNyIiwgQUxUX05PVF9YRU4sDQo+Pj4gK8Kg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEFMVF9DQUxMX0lOU1RSLCBB
TFRfWEVOUFZfQ0FMTCkNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIjI6XG4i
DQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIF9BU01fRVhUQUJMRV9UWVBFKDFi
LCAyYiwgRVhfVFlQRV9XUk1TUikNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
OiBBU01fQ0FMTF9DT05TVFJBSU5UDQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IDogcGFyYXZpcnRfcHRyKGNwdS53cml0ZV9tc3IpLA0KPj4+ICvCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCAiYyIgKG1zciksICJhIiAoKHUzMil2YWwpLCAiZCIgKCh1MzIpKHZhbCA+
PiAzMikpDQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogIm1lbW9yeSIpOw0K
Pj4+IMKgIH0NCj4+PiAtc3RhdGljIGlubGluZSBpbnQgcGFyYXZpcnRfcmVhZF9tc3Jfc2Fm
ZSh1MzIgbXNyLCB1NjQgKnZhbCkNCj4+PiArc3RhdGljIF9fYWx3YXlzX2lubGluZSBpbnQg
cGFyYXZpcnRfcmVhZF9tc3Jfc2FmZSh1MzIgbXNyLCB1NjQgKnApDQo+Pj4gwqAgew0KPj4+
IC3CoMKgwqAgcmV0dXJuIFBWT1BfQ0FMTDIoaW50LCBjcHUucmVhZF9tc3Jfc2FmZSwgbXNy
LCB2YWwpOw0KPj4+ICvCoMKgwqAgaW50IGVycjsNCj4+PiArwqDCoMKgIEVBWF9FRFhfREVD
TEFSRV9BUkdTKHZhbCwgbG93LCBoaWdoKTsNCj4+PiArDQo+Pj4gK8KgwqDCoCBQVk9QX1RF
U1RfTlVMTChjcHUucmVhZF9tc3Jfc2FmZSk7DQo+Pj4gK8KgwqDCoCBhc20gdm9sYXRpbGUo
IjE6ICJBTFRFUk5BVElWRV8yKFBBUkFWSVJUX0NBTEwsDQo+Pj4gK8KgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJyZG1zcjsgeG9yICVbZXJyXSwlW2Vycl0iLCBB
TFRfTk9UX1hFTiwNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgQUxUX0NBTExfSU5TVFIsIEFMVF9YRU5QVl9DQUxMKQ0KPj4+ICvCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgIjI6XG4iDQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBfQVNN
X0VYVEFCTEVfVFlQRV9SRUcoMWIsIDJiLCBFWF9UWVBFX1JETVNSX1NBRkUsICVbZXJyXSkN
Cj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogW2Vycl0gIj1jIiAoZXJyKSwgRUFY
X0VEWF9SRVQodmFsLCBsb3csIGhpZ2gpLA0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIEFTTV9DQUxMX0NPTlNUUkFJTlQNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIDogcGFyYXZpcnRfcHRyKGNwdS5yZWFkX21zcl9zYWZlKSwgIjAiIChtc3IpKTsNCj4+
PiArDQo+Pj4gK8KgwqDCoCAqcCA9IEVBWF9FRFhfVkFMKHZhbCwgbG93LCBoaWdoKTsNCj4+
PiArDQo+Pj4gK8KgwqDCoCByZXR1cm4gZXJyOw0KPj4+IMKgIH0NCj4+PiAtc3RhdGljIGlu
bGluZSBpbnQgcGFyYXZpcnRfd3JpdGVfbXNyX3NhZmUodTMyIG1zciwgdTY0IHZhbCkNCj4+
PiArc3RhdGljIF9fYWx3YXlzX2lubGluZSBpbnQgcGFyYXZpcnRfd3JpdGVfbXNyX3NhZmUo
dTMyIG1zciwgdTY0IHZhbCkNCj4+PiDCoCB7DQo+Pj4gLcKgwqDCoCByZXR1cm4gUFZPUF9D
QUxMMihpbnQsIGNwdS53cml0ZV9tc3Jfc2FmZSwgbXNyLCB2YWwpOw0KPj4+ICvCoMKgwqAg
aW50IGVycjsNCj4+PiArDQo+Pj4gK8KgwqDCoCBQVk9QX1RFU1RfTlVMTChjcHUud3JpdGVf
bXNyX3NhZmUpOw0KPj4+ICvCoMKgwqAgYXNtIHZvbGF0aWxlKCIxOiAiQUxURVJOQVRJVkVf
MihQQVJBVklSVF9DQUxMLA0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCAid3Jtc3I7IHhvciAlW2Vycl0sJVtlcnJdIiwgQUxUX05PVF9YRU4sDQo+Pj4g
K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEFMVF9DQUxMX0lOU1RS
LCBBTFRfWEVOUFZfQ0FMTCkNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICIyOlxu
Ig0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgX0FTTV9FWFRBQkxFX1RZUEVfUkVH
KDFiLCAyYiwgRVhfVFlQRV9XUk1TUl9TQUZFLCAlW2Vycl0pDQo+Pj4gK8KgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCA6IFtlcnJdICI9YSIgKGVyciksIEFTTV9DQUxMX0NPTlNUUkFJTlQN
Cj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogcGFyYXZpcnRfcHRyKGNwdS53cml0
ZV9tc3Jfc2FmZSksDQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgImMiICht
c3IpLCAiMCIgKCh1MzIpdmFsKSwgImQiICgodTMyKSh2YWwgPj4gMzIpKQ0KPj4+ICvCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqAgOiAibWVtb3J5Iik7DQo+Pj4gKw0KPj4+ICvCoMKgwqAg
cmV0dXJuIGVycjsNCj4+PiDCoCB9DQo+Pj4gwqAgc3RhdGljIF9fYWx3YXlzX2lubGluZSB1
NjQgcmVhZF9tc3IodTMyIG1zcikNCj4+PiBAQCAtNTczLDI3ICs2MjEsNDMgQEAgYm9vbCBf
X3Jhd19jYWxsZWVfc2F2ZV9fX25hdGl2ZV92Y3B1X2lzX3ByZWVtcHRlZChsb25nIA0KPj4+
IGNwdSk7DQo+Pj4gwqAgI2RlZmluZSBQVl9TQVZFX0FMTF9DQUxMRVJfUkVHU8KgwqDCoMKg
wqDCoMKgICJwdXNobCAlZWN4OyINCj4+PiDCoCAjZGVmaW5lIFBWX1JFU1RPUkVfQUxMX0NB
TExFUl9SRUdTwqDCoMKgICJwb3BswqAgJWVjeDsiDQo+Pj4gwqAgI2Vsc2UNCj4+PiArLyog
c2F2ZSBhbmQgcmVzdG9yZSBjYWxsZXItc2F2ZSByZWdpc3RlcnMsIGV4Y2VwdCAlcmF4LCAl
cmN4IGFuZCAlcmR4LiAqLw0KPj4+ICsjZGVmaW5lIFBWX1NBVkVfQ09NTU9OX0NBTExFUl9S
RUdTwqDCoMKgIFwNCj4+PiArwqDCoMKgICJwdXNoICVyc2k7IsKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgXA0KPj4+ICvCoMKgwqAgInB1c2ggJXJkaTsiwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCBcDQo+Pj4gK8KgwqDCoCAicHVzaCAlcjg7IsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0K
Pj4+ICvCoMKgwqAgInB1c2ggJXI5OyLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+PiAr
wqDCoMKgICJwdXNoICVyMTA7IsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+ICvCoMKg
wqAgInB1c2ggJXIxMTsiDQo+Pg0KPj4gQWRkIGFuIGVtcHR5IGxpbmUgcGxlYXNlLCBlYXNp
ZXIgdG8gcmVhZC4NCj4gDQo+IE9rYXkgKHNhbWUgYmVsb3cpLg0KPiANCj4+DQo+Pj4gKyNk
ZWZpbmUgUFZfUkVTVE9SRV9DT01NT05fQ0FMTEVSX1JFR1PCoMKgwqAgXA0KPj4+ICvCoMKg
wqAgInBvcCAlcjExOyLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+PiArwqDCoMKgICJw
b3AgJXIxMDsiwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+Pj4gK8KgwqDCoCAicG9wICVy
OTsiwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+Pj4gK8KgwqDCoCAicG9wICVyODsiwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+Pj4gK8KgwqDCoCAicG9wICVyZGk7IsKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgXA0KPj4+ICvCoMKgwqAgInBvcCAlcnNpOyINCj4+PiArDQo+Pj4g
KyNkZWZpbmUgUFZfUFJPTE9HVUVfTVNSKGZ1bmMpwqDCoMKgwqDCoMKgwqAgXA0KPj4+ICvC
oMKgwqAgUFZfU0FWRV9DT01NT05fQ0FMTEVSX1JFR1PCoMKgwqAgXA0KPj4+ICvCoMKgwqAg
UFZfUFJPTE9HVUVfTVNSXyMjZnVuYw0KPj4NCj4+IERpdHRvLsKgIEFuZCB0aGUgZm9sbG93
aW5nIHNpbWlsYXIgY2FzZXMuDQo+Pg0KPj4+ICsjZGVmaW5lIFBWX0VQSUxPR1VFX01TUihm
dW5jKcKgwqDCoMKgwqDCoMKgIFwNCj4+PiArwqDCoMKgIFBWX0VQSUxPR1VFX01TUl8jI2Z1
bmPCoMKgwqDCoMKgwqDCoCBcDQo+Pj4gK8KgwqDCoCBQVl9SRVNUT1JFX0NPTU1PTl9DQUxM
RVJfUkVHUw0KPj4+ICsNCj4+PiDCoCAvKiBzYXZlIGFuZCByZXN0b3JlIGFsbCBjYWxsZXIt
c2F2ZSByZWdpc3RlcnMsIGV4Y2VwdCByZXR1cm4gdmFsdWUgKi8NCj4+PiDCoCAjZGVmaW5l
IFBWX1NBVkVfQUxMX0NBTExFUl9SRUdTwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCBcDQo+Pj4gwqDCoMKgwqDCoCAicHVzaCAlcmN4OyLCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+
IMKgwqDCoMKgwqAgInB1c2ggJXJkeDsiwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+PiAtwqDCoMKgICJwdXNoICVyc2k7IsKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBc
DQo+Pj4gLcKgwqDCoCAicHVzaCAlcmRpOyLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+IC3CoMKgwqAgInB1c2ggJXI4OyLC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
XA0KPj4+IC3CoMKgwqAgInB1c2ggJXI5OyLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+IC3CoMKgwqAgInB1c2ggJXIxMDsi
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IFwNCj4+PiAtwqDCoMKgICJwdXNoICVyMTE7Ig0KPj4+ICvCoMKgwqAgUFZfU0FWRV9DT01N
T05fQ0FMTEVSX1JFR1MNCj4+PiDCoCAjZGVmaW5lIFBWX1JFU1RPUkVfQUxMX0NBTExFUl9S
RUdTwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+IC3CoMKg
wqAgInBvcCAlcjExOyLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgXA0KPj4+IC3CoMKgwqAgInBvcCAlcjEwOyLCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+IC3CoMKg
wqAgInBvcCAlcjk7IsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCBcDQo+Pj4gLcKgwqDCoCAicG9wICVyODsiwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+PiAtwqDCoMKg
ICJwb3AgJXJkaTsiwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIFwNCj4+PiAtwqDCoMKgICJwb3AgJXJzaTsiwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+PiArwqDCoMKg
IFBWX1JFU1RPUkVfQ09NTU9OX0NBTExFUl9SRUdTwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgXA0KPj4+IMKgwqDCoMKgwqAgInBvcCAlcmR4OyLCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+IMKg
wqDCoMKgwqAgInBvcCAlcmN4OyINCj4+PiDCoCAjZW5kaWYNCj4+PiArI2RlZmluZSBQVl9Q
Uk9MT0dVRV9BTEwoZnVuYynCoMKgwqAgUFZfU0FWRV9BTExfQ0FMTEVSX1JFR1MNCj4+PiAr
I2RlZmluZSBQVl9FUElMT0dVRV9BTEwoZnVuYynCoMKgwqAgUFZfUkVTVE9SRV9BTExfQ0FM
TEVSX1JFR1MNCj4+PiArDQo+Pj4gwqAgLyoNCj4+PiDCoMKgICogR2VuZXJhdGUgYSB0aHVu
ayBhcm91bmQgYSBmdW5jdGlvbiB3aGljaCBzYXZlcyBhbGwgY2FsbGVyLXNhdmUNCj4+PiDC
oMKgICogcmVnaXN0ZXJzIGV4Y2VwdCBmb3IgdGhlIHJldHVybiB2YWx1ZS7CoCBUaGlzIGFs
bG93cyBDIGZ1bmN0aW9ucyB0bw0KPj4+IEBAIC02MDcsNyArNjcxLDcgQEAgYm9vbCBfX3Jh
d19jYWxsZWVfc2F2ZV9fX25hdGl2ZV92Y3B1X2lzX3ByZWVtcHRlZChsb25nIGNwdSk7DQo+
Pj4gwqDCoCAqIGZ1bmN0aW9ucy4NCj4+PiDCoMKgICovDQo+Pj4gwqAgI2RlZmluZSBQVl9U
SFVOS19OQU1FKGZ1bmMpICJfX3Jhd19jYWxsZWVfc2F2ZV8iICNmdW5jDQo+Pj4gLSNkZWZp
bmUgX19QVl9DQUxMRUVfU0FWRV9SRUdTX1RIVU5LKGZ1bmMsIHNlY3Rpb24pwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCBcDQo+Pj4gKyNkZWZpbmUgX19QVl9DQUxMRUVfU0FWRV9SRUdTX1RI
VU5LKGZ1bmMsIHNlY3Rpb24sIGhlbHBlcinCoMKgwqDCoMKgwqDCoCBcDQo+Pj4gwqDCoMKg
wqDCoCBleHRlcm4gdHlwZW9mKGZ1bmMpIF9fcmF3X2NhbGxlZV9zYXZlXyMjZnVuYzvCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+Pj4g
wqDCoMKgwqDCoCBhc20oIi5wdXNoc2VjdGlvbiAiIHNlY3Rpb24gIiwgXCJheFwiOyLCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+IEBAIC02MTcsMTYgKzY4MSwxOCBA
QCBib29sIF9fcmF3X2NhbGxlZV9zYXZlX19fbmF0aXZlX3ZjcHVfaXNfcHJlZW1wdGVkKGxv
bmcgDQo+Pj4gY3B1KTsNCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqAgUFZfVEhVTktfTkFNRShm
dW5jKSAiOiLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+Pj4g
wqDCoMKgwqDCoMKgwqDCoMKgIEFTTV9FTkRCUsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKg
IEZSQU1FX0JFR0lOwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIFwNCj4+PiAtwqDCoMKgwqDCoMKgwqAgUFZfU0FWRV9BTExfQ0FMTEVS
X1JFR1PCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+Pj4gK8Kg
wqDCoMKgwqDCoMKgIFBWX1BST0xPR1VFXyMjaGVscGVyKGZ1bmMpwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+IMKgwqDCoMKgwqDCoMKgwqDCoCAiY2Fs
bCAiICNmdW5jICI7IsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgXA0KPj4+IC3CoMKgwqDCoMKgwqDCoCBQVl9SRVNUT1JFX0FMTF9DQUxMRVJfUkVH
U8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFwNCj4+PiArwqDCoMKg
wqDCoMKgwqAgUFZfRVBJTE9HVUVfIyNoZWxwZXIoZnVuYynCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIEZSQU1FX0VO
RMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCBcDQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIEFTTV9SRVTCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+IMKgwqDCoMKgwqDC
oMKgwqDCoCAiLnNpemUgIiBQVl9USFVOS19OQU1FKGZ1bmMpICIsIC4tIiBQVl9USFVOS19O
QU1FKGZ1bmMpICI7IsKgwqDCoCBcDQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgICIucG9wc2Vj
dGlvbiIpDQo+Pj4gwqAgI2RlZmluZSBQVl9DQUxMRUVfU0FWRV9SRUdTX1RIVU5LKGZ1bmMp
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBcDQo+Pj4gLcKgwqDCoCBfX1BWX0NBTExFRV9TQVZF
X1JFR1NfVEhVTksoZnVuYywgIi50ZXh0IikNCj4+PiArwqDCoMKgIF9fUFZfQ0FMTEVFX1NB
VkVfUkVHU19USFVOSyhmdW5jLCAiLnRleHQiLCBBTEwpDQo+Pj4gKyNkZWZpbmUgUFZfQ0FM
TEVFX1NBVkVfUkVHU19NU1JfVEhVTksoZnVuYynCoMKgwqDCoMKgwqDCoCBcDQo+Pj4gK8Kg
wqDCoCBfX1BWX0NBTExFRV9TQVZFX1JFR1NfVEhVTksoZnVuYywgIi50ZXh0IiwgTVNSKQ0K
Pj4+IMKgIC8qIEdldCBhIHJlZmVyZW5jZSB0byBhIGNhbGxlZS1zYXZlIGZ1bmN0aW9uICov
DQo+Pj4gwqAgI2RlZmluZSBQVl9DQUxMRUVfU0FWRShmdW5jKcKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXA0KPj4+IGRpZmYgLS1naXQgYS9hcmNo
L3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydF90eXBlcy5oIGIvYXJjaC94ODYvaW5jbHVkZS9h
c20vIA0KPj4+IHBhcmF2aXJ0X3R5cGVzLmgNCj4+PiBpbmRleCBiMDhiOWQzMTIyZDYuLmY3
Zjg3OTMxOWU5MCAxMDA2NDQNCj4+PiAtLS0gYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wYXJh
dmlydF90eXBlcy5oDQo+Pj4gKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnRf
dHlwZXMuaA0KPj4+IEBAIC05MSwxNSArOTEsMTUgQEAgc3RydWN0IHB2X2NwdV9vcHMgew0K
Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQgKmVjeCwg
dW5zaWduZWQgaW50ICplZHgpOw0KPj4+IMKgwqDCoMKgwqAgLyogVW5zYWZlIE1TUiBvcGVy
YXRpb25zLsKgIFRoZXNlIHdpbGwgd2FybiBvciBwYW5pYyBvbiBmYWlsdXJlLiAqLw0KPj4+
IC3CoMKgwqAgdTY0ICgqcmVhZF9tc3IpKHUzMiBtc3IpOw0KPj4+IC3CoMKgwqAgdm9pZCAo
KndyaXRlX21zcikodTMyIG1zciwgdTY0IHZhbCk7DQo+Pj4gK8KgwqDCoCBzdHJ1Y3QgcGFy
YXZpcnRfY2FsbGVlX3NhdmUgcmVhZF9tc3I7DQo+Pj4gK8KgwqDCoCBzdHJ1Y3QgcGFyYXZp
cnRfY2FsbGVlX3NhdmUgd3JpdGVfbXNyOw0KPj4+IMKgwqDCoMKgwqAgLyoNCj4+PiDCoMKg
wqDCoMKgwqAgKiBTYWZlIE1TUiBvcGVyYXRpb25zLg0KPj4+IMKgwqDCoMKgwqDCoCAqIFJl
dHVybnMgMCBvciAtRUlPLg0KPj4+IMKgwqDCoMKgwqDCoCAqLw0KPj4+IC3CoMKgwqAgaW50
ICgqcmVhZF9tc3Jfc2FmZSkodTMyIG1zciwgdTY0ICp2YWwpOw0KPj4+IC3CoMKgwqAgaW50
ICgqd3JpdGVfbXNyX3NhZmUpKHUzMiBtc3IsIHU2NCB2YWwpOw0KPj4+ICvCoMKgwqAgc3Ry
dWN0IHBhcmF2aXJ0X2NhbGxlZV9zYXZlIHJlYWRfbXNyX3NhZmU7DQo+Pj4gK8KgwqDCoCBz
dHJ1Y3QgcGFyYXZpcnRfY2FsbGVlX3NhdmUgd3JpdGVfbXNyX3NhZmU7DQo+Pj4gwqDCoMKg
wqDCoCB1NjQgKCpyZWFkX3BtYykoaW50IGNvdW50ZXIpOw0KPj4+IEBAIC01MjAsNiArNTIw
LDEwIEBAIHVuc2lnbmVkIGxvbmcgcHZfbmF0aXZlX3NhdmVfZmwodm9pZCk7DQo+Pj4gwqAg
dm9pZCBwdl9uYXRpdmVfaXJxX2Rpc2FibGUodm9pZCk7DQo+Pj4gwqAgdm9pZCBwdl9uYXRp
dmVfaXJxX2VuYWJsZSh2b2lkKTsNCj4+PiDCoCB1bnNpZ25lZCBsb25nIHB2X25hdGl2ZV9y
ZWFkX2NyMih2b2lkKTsNCj4+PiArdm9pZCBwdl9uYXRpdmVfcmRtc3Iodm9pZCk7DQo+Pj4g
K3ZvaWQgcHZfbmF0aXZlX3dybXNyKHZvaWQpOw0KPj4+ICt2b2lkIHB2X25hdGl2ZV9yZG1z
cl9zYWZlKHZvaWQpOw0KPj4+ICt2b2lkIHB2X25hdGl2ZV93cm1zcl9zYWZlKHZvaWQpOw0K
Pj4+IMKgICNlbmRpZg0KPj4+IMKgICNkZWZpbmUgcGFyYXZpcnRfbm9wwqDCoMKgICgodm9p
ZCAqKW5vcF9mdW5jKQ0KPj4+IEBAIC01MjcsNiArNTMxLDcgQEAgdW5zaWduZWQgbG9uZyBw
dl9uYXRpdmVfcmVhZF9jcjIodm9pZCk7DQo+Pj4gwqAgI2VuZGlmwqDCoMKgIC8qIF9fQVNT
RU1CTEVSX18gKi8NCj4+PiDCoCAjZGVmaW5lIEFMVF9OT1RfWEVOwqDCoMKgIEFMVF9OT1Qo
WDg2X0ZFQVRVUkVfWEVOUFYpDQo+Pj4gKyNkZWZpbmUgQUxUX1hFTlBWX0NBTEzCoMKgwqAg
QUxUX0RJUkVDVF9DQUxMKFg4Nl9GRUFUVVJFX1hFTlBWKQ0KPj4+IMKgICNlbmRpZsKgIC8q
IENPTkZJR19QQVJBVklSVCAqLw0KPj4+IMKgICNlbmRpZsKgwqDCoCAvKiBfQVNNX1g4Nl9Q
QVJBVklSVF9UWVBFU19IICovDQo+Pj4gZGlmZiAtLWdpdCBhL2FyY2gveDg2L2luY2x1ZGUv
YXNtL3FzcGlubG9ja19wYXJhdmlydC5oIGIvYXJjaC94ODYvaW5jbHVkZS8gDQo+Pj4gYXNt
LyBxc3BpbmxvY2tfcGFyYXZpcnQuaA0KPj4+IGluZGV4IDBhOTg1Nzg0YmU5Yi4uMDM1MWFj
YjVhMTQzIDEwMDY0NA0KPj4+IC0tLSBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3FzcGlubG9j
a19wYXJhdmlydC5oDQo+Pj4gKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vcXNwaW5sb2Nr
X3BhcmF2aXJ0LmgNCj4+PiBAQCAtMTQsNyArMTQsOCBAQCB2b2lkIF9fbG9ja2Z1bmMgX19w
dl9xdWV1ZWRfc3Bpbl91bmxvY2tfc2xvd3BhdGgoc3RydWN0IA0KPj4+IHFzcGlubG9jayAq
bG9jaywgdTggbG9jaw0KPj4+IMKgwqAgKi8NCj4+PiDCoCAjaWZkZWYgQ09ORklHXzY0QklU
DQo+Pj4gLV9fUFZfQ0FMTEVFX1NBVkVfUkVHU19USFVOSyhfX3B2X3F1ZXVlZF9zcGluX3Vu
bG9ja19zbG93cGF0aCwgDQo+Pj4gIi5zcGlubG9jay50ZXh0Iik7DQo+Pj4gK19fUFZfQ0FM
TEVFX1NBVkVfUkVHU19USFVOSyhfX3B2X3F1ZXVlZF9zcGluX3VubG9ja19zbG93cGF0aCwg
Ii5zcGlubG9jay50ZXh0IiwNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IEFMTCk7DQo+Pj4gwqAgI2RlZmluZSBfX3B2X3F1ZXVlZF9zcGluX3VubG9ja8KgwqDCoCBf
X3B2X3F1ZXVlZF9zcGluX3VubG9jaw0KPj4+IMKgIC8qDQo+Pj4gQEAgLTYxLDcgKzYyLDcg
QEAgREVGSU5FX0FTTV9GVU5DKF9fcmF3X2NhbGxlZV9zYXZlX19fcHZfcXVldWVkX3NwaW5f
dW5sb2NrLA0KPj4+IMKgICNlbHNlIC8qIENPTkZJR182NEJJVCAqLw0KPj4+IMKgIGV4dGVy
biB2b2lkIF9fbG9ja2Z1bmMgX19wdl9xdWV1ZWRfc3Bpbl91bmxvY2soc3RydWN0IHFzcGlu
bG9jayAqbG9jayk7DQo+Pj4gLV9fUFZfQ0FMTEVFX1NBVkVfUkVHU19USFVOSyhfX3B2X3F1
ZXVlZF9zcGluX3VubG9jaywgIi5zcGlubG9jay50ZXh0Iik7DQo+Pj4gK19fUFZfQ0FMTEVF
X1NBVkVfUkVHU19USFVOSyhfX3B2X3F1ZXVlZF9zcGluX3VubG9jaywgIi5zcGlubG9jay50
ZXh0IiwgQUxMKTsNCj4+PiDCoCAjZW5kaWYgLyogQ09ORklHXzY0QklUICovDQo+Pj4gwqAg
I2VuZGlmDQo+Pj4gZGlmZiAtLWdpdCBhL2FyY2gveDg2L2tlcm5lbC9wYXJhdmlydC5jIGIv
YXJjaC94ODYva2VybmVsL3BhcmF2aXJ0LmMNCj4+PiBpbmRleCAwMTViZjI5ODQzNGYuLmZm
N2Q3ZmRhZTM2MCAxMDA2NDQNCj4+PiAtLS0gYS9hcmNoL3g4Ni9rZXJuZWwvcGFyYXZpcnQu
Yw0KPj4+ICsrKyBiL2FyY2gveDg2L2tlcm5lbC9wYXJhdmlydC5jDQo+Pj4gQEAgLTUwLDYg
KzUwLDI0IEBAIERFRklORV9BU01fRlVOQyhwdl9uYXRpdmVfc2F2ZV9mbCwgInB1c2hmOyBw
b3AgDQo+Pj4gJXJheCIsIC5ub2luc3RyLnRleHQpOw0KPj4+IMKgIERFRklORV9BU01fRlVO
Qyhwdl9uYXRpdmVfaXJxX2Rpc2FibGUsICJjbGkiLCAubm9pbnN0ci50ZXh0KTsNCj4+PiDC
oCBERUZJTkVfQVNNX0ZVTkMocHZfbmF0aXZlX2lycV9lbmFibGUsICJzdGkiLCAubm9pbnN0
ci50ZXh0KTsNCj4+PiDCoCBERUZJTkVfQVNNX0ZVTkMocHZfbmF0aXZlX3JlYWRfY3IyLCAi
bW92ICVjcjIsICVyYXgiLCAubm9pbnN0ci50ZXh0KTsNCj4+PiArREVGSU5FX0FTTV9GVU5D
KHB2X25hdGl2ZV9yZG1zciwNCj4+PiArwqDCoMKgwqDCoMKgwqAgIjE6IHJkbXNyXG4iDQo+
Pj4gK8KgwqDCoMKgwqDCoMKgICIyOlxuIg0KPj4+ICvCoMKgwqDCoMKgwqDCoCBfQVNNX0VY
VEFCTEVfVFlQRSgxYiwgMmIsIEVYX1RZUEVfUkRNU1IpLCAubm9pbnN0ci50ZXh0KTsNCj4+
PiArREVGSU5FX0FTTV9GVU5DKHB2X25hdGl2ZV93cm1zciwNCj4+PiArwqDCoMKgwqDCoMKg
wqAgIjE6IHdybXNyXG4iDQo+Pj4gK8KgwqDCoMKgwqDCoMKgICIyOlxuIg0KPj4+ICvCoMKg
wqDCoMKgwqDCoCBfQVNNX0VYVEFCTEVfVFlQRSgxYiwgMmIsIEVYX1RZUEVfV1JNU1IpLCAu
bm9pbnN0ci50ZXh0KTsNCj4+PiArREVGSU5FX0FTTV9GVU5DKHB2X25hdGl2ZV9yZG1zcl9z
YWZlLA0KPj4+ICvCoMKgwqDCoMKgwqDCoCAiMTogcmRtc3I7IHhvciAlZWN4LCAlZWN4XG4i
DQo+Pj4gK8KgwqDCoMKgwqDCoMKgICIyOlxuIg0KPj4+ICvCoMKgwqDCoMKgwqDCoCBfQVNN
X0VYVEFCTEVfVFlQRV9SRUcoMWIsIDJiLCBFWF9UWVBFX1JETVNSX1NBRkUsICUlZWN4KSwN
Cj4+PiArwqDCoMKgwqDCoMKgwqAgLm5vaW5zdHIudGV4dCk7DQo+Pj4gK0RFRklORV9BU01f
RlVOQyhwdl9uYXRpdmVfd3Jtc3Jfc2FmZSwNCj4+PiArwqDCoMKgwqDCoMKgwqAgIjE6IHdy
bXNyOyB4b3IgJWVheCwgJWVheFxuIg0KPj4+ICvCoMKgwqDCoMKgwqDCoCAiMjpcbiINCj4+
PiArwqDCoMKgwqDCoMKgwqAgX0FTTV9FWFRBQkxFX1RZUEVfUkVHKDFiLCAyYiwgRVhfVFlQ
RV9XUk1TUl9TQUZFLCAlJWVheCksDQo+Pj4gK8KgwqDCoMKgwqDCoMKgIC5ub2luc3RyLnRl
eHQpOw0KPj4+IMKgICNlbmRpZg0KPj4+IMKgIERFRklORV9TVEFUSUNfS0VZX0ZBTFNFKHZp
cnRfc3Bpbl9sb2NrX2tleSk7DQo+Pj4gQEAgLTEyOSwxMCArMTQ3LDEwIEBAIHN0cnVjdCBw
YXJhdmlydF9wYXRjaF90ZW1wbGF0ZSBwdl9vcHMgPSB7DQo+Pj4gwqDCoMKgwqDCoCAuY3B1
LnJlYWRfY3IwwqDCoMKgwqDCoMKgwqAgPSBuYXRpdmVfcmVhZF9jcjAsDQo+Pj4gwqDCoMKg
wqDCoCAuY3B1LndyaXRlX2NyMMKgwqDCoMKgwqDCoMKgID0gbmF0aXZlX3dyaXRlX2NyMCwN
Cj4+PiDCoMKgwqDCoMKgIC5jcHUud3JpdGVfY3I0wqDCoMKgwqDCoMKgwqAgPSBuYXRpdmVf
d3JpdGVfY3I0LA0KPj4+IC3CoMKgwqAgLmNwdS5yZWFkX21zcsKgwqDCoMKgwqDCoMKgID0g
bmF0aXZlX3JlYWRfbXNyLA0KPj4+IC3CoMKgwqAgLmNwdS53cml0ZV9tc3LCoMKgwqDCoMKg
wqDCoCA9IG5hdGl2ZV93cml0ZV9tc3IsDQo+Pj4gLcKgwqDCoCAuY3B1LnJlYWRfbXNyX3Nh
ZmXCoMKgwqAgPSBuYXRpdmVfcmVhZF9tc3Jfc2FmZSwNCj4+PiAtwqDCoMKgIC5jcHUud3Jp
dGVfbXNyX3NhZmXCoMKgwqAgPSBuYXRpdmVfd3JpdGVfbXNyX3NhZmUsDQo+Pj4gK8KgwqDC
oCAuY3B1LnJlYWRfbXNywqDCoMKgwqDCoMKgwqAgPSBfX1BWX0lTX0NBTExFRV9TQVZFKHB2
X25hdGl2ZV9yZG1zciksDQo+Pj4gK8KgwqDCoCAuY3B1LndyaXRlX21zcsKgwqDCoMKgwqDC
oMKgID0gX19QVl9JU19DQUxMRUVfU0FWRShwdl9uYXRpdmVfd3Jtc3IpLA0KPj4+ICvCoMKg
wqAgLmNwdS5yZWFkX21zcl9zYWZlwqDCoMKgID0gX19QVl9JU19DQUxMRUVfU0FWRShwdl9u
YXRpdmVfcmRtc3Jfc2FmZSksDQo+Pj4gK8KgwqDCoCAuY3B1LndyaXRlX21zcl9zYWZlwqDC
oMKgID0gX19QVl9JU19DQUxMRUVfU0FWRShwdl9uYXRpdmVfd3Jtc3Jfc2FmZSksDQo+Pj4g
wqDCoMKgwqDCoCAuY3B1LnJlYWRfcG1jwqDCoMKgwqDCoMKgwqAgPSBuYXRpdmVfcmVhZF9w
bWMsDQo+Pj4gwqDCoMKgwqDCoCAuY3B1LmxvYWRfdHJfZGVzY8KgwqDCoCA9IG5hdGl2ZV9s
b2FkX3RyX2Rlc2MsDQo+Pj4gwqDCoMKgwqDCoCAuY3B1LnNldF9sZHTCoMKgwqDCoMKgwqDC
oCA9IG5hdGl2ZV9zZXRfbGR0LA0KPj4+IGRpZmYgLS1naXQgYS9hcmNoL3g4Ni94ZW4vZW5s
aWdodGVuX3B2LmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuX3B2LmMNCj4+PiBpbmRleCAz
YmUzODM1MGYwNDQuLmMyNzliMmJlZjdlYiAxMDA2NDQNCj4+PiAtLS0gYS9hcmNoL3g4Ni94
ZW4vZW5saWdodGVuX3B2LmMNCj4+PiArKysgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuX3B2
LmMNCj4+PiBAQCAtMTE2MCwzNiArMTE2MCw2NiBAQCBzdGF0aWMgdm9pZCB4ZW5fZG9fd3Jp
dGVfbXNyKHUzMiBtc3IsIHU2NCB2YWwsIGludCAqZXJyKQ0KPj4+IMKgwqDCoMKgwqAgfQ0K
Pj4+IMKgIH0NCj4+PiAtc3RhdGljIGludCB4ZW5fcmVhZF9tc3Jfc2FmZSh1MzIgbXNyLCB1
NjQgKnZhbCkNCj4+PiAtew0KPj4+ICsvKg0KPj4+ICsgKiBQcm90b3R5cGVzIGZvciBmdW5j
dGlvbnMgY2FsbGVkIHZpYSBQVl9DQUxMRUVfU0FWRV9SRUdTX1RIVU5LKCkgaW4gb3JkZXIN
Cj4+PiArICogdG8gYXZvaWQgd2FybmluZ3Mgd2l0aCAiLVdtaXNzaW5nLXByb3RvdHlwZXMi
Lg0KPj4+ICsgKi8NCj4+PiArc3RydWN0IHhlbl9yZG1zcl9zYWZlX3JldCB7DQo+Pj4gK8Kg
wqDCoCB1NjQgdmFsOw0KPj4+IMKgwqDCoMKgwqAgaW50IGVycjsNCj4+PiArfTsNCj4+PiAr
c3RydWN0IHhlbl9yZG1zcl9zYWZlX3JldCB4ZW5fcmVhZF9tc3Jfc2FmZSh1MzIgbXNyKTsN
Cj4+PiAraW50IHhlbl93cml0ZV9tc3Jfc2FmZSh1MzIgbXNyLCB1MzIgbG93LCB1MzIgaGln
aCk7DQo+Pj4gK3U2NCB4ZW5fcmVhZF9tc3IodTMyIG1zcik7DQo+Pj4gK3ZvaWQgeGVuX3dy
aXRlX21zcih1MzIgbXNyLCB1MzIgbG93LCB1MzIgaGlnaCk7DQo+Pj4gLcKgwqDCoCAqdmFs
ID0geGVuX2RvX3JlYWRfbXNyKG1zciwgJmVycik7DQo+Pj4gLcKgwqDCoCByZXR1cm4gZXJy
Ow0KPj4+ICtfX3Zpc2libGUgc3RydWN0IHhlbl9yZG1zcl9zYWZlX3JldCB4ZW5fcmVhZF9t
c3Jfc2FmZSh1MzIgbXNyKQ0KPj4+ICt7DQo+Pj4gK8KgwqDCoCBzdHJ1Y3QgeGVuX3JkbXNy
X3NhZmVfcmV0IHJldDsNCj4+DQo+PiBzdHJ1Y3QgeGVuX3JkbXNyX3NhZmVfcmV0IHJldCA9
IHsgMCwgMCB9Ow0KPj4NCj4+IEJlY2F1c2UgdGhlICdlcnInIG1lbWJlciBtYXkgbm90IGJl
IHNldCBpbiB4ZW5fZG9fcmVhZF9tc3IoKS4NCj4gDQo+IFJpZ2h0Lg0KPiANCj4+DQo+Pj4g
Kw0KPj4+ICvCoMKgwqAgcmV0LnZhbCA9IHhlbl9kb19yZWFkX21zcihtc3IsICZyZXQuZXJy
KTsNCj4+PiArwqDCoMKgIHJldHVybiByZXQ7DQo+Pj4gwqAgfQ0KPj4+ICsjZGVmaW5lIFBW
X1BST0xPR1VFX01TUl94ZW5fcmVhZF9tc3Jfc2FmZcKgwqDCoCAibW92ICVlY3gsICVlZGk7
Ig0KPj4+ICsjZGVmaW5lIFBWX0VQSUxPR1VFX01TUl94ZW5fcmVhZF9tc3Jfc2FmZcKgwqDC
oCBcDQo+Pj4gK8KgwqDCoCAibW92ICVlZHgsICVlY3g7IG1vdiAlcmF4LCAlcmR4OyBtb3Yg
JWVheCwgJWVheDsgc2hyICQweDIwLCAlcmR4OyINCj4+PiArUFZfQ0FMTEVFX1NBVkVfUkVH
U19NU1JfVEhVTksoeGVuX3JlYWRfbXNyX3NhZmUpOw0KPj4+IC1zdGF0aWMgaW50IHhlbl93
cml0ZV9tc3Jfc2FmZSh1MzIgbXNyLCB1NjQgdmFsKQ0KPj4+ICtfX3Zpc2libGUgaW50IHhl
bl93cml0ZV9tc3Jfc2FmZSh1MzIgbXNyLCB1MzIgbG93LCB1MzIgaGlnaCkNCj4+DQo+PiBJ
IHRoaW5rIHdlIGNhbiBhdm9pZCBzcGxpdHRpbmcgdGhpcyB1NjQgaW50byB0d28gdTMyLg0K
PiANCj4gVGhpcyBpcyByZWxhdGVkIHRvIHRoZSBuYXRpdmUgV1JNU1IgaW50ZXJmYWNlLiBU
aGUgV1JNU1IgbmVlZHMgdG8gYmUNCj4gYWJsZSB0byBiZSByZXBsYWNlZCBieSB0aGUgY2Fs
bCBvZiB0aGUgWGVuIHNwZWNpZmljIGZ1bmN0aW9uLg0KPiANCj4gSSBjb3VsZCBoYW5kbGUg
dGhpcyBpbiB0aGUgcHJvbG9ndWUgaGVscGVycywgYnV0IEknZCBwcmVmZXIgdG8ga2VlcA0K
PiB0aG9zZSBoZWxwZXJzIGFzIHNtYWxsIGFzIHBvc3NpYmxlLg0KPiANCj4+DQo+Pj4gwqAg
ew0KPj4+IMKgwqDCoMKgwqAgaW50IGVyciA9IDA7DQo+Pj4gLcKgwqDCoCB4ZW5fZG9fd3Jp
dGVfbXNyKG1zciwgdmFsLCAmZXJyKTsNCj4+PiArwqDCoMKgIHhlbl9kb193cml0ZV9tc3Io
bXNyLCAodTY0KWhpZ2ggPDwgMzIgfCBsb3csICZlcnIpOw0KPj4+IMKgwqDCoMKgwqAgcmV0
dXJuIGVycjsNCj4+PiDCoCB9DQo+Pj4gKyNkZWZpbmUgUFZfUFJPTE9HVUVfTVNSX3hlbl93
cml0ZV9tc3Jfc2FmZcKgwqDCoCBcDQo+Pj4gK8KgwqDCoCAibW92ICVlY3gsICVlZGk7IG1v
diAlZWF4LCAlZXNpOyINCj4+PiArI2RlZmluZSBQVl9FUElMT0dVRV9NU1JfeGVuX3dyaXRl
X21zcl9zYWZlDQo+Pj4gK1BWX0NBTExFRV9TQVZFX1JFR1NfTVNSX1RIVU5LKHhlbl93cml0
ZV9tc3Jfc2FmZSk7DQo+Pj4gLXN0YXRpYyB1NjQgeGVuX3JlYWRfbXNyKHUzMiBtc3IpDQo+
Pj4gK19fdmlzaWJsZSB1NjQgeGVuX3JlYWRfbXNyKHUzMiBtc3IpDQo+Pj4gwqAgew0KPj4+
IMKgwqDCoMKgwqAgaW50IGVycjsNCj4+PiDCoMKgwqDCoMKgIHJldHVybiB4ZW5fZG9fcmVh
ZF9tc3IobXNyLCB4ZW5fbXNyX3NhZmUgPyAmZXJyIDogTlVMTCk7DQo+Pj4gwqAgfQ0KPj4+
ICsjZGVmaW5lIFBWX1BST0xPR1VFX01TUl94ZW5fcmVhZF9tc3LCoMKgwqAgIm1vdiAlZWN4
LCAlZWRpOyINCj4+PiArI2RlZmluZSBQVl9FUElMT0dVRV9NU1JfeGVuX3JlYWRfbXNywqDC
oMKgIFwNCj4+PiArwqDCoMKgICJtb3YgJXJheCwgJXJkeDsgbW92ICVlYXgsICVlYXg7IHNo
ciAkMHgyMCwgJXJkeDsiDQo+Pj4gK1BWX0NBTExFRV9TQVZFX1JFR1NfTVNSX1RIVU5LKHhl
bl9yZWFkX21zcik7DQo+Pj4gLXN0YXRpYyB2b2lkIHhlbl93cml0ZV9tc3IodTMyIG1zciwg
dTY0IHZhbCkNCj4+PiArX192aXNpYmxlIHZvaWQgeGVuX3dyaXRlX21zcih1MzIgbXNyLCB1
MzIgbG93LCB1MzIgaGlnaCkNCj4+DQo+PiBEaXR0by4NCj4gDQo+IFNlZSBhYm92ZS4NCj4g
DQo+Pg0KPj4+IMKgIHsNCj4+PiDCoMKgwqDCoMKgIGludCBlcnI7DQo+Pj4gLcKgwqDCoCB4
ZW5fZG9fd3JpdGVfbXNyKG1zciwgdmFsLCB4ZW5fbXNyX3NhZmUgPyAmZXJyIDogTlVMTCk7
DQo+Pj4gK8KgwqDCoCB4ZW5fZG9fd3JpdGVfbXNyKG1zciwgKHU2NCloaWdoIDw8IDMyIHwg
bG93LA0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgeGVuX21zcl9zYWZlID8gJmVy
ciA6IE5VTEwpOw0KPj4+IMKgIH0NCj4+PiArI2RlZmluZSBQVl9QUk9MT0dVRV9NU1JfeGVu
X3dyaXRlX21zcsKgwqDCoCBcDQo+Pj4gK8KgwqDCoCAibW92ICVlY3gsICVlZGk7IG1vdiAl
ZWF4LCAlZXNpOyINCj4+PiArI2RlZmluZSBQVl9FUElMT0dVRV9NU1JfeGVuX3dyaXRlX21z
cg0KPj4+ICtQVl9DQUxMRUVfU0FWRV9SRUdTX01TUl9USFVOSyh4ZW5fd3JpdGVfbXNyKTsN
Cj4+PiDCoCAvKiBUaGlzIGlzIGNhbGxlZCBvbmNlIHdlIGhhdmUgdGhlIGNwdV9wb3NzaWJs
ZV9tYXNrICovDQo+Pj4gwqAgdm9pZCBfX2luaXQgeGVuX3NldHVwX3ZjcHVfaW5mb19wbGFj
ZW1lbnQodm9pZCkNCj4gDQo+IA0KPiBKdWVyZ2VuDQoNCg==
--------------8gPqDNrCU3txf0i5KlVP6wo8
Content-Type: text/x-patch; charset=UTF-8;
 name="0001-x86-alternative-save-original-code-before-replacing-.patch"
Content-Disposition: attachment;
 filename*0="0001-x86-alternative-save-original-code-before-replacing-.pa";
 filename*1="tch"
Content-Transfer-Encoding: base64

RnJvbSA3ZGIyZTk3OTA0NDJkMDczZDI1ZmVjMjIwZDg4ZmIyZjg1ZTQ2ODNmIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+
CkRhdGU6IFdlZCwgNyBNYXkgMjAyNSAxMjo0NzoyMiArMDIwMApTdWJqZWN0OiBbUEFUQ0hd
IHg4Ni9hbHRlcm5hdGl2ZTogc2F2ZSBvcmlnaW5hbCBjb2RlIGJlZm9yZSByZXBsYWNpbmcg
aXQKCkluIGNhc2Ugb2YgQUxUX0ZMQUdfRElSRUNUX0NBTEwgYmVpbmcgc2V0IGZvciBhbiBh
bHRlcm5hdGl2ZQpyZXBsYWNlbWVudCwgdGhlIHBhdGNoaW5nIG5lZWRzIHRvIGxvb2sgYXQg
dGhlIG9yaWdpbmFsIGluc3RydWN0aW9uIHRvCmZpbmQgdGhlIHRhcmdldCBhZGRyZXNzIG9m
IHRoZSBkaXJlY3QgY2FsbCB0byBiZSBwYXRjaGVkIGluLgoKSW4gY2FzZSBvZiBuZXN0ZWQg
QUxURVJOQVRJVkVzIHRoaXMgbGltaXRzIHRoZSB1c2Ugb2YKQUxUX0ZMQUdfRElSRUNUX0NB
TEwgdG8gZWl0aGVyIHRoZSBmaXJzdCByZXBsYWNlbWVudCwgb3IgdG8gYmUKbXV0dWFsbHkg
ZXhjbHVzaXZlIHdpdGggYWxsIHByZXZpb3VzIHJlcGxhY2VtZW50cy4gT3RoZXJ3aXNlIHRo
ZQpvcmlnaW5hbCBjb2RlIGNvdWxkIGhhdmUgYmVlbiBvdmVyd3JpdHRlbiBhbHJlYWR5IHJl
c3VsdGluZyBpbiBhCkJVRygpLCBkdWUgdG8gQUxUX0ZMQUdfRElSRUNUX0NBTEwgaGFuZGxp
bmcgbm90IGZpbmRpbmcgdGhlIGV4cGVjdGVkCmluZGlyZWN0IGNhbGwgaW5zdHJ1Y3Rpb24u
CgpBdm9pZCB0aGlzIHByb2JsZW0gYnkgc2F2aW5nIHRoZSBvcmlnaW5hbCBjb2RlIGJlZm9y
ZSByZXBsYWNpbmcgaXQuIEFzCnRoaXMgaXMgdGhlIG9ubHkgY2FzZSB3aGVyZSB0aGUgb3Jp
Z2luYWwgY29kZSBpcyByZXF1aXJlZCB0byBiZQphbmFseXplZCwgc3BlY2lhbCBjYXNlIHRo
ZSBjb3B5IHRvIGhhcHBlbiBvbmx5IGlmIHRoZSBvcmlnaW5hbCBjb2RlIGhhcwp0aGUgbGVu
Z3RoIG9mIGFuIGluZGlyZWN0IGNhbGwgKDYgYnl0ZXMpLiBUaGlzIG1pbmltaXplcyBjb21w
bGV4aXR5IGFuZApzdGFjayB1c2FnZS4KClNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jvc3Mg
PGpncm9zc0BzdXNlLmNvbT4KLS0tCiBhcmNoL3g4Ni9rZXJuZWwvYWx0ZXJuYXRpdmUuYyB8
IDMwICsrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDIx
IGluc2VydGlvbnMoKyksIDkgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvYXJjaC94ODYv
a2VybmVsL2FsdGVybmF0aXZlLmMgYi9hcmNoL3g4Ni9rZXJuZWwvYWx0ZXJuYXRpdmUuYwpp
bmRleCBiZjgyYzZmN2Q2OTAuLjhkNmQzYTRmYzRhYiAxMDA2NDQKLS0tIGEvYXJjaC94ODYv
a2VybmVsL2FsdGVybmF0aXZlLmMKKysrIGIvYXJjaC94ODYva2VybmVsL2FsdGVybmF0aXZl
LmMKQEAgLTM4Nyw2ICszODcsMTIgQEAgRVhQT1JUX1NZTUJPTChCVUdfZnVuYyk7CiAKICNk
ZWZpbmUgQ0FMTF9SSVBfUkVMX09QQ09ERQkweGZmCiAjZGVmaW5lIENBTExfUklQX1JFTF9N
T0RSTQkweDE1CisjZGVmaW5lIENBTExfUklQX0lOU1RSX0xFTgk2CisKK3N0YXRpYyBpbmxp
bmUgdTggKiBpbnN0cl92YShzdHJ1Y3QgYWx0X2luc3RyICppKQoreworCXJldHVybiAodTgg
KikmaS0+aW5zdHJfb2Zmc2V0ICsgaS0+aW5zdHJfb2Zmc2V0OworfQogCiAvKgogICogUmV3
cml0ZSB0aGUgImNhbGwgQlVHX2Z1bmMiIHJlcGxhY2VtZW50IHRvIHBvaW50IHRvIHRoZSB0
YXJnZXQgb2YgdGhlCkBAIC00MDIsNyArNDA4LDcgQEAgc3RhdGljIGludCBhbHRfcmVwbGFj
ZV9jYWxsKHU4ICppbnN0ciwgdTggKmluc25fYnVmZiwgc3RydWN0IGFsdF9pbnN0ciAqYSkK
IAkJQlVHKCk7CiAJfQogCi0JaWYgKGEtPmluc3RybGVuICE9IDYgfHwKKwlpZiAoYS0+aW5z
dHJsZW4gIT0gQ0FMTF9SSVBfSU5TVFJfTEVOIHx8CiAJICAgIGluc3RyWzBdICE9IENBTExf
UklQX1JFTF9PUENPREUgfHwKIAkgICAgaW5zdHJbMV0gIT0gQ0FMTF9SSVBfUkVMX01PRFJN
KSB7CiAJCXByX2VycigiQUxUX0ZMQUdfRElSRUNUX0NBTEwgc2V0IGZvciB1bnJlY29nbml6
ZWQgaW5kaXJlY3QgY2FsbFxuIik7CkBAIC00MTQsNyArNDIwLDcgQEAgc3RhdGljIGludCBh
bHRfcmVwbGFjZV9jYWxsKHU4ICppbnN0ciwgdTggKmluc25fYnVmZiwgc3RydWN0IGFsdF9p
bnN0ciAqYSkKICNpZmRlZiBDT05GSUdfWDg2XzY0CiAJLyogZmYgMTUgMDAgMDAgMDAgMDAg
ICBjYWxsICAgKjB4MCglcmlwKSAqLwogCS8qIHRhcmdldCBhZGRyZXNzIGlzIHN0b3JlZCBh
dCAibmV4dCBpbnN0cnVjdGlvbiArIGRpc3AiLiAqLwotCXRhcmdldCA9ICoodm9pZCAqKiko
aW5zdHIgKyBhLT5pbnN0cmxlbiArIGRpc3ApOworCXRhcmdldCA9ICoodm9pZCAqKikoaW5z
dHJfdmEoYSkgKyBhLT5pbnN0cmxlbiArIGRpc3ApOwogI2Vsc2UKIAkvKiBmZiAxNSAwMCAw
MCAwMCAwMCAgIGNhbGwgICAqMHgwICovCiAJLyogdGFyZ2V0IGFkZHJlc3MgaXMgc3RvcmVk
IGF0IGRpc3AuICovCkBAIC00MzIsMTEgKzQzOCw2IEBAIHN0YXRpYyBpbnQgYWx0X3JlcGxh
Y2VfY2FsbCh1OCAqaW5zdHIsIHU4ICppbnNuX2J1ZmYsIHN0cnVjdCBhbHRfaW5zdHIgKmEp
CiAJcmV0dXJuIDU7CiB9CiAKLXN0YXRpYyBpbmxpbmUgdTggKiBpbnN0cl92YShzdHJ1Y3Qg
YWx0X2luc3RyICppKQotewotCXJldHVybiAodTggKikmaS0+aW5zdHJfb2Zmc2V0ICsgaS0+
aW5zdHJfb2Zmc2V0OwotfQotCiAvKgogICogUmVwbGFjZSBpbnN0cnVjdGlvbnMgd2l0aCBi
ZXR0ZXIgYWx0ZXJuYXRpdmVzIGZvciB0aGlzIENQVSB0eXBlLiBUaGlzIHJ1bnMKICAqIGJl
Zm9yZSBTTVAgaXMgaW5pdGlhbGl6ZWQgdG8gYXZvaWQgU01QIHByb2JsZW1zIHdpdGggc2Vs
ZiBtb2RpZnlpbmcgY29kZS4KQEAgLTQ1MSw3ICs0NTIsOCBAQCB2b2lkIF9faW5pdF9vcl9t
b2R1bGUgbm9pbmxpbmUgYXBwbHlfYWx0ZXJuYXRpdmVzKHN0cnVjdCBhbHRfaW5zdHIgKnN0
YXJ0LAogCQkJCQkJICBzdHJ1Y3QgYWx0X2luc3RyICplbmQpCiB7CiAJdTggaW5zbl9idWZm
W01BWF9QQVRDSF9MRU5dOwotCXU4ICppbnN0ciwgKnJlcGxhY2VtZW50OworCXU4IG9sZF9p
bnNuW0NBTExfUklQX0lOU1RSX0xFTl07CisJdTggKmluc3RyLCAqcmVwbGFjZW1lbnQsICpv
bGRfdmEgPSBOVUxMOwogCXN0cnVjdCBhbHRfaW5zdHIgKmEsICpiOwogCiAJRFBSSU5USyhB
TFQsICJhbHQgdGFibGUgJXB4LCAtPiAlcHgiLCBzdGFydCwgZW5kKTsKQEAgLTUxMywxMSAr
NTE1LDIxIEBAIHZvaWQgX19pbml0X29yX21vZHVsZSBub2lubGluZSBhcHBseV9hbHRlcm5h
dGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAJCQlpbnN0ciwgaW5zdHIsIGEtPmlu
c3RybGVuLAogCQkJcmVwbGFjZW1lbnQsIGEtPnJlcGxhY2VtZW50bGVuLCBhLT5mbGFncyk7
CiAKKwkJLyoKKwkJICogUmVtZW1iZXIgb3JpZ2luYWwgY29kZSBpZiBpdCBjb3VsZCBiZSBh
biBpbmRpcmVjdCBjYWxsLgorCQkgKiBUaGlzIGVuYWJsZXMgQUxUX0ZMQUdfRElSRUNUX0NB
TEwgaGFuZGxpbmcgd2l0aCBuZXN0ZWQKKwkJICogYWx0ZXJuYXRpdmVzIGV2ZW4gaWYgdGhl
IG9yaWdpbmFsIGNvZGUgaGFzIGJlZW4gbW9kaWZpZWQKKwkJICogYWxyZWFkeS4KKwkJICov
CisJCWlmIChvbGRfdmEgIT0gaW5zdHIgJiYgYS0+aW5zdHJsZW4gPT0gQ0FMTF9SSVBfSU5T
VFJfTEVOKSB7CisJCQlvbGRfdmEgPSBpbnN0cjsKKwkJCW1lbWNweShvbGRfaW5zbiwgaW5z
dHIsIENBTExfUklQX0lOU1RSX0xFTik7CisJCX0KIAkJbWVtY3B5KGluc25fYnVmZiwgcmVw
bGFjZW1lbnQsIGEtPnJlcGxhY2VtZW50bGVuKTsKIAkJaW5zbl9idWZmX3N6ID0gYS0+cmVw
bGFjZW1lbnRsZW47CiAKIAkJaWYgKGEtPmZsYWdzICYgQUxUX0ZMQUdfRElSRUNUX0NBTEwp
IHsKLQkJCWluc25fYnVmZl9zeiA9IGFsdF9yZXBsYWNlX2NhbGwoaW5zdHIsIGluc25fYnVm
ZiwgYSk7CisJCQlpbnNuX2J1ZmZfc3ogPSBhbHRfcmVwbGFjZV9jYWxsKG9sZF9pbnNuLCBp
bnNuX2J1ZmYsIGEpOwogCQkJaWYgKGluc25fYnVmZl9zeiA8IDApCiAJCQkJY29udGludWU7
CiAJCX0KLS0gCjIuNDMuMAoK
--------------8gPqDNrCU3txf0i5KlVP6wo8
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-----

--------------8gPqDNrCU3txf0i5KlVP6wo8--

--------------FQpVx09W26fNIC7HeaTTIYft--

--------------cmlXY6sTu0icBS3IID1Pum54
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/Ey8FAmgh2nUFAwAAAAAACgkQsN6d1ii/Ey9o
7ggAjBJOzNRO+4BzxuLGg+syxKJfYbYssjfuDVf1QCze3TTqr1lPO4z1J+Fkat7RPFWDwQWfQiFO
YoOo3dOc1HiL8ur2b3hDAxrxVjxfmhsoOLg4MKpAxlsczgmuoSNpjP9+mCZARWFymGcYvtOwmbCW
TlZUpqxHUH8eHtJYHfw3QJTeZjWdyUok1NCxUrhXvTmX4+7ru7YSYk4ombP3MW1SMfgOBkeMvQCK
FX+MuOApiBKennMroQQ1S0tMbpzwMF0N41PmKup1rq0hIWPe5ddbF9S/UrUWDPMe6kw/aVOzcXgN
AZ/XVapQ4L5AGg25bOh4TLNmF+9766wn6r/BYFkt/w==
=3Fv4
-----END PGP SIGNATURE-----

--------------cmlXY6sTu0icBS3IID1Pum54--


From xen-devel-bounces@lists.xenproject.org Mon May 12 11:26:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 11:26:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981306.1367696 (Exim 4.92)
	(envelope-from )
	id 1uERIh-0002ev-Qc; Mon, 12 May 2025 11:26:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981306.1367696; Mon, 12 May 2025 11:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uERIh-0002eo-Nl; Mon, 12 May 2025 11:26:27 +0000
Received: by outflank-mailman (input) for mailman id 981306;
 Mon, 12 May 2025 11:26:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uERIg-0002ei-He
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 11:26:26 +0000
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [2a00:1450:4864:20::432])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id efdd9d9b-2f23-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 13:26:24 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a0be321968so2532662f8f.2
 for ; Mon, 12 May 2025 04:26:24 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442d773f794sm81649465e9.0.2025.05.12.04.26.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 04: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" 
X-Inumbo-ID: efdd9d9b-2f23-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747049184; x=1747653984; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=LLyuq94eLIOoomhbtngtzYWNd8RViT8j01aFh2gXs7M=;
        b=cW3JwGrh60AxB7LYjM2oaBCzNWgCC1bTnA5mZiqGebYnlSrrmfDc5oFpGRBplRYj0n
         yaR9RcxAyhyEMmbXU0srWZ3k7qScmoLpA25PkZ2dqGEbBM3jcwdgufecB99Z3scto5XB
         KXchF9ThPixLfB/+xuipAon8FRYS3Ek9GghZc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747049184; x=1747653984;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LLyuq94eLIOoomhbtngtzYWNd8RViT8j01aFh2gXs7M=;
        b=FP8ywT93neHNI+z5VTQgehK5fzx3zXZy8YcMIVZoHutWaTa2mUkDYkkFdTR7mXrDgQ
         uw6pgj40S4N6hyvnb8dQ3lH/8irnQNGCZSGli2X+r3xG9d4+kQ9e0+17tyyy+WbDJAfV
         44r1Iih1NeQouhiCBd1aDuH7BC8+np/wrYjzgMotBzEs6tpdf+dYupwlEfEH9N3RnXgt
         tgBHlkyFQmZxt9pouCepZg5VhT+yf3YG1CkbtjKMV0JkTJmK7TsXk3k6w58QfWfy09WH
         b5RjuNT5b53SpU+piZ7V9GuAQeYjQzoXZtgFpRrTt8rnpVfzUKedtVyl2+EXy/9UMu9B
         SMMA==
X-Forwarded-Encrypted: i=1; AJvYcCV4mtqNPY5GA7SK8xrgWF77rPCHZBY/o/R8a+5TeS43sAwhS0Xr0SlD2mUWbB3BQ/YgPLV71LVHqZM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+h4tc51wWG9QpozpeBGCf1pPdbeXkv3dgqSpKCHSj3X/KTuX0
	NIXW6EWNckLfFrjI0iL7GWdnl47cPOEBdI84qDTXt9RFXmCkgkDK80duAGw2veo=
X-Gm-Gg: ASbGncvnNlBuPI4HQDz+mtvNOhKjFgeb0U0rL0B0afgpLDbxxLKytKJ505vxlBATPHx
	5ICUOQII0NrIHTh15E7IU/qK3opww/sKBOYWVuRj9pONtZoPnYbOV54v3ntvmdyUBIMB0m65KI8
	FqDU/tiv1g9Rc+iTBuL+ATHTgyHm4lxfepDId5fY0uF8NN0a7Qtr1CnqM2GTHcAd7IUQDFqzIz/
	6qzNn53VxL1IYd+sTNno5e5dlCvZnPzzL2upfCmbke7C/BoxolDtkrH3PD+ihzBWyJyut7BLkAD
	lkn+qxNTNTAPPnQJaLipnyodf9D9GFjLZ7FrkymKlMvBoEf/Xs3TsbeNEanmbkdGPLOZ8m7pz0c
	8QBK4bTg02bdfJWo4
X-Google-Smtp-Source: AGHT+IGw9UqU4jDjGgGTcaGF/+ci6pKQSiBtPRCL6EtFhxMexazWh0EFoAfk3WVfgqq7J+xVcgqJDQ==
X-Received: by 2002:a05:6000:200d:b0:3a0:7d27:f076 with SMTP id ffacd0b85a97d-3a1f64299d8mr10634898f8f.2.1747049183878;
        Mon, 12 May 2025 04:26:23 -0700 (PDT)
Message-ID: <6c64fd25-e7cf-47e9-9830-c631cb497c2b@citrix.com>
Date: Mon, 12 May 2025 12:26:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3] sbat: Add SBAT section to the Xen EFI binary
To: Jan Beulich ,
 Gerald Elder-Vass 
Cc: dpsmith@apertussolutions.com, marmarek@invisiblethingslab.com,
 Frediano Ziglio ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250507135442.3439237-1-gerald.elder-vass@cloud.com>
 <94652153-99fe-47d8-84d5-cbf2865ad6e0@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

On 12/05/2025 11:50 am, Jan Beulich wrote:
> On 08.05.2025 10:51, Andrew Cooper wrote:
>> On 07/05/2025 2:54 pm, Gerald Elder-Vass wrote:
>> Also,
>>
>>> ld: warning: orphan section `.sbat' from `prelink.o' being placed in section `.sbat'
>> This is because sbat.o is getting linked into the non-EFI build of Xen too.
>>
>> I'm less sure how to go about fixing this.  There's no nice way I can
>> see of of getting sbat.o only in the EFI build.  The other option is to
>> discard it for the ELF build.
> We already link $(note_file) into just xen.efi; I'm pretty sure the same could
> be done for this new object.

Ah - that was the string I was failing to search for.

But, note_file is special and complicated.  sbat.o would be a regular
EFI-only object, but that can't be expressed currently, with how
prelink.o works.

I think in the short term, the v4 patch is the way to go.  Reworking the
build system to have EFI-only and ELF-only objects is a larger task.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 12 11:48:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 11:48:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981315.1367706 (Exim 4.92)
	(envelope-from )
	id 1uERdo-0005lR-Ae; Mon, 12 May 2025 11:48:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981315.1367706; Mon, 12 May 2025 11:48: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 1uERdo-0005lK-89; Mon, 12 May 2025 11:48:16 +0000
Received: by outflank-mailman (input) for mailman id 981315;
 Mon, 12 May 2025 11:48:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uERdm-0005lE-W4
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 11:48:15 +0000
Received: from mail5.wdc04.mandrillapp.com (mail5.wdc04.mandrillapp.com
 [205.201.139.5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fb1ff8a4-2f26-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 13:48:12 +0200 (CEST)
Received: from pmta16.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail5.wdc04.mandrillapp.com (Mailchimp) with ESMTP id 4ZwyXq0MQvzG0CKHQ
 for ; Mon, 12 May 2025 11:48:11 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 dbe51b49c11a48ea980e2dc3adc9e7ba; Mon, 12 May 2025 11: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" 
X-Inumbo-ID: fb1ff8a4-2f26-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747050491; x=1747320491;
	bh=YEqULifj3Mz1rv6w9uKqW/wpFiLVlULCp7JvhnkpaEk=;
	h=From:Subject:Message-Id:To:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=eQcgz9xa/IWu/jnptGzbtBuHpj0OYjVpFpp6WsYwp6Lq9bR5A1F5SaGmVR9/Ep/pW
	 QuYGnfl6RO5PJpFbrJhTKDtUX7qFY57tPkzcgE/n1ce28vum+VHgDP0CFuqeMhFgVo
	 uDXPPj7KISF1J/y8m8YDKNeSJlaWqfAvLlAQF9x4wVU7637aSccSulZRT/MvDeMCFd
	 QirvVbphWpL7BxUPcKuUrT9hOi7soF33ata8l6+gNgStuk89Scs27VmkA5XVi4NZC2
	 ofaof5P4eAuJYLuVKZtL2iCNQEZl5Ym2wEH7P1VBfffWUrgvPbjL85VBbAAzZhWicb
	 db20F0B6ZKaBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747050491; x=1747310991; i=teddy.astie@vates.tech;
	bh=YEqULifj3Mz1rv6w9uKqW/wpFiLVlULCp7JvhnkpaEk=;
	h=From:Subject:Message-Id:To:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=wPkSW6NyIDSy4Ndyualv0vGwlTLNMt9RZ2BAnu93WHbNb6zooEOt+Hm6wM1ArkB2T
	 +qfZ2E/L+CoCtSfXXHn/iIapCgDplac2GKBukoFWBUNH9ce2Ka0RHFATtjXoDaImYH
	 3WW2vQ2r5OF1vbOevSlyXpRY7lIo4SxqsFrRaeiRDTNGsDE37SWkson25QetXxapcZ
	 WKiyTqCYzshWBwz43RijyktUSGSuA2iylfvWeSe4PjxlEz8mIe83UqF4nJDvf7ZyCb
	 0eEIFJxQafO3xdB9HYUQqfT1TDKJ0gpmTLYp/KtP9u9cgUOxiZJtzYOfSFY14s4WZu
	 jstSFfPOzjgEQ==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=204/4]=20Disallow=20most=20command-line=20options=20when=20lockdown=20mode=20is=20enabled?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747050490075
Message-Id: <3e35eeb3-c4f6-423e-9185-5d98b6d1d060@vates.tech>
To: "Kevin Lampis" , xen-devel@lists.xenproject.org
References: <20250506162347.1676357-1-kevin.lampis@cloud.com> <20250512090210.1718623-1-kevin.lampis@cloud.com>
In-Reply-To: <20250512090210.1718623-1-kevin.lampis@cloud.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.dbe51b49c11a48ea980e2dc3adc9e7ba?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250512:md
Date: Mon, 12 May 2025 11:48:11 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

Le 12/05/2025 =C3=A0 11:04, Kevin Lampis a =C3=A9crit=C2=A0:
> A subset of command-line parameters that are specifically safe to use
> when lockdown mode is enabled are annotated as such.
> 
> Signed-off-by: Kevin Lampis 
> ---
>   xen/arch/arm/domain_build.c           |  4 +--
>   xen/arch/x86/acpi/cpu_idle.c          |  2 +-
>   xen/arch/x86/cpu/amd.c                |  2 +-
>   xen/arch/x86/cpu/mcheck/mce.c         |  2 +-
>   xen/arch/x86/cpu/microcode/core.c     |  2 +-
>   xen/arch/x86/dom0_build.c             |  4 +--
>   xen/arch/x86/hvm/hvm.c                |  2 +-
>   xen/arch/x86/irq.c                    |  2 +-
>   xen/arch/x86/nmi.c                    |  2 +-
>   xen/arch/x86/setup.c                  |  2 +-
>   xen/arch/x86/traps.c                  |  2 +-
>   xen/arch/x86/x86_64/mmconfig-shared.c |  2 +-
>   xen/common/domain.c                   |  2 +-
>   xen/common/kernel.c                   | 10 +++++-
>   xen/common/kexec.c                    |  2 +-
>   xen/common/numa.c                     |  2 +-
>   xen/common/page_alloc.c               |  2 +-
>   xen/common/shutdown.c                 |  2 +-
>   xen/drivers/char/console.c            |  2 +-
>   xen/drivers/char/ns16550.c            |  4 +--
>   xen/drivers/video/vga.c               |  2 +-
>   xen/include/xen/param.h               | 49 +++++++++++++++++++++------
>   22 files changed, 70 insertions(+), 35 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index df29619c40..8ff1af3787 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -41,7 +41,7 @@
>   #include 
>   
>   static unsigned int __initdata opt_dom0_max_vcpus;
> -integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
> +integer_secure_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>   
>   /*
>    * If true, the extended regions support is enabled for dom0 and
> @@ -61,7 +61,7 @@ static int __init parse_dom0_mem(const char *s)
>   
>       return *s ? -EINVAL : 0;
>   }
> -custom_param("dom0_mem", parse_dom0_mem);
> +custom_secure_param("dom0_mem", parse_dom0_mem);
>   
>   int __init parse_arch_dom0_param(const char *s, const char *e)
>   {
> diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
> index 1dbf15b01e..431fd0c997 100644
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -113,7 +113,7 @@ static int __init cf_check parse_cstate(const char *s=
)
>           max_csubstate =3D simple_strtoul(s + 1, NULL, 0);
>       return 0;
>   }

What makes ...

> -custom_param("max_cstate", parse_cstate);
> +custom_secure_param("max_cstate", parse_cstate);

... specifically unsafe ?

>   
>   static bool __read_mostly local_apic_timer_c2_ok;
>   boolean_param("lapic_timer_c2_ok", local_apic_timer_c2_ok);
> diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
> index 37d67dd15c..c36351c968 100644
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -47,7 +47,7 @@ integer_param("cpuid_mask_thermal_ecx", opt_cpuid_mask_=
thermal_ecx);
>   
>   /* 1 =3D allow, 0 =3D don't allow guest creation, -1 =3D don't allow bo=
ot */
>   int8_t __read_mostly opt_allow_unsafe;
> -boolean_param("allow_unsafe", opt_allow_unsafe);
> +boolean_secure_param("allow_unsafe", opt_allow_unsafe);
>   
>   /* Signal whether the ACPI C1E quirk is required. */
>   bool __read_mostly amd_acpi_c1e_quirk;
> diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.=
c
> index 1c348e557d..a229af6fd3 100644
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -31,7 +31,7 @@
>   #include "vmce.h"
>   
>   bool __read_mostly opt_mce =3D true;
> -boolean_param("mce", opt_mce);
> +boolean_secure_param("mce", opt_mce);
>   bool __read_mostly mce_broadcast;
>   bool is_mc_panic;
>   DEFINE_PER_CPU_READ_MOSTLY(unsigned int, nr_mce_banks);
> diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microco=
de/core.c
> index 34a94cd25b..b5b7304ae7 100644
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -160,7 +160,7 @@ static int __init cf_check parse_ucode(const char *s)
>   
>       return rc;
>   }
> -custom_param("ucode", parse_ucode);
> +custom_secure_param("ucode", parse_ucode);
>   
>   static struct microcode_ops __ro_after_init ucode_ops;
>   
> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
> index 0b467fd4a4..6d42acb661 100644
> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
> @@ -142,7 +142,7 @@ static int __init cf_check parse_dom0_mem(const char =
*s)
>   
>       return s[-1] ? -EINVAL : ret;
>   }
> -custom_param("dom0_mem", parse_dom0_mem);
> +custom_secure_param("dom0_mem", parse_dom0_mem);
>   
>   static unsigned int __initdata opt_dom0_max_vcpus_min =3D 1;
>   static unsigned int __initdata opt_dom0_max_vcpus_max =3D UINT_MAX;
> @@ -164,7 +164,7 @@ static int __init cf_check parse_dom0_max_vcpus(const=
 char *s)
>   
>       return *s ? -EINVAL : 0;
>   }
> -custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
> +custom_secure_param("dom0_max_vcpus", parse_dom0_max_vcpus);
>   

I think it is acceptable for being able to configure dom0-max-vcpus and 
dom0-mem. It's very likely that the toolstack/user wants to configure that.

>   static __initdata unsigned int dom0_nr_pxms;
>   static __initdata unsigned int dom0_pxms[MAX_NUMNODES] =3D
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 4cb2e13046..97afb274fe 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -87,7 +87,7 @@ unsigned long __section(".bss.page_aligned") __aligned(=
PAGE_SIZE)
>   
>   /* Xen command-line option to enable HAP */
>   static bool __initdata opt_hap_enabled =3D true;
> -boolean_param("hap", opt_hap_enabled);
> +boolean_secure_param("hap", opt_hap_enabled);

---

I think there are several lockdown missing parameters, for instance 
(dom0-)iommu related parameters should be definetely supposed unsafe.

(dom0-)iommu parameter can be used to disable PCI Passthrough related 
security features (quarantine thus disabling fix for some XSA variants) 
or using invalid IOMMU configurations (e.g dom0-iommu=3Dnone).

In the same idea, PCI Passthrough to PV guests without a IOMMU should be 
made impossible in this mode, as it actually allows the guest to perform 
a privilege escalation using (actually unrestricted) DMA.

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Mon May 12 11:51:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 11:51:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981326.1367717 (Exim 4.92)
	(envelope-from )
	id 1uERgz-0007Uy-PH; Mon, 12 May 2025 11:51:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981326.1367717; Mon, 12 May 2025 11: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 1uERgz-0007Ur-Lz; Mon, 12 May 2025 11:51:33 +0000
Received: by outflank-mailman (input) for mailman id 981326;
 Mon, 12 May 2025 11:51:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uERgy-0007UY-Mv
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 11:51:32 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 727089d9-2f27-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 13:51:32 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a1b8e8b2b2so2149142f8f.2
 for ; Mon, 12 May 2025 04:51:32 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f5a4c5d6sm12094962f8f.83.2025.05.12.04.51.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 04:51: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" 
X-Inumbo-ID: 727089d9-2f27-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747050691; x=1747655491; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8SDF3LYJCyjiVfqNond5j2p/vCSnfsuzefPFVHAPXo4=;
        b=IvoE3UbxYAEtmMMraMFG0ymxcv/TVInxfW56QDvXvJ47pGOiAPkPYXEdLsKpudP94h
         UJTOMNUJrKNFlwP27II+q/FMqTIsIEDvJqLlhaaMBK3qU4hVL76Y2p/fp0SPBVCtFF6Q
         w2aCRCL9m7FLlEtgZi6yilErhPBEpzc9D2I4c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747050691; x=1747655491;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8SDF3LYJCyjiVfqNond5j2p/vCSnfsuzefPFVHAPXo4=;
        b=OfV7Wk+7h215wHiujJ4nVUWtFoOfl+UEYqFcoaSGt3m2tk0mwLsCiZy8tSORdX0c4Y
         OHc5W4ODMlQlY239i1GidPrXvPZfMCBGWP1SkpIxoekIiB9qQH5pErEMKBJARjRZYPAp
         QH2Lb9xD3HoihjESzJBoTxIidC9waiW4oehunvBxNWtNkPVOlEZeIlfkRDZ+B6zFDqqz
         R48lCNcHsz1JLbmsUlDsXtsS7uoW+TF3Lw1spL0XDcT0yQVnH8tYkrjoXesLLPja8aPt
         oI+/EIcMKTaKtLtxBFH0aDwd5LZrRcFkxlKyFEB+kcjMd8zavWl0Sp8Z2h+EyDb8hFBg
         ZaCA==
X-Gm-Message-State: AOJu0Yxl5CjC2jmsIVtf6xr0tACGfbUPDv2ZtDNlm47Hgtbjmv/jzZDN
	BHtBiwlQu+KO5vC+A4sGWZZdZTQTuNeFY8+/34VfFzpLrxgE2D3nqalc/FkuXn8=
X-Gm-Gg: ASbGnctlEX3RsdT+HmoIdK7n69gbYoyKuANmDqTjqsYck0WL8No/29YLnDsHxsmUzOq
	EDZYhWctmVLOFE5Wtf+9Sa1huFVL0UY9ltwCf1ghDx2tSROZmOGeM/Gi3G0qVhmiOJXtQgHWD8j
	oaFFrHCB6MUnv7tJp6GAZ6jOm7QDbKrSb+9PDc3CX4URu/16qtqi7hj38v5bqabVAUt7qmlK9QY
	M6wcRaBwChXvALifOfOcRzIee3VHY1k6/TIPwPFP5aBvnkcPLy/Os249zD6yR5gwECZMJ8mjzQF
	1w6Bw2GKhoSIoia8/kYjn31mU6IQWiUq/3GTeun0fJbS8gULmTDwl48uqjKKF2cZRy4avGfSXlV
	VLqDFIxpsV5519kU2
X-Google-Smtp-Source: AGHT+IGdXHuIiKYssrajeFOsVbHZ6SnQScWj+fkWJ9N15W1jc1FzwLy2ucCrQvxW2ng9vUxgzkwTNg==
X-Received: by 2002:a5d:64cd:0:b0:3a0:7017:61f6 with SMTP id ffacd0b85a97d-3a1f6436694mr10495635f8f.14.1747050691423;
        Mon, 12 May 2025 04:51:31 -0700 (PDT)
Message-ID: <33bb2c1d-0283-4cea-b1ce-84ef0ea950ad@citrix.com>
Date: Mon, 12 May 2025 12:51:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/4] Add lockdown mode
To: Jan Beulich , Kevin Lampis 
Cc: xen-devel@lists.xenproject.org
References: <20250506162347.1676357-1-kevin.lampis@cloud.com>
 <10454237-2ada-4972-8e31-8ae21a6d6d22@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: <10454237-2ada-4972-8e31-8ae21a6d6d22@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/05/2025 11:27 am, Jan Beulich wrote:
> On 06.05.2025 18:23, Kevin Lampis wrote:
>> Add lockdown mode
>>
>> The intention of lockdown mode is to prevent attacks from a rogue dom0
>> userspace from compromising the system. Lockdown mode can be controlled by a
>> Kconfig option and a command-line parameter. It is also enabled automatically
>> when Secure Boot is enabled and it cannot be disabled in that case.
>>
>> Ross Lagerwall (3):
>>   lib: Add strcspn function
>>   efi: Add a function to check if Secure Boot mode is enabled
>>   Add lockdown mode
>>
>> Kevin Lampis (1):
>>   Disallow most command-line options when lockdown mode is enabled
> Returning from vacation, this series is a mess in my inbox (and also on
> https://lists.xen.org/archives/html/xen-devel/2025-05/threads.html): Only
> patch 4 is properly threaded. Please can you see about adjusting your
> mail configuration?

We had corporate mail problems last week, which was interfering with
posting patches.  It's hopefully been resolved now.

Kevin: It will be best to resend the series in full.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 12 11:58:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 11:58:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981334.1367727 (Exim 4.92)
	(envelope-from )
	id 1uERng-00085O-Dv; Mon, 12 May 2025 11:58:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981334.1367727; Mon, 12 May 2025 11:58: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 1uERng-00085H-B0; Mon, 12 May 2025 11:58:28 +0000
Received: by outflank-mailman (input) for mailman id 981334;
 Mon, 12 May 2025 11:58:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uERne-00085B-RB
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 11:58:26 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 685a8808-2f28-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 13:58:24 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a064a3e143so2442436f8f.3
 for ; Mon, 12 May 2025 04:58:24 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442cd3b7c89sm164194925e9.38.2025.05.12.04.58.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 04:58: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" 
X-Inumbo-ID: 685a8808-2f28-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747051104; x=1747655904; 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;
        bh=13MkauBuH09ermsY/i1fhguUQBZhfWnVGzvmuz1PuqQ=;
        b=plBb4XBSk5cbphflK+cEQ/t17tGc3iWKTI0HfY3/6ZF0MVDliEwcis6of9Fb3LAE69
         ToX3oXs9ifm4lDuzNOBEC4B4IJtgscJYaNc6NukVzsfA/Sgk2qHIjX0FzpTHdi/StYZ0
         tHsvKq7ORcZd1J/4OGNU6hZAX1Y3AAflSArOc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747051104; x=1747655904;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=13MkauBuH09ermsY/i1fhguUQBZhfWnVGzvmuz1PuqQ=;
        b=blkyarepP7F+yvJzVK4OnUE7h8wnbZcJQNJ6U2CCA7hUF4BApUm8pUNV+vDtHrcjpv
         N/nlTLz0bOKp2NidKX0dymUSKyob6UuplNzFi7r+rRS5ZU8SzAge2cho0CF0I0WqVNUs
         md9MgLNfvTeoO4XwKrWD8XgJuAytxnzXLdJKTJCwwCeEY9m89fSd8JeMEdBm5slCTBLS
         1xd5Dubua7F4MmIZyIb3yAGAEjMWhLYY3T5MPMIRiCACJyk/by2EVVqg2MCSojIMqUHr
         SdG62ovOIOvUaeEhd626TaQtyGNy5thisRMNuVzs/kw3cr3qGF2qZlTmBbHFXpHCwRO6
         kJ2Q==
X-Gm-Message-State: AOJu0YyhbjjKEU3rznqbDdqksldKX1h/SYoC+GB98gMXjnLAKpLRV68A
	QN7sQLqAR7rOVkakBcFCng6CEjLccRXCbYHzjcnX13P3EIyUU1ZBFXi63SHds21WbVqmxoenWWz
	9
X-Gm-Gg: ASbGncunAopm9GqRHYwYm8ljHC/J7sT96FPPDcj8pWphjof0UwHjVoCUe4ZnpKSVQJK
	yG1gdg4gapLiSV8gfPrdc/+9Z1+F/7oWHjfArucRL7dY1AhLOhrat3PP+Ju0diqRDTk7IZvpbld
	jMlveRX8PJv98T1uF3DJU00a/CBEVN/IY93ock3w3sj/KDJLMBA5UY9MENzOBh4jMYTcMVuFtSM
	AqnlFg/o2uETial0kuBelurKm5z/dZ7NrEl1y8HEx+j2xtMQfUxtvyiIuHxy9mS8MbGQ7w9rEyp
	Lxkt+oxdY4fNr8tNDyKRKzqF4aI7SiBvPcUetWi5+WVxH1s+kln6/TgbWaseD8Y4bcL/71VFoof
	3l4BySd3HBjeXnPMO7BnNpZPp
X-Google-Smtp-Source: AGHT+IG6QrcUJ/ZIO7OBToaPa9UL75zA32ElOmFpp6UnK2ZFdurh8+2ji/LkDXOULYW3JqN7m+ZCNg==
X-Received: by 2002:a5d:5f56:0:b0:3a0:85b5:463b with SMTP id ffacd0b85a97d-3a1f64ab29fmr10853978f8f.48.1747051103794;
        Mon, 12 May 2025 04:58:23 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/idt: Minor improvements to _update_gate_addr_lower()
Date: Mon, 12 May 2025 12:58:21 +0100
Message-Id: <20250512115821.3444375-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

After some experimentation, using .a/.b makes far better logic than using the
named fields, as both Clang and GCC spill idte to the stack when named fields
are used.

GCC seems to do something very daft for the addr1 field.  It takes addr,
shifts it by 32, then ANDs with 0xffff0000000000000UL, which requires
manifesting a MOVABS.

Clang follows the C, whereby it ANDs with $imm32, then shifts, avoiding the
MOVABS entirely.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

I'm disappointed about how poor the code generation is when assigning to named
fields, but I suppose it is a harder problem for the compiler to figure out.

add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-24 (-24)
Function                                     old     new   delta
machine_kexec                                356     348      -8
traps_init                                   434     418     -16
---
 xen/arch/x86/include/asm/idt.h | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/include/asm/idt.h b/xen/arch/x86/include/asm/idt.h
index f613d5693e0e..b5e570a77fae 100644
--- a/xen/arch/x86/include/asm/idt.h
+++ b/xen/arch/x86/include/asm/idt.h
@@ -92,15 +92,16 @@ static inline void _set_gate_lower(idt_entry_t *gate, unsigned long type,
  * Update the lower half handler of an IDT entry, without changing any other
  * configuration.
  */
-static inline void _update_gate_addr_lower(idt_entry_t *gate, void *addr)
+static inline void _update_gate_addr_lower(idt_entry_t *gate, void *_addr)
 {
+    unsigned long addr = (unsigned long)_addr;
+    unsigned int addr1 = addr & 0xffff0000U; /* GCC force better codegen. */
     idt_entry_t idte;
-    idte.a = gate->a;
 
-    idte.b = ((unsigned long)(addr) >> 32);
-    idte.a &= 0x0000FFFFFFFF0000ULL;
-    idte.a |= (((unsigned long)(addr) & 0xFFFF0000UL) << 32) |
-        ((unsigned long)(addr) & 0xFFFFUL);
+    idte.b = addr >> 32;
+    idte.a = gate->a & 0x0000ffffffff0000UL;
+    idte.a |= (unsigned long)addr1 << 32;
+    idte.a |= addr & 0xffff;
 
     _write_gate_lower(gate, &idte);
 }
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 12 11:59:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 11:59:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981344.1367737 (Exim 4.92)
	(envelope-from )
	id 1uERob-0000Cy-PF; Mon, 12 May 2025 11:59:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981344.1367737; Mon, 12 May 2025 11:59: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 1uERob-0000Cr-M2; Mon, 12 May 2025 11:59:25 +0000
Received: by outflank-mailman (input) for mailman id 981344;
 Mon, 12 May 2025 11:59:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uERoa-00085B-EJ
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 11:59:24 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8b1a1314-2f28-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 13:59:22 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5feb22e7d84so1130989a12.3
 for ; Mon, 12 May 2025 04:59: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
 a640c23a62f3a-ad2197bd37dsm605046466b.124.2025.05.12.04.59.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 04:59: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" 
X-Inumbo-ID: 8b1a1314-2f28-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747051162; x=1747655962; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=FK4JcS+fIT6eo9UjGYSqne0KLmiGSIGmFIR8W4uh718=;
        b=g/ImPGHuTl1/vF8zKjUpMA10howREAk+3b22KV/p2nYMdZDcFQsh0Pq/ba38RtmKug
         3KXc5QA4AKcHToH2I1+LNJWobU4ZAqCxaP6/3ZczCeZK4961XnhIEuOjZfLNDlFk1HPk
         Wb0+K0SxXqIOOYD2jKbPQOCTKSwCww6AwpmIuEC/B0RkcxZe0LD2iH2rC235pCD7nPTz
         L1tc9YVdXkBVcXj8SvZFBkFnGq8R5njLX55eqGrMoSpXPjjLbtMhZpAhxXrow/7BIOhK
         gY1Z0Yxj5BkKj5KNUwr6fhBxKAjdUjcZiXJ/4id6OsPF/36OOA+hfORcL1Q39mQAueST
         d0/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747051162; x=1747655962;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FK4JcS+fIT6eo9UjGYSqne0KLmiGSIGmFIR8W4uh718=;
        b=ViAgkUZW1ILrglg9eP/o1RghZgLYHe+ak1sTUrgyptDh2wbD/uwLyn1zurS1rzjXFQ
         kOGlpLYJMoVokbeLTDGXHEzewGisbODQW1HSpL3L3dcY+ceiuRVkCtaeQnCpCrvq+ETw
         +PsHLRYpQuhalG8KC0ZdaG346ANEoD5+WQ0DtAOvN/AVmtTKpXqkvfiztoVg5SLYb4lC
         Lt6f16zyXHlOLojyGr9j3fiUtgWGrrsJe7h7gFaLLYqAFA7GjTUFI2i0sVYFJ8lfUXnS
         oRJ+aeLUVMhsJpnm6X92fBjh3R4GOYEf0gCKq4dA2DgU1CdrFhQcWoEMzMDE6RR/oTOl
         yiBQ==
X-Gm-Message-State: AOJu0YzerokB0J4f3yFempcXEj1lNsDyLldpi60AgU+k33I0fs/A56mW
	SbqxcrRT6YVBML0BLkGMu6jHJOmhCwBbeD8/sGXm3wfNVKZ8PyYK9OMn3Hq/ew==
X-Gm-Gg: ASbGnctbT5U01VCf0OfMlXmrayqYRX4HjEAj3Ce0RHQIH8naJ7HAN9QgJdsOD0eWy0g
	dBsV5lh5IOMtftnJEjS6zSO8+YrBtUeMpd903/K1otOGM7dh+odiSq45zWO7vE2SUTeXpv1y2ec
	JA5R03Q9tllZB9Ja0vcK1kO+YfvVUQ1VEY9IsUu9kmJ2v+5Wxzu5Q7iqf/q5051StVMeBn1PAi3
	dntepBBikLipHqUmmjWkPjhKKnCJSToaOiUIsKvawRTNxXpjvwqCDC6gfOP/NI9vHIXO8/EBXTY
	Q0ZdrpbN4qD3OfzTG7psavIKvPo28Q/+FTYKUU0/9K6PyiGVSemcxJrpv1eBEDmsPqtFyadT9l/
	kWmbYDBM7HBrqnHGu4ygSJTRR1KjfwudGaNVT
X-Google-Smtp-Source: AGHT+IGwalL61JL/0IxRUygjg7Vg6IAxjh135BvpRdE7WCIspYr32t/XiHlIFkAQpdHsAbU40YDevg==
X-Received: by 2002:a17:907:6a13:b0:ace:c518:1327 with SMTP id a640c23a62f3a-ad218f1b830mr1244603466b.14.1747051162265;
        Mon, 12 May 2025 04:59:22 -0700 (PDT)
Message-ID: <548430a5-fa4a-41d1-b5ba-ba45efa90bbc@suse.com>
Date: Mon, 12 May 2025 13:59:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Use __auto_type
To: Andrew Cooper 
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Roberto Bagnara ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" ,
 Stefano Stabellini 
References: <20250505124646.1569767-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.05.2025 21:44, Stefano Stabellini wrote:
> On Mon, 5 May 2025, Andrew Cooper wrote:
>> In macros it is common to declare local variables using typeof(param) in order
>> to ensure that side effects are only evaluated once.  A consequence of this is
>> double textural expansion of the parameter, which can get out of hand very
>> quickly with nested macros.
>>
>> A GCC extension, __auto_type, is now avaialble in the new toolchain baseline
>> and avoids the double textural expansion.
> 
> I think this is a good change

+1

Jan



From xen-devel-bounces@lists.xenproject.org Mon May 12 12:00:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 12:00:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981353.1367748 (Exim 4.92)
	(envelope-from )
	id 1uERpd-0001iN-6e; Mon, 12 May 2025 12:00:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981353.1367748; Mon, 12 May 2025 12: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 1uERpd-0001iG-25; Mon, 12 May 2025 12:00:29 +0000
Received: by outflank-mailman (input) for mailman id 981353;
 Mon, 12 May 2025 12:00:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uERpb-0001i4-Vh
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 12:00:27 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b0d4a3a1-2f28-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 14:00:26 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-440685d6afcso49085555e9.0
 for ; Mon, 12 May 2025 05:00:26 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f58f33b5sm12460480f8f.54.2025.05.12.05.00.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 05:00: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" 
X-Inumbo-ID: b0d4a3a1-2f28-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747051225; x=1747656025; 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;
        bh=o9C25/zJkOBu3Gqsy7Zlw3kC1/MzrPAZCWFxQZ+xvH0=;
        b=HcDTe3MOPNcp+d2pVcD1FofJNUt6gl8tuQvSbcLnngEL2uuMKZ3I4WN162Q1uhkAyS
         V/L8XhPnBcIX9etzPospe8g58NuIail5vVvSBRRWpReTc7rDE162/PSeSxt2byeFzIsa
         PDBDhETnbPv9NiHnyEQ6aSb69lVkprbJm5QoA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747051225; x=1747656025;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=o9C25/zJkOBu3Gqsy7Zlw3kC1/MzrPAZCWFxQZ+xvH0=;
        b=AkOv5HVHJRxuwE+IYeGh/SqMgv/sGX+yxlAgX4R8J8u5LRKzoJzn+2BE6cGhy+drHF
         DMTbXrNZS/IzBaVohqOOLT/ub9pSVFP6Q9Sws/SEowj2w3BH03NxwtEw6eHf4ooACY36
         IeZmoMu4Fqz7FtNXRTF0+2FnF86t4d/y9l2lARdgaSnc8nYY2YlJmFguTxoAexXsWxCV
         zVQT7bkuatIiTBS6anQQryRx05PDuHTP4Ma7LMnOw285l5HPamTt3Kb79rnDT86Hl2ht
         u671zqiRKogbq0BpnonGaYXvw4HrPhjqeuuPjPQTg/dvZG3AJMUFYNC/pDeGZ2UZapPs
         y3mg==
X-Gm-Message-State: AOJu0YwOfT3KwQb7atZ5/ZM5HU7Yb8y96e7PvLJtRjOPTySuakfPVYvO
	OAnXJbVJjeMqqvAX/jijr69b958vqnu1js75jNCn6bgOrfAFSLzTJZHPOcKVLFbCgrH1B74CSEB
	+
X-Gm-Gg: ASbGncvAYHiFw8wFHAexzrHCAkeyo2sIjpnMIbtassfoSogLN4UuWyXtaDQS+3o0LMa
	t027WYYymKZ7m7rV3Mo4us8PZoGScKE72pSkghM0ZxdvSE9VD1D7Q+8YPe8xl3Ix6+4P7uySNNn
	PSEOiFbCe0qK0pPL1POTuLyn1i+XF+1c2CeS7bhP5cFqWs28ozAzWvjQRfzrD+NNVFHAhgYPVy0
	VXc81vmLDEY7l0dGb8QVxwddcwyqWpeelYnXO2dkHsfUIA1/tg40hQ8Vued1CLMa3hIdjOlML1S
	oGHwOnZuVDczj6bbHDNhacFX+mTF6JkrwIzd7XrsSRipcz5X79EEQJ54frS+HJ9H1P4zEP8ZPNG
	Em5f18outQO3YaACJQA69OdJG
X-Google-Smtp-Source: AGHT+IEPYR4IRNTXWcqq94UhwJv9iE6hL37pLoU8EhyoZyHwEwnuQu782X7E0Zgx9cXdCy/i3Zxu4A==
X-Received: by 2002:a5d:588a:0:b0:3a0:b2ff:fb00 with SMTP id ffacd0b85a97d-3a1f64b4557mr8853139f8f.44.1747051225328;
        Mon, 12 May 2025 05:00:25 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/smp: Drop booting_cpu
Date: Mon, 12 May 2025 13:00:15 +0100
Message-Id: <20250512120015.3445217-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

Since commit 434596bbd44a ("x86/smpboot: Write the top-of-stack block in
cpu_smpboot_alloc()"), smp_processor_id() is unconditionally usable on APs.
Drop the global variable.

Also drop the parameter from start_secondary().  It was introduced as unused
in commit e9ac3bbccab0 ("Move initial stack-pointer adjustment into assembly
bootstrap code.") in 2005.  At the time, the caller was a shared codepath with
__start_xen() with a parameter on the stack, but that never mattered for
start_secondary() which ultimately reset_stack_and_jump()'s out of context.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/smpboot.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 54207e6d8830..49e111018224 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -226,8 +226,6 @@ static void smp_callin(void)
         cpu_relax();
 }
 
-static int booting_cpu;
-
 /* CPUs for which sibling maps can be computed. */
 static cpumask_t cpu_sibling_setup_map;
 
@@ -315,15 +313,10 @@ static void set_cpu_sibling_map(unsigned int cpu)
     }
 }
 
-void asmlinkage start_secondary(void *unused)
+void asmlinkage start_secondary(void)
 {
     struct cpu_info *info = get_cpu_info();
-
-    /*
-     * Dont put anything before smp_callin(), SMP booting is so fragile that we
-     * want to limit the things done here to the most necessary things.
-     */
-    unsigned int cpu = booting_cpu;
+    unsigned int cpu = smp_processor_id();
 
     /* Critical region without IDT or TSS.  Any fault is deadly! */
 
@@ -571,8 +564,6 @@ static int do_boot_cpu(int apicid, int cpu)
      */
     mtrr_save_state();
 
-    booting_cpu = cpu;
-
     start_eip = bootsym_phys(entry_SIPI16);
 
     /* start_eip needs be page aligned, and below the 1M boundary. */
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 12 12:07:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 12:07:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981367.1367756 (Exim 4.92)
	(envelope-from )
	id 1uERwd-0002nN-Qy; Mon, 12 May 2025 12:07:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981367.1367756; Mon, 12 May 2025 12: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 1uERwd-0002nG-OT; Mon, 12 May 2025 12:07:43 +0000
Received: by outflank-mailman (input) for mailman id 981367;
 Mon, 12 May 2025 12:07:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uERwc-0002nA-Ov
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 12:07:42 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b336aa4a-2f29-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 14:07:39 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5fc7edf00b2so5985832a12.2
 for ; Mon, 12 May 2025 05:07: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
 a640c23a62f3a-ad2193495bdsm610340666b.70.2025.05.12.05.07.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 05: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" 
X-Inumbo-ID: b336aa4a-2f29-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747051659; x=1747656459; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ZzxqJRUchxduD2qliZWGJ4qreGyMGn/+ORIcwAXW37k=;
        b=RW0J5Kqv1gdZReoN+SpYawhu8fBAlvsG4Fc5ceZLz3uWE94bOXy+ITKfUzs0UaxMd8
         ToTLEYHB9hBMrB7q8c2j7merec4JFpC7/F+1T8YY+cnbZj7Vbb1mG4PdgZG1wLn14DZg
         pcokUsK/l2FmWGdAiamGyi0IKafiVa7oGfUb1/KiNTsGS7TrIUPcdyw0Iqx2/R2kZSsA
         ldB9POp0IW0FE5Nl4NbbhNC/6gIh+6i1v5PlsOxs7DLYYWZLN6VmE+EvNN03sMwcIhQi
         KZyYr5vBnrrs7V5edWMzT0rIY2fxB7VNNISXs13IBIWpVBzwlfEntBj8x9k/z2j/oXBJ
         8FpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747051659; x=1747656459;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZzxqJRUchxduD2qliZWGJ4qreGyMGn/+ORIcwAXW37k=;
        b=S1KgUI9I9UcBl8sZ2WspRMk2LPA5bOR9cdOpNBY6GvMXB5DclGHpVWRAvhEGoLA4S5
         RGkq5TAci7nq4IPBKLV1bft7d7a12wo8k9idhx12rJeXJ/KYhEerphaHsMHFDV6sdJbS
         iLthtJaXiCWZKcemdyoukRXz8/uHKZQ6ng93qeW5dIte3hditcKui/Mr5DwFlqTnPx5Q
         Ap7j05JmN+5ZA8M9s/RruWMC7XIAzAHOvXvM/Lmi+CicOsTEd/6SJaDRRSXmzgHqZTrm
         pD5SVeK7SoOdSsDP6/KOrtOnHXlnygLjbkp9w/1X8VdU2oQjfnyGYrBdaRaIK2jzfT7s
         vsLA==
X-Forwarded-Encrypted: i=1; AJvYcCVa+a17hDKw7fg+2KyS25ugrSUm3pp2ljXqulQ0tZ397P/1jkzESZDG8OT2fC/YN0S/cVG5/NVcK58=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw0P7SwOsSDntJg3G8xwE7LrfwoO4Ar/6DoDiy8otnjdVAucU47
	cg4DNlcAsVlBQRoM1LtFICWj/HSnALs/Txf4P4+s/JBSieJEMNw+QNL9b26jAw==
X-Gm-Gg: ASbGncvXL9rv7QBdQ3OjFYW7tvUrmM03uE0azXQdBIerfr1rr+zVxMhYK1IoSRqlN1M
	NMLRpknwheqeljp8nhTgA9H9LHpQ+PV8bHn3YUACPXTul+3wHBnuxX7m9wJK2qOdOl5g5CDG1lq
	bLfycvc7uoGKRSnC0LoKUjErdRJ1zCRfBD2Ax4gPC5GI85ocSsDp87W/idWMxrQ9Qd9/Ut/iPJ2
	oeajYHITVpjqp7G20eC0IlgC8NzQrlFuCMn8CzirPSmJ5KEgTErPMRrZ6vQKw9LjEOuNJYa0Vsy
	qkIXaFEpPOuAEbXLVeU/hO8xEHarSN+Hn+c5nKuw7OJPH7tmSgRTSXsgO3uliyCZrCLFHlUSwUo
	w8sBkVGBu611IFDXqF3wQuXh2b8wvuUGexNlh
X-Google-Smtp-Source: AGHT+IFxXlGCW60sYk5MF6pA2kX62MOZYW8hlTyUK2tD7Plgkrcv9aMt/whiWuScc4EcepSOVvOpFw==
X-Received: by 2002:a17:907:72c9:b0:ad2:3637:805e with SMTP id a640c23a62f3a-ad236378505mr768201266b.35.1747051659080;
        Mon, 12 May 2025 05:07:39 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 14:07:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/page_alloc: address violation of Rule 14.3
To: Stefano Stabellini 
Cc: Nicola Vetrini ,
 Victor Lira , Andrew Cooper
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Federico Serafini ,
 Bertrand Marquis , 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

On 10.05.2025 01:28, Stefano Stabellini wrote:
> From: Federico Serafini 
> 
> MISRA C Rule 14.3 states that "Controlling expressions shall not be
> invariant".
> 
> Change the #define to static inline to resolve the violation.
> 
> Signed-off-by: Federico Serafini 
> Signed-off-by: Victor Lira 
> 
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index bd4538c28d..9ee1506703 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2005,7 +2005,10 @@ static unsigned long __initdata buddy_alloc_size =
>      MB(CONFIG_BUDDY_ALLOCATOR_SIZE);
>  size_param("buddy-alloc-size", buddy_alloc_size);
>  #else
> -#define domain_num_llc_colors(d) 0
> +static inline unsigned int domain_num_llc_colors(const struct domain *d)
> +{
> +    return 0;
> +}

Isn't this merely pleasing Eclair without actually addressing the violation?
The spec's last example is, I think, a good demonstration (sadly the PDF
doesn't allow copy-out). The violation described there, with a loop
calculating a value ahead of the actual if(), is even less obviously one
than the inline function here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 12:09:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 12:09:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981374.1367768 (Exim 4.92)
	(envelope-from )
	id 1uERyf-0003JZ-71; Mon, 12 May 2025 12:09:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981374.1367768; Mon, 12 May 2025 12:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uERyf-0003JS-2p; Mon, 12 May 2025 12:09:49 +0000
Received: by outflank-mailman (input) for mailman id 981374;
 Mon, 12 May 2025 12:09:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uERyd-0003JM-Nv
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 12:09:47 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ff0546a9-2f29-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 14:09:46 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-442d146a1aaso40393375e9.1
 for ; Mon, 12 May 2025 05:09:46 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442cd3aecb0sm169013085e9.28.2025.05.12.05.09.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 05:09: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" 
X-Inumbo-ID: ff0546a9-2f29-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747051786; x=1747656586; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1XybKaSeMET3ehfT/Pk08q5R7nB6PeZjU+wO/tiIGbQ=;
        b=cXW1upvcIzrDQhagMgvo3DP1n16DQS8VVthhpaOOFy+9MXODJ/JI21A5fcEJqTmjXY
         YUynn8QbQFHbTPVLRuoOm0VI/SUxmhQOF/9mLX6WFVfBMKXupfenNWNVrznXOyAMK7aQ
         9B+O8FtHviLpYMyaY1nUuJMSXM6cTynq8YmLw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747051786; x=1747656586;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1XybKaSeMET3ehfT/Pk08q5R7nB6PeZjU+wO/tiIGbQ=;
        b=lOKidwczjZmsji0a/tPfccA1JyF9xUkUDataDmzGxqir272Ag9HZ1YaObLR7zLXfMA
         2wo2Z1ik5orTj3L2LZtH24sFG6i7phS0lZmq0uuQt++tweC/wBQuLOl/vo87oZtmaM2V
         3LQ4J2QFedJVa3LluWqx0YPAvZG5DIFYho70b02it+s1Ju74f41xpW8mpizO0SE20Ylb
         ZrXFsniw3L/gSododwhh42gPvx9U5j+a9wRnk205InmENLYH5Un1BaMeEqnmCiS5UNi+
         //QAhW7513g1NmNbqgZ8+Bx4YYG8DcYDDrfyFQYzw1h5zIWYdDbUntqGW09/TxaYhEXt
         Z9TA==
X-Gm-Message-State: AOJu0Yywa148MRkP6yve1rDKrABd6liDCb3ksaMYHAJSWoeHMuMioKvc
	BzyMM5XBh5eWtlQpl/fry/bAF2gevS0KA49gSqOPMUCJ3bYDAGawBtmCuacWfQA=
X-Gm-Gg: ASbGncsd5zeB2WhOv/H0e/EFZQUoZoAWLWxVHSqdJWjbnxSSKT8ztv74Bu0tGbbsC2A
	s34dkmYL/LD47/t3tEvCPepPPMYVM+GXQzXSTF+G/4mxavWj5hqKgZptPDeVk76uXgyKgvLCkN2
	UGPoFIphshWk4Y4ZLQTTKhEZDlSEfFtfj3uvCyYWo5lVhjXSl56yWgfWGAXQdq7y7bcesS0ZbZS
	o/BtstYlfwnQNr31KbdfhTJGulrH8VxYWRoz/K80UjvyI2+sZCeR2SVsbDBncHWQ5jW39k389lA
	q/GXtIbID0A6tiI+lqgHCK2zTrfPoWJhVp+YNpNhPJG+7EjMEm8hkgU9a0CWPi9weRjaGqav0/3
	Ojz72sMpAFYIwhliFMjR9mOXxFo8=
X-Google-Smtp-Source: AGHT+IEHy7zUQakT+qgVzLlZGy4BxYJ7YD+USINp1q4dMcfZTLEcgT3YlTPICkfIYebEYIzKNO7h2Q==
X-Received: by 2002:a05:600c:8519:b0:43c:e481:3353 with SMTP id 5b1f17b1804b1-442d6dacbdcmr130772525e9.17.1747051786286;
        Mon, 12 May 2025 05:09:46 -0700 (PDT)
Message-ID: <7acc83a3-2b15-4557-b293-0832b35e3680@citrix.com>
Date: Mon, 12 May 2025 13:09:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Use __auto_type
To: Jan Beulich 
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Roberto Bagnara ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" ,
 Stefano Stabellini 
References: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
 
 <548430a5-fa4a-41d1-b5ba-ba45efa90bbc@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: <548430a5-fa4a-41d1-b5ba-ba45efa90bbc@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/05/2025 12:59 pm, Jan Beulich wrote:
> On 05.05.2025 21:44, Stefano Stabellini wrote:
>> On Mon, 5 May 2025, Andrew Cooper wrote:
>>> In macros it is common to declare local variables using typeof(param) in order
>>> to ensure that side effects are only evaluated once.  A consequence of this is
>>> double textural expansion of the parameter, which can get out of hand very
>>> quickly with nested macros.
>>>
>>> A GCC extension, __auto_type, is now avaialble in the new toolchain baseline
>>> and avoids the double textural expansion.
>> I think this is a good change
> +1

That looks like agreement.

Now for the (new) controversial part.  Since sending this, Linux has
decided to just #define auto __auto_type for C < 23, in order to start
writing C23 compatible code from now.  It's more succinct, and has
better longevity.

We might want to consider the same, although it will introduce a new
example of defining a keyword, which we'd have to call out in the
MISRA/Eclair config.

If we're going to do this, we should do it from the outset.

Thoughts?

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 12 12:19:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 12:19:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981383.1367776 (Exim 4.92)
	(envelope-from )
	id 1uES7l-0005Hm-0O; Mon, 12 May 2025 12:19:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981383.1367776; Mon, 12 May 2025 12:19: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 1uES7k-0005Hf-U3; Mon, 12 May 2025 12:19:12 +0000
Received: by outflank-mailman (input) for mailman id 981383;
 Mon, 12 May 2025 12:19:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uES7i-0005HW-RM
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 12:19:10 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4de92d8c-2f2b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 14:19:08 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad21cc2594eso458855766b.1
 for ; Mon, 12 May 2025 05:19: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
 a640c23a62f3a-ad219746730sm617518866b.94.2025.05.12.05.19.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 05:19:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4de92d8c-2f2b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747052348; x=1747657148; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=EVWA36RgFiCmqoJ9uRX+CTqmQc93aIquu6iaXIi+lnc=;
        b=cf6e52vkacJ5SDDzkV+zZtyJBGyEgkZ5ajL1q1ZDj3Gah/IurttkOLIX+PCCKwTgGa
         qyXWLMYhvGLwLaTgKNhGplvndnwZX/WeVuFl6m5I8lASkVceO/Xomu+R+RT8GJhWvqRe
         qC5dvVi4lkFDr/YkiYX8HtTxnb2XhlNbIwqkPVCVQJXf5ToUTnykuhwTSHdelDAgHCc8
         rq8w3AYdAYYpYXah+HO7zgerbZxPhb9axZ/x9MSWntB2uwyzxHewKHdUQh+7FyA2vbt2
         NBbpd3WCA6CGMnTehaU8MSFls1L70oQj9kchCwqOPqgUcnoTZh44y3v/fprXEO98mt8G
         Y4zA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747052348; x=1747657148;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EVWA36RgFiCmqoJ9uRX+CTqmQc93aIquu6iaXIi+lnc=;
        b=govefViUFe2UNMgzQQBg2oU3HrWD9diciCE7HD7q1qbJYd6ME4MQZ8E8/Tcckop0Rl
         L3ySKG0/VfoCL3izt5kXCd4jHiHQSCUILE0vDlBEbLSP5c7bXXdM+NtowEVdF/je/9NF
         6bxaIUyXvRGrj2ra8z5x0Xg+RlPTEnbz25U5OKcPSpo9dZrIeAKPeQw04WxTFKPdgy4M
         i6k/f605XLS0UJHnL8I4byetRmDnjaNbutiRajGrMgelHz0ts5jQT6GhwLyt6MgNim5T
         Z/uSE8JSnOLXnw2vCQnN4luD8TSerBEc/N8bDR9YStcnchLVxdwQGqJwjX22Xo+5wgmF
         ozdA==
X-Forwarded-Encrypted: i=1; AJvYcCW1ZPG2WVsJzMK/eroNn1k46fyl1zUnJK8OH1IVNM7xPUsBYAc8M/rl4O/HOcB8AaFod/XudJB51+0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzUCIHe1s5C8BXEClc3swtgo7HQ9oWYvmo+21OW5caDD3KoJweN
	gTZCRe4tZ23YAyThENo6VNzb+xTTumiT3OzA1okkBwV03E3NKzjAOv2HaT0Svw==
X-Gm-Gg: ASbGnctbmZPjLmszBXWZVbvkCT3I6NHBv4EOz/MTnDEGlurBLQis3nmTWqfiF9IpK7o
	vhKmOHNhc1py8g0kal2KEOQurIv+eHf7djZMd23Hk4dmfSvoleG6nPq1nXfdMw3bslF9cenCZxi
	9bhMZ32oR3m2tgCAZsd+3W25X7x7daI5+uv55R7zmfF2JMuDLnusaEfYI4V+3q0PaEm58U4D1v5
	8JUjCGpqOEIYJvdhhwFdrvD8bWYRoRWxgdt/vIYWR75ErNRHbDRdsJqsB5RtOVsqC6Kn8q8zLHJ
	Gy45ZsF9GQztYpG+PEUC1/MbAL4E1171C9sOhnbv/M60UdKpusJH3JMR9UFi8vxqz0rwDE/LdOD
	lKlyEflx10bHKovMMMEBHRuABsk8LBjbZT4TE
X-Google-Smtp-Source: AGHT+IFHd8A2Hw/TR1YrbrgH4TYBQepQqVSzp0DYLOCzNUbvB/kRcYSur7Vker0Wz+dj+apwTZjBzg==
X-Received: by 2002:a17:907:cb83:b0:ad2:321d:2726 with SMTP id a640c23a62f3a-ad2321d2b5amr929900466b.38.1747052347997;
        Mon, 12 May 2025 05:19:07 -0700 (PDT)
Message-ID: <5e3a8054-53aa-490f-a60e-44ed34cbc74b@suse.com>
Date: Mon, 12 May 2025 14:19:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] docs: Introduce live patch signing
To: Ross Lagerwall 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
 <20250509161846.45851-1-ross.lagerwall@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250509161846.45851-1-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 18:18, Ross Lagerwall wrote:
> --- a/docs/misc/livepatch.pandoc
> +++ b/docs/misc/livepatch.pandoc
> @@ -917,6 +917,58 @@ The normal sequence of events is to:
>   3. *XEN_SYSCTL_LIVEPATCH_ACTION* with *LIVEPATCH_ACTION_APPLY* to apply the patch.
>   4. *XEN_SYSCTL_LIVEPATCH_GET* to check the `->rc`. If in *-XEN_EAGAIN* spin. If zero exit with success.
>  
> +## Signature Checking
> +
> +While loading live patches would generally be restricted to a privileged
> +process in dom0, in certain cases signature checking in Xen may be required.
> +For example, when Secure Boot is enabled live patches need to be verified
> +before being loaded.
> +
> +Xen live patches are ELF binaries but there is no standardized mechanism for
> +signing ELF binaries. One approach used by Linux is to append a signature to
> +the end of the binary, outside of the ELF container. While this works, it tends
> +to be fragile since tools that handle ELF binaries do not correctly handle the
> +signature. Instead, the approach taken here is to use an ELF note for the
> +signature.
> +
> +The ELF note section name shall be `.note.Xen.signature` with note name `Xen`
> +and type `0`.
> +
> +The note data shall contain a header followed by the signature data:
> +
> +    #define SIGNATURE_SUPPORTED_VERION 1

I don't think this is a good name (leaving aside the typo); conceptually
multiple versions could be supported. Otoh live patches are hypervisor
build specific anyway, so it's hard to see why a version would be needed
in the first place. Alternatively should version or ...

> +    #define SIGNATURE_ALGORITHM_RSA 0
> +    #define SIGNATURE_HASH_SHA256 0

... these two be encoded in the note's type, instead of leaving that
effectively unused?

> +    struct payload_signature {
> +        uint16_t version;
> +        uint8_t algo;        /* Public-key crypto algorithm */
> +        uint8_t hash;        /* Digest algorithm */
> +        uint32_t sig_len;    /* Length of signature data */

Should there be a minimum length specified, to ensure security at least
for the moment (before e.g. quantum computers can break things)?

> +    };
> +
> +To sign a live patch:
> +
> +1) Add a new note section with a populated payload signature and zeroed out
> +   signature.
> +2) Generate a detached signature over the entire binary.
> +3) Fill in the signature in the note section.
> +
> +During live patch load, Xen shall verify the signature using the following
> +steps:
> +
> +1) Copy the signature out of the note section.
> +2) Zero the signature.
> +3) Generate a detached signature over the entire binary.
> +4) Compare against the signature from (1).
> +
> +Initially, to avoid including DER / X.509 parsing of certificates, handling
> +chains, etc. Xen shall verify signatures against a compiled in RSA key in
> +exponent/modulus form.

And this is sufficient to satisfy (Microsoft's?) requirements?

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 12:38:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 12:38:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981396.1367788 (Exim 4.92)
	(envelope-from )
	id 1uESQ1-00008T-Ka; Mon, 12 May 2025 12:38:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981396.1367788; Mon, 12 May 2025 12: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 1uESQ1-00008L-Gm; Mon, 12 May 2025 12:38:05 +0000
Received: by outflank-mailman (input) for mailman id 981396;
 Mon, 12 May 2025 12:38:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uESQ0-00008F-MI
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 12:38:04 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f0ff1ec7-2f2d-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 14:38:01 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ad228552355so480275166b.3
 for ; Mon, 12 May 2025 05:38: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
 a640c23a62f3a-ad2192c8b8asm610752066b.5.2025.05.12.05.38.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 05:38: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" 
X-Inumbo-ID: f0ff1ec7-2f2d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747053481; x=1747658281; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=aT0D4ojX2bvbICT+PYBWDsRqSpt4TYYKT0tGZvIX83U=;
        b=YvAsEXDloB1L1v0mmsftKlIRFonSvRinndBQf9EvTRUMsUqAs+I7IMVMhIkI7OKrOU
         rcZXCQnDTdKw8LE88BlNjcEgFpgW15hSapJfAHiqUIj+GfprKBqwlC+YN0qLe7QdoI/d
         BAFzlz5vNZNfYb0zp+T/uWIgnzsfcbb7/Mp5J+MAZfnanc3ZPpAmw1H1DBzQRX4J1CkG
         DKzsC3P9cpiObYyAISdt677WtCzDRszQa0dWqnMNyD4x6k17Z5AkzEckB6irQgXbbtrJ
         I5RF9Y7yYF4+zAHk4TYEAraZlNOAWUkj+yqCuMQWJWwJ2fEyYfp4lVph2lyMkjYijmkK
         /nmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747053481; x=1747658281;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aT0D4ojX2bvbICT+PYBWDsRqSpt4TYYKT0tGZvIX83U=;
        b=KQtN0YyD/cNccd5OdZOtMXa5C1nZ24WVF/nX5GvVZqBM+QGwv+zZHJcDBB3NP/X2xz
         C2DebXtipC8AD+JgXaBGT+3KriHpC3enh2mjUrFEp9suF9UIZkYsG4NcCPztkTqLN/KA
         GLmZ0WXkh/coZCCJbhZ7Z+vizeloIQKOANcKzVkD9hvnEvtrfMOw4XoaPEcA+uU4qsgG
         lN/Sl/Sfk/iWCL+NudUeI1vO1Vt728btjVpfOrO5SmfFK2wuTRUECMONRr7iF8wxgHCf
         e7DmHPK2k7OFlli4RXEJDMIbz7zCvLk+t4kYg54zetxJM3htw9kK/VO2xfgaTZVniLT0
         axlQ==
X-Forwarded-Encrypted: i=1; AJvYcCUI1Tmxj9vf9rNESjbz8sl5Q8Mi0csiu6HEMtT588shmwyIvlfYFPJ9RG0SJNz+sCN16fJGO/rDlPo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwiQX736z8Z9eCdtWV7fM7Z7FpIOyrBzZvepRdQOJmDBOJRmRBa
	TecRlnBQbPHO9YMjCNa6PpWTwywSTjvWbQZowQsJAciU6otnKHln7iaWFxy0ag==
X-Gm-Gg: ASbGncuD7zsG+PTM95pf2YivZCQNhlpo+PsfAQ9ISTpeE4FxdqmwIYvedLWyh27xijy
	pYh2ecWGDqnZwGR77m7Sa8KjkZQ61ycGsfbcDcoS+zK3eJ2h3x4hBesU4ektr+TKPEtGkZR4XO5
	bahDlKRG+kC/OthPpwXl51k2ugBiv1z0Av45d+i24ig1C5CVcGWJWPIagS36XVYHtfV+0bBJsV0
	BaTOaRo2x6/vroafQLj1aVJT5V2HhFzv/Mhwi/epj9QerhnfZOqzIOW6l+baaGeh+G+I/zatka6
	i+6iBvC0AA6lWZlAbobCK3PVHbQFD4l8/Z9rXsn5tXPpfQhlNS+I1h6f3kJSQSonxRLZNGCPj4U
	xG5siVcxh6KIehXAle7TJ4l8S9Mtg8K6xhMI4
X-Google-Smtp-Source: AGHT+IHw6diZo6qF2AlRwMb35VVgohXIo8GCL44ILkPZIqS0+CBgoOpBMfnoWJ/gzLn9e5RgN/to6w==
X-Received: by 2002:a17:906:4796:b0:ace:5461:81dd with SMTP id a640c23a62f3a-ad218e4c509mr1228577066b.3.1747053481324;
        Mon, 12 May 2025 05:38:01 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 14:38:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] crypto: Add RSA support
To: Ross Lagerwall 
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: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
 <20250506143218.1782603-3-ross.lagerwall@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250506143218.1782603-3-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.05.2025 16:32, Ross Lagerwall wrote:
> In preparation for adding support for livepatch signing, add support for
> RSA crypto.

If this is needed just for live-patch, ...

> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
>  obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
>  obj-$(CONFIG_VM_EVENT) += mem_access.o
>  obj-y += memory.o
> +obj-y += mpi.o

... why would this be obj-y? Same for rsa.o further down.

> --- /dev/null
> +++ b/xen/common/mpi.c
> @@ -0,0 +1,1724 @@
> +/* mpi-pow.c  -  MPI functions

Nit: This doesn't match the filename.

> + *	Copyright (C) 1994, 1996, 1998, 2000 Free Software Foundation, Inc.
> + *
> + * This file is part of GnuPG.
> + *
> + * GnuPG is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * GnuPG is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
> + *
> + * Note: This code is heavily based on the GNU MP Library.
> + *	 Actually it's the same code with only minor changes in the
> + *	 way the data is stored; this is to support the abstraction
> + *	 of an optional secure memory allocation which may be used
> + *	 to avoid revealing of sensitive data due to paging etc.
> + *	 The GNU MP Library itself is published under the LGPL;
> + *	 however I decided to publish this code under the plain GPL.
> + *
> + * mpi.c code extracted from linux @ eef0df6a5953, lib/mpi

I fear this line would go unnoticed with future changes, and hence go stale
rather easily. Menioning the origin in just the commit message ought to be
sufficient.

Btw - how heavily did you need to adjust the code to pass our Eclair scan?
Depending on that I then might raise the question of converting to proper
Xen style (it currently isn't even proper Linux style, afaict).

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Please sort alphabetically. Same for the other new files.

> +#define MAX_EXTERN_MPI_BITS 16384
> +
> +/* Define it to a value which is good on most machines.
> + * tested 4, 16, 32 and 64, where 16 gave the best performance when
> + * checking a 768 and a 1024 bit ElGamal signature.
> + * (wk 22.12.97) */
> +#define KARATSUBA_THRESHOLD 16
> +
> +typedef mpi_limb_t *mpi_ptr_t;	/* pointer to a limb */
> +typedef int mpi_size_t;		/* (must be a signed type) */
> +
> +/* Copy N limbs from S to D.  */
> +#define MPN_COPY(d, s, n) \
> +	do {					\
> +		mpi_size_t _i;			\

With this and ...

> +		for (_i = 0; _i < (n); _i++)	\
> +			(d)[_i] = (s)[_i];	\
> +	} while (0)
> +
> +#define MPN_COPY_DECR(d, s, n) \
> +	do {					\
> +		mpi_size_t _i;			\

... this I wonder why ...

> +		for (_i = (n)-1; _i >= 0; _i--) \
> +			(d)[_i] = (s)[_i];	\
> +	} while (0)
> +
> +/* Zero N limbs at D */
> +#define MPN_ZERO(d, n) \
> +	do {					\
> +		int  _i;			\

... this is plain int. There are apparently many similar issue.

>[...]
> +leave:

Here and elsewhere - labels indented by at least one blank, please.

> --- /dev/null
> +++ b/xen/crypto/rsa.c
> @@ -0,0 +1,194 @@
> +/* rsa.c
> +
> +   The RSA publickey algorithm.
> +
> +   Copyright (C) 2001 Niels Möller
> +
> +   This file is part of GNU Nettle.
> +
> +   GNU Nettle is free software: you can redistribute it and/or
> +   modify it under the terms of either:
> +
> +     * the GNU Lesser General Public License as published by the Free
> +       Software Foundation; either version 3 of the License, or (at your
> +       option) any later version.
> +
> +   or
> +
> +     * the GNU General Public License as published by the Free
> +       Software Foundation; either version 2 of the License, or (at your
> +       option) any later version.
> +
> +   or both in parallel, as here.
> +
> +   GNU Nettle is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   General Public License for more details.
> +
> +   You should have received copies of the GNU General Public License and
> +   the GNU Lesser General Public License along with this program.  If
> +   not, see http://www.gnu.org/licenses/.
> +*/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +void rsa_public_key_init(struct rsa_public_key *key)
> +{
> +    key->n = NULL;
> +    key->e = NULL;
> +    key->size = 0;
> +}
> +
> +/*
> + * Computes the size, in octets, of the modulo. Returns 0 if the
> + * modulo is too small to be useful, or otherwise appears invalid.
> + */
> +static size_t rsa_check_size(MPI n)
> +{
> +    /* Round upwards */
> +    size_t size;
> +
> +    /* Even moduli are invalid */
> +    if ( mpi_test_bit(n, 0) == 0 )
> +        return 0;
> +
> +    size = (mpi_get_nbits(n) + 7) / 8;
> +
> +    if ( size < RSA_MINIMUM_N_OCTETS )
> +        return 0;
> +
> +    return size;
> +}
> +
> +int rsa_public_key_prepare(struct rsa_public_key *key)
> +{
> +    if ( !key->n || !key->e || key->size )
> +        return -EINVAL;
> +
> +    key->size = rsa_check_size(key->n);
> +
> +    return key->size > 0 ? 0 : -EINVAL;
> +}
> +
> +/*
> + * Formats the PKCS#1 padding, of the form
> + *
> + *   0x00 0x01 0xff ... 0xff 0x00 id ...digest...
> + *
> + * where the 0xff ... 0xff part consists of at least 8 octets. The
> + * total size equals the octet size of n.
> + */
> +static uint8_t *pkcs1_signature_prefix(unsigned int key_size, uint8_t *buffer,
> +                                       unsigned int id_size, const uint8_t *id,
> +                                       unsigned int digest_size)
> +{
> +    unsigned int j;
> +
> +    if ( key_size < 11 + id_size + digest_size )
> +        return NULL;
> +
> +    j = key_size - digest_size - id_size;
> +
> +    memcpy(buffer + j, id, id_size);
> +    buffer[0] = 0;
> +    buffer[1] = 1;
> +    buffer[j - 1] = 0;
> +
> +    ASSERT(j >= 11);
> +    memset(buffer + 2, 0xff, j - 3);
> +
> +    return buffer + j + id_size;
> +}
> +
> +/*
> + * From RFC 3447, Public-Key Cryptography Standards (PKCS) #1: RSA
> + * Cryptography Specifications Version 2.1.
> + *
> + *     id-sha256    OBJECT IDENTIFIER ::=
> + *       {joint-iso-itu-t(2) country(16) us(840) organization(1)
> + *         gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1}
> + */
> +static const uint8_t
> +sha256_prefix[] =
> +{
> +  /* 19 octets prefix, 32 octets hash, total 51 */
> +  0x30,      49, /* SEQUENCE */
> +    0x30,    13, /* SEQUENCE */
> +      0x06,   9, /* OBJECT IDENTIFIER */
> +        0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01,
> +      0x05,   0, /* NULL */
> +    0x04,    32  /* OCTET STRING */
> +      /* Here comes the raw hash value */
> +};
> +
> +static int pkcs1_rsa_sha256_encode(MPI *m, size_t key_size,
> +                                   struct sha2_256_state *hash)
> +{
> +    uint8_t *ptr;
> +    uint8_t *buf;
> +
> +    buf = xmalloc_bytes(key_size);
> +    if ( !buf )
> +        return -ENOMEM;
> +
> +    ptr = pkcs1_signature_prefix(key_size, buf,
> +                                 sizeof(sha256_prefix), sha256_prefix,
> +                                 SHA2_256_DIGEST_SIZE);
> +    if ( !ptr )
> +    {
> +        xfree(buf);
> +        return -EINVAL;
> +    }
> +
> +    sha2_256_final(hash, ptr);
> +    *m = mpi_read_raw_data(buf, key_size);
> +    xfree(buf);
> +    return 0;
> +}
> +
> +static int rsa_verify(const struct rsa_public_key *key, MPI m, MPI s)
> +{
> +    int ret;
> +    MPI m1;
> +
> +    /* (1) Validate 0 <= s < n */
> +    if ( mpi_cmp_ui(s, 0) < 0 || mpi_cmp(s, key->n) >= 0 )
> +        return -EINVAL;
> +
> +    m1 = mpi_alloc(key->size / BYTES_PER_MPI_LIMB);
> +    if ( !m1 )
> +        return -ENOMEM;
> +
> +    /* (2) m = s^e mod n */
> +    ret = mpi_powm(m1, s, key->e, key->n);
> +    if ( ret )
> +        goto out;
> +
> +    ret = mpi_cmp (m, m1) ? -EINVAL : 0;

You look to have striven to convert this file to Xen style; there's a stray
blank here, though.

> --- /dev/null
> +++ b/xen/include/xen/mpi.h
> @@ -0,0 +1,63 @@
> +/* mpi.h  -  Multi Precision Integers
> + *        Copyright (C) 1994, 1996, 1998, 1999,
> + *                    2000, 2001 Free Software Foundation, Inc.
> + *
> + * This file is part of GNUPG.
> + *
> + * GNUPG is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.

While this may want to remain, accompany it with an SPDX header? (Same
elsewhere perhaps.)

> + * GNUPG is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
> + *
> + * Note: This code is heavily based on the GNU MP Library.
> + *         Actually it's the same code with only minor changes in the
> + *         way the data is stored; this is to support the abstraction
> + *         of an optional secure memory allocation which may be used
> + *         to avoid revealing of sensitive data due to paging etc.
> + *         The GNU MP Library itself is published under the LGPL;
> + *         however I decided to publish this code under the plain GPL.
> + */
> +
> +#ifndef MPI_H
> +#define MPI_H

This imo wants at least a XEN_ prefix. Same in rsa.h.

> +#include 
> +
> +#define BYTES_PER_MPI_LIMB      (BITS_PER_LONG / 8)
> +#define BITS_PER_MPI_LIMB       BITS_PER_LONG
> +
> +typedef unsigned long int mpi_limb_t;
> +typedef signed long int mpi_limb_signed_t;
> +
> +struct mpi {
> +    int alloced;        /* array size (# of allocated limbs) */
> +    int nlimbs;         /* number of valid limbs */
> +    int nbits;          /* the real number of valid bits (info only) */

I understand the goal likely is to not meaningfully change the original, but
none of these look like they can hold negative values, and ...

> +    int sign;           /* indicates a negative number */

... this one looks like it's a boolean.

> +    unsigned flags;     /* bit 0: array must be allocated in secure memory space */

In Xen we use "unsigned int", not plain "unsigned".

> +    /* bit 1: not used */
> +    /* bit 2: the limb is a pointer to some m_alloced data */

I think these comments would better be padded to align with the earlier one.
The individual bits likely also want corresponding #define-s.

> --- /dev/null
> +++ b/xen/include/xen/rsa.h
> @@ -0,0 +1,72 @@
> +/* rsa.h
> +
> +   The RSA publickey algorithm.
> +
> +   Copyright (C) 2001, 2002 Niels Möller
> +
> +   This file is part of GNU Nettle.
> +
> +   GNU Nettle is free software: you can redistribute it and/or
> +   modify it under the terms of either:
> +
> +     * the GNU Lesser General Public License as published by the Free
> +       Software Foundation; either version 3 of the License, or (at your
> +       option) any later version.
> +
> +   or
> +
> +     * the GNU General Public License as published by the Free
> +       Software Foundation; either version 2 of the License, or (at your
> +       option) any later version.
> +
> +   or both in parallel, as here.
> +
> +   GNU Nettle is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   General Public License for more details.
> +
> +   You should have received copies of the GNU General Public License and
> +   the GNU Lesser General Public License along with this program.  If
> +   not, see http://www.gnu.org/licenses/.
> +*/
> + 
> +#ifndef RSA_H
> +#define RSA_H
> +
> +#include 
> +#include 

This isn't needed here, is it? All you need is ...

> +#include 
> +
> +/*
> + * This limit is somewhat arbitrary. Technically, the smallest modulo
> + * which makes sense at all is 15 = 3*5, phi(15) = 8, size 4 bits. But
> + * for ridiculously small keys, not all odd e are possible (e.g., for
> + * 5 bits, the only possible modulo is 3*7 = 21, phi(21) = 12, and e =
> + * 3 don't work). The smallest size that makes sense with pkcs#1, and
> + * which allows RSA encryption of one byte messages, is 12 octets, 89
> + * bits.
> + */
> +#define RSA_MINIMUM_N_OCTETS 12
> +#define RSA_MINIMUM_N_BITS (8 * RSA_MINIMUM_N_OCTETS - 7)
> +
> +struct rsa_public_key
> +{
> +    /*
> +     * Size of the modulo, in octets. This is also the size of all
> +     * signatures that are created or verified with this key.
> +     */
> +    size_t size;
> +    MPI n; /* Modulo */
> +    MPI e; /* Public exponent */
> +};
> +
> +void rsa_public_key_init(struct rsa_public_key *key);
> +
> +int rsa_public_key_prepare(struct rsa_public_key *key);
> +
> +int rsa_sha256_verify(const struct rsa_public_key *key,
> +                      struct sha2_256_state *hash,

... a forward decl of this type.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 12:41:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 12:41:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981405.1367797 (Exim 4.92)
	(envelope-from )
	id 1uESTP-0001ww-1k; Mon, 12 May 2025 12:41:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981405.1367797; Mon, 12 May 2025 12: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 1uESTO-0001wp-Ue; Mon, 12 May 2025 12:41:34 +0000
Received: by outflank-mailman (input) for mailman id 981405;
 Mon, 12 May 2025 12:41:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uESTO-0001wj-99
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 12:41:34 +0000
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com
 [2607:f8b0:4864:20::22c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6de9ea3f-2f2e-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 14:41:31 +0200 (CEST)
Received: by mail-oi1-x22c.google.com with SMTP id
 5614622812f47-3f6aa4b3a7fso1554297b6e.3
 for ; Mon, 12 May 2025 05:41: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" 
X-Inumbo-ID: 6de9ea3f-2f2e-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747053691; x=1747658491; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jowbBovZjboUOeAr5SXVNumRTZ5MQ3jW2MvxnJuwk6A=;
        b=fpRUh14QD5xymGz2/mhBqxX14ArjH6+bY7PX1fRpGQTB0oj/OeiAgX2gSOjG4CyoqT
         OQ/ep/ULeMMSwrPlTMzZ3vQLShKUG87G9NThHm9ESN8oOnypymKFGq6sPpGgunMC2fau
         sK0hw1liZwoJvo8r5rqP85OcskboPhQr/KA5c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747053691; x=1747658491;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jowbBovZjboUOeAr5SXVNumRTZ5MQ3jW2MvxnJuwk6A=;
        b=MGe/TGiJ4+TL3D+BZooWTCjcybmkdbm2aTUnfjOnk89ncQPIcY96Xmq8cAce7Zylxs
         FYHkcQWv/fCqlIqcvM2gYP+wm6Tt1zDXKR6O9e3uHaEAH2ExijPmNwGLDOlev7ZrnW/W
         FiZ8X7rOAlnKoFtFAgVkPgFRsbIaj7g6YBpnfMV46jDl9S6q+iUcllJTPw6qapA+u9CT
         lbk9F5K9a0PAiQwjHO6mxKJCtM905ApexJo8M3Gqf7QNdeK6SsktybAxTDLJYtsuFAGm
         fuVUkwI5h96lZPPURhnPFJvBokvfsvI89ZEqgmAKRzxxtgRhbWu3cLY0q0YHTAMEEuNM
         BcxA==
X-Forwarded-Encrypted: i=1; AJvYcCWk8zhyKdmTTxTi7nAU9rucSa+6BbplD2BzIXa/2QGjTfhmU2+BcypUgMpYgi9N1xkzyLOssRq1egw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyHL1xsAWoeF8/5zC8uxVusUTM2MCffsr2V0gnck9IMUe+V/bm4
	yhZvg7IVLYsigpVHDh6K20m4OHER7xIrM2Tu+N7PI2NBR1LeIkPQa+pTjvw02dJF/64gyRXeon/
	1KQ21sZxKeqfsIV9L+xpazkWVuijnVjZq72/Kyg==
X-Gm-Gg: ASbGncubEYtgLd7OSUEuSKhfjxAzIURKfVZLWdsJBpzekR3WDDH4TWN7/FyAcF32GAB
	lzV7GrPCGNTYum9kFjyLo8DPN9U+q0gGMRTQKBzZmvB0a5S4rtmYU7nQJ/ODK3VKHC18MgSUuLI
	LQgPDlO0KyjVLOejxlZMpP4VGbOO4B4ZSo6YwalX+en64=
X-Google-Smtp-Source: AGHT+IHJuYU4GWCYb0esf/RDBWCVFdj0eFAlhr8Gzpxu1dGOL26rzP9t3aMBooxYSYlxDlz93kIVDAfepRiWQYnbfPc=
X-Received: by 2002:a05:6808:1b0a:b0:400:fa6b:5dfb with SMTP id
 5614622812f47-4037fe93b20mr6667972b6e.36.1747053690828; Mon, 12 May 2025
 05:41:30 -0700 (PDT)
MIME-Version: 1.0
References: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
 
 <548430a5-fa4a-41d1-b5ba-ba45efa90bbc@suse.com> <7acc83a3-2b15-4557-b293-0832b35e3680@citrix.com>
In-Reply-To: <7acc83a3-2b15-4557-b293-0832b35e3680@citrix.com>
From: Frediano Ziglio 
Date: Mon, 12 May 2025 13:41:20 +0100
X-Gm-Features: AX0GCFu9FlRtyTOMs8PdFQD4NnGWSRpRRo2cJA3HB5U98u5m4CEpFbOkq3QSjn4
Message-ID: 
Subject: Re: [PATCH] xen: Use __auto_type
To: Andrew Cooper 
Cc: Jan Beulich , Xen-devel , 
	Anthony PERARD , Michal Orzel , 
	Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Roberto Bagnara , Nicola Vetrini , 
	"consulting @ bugseng . com" , Stefano Stabellini 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 12, 2025 at 1:09=E2=80=AFPM Andrew Cooper  wrote:
>
> On 12/05/2025 12:59 pm, Jan Beulich wrote:
> > On 05.05.2025 21:44, Stefano Stabellini wrote:
> >> On Mon, 5 May 2025, Andrew Cooper wrote:
> >>> In macros it is common to declare local variables using typeof(param)=
 in order
> >>> to ensure that side effects are only evaluated once.  A consequence o=
f this is
> >>> double textural expansion of the parameter, which can get out of hand=
 very
> >>> quickly with nested macros.
> >>>
> >>> A GCC extension, __auto_type, is now avaialble in the new toolchain b=
aseline
> >>> and avoids the double textural expansion.
> >> I think this is a good change
> > +1
>
> That looks like agreement.
>
> Now for the (new) controversial part.  Since sending this, Linux has
> decided to just #define auto __auto_type for C < 23, in order to start
> writing C23 compatible code from now.  It's more succinct, and has
> better longevity.
>
> We might want to consider the same, although it will introduce a new
> example of defining a keyword, which we'd have to call out in the
> MISRA/Eclair config.
>
> If we're going to do this, we should do it from the outset.
>
> Thoughts?
>
> ~Andrew
>

I vote for avoiding extensions when the same feature is implemented by
standard, so yes for using "auto".

Frediano


From xen-devel-bounces@lists.xenproject.org Mon May 12 12:50:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 12:50:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981413.1367806 (Exim 4.92)
	(envelope-from )
	id 1uESbh-0003T9-Qk; Mon, 12 May 2025 12:50:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981413.1367806; Mon, 12 May 2025 12:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uESbh-0003T2-O5; Mon, 12 May 2025 12:50:09 +0000
Received: by outflank-mailman (input) for mailman id 981413;
 Mon, 12 May 2025 12:50:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uESbf-0003Sw-VQ
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 12:50:07 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9f5d417a-2f2f-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 14:50:03 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad238c68b35so403770766b.1
 for ; Mon, 12 May 2025 05:50: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
 4fb4d7f45d1cf-5feadd3957csm861144a12.67.2025.05.12.05.50.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 05:50: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" 
X-Inumbo-ID: 9f5d417a-2f2f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747054203; x=1747659003; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=S0ioB1iR1WhfTmkMqK6KLIKAn8Qei79H7hXjbIZsKLQ=;
        b=exkJeA+o/DpeKRwpLAO1rPtES7x9YcmPG6dH244MQ+kVmu5My2SKditxrMdBcMcHaQ
         UtcExnP2l62X8tDwKH0+n/GQMBaJEXNkVQOhTxCWqQ4qO0/5tAJD05Bl0N4jNR2VOKk/
         f8ktjVrfWN8tEwMjPl39BiT4+n70Rs1x6SRwDv362ObVTgBEv3Nj91EeVe2pzlsxbF5T
         wEjogCxF3ok8LvVu6EYNIfhdMmCIlqRQ/Z0Ahi+/4yinITU+EQB0wi9m5NXByuAPUzUZ
         UOtiepolJY/e9oVRS8hcDipQARwHRrskyEe1jmaZXWCoC2Gxv4U6f6bq7HnQmzAqa8GC
         u/ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747054203; x=1747659003;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=S0ioB1iR1WhfTmkMqK6KLIKAn8Qei79H7hXjbIZsKLQ=;
        b=hh8wYmBf9IlPmKBTps9LN/jhG8TdDZaroTDXGSQVIMRvJ2fc086InZgY2L0y7sYrzU
         N6SQT/cj92ksV7T24918UxWoSk0vcU3mKhrhDMPa++EcDEYAAxlTyvGnKjcvwqJEqa7R
         CkKLw+Fg7pkD3mAbt6WZoZU3EGX27DnWFoj33zz0qSinzm5gMK/2o/F5d27DFFCbfzdV
         OSJ4u8FXbJIRXqkLg+WxZNPuFTI9yNuq/ypy3Hxrhy0cLlafv9WTKPJd8av0jIx1FFCz
         /gBPLEd/DI70ICnnp3f85/j+dgci+UeysVGwI/3Nr8g619VFfrBPhG6daWom8rj9Uohl
         xYqg==
X-Forwarded-Encrypted: i=1; AJvYcCWA2c5zwnrr++J2vc788ULZPLfps8FKcdEsGeGe8EwC26utHTjtoaVL0ae/ExjYUCYkrmp1xegb+gQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxVQYmyyeeC69SSx1hOk41zDLixpM6jmhjCayoW4njTwMQZauan
	xzNLmTFHLaFoygmF7n5PH/T0Qf8RHifDxaE/wdq4ue28mMP3iLhu3uLfbuXDUA==
X-Gm-Gg: ASbGnctgu63Y2DpdKAUOv4gUJ2ksh58Znb3t4Yu2I8mdg/YCBUV9tXRLizRxGQUBy9l
	ckgLY1R4Cs23tw4QONTWfCIHfLZp0xAA/dit5NWtL2uPsHG46dHt7kVwIwX4J3+pFcL+/+Zy1UH
	NtQyYAverfwdVN5U3ynoU4DLM3iYx8PZsXZhyGxYeKZq/qENOuP90KaB8gYrAKO+cnF919nUNcl
	eeOwlSR505OUw+C6IQldfpF0LQCB07wPIpzXPQPwZPjsJQNIgFVIHZuCmNU+rZRmLM70ym11His
	dfxAhZQeiBODZsMOl1C8GM2PNgAYfmY4mCe1yH99+bHQQzzQ7Rsn5waJSiyRmmtEVRsvTElitev
	fwJ+pI+Zo+A2C0Om8t70Q3sfsPgTsnVqGoZds
X-Google-Smtp-Source: AGHT+IGVbY5dubBblAP8L8MAyl12o4+2CKgR0f1CEHrXUUeHAOCdON8jlov9lv3EMiHcPzu4PdvX0w==
X-Received: by 2002:a17:907:8990:b0:ad2:2ba6:2012 with SMTP id a640c23a62f3a-ad22ba6342fmr857521766b.11.1747054203453;
        Mon, 12 May 2025 05:50:03 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 14:50:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] livepatch: Embed public key in Xen
To: Ross Lagerwall ,
 Kevin Lampis 
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: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
 <20250506143218.1782603-4-ross.lagerwall@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250506143218.1782603-4-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 16:32, Ross Lagerwall wrote:
> From: Kevin Lampis 
> 
> Make it possible to embed a public key in Xen to be used when verifying
> live patch payloads. Inclusion of the public key is optional.
> 
> To avoid needing to include a DER / X.509 parser in the hypervisor, the
> public key is unpacked at build time and included in a form that is
> convenient for the hypervisor to consume. This is different approach
> from that used by Linux which embeds the entire X.509 certificate and
> builds in a parser for it.
> 
> A suitable key can be created using openssl:
> 
> openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \
>     -sha256 -days 3650 -nodes \
>     -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
> openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out crypto/signing_key.pem

According to this the .pem file isn't really a source one; how does ...

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -481,6 +481,24 @@ config LIVEPATCH
>  
>  	  If unsure, say Y.
>  
> +config PAYLOAD_SIGNING
> +	bool "Verify signed LivePatch payloads"
> +	depends on LIVEPATCH
> +	select CRYPTO
> +	help
> +	  Verify signed LivePatch payloads using an RSA public key built
> +	  into the Xen hypervisor. Selecting this option requires a
> +	  public key in PEM format to be available for embedding during
> +	  the build.
> +
> +config PAYLOAD_SIG_KEY
> +	string "File name of payload signing public key"
> +	default "signing_key.pem"

... this work in an out-of-tree build?

> +	depends on PAYLOAD_SIGNING

As to the name of this: According to its description, it's signature
verification, not signing. I think this wants reflecting in the name.

> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -28,7 +28,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
>  obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
>  obj-$(CONFIG_VM_EVENT) += mem_access.o
>  obj-y += memory.o
> -obj-y += mpi.o
> +obj-$(CONFIG_PAYLOAD_SIGNING) += mpi.o

Looks like the Kconfig symbol then wants introducing in the earlier
patch, or as a prereq thereto.

> --- a/xen/common/livepatch.c
> +++ b/xen/common/livepatch.c
> @@ -11,6 +11,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -73,6 +75,12 @@ static struct livepatch_work livepatch_work;
>  static DEFINE_PER_CPU(bool, work_to_do);
>  static DEFINE_PER_CPU(struct tasklet, livepatch_tasklet);
>  
> +#ifdef CONFIG_PAYLOAD_SIGNING
> +/* The public key contained with Xen used to verify payload signatures. */
> +extern const uint8_t xen_livepatch_key_data[];

Iirc Misra demands that declarations appear in headers.

> +static struct rsa_public_key builtin_payload_key;
> +#endif
> +
>  static int get_name(const struct xen_livepatch_name *name, char *n)
>  {
>      if ( !name->size || name->size > XEN_LIVEPATCH_NAME_SIZE )
> @@ -2287,6 +2295,34 @@ static void cf_check livepatch_printall(unsigned char key)
>      spin_unlock(&payload_lock);
>  }
>  
> +#ifdef CONFIG_PAYLOAD_SIGNING

Nit: The #ifdef would better appear inside the function body, to
reduce redundancy.

> +static int __init load_builtin_payload_key(void)
> +{
> +    const uint8_t *ptr;
> +    uint32_t len;
> +
> +    rsa_public_key_init(&builtin_payload_key);
> +
> +    ptr = xen_livepatch_key_data;

This being the sole place where the array is used, ...

> @@ -2305,6 +2341,11 @@ static struct notifier_block cpu_nfb = {
>  static int __init cf_check livepatch_init(void)
>  {
>      unsigned int cpu;
> +    int err;
> +
> +    err = load_builtin_payload_key();
> +    if (err)

(Nit: style)

> --- a/xen/crypto/Makefile
> +++ b/xen/crypto/Makefile
> @@ -1,3 +1,15 @@
>  obj-y += rijndael.o
> -obj-y += rsa.o
> +obj-$(CONFIG_PAYLOAD_SIGNING) += rsa.o
>  obj-y += vmac.o
> +
> +obj-$(CONFIG_PAYLOAD_SIGNING) += builtin_payload_key.o
> +
> +ifeq ($(CONFIG_PAYLOAD_SIGNING),y)
> +key_path := $(srctree)/crypto/$(patsubst "%",%,$(CONFIG_PAYLOAD_SIG_KEY))
> +$(obj)/builtin_payload_key.bin: $(key_path) $(srctree)/tools/extract-key.py
> +	$(srctree)/tools/extract-key.py < $< > $@.new
> +	$(call move-if-changed,$@.new,$@)
> +
> +$(obj)/builtin_payload_key.S: $(srctree)/tools/binfile $(obj)/builtin_payload_key.bin FORCE
> +	$(call if_changed,binfile,$(obj)/builtin_payload_key.bin xen_livepatch_key_data)

... arrangements want making for the array to live ideally in .init.rodata,
but at least somewhere in .init.*. E.g. by passing -i to tools/binfile.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 13:00:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 13:00:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981426.1367818 (Exim 4.92)
	(envelope-from )
	id 1uESlb-0005Qd-SU; Mon, 12 May 2025 13:00:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981426.1367818; Mon, 12 May 2025 13: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 1uESlb-0005QW-O4; Mon, 12 May 2025 13:00:23 +0000
Received: by outflank-mailman (input) for mailman id 981426;
 Mon, 12 May 2025 13:00:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uESla-0005QQ-Fr
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 13:00:22 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0f478981-2f31-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 15:00:20 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ac3eb3fdd2eso815163866b.0
 for ; Mon, 12 May 2025 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
 a640c23a62f3a-ad2197bd4d3sm612394466b.132.2025.05.12.06.00.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 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" 
X-Inumbo-ID: 0f478981-2f31-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747054820; x=1747659620; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jo9IgKAX9RI6Gt2JpUdnx0f6/WDvpERGqs2A7RSta38=;
        b=Xy9Zekh440WoUNY0fTbkGimXitueHB8azHOoPlmjOgB73AotAmb/g8OXoTzrzzuqLs
         8cd2EhEFOf9c4d68nEAYGHhD7201+cFe+iVj2Vi3lg9ME4gVj8QxGjI33xxRvsrkqXNx
         12G7jrPdrTYXBBgyOlHaz7gMR5CIrnn3mWxv4iV+OYN/2UWdY3mFFNqLagYhT/FP4Pl7
         PG+ZM77uelXeymw07Vgd7WMqmGIPGTVcOZlxfrCv0WyMmIMUT4UqEx4wiQYc8vNSAoyx
         Mi3vrtNGmdY5u3Dy0eNN4Ui9qm8oBUWxF+r8BU5fB8ZHncQhJe9TuSq+Y01gEBDzz1lv
         Q0Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747054820; x=1747659620;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jo9IgKAX9RI6Gt2JpUdnx0f6/WDvpERGqs2A7RSta38=;
        b=M2rZkptOfEGkt48ldIn7jiufzuSGtkI0QZvOrchrfh/8n27iCW3Ho3jlMPe3C2zu9z
         4wCe7bq0w04FhuP3XBUpNpDrtKhvGD5wrPOGt2vMfLVOkfFQpF/bDvs5XTsrVUCfG+BQ
         0t1iBaE3CawpBm4/BrjlUVjEmPtD0ZFtvCyFsUOdI3gxSynsPF2TtkAYFwVB5GoLaG/E
         +AiMoVNH/OAXyxpGfFicrUYlKs8o5PfagMXhVgdYl4HXdBqB9lxokZOjPwcOVKj++x5T
         h5HQPgj8MjnoP9RZAYb4dJlShVv2Yoe964/RyvJkZagKX44bmUGc18smcukeXZRx2cqs
         QAow==
X-Gm-Message-State: AOJu0YzTypgMqflTCSrmrIpeSXHrjBEoEhq1fqukjppkeJS1+xM+efOD
	f7XeRgrl5LUtnGTJUHECYfUBAXdCGShzaQRC76y4zHiDKkUh2sGmavSeHJ18eQ==
X-Gm-Gg: ASbGncuaOtkUHTM9sv4GEfxU8dHIlPgdeJ547MrKcRxmR8pIZDaMNJ5LgUsRvVXstax
	cFQLISdSO/FmornPMKZUydqRU5wXO69wAuwbD5siSWa3evAQ2TC8JGRpgy+6R8cLiOojrRKsjSU
	xyxi4lc+RiTprBRAU+SsbNdDjufZF2B74KLEzWPAM79dvT5RT12EtPd+Rd0B0/2GVWsRhR8DgC0
	x6NV4SDtnMPMClX4z4+1xsgn1b24JvwQNElwJo8w6P22FmNNwOuYMazgtbcomUp9eG05iGVk9oy
	NFr/Uh/VNdRN0Kkd7EGUaW0zVAbraMsEyNgxIfX8koGERm523Py9I4rz/Cy99GaI970cEhUNInK
	GezkxRjPOheleFU4u43/mIttGFtw3pmQw1Ecq
X-Google-Smtp-Source: AGHT+IHU+M4bIUTMYDFmjS/Jo1QWuh2+ZV4wmuVeX0lI22uNsj1iBGXWatJplcZp7A6b4hUuhLh4Lg==
X-Received: by 2002:a17:906:9c8a:b0:ac7:805f:9056 with SMTP id a640c23a62f3a-ad21905690amr1142936466b.32.1747054819968;
        Mon, 12 May 2025 06:00:19 -0700 (PDT)
Message-ID: <35826c2a-4266-49d2-b1b8-1248aac227b5@suse.com>
Date: Mon, 12 May 2025 15:00:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Use __auto_type
To: Andrew Cooper 
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Roberto Bagnara ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" ,
 Stefano Stabellini 
References: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
 
 <548430a5-fa4a-41d1-b5ba-ba45efa90bbc@suse.com>
 <7acc83a3-2b15-4557-b293-0832b35e3680@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: <7acc83a3-2b15-4557-b293-0832b35e3680@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12.05.2025 14:09, Andrew Cooper wrote:
> On 12/05/2025 12:59 pm, Jan Beulich wrote:
>> On 05.05.2025 21:44, Stefano Stabellini wrote:
>>> On Mon, 5 May 2025, Andrew Cooper wrote:
>>>> In macros it is common to declare local variables using typeof(param) in order
>>>> to ensure that side effects are only evaluated once.  A consequence of this is
>>>> double textural expansion of the parameter, which can get out of hand very
>>>> quickly with nested macros.
>>>>
>>>> A GCC extension, __auto_type, is now avaialble in the new toolchain baseline
>>>> and avoids the double textural expansion.
>>> I think this is a good change
>> +1
> 
> That looks like agreement.
> 
> Now for the (new) controversial part.  Since sending this, Linux has
> decided to just #define auto __auto_type for C < 23, in order to start
> writing C23 compatible code from now.  It's more succinct, and has
> better longevity.
> 
> We might want to consider the same, although it will introduce a new
> example of defining a keyword, which we'd have to call out in the
> MISRA/Eclair config.

I'm not outright opposed, as I don't think we use "auto" with its
original semantics, but it feels somewhat odd.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 13:11:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 13:11:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981434.1367826 (Exim 4.92)
	(envelope-from )
	id 1uESwR-0007Y7-Q6; Mon, 12 May 2025 13:11:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981434.1367826; Mon, 12 May 2025 13:11: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 1uESwR-0007Y0-NA; Mon, 12 May 2025 13:11:35 +0000
Received: by outflank-mailman (input) for mailman id 981434;
 Mon, 12 May 2025 13:11:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uESwQ-0007Xu-Q6
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 13:11:34 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9f5f0279-2f32-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 15:11:31 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ace94273f0dso853073466b.3
 for ; Mon, 12 May 2025 06:11: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
 4fb4d7f45d1cf-5fd29f9fdc2sm2292434a12.4.2025.05.12.06.11.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 06:11: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" 
X-Inumbo-ID: 9f5f0279-2f32-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747055492; x=1747660292; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ri7MrhNgClldSHZwYBLId7hYhTsIsGemJo+9YJa1G7c=;
        b=DcEKC2mxV/QN8HwFT+vMJRYwOatQ9FeMO2oGLPV5mpEZQdSG6+Z7ehokN0Byg6oV37
         d+xqFRcaq7zb9Y6QBuztbLQK2CM58yQ5Guy8EuECvebUqbEpSbLmcpV0+cPC61LmJLh+
         pIhGGX1lpj+vWSZc37UbjRGd+fWgcmAxb7SypG1I4+b819+il46RKz2oJjZoXzV33V4M
         9KXNKBjP6ZlhyeH+QSxemc/V3JlNVup5eck5Lyul9jbApDDkXnclckCre7aNf/IyVwPu
         KSJpP8WT5xTXinPTq9KAMiMVpl3FggvXyqpVQEkzXzNpe3D6LK1R2wBk+TKGL9Ja9JQh
         tjtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747055492; x=1747660292;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ri7MrhNgClldSHZwYBLId7hYhTsIsGemJo+9YJa1G7c=;
        b=eQvyrHpigW3fZQBtNhIqAxV24WoIJVfuaQFeLP5sYFWJxA5nxdWZrkAfRh8UPzZloP
         GgW7NRorm6b6YUqDRRvST7vKCu8vCY79ZgJKC5yRbB7bFtEyZuE6jpqyNf8TRoMmJMhK
         iL1fa/dYNqgFKeB07gIoBPkXcir2NWtE/4gGkQBq40vVQaUEyaj1oR6Dqvn7E2cPjxBb
         jiEcLFSarJRcyfXgh1yMA2hCgFcMW+LFY5heIEvAuQ7ZgXGM1Vi3xnfIFgky15MdHD76
         qSGK5mRzAlUVN0tf9AXE2p8kPfkDe4e4QwQiVG74CAaTpGm2sl7LUVkFuvzdWKgkX/wG
         dciw==
X-Forwarded-Encrypted: i=1; AJvYcCWLag96GeD70Vtzal+RtlMoH/M2RGZZKSA1kZr0Dsc8sHV4vmNrXbH+F39nQx8QnCevx4+/ISuoaYE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwJgu8+lniMR9A+Fo3+meKNaFu/Os+rZkP3xtf4XA+e+20Kg7+N
	icHtmpd2dwnWnofbHeICxeLT8t6UqdXEizzJ19XaaBy9nrQJtWD0Iemo7bLHSg==
X-Gm-Gg: ASbGncuAw5+39e7En7KVIA3YtaCVSWCGgdsTxT7fab4gL50IYJYQQWKQuquxiNBiOd6
	Y9grbGLmhaOONaD/MGNJ/p6MdS75XuiT0IVB/ncl9CMpjbpxtAtOfb1gQEXMk0dqqt02AiStpt7
	WOD21n/MeRgHhyAOeIf1D2vXZcaEimvZ/HvPBeJQbj4MXsgEe5XVqKB6MxamFc8XV2OhwesmvPC
	9vsLuheCUXfs9bICMYi+VMdpuDhKwa5lyF6pkaq8T3N9Ohe6SACwgCZr3hQdj1oAVdYVbw8Hcp6
	9JHqhj4gz8SrNf+BtoS8FlQo505w5aZR4mHAeyF2T+UQ6BDY/PwMqAigSZDuVWn4Zggb7ZmBWB6
	6Ys33feyPS7JFBJhyu6/6k7swmM8mqW+iVZUe
X-Google-Smtp-Source: AGHT+IFZEQllPc9mbdtmDR6Mvlca7IMg4bvgILHGwdaHdPdkktiW14Ee4dWrBtjQnppncRYj0f0VGA==
X-Received: by 2002:a17:906:f80f:b0:ad2:238e:4a1b with SMTP id a640c23a62f3a-ad2238e4b77mr980151266b.15.1747055492045;
        Mon, 12 May 2025 06:11:32 -0700 (PDT)
Message-ID: <71bdba1f-8e2a-4335-8302-b14fd1dcfe7a@suse.com>
Date: Mon, 12 May 2025 15:11:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v3 1/2] xen: add libafl-qemu fuzzer support
To: Volodymyr Babchuk 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Dario Faggioli , Juergen Gross ,
 George Dunlap ,
 "xen-devel@lists.xenproject.org" 
References: <20250507095338.735228-1-volodymyr_babchuk@epam.com>
 <20250507095338.735228-2-volodymyr_babchuk@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: <20250507095338.735228-2-volodymyr_babchuk@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.05.2025 11:53, Volodymyr Babchuk wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -78,6 +78,7 @@ extra-y := symbols-dummy.o
>  obj-$(CONFIG_COVERAGE) += coverage/
>  obj-y += sched/
>  obj-$(CONFIG_UBSAN) += ubsan/
> +obj-$(CONFIG_FUZZER_LIBAFL_QEMU) += libafl-qemu.o

This ought to move up into the list of (mostly?) sorted object files.

> --- /dev/null
> +++ b/xen/common/libafl-qemu.c
> @@ -0,0 +1,80 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> +  This file is based on libafl_qemu_impl.h, libafl_qemu_qemu_arch.h
> +  and libafl_qemu_defs.h from LibAFL project.
> +*/
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Generates sync exit functions */
> +LIBAFL_DEFINE_FUNCTIONS(sync_exit, LIBAFL_SYNC_EXIT_OPCODE)
> +
> +    void libafl_qemu_end(enum LibaflQemuEndStatus status)
> +{
> +    _libafl_sync_exit_call1(LIBAFL_QEMU_COMMAND_END, status);
> +}
> +
> +void libafl_qemu_internal_error(void)
> +{
> +    _libafl_sync_exit_call0(LIBAFL_QEMU_COMMAND_INTERNAL_ERROR);
> +}
> +
> +void lqprintf(const char *fmt, ...)

At least this one looks as if it can be static. Anything which can be should
be made so.

> +{
> +    static DEFINE_SPINLOCK(lock);
> +    static char buffer[LIBAFL_QEMU_PRINTF_MAX_SIZE] = {0};
> +    va_list args;
> +    int res;
> +
> +    spin_lock(&lock);
> +
> +    va_start(args, fmt);
> +    res = vsnprintf(buffer, LIBAFL_QEMU_PRINTF_MAX_SIZE, fmt, args);
> +    va_end(args);
> +
> +    if ( res >= LIBAFL_QEMU_PRINTF_MAX_SIZE )
> +    {
> +        /* buffer is not big enough, either recompile the target with more */
> +        /* space or print less things */
> +        libafl_qemu_internal_error();
> +    }
> +
> +    _libafl_sync_exit_call2(LIBAFL_QEMU_COMMAND_LQPRINTF,
> +                            (libafl_word)buffer, res);
> +    spin_unlock(&lock);
> +}
> +
> +void libafl_qemu_trace_vaddr_range(libafl_word start,
> +                                   libafl_word end)
> +{
> +    _libafl_sync_exit_call2(LIBAFL_QEMU_COMMAND_VADDR_FILTER_ALLOW, start, end);
> +}
> +
> +static int init_afl(void)
> +{
> +    vaddr_t xen_text_start = (vaddr_t)_stext;
> +    vaddr_t xen_text_end = (vaddr_t)_etext;
> +
> +    lqprintf("Telling AFL about code section: %lx - %lx\n", xen_text_start,
> +             xen_text_end);
> +
> +    libafl_qemu_trace_vaddr_range(xen_text_start, xen_text_end);
> +
> +    return 0;
> +}
> +
> +__initcall(init_afl);

Please omit the blank line ahead of the __initcall() if that immediately
follows the respective function.

> --- /dev/null
> +++ b/xen/include/xen/libafl-qemu.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: MIT */
> +#ifndef __XEN_LIBAFL_QEMU_H
> +#define __XEN_LIBAFL_QEMU_H
> +
> +#include 
> +#define LIBAFL_QEMU_PRINTF_MAX_SIZE 4096
> +
> +#define LIBAFL_STRINGIFY(s) #s
> +#define XSTRINGIFY(s) LIBAFL_STRINGIFY(s)

We have STR() (and stringify()) - why would we need yet another macro?

> +#define LIBAFL_SYNC_EXIT_OPCODE 0x66f23a0f
> +
> +typedef enum LibaflQemuCommand
> +{
> +  LIBAFL_QEMU_COMMAND_START_VIRT = 0,
> +  LIBAFL_QEMU_COMMAND_START_PHYS = 1,
> +  LIBAFL_QEMU_COMMAND_INPUT_VIRT = 2,
> +  LIBAFL_QEMU_COMMAND_INPUT_PHYS = 3,
> +  LIBAFL_QEMU_COMMAND_END = 4,
> +  LIBAFL_QEMU_COMMAND_SAVE = 5,
> +  LIBAFL_QEMU_COMMAND_LOAD = 6,
> +  LIBAFL_QEMU_COMMAND_VERSION = 7,
> +  LIBAFL_QEMU_COMMAND_VADDR_FILTER_ALLOW = 8,
> +  LIBAFL_QEMU_COMMAND_INTERNAL_ERROR = 9,
> +  LIBAFL_QEMU_COMMAND_LQPRINTF = 10,
> +  LIBAFL_QEMU_COMMAND_TEST = 11,
> +} LibaflExit;
> +
> +typedef uint64_t libafl_word;

Looking at its uses, this rather wants to be unsigned long as it seems.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 13:16:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 13:16:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981443.1367837 (Exim 4.92)
	(envelope-from )
	id 1uET1G-00087d-Bp; Mon, 12 May 2025 13:16:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981443.1367837; Mon, 12 May 2025 13: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 1uET1G-00087W-8D; Mon, 12 May 2025 13:16:34 +0000
Received: by outflank-mailman (input) for mailman id 981443;
 Mon, 12 May 2025 13:16:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uET1F-00087Q-4B
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 13:16:33 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 51d25c7e-2f33-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 15:16:31 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5fbe7a65609so7228635a12.0
 for ; Mon, 12 May 2025 06:16: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
 a640c23a62f3a-ad2397f76e4sm421679966b.21.2025.05.12.06.16.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 06: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" 
X-Inumbo-ID: 51d25c7e-2f33-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747055791; x=1747660591; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=28ygnLv+YxBBbD/HB3d/4WbFbTv+JnAin77j7lJJENw=;
        b=BdF7NcmiFbI3/g3Wsk4Sf6oyssQfPrUNRqlU+q4MUMAkzV0iIO2LZAyFFR/Z2I65Oe
         8Btnc/pe3KYSvsMcYIdNZyIw0Pxi/yyZELz1VtYgihZxQIo2M+yUfJFu5wk193kYd2xK
         OpgMI0gUSX+tUGxiIQ7Iy0nwc5m8omwjIuLu8PSE0AcfX3ih8SbtZN4Xd9pCfE4Hv0hZ
         M1Ca+QmKkv4Gwi4jWs7veHzcRT4neh/iokQhJXqnL8aeuVpgticwHtGRIpXYPVy1rLgU
         mSajvD7Soe8E8PLwpbo7CzxeNlegtdbi5XnomhOBZPQmWJ9r6X0R0DJah7z+hFW8pboQ
         HOAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747055791; x=1747660591;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=28ygnLv+YxBBbD/HB3d/4WbFbTv+JnAin77j7lJJENw=;
        b=W0AwzHAcyVUf4rVTo+hnrukR/IMO88etQJ1vEqN0iKmS2oMGGHeIJDHLLFMdMrkwas
         6xYJIMQV6zySExOtJK2+BU6BOAzaA9xEWO+HFXLIAi5qrOkzMWAKcRmMDqgTp3nPWyqP
         /Hb+S8e5KiN1NhYV/lN0YX+IzxIBAqWcTLTPBFgrl8jVwqQqQMgLLn51XOl1c0UCKyBy
         CqJK1w7KfGwk8WfcwLYzAeiP0O8n3u34xW3itoMyHJPoOXIpPl3pTW2xbezO9vHL6Wfm
         zGTBuow7whcLos7B7xD4G85NCsfaYJelvfIBPyb3iHl+zgmRouMCv7K+OoSJls7LptBC
         sXyA==
X-Forwarded-Encrypted: i=1; AJvYcCUWlP1NRyQxZXLnU6RYC2GXbYcAPlTn+CGL+oID27IcybmIKTynlUSGgv4DCp3z3npFiPWnQlm/SVU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw2+ftFCiwGcehW7gpB0ObBkpi139urO7IWYcv+AlmnUQfTOPiY
	7dljRKCrS2o2k9ShUt6XQq+YeR+mAdZn4iP9wbC8mBuFoUbPsTdQMHpSQRi1zA==
X-Gm-Gg: ASbGncv/MBwckbS6A2LnJIcL+bx+CaaiCs0iK8Sd4Rb6oEKCkY7PlGWsFA23e7RYFL5
	gnqr1Eney/iZLn4M16FV0fafe4EHI6hr7W7h+5Uyx0UNaU4PHIc95eeK8y+wugPcCrkKnfeJ6ay
	TWAgZyqIoHVgWnpw8YOClpM+4jGrT945Ni0gTEPzFUWl80iuWbPxQdNIO6EVrzT0th3qvbHTLOX
	0idW6JL7HEzX2xueLE1AcqnarP4aUdFi3R/fsjC4rSjPaPFpblG+B81P2VIbtiVAuq+cjjVup88
	FYYToX7+WpZh6j2MaRj48roqrPZ/ZYT+PpR+rIL/VXdjvKTzTr/vlnLipB2XeyTLhZhQq7gBwJY
	S7RPmRjtglOERx5d3bgvZU1GUwibxcS6NEm9D
X-Google-Smtp-Source: AGHT+IFEhzs69mAnj7zPtZ3ZzujnBV3aQ/mjNEvQMYSCvSM2uYnqlSvHO2e/v2hjK7VqE//jz5Q63A==
X-Received: by 2002:a17:907:84c:b0:ac6:fcdd:5a97 with SMTP id a640c23a62f3a-ad21914204dmr1288107366b.48.1747055790692;
        Mon, 12 May 2025 06:16:30 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 15:16:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] xen/elfstructs: Include xen/types.h
To: Andrew Cooper 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Volodymyr Babchuk ,
 Bertrand Marquis ,
 Oleksii Kurochko ,
 Shawn Anastasio ,
 Ross Lagerwall ,
 Xen-devel 
References: <20250509163212.2948359-1-andrew.cooper3@citrix.com>
 <20250509163212.2948359-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: <20250509163212.2948359-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 18:32, Andrew Cooper wrote:
> elfstructs.h needs the stdint.h types.  Two headers arrange this manually, but
> elf.h and livepatch.h do not, which breaks source files whose headers are
> properly sorted.
> 
> elfstructs.h is used by tools too, so use stdint directly outside of Xen.
> 
> Clean up trailing whitespace.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon May 12 13:21:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 13:21:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981451.1367847 (Exim 4.92)
	(envelope-from )
	id 1uET5l-0001QT-Re; Mon, 12 May 2025 13:21:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981451.1367847; Mon, 12 May 2025 13:21: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 1uET5l-0001QM-Oj; Mon, 12 May 2025 13:21:13 +0000
Received: by outflank-mailman (input) for mailman id 981451;
 Mon, 12 May 2025 13:21:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uET5k-0001QG-Kp
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 13:21:12 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f7b60d5f-2f33-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 15:21:09 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ad21cc2594eso469559166b.1
 for ; Mon, 12 May 2025 06:21: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
 a640c23a62f3a-ad240b9eef6sm355368766b.18.2025.05.12.06.21.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 06:21:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f7b60d5f-2f33-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747056069; x=1747660869; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8/Jdp6xh00TVYrcHdZBiDTzzdhUl51dq6C2/tTNi7/M=;
        b=axqpGMMgw93/mM1f66IANxHI4F0vyJbLU7JF68GH9JJAmRjkPZJM0oZwv0qEQU7eVj
         sLJ/F+MCM7gbTxy/lbeOtzPEsieXmy7Gt/0Iv4qKQED7bT80GxDr4azUdrTXsXDM52yt
         YfXc24RqcwKaWbu2TfHKawGNuFe0HflwiW17k/pLsLon+t1r9w8chga4wHy54o4RRID+
         upbSYG5RGjcW+mT9DdW+ggLmX43GJ8OghubTM/Y5WPjrrrjflfthwpDhsKcg6mbOqwTg
         7GJu1+1lByfOKDSKkPCO/cVDpYKSCFoqEWWQrh17j0WRQEk0qCeV+sKhuBfV5d6Xnu5t
         Pbyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747056069; x=1747660869;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8/Jdp6xh00TVYrcHdZBiDTzzdhUl51dq6C2/tTNi7/M=;
        b=Mgu+zCi84O0heFAvrV03OzC+trUoGR4TOrt7Q52Gfr+HoyzM37VkHmi5jnW+Ci6q05
         7NuctraIMoySd6TWIR53mkHv2+98/AQ11yE6g5DlUQlb1TNdywCiP7gkE8AiwxGzixCm
         Km24lcNRgGtf88oEE58C2LCmW/FS5BnbEimH53FcYpUp3l1tQZxE6RHHIxRhM5r0Wzx2
         bqF/uAaFDx+0njakLew/6MQArtVJLYO+ELjpK5JMpMv7rrdg97KrC/rhcfwBnx7pQ/NK
         nwFLmuICXfl49GXr0C3Hrmek0+aCf9Holkv5kBXkzLF5yRbCCRFdpsZVwGeWiySDekQ6
         dpEg==
X-Forwarded-Encrypted: i=1; AJvYcCWGne1ZdY1XZpK3V6Ujm6CkdGxbEE1TVaK+RlvtYcUQzYJWKPZdwQyXc8MkUK8EQlaoUNXYVkHqItg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxgbHC/Bh4qhz4tupO2gftHY1zhLGIUQLR6uXayrJOJVXXiUvmD
	qX6Gmr9rHGsuZ/oYXy6h+2jmXy9fl4Li6bEAQNACV+1K21RCHReTfsQcgYnR3A==
X-Gm-Gg: ASbGncu2uk+0mt5aArxN1I71XE6XI5fDV+p+okJaZdWuc3OS8uaQfu/0BdNBOGi3v6r
	nkgwPALZHJGQ0csXcwadTuj9xUnB2c9Opacxf0dGc4CoHG6zGgCFrRqfuUwZOr+XOqZ+HPBKazu
	bqHEaVAPmMXODgNIZnwQBAZYAaY93Vwp3kk3eqMzyHujTPBDK2Fgql0PbUVL9C8WAwWsYCcZLSL
	cxbp3zCEcdyp9ple6uZaWBBoGkCrAuofAFY5BySrmiCdeicGPG8VLBUE7SMGuRNDt/9220BjZZB
	Yv2EMsLRmh8jmvYP9viQcKicfnn0/ccgRaew+Cn6rPdjCNa+beWd/bEpK+rIIsjT1utFU5pFI/t
	Npq5f1sNK72xUf57gPF4N+CChQ/yZd3FQB1XxOm5GdG39PfE=
X-Google-Smtp-Source: AGHT+IGHi15OEk7tmogpsygRQCDXYrkbHMNo9o2DGJc8iLaPkyF9gX1MvGX/EAzyqhTJO8yhkqnaTA==
X-Received: by 2002:a17:907:9729:b0:ad2:53fc:a876 with SMTP id a640c23a62f3a-ad253fcad19mr398914766b.31.1747056068894;
        Mon, 12 May 2025 06:21:08 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 15:21:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/idt: Minor improvements to _update_gate_addr_lower()
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250512115821.3444375-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: <20250512115821.3444375-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.05.2025 13:58, Andrew Cooper wrote:
> --- a/xen/arch/x86/include/asm/idt.h
> +++ b/xen/arch/x86/include/asm/idt.h
> @@ -92,15 +92,16 @@ static inline void _set_gate_lower(idt_entry_t *gate, unsigned long type,
>   * Update the lower half handler of an IDT entry, without changing any other
>   * configuration.
>   */
> -static inline void _update_gate_addr_lower(idt_entry_t *gate, void *addr)
> +static inline void _update_gate_addr_lower(idt_entry_t *gate, void *_addr)

Considering comment and name of the function, ...

>  {
> +    unsigned long addr = (unsigned long)_addr;
> +    unsigned int addr1 = addr & 0xffff0000U; /* GCC force better codegen. */
>      idt_entry_t idte;
> -    idte.a = gate->a;
>  
> -    idte.b = ((unsigned long)(addr) >> 32);
> -    idte.a &= 0x0000FFFFFFFF0000ULL;
> -    idte.a |= (((unsigned long)(addr) & 0xFFFF0000UL) << 32) |
> -        ((unsigned long)(addr) & 0xFFFFUL);
> +    idte.b = addr >> 32;

... doesn't this line want dropping altogether? Or at best be an assertion?

Jan

> +    idte.a = gate->a & 0x0000ffffffff0000UL;
> +    idte.a |= (unsigned long)addr1 << 32;
> +    idte.a |= addr & 0xffff;
>  
>      _write_gate_lower(gate, &idte);
>  }



From xen-devel-bounces@lists.xenproject.org Mon May 12 13:23:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 13:23:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981462.1367857 (Exim 4.92)
	(envelope-from )
	id 1uET7n-0001zi-9P; Mon, 12 May 2025 13:23:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981462.1367857; Mon, 12 May 2025 13:23:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uET7n-0001zb-5j; Mon, 12 May 2025 13:23:19 +0000
Received: by outflank-mailman (input) for mailman id 981462;
 Mon, 12 May 2025 13:23:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uET7l-0001zV-Tk
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 13:23:17 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4306e0b9-2f34-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 15:23:15 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5fcf1dc8737so4600991a12.1
 for ; Mon, 12 May 2025 06:23: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
 4fb4d7f45d1cf-5fc9d700e7csm5629155a12.64.2025.05.12.06.23.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 06: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" 
X-Inumbo-ID: 4306e0b9-2f34-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747056195; x=1747660995; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=T6/9KfdoDtBR/pnkYhsv1uWvVd/ELl83YK4VN8D1KqY=;
        b=Ro0rWo712GXlRsSmuYmHFmQ/hM+lfq6xrHfW9iKdXWu0d/M5FQ31reiLNwo+234yAC
         tm6Kl08qk2uS3BO3ENNMl6nJJwmhwztaA9WS2Ob9zbYGwLGG3c16cxdtggSx3XX4uzWV
         q/5RRh5iQP4di0k8Jl3otUHPly2UM3OkfRKbWabAKcppZq//IqTpAzYhdiokMY6Kh7wa
         sPSwFgIag8/5eHae1FDdkj+MrL6DkYbJoiNcL4//9VnjW+eLMsha3qKDy3CEXZh1pZY7
         6cLJ67+QvxxQwP2cjihDm0nowHVflHjcQTdEVyGOzzB61x1Ms8lBwqbtCDW9TXH9mkIF
         EanQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747056195; x=1747660995;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=T6/9KfdoDtBR/pnkYhsv1uWvVd/ELl83YK4VN8D1KqY=;
        b=ldIECoR6Y6Omv/48lHu3h/jmNUg4HNpYrj98ExAXWuU01VGwFvS9cUBgKP4C8h4cKo
         zfifMZIyOZbRPs1el3dPn86xJx4hpm0BvyDY07t5mtorugKW5Dr2GYqi5H9hOBcH7fis
         n52KOAo9KHEtZOFrMibEOi8Fe6qh7dgBKY6vAkz41PMyA0dZNFzX5pdpPBr/KwWXYpfG
         LmuUfs2+ZBKoRlWVmDyWuB0TCIjue0tRugPU4Iyb5RCrtlVnfEBFJwoBSqdkHx78rp3G
         TSEhsAkBKfqxwG6Tjtc04y+Bi+X61heZoUPT1MhAOnw2JlrDEGi9+ROA2paTfHD+RCkI
         S0QQ==
X-Forwarded-Encrypted: i=1; AJvYcCVCL6d0Bqrh/18mxNDJZ7EyHCvZtbGltPXADyq5RQKlLxSLdOAMRNJLAZSIBhxdl/jZzUKOwF5FIME=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwqVMA2ku7M3mMXVl6aLGRHouSaKNItvwvjlkVU1Y4wSF77mslr
	Nqmj7fz9hOkgRE44F4OOp5yZdFNdkJUAzVASaDhtOAoM6Yvs0/rMlgmURpD6JQ==
X-Gm-Gg: ASbGncvuGmz2Kdmz01fi/rNaza3AJBS9jzY7k8XL23cFz//s8grHsLZf/T/Aq6ZDDbX
	T5rFqGFQTNqJ6xaOwmOhtLgLcbtPSrjq0QJLlKeFdRyThfrzx3r/su/Ta23Q+mob9Sx1UC0kKiL
	7gqZJE2S0CNGSAPSy74xSwyHtALabVJlJkk4WcCGenqZQ9BPnAMxxA5xRBLzGHeCAXazDt9vf8L
	XK3FTD/SYISc8FKnbC0vKNlZSXSgSO5AhWRgnAgdGZo7YOLsD0FOOHRQ69bSiTW6GQb4zKozOhI
	8Ats6SBRIlnEqXGkezc1n1VvZmK1ErguZUIyYsET70ZpDcxJZv2HoyoehFhmIqlz1yxJ+JxAUpL
	4RzuWtBPjhF1mv01l0i99jtmYMlPFWz5RfEg3
X-Google-Smtp-Source: AGHT+IH0/RBCLmYofkPGYSOzdt/Kr3Q5JAUYhGYBrca1+mpvJ1kGEZnVdD/JO2dj2+4dbRWmz5WJjQ==
X-Received: by 2002:a05:6402:5241:b0:5f6:59e5:5c6e with SMTP id 4fb4d7f45d1cf-5fca07e9956mr10913568a12.26.1747056195352;
        Mon, 12 May 2025 06:23:15 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 15:23:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/smp: Drop booting_cpu
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250512120015.3445217-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: <20250512120015.3445217-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.05.2025 14:00, Andrew Cooper wrote:
> Since commit 434596bbd44a ("x86/smpboot: Write the top-of-stack block in
> cpu_smpboot_alloc()"), smp_processor_id() is unconditionally usable on APs.
> Drop the global variable.
> 
> Also drop the parameter from start_secondary().  It was introduced as unused
> in commit e9ac3bbccab0 ("Move initial stack-pointer adjustment into assembly
> bootstrap code.") in 2005.  At the time, the caller was a shared codepath with
> __start_xen() with a parameter on the stack, but that never mattered for
> start_secondary() which ultimately reset_stack_and_jump()'s out of context.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon May 12 13:31:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 13:31:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981472.1367866 (Exim 4.92)
	(envelope-from )
	id 1uETFu-0003pX-12; Mon, 12 May 2025 13:31:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981472.1367866; Mon, 12 May 2025 13:31: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 1uETFt-0003pQ-UZ; Mon, 12 May 2025 13:31:41 +0000
Received: by outflank-mailman (input) for mailman id 981472;
 Mon, 12 May 2025 13:31:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uETFr-0003pK-UF
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 13:31:40 +0000
Received: from fhigh-b7-smtp.messagingengine.com
 (fhigh-b7-smtp.messagingengine.com [202.12.124.158])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6ce03bfa-2f35-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 15:31:36 +0200 (CEST)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfhigh.stl.internal (Postfix) with ESMTP id D455B254010B;
 Mon, 12 May 2025 09:31:34 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-04.internal (MEProxy); Mon, 12 May 2025 09:31:34 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 12 May 2025 09:31:33 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6ce03bfa-2f35-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1747056694;
	 x=1747143094; bh=2613pibrfGOHnaBEKtDJgenzrRFpzBW4dNT0wxAH9Dw=; b=
	EbK4ZMqGvrFQej4FWs1DPvFNIfljX97EPitjHFAERKsRKlKZXmJjiIClmtyMr/FC
	PoBMmIC7cpKJuSpTUHWtQnhEALWSwARRLqxWzMWIg7ifj6/drTe7tzP6wAb89BMs
	HnM6XPbcxR+nXeoBef/s1QNPRo3qGRnDVsMXBOCaxz2lYNJPjK+v4gVQ3nmtHlCR
	1U9c9QQ9GtoTPIO8J/jSCd2GSGTJB9LKx4DjryM8ErcVv2D822phBGPqO/OuRC4c
	y3saePk0N6puR3BJ6/zryeKDMw+c8/NpJFNgg331iPPBMTphHdVvV0lcEv+E8Nck
	77pPazUDOIl/bWuIQCWlbQ==
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=fm3; t=
	1747056694; x=1747143094; bh=2613pibrfGOHnaBEKtDJgenzrRFpzBW4dNT
	0wxAH9Dw=; b=hYEvoc3Ch/GMt+C13g8ZJ35igRPpo+vaTCnEIPTttQBu7vI0kGs
	kw+V0x+McjkjgxP2VLpxvbrgukytwfJs9ktPbqzPNuFM+iBeNJY1SJD96pbF8bGg
	jXLqufNmtXHPE+T+Cy5D1Ci5735iLsZacJ+8x/LV4q5cHbubPfAJAI6IJEa7QP6X
	yfXN+ZShDGSUX5Q5sYmvO7ELYwePgOqX5929fgY3OCC2lZedKbIkJv2vaoCR78zH
	nKi2mBtdCbndB3pa8J/lvQvQ5uNJ2AknPxaDFMRoUKSeZRc9IQyAlV2WFUfzesR1
	mGiGK1y8iRR1jSAn1tEK3DZoewwYCD19Pow==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftddufeekucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepveeujeetgeelleetudeuvefhtefgffejvedtvdfgieevheethe
    elgeeuledvjeevnecuffhomhgrihhnpehgihhtlhgrsgdrtghomhenucevlhhushhtvghr
    ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvh
    hishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedvpdhmohgu
    vgepshhmthhpohhuthdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg
    homhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggt
    thdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Mon, 12 May 2025 15:31:19 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="p2yanDuF2DT+GMpm"
Content-Disposition: inline
In-Reply-To: 


--p2yanDuF2DT+GMpm
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 May 2025 15:31:19 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner

On Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monn=C3=A9 wrote:
> On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > Hi,
> >=20
> > I wanted to post another revision of the series adding hw12 runner,
> > hoping that all known issues are fixed now, but unfortunately there is
> > still something broken. I've rebased my series on top of staging
> > (ed9488a0d) and got this pipeline:
> >=20
> > https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/18078191=
42
> > (note due to some added debugging, some tests are incorrectly marked as
> > success even if they failed...)
> >=20
> > 1. USB ethernet doesn't work on PVH dom0: https://gitlab.com/xen-projec=
t/people/marmarek/xen/-/jobs/9978694739
> > There supposed to be an USB ethernet device connected to the USB
> > controller at c3:00.4. In the PV dom0 case it's detected as:
> >=20
> >     [    3.911555] usb 7-1.4: new high-speed USB device number 3 using =
xhci_hcd
> >     [    4.004201] usb 7-1.4: New USB device found, idVendor=3D0bda, id=
Product=3D8153, bcdDevice=3D30.00
> >     [    4.004675] usb 7-1.4: New USB device strings: Mfr=3D1, Product=
=3D2, SerialNumber=3D6
> >     [    4.005079] usb 7-1.4: Product: USB 10/100/1000 LAN
> >     [    4.005349] usb 7-1.4: Manufacturer: Realtek
> >     [    4.005599] usb 7-1.4: SerialNumber: 684D35
> >=20
> > But it's not there on PVH. The USB controller itself is detected, just
> > not device(s) connected to it. This applies to other controllers too
> > (there should be about 3 or 4 other USB devices - none of them show up).
> >=20
> > 2. There is a bunch of "unhandled memory read" errors during PVH dom0
> > startup: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978=
694739
> >=20
> >     (XEN) [    4.026323] arch/x86/hvm/emulate.c:417:d0v0 unhandled memo=
ry read from 0xfedc0020 size 1
> >     (XEN) [    4.026789] arch/x86/hvm/emulate.c:417:d0v0 unhandled memo=
ry read from 0xfedc0021 size 1
> >     (XEN) [    4.027247] arch/x86/hvm/emulate.c:417:d0v0 unhandled memo=
ry read from 0xfedc0020 size 1
> >     (XEN) [    4.027671] arch/x86/hvm/emulate.c:417:d0v0 unhandled memo=
ry read from 0xfedc0021 size 1
> >     ...
> >=20
> > This repeats several times. Could be related to the USB issue above?
>=20
> Can you try with dom0=3Dpf-fixup?  Those unhandled accesses might be the
> cause of the USB issues.

It did got rid of those messages, but USB still doesn't work:
https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/10006580289

> > There is also, likely related:
> >=20
> >     (XEN) [    5.002036] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIR=
Q 2484: unsupported address 0
> >     (XEN) [    5.002365] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIR=
Q 2484: unsupported address 0
> >     (XEN) [    5.002693] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIR=
Q 2484: unsupported address 0
>=20
> Is this at shutdown? (doesn't look like by the timestamps).  There are
> cases where Linux zeroes the MSR entries while the capability is still
> enabled, and that results in those messages.  They are usually benign.

That's not shutdown. But also it's a different device than I care the
most, so I guess I can ignore it for now.

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--p2yanDuF2DT+GMpm
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgh+DcACgkQ24/THMrX
1ywaEggAhFREFFmDu2upT+LEJTp/+Df1BhPloGT7IyMhsSaJiifxSJil1VxQbxOn
3x1kBgTiZlZQU0S+WdGtPIKJkaHifJt7LVcdK8DRGdj8SOexzuDRd8Cs+8Zpgmcy
u2lJIZXY6Dpyt90AxzEdRIl7YXc9UPl6clpn9rNIUI6RvvPGXZfLcog0LkA+lOdu
4USMcatr5UYeP7/uyC/kqZs4gmUskPO4OWt9hNILTSuy5o/N0sawtda7aDEnN53G
PJG6HvEVUokDx2myTU4r4IVVluSd8Tu2ZV9Z/47VCSkOZgsL2j59Vw46SOa1WKj2
jiW5tE+ogyA2YfbgYQ/BdgTfVp6uag==
=sXE6
-----END PGP SIGNATURE-----

--p2yanDuF2DT+GMpm--


From xen-devel-bounces@lists.xenproject.org Mon May 12 13:34:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 13:34:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981480.1367876 (Exim 4.92)
	(envelope-from )
	id 1uETIF-0004Np-Dm; Mon, 12 May 2025 13:34:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981480.1367876; Mon, 12 May 2025 13:34: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 1uETIF-0004Ni-Ao; Mon, 12 May 2025 13:34:07 +0000
Received: by outflank-mailman (input) for mailman id 981480;
 Mon, 12 May 2025 13:34:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uETIE-0004NZ-VT
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 13:34:06 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c65485bf-2f35-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 15:34:05 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad23c20f977so297597466b.2
 for ; Mon, 12 May 2025 06:34: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
 a640c23a62f3a-ad23e8d4e88sm387769266b.99.2025.05.12.06.34.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 06:34: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" 
X-Inumbo-ID: c65485bf-2f35-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747056845; x=1747661645; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=J4EnwZzLfcv96qOvyBFBSfmU5guZudzTcnhcVL3gWkI=;
        b=LIoEfX6yFZIFvm8mrxMpPzLCPYj/WzxXlOQFaLeoq6ZQdWhpeWdD6Q5QADP/9ygrd3
         4HUpBPB2zJtv6lSRGeEu5Ub3bWN0M8IYx4ZGd67o3UqBphJ/3qVpR7DnICqUG3NBvRgM
         0li0CGNIChyUV2U5btOMW/MEw01I5HoXcHqBHkLBIKYSN/yvLJC5RIN3KvNHEpRQnkuS
         Qquh+UuIbQGXVEUeGI8TwgpGHwbe0RKZNxHYhzOVyD4CCfIU/2d0irAzK4dlOSjXpRNv
         xeNQefB1gBMUNvytW0zFxKGKa6vJ2uxXZ+jP43phM/D+6BulJh4AlkX6hg09NPYK/Mmz
         IgMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747056845; x=1747661645;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=J4EnwZzLfcv96qOvyBFBSfmU5guZudzTcnhcVL3gWkI=;
        b=L5yDEnhPUt/7SV5dQxhstApRdJIjwk3VlUQ1tuHO6pUrH5JVU2dHICCS+4b7J1Gy6v
         MlNSRtytjt74k6dCWzrskn8xjuwXvJCCaUuk1FKHU/BNAoMdRq9DnKqMCoYEyBR1X0Pt
         /ZXnpYWi49pUXbA0bBavmwAjEX/VRInUsg9I5rPr0EBmQMzvxtROR96/3A9iOg/uoQsF
         BpxRA0DVmMv+1DELR6pTysBtDfVrl0VFlqG1BODREKYIXnj/CDUZbv1xlB+vzq8fvRCg
         UPlPcupkJdFM6c2IA6mlMmXo+DTe5BQCGLQOCLLpkjJAjAnI7t3VK1A0l69KA5K0KVjZ
         2J5g==
X-Forwarded-Encrypted: i=1; AJvYcCWK1DEL74JzasGqRIkX9makqic6O4mHYVFqjVI0I1dIIgA3rB2+jf0YzhHVDHu2Ns51wtT6nGP3qS0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxBPQ1xNAKyoH7T4ZHMRIvNTZAShJqHpJOC9rYibmbxBI/Fk95W
	Y2Qav2hT+Et51hPhgn0WKbf4TdLItKnZY0c4BgOsJpDThyfkm7wWtfPL3fhElg==
X-Gm-Gg: ASbGncscnZZaoNd4+6vS+SBOILL2QsG7i+uyzBcVk0hhQD3vbPmIR+K0B0433b/1ufI
	+8fRLXJoyzKh7Ck6mlm6mPCqTZeVRMoBocajTIfRfgr6TaB5QhM7OxS0VlxCt+uVR0rpWYfYQ/f
	gS191nBPtSAV/uT1c/pPODGtCsqkWG+/MRDRs2YEwvh6j8A8kTAi66R0T0DOlqD2rKRQ3VzBkR6
	vztrjStqKZuihownj8tuPye8IORB8HHOpN0omzThoCfDopbqGwPKv49GOZQKFtTV2DcEVVOdcml
	6OFD6xXofmTttayjeePgjX3JOzPN3kiLrN5ZT8K0RmaUYAomMVVLP/vXYO+diZdYpD2wJxwhoN8
	352SSPE/Tl1D/cP297rN8BctOHDNzl1RcIMR+
X-Google-Smtp-Source: AGHT+IFxvl9xQWJenm01CS0uqYxAUHGrgGK1bQiEGWSHGb4P5dOovhuPkO4lYz8maBjfAl398CyBjA==
X-Received: by 2002:a17:907:c319:b0:ad2:595d:dd21 with SMTP id a640c23a62f3a-ad2595ddfcamr215965666b.60.1747056845126;
        Mon, 12 May 2025 06:34:05 -0700 (PDT)
Message-ID: <084a6583-a7c2-4f65-973f-4c403bb41263@suse.com>
Date: Mon, 12 May 2025 15:34:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v4] sbat: Add SBAT section to the Xen EFI binary
To: Gerald Elder-Vass 
Cc: marmarek@invisiblethingslab.com, dpsmith@apertussolutions.com,
 Frediano Ziglio ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250512103942.173136-1-gerald.elder-vass@cloud.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: <20250512103942.173136-1-gerald.elder-vass@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.05.2025 12:39, Gerald Elder-Vass wrote:
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -6,11 +6,19 @@ cmd_objcopy_o_ihex = $(OBJCOPY) -I ihex -O binary $< $@
>  $(obj)/%.o: $(src)/%.ihex FORCE
>  	$(call if_changed,objcopy_o_ihex)
>  
> +$(obj)/sbat.o: OBJCOPYFLAGS := -I binary -O elf64-x86-64 \
> +	--rename-section .data=.sbat,readonly,data,contents \
> +	--add-section .note.GNU-stack=/dev/null
> +$(obj)/sbat.o: $(src)/sbat.sbat FORCE
> +	$(call if_changed,objcopy)
> +
>  $(obj)/boot.init.o: $(obj)/buildid.o
>  
>  $(call cc-option-add,cflags-stack-boundary,CC,-mpreferred-stack-boundary=4)
>  $(addprefix $(obj)/,$(EFIOBJ-y) mbi2.init.o): CFLAGS_stack_boundary := $(cflags-stack-boundary)
>  
> +EFIOBJ-y += sbat.o
> +
>  obj-y := common-stub.o stub.o
>  obj-$(XEN_BUILD_EFI) := $(filter-out %.init.o,$(EFIOBJ-y))
>  obj-bin-$(XEN_BUILD_EFI) := $(filter %.init.o,$(EFIOBJ-y))
> --- /dev/null
> +++ b/xen/arch/x86/efi/sbat.sbat
> @@ -0,0 +1 @@
> +sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -343,6 +343,8 @@ SECTIONS
>      *(.reloc)
>      __base_relocs_end = .;
>    }
> +
> +  .sbat (NOLOAD) : { *(.sbat) }

If NOLOAD really took effect, this placement would certainly be okay. Since
it doesn't (from all I know), I'm unsure though of putting this after .reloc.
Then again you don't have "alloc" in the renamed section's flags, so maybe
all is indeed fine as you have it.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 13:48:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 13:48:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981492.1367887 (Exim 4.92)
	(envelope-from )
	id 1uETW9-0006JO-Lw; Mon, 12 May 2025 13:48:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981492.1367887; Mon, 12 May 2025 13:48: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 1uETW9-0006JG-H3; Mon, 12 May 2025 13:48:29 +0000
Received: by outflank-mailman (input) for mailman id 981492;
 Mon, 12 May 2025 13:48:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uETW8-0006J2-CJ
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 13:48:28 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c72b98ee-2f37-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 15:48:26 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a0bdcd7357so3043452f8f.1
 for ; Mon, 12 May 2025 06:48:26 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f58f2961sm12513417f8f.45.2025.05.12.06.48.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 06:48: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" 
X-Inumbo-ID: c72b98ee-2f37-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747057705; x=1747662505; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=467QYmVq6MMhKVSE/NeASZW0c+Ge2q/6FRFA94JDfFw=;
        b=B4TyFm2tjqw0jqRR73hqJfQZZWoFZEnZo+MgI9MRrPI39xvklcgkD9UwHPjYCbVnaI
         Q+6hwcTRwc9wV3IEXYgFBIpKhYdp/+iVxPa+VfIs38wgSbA59GIB9JLm4u691F6xdJ70
         ctteQxYbZwtcNulw0EyoDJUgrVyWKqEc3A+sw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747057705; x=1747662505;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=467QYmVq6MMhKVSE/NeASZW0c+Ge2q/6FRFA94JDfFw=;
        b=lRMVOqQfEuqwOak3M7pThohx07zc8f4+MIulzbz66kZ/gYWNNO582Ixgt5IhEVS3TT
         +o9P1S0rfVwXteivxrrgcrBakh0yMAVr1Rw5JNa6MIa4RtJ6kejXudlr8TcrYi13EMVM
         8LDnVYllYse/3Hf5wwSaYvg2gP/oR/9zv+ZllQftGfTDAV3aSSSG04PuLFuVmsuDhLLh
         FFCGvAZAQB10oi1O1Ldt+lzP5k+NvRjJ1+aHGMgHF+VAMRdIr5fi4AkjfChegRoNKhkf
         5ai1l3PCULTGBynlT+0rxI13FFA5xL0Ih1ITMLIu4pE4oAR+f25u2+x5vGwEK7TTaIRd
         8yYw==
X-Forwarded-Encrypted: i=1; AJvYcCX5CWwzmgIIu0Gsy2lbioLLHEi8dBsHQVNu2onPr8ZujRMFuwIrUYc76Liqbsv0KcSs6H8o1x01jCI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9EPmQLvcmN086w2OwwxoLiAOGMEuGKq83lUwOGJyNeY7lNevA
	NAisZdcIIKjFoQmYG4Vh/AQtWZ5iyWxgHdPR4LiXM0fq0ndpgrkY/6cE8zCaBMk=
X-Gm-Gg: ASbGnctDMqEFKBTVI6jGFinnUmywuZS1+XGvCg9IhY0D4mCuLYco80KRj7LxAUe/Tmu
	64bIh4DebSt/uju2E4NynHt5wM19Z7gmRwdnWSIL/cOMu7XNJu3r2GSuoRHf6FyAFsS+GwF3sMU
	WnEZqJ4AxOce4k34/6QgDcm87SxfSbaao7MmvEOnyQx5enJRn3IPaUTP2LbIWy3Qz9pNq0GQ8pb
	ISASrUTVNezgg0BdQ4QYUMnIepnnW3RsR1dRfcK6Gx/3FoSMES7J2H7kNYg+HP0DgFyvTz7cNSN
	4BO8lGv5Ip7KNHnu/MD3qpUPnkWxZyq3n+IAo0NsGmQkZMeGrEMr04zyJQct5SWlnA7QVLlUe+v
	4+NCs+02J6bAB/oVJ
X-Google-Smtp-Source: AGHT+IEzMHLH1f8ck8j+fXIgJfou97bpMdBCAbYmyAbTEL501SxMD395Ao29oXIhU9IYD3M0BTC5BA==
X-Received: by 2002:a05:6000:1ac6:b0:39e:dbee:f644 with SMTP id ffacd0b85a97d-3a1f64b5a71mr10093478f8f.46.1747057705631;
        Mon, 12 May 2025 06:48:25 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 14:48:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/idt: Minor improvements to _update_gate_addr_lower()
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250512115821.3444375-1-andrew.cooper3@citrix.com>
 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/05/2025 2:21 pm, Jan Beulich wrote:
> On 12.05.2025 13:58, Andrew Cooper wrote:
>> --- a/xen/arch/x86/include/asm/idt.h
>> +++ b/xen/arch/x86/include/asm/idt.h
>> @@ -92,15 +92,16 @@ static inline void _set_gate_lower(idt_entry_t *gate, unsigned long type,
>>   * Update the lower half handler of an IDT entry, without changing any other
>>   * configuration.
>>   */
>> -static inline void _update_gate_addr_lower(idt_entry_t *gate, void *addr)
>> +static inline void _update_gate_addr_lower(idt_entry_t *gate, void *_addr)
> Considering comment and name of the function, ...
>
>>  {
>> +    unsigned long addr = (unsigned long)_addr;
>> +    unsigned int addr1 = addr & 0xffff0000U; /* GCC force better codegen. */
>>      idt_entry_t idte;
>> -    idte.a = gate->a;
>>  
>> -    idte.b = ((unsigned long)(addr) >> 32);
>> -    idte.a &= 0x0000FFFFFFFF0000ULL;
>> -    idte.a |= (((unsigned long)(addr) & 0xFFFF0000UL) << 32) |
>> -        ((unsigned long)(addr) & 0xFFFFUL);
>> +    idte.b = addr >> 32;
> ... doesn't this line want dropping altogether? Or at best be an assertion?

That's what _write_gate_lower() does, hence why
_update_gate_addr_lower() needs to calculate .b.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 12 13:53:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 13:53:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981505.1367897 (Exim 4.92)
	(envelope-from )
	id 1uETaV-0008AY-8m; Mon, 12 May 2025 13:52:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981505.1367897; Mon, 12 May 2025 13:52: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 1uETaV-0008AR-5S; Mon, 12 May 2025 13:52:59 +0000
Received: by outflank-mailman (input) for mailman id 981505;
 Mon, 12 May 2025 13:52:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uETaT-0008AL-TO
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 13:52:57 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 68733490-2f38-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 15:52:56 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ad24b7e0331so234739866b.0
 for ; Mon, 12 May 2025 06: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
 a640c23a62f3a-ad23f91bc29sm372746666b.96.2025.05.12.06.52.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 06: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" 
X-Inumbo-ID: 68733490-2f38-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747057976; x=1747662776; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8/RLF51UJaNE46KzrtNql2Sht6Sf0h+ntpwex1lsjaw=;
        b=MO56Txc3y+e1KZbyeL4w70+PivRHRGjmGFUjvvOoLLwCNops2Ipz2W3KoHvzXStb4q
         ut788U2chErtL0JH5MvfCLvTJe6EFn0duTKu2L7oa81SL2D/1oo324W82+Qi6wfbYoLk
         6AbvD0xo4beIT6vWgjZrLftdZ2q/6m5iSU8c775p9nK6jpgk6reLJslx51zS3u95/IwU
         ttD4dWu/oEPZ1xbfms6Avp4vC25/yrfiadBXd2dVM3FiPOypQ5vVh0L9JdoH5xIzRuDe
         kucDUoPRxTf95idtwfb+onGLsDkgXCBH+P4Lc6UUJWbsTcqkY6zxxvihrLtbf4zE7Q3k
         yC1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747057976; x=1747662776;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8/RLF51UJaNE46KzrtNql2Sht6Sf0h+ntpwex1lsjaw=;
        b=Q7F51XrBmia19PlaAHw5cq5yFIxX4X9xZTvnbfIFYiGmznXRnNfpwOE5t/I2+Yc2+3
         FO7AOy92cQ1ZXCmlPLOvZXudXy2qAeXXFgrRS4b+Dlcy7XAqYm/4C6NHtOpLJxBOWfQt
         QDFgCwF77ky5jJszL6Ib+BAQWdN14sg6o1zwsZLk+K8pOJXAuzpeiqdI7dUi1sOYjjJE
         lTYM40aOQNBWReIVSQB/9pT3FjtAbB0VLIhT9W9uBaqea537GJZYAS3DlJu3oZNJcE+t
         gawZzS60j+K3TwuVuIOS8SGG6Hcjrzmg+ne6MZ4F/D1vPS8ie8JjL0ZLuDwG2AtARV4W
         DYFg==
X-Forwarded-Encrypted: i=1; AJvYcCVy0RNfFSdYKjKuHe0VdezGQtfUBTgsSHl5RcKMVbyblGcN9sr7Jua0MF6NYGr05HZftPiB2gJmn94=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzoop61B8Y7kw2SqxsFrqCrgEIFJ1v5clAkIrb+Vp24XJj+tVDx
	U65eAK1qQ9zffSkIuUPDQ30S5mctSgJEoSrKDIANOT8hiI3L2vQzF6wBBYA/nA==
X-Gm-Gg: ASbGncvEz8aV9Y/BeDIqSrdGH1PCDqxBz/yt/11jH3JJDiwlGU5HbWX5R7ZZX6l1ypk
	CbJ/sZOuZRXlQXCvv2oEff1uPbgmsDlVl9cVh5WeHRSRiM9doZO3XKh1lA5ht0dib4jaWGWQb0k
	8nzL3Y6WVMwaaWEH3ZlaUJrEDqc6eW3X/gQAgumyZ1aGbGrOy+sQF1UlBzMvvzky8+EQYJFV8YS
	VkpyHVY3BWJxijUQH4zZ68FyFhYUlxekTtHivfygobFY+Q2OZrP3UIJ9QyA6dlpK6GWkhsFf9ve
	SdBt2HBKbxAs+q4W5xa8gpOWzqVpa9UxZVg9/oWY4IIHVDm4lMrWZ8y2+tY/m7TINAZtOxTGspn
	R49p+wmrCOXEHuCCz8RrjCgUcmdMcVaMdAfcI
X-Google-Smtp-Source: AGHT+IHxXff6MJLgLPZ54zNa+aijA+HxXc0tRlIYu9AMGaodAOKw+tvZVLWpbbu8vZLdtwaOGdWb+w==
X-Received: by 2002:a17:907:72d0:b0:ace:6d5b:e785 with SMTP id a640c23a62f3a-ad2192b6b17mr1196407166b.47.1747057976081;
        Mon, 12 May 2025 06:52:56 -0700 (PDT)
Message-ID: <38d1e57b-4991-40f3-b826-935e3416bbdd@suse.com>
Date: Mon, 12 May 2025 15:52:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/idt: Minor improvements to _update_gate_addr_lower()
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250512115821.3444375-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.05.2025 15:48, Andrew Cooper wrote:
> On 12/05/2025 2:21 pm, Jan Beulich wrote:
>> On 12.05.2025 13:58, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/include/asm/idt.h
>>> +++ b/xen/arch/x86/include/asm/idt.h
>>> @@ -92,15 +92,16 @@ static inline void _set_gate_lower(idt_entry_t *gate, unsigned long type,
>>>   * Update the lower half handler of an IDT entry, without changing any other
>>>   * configuration.
>>>   */
>>> -static inline void _update_gate_addr_lower(idt_entry_t *gate, void *addr)
>>> +static inline void _update_gate_addr_lower(idt_entry_t *gate, void *_addr)
>> Considering comment and name of the function, ...
>>
>>>  {
>>> +    unsigned long addr = (unsigned long)_addr;
>>> +    unsigned int addr1 = addr & 0xffff0000U; /* GCC force better codegen. */
>>>      idt_entry_t idte;
>>> -    idte.a = gate->a;
>>>  
>>> -    idte.b = ((unsigned long)(addr) >> 32);
>>> -    idte.a &= 0x0000FFFFFFFF0000ULL;
>>> -    idte.a |= (((unsigned long)(addr) & 0xFFFF0000UL) << 32) |
>>> -        ((unsigned long)(addr) & 0xFFFFUL);
>>> +    idte.b = addr >> 32;
>> ... doesn't this line want dropping altogether? Or at best be an assertion?
> 
> That's what _write_gate_lower() does, hence why
> _update_gate_addr_lower() needs to calculate .b.

To satisfy that, idte.b = gate.b would be all we need (i.e. just like
_set_gate_lower() does). Or else I think the "lower" would need dropping from
comment and name here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:09:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:09:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981514.1367907 (Exim 4.92)
	(envelope-from )
	id 1uETqX-0001m3-Jp; Mon, 12 May 2025 14:09:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981514.1367907; Mon, 12 May 2025 14:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uETqX-0001lw-Gh; Mon, 12 May 2025 14:09:33 +0000
Received: by outflank-mailman (input) for mailman id 981514;
 Mon, 12 May 2025 14:09:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uETqW-0001lq-8P
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:09:32 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b8e966dc-2f3a-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 16:09:30 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad257009e81so159531266b.2
 for ; Mon, 12 May 2025 07:09: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
 a640c23a62f3a-ad2198505fdsm617151266b.168.2025.05.12.07.09.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 07:09: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" 
X-Inumbo-ID: b8e966dc-2f3a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747058970; x=1747663770; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=zouBe1hKJ+wNHpNuXJcq0KUvEJkKnc5aDdoaZSgHJ84=;
        b=J/9mwooGrBs0MHoQVCVkhCzN01n6pkA8HbkN9i/vYHWoYI6M5LFfvSAkl7YK7RRKHs
         Xa2Ti3Q6YZv7zusOhgZticacq93dNbhbBflVL6p3WfuzpihRHOvkPeSNrQbq4A+DyacJ
         H2ZmvPswRMp5zAe05IRdvFvWVc/V7mzliat0DMz3jBUbFOO0Zsi9fJ9/rPScGjJAHhtY
         9bwpo5aBjHEQSi4UH5dLodInG2xVW++vmVJ4ysuQL7wXjntdFKi0STowv03hJYb968rw
         03RO1lWYc6cPkbuamesD1ga1Y8xBPGfojfUifK61wynXx3yrHn8YXH4E4B3nvGiN6Kbn
         aebg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747058970; x=1747663770;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zouBe1hKJ+wNHpNuXJcq0KUvEJkKnc5aDdoaZSgHJ84=;
        b=NXcLLq0kgdW7U2qk6upDhzQTKSuIJ9a8W+tWnpKkxqDl0mTEa95SmaAMXvXHpJ2Dxv
         FfeTeOq8DA4NI2ifz2/1NjJNAxPC3ARI65R+xcEOUwAgmlnPoBfp+Bmc6C4RBLv2xx2G
         XMo/BGJd2yXSK0hTepFmEuMYV/M34WbKdI8TKNyp/mAvFgFjQ++3BW84J4cdc44PsGUa
         Wx8mpAG54e0LO71JDQPhUcnjQbNfGXdJXHr0TRrA8Dn6mzBSrwH1GeG2EC/7Rka1mpRM
         hS76JYmnZrw6Mn4SVXw6Hb2sDtPUp9SKnfmv7V2VLd7nNJ0z/Z2RQbegBTz8yZeutrdp
         eywQ==
X-Forwarded-Encrypted: i=1; AJvYcCWa201ZkFpizNweqnLyEdrK6zy76L0TELkgqAeqfJYSYqq81+dHQRh1kb2tvcMem+Q/m+r+ItYiTQM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx5ayMmPF4lAqX9GpCao4noLcmiMaVz0E+4L+v78xWL4YXSAsHu
	6E7GU7GlHvzfd5CAiZfxCHurHm1mhPuNWMspdiPzdzMB0rVDXH7Xo2AfwrJeMVh2EVIaoz2njhc
	=
X-Gm-Gg: ASbGncs1N4HpB5sZQ+tc9ErBJPo/AsF+CI63zsfdsEb2x2Dl/Qkj+EC5OpN2JoQ+cNM
	gH+JQBBrHQqdj7TO+zfDxxzmAJckq4OSPqjnBcLBQqTVz9Ca0Z11eOU0TF4K0f98HuZfTRPJiFr
	Pc2qm+n2z1uhT9yxuF70ARv9CukdoVCbDW7Eckz05llrRy/gQRnYgX/bV7X5+QuIuFPM2Pcns+s
	z8KKMgUUfdOEvkb6gRPBPKDvSmYYT7OX5du+Si4+82JQS8GV1LutyDFBzMrBa8+y9LidyuCKEfq
	/426ILptIwsBi7paT761GmB9VUpmE3X9wQLUBsp29KGeKyOmiDPWnebB+uEaKYX8zkSoVTZ0eq3
	rAsQYQsMLAdBGqpHhzS3gvTEhSQnBGF9yxEUm
X-Google-Smtp-Source: AGHT+IHadKJX9nJXfl5J887yW6e/hPewvrqQ/Pkd6Wxu+xOWdJbTUengzEU//H43pRYTwWpGseRusg==
X-Received: by 2002:a17:907:7b08:b0:ad2:2ff9:c912 with SMTP id a640c23a62f3a-ad22ff9dfebmr975288066b.17.1747058969947;
        Mon, 12 May 2025 07:09:29 -0700 (PDT)
Message-ID: <81a5182a-19aa-437d-b575-f3d8e45e4ca9@suse.com>
Date: Mon, 12 May 2025 16:09:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/9] x86/pv: fix MMUEXT_FLUSH_CACHE to flush all pCPU
 caches
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-2-roger.pau@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: <20250506083148.34963-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.05.2025 10:31, Roger Pau Monne wrote:
> The implementation of MMUEXT_FLUSH_CACHE is bogus, as it doesn't account to
> flush the cache of any previous pCPU where the current vCPU might have run,
> and hence is likely to not work as expected.
> 
> Fix this by resorting to use the same logic as MMUEXT_FLUSH_CACHE_GLOBAL,
> which will be correct in all cases.
> 
> Fixes: 534ffcb416bb ("Fix WBINVD by adding a new hypercall.")
> Signed-off-by: Roger Pau Monné 
> ---
> Alternatively, the hypercall could be made correct by keeping track of the
> pCPUs the vCPU has run on since the last cache flush.  That's however more
> work.  See later in the series.

Since, as iirc you indicated elsewhere, there's no actual user of this sub-op,
doing as you do here is likely good enough. Just one concern:

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3805,14 +3805,11 @@ long do_mmuext_op(
>              break;
>  
>          case MMUEXT_FLUSH_CACHE:
> -            if ( unlikely(currd != pg_owner) )
> -                rc = -EPERM;
> -            else if ( unlikely(!cache_flush_permitted(currd)) )
> -                rc = -EACCES;

This error code will change to ...

> -            else
> -                wbinvd();
> -            break;
> -
> +            /*
> +             * Dirty pCPU caches where the current vCPU has been scheduled are
> +             * not tracked, and hence we need to resort to a global cache
> +             * flush for correctness.
> +             */
>          case MMUEXT_FLUSH_CACHE_GLOBAL:
>              if ( unlikely(currd != pg_owner) )
>                  rc = -EPERM;

... -EINVAL (sitting out of context). If we accept any error code change here,
I think it wants to be the other way around, as EINVAL isn't quite appropriate
to signal !cache_flush_permitted() to the caller. With that extra adjustment:
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:12:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:12:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981520.1367917 (Exim 4.92)
	(envelope-from )
	id 1uETt0-0003YO-0E; Mon, 12 May 2025 14:12:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981520.1367917; Mon, 12 May 2025 14:12: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 1uETsz-0003YH-TZ; Mon, 12 May 2025 14:12:05 +0000
Received: by outflank-mailman (input) for mailman id 981520;
 Mon, 12 May 2025 14:12:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uETsz-0003YB-HU
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:12:05 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 13fc3cc9-2f3b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 16:12:03 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-54fcd7186dfso2597597e87.0
 for ; Mon, 12 May 2025 07:12: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
 a640c23a62f3a-ad2197bd2c0sm620776866b.130.2025.05.12.07.11.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 07:11: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" 
X-Inumbo-ID: 13fc3cc9-2f3b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747059123; x=1747663923; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=lWEcYkHkTxvckQRlU57M5o6O+Ermhnn7bjn+A02xAY8=;
        b=aR/VF3+VlFKMQvn4egzfTZfNykURy6UL6wTytGKw41oWhm4lEYnm3XDQeAVWk2tWcf
         GgLzVtzl6YO7IHhCNiseGylF4UYhtW6dlSiovl8TBCJkOhl3NrkaxBPil2a2v5xYVZV/
         RH4e6ySfOfBN3SwwHz9q+9RXRwXdIEMUEpTTK1TL8CpSbGMMxVRtcDSLYDHiWONPEpff
         j6JnoGFqau6dtejRtYwWzrrzDBmsrr90mZ8dTKK6/a8uQtYZh0F7YIlvM3n6KL64UNJD
         CNuceKR0Sm4Hl9QwFRHlfIhZWBl6Qr9gTaNnjcG0EOdUb2wtzwQf6Idpp26KIvuX58t+
         7p7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747059123; x=1747663923;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=lWEcYkHkTxvckQRlU57M5o6O+Ermhnn7bjn+A02xAY8=;
        b=t1UkmiUPNeYzdOQe1x5sYfwiggnbUwf/qdZwi31gmnLx3qbZkPNqOYk0yodlrozdLN
         8FHond6CeRD9H3REkg9HYXFdulKAdCFA+GYaOqjwJ3z7yWQuXpEyOpsUTVGrg7UpP9sX
         fpa+lYo5kr1tEaft7emtFkWI7ZlWfEGx4l9M4WQhrymZMJs1WtV+Ik7w/MUBEE/VGFcH
         JWCnarcVE4QNdQUsqXs/XXf3CfDdIzUZrBgdxvhL68ldRGb8UzN5tgDWhG8nw3XcHOre
         fcT3/anRezIcaE3HGoE1vNUr145oPIPgqljm82YE5+EKkkT+iN8asWgQadsHj4AF9EjH
         dRwQ==
X-Forwarded-Encrypted: i=1; AJvYcCW/DaR669SxzwziCEZJF4/pB7VsSxrbFAx1gE4b5j+FUf/SxAITJ9jZ/+cu5amQ2dRNXWPMTzkH5NE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwNA6LZLAgQQw8MLIttShFGggNAZy0j4IOU2WIFTz3qnF0qkQcT
	YFR3kVW0ufHyHc5Ip/DV4E62XqcGiyvIBfNeTa6kJ6g2jc2nzGvWqUFd87mZcxWaOy+9FXP6RF4
	=
X-Gm-Gg: ASbGncseP6CIWBHk94PAz3gQ0nxm8/VT/IK0MDE88czSZzlN3n934hAF80xSUvCGQSc
	at8iBUQQfiMtcnzk4NG76Pj91DYJVtWh51f01TrP/9nOh3yptsCrM9UBpX10P/AyTGOKoBsScAW
	m2Fh2B+jZ057WS6IiQ/H9lfuyJUL5PAoDAKt0hcT8QIuozRsG4csa3Hb7QykbA1QXQyakswNFOB
	rrykqQJ1gpDOCtzQIP1fmZLT/sAjMcGvcMf6cSv+r11EfaUO1HffnuLzdKEEtVcCxkqkNacb/yd
	kFEYtONWGeD43TlQEwJvApilqtPEbe4he8OZHIbENwdOD6eBTvCct9+t1uml+BFguXwySvjyY4C
	puNbJSlHCiA51hTwxJzD4tcLRKI9c8OnWMrTv
X-Google-Smtp-Source: AGHT+IEGyjYoIc8cSC1xhOIpQ9+Idd3o4q0Fy2ouqKpbgImZH7dZC899Y6zAu/SkrBwCLTlphqPQrg==
X-Received: by 2002:a17:907:1c08:b0:ad2:2ed0:74a9 with SMTP id a640c23a62f3a-ad22ed07544mr1013416166b.59.1747059112024;
        Mon, 12 May 2025 07:11:52 -0700 (PDT)
Message-ID: <66f5d1f8-7d46-43e8-989a-040c3b1022bc@suse.com>
Date: Mon, 12 May 2025 16:11:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/9] x86/pv: fix MMUEXT_FLUSH_CACHE to flush all pCPU
 caches
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-2-roger.pau@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: <20250506083148.34963-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 10:31, Roger Pau Monne wrote:
> The implementation of MMUEXT_FLUSH_CACHE is bogus, as it doesn't account to
> flush the cache of any previous pCPU where the current vCPU might have run,
> and hence is likely to not work as expected.
> 
> Fix this by resorting to use the same logic as MMUEXT_FLUSH_CACHE_GLOBAL,
> which will be correct in all cases.
> 
> Fixes: 534ffcb416bb ("Fix WBINVD by adding a new hypercall.")

Oh, and: I've looked up this hash, and found a "trivial merge". Are you sure
here?

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:20:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:20:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981530.1367927 (Exim 4.92)
	(envelope-from )
	id 1uEU0o-00054o-Ni; Mon, 12 May 2025 14:20:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981530.1367927; Mon, 12 May 2025 14:20:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEU0o-00054h-L6; Mon, 12 May 2025 14:20:10 +0000
Received: by outflank-mailman (input) for mailman id 981530;
 Mon, 12 May 2025 14:20:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEU0n-00054b-GQ
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:20:09 +0000
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com
 [2607:f8b0:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 33bf10fd-2f3c-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 16:20:07 +0200 (CEST)
Received: by mail-pf1-x434.google.com with SMTP id
 d2e1a72fcca58-7426c44e014so829096b3a.3
 for ; Mon, 12 May 2025 07:20:07 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-742377610a7sm6054992b3a.84.2025.05.12.07.20.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 07:20: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" 
X-Inumbo-ID: 33bf10fd-2f3c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747059605; x=1747664405; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Bn8IEfgic51WP+0k51mBI9b7UOmqTdbdkAuOzjnGVkc=;
        b=MbyydqVpShniGWlP4Z/gXqc4+3IKughx5fmKQ+UbmslOxOgSDYnHHS3k8Y+TjVNYo4
         IhRjN/ahxIQdwFY8rW76/9bt1+ylq34zCIq12ZcbNMrHzlixbAot3+8zv5TwY7/v37bB
         T3BeA3SMOxHP0e2fIBPU7ZZbCBBQpuHpQDsIk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747059605; x=1747664405;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Bn8IEfgic51WP+0k51mBI9b7UOmqTdbdkAuOzjnGVkc=;
        b=rFFn7REnqy3eupXoR1HJcnccBwIno6Yzlp1fv4v3EfmTwyK5NlHQY6zZriZ0aZ8u3B
         nmPc+B7OlIBI8qW8YET0aXbRd2fABtBmPFJw1X6rdYlppBtdD4ccp7zjK6jlAYQjKOuX
         /dc3UHdhtftKW9ynkuR6DeMOtsL+3BpfY5I9O0tz0Izxo2iSWErNZyPR4ug5u09pCOJo
         Rpr7FrVwCOqFsWvnc4UxqgYhtE+o59Y1Xyj+N/74uIBZvJRYFb1y/ZRsgnugZ5x3j6X6
         ebKGscfdyd5OYxK7wASZHpT9YXG5BYZ22enItcmpoN6iM5KorT9pV2mGB0sr0iWAM3Bq
         XZNg==
X-Gm-Message-State: AOJu0Yyo43pCHLR6PphRiEVTUFEmyeS6kMcgG676D2vioirmU4V/Ons4
	ezO+b07dxJTQtf85UJMRa6+mVGheSUlbq1BqfwiPXQ4IbXfpB9XeRfB754TRACU=
X-Gm-Gg: ASbGncva7GFAQQOjDplUFw2xRk7RECV5Ohu01dF2foTSsUxUvhh+cZQzUIAbdci8dXE
	lRtjn4bYIJYrz/Z6/RxZa6AEc2xBn2flpm58pGy1i8yqz9qKORHq4Aes0le5a/rwia2RJa+kZi3
	SX42tOtUv1520nTDO24gKD95edApCVN63f98FqM09I6eDTmeuhzY93hiMN09MIjhn5BuJcjyndj
	RE0FaljHSknjLo7ToAx2uP7lFNUxxhNlk7ZDQRv02D+Bs/I6IZQj6a/UNbQKxHZreHq+l1NnRxh
	qeRql5krwv8sucWueYpIbQJ0rn3XIhE7vCUOslohzeWttweAP9qltRI/
X-Google-Smtp-Source: AGHT+IEfnY1+wLmw/GCrFhIhgcGUoMjTdTbCu4G6P5PWxINX4XUojfai4QMD2pAtwfza5ECo1HzVXg==
X-Received: by 2002:a05:6a00:190f:b0:736:a6e0:e66d with SMTP id d2e1a72fcca58-7423bc58f29mr17474916b3a.6.1747059605148;
        Mon, 12 May 2025 07:20:05 -0700 (PDT)
Date: Mon, 12 May 2025 16:19:59 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner
Message-ID: 
References: 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Mon, May 12, 2025 at 03:31:19PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monné wrote:
> > On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-Górecki wrote:
> > > Hi,
> > > 
> > > I wanted to post another revision of the series adding hw12 runner,
> > > hoping that all known issues are fixed now, but unfortunately there is
> > > still something broken. I've rebased my series on top of staging
> > > (ed9488a0d) and got this pipeline:
> > > 
> > > https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1807819142
> > > (note due to some added debugging, some tests are incorrectly marked as
> > > success even if they failed...)
> > > 
> > > 1. USB ethernet doesn't work on PVH dom0: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739
> > > There supposed to be an USB ethernet device connected to the USB
> > > controller at c3:00.4. In the PV dom0 case it's detected as:
> > > 
> > >     [    3.911555] usb 7-1.4: new high-speed USB device number 3 using xhci_hcd
> > >     [    4.004201] usb 7-1.4: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
> > >     [    4.004675] usb 7-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
> > >     [    4.005079] usb 7-1.4: Product: USB 10/100/1000 LAN
> > >     [    4.005349] usb 7-1.4: Manufacturer: Realtek
> > >     [    4.005599] usb 7-1.4: SerialNumber: 684D35
> > > 
> > > But it's not there on PVH. The USB controller itself is detected, just
> > > not device(s) connected to it. This applies to other controllers too
> > > (there should be about 3 or 4 other USB devices - none of them show up).
> > > 
> > > 2. There is a bunch of "unhandled memory read" errors during PVH dom0
> > > startup: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739
> > > 
> > >     (XEN) [    4.026323] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0020 size 1
> > >     (XEN) [    4.026789] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0021 size 1
> > >     (XEN) [    4.027247] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0020 size 1
> > >     (XEN) [    4.027671] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0021 size 1
> > >     ...
> > > 
> > > This repeats several times. Could be related to the USB issue above?
> > 
> > Can you try with dom0=pf-fixup?  Those unhandled accesses might be the
> > cause of the USB issues.
> 
> It did got rid of those messages, but USB still doesn't work:
> https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/10006580289

Hm, is it possible that the usage of console=xhci is interfering with
USB devices?  Could you try to boot without console=xhci and see if
you can still reproduce the issue?  You will need the physical device
by your side, which I'm not sure it's possible.  Don't know if you
host those remotely somewhere.

> > > There is also, likely related:
> > > 
> > >     (XEN) [    5.002036] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 2484: unsupported address 0
> > >     (XEN) [    5.002365] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 2484: unsupported address 0
> > >     (XEN) [    5.002693] arch/x86/hvm/vmsi.c:845:d0v9 0000:c1:00.1: PIRQ 2484: unsupported address 0
> > 
> > Is this at shutdown? (doesn't look like by the timestamps).  There are
> > cases where Linux zeroes the MSR entries while the capability is still
> > enabled, and that results in those messages.  They are usually benign.
> 
> That's not shutdown. But also it's a different device than I care the
> most, so I guess I can ignore it for now.

Even if you see those messages the device might work OK - it's just
that at some point Linux has set the MSI address field as 0.  Xen
won't print anything when the address is switched from 0 (invalid) to
a valid value.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:20:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:20:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981533.1367937 (Exim 4.92)
	(envelope-from )
	id 1uEU1D-0005W3-34; Mon, 12 May 2025 14:20:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981533.1367937; Mon, 12 May 2025 14:20: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 1uEU1C-0005Vu-V2; Mon, 12 May 2025 14:20:34 +0000
Received: by outflank-mailman (input) for mailman id 981533;
 Mon, 12 May 2025 14:20:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEU1C-00054b-0U
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:20:34 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4341986e-2f3c-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 16:20:32 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ace333d5f7bso838962466b.3
 for ; Mon, 12 May 2025 07:20: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
 a640c23a62f3a-ad219322b57sm619814466b.41.2025.05.12.07.20.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 07:20:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4341986e-2f3c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747059632; x=1747664432; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6lAA44VGM+JLpAluZ7RHOVcz+IBGvEJntmd2pUdfrbE=;
        b=QLNnpvGPBf+g0ztHJjnK58tV1R5Spn89E2BcnY7JM+WnJWE3LWiZ0zT4owEWySo/xZ
         0dQme7FrooMcfDVpOzIYl1ZXH0n+s5zfmnjAAMoOdPZo8WUO002XJLyVxukTBuzPX4B6
         aHZdw3zFhnO1epGUS+E6vr2gB0bG5FCO/DYjegQeweljNe1Z9zOWAR4RPEz14QcgSn6l
         GxQwSzHawoAVjlfKGN1P9OfAC+5ZpAek9Jv9zytB5lkSbId2j53fdZ3PAF2E02/bnqAI
         5NTmIakbjasWHLrZ8KYh2qAKpkbD3g3bcy8ZPUBF1+GjXlTJHYDN+CATOA5uEx6PyV+h
         ZRbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747059632; x=1747664432;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6lAA44VGM+JLpAluZ7RHOVcz+IBGvEJntmd2pUdfrbE=;
        b=agX2UGKA6wld6oAoA09clU/3NVnH0hEf4fXfhNPpoOolFTppbpkMRY8/GpHqhoOFND
         JgwBeQze9S1Pwu8q3dkmVxOpy2hgMZaw/6KJERvUCZvrVZylC00a9GbMRYOmbPahGO6/
         jWOjWfB+g/mkz/JPTlO0qOzuue9cux8GpFnmwxpJVgWLUIeZaIk8SmX2ZCdOynxNX/DY
         QiHHO6ks4EAk7DE2wRD+rHseeN1f2JMf+UwXC+JmxpExfYjfJWF6vddNg0H2f3mtPXCM
         mC2ImSN7Td7ieI6Ci5pJa8FI2uVcikwleBCKR5lhVJCFtA8CzJZQEI8Lh6j5ypmlNG8/
         KIKw==
X-Forwarded-Encrypted: i=1; AJvYcCWBMR351HiPzOJBGiLAR+K0dDyvqV7KREhGGc0DQjxERewMP/CT5SaNEKi0iPYP1zNYo/pbLOaIm/w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzTPP0oIAK7VSdM6VlSKmFkCATdKrxHPuHO7C8tdEeOU0egn9bU
	BW8fzA06vG/eXkaTGfwCUA1DbcatQyRhKL5FFu6lxiKaitMAZApEz7e+s0f7uA==
X-Gm-Gg: ASbGncslRwdA7+ok2zyF+eQFDOTO6+GfFs1pc6xXx3mgAuOa51blfjdiVN81S0THSqN
	0lMQOlYWYc2Bi62WO2nYjOs22K76Hk9/GJhQ8dyZCeSJ9v+JsVziGy03LwdI83gLuMK/K+nvkCk
	9qY59ZX307iWoNkrdStCElTmteriDFXDUJ0yJyRrMsxj/54wcRB3sCk870IVjiF9MRRpwymbl4W
	c+QNJ7Kv+60O4gktWmD99Zqp9r2OdZSYKXhpUwhweXat5aAcuJq17RY9Omh8W4poH6XsNihnJfp
	Um2Lx6PTh7weXNJtxUMYU0lBhKLZ6tgScWbRzd6zdun414AbcYDOIdXadbF4W5QnvIOP1J02oJJ
	7WJW2Olx793MKoqEBrcVbh+K+Scqvvzta2PdS
X-Google-Smtp-Source: AGHT+IENM+5oz2Fjs+uB39H8u3KVEeSGEYIKgmxumu4bawQrnX80jMhT0Oqblo9pKULME3ztrhN3DQ==
X-Received: by 2002:a17:907:7d93:b0:ad2:4464:3278 with SMTP id a640c23a62f3a-ad2446436fcmr608313366b.4.1747059631799;
        Mon, 12 May 2025 07:20:31 -0700 (PDT)
Message-ID: <7102b188-7abe-47a5-b889-d11db3eda674@suse.com>
Date: Mon, 12 May 2025 16:20:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/9] x86/pv: fix emulation of wb{,no}invd to flush all
 pCPU caches
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-3-roger.pau@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: <20250506083148.34963-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 10:31, Roger Pau Monne wrote:
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -1193,17 +1193,18 @@ static int cf_check cache_op(
>  {
>      ASSERT(op == x86emul_wbinvd || op == x86emul_wbnoinvd);
>  
> -    /* Ignore the instruction if unprivileged. */
> -    if ( !cache_flush_permitted(current->domain) )
> +    /*
> +     * Ignore the instruction if domain doesn't have cache control.
> +     * Non-physdev domain attempted WBINVD; ignore for now since
> +     * newer linux uses this in some start-of-day timing loops.

That's very old comment, and hence I think "newer" isn't quite applicable
anymore. Either omit the word (if Linux still does so), or say "older"
instead? Also since you touch the comment, upper-casing the L in Linux
might be nice.

> +     */
> +    if ( cache_flush_permitted(current->domain) )
>          /*
> -         * Non-physdev domain attempted WBINVD; ignore for now since
> -         * newer linux uses this in some start-of-day timing loops.
> +         * Handle wbnoinvd as wbinvd, at the expense of higher cost.  Broadcast
> +         * the flush to all pCPUs, Xen doesn't track where the vCPU has ran
> +         * previously.
>           */
> -        ;
> -    else if ( op == x86emul_wbnoinvd /* && cpu_has_wbnoinvd */ )
> -        wbnoinvd();

So this goes away altogether, which isn't nice. It was "only" 2 years ago that
I posted a series where an additional ...

> -    else
> -        wbinvd();
> +        flush_all(FLUSH_CACHE);

... FLUSH_CACHE_WRITEBACK is introduced [1]. I really, really think that should
go in first, for it to then be used here. The more that it's the 1st patch in
that series.

Jan

[1] https://lists.xen.org/archives/html/xen-devel/2023-05/msg00242.html


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:23:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:23:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981552.1367946 (Exim 4.92)
	(envelope-from )
	id 1uEU4J-0006G2-Fo; Mon, 12 May 2025 14:23:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981552.1367946; Mon, 12 May 2025 14: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 1uEU4J-0006Fv-D1; Mon, 12 May 2025 14:23:47 +0000
Received: by outflank-mailman (input) for mailman id 981552;
 Mon, 12 May 2025 14:23:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEU4H-0006Fp-NG
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:23:45 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b368620e-2f3c-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 16:23:40 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ac3eb3fdd2eso836781166b.0
 for ; Mon, 12 May 2025 07:23:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad21988cb0asm625224766b.179.2025.05.12.07.23.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 07:23:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b368620e-2f3c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747059820; x=1747664620; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NQDyP2kSWo2UfqSGbt/i0FEyz8oaEXjDkLUyz/q94dA=;
        b=MSg9bDhr4XA8aLWCqbasQSkCOx7dVB8phvEwso1ZORoCGBYC5Cc63A7l7cKRvYNgXA
         s9Y7HHUzZ/hD2U0EyCYbHceeObc2VGv5mpywwMYeWQPWEi4eCXUNOQLorcrctt1tBWI5
         +W18ar3C1o9Proc0VZz0xXslh1Wy7tZ02Htax21kBYx6sv5pskbRIYRdQ0qWsibQnbma
         50fMa+fqZWX3bITUSFBTaaMVLxdN0hgbznZuvpNFuvu14SaQ5W9ZTLCEhVQK1HvG5QXy
         dzaB7vh5n9VGHvXDVuNvX8kg+IffZNRK5orr+D27L07R/QGB4rPlCz2tM2kpi3zlNiVq
         BI8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747059820; x=1747664620;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NQDyP2kSWo2UfqSGbt/i0FEyz8oaEXjDkLUyz/q94dA=;
        b=Z+FbmRPY8deEO2yB2LlpV2aV6QPG4c/pukhw/Gb87JF/4xlbz3vhkDxZROEQ0iKZqc
         4GupRVBXI9b7aTTLhoSeuIiWJXKRYq7NsMSQvfknI9/UqLNztw7geaUk4Vrn3cuwSqsM
         souBonhCshy5HrzCBfHlEdhKiTBs3EZcAzofUbEVjZS4pStmfsSBrJCwWwQIZ0Pl0kJD
         8qKlHabkumFuHjtsdQlSw0vSMX3F9EV+EaB+BjAGp3SO53dQvL24MZuj7fIyRJNq1SwR
         D6AQoEi+f2RCiLLYrzyFMbMm9Vif5SaCqIeFVSEfM0xP4/Uf4CsTFJpoBsR/qqiqa1Je
         YpGw==
X-Gm-Message-State: AOJu0YwR/XdHhQX3kxslUK0vQOFqolLjrLJUEEllKrMnB+FTD3cNxXYL
	OQsbhHf55MMDCTLmMRi4lOqxAwkLSz9fCOuEiPCUBNWUe7LX5zIcFt7GRXabww==
X-Gm-Gg: ASbGncu7tY0C7eFYph/7lmGkchrRS3CwGwNV/IJEenA55AySBvYRYxSPAI+F8jz+Kw9
	3GsOag4gu2iySrdQpfpDnRAPjuUOAtHTHcAGzqPE0R0OkO6QrsXKD1g4pnyomn9jTIjD9wXX/1X
	2j65Jav1jgg6JiPMje0qbjwFU9627DjWfbY9LGCqbWRM8ZY0r7e+jhaMxQD78KhzD7L1+1hzrTp
	RiyBUWeCMuigDlyAz51b9bTCRQLgEXitSw3XM3YXYadLv9QZzlp/Ef9uZgpcFV4QZc+ORdEmUfU
	vZiRU7yoDgRl376ljOxqJJ2/yrvG1oTNjCEHpSE9PKdVC53T43hDZXvaZcHNGEG2ZQq9iWp81t1
	aTljJjiPhX44aVLCWsHNKj2/eKd4NQCriweqRfMBfhHCiLmE=
X-Google-Smtp-Source: AGHT+IFzeh0QATr23pIa0raDM0tut3oc74y3QPVklKZocxuFpw6AwhZxT6TLwwOFJ+K67Th8LF1Wdw==
X-Received: by 2002:a17:907:c089:b0:ad2:44cd:d1a8 with SMTP id a640c23a62f3a-ad244cdd412mr624864466b.56.1747059819947;
        Mon, 12 May 2025 07:23:39 -0700 (PDT)
Message-ID: <90a2e51f-326c-4126-bfc6-e2cf40969b17@suse.com>
Date: Mon, 12 May 2025 16:23:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/9] xen/gnttab: limit cache flush operation to guests
 allowed cache control
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Anthony PERARD ,
 Michal Orzel ,
 Stefano Stabellini , Julien Grall 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-4-roger.pau@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

On 06.05.2025 12:40, Roger Pau Monné wrote:
> On Tue, May 06, 2025 at 11:15:09AM +0100, Julien Grall wrote:
>> On 06/05/2025 09:31, Roger Pau Monne wrote:
>>> Whether a domain is allowed to issue cache-control operations is reported
>>> by the cache_flush_permitted() check.  Introduce such check to limit the
>>> availability of GNTTABOP_cache_flush to only guests that are granted cache
>>> control.
>>
>> Can you outline what's the problem you are trying to solve? Asking, because
>> I don't see the problem of allowing any guest calling GNTTABOP_cache_flush
>> on Arm from any domains.
> 
> At least on x86 cache flush operations are restricted to guests for
> which cache_flush_permitted() returns true.  I've assumed the same
> would apply to Arm, since cache_flush_permitted() is also defined
> there.  If it's fine to issue cache flush operations from any guests
> on ARM, I suggest cache_flush_permitted() should unconditionally
> return true then.
> 
> The problem on x86 is that it's an expensive operation when done
> correctly, as it involves flushing the caches of all pCPUs where the
> vCPU has been scheduled.  Note however the implementation of
> GNTTABOP_cache_flush is incorrect on x86, and won't work as
> expected.

So instead of altering Arm behavior, how about rejecting GNTTABOP_cache_flush
on x86 then? It was introduced specifically for Arm, and it shouldn't have
gained any users (albeit of course we can't be sure of that).

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:24:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:24:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981559.1367957 (Exim 4.92)
	(envelope-from )
	id 1uEU5A-0006lB-NV; Mon, 12 May 2025 14:24:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981559.1367957; Mon, 12 May 2025 14:24:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEU5A-0006l4-Kl; Mon, 12 May 2025 14:24:40 +0000
Received: by outflank-mailman (input) for mailman id 981559;
 Mon, 12 May 2025 14:24:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEU59-0006ku-0g
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:24:39 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d5284b35-2f3c-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 16:24:37 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-acae7e7587dso701838466b.2
 for ; Mon, 12 May 2025 07:24:37 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad2198b68absm615254466b.182.2025.05.12.07.24.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 07: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" 
X-Inumbo-ID: d5284b35-2f3c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747059877; x=1747664677; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=eQBc8XzwFzdX27I59BZQsi2Cmrxq4cC4Tv+THghJyy0=;
        b=AghHX/XpG6R0wXhf2XCWR9kZ2As8yvOaCDF+B0sueHyZ2gKOtJOSmDW12IM526gKSG
         BO0gzvCuK/BRemrRzfDMO4cXNz9Y/d4ANMOwMJy84k+yE45LFc9cxSCNZbPcZKN2ISwo
         5FWOMbY2Umtktr0ttW2I8cF/I3ZwNz0VFKwnk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747059877; x=1747664677;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eQBc8XzwFzdX27I59BZQsi2Cmrxq4cC4Tv+THghJyy0=;
        b=iHQv/vqpvcT4oeW6vBQa+wnojhW/NY6NJ+XiafpKAK4uHdZcq8YRqLaNL/PeUcpWvH
         mEwebF6txrod5CWgRAqeFggUnFrTTIM7W3CB2FX7FtQy6qfoybSVqCKl7n/6zKHj9jOA
         Es01z8ioOxbzQGgoQJZUGFpwTvDWKVI+9POf46OPZxwJwKvHf1h567mCFh/KUMYJwUz2
         n2IKUcGCD/GJTlKdUCZxKcPLbj6to0Gro4IQicK3hNwKSA6eP22Qu0DwwOKj1IZjthcd
         1Us1miZ/wiM+D7G3d9lKfAsXg6CcmGfcfpOQw668ZKjSTH6RTKXrXsqp+uqcdyZzZcaq
         dj9Q==
X-Forwarded-Encrypted: i=1; AJvYcCWLLwHJz3rea0+lzGvSDaf//gciYA/f0A8KE5w2xPgMGevOc7SbTN2KcBRt0k+xid58D78fK/NmYkw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz0PTNSoTh+oibFKdya3YFEvO4xl1EBd20vT3n/jRMAD8kvh6xv
	sSkXX9aS3KidelUZOp1xjzQO6/PQELOWC+4JLkhX9vxpjy9IqJDhG0S7dG3/lRI=
X-Gm-Gg: ASbGncsl3zBOfNiWL48rlviT//YLRqecaztTzbqB8wborPU2rkR+JfcjwaddXhzFnQo
	848qx1wW1RvxVbes9Tbjztwdh6bviyunWtG3feSMtQvnplarpTxS7sdczNF2uIFkfeoNnREAmUx
	t4Z4ShUbF/m8vX6COHC1hhXtI1LGQE038fc4lKfBUmgEqVWQFZ1PssGGUawGf9LsacPa2/0/2jA
	R1uQgYIS7dwZ0XJOCyEnVZ8AHPHQl28mnhP4mU02J/9ZOyvxSpbLE5MJVY3YlGweC+DcjpBFdGw
	ICY88a090J+A6wtYsOH9Qh4s+YPeXNMxtwrJYMwxu3XCgIXijbPit8Wg
X-Google-Smtp-Source: AGHT+IG+kPfnwN5InV0/KtmER+TqBTRl8taDQ6oUhvcxCUXMALbAx+5JAXzdnXuah9sMbPo//ZKFug==
X-Received: by 2002:a17:907:944f:b0:ad2:42f3:86e0 with SMTP id a640c23a62f3a-ad242f389f9mr710138966b.27.1747059876586;
        Mon, 12 May 2025 07:24:36 -0700 (PDT)
Date: Mon, 12 May 2025 16:24:35 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/9] x86/pv: fix MMUEXT_FLUSH_CACHE to flush all pCPU
 caches
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-2-roger.pau@citrix.com>
 <66f5d1f8-7d46-43e8-989a-040c3b1022bc@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <66f5d1f8-7d46-43e8-989a-040c3b1022bc@suse.com>

On Mon, May 12, 2025 at 04:11:51PM +0200, Jan Beulich wrote:
> On 06.05.2025 10:31, Roger Pau Monne wrote:
> > The implementation of MMUEXT_FLUSH_CACHE is bogus, as it doesn't account to
> > flush the cache of any previous pCPU where the current vCPU might have run,
> > and hence is likely to not work as expected.
> > 
> > Fix this by resorting to use the same logic as MMUEXT_FLUSH_CACHE_GLOBAL,
> > which will be correct in all cases.
> > 
> > Fixes: 534ffcb416bb ("Fix WBINVD by adding a new hypercall.")
> 
> Oh, and: I've looked up this hash, and found a "trivial merge". Are you sure
> here?

Indeed, sorry.  I've made a mistake and copied the wrong hash, it
should be 8e90e37e6db8.  The change subject is correct however.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:27:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:27:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981568.1367967 (Exim 4.92)
	(envelope-from )
	id 1uEU7u-0007lN-3B; Mon, 12 May 2025 14:27:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981568.1367967; Mon, 12 May 2025 14:27: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 1uEU7u-0007lG-0O; Mon, 12 May 2025 14:27:30 +0000
Received: by outflank-mailman (input) for mailman id 981568;
 Mon, 12 May 2025 14:27:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEU7t-0007lA-3K
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:27:29 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 359a829c-2f3d-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 16:27:18 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5fd0d383b32so3012106a12.3
 for ; Mon, 12 May 2025 07:27: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
 4fb4d7f45d1cf-5fc9cc3f5c9sm5856742a12.28.2025.05.12.07.27.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 07:27: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" 
X-Inumbo-ID: 359a829c-2f3d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747060038; x=1747664838; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Qqmo5CL3c5gsz3mZVjw/Wmz019VO1n40VjC4cP+wD4E=;
        b=fPjhWWlsBC4pbF4VC+9xivrO8BidI9VuYg/iv563SqoQ6f+1+h84r5aoLRgM7k/jn5
         MzhPjv21eObIYDzaS1C1Kx8+Ju7C+Z+M1v9UtHNV1I0sMKtU1V9dhEBga0AY33Z86wAk
         eYXnF/0uEwqlEK24xCBfLk3M+Zperhu+DGQK25XLBClq1r5Ag12sk1wFXCnB4axzKJM4
         uhBN6wLfHMD6qHILxvdziBrPoT/v9WMATKItHB7YRg6Oyxz0ZnLfCUJHh293tIqweVvA
         xXxhRru0HvqKEd5uaWA0M3dcEVT50r7CE+tTiKzNJZJ1dEoVSDvJwyxLaer1yzo8nOU/
         gF+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747060038; x=1747664838;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Qqmo5CL3c5gsz3mZVjw/Wmz019VO1n40VjC4cP+wD4E=;
        b=p5Y30kfys8GtaJ3OcremQebVDMLy4PZcmSAsQ/jhj3MQf0y3syD6dLXf/MrbxNK/k1
         ytDmFBmNEk8pVqPv0hnN300hrGN5nP8Q3B3Zc3qUKSOoQbg2s15zkA5juxBKZ/LPvCix
         ELAL1clRlCTQNoX+/b1C55Bi5e2E2d2docqcpc6e+ADE0oDz3wgZmsM/m7V+w5OGIOd3
         gzj2dLHJtDIufoPLj+EYZ4HE2CHjK2lt6xf+ax8YK6hgFT/YTw5Dyx7ijKEWi+Ed2W01
         QKcJKTYOFl+G8yI7uebKG9U9YYdIY69w6VxJp43p1YIBspCoJQZgxaIpHy86fhSzvDe0
         n7Pg==
X-Forwarded-Encrypted: i=1; AJvYcCX/ySrvizhpzkyv7y30aqvGt/Jw1iBZyLoWwews6Dl5z1PlPgeVjctYgvNSgMARsZzQ9WGd4G2AxGA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyaQoE0QfLTxW9UsSgJ6kIrycrfNFui5MKdf0Gby7949DMG5mhv
	RUyYg2JbTVT6c8oT8pRLuidqGyQNAiLbio8iMjLw25vEhzWCCpiTXcLRctdIDA==
X-Gm-Gg: ASbGnctwfl087LE/aKbXJmKOG7fY4VnrcH3i6BCgQww2DDxp55D5lhkdCaCHv21zqWu
	lY4EiIyn30wbmKiL2qj9+S643CEoCxCiGq7GLDLa4P1eM+gadpKFKQKgiVcFmTS6dz80dPBPY+V
	7wnsaOqXz+VUpE+ivPTTzfjf6xoBLwHr8djekun8VAwhypPBJfDeK0A4fSLG0hb9uSPQf0g64bA
	+O4YRnoq8/ISX1NcXuQ/l2c4iBvpQwcf+Bu65rKqBtHOPrHZutyMyND7uKOowx3kDwCkHcl/PSI
	4/4uodJeA0GySzno84Rhmp29GHJ6C4s+xfHlBV4kJAysplmu4nXsXT6W32ZLifqi0kmGwt9YRrF
	ZRw/nu5hXpEXU1yfRYLzsTOh6IpEuZ4XjoswT
X-Google-Smtp-Source: AGHT+IGD8cYe56+34TdE6ssJ6nYBjI4mWbH6ySXD2OW6SgrMIGYSEtpUajRU6s8Rm7Z607SEy4PfFQ==
X-Received: by 2002:a05:6402:518d:b0:5e1:dac1:fa22 with SMTP id 4fb4d7f45d1cf-5fca080a47dmr10733342a12.21.1747060038421;
        Mon, 12 May 2025 07:27:18 -0700 (PDT)
Message-ID: <41f0e746-5200-417b-93b9-36b6d8b33d99@suse.com>
Date: Mon, 12 May 2025 16:27:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/9] x86/gnttab: do not implement GNTTABOP_cache_flush
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-5-roger.pau@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: <20250506083148.34963-5-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.05.2025 10:31, Roger Pau Monne wrote:
> The current underlying implementation of GNTTABOP_cache_flush on x86 won't
> work as expected.  The provided {clean,invalidate}_dcache_va_range()
> helpers only do a local pCPU cache flush, so the cache of previous pCPUs
> where the vCPU might have run are not flushed.
> 
> However instead of attempting to fix this, make the GNTTABOP_cache_flush
> operation only available to ARM.  There are no known users on x86, the
> implementation is broken, and other architectures don't have grant-table
> support yet.
> 
> With that operation not implemented on x86, the related
> {clean,invalidate}_dcache_va_range() helpers can also be removed.
> 
> Fixes: f62dc81c2df7 ("x86: introduce more cache maintenance operations")
> Fixes: 18e8d22fe750 ("introduce GNTTABOP_cache_flush")
> Signed-off-by: Roger Pau Monné 

Ah, here we go. I think this is what we want, without patch 3. It will want
to come with a CHANGELOG entry, though.

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -940,6 +940,7 @@ static void reduce_status_for_pin(struct domain *rd,
>          gnttab_clear_flags(rd, clear_flags, status);
>  }
>  
> +#ifdef CONFIG_ARM

Better introduce a new Kconfig setting (e.g. HAS_GRANT_CACHE_FLUSH) right
away, in case RISC-V and/or PPC would also want such behavior? 

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:27:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:27:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981570.1367977 (Exim 4.92)
	(envelope-from )
	id 1uEU8D-00088c-B7; Mon, 12 May 2025 14:27:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981570.1367977; Mon, 12 May 2025 14:27:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEU8D-00088V-7k; Mon, 12 May 2025 14:27:49 +0000
Received: by outflank-mailman (input) for mailman id 981570;
 Mon, 12 May 2025 14:27:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEU8C-0007lA-I3
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:27:48 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4652ccd7-2f3d-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 16:27:46 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ad216a5a59cso488494466b.3
 for ; Mon, 12 May 2025 07:27:47 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad2193495bdsm625970566b.70.2025.05.12.07.27.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 07:27: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" 
X-Inumbo-ID: 4652ccd7-2f3d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747060066; x=1747664866; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=or+r3MwJKV/Rk/FcE0NBVHWCY1awSXgGLUSkz63QNZ8=;
        b=Su/ll87rsNHFujnaCfdAS+edBqjsnibNMdHFRq56ekiPqll9Z3kW8DI1H6GvXD8uPk
         ZJA+9h6a6wL/qNpHcC8bzDozo9FS+iLuq9kQubZQnXRN0C9BJsfEu9huZD5eOUQgPcGy
         /EviF5au6Os0tAn/JtmGc8GIYP9zBoAHkPla0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747060066; x=1747664866;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=or+r3MwJKV/Rk/FcE0NBVHWCY1awSXgGLUSkz63QNZ8=;
        b=M5xRl7v+VFo1CpqYeIYZcN5msZQbuhfyPRMawVzbwqO9pUZ9TunbJT30Kn6RHR5t/g
         kfsiyv2VHIOqE6O4QIE/qJf30v6PfNuheZesCjS4zTccqzr64f1zoSGba1uADOW2lYsI
         ZzqS8o3OvC0fKTx3uehxUUBkr+5mexNW3/tgNpUwlMI34g2nR0qbf/E1KQo9Tr6L5iVo
         DtSVJ8m97fXwWixh42AtANncohWEPRMi2RFn+0oTfGzJVqgY7rjET9fM6j0bq3oI2sEp
         wNR8ytTz85ifXXvfekOelsxBx72KVbt1NikH1cmK19lXWurLhOUPopP14Se7VYBZN806
         aPfw==
X-Forwarded-Encrypted: i=1; AJvYcCXNAJP+4esMQrSIYqp4yktPisAJjnQfGVH0kN6FrInmknznPkd98oEbCCUI1f7BDwhsE4oONF/hAC4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJQEhiwhNvAz4PDU/W4njgQxHSyTLVaemU6rWiyxtnuMteEiOM
	y2yY64CLKUS3sC1OHajaBzoudWhAtp8hl1pZTr9Qryj6aUlwVZHOQPU5w05vT8g=
X-Gm-Gg: ASbGncud8IfoTL6MdeEX0QLiAw3J0/5oTb0Qjgkzefg5S3fCJbKCht2G2ELtne3xL6G
	qougy7bbLwv/gnpgntyBr8jzkiecHAhk+yTxTr+Ch2XRx7M2JCXNcfCsEqNw+BPVl4QMJZu+Pj8
	PPjUCypHMpft8BkYOFAcJEfovly2Fn5YTt6R1QBaxcS3Z1zWQvOBHWjNIubIV0zyIBGYouHUO8+
	fzROUtOvieCgM1aSIWYowZtImKfxKMZkLSDyVVsnOcqscLANpQiVZbyiU4z+diR7BWp+E5X2IsE
	Kuww77u2UVKP6L5AL0X4aAvjEU/fXSjh/ztMPqwzr66sBwHnMvf9sTeaPfxE69vd3c4=
X-Google-Smtp-Source: AGHT+IGzR/W524pfd6gfbIKUYGOHr6G0/tATie6nfnbiSf8zm37FFvLMhQTaF6MtTtR57N8lNKOMcw==
X-Received: by 2002:a17:907:7f21:b0:ac1:ea29:4e63 with SMTP id a640c23a62f3a-ad219002422mr1099979866b.26.1747060066465;
        Mon, 12 May 2025 07:27:46 -0700 (PDT)
Date: Mon, 12 May 2025 16:27:45 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/9] x86/pv: fix MMUEXT_FLUSH_CACHE to flush all pCPU
 caches
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-2-roger.pau@citrix.com>
 <81a5182a-19aa-437d-b575-f3d8e45e4ca9@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <81a5182a-19aa-437d-b575-f3d8e45e4ca9@suse.com>

On Mon, May 12, 2025 at 04:09:28PM +0200, Jan Beulich wrote:
> On 06.05.2025 10:31, Roger Pau Monne wrote:
> > The implementation of MMUEXT_FLUSH_CACHE is bogus, as it doesn't account to
> > flush the cache of any previous pCPU where the current vCPU might have run,
> > and hence is likely to not work as expected.
> > 
> > Fix this by resorting to use the same logic as MMUEXT_FLUSH_CACHE_GLOBAL,
> > which will be correct in all cases.
> > 
> > Fixes: 534ffcb416bb ("Fix WBINVD by adding a new hypercall.")
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Alternatively, the hypercall could be made correct by keeping track of the
> > pCPUs the vCPU has run on since the last cache flush.  That's however more
> > work.  See later in the series.
> 
> Since, as iirc you indicated elsewhere, there's no actual user of this sub-op,
> doing as you do here is likely good enough. Just one concern:
> 
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -3805,14 +3805,11 @@ long do_mmuext_op(
> >              break;
> >  
> >          case MMUEXT_FLUSH_CACHE:
> > -            if ( unlikely(currd != pg_owner) )
> > -                rc = -EPERM;
> > -            else if ( unlikely(!cache_flush_permitted(currd)) )
> > -                rc = -EACCES;
> 
> This error code will change to ...
> 
> > -            else
> > -                wbinvd();
> > -            break;
> > -
> > +            /*
> > +             * Dirty pCPU caches where the current vCPU has been scheduled are
> > +             * not tracked, and hence we need to resort to a global cache
> > +             * flush for correctness.
> > +             */
> >          case MMUEXT_FLUSH_CACHE_GLOBAL:
> >              if ( unlikely(currd != pg_owner) )
> >                  rc = -EPERM;
> 
> ... -EINVAL (sitting out of context). If we accept any error code change here,
> I think it wants to be the other way around, as EINVAL isn't quite appropriate
> to signal !cache_flush_permitted() to the caller. With that extra adjustment:
> Acked-by: Jan Beulich 

Oh, good catch.  I didn't realize the return code change.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:40:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:40:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981588.1367987 (Exim 4.92)
	(envelope-from )
	id 1uEUKd-00032W-G5; Mon, 12 May 2025 14:40:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981588.1367987; Mon, 12 May 2025 14:40: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 1uEUKd-00032P-CQ; Mon, 12 May 2025 14:40:39 +0000
Received: by outflank-mailman (input) for mailman id 981588;
 Mon, 12 May 2025 14:40:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEUKb-0002zR-Qw
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:40:38 +0000
Received: from fhigh-b8-smtp.messagingengine.com
 (fhigh-b8-smtp.messagingengine.com [202.12.124.159])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0f049c08-2f3f-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 16:40:34 +0200 (CEST)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 000B1254008E;
 Mon, 12 May 2025 10:40:32 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-11.internal (MEProxy); Mon, 12 May 2025 10:40:33 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 12 May 2025 10:40:31 -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" 
X-Inumbo-ID: 0f049c08-2f3f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1747060832;
	 x=1747147232; bh=NmRDmWTFg3ocMBQn/1j5ysNHailaYK3KynlSL0Gb9pw=; b=
	dwPj1iHZWC7ovuIkQ75P9Hngh3Zd1/RHLvKtfm7eW/8+W1P79XrpVS+sij3hCdC7
	X1ScGEigDoJLLSLq6uHS0zWDeTTojCLcwWTD9MGrLc1XPJAVPk7vITNvxyoy1hDi
	UaVFcVn+fOsVKgIx2JLygqE3sRCzVHGF0tUfflgNez+peumvIqnUkj9E9keWy2xJ
	cYkuk8y9NtoYglnRhG0vCKlxqqKwaBM1gn6eLJ1Uhfzw4dr44hafCK4yNhpiVEt+
	85G1J/EUxcDc8lWWRAVEo+iMXkPSUgYn64hFTvkR5GXAL7nY6FeoktbBene1JJf+
	MoPwypPYzP9CwPWWRk2cWQ==
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=fm3; t=
	1747060832; x=1747147232; bh=NmRDmWTFg3ocMBQn/1j5ysNHailaYK3Kynl
	SL0Gb9pw=; b=uuawL/7URmchijrmoE26AySGUXWqL5sUaGC3X4XozWSIj+y3qLB
	INivGbuOw5LJcWvexTjatLTXm0JTTV8eJFx6+KfPI02upp83m2sn0gOMfdTjmoTa
	qycTxUcUFLAB/xdgaxsHQPilpLJIp/KVFE3ZyOsTOBp+LYTd4T7jInz7bJT2oTYP
	w8EV8JxLmnKLCDJj3P3wh3eWjSfGoE7Rkkku6T0HkMa739htUVodB4XOZDyMYgzb
	VTBXOCLQA2url3caWrB1noOSi1pW9BFs6zA42fOcAWhnF70UdRVHT9n0Y6CSKpP3
	ptxHAJAJlRkiLjF6AjETv+q3sHwT0m/Mg5Q==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdduhedvucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepveeujeetgeelleetudeuvefhtefgffejvedtvdfgieevheethe
    elgeeuledvjeevnecuffhomhgrihhnpehgihhtlhgrsgdrtghomhenucevlhhushhtvghr
    ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvh
    hishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedvpdhmohgu
    vgepshhmthhpohhuthdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg
    homhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggt
    thdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Mon, 12 May 2025 16:40:29 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner
Message-ID: 
References: 
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="udp08jojfO2v1HwX"
Content-Disposition: inline
In-Reply-To: 


--udp08jojfO2v1HwX
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 May 2025 16:40:29 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner

On Mon, May 12, 2025 at 04:19:59PM +0200, Roger Pau Monn=C3=A9 wrote:
> On Mon, May 12, 2025 at 03:31:19PM +0200, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > On Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monn=C3=A9 wrote:
> > > On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-G=C3=B3r=
ecki wrote:
> > > > Hi,
> > > >=20
> > > > I wanted to post another revision of the series adding hw12 runner,
> > > > hoping that all known issues are fixed now, but unfortunately there=
 is
> > > > still something broken. I've rebased my series on top of staging
> > > > (ed9488a0d) and got this pipeline:
> > > >=20
> > > > https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1807=
819142
> > > > (note due to some added debugging, some tests are incorrectly marke=
d as
> > > > success even if they failed...)
> > > >=20
> > > > 1. USB ethernet doesn't work on PVH dom0: https://gitlab.com/xen-pr=
oject/people/marmarek/xen/-/jobs/9978694739
> > > > There supposed to be an USB ethernet device connected to the USB
> > > > controller at c3:00.4. In the PV dom0 case it's detected as:
> > > >=20
> > > >     [    3.911555] usb 7-1.4: new high-speed USB device number 3 us=
ing xhci_hcd
> > > >     [    4.004201] usb 7-1.4: New USB device found, idVendor=3D0bda=
, idProduct=3D8153, bcdDevice=3D30.00
> > > >     [    4.004675] usb 7-1.4: New USB device strings: Mfr=3D1, Prod=
uct=3D2, SerialNumber=3D6
> > > >     [    4.005079] usb 7-1.4: Product: USB 10/100/1000 LAN
> > > >     [    4.005349] usb 7-1.4: Manufacturer: Realtek
> > > >     [    4.005599] usb 7-1.4: SerialNumber: 684D35
> > > >=20
> > > > But it's not there on PVH. The USB controller itself is detected, j=
ust
> > > > not device(s) connected to it. This applies to other controllers too
> > > > (there should be about 3 or 4 other USB devices - none of them show=
 up).
> > > >=20
> > > > 2. There is a bunch of "unhandled memory read" errors during PVH do=
m0
> > > > startup: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/=
9978694739
> > > >=20
> > > >     (XEN) [    4.026323] arch/x86/hvm/emulate.c:417:d0v0 unhandled =
memory read from 0xfedc0020 size 1
> > > >     (XEN) [    4.026789] arch/x86/hvm/emulate.c:417:d0v0 unhandled =
memory read from 0xfedc0021 size 1
> > > >     (XEN) [    4.027247] arch/x86/hvm/emulate.c:417:d0v0 unhandled =
memory read from 0xfedc0020 size 1
> > > >     (XEN) [    4.027671] arch/x86/hvm/emulate.c:417:d0v0 unhandled =
memory read from 0xfedc0021 size 1
> > > >     ...
> > > >=20
> > > > This repeats several times. Could be related to the USB issue above?
> > >=20
> > > Can you try with dom0=3Dpf-fixup?  Those unhandled accesses might be =
the
> > > cause of the USB issues.
> >=20
> > It did got rid of those messages, but USB still doesn't work:
> > https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/10006580289
>=20
> Hm, is it possible that the usage of console=3Dxhci is interfering with
> USB devices?  Could you try to boot without console=3Dxhci and see if
> you can still reproduce the issue?  You will need the physical device
> by your side, which I'm not sure it's possible.  Don't know if you
> host those remotely somewhere.

I can try, but will need a proper driver there (in dom0?) - AFAIR VGA
nor efifb doesn't output to HDMI there (and eDP is not connected).
Anyway, it's IMO unlikely, given it works just fine with PV dom0...

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--udp08jojfO2v1HwX
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgiCF0ACgkQ24/THMrX
1yz5pgf5AXuzojrbbMGQoZr7k+8lI/PQjYisPyTyCwajAyeXxqO5tZhfWzYXNxRe
wCgSjJ1YybIvJxW7vZMqyl5Hg54ZzK9Y5Ew1/O29m97mfLvltAunGMZ7sxSy2tiF
8QK3zAw6AKlHivrBHDXmO7M02lzxUyJqgfHvFgrqQ3KYdq3ZTAnRuSlD//oodJuz
KfSlbYABeXN/ZsbtMR3Xpxli395bK2yjtr5Lpn6daGgoO2ad0OSHUNZQIMn+Y+D1
5nk7pWCYw9LbxCBUBveknRHd2oyvNNqcbLNt2mM0FDjIzIO6Qk/PJttPv5+cCMhm
q8jomsE25noFmybCYSRJ69qBKyvCjA==
=U694
-----END PGP SIGNATURE-----

--udp08jojfO2v1HwX--


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:42:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:42:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981596.1367997 (Exim 4.92)
	(envelope-from )
	id 1uEULx-00043r-Ob; Mon, 12 May 2025 14:42:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981596.1367997; Mon, 12 May 2025 14:42: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 1uEULx-00043k-Lh; Mon, 12 May 2025 14:42:01 +0000
Received: by outflank-mailman (input) for mailman id 981596;
 Mon, 12 May 2025 14:42:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEULw-00043c-PJ
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:42:00 +0000
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com
 [2607:f8b0:4864:20::52f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4247f3e0-2f3f-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 16:41:59 +0200 (CEST)
Received: by mail-pg1-x52f.google.com with SMTP id
 41be03b00d2f7-b2325c56ebdso3327585a12.1
 for ; Mon, 12 May 2025 07:41:59 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 41be03b00d2f7-b234ad3ea55sm5721845a12.36.2025.05.12.07.41.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 07:41: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" 
X-Inumbo-ID: 4247f3e0-2f3f-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747060918; x=1747665718; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=EJCRz/oIYTWnj4EjPCmhOZH2eW6o4a9pf5HS4Ytyvi4=;
        b=feCQFxp00HxcPNkUxad7E/NiT+2A/xK+7EaRYcSnkNDqjKiE/wQZRLh1ZMqswab+TR
         8qIYi5CM1SliCB4DJ2f+Cf5rpQCI2CAa22Qi2ySFMJgxpOig7EsBRTOwr77v53ZldUH7
         89z4+SMahfkIER8FIIyN53RHalb7dYNqZAMQE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747060918; x=1747665718;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EJCRz/oIYTWnj4EjPCmhOZH2eW6o4a9pf5HS4Ytyvi4=;
        b=roWUIhCWFs3Mzm4XZ+QOtMoYQPCmDLzVUcynAPM+k1zDGG2hg7hb1NmX3Y3LkUsuM2
         fPPTJTtSI2V4NdclnldkF7wtNt0r2PvTky7+z/qqk8wAmBaeGehbYOd8SgQwrjB9mnpY
         RFp3+BVj3FoNbzLnF23Ejuk0uP4zSSF5h+6JJALmRt1J/M+v+NxReSYeYP3YN+OEMuHJ
         oTT0gF9+Z+oBpz6YkgDDfuzEK706AjRYWNthPE9sP6hHuDJ6FQJDRg042RLUyviSCz5U
         nCpz1D7I5MupoLoo2YLIqRP2QB4sSsqMfz0D8m+4cHFjN7ANAuA8MGiGxUfGhRfs+S+J
         NNvg==
X-Forwarded-Encrypted: i=1; AJvYcCVpleZ88FxOG+qmI1DjCaAT8ClRiyHxI2FdzjDlkNOwx726sKTarckUzL3cThk9e0r5MtnmN3HEjIk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxfvsgjTSw8aQ/zEmwqQRR56x+haTSUA5dnKvxi0zUauRoLJzxR
	gWisvHQFMrWsiu6d4U00liEb8kPRbNLLNBtrFN+89EvY+dkSSotWzTt6e1oZZoQ=
X-Gm-Gg: ASbGncvtG8xaCpaKk+HYjrCWJ77t0ABlZ6wMa4zd9TUu+X+alsK295s+u80BpSeB1b+
	yDmUOjkd1ZfsOgxzdRnKSY16Qz/fES6OO/Tnylweuv6iKGM7hwx8nOgJxSi7AofdckiLXeSR5V0
	PySC8SVyGh3soYTtDRl6XHsrMNk/2QzyehZ4zEO4Aa98mio58ol+U+bgnKblQIVfGRJV9QogHG+
	vKD+/9FfkjZWFeSilhHAaFho0G0vzbJRQv34izwPDE6XnU6pxl4MT9Sa/Nq4/PqhrHUyhldjH6a
	Tluj6+mhbdb3e9MPxTJmffCpYanTtfqxtMsl8wV5YHUt6WlNC0vJZa0Z
X-Google-Smtp-Source: AGHT+IFcwMyIdOPYIo3ThrSrj9RRUrfhVJ4x6Mox2oKpHgr4uXhdNgA2CZff3sQRqpIg5eriz8IGXA==
X-Received: by 2002:a05:6a20:559e:b0:215:e53b:9ead with SMTP id adf61e73a8af0-215e53b9f85mr1164259637.26.1747060918038;
        Mon, 12 May 2025 07:41:58 -0700 (PDT)
Date: Mon, 12 May 2025 16:41:52 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/9] x86/pv: fix emulation of wb{,no}invd to flush all
 pCPU caches
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-3-roger.pau@citrix.com>
 <7102b188-7abe-47a5-b889-d11db3eda674@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <7102b188-7abe-47a5-b889-d11db3eda674@suse.com>

On Mon, May 12, 2025 at 04:20:30PM +0200, Jan Beulich wrote:
> On 06.05.2025 10:31, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/pv/emul-priv-op.c
> > +++ b/xen/arch/x86/pv/emul-priv-op.c
> > @@ -1193,17 +1193,18 @@ static int cf_check cache_op(
> >  {
> >      ASSERT(op == x86emul_wbinvd || op == x86emul_wbnoinvd);
> >  
> > -    /* Ignore the instruction if unprivileged. */
> > -    if ( !cache_flush_permitted(current->domain) )
> > +    /*
> > +     * Ignore the instruction if domain doesn't have cache control.
> > +     * Non-physdev domain attempted WBINVD; ignore for now since
> > +     * newer linux uses this in some start-of-day timing loops.
> 
> That's very old comment, and hence I think "newer" isn't quite applicable
> anymore. Either omit the word (if Linux still does so), or say "older"
> instead? Also since you touch the comment, upper-casing the L in Linux
> might be nice.

There's a wbinvd at the beginning of trampoline_start, which is
possibly to what this comment is referring to?

I will just drop the mention of "new" or "old" and capitalize the L in
Linux.

> > +     */
> > +    if ( cache_flush_permitted(current->domain) )
> >          /*
> > -         * Non-physdev domain attempted WBINVD; ignore for now since
> > -         * newer linux uses this in some start-of-day timing loops.
> > +         * Handle wbnoinvd as wbinvd, at the expense of higher cost.  Broadcast
> > +         * the flush to all pCPUs, Xen doesn't track where the vCPU has ran
> > +         * previously.
> >           */
> > -        ;
> > -    else if ( op == x86emul_wbnoinvd /* && cpu_has_wbnoinvd */ )
> > -        wbnoinvd();
> 
> So this goes away altogether, which isn't nice. It was "only" 2 years ago that
> I posted a series where an additional ...
> 
> > -    else
> > -        wbinvd();
> > +        flush_all(FLUSH_CACHE);
> 
> ... FLUSH_CACHE_WRITEBACK is introduced [1]. I really, really think that should
> go in first, for it to then be used here. The more that it's the 1st patch in
> that series.

Saw that series when doing this, I was going to ask about them but you
where away and then I forgot about it.

Let me take a look now.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:47:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:47:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981607.1368017 (Exim 4.92)
	(envelope-from )
	id 1uEUQv-0004sX-Jw; Mon, 12 May 2025 14:47:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981607.1368017; Mon, 12 May 2025 14:47: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 1uEUQv-0004sK-G4; Mon, 12 May 2025 14:47:09 +0000
Received: by outflank-mailman (input) for mailman id 981607;
 Mon, 12 May 2025 14:47:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEUQv-0004nZ-5P
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:47:09 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f9f6cc56-2f3f-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 16:47:07 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-acbb85ce788so816797666b.3
 for ; Mon, 12 May 2025 07:47:07 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197bd219sm634459366b.141.2025.05.12.07.47.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 07: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" 
X-Inumbo-ID: f9f6cc56-2f3f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747061226; x=1747666026; 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;
        bh=QZdT8ksWgEMXDFM8tuDjoHvSvI8JR1Ks3DBaGeWomBI=;
        b=NSarexCuj7nMVA4PnCrjzNge/ER9nvZwvrruGN+kNMiyKX4aMRXhtTmg4Sq/P5Mmyu
         0YIenGdy/TgbDhGH6IHbSfq4CwgHjCDX9Ub2rLj18Fgx8RJ9kUiMb7RMWOXcylejiDEg
         Grgx53xNIoYvWCuBOYzbQEwmxRd71aaaxmv48=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747061226; x=1747666026;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=QZdT8ksWgEMXDFM8tuDjoHvSvI8JR1Ks3DBaGeWomBI=;
        b=k4hTP4jkmBg2A/Lpm8k0dJePUwsMJoOc5Z7C4QZcOE2ZywCREjMwMhFj7LIBH6BmDn
         7LVKFo/emW8VNSfXOFAb7CqAqu2OMEX8GXkTPUKMuvv+p29eHqxWd7F4X8TKwgTNIPmm
         gmZbSNLo+6GuCojH3vGfX370ozlDLmvcC3x2+uIIfjLRHyg33+ab7pBeFSzWxrbF9hwc
         9ITnqwFsi8j4W8wHxgOfwgsYx+SKcuNvwvQVLFyDbF0r8w24ex1LjFSYX6tZfMT4GAaD
         G1Xdap0FrnsnmMwc88wG2k7IkejIYHk8sNx86pRCxVx4SijkYneuDr0yKqOAlQbFIs4L
         pk4Q==
X-Gm-Message-State: AOJu0YwEI71t9Q6SrIS/ReuCfbjTj9R1I1m0hrgTrx6BMv0eQEeIp0/B
	CukzWglXMfxta3XMu8tg3GhqMdIFbm/lvkt9mem2tjbP4QIp8AxT7R+XMAxwYHAYrKvWIARNfi4
	=
X-Gm-Gg: ASbGncv+udn3t6xYBXaHxlU1i9xS+it/bW/9JWa8s56fl5WgPvLAiZ9LO40LCUTwnfR
	persCJVJbvwyhVDefQ7fidufalV5EPA5BULozYpQ22tUz24W6eyOgDCCljorILd3c8A6XMlaCQ7
	GCO4Y3S3qVp7ew+NjkcxJZCRYCOQhYnZzpRl9PsoLTZmAMjFBxIt4nLTQ+8bUtRygcgDjJ2IsmB
	91p4MnobtDiteKFrPnKY9ZzF8bQOZr2u46dcDnlJTX+Qx/S97g63K2XXvu236ZTXbvKUNyRkMWn
	SDEAbObOUT0acpomHGqKbtIP3QwS3sTW8zSNk+NZzA3dPcRJ8RP1fDP5xvIoF/aasvsY2uaSnX4
	=
X-Google-Smtp-Source: AGHT+IEms7S0A8wfxZM3hG5JDaxttkq/QHLgGpNwo1989lCGrQUA8aQ+tPm02NydXplFG1iINuLIxg==
X-Received: by 2002:a17:907:7b97:b0:ac3:8516:9cf2 with SMTP id a640c23a62f3a-ad21928f0e7mr1395679266b.55.1747061226318;
        Mon, 12 May 2025 07:47:06 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich 
Subject: [PATCH v2 1/5] x86/pmstat: Check size of PMSTAT_get_pxstat buffers
Date: Mon, 12 May 2025 15:46:52 +0100
Message-ID: <20250512144656.314925-2-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250512144656.314925-1-ross.lagerwall@citrix.com>
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Check that the total number of states passed in and hence the size of
buffers is sufficient to avoid writing more than the caller has
allocated.

The interface is not explicit about whether getpx.total is expected to
be set by the caller in this case but since it is always set in
libxenctrl it seems reasonable to check it.

Signed-off-by: Ross Lagerwall 
Fixes: c06a7db0c547 ("X86 and IA64: Update cpufreq statistic logic for supporting both x86 and ia64")
---

In v2: Rather than erroring out, copy as much as possible.

 xen/drivers/acpi/pmstat.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index c51b9ca358c2..4736a84d1256 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -103,8 +103,10 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
 
         cpufreq_residency_update(op->cpuid, pxpt->u.cur);
 
-        ct = pmpt->perf.state_count;
-        if ( copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct*ct) )
+        ct = min_t(uint32_t, pmpt->perf.state_count, op->u.getpx.total);
+
+        if ( ct <= op->u.getpx.total &&
+             copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct * ct) )
         {
             spin_unlock(cpufreq_statistic_lock);
             ret = -EFAULT;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 14:47:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:47:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981608.1368027 (Exim 4.92)
	(envelope-from )
	id 1uEUQw-00056n-Ql; Mon, 12 May 2025 14:47:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981608.1368027; Mon, 12 May 2025 14: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 1uEUQw-00056g-NH; Mon, 12 May 2025 14:47:10 +0000
Received: by outflank-mailman (input) for mailman id 981608;
 Mon, 12 May 2025 14:47:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEUQv-0004eT-F8
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:47:09 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fb103bbf-2f3f-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 16:47:09 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad238c68b35so432066366b.1
 for ; Mon, 12 May 2025 07:47:09 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197bd219sm634459366b.141.2025.05.12.07.47.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 07: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" 
X-Inumbo-ID: fb103bbf-2f3f-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747061228; x=1747666028; 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;
        bh=m24oQdGhZQ3HdAHSB/EUXyg1ydozRabCfdfrnP4B+2U=;
        b=ElR5qTzyoUwABz4TsbgeWmfT8L9eFVNBQkXuMoKaNcQYRWVsADjZ8I7f/DWxOPOTqy
         ZdpYFN7V/0eKEzy3Awh5vN3M623PFeLcHbNCGghvhQ24OKvEfQm0STLPb6BRC1b4FZSY
         YdlQdg+M3GLYUvVgvYitTVKD2uc5/8DZNckFM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747061228; x=1747666028;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=m24oQdGhZQ3HdAHSB/EUXyg1ydozRabCfdfrnP4B+2U=;
        b=CusvXPfAXig9oqRSM13CWAavox0ikNVooUqyoZXW6KOU2ikOXGXzImY4W+aXg/gdhT
         K1VxZifdLSq5F+DCRjmkb555K6/Bb9JMajkXeBx2sGQApxyaRLhIbLBFBT8OgdlIXf0u
         +ZsU+d9A/eJgDG4HxITyrG+rCZZT1A2NCsYtN1aW3uIE4amQ3ndVOXKUVYVm17729SPT
         kG43pHaBSJXSFvytKD6rCxtsrENCPVAynnhLvkGGXIdwCyVSpEOlhJISmtVIQiX3Z+is
         YJkOrhycCZUg/dggHPcjQgXFZJoCuSQAYUTfeaNsmVhEq3hunw4YOV9eik/fbXhutJe5
         5rLA==
X-Gm-Message-State: AOJu0Yx7FCRD7rNbPH6yBRfFFuuc9istSgYc6bpRERJbipY34mX06UMI
	lMuu8uVoDFaJMCgLdx9rBMs0Y55chbZP+rUrI7n8/z8N9c58Ni8f7UTB/ahlTcO7RLq6V+fwpXU
	=
X-Gm-Gg: ASbGnctHje5yNDE5McFMCMjFxypinZK18jzxyJjXYI5+odhsvHacvrD26v0lWSqItys
	VJWmjwqdx6bT8/WZ1JkBNmzNWa8Q7Xj4/m34npyTlv8s3g+GO/KENRhvk4qxLIK2OnoDdgkASBG
	do96JoL5wWlg73D7Xc3SIuHA88dvSzSNrQ1zIj7u7pXqNvDXZGMUVfDgQTdQVLJ4e9reWK0FOvo
	5JkXlsgy793tnDBQYRrNOMCVbHs2NncQT46ugIqycADJB5eh0bS/3yCtAqy0r76e3bmTkXO6nZ4
	bxeAUuYevJZLjiRfN1Hx+wnbaD2amBCTyfUPcYv1+4w6eS9jbeBGQBKNj5On2kCSY/Z0INNatyY
	=
X-Google-Smtp-Source: AGHT+IGDg68Dia+Sb7azYtZ3RqgcJF32Yh0aCRJgxz8nmhA7pyfOvZlCoeeojNEcTdkODeO9dUl6+g==
X-Received: by 2002:a17:907:6c12:b0:ad2:4cac:46fc with SMTP id a640c23a62f3a-ad24cac5916mr605848566b.36.1747061228219;
        Mon, 12 May 2025 07:47:08 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 2/5] public/sysctl: Clarify usage of pm_{px,cx}_stat
Date: Mon, 12 May 2025 15:46:53 +0100
Message-ID: <20250512144656.314925-3-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250512144656.314925-1-ross.lagerwall@citrix.com>
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Suggested-by: Jan Beulich 
Signed-off-by: Ross Lagerwall 
---

* New in v2.

 xen/include/public/sysctl.h | 52 ++++++++++++++++++++++++++++---------
 1 file changed, 40 insertions(+), 12 deletions(-)

diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index b0fec271d36f..449f0161920a 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -215,23 +215,51 @@ typedef struct pm_px_val pm_px_val_t;
 DEFINE_XEN_GUEST_HANDLE(pm_px_val_t);
 
 struct pm_px_stat {
-    uint8_t total;        /* total Px states */
-    uint8_t usable;       /* usable Px states */
-    uint8_t last;         /* last Px state */
-    uint8_t cur;          /* current Px state */
-    XEN_GUEST_HANDLE_64(uint64) trans_pt;   /* Px transition table */
+    /*
+     * IN: Number of elements in pt, number of rows/columns in trans_pt
+     *     (PMSTAT_get_pxstat)
+     * OUT: total Px states (PMSTAT_get_max_px, PMSTAT_get_pxstat)
+     */
+    uint8_t total;
+    uint8_t usable;       /* OUT: usable Px states (PMSTAT_get_pxstat) */
+    uint8_t last;         /* OUT: last Px state (PMSTAT_get_pxstat) */
+    uint8_t cur;          /* OUT: current Px state (PMSTAT_get_pxstat) */
+    /*
+     * OUT: Px transition table. This should have total * total elements.
+     *      This will not be copied if it is smaller than the hypervisor's
+     *      Px transition table. (PMSTAT_get_pxstat)
+     */
+    XEN_GUEST_HANDLE_64(uint64) trans_pt;
+    /* OUT: This should have total elements (PMSTAT_get_pxstat) */
     XEN_GUEST_HANDLE_64(pm_px_val_t) pt;
 };
 
 struct pm_cx_stat {
-    uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
-    uint32_t last;  /* last Cx state */
-    uint64_aligned_t idle_time;                 /* idle time from boot */
-    XEN_GUEST_HANDLE_64(uint64) triggers;    /* Cx trigger counts */
-    XEN_GUEST_HANDLE_64(uint64) residencies; /* Cx residencies */
-    uint32_t nr_pc;                          /* entry nr in pc[] */
-    uint32_t nr_cc;                          /* entry nr in cc[] */
     /*
+     * IN:  Number of elements in triggers, residencies (PMSTAT_get_cxstat)
+     * OUT: entry nr in triggers & residencies, including C0
+     *      (PMSTAT_get_cxstat, PMSTAT_get_max_cx)
+     */
+    uint32_t nr;
+    uint32_t last;  /* OUT: last Cx state (PMSTAT_get_cxstat) */
+    /* OUT: idle time from boot (PMSTAT_get_cxstat)*/
+    uint64_aligned_t idle_time;
+    /* OUT: Cx trigger counts, nr elements (PMSTAT_get_cxstat) */
+    XEN_GUEST_HANDLE_64(uint64) triggers;
+    /* OUT: Cx residencies, nr elements (PMSTAT_get_cxstat) */
+    XEN_GUEST_HANDLE_64(uint64) residencies;
+    /*
+     * IN: entry nr in pc[] (PMSTAT_get_cxstat)
+     * OUT: Index of highest non-zero entry set in pc[] (PMSTAT_get_cxstat)
+     */
+    uint32_t nr_pc;
+    /*
+     * IN: entry nr in cc[] (PMSTAT_get_cxstat)
+     * OUT: Index of highest non-zero entry set in cc[] (PMSTAT_get_cxstat)
+     */
+    uint32_t nr_cc;
+    /*
+     * OUT: (PMSTAT_get_cxstat)
      * These two arrays may (and generally will) have unused slots; slots not
      * having a corresponding hardware register will not be written by the
      * hypervisor. It is therefore up to the caller to put a suitable sentinel
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 14:47:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:47:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981606.1368008 (Exim 4.92)
	(envelope-from )
	id 1uEUQu-0004eg-CZ; Mon, 12 May 2025 14:47:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981606.1368008; Mon, 12 May 2025 14:47: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 1uEUQu-0004eZ-8H; Mon, 12 May 2025 14:47:08 +0000
Received: by outflank-mailman (input) for mailman id 981606;
 Mon, 12 May 2025 14:47:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEUQs-0004eT-FX
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:47:06 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f8e0641e-2f3f-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 16:47:05 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5fcc96b6a64so4696718a12.0
 for ; Mon, 12 May 2025 07:47:05 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197bd219sm634459366b.141.2025.05.12.07.47.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 07:47: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" 
X-Inumbo-ID: f8e0641e-2f3f-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747061224; x=1747666024; 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;
        bh=edvOPEfgYBiY31RUPQrTKj3oj6FLwY0EZ5M5g55NxnM=;
        b=P2SjFqQtBTyDcOEr1aBlDYXXhY6qw43Ql88LfS4cYkHKJmd3UQEiGNYS5p++hNe/Vn
         WgDOQ84tN9e2t7zAV6nYQRDFzOvYrcf248NIqNpOHanj1ZyRqY2QS8UsPNBcclJfYfRp
         c5WN0JDMjrDV8set+WYiJMA/Qzgj9S2LoDwPA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747061224; x=1747666024;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=edvOPEfgYBiY31RUPQrTKj3oj6FLwY0EZ5M5g55NxnM=;
        b=Bu29JHncNPNs/MzMHVZK4TvtFicBpmk/FfFQtk11UcbWE/rL6rHhs8Wr1gbhmuWVR8
         s/TNFO6FC6JczjzgJq300twYM7C1wiv4irGRguhR7ZGk8digJr+mpGnFcYVsFzWUv4f0
         wLiKxhnGBm/XC7g/FaY7WWrM9s/qKcw2yF59HcsWhih8xnRXO//6A+eaBmBIMYxOuqD5
         iYm2nOJ1DJCKWPj0sp6YH8XKp+M422iyqMcOq9gU0lo8PCOitLTbZTwnKchF6nKysxiV
         baBB05ORSOSAdJWWjjJZZ9t/j5uM2CMHaqpHE99CS5CvUW/EjklOp9Xn0nXX9GY+pufn
         OG6Q==
X-Gm-Message-State: AOJu0Yx5lTiGNElbmyoyRsVNip4CPdKHI2sueV2qGjaI6KdL75q8aJGR
	6mJS1RyRybLUM/28tx7Yi8sT3dU6pQ/mfuJNzBUI+BgIEFh3ZHM1fkOLHPZhl5SfArh1vSwUlEM
	=
X-Gm-Gg: ASbGnctmtXnVy3Y+1N3pRjURDeJBzbAAR1I+KB0dJVhj+yAc7uqBNbe36BqLR1C5qjJ
	veAPlyDDquaRzlH0OFoC3V5oarBLQLWPCnapawbi+kjugWwIKEiZaa5pEt9/LAEAM6YzsBelMYt
	0lznb9UQx7fEkqTOqy8qAZsrR6gniW60SWYuiYdxuTKNopF+ffWA9TxjbmP5xAC5zehgFAOVq6a
	7m32Ut8isgraQyuQqdiIQYbYiJVfac6ExVTCMEf6Os+cvo+uuIk7puiBnHjRkhDS7CUR0MDsOZ6
	wITlC2l+M1hMT4Eh5EjAZP1AW4cEqTURpuAg/GBDVG9OqE1FA1wF1I3QWUMiSrUXHPk/fQHJenU
	=
X-Google-Smtp-Source: AGHT+IHG4mPFcPutSdz0S4m0QP068mVkMhrjUODjFuan01ZTRRK4WVwpMA9FsAQF0HJgL2mq6snOUw==
X-Received: by 2002:a17:907:6a13:b0:ace:c518:1327 with SMTP id a640c23a62f3a-ad218f1b830mr1298948766b.14.1747061224589;
        Mon, 12 May 2025 07:47:04 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Juergen Gross 
Subject: [PATCH v2 0/5] pmstat interface fixes
Date: Mon, 12 May 2025 15:46:51 +0100
Message-ID: <20250512144656.314925-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Clarify and fix usage of the pmstat hypervisor and tools interfaces
regarding sizes of buffers passed in.

Ross Lagerwall (5):
  x86/pmstat: Check size of PMSTAT_get_pxstat buffers
  public/sysctl: Clarify usage of pm_{px,cx}_stat
  cpufreq: Avoid potential buffer overrun and leak
  libxc/PM: Ensure pxstat buffers are correctly sized
  libxc/PM: Retry get_pxstat if data is incomplete

 tools/libs/ctrl/xc_pm.c       | 20 ++++++--------
 tools/misc/xenpm.c            | 48 ++++++++++++++++++++------------
 xen/drivers/acpi/pmstat.c     |  6 ++--
 xen/drivers/cpufreq/cpufreq.c |  4 ++-
 xen/include/public/sysctl.h   | 52 +++++++++++++++++++++++++++--------
 5 files changed, 87 insertions(+), 43 deletions(-)

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 14:47:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:47:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981609.1368038 (Exim 4.92)
	(envelope-from )
	id 1uEUR0-0005Ow-7I; Mon, 12 May 2025 14:47:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981609.1368038; Mon, 12 May 2025 14: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 1uEUR0-0005Oj-2w; Mon, 12 May 2025 14:47:14 +0000
Received: by outflank-mailman (input) for mailman id 981609;
 Mon, 12 May 2025 14:47:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEUQy-0004nZ-EK
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:47:12 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fc1c9e27-2f3f-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 16:47:10 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5fd1f7f8b25so3058369a12.0
 for ; Mon, 12 May 2025 07:47:10 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197bd219sm634459366b.141.2025.05.12.07.47.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 07:47: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" 
X-Inumbo-ID: fc1c9e27-2f3f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747061230; x=1747666030; 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;
        bh=wdxxBMh/8WuvhnZcKFZ8Olw6CipXskfibxNFcNvZtyA=;
        b=dPO1Dcv4MurhPry58joWp32vfXYlIQSYwOfTjyAExlKWnVuLkzp+yTShL01B87Lqzx
         Fp5bUbR1sd09g+OpvslC6nKS0URaltyxujOti6etvEM1NTAmdcNqpOMgQYjM6b2VQ4s9
         XgWb8RhfhfPaE0Dc3+rM73/SnFbyTYeUmBw1s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747061230; x=1747666030;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=wdxxBMh/8WuvhnZcKFZ8Olw6CipXskfibxNFcNvZtyA=;
        b=UbyJmUqXxXrTQxLmn/4jojfH9Irg84P5b+R7KIgIvFOYE/KcYPecnyEgpEhZJxMFDc
         WLrYUGT4a0TWYFdpYRtOJ7EK2HTl5BuI/a41sr7z5he9pFfkBSbOu2YlGQuSwvMfjF1h
         TlC9zaC1aHfGfDkJFQZORz0ZFlDrUmCjwf5jBVllEefHNftY0fQ2xXOwqgcyltbWt07r
         RmGoLYdC6KGVJgD24BHWgAhzUtCxx2GXoAyhDmZqZfCwdmXl0CqXgxuJBpnDYmcAItqW
         fZJoO0LG9Rrww8Ahm6MpzG8mQxDi2wHVFdsG2Vvl6z8bsFn581TBbwnthH2Ubz7YJzI4
         WEcA==
X-Gm-Message-State: AOJu0YzoPONCB3n2a7o8rufbnSbOnf5w77UbhAu5AygNCKWxHR/iTO1u
	z4ZdjLj6o/y2x48YPPbH+XIe27CZr3531NB1pnNeGzScu3LQq9gzISn57jAtnPwuXRhHMFlAgnE
	=
X-Gm-Gg: ASbGncuU1iY5xig69gtTc28pIRoov0QvXXsxy+yuVZM+KtFZB1+EpcyvcYVWaJENXHj
	hJB5Clx/nJTFQfJ8bBKj4XCrBqNJDG6CHKAZmjNBbxkiegmrk35L0hWop+z8XYspFqgZUn87gGA
	3KHsnopuvcAhqTuB0QolktPGePPI+gFpu+d4kGL0k8aA2S7/2v1P0c5je0LWCGp5EJqgyoPwr/7
	4D/EjH2KmX9P0l7KkvdUNGGigUuJcRlUzMAK+lMbSvBtl0L7Y7fATx5nN9wxMkkTk6Y7uOJ1bHP
	L8zaeWM0RvlOD2JcI9NymGFSC4+ILv4nABK0TKGT1p15ViJMWXaYJG5Qky33oNTL1Xb+X76rn9w
	=
X-Google-Smtp-Source: AGHT+IEfSekAHKOEUn0CR4UQaDaWEYPwhkWiAlH4A74/DDvj+20F3qik12yG4Et71HKanrJCdcH8UQ==
X-Received: by 2002:a17:907:9484:b0:ad2:5657:3161 with SMTP id a640c23a62f3a-ad256573523mr402058766b.59.1747061229968;
        Mon, 12 May 2025 07:47:09 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich 
Subject: [PATCH v2 3/5] cpufreq: Avoid potential buffer overrun and leak
Date: Mon, 12 May 2025 15:46:54 +0100
Message-ID: <20250512144656.314925-4-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250512144656.314925-1-ross.lagerwall@citrix.com>
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

If set_px_pminfo is called a second time with a larger state_count than
the first call, calls to PMSTAT_get_pxstat will read beyond the end of
the pt and trans_pt buffers allocated in cpufreq_statistic_init() since
they would have been allocated with the original state_count.

Secondly, the states array leaks on each subsequent call of
set_px_pminfo.

As far as I know, there is no valid reason to call set_px_pminfo
multiple times for the same CPU so fix both these issues by disallowing
it.

At the same time, fix a leak of the states array on error.

Signed-off-by: Ross Lagerwall 
---

* New in v2.

 xen/drivers/cpufreq/cpufreq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index 19e29923356a..bf65403ff50b 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -520,7 +520,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf)
     if ( perf->flags & XEN_PX_PSS )
     {
         /* capability check */
-        if ( perf->state_count <= 1 )
+        if ( perf->state_count <= 1 || pxpt->states )
         {
             ret = -EINVAL;
             goto out;
@@ -534,6 +534,8 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf)
         }
         if ( copy_from_guest(pxpt->states, perf->states, perf->state_count) )
         {
+            xfree(pxpt->states);
+            pxpt->states = NULL;
             ret = -EFAULT;
             goto out;
         }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 14:47:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:47:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981610.1368041 (Exim 4.92)
	(envelope-from )
	id 1uEUR0-0005SS-Fp; Mon, 12 May 2025 14:47:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981610.1368041; Mon, 12 May 2025 14: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 1uEUR0-0005Rn-Ae; Mon, 12 May 2025 14:47:14 +0000
Received: by outflank-mailman (input) for mailman id 981610;
 Mon, 12 May 2025 14:47:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEUQz-0004eT-0M
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:47:13 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fd27dc1a-2f3f-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 16:47:12 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5fd1f7f8b25so3058474a12.0
 for ; Mon, 12 May 2025 07:47:12 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197bd219sm634459366b.141.2025.05.12.07.47.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 07: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" 
X-Inumbo-ID: fd27dc1a-2f3f-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747061232; x=1747666032; 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;
        bh=yvQdZIK/JXFuZvTKoVLrQyBHywf2ZxT+4HEeq47F6rg=;
        b=uM9jB+mYlLOYOvLPfxGxtAP7fC9t+sW5oqwGVXADLPtEED8N0oN5DSpLM+PQjah4lR
         tRuAx5Vtdvssky3GhS++5q+fOWJDPiJXVzkKGyMcgk198ZBsFLh0E+d8Vo8OhsN4woct
         R2u5NBOKdudJr0NFPYk4Fsrzf+7ubHi/ofbac=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747061232; x=1747666032;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=yvQdZIK/JXFuZvTKoVLrQyBHywf2ZxT+4HEeq47F6rg=;
        b=uQUTxtq8GNZIXPn4wZPKV2wclQSk7N0wb3wXANFg5xIzuJ0J4qiD3k8dSnI/TkhRkq
         oSruDLh7Y4Rhm2Y/QyiIcCQui+kl+VFXGP7AbTvM0PCOvm7XKOun0qOWzWDqma4c3ZpW
         V3e1QiQtIsnXXiQ4eyJiTgtr5E+xtqod1dUCztG/RyxaCps0vXR4VkLaKDqTo0mLR4gx
         D4GfFB0MMuvhmKTV0l8hrg8FU27qdJFobLEhMllVGYg4ahILkyPtRwQSe8nDxRsp7tcY
         jyh0//D9Use/J58VPHBe976mBVVBOSb1ZmhVuyvmqc4v41FfMj3ocQYL6fVq+rdBmO2V
         RjQQ==
X-Gm-Message-State: AOJu0YzlGh0Amf98skI/ZewYsCQ2TNQNp4NqndYlFl679COL6ts1hk2v
	VZIvpyY+HIK/EkJp5Th5qCo69OFzXLOwLqIrD8qHYdfWSvpk/osOtMiq+3jkmYuSq6VIE0uQx3Y
	=
X-Gm-Gg: ASbGncuvl4/JDxUWst6gahcSh+VWh+VOsWBqJ9CZzykPqjz+zUaw73ODF4eQcvxicRq
	/lOQE47e3d2zgpKe++O/z6eRnzadP2fisN8r+WA9R7jzdXPE7CrhxFG0WTY6pKznGciXsu1G6EC
	ABjW0kpCssRUcs4SmBrrOH9+2HWTL9XrLCbsV4CKs0eM0hacI55ANpgc/DIYAtv+fq+dnpiKIV4
	g2C3AvWf1nFldTIQtcrFRp3Cp/J8e1ilid0EUuzTr/LM+DWoky32/QlXut+aSSJmbQvwp+pse7/
	n5PKiJHuCcKQLldJMiYydRv6nc1ojwjtg+XLidLUq7K1/2o7Dd7oeKXv/+ES98ChYkH6lHWtYE8
	=
X-Google-Smtp-Source: AGHT+IGgEcr4x5iQWIFKccA8eC5vCGT1qAVTBjx7C45iZw/EIh4KJNcSAiaafo5TFy0lRllyaadJBw==
X-Received: by 2002:a17:907:9453:b0:ad1:76d2:d06 with SMTP id a640c23a62f3a-ad219171d53mr1385413566b.47.1747061231720;
        Mon, 12 May 2025 07:47:11 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Anthony PERARD ,
	Juergen Gross ,
	Jan Beulich 
Subject: [PATCH v2 4/5] libxc/PM: Ensure pxstat buffers are correctly sized
Date: Mon, 12 May 2025 15:46:55 +0100
Message-ID: <20250512144656.314925-5-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250512144656.314925-1-ross.lagerwall@citrix.com>
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

xc_pm_get_pxstat() requires the caller to allocate the pt and trans_pt
buffers but then calls xc_pm_get_max_px() to determine how big they are
(and hence how much Xen will copy into them). This is susceptible to
races if xc_pm_get_max_px() changes so avoid the problem by requiring
the caller to also pass in the size of the buffers.

Suggested-by: Jan Beulich 
Signed-off-by: Ross Lagerwall 
---

* New in v2.

 tools/libs/ctrl/xc_pm.c | 20 +++++++++-----------
 tools/misc/xenpm.c      |  1 +
 2 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/tools/libs/ctrl/xc_pm.c b/tools/libs/ctrl/xc_pm.c
index ff7b5ada053f..cffbd1b8a955 100644
--- a/tools/libs/ctrl/xc_pm.c
+++ b/tools/libs/ctrl/xc_pm.c
@@ -46,35 +46,33 @@ int xc_pm_get_pxstat(xc_interface *xch, int cpuid, struct xc_px_stat *pxpt)
 {
     struct xen_sysctl sysctl = {};
     /* Sizes unknown until xc_pm_get_max_px */
-    DECLARE_NAMED_HYPERCALL_BOUNCE(trans, pxpt->trans_pt, 0, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
-    DECLARE_NAMED_HYPERCALL_BOUNCE(pt, pxpt->pt, 0, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+    DECLARE_NAMED_HYPERCALL_BOUNCE(trans, pxpt->trans_pt,
+                                   pxpt->total * pxpt->total,
+                                   XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+    DECLARE_NAMED_HYPERCALL_BOUNCE(pt, pxpt->pt, pxpt->total,
+                                   XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
 
-    int max_px, ret;
+    int ret;
 
     if ( !pxpt->trans_pt || !pxpt->pt )
     {
         errno = EINVAL;
         return -1;
     }
-    if ( (ret = xc_pm_get_max_px(xch, cpuid, &max_px)) != 0)
-        return ret;
-
-    HYPERCALL_BOUNCE_SET_SIZE(trans, max_px * max_px * sizeof(uint64_t));
-    HYPERCALL_BOUNCE_SET_SIZE(pt, max_px * sizeof(struct xc_px_val));
 
     if ( xc_hypercall_bounce_pre(xch, trans) )
-        return ret;
+        return -1;
 
     if ( xc_hypercall_bounce_pre(xch, pt) )
     {
         xc_hypercall_bounce_post(xch, trans);
-        return ret;
+        return -1;
     }
 
     sysctl.cmd = XEN_SYSCTL_get_pmstat;
     sysctl.u.get_pmstat.type = PMSTAT_get_pxstat;
     sysctl.u.get_pmstat.cpuid = cpuid;
-    sysctl.u.get_pmstat.u.getpx.total = max_px;
+    sysctl.u.get_pmstat.u.getpx.total = pxpt->total;
     set_xen_guest_handle(sysctl.u.get_pmstat.u.getpx.trans_pt, trans);
     set_xen_guest_handle(sysctl.u.get_pmstat.u.getpx.pt, pt);
 
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index db658ebaddd5..de319329e6b0 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -319,6 +319,7 @@ static int get_pxstat_by_cpuid(xc_interface *xc_handle, int cpuid, struct xc_px_
     if ( !pxstat)
         return -EINVAL;
 
+    pxstat->total = max_px_num;
     pxstat->trans_pt = malloc(max_px_num * max_px_num *
                               sizeof(uint64_t));
     if ( !pxstat->trans_pt )
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 14:47:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:47:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981611.1368057 (Exim 4.92)
	(envelope-from )
	id 1uEUR1-0005rK-Rj; Mon, 12 May 2025 14:47:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981611.1368057; Mon, 12 May 2025 14: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 1uEUR1-0005pF-LA; Mon, 12 May 2025 14:47:15 +0000
Received: by outflank-mailman (input) for mailman id 981611;
 Mon, 12 May 2025 14:47:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEUR0-0004eT-G4
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:47:14 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fe10d5d7-2f3f-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 16:47:14 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5faaddb09feso9077754a12.2
 for ; Mon, 12 May 2025 07:47:14 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197bd219sm634459366b.141.2025.05.12.07.47.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 07:47: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" 
X-Inumbo-ID: fe10d5d7-2f3f-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747061233; x=1747666033; 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;
        bh=01JaPJq1HUIfLyd6p/KMDQycku6jkHQu8doHAfMrhUM=;
        b=eQKPkY8A1KSahdaUcxpyy3bCEU9rotVhgE2NiT9Vz2KrVby5tcR4ansAIcoMQouhpM
         3+HL48JlduX67HBxdobjijMSCwDOREYQ0e//soEKSjizbsb/Vb1OpGriSUOUrNrSJKqq
         vkcpWkMpMpyiubiomuTyk/zQ+6pT+fG8cTseA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747061233; x=1747666033;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=01JaPJq1HUIfLyd6p/KMDQycku6jkHQu8doHAfMrhUM=;
        b=E7h/ddzfWVb8K4c+tldZalmz3EcKcU9bys/TecYFHYyiXHiwJ0XWxtTVzy4Lvmi/jl
         dnmEp+mDqtlz1HWw/5UaOTvgCmi16KWx01/XHZXx5Pbx9XTmAeYTgfXzdVby0FNWC9Ol
         k70skYd8oQP/IGznExrlpXKlzggDVkp6UFI/iA/8iT6ItbtlNcTmsSsG3XfOtlAjJuO9
         bMSfOKqubn4HkARwPntgxIwCeJI9zr78xsDtmON1NjlVlUiA5oGppNCUwbEVHutj/vDo
         yd9lvdkQHvddw07RlQd6lv4rfLa3kBE8PlsH1k/aIxsXqZeu/DgFMQMJDGjkd/ZwxtGe
         Jvgw==
X-Gm-Message-State: AOJu0Yzm+usMmuRyIxLAoHgNzEWXwLio2VrqEZXQy1jvTuLTFqV5tngW
	rEj5PJPEcCjosN2TANJQH9MjRk1ssfpP2jvF2Pya9TagOg/bt9n/BtT11c7MTt8q9Bm5LhUkz44
	=
X-Gm-Gg: ASbGnct/VpQ5QXVtuT1xtK7yf3/yX5DPWZr/E4T70tXX7gj5OkdSM866HKJlVfyKfhM
	+XQL1Eodz7EPl014hjAwgXL0k4fsl8hIsNauDTe/+Zn++lPeaMMDgtGZ2W/U7THU/Z0QfeLwkr4
	BgPwubMqkWkCKpBdFDQcFk2loFpV6hdflP8y2GNsw2MBiw7Rg1HdZUCBCTLp9NEOxH5M23TtVA3
	jQRMmEvVTHOhQ26Qs8Vo34FUp+gUeX6sZZHsHcwWfwK9JeW+L9Zm9YfYYmNiAbMab8XY1hBNCbh
	8HucQ5b9sdBPl4A817X8TJi1/tu+AfZGUzYzOYVwUAZvFf7LA6rwjrw/vJYxxlF5lrU+sPDLLg4
	=
X-Google-Smtp-Source: AGHT+IEBx/JzvRvtyi20dg41RTK2744kQ4OpYwLZRVXJH0s8BIZ5GL4/1D1aW4SSUruHPIoM8r1NyA==
X-Received: by 2002:a17:906:f80f:b0:ad2:238e:4a1b with SMTP id a640c23a62f3a-ad2238e4b77mr1010070866b.15.1747061233344;
        Mon, 12 May 2025 07:47:13 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Anthony PERARD 
Subject: [PATCH v2 5/5] libxc/PM: Retry get_pxstat if data is incomplete
Date: Mon, 12 May 2025 15:46:56 +0100
Message-ID: <20250512144656.314925-6-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250512144656.314925-1-ross.lagerwall@citrix.com>
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

If the total returned by Xen is more than the number of elements
allocated, it means that the buffer was too small and so the data is
incomplete. Retry to get all the data.

Signed-off-by: Ross Lagerwall 
---

* New in v2.

 tools/misc/xenpm.c | 49 +++++++++++++++++++++++++++++-----------------
 1 file changed, 31 insertions(+), 18 deletions(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index de319329e6b0..d5387f5f0693 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -312,29 +312,42 @@ static int get_pxstat_by_cpuid(xc_interface *xc_handle, int cpuid, struct xc_px_
     int ret = 0;
     int max_px_num = 0;
 
-    ret = xc_pm_get_max_px(xc_handle, cpuid, &max_px_num);
-    if ( ret )
-        return -errno;
-
     if ( !pxstat)
         return -EINVAL;
 
-    pxstat->total = max_px_num;
-    pxstat->trans_pt = malloc(max_px_num * max_px_num *
-                              sizeof(uint64_t));
-    if ( !pxstat->trans_pt )
-        return -ENOMEM;
-    pxstat->pt = malloc(max_px_num * sizeof(struct xc_px_val));
-    if ( !pxstat->pt )
+    for ( ; ; )
     {
-        free(pxstat->trans_pt);
-        return -ENOMEM;
-    }
+        ret = xc_pm_get_max_px(xc_handle, cpuid, &max_px_num);
+        if ( ret )
+            return -errno;
 
-    ret = xc_pm_get_pxstat(xc_handle, cpuid, pxstat);
-    if( ret )
-    {
-        ret = -errno;
+        pxstat->total = max_px_num;
+        pxstat->trans_pt = malloc(max_px_num * max_px_num *
+                                  sizeof(uint64_t));
+        if ( !pxstat->trans_pt )
+            return -ENOMEM;
+        pxstat->pt = malloc(max_px_num * sizeof(struct xc_px_val));
+        if ( !pxstat->pt )
+        {
+            free(pxstat->trans_pt);
+            return -ENOMEM;
+        }
+
+        ret = xc_pm_get_pxstat(xc_handle, cpuid, pxstat);
+        if ( ret )
+        {
+            ret = -errno;
+            free(pxstat->trans_pt);
+            free(pxstat->pt);
+            pxstat->trans_pt = NULL;
+            pxstat->pt = NULL;
+            break;
+        }
+
+        if ( pxstat->total <= max_px_num )
+            break;
+
+        /* get_max_px changed under our feet so the data is incomplete. */
         free(pxstat->trans_pt);
         free(pxstat->pt);
         pxstat->trans_pt = NULL;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 14:50:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:50:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981651.1368066 (Exim 4.92)
	(envelope-from )
	id 1uEUU7-0000Ga-8r; Mon, 12 May 2025 14:50:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981651.1368066; Mon, 12 May 2025 14: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 1uEUU7-0000GT-6M; Mon, 12 May 2025 14:50:27 +0000
Received: by outflank-mailman (input) for mailman id 981651;
 Mon, 12 May 2025 14:50:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEUU6-0000GN-KD
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:50:26 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6f78f79b-2f40-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 16:50:24 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ad238c68b35so432754866b.1
 for ; Mon, 12 May 2025 07:50:24 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad22a3a1501sm503204766b.121.2025.05.12.07.50.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 07:50:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6f78f79b-2f40-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747061424; x=1747666224; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=6oZNQb/xEs5YyNa3I9FOEMw3ehWkBbYRL9ptJa2iUDs=;
        b=vBr9bGCPRZVonKLCDzfuuxQ/xGBHEolB5BdDsDsBoxNystfESHENvhNVQhfyV/meZK
         ChfECtFR7fe+6gdpEZeGX9o+2eKobrQge/TUf0oGFkc9qF54elLhbBwMu8YgVw/6fyp4
         0MNEpsHKCdmfDO6ZQV38ODPR/OySE7QAXDMfE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747061424; x=1747666224;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=6oZNQb/xEs5YyNa3I9FOEMw3ehWkBbYRL9ptJa2iUDs=;
        b=dv1NzElZZRhjR94zWhqugEroTpBdPVuFFgei9AOirWNWiyPJpAo6G/80BUeyaD7io0
         6L8nJoKdqEvSEC0kV3nofxqHnRKhhdYpLzzI5ORChQZEGt8S2q9q4Gy7exC29vWPmV4G
         8BTgTkcpw7XPSHZXt1RygIAAtRcbeyoL1YhzUiyzqB0tkolYQciLR+HI9aT9XuDoRGeJ
         kYQ9Qh6nH8oinAN0fvgVDBRNPg/HGhDpgRKnL/R0gEWE0mcf86aepAUn27VvDSXLHuIP
         BZKggQQE2HRXkuZCVebZbucYqk5MTyalv6U8+OU285OBJBcmmYro2VwddBt45bk2hA1L
         csnw==
X-Gm-Message-State: AOJu0YzV9GuxdqCCKa/nTtDCo/Xz9hwlLnWC24fi3o8cvLPOwtkoUREG
	FFu78ijZ/nOFar393rfAQdixxRm7ip3oXXWhK3mePnokQcltdkkfDCAKdr5Qd+BEY+AvP0Xtg7/
	p
X-Gm-Gg: ASbGncvU6C5ps87L1LdPR8ilXq6ZryxVQesZTnd2Ll/xrKNCOOF1ild4WQG8YchbXDV
	f8ir0gKu/lyXSpRX7BRJommzpWrnydCWlHvfBPUGeiwNr3XU39yFXVsYBwbi5I+dQz/+TVwDDGh
	dHobIEFBDD/IIB85HO12Y1fI5bOEcD3cLVM9rA/eABH5w6nCON0F8PD/T3rRA0NMIU808UYoDju
	ofsiBym1qsB/CUaY1a7LNtttyFwYd04BPwuCWWDRUoJuqGY8I5UTvp2iSbVHd0XmfrGIHXCKElF
	v0/rg9LWx75e2Hero/GHG5v2vYlfOkM/0LIquMjjXGa738wQ3ksK9gJO
X-Google-Smtp-Source: AGHT+IFs7VjS7QiiNngk4TZCclha7Qvs9KkdCp7ReDVoSqhKJBBKPwaq4fNuAl6TMIzdDX8rKyXT2Q==
X-Received: by 2002:a17:907:3e8d:b0:ad2:3555:f535 with SMTP id a640c23a62f3a-ad23555f608mr879059566b.5.1747061423758;
        Mon, 12 May 2025 07:50:23 -0700 (PDT)
Date: Mon, 12 May 2025 16:50:22 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner
Message-ID: 
References: 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Mon, May 12, 2025 at 04:40:29PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, May 12, 2025 at 04:19:59PM +0200, Roger Pau Monné wrote:
> > On Mon, May 12, 2025 at 03:31:19PM +0200, Marek Marczykowski-Górecki wrote:
> > > On Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monné wrote:
> > > > On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-Górecki wrote:
> > > > > Hi,
> > > > > 
> > > > > I wanted to post another revision of the series adding hw12 runner,
> > > > > hoping that all known issues are fixed now, but unfortunately there is
> > > > > still something broken. I've rebased my series on top of staging
> > > > > (ed9488a0d) and got this pipeline:
> > > > > 
> > > > > https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1807819142
> > > > > (note due to some added debugging, some tests are incorrectly marked as
> > > > > success even if they failed...)
> > > > > 
> > > > > 1. USB ethernet doesn't work on PVH dom0: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739
> > > > > There supposed to be an USB ethernet device connected to the USB
> > > > > controller at c3:00.4. In the PV dom0 case it's detected as:
> > > > > 
> > > > >     [    3.911555] usb 7-1.4: new high-speed USB device number 3 using xhci_hcd
> > > > >     [    4.004201] usb 7-1.4: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
> > > > >     [    4.004675] usb 7-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
> > > > >     [    4.005079] usb 7-1.4: Product: USB 10/100/1000 LAN
> > > > >     [    4.005349] usb 7-1.4: Manufacturer: Realtek
> > > > >     [    4.005599] usb 7-1.4: SerialNumber: 684D35
> > > > > 
> > > > > But it's not there on PVH. The USB controller itself is detected, just
> > > > > not device(s) connected to it. This applies to other controllers too
> > > > > (there should be about 3 or 4 other USB devices - none of them show up).
> > > > > 
> > > > > 2. There is a bunch of "unhandled memory read" errors during PVH dom0
> > > > > startup: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739
> > > > > 
> > > > >     (XEN) [    4.026323] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0020 size 1
> > > > >     (XEN) [    4.026789] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0021 size 1
> > > > >     (XEN) [    4.027247] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0020 size 1
> > > > >     (XEN) [    4.027671] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0021 size 1
> > > > >     ...
> > > > > 
> > > > > This repeats several times. Could be related to the USB issue above?
> > > > 
> > > > Can you try with dom0=pf-fixup?  Those unhandled accesses might be the
> > > > cause of the USB issues.
> > > 
> > > It did got rid of those messages, but USB still doesn't work:
> > > https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/10006580289
> > 
> > Hm, is it possible that the usage of console=xhci is interfering with
> > USB devices?  Could you try to boot without console=xhci and see if
> > you can still reproduce the issue?  You will need the physical device
> > by your side, which I'm not sure it's possible.  Don't know if you
> > host those remotely somewhere.
> 
> I can try, but will need a proper driver there (in dom0?) - AFAIR VGA
> nor efifb doesn't output to HDMI there (and eDP is not connected).
> Anyway, it's IMO unlikely, given it works just fine with PV dom0...

Oh, I see, that's a good data point that it works with PV dom0.
Handling of r/o subpage accesses is still different between PV and PVH
which could maybe explain this, but it's less likely.

Maybe I'm not spotting it, but I don't see any specific errors (like
timeouts) from the XHCI controller on the log?  Neither there seems to
be any errors or warnings from Xen.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 12 14:58:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 14:58:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981672.1368077 (Exim 4.92)
	(envelope-from )
	id 1uEUcH-0001iU-22; Mon, 12 May 2025 14:58:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981672.1368077; Mon, 12 May 2025 14: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 1uEUcG-0001iN-VK; Mon, 12 May 2025 14:58:52 +0000
Received: by outflank-mailman (input) for mailman id 981672;
 Mon, 12 May 2025 14:58:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEUcF-0001iH-4h
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 14:58:51 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 99f5e65d-2f41-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 16:58:45 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-442ccf0e1b3so53234465e9.3
 for ; Mon, 12 May 2025 07:58:45 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442cd34bde2sm169088925e9.19.2025.05.12.07.58.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 07:58: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" 
X-Inumbo-ID: 99f5e65d-2f41-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747061925; x=1747666725; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=oECtGyyiEbPi9KU2nBruScd8gOF2xB3/flfzNokTBcM=;
        b=c10NYhyxocF0goXqPe3fORb/dGCfKGjM5yNoUr3VIXAgsVdtI2pz58aZ+N2XT36Um3
         BFG1AoEf31aL1jvJvLJLFgy75vWBC+kC42wOtRiD0BrfqOPIzuJYZO36CqeqLW7ac8jB
         XKrPL8XJiLPXbxIBI3+HGyEIy7v7xteq/qzaU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747061925; x=1747666725;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oECtGyyiEbPi9KU2nBruScd8gOF2xB3/flfzNokTBcM=;
        b=AMxBoYZqyqUlWs6NYF+/KpjwmJlL/AYdRpKnJ37pGLHtVcME5t2U/F/gDZ9R0vsbIg
         hN6/NbtDTg1U7o11mEZ0PK94R66ky6LRp6r/uQYQGTVaZAqsB3LrV3VGyN4yD4BUKaZy
         +V87k8K/sMcxfFT74+bPJVYMJTgEkWFdqfIRgasn1H3JBsi1+LB3zA9KXcKZkyI8dIpz
         eMHscqYQX4isMNDvHowI+4OYClMLqS3kT3lT0VXpkkcEA8I5nsGbgpKIjiXBQtSdCW+z
         PeVWzsz1UcFAXUWXDKibni4fxUXzhgoia4xem0FVHlJMml28hPismXzMm8qdqjWBI9/J
         4kxA==
X-Forwarded-Encrypted: i=1; AJvYcCVEUJ8byPSSH9CpbwEzypqDRZLa0R8fqtRKbApaQgducT/7ubq7DUJNVN7ZeMHD2T3N0ZJDkaYKay8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyIRHgsNxxZYsg/Rr/dtCCycMTkZcz3lFB6YAEZPRFtZZ9WiF+T
	cLPCheOBkt62bLsOjTdxNpOPboZS5DLtEdGyvZvSd0rYsbx9w65D26AjQF/V2bA=
X-Gm-Gg: ASbGncunSOdhvmHSSGvcotQaEOKApK3OuOHZjUTjTcbatvFBw2BCa//JOtIsM0qReFs
	HTwYPBUPuT22geZzmTAUvZP/owc+gt06VAlI/lQ3ks+EdKcUmJU6vrDpHgzrlMV+9z56+uGlN6E
	Y5BCXghEHJzgjfsk5IdfAGyhzA/L28jYjHa+hzY4doZZNGNDTbrK5XF4wohdx0XnRKTO3F6rt1p
	jaWBp6TPo156mLFCbD72M7QoQ3/+RZCERNfNaVS86+57R8RwLwouMWELEuWnIziLugd3lhvOcTN
	3uu4Xw1G7Ag4FIidZEjIz0Fs1QeAK1rH8WYLjNEYm22XfbZTj0uCd2UnZaWizV2e82Xz3t5lP1/
	XAVi2RXKILq7Bt1SR
X-Google-Smtp-Source: AGHT+IEW7PuhQk6tqVlitcwb25jEIiD7HkCOPGAUZblwFTjuhLPszhi9agikIkQc6V5LgJP0OKNLxw==
X-Received: by 2002:a05:600c:46c3:b0:43c:f44c:72a6 with SMTP id 5b1f17b1804b1-442d6d18bdcmr122788675e9.2.1747061924600;
        Mon, 12 May 2025 07:58:44 -0700 (PDT)
Message-ID: <63652356-4b82-401f-a6ba-8eb53b2f8317@citrix.com>
Date: Mon, 12 May 2025 15:58:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/Kconfig: Improve help test for speculative options
To: Jan Beulich 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Xen-devel 
References: <20250508160336.2232152-1-andrew.cooper3@citrix.com>
 <18f73078-c512-416b-9406-c76f8db178eb@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: <18f73078-c512-416b-9406-c76f8db178eb@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/05/2025 11:58 am, Jan Beulich wrote:
> On 08.05.2025 18:03, Andrew Cooper wrote:
>> The text for CONFIG_INDIRECT_THUNK isn't really correct, and was already stale
>> by the time speculative vulnerabilities hit the headlines in 2018.  It is
>> specifically an out-of-line-ing mechansim, and repoline is one of several
>> safety sequences used.
>>
>> Some of this boilerplate has been copied into all other options, and isn't
>> interesting for the target audience given that they're all in a "Speculative
>> Hardning" menu.
>>
>> Reword it to be more concise.
>>
>> 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 
>>
>> CONFIG_SPECULATIVE_HARDEN_BRANCH really ought to be named
>> CONFIG_SPECULATIVE_HARDEN_CONDITIONAL, but this would be a (minor) functional
>> change.
> Hmm, so you're suggesting all the straight-line speculation changes then ought
> to be conditional upon a separate, new Kconfig control? So far I've keyed them
> all to this one.

Straight line speculation is complicated in multiple ways, and our
understanding has evolved over time.

I'd forgotten that we grouped it with HARDEN_BRANCH, and it is not an
ideal grouping.  What we have in the way of SLS protections are token at
best.

First, in light of Branch Type Confusion on Fam17h processors, where any
instruction can manifest as a speculative branch, there's nothing that
can be done.  (This was demonstrated rather more thoroughly with SRSO
than BTC.)

There is straight line decode (at least) through any branch the
predictor doesn't know about.  Only "taken branches" get tracked, but
also you get a higher rate of SLS immediately after leaving userspace
for a long time (such that the branch predictor fully lost supervisor
state).  Again, this is inherent and we cannot control it.

Intel say that a branch type mismatch (for a direct branch) will halt at
decode.  Indirect branches are documented to potentially suffer SLS. 
AMD Fam19h say that any branch type mismatch will halt at decode.  Also,
with AMD IBRS, indirect branches stall dispatch until they execute.


Therefore, it's indirect branches which are of most concern.

Putting an INT3 after any unconditional JMP *ind is easy.  Compilers
even support doing this.  CALL *ind on the other hand has architectural
execution beyond it, so if protection is needed, LFENCE is the only option.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 12 15:05:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:05:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981685.1368087 (Exim 4.92)
	(envelope-from )
	id 1uEUiD-00049B-Oh; Mon, 12 May 2025 15:05:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981685.1368087; Mon, 12 May 2025 15:05: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 1uEUiD-000494-Lp; Mon, 12 May 2025 15:05:01 +0000
Received: by outflank-mailman (input) for mailman id 981685;
 Mon, 12 May 2025 15:05:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEUiC-00048i-JA
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:05:00 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78706fd7-2f42-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 17:04:58 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-acb39c45b4eso745907766b.1
 for ; Mon, 12 May 2025 08:04: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
 a640c23a62f3a-ad24121e992sm359062466b.14.2025.05.12.08.04.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08:04: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" 
X-Inumbo-ID: 78706fd7-2f42-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747062298; x=1747667098; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=unh1Z08yi853tTMmNV7mBkk/ke51ca0jr1QFjP9DroA=;
        b=Ue3/Zb3/5/E/9x9O5VD+/2m/80O6zC4/ie1s42WvLUxFWn3HSVZSNm0SSW/nF+HRkN
         gCRCiajy7TWsuzmP0hKaRxFR4VJVPDiKP85kIR/e1MQs29W9/Mee/CD3Wru1g9l559Pd
         iR6bLOCx32gBTL/LyucVarB2lSWyANKxN4S5gxGx0pSlX11Q07VO9v/f21FgHnLing9H
         DBnqsghRJjBqFFKvLdHYWKftSPpTZiw111iAimPwkzZFNDsvAnGZB639ncH8UFcRVjtk
         te20SAuRDEc7IyobdrvzQ6xYKIG2HIj/Mv5NZnqPQf0ZDuRgTZzeBD5zphRGDqFoQW88
         UWUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747062298; x=1747667098;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=unh1Z08yi853tTMmNV7mBkk/ke51ca0jr1QFjP9DroA=;
        b=Gbar+QXyB++sNf/o8L+EsgwU2ZIA/LJ7debGRl17VWde6szNe6YAke5M5Loy8f5jFr
         FiEjKw04qWJnU97aziK4iXPZ0Kids/LeMpb+iA6u4/5nziMQwVhuccA3Smr7raSMKU7+
         ojkqFx2wjeUHgOXuQAKgaWG72cpzdtcBGQ5oF0pkfKB4Dc2axKNVg4oPBhMMC8YA7XFn
         0sXXztX7rU2gD8dLMcMIDukCZ//z0yWJDAprkbF/9WhjSLzU6vrQm8Xdh5BZ8WyxpvJm
         X+b2YJvnJ7UixCkKvtESN4x1P1agkYNJdl1KIHttQNOi1mM+p4DyZ7gxt3wqQHdMUPQp
         SphQ==
X-Forwarded-Encrypted: i=1; AJvYcCWlN2yV51evoYyEcaFhNfmmgbnPJW5WLuMXpj/X1DOWytwjH1AKXVKHj5mex9JtEkQqat8HROFprso=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxX1asoJzi3O2s/y7KYfOnHGCTV6hZh4DlXLKR4tPdKaSjxhpD6
	XGdEU2+7TKlaJAhtV3Ll3DMrqYjAzo7Y04j+5Sbi/XZnp0NFyTlHhjI2R/55mA==
X-Gm-Gg: ASbGncsv1qfG/eCbUYwN88LnHO5Vpm2V6uzbAjawgr5LWZxBmztSoNgCJdp+eY1YDEP
	YdpcZ0xrofQ4XMCmrVnbt1AOC2lBB9jzvcH1g3OTvwAKNZgUxCnEVVAeUD5BmW1hfIxJPmjqhl2
	jIv1rDrjmgHW6n1dZ7Ew5sVjUBDcQFTW7goxt1jY0QcH9MiFlsu9C/OmblljyACDUbL5su1X2WT
	JDH5Dy4ul+sD5t5Nr4hDhuSfcVWUvnrgp9nWrccmNfCEIzJTWwACCw32yX293FgKRCdQaL4kAQU
	kViQjPe7g++yIXM9jcaT7tguQZo8LICiYURjwIyyQnlUqsSIFcaU3vPnbp9XLPGt+epfGmJ1AVu
	r0gbNrQGvX+yfVcqeDH0/prf4Tx6wRYcVIbk1
X-Google-Smtp-Source: AGHT+IHIufP0jYW6y/4AHW+DTVoBN67DkruUehK8TXSz5LL7qGijP9kOuuL13ctSG5wUwERzq93p7w==
X-Received: by 2002:a17:907:7fa6:b0:ad2:54c5:42e8 with SMTP id a640c23a62f3a-ad254c54483mr279783366b.8.1747062297748;
        Mon, 12 May 2025 08:04:57 -0700 (PDT)
Message-ID: <853ffc16-f14b-44fa-9e71-4fae8377fa95@suse.com>
Date: Mon, 12 May 2025 17:04:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/9] x86/mtrr: use memory_type_changed() in
 hvm_set_mem_pinned_cacheattr()
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-6-roger.pau@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: <20250506083148.34963-6-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.05.2025 10:31, Roger Pau Monne wrote:
> The current logic partially open-codes memory_type_changed(), but doesn't
> check whether the type change or the cache flush is actually needed.
> Instead switch to using memory_type_changed(), at possibly a higher expense
> cost of not exclusively issuing cache flushes when limiting cacheability.
> 
> However using memory_type_changed() has the benefit of limiting
> recalculations and cache flushes to strictly only when it's meaningful due
> to the guest configuration, like having devices or IO regions assigned.
> 
> Signed-off-by: Roger Pau Monné 

Hmm, I'm not convinced this is a win. This operation isn't normally used on
a running guest, aiui.

What's more, this heavily conflicts with a patch posted (again) over 2 years
ago [1]. Unless there's something severely wrong with that (and unless your
patch would make that old one unnecessary), I'm again of the opinion that
that one should go in first. It is becoming increasingly noticeable that it's
unhelpful if posted patches aren't being looked at.

Jan

[1] https://lists.xen.org/archives/html/xen-devel/2023-03/msg01551.html



From xen-devel-bounces@lists.xenproject.org Mon May 12 15:10:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:10:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981692.1368096 (Exim 4.92)
	(envelope-from )
	id 1uEUn7-0005N0-9f; Mon, 12 May 2025 15:10:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981692.1368096; Mon, 12 May 2025 15:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEUn7-0005Ma-6k; Mon, 12 May 2025 15:10:05 +0000
Received: by outflank-mailman (input) for mailman id 981692;
 Mon, 12 May 2025 15:10:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEUn6-0004zQ-9I
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:10:04 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2d9c65cd-2f43-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 17:10:02 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5fc3f0a5506so933186a12.0
 for ; Mon, 12 May 2025 08: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
 a640c23a62f3a-ad225a6bac2sm550603866b.101.2025.05.12.08.10.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08: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" 
X-Inumbo-ID: 2d9c65cd-2f43-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747062602; x=1747667402; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Rp7tiJIV3rnHgB93GQ0E3AMTocGLPGRp9ek9HbTTwME=;
        b=AudirPBh3Cayytmns04so/r+brO70ZOlwe/K3KwbeSNuOG45NFqcEMfahYouxFFT1r
         uzNweG1kS/o8+vjKsXWEZBzFfrWVhnQxxAtanlwohg3M9kPNLtdu5VuRQK3bnhV3YjEk
         P2qH7fsocxMG/FchQeGinF9Dw51xPScduXm2XwQRVs8KLKAvbbi+PceIWnrbFS909hmE
         6NQjgm3WLI8dxaanL9Zb1B9+rCh1snSK33TRA6cS+8Z1kctyzLusPD5t8rDgXsE5O6QE
         lIgA2lpXKz6Gw6lJjsUjWY2P0wPYW6SqEvyt0dNDskRrnxKgq/sH976mbj+JB8mpEqLJ
         uCdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747062602; x=1747667402;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Rp7tiJIV3rnHgB93GQ0E3AMTocGLPGRp9ek9HbTTwME=;
        b=oJ/bWy04GW8Ld2zSJww6JyMwllKCc3OW8/h4he7VlPfBl9Au4nZBt93YCD3GeYh+wy
         h5p08kPnPJcnMvdHIzZYyG6vdyHKHjuTV58csUbiDOWqaTE38QRjTzqmL6tVOJJbTk7O
         gp+c5O8g1tMcscd8MkCoBTGB/9I+21Meip9I77m7kmO6nEyGRzCz4plNhvTUrZVTWe01
         i6FVkhMnyj3PzcC57qjengltJPIdZP47grHTs/XFPs5hRSjzD0cv/h5DB3OHf2pZiGk8
         xr7mSkxw1/VZdZ0RMmVKcsWyOSfdAR7CKXDLi+Of4qizT3VgUOWvc9uCxPqkrEJH4Dd+
         zKcg==
X-Forwarded-Encrypted: i=1; AJvYcCWboUx8dGIn/kIx+z8yt4vkb7cdUWx6e0bNGtSHQiTXpSkeSvtCEhkQqfBIf7mHFvoGZJbXBVuUgus=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxbh1pi3NvvBndbycSaTarIWFe4Jy78TbH27v2lhuZnor0LcZRg
	PUUJkdwo3CByIqDsVU0RM3CeaGSCXYYFCMCrmJZ+0R6rqlYIyjyhP/Rufy8/Pw==
X-Gm-Gg: ASbGncvlFDLO75+1YeMK2xaGQxt7rLrM0gdSO7pHmEOzSRM9X+0sz4qvLRarIaPgoj1
	4ZXaSsNyDjMXdEiWCkjwF5NfWDbLNzW9UmACLufuxcUZa/TKzxiAj77FT3gUVdN0A2SgrKJTxVK
	8pb5zgxv06J3cmAVdn7rdX8dyNoeZjUm7il3yOkYGaEOBsl9aPKj9OHpdxzlwnAe9XNeffBO5fF
	npHniRBHcH5zhswu6POiGhX21/6sWmqFS/qho4iE7vsSSQdxD0xSNmoCr0+jCZijv6DQy825Li9
	uVFX723BRhG9yL/BaSExiNIQf+Lg8r2Ba8H/TlE6vpLbIHOjvCUcmOUGIIp8VFHxfOn4hYFZxtC
	Cu8FA/F3GbeKLIPgWfwV8kpTNDS7SSs+bK7S2
X-Google-Smtp-Source: AGHT+IFjTRqfI+Vnr0XiLOGcimLe6d/X8BkHTZF7LXKz1OYE4qvCK2pQMXw346Q2lr6bfo9UsgwkFQ==
X-Received: by 2002:a17:907:6e94:b0:ad2:428e:dd2a with SMTP id a640c23a62f3a-ad2428ef7c1mr678244266b.60.1747062601709;
        Mon, 12 May 2025 08:10:01 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 17:10:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/9] x86/p2m: limit cache flush in memory_type_changed()
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-7-roger.pau@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: <20250506083148.34963-7-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.05.2025 10:31, Roger Pau Monne wrote:
> Only do the cache flush when there's a p2m type change to propagate,
> otherwise there's no change in the p2m effective caching attributes.
> 
> If the p2m memory_type_changed hook is not set p2m_memory_type_changed() is
> a no-op, no recalculation of caching attributes is needed, nor flushing of
> the previous cache contents.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon May 12 15:12:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:12:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981699.1368107 (Exim 4.92)
	(envelope-from )
	id 1uEUoz-0006hy-LQ; Mon, 12 May 2025 15:12:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981699.1368107; Mon, 12 May 2025 15:12: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 1uEUoz-0006hr-IE; Mon, 12 May 2025 15:12:01 +0000
Received: by outflank-mailman (input) for mailman id 981699;
 Mon, 12 May 2025 15:12:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEUoy-0006fd-3q
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:12:00 +0000
Received: from fout-b2-smtp.messagingengine.com
 (fout-b2-smtp.messagingengine.com [202.12.124.145])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 71d7161a-2f43-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 17:11:57 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfout.stl.internal (Postfix) with ESMTP id 455191140152;
 Mon, 12 May 2025 11:11:56 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-05.internal (MEProxy); Mon, 12 May 2025 11:11:56 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 12 May 2025 11:11:55 -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" 
X-Inumbo-ID: 71d7161a-2f43-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1747062716;
	 x=1747149116; bh=7jc6TjKAOKtRsxnHmSgPk0zJ1JgwyBLUJAhdDZv3T1A=; b=
	ig9brFlmWR7T7UPQ3XwhfMljdbnNuGszNu4E3sVSV6ndFrFef3z4p9qId8clAVwD
	Lf10rnQxGZcZ3q9p3JV0z6fXaWP8zzsobC3u6jcYi4TfFPPvqzo6EdmFtyu70Fae
	llVaxVoeKWrJ/yFLuDjjUHjcbB+T6LZHKr7swU/BAQWSTFpoepjGbcCpDeK1m7cA
	ks8Jzy7zQCSeyvC5oqLJ8SQzd+Q4EhUA9UPU+X3WJh94cA3clBtXXkUYcjVlO3pg
	sKmDTWmvNrWUJ5Udn5ILVrUfTfRG54c++63glrUT2SAQI5S9iIhWtSEcc8jMYNRL
	ivuQHyLKXmJIU7A2AjejFA==
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=fm3; t=
	1747062716; x=1747149116; bh=7jc6TjKAOKtRsxnHmSgPk0zJ1JgwyBLUJAh
	dDZv3T1A=; b=Z8cAyo+WG4r2Zi2pJSBfMQf7FnH2hQj/mWc7fApLdG57mXADU6L
	Q2WVEkD84V1C5KZwloRYpFsV8q4w9rBxTAurUPZ9+8Py+9TLukbMpjfgyw7pozU4
	Q0iE1JcLM+b9S8jLl0BCzEAsa/Qw2uEzcWm68cZYSmAXFt8/ew1jILB4IPEcE9Nt
	QyEJ8d3ruF51MMgSo2NgIj0g3Gt1KQJBPXZuW0fhWKdCuTWDjT7fd9PV39SXpTXj
	KUULQekfAkJYGMT6YvvI/e6oSAD0BCk1jOp/ifXMdEEyHhyr8ihKwBhs4/k4TMLd
	RxQ0HDSs6kSlmoChJxZpqaYEuviM7eymecQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdduheekucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepveeujeetgeelleetudeuvefhtefgffejvedtvdfgieevheethe
    elgeeuledvjeevnecuffhomhgrihhnpehgihhtlhgrsgdrtghomhenucevlhhushhtvghr
    ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvh
    hishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedvpdhmohgu
    vgepshhmthhpohhuthdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg
    homhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggt
    thdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Mon, 12 May 2025 17:11:53 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner
Message-ID: 
References: 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="Jr4GwN9SOrWZoMwX"
Content-Disposition: inline
In-Reply-To: 


--Jr4GwN9SOrWZoMwX
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 May 2025 17:11:53 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner

On Mon, May 12, 2025 at 04:50:22PM +0200, Roger Pau Monn=C3=A9 wrote:
> On Mon, May 12, 2025 at 04:40:29PM +0200, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > On Mon, May 12, 2025 at 04:19:59PM +0200, Roger Pau Monn=C3=A9 wrote:
> > > On Mon, May 12, 2025 at 03:31:19PM +0200, Marek Marczykowski-G=C3=B3r=
ecki wrote:
> > > > On Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monn=C3=A9 wrot=
e:
> > > > > On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-G=C3=
=B3recki wrote:
> > > > > > Hi,
> > > > > >=20
> > > > > > I wanted to post another revision of the series adding hw12 run=
ner,
> > > > > > hoping that all known issues are fixed now, but unfortunately t=
here is
> > > > > > still something broken. I've rebased my series on top of staging
> > > > > > (ed9488a0d) and got this pipeline:
> > > > > >=20
> > > > > > https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/=
1807819142
> > > > > > (note due to some added debugging, some tests are incorrectly m=
arked as
> > > > > > success even if they failed...)
> > > > > >=20
> > > > > > 1. USB ethernet doesn't work on PVH dom0: https://gitlab.com/xe=
n-project/people/marmarek/xen/-/jobs/9978694739
> > > > > > There supposed to be an USB ethernet device connected to the USB
> > > > > > controller at c3:00.4. In the PV dom0 case it's detected as:
> > > > > >=20
> > > > > >     [    3.911555] usb 7-1.4: new high-speed USB device number =
3 using xhci_hcd
> > > > > >     [    4.004201] usb 7-1.4: New USB device found, idVendor=3D=
0bda, idProduct=3D8153, bcdDevice=3D30.00
> > > > > >     [    4.004675] usb 7-1.4: New USB device strings: Mfr=3D1, =
Product=3D2, SerialNumber=3D6
> > > > > >     [    4.005079] usb 7-1.4: Product: USB 10/100/1000 LAN
> > > > > >     [    4.005349] usb 7-1.4: Manufacturer: Realtek
> > > > > >     [    4.005599] usb 7-1.4: SerialNumber: 684D35
> > > > > >=20
> > > > > > But it's not there on PVH. The USB controller itself is detecte=
d, just
> > > > > > not device(s) connected to it. This applies to other controller=
s too
> > > > > > (there should be about 3 or 4 other USB devices - none of them =
show up).
> > > > > >=20
> > > > > > 2. There is a bunch of "unhandled memory read" errors during PV=
H dom0
> > > > > > startup: https://gitlab.com/xen-project/people/marmarek/xen/-/j=
obs/9978694739
> > > > > >=20
> > > > > >     (XEN) [    4.026323] arch/x86/hvm/emulate.c:417:d0v0 unhand=
led memory read from 0xfedc0020 size 1
> > > > > >     (XEN) [    4.026789] arch/x86/hvm/emulate.c:417:d0v0 unhand=
led memory read from 0xfedc0021 size 1
> > > > > >     (XEN) [    4.027247] arch/x86/hvm/emulate.c:417:d0v0 unhand=
led memory read from 0xfedc0020 size 1
> > > > > >     (XEN) [    4.027671] arch/x86/hvm/emulate.c:417:d0v0 unhand=
led memory read from 0xfedc0021 size 1
> > > > > >     ...
> > > > > >=20
> > > > > > This repeats several times. Could be related to the USB issue a=
bove?
> > > > >=20
> > > > > Can you try with dom0=3Dpf-fixup?  Those unhandled accesses might=
 be the
> > > > > cause of the USB issues.
> > > >=20
> > > > It did got rid of those messages, but USB still doesn't work:
> > > > https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/100065802=
89
> > >=20
> > > Hm, is it possible that the usage of console=3Dxhci is interfering wi=
th
> > > USB devices?  Could you try to boot without console=3Dxhci and see if
> > > you can still reproduce the issue?  You will need the physical device
> > > by your side, which I'm not sure it's possible.  Don't know if you
> > > host those remotely somewhere.
> >=20
> > I can try, but will need a proper driver there (in dom0?) - AFAIR VGA
> > nor efifb doesn't output to HDMI there (and eDP is not connected).
> > Anyway, it's IMO unlikely, given it works just fine with PV dom0...
>=20
> Oh, I see, that's a good data point that it works with PV dom0.
> Handling of r/o subpage accesses is still different between PV and PVH
> which could maybe explain this, but it's less likely.
>=20
> Maybe I'm not spotting it, but I don't see any specific errors (like
> timeouts) from the XHCI controller on the log?  Neither there seems to
> be any errors or warnings from Xen.

I don't see any either...

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--Jr4GwN9SOrWZoMwX
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgiD7kACgkQ24/THMrX
1ywHmAf/a1KY5fMYQXtARL8pIynDdEoFAeDFszzLP302nxijIBCwGTVe3nQzJI+N
enbqhUdR9JwWc2nVOY2V40gqzYEx5FVXUDZWjJlhTmRsG/RJTE63+FAX2OjwBRV4
ZQv1bmgtPrpdmVwEgdyXVDenj7/P/L27WgW2aQEJxmFczhx19EFvvDS9jbM/RfOA
kH/jhg6kTNzF2WzBZtV9jYIoZ1GcCygJhgquKLUHUiMSBSwsHlfdJY/04oZaOhxi
Rwc6NECWIA87jm/xx0lZTz5hrE8kMyf/LvdLCuO9LitElhur5H2kokhhiOXfQKwI
OLfpJSVXX7GHaoVt7VYODBQ6TN3pMg==
=wbne
-----END PGP SIGNATURE-----

--Jr4GwN9SOrWZoMwX--


From xen-devel-bounces@lists.xenproject.org Mon May 12 15:16:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:16:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981708.1368117 (Exim 4.92)
	(envelope-from )
	id 1uEUsx-0007RT-4w; Mon, 12 May 2025 15:16:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981708.1368117; Mon, 12 May 2025 15:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEUsx-0007RM-1W; Mon, 12 May 2025 15:16:07 +0000
Received: by outflank-mailman (input) for mailman id 981708;
 Mon, 12 May 2025 15:16:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEUsw-0007RG-41
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:16:06 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0529d887-2f44-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 17:16:04 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5fbeadf2275so7965182a12.2
 for ; Mon, 12 May 2025 08:16: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
 a640c23a62f3a-ad2290a4cc2sm521517166b.183.2025.05.12.08.16.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08:16: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" 
X-Inumbo-ID: 0529d887-2f44-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747062963; x=1747667763; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1vaOAeO+2iZcxputsDsvjqYlnmGm22ZI4rH48ZJ96VM=;
        b=D6wk1Jt7beSU76p6reZgCuDmgIi7BUpsAjKR1j11WJtpM1UHtDftvvhssOHlK0Ssss
         O4ZmKiX0AjDinuuAgkg8EmHbtknSGeWpIxA/U95vN5kp5C4PwHHmK6ijzJwikgPHvr5Q
         xXdUtYmNDQeDWRFNMKwL1OfhbJiGWlGs9P59Ch6Rk8Y3T0dc0mGiY4VMzSJEjeyNrjzq
         cbYBd7SQ4fWplu9zx1gJtObVEstihArOPaMjiOzUhDqYTRekEYvd7OAwz+1ZcW+TOpaa
         qpUeJq5LCau7aIs2QuWUenhW+w4u5cR9QMm1C6Mx8Zf9KquKquNf3Y75q/Y4CSbLsGTK
         SKQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747062963; x=1747667763;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1vaOAeO+2iZcxputsDsvjqYlnmGm22ZI4rH48ZJ96VM=;
        b=eYvJfveu8BVwM8ViKKwxDZUyHcNEXVkIJfJ3cdJebJyoUn0ufPA4nX/WFK8uh3mqPt
         q/SSB/dOnduPHdKturQbzN8lndaKJAlsWwyKQXUCf05ZwBZqA37Ps7eqvO9MXYo//+iH
         S+HYXlZ7Ht/5icXDC7ASK89bB2rQFmBi+/dXDtzv0HYI7475DXNlNOktj/wZj73srQpC
         yri9z5bJ9koSJ7sgXuw+akb+wcZGV172bDmgXAZaDZtZBvXlNOi/gaqIhcrg8vp53qPT
         A6OYg2Wd0mmGQ83COKYlAgJM9KZC9O5BQMzPhgMY6Qwy8tv38Tu8hr+nW9ujR7qMfzmP
         +fcQ==
X-Forwarded-Encrypted: i=1; AJvYcCXrUTNwHNcbWjLr/QGl7vZRxrL/dsDXJ4XJSzLDCNXyCA0wY70T/lDW03M/5aD5aIpO5SIdq2nslHs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEiAsST0Qqq9JGEC+9f5muEV3nBTLr+N9AOft0E8Lwq0eSnLx0
	PQNrJGGQRAZigYOklmKR5zMdaiUXEmqBvR4kbsll83nC9Twh103VT6YLHCtWlw==
X-Gm-Gg: ASbGnct8xputuiwUQPZ/T8Zoelnv1c0Fa7ZDo9DovmARBsp8mXTiQEeRDJUZc+uLEQ2
	PREOh3UglQwdBSJzQ+2NWKb4ORLZIahIcj3dXnxuRKP+0b13MqosPEHAhM3p2FpWlBUuGWv9Egq
	+HEB+azNYMgkrTyC6gevas0bpsSGf9T1mUZB+FDPO4blsgT/jUM8mV6Q0Xp8BtxvZe7gsNqYLGY
	HAtkpGF9bBhlc4WWXhu2Uh9dfCloO5gREJvaKfe6PX1sXSxaKn4LUiJnkUZE49QpfroxOlB+BDc
	1sniyqbtfN5tRs2xRqiVck431onWqW8msIt6BsKqrv7hPZTnqSoRqfzc55vNMAAMSoXk91vgqt/
	Lu0hu/FxYdzVaiCAzaCX9/CBsMS0AazkkFcvO
X-Google-Smtp-Source: AGHT+IGT/brKM2IUCwhqhCRK+2J/fKmc59SeAAQTZPOM1JcySiQGkMtb1Oqj/p+yiR6kqDc8FOmzkw==
X-Received: by 2002:a17:907:8990:b0:ad2:2ba6:2012 with SMTP id a640c23a62f3a-ad22ba6342fmr912545966b.11.1747062963445;
        Mon, 12 May 2025 08:16:03 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 17:16:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 7/9] xen/x86: rename cache_flush_permitted() to
 has_arch_io_resources()
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-8-roger.pau@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: <20250506083148.34963-8-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 10:31, Roger Pau Monne wrote:
> To better describe the underlying implementation.  Define
> cache_flush_permitted() as an alias of has_arch_io_resources(), so that
> current users of cache_flush_permitted() are not effectively modified.
> 
> With the introduction of the new handler, change some of the call sites of
> cache_flush_permitted() to instead use has_arch_io_resources() as such
> callers are not after whether cache flush is enabled, but rather whether
> the domain has any IO resources assigned.
> 
> Take the opportunity to adjust l1_disallow_mask() to use the newly
> introduced has_arch_io_resources() macro.

While I'm happy with everything else here, to me it's at least on the
edge whether cache_flush_permitted() wouldn't be the better predicate
to use there, for this being about ...

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -172,8 +172,7 @@ static DEFINE_SPINLOCK(subpage_ro_lock);
>  
>  #define l1_disallow_mask(d)                                     \
>      (((d) != dom_io) &&                                         \
> -     (rangeset_is_empty((d)->iomem_caps) &&                     \
> -      rangeset_is_empty((d)->arch.ioport_caps) &&               \
> +     (!has_arch_io_resources(d) &&                              \
>        !has_arch_pdevs(d) &&                                     \
>        is_pv_domain(d)) ?                                        \
>       L1_DISALLOW_MASK : (L1_DISALLOW_MASK & ~PAGE_CACHE_ATTRS))

... cachability, which goes hand in hand with the ability to also
flush cache contents.

Tangentially - is it plausible for has_arch_io_resources() to return
false when has_arch_pdevs() returns true? Perhaps there are exotic
PCI devices (but non-bridges) which work with no BARs at all ...

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 15:18:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:18:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981723.1368127 (Exim 4.92)
	(envelope-from )
	id 1uEUvU-00084I-J8; Mon, 12 May 2025 15:18:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981723.1368127; Mon, 12 May 2025 15:18: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 1uEUvU-00084B-GZ; Mon, 12 May 2025 15:18:44 +0000
Received: by outflank-mailman (input) for mailman id 981723;
 Mon, 12 May 2025 15:18:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEUvT-000845-CS
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:18:43 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 639e4a42-2f44-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 17:18:42 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ad2452e877aso274752266b.3
 for ; Mon, 12 May 2025 08:18: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
 a640c23a62f3a-ad2197be656sm625041266b.127.2025.05.12.08.18.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08:18: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" 
X-Inumbo-ID: 639e4a42-2f44-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747063122; x=1747667922; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fUpJg3iDtLKAgpJKRCZ+4fA5gkgvCqcGcbCcDERqGkY=;
        b=O5yU/AXntzsNLsBJPfA2smiGJ+toqoBSGpGIg+w4i/rfwQaVdnE8ZScqSAHgAvUyIS
         LxA0rmpZMlmc6rwNd2LL+otEfbQKxDDlO+LjTbnQxIGxKUd5TWPADwWJ/VbVOUp9b5iQ
         1sqMNtQRrtyDz2/qn+59s+9xQ0Q0Vbm/WIeBk3XbO1uTyTp+XOVz5XoQkMhHuqfBktfW
         Sme2haUFG7Iw+m/oESIgXsSaeVCwtBIxPzjm02splGqBTDVPbFDGDj/jyxuvrZo4Lh2U
         H5yr1K+I+b0MF3bFO2TxfHcRl8KVd2JKLhB3+VUucwGTAAapQQNbPnbi0iEnzH/uJkuX
         2sJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747063122; x=1747667922;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fUpJg3iDtLKAgpJKRCZ+4fA5gkgvCqcGcbCcDERqGkY=;
        b=Xe9cfWnz7yOfT7sbIQWUNeX6HV964enDB2yMQPYclz7cV+bcnF4GAkmHyrqlcRYtGa
         K1wg+L68I/UWNzvuVFuYlR5JH/oo0tqe7pUtZsooNFfpkUEQXs3hWHSYbuNjPzZVPOw8
         b/CQSExaRMX4Fe7Qf1UPBkHULjz17WoGpWN58myjanqUajboV6dh+tuSf/6mFgmZXtn/
         AcLsK9A8iarrveYEsQV8PJMMWOyaz8vbIuPQQ27R0zmmvLhnQcgNGiB8BqVboPQ2g0wd
         XHGAmR+/wcrBEvR3zJMa9TbU1VGK5hMUowE4/txAy1VIGQ6krZYaiNSNgp7ABxn4kals
         4QaQ==
X-Forwarded-Encrypted: i=1; AJvYcCVKRbhEtRDH4y1F8zUmvfjeMoh7msSzlZkPXa9FKC4v7hPGAnIJLEbsfe4xB2Y3SoJm605atfwykoQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwrpyMEy31LQumA4jpuU8SGMmD/4u+bE7o7rvquf4JgkSTGnpdw
	/10rmrsE/HImLUBUFwaUXcs3qmWSnUgmlFjYs1Ge4NLXor98i2cmC1njeY63Cg==
X-Gm-Gg: ASbGncu9tb65fTMdxaM+eaKLlfa+ipVJEP6WPNE6DlaDXmrwCqCgeARjix7ab1oXRv4
	yn59lUQThX8ETPY27YienuCm1+ngjsYIvEbnDgkpe+1Ek7VKrwFIqZswhnxr4w1OiXiFEmSwrT6
	R1yO7VJQRcY9wBglmUINZb2pw74lj9hg8O7VLzYzGmWVI2+fUlMfpXUyWNYiAkgjR/4ofbCFrLp
	ko418BfXr25cxgepbQ4o9bVGcais719WVnjfO6/nH0+9h3D/s09CycwadGpoCedwwLxyJs1emX2
	clQo60F4iD08IL+GoW67ZH/LlBzwKHY6jIccwQsAz/JGPHRiY6w2PPHnEn34ZZxu5VOJ/n2BM8q
	2louK/xL2ko6/7sRdfPDqW3MYx5YjbDAbmB8F
X-Google-Smtp-Source: AGHT+IHd2k4msB0DofIG5f0ThGTdHRlto2SIRi4HnVJBGDXAmo/CxDaAxwdGIQ54zgGQu5ZX1gYIZg==
X-Received: by 2002:a17:907:7f9e:b0:ad2:411b:589e with SMTP id a640c23a62f3a-ad2411b5dbbmr871077466b.43.1747063121952;
        Mon, 12 May 2025 08:18:41 -0700 (PDT)
Message-ID: <3abf6813-d251-4672-838b-af01a05c84d4@suse.com>
Date: Mon, 12 May 2025 17:18:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/Kconfig: Improve help test for speculative options
To: Andrew Cooper 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Xen-devel 
References: <20250508160336.2232152-1-andrew.cooper3@citrix.com>
 <18f73078-c512-416b-9406-c76f8db178eb@suse.com>
 <63652356-4b82-401f-a6ba-8eb53b2f8317@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: <63652356-4b82-401f-a6ba-8eb53b2f8317@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12.05.2025 16:58, Andrew Cooper wrote:
> On 12/05/2025 11:58 am, Jan Beulich wrote:
>> On 08.05.2025 18:03, Andrew Cooper wrote:
>>> The text for CONFIG_INDIRECT_THUNK isn't really correct, and was already stale
>>> by the time speculative vulnerabilities hit the headlines in 2018.  It is
>>> specifically an out-of-line-ing mechansim, and repoline is one of several
>>> safety sequences used.
>>>
>>> Some of this boilerplate has been copied into all other options, and isn't
>>> interesting for the target audience given that they're all in a "Speculative
>>> Hardning" menu.
>>>
>>> Reword it to be more concise.
>>>
>>> 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 
>>>
>>> CONFIG_SPECULATIVE_HARDEN_BRANCH really ought to be named
>>> CONFIG_SPECULATIVE_HARDEN_CONDITIONAL, but this would be a (minor) functional
>>> change.
>> Hmm, so you're suggesting all the straight-line speculation changes then ought
>> to be conditional upon a separate, new Kconfig control? So far I've keyed them
>> all to this one.
> 
> Straight line speculation is complicated in multiple ways, and our
> understanding has evolved over time.
> 
> I'd forgotten that we grouped it with HARDEN_BRANCH, and it is not an
> ideal grouping.  What we have in the way of SLS protections are token at
> best.
> 
> First, in light of Branch Type Confusion on Fam17h processors, where any
> instruction can manifest as a speculative branch, there's nothing that
> can be done.  (This was demonstrated rather more thoroughly with SRSO
> than BTC.)
> 
> There is straight line decode (at least) through any branch the
> predictor doesn't know about.  Only "taken branches" get tracked, but
> also you get a higher rate of SLS immediately after leaving userspace
> for a long time (such that the branch predictor fully lost supervisor
> state).  Again, this is inherent and we cannot control it.
> 
> Intel say that a branch type mismatch (for a direct branch) will halt at
> decode.  Indirect branches are documented to potentially suffer SLS. 
> AMD Fam19h say that any branch type mismatch will halt at decode.  Also,
> with AMD IBRS, indirect branches stall dispatch until they execute.
> 
> 
> Therefore, it's indirect branches which are of most concern.
> 
> Putting an INT3 after any unconditional JMP *ind is easy.  Compilers
> even support doing this.  CALL *ind on the other hand has architectural
> execution beyond it, so if protection is needed, LFENCE is the only option.

Is it valid to summarize your reply as "throw away any SLS patches you have"?

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 15:24:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:24:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981732.1368137 (Exim 4.92)
	(envelope-from )
	id 1uEV0h-0001tY-5g; Mon, 12 May 2025 15:24:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981732.1368137; Mon, 12 May 2025 15:24: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 1uEV0h-0001tR-2w; Mon, 12 May 2025 15:24:07 +0000
Received: by outflank-mailman (input) for mailman id 981732;
 Mon, 12 May 2025 15:24:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEV0f-0001tL-Ul
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:24:05 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 23099059-2f45-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 17:24:03 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ad21c5d9db2so555994366b.3
 for ; Mon, 12 May 2025 08:24: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
 4fb4d7f45d1cf-5fe7fb0ac1asm1852705a12.7.2025.05.12.08.24.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08:24: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" 
X-Inumbo-ID: 23099059-2f45-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747063443; x=1747668243; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3QTd3xrVP/KI7ZiDMztUI9sKFVgx/mAQLfFiF91k6SA=;
        b=KfhwRmZOfVb3KQzOZNVkfsvdecac8PO+7B704HA/jBss17R+g3QYhWnmOggpvZ1orl
         f0zG0xr9CFgC0U3OUnYkdhFdGU4+3RM0CcktC/50TPG/nsdZ0k1h1c/IHv3geOQy1R3i
         LGe2g4rx64/0dhKHcie9KSJF7boIs+g7TGmMluitXq5cALFrPfZXYjXahDwL+MErGvSN
         xGeGXuqBrqjMlyJ/m/fWmxdinG3K2AQbi2ZPdMeedlrr2ZxaW2iDi+dxm+wOKIbnLioS
         hToNCm6ZxNbztkHSS0gYEtfaI6j9Hwn/UqW6Ad9Eg8VXCQxMS2i2HKr3ELYPRPNAL7IW
         mJ/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747063443; x=1747668243;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3QTd3xrVP/KI7ZiDMztUI9sKFVgx/mAQLfFiF91k6SA=;
        b=u1imaZo3P8J1HKq6wpQFz+gHY3mDCFd8TG14YQS5tDpqWbxIEcAbLfekfMeCUZrOSB
         KweckdINRqO6ir7LPgGXjfCJdYM9GoijyZ6iSR8x8ro1e7LpHYTR1LltQ8LaSuvTTDfc
         aBPejOqrzKqVg8lC0RU9Xof32dOwbiBE4VL7e/+8S+1+7s+PoD6a0/DC0rm27YNLebj4
         Qao9d2Lnc02a79JLtIVvu6NfhQdBREdJY7vk56yi4toYSzGSsRhfeGQ0hSPi4DlKCkHh
         WeFaEJHSeCWaNw5mbHhGmLerdYESv9tpbXUhEGPyjiJxSYK1MQOdT6VNIAYB0brieW7W
         p+Yw==
X-Forwarded-Encrypted: i=1; AJvYcCWilhZdkYv9Sf+HQQoyrzboohFM7a3chSYOXUsDPEJVPOSpnwVzEPQyZUb/kxlKaAONMSSwDQhsiVk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwMSFPdo8DTArjgVBVOEihP3EpNJI+kdzS1q6jPApj+dWG5NU0g
	glF817yachymOpyinoU6kpiuCUpMlxixNxjBeXFyfxpengk2VtKrSmXRqpRZZQ==
X-Gm-Gg: ASbGnctWBl+paOhXlsOKtynwn6hyNymOJxztgb8PIMsrD34dkbJ/MbmbTK/VSlars+4
	gNb3yj/BIbTxFA8zpeAl2mXvohI3FfRDt91VlV2CYZcQvi+rYxMB83xhQRZ+VQrLEcMTtZLG0PF
	pYWFhHSMIaCGd6jWySaBfUJdKRG/sdQtLgYW7/2V2NCLpL4nCnsDgLv6mY+DxjWi7bNRAFmU0ro
	1PPNaf3sSqYrtDpSXRQ+R2SGtTb2tf9E+PVXRn+hjw5c56Sf5TjNE3Hzyv0U3xe3C/iJAFe5F4V
	vNkWGUxImOVcmIh77Kma5jintP4/WT42+0yogEvv6v/5WsNScHrveVu4ECEt0gcaETLxJHg7UYK
	fo9xbnPu1Nw4YFdHyqa4YP9lucx/mnOmvTnRC
X-Google-Smtp-Source: AGHT+IFgXJglUc30cMkXqqpT1tGlPTXMgOLjq79RpYURz07MLDp+7EaNgn39pCdmXToT+a7HM1K/xg==
X-Received: by 2002:a17:907:9723:b0:ad2:40ee:5e26 with SMTP id a640c23a62f3a-ad240ee6004mr714275666b.4.1747063443150;
        Mon, 12 May 2025 08:24:03 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 17:24:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 8/9] xen: introduce flag when a domain requires cache
 control
To: Roger Pau Monne 
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , Juergen Gross
 , Christian Lindig ,
 David Scott , Bertrand Marquis ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-9-roger.pau@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: <20250506083148.34963-9-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 10:31, Roger Pau Monne wrote:
> Such flag is added to the domain create hypercall, and a matching option is
> added to xl and libxl to set the flag: `cache_control`.  When the flag is
> set, the domain is allowed the usage of cache control operations.  If the
> flag is not explicitly set, libxl will set it if the domain has any `iomem`
> or `ioports` ranges assigned.
> 
> Modify cache_flush_permitted() helper so that it's return value is no
> longer based on the IO resources assigned to the domain, but rather whether
> the domain has been explicitly allowed control over the cache, or if it has
> IOMMU support and there's a single IOMMU in the system that doesn't allow
> forcing snooping behind the guest back.  As a result of this, the return of
> cache_flush_permitted() is constant for the lifetime of a domain, based on
> the domain creation flags and the capabilities of the IOMMU if enabled
> for the domain.

This then further emphasizes the remark made for patch 7.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 15:34:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:34:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981741.1368147 (Exim 4.92)
	(envelope-from )
	id 1uEVAK-0003t8-2E; Mon, 12 May 2025 15:34:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981741.1368147; Mon, 12 May 2025 15:34: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 1uEVAJ-0003t1-Uq; Mon, 12 May 2025 15:34:03 +0000
Received: by outflank-mailman (input) for mailman id 981741;
 Mon, 12 May 2025 15:34:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEVAI-0003sv-Oo
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:34:02 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8668c418-2f46-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 17:34:00 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5f7ec0e4978so862312a12.1
 for ; Mon, 12 May 2025 08:34: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
 4fb4d7f45d1cf-5fc9d700e56sm5842028a12.57.2025.05.12.08.33.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08:33: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" 
X-Inumbo-ID: 8668c418-2f46-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747064039; x=1747668839; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QPIXPAv4PPVLmmkjR87Ub2AuyzhTKKJSpkg0dNS1NR0=;
        b=DDNivKTg9FRivwKYO+Vhcf1HofOHoM4CgOPHd5SNbqEiKLjfyfbH8FFTi9Dv/XybcK
         0pycNPY0U+TV6yge1Qw2rW8u9RAag8QSAgJIV/2pwULLZwixquIccJb1QJlkvOENh5tl
         I5y9D0091QGemZwE9ClA7a3vwGDxaRtQg9maZj00Sc0oXMBTXrwRB57xZQfhsQqyXFTm
         3QuOMBzwe2g6MITofOvE97esNG/u1BQtFoxd2vebt3HLknR/a9PNXVK5/Idu6kIp0jUA
         vlQWHoWuHAE0LJEA3fAFdwed+dKvM4hlecm95kuNIji76sKvOE+S1GvHIiPzqwCnD9dA
         UMiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747064039; x=1747668839;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QPIXPAv4PPVLmmkjR87Ub2AuyzhTKKJSpkg0dNS1NR0=;
        b=qJ6RJvVdOCq+FP5p8eWSI3U8mO3KT+9E42D1zNNd46t7ltyFrAHCflMip7zKguvZSi
         hRtf/EjqZUsDibMiZCnVJLkCue8xUmQLWNCqEW5Nn7/KQF1hAhKTgFJ9ncFqkHN6b6MQ
         RSktdrporHjeaSuiJjRJ9DtdOk81Hq68NG6k+YemZTUws9eIs4uiUeFD8VEcWClSBgXI
         LW4txJHExpKS2DkFVywB6cMwy0LDe3+jBVhxHBHH4G0gWFDYAjWuemof9lBmLlI8HcZV
         oxLldY4ph01Ug3Afi4XX+7FewcF+QzNO6VbnqHfz9UjfRCeHcD7gywI2olqdhQmCuD/A
         gbug==
X-Forwarded-Encrypted: i=1; AJvYcCW74ynLpuZZG+tVamcGPEV6/ZmuViPiro6yBsSGHlwAv6nEnUq7/QnSDTQewpypCifOkOkdMrAmIDo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxoTC/fmS9DMxsGLS8lBXuBirIvu5Jc8VtCsz1OjZ+YxkYncPur
	OrJcbTZjliAHCxS8Gf5rgdmK8Exc5jFRNE8yeIuxjhqkSI3MxE3uWNNitrTsxw==
X-Gm-Gg: ASbGncsoDr8SJou5l2lhnzKEfBw1qTZWOGh5StV8PQN9VKkHfYYoNy0AKZr2Jaz/RvN
	mtX7yExOkneX8R+MBpJ3Hrp1rWBig0LPx8gS/szMdi1jV6YQoPdA2scemNJ5z2YZyIKyDZbtJtJ
	rFpQUOH+19bpTtvhlWBh+glIWJyR6XsaWnh3Yhl6liBLETSNkd/IkZxGwkkkebiagBaae2loxxs
	F4MbpuxePi1u+veExogXX8MMVw7iPDC8gRZL2s+qJdJiGrY+j83S+4Rc/sHmiJdV/0Eg2tRksIF
	iEuZXEJr0LmaOdWbH2prlctdxU1k4xE6h2UqIkWwGw+CiGsSkW5RyfsgiiqQTCvmF+FbPcu3lu5
	MY1YLgLGlJLbi17/fL5jiy44Hc/4BDXG6LlTV
X-Google-Smtp-Source: AGHT+IGxopyOP86skr4mx/8q8/3wLGXVVktB59X6nLu8qcKQmi42DK3JomojZ7id53QgedcXwlHdzg==
X-Received: by 2002:a05:6402:280a:b0:5fc:a510:502e with SMTP id 4fb4d7f45d1cf-5fca510505cmr9314145a12.29.1747064039411;
        Mon, 12 May 2025 08:33:59 -0700 (PDT)
Message-ID: <50d87c60-55fa-49c8-be85-7c70ee6dcb42@suse.com>
Date: Mon, 12 May 2025 17:33:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 9/9] xen/x86: track dirty pCPU caches for a given vCPU
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-10-roger.pau@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: <20250506083148.34963-10-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 10:31, Roger Pau Monne wrote:
> @@ -2606,6 +2619,36 @@ unsigned int domain_max_paddr_bits(const struct domain *d)
>      return bits;
>  }
>  
> +void vcpu_flush_cache(struct vcpu *curr)
> +{
> +    ASSERT(curr == current);
> +    ASSERT(cache_flush_permitted(curr->domain));
> +
> +    flush_mask(curr->arch.dirty_cache, FLUSH_CACHE);
> +    cpumask_clear(curr->arch.dirty_cache);

While here re-ordering of the two operations would be merely for (kind of)
doc purposes, ...

> +    __cpumask_set_cpu(smp_processor_id(), curr->arch.dirty_cache);
> +}
> +
> +void domain_flush_cache(const struct domain *d)
> +{
> +    const struct vcpu *v;
> +    cpumask_t *mask = this_cpu(scratch_cpumask);
> +
> +    ASSERT(cache_flush_permitted(d));
> +
> +    cpumask_clear(mask);
> +    for_each_vcpu( d, v )
> +        cpumask_or(mask, mask, v->arch.dirty_cache);
> +
> +    flush_mask(mask, FLUSH_CACHE);
> +    /*
> +     * Clearing the mask of vCPUs in the domain would be racy unless all vCPUs
> +     * are paused, so just leave them as-is, at the cost of possibly doing
> +     * redundant flushes in later calls.  It's still better than doing a
> +     * host-wide cache flush.
> +     */

... wouldn't clearing before flushing avoid the raciness here?

> +}

Also imo both functions are a better fit in mm.c.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 15:38:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:38:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981749.1368157 (Exim 4.92)
	(envelope-from )
	id 1uEVEJ-0004X6-Gs; Mon, 12 May 2025 15:38:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981749.1368157; Mon, 12 May 2025 15:38: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 1uEVEJ-0004Wz-Dy; Mon, 12 May 2025 15:38:11 +0000
Received: by outflank-mailman (input) for mailman id 981749;
 Mon, 12 May 2025 15:38:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEVEI-0004Wt-LD
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:38:10 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1aaf2a4d-2f47-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 17:38:08 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5fd0d383b32so3167973a12.3
 for ; Mon, 12 May 2025 08:38: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
 4fb4d7f45d1cf-5fe943484e6sm1315048a12.24.2025.05.12.08.38.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08: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" 
X-Inumbo-ID: 1aaf2a4d-2f47-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747064288; x=1747669088; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=MG1uROywJGEjyfQbCjXiFOg6F5BMz/3WanvKrrzvY2g=;
        b=Pg0GHIt5Wnvee3/al2oPwamUKljr4LUURYl+jowz/Sub7WqJoclwvTqufBwsC3hlPX
         bTL3BO7vgMbK7zYGi3zy9obKA4N6J7muLR5DOV1+6+rDQmWpEYPHklQs2tAJavX/eFoL
         AZGHmne0IQ2cx6gM2m9zRi6VRK8d2WVC22zckUybAvHnm2zjHLjKLWB20Y989YNpYIEM
         t1ayxNlfKO+ENALt/Zj12G4buFu55+qSDOANDdSLOu8nWPVN3Y15zUutYlZIeKmoIKbW
         JxpY4yEMDIW0B1c67fXj7+xNY/6NCJHaX9fzyaHaevC4cXJHemhhweUy45vyZzbzMPTI
         kKnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747064288; x=1747669088;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=MG1uROywJGEjyfQbCjXiFOg6F5BMz/3WanvKrrzvY2g=;
        b=XqMqX6or2xbG2a57dv2qKqFJ6fr2sRMVWTkWZ8kochvrh+o788JLrfERLfEeTxm3J9
         ujEnTCmUgoQqISzLsAUvbSOD1zdDMFvXln55uQnMq1SSzNwabnteyEayf12MhI+C0FoK
         1ul9mEGAJCvQ4zlPQtJpXKN5NL9m5UYyeu25Mf6OQg3HSb8AgmMvtS4x72zG5AjkrIuD
         GtnzAexwvuRUFItf2+nluyN/uli3Z0zGIqC4P00hQJ+99t/0+j8Jumzn4l9JQgfoB/SB
         cF4KM9JmSz/LNTGMeG+gNChvrFxHcY++Cz0Fv2sFe9921VasaKRai1bP8YeC3M+FAvsB
         /oWw==
X-Gm-Message-State: AOJu0YzGQzxQLB4o9jgV1lJQRPmH1LrduXNEhw3MWGlp7Klmh0L9xOlB
	flWiAabBMo7BAVYgQDODnpsWirnz25u8whi6/MQJeTC/3/Wf6g9RI7kQhFSGGQ==
X-Gm-Gg: ASbGnct06MONNYgyC5SklWLs0Utq4LIGYLF5XKR8OGitHWLQ7b5a3YbaMcqQAbqtmhh
	N1jkXXIKnwM3yU7lig3CdTPCn1OnFGvMFYQSMW8m8uSW4YBGFm2fJnUfc7bVJHBJLVjCgCwb79E
	44Zf+qfIRde19IL2w5epjUQatZ2+q5fOE/9aAc5M5XPy/zhvcC4Dy2ATqHHIuilfvLQTOWMb6de
	jDGccsWb6Nk7X0gat6rRzuk1h/kAgiTV/UPBr5JG7NS4sBAiUCgMp/eckOnx+/vvHMtY/pXu0Yb
	q8WYmVQSMVBDKDq0iC94umZ2oKafpNSLcKFs30ZcwNSEzWR1adsJ4d6MbF+M56GDydeI7OHmVkA
	jiF6KXjSfnC61R3KO4J0eQ/NgRePQmJQ+x7KY
X-Google-Smtp-Source: AGHT+IEHSeMTKrvK9dL59lb3BXVTQPPUkdhwQ4O3JadntKeohaOG0mf6TcDvQNBhaPO/ODJ+n7B9cQ==
X-Received: by 2002:a05:6402:2686:b0:5f6:218d:34f3 with SMTP id 4fb4d7f45d1cf-5fca11dd3b6mr13630921a12.28.1747064288165;
        Mon, 12 May 2025 08:38:08 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 17:38:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 9/9] xen/x86: track dirty pCPU caches for a given vCPU
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-10-roger.pau@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

On 06.05.2025 14:55, Roger Pau Monné wrote:
> On Tue, May 06, 2025 at 12:16:00PM +0100, Andrew Cooper wrote:
>> On 06/05/2025 9:31 am, Roger Pau Monne wrote:
>>> When a guest is allowed access to cache control operations such tracking
>>> prevents having to issue a system-wide cache flush, and rather just flush
>>> the pCPUs where the vCPU has been scheduled since the last flush.
>>>
>>> Note that domain-wide flushes accumulate the dirty caches from all the
>>> vCPUs, but clearing the vCPU masks will require pausing all vCPUs, which
>>> seems overkill.  Instead leave the vCPU dirty masks as-is, worse case it
>>> will result in redundant flushes in further calls.
>>>
>>> Signed-off-by: Roger Pau Monné 
>>
>> I'm afraid this doesn't work.
>>
>> Unlike TLBs, dirty cacheline can move sideways, e.g. by foreign or grant
>> mapping, but also naturally because of how cache coherency works.
> 
> Does such sideway moving also imply that local WB{NO,}INVD on native
> could be equally bogus?
> 
> According to the SDM, cache lines can indeed move between processor
> caches, but the memory controller must always snoop such moves and
> flush the data to memory:
> 
> "Here, the processor with the valid data may pass the data to the
> other processors without actually writing it to system memory;
> however, it is the responsibility of the memory controller to snoop
> this operation and update memory."
> 
> So a cache line moving sideways will always be propagated to memory as
> part of the move, and hence the data in the previous pCPU cache will
> always hit memory.

But that's only one of the two aspects of a flush. The other is to ensure
respective data isn't in any (covered) cache anymore. IOW dirty-ness (as
the title has it) isn't a criteria, unless of course you mean "dirty" in
a sense different from what it means in the cache coherency model.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 15:41:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:41:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981763.1368167 (Exim 4.92)
	(envelope-from )
	id 1uEVHR-0006T8-2Q; Mon, 12 May 2025 15:41:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981763.1368167; Mon, 12 May 2025 15:41: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 1uEVHQ-0006T1-W1; Mon, 12 May 2025 15:41:24 +0000
Received: by outflank-mailman (input) for mailman id 981763;
 Mon, 12 May 2025 15:41:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEVHP-0006Rg-6B
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:41:23 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8df788b3-2f47-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 17:41:22 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5fbf52aad74so9541022a12.1
 for ; Mon, 12 May 2025 08:41: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
 4fb4d7f45d1cf-5fe17c6c918sm2190808a12.23.2025.05.12.08.41.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08:41: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" 
X-Inumbo-ID: 8df788b3-2f47-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747064481; x=1747669281; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=20xrL+8f4Mo1wmEMliefXpltpUJiQP3DhTavYpR2koU=;
        b=ZLVTMlOEg/JzbG68X7dUoQZ2vkt7N0sK1mc6TNM8hy6rbLZmA3Cx3aSpHW3uv9Zo3a
         fcSCVNz9MrbHnaQ0z3YyP6xlpc39eVUsN1Gv/t7KCLMIhFVAb5cPw8KQTddi7olIbvaS
         CcqvmXCr/tkoRkcJ/IMmyoIm4DLOGP8PS5RUJrHEzuSd+T/9+Q/KTu6aikkmBXqNsxCS
         xCgC0t3cMMDgCKRRIupVSMnvH+6sR9HlR3fVCEnrNMUSG/rtcmZeNtTLznv3ytH0z0iB
         mMORQMt41eu0zZFE13mp75SEFbJjFhRLfuDqCZdBMlPqU48vJS9jujvc/BpdwlTP2C3o
         KB5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747064481; x=1747669281;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=20xrL+8f4Mo1wmEMliefXpltpUJiQP3DhTavYpR2koU=;
        b=TTWM+awhCDyN721kjuPI+GhCLDYHfMAMFFiW/MxrwAPQf4NzxFi6tOVKJ6A6Qa/oCn
         c4ne1qS9FNefxDbfY0izmGWVh20uOWCeUbwRaKI+stSHlDVHBjLwT1MKfUMSszwj+cmu
         PbUVKR8GrieANur9blTC6F6ypH+Avx2ghR7e6zC32WjWd/G7/m7OT5elmNHPFfVI2Awi
         +a6H36V71e+7Aonri2HisN9ywR5zQYiYxMTi7YDMY8sfNXD4MAQFNb4NNjKnDVUD/Rtv
         Zgnbpje+Bh834EKk9eJ6E+phYaTk3e+15M2muAVvyRYxrVxZPnrIhvc+cVlLCn+7bmZM
         ptmg==
X-Forwarded-Encrypted: i=1; AJvYcCW1r+lCdqop6iQ8ecx09DMs53GQpEIh0jm/d2FCCH3zLUKQcGfcjsqIARMDBhperMxILiOSnknCAxk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyowywI5mJS3X/PCoIegcv4Nku0Kkg86faYXFm/zTfAo8Hk0rsK
	4VVTaJTaE9rP5S8z/3gAztNH3af71OxeRp80QJsBMK7rVP93SZyNAspY7BUZZQ==
X-Gm-Gg: ASbGncvUjtB9R7B4TIlMpZ1j5c3vV9dh3vXS5nqKGaHUTfvHVj5JWPDeb2rod68qb3s
	FdW5KiPrPkk4LAXjHSsD8d5fwehyt1Yi3ZaRfi2hivOvNZ0MnLbo0iaFv4y5pGMi8lBzHjNEfPt
	8ccb0QT39T2CkhwMcX1tt7pPb3PhOxHh78i03Qm7VbAUm5Bk1rfC/S9dvgsb8nzzcu+ZoEgeZgc
	q9pjEJPRoTspkNjD9KPokh/2jA8nBVeqCb6POnqb32M5zmuQSzvlPCM7ZSdfG9IrthTbDqwa81P
	yxiB0fwYCa7Q9HN+0o7JYGaf2psJhEKMBw+8hlQZmpOHcvpRtBpiLenuat3O62s2xZb67+0cFwP
	uoZTJDJI3DzaO0lh75zlw7B5s/kKMvWgBD9pv
X-Google-Smtp-Source: AGHT+IFZ2sqk6xq36aEbJGk2UL4LcptumihTR160i108p3SH5xk+Wa1IkpsxBjz2ADR0uk/VpR40aA==
X-Received: by 2002:a17:907:74c:b0:acf:b9b6:9608 with SMTP id a640c23a62f3a-ad1fca0fd60mr1587459766b.9.1747064481499;
        Mon, 12 May 2025 08:41:21 -0700 (PDT)
Message-ID: <03caed8e-91fc-4bfd-8623-d5a2efdaadbf@suse.com>
Date: Mon, 12 May 2025 17:41:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/15] xen/cpufreq: move "init" flag into common
 structure
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-2-Penny.Zheng@amd.com>
 <26067708-2854-4493-8801-d0fb709242d0@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 07:33, Penny, Zheng wrote:
> [Public]
> 
> Hi,
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, April 17, 2025 11:12 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v4 01/15] xen/cpufreq: move "init" flag into common structure
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> AMD cpufreq cores will be intialized in two modes, legacy P-state
>>> mode, and CPPC mode. So "init" flag shall be extracted from specific
>>> "struct xen_processor_perf", and placed in the common "struct
>>> processor_pminfo".
>>
>> The code change is certainly acceptable, as being largely mechanical.
>> However, the above doesn't explain _why_ we need that change. There's
>> probably a little more connection that needs making between that's there and what
>> you mean to add.
>>
> 
> How about complement the following description:
> ```
> Otherwise, later when introducing new sub-hypercall
> to propagate CPPC data in commit "xen/x86: introduce new sub-hypercall to
> propagate CPPC data", we need to pass irrelevant px-specific
> "struct xen_processor_perf" in set_cppc_pminfo() to just set init flag.
> ```

If spelled out in more abstract terms, in particular without a forward
reference to a future commit, whose title may still change, this may
then be okay if added.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 15:43:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:43:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981769.1368176 (Exim 4.92)
	(envelope-from )
	id 1uEVJ1-0006zI-CH; Mon, 12 May 2025 15:43:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981769.1368176; Mon, 12 May 2025 15:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEVJ1-0006zB-9i; Mon, 12 May 2025 15:43:03 +0000
Received: by outflank-mailman (input) for mailman id 981769;
 Mon, 12 May 2025 15:43:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEVJ0-0006z3-5N
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:43:02 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c69cb410-2f47-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 17:42:57 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-acb5ec407b1so802520866b.1
 for ; Mon, 12 May 2025 08:42: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
 a640c23a62f3a-ad23fc5328bsm378115166b.40.2025.05.12.08.42.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08:42: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" 
X-Inumbo-ID: c69cb410-2f47-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747064576; x=1747669376; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=woq5axa4XDROliFlm/IrjqsVSOX8rkTvq0NLFICJj2I=;
        b=cmINE4e6mrZT/Efcc1+OUzpD0vDYRVyYdl6cdwyM+xFKt4oHmVx13D/RCuHGCAJ/WK
         /dOdquYtPsoHN052eUcQ9YyvKWKnULyRDdwo/jptBkznzYTjrHemlC/pf/8PBA/tthTD
         rsWhmLaJvJiq1DLheuStl50Icbv5+SmxiEHgODBcKCCG3DVFXmlvCaC3PdtqXZrQsxES
         EUlq3YbQqn+bKBmqolj+mGcsNjjH/HrOPLxnOMp+nzByxcowyWwss3nSQ9/UErL7ko8l
         foNnfa3UXnq+g4vh8PBFfJ4PeuDqFmvz8JXUuYhBbta1k+RtCUcDzrM5GU7WCtI/Tish
         5TDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747064576; x=1747669376;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=woq5axa4XDROliFlm/IrjqsVSOX8rkTvq0NLFICJj2I=;
        b=Dn6fIs6OAF4xZwuD18ZmpXBzWO/N6MP0WY3zf6n+p7B3rsvzbEdOJzhwzlwNgApEjx
         uBxemwKy+d2lmB4aYKT5IGU2RF1Q/eMDoB8e04IzWJSMEwdGs7XxNGkCiHBtEXY5EV5Y
         Ijx4PgqdTuwrwaPEJxEPMPFT1woAoMDxx+gK3S1AbjnS7LLs4fqXzg6m6nzbFVL105jg
         SzaQ8giMsP7OKK55fDzGZdxG7QvhMl93xbIM7S8iU9Sj4GCmoIg307Ov8r3H9/vuUCOd
         sBXGCvoxmZq2igr4KxZPqYdbZbvLjNs/fQorViDbVTnGk468tzOui8iLQNUeba1EMhtg
         2+qw==
X-Forwarded-Encrypted: i=1; AJvYcCVUL5MNBTyHZIqq/Zc1ySw+fWjcV0/hlJV+QZO1Vrj5dTqjCSSRSg6aAri1wcX8yI8DWAnHaiy5Fi4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzQ8sR1zEDzKjcN6dVwvSHVaJpNqOfPGsvgbbPa2PRPFYOAvCl0
	zoM0t7LI54TDPByAXBXumpfJ5C1JIKXOuLBv+Alxyns0kouG75IoLfYDPEH+hw==
X-Gm-Gg: ASbGncuMXAisAFlcj5pXkxbG1l5FFmDx/IA8NuX+hcspJM0CXip7lgwgH4S6lGn/hgX
	oo2T6wajO9X00nJcnLt8C7Oqi3mLfYOAN8tuS/BOF1tB2d4MxZLllO3dsj54kkRlQgO6sgGRHjU
	wWPCy9xFF4IvwtNxkFXKpH6KsUyxdNbAqY0/7J77n6pnZ0ZonlFOe4c/tSJVJNBnA2mXax+3qDY
	HSdyQPJV3O8q+4+fqEhbBb90YBg7MYXFnV+C9irXMd2VeueH06tbLVszAvMlwXdQrEUgiZeaWa4
	csdNRjcRx72o7optTeL9OXekx7vms8xR1Zzft8YUFDIGmbt7VVaTiD98C8GSVnqTyYS7lt5ylNA
	Uv+XHSZUL1qUeZTT/CKkqbm0YA+7eZeo0LS5I
X-Google-Smtp-Source: AGHT+IF2sCku4ymuGnWw98Ksj2JonP9Fyemm3PQkMSO3URizeTRG8FQ6NrKkXmWNMhRsvODM0qWVXQ==
X-Received: by 2002:a17:907:c009:b0:ad2:372d:6bf8 with SMTP id a640c23a62f3a-ad2372d7b62mr952670366b.15.1747064576645;
        Mon, 12 May 2025 08:42:56 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 17:42:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-3-Penny.Zheng@amd.com>
 <829e710d-d257-455a-b4fc-1746119609ef@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

On 06.05.2025 07:56, Penny, Zheng wrote:
> [Public]
> 
> Hi,
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Monday, April 28, 2025 11:32 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Anthony PERARD ;
>> Orzel, Michal ; Julien Grall ; Roger
>> Pau Monné ; Stefano Stabellini ;
>> xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct
>> xen_processor_performance"
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> --- a/xen/include/public/platform.h
>>> +++ b/xen/include/public/platform.h
>>> @@ -440,6 +440,11 @@ struct xen_psd_package {
>>>      uint64_t num_processors;
>>>  };
>>>
>>> +/* Coordination type value */
>>> +#define XEN_CPUPERF_SHARED_TYPE_HW   1 /* HW does needed
>> coordination */
>>> +#define XEN_CPUPERF_SHARED_TYPE_ALL  2 /* All dependent CPUs
>> should
>>> +set freq */ #define XEN_CPUPERF_SHARED_TYPE_ANY  3 /* Freq can be
>> set
>>> +from any dependent CPU */
>>> +
>>>  struct xen_processor_performance {
>>>      uint32_t flags;     /* flag for Px sub info type */
>>>      uint32_t platform_limit;  /* Platform limitation on freq usage */
>>> @@ -449,10 +454,7 @@ struct xen_processor_performance {
>>>      XEN_GUEST_HANDLE(xen_processor_px_t) states;
>>>      struct xen_psd_package domain_info;
>>>      /* Coordination type of this processor */
>>> -#define XEN_CPUPERF_SHARED_TYPE_HW   1 /* HW does needed
>> coordination */
>>> -#define XEN_CPUPERF_SHARED_TYPE_ALL  2 /* All dependent CPUs
>> should
>>> set freq */ -#define XEN_CPUPERF_SHARED_TYPE_ANY  3 /* Freq can be set
>> from any dependent CPU */
>>> -    uint32_t shared_type;
>>> +    uint32_t shared_type; /* XEN_CPUPERF_SHARED_TYPE_xxx */
>>>  };
>>>  typedef struct xen_processor_performance xen_processor_performance_t;
>>> DEFINE_XEN_GUEST_HANDLE(xen_processor_performance_t);
>>
>> What's this movement about? In the public interface nothing changes?
> 
> As we will have shared type in "struct xen_processor_cppc" too, maybe the definition would like to live
> at more common place, then it could be shared?
> Living inside "struct xen_processor_performance" looks like internal values for internal field.
> If it breaks the public interface some way, I'll change it back and duplicate the definition in "struct xen_processor_cppc" too

I don't think it would break anything, but I also don't see any need for the
movement. And generally we prefer to avoid unnecessary code churn.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 15:45:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:45:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981779.1368186 (Exim 4.92)
	(envelope-from )
	id 1uEVLN-0007Wp-NK; Mon, 12 May 2025 15:45:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981779.1368186; Mon, 12 May 2025 15:45: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 1uEVLN-0007Wi-Ke; Mon, 12 May 2025 15:45:29 +0000
Received: by outflank-mailman (input) for mailman id 981779;
 Mon, 12 May 2025 15:45:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEVLM-0007Wc-74
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:45:28 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 201cb33d-2f48-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 17:45:27 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5fc8c68dc9fso2264054a12.1
 for ; Mon, 12 May 2025 08:45: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
 4fb4d7f45d1cf-5fdd088798dsm2253874a12.13.2025.05.12.08.45.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08:45: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" 
X-Inumbo-ID: 201cb33d-2f48-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747064727; x=1747669527; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uLZ5lLRzqSOVbBVCu0uKzeU1eltQpxxmcZdkkSjHSuM=;
        b=RKg/OdwCn/LT4y8AemptvfXWrCgLhgATymmIDZXb0cFHn2tlTqbk6jUmLCVxoK8xci
         4eMIaceLXkgWz1giD+h+/CyaeDmOXmfBKsp8XIZFUYVV46XX6Ss7T0wABJ8n1DPajJya
         qxdMoJT0BRg5NP7i9xU4tKAIZ2fCnEsbqQ7NaAbwSSIkTDel/i5SSg3mFOrPIKatxtBu
         TaEM0/CE63umlQztsr+U8yF18/NwLHGVRi/PMUnnF1MhpW7HkSjevemJigT4M4an8tMr
         41KTwBVdVFDTsY0coDtfNq0KrUKlD9E9OZZ9VcNAdg/2hYcgXlbEx5APBzY27Jc5F+Vl
         DmGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747064727; x=1747669527;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uLZ5lLRzqSOVbBVCu0uKzeU1eltQpxxmcZdkkSjHSuM=;
        b=ExDb0YzdpzknOOW2sKhaQ+bUCyfgU45jSDYpHf2RW3tsHABsfXUUJIiMFMFH2zFPlQ
         n+sH0S3hGfWPTexPESu2Fe/UeALbxQsBYaS5yrfTfwzobWTErjckHf0NS3d9pWTC63iQ
         eet4nxWgJVH1MLjDPhEzqoOrYgDiVtvTDSI16aZlJeZqppxm7uLkoCreXTwN9Pj6emgn
         3Uowri/i6yugN5k/IoVar6/qKIViUinb3/OzxmipdqwGY2GHpE0cw0gIGjUehNQmym9F
         WFo15Bfj0XtigG4SE1IOWJorfd7NE3cCB4MYjnZEjssUSoo+jKdTkdvZEhi9kqF6w/q1
         UGwg==
X-Forwarded-Encrypted: i=1; AJvYcCVy2+iDLVSsgNuOb4VQyDJ4IQueNbsQgvF1wWjLww9Ux8IVE3/LoYDlD/71htVDw93v5Fh18UQlTYs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz/m18tICVhllzga54JcvzF5s5yHCrFNwiV+kHvn1zBsIVexdOM
	ugha67XKzocfBUfTq+4FlEYPRpXyrjBq794GmfOuZjqXYdLaxUjnk9D7Jv6ojA==
X-Gm-Gg: ASbGncseToMU6sj7MARmb5o7CL8kliqCuRwuPei+3uXk0rPQMXrpWEENQV16DYE++Wl
	PP9vKq230swjRWHuv4AqqQO2UvsIA2GHD+oz427FHw+V3rLzKAm/A/YEDrXdryLbLpOg7Ts2x9b
	g9skXNcrQwxZMUi/rQCkKZ0sZaxCWFmxPo1QjpgYzpdu88QrTOA5NTR4RRuAUY5pFcxgzHiHLjr
	+bb1px/GMcKLFboPH2pRYSEktGGYC8iCDd2vO7dmtuydOOsh6ySuuVCGKqvqOJUAaAsiYJ7Do82
	3G8RnqQxGmnkKRH+ZHWeRh9v1+86yeBb6edKs4Dm28qRUIwCWvi+4I291FIJ4axul6g/dk84Kbi
	/wlcyLJa49zIl3BfwAGNWQ8j/4eB8/Qfhs6zZ
X-Google-Smtp-Source: AGHT+IHMqsV4licPo7r9WTATzWX6lkhuiLc6xNTR2H8r9rWKaQUn3U7AwAENEjvSpjRwAzcWzE7+TQ==
X-Received: by 2002:a05:6402:378c:b0:5f8:357c:d58c with SMTP id 4fb4d7f45d1cf-5fca11e5e51mr10245749a12.34.1747064726313;
        Mon, 12 May 2025 08:45:26 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 17:45:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-3-Penny.Zheng@amd.com>
 <829e710d-d257-455a-b4fc-1746119609ef@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 09:22, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Monday, April 28, 2025 11:32 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> --- a/xen/drivers/cpufreq/cpufreq.c
>>> +++ b/xen/drivers/cpufreq/cpufreq.c
>>> +    {
>>> +    case XEN_PX_INIT:
>>> +        if ( shared_type )
>>> +            *shared_type = processor_pminfo[cpu]->perf.shared_type;
>>> +        if ( domain_info )
>>> +            *domain_info = processor_pminfo[cpu]->perf.domain_info;
>>
>> Does this need to be a structure copy? Can't you hand back just a pointer, with the
>> function parameter being const struct xen_psd_package **?
>>
> 
> I've considered handing backing a pointer, then maybe we need to allocate space for
> "struct xen_psd_package **domain_info = xvzalloc(struct xen_psd_package *);", and XVFREE(xxx)
> it in each exit, especially cpufreq_add_cpu() has a lot exits, which could be a few code churn.
> So I chose the struct copy to have the smallest change.

I fear I don't see why such allocations (of space holding a single pointer)
would be necessary. Afaict all you need is a local variable of the specific
(pointer) type, the address of which you pass into here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 15:52:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:52:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981789.1368196 (Exim 4.92)
	(envelope-from )
	id 1uEVSP-00019U-CE; Mon, 12 May 2025 15:52:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981789.1368196; Mon, 12 May 2025 15:52: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 1uEVSP-00019N-9l; Mon, 12 May 2025 15:52:45 +0000
Received: by outflank-mailman (input) for mailman id 981789;
 Mon, 12 May 2025 15:52:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEVSN-00019H-VJ
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:52:43 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2321e9ea-2f49-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 17:52:41 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad216a5a59cso501911466b.3
 for ; Mon, 12 May 2025 08:52: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
 a640c23a62f3a-ad2198b6ebcsm628618466b.185.2025.05.12.08.52.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08:52: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" 
X-Inumbo-ID: 2321e9ea-2f49-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747065161; x=1747669961; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=gaFIforIFMWYLs76C5IfEyp2isGvwpw3w906clwWksA=;
        b=fNONocSkXYi5y1eo2Er/J55ZZ5bGAStVGWSDm4utOewkrjERopikiLz6hRb6TB8eXR
         2LkFisCLn+pSUtcs+WlbtiBi50xMkBcO6+R4Rp/lVSUXUqqwQ0IS41XEdaTHeS26VMYv
         Xbi/tOtpZ3Fo9uXE5iZycOXSDyWQvVONhvbh6q8U4PmLljXNg5vaNl8LccEAjSgGAEaV
         krmdn2k9V1WjO1sMqBTpfcFVxR2Pa03qEAdTBynqhdpQmW32OA1+0BfSCpUSuEZFhi88
         bv5PVc2z2NnRULBvg2qZa7i09QHRlnpMzVrLH6hKGnAfun5lnbW4bC3yI/Ru9lfUt8vW
         nmNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747065161; x=1747669961;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=gaFIforIFMWYLs76C5IfEyp2isGvwpw3w906clwWksA=;
        b=VFGcTdN2oDf/iWBKYrFlkrxSeQ1qR6MMSu3w5wUMa/T277vBuld33davp4WSihYMV5
         FDCOJkiYfm7TdqD2p4nZnYCNNz2BS1wVce9MmCXhx7dpYfO9f6L6ivZKoDF9SGtYIeux
         /f3jgHZ6PenK/MDnXb9LQEPRLENmYWAbEo36p9MawO0Tk1Oc79wBgjtSEJW/FRccLo91
         gG++zaIJkpvhAVBevmHlu3CmILaIlyhoguSJEzs76aRFm11/wpP9h7jHQ71CPuzXGsiB
         ecow7QooW8QCnW28X5lT/KNySX2ttI5cxTe22ZfAiR2NeESqfue3iSZXRB6TjNCYe03C
         elJQ==
X-Forwarded-Encrypted: i=1; AJvYcCX/4lyFCNXq6G2I/qf4AgS+YYqK5XqPmSxIvz23NlVTSarKlA8LN9o2AX2SrqIxx/pwo9ao7Uz3yrw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YybZrs91e3FB4/O+7Hq12iOXJ8xtOhvjA++0aYm6M+b48v524EW
	EMW7XtoSegxHjLnR1QyqRVm8lY6X096FzdF0MYe6BLm+R3UHAl5C/4gWMJGtEQ==
X-Gm-Gg: ASbGncuufgthBctcQ0d053eutqomluGkF7a+IqrnxGl4oL4lYwqhsEsbFLFcp/QBo3X
	scsJKIczr3ptF/x7VsgVlmruxVlWiMdXx8vL3NUbsWryiIXpczwJ0Y9Jmn6PULgVfyVZCYI3jfM
	26Sj4Y1r+2gLj9yJjl39l+AOZRDlh8k+24tvMlBylWT7QXQVGZO+8/D4UqSwlU/nXWYjq/PGpqS
	JQEn1NXNxT9jh3AmMRFqMFOoZNLbdCujvy/G9ctIZt8J2oMaMF7OaAUytzGkp6z4piql9L4nHtL
	Cx8mjS+vphyhBoRd1dpvGAEHmTElmw4IryaGc/MGiF+kW+HthJzoGJYnnvzYVbL3TheVWodvw6M
	BGEf6GLr7JsKdnf/F+gdnh2dCMYCvASY8bgTk
X-Google-Smtp-Source: AGHT+IGV+2BTIjzIhC/pBnIElBSfuLtzDrM48BGhSG47QlrklxQIaRpReEALEVKPhcjpMSrrqG0TzA==
X-Received: by 2002:a17:906:1692:b0:ad2:1b0e:bfe5 with SMTP id a640c23a62f3a-ad21b0ec1bemr903746966b.7.1747065161196;
        Mon, 12 May 2025 08:52:41 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 17:52:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/15] xen/x86: introduce new sub-hypercall to
 propagate CPPC data
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-4-Penny.Zheng@amd.com>
 <2e1de23f-cc79-4d37-8667-0afd07736db3@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 11:11, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Monday, April 28, 2025 11:57 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> +    if ( cppc_data->flags & XEN_CPPC_CPC )
>>> +    {
>>> +        if ( cppc_data->cpc.highest_perf == 0 ||
>>> +             cppc_data->cpc.highest_perf > UINT8_MAX ||
>>> +             cppc_data->cpc.nominal_perf == 0 ||
>>> +             cppc_data->cpc.nominal_perf > UINT8_MAX ||
>>> +             cppc_data->cpc.lowest_nonlinear_perf == 0 ||
>>> +             cppc_data->cpc.lowest_nonlinear_perf > UINT8_MAX ||
>>> +             cppc_data->cpc.lowest_perf == 0 ||
>>> +             cppc_data->cpc.lowest_perf > UINT8_MAX ||
>>> +             cppc_data->cpc.lowest_perf >
>>> +                cppc_data->cpc.lowest_nonlinear_perf ||
>>
>> Where's this ordering spelled out in the spec?
>>
> 
> Clip a snippet from description on lowest performance[1], we may deduce that
> ```
> Selecting a performance level lower than the lowest nonlinear performance level may actually cause an efficiency penalty,
> but should reduce the instantaneous power consumption of the processor
> ```
> lowest is smaller than lowest nonlinear

I can't imply that from the quoted sentence. It describes what happens in that
situation, but it doesn't exclude the opposite relationship (in which case the
described situation simply can't occur).

>>> +             cppc_data->cpc.lowest_nonlinear_perf >
>>> +                cppc_data->cpc.nominal_perf ||
>>> +             cppc_data->cpc.nominal_perf > cppc_data->cpc.highest_perf )
>>> +            /*
>>> +             * Right now, Xen doesn't actually use perf values
>>> +             * in ACPI _CPC table, warning is enough.
>>> +             */
>>> +            printk(XENLOG_WARNING
>>> +                   "Broken CPPC perf values: lowest(%u), nonlinear_lowest(%u),
>> nominal(%u), highest(%u)\n",
>>> +                   cppc_data->cpc.lowest_perf,
>>> +                   cppc_data->cpc.lowest_nonlinear_perf,
>>> +                   cppc_data->cpc.nominal_perf,
>>> +                   cppc_data->cpc.highest_perf);
>>
>> If this warning was to ever surface, it would likely surface for every CPU.
>> That's unnecessarily verbose, I guess. Please consider using printk_once() here.
>>
> 
> Understood
> 
>> Also, is "right now" (as the comment says) still going to be true by the end of the
>> series? Didn't I see you use the values in earlier versions?
>>
> 
> The reason why I added this comment is that in current implementation, we actually
> don't use values read from ACPI _CPC table for lowest_perf, lowest_nonlinear_perf,
> nominal_perf, and highest_perf.
> We read CPPC capability MSR to get these four values.

Oh, okay. Could you slightly extend that comment to include this detail?

>>> +    if ( cppc_data->flags == (XEN_CPPC_PSD | XEN_CPPC_CPC) )
>>
>> If either flag may be clear, ...
>>
>>> +    {
>>> +        pm_info->cppc_data = *cppc_data;
>>> +        if ( cpufreq_verbose )
>>> +        {
>>> +            print_PSD(&pm_info->cppc_data.domain_info);
>>> +            print_CPPC(&pm_info->cppc_data);
>>
>> ... why unconditionally loog both?
>>
>>> +        }
>>> +
>>> +        pm_info->init = XEN_CPPC_INIT;
>>
>> Plus is it correct to set this flag if either of the incoming flags was clear?
> 
> Hmm, I may not understand what you mean here...
> I log and set this flag only when both flags are set (cppc_data->flags == (XEN_CPPC_PSD | XEN_CPPC_CPC))
> _PSD entry and _CPC entry are both mandatory
> Did you suggest that we shall give warning message when either flag is clear?

Oh, sorry - I read & where you have == actually. Hence why I thought only
one of the flags may be set. Please disregard those comments of mine.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 15:55:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:55:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981802.1368207 (Exim 4.92)
	(envelope-from )
	id 1uEVV2-0001kx-UD; Mon, 12 May 2025 15:55:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981802.1368207; Mon, 12 May 2025 15:55: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 1uEVV2-0001kq-R0; Mon, 12 May 2025 15:55:28 +0000
Received: by outflank-mailman (input) for mailman id 981802;
 Mon, 12 May 2025 15:55:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEVV1-0001kj-UD
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:55:28 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 84e45d5d-2f49-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 17:55:25 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5fbe7a65609so7558891a12.0
 for ; Mon, 12 May 2025 08:55:25 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5fc9cc51276sm6050012a12.43.2025.05.12.08.55.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 08:55: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" 
X-Inumbo-ID: 84e45d5d-2f49-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747065325; x=1747670125; 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;
        bh=ClXOu/z90O3dmoZ2tVyFEerAGFbkRtZ0PJmA05IgPHU=;
        b=Gms+imt5LoiH2BJzmXZYkDI1I+MDed6NFwAsm2n5ZOg/sxt9P2OIbQ4fFSecTC6Oop
         ldKAWUeMuy/65HaGDMaKkYvJn5q5H3saNcu90ZpvjHwOtD+D0KMBe2hpLGsMpoAyjMpd
         Hq9PFz/m0rQwGplgR4fiymRcURGmTMR9KVYb2FhYznx9DzzuvSYeDTz5UrtAxUzxi+EM
         NuxGzuhiDC9tOsz1aDvzzNkDvDIBG68bt2n2qZzzNNhU+ZHiaFDhyhVlCTtnMdQNXYo4
         3YYCYIePR2KPaGnC2VYGrpJgWdUunuukRluDoGsVp/8tUje0RCPX2MnLJF648QD0N6FS
         wfFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747065325; x=1747670125;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ClXOu/z90O3dmoZ2tVyFEerAGFbkRtZ0PJmA05IgPHU=;
        b=Sqlr9Irdi+lnR83eEgHXsDIwnXk44Nfdhqrhswn2Fr1MxPhHaOCFp7Y+c1Pv+fJlLD
         dsmJ8P6X0AGes9so4NU8CwGQH/wmfEHYPPmDY2qLEDj4tOgj2mqaRpx6/9PFj22t+N51
         Wd6KyZ8GB1EdqotvP4b1kV20Eydrn8xtr2Y7A1aJgHi0szrImQXuj7tt7kamw1OLY3W+
         8rHlcozN9FQuD9dMnhHgNT8jIG69iQRACJT/Y1OpGRKx5Wej4CJMuQMqYKAkN3frqfJu
         FJ7d7F7rBLBdgMeyqEj0QIXeYa4nc0V3vRbhDlRrtX1ovtW/PeHCGaVY632OF05ooHDD
         3R8Q==
X-Gm-Message-State: AOJu0YyrXbTiXiEa5T7noAHohR5nzGoiLiYxwT3/VuyRW+8kA2s5OCJm
	nPspR74XdhIPMEN/G8J3IEeNEhLanPSwAFZR5r/aDm37TuH3JsSQfjzuWQ==
X-Gm-Gg: ASbGncsjNhM9cHj5CJ8/jUn5OAOI32jhku71+HOT0m3PgLWGtq1YD8ZCOJR+ZKr2dfl
	nvDKM+CXVts0AEfhi8dWYU+RQgBq+rm8532ZrFDMgQFyjQhX8hgerIWOyE8cc/OnMb3VBD4gc4L
	umAGI7NP7WES2y6JARg/k5suwv53/DmNsMUbVKg5XB65BH57Q8RIT7M69f6JlVL1hxE9LEAWSEi
	7W12ML5Mkb/2KQObupX2yR4EuHV6Vha94a1b51XD6WvSX/eyRDe1BomSkN1ocrFT6FVsilyWgFk
	5NH4s2cUrBCLWVNRSpwAPyTmudXmQB/+xf9o2wdJghcLUXziRsJkgXzk+p5KwQ1k9H+o75DOo5l
	UeBrvFFOUsd9ykoqmjg==
X-Google-Smtp-Source: AGHT+IETqaaXAIFXU5tt3PC+pzrwGtqnPDwvhKrb+QT17NT4XQB5T1fTVSVA1DinRpFl/yX8iRSTQg==
X-Received: by 2002:a05:6402:2710:b0:5fb:d2dc:523a with SMTP id 4fb4d7f45d1cf-5fca078eebamr11941125a12.15.1747065324421;
        Mon, 12 May 2025 08:55:24 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v1] xen/riscv: add initialization support for virtual SBI UART (vSBI UART)
Date: Mon, 12 May 2025 17:55:21 +0200
Message-ID: <1f380b7061496f999d4d60a60b58f494dae886e1.1747064551.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This is the first step toward supporting a vSBI UART.

The implementation checks for the presence of the "vsbi_uart" property
in the device tree. If present, the vSBI UART is initialized by:
- Allocating a structure that holds Xen console rings and character
  buffers.
- Initializing the vSBI UART spinlock.

This commit introduces the following:
- domain_vsbi_uart_init() and domain_vsbi_uart_deinit() functions.
- A new arch_kernel_info structure with a vsbi_uart member.
- A vsbi_uart structure to hold information related to the vSBI
  driver, including:
  - Whether the vSBI UART backend is in the domain or in Xen.
  - If the backend is in Xen: details such as ring buffer, ring page,
    Xen console ring indexes, and character buffers.
  - A spinlock for synchronization.

Also, introduce init_vuart() which is going to be called by dom0less
generic code during guest domain construction.

Signed-off-by: Oleksii Kurochko 
---
This patch is independent from other RISC-V connected patch series, but it could
be a merge conflict with some patches of other patch series.
---
 xen/arch/riscv/Makefile                |  2 +
 xen/arch/riscv/dom0less-build.c        | 30 +++++++++++++
 xen/arch/riscv/include/asm/domain.h    |  4 ++
 xen/arch/riscv/include/asm/kernel.h    | 21 +++++++++
 xen/arch/riscv/include/asm/vsbi-uart.h | 58 ++++++++++++++++++++++++
 xen/arch/riscv/vsbi-uart.c             | 62 ++++++++++++++++++++++++++
 6 files changed, 177 insertions(+)
 create mode 100644 xen/arch/riscv/dom0less-build.c
 create mode 100644 xen/arch/riscv/include/asm/kernel.h
 create mode 100644 xen/arch/riscv/include/asm/vsbi-uart.h
 create mode 100644 xen/arch/riscv/vsbi-uart.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index d882c57528..89a1897228 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,5 +1,6 @@
 obj-y += aplic.o
 obj-y += cpufeature.o
+obj-y += dom0less-build.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
 obj-y += intc.o
@@ -14,6 +15,7 @@ obj-y += stubs.o
 obj-y += time.o
 obj-y += traps.o
 obj-y += vm_event.o
+obj-y += vsbi-uart.o
 
 $(TARGET): $(TARGET)-syms
 	$(OBJCOPY) -O binary -S $< $@
diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c
new file mode 100644
index 0000000000..afce2f606d
--- /dev/null
+++ b/xen/arch/riscv/dom0less-build.c
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
+                      const struct dt_device_node *node)
+{
+    int rc = -EINVAL;
+
+    kinfo->arch.vsbi_uart = dt_property_read_bool(node, "vsbi_uart");
+
+    if ( kinfo->arch.vsbi_uart )
+    {
+        rc = domain_vsbi_uart_init(d, NULL);
+        if ( rc < 0 )
+            return rc;
+    }
+
+    if ( rc )
+        panic("%s: what a domain should use as an UART?\n", __func__);
+
+    return rc;
+}
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index c3d965a559..c312827d18 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -5,6 +5,8 @@
 #include 
 #include 
 
+#include 
+
 struct hvm_domain
 {
     uint64_t              params[HVM_NR_PARAMS];
@@ -18,6 +20,8 @@ struct arch_vcpu {
 
 struct arch_domain {
     struct hvm_domain hvm;
+
+    struct vsbi_uart vsbi_uart;
 };
 
 #include 
diff --git a/xen/arch/riscv/include/asm/kernel.h b/xen/arch/riscv/include/asm/kernel.h
new file mode 100644
index 0000000000..15c13da158
--- /dev/null
+++ b/xen/arch/riscv/include/asm/kernel.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef ASM__RISCV__KERNEL_H
+#define ASM__RISCV__KERNEL_H
+
+struct arch_kernel_info
+{
+    /* Enable vsbi_uart emulation */
+    bool vsbi_uart;
+};
+
+#endif /* #ifdef ASM__RISCV__KERNEL_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/riscv/include/asm/vsbi-uart.h b/xen/arch/riscv/include/asm/vsbi-uart.h
new file mode 100644
index 0000000000..144e3191ff
--- /dev/null
+++ b/xen/arch/riscv/include/asm/vsbi-uart.h
@@ -0,0 +1,58 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef ASM__RISCV__VSBI_UART_H
+#define ASM__RISCV__VSBI_UART_H
+
+#include 
+#include 
+
+#include 
+
+struct domain;
+struct page_info;
+
+#define VSBI_UART_FIFO_SIZE 32
+#define VSBI_UART_OUT_BUF_SIZE 128
+
+struct vsbi_uart_xen_backend {
+    char in[VSBI_UART_FIFO_SIZE];
+    char out[VSBI_UART_OUT_BUF_SIZE];
+    XENCONS_RING_IDX in_cons, in_prod;
+    XENCONS_RING_IDX out_prod;
+};
+
+struct vsbi_uart {
+    bool backend_in_domain;
+    union {
+        struct {
+            void *ring_buf;
+            struct page_info *ring_page;
+        } dom;
+        struct vsbi_uart_xen_backend *xen;
+    } backend;
+
+    spinlock_t lock;
+};
+
+/*
+ * TODO: we don't support an option that backend is in a domain.
+ *       At the moment, backend is ib Xen.
+ *       This structure should be implemented in the case if backend
+ *       is in a domain.
+ */
+struct vsbi_uart_init_info {
+};
+
+int domain_vsbi_uart_init(struct domain *d , struct vsbi_uart_init_info *info);
+void domain_vsbi_uart_deinit(struct domain *d);
+
+#endif /* ASM__RISCV__VSBI_UART_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/riscv/vsbi-uart.c b/xen/arch/riscv/vsbi-uart.c
new file mode 100644
index 0000000000..5fe617ae30
--- /dev/null
+++ b/xen/arch/riscv/vsbi-uart.c
@@ -0,0 +1,62 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+int domain_vsbi_uart_init(struct domain *d, struct vsbi_uart_init_info *info)
+{
+    int rc;
+    struct vsbi_uart *vsbi_uart = &d->arch.vsbi_uart;
+
+    if ( vsbi_uart->backend.dom.ring_buf )
+    {
+        printk("%s: ring_buf != 0\n", __func__);
+        return -EINVAL;
+    }
+
+    /*
+     * info is NULL when the backend is in Xen.
+     * info is != NULL when the backend is in a domain.
+     */
+    if ( info != NULL )
+    {
+        printk("%s: vsbi_uart backend in a domain isn't supported\n", __func__);
+        rc = -EOPNOTSUPP;
+        goto out;
+    }
+    else
+    {
+        vsbi_uart->backend_in_domain = false;
+
+        vsbi_uart->backend.xen = xzalloc(struct vsbi_uart_xen_backend);
+        if ( vsbi_uart->backend.xen == NULL )
+        {
+            rc = -ENOMEM;
+            goto out;
+        }
+    }
+
+    spin_lock_init(&vsbi_uart->lock);
+
+    return 0;
+
+out:
+    domain_vsbi_uart_deinit(d);
+
+    return rc;
+}
+
+void domain_vsbi_uart_deinit(struct domain *d)
+{
+    struct vsbi_uart *vsbi_uart = &d->arch.vsbi_uart;
+
+    if ( vsbi_uart->backend_in_domain )
+        printk("%s: backed in a domain isn't supported\n", __func__);
+    else
+        XFREE(vsbi_uart->backend.xen);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 15:58:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 15:58:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981811.1368218 (Exim 4.92)
	(envelope-from )
	id 1uEVXV-0002JK-Bj; Mon, 12 May 2025 15:58:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981811.1368218; Mon, 12 May 2025 15: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 1uEVXV-0002JD-7E; Mon, 12 May 2025 15:58:01 +0000
Received: by outflank-mailman (input) for mailman id 981811;
 Mon, 12 May 2025 15:57:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEVXT-0002Io-Ct
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 15:57:59 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dfc952ba-2f49-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 17:57:58 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ad1a87d93f7so718547066b.0
 for ; Mon, 12 May 2025 08:57: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
 a640c23a62f3a-ad2198b6ebcsm629255866b.185.2025.05.12.08.57.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 08:57: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" 
X-Inumbo-ID: dfc952ba-2f49-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747065478; x=1747670278; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=URsiW6etZeVXBbbA4YDam9YA558UTVI6TLs+9tPd8hA=;
        b=R6ZNdu7bgMeqILBcPzPODeR1qBrUAXEBT++84hkx0xR/bMo7B3eJ8Ba6wZfeZ4uD5z
         dfzcnftL5Jhwf+VHtH4JObA4uFAo9j0JSvF4lVRkmSXHezz9ZZ9zYr3gxUMj/R5Xx5gU
         h9M92IrBnqt6YHEUmyGPym/24yPVjB3vl6G8hpnqnNkQgZWt4AqPpj3BsE6Te8ODP/VR
         H6WrkRdmPB+LZ/ugwv9WrT7ASEL8PMq2raqNkQZDFaK9ONBso+4U9tR8a5unMM3lYHDY
         qpdNzbJbW8dVC0Z2iGozMD35o1qsg1G8mwPJWdQK+9GHPdyz2tht5JoDcM0GWl8m/ygZ
         LYjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747065478; x=1747670278;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=URsiW6etZeVXBbbA4YDam9YA558UTVI6TLs+9tPd8hA=;
        b=HJNh5Nv+YS1AS/BcsBb888vDXp5ZqzhC+ejpYXzZA9UxHa3NPc8pA1w6mz9m9nfOlT
         wJbFFtud9Tj2OBV0O+KzhqSu16l+ZoZ09VUT3EtPV/pqho8UQm+8Mwa/1g/2Kqd2+RDU
         dn5pCIauxTuc7UXoQHZq6wVC1XeDy7RFDK4pi3VyfTlIQgPZPOLPKE25LWXfnTY9XuQN
         Mzgru1nYVCHS3kdqziWhfSO7wXYTybhEY8SGJwZWRxd7X2a9mRM7XWiEpQUyW6xlU/qV
         g6aQ4Y/3S68Ro2NjPqx/7v8OCwh6Pl48ZXq4wNQqdXr5/APHSr31zH2+xJEbaqEGF4t7
         Ja0w==
X-Forwarded-Encrypted: i=1; AJvYcCW+NJn/vGPtTNMYkI+aeAMn/KdbgGVAAMd1u4L5TBaGHKiM3gpWk9oCDS4z6RZYO2JtcW3+w8fwEPw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxTMTejKXnj/uA4Rl4Wnh0Hoh+jr3Unw5RMC9FyGhpuJz2FJUzA
	zkO49kH3ZgKqECslnHdPy1Vb93GEDDgfFR5NG/r/P97UBl+nQC4NzeYPTacqDw==
X-Gm-Gg: ASbGnctwrQOUQclEAV4pE/ng8qesEPWOfZwMEduRYubBbkWaG5zeDAc4/xvFZQIwdFN
	t4Z1nyimWaD/bWveuioA3Mmndx1NgpFIU9tC+C92A21J52tcmRxaua76kUez/KkEVxJE47n0iYi
	cgltSH87TU98cFgeAThtcnDHn930EjebPraQiA3iBu9u/DOwSc6nGTgUxtkQJ3OezgYIi8Q6Jd5
	tpmTgCOmfxO17XTWyDyqc186TteNPFkOw0ulkoN9WzNS3Y7TsrqxhIgVVQYeojJRaQM/AGjBDHu
	H/qs78n61Dc2mxPS7WHefKtPts2dK7WXsDX3X8t2T2EhthhZNZpl0YLGUIjXxmDvaYfQ+oWb1+N
	OMIGRKjA7hsFL2lKOdHosXd3XUNmdSLiZIIAY
X-Google-Smtp-Source: AGHT+IGYzBCPpKKDd6jx8W288tNm6UNLaayrzFAg/SP6KqOZEzURr1agHSigVs4ba4R7TcJO9Rr8jg==
X-Received: by 2002:a17:907:7216:b0:ad3:f3dc:e36d with SMTP id a640c23a62f3a-ad3f3dce636mr251179766b.50.1747065477824;
        Mon, 12 May 2025 08:57:57 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 17:57:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-5-Penny.Zheng@amd.com>
 <2f3702f3-a46b-4161-a890-7aad9bbbcac4@suse.com>
 <889d2b2b-db42-43d2-9da0-dcd130d64d9c@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.05.2025 05:18, Penny, Zheng wrote:
> [Public]
> 
> Hi,
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Tuesday, April 29, 2025 7:47 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
>>
>> On 29.04.2025 12:36, Jan Beulich wrote:
>>> On 14.04.2025 09:40, Penny Zheng wrote:
>>>> --- a/xen/drivers/cpufreq/cpufreq.c
>>>> +++ b/xen/drivers/cpufreq/cpufreq.c
>>>> @@ -71,6 +71,49 @@ unsigned int __initdata cpufreq_xen_cnt = 1;
>>>>
>>>>  static int __init cpufreq_cmdline_parse(const char *s, const char
>>>> *e);
>>>>
>>>> +static bool __init cpufreq_opts_contain(enum cpufreq_xen_opt option)
>>>> +{
>>>> +    unsigned int count = cpufreq_xen_cnt;
>>>> +
>>>> +    while ( count )
>>>> +    {
>>>> +        if ( cpufreq_xen_opts[--count] == option )
>>>> +            return true;
>>>> +    }
>>>> +
>>>> +    return false;
>>>> +}
>>>> +
>>>> +static int __init handle_cpufreq_cmdline(enum cpufreq_xen_opt
>>>> +option) {
>>>> +    int ret = 0;
>>>> +
>>>> +    if ( cpufreq_opts_contain(option) )
>>>> +    {
>>>> +        const char *cpufreq_opts_str[] = { "CPUFREQ_xen",
>>>> + "CPUFREQ_hwp" };
>>>
>>>         const char *const __initconstrel cpufreq_opts_str[] = {
>>> "CPUFREQ_xen", "CPUFREQ_hwp" };
>>>
>>> (line wrapped suitably, of course) Or maybe even better
>>>
>>>         const char __initconst cpufreq_opts_str[][12] = {
>>> "CPUFREQ_xen", "CPUFREQ_hwp" };
>>>
>>> for the string literals to also end up in .init.rodata.
>>
>> Actually, it didn't even occur to me that there might be a "static" missing here, too.
> 
> Sorry, I may need more explanation, what is the "static" missing you are referring?

In your code cpufreq_opts_str[] is an automatic variable, which the compiler
needs to emit code for in order to instantiate it on the stack. This can be
avoided if you make the array a static variable, as then all construction
occurs at build time.

>> Plus I'm missing any arrangement for the array slots to remain in sync with the
>> corresponding enumerators. With that ...
>>
> 
> Thanks for the detailed instructions, learned and I'll change it to
>         const char __initconst cpufreq_opts_str[][4] = { "xen", "hwp" };
> And for in sync with the corresponding enumerators, maybe we shall add comment here,
>         /* The order of cpufreq string literal must be in sync with  the order in "enum cpufreq_xen_opt" */

Instead of a comment I has rather hoping for some use of dedicated array slot
initializers.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 12 16:02:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 16:02:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981820.1368226 (Exim 4.92)
	(envelope-from )
	id 1uEVbr-0004ev-PR; Mon, 12 May 2025 16:02:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981820.1368226; Mon, 12 May 2025 16:02: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 1uEVbr-0004eo-Mb; Mon, 12 May 2025 16:02:31 +0000
Received: by outflank-mailman (input) for mailman id 981820;
 Mon, 12 May 2025 16:02:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEVbq-0004ei-Bk
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 16:02:30 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 80ad1046-2f4a-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 18:02:28 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad1b94382b8so755324666b.0
 for ; Mon, 12 May 2025 09:02: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
 a640c23a62f3a-ad2290a4cc2sm526861366b.183.2025.05.12.09.02.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 09:02: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" 
X-Inumbo-ID: 80ad1046-2f4a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747065748; x=1747670548; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=nBDzpcpLffFQaUT3+67+bqNJ0RPcHCafk40SE2v99U4=;
        b=OFPAEyiQwQ1hbxDTLaAuRVg53K0D4f5B/75puT3ekeSTmYDieZ/xAW897iQcKDNBcq
         f6IfiP5u85iA8r+v1yK2j/9bfylctwxugnCiQ06YGQ86+8hh+GcdXv7LBvWIK4Y5WrvE
         rj2YJ6+b26ZVgsvg7mDjQpp9I3tPK4BwdS5DNWD7VlCwBLrziC0RU8ozb7UaiiHuaS/P
         gWhL8AinsSmZiCuLrXNgqZRb4wgVq75+c8CVmUkFUbR4nthic4fOI0EQiB2mT1wU5LGY
         crYLRaDZ+GSCt0NvgNXeXX9J/i9nA8WeJ1oznR7XQBaJTEmpbe1nJICb9dTYZZYD66DV
         m+rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747065748; x=1747670548;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nBDzpcpLffFQaUT3+67+bqNJ0RPcHCafk40SE2v99U4=;
        b=CZZH/MaFtGIhsolcJJOJ4fukR8D65Y3SaEXdr7LE4fGrLyPMUPRcygQ+gsXtpoNafT
         44ab/m9LcZU+wcQEby8I/2/j3pebz4i41EyUlrxAbdzUOrT4zHiQYEWBnoooQAXAcwiC
         oS5nmRcRKL+pCX3C2rGGPSlBU7SwPB7t4qYjQjM+Iijdzmw1L+u7Ki9aBqRoG5EWbOA+
         /bJ8in7u7jp+2a7A3LEzD7oHZF+K6M7ZHevXcyxA4Rg7r5Q3dHLckhRQRKcWIwjdgc+w
         JW+NzwVGm9+Dm3lyy6WJprWA/oYt+TmeZtnfSa9ti8ysBiXd4RYguafYMXnQ4QWiwUTq
         ytMw==
X-Forwarded-Encrypted: i=1; AJvYcCXmZUwoccaMcWEqKZ38OoGEHLqFr6h+A7bAqraGzWhH3M6GdLOjDCYnxH+aK6VZIRp96/C/TjAvPAs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxWYleOSm0I8xxryr1Cn3UJAH2Ohy99cy3uCIuOxy3uKCRdEWV3
	ceMBqqbMdehRu9YLlCZcYAHO8XJjUmzE59NrGM6URaFrlsN+QVQZ4zPvLeOM6Q==
X-Gm-Gg: ASbGnctU9UN+jXlIWeI2G6sbiOVuzhx6cMNwFyat+zoG4Lxa9aPAE80GW8IC//Q993/
	/osD9hiaF/x2+44bYuhx4aT9llecw3/FkBSKSTd79nv/VQkuaX7MIU08fkN4VMd2dKcsetcTXFU
	tGLteNo1vxg7F+a6qrcbvbyjP+V4Z5YbmHAoZG5a2J/f1KPg+CPqW7wof1mOVGOEc0OyLinoToo
	gayeJBNnyLcWwXF8ToXuBi6hnQjtASyCFLKdjCi9owwm6RY/BwhUci4IgcfRNGUfH1XZfRfTk4E
	WCUMMhp/MgPKbUmvBmBJsG/p8d2iMKh4efpbtoYZa7rNgiH82mht4DrQezuetc+OMjLUMGsszB+
	u5pJtzGlPap+noDlkWk4Tn0NFh3B5s+nQoVNg
X-Google-Smtp-Source: AGHT+IFEBteYHD2pe1od47+0ZyqZSEHibimfVYcVMHJD8zvi6WL6upUaJ8ZvrWCRlyafv2yNSljCDQ==
X-Received: by 2002:a17:907:3f11:b0:ace:d710:a8d1 with SMTP id a640c23a62f3a-ad218f1bafcmr1251884266b.24.1747065747621;
        Mon, 12 May 2025 09:02:27 -0700 (PDT)
Message-ID: <9ca29295-717b-46c6-be00-a86217ec4550@suse.com>
Date: Mon, 12 May 2025 18:02:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-6-Penny.Zheng@amd.com>
 <57a3b2c0-d57d-46e3-b248-0e243f715423@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.05.2025 07:27, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Tuesday, April 29, 2025 8:52 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> @@ -573,6 +576,14 @@ ret_t do_platform_op(
>>>          }
>>>
>>>          case XEN_PM_CPPC:
>>> +            if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_CPPC) )
>>> +            {
>>> +                ret = -EOPNOTSUPP;
>>> +                break;
>>> +            }
>>
>> While at least you no longer use -ENOSYS here, I question this behavior, including
>> that for the pre-existing cases: How is the caller supposed to know whether to
>> invoke this sub-op? Ignoring errors is generally not a good idea, so it would be
>> better if the caller could blindly issue this request, getting back success unless
>> there really was an issue with the data provided.
>>
> 
> Understood.
> I will change it to ret = 0. Do you think we shall add warning info here?

No, for precisely ...

> Dom0 will send the CPPC data whenever it could.

... this reason.

Jan

> XEN_PROCESSOR_PM_CPPC
> is not set could largely be users choosing not to. In such case, silently getting back success
> shall be enough.
> 
> 
>> Jan



From xen-devel-bounces@lists.xenproject.org Mon May 12 16:17:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 16:17:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981829.1368237 (Exim 4.92)
	(envelope-from )
	id 1uEVpn-0006vM-Ug; Mon, 12 May 2025 16:16:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981829.1368237; Mon, 12 May 2025 16:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEVpn-0006vF-Rk; Mon, 12 May 2025 16:16:55 +0000
Received: by outflank-mailman (input) for mailman id 981829;
 Mon, 12 May 2025 16:16:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEVpm-0006v7-7R
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 16:16:54 +0000
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com
 [2607:f8b0:4864:20::42d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 821133ff-2f4c-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 18:16:50 +0200 (CEST)
Received: by mail-pf1-x42d.google.com with SMTP id
 d2e1a72fcca58-7424c24f88bso2948569b3a.1
 for ; Mon, 12 May 2025 09:16:50 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-74237a8f805sm6407121b3a.170.2025.05.12.09.16.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 09:16: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" 
X-Inumbo-ID: 821133ff-2f4c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747066609; x=1747671409; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=nN/S4cK2LyFgxGlldWjXucgg0EQKtBoxU2FXSYhGWuw=;
        b=JZkFH+CUqfeilhhIrDyf8GeyYtmWNRYig4vFCc6wnwgfkOlLSVKvXUCtbxn4nzH2Nr
         U35+HhgOQlnkSh03I7mlHtOPS1fGo3T//R8VKcem0sWvFu19V3J+xsVv8pxueg8qWr77
         PPa7SM1eX7DSXZo04eu5Y2MVRe1pjEcZp129w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747066609; x=1747671409;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nN/S4cK2LyFgxGlldWjXucgg0EQKtBoxU2FXSYhGWuw=;
        b=kndwTZ6kSypChE4FjDit68t4X0fF/0c25Dwr47T5uCgbKlm51bZSXhNugWZdCrSlBP
         tgkzMGrlpdF8VilsSqLhNQtWSE3EVruHuaFtsE+945TxgSwGusAax77jlncQyN6A1F0B
         O9ZlV07Mky/VLSkIu8QhvFXb54+Aa1Jep/nNZSf5JpoAF3p/I3SWindMQaruul/T7O3M
         3QIcEieeSjdypYYGsJtsUlCsyqfwBnMNwChJzmjlqO9IuXcet+d6OD5NAz4tBuQy3Jh2
         AYWImJtZjRVt3JqU6X8Czqm/jNQRudQWmpuV4w/DCGqX/twQhvJUuzkJy0AEzdlb61t9
         EGfA==
X-Forwarded-Encrypted: i=1; AJvYcCWBMen2OaF9AfQ2JdY4K/BfVeURaxHhw9varCuXC4d1WrVjfy6ZnnVUJ6w3m1QNunY/9HgNsqBRHIw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YySb8gvLuoiMKP2xFyCNjydAfuBUPQbUSzT/QMhvb5QtkyzgXGD
	1svFZWHMS8u8ATG+nKk3tmDq5/k7EJmhl4QT8bnCE0PVfpF/2xGvmVid4RfyqFY=
X-Gm-Gg: ASbGncvW2W2/H21SA+2kFhlSqimHTSZvgYRVOxgH35J5jF6yvBslQYAqiL6s1SNloGQ
	o/CANODB1/F4iIADrX1GtPZnx8Zz4vnS+pj8Aobr95ytYlB88xrEB4VECdJtFySqYseLyR9afJt
	9XGBHDUr6pr9BB8VqQb6eWe/xIhVZn1D4K5e/0eDWA1pTuqoi5vBxCQSVOdluwuNrDtQsx10LZg
	2Gk3Smx+VBudT0AnPGJY0p99g5DmTO/if1YffnsI1s9WVNKCTvjXd3d6LMFy/uvl00neepWwFS/
	UH5og1X1pbx3u9xbrgNhS0yhYZpMpA8R6AcaUnnBnSRiD9yg/9C4xXGE
X-Google-Smtp-Source: AGHT+IEzDQhrQsnDKcstSjrZA+fIg9XIH70ZRMYMvAo6RsBaOI1k/Dqiq37ekiLbLa5j2ahFagTpCw==
X-Received: by 2002:a05:6a00:3d43:b0:73e:23bb:e750 with SMTP id d2e1a72fcca58-7423c02cdcamr20611593b3a.23.1747066608721;
        Mon, 12 May 2025 09:16:48 -0700 (PDT)
Date: Mon, 12 May 2025 18:16:43 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Lira, Victor M" 
Cc: Jan Beulich , Jason Andryuk ,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Andrew Cooper , Xenia.Ragiadakou@amd.com,
	Alejandro.GarciaVallejo@amd.com
Subject: Re: [RFC] xen/x86: allow overlaps with non-RAM regions
Message-ID: 
References: 
 
 
 
 <775d3ac0-8f43-415a-a32d-14377092b96b@amd.com>
 <554026de-bbb4-488f-95c4-8e2f034d6d0e@amd.com>
 
 <2acad9ba-564a-4d18-9b09-dcabe8f7b025@suse.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Fri, Apr 25, 2025 at 09:47:57AM -0700, Lira, Victor M wrote:
> I can confirm with the patch the NVME drive can be accessed despite the "not
> mapping BAR" warning from Xen.
> Output log attached.

Thanks a lot for the test, and sorry for the delay in getting back.  I
was busy with other stuff and needed some time to figure out the best
way to deal with this.  Can you give a try to the patch below?  I hope
it will still fix the issue.

Thanks, Roger.
---
diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
index 7f77226c9bbf..1605ec660d0b 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -128,6 +128,9 @@ int pci_host_bridge_mappings(struct domain *d);
 
 bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
 
+static inline int pci_sanitize_bar_memory(struct rangeset *r)
+{ return 0; }
+
 #else   /*!CONFIG_HAS_PCI*/
 
 struct pci_dev;
diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h
index fd5480d67d43..d2701f2deb62 100644
--- a/xen/arch/x86/include/asm/pci.h
+++ b/xen/arch/x86/include/asm/pci.h
@@ -2,6 +2,7 @@
 #define __X86_PCI_H__
 
 #include 
+#include 
 
 #define CF8_BDF(cf8)     (  ((cf8) & 0x00ffff00U) >> 8)
 #define CF8_ADDR_LO(cf8) (   (cf8) & 0x000000fcU)
@@ -57,14 +58,7 @@ static always_inline bool is_pci_passthrough_enabled(void)
 
 void arch_pci_init_pdev(struct pci_dev *pdev);
 
-static inline bool pci_check_bar(const struct pci_dev *pdev,
-                                 mfn_t start, mfn_t end)
-{
-    /*
-     * Check if BAR is not overlapping with any memory region defined
-     * in the memory map.
-     */
-    return is_memory_hole(start, end);
-}
+bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
+int pci_sanitize_bar_memory(struct rangeset *r);
 
 #endif /* __X86_PCI_H__ */
diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
index 97b792e578f1..de9ce76e1c8a 100644
--- a/xen/arch/x86/pci.c
+++ b/xen/arch/x86/pci.c
@@ -98,3 +98,56 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
 
     return rc;
 }
+
+bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
+{
+    /*
+     * Check if BAR is not overlapping with any memory region defined
+     * in the memory map.
+     */
+    if ( !is_memory_hole(start, end) )
+        gdprintk(XENLOG_WARNING,
+                 "%pp: BAR at [%"PRI_mfn", %"PRI_mfn"] not in memory map hole\n",
+                 &pdev->sbdf, mfn_x(start), mfn_x(end));
+
+    /*
+     * Unconditionally return true, pci_sanitize_bar_memory() will remove any
+     * non-hole regions.
+     */
+    return true;
+}
+
+int pci_sanitize_bar_memory(struct rangeset *r)
+{
+    unsigned int i;
+
+    for ( i = 0; i < e820.nr_map; i++ )
+    {
+        const struct e820entry *entry = &e820.map[i];
+        int rc;
+
+        if ( !entry->size )
+            continue;
+
+        /*
+         * Remove overlaps with any memory ranges defined in the host memory
+         * map.
+         */
+        rc = rangeset_remove_range(r, PFN_DOWN(entry->addr),
+                                   PFN_DOWN(entry->addr + entry->size - 1));
+        if ( rc )
+            return rc;
+    }
+
+    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/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index ef6c965c081c..533e24ca3674 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -394,6 +394,14 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
                 return rc;
             }
         }
+
+        rc = pci_sanitize_bar_memory(bar->mem);
+        if ( rc )
+        {
+            gprintk(XENLOG_WARNING, "%pp: failed to sanitize BAR memory: %d\n",
+                    &pdev->sbdf, rc);
+            return rc;
+        }
     }
 
     /* Remove any MSIX regions if present. */



From xen-devel-bounces@lists.xenproject.org Mon May 12 17:05:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 17:05:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981843.1368250 (Exim 4.92)
	(envelope-from )
	id 1uEWb4-0005ea-Q6; Mon, 12 May 2025 17:05:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981843.1368250; Mon, 12 May 2025 17: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 1uEWb4-0005eT-MF; Mon, 12 May 2025 17:05:46 +0000
Received: by outflank-mailman (input) for mailman id 981843;
 Mon, 12 May 2025 17:05:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEWb2-0005eI-Dl
 for xen-devel@lists.xen.org; Mon, 12 May 2025 17:05:45 +0000
Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 528a4fdb-2f53-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 19:05:38 +0200 (CEST)
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uEWan-004GYa-2u;
 Mon, 12 May 2025 17:05:29 +0000
Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96)
 (envelope-from ) id 1uEWan-002juL-1i;
 Mon, 12 May 2025 17:05: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" 
X-Inumbo-ID: 528a4fdb-2f53-11f0-9ffb-bf95429c2676
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 469 v1 - x86: Indirect Target Selection
Message-Id: 
Date: Mon, 12 May 2025 17:05:29 +0000

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

                    Xen Security Advisory XSA-469

                    x86: Indirect Target Selection

ISSUE DESCRIPTION
=================

Researchers at VU Amsterdam have released Training Solo, detailing
several speculative attacks which bypass current protections.

One issue, which Intel have named Indirect Target Selection, is a bug in
the hardware support for prediction-domain isolation.  The mitigation
for this involves both microcode and software changes in Xen.

For more details, see:
  https://vusec.net/projects/training-solo
  https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/indirect-target-selection.html

Another issue discussed in the Training Solo paper pertains to
classic-BPF.  Xen does not have any capability similar to BPF filters,
so is not believed to be affected by this issue.

IMPACT
======

An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==================

Systems running all versions of Xen are affected.

Only Intel x86 CPUs are potentially affected.  CPUs from other
manufacturers are not known to be affected.

The affected Intel CPUs are believed to be those which have eIBRS
(hardware Spectre-v2 mitigations, starting with Cascade Lake) up to but
not including those which have BHI_CTRL (Alder Lake and Sapphire
Rapids).  See the Intel whitepaper for full details.

MITIGATION
==========

There are no mitigations.

RESOLUTION
==========

Intel are producing microcode to address part of this issue, by
extending IBPB.  This was released in IPU 2025.1 (February 2025).
Consult your dom0 OS vendor and/or hardware vendor for updated
microcode.

In addition to the microcode, changes are required to Xen to address the
other part of the issue.  These involve recompiling Xen using Return
Thunks (-mfunction-return).  Support for Return Thunks is available in
GCC 8 and Clang 15.  Therefore, the Xen patches further rely on a
toolchain at least this new.

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.

xsa469/xsa469-??.patch           xen-unstable
xsa469/xsa469-4.20-??.patch      Xen 4.20.x
xsa469/xsa469-4.19-??.patch      Xen 4.19.x
xsa469/xsa469-4.18-??.patch      Xen 4.18.x
xsa469/xsa469-4.17-??.patch      Xen 4.17.x

$ sha256sum xsa469*/*
24648f43282a4c4917f49a828f0889139ffd08710884c2d5d2a149213f889316  xsa469/xsa469-01.patch
f9e1e999e5121b71263ccac9e5dbc7f2422751cd8776526b59a3a535245ee271  xsa469/xsa469-02.patch
3aebd84d8c9374e8db4f28a1bd0265ff46d60a142e8cc983c0eae99a3caa4459  xsa469/xsa469-03.patch
1f836801a543d00a4e79daff0438932c7d7b5e9ee76dead124d290e805adc0f2  xsa469/xsa469-4.17-01.patch
aaa7b6967b3ff8b279675edafbccff4e1882202251e8f37c1aaab8e16f4ca8c9  xsa469/xsa469-4.17-02.patch
cf9a224628f218a7afdf7a275da270b8f469342133d3239c19a8b05adb8d9d9e  xsa469/xsa469-4.17-03.patch
5179885f9452f932b9829e942a6942d7a1bba6820c383b0e0ac7ade34f6f444c  xsa469/xsa469-4.17-04.patch
7d44272960d7ecdc920a14eb19c686c6808fe980bb85c3a467b5e343f137d927  xsa469/xsa469-4.17-05.patch
3984f20f3b84a579a4828da8c60268f55f1ff2dfc030d1790efb52a6ad659cd9  xsa469/xsa469-4.17-06.patch
8ec20c0943def1764c858c76699991aa0b7af76a8773be8219d62c240cf0b294  xsa469/xsa469-4.17-07.patch
00943be479ac428a496dec248c33e9ae9a0002e437a50c46a43d15146ddcccd8  xsa469/xsa469-4.18-01.patch
b5e9ab3ba33c7a5ad2948521a71d73b8e587d4b86fb73b3ce06557343753b097  xsa469/xsa469-4.18-02.patch
cf9a224628f218a7afdf7a275da270b8f469342133d3239c19a8b05adb8d9d9e  xsa469/xsa469-4.18-03.patch
5179885f9452f932b9829e942a6942d7a1bba6820c383b0e0ac7ade34f6f444c  xsa469/xsa469-4.18-04.patch
d7271118c516ea2b57b82afbaa67e44ebc0bee9067925850671a47ba7e6916fc  xsa469/xsa469-4.18-05.patch
99aa42f3b4d492c21d3027f74abe20183cdd411fdf94d62c10c423e6516db5aa  xsa469/xsa469-4.18-06.patch
893e3b721fe00623a8d75414f40f11033a4a3999d368a141eec8652d9733a77e  xsa469/xsa469-4.18-07.patch
a5a958452c4b3adc820692349103892ec3ffc3195c9b4e1fc55547d2ec7aec57  xsa469/xsa469-4.19-01.patch
2f3a3dadc69026ffa0a093ae34c239023e2336b3f9ec90a1ddc5df7b103c158c  xsa469/xsa469-4.19-02.patch
3aebd84d8c9374e8db4f28a1bd0265ff46d60a142e8cc983c0eae99a3caa4459  xsa469/xsa469-4.19-03.patch
bbdb2fcda3d2fe36ceaaf235700158f5a4f08c8983732265725cc7ac811c9bd2  xsa469/xsa469-4.19-04.patch
fd01af8b8cc66b6a1f0e2a7383b4c320cbb1513b7f23a7bd84fbb3e626751122  xsa469/xsa469-4.19-05.patch
1ed51e005c7f07a99793bfc97680bc02e8661412d88a853594f40a02599e03c2  xsa469/xsa469-4.19-06.patch
4dda661661f23b48f62caeaadd1b02ef79b2d7b08e61ab44c2eacdd2171f63b8  xsa469/xsa469-4.19-07.patch
27ce09ab9bb9460bec08761b2f739ce5adb292dc13664dfa425e42e5b8db8731  xsa469/xsa469-4.20-01.patch
f9e1e999e5121b71263ccac9e5dbc7f2422751cd8776526b59a3a535245ee271  xsa469/xsa469-4.20-02.patch
3aebd84d8c9374e8db4f28a1bd0265ff46d60a142e8cc983c0eae99a3caa4459  xsa469/xsa469-4.20-03.patch
bbdb2fcda3d2fe36ceaaf235700158f5a4f08c8983732265725cc7ac811c9bd2  xsa469/xsa469-4.20-04.patch
656031e56bbf8c8d0e8bd294c1e8857dd80850ae3cc68efbf42564f2b9efdb1f  xsa469/xsa469-4.20-05.patch
3343a834e0931b56490a50cc9fc7488a13a98a00923e4399020f628b3aab0220  xsa469/xsa469-4.20-06.patch
465d916cac02bb4ae1edf9db34fe5d2426ac1681a1078d331fbdf449834692c4  xsa469/xsa469-4.20-07.patch
97335c870407928039464307611c0b9687fd7cdfde5124ec5441a4fddfaa4165  xsa469/xsa469-04.patch
226771d9359b3c341c0978a145c29478d4c6ca196ec67d48c3df6115aee27940  xsa469/xsa469-05.patch
17eae8965871975569be4228943d5136eb65951d9c9513d2b0fe743e8cf8e4ef  xsa469/xsa469-06.patch
fa8b7ed035e242a3881431150ee86965f26520dab4432e3f7ac9862063491f72  xsa469/xsa469-07.patch
$
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmgiKiwMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ34YIAL+cSkrufuniNR6qUkRfhVJhuB8fZ+xfg6Cb37H6
Gsqc2b+ABlDDb0SLPhN/LcPTSOL5ypoWZ6+ZUZg+66++O8NjfBu7HDaNFlQsN6o3
cCV1Go04fMivE5BygYwhyvGUTCCoB21+AZAdWU6MHZcgrof2rJmaB+D+Und6ihd9
g9kQYRQNoWs/tyRrv27XUdmRokh1ozB6bcPAaCMOpbHDiQwVtHogUruFS7Gaoahx
tv/NeTzl8NKtpovBK1KHGxCvcLnDTz3CKQbV0W653qvt743H6/5nA9LwFdOKWG8T
UzIfCGVVgUo8MjLIwAnqSvH1pD3btMLzosdl0Eg6ekuQW84=
=/wFw
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-01.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-01.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2FsdGVybmF0aXZlOiBTdXBwb3J0IHJlcGxhY2Vt
ZW50cyB3aGVuIGEgZmVhdHVyZSBpcyBub3QgcHJlc2VudAoKVXNlIHRoZSB0
b3AgYml0IG9mIGEtPmNwdWlkIHRvIGV4cHJlc3MgaW52ZXJ0ZWQgcG9sYXJp
dHkuICBUaGlzIHJlcXVpcmVzCnN0cmlwcGluZyB0aGUgdG9wIGJpdCBiYWNr
IG91dCB3aGVuIHBlcmZvcm1pbmcgdGhlIHNhbml0eSBjaGVja3MuCgpEZXNw
aXRlIG9ubHkgYmVpbmcgdXNlZCBvbmNlLCBjcmVhdGUgYSByZXBsYWNlIGJv
b2xlYW4gdG8gZXhwcmVzcyB0aGUgZGVjaXNpb24KbW9yZSBjbGVhcmx5IGlu
IF9hcHBseV9hbHRlcm5hdGl2ZXMoKS4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0t
Z2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94
ODYvYWx0ZXJuYXRpdmUuYwppbmRleCA0M2IwMDk4ODhjMDIuLjRkMWJiZTcz
MTNmZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMK
KysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTIyOCw2ICsy
MjgsOCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBseV9h
bHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAgICAg
IHVpbnQ4X3QgKnJlcGwgPSBBTFRfUkVQTF9QVFIoYSk7CiAgICAgICAgIHVp
bnQ4X3QgYnVmW01BWF9QQVRDSF9MRU5dOwogICAgICAgICB1bnNpZ25lZCBp
bnQgdG90YWxfbGVuID0gYS0+b3JpZ19sZW4gKyBhLT5wYWRfbGVuOworICAg
ICAgICB1bnNpZ25lZCBpbnQgZmVhdCA9IGEtPmNwdWlkICYgfkFMVF9GTEFH
X05PVDsKKyAgICAgICAgYm9vbCBpbnYgPSBhLT5jcHVpZCAmIEFMVF9GTEFH
X05PVCwgcmVwbGFjZTsKIAogICAgICAgICBpZiAoIGEtPnJlcGxfbGVuID4g
dG90YWxfbGVuICkKICAgICAgICAgewpAQCAtMjQ1LDExICsyNDcsMTEgQEAg
c3RhdGljIGludCBpbml0X29yX2xpdmVwYXRjaCBfYXBwbHlfYWx0ZXJuYXRp
dmVzKHN0cnVjdCBhbHRfaW5zdHIgKnN0YXJ0LAogICAgICAgICAgICAgcmV0
dXJuIC1FTk9TUEM7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAoIGEtPmNw
dWlkID49IE5DQVBJTlRTICogMzIgKQorICAgICAgICBpZiAoIGZlYXQgPj0g
TkNBUElOVFMgKiAzMiApCiAgICAgICAgIHsKICAgICAgICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUgogICAgICAgICAgICAgICAgICAgICJBbHQgZm9yICVw
cywgZmVhdHVyZSAlI3ggb3V0c2lkZSBvZiBmZWF0dXJlc2V0IHJhbmdlICUj
eFxuIiwKLSAgICAgICAgICAgICAgICAgICBBTFRfT1JJR19QVFIoYSksIGEt
PmNwdWlkLCBOQ0FQSU5UUyAqIDMyKTsKKyAgICAgICAgICAgICAgICAgICBB
TFRfT1JJR19QVFIoYSksIGZlYXQsIE5DQVBJTlRTICogMzIpOwogICAgICAg
ICAgICAgcmV0dXJuIC1FUkFOR0U7CiAgICAgICAgIH0KIApAQCAtMjcxLDgg
KzI3MywxNCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAg
ICAgIGlmICggYS0+cHJpdiApCiAgICAgICAgICAgICBjb250aW51ZTsKIAor
ICAgICAgICAvKgorICAgICAgICAgKiBTaG91bGQgYSByZXBsYWNlbWVudCBi
ZSBwZXJmb3JtZWQ/ICBNb3N0IHJlcGxhY2VtZW50cyBoYXZlIHBvc2l0aXZl
CisgICAgICAgICAqIHBvbGFyaXR5LCBidXQgd2Ugc3VwcG9ydCBuZWdhdGl2
ZSBwb2xhcml0eSB0b28uCisgICAgICAgICAqLworICAgICAgICByZXBsYWNl
ID0gYm9vdF9jcHVfaGFzKGZlYXQpIF4gaW52OworCiAgICAgICAgIC8qIElm
IHRoZXJlIGlzIG5vIHJlcGxhY2VtZW50IHRvIG1ha2UsIHNlZSBhYm91dCBv
cHRpbWlzaW5nIHRoZSBub3BzLiAqLwotICAgICAgICBpZiAoICFib290X2Nw
dV9oYXMoYS0+Y3B1aWQpICkKKyAgICAgICAgaWYgKCAhcmVwbGFjZSApCiAg
ICAgICAgIHsKICAgICAgICAgICAgIC8qIE9yaWdpbiBzaXRlIHNpdGUgYWxy
ZWFkeSB0b3VjaGVkPyAgRG9uJ3Qgbm9wIGFueXRoaW5nLiAqLwogICAgICAg
ICAgICAgaWYgKCBiYXNlLT5wcml2ICkKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS1hc20uaCBiL3hlbi9hcmNo
L3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS1hc20uaAppbmRleCAyMmRh
OWY4OWYxNWEuLjNlYjBmNGU4YTAyYSAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLWFzbS5oCisrKyBiL3hlbi9h
cmNoL3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS1hc20uaApAQCAtMTIs
NyArMTIsNyBAQAogICogaW5zdHJ1Y3Rpb24uIFNlZSBhcHBseV9hbHRlcm5h
dGl2ZXMoKS4KICAqLwogLm1hY3JvIGFsdGluc3RydWN0aW9uX2VudHJ5IG9y
aWcsIHJlcGwsIGZlYXR1cmUsIG9yaWdfbGVuLCByZXBsX2xlbiwgcGFkX2xl
bgotICAgIC5pZiBcZmVhdHVyZSA+PSBOQ0FQSU5UUyAqIDMyCisgICAgLmlm
ICgoXGZlYXR1cmUpICYgfkFMVF9GTEFHX05PVCkgPj0gTkNBUElOVFMgKiAz
MgogICAgICAgICAuZXJyb3IgImFsdGVybmF0aXZlIGZlYXR1cmUgb3V0c2lk
ZSBvZiBmZWF0dXJlc2V0IHJhbmdlIgogICAgIC5lbmRpZgogICAgIC5sb25n
IFxvcmlnIC0gLgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v
YWx0ZXJuYXRpdmUuaAppbmRleCAyOWMzZDcyNGIwN2YuLmI5ZWE0OWJkMWMz
ZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKQEAgLTEsNiArMSwxMyBAQAogI2lmbmRlZiBfX1g4Nl9BTFRF
Uk5BVElWRV9IX18KICNkZWZpbmUgX19YODZfQUxURVJOQVRJVkVfSF9fCiAK
Ky8qCisgKiBDb21tb24gdG8gYm90aCBDIGFuZCBBU00uICBFeHByZXNzIGEg
cmVwbGFjZW1lbnQgd2hlbiBhIGZlYXR1cmUgaXMgbm90CisgKiBhdmFpbGFi
bGUuCisgKi8KKyNkZWZpbmUgQUxUX0ZMQUdfTk9UICgxIDw8IDE1KQorI2Rl
ZmluZSBBTFRfTk9UKHgpIChBTFRfRkxBR19OT1QgfCAoeCkpCisKICNpZmRl
ZiBfX0FTU0VNQkxZX18KICNpbmNsdWRlIDxhc20vYWx0ZXJuYXRpdmUtYXNt
Lmg+CiAjZWxzZQpAQCAtMTQsNyArMjEsNyBAQAogc3RydWN0IF9fcGFja2Vk
IGFsdF9pbnN0ciB7CiAgICAgaW50MzJfdCAgb3JpZ19vZmZzZXQ7ICAgLyog
b3JpZ2luYWwgaW5zdHJ1Y3Rpb24gKi8KICAgICBpbnQzMl90ICByZXBsX29m
ZnNldDsgICAvKiBvZmZzZXQgdG8gcmVwbGFjZW1lbnQgaW5zdHJ1Y3Rpb24g
Ki8KLSAgICB1aW50MTZfdCBjcHVpZDsgICAgICAgICAvKiBjcHVpZCBiaXQg
c2V0IGZvciByZXBsYWNlbWVudCAqLworICAgIHVpbnQxNl90IGNwdWlkOyAg
ICAgICAgIC8qIGNwdWlkIGJpdCBzZXQgZm9yIHJlcGxhY2VtZW50ICh0b3Ag
Yml0IGlzIHBvbGFyaXR5KSAqLwogICAgIHVpbnQ4X3QgIG9yaWdfbGVuOyAg
ICAgIC8qIGxlbmd0aCBvZiBvcmlnaW5hbCBpbnN0cnVjdGlvbiAqLwogICAg
IHVpbnQ4X3QgIHJlcGxfbGVuOyAgICAgIC8qIGxlbmd0aCBvZiBuZXcgaW5z
dHJ1Y3Rpb24gKi8KICAgICB1aW50OF90ICBwYWRfbGVuOyAgICAgICAvKiBs
ZW5ndGggb2YgYnVpbGQtdGltZSBwYWRkaW5nICovCkBAIC02MSw3ICs2OCw3
IEBAIGV4dGVybiB2b2lkIGFsdGVybmF0aXZlX2luc3RydWN0aW9ucyh2b2lk
KTsKICAgICAgICAgICAgICAgICAgICAgYWx0X3JlcGxfbGVuKG4yKSkgIi0i
IGFsdF9vcmlnX2xlbikKIAogI2RlZmluZSBBTFRJTlNUUl9FTlRSWShmZWF0
dXJlLCBudW0pICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
XAotICAgICAgICAiIC5pZiAiIFNUUihmZWF0dXJlKSAiID49ICIgU1RSKE5D
QVBJTlRTICogMzIpICJcbiIgICAgICAgICAgICAgXAorICAgICAgICAiIC5p
ZiAoIiBTVFIoZmVhdHVyZSAmIH5BTFRfRkxBR19OT1QpICIpID49ICIgU1RS
KE5DQVBJTlRTICogMzIpICJcbiIgXAogICAgICAgICAiIC5lcnJvciBcImFs
dGVybmF0aXZlIGZlYXR1cmUgb3V0c2lkZSBvZiBmZWF0dXJlc2V0IHJhbmdl
XCJcbiIgXAogICAgICAgICAiIC5lbmRpZlxuIiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAg
ICAiIC5sb25nIC5MWEVOJT1fb3JpZ19zIC0gLlxuIiAgICAgICAgICAgICAv
KiBsYWJlbCAgICAgICAgICAgKi8gXAoK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-02.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-02.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2d1ZXN0OiBSZW1vdmUgdXNlIG9mIHRoZSBYZW4g
aHlwZXJjYWxsX3BhZ2UKCkluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCBJ
VFMsIFhlbiBuZWVkcyB0byBzdGFydCB1c2luZyByZXR1cm4gdGh1bmtzLgpU
aGVyZWZvcmUgdGhlIGFkdmljZSBpbiBYU0EtNDY2IGJlY29tZXMgcmVsZXZh
bnQsIGFuZCB0aGUgaHlwZXJjYWxsX3BhZ2UgbmVlZHMKdG8gYmUgcmVtb3Zl
ZC4KCkltcGxlbWVudCBlYXJseV9oeXBlcmNhbGwoKSwgd2l0aCBpbmZyYXN0
cnVjdHVyZSB0byBmaWd1cmUgb3V0IHRoZSBjb3JyZWN0Cmluc3RydWN0aW9u
IG9uIGZpcnN0IHVzZS4gIFVzZSBBTFRFUk5BVElWRSgpcyB0byByZXN1bHQg
aW4gaW5saW5lIGh5cGVyY2FsbHMsCmluY2x1ZGluZyB0aGUgQUxUX05PVCgp
IGZvcm0gc28gd2Ugb25seSBuZWVkIGEgc2luZ2xlIHN5bnRoZXRpYyBmZWF0
dXJlIGJpdC4KCk5vIG92ZXJhbGwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0IG9m
IFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTogQW5k
cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3
ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9ndWVzdC94ZW4vTWFrZWZp
bGUgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCmluZGV4IDI2
ZmI0YjEwMDdjMC4uOGIzMjUwYWE4ODg2IDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCisrKyBiL3hlbi9hcmNoL3g4Ni9n
dWVzdC94ZW4vTWFrZWZpbGUKQEAgLTEsNCArMSw0IEBACi1vYmoteSArPSBo
eXBlcmNhbGxfcGFnZS5vCitvYmotYmluLXkgKz0gaHlwZXJjYWxsLmluaXQu
bwogb2JqLXkgKz0geGVuLm8KIAogb2JqLWJpbi0kKENPTkZJR19QVkhfR1VF
U1QpICs9IHB2aC1ib290LmluaXQubwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGwuUyBiL3hlbi9hcmNoL3g4Ni9ndWVz
dC94ZW4vaHlwZXJjYWxsLlMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg
MDAwMDAwMDAwMDAwLi4wNWU0Mjk3OTRjYzQKLS0tIC9kZXYvbnVsbAorKysg
Yi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbC5TCkBAIC0wLDAg
KzEsNTAgQEAKKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4w
LW9yLWxhdGVyICovCisKKyNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPgorCisg
ICAgICAgIC5zZWN0aW9uIC5pbml0LnRleHQsICJheCIsIEBwcm9nYml0cwor
CisgICAgICAgIC8qCisgICAgICAgICAqIFVzZWQgZHVyaW5nIGVhcmx5IGJv
b3QsIGJlZm9yZSBhbHRlcm5hdGl2ZXMgaGF2ZSBydW4gYW5kIGlubGluZWQK
KyAgICAgICAgICogdGhlIGFwcHJvcHJpYXRlIGluc3RydWN0aW9uLiAgQ2Fs
bGVkIHVzaW5nIHRoZSBoeXBlcmNhbGwgQUJJLgorICAgICAgICAgKi8KK0ZV
TkMoZWFybHlfaHlwZXJjYWxsKQorICAgICAgICBjbXBiICAgICQwLCBlYXJs
eV9oeXBlcmNhbGxfaW5zbiglcmlwKQorICAgICAgICBqbCAgICAgIC5MX3Nl
dHVwCisgICAgICAgIGplICAgICAgMWYKKworICAgICAgICB2bW1jYWxsCisg
ICAgICAgIHJldAorCisxOiAgICAgIHZtY2FsbAorICAgICAgICByZXQKKwor
Lkxfc2V0dXA6CisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gc2V0dGlu
ZyB1cCB0aGUgZmlyc3QgdGltZSBhcm91bmQsIGFsbCByZWdpc3RlcnMgbmVl
ZAorICAgICAgICAgKiBwcmVzZXJ2aW5nLiAgU2F2ZSB0aGUgbm9uLWNhbGxl
ZS1zYXZlZCBvbmVzLgorICAgICAgICAgKi8KKyAgICAgICAgcHVzaCAgICAl
cjExCisgICAgICAgIHB1c2ggICAgJXIxMAorICAgICAgICBwdXNoICAgICVy
OQorICAgICAgICBwdXNoICAgICVyOAorICAgICAgICBwdXNoICAgICVyZGkK
KyAgICAgICAgcHVzaCAgICAlcnNpCisgICAgICAgIHB1c2ggICAgJXJkeAor
ICAgICAgICBwdXNoICAgICVyY3gKKyAgICAgICAgcHVzaCAgICAlcmF4CisK
KyAgICAgICAgY2FsbCAgICBlYXJseV9oeXBlcmNhbGxfc2V0dXAKKworICAg
ICAgICBwb3AgICAgICVyYXgKKyAgICAgICAgcG9wICAgICAlcmN4CisgICAg
ICAgIHBvcCAgICAgJXJkeAorICAgICAgICBwb3AgICAgICVyc2kKKyAgICAg
ICAgcG9wICAgICAlcmRpCisgICAgICAgIHBvcCAgICAgJXI4CisgICAgICAg
IHBvcCAgICAgJXI5CisgICAgICAgIHBvcCAgICAgJXIxMAorICAgICAgICBw
b3AgICAgICVyMTEKKworICAgICAgICBqbXAgICAgIGVhcmx5X2h5cGVyY2Fs
bAorRU5EKGVhcmx5X2h5cGVyY2FsbCkKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUyBiL3hlbi9hcmNoL3g4
Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUwpkZWxldGVkIGZpbGUgbW9k
ZSAxMDA2NDQKaW5kZXggN2FiNTVmYzFmNmU2Li4wMDAwMDAwMDAwMDAKLS0t
IGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGxfcGFnZS5TCisr
KyAvZGV2L251bGwKQEAgLTEsNzYgKzAsMCBAQAotI2luY2x1ZGUgPGFzbS9w
YWdlLmg+Ci0jaW5jbHVkZSA8YXNtL2FzbV9kZWZucy5oPgotI2luY2x1ZGUg
PHB1YmxpYy94ZW4uaD4KLQotICAgICAgICAuc2VjdGlvbiAiLnRleHQucGFn
ZV9hbGlnbmVkIiwgImF4IiwgQHByb2diaXRzCi0KLURBVEEoaHlwZXJjYWxs
X3BhZ2UsIFBBR0VfU0laRSkKLSAgICAgICAgIC8qIFBvaXNvbmVkIHdpdGgg
YHJldGAgZm9yIHNhZmV0eSBiZWZvcmUgaHlwZXJjYWxscyBhcmUgc2V0IHVw
LiAqLwotICAgICAgICAuZmlsbCBQQUdFX1NJWkUsIDEsIDB4YzMKLUVORCho
eXBlcmNhbGxfcGFnZSkKLQotLyoKLSAqIElkZW50aWZ5IGEgc3BlY2lmaWMg
aHlwZXJjYWxsIGluIHRoZSBoeXBlcmNhbGwgcGFnZQotICogQHBhcmFtIG5h
bWUgSHlwZXJjYWxsIG5hbWUuCi0gKi8KLSNkZWZpbmUgREVDTEFSRV9IWVBF
UkNBTEwobmFtZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAotICAgICAgICAuZ2xvYmwgSFlQRVJDQUxMXyAj
IyBuYW1lOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBcCi0gICAgICAgIC50eXBlICBIWVBFUkNBTExfICMjIG5hbWUs
IFNUVF9GVU5DOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFwKLSAgICAgICAgLnNpemUgIEhZUEVSQ0FMTF8gIyMgbmFtZSwgMzI7ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAotICAg
ICAgICAuc2V0ICAgSFlQRVJDQUxMXyAjIyBuYW1lLCBoeXBlcmNhbGxfcGFn
ZSArIF9fSFlQRVJWSVNPUl8gIyMgbmFtZSAqIDMyCi0KLURFQ0xBUkVfSFlQ
RVJDQUxMKHNldF90cmFwX3RhYmxlKQotREVDTEFSRV9IWVBFUkNBTEwobW11
X3VwZGF0ZSkKLURFQ0xBUkVfSFlQRVJDQUxMKHNldF9nZHQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChzdGFja19zd2l0Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChz
ZXRfY2FsbGJhY2tzKQotREVDTEFSRV9IWVBFUkNBTEwoZnB1X3Rhc2tzd2l0
Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChzY2hlZF9vcF9jb21wYXQpCi1ERUNM
QVJFX0hZUEVSQ0FMTChwbGF0Zm9ybV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxM
KHNldF9kZWJ1Z3JlZykKLURFQ0xBUkVfSFlQRVJDQUxMKGdldF9kZWJ1Z3Jl
ZykKLURFQ0xBUkVfSFlQRVJDQUxMKHVwZGF0ZV9kZXNjcmlwdG9yKQotREVD
TEFSRV9IWVBFUkNBTEwobWVtb3J5X29wKQotREVDTEFSRV9IWVBFUkNBTEwo
bXVsdGljYWxsKQotREVDTEFSRV9IWVBFUkNBTEwodXBkYXRlX3ZhX21hcHBp
bmcpCi1ERUNMQVJFX0hZUEVSQ0FMTChzZXRfdGltZXJfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTChldmVudF9jaGFubmVsX29wX2NvbXBhdCkKLURFQ0xBUkVf
SFlQRVJDQUxMKHhlbl92ZXJzaW9uKQotREVDTEFSRV9IWVBFUkNBTEwoY29u
c29sZV9pbykKLURFQ0xBUkVfSFlQRVJDQUxMKHBoeXNkZXZfb3BfY29tcGF0
KQotREVDTEFSRV9IWVBFUkNBTEwoZ3JhbnRfdGFibGVfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh2bV9hc3Npc3QpCi1ERUNMQVJFX0hZUEVSQ0FMTCh1cGRh
dGVfdmFfbWFwcGluZ19vdGhlcmRvbWFpbikKLURFQ0xBUkVfSFlQRVJDQUxM
KGlyZXQpCi1ERUNMQVJFX0hZUEVSQ0FMTCh2Y3B1X29wKQotREVDTEFSRV9I
WVBFUkNBTEwoc2V0X3NlZ21lbnRfYmFzZSkKLURFQ0xBUkVfSFlQRVJDQUxM
KG1tdWV4dF9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHhzbV9vcCkKLURFQ0xB
UkVfSFlQRVJDQUxMKG5taV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHNjaGVk
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoY2FsbGJhY2tfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh4ZW5vcHJvZl9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKGV2
ZW50X2NoYW5uZWxfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChwaHlzZGV2X29w
KQotREVDTEFSRV9IWVBFUkNBTEwoaHZtX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoc3lzY3RsKQotREVDTEFSRV9IWVBFUkNBTEwoZG9tY3RsKQotREVDTEFS
RV9IWVBFUkNBTEwoa2V4ZWNfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmdv
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoeGVucG11X29wKQotCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzEp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzIpCi1ERUNMQVJFX0hZUEVSQ0FM
TChhcmNoXzMpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzUpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzYp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzcpCi0KLS8qCi0gKiBMb2NhbCB2
YXJpYWJsZXM6Ci0gKiB0YWItd2lkdGg6IDgKLSAqIGluZGVudC10YWJzLW1v
ZGU6IG5pbAotICogRW5kOgotICovCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvZ3Vlc3QveGVuL3hlbi5jIGIveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94
ZW4uYwppbmRleCBjMTdmNWM0NDdhYjYuLjVjOWYzOTNjNzUxNCAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94ZW4uYworKysgYi94ZW4v
YXJjaC94ODYvZ3Vlc3QveGVuL3hlbi5jCkBAIC0yNiw3ICsyNiw2IEBACiBi
b29sIF9fcmVhZF9tb3N0bHkgeGVuX2d1ZXN0OwogCiB1aW50MzJfdCBfX3Jl
YWRfbW9zdGx5IHhlbl9jcHVpZF9iYXNlOwotZXh0ZXJuIGNoYXIgaHlwZXJj
YWxsX3BhZ2VbXTsKIHN0YXRpYyBzdHJ1Y3QgcmFuZ2VzZXQgKm1lbTsKIAog
REVGSU5FX1BFUl9DUFUodW5zaWduZWQgaW50LCB2Y3B1X2lkKTsKQEAgLTM1
LDYgKzM0LDUwIEBAIHN0YXRpYyBzdHJ1Y3QgdmNwdV9pbmZvICp2Y3B1X2lu
Zm87CiBzdGF0aWMgdW5zaWduZWQgbG9uZyB2Y3B1X2luZm9fbWFwcGVkW0JJ
VFNfVE9fTE9OR1MoTlJfQ1BVUyldOwogREVGSU5FX1BFUl9DUFUoc3RydWN0
IHZjcHVfaW5mbyAqLCB2Y3B1X2luZm8pOwogCisvKgorICogV2hpY2ggaW5z
dHJ1Y3Rpb24gdG8gdXNlIGZvciBlYXJseSBoeXBlcmNhbGxzOgorICogICA8
IDAgc2V0dXAKKyAqICAgICAwIHZtY2FsbAorICogICA+IDAgdm1tY2FsbAor
ICovCitpbnQ4X3QgX19pbml0ZGF0YSBlYXJseV9oeXBlcmNhbGxfaW5zbiA9
IC0xOworCisvKgorICogQ2FsbGVkIG9uY2UgZHVyaW5nIHRoZSBmaXJzdCBo
eXBlcmNhbGwgdG8gZmlndXJlIG91dCB3aGljaCBpbnN0cnVjdGlvbiB0bwor
ICogdXNlLiAgRXJyb3IgaGFuZGxpbmcgb3B0aW9ucyBhcmUgbGltaXRlZC4K
KyAqLwordm9pZCBhc21saW5rYWdlIF9faW5pdCBlYXJseV9oeXBlcmNhbGxf
c2V0dXAodm9pZCkKK3sKKyAgICBCVUdfT04oZWFybHlfaHlwZXJjYWxsX2lu
c24gIT0gLTEpOworCisgICAgaWYgKCAhYm9vdF9jcHVfZGF0YS54ODZfdmVu
ZG9yICkKKyAgICB7CisgICAgICAgIHVuc2lnbmVkIGludCBlYXgsIGVieCwg
ZWN4LCBlZHg7CisKKyAgICAgICAgY3B1aWQoMCwgJmVheCwgJmVieCwgJmVj
eCwgJmVkeCk7CisKKyAgICAgICAgYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ID0geDg2X2NwdWlkX2xvb2t1cF92ZW5kb3IoZWJ4LCBlY3gsIGVkeCk7Cisg
ICAgfQorCisgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ICkKKyAgICB7CisgICAgY2FzZSBYODZfVkVORE9SX0lOVEVMOgorICAgIGNh
c2UgWDg2X1ZFTkRPUl9DRU5UQVVSOgorICAgIGNhc2UgWDg2X1ZFTkRPUl9T
SEFOR0hBSToKKyAgICAgICAgZWFybHlfaHlwZXJjYWxsX2luc24gPSAwOwor
ICAgICAgICBzZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpOworICAgICAgICBicmVhazsKKworICAgIGNhc2UgWDg2X1ZFTkRP
Ul9BTUQ6CisgICAgY2FzZSBYODZfVkVORE9SX0hZR09OOgorICAgICAgICBl
YXJseV9oeXBlcmNhbGxfaW5zbiA9IDE7CisgICAgICAgIGJyZWFrOworCisg
ICAgZGVmYXVsdDoKKyAgICAgICAgQlVHKCk7CisgICAgfQorfQorCiBzdGF0
aWMgdm9pZCBfX2luaXQgZmluZF94ZW5fbGVhdmVzKHZvaWQpCiB7CiAgICAg
dWludDMyX3QgZWF4LCBlYngsIGVjeCwgZWR4LCBiYXNlOwpAQCAtMzM3LDkg
KzM4MCw2IEBAIGNvbnN0IHN0cnVjdCBoeXBlcnZpc29yX29wcyAqX19pbml0
IHhnX3Byb2JlKHZvaWQpCiAgICAgaWYgKCAheGVuX2NwdWlkX2Jhc2UgKQog
ICAgICAgICByZXR1cm4gTlVMTDsKIAotICAgIC8qIEZpbGwgdGhlIGh5cGVy
Y2FsbCBwYWdlLiAqLwotICAgIHdybXNybChjcHVpZF9lYngoeGVuX2NwdWlk
X2Jhc2UgKyAyKSwgX19wYShoeXBlcmNhbGxfcGFnZSkpOwotCiAgICAgeGVu
X2d1ZXN0ID0gdHJ1ZTsKIAogICAgIHJldHVybiAmb3BzOwpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmggYi94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vY3B1ZmVhdHVyZXMuaAppbmRleCBi
YTNkZjE3NGI3NmUuLjllM2VkMjFjMDI2ZCAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKKysrIGIveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKQEAgLTQyLDYgKzQy
LDcgQEAgWEVOX0NQVUZFQVRVUkUoWEVOX1NIU1RLLCAgICAgICAgIFg4Nl9T
WU5USCgyNikpIC8qIFhlbiB1c2VzIENFVCBTaGFkb3cgU3RhY2tzICoKIFhF
Tl9DUFVGRUFUVVJFKFhFTl9JQlQsICAgICAgICAgICBYODZfU1lOVEgoMjcp
KSAvKiBYZW4gdXNlcyBDRVQgSW5kaXJlY3QgQnJhbmNoIFRyYWNraW5nICov
CiBYRU5fQ1BVRkVBVFVSRShJQlBCX0VOVFJZX1BWLCAgICAgWDg2X1NZTlRI
KDI4KSkgLyogTVNSX1BSRURfQ01EIHVzZWQgYnkgWGVuIGZvciBQViAqLwog
WEVOX0NQVUZFQVRVUkUoSUJQQl9FTlRSWV9IVk0sICAgIFg4Nl9TWU5USCgy
OSkpIC8qIE1TUl9QUkVEX0NNRCB1c2VkIGJ5IFhlbiBmb3IgSFZNICovCitY
RU5fQ1BVRkVBVFVSRShVU0VfVk1DQUxMLCAgICAgICAgWDg2X1NZTlRIKDMw
KSkgLyogVXNlIFZNQ0FMTCBpbnN0ZWFkIG9mIFZNTUNBTEwgKi8KIAogLyog
QnVnIHdvcmRzIGZvbGxvdyB0aGUgc3ludGhldGljIHdvcmRzLiAqLwogI2Rl
ZmluZSBYODZfTlJfQlVHIDEKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaCBiL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaAppbmRleCA2NjViNDcyZDA1
YWMuLjk2MDA0ZGVjOTkwOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2d1ZXN0L3hlbi1oY2FsbC5oCisrKyBiL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaApAQCAtMzAsOSArMzAs
MTEgQEAKICAgICAoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICgg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKLSAgICAgICAgICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNb
b2Zmc2V0XSIgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAg
ICAgIEFMVEVSTkFUSVZFXzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgInZtbWNhbGwiLCBBTFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwp
LCAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4
Nl9GRUFUVVJFX1VTRV9WTUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgIDogIj1hIiAocmVzKSwgIj1EIiAodG1wX18pIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgIDogW29mZnNldF0g
ImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2FsbCksICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgICAgIjEiICgobG9uZykoYTEpKSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgKHR5cGUpcmVzOyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKQEAgLTQyLDEw
ICs0NCwxMiBAQAogICAgICh7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICBsb25nIHJlcywgdG1wX187ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBhc20gdm9sYXRp
bGUgKCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgImNhbGwgaHlwZXJjYWxsX3BhZ2Ug
KyAlY1tvZmZzZXRdIiAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgQUxURVJOQVRJVkVfMigiY2FsbCBlYXJseV9oeXBlcmNhbGwi
LCAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAidm1tY2FsbCIsIEFMVF9OT1QoWDg2X0ZFQVRVUkVfVVNFX1ZN
Q0FMTCksICAgXAorICAgICAgICAgICAgICAgICAgICAgICAgICAidm1jYWxs
IiwgWDg2X0ZFQVRVUkVfVVNFX1ZNQ0FMTCkgICAgICAgICAgICAgXAogICAg
ICAgICAgICAgOiAiPWEiIChyZXMpLCAiPUQiICh0bXBfXyksICI9UyIgKHRt
cF9fKSAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICBBU01f
Q0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgOiBbb2Zmc2V0XSAiaSIgKGhjYWxs
ICogMzIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgOiAiMCIgKGhjYWxsKSwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAiMSIg
KChsb25nKShhMSkpLCAiMiIgKChsb25nKShhMikpICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgICAgICAgICAgOiAibWVtb3J5IiApOyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICAodHlwZSlyZXM7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXApAQCAtNTUsMTAgKzU5LDEyIEBA
CiAgICAgKHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGxvbmcg
cmVzLCB0bXBfXzsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICAiY2FsbCBoeXBlcmNhbGxfcGFnZSArICVjW29mZnNl
dF0iICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICBB
TFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5cGVyY2FsbCIsICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2
bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSwgICBc
CisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2bWNhbGwiLCBYODZfRkVB
VFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAgICBcCiAgICAgICAgICAgICA6
ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSwgIj1TIiAodG1wX18pLCAiPWQi
ICh0bXBfXykgICAgICBcCiAgICAgICAgICAgICAgIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiksICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICA6
ICIwIiAoaGNhbGwpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcpKGEx
KSksICIyIiAoKGxvbmcpKGEyKSksICIzIiAoKGxvbmcpKGEzKSkgICAgICBc
CiAgICAgICAgICAgICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICh0eXBl
KXJlczsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCkBAIC02OSwxMCArNzUsMTIgQEAKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgcmVnaXN0ZXIgbG9uZyBf
YTQgYXNtICgicjEwIikgPSAoKGxvbmcpKGE0KSk7ICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICggICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNbb2Zmc2V0XSIgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIEFMVEVSTkFUSVZF
XzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtbWNhbGwiLCBB
TFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwpLCAgIFwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIj1hIiAocmVz
KSwgIj1EIiAodG1wX18pLCAiPVMiICh0bXBfXyksICI9ZCIgKHRtcF9fKSwg
ICAgIFwKICAgICAgICAgICAgICAgIj0mciIgKHRtcF9fKSBBU01fQ0FMTF9D
T05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgIDogW29mZnNldF0gImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2Fs
bCksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgICAgICAgIjEiICgobG9uZykoYTEpKSwgIjIiICgo
bG9uZykoYTIpKSwgIjMiICgobG9uZykoYTMpKSwgICAgIFwKICAgICAgICAg
ICAgICAgIjQiIChfYTQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-03.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-03.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IChNaXMpYWxpZ24gX194ODZfaW5kaXJlY3RfdGh1bmtf
KiB0byBtaXRpZ2F0ZSBJVFMKClRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRp
cmVjdApicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hl
biBpbiB0aGUgZmlyc3QgaGFsZiBvZiBhIGNhY2hlbGluZS4KCkFycmFuZ2Ug
Zm9yIF9feDg2X2luZGlyZWN0X3RodW5rXyogdG8gYWx3YXlzIGJlIGluIHRo
ZSBzZWNvbmQgaGFsZi4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDY5IC8gQ1ZF
LTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TCmluZGV4IGZkNTQ5M2MyMmIxNi4uYzRiOTc4ZDY3Yjhl
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwor
KysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMTEsNiAr
MTEsMTAgQEAKIAogI2luY2x1ZGUgPGFzbS9hc21fZGVmbnMuaD4KIAorLyog
QWxpZ25tZW50IGlzIGRlYWx0IHdpdGggZXhwbGljaXRseSBoZXJlOyBvdmVy
cmlkZSB0aGUgcmVzcGVjdGl2ZSBtYWNyby4gKi8KKyN1bmRlZiBTWU1fQUxJ
R04KKyNkZWZpbmUgU1lNX0FMSUdOKGFsaWduLi4uKQorCiAubWFjcm8gSU5E
X1RIVU5LX1JFVFBPTElORSByZWc6cmVxCiAgICAgICAgIGNhbGwgMWYKICAg
ICAgICAgaW50MwpAQCAtMzUsNiArMzksMTYgQEAKIC5tYWNybyBHRU5fSU5E
SVJFQ1RfVEhVTksgcmVnOnJlcQogICAgICAgICAuc2VjdGlvbiAudGV4dC5f
X3g4Nl9pbmRpcmVjdF90aHVua19ccmVnLCAiYXgiLCBAcHJvZ2JpdHMKIAor
ICAgICAgICAvKgorICAgICAgICAgKiBUaGUgSW5kaXJlY3QgVGFyZ2V0IFNl
bGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5zIHRoYXQK
KyAgICAgICAgICogaW5kaXJlY3QgYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRz
KSBhcmUgdW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0CisgICAgICAgICAqIGhh
bGYgb2YgYSBjYWNoZWxpbmUuICBBcnJhbmdlIGZvciB0aGVtIHRvIGJlIGlu
IHRoZSBzZWNvbmQgaGFsZi4KKyAgICAgICAgICoKKyAgICAgICAgICogQWxp
Z24gdG8gNjQsIHRoZW4gc2tpcCAzMi4KKyAgICAgICAgICovCisgICAgICAg
IC5iYWxpZ24gNjQKKyAgICAgICAgLmZpbGwgMzIsIDEsIDB4Y2MKKwogRlVO
QyhfX3g4Nl9pbmRpcmVjdF90aHVua19ccmVnKQogICAgICAgICBBTFRFUk5B
VElWRV8yIF9fc3RyaW5naWZ5KElORF9USFVOS19SRVRQT0xJTkUgXHJlZyks
ICAgICAgICAgICAgICBcCiAgICAgICAgIF9fc3RyaW5naWZ5KElORF9USFVO
S19MRkVOQ0UgXHJlZyksIFg4Nl9GRUFUVVJFX0lORF9USFVOS19MRkVOQ0Us
IFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-01.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-01.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2FsdGVybmF0aXZlOiBTdXBwb3J0IHJlcGxhY2Vt
ZW50cyB3aGVuIGEgZmVhdHVyZSBpcyBub3QgcHJlc2VudAoKVXNlIHRoZSB0
b3AgYml0IG9mIGEtPmNwdWlkIHRvIGV4cHJlc3MgaW52ZXJ0ZWQgcG9sYXJp
dHkuICBUaGlzIHJlcXVpcmVzCnN0cmlwcGluZyB0aGUgdG9wIGJpdCBiYWNr
IG91dCB3aGVuIHBlcmZvcm1pbmcgdGhlIHNhbml0eSBjaGVja3MuCgpEZXNw
aXRlIG9ubHkgYmVpbmcgdXNlZCBvbmNlLCBjcmVhdGUgYSByZXBsYWNlIGJv
b2xlYW4gdG8gZXhwcmVzcyB0aGUgZGVjaXNpb24KbW9yZSBjbGVhcmx5IGlu
IF9hcHBseV9hbHRlcm5hdGl2ZXMoKS4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0t
Z2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94
ODYvYWx0ZXJuYXRpdmUuYwppbmRleCA4MzU2NDE0YmU3MDEuLjZlZWU2ZTUw
MWFkOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMK
KysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTIwOSwxMCAr
MjA5LDEyIEBAIHN0YXRpYyB2b2lkIGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAg
ICAgIHVpbnQ4X3QgKnJlcGwgPSBBTFRfUkVQTF9QVFIoYSk7CiAgICAgICAg
IHVpbnQ4X3QgYnVmW01BWF9QQVRDSF9MRU5dOwogICAgICAgICB1bnNpZ25l
ZCBpbnQgdG90YWxfbGVuID0gYS0+b3JpZ19sZW4gKyBhLT5wYWRfbGVuOwor
ICAgICAgICB1bnNpZ25lZCBpbnQgZmVhdCA9IGEtPmNwdWlkICYgfkFMVF9G
TEFHX05PVDsKKyAgICAgICAgYm9vbCBpbnYgPSBhLT5jcHVpZCAmIEFMVF9G
TEFHX05PVCwgcmVwbGFjZTsKIAogICAgICAgICBCVUdfT04oYS0+cmVwbF9s
ZW4gPiB0b3RhbF9sZW4pOwogICAgICAgICBCVUdfT04odG90YWxfbGVuID4g
c2l6ZW9mKGJ1ZikpOwotICAgICAgICBCVUdfT04oYS0+Y3B1aWQgPj0gTkNB
UElOVFMgKiAzMik7CisgICAgICAgIEJVR19PTihmZWF0ID49IE5DQVBJTlRT
ICogMzIpOwogCiAgICAgICAgIC8qCiAgICAgICAgICAqIERldGVjdCBzZXF1
ZW5jZXMgb2YgYWx0X2luc3RyJ3MgcGF0Y2hpbmcgdGhlIHNhbWUgb3JpZ2lu
IHNpdGUsIGFuZApAQCAtMjM1LDggKzIzNywxNCBAQCBzdGF0aWMgdm9pZCBp
bml0X29yX2xpdmVwYXRjaCBfYXBwbHlfYWx0ZXJuYXRpdmVzKHN0cnVjdCBh
bHRfaW5zdHIgKnN0YXJ0LAogICAgICAgICAgICAgY29udGludWU7CiAgICAg
ICAgIH0KIAorICAgICAgICAvKgorICAgICAgICAgKiBTaG91bGQgYSByZXBs
YWNlbWVudCBiZSBwZXJmb3JtZWQ/ICBNb3N0IHJlcGxhY2VtZW50cyBoYXZl
IHBvc2l0aXZlCisgICAgICAgICAqIHBvbGFyaXR5LCBidXQgd2Ugc3VwcG9y
dCBuZWdhdGl2ZSBwb2xhcml0eSB0b28uCisgICAgICAgICAqLworICAgICAg
ICByZXBsYWNlID0gYm9vdF9jcHVfaGFzKGZlYXQpIF4gaW52OworCiAgICAg
ICAgIC8qIElmIHRoZXJlIGlzIG5vIHJlcGxhY2VtZW50IHRvIG1ha2UsIHNl
ZSBhYm91dCBvcHRpbWlzaW5nIHRoZSBub3BzLiAqLwotICAgICAgICBpZiAo
ICFib290X2NwdV9oYXMoYS0+Y3B1aWQpICkKKyAgICAgICAgaWYgKCAhcmVw
bGFjZSApCiAgICAgICAgIHsKICAgICAgICAgICAgIC8qIE9yaWdpbiBzaXRl
IHNpdGUgYWxyZWFkeSB0b3VjaGVkPyAgRG9uJ3Qgbm9wIGFueXRoaW5nLiAq
LwogICAgICAgICAgICAgaWYgKCBiYXNlLT5wcml2ICkKZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmgKaW5kZXggZWU0
Y2JlOTJjYzJiLi4zODhlNTk1Nzg2ZTAgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNo
L3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCisrKyBiL3hlbi9hcmNo
L3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCkBAIC0xLDYgKzEsMTMg
QEAKICNpZm5kZWYgX19YODZfQUxURVJOQVRJVkVfSF9fCiAjZGVmaW5lIF9f
WDg2X0FMVEVSTkFUSVZFX0hfXwogCisvKgorICogQ29tbW9uIHRvIGJvdGgg
QyBhbmQgQVNNLiAgRXhwcmVzcyBhIHJlcGxhY2VtZW50IHdoZW4gYSBmZWF0
dXJlIGlzIG5vdAorICogYXZhaWxhYmxlLgorICovCisjZGVmaW5lIEFMVF9G
TEFHX05PVCAoMSA8PCAxNSkKKyNkZWZpbmUgQUxUX05PVCh4KSAoQUxUX0ZM
QUdfTk9UIHwgKHgpKQorCiAjaWZkZWYgX19BU1NFTUJMWV9fCiAjaW5jbHVk
ZSA8YXNtL2FsdGVybmF0aXZlLWFzbS5oPgogI2Vsc2UKQEAgLTExLDcgKzE4
LDcgQEAKIHN0cnVjdCBfX3BhY2tlZCBhbHRfaW5zdHIgewogICAgIGludDMy
X3QgIG9yaWdfb2Zmc2V0OyAgIC8qIG9yaWdpbmFsIGluc3RydWN0aW9uICov
CiAgICAgaW50MzJfdCAgcmVwbF9vZmZzZXQ7ICAgLyogb2Zmc2V0IHRvIHJl
cGxhY2VtZW50IGluc3RydWN0aW9uICovCi0gICAgdWludDE2X3QgY3B1aWQ7
ICAgICAgICAgLyogY3B1aWQgYml0IHNldCBmb3IgcmVwbGFjZW1lbnQgKi8K
KyAgICB1aW50MTZfdCBjcHVpZDsgICAgICAgICAvKiBjcHVpZCBiaXQgc2V0
IGZvciByZXBsYWNlbWVudCAodG9wIGJpdCBpcyBwb2xhcml0eSkgKi8KICAg
ICB1aW50OF90ICBvcmlnX2xlbjsgICAgICAvKiBsZW5ndGggb2Ygb3JpZ2lu
YWwgaW5zdHJ1Y3Rpb24gKi8KICAgICB1aW50OF90ICByZXBsX2xlbjsgICAg
ICAvKiBsZW5ndGggb2YgbmV3IGluc3RydWN0aW9uICovCiAgICAgdWludDhf
dCAgcGFkX2xlbjsgICAgICAgLyogbGVuZ3RoIG9mIGJ1aWxkLXRpbWUgcGFk
ZGluZyAqLwoK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-02.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-02.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2d1ZXN0OiBSZW1vdmUgdXNlIG9mIHRoZSBYZW4g
aHlwZXJjYWxsX3BhZ2UKCkluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCBJ
VFMsIFhlbiBuZWVkcyB0byBzdGFydCB1c2luZyByZXR1cm4gdGh1bmtzLgpU
aGVyZWZvcmUgdGhlIGFkdmljZSBpbiBYU0EtNDY2IGJlY29tZXMgcmVsZXZh
bnQsIGFuZCB0aGUgaHlwZXJjYWxsX3BhZ2UgbmVlZHMKdG8gYmUgcmVtb3Zl
ZC4KCkltcGxlbWVudCBlYXJseV9oeXBlcmNhbGwoKSwgd2l0aCBpbmZyYXN0
cnVjdHVyZSB0byBmaWd1cmUgb3V0IHRoZSBjb3JyZWN0Cmluc3RydWN0aW9u
IG9uIGZpcnN0IHVzZS4gIFVzZSBBTFRFUk5BVElWRSgpcyB0byByZXN1bHQg
aW4gaW5saW5lIGh5cGVyY2FsbHMsCmluY2x1ZGluZyB0aGUgQUxUX05PVCgp
IGZvcm0gc28gd2Ugb25seSBuZWVkIGEgc2luZ2xlIHN5bnRoZXRpYyBmZWF0
dXJlIGJpdC4KCk5vIG92ZXJhbGwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0IG9m
IFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTogQW5k
cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3
ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9ndWVzdC94ZW4vTWFrZWZp
bGUgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCmluZGV4IDI2
ZmI0YjEwMDdjMC4uOGIzMjUwYWE4ODg2IDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCisrKyBiL3hlbi9hcmNoL3g4Ni9n
dWVzdC94ZW4vTWFrZWZpbGUKQEAgLTEsNCArMSw0IEBACi1vYmoteSArPSBo
eXBlcmNhbGxfcGFnZS5vCitvYmotYmluLXkgKz0gaHlwZXJjYWxsLmluaXQu
bwogb2JqLXkgKz0geGVuLm8KIAogb2JqLWJpbi0kKENPTkZJR19QVkhfR1VF
U1QpICs9IHB2aC1ib290LmluaXQubwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGwuUyBiL3hlbi9hcmNoL3g4Ni9ndWVz
dC94ZW4vaHlwZXJjYWxsLlMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg
MDAwMDAwMDAwMDAwLi40N2FiNjg1Y2Y4NDgKLS0tIC9kZXYvbnVsbAorKysg
Yi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbC5TCkBAIC0wLDAg
KzEsNTIgQEAKKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4w
LW9yLWxhdGVyICovCisKKyNpbmNsdWRlIDxhc20vYXNtX2RlZm5zLmg+CisK
KyAgICAgICAgLnNlY3Rpb24gLmluaXQudGV4dCwgImF4IiwgQHByb2diaXRz
CisKKyAgICAgICAgLyoKKyAgICAgICAgICogVXNlZCBkdXJpbmcgZWFybHkg
Ym9vdCwgYmVmb3JlIGFsdGVybmF0aXZlcyBoYXZlIHJ1biBhbmQgaW5saW5l
ZAorICAgICAgICAgKiB0aGUgYXBwcm9wcmlhdGUgaW5zdHJ1Y3Rpb24uICBD
YWxsZWQgdXNpbmcgdGhlIGh5cGVyY2FsbCBBQkkuCisgICAgICAgICAqLwor
RU5UUlkoZWFybHlfaHlwZXJjYWxsKQorICAgICAgICBjbXBiICAgICQwLCBl
YXJseV9oeXBlcmNhbGxfaW5zbiglcmlwKQorICAgICAgICBqbCAgICAgIC5M
X3NldHVwCisgICAgICAgIGplICAgICAgMWYKKworICAgICAgICB2bW1jYWxs
CisgICAgICAgIHJldAorCisxOiAgICAgIHZtY2FsbAorICAgICAgICByZXQK
KworLkxfc2V0dXA6CisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gc2V0
dGluZyB1cCB0aGUgZmlyc3QgdGltZSBhcm91bmQsIGFsbCByZWdpc3RlcnMg
bmVlZAorICAgICAgICAgKiBwcmVzZXJ2aW5nLiAgU2F2ZSB0aGUgbm9uLWNh
bGxlZS1zYXZlZCBvbmVzLgorICAgICAgICAgKi8KKyAgICAgICAgcHVzaCAg
ICAlcjExCisgICAgICAgIHB1c2ggICAgJXIxMAorICAgICAgICBwdXNoICAg
ICVyOQorICAgICAgICBwdXNoICAgICVyOAorICAgICAgICBwdXNoICAgICVy
ZGkKKyAgICAgICAgcHVzaCAgICAlcnNpCisgICAgICAgIHB1c2ggICAgJXJk
eAorICAgICAgICBwdXNoICAgICVyY3gKKyAgICAgICAgcHVzaCAgICAlcmF4
CisKKyAgICAgICAgY2FsbCAgICBlYXJseV9oeXBlcmNhbGxfc2V0dXAKKwor
ICAgICAgICBwb3AgICAgICVyYXgKKyAgICAgICAgcG9wICAgICAlcmN4Cisg
ICAgICAgIHBvcCAgICAgJXJkeAorICAgICAgICBwb3AgICAgICVyc2kKKyAg
ICAgICAgcG9wICAgICAlcmRpCisgICAgICAgIHBvcCAgICAgJXI4CisgICAg
ICAgIHBvcCAgICAgJXI5CisgICAgICAgIHBvcCAgICAgJXIxMAorICAgICAg
ICBwb3AgICAgICVyMTEKKworICAgICAgICBqbXAgICAgIGVhcmx5X2h5cGVy
Y2FsbAorCisgICAgICAgIC50eXBlIGVhcmx5X2h5cGVyY2FsbCwgQGZ1bmN0
aW9uCisgICAgICAgIC5zaXplIGVhcmx5X2h5cGVyY2FsbCwgLiAtIGVhcmx5
X2h5cGVyY2FsbApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2d1ZXN0L3hl
bi9oeXBlcmNhbGxfcGFnZS5TIGIveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi9o
eXBlcmNhbGxfcGFnZS5TCmRlbGV0ZWQgZmlsZSBtb2RlIDEwMDY0NAppbmRl
eCA5OTU4ZDAyY2ZkNWIuLjAwMDAwMDAwMDAwMAotLS0gYS94ZW4vYXJjaC94
ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbF9wYWdlLlMKKysrIC9kZXYvbnVsbApA
QCAtMSw3OCArMCwwIEBACi0jaW5jbHVkZSA8YXNtL3BhZ2UuaD4KLSNpbmNs
dWRlIDxhc20vYXNtX2RlZm5zLmg+Ci0jaW5jbHVkZSA8cHVibGljL3hlbi5o
PgotCi0gICAgICAgIC5zZWN0aW9uICIudGV4dC5wYWdlX2FsaWduZWQiLCAi
YXgiLCBAcHJvZ2JpdHMKLSAgICAgICAgLnAyYWxpZ24gUEFHRV9TSElGVAot
Ci1HTE9CQUwoaHlwZXJjYWxsX3BhZ2UpCi0gICAgICAgICAvKiBQb2lzb25l
ZCB3aXRoIGByZXRgIGZvciBzYWZldHkgYmVmb3JlIGh5cGVyY2FsbHMgYXJl
IHNldCB1cC4gKi8KLSAgICAgICAgLmZpbGwgUEFHRV9TSVpFLCAxLCAweGMz
Ci0gICAgICAgIC50eXBlIGh5cGVyY2FsbF9wYWdlLCBTVFRfT0JKRUNUCi0g
ICAgICAgIC5zaXplIGh5cGVyY2FsbF9wYWdlLCBQQUdFX1NJWkUKLQotLyoK
LSAqIElkZW50aWZ5IGEgc3BlY2lmaWMgaHlwZXJjYWxsIGluIHRoZSBoeXBl
cmNhbGwgcGFnZQotICogQHBhcmFtIG5hbWUgSHlwZXJjYWxsIG5hbWUuCi0g
Ki8KLSNkZWZpbmUgREVDTEFSRV9IWVBFUkNBTEwobmFtZSkgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAotICAg
ICAgICAuZ2xvYmwgSFlQRVJDQUxMXyAjIyBuYW1lOyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgIC50
eXBlICBIWVBFUkNBTExfICMjIG5hbWUsIFNUVF9GVU5DOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgLnNpemUgIEhZ
UEVSQ0FMTF8gIyMgbmFtZSwgMzI7ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXAotICAgICAgICAuc2V0ICAgSFlQRVJDQUxM
XyAjIyBuYW1lLCBoeXBlcmNhbGxfcGFnZSArIF9fSFlQRVJWSVNPUl8gIyMg
bmFtZSAqIDMyCi0KLURFQ0xBUkVfSFlQRVJDQUxMKHNldF90cmFwX3RhYmxl
KQotREVDTEFSRV9IWVBFUkNBTEwobW11X3VwZGF0ZSkKLURFQ0xBUkVfSFlQ
RVJDQUxMKHNldF9nZHQpCi1ERUNMQVJFX0hZUEVSQ0FMTChzdGFja19zd2l0
Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChzZXRfY2FsbGJhY2tzKQotREVDTEFS
RV9IWVBFUkNBTEwoZnB1X3Rhc2tzd2l0Y2gpCi1ERUNMQVJFX0hZUEVSQ0FM
TChzY2hlZF9vcF9jb21wYXQpCi1ERUNMQVJFX0hZUEVSQ0FMTChwbGF0Zm9y
bV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHNldF9kZWJ1Z3JlZykKLURFQ0xB
UkVfSFlQRVJDQUxMKGdldF9kZWJ1Z3JlZykKLURFQ0xBUkVfSFlQRVJDQUxM
KHVwZGF0ZV9kZXNjcmlwdG9yKQotREVDTEFSRV9IWVBFUkNBTEwobWVtb3J5
X29wKQotREVDTEFSRV9IWVBFUkNBTEwobXVsdGljYWxsKQotREVDTEFSRV9I
WVBFUkNBTEwodXBkYXRlX3ZhX21hcHBpbmcpCi1ERUNMQVJFX0hZUEVSQ0FM
TChzZXRfdGltZXJfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChldmVudF9jaGFu
bmVsX29wX2NvbXBhdCkKLURFQ0xBUkVfSFlQRVJDQUxMKHhlbl92ZXJzaW9u
KQotREVDTEFSRV9IWVBFUkNBTEwoY29uc29sZV9pbykKLURFQ0xBUkVfSFlQ
RVJDQUxMKHBoeXNkZXZfb3BfY29tcGF0KQotREVDTEFSRV9IWVBFUkNBTEwo
Z3JhbnRfdGFibGVfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTCh2bV9hc3Npc3Qp
Ci1ERUNMQVJFX0hZUEVSQ0FMTCh1cGRhdGVfdmFfbWFwcGluZ19vdGhlcmRv
bWFpbikKLURFQ0xBUkVfSFlQRVJDQUxMKGlyZXQpCi1ERUNMQVJFX0hZUEVS
Q0FMTCh2Y3B1X29wKQotREVDTEFSRV9IWVBFUkNBTEwoc2V0X3NlZ21lbnRf
YmFzZSkKLURFQ0xBUkVfSFlQRVJDQUxMKG1tdWV4dF9vcCkKLURFQ0xBUkVf
SFlQRVJDQUxMKHhzbV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKG5taV9vcCkK
LURFQ0xBUkVfSFlQRVJDQUxMKHNjaGVkX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoY2FsbGJhY2tfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTCh4ZW5vcHJvZl9v
cCkKLURFQ0xBUkVfSFlQRVJDQUxMKGV2ZW50X2NoYW5uZWxfb3ApCi1ERUNM
QVJFX0hZUEVSQ0FMTChwaHlzZGV2X29wKQotREVDTEFSRV9IWVBFUkNBTEwo
aHZtX29wKQotREVDTEFSRV9IWVBFUkNBTEwoc3lzY3RsKQotREVDTEFSRV9I
WVBFUkNBTEwoZG9tY3RsKQotREVDTEFSRV9IWVBFUkNBTEwoa2V4ZWNfb3Ap
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmdvX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoeGVucG11X29wKQotCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzApCi1E
RUNMQVJFX0hZUEVSQ0FMTChhcmNoXzEpCi1ERUNMQVJFX0hZUEVSQ0FMTChh
cmNoXzIpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzMpCi1ERUNMQVJFX0hZ
UEVSQ0FMTChhcmNoXzQpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzUpCi1E
RUNMQVJFX0hZUEVSQ0FMTChhcmNoXzYpCi1ERUNMQVJFX0hZUEVSQ0FMTChh
cmNoXzcpCi0KLS8qCi0gKiBMb2NhbCB2YXJpYWJsZXM6Ci0gKiB0YWItd2lk
dGg6IDgKLSAqIGluZGVudC10YWJzLW1vZGU6IG5pbAotICogRW5kOgotICov
CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL3hlbi5jIGIv
eGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94ZW4uYwppbmRleCBjNGNiMTZkZjM4
YjMuLjBkMWU2ZDA2NTg2YiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2d1
ZXN0L3hlbi94ZW4uYworKysgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL3hl
bi5jCkBAIC0zOCw3ICszOCw2IEBACiBib29sIF9fcmVhZF9tb3N0bHkgeGVu
X2d1ZXN0OwogCiB1aW50MzJfdCBfX3JlYWRfbW9zdGx5IHhlbl9jcHVpZF9i
YXNlOwotZXh0ZXJuIGNoYXIgaHlwZXJjYWxsX3BhZ2VbXTsKIHN0YXRpYyBz
dHJ1Y3QgcmFuZ2VzZXQgKm1lbTsKIAogREVGSU5FX1BFUl9DUFUodW5zaWdu
ZWQgaW50LCB2Y3B1X2lkKTsKQEAgLTQ3LDYgKzQ2LDUwIEBAIHN0YXRpYyBz
dHJ1Y3QgdmNwdV9pbmZvICp2Y3B1X2luZm87CiBzdGF0aWMgdW5zaWduZWQg
bG9uZyB2Y3B1X2luZm9fbWFwcGVkW0JJVFNfVE9fTE9OR1MoTlJfQ1BVUyld
OwogREVGSU5FX1BFUl9DUFUoc3RydWN0IHZjcHVfaW5mbyAqLCB2Y3B1X2lu
Zm8pOwogCisvKgorICogV2hpY2ggaW5zdHJ1Y3Rpb24gdG8gdXNlIGZvciBl
YXJseSBoeXBlcmNhbGxzOgorICogICA8IDAgc2V0dXAKKyAqICAgICAwIHZt
Y2FsbAorICogICA+IDAgdm1tY2FsbAorICovCitpbnQ4X3QgX19pbml0ZGF0
YSBlYXJseV9oeXBlcmNhbGxfaW5zbiA9IC0xOworCisvKgorICogQ2FsbGVk
IG9uY2UgZHVyaW5nIHRoZSBmaXJzdCBoeXBlcmNhbGwgdG8gZmlndXJlIG91
dCB3aGljaCBpbnN0cnVjdGlvbiB0bworICogdXNlLiAgRXJyb3IgaGFuZGxp
bmcgb3B0aW9ucyBhcmUgbGltaXRlZC4KKyAqLwordm9pZCBfX2luaXQgZWFy
bHlfaHlwZXJjYWxsX3NldHVwKHZvaWQpCit7CisgICAgQlVHX09OKGVhcmx5
X2h5cGVyY2FsbF9pbnNuICE9IC0xKTsKKworICAgIGlmICggIWJvb3RfY3B1
X2RhdGEueDg2X3ZlbmRvciApCisgICAgeworICAgICAgICB1bnNpZ25lZCBp
bnQgZWF4LCBlYngsIGVjeCwgZWR4OworCisgICAgICAgIGNwdWlkKDAsICZl
YXgsICZlYngsICZlY3gsICZlZHgpOworCisgICAgICAgIGJvb3RfY3B1X2Rh
dGEueDg2X3ZlbmRvciA9IHg4Nl9jcHVpZF9sb29rdXBfdmVuZG9yKGVieCwg
ZWN4LCBlZHgpOworICAgIH0KKworICAgIHN3aXRjaCAoIGJvb3RfY3B1X2Rh
dGEueDg2X3ZlbmRvciApCisgICAgeworICAgIGNhc2UgWDg2X1ZFTkRPUl9J
TlRFTDoKKyAgICBjYXNlIFg4Nl9WRU5ET1JfQ0VOVEFVUjoKKyAgICBjYXNl
IFg4Nl9WRU5ET1JfU0hBTkdIQUk6CisgICAgICAgIGVhcmx5X2h5cGVyY2Fs
bF9pbnNuID0gMDsKKyAgICAgICAgc2V0dXBfZm9yY2VfY3B1X2NhcChYODZf
RkVBVFVSRV9VU0VfVk1DQUxMKTsKKyAgICAgICAgYnJlYWs7CisKKyAgICBj
YXNlIFg4Nl9WRU5ET1JfQU1EOgorICAgIGNhc2UgWDg2X1ZFTkRPUl9IWUdP
TjoKKyAgICAgICAgZWFybHlfaHlwZXJjYWxsX2luc24gPSAxOworICAgICAg
ICBicmVhazsKKworICAgIGRlZmF1bHQ6CisgICAgICAgIEJVRygpOworICAg
IH0KK30KKwogc3RhdGljIHZvaWQgX19pbml0IGZpbmRfeGVuX2xlYXZlcyh2
b2lkKQogewogICAgIHVpbnQzMl90IGVheCwgZWJ4LCBlY3gsIGVkeCwgYmFz
ZTsKQEAgLTM0OSw5ICszOTIsNiBAQCBjb25zdCBzdHJ1Y3QgaHlwZXJ2aXNv
cl9vcHMgKl9faW5pdCB4Z19wcm9iZSh2b2lkKQogICAgIGlmICggIXhlbl9j
cHVpZF9iYXNlICkKICAgICAgICAgcmV0dXJuIE5VTEw7CiAKLSAgICAvKiBG
aWxsIHRoZSBoeXBlcmNhbGwgcGFnZS4gKi8KLSAgICB3cm1zcmwoY3B1aWRf
ZWJ4KHhlbl9jcHVpZF9iYXNlICsgMiksIF9fcGEoaHlwZXJjYWxsX3BhZ2Up
KTsKLQogICAgIHhlbl9ndWVzdCA9IHRydWU7CiAKICAgICByZXR1cm4gJm9w
czsKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVm
ZWF0dXJlcy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1
cmVzLmgKaW5kZXggYmEzZGYxNzRiNzZlLi45ZTNlZDIxYzAyNmQgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5o
CisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5o
CkBAIC00Miw2ICs0Miw3IEBAIFhFTl9DUFVGRUFUVVJFKFhFTl9TSFNUSywg
ICAgICAgICBYODZfU1lOVEgoMjYpKSAvKiBYZW4gdXNlcyBDRVQgU2hhZG93
IFN0YWNrcyAqCiBYRU5fQ1BVRkVBVFVSRShYRU5fSUJULCAgICAgICAgICAg
WDg2X1NZTlRIKDI3KSkgLyogWGVuIHVzZXMgQ0VUIEluZGlyZWN0IEJyYW5j
aCBUcmFja2luZyAqLwogWEVOX0NQVUZFQVRVUkUoSUJQQl9FTlRSWV9QViwg
ICAgIFg4Nl9TWU5USCgyOCkpIC8qIE1TUl9QUkVEX0NNRCB1c2VkIGJ5IFhl
biBmb3IgUFYgKi8KIFhFTl9DUFVGRUFUVVJFKElCUEJfRU5UUllfSFZNLCAg
ICBYODZfU1lOVEgoMjkpKSAvKiBNU1JfUFJFRF9DTUQgdXNlZCBieSBYZW4g
Zm9yIEhWTSAqLworWEVOX0NQVUZFQVRVUkUoVVNFX1ZNQ0FMTCwgICAgICAg
IFg4Nl9TWU5USCgzMCkpIC8qIFVzZSBWTUNBTEwgaW5zdGVhZCBvZiBWTU1D
QUxMICovCiAKIC8qIEJ1ZyB3b3JkcyBmb2xsb3cgdGhlIHN5bnRoZXRpYyB3
b3Jkcy4gKi8KICNkZWZpbmUgWDg2X05SX0JVRyAxCmRpZmYgLS1naXQgYS94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmggYi94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmgKaW5k
ZXggMDNkNTg2OGE5ZWZkLi5hN2U5MGFkYmFmYjcgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaAorKysg
Yi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmgK
QEAgLTQxLDkgKzQxLDExIEBACiAgICAgKHsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgICAgIGxvbmcgcmVzLCB0bXBfXzsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGFz
bSB2b2xhdGlsZSAoICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICAiY2FsbCBoeXBlcmNh
bGxfcGFnZSArICVjW29mZnNldF0iICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCisgICAgICAgICAgICBBTFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5
cGVyY2FsbCIsICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICJ2bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVS
RV9VU0VfVk1DQUxMKSwgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICJ2bWNhbGwiLCBYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAg
ICBcCiAgICAgICAgICAgICA6ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSBB
U01fQ0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICBcCi0gICAgICAgICAg
ICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiksICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICA6ICIwIiAoaGNhbGwp
LCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcpKGExKSkgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgICh0eXBlKXJlczsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCkBAIC01MywxMCArNTUsMTIgQEAKICAgICAoeyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICAgICAgbG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgYXNtIHZvbGF0aWxlICggICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgICJjYWxsIGh5
cGVyY2FsbF9wYWdlICsgJWNbb2Zmc2V0XSIgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICAgICAgICAgIEFMVEVSTkFUSVZFXzIoImNhbGwgZWFy
bHlfaHlwZXJjYWxsIiwgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgInZtbWNhbGwiLCBBTFRfTk9UKFg4Nl9G
RUFUVVJFX1VTRV9WTUNBTEwpLCAgIFwKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgInZtY2FsbCIsIFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwpICAgICAg
ICAgICAgIFwKICAgICAgICAgICAgIDogIj1hIiAocmVzKSwgIj1EIiAodG1w
X18pLCAiPVMiICh0bXBfXykgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgICAgICAgQVNNX0NBTExfQ09OU1RSQUlOVCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgIDogW29mZnNl
dF0gImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2FsbCksICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgICAgICAgIjEiICgobG9uZykoYTEpKSwgIjIiICgobG9uZykoYTIpKSAg
ICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9y
eSIgKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICAgICAgKHR5cGUpcmVzOyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKQEAgLTY2
LDEwICs3MCwxMiBAQAogICAgICh7ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAog
ICAgICAgICBsb25nIHJlcywgdG1wX187ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBhc20gdm9s
YXRpbGUgKCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAotICAgICAgICAgICAgImNhbGwgaHlwZXJjYWxsX3Bh
Z2UgKyAlY1tvZmZzZXRdIiAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICAgICAgQUxURVJOQVRJVkVfMigiY2FsbCBlYXJseV9oeXBlcmNh
bGwiLCAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAg
ICAgICAgICAgICAidm1tY2FsbCIsIEFMVF9OT1QoWDg2X0ZFQVRVUkVfVVNF
X1ZNQ0FMTCksICAgXAorICAgICAgICAgICAgICAgICAgICAgICAgICAidm1j
YWxsIiwgWDg2X0ZFQVRVUkVfVVNFX1ZNQ0FMTCkgICAgICAgICAgICAgXAog
ICAgICAgICAgICAgOiAiPWEiIChyZXMpLCAiPUQiICh0bXBfXyksICI9UyIg
KHRtcF9fKSwgIj1kIiAodG1wX18pICAgICAgXAogICAgICAgICAgICAgICBB
U01fQ0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAotICAgICAgICAgICAgOiBbb2Zmc2V0XSAiaSIgKGhj
YWxsICogMzIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICAgICAgOiAiMCIgKGhjYWxsKSwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAi
MSIgKChsb25nKShhMSkpLCAiMiIgKChsb25nKShhMikpLCAiMyIgKChsb25n
KShhMykpICAgICAgXAogICAgICAgICAgICAgOiAibWVtb3J5IiApOyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAog
ICAgICAgICAodHlwZSlyZXM7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXApAQCAtODAsMTAgKzg2LDEy
IEBACiAgICAgICAgIGxvbmcgcmVzLCB0bXBfXzsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIHJl
Z2lzdGVyIGxvbmcgX2E0IGFzbSAoInIxMCIpID0gKChsb25nKShhNCkpOyAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCi0gICAgICAgICAgICAiY2FsbCBoeXBlcmNhbGxfcGFnZSArICVjW29m
ZnNldF0iICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICBBTFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5cGVyY2FsbCIsICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICJ2bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSwg
ICBcCisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2bWNhbGwiLCBYODZf
RkVBVFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSwgIj1TIiAodG1wX18pLCAi
PWQiICh0bXBfXyksICAgICBcCiAgICAgICAgICAgICAgICI9JnIiICh0bXBf
XykgQVNNX0NBTExfQ09OU1RSQUlOVCAgICAgICAgICAgICAgICAgICAgICAg
ICBcCi0gICAgICAgICAgICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiks
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICA6ICIwIiAoaGNhbGwpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcp
KGExKSksICIyIiAoKGxvbmcpKGEyKSksICIzIiAoKGxvbmcpKGEzKSksICAg
ICBcCiAgICAgICAgICAgICAgICI0IiAoX2E0KSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-03.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-03.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IChNaXMpYWxpZ24gX194ODZfaW5kaXJlY3RfdGh1bmtf
KiB0byBtaXRpZ2F0ZSBJVFMKClRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRp
cmVjdApicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hl
biBpbiB0aGUgZmlyc3QgaGFsZiBvZiBhIGNhY2hlbGluZS4KCkFycmFuZ2Ug
Zm9yIF9feDg2X2luZGlyZWN0X3RodW5rXyogdG8gYWx3YXlzIGJlIGluIHRo
ZSBzZWNvbmQgaGFsZi4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDY5IC8gQ1ZF
LTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TCmluZGV4IGRlNmFlZjYwNjgzMi4uZTdlZjEwNGQzYmQz
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwor
KysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMzUsNiAr
MzUsMTYgQEAKIC5tYWNybyBHRU5fSU5ESVJFQ1RfVEhVTksgcmVnOnJlcQog
ICAgICAgICAuc2VjdGlvbiAudGV4dC5fX3g4Nl9pbmRpcmVjdF90aHVua19c
cmVnLCAiYXgiLCBAcHJvZ2JpdHMKIAorICAgICAgICAvKgorICAgICAgICAg
KiBUaGUgSW5kaXJlY3QgVGFyZ2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2
dWxuZXJhYmlsaXR5IG1lYW5zIHRoYXQKKyAgICAgICAgICogaW5kaXJlY3Qg
YnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUgdW5zYWZlIHdoZW4gaW4g
dGhlIGZpcnN0CisgICAgICAgICAqIGhhbGYgb2YgYSBjYWNoZWxpbmUuICBB
cnJhbmdlIGZvciB0aGVtIHRvIGJlIGluIHRoZSBzZWNvbmQgaGFsZi4KKyAg
ICAgICAgICoKKyAgICAgICAgICogQWxpZ24gdG8gNjQsIHRoZW4gc2tpcCAz
Mi4KKyAgICAgICAgICovCisgICAgICAgIC5iYWxpZ24gNjQKKyAgICAgICAg
LmZpbGwgMzIsIDEsIDB4Y2MKKwogRU5UUlkoX194ODZfaW5kaXJlY3RfdGh1
bmtfXHJlZykKICAgICAgICAgQUxURVJOQVRJVkVfMiBfX3N0cmluZ2lmeShJ
TkRfVEhVTktfUkVUUE9MSU5FIFxyZWcpLCAgICAgICAgICAgICAgXAogICAg
ICAgICBfX3N0cmluZ2lmeShJTkRfVEhVTktfTEZFTkNFIFxyZWcpLCBYODZf
RkVBVFVSRV9JTkRfVEhVTktfTEZFTkNFLCBcCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-04.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-04.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3RodW5rOiAoTWlzKWFsaWduIHRoZSBSRVRzIGlu
IGNsZWFyX2JoYl9sb29wcygpIHRvIG1pdGlnYXRlIElUUwoKVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0IGluZGlyZWN0CmJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdCBoYWxmIG9mIGEgY2Fj
aGVsaW5lLgoKY2xlYXJfYmhiX2xvb3BzKCkgaGFzIGEgcHJlY2lzZSBsYXlv
dXQgb2YgYnJhbmNoZXMuICBUaGUgYWxpZ25tZW50IGZvcgpwZXJmb3JtYW5j
ZSBjYXVzZSB0aGUgUkVUcyB0byBhbHdheXMgYmUgaW4gYW4gdW5zYWZlIHBv
c2l0aW9uLCBhbmQgY29udmVydGluZwp0aG9zZSB0byByZXR1cm4gdGh1bmtz
IGNoYW5nZXMgdGhlIGJyYW5jaGluZyBwYXR0ZXJuLiAgV2hpbGUgc3VjaCBh
IGNvbnZlcnNpb24KaXMgYmVsaWV2ZWQgdG8gYmUgc2FmZSwgY2xlYXJfYmhi
X2xvb3BzKCkgaXMgYWxzbyBhIHBlcmZvcm1hbmNlLXJlbGV2YW50CmZhc3Rw
YXRoLCBzbyAobWlzKWFsaWduIHRoZSBSRVRzIHRvIGJlIGluIGEgc2FmZSBw
b3NpdGlvbi4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0
IG9mIFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUyBi
L3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCA3ZTg2Njc4NGY3ODQu
LjA1ZjEwNDNkZjdkMCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2JoYi10
aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwpAQCAtNTIs
NyArNTIsMTIgQEAgRU5UUlkoY2xlYXJfYmhiX3RzeCkKICAqICAgcmV0CiAg
KgogICogVGhlIENBTEwvUkVUcyBhcmUgbmVjZXNzYXJ5IHRvIHByZXZlbnQg
dGhlIExvb3AgU3RyZWFtIERldGVjdG9yIGZyb20KLSAqIGludGVyZmVyaW5n
LiAgVGhlIGFsaWdubWVudCBpcyBmb3IgcGVyZm9ybWFuY2UgYW5kIG5vdCBz
YWZldHkuCisgKiBpbnRlcmZlcmluZy4KKyAqCisgKiBUaGUgLmJhbGlnbidz
IGFyZSBmb3IgcGVyZm9ybWFuY2UsIGJ1dCB0aGV5IGNhdXNlIHRoZSBSRVRz
IHRvIGJlIGluIHVuc2FmZQorICogcG9zaXRpb25zIHdpdGggcmVzcGVjdCB0
byBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uLiAgVGhlIC5za2lwcyBhcmUg
dG8KKyAqIG1vdmUgdGhlIFJFVHMgaW50byBJVFMtc2FmZSBwb3NpdGlvbnMs
IHJhdGhlciB0aGFuIHVzaW5nIHRoZSBzbG93cGF0aAorICogdGhyb3VnaCBf
X3g4Nl9yZXR1cm5fdGh1bmsuCiAgKgogICogVGhlICJzaG9ydCIgc2VxdWVu
Y2UgKDUgYW5kIDUpIGlzIGZvciBDUFVzIHByaW9yIHRvIEFsZGVyIExha2Ug
LyBTYXBwaGlyZQogICogUmFwaWRzIChpLmUuIENvcmVzIHByaW9yIHRvIEdv
bGRlbiBDb3ZlIGFuZC9vciBHcmFjZW1vbnQpLgpAQCAtNjgsMTIgKzczLDE0
IEBAIEVOVFJZKGNsZWFyX2JoYl9sb29wcykKICAgICAgICAgam1wICAgICA1
ZgogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAgICAg
IC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtICguTHIxIC0gMWYp
LCAweGNjCiAxOiAgICAgIGNhbGwgICAgMmYKLSAgICAgICAgcmV0CisuTHIx
OiAgIHJldAogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0Cisg
ICAgICAgIC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtIDE4IC8q
ICguTHIyIC0gMmYpIGJ1dCBDbGFuZyBJQVMgZG9lc24ndCBsaWtlIHRoaXMg
Ki8sIDB4Y2MKIDI6ICAgICAgQUxURVJOQVRJVkUgIm1vdiAkNSwgJWVheCIs
ICJtb3YgJDcsICVlYXgiLCBYODZfU1BFQ19CSEJfTE9PUFNfTE9ORwogCiAz
OiAgICAgIGptcCAgICAgNGYKQEAgLTg1LDcgKzkyLDcgQEAgRU5UUlkoY2xl
YXJfYmhiX2xvb3BzKQogICAgICAgICBzdWIgICAgICQxLCAlZWN4CiAgICAg
ICAgIGpueiAgICAgMWIKIAotICAgICAgICByZXQKKy5McjI6ICAgcmV0CiA1
OgogICAgICAgICAvKgogICAgICAgICAgKiBUaGUgSW50ZWwgc2VxdWVuY2Ug
aGFzIGFuIExGRU5DRSBoZXJlLiAgVGhlIHB1cnBvc2UgaXMgdG8gZW5zdXJl
Cg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-05.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-05.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3N0dWJzOiBJbnRyb2R1Y2UgcGxhY2VfcmV0KCkg
dG8gYWJzdHJhY3QgYXdheSByYXcgMHhjMydzCgpUaGUgSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5z
IHRoYXQgaW5kaXJlY3QKYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUg
dW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0IGhhbGYgb2YgYSBjYWNoZWxpbmUu
ClRoaXMgbWVhbnMgaXQncyBub3Qgc2FmZSBmb3IgbG9naWMgdXNpbmcgdGhl
IHN0dWJzIHRvIHdyaXRlIHJhdyAweGMzJ3MuCgpJbnRyb2R1Y2UgcGxhY2Vf
cmV0KCkgd2hpY2gsIGZvciBub3csIHdyaXRlcyBhIHJhdyAweGMzIGJ1dCB3
aWxsIGNvbnRhaW4KYWRkaXRpb25hbCBsb2dpYyB3aGVuIHJldHVybiB0aHVu
a3MgYXJlIGluIHVzZS4KCnN0dWJfc2VsZnRlc3QoKSBkb2Vzbid0IHN0cmlj
dGx5IG5lZWQgdG8gYmUgY29udmVydGVkIGFzIHRoZXkgb25seSBydW4gb24K
Ym9vdCwgYnV0IGRvaW5nIHNvIGdldHMgdXMgYSBwYXJ0aWFsIHRlc3Qgb2Yg
cGxhY2VfcmV0KCkgdG9vLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ2OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQt
b2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu
Y29tPgpSZXZpZXdlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvdG9vbHMvdGVzdHMveDg2X2Vt
dWxhdG9yL3g4Ni1lbXVsYXRlLmggYi90b29scy90ZXN0cy94ODZfZW11bGF0
b3IveDg2LWVtdWxhdGUuaAppbmRleCA1ODc2MGYwOTZkM2UuLjY1YWU5NWU2
MjRlNiAxMDA2NDQKLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKKysrIGIvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKQEAgLTY3LDYgKzY3LDEyIEBACiAKICNkZWZpbmUgaXNf
Y2Fub25pY2FsX2FkZHJlc3MoeCkgKCgoaW50NjRfdCkoeCkgPj4gNDcpID09
ICgoaW50NjRfdCkoeCkgPj4gNjMpKQogCitzdGF0aWMgaW5saW5lIHZvaWQg
KnBsYWNlX3JldCh2b2lkICpwdHIpCit7CisgICAgKih1aW50OF90ICopcHRy
ID0gMHhjMzsKKyAgICByZXR1cm4gcHRyICsgMTsKK30KKwogZXh0ZXJuIHVp
bnQzMl90IG14Y3NyX21hc2s7CiBleHRlcm4gc3RydWN0IGNwdV9wb2xpY3kg
Y3A7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hl
bi9hcmNoL3g4Ni9NYWtlZmlsZQppbmRleCA2YTA3MGE4Y2Y4ZGEuLjg4MjQw
OGNjYWY5YSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisr
KyBiL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtMTAsOSArMTAsNyBAQCBv
YmotJChDT05GSUdfWEVOT1BST0YpICs9IG9wcm9maWxlLwogb2JqLSQoQ09O
RklHX1BWKSArPSBwdi8KIG9iai15ICs9IHg4Nl82NC8KIAotYWx0ZXJuYXRp
dmUteSA6PSBhbHRlcm5hdGl2ZS5pbml0Lm8KLWFsdGVybmF0aXZlLSQoQ09O
RklHX0xJVkVQQVRDSCkgOj0KLW9iai1iaW4teSArPSAkKGFsdGVybmF0aXZl
LXkpCitvYmoteSArPSBhbHRlcm5hdGl2ZS5vCiBvYmoteSArPSBhcGljLm8K
IG9iai15ICs9IGJoYi10aHVuay5vCiBvYmoteSArPSBiaXRvcHMubwpAQCAt
NDAsNyArMzgsNyBAQCBvYmoteSArPSBoeXBlcmNhbGwubwogb2JqLXkgKz0g
aTM4Ny5vCiBvYmoteSArPSBpODI1OS5vCiBvYmoteSArPSBpb19hcGljLm8K
LW9iai0kKENPTkZJR19MSVZFUEFUQ0gpICs9IGFsdGVybmF0aXZlLm8gbGl2
ZXBhdGNoLm8KK29iai0kKENPTkZJR19MSVZFUEFUQ0gpICs9IGxpdmVwYXRj
aC5vCiBvYmoteSArPSBtc2kubwogb2JqLXkgKz0gbXNyLm8KIG9iai0kKENP
TkZJR19JTkRJUkVDVF9USFVOSykgKz0gaW5kaXJlY3QtdGh1bmsubwpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJj
aC94ODYvYWx0ZXJuYXRpdmUuYwppbmRleCA2ZWVlNmU1MDFhZDkuLjg4MDgy
ZjY4YTk4MiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZl
LmMKKysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTE0OSw2
ICsxNDksMjAgQEAgdm9pZCBpbml0X29yX2xpdmVwYXRjaCBhZGRfbm9wcyh2
b2lkICppbnNucywgdW5zaWduZWQgaW50IGxlbikKICAgICB9CiB9CiAKKy8q
CisgKiBQbGFjZSBhIHJldHVybiBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGlu
IHRoZSB3cml0YWJsZSBhbGlhcyBvZiBhIHN0dWIuCisgKgorICogUmV0dXJu
cyB0aGUgbmV4dCBwb3NpdGlvbiB0byB3cml0ZSBpbnRvIHRoZSBzdHViLgor
ICovCit2b2lkICpwbGFjZV9yZXQodm9pZCAqcHRyKQoreworICAgIHVpbnQ4
X3QgKnAgPSBwdHI7CisKKyAgICAqcCsrID0gMHhjMzsKKworICAgIHJldHVy
biBwOworfQorCiAvKgogICogdGV4dF9wb2tlIC0gVXBkYXRlIGluc3RydWN0
aW9ucyBvbiBhIGxpdmUga2VybmVsIG9yIG5vbi1leGVjdXRlZCBjb2RlLgog
ICogQGFkZHI6IGFkZHJlc3MgdG8gbW9kaWZ5CmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvZXh0YWJsZS5jIGIveGVuL2FyY2gveDg2L2V4dGFibGUuYwpp
bmRleCBmMDVjMTZkZWY2OGIuLmFkZmQ0MzlkM2E1MCAxMDA2NDQKLS0tIGEv
eGVuL2FyY2gveDg2L2V4dGFibGUuYworKysgYi94ZW4vYXJjaC94ODYvZXh0
YWJsZS5jCkBAIC0xMzUsMjAgKzEzNSwyMCBAQCBzZWFyY2hfZXhjZXB0aW9u
X3RhYmxlKGNvbnN0IHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzLCB1bnNp
Z25lZCBsb25nICpzdHViX3JhKQogaW50IF9faW5pdCBjZl9jaGVjayBzdHVi
X3NlbGZ0ZXN0KHZvaWQpCiB7CiAgICAgc3RhdGljIGNvbnN0IHN0cnVjdCB7
Ci0gICAgICAgIHVpbnQ4X3Qgb3BjWzhdOworICAgICAgICB1aW50OF90IG9w
Y1s3XTsKICAgICAgICAgdWludDY0X3QgcmF4OwogICAgICAgICB1bmlvbiBz
dHViX2V4Y2VwdGlvbl90b2tlbiByZXM7CiAgICAgfSB0ZXN0c1tdIF9faW5p
dGNvbnN0ID0gewogI2RlZmluZSBlbmRicjY0IDB4ZjMsIDB4MGYsIDB4MWUs
IDB4ZmEKLSAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDBmLCAweGI5
LCAweGMzLCAweGMzIH0sIC8qIHVkMSAqLworICAgICAgICB7IC5vcGMgPSB7
IGVuZGJyNjQsIDB4MGYsIDB4YjksIDB4OTAgfSwgLyogdWQxICovCiAgICAg
ICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0gVFJBUF9pbnZhbGlkX29wIH0s
Ci0gICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwgMHg5MCwgMHgwMiwgMHgw
MCwgMHhjMyB9LCAvKiBub3A7IGFkZCAoJXJheCksJWFsICovCisgICAgICAg
IHsgLm9wYyA9IHsgZW5kYnI2NCwgMHg5MCwgMHgwMiwgMHgwMCB9LCAvKiBu
b3A7IGFkZCAoJXJheCksJWFsICovCiAgICAgICAgICAgLnJheCA9IDB4MDEy
MzQ1Njc4OWFiY2RlZiwKICAgICAgICAgICAucmVzLmZpZWxkcy50cmFwbnIg
PSBUUkFQX2dwX2ZhdWx0IH0sCi0gICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2
NCwgMHgwMiwgMHgwNCwgMHgwNCwgMHhjMyB9LCAvKiBhZGQgKCVyc3AsJXJh
eCksJWFsICovCisgICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwgMHgwMiwg
MHgwNCwgMHgwNCB9LCAvKiBhZGQgKCVyc3AsJXJheCksJWFsICovCiAgICAg
ICAgICAgLnJheCA9IDB4ZmVkY2JhOTg3NjU0MzIxMCwKICAgICAgICAgICAu
cmVzLmZpZWxkcy50cmFwbnIgPSBUUkFQX3N0YWNrX2Vycm9yIH0sCi0gICAg
ICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwgMHhjYywgMHhjMywgMHhjMywgMHhj
MyB9LCAvKiBpbnQzICovCisgICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwg
MHhjYywgMHg5MCwgMHg5MCB9LCAvKiBpbnQzICovCiAgICAgICAgICAgLnJl
cy5maWVsZHMudHJhcG5yID0gVFJBUF9pbnQzIH0sCiAjdW5kZWYgZW5kYnI2
NAogICAgIH07CkBAIC0xNjcsNiArMTY3LDcgQEAgaW50IF9faW5pdCBjZl9j
aGVjayBzdHViX3NlbGZ0ZXN0KHZvaWQpCiAKICAgICAgICAgbWVtc2V0KHB0
ciwgMHhjYywgU1RVQl9CVUZfU0laRSAvIDIpOwogICAgICAgICBtZW1jcHko
cHRyLCB0ZXN0c1tpXS5vcGMsIEFSUkFZX1NJWkUodGVzdHNbaV0ub3BjKSk7
CisgICAgICAgIHBsYWNlX3JldChwdHIgKyBBUlJBWV9TSVpFKHRlc3RzW2ld
Lm9wYykpOwogICAgICAgICB1bm1hcF9kb21haW5fcGFnZShwdHIpOwogCiAg
ICAgICAgIGFzbSB2b2xhdGlsZSAoICJJTkRJUkVDVF9DQUxMICVbc3RiXVxu
IgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYWx0ZXJuYXRp
dmUuaAppbmRleCAzODhlNTk1Nzg2ZTAuLjI4ZTY5ZTk4OGFjMCAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmgK
KysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmgK
QEAgLTMwLDYgKzMwLDggQEAgc3RydWN0IF9fcGFja2VkIGFsdF9pbnN0ciB7
CiAjZGVmaW5lIEFMVF9SRVBMX1BUUihhKSAgICAgX19BTFRfUFRSKGEsIHJl
cGxfb2Zmc2V0KQogCiBleHRlcm4gdm9pZCBhZGRfbm9wcyh2b2lkICppbnNu
cywgdW5zaWduZWQgaW50IGxlbik7Cit2b2lkICpwbGFjZV9yZXQodm9pZCAq
cHRyKTsKKwogLyogU2ltaWxhciB0byBhbHRlcm5hdGl2ZV9pbnN0cnVjdGlv
bnMgZXhjZXB0IGl0IGNhbiBiZSBydW4gd2l0aCBJUlFzIGVuYWJsZWQuICov
CiBleHRlcm4gdm9pZCBhcHBseV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9p
bnN0ciAqc3RhcnQsIHN0cnVjdCBhbHRfaW5zdHIgKmVuZCk7CiBleHRlcm4g
dm9pZCBhbHRlcm5hdGl2ZV9pbnN0cnVjdGlvbnModm9pZCk7CmRpZmYgLS1n
aXQgYS94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMgYi94ZW4vYXJj
aC94ODYvcHYvZW11bC1wcml2LW9wLmMKaW5kZXggZjIxNmMyNjQxMjA1Li4y
OGVhN2NjNTgwYTkgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9wdi9lbXVs
LXByaXYtb3AuYworKysgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9w
LmMKQEAgLTg4LDcgKzg4LDYgQEAgc3RhdGljIGlvX2VtdWxfc3R1Yl90ICpp
b19lbXVsX3N0dWJfc2V0dXAoc3RydWN0IHByaXZfb3BfY3R4dCAqY3R4dCwg
dTggb3Bjb2RlLAogICAgICAgICAweDQxLCAweDVjLCAvKiBwb3AgJXIxMiAg
Ki8KICAgICAgICAgMHg1ZCwgICAgICAgLyogcG9wICVyYnAgICovCiAgICAg
ICAgIDB4NWIsICAgICAgIC8qIHBvcCAlcmJ4ICAqLwotICAgICAgICAweGMz
LCAgICAgICAvKiByZXQgICAgICAgKi8KICAgICB9OwogCiAgICAgY29uc3Qg
c3RydWN0IHN0dWJzICp0aGlzX3N0dWJzID0gJnRoaXNfY3B1KHN0dWJzKTsK
QEAgLTEzOCwxMSArMTM3LDEzIEBAIHN0YXRpYyBpb19lbXVsX3N0dWJfdCAq
aW9fZW11bF9zdHViX3NldHVwKHN0cnVjdCBwcml2X29wX2N0eHQgKmN0eHQs
IHU4IG9wY29kZSwKIAogICAgIEFQUEVORF9DQUxMKHNhdmVfZ3Vlc3RfZ3By
cyk7CiAgICAgQVBQRU5EX0JVRkYoZXBpbG9ndWUpOworICAgIHAgPSBwbGFj
ZV9yZXQocCk7CiAKICAgICAvKiBCdWlsZC10aW1lIGJlc3QgZWZmb3J0IGF0
dGVtcHQgdG8gY2F0Y2ggcHJvYmxlbXMuICovCiAgICAgQlVJTERfQlVHX09O
KFNUVUJfQlVGX1NJWkUgLyAyIDwKICAgICAgICAgICAgICAgICAgKHNpemVv
Zihwcm9sb2d1ZSkgKyBzaXplb2YoZXBpbG9ndWUpICsgMTAgLyogMnggY2Fs
bCAqLyArCi0gICAgICAgICAgICAgICAgICBNQVgoMyAvKiBkZWZhdWx0IHN0
dWIgKi8sIElPRU1VTF9RVUlSS19TVFVCX0JZVEVTKSkpOworICAgICAgICAg
ICAgICAgICAgTUFYKDMgLyogZGVmYXVsdCBzdHViICovLCBJT0VNVUxfUVVJ
UktfU1RVQl9CWVRFUykgKworICAgICAgICAgICAgICAgICAgMSAvKiByZXQg
Ki8pKTsKICAgICAvKiBSdW50aW1lIGNvbmZpcm1hdGlvbiB0aGF0IHdlIGhh
dmVuJ3QgY2xvYmJlcmVkIGFuIGFkamFjZW50IHN0dWIuICovCiAgICAgQlVH
X09OKFNUVUJfQlVGX1NJWkUgLyAyIDwgKHAgLSBjdHh0LT5pb19lbXVsX3N0
dWIpKTsKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRl
L3g4Nl9lbXVsYXRlLmMgYi94ZW4vYXJjaC94ODYveDg2X2VtdWxhdGUveDg2
X2VtdWxhdGUuYwppbmRleCA5OTU2NzBjYmM4ZTkuLmI1ZWNhMTM0MTBjZCAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVs
YXRlLmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVs
YXRlLmMKQEAgLTE1MzMsMzYgKzE1MzMsNDIgQEAgc3RhdGljIGlubGluZSBi
b29sIGZwdV9jaGVja193cml0ZSh2b2lkKQogCiAjZGVmaW5lIGVtdWxhdGVf
ZnB1X2luc25fbWVtZHN0KG9wYywgZXh0LCBhcmcpICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisg
ICAgdm9pZCAqX3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgLyogTW9kUk06IG1v
ZD0wLCByZWc9ZXh0LCBybT0wLCBpLmUuIGEgKCVyYXgpIG9wZXJhbmQgKi8g
ICAgICAgICAgICBcCiAgICAgaW5zbl9ieXRlcyA9IDI7ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0g
ICAgbWVtY3B5KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWlu
dDhfdFtdKXsgb3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsg
ICAgICAgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9w
YywgKChleHQpICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisg
ICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIo
IiIsICIiLCAiK20iIChhcmcpIDogImEiICgmKGFyZykpKTsgICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9
IHdoaWxlICgwKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fbWVtc3Jj
KG9wYywgZXh0LCBhcmcpICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBk
byB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBn
ZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgLyogTW9kUk06IG1vZD0wLCByZWc9ZXh0LCBy
bT0wLCBpLmUuIGEgKCVyYXgpIG9wZXJhbmQgKi8gICAgICAgICAgICBcCi0g
ICAgbWVtY3B5KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWlu
dDhfdFtdKXsgb3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsg
ICAgICAgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9w
YywgKChleHQpICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisg
ICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIo
IiIsICIiLCAiPW0iIChkdW1teSkgOiAibSIgKGFyZyksICJhIiAoJihhcmcp
KSk7ICAgICAgICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9
IHdoaWxlICgwKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fc3R1Yihi
eXRlcy4uLikgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBk
byB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBn
ZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgdW5zaWduZWQgaW50IG5yXyA9IHNpemVvZigo
dWludDhfdFtdKXsgYnl0ZXMgfSk7ICAgICAgICAgICAgICAgICAgICBcCi0g
ICAgbWVtY3B5KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVz
LCAweGMzIH0pLCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAo
KHVpbnQ4X3RbXSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAg
ICAgICAgICAgICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAg
ICAgaW52b2tlX3N0dWIoIiIsICIiLCAiPW0iIChkdW1teSkgOiAiaSIgKDAp
KTsgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgcHV0X3N0dWIoc3R1
Yik7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiB9IHdoaWxlICgwKQogCiAjZGVmaW5lIGVtdWxhdGVf
ZnB1X2luc25fc3R1Yl9lZmxhZ3MoYnl0ZXMuLi4pICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisg
ICAgdm9pZCAqX3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgdW5zaWduZWQgaW50
IG5yXyA9IHNpemVvZigodWludDhfdFtdKXsgYnl0ZXMgfSk7ICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgdW5zaWduZWQgbG9uZyB0bXBfOyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0g
ICAgbWVtY3B5KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVz
LCAweGMzIH0pLCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAo
KHVpbnQ4X3RbXSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAg
ICAgICAgICAgICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAg
ICAgaW52b2tlX3N0dWIoX1BSRV9FRkxBR1MoIltlZmxhZ3NdIiwgIlttYXNr
XSIsICJbdG1wXSIpLCAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAg
X1BPU1RfRUZMQUdTKCJbZWZsYWdzXSIsICJbbWFza10iLCAiW3RtcF0iKSwg
ICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgW2VmbGFnc10gIitnIiAo
X3JlZ3MuZWZsYWdzKSwgW3RtcF0gIj0mciIgKHRtcF8pICAgICAgICBcCkBA
IC0zODUyLDcgKzM4NTgsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgc3Ri
WzNdID0gMHg5MTsKICAgICAgICAgc3RiWzRdID0gZXZleC5vcG1zayA8PCAz
OwogICAgICAgICBpbnNuX2J5dGVzID0gNTsKLSAgICAgICAgc3RiWzVdID0g
MHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZzdGJbNV0pOwogCiAgICAgICAg
IGludm9rZV9zdHViKCIiLCAiIiwgIittIiAob3BfbWFzaykgOiAiYSIgKCZv
cF9tYXNrKSk7CiAKQEAgLTY3NTEsNyArNjc1Nyw3IEBAIHg4Nl9lbXVsYXRl
KAogICAgICAgICAgICAgZXZleC5sciA9IDA7CiAgICAgICAgIG9wY1sxXSA9
IChtb2RybSAmIDB4MzgpIHwgMHhjMDsKICAgICAgICAgaW5zbl9ieXRlcyA9
IEVWRVhfUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
RVZFWChvcGMsIGV2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIs
ICI9ZyIgKGR1bW15KSA6ICJhIiAoc3JjLnZhbCkpOwpAQCAtNjgxNiw3ICs2
ODIyLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAgICBpbnNuX2J5dGVz
ID0gUEZYX0JZVEVTICsgMjsKICAgICAgICAgICAgIGNvcHlfUkVYX1ZFWChv
cGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIH0KLSAgICAgICAgb3Bj
WzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAg
ICAgICAgIGVhLnJlZyA9IGRlY29kZV9ncHIoJl9yZWdzLCBtb2RybV9yZWcp
OwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9YSIgKCplYS5yZWcp
IDogImMiIChtbXZhbHApLCAibSIgKCptbXZhbHApKTsKQEAgLTY4ODQsNyAr
Njg5MCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAgaW5zbl9ieXRl
cyA9IFBGWF9CWVRFUyArIDI7CiAgICAgICAgICAgICBjb3B5X1JFWF9WRVgo
b3BjLCByZXhfcHJlZml4LCB2ZXgpOwogICAgICAgICB9Ci0gICAgICAgIG9w
Y1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAog
ICAgICAgICBfcmVncy5lZmxhZ3MgJj0gfkVGTEFHU19NQVNLOwogICAgICAg
ICBpbnZva2Vfc3R1YigiIiwKQEAgLTcxMTMsNyArNzExOSw3IEBAIHg4Nl9l
bXVsYXRlKAogICAgICAgICBvcGNbMV0gPSBtb2RybSAmIDB4Yzc7CiAgICAg
ICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwogICAgIHNpbWRfMGZf
dG9fZ3ByOgotICAgICAgICBvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10g
PSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1tpbnNuX2J5dGVzIC0g
UEZYX0JZVEVTXSk7CiAKICAgICAgICAgZ2VuZXJhdGVfZXhjZXB0aW9uX2lm
KGVhLnR5cGUgIT0gT1BfUkVHLCBFWENfVUQpOwogCkBAIC03NTEwLDcgKzc1
MTYsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgIHZleC53ID0gMDsK
ICAgICAgICAgb3BjWzFdID0gbW9kcm0gJiAweDM4OwogICAgICAgICBpbnNu
X2J5dGVzID0gUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhj
MzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNv
cHlfUkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIGlu
dm9rZV9zdHViKCIiLCAiIiwgIittIiAoc3JjLnZhbCkgOiAiYSIgKCZzcmMu
dmFsKSk7CkBAIC03NTM4LDcgKzc1NDQsNyBAQCB4ODZfZW11bGF0ZSgKICAg
ICAgICAgICAgIGV2ZXgudyA9IDA7CiAgICAgICAgIG9wY1sxXSA9IG1vZHJt
ICYgMHgzODsKICAgICAgICAgaW5zbl9ieXRlcyA9IEVWRVhfUEZYX0JZVEVT
ICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2Vf
cmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlfRVZFWChvcGMsIGV2ZXgp
OwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKHNyYy52YWwp
IDogImEiICgmc3JjLnZhbCkpOwpAQCAtNzczMyw3ICs3NzM5LDcgQEAgeDg2
X2VtdWxhdGUoCiAjZW5kaWYgLyogWDg2RU1VTF9OT19TSU1EICovCiAKICAg
ICBzaW1kXzBmX3JlZ19vbmx5OgotICAgICAgICBvcGNbaW5zbl9ieXRlcyAt
IFBGWF9CWVRFU10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1tp
bnNuX2J5dGVzIC0gUEZYX0JZVEVTXSk7CiAKICAgICAgICAgY29weV9SRVhf
VkVYKG9wYywgcmV4X3ByZWZpeCwgdmV4KTsKICAgICAgICAgaW52b2tlX3N0
dWIoIiIsICIiLCBbZHVtbXlfb3V0XSAiPWciIChkdW1teSkgOiBbZHVtbXlf
aW5dICJpIiAoMCkgKTsKQEAgLTgwNTgsNyArODA2NCw3IEBAIHg4Nl9lbXVs
YXRlKAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0KCkgKQogICAgICAgICAg
ICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2RybSAmIDB4Zjg7
Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgm
b3BjWzJdKTsKIAogICAgICAgICBjb3B5X1ZFWChvcGMsIHZleCk7CiAgICAg
ICAgIGVhLnJlZyA9IGRlY29kZV9ncHIoJl9yZWdzLCBtb2RybV9ybSk7CkBA
IC04MTAxLDcgKzgxMDcsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgaWYg
KCAhbW9kZV82NGJpdCgpICkKICAgICAgICAgICAgIHZleC53ID0gMDsKICAg
ICAgICAgb3BjWzFdID0gbW9kcm0gJiAweGM3OwotICAgICAgICBvcGNbMl0g
PSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAg
ICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1Yigi
IiwgIiIsICI9YSIgKGRzdC52YWwpIDogW2R1bW15XSAiaSIgKDApKTsKQEAg
LTgxMzEsNyArODEzNyw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBvcGMg
PSBpbml0X3ByZWZpeGVzKHN0dWIpOwogICAgICAgICBvcGNbMF0gPSBiOwog
ICAgICAgICBvcGNbMV0gPSBtb2RybTsKLSAgICAgICAgb3BjWzJdID0gMHhj
MzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNv
cHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAgX3JlZ3MuZWZsYWdzICY9IH5F
RkxBR1NfTUFTSzsKQEAgLTkwMjcsNyArOTAzMyw3IEBAIHg4Nl9lbXVsYXRl
KAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0KCkgKQogICAgICAgICAgICAg
dmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2RybSAmIDB4Yzc7Ci0g
ICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzJdKTsKIAogICAgICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4
LCB2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9YSIgKGVh
LnZhbCkgOiBbZHVtbXldICJpIiAoMCkpOwpAQCAtOTE0NSw3ICs5MTUxLDcg
QEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAgICBvcGNbMV0gJj0gMHgzODsK
ICAgICAgICAgfQogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsg
MjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0
KCZvcGNbMl0pOwogICAgICAgICBpZiAoIHZleC5vcGN4ID09IHZleF9ub25l
ICkKICAgICAgICAgewogICAgICAgICAgICAgLyogQ292ZXIgZm9yIGV4dHJh
IHByZWZpeCBieXRlLiAqLwpAQCAtOTQyNCw3ICs5NDMwLDcgQEAgeDg2X2Vt
dWxhdGUoCiAgICAgICAgIHB2ZXgtPmIgPSAhbW9kZV82NGJpdCgpIHx8ICh2
ZXgucmVnID4+IDMpOwogICAgICAgICBvcGNbMV0gPSAweGMwIHwgKH52ZXgu
cmVnICYgNyk7CiAgICAgICAgIHB2ZXgtPnJlZyA9IDB4ZjsKLSAgICAgICAg
b3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwog
CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1hIiAoZWEudmFsKSA6
IFtkdW1teV0gImkiICgwKSk7CiAgICAgICAgIHB1dF9zdHViKHN0dWIpOwpA
QCAtOTY4NCw3ICs5NjkwLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAg
ICBldmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2RybSAmIDB4Zjg7
CiAgICAgICAgIGluc25fYnl0ZXMgPSBFVkVYX1BGWF9CWVRFUyArIDI7Ci0g
ICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzJdKTsKIAogICAgICAgICBjb3B5X0VWRVgob3BjLCBldmV4KTsKICAgICAg
ICAgaW52b2tlX3N0dWIoIiIsICIiLCAiPWciIChkdW1teSkgOiAiYSIgKHNy
Yy52YWwpKTsKQEAgLTk3ODMsNyArOTc4OSw3IEBAIHg4Nl9lbXVsYXRlKAog
ICAgICAgICBwdmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJt
X3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHB2ZXgtPnJlZyA9IDB4ZjsKLSAg
ICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNb
Ml0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1tIiAoKm1t
dmFscCkgOiAiYSIgKG1tdmFscCkpOwogCkBAIC05ODUzLDcgKzk4NTksNyBA
QCB4ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+YiA9IDE7CiAgICAgICAg
IG9wY1sxXSA9IChtb2RybV9yZWcgJiA3KSA8PCAzOwogICAgICAgICBwdmV4
LT5yZWcgPSAweGY7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAg
IHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1Yigi
IiwgIiIsICIrbSIgKCptbXZhbHApIDogImEiIChtbXZhbHApKTsKIApAQCAt
OTkwOSw3ICs5OTE1LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHBldmV4
LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJtX3JlZyAmIDcpIDw8
IDM7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0gICAgICAgIG9wY1syXSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAg
ICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKCptbXZhbHApIDogImEiICht
bXZhbHApKTsKIApAQCAtOTk3NCw3ICs5OTgwLDcgQEAgeDg2X2VtdWxhdGUo
CiAgICAgICAgIHBldmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1v
ZHJtX3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0g
ICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKCpt
bXZhbHApIDogImEiIChtbXZhbHApKTsKIApAQCAtOTk4OCw3ICs5OTk0LDcg
QEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIG9wY1syXSA9IDB4OTA7CiAgICAg
ICAgIC8qIFVzZSAoJXJheCkgYXMgc291cmNlLiAqLwogICAgICAgICBvcGNb
M10gPSBldmV4Lm9wbXNrIDw8IDM7Ci0gICAgICAgIG9wY1s0XSA9IDB4YzM7
CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzRdKTsKIAogICAgICAgICBpbnZv
a2Vfc3R1YigiIiwgIiIsICIrbSIgKG9wX21hc2spIDogImEiICgmb3BfbWFz
aykpOwogICAgICAgICBwdXRfc3R1YihzdHViKTsKQEAgLTEwMDgyLDcgKzEw
MDg4LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHBldmV4LT5iID0gMTsK
ICAgICAgICAgb3BjWzFdID0gKG1vZHJtX3JlZyAmIDcpIDw8IDM7CiAgICAg
ICAgIHBldmV4LT5SWCA9IDE7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vf
c3R1YigiIiwgIiIsICI9bSIgKCptbXZhbHApIDogImEiIChtbXZhbHApKTsK
IApAQCAtMTAxNjAsNyArMTAxNjYsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAg
ICAgb3BjWzJdID0gMHg5MDsKICAgICAgICAgLyogVXNlICglcmF4KSBhcyBz
b3VyY2UuICovCiAgICAgICAgIG9wY1szXSA9IGV2ZXgub3Btc2sgPDwgMzsK
LSAgICAgICAgb3BjWzRdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbNF0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAo
b3BfbWFzaykgOiAiYSIgKCZvcF9tYXNrKSk7CiAgICAgICAgIHB1dF9zdHVi
KHN0dWIpOwpAQCAtMTAyMjksNyArMTAyMzUsNyBAQCB4ODZfZW11bGF0ZSgK
ICAgICAgICAgcGV2ZXgtPnIgPSAhbW9kZV82NGJpdCgpIHx8ICEoc3RhdGUt
PnNpYl9pbmRleCAmIDB4MDgpOwogICAgICAgICBwZXZleC0+UiA9ICFtb2Rl
XzY0Yml0KCkgfHwgIShzdGF0ZS0+c2liX2luZGV4ICYgMHgxMCk7CiAgICAg
ICAgIHBldmV4LT5SWCA9IDE7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vf
c3R1YigiIiwgIiIsICI9bSIgKGluZGV4KSA6ICJhIiAoJmluZGV4KSk7CiAg
ICAgICAgIHB1dF9zdHViKHN0dWIpOwpAQCAtMTA0MDQsNyArMTA0MTAsNyBA
QCB4ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+cmVnID0gMHhmOyAvKiBy
QVggKi8KICAgICAgICAgYnVmWzNdID0gYjsKICAgICAgICAgYnVmWzRdID0g
MHgwOTsgLyogcmVnPXJDWCByL209KCVyQ1gpICovCi0gICAgICAgIGJ1Zls1
XSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzVdKTsKIAogICAg
ICAgICBzcmMucmVnID0gZGVjb2RlX3ZleF9ncHIodmV4LnJlZywgJl9yZWdz
LCBjdHh0KTsKICAgICAgICAgZW11bGF0ZV9zdHViKFtkc3RdICI9JmMiIChk
c3QudmFsKSwgIltkc3RdIiAoJnNyYy52YWwpLCAiYSIgKCpzcmMucmVnKSk7
CkBAIC0xMDQzOCw3ICsxMDQ0NCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAg
ICBwdmV4LT5yZWcgPSAweGY7IC8qIHJBWCAqLwogICAgICAgICBidWZbM10g
PSBiOwogICAgICAgICBidWZbNF0gPSAobW9kcm0gJiAweDM4KSB8IDB4MDE7
IC8qIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgIGRzdC5yZWcg
PSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3JlZ3MsIGN0eHQpOwogICAg
ICAgICBlbXVsYXRlX3N0dWIoIj0mYSIgKGRzdC52YWwpLCAiYyIgKCZzcmMu
dmFsKSk7CkBAIC0xMDY3MCw3ICsxMDY3Niw3IEBAIHg4Nl9lbXVsYXRlKAog
ICAgICAgICAgICAgZXZleC53ID0gdmV4LncgPSAwOwogICAgICAgICBvcGNb
MV0gPSBtb2RybSAmIDB4Mzg7CiAgICAgICAgIG9wY1syXSA9IGltbTE7Ci0g
ICAgICAgIG9wY1szXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzNdKTsKICAgICAgICAgaWYgKCB2ZXgub3BjeCA9PSB2ZXhfbm9uZSApCiAg
ICAgICAgIHsKICAgICAgICAgICAgIC8qIENvdmVyIGZvciBleHRyYSBwcmVm
aXggYnl0ZS4gKi8KQEAgLTEwODM3LDcgKzEwODQzLDcgQEAgeDg2X2VtdWxh
dGUoCiAgICAgICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMzsK
ICAgICAgICAgICAgIGNvcHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAgfQot
ICAgICAgICBvcGNbM10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9w
Y1szXSk7CiAKICAgICAgICAgLyogTGF0Y2ggTVhDU1IgLSB3ZSBtYXkgbmVl
ZCB0byByZXN0b3JlIGl0IGJlbG93LiAqLwogICAgICAgICBpbnZva2Vfc3R1
Yigic3RteGNzciAlW214Y3NyXSIsICIiLApAQCAtMTEwNjUsNyArMTEwNzEs
NyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgfQogICAgICAgICBvcGNbMl0g
PSBpbW0xOwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMzsK
LSAgICAgICAgb3BjWzNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbM10pOwogICAgICAgICBpZiAoIHZleC5vcGN4ID09IHZleF9ub25lICkK
ICAgICAgICAgewogICAgICAgICAgICAgLyogQ292ZXIgZm9yIGV4dHJhIHBy
ZWZpeCBieXRlLiAqLwpAQCAtMTEyMjUsNyArMTEyMzEsNyBAQCB4ODZfZW11
bGF0ZSgKICAgICAgICAgcHhvcC0+cmVnID0gMHhmOyAvKiByQVggKi8KICAg
ICAgICAgYnVmWzNdID0gYjsKICAgICAgICAgYnVmWzRdID0gKG1vZHJtICYg
MHgzOCkgfCAweDAxOyAvKiByL209KCVyQ1gpICovCi0gICAgICAgIGJ1Zls1
XSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzVdKTsKIAogICAg
ICAgICBkc3QucmVnID0gZGVjb2RlX3ZleF9ncHIodmV4LnJlZywgJl9yZWdz
LCBjdHh0KTsKICAgICAgICAgZW11bGF0ZV9zdHViKFtkc3RdICI9JmEiIChk
c3QudmFsKSwgImMiICgmc3JjLnZhbCkpOwpAQCAtMTEzMzQsNyArMTEzNDAs
NyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgYnVmWzNdID0gYjsKICAgICAg
ICAgYnVmWzRdID0gMHgwOTsgLyogcmVnPXJDWCByL209KCVyQ1gpICovCiAg
ICAgICAgICoodWludDMyX3QgKikoYnVmICsgNSkgPSBpbW0xOwotICAgICAg
ICBidWZbOV0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls5XSk7
CiAKICAgICAgICAgZW11bGF0ZV9zdHViKFtkc3RdICI9JmMiIChkc3QudmFs
KSwgIltkc3RdIiAoJnNyYy52YWwpKTsKIApAQCAtMTE0MDEsMTIgKzExNDA3
LDEyIEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAgQlVHKCk7CiAgICAg
ICAgIGlmICggZXZleF9lbmNvZGVkKCkgKQogICAgICAgICB7Ci0gICAgICAg
ICAgICBvcGNbaW5zbl9ieXRlcyAtIEVWRVhfUEZYX0JZVEVTXSA9IDB4YzM7
CisgICAgICAgICAgICBwbGFjZV9yZXQoJm9wY1tpbnNuX2J5dGVzIC0gRVZF
WF9QRlhfQllURVNdKTsKICAgICAgICAgICAgIGNvcHlfRVZFWChvcGMsIGV2
ZXgpOwogICAgICAgICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgewotICAg
ICAgICAgICAgb3BjW2luc25fYnl0ZXMgLSBQRlhfQllURVNdID0gMHhjMzsK
KyAgICAgICAgICAgIHBsYWNlX3JldCgmb3BjW2luc25fYnl0ZXMgLSBQRlhf
QllURVNdKTsKICAgICAgICAgICAgIGNvcHlfUkVYX1ZFWChvcGMsIHJleF9w
cmVmaXgsIHZleCk7CiAgICAgICAgIH0KIAo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-06.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-06.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IEJ1aWxkIFhlbiB3aXRoIFJldHVybiBUaHVua3MKClRo
ZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uIHNwZWN1bGF0aXZlIHZ1bG5l
cmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRpcmVjdApicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QgaGFsZiBv
ZiBhIGNhY2hlbGluZS4KCkluIG9yZGVyIHRvIG1pdGlnYXRlIHRoaXMsIGJ1
aWxkIHdpdGggcmV0dXJuIHRodW5rcyBhbmQgYXJyYW5nZSBmb3IKX194ODZf
cmV0dXJuX3RodW5rIHRvIGJlIChtaXMpYWxpZ25lZCBpbiB0aGUgc2FtZSBt
YW5uZXIgYXMKX194ODZfaW5kaXJlY3RfdGh1bmtfKiBzbyB0aGUgUkVUIGlu
c3RydWN0aW9uIGlzIHBsYWNlZCBpbiBhIHNhZmUgbG9jYXRpb24uCgpwbGFj
ZV9yZXQoKSBuZWVkcyB0byBjb25kaXRpb25hbGx5IGVtaXQgSk1QIF9feDg2
X3JldHVybl90aHVuayBpbnN0ZWFkIG9mIFJFVC4KClRoaXMgaXMgcGFydCBv
ZiBYU0EtNDY5IC8gQ1ZFLTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnIGIveGVu
L2FyY2gveDg2L0tjb25maWcKaW5kZXggNDcxY2ZkOGE4MGVmLi4zNzA1NTg3
NTZmMGQgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnCisrKyBi
L3hlbi9hcmNoL3g4Ni9LY29uZmlnCkBAIC0zNSw5ICszNSwxNCBAQCBjb25m
aWcgQVJDSF9ERUZDT05GSUcKIAlkZWZhdWx0ICJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCiAKIGNvbmZpZyBDQ19IQVNfSU5ESVJFQ1Rf
VEhVTksKKwkjIEdDQyA+PSA4IG9yIENsYW5nID49IDYKIAlkZWZfYm9vbCAk
KGNjLW9wdGlvbiwtbWluZGlyZWN0LWJyYW5jaC1yZWdpc3RlcikgfHwgXAog
CSAgICAgICAgICQoY2Mtb3B0aW9uLC1tcmV0cG9saW5lLWV4dGVybmFsLXRo
dW5rKQogCitjb25maWcgQ0NfSEFTX1JFVFVSTl9USFVOSworCSMgR0NDID49
IDggb3IgQ2xhbmcgPj0gMTUKKwlkZWZfYm9vbCAkKGNjLW9wdGlvbiwtbWZ1
bmN0aW9uLXJldHVybj10aHVuay1leHRlcm4pCisKIGNvbmZpZyBIQVNfQVNf
Q0VUX1NTCiAJIyBiaW51dGlscyA+PSAyLjI5IG9yIExMVk0gPj0gNgogCWRl
Zl9ib29sICQoYXMtaW5zdHIsd3Jzc3EgJXJheCQoY29tbWEpMDtzZXRzc2Jz
eSkKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hlbi9h
cmNoL3g4Ni9NYWtlZmlsZQppbmRleCA4ODI0MDhjY2FmOWEuLjIyMjkzZDk2
OWIzOCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisrKyBi
L3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtNDIsNiArNDIsNyBAQCBvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KK29iai0kKENPTkZJR19SRVRV
Uk5fVEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KIG9iai0kKENPTkZJR19Q
VikgKz0gaW9wb3J0X2VtdWxhdGUubwogb2JqLXkgKz0gaXJxLm8KIG9iai0k
KENPTkZJR19LRVhFQykgKz0gbWFjaGluZV9rZXhlYy5vCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJvdC5TIGIveGVuL2FyY2gv
eDg2L2FjcGkvd2FrZXVwX3Byb3QuUwppbmRleCAzODU1ZmYxZGRiOTQuLmNk
NDY4MmI5ZjljNSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvd2Fr
ZXVwX3Byb3QuUworKysgYi94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJv
dC5TCkBAIC0xMzEsNyArMTMxLDcgQEAgRU5UUlkoczNfcmVzdW1lKQogICAg
ICAgICBwb3AgICAgICVyMTIKICAgICAgICAgcG9wICAgICAlcmJ4CiAgICAg
ICAgIHBvcCAgICAgJXJicAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAK
IC5kYXRhCiAgICAgICAgIC5hbGlnbiAxNgpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94ODYvYWx0ZXJuYXRp
dmUuYwppbmRleCA4ODA4MmY2OGE5ODIuLjE1MWRmNzM1ODNmMSAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKKysrIGIveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTE0OSwxNiArMTQ5LDQ1IEBAIHZv
aWQgaW5pdF9vcl9saXZlcGF0Y2ggYWRkX25vcHModm9pZCAqaW5zbnMsIHVu
c2lnbmVkIGludCBsZW4pCiAgICAgfQogfQogCit2b2lkIG5vY2FsbCBfX3g4
Nl9yZXR1cm5fdGh1bmsodm9pZCk7CisKIC8qCiAgKiBQbGFjZSBhIHJldHVy
biBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGluIHRoZSB3cml0YWJsZSBhbGlh
cyBvZiBhIHN0dWIuCiAgKgorICogV2hlbiBDT05GSUdfUkVUVVJOX1RIVU5L
IGlzIGFjdGl2ZSwgdGhpcyBtYXkgYmUgYSBKTVAgX194ODZfcmV0dXJuX3Ro
dW5rCisgKiBpbnN0ZWFkLCBkZXBlbmRpbmcgb24gdGhlIHNhZmV0eSBvZiBA
cHRyIHdpdGggcmVzcGVjdCB0byBJbmRpcmVjdCBUYXJnZXQKKyAqIFNlbGVj
dGlvbi4KKyAqCiAgKiBSZXR1cm5zIHRoZSBuZXh0IHBvc2l0aW9uIHRvIHdy
aXRlIGludG8gdGhlIHN0dWIuCiAgKi8KIHZvaWQgKnBsYWNlX3JldCh2b2lk
ICpwdHIpCiB7CisgICAgdW5zaWduZWQgbG9uZyBhZGRyID0gKHVuc2lnbmVk
IGxvbmcpcHRyOwogICAgIHVpbnQ4X3QgKnAgPSBwdHI7CiAKLSAgICAqcCsr
ID0gMHhjMzsKKyAgICAvKgorICAgICAqIFdoZW4gUmV0dXJuIFRodW5rcyBh
cmUgdXNlZCwgaWYgYSBSRVQgd291bGQgYmUgdW5zYWZlIGF0IHRoaXMgbG9j
YXRpb24KKyAgICAgKiB3aXRoIHJlc3BlY3QgdG8gSW5kaXJlY3QgVGFyZ2V0
IFNlbGVjdGlvbiAoaS5lLiBpZiBhZGRyIGlzIGluIHRoZSBmaXJzdAorICAg
ICAqIGhhbGYgb2YgYSBjYWNoZWxpbmUpLCBpbnNlcnQgYSBKTVAgX194ODZf
cmV0dXJuX3RodW5rIGluc3RlYWQuCisgICAgICoKKyAgICAgKiBUaGUgZGlz
cGxhY2VtZW50IG5lZWRzIHRvIGJlIHJlbGF0aXZlIHRvIHRoZSBleGVjdXRh
YmxlIGFsaWFzIG9mIHRoZQorICAgICAqIHN0dWIsIG5vdCB0byBAcHRyIHdo
aWNoIGlzIHRoZSB3cml0ZWFibGUgYWxpYXMuCisgICAgICovCisgICAgaWYg
KCBJU19FTkFCTEVEKENPTkZJR19SRVRVUk5fVEhVTkspICYmICEoYWRkciAm
IDB4MjApICkKKyAgICB7CisgICAgICAgIGxvbmcgc3R1Yl92YSA9ICh0aGlz
X2NwdShzdHVicy5hZGRyKSAmIFBBR0VfTUFTSykgKyAoYWRkciAmIH5QQUdF
X01BU0spOworICAgICAgICBsb25nIGRpc3AgPSAobG9uZylfX3g4Nl9yZXR1
cm5fdGh1bmsgLSAoc3R1Yl92YSArIDUpOworCisgICAgICAgIEJVR19PTigo
aW50MzJfdClkaXNwICE9IGRpc3ApOworCisgICAgICAgICpwKysgPSAweGU5
OworICAgICAgICAqKGludDMyX3QgKilwID0gZGlzcDsKKyAgICAgICAgcCAr
PSA0OworICAgIH0KKyAgICBlbHNlCisgICAgeworICAgICAgICAqcCsrID0g
MHhjMzsKKyAgICB9CiAKICAgICByZXR1cm4gcDsKIH0KZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rIGIveGVuL2FyY2gveDg2L2FyY2gubWsK
aW5kZXggMjI3ZDQzOWE0NTIzLi4zNzkzMTdjMDEzMzcgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rCisrKyBiL3hlbi9hcmNoL3g4Ni9hcmNo
Lm1rCkBAIC01MCw2ICs1MCw5IEBAIENGTEFHUy0kKENPTkZJR19DQ19JU19H
Q0MpICs9IC1mbm8tanVtcC10YWJsZXMKIENGTEFHUy0kKENPTkZJR19DQ19J
U19DTEFORykgKz0gLW1yZXRwb2xpbmUtZXh0ZXJuYWwtdGh1bmsKIGVuZGlm
CiAKKyMgQ29tcGlsZSB3aXRoIHJldHVybiB0aHVuayBzdXBwb3J0IGlmIHNl
bGVjdGVkLgorQ0ZMQUdTLSQoQ09ORklHX1JFVFVSTl9USFVOSykgKz0gLW1m
dW5jdGlvbi1yZXR1cm49dGh1bmstZXh0ZXJuCisKIGlmZGVmIENPTkZJR19Y
RU5fSUJUCiAjIEZvcmNlIC1mbm8tanVtcC10YWJsZXMgdG8gd29yayBhcm91
bmQKICMgICBodHRwczovL2djYy5nbnUub3JnL2J1Z3ppbGxhL3Nob3dfYnVn
LmNnaT9pZD0xMDQ4MTYKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGIt
dGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCAwNWYx
MDQzZGY3ZDAuLjQ3MmRhNDgxZGQ0MiAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L2JoYi10aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsu
UwpAQCAtMjMsNyArMjMsNyBAQCBFTlRSWShjbGVhcl9iaGJfdHN4KQogMDog
ICAgICAuYnl0ZSAweGM2LCAweGY4LCAwICAgICAgICAgICAgIC8qIHhhYm9y
dCAkMCAqLwogICAgICAgICBpbnQzCiAxOgotICAgICAgICByZXQKKyAgICAg
ICAgUkVUCiAKICAgICAgICAgLnNpemUgY2xlYXJfYmhiX3RzeCwgLiAtIGNs
ZWFyX2JoYl90c3gKICAgICAgICAgLnR5cGUgY2xlYXJfYmhiX3RzeCwgQGZ1
bmN0aW9uCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvY2xlYXJfcGFnZS5T
IGIveGVuL2FyY2gveDg2L2NsZWFyX3BhZ2UuUwppbmRleCBkOWQ1MjRjNzll
Y2QuLmVhNzBiZDkxNjc2ZSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2Ns
ZWFyX3BhZ2UuUworKysgYi94ZW4vYXJjaC94ODYvY2xlYXJfcGFnZS5TCkBA
IC0xLDUgKzEsNiBAQAogICAgICAgICAuZmlsZSBfX0ZJTEVfXwogCisjaW5j
bHVkZSA8YXNtL2FzbV9kZWZucy5oPgogI2luY2x1ZGUgPGFzbS9wYWdlLmg+
CiAKIEVOVFJZKGNsZWFyX3BhZ2Vfc3NlMikKQEAgLTE1LDQgKzE2LDQgQEAg
RU5UUlkoY2xlYXJfcGFnZV9zc2UyKQogICAgICAgICBqbnogICAgIDBiCiAK
ICAgICAgICAgc2ZlbmNlCi0gICAgICAgIHJldAorICAgICAgICBSRVQKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUyBiL3hlbi9hcmNo
L3g4Ni9jb3B5X3BhZ2UuUwppbmRleCAyZGE4MTEyNmM1ZmEuLmJiNzljNWZj
NzlkYiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2NvcHlfcGFnZS5TCisr
KyBiL3hlbi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUwpAQCAtMSw1ICsxLDYgQEAK
ICAgICAgICAgLmZpbGUgX19GSUxFX18KIAorI2luY2x1ZGUgPGFzbS9hc21f
ZGVmbnMuaD4KICNpbmNsdWRlIDxhc20vcGFnZS5oPgogCiAjZGVmaW5lIHNy
Y19yZWcgJXJzaQpAQCAtNDAsNCArNDEsNCBAQCBFTlRSWShjb3B5X3BhZ2Vf
c3NlMikKICAgICAgICAgbW92bnRpICB0bXA0X3JlZywgMypXT1JEX1NJWkUo
ZHN0X3JlZykKIAogICAgICAgICBzZmVuY2UKLSAgICAgICAgcmV0CisgICAg
ICAgIFJFVApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2VmaS9jaGVjay5j
IGIveGVuL2FyY2gveDg2L2VmaS9jaGVjay5jCmluZGV4IDllNDczZmFhZDNj
OS4uMjNiYTMwYWJmMzMwIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvZWZp
L2NoZWNrLmMKKysrIGIveGVuL2FyY2gveDg2L2VmaS9jaGVjay5jCkBAIC0z
LDYgKzMsOSBAQCBpbnQgX19hdHRyaWJ1dGVfXygoX19tc19hYmlfXykpIHRl
c3QoaW50IGkpCiAgICAgcmV0dXJuIGk7CiB9CiAKKy8qIEluIGNhc2UgLW1m
dW5jdGlvbi1yZXR1cm4gaXMgaW4gdXNlLiAqLwordm9pZCBfX3g4Nl9yZXR1
cm5fdGh1bmsodm9pZCkge307CisKIC8qCiAgKiBQb3B1bGF0ZSBhbiBhcnJh
eSB3aXRoICJhZGRyZXNzZXMiIG9mIHJlbG9jYXRhYmxlIGFuZCBhYnNvbHV0
ZSB2YWx1ZXMuCiAgKiBUaGlzIGlzIHRvIHByb2JlIGxkIGZvciAoYSkgZW1p
dHRpbmcgYmFzZSByZWxvY2F0aW9ucyBhdCBhbGwgYW5kIChiKSBub3QKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hc20tZGVmbnMu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hc20tZGVmbnMuaAppbmRl
eCA3ZTIyZmNiOWMwNmIuLmE5Y2EwZDA1ZWM5OSAxMDA2NDQKLS0tIGEveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1kZWZucy5oCisrKyBiL3hlbi9h
cmNoL3g4Ni9pbmNsdWRlL2FzbS9hc20tZGVmbnMuaApAQCAtNDcsNiArNDcs
MTIgQEAKICAgICAuZW5kaWYKIC5lbmRtCiAKKyNpZmRlZiBDT05GSUdfUkVU
VVJOX1RIVU5LCisjIGRlZmluZSBSRVQgam1wIF9feDg2X3JldHVybl90aHVu
aworI2Vsc2UKKyMgZGVmaW5lIFJFVCByZXQKKyNlbmRpZgorCiAjaWZkZWYg
Q09ORklHX1hFTl9JQlQKICMgZGVmaW5lIEVOREJSNjQgZW5kYnI2NAogI2Vs
c2UKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmRpcmVjdC10aHVuay5T
IGIveGVuL2FyY2gveDg2L2luZGlyZWN0LXRodW5rLlMKaW5kZXggZTdlZjEw
NGQzYmQzLi4yMzljZjdkYzc3MGIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9pbmRpcmVjdC10aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9pbmRpcmVj
dC10aHVuay5TCkBAIC0xMSw2ICsxMSw5IEBACiAKICNpbmNsdWRlIDxhc20v
YXNtX2RlZm5zLmg+CiAKKworI2lmZGVmIENPTkZJR19JTkRJUkVDVF9USFVO
SworCiAubWFjcm8gSU5EX1RIVU5LX1JFVFBPTElORSByZWc6cmVxCiAgICAg
ICAgIGNhbGwgMWYKICAgICAgICAgaW50MwpAQCAtNjAsMyArNjMsMjcgQEAg
RU5UUlkoX194ODZfaW5kaXJlY3RfdGh1bmtfXHJlZykKIC5pcnAgcmVnLCBh
eCwgY3gsIGR4LCBieCwgYnAsIHNpLCBkaSwgOCwgOSwgMTAsIDExLCAxMiwg
MTMsIDE0LCAxNQogICAgICAgICBHRU5fSU5ESVJFQ1RfVEhVTksgcmVnPXJc
cmVnCiAuZW5kcgorCisjZW5kaWYgLyogQ09ORklHX0lORElSRUNUX1RIVU5L
ICovCisKKyNpZmRlZiBDT05GSUdfUkVUVVJOX1RIVU5LCisgICAgICAgIC5z
ZWN0aW9uIC50ZXh0LmVudHJ5Ll9feDg2X3JldHVybl90aHVuaywgImF4Iiwg
QHByb2diaXRzCisKKyAgICAgICAgLyoKKyAgICAgICAgICogVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0CisgICAgICAgICAqIGluZGlyZWN0IGJyYW5jaGVzIChp
bmNsdWRpbmcgUkVUcykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdAor
ICAgICAgICAgKiBoYWxmIG9mIGEgY2FjaGVsaW5lLiAgQXJyYW5nZSBmb3Ig
dGhlbSB0byBiZSBpbiB0aGUgc2Vjb25kIGhhbGYuCisgICAgICAgICAqCisg
ICAgICAgICAqIEFsaWduIHRvIDY0LCB0aGVuIHNraXAgMzIuCisgICAgICAg
ICAqLworICAgICAgICAuYmFsaWduIDY0CisgICAgICAgIC5maWxsIDMyLCAx
LCAweGNjCisKK0VOVFJZKF9feDg2X3JldHVybl90aHVuaykKKyAgICAgICAg
cmV0CisgICAgICAgIGludDMgLyogSGFsdCBzdHJhaWdodC1saW5lIHNwZWN1
bGF0aW9uICovCisKKyAgICAgICAgLnNpemUgX194ODZfcmV0dXJuX3RodW5r
LCAuIC0gX194ODZfcmV0dXJuX3RodW5rCisgICAgICAgIC50eXBlIF9feDg2
X3JldHVybl90aHVuaywgQGZ1bmN0aW9uCisKKyNlbmRpZiAvKiBDT05GSUdf
UkVUVVJOX1RIVU5LICovCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvcHYv
ZW11bC1wcml2LW9wLmMgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9w
LmMKaW5kZXggMjhlYTdjYzU4MGE5Li44NzJhODlkYjc2OWMgMTAwNjQ0Ci0t
LSBhL3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXByaXYtb3AuYworKysgYi94ZW4v
YXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMKQEAgLTE0Myw3ICsxNDMsNyBA
QCBzdGF0aWMgaW9fZW11bF9zdHViX3QgKmlvX2VtdWxfc3R1Yl9zZXR1cChz
dHJ1Y3QgcHJpdl9vcF9jdHh0ICpjdHh0LCB1OCBvcGNvZGUsCiAgICAgQlVJ
TERfQlVHX09OKFNUVUJfQlVGX1NJWkUgLyAyIDwKICAgICAgICAgICAgICAg
ICAgKHNpemVvZihwcm9sb2d1ZSkgKyBzaXplb2YoZXBpbG9ndWUpICsgMTAg
LyogMnggY2FsbCAqLyArCiAgICAgICAgICAgICAgICAgICBNQVgoMyAvKiBk
ZWZhdWx0IHN0dWIgKi8sIElPRU1VTF9RVUlSS19TVFVCX0JZVEVTKSArCi0g
ICAgICAgICAgICAgICAgICAxIC8qIHJldCAqLykpOworICAgICAgICAgICAg
ICAgICAgKElTX0VOQUJMRUQoQ09ORklHX1JFVFVSTl9USFVOSykgPyA1IDog
MSkgLyogcmV0ICovKSk7CiAgICAgLyogUnVudGltZSBjb25maXJtYXRpb24g
dGhhdCB3ZSBoYXZlbid0IGNsb2JiZXJlZCBhbiBhZGphY2VudCBzdHViLiAq
LwogICAgIEJVR19PTihTVFVCX0JVRl9TSVpFIC8gMiA8IChwIC0gY3R4dC0+
aW9fZW11bF9zdHViKSk7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9w
di9ncHJfc3dpdGNoLlMgYi94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5T
CmluZGV4IGU3ZjViZmNkMmQwMy4uZDkwNDM1YmU4ODJlIDEwMDY0NAotLS0g
YS94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5TCisrKyBiL3hlbi9hcmNo
L3g4Ni9wdi9ncHJfc3dpdGNoLlMKQEAgLTI2LDcgKzI2LDcgQEAgRU5UUlko
bG9hZF9ndWVzdF9ncHJzKQogICAgICAgICBtb3ZxICBVUkVHU19yMTUoJXJk
aSksICVyMTUKICAgICAgICAgbW92cSAgVVJFR1NfcmN4KCVyZGkpLCAlcmN4
CiAgICAgICAgIG1vdnEgIFVSRUdTX3JkaSglcmRpKSwgJXJkaQotICAgICAg
ICByZXQKKyAgICAgICAgUkVUCiAKICAgICAgICAgLnNpemUgbG9hZF9ndWVz
dF9ncHJzLCAuIC0gbG9hZF9ndWVzdF9ncHJzCiAgICAgICAgIC50eXBlIGxv
YWRfZ3Vlc3RfZ3BycywgU1RUX0ZVTkMKQEAgLTUxLDcgKzUxLDcgQEAgRU5U
Ulkoc2F2ZV9ndWVzdF9ncHJzKQogICAgICAgICBtb3ZxICAlcmJ4LCBVUkVH
U19yYngoJXJkaSkKICAgICAgICAgbW92cSAgJXJkeCwgVVJFR1NfcmR4KCVy
ZGkpCiAgICAgICAgIG1vdnEgICVyY3gsIFVSRUdTX3JjeCglcmRpKQotICAg
ICAgICByZXQKKyAgICAgICAgUkVUCiAKICAgICAgICAgLnNpemUgc2F2ZV9n
dWVzdF9ncHJzLCAuIC0gc2F2ZV9ndWVzdF9ncHJzCiAgICAgICAgIC50eXBl
IHNhdmVfZ3Vlc3RfZ3BycywgU1RUX0ZVTkMKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu
YwppbmRleCBiMWU0N2E4NDllODcuLjJmNzc3ZThhN2U3NSAxMDA2NDQKLS0t
IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCisrKyBiL3hlbi9hcmNoL3g4
Ni9zcGVjX2N0cmwuYwpAQCAtNTc1LDYgKzU3NSw5IEBAIHN0YXRpYyB2b2lk
IF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rKQog
I2lmZGVmIENPTkZJR19JTkRJUkVDVF9USFVOSwogICAgICAgICAgICAgICAg
IiBJTkRJUkVDVF9USFVOSyIKICNlbmRpZgorI2lmZGVmIENPTkZJR19SRVRV
Uk5fVEhVTksKKyAgICAgICAgICAgICAgICIgUkVUVVJOX1RIVU5LIgorI2Vu
ZGlmCiAjaWZkZWYgQ09ORklHX1NIQURPV19QQUdJTkcKICAgICAgICAgICAg
ICAgICIgU0hBRE9XX1BBR0lORyIKICNlbmRpZgpkaWZmIC0tZ2l0IGEveGVu
L2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUyBiL3hlbi9hcmNoL3g4
Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKaW5kZXggZmY0NjJhOTJlMDAzLi41
N2U1NGRjNzVmYzIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQv
Y29tcGF0L2VudHJ5LlMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21w
YXQvZW50cnkuUwpAQCAtMTgzLDcgKzE4Myw3IEBAIEVOVFJZKGNyNF9wdjMy
X3Jlc3RvcmUpCiAgICAgICAgIG1vdiAgICVyYXgsICVjcjQKICAgICAgICAg
bW92ICAgJXJheCwgKCVyZHgpCiAgICAgICAgIHBvcCAgICVyZHgKLSAgICAg
ICAgcmV0CisgICAgICAgIFJFVAogMDoKICNpZm5kZWYgTkRFQlVHCiAgICAg
ICAgIC8qIENoZWNrIHRoYXQgX2FsbF8gb2YgdGhlIGJpdHMgaW50ZW5kZWQg
dG8gYmUgc2V0IGFjdHVhbGx5IGFyZS4gKi8KQEAgLTIwMiw3ICsyMDIsNyBA
QCBFTlRSWShjcjRfcHYzMl9yZXN0b3JlKQogI2VuZGlmCiAgICAgICAgIHBv
cCAgICVyZHgKICAgICAgICAgeG9yICAgJWVheCwgJWVheAotICAgICAgICBy
ZXQKKyAgICAgICAgUkVUCiAKIEVOVFJZKGNvbXBhdF9zeXNjYWxsKQogICAg
ICAgICAvKiBGaXggdXAgcmVwb3J0ZWQgJWNzLyVzcyBmb3IgY29tcGF0IGRv
bWFpbnMuICovCkBAIC0zMjksNyArMzI5LDcgQEAgX19VTkxJS0VMWV9FTkQo
Y29tcGF0X2JvdW5jZV9udWxsX3NlbGVjdG9yKQogICAgICAgICB4b3IgICAl
ZWF4LCAlZWF4CiAgICAgICAgIG1vdiAgICVheCwgIFRSQVBCT1VOQ0VfY3Mo
JXJkeCkKICAgICAgICAgbW92ICAgJWFsLCAgVFJBUEJPVU5DRV9mbGFncygl
cmR4KQotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAKIC5zZWN0aW9uIC5m
aXh1cCwiYXgiCiAuTGZ4MTM6CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
eDg2XzY0L2VudHJ5LlMgYi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMK
aW5kZXggN2JiMGNjNzA4YTc2Li5mZDYzZWUyZTRjMWYgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUworKysgYi94ZW4vYXJjaC94
ODYveDg2XzY0L2VudHJ5LlMKQEAgLTU5OCw3ICs1OTgsNyBAQCBfX1VOTElL
RUxZX0VORChjcmVhdGVfYm91bmNlX2ZyYW1lX2JhZF9ib3VuY2VfaXApCiAg
ICAgICAgIHhvciAgICVlYXgsICVlYXgKICAgICAgICAgbW92ICAgJXJheCwg
VFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAgICAgbW92ICAgJWFsLCAgVFJB
UEJPVU5DRV9mbGFncyglcmR4KQotICAgICAgICByZXQKKyAgICAgICAgUkVU
CiAKICAgICAgICAgLnB1c2hzZWN0aW9uIC5maXh1cCwgImF4IiwgQHByb2di
aXRzCiAgICAgICAgICMgTnVtZXJpYyB0YWdzIGJlbG93IHJlcHJlc2VudCB0
aGUgaW50ZW5kZWQgb3ZlcmFsbCAlcnNpIGFkanVzdG1lbnQuCmRpZmYgLS1n
aXQgYS94ZW4vYXJjaC94ODYveGVuLmxkcy5TIGIveGVuL2FyY2gveDg2L3hl
bi5sZHMuUwppbmRleCA4OTMwZTE0ZmM0MGUuLmI2NmU3MDhlYmY2OSAxMDA2
NDQKLS0tIGEveGVuL2FyY2gveDg2L3hlbi5sZHMuUworKysgYi94ZW4vYXJj
aC94ODYveGVuLmxkcy5TCkBAIC04Niw2ICs4Niw3IEBAIFNFQ1RJT05TCiAg
ICAgICAgLiA9IEFMSUdOKFBBR0VfU0laRSk7CiAgICAgICAgX3N0ZXh0ZW50
cnkgPSAuOwogICAgICAgICooLnRleHQuZW50cnkpCisgICAgICAgKigudGV4
dC5lbnRyeS4qKQogICAgICAgIC4gPSBBTElHTihQQUdFX1NJWkUpOwogICAg
ICAgIF9ldGV4dGVudHJ5ID0gLjsKIApkaWZmIC0tZ2l0IGEveGVuL2NvbW1v
bi9LY29uZmlnIGIveGVuL2NvbW1vbi9LY29uZmlnCmluZGV4IGNkNzM4NTE1
MzgyMy4uYzgyYmVlOTJmNGNhIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL0tj
b25maWcKKysrIGIveGVuL2NvbW1vbi9LY29uZmlnCkBAIC0xMTIsNiArMTEy
LDE3IEBAIGNvbmZpZyBJTkRJUkVDVF9USFVOSwogCSAgV2hlbiBlbmFibGVk
LCBpbmRpcmVjdCBicmFuY2hlcyBhcmUgaW1wbGVtZW50ZWQgdXNpbmcgYSBu
ZXcgY29uc3RydWN0CiAJICBjYWxsZWQgInJldHBvbGluZSIgdGhhdCBwcmV2
ZW50cyBzcGVjdWxhdGlvbi4KIAorY29uZmlnIFJFVFVSTl9USFVOSworCWJv
b2wgIk91dC1vZi1saW5lIFJldHVybnMiCisJZGVwZW5kcyBvbiBDQ19IQVNf
UkVUVVJOX1RIVU5LCisJZGVmYXVsdCBJTkRJUkVDVF9USFVOSworCWhlbHAK
KwkgIENvbXBpbGUgWGVuIHdpdGggb3V0LW9mLWxpbmUgcmV0dXJucy4KKwor
CSAgVGhpcyBhbGxvd3MgWGVuIHRvIG1pdGlnYXRlIGEgdmFyaWV0eSBvZiBz
cGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXRpZXMKKwkgIGJ5IGNob29zaW5nIGEg
aGFyZHdhcmUtZGVwZW5kZW50IGluc3RydWN0aW9uIHNlcXVlbmNlIHRvIGlt
cGxlbWVudAorCSAgZnVuY3Rpb24gcmV0dXJucyBzYWZlbHkuCisKIGNvbmZp
ZyBTUEVDVUxBVElWRV9IQVJERU5fQVJSQVkKIAlib29sICJTcGVjdWxhdGl2
ZSBBcnJheSBIYXJkZW5pbmciCiAJZGVmYXVsdCB5Cg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-07.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-07.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogU3ludGhlc2lzZSBJVFNfTk8g
dG8gZ3Vlc3RzIG9uIHVuYWZmZWN0ZWQgaGFyZHdhcmUKCkl0IGlzIGVhc2ll
ciB0byBleHByZXNzIGZlYXR1cmUgd29yZCAxNyBpbiB0ZXJtcyBvZiB3b3Jk
IDE2ICsgWzMyLCA2NCkgYXMKdGhhdCdzIGhvdyB0aGUgbGF5b3V0IGlzIGdp
dmVuIGluIGRvY3VtZW50YXRpb24uCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2
OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29v
cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKaW5k
ZXggYTZiOGFmMTI5NjRjLi5kOWFlZGZjMjVhYjAgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKKysrIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaApAQCAtMTY0LDYg
KzE2NCw3IEBACiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAgICAgICAgIGJv
b3RfY3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCiAjZGVmaW5lIGNwdV9o
YXNfcmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9S
RkRTX05PKQogI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIgICAgICBib290
X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKKyNkZWZpbmUgY3B1
X2hhc19pdHNfbm8gICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF
X0lUU19OTykKIAogLyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5lIGNwdV9o
YXNfYXJjaF9wZXJmbW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9B
UkNIX1BFUkZNT04pCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXggMmY3Nzdl
OGE3ZTc1Li41NTllZTkwYjQ0ZGMgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMK
QEAgLTE3NjYsNiArMTc2Niw5MCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgYmhp
X2NhbGN1bGF0aW9ucyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAqIGh0dHBz
Oi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZlbG9wZXIv
YXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1aWRhbmNl
L2Fkdmlzb3J5LWd1aWRhbmNlL2luZGlyZWN0LXRhcmdldC1zZWxlY3Rpb24u
aHRtbAorICovCitzdGF0aWMgdm9pZCBfX2luaXQgaXRzX2NhbGN1bGF0aW9u
cyh2b2lkKQoreworICAgIC8qCisgICAgICogSW5kaXJlY3QgVGFyZ2V0IFNl
bGVjdGlvbiBpcyBhIEJyYW5jaCBQcmVkaWN0aW9uIGJ1ZyB3aGVyZWJ5IGNl
cnRhaW4KKyAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVkaW5nIFJF
VHMpIGdldCBwcmVkaWN0ZWQgdXNpbmcgYSBkaXJlY3QgYnJhbmNoCisgICAg
ICogdGFyZ2V0LCByYXRoZXIgdGhhbiBhIHN1aXRhYmxlIGluZGlyZWN0IHRh
cmdldCwgYnlwYXNzaW5nIGhhcmR3YXJlCisgICAgICogaXNvbGF0aW9uIHBy
b3RlY3Rpb25zLgorICAgICAqCisgICAgICogSVRTIGFmZmVjdHMgQ29yZSAo
YnV0IG5vdCBBdG9tKSBwcm9jZXNzb3JzIHN0YXJ0aW5nIGZyb20gdGhlCisg
ICAgICogaW50cm9kdWN0aW9uIG9mIGVJQlJTLCB1cCB0byBidXQgbm90IGlu
Y2x1ZGluZyBHb2xkZW4gQ292ZSBjb3JlcworICAgICAqIChjaGVja2VkIGhl
cmUgd2l0aCBCSElfQ1RSTCkuCisgICAgICoKKyAgICAgKiBUaGUgSVRTX05P
IGZlYXR1cmUgaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVudW1lcmF0ZWQgYnkg
aGFyZHdhcmUsIGFuZCBpcworICAgICAqIG9ubHkgZm9yIFZNTXMgdG8gc3lu
dGhlc2lzZSBmb3IgZ3Vlc3RzLgorICAgICAqCisgICAgICogSVRTIGNvbWVz
IGluIDMgZmxhdm91cnM6CisgICAgICoKKyAgICAgKiAgIDEpIEFjcm9zcy1J
QlBCLiAgSW5kaXJlY3QgYnJhbmNoZXMgYWZ0ZXIgdGhlIElCUEIgY2FuIGJl
IGNvbnRyb2xsZWQKKyAgICAgKiAgICAgIGJ5IGRpcmVjdCB0YXJnZXRzIHdo
aWNoIGV4aXN0ZWQgcHJpb3IgdG8gdGhlIElCUEIuICBUaGlzIGlzCisgICAg
ICogICAgICBhZGRyZXNzZWQgaW4gdGhlIElQVSAyMDI1LjEgbWljcm9jb2Rl
IGRyb3AsIGFuZCBoYXMgbm8gb3RoZXIKKyAgICAgKiAgICAgIHNvZnR3YXJl
IGludGVyYWN0aW9uLgorICAgICAqCisgICAgICogICAyKSBHdWVzdC9Ib3N0
LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUgY29udHJv
bGxlZCBieQorICAgICAqICAgICAgZGlyZWN0IHRhcmdldHMgZnJvbSB0aGUg
Z3Vlc3QuICBUaGlzIGFwcGxpZXMgZXF1YWxseSB0byBQViBndWVzdHMKKyAg
ICAgKiAgICAgIChSaW5nMykgYW5kIEhWTSBndWVzdHMgKFZNWCksIGFuZCBh
cHBsaWVzIHRvIGFsbCBTa3lsYWtlLXVhcmNoCisgICAgICogICAgICBjb3Jl
cyB3aXRoIGVJQlJTLgorICAgICAqCisgICAgICogICAzKSBJbnRyYS1tb2Rl
LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUgY29udHJv
bGxlZCBieQorICAgICAqICAgICAgb3RoZXIgZXhlY3V0aW9uIGluIHRoZSBz
YW1lIG1vZGUuCisgICAgICovCisKKyAgICAvKgorICAgICAqIElmIHdlIGNh
biBzZWUgSVRTX05PLCBvciB3ZSdyZSB2aXJ0dWFsaXNlZCwgZG8gbm90aGlu
Zy4gIFdlIGFyZSBvciBtYXkKKyAgICAgKiBtaWdyYXRlIHNvbWV3aGVyZSB1
bnNhZmUuCisgICAgICovCisgICAgaWYgKCBjcHVfaGFzX2l0c19ubyB8fCBj
cHVfaGFzX2h5cGVydmlzb3IgKQorICAgICAgICByZXR1cm47CisKKyAgICAv
KiBJVFMgaXMgb25seSBrbm93biB0byBhZmZlY3QgSW50ZWwgcHJvY2Vzc29y
cyBhdCB0aGlzIHRpbWUuICovCisgICAgaWYgKCBib290X2NwdV9kYXRhLng4
Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9JTlRFTCApCisgICAgICAgIHJldHVy
bjsKKworICAgIC8qCisgICAgICogSVRTIGRvZXMgbm90IGV4aXN0IG9uOgor
ICAgICAqICAtIG5vbi1GYW1pbHkgNiBDUFVzCisgICAgICogIC0gdGhvc2Ug
d2l0aG91dCBlSUJSUworICAgICAqICAtIHRob3NlIHdpdGggQkhJX0NUUkwK
KyAgICAgKiBidXQgd2Ugc3RpbGwgbmVlZCB0byBzeW50aGVzaXNlIElUU19O
Ty4KKyAgICAgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2ICE9IDYg
fHwgIWNwdV9oYXNfZWlicnMgfHwKKyAgICAgICAgIGJvb3RfY3B1X2hhcyhY
ODZfRkVBVFVSRV9CSElfQ1RSTCkgKQorICAgICAgICBnb3RvIHN5bnRoZXNp
c2U7CisKKyAgICBzd2l0Y2ggKCBib290X2NwdV9kYXRhLng4Nl9tb2RlbCAp
CisgICAgeworICAgICAgICAvKiBUaGVzZSBTa3lsYWtlLXVhcmNoIGNvcmVz
IHN1ZmZlciBjYXNlcyAjMiBhbmQgIzMuICovCisgICAgY2FzZSBJTlRFTF9G
QU02X1NLWUxBS0VfWDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0Vf
TDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0U6CisgICAgY2FzZSBJ
TlRFTF9GQU02X0NPTUVUTEFLRToKKyAgICBjYXNlIElOVEVMX0ZBTTZfQ09N
RVRMQUtFX0w6CisgICAgICAgIHJldHVybjsKKworICAgICAgICAvKiBUaGVz
ZSBTdW5ueS9XaWxsb3cvQ3lwcmVzcyBDb3ZlIGNvcmVzIHN1ZmZlciBjYXNl
ICMzLiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9JQ0VMQUtFX1g6CisgICAg
Y2FzZSBJTlRFTF9GQU02X0lDRUxBS0VfRDoKKyAgICBjYXNlIElOVEVMX0ZB
TTZfSUNFTEFLRV9MOgorICAgIGNhc2UgSU5URUxfRkFNNl9USUdFUkxBS0Vf
TDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfVElHRVJMQUtFOgorICAgIGNhc2Ug
SU5URUxfRkFNNl9ST0NLRVRMQUtFOgorICAgICAgICByZXR1cm47CisKKyAg
ICBkZWZhdWx0OgorICAgICAgICBicmVhazsKKyAgICB9CisKKyAgICAvKiBQ
bGF0Zm9ybXMgcmVtYWluaW5nIGFyZSBub3QgYmVsaWV2ZWQgdG8gYmUgdnVs
bmVyYWJsZSB0byBJVFMuICovCisgc3ludGhlc2lzZToKKyAgICBzZXR1cF9m
b3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX0lUU19OTyk7Cit9CisKIHZvaWQg
c3BlY19jdHJsX2luaXRfZG9tYWluKHN0cnVjdCBkb21haW4gKmQpCiB7CiAg
ICAgYm9vbCBwdiA9IGlzX3B2X2RvbWFpbihkKTsKQEAgLTIzMTYsNiArMjQw
MCw4IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0aWdhdGlv
bnModm9pZCkKIAogICAgIGJoaV9jYWxjdWxhdGlvbnMoKTsKIAorICAgIGl0
c19jYWxjdWxhdGlvbnMoKTsKKwogICAgIHByaW50X2RldGFpbHModGh1bmsp
OwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9h
cmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9wdWJsaWMv
YXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IDAwMDRmZDRiZjU2ZS4u
OTljNGRjMWZmZDQwIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
YXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTMzNCw3ICszMzQs
OCBAQCBYRU5fQ1BVRkVBVFVSRShHRFNfTk8sICAgICAgICAgICAgIDE2KjMy
KzI2KSAvKkEgIE5vIEdhdGhlciBEYXRhIFNhbXBsaW5nICovCiBYRU5fQ1BV
RkVBVFVSRShSRkRTX05PLCAgICAgICAgICAgIDE2KjMyKzI3KSAvKkEgIE5v
IFJlZ2lzdGVyIEZpbGUgRGF0YSBTYW1wbGluZyAqLwogWEVOX0NQVUZFQVRV
UkUoUkZEU19DTEVBUiwgICAgICAgICAxNiozMisyOCkgLyohQSBSZWdpc3Rl
ciBGaWxlKHMpIGNsZWFyZWQgYnkgVkVSVyAqLwogCi0vKiBJbnRlbC1kZWZp
bmVkIENQVSBmZWF0dXJlcywgTVNSX0FSQ0hfQ0FQUyAweDEwYS5lZHgsIHdv
cmQgMTcgKi8KKy8qIEludGVsLWRlZmluZWQgQ1BVIGZlYXR1cmVzLCBNU1Jf
QVJDSF9DQVBTIDB4MTBhLmVkeCwgd29yZCAxNyAoZXhwcmVzcyBpbiB0ZXJt
cyBvZiB3b3JkIDE2KSAqLworWEVOX0NQVUZFQVRVUkUoSVRTX05PLCAgICAg
ICAgICAgICAxNiozMis2MikgLyohQSBObyBJbmRpcmVjdCBUYXJnZXQgU2Vs
ZWN0aW9uICovCiAKICNlbmRpZiAvKiBYRU5fQ1BVRkVBVFVSRSAqLwogCmRp
ZmYgLS1naXQgYS94ZW4vdG9vbHMvZ2VuLWNwdWlkLnB5IGIveGVuL3Rvb2xz
L2dlbi1jcHVpZC5weQppbmRleCA0MTViOGIxZDY4ODEuLjA1YjFjMTNlYzQ3
OCAxMDA3NTUKLS0tIGEveGVuL3Rvb2xzL2dlbi1jcHVpZC5weQorKysgYi94
ZW4vdG9vbHMvZ2VuLWNwdWlkLnB5CkBAIC01MSw3ICs1MSw3IEBAIGRlZiBw
YXJzZV9kZWZpbml0aW9ucyhzdGF0ZSk6CiAgICAgICAgIHIiXHMrL1wqKFtc
dyFdKikgLiokIikKIAogICAgIHdvcmRfcmVnZXggPSByZS5jb21waWxlKAot
ICAgICAgICByIl4vXCogLiogd29yZCAoXGQqKSBcKi8kIikKKyAgICAgICAg
ciJeL1wqIC4qIHdvcmQgKFxkKikgLipcKi8kIikKICAgICBsYXN0X3dvcmQg
PSAtMQogCiAgICAgdGhpcyA9IHN5cy5tb2R1bGVzW19fbmFtZV9fXQo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-01.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-01.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2FsdGVybmF0aXZlOiBTdXBwb3J0IHJlcGxhY2Vt
ZW50cyB3aGVuIGEgZmVhdHVyZSBpcyBub3QgcHJlc2VudAoKVXNlIHRoZSB0
b3AgYml0IG9mIGEtPmNwdWlkIHRvIGV4cHJlc3MgaW52ZXJ0ZWQgcG9sYXJp
dHkuICBUaGlzIHJlcXVpcmVzCnN0cmlwcGluZyB0aGUgdG9wIGJpdCBiYWNr
IG91dCB3aGVuIHBlcmZvcm1pbmcgdGhlIHNhbml0eSBjaGVja3MuCgpEZXNw
aXRlIG9ubHkgYmVpbmcgdXNlZCBvbmNlLCBjcmVhdGUgYSByZXBsYWNlIGJv
b2xlYW4gdG8gZXhwcmVzcyB0aGUgZGVjaXNpb24KbW9yZSBjbGVhcmx5IGlu
IF9hcHBseV9hbHRlcm5hdGl2ZXMoKS4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0t
Z2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94
ODYvYWx0ZXJuYXRpdmUuYwppbmRleCA5MWI2MDg2NWJmM2IuLjkwYmY5YTky
YmZmOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMK
KysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTE5Nyw2ICsx
OTcsOCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBseV9h
bHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAgICAg
IHVpbnQ4X3QgKnJlcGwgPSBBTFRfUkVQTF9QVFIoYSk7CiAgICAgICAgIHVp
bnQ4X3QgYnVmW01BWF9QQVRDSF9MRU5dOwogICAgICAgICB1bnNpZ25lZCBp
bnQgdG90YWxfbGVuID0gYS0+b3JpZ19sZW4gKyBhLT5wYWRfbGVuOworICAg
ICAgICB1bnNpZ25lZCBpbnQgZmVhdCA9IGEtPmNwdWlkICYgfkFMVF9GTEFH
X05PVDsKKyAgICAgICAgYm9vbCBpbnYgPSBhLT5jcHVpZCAmIEFMVF9GTEFH
X05PVCwgcmVwbGFjZTsKIAogICAgICAgICBpZiAoIGEtPnJlcGxfbGVuID4g
dG90YWxfbGVuICkKICAgICAgICAgewpAQCAtMjE0LDExICsyMTYsMTEgQEAg
c3RhdGljIGludCBpbml0X29yX2xpdmVwYXRjaCBfYXBwbHlfYWx0ZXJuYXRp
dmVzKHN0cnVjdCBhbHRfaW5zdHIgKnN0YXJ0LAogICAgICAgICAgICAgcmV0
dXJuIC1FTk9TUEM7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAoIGEtPmNw
dWlkID49IE5DQVBJTlRTICogMzIgKQorICAgICAgICBpZiAoIGZlYXQgPj0g
TkNBUElOVFMgKiAzMiApCiAgICAgICAgIHsKICAgICAgICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUgogICAgICAgICAgICAgICAgICAgICJBbHQgZm9yICVw
cywgZmVhdHVyZSAlI3ggb3V0c2lkZSBvZiBmZWF0dXJlc2V0IHJhbmdlICUj
eFxuIiwKLSAgICAgICAgICAgICAgICAgICBBTFRfT1JJR19QVFIoYSksIGEt
PmNwdWlkLCBOQ0FQSU5UUyAqIDMyKTsKKyAgICAgICAgICAgICAgICAgICBB
TFRfT1JJR19QVFIoYSksIGZlYXQsIE5DQVBJTlRTICogMzIpOwogICAgICAg
ICAgICAgcmV0dXJuIC1FUkFOR0U7CiAgICAgICAgIH0KIApAQCAtMjQzLDgg
KzI0NSwxNCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAg
ICAgICAgICBjb250aW51ZTsKICAgICAgICAgfQogCisgICAgICAgIC8qCisg
ICAgICAgICAqIFNob3VsZCBhIHJlcGxhY2VtZW50IGJlIHBlcmZvcm1lZD8g
IE1vc3QgcmVwbGFjZW1lbnRzIGhhdmUgcG9zaXRpdmUKKyAgICAgICAgICog
cG9sYXJpdHksIGJ1dCB3ZSBzdXBwb3J0IG5lZ2F0aXZlIHBvbGFyaXR5IHRv
by4KKyAgICAgICAgICovCisgICAgICAgIHJlcGxhY2UgPSBib290X2NwdV9o
YXMoZmVhdCkgXiBpbnY7CisKICAgICAgICAgLyogSWYgdGhlcmUgaXMgbm8g
cmVwbGFjZW1lbnQgdG8gbWFrZSwgc2VlIGFib3V0IG9wdGltaXNpbmcgdGhl
IG5vcHMuICovCi0gICAgICAgIGlmICggIWJvb3RfY3B1X2hhcyhhLT5jcHVp
ZCkgKQorICAgICAgICBpZiAoICFyZXBsYWNlICkKICAgICAgICAgewogICAg
ICAgICAgICAgLyogT3JpZ2luIHNpdGUgc2l0ZSBhbHJlYWR5IHRvdWNoZWQ/
ICBEb24ndCBub3AgYW55dGhpbmcuICovCiAgICAgICAgICAgICBpZiAoIGJh
c2UtPnByaXYgKQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v
YWx0ZXJuYXRpdmUuaAppbmRleCA2OTU1NWQ3ODFlZjkuLjg5YjdiZGNiODJl
NSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKQEAgLTEsNiArMSwxMyBAQAogI2lmbmRlZiBfX1g4Nl9BTFRF
Uk5BVElWRV9IX18KICNkZWZpbmUgX19YODZfQUxURVJOQVRJVkVfSF9fCiAK
Ky8qCisgKiBDb21tb24gdG8gYm90aCBDIGFuZCBBU00uICBFeHByZXNzIGEg
cmVwbGFjZW1lbnQgd2hlbiBhIGZlYXR1cmUgaXMgbm90CisgKiBhdmFpbGFi
bGUuCisgKi8KKyNkZWZpbmUgQUxUX0ZMQUdfTk9UICgxIDw8IDE1KQorI2Rl
ZmluZSBBTFRfTk9UKHgpIChBTFRfRkxBR19OT1QgfCAoeCkpCisKICNpZmRl
ZiBfX0FTU0VNQkxZX18KICNpbmNsdWRlIDxhc20vYWx0ZXJuYXRpdmUtYXNt
Lmg+CiAjZWxzZQpAQCAtMTEsNyArMTgsNyBAQAogc3RydWN0IF9fcGFja2Vk
IGFsdF9pbnN0ciB7CiAgICAgaW50MzJfdCAgb3JpZ19vZmZzZXQ7ICAgLyog
b3JpZ2luYWwgaW5zdHJ1Y3Rpb24gKi8KICAgICBpbnQzMl90ICByZXBsX29m
ZnNldDsgICAvKiBvZmZzZXQgdG8gcmVwbGFjZW1lbnQgaW5zdHJ1Y3Rpb24g
Ki8KLSAgICB1aW50MTZfdCBjcHVpZDsgICAgICAgICAvKiBjcHVpZCBiaXQg
c2V0IGZvciByZXBsYWNlbWVudCAqLworICAgIHVpbnQxNl90IGNwdWlkOyAg
ICAgICAgIC8qIGNwdWlkIGJpdCBzZXQgZm9yIHJlcGxhY2VtZW50ICh0b3Ag
Yml0IGlzIHBvbGFyaXR5KSAqLwogICAgIHVpbnQ4X3QgIG9yaWdfbGVuOyAg
ICAgIC8qIGxlbmd0aCBvZiBvcmlnaW5hbCBpbnN0cnVjdGlvbiAqLwogICAg
IHVpbnQ4X3QgIHJlcGxfbGVuOyAgICAgIC8qIGxlbmd0aCBvZiBuZXcgaW5z
dHJ1Y3Rpb24gKi8KICAgICB1aW50OF90ICBwYWRfbGVuOyAgICAgICAvKiBs
ZW5ndGggb2YgYnVpbGQtdGltZSBwYWRkaW5nICovCgo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-02.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-02.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2d1ZXN0OiBSZW1vdmUgdXNlIG9mIHRoZSBYZW4g
aHlwZXJjYWxsX3BhZ2UKCkluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCBJ
VFMsIFhlbiBuZWVkcyB0byBzdGFydCB1c2luZyByZXR1cm4gdGh1bmtzLgpU
aGVyZWZvcmUgdGhlIGFkdmljZSBpbiBYU0EtNDY2IGJlY29tZXMgcmVsZXZh
bnQsIGFuZCB0aGUgaHlwZXJjYWxsX3BhZ2UgbmVlZHMKdG8gYmUgcmVtb3Zl
ZC4KCkltcGxlbWVudCBlYXJseV9oeXBlcmNhbGwoKSwgd2l0aCBpbmZyYXN0
cnVjdHVyZSB0byBmaWd1cmUgb3V0IHRoZSBjb3JyZWN0Cmluc3RydWN0aW9u
IG9uIGZpcnN0IHVzZS4gIFVzZSBBTFRFUk5BVElWRSgpcyB0byByZXN1bHQg
aW4gaW5saW5lIGh5cGVyY2FsbHMsCmluY2x1ZGluZyB0aGUgQUxUX05PVCgp
IGZvcm0gc28gd2Ugb25seSBuZWVkIGEgc2luZ2xlIHN5bnRoZXRpYyBmZWF0
dXJlIGJpdC4KCk5vIG92ZXJhbGwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0IG9m
IFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTogQW5k
cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3
ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9ndWVzdC94ZW4vTWFrZWZp
bGUgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCmluZGV4IDI2
ZmI0YjEwMDdjMC4uOGIzMjUwYWE4ODg2IDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCisrKyBiL3hlbi9hcmNoL3g4Ni9n
dWVzdC94ZW4vTWFrZWZpbGUKQEAgLTEsNCArMSw0IEBACi1vYmoteSArPSBo
eXBlcmNhbGxfcGFnZS5vCitvYmotYmluLXkgKz0gaHlwZXJjYWxsLmluaXQu
bwogb2JqLXkgKz0geGVuLm8KIAogb2JqLWJpbi0kKENPTkZJR19QVkhfR1VF
U1QpICs9IHB2aC1ib290LmluaXQubwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGwuUyBiL3hlbi9hcmNoL3g4Ni9ndWVz
dC94ZW4vaHlwZXJjYWxsLlMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg
MDAwMDAwMDAwMDAwLi40N2FiNjg1Y2Y4NDgKLS0tIC9kZXYvbnVsbAorKysg
Yi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbC5TCkBAIC0wLDAg
KzEsNTIgQEAKKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4w
LW9yLWxhdGVyICovCisKKyNpbmNsdWRlIDxhc20vYXNtX2RlZm5zLmg+CisK
KyAgICAgICAgLnNlY3Rpb24gLmluaXQudGV4dCwgImF4IiwgQHByb2diaXRz
CisKKyAgICAgICAgLyoKKyAgICAgICAgICogVXNlZCBkdXJpbmcgZWFybHkg
Ym9vdCwgYmVmb3JlIGFsdGVybmF0aXZlcyBoYXZlIHJ1biBhbmQgaW5saW5l
ZAorICAgICAgICAgKiB0aGUgYXBwcm9wcmlhdGUgaW5zdHJ1Y3Rpb24uICBD
YWxsZWQgdXNpbmcgdGhlIGh5cGVyY2FsbCBBQkkuCisgICAgICAgICAqLwor
RU5UUlkoZWFybHlfaHlwZXJjYWxsKQorICAgICAgICBjbXBiICAgICQwLCBl
YXJseV9oeXBlcmNhbGxfaW5zbiglcmlwKQorICAgICAgICBqbCAgICAgIC5M
X3NldHVwCisgICAgICAgIGplICAgICAgMWYKKworICAgICAgICB2bW1jYWxs
CisgICAgICAgIHJldAorCisxOiAgICAgIHZtY2FsbAorICAgICAgICByZXQK
KworLkxfc2V0dXA6CisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gc2V0
dGluZyB1cCB0aGUgZmlyc3QgdGltZSBhcm91bmQsIGFsbCByZWdpc3RlcnMg
bmVlZAorICAgICAgICAgKiBwcmVzZXJ2aW5nLiAgU2F2ZSB0aGUgbm9uLWNh
bGxlZS1zYXZlZCBvbmVzLgorICAgICAgICAgKi8KKyAgICAgICAgcHVzaCAg
ICAlcjExCisgICAgICAgIHB1c2ggICAgJXIxMAorICAgICAgICBwdXNoICAg
ICVyOQorICAgICAgICBwdXNoICAgICVyOAorICAgICAgICBwdXNoICAgICVy
ZGkKKyAgICAgICAgcHVzaCAgICAlcnNpCisgICAgICAgIHB1c2ggICAgJXJk
eAorICAgICAgICBwdXNoICAgICVyY3gKKyAgICAgICAgcHVzaCAgICAlcmF4
CisKKyAgICAgICAgY2FsbCAgICBlYXJseV9oeXBlcmNhbGxfc2V0dXAKKwor
ICAgICAgICBwb3AgICAgICVyYXgKKyAgICAgICAgcG9wICAgICAlcmN4Cisg
ICAgICAgIHBvcCAgICAgJXJkeAorICAgICAgICBwb3AgICAgICVyc2kKKyAg
ICAgICAgcG9wICAgICAlcmRpCisgICAgICAgIHBvcCAgICAgJXI4CisgICAg
ICAgIHBvcCAgICAgJXI5CisgICAgICAgIHBvcCAgICAgJXIxMAorICAgICAg
ICBwb3AgICAgICVyMTEKKworICAgICAgICBqbXAgICAgIGVhcmx5X2h5cGVy
Y2FsbAorCisgICAgICAgIC50eXBlIGVhcmx5X2h5cGVyY2FsbCwgQGZ1bmN0
aW9uCisgICAgICAgIC5zaXplIGVhcmx5X2h5cGVyY2FsbCwgLiAtIGVhcmx5
X2h5cGVyY2FsbApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2d1ZXN0L3hl
bi9oeXBlcmNhbGxfcGFnZS5TIGIveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi9o
eXBlcmNhbGxfcGFnZS5TCmRlbGV0ZWQgZmlsZSBtb2RlIDEwMDY0NAppbmRl
eCA5OTU4ZDAyY2ZkNWIuLjAwMDAwMDAwMDAwMAotLS0gYS94ZW4vYXJjaC94
ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbF9wYWdlLlMKKysrIC9kZXYvbnVsbApA
QCAtMSw3OCArMCwwIEBACi0jaW5jbHVkZSA8YXNtL3BhZ2UuaD4KLSNpbmNs
dWRlIDxhc20vYXNtX2RlZm5zLmg+Ci0jaW5jbHVkZSA8cHVibGljL3hlbi5o
PgotCi0gICAgICAgIC5zZWN0aW9uICIudGV4dC5wYWdlX2FsaWduZWQiLCAi
YXgiLCBAcHJvZ2JpdHMKLSAgICAgICAgLnAyYWxpZ24gUEFHRV9TSElGVAot
Ci1HTE9CQUwoaHlwZXJjYWxsX3BhZ2UpCi0gICAgICAgICAvKiBQb2lzb25l
ZCB3aXRoIGByZXRgIGZvciBzYWZldHkgYmVmb3JlIGh5cGVyY2FsbHMgYXJl
IHNldCB1cC4gKi8KLSAgICAgICAgLmZpbGwgUEFHRV9TSVpFLCAxLCAweGMz
Ci0gICAgICAgIC50eXBlIGh5cGVyY2FsbF9wYWdlLCBTVFRfT0JKRUNUCi0g
ICAgICAgIC5zaXplIGh5cGVyY2FsbF9wYWdlLCBQQUdFX1NJWkUKLQotLyoK
LSAqIElkZW50aWZ5IGEgc3BlY2lmaWMgaHlwZXJjYWxsIGluIHRoZSBoeXBl
cmNhbGwgcGFnZQotICogQHBhcmFtIG5hbWUgSHlwZXJjYWxsIG5hbWUuCi0g
Ki8KLSNkZWZpbmUgREVDTEFSRV9IWVBFUkNBTEwobmFtZSkgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAotICAg
ICAgICAuZ2xvYmwgSFlQRVJDQUxMXyAjIyBuYW1lOyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgIC50
eXBlICBIWVBFUkNBTExfICMjIG5hbWUsIFNUVF9GVU5DOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgLnNpemUgIEhZ
UEVSQ0FMTF8gIyMgbmFtZSwgMzI7ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXAotICAgICAgICAuc2V0ICAgSFlQRVJDQUxM
XyAjIyBuYW1lLCBoeXBlcmNhbGxfcGFnZSArIF9fSFlQRVJWSVNPUl8gIyMg
bmFtZSAqIDMyCi0KLURFQ0xBUkVfSFlQRVJDQUxMKHNldF90cmFwX3RhYmxl
KQotREVDTEFSRV9IWVBFUkNBTEwobW11X3VwZGF0ZSkKLURFQ0xBUkVfSFlQ
RVJDQUxMKHNldF9nZHQpCi1ERUNMQVJFX0hZUEVSQ0FMTChzdGFja19zd2l0
Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChzZXRfY2FsbGJhY2tzKQotREVDTEFS
RV9IWVBFUkNBTEwoZnB1X3Rhc2tzd2l0Y2gpCi1ERUNMQVJFX0hZUEVSQ0FM
TChzY2hlZF9vcF9jb21wYXQpCi1ERUNMQVJFX0hZUEVSQ0FMTChwbGF0Zm9y
bV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHNldF9kZWJ1Z3JlZykKLURFQ0xB
UkVfSFlQRVJDQUxMKGdldF9kZWJ1Z3JlZykKLURFQ0xBUkVfSFlQRVJDQUxM
KHVwZGF0ZV9kZXNjcmlwdG9yKQotREVDTEFSRV9IWVBFUkNBTEwobWVtb3J5
X29wKQotREVDTEFSRV9IWVBFUkNBTEwobXVsdGljYWxsKQotREVDTEFSRV9I
WVBFUkNBTEwodXBkYXRlX3ZhX21hcHBpbmcpCi1ERUNMQVJFX0hZUEVSQ0FM
TChzZXRfdGltZXJfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChldmVudF9jaGFu
bmVsX29wX2NvbXBhdCkKLURFQ0xBUkVfSFlQRVJDQUxMKHhlbl92ZXJzaW9u
KQotREVDTEFSRV9IWVBFUkNBTEwoY29uc29sZV9pbykKLURFQ0xBUkVfSFlQ
RVJDQUxMKHBoeXNkZXZfb3BfY29tcGF0KQotREVDTEFSRV9IWVBFUkNBTEwo
Z3JhbnRfdGFibGVfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTCh2bV9hc3Npc3Qp
Ci1ERUNMQVJFX0hZUEVSQ0FMTCh1cGRhdGVfdmFfbWFwcGluZ19vdGhlcmRv
bWFpbikKLURFQ0xBUkVfSFlQRVJDQUxMKGlyZXQpCi1ERUNMQVJFX0hZUEVS
Q0FMTCh2Y3B1X29wKQotREVDTEFSRV9IWVBFUkNBTEwoc2V0X3NlZ21lbnRf
YmFzZSkKLURFQ0xBUkVfSFlQRVJDQUxMKG1tdWV4dF9vcCkKLURFQ0xBUkVf
SFlQRVJDQUxMKHhzbV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKG5taV9vcCkK
LURFQ0xBUkVfSFlQRVJDQUxMKHNjaGVkX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoY2FsbGJhY2tfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTCh4ZW5vcHJvZl9v
cCkKLURFQ0xBUkVfSFlQRVJDQUxMKGV2ZW50X2NoYW5uZWxfb3ApCi1ERUNM
QVJFX0hZUEVSQ0FMTChwaHlzZGV2X29wKQotREVDTEFSRV9IWVBFUkNBTEwo
aHZtX29wKQotREVDTEFSRV9IWVBFUkNBTEwoc3lzY3RsKQotREVDTEFSRV9I
WVBFUkNBTEwoZG9tY3RsKQotREVDTEFSRV9IWVBFUkNBTEwoa2V4ZWNfb3Ap
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmdvX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoeGVucG11X29wKQotCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzApCi1E
RUNMQVJFX0hZUEVSQ0FMTChhcmNoXzEpCi1ERUNMQVJFX0hZUEVSQ0FMTChh
cmNoXzIpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzMpCi1ERUNMQVJFX0hZ
UEVSQ0FMTChhcmNoXzQpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzUpCi1E
RUNMQVJFX0hZUEVSQ0FMTChhcmNoXzYpCi1ERUNMQVJFX0hZUEVSQ0FMTChh
cmNoXzcpCi0KLS8qCi0gKiBMb2NhbCB2YXJpYWJsZXM6Ci0gKiB0YWItd2lk
dGg6IDgKLSAqIGluZGVudC10YWJzLW1vZGU6IG5pbAotICogRW5kOgotICov
CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL3hlbi5jIGIv
eGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94ZW4uYwppbmRleCA0NGE2ODlkNDM5
NGIuLjMwNmY4OGVmNmFkZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2d1
ZXN0L3hlbi94ZW4uYworKysgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL3hl
bi5jCkBAIC0yNiw3ICsyNiw2IEBACiBib29sIF9fcmVhZF9tb3N0bHkgeGVu
X2d1ZXN0OwogCiB1aW50MzJfdCBfX3JlYWRfbW9zdGx5IHhlbl9jcHVpZF9i
YXNlOwotZXh0ZXJuIGNoYXIgaHlwZXJjYWxsX3BhZ2VbXTsKIHN0YXRpYyBz
dHJ1Y3QgcmFuZ2VzZXQgKm1lbTsKIAogREVGSU5FX1BFUl9DUFUodW5zaWdu
ZWQgaW50LCB2Y3B1X2lkKTsKQEAgLTM1LDYgKzM0LDUwIEBAIHN0YXRpYyBz
dHJ1Y3QgdmNwdV9pbmZvICp2Y3B1X2luZm87CiBzdGF0aWMgdW5zaWduZWQg
bG9uZyB2Y3B1X2luZm9fbWFwcGVkW0JJVFNfVE9fTE9OR1MoTlJfQ1BVUyld
OwogREVGSU5FX1BFUl9DUFUoc3RydWN0IHZjcHVfaW5mbyAqLCB2Y3B1X2lu
Zm8pOwogCisvKgorICogV2hpY2ggaW5zdHJ1Y3Rpb24gdG8gdXNlIGZvciBl
YXJseSBoeXBlcmNhbGxzOgorICogICA8IDAgc2V0dXAKKyAqICAgICAwIHZt
Y2FsbAorICogICA+IDAgdm1tY2FsbAorICovCitpbnQ4X3QgX19pbml0ZGF0
YSBlYXJseV9oeXBlcmNhbGxfaW5zbiA9IC0xOworCisvKgorICogQ2FsbGVk
IG9uY2UgZHVyaW5nIHRoZSBmaXJzdCBoeXBlcmNhbGwgdG8gZmlndXJlIG91
dCB3aGljaCBpbnN0cnVjdGlvbiB0bworICogdXNlLiAgRXJyb3IgaGFuZGxp
bmcgb3B0aW9ucyBhcmUgbGltaXRlZC4KKyAqLwordm9pZCBfX2luaXQgZWFy
bHlfaHlwZXJjYWxsX3NldHVwKHZvaWQpCit7CisgICAgQlVHX09OKGVhcmx5
X2h5cGVyY2FsbF9pbnNuICE9IC0xKTsKKworICAgIGlmICggIWJvb3RfY3B1
X2RhdGEueDg2X3ZlbmRvciApCisgICAgeworICAgICAgICB1bnNpZ25lZCBp
bnQgZWF4LCBlYngsIGVjeCwgZWR4OworCisgICAgICAgIGNwdWlkKDAsICZl
YXgsICZlYngsICZlY3gsICZlZHgpOworCisgICAgICAgIGJvb3RfY3B1X2Rh
dGEueDg2X3ZlbmRvciA9IHg4Nl9jcHVpZF9sb29rdXBfdmVuZG9yKGVieCwg
ZWN4LCBlZHgpOworICAgIH0KKworICAgIHN3aXRjaCAoIGJvb3RfY3B1X2Rh
dGEueDg2X3ZlbmRvciApCisgICAgeworICAgIGNhc2UgWDg2X1ZFTkRPUl9J
TlRFTDoKKyAgICBjYXNlIFg4Nl9WRU5ET1JfQ0VOVEFVUjoKKyAgICBjYXNl
IFg4Nl9WRU5ET1JfU0hBTkdIQUk6CisgICAgICAgIGVhcmx5X2h5cGVyY2Fs
bF9pbnNuID0gMDsKKyAgICAgICAgc2V0dXBfZm9yY2VfY3B1X2NhcChYODZf
RkVBVFVSRV9VU0VfVk1DQUxMKTsKKyAgICAgICAgYnJlYWs7CisKKyAgICBj
YXNlIFg4Nl9WRU5ET1JfQU1EOgorICAgIGNhc2UgWDg2X1ZFTkRPUl9IWUdP
TjoKKyAgICAgICAgZWFybHlfaHlwZXJjYWxsX2luc24gPSAxOworICAgICAg
ICBicmVhazsKKworICAgIGRlZmF1bHQ6CisgICAgICAgIEJVRygpOworICAg
IH0KK30KKwogc3RhdGljIHZvaWQgX19pbml0IGZpbmRfeGVuX2xlYXZlcyh2
b2lkKQogewogICAgIHVpbnQzMl90IGVheCwgZWJ4LCBlY3gsIGVkeCwgYmFz
ZTsKQEAgLTMzNyw5ICszODAsNiBAQCBjb25zdCBzdHJ1Y3QgaHlwZXJ2aXNv
cl9vcHMgKl9faW5pdCB4Z19wcm9iZSh2b2lkKQogICAgIGlmICggIXhlbl9j
cHVpZF9iYXNlICkKICAgICAgICAgcmV0dXJuIE5VTEw7CiAKLSAgICAvKiBG
aWxsIHRoZSBoeXBlcmNhbGwgcGFnZS4gKi8KLSAgICB3cm1zcmwoY3B1aWRf
ZWJ4KHhlbl9jcHVpZF9iYXNlICsgMiksIF9fcGEoaHlwZXJjYWxsX3BhZ2Up
KTsKLQogICAgIHhlbl9ndWVzdCA9IHRydWU7CiAKICAgICByZXR1cm4gJm9w
czsKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVm
ZWF0dXJlcy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1
cmVzLmgKaW5kZXggYmEzZGYxNzRiNzZlLi45ZTNlZDIxYzAyNmQgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5o
CisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5o
CkBAIC00Miw2ICs0Miw3IEBAIFhFTl9DUFVGRUFUVVJFKFhFTl9TSFNUSywg
ICAgICAgICBYODZfU1lOVEgoMjYpKSAvKiBYZW4gdXNlcyBDRVQgU2hhZG93
IFN0YWNrcyAqCiBYRU5fQ1BVRkVBVFVSRShYRU5fSUJULCAgICAgICAgICAg
WDg2X1NZTlRIKDI3KSkgLyogWGVuIHVzZXMgQ0VUIEluZGlyZWN0IEJyYW5j
aCBUcmFja2luZyAqLwogWEVOX0NQVUZFQVRVUkUoSUJQQl9FTlRSWV9QViwg
ICAgIFg4Nl9TWU5USCgyOCkpIC8qIE1TUl9QUkVEX0NNRCB1c2VkIGJ5IFhl
biBmb3IgUFYgKi8KIFhFTl9DUFVGRUFUVVJFKElCUEJfRU5UUllfSFZNLCAg
ICBYODZfU1lOVEgoMjkpKSAvKiBNU1JfUFJFRF9DTUQgdXNlZCBieSBYZW4g
Zm9yIEhWTSAqLworWEVOX0NQVUZFQVRVUkUoVVNFX1ZNQ0FMTCwgICAgICAg
IFg4Nl9TWU5USCgzMCkpIC8qIFVzZSBWTUNBTEwgaW5zdGVhZCBvZiBWTU1D
QUxMICovCiAKIC8qIEJ1ZyB3b3JkcyBmb2xsb3cgdGhlIHN5bnRoZXRpYyB3
b3Jkcy4gKi8KICNkZWZpbmUgWDg2X05SX0JVRyAxCmRpZmYgLS1naXQgYS94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmggYi94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmgKaW5k
ZXggNjY1YjQ3MmQwNWFjLi45NjAwNGRlYzk5MDkgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaAorKysg
Yi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmgK
QEAgLTMwLDkgKzMwLDExIEBACiAgICAgKHsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgICAgIGxvbmcgcmVzLCB0bXBfXzsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGFz
bSB2b2xhdGlsZSAoICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICAiY2FsbCBoeXBlcmNh
bGxfcGFnZSArICVjW29mZnNldF0iICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCisgICAgICAgICAgICBBTFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5
cGVyY2FsbCIsICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICJ2bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVS
RV9VU0VfVk1DQUxMKSwgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICJ2bWNhbGwiLCBYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAg
ICBcCiAgICAgICAgICAgICA6ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSBB
U01fQ0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICBcCi0gICAgICAgICAg
ICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiksICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICA6ICIwIiAoaGNhbGwp
LCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcpKGExKSkgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgICh0eXBlKXJlczsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCkBAIC00MiwxMCArNDQsMTIgQEAKICAgICAoeyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICAgICAgbG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgYXNtIHZvbGF0aWxlICggICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgICJjYWxsIGh5
cGVyY2FsbF9wYWdlICsgJWNbb2Zmc2V0XSIgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICAgICAgICAgIEFMVEVSTkFUSVZFXzIoImNhbGwgZWFy
bHlfaHlwZXJjYWxsIiwgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgInZtbWNhbGwiLCBBTFRfTk9UKFg4Nl9G
RUFUVVJFX1VTRV9WTUNBTEwpLCAgIFwKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgInZtY2FsbCIsIFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwpICAgICAg
ICAgICAgIFwKICAgICAgICAgICAgIDogIj1hIiAocmVzKSwgIj1EIiAodG1w
X18pLCAiPVMiICh0bXBfXykgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgICAgICAgQVNNX0NBTExfQ09OU1RSQUlOVCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgIDogW29mZnNl
dF0gImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2FsbCksICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgICAgICAgIjEiICgobG9uZykoYTEpKSwgIjIiICgobG9uZykoYTIpKSAg
ICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9y
eSIgKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICAgICAgKHR5cGUpcmVzOyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKQEAgLTU1
LDEwICs1OSwxMiBAQAogICAgICh7ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAog
ICAgICAgICBsb25nIHJlcywgdG1wX187ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBhc20gdm9s
YXRpbGUgKCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAotICAgICAgICAgICAgImNhbGwgaHlwZXJjYWxsX3Bh
Z2UgKyAlY1tvZmZzZXRdIiAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICAgICAgQUxURVJOQVRJVkVfMigiY2FsbCBlYXJseV9oeXBlcmNh
bGwiLCAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAg
ICAgICAgICAgICAidm1tY2FsbCIsIEFMVF9OT1QoWDg2X0ZFQVRVUkVfVVNF
X1ZNQ0FMTCksICAgXAorICAgICAgICAgICAgICAgICAgICAgICAgICAidm1j
YWxsIiwgWDg2X0ZFQVRVUkVfVVNFX1ZNQ0FMTCkgICAgICAgICAgICAgXAog
ICAgICAgICAgICAgOiAiPWEiIChyZXMpLCAiPUQiICh0bXBfXyksICI9UyIg
KHRtcF9fKSwgIj1kIiAodG1wX18pICAgICAgXAogICAgICAgICAgICAgICBB
U01fQ0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAotICAgICAgICAgICAgOiBbb2Zmc2V0XSAiaSIgKGhj
YWxsICogMzIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICAgICAgOiAiMCIgKGhjYWxsKSwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAi
MSIgKChsb25nKShhMSkpLCAiMiIgKChsb25nKShhMikpLCAiMyIgKChsb25n
KShhMykpICAgICAgXAogICAgICAgICAgICAgOiAibWVtb3J5IiApOyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAog
ICAgICAgICAodHlwZSlyZXM7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXApAQCAtNjksMTAgKzc1LDEy
IEBACiAgICAgICAgIGxvbmcgcmVzLCB0bXBfXzsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIHJl
Z2lzdGVyIGxvbmcgX2E0IGFzbSAoInIxMCIpID0gKChsb25nKShhNCkpOyAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCi0gICAgICAgICAgICAiY2FsbCBoeXBlcmNhbGxfcGFnZSArICVjW29m
ZnNldF0iICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICBBTFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5cGVyY2FsbCIsICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICJ2bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSwg
ICBcCisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2bWNhbGwiLCBYODZf
RkVBVFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSwgIj1TIiAodG1wX18pLCAi
PWQiICh0bXBfXyksICAgICBcCiAgICAgICAgICAgICAgICI9JnIiICh0bXBf
XykgQVNNX0NBTExfQ09OU1RSQUlOVCAgICAgICAgICAgICAgICAgICAgICAg
ICBcCi0gICAgICAgICAgICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiks
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICA6ICIwIiAoaGNhbGwpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcp
KGExKSksICIyIiAoKGxvbmcpKGEyKSksICIzIiAoKGxvbmcpKGEzKSksICAg
ICBcCiAgICAgICAgICAgICAgICI0IiAoX2E0KSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-03.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-03.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IChNaXMpYWxpZ24gX194ODZfaW5kaXJlY3RfdGh1bmtf
KiB0byBtaXRpZ2F0ZSBJVFMKClRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRp
cmVjdApicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hl
biBpbiB0aGUgZmlyc3QgaGFsZiBvZiBhIGNhY2hlbGluZS4KCkFycmFuZ2Ug
Zm9yIF9feDg2X2luZGlyZWN0X3RodW5rXyogdG8gYWx3YXlzIGJlIGluIHRo
ZSBzZWNvbmQgaGFsZi4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDY5IC8gQ1ZF
LTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TCmluZGV4IGRlNmFlZjYwNjgzMi4uZTdlZjEwNGQzYmQz
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwor
KysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMzUsNiAr
MzUsMTYgQEAKIC5tYWNybyBHRU5fSU5ESVJFQ1RfVEhVTksgcmVnOnJlcQog
ICAgICAgICAuc2VjdGlvbiAudGV4dC5fX3g4Nl9pbmRpcmVjdF90aHVua19c
cmVnLCAiYXgiLCBAcHJvZ2JpdHMKIAorICAgICAgICAvKgorICAgICAgICAg
KiBUaGUgSW5kaXJlY3QgVGFyZ2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2
dWxuZXJhYmlsaXR5IG1lYW5zIHRoYXQKKyAgICAgICAgICogaW5kaXJlY3Qg
YnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUgdW5zYWZlIHdoZW4gaW4g
dGhlIGZpcnN0CisgICAgICAgICAqIGhhbGYgb2YgYSBjYWNoZWxpbmUuICBB
cnJhbmdlIGZvciB0aGVtIHRvIGJlIGluIHRoZSBzZWNvbmQgaGFsZi4KKyAg
ICAgICAgICoKKyAgICAgICAgICogQWxpZ24gdG8gNjQsIHRoZW4gc2tpcCAz
Mi4KKyAgICAgICAgICovCisgICAgICAgIC5iYWxpZ24gNjQKKyAgICAgICAg
LmZpbGwgMzIsIDEsIDB4Y2MKKwogRU5UUlkoX194ODZfaW5kaXJlY3RfdGh1
bmtfXHJlZykKICAgICAgICAgQUxURVJOQVRJVkVfMiBfX3N0cmluZ2lmeShJ
TkRfVEhVTktfUkVUUE9MSU5FIFxyZWcpLCAgICAgICAgICAgICAgXAogICAg
ICAgICBfX3N0cmluZ2lmeShJTkRfVEhVTktfTEZFTkNFIFxyZWcpLCBYODZf
RkVBVFVSRV9JTkRfVEhVTktfTEZFTkNFLCBcCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-04.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-04.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3RodW5rOiAoTWlzKWFsaWduIHRoZSBSRVRzIGlu
IGNsZWFyX2JoYl9sb29wcygpIHRvIG1pdGlnYXRlIElUUwoKVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0IGluZGlyZWN0CmJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdCBoYWxmIG9mIGEgY2Fj
aGVsaW5lLgoKY2xlYXJfYmhiX2xvb3BzKCkgaGFzIGEgcHJlY2lzZSBsYXlv
dXQgb2YgYnJhbmNoZXMuICBUaGUgYWxpZ25tZW50IGZvcgpwZXJmb3JtYW5j
ZSBjYXVzZSB0aGUgUkVUcyB0byBhbHdheXMgYmUgaW4gYW4gdW5zYWZlIHBv
c2l0aW9uLCBhbmQgY29udmVydGluZwp0aG9zZSB0byByZXR1cm4gdGh1bmtz
IGNoYW5nZXMgdGhlIGJyYW5jaGluZyBwYXR0ZXJuLiAgV2hpbGUgc3VjaCBh
IGNvbnZlcnNpb24KaXMgYmVsaWV2ZWQgdG8gYmUgc2FmZSwgY2xlYXJfYmhi
X2xvb3BzKCkgaXMgYWxzbyBhIHBlcmZvcm1hbmNlLXJlbGV2YW50CmZhc3Rw
YXRoLCBzbyAobWlzKWFsaWduIHRoZSBSRVRzIHRvIGJlIGluIGEgc2FmZSBw
b3NpdGlvbi4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0
IG9mIFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUyBi
L3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCA3ZTg2Njc4NGY3ODQu
LjA1ZjEwNDNkZjdkMCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2JoYi10
aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwpAQCAtNTIs
NyArNTIsMTIgQEAgRU5UUlkoY2xlYXJfYmhiX3RzeCkKICAqICAgcmV0CiAg
KgogICogVGhlIENBTEwvUkVUcyBhcmUgbmVjZXNzYXJ5IHRvIHByZXZlbnQg
dGhlIExvb3AgU3RyZWFtIERldGVjdG9yIGZyb20KLSAqIGludGVyZmVyaW5n
LiAgVGhlIGFsaWdubWVudCBpcyBmb3IgcGVyZm9ybWFuY2UgYW5kIG5vdCBz
YWZldHkuCisgKiBpbnRlcmZlcmluZy4KKyAqCisgKiBUaGUgLmJhbGlnbidz
IGFyZSBmb3IgcGVyZm9ybWFuY2UsIGJ1dCB0aGV5IGNhdXNlIHRoZSBSRVRz
IHRvIGJlIGluIHVuc2FmZQorICogcG9zaXRpb25zIHdpdGggcmVzcGVjdCB0
byBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uLiAgVGhlIC5za2lwcyBhcmUg
dG8KKyAqIG1vdmUgdGhlIFJFVHMgaW50byBJVFMtc2FmZSBwb3NpdGlvbnMs
IHJhdGhlciB0aGFuIHVzaW5nIHRoZSBzbG93cGF0aAorICogdGhyb3VnaCBf
X3g4Nl9yZXR1cm5fdGh1bmsuCiAgKgogICogVGhlICJzaG9ydCIgc2VxdWVu
Y2UgKDUgYW5kIDUpIGlzIGZvciBDUFVzIHByaW9yIHRvIEFsZGVyIExha2Ug
LyBTYXBwaGlyZQogICogUmFwaWRzIChpLmUuIENvcmVzIHByaW9yIHRvIEdv
bGRlbiBDb3ZlIGFuZC9vciBHcmFjZW1vbnQpLgpAQCAtNjgsMTIgKzczLDE0
IEBAIEVOVFJZKGNsZWFyX2JoYl9sb29wcykKICAgICAgICAgam1wICAgICA1
ZgogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAgICAg
IC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtICguTHIxIC0gMWYp
LCAweGNjCiAxOiAgICAgIGNhbGwgICAgMmYKLSAgICAgICAgcmV0CisuTHIx
OiAgIHJldAogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0Cisg
ICAgICAgIC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtIDE4IC8q
ICguTHIyIC0gMmYpIGJ1dCBDbGFuZyBJQVMgZG9lc24ndCBsaWtlIHRoaXMg
Ki8sIDB4Y2MKIDI6ICAgICAgQUxURVJOQVRJVkUgIm1vdiAkNSwgJWVheCIs
ICJtb3YgJDcsICVlYXgiLCBYODZfU1BFQ19CSEJfTE9PUFNfTE9ORwogCiAz
OiAgICAgIGptcCAgICAgNGYKQEAgLTg1LDcgKzkyLDcgQEAgRU5UUlkoY2xl
YXJfYmhiX2xvb3BzKQogICAgICAgICBzdWIgICAgICQxLCAlZWN4CiAgICAg
ICAgIGpueiAgICAgMWIKIAotICAgICAgICByZXQKKy5McjI6ICAgcmV0CiA1
OgogICAgICAgICAvKgogICAgICAgICAgKiBUaGUgSW50ZWwgc2VxdWVuY2Ug
aGFzIGFuIExGRU5DRSBoZXJlLiAgVGhlIHB1cnBvc2UgaXMgdG8gZW5zdXJl
Cg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-05.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-05.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3N0dWJzOiBJbnRyb2R1Y2UgcGxhY2VfcmV0KCkg
dG8gYWJzdHJhY3QgYXdheSByYXcgMHhjMydzCgpUaGUgSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5z
IHRoYXQgaW5kaXJlY3QKYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUg
dW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0IGhhbGYgb2YgYSBjYWNoZWxpbmUu
ClRoaXMgbWVhbnMgaXQncyBub3Qgc2FmZSBmb3IgbG9naWMgdXNpbmcgdGhl
IHN0dWJzIHRvIHdyaXRlIHJhdyAweGMzJ3MuCgpJbnRyb2R1Y2UgcGxhY2Vf
cmV0KCkgd2hpY2gsIGZvciBub3csIHdyaXRlcyBhIHJhdyAweGMzIGJ1dCB3
aWxsIGNvbnRhaW4KYWRkaXRpb25hbCBsb2dpYyB3aGVuIHJldHVybiB0aHVu
a3MgYXJlIGluIHVzZS4KCnN0dWJfc2VsZnRlc3QoKSBkb2Vzbid0IHN0cmlj
dGx5IG5lZWQgdG8gYmUgY29udmVydGVkIGFzIHRoZXkgb25seSBydW4gb24K
Ym9vdCwgYnV0IGRvaW5nIHNvIGdldHMgdXMgYSBwYXJ0aWFsIHRlc3Qgb2Yg
cGxhY2VfcmV0KCkgdG9vLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ2OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQt
b2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu
Y29tPgpSZXZpZXdlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvdG9vbHMvdGVzdHMveDg2X2Vt
dWxhdG9yL3g4Ni1lbXVsYXRlLmggYi90b29scy90ZXN0cy94ODZfZW11bGF0
b3IveDg2LWVtdWxhdGUuaAppbmRleCAzNGYwODU1MTE0OTcuLjE0ODNhNWE4
ODgwOSAxMDA2NDQKLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKKysrIGIvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKQEAgLTY4LDYgKzY4LDEyIEBACiAKICNkZWZpbmUgaXNf
Y2Fub25pY2FsX2FkZHJlc3MoeCkgKCgoaW50NjRfdCkoeCkgPj4gNDcpID09
ICgoaW50NjRfdCkoeCkgPj4gNjMpKQogCitzdGF0aWMgaW5saW5lIHZvaWQg
KnBsYWNlX3JldCh2b2lkICpwdHIpCit7CisgICAgKih1aW50OF90ICopcHRy
ID0gMHhjMzsKKyAgICByZXR1cm4gcHRyICsgMTsKK30KKwogZXh0ZXJuIHVp
bnQzMl90IG14Y3NyX21hc2s7CiBleHRlcm4gc3RydWN0IGNwdV9wb2xpY3kg
Y3A7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hl
bi9hcmNoL3g4Ni9NYWtlZmlsZQppbmRleCBlOGE0YmY1OWMzNGYuLjdkZjg3
N2EwOWQzZiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisr
KyBiL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtMTEsOSArMTEsNyBAQCBv
YmotJChDT05GSUdfUFYpICs9IHB2Lwogb2JqLXkgKz0geDg2XzY0Lwogb2Jq
LXkgKz0geDg2X2VtdWxhdGUvCiAKLWFsdGVybmF0aXZlLXkgOj0gYWx0ZXJu
YXRpdmUuaW5pdC5vCi1hbHRlcm5hdGl2ZS0kKENPTkZJR19MSVZFUEFUQ0gp
IDo9Ci1vYmotYmluLXkgKz0gJChhbHRlcm5hdGl2ZS15KQorb2JqLXkgKz0g
YWx0ZXJuYXRpdmUubwogb2JqLXkgKz0gYXBpYy5vCiBvYmoteSArPSBiaGIt
dGh1bmsubwogb2JqLXkgKz0gYml0b3BzLm8KQEAgLTQyLDcgKzQwLDcgQEAg
b2JqLXkgKz0gaHlwZXJjYWxsLm8KIG9iai15ICs9IGkzODcubwogb2JqLXkg
Kz0gaTgyNTkubwogb2JqLXkgKz0gaW9fYXBpYy5vCi1vYmotJChDT05GSUdf
TElWRVBBVENIKSArPSBhbHRlcm5hdGl2ZS5vIGxpdmVwYXRjaC5vCitvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9hbHRlcm5hdGl2ZS5jIGIveGVuL2FyY2gveDg2L2FsdGVybmF0
aXZlLmMKaW5kZXggOTBiZjlhOTJiZmY5Li5iZTE5NTc3MjM0NzIgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCkBAIC0xMzcsNiArMTM3LDIwIEBAIHZv
aWQgaW5pdF9vcl9saXZlcGF0Y2ggYWRkX25vcHModm9pZCAqaW5zbnMsIHVu
c2lnbmVkIGludCBsZW4pCiAgICAgfQogfQogCisvKgorICogUGxhY2UgYSBy
ZXR1cm4gYXQgQHB0ci4gIEBwdHIgbXVzdCBiZSBpbiB0aGUgd3JpdGFibGUg
YWxpYXMgb2YgYSBzdHViLgorICoKKyAqIFJldHVybnMgdGhlIG5leHQgcG9z
aXRpb24gdG8gd3JpdGUgaW50byB0aGUgc3R1Yi4KKyAqLwordm9pZCAqcGxh
Y2VfcmV0KHZvaWQgKnB0cikKK3sKKyAgICB1aW50OF90ICpwID0gcHRyOwor
CisgICAgKnArKyA9IDB4YzM7CisKKyAgICByZXR1cm4gcDsKK30KKwogLyoK
ICAqIHRleHRfcG9rZSAtIFVwZGF0ZSBpbnN0cnVjdGlvbnMgb24gYSBsaXZl
IGtlcm5lbCBvciBub24tZXhlY3V0ZWQgY29kZS4KICAqIEBhZGRyOiBhZGRy
ZXNzIHRvIG1vZGlmeQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2V4dGFi
bGUuYyBiL3hlbi9hcmNoL3g4Ni9leHRhYmxlLmMKaW5kZXggMTJjYzk5MzVk
ODg1Li4xNmJmMmNjNjJiODkgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9l
eHRhYmxlLmMKKysrIGIveGVuL2FyY2gveDg2L2V4dGFibGUuYwpAQCAtMTM1
LDIwICsxMzUsMjAgQEAgc2VhcmNoX2V4Y2VwdGlvbl90YWJsZShjb25zdCBz
dHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncywgdW5zaWduZWQgbG9uZyAqc3R1
Yl9yYSkKIGludCBfX2luaXQgY2ZfY2hlY2sgc3R1Yl9zZWxmdGVzdCh2b2lk
KQogewogICAgIHN0YXRpYyBjb25zdCBzdHJ1Y3QgewotICAgICAgICB1aW50
OF90IG9wY1s4XTsKKyAgICAgICAgdWludDhfdCBvcGNbN107CiAgICAgICAg
IHVpbnQ2NF90IHJheDsKICAgICAgICAgdW5pb24gc3R1Yl9leGNlcHRpb25f
dG9rZW4gcmVzOwogICAgIH0gdGVzdHNbXSBfX2luaXRjb25zdCA9IHsKICNk
ZWZpbmUgZW5kYnI2NCAweGYzLCAweDBmLCAweDFlLCAweGZhCi0gICAgICAg
IHsgLm9wYyA9IHsgZW5kYnI2NCwgMHgwZiwgMHhiOSwgMHhjMywgMHhjMyB9
LCAvKiB1ZDEgKi8KKyAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDBm
LCAweGI5LCAweDkwIH0sIC8qIHVkMSAqLwogICAgICAgICAgIC5yZXMuZmll
bGRzLnRyYXBuciA9IFg4Nl9FWENfVUQgfSwKLSAgICAgICAgeyAub3BjID0g
eyBlbmRicjY0LCAweDkwLCAweDAyLCAweDAwLCAweGMzIH0sIC8qIG5vcDsg
YWRkICglcmF4KSwlYWwgKi8KKyAgICAgICAgeyAub3BjID0geyBlbmRicjY0
LCAweDkwLCAweDAyLCAweDAwIH0sIC8qIG5vcDsgYWRkICglcmF4KSwlYWwg
Ki8KICAgICAgICAgICAucmF4ID0gMHgwMTIzNDU2Nzg5YWJjZGVmLAogICAg
ICAgICAgIC5yZXMuZmllbGRzLnRyYXBuciA9IFg4Nl9FWENfR1AgfSwKLSAg
ICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDAyLCAweDA0LCAweDA0LCAw
eGMzIH0sIC8qIGFkZCAoJXJzcCwlcmF4KSwlYWwgKi8KKyAgICAgICAgeyAu
b3BjID0geyBlbmRicjY0LCAweDAyLCAweDA0LCAweDA0IH0sIC8qIGFkZCAo
JXJzcCwlcmF4KSwlYWwgKi8KICAgICAgICAgICAucmF4ID0gMHhmZWRjYmE5
ODc2NTQzMjEwLAogICAgICAgICAgIC5yZXMuZmllbGRzLnRyYXBuciA9IFg4
Nl9FWENfU1MgfSwKLSAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweGNj
LCAweGMzLCAweGMzLCAweGMzIH0sIC8qIGludDMgKi8KKyAgICAgICAgeyAu
b3BjID0geyBlbmRicjY0LCAweGNjLCAweDkwLCAweDkwIH0sIC8qIGludDMg
Ki8KICAgICAgICAgICAucmVzLmZpZWxkcy50cmFwbnIgPSBYODZfRVhDX0JQ
IH0sCiAjdW5kZWYgZW5kYnI2NAogICAgIH07CkBAIC0xNjcsNiArMTY3LDcg
QEAgaW50IF9faW5pdCBjZl9jaGVjayBzdHViX3NlbGZ0ZXN0KHZvaWQpCiAK
ICAgICAgICAgbWVtc2V0KHB0ciwgMHhjYywgU1RVQl9CVUZfU0laRSAvIDIp
OwogICAgICAgICBtZW1jcHkocHRyLCB0ZXN0c1tpXS5vcGMsIEFSUkFZX1NJ
WkUodGVzdHNbaV0ub3BjKSk7CisgICAgICAgIHBsYWNlX3JldChwdHIgKyBB
UlJBWV9TSVpFKHRlc3RzW2ldLm9wYykpOwogICAgICAgICB1bm1hcF9kb21h
aW5fcGFnZShwdHIpOwogCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICJJTkRJ
UkVDVF9DQUxMICVbc3RiXVxuIgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2
L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmggYi94ZW4vYXJjaC94ODYvaW5j
bHVkZS9hc20vYWx0ZXJuYXRpdmUuaAppbmRleCA4OWI3YmRjYjgyZTUuLjg0
MWE2M2ViZjFiNiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLmgKQEAgLTMwLDYgKzMwLDggQEAgc3RydWN0IF9f
cGFja2VkIGFsdF9pbnN0ciB7CiAjZGVmaW5lIEFMVF9SRVBMX1BUUihhKSAg
ICAgX19BTFRfUFRSKGEsIHJlcGxfb2Zmc2V0KQogCiBleHRlcm4gdm9pZCBh
ZGRfbm9wcyh2b2lkICppbnNucywgdW5zaWduZWQgaW50IGxlbik7Cit2b2lk
ICpwbGFjZV9yZXQodm9pZCAqcHRyKTsKKwogLyogU2ltaWxhciB0byBhbHRl
cm5hdGl2ZV9pbnN0cnVjdGlvbnMgZXhjZXB0IGl0IGNhbiBiZSBydW4gd2l0
aCBJUlFzIGVuYWJsZWQuICovCiBleHRlcm4gaW50IGFwcGx5X2FsdGVybmF0
aXZlcyhzdHJ1Y3QgYWx0X2luc3RyICpzdGFydCwgc3RydWN0IGFsdF9pbnN0
ciAqZW5kKTsKIGV4dGVybiB2b2lkIGFsdGVybmF0aXZlX2luc3RydWN0aW9u
cyh2b2lkKTsKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXBy
aXYtb3AuYyBiL3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXByaXYtb3AuYwppbmRl
eCA3MDE1MGMyNzIyNzYuLmZmNWQxYzlmODYzNCAxMDA2NDQKLS0tIGEveGVu
L2FyY2gveDg2L3B2L2VtdWwtcHJpdi1vcC5jCisrKyBiL3hlbi9hcmNoL3g4
Ni9wdi9lbXVsLXByaXYtb3AuYwpAQCAtNzYsNyArNzYsNiBAQCBzdGF0aWMg
aW9fZW11bF9zdHViX3QgKmlvX2VtdWxfc3R1Yl9zZXR1cChzdHJ1Y3QgcHJp
dl9vcF9jdHh0ICpjdHh0LCB1OCBvcGNvZGUsCiAgICAgICAgIDB4NDEsIDB4
NWMsIC8qIHBvcCAlcjEyICAqLwogICAgICAgICAweDVkLCAgICAgICAvKiBw
b3AgJXJicCAgKi8KICAgICAgICAgMHg1YiwgICAgICAgLyogcG9wICVyYngg
ICovCi0gICAgICAgIDB4YzMsICAgICAgIC8qIHJldCAgICAgICAqLwogICAg
IH07CiAKICAgICBjb25zdCBzdHJ1Y3Qgc3R1YnMgKnRoaXNfc3R1YnMgPSAm
dGhpc19jcHUoc3R1YnMpOwpAQCAtMTI2LDExICsxMjUsMTMgQEAgc3RhdGlj
IGlvX2VtdWxfc3R1Yl90ICppb19lbXVsX3N0dWJfc2V0dXAoc3RydWN0IHBy
aXZfb3BfY3R4dCAqY3R4dCwgdTggb3Bjb2RlLAogCiAgICAgQVBQRU5EX0NB
TEwoc2F2ZV9ndWVzdF9ncHJzKTsKICAgICBBUFBFTkRfQlVGRihlcGlsb2d1
ZSk7CisgICAgcCA9IHBsYWNlX3JldChwKTsKIAogICAgIC8qIEJ1aWxkLXRp
bWUgYmVzdCBlZmZvcnQgYXR0ZW1wdCB0byBjYXRjaCBwcm9ibGVtcy4gKi8K
ICAgICBCVUlMRF9CVUdfT04oU1RVQl9CVUZfU0laRSAvIDIgPAogICAgICAg
ICAgICAgICAgICAoc2l6ZW9mKHByb2xvZ3VlKSArIHNpemVvZihlcGlsb2d1
ZSkgKyAxMCAvKiAyeCBjYWxsICovICsKLSAgICAgICAgICAgICAgICAgIE1B
WCgzIC8qIGRlZmF1bHQgc3R1YiAqLywgSU9FTVVMX1FVSVJLX1NUVUJfQllU
RVMpKSk7CisgICAgICAgICAgICAgICAgICBNQVgoMyAvKiBkZWZhdWx0IHN0
dWIgKi8sIElPRU1VTF9RVUlSS19TVFVCX0JZVEVTKSArCisgICAgICAgICAg
ICAgICAgICAxIC8qIHJldCAqLykpOwogICAgIC8qIFJ1bnRpbWUgY29uZmly
bWF0aW9uIHRoYXQgd2UgaGF2ZW4ndCBjbG9iYmVyZWQgYW4gYWRqYWNlbnQg
c3R1Yi4gKi8KICAgICBCVUdfT04oU1RVQl9CVUZfU0laRSAvIDIgPCAocCAt
IGN0eHQtPmlvX2VtdWxfc3R1YikpOwogCmRpZmYgLS1naXQgYS94ZW4vYXJj
aC94ODYveDg2X2VtdWxhdGUvZnB1LmMgYi94ZW4vYXJjaC94ODYveDg2X2Vt
dWxhdGUvZnB1LmMKaW5kZXggNDgwZDg3OTY1NzA1Li4wMzYxMmQwMGEyY2Ug
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfZW11bGF0ZS9mcHUuYwor
KysgYi94ZW4vYXJjaC94ODYveDg2X2VtdWxhdGUvZnB1LmMKQEAgLTMyLDM2
ICszMiw0MiBAQCBzdGF0aWMgaW5saW5lIGJvb2wgZnB1X2NoZWNrX3dyaXRl
KHZvaWQpCiAKICNkZWZpbmUgZW11bGF0ZV9mcHVfaW5zbl9tZW1kc3Qob3Bj
LCBleHQsIGFyZykgICAgICAgICAgICAgICAgICAgICAgICAgIFwKIGRvIHsg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICB2b2lkICpfcCA9IGdldF9z
dHViKHN0dWIpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICAvKiBNb2RSTTogbW9kPTAsIHJlZz1leHQsIHJtPTAs
IGkuZS4gYSAoJXJheCkgb3BlcmFuZCAqLyAgICAgICAgICAgIFwKICAgICAq
aW5zbl9ieXRlcyA9IDI7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICBtZW1jcHkoZ2V0X3N0dWIo
c3R1YiksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKLSAgICAgICAgICAgKCh1aW50OF90W10peyBvcGMsICgoZXh0
KSAmIDcpIDw8IDMsIDB4YzMgfSksIDMpOyAgICAgICAgICAgIFwKKyAgICBt
ZW1jcHkoX3AsICgodWludDhfdFtdKXsgb3BjLCAoKGV4dCkgJiA3KSA8PCAz
IH0pLCAyKTsgX3AgKz0gMjsgICAgIFwKKyAgICBwbGFjZV9yZXQoX3ApOyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKGFyZykg
OiAiYSIgKCYoYXJnKSkpOyAgICAgICAgICAgICAgICAgICAgIFwKICAgICBw
dXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKIH0gd2hpbGUgKDApCiAKICNkZWZp
bmUgZW11bGF0ZV9mcHVfaW5zbl9tZW1zcmMob3BjLCBleHQsIGFyZykgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKIGRvIHsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICB2b2lkICpfcCA9IGdldF9zdHViKHN0dWIpOyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAv
KiBNb2RSTTogbW9kPTAsIHJlZz1leHQsIHJtPTAsIGkuZS4gYSAoJXJheCkg
b3BlcmFuZCAqLyAgICAgICAgICAgIFwKLSAgICBtZW1jcHkoZ2V0X3N0dWIo
c3R1YiksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKLSAgICAgICAgICAgKCh1aW50OF90W10peyBvcGMsICgoZXh0
KSAmIDcpIDw8IDMsIDB4YzMgfSksIDMpOyAgICAgICAgICAgIFwKKyAgICBt
ZW1jcHkoX3AsICgodWludDhfdFtdKXsgb3BjLCAoKGV4dCkgJiA3KSA8PCAz
IH0pLCAyKTsgX3AgKz0gMjsgICAgIFwKKyAgICBwbGFjZV9yZXQoX3ApOyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKGR1bW15
KSA6ICJtIiAoYXJnKSwgImEiICgmKGFyZykpKTsgICAgICAgIFwKICAgICBw
dXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKIH0gd2hpbGUgKDApCiAKICNkZWZp
bmUgZW11bGF0ZV9mcHVfaW5zbl9zdHViKGJ5dGVzLi4uKSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKIGRvIHsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICB2b2lkICpfcCA9IGdldF9zdHViKHN0dWIpOyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICB1
bnNpZ25lZCBpbnQgbnJfID0gc2l6ZW9mKCh1aW50OF90W10peyBieXRlcyB9
KTsgICAgICAgICAgICAgICAgICAgIFwKLSAgICBtZW1jcHkoZ2V0X3N0dWIo
c3R1YiksICgodWludDhfdFtdKXsgYnl0ZXMsIDB4YzMgfSksIG5yXyArIDEp
OyAgICAgIFwKKyAgICBtZW1jcHkoX3AsICgodWludDhfdFtdKXsgYnl0ZXMg
fSksIG5yXyk7IF9wICs9IG5yXzsgICAgICAgICAgICAgICAgIFwKKyAgICBw
bGFjZV9yZXQoX3ApOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKICAgICBpbnZva2Vfc3R1YigiIiwg
IiIsICI9bSIgKGR1bW15KSA6ICJpIiAoMCkpOyAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICBwdXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKIH0gd2hp
bGUgKDApCiAKICNkZWZpbmUgZW11bGF0ZV9mcHVfaW5zbl9zdHViX2VmbGFn
cyhieXRlcy4uLikgICAgICAgICAgICAgICAgICAgICAgICAgIFwKIGRvIHsg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICB2b2lkICpfcCA9IGdldF9z
dHViKHN0dWIpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICB1bnNpZ25lZCBpbnQgbnJfID0gc2l6ZW9mKCh1aW50
OF90W10peyBieXRlcyB9KTsgICAgICAgICAgICAgICAgICAgIFwKICAgICB1
bnNpZ25lZCBsb25nIHRtcF87ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICBtZW1jcHkoZ2V0X3N0dWIo
c3R1YiksICgodWludDhfdFtdKXsgYnl0ZXMsIDB4YzMgfSksIG5yXyArIDEp
OyAgICAgIFwKKyAgICBtZW1jcHkoX3AsICgodWludDhfdFtdKXsgYnl0ZXMg
fSksIG5yXyk7IF9wICs9IG5yXzsgICAgICAgICAgICAgICAgIFwKKyAgICBw
bGFjZV9yZXQoX3ApOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKICAgICBpbnZva2Vfc3R1YihfUFJF
X0VGTEFHUygiW2VmbGFnc10iLCAiW21hc2tdIiwgIlt0bXBdIiksICAgICAg
ICAgICAgIFwKICAgICAgICAgICAgICAgICBfUE9TVF9FRkxBR1MoIltlZmxh
Z3NdIiwgIlttYXNrXSIsICJbdG1wXSIpLCAgICAgICAgICAgIFwKICAgICAg
ICAgICAgICAgICBbZWZsYWdzXSAiK2ciIChyZWdzLT5lZmxhZ3MpLCBbdG1w
XSAiPSZyIiAodG1wXykgICAgICAgIFwKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni94ODZfZW11bGF0ZS94ODZfZW11bGF0ZS5jIGIveGVuL2FyY2gveDg2
L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMKaW5kZXggZWYyNTk4ZDRjYTNm
Li5kZDViNjVhZmUwNjQgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZf
ZW11bGF0ZS94ODZfZW11bGF0ZS5jCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZf
ZW11bGF0ZS94ODZfZW11bGF0ZS5jCkBAIC0xMzk2LDcgKzEzOTYsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgc3RiWzNdID0gMHg5MTsKICAgICAgICAg
c3RiWzRdID0gZXZleC5vcG1zayA8PCAzOwogICAgICAgICBpbnNuX2J5dGVz
ID0gNTsKLSAgICAgICAgc3RiWzVdID0gMHhjMzsKKyAgICAgICAgcGxhY2Vf
cmV0KCZzdGJbNV0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwg
IittIiAob3BfbWFzaykgOiAiYSIgKCZvcF9tYXNrKSk7CiAKQEAgLTM2Mjcs
NyArMzYyNyw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICB9CiAgICAgICAg
IG9wY1sxXSA9IChtb2RybSAmIDB4MzgpIHwgMHhjMDsKICAgICAgICAgaW5z
bl9ieXRlcyA9IEVWRVhfUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJd
ID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAg
ICAgIGNvcHlfRVZFWChvcGMsIGV2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1
YigiIiwgIiIsICI9ZyIgKGR1bW15KSA6ICJhIiAoc3JjLnZhbCkpOwpAQCAt
MzY5NCw3ICszNjk0LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAgICBp
bnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMjsKICAgICAgICAgICAgIGNvcHlf
UkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIH0KLSAg
ICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNb
Ml0pOwogCiAgICAgICAgIGVhLnJlZyA9IGRlY29kZV9ncHIoJl9yZWdzLCBt
b2RybV9yZWcpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9YSIg
KCplYS5yZWcpIDogImMiIChtbXZhbHApLCAibSIgKCptbXZhbHApKTsKQEAg
LTM3NjgsNyArMzc2OCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAg
aW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDI7CiAgICAgICAgICAgICBjb3B5
X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2ZXgpOwogICAgICAgICB9Ci0g
ICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzJdKTsKIAogICAgICAgICBfcmVncy5lZmxhZ3MgJj0gfkVGTEFHU19NQVNL
OwogICAgICAgICBpbnZva2Vfc3R1YigiIiwKQEAgLTQwMDQsNyArNDAwNCw3
IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBvcGNbMV0gPSBtb2RybSAmIDB4
Yzc7CiAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwogICAg
IHNpbWRfMGZfdG9fZ3ByOgotICAgICAgICBvcGNbaW5zbl9ieXRlcyAtIFBG
WF9CWVRFU10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1tpbnNu
X2J5dGVzIC0gUEZYX0JZVEVTXSk7CiAKICAgICAgICAgZ2VuZXJhdGVfZXhj
ZXB0aW9uX2lmKGVhLnR5cGUgIT0gT1BfUkVHLCBYODZfRVhDX1VEKTsKIApA
QCAtNDQwMSw3ICs0NDAxLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAg
ICB2ZXgudyA9IDA7CiAgICAgICAgIG9wY1sxXSA9IG1vZHJtICYgMHgzODsK
ICAgICAgICAgaW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDI7Ci0gICAgICAg
IG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsK
IAogICAgICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2ZXgp
OwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKHNyYy52YWwp
IDogImEiICgmc3JjLnZhbCkpOwpAQCAtNDQzOCw3ICs0NDM4LDcgQEAgeDg2
X2VtdWxhdGUoCiAgICAgICAgICAgICBldmV4LncgPSAwOwogICAgICAgICBv
cGNbMV0gPSBtb2RybSAmIDB4Mzg7CiAgICAgICAgIGluc25fYnl0ZXMgPSBF
VkVYX1BGWF9CWVRFUyArIDI7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X0VW
RVgob3BjLCBldmV4KTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAi
K20iIChzcmMudmFsKSA6ICJhIiAoJnNyYy52YWwpKTsKQEAgLTQ2MzMsNyAr
NDYzMyw3IEBAIHg4Nl9lbXVsYXRlKAogI2VuZGlmIC8qIFg4NkVNVUxfTk9f
U0lNRCAqLwogCiAgICAgc2ltZF8wZl9yZWdfb25seToKLSAgICAgICAgb3Bj
W2luc25fYnl0ZXMgLSBQRlhfQllURVNdID0gMHhjMzsKKyAgICAgICAgcGxh
Y2VfcmV0KCZvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10pOwogCiAgICAg
ICAgIGNvcHlfUkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAg
ICAgIGludm9rZV9zdHViKCIiLCAiIiwgW2R1bW15X291dF0gIj1nIiAoZHVt
bXkpIDogW2R1bW15X2luXSAiaSIgKDApICk7CkBAIC00OTY3LDcgKzQ5Njcs
NyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgaWYgKCAhbW9kZV82NGJpdCgp
ICkKICAgICAgICAgICAgIHZleC53ID0gMDsKICAgICAgICAgb3BjWzFdID0g
bW9kcm0gJiAweGY4OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAg
ICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgY29weV9WRVgob3Bj
LCB2ZXgpOwogICAgICAgICBlYS5yZWcgPSBkZWNvZGVfZ3ByKCZfcmVncywg
bW9kcm1fcm0pOwpAQCAtNTAxMCw3ICs1MDEwLDcgQEAgeDg2X2VtdWxhdGUo
CiAgICAgICAgIGlmICggIW1vZGVfNjRiaXQoKSApCiAgICAgICAgICAgICB2
ZXgudyA9IDA7CiAgICAgICAgIG9wY1sxXSA9IG1vZHJtICYgMHhjNzsKLSAg
ICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNb
Ml0pOwogCiAgICAgICAgIGNvcHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAg
aW52b2tlX3N0dWIoIiIsICIiLCAiPWEiIChkc3QudmFsKSA6IFtkdW1teV0g
ImkiICgwKSk7CkBAIC01MDQwLDcgKzUwNDAsNyBAQCB4ODZfZW11bGF0ZSgK
ICAgICAgICAgb3BjID0gaW5pdF9wcmVmaXhlcyhzdHViKTsKICAgICAgICAg
b3BjWzBdID0gYjsKICAgICAgICAgb3BjWzFdID0gbW9kcm07Ci0gICAgICAg
IG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsK
IAogICAgICAgICBjb3B5X1ZFWChvcGMsIHZleCk7CiAgICAgICAgIF9yZWdz
LmVmbGFncyAmPSB+RUZMQUdTX01BU0s7CkBAIC01NjA4LDcgKzU2MDgsNyBA
QCB4ODZfZW11bGF0ZSgKICAgICAgICAgaWYgKCAhbW9kZV82NGJpdCgpICkK
ICAgICAgICAgICAgIHZleC53ID0gMDsKICAgICAgICAgb3BjWzFdID0gbW9k
cm0gJiAweGM3OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBw
bGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgY29weV9SRVhfVkVYKG9w
YywgcmV4X3ByZWZpeCwgdmV4KTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIs
ICIiLCAiPWEiIChlYS52YWwpIDogW2R1bW15XSAiaSIgKDApKTsKQEAgLTU3
MjYsNyArNTcyNiw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAgb3Bj
WzFdICY9IDB4Mzg7CiAgICAgICAgIH0KICAgICAgICAgaW5zbl9ieXRlcyA9
IFBGWF9CWVRFUyArIDI7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAg
ICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKICAgICAgICAgaWYgKCB2ZXgub3Bj
eCA9PSB2ZXhfbm9uZSApCiAgICAgICAgIHsKICAgICAgICAgICAgIC8qIENv
dmVyIGZvciBleHRyYSBwcmVmaXggYnl0ZS4gKi8KQEAgLTYwMDYsNyArNjAw
Niw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBwdmV4LT5iID0gIW1vZGVf
NjRiaXQoKSB8fCAodmV4LnJlZyA+PiAzKTsKICAgICAgICAgb3BjWzFdID0g
MHhjMCB8ICh+dmV4LnJlZyAmIDcpOwogICAgICAgICBwdmV4LT5yZWcgPSAw
eGY7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3Jl
dCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9
YSIgKGVhLnZhbCkgOiBbZHVtbXldICJpIiAoMCkpOwogICAgICAgICBwdXRf
c3R1YihzdHViKTsKQEAgLTYyOTAsNyArNjI5MCw3IEBAIHg4Nl9lbXVsYXRl
KAogICAgICAgICAgICAgZXZleC53ID0gMDsKICAgICAgICAgb3BjWzFdID0g
bW9kcm0gJiAweGY4OwogICAgICAgICBpbnNuX2J5dGVzID0gRVZFWF9QRlhf
QllURVMgKyAyOwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBw
bGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgY29weV9FVkVYKG9wYywg
ZXZleCk7CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1nIiAoZHVt
bXkpIDogImEiIChzcmMudmFsKSk7CkBAIC02Mzg5LDcgKzYzODksNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+YiA9IDE7CiAgICAgICAgIG9w
Y1sxXSA9IChtb2RybV9yZWcgJiA3KSA8PCAzOwogICAgICAgICBwdmV4LT5y
ZWcgPSAweGY7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBs
YWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwg
IiIsICI9bSIgKCptbXZhbHApIDogImEiIChtbXZhbHApKTsKIApAQCAtNjQ1
OSw3ICs2NDU5LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHB2ZXgtPmIg
PSAxOwogICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsK
ICAgICAgICAgcHZleC0+cmVnID0gMHhmOwotICAgICAgICBvcGNbMl0gPSAw
eGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAg
aW52b2tlX3N0dWIoIiIsICIiLCAiK20iICgqbW12YWxwKSA6ICJhIiAobW12
YWxwKSk7CiAKQEAgLTY1MTUsNyArNjUxNSw3IEBAIHg4Nl9lbXVsYXRlKAog
ICAgICAgICBwZXZleC0+YiA9IDE7CiAgICAgICAgIG9wY1sxXSA9IChtb2Ry
bV9yZWcgJiA3KSA8PCAzOwogICAgICAgICBwZXZleC0+UlggPSAxOwotICAg
ICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1sy
XSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiPW0iICgqbW12
YWxwKSA6ICJhIiAobW12YWxwKSk7CiAKQEAgLTY1ODAsNyArNjU4MCw3IEBA
IHg4Nl9lbXVsYXRlKAogICAgICAgICBwZXZleC0+YiA9IDE7CiAgICAgICAg
IG9wY1sxXSA9IChtb2RybV9yZWcgJiA3KSA8PCAzOwogICAgICAgICBwZXZl
eC0+UlggPSAxOwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBw
bGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIoIiIs
ICIiLCAiK20iICgqbW12YWxwKSA6ICJhIiAobW12YWxwKSk7CiAKQEAgLTY1
OTQsNyArNjU5NCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBvcGNbMl0g
PSAweDkwOwogICAgICAgICAvKiBVc2UgKCVyYXgpIGFzIHNvdXJjZS4gKi8K
ICAgICAgICAgb3BjWzNdID0gZXZleC5vcG1zayA8PCAzOwotICAgICAgICBv
cGNbNF0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1s0XSk7CiAK
ICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiK20iIChvcF9tYXNrKSA6
ICJhIiAoJm9wX21hc2spKTsKICAgICAgICAgcHV0X3N0dWIoc3R1Yik7CkBA
IC02Njg4LDcgKzY2ODgsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcGV2
ZXgtPmIgPSAxOwogICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykg
PDwgMzsKICAgICAgICAgcGV2ZXgtPlJYID0gMTsKLSAgICAgICAgb3BjWzJd
ID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAg
ICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1tIiAoKm1tdmFscCkgOiAiYSIg
KG1tdmFscCkpOwogCkBAIC02NzY2LDcgKzY3NjYsNyBAQCB4ODZfZW11bGF0
ZSgKICAgICAgICAgb3BjWzJdID0gMHg5MDsKICAgICAgICAgLyogVXNlICgl
cmF4KSBhcyBzb3VyY2UuICovCiAgICAgICAgIG9wY1szXSA9IGV2ZXgub3Bt
c2sgPDwgMzsKLSAgICAgICAgb3BjWzRdID0gMHhjMzsKKyAgICAgICAgcGxh
Y2VfcmV0KCZvcGNbNF0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAi
IiwgIittIiAob3BfbWFzaykgOiAiYSIgKCZvcF9tYXNrKSk7CiAgICAgICAg
IHB1dF9zdHViKHN0dWIpOwpAQCAtNjg0OCw3ICs2ODQ4LDcgQEAgeDg2X2Vt
dWxhdGUoCiAgICAgICAgIHBldmV4LT5yID0gIW1vZGVfNjRiaXQoKSB8fCAh
KHN0YXRlLT5zaWJfaW5kZXggJiAweDA4KTsKICAgICAgICAgcGV2ZXgtPlIg
PSAhbW9kZV82NGJpdCgpIHx8ICEoc3RhdGUtPnNpYl9pbmRleCAmIDB4MTAp
OwogICAgICAgICBwZXZleC0+UlggPSAxOwotICAgICAgICBvcGNbMl0gPSAw
eGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAg
aW52b2tlX3N0dWIoIiIsICIiLCAiPW0iIChpbmRleCkgOiAiYSIgKCZpbmRl
eCkpOwogICAgICAgICBwdXRfc3R1YihzdHViKTsKQEAgLTcwMjYsNyArNzAy
Niw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBwdmV4LT5yZWcgPSAweGY7
IC8qIHJBWCAqLwogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZb
NF0gPSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KLSAgICAgICAg
YnVmWzVdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwog
CiAgICAgICAgIHNyYy5yZWcgPSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAm
X3JlZ3MsIGN0eHQpOwogICAgICAgICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0m
YyIgKGRzdC52YWwpLCAiW2RzdF0iICgmc3JjLnZhbCksICJhIiAoKnNyYy5y
ZWcpKTsKQEAgLTcwNjIsNyArNzA2Miw3IEBAIHg4Nl9lbXVsYXRlKAogICAg
ICAgICBwdmV4LT5yZWcgPSAweGY7IC8qIHJBWCAqLwogICAgICAgICBidWZb
M10gPSBiOwogICAgICAgICBidWZbNF0gPSAobW9kcm0gJiAweDM4KSB8IDB4
MDE7IC8qIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgIGRzdC5y
ZWcgPSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3JlZ3MsIGN0eHQpOwog
ICAgICAgICBlbXVsYXRlX3N0dWIoIj0mYSIgKGRzdC52YWwpLCAiYyIgKCZz
cmMudmFsKSk7CkBAIC03MzAzLDcgKzczMDMsNyBAQCB4ODZfZW11bGF0ZSgK
ICAgICAgICAgICAgIGV2ZXgudyA9IHZleC53ID0gMDsKICAgICAgICAgb3Bj
WzFdID0gbW9kcm0gJiAweDM4OwogICAgICAgICBvcGNbMl0gPSBpbW0xOwot
ICAgICAgICBvcGNbM10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9w
Y1szXSk7CiAgICAgICAgIGlmICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQog
ICAgICAgICB7CiAgICAgICAgICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJl
Zml4IGJ5dGUuICovCkBAIC03NDcwLDcgKzc0NzAsNyBAQCB4ODZfZW11bGF0
ZSgKICAgICAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAzOwog
ICAgICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAgICAgICB9Ci0g
ICAgICAgIG9wY1szXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzNdKTsKIAogICAgICAgICAvKiBMYXRjaCBNWENTUiAtIHdlIG1heSBuZWVk
IHRvIHJlc3RvcmUgaXQgYmVsb3cuICovCiAgICAgICAgIGludm9rZV9zdHVi
KCJzdG14Y3NyICVbbXhjc3JdIiwgIiIsCkBAIC03NzE2LDcgKzc3MTYsNyBA
QCB4ODZfZW11bGF0ZSgKICAgICAgICAgfQogICAgICAgICBvcGNbMl0gPSBp
bW0xOwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMzsKLSAg
ICAgICAgb3BjWzNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNb
M10pOwogICAgICAgICBpZiAoIHZleC5vcGN4ID09IHZleF9ub25lICkKICAg
ICAgICAgewogICAgICAgICAgICAgLyogQ292ZXIgZm9yIGV4dHJhIHByZWZp
eCBieXRlLiAqLwpAQCAtODA1Niw3ICs4MDU2LDcgQEAgeDg2X2VtdWxhdGUo
CiAgICAgICAgIHB4b3AtPnJlZyA9IDB4ZjsgLyogckFYICovCiAgICAgICAg
IGJ1ZlszXSA9IGI7CiAgICAgICAgIGJ1Zls0XSA9IChtb2RybSAmIDB4Mzgp
IHwgMHgwMTsgLyogci9tPSglckNYKSAqLwotICAgICAgICBidWZbNV0gPSAw
eGMzOworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls1XSk7CiAKICAgICAgICAg
ZHN0LnJlZyA9IGRlY29kZV92ZXhfZ3ByKHZleC5yZWcsICZfcmVncywgY3R4
dCk7CiAgICAgICAgIGVtdWxhdGVfc3R1YihbZHN0XSAiPSZhIiAoZHN0LnZh
bCksICJjIiAoJnNyYy52YWwpKTsKQEAgLTgxNjUsNyArODE2NSw3IEBAIHg4
Nl9lbXVsYXRlKAogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZb
NF0gPSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KICAgICAgICAg
Kih1aW50MzJfdCAqKShidWYgKyA1KSA9IGltbTE7Ci0gICAgICAgIGJ1Zls5
XSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzldKTsKIAogICAg
ICAgICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0mYyIgKGRzdC52YWwpLCAiW2Rz
dF0iICgmc3JjLnZhbCkpOwogCkBAIC04MjU1LDEyICs4MjU1LDEyIEBAIHg4
Nl9lbXVsYXRlKAogICAgICAgICAgICAgQlVHKCk7CiAgICAgICAgIGlmICgg
ZXZleF9lbmNvZGVkKCkgKQogICAgICAgICB7Ci0gICAgICAgICAgICBvcGNb
aW5zbl9ieXRlcyAtIEVWRVhfUEZYX0JZVEVTXSA9IDB4YzM7CisgICAgICAg
ICAgICBwbGFjZV9yZXQoJm9wY1tpbnNuX2J5dGVzIC0gRVZFWF9QRlhfQllU
RVNdKTsKICAgICAgICAgICAgIGNvcHlfRVZFWChvcGMsIGV2ZXgpOwogICAg
ICAgICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgewotICAgICAgICAgICAg
b3BjW2luc25fYnl0ZXMgLSBQRlhfQllURVNdID0gMHhjMzsKKyAgICAgICAg
ICAgIHBsYWNlX3JldCgmb3BjW2luc25fYnl0ZXMgLSBQRlhfQllURVNdKTsK
ICAgICAgICAgICAgIGNvcHlfUkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZl
eCk7CiAgICAgICAgIH0KIAo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-06.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-06.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IEJ1aWxkIFhlbiB3aXRoIFJldHVybiBUaHVua3MKClRo
ZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uIHNwZWN1bGF0aXZlIHZ1bG5l
cmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRpcmVjdApicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QgaGFsZiBv
ZiBhIGNhY2hlbGluZS4KCkluIG9yZGVyIHRvIG1pdGlnYXRlIHRoaXMsIGJ1
aWxkIHdpdGggcmV0dXJuIHRodW5rcyBhbmQgYXJyYW5nZSBmb3IKX194ODZf
cmV0dXJuX3RodW5rIHRvIGJlIChtaXMpYWxpZ25lZCBpbiB0aGUgc2FtZSBt
YW5uZXIgYXMKX194ODZfaW5kaXJlY3RfdGh1bmtfKiBzbyB0aGUgUkVUIGlu
c3RydWN0aW9uIGlzIHBsYWNlZCBpbiBhIHNhZmUgbG9jYXRpb24uCgpwbGFj
ZV9yZXQoKSBuZWVkcyB0byBjb25kaXRpb25hbGx5IGVtaXQgSk1QIF9feDg2
X3JldHVybl90aHVuayBpbnN0ZWFkIG9mIFJFVC4KClRoaXMgaXMgcGFydCBv
ZiBYU0EtNDY5IC8gQ1ZFLTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnIGIveGVu
L2FyY2gveDg2L0tjb25maWcKaW5kZXggMWFjZGZmYzUxYzIyLi45NjExYjgw
NzYxOTcgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnCisrKyBi
L3hlbi9hcmNoL3g4Ni9LY29uZmlnCkBAIC0zNSw5ICszNSwxNCBAQCBjb25m
aWcgQVJDSF9ERUZDT05GSUcKIAlkZWZhdWx0ICJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCiAKIGNvbmZpZyBDQ19IQVNfSU5ESVJFQ1Rf
VEhVTksKKwkjIEdDQyA+PSA4IG9yIENsYW5nID49IDYKIAlkZWZfYm9vbCAk
KGNjLW9wdGlvbiwtbWluZGlyZWN0LWJyYW5jaC1yZWdpc3RlcikgfHwgXAog
CSAgICAgICAgICQoY2Mtb3B0aW9uLC1tcmV0cG9saW5lLWV4dGVybmFsLXRo
dW5rKQogCitjb25maWcgQ0NfSEFTX1JFVFVSTl9USFVOSworCSMgR0NDID49
IDggb3IgQ2xhbmcgPj0gMTUKKwlkZWZfYm9vbCAkKGNjLW9wdGlvbiwtbWZ1
bmN0aW9uLXJldHVybj10aHVuay1leHRlcm4pCisKIGNvbmZpZyBIQVNfQVNf
Q0VUX1NTCiAJIyBiaW51dGlscyA+PSAyLjI5IG9yIExMVk0gPj0gNgogCWRl
Zl9ib29sICQoYXMtaW5zdHIsd3Jzc3EgJXJheCQoY29tbWEpMDtzZXRzc2Jz
eSkKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hlbi9h
cmNoL3g4Ni9NYWtlZmlsZQppbmRleCA3ZGY4NzdhMDlkM2YuLmZjOTg0ZDYy
OWVkYiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisrKyBi
L3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtNDQsNiArNDQsNyBAQCBvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KK29iai0kKENPTkZJR19SRVRV
Uk5fVEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KIG9iai0kKENPTkZJR19Q
VikgKz0gaW9wb3J0X2VtdWxhdGUubwogb2JqLXkgKz0gaXJxLm8KIG9iai0k
KENPTkZJR19LRVhFQykgKz0gbWFjaGluZV9rZXhlYy5vCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJvdC5TIGIveGVuL2FyY2gv
eDg2L2FjcGkvd2FrZXVwX3Byb3QuUwppbmRleCA2NmY3OTkzMzk5MTMuLjk3
YmQ2NzZhYWVlMiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvd2Fr
ZXVwX3Byb3QuUworKysgYi94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJv
dC5TCkBAIC0xMzMsNyArMTMzLDcgQEAgRU5UUlkoczNfcmVzdW1lKQogICAg
ICAgICBwb3AgICAgICVyMTIKICAgICAgICAgcG9wICAgICAlcmJ4CiAgICAg
ICAgIHBvcCAgICAgJXJicAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAK
IC5kYXRhCiAgICAgICAgIC5hbGlnbiAxNgpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94ODYvYWx0ZXJuYXRp
dmUuYwppbmRleCBiZTE5NTc3MjM0NzIuLmNjYjk5ODVhNzY2ZSAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKKysrIGIveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTEzNywxNiArMTM3LDQ1IEBAIHZv
aWQgaW5pdF9vcl9saXZlcGF0Y2ggYWRkX25vcHModm9pZCAqaW5zbnMsIHVu
c2lnbmVkIGludCBsZW4pCiAgICAgfQogfQogCit2b2lkIG5vY2FsbCBfX3g4
Nl9yZXR1cm5fdGh1bmsodm9pZCk7CisKIC8qCiAgKiBQbGFjZSBhIHJldHVy
biBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGluIHRoZSB3cml0YWJsZSBhbGlh
cyBvZiBhIHN0dWIuCiAgKgorICogV2hlbiBDT05GSUdfUkVUVVJOX1RIVU5L
IGlzIGFjdGl2ZSwgdGhpcyBtYXkgYmUgYSBKTVAgX194ODZfcmV0dXJuX3Ro
dW5rCisgKiBpbnN0ZWFkLCBkZXBlbmRpbmcgb24gdGhlIHNhZmV0eSBvZiBA
cHRyIHdpdGggcmVzcGVjdCB0byBJbmRpcmVjdCBUYXJnZXQKKyAqIFNlbGVj
dGlvbi4KKyAqCiAgKiBSZXR1cm5zIHRoZSBuZXh0IHBvc2l0aW9uIHRvIHdy
aXRlIGludG8gdGhlIHN0dWIuCiAgKi8KIHZvaWQgKnBsYWNlX3JldCh2b2lk
ICpwdHIpCiB7CisgICAgdW5zaWduZWQgbG9uZyBhZGRyID0gKHVuc2lnbmVk
IGxvbmcpcHRyOwogICAgIHVpbnQ4X3QgKnAgPSBwdHI7CiAKLSAgICAqcCsr
ID0gMHhjMzsKKyAgICAvKgorICAgICAqIFdoZW4gUmV0dXJuIFRodW5rcyBh
cmUgdXNlZCwgaWYgYSBSRVQgd291bGQgYmUgdW5zYWZlIGF0IHRoaXMgbG9j
YXRpb24KKyAgICAgKiB3aXRoIHJlc3BlY3QgdG8gSW5kaXJlY3QgVGFyZ2V0
IFNlbGVjdGlvbiAoaS5lLiBpZiBhZGRyIGlzIGluIHRoZSBmaXJzdAorICAg
ICAqIGhhbGYgb2YgYSBjYWNoZWxpbmUpLCBpbnNlcnQgYSBKTVAgX194ODZf
cmV0dXJuX3RodW5rIGluc3RlYWQuCisgICAgICoKKyAgICAgKiBUaGUgZGlz
cGxhY2VtZW50IG5lZWRzIHRvIGJlIHJlbGF0aXZlIHRvIHRoZSBleGVjdXRh
YmxlIGFsaWFzIG9mIHRoZQorICAgICAqIHN0dWIsIG5vdCB0byBAcHRyIHdo
aWNoIGlzIHRoZSB3cml0ZWFibGUgYWxpYXMuCisgICAgICovCisgICAgaWYg
KCBJU19FTkFCTEVEKENPTkZJR19SRVRVUk5fVEhVTkspICYmICEoYWRkciAm
IDB4MjApICkKKyAgICB7CisgICAgICAgIGxvbmcgc3R1Yl92YSA9ICh0aGlz
X2NwdShzdHVicy5hZGRyKSAmIFBBR0VfTUFTSykgKyAoYWRkciAmIH5QQUdF
X01BU0spOworICAgICAgICBsb25nIGRpc3AgPSAobG9uZylfX3g4Nl9yZXR1
cm5fdGh1bmsgLSAoc3R1Yl92YSArIDUpOworCisgICAgICAgIEJVR19PTigo
aW50MzJfdClkaXNwICE9IGRpc3ApOworCisgICAgICAgICpwKysgPSAweGU5
OworICAgICAgICAqKGludDMyX3QgKilwID0gZGlzcDsKKyAgICAgICAgcCAr
PSA0OworICAgIH0KKyAgICBlbHNlCisgICAgeworICAgICAgICAqcCsrID0g
MHhjMzsKKyAgICB9CiAKICAgICByZXR1cm4gcDsKIH0KZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rIGIveGVuL2FyY2gveDg2L2FyY2gubWsK
aW5kZXggMjgyMTdjOWFjZTQ2Li4yMWE3NTNiNjM5NGUgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rCisrKyBiL3hlbi9hcmNoL3g4Ni9hcmNo
Lm1rCkBAIC00Niw2ICs0Niw5IEBAIENGTEFHUy0kKENPTkZJR19DQ19JU19H
Q0MpICs9IC1mbm8tanVtcC10YWJsZXMKIENGTEFHUy0kKENPTkZJR19DQ19J
U19DTEFORykgKz0gLW1yZXRwb2xpbmUtZXh0ZXJuYWwtdGh1bmsKIGVuZGlm
CiAKKyMgQ29tcGlsZSB3aXRoIHJldHVybiB0aHVuayBzdXBwb3J0IGlmIHNl
bGVjdGVkLgorQ0ZMQUdTLSQoQ09ORklHX1JFVFVSTl9USFVOSykgKz0gLW1m
dW5jdGlvbi1yZXR1cm49dGh1bmstZXh0ZXJuCisKICMgRGlzYWJsZSB0aGUg
YWRkaXRpb24gb2YgYSAubm90ZS5nbnUucHJvcGVydHkgc2VjdGlvbiB0byBv
YmplY3QgZmlsZXMgd2hlbgogIyBsaXZlcGF0Y2ggc3VwcG9ydCBpcyBlbmFi
bGVkLiAgVGhlIGNvbnRlbnRzIG9mIHRoYXQgc2VjdGlvbiBjYW4gY2hhbmdl
CiAjIGRlcGVuZGluZyBvbiB0aGUgaW5zdHJ1Y3Rpb25zIHVzZWQsIGFuZCBs
aXZlcGF0Y2gtYnVpbGQtdG9vbHMgZG9lc24ndCBrbm93CmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYmhiLXRodW5rLlMgYi94ZW4vYXJjaC94ODYvYmhi
LXRodW5rLlMKaW5kZXggMDVmMTA0M2RmN2QwLi40NzJkYTQ4MWRkNDIgMTAw
NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUworKysgYi94ZW4v
YXJjaC94ODYvYmhiLXRodW5rLlMKQEAgLTIzLDcgKzIzLDcgQEAgRU5UUlko
Y2xlYXJfYmhiX3RzeCkKIDA6ICAgICAgLmJ5dGUgMHhjNiwgMHhmOCwgMCAg
ICAgICAgICAgICAvKiB4YWJvcnQgJDAgKi8KICAgICAgICAgaW50MwogMToK
LSAgICAgICAgcmV0CisgICAgICAgIFJFVAogCiAgICAgICAgIC5zaXplIGNs
ZWFyX2JoYl90c3gsIC4gLSBjbGVhcl9iaGJfdHN4CiAgICAgICAgIC50eXBl
IGNsZWFyX2JoYl90c3gsIEBmdW5jdGlvbgpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L2NsZWFyX3BhZ2UuUyBiL3hlbi9hcmNoL3g4Ni9jbGVhcl9wYWdl
LlMKaW5kZXggNWI1NjIyY2M1MjZmLi5mZDRjOGMwYjJhMjggMTAwNjQ0Ci0t
LSBhL3hlbi9hcmNoL3g4Ni9jbGVhcl9wYWdlLlMKKysrIGIveGVuL2FyY2gv
eDg2L2NsZWFyX3BhZ2UuUwpAQCAtMSw1ICsxLDYgQEAKICAgICAgICAgLmZp
bGUgX19GSUxFX18KIAorI2luY2x1ZGUgPGFzbS9hc21fZGVmbnMuaD4KICNp
bmNsdWRlIDxhc20vcGFnZS5oPgogCiBFTlRSWShjbGVhcl9wYWdlX3NzZTIp
CkBAIC0xNSw3ICsxNiw3IEBAIEVOVFJZKGNsZWFyX3BhZ2Vfc3NlMikKICAg
ICAgICAgam56ICAgICAwYgogCiAgICAgICAgIHNmZW5jZQotICAgICAgICBy
ZXQKKyAgICAgICAgUkVUCiAKICAgICAgICAgLnR5cGUgY2xlYXJfcGFnZV9z
c2UyLCBAZnVuY3Rpb24KICAgICAgICAgLnNpemUgY2xlYXJfcGFnZV9zc2Uy
LCAuIC0gY2xlYXJfcGFnZV9zc2UyCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvY29weV9wYWdlLlMgYi94ZW4vYXJjaC94ODYvY29weV9wYWdlLlMKaW5k
ZXggZGRiNmUwZWJiYjZlLi4xODQxMjdjMTFkODYgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUworKysgYi94ZW4vYXJjaC94ODYvY29w
eV9wYWdlLlMKQEAgLTEsNSArMSw2IEBACiAgICAgICAgIC5maWxlIF9fRklM
RV9fCiAKKyNpbmNsdWRlIDxhc20vYXNtX2RlZm5zLmg+CiAjaW5jbHVkZSA8
YXNtL3BhZ2UuaD4KIAogI2RlZmluZSBzcmNfcmVnICVyc2kKQEAgLTQwLDcg
KzQxLDcgQEAgRU5UUlkoY29weV9wYWdlX3NzZTIpCiAgICAgICAgIG1vdm50
aSAgdG1wNF9yZWcsIDMqV09SRF9TSVpFKGRzdF9yZWcpCiAKICAgICAgICAg
c2ZlbmNlCi0gICAgICAgIHJldAorICAgICAgICBSRVQKIAogICAgICAgICAu
dHlwZSBjb3B5X3BhZ2Vfc3NlMiwgQGZ1bmN0aW9uCiAgICAgICAgIC5zaXpl
IGNvcHlfcGFnZV9zc2UyLCAuIC0gY29weV9wYWdlX3NzZTIKZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL3g4Ni9lZmkvY2hlY2suYyBiL3hlbi9hcmNoL3g4Ni9l
ZmkvY2hlY2suYwppbmRleCA5ZTQ3M2ZhYWQzYzkuLjIzYmEzMGFiZjMzMCAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2VmaS9jaGVjay5jCisrKyBiL3hl
bi9hcmNoL3g4Ni9lZmkvY2hlY2suYwpAQCAtMyw2ICszLDkgQEAgaW50IF9f
YXR0cmlidXRlX18oKF9fbXNfYWJpX18pKSB0ZXN0KGludCBpKQogICAgIHJl
dHVybiBpOwogfQogCisvKiBJbiBjYXNlIC1tZnVuY3Rpb24tcmV0dXJuIGlz
IGluIHVzZS4gKi8KK3ZvaWQgX194ODZfcmV0dXJuX3RodW5rKHZvaWQpIHt9
OworCiAvKgogICogUG9wdWxhdGUgYW4gYXJyYXkgd2l0aCAiYWRkcmVzc2Vz
IiBvZiByZWxvY2F0YWJsZSBhbmQgYWJzb2x1dGUgdmFsdWVzLgogICogVGhp
cyBpcyB0byBwcm9iZSBsZCBmb3IgKGEpIGVtaXR0aW5nIGJhc2UgcmVsb2Nh
dGlvbnMgYXQgYWxsIGFuZCAoYikgbm90CmRpZmYgLS1naXQgYS94ZW4vYXJj
aC94ODYvaW5jbHVkZS9hc20vYXNtLWRlZm5zLmggYi94ZW4vYXJjaC94ODYv
aW5jbHVkZS9hc20vYXNtLWRlZm5zLmgKaW5kZXggMzJkNmI0NDkxMDYzLi45
N2ViZTIxMjk4YTIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRl
L2FzbS9hc20tZGVmbnMuaAorKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9h
c20vYXNtLWRlZm5zLmgKQEAgLTU4LDYgKzU4LDEyIEBACiAgICAgLmVuZGlm
CiAuZW5kbQogCisjaWZkZWYgQ09ORklHX1JFVFVSTl9USFVOSworIyBkZWZp
bmUgUkVUIGptcCBfX3g4Nl9yZXR1cm5fdGh1bmsKKyNlbHNlCisjIGRlZmlu
ZSBSRVQgcmV0CisjZW5kaWYKKwogI2lmZGVmIENPTkZJR19YRU5fSUJUCiAj
IGRlZmluZSBFTkRCUjY0IGVuZGJyNjQKICNlbHNlCmRpZmYgLS1naXQgYS94
ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9p
bmRpcmVjdC10aHVuay5TCmluZGV4IGU3ZWYxMDRkM2JkMy4uMjM5Y2Y3ZGM3
NzBiIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsu
UworKysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMTEs
NiArMTEsOSBAQAogCiAjaW5jbHVkZSA8YXNtL2FzbV9kZWZucy5oPgogCisK
KyNpZmRlZiBDT05GSUdfSU5ESVJFQ1RfVEhVTksKKwogLm1hY3JvIElORF9U
SFVOS19SRVRQT0xJTkUgcmVnOnJlcQogICAgICAgICBjYWxsIDFmCiAgICAg
ICAgIGludDMKQEAgLTYwLDMgKzYzLDI3IEBAIEVOVFJZKF9feDg2X2luZGly
ZWN0X3RodW5rX1xyZWcpCiAuaXJwIHJlZywgYXgsIGN4LCBkeCwgYngsIGJw
LCBzaSwgZGksIDgsIDksIDEwLCAxMSwgMTIsIDEzLCAxNCwgMTUKICAgICAg
ICAgR0VOX0lORElSRUNUX1RIVU5LIHJlZz1yXHJlZwogLmVuZHIKKworI2Vu
ZGlmIC8qIENPTkZJR19JTkRJUkVDVF9USFVOSyAqLworCisjaWZkZWYgQ09O
RklHX1JFVFVSTl9USFVOSworICAgICAgICAuc2VjdGlvbiAudGV4dC5lbnRy
eS5fX3g4Nl9yZXR1cm5fdGh1bmssICJheCIsIEBwcm9nYml0cworCisgICAg
ICAgIC8qCisgICAgICAgICAqIFRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdAorICAg
ICAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFy
ZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QKKyAgICAgICAgICogaGFsZiBv
ZiBhIGNhY2hlbGluZS4gIEFycmFuZ2UgZm9yIHRoZW0gdG8gYmUgaW4gdGhl
IHNlY29uZCBoYWxmLgorICAgICAgICAgKgorICAgICAgICAgKiBBbGlnbiB0
byA2NCwgdGhlbiBza2lwIDMyLgorICAgICAgICAgKi8KKyAgICAgICAgLmJh
bGlnbiA2NAorICAgICAgICAuZmlsbCAzMiwgMSwgMHhjYworCitFTlRSWShf
X3g4Nl9yZXR1cm5fdGh1bmspCisgICAgICAgIHJldAorICAgICAgICBpbnQz
IC8qIEhhbHQgc3RyYWlnaHQtbGluZSBzcGVjdWxhdGlvbiAqLworCisgICAg
ICAgIC5zaXplIF9feDg2X3JldHVybl90aHVuaywgLiAtIF9feDg2X3JldHVy
bl90aHVuaworICAgICAgICAudHlwZSBfX3g4Nl9yZXR1cm5fdGh1bmssIEBm
dW5jdGlvbgorCisjZW5kaWYgLyogQ09ORklHX1JFVFVSTl9USFVOSyAqLwpk
aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3B2L2VtdWwtcHJpdi1vcC5jIGIv
eGVuL2FyY2gveDg2L3B2L2VtdWwtcHJpdi1vcC5jCmluZGV4IGZmNWQxYzlm
ODYzNC4uMjk1ZDg0N2VhMjRjIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYv
cHYvZW11bC1wcml2LW9wLmMKKysrIGIveGVuL2FyY2gveDg2L3B2L2VtdWwt
cHJpdi1vcC5jCkBAIC0xMzEsNyArMTMxLDcgQEAgc3RhdGljIGlvX2VtdWxf
c3R1Yl90ICppb19lbXVsX3N0dWJfc2V0dXAoc3RydWN0IHByaXZfb3BfY3R4
dCAqY3R4dCwgdTggb3Bjb2RlLAogICAgIEJVSUxEX0JVR19PTihTVFVCX0JV
Rl9TSVpFIC8gMiA8CiAgICAgICAgICAgICAgICAgIChzaXplb2YocHJvbG9n
dWUpICsgc2l6ZW9mKGVwaWxvZ3VlKSArIDEwIC8qIDJ4IGNhbGwgKi8gKwog
ICAgICAgICAgICAgICAgICAgTUFYKDMgLyogZGVmYXVsdCBzdHViICovLCBJ
T0VNVUxfUVVJUktfU1RVQl9CWVRFUykgKwotICAgICAgICAgICAgICAgICAg
MSAvKiByZXQgKi8pKTsKKyAgICAgICAgICAgICAgICAgIChJU19FTkFCTEVE
KENPTkZJR19SRVRVUk5fVEhVTkspID8gNSA6IDEpIC8qIHJldCAqLykpOwog
ICAgIC8qIFJ1bnRpbWUgY29uZmlybWF0aW9uIHRoYXQgd2UgaGF2ZW4ndCBj
bG9iYmVyZWQgYW4gYWRqYWNlbnQgc3R1Yi4gKi8KICAgICBCVUdfT04oU1RV
Ql9CVUZfU0laRSAvIDIgPCAocCAtIGN0eHQtPmlvX2VtdWxfc3R1YikpOwog
CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5TIGIv
eGVuL2FyY2gveDg2L3B2L2dwcl9zd2l0Y2guUwppbmRleCBlN2Y1YmZjZDJk
MDMuLmJmODMwYTc4ZjhhZSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3B2
L2dwcl9zd2l0Y2guUworKysgYi94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRj
aC5TCkBAIC0yNiwxMiArMjYsMTEgQEAgRU5UUlkobG9hZF9ndWVzdF9ncHJz
KQogICAgICAgICBtb3ZxICBVUkVHU19yMTUoJXJkaSksICVyMTUKICAgICAg
ICAgbW92cSAgVVJFR1NfcmN4KCVyZGkpLCAlcmN4CiAgICAgICAgIG1vdnEg
IFVSRUdTX3JkaSglcmRpKSwgJXJkaQotICAgICAgICByZXQKKyAgICAgICAg
UkVUCiAKICAgICAgICAgLnNpemUgbG9hZF9ndWVzdF9ncHJzLCAuIC0gbG9h
ZF9ndWVzdF9ncHJzCiAgICAgICAgIC50eXBlIGxvYWRfZ3Vlc3RfZ3Bycywg
U1RUX0ZVTkMKIAotCiAvKiBTYXZlIGd1ZXN0IEdQUnMuICBQYXJhbWV0ZXIg
b24gdGhlIHN0YWNrIGFib3ZlIHRoZSByZXR1cm4gYWRkcmVzcy4gKi8KIEVO
VFJZKHNhdmVfZ3Vlc3RfZ3BycykKICAgICAgICAgcHVzaHEgJXJkaQpAQCAt
NTEsNyArNTAsNyBAQCBFTlRSWShzYXZlX2d1ZXN0X2dwcnMpCiAgICAgICAg
IG1vdnEgICVyYngsIFVSRUdTX3JieCglcmRpKQogICAgICAgICBtb3ZxICAl
cmR4LCBVUkVHU19yZHgoJXJkaSkKICAgICAgICAgbW92cSAgJXJjeCwgVVJF
R1NfcmN4KCVyZGkpCi0gICAgICAgIHJldAorICAgICAgICBSRVQKIAogICAg
ICAgICAuc2l6ZSBzYXZlX2d1ZXN0X2dwcnMsIC4gLSBzYXZlX2d1ZXN0X2dw
cnMKICAgICAgICAgLnR5cGUgc2F2ZV9ndWVzdF9ncHJzLCBTVFRfRlVOQwpk
aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jIGIveGVuL2Fy
Y2gveDg2L3NwZWNfY3RybC5jCmluZGV4IDUxYTY2YTE0NGU2Yy4uOGRhYTI4
ZTFlYTk3IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMK
KysrIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCkBAIC01NjksNiArNTY5
LDkgQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2RldGFpbHMoZW51bSBp
bmRfdGh1bmsgdGh1bmspCiAjaWZkZWYgQ09ORklHX0lORElSRUNUX1RIVU5L
CiAgICAgICAgICAgICAgICAiIElORElSRUNUX1RIVU5LIgogI2VuZGlmCisj
aWZkZWYgQ09ORklHX1JFVFVSTl9USFVOSworICAgICAgICAgICAgICAgIiBS
RVRVUk5fVEhVTksiCisjZW5kaWYKICNpZmRlZiBDT05GSUdfU0hBRE9XX1BB
R0lORwogICAgICAgICAgICAgICAgIiBTSEFET1dfUEFHSU5HIgogI2VuZGlm
CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRy
eS5TIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwppbmRl
eCAzYzU0NGU5YTE0ZDYuLmRmYTExNTJiNjA0OSAxMDA2NDQKLS0tIGEveGVu
L2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUworKysgYi94ZW4vYXJj
aC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCkBAIC0xODMsNyArMTgzLDcg
QEAgRU5UUlkoY3I0X3B2MzJfcmVzdG9yZSkKICAgICAgICAgbW92ICAgJXJh
eCwgJWNyNAogICAgICAgICBtb3YgICAlcmF4LCAoJXJkeCkKICAgICAgICAg
cG9wICAgJXJkeAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAwOgogI2lm
bmRlZiBOREVCVUcKICAgICAgICAgLyogQ2hlY2sgdGhhdCBfYWxsXyBvZiB0
aGUgYml0cyBpbnRlbmRlZCB0byBiZSBzZXQgYWN0dWFsbHkgYXJlLiAqLwpA
QCAtMjAyLDcgKzIwMiw3IEBAIEVOVFJZKGNyNF9wdjMyX3Jlc3RvcmUpCiAj
ZW5kaWYKICAgICAgICAgcG9wICAgJXJkeAogICAgICAgICB4b3IgICAlZWF4
LCAlZWF4Ci0gICAgICAgIHJldAorICAgICAgICBSRVQKIAogRU5UUlkoY29t
cGF0X3N5c2NhbGwpCiAgICAgICAgIC8qIEZpeCB1cCByZXBvcnRlZCAlY3Mv
JXNzIGZvciBjb21wYXQgZG9tYWlucy4gKi8KQEAgLTMyOSw3ICszMjksNyBA
QCBfX1VOTElLRUxZX0VORChjb21wYXRfYm91bmNlX251bGxfc2VsZWN0b3Ip
CiAgICAgICAgIHhvciAgICVlYXgsICVlYXgKICAgICAgICAgbW92ICAgJWF4
LCAgVFJBUEJPVU5DRV9jcyglcmR4KQogICAgICAgICBtb3YgICAlYWwsICBU
UkFQQk9VTkNFX2ZsYWdzKCVyZHgpCi0gICAgICAgIHJldAorICAgICAgICBS
RVQKIAogLnNlY3Rpb24gLmZpeHVwLCJheCIKIC5MZngxMzoKZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUyBiL3hlbi9hcmNoL3g4
Ni94ODZfNjQvZW50cnkuUwppbmRleCBkZjNmM2I0ZWE3MjMuLmNjZjA1OGFl
NTU3NSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5T
CisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwpAQCAtNTk4LDcg
KzU5OCw3IEBAIF9fVU5MSUtFTFlfRU5EKGNyZWF0ZV9ib3VuY2VfZnJhbWVf
YmFkX2JvdW5jZV9pcCkKICAgICAgICAgeG9yICAgJWVheCwgJWVheAogICAg
ICAgICBtb3YgICAlcmF4LCBUUkFQQk9VTkNFX2VpcCglcmR4KQogICAgICAg
ICBtb3YgICAlYWwsICBUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCi0gICAgICAg
IHJldAorICAgICAgICBSRVQKIAogICAgICAgICAucHVzaHNlY3Rpb24gLmZp
eHVwLCAiYXgiLCBAcHJvZ2JpdHMKICAgICAgICAgIyBOdW1lcmljIHRhZ3Mg
YmVsb3cgcmVwcmVzZW50IHRoZSBpbnRlbmRlZCBvdmVyYWxsICVyc2kgYWRq
dXN0bWVudC4KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMg
Yi94ZW4vYXJjaC94ODYveGVuLmxkcy5TCmluZGV4IDg5MzBlMTRmYzQwZS4u
YjY2ZTcwOGViZjY5IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYveGVuLmxk
cy5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMKQEAgLTg2LDYgKzg2
LDcgQEAgU0VDVElPTlMKICAgICAgICAuID0gQUxJR04oUEFHRV9TSVpFKTsK
ICAgICAgICBfc3RleHRlbnRyeSA9IC47CiAgICAgICAgKigudGV4dC5lbnRy
eSkKKyAgICAgICAqKC50ZXh0LmVudHJ5LiopCiAgICAgICAgLiA9IEFMSUdO
KFBBR0VfU0laRSk7CiAgICAgICAgX2V0ZXh0ZW50cnkgPSAuOwogCmRpZmYg
LS1naXQgYS94ZW4vY29tbW9uL0tjb25maWcgYi94ZW4vY29tbW9uL0tjb25m
aWcKaW5kZXggMzM2MWE2ZDg5MjU3Li4yYzEwM2MyYzQ3MzYgMTAwNjQ0Ci0t
LSBhL3hlbi9jb21tb24vS2NvbmZpZworKysgYi94ZW4vY29tbW9uL0tjb25m
aWcKQEAgLTEyNyw2ICsxMjcsMTcgQEAgY29uZmlnIElORElSRUNUX1RIVU5L
CiAJICBXaGVuIGVuYWJsZWQsIGluZGlyZWN0IGJyYW5jaGVzIGFyZSBpbXBs
ZW1lbnRlZCB1c2luZyBhIG5ldyBjb25zdHJ1Y3QKIAkgIGNhbGxlZCAicmV0
cG9saW5lIiB0aGF0IHByZXZlbnRzIHNwZWN1bGF0aW9uLgogCitjb25maWcg
UkVUVVJOX1RIVU5LCisJYm9vbCAiT3V0LW9mLWxpbmUgUmV0dXJucyIKKwlk
ZXBlbmRzIG9uIENDX0hBU19SRVRVUk5fVEhVTksKKwlkZWZhdWx0IElORElS
RUNUX1RIVU5LCisJaGVscAorCSAgQ29tcGlsZSBYZW4gd2l0aCBvdXQtb2Yt
bGluZSByZXR1cm5zLgorCisJICBUaGlzIGFsbG93cyBYZW4gdG8gbWl0aWdh
dGUgYSB2YXJpZXR5IG9mIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdGllcwor
CSAgYnkgY2hvb3NpbmcgYSBoYXJkd2FyZS1kZXBlbmRlbnQgaW5zdHJ1Y3Rp
b24gc2VxdWVuY2UgdG8gaW1wbGVtZW50CisJICBmdW5jdGlvbiByZXR1cm5z
IHNhZmVseS4KKwogY29uZmlnIFNQRUNVTEFUSVZFX0hBUkRFTl9BUlJBWQog
CWJvb2wgIlNwZWN1bGF0aXZlIEFycmF5IEhhcmRlbmluZyIKIAlkZWZhdWx0
IHkK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-07.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-07.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogU3ludGhlc2lzZSBJVFNfTk8g
dG8gZ3Vlc3RzIG9uIHVuYWZmZWN0ZWQgaGFyZHdhcmUKCkl0IGlzIGVhc2ll
ciB0byBleHByZXNzIGZlYXR1cmUgd29yZCAxNyBpbiB0ZXJtcyBvZiB3b3Jk
IDE2ICsgWzMyLCA2NCkgYXMKdGhhdCdzIGhvdyB0aGUgbGF5b3V0IGlzIGdp
dmVuIGluIGRvY3VtZW50YXRpb24uCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2
OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29v
cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKaW5k
ZXggM2M1N2Y1NWRlMDc1Li4xMDQ4ZjE2ZTBjNjQgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKKysrIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaApAQCAtMjExLDYg
KzIxMSw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBib290X2NwdV9oYXModW5z
aWduZWQgaW50IGZlYXQpCiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAgICAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCiAjZGVmaW5l
IGNwdV9oYXNfcmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9SRkRTX05PKQogI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIgICAg
ICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKKyNkZWZp
bmUgY3B1X2hhc19pdHNfbm8gICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX0lUU19OTykKIAogLyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5l
IGNwdV9oYXNfYXJjaF9wZXJmbW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9BUkNIX1BFUkZNT04pCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg
OGRhYTI4ZTFlYTk3Li40NjY4MWQxMGFlOTYgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMKQEAgLTE3ODEsNiArMTc4MSw5MCBAQCBzdGF0aWMgdm9pZCBfX2lu
aXQgYmhpX2NhbGN1bGF0aW9ucyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAq
IGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZl
bG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1
aWRhbmNlL2Fkdmlzb3J5LWd1aWRhbmNlL2luZGlyZWN0LXRhcmdldC1zZWxl
Y3Rpb24uaHRtbAorICovCitzdGF0aWMgdm9pZCBfX2luaXQgaXRzX2NhbGN1
bGF0aW9ucyh2b2lkKQoreworICAgIC8qCisgICAgICogSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBpcyBhIEJyYW5jaCBQcmVkaWN0aW9uIGJ1ZyB3aGVy
ZWJ5IGNlcnRhaW4KKyAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGdldCBwcmVkaWN0ZWQgdXNpbmcgYSBkaXJlY3QgYnJhbmNo
CisgICAgICogdGFyZ2V0LCByYXRoZXIgdGhhbiBhIHN1aXRhYmxlIGluZGly
ZWN0IHRhcmdldCwgYnlwYXNzaW5nIGhhcmR3YXJlCisgICAgICogaXNvbGF0
aW9uIHByb3RlY3Rpb25zLgorICAgICAqCisgICAgICogSVRTIGFmZmVjdHMg
Q29yZSAoYnV0IG5vdCBBdG9tKSBwcm9jZXNzb3JzIHN0YXJ0aW5nIGZyb20g
dGhlCisgICAgICogaW50cm9kdWN0aW9uIG9mIGVJQlJTLCB1cCB0byBidXQg
bm90IGluY2x1ZGluZyBHb2xkZW4gQ292ZSBjb3JlcworICAgICAqIChjaGVj
a2VkIGhlcmUgd2l0aCBCSElfQ1RSTCkuCisgICAgICoKKyAgICAgKiBUaGUg
SVRTX05PIGZlYXR1cmUgaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVudW1lcmF0
ZWQgYnkgaGFyZHdhcmUsIGFuZCBpcworICAgICAqIG9ubHkgZm9yIFZNTXMg
dG8gc3ludGhlc2lzZSBmb3IgZ3Vlc3RzLgorICAgICAqCisgICAgICogSVRT
IGNvbWVzIGluIDMgZmxhdm91cnM6CisgICAgICoKKyAgICAgKiAgIDEpIEFj
cm9zcy1JQlBCLiAgSW5kaXJlY3QgYnJhbmNoZXMgYWZ0ZXIgdGhlIElCUEIg
Y2FuIGJlIGNvbnRyb2xsZWQKKyAgICAgKiAgICAgIGJ5IGRpcmVjdCB0YXJn
ZXRzIHdoaWNoIGV4aXN0ZWQgcHJpb3IgdG8gdGhlIElCUEIuICBUaGlzIGlz
CisgICAgICogICAgICBhZGRyZXNzZWQgaW4gdGhlIElQVSAyMDI1LjEgbWlj
cm9jb2RlIGRyb3AsIGFuZCBoYXMgbm8gb3RoZXIKKyAgICAgKiAgICAgIHNv
ZnR3YXJlIGludGVyYWN0aW9uLgorICAgICAqCisgICAgICogICAyKSBHdWVz
dC9Ib3N0LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgZGlyZWN0IHRhcmdldHMgZnJv
bSB0aGUgZ3Vlc3QuICBUaGlzIGFwcGxpZXMgZXF1YWxseSB0byBQViBndWVz
dHMKKyAgICAgKiAgICAgIChSaW5nMykgYW5kIEhWTSBndWVzdHMgKFZNWCks
IGFuZCBhcHBsaWVzIHRvIGFsbCBTa3lsYWtlLXVhcmNoCisgICAgICogICAg
ICBjb3JlcyB3aXRoIGVJQlJTLgorICAgICAqCisgICAgICogICAzKSBJbnRy
YS1tb2RlLiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgb3RoZXIgZXhlY3V0aW9uIGlu
IHRoZSBzYW1lIG1vZGUuCisgICAgICovCisKKyAgICAvKgorICAgICAqIElm
IHdlIGNhbiBzZWUgSVRTX05PLCBvciB3ZSdyZSB2aXJ0dWFsaXNlZCwgZG8g
bm90aGluZy4gIFdlIGFyZSBvciBtYXkKKyAgICAgKiBtaWdyYXRlIHNvbWV3
aGVyZSB1bnNhZmUuCisgICAgICovCisgICAgaWYgKCBjcHVfaGFzX2l0c19u
byB8fCBjcHVfaGFzX2h5cGVydmlzb3IgKQorICAgICAgICByZXR1cm47CisK
KyAgICAvKiBJVFMgaXMgb25seSBrbm93biB0byBhZmZlY3QgSW50ZWwgcHJv
Y2Vzc29ycyBhdCB0aGlzIHRpbWUuICovCisgICAgaWYgKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9JTlRFTCApCisgICAgICAg
IHJldHVybjsKKworICAgIC8qCisgICAgICogSVRTIGRvZXMgbm90IGV4aXN0
IG9uOgorICAgICAqICAtIG5vbi1GYW1pbHkgNiBDUFVzCisgICAgICogIC0g
dGhvc2Ugd2l0aG91dCBlSUJSUworICAgICAqICAtIHRob3NlIHdpdGggQkhJ
X0NUUkwKKyAgICAgKiBidXQgd2Ugc3RpbGwgbmVlZCB0byBzeW50aGVzaXNl
IElUU19OTy4KKyAgICAgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2
ICE9IDYgfHwgIWNwdV9oYXNfZWlicnMgfHwKKyAgICAgICAgIGJvb3RfY3B1
X2hhcyhYODZfRkVBVFVSRV9CSElfQ1RSTCkgKQorICAgICAgICBnb3RvIHN5
bnRoZXNpc2U7CisKKyAgICBzd2l0Y2ggKCBib290X2NwdV9kYXRhLng4Nl9t
b2RlbCApCisgICAgeworICAgICAgICAvKiBUaGVzZSBTa3lsYWtlLXVhcmNo
IGNvcmVzIHN1ZmZlciBjYXNlcyAjMiBhbmQgIzMuICovCisgICAgY2FzZSBJ
TlRFTF9GQU02X1NLWUxBS0VfWDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FC
WUxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0U6CisgICAg
Y2FzZSBJTlRFTF9GQU02X0NPTUVUTEFLRToKKyAgICBjYXNlIElOVEVMX0ZB
TTZfQ09NRVRMQUtFX0w6CisgICAgICAgIHJldHVybjsKKworICAgICAgICAv
KiBUaGVzZSBTdW5ueS9XaWxsb3cvQ3lwcmVzcyBDb3ZlIGNvcmVzIHN1ZmZl
ciBjYXNlICMzLiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9JQ0VMQUtFX1g6
CisgICAgY2FzZSBJTlRFTF9GQU02X0lDRUxBS0VfRDoKKyAgICBjYXNlIElO
VEVMX0ZBTTZfSUNFTEFLRV9MOgorICAgIGNhc2UgSU5URUxfRkFNNl9USUdF
UkxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfVElHRVJMQUtFOgorICAg
IGNhc2UgSU5URUxfRkFNNl9ST0NLRVRMQUtFOgorICAgICAgICByZXR1cm47
CisKKyAgICBkZWZhdWx0OgorICAgICAgICBicmVhazsKKyAgICB9CisKKyAg
ICAvKiBQbGF0Zm9ybXMgcmVtYWluaW5nIGFyZSBub3QgYmVsaWV2ZWQgdG8g
YmUgdnVsbmVyYWJsZSB0byBJVFMuICovCisgc3ludGhlc2lzZToKKyAgICBz
ZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX0lUU19OTyk7Cit9CisK
IHZvaWQgc3BlY19jdHJsX2luaXRfZG9tYWluKHN0cnVjdCBkb21haW4gKmQp
CiB7CiAgICAgYm9vbCBwdiA9IGlzX3B2X2RvbWFpbihkKTsKQEAgLTIzMzEs
NiArMjQxNSw4IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0
aWdhdGlvbnModm9pZCkKIAogICAgIGJoaV9jYWxjdWxhdGlvbnMoKTsKIAor
ICAgIGl0c19jYWxjdWxhdGlvbnMoKTsKKwogICAgIHByaW50X2RldGFpbHMo
dGh1bmspOwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IDYwM2E0NDhj
YjNkMi4uNmZhNzc3NzQwOTFkIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNs
dWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTM0NCw3
ICszNDQsOCBAQCBYRU5fQ1BVRkVBVFVSRShHRFNfTk8sICAgICAgICAgICAg
IDE2KjMyKzI2KSAvKkEgIE5vIEdhdGhlciBEYXRhIFNhbXBsaW5nICovCiBY
RU5fQ1BVRkVBVFVSRShSRkRTX05PLCAgICAgICAgICAgIDE2KjMyKzI3KSAv
KkEgIE5vIFJlZ2lzdGVyIEZpbGUgRGF0YSBTYW1wbGluZyAqLwogWEVOX0NQ
VUZFQVRVUkUoUkZEU19DTEVBUiwgICAgICAgICAxNiozMisyOCkgLyohQSBS
ZWdpc3RlciBGaWxlKHMpIGNsZWFyZWQgYnkgVkVSVyAqLwogCi0vKiBJbnRl
bC1kZWZpbmVkIENQVSBmZWF0dXJlcywgTVNSX0FSQ0hfQ0FQUyAweDEwYS5l
ZHgsIHdvcmQgMTcgKi8KKy8qIEludGVsLWRlZmluZWQgQ1BVIGZlYXR1cmVz
LCBNU1JfQVJDSF9DQVBTIDB4MTBhLmVkeCwgd29yZCAxNyAoZXhwcmVzcyBp
biB0ZXJtcyBvZiB3b3JkIDE2KSAqLworWEVOX0NQVUZFQVRVUkUoSVRTX05P
LCAgICAgICAgICAgICAxNiozMis2MikgLyohQSBObyBJbmRpcmVjdCBUYXJn
ZXQgU2VsZWN0aW9uICovCiAKICNlbmRpZiAvKiBYRU5fQ1BVRkVBVFVSRSAq
LwogCmRpZmYgLS1naXQgYS94ZW4vdG9vbHMvZ2VuLWNwdWlkLnB5IGIveGVu
L3Rvb2xzL2dlbi1jcHVpZC5weQppbmRleCA0MTVkNjQ0ZGI1MTkuLjYxZDIz
NjA1OGE3OCAxMDA3NTUKLS0tIGEveGVuL3Rvb2xzL2dlbi1jcHVpZC5weQor
KysgYi94ZW4vdG9vbHMvZ2VuLWNwdWlkLnB5CkBAIC01MSw3ICs1MSw3IEBA
IGRlZiBwYXJzZV9kZWZpbml0aW9ucyhzdGF0ZSk6CiAgICAgICAgIHIiXHMr
L1wqKFtcdyFdKikgLiokIikKIAogICAgIHdvcmRfcmVnZXggPSByZS5jb21w
aWxlKAotICAgICAgICByIl4vXCogLiogd29yZCAoXGQqKSBcKi8kIikKKyAg
ICAgICAgciJeL1wqIC4qIHdvcmQgKFxkKikgLipcKi8kIikKICAgICBsYXN0
X3dvcmQgPSAtMQogCiAgICAgdGhpcyA9IHN5cy5tb2R1bGVzW19fbmFtZV9f
XQo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-01.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-01.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2FsdGVybmF0aXZlOiBTdXBwb3J0IHJlcGxhY2Vt
ZW50cyB3aGVuIGEgZmVhdHVyZSBpcyBub3QgcHJlc2VudAoKVXNlIHRoZSB0
b3AgYml0IG9mIGEtPmNwdWlkIHRvIGV4cHJlc3MgaW52ZXJ0ZWQgcG9sYXJp
dHkuICBUaGlzIHJlcXVpcmVzCnN0cmlwcGluZyB0aGUgdG9wIGJpdCBiYWNr
IG91dCB3aGVuIHBlcmZvcm1pbmcgdGhlIHNhbml0eSBjaGVja3MuCgpEZXNw
aXRlIG9ubHkgYmVpbmcgdXNlZCBvbmNlLCBjcmVhdGUgYSByZXBsYWNlIGJv
b2xlYW4gdG8gZXhwcmVzcyB0aGUgZGVjaXNpb24KbW9yZSBjbGVhcmx5IGlu
IF9hcHBseV9hbHRlcm5hdGl2ZXMoKS4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0t
Z2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94
ODYvYWx0ZXJuYXRpdmUuYwppbmRleCAxYmEzNWNiOWVkZTkuLjg4YzkwMDQ0
YzIwZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMK
KysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTE5Nyw2ICsx
OTcsOCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBseV9h
bHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAgICAg
IHVpbnQ4X3QgKnJlcGwgPSBBTFRfUkVQTF9QVFIoYSk7CiAgICAgICAgIHVp
bnQ4X3QgYnVmW01BWF9QQVRDSF9MRU5dOwogICAgICAgICB1bnNpZ25lZCBp
bnQgdG90YWxfbGVuID0gYS0+b3JpZ19sZW4gKyBhLT5wYWRfbGVuOworICAg
ICAgICB1bnNpZ25lZCBpbnQgZmVhdCA9IGEtPmNwdWlkICYgfkFMVF9GTEFH
X05PVDsKKyAgICAgICAgYm9vbCBpbnYgPSBhLT5jcHVpZCAmIEFMVF9GTEFH
X05PVCwgcmVwbGFjZTsKIAogICAgICAgICBpZiAoIGEtPnJlcGxfbGVuID4g
dG90YWxfbGVuICkKICAgICAgICAgewpAQCAtMjE0LDExICsyMTYsMTEgQEAg
c3RhdGljIGludCBpbml0X29yX2xpdmVwYXRjaCBfYXBwbHlfYWx0ZXJuYXRp
dmVzKHN0cnVjdCBhbHRfaW5zdHIgKnN0YXJ0LAogICAgICAgICAgICAgcmV0
dXJuIC1FTk9TUEM7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAoIGEtPmNw
dWlkID49IE5DQVBJTlRTICogMzIgKQorICAgICAgICBpZiAoIGZlYXQgPj0g
TkNBUElOVFMgKiAzMiApCiAgICAgICAgIHsKICAgICAgICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUgogICAgICAgICAgICAgICAgICAgICJBbHQgZm9yICVw
cywgZmVhdHVyZSAlI3ggb3V0c2lkZSBvZiBmZWF0dXJlc2V0IHJhbmdlICUj
eFxuIiwKLSAgICAgICAgICAgICAgICAgICBBTFRfT1JJR19QVFIoYSksIGEt
PmNwdWlkLCBOQ0FQSU5UUyAqIDMyKTsKKyAgICAgICAgICAgICAgICAgICBB
TFRfT1JJR19QVFIoYSksIGZlYXQsIE5DQVBJTlRTICogMzIpOwogICAgICAg
ICAgICAgcmV0dXJuIC1FUkFOR0U7CiAgICAgICAgIH0KIApAQCAtMjQzLDgg
KzI0NSwxNCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAg
ICAgICAgICBjb250aW51ZTsKICAgICAgICAgfQogCisgICAgICAgIC8qCisg
ICAgICAgICAqIFNob3VsZCBhIHJlcGxhY2VtZW50IGJlIHBlcmZvcm1lZD8g
IE1vc3QgcmVwbGFjZW1lbnRzIGhhdmUgcG9zaXRpdmUKKyAgICAgICAgICog
cG9sYXJpdHksIGJ1dCB3ZSBzdXBwb3J0IG5lZ2F0aXZlIHBvbGFyaXR5IHRv
by4KKyAgICAgICAgICovCisgICAgICAgIHJlcGxhY2UgPSBib290X2NwdV9o
YXMoZmVhdCkgXiBpbnY7CisKICAgICAgICAgLyogSWYgdGhlcmUgaXMgbm8g
cmVwbGFjZW1lbnQgdG8gbWFrZSwgc2VlIGFib3V0IG9wdGltaXNpbmcgdGhl
IG5vcHMuICovCi0gICAgICAgIGlmICggIWJvb3RfY3B1X2hhcyhhLT5jcHVp
ZCkgKQorICAgICAgICBpZiAoICFyZXBsYWNlICkKICAgICAgICAgewogICAg
ICAgICAgICAgLyogT3JpZ2luIHNpdGUgc2l0ZSBhbHJlYWR5IHRvdWNoZWQ/
ICBEb24ndCBub3AgYW55dGhpbmcuICovCiAgICAgICAgICAgICBpZiAoIGJh
c2UtPnByaXYgKQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v
YWx0ZXJuYXRpdmUuaAppbmRleCA2OTU1NWQ3ODFlZjkuLjg5YjdiZGNiODJl
NSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKQEAgLTEsNiArMSwxMyBAQAogI2lmbmRlZiBfX1g4Nl9BTFRF
Uk5BVElWRV9IX18KICNkZWZpbmUgX19YODZfQUxURVJOQVRJVkVfSF9fCiAK
Ky8qCisgKiBDb21tb24gdG8gYm90aCBDIGFuZCBBU00uICBFeHByZXNzIGEg
cmVwbGFjZW1lbnQgd2hlbiBhIGZlYXR1cmUgaXMgbm90CisgKiBhdmFpbGFi
bGUuCisgKi8KKyNkZWZpbmUgQUxUX0ZMQUdfTk9UICgxIDw8IDE1KQorI2Rl
ZmluZSBBTFRfTk9UKHgpIChBTFRfRkxBR19OT1QgfCAoeCkpCisKICNpZmRl
ZiBfX0FTU0VNQkxZX18KICNpbmNsdWRlIDxhc20vYWx0ZXJuYXRpdmUtYXNt
Lmg+CiAjZWxzZQpAQCAtMTEsNyArMTgsNyBAQAogc3RydWN0IF9fcGFja2Vk
IGFsdF9pbnN0ciB7CiAgICAgaW50MzJfdCAgb3JpZ19vZmZzZXQ7ICAgLyog
b3JpZ2luYWwgaW5zdHJ1Y3Rpb24gKi8KICAgICBpbnQzMl90ICByZXBsX29m
ZnNldDsgICAvKiBvZmZzZXQgdG8gcmVwbGFjZW1lbnQgaW5zdHJ1Y3Rpb24g
Ki8KLSAgICB1aW50MTZfdCBjcHVpZDsgICAgICAgICAvKiBjcHVpZCBiaXQg
c2V0IGZvciByZXBsYWNlbWVudCAqLworICAgIHVpbnQxNl90IGNwdWlkOyAg
ICAgICAgIC8qIGNwdWlkIGJpdCBzZXQgZm9yIHJlcGxhY2VtZW50ICh0b3Ag
Yml0IGlzIHBvbGFyaXR5KSAqLwogICAgIHVpbnQ4X3QgIG9yaWdfbGVuOyAg
ICAgIC8qIGxlbmd0aCBvZiBvcmlnaW5hbCBpbnN0cnVjdGlvbiAqLwogICAg
IHVpbnQ4X3QgIHJlcGxfbGVuOyAgICAgIC8qIGxlbmd0aCBvZiBuZXcgaW5z
dHJ1Y3Rpb24gKi8KICAgICB1aW50OF90ICBwYWRfbGVuOyAgICAgICAvKiBs
ZW5ndGggb2YgYnVpbGQtdGltZSBwYWRkaW5nICovCgo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-02.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-02.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2d1ZXN0OiBSZW1vdmUgdXNlIG9mIHRoZSBYZW4g
aHlwZXJjYWxsX3BhZ2UKCkluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCBJ
VFMsIFhlbiBuZWVkcyB0byBzdGFydCB1c2luZyByZXR1cm4gdGh1bmtzLgpU
aGVyZWZvcmUgdGhlIGFkdmljZSBpbiBYU0EtNDY2IGJlY29tZXMgcmVsZXZh
bnQsIGFuZCB0aGUgaHlwZXJjYWxsX3BhZ2UgbmVlZHMKdG8gYmUgcmVtb3Zl
ZC4KCkltcGxlbWVudCBlYXJseV9oeXBlcmNhbGwoKSwgd2l0aCBpbmZyYXN0
cnVjdHVyZSB0byBmaWd1cmUgb3V0IHRoZSBjb3JyZWN0Cmluc3RydWN0aW9u
IG9uIGZpcnN0IHVzZS4gIFVzZSBBTFRFUk5BVElWRSgpcyB0byByZXN1bHQg
aW4gaW5saW5lIGh5cGVyY2FsbHMsCmluY2x1ZGluZyB0aGUgQUxUX05PVCgp
IGZvcm0gc28gd2Ugb25seSBuZWVkIGEgc2luZ2xlIHN5bnRoZXRpYyBmZWF0
dXJlIGJpdC4KCk5vIG92ZXJhbGwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0IG9m
IFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTogQW5k
cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3
ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9ndWVzdC94ZW4vTWFrZWZp
bGUgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCmluZGV4IDI2
ZmI0YjEwMDdjMC4uOGIzMjUwYWE4ODg2IDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCisrKyBiL3hlbi9hcmNoL3g4Ni9n
dWVzdC94ZW4vTWFrZWZpbGUKQEAgLTEsNCArMSw0IEBACi1vYmoteSArPSBo
eXBlcmNhbGxfcGFnZS5vCitvYmotYmluLXkgKz0gaHlwZXJjYWxsLmluaXQu
bwogb2JqLXkgKz0geGVuLm8KIAogb2JqLWJpbi0kKENPTkZJR19QVkhfR1VF
U1QpICs9IHB2aC1ib290LmluaXQubwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGwuUyBiL3hlbi9hcmNoL3g4Ni9ndWVz
dC94ZW4vaHlwZXJjYWxsLlMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg
MDAwMDAwMDAwMDAwLi4wNWU0Mjk3OTRjYzQKLS0tIC9kZXYvbnVsbAorKysg
Yi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbC5TCkBAIC0wLDAg
KzEsNTAgQEAKKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4w
LW9yLWxhdGVyICovCisKKyNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPgorCisg
ICAgICAgIC5zZWN0aW9uIC5pbml0LnRleHQsICJheCIsIEBwcm9nYml0cwor
CisgICAgICAgIC8qCisgICAgICAgICAqIFVzZWQgZHVyaW5nIGVhcmx5IGJv
b3QsIGJlZm9yZSBhbHRlcm5hdGl2ZXMgaGF2ZSBydW4gYW5kIGlubGluZWQK
KyAgICAgICAgICogdGhlIGFwcHJvcHJpYXRlIGluc3RydWN0aW9uLiAgQ2Fs
bGVkIHVzaW5nIHRoZSBoeXBlcmNhbGwgQUJJLgorICAgICAgICAgKi8KK0ZV
TkMoZWFybHlfaHlwZXJjYWxsKQorICAgICAgICBjbXBiICAgICQwLCBlYXJs
eV9oeXBlcmNhbGxfaW5zbiglcmlwKQorICAgICAgICBqbCAgICAgIC5MX3Nl
dHVwCisgICAgICAgIGplICAgICAgMWYKKworICAgICAgICB2bW1jYWxsCisg
ICAgICAgIHJldAorCisxOiAgICAgIHZtY2FsbAorICAgICAgICByZXQKKwor
Lkxfc2V0dXA6CisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gc2V0dGlu
ZyB1cCB0aGUgZmlyc3QgdGltZSBhcm91bmQsIGFsbCByZWdpc3RlcnMgbmVl
ZAorICAgICAgICAgKiBwcmVzZXJ2aW5nLiAgU2F2ZSB0aGUgbm9uLWNhbGxl
ZS1zYXZlZCBvbmVzLgorICAgICAgICAgKi8KKyAgICAgICAgcHVzaCAgICAl
cjExCisgICAgICAgIHB1c2ggICAgJXIxMAorICAgICAgICBwdXNoICAgICVy
OQorICAgICAgICBwdXNoICAgICVyOAorICAgICAgICBwdXNoICAgICVyZGkK
KyAgICAgICAgcHVzaCAgICAlcnNpCisgICAgICAgIHB1c2ggICAgJXJkeAor
ICAgICAgICBwdXNoICAgICVyY3gKKyAgICAgICAgcHVzaCAgICAlcmF4CisK
KyAgICAgICAgY2FsbCAgICBlYXJseV9oeXBlcmNhbGxfc2V0dXAKKworICAg
ICAgICBwb3AgICAgICVyYXgKKyAgICAgICAgcG9wICAgICAlcmN4CisgICAg
ICAgIHBvcCAgICAgJXJkeAorICAgICAgICBwb3AgICAgICVyc2kKKyAgICAg
ICAgcG9wICAgICAlcmRpCisgICAgICAgIHBvcCAgICAgJXI4CisgICAgICAg
IHBvcCAgICAgJXI5CisgICAgICAgIHBvcCAgICAgJXIxMAorICAgICAgICBw
b3AgICAgICVyMTEKKworICAgICAgICBqbXAgICAgIGVhcmx5X2h5cGVyY2Fs
bAorRU5EKGVhcmx5X2h5cGVyY2FsbCkKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUyBiL3hlbi9hcmNoL3g4
Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUwpkZWxldGVkIGZpbGUgbW9k
ZSAxMDA2NDQKaW5kZXggN2FiNTVmYzFmNmU2Li4wMDAwMDAwMDAwMDAKLS0t
IGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGxfcGFnZS5TCisr
KyAvZGV2L251bGwKQEAgLTEsNzYgKzAsMCBAQAotI2luY2x1ZGUgPGFzbS9w
YWdlLmg+Ci0jaW5jbHVkZSA8YXNtL2FzbV9kZWZucy5oPgotI2luY2x1ZGUg
PHB1YmxpYy94ZW4uaD4KLQotICAgICAgICAuc2VjdGlvbiAiLnRleHQucGFn
ZV9hbGlnbmVkIiwgImF4IiwgQHByb2diaXRzCi0KLURBVEEoaHlwZXJjYWxs
X3BhZ2UsIFBBR0VfU0laRSkKLSAgICAgICAgIC8qIFBvaXNvbmVkIHdpdGgg
YHJldGAgZm9yIHNhZmV0eSBiZWZvcmUgaHlwZXJjYWxscyBhcmUgc2V0IHVw
LiAqLwotICAgICAgICAuZmlsbCBQQUdFX1NJWkUsIDEsIDB4YzMKLUVORCho
eXBlcmNhbGxfcGFnZSkKLQotLyoKLSAqIElkZW50aWZ5IGEgc3BlY2lmaWMg
aHlwZXJjYWxsIGluIHRoZSBoeXBlcmNhbGwgcGFnZQotICogQHBhcmFtIG5h
bWUgSHlwZXJjYWxsIG5hbWUuCi0gKi8KLSNkZWZpbmUgREVDTEFSRV9IWVBF
UkNBTEwobmFtZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAotICAgICAgICAuZ2xvYmwgSFlQRVJDQUxMXyAj
IyBuYW1lOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBcCi0gICAgICAgIC50eXBlICBIWVBFUkNBTExfICMjIG5hbWUs
IFNUVF9GVU5DOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFwKLSAgICAgICAgLnNpemUgIEhZUEVSQ0FMTF8gIyMgbmFtZSwgMzI7ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAotICAg
ICAgICAuc2V0ICAgSFlQRVJDQUxMXyAjIyBuYW1lLCBoeXBlcmNhbGxfcGFn
ZSArIF9fSFlQRVJWSVNPUl8gIyMgbmFtZSAqIDMyCi0KLURFQ0xBUkVfSFlQ
RVJDQUxMKHNldF90cmFwX3RhYmxlKQotREVDTEFSRV9IWVBFUkNBTEwobW11
X3VwZGF0ZSkKLURFQ0xBUkVfSFlQRVJDQUxMKHNldF9nZHQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChzdGFja19zd2l0Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChz
ZXRfY2FsbGJhY2tzKQotREVDTEFSRV9IWVBFUkNBTEwoZnB1X3Rhc2tzd2l0
Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChzY2hlZF9vcF9jb21wYXQpCi1ERUNM
QVJFX0hZUEVSQ0FMTChwbGF0Zm9ybV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxM
KHNldF9kZWJ1Z3JlZykKLURFQ0xBUkVfSFlQRVJDQUxMKGdldF9kZWJ1Z3Jl
ZykKLURFQ0xBUkVfSFlQRVJDQUxMKHVwZGF0ZV9kZXNjcmlwdG9yKQotREVD
TEFSRV9IWVBFUkNBTEwobWVtb3J5X29wKQotREVDTEFSRV9IWVBFUkNBTEwo
bXVsdGljYWxsKQotREVDTEFSRV9IWVBFUkNBTEwodXBkYXRlX3ZhX21hcHBp
bmcpCi1ERUNMQVJFX0hZUEVSQ0FMTChzZXRfdGltZXJfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTChldmVudF9jaGFubmVsX29wX2NvbXBhdCkKLURFQ0xBUkVf
SFlQRVJDQUxMKHhlbl92ZXJzaW9uKQotREVDTEFSRV9IWVBFUkNBTEwoY29u
c29sZV9pbykKLURFQ0xBUkVfSFlQRVJDQUxMKHBoeXNkZXZfb3BfY29tcGF0
KQotREVDTEFSRV9IWVBFUkNBTEwoZ3JhbnRfdGFibGVfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh2bV9hc3Npc3QpCi1ERUNMQVJFX0hZUEVSQ0FMTCh1cGRh
dGVfdmFfbWFwcGluZ19vdGhlcmRvbWFpbikKLURFQ0xBUkVfSFlQRVJDQUxM
KGlyZXQpCi1ERUNMQVJFX0hZUEVSQ0FMTCh2Y3B1X29wKQotREVDTEFSRV9I
WVBFUkNBTEwoc2V0X3NlZ21lbnRfYmFzZSkKLURFQ0xBUkVfSFlQRVJDQUxM
KG1tdWV4dF9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHhzbV9vcCkKLURFQ0xB
UkVfSFlQRVJDQUxMKG5taV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHNjaGVk
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoY2FsbGJhY2tfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh4ZW5vcHJvZl9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKGV2
ZW50X2NoYW5uZWxfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChwaHlzZGV2X29w
KQotREVDTEFSRV9IWVBFUkNBTEwoaHZtX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoc3lzY3RsKQotREVDTEFSRV9IWVBFUkNBTEwoZG9tY3RsKQotREVDTEFS
RV9IWVBFUkNBTEwoa2V4ZWNfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmdv
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoeGVucG11X29wKQotCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzEp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzIpCi1ERUNMQVJFX0hZUEVSQ0FM
TChhcmNoXzMpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzUpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzYp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzcpCi0KLS8qCi0gKiBMb2NhbCB2
YXJpYWJsZXM6Ci0gKiB0YWItd2lkdGg6IDgKLSAqIGluZGVudC10YWJzLW1v
ZGU6IG5pbAotICogRW5kOgotICovCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvZ3Vlc3QveGVuL3hlbi5jIGIveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94
ZW4uYwppbmRleCA3NDg0YjNmNzNhZDMuLjJjMzBkYjA1ZGZhNyAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94ZW4uYworKysgYi94ZW4v
YXJjaC94ODYvZ3Vlc3QveGVuL3hlbi5jCkBAIC0yNiw3ICsyNiw2IEBACiBi
b29sIF9fcmVhZF9tb3N0bHkgeGVuX2d1ZXN0OwogCiB1aW50MzJfdCBfX3Jl
YWRfbW9zdGx5IHhlbl9jcHVpZF9iYXNlOwotZXh0ZXJuIGNoYXIgaHlwZXJj
YWxsX3BhZ2VbXTsKIHN0YXRpYyBzdHJ1Y3QgcmFuZ2VzZXQgKm1lbTsKIAog
REVGSU5FX1BFUl9DUFUodW5zaWduZWQgaW50LCB2Y3B1X2lkKTsKQEAgLTM1
LDYgKzM0LDUwIEBAIHN0YXRpYyBzdHJ1Y3QgdmNwdV9pbmZvICp2Y3B1X2lu
Zm87CiBzdGF0aWMgdW5zaWduZWQgbG9uZyB2Y3B1X2luZm9fbWFwcGVkW0JJ
VFNfVE9fTE9OR1MoTlJfQ1BVUyldOwogREVGSU5FX1BFUl9DUFUoc3RydWN0
IHZjcHVfaW5mbyAqLCB2Y3B1X2luZm8pOwogCisvKgorICogV2hpY2ggaW5z
dHJ1Y3Rpb24gdG8gdXNlIGZvciBlYXJseSBoeXBlcmNhbGxzOgorICogICA8
IDAgc2V0dXAKKyAqICAgICAwIHZtY2FsbAorICogICA+IDAgdm1tY2FsbAor
ICovCitpbnQ4X3QgX19pbml0ZGF0YSBlYXJseV9oeXBlcmNhbGxfaW5zbiA9
IC0xOworCisvKgorICogQ2FsbGVkIG9uY2UgZHVyaW5nIHRoZSBmaXJzdCBo
eXBlcmNhbGwgdG8gZmlndXJlIG91dCB3aGljaCBpbnN0cnVjdGlvbiB0bwor
ICogdXNlLiAgRXJyb3IgaGFuZGxpbmcgb3B0aW9ucyBhcmUgbGltaXRlZC4K
KyAqLwordm9pZCBhc21saW5rYWdlIF9faW5pdCBlYXJseV9oeXBlcmNhbGxf
c2V0dXAodm9pZCkKK3sKKyAgICBCVUdfT04oZWFybHlfaHlwZXJjYWxsX2lu
c24gIT0gLTEpOworCisgICAgaWYgKCAhYm9vdF9jcHVfZGF0YS54ODZfdmVu
ZG9yICkKKyAgICB7CisgICAgICAgIHVuc2lnbmVkIGludCBlYXgsIGVieCwg
ZWN4LCBlZHg7CisKKyAgICAgICAgY3B1aWQoMCwgJmVheCwgJmVieCwgJmVj
eCwgJmVkeCk7CisKKyAgICAgICAgYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ID0geDg2X2NwdWlkX2xvb2t1cF92ZW5kb3IoZWJ4LCBlY3gsIGVkeCk7Cisg
ICAgfQorCisgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ICkKKyAgICB7CisgICAgY2FzZSBYODZfVkVORE9SX0lOVEVMOgorICAgIGNh
c2UgWDg2X1ZFTkRPUl9DRU5UQVVSOgorICAgIGNhc2UgWDg2X1ZFTkRPUl9T
SEFOR0hBSToKKyAgICAgICAgZWFybHlfaHlwZXJjYWxsX2luc24gPSAwOwor
ICAgICAgICBzZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpOworICAgICAgICBicmVhazsKKworICAgIGNhc2UgWDg2X1ZFTkRP
Ul9BTUQ6CisgICAgY2FzZSBYODZfVkVORE9SX0hZR09OOgorICAgICAgICBl
YXJseV9oeXBlcmNhbGxfaW5zbiA9IDE7CisgICAgICAgIGJyZWFrOworCisg
ICAgZGVmYXVsdDoKKyAgICAgICAgQlVHKCk7CisgICAgfQorfQorCiBzdGF0
aWMgdm9pZCBfX2luaXQgZmluZF94ZW5fbGVhdmVzKHZvaWQpCiB7CiAgICAg
dWludDMyX3QgZWF4LCBlYngsIGVjeCwgZWR4LCBiYXNlOwpAQCAtMzM3LDkg
KzM4MCw2IEBAIGNvbnN0IHN0cnVjdCBoeXBlcnZpc29yX29wcyAqX19pbml0
IHhnX3Byb2JlKHZvaWQpCiAgICAgaWYgKCAheGVuX2NwdWlkX2Jhc2UgKQog
ICAgICAgICByZXR1cm4gTlVMTDsKIAotICAgIC8qIEZpbGwgdGhlIGh5cGVy
Y2FsbCBwYWdlLiAqLwotICAgIHdybXNybChjcHVpZF9lYngoeGVuX2NwdWlk
X2Jhc2UgKyAyKSwgX19wYShoeXBlcmNhbGxfcGFnZSkpOwotCiAgICAgeGVu
X2d1ZXN0ID0gdHJ1ZTsKIAogICAgIHJldHVybiAmb3BzOwpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmggYi94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vY3B1ZmVhdHVyZXMuaAppbmRleCBi
YTNkZjE3NGI3NmUuLjllM2VkMjFjMDI2ZCAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKKysrIGIveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKQEAgLTQyLDYgKzQy
LDcgQEAgWEVOX0NQVUZFQVRVUkUoWEVOX1NIU1RLLCAgICAgICAgIFg4Nl9T
WU5USCgyNikpIC8qIFhlbiB1c2VzIENFVCBTaGFkb3cgU3RhY2tzICoKIFhF
Tl9DUFVGRUFUVVJFKFhFTl9JQlQsICAgICAgICAgICBYODZfU1lOVEgoMjcp
KSAvKiBYZW4gdXNlcyBDRVQgSW5kaXJlY3QgQnJhbmNoIFRyYWNraW5nICov
CiBYRU5fQ1BVRkVBVFVSRShJQlBCX0VOVFJZX1BWLCAgICAgWDg2X1NZTlRI
KDI4KSkgLyogTVNSX1BSRURfQ01EIHVzZWQgYnkgWGVuIGZvciBQViAqLwog
WEVOX0NQVUZFQVRVUkUoSUJQQl9FTlRSWV9IVk0sICAgIFg4Nl9TWU5USCgy
OSkpIC8qIE1TUl9QUkVEX0NNRCB1c2VkIGJ5IFhlbiBmb3IgSFZNICovCitY
RU5fQ1BVRkVBVFVSRShVU0VfVk1DQUxMLCAgICAgICAgWDg2X1NZTlRIKDMw
KSkgLyogVXNlIFZNQ0FMTCBpbnN0ZWFkIG9mIFZNTUNBTEwgKi8KIAogLyog
QnVnIHdvcmRzIGZvbGxvdyB0aGUgc3ludGhldGljIHdvcmRzLiAqLwogI2Rl
ZmluZSBYODZfTlJfQlVHIDEKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaCBiL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaAppbmRleCA2NjViNDcyZDA1
YWMuLjk2MDA0ZGVjOTkwOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2d1ZXN0L3hlbi1oY2FsbC5oCisrKyBiL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaApAQCAtMzAsOSArMzAs
MTEgQEAKICAgICAoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICgg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKLSAgICAgICAgICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNb
b2Zmc2V0XSIgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAg
ICAgIEFMVEVSTkFUSVZFXzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgInZtbWNhbGwiLCBBTFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwp
LCAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4
Nl9GRUFUVVJFX1VTRV9WTUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgIDogIj1hIiAocmVzKSwgIj1EIiAodG1wX18pIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgIDogW29mZnNldF0g
ImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2FsbCksICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgICAgIjEiICgobG9uZykoYTEpKSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgKHR5cGUpcmVzOyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKQEAgLTQyLDEw
ICs0NCwxMiBAQAogICAgICh7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICBsb25nIHJlcywgdG1wX187ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBhc20gdm9sYXRp
bGUgKCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgImNhbGwgaHlwZXJjYWxsX3BhZ2Ug
KyAlY1tvZmZzZXRdIiAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgQUxURVJOQVRJVkVfMigiY2FsbCBlYXJseV9oeXBlcmNhbGwi
LCAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAidm1tY2FsbCIsIEFMVF9OT1QoWDg2X0ZFQVRVUkVfVVNFX1ZN
Q0FMTCksICAgXAorICAgICAgICAgICAgICAgICAgICAgICAgICAidm1jYWxs
IiwgWDg2X0ZFQVRVUkVfVVNFX1ZNQ0FMTCkgICAgICAgICAgICAgXAogICAg
ICAgICAgICAgOiAiPWEiIChyZXMpLCAiPUQiICh0bXBfXyksICI9UyIgKHRt
cF9fKSAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICBBU01f
Q0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgOiBbb2Zmc2V0XSAiaSIgKGhjYWxs
ICogMzIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgOiAiMCIgKGhjYWxsKSwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAiMSIg
KChsb25nKShhMSkpLCAiMiIgKChsb25nKShhMikpICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgICAgICAgICAgOiAibWVtb3J5IiApOyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICAodHlwZSlyZXM7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXApAQCAtNTUsMTAgKzU5LDEyIEBA
CiAgICAgKHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGxvbmcg
cmVzLCB0bXBfXzsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICAiY2FsbCBoeXBlcmNhbGxfcGFnZSArICVjW29mZnNl
dF0iICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICBB
TFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5cGVyY2FsbCIsICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2
bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSwgICBc
CisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2bWNhbGwiLCBYODZfRkVB
VFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAgICBcCiAgICAgICAgICAgICA6
ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSwgIj1TIiAodG1wX18pLCAiPWQi
ICh0bXBfXykgICAgICBcCiAgICAgICAgICAgICAgIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiksICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICA6
ICIwIiAoaGNhbGwpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcpKGEx
KSksICIyIiAoKGxvbmcpKGEyKSksICIzIiAoKGxvbmcpKGEzKSkgICAgICBc
CiAgICAgICAgICAgICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICh0eXBl
KXJlczsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCkBAIC02OSwxMCArNzUsMTIgQEAKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgcmVnaXN0ZXIgbG9uZyBf
YTQgYXNtICgicjEwIikgPSAoKGxvbmcpKGE0KSk7ICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICggICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNbb2Zmc2V0XSIgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIEFMVEVSTkFUSVZF
XzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtbWNhbGwiLCBB
TFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwpLCAgIFwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIj1hIiAocmVz
KSwgIj1EIiAodG1wX18pLCAiPVMiICh0bXBfXyksICI9ZCIgKHRtcF9fKSwg
ICAgIFwKICAgICAgICAgICAgICAgIj0mciIgKHRtcF9fKSBBU01fQ0FMTF9D
T05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgIDogW29mZnNldF0gImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2Fs
bCksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgICAgICAgIjEiICgobG9uZykoYTEpKSwgIjIiICgo
bG9uZykoYTIpKSwgIjMiICgobG9uZykoYTMpKSwgICAgIFwKICAgICAgICAg
ICAgICAgIjQiIChfYTQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-03.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-03.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IChNaXMpYWxpZ24gX194ODZfaW5kaXJlY3RfdGh1bmtf
KiB0byBtaXRpZ2F0ZSBJVFMKClRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRp
cmVjdApicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hl
biBpbiB0aGUgZmlyc3QgaGFsZiBvZiBhIGNhY2hlbGluZS4KCkFycmFuZ2Ug
Zm9yIF9feDg2X2luZGlyZWN0X3RodW5rXyogdG8gYWx3YXlzIGJlIGluIHRo
ZSBzZWNvbmQgaGFsZi4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDY5IC8gQ1ZF
LTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TCmluZGV4IGZkNTQ5M2MyMmIxNi4uYzRiOTc4ZDY3Yjhl
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwor
KysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMTEsNiAr
MTEsMTAgQEAKIAogI2luY2x1ZGUgPGFzbS9hc21fZGVmbnMuaD4KIAorLyog
QWxpZ25tZW50IGlzIGRlYWx0IHdpdGggZXhwbGljaXRseSBoZXJlOyBvdmVy
cmlkZSB0aGUgcmVzcGVjdGl2ZSBtYWNyby4gKi8KKyN1bmRlZiBTWU1fQUxJ
R04KKyNkZWZpbmUgU1lNX0FMSUdOKGFsaWduLi4uKQorCiAubWFjcm8gSU5E
X1RIVU5LX1JFVFBPTElORSByZWc6cmVxCiAgICAgICAgIGNhbGwgMWYKICAg
ICAgICAgaW50MwpAQCAtMzUsNiArMzksMTYgQEAKIC5tYWNybyBHRU5fSU5E
SVJFQ1RfVEhVTksgcmVnOnJlcQogICAgICAgICAuc2VjdGlvbiAudGV4dC5f
X3g4Nl9pbmRpcmVjdF90aHVua19ccmVnLCAiYXgiLCBAcHJvZ2JpdHMKIAor
ICAgICAgICAvKgorICAgICAgICAgKiBUaGUgSW5kaXJlY3QgVGFyZ2V0IFNl
bGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5zIHRoYXQK
KyAgICAgICAgICogaW5kaXJlY3QgYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRz
KSBhcmUgdW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0CisgICAgICAgICAqIGhh
bGYgb2YgYSBjYWNoZWxpbmUuICBBcnJhbmdlIGZvciB0aGVtIHRvIGJlIGlu
IHRoZSBzZWNvbmQgaGFsZi4KKyAgICAgICAgICoKKyAgICAgICAgICogQWxp
Z24gdG8gNjQsIHRoZW4gc2tpcCAzMi4KKyAgICAgICAgICovCisgICAgICAg
IC5iYWxpZ24gNjQKKyAgICAgICAgLmZpbGwgMzIsIDEsIDB4Y2MKKwogRlVO
QyhfX3g4Nl9pbmRpcmVjdF90aHVua19ccmVnKQogICAgICAgICBBTFRFUk5B
VElWRV8yIF9fc3RyaW5naWZ5KElORF9USFVOS19SRVRQT0xJTkUgXHJlZyks
ICAgICAgICAgICAgICBcCiAgICAgICAgIF9fc3RyaW5naWZ5KElORF9USFVO
S19MRkVOQ0UgXHJlZyksIFg4Nl9GRUFUVVJFX0lORF9USFVOS19MRkVOQ0Us
IFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-04.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-04.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3RodW5rOiAoTWlzKWFsaWduIHRoZSBSRVRzIGlu
IGNsZWFyX2JoYl9sb29wcygpIHRvIG1pdGlnYXRlIElUUwoKVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0IGluZGlyZWN0CmJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdCBoYWxmIG9mIGEgY2Fj
aGVsaW5lLgoKY2xlYXJfYmhiX2xvb3BzKCkgaGFzIGEgcHJlY2lzZSBsYXlv
dXQgb2YgYnJhbmNoZXMuICBUaGUgYWxpZ25tZW50IGZvcgpwZXJmb3JtYW5j
ZSBjYXVzZSB0aGUgUkVUcyB0byBhbHdheXMgYmUgaW4gYW4gdW5zYWZlIHBv
c2l0aW9uLCBhbmQgY29udmVydGluZwp0aG9zZSB0byByZXR1cm4gdGh1bmtz
IGNoYW5nZXMgdGhlIGJyYW5jaGluZyBwYXR0ZXJuLiAgV2hpbGUgc3VjaCBh
IGNvbnZlcnNpb24KaXMgYmVsaWV2ZWQgdG8gYmUgc2FmZSwgY2xlYXJfYmhi
X2xvb3BzKCkgaXMgYWxzbyBhIHBlcmZvcm1hbmNlLXJlbGV2YW50CmZhc3Rw
YXRoLCBzbyAobWlzKWFsaWduIHRoZSBSRVRzIHRvIGJlIGluIGEgc2FmZSBw
b3NpdGlvbi4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0
IG9mIFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUyBi
L3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCA2NzhjMDBjNWQwNmYu
LjUyNjI1ZjRlMmMxNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2JoYi10
aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwpAQCAtNTAs
NyArNTAsMTIgQEAgRU5EKGNsZWFyX2JoYl90c3gpCiAgKiAgIHJldAogICoK
ICAqIFRoZSBDQUxML1JFVHMgYXJlIG5lY2Vzc2FyeSB0byBwcmV2ZW50IHRo
ZSBMb29wIFN0cmVhbSBEZXRlY3RvciBmcm9tCi0gKiBpbnRlcmZlcmluZy4g
IFRoZSBhbGlnbm1lbnQgaXMgZm9yIHBlcmZvcm1hbmNlIGFuZCBub3Qgc2Fm
ZXR5LgorICogaW50ZXJmZXJpbmcuCisgKgorICogVGhlIC5iYWxpZ24ncyBh
cmUgZm9yIHBlcmZvcm1hbmNlLCBidXQgdGhleSBjYXVzZSB0aGUgUkVUcyB0
byBiZSBpbiB1bnNhZmUKKyAqIHBvc2l0aW9ucyB3aXRoIHJlc3BlY3QgdG8g
SW5kaXJlY3QgVGFyZ2V0IFNlbGVjdGlvbi4gIFRoZSAuc2tpcHMgYXJlIHRv
CisgKiBtb3ZlIHRoZSBSRVRzIGludG8gSVRTLXNhZmUgcG9zaXRpb25zLCBy
YXRoZXIgdGhhbiB1c2luZyB0aGUgc2xvd3BhdGgKKyAqIHRocm91Z2ggX194
ODZfcmV0dXJuX3RodW5rLgogICoKICAqIFRoZSAic2hvcnQiIHNlcXVlbmNl
ICg1IGFuZCA1KSBpcyBmb3IgQ1BVcyBwcmlvciB0byBBbGRlciBMYWtlIC8g
U2FwcGhpcmUKICAqIFJhcGlkcyAoaS5lLiBDb3JlcyBwcmlvciB0byBHb2xk
ZW4gQ292ZSBhbmQvb3IgR3JhY2Vtb250KS4KQEAgLTY2LDEyICs3MSwxNCBA
QCBGVU5DKGNsZWFyX2JoYl9sb29wcykKICAgICAgICAgam1wICAgICA1Zgog
ICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAgICAgIC5i
YWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtICguTHIxIC0gMWYpLCAw
eGNjCiAxOiAgICAgIGNhbGwgICAgMmYKLSAgICAgICAgcmV0CisuTHIxOiAg
IHJldAogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAg
ICAgIC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtIDE4IC8qICgu
THIyIC0gMmYpIGJ1dCBDbGFuZyBJQVMgZG9lc24ndCBsaWtlIHRoaXMgKi8s
IDB4Y2MKIDI6ICAgICAgQUxURVJOQVRJVkUgIm1vdiAkNSwgJWVheCIsICJt
b3YgJDcsICVlYXgiLCBYODZfU1BFQ19CSEJfTE9PUFNfTE9ORwogCiAzOiAg
ICAgIGptcCAgICAgNGYKQEAgLTgzLDcgKzkwLDcgQEAgRlVOQyhjbGVhcl9i
aGJfbG9vcHMpCiAgICAgICAgIHN1YiAgICAgJDEsICVlY3gKICAgICAgICAg
am56ICAgICAxYgogCi0gICAgICAgIHJldAorLkxyMjogICByZXQKIDU6CiAg
ICAgICAgIC8qCiAgICAgICAgICAqIFRoZSBJbnRlbCBzZXF1ZW5jZSBoYXMg
YW4gTEZFTkNFIGhlcmUuICBUaGUgcHVycG9zZSBpcyB0byBlbnN1cmUK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-05.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-05.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3N0dWJzOiBJbnRyb2R1Y2UgcGxhY2VfcmV0KCkg
dG8gYWJzdHJhY3QgYXdheSByYXcgMHhjMydzCgpUaGUgSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5z
IHRoYXQgaW5kaXJlY3QKYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUg
dW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0IGhhbGYgb2YgYSBjYWNoZWxpbmUu
ClRoaXMgbWVhbnMgaXQncyBub3Qgc2FmZSBmb3IgbG9naWMgdXNpbmcgdGhl
IHN0dWJzIHRvIHdyaXRlIHJhdyAweGMzJ3MuCgpJbnRyb2R1Y2UgcGxhY2Vf
cmV0KCkgd2hpY2gsIGZvciBub3csIHdyaXRlcyBhIHJhdyAweGMzIGJ1dCB3
aWxsIGNvbnRhaW4KYWRkaXRpb25hbCBsb2dpYyB3aGVuIHJldHVybiB0aHVu
a3MgYXJlIGluIHVzZS4KCnN0dWJfc2VsZnRlc3QoKSBkb2Vzbid0IHN0cmlj
dGx5IG5lZWQgdG8gYmUgY29udmVydGVkIGFzIHRoZXkgb25seSBydW4gb24K
Ym9vdCwgYnV0IGRvaW5nIHNvIGdldHMgdXMgYSBwYXJ0aWFsIHRlc3Qgb2Yg
cGxhY2VfcmV0KCkgdG9vLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ2OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQt
b2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu
Y29tPgpSZXZpZXdlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvdG9vbHMvdGVzdHMveDg2X2Vt
dWxhdG9yL3g4Ni1lbXVsYXRlLmggYi90b29scy90ZXN0cy94ODZfZW11bGF0
b3IveDg2LWVtdWxhdGUuaAppbmRleCA4ZjhhY2NmZTNlNzAuLjk0NmFhYTlk
NjYwYiAxMDA2NDQKLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKKysrIGIvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKQEAgLTY4LDYgKzY4LDEyIEBACiAKICNkZWZpbmUgaXNf
Y2Fub25pY2FsX2FkZHJlc3MoeCkgKCgoaW50NjRfdCkoeCkgPj4gNDcpID09
ICgoaW50NjRfdCkoeCkgPj4gNjMpKQogCitzdGF0aWMgaW5saW5lIHZvaWQg
KnBsYWNlX3JldCh2b2lkICpwdHIpCit7CisgICAgKih1aW50OF90ICopcHRy
ID0gMHhjMzsKKyAgICByZXR1cm4gcHRyICsgMTsKK30KKwogZXh0ZXJuIHVp
bnQzMl90IG14Y3NyX21hc2s7CiBleHRlcm4gc3RydWN0IGNwdV9wb2xpY3kg
Y3A7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hl
bi9hcmNoL3g4Ni9NYWtlZmlsZQppbmRleCBjMWU2NDI3OGNlODUuLmE3ZTVh
ODI2ODlkZSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisr
KyBiL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtMTEsOSArMTEsNyBAQCBv
YmotJChDT05GSUdfUFYpICs9IHB2Lwogb2JqLXkgKz0geDg2XzY0Lwogb2Jq
LXkgKz0geDg2X2VtdWxhdGUvCiAKLWFsdGVybmF0aXZlLXkgOj0gYWx0ZXJu
YXRpdmUuaW5pdC5vCi1hbHRlcm5hdGl2ZS0kKENPTkZJR19MSVZFUEFUQ0gp
IDo9Ci1vYmotYmluLXkgKz0gJChhbHRlcm5hdGl2ZS15KQorb2JqLXkgKz0g
YWx0ZXJuYXRpdmUubwogb2JqLXkgKz0gYXBpYy5vCiBvYmoteSArPSBiaGIt
dGh1bmsubwogb2JqLXkgKz0gYml0b3BzLm8KQEAgLTQxLDcgKzM5LDcgQEAg
b2JqLXkgKz0gaHlwZXJjYWxsLm8KIG9iai15ICs9IGkzODcubwogb2JqLXkg
Kz0gaTgyNTkubwogb2JqLXkgKz0gaW9fYXBpYy5vCi1vYmotJChDT05GSUdf
TElWRVBBVENIKSArPSBhbHRlcm5hdGl2ZS5vIGxpdmVwYXRjaC5vCitvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9hbHRlcm5hdGl2ZS5jIGIveGVuL2FyY2gveDg2L2FsdGVybmF0
aXZlLmMKaW5kZXggODhjOTAwNDRjMjBkLi5lYzQ1MWQ5NjJjMTAgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCkBAIC0xMzcsNiArMTM3LDIwIEBAIHZv
aWQgaW5pdF9vcl9saXZlcGF0Y2ggYWRkX25vcHModm9pZCAqaW5zbnMsIHVu
c2lnbmVkIGludCBsZW4pCiAgICAgfQogfQogCisvKgorICogUGxhY2UgYSBy
ZXR1cm4gYXQgQHB0ci4gIEBwdHIgbXVzdCBiZSBpbiB0aGUgd3JpdGFibGUg
YWxpYXMgb2YgYSBzdHViLgorICoKKyAqIFJldHVybnMgdGhlIG5leHQgcG9z
aXRpb24gdG8gd3JpdGUgaW50byB0aGUgc3R1Yi4KKyAqLwordm9pZCAqcGxh
Y2VfcmV0KHZvaWQgKnB0cikKK3sKKyAgICB1aW50OF90ICpwID0gcHRyOwor
CisgICAgKnArKyA9IDB4YzM7CisKKyAgICByZXR1cm4gcDsKK30KKwogLyoK
ICAqIHRleHRfcG9rZSAtIFVwZGF0ZSBpbnN0cnVjdGlvbnMgb24gYSBsaXZl
IGtlcm5lbCBvciBub24tZXhlY3V0ZWQgY29kZS4KICAqIEBhZGRyOiBhZGRy
ZXNzIHRvIG1vZGlmeQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2V4dGFi
bGUuYyBiL3hlbi9hcmNoL3g4Ni9leHRhYmxlLmMKaW5kZXggNzA1Y2Y5ZWI5
NGNhLi4xNTcyZWZhNjlhMDAgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9l
eHRhYmxlLmMKKysrIGIveGVuL2FyY2gveDg2L2V4dGFibGUuYwpAQCAtMTUx
LDIwICsxNTEsMjAgQEAgc2VhcmNoX2V4Y2VwdGlvbl90YWJsZShjb25zdCBz
dHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncywgdW5zaWduZWQgbG9uZyAqc3R1
Yl9yYSkKIGludCBfX2luaXQgY2ZfY2hlY2sgc3R1Yl9zZWxmdGVzdCh2b2lk
KQogewogICAgIHN0YXRpYyBjb25zdCBzdHJ1Y3QgewotICAgICAgICB1aW50
OF90IG9wY1s4XTsKKyAgICAgICAgdWludDhfdCBvcGNbN107CiAgICAgICAg
IHVpbnQ2NF90IHJheDsKICAgICAgICAgdW5pb24gc3R1Yl9leGNlcHRpb25f
dG9rZW4gcmVzOwogICAgIH0gdGVzdHNbXSBfX2luaXRjb25zdCA9IHsKICNk
ZWZpbmUgZW5kYnI2NCAweGYzLCAweDBmLCAweDFlLCAweGZhCi0gICAgICAg
IHsgLm9wYyA9IHsgZW5kYnI2NCwgMHgwZiwgMHhiOSwgMHhjMywgMHhjMyB9
LCAvKiB1ZDEgKi8KKyAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDBm
LCAweGI5LCAweDkwIH0sIC8qIHVkMSAqLwogICAgICAgICAgIC5yZXMuZmll
bGRzLnRyYXBuciA9IFg4Nl9FWENfVUQgfSwKLSAgICAgICAgeyAub3BjID0g
eyBlbmRicjY0LCAweDkwLCAweDAyLCAweDAwLCAweGMzIH0sIC8qIG5vcDsg
YWRkICglcmF4KSwlYWwgKi8KKyAgICAgICAgeyAub3BjID0geyBlbmRicjY0
LCAweDkwLCAweDAyLCAweDAwIH0sIC8qIG5vcDsgYWRkICglcmF4KSwlYWwg
Ki8KICAgICAgICAgICAucmF4ID0gMHgwMTIzNDU2Nzg5YWJjZGVmLAogICAg
ICAgICAgIC5yZXMuZmllbGRzLnRyYXBuciA9IFg4Nl9FWENfR1AgfSwKLSAg
ICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDAyLCAweDA0LCAweDA0LCAw
eGMzIH0sIC8qIGFkZCAoJXJzcCwlcmF4KSwlYWwgKi8KKyAgICAgICAgeyAu
b3BjID0geyBlbmRicjY0LCAweDAyLCAweDA0LCAweDA0IH0sIC8qIGFkZCAo
JXJzcCwlcmF4KSwlYWwgKi8KICAgICAgICAgICAucmF4ID0gMHhmZWRjYmE5
ODc2NTQzMjEwVUwsCiAgICAgICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0g
WDg2X0VYQ19TUyB9LAotICAgICAgICB7IC5vcGMgPSB7IGVuZGJyNjQsIDB4
Y2MsIDB4YzMsIDB4YzMsIDB4YzMgfSwgLyogaW50MyAqLworICAgICAgICB7
IC5vcGMgPSB7IGVuZGJyNjQsIDB4Y2MsIDB4OTAsIDB4OTAgfSwgLyogaW50
MyAqLwogICAgICAgICAgIC5yZXMuZmllbGRzLnRyYXBuciA9IFg4Nl9FWENf
QlAgfSwKICN1bmRlZiBlbmRicjY0CiAgICAgfTsKQEAgLTE4Myw2ICsxODMs
NyBAQCBpbnQgX19pbml0IGNmX2NoZWNrIHN0dWJfc2VsZnRlc3Qodm9pZCkK
IAogICAgICAgICBtZW1zZXQocHRyLCAweGNjLCBTVFVCX0JVRl9TSVpFIC8g
Mik7CiAgICAgICAgIG1lbWNweShwdHIsIHRlc3RzW2ldLm9wYywgQVJSQVlf
U0laRSh0ZXN0c1tpXS5vcGMpKTsKKyAgICAgICAgcGxhY2VfcmV0KHB0ciAr
IEFSUkFZX1NJWkUodGVzdHNbaV0ub3BjKSk7CiAgICAgICAgIHVubWFwX2Rv
bWFpbl9wYWdlKHB0cik7CiAKICAgICAgICAgYXNtIHZvbGF0aWxlICggIklO
RElSRUNUX0NBTEwgJVtzdGJdXG4iCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvaW5jbHVkZS9hc20vYWx0ZXJuYXRpdmUuaCBiL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCmluZGV4IDg5YjdiZGNiODJlNS4u
ODQxYTYzZWJmMWI2IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVk
ZS9hc20vYWx0ZXJuYXRpdmUuaAorKysgYi94ZW4vYXJjaC94ODYvaW5jbHVk
ZS9hc20vYWx0ZXJuYXRpdmUuaApAQCAtMzAsNiArMzAsOCBAQCBzdHJ1Y3Qg
X19wYWNrZWQgYWx0X2luc3RyIHsKICNkZWZpbmUgQUxUX1JFUExfUFRSKGEp
ICAgICBfX0FMVF9QVFIoYSwgcmVwbF9vZmZzZXQpCiAKIGV4dGVybiB2b2lk
IGFkZF9ub3BzKHZvaWQgKmluc25zLCB1bnNpZ25lZCBpbnQgbGVuKTsKK3Zv
aWQgKnBsYWNlX3JldCh2b2lkICpwdHIpOworCiAvKiBTaW1pbGFyIHRvIGFs
dGVybmF0aXZlX2luc3RydWN0aW9ucyBleGNlcHQgaXQgY2FuIGJlIHJ1biB3
aXRoIElSUXMgZW5hYmxlZC4gKi8KIGV4dGVybiBpbnQgYXBwbHlfYWx0ZXJu
YXRpdmVzKHN0cnVjdCBhbHRfaW5zdHIgKnN0YXJ0LCBzdHJ1Y3QgYWx0X2lu
c3RyICplbmQpOwogZXh0ZXJuIHZvaWQgYWx0ZXJuYXRpdmVfaW5zdHJ1Y3Rp
b25zKHZvaWQpOwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3B2L2VtdWwt
cHJpdi1vcC5jIGIveGVuL2FyY2gveDg2L3B2L2VtdWwtcHJpdi1vcC5jCmlu
ZGV4IDcwMTUwYzI3MjI3Ni4uZmY1ZDFjOWY4NjM0IDEwMDY0NAotLS0gYS94
ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMKKysrIGIveGVuL2FyY2gv
eDg2L3B2L2VtdWwtcHJpdi1vcC5jCkBAIC03Niw3ICs3Niw2IEBAIHN0YXRp
YyBpb19lbXVsX3N0dWJfdCAqaW9fZW11bF9zdHViX3NldHVwKHN0cnVjdCBw
cml2X29wX2N0eHQgKmN0eHQsIHU4IG9wY29kZSwKICAgICAgICAgMHg0MSwg
MHg1YywgLyogcG9wICVyMTIgICovCiAgICAgICAgIDB4NWQsICAgICAgIC8q
IHBvcCAlcmJwICAqLwogICAgICAgICAweDViLCAgICAgICAvKiBwb3AgJXJi
eCAgKi8KLSAgICAgICAgMHhjMywgICAgICAgLyogcmV0ICAgICAgICovCiAg
ICAgfTsKIAogICAgIGNvbnN0IHN0cnVjdCBzdHVicyAqdGhpc19zdHVicyA9
ICZ0aGlzX2NwdShzdHVicyk7CkBAIC0xMjYsMTEgKzEyNSwxMyBAQCBzdGF0
aWMgaW9fZW11bF9zdHViX3QgKmlvX2VtdWxfc3R1Yl9zZXR1cChzdHJ1Y3Qg
cHJpdl9vcF9jdHh0ICpjdHh0LCB1OCBvcGNvZGUsCiAKICAgICBBUFBFTkRf
Q0FMTChzYXZlX2d1ZXN0X2dwcnMpOwogICAgIEFQUEVORF9CVUZGKGVwaWxv
Z3VlKTsKKyAgICBwID0gcGxhY2VfcmV0KHApOwogCiAgICAgLyogQnVpbGQt
dGltZSBiZXN0IGVmZm9ydCBhdHRlbXB0IHRvIGNhdGNoIHByb2JsZW1zLiAq
LwogICAgIEJVSUxEX0JVR19PTihTVFVCX0JVRl9TSVpFIC8gMiA8CiAgICAg
ICAgICAgICAgICAgIChzaXplb2YocHJvbG9ndWUpICsgc2l6ZW9mKGVwaWxv
Z3VlKSArIDEwIC8qIDJ4IGNhbGwgKi8gKwotICAgICAgICAgICAgICAgICAg
TUFYKDMgLyogZGVmYXVsdCBzdHViICovLCBJT0VNVUxfUVVJUktfU1RVQl9C
WVRFUykpKTsKKyAgICAgICAgICAgICAgICAgIE1BWCgzIC8qIGRlZmF1bHQg
c3R1YiAqLywgSU9FTVVMX1FVSVJLX1NUVUJfQllURVMpICsKKyAgICAgICAg
ICAgICAgICAgIDEgLyogcmV0ICovKSk7CiAgICAgLyogUnVudGltZSBjb25m
aXJtYXRpb24gdGhhdCB3ZSBoYXZlbid0IGNsb2JiZXJlZCBhbiBhZGphY2Vu
dCBzdHViLiAqLwogICAgIEJVR19PTihTVFVCX0JVRl9TSVpFIC8gMiA8IChw
IC0gY3R4dC0+aW9fZW11bF9zdHViKSk7CiAKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni94ODZfZW11bGF0ZS9mcHUuYyBiL3hlbi9hcmNoL3g4Ni94ODZf
ZW11bGF0ZS9mcHUuYwppbmRleCA0ODBkODc5NjU3MDUuLjAzNjEyZDAwYTJj
ZSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL2ZwdS5j
CisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfZW11bGF0ZS9mcHUuYwpAQCAtMzIs
MzYgKzMyLDQyIEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBmcHVfY2hlY2tfd3Jp
dGUodm9pZCkKIAogI2RlZmluZSBlbXVsYXRlX2ZwdV9pbnNuX21lbWRzdChv
cGMsIGV4dCwgYXJnKSAgICAgICAgICAgICAgICAgICAgICAgICAgXAogZG8g
eyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIHZvaWQgKl9wID0gZ2V0
X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIC8qIE1vZFJNOiBtb2Q9MCwgcmVnPWV4dCwgcm09
MCwgaS5lLiBhICglcmF4KSBvcGVyYW5kICovICAgICAgICAgICAgXAogICAg
ICppbnNuX2J5dGVzID0gMjsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAotICAgIG1lbWNweShnZXRfc3R1
YihzdHViKSwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAoKHVpbnQ4X3RbXSl7IG9wYywgKChl
eHQpICYgNykgPDwgMywgMHhjMyB9KSwgMyk7ICAgICAgICAgICAgXAorICAg
IG1lbWNweShfcCwgKCh1aW50OF90W10peyBvcGMsICgoZXh0KSAmIDcpIDw8
IDMgfSksIDIpOyBfcCArPSAyOyAgICAgXAorICAgIHBsYWNlX3JldChfcCk7
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAoYXJn
KSA6ICJhIiAoJihhcmcpKSk7ICAgICAgICAgICAgICAgICAgICAgXAogICAg
IHB1dF9zdHViKHN0dWIpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogfSB3aGlsZSAoMCkKIAogI2Rl
ZmluZSBlbXVsYXRlX2ZwdV9pbnNuX21lbXNyYyhvcGMsIGV4dCwgYXJnKSAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogZG8geyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAorICAgIHZvaWQgKl9wID0gZ2V0X3N0dWIoc3R1Yik7ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
IC8qIE1vZFJNOiBtb2Q9MCwgcmVnPWV4dCwgcm09MCwgaS5lLiBhICglcmF4
KSBvcGVyYW5kICovICAgICAgICAgICAgXAotICAgIG1lbWNweShnZXRfc3R1
YihzdHViKSwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAoKHVpbnQ4X3RbXSl7IG9wYywgKChl
eHQpICYgNykgPDwgMywgMHhjMyB9KSwgMyk7ICAgICAgICAgICAgXAorICAg
IG1lbWNweShfcCwgKCh1aW50OF90W10peyBvcGMsICgoZXh0KSAmIDcpIDw8
IDMgfSksIDIpOyBfcCArPSAyOyAgICAgXAorICAgIHBsYWNlX3JldChfcCk7
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1tIiAoZHVt
bXkpIDogIm0iIChhcmcpLCAiYSIgKCYoYXJnKSkpOyAgICAgICAgXAogICAg
IHB1dF9zdHViKHN0dWIpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogfSB3aGlsZSAoMCkKIAogI2Rl
ZmluZSBlbXVsYXRlX2ZwdV9pbnNuX3N0dWIoYnl0ZXMuLi4pICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogZG8geyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAorICAgIHZvaWQgKl9wID0gZ2V0X3N0dWIoc3R1Yik7ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
IHVuc2lnbmVkIGludCBucl8gPSBzaXplb2YoKHVpbnQ4X3RbXSl7IGJ5dGVz
IH0pOyAgICAgICAgICAgICAgICAgICAgXAotICAgIG1lbWNweShnZXRfc3R1
YihzdHViKSwgKCh1aW50OF90W10peyBieXRlcywgMHhjMyB9KSwgbnJfICsg
MSk7ICAgICAgXAorICAgIG1lbWNweShfcCwgKCh1aW50OF90W10peyBieXRl
cyB9KSwgbnJfKTsgX3AgKz0gbnJfOyAgICAgICAgICAgICAgICAgXAorICAg
IHBsYWNlX3JldChfcCk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgIGludm9rZV9zdHViKCIi
LCAiIiwgIj1tIiAoZHVtbXkpIDogImkiICgwKSk7ICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIHB1dF9zdHViKHN0dWIpOyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogfSB3
aGlsZSAoMCkKIAogI2RlZmluZSBlbXVsYXRlX2ZwdV9pbnNuX3N0dWJfZWZs
YWdzKGJ5dGVzLi4uKSAgICAgICAgICAgICAgICAgICAgICAgICAgXAogZG8g
eyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIHZvaWQgKl9wID0gZ2V0
X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIHVuc2lnbmVkIGludCBucl8gPSBzaXplb2YoKHVp
bnQ4X3RbXSl7IGJ5dGVzIH0pOyAgICAgICAgICAgICAgICAgICAgXAogICAg
IHVuc2lnbmVkIGxvbmcgdG1wXzsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAotICAgIG1lbWNweShnZXRfc3R1
YihzdHViKSwgKCh1aW50OF90W10peyBieXRlcywgMHhjMyB9KSwgbnJfICsg
MSk7ICAgICAgXAorICAgIG1lbWNweShfcCwgKCh1aW50OF90W10peyBieXRl
cyB9KSwgbnJfKTsgX3AgKz0gbnJfOyAgICAgICAgICAgICAgICAgXAorICAg
IHBsYWNlX3JldChfcCk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgIGludm9rZV9zdHViKF9Q
UkVfRUZMQUdTKCJbZWZsYWdzXSIsICJbbWFza10iLCAiW3RtcF0iKSwgICAg
ICAgICAgICAgXAogICAgICAgICAgICAgICAgIF9QT1NUX0VGTEFHUygiW2Vm
bGFnc10iLCAiW21hc2tdIiwgIlt0bXBdIiksICAgICAgICAgICAgXAogICAg
ICAgICAgICAgICAgIFtlZmxhZ3NdICIrZyIgKHJlZ3MtPmVmbGFncyksIFt0
bXBdICI9JnIiICh0bXBfKSAgICAgICAgXApkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMgYi94ZW4vYXJjaC94
ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYwppbmRleCBiMWQxOTJjYmJm
MWUuLmY0MDcwOTY4MjQ4NCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4
Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMKKysrIGIveGVuL2FyY2gveDg2L3g4
Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMKQEAgLTEzOTYsNyArMTM5Niw3IEBA
IHg4Nl9lbXVsYXRlKAogICAgICAgICBzdGJbM10gPSAweDkxOwogICAgICAg
ICBzdGJbNF0gPSBldmV4Lm9wbXNrIDw8IDM7CiAgICAgICAgIGluc25fYnl0
ZXMgPSA1OwotICAgICAgICBzdGJbNV0gPSAweGMzOworICAgICAgICBwbGFj
ZV9yZXQoJnN0Yls1XSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIi
LCAiK20iIChvcF9tYXNrKSA6ICJhIiAoJm9wX21hc2spKTsKIApAQCAtMzYy
Nyw3ICszNjI3LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIH0KICAgICAg
ICAgb3BjWzFdID0gKG1vZHJtICYgMHgzOCkgfCAweGMwOwogICAgICAgICBp
bnNuX2J5dGVzID0gRVZFWF9QRlhfQllURVMgKyAyOwotICAgICAgICBvcGNb
Ml0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAg
ICAgICAgY29weV9FVkVYKG9wYywgZXZleCk7CiAgICAgICAgIGludm9rZV9z
dHViKCIiLCAiIiwgIj1nIiAoZHVtbXkpIDogImEiIChzcmMudmFsKSk7CkBA
IC0zNjk0LDcgKzM2OTQsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAg
IGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwogICAgICAgICAgICAgY29w
eV9SRVhfVkVYKG9wYywgcmV4X3ByZWZpeCwgdmV4KTsKICAgICAgICAgfQot
ICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9w
Y1syXSk7CiAKICAgICAgICAgZWEucmVnID0gZGVjb2RlX2dwcigmX3JlZ3Ms
IG1vZHJtX3JlZyk7CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1h
IiAoKmVhLnJlZykgOiAiYyIgKG1tdmFscCksICJtIiAoKm1tdmFscCkpOwpA
QCAtMzc2OCw3ICszNzY4LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAg
ICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMjsKICAgICAgICAgICAgIGNv
cHlfUkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIH0K
LSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbMl0pOwogCiAgICAgICAgIF9yZWdzLmVmbGFncyAmPSB+RUZMQUdTX01B
U0s7CiAgICAgICAgIGludm9rZV9zdHViKCIiLApAQCAtNDAwNCw3ICs0MDA0
LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIG9wY1sxXSA9IG1vZHJtICYg
MHhjNzsKICAgICAgICAgaW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDI7CiAg
ICAgc2ltZF8wZl90b19ncHI6Ci0gICAgICAgIG9wY1tpbnNuX2J5dGVzIC0g
UEZYX0JZVEVTXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjW2lu
c25fYnl0ZXMgLSBQRlhfQllURVNdKTsKIAogICAgICAgICBnZW5lcmF0ZV9l
eGNlcHRpb25faWYoZWEudHlwZSAhPSBPUF9SRUcsIFg4Nl9FWENfVUQpOwog
CkBAIC00NDAxLDcgKzQ0MDEsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAg
ICAgIHZleC53ID0gMDsKICAgICAgICAgb3BjWzFdID0gbW9kcm0gJiAweDM4
OwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMjsKLSAgICAg
ICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0p
OwogCiAgICAgICAgIGNvcHlfUkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZl
eCk7CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAoc3JjLnZh
bCkgOiAiYSIgKCZzcmMudmFsKSk7CkBAIC00NDM4LDcgKzQ0MzgsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgICAgIGV2ZXgudyA9IDA7CiAgICAgICAg
IG9wY1sxXSA9IG1vZHJtICYgMHgzODsKICAgICAgICAgaW5zbl9ieXRlcyA9
IEVWRVhfUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
RVZFWChvcGMsIGV2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIs
ICIrbSIgKHNyYy52YWwpIDogImEiICgmc3JjLnZhbCkpOwpAQCAtNDYzMyw3
ICs0NjMzLDcgQEAgeDg2X2VtdWxhdGUoCiAjZW5kaWYgLyogWDg2RU1VTF9O
T19TSU1EICovCiAKICAgICBzaW1kXzBmX3JlZ19vbmx5OgotICAgICAgICBv
cGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10gPSAweGMzOworICAgICAgICBw
bGFjZV9yZXQoJm9wY1tpbnNuX2J5dGVzIC0gUEZYX0JZVEVTXSk7CiAKICAg
ICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3ByZWZpeCwgdmV4KTsKICAg
ICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCBbZHVtbXlfb3V0XSAiPWciIChk
dW1teSkgOiBbZHVtbXlfaW5dICJpIiAoMCkgKTsKQEAgLTQ5NjcsNyArNDk2
Nyw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0
KCkgKQogICAgICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0g
PSBtb2RybSAmIDB4Zjg7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAg
ICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X1ZFWChv
cGMsIHZleCk7CiAgICAgICAgIGVhLnJlZyA9IGRlY29kZV9ncHIoJl9yZWdz
LCBtb2RybV9ybSk7CkBAIC01MDEwLDcgKzUwMTAsNyBAQCB4ODZfZW11bGF0
ZSgKICAgICAgICAgaWYgKCAhbW9kZV82NGJpdCgpICkKICAgICAgICAgICAg
IHZleC53ID0gMDsKICAgICAgICAgb3BjWzFdID0gbW9kcm0gJiAweGM3Owot
ICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9w
Y1syXSk7CiAKICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAgICAg
ICBpbnZva2Vfc3R1YigiIiwgIiIsICI9YSIgKGRzdC52YWwpIDogW2R1bW15
XSAiaSIgKDApKTsKQEAgLTUwNDAsNyArNTA0MCw3IEBAIHg4Nl9lbXVsYXRl
KAogICAgICAgICBvcGMgPSBpbml0X3ByZWZpeGVzKHN0dWIpOwogICAgICAg
ICBvcGNbMF0gPSBiOwogICAgICAgICBvcGNbMV0gPSBtb2RybTsKLSAgICAg
ICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0p
OwogCiAgICAgICAgIGNvcHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAgX3Jl
Z3MuZWZsYWdzICY9IH5FRkxBR1NfTUFTSzsKQEAgLTU2MDgsNyArNTYwOCw3
IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0KCkg
KQogICAgICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBt
b2RybSAmIDB4Yzc7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAg
IHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X1JFWF9WRVgo
b3BjLCByZXhfcHJlZml4LCB2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1Yigi
IiwgIiIsICI9YSIgKGVhLnZhbCkgOiBbZHVtbXldICJpIiAoMCkpOwpAQCAt
NTcyNiw3ICs1NzI2LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAgICBv
cGNbMV0gJj0gMHgzODsKICAgICAgICAgfQogICAgICAgICBpbnNuX2J5dGVz
ID0gUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogICAgICAgICBpZiAoIHZleC5v
cGN4ID09IHZleF9ub25lICkKICAgICAgICAgewogICAgICAgICAgICAgLyog
Q292ZXIgZm9yIGV4dHJhIHByZWZpeCBieXRlLiAqLwpAQCAtNjAwNiw3ICs2
MDA2LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHB2ZXgtPmIgPSAhbW9k
ZV82NGJpdCgpIHx8ICh2ZXgucmVnID4+IDMpOwogICAgICAgICBvcGNbMV0g
PSAweGMwIHwgKH52ZXgucmVnICYgNyk7CiAgICAgICAgIHB2ZXgtPnJlZyA9
IDB4ZjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2Vf
cmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwg
Ij1hIiAoZWEudmFsKSA6IFtkdW1teV0gImkiICgwKSk7CiAgICAgICAgIHB1
dF9zdHViKHN0dWIpOwpAQCAtNjI5MCw3ICs2MjkwLDcgQEAgeDg2X2VtdWxh
dGUoCiAgICAgICAgICAgICBldmV4LncgPSAwOwogICAgICAgICBvcGNbMV0g
PSBtb2RybSAmIDB4Zjg7CiAgICAgICAgIGluc25fYnl0ZXMgPSBFVkVYX1BG
WF9CWVRFUyArIDI7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAg
IHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X0VWRVgob3Bj
LCBldmV4KTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiPWciIChk
dW1teSkgOiAiYSIgKHNyYy52YWwpKTsKQEAgLTYzODksNyArNjM4OSw3IEBA
IHg4Nl9lbXVsYXRlKAogICAgICAgICBwdmV4LT5iID0gMTsKICAgICAgICAg
b3BjWzFdID0gKG1vZHJtX3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHB2ZXgt
PnJlZyA9IDB4ZjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAg
cGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIi
LCAiIiwgIj1tIiAoKm1tdmFscCkgOiAiYSIgKG1tdmFscCkpOwogCkBAIC02
NDU5LDcgKzY0NTksNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+
YiA9IDE7CiAgICAgICAgIG9wY1sxXSA9IChtb2RybV9yZWcgJiA3KSA8PCAz
OwogICAgICAgICBwdmV4LT5yZWcgPSAweGY7Ci0gICAgICAgIG9wY1syXSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAg
ICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKCptbXZhbHApIDogImEiICht
bXZhbHApKTsKIApAQCAtNjUxNSw3ICs2NTE1LDcgQEAgeDg2X2VtdWxhdGUo
CiAgICAgICAgIHBldmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1v
ZHJtX3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0g
ICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKCpt
bXZhbHApIDogImEiIChtbXZhbHApKTsKIApAQCAtNjU4MCw3ICs2NTgwLDcg
QEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHBldmV4LT5iID0gMTsKICAgICAg
ICAgb3BjWzFdID0gKG1vZHJtX3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHBl
dmV4LT5SWCA9IDE7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAg
IHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1Yigi
IiwgIiIsICIrbSIgKCptbXZhbHApIDogImEiIChtbXZhbHApKTsKIApAQCAt
NjU5NCw3ICs2NTk0LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIG9wY1sy
XSA9IDB4OTA7CiAgICAgICAgIC8qIFVzZSAoJXJheCkgYXMgc291cmNlLiAq
LwogICAgICAgICBvcGNbM10gPSBldmV4Lm9wbXNrIDw8IDM7Ci0gICAgICAg
IG9wY1s0XSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzRdKTsK
IAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKG9wX21hc2sp
IDogImEiICgmb3BfbWFzaykpOwogICAgICAgICBwdXRfc3R1YihzdHViKTsK
QEAgLTY2ODgsNyArNjY4OCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBw
ZXZleC0+YiA9IDE7CiAgICAgICAgIG9wY1sxXSA9IChtb2RybV9yZWcgJiA3
KSA8PCAzOwogICAgICAgICBwZXZleC0+UlggPSAxOwotICAgICAgICBvcGNb
Ml0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAg
ICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiPW0iICgqbW12YWxwKSA6ICJh
IiAobW12YWxwKSk7CiAKQEAgLTY3NjYsNyArNjc2Niw3IEBAIHg4Nl9lbXVs
YXRlKAogICAgICAgICBvcGNbMl0gPSAweDkwOwogICAgICAgICAvKiBVc2Ug
KCVyYXgpIGFzIHNvdXJjZS4gKi8KICAgICAgICAgb3BjWzNdID0gZXZleC5v
cG1zayA8PCAzOwotICAgICAgICBvcGNbNF0gPSAweGMzOworICAgICAgICBw
bGFjZV9yZXQoJm9wY1s0XSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIoIiIs
ICIiLCAiK20iIChvcF9tYXNrKSA6ICJhIiAoJm9wX21hc2spKTsKICAgICAg
ICAgcHV0X3N0dWIoc3R1Yik7CkBAIC02ODQ4LDcgKzY4NDgsNyBAQCB4ODZf
ZW11bGF0ZSgKICAgICAgICAgcGV2ZXgtPnIgPSAhbW9kZV82NGJpdCgpIHx8
ICEoc3RhdGUtPnNpYl9pbmRleCAmIDB4MDgpOwogICAgICAgICBwZXZleC0+
UiA9ICFtb2RlXzY0Yml0KCkgfHwgIShzdGF0ZS0+c2liX2luZGV4ICYgMHgx
MCk7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0gICAgICAgIG9wY1syXSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAg
ICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKGluZGV4KSA6ICJhIiAoJmlu
ZGV4KSk7CiAgICAgICAgIHB1dF9zdHViKHN0dWIpOwpAQCAtNzA1OCw3ICs3
MDU4LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHB2ZXgtPnJlZyA9IDB4
ZjsgLyogckFYICovCiAgICAgICAgIGJ1ZlszXSA9IGI7CiAgICAgICAgIGJ1
Zls0XSA9IDB4MDk7IC8qIHJlZz1yQ1ggci9tPSglckNYKSAqLwotICAgICAg
ICBidWZbNV0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls1XSk7
CiAKICAgICAgICAgc3JjLnJlZyA9IGRlY29kZV92ZXhfZ3ByKHZleC5yZWcs
ICZfcmVncywgY3R4dCk7CiAgICAgICAgIGVtdWxhdGVfc3R1YihbZHN0XSAi
PSZjIiAoZHN0LnZhbCksICJbZHN0XSIgKCZzcmMudmFsKSwgImEiICgqc3Jj
LnJlZykpOwpAQCAtNzA5NCw3ICs3MDk0LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIHB2ZXgtPnJlZyA9IDB4ZjsgLyogckFYICovCiAgICAgICAgIGJ1
ZlszXSA9IGI7CiAgICAgICAgIGJ1Zls0XSA9IChtb2RybSAmIDB4MzgpIHwg
MHgwMTsgLyogci9tPSglckNYKSAqLwotICAgICAgICBidWZbNV0gPSAweGMz
OworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls1XSk7CiAKICAgICAgICAgZHN0
LnJlZyA9IGRlY29kZV92ZXhfZ3ByKHZleC5yZWcsICZfcmVncywgY3R4dCk7
CiAgICAgICAgIGVtdWxhdGVfc3R1YigiPSZhIiAoZHN0LnZhbCksICJjIiAo
JnNyYy52YWwpKTsKQEAgLTczMzUsNyArNzMzNSw3IEBAIHg4Nl9lbXVsYXRl
KAogICAgICAgICAgICAgZXZleC53ID0gdmV4LncgPSAwOwogICAgICAgICBv
cGNbMV0gPSBtb2RybSAmIDB4Mzg7CiAgICAgICAgIG9wY1syXSA9IGltbTE7
Ci0gICAgICAgIG9wY1szXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgm
b3BjWzNdKTsKICAgICAgICAgaWYgKCB2ZXgub3BjeCA9PSB2ZXhfbm9uZSAp
CiAgICAgICAgIHsKICAgICAgICAgICAgIC8qIENvdmVyIGZvciBleHRyYSBw
cmVmaXggYnl0ZS4gKi8KQEAgLTc1MDIsNyArNzUwMiw3IEBAIHg4Nl9lbXVs
YXRlKAogICAgICAgICAgICAgaW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDM7
CiAgICAgICAgICAgICBjb3B5X1ZFWChvcGMsIHZleCk7CiAgICAgICAgIH0K
LSAgICAgICAgb3BjWzNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbM10pOwogCiAgICAgICAgIC8qIExhdGNoIE1YQ1NSIC0gd2UgbWF5IG5l
ZWQgdG8gcmVzdG9yZSBpdCBiZWxvdy4gKi8KICAgICAgICAgaW52b2tlX3N0
dWIoInN0bXhjc3IgJVtteGNzcl0iLCAiIiwKQEAgLTc3NDgsNyArNzc0OCw3
IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICB9CiAgICAgICAgIG9wY1syXSA9
IGltbTE7CiAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAzOwot
ICAgICAgICBvcGNbM10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9w
Y1szXSk7CiAgICAgICAgIGlmICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQog
ICAgICAgICB7CiAgICAgICAgICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJl
Zml4IGJ5dGUuICovCkBAIC04MDk0LDcgKzgwOTQsNyBAQCB4ODZfZW11bGF0
ZSgKICAgICAgICAgcHhvcC0+cmVnID0gMHhmOyAvKiByQVggKi8KICAgICAg
ICAgYnVmWzNdID0gYjsKICAgICAgICAgYnVmWzRdID0gKG1vZHJtICYgMHgz
OCkgfCAweDAxOyAvKiByL209KCVyQ1gpICovCi0gICAgICAgIGJ1Zls1XSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzVdKTsKIAogICAgICAg
ICBkc3QucmVnID0gZGVjb2RlX3ZleF9ncHIodmV4LnJlZywgJl9yZWdzLCBj
dHh0KTsKICAgICAgICAgZW11bGF0ZV9zdHViKFtkc3RdICI9JmEiIChkc3Qu
dmFsKSwgImMiICgmc3JjLnZhbCkpOwpAQCAtODIwMyw3ICs4MjAzLDcgQEAg
eDg2X2VtdWxhdGUoCiAgICAgICAgIGJ1ZlszXSA9IGI7CiAgICAgICAgIGJ1
Zls0XSA9IDB4MDk7IC8qIHJlZz1yQ1ggci9tPSglckNYKSAqLwogICAgICAg
ICAqKHVpbnQzMl90ICopKGJ1ZiArIDUpID0gaW1tMTsKLSAgICAgICAgYnVm
WzldID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZidWZbOV0pOwogCiAg
ICAgICAgIGVtdWxhdGVfc3R1YihbZHN0XSAiPSZjIiAoZHN0LnZhbCksICJb
ZHN0XSIgKCZzcmMudmFsKSk7CiAKQEAgLTgyOTMsMTIgKzgyOTMsMTIgQEAg
eDg2X2VtdWxhdGUoCiAgICAgICAgICAgICBCVUcoKTsKICAgICAgICAgaWYg
KCBldmV4X2VuY29kZWQoKSApCiAgICAgICAgIHsKLSAgICAgICAgICAgIG9w
Y1tpbnNuX2J5dGVzIC0gRVZFWF9QRlhfQllURVNdID0gMHhjMzsKKyAgICAg
ICAgICAgIHBsYWNlX3JldCgmb3BjW2luc25fYnl0ZXMgLSBFVkVYX1BGWF9C
WVRFU10pOwogICAgICAgICAgICAgY29weV9FVkVYKG9wYywgZXZleCk7CiAg
ICAgICAgIH0KICAgICAgICAgZWxzZQogICAgICAgICB7Ci0gICAgICAgICAg
ICBvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10gPSAweGMzOworICAgICAg
ICAgICAgcGxhY2VfcmV0KCZvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10p
OwogICAgICAgICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3ByZWZpeCwg
dmV4KTsKICAgICAgICAgfQogCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-06.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-06.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IEJ1aWxkIFhlbiB3aXRoIFJldHVybiBUaHVua3MKClRo
ZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uIHNwZWN1bGF0aXZlIHZ1bG5l
cmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRpcmVjdApicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QgaGFsZiBv
ZiBhIGNhY2hlbGluZS4KCkluIG9yZGVyIHRvIG1pdGlnYXRlIHRoaXMsIGJ1
aWxkIHdpdGggcmV0dXJuIHRodW5rcyBhbmQgYXJyYW5nZSBmb3IKX194ODZf
cmV0dXJuX3RodW5rIHRvIGJlIChtaXMpYWxpZ25lZCBpbiB0aGUgc2FtZSBt
YW5uZXIgYXMKX194ODZfaW5kaXJlY3RfdGh1bmtfKiBzbyB0aGUgUkVUIGlu
c3RydWN0aW9uIGlzIHBsYWNlZCBpbiBhIHNhZmUgbG9jYXRpb24uCgpwbGFj
ZV9yZXQoKSBuZWVkcyB0byBjb25kaXRpb25hbGx5IGVtaXQgSk1QIF9feDg2
X3JldHVybl90aHVuayBpbnN0ZWFkIG9mIFJFVC4KClRoaXMgaXMgcGFydCBv
ZiBYU0EtNDY5IC8gQ1ZFLTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnIGIveGVu
L2FyY2gveDg2L0tjb25maWcKaW5kZXggN2UwM2U0YmM1NTQ2Li40NTQyZWE4
NDA4YzcgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnCisrKyBi
L3hlbi9hcmNoL3g4Ni9LY29uZmlnCkBAIC0zNyw5ICszNywxNCBAQCBjb25m
aWcgQVJDSF9ERUZDT05GSUcKIAlkZWZhdWx0ICJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCiAKIGNvbmZpZyBDQ19IQVNfSU5ESVJFQ1Rf
VEhVTksKKwkjIEdDQyA+PSA4IG9yIENsYW5nID49IDYKIAlkZWZfYm9vbCAk
KGNjLW9wdGlvbiwtbWluZGlyZWN0LWJyYW5jaC1yZWdpc3RlcikgfHwgXAog
CSAgICAgICAgICQoY2Mtb3B0aW9uLC1tcmV0cG9saW5lLWV4dGVybmFsLXRo
dW5rKQogCitjb25maWcgQ0NfSEFTX1JFVFVSTl9USFVOSworCSMgR0NDID49
IDggb3IgQ2xhbmcgPj0gMTUKKwlkZWZfYm9vbCAkKGNjLW9wdGlvbiwtbWZ1
bmN0aW9uLXJldHVybj10aHVuay1leHRlcm4pCisKIGNvbmZpZyBIQVNfQVNf
Q0VUX1NTCiAJIyBiaW51dGlscyA+PSAyLjI5IG9yIExMVk0gPj0gNgogCWRl
Zl9ib29sICQoYXMtaW5zdHIsd3Jzc3EgJXJheCQoY29tbWEpMDtzZXRzc2Jz
eSkKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hlbi9h
cmNoL3g4Ni9NYWtlZmlsZQppbmRleCBhN2U1YTgyNjg5ZGUuLjI3ODA2YTgx
YWNhOCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisrKyBi
L3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtNDMsNiArNDMsNyBAQCBvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KK29iai0kKENPTkZJR19SRVRV
Uk5fVEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KIG9iai0kKENPTkZJR19Q
VikgKz0gaW9wb3J0X2VtdWxhdGUubwogb2JqLXkgKz0gaXJxLm8KIG9iai0k
KENPTkZJR19LRVhFQykgKz0gbWFjaGluZV9rZXhlYy5vCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJvdC5TIGIveGVuL2FyY2gv
eDg2L2FjcGkvd2FrZXVwX3Byb3QuUwppbmRleCA2NmY3OTkzMzk5MTMuLjk3
YmQ2NzZhYWVlMiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvd2Fr
ZXVwX3Byb3QuUworKysgYi94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJv
dC5TCkBAIC0xMzMsNyArMTMzLDcgQEAgRU5UUlkoczNfcmVzdW1lKQogICAg
ICAgICBwb3AgICAgICVyMTIKICAgICAgICAgcG9wICAgICAlcmJ4CiAgICAg
ICAgIHBvcCAgICAgJXJicAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAK
IC5kYXRhCiAgICAgICAgIC5hbGlnbiAxNgpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94ODYvYWx0ZXJuYXRp
dmUuYwppbmRleCBlYzQ1MWQ5NjJjMTAuLjFiNzFhZTk1OWFiZSAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKKysrIGIveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTEzNywxNiArMTM3LDQ1IEBAIHZv
aWQgaW5pdF9vcl9saXZlcGF0Y2ggYWRkX25vcHModm9pZCAqaW5zbnMsIHVu
c2lnbmVkIGludCBsZW4pCiAgICAgfQogfQogCit2b2lkIG5vY2FsbCBfX3g4
Nl9yZXR1cm5fdGh1bmsodm9pZCk7CisKIC8qCiAgKiBQbGFjZSBhIHJldHVy
biBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGluIHRoZSB3cml0YWJsZSBhbGlh
cyBvZiBhIHN0dWIuCiAgKgorICogV2hlbiBDT05GSUdfUkVUVVJOX1RIVU5L
IGlzIGFjdGl2ZSwgdGhpcyBtYXkgYmUgYSBKTVAgX194ODZfcmV0dXJuX3Ro
dW5rCisgKiBpbnN0ZWFkLCBkZXBlbmRpbmcgb24gdGhlIHNhZmV0eSBvZiBA
cHRyIHdpdGggcmVzcGVjdCB0byBJbmRpcmVjdCBUYXJnZXQKKyAqIFNlbGVj
dGlvbi4KKyAqCiAgKiBSZXR1cm5zIHRoZSBuZXh0IHBvc2l0aW9uIHRvIHdy
aXRlIGludG8gdGhlIHN0dWIuCiAgKi8KIHZvaWQgKnBsYWNlX3JldCh2b2lk
ICpwdHIpCiB7CisgICAgdW5zaWduZWQgbG9uZyBhZGRyID0gKHVuc2lnbmVk
IGxvbmcpcHRyOwogICAgIHVpbnQ4X3QgKnAgPSBwdHI7CiAKLSAgICAqcCsr
ID0gMHhjMzsKKyAgICAvKgorICAgICAqIFdoZW4gUmV0dXJuIFRodW5rcyBh
cmUgdXNlZCwgaWYgYSBSRVQgd291bGQgYmUgdW5zYWZlIGF0IHRoaXMgbG9j
YXRpb24KKyAgICAgKiB3aXRoIHJlc3BlY3QgdG8gSW5kaXJlY3QgVGFyZ2V0
IFNlbGVjdGlvbiAoaS5lLiBpZiBhZGRyIGlzIGluIHRoZSBmaXJzdAorICAg
ICAqIGhhbGYgb2YgYSBjYWNoZWxpbmUpLCBpbnNlcnQgYSBKTVAgX194ODZf
cmV0dXJuX3RodW5rIGluc3RlYWQuCisgICAgICoKKyAgICAgKiBUaGUgZGlz
cGxhY2VtZW50IG5lZWRzIHRvIGJlIHJlbGF0aXZlIHRvIHRoZSBleGVjdXRh
YmxlIGFsaWFzIG9mIHRoZQorICAgICAqIHN0dWIsIG5vdCB0byBAcHRyIHdo
aWNoIGlzIHRoZSB3cml0ZWFibGUgYWxpYXMuCisgICAgICovCisgICAgaWYg
KCBJU19FTkFCTEVEKENPTkZJR19SRVRVUk5fVEhVTkspICYmICEoYWRkciAm
IDB4MjApICkKKyAgICB7CisgICAgICAgIGxvbmcgc3R1Yl92YSA9ICh0aGlz
X2NwdShzdHVicy5hZGRyKSAmIFBBR0VfTUFTSykgKyAoYWRkciAmIH5QQUdF
X01BU0spOworICAgICAgICBsb25nIGRpc3AgPSAobG9uZylfX3g4Nl9yZXR1
cm5fdGh1bmsgLSAoc3R1Yl92YSArIDUpOworCisgICAgICAgIEJVR19PTigo
aW50MzJfdClkaXNwICE9IGRpc3ApOworCisgICAgICAgICpwKysgPSAweGU5
OworICAgICAgICAqKGludDMyX3QgKilwID0gZGlzcDsKKyAgICAgICAgcCAr
PSA0OworICAgIH0KKyAgICBlbHNlCisgICAgeworICAgICAgICAqcCsrID0g
MHhjMzsKKyAgICB9CiAKICAgICByZXR1cm4gcDsKIH0KZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rIGIveGVuL2FyY2gveDg2L2FyY2gubWsK
aW5kZXggYjg4ZDA5N2E4NDRiLi44NWQzZTdjYmZlZWIgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rCisrKyBiL3hlbi9hcmNoL3g4Ni9hcmNo
Lm1rCkBAIC00Niw2ICs0Niw5IEBAIENGTEFHUy0kKENPTkZJR19DQ19JU19H
Q0MpICs9IC1mbm8tanVtcC10YWJsZXMKIENGTEFHUy0kKENPTkZJR19DQ19J
U19DTEFORykgKz0gLW1yZXRwb2xpbmUtZXh0ZXJuYWwtdGh1bmsKIGVuZGlm
CiAKKyMgQ29tcGlsZSB3aXRoIHJldHVybiB0aHVuayBzdXBwb3J0IGlmIHNl
bGVjdGVkLgorQ0ZMQUdTLSQoQ09ORklHX1JFVFVSTl9USFVOSykgKz0gLW1m
dW5jdGlvbi1yZXR1cm49dGh1bmstZXh0ZXJuCisKICMgRGlzYWJsZSB0aGUg
YWRkaXRpb24gb2YgYSAubm90ZS5nbnUucHJvcGVydHkgc2VjdGlvbiB0byBv
YmplY3QgZmlsZXMgd2hlbgogIyBsaXZlcGF0Y2ggc3VwcG9ydCBpcyBlbmFi
bGVkLiAgVGhlIGNvbnRlbnRzIG9mIHRoYXQgc2VjdGlvbiBjYW4gY2hhbmdl
CiAjIGRlcGVuZGluZyBvbiB0aGUgaW5zdHJ1Y3Rpb25zIHVzZWQsIGFuZCBs
aXZlcGF0Y2gtYnVpbGQtdG9vbHMgZG9lc24ndCBrbm93CmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYmhiLXRodW5rLlMgYi94ZW4vYXJjaC94ODYvYmhi
LXRodW5rLlMKaW5kZXggNTI2MjVmNGUyYzE3Li43ZjkyMjAxYTNjYmIgMTAw
NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUworKysgYi94ZW4v
YXJjaC94ODYvYmhiLXRodW5rLlMKQEAgLTIzLDcgKzIzLDcgQEAgRlVOQyhj
bGVhcl9iaGJfdHN4KQogMDogICAgICAuYnl0ZSAweGM2LCAweGY4LCAwICAg
ICAgICAgICAgIC8qIHhhYm9ydCAkMCAqLwogICAgICAgICBpbnQzCiAxOgot
ICAgICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQoY2xlYXJfYmhiX3RzeCkK
IAogLyoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jbGVhcl9wYWdlLlMg
Yi94ZW4vYXJjaC94ODYvY2xlYXJfcGFnZS5TCmluZGV4IGQ2YzA3NmYxZDhi
Yy4uZGMzYzNjMjZiZmI3IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvY2xl
YXJfcGFnZS5TCisrKyBiL3hlbi9hcmNoL3g4Ni9jbGVhcl9wYWdlLlMKQEAg
LTEsNiArMSw4IEBACiAgICAgICAgIC5maWxlIF9fRklMRV9fCiAKICNpbmNs
dWRlIDx4ZW4vbGlua2FnZS5oPgorCisjaW5jbHVkZSA8YXNtL2FzbV9kZWZu
cy5oPgogI2luY2x1ZGUgPGFzbS9wYWdlLmg+CiAKIEZVTkMoY2xlYXJfcGFn
ZV9zc2UyKQpAQCAtMTYsNSArMTgsNSBAQCBGVU5DKGNsZWFyX3BhZ2Vfc3Nl
MikKICAgICAgICAgam56ICAgICAwYgogCiAgICAgICAgIHNmZW5jZQotICAg
ICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQoY2xlYXJfcGFnZV9zc2UyKQpk
aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2NvcHlfcGFnZS5TIGIveGVuL2Fy
Y2gveDg2L2NvcHlfcGFnZS5TCmluZGV4IGMzYzQzNjU0NWJhYy4uZTQzZTUz
NzBjODE1IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvY29weV9wYWdlLlMK
KysrIGIveGVuL2FyY2gveDg2L2NvcHlfcGFnZS5TCkBAIC0xLDYgKzEsOCBA
QAogICAgICAgICAuZmlsZSBfX0ZJTEVfXwogCiAjaW5jbHVkZSA8eGVuL2xp
bmthZ2UuaD4KKworI2luY2x1ZGUgPGFzbS9hc21fZGVmbnMuaD4KICNpbmNs
dWRlIDxhc20vcGFnZS5oPgogCiAjZGVmaW5lIHNyY19yZWcgJXJzaQpAQCAt
NDEsNSArNDMsNSBAQCBGVU5DKGNvcHlfcGFnZV9zc2UyKQogICAgICAgICBt
b3ZudGkgIHRtcDRfcmVnLCAzKldPUkRfU0laRShkc3RfcmVnKQogCiAgICAg
ICAgIHNmZW5jZQotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQoY29w
eV9wYWdlX3NzZTIpCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvZWZpL2No
ZWNrLmMgYi94ZW4vYXJjaC94ODYvZWZpL2NoZWNrLmMKaW5kZXggOWU0NzNm
YWFkM2M5Li4yM2JhMzBhYmYzMzAgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9lZmkvY2hlY2suYworKysgYi94ZW4vYXJjaC94ODYvZWZpL2NoZWNrLmMK
QEAgLTMsNiArMyw5IEBAIGludCBfX2F0dHJpYnV0ZV9fKChfX21zX2FiaV9f
KSkgdGVzdChpbnQgaSkKICAgICByZXR1cm4gaTsKIH0KIAorLyogSW4gY2Fz
ZSAtbWZ1bmN0aW9uLXJldHVybiBpcyBpbiB1c2UuICovCit2b2lkIF9feDg2
X3JldHVybl90aHVuayh2b2lkKSB7fTsKKwogLyoKICAqIFBvcHVsYXRlIGFu
IGFycmF5IHdpdGggImFkZHJlc3NlcyIgb2YgcmVsb2NhdGFibGUgYW5kIGFi
c29sdXRlIHZhbHVlcy4KICAqIFRoaXMgaXMgdG8gcHJvYmUgbGQgZm9yIChh
KSBlbWl0dGluZyBiYXNlIHJlbG9jYXRpb25zIGF0IGFsbCBhbmQgKGIpIG5v
dApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1k
ZWZucy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1kZWZucy5o
CmluZGV4IDMyZDZiNDQ5MTA2My4uOTdlYmUyMTI5OGEyIDEwMDY0NAotLS0g
YS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYXNtLWRlZm5zLmgKKysrIGIv
eGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1kZWZucy5oCkBAIC01OCw2
ICs1OCwxMiBAQAogICAgIC5lbmRpZgogLmVuZG0KIAorI2lmZGVmIENPTkZJ
R19SRVRVUk5fVEhVTksKKyMgZGVmaW5lIFJFVCBqbXAgX194ODZfcmV0dXJu
X3RodW5rCisjZWxzZQorIyBkZWZpbmUgUkVUIHJldAorI2VuZGlmCisKICNp
ZmRlZiBDT05GSUdfWEVOX0lCVAogIyBkZWZpbmUgRU5EQlI2NCBlbmRicjY0
CiAjZWxzZQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luZGlyZWN0LXRo
dW5rLlMgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwppbmRleCBj
NGI5NzhkNjdiOGUuLjI2ZGFkMTVmMTJjOSAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2luZGlyZWN0LXRodW5rLlMKKysrIGIveGVuL2FyY2gveDg2L2lu
ZGlyZWN0LXRodW5rLlMKQEAgLTE1LDYgKzE1LDggQEAKICN1bmRlZiBTWU1f
QUxJR04KICNkZWZpbmUgU1lNX0FMSUdOKGFsaWduLi4uKQogCisjaWZkZWYg
Q09ORklHX0lORElSRUNUX1RIVU5LCisKIC5tYWNybyBJTkRfVEhVTktfUkVU
UE9MSU5FIHJlZzpyZXEKICAgICAgICAgY2FsbCAxZgogICAgICAgICBpbnQz
CkBAIC02MiwzICs2NCwyNSBAQCBFTkQoX194ODZfaW5kaXJlY3RfdGh1bmtf
XHJlZykKIC5pcnAgcmVnLCBheCwgY3gsIGR4LCBieCwgYnAsIHNpLCBkaSwg
OCwgOSwgMTAsIDExLCAxMiwgMTMsIDE0LCAxNQogICAgICAgICBHRU5fSU5E
SVJFQ1RfVEhVTksgcmVnPXJccmVnCiAuZW5kcgorCisjZW5kaWYgLyogQ09O
RklHX0lORElSRUNUX1RIVU5LICovCisKKyNpZmRlZiBDT05GSUdfUkVUVVJO
X1RIVU5LCisgICAgICAgIC5zZWN0aW9uIC50ZXh0LmVudHJ5Ll9feDg2X3Jl
dHVybl90aHVuaywgImF4IiwgQHByb2diaXRzCisKKyAgICAgICAgLyoKKyAg
ICAgICAgICogVGhlIEluZGlyZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3Vs
YXRpdmUgdnVsbmVyYWJpbGl0eSBtZWFucyB0aGF0CisgICAgICAgICAqIGlu
ZGlyZWN0IGJyYW5jaGVzIChpbmNsdWRpbmcgUkVUcykgYXJlIHVuc2FmZSB3
aGVuIGluIHRoZSBmaXJzdAorICAgICAgICAgKiBoYWxmIG9mIGEgY2FjaGVs
aW5lLiAgQXJyYW5nZSBmb3IgdGhlbSB0byBiZSBpbiB0aGUgc2Vjb25kIGhh
bGYuCisgICAgICAgICAqCisgICAgICAgICAqIEFsaWduIHRvIDY0LCB0aGVu
IHNraXAgMzIuCisgICAgICAgICAqLworICAgICAgICAuYmFsaWduIDY0Cisg
ICAgICAgIC5maWxsIDMyLCAxLCAweGNjCisKK0ZVTkMoX194ODZfcmV0dXJu
X3RodW5rKQorICAgICAgICByZXQKKyAgICAgICAgaW50MyAvKiBIYWx0IHN0
cmFpZ2h0LWxpbmUgc3BlY3VsYXRpb24gKi8KK0VORChfX3g4Nl9yZXR1cm5f
dGh1bmspCisKKyNlbmRpZiAvKiBDT05GSUdfUkVUVVJOX1RIVU5LICovCmRp
ZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMgYi94
ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMKaW5kZXggZmY1ZDFjOWY4
NjM0Li4yOTVkODQ3ZWEyNGMgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9w
di9lbXVsLXByaXYtb3AuYworKysgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1w
cml2LW9wLmMKQEAgLTEzMSw3ICsxMzEsNyBAQCBzdGF0aWMgaW9fZW11bF9z
dHViX3QgKmlvX2VtdWxfc3R1Yl9zZXR1cChzdHJ1Y3QgcHJpdl9vcF9jdHh0
ICpjdHh0LCB1OCBvcGNvZGUsCiAgICAgQlVJTERfQlVHX09OKFNUVUJfQlVG
X1NJWkUgLyAyIDwKICAgICAgICAgICAgICAgICAgKHNpemVvZihwcm9sb2d1
ZSkgKyBzaXplb2YoZXBpbG9ndWUpICsgMTAgLyogMnggY2FsbCAqLyArCiAg
ICAgICAgICAgICAgICAgICBNQVgoMyAvKiBkZWZhdWx0IHN0dWIgKi8sIElP
RU1VTF9RVUlSS19TVFVCX0JZVEVTKSArCi0gICAgICAgICAgICAgICAgICAx
IC8qIHJldCAqLykpOworICAgICAgICAgICAgICAgICAgKElTX0VOQUJMRUQo
Q09ORklHX1JFVFVSTl9USFVOSykgPyA1IDogMSkgLyogcmV0ICovKSk7CiAg
ICAgLyogUnVudGltZSBjb25maXJtYXRpb24gdGhhdCB3ZSBoYXZlbid0IGNs
b2JiZXJlZCBhbiBhZGphY2VudCBzdHViLiAqLwogICAgIEJVR19PTihTVFVC
X0JVRl9TSVpFIC8gMiA8IChwIC0gY3R4dC0+aW9fZW11bF9zdHViKSk7CiAK
ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9wdi9ncHJfc3dpdGNoLlMgYi94
ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5TCmluZGV4IDU0MDlhZDNiMTQ0
Ny4uMzYyYjVkMjQxNjIzIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvcHYv
Z3ByX3N3aXRjaC5TCisrKyBiL3hlbi9hcmNoL3g4Ni9wdi9ncHJfc3dpdGNo
LlMKQEAgLTI2LDcgKzI2LDcgQEAgRlVOQyhsb2FkX2d1ZXN0X2dwcnMpCiAg
ICAgICAgIG1vdnEgIFVSRUdTX3IxNSglcmRpKSwgJXIxNQogICAgICAgICBt
b3ZxICBVUkVHU19yY3goJXJkaSksICVyY3gKICAgICAgICAgbW92cSAgVVJF
R1NfcmRpKCVyZGkpLCAlcmRpCi0gICAgICAgIHJldAorICAgICAgICBSRVQK
IEVORChsb2FkX2d1ZXN0X2dwcnMpCiAKIC8qIFNhdmUgZ3Vlc3QgR1BScy4g
IFBhcmFtZXRlciBvbiB0aGUgc3RhY2sgYWJvdmUgdGhlIHJldHVybiBhZGRy
ZXNzLiAqLwpAQCAtNDgsNSArNDgsNSBAQCBGVU5DKHNhdmVfZ3Vlc3RfZ3By
cykKICAgICAgICAgbW92cSAgJXJieCwgVVJFR1NfcmJ4KCVyZGkpCiAgICAg
ICAgIG1vdnEgICVyZHgsIFVSRUdTX3JkeCglcmRpKQogICAgICAgICBtb3Zx
ICAlcmN4LCBVUkVHU19yY3goJXJkaSkKLSAgICAgICAgcmV0CisgICAgICAg
IFJFVAogRU5EKHNhdmVfZ3Vlc3RfZ3BycykKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu
YwppbmRleCAzNTM1MTA0NGY5MDEuLjAxOWEwYTgxZjRhNyAxMDA2NDQKLS0t
IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCisrKyBiL3hlbi9hcmNoL3g4
Ni9zcGVjX2N0cmwuYwpAQCAtNTY5LDYgKzU2OSw5IEBAIHN0YXRpYyB2b2lk
IF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rKQog
I2lmZGVmIENPTkZJR19JTkRJUkVDVF9USFVOSwogICAgICAgICAgICAgICAg
IiBJTkRJUkVDVF9USFVOSyIKICNlbmRpZgorI2lmZGVmIENPTkZJR19SRVRV
Uk5fVEhVTksKKyAgICAgICAgICAgICAgICIgUkVUVVJOX1RIVU5LIgorI2Vu
ZGlmCiAjaWZkZWYgQ09ORklHX1NIQURPV19QQUdJTkcKICAgICAgICAgICAg
ICAgICIgU0hBRE9XX1BBR0lORyIKICNlbmRpZgpkaWZmIC0tZ2l0IGEveGVu
L2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUyBiL3hlbi9hcmNoL3g4
Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKaW5kZXggYTk5NjQ2YzBjZDRlLi4x
OGY0NmM3OGNmYmUgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQv
Y29tcGF0L2VudHJ5LlMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21w
YXQvZW50cnkuUwpAQCAtMTgwLDcgKzE4MCw3IEBAIEZVTkMoY3I0X3B2MzJf
cmVzdG9yZSkKICAgICAgICAgb3IgICAgY3I0X3B2MzJfbWFzayglcmlwKSwg
JXJheAogICAgICAgICBtb3YgICAlcmF4LCAlY3I0CiAgICAgICAgIG1vdiAg
ICVyYXgsICglcmN4KQotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAwOgog
I2lmbmRlZiBOREVCVUcKICAgICAgICAgLyogQ2hlY2sgdGhhdCBfYWxsXyBv
ZiB0aGUgYml0cyBpbnRlbmRlZCB0byBiZSBzZXQgYWN0dWFsbHkgYXJlLiAq
LwpAQCAtMTk4LDcgKzE5OCw3IEBAIEZVTkMoY3I0X3B2MzJfcmVzdG9yZSkK
IDE6CiAjZW5kaWYKICAgICAgICAgeG9yICAgJWVheCwgJWVheAotICAgICAg
ICByZXQKKyAgICAgICAgUkVUCiBFTkQoY3I0X3B2MzJfcmVzdG9yZSkKIAog
RlVOQyhjb21wYXRfc3lzY2FsbCkKQEAgLTMyOSw3ICszMjksNyBAQCBfX1VO
TElLRUxZX0VORChjb21wYXRfYm91bmNlX251bGxfc2VsZWN0b3IpCiAgICAg
ICAgIHhvciAgICVlYXgsICVlYXgKICAgICAgICAgbW92ICAgJWF4LCAgVFJB
UEJPVU5DRV9jcyglcmR4KQogICAgICAgICBtb3YgICAlYWwsICBUUkFQQk9V
TkNFX2ZsYWdzKCVyZHgpCi0gICAgICAgIHJldAorICAgICAgICBSRVQKIAog
LnNlY3Rpb24gLmZpeHVwLCJheCIKIC5MZngxMzoKZGlmZiAtLWdpdCBhL3hl
bi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUyBiL3hlbi9hcmNoL3g4Ni94ODZf
NjQvZW50cnkuUwppbmRleCA5YjBjZGI3NjQwOGIuLmViNjJlN2MzMjliZCAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCisrKyBi
L3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwpAQCAtNjA0LDcgKzYwNCw3
IEBAIF9fVU5MSUtFTFlfRU5EKGNyZWF0ZV9ib3VuY2VfZnJhbWVfYmFkX2Jv
dW5jZV9pcCkKICAgICAgICAgeG9yICAgJWVheCwgJWVheAogICAgICAgICBt
b3YgICAlcmF4LCBUUkFQQk9VTkNFX2VpcCglcmR4KQogICAgICAgICBtb3Yg
ICAlYWwsICBUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCi0gICAgICAgIHJldAor
ICAgICAgICBSRVQKIAogICAgICAgICAucHVzaHNlY3Rpb24gLmZpeHVwLCAi
YXgiLCBAcHJvZ2JpdHMKICAgICAgICAgIyBOdW1lcmljIHRhZ3MgYmVsb3cg
cmVwcmVzZW50IHRoZSBpbnRlbmRlZCBvdmVyYWxsICVyc2kgYWRqdXN0bWVu
dC4KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMgYi94ZW4v
YXJjaC94ODYveGVuLmxkcy5TCmluZGV4IDlhMWRmZTFiMzQwYS4uNTA2OTkz
ODY3NTAyIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYveGVuLmxkcy5TCisr
KyBiL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMKQEAgLTgyLDYgKzgyLDcgQEAg
U0VDVElPTlMKICAgICAgICAuID0gQUxJR04oUEFHRV9TSVpFKTsKICAgICAg
ICBfc3RleHRlbnRyeSA9IC47CiAgICAgICAgKigudGV4dC5lbnRyeSkKKyAg
ICAgICAqKC50ZXh0LmVudHJ5LiopCiAgICAgICAgLiA9IEFMSUdOKFBBR0Vf
U0laRSk7CiAgICAgICAgX2V0ZXh0ZW50cnkgPSAuOwogCmRpZmYgLS1naXQg
YS94ZW4vY29tbW9uL0tjb25maWcgYi94ZW4vY29tbW9uL0tjb25maWcKaW5k
ZXggNTY1Y2VkYTc0MWI5Li5kYTBmYTc1Mjc2NDMgMTAwNjQ0Ci0tLSBhL3hl
bi9jb21tb24vS2NvbmZpZworKysgYi94ZW4vY29tbW9uL0tjb25maWcKQEAg
LTEzMCw2ICsxMzAsMTcgQEAgY29uZmlnIElORElSRUNUX1RIVU5LCiAJICBX
aGVuIGVuYWJsZWQsIGluZGlyZWN0IGJyYW5jaGVzIGFyZSBpbXBsZW1lbnRl
ZCB1c2luZyBhIG5ldyBjb25zdHJ1Y3QKIAkgIGNhbGxlZCAicmV0cG9saW5l
IiB0aGF0IHByZXZlbnRzIHNwZWN1bGF0aW9uLgogCitjb25maWcgUkVUVVJO
X1RIVU5LCisJYm9vbCAiT3V0LW9mLWxpbmUgUmV0dXJucyIKKwlkZXBlbmRz
IG9uIENDX0hBU19SRVRVUk5fVEhVTksKKwlkZWZhdWx0IElORElSRUNUX1RI
VU5LCisJaGVscAorCSAgQ29tcGlsZSBYZW4gd2l0aCBvdXQtb2YtbGluZSBy
ZXR1cm5zLgorCisJICBUaGlzIGFsbG93cyBYZW4gdG8gbWl0aWdhdGUgYSB2
YXJpZXR5IG9mIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdGllcworCSAgYnkg
Y2hvb3NpbmcgYSBoYXJkd2FyZS1kZXBlbmRlbnQgaW5zdHJ1Y3Rpb24gc2Vx
dWVuY2UgdG8gaW1wbGVtZW50CisJICBmdW5jdGlvbiByZXR1cm5zIHNhZmVs
eS4KKwogY29uZmlnIFNQRUNVTEFUSVZFX0hBUkRFTl9BUlJBWQogCWJvb2wg
IlNwZWN1bGF0aXZlIEFycmF5IEhhcmRlbmluZyIKIAlkZWZhdWx0IHkK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-07.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-07.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogU3ludGhlc2lzZSBJVFNfTk8g
dG8gZ3Vlc3RzIG9uIHVuYWZmZWN0ZWQgaGFyZHdhcmUKCkl0IGlzIGVhc2ll
ciB0byBleHByZXNzIGZlYXR1cmUgd29yZCAxNyBpbiB0ZXJtcyBvZiB3b3Jk
IDE2ICsgWzMyLCA2NCkgYXMKdGhhdCdzIGhvdyB0aGUgbGF5b3V0IGlzIGdp
dmVuIGluIGRvY3VtZW50YXRpb24uCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2
OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29v
cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKaW5k
ZXggOWJjNTUzNjgxZjRhLi4xNzI5YmEwYzMwOTcgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKKysrIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaApAQCAtMjE2LDYg
KzIxNiw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBib290X2NwdV9oYXModW5z
aWduZWQgaW50IGZlYXQpCiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAgICAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCiAjZGVmaW5l
IGNwdV9oYXNfcmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9SRkRTX05PKQogI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIgICAg
ICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKKyNkZWZp
bmUgY3B1X2hhc19pdHNfbm8gICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX0lUU19OTykKIAogLyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5l
IGNwdV9oYXNfYXJjaF9wZXJmbW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9BUkNIX1BFUkZNT04pCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg
MDE5YTBhODFmNGE3Li45NGNkYmQ1MjFjNGQgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMKQEAgLTE3ODEsNiArMTc4MSw5MCBAQCBzdGF0aWMgdm9pZCBfX2lu
aXQgYmhpX2NhbGN1bGF0aW9ucyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAq
IGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZl
bG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1
aWRhbmNlL2Fkdmlzb3J5LWd1aWRhbmNlL2luZGlyZWN0LXRhcmdldC1zZWxl
Y3Rpb24uaHRtbAorICovCitzdGF0aWMgdm9pZCBfX2luaXQgaXRzX2NhbGN1
bGF0aW9ucyh2b2lkKQoreworICAgIC8qCisgICAgICogSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBpcyBhIEJyYW5jaCBQcmVkaWN0aW9uIGJ1ZyB3aGVy
ZWJ5IGNlcnRhaW4KKyAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGdldCBwcmVkaWN0ZWQgdXNpbmcgYSBkaXJlY3QgYnJhbmNo
CisgICAgICogdGFyZ2V0LCByYXRoZXIgdGhhbiBhIHN1aXRhYmxlIGluZGly
ZWN0IHRhcmdldCwgYnlwYXNzaW5nIGhhcmR3YXJlCisgICAgICogaXNvbGF0
aW9uIHByb3RlY3Rpb25zLgorICAgICAqCisgICAgICogSVRTIGFmZmVjdHMg
Q29yZSAoYnV0IG5vdCBBdG9tKSBwcm9jZXNzb3JzIHN0YXJ0aW5nIGZyb20g
dGhlCisgICAgICogaW50cm9kdWN0aW9uIG9mIGVJQlJTLCB1cCB0byBidXQg
bm90IGluY2x1ZGluZyBHb2xkZW4gQ292ZSBjb3JlcworICAgICAqIChjaGVj
a2VkIGhlcmUgd2l0aCBCSElfQ1RSTCkuCisgICAgICoKKyAgICAgKiBUaGUg
SVRTX05PIGZlYXR1cmUgaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVudW1lcmF0
ZWQgYnkgaGFyZHdhcmUsIGFuZCBpcworICAgICAqIG9ubHkgZm9yIFZNTXMg
dG8gc3ludGhlc2lzZSBmb3IgZ3Vlc3RzLgorICAgICAqCisgICAgICogSVRT
IGNvbWVzIGluIDMgZmxhdm91cnM6CisgICAgICoKKyAgICAgKiAgIDEpIEFj
cm9zcy1JQlBCLiAgSW5kaXJlY3QgYnJhbmNoZXMgYWZ0ZXIgdGhlIElCUEIg
Y2FuIGJlIGNvbnRyb2xsZWQKKyAgICAgKiAgICAgIGJ5IGRpcmVjdCB0YXJn
ZXRzIHdoaWNoIGV4aXN0ZWQgcHJpb3IgdG8gdGhlIElCUEIuICBUaGlzIGlz
CisgICAgICogICAgICBhZGRyZXNzZWQgaW4gdGhlIElQVSAyMDI1LjEgbWlj
cm9jb2RlIGRyb3AsIGFuZCBoYXMgbm8gb3RoZXIKKyAgICAgKiAgICAgIHNv
ZnR3YXJlIGludGVyYWN0aW9uLgorICAgICAqCisgICAgICogICAyKSBHdWVz
dC9Ib3N0LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgZGlyZWN0IHRhcmdldHMgZnJv
bSB0aGUgZ3Vlc3QuICBUaGlzIGFwcGxpZXMgZXF1YWxseSB0byBQViBndWVz
dHMKKyAgICAgKiAgICAgIChSaW5nMykgYW5kIEhWTSBndWVzdHMgKFZNWCks
IGFuZCBhcHBsaWVzIHRvIGFsbCBTa3lsYWtlLXVhcmNoCisgICAgICogICAg
ICBjb3JlcyB3aXRoIGVJQlJTLgorICAgICAqCisgICAgICogICAzKSBJbnRy
YS1tb2RlLiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgb3RoZXIgZXhlY3V0aW9uIGlu
IHRoZSBzYW1lIG1vZGUuCisgICAgICovCisKKyAgICAvKgorICAgICAqIElm
IHdlIGNhbiBzZWUgSVRTX05PLCBvciB3ZSdyZSB2aXJ0dWFsaXNlZCwgZG8g
bm90aGluZy4gIFdlIGFyZSBvciBtYXkKKyAgICAgKiBtaWdyYXRlIHNvbWV3
aGVyZSB1bnNhZmUuCisgICAgICovCisgICAgaWYgKCBjcHVfaGFzX2l0c19u
byB8fCBjcHVfaGFzX2h5cGVydmlzb3IgKQorICAgICAgICByZXR1cm47CisK
KyAgICAvKiBJVFMgaXMgb25seSBrbm93biB0byBhZmZlY3QgSW50ZWwgcHJv
Y2Vzc29ycyBhdCB0aGlzIHRpbWUuICovCisgICAgaWYgKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9JTlRFTCApCisgICAgICAg
IHJldHVybjsKKworICAgIC8qCisgICAgICogSVRTIGRvZXMgbm90IGV4aXN0
IG9uOgorICAgICAqICAtIG5vbi1GYW1pbHkgNiBDUFVzCisgICAgICogIC0g
dGhvc2Ugd2l0aG91dCBlSUJSUworICAgICAqICAtIHRob3NlIHdpdGggQkhJ
X0NUUkwKKyAgICAgKiBidXQgd2Ugc3RpbGwgbmVlZCB0byBzeW50aGVzaXNl
IElUU19OTy4KKyAgICAgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2
ICE9IDYgfHwgIWNwdV9oYXNfZWlicnMgfHwKKyAgICAgICAgIGJvb3RfY3B1
X2hhcyhYODZfRkVBVFVSRV9CSElfQ1RSTCkgKQorICAgICAgICBnb3RvIHN5
bnRoZXNpc2U7CisKKyAgICBzd2l0Y2ggKCBib290X2NwdV9kYXRhLng4Nl9t
b2RlbCApCisgICAgeworICAgICAgICAvKiBUaGVzZSBTa3lsYWtlLXVhcmNo
IGNvcmVzIHN1ZmZlciBjYXNlcyAjMiBhbmQgIzMuICovCisgICAgY2FzZSBJ
TlRFTF9GQU02X1NLWUxBS0VfWDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FC
WUxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0U6CisgICAg
Y2FzZSBJTlRFTF9GQU02X0NPTUVUTEFLRToKKyAgICBjYXNlIElOVEVMX0ZB
TTZfQ09NRVRMQUtFX0w6CisgICAgICAgIHJldHVybjsKKworICAgICAgICAv
KiBUaGVzZSBTdW5ueS9XaWxsb3cvQ3lwcmVzcyBDb3ZlIGNvcmVzIHN1ZmZl
ciBjYXNlICMzLiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9JQ0VMQUtFX1g6
CisgICAgY2FzZSBJTlRFTF9GQU02X0lDRUxBS0VfRDoKKyAgICBjYXNlIElO
VEVMX0ZBTTZfSUNFTEFLRV9MOgorICAgIGNhc2UgSU5URUxfRkFNNl9USUdF
UkxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfVElHRVJMQUtFOgorICAg
IGNhc2UgSU5URUxfRkFNNl9ST0NLRVRMQUtFOgorICAgICAgICByZXR1cm47
CisKKyAgICBkZWZhdWx0OgorICAgICAgICBicmVhazsKKyAgICB9CisKKyAg
ICAvKiBQbGF0Zm9ybXMgcmVtYWluaW5nIGFyZSBub3QgYmVsaWV2ZWQgdG8g
YmUgdnVsbmVyYWJsZSB0byBJVFMuICovCisgc3ludGhlc2lzZToKKyAgICBz
ZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX0lUU19OTyk7Cit9CisK
IHZvaWQgc3BlY19jdHJsX2luaXRfZG9tYWluKHN0cnVjdCBkb21haW4gKmQp
CiB7CiAgICAgYm9vbCBwdiA9IGlzX3B2X2RvbWFpbihkKTsKQEAgLTIzMzEs
NiArMjQxNSw4IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0
aWdhdGlvbnModm9pZCkKIAogICAgIGJoaV9jYWxjdWxhdGlvbnMoKTsKIAor
ICAgIGl0c19jYWxjdWxhdGlvbnMoKTsKKwogICAgIHByaW50X2RldGFpbHMo
dGh1bmspOwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IDljOThlNDk5
Mjg2MS4uNGQ5ZTQ2OGFmNjUzIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNs
dWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTM2NSw3
ICszNjUsOCBAQCBYRU5fQ1BVRkVBVFVSRShHRFNfTk8sICAgICAgICAgICAg
IDE2KjMyKzI2KSAvKkEgIE5vIEdhdGhlciBEYXRhIFNhbXBsaW5nICovCiBY
RU5fQ1BVRkVBVFVSRShSRkRTX05PLCAgICAgICAgICAgIDE2KjMyKzI3KSAv
KkEgIE5vIFJlZ2lzdGVyIEZpbGUgRGF0YSBTYW1wbGluZyAqLwogWEVOX0NQ
VUZFQVRVUkUoUkZEU19DTEVBUiwgICAgICAgICAxNiozMisyOCkgLyohQXwg
UmVnaXN0ZXIgRmlsZShzKSBjbGVhcmVkIGJ5IFZFUlcgKi8KIAotLyogSW50
ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMsIE1TUl9BUkNIX0NBUFMgMHgxMGEu
ZWR4LCB3b3JkIDE3ICovCisvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl
cywgTVNSX0FSQ0hfQ0FQUyAweDEwYS5lZHgsIHdvcmQgMTcgKGV4cHJlc3Mg
aW4gdGVybXMgb2Ygd29yZCAxNikgKi8KK1hFTl9DUFVGRUFUVVJFKElUU19O
TywgICAgICAgICAgICAgMTYqMzIrNjIpIC8qIUEgTm8gSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiAqLwogCiAjZW5kaWYgLyogWEVOX0NQVUZFQVRVUkUg
Ki8KIApkaWZmIC0tZ2l0IGEveGVuL3Rvb2xzL2dlbi1jcHVpZC5weSBiL3hl
bi90b29scy9nZW4tY3B1aWQucHkKaW5kZXggNjAxZWVjNjA4OTgzLi5kYzMz
Y2EzMTgxYjEgMTAwNzU1Ci0tLSBhL3hlbi90b29scy9nZW4tY3B1aWQucHkK
KysrIGIveGVuL3Rvb2xzL2dlbi1jcHVpZC5weQpAQCAtNTEsNyArNTEsNyBA
QCBkZWYgcGFyc2VfZGVmaW5pdGlvbnMoc3RhdGUpOgogICAgICAgICByIlxz
Ky9cKihbXHchfF0qKSAuKiQiKQogCiAgICAgd29yZF9yZWdleCA9IHJlLmNv
bXBpbGUoCi0gICAgICAgIHIiXi9cKiAuKiB3b3JkIChcZCopIFwqLyQiKQor
ICAgICAgICByIl4vXCogLiogd29yZCAoXGQqKSAuKlwqLyQiKQogICAgIGxh
c3Rfd29yZCA9IC0xCiAKICAgICB0aGlzID0gc3lzLm1vZHVsZXNbX19uYW1l
X19dCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-01.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-01.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2FsdGVybmF0aXZlOiBTdXBwb3J0IHJlcGxhY2Vt
ZW50cyB3aGVuIGEgZmVhdHVyZSBpcyBub3QgcHJlc2VudAoKVXNlIHRoZSB0
b3AgYml0IG9mIGEtPmNwdWlkIHRvIGV4cHJlc3MgaW52ZXJ0ZWQgcG9sYXJp
dHkuICBUaGlzIHJlcXVpcmVzCnN0cmlwcGluZyB0aGUgdG9wIGJpdCBiYWNr
IG91dCB3aGVuIHBlcmZvcm1pbmcgdGhlIHNhbml0eSBjaGVja3MuCgpEZXNw
aXRlIG9ubHkgYmVpbmcgdXNlZCBvbmNlLCBjcmVhdGUgYSByZXBsYWNlIGJv
b2xlYW4gdG8gZXhwcmVzcyB0aGUgZGVjaXNpb24KbW9yZSBjbGVhcmx5IGlu
IF9hcHBseV9hbHRlcm5hdGl2ZXMoKS4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0t
Z2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94
ODYvYWx0ZXJuYXRpdmUuYwppbmRleCAxYmEzNWNiOWVkZTkuLjg4YzkwMDQ0
YzIwZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMK
KysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTE5Nyw2ICsx
OTcsOCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBseV9h
bHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAgICAg
IHVpbnQ4X3QgKnJlcGwgPSBBTFRfUkVQTF9QVFIoYSk7CiAgICAgICAgIHVp
bnQ4X3QgYnVmW01BWF9QQVRDSF9MRU5dOwogICAgICAgICB1bnNpZ25lZCBp
bnQgdG90YWxfbGVuID0gYS0+b3JpZ19sZW4gKyBhLT5wYWRfbGVuOworICAg
ICAgICB1bnNpZ25lZCBpbnQgZmVhdCA9IGEtPmNwdWlkICYgfkFMVF9GTEFH
X05PVDsKKyAgICAgICAgYm9vbCBpbnYgPSBhLT5jcHVpZCAmIEFMVF9GTEFH
X05PVCwgcmVwbGFjZTsKIAogICAgICAgICBpZiAoIGEtPnJlcGxfbGVuID4g
dG90YWxfbGVuICkKICAgICAgICAgewpAQCAtMjE0LDExICsyMTYsMTEgQEAg
c3RhdGljIGludCBpbml0X29yX2xpdmVwYXRjaCBfYXBwbHlfYWx0ZXJuYXRp
dmVzKHN0cnVjdCBhbHRfaW5zdHIgKnN0YXJ0LAogICAgICAgICAgICAgcmV0
dXJuIC1FTk9TUEM7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAoIGEtPmNw
dWlkID49IE5DQVBJTlRTICogMzIgKQorICAgICAgICBpZiAoIGZlYXQgPj0g
TkNBUElOVFMgKiAzMiApCiAgICAgICAgIHsKICAgICAgICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUgogICAgICAgICAgICAgICAgICAgICJBbHQgZm9yICVw
cywgZmVhdHVyZSAlI3ggb3V0c2lkZSBvZiBmZWF0dXJlc2V0IHJhbmdlICUj
eFxuIiwKLSAgICAgICAgICAgICAgICAgICBBTFRfT1JJR19QVFIoYSksIGEt
PmNwdWlkLCBOQ0FQSU5UUyAqIDMyKTsKKyAgICAgICAgICAgICAgICAgICBB
TFRfT1JJR19QVFIoYSksIGZlYXQsIE5DQVBJTlRTICogMzIpOwogICAgICAg
ICAgICAgcmV0dXJuIC1FUkFOR0U7CiAgICAgICAgIH0KIApAQCAtMjQzLDgg
KzI0NSwxNCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAg
ICAgICAgICBjb250aW51ZTsKICAgICAgICAgfQogCisgICAgICAgIC8qCisg
ICAgICAgICAqIFNob3VsZCBhIHJlcGxhY2VtZW50IGJlIHBlcmZvcm1lZD8g
IE1vc3QgcmVwbGFjZW1lbnRzIGhhdmUgcG9zaXRpdmUKKyAgICAgICAgICog
cG9sYXJpdHksIGJ1dCB3ZSBzdXBwb3J0IG5lZ2F0aXZlIHBvbGFyaXR5IHRv
by4KKyAgICAgICAgICovCisgICAgICAgIHJlcGxhY2UgPSBib290X2NwdV9o
YXMoZmVhdCkgXiBpbnY7CisKICAgICAgICAgLyogSWYgdGhlcmUgaXMgbm8g
cmVwbGFjZW1lbnQgdG8gbWFrZSwgc2VlIGFib3V0IG9wdGltaXNpbmcgdGhl
IG5vcHMuICovCi0gICAgICAgIGlmICggIWJvb3RfY3B1X2hhcyhhLT5jcHVp
ZCkgKQorICAgICAgICBpZiAoICFyZXBsYWNlICkKICAgICAgICAgewogICAg
ICAgICAgICAgLyogT3JpZ2luIHNpdGUgc2l0ZSBhbHJlYWR5IHRvdWNoZWQ/
ICBEb24ndCBub3AgYW55dGhpbmcuICovCiAgICAgICAgICAgICBpZiAoIGJh
c2UtPnByaXYgKQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLWFzbS5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLWFzbS5oCmluZGV4IDgzZTg1OTRmMGVhZi4uZWQz
ZjRjYjA1NWU4IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9h
c20vYWx0ZXJuYXRpdmUtYXNtLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1
ZGUvYXNtL2FsdGVybmF0aXZlLWFzbS5oCkBAIC0xMiw3ICsxMiw3IEBACiAg
KiBpbnN0cnVjdGlvbi4gU2VlIGFwcGx5X2FsdGVybmF0aXZlcygpLgogICov
CiAubWFjcm8gYWx0aW5zdHJ1Y3Rpb25fZW50cnkgb3JpZywgcmVwbCwgZmVh
dHVyZSwgb3JpZ19sZW4sIHJlcGxfbGVuLCBwYWRfbGVuCi0gICAgLmlmIFxm
ZWF0dXJlID49IE5DQVBJTlRTICogMzIKKyAgICAuaWYgKChcZmVhdHVyZSkg
JiB+QUxUX0ZMQUdfTk9UKSA+PSBOQ0FQSU5UUyAqIDMyCiAgICAgICAgIC5l
cnJvciAiYWx0ZXJuYXRpdmUgZmVhdHVyZSBvdXRzaWRlIG9mIGZlYXR1cmVz
ZXQgcmFuZ2UiCiAgICAgLmVuZGlmCiAgICAgLmxvbmcgXG9yaWcgLSAuCmRp
ZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYWx0ZXJuYXRp
dmUuaCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5o
CmluZGV4IDM4NDcyZmI1OGUyZC4uZWY2M2UyNTdhZDc4IDEwMDY0NAotLS0g
YS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYWx0ZXJuYXRpdmUuaAorKysg
Yi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYWx0ZXJuYXRpdmUuaApAQCAt
MSw2ICsxLDEzIEBACiAjaWZuZGVmIF9fWDg2X0FMVEVSTkFUSVZFX0hfXwog
I2RlZmluZSBfX1g4Nl9BTFRFUk5BVElWRV9IX18KIAorLyoKKyAqIENvbW1v
biB0byBib3RoIEMgYW5kIEFTTS4gIEV4cHJlc3MgYSByZXBsYWNlbWVudCB3
aGVuIGEgZmVhdHVyZSBpcyBub3QKKyAqIGF2YWlsYWJsZS4KKyAqLworI2Rl
ZmluZSBBTFRfRkxBR19OT1QgKDEgPDwgMTUpCisjZGVmaW5lIEFMVF9OT1Qo
eCkgKEFMVF9GTEFHX05PVCB8ICh4KSkKKwogI2lmZGVmIF9fQVNTRU1CTFlf
XwogI2luY2x1ZGUgPGFzbS9hbHRlcm5hdGl2ZS1hc20uaD4KICNlbHNlCkBA
IC0xMiw3ICsxOSw3IEBACiBzdHJ1Y3QgX19wYWNrZWQgYWx0X2luc3RyIHsK
ICAgICBpbnQzMl90ICBvcmlnX29mZnNldDsgICAvKiBvcmlnaW5hbCBpbnN0
cnVjdGlvbiAqLwogICAgIGludDMyX3QgIHJlcGxfb2Zmc2V0OyAgIC8qIG9m
ZnNldCB0byByZXBsYWNlbWVudCBpbnN0cnVjdGlvbiAqLwotICAgIHVpbnQx
Nl90IGNwdWlkOyAgICAgICAgIC8qIGNwdWlkIGJpdCBzZXQgZm9yIHJlcGxh
Y2VtZW50ICovCisgICAgdWludDE2X3QgY3B1aWQ7ICAgICAgICAgLyogY3B1
aWQgYml0IHNldCBmb3IgcmVwbGFjZW1lbnQgKHRvcCBiaXQgaXMgcG9sYXJp
dHkpICovCiAgICAgdWludDhfdCAgb3JpZ19sZW47ICAgICAgLyogbGVuZ3Ro
IG9mIG9yaWdpbmFsIGluc3RydWN0aW9uICovCiAgICAgdWludDhfdCAgcmVw
bF9sZW47ICAgICAgLyogbGVuZ3RoIG9mIG5ldyBpbnN0cnVjdGlvbiAqLwog
ICAgIHVpbnQ4X3QgIHBhZF9sZW47ICAgICAgIC8qIGxlbmd0aCBvZiBidWls
ZC10aW1lIHBhZGRpbmcgKi8KQEAgLTYwLDcgKzY3LDcgQEAgZXh0ZXJuIHZv
aWQgYWx0ZXJuYXRpdmVfYnJhbmNoZXModm9pZCk7CiAgICAgICAgICAgICAg
ICAgICAgIGFsdF9yZXBsX2xlbihuMikpICItIiBhbHRfb3JpZ19sZW4pCiAK
ICNkZWZpbmUgQUxUSU5TVFJfRU5UUlkoZmVhdHVyZSwgbnVtKSAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgIiAuaWYg
IiBTVFIoZmVhdHVyZSkgIiA+PSAiIFNUUihOQ0FQSU5UUyAqIDMyKSAiXG4i
ICAgICAgICAgICAgIFwKKyAgICAgICAgIiAuaWYgKCIgU1RSKGZlYXR1cmUg
JiB+QUxUX0ZMQUdfTk9UKSAiKSA+PSAiIFNUUihOQ0FQSU5UUyAqIDMyKSAi
XG4iIFwKICAgICAgICAgIiAuZXJyb3IgXCJhbHRlcm5hdGl2ZSBmZWF0dXJl
IG91dHNpZGUgb2YgZmVhdHVyZXNldCByYW5nZVwiXG4iIFwKICAgICAgICAg
IiAuZW5kaWZcbiIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgIiAubG9uZyAuTFhFTiU9
X29yaWdfcyAtIC5cbiIgICAgICAgICAgICAgLyogbGFiZWwgICAgICAgICAg
ICovIFwKCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-02.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-02.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2d1ZXN0OiBSZW1vdmUgdXNlIG9mIHRoZSBYZW4g
aHlwZXJjYWxsX3BhZ2UKCkluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCBJ
VFMsIFhlbiBuZWVkcyB0byBzdGFydCB1c2luZyByZXR1cm4gdGh1bmtzLgpU
aGVyZWZvcmUgdGhlIGFkdmljZSBpbiBYU0EtNDY2IGJlY29tZXMgcmVsZXZh
bnQsIGFuZCB0aGUgaHlwZXJjYWxsX3BhZ2UgbmVlZHMKdG8gYmUgcmVtb3Zl
ZC4KCkltcGxlbWVudCBlYXJseV9oeXBlcmNhbGwoKSwgd2l0aCBpbmZyYXN0
cnVjdHVyZSB0byBmaWd1cmUgb3V0IHRoZSBjb3JyZWN0Cmluc3RydWN0aW9u
IG9uIGZpcnN0IHVzZS4gIFVzZSBBTFRFUk5BVElWRSgpcyB0byByZXN1bHQg
aW4gaW5saW5lIGh5cGVyY2FsbHMsCmluY2x1ZGluZyB0aGUgQUxUX05PVCgp
IGZvcm0gc28gd2Ugb25seSBuZWVkIGEgc2luZ2xlIHN5bnRoZXRpYyBmZWF0
dXJlIGJpdC4KCk5vIG92ZXJhbGwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0IG9m
IFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTogQW5k
cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3
ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9ndWVzdC94ZW4vTWFrZWZp
bGUgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCmluZGV4IDI2
ZmI0YjEwMDdjMC4uOGIzMjUwYWE4ODg2IDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCisrKyBiL3hlbi9hcmNoL3g4Ni9n
dWVzdC94ZW4vTWFrZWZpbGUKQEAgLTEsNCArMSw0IEBACi1vYmoteSArPSBo
eXBlcmNhbGxfcGFnZS5vCitvYmotYmluLXkgKz0gaHlwZXJjYWxsLmluaXQu
bwogb2JqLXkgKz0geGVuLm8KIAogb2JqLWJpbi0kKENPTkZJR19QVkhfR1VF
U1QpICs9IHB2aC1ib290LmluaXQubwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGwuUyBiL3hlbi9hcmNoL3g4Ni9ndWVz
dC94ZW4vaHlwZXJjYWxsLlMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg
MDAwMDAwMDAwMDAwLi4wNWU0Mjk3OTRjYzQKLS0tIC9kZXYvbnVsbAorKysg
Yi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbC5TCkBAIC0wLDAg
KzEsNTAgQEAKKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4w
LW9yLWxhdGVyICovCisKKyNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPgorCisg
ICAgICAgIC5zZWN0aW9uIC5pbml0LnRleHQsICJheCIsIEBwcm9nYml0cwor
CisgICAgICAgIC8qCisgICAgICAgICAqIFVzZWQgZHVyaW5nIGVhcmx5IGJv
b3QsIGJlZm9yZSBhbHRlcm5hdGl2ZXMgaGF2ZSBydW4gYW5kIGlubGluZWQK
KyAgICAgICAgICogdGhlIGFwcHJvcHJpYXRlIGluc3RydWN0aW9uLiAgQ2Fs
bGVkIHVzaW5nIHRoZSBoeXBlcmNhbGwgQUJJLgorICAgICAgICAgKi8KK0ZV
TkMoZWFybHlfaHlwZXJjYWxsKQorICAgICAgICBjbXBiICAgICQwLCBlYXJs
eV9oeXBlcmNhbGxfaW5zbiglcmlwKQorICAgICAgICBqbCAgICAgIC5MX3Nl
dHVwCisgICAgICAgIGplICAgICAgMWYKKworICAgICAgICB2bW1jYWxsCisg
ICAgICAgIHJldAorCisxOiAgICAgIHZtY2FsbAorICAgICAgICByZXQKKwor
Lkxfc2V0dXA6CisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gc2V0dGlu
ZyB1cCB0aGUgZmlyc3QgdGltZSBhcm91bmQsIGFsbCByZWdpc3RlcnMgbmVl
ZAorICAgICAgICAgKiBwcmVzZXJ2aW5nLiAgU2F2ZSB0aGUgbm9uLWNhbGxl
ZS1zYXZlZCBvbmVzLgorICAgICAgICAgKi8KKyAgICAgICAgcHVzaCAgICAl
cjExCisgICAgICAgIHB1c2ggICAgJXIxMAorICAgICAgICBwdXNoICAgICVy
OQorICAgICAgICBwdXNoICAgICVyOAorICAgICAgICBwdXNoICAgICVyZGkK
KyAgICAgICAgcHVzaCAgICAlcnNpCisgICAgICAgIHB1c2ggICAgJXJkeAor
ICAgICAgICBwdXNoICAgICVyY3gKKyAgICAgICAgcHVzaCAgICAlcmF4CisK
KyAgICAgICAgY2FsbCAgICBlYXJseV9oeXBlcmNhbGxfc2V0dXAKKworICAg
ICAgICBwb3AgICAgICVyYXgKKyAgICAgICAgcG9wICAgICAlcmN4CisgICAg
ICAgIHBvcCAgICAgJXJkeAorICAgICAgICBwb3AgICAgICVyc2kKKyAgICAg
ICAgcG9wICAgICAlcmRpCisgICAgICAgIHBvcCAgICAgJXI4CisgICAgICAg
IHBvcCAgICAgJXI5CisgICAgICAgIHBvcCAgICAgJXIxMAorICAgICAgICBw
b3AgICAgICVyMTEKKworICAgICAgICBqbXAgICAgIGVhcmx5X2h5cGVyY2Fs
bAorRU5EKGVhcmx5X2h5cGVyY2FsbCkKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUyBiL3hlbi9hcmNoL3g4
Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUwpkZWxldGVkIGZpbGUgbW9k
ZSAxMDA2NDQKaW5kZXggN2FiNTVmYzFmNmU2Li4wMDAwMDAwMDAwMDAKLS0t
IGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGxfcGFnZS5TCisr
KyAvZGV2L251bGwKQEAgLTEsNzYgKzAsMCBAQAotI2luY2x1ZGUgPGFzbS9w
YWdlLmg+Ci0jaW5jbHVkZSA8YXNtL2FzbV9kZWZucy5oPgotI2luY2x1ZGUg
PHB1YmxpYy94ZW4uaD4KLQotICAgICAgICAuc2VjdGlvbiAiLnRleHQucGFn
ZV9hbGlnbmVkIiwgImF4IiwgQHByb2diaXRzCi0KLURBVEEoaHlwZXJjYWxs
X3BhZ2UsIFBBR0VfU0laRSkKLSAgICAgICAgIC8qIFBvaXNvbmVkIHdpdGgg
YHJldGAgZm9yIHNhZmV0eSBiZWZvcmUgaHlwZXJjYWxscyBhcmUgc2V0IHVw
LiAqLwotICAgICAgICAuZmlsbCBQQUdFX1NJWkUsIDEsIDB4YzMKLUVORCho
eXBlcmNhbGxfcGFnZSkKLQotLyoKLSAqIElkZW50aWZ5IGEgc3BlY2lmaWMg
aHlwZXJjYWxsIGluIHRoZSBoeXBlcmNhbGwgcGFnZQotICogQHBhcmFtIG5h
bWUgSHlwZXJjYWxsIG5hbWUuCi0gKi8KLSNkZWZpbmUgREVDTEFSRV9IWVBF
UkNBTEwobmFtZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAotICAgICAgICAuZ2xvYmwgSFlQRVJDQUxMXyAj
IyBuYW1lOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBcCi0gICAgICAgIC50eXBlICBIWVBFUkNBTExfICMjIG5hbWUs
IFNUVF9GVU5DOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFwKLSAgICAgICAgLnNpemUgIEhZUEVSQ0FMTF8gIyMgbmFtZSwgMzI7ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAotICAg
ICAgICAuc2V0ICAgSFlQRVJDQUxMXyAjIyBuYW1lLCBoeXBlcmNhbGxfcGFn
ZSArIF9fSFlQRVJWSVNPUl8gIyMgbmFtZSAqIDMyCi0KLURFQ0xBUkVfSFlQ
RVJDQUxMKHNldF90cmFwX3RhYmxlKQotREVDTEFSRV9IWVBFUkNBTEwobW11
X3VwZGF0ZSkKLURFQ0xBUkVfSFlQRVJDQUxMKHNldF9nZHQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChzdGFja19zd2l0Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChz
ZXRfY2FsbGJhY2tzKQotREVDTEFSRV9IWVBFUkNBTEwoZnB1X3Rhc2tzd2l0
Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChzY2hlZF9vcF9jb21wYXQpCi1ERUNM
QVJFX0hZUEVSQ0FMTChwbGF0Zm9ybV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxM
KHNldF9kZWJ1Z3JlZykKLURFQ0xBUkVfSFlQRVJDQUxMKGdldF9kZWJ1Z3Jl
ZykKLURFQ0xBUkVfSFlQRVJDQUxMKHVwZGF0ZV9kZXNjcmlwdG9yKQotREVD
TEFSRV9IWVBFUkNBTEwobWVtb3J5X29wKQotREVDTEFSRV9IWVBFUkNBTEwo
bXVsdGljYWxsKQotREVDTEFSRV9IWVBFUkNBTEwodXBkYXRlX3ZhX21hcHBp
bmcpCi1ERUNMQVJFX0hZUEVSQ0FMTChzZXRfdGltZXJfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTChldmVudF9jaGFubmVsX29wX2NvbXBhdCkKLURFQ0xBUkVf
SFlQRVJDQUxMKHhlbl92ZXJzaW9uKQotREVDTEFSRV9IWVBFUkNBTEwoY29u
c29sZV9pbykKLURFQ0xBUkVfSFlQRVJDQUxMKHBoeXNkZXZfb3BfY29tcGF0
KQotREVDTEFSRV9IWVBFUkNBTEwoZ3JhbnRfdGFibGVfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh2bV9hc3Npc3QpCi1ERUNMQVJFX0hZUEVSQ0FMTCh1cGRh
dGVfdmFfbWFwcGluZ19vdGhlcmRvbWFpbikKLURFQ0xBUkVfSFlQRVJDQUxM
KGlyZXQpCi1ERUNMQVJFX0hZUEVSQ0FMTCh2Y3B1X29wKQotREVDTEFSRV9I
WVBFUkNBTEwoc2V0X3NlZ21lbnRfYmFzZSkKLURFQ0xBUkVfSFlQRVJDQUxM
KG1tdWV4dF9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHhzbV9vcCkKLURFQ0xB
UkVfSFlQRVJDQUxMKG5taV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHNjaGVk
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoY2FsbGJhY2tfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh4ZW5vcHJvZl9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKGV2
ZW50X2NoYW5uZWxfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChwaHlzZGV2X29w
KQotREVDTEFSRV9IWVBFUkNBTEwoaHZtX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoc3lzY3RsKQotREVDTEFSRV9IWVBFUkNBTEwoZG9tY3RsKQotREVDTEFS
RV9IWVBFUkNBTEwoa2V4ZWNfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmdv
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoeGVucG11X29wKQotCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzEp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzIpCi1ERUNMQVJFX0hZUEVSQ0FM
TChhcmNoXzMpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzUpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzYp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzcpCi0KLS8qCi0gKiBMb2NhbCB2
YXJpYWJsZXM6Ci0gKiB0YWItd2lkdGg6IDgKLSAqIGluZGVudC10YWJzLW1v
ZGU6IG5pbAotICogRW5kOgotICovCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvZ3Vlc3QveGVuL3hlbi5jIGIveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94
ZW4uYwppbmRleCBjMTdmNWM0NDdhYjYuLjVjOWYzOTNjNzUxNCAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94ZW4uYworKysgYi94ZW4v
YXJjaC94ODYvZ3Vlc3QveGVuL3hlbi5jCkBAIC0yNiw3ICsyNiw2IEBACiBi
b29sIF9fcmVhZF9tb3N0bHkgeGVuX2d1ZXN0OwogCiB1aW50MzJfdCBfX3Jl
YWRfbW9zdGx5IHhlbl9jcHVpZF9iYXNlOwotZXh0ZXJuIGNoYXIgaHlwZXJj
YWxsX3BhZ2VbXTsKIHN0YXRpYyBzdHJ1Y3QgcmFuZ2VzZXQgKm1lbTsKIAog
REVGSU5FX1BFUl9DUFUodW5zaWduZWQgaW50LCB2Y3B1X2lkKTsKQEAgLTM1
LDYgKzM0LDUwIEBAIHN0YXRpYyBzdHJ1Y3QgdmNwdV9pbmZvICp2Y3B1X2lu
Zm87CiBzdGF0aWMgdW5zaWduZWQgbG9uZyB2Y3B1X2luZm9fbWFwcGVkW0JJ
VFNfVE9fTE9OR1MoTlJfQ1BVUyldOwogREVGSU5FX1BFUl9DUFUoc3RydWN0
IHZjcHVfaW5mbyAqLCB2Y3B1X2luZm8pOwogCisvKgorICogV2hpY2ggaW5z
dHJ1Y3Rpb24gdG8gdXNlIGZvciBlYXJseSBoeXBlcmNhbGxzOgorICogICA8
IDAgc2V0dXAKKyAqICAgICAwIHZtY2FsbAorICogICA+IDAgdm1tY2FsbAor
ICovCitpbnQ4X3QgX19pbml0ZGF0YSBlYXJseV9oeXBlcmNhbGxfaW5zbiA9
IC0xOworCisvKgorICogQ2FsbGVkIG9uY2UgZHVyaW5nIHRoZSBmaXJzdCBo
eXBlcmNhbGwgdG8gZmlndXJlIG91dCB3aGljaCBpbnN0cnVjdGlvbiB0bwor
ICogdXNlLiAgRXJyb3IgaGFuZGxpbmcgb3B0aW9ucyBhcmUgbGltaXRlZC4K
KyAqLwordm9pZCBhc21saW5rYWdlIF9faW5pdCBlYXJseV9oeXBlcmNhbGxf
c2V0dXAodm9pZCkKK3sKKyAgICBCVUdfT04oZWFybHlfaHlwZXJjYWxsX2lu
c24gIT0gLTEpOworCisgICAgaWYgKCAhYm9vdF9jcHVfZGF0YS54ODZfdmVu
ZG9yICkKKyAgICB7CisgICAgICAgIHVuc2lnbmVkIGludCBlYXgsIGVieCwg
ZWN4LCBlZHg7CisKKyAgICAgICAgY3B1aWQoMCwgJmVheCwgJmVieCwgJmVj
eCwgJmVkeCk7CisKKyAgICAgICAgYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ID0geDg2X2NwdWlkX2xvb2t1cF92ZW5kb3IoZWJ4LCBlY3gsIGVkeCk7Cisg
ICAgfQorCisgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ICkKKyAgICB7CisgICAgY2FzZSBYODZfVkVORE9SX0lOVEVMOgorICAgIGNh
c2UgWDg2X1ZFTkRPUl9DRU5UQVVSOgorICAgIGNhc2UgWDg2X1ZFTkRPUl9T
SEFOR0hBSToKKyAgICAgICAgZWFybHlfaHlwZXJjYWxsX2luc24gPSAwOwor
ICAgICAgICBzZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpOworICAgICAgICBicmVhazsKKworICAgIGNhc2UgWDg2X1ZFTkRP
Ul9BTUQ6CisgICAgY2FzZSBYODZfVkVORE9SX0hZR09OOgorICAgICAgICBl
YXJseV9oeXBlcmNhbGxfaW5zbiA9IDE7CisgICAgICAgIGJyZWFrOworCisg
ICAgZGVmYXVsdDoKKyAgICAgICAgQlVHKCk7CisgICAgfQorfQorCiBzdGF0
aWMgdm9pZCBfX2luaXQgZmluZF94ZW5fbGVhdmVzKHZvaWQpCiB7CiAgICAg
dWludDMyX3QgZWF4LCBlYngsIGVjeCwgZWR4LCBiYXNlOwpAQCAtMzM3LDkg
KzM4MCw2IEBAIGNvbnN0IHN0cnVjdCBoeXBlcnZpc29yX29wcyAqX19pbml0
IHhnX3Byb2JlKHZvaWQpCiAgICAgaWYgKCAheGVuX2NwdWlkX2Jhc2UgKQog
ICAgICAgICByZXR1cm4gTlVMTDsKIAotICAgIC8qIEZpbGwgdGhlIGh5cGVy
Y2FsbCBwYWdlLiAqLwotICAgIHdybXNybChjcHVpZF9lYngoeGVuX2NwdWlk
X2Jhc2UgKyAyKSwgX19wYShoeXBlcmNhbGxfcGFnZSkpOwotCiAgICAgeGVu
X2d1ZXN0ID0gdHJ1ZTsKIAogICAgIHJldHVybiAmb3BzOwpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmggYi94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vY3B1ZmVhdHVyZXMuaAppbmRleCBi
YTNkZjE3NGI3NmUuLjllM2VkMjFjMDI2ZCAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKKysrIGIveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKQEAgLTQyLDYgKzQy
LDcgQEAgWEVOX0NQVUZFQVRVUkUoWEVOX1NIU1RLLCAgICAgICAgIFg4Nl9T
WU5USCgyNikpIC8qIFhlbiB1c2VzIENFVCBTaGFkb3cgU3RhY2tzICoKIFhF
Tl9DUFVGRUFUVVJFKFhFTl9JQlQsICAgICAgICAgICBYODZfU1lOVEgoMjcp
KSAvKiBYZW4gdXNlcyBDRVQgSW5kaXJlY3QgQnJhbmNoIFRyYWNraW5nICov
CiBYRU5fQ1BVRkVBVFVSRShJQlBCX0VOVFJZX1BWLCAgICAgWDg2X1NZTlRI
KDI4KSkgLyogTVNSX1BSRURfQ01EIHVzZWQgYnkgWGVuIGZvciBQViAqLwog
WEVOX0NQVUZFQVRVUkUoSUJQQl9FTlRSWV9IVk0sICAgIFg4Nl9TWU5USCgy
OSkpIC8qIE1TUl9QUkVEX0NNRCB1c2VkIGJ5IFhlbiBmb3IgSFZNICovCitY
RU5fQ1BVRkVBVFVSRShVU0VfVk1DQUxMLCAgICAgICAgWDg2X1NZTlRIKDMw
KSkgLyogVXNlIFZNQ0FMTCBpbnN0ZWFkIG9mIFZNTUNBTEwgKi8KIAogLyog
QnVnIHdvcmRzIGZvbGxvdyB0aGUgc3ludGhldGljIHdvcmRzLiAqLwogI2Rl
ZmluZSBYODZfTlJfQlVHIDEKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaCBiL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaAppbmRleCA2NjViNDcyZDA1
YWMuLjk2MDA0ZGVjOTkwOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2d1ZXN0L3hlbi1oY2FsbC5oCisrKyBiL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaApAQCAtMzAsOSArMzAs
MTEgQEAKICAgICAoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICgg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKLSAgICAgICAgICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNb
b2Zmc2V0XSIgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAg
ICAgIEFMVEVSTkFUSVZFXzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgInZtbWNhbGwiLCBBTFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwp
LCAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4
Nl9GRUFUVVJFX1VTRV9WTUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgIDogIj1hIiAocmVzKSwgIj1EIiAodG1wX18pIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgIDogW29mZnNldF0g
ImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2FsbCksICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgICAgIjEiICgobG9uZykoYTEpKSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgKHR5cGUpcmVzOyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKQEAgLTQyLDEw
ICs0NCwxMiBAQAogICAgICh7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICBsb25nIHJlcywgdG1wX187ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBhc20gdm9sYXRp
bGUgKCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgImNhbGwgaHlwZXJjYWxsX3BhZ2Ug
KyAlY1tvZmZzZXRdIiAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgQUxURVJOQVRJVkVfMigiY2FsbCBlYXJseV9oeXBlcmNhbGwi
LCAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAidm1tY2FsbCIsIEFMVF9OT1QoWDg2X0ZFQVRVUkVfVVNFX1ZN
Q0FMTCksICAgXAorICAgICAgICAgICAgICAgICAgICAgICAgICAidm1jYWxs
IiwgWDg2X0ZFQVRVUkVfVVNFX1ZNQ0FMTCkgICAgICAgICAgICAgXAogICAg
ICAgICAgICAgOiAiPWEiIChyZXMpLCAiPUQiICh0bXBfXyksICI9UyIgKHRt
cF9fKSAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICBBU01f
Q0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgOiBbb2Zmc2V0XSAiaSIgKGhjYWxs
ICogMzIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgOiAiMCIgKGhjYWxsKSwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAiMSIg
KChsb25nKShhMSkpLCAiMiIgKChsb25nKShhMikpICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgICAgICAgICAgOiAibWVtb3J5IiApOyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICAodHlwZSlyZXM7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXApAQCAtNTUsMTAgKzU5LDEyIEBA
CiAgICAgKHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGxvbmcg
cmVzLCB0bXBfXzsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICAiY2FsbCBoeXBlcmNhbGxfcGFnZSArICVjW29mZnNl
dF0iICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICBB
TFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5cGVyY2FsbCIsICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2
bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSwgICBc
CisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2bWNhbGwiLCBYODZfRkVB
VFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAgICBcCiAgICAgICAgICAgICA6
ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSwgIj1TIiAodG1wX18pLCAiPWQi
ICh0bXBfXykgICAgICBcCiAgICAgICAgICAgICAgIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiksICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICA6
ICIwIiAoaGNhbGwpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcpKGEx
KSksICIyIiAoKGxvbmcpKGEyKSksICIzIiAoKGxvbmcpKGEzKSkgICAgICBc
CiAgICAgICAgICAgICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICh0eXBl
KXJlczsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCkBAIC02OSwxMCArNzUsMTIgQEAKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgcmVnaXN0ZXIgbG9uZyBf
YTQgYXNtICgicjEwIikgPSAoKGxvbmcpKGE0KSk7ICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICggICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNbb2Zmc2V0XSIgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIEFMVEVSTkFUSVZF
XzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtbWNhbGwiLCBB
TFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwpLCAgIFwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIj1hIiAocmVz
KSwgIj1EIiAodG1wX18pLCAiPVMiICh0bXBfXyksICI9ZCIgKHRtcF9fKSwg
ICAgIFwKICAgICAgICAgICAgICAgIj0mciIgKHRtcF9fKSBBU01fQ0FMTF9D
T05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgIDogW29mZnNldF0gImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2Fs
bCksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgICAgICAgIjEiICgobG9uZykoYTEpKSwgIjIiICgo
bG9uZykoYTIpKSwgIjMiICgobG9uZykoYTMpKSwgICAgIFwKICAgICAgICAg
ICAgICAgIjQiIChfYTQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-03.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-03.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IChNaXMpYWxpZ24gX194ODZfaW5kaXJlY3RfdGh1bmtf
KiB0byBtaXRpZ2F0ZSBJVFMKClRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRp
cmVjdApicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hl
biBpbiB0aGUgZmlyc3QgaGFsZiBvZiBhIGNhY2hlbGluZS4KCkFycmFuZ2Ug
Zm9yIF9feDg2X2luZGlyZWN0X3RodW5rXyogdG8gYWx3YXlzIGJlIGluIHRo
ZSBzZWNvbmQgaGFsZi4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDY5IC8gQ1ZF
LTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TCmluZGV4IGZkNTQ5M2MyMmIxNi4uYzRiOTc4ZDY3Yjhl
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwor
KysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMTEsNiAr
MTEsMTAgQEAKIAogI2luY2x1ZGUgPGFzbS9hc21fZGVmbnMuaD4KIAorLyog
QWxpZ25tZW50IGlzIGRlYWx0IHdpdGggZXhwbGljaXRseSBoZXJlOyBvdmVy
cmlkZSB0aGUgcmVzcGVjdGl2ZSBtYWNyby4gKi8KKyN1bmRlZiBTWU1fQUxJ
R04KKyNkZWZpbmUgU1lNX0FMSUdOKGFsaWduLi4uKQorCiAubWFjcm8gSU5E
X1RIVU5LX1JFVFBPTElORSByZWc6cmVxCiAgICAgICAgIGNhbGwgMWYKICAg
ICAgICAgaW50MwpAQCAtMzUsNiArMzksMTYgQEAKIC5tYWNybyBHRU5fSU5E
SVJFQ1RfVEhVTksgcmVnOnJlcQogICAgICAgICAuc2VjdGlvbiAudGV4dC5f
X3g4Nl9pbmRpcmVjdF90aHVua19ccmVnLCAiYXgiLCBAcHJvZ2JpdHMKIAor
ICAgICAgICAvKgorICAgICAgICAgKiBUaGUgSW5kaXJlY3QgVGFyZ2V0IFNl
bGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5zIHRoYXQK
KyAgICAgICAgICogaW5kaXJlY3QgYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRz
KSBhcmUgdW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0CisgICAgICAgICAqIGhh
bGYgb2YgYSBjYWNoZWxpbmUuICBBcnJhbmdlIGZvciB0aGVtIHRvIGJlIGlu
IHRoZSBzZWNvbmQgaGFsZi4KKyAgICAgICAgICoKKyAgICAgICAgICogQWxp
Z24gdG8gNjQsIHRoZW4gc2tpcCAzMi4KKyAgICAgICAgICovCisgICAgICAg
IC5iYWxpZ24gNjQKKyAgICAgICAgLmZpbGwgMzIsIDEsIDB4Y2MKKwogRlVO
QyhfX3g4Nl9pbmRpcmVjdF90aHVua19ccmVnKQogICAgICAgICBBTFRFUk5B
VElWRV8yIF9fc3RyaW5naWZ5KElORF9USFVOS19SRVRQT0xJTkUgXHJlZyks
ICAgICAgICAgICAgICBcCiAgICAgICAgIF9fc3RyaW5naWZ5KElORF9USFVO
S19MRkVOQ0UgXHJlZyksIFg4Nl9GRUFUVVJFX0lORF9USFVOS19MRkVOQ0Us
IFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-04.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-04.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3RodW5rOiAoTWlzKWFsaWduIHRoZSBSRVRzIGlu
IGNsZWFyX2JoYl9sb29wcygpIHRvIG1pdGlnYXRlIElUUwoKVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0IGluZGlyZWN0CmJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdCBoYWxmIG9mIGEgY2Fj
aGVsaW5lLgoKY2xlYXJfYmhiX2xvb3BzKCkgaGFzIGEgcHJlY2lzZSBsYXlv
dXQgb2YgYnJhbmNoZXMuICBUaGUgYWxpZ25tZW50IGZvcgpwZXJmb3JtYW5j
ZSBjYXVzZSB0aGUgUkVUcyB0byBhbHdheXMgYmUgaW4gYW4gdW5zYWZlIHBv
c2l0aW9uLCBhbmQgY29udmVydGluZwp0aG9zZSB0byByZXR1cm4gdGh1bmtz
IGNoYW5nZXMgdGhlIGJyYW5jaGluZyBwYXR0ZXJuLiAgV2hpbGUgc3VjaCBh
IGNvbnZlcnNpb24KaXMgYmVsaWV2ZWQgdG8gYmUgc2FmZSwgY2xlYXJfYmhi
X2xvb3BzKCkgaXMgYWxzbyBhIHBlcmZvcm1hbmNlLXJlbGV2YW50CmZhc3Rw
YXRoLCBzbyAobWlzKWFsaWduIHRoZSBSRVRzIHRvIGJlIGluIGEgc2FmZSBw
b3NpdGlvbi4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0
IG9mIFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUyBi
L3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCA2NzhjMDBjNWQwNmYu
LjUyNjI1ZjRlMmMxNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2JoYi10
aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwpAQCAtNTAs
NyArNTAsMTIgQEAgRU5EKGNsZWFyX2JoYl90c3gpCiAgKiAgIHJldAogICoK
ICAqIFRoZSBDQUxML1JFVHMgYXJlIG5lY2Vzc2FyeSB0byBwcmV2ZW50IHRo
ZSBMb29wIFN0cmVhbSBEZXRlY3RvciBmcm9tCi0gKiBpbnRlcmZlcmluZy4g
IFRoZSBhbGlnbm1lbnQgaXMgZm9yIHBlcmZvcm1hbmNlIGFuZCBub3Qgc2Fm
ZXR5LgorICogaW50ZXJmZXJpbmcuCisgKgorICogVGhlIC5iYWxpZ24ncyBh
cmUgZm9yIHBlcmZvcm1hbmNlLCBidXQgdGhleSBjYXVzZSB0aGUgUkVUcyB0
byBiZSBpbiB1bnNhZmUKKyAqIHBvc2l0aW9ucyB3aXRoIHJlc3BlY3QgdG8g
SW5kaXJlY3QgVGFyZ2V0IFNlbGVjdGlvbi4gIFRoZSAuc2tpcHMgYXJlIHRv
CisgKiBtb3ZlIHRoZSBSRVRzIGludG8gSVRTLXNhZmUgcG9zaXRpb25zLCBy
YXRoZXIgdGhhbiB1c2luZyB0aGUgc2xvd3BhdGgKKyAqIHRocm91Z2ggX194
ODZfcmV0dXJuX3RodW5rLgogICoKICAqIFRoZSAic2hvcnQiIHNlcXVlbmNl
ICg1IGFuZCA1KSBpcyBmb3IgQ1BVcyBwcmlvciB0byBBbGRlciBMYWtlIC8g
U2FwcGhpcmUKICAqIFJhcGlkcyAoaS5lLiBDb3JlcyBwcmlvciB0byBHb2xk
ZW4gQ292ZSBhbmQvb3IgR3JhY2Vtb250KS4KQEAgLTY2LDEyICs3MSwxNCBA
QCBGVU5DKGNsZWFyX2JoYl9sb29wcykKICAgICAgICAgam1wICAgICA1Zgog
ICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAgICAgIC5i
YWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtICguTHIxIC0gMWYpLCAw
eGNjCiAxOiAgICAgIGNhbGwgICAgMmYKLSAgICAgICAgcmV0CisuTHIxOiAg
IHJldAogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAg
ICAgIC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtIDE4IC8qICgu
THIyIC0gMmYpIGJ1dCBDbGFuZyBJQVMgZG9lc24ndCBsaWtlIHRoaXMgKi8s
IDB4Y2MKIDI6ICAgICAgQUxURVJOQVRJVkUgIm1vdiAkNSwgJWVheCIsICJt
b3YgJDcsICVlYXgiLCBYODZfU1BFQ19CSEJfTE9PUFNfTE9ORwogCiAzOiAg
ICAgIGptcCAgICAgNGYKQEAgLTgzLDcgKzkwLDcgQEAgRlVOQyhjbGVhcl9i
aGJfbG9vcHMpCiAgICAgICAgIHN1YiAgICAgJDEsICVlY3gKICAgICAgICAg
am56ICAgICAxYgogCi0gICAgICAgIHJldAorLkxyMjogICByZXQKIDU6CiAg
ICAgICAgIC8qCiAgICAgICAgICAqIFRoZSBJbnRlbCBzZXF1ZW5jZSBoYXMg
YW4gTEZFTkNFIGhlcmUuICBUaGUgcHVycG9zZSBpcyB0byBlbnN1cmUK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-05.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-05.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3N0dWJzOiBJbnRyb2R1Y2UgcGxhY2VfcmV0KCkg
dG8gYWJzdHJhY3QgYXdheSByYXcgMHhjMydzCgpUaGUgSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5z
IHRoYXQgaW5kaXJlY3QKYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUg
dW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0IGhhbGYgb2YgYSBjYWNoZWxpbmUu
ClRoaXMgbWVhbnMgaXQncyBub3Qgc2FmZSBmb3IgbG9naWMgdXNpbmcgdGhl
IHN0dWJzIHRvIHdyaXRlIHJhdyAweGMzJ3MuCgpJbnRyb2R1Y2UgcGxhY2Vf
cmV0KCkgd2hpY2gsIGZvciBub3csIHdyaXRlcyBhIHJhdyAweGMzIGJ1dCB3
aWxsIGNvbnRhaW4KYWRkaXRpb25hbCBsb2dpYyB3aGVuIHJldHVybiB0aHVu
a3MgYXJlIGluIHVzZS4KCnN0dWJfc2VsZnRlc3QoKSBkb2Vzbid0IHN0cmlj
dGx5IG5lZWQgdG8gYmUgY29udmVydGVkIGFzIHRoZXkgb25seSBydW4gb24K
Ym9vdCwgYnV0IGRvaW5nIHNvIGdldHMgdXMgYSBwYXJ0aWFsIHRlc3Qgb2Yg
cGxhY2VfcmV0KCkgdG9vLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ2OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQt
b2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu
Y29tPgpSZXZpZXdlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvdG9vbHMvdGVzdHMveDg2X2Vt
dWxhdG9yL3g4Ni1lbXVsYXRlLmggYi90b29scy90ZXN0cy94ODZfZW11bGF0
b3IveDg2LWVtdWxhdGUuaAppbmRleCA5MjljMWE3MmFlODguLjRjMjkyYWMz
MzhmNiAxMDA2NDQKLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKKysrIGIvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKQEAgLTc3LDYgKzc3LDEyIEBACiAKICNkZWZpbmUgaXNf
Y2Fub25pY2FsX2FkZHJlc3MoeCkgKCgoaW50NjRfdCkoeCkgPj4gNDcpID09
ICgoaW50NjRfdCkoeCkgPj4gNjMpKQogCitzdGF0aWMgaW5saW5lIHZvaWQg
KnBsYWNlX3JldCh2b2lkICpwdHIpCit7CisgICAgKih1aW50OF90ICopcHRy
ID0gMHhjMzsKKyAgICByZXR1cm4gcHRyICsgMTsKK30KKwogZXh0ZXJuIHVp
bnQzMl90IG14Y3NyX21hc2s7CiBleHRlcm4gc3RydWN0IGNwdV9wb2xpY3kg
Y3B1X3BvbGljeTsKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L01ha2Vm
aWxlIGIveGVuL2FyY2gveDg2L01ha2VmaWxlCmluZGV4IDBkZWQ2OGQwNjk1
OC4uMDJhYjIzNWRlN2ZmIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvTWFr
ZWZpbGUKKysrIGIveGVuL2FyY2gveDg2L01ha2VmaWxlCkBAIC0xMSw5ICsx
MSw3IEBAIG9iai0kKENPTkZJR19QVikgKz0gcHYvCiBvYmoteSArPSB4ODZf
NjQvCiBvYmoteSArPSB4ODZfZW11bGF0ZS8KIAotYWx0ZXJuYXRpdmUteSA6
PSBhbHRlcm5hdGl2ZS5pbml0Lm8KLWFsdGVybmF0aXZlLSQoQ09ORklHX0xJ
VkVQQVRDSCkgOj0KLW9iai1iaW4teSArPSAkKGFsdGVybmF0aXZlLXkpCitv
YmoteSArPSBhbHRlcm5hdGl2ZS5vCiBvYmoteSArPSBhcGljLm8KIG9iai15
ICs9IGJoYi10aHVuay5vCiBvYmoteSArPSBiaXRvcHMubwpAQCAtNDEsNyAr
MzksNyBAQCBvYmoteSArPSBoeXBlcmNhbGwubwogb2JqLXkgKz0gaTM4Ny5v
CiBvYmoteSArPSBpODI1OS5vCiBvYmoteSArPSBpb19hcGljLm8KLW9iai0k
KENPTkZJR19MSVZFUEFUQ0gpICs9IGFsdGVybmF0aXZlLm8gbGl2ZXBhdGNo
Lm8KK29iai0kKENPTkZJR19MSVZFUEFUQ0gpICs9IGxpdmVwYXRjaC5vCiBv
YmoteSArPSBtc2kubwogb2JqLXkgKz0gbXNyLm8KIG9iai0kKENPTkZJR19J
TkRJUkVDVF9USFVOSykgKz0gaW5kaXJlY3QtdGh1bmsubwpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94ODYv
YWx0ZXJuYXRpdmUuYwppbmRleCA4OGM5MDA0NGMyMGQuLmVjNDUxZDk2MmMx
MCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKKysr
IGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTEzNyw2ICsxMzcs
MjAgQEAgdm9pZCBpbml0X29yX2xpdmVwYXRjaCBhZGRfbm9wcyh2b2lkICpp
bnNucywgdW5zaWduZWQgaW50IGxlbikKICAgICB9CiB9CiAKKy8qCisgKiBQ
bGFjZSBhIHJldHVybiBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGluIHRoZSB3
cml0YWJsZSBhbGlhcyBvZiBhIHN0dWIuCisgKgorICogUmV0dXJucyB0aGUg
bmV4dCBwb3NpdGlvbiB0byB3cml0ZSBpbnRvIHRoZSBzdHViLgorICovCit2
b2lkICpwbGFjZV9yZXQodm9pZCAqcHRyKQoreworICAgIHVpbnQ4X3QgKnAg
PSBwdHI7CisKKyAgICAqcCsrID0gMHhjMzsKKworICAgIHJldHVybiBwOwor
fQorCiAvKgogICogdGV4dF9wb2tlIC0gVXBkYXRlIGluc3RydWN0aW9ucyBv
biBhIGxpdmUga2VybmVsIG9yIG5vbi1leGVjdXRlZCBjb2RlLgogICogQGFk
ZHI6IGFkZHJlc3MgdG8gbW9kaWZ5CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvZXh0YWJsZS5jIGIveGVuL2FyY2gveDg2L2V4dGFibGUuYwppbmRleCA3
MDVjZjllYjk0Y2EuLjE1NzJlZmE2OWEwMCAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2V4dGFibGUuYworKysgYi94ZW4vYXJjaC94ODYvZXh0YWJsZS5j
CkBAIC0xNTEsMjAgKzE1MSwyMCBAQCBzZWFyY2hfZXhjZXB0aW9uX3RhYmxl
KGNvbnN0IHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzLCB1bnNpZ25lZCBs
b25nICpzdHViX3JhKQogaW50IF9faW5pdCBjZl9jaGVjayBzdHViX3NlbGZ0
ZXN0KHZvaWQpCiB7CiAgICAgc3RhdGljIGNvbnN0IHN0cnVjdCB7Ci0gICAg
ICAgIHVpbnQ4X3Qgb3BjWzhdOworICAgICAgICB1aW50OF90IG9wY1s3XTsK
ICAgICAgICAgdWludDY0X3QgcmF4OwogICAgICAgICB1bmlvbiBzdHViX2V4
Y2VwdGlvbl90b2tlbiByZXM7CiAgICAgfSB0ZXN0c1tdIF9faW5pdGNvbnN0
ID0gewogI2RlZmluZSBlbmRicjY0IDB4ZjMsIDB4MGYsIDB4MWUsIDB4ZmEK
LSAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDBmLCAweGI5LCAweGMz
LCAweGMzIH0sIC8qIHVkMSAqLworICAgICAgICB7IC5vcGMgPSB7IGVuZGJy
NjQsIDB4MGYsIDB4YjksIDB4OTAgfSwgLyogdWQxICovCiAgICAgICAgICAg
LnJlcy5maWVsZHMudHJhcG5yID0gWDg2X0VYQ19VRCB9LAotICAgICAgICB7
IC5vcGMgPSB7IGVuZGJyNjQsIDB4OTAsIDB4MDIsIDB4MDAsIDB4YzMgfSwg
Lyogbm9wOyBhZGQgKCVyYXgpLCVhbCAqLworICAgICAgICB7IC5vcGMgPSB7
IGVuZGJyNjQsIDB4OTAsIDB4MDIsIDB4MDAgfSwgLyogbm9wOyBhZGQgKCVy
YXgpLCVhbCAqLwogICAgICAgICAgIC5yYXggPSAweDAxMjM0NTY3ODlhYmNk
ZWYsCiAgICAgICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0gWDg2X0VYQ19H
UCB9LAotICAgICAgICB7IC5vcGMgPSB7IGVuZGJyNjQsIDB4MDIsIDB4MDQs
IDB4MDQsIDB4YzMgfSwgLyogYWRkICglcnNwLCVyYXgpLCVhbCAqLworICAg
ICAgICB7IC5vcGMgPSB7IGVuZGJyNjQsIDB4MDIsIDB4MDQsIDB4MDQgfSwg
LyogYWRkICglcnNwLCVyYXgpLCVhbCAqLwogICAgICAgICAgIC5yYXggPSAw
eGZlZGNiYTk4NzY1NDMyMTBVTCwKICAgICAgICAgICAucmVzLmZpZWxkcy50
cmFwbnIgPSBYODZfRVhDX1NTIH0sCi0gICAgICAgIHsgLm9wYyA9IHsgZW5k
YnI2NCwgMHhjYywgMHhjMywgMHhjMywgMHhjMyB9LCAvKiBpbnQzICovCisg
ICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwgMHhjYywgMHg5MCwgMHg5MCB9
LCAvKiBpbnQzICovCiAgICAgICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0g
WDg2X0VYQ19CUCB9LAogI3VuZGVmIGVuZGJyNjQKICAgICB9OwpAQCAtMTgz
LDYgKzE4Myw3IEBAIGludCBfX2luaXQgY2ZfY2hlY2sgc3R1Yl9zZWxmdGVz
dCh2b2lkKQogCiAgICAgICAgIG1lbXNldChwdHIsIDB4Y2MsIFNUVUJfQlVG
X1NJWkUgLyAyKTsKICAgICAgICAgbWVtY3B5KHB0ciwgdGVzdHNbaV0ub3Bj
LCBBUlJBWV9TSVpFKHRlc3RzW2ldLm9wYykpOworICAgICAgICBwbGFjZV9y
ZXQocHRyICsgQVJSQVlfU0laRSh0ZXN0c1tpXS5vcGMpKTsKICAgICAgICAg
dW5tYXBfZG9tYWluX3BhZ2UocHRyKTsKIAogICAgICAgICBhc20gdm9sYXRp
bGUgKCAiSU5ESVJFQ1RfQ0FMTCAlW3N0Yl1cbiIKZGlmZiAtLWdpdCBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oIGIveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmgKaW5kZXggZWY2M2Uy
NTdhZDc4Li4yOGQ0ZWMwZjljNGEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCisrKyBiL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCkBAIC0zMSw2ICszMSw4IEBA
IHN0cnVjdCBfX3BhY2tlZCBhbHRfaW5zdHIgewogI2RlZmluZSBBTFRfUkVQ
TF9QVFIoYSkgICAgIF9fQUxUX1BUUihhLCByZXBsX29mZnNldCkKIAogZXh0
ZXJuIHZvaWQgYWRkX25vcHModm9pZCAqaW5zbnMsIHVuc2lnbmVkIGludCBs
ZW4pOwordm9pZCAqcGxhY2VfcmV0KHZvaWQgKnB0cik7CisKIC8qIFNpbWls
YXIgdG8gYWx0ZXJuYXRpdmVfaW5zdHJ1Y3Rpb25zIGV4Y2VwdCBpdCBjYW4g
YmUgcnVuIHdpdGggSVJRcyBlbmFibGVkLiAqLwogZXh0ZXJuIGludCBhcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsIHN0cnVj
dCBhbHRfaW5zdHIgKmVuZCk7CiBleHRlcm4gdm9pZCBhbHRlcm5hdGl2ZV9p
bnN0cnVjdGlvbnModm9pZCk7CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
cHYvZW11bC1wcml2LW9wLmMgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2
LW9wLmMKaW5kZXggNzAxNTBjMjcyMjc2Li5mZjVkMWM5Zjg2MzQgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXByaXYtb3AuYworKysgYi94
ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMKQEAgLTc2LDcgKzc2LDYg
QEAgc3RhdGljIGlvX2VtdWxfc3R1Yl90ICppb19lbXVsX3N0dWJfc2V0dXAo
c3RydWN0IHByaXZfb3BfY3R4dCAqY3R4dCwgdTggb3Bjb2RlLAogICAgICAg
ICAweDQxLCAweDVjLCAvKiBwb3AgJXIxMiAgKi8KICAgICAgICAgMHg1ZCwg
ICAgICAgLyogcG9wICVyYnAgICovCiAgICAgICAgIDB4NWIsICAgICAgIC8q
IHBvcCAlcmJ4ICAqLwotICAgICAgICAweGMzLCAgICAgICAvKiByZXQgICAg
ICAgKi8KICAgICB9OwogCiAgICAgY29uc3Qgc3RydWN0IHN0dWJzICp0aGlz
X3N0dWJzID0gJnRoaXNfY3B1KHN0dWJzKTsKQEAgLTEyNiwxMSArMTI1LDEz
IEBAIHN0YXRpYyBpb19lbXVsX3N0dWJfdCAqaW9fZW11bF9zdHViX3NldHVw
KHN0cnVjdCBwcml2X29wX2N0eHQgKmN0eHQsIHU4IG9wY29kZSwKIAogICAg
IEFQUEVORF9DQUxMKHNhdmVfZ3Vlc3RfZ3Bycyk7CiAgICAgQVBQRU5EX0JV
RkYoZXBpbG9ndWUpOworICAgIHAgPSBwbGFjZV9yZXQocCk7CiAKICAgICAv
KiBCdWlsZC10aW1lIGJlc3QgZWZmb3J0IGF0dGVtcHQgdG8gY2F0Y2ggcHJv
YmxlbXMuICovCiAgICAgQlVJTERfQlVHX09OKFNUVUJfQlVGX1NJWkUgLyAy
IDwKICAgICAgICAgICAgICAgICAgKHNpemVvZihwcm9sb2d1ZSkgKyBzaXpl
b2YoZXBpbG9ndWUpICsgMTAgLyogMnggY2FsbCAqLyArCi0gICAgICAgICAg
ICAgICAgICBNQVgoMyAvKiBkZWZhdWx0IHN0dWIgKi8sIElPRU1VTF9RVUlS
S19TVFVCX0JZVEVTKSkpOworICAgICAgICAgICAgICAgICAgTUFYKDMgLyog
ZGVmYXVsdCBzdHViICovLCBJT0VNVUxfUVVJUktfU1RVQl9CWVRFUykgKwor
ICAgICAgICAgICAgICAgICAgMSAvKiByZXQgKi8pKTsKICAgICAvKiBSdW50
aW1lIGNvbmZpcm1hdGlvbiB0aGF0IHdlIGhhdmVuJ3QgY2xvYmJlcmVkIGFu
IGFkamFjZW50IHN0dWIuICovCiAgICAgQlVHX09OKFNUVUJfQlVGX1NJWkUg
LyAyIDwgKHAgLSBjdHh0LT5pb19lbXVsX3N0dWIpKTsKIApkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL2ZwdS5jIGIveGVuL2FyY2gv
eDg2L3g4Nl9lbXVsYXRlL2ZwdS5jCmluZGV4IDU0Yzg2MjE0MjFjNi4uOWNj
MzdhMWQ4ZTNjIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYveDg2X2VtdWxh
dGUvZnB1LmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL2ZwdS5j
CkBAIC0zMiwzNiArMzIsNDIgQEAgc3RhdGljIGlubGluZSBib29sIGZwdV9j
aGVja193cml0ZSh2b2lkKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25f
bWVtZHN0KG9wYywgZXh0LCBhcmcpICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAq
X3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgLyogTW9kUk06IG1vZD0wLCByZWc9
ZXh0LCBybT0wLCBpLmUuIGEgKCVyYXgpIG9wZXJhbmQgKi8gICAgICAgICAg
ICBcCiAgICAgKmluc25fYnl0ZXMgPSAyOyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWludDhfdFtdKXsg
b3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsgICAgICAgICAg
ICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9wYywgKChleHQp
ICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisgICAgcGxhY2Vf
cmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAi
K20iIChhcmcpIDogImEiICgmKGFyZykpKTsgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9IHdoaWxlICgw
KQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fbWVtc3JjKG9wYywgZXh0
LCBhcmcpICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBkbyB7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBnZXRfc3R1Yihz
dHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgLyogTW9kUk06IG1vZD0wLCByZWc9ZXh0LCBybT0wLCBpLmUu
IGEgKCVyYXgpIG9wZXJhbmQgKi8gICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWludDhfdFtdKXsg
b3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsgICAgICAgICAg
ICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9wYywgKChleHQp
ICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisgICAgcGxhY2Vf
cmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAi
PW0iIChkdW1teSkgOiAibSIgKGFyZyksICJhIiAoJihhcmcpKSk7ICAgICAg
ICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9IHdoaWxlICgw
KQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fc3R1YihieXRlcy4uLikg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBkbyB7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBnZXRfc3R1Yihz
dHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgdW5zaWduZWQgaW50IG5yXyA9IHNpemVvZigodWludDhfdFtd
KXsgYnl0ZXMgfSk7ICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVzLCAweGMzIH0p
LCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3Rb
XSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAgICAgICAgICAg
ICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tl
X3N0dWIoIiIsICIiLCAiPW0iIChkdW1teSkgOiAiaSIgKDApKTsgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiB9IHdoaWxlICgwKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25f
c3R1Yl9lZmxhZ3MoYnl0ZXMuLi4pICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAq
X3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgdW5zaWduZWQgaW50IG5yXyA9IHNp
emVvZigodWludDhfdFtdKXsgYnl0ZXMgfSk7ICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgdW5zaWduZWQgbG9uZyB0bXBfOyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVzLCAweGMzIH0p
LCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3Rb
XSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAgICAgICAgICAg
ICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tl
X3N0dWIoX1BSRV9FRkxBR1MoIltlZmxhZ3NdIiwgIlttYXNrXSIsICJbdG1w
XSIpLCAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgX1BPU1RfRUZM
QUdTKCJbZWZsYWdzXSIsICJbbWFza10iLCAiW3RtcF0iKSwgICAgICAgICAg
ICBcCiAgICAgICAgICAgICAgICAgW2VmbGFnc10gIitnIiAocmVncy0+ZWZs
YWdzKSwgW3RtcF0gIj0mciIgKHRtcF8pICAgICAgICBcCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYyBiL3hl
bi9hcmNoL3g4Ni94ODZfZW11bGF0ZS94ODZfZW11bGF0ZS5jCmluZGV4IGU4
Y2JhNWEyN2Y1Ni4uYTZhMWM5OTM3ZjVkIDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYworKysgYi94ZW4vYXJj
aC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYwpAQCAtMTM5OCw3ICsx
Mzk4LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHN0YlszXSA9IDB4OTE7
CiAgICAgICAgIHN0Yls0XSA9IGV2ZXgub3Btc2sgPDwgMzsKICAgICAgICAg
aW5zbl9ieXRlcyA9IDU7Ci0gICAgICAgIHN0Yls1XSA9IDB4YzM7CisgICAg
ICAgIHBsYWNlX3JldCgmc3RiWzVdKTsKIAogICAgICAgICBpbnZva2Vfc3R1
YigiIiwgIiIsICIrbSIgKG9wX21hc2spIDogImEiICgmb3BfbWFzaykpOwog
CkBAIC0zNjMxLDcgKzM2MzEsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAg
fQogICAgICAgICBvcGNbMV0gPSAobW9kcm0gJiAweDM4KSB8IDB4YzA7CiAg
ICAgICAgIGluc25fYnl0ZXMgPSBFVkVYX1BGWF9CWVRFUyArIDI7Ci0gICAg
ICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJd
KTsKIAogICAgICAgICBjb3B5X0VWRVgob3BjLCBldmV4KTsKICAgICAgICAg
aW52b2tlX3N0dWIoIiIsICIiLCAiPWciIChkdW1teSkgOiAiYSIgKHNyYy52
YWwpKTsKQEAgLTM2OTgsNyArMzY5OCw3IEBAIHg4Nl9lbXVsYXRlKAogICAg
ICAgICAgICAgaW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDI7CiAgICAgICAg
ICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2ZXgpOwogICAg
ICAgICB9Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNl
X3JldCgmb3BjWzJdKTsKIAogICAgICAgICBlYS5yZWcgPSBkZWNvZGVfZ3By
KCZfcmVncywgbW9kcm1fcmVnKTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIs
ICIiLCAiPWEiICgqZWEucmVnKSA6ICJjIiAobW12YWxwKSwgIm0iICgqbW12
YWxwKSk7CkBAIC0zNzcyLDcgKzM3NzIsNyBAQCB4ODZfZW11bGF0ZSgKICAg
ICAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwogICAgICAg
ICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3ByZWZpeCwgdmV4KTsKICAg
ICAgICAgfQotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFj
ZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgX3JlZ3MuZWZsYWdzICY9IH5F
RkxBR1NfTUFTSzsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsCkBAIC00MDA4
LDcgKzQwMDgsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgb3BjWzFdID0g
bW9kcm0gJiAweGM3OwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVT
ICsgMjsKICAgICBzaW1kXzBmX3RvX2dwcjoKLSAgICAgICAgb3BjW2luc25f
Ynl0ZXMgLSBQRlhfQllURVNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0
KCZvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10pOwogCiAgICAgICAgIGdl
bmVyYXRlX2V4Y2VwdGlvbl9pZihlYS50eXBlICE9IE9QX1JFRywgWDg2X0VY
Q19VRCk7CiAKQEAgLTQ0MDUsNyArNDQwNSw3IEBAIHg4Nl9lbXVsYXRlKAog
ICAgICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2Ry
bSAmIDB4Mzg7CiAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAy
OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQo
Jm9wY1syXSk7CiAKICAgICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3By
ZWZpeCwgdmV4KTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiK20i
IChzcmMudmFsKSA6ICJhIiAoJnNyYy52YWwpKTsKQEAgLTQ0NDIsNyArNDQ0
Miw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAgZXZleC53ID0gMDsK
ICAgICAgICAgb3BjWzFdID0gbW9kcm0gJiAweDM4OwogICAgICAgICBpbnNu
X2J5dGVzID0gRVZFWF9QRlhfQllURVMgKyAyOwotICAgICAgICBvcGNbMl0g
PSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAg
ICAgY29weV9FVkVYKG9wYywgZXZleCk7CiAgICAgICAgIGludm9rZV9zdHVi
KCIiLCAiIiwgIittIiAoc3JjLnZhbCkgOiAiYSIgKCZzcmMudmFsKSk7CkBA
IC00NjM3LDcgKzQ2MzcsNyBAQCB4ODZfZW11bGF0ZSgKICNlbmRpZiAvKiBY
ODZFTVVMX05PX1NJTUQgKi8KIAogICAgIHNpbWRfMGZfcmVnX29ubHk6Ci0g
ICAgICAgIG9wY1tpbnNuX2J5dGVzIC0gUEZYX0JZVEVTXSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjW2luc25fYnl0ZXMgLSBQRlhfQllURVNd
KTsKIAogICAgICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2
ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsIFtkdW1teV9vdXRd
ICI9ZyIgKGR1bW15KSA6IFtkdW1teV9pbl0gImkiICgwKSApOwpAQCAtNDk3
MSw3ICs0OTcxLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIGlmICggIW1v
ZGVfNjRiaXQoKSApCiAgICAgICAgICAgICB2ZXgudyA9IDA7CiAgICAgICAg
IG9wY1sxXSA9IG1vZHJtICYgMHhmODsKLSAgICAgICAgb3BjWzJdID0gMHhj
MzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNv
cHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAgZWEucmVnID0gZGVjb2RlX2dw
cigmX3JlZ3MsIG1vZHJtX3JtKTsKQEAgLTUwMTQsNyArNTAxNCw3IEBAIHg4
Nl9lbXVsYXRlKAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0KCkgKQogICAg
ICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2RybSAm
IDB4Yzc7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNl
X3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X1ZFWChvcGMsIHZleCk7
CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1hIiAoZHN0LnZhbCkg
OiBbZHVtbXldICJpIiAoMCkpOwpAQCAtNTA0NCw3ICs1MDQ0LDcgQEAgeDg2
X2VtdWxhdGUoCiAgICAgICAgIG9wYyA9IGluaXRfcHJlZml4ZXMoc3R1Yik7
CiAgICAgICAgIG9wY1swXSA9IGI7CiAgICAgICAgIG9wY1sxXSA9IG1vZHJt
OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQo
Jm9wY1syXSk7CiAKICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAg
ICAgICBfcmVncy5lZmxhZ3MgJj0gfkVGTEFHU19NQVNLOwpAQCAtNTYxMiw3
ICs1NjEyLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIGlmICggIW1vZGVf
NjRiaXQoKSApCiAgICAgICAgICAgICB2ZXgudyA9IDA7CiAgICAgICAgIG9w
Y1sxXSA9IG1vZHJtICYgMHhjNzsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
UkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIGludm9r
ZV9zdHViKCIiLCAiIiwgIj1hIiAoZWEudmFsKSA6IFtkdW1teV0gImkiICgw
KSk7CkBAIC01NzMwLDcgKzU3MzAsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAg
ICAgICAgIG9wY1sxXSAmPSAweDM4OwogICAgICAgICB9CiAgICAgICAgIGlu
c25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwotICAgICAgICBvcGNbMl0gPSAw
eGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAgICAgICAgIGlm
ICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQogICAgICAgICB7CiAgICAgICAg
ICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJlZml4IGJ5dGUuICovCkBAIC02
MDEwLDcgKzYwMTAsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+
YiA9ICFtb2RlXzY0Yml0KCkgfHwgKHZleC5yZWcgPj4gMyk7CiAgICAgICAg
IG9wY1sxXSA9IDB4YzAgfCAofnZleC5yZWcgJiA3KTsKICAgICAgICAgcHZl
eC0+cmVnID0gMHhmOwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAg
ICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIo
IiIsICIiLCAiPWEiIChlYS52YWwpIDogW2R1bW15XSAiaSIgKDApKTsKICAg
ICAgICAgcHV0X3N0dWIoc3R1Yik7CkBAIC02Mjg0LDcgKzYyODQsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgICAgIGV2ZXgudyA9IDA7CiAgICAgICAg
IG9wY1sxXSA9IG1vZHJtICYgMHhmODsKICAgICAgICAgaW5zbl9ieXRlcyA9
IEVWRVhfUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
RVZFWChvcGMsIGV2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIs
ICI9ZyIgKGR1bW15KSA6ICJhIiAoc3JjLnZhbCkpOwpAQCAtNjM4Myw3ICs2
MzgzLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHB2ZXgtPmIgPSAxOwog
ICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAgICAg
ICAgcHZleC0+cmVnID0gMHhmOwotICAgICAgICBvcGNbMl0gPSAweGMzOwor
ICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgaW52b2tl
X3N0dWIoIiIsICIiLCAiPW0iICgqbW12YWxwKSA6ICJhIiAobW12YWxwKSk7
CiAKQEAgLTY0NTMsNyArNjQ1Myw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAg
ICBwdmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJtX3JlZyAm
IDcpIDw8IDM7CiAgICAgICAgIHB2ZXgtPnJlZyA9IDB4ZjsKLSAgICAgICAg
b3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwog
CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAoKm1tdmFscCkg
OiAiYSIgKG1tdmFscCkpOwogCkBAIC02NTA5LDcgKzY1MDksNyBAQCB4ODZf
ZW11bGF0ZSgKICAgICAgICAgcGV2ZXgtPmIgPSAxOwogICAgICAgICBvcGNb
MV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAgICAgICAgcGV2ZXgtPlJY
ID0gMTsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2Vf
cmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwg
Ij1tIiAoKm1tdmFscCkgOiAiYSIgKG1tdmFscCkpOwogCkBAIC02NTc0LDcg
KzY1NzQsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcGV2ZXgtPmIgPSAx
OwogICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAg
ICAgICAgcGV2ZXgtPlJYID0gMTsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9r
ZV9zdHViKCIiLCAiIiwgIittIiAoKm1tdmFscCkgOiAiYSIgKG1tdmFscCkp
OwogCkBAIC02NTg4LDcgKzY1ODgsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAg
ICAgb3BjWzJdID0gMHg5MDsKICAgICAgICAgLyogVXNlICglcmF4KSBhcyBz
b3VyY2UuICovCiAgICAgICAgIG9wY1szXSA9IGV2ZXgub3Btc2sgPDwgMzsK
LSAgICAgICAgb3BjWzRdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbNF0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAo
b3BfbWFzaykgOiAiYSIgKCZvcF9tYXNrKSk7CiAgICAgICAgIHB1dF9zdHVi
KHN0dWIpOwpAQCAtNjY2NCw3ICs2NjY0LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIHBldmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJt
X3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0gICAg
ICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJd
KTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKCptbXZh
bHApIDogImEiIChtbXZhbHApKTsKIApAQCAtNjc0MSw3ICs2NzQxLDcgQEAg
eDg2X2VtdWxhdGUoCiAgICAgICAgIG9wY1syXSA9IDB4OTA7CiAgICAgICAg
IC8qIFVzZSAoJXJheCkgYXMgc291cmNlLiAqLwogICAgICAgICBvcGNbM10g
PSBldmV4Lm9wbXNrIDw8IDM7Ci0gICAgICAgIG9wY1s0XSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjWzRdKTsKIAogICAgICAgICBpbnZva2Vf
c3R1YigiIiwgIiIsICIrbSIgKG9wX21hc2spIDogImEiICgmb3BfbWFzaykp
OwogICAgICAgICBwdXRfc3R1YihzdHViKTsKQEAgLTY5NDAsNyArNjk0MCw3
IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBwdmV4LT5yZWcgPSAweGY7IC8q
IHJBWCAqLwogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZbNF0g
PSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVm
WzVdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAg
ICAgICAgIHNyYy5yZWcgPSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3Jl
Z3MsIGN0eHQpOwogICAgICAgICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0mYyIg
KGRzdC52YWwpLCAiW2RzdF0iICgmc3JjLnZhbCksICJhIiAoKnNyYy5yZWcp
KTsKQEAgLTY5NzYsNyArNjk3Niw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAg
ICBwdmV4LT5yZWcgPSAweGY7IC8qIHJBWCAqLwogICAgICAgICBidWZbM10g
PSBiOwogICAgICAgICBidWZbNF0gPSAobW9kcm0gJiAweDM4KSB8IDB4MDE7
IC8qIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgIGRzdC5yZWcg
PSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3JlZ3MsIGN0eHQpOwogICAg
ICAgICBlbXVsYXRlX3N0dWIoIj0mYSIgKGRzdC52YWwpLCAiYyIgKCZzcmMu
dmFsKSk7CkBAIC03MjE3LDcgKzcyMTcsNyBAQCB4ODZfZW11bGF0ZSgKICAg
ICAgICAgICAgIGV2ZXgudyA9IHZleC53ID0gMDsKICAgICAgICAgb3BjWzFd
ID0gbW9kcm0gJiAweDM4OwogICAgICAgICBvcGNbMl0gPSBpbW0xOwotICAg
ICAgICBvcGNbM10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1sz
XSk7CiAgICAgICAgIGlmICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQogICAg
ICAgICB7CiAgICAgICAgICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJlZml4
IGJ5dGUuICovCkBAIC03Mzg0LDcgKzczODQsNyBAQCB4ODZfZW11bGF0ZSgK
ICAgICAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAzOwogICAg
ICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAgICAgICB9Ci0gICAg
ICAgIG9wY1szXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzNd
KTsKIAogICAgICAgICAvKiBMYXRjaCBNWENTUiAtIHdlIG1heSBuZWVkIHRv
IHJlc3RvcmUgaXQgYmVsb3cuICovCiAgICAgICAgIGludm9rZV9zdHViKCJz
dG14Y3NyICVbbXhjc3JdIiwgIiIsCkBAIC03NjMwLDcgKzc2MzAsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgfQogICAgICAgICBvcGNbMl0gPSBpbW0x
OwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMzsKLSAgICAg
ICAgb3BjWzNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbM10p
OwogICAgICAgICBpZiAoIHZleC5vcGN4ID09IHZleF9ub25lICkKICAgICAg
ICAgewogICAgICAgICAgICAgLyogQ292ZXIgZm9yIGV4dHJhIHByZWZpeCBi
eXRlLiAqLwpAQCAtNzk3Niw3ICs3OTc2LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIHB4b3AtPnJlZyA9IDB4ZjsgLyogckFYICovCiAgICAgICAgIGJ1
ZlszXSA9IGI7CiAgICAgICAgIGJ1Zls0XSA9IChtb2RybSAmIDB4MzgpIHwg
MHgwMTsgLyogci9tPSglckNYKSAqLwotICAgICAgICBidWZbNV0gPSAweGMz
OworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls1XSk7CiAKICAgICAgICAgZHN0
LnJlZyA9IGRlY29kZV92ZXhfZ3ByKHZleC5yZWcsICZfcmVncywgY3R4dCk7
CiAgICAgICAgIGVtdWxhdGVfc3R1YihbZHN0XSAiPSZhIiAoZHN0LnZhbCks
ICJjIiAoJnNyYy52YWwpKTsKQEAgLTgwODUsNyArODA4NSw3IEBAIHg4Nl9l
bXVsYXRlKAogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZbNF0g
PSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KICAgICAgICAgKih1
aW50MzJfdCAqKShidWYgKyA1KSA9IGltbTE7Ci0gICAgICAgIGJ1Zls5XSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzldKTsKIAogICAgICAg
ICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0mYyIgKGRzdC52YWwpLCAiW2RzdF0i
ICgmc3JjLnZhbCkpOwogCkBAIC04MTgxLDEyICs4MTgxLDEyIEBAIHg4Nl9l
bXVsYXRlKAogCiAgICAgICAgIGlmICggZXZleF9lbmNvZGVkKCkgKQogICAg
ICAgICB7Ci0gICAgICAgICAgICBvcGNbaW5zbl9ieXRlcyAtIEVWRVhfUEZY
X0JZVEVTXSA9IDB4YzM7CisgICAgICAgICAgICBwbGFjZV9yZXQoJm9wY1tp
bnNuX2J5dGVzIC0gRVZFWF9QRlhfQllURVNdKTsKICAgICAgICAgICAgIGNv
cHlfRVZFWChvcGMsIGV2ZXgpOwogICAgICAgICB9CiAgICAgICAgIGVsc2UK
ICAgICAgICAgewotICAgICAgICAgICAgb3BjW2luc25fYnl0ZXMgLSBQRlhf
QllURVNdID0gMHhjMzsKKyAgICAgICAgICAgIHBsYWNlX3JldCgmb3BjW2lu
c25fYnl0ZXMgLSBQRlhfQllURVNdKTsKICAgICAgICAgICAgIGNvcHlfUkVY
X1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIH0KIApAQCAt
ODUxMCw3ICs4NTEwLDcgQEAgaW50IHg4Nl9lbXVsX3JtdygKICAgICAgICAg
cHZleC0+cmVnID0gMHhmOyAvKiByQVggKi8KICAgICAgICAgYnVmWzNdID0g
Y3R4dC0+b3Bjb2RlOwogICAgICAgICBidWZbNF0gPSAweDExOyAvKiByZWc9
ckRYIHIvbT0oJVJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgICplZmxhZ3Mg
Jj0gfkVGTEFHU19NQVNLOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-06.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-06.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IEJ1aWxkIFhlbiB3aXRoIFJldHVybiBUaHVua3MKClRo
ZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uIHNwZWN1bGF0aXZlIHZ1bG5l
cmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRpcmVjdApicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QgaGFsZiBv
ZiBhIGNhY2hlbGluZS4KCkluIG9yZGVyIHRvIG1pdGlnYXRlIHRoaXMsIGJ1
aWxkIHdpdGggcmV0dXJuIHRodW5rcyBhbmQgYXJyYW5nZSBmb3IKX194ODZf
cmV0dXJuX3RodW5rIHRvIGJlIChtaXMpYWxpZ25lZCBpbiB0aGUgc2FtZSBt
YW5uZXIgYXMKX194ODZfaW5kaXJlY3RfdGh1bmtfKiBzbyB0aGUgUkVUIGlu
c3RydWN0aW9uIGlzIHBsYWNlZCBpbiBhIHNhZmUgbG9jYXRpb24uCgpwbGFj
ZV9yZXQoKSBuZWVkcyB0byBjb25kaXRpb25hbGx5IGVtaXQgSk1QIF9feDg2
X3JldHVybl90aHVuayBpbnN0ZWFkIG9mIFJFVC4KClRoaXMgaXMgcGFydCBv
ZiBYU0EtNDY5IC8gQ1ZFLTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnIGIveGVu
L2FyY2gveDg2L0tjb25maWcKaW5kZXggOWNkZDA0NzIxYWZhLi45NmZkMWMz
MjcyZDEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnCisrKyBi
L3hlbi9hcmNoL3g4Ni9LY29uZmlnCkBAIC0zOCw5ICszOCwxNCBAQCBjb25m
aWcgQVJDSF9ERUZDT05GSUcKIAlkZWZhdWx0ICJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCiAKIGNvbmZpZyBDQ19IQVNfSU5ESVJFQ1Rf
VEhVTksKKwkjIEdDQyA+PSA4IG9yIENsYW5nID49IDYKIAlkZWZfYm9vbCAk
KGNjLW9wdGlvbiwtbWluZGlyZWN0LWJyYW5jaC1yZWdpc3RlcikgfHwgXAog
CSAgICAgICAgICQoY2Mtb3B0aW9uLC1tcmV0cG9saW5lLWV4dGVybmFsLXRo
dW5rKQogCitjb25maWcgQ0NfSEFTX1JFVFVSTl9USFVOSworCSMgR0NDID49
IDggb3IgQ2xhbmcgPj0gMTUKKwlkZWZfYm9vbCAkKGNjLW9wdGlvbiwtbWZ1
bmN0aW9uLXJldHVybj10aHVuay1leHRlcm4pCisKIGNvbmZpZyBIQVNfQVNf
Q0VUX1NTCiAJIyBiaW51dGlscyA+PSAyLjI5IG9yIExMVk0gPj0gNgogCWRl
Zl9ib29sICQoYXMtaW5zdHIsd3Jzc3EgJXJheCQoY29tbWEpMDtzZXRzc2Jz
eSkKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hlbi9h
cmNoL3g4Ni9NYWtlZmlsZQppbmRleCAwMmFiMjM1ZGU3ZmYuLmEwOTU0YTZh
OGMxNCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisrKyBi
L3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtNDMsNiArNDMsNyBAQCBvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KK29iai0kKENPTkZJR19SRVRV
Uk5fVEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KIG9iai0kKENPTkZJR19Q
VikgKz0gaW9wb3J0X2VtdWxhdGUubwogb2JqLXkgKz0gaXJxLm8KIG9iai0k
KENPTkZJR19LRVhFQykgKz0gbWFjaGluZV9rZXhlYy5vCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJvdC5TIGIveGVuL2FyY2gv
eDg2L2FjcGkvd2FrZXVwX3Byb3QuUwppbmRleCBhNzQxZDU4YjkxMTcuLjky
YWY2MjMwYjMxZiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvd2Fr
ZXVwX3Byb3QuUworKysgYi94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJv
dC5TCkBAIC0xMzMsNyArMTMzLDcgQEAgTEFCRUwoczNfcmVzdW1lKQogICAg
ICAgICBwb3AgICAgICVyMTIKICAgICAgICAgcG9wICAgICAlcmJ4CiAgICAg
ICAgIHBvcCAgICAgJXJicAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBF
TkQoZG9fc3VzcGVuZF9sb3dsZXZlbCkKIAogLmRhdGEKZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jIGIveGVuL2FyY2gveDg2L2Fs
dGVybmF0aXZlLmMKaW5kZXggZWM0NTFkOTYyYzEwLi4xYjcxYWU5NTlhYmUg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCisrKyBi
L3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCkBAIC0xMzcsMTYgKzEzNyw0
NSBAQCB2b2lkIGluaXRfb3JfbGl2ZXBhdGNoIGFkZF9ub3BzKHZvaWQgKmlu
c25zLCB1bnNpZ25lZCBpbnQgbGVuKQogICAgIH0KIH0KIAordm9pZCBub2Nh
bGwgX194ODZfcmV0dXJuX3RodW5rKHZvaWQpOworCiAvKgogICogUGxhY2Ug
YSByZXR1cm4gYXQgQHB0ci4gIEBwdHIgbXVzdCBiZSBpbiB0aGUgd3JpdGFi
bGUgYWxpYXMgb2YgYSBzdHViLgogICoKKyAqIFdoZW4gQ09ORklHX1JFVFVS
Tl9USFVOSyBpcyBhY3RpdmUsIHRoaXMgbWF5IGJlIGEgSk1QIF9feDg2X3Jl
dHVybl90aHVuaworICogaW5zdGVhZCwgZGVwZW5kaW5nIG9uIHRoZSBzYWZl
dHkgb2YgQHB0ciB3aXRoIHJlc3BlY3QgdG8gSW5kaXJlY3QgVGFyZ2V0Cisg
KiBTZWxlY3Rpb24uCisgKgogICogUmV0dXJucyB0aGUgbmV4dCBwb3NpdGlv
biB0byB3cml0ZSBpbnRvIHRoZSBzdHViLgogICovCiB2b2lkICpwbGFjZV9y
ZXQodm9pZCAqcHRyKQogeworICAgIHVuc2lnbmVkIGxvbmcgYWRkciA9ICh1
bnNpZ25lZCBsb25nKXB0cjsKICAgICB1aW50OF90ICpwID0gcHRyOwogCi0g
ICAgKnArKyA9IDB4YzM7CisgICAgLyoKKyAgICAgKiBXaGVuIFJldHVybiBU
aHVua3MgYXJlIHVzZWQsIGlmIGEgUkVUIHdvdWxkIGJlIHVuc2FmZSBhdCB0
aGlzIGxvY2F0aW9uCisgICAgICogd2l0aCByZXNwZWN0IHRvIEluZGlyZWN0
IFRhcmdldCBTZWxlY3Rpb24gKGkuZS4gaWYgYWRkciBpcyBpbiB0aGUgZmly
c3QKKyAgICAgKiBoYWxmIG9mIGEgY2FjaGVsaW5lKSwgaW5zZXJ0IGEgSk1Q
IF9feDg2X3JldHVybl90aHVuayBpbnN0ZWFkLgorICAgICAqCisgICAgICog
VGhlIGRpc3BsYWNlbWVudCBuZWVkcyB0byBiZSByZWxhdGl2ZSB0byB0aGUg
ZXhlY3V0YWJsZSBhbGlhcyBvZiB0aGUKKyAgICAgKiBzdHViLCBub3QgdG8g
QHB0ciB3aGljaCBpcyB0aGUgd3JpdGVhYmxlIGFsaWFzLgorICAgICAqLwor
ICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfUkVUVVJOX1RIVU5LKSAmJiAh
KGFkZHIgJiAweDIwKSApCisgICAgeworICAgICAgICBsb25nIHN0dWJfdmEg
PSAodGhpc19jcHUoc3R1YnMuYWRkcikgJiBQQUdFX01BU0spICsgKGFkZHIg
JiB+UEFHRV9NQVNLKTsKKyAgICAgICAgbG9uZyBkaXNwID0gKGxvbmcpX194
ODZfcmV0dXJuX3RodW5rIC0gKHN0dWJfdmEgKyA1KTsKKworICAgICAgICBC
VUdfT04oKGludDMyX3QpZGlzcCAhPSBkaXNwKTsKKworICAgICAgICAqcCsr
ID0gMHhlOTsKKyAgICAgICAgKihpbnQzMl90ICopcCA9IGRpc3A7CisgICAg
ICAgIHAgKz0gNDsKKyAgICB9CisgICAgZWxzZQorICAgIHsKKyAgICAgICAg
KnArKyA9IDB4YzM7CisgICAgfQogCiAgICAgcmV0dXJuIHA7CiB9CmRpZmYg
LS1naXQgYS94ZW4vYXJjaC94ODYvYXJjaC5tayBiL3hlbi9hcmNoL3g4Ni9h
cmNoLm1rCmluZGV4IGNiNDdkNzI5OTExZS4uZWZkYmRiNjA0NWJlIDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYvYXJjaC5taworKysgYi94ZW4vYXJjaC94
ODYvYXJjaC5tawpAQCAtNDQsNiArNDQsOSBAQCBDRkxBR1MtJChDT05GSUdf
Q0NfSVNfR0NDKSArPSAtZm5vLWp1bXAtdGFibGVzCiBDRkxBR1MtJChDT05G
SUdfQ0NfSVNfQ0xBTkcpICs9IC1tcmV0cG9saW5lLWV4dGVybmFsLXRodW5r
CiBlbmRpZgogCisjIENvbXBpbGUgd2l0aCByZXR1cm4gdGh1bmsgc3VwcG9y
dCBpZiBzZWxlY3RlZC4KK0NGTEFHUy0kKENPTkZJR19SRVRVUk5fVEhVTksp
ICs9IC1tZnVuY3Rpb24tcmV0dXJuPXRodW5rLWV4dGVybgorCiAjIERpc2Fi
bGUgdGhlIGFkZGl0aW9uIG9mIGEgLm5vdGUuZ251LnByb3BlcnR5IHNlY3Rp
b24gdG8gb2JqZWN0IGZpbGVzIHdoZW4KICMgbGl2ZXBhdGNoIHN1cHBvcnQg
aXMgZW5hYmxlZC4gIFRoZSBjb250ZW50cyBvZiB0aGF0IHNlY3Rpb24gY2Fu
IGNoYW5nZQogIyBkZXBlbmRpbmcgb24gdGhlIGluc3RydWN0aW9ucyB1c2Vk
LCBhbmQgbGl2ZXBhdGNoLWJ1aWxkLXRvb2xzIGRvZXNuJ3Qga25vdwpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2JoYi10aHVuay5TIGIveGVuL2FyY2gv
eDg2L2JoYi10aHVuay5TCmluZGV4IDUyNjI1ZjRlMmMxNy4uN2Y5MjIwMWEz
Y2JiIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvYmhiLXRodW5rLlMKKysr
IGIveGVuL2FyY2gveDg2L2JoYi10aHVuay5TCkBAIC0yMyw3ICsyMyw3IEBA
IEZVTkMoY2xlYXJfYmhiX3RzeCkKIDA6ICAgICAgLmJ5dGUgMHhjNiwgMHhm
OCwgMCAgICAgICAgICAgICAvKiB4YWJvcnQgJDAgKi8KICAgICAgICAgaW50
MwogMToKLSAgICAgICAgcmV0CisgICAgICAgIFJFVAogRU5EKGNsZWFyX2Jo
Yl90c3gpCiAKIC8qCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvY2xlYXJf
cGFnZS5TIGIveGVuL2FyY2gveDg2L2NsZWFyX3BhZ2UuUwppbmRleCBkNmMw
NzZmMWQ4YmMuLmRjM2MzYzI2YmZiNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L2NsZWFyX3BhZ2UuUworKysgYi94ZW4vYXJjaC94ODYvY2xlYXJfcGFn
ZS5TCkBAIC0xLDYgKzEsOCBAQAogICAgICAgICAuZmlsZSBfX0ZJTEVfXwog
CiAjaW5jbHVkZSA8eGVuL2xpbmthZ2UuaD4KKworI2luY2x1ZGUgPGFzbS9h
c21fZGVmbnMuaD4KICNpbmNsdWRlIDxhc20vcGFnZS5oPgogCiBGVU5DKGNs
ZWFyX3BhZ2Vfc3NlMikKQEAgLTE2LDUgKzE4LDUgQEAgRlVOQyhjbGVhcl9w
YWdlX3NzZTIpCiAgICAgICAgIGpueiAgICAgMGIKIAogICAgICAgICBzZmVu
Y2UKLSAgICAgICAgcmV0CisgICAgICAgIFJFVAogRU5EKGNsZWFyX3BhZ2Vf
c3NlMikKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUyBi
L3hlbi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUwppbmRleCBjM2M0MzY1NDViYWMu
LmU0M2U1MzcwYzgxNSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2NvcHlf
cGFnZS5TCisrKyBiL3hlbi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUwpAQCAtMSw2
ICsxLDggQEAKICAgICAgICAgLmZpbGUgX19GSUxFX18KIAogI2luY2x1ZGUg
PHhlbi9saW5rYWdlLmg+CisKKyNpbmNsdWRlIDxhc20vYXNtX2RlZm5zLmg+
CiAjaW5jbHVkZSA8YXNtL3BhZ2UuaD4KIAogI2RlZmluZSBzcmNfcmVnICVy
c2kKQEAgLTQxLDUgKzQzLDUgQEAgRlVOQyhjb3B5X3BhZ2Vfc3NlMikKICAg
ICAgICAgbW92bnRpICB0bXA0X3JlZywgMypXT1JEX1NJWkUoZHN0X3JlZykK
IAogICAgICAgICBzZmVuY2UKLSAgICAgICAgcmV0CisgICAgICAgIFJFVAog
RU5EKGNvcHlfcGFnZV9zc2UyKQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2
L2VmaS9jaGVjay5jIGIveGVuL2FyY2gveDg2L2VmaS9jaGVjay5jCmluZGV4
IDllNDczZmFhZDNjOS4uMjNiYTMwYWJmMzMwIDEwMDY0NAotLS0gYS94ZW4v
YXJjaC94ODYvZWZpL2NoZWNrLmMKKysrIGIveGVuL2FyY2gveDg2L2VmaS9j
aGVjay5jCkBAIC0zLDYgKzMsOSBAQCBpbnQgX19hdHRyaWJ1dGVfXygoX19t
c19hYmlfXykpIHRlc3QoaW50IGkpCiAgICAgcmV0dXJuIGk7CiB9CiAKKy8q
IEluIGNhc2UgLW1mdW5jdGlvbi1yZXR1cm4gaXMgaW4gdXNlLiAqLwordm9p
ZCBfX3g4Nl9yZXR1cm5fdGh1bmsodm9pZCkge307CisKIC8qCiAgKiBQb3B1
bGF0ZSBhbiBhcnJheSB3aXRoICJhZGRyZXNzZXMiIG9mIHJlbG9jYXRhYmxl
IGFuZCBhYnNvbHV0ZSB2YWx1ZXMuCiAgKiBUaGlzIGlzIHRvIHByb2JlIGxk
IGZvciAoYSkgZW1pdHRpbmcgYmFzZSByZWxvY2F0aW9ucyBhdCBhbGwgYW5k
IChiKSBub3QKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9hc20tZGVmbnMuaCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hc20t
ZGVmbnMuaAppbmRleCAzMmQ2YjQ0OTEwNjMuLjk3ZWJlMjEyOThhMiAxMDA2
NDQKLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1kZWZucy5o
CisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hc20tZGVmbnMuaApA
QCAtNTgsNiArNTgsMTIgQEAKICAgICAuZW5kaWYKIC5lbmRtCiAKKyNpZmRl
ZiBDT05GSUdfUkVUVVJOX1RIVU5LCisjIGRlZmluZSBSRVQgam1wIF9feDg2
X3JldHVybl90aHVuaworI2Vsc2UKKyMgZGVmaW5lIFJFVCByZXQKKyNlbmRp
ZgorCiAjaWZkZWYgQ09ORklHX1hFTl9JQlQKICMgZGVmaW5lIEVOREJSNjQg
ZW5kYnI2NAogI2Vsc2UKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TIGIveGVuL2FyY2gveDg2L2luZGlyZWN0LXRodW5rLlMK
aW5kZXggYzRiOTc4ZDY3YjhlLi4yNmRhZDE1ZjEyYzkgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9pbmRpcmVjdC10aHVuay5TCisrKyBiL3hlbi9hcmNo
L3g4Ni9pbmRpcmVjdC10aHVuay5TCkBAIC0xNSw2ICsxNSw4IEBACiAjdW5k
ZWYgU1lNX0FMSUdOCiAjZGVmaW5lIFNZTV9BTElHTihhbGlnbi4uLikKIAor
I2lmZGVmIENPTkZJR19JTkRJUkVDVF9USFVOSworCiAubWFjcm8gSU5EX1RI
VU5LX1JFVFBPTElORSByZWc6cmVxCiAgICAgICAgIGNhbGwgMWYKICAgICAg
ICAgaW50MwpAQCAtNjIsMyArNjQsMjUgQEAgRU5EKF9feDg2X2luZGlyZWN0
X3RodW5rX1xyZWcpCiAuaXJwIHJlZywgYXgsIGN4LCBkeCwgYngsIGJwLCBz
aSwgZGksIDgsIDksIDEwLCAxMSwgMTIsIDEzLCAxNCwgMTUKICAgICAgICAg
R0VOX0lORElSRUNUX1RIVU5LIHJlZz1yXHJlZwogLmVuZHIKKworI2VuZGlm
IC8qIENPTkZJR19JTkRJUkVDVF9USFVOSyAqLworCisjaWZkZWYgQ09ORklH
X1JFVFVSTl9USFVOSworICAgICAgICAuc2VjdGlvbiAudGV4dC5lbnRyeS5f
X3g4Nl9yZXR1cm5fdGh1bmssICJheCIsIEBwcm9nYml0cworCisgICAgICAg
IC8qCisgICAgICAgICAqIFRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9u
IHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdAorICAgICAg
ICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1
bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QKKyAgICAgICAgICogaGFsZiBvZiBh
IGNhY2hlbGluZS4gIEFycmFuZ2UgZm9yIHRoZW0gdG8gYmUgaW4gdGhlIHNl
Y29uZCBoYWxmLgorICAgICAgICAgKgorICAgICAgICAgKiBBbGlnbiB0byA2
NCwgdGhlbiBza2lwIDMyLgorICAgICAgICAgKi8KKyAgICAgICAgLmJhbGln
biA2NAorICAgICAgICAuZmlsbCAzMiwgMSwgMHhjYworCitGVU5DKF9feDg2
X3JldHVybl90aHVuaykKKyAgICAgICAgcmV0CisgICAgICAgIGludDMgLyog
SGFsdCBzdHJhaWdodC1saW5lIHNwZWN1bGF0aW9uICovCitFTkQoX194ODZf
cmV0dXJuX3RodW5rKQorCisjZW5kaWYgLyogQ09ORklHX1JFVFVSTl9USFVO
SyAqLwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3B2L2VtdWwtcHJpdi1v
cC5jIGIveGVuL2FyY2gveDg2L3B2L2VtdWwtcHJpdi1vcC5jCmluZGV4IGZm
NWQxYzlmODYzNC4uMjk1ZDg0N2VhMjRjIDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvcHYvZW11bC1wcml2LW9wLmMKKysrIGIveGVuL2FyY2gveDg2L3B2
L2VtdWwtcHJpdi1vcC5jCkBAIC0xMzEsNyArMTMxLDcgQEAgc3RhdGljIGlv
X2VtdWxfc3R1Yl90ICppb19lbXVsX3N0dWJfc2V0dXAoc3RydWN0IHByaXZf
b3BfY3R4dCAqY3R4dCwgdTggb3Bjb2RlLAogICAgIEJVSUxEX0JVR19PTihT
VFVCX0JVRl9TSVpFIC8gMiA8CiAgICAgICAgICAgICAgICAgIChzaXplb2Yo
cHJvbG9ndWUpICsgc2l6ZW9mKGVwaWxvZ3VlKSArIDEwIC8qIDJ4IGNhbGwg
Ki8gKwogICAgICAgICAgICAgICAgICAgTUFYKDMgLyogZGVmYXVsdCBzdHVi
ICovLCBJT0VNVUxfUVVJUktfU1RVQl9CWVRFUykgKwotICAgICAgICAgICAg
ICAgICAgMSAvKiByZXQgKi8pKTsKKyAgICAgICAgICAgICAgICAgIChJU19F
TkFCTEVEKENPTkZJR19SRVRVUk5fVEhVTkspID8gNSA6IDEpIC8qIHJldCAq
LykpOwogICAgIC8qIFJ1bnRpbWUgY29uZmlybWF0aW9uIHRoYXQgd2UgaGF2
ZW4ndCBjbG9iYmVyZWQgYW4gYWRqYWNlbnQgc3R1Yi4gKi8KICAgICBCVUdf
T04oU1RVQl9CVUZfU0laRSAvIDIgPCAocCAtIGN0eHQtPmlvX2VtdWxfc3R1
YikpOwogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRj
aC5TIGIveGVuL2FyY2gveDg2L3B2L2dwcl9zd2l0Y2guUwppbmRleCA1NDA5
YWQzYjE0NDcuLjM2MmI1ZDI0MTYyMyAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L3B2L2dwcl9zd2l0Y2guUworKysgYi94ZW4vYXJjaC94ODYvcHYvZ3By
X3N3aXRjaC5TCkBAIC0yNiw3ICsyNiw3IEBAIEZVTkMobG9hZF9ndWVzdF9n
cHJzKQogICAgICAgICBtb3ZxICBVUkVHU19yMTUoJXJkaSksICVyMTUKICAg
ICAgICAgbW92cSAgVVJFR1NfcmN4KCVyZGkpLCAlcmN4CiAgICAgICAgIG1v
dnEgIFVSRUdTX3JkaSglcmRpKSwgJXJkaQotICAgICAgICByZXQKKyAgICAg
ICAgUkVUCiBFTkQobG9hZF9ndWVzdF9ncHJzKQogCiAvKiBTYXZlIGd1ZXN0
IEdQUnMuICBQYXJhbWV0ZXIgb24gdGhlIHN0YWNrIGFib3ZlIHRoZSByZXR1
cm4gYWRkcmVzcy4gKi8KQEAgLTQ4LDUgKzQ4LDUgQEAgRlVOQyhzYXZlX2d1
ZXN0X2dwcnMpCiAgICAgICAgIG1vdnEgICVyYngsIFVSRUdTX3JieCglcmRp
KQogICAgICAgICBtb3ZxICAlcmR4LCBVUkVHU19yZHgoJXJkaSkKICAgICAg
ICAgbW92cSAgJXJjeCwgVVJFR1NfcmN4KCVyZGkpCi0gICAgICAgIHJldAor
ICAgICAgICBSRVQKIEVORChzYXZlX2d1ZXN0X2dwcnMpCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3Bl
Y19jdHJsLmMKaW5kZXggY2VkODQ3NTAwMTVjLi5mZTI3ZTgyYTQ3MDcgMTAw
NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4v
YXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTU3MSw2ICs1NzEsOSBAQCBzdGF0
aWMgdm9pZCBfX2luaXQgcHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0
aHVuaykKICNpZmRlZiBDT05GSUdfSU5ESVJFQ1RfVEhVTksKICAgICAgICAg
ICAgICAgICIgSU5ESVJFQ1RfVEhVTksiCiAjZW5kaWYKKyNpZmRlZiBDT05G
SUdfUkVUVVJOX1RIVU5LCisgICAgICAgICAgICAgICAiIFJFVFVSTl9USFVO
SyIKKyNlbmRpZgogI2lmZGVmIENPTkZJR19TSEFET1dfUEFHSU5HCiAgICAg
ICAgICAgICAgICAiIFNIQURPV19QQUdJTkciCiAjZW5kaWYKZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMgYi94ZW4v
YXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCmluZGV4IDFlODc2NTJm
NGJjYi4uZDdiMzgxZWE1NDZkIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYv
eDg2XzY0L2NvbXBhdC9lbnRyeS5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZf
NjQvY29tcGF0L2VudHJ5LlMKQEAgLTE4MCw3ICsxODAsNyBAQCBGVU5DKGNy
NF9wdjMyX3Jlc3RvcmUpCiAgICAgICAgIG9yICAgIGNyNF9wdjMyX21hc2so
JXJpcCksICVyYXgKICAgICAgICAgbW92ICAgJXJheCwgJWNyNAogICAgICAg
ICBtb3YgICAlcmF4LCAoJXJjeCkKLSAgICAgICAgcmV0CisgICAgICAgIFJF
VAogMDoKICNpZm5kZWYgTkRFQlVHCiAgICAgICAgIC8qIENoZWNrIHRoYXQg
X2FsbF8gb2YgdGhlIGJpdHMgaW50ZW5kZWQgdG8gYmUgc2V0IGFjdHVhbGx5
IGFyZS4gKi8KQEAgLTE5OCw3ICsxOTgsNyBAQCBGVU5DKGNyNF9wdjMyX3Jl
c3RvcmUpCiAxOgogI2VuZGlmCiAgICAgICAgIHhvciAgICVlYXgsICVlYXgK
LSAgICAgICAgcmV0CisgICAgICAgIFJFVAogRU5EKGNyNF9wdjMyX3Jlc3Rv
cmUpCiAKIEZVTkMoY29tcGF0X3N5c2NhbGwpCkBAIC0zMjksNyArMzI5LDcg
QEAgX19VTkxJS0VMWV9FTkQoY29tcGF0X2JvdW5jZV9udWxsX3NlbGVjdG9y
KQogICAgICAgICB4b3IgICAlZWF4LCAlZWF4CiAgICAgICAgIG1vdiAgICVh
eCwgIFRSQVBCT1VOQ0VfY3MoJXJkeCkKICAgICAgICAgbW92ICAgJWFsLCAg
VFJBUEJPVU5DRV9mbGFncyglcmR4KQotICAgICAgICByZXQKKyAgICAgICAg
UkVUCiAKIC5zZWN0aW9uIC5maXh1cCwiYXgiCiAuTGZ4MTM6CmRpZmYgLS1n
aXQgYS94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMgYi94ZW4vYXJjaC94
ODYveDg2XzY0L2VudHJ5LlMKaW5kZXggNDBkMDk0ZDViMmVlLi42ZWZjNmJh
YjFlZGIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnku
UworKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKQEAgLTYwNCw3
ICs2MDQsNyBAQCBfX1VOTElLRUxZX0VORChjcmVhdGVfYm91bmNlX2ZyYW1l
X2JhZF9ib3VuY2VfaXApCiAgICAgICAgIHhvciAgICVlYXgsICVlYXgKICAg
ICAgICAgbW92ICAgJXJheCwgVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAg
ICAgbW92ICAgJWFsLCAgVFJBUEJPVU5DRV9mbGFncyglcmR4KQotICAgICAg
ICByZXQKKyAgICAgICAgUkVUCiAKICAgICAgICAgLnB1c2hzZWN0aW9uIC5m
aXh1cCwgImF4IiwgQHByb2diaXRzCiAgICAgICAgICMgTnVtZXJpYyB0YWdz
IGJlbG93IHJlcHJlc2VudCB0aGUgaW50ZW5kZWQgb3ZlcmFsbCAlcnNpIGFk
anVzdG1lbnQuCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYveGVuLmxkcy5T
IGIveGVuL2FyY2gveDg2L3hlbi5sZHMuUwppbmRleCA0MjIxN2VhZjI0ODUu
LmU2YzcxYThlM2UyMSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3hlbi5s
ZHMuUworKysgYi94ZW4vYXJjaC94ODYveGVuLmxkcy5TCkBAIC04Myw2ICs4
Myw3IEBAIFNFQ1RJT05TCiAgICAgICAgLiA9IEFMSUdOKFBBR0VfU0laRSk7
CiAgICAgICAgX3N0ZXh0ZW50cnkgPSAuOwogICAgICAgICooLnRleHQuZW50
cnkpCisgICAgICAgKigudGV4dC5lbnRyeS4qKQogICAgICAgIC4gPSBBTElH
TihQQUdFX1NJWkUpOwogICAgICAgIF9ldGV4dGVudHJ5ID0gLjsKIApkaWZm
IC0tZ2l0IGEveGVuL2NvbW1vbi9LY29uZmlnIGIveGVuL2NvbW1vbi9LY29u
ZmlnCmluZGV4IDYxNjYzMjdmNGQxNC4uN2Q5NDQyZWMwNWMxIDEwMDY0NAot
LS0gYS94ZW4vY29tbW9uL0tjb25maWcKKysrIGIveGVuL2NvbW1vbi9LY29u
ZmlnCkBAIC0xMzYsNiArMTM2LDE3IEBAIGNvbmZpZyBJTkRJUkVDVF9USFVO
SwogCSAgV2hlbiBlbmFibGVkLCBpbmRpcmVjdCBicmFuY2hlcyBhcmUgaW1w
bGVtZW50ZWQgdXNpbmcgYSBuZXcgY29uc3RydWN0CiAJICBjYWxsZWQgInJl
dHBvbGluZSIgdGhhdCBwcmV2ZW50cyBzcGVjdWxhdGlvbi4KIAorY29uZmln
IFJFVFVSTl9USFVOSworCWJvb2wgIk91dC1vZi1saW5lIFJldHVybnMiCisJ
ZGVwZW5kcyBvbiBDQ19IQVNfUkVUVVJOX1RIVU5LCisJZGVmYXVsdCBJTkRJ
UkVDVF9USFVOSworCWhlbHAKKwkgIENvbXBpbGUgWGVuIHdpdGggb3V0LW9m
LWxpbmUgcmV0dXJucy4KKworCSAgVGhpcyBhbGxvd3MgWGVuIHRvIG1pdGln
YXRlIGEgdmFyaWV0eSBvZiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXRpZXMK
KwkgIGJ5IGNob29zaW5nIGEgaGFyZHdhcmUtZGVwZW5kZW50IGluc3RydWN0
aW9uIHNlcXVlbmNlIHRvIGltcGxlbWVudAorCSAgZnVuY3Rpb24gcmV0dXJu
cyBzYWZlbHkuCisKIGNvbmZpZyBTUEVDVUxBVElWRV9IQVJERU5fQVJSQVkK
IAlib29sICJTcGVjdWxhdGl2ZSBBcnJheSBIYXJkZW5pbmciCiAJZGVmYXVs
dCB5CmRpZmYgLS1naXQgYS94ZW4vbGliL3g4Ni1nZW5lcmljLWh3ZWlnaHRs
LmMgYi94ZW4vbGliL3g4Ni1nZW5lcmljLWh3ZWlnaHRsLmMKaW5kZXggMTIz
YTViNDM5MjhkLi4xY2FiNjg5NTJhNDIgMTAwNjQ0Ci0tLSBhL3hlbi9saWIv
eDg2LWdlbmVyaWMtaHdlaWdodGwuYworKysgYi94ZW4vbGliL3g4Ni1nZW5l
cmljLWh3ZWlnaHRsLmMKQEAgLTUxLDcgKzUxLDExIEBAIGFzbSAoCiAgICAg
InBvcCAgICAlcmR4XG5cdCIKICAgICAicG9wICAgICVyZGlcblx0IgogCisj
aWZkZWYgQ09ORklHX1JFVFVSTl9USFVOSworICAgICJqbXAgICAgX194ODZf
cmV0dXJuX3RodW5rXG5cdCIKKyNlbHNlCiAgICAgInJldFxuXHQiCisjZW5k
aWYKIAogICAgICIuc2l6ZSBhcmNoX2dlbmVyaWNfaHdlaWdodGwsIC4gLSBh
cmNoX2dlbmVyaWNfaHdlaWdodGxcblx0IgogKTsK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-07.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-07.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogU3ludGhlc2lzZSBJVFNfTk8g
dG8gZ3Vlc3RzIG9uIHVuYWZmZWN0ZWQgaGFyZHdhcmUKCkl0IGlzIGVhc2ll
ciB0byBleHByZXNzIGZlYXR1cmUgd29yZCAxNyBpbiB0ZXJtcyBvZiB3b3Jk
IDE2ICsgWzMyLCA2NCkgYXMKdGhhdCdzIGhvdyB0aGUgbGF5b3V0IGlzIGdp
dmVuIGluIGRvY3VtZW50YXRpb24uCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2
OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29v
cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKaW5k
ZXggM2EwNmI2ZjI5N2I5Li4yNGIwMjFlZWZmYzggMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKKysrIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaApAQCAtMjE4LDYg
KzIxOCw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBib290X2NwdV9oYXModW5z
aWduZWQgaW50IGZlYXQpCiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAgICAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCiAjZGVmaW5l
IGNwdV9oYXNfcmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9SRkRTX05PKQogI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIgICAg
ICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKKyNkZWZp
bmUgY3B1X2hhc19pdHNfbm8gICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX0lUU19OTykKIAogLyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5l
IGNwdV9oYXNfYXJjaF9wZXJmbW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9BUkNIX1BFUkZNT04pCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg
ZmUyN2U4MmE0NzA3Li4wYTYzNTAyNWU0ODggMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMKQEAgLTE3NjAsNiArMTc2MCw5MCBAQCBzdGF0aWMgdm9pZCBfX2lu
aXQgYmhpX2NhbGN1bGF0aW9ucyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAq
IGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZl
bG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1
aWRhbmNlL2Fkdmlzb3J5LWd1aWRhbmNlL2luZGlyZWN0LXRhcmdldC1zZWxl
Y3Rpb24uaHRtbAorICovCitzdGF0aWMgdm9pZCBfX2luaXQgaXRzX2NhbGN1
bGF0aW9ucyh2b2lkKQoreworICAgIC8qCisgICAgICogSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBpcyBhIEJyYW5jaCBQcmVkaWN0aW9uIGJ1ZyB3aGVy
ZWJ5IGNlcnRhaW4KKyAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGdldCBwcmVkaWN0ZWQgdXNpbmcgYSBkaXJlY3QgYnJhbmNo
CisgICAgICogdGFyZ2V0LCByYXRoZXIgdGhhbiBhIHN1aXRhYmxlIGluZGly
ZWN0IHRhcmdldCwgYnlwYXNzaW5nIGhhcmR3YXJlCisgICAgICogaXNvbGF0
aW9uIHByb3RlY3Rpb25zLgorICAgICAqCisgICAgICogSVRTIGFmZmVjdHMg
Q29yZSAoYnV0IG5vdCBBdG9tKSBwcm9jZXNzb3JzIHN0YXJ0aW5nIGZyb20g
dGhlCisgICAgICogaW50cm9kdWN0aW9uIG9mIGVJQlJTLCB1cCB0byBidXQg
bm90IGluY2x1ZGluZyBHb2xkZW4gQ292ZSBjb3JlcworICAgICAqIChjaGVj
a2VkIGhlcmUgd2l0aCBCSElfQ1RSTCkuCisgICAgICoKKyAgICAgKiBUaGUg
SVRTX05PIGZlYXR1cmUgaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVudW1lcmF0
ZWQgYnkgaGFyZHdhcmUsIGFuZCBpcworICAgICAqIG9ubHkgZm9yIFZNTXMg
dG8gc3ludGhlc2lzZSBmb3IgZ3Vlc3RzLgorICAgICAqCisgICAgICogSVRT
IGNvbWVzIGluIDMgZmxhdm91cnM6CisgICAgICoKKyAgICAgKiAgIDEpIEFj
cm9zcy1JQlBCLiAgSW5kaXJlY3QgYnJhbmNoZXMgYWZ0ZXIgdGhlIElCUEIg
Y2FuIGJlIGNvbnRyb2xsZWQKKyAgICAgKiAgICAgIGJ5IGRpcmVjdCB0YXJn
ZXRzIHdoaWNoIGV4aXN0ZWQgcHJpb3IgdG8gdGhlIElCUEIuICBUaGlzIGlz
CisgICAgICogICAgICBhZGRyZXNzZWQgaW4gdGhlIElQVSAyMDI1LjEgbWlj
cm9jb2RlIGRyb3AsIGFuZCBoYXMgbm8gb3RoZXIKKyAgICAgKiAgICAgIHNv
ZnR3YXJlIGludGVyYWN0aW9uLgorICAgICAqCisgICAgICogICAyKSBHdWVz
dC9Ib3N0LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgZGlyZWN0IHRhcmdldHMgZnJv
bSB0aGUgZ3Vlc3QuICBUaGlzIGFwcGxpZXMgZXF1YWxseSB0byBQViBndWVz
dHMKKyAgICAgKiAgICAgIChSaW5nMykgYW5kIEhWTSBndWVzdHMgKFZNWCks
IGFuZCBhcHBsaWVzIHRvIGFsbCBTa3lsYWtlLXVhcmNoCisgICAgICogICAg
ICBjb3JlcyB3aXRoIGVJQlJTLgorICAgICAqCisgICAgICogICAzKSBJbnRy
YS1tb2RlLiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgb3RoZXIgZXhlY3V0aW9uIGlu
IHRoZSBzYW1lIG1vZGUuCisgICAgICovCisKKyAgICAvKgorICAgICAqIElm
IHdlIGNhbiBzZWUgSVRTX05PLCBvciB3ZSdyZSB2aXJ0dWFsaXNlZCwgZG8g
bm90aGluZy4gIFdlIGFyZSBvciBtYXkKKyAgICAgKiBtaWdyYXRlIHNvbWV3
aGVyZSB1bnNhZmUuCisgICAgICovCisgICAgaWYgKCBjcHVfaGFzX2l0c19u
byB8fCBjcHVfaGFzX2h5cGVydmlzb3IgKQorICAgICAgICByZXR1cm47CisK
KyAgICAvKiBJVFMgaXMgb25seSBrbm93biB0byBhZmZlY3QgSW50ZWwgcHJv
Y2Vzc29ycyBhdCB0aGlzIHRpbWUuICovCisgICAgaWYgKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9JTlRFTCApCisgICAgICAg
IHJldHVybjsKKworICAgIC8qCisgICAgICogSVRTIGRvZXMgbm90IGV4aXN0
IG9uOgorICAgICAqICAtIG5vbi1GYW1pbHkgNiBDUFVzCisgICAgICogIC0g
dGhvc2Ugd2l0aG91dCBlSUJSUworICAgICAqICAtIHRob3NlIHdpdGggQkhJ
X0NUUkwKKyAgICAgKiBidXQgd2Ugc3RpbGwgbmVlZCB0byBzeW50aGVzaXNl
IElUU19OTy4KKyAgICAgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2
ICE9IDYgfHwgIWNwdV9oYXNfZWlicnMgfHwKKyAgICAgICAgIGJvb3RfY3B1
X2hhcyhYODZfRkVBVFVSRV9CSElfQ1RSTCkgKQorICAgICAgICBnb3RvIHN5
bnRoZXNpc2U7CisKKyAgICBzd2l0Y2ggKCBib290X2NwdV9kYXRhLng4Nl9t
b2RlbCApCisgICAgeworICAgICAgICAvKiBUaGVzZSBTa3lsYWtlLXVhcmNo
IGNvcmVzIHN1ZmZlciBjYXNlcyAjMiBhbmQgIzMuICovCisgICAgY2FzZSBJ
TlRFTF9GQU02X1NLWUxBS0VfWDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FC
WUxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0U6CisgICAg
Y2FzZSBJTlRFTF9GQU02X0NPTUVUTEFLRToKKyAgICBjYXNlIElOVEVMX0ZB
TTZfQ09NRVRMQUtFX0w6CisgICAgICAgIHJldHVybjsKKworICAgICAgICAv
KiBUaGVzZSBTdW5ueS9XaWxsb3cvQ3lwcmVzcyBDb3ZlIGNvcmVzIHN1ZmZl
ciBjYXNlICMzLiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9JQ0VMQUtFX1g6
CisgICAgY2FzZSBJTlRFTF9GQU02X0lDRUxBS0VfRDoKKyAgICBjYXNlIElO
VEVMX0ZBTTZfSUNFTEFLRV9MOgorICAgIGNhc2UgSU5URUxfRkFNNl9USUdF
UkxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfVElHRVJMQUtFOgorICAg
IGNhc2UgSU5URUxfRkFNNl9ST0NLRVRMQUtFOgorICAgICAgICByZXR1cm47
CisKKyAgICBkZWZhdWx0OgorICAgICAgICBicmVhazsKKyAgICB9CisKKyAg
ICAvKiBQbGF0Zm9ybXMgcmVtYWluaW5nIGFyZSBub3QgYmVsaWV2ZWQgdG8g
YmUgdnVsbmVyYWJsZSB0byBJVFMuICovCisgc3ludGhlc2lzZToKKyAgICBz
ZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX0lUU19OTyk7Cit9CisK
IHZvaWQgc3BlY19jdHJsX2luaXRfZG9tYWluKHN0cnVjdCBkb21haW4gKmQp
CiB7CiAgICAgYm9vbCBwdiA9IGlzX3B2X2RvbWFpbihkKTsKQEAgLTIzMTYs
NiArMjQwMCw4IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0
aWdhdGlvbnModm9pZCkKIAogICAgIGJoaV9jYWxjdWxhdGlvbnMoKTsKIAor
ICAgIGl0c19jYWxjdWxhdGlvbnMoKTsKKwogICAgIHByaW50X2RldGFpbHMo
dGh1bmspOwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IDE2MjA3ZTM4
MTdiYi4uMWUwZTg3MGM1YzdkIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNs
dWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTM3OSw3
ICszNzksOCBAQCBYRU5fQ1BVRkVBVFVSRShHRFNfTk8sICAgICAgICAgICAg
IDE2KjMyKzI2KSAvKkEgIE5vIEdhdGhlciBEYXRhIFNhbXBsaW5nICovCiBY
RU5fQ1BVRkVBVFVSRShSRkRTX05PLCAgICAgICAgICAgIDE2KjMyKzI3KSAv
KkEgIE5vIFJlZ2lzdGVyIEZpbGUgRGF0YSBTYW1wbGluZyAqLwogWEVOX0NQ
VUZFQVRVUkUoUkZEU19DTEVBUiwgICAgICAgICAxNiozMisyOCkgLyohQXwg
UmVnaXN0ZXIgRmlsZShzKSBjbGVhcmVkIGJ5IFZFUlcgKi8KIAotLyogSW50
ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMsIE1TUl9BUkNIX0NBUFMgMHgxMGEu
ZWR4LCB3b3JkIDE3ICovCisvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl
cywgTVNSX0FSQ0hfQ0FQUyAweDEwYS5lZHgsIHdvcmQgMTcgKGV4cHJlc3Mg
aW4gdGVybXMgb2Ygd29yZCAxNikgKi8KK1hFTl9DUFVGRUFUVVJFKElUU19O
TywgICAgICAgICAgICAgMTYqMzIrNjIpIC8qIUEgTm8gSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiAqLwogCiAjZW5kaWYgLyogWEVOX0NQVUZFQVRVUkUg
Ki8KIApkaWZmIC0tZ2l0IGEveGVuL3Rvb2xzL2dlbi1jcHVpZC5weSBiL3hl
bi90b29scy9nZW4tY3B1aWQucHkKaW5kZXggYTc3Y2IzMGJkYjRmLi4xNjNi
MTA1YmM2YTcgMTAwNzU1Ci0tLSBhL3hlbi90b29scy9nZW4tY3B1aWQucHkK
KysrIGIveGVuL3Rvb2xzL2dlbi1jcHVpZC5weQpAQCAtNTEsNyArNTEsNyBA
QCBkZWYgcGFyc2VfZGVmaW5pdGlvbnMoc3RhdGUpOgogICAgICAgICByIlxz
Ky9cKihbXHchfF0qKSAuKiQiKQogCiAgICAgd29yZF9yZWdleCA9IHJlLmNv
bXBpbGUoCi0gICAgICAgIHIiXi9cKiAuKiB3b3JkIChcZCopIFwqLyQiKQor
ICAgICAgICByIl4vXCogLiogd29yZCAoXGQqKSAuKlwqLyQiKQogICAgIGxh
c3Rfd29yZCA9IC0xCiAKICAgICB0aGlzID0gc3lzLm1vZHVsZXNbX19uYW1l
X19dCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-04.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-04.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3RodW5rOiAoTWlzKWFsaWduIHRoZSBSRVRzIGlu
IGNsZWFyX2JoYl9sb29wcygpIHRvIG1pdGlnYXRlIElUUwoKVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0IGluZGlyZWN0CmJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdCBoYWxmIG9mIGEgY2Fj
aGVsaW5lLgoKY2xlYXJfYmhiX2xvb3BzKCkgaGFzIGEgcHJlY2lzZSBsYXlv
dXQgb2YgYnJhbmNoZXMuICBUaGUgYWxpZ25tZW50IGZvcgpwZXJmb3JtYW5j
ZSBjYXVzZSB0aGUgUkVUcyB0byBhbHdheXMgYmUgaW4gYW4gdW5zYWZlIHBv
c2l0aW9uLCBhbmQgY29udmVydGluZwp0aG9zZSB0byByZXR1cm4gdGh1bmtz
IGNoYW5nZXMgdGhlIGJyYW5jaGluZyBwYXR0ZXJuLiAgV2hpbGUgc3VjaCBh
IGNvbnZlcnNpb24KaXMgYmVsaWV2ZWQgdG8gYmUgc2FmZSwgY2xlYXJfYmhi
X2xvb3BzKCkgaXMgYWxzbyBhIHBlcmZvcm1hbmNlLXJlbGV2YW50CmZhc3Rw
YXRoLCBzbyAobWlzKWFsaWduIHRoZSBSRVRzIHRvIGJlIGluIGEgc2FmZSBw
b3NpdGlvbi4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0
IG9mIFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUyBi
L3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCBmNWFjNDE4MzRiYmQu
LjcxNzU3NzhiZGQxMSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2JoYi10
aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwpAQCAtNTAs
NyArNTAsMTIgQEAgRU5EKGNsZWFyX2JoYl90c3gpCiAgKiAgIHJldAogICoK
ICAqIFRoZSBDQUxML1JFVHMgYXJlIG5lY2Vzc2FyeSB0byBwcmV2ZW50IHRo
ZSBMb29wIFN0cmVhbSBEZXRlY3RvciBmcm9tCi0gKiBpbnRlcmZlcmluZy4g
IFRoZSBhbGlnbm1lbnQgaXMgZm9yIHBlcmZvcm1hbmNlIGFuZCBub3Qgc2Fm
ZXR5LgorICogaW50ZXJmZXJpbmcuCisgKgorICogVGhlIC5iYWxpZ24ncyBh
cmUgZm9yIHBlcmZvcm1hbmNlLCBidXQgdGhleSBjYXVzZSB0aGUgUkVUcyB0
byBiZSBpbiB1bnNhZmUKKyAqIHBvc2l0aW9ucyB3aXRoIHJlc3BlY3QgdG8g
SW5kaXJlY3QgVGFyZ2V0IFNlbGVjdGlvbi4gIFRoZSAuc2tpcHMgYXJlIHRv
CisgKiBtb3ZlIHRoZSBSRVRzIGludG8gSVRTLXNhZmUgcG9zaXRpb25zLCBy
YXRoZXIgdGhhbiB1c2luZyB0aGUgc2xvd3BhdGgKKyAqIHRocm91Z2ggX194
ODZfcmV0dXJuX3RodW5rLgogICoKICAqIFRoZSAic2hvcnQiIHNlcXVlbmNl
ICg1IGFuZCA1KSBpcyBmb3IgQ1BVcyBwcmlvciB0byBBbGRlciBMYWtlIC8g
U2FwcGhpcmUKICAqIFJhcGlkcyAoaS5lLiBDb3JlcyBwcmlvciB0byBHb2xk
ZW4gQ292ZSBhbmQvb3IgR3JhY2Vtb250KS4KQEAgLTY2LDEyICs3MSwxNCBA
QCBGVU5DKGNsZWFyX2JoYl9sb29wcykKICAgICAgICAgam1wICAgICA1Zgog
ICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAgICAgIC5i
YWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtICguTHIxIC0gMWYpLCAw
eGNjCiAxOiAgICAgIGNhbGwgICAgMmYKLSAgICAgICAgcmV0CisuTHIxOiAg
IHJldAogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAg
ICAgIC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtIDE4IC8qICgu
THIyIC0gMmYpIGJ1dCBDbGFuZyBJQVMgZG9lc24ndCBsaWtlIHRoaXMgKi8s
IDB4Y2MKIDI6ICAgICAgQUxURVJOQVRJVkUgIm1vdiAkNSwgJWVheCIsICJt
b3YgJDcsICVlYXgiLCBYODZfU1BFQ19CSEJfTE9PUFNfTE9ORwogCiAzOiAg
ICAgIGptcCAgICAgNGYKQEAgLTgzLDcgKzkwLDcgQEAgRlVOQyhjbGVhcl9i
aGJfbG9vcHMpCiAgICAgICAgIHN1YiAgICAgJDEsICVlY3gKICAgICAgICAg
am56ICAgICAxYgogCi0gICAgICAgIHJldAorLkxyMjogICByZXQKIDU6CiAg
ICAgICAgIC8qCiAgICAgICAgICAqIFRoZSBJbnRlbCBzZXF1ZW5jZSBoYXMg
YW4gTEZFTkNFIGhlcmUuICBUaGUgcHVycG9zZSBpcyB0byBlbnN1cmUK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-05.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-05.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3N0dWJzOiBJbnRyb2R1Y2UgcGxhY2VfcmV0KCkg
dG8gYWJzdHJhY3QgYXdheSByYXcgMHhjMydzCgpUaGUgSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5z
IHRoYXQgaW5kaXJlY3QKYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUg
dW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0IGhhbGYgb2YgYSBjYWNoZWxpbmUu
ClRoaXMgbWVhbnMgaXQncyBub3Qgc2FmZSBmb3IgbG9naWMgdXNpbmcgdGhl
IHN0dWJzIHRvIHdyaXRlIHJhdyAweGMzJ3MuCgpJbnRyb2R1Y2UgcGxhY2Vf
cmV0KCkgd2hpY2gsIGZvciBub3csIHdyaXRlcyBhIHJhdyAweGMzIGJ1dCB3
aWxsIGNvbnRhaW4KYWRkaXRpb25hbCBsb2dpYyB3aGVuIHJldHVybiB0aHVu
a3MgYXJlIGluIHVzZS4KCnN0dWJfc2VsZnRlc3QoKSBkb2Vzbid0IHN0cmlj
dGx5IG5lZWQgdG8gYmUgY29udmVydGVkIGFzIHRoZXkgb25seSBydW4gb24K
Ym9vdCwgYnV0IGRvaW5nIHNvIGdldHMgdXMgYSBwYXJ0aWFsIHRlc3Qgb2Yg
cGxhY2VfcmV0KCkgdG9vLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ2OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQt
b2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu
Y29tPgpSZXZpZXdlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvdG9vbHMvdGVzdHMveDg2X2Vt
dWxhdG9yL3g4Ni1lbXVsYXRlLmggYi90b29scy90ZXN0cy94ODZfZW11bGF0
b3IveDg2LWVtdWxhdGUuaAppbmRleCA5MjljMWE3MmFlODguLjRjMjkyYWMz
MzhmNiAxMDA2NDQKLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKKysrIGIvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKQEAgLTc3LDYgKzc3LDEyIEBACiAKICNkZWZpbmUgaXNf
Y2Fub25pY2FsX2FkZHJlc3MoeCkgKCgoaW50NjRfdCkoeCkgPj4gNDcpID09
ICgoaW50NjRfdCkoeCkgPj4gNjMpKQogCitzdGF0aWMgaW5saW5lIHZvaWQg
KnBsYWNlX3JldCh2b2lkICpwdHIpCit7CisgICAgKih1aW50OF90ICopcHRy
ID0gMHhjMzsKKyAgICByZXR1cm4gcHRyICsgMTsKK30KKwogZXh0ZXJuIHVp
bnQzMl90IG14Y3NyX21hc2s7CiBleHRlcm4gc3RydWN0IGNwdV9wb2xpY3kg
Y3B1X3BvbGljeTsKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L01ha2Vm
aWxlIGIveGVuL2FyY2gveDg2L01ha2VmaWxlCmluZGV4IGMyZjFkY2YzMDFk
Ni4uYzMyYWJhMDI5ZDQ0IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvTWFr
ZWZpbGUKKysrIGIveGVuL2FyY2gveDg2L01ha2VmaWxlCkBAIC0xMSw5ICsx
MSw3IEBAIG9iai0kKENPTkZJR19QVikgKz0gcHYvCiBvYmoteSArPSB4ODZf
NjQvCiBvYmoteSArPSB4ODZfZW11bGF0ZS8KIAotYWx0ZXJuYXRpdmUteSA6
PSBhbHRlcm5hdGl2ZS5pbml0Lm8KLWFsdGVybmF0aXZlLSQoQ09ORklHX0xJ
VkVQQVRDSCkgOj0KLW9iai1iaW4teSArPSAkKGFsdGVybmF0aXZlLXkpCitv
YmoteSArPSBhbHRlcm5hdGl2ZS5vCiBvYmoteSArPSBhcGljLm8KIG9iai15
ICs9IGJoYi10aHVuay5vCiBvYmoteSArPSBiaXRvcHMubwpAQCAtNDEsNyAr
MzksNyBAQCBvYmoteSArPSBoeXBlcmNhbGwubwogb2JqLXkgKz0gaTM4Ny5v
CiBvYmoteSArPSBpODI1OS5vCiBvYmoteSArPSBpb19hcGljLm8KLW9iai0k
KENPTkZJR19MSVZFUEFUQ0gpICs9IGFsdGVybmF0aXZlLm8gbGl2ZXBhdGNo
Lm8KK29iai0kKENPTkZJR19MSVZFUEFUQ0gpICs9IGxpdmVwYXRjaC5vCiBv
YmoteSArPSBtc2kubwogb2JqLXkgKz0gbXNyLm8KIG9iai0kKENPTkZJR19J
TkRJUkVDVF9USFVOSykgKz0gaW5kaXJlY3QtdGh1bmsubwpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94ODYv
YWx0ZXJuYXRpdmUuYwppbmRleCA0ZDFiYmU3MzEzZmQuLjA0NDliOWMxYjdl
NSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKKysr
IGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTEzNSw2ICsxMzUs
MjAgQEAgdm9pZCBpbml0X29yX2xpdmVwYXRjaCBhZGRfbm9wcyh2b2lkICpp
bnNucywgdW5zaWduZWQgaW50IGxlbikKICAgICB9CiB9CiAKKy8qCisgKiBQ
bGFjZSBhIHJldHVybiBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGluIHRoZSB3
cml0YWJsZSBhbGlhcyBvZiBhIHN0dWIuCisgKgorICogUmV0dXJucyB0aGUg
bmV4dCBwb3NpdGlvbiB0byB3cml0ZSBpbnRvIHRoZSBzdHViLgorICovCit2
b2lkICpwbGFjZV9yZXQodm9pZCAqcHRyKQoreworICAgIHVpbnQ4X3QgKnAg
PSBwdHI7CisKKyAgICAqcCsrID0gMHhjMzsKKworICAgIHJldHVybiBwOwor
fQorCiAvKgogICogdGV4dF9wb2tlIC0gVXBkYXRlIGluc3RydWN0aW9ucyBv
biBhIGxpdmUga2VybmVsIG9yIG5vbi1leGVjdXRlZCBjb2RlLgogICogQGFk
ZHI6IGFkZHJlc3MgdG8gbW9kaWZ5CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvZXh0YWJsZS5jIGIveGVuL2FyY2gveDg2L2V4dGFibGUuYwppbmRleCA3
MDVjZjllYjk0Y2EuLjE1NzJlZmE2OWEwMCAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2V4dGFibGUuYworKysgYi94ZW4vYXJjaC94ODYvZXh0YWJsZS5j
CkBAIC0xNTEsMjAgKzE1MSwyMCBAQCBzZWFyY2hfZXhjZXB0aW9uX3RhYmxl
KGNvbnN0IHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzLCB1bnNpZ25lZCBs
b25nICpzdHViX3JhKQogaW50IF9faW5pdCBjZl9jaGVjayBzdHViX3NlbGZ0
ZXN0KHZvaWQpCiB7CiAgICAgc3RhdGljIGNvbnN0IHN0cnVjdCB7Ci0gICAg
ICAgIHVpbnQ4X3Qgb3BjWzhdOworICAgICAgICB1aW50OF90IG9wY1s3XTsK
ICAgICAgICAgdWludDY0X3QgcmF4OwogICAgICAgICB1bmlvbiBzdHViX2V4
Y2VwdGlvbl90b2tlbiByZXM7CiAgICAgfSB0ZXN0c1tdIF9faW5pdGNvbnN0
ID0gewogI2RlZmluZSBlbmRicjY0IDB4ZjMsIDB4MGYsIDB4MWUsIDB4ZmEK
LSAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDBmLCAweGI5LCAweGMz
LCAweGMzIH0sIC8qIHVkMSAqLworICAgICAgICB7IC5vcGMgPSB7IGVuZGJy
NjQsIDB4MGYsIDB4YjksIDB4OTAgfSwgLyogdWQxICovCiAgICAgICAgICAg
LnJlcy5maWVsZHMudHJhcG5yID0gWDg2X0VYQ19VRCB9LAotICAgICAgICB7
IC5vcGMgPSB7IGVuZGJyNjQsIDB4OTAsIDB4MDIsIDB4MDAsIDB4YzMgfSwg
Lyogbm9wOyBhZGQgKCVyYXgpLCVhbCAqLworICAgICAgICB7IC5vcGMgPSB7
IGVuZGJyNjQsIDB4OTAsIDB4MDIsIDB4MDAgfSwgLyogbm9wOyBhZGQgKCVy
YXgpLCVhbCAqLwogICAgICAgICAgIC5yYXggPSAweDAxMjM0NTY3ODlhYmNk
ZWYsCiAgICAgICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0gWDg2X0VYQ19H
UCB9LAotICAgICAgICB7IC5vcGMgPSB7IGVuZGJyNjQsIDB4MDIsIDB4MDQs
IDB4MDQsIDB4YzMgfSwgLyogYWRkICglcnNwLCVyYXgpLCVhbCAqLworICAg
ICAgICB7IC5vcGMgPSB7IGVuZGJyNjQsIDB4MDIsIDB4MDQsIDB4MDQgfSwg
LyogYWRkICglcnNwLCVyYXgpLCVhbCAqLwogICAgICAgICAgIC5yYXggPSAw
eGZlZGNiYTk4NzY1NDMyMTBVTCwKICAgICAgICAgICAucmVzLmZpZWxkcy50
cmFwbnIgPSBYODZfRVhDX1NTIH0sCi0gICAgICAgIHsgLm9wYyA9IHsgZW5k
YnI2NCwgMHhjYywgMHhjMywgMHhjMywgMHhjMyB9LCAvKiBpbnQzICovCisg
ICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwgMHhjYywgMHg5MCwgMHg5MCB9
LCAvKiBpbnQzICovCiAgICAgICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0g
WDg2X0VYQ19CUCB9LAogI3VuZGVmIGVuZGJyNjQKICAgICB9OwpAQCAtMTgz
LDYgKzE4Myw3IEBAIGludCBfX2luaXQgY2ZfY2hlY2sgc3R1Yl9zZWxmdGVz
dCh2b2lkKQogCiAgICAgICAgIG1lbXNldChwdHIsIDB4Y2MsIFNUVUJfQlVG
X1NJWkUgLyAyKTsKICAgICAgICAgbWVtY3B5KHB0ciwgdGVzdHNbaV0ub3Bj
LCBBUlJBWV9TSVpFKHRlc3RzW2ldLm9wYykpOworICAgICAgICBwbGFjZV9y
ZXQocHRyICsgQVJSQVlfU0laRSh0ZXN0c1tpXS5vcGMpKTsKICAgICAgICAg
dW5tYXBfZG9tYWluX3BhZ2UocHRyKTsKIAogICAgICAgICBhc20gdm9sYXRp
bGUgKCAiSU5ESVJFQ1RfQ0FMTCAlW3N0Yl1cbiIKZGlmZiAtLWdpdCBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oIGIveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmgKaW5kZXggYjllYTQ5
YmQxYzNkLi5lMTdiZThkZGZkODIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCisrKyBiL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCkBAIC0zMyw2ICszMyw4IEBA
IHN0cnVjdCBfX3BhY2tlZCBhbHRfaW5zdHIgewogI2RlZmluZSBBTFRfUkVQ
TF9QVFIoYSkgICAgIF9fQUxUX1BUUihhLCByZXBsX29mZnNldCkKIAogZXh0
ZXJuIHZvaWQgYWRkX25vcHModm9pZCAqaW5zbnMsIHVuc2lnbmVkIGludCBs
ZW4pOwordm9pZCAqcGxhY2VfcmV0KHZvaWQgKnB0cik7CisKIC8qIFNpbWls
YXIgdG8gYWx0ZXJuYXRpdmVfaW5zdHJ1Y3Rpb25zIGV4Y2VwdCBpdCBjYW4g
YmUgcnVuIHdpdGggSVJRcyBlbmFibGVkLiAqLwogZXh0ZXJuIGludCBhcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsIHN0cnVj
dCBhbHRfaW5zdHIgKmVuZCk7CiBleHRlcm4gdm9pZCBhbHRlcm5hdGl2ZV9p
bnN0cnVjdGlvbnModm9pZCk7CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
cHYvZW11bC1wcml2LW9wLmMgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2
LW9wLmMKaW5kZXggNzAxNTBjMjcyMjc2Li5mZjVkMWM5Zjg2MzQgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXByaXYtb3AuYworKysgYi94
ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMKQEAgLTc2LDcgKzc2LDYg
QEAgc3RhdGljIGlvX2VtdWxfc3R1Yl90ICppb19lbXVsX3N0dWJfc2V0dXAo
c3RydWN0IHByaXZfb3BfY3R4dCAqY3R4dCwgdTggb3Bjb2RlLAogICAgICAg
ICAweDQxLCAweDVjLCAvKiBwb3AgJXIxMiAgKi8KICAgICAgICAgMHg1ZCwg
ICAgICAgLyogcG9wICVyYnAgICovCiAgICAgICAgIDB4NWIsICAgICAgIC8q
IHBvcCAlcmJ4ICAqLwotICAgICAgICAweGMzLCAgICAgICAvKiByZXQgICAg
ICAgKi8KICAgICB9OwogCiAgICAgY29uc3Qgc3RydWN0IHN0dWJzICp0aGlz
X3N0dWJzID0gJnRoaXNfY3B1KHN0dWJzKTsKQEAgLTEyNiwxMSArMTI1LDEz
IEBAIHN0YXRpYyBpb19lbXVsX3N0dWJfdCAqaW9fZW11bF9zdHViX3NldHVw
KHN0cnVjdCBwcml2X29wX2N0eHQgKmN0eHQsIHU4IG9wY29kZSwKIAogICAg
IEFQUEVORF9DQUxMKHNhdmVfZ3Vlc3RfZ3Bycyk7CiAgICAgQVBQRU5EX0JV
RkYoZXBpbG9ndWUpOworICAgIHAgPSBwbGFjZV9yZXQocCk7CiAKICAgICAv
KiBCdWlsZC10aW1lIGJlc3QgZWZmb3J0IGF0dGVtcHQgdG8gY2F0Y2ggcHJv
YmxlbXMuICovCiAgICAgQlVJTERfQlVHX09OKFNUVUJfQlVGX1NJWkUgLyAy
IDwKICAgICAgICAgICAgICAgICAgKHNpemVvZihwcm9sb2d1ZSkgKyBzaXpl
b2YoZXBpbG9ndWUpICsgMTAgLyogMnggY2FsbCAqLyArCi0gICAgICAgICAg
ICAgICAgICBNQVgoMyAvKiBkZWZhdWx0IHN0dWIgKi8sIElPRU1VTF9RVUlS
S19TVFVCX0JZVEVTKSkpOworICAgICAgICAgICAgICAgICAgTUFYKDMgLyog
ZGVmYXVsdCBzdHViICovLCBJT0VNVUxfUVVJUktfU1RVQl9CWVRFUykgKwor
ICAgICAgICAgICAgICAgICAgMSAvKiByZXQgKi8pKTsKICAgICAvKiBSdW50
aW1lIGNvbmZpcm1hdGlvbiB0aGF0IHdlIGhhdmVuJ3QgY2xvYmJlcmVkIGFu
IGFkamFjZW50IHN0dWIuICovCiAgICAgQlVHX09OKFNUVUJfQlVGX1NJWkUg
LyAyIDwgKHAgLSBjdHh0LT5pb19lbXVsX3N0dWIpKTsKIApkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL2ZwdS5jIGIveGVuL2FyY2gv
eDg2L3g4Nl9lbXVsYXRlL2ZwdS5jCmluZGV4IDU0Yzg2MjE0MjFjNi4uOWNj
MzdhMWQ4ZTNjIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYveDg2X2VtdWxh
dGUvZnB1LmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL2ZwdS5j
CkBAIC0zMiwzNiArMzIsNDIgQEAgc3RhdGljIGlubGluZSBib29sIGZwdV9j
aGVja193cml0ZSh2b2lkKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25f
bWVtZHN0KG9wYywgZXh0LCBhcmcpICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAq
X3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgLyogTW9kUk06IG1vZD0wLCByZWc9
ZXh0LCBybT0wLCBpLmUuIGEgKCVyYXgpIG9wZXJhbmQgKi8gICAgICAgICAg
ICBcCiAgICAgKmluc25fYnl0ZXMgPSAyOyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWludDhfdFtdKXsg
b3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsgICAgICAgICAg
ICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9wYywgKChleHQp
ICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisgICAgcGxhY2Vf
cmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAi
K20iIChhcmcpIDogImEiICgmKGFyZykpKTsgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9IHdoaWxlICgw
KQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fbWVtc3JjKG9wYywgZXh0
LCBhcmcpICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBkbyB7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBnZXRfc3R1Yihz
dHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgLyogTW9kUk06IG1vZD0wLCByZWc9ZXh0LCBybT0wLCBpLmUu
IGEgKCVyYXgpIG9wZXJhbmQgKi8gICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWludDhfdFtdKXsg
b3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsgICAgICAgICAg
ICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9wYywgKChleHQp
ICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisgICAgcGxhY2Vf
cmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAi
PW0iIChkdW1teSkgOiAibSIgKGFyZyksICJhIiAoJihhcmcpKSk7ICAgICAg
ICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9IHdoaWxlICgw
KQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fc3R1YihieXRlcy4uLikg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBkbyB7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBnZXRfc3R1Yihz
dHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgdW5zaWduZWQgaW50IG5yXyA9IHNpemVvZigodWludDhfdFtd
KXsgYnl0ZXMgfSk7ICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVzLCAweGMzIH0p
LCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3Rb
XSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAgICAgICAgICAg
ICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tl
X3N0dWIoIiIsICIiLCAiPW0iIChkdW1teSkgOiAiaSIgKDApKTsgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiB9IHdoaWxlICgwKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25f
c3R1Yl9lZmxhZ3MoYnl0ZXMuLi4pICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAq
X3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgdW5zaWduZWQgaW50IG5yXyA9IHNp
emVvZigodWludDhfdFtdKXsgYnl0ZXMgfSk7ICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgdW5zaWduZWQgbG9uZyB0bXBfOyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVzLCAweGMzIH0p
LCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3Rb
XSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAgICAgICAgICAg
ICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tl
X3N0dWIoX1BSRV9FRkxBR1MoIltlZmxhZ3NdIiwgIlttYXNrXSIsICJbdG1w
XSIpLCAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgX1BPU1RfRUZM
QUdTKCJbZWZsYWdzXSIsICJbbWFza10iLCAiW3RtcF0iKSwgICAgICAgICAg
ICBcCiAgICAgICAgICAgICAgICAgW2VmbGFnc10gIitnIiAocmVncy0+ZWZs
YWdzKSwgW3RtcF0gIj0mciIgKHRtcF8pICAgICAgICBcCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYyBiL3hl
bi9hcmNoL3g4Ni94ODZfZW11bGF0ZS94ODZfZW11bGF0ZS5jCmluZGV4IDdk
NjhlYmU3ZWEwNS4uMGE5OGI0MzQ3NjMxIDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYworKysgYi94ZW4vYXJj
aC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYwpAQCAtMTQwMCw3ICsx
NDAwLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHN0YlszXSA9IDB4OTE7
CiAgICAgICAgIHN0Yls0XSA9IGV2ZXgub3Btc2sgPDwgMzsKICAgICAgICAg
aW5zbl9ieXRlcyA9IDU7Ci0gICAgICAgIHN0Yls1XSA9IDB4YzM7CisgICAg
ICAgIHBsYWNlX3JldCgmc3RiWzVdKTsKIAogICAgICAgICBpbnZva2Vfc3R1
YigiIiwgIiIsICIrbSIgKG9wX21hc2spIDogImEiICgmb3BfbWFzaykpOwog
CkBAIC0zNjMzLDcgKzM2MzMsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAg
fQogICAgICAgICBvcGNbMV0gPSAobW9kcm0gJiAweDM4KSB8IDB4YzA7CiAg
ICAgICAgIGluc25fYnl0ZXMgPSBFVkVYX1BGWF9CWVRFUyArIDI7Ci0gICAg
ICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJd
KTsKIAogICAgICAgICBjb3B5X0VWRVgob3BjLCBldmV4KTsKICAgICAgICAg
aW52b2tlX3N0dWIoIiIsICIiLCAiPWciIChkdW1teSkgOiAiYSIgKHNyYy52
YWwpKTsKQEAgLTM3MDAsNyArMzcwMCw3IEBAIHg4Nl9lbXVsYXRlKAogICAg
ICAgICAgICAgaW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDI7CiAgICAgICAg
ICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2ZXgpOwogICAg
ICAgICB9Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNl
X3JldCgmb3BjWzJdKTsKIAogICAgICAgICBlYS5yZWcgPSBkZWNvZGVfZ3By
KCZfcmVncywgbW9kcm1fcmVnKTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIs
ICIiLCAiPWEiICgqZWEucmVnKSA6ICJjIiAobW12YWxwKSwgIm0iICgqbW12
YWxwKSk7CkBAIC0zNzc0LDcgKzM3NzQsNyBAQCB4ODZfZW11bGF0ZSgKICAg
ICAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwogICAgICAg
ICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3ByZWZpeCwgdmV4KTsKICAg
ICAgICAgfQotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFj
ZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgX3JlZ3MuZWZsYWdzICY9IH5F
RkxBR1NfTUFTSzsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsCkBAIC00MDEw
LDcgKzQwMTAsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgb3BjWzFdID0g
bW9kcm0gJiAweGM3OwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVT
ICsgMjsKICAgICBzaW1kXzBmX3RvX2dwcjoKLSAgICAgICAgb3BjW2luc25f
Ynl0ZXMgLSBQRlhfQllURVNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0
KCZvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10pOwogCiAgICAgICAgIGdl
bmVyYXRlX2V4Y2VwdGlvbl9pZihlYS50eXBlICE9IE9QX1JFRywgWDg2X0VY
Q19VRCk7CiAKQEAgLTQ0MDcsNyArNDQwNyw3IEBAIHg4Nl9lbXVsYXRlKAog
ICAgICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2Ry
bSAmIDB4Mzg7CiAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAy
OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQo
Jm9wY1syXSk7CiAKICAgICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3By
ZWZpeCwgdmV4KTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiK20i
IChzcmMudmFsKSA6ICJhIiAoJnNyYy52YWwpKTsKQEAgLTQ0NDQsNyArNDQ0
NCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAgZXZleC53ID0gMDsK
ICAgICAgICAgb3BjWzFdID0gbW9kcm0gJiAweDM4OwogICAgICAgICBpbnNu
X2J5dGVzID0gRVZFWF9QRlhfQllURVMgKyAyOwotICAgICAgICBvcGNbMl0g
PSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAg
ICAgY29weV9FVkVYKG9wYywgZXZleCk7CiAgICAgICAgIGludm9rZV9zdHVi
KCIiLCAiIiwgIittIiAoc3JjLnZhbCkgOiAiYSIgKCZzcmMudmFsKSk7CkBA
IC00NjM5LDcgKzQ2MzksNyBAQCB4ODZfZW11bGF0ZSgKICNlbmRpZiAvKiBY
ODZFTVVMX05PX1NJTUQgKi8KIAogICAgIHNpbWRfMGZfcmVnX29ubHk6Ci0g
ICAgICAgIG9wY1tpbnNuX2J5dGVzIC0gUEZYX0JZVEVTXSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjW2luc25fYnl0ZXMgLSBQRlhfQllURVNd
KTsKIAogICAgICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2
ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsIFtkdW1teV9vdXRd
ICI9ZyIgKGR1bW15KSA6IFtkdW1teV9pbl0gImkiICgwKSApOwpAQCAtNDk3
Myw3ICs0OTczLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIGlmICggIW1v
ZGVfNjRiaXQoKSApCiAgICAgICAgICAgICB2ZXgudyA9IDA7CiAgICAgICAg
IG9wY1sxXSA9IG1vZHJtICYgMHhmODsKLSAgICAgICAgb3BjWzJdID0gMHhj
MzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNv
cHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAgZWEucmVnID0gZGVjb2RlX2dw
cigmX3JlZ3MsIG1vZHJtX3JtKTsKQEAgLTUwMTYsNyArNTAxNiw3IEBAIHg4
Nl9lbXVsYXRlKAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0KCkgKQogICAg
ICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2RybSAm
IDB4Yzc7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNl
X3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X1ZFWChvcGMsIHZleCk7
CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1hIiAoZHN0LnZhbCkg
OiBbZHVtbXldICJpIiAoMCkpOwpAQCAtNTA0Niw3ICs1MDQ2LDcgQEAgeDg2
X2VtdWxhdGUoCiAgICAgICAgIG9wYyA9IGluaXRfcHJlZml4ZXMoc3R1Yik7
CiAgICAgICAgIG9wY1swXSA9IGI7CiAgICAgICAgIG9wY1sxXSA9IG1vZHJt
OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQo
Jm9wY1syXSk7CiAKICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAg
ICAgICBfcmVncy5lZmxhZ3MgJj0gfkVGTEFHU19NQVNLOwpAQCAtNTYxNCw3
ICs1NjE0LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIGlmICggIW1vZGVf
NjRiaXQoKSApCiAgICAgICAgICAgICB2ZXgudyA9IDA7CiAgICAgICAgIG9w
Y1sxXSA9IG1vZHJtICYgMHhjNzsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
UkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIGludm9r
ZV9zdHViKCIiLCAiIiwgIj1hIiAoZWEudmFsKSA6IFtkdW1teV0gImkiICgw
KSk7CkBAIC01NzMyLDcgKzU3MzIsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAg
ICAgICAgIG9wY1sxXSAmPSAweDM4OwogICAgICAgICB9CiAgICAgICAgIGlu
c25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwotICAgICAgICBvcGNbMl0gPSAw
eGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAgICAgICAgIGlm
ICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQogICAgICAgICB7CiAgICAgICAg
ICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJlZml4IGJ5dGUuICovCkBAIC02
MDEyLDcgKzYwMTIsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+
YiA9ICFtb2RlXzY0Yml0KCkgfHwgKHZleC5yZWcgPj4gMyk7CiAgICAgICAg
IG9wY1sxXSA9IDB4YzAgfCAofnZleC5yZWcgJiA3KTsKICAgICAgICAgcHZl
eC0+cmVnID0gMHhmOwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAg
ICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIo
IiIsICIiLCAiPWEiIChlYS52YWwpIDogW2R1bW15XSAiaSIgKDApKTsKICAg
ICAgICAgcHV0X3N0dWIoc3R1Yik7CkBAIC02Mjg2LDcgKzYyODYsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgICAgIGV2ZXgudyA9IDA7CiAgICAgICAg
IG9wY1sxXSA9IG1vZHJtICYgMHhmODsKICAgICAgICAgaW5zbl9ieXRlcyA9
IEVWRVhfUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
RVZFWChvcGMsIGV2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIs
ICI9ZyIgKGR1bW15KSA6ICJhIiAoc3JjLnZhbCkpOwpAQCAtNjM4NSw3ICs2
Mzg1LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHB2ZXgtPmIgPSAxOwog
ICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAgICAg
ICAgcHZleC0+cmVnID0gMHhmOwotICAgICAgICBvcGNbMl0gPSAweGMzOwor
ICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgaW52b2tl
X3N0dWIoIiIsICIiLCAiPW0iICgqbW12YWxwKSA6ICJhIiAobW12YWxwKSk7
CiAKQEAgLTY0NTUsNyArNjQ1NSw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAg
ICBwdmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJtX3JlZyAm
IDcpIDw8IDM7CiAgICAgICAgIHB2ZXgtPnJlZyA9IDB4ZjsKLSAgICAgICAg
b3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwog
CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAoKm1tdmFscCkg
OiAiYSIgKG1tdmFscCkpOwogCkBAIC02NTExLDcgKzY1MTEsNyBAQCB4ODZf
ZW11bGF0ZSgKICAgICAgICAgcGV2ZXgtPmIgPSAxOwogICAgICAgICBvcGNb
MV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAgICAgICAgcGV2ZXgtPlJY
ID0gMTsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2Vf
cmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwg
Ij1tIiAoKm1tdmFscCkgOiAiYSIgKG1tdmFscCkpOwogCkBAIC02NTc2LDcg
KzY1NzYsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcGV2ZXgtPmIgPSAx
OwogICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAg
ICAgICAgcGV2ZXgtPlJYID0gMTsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9r
ZV9zdHViKCIiLCAiIiwgIittIiAoKm1tdmFscCkgOiAiYSIgKG1tdmFscCkp
OwogCkBAIC02NTkwLDcgKzY1OTAsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAg
ICAgb3BjWzJdID0gMHg5MDsKICAgICAgICAgLyogVXNlICglcmF4KSBhcyBz
b3VyY2UuICovCiAgICAgICAgIG9wY1szXSA9IGV2ZXgub3Btc2sgPDwgMzsK
LSAgICAgICAgb3BjWzRdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbNF0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAo
b3BfbWFzaykgOiAiYSIgKCZvcF9tYXNrKSk7CiAgICAgICAgIHB1dF9zdHVi
KHN0dWIpOwpAQCAtNjY2Niw3ICs2NjY2LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIHBldmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJt
X3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0gICAg
ICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJd
KTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKCptbXZh
bHApIDogImEiIChtbXZhbHApKTsKIApAQCAtNjc0Myw3ICs2NzQzLDcgQEAg
eDg2X2VtdWxhdGUoCiAgICAgICAgIG9wY1syXSA9IDB4OTA7CiAgICAgICAg
IC8qIFVzZSAoJXJheCkgYXMgc291cmNlLiAqLwogICAgICAgICBvcGNbM10g
PSBldmV4Lm9wbXNrIDw8IDM7Ci0gICAgICAgIG9wY1s0XSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjWzRdKTsKIAogICAgICAgICBpbnZva2Vf
c3R1YigiIiwgIiIsICIrbSIgKG9wX21hc2spIDogImEiICgmb3BfbWFzaykp
OwogICAgICAgICBwdXRfc3R1YihzdHViKTsKQEAgLTY5NDEsNyArNjk0MSw3
IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBwdmV4LT5yZWcgPSAweGY7IC8q
IHJBWCAqLwogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZbNF0g
PSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVm
WzVdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAg
ICAgICAgIHNyYy5yZWcgPSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3Jl
Z3MsIGN0eHQpOwogICAgICAgICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0mYyIg
KGRzdC52YWwpLCAiW2RzdF0iICgmc3JjLnZhbCksICJhIiAoKnNyYy5yZWcp
KTsKQEAgLTY5NzcsNyArNjk3Nyw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAg
ICBwdmV4LT5yZWcgPSAweGY7IC8qIHJBWCAqLwogICAgICAgICBidWZbM10g
PSBiOwogICAgICAgICBidWZbNF0gPSAobW9kcm0gJiAweDM4KSB8IDB4MDE7
IC8qIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgIGRzdC5yZWcg
PSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3JlZ3MsIGN0eHQpOwogICAg
ICAgICBlbXVsYXRlX3N0dWIoIj0mYSIgKGRzdC52YWwpLCAiYyIgKCZzcmMu
dmFsKSk7CkBAIC03MjE4LDcgKzcyMTgsNyBAQCB4ODZfZW11bGF0ZSgKICAg
ICAgICAgICAgIGV2ZXgudyA9IHZleC53ID0gMDsKICAgICAgICAgb3BjWzFd
ID0gbW9kcm0gJiAweDM4OwogICAgICAgICBvcGNbMl0gPSBpbW0xOwotICAg
ICAgICBvcGNbM10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1sz
XSk7CiAgICAgICAgIGlmICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQogICAg
ICAgICB7CiAgICAgICAgICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJlZml4
IGJ5dGUuICovCkBAIC03Mzg1LDcgKzczODUsNyBAQCB4ODZfZW11bGF0ZSgK
ICAgICAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAzOwogICAg
ICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAgICAgICB9Ci0gICAg
ICAgIG9wY1szXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzNd
KTsKIAogICAgICAgICAvKiBMYXRjaCBNWENTUiAtIHdlIG1heSBuZWVkIHRv
IHJlc3RvcmUgaXQgYmVsb3cuICovCiAgICAgICAgIGludm9rZV9zdHViKCJz
dG14Y3NyICVbbXhjc3JdIiwgIiIsCkBAIC03NjMxLDcgKzc2MzEsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgfQogICAgICAgICBvcGNbMl0gPSBpbW0x
OwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMzsKLSAgICAg
ICAgb3BjWzNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbM10p
OwogICAgICAgICBpZiAoIHZleC5vcGN4ID09IHZleF9ub25lICkKICAgICAg
ICAgewogICAgICAgICAgICAgLyogQ292ZXIgZm9yIGV4dHJhIHByZWZpeCBi
eXRlLiAqLwpAQCAtNzk3Nyw3ICs3OTc3LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIHB4b3AtPnJlZyA9IDB4ZjsgLyogckFYICovCiAgICAgICAgIGJ1
ZlszXSA9IGI7CiAgICAgICAgIGJ1Zls0XSA9IChtb2RybSAmIDB4MzgpIHwg
MHgwMTsgLyogci9tPSglckNYKSAqLwotICAgICAgICBidWZbNV0gPSAweGMz
OworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls1XSk7CiAKICAgICAgICAgZHN0
LnJlZyA9IGRlY29kZV92ZXhfZ3ByKHZleC5yZWcsICZfcmVncywgY3R4dCk7
CiAgICAgICAgIGVtdWxhdGVfc3R1YihbZHN0XSAiPSZhIiAoZHN0LnZhbCks
ICJjIiAoJnNyYy52YWwpKTsKQEAgLTgwODYsNyArODA4Niw3IEBAIHg4Nl9l
bXVsYXRlKAogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZbNF0g
PSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KICAgICAgICAgKih1
aW50MzJfdCAqKShidWYgKyA1KSA9IGltbTE7Ci0gICAgICAgIGJ1Zls5XSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzldKTsKIAogICAgICAg
ICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0mYyIgKGRzdC52YWwpLCAiW2RzdF0i
ICgmc3JjLnZhbCkpOwogCkBAIC04MTgyLDEyICs4MTgyLDEyIEBAIHg4Nl9l
bXVsYXRlKAogCiAgICAgICAgIGlmICggZXZleF9lbmNvZGVkKCkgKQogICAg
ICAgICB7Ci0gICAgICAgICAgICBvcGNbaW5zbl9ieXRlcyAtIEVWRVhfUEZY
X0JZVEVTXSA9IDB4YzM7CisgICAgICAgICAgICBwbGFjZV9yZXQoJm9wY1tp
bnNuX2J5dGVzIC0gRVZFWF9QRlhfQllURVNdKTsKICAgICAgICAgICAgIGNv
cHlfRVZFWChvcGMsIGV2ZXgpOwogICAgICAgICB9CiAgICAgICAgIGVsc2UK
ICAgICAgICAgewotICAgICAgICAgICAgb3BjW2luc25fYnl0ZXMgLSBQRlhf
QllURVNdID0gMHhjMzsKKyAgICAgICAgICAgIHBsYWNlX3JldCgmb3BjW2lu
c25fYnl0ZXMgLSBQRlhfQllURVNdKTsKICAgICAgICAgICAgIGNvcHlfUkVY
X1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIH0KIApAQCAt
ODUxMSw3ICs4NTExLDcgQEAgaW50IHg4Nl9lbXVsX3JtdygKICAgICAgICAg
cHZleC0+cmVnID0gMHhmOyAvKiByQVggKi8KICAgICAgICAgYnVmWzNdID0g
Y3R4dC0+b3Bjb2RlOwogICAgICAgICBidWZbNF0gPSAweDExOyAvKiByZWc9
ckRYIHIvbT0oJVJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgICplZmxhZ3Mg
Jj0gfkVGTEFHU19NQVNLOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-06.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-06.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IEJ1aWxkIFhlbiB3aXRoIFJldHVybiBUaHVua3MKClRo
ZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uIHNwZWN1bGF0aXZlIHZ1bG5l
cmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRpcmVjdApicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QgaGFsZiBv
ZiBhIGNhY2hlbGluZS4KCkluIG9yZGVyIHRvIG1pdGlnYXRlIHRoaXMsIGJ1
aWxkIHdpdGggcmV0dXJuIHRodW5rcyBhbmQgYXJyYW5nZSBmb3IKX194ODZf
cmV0dXJuX3RodW5rIHRvIGJlIChtaXMpYWxpZ25lZCBpbiB0aGUgc2FtZSBt
YW5uZXIgYXMKX194ODZfaW5kaXJlY3RfdGh1bmtfKiBzbyB0aGUgUkVUIGlu
c3RydWN0aW9uIGlzIHBsYWNlZCBpbiBhIHNhZmUgbG9jYXRpb24uCgpwbGFj
ZV9yZXQoKSBuZWVkcyB0byBjb25kaXRpb25hbGx5IGVtaXQgSk1QIF9feDg2
X3JldHVybl90aHVuayBpbnN0ZWFkIG9mIFJFVC4KClRoaXMgaXMgcGFydCBv
ZiBYU0EtNDY5IC8gQ1ZFLTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnIGIveGVu
L2FyY2gveDg2L0tjb25maWcKaW5kZXggZGUyZmEzN2YwODhkLi43YWZlODc5
NzEwYmUgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnCisrKyBi
L3hlbi9hcmNoL3g4Ni9LY29uZmlnCkBAIC0zOSw5ICszOSwxNCBAQCBjb25m
aWcgQVJDSF9ERUZDT05GSUcKIAlkZWZhdWx0ICJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCiAKIGNvbmZpZyBDQ19IQVNfSU5ESVJFQ1Rf
VEhVTksKKwkjIEdDQyA+PSA4IG9yIENsYW5nID49IDYKIAlkZWZfYm9vbCAk
KGNjLW9wdGlvbiwtbWluZGlyZWN0LWJyYW5jaC1yZWdpc3RlcikgfHwgXAog
CSAgICAgICAgICQoY2Mtb3B0aW9uLC1tcmV0cG9saW5lLWV4dGVybmFsLXRo
dW5rKQogCitjb25maWcgQ0NfSEFTX1JFVFVSTl9USFVOSworCSMgR0NDID49
IDggb3IgQ2xhbmcgPj0gMTUKKwlkZWZfYm9vbCAkKGNjLW9wdGlvbiwtbWZ1
bmN0aW9uLXJldHVybj10aHVuay1leHRlcm4pCisKIGNvbmZpZyBIQVNfQVNf
Q0VUX1NTCiAJIyBiaW51dGlscyA+PSAyLjI5IG9yIExMVk0gPj0gNgogCWRl
Zl9ib29sICQoYXMtaW5zdHIsd3Jzc3EgJXJheCQoY29tbWEpMDtzZXRzc2Jz
eSkKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hlbi9h
cmNoL3g4Ni9NYWtlZmlsZQppbmRleCBjMzJhYmEwMjlkNDQuLmJlZGI5N2Ni
ZWVkOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisrKyBi
L3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtNDMsNiArNDMsNyBAQCBvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KK29iai0kKENPTkZJR19SRVRV
Uk5fVEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KIG9iai0kKENPTkZJR19Q
VikgKz0gaW9wb3J0X2VtdWxhdGUubwogb2JqLXkgKz0gaXJxLm8KIG9iai0k
KENPTkZJR19LRVhFQykgKz0gbWFjaGluZV9rZXhlYy5vCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJvdC5TIGIveGVuL2FyY2gv
eDg2L2FjcGkvd2FrZXVwX3Byb3QuUwppbmRleCBhNzQxZDU4YjkxMTcuLjky
YWY2MjMwYjMxZiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvd2Fr
ZXVwX3Byb3QuUworKysgYi94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJv
dC5TCkBAIC0xMzMsNyArMTMzLDcgQEAgTEFCRUwoczNfcmVzdW1lKQogICAg
ICAgICBwb3AgICAgICVyMTIKICAgICAgICAgcG9wICAgICAlcmJ4CiAgICAg
ICAgIHBvcCAgICAgJXJicAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBF
TkQoZG9fc3VzcGVuZF9sb3dsZXZlbCkKIAogLmRhdGEKZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jIGIveGVuL2FyY2gveDg2L2Fs
dGVybmF0aXZlLmMKaW5kZXggMDQ0OWI5YzFiN2U1Li5lY2M1Njk2NGJkOWMg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCisrKyBi
L3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCkBAIC0xMzUsMTYgKzEzNSw0
NSBAQCB2b2lkIGluaXRfb3JfbGl2ZXBhdGNoIGFkZF9ub3BzKHZvaWQgKmlu
c25zLCB1bnNpZ25lZCBpbnQgbGVuKQogICAgIH0KIH0KIAordm9pZCBub2Nh
bGwgX194ODZfcmV0dXJuX3RodW5rKHZvaWQpOworCiAvKgogICogUGxhY2Ug
YSByZXR1cm4gYXQgQHB0ci4gIEBwdHIgbXVzdCBiZSBpbiB0aGUgd3JpdGFi
bGUgYWxpYXMgb2YgYSBzdHViLgogICoKKyAqIFdoZW4gQ09ORklHX1JFVFVS
Tl9USFVOSyBpcyBhY3RpdmUsIHRoaXMgbWF5IGJlIGEgSk1QIF9feDg2X3Jl
dHVybl90aHVuaworICogaW5zdGVhZCwgZGVwZW5kaW5nIG9uIHRoZSBzYWZl
dHkgb2YgQHB0ciB3aXRoIHJlc3BlY3QgdG8gSW5kaXJlY3QgVGFyZ2V0Cisg
KiBTZWxlY3Rpb24uCisgKgogICogUmV0dXJucyB0aGUgbmV4dCBwb3NpdGlv
biB0byB3cml0ZSBpbnRvIHRoZSBzdHViLgogICovCiB2b2lkICpwbGFjZV9y
ZXQodm9pZCAqcHRyKQogeworICAgIHVuc2lnbmVkIGxvbmcgYWRkciA9ICh1
bnNpZ25lZCBsb25nKXB0cjsKICAgICB1aW50OF90ICpwID0gcHRyOwogCi0g
ICAgKnArKyA9IDB4YzM7CisgICAgLyoKKyAgICAgKiBXaGVuIFJldHVybiBU
aHVua3MgYXJlIHVzZWQsIGlmIGEgUkVUIHdvdWxkIGJlIHVuc2FmZSBhdCB0
aGlzIGxvY2F0aW9uCisgICAgICogd2l0aCByZXNwZWN0IHRvIEluZGlyZWN0
IFRhcmdldCBTZWxlY3Rpb24gKGkuZS4gaWYgYWRkciBpcyBpbiB0aGUgZmly
c3QKKyAgICAgKiBoYWxmIG9mIGEgY2FjaGVsaW5lKSwgaW5zZXJ0IGEgSk1Q
IF9feDg2X3JldHVybl90aHVuayBpbnN0ZWFkLgorICAgICAqCisgICAgICog
VGhlIGRpc3BsYWNlbWVudCBuZWVkcyB0byBiZSByZWxhdGl2ZSB0byB0aGUg
ZXhlY3V0YWJsZSBhbGlhcyBvZiB0aGUKKyAgICAgKiBzdHViLCBub3QgdG8g
QHB0ciB3aGljaCBpcyB0aGUgd3JpdGVhYmxlIGFsaWFzLgorICAgICAqLwor
ICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfUkVUVVJOX1RIVU5LKSAmJiAh
KGFkZHIgJiAweDIwKSApCisgICAgeworICAgICAgICBsb25nIHN0dWJfdmEg
PSAodGhpc19jcHUoc3R1YnMuYWRkcikgJiBQQUdFX01BU0spICsgKGFkZHIg
JiB+UEFHRV9NQVNLKTsKKyAgICAgICAgbG9uZyBkaXNwID0gKGxvbmcpX194
ODZfcmV0dXJuX3RodW5rIC0gKHN0dWJfdmEgKyA1KTsKKworICAgICAgICBC
VUdfT04oKGludDMyX3QpZGlzcCAhPSBkaXNwKTsKKworICAgICAgICAqcCsr
ID0gMHhlOTsKKyAgICAgICAgKihpbnQzMl90ICopcCA9IGRpc3A7CisgICAg
ICAgIHAgKz0gNDsKKyAgICB9CisgICAgZWxzZQorICAgIHsKKyAgICAgICAg
KnArKyA9IDB4YzM7CisgICAgfQogCiAgICAgcmV0dXJuIHA7CiB9CmRpZmYg
LS1naXQgYS94ZW4vYXJjaC94ODYvYXJjaC5tayBiL3hlbi9hcmNoL3g4Ni9h
cmNoLm1rCmluZGV4IDA5YjZkODc1OGU5NS4uNDk5MTU0NTEyNTlmIDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYvYXJjaC5taworKysgYi94ZW4vYXJjaC94
ODYvYXJjaC5tawpAQCAtMzQsNiArMzQsOSBAQCBDRkxBR1MtJChDT05GSUdf
Q0NfSVNfR0NDKSArPSAtZm5vLWp1bXAtdGFibGVzCiBDRkxBR1MtJChDT05G
SUdfQ0NfSVNfQ0xBTkcpICs9IC1tcmV0cG9saW5lLWV4dGVybmFsLXRodW5r
CiBlbmRpZgogCisjIENvbXBpbGUgd2l0aCByZXR1cm4gdGh1bmsgc3VwcG9y
dCBpZiBzZWxlY3RlZC4KK0NGTEFHUy0kKENPTkZJR19SRVRVUk5fVEhVTksp
ICs9IC1tZnVuY3Rpb24tcmV0dXJuPXRodW5rLWV4dGVybgorCiAjIERpc2Fi
bGUgdGhlIGFkZGl0aW9uIG9mIGEgLm5vdGUuZ251LnByb3BlcnR5IHNlY3Rp
b24gdG8gb2JqZWN0IGZpbGVzIHdoZW4KICMgbGl2ZXBhdGNoIHN1cHBvcnQg
aXMgZW5hYmxlZC4gIFRoZSBjb250ZW50cyBvZiB0aGF0IHNlY3Rpb24gY2Fu
IGNoYW5nZQogIyBkZXBlbmRpbmcgb24gdGhlIGluc3RydWN0aW9ucyB1c2Vk
LCBhbmQgbGl2ZXBhdGNoLWJ1aWxkLXRvb2xzIGRvZXNuJ3Qga25vdwpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2JoYi10aHVuay5TIGIveGVuL2FyY2gv
eDg2L2JoYi10aHVuay5TCmluZGV4IDcxNzU3NzhiZGQxMS4uNjA2YjM3OGQ4
NGNmIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvYmhiLXRodW5rLlMKKysr
IGIveGVuL2FyY2gveDg2L2JoYi10aHVuay5TCkBAIC0yMyw3ICsyMyw3IEBA
IEZVTkMoY2xlYXJfYmhiX3RzeCkKICAgICAgICAgeGFib3J0ICAkMAogICAg
ICAgICBpbnQzCiAxOgotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQo
Y2xlYXJfYmhiX3RzeCkKIAogLyoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4
Ni9jbGVhcl9wYWdlLlMgYi94ZW4vYXJjaC94ODYvY2xlYXJfcGFnZS5TCmlu
ZGV4IGQ2YzA3NmYxZDhiYy4uZGMzYzNjMjZiZmI3IDEwMDY0NAotLS0gYS94
ZW4vYXJjaC94ODYvY2xlYXJfcGFnZS5TCisrKyBiL3hlbi9hcmNoL3g4Ni9j
bGVhcl9wYWdlLlMKQEAgLTEsNiArMSw4IEBACiAgICAgICAgIC5maWxlIF9f
RklMRV9fCiAKICNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPgorCisjaW5jbHVk
ZSA8YXNtL2FzbV9kZWZucy5oPgogI2luY2x1ZGUgPGFzbS9wYWdlLmg+CiAK
IEZVTkMoY2xlYXJfcGFnZV9zc2UyKQpAQCAtMTYsNSArMTgsNSBAQCBGVU5D
KGNsZWFyX3BhZ2Vfc3NlMikKICAgICAgICAgam56ICAgICAwYgogCiAgICAg
ICAgIHNmZW5jZQotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQoY2xl
YXJfcGFnZV9zc2UyKQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2NvcHlf
cGFnZS5TIGIveGVuL2FyY2gveDg2L2NvcHlfcGFnZS5TCmluZGV4IGMzYzQz
NjU0NWJhYy4uZTQzZTUzNzBjODE1IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94
ODYvY29weV9wYWdlLlMKKysrIGIveGVuL2FyY2gveDg2L2NvcHlfcGFnZS5T
CkBAIC0xLDYgKzEsOCBAQAogICAgICAgICAuZmlsZSBfX0ZJTEVfXwogCiAj
aW5jbHVkZSA8eGVuL2xpbmthZ2UuaD4KKworI2luY2x1ZGUgPGFzbS9hc21f
ZGVmbnMuaD4KICNpbmNsdWRlIDxhc20vcGFnZS5oPgogCiAjZGVmaW5lIHNy
Y19yZWcgJXJzaQpAQCAtNDEsNSArNDMsNSBAQCBGVU5DKGNvcHlfcGFnZV9z
c2UyKQogICAgICAgICBtb3ZudGkgIHRtcDRfcmVnLCAzKldPUkRfU0laRShk
c3RfcmVnKQogCiAgICAgICAgIHNmZW5jZQotICAgICAgICByZXQKKyAgICAg
ICAgUkVUCiBFTkQoY29weV9wYWdlX3NzZTIpCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvZWZpL2NoZWNrLmMgYi94ZW4vYXJjaC94ODYvZWZpL2NoZWNr
LmMKaW5kZXggOWU0NzNmYWFkM2M5Li4yM2JhMzBhYmYzMzAgMTAwNjQ0Ci0t
LSBhL3hlbi9hcmNoL3g4Ni9lZmkvY2hlY2suYworKysgYi94ZW4vYXJjaC94
ODYvZWZpL2NoZWNrLmMKQEAgLTMsNiArMyw5IEBAIGludCBfX2F0dHJpYnV0
ZV9fKChfX21zX2FiaV9fKSkgdGVzdChpbnQgaSkKICAgICByZXR1cm4gaTsK
IH0KIAorLyogSW4gY2FzZSAtbWZ1bmN0aW9uLXJldHVybiBpcyBpbiB1c2Uu
ICovCit2b2lkIF9feDg2X3JldHVybl90aHVuayh2b2lkKSB7fTsKKwogLyoK
ICAqIFBvcHVsYXRlIGFuIGFycmF5IHdpdGggImFkZHJlc3NlcyIgb2YgcmVs
b2NhdGFibGUgYW5kIGFic29sdXRlIHZhbHVlcy4KICAqIFRoaXMgaXMgdG8g
cHJvYmUgbGQgZm9yIChhKSBlbWl0dGluZyBiYXNlIHJlbG9jYXRpb25zIGF0
IGFsbCBhbmQgKGIpIG5vdApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2FzbS1kZWZucy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FzbS1kZWZucy5oCmluZGV4IDFiODIxZGI0OWNhMy4uOTYzNzBkZDky
YTU4IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYXNt
LWRlZm5zLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1k
ZWZucy5oCkBAIC0zNiw2ICszNiwxMiBAQAogICAgIC5lbmRpZgogLmVuZG0K
IAorI2lmZGVmIENPTkZJR19SRVRVUk5fVEhVTksKKyMgZGVmaW5lIFJFVCBq
bXAgX194ODZfcmV0dXJuX3RodW5rCisjZWxzZQorIyBkZWZpbmUgUkVUIHJl
dAorI2VuZGlmCisKICNpZmRlZiBDT05GSUdfWEVOX0lCVAogIyBkZWZpbmUg
RU5EQlI2NCBlbmRicjY0CiAjZWxzZQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2luZGlyZWN0LXRodW5rLlMgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3Qt
dGh1bmsuUwppbmRleCBjNGI5NzhkNjdiOGUuLjI2ZGFkMTVmMTJjOSAxMDA2
NDQKLS0tIGEveGVuL2FyY2gveDg2L2luZGlyZWN0LXRodW5rLlMKKysrIGIv
eGVuL2FyY2gveDg2L2luZGlyZWN0LXRodW5rLlMKQEAgLTE1LDYgKzE1LDgg
QEAKICN1bmRlZiBTWU1fQUxJR04KICNkZWZpbmUgU1lNX0FMSUdOKGFsaWdu
Li4uKQogCisjaWZkZWYgQ09ORklHX0lORElSRUNUX1RIVU5LCisKIC5tYWNy
byBJTkRfVEhVTktfUkVUUE9MSU5FIHJlZzpyZXEKICAgICAgICAgY2FsbCAx
ZgogICAgICAgICBpbnQzCkBAIC02MiwzICs2NCwyNSBAQCBFTkQoX194ODZf
aW5kaXJlY3RfdGh1bmtfXHJlZykKIC5pcnAgcmVnLCBheCwgY3gsIGR4LCBi
eCwgYnAsIHNpLCBkaSwgOCwgOSwgMTAsIDExLCAxMiwgMTMsIDE0LCAxNQog
ICAgICAgICBHRU5fSU5ESVJFQ1RfVEhVTksgcmVnPXJccmVnCiAuZW5kcgor
CisjZW5kaWYgLyogQ09ORklHX0lORElSRUNUX1RIVU5LICovCisKKyNpZmRl
ZiBDT05GSUdfUkVUVVJOX1RIVU5LCisgICAgICAgIC5zZWN0aW9uIC50ZXh0
LmVudHJ5Ll9feDg2X3JldHVybl90aHVuaywgImF4IiwgQHByb2diaXRzCisK
KyAgICAgICAgLyoKKyAgICAgICAgICogVGhlIEluZGlyZWN0IFRhcmdldCBT
ZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0eSBtZWFucyB0aGF0
CisgICAgICAgICAqIGluZGlyZWN0IGJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdAorICAgICAgICAgKiBo
YWxmIG9mIGEgY2FjaGVsaW5lLiAgQXJyYW5nZSBmb3IgdGhlbSB0byBiZSBp
biB0aGUgc2Vjb25kIGhhbGYuCisgICAgICAgICAqCisgICAgICAgICAqIEFs
aWduIHRvIDY0LCB0aGVuIHNraXAgMzIuCisgICAgICAgICAqLworICAgICAg
ICAuYmFsaWduIDY0CisgICAgICAgIC5maWxsIDMyLCAxLCAweGNjCisKK0ZV
TkMoX194ODZfcmV0dXJuX3RodW5rKQorICAgICAgICByZXQKKyAgICAgICAg
aW50MyAvKiBIYWx0IHN0cmFpZ2h0LWxpbmUgc3BlY3VsYXRpb24gKi8KK0VO
RChfX3g4Nl9yZXR1cm5fdGh1bmspCisKKyNlbmRpZiAvKiBDT05GSUdfUkVU
VVJOX1RIVU5LICovCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvcHYvZW11
bC1wcml2LW9wLmMgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMK
aW5kZXggZmY1ZDFjOWY4NjM0Li4yOTVkODQ3ZWEyNGMgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXByaXYtb3AuYworKysgYi94ZW4vYXJj
aC94ODYvcHYvZW11bC1wcml2LW9wLmMKQEAgLTEzMSw3ICsxMzEsNyBAQCBz
dGF0aWMgaW9fZW11bF9zdHViX3QgKmlvX2VtdWxfc3R1Yl9zZXR1cChzdHJ1
Y3QgcHJpdl9vcF9jdHh0ICpjdHh0LCB1OCBvcGNvZGUsCiAgICAgQlVJTERf
QlVHX09OKFNUVUJfQlVGX1NJWkUgLyAyIDwKICAgICAgICAgICAgICAgICAg
KHNpemVvZihwcm9sb2d1ZSkgKyBzaXplb2YoZXBpbG9ndWUpICsgMTAgLyog
MnggY2FsbCAqLyArCiAgICAgICAgICAgICAgICAgICBNQVgoMyAvKiBkZWZh
dWx0IHN0dWIgKi8sIElPRU1VTF9RVUlSS19TVFVCX0JZVEVTKSArCi0gICAg
ICAgICAgICAgICAgICAxIC8qIHJldCAqLykpOworICAgICAgICAgICAgICAg
ICAgKElTX0VOQUJMRUQoQ09ORklHX1JFVFVSTl9USFVOSykgPyA1IDogMSkg
LyogcmV0ICovKSk7CiAgICAgLyogUnVudGltZSBjb25maXJtYXRpb24gdGhh
dCB3ZSBoYXZlbid0IGNsb2JiZXJlZCBhbiBhZGphY2VudCBzdHViLiAqLwog
ICAgIEJVR19PTihTVFVCX0JVRl9TSVpFIC8gMiA8IChwIC0gY3R4dC0+aW9f
ZW11bF9zdHViKSk7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9wdi9n
cHJfc3dpdGNoLlMgYi94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5TCmlu
ZGV4IDU0MDlhZDNiMTQ0Ny4uMzYyYjVkMjQxNjIzIDEwMDY0NAotLS0gYS94
ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5TCisrKyBiL3hlbi9hcmNoL3g4
Ni9wdi9ncHJfc3dpdGNoLlMKQEAgLTI2LDcgKzI2LDcgQEAgRlVOQyhsb2Fk
X2d1ZXN0X2dwcnMpCiAgICAgICAgIG1vdnEgIFVSRUdTX3IxNSglcmRpKSwg
JXIxNQogICAgICAgICBtb3ZxICBVUkVHU19yY3goJXJkaSksICVyY3gKICAg
ICAgICAgbW92cSAgVVJFR1NfcmRpKCVyZGkpLCAlcmRpCi0gICAgICAgIHJl
dAorICAgICAgICBSRVQKIEVORChsb2FkX2d1ZXN0X2dwcnMpCiAKIC8qIFNh
dmUgZ3Vlc3QgR1BScy4gIFBhcmFtZXRlciBvbiB0aGUgc3RhY2sgYWJvdmUg
dGhlIHJldHVybiBhZGRyZXNzLiAqLwpAQCAtNDgsNSArNDgsNSBAQCBGVU5D
KHNhdmVfZ3Vlc3RfZ3BycykKICAgICAgICAgbW92cSAgJXJieCwgVVJFR1Nf
cmJ4KCVyZGkpCiAgICAgICAgIG1vdnEgICVyZHgsIFVSRUdTX3JkeCglcmRp
KQogICAgICAgICBtb3ZxICAlcmN4LCBVUkVHU19yY3goJXJkaSkKLSAgICAg
ICAgcmV0CisgICAgICAgIFJFVAogRU5EKHNhdmVfZ3Vlc3RfZ3BycykKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNo
L3g4Ni9zcGVjX2N0cmwuYwppbmRleCBjZWQ4NDc1MDAxNWMuLmZlMjdlODJh
NDcwNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCisr
KyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwpAQCAtNTcxLDYgKzU3MSw5
IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5k
X3RodW5rIHRodW5rKQogI2lmZGVmIENPTkZJR19JTkRJUkVDVF9USFVOSwog
ICAgICAgICAgICAgICAgIiBJTkRJUkVDVF9USFVOSyIKICNlbmRpZgorI2lm
ZGVmIENPTkZJR19SRVRVUk5fVEhVTksKKyAgICAgICAgICAgICAgICIgUkVU
VVJOX1RIVU5LIgorI2VuZGlmCiAjaWZkZWYgQ09ORklHX1NIQURPV19QQUdJ
TkcKICAgICAgICAgICAgICAgICIgU0hBRE9XX1BBR0lORyIKICNlbmRpZgpk
aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnku
UyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKaW5kZXgg
MWU4NzY1MmY0YmNiLi5kN2IzODFlYTU0NmQgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKKysrIGIveGVuL2FyY2gv
eDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwpAQCAtMTgwLDcgKzE4MCw3IEBA
IEZVTkMoY3I0X3B2MzJfcmVzdG9yZSkKICAgICAgICAgb3IgICAgY3I0X3B2
MzJfbWFzayglcmlwKSwgJXJheAogICAgICAgICBtb3YgICAlcmF4LCAlY3I0
CiAgICAgICAgIG1vdiAgICVyYXgsICglcmN4KQotICAgICAgICByZXQKKyAg
ICAgICAgUkVUCiAwOgogI2lmbmRlZiBOREVCVUcKICAgICAgICAgLyogQ2hl
Y2sgdGhhdCBfYWxsXyBvZiB0aGUgYml0cyBpbnRlbmRlZCB0byBiZSBzZXQg
YWN0dWFsbHkgYXJlLiAqLwpAQCAtMTk4LDcgKzE5OCw3IEBAIEZVTkMoY3I0
X3B2MzJfcmVzdG9yZSkKIDE6CiAjZW5kaWYKICAgICAgICAgeG9yICAgJWVh
eCwgJWVheAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQoY3I0X3B2
MzJfcmVzdG9yZSkKIAogRlVOQyhjb21wYXRfc3lzY2FsbCkKQEAgLTMyOSw3
ICszMjksNyBAQCBfX1VOTElLRUxZX0VORChjb21wYXRfYm91bmNlX251bGxf
c2VsZWN0b3IpCiAgICAgICAgIHhvciAgICVlYXgsICVlYXgKICAgICAgICAg
bW92ICAgJWF4LCAgVFJBUEJPVU5DRV9jcyglcmR4KQogICAgICAgICBtb3Yg
ICAlYWwsICBUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCi0gICAgICAgIHJldAor
ICAgICAgICBSRVQKIAogLnNlY3Rpb24gLmZpeHVwLCJheCIKIC5MZngxMzoK
ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUyBiL3hl
bi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwppbmRleCBkODFhNjI2ZDE2Njcu
LjM5YzdiOWQxN2Y5ZSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82
NC9lbnRyeS5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwpA
QCAtNjA0LDcgKzYwNCw3IEBAIF9fVU5MSUtFTFlfRU5EKGNyZWF0ZV9ib3Vu
Y2VfZnJhbWVfYmFkX2JvdW5jZV9pcCkKICAgICAgICAgeG9yICAgJWVheCwg
JWVheAogICAgICAgICBtb3YgICAlcmF4LCBUUkFQQk9VTkNFX2VpcCglcmR4
KQogICAgICAgICBtb3YgICAlYWwsICBUUkFQQk9VTkNFX2ZsYWdzKCVyZHgp
Ci0gICAgICAgIHJldAorICAgICAgICBSRVQKIAogICAgICAgICAucHVzaHNl
Y3Rpb24gLmZpeHVwLCAiYXgiLCBAcHJvZ2JpdHMKICAgICAgICAgIyBOdW1l
cmljIHRhZ3MgYmVsb3cgcmVwcmVzZW50IHRoZSBpbnRlbmRlZCBvdmVyYWxs
ICVyc2kgYWRqdXN0bWVudC4KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94
ZW4ubGRzLlMgYi94ZW4vYXJjaC94ODYveGVuLmxkcy5TCmluZGV4IDUzYmFm
Yzk4YTUzNi4uYmY5NTZiNmM1ZmMwIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94
ODYveGVuLmxkcy5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMKQEAg
LTg1LDYgKzg1LDcgQEAgU0VDVElPTlMKICAgICAgICAuID0gQUxJR04oUEFH
RV9TSVpFKTsKICAgICAgICBfc3RleHRlbnRyeSA9IC47CiAgICAgICAgKigu
dGV4dC5lbnRyeSkKKyAgICAgICAqKC50ZXh0LmVudHJ5LiopCiAgICAgICAg
LiA9IEFMSUdOKFBBR0VfU0laRSk7CiAgICAgICAgX2V0ZXh0ZW50cnkgPSAu
OwogCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL0tjb25maWcgYi94ZW4vY29t
bW9uL0tjb25maWcKaW5kZXggYmY3YjA4MWFkMGI3Li42ZDQzYmUyZTZlOGEg
MTAwNjQ0Ci0tLSBhL3hlbi9jb21tb24vS2NvbmZpZworKysgYi94ZW4vY29t
bW9uL0tjb25maWcKQEAgLTE3Miw2ICsxNzIsMTcgQEAgY29uZmlnIElORElS
RUNUX1RIVU5LCiAJICBieSBjaG9vc2luZyBhIGhhcmR3YXJlLWRlcGVuZGVu
dCBpbnN0cnVjdGlvbiBzZXF1ZW5jZSB0byBpbXBsZW1lbnQKIAkgIChlLmcu
IGZ1bmN0aW9uIHBvaW50ZXJzKSBzYWZlbHkuICAiUmV0cG9saW5lIiBpcyBv
bmUgc3VjaCBzZXF1ZW5jZS4KIAorY29uZmlnIFJFVFVSTl9USFVOSworCWJv
b2wgIk91dC1vZi1saW5lIFJldHVybnMiCisJZGVwZW5kcyBvbiBDQ19IQVNf
UkVUVVJOX1RIVU5LCisJZGVmYXVsdCBJTkRJUkVDVF9USFVOSworCWhlbHAK
KwkgIENvbXBpbGUgWGVuIHdpdGggb3V0LW9mLWxpbmUgcmV0dXJucy4KKwor
CSAgVGhpcyBhbGxvd3MgWGVuIHRvIG1pdGlnYXRlIGEgdmFyaWV0eSBvZiBz
cGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXRpZXMKKwkgIGJ5IGNob29zaW5nIGEg
aGFyZHdhcmUtZGVwZW5kZW50IGluc3RydWN0aW9uIHNlcXVlbmNlIHRvIGlt
cGxlbWVudAorCSAgZnVuY3Rpb24gcmV0dXJucyBzYWZlbHkuCisKIGNvbmZp
ZyBTUEVDVUxBVElWRV9IQVJERU5fQVJSQVkKIAlib29sICJTcGVjdWxhdGl2
ZSBBcnJheSBIYXJkZW5pbmciCiAJZGVmYXVsdCB5CmRpZmYgLS1naXQgYS94
ZW4vbGliL3g4Ni1nZW5lcmljLWh3ZWlnaHRsLmMgYi94ZW4vbGliL3g4Ni1n
ZW5lcmljLWh3ZWlnaHRsLmMKaW5kZXggMTIzYTViNDM5MjhkLi4xY2FiNjg5
NTJhNDIgMTAwNjQ0Ci0tLSBhL3hlbi9saWIveDg2LWdlbmVyaWMtaHdlaWdo
dGwuYworKysgYi94ZW4vbGliL3g4Ni1nZW5lcmljLWh3ZWlnaHRsLmMKQEAg
LTUxLDcgKzUxLDExIEBAIGFzbSAoCiAgICAgInBvcCAgICAlcmR4XG5cdCIK
ICAgICAicG9wICAgICVyZGlcblx0IgogCisjaWZkZWYgQ09ORklHX1JFVFVS
Tl9USFVOSworICAgICJqbXAgICAgX194ODZfcmV0dXJuX3RodW5rXG5cdCIK
KyNlbHNlCiAgICAgInJldFxuXHQiCisjZW5kaWYKIAogICAgICIuc2l6ZSBh
cmNoX2dlbmVyaWNfaHdlaWdodGwsIC4gLSBhcmNoX2dlbmVyaWNfaHdlaWdo
dGxcblx0IgogKTsK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-07.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-07.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogU3ludGhlc2lzZSBJVFNfTk8g
dG8gZ3Vlc3RzIG9uIHVuYWZmZWN0ZWQgaGFyZHdhcmUKCkl0IGlzIGVhc2ll
ciB0byBleHByZXNzIGZlYXR1cmUgd29yZCAxNyBpbiB0ZXJtcyBvZiB3b3Jk
IDE2ICsgWzMyLCA2NCkgYXMKdGhhdCdzIGhvdyB0aGUgbGF5b3V0IGlzIGdp
dmVuIGluIGRvY3VtZW50YXRpb24uCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2
OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29v
cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKaW5k
ZXggMDUzOTlmYjljOTgyLi4zOTdhMDRhZjQxYTEgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKKysrIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaApAQCAtMjE5LDYg
KzIxOSw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBib290X2NwdV9oYXModW5z
aWduZWQgaW50IGZlYXQpCiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAgICAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCiAjZGVmaW5l
IGNwdV9oYXNfcmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9SRkRTX05PKQogI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIgICAg
ICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKKyNkZWZp
bmUgY3B1X2hhc19pdHNfbm8gICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX0lUU19OTykKIAogLyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5l
IGNwdV9oYXNfYXJjaF9wZXJmbW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9BUkNIX1BFUkZNT04pCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg
ZmUyN2U4MmE0NzA3Li4wYTYzNTAyNWU0ODggMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMKQEAgLTE3NjAsNiArMTc2MCw5MCBAQCBzdGF0aWMgdm9pZCBfX2lu
aXQgYmhpX2NhbGN1bGF0aW9ucyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAq
IGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZl
bG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1
aWRhbmNlL2Fkdmlzb3J5LWd1aWRhbmNlL2luZGlyZWN0LXRhcmdldC1zZWxl
Y3Rpb24uaHRtbAorICovCitzdGF0aWMgdm9pZCBfX2luaXQgaXRzX2NhbGN1
bGF0aW9ucyh2b2lkKQoreworICAgIC8qCisgICAgICogSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBpcyBhIEJyYW5jaCBQcmVkaWN0aW9uIGJ1ZyB3aGVy
ZWJ5IGNlcnRhaW4KKyAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGdldCBwcmVkaWN0ZWQgdXNpbmcgYSBkaXJlY3QgYnJhbmNo
CisgICAgICogdGFyZ2V0LCByYXRoZXIgdGhhbiBhIHN1aXRhYmxlIGluZGly
ZWN0IHRhcmdldCwgYnlwYXNzaW5nIGhhcmR3YXJlCisgICAgICogaXNvbGF0
aW9uIHByb3RlY3Rpb25zLgorICAgICAqCisgICAgICogSVRTIGFmZmVjdHMg
Q29yZSAoYnV0IG5vdCBBdG9tKSBwcm9jZXNzb3JzIHN0YXJ0aW5nIGZyb20g
dGhlCisgICAgICogaW50cm9kdWN0aW9uIG9mIGVJQlJTLCB1cCB0byBidXQg
bm90IGluY2x1ZGluZyBHb2xkZW4gQ292ZSBjb3JlcworICAgICAqIChjaGVj
a2VkIGhlcmUgd2l0aCBCSElfQ1RSTCkuCisgICAgICoKKyAgICAgKiBUaGUg
SVRTX05PIGZlYXR1cmUgaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVudW1lcmF0
ZWQgYnkgaGFyZHdhcmUsIGFuZCBpcworICAgICAqIG9ubHkgZm9yIFZNTXMg
dG8gc3ludGhlc2lzZSBmb3IgZ3Vlc3RzLgorICAgICAqCisgICAgICogSVRT
IGNvbWVzIGluIDMgZmxhdm91cnM6CisgICAgICoKKyAgICAgKiAgIDEpIEFj
cm9zcy1JQlBCLiAgSW5kaXJlY3QgYnJhbmNoZXMgYWZ0ZXIgdGhlIElCUEIg
Y2FuIGJlIGNvbnRyb2xsZWQKKyAgICAgKiAgICAgIGJ5IGRpcmVjdCB0YXJn
ZXRzIHdoaWNoIGV4aXN0ZWQgcHJpb3IgdG8gdGhlIElCUEIuICBUaGlzIGlz
CisgICAgICogICAgICBhZGRyZXNzZWQgaW4gdGhlIElQVSAyMDI1LjEgbWlj
cm9jb2RlIGRyb3AsIGFuZCBoYXMgbm8gb3RoZXIKKyAgICAgKiAgICAgIHNv
ZnR3YXJlIGludGVyYWN0aW9uLgorICAgICAqCisgICAgICogICAyKSBHdWVz
dC9Ib3N0LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgZGlyZWN0IHRhcmdldHMgZnJv
bSB0aGUgZ3Vlc3QuICBUaGlzIGFwcGxpZXMgZXF1YWxseSB0byBQViBndWVz
dHMKKyAgICAgKiAgICAgIChSaW5nMykgYW5kIEhWTSBndWVzdHMgKFZNWCks
IGFuZCBhcHBsaWVzIHRvIGFsbCBTa3lsYWtlLXVhcmNoCisgICAgICogICAg
ICBjb3JlcyB3aXRoIGVJQlJTLgorICAgICAqCisgICAgICogICAzKSBJbnRy
YS1tb2RlLiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgb3RoZXIgZXhlY3V0aW9uIGlu
IHRoZSBzYW1lIG1vZGUuCisgICAgICovCisKKyAgICAvKgorICAgICAqIElm
IHdlIGNhbiBzZWUgSVRTX05PLCBvciB3ZSdyZSB2aXJ0dWFsaXNlZCwgZG8g
bm90aGluZy4gIFdlIGFyZSBvciBtYXkKKyAgICAgKiBtaWdyYXRlIHNvbWV3
aGVyZSB1bnNhZmUuCisgICAgICovCisgICAgaWYgKCBjcHVfaGFzX2l0c19u
byB8fCBjcHVfaGFzX2h5cGVydmlzb3IgKQorICAgICAgICByZXR1cm47CisK
KyAgICAvKiBJVFMgaXMgb25seSBrbm93biB0byBhZmZlY3QgSW50ZWwgcHJv
Y2Vzc29ycyBhdCB0aGlzIHRpbWUuICovCisgICAgaWYgKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9JTlRFTCApCisgICAgICAg
IHJldHVybjsKKworICAgIC8qCisgICAgICogSVRTIGRvZXMgbm90IGV4aXN0
IG9uOgorICAgICAqICAtIG5vbi1GYW1pbHkgNiBDUFVzCisgICAgICogIC0g
dGhvc2Ugd2l0aG91dCBlSUJSUworICAgICAqICAtIHRob3NlIHdpdGggQkhJ
X0NUUkwKKyAgICAgKiBidXQgd2Ugc3RpbGwgbmVlZCB0byBzeW50aGVzaXNl
IElUU19OTy4KKyAgICAgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2
ICE9IDYgfHwgIWNwdV9oYXNfZWlicnMgfHwKKyAgICAgICAgIGJvb3RfY3B1
X2hhcyhYODZfRkVBVFVSRV9CSElfQ1RSTCkgKQorICAgICAgICBnb3RvIHN5
bnRoZXNpc2U7CisKKyAgICBzd2l0Y2ggKCBib290X2NwdV9kYXRhLng4Nl9t
b2RlbCApCisgICAgeworICAgICAgICAvKiBUaGVzZSBTa3lsYWtlLXVhcmNo
IGNvcmVzIHN1ZmZlciBjYXNlcyAjMiBhbmQgIzMuICovCisgICAgY2FzZSBJ
TlRFTF9GQU02X1NLWUxBS0VfWDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FC
WUxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0U6CisgICAg
Y2FzZSBJTlRFTF9GQU02X0NPTUVUTEFLRToKKyAgICBjYXNlIElOVEVMX0ZB
TTZfQ09NRVRMQUtFX0w6CisgICAgICAgIHJldHVybjsKKworICAgICAgICAv
KiBUaGVzZSBTdW5ueS9XaWxsb3cvQ3lwcmVzcyBDb3ZlIGNvcmVzIHN1ZmZl
ciBjYXNlICMzLiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9JQ0VMQUtFX1g6
CisgICAgY2FzZSBJTlRFTF9GQU02X0lDRUxBS0VfRDoKKyAgICBjYXNlIElO
VEVMX0ZBTTZfSUNFTEFLRV9MOgorICAgIGNhc2UgSU5URUxfRkFNNl9USUdF
UkxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfVElHRVJMQUtFOgorICAg
IGNhc2UgSU5URUxfRkFNNl9ST0NLRVRMQUtFOgorICAgICAgICByZXR1cm47
CisKKyAgICBkZWZhdWx0OgorICAgICAgICBicmVhazsKKyAgICB9CisKKyAg
ICAvKiBQbGF0Zm9ybXMgcmVtYWluaW5nIGFyZSBub3QgYmVsaWV2ZWQgdG8g
YmUgdnVsbmVyYWJsZSB0byBJVFMuICovCisgc3ludGhlc2lzZToKKyAgICBz
ZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX0lUU19OTyk7Cit9CisK
IHZvaWQgc3BlY19jdHJsX2luaXRfZG9tYWluKHN0cnVjdCBkb21haW4gKmQp
CiB7CiAgICAgYm9vbCBwdiA9IGlzX3B2X2RvbWFpbihkKTsKQEAgLTIzMTYs
NiArMjQwMCw4IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0
aWdhdGlvbnModm9pZCkKIAogICAgIGJoaV9jYWxjdWxhdGlvbnMoKTsKIAor
ICAgIGl0c19jYWxjdWxhdGlvbnMoKTsKKwogICAgIHByaW50X2RldGFpbHMo
dGh1bmspOwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IGMyOTBkMTY2
ODM1OC4uYTZkNGEwY2JhN2Q4IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNs
dWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTM5MSw3
ICszOTEsOCBAQCBYRU5fQ1BVRkVBVFVSRShSRkRTX0NMRUFSLCAgICAgICAg
IDE2KjMyKzI4KSAvKiFBfCBSZWdpc3RlciBGaWxlKHMpIGNsZWFyZWQgYnkg
VgogWEVOX0NQVUZFQVRVUkUoSUdOX1VNT05JVE9SLCAgICAgICAxNiozMisy
OSkgLyogICBNQ1VfT1BUX0NUUkwuSUdOX1VNT05JVE9SICovCiBYRU5fQ1BV
RkVBVFVSRShNT05fVU1PTl9NSVRHLCAgICAgIDE2KjMyKzMwKSAvKiAgIE1D
VV9PUFRfQ1RSTC5NT05fVU1PTl9NSVRHICovCiAKLS8qIEludGVsLWRlZmlu
ZWQgQ1BVIGZlYXR1cmVzLCBNU1JfQVJDSF9DQVBTIDB4MTBhLmVkeCwgd29y
ZCAxNyAqLworLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMsIE1TUl9B
UkNIX0NBUFMgMHgxMGEuZWR4LCB3b3JkIDE3IChleHByZXNzIGluIHRlcm1z
IG9mIHdvcmQgMTYpICovCitYRU5fQ1BVRkVBVFVSRShJVFNfTk8sICAgICAg
ICAgICAgIDE2KjMyKzYyKSAvKiFBIE5vIEluZGlyZWN0IFRhcmdldCBTZWxl
Y3Rpb24gKi8KIAogI2VuZGlmIC8qIFhFTl9DUFVGRUFUVVJFICovCiAKZGlm
ZiAtLWdpdCBhL3hlbi90b29scy9nZW4tY3B1aWQucHkgYi94ZW4vdG9vbHMv
Z2VuLWNwdWlkLnB5CmluZGV4IGE3N2NiMzBiZGI0Zi4uMTYzYjEwNWJjNmE3
IDEwMDc1NQotLS0gYS94ZW4vdG9vbHMvZ2VuLWNwdWlkLnB5CisrKyBiL3hl
bi90b29scy9nZW4tY3B1aWQucHkKQEAgLTUxLDcgKzUxLDcgQEAgZGVmIHBh
cnNlX2RlZmluaXRpb25zKHN0YXRlKToKICAgICAgICAgciJccysvXCooW1x3
IXxdKikgLiokIikKIAogICAgIHdvcmRfcmVnZXggPSByZS5jb21waWxlKAot
ICAgICAgICByIl4vXCogLiogd29yZCAoXGQqKSBcKi8kIikKKyAgICAgICAg
ciJeL1wqIC4qIHdvcmQgKFxkKikgLipcKi8kIikKICAgICBsYXN0X3dvcmQg
PSAtMQogCiAgICAgdGhpcyA9IHN5cy5tb2R1bGVzW19fbmFtZV9fXQo=

--=separator--


From xen-devel-bounces@lists.xenproject.org Mon May 12 17:15:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 17:15:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981919.1368383 (Exim 4.92)
	(envelope-from )
	id 1uEWkW-00010j-C7; Mon, 12 May 2025 17:15:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981919.1368383; Mon, 12 May 2025 17: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 1uEWkW-00010b-7Y; Mon, 12 May 2025 17:15:32 +0000
Received: by outflank-mailman (input) for mailman id 981919;
 Mon, 12 May 2025 17:15:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEWkU-0000y3-Gw
 for xen-devel@lists.xen.org; Mon, 12 May 2025 17:15:31 +0000
Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b2d9fcbe-2f54-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 19:15:28 +0200 (CEST)
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uEWkM-004GoG-2v;
 Mon, 12 May 2025 17:15:22 +0000
Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96)
 (envelope-from ) id 1uEWkM-002pP4-24;
 Mon, 12 May 2025 17:15: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" 
X-Inumbo-ID: b2d9fcbe-2f54-11f0-9eb6-5ba50f476ded
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 469 v2 (CVE-2024-28956) - x86: Indirect
 Target Selection
Message-Id: 
Date: Mon, 12 May 2025 17:15:22 +0000

--=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-2024-28956 / XSA-469
                               version 2

                    x86: Indirect Target Selection

UPDATES IN VERSION 2
====================

State the CVE.

ISSUE DESCRIPTION
=================

Researchers at VU Amsterdam have released Training Solo, detailing
several speculative attacks which bypass current protections.

One issue, which Intel have named Indirect Target Selection, is a bug in
the hardware support for prediction-domain isolation.  The mitigation
for this involves both microcode and software changes in Xen.

For more details, see:
  https://vusec.net/projects/training-solo
  https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/indirect-target-selection.html

Another issue discussed in the Training Solo paper pertains to
classic-BPF.  Xen does not have any capability similar to BPF filters,
so is not believed to be affected by this issue.

IMPACT
======

An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==================

Systems running all versions of Xen are affected.

Only Intel x86 CPUs are potentially affected.  CPUs from other
manufacturers are not known to be affected.

The affected Intel CPUs are believed to be those which have eIBRS
(hardware Spectre-v2 mitigations, starting with Cascade Lake) up to but
not including those which have BHI_CTRL (Alder Lake and Sapphire
Rapids).  See the Intel whitepaper for full details.

MITIGATION
==========

There are no mitigations.

RESOLUTION
==========

Intel are producing microcode to address part of this issue, by
extending IBPB.  This was released in IPU 2025.1 (February 2025).
Consult your dom0 OS vendor and/or hardware vendor for updated
microcode.

In addition to the microcode, changes are required to Xen to address the
other part of the issue.  These involve recompiling Xen using Return
Thunks (-mfunction-return).  Support for Return Thunks is available in
GCC 8 and Clang 15.  Therefore, the Xen patches further rely on a
toolchain at least this new.

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.

xsa469/xsa469-??.patch           xen-unstable
xsa469/xsa469-4.20-??.patch      Xen 4.20.x
xsa469/xsa469-4.19-??.patch      Xen 4.19.x
xsa469/xsa469-4.18-??.patch      Xen 4.18.x
xsa469/xsa469-4.17-??.patch      Xen 4.17.x

$ sha256sum xsa469*/*
24648f43282a4c4917f49a828f0889139ffd08710884c2d5d2a149213f889316  xsa469/xsa469-01.patch
f9e1e999e5121b71263ccac9e5dbc7f2422751cd8776526b59a3a535245ee271  xsa469/xsa469-02.patch
3aebd84d8c9374e8db4f28a1bd0265ff46d60a142e8cc983c0eae99a3caa4459  xsa469/xsa469-03.patch
1f836801a543d00a4e79daff0438932c7d7b5e9ee76dead124d290e805adc0f2  xsa469/xsa469-4.17-01.patch
aaa7b6967b3ff8b279675edafbccff4e1882202251e8f37c1aaab8e16f4ca8c9  xsa469/xsa469-4.17-02.patch
cf9a224628f218a7afdf7a275da270b8f469342133d3239c19a8b05adb8d9d9e  xsa469/xsa469-4.17-03.patch
5179885f9452f932b9829e942a6942d7a1bba6820c383b0e0ac7ade34f6f444c  xsa469/xsa469-4.17-04.patch
7d44272960d7ecdc920a14eb19c686c6808fe980bb85c3a467b5e343f137d927  xsa469/xsa469-4.17-05.patch
3984f20f3b84a579a4828da8c60268f55f1ff2dfc030d1790efb52a6ad659cd9  xsa469/xsa469-4.17-06.patch
8ec20c0943def1764c858c76699991aa0b7af76a8773be8219d62c240cf0b294  xsa469/xsa469-4.17-07.patch
00943be479ac428a496dec248c33e9ae9a0002e437a50c46a43d15146ddcccd8  xsa469/xsa469-4.18-01.patch
b5e9ab3ba33c7a5ad2948521a71d73b8e587d4b86fb73b3ce06557343753b097  xsa469/xsa469-4.18-02.patch
cf9a224628f218a7afdf7a275da270b8f469342133d3239c19a8b05adb8d9d9e  xsa469/xsa469-4.18-03.patch
5179885f9452f932b9829e942a6942d7a1bba6820c383b0e0ac7ade34f6f444c  xsa469/xsa469-4.18-04.patch
d7271118c516ea2b57b82afbaa67e44ebc0bee9067925850671a47ba7e6916fc  xsa469/xsa469-4.18-05.patch
99aa42f3b4d492c21d3027f74abe20183cdd411fdf94d62c10c423e6516db5aa  xsa469/xsa469-4.18-06.patch
893e3b721fe00623a8d75414f40f11033a4a3999d368a141eec8652d9733a77e  xsa469/xsa469-4.18-07.patch
a5a958452c4b3adc820692349103892ec3ffc3195c9b4e1fc55547d2ec7aec57  xsa469/xsa469-4.19-01.patch
2f3a3dadc69026ffa0a093ae34c239023e2336b3f9ec90a1ddc5df7b103c158c  xsa469/xsa469-4.19-02.patch
3aebd84d8c9374e8db4f28a1bd0265ff46d60a142e8cc983c0eae99a3caa4459  xsa469/xsa469-4.19-03.patch
bbdb2fcda3d2fe36ceaaf235700158f5a4f08c8983732265725cc7ac811c9bd2  xsa469/xsa469-4.19-04.patch
fd01af8b8cc66b6a1f0e2a7383b4c320cbb1513b7f23a7bd84fbb3e626751122  xsa469/xsa469-4.19-05.patch
1ed51e005c7f07a99793bfc97680bc02e8661412d88a853594f40a02599e03c2  xsa469/xsa469-4.19-06.patch
4dda661661f23b48f62caeaadd1b02ef79b2d7b08e61ab44c2eacdd2171f63b8  xsa469/xsa469-4.19-07.patch
27ce09ab9bb9460bec08761b2f739ce5adb292dc13664dfa425e42e5b8db8731  xsa469/xsa469-4.20-01.patch
f9e1e999e5121b71263ccac9e5dbc7f2422751cd8776526b59a3a535245ee271  xsa469/xsa469-4.20-02.patch
3aebd84d8c9374e8db4f28a1bd0265ff46d60a142e8cc983c0eae99a3caa4459  xsa469/xsa469-4.20-03.patch
bbdb2fcda3d2fe36ceaaf235700158f5a4f08c8983732265725cc7ac811c9bd2  xsa469/xsa469-4.20-04.patch
656031e56bbf8c8d0e8bd294c1e8857dd80850ae3cc68efbf42564f2b9efdb1f  xsa469/xsa469-4.20-05.patch
3343a834e0931b56490a50cc9fc7488a13a98a00923e4399020f628b3aab0220  xsa469/xsa469-4.20-06.patch
465d916cac02bb4ae1edf9db34fe5d2426ac1681a1078d331fbdf449834692c4  xsa469/xsa469-4.20-07.patch
97335c870407928039464307611c0b9687fd7cdfde5124ec5441a4fddfaa4165  xsa469/xsa469-04.patch
226771d9359b3c341c0978a145c29478d4c6ca196ec67d48c3df6115aee27940  xsa469/xsa469-05.patch
17eae8965871975569be4228943d5136eb65951d9c9513d2b0fe743e8cf8e4ef  xsa469/xsa469-06.patch
fa8b7ed035e242a3881431150ee86965f26520dab4432e3f7ac9862063491f72  xsa469/xsa469-07.patch
$
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmgiLJAMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ7uUIAIrV83bfhcHAnZvWo5CGOtuyuwQQuobYKqUcC3fq
/LGKVwmrQVCR6qm2YeI8TIhJfet8OiqutteaVknAJlegVR8uTIznIr7CzjmzgoR5
ojnw0Ae0rQ5rhzSeMvBD1VsbheBI7nmLR9dorMs+Rp9MiVzboT81XOpWDTMHisjI
4LpN+TB+yIB76hQQ4divDnqFKxA1SFQWrmn2bcr3v5cJ1cctvLOic/67WO9Uto92
5tG7iV68cStski0wMvjO1isalCTKSaU7eDjTe1ar+/SwhE4T0RKfcpim3xcc5ZVk
cH/xKcK4vbJUKIxjqnDrEdT3uGk1vdVxJfNAOCpfZc5EwiI=
=A2YZ
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-01.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-01.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2FsdGVybmF0aXZlOiBTdXBwb3J0IHJlcGxhY2Vt
ZW50cyB3aGVuIGEgZmVhdHVyZSBpcyBub3QgcHJlc2VudAoKVXNlIHRoZSB0
b3AgYml0IG9mIGEtPmNwdWlkIHRvIGV4cHJlc3MgaW52ZXJ0ZWQgcG9sYXJp
dHkuICBUaGlzIHJlcXVpcmVzCnN0cmlwcGluZyB0aGUgdG9wIGJpdCBiYWNr
IG91dCB3aGVuIHBlcmZvcm1pbmcgdGhlIHNhbml0eSBjaGVja3MuCgpEZXNw
aXRlIG9ubHkgYmVpbmcgdXNlZCBvbmNlLCBjcmVhdGUgYSByZXBsYWNlIGJv
b2xlYW4gdG8gZXhwcmVzcyB0aGUgZGVjaXNpb24KbW9yZSBjbGVhcmx5IGlu
IF9hcHBseV9hbHRlcm5hdGl2ZXMoKS4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0t
Z2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94
ODYvYWx0ZXJuYXRpdmUuYwppbmRleCA0M2IwMDk4ODhjMDIuLjRkMWJiZTcz
MTNmZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMK
KysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTIyOCw2ICsy
MjgsOCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBseV9h
bHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAgICAg
IHVpbnQ4X3QgKnJlcGwgPSBBTFRfUkVQTF9QVFIoYSk7CiAgICAgICAgIHVp
bnQ4X3QgYnVmW01BWF9QQVRDSF9MRU5dOwogICAgICAgICB1bnNpZ25lZCBp
bnQgdG90YWxfbGVuID0gYS0+b3JpZ19sZW4gKyBhLT5wYWRfbGVuOworICAg
ICAgICB1bnNpZ25lZCBpbnQgZmVhdCA9IGEtPmNwdWlkICYgfkFMVF9GTEFH
X05PVDsKKyAgICAgICAgYm9vbCBpbnYgPSBhLT5jcHVpZCAmIEFMVF9GTEFH
X05PVCwgcmVwbGFjZTsKIAogICAgICAgICBpZiAoIGEtPnJlcGxfbGVuID4g
dG90YWxfbGVuICkKICAgICAgICAgewpAQCAtMjQ1LDExICsyNDcsMTEgQEAg
c3RhdGljIGludCBpbml0X29yX2xpdmVwYXRjaCBfYXBwbHlfYWx0ZXJuYXRp
dmVzKHN0cnVjdCBhbHRfaW5zdHIgKnN0YXJ0LAogICAgICAgICAgICAgcmV0
dXJuIC1FTk9TUEM7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAoIGEtPmNw
dWlkID49IE5DQVBJTlRTICogMzIgKQorICAgICAgICBpZiAoIGZlYXQgPj0g
TkNBUElOVFMgKiAzMiApCiAgICAgICAgIHsKICAgICAgICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUgogICAgICAgICAgICAgICAgICAgICJBbHQgZm9yICVw
cywgZmVhdHVyZSAlI3ggb3V0c2lkZSBvZiBmZWF0dXJlc2V0IHJhbmdlICUj
eFxuIiwKLSAgICAgICAgICAgICAgICAgICBBTFRfT1JJR19QVFIoYSksIGEt
PmNwdWlkLCBOQ0FQSU5UUyAqIDMyKTsKKyAgICAgICAgICAgICAgICAgICBB
TFRfT1JJR19QVFIoYSksIGZlYXQsIE5DQVBJTlRTICogMzIpOwogICAgICAg
ICAgICAgcmV0dXJuIC1FUkFOR0U7CiAgICAgICAgIH0KIApAQCAtMjcxLDgg
KzI3MywxNCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAg
ICAgIGlmICggYS0+cHJpdiApCiAgICAgICAgICAgICBjb250aW51ZTsKIAor
ICAgICAgICAvKgorICAgICAgICAgKiBTaG91bGQgYSByZXBsYWNlbWVudCBi
ZSBwZXJmb3JtZWQ/ICBNb3N0IHJlcGxhY2VtZW50cyBoYXZlIHBvc2l0aXZl
CisgICAgICAgICAqIHBvbGFyaXR5LCBidXQgd2Ugc3VwcG9ydCBuZWdhdGl2
ZSBwb2xhcml0eSB0b28uCisgICAgICAgICAqLworICAgICAgICByZXBsYWNl
ID0gYm9vdF9jcHVfaGFzKGZlYXQpIF4gaW52OworCiAgICAgICAgIC8qIElm
IHRoZXJlIGlzIG5vIHJlcGxhY2VtZW50IHRvIG1ha2UsIHNlZSBhYm91dCBv
cHRpbWlzaW5nIHRoZSBub3BzLiAqLwotICAgICAgICBpZiAoICFib290X2Nw
dV9oYXMoYS0+Y3B1aWQpICkKKyAgICAgICAgaWYgKCAhcmVwbGFjZSApCiAg
ICAgICAgIHsKICAgICAgICAgICAgIC8qIE9yaWdpbiBzaXRlIHNpdGUgYWxy
ZWFkeSB0b3VjaGVkPyAgRG9uJ3Qgbm9wIGFueXRoaW5nLiAqLwogICAgICAg
ICAgICAgaWYgKCBiYXNlLT5wcml2ICkKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS1hc20uaCBiL3hlbi9hcmNo
L3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS1hc20uaAppbmRleCAyMmRh
OWY4OWYxNWEuLjNlYjBmNGU4YTAyYSAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLWFzbS5oCisrKyBiL3hlbi9h
cmNoL3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS1hc20uaApAQCAtMTIs
NyArMTIsNyBAQAogICogaW5zdHJ1Y3Rpb24uIFNlZSBhcHBseV9hbHRlcm5h
dGl2ZXMoKS4KICAqLwogLm1hY3JvIGFsdGluc3RydWN0aW9uX2VudHJ5IG9y
aWcsIHJlcGwsIGZlYXR1cmUsIG9yaWdfbGVuLCByZXBsX2xlbiwgcGFkX2xl
bgotICAgIC5pZiBcZmVhdHVyZSA+PSBOQ0FQSU5UUyAqIDMyCisgICAgLmlm
ICgoXGZlYXR1cmUpICYgfkFMVF9GTEFHX05PVCkgPj0gTkNBUElOVFMgKiAz
MgogICAgICAgICAuZXJyb3IgImFsdGVybmF0aXZlIGZlYXR1cmUgb3V0c2lk
ZSBvZiBmZWF0dXJlc2V0IHJhbmdlIgogICAgIC5lbmRpZgogICAgIC5sb25n
IFxvcmlnIC0gLgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v
YWx0ZXJuYXRpdmUuaAppbmRleCAyOWMzZDcyNGIwN2YuLmI5ZWE0OWJkMWMz
ZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKQEAgLTEsNiArMSwxMyBAQAogI2lmbmRlZiBfX1g4Nl9BTFRF
Uk5BVElWRV9IX18KICNkZWZpbmUgX19YODZfQUxURVJOQVRJVkVfSF9fCiAK
Ky8qCisgKiBDb21tb24gdG8gYm90aCBDIGFuZCBBU00uICBFeHByZXNzIGEg
cmVwbGFjZW1lbnQgd2hlbiBhIGZlYXR1cmUgaXMgbm90CisgKiBhdmFpbGFi
bGUuCisgKi8KKyNkZWZpbmUgQUxUX0ZMQUdfTk9UICgxIDw8IDE1KQorI2Rl
ZmluZSBBTFRfTk9UKHgpIChBTFRfRkxBR19OT1QgfCAoeCkpCisKICNpZmRl
ZiBfX0FTU0VNQkxZX18KICNpbmNsdWRlIDxhc20vYWx0ZXJuYXRpdmUtYXNt
Lmg+CiAjZWxzZQpAQCAtMTQsNyArMjEsNyBAQAogc3RydWN0IF9fcGFja2Vk
IGFsdF9pbnN0ciB7CiAgICAgaW50MzJfdCAgb3JpZ19vZmZzZXQ7ICAgLyog
b3JpZ2luYWwgaW5zdHJ1Y3Rpb24gKi8KICAgICBpbnQzMl90ICByZXBsX29m
ZnNldDsgICAvKiBvZmZzZXQgdG8gcmVwbGFjZW1lbnQgaW5zdHJ1Y3Rpb24g
Ki8KLSAgICB1aW50MTZfdCBjcHVpZDsgICAgICAgICAvKiBjcHVpZCBiaXQg
c2V0IGZvciByZXBsYWNlbWVudCAqLworICAgIHVpbnQxNl90IGNwdWlkOyAg
ICAgICAgIC8qIGNwdWlkIGJpdCBzZXQgZm9yIHJlcGxhY2VtZW50ICh0b3Ag
Yml0IGlzIHBvbGFyaXR5KSAqLwogICAgIHVpbnQ4X3QgIG9yaWdfbGVuOyAg
ICAgIC8qIGxlbmd0aCBvZiBvcmlnaW5hbCBpbnN0cnVjdGlvbiAqLwogICAg
IHVpbnQ4X3QgIHJlcGxfbGVuOyAgICAgIC8qIGxlbmd0aCBvZiBuZXcgaW5z
dHJ1Y3Rpb24gKi8KICAgICB1aW50OF90ICBwYWRfbGVuOyAgICAgICAvKiBs
ZW5ndGggb2YgYnVpbGQtdGltZSBwYWRkaW5nICovCkBAIC02MSw3ICs2OCw3
IEBAIGV4dGVybiB2b2lkIGFsdGVybmF0aXZlX2luc3RydWN0aW9ucyh2b2lk
KTsKICAgICAgICAgICAgICAgICAgICAgYWx0X3JlcGxfbGVuKG4yKSkgIi0i
IGFsdF9vcmlnX2xlbikKIAogI2RlZmluZSBBTFRJTlNUUl9FTlRSWShmZWF0
dXJlLCBudW0pICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
XAotICAgICAgICAiIC5pZiAiIFNUUihmZWF0dXJlKSAiID49ICIgU1RSKE5D
QVBJTlRTICogMzIpICJcbiIgICAgICAgICAgICAgXAorICAgICAgICAiIC5p
ZiAoIiBTVFIoZmVhdHVyZSAmIH5BTFRfRkxBR19OT1QpICIpID49ICIgU1RS
KE5DQVBJTlRTICogMzIpICJcbiIgXAogICAgICAgICAiIC5lcnJvciBcImFs
dGVybmF0aXZlIGZlYXR1cmUgb3V0c2lkZSBvZiBmZWF0dXJlc2V0IHJhbmdl
XCJcbiIgXAogICAgICAgICAiIC5lbmRpZlxuIiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAg
ICAiIC5sb25nIC5MWEVOJT1fb3JpZ19zIC0gLlxuIiAgICAgICAgICAgICAv
KiBsYWJlbCAgICAgICAgICAgKi8gXAoK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-02.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-02.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2d1ZXN0OiBSZW1vdmUgdXNlIG9mIHRoZSBYZW4g
aHlwZXJjYWxsX3BhZ2UKCkluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCBJ
VFMsIFhlbiBuZWVkcyB0byBzdGFydCB1c2luZyByZXR1cm4gdGh1bmtzLgpU
aGVyZWZvcmUgdGhlIGFkdmljZSBpbiBYU0EtNDY2IGJlY29tZXMgcmVsZXZh
bnQsIGFuZCB0aGUgaHlwZXJjYWxsX3BhZ2UgbmVlZHMKdG8gYmUgcmVtb3Zl
ZC4KCkltcGxlbWVudCBlYXJseV9oeXBlcmNhbGwoKSwgd2l0aCBpbmZyYXN0
cnVjdHVyZSB0byBmaWd1cmUgb3V0IHRoZSBjb3JyZWN0Cmluc3RydWN0aW9u
IG9uIGZpcnN0IHVzZS4gIFVzZSBBTFRFUk5BVElWRSgpcyB0byByZXN1bHQg
aW4gaW5saW5lIGh5cGVyY2FsbHMsCmluY2x1ZGluZyB0aGUgQUxUX05PVCgp
IGZvcm0gc28gd2Ugb25seSBuZWVkIGEgc2luZ2xlIHN5bnRoZXRpYyBmZWF0
dXJlIGJpdC4KCk5vIG92ZXJhbGwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0IG9m
IFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTogQW5k
cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3
ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9ndWVzdC94ZW4vTWFrZWZp
bGUgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCmluZGV4IDI2
ZmI0YjEwMDdjMC4uOGIzMjUwYWE4ODg2IDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCisrKyBiL3hlbi9hcmNoL3g4Ni9n
dWVzdC94ZW4vTWFrZWZpbGUKQEAgLTEsNCArMSw0IEBACi1vYmoteSArPSBo
eXBlcmNhbGxfcGFnZS5vCitvYmotYmluLXkgKz0gaHlwZXJjYWxsLmluaXQu
bwogb2JqLXkgKz0geGVuLm8KIAogb2JqLWJpbi0kKENPTkZJR19QVkhfR1VF
U1QpICs9IHB2aC1ib290LmluaXQubwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGwuUyBiL3hlbi9hcmNoL3g4Ni9ndWVz
dC94ZW4vaHlwZXJjYWxsLlMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg
MDAwMDAwMDAwMDAwLi4wNWU0Mjk3OTRjYzQKLS0tIC9kZXYvbnVsbAorKysg
Yi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbC5TCkBAIC0wLDAg
KzEsNTAgQEAKKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4w
LW9yLWxhdGVyICovCisKKyNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPgorCisg
ICAgICAgIC5zZWN0aW9uIC5pbml0LnRleHQsICJheCIsIEBwcm9nYml0cwor
CisgICAgICAgIC8qCisgICAgICAgICAqIFVzZWQgZHVyaW5nIGVhcmx5IGJv
b3QsIGJlZm9yZSBhbHRlcm5hdGl2ZXMgaGF2ZSBydW4gYW5kIGlubGluZWQK
KyAgICAgICAgICogdGhlIGFwcHJvcHJpYXRlIGluc3RydWN0aW9uLiAgQ2Fs
bGVkIHVzaW5nIHRoZSBoeXBlcmNhbGwgQUJJLgorICAgICAgICAgKi8KK0ZV
TkMoZWFybHlfaHlwZXJjYWxsKQorICAgICAgICBjbXBiICAgICQwLCBlYXJs
eV9oeXBlcmNhbGxfaW5zbiglcmlwKQorICAgICAgICBqbCAgICAgIC5MX3Nl
dHVwCisgICAgICAgIGplICAgICAgMWYKKworICAgICAgICB2bW1jYWxsCisg
ICAgICAgIHJldAorCisxOiAgICAgIHZtY2FsbAorICAgICAgICByZXQKKwor
Lkxfc2V0dXA6CisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gc2V0dGlu
ZyB1cCB0aGUgZmlyc3QgdGltZSBhcm91bmQsIGFsbCByZWdpc3RlcnMgbmVl
ZAorICAgICAgICAgKiBwcmVzZXJ2aW5nLiAgU2F2ZSB0aGUgbm9uLWNhbGxl
ZS1zYXZlZCBvbmVzLgorICAgICAgICAgKi8KKyAgICAgICAgcHVzaCAgICAl
cjExCisgICAgICAgIHB1c2ggICAgJXIxMAorICAgICAgICBwdXNoICAgICVy
OQorICAgICAgICBwdXNoICAgICVyOAorICAgICAgICBwdXNoICAgICVyZGkK
KyAgICAgICAgcHVzaCAgICAlcnNpCisgICAgICAgIHB1c2ggICAgJXJkeAor
ICAgICAgICBwdXNoICAgICVyY3gKKyAgICAgICAgcHVzaCAgICAlcmF4CisK
KyAgICAgICAgY2FsbCAgICBlYXJseV9oeXBlcmNhbGxfc2V0dXAKKworICAg
ICAgICBwb3AgICAgICVyYXgKKyAgICAgICAgcG9wICAgICAlcmN4CisgICAg
ICAgIHBvcCAgICAgJXJkeAorICAgICAgICBwb3AgICAgICVyc2kKKyAgICAg
ICAgcG9wICAgICAlcmRpCisgICAgICAgIHBvcCAgICAgJXI4CisgICAgICAg
IHBvcCAgICAgJXI5CisgICAgICAgIHBvcCAgICAgJXIxMAorICAgICAgICBw
b3AgICAgICVyMTEKKworICAgICAgICBqbXAgICAgIGVhcmx5X2h5cGVyY2Fs
bAorRU5EKGVhcmx5X2h5cGVyY2FsbCkKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUyBiL3hlbi9hcmNoL3g4
Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUwpkZWxldGVkIGZpbGUgbW9k
ZSAxMDA2NDQKaW5kZXggN2FiNTVmYzFmNmU2Li4wMDAwMDAwMDAwMDAKLS0t
IGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGxfcGFnZS5TCisr
KyAvZGV2L251bGwKQEAgLTEsNzYgKzAsMCBAQAotI2luY2x1ZGUgPGFzbS9w
YWdlLmg+Ci0jaW5jbHVkZSA8YXNtL2FzbV9kZWZucy5oPgotI2luY2x1ZGUg
PHB1YmxpYy94ZW4uaD4KLQotICAgICAgICAuc2VjdGlvbiAiLnRleHQucGFn
ZV9hbGlnbmVkIiwgImF4IiwgQHByb2diaXRzCi0KLURBVEEoaHlwZXJjYWxs
X3BhZ2UsIFBBR0VfU0laRSkKLSAgICAgICAgIC8qIFBvaXNvbmVkIHdpdGgg
YHJldGAgZm9yIHNhZmV0eSBiZWZvcmUgaHlwZXJjYWxscyBhcmUgc2V0IHVw
LiAqLwotICAgICAgICAuZmlsbCBQQUdFX1NJWkUsIDEsIDB4YzMKLUVORCho
eXBlcmNhbGxfcGFnZSkKLQotLyoKLSAqIElkZW50aWZ5IGEgc3BlY2lmaWMg
aHlwZXJjYWxsIGluIHRoZSBoeXBlcmNhbGwgcGFnZQotICogQHBhcmFtIG5h
bWUgSHlwZXJjYWxsIG5hbWUuCi0gKi8KLSNkZWZpbmUgREVDTEFSRV9IWVBF
UkNBTEwobmFtZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAotICAgICAgICAuZ2xvYmwgSFlQRVJDQUxMXyAj
IyBuYW1lOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBcCi0gICAgICAgIC50eXBlICBIWVBFUkNBTExfICMjIG5hbWUs
IFNUVF9GVU5DOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFwKLSAgICAgICAgLnNpemUgIEhZUEVSQ0FMTF8gIyMgbmFtZSwgMzI7ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAotICAg
ICAgICAuc2V0ICAgSFlQRVJDQUxMXyAjIyBuYW1lLCBoeXBlcmNhbGxfcGFn
ZSArIF9fSFlQRVJWSVNPUl8gIyMgbmFtZSAqIDMyCi0KLURFQ0xBUkVfSFlQ
RVJDQUxMKHNldF90cmFwX3RhYmxlKQotREVDTEFSRV9IWVBFUkNBTEwobW11
X3VwZGF0ZSkKLURFQ0xBUkVfSFlQRVJDQUxMKHNldF9nZHQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChzdGFja19zd2l0Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChz
ZXRfY2FsbGJhY2tzKQotREVDTEFSRV9IWVBFUkNBTEwoZnB1X3Rhc2tzd2l0
Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChzY2hlZF9vcF9jb21wYXQpCi1ERUNM
QVJFX0hZUEVSQ0FMTChwbGF0Zm9ybV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxM
KHNldF9kZWJ1Z3JlZykKLURFQ0xBUkVfSFlQRVJDQUxMKGdldF9kZWJ1Z3Jl
ZykKLURFQ0xBUkVfSFlQRVJDQUxMKHVwZGF0ZV9kZXNjcmlwdG9yKQotREVD
TEFSRV9IWVBFUkNBTEwobWVtb3J5X29wKQotREVDTEFSRV9IWVBFUkNBTEwo
bXVsdGljYWxsKQotREVDTEFSRV9IWVBFUkNBTEwodXBkYXRlX3ZhX21hcHBp
bmcpCi1ERUNMQVJFX0hZUEVSQ0FMTChzZXRfdGltZXJfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTChldmVudF9jaGFubmVsX29wX2NvbXBhdCkKLURFQ0xBUkVf
SFlQRVJDQUxMKHhlbl92ZXJzaW9uKQotREVDTEFSRV9IWVBFUkNBTEwoY29u
c29sZV9pbykKLURFQ0xBUkVfSFlQRVJDQUxMKHBoeXNkZXZfb3BfY29tcGF0
KQotREVDTEFSRV9IWVBFUkNBTEwoZ3JhbnRfdGFibGVfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh2bV9hc3Npc3QpCi1ERUNMQVJFX0hZUEVSQ0FMTCh1cGRh
dGVfdmFfbWFwcGluZ19vdGhlcmRvbWFpbikKLURFQ0xBUkVfSFlQRVJDQUxM
KGlyZXQpCi1ERUNMQVJFX0hZUEVSQ0FMTCh2Y3B1X29wKQotREVDTEFSRV9I
WVBFUkNBTEwoc2V0X3NlZ21lbnRfYmFzZSkKLURFQ0xBUkVfSFlQRVJDQUxM
KG1tdWV4dF9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHhzbV9vcCkKLURFQ0xB
UkVfSFlQRVJDQUxMKG5taV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHNjaGVk
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoY2FsbGJhY2tfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh4ZW5vcHJvZl9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKGV2
ZW50X2NoYW5uZWxfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChwaHlzZGV2X29w
KQotREVDTEFSRV9IWVBFUkNBTEwoaHZtX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoc3lzY3RsKQotREVDTEFSRV9IWVBFUkNBTEwoZG9tY3RsKQotREVDTEFS
RV9IWVBFUkNBTEwoa2V4ZWNfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmdv
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoeGVucG11X29wKQotCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzEp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzIpCi1ERUNMQVJFX0hZUEVSQ0FM
TChhcmNoXzMpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzUpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzYp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzcpCi0KLS8qCi0gKiBMb2NhbCB2
YXJpYWJsZXM6Ci0gKiB0YWItd2lkdGg6IDgKLSAqIGluZGVudC10YWJzLW1v
ZGU6IG5pbAotICogRW5kOgotICovCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvZ3Vlc3QveGVuL3hlbi5jIGIveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94
ZW4uYwppbmRleCBjMTdmNWM0NDdhYjYuLjVjOWYzOTNjNzUxNCAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94ZW4uYworKysgYi94ZW4v
YXJjaC94ODYvZ3Vlc3QveGVuL3hlbi5jCkBAIC0yNiw3ICsyNiw2IEBACiBi
b29sIF9fcmVhZF9tb3N0bHkgeGVuX2d1ZXN0OwogCiB1aW50MzJfdCBfX3Jl
YWRfbW9zdGx5IHhlbl9jcHVpZF9iYXNlOwotZXh0ZXJuIGNoYXIgaHlwZXJj
YWxsX3BhZ2VbXTsKIHN0YXRpYyBzdHJ1Y3QgcmFuZ2VzZXQgKm1lbTsKIAog
REVGSU5FX1BFUl9DUFUodW5zaWduZWQgaW50LCB2Y3B1X2lkKTsKQEAgLTM1
LDYgKzM0LDUwIEBAIHN0YXRpYyBzdHJ1Y3QgdmNwdV9pbmZvICp2Y3B1X2lu
Zm87CiBzdGF0aWMgdW5zaWduZWQgbG9uZyB2Y3B1X2luZm9fbWFwcGVkW0JJ
VFNfVE9fTE9OR1MoTlJfQ1BVUyldOwogREVGSU5FX1BFUl9DUFUoc3RydWN0
IHZjcHVfaW5mbyAqLCB2Y3B1X2luZm8pOwogCisvKgorICogV2hpY2ggaW5z
dHJ1Y3Rpb24gdG8gdXNlIGZvciBlYXJseSBoeXBlcmNhbGxzOgorICogICA8
IDAgc2V0dXAKKyAqICAgICAwIHZtY2FsbAorICogICA+IDAgdm1tY2FsbAor
ICovCitpbnQ4X3QgX19pbml0ZGF0YSBlYXJseV9oeXBlcmNhbGxfaW5zbiA9
IC0xOworCisvKgorICogQ2FsbGVkIG9uY2UgZHVyaW5nIHRoZSBmaXJzdCBo
eXBlcmNhbGwgdG8gZmlndXJlIG91dCB3aGljaCBpbnN0cnVjdGlvbiB0bwor
ICogdXNlLiAgRXJyb3IgaGFuZGxpbmcgb3B0aW9ucyBhcmUgbGltaXRlZC4K
KyAqLwordm9pZCBhc21saW5rYWdlIF9faW5pdCBlYXJseV9oeXBlcmNhbGxf
c2V0dXAodm9pZCkKK3sKKyAgICBCVUdfT04oZWFybHlfaHlwZXJjYWxsX2lu
c24gIT0gLTEpOworCisgICAgaWYgKCAhYm9vdF9jcHVfZGF0YS54ODZfdmVu
ZG9yICkKKyAgICB7CisgICAgICAgIHVuc2lnbmVkIGludCBlYXgsIGVieCwg
ZWN4LCBlZHg7CisKKyAgICAgICAgY3B1aWQoMCwgJmVheCwgJmVieCwgJmVj
eCwgJmVkeCk7CisKKyAgICAgICAgYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ID0geDg2X2NwdWlkX2xvb2t1cF92ZW5kb3IoZWJ4LCBlY3gsIGVkeCk7Cisg
ICAgfQorCisgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ICkKKyAgICB7CisgICAgY2FzZSBYODZfVkVORE9SX0lOVEVMOgorICAgIGNh
c2UgWDg2X1ZFTkRPUl9DRU5UQVVSOgorICAgIGNhc2UgWDg2X1ZFTkRPUl9T
SEFOR0hBSToKKyAgICAgICAgZWFybHlfaHlwZXJjYWxsX2luc24gPSAwOwor
ICAgICAgICBzZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpOworICAgICAgICBicmVhazsKKworICAgIGNhc2UgWDg2X1ZFTkRP
Ul9BTUQ6CisgICAgY2FzZSBYODZfVkVORE9SX0hZR09OOgorICAgICAgICBl
YXJseV9oeXBlcmNhbGxfaW5zbiA9IDE7CisgICAgICAgIGJyZWFrOworCisg
ICAgZGVmYXVsdDoKKyAgICAgICAgQlVHKCk7CisgICAgfQorfQorCiBzdGF0
aWMgdm9pZCBfX2luaXQgZmluZF94ZW5fbGVhdmVzKHZvaWQpCiB7CiAgICAg
dWludDMyX3QgZWF4LCBlYngsIGVjeCwgZWR4LCBiYXNlOwpAQCAtMzM3LDkg
KzM4MCw2IEBAIGNvbnN0IHN0cnVjdCBoeXBlcnZpc29yX29wcyAqX19pbml0
IHhnX3Byb2JlKHZvaWQpCiAgICAgaWYgKCAheGVuX2NwdWlkX2Jhc2UgKQog
ICAgICAgICByZXR1cm4gTlVMTDsKIAotICAgIC8qIEZpbGwgdGhlIGh5cGVy
Y2FsbCBwYWdlLiAqLwotICAgIHdybXNybChjcHVpZF9lYngoeGVuX2NwdWlk
X2Jhc2UgKyAyKSwgX19wYShoeXBlcmNhbGxfcGFnZSkpOwotCiAgICAgeGVu
X2d1ZXN0ID0gdHJ1ZTsKIAogICAgIHJldHVybiAmb3BzOwpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmggYi94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vY3B1ZmVhdHVyZXMuaAppbmRleCBi
YTNkZjE3NGI3NmUuLjllM2VkMjFjMDI2ZCAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKKysrIGIveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKQEAgLTQyLDYgKzQy
LDcgQEAgWEVOX0NQVUZFQVRVUkUoWEVOX1NIU1RLLCAgICAgICAgIFg4Nl9T
WU5USCgyNikpIC8qIFhlbiB1c2VzIENFVCBTaGFkb3cgU3RhY2tzICoKIFhF
Tl9DUFVGRUFUVVJFKFhFTl9JQlQsICAgICAgICAgICBYODZfU1lOVEgoMjcp
KSAvKiBYZW4gdXNlcyBDRVQgSW5kaXJlY3QgQnJhbmNoIFRyYWNraW5nICov
CiBYRU5fQ1BVRkVBVFVSRShJQlBCX0VOVFJZX1BWLCAgICAgWDg2X1NZTlRI
KDI4KSkgLyogTVNSX1BSRURfQ01EIHVzZWQgYnkgWGVuIGZvciBQViAqLwog
WEVOX0NQVUZFQVRVUkUoSUJQQl9FTlRSWV9IVk0sICAgIFg4Nl9TWU5USCgy
OSkpIC8qIE1TUl9QUkVEX0NNRCB1c2VkIGJ5IFhlbiBmb3IgSFZNICovCitY
RU5fQ1BVRkVBVFVSRShVU0VfVk1DQUxMLCAgICAgICAgWDg2X1NZTlRIKDMw
KSkgLyogVXNlIFZNQ0FMTCBpbnN0ZWFkIG9mIFZNTUNBTEwgKi8KIAogLyog
QnVnIHdvcmRzIGZvbGxvdyB0aGUgc3ludGhldGljIHdvcmRzLiAqLwogI2Rl
ZmluZSBYODZfTlJfQlVHIDEKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaCBiL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaAppbmRleCA2NjViNDcyZDA1
YWMuLjk2MDA0ZGVjOTkwOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2d1ZXN0L3hlbi1oY2FsbC5oCisrKyBiL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaApAQCAtMzAsOSArMzAs
MTEgQEAKICAgICAoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICgg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKLSAgICAgICAgICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNb
b2Zmc2V0XSIgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAg
ICAgIEFMVEVSTkFUSVZFXzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgInZtbWNhbGwiLCBBTFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwp
LCAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4
Nl9GRUFUVVJFX1VTRV9WTUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgIDogIj1hIiAocmVzKSwgIj1EIiAodG1wX18pIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgIDogW29mZnNldF0g
ImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2FsbCksICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgICAgIjEiICgobG9uZykoYTEpKSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgKHR5cGUpcmVzOyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKQEAgLTQyLDEw
ICs0NCwxMiBAQAogICAgICh7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICBsb25nIHJlcywgdG1wX187ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBhc20gdm9sYXRp
bGUgKCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgImNhbGwgaHlwZXJjYWxsX3BhZ2Ug
KyAlY1tvZmZzZXRdIiAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgQUxURVJOQVRJVkVfMigiY2FsbCBlYXJseV9oeXBlcmNhbGwi
LCAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAidm1tY2FsbCIsIEFMVF9OT1QoWDg2X0ZFQVRVUkVfVVNFX1ZN
Q0FMTCksICAgXAorICAgICAgICAgICAgICAgICAgICAgICAgICAidm1jYWxs
IiwgWDg2X0ZFQVRVUkVfVVNFX1ZNQ0FMTCkgICAgICAgICAgICAgXAogICAg
ICAgICAgICAgOiAiPWEiIChyZXMpLCAiPUQiICh0bXBfXyksICI9UyIgKHRt
cF9fKSAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICBBU01f
Q0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgOiBbb2Zmc2V0XSAiaSIgKGhjYWxs
ICogMzIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgOiAiMCIgKGhjYWxsKSwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAiMSIg
KChsb25nKShhMSkpLCAiMiIgKChsb25nKShhMikpICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgICAgICAgICAgOiAibWVtb3J5IiApOyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICAodHlwZSlyZXM7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXApAQCAtNTUsMTAgKzU5LDEyIEBA
CiAgICAgKHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGxvbmcg
cmVzLCB0bXBfXzsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICAiY2FsbCBoeXBlcmNhbGxfcGFnZSArICVjW29mZnNl
dF0iICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICBB
TFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5cGVyY2FsbCIsICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2
bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSwgICBc
CisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2bWNhbGwiLCBYODZfRkVB
VFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAgICBcCiAgICAgICAgICAgICA6
ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSwgIj1TIiAodG1wX18pLCAiPWQi
ICh0bXBfXykgICAgICBcCiAgICAgICAgICAgICAgIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiksICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICA6
ICIwIiAoaGNhbGwpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcpKGEx
KSksICIyIiAoKGxvbmcpKGEyKSksICIzIiAoKGxvbmcpKGEzKSkgICAgICBc
CiAgICAgICAgICAgICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICh0eXBl
KXJlczsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCkBAIC02OSwxMCArNzUsMTIgQEAKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgcmVnaXN0ZXIgbG9uZyBf
YTQgYXNtICgicjEwIikgPSAoKGxvbmcpKGE0KSk7ICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICggICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNbb2Zmc2V0XSIgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIEFMVEVSTkFUSVZF
XzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtbWNhbGwiLCBB
TFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwpLCAgIFwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIj1hIiAocmVz
KSwgIj1EIiAodG1wX18pLCAiPVMiICh0bXBfXyksICI9ZCIgKHRtcF9fKSwg
ICAgIFwKICAgICAgICAgICAgICAgIj0mciIgKHRtcF9fKSBBU01fQ0FMTF9D
T05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgIDogW29mZnNldF0gImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2Fs
bCksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgICAgICAgIjEiICgobG9uZykoYTEpKSwgIjIiICgo
bG9uZykoYTIpKSwgIjMiICgobG9uZykoYTMpKSwgICAgIFwKICAgICAgICAg
ICAgICAgIjQiIChfYTQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-03.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-03.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IChNaXMpYWxpZ24gX194ODZfaW5kaXJlY3RfdGh1bmtf
KiB0byBtaXRpZ2F0ZSBJVFMKClRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRp
cmVjdApicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hl
biBpbiB0aGUgZmlyc3QgaGFsZiBvZiBhIGNhY2hlbGluZS4KCkFycmFuZ2Ug
Zm9yIF9feDg2X2luZGlyZWN0X3RodW5rXyogdG8gYWx3YXlzIGJlIGluIHRo
ZSBzZWNvbmQgaGFsZi4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDY5IC8gQ1ZF
LTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TCmluZGV4IGZkNTQ5M2MyMmIxNi4uYzRiOTc4ZDY3Yjhl
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwor
KysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMTEsNiAr
MTEsMTAgQEAKIAogI2luY2x1ZGUgPGFzbS9hc21fZGVmbnMuaD4KIAorLyog
QWxpZ25tZW50IGlzIGRlYWx0IHdpdGggZXhwbGljaXRseSBoZXJlOyBvdmVy
cmlkZSB0aGUgcmVzcGVjdGl2ZSBtYWNyby4gKi8KKyN1bmRlZiBTWU1fQUxJ
R04KKyNkZWZpbmUgU1lNX0FMSUdOKGFsaWduLi4uKQorCiAubWFjcm8gSU5E
X1RIVU5LX1JFVFBPTElORSByZWc6cmVxCiAgICAgICAgIGNhbGwgMWYKICAg
ICAgICAgaW50MwpAQCAtMzUsNiArMzksMTYgQEAKIC5tYWNybyBHRU5fSU5E
SVJFQ1RfVEhVTksgcmVnOnJlcQogICAgICAgICAuc2VjdGlvbiAudGV4dC5f
X3g4Nl9pbmRpcmVjdF90aHVua19ccmVnLCAiYXgiLCBAcHJvZ2JpdHMKIAor
ICAgICAgICAvKgorICAgICAgICAgKiBUaGUgSW5kaXJlY3QgVGFyZ2V0IFNl
bGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5zIHRoYXQK
KyAgICAgICAgICogaW5kaXJlY3QgYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRz
KSBhcmUgdW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0CisgICAgICAgICAqIGhh
bGYgb2YgYSBjYWNoZWxpbmUuICBBcnJhbmdlIGZvciB0aGVtIHRvIGJlIGlu
IHRoZSBzZWNvbmQgaGFsZi4KKyAgICAgICAgICoKKyAgICAgICAgICogQWxp
Z24gdG8gNjQsIHRoZW4gc2tpcCAzMi4KKyAgICAgICAgICovCisgICAgICAg
IC5iYWxpZ24gNjQKKyAgICAgICAgLmZpbGwgMzIsIDEsIDB4Y2MKKwogRlVO
QyhfX3g4Nl9pbmRpcmVjdF90aHVua19ccmVnKQogICAgICAgICBBTFRFUk5B
VElWRV8yIF9fc3RyaW5naWZ5KElORF9USFVOS19SRVRQT0xJTkUgXHJlZyks
ICAgICAgICAgICAgICBcCiAgICAgICAgIF9fc3RyaW5naWZ5KElORF9USFVO
S19MRkVOQ0UgXHJlZyksIFg4Nl9GRUFUVVJFX0lORF9USFVOS19MRkVOQ0Us
IFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-01.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-01.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2FsdGVybmF0aXZlOiBTdXBwb3J0IHJlcGxhY2Vt
ZW50cyB3aGVuIGEgZmVhdHVyZSBpcyBub3QgcHJlc2VudAoKVXNlIHRoZSB0
b3AgYml0IG9mIGEtPmNwdWlkIHRvIGV4cHJlc3MgaW52ZXJ0ZWQgcG9sYXJp
dHkuICBUaGlzIHJlcXVpcmVzCnN0cmlwcGluZyB0aGUgdG9wIGJpdCBiYWNr
IG91dCB3aGVuIHBlcmZvcm1pbmcgdGhlIHNhbml0eSBjaGVja3MuCgpEZXNw
aXRlIG9ubHkgYmVpbmcgdXNlZCBvbmNlLCBjcmVhdGUgYSByZXBsYWNlIGJv
b2xlYW4gdG8gZXhwcmVzcyB0aGUgZGVjaXNpb24KbW9yZSBjbGVhcmx5IGlu
IF9hcHBseV9hbHRlcm5hdGl2ZXMoKS4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0t
Z2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94
ODYvYWx0ZXJuYXRpdmUuYwppbmRleCA4MzU2NDE0YmU3MDEuLjZlZWU2ZTUw
MWFkOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMK
KysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTIwOSwxMCAr
MjA5LDEyIEBAIHN0YXRpYyB2b2lkIGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAg
ICAgIHVpbnQ4X3QgKnJlcGwgPSBBTFRfUkVQTF9QVFIoYSk7CiAgICAgICAg
IHVpbnQ4X3QgYnVmW01BWF9QQVRDSF9MRU5dOwogICAgICAgICB1bnNpZ25l
ZCBpbnQgdG90YWxfbGVuID0gYS0+b3JpZ19sZW4gKyBhLT5wYWRfbGVuOwor
ICAgICAgICB1bnNpZ25lZCBpbnQgZmVhdCA9IGEtPmNwdWlkICYgfkFMVF9G
TEFHX05PVDsKKyAgICAgICAgYm9vbCBpbnYgPSBhLT5jcHVpZCAmIEFMVF9G
TEFHX05PVCwgcmVwbGFjZTsKIAogICAgICAgICBCVUdfT04oYS0+cmVwbF9s
ZW4gPiB0b3RhbF9sZW4pOwogICAgICAgICBCVUdfT04odG90YWxfbGVuID4g
c2l6ZW9mKGJ1ZikpOwotICAgICAgICBCVUdfT04oYS0+Y3B1aWQgPj0gTkNB
UElOVFMgKiAzMik7CisgICAgICAgIEJVR19PTihmZWF0ID49IE5DQVBJTlRT
ICogMzIpOwogCiAgICAgICAgIC8qCiAgICAgICAgICAqIERldGVjdCBzZXF1
ZW5jZXMgb2YgYWx0X2luc3RyJ3MgcGF0Y2hpbmcgdGhlIHNhbWUgb3JpZ2lu
IHNpdGUsIGFuZApAQCAtMjM1LDggKzIzNywxNCBAQCBzdGF0aWMgdm9pZCBp
bml0X29yX2xpdmVwYXRjaCBfYXBwbHlfYWx0ZXJuYXRpdmVzKHN0cnVjdCBh
bHRfaW5zdHIgKnN0YXJ0LAogICAgICAgICAgICAgY29udGludWU7CiAgICAg
ICAgIH0KIAorICAgICAgICAvKgorICAgICAgICAgKiBTaG91bGQgYSByZXBs
YWNlbWVudCBiZSBwZXJmb3JtZWQ/ICBNb3N0IHJlcGxhY2VtZW50cyBoYXZl
IHBvc2l0aXZlCisgICAgICAgICAqIHBvbGFyaXR5LCBidXQgd2Ugc3VwcG9y
dCBuZWdhdGl2ZSBwb2xhcml0eSB0b28uCisgICAgICAgICAqLworICAgICAg
ICByZXBsYWNlID0gYm9vdF9jcHVfaGFzKGZlYXQpIF4gaW52OworCiAgICAg
ICAgIC8qIElmIHRoZXJlIGlzIG5vIHJlcGxhY2VtZW50IHRvIG1ha2UsIHNl
ZSBhYm91dCBvcHRpbWlzaW5nIHRoZSBub3BzLiAqLwotICAgICAgICBpZiAo
ICFib290X2NwdV9oYXMoYS0+Y3B1aWQpICkKKyAgICAgICAgaWYgKCAhcmVw
bGFjZSApCiAgICAgICAgIHsKICAgICAgICAgICAgIC8qIE9yaWdpbiBzaXRl
IHNpdGUgYWxyZWFkeSB0b3VjaGVkPyAgRG9uJ3Qgbm9wIGFueXRoaW5nLiAq
LwogICAgICAgICAgICAgaWYgKCBiYXNlLT5wcml2ICkKZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmgKaW5kZXggZWU0
Y2JlOTJjYzJiLi4zODhlNTk1Nzg2ZTAgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNo
L3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCisrKyBiL3hlbi9hcmNo
L3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCkBAIC0xLDYgKzEsMTMg
QEAKICNpZm5kZWYgX19YODZfQUxURVJOQVRJVkVfSF9fCiAjZGVmaW5lIF9f
WDg2X0FMVEVSTkFUSVZFX0hfXwogCisvKgorICogQ29tbW9uIHRvIGJvdGgg
QyBhbmQgQVNNLiAgRXhwcmVzcyBhIHJlcGxhY2VtZW50IHdoZW4gYSBmZWF0
dXJlIGlzIG5vdAorICogYXZhaWxhYmxlLgorICovCisjZGVmaW5lIEFMVF9G
TEFHX05PVCAoMSA8PCAxNSkKKyNkZWZpbmUgQUxUX05PVCh4KSAoQUxUX0ZM
QUdfTk9UIHwgKHgpKQorCiAjaWZkZWYgX19BU1NFTUJMWV9fCiAjaW5jbHVk
ZSA8YXNtL2FsdGVybmF0aXZlLWFzbS5oPgogI2Vsc2UKQEAgLTExLDcgKzE4
LDcgQEAKIHN0cnVjdCBfX3BhY2tlZCBhbHRfaW5zdHIgewogICAgIGludDMy
X3QgIG9yaWdfb2Zmc2V0OyAgIC8qIG9yaWdpbmFsIGluc3RydWN0aW9uICov
CiAgICAgaW50MzJfdCAgcmVwbF9vZmZzZXQ7ICAgLyogb2Zmc2V0IHRvIHJl
cGxhY2VtZW50IGluc3RydWN0aW9uICovCi0gICAgdWludDE2X3QgY3B1aWQ7
ICAgICAgICAgLyogY3B1aWQgYml0IHNldCBmb3IgcmVwbGFjZW1lbnQgKi8K
KyAgICB1aW50MTZfdCBjcHVpZDsgICAgICAgICAvKiBjcHVpZCBiaXQgc2V0
IGZvciByZXBsYWNlbWVudCAodG9wIGJpdCBpcyBwb2xhcml0eSkgKi8KICAg
ICB1aW50OF90ICBvcmlnX2xlbjsgICAgICAvKiBsZW5ndGggb2Ygb3JpZ2lu
YWwgaW5zdHJ1Y3Rpb24gKi8KICAgICB1aW50OF90ICByZXBsX2xlbjsgICAg
ICAvKiBsZW5ndGggb2YgbmV3IGluc3RydWN0aW9uICovCiAgICAgdWludDhf
dCAgcGFkX2xlbjsgICAgICAgLyogbGVuZ3RoIG9mIGJ1aWxkLXRpbWUgcGFk
ZGluZyAqLwoK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-02.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-02.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2d1ZXN0OiBSZW1vdmUgdXNlIG9mIHRoZSBYZW4g
aHlwZXJjYWxsX3BhZ2UKCkluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCBJ
VFMsIFhlbiBuZWVkcyB0byBzdGFydCB1c2luZyByZXR1cm4gdGh1bmtzLgpU
aGVyZWZvcmUgdGhlIGFkdmljZSBpbiBYU0EtNDY2IGJlY29tZXMgcmVsZXZh
bnQsIGFuZCB0aGUgaHlwZXJjYWxsX3BhZ2UgbmVlZHMKdG8gYmUgcmVtb3Zl
ZC4KCkltcGxlbWVudCBlYXJseV9oeXBlcmNhbGwoKSwgd2l0aCBpbmZyYXN0
cnVjdHVyZSB0byBmaWd1cmUgb3V0IHRoZSBjb3JyZWN0Cmluc3RydWN0aW9u
IG9uIGZpcnN0IHVzZS4gIFVzZSBBTFRFUk5BVElWRSgpcyB0byByZXN1bHQg
aW4gaW5saW5lIGh5cGVyY2FsbHMsCmluY2x1ZGluZyB0aGUgQUxUX05PVCgp
IGZvcm0gc28gd2Ugb25seSBuZWVkIGEgc2luZ2xlIHN5bnRoZXRpYyBmZWF0
dXJlIGJpdC4KCk5vIG92ZXJhbGwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0IG9m
IFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTogQW5k
cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3
ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9ndWVzdC94ZW4vTWFrZWZp
bGUgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCmluZGV4IDI2
ZmI0YjEwMDdjMC4uOGIzMjUwYWE4ODg2IDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCisrKyBiL3hlbi9hcmNoL3g4Ni9n
dWVzdC94ZW4vTWFrZWZpbGUKQEAgLTEsNCArMSw0IEBACi1vYmoteSArPSBo
eXBlcmNhbGxfcGFnZS5vCitvYmotYmluLXkgKz0gaHlwZXJjYWxsLmluaXQu
bwogb2JqLXkgKz0geGVuLm8KIAogb2JqLWJpbi0kKENPTkZJR19QVkhfR1VF
U1QpICs9IHB2aC1ib290LmluaXQubwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGwuUyBiL3hlbi9hcmNoL3g4Ni9ndWVz
dC94ZW4vaHlwZXJjYWxsLlMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg
MDAwMDAwMDAwMDAwLi40N2FiNjg1Y2Y4NDgKLS0tIC9kZXYvbnVsbAorKysg
Yi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbC5TCkBAIC0wLDAg
KzEsNTIgQEAKKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4w
LW9yLWxhdGVyICovCisKKyNpbmNsdWRlIDxhc20vYXNtX2RlZm5zLmg+CisK
KyAgICAgICAgLnNlY3Rpb24gLmluaXQudGV4dCwgImF4IiwgQHByb2diaXRz
CisKKyAgICAgICAgLyoKKyAgICAgICAgICogVXNlZCBkdXJpbmcgZWFybHkg
Ym9vdCwgYmVmb3JlIGFsdGVybmF0aXZlcyBoYXZlIHJ1biBhbmQgaW5saW5l
ZAorICAgICAgICAgKiB0aGUgYXBwcm9wcmlhdGUgaW5zdHJ1Y3Rpb24uICBD
YWxsZWQgdXNpbmcgdGhlIGh5cGVyY2FsbCBBQkkuCisgICAgICAgICAqLwor
RU5UUlkoZWFybHlfaHlwZXJjYWxsKQorICAgICAgICBjbXBiICAgICQwLCBl
YXJseV9oeXBlcmNhbGxfaW5zbiglcmlwKQorICAgICAgICBqbCAgICAgIC5M
X3NldHVwCisgICAgICAgIGplICAgICAgMWYKKworICAgICAgICB2bW1jYWxs
CisgICAgICAgIHJldAorCisxOiAgICAgIHZtY2FsbAorICAgICAgICByZXQK
KworLkxfc2V0dXA6CisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gc2V0
dGluZyB1cCB0aGUgZmlyc3QgdGltZSBhcm91bmQsIGFsbCByZWdpc3RlcnMg
bmVlZAorICAgICAgICAgKiBwcmVzZXJ2aW5nLiAgU2F2ZSB0aGUgbm9uLWNh
bGxlZS1zYXZlZCBvbmVzLgorICAgICAgICAgKi8KKyAgICAgICAgcHVzaCAg
ICAlcjExCisgICAgICAgIHB1c2ggICAgJXIxMAorICAgICAgICBwdXNoICAg
ICVyOQorICAgICAgICBwdXNoICAgICVyOAorICAgICAgICBwdXNoICAgICVy
ZGkKKyAgICAgICAgcHVzaCAgICAlcnNpCisgICAgICAgIHB1c2ggICAgJXJk
eAorICAgICAgICBwdXNoICAgICVyY3gKKyAgICAgICAgcHVzaCAgICAlcmF4
CisKKyAgICAgICAgY2FsbCAgICBlYXJseV9oeXBlcmNhbGxfc2V0dXAKKwor
ICAgICAgICBwb3AgICAgICVyYXgKKyAgICAgICAgcG9wICAgICAlcmN4Cisg
ICAgICAgIHBvcCAgICAgJXJkeAorICAgICAgICBwb3AgICAgICVyc2kKKyAg
ICAgICAgcG9wICAgICAlcmRpCisgICAgICAgIHBvcCAgICAgJXI4CisgICAg
ICAgIHBvcCAgICAgJXI5CisgICAgICAgIHBvcCAgICAgJXIxMAorICAgICAg
ICBwb3AgICAgICVyMTEKKworICAgICAgICBqbXAgICAgIGVhcmx5X2h5cGVy
Y2FsbAorCisgICAgICAgIC50eXBlIGVhcmx5X2h5cGVyY2FsbCwgQGZ1bmN0
aW9uCisgICAgICAgIC5zaXplIGVhcmx5X2h5cGVyY2FsbCwgLiAtIGVhcmx5
X2h5cGVyY2FsbApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2d1ZXN0L3hl
bi9oeXBlcmNhbGxfcGFnZS5TIGIveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi9o
eXBlcmNhbGxfcGFnZS5TCmRlbGV0ZWQgZmlsZSBtb2RlIDEwMDY0NAppbmRl
eCA5OTU4ZDAyY2ZkNWIuLjAwMDAwMDAwMDAwMAotLS0gYS94ZW4vYXJjaC94
ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbF9wYWdlLlMKKysrIC9kZXYvbnVsbApA
QCAtMSw3OCArMCwwIEBACi0jaW5jbHVkZSA8YXNtL3BhZ2UuaD4KLSNpbmNs
dWRlIDxhc20vYXNtX2RlZm5zLmg+Ci0jaW5jbHVkZSA8cHVibGljL3hlbi5o
PgotCi0gICAgICAgIC5zZWN0aW9uICIudGV4dC5wYWdlX2FsaWduZWQiLCAi
YXgiLCBAcHJvZ2JpdHMKLSAgICAgICAgLnAyYWxpZ24gUEFHRV9TSElGVAot
Ci1HTE9CQUwoaHlwZXJjYWxsX3BhZ2UpCi0gICAgICAgICAvKiBQb2lzb25l
ZCB3aXRoIGByZXRgIGZvciBzYWZldHkgYmVmb3JlIGh5cGVyY2FsbHMgYXJl
IHNldCB1cC4gKi8KLSAgICAgICAgLmZpbGwgUEFHRV9TSVpFLCAxLCAweGMz
Ci0gICAgICAgIC50eXBlIGh5cGVyY2FsbF9wYWdlLCBTVFRfT0JKRUNUCi0g
ICAgICAgIC5zaXplIGh5cGVyY2FsbF9wYWdlLCBQQUdFX1NJWkUKLQotLyoK
LSAqIElkZW50aWZ5IGEgc3BlY2lmaWMgaHlwZXJjYWxsIGluIHRoZSBoeXBl
cmNhbGwgcGFnZQotICogQHBhcmFtIG5hbWUgSHlwZXJjYWxsIG5hbWUuCi0g
Ki8KLSNkZWZpbmUgREVDTEFSRV9IWVBFUkNBTEwobmFtZSkgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAotICAg
ICAgICAuZ2xvYmwgSFlQRVJDQUxMXyAjIyBuYW1lOyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgIC50
eXBlICBIWVBFUkNBTExfICMjIG5hbWUsIFNUVF9GVU5DOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgLnNpemUgIEhZ
UEVSQ0FMTF8gIyMgbmFtZSwgMzI7ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXAotICAgICAgICAuc2V0ICAgSFlQRVJDQUxM
XyAjIyBuYW1lLCBoeXBlcmNhbGxfcGFnZSArIF9fSFlQRVJWSVNPUl8gIyMg
bmFtZSAqIDMyCi0KLURFQ0xBUkVfSFlQRVJDQUxMKHNldF90cmFwX3RhYmxl
KQotREVDTEFSRV9IWVBFUkNBTEwobW11X3VwZGF0ZSkKLURFQ0xBUkVfSFlQ
RVJDQUxMKHNldF9nZHQpCi1ERUNMQVJFX0hZUEVSQ0FMTChzdGFja19zd2l0
Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChzZXRfY2FsbGJhY2tzKQotREVDTEFS
RV9IWVBFUkNBTEwoZnB1X3Rhc2tzd2l0Y2gpCi1ERUNMQVJFX0hZUEVSQ0FM
TChzY2hlZF9vcF9jb21wYXQpCi1ERUNMQVJFX0hZUEVSQ0FMTChwbGF0Zm9y
bV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHNldF9kZWJ1Z3JlZykKLURFQ0xB
UkVfSFlQRVJDQUxMKGdldF9kZWJ1Z3JlZykKLURFQ0xBUkVfSFlQRVJDQUxM
KHVwZGF0ZV9kZXNjcmlwdG9yKQotREVDTEFSRV9IWVBFUkNBTEwobWVtb3J5
X29wKQotREVDTEFSRV9IWVBFUkNBTEwobXVsdGljYWxsKQotREVDTEFSRV9I
WVBFUkNBTEwodXBkYXRlX3ZhX21hcHBpbmcpCi1ERUNMQVJFX0hZUEVSQ0FM
TChzZXRfdGltZXJfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChldmVudF9jaGFu
bmVsX29wX2NvbXBhdCkKLURFQ0xBUkVfSFlQRVJDQUxMKHhlbl92ZXJzaW9u
KQotREVDTEFSRV9IWVBFUkNBTEwoY29uc29sZV9pbykKLURFQ0xBUkVfSFlQ
RVJDQUxMKHBoeXNkZXZfb3BfY29tcGF0KQotREVDTEFSRV9IWVBFUkNBTEwo
Z3JhbnRfdGFibGVfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTCh2bV9hc3Npc3Qp
Ci1ERUNMQVJFX0hZUEVSQ0FMTCh1cGRhdGVfdmFfbWFwcGluZ19vdGhlcmRv
bWFpbikKLURFQ0xBUkVfSFlQRVJDQUxMKGlyZXQpCi1ERUNMQVJFX0hZUEVS
Q0FMTCh2Y3B1X29wKQotREVDTEFSRV9IWVBFUkNBTEwoc2V0X3NlZ21lbnRf
YmFzZSkKLURFQ0xBUkVfSFlQRVJDQUxMKG1tdWV4dF9vcCkKLURFQ0xBUkVf
SFlQRVJDQUxMKHhzbV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKG5taV9vcCkK
LURFQ0xBUkVfSFlQRVJDQUxMKHNjaGVkX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoY2FsbGJhY2tfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTCh4ZW5vcHJvZl9v
cCkKLURFQ0xBUkVfSFlQRVJDQUxMKGV2ZW50X2NoYW5uZWxfb3ApCi1ERUNM
QVJFX0hZUEVSQ0FMTChwaHlzZGV2X29wKQotREVDTEFSRV9IWVBFUkNBTEwo
aHZtX29wKQotREVDTEFSRV9IWVBFUkNBTEwoc3lzY3RsKQotREVDTEFSRV9I
WVBFUkNBTEwoZG9tY3RsKQotREVDTEFSRV9IWVBFUkNBTEwoa2V4ZWNfb3Ap
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmdvX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoeGVucG11X29wKQotCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzApCi1E
RUNMQVJFX0hZUEVSQ0FMTChhcmNoXzEpCi1ERUNMQVJFX0hZUEVSQ0FMTChh
cmNoXzIpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzMpCi1ERUNMQVJFX0hZ
UEVSQ0FMTChhcmNoXzQpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzUpCi1E
RUNMQVJFX0hZUEVSQ0FMTChhcmNoXzYpCi1ERUNMQVJFX0hZUEVSQ0FMTChh
cmNoXzcpCi0KLS8qCi0gKiBMb2NhbCB2YXJpYWJsZXM6Ci0gKiB0YWItd2lk
dGg6IDgKLSAqIGluZGVudC10YWJzLW1vZGU6IG5pbAotICogRW5kOgotICov
CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL3hlbi5jIGIv
eGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94ZW4uYwppbmRleCBjNGNiMTZkZjM4
YjMuLjBkMWU2ZDA2NTg2YiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2d1
ZXN0L3hlbi94ZW4uYworKysgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL3hl
bi5jCkBAIC0zOCw3ICszOCw2IEBACiBib29sIF9fcmVhZF9tb3N0bHkgeGVu
X2d1ZXN0OwogCiB1aW50MzJfdCBfX3JlYWRfbW9zdGx5IHhlbl9jcHVpZF9i
YXNlOwotZXh0ZXJuIGNoYXIgaHlwZXJjYWxsX3BhZ2VbXTsKIHN0YXRpYyBz
dHJ1Y3QgcmFuZ2VzZXQgKm1lbTsKIAogREVGSU5FX1BFUl9DUFUodW5zaWdu
ZWQgaW50LCB2Y3B1X2lkKTsKQEAgLTQ3LDYgKzQ2LDUwIEBAIHN0YXRpYyBz
dHJ1Y3QgdmNwdV9pbmZvICp2Y3B1X2luZm87CiBzdGF0aWMgdW5zaWduZWQg
bG9uZyB2Y3B1X2luZm9fbWFwcGVkW0JJVFNfVE9fTE9OR1MoTlJfQ1BVUyld
OwogREVGSU5FX1BFUl9DUFUoc3RydWN0IHZjcHVfaW5mbyAqLCB2Y3B1X2lu
Zm8pOwogCisvKgorICogV2hpY2ggaW5zdHJ1Y3Rpb24gdG8gdXNlIGZvciBl
YXJseSBoeXBlcmNhbGxzOgorICogICA8IDAgc2V0dXAKKyAqICAgICAwIHZt
Y2FsbAorICogICA+IDAgdm1tY2FsbAorICovCitpbnQ4X3QgX19pbml0ZGF0
YSBlYXJseV9oeXBlcmNhbGxfaW5zbiA9IC0xOworCisvKgorICogQ2FsbGVk
IG9uY2UgZHVyaW5nIHRoZSBmaXJzdCBoeXBlcmNhbGwgdG8gZmlndXJlIG91
dCB3aGljaCBpbnN0cnVjdGlvbiB0bworICogdXNlLiAgRXJyb3IgaGFuZGxp
bmcgb3B0aW9ucyBhcmUgbGltaXRlZC4KKyAqLwordm9pZCBfX2luaXQgZWFy
bHlfaHlwZXJjYWxsX3NldHVwKHZvaWQpCit7CisgICAgQlVHX09OKGVhcmx5
X2h5cGVyY2FsbF9pbnNuICE9IC0xKTsKKworICAgIGlmICggIWJvb3RfY3B1
X2RhdGEueDg2X3ZlbmRvciApCisgICAgeworICAgICAgICB1bnNpZ25lZCBp
bnQgZWF4LCBlYngsIGVjeCwgZWR4OworCisgICAgICAgIGNwdWlkKDAsICZl
YXgsICZlYngsICZlY3gsICZlZHgpOworCisgICAgICAgIGJvb3RfY3B1X2Rh
dGEueDg2X3ZlbmRvciA9IHg4Nl9jcHVpZF9sb29rdXBfdmVuZG9yKGVieCwg
ZWN4LCBlZHgpOworICAgIH0KKworICAgIHN3aXRjaCAoIGJvb3RfY3B1X2Rh
dGEueDg2X3ZlbmRvciApCisgICAgeworICAgIGNhc2UgWDg2X1ZFTkRPUl9J
TlRFTDoKKyAgICBjYXNlIFg4Nl9WRU5ET1JfQ0VOVEFVUjoKKyAgICBjYXNl
IFg4Nl9WRU5ET1JfU0hBTkdIQUk6CisgICAgICAgIGVhcmx5X2h5cGVyY2Fs
bF9pbnNuID0gMDsKKyAgICAgICAgc2V0dXBfZm9yY2VfY3B1X2NhcChYODZf
RkVBVFVSRV9VU0VfVk1DQUxMKTsKKyAgICAgICAgYnJlYWs7CisKKyAgICBj
YXNlIFg4Nl9WRU5ET1JfQU1EOgorICAgIGNhc2UgWDg2X1ZFTkRPUl9IWUdP
TjoKKyAgICAgICAgZWFybHlfaHlwZXJjYWxsX2luc24gPSAxOworICAgICAg
ICBicmVhazsKKworICAgIGRlZmF1bHQ6CisgICAgICAgIEJVRygpOworICAg
IH0KK30KKwogc3RhdGljIHZvaWQgX19pbml0IGZpbmRfeGVuX2xlYXZlcyh2
b2lkKQogewogICAgIHVpbnQzMl90IGVheCwgZWJ4LCBlY3gsIGVkeCwgYmFz
ZTsKQEAgLTM0OSw5ICszOTIsNiBAQCBjb25zdCBzdHJ1Y3QgaHlwZXJ2aXNv
cl9vcHMgKl9faW5pdCB4Z19wcm9iZSh2b2lkKQogICAgIGlmICggIXhlbl9j
cHVpZF9iYXNlICkKICAgICAgICAgcmV0dXJuIE5VTEw7CiAKLSAgICAvKiBG
aWxsIHRoZSBoeXBlcmNhbGwgcGFnZS4gKi8KLSAgICB3cm1zcmwoY3B1aWRf
ZWJ4KHhlbl9jcHVpZF9iYXNlICsgMiksIF9fcGEoaHlwZXJjYWxsX3BhZ2Up
KTsKLQogICAgIHhlbl9ndWVzdCA9IHRydWU7CiAKICAgICByZXR1cm4gJm9w
czsKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVm
ZWF0dXJlcy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1
cmVzLmgKaW5kZXggYmEzZGYxNzRiNzZlLi45ZTNlZDIxYzAyNmQgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5o
CisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5o
CkBAIC00Miw2ICs0Miw3IEBAIFhFTl9DUFVGRUFUVVJFKFhFTl9TSFNUSywg
ICAgICAgICBYODZfU1lOVEgoMjYpKSAvKiBYZW4gdXNlcyBDRVQgU2hhZG93
IFN0YWNrcyAqCiBYRU5fQ1BVRkVBVFVSRShYRU5fSUJULCAgICAgICAgICAg
WDg2X1NZTlRIKDI3KSkgLyogWGVuIHVzZXMgQ0VUIEluZGlyZWN0IEJyYW5j
aCBUcmFja2luZyAqLwogWEVOX0NQVUZFQVRVUkUoSUJQQl9FTlRSWV9QViwg
ICAgIFg4Nl9TWU5USCgyOCkpIC8qIE1TUl9QUkVEX0NNRCB1c2VkIGJ5IFhl
biBmb3IgUFYgKi8KIFhFTl9DUFVGRUFUVVJFKElCUEJfRU5UUllfSFZNLCAg
ICBYODZfU1lOVEgoMjkpKSAvKiBNU1JfUFJFRF9DTUQgdXNlZCBieSBYZW4g
Zm9yIEhWTSAqLworWEVOX0NQVUZFQVRVUkUoVVNFX1ZNQ0FMTCwgICAgICAg
IFg4Nl9TWU5USCgzMCkpIC8qIFVzZSBWTUNBTEwgaW5zdGVhZCBvZiBWTU1D
QUxMICovCiAKIC8qIEJ1ZyB3b3JkcyBmb2xsb3cgdGhlIHN5bnRoZXRpYyB3
b3Jkcy4gKi8KICNkZWZpbmUgWDg2X05SX0JVRyAxCmRpZmYgLS1naXQgYS94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmggYi94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmgKaW5k
ZXggMDNkNTg2OGE5ZWZkLi5hN2U5MGFkYmFmYjcgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaAorKysg
Yi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmgK
QEAgLTQxLDkgKzQxLDExIEBACiAgICAgKHsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgICAgIGxvbmcgcmVzLCB0bXBfXzsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGFz
bSB2b2xhdGlsZSAoICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICAiY2FsbCBoeXBlcmNh
bGxfcGFnZSArICVjW29mZnNldF0iICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCisgICAgICAgICAgICBBTFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5
cGVyY2FsbCIsICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICJ2bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVS
RV9VU0VfVk1DQUxMKSwgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICJ2bWNhbGwiLCBYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAg
ICBcCiAgICAgICAgICAgICA6ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSBB
U01fQ0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICBcCi0gICAgICAgICAg
ICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiksICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICA6ICIwIiAoaGNhbGwp
LCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcpKGExKSkgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgICh0eXBlKXJlczsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCkBAIC01MywxMCArNTUsMTIgQEAKICAgICAoeyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICAgICAgbG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgYXNtIHZvbGF0aWxlICggICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgICJjYWxsIGh5
cGVyY2FsbF9wYWdlICsgJWNbb2Zmc2V0XSIgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICAgICAgICAgIEFMVEVSTkFUSVZFXzIoImNhbGwgZWFy
bHlfaHlwZXJjYWxsIiwgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgInZtbWNhbGwiLCBBTFRfTk9UKFg4Nl9G
RUFUVVJFX1VTRV9WTUNBTEwpLCAgIFwKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgInZtY2FsbCIsIFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwpICAgICAg
ICAgICAgIFwKICAgICAgICAgICAgIDogIj1hIiAocmVzKSwgIj1EIiAodG1w
X18pLCAiPVMiICh0bXBfXykgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgICAgICAgQVNNX0NBTExfQ09OU1RSQUlOVCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgIDogW29mZnNl
dF0gImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2FsbCksICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgICAgICAgIjEiICgobG9uZykoYTEpKSwgIjIiICgobG9uZykoYTIpKSAg
ICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9y
eSIgKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICAgICAgKHR5cGUpcmVzOyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKQEAgLTY2
LDEwICs3MCwxMiBAQAogICAgICh7ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAog
ICAgICAgICBsb25nIHJlcywgdG1wX187ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBhc20gdm9s
YXRpbGUgKCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAotICAgICAgICAgICAgImNhbGwgaHlwZXJjYWxsX3Bh
Z2UgKyAlY1tvZmZzZXRdIiAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICAgICAgQUxURVJOQVRJVkVfMigiY2FsbCBlYXJseV9oeXBlcmNh
bGwiLCAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAg
ICAgICAgICAgICAidm1tY2FsbCIsIEFMVF9OT1QoWDg2X0ZFQVRVUkVfVVNF
X1ZNQ0FMTCksICAgXAorICAgICAgICAgICAgICAgICAgICAgICAgICAidm1j
YWxsIiwgWDg2X0ZFQVRVUkVfVVNFX1ZNQ0FMTCkgICAgICAgICAgICAgXAog
ICAgICAgICAgICAgOiAiPWEiIChyZXMpLCAiPUQiICh0bXBfXyksICI9UyIg
KHRtcF9fKSwgIj1kIiAodG1wX18pICAgICAgXAogICAgICAgICAgICAgICBB
U01fQ0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAotICAgICAgICAgICAgOiBbb2Zmc2V0XSAiaSIgKGhj
YWxsICogMzIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICAgICAgOiAiMCIgKGhjYWxsKSwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAi
MSIgKChsb25nKShhMSkpLCAiMiIgKChsb25nKShhMikpLCAiMyIgKChsb25n
KShhMykpICAgICAgXAogICAgICAgICAgICAgOiAibWVtb3J5IiApOyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAog
ICAgICAgICAodHlwZSlyZXM7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXApAQCAtODAsMTAgKzg2LDEy
IEBACiAgICAgICAgIGxvbmcgcmVzLCB0bXBfXzsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIHJl
Z2lzdGVyIGxvbmcgX2E0IGFzbSAoInIxMCIpID0gKChsb25nKShhNCkpOyAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCi0gICAgICAgICAgICAiY2FsbCBoeXBlcmNhbGxfcGFnZSArICVjW29m
ZnNldF0iICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICBBTFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5cGVyY2FsbCIsICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICJ2bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSwg
ICBcCisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2bWNhbGwiLCBYODZf
RkVBVFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSwgIj1TIiAodG1wX18pLCAi
PWQiICh0bXBfXyksICAgICBcCiAgICAgICAgICAgICAgICI9JnIiICh0bXBf
XykgQVNNX0NBTExfQ09OU1RSQUlOVCAgICAgICAgICAgICAgICAgICAgICAg
ICBcCi0gICAgICAgICAgICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiks
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICA6ICIwIiAoaGNhbGwpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcp
KGExKSksICIyIiAoKGxvbmcpKGEyKSksICIzIiAoKGxvbmcpKGEzKSksICAg
ICBcCiAgICAgICAgICAgICAgICI0IiAoX2E0KSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-03.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-03.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IChNaXMpYWxpZ24gX194ODZfaW5kaXJlY3RfdGh1bmtf
KiB0byBtaXRpZ2F0ZSBJVFMKClRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRp
cmVjdApicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hl
biBpbiB0aGUgZmlyc3QgaGFsZiBvZiBhIGNhY2hlbGluZS4KCkFycmFuZ2Ug
Zm9yIF9feDg2X2luZGlyZWN0X3RodW5rXyogdG8gYWx3YXlzIGJlIGluIHRo
ZSBzZWNvbmQgaGFsZi4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDY5IC8gQ1ZF
LTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TCmluZGV4IGRlNmFlZjYwNjgzMi4uZTdlZjEwNGQzYmQz
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwor
KysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMzUsNiAr
MzUsMTYgQEAKIC5tYWNybyBHRU5fSU5ESVJFQ1RfVEhVTksgcmVnOnJlcQog
ICAgICAgICAuc2VjdGlvbiAudGV4dC5fX3g4Nl9pbmRpcmVjdF90aHVua19c
cmVnLCAiYXgiLCBAcHJvZ2JpdHMKIAorICAgICAgICAvKgorICAgICAgICAg
KiBUaGUgSW5kaXJlY3QgVGFyZ2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2
dWxuZXJhYmlsaXR5IG1lYW5zIHRoYXQKKyAgICAgICAgICogaW5kaXJlY3Qg
YnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUgdW5zYWZlIHdoZW4gaW4g
dGhlIGZpcnN0CisgICAgICAgICAqIGhhbGYgb2YgYSBjYWNoZWxpbmUuICBB
cnJhbmdlIGZvciB0aGVtIHRvIGJlIGluIHRoZSBzZWNvbmQgaGFsZi4KKyAg
ICAgICAgICoKKyAgICAgICAgICogQWxpZ24gdG8gNjQsIHRoZW4gc2tpcCAz
Mi4KKyAgICAgICAgICovCisgICAgICAgIC5iYWxpZ24gNjQKKyAgICAgICAg
LmZpbGwgMzIsIDEsIDB4Y2MKKwogRU5UUlkoX194ODZfaW5kaXJlY3RfdGh1
bmtfXHJlZykKICAgICAgICAgQUxURVJOQVRJVkVfMiBfX3N0cmluZ2lmeShJ
TkRfVEhVTktfUkVUUE9MSU5FIFxyZWcpLCAgICAgICAgICAgICAgXAogICAg
ICAgICBfX3N0cmluZ2lmeShJTkRfVEhVTktfTEZFTkNFIFxyZWcpLCBYODZf
RkVBVFVSRV9JTkRfVEhVTktfTEZFTkNFLCBcCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-04.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-04.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3RodW5rOiAoTWlzKWFsaWduIHRoZSBSRVRzIGlu
IGNsZWFyX2JoYl9sb29wcygpIHRvIG1pdGlnYXRlIElUUwoKVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0IGluZGlyZWN0CmJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdCBoYWxmIG9mIGEgY2Fj
aGVsaW5lLgoKY2xlYXJfYmhiX2xvb3BzKCkgaGFzIGEgcHJlY2lzZSBsYXlv
dXQgb2YgYnJhbmNoZXMuICBUaGUgYWxpZ25tZW50IGZvcgpwZXJmb3JtYW5j
ZSBjYXVzZSB0aGUgUkVUcyB0byBhbHdheXMgYmUgaW4gYW4gdW5zYWZlIHBv
c2l0aW9uLCBhbmQgY29udmVydGluZwp0aG9zZSB0byByZXR1cm4gdGh1bmtz
IGNoYW5nZXMgdGhlIGJyYW5jaGluZyBwYXR0ZXJuLiAgV2hpbGUgc3VjaCBh
IGNvbnZlcnNpb24KaXMgYmVsaWV2ZWQgdG8gYmUgc2FmZSwgY2xlYXJfYmhi
X2xvb3BzKCkgaXMgYWxzbyBhIHBlcmZvcm1hbmNlLXJlbGV2YW50CmZhc3Rw
YXRoLCBzbyAobWlzKWFsaWduIHRoZSBSRVRzIHRvIGJlIGluIGEgc2FmZSBw
b3NpdGlvbi4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0
IG9mIFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUyBi
L3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCA3ZTg2Njc4NGY3ODQu
LjA1ZjEwNDNkZjdkMCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2JoYi10
aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwpAQCAtNTIs
NyArNTIsMTIgQEAgRU5UUlkoY2xlYXJfYmhiX3RzeCkKICAqICAgcmV0CiAg
KgogICogVGhlIENBTEwvUkVUcyBhcmUgbmVjZXNzYXJ5IHRvIHByZXZlbnQg
dGhlIExvb3AgU3RyZWFtIERldGVjdG9yIGZyb20KLSAqIGludGVyZmVyaW5n
LiAgVGhlIGFsaWdubWVudCBpcyBmb3IgcGVyZm9ybWFuY2UgYW5kIG5vdCBz
YWZldHkuCisgKiBpbnRlcmZlcmluZy4KKyAqCisgKiBUaGUgLmJhbGlnbidz
IGFyZSBmb3IgcGVyZm9ybWFuY2UsIGJ1dCB0aGV5IGNhdXNlIHRoZSBSRVRz
IHRvIGJlIGluIHVuc2FmZQorICogcG9zaXRpb25zIHdpdGggcmVzcGVjdCB0
byBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uLiAgVGhlIC5za2lwcyBhcmUg
dG8KKyAqIG1vdmUgdGhlIFJFVHMgaW50byBJVFMtc2FmZSBwb3NpdGlvbnMs
IHJhdGhlciB0aGFuIHVzaW5nIHRoZSBzbG93cGF0aAorICogdGhyb3VnaCBf
X3g4Nl9yZXR1cm5fdGh1bmsuCiAgKgogICogVGhlICJzaG9ydCIgc2VxdWVu
Y2UgKDUgYW5kIDUpIGlzIGZvciBDUFVzIHByaW9yIHRvIEFsZGVyIExha2Ug
LyBTYXBwaGlyZQogICogUmFwaWRzIChpLmUuIENvcmVzIHByaW9yIHRvIEdv
bGRlbiBDb3ZlIGFuZC9vciBHcmFjZW1vbnQpLgpAQCAtNjgsMTIgKzczLDE0
IEBAIEVOVFJZKGNsZWFyX2JoYl9sb29wcykKICAgICAgICAgam1wICAgICA1
ZgogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAgICAg
IC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtICguTHIxIC0gMWYp
LCAweGNjCiAxOiAgICAgIGNhbGwgICAgMmYKLSAgICAgICAgcmV0CisuTHIx
OiAgIHJldAogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0Cisg
ICAgICAgIC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtIDE4IC8q
ICguTHIyIC0gMmYpIGJ1dCBDbGFuZyBJQVMgZG9lc24ndCBsaWtlIHRoaXMg
Ki8sIDB4Y2MKIDI6ICAgICAgQUxURVJOQVRJVkUgIm1vdiAkNSwgJWVheCIs
ICJtb3YgJDcsICVlYXgiLCBYODZfU1BFQ19CSEJfTE9PUFNfTE9ORwogCiAz
OiAgICAgIGptcCAgICAgNGYKQEAgLTg1LDcgKzkyLDcgQEAgRU5UUlkoY2xl
YXJfYmhiX2xvb3BzKQogICAgICAgICBzdWIgICAgICQxLCAlZWN4CiAgICAg
ICAgIGpueiAgICAgMWIKIAotICAgICAgICByZXQKKy5McjI6ICAgcmV0CiA1
OgogICAgICAgICAvKgogICAgICAgICAgKiBUaGUgSW50ZWwgc2VxdWVuY2Ug
aGFzIGFuIExGRU5DRSBoZXJlLiAgVGhlIHB1cnBvc2UgaXMgdG8gZW5zdXJl
Cg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-05.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-05.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3N0dWJzOiBJbnRyb2R1Y2UgcGxhY2VfcmV0KCkg
dG8gYWJzdHJhY3QgYXdheSByYXcgMHhjMydzCgpUaGUgSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5z
IHRoYXQgaW5kaXJlY3QKYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUg
dW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0IGhhbGYgb2YgYSBjYWNoZWxpbmUu
ClRoaXMgbWVhbnMgaXQncyBub3Qgc2FmZSBmb3IgbG9naWMgdXNpbmcgdGhl
IHN0dWJzIHRvIHdyaXRlIHJhdyAweGMzJ3MuCgpJbnRyb2R1Y2UgcGxhY2Vf
cmV0KCkgd2hpY2gsIGZvciBub3csIHdyaXRlcyBhIHJhdyAweGMzIGJ1dCB3
aWxsIGNvbnRhaW4KYWRkaXRpb25hbCBsb2dpYyB3aGVuIHJldHVybiB0aHVu
a3MgYXJlIGluIHVzZS4KCnN0dWJfc2VsZnRlc3QoKSBkb2Vzbid0IHN0cmlj
dGx5IG5lZWQgdG8gYmUgY29udmVydGVkIGFzIHRoZXkgb25seSBydW4gb24K
Ym9vdCwgYnV0IGRvaW5nIHNvIGdldHMgdXMgYSBwYXJ0aWFsIHRlc3Qgb2Yg
cGxhY2VfcmV0KCkgdG9vLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ2OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQt
b2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu
Y29tPgpSZXZpZXdlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvdG9vbHMvdGVzdHMveDg2X2Vt
dWxhdG9yL3g4Ni1lbXVsYXRlLmggYi90b29scy90ZXN0cy94ODZfZW11bGF0
b3IveDg2LWVtdWxhdGUuaAppbmRleCA1ODc2MGYwOTZkM2UuLjY1YWU5NWU2
MjRlNiAxMDA2NDQKLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKKysrIGIvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKQEAgLTY3LDYgKzY3LDEyIEBACiAKICNkZWZpbmUgaXNf
Y2Fub25pY2FsX2FkZHJlc3MoeCkgKCgoaW50NjRfdCkoeCkgPj4gNDcpID09
ICgoaW50NjRfdCkoeCkgPj4gNjMpKQogCitzdGF0aWMgaW5saW5lIHZvaWQg
KnBsYWNlX3JldCh2b2lkICpwdHIpCit7CisgICAgKih1aW50OF90ICopcHRy
ID0gMHhjMzsKKyAgICByZXR1cm4gcHRyICsgMTsKK30KKwogZXh0ZXJuIHVp
bnQzMl90IG14Y3NyX21hc2s7CiBleHRlcm4gc3RydWN0IGNwdV9wb2xpY3kg
Y3A7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hl
bi9hcmNoL3g4Ni9NYWtlZmlsZQppbmRleCA2YTA3MGE4Y2Y4ZGEuLjg4MjQw
OGNjYWY5YSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisr
KyBiL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtMTAsOSArMTAsNyBAQCBv
YmotJChDT05GSUdfWEVOT1BST0YpICs9IG9wcm9maWxlLwogb2JqLSQoQ09O
RklHX1BWKSArPSBwdi8KIG9iai15ICs9IHg4Nl82NC8KIAotYWx0ZXJuYXRp
dmUteSA6PSBhbHRlcm5hdGl2ZS5pbml0Lm8KLWFsdGVybmF0aXZlLSQoQ09O
RklHX0xJVkVQQVRDSCkgOj0KLW9iai1iaW4teSArPSAkKGFsdGVybmF0aXZl
LXkpCitvYmoteSArPSBhbHRlcm5hdGl2ZS5vCiBvYmoteSArPSBhcGljLm8K
IG9iai15ICs9IGJoYi10aHVuay5vCiBvYmoteSArPSBiaXRvcHMubwpAQCAt
NDAsNyArMzgsNyBAQCBvYmoteSArPSBoeXBlcmNhbGwubwogb2JqLXkgKz0g
aTM4Ny5vCiBvYmoteSArPSBpODI1OS5vCiBvYmoteSArPSBpb19hcGljLm8K
LW9iai0kKENPTkZJR19MSVZFUEFUQ0gpICs9IGFsdGVybmF0aXZlLm8gbGl2
ZXBhdGNoLm8KK29iai0kKENPTkZJR19MSVZFUEFUQ0gpICs9IGxpdmVwYXRj
aC5vCiBvYmoteSArPSBtc2kubwogb2JqLXkgKz0gbXNyLm8KIG9iai0kKENP
TkZJR19JTkRJUkVDVF9USFVOSykgKz0gaW5kaXJlY3QtdGh1bmsubwpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJj
aC94ODYvYWx0ZXJuYXRpdmUuYwppbmRleCA2ZWVlNmU1MDFhZDkuLjg4MDgy
ZjY4YTk4MiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZl
LmMKKysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTE0OSw2
ICsxNDksMjAgQEAgdm9pZCBpbml0X29yX2xpdmVwYXRjaCBhZGRfbm9wcyh2
b2lkICppbnNucywgdW5zaWduZWQgaW50IGxlbikKICAgICB9CiB9CiAKKy8q
CisgKiBQbGFjZSBhIHJldHVybiBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGlu
IHRoZSB3cml0YWJsZSBhbGlhcyBvZiBhIHN0dWIuCisgKgorICogUmV0dXJu
cyB0aGUgbmV4dCBwb3NpdGlvbiB0byB3cml0ZSBpbnRvIHRoZSBzdHViLgor
ICovCit2b2lkICpwbGFjZV9yZXQodm9pZCAqcHRyKQoreworICAgIHVpbnQ4
X3QgKnAgPSBwdHI7CisKKyAgICAqcCsrID0gMHhjMzsKKworICAgIHJldHVy
biBwOworfQorCiAvKgogICogdGV4dF9wb2tlIC0gVXBkYXRlIGluc3RydWN0
aW9ucyBvbiBhIGxpdmUga2VybmVsIG9yIG5vbi1leGVjdXRlZCBjb2RlLgog
ICogQGFkZHI6IGFkZHJlc3MgdG8gbW9kaWZ5CmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvZXh0YWJsZS5jIGIveGVuL2FyY2gveDg2L2V4dGFibGUuYwpp
bmRleCBmMDVjMTZkZWY2OGIuLmFkZmQ0MzlkM2E1MCAxMDA2NDQKLS0tIGEv
eGVuL2FyY2gveDg2L2V4dGFibGUuYworKysgYi94ZW4vYXJjaC94ODYvZXh0
YWJsZS5jCkBAIC0xMzUsMjAgKzEzNSwyMCBAQCBzZWFyY2hfZXhjZXB0aW9u
X3RhYmxlKGNvbnN0IHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzLCB1bnNp
Z25lZCBsb25nICpzdHViX3JhKQogaW50IF9faW5pdCBjZl9jaGVjayBzdHVi
X3NlbGZ0ZXN0KHZvaWQpCiB7CiAgICAgc3RhdGljIGNvbnN0IHN0cnVjdCB7
Ci0gICAgICAgIHVpbnQ4X3Qgb3BjWzhdOworICAgICAgICB1aW50OF90IG9w
Y1s3XTsKICAgICAgICAgdWludDY0X3QgcmF4OwogICAgICAgICB1bmlvbiBz
dHViX2V4Y2VwdGlvbl90b2tlbiByZXM7CiAgICAgfSB0ZXN0c1tdIF9faW5p
dGNvbnN0ID0gewogI2RlZmluZSBlbmRicjY0IDB4ZjMsIDB4MGYsIDB4MWUs
IDB4ZmEKLSAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDBmLCAweGI5
LCAweGMzLCAweGMzIH0sIC8qIHVkMSAqLworICAgICAgICB7IC5vcGMgPSB7
IGVuZGJyNjQsIDB4MGYsIDB4YjksIDB4OTAgfSwgLyogdWQxICovCiAgICAg
ICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0gVFJBUF9pbnZhbGlkX29wIH0s
Ci0gICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwgMHg5MCwgMHgwMiwgMHgw
MCwgMHhjMyB9LCAvKiBub3A7IGFkZCAoJXJheCksJWFsICovCisgICAgICAg
IHsgLm9wYyA9IHsgZW5kYnI2NCwgMHg5MCwgMHgwMiwgMHgwMCB9LCAvKiBu
b3A7IGFkZCAoJXJheCksJWFsICovCiAgICAgICAgICAgLnJheCA9IDB4MDEy
MzQ1Njc4OWFiY2RlZiwKICAgICAgICAgICAucmVzLmZpZWxkcy50cmFwbnIg
PSBUUkFQX2dwX2ZhdWx0IH0sCi0gICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2
NCwgMHgwMiwgMHgwNCwgMHgwNCwgMHhjMyB9LCAvKiBhZGQgKCVyc3AsJXJh
eCksJWFsICovCisgICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwgMHgwMiwg
MHgwNCwgMHgwNCB9LCAvKiBhZGQgKCVyc3AsJXJheCksJWFsICovCiAgICAg
ICAgICAgLnJheCA9IDB4ZmVkY2JhOTg3NjU0MzIxMCwKICAgICAgICAgICAu
cmVzLmZpZWxkcy50cmFwbnIgPSBUUkFQX3N0YWNrX2Vycm9yIH0sCi0gICAg
ICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwgMHhjYywgMHhjMywgMHhjMywgMHhj
MyB9LCAvKiBpbnQzICovCisgICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwg
MHhjYywgMHg5MCwgMHg5MCB9LCAvKiBpbnQzICovCiAgICAgICAgICAgLnJl
cy5maWVsZHMudHJhcG5yID0gVFJBUF9pbnQzIH0sCiAjdW5kZWYgZW5kYnI2
NAogICAgIH07CkBAIC0xNjcsNiArMTY3LDcgQEAgaW50IF9faW5pdCBjZl9j
aGVjayBzdHViX3NlbGZ0ZXN0KHZvaWQpCiAKICAgICAgICAgbWVtc2V0KHB0
ciwgMHhjYywgU1RVQl9CVUZfU0laRSAvIDIpOwogICAgICAgICBtZW1jcHko
cHRyLCB0ZXN0c1tpXS5vcGMsIEFSUkFZX1NJWkUodGVzdHNbaV0ub3BjKSk7
CisgICAgICAgIHBsYWNlX3JldChwdHIgKyBBUlJBWV9TSVpFKHRlc3RzW2ld
Lm9wYykpOwogICAgICAgICB1bm1hcF9kb21haW5fcGFnZShwdHIpOwogCiAg
ICAgICAgIGFzbSB2b2xhdGlsZSAoICJJTkRJUkVDVF9DQUxMICVbc3RiXVxu
IgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYWx0ZXJuYXRp
dmUuaAppbmRleCAzODhlNTk1Nzg2ZTAuLjI4ZTY5ZTk4OGFjMCAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmgK
KysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmgK
QEAgLTMwLDYgKzMwLDggQEAgc3RydWN0IF9fcGFja2VkIGFsdF9pbnN0ciB7
CiAjZGVmaW5lIEFMVF9SRVBMX1BUUihhKSAgICAgX19BTFRfUFRSKGEsIHJl
cGxfb2Zmc2V0KQogCiBleHRlcm4gdm9pZCBhZGRfbm9wcyh2b2lkICppbnNu
cywgdW5zaWduZWQgaW50IGxlbik7Cit2b2lkICpwbGFjZV9yZXQodm9pZCAq
cHRyKTsKKwogLyogU2ltaWxhciB0byBhbHRlcm5hdGl2ZV9pbnN0cnVjdGlv
bnMgZXhjZXB0IGl0IGNhbiBiZSBydW4gd2l0aCBJUlFzIGVuYWJsZWQuICov
CiBleHRlcm4gdm9pZCBhcHBseV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9p
bnN0ciAqc3RhcnQsIHN0cnVjdCBhbHRfaW5zdHIgKmVuZCk7CiBleHRlcm4g
dm9pZCBhbHRlcm5hdGl2ZV9pbnN0cnVjdGlvbnModm9pZCk7CmRpZmYgLS1n
aXQgYS94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMgYi94ZW4vYXJj
aC94ODYvcHYvZW11bC1wcml2LW9wLmMKaW5kZXggZjIxNmMyNjQxMjA1Li4y
OGVhN2NjNTgwYTkgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9wdi9lbXVs
LXByaXYtb3AuYworKysgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9w
LmMKQEAgLTg4LDcgKzg4LDYgQEAgc3RhdGljIGlvX2VtdWxfc3R1Yl90ICpp
b19lbXVsX3N0dWJfc2V0dXAoc3RydWN0IHByaXZfb3BfY3R4dCAqY3R4dCwg
dTggb3Bjb2RlLAogICAgICAgICAweDQxLCAweDVjLCAvKiBwb3AgJXIxMiAg
Ki8KICAgICAgICAgMHg1ZCwgICAgICAgLyogcG9wICVyYnAgICovCiAgICAg
ICAgIDB4NWIsICAgICAgIC8qIHBvcCAlcmJ4ICAqLwotICAgICAgICAweGMz
LCAgICAgICAvKiByZXQgICAgICAgKi8KICAgICB9OwogCiAgICAgY29uc3Qg
c3RydWN0IHN0dWJzICp0aGlzX3N0dWJzID0gJnRoaXNfY3B1KHN0dWJzKTsK
QEAgLTEzOCwxMSArMTM3LDEzIEBAIHN0YXRpYyBpb19lbXVsX3N0dWJfdCAq
aW9fZW11bF9zdHViX3NldHVwKHN0cnVjdCBwcml2X29wX2N0eHQgKmN0eHQs
IHU4IG9wY29kZSwKIAogICAgIEFQUEVORF9DQUxMKHNhdmVfZ3Vlc3RfZ3By
cyk7CiAgICAgQVBQRU5EX0JVRkYoZXBpbG9ndWUpOworICAgIHAgPSBwbGFj
ZV9yZXQocCk7CiAKICAgICAvKiBCdWlsZC10aW1lIGJlc3QgZWZmb3J0IGF0
dGVtcHQgdG8gY2F0Y2ggcHJvYmxlbXMuICovCiAgICAgQlVJTERfQlVHX09O
KFNUVUJfQlVGX1NJWkUgLyAyIDwKICAgICAgICAgICAgICAgICAgKHNpemVv
Zihwcm9sb2d1ZSkgKyBzaXplb2YoZXBpbG9ndWUpICsgMTAgLyogMnggY2Fs
bCAqLyArCi0gICAgICAgICAgICAgICAgICBNQVgoMyAvKiBkZWZhdWx0IHN0
dWIgKi8sIElPRU1VTF9RVUlSS19TVFVCX0JZVEVTKSkpOworICAgICAgICAg
ICAgICAgICAgTUFYKDMgLyogZGVmYXVsdCBzdHViICovLCBJT0VNVUxfUVVJ
UktfU1RVQl9CWVRFUykgKworICAgICAgICAgICAgICAgICAgMSAvKiByZXQg
Ki8pKTsKICAgICAvKiBSdW50aW1lIGNvbmZpcm1hdGlvbiB0aGF0IHdlIGhh
dmVuJ3QgY2xvYmJlcmVkIGFuIGFkamFjZW50IHN0dWIuICovCiAgICAgQlVH
X09OKFNUVUJfQlVGX1NJWkUgLyAyIDwgKHAgLSBjdHh0LT5pb19lbXVsX3N0
dWIpKTsKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRl
L3g4Nl9lbXVsYXRlLmMgYi94ZW4vYXJjaC94ODYveDg2X2VtdWxhdGUveDg2
X2VtdWxhdGUuYwppbmRleCA5OTU2NzBjYmM4ZTkuLmI1ZWNhMTM0MTBjZCAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVs
YXRlLmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVs
YXRlLmMKQEAgLTE1MzMsMzYgKzE1MzMsNDIgQEAgc3RhdGljIGlubGluZSBi
b29sIGZwdV9jaGVja193cml0ZSh2b2lkKQogCiAjZGVmaW5lIGVtdWxhdGVf
ZnB1X2luc25fbWVtZHN0KG9wYywgZXh0LCBhcmcpICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisg
ICAgdm9pZCAqX3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgLyogTW9kUk06IG1v
ZD0wLCByZWc9ZXh0LCBybT0wLCBpLmUuIGEgKCVyYXgpIG9wZXJhbmQgKi8g
ICAgICAgICAgICBcCiAgICAgaW5zbl9ieXRlcyA9IDI7ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0g
ICAgbWVtY3B5KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWlu
dDhfdFtdKXsgb3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsg
ICAgICAgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9w
YywgKChleHQpICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisg
ICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIo
IiIsICIiLCAiK20iIChhcmcpIDogImEiICgmKGFyZykpKTsgICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9
IHdoaWxlICgwKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fbWVtc3Jj
KG9wYywgZXh0LCBhcmcpICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBk
byB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBn
ZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgLyogTW9kUk06IG1vZD0wLCByZWc9ZXh0LCBy
bT0wLCBpLmUuIGEgKCVyYXgpIG9wZXJhbmQgKi8gICAgICAgICAgICBcCi0g
ICAgbWVtY3B5KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWlu
dDhfdFtdKXsgb3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsg
ICAgICAgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9w
YywgKChleHQpICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisg
ICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIo
IiIsICIiLCAiPW0iIChkdW1teSkgOiAibSIgKGFyZyksICJhIiAoJihhcmcp
KSk7ICAgICAgICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9
IHdoaWxlICgwKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fc3R1Yihi
eXRlcy4uLikgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBk
byB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBn
ZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgdW5zaWduZWQgaW50IG5yXyA9IHNpemVvZigo
dWludDhfdFtdKXsgYnl0ZXMgfSk7ICAgICAgICAgICAgICAgICAgICBcCi0g
ICAgbWVtY3B5KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVz
LCAweGMzIH0pLCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAo
KHVpbnQ4X3RbXSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAg
ICAgICAgICAgICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAg
ICAgaW52b2tlX3N0dWIoIiIsICIiLCAiPW0iIChkdW1teSkgOiAiaSIgKDAp
KTsgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgcHV0X3N0dWIoc3R1
Yik7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiB9IHdoaWxlICgwKQogCiAjZGVmaW5lIGVtdWxhdGVf
ZnB1X2luc25fc3R1Yl9lZmxhZ3MoYnl0ZXMuLi4pICAgICAgICAgICAgICAg
ICAgICAgICAgICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisg
ICAgdm9pZCAqX3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgdW5zaWduZWQgaW50
IG5yXyA9IHNpemVvZigodWludDhfdFtdKXsgYnl0ZXMgfSk7ICAgICAgICAg
ICAgICAgICAgICBcCiAgICAgdW5zaWduZWQgbG9uZyB0bXBfOyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0g
ICAgbWVtY3B5KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVz
LCAweGMzIH0pLCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAo
KHVpbnQ4X3RbXSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAg
ICAgICAgICAgICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAg
ICAgaW52b2tlX3N0dWIoX1BSRV9FRkxBR1MoIltlZmxhZ3NdIiwgIlttYXNr
XSIsICJbdG1wXSIpLCAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAg
X1BPU1RfRUZMQUdTKCJbZWZsYWdzXSIsICJbbWFza10iLCAiW3RtcF0iKSwg
ICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgW2VmbGFnc10gIitnIiAo
X3JlZ3MuZWZsYWdzKSwgW3RtcF0gIj0mciIgKHRtcF8pICAgICAgICBcCkBA
IC0zODUyLDcgKzM4NTgsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgc3Ri
WzNdID0gMHg5MTsKICAgICAgICAgc3RiWzRdID0gZXZleC5vcG1zayA8PCAz
OwogICAgICAgICBpbnNuX2J5dGVzID0gNTsKLSAgICAgICAgc3RiWzVdID0g
MHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZzdGJbNV0pOwogCiAgICAgICAg
IGludm9rZV9zdHViKCIiLCAiIiwgIittIiAob3BfbWFzaykgOiAiYSIgKCZv
cF9tYXNrKSk7CiAKQEAgLTY3NTEsNyArNjc1Nyw3IEBAIHg4Nl9lbXVsYXRl
KAogICAgICAgICAgICAgZXZleC5sciA9IDA7CiAgICAgICAgIG9wY1sxXSA9
IChtb2RybSAmIDB4MzgpIHwgMHhjMDsKICAgICAgICAgaW5zbl9ieXRlcyA9
IEVWRVhfUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
RVZFWChvcGMsIGV2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIs
ICI9ZyIgKGR1bW15KSA6ICJhIiAoc3JjLnZhbCkpOwpAQCAtNjgxNiw3ICs2
ODIyLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAgICBpbnNuX2J5dGVz
ID0gUEZYX0JZVEVTICsgMjsKICAgICAgICAgICAgIGNvcHlfUkVYX1ZFWChv
cGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIH0KLSAgICAgICAgb3Bj
WzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAg
ICAgICAgIGVhLnJlZyA9IGRlY29kZV9ncHIoJl9yZWdzLCBtb2RybV9yZWcp
OwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9YSIgKCplYS5yZWcp
IDogImMiIChtbXZhbHApLCAibSIgKCptbXZhbHApKTsKQEAgLTY4ODQsNyAr
Njg5MCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAgaW5zbl9ieXRl
cyA9IFBGWF9CWVRFUyArIDI7CiAgICAgICAgICAgICBjb3B5X1JFWF9WRVgo
b3BjLCByZXhfcHJlZml4LCB2ZXgpOwogICAgICAgICB9Ci0gICAgICAgIG9w
Y1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAog
ICAgICAgICBfcmVncy5lZmxhZ3MgJj0gfkVGTEFHU19NQVNLOwogICAgICAg
ICBpbnZva2Vfc3R1YigiIiwKQEAgLTcxMTMsNyArNzExOSw3IEBAIHg4Nl9l
bXVsYXRlKAogICAgICAgICBvcGNbMV0gPSBtb2RybSAmIDB4Yzc7CiAgICAg
ICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwogICAgIHNpbWRfMGZf
dG9fZ3ByOgotICAgICAgICBvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10g
PSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1tpbnNuX2J5dGVzIC0g
UEZYX0JZVEVTXSk7CiAKICAgICAgICAgZ2VuZXJhdGVfZXhjZXB0aW9uX2lm
KGVhLnR5cGUgIT0gT1BfUkVHLCBFWENfVUQpOwogCkBAIC03NTEwLDcgKzc1
MTYsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAgIHZleC53ID0gMDsK
ICAgICAgICAgb3BjWzFdID0gbW9kcm0gJiAweDM4OwogICAgICAgICBpbnNu
X2J5dGVzID0gUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhj
MzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNv
cHlfUkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIGlu
dm9rZV9zdHViKCIiLCAiIiwgIittIiAoc3JjLnZhbCkgOiAiYSIgKCZzcmMu
dmFsKSk7CkBAIC03NTM4LDcgKzc1NDQsNyBAQCB4ODZfZW11bGF0ZSgKICAg
ICAgICAgICAgIGV2ZXgudyA9IDA7CiAgICAgICAgIG9wY1sxXSA9IG1vZHJt
ICYgMHgzODsKICAgICAgICAgaW5zbl9ieXRlcyA9IEVWRVhfUEZYX0JZVEVT
ICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2Vf
cmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlfRVZFWChvcGMsIGV2ZXgp
OwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKHNyYy52YWwp
IDogImEiICgmc3JjLnZhbCkpOwpAQCAtNzczMyw3ICs3NzM5LDcgQEAgeDg2
X2VtdWxhdGUoCiAjZW5kaWYgLyogWDg2RU1VTF9OT19TSU1EICovCiAKICAg
ICBzaW1kXzBmX3JlZ19vbmx5OgotICAgICAgICBvcGNbaW5zbl9ieXRlcyAt
IFBGWF9CWVRFU10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1tp
bnNuX2J5dGVzIC0gUEZYX0JZVEVTXSk7CiAKICAgICAgICAgY29weV9SRVhf
VkVYKG9wYywgcmV4X3ByZWZpeCwgdmV4KTsKICAgICAgICAgaW52b2tlX3N0
dWIoIiIsICIiLCBbZHVtbXlfb3V0XSAiPWciIChkdW1teSkgOiBbZHVtbXlf
aW5dICJpIiAoMCkgKTsKQEAgLTgwNTgsNyArODA2NCw3IEBAIHg4Nl9lbXVs
YXRlKAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0KCkgKQogICAgICAgICAg
ICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2RybSAmIDB4Zjg7
Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgm
b3BjWzJdKTsKIAogICAgICAgICBjb3B5X1ZFWChvcGMsIHZleCk7CiAgICAg
ICAgIGVhLnJlZyA9IGRlY29kZV9ncHIoJl9yZWdzLCBtb2RybV9ybSk7CkBA
IC04MTAxLDcgKzgxMDcsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgaWYg
KCAhbW9kZV82NGJpdCgpICkKICAgICAgICAgICAgIHZleC53ID0gMDsKICAg
ICAgICAgb3BjWzFdID0gbW9kcm0gJiAweGM3OwotICAgICAgICBvcGNbMl0g
PSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAg
ICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1Yigi
IiwgIiIsICI9YSIgKGRzdC52YWwpIDogW2R1bW15XSAiaSIgKDApKTsKQEAg
LTgxMzEsNyArODEzNyw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBvcGMg
PSBpbml0X3ByZWZpeGVzKHN0dWIpOwogICAgICAgICBvcGNbMF0gPSBiOwog
ICAgICAgICBvcGNbMV0gPSBtb2RybTsKLSAgICAgICAgb3BjWzJdID0gMHhj
MzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNv
cHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAgX3JlZ3MuZWZsYWdzICY9IH5F
RkxBR1NfTUFTSzsKQEAgLTkwMjcsNyArOTAzMyw3IEBAIHg4Nl9lbXVsYXRl
KAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0KCkgKQogICAgICAgICAgICAg
dmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2RybSAmIDB4Yzc7Ci0g
ICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzJdKTsKIAogICAgICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4
LCB2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9YSIgKGVh
LnZhbCkgOiBbZHVtbXldICJpIiAoMCkpOwpAQCAtOTE0NSw3ICs5MTUxLDcg
QEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAgICBvcGNbMV0gJj0gMHgzODsK
ICAgICAgICAgfQogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsg
MjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0
KCZvcGNbMl0pOwogICAgICAgICBpZiAoIHZleC5vcGN4ID09IHZleF9ub25l
ICkKICAgICAgICAgewogICAgICAgICAgICAgLyogQ292ZXIgZm9yIGV4dHJh
IHByZWZpeCBieXRlLiAqLwpAQCAtOTQyNCw3ICs5NDMwLDcgQEAgeDg2X2Vt
dWxhdGUoCiAgICAgICAgIHB2ZXgtPmIgPSAhbW9kZV82NGJpdCgpIHx8ICh2
ZXgucmVnID4+IDMpOwogICAgICAgICBvcGNbMV0gPSAweGMwIHwgKH52ZXgu
cmVnICYgNyk7CiAgICAgICAgIHB2ZXgtPnJlZyA9IDB4ZjsKLSAgICAgICAg
b3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwog
CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1hIiAoZWEudmFsKSA6
IFtkdW1teV0gImkiICgwKSk7CiAgICAgICAgIHB1dF9zdHViKHN0dWIpOwpA
QCAtOTY4NCw3ICs5NjkwLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAg
ICBldmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2RybSAmIDB4Zjg7
CiAgICAgICAgIGluc25fYnl0ZXMgPSBFVkVYX1BGWF9CWVRFUyArIDI7Ci0g
ICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzJdKTsKIAogICAgICAgICBjb3B5X0VWRVgob3BjLCBldmV4KTsKICAgICAg
ICAgaW52b2tlX3N0dWIoIiIsICIiLCAiPWciIChkdW1teSkgOiAiYSIgKHNy
Yy52YWwpKTsKQEAgLTk3ODMsNyArOTc4OSw3IEBAIHg4Nl9lbXVsYXRlKAog
ICAgICAgICBwdmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJt
X3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHB2ZXgtPnJlZyA9IDB4ZjsKLSAg
ICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNb
Ml0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1tIiAoKm1t
dmFscCkgOiAiYSIgKG1tdmFscCkpOwogCkBAIC05ODUzLDcgKzk4NTksNyBA
QCB4ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+YiA9IDE7CiAgICAgICAg
IG9wY1sxXSA9IChtb2RybV9yZWcgJiA3KSA8PCAzOwogICAgICAgICBwdmV4
LT5yZWcgPSAweGY7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAg
IHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1Yigi
IiwgIiIsICIrbSIgKCptbXZhbHApIDogImEiIChtbXZhbHApKTsKIApAQCAt
OTkwOSw3ICs5OTE1LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHBldmV4
LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJtX3JlZyAmIDcpIDw8
IDM7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0gICAgICAgIG9wY1syXSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAg
ICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKCptbXZhbHApIDogImEiICht
bXZhbHApKTsKIApAQCAtOTk3NCw3ICs5OTgwLDcgQEAgeDg2X2VtdWxhdGUo
CiAgICAgICAgIHBldmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1v
ZHJtX3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0g
ICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKCpt
bXZhbHApIDogImEiIChtbXZhbHApKTsKIApAQCAtOTk4OCw3ICs5OTk0LDcg
QEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIG9wY1syXSA9IDB4OTA7CiAgICAg
ICAgIC8qIFVzZSAoJXJheCkgYXMgc291cmNlLiAqLwogICAgICAgICBvcGNb
M10gPSBldmV4Lm9wbXNrIDw8IDM7Ci0gICAgICAgIG9wY1s0XSA9IDB4YzM7
CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzRdKTsKIAogICAgICAgICBpbnZv
a2Vfc3R1YigiIiwgIiIsICIrbSIgKG9wX21hc2spIDogImEiICgmb3BfbWFz
aykpOwogICAgICAgICBwdXRfc3R1YihzdHViKTsKQEAgLTEwMDgyLDcgKzEw
MDg4LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHBldmV4LT5iID0gMTsK
ICAgICAgICAgb3BjWzFdID0gKG1vZHJtX3JlZyAmIDcpIDw8IDM7CiAgICAg
ICAgIHBldmV4LT5SWCA9IDE7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vf
c3R1YigiIiwgIiIsICI9bSIgKCptbXZhbHApIDogImEiIChtbXZhbHApKTsK
IApAQCAtMTAxNjAsNyArMTAxNjYsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAg
ICAgb3BjWzJdID0gMHg5MDsKICAgICAgICAgLyogVXNlICglcmF4KSBhcyBz
b3VyY2UuICovCiAgICAgICAgIG9wY1szXSA9IGV2ZXgub3Btc2sgPDwgMzsK
LSAgICAgICAgb3BjWzRdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbNF0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAo
b3BfbWFzaykgOiAiYSIgKCZvcF9tYXNrKSk7CiAgICAgICAgIHB1dF9zdHVi
KHN0dWIpOwpAQCAtMTAyMjksNyArMTAyMzUsNyBAQCB4ODZfZW11bGF0ZSgK
ICAgICAgICAgcGV2ZXgtPnIgPSAhbW9kZV82NGJpdCgpIHx8ICEoc3RhdGUt
PnNpYl9pbmRleCAmIDB4MDgpOwogICAgICAgICBwZXZleC0+UiA9ICFtb2Rl
XzY0Yml0KCkgfHwgIShzdGF0ZS0+c2liX2luZGV4ICYgMHgxMCk7CiAgICAg
ICAgIHBldmV4LT5SWCA9IDE7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vf
c3R1YigiIiwgIiIsICI9bSIgKGluZGV4KSA6ICJhIiAoJmluZGV4KSk7CiAg
ICAgICAgIHB1dF9zdHViKHN0dWIpOwpAQCAtMTA0MDQsNyArMTA0MTAsNyBA
QCB4ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+cmVnID0gMHhmOyAvKiBy
QVggKi8KICAgICAgICAgYnVmWzNdID0gYjsKICAgICAgICAgYnVmWzRdID0g
MHgwOTsgLyogcmVnPXJDWCByL209KCVyQ1gpICovCi0gICAgICAgIGJ1Zls1
XSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzVdKTsKIAogICAg
ICAgICBzcmMucmVnID0gZGVjb2RlX3ZleF9ncHIodmV4LnJlZywgJl9yZWdz
LCBjdHh0KTsKICAgICAgICAgZW11bGF0ZV9zdHViKFtkc3RdICI9JmMiIChk
c3QudmFsKSwgIltkc3RdIiAoJnNyYy52YWwpLCAiYSIgKCpzcmMucmVnKSk7
CkBAIC0xMDQzOCw3ICsxMDQ0NCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAg
ICBwdmV4LT5yZWcgPSAweGY7IC8qIHJBWCAqLwogICAgICAgICBidWZbM10g
PSBiOwogICAgICAgICBidWZbNF0gPSAobW9kcm0gJiAweDM4KSB8IDB4MDE7
IC8qIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgIGRzdC5yZWcg
PSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3JlZ3MsIGN0eHQpOwogICAg
ICAgICBlbXVsYXRlX3N0dWIoIj0mYSIgKGRzdC52YWwpLCAiYyIgKCZzcmMu
dmFsKSk7CkBAIC0xMDY3MCw3ICsxMDY3Niw3IEBAIHg4Nl9lbXVsYXRlKAog
ICAgICAgICAgICAgZXZleC53ID0gdmV4LncgPSAwOwogICAgICAgICBvcGNb
MV0gPSBtb2RybSAmIDB4Mzg7CiAgICAgICAgIG9wY1syXSA9IGltbTE7Ci0g
ICAgICAgIG9wY1szXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzNdKTsKICAgICAgICAgaWYgKCB2ZXgub3BjeCA9PSB2ZXhfbm9uZSApCiAg
ICAgICAgIHsKICAgICAgICAgICAgIC8qIENvdmVyIGZvciBleHRyYSBwcmVm
aXggYnl0ZS4gKi8KQEAgLTEwODM3LDcgKzEwODQzLDcgQEAgeDg2X2VtdWxh
dGUoCiAgICAgICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMzsK
ICAgICAgICAgICAgIGNvcHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAgfQot
ICAgICAgICBvcGNbM10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9w
Y1szXSk7CiAKICAgICAgICAgLyogTGF0Y2ggTVhDU1IgLSB3ZSBtYXkgbmVl
ZCB0byByZXN0b3JlIGl0IGJlbG93LiAqLwogICAgICAgICBpbnZva2Vfc3R1
Yigic3RteGNzciAlW214Y3NyXSIsICIiLApAQCAtMTEwNjUsNyArMTEwNzEs
NyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgfQogICAgICAgICBvcGNbMl0g
PSBpbW0xOwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMzsK
LSAgICAgICAgb3BjWzNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbM10pOwogICAgICAgICBpZiAoIHZleC5vcGN4ID09IHZleF9ub25lICkK
ICAgICAgICAgewogICAgICAgICAgICAgLyogQ292ZXIgZm9yIGV4dHJhIHBy
ZWZpeCBieXRlLiAqLwpAQCAtMTEyMjUsNyArMTEyMzEsNyBAQCB4ODZfZW11
bGF0ZSgKICAgICAgICAgcHhvcC0+cmVnID0gMHhmOyAvKiByQVggKi8KICAg
ICAgICAgYnVmWzNdID0gYjsKICAgICAgICAgYnVmWzRdID0gKG1vZHJtICYg
MHgzOCkgfCAweDAxOyAvKiByL209KCVyQ1gpICovCi0gICAgICAgIGJ1Zls1
XSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzVdKTsKIAogICAg
ICAgICBkc3QucmVnID0gZGVjb2RlX3ZleF9ncHIodmV4LnJlZywgJl9yZWdz
LCBjdHh0KTsKICAgICAgICAgZW11bGF0ZV9zdHViKFtkc3RdICI9JmEiIChk
c3QudmFsKSwgImMiICgmc3JjLnZhbCkpOwpAQCAtMTEzMzQsNyArMTEzNDAs
NyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgYnVmWzNdID0gYjsKICAgICAg
ICAgYnVmWzRdID0gMHgwOTsgLyogcmVnPXJDWCByL209KCVyQ1gpICovCiAg
ICAgICAgICoodWludDMyX3QgKikoYnVmICsgNSkgPSBpbW0xOwotICAgICAg
ICBidWZbOV0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls5XSk7
CiAKICAgICAgICAgZW11bGF0ZV9zdHViKFtkc3RdICI9JmMiIChkc3QudmFs
KSwgIltkc3RdIiAoJnNyYy52YWwpKTsKIApAQCAtMTE0MDEsMTIgKzExNDA3
LDEyIEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAgQlVHKCk7CiAgICAg
ICAgIGlmICggZXZleF9lbmNvZGVkKCkgKQogICAgICAgICB7Ci0gICAgICAg
ICAgICBvcGNbaW5zbl9ieXRlcyAtIEVWRVhfUEZYX0JZVEVTXSA9IDB4YzM7
CisgICAgICAgICAgICBwbGFjZV9yZXQoJm9wY1tpbnNuX2J5dGVzIC0gRVZF
WF9QRlhfQllURVNdKTsKICAgICAgICAgICAgIGNvcHlfRVZFWChvcGMsIGV2
ZXgpOwogICAgICAgICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgewotICAg
ICAgICAgICAgb3BjW2luc25fYnl0ZXMgLSBQRlhfQllURVNdID0gMHhjMzsK
KyAgICAgICAgICAgIHBsYWNlX3JldCgmb3BjW2luc25fYnl0ZXMgLSBQRlhf
QllURVNdKTsKICAgICAgICAgICAgIGNvcHlfUkVYX1ZFWChvcGMsIHJleF9w
cmVmaXgsIHZleCk7CiAgICAgICAgIH0KIAo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-06.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-06.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IEJ1aWxkIFhlbiB3aXRoIFJldHVybiBUaHVua3MKClRo
ZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uIHNwZWN1bGF0aXZlIHZ1bG5l
cmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRpcmVjdApicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QgaGFsZiBv
ZiBhIGNhY2hlbGluZS4KCkluIG9yZGVyIHRvIG1pdGlnYXRlIHRoaXMsIGJ1
aWxkIHdpdGggcmV0dXJuIHRodW5rcyBhbmQgYXJyYW5nZSBmb3IKX194ODZf
cmV0dXJuX3RodW5rIHRvIGJlIChtaXMpYWxpZ25lZCBpbiB0aGUgc2FtZSBt
YW5uZXIgYXMKX194ODZfaW5kaXJlY3RfdGh1bmtfKiBzbyB0aGUgUkVUIGlu
c3RydWN0aW9uIGlzIHBsYWNlZCBpbiBhIHNhZmUgbG9jYXRpb24uCgpwbGFj
ZV9yZXQoKSBuZWVkcyB0byBjb25kaXRpb25hbGx5IGVtaXQgSk1QIF9feDg2
X3JldHVybl90aHVuayBpbnN0ZWFkIG9mIFJFVC4KClRoaXMgaXMgcGFydCBv
ZiBYU0EtNDY5IC8gQ1ZFLTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnIGIveGVu
L2FyY2gveDg2L0tjb25maWcKaW5kZXggNDcxY2ZkOGE4MGVmLi4zNzA1NTg3
NTZmMGQgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnCisrKyBi
L3hlbi9hcmNoL3g4Ni9LY29uZmlnCkBAIC0zNSw5ICszNSwxNCBAQCBjb25m
aWcgQVJDSF9ERUZDT05GSUcKIAlkZWZhdWx0ICJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCiAKIGNvbmZpZyBDQ19IQVNfSU5ESVJFQ1Rf
VEhVTksKKwkjIEdDQyA+PSA4IG9yIENsYW5nID49IDYKIAlkZWZfYm9vbCAk
KGNjLW9wdGlvbiwtbWluZGlyZWN0LWJyYW5jaC1yZWdpc3RlcikgfHwgXAog
CSAgICAgICAgICQoY2Mtb3B0aW9uLC1tcmV0cG9saW5lLWV4dGVybmFsLXRo
dW5rKQogCitjb25maWcgQ0NfSEFTX1JFVFVSTl9USFVOSworCSMgR0NDID49
IDggb3IgQ2xhbmcgPj0gMTUKKwlkZWZfYm9vbCAkKGNjLW9wdGlvbiwtbWZ1
bmN0aW9uLXJldHVybj10aHVuay1leHRlcm4pCisKIGNvbmZpZyBIQVNfQVNf
Q0VUX1NTCiAJIyBiaW51dGlscyA+PSAyLjI5IG9yIExMVk0gPj0gNgogCWRl
Zl9ib29sICQoYXMtaW5zdHIsd3Jzc3EgJXJheCQoY29tbWEpMDtzZXRzc2Jz
eSkKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hlbi9h
cmNoL3g4Ni9NYWtlZmlsZQppbmRleCA4ODI0MDhjY2FmOWEuLjIyMjkzZDk2
OWIzOCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisrKyBi
L3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtNDIsNiArNDIsNyBAQCBvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KK29iai0kKENPTkZJR19SRVRV
Uk5fVEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KIG9iai0kKENPTkZJR19Q
VikgKz0gaW9wb3J0X2VtdWxhdGUubwogb2JqLXkgKz0gaXJxLm8KIG9iai0k
KENPTkZJR19LRVhFQykgKz0gbWFjaGluZV9rZXhlYy5vCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJvdC5TIGIveGVuL2FyY2gv
eDg2L2FjcGkvd2FrZXVwX3Byb3QuUwppbmRleCAzODU1ZmYxZGRiOTQuLmNk
NDY4MmI5ZjljNSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvd2Fr
ZXVwX3Byb3QuUworKysgYi94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJv
dC5TCkBAIC0xMzEsNyArMTMxLDcgQEAgRU5UUlkoczNfcmVzdW1lKQogICAg
ICAgICBwb3AgICAgICVyMTIKICAgICAgICAgcG9wICAgICAlcmJ4CiAgICAg
ICAgIHBvcCAgICAgJXJicAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAK
IC5kYXRhCiAgICAgICAgIC5hbGlnbiAxNgpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94ODYvYWx0ZXJuYXRp
dmUuYwppbmRleCA4ODA4MmY2OGE5ODIuLjE1MWRmNzM1ODNmMSAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKKysrIGIveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTE0OSwxNiArMTQ5LDQ1IEBAIHZv
aWQgaW5pdF9vcl9saXZlcGF0Y2ggYWRkX25vcHModm9pZCAqaW5zbnMsIHVu
c2lnbmVkIGludCBsZW4pCiAgICAgfQogfQogCit2b2lkIG5vY2FsbCBfX3g4
Nl9yZXR1cm5fdGh1bmsodm9pZCk7CisKIC8qCiAgKiBQbGFjZSBhIHJldHVy
biBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGluIHRoZSB3cml0YWJsZSBhbGlh
cyBvZiBhIHN0dWIuCiAgKgorICogV2hlbiBDT05GSUdfUkVUVVJOX1RIVU5L
IGlzIGFjdGl2ZSwgdGhpcyBtYXkgYmUgYSBKTVAgX194ODZfcmV0dXJuX3Ro
dW5rCisgKiBpbnN0ZWFkLCBkZXBlbmRpbmcgb24gdGhlIHNhZmV0eSBvZiBA
cHRyIHdpdGggcmVzcGVjdCB0byBJbmRpcmVjdCBUYXJnZXQKKyAqIFNlbGVj
dGlvbi4KKyAqCiAgKiBSZXR1cm5zIHRoZSBuZXh0IHBvc2l0aW9uIHRvIHdy
aXRlIGludG8gdGhlIHN0dWIuCiAgKi8KIHZvaWQgKnBsYWNlX3JldCh2b2lk
ICpwdHIpCiB7CisgICAgdW5zaWduZWQgbG9uZyBhZGRyID0gKHVuc2lnbmVk
IGxvbmcpcHRyOwogICAgIHVpbnQ4X3QgKnAgPSBwdHI7CiAKLSAgICAqcCsr
ID0gMHhjMzsKKyAgICAvKgorICAgICAqIFdoZW4gUmV0dXJuIFRodW5rcyBh
cmUgdXNlZCwgaWYgYSBSRVQgd291bGQgYmUgdW5zYWZlIGF0IHRoaXMgbG9j
YXRpb24KKyAgICAgKiB3aXRoIHJlc3BlY3QgdG8gSW5kaXJlY3QgVGFyZ2V0
IFNlbGVjdGlvbiAoaS5lLiBpZiBhZGRyIGlzIGluIHRoZSBmaXJzdAorICAg
ICAqIGhhbGYgb2YgYSBjYWNoZWxpbmUpLCBpbnNlcnQgYSBKTVAgX194ODZf
cmV0dXJuX3RodW5rIGluc3RlYWQuCisgICAgICoKKyAgICAgKiBUaGUgZGlz
cGxhY2VtZW50IG5lZWRzIHRvIGJlIHJlbGF0aXZlIHRvIHRoZSBleGVjdXRh
YmxlIGFsaWFzIG9mIHRoZQorICAgICAqIHN0dWIsIG5vdCB0byBAcHRyIHdo
aWNoIGlzIHRoZSB3cml0ZWFibGUgYWxpYXMuCisgICAgICovCisgICAgaWYg
KCBJU19FTkFCTEVEKENPTkZJR19SRVRVUk5fVEhVTkspICYmICEoYWRkciAm
IDB4MjApICkKKyAgICB7CisgICAgICAgIGxvbmcgc3R1Yl92YSA9ICh0aGlz
X2NwdShzdHVicy5hZGRyKSAmIFBBR0VfTUFTSykgKyAoYWRkciAmIH5QQUdF
X01BU0spOworICAgICAgICBsb25nIGRpc3AgPSAobG9uZylfX3g4Nl9yZXR1
cm5fdGh1bmsgLSAoc3R1Yl92YSArIDUpOworCisgICAgICAgIEJVR19PTigo
aW50MzJfdClkaXNwICE9IGRpc3ApOworCisgICAgICAgICpwKysgPSAweGU5
OworICAgICAgICAqKGludDMyX3QgKilwID0gZGlzcDsKKyAgICAgICAgcCAr
PSA0OworICAgIH0KKyAgICBlbHNlCisgICAgeworICAgICAgICAqcCsrID0g
MHhjMzsKKyAgICB9CiAKICAgICByZXR1cm4gcDsKIH0KZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rIGIveGVuL2FyY2gveDg2L2FyY2gubWsK
aW5kZXggMjI3ZDQzOWE0NTIzLi4zNzkzMTdjMDEzMzcgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rCisrKyBiL3hlbi9hcmNoL3g4Ni9hcmNo
Lm1rCkBAIC01MCw2ICs1MCw5IEBAIENGTEFHUy0kKENPTkZJR19DQ19JU19H
Q0MpICs9IC1mbm8tanVtcC10YWJsZXMKIENGTEFHUy0kKENPTkZJR19DQ19J
U19DTEFORykgKz0gLW1yZXRwb2xpbmUtZXh0ZXJuYWwtdGh1bmsKIGVuZGlm
CiAKKyMgQ29tcGlsZSB3aXRoIHJldHVybiB0aHVuayBzdXBwb3J0IGlmIHNl
bGVjdGVkLgorQ0ZMQUdTLSQoQ09ORklHX1JFVFVSTl9USFVOSykgKz0gLW1m
dW5jdGlvbi1yZXR1cm49dGh1bmstZXh0ZXJuCisKIGlmZGVmIENPTkZJR19Y
RU5fSUJUCiAjIEZvcmNlIC1mbm8tanVtcC10YWJsZXMgdG8gd29yayBhcm91
bmQKICMgICBodHRwczovL2djYy5nbnUub3JnL2J1Z3ppbGxhL3Nob3dfYnVn
LmNnaT9pZD0xMDQ4MTYKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGIt
dGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCAwNWYx
MDQzZGY3ZDAuLjQ3MmRhNDgxZGQ0MiAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L2JoYi10aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsu
UwpAQCAtMjMsNyArMjMsNyBAQCBFTlRSWShjbGVhcl9iaGJfdHN4KQogMDog
ICAgICAuYnl0ZSAweGM2LCAweGY4LCAwICAgICAgICAgICAgIC8qIHhhYm9y
dCAkMCAqLwogICAgICAgICBpbnQzCiAxOgotICAgICAgICByZXQKKyAgICAg
ICAgUkVUCiAKICAgICAgICAgLnNpemUgY2xlYXJfYmhiX3RzeCwgLiAtIGNs
ZWFyX2JoYl90c3gKICAgICAgICAgLnR5cGUgY2xlYXJfYmhiX3RzeCwgQGZ1
bmN0aW9uCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvY2xlYXJfcGFnZS5T
IGIveGVuL2FyY2gveDg2L2NsZWFyX3BhZ2UuUwppbmRleCBkOWQ1MjRjNzll
Y2QuLmVhNzBiZDkxNjc2ZSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2Ns
ZWFyX3BhZ2UuUworKysgYi94ZW4vYXJjaC94ODYvY2xlYXJfcGFnZS5TCkBA
IC0xLDUgKzEsNiBAQAogICAgICAgICAuZmlsZSBfX0ZJTEVfXwogCisjaW5j
bHVkZSA8YXNtL2FzbV9kZWZucy5oPgogI2luY2x1ZGUgPGFzbS9wYWdlLmg+
CiAKIEVOVFJZKGNsZWFyX3BhZ2Vfc3NlMikKQEAgLTE1LDQgKzE2LDQgQEAg
RU5UUlkoY2xlYXJfcGFnZV9zc2UyKQogICAgICAgICBqbnogICAgIDBiCiAK
ICAgICAgICAgc2ZlbmNlCi0gICAgICAgIHJldAorICAgICAgICBSRVQKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUyBiL3hlbi9hcmNo
L3g4Ni9jb3B5X3BhZ2UuUwppbmRleCAyZGE4MTEyNmM1ZmEuLmJiNzljNWZj
NzlkYiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2NvcHlfcGFnZS5TCisr
KyBiL3hlbi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUwpAQCAtMSw1ICsxLDYgQEAK
ICAgICAgICAgLmZpbGUgX19GSUxFX18KIAorI2luY2x1ZGUgPGFzbS9hc21f
ZGVmbnMuaD4KICNpbmNsdWRlIDxhc20vcGFnZS5oPgogCiAjZGVmaW5lIHNy
Y19yZWcgJXJzaQpAQCAtNDAsNCArNDEsNCBAQCBFTlRSWShjb3B5X3BhZ2Vf
c3NlMikKICAgICAgICAgbW92bnRpICB0bXA0X3JlZywgMypXT1JEX1NJWkUo
ZHN0X3JlZykKIAogICAgICAgICBzZmVuY2UKLSAgICAgICAgcmV0CisgICAg
ICAgIFJFVApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2VmaS9jaGVjay5j
IGIveGVuL2FyY2gveDg2L2VmaS9jaGVjay5jCmluZGV4IDllNDczZmFhZDNj
OS4uMjNiYTMwYWJmMzMwIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvZWZp
L2NoZWNrLmMKKysrIGIveGVuL2FyY2gveDg2L2VmaS9jaGVjay5jCkBAIC0z
LDYgKzMsOSBAQCBpbnQgX19hdHRyaWJ1dGVfXygoX19tc19hYmlfXykpIHRl
c3QoaW50IGkpCiAgICAgcmV0dXJuIGk7CiB9CiAKKy8qIEluIGNhc2UgLW1m
dW5jdGlvbi1yZXR1cm4gaXMgaW4gdXNlLiAqLwordm9pZCBfX3g4Nl9yZXR1
cm5fdGh1bmsodm9pZCkge307CisKIC8qCiAgKiBQb3B1bGF0ZSBhbiBhcnJh
eSB3aXRoICJhZGRyZXNzZXMiIG9mIHJlbG9jYXRhYmxlIGFuZCBhYnNvbHV0
ZSB2YWx1ZXMuCiAgKiBUaGlzIGlzIHRvIHByb2JlIGxkIGZvciAoYSkgZW1p
dHRpbmcgYmFzZSByZWxvY2F0aW9ucyBhdCBhbGwgYW5kIChiKSBub3QKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hc20tZGVmbnMu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hc20tZGVmbnMuaAppbmRl
eCA3ZTIyZmNiOWMwNmIuLmE5Y2EwZDA1ZWM5OSAxMDA2NDQKLS0tIGEveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1kZWZucy5oCisrKyBiL3hlbi9h
cmNoL3g4Ni9pbmNsdWRlL2FzbS9hc20tZGVmbnMuaApAQCAtNDcsNiArNDcs
MTIgQEAKICAgICAuZW5kaWYKIC5lbmRtCiAKKyNpZmRlZiBDT05GSUdfUkVU
VVJOX1RIVU5LCisjIGRlZmluZSBSRVQgam1wIF9feDg2X3JldHVybl90aHVu
aworI2Vsc2UKKyMgZGVmaW5lIFJFVCByZXQKKyNlbmRpZgorCiAjaWZkZWYg
Q09ORklHX1hFTl9JQlQKICMgZGVmaW5lIEVOREJSNjQgZW5kYnI2NAogI2Vs
c2UKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmRpcmVjdC10aHVuay5T
IGIveGVuL2FyY2gveDg2L2luZGlyZWN0LXRodW5rLlMKaW5kZXggZTdlZjEw
NGQzYmQzLi4yMzljZjdkYzc3MGIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9pbmRpcmVjdC10aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9pbmRpcmVj
dC10aHVuay5TCkBAIC0xMSw2ICsxMSw5IEBACiAKICNpbmNsdWRlIDxhc20v
YXNtX2RlZm5zLmg+CiAKKworI2lmZGVmIENPTkZJR19JTkRJUkVDVF9USFVO
SworCiAubWFjcm8gSU5EX1RIVU5LX1JFVFBPTElORSByZWc6cmVxCiAgICAg
ICAgIGNhbGwgMWYKICAgICAgICAgaW50MwpAQCAtNjAsMyArNjMsMjcgQEAg
RU5UUlkoX194ODZfaW5kaXJlY3RfdGh1bmtfXHJlZykKIC5pcnAgcmVnLCBh
eCwgY3gsIGR4LCBieCwgYnAsIHNpLCBkaSwgOCwgOSwgMTAsIDExLCAxMiwg
MTMsIDE0LCAxNQogICAgICAgICBHRU5fSU5ESVJFQ1RfVEhVTksgcmVnPXJc
cmVnCiAuZW5kcgorCisjZW5kaWYgLyogQ09ORklHX0lORElSRUNUX1RIVU5L
ICovCisKKyNpZmRlZiBDT05GSUdfUkVUVVJOX1RIVU5LCisgICAgICAgIC5z
ZWN0aW9uIC50ZXh0LmVudHJ5Ll9feDg2X3JldHVybl90aHVuaywgImF4Iiwg
QHByb2diaXRzCisKKyAgICAgICAgLyoKKyAgICAgICAgICogVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0CisgICAgICAgICAqIGluZGlyZWN0IGJyYW5jaGVzIChp
bmNsdWRpbmcgUkVUcykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdAor
ICAgICAgICAgKiBoYWxmIG9mIGEgY2FjaGVsaW5lLiAgQXJyYW5nZSBmb3Ig
dGhlbSB0byBiZSBpbiB0aGUgc2Vjb25kIGhhbGYuCisgICAgICAgICAqCisg
ICAgICAgICAqIEFsaWduIHRvIDY0LCB0aGVuIHNraXAgMzIuCisgICAgICAg
ICAqLworICAgICAgICAuYmFsaWduIDY0CisgICAgICAgIC5maWxsIDMyLCAx
LCAweGNjCisKK0VOVFJZKF9feDg2X3JldHVybl90aHVuaykKKyAgICAgICAg
cmV0CisgICAgICAgIGludDMgLyogSGFsdCBzdHJhaWdodC1saW5lIHNwZWN1
bGF0aW9uICovCisKKyAgICAgICAgLnNpemUgX194ODZfcmV0dXJuX3RodW5r
LCAuIC0gX194ODZfcmV0dXJuX3RodW5rCisgICAgICAgIC50eXBlIF9feDg2
X3JldHVybl90aHVuaywgQGZ1bmN0aW9uCisKKyNlbmRpZiAvKiBDT05GSUdf
UkVUVVJOX1RIVU5LICovCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvcHYv
ZW11bC1wcml2LW9wLmMgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9w
LmMKaW5kZXggMjhlYTdjYzU4MGE5Li44NzJhODlkYjc2OWMgMTAwNjQ0Ci0t
LSBhL3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXByaXYtb3AuYworKysgYi94ZW4v
YXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMKQEAgLTE0Myw3ICsxNDMsNyBA
QCBzdGF0aWMgaW9fZW11bF9zdHViX3QgKmlvX2VtdWxfc3R1Yl9zZXR1cChz
dHJ1Y3QgcHJpdl9vcF9jdHh0ICpjdHh0LCB1OCBvcGNvZGUsCiAgICAgQlVJ
TERfQlVHX09OKFNUVUJfQlVGX1NJWkUgLyAyIDwKICAgICAgICAgICAgICAg
ICAgKHNpemVvZihwcm9sb2d1ZSkgKyBzaXplb2YoZXBpbG9ndWUpICsgMTAg
LyogMnggY2FsbCAqLyArCiAgICAgICAgICAgICAgICAgICBNQVgoMyAvKiBk
ZWZhdWx0IHN0dWIgKi8sIElPRU1VTF9RVUlSS19TVFVCX0JZVEVTKSArCi0g
ICAgICAgICAgICAgICAgICAxIC8qIHJldCAqLykpOworICAgICAgICAgICAg
ICAgICAgKElTX0VOQUJMRUQoQ09ORklHX1JFVFVSTl9USFVOSykgPyA1IDog
MSkgLyogcmV0ICovKSk7CiAgICAgLyogUnVudGltZSBjb25maXJtYXRpb24g
dGhhdCB3ZSBoYXZlbid0IGNsb2JiZXJlZCBhbiBhZGphY2VudCBzdHViLiAq
LwogICAgIEJVR19PTihTVFVCX0JVRl9TSVpFIC8gMiA8IChwIC0gY3R4dC0+
aW9fZW11bF9zdHViKSk7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9w
di9ncHJfc3dpdGNoLlMgYi94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5T
CmluZGV4IGU3ZjViZmNkMmQwMy4uZDkwNDM1YmU4ODJlIDEwMDY0NAotLS0g
YS94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5TCisrKyBiL3hlbi9hcmNo
L3g4Ni9wdi9ncHJfc3dpdGNoLlMKQEAgLTI2LDcgKzI2LDcgQEAgRU5UUlko
bG9hZF9ndWVzdF9ncHJzKQogICAgICAgICBtb3ZxICBVUkVHU19yMTUoJXJk
aSksICVyMTUKICAgICAgICAgbW92cSAgVVJFR1NfcmN4KCVyZGkpLCAlcmN4
CiAgICAgICAgIG1vdnEgIFVSRUdTX3JkaSglcmRpKSwgJXJkaQotICAgICAg
ICByZXQKKyAgICAgICAgUkVUCiAKICAgICAgICAgLnNpemUgbG9hZF9ndWVz
dF9ncHJzLCAuIC0gbG9hZF9ndWVzdF9ncHJzCiAgICAgICAgIC50eXBlIGxv
YWRfZ3Vlc3RfZ3BycywgU1RUX0ZVTkMKQEAgLTUxLDcgKzUxLDcgQEAgRU5U
Ulkoc2F2ZV9ndWVzdF9ncHJzKQogICAgICAgICBtb3ZxICAlcmJ4LCBVUkVH
U19yYngoJXJkaSkKICAgICAgICAgbW92cSAgJXJkeCwgVVJFR1NfcmR4KCVy
ZGkpCiAgICAgICAgIG1vdnEgICVyY3gsIFVSRUdTX3JjeCglcmRpKQotICAg
ICAgICByZXQKKyAgICAgICAgUkVUCiAKICAgICAgICAgLnNpemUgc2F2ZV9n
dWVzdF9ncHJzLCAuIC0gc2F2ZV9ndWVzdF9ncHJzCiAgICAgICAgIC50eXBl
IHNhdmVfZ3Vlc3RfZ3BycywgU1RUX0ZVTkMKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu
YwppbmRleCBiMWU0N2E4NDllODcuLjJmNzc3ZThhN2U3NSAxMDA2NDQKLS0t
IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCisrKyBiL3hlbi9hcmNoL3g4
Ni9zcGVjX2N0cmwuYwpAQCAtNTc1LDYgKzU3NSw5IEBAIHN0YXRpYyB2b2lk
IF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rKQog
I2lmZGVmIENPTkZJR19JTkRJUkVDVF9USFVOSwogICAgICAgICAgICAgICAg
IiBJTkRJUkVDVF9USFVOSyIKICNlbmRpZgorI2lmZGVmIENPTkZJR19SRVRV
Uk5fVEhVTksKKyAgICAgICAgICAgICAgICIgUkVUVVJOX1RIVU5LIgorI2Vu
ZGlmCiAjaWZkZWYgQ09ORklHX1NIQURPV19QQUdJTkcKICAgICAgICAgICAg
ICAgICIgU0hBRE9XX1BBR0lORyIKICNlbmRpZgpkaWZmIC0tZ2l0IGEveGVu
L2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUyBiL3hlbi9hcmNoL3g4
Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKaW5kZXggZmY0NjJhOTJlMDAzLi41
N2U1NGRjNzVmYzIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQv
Y29tcGF0L2VudHJ5LlMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21w
YXQvZW50cnkuUwpAQCAtMTgzLDcgKzE4Myw3IEBAIEVOVFJZKGNyNF9wdjMy
X3Jlc3RvcmUpCiAgICAgICAgIG1vdiAgICVyYXgsICVjcjQKICAgICAgICAg
bW92ICAgJXJheCwgKCVyZHgpCiAgICAgICAgIHBvcCAgICVyZHgKLSAgICAg
ICAgcmV0CisgICAgICAgIFJFVAogMDoKICNpZm5kZWYgTkRFQlVHCiAgICAg
ICAgIC8qIENoZWNrIHRoYXQgX2FsbF8gb2YgdGhlIGJpdHMgaW50ZW5kZWQg
dG8gYmUgc2V0IGFjdHVhbGx5IGFyZS4gKi8KQEAgLTIwMiw3ICsyMDIsNyBA
QCBFTlRSWShjcjRfcHYzMl9yZXN0b3JlKQogI2VuZGlmCiAgICAgICAgIHBv
cCAgICVyZHgKICAgICAgICAgeG9yICAgJWVheCwgJWVheAotICAgICAgICBy
ZXQKKyAgICAgICAgUkVUCiAKIEVOVFJZKGNvbXBhdF9zeXNjYWxsKQogICAg
ICAgICAvKiBGaXggdXAgcmVwb3J0ZWQgJWNzLyVzcyBmb3IgY29tcGF0IGRv
bWFpbnMuICovCkBAIC0zMjksNyArMzI5LDcgQEAgX19VTkxJS0VMWV9FTkQo
Y29tcGF0X2JvdW5jZV9udWxsX3NlbGVjdG9yKQogICAgICAgICB4b3IgICAl
ZWF4LCAlZWF4CiAgICAgICAgIG1vdiAgICVheCwgIFRSQVBCT1VOQ0VfY3Mo
JXJkeCkKICAgICAgICAgbW92ICAgJWFsLCAgVFJBUEJPVU5DRV9mbGFncygl
cmR4KQotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAKIC5zZWN0aW9uIC5m
aXh1cCwiYXgiCiAuTGZ4MTM6CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
eDg2XzY0L2VudHJ5LlMgYi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMK
aW5kZXggN2JiMGNjNzA4YTc2Li5mZDYzZWUyZTRjMWYgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUworKysgYi94ZW4vYXJjaC94
ODYveDg2XzY0L2VudHJ5LlMKQEAgLTU5OCw3ICs1OTgsNyBAQCBfX1VOTElL
RUxZX0VORChjcmVhdGVfYm91bmNlX2ZyYW1lX2JhZF9ib3VuY2VfaXApCiAg
ICAgICAgIHhvciAgICVlYXgsICVlYXgKICAgICAgICAgbW92ICAgJXJheCwg
VFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAgICAgbW92ICAgJWFsLCAgVFJB
UEJPVU5DRV9mbGFncyglcmR4KQotICAgICAgICByZXQKKyAgICAgICAgUkVU
CiAKICAgICAgICAgLnB1c2hzZWN0aW9uIC5maXh1cCwgImF4IiwgQHByb2di
aXRzCiAgICAgICAgICMgTnVtZXJpYyB0YWdzIGJlbG93IHJlcHJlc2VudCB0
aGUgaW50ZW5kZWQgb3ZlcmFsbCAlcnNpIGFkanVzdG1lbnQuCmRpZmYgLS1n
aXQgYS94ZW4vYXJjaC94ODYveGVuLmxkcy5TIGIveGVuL2FyY2gveDg2L3hl
bi5sZHMuUwppbmRleCA4OTMwZTE0ZmM0MGUuLmI2NmU3MDhlYmY2OSAxMDA2
NDQKLS0tIGEveGVuL2FyY2gveDg2L3hlbi5sZHMuUworKysgYi94ZW4vYXJj
aC94ODYveGVuLmxkcy5TCkBAIC04Niw2ICs4Niw3IEBAIFNFQ1RJT05TCiAg
ICAgICAgLiA9IEFMSUdOKFBBR0VfU0laRSk7CiAgICAgICAgX3N0ZXh0ZW50
cnkgPSAuOwogICAgICAgICooLnRleHQuZW50cnkpCisgICAgICAgKigudGV4
dC5lbnRyeS4qKQogICAgICAgIC4gPSBBTElHTihQQUdFX1NJWkUpOwogICAg
ICAgIF9ldGV4dGVudHJ5ID0gLjsKIApkaWZmIC0tZ2l0IGEveGVuL2NvbW1v
bi9LY29uZmlnIGIveGVuL2NvbW1vbi9LY29uZmlnCmluZGV4IGNkNzM4NTE1
MzgyMy4uYzgyYmVlOTJmNGNhIDEwMDY0NAotLS0gYS94ZW4vY29tbW9uL0tj
b25maWcKKysrIGIveGVuL2NvbW1vbi9LY29uZmlnCkBAIC0xMTIsNiArMTEy
LDE3IEBAIGNvbmZpZyBJTkRJUkVDVF9USFVOSwogCSAgV2hlbiBlbmFibGVk
LCBpbmRpcmVjdCBicmFuY2hlcyBhcmUgaW1wbGVtZW50ZWQgdXNpbmcgYSBu
ZXcgY29uc3RydWN0CiAJICBjYWxsZWQgInJldHBvbGluZSIgdGhhdCBwcmV2
ZW50cyBzcGVjdWxhdGlvbi4KIAorY29uZmlnIFJFVFVSTl9USFVOSworCWJv
b2wgIk91dC1vZi1saW5lIFJldHVybnMiCisJZGVwZW5kcyBvbiBDQ19IQVNf
UkVUVVJOX1RIVU5LCisJZGVmYXVsdCBJTkRJUkVDVF9USFVOSworCWhlbHAK
KwkgIENvbXBpbGUgWGVuIHdpdGggb3V0LW9mLWxpbmUgcmV0dXJucy4KKwor
CSAgVGhpcyBhbGxvd3MgWGVuIHRvIG1pdGlnYXRlIGEgdmFyaWV0eSBvZiBz
cGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXRpZXMKKwkgIGJ5IGNob29zaW5nIGEg
aGFyZHdhcmUtZGVwZW5kZW50IGluc3RydWN0aW9uIHNlcXVlbmNlIHRvIGlt
cGxlbWVudAorCSAgZnVuY3Rpb24gcmV0dXJucyBzYWZlbHkuCisKIGNvbmZp
ZyBTUEVDVUxBVElWRV9IQVJERU5fQVJSQVkKIAlib29sICJTcGVjdWxhdGl2
ZSBBcnJheSBIYXJkZW5pbmciCiAJZGVmYXVsdCB5Cg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.17-07.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.17-07.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogU3ludGhlc2lzZSBJVFNfTk8g
dG8gZ3Vlc3RzIG9uIHVuYWZmZWN0ZWQgaGFyZHdhcmUKCkl0IGlzIGVhc2ll
ciB0byBleHByZXNzIGZlYXR1cmUgd29yZCAxNyBpbiB0ZXJtcyBvZiB3b3Jk
IDE2ICsgWzMyLCA2NCkgYXMKdGhhdCdzIGhvdyB0aGUgbGF5b3V0IGlzIGdp
dmVuIGluIGRvY3VtZW50YXRpb24uCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2
OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29v
cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKaW5k
ZXggYTZiOGFmMTI5NjRjLi5kOWFlZGZjMjVhYjAgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKKysrIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaApAQCAtMTY0LDYg
KzE2NCw3IEBACiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAgICAgICAgIGJv
b3RfY3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCiAjZGVmaW5lIGNwdV9o
YXNfcmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9S
RkRTX05PKQogI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIgICAgICBib290
X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKKyNkZWZpbmUgY3B1
X2hhc19pdHNfbm8gICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF
X0lUU19OTykKIAogLyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5lIGNwdV9o
YXNfYXJjaF9wZXJmbW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9B
UkNIX1BFUkZNT04pCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXggMmY3Nzdl
OGE3ZTc1Li41NTllZTkwYjQ0ZGMgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMK
QEAgLTE3NjYsNiArMTc2Niw5MCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgYmhp
X2NhbGN1bGF0aW9ucyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAqIGh0dHBz
Oi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZlbG9wZXIv
YXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1aWRhbmNl
L2Fkdmlzb3J5LWd1aWRhbmNlL2luZGlyZWN0LXRhcmdldC1zZWxlY3Rpb24u
aHRtbAorICovCitzdGF0aWMgdm9pZCBfX2luaXQgaXRzX2NhbGN1bGF0aW9u
cyh2b2lkKQoreworICAgIC8qCisgICAgICogSW5kaXJlY3QgVGFyZ2V0IFNl
bGVjdGlvbiBpcyBhIEJyYW5jaCBQcmVkaWN0aW9uIGJ1ZyB3aGVyZWJ5IGNl
cnRhaW4KKyAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVkaW5nIFJF
VHMpIGdldCBwcmVkaWN0ZWQgdXNpbmcgYSBkaXJlY3QgYnJhbmNoCisgICAg
ICogdGFyZ2V0LCByYXRoZXIgdGhhbiBhIHN1aXRhYmxlIGluZGlyZWN0IHRh
cmdldCwgYnlwYXNzaW5nIGhhcmR3YXJlCisgICAgICogaXNvbGF0aW9uIHBy
b3RlY3Rpb25zLgorICAgICAqCisgICAgICogSVRTIGFmZmVjdHMgQ29yZSAo
YnV0IG5vdCBBdG9tKSBwcm9jZXNzb3JzIHN0YXJ0aW5nIGZyb20gdGhlCisg
ICAgICogaW50cm9kdWN0aW9uIG9mIGVJQlJTLCB1cCB0byBidXQgbm90IGlu
Y2x1ZGluZyBHb2xkZW4gQ292ZSBjb3JlcworICAgICAqIChjaGVja2VkIGhl
cmUgd2l0aCBCSElfQ1RSTCkuCisgICAgICoKKyAgICAgKiBUaGUgSVRTX05P
IGZlYXR1cmUgaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVudW1lcmF0ZWQgYnkg
aGFyZHdhcmUsIGFuZCBpcworICAgICAqIG9ubHkgZm9yIFZNTXMgdG8gc3lu
dGhlc2lzZSBmb3IgZ3Vlc3RzLgorICAgICAqCisgICAgICogSVRTIGNvbWVz
IGluIDMgZmxhdm91cnM6CisgICAgICoKKyAgICAgKiAgIDEpIEFjcm9zcy1J
QlBCLiAgSW5kaXJlY3QgYnJhbmNoZXMgYWZ0ZXIgdGhlIElCUEIgY2FuIGJl
IGNvbnRyb2xsZWQKKyAgICAgKiAgICAgIGJ5IGRpcmVjdCB0YXJnZXRzIHdo
aWNoIGV4aXN0ZWQgcHJpb3IgdG8gdGhlIElCUEIuICBUaGlzIGlzCisgICAg
ICogICAgICBhZGRyZXNzZWQgaW4gdGhlIElQVSAyMDI1LjEgbWljcm9jb2Rl
IGRyb3AsIGFuZCBoYXMgbm8gb3RoZXIKKyAgICAgKiAgICAgIHNvZnR3YXJl
IGludGVyYWN0aW9uLgorICAgICAqCisgICAgICogICAyKSBHdWVzdC9Ib3N0
LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUgY29udHJv
bGxlZCBieQorICAgICAqICAgICAgZGlyZWN0IHRhcmdldHMgZnJvbSB0aGUg
Z3Vlc3QuICBUaGlzIGFwcGxpZXMgZXF1YWxseSB0byBQViBndWVzdHMKKyAg
ICAgKiAgICAgIChSaW5nMykgYW5kIEhWTSBndWVzdHMgKFZNWCksIGFuZCBh
cHBsaWVzIHRvIGFsbCBTa3lsYWtlLXVhcmNoCisgICAgICogICAgICBjb3Jl
cyB3aXRoIGVJQlJTLgorICAgICAqCisgICAgICogICAzKSBJbnRyYS1tb2Rl
LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUgY29udHJv
bGxlZCBieQorICAgICAqICAgICAgb3RoZXIgZXhlY3V0aW9uIGluIHRoZSBz
YW1lIG1vZGUuCisgICAgICovCisKKyAgICAvKgorICAgICAqIElmIHdlIGNh
biBzZWUgSVRTX05PLCBvciB3ZSdyZSB2aXJ0dWFsaXNlZCwgZG8gbm90aGlu
Zy4gIFdlIGFyZSBvciBtYXkKKyAgICAgKiBtaWdyYXRlIHNvbWV3aGVyZSB1
bnNhZmUuCisgICAgICovCisgICAgaWYgKCBjcHVfaGFzX2l0c19ubyB8fCBj
cHVfaGFzX2h5cGVydmlzb3IgKQorICAgICAgICByZXR1cm47CisKKyAgICAv
KiBJVFMgaXMgb25seSBrbm93biB0byBhZmZlY3QgSW50ZWwgcHJvY2Vzc29y
cyBhdCB0aGlzIHRpbWUuICovCisgICAgaWYgKCBib290X2NwdV9kYXRhLng4
Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9JTlRFTCApCisgICAgICAgIHJldHVy
bjsKKworICAgIC8qCisgICAgICogSVRTIGRvZXMgbm90IGV4aXN0IG9uOgor
ICAgICAqICAtIG5vbi1GYW1pbHkgNiBDUFVzCisgICAgICogIC0gdGhvc2Ug
d2l0aG91dCBlSUJSUworICAgICAqICAtIHRob3NlIHdpdGggQkhJX0NUUkwK
KyAgICAgKiBidXQgd2Ugc3RpbGwgbmVlZCB0byBzeW50aGVzaXNlIElUU19O
Ty4KKyAgICAgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2ICE9IDYg
fHwgIWNwdV9oYXNfZWlicnMgfHwKKyAgICAgICAgIGJvb3RfY3B1X2hhcyhY
ODZfRkVBVFVSRV9CSElfQ1RSTCkgKQorICAgICAgICBnb3RvIHN5bnRoZXNp
c2U7CisKKyAgICBzd2l0Y2ggKCBib290X2NwdV9kYXRhLng4Nl9tb2RlbCAp
CisgICAgeworICAgICAgICAvKiBUaGVzZSBTa3lsYWtlLXVhcmNoIGNvcmVz
IHN1ZmZlciBjYXNlcyAjMiBhbmQgIzMuICovCisgICAgY2FzZSBJTlRFTF9G
QU02X1NLWUxBS0VfWDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0Vf
TDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0U6CisgICAgY2FzZSBJ
TlRFTF9GQU02X0NPTUVUTEFLRToKKyAgICBjYXNlIElOVEVMX0ZBTTZfQ09N
RVRMQUtFX0w6CisgICAgICAgIHJldHVybjsKKworICAgICAgICAvKiBUaGVz
ZSBTdW5ueS9XaWxsb3cvQ3lwcmVzcyBDb3ZlIGNvcmVzIHN1ZmZlciBjYXNl
ICMzLiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9JQ0VMQUtFX1g6CisgICAg
Y2FzZSBJTlRFTF9GQU02X0lDRUxBS0VfRDoKKyAgICBjYXNlIElOVEVMX0ZB
TTZfSUNFTEFLRV9MOgorICAgIGNhc2UgSU5URUxfRkFNNl9USUdFUkxBS0Vf
TDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfVElHRVJMQUtFOgorICAgIGNhc2Ug
SU5URUxfRkFNNl9ST0NLRVRMQUtFOgorICAgICAgICByZXR1cm47CisKKyAg
ICBkZWZhdWx0OgorICAgICAgICBicmVhazsKKyAgICB9CisKKyAgICAvKiBQ
bGF0Zm9ybXMgcmVtYWluaW5nIGFyZSBub3QgYmVsaWV2ZWQgdG8gYmUgdnVs
bmVyYWJsZSB0byBJVFMuICovCisgc3ludGhlc2lzZToKKyAgICBzZXR1cF9m
b3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX0lUU19OTyk7Cit9CisKIHZvaWQg
c3BlY19jdHJsX2luaXRfZG9tYWluKHN0cnVjdCBkb21haW4gKmQpCiB7CiAg
ICAgYm9vbCBwdiA9IGlzX3B2X2RvbWFpbihkKTsKQEAgLTIzMTYsNiArMjQw
MCw4IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0aWdhdGlv
bnModm9pZCkKIAogICAgIGJoaV9jYWxjdWxhdGlvbnMoKTsKIAorICAgIGl0
c19jYWxjdWxhdGlvbnMoKTsKKwogICAgIHByaW50X2RldGFpbHModGh1bmsp
OwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9h
cmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9wdWJsaWMv
YXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IDAwMDRmZDRiZjU2ZS4u
OTljNGRjMWZmZDQwIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
YXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTMzNCw3ICszMzQs
OCBAQCBYRU5fQ1BVRkVBVFVSRShHRFNfTk8sICAgICAgICAgICAgIDE2KjMy
KzI2KSAvKkEgIE5vIEdhdGhlciBEYXRhIFNhbXBsaW5nICovCiBYRU5fQ1BV
RkVBVFVSRShSRkRTX05PLCAgICAgICAgICAgIDE2KjMyKzI3KSAvKkEgIE5v
IFJlZ2lzdGVyIEZpbGUgRGF0YSBTYW1wbGluZyAqLwogWEVOX0NQVUZFQVRV
UkUoUkZEU19DTEVBUiwgICAgICAgICAxNiozMisyOCkgLyohQSBSZWdpc3Rl
ciBGaWxlKHMpIGNsZWFyZWQgYnkgVkVSVyAqLwogCi0vKiBJbnRlbC1kZWZp
bmVkIENQVSBmZWF0dXJlcywgTVNSX0FSQ0hfQ0FQUyAweDEwYS5lZHgsIHdv
cmQgMTcgKi8KKy8qIEludGVsLWRlZmluZWQgQ1BVIGZlYXR1cmVzLCBNU1Jf
QVJDSF9DQVBTIDB4MTBhLmVkeCwgd29yZCAxNyAoZXhwcmVzcyBpbiB0ZXJt
cyBvZiB3b3JkIDE2KSAqLworWEVOX0NQVUZFQVRVUkUoSVRTX05PLCAgICAg
ICAgICAgICAxNiozMis2MikgLyohQSBObyBJbmRpcmVjdCBUYXJnZXQgU2Vs
ZWN0aW9uICovCiAKICNlbmRpZiAvKiBYRU5fQ1BVRkVBVFVSRSAqLwogCmRp
ZmYgLS1naXQgYS94ZW4vdG9vbHMvZ2VuLWNwdWlkLnB5IGIveGVuL3Rvb2xz
L2dlbi1jcHVpZC5weQppbmRleCA0MTViOGIxZDY4ODEuLjA1YjFjMTNlYzQ3
OCAxMDA3NTUKLS0tIGEveGVuL3Rvb2xzL2dlbi1jcHVpZC5weQorKysgYi94
ZW4vdG9vbHMvZ2VuLWNwdWlkLnB5CkBAIC01MSw3ICs1MSw3IEBAIGRlZiBw
YXJzZV9kZWZpbml0aW9ucyhzdGF0ZSk6CiAgICAgICAgIHIiXHMrL1wqKFtc
dyFdKikgLiokIikKIAogICAgIHdvcmRfcmVnZXggPSByZS5jb21waWxlKAot
ICAgICAgICByIl4vXCogLiogd29yZCAoXGQqKSBcKi8kIikKKyAgICAgICAg
ciJeL1wqIC4qIHdvcmQgKFxkKikgLipcKi8kIikKICAgICBsYXN0X3dvcmQg
PSAtMQogCiAgICAgdGhpcyA9IHN5cy5tb2R1bGVzW19fbmFtZV9fXQo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-01.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-01.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2FsdGVybmF0aXZlOiBTdXBwb3J0IHJlcGxhY2Vt
ZW50cyB3aGVuIGEgZmVhdHVyZSBpcyBub3QgcHJlc2VudAoKVXNlIHRoZSB0
b3AgYml0IG9mIGEtPmNwdWlkIHRvIGV4cHJlc3MgaW52ZXJ0ZWQgcG9sYXJp
dHkuICBUaGlzIHJlcXVpcmVzCnN0cmlwcGluZyB0aGUgdG9wIGJpdCBiYWNr
IG91dCB3aGVuIHBlcmZvcm1pbmcgdGhlIHNhbml0eSBjaGVja3MuCgpEZXNw
aXRlIG9ubHkgYmVpbmcgdXNlZCBvbmNlLCBjcmVhdGUgYSByZXBsYWNlIGJv
b2xlYW4gdG8gZXhwcmVzcyB0aGUgZGVjaXNpb24KbW9yZSBjbGVhcmx5IGlu
IF9hcHBseV9hbHRlcm5hdGl2ZXMoKS4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0t
Z2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94
ODYvYWx0ZXJuYXRpdmUuYwppbmRleCA5MWI2MDg2NWJmM2IuLjkwYmY5YTky
YmZmOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMK
KysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTE5Nyw2ICsx
OTcsOCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBseV9h
bHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAgICAg
IHVpbnQ4X3QgKnJlcGwgPSBBTFRfUkVQTF9QVFIoYSk7CiAgICAgICAgIHVp
bnQ4X3QgYnVmW01BWF9QQVRDSF9MRU5dOwogICAgICAgICB1bnNpZ25lZCBp
bnQgdG90YWxfbGVuID0gYS0+b3JpZ19sZW4gKyBhLT5wYWRfbGVuOworICAg
ICAgICB1bnNpZ25lZCBpbnQgZmVhdCA9IGEtPmNwdWlkICYgfkFMVF9GTEFH
X05PVDsKKyAgICAgICAgYm9vbCBpbnYgPSBhLT5jcHVpZCAmIEFMVF9GTEFH
X05PVCwgcmVwbGFjZTsKIAogICAgICAgICBpZiAoIGEtPnJlcGxfbGVuID4g
dG90YWxfbGVuICkKICAgICAgICAgewpAQCAtMjE0LDExICsyMTYsMTEgQEAg
c3RhdGljIGludCBpbml0X29yX2xpdmVwYXRjaCBfYXBwbHlfYWx0ZXJuYXRp
dmVzKHN0cnVjdCBhbHRfaW5zdHIgKnN0YXJ0LAogICAgICAgICAgICAgcmV0
dXJuIC1FTk9TUEM7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAoIGEtPmNw
dWlkID49IE5DQVBJTlRTICogMzIgKQorICAgICAgICBpZiAoIGZlYXQgPj0g
TkNBUElOVFMgKiAzMiApCiAgICAgICAgIHsKICAgICAgICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUgogICAgICAgICAgICAgICAgICAgICJBbHQgZm9yICVw
cywgZmVhdHVyZSAlI3ggb3V0c2lkZSBvZiBmZWF0dXJlc2V0IHJhbmdlICUj
eFxuIiwKLSAgICAgICAgICAgICAgICAgICBBTFRfT1JJR19QVFIoYSksIGEt
PmNwdWlkLCBOQ0FQSU5UUyAqIDMyKTsKKyAgICAgICAgICAgICAgICAgICBB
TFRfT1JJR19QVFIoYSksIGZlYXQsIE5DQVBJTlRTICogMzIpOwogICAgICAg
ICAgICAgcmV0dXJuIC1FUkFOR0U7CiAgICAgICAgIH0KIApAQCAtMjQzLDgg
KzI0NSwxNCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAg
ICAgICAgICBjb250aW51ZTsKICAgICAgICAgfQogCisgICAgICAgIC8qCisg
ICAgICAgICAqIFNob3VsZCBhIHJlcGxhY2VtZW50IGJlIHBlcmZvcm1lZD8g
IE1vc3QgcmVwbGFjZW1lbnRzIGhhdmUgcG9zaXRpdmUKKyAgICAgICAgICog
cG9sYXJpdHksIGJ1dCB3ZSBzdXBwb3J0IG5lZ2F0aXZlIHBvbGFyaXR5IHRv
by4KKyAgICAgICAgICovCisgICAgICAgIHJlcGxhY2UgPSBib290X2NwdV9o
YXMoZmVhdCkgXiBpbnY7CisKICAgICAgICAgLyogSWYgdGhlcmUgaXMgbm8g
cmVwbGFjZW1lbnQgdG8gbWFrZSwgc2VlIGFib3V0IG9wdGltaXNpbmcgdGhl
IG5vcHMuICovCi0gICAgICAgIGlmICggIWJvb3RfY3B1X2hhcyhhLT5jcHVp
ZCkgKQorICAgICAgICBpZiAoICFyZXBsYWNlICkKICAgICAgICAgewogICAg
ICAgICAgICAgLyogT3JpZ2luIHNpdGUgc2l0ZSBhbHJlYWR5IHRvdWNoZWQ/
ICBEb24ndCBub3AgYW55dGhpbmcuICovCiAgICAgICAgICAgICBpZiAoIGJh
c2UtPnByaXYgKQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v
YWx0ZXJuYXRpdmUuaAppbmRleCA2OTU1NWQ3ODFlZjkuLjg5YjdiZGNiODJl
NSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKQEAgLTEsNiArMSwxMyBAQAogI2lmbmRlZiBfX1g4Nl9BTFRF
Uk5BVElWRV9IX18KICNkZWZpbmUgX19YODZfQUxURVJOQVRJVkVfSF9fCiAK
Ky8qCisgKiBDb21tb24gdG8gYm90aCBDIGFuZCBBU00uICBFeHByZXNzIGEg
cmVwbGFjZW1lbnQgd2hlbiBhIGZlYXR1cmUgaXMgbm90CisgKiBhdmFpbGFi
bGUuCisgKi8KKyNkZWZpbmUgQUxUX0ZMQUdfTk9UICgxIDw8IDE1KQorI2Rl
ZmluZSBBTFRfTk9UKHgpIChBTFRfRkxBR19OT1QgfCAoeCkpCisKICNpZmRl
ZiBfX0FTU0VNQkxZX18KICNpbmNsdWRlIDxhc20vYWx0ZXJuYXRpdmUtYXNt
Lmg+CiAjZWxzZQpAQCAtMTEsNyArMTgsNyBAQAogc3RydWN0IF9fcGFja2Vk
IGFsdF9pbnN0ciB7CiAgICAgaW50MzJfdCAgb3JpZ19vZmZzZXQ7ICAgLyog
b3JpZ2luYWwgaW5zdHJ1Y3Rpb24gKi8KICAgICBpbnQzMl90ICByZXBsX29m
ZnNldDsgICAvKiBvZmZzZXQgdG8gcmVwbGFjZW1lbnQgaW5zdHJ1Y3Rpb24g
Ki8KLSAgICB1aW50MTZfdCBjcHVpZDsgICAgICAgICAvKiBjcHVpZCBiaXQg
c2V0IGZvciByZXBsYWNlbWVudCAqLworICAgIHVpbnQxNl90IGNwdWlkOyAg
ICAgICAgIC8qIGNwdWlkIGJpdCBzZXQgZm9yIHJlcGxhY2VtZW50ICh0b3Ag
Yml0IGlzIHBvbGFyaXR5KSAqLwogICAgIHVpbnQ4X3QgIG9yaWdfbGVuOyAg
ICAgIC8qIGxlbmd0aCBvZiBvcmlnaW5hbCBpbnN0cnVjdGlvbiAqLwogICAg
IHVpbnQ4X3QgIHJlcGxfbGVuOyAgICAgIC8qIGxlbmd0aCBvZiBuZXcgaW5z
dHJ1Y3Rpb24gKi8KICAgICB1aW50OF90ICBwYWRfbGVuOyAgICAgICAvKiBs
ZW5ndGggb2YgYnVpbGQtdGltZSBwYWRkaW5nICovCgo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-02.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-02.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2d1ZXN0OiBSZW1vdmUgdXNlIG9mIHRoZSBYZW4g
aHlwZXJjYWxsX3BhZ2UKCkluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCBJ
VFMsIFhlbiBuZWVkcyB0byBzdGFydCB1c2luZyByZXR1cm4gdGh1bmtzLgpU
aGVyZWZvcmUgdGhlIGFkdmljZSBpbiBYU0EtNDY2IGJlY29tZXMgcmVsZXZh
bnQsIGFuZCB0aGUgaHlwZXJjYWxsX3BhZ2UgbmVlZHMKdG8gYmUgcmVtb3Zl
ZC4KCkltcGxlbWVudCBlYXJseV9oeXBlcmNhbGwoKSwgd2l0aCBpbmZyYXN0
cnVjdHVyZSB0byBmaWd1cmUgb3V0IHRoZSBjb3JyZWN0Cmluc3RydWN0aW9u
IG9uIGZpcnN0IHVzZS4gIFVzZSBBTFRFUk5BVElWRSgpcyB0byByZXN1bHQg
aW4gaW5saW5lIGh5cGVyY2FsbHMsCmluY2x1ZGluZyB0aGUgQUxUX05PVCgp
IGZvcm0gc28gd2Ugb25seSBuZWVkIGEgc2luZ2xlIHN5bnRoZXRpYyBmZWF0
dXJlIGJpdC4KCk5vIG92ZXJhbGwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0IG9m
IFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTogQW5k
cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3
ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9ndWVzdC94ZW4vTWFrZWZp
bGUgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCmluZGV4IDI2
ZmI0YjEwMDdjMC4uOGIzMjUwYWE4ODg2IDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCisrKyBiL3hlbi9hcmNoL3g4Ni9n
dWVzdC94ZW4vTWFrZWZpbGUKQEAgLTEsNCArMSw0IEBACi1vYmoteSArPSBo
eXBlcmNhbGxfcGFnZS5vCitvYmotYmluLXkgKz0gaHlwZXJjYWxsLmluaXQu
bwogb2JqLXkgKz0geGVuLm8KIAogb2JqLWJpbi0kKENPTkZJR19QVkhfR1VF
U1QpICs9IHB2aC1ib290LmluaXQubwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGwuUyBiL3hlbi9hcmNoL3g4Ni9ndWVz
dC94ZW4vaHlwZXJjYWxsLlMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg
MDAwMDAwMDAwMDAwLi40N2FiNjg1Y2Y4NDgKLS0tIC9kZXYvbnVsbAorKysg
Yi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbC5TCkBAIC0wLDAg
KzEsNTIgQEAKKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4w
LW9yLWxhdGVyICovCisKKyNpbmNsdWRlIDxhc20vYXNtX2RlZm5zLmg+CisK
KyAgICAgICAgLnNlY3Rpb24gLmluaXQudGV4dCwgImF4IiwgQHByb2diaXRz
CisKKyAgICAgICAgLyoKKyAgICAgICAgICogVXNlZCBkdXJpbmcgZWFybHkg
Ym9vdCwgYmVmb3JlIGFsdGVybmF0aXZlcyBoYXZlIHJ1biBhbmQgaW5saW5l
ZAorICAgICAgICAgKiB0aGUgYXBwcm9wcmlhdGUgaW5zdHJ1Y3Rpb24uICBD
YWxsZWQgdXNpbmcgdGhlIGh5cGVyY2FsbCBBQkkuCisgICAgICAgICAqLwor
RU5UUlkoZWFybHlfaHlwZXJjYWxsKQorICAgICAgICBjbXBiICAgICQwLCBl
YXJseV9oeXBlcmNhbGxfaW5zbiglcmlwKQorICAgICAgICBqbCAgICAgIC5M
X3NldHVwCisgICAgICAgIGplICAgICAgMWYKKworICAgICAgICB2bW1jYWxs
CisgICAgICAgIHJldAorCisxOiAgICAgIHZtY2FsbAorICAgICAgICByZXQK
KworLkxfc2V0dXA6CisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gc2V0
dGluZyB1cCB0aGUgZmlyc3QgdGltZSBhcm91bmQsIGFsbCByZWdpc3RlcnMg
bmVlZAorICAgICAgICAgKiBwcmVzZXJ2aW5nLiAgU2F2ZSB0aGUgbm9uLWNh
bGxlZS1zYXZlZCBvbmVzLgorICAgICAgICAgKi8KKyAgICAgICAgcHVzaCAg
ICAlcjExCisgICAgICAgIHB1c2ggICAgJXIxMAorICAgICAgICBwdXNoICAg
ICVyOQorICAgICAgICBwdXNoICAgICVyOAorICAgICAgICBwdXNoICAgICVy
ZGkKKyAgICAgICAgcHVzaCAgICAlcnNpCisgICAgICAgIHB1c2ggICAgJXJk
eAorICAgICAgICBwdXNoICAgICVyY3gKKyAgICAgICAgcHVzaCAgICAlcmF4
CisKKyAgICAgICAgY2FsbCAgICBlYXJseV9oeXBlcmNhbGxfc2V0dXAKKwor
ICAgICAgICBwb3AgICAgICVyYXgKKyAgICAgICAgcG9wICAgICAlcmN4Cisg
ICAgICAgIHBvcCAgICAgJXJkeAorICAgICAgICBwb3AgICAgICVyc2kKKyAg
ICAgICAgcG9wICAgICAlcmRpCisgICAgICAgIHBvcCAgICAgJXI4CisgICAg
ICAgIHBvcCAgICAgJXI5CisgICAgICAgIHBvcCAgICAgJXIxMAorICAgICAg
ICBwb3AgICAgICVyMTEKKworICAgICAgICBqbXAgICAgIGVhcmx5X2h5cGVy
Y2FsbAorCisgICAgICAgIC50eXBlIGVhcmx5X2h5cGVyY2FsbCwgQGZ1bmN0
aW9uCisgICAgICAgIC5zaXplIGVhcmx5X2h5cGVyY2FsbCwgLiAtIGVhcmx5
X2h5cGVyY2FsbApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2d1ZXN0L3hl
bi9oeXBlcmNhbGxfcGFnZS5TIGIveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi9o
eXBlcmNhbGxfcGFnZS5TCmRlbGV0ZWQgZmlsZSBtb2RlIDEwMDY0NAppbmRl
eCA5OTU4ZDAyY2ZkNWIuLjAwMDAwMDAwMDAwMAotLS0gYS94ZW4vYXJjaC94
ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbF9wYWdlLlMKKysrIC9kZXYvbnVsbApA
QCAtMSw3OCArMCwwIEBACi0jaW5jbHVkZSA8YXNtL3BhZ2UuaD4KLSNpbmNs
dWRlIDxhc20vYXNtX2RlZm5zLmg+Ci0jaW5jbHVkZSA8cHVibGljL3hlbi5o
PgotCi0gICAgICAgIC5zZWN0aW9uICIudGV4dC5wYWdlX2FsaWduZWQiLCAi
YXgiLCBAcHJvZ2JpdHMKLSAgICAgICAgLnAyYWxpZ24gUEFHRV9TSElGVAot
Ci1HTE9CQUwoaHlwZXJjYWxsX3BhZ2UpCi0gICAgICAgICAvKiBQb2lzb25l
ZCB3aXRoIGByZXRgIGZvciBzYWZldHkgYmVmb3JlIGh5cGVyY2FsbHMgYXJl
IHNldCB1cC4gKi8KLSAgICAgICAgLmZpbGwgUEFHRV9TSVpFLCAxLCAweGMz
Ci0gICAgICAgIC50eXBlIGh5cGVyY2FsbF9wYWdlLCBTVFRfT0JKRUNUCi0g
ICAgICAgIC5zaXplIGh5cGVyY2FsbF9wYWdlLCBQQUdFX1NJWkUKLQotLyoK
LSAqIElkZW50aWZ5IGEgc3BlY2lmaWMgaHlwZXJjYWxsIGluIHRoZSBoeXBl
cmNhbGwgcGFnZQotICogQHBhcmFtIG5hbWUgSHlwZXJjYWxsIG5hbWUuCi0g
Ki8KLSNkZWZpbmUgREVDTEFSRV9IWVBFUkNBTEwobmFtZSkgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAotICAg
ICAgICAuZ2xvYmwgSFlQRVJDQUxMXyAjIyBuYW1lOyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgICAgIC50
eXBlICBIWVBFUkNBTExfICMjIG5hbWUsIFNUVF9GVU5DOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgLnNpemUgIEhZ
UEVSQ0FMTF8gIyMgbmFtZSwgMzI7ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXAotICAgICAgICAuc2V0ICAgSFlQRVJDQUxM
XyAjIyBuYW1lLCBoeXBlcmNhbGxfcGFnZSArIF9fSFlQRVJWSVNPUl8gIyMg
bmFtZSAqIDMyCi0KLURFQ0xBUkVfSFlQRVJDQUxMKHNldF90cmFwX3RhYmxl
KQotREVDTEFSRV9IWVBFUkNBTEwobW11X3VwZGF0ZSkKLURFQ0xBUkVfSFlQ
RVJDQUxMKHNldF9nZHQpCi1ERUNMQVJFX0hZUEVSQ0FMTChzdGFja19zd2l0
Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChzZXRfY2FsbGJhY2tzKQotREVDTEFS
RV9IWVBFUkNBTEwoZnB1X3Rhc2tzd2l0Y2gpCi1ERUNMQVJFX0hZUEVSQ0FM
TChzY2hlZF9vcF9jb21wYXQpCi1ERUNMQVJFX0hZUEVSQ0FMTChwbGF0Zm9y
bV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHNldF9kZWJ1Z3JlZykKLURFQ0xB
UkVfSFlQRVJDQUxMKGdldF9kZWJ1Z3JlZykKLURFQ0xBUkVfSFlQRVJDQUxM
KHVwZGF0ZV9kZXNjcmlwdG9yKQotREVDTEFSRV9IWVBFUkNBTEwobWVtb3J5
X29wKQotREVDTEFSRV9IWVBFUkNBTEwobXVsdGljYWxsKQotREVDTEFSRV9I
WVBFUkNBTEwodXBkYXRlX3ZhX21hcHBpbmcpCi1ERUNMQVJFX0hZUEVSQ0FM
TChzZXRfdGltZXJfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChldmVudF9jaGFu
bmVsX29wX2NvbXBhdCkKLURFQ0xBUkVfSFlQRVJDQUxMKHhlbl92ZXJzaW9u
KQotREVDTEFSRV9IWVBFUkNBTEwoY29uc29sZV9pbykKLURFQ0xBUkVfSFlQ
RVJDQUxMKHBoeXNkZXZfb3BfY29tcGF0KQotREVDTEFSRV9IWVBFUkNBTEwo
Z3JhbnRfdGFibGVfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTCh2bV9hc3Npc3Qp
Ci1ERUNMQVJFX0hZUEVSQ0FMTCh1cGRhdGVfdmFfbWFwcGluZ19vdGhlcmRv
bWFpbikKLURFQ0xBUkVfSFlQRVJDQUxMKGlyZXQpCi1ERUNMQVJFX0hZUEVS
Q0FMTCh2Y3B1X29wKQotREVDTEFSRV9IWVBFUkNBTEwoc2V0X3NlZ21lbnRf
YmFzZSkKLURFQ0xBUkVfSFlQRVJDQUxMKG1tdWV4dF9vcCkKLURFQ0xBUkVf
SFlQRVJDQUxMKHhzbV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKG5taV9vcCkK
LURFQ0xBUkVfSFlQRVJDQUxMKHNjaGVkX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoY2FsbGJhY2tfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTCh4ZW5vcHJvZl9v
cCkKLURFQ0xBUkVfSFlQRVJDQUxMKGV2ZW50X2NoYW5uZWxfb3ApCi1ERUNM
QVJFX0hZUEVSQ0FMTChwaHlzZGV2X29wKQotREVDTEFSRV9IWVBFUkNBTEwo
aHZtX29wKQotREVDTEFSRV9IWVBFUkNBTEwoc3lzY3RsKQotREVDTEFSRV9I
WVBFUkNBTEwoZG9tY3RsKQotREVDTEFSRV9IWVBFUkNBTEwoa2V4ZWNfb3Ap
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmdvX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoeGVucG11X29wKQotCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzApCi1E
RUNMQVJFX0hZUEVSQ0FMTChhcmNoXzEpCi1ERUNMQVJFX0hZUEVSQ0FMTChh
cmNoXzIpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzMpCi1ERUNMQVJFX0hZ
UEVSQ0FMTChhcmNoXzQpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzUpCi1E
RUNMQVJFX0hZUEVSQ0FMTChhcmNoXzYpCi1ERUNMQVJFX0hZUEVSQ0FMTChh
cmNoXzcpCi0KLS8qCi0gKiBMb2NhbCB2YXJpYWJsZXM6Ci0gKiB0YWItd2lk
dGg6IDgKLSAqIGluZGVudC10YWJzLW1vZGU6IG5pbAotICogRW5kOgotICov
CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL3hlbi5jIGIv
eGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94ZW4uYwppbmRleCA0NGE2ODlkNDM5
NGIuLjMwNmY4OGVmNmFkZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2d1
ZXN0L3hlbi94ZW4uYworKysgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL3hl
bi5jCkBAIC0yNiw3ICsyNiw2IEBACiBib29sIF9fcmVhZF9tb3N0bHkgeGVu
X2d1ZXN0OwogCiB1aW50MzJfdCBfX3JlYWRfbW9zdGx5IHhlbl9jcHVpZF9i
YXNlOwotZXh0ZXJuIGNoYXIgaHlwZXJjYWxsX3BhZ2VbXTsKIHN0YXRpYyBz
dHJ1Y3QgcmFuZ2VzZXQgKm1lbTsKIAogREVGSU5FX1BFUl9DUFUodW5zaWdu
ZWQgaW50LCB2Y3B1X2lkKTsKQEAgLTM1LDYgKzM0LDUwIEBAIHN0YXRpYyBz
dHJ1Y3QgdmNwdV9pbmZvICp2Y3B1X2luZm87CiBzdGF0aWMgdW5zaWduZWQg
bG9uZyB2Y3B1X2luZm9fbWFwcGVkW0JJVFNfVE9fTE9OR1MoTlJfQ1BVUyld
OwogREVGSU5FX1BFUl9DUFUoc3RydWN0IHZjcHVfaW5mbyAqLCB2Y3B1X2lu
Zm8pOwogCisvKgorICogV2hpY2ggaW5zdHJ1Y3Rpb24gdG8gdXNlIGZvciBl
YXJseSBoeXBlcmNhbGxzOgorICogICA8IDAgc2V0dXAKKyAqICAgICAwIHZt
Y2FsbAorICogICA+IDAgdm1tY2FsbAorICovCitpbnQ4X3QgX19pbml0ZGF0
YSBlYXJseV9oeXBlcmNhbGxfaW5zbiA9IC0xOworCisvKgorICogQ2FsbGVk
IG9uY2UgZHVyaW5nIHRoZSBmaXJzdCBoeXBlcmNhbGwgdG8gZmlndXJlIG91
dCB3aGljaCBpbnN0cnVjdGlvbiB0bworICogdXNlLiAgRXJyb3IgaGFuZGxp
bmcgb3B0aW9ucyBhcmUgbGltaXRlZC4KKyAqLwordm9pZCBfX2luaXQgZWFy
bHlfaHlwZXJjYWxsX3NldHVwKHZvaWQpCit7CisgICAgQlVHX09OKGVhcmx5
X2h5cGVyY2FsbF9pbnNuICE9IC0xKTsKKworICAgIGlmICggIWJvb3RfY3B1
X2RhdGEueDg2X3ZlbmRvciApCisgICAgeworICAgICAgICB1bnNpZ25lZCBp
bnQgZWF4LCBlYngsIGVjeCwgZWR4OworCisgICAgICAgIGNwdWlkKDAsICZl
YXgsICZlYngsICZlY3gsICZlZHgpOworCisgICAgICAgIGJvb3RfY3B1X2Rh
dGEueDg2X3ZlbmRvciA9IHg4Nl9jcHVpZF9sb29rdXBfdmVuZG9yKGVieCwg
ZWN4LCBlZHgpOworICAgIH0KKworICAgIHN3aXRjaCAoIGJvb3RfY3B1X2Rh
dGEueDg2X3ZlbmRvciApCisgICAgeworICAgIGNhc2UgWDg2X1ZFTkRPUl9J
TlRFTDoKKyAgICBjYXNlIFg4Nl9WRU5ET1JfQ0VOVEFVUjoKKyAgICBjYXNl
IFg4Nl9WRU5ET1JfU0hBTkdIQUk6CisgICAgICAgIGVhcmx5X2h5cGVyY2Fs
bF9pbnNuID0gMDsKKyAgICAgICAgc2V0dXBfZm9yY2VfY3B1X2NhcChYODZf
RkVBVFVSRV9VU0VfVk1DQUxMKTsKKyAgICAgICAgYnJlYWs7CisKKyAgICBj
YXNlIFg4Nl9WRU5ET1JfQU1EOgorICAgIGNhc2UgWDg2X1ZFTkRPUl9IWUdP
TjoKKyAgICAgICAgZWFybHlfaHlwZXJjYWxsX2luc24gPSAxOworICAgICAg
ICBicmVhazsKKworICAgIGRlZmF1bHQ6CisgICAgICAgIEJVRygpOworICAg
IH0KK30KKwogc3RhdGljIHZvaWQgX19pbml0IGZpbmRfeGVuX2xlYXZlcyh2
b2lkKQogewogICAgIHVpbnQzMl90IGVheCwgZWJ4LCBlY3gsIGVkeCwgYmFz
ZTsKQEAgLTMzNyw5ICszODAsNiBAQCBjb25zdCBzdHJ1Y3QgaHlwZXJ2aXNv
cl9vcHMgKl9faW5pdCB4Z19wcm9iZSh2b2lkKQogICAgIGlmICggIXhlbl9j
cHVpZF9iYXNlICkKICAgICAgICAgcmV0dXJuIE5VTEw7CiAKLSAgICAvKiBG
aWxsIHRoZSBoeXBlcmNhbGwgcGFnZS4gKi8KLSAgICB3cm1zcmwoY3B1aWRf
ZWJ4KHhlbl9jcHVpZF9iYXNlICsgMiksIF9fcGEoaHlwZXJjYWxsX3BhZ2Up
KTsKLQogICAgIHhlbl9ndWVzdCA9IHRydWU7CiAKICAgICByZXR1cm4gJm9w
czsKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVm
ZWF0dXJlcy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1
cmVzLmgKaW5kZXggYmEzZGYxNzRiNzZlLi45ZTNlZDIxYzAyNmQgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5o
CisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlcy5o
CkBAIC00Miw2ICs0Miw3IEBAIFhFTl9DUFVGRUFUVVJFKFhFTl9TSFNUSywg
ICAgICAgICBYODZfU1lOVEgoMjYpKSAvKiBYZW4gdXNlcyBDRVQgU2hhZG93
IFN0YWNrcyAqCiBYRU5fQ1BVRkVBVFVSRShYRU5fSUJULCAgICAgICAgICAg
WDg2X1NZTlRIKDI3KSkgLyogWGVuIHVzZXMgQ0VUIEluZGlyZWN0IEJyYW5j
aCBUcmFja2luZyAqLwogWEVOX0NQVUZFQVRVUkUoSUJQQl9FTlRSWV9QViwg
ICAgIFg4Nl9TWU5USCgyOCkpIC8qIE1TUl9QUkVEX0NNRCB1c2VkIGJ5IFhl
biBmb3IgUFYgKi8KIFhFTl9DUFVGRUFUVVJFKElCUEJfRU5UUllfSFZNLCAg
ICBYODZfU1lOVEgoMjkpKSAvKiBNU1JfUFJFRF9DTUQgdXNlZCBieSBYZW4g
Zm9yIEhWTSAqLworWEVOX0NQVUZFQVRVUkUoVVNFX1ZNQ0FMTCwgICAgICAg
IFg4Nl9TWU5USCgzMCkpIC8qIFVzZSBWTUNBTEwgaW5zdGVhZCBvZiBWTU1D
QUxMICovCiAKIC8qIEJ1ZyB3b3JkcyBmb2xsb3cgdGhlIHN5bnRoZXRpYyB3
b3Jkcy4gKi8KICNkZWZpbmUgWDg2X05SX0JVRyAxCmRpZmYgLS1naXQgYS94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmggYi94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmgKaW5k
ZXggNjY1YjQ3MmQwNWFjLi45NjAwNGRlYzk5MDkgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaAorKysg
Yi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZ3Vlc3QveGVuLWhjYWxsLmgK
QEAgLTMwLDkgKzMwLDExIEBACiAgICAgKHsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgICAgIGxvbmcgcmVzLCB0bXBfXzsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGFz
bSB2b2xhdGlsZSAoICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICAiY2FsbCBoeXBlcmNh
bGxfcGFnZSArICVjW29mZnNldF0iICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCisgICAgICAgICAgICBBTFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5
cGVyY2FsbCIsICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICJ2bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVS
RV9VU0VfVk1DQUxMKSwgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICJ2bWNhbGwiLCBYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAg
ICBcCiAgICAgICAgICAgICA6ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSBB
U01fQ0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICBcCi0gICAgICAgICAg
ICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiksICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICA6ICIwIiAoaGNhbGwp
LCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcpKGExKSkgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgICh0eXBlKXJlczsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCkBAIC00MiwxMCArNDQsMTIgQEAKICAgICAoeyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICAgICAgbG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgYXNtIHZvbGF0aWxlICggICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgICJjYWxsIGh5
cGVyY2FsbF9wYWdlICsgJWNbb2Zmc2V0XSIgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICAgICAgICAgIEFMVEVSTkFUSVZFXzIoImNhbGwgZWFy
bHlfaHlwZXJjYWxsIiwgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgInZtbWNhbGwiLCBBTFRfTk9UKFg4Nl9G
RUFUVVJFX1VTRV9WTUNBTEwpLCAgIFwKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgInZtY2FsbCIsIFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwpICAgICAg
ICAgICAgIFwKICAgICAgICAgICAgIDogIj1hIiAocmVzKSwgIj1EIiAodG1w
X18pLCAiPVMiICh0bXBfXykgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgICAgICAgQVNNX0NBTExfQ09OU1RSQUlOVCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgIDogW29mZnNl
dF0gImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2FsbCksICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg
ICAgICAgICAgIjEiICgobG9uZykoYTEpKSwgIjIiICgobG9uZykoYTIpKSAg
ICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9y
eSIgKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICAgICAgKHR5cGUpcmVzOyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKQEAgLTU1
LDEwICs1OSwxMiBAQAogICAgICh7ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAog
ICAgICAgICBsb25nIHJlcywgdG1wX187ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBhc20gdm9s
YXRpbGUgKCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAotICAgICAgICAgICAgImNhbGwgaHlwZXJjYWxsX3Bh
Z2UgKyAlY1tvZmZzZXRdIiAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICAgICAgQUxURVJOQVRJVkVfMigiY2FsbCBlYXJseV9oeXBlcmNh
bGwiLCAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAg
ICAgICAgICAgICAidm1tY2FsbCIsIEFMVF9OT1QoWDg2X0ZFQVRVUkVfVVNF
X1ZNQ0FMTCksICAgXAorICAgICAgICAgICAgICAgICAgICAgICAgICAidm1j
YWxsIiwgWDg2X0ZFQVRVUkVfVVNFX1ZNQ0FMTCkgICAgICAgICAgICAgXAog
ICAgICAgICAgICAgOiAiPWEiIChyZXMpLCAiPUQiICh0bXBfXyksICI9UyIg
KHRtcF9fKSwgIj1kIiAodG1wX18pICAgICAgXAogICAgICAgICAgICAgICBB
U01fQ0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXAotICAgICAgICAgICAgOiBbb2Zmc2V0XSAiaSIgKGhj
YWxsICogMzIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAor
ICAgICAgICAgICAgOiAiMCIgKGhjYWxsKSwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAi
MSIgKChsb25nKShhMSkpLCAiMiIgKChsb25nKShhMikpLCAiMyIgKChsb25n
KShhMykpICAgICAgXAogICAgICAgICAgICAgOiAibWVtb3J5IiApOyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAog
ICAgICAgICAodHlwZSlyZXM7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgXApAQCAtNjksMTAgKzc1LDEy
IEBACiAgICAgICAgIGxvbmcgcmVzLCB0bXBfXzsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIHJl
Z2lzdGVyIGxvbmcgX2E0IGFzbSAoInIxMCIpID0gKChsb25nKShhNCkpOyAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCi0gICAgICAgICAgICAiY2FsbCBoeXBlcmNhbGxfcGFnZSArICVjW29m
ZnNldF0iICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICBBTFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5cGVyY2FsbCIsICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICJ2bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSwg
ICBcCisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2bWNhbGwiLCBYODZf
RkVBVFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSwgIj1TIiAodG1wX18pLCAi
PWQiICh0bXBfXyksICAgICBcCiAgICAgICAgICAgICAgICI9JnIiICh0bXBf
XykgQVNNX0NBTExfQ09OU1RSQUlOVCAgICAgICAgICAgICAgICAgICAgICAg
ICBcCi0gICAgICAgICAgICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiks
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAg
ICA6ICIwIiAoaGNhbGwpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcp
KGExKSksICIyIiAoKGxvbmcpKGEyKSksICIzIiAoKGxvbmcpKGEzKSksICAg
ICBcCiAgICAgICAgICAgICAgICI0IiAoX2E0KSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAg
ICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-03.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-03.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IChNaXMpYWxpZ24gX194ODZfaW5kaXJlY3RfdGh1bmtf
KiB0byBtaXRpZ2F0ZSBJVFMKClRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRp
cmVjdApicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hl
biBpbiB0aGUgZmlyc3QgaGFsZiBvZiBhIGNhY2hlbGluZS4KCkFycmFuZ2Ug
Zm9yIF9feDg2X2luZGlyZWN0X3RodW5rXyogdG8gYWx3YXlzIGJlIGluIHRo
ZSBzZWNvbmQgaGFsZi4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDY5IC8gQ1ZF
LTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TCmluZGV4IGRlNmFlZjYwNjgzMi4uZTdlZjEwNGQzYmQz
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwor
KysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMzUsNiAr
MzUsMTYgQEAKIC5tYWNybyBHRU5fSU5ESVJFQ1RfVEhVTksgcmVnOnJlcQog
ICAgICAgICAuc2VjdGlvbiAudGV4dC5fX3g4Nl9pbmRpcmVjdF90aHVua19c
cmVnLCAiYXgiLCBAcHJvZ2JpdHMKIAorICAgICAgICAvKgorICAgICAgICAg
KiBUaGUgSW5kaXJlY3QgVGFyZ2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2
dWxuZXJhYmlsaXR5IG1lYW5zIHRoYXQKKyAgICAgICAgICogaW5kaXJlY3Qg
YnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUgdW5zYWZlIHdoZW4gaW4g
dGhlIGZpcnN0CisgICAgICAgICAqIGhhbGYgb2YgYSBjYWNoZWxpbmUuICBB
cnJhbmdlIGZvciB0aGVtIHRvIGJlIGluIHRoZSBzZWNvbmQgaGFsZi4KKyAg
ICAgICAgICoKKyAgICAgICAgICogQWxpZ24gdG8gNjQsIHRoZW4gc2tpcCAz
Mi4KKyAgICAgICAgICovCisgICAgICAgIC5iYWxpZ24gNjQKKyAgICAgICAg
LmZpbGwgMzIsIDEsIDB4Y2MKKwogRU5UUlkoX194ODZfaW5kaXJlY3RfdGh1
bmtfXHJlZykKICAgICAgICAgQUxURVJOQVRJVkVfMiBfX3N0cmluZ2lmeShJ
TkRfVEhVTktfUkVUUE9MSU5FIFxyZWcpLCAgICAgICAgICAgICAgXAogICAg
ICAgICBfX3N0cmluZ2lmeShJTkRfVEhVTktfTEZFTkNFIFxyZWcpLCBYODZf
RkVBVFVSRV9JTkRfVEhVTktfTEZFTkNFLCBcCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-04.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-04.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3RodW5rOiAoTWlzKWFsaWduIHRoZSBSRVRzIGlu
IGNsZWFyX2JoYl9sb29wcygpIHRvIG1pdGlnYXRlIElUUwoKVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0IGluZGlyZWN0CmJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdCBoYWxmIG9mIGEgY2Fj
aGVsaW5lLgoKY2xlYXJfYmhiX2xvb3BzKCkgaGFzIGEgcHJlY2lzZSBsYXlv
dXQgb2YgYnJhbmNoZXMuICBUaGUgYWxpZ25tZW50IGZvcgpwZXJmb3JtYW5j
ZSBjYXVzZSB0aGUgUkVUcyB0byBhbHdheXMgYmUgaW4gYW4gdW5zYWZlIHBv
c2l0aW9uLCBhbmQgY29udmVydGluZwp0aG9zZSB0byByZXR1cm4gdGh1bmtz
IGNoYW5nZXMgdGhlIGJyYW5jaGluZyBwYXR0ZXJuLiAgV2hpbGUgc3VjaCBh
IGNvbnZlcnNpb24KaXMgYmVsaWV2ZWQgdG8gYmUgc2FmZSwgY2xlYXJfYmhi
X2xvb3BzKCkgaXMgYWxzbyBhIHBlcmZvcm1hbmNlLXJlbGV2YW50CmZhc3Rw
YXRoLCBzbyAobWlzKWFsaWduIHRoZSBSRVRzIHRvIGJlIGluIGEgc2FmZSBw
b3NpdGlvbi4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0
IG9mIFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUyBi
L3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCA3ZTg2Njc4NGY3ODQu
LjA1ZjEwNDNkZjdkMCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2JoYi10
aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwpAQCAtNTIs
NyArNTIsMTIgQEAgRU5UUlkoY2xlYXJfYmhiX3RzeCkKICAqICAgcmV0CiAg
KgogICogVGhlIENBTEwvUkVUcyBhcmUgbmVjZXNzYXJ5IHRvIHByZXZlbnQg
dGhlIExvb3AgU3RyZWFtIERldGVjdG9yIGZyb20KLSAqIGludGVyZmVyaW5n
LiAgVGhlIGFsaWdubWVudCBpcyBmb3IgcGVyZm9ybWFuY2UgYW5kIG5vdCBz
YWZldHkuCisgKiBpbnRlcmZlcmluZy4KKyAqCisgKiBUaGUgLmJhbGlnbidz
IGFyZSBmb3IgcGVyZm9ybWFuY2UsIGJ1dCB0aGV5IGNhdXNlIHRoZSBSRVRz
IHRvIGJlIGluIHVuc2FmZQorICogcG9zaXRpb25zIHdpdGggcmVzcGVjdCB0
byBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uLiAgVGhlIC5za2lwcyBhcmUg
dG8KKyAqIG1vdmUgdGhlIFJFVHMgaW50byBJVFMtc2FmZSBwb3NpdGlvbnMs
IHJhdGhlciB0aGFuIHVzaW5nIHRoZSBzbG93cGF0aAorICogdGhyb3VnaCBf
X3g4Nl9yZXR1cm5fdGh1bmsuCiAgKgogICogVGhlICJzaG9ydCIgc2VxdWVu
Y2UgKDUgYW5kIDUpIGlzIGZvciBDUFVzIHByaW9yIHRvIEFsZGVyIExha2Ug
LyBTYXBwaGlyZQogICogUmFwaWRzIChpLmUuIENvcmVzIHByaW9yIHRvIEdv
bGRlbiBDb3ZlIGFuZC9vciBHcmFjZW1vbnQpLgpAQCAtNjgsMTIgKzczLDE0
IEBAIEVOVFJZKGNsZWFyX2JoYl9sb29wcykKICAgICAgICAgam1wICAgICA1
ZgogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAgICAg
IC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtICguTHIxIC0gMWYp
LCAweGNjCiAxOiAgICAgIGNhbGwgICAgMmYKLSAgICAgICAgcmV0CisuTHIx
OiAgIHJldAogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0Cisg
ICAgICAgIC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtIDE4IC8q
ICguTHIyIC0gMmYpIGJ1dCBDbGFuZyBJQVMgZG9lc24ndCBsaWtlIHRoaXMg
Ki8sIDB4Y2MKIDI6ICAgICAgQUxURVJOQVRJVkUgIm1vdiAkNSwgJWVheCIs
ICJtb3YgJDcsICVlYXgiLCBYODZfU1BFQ19CSEJfTE9PUFNfTE9ORwogCiAz
OiAgICAgIGptcCAgICAgNGYKQEAgLTg1LDcgKzkyLDcgQEAgRU5UUlkoY2xl
YXJfYmhiX2xvb3BzKQogICAgICAgICBzdWIgICAgICQxLCAlZWN4CiAgICAg
ICAgIGpueiAgICAgMWIKIAotICAgICAgICByZXQKKy5McjI6ICAgcmV0CiA1
OgogICAgICAgICAvKgogICAgICAgICAgKiBUaGUgSW50ZWwgc2VxdWVuY2Ug
aGFzIGFuIExGRU5DRSBoZXJlLiAgVGhlIHB1cnBvc2UgaXMgdG8gZW5zdXJl
Cg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-05.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-05.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3N0dWJzOiBJbnRyb2R1Y2UgcGxhY2VfcmV0KCkg
dG8gYWJzdHJhY3QgYXdheSByYXcgMHhjMydzCgpUaGUgSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5z
IHRoYXQgaW5kaXJlY3QKYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUg
dW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0IGhhbGYgb2YgYSBjYWNoZWxpbmUu
ClRoaXMgbWVhbnMgaXQncyBub3Qgc2FmZSBmb3IgbG9naWMgdXNpbmcgdGhl
IHN0dWJzIHRvIHdyaXRlIHJhdyAweGMzJ3MuCgpJbnRyb2R1Y2UgcGxhY2Vf
cmV0KCkgd2hpY2gsIGZvciBub3csIHdyaXRlcyBhIHJhdyAweGMzIGJ1dCB3
aWxsIGNvbnRhaW4KYWRkaXRpb25hbCBsb2dpYyB3aGVuIHJldHVybiB0aHVu
a3MgYXJlIGluIHVzZS4KCnN0dWJfc2VsZnRlc3QoKSBkb2Vzbid0IHN0cmlj
dGx5IG5lZWQgdG8gYmUgY29udmVydGVkIGFzIHRoZXkgb25seSBydW4gb24K
Ym9vdCwgYnV0IGRvaW5nIHNvIGdldHMgdXMgYSBwYXJ0aWFsIHRlc3Qgb2Yg
cGxhY2VfcmV0KCkgdG9vLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ2OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQt
b2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu
Y29tPgpSZXZpZXdlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvdG9vbHMvdGVzdHMveDg2X2Vt
dWxhdG9yL3g4Ni1lbXVsYXRlLmggYi90b29scy90ZXN0cy94ODZfZW11bGF0
b3IveDg2LWVtdWxhdGUuaAppbmRleCAzNGYwODU1MTE0OTcuLjE0ODNhNWE4
ODgwOSAxMDA2NDQKLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKKysrIGIvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKQEAgLTY4LDYgKzY4LDEyIEBACiAKICNkZWZpbmUgaXNf
Y2Fub25pY2FsX2FkZHJlc3MoeCkgKCgoaW50NjRfdCkoeCkgPj4gNDcpID09
ICgoaW50NjRfdCkoeCkgPj4gNjMpKQogCitzdGF0aWMgaW5saW5lIHZvaWQg
KnBsYWNlX3JldCh2b2lkICpwdHIpCit7CisgICAgKih1aW50OF90ICopcHRy
ID0gMHhjMzsKKyAgICByZXR1cm4gcHRyICsgMTsKK30KKwogZXh0ZXJuIHVp
bnQzMl90IG14Y3NyX21hc2s7CiBleHRlcm4gc3RydWN0IGNwdV9wb2xpY3kg
Y3A7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hl
bi9hcmNoL3g4Ni9NYWtlZmlsZQppbmRleCBlOGE0YmY1OWMzNGYuLjdkZjg3
N2EwOWQzZiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisr
KyBiL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtMTEsOSArMTEsNyBAQCBv
YmotJChDT05GSUdfUFYpICs9IHB2Lwogb2JqLXkgKz0geDg2XzY0Lwogb2Jq
LXkgKz0geDg2X2VtdWxhdGUvCiAKLWFsdGVybmF0aXZlLXkgOj0gYWx0ZXJu
YXRpdmUuaW5pdC5vCi1hbHRlcm5hdGl2ZS0kKENPTkZJR19MSVZFUEFUQ0gp
IDo9Ci1vYmotYmluLXkgKz0gJChhbHRlcm5hdGl2ZS15KQorb2JqLXkgKz0g
YWx0ZXJuYXRpdmUubwogb2JqLXkgKz0gYXBpYy5vCiBvYmoteSArPSBiaGIt
dGh1bmsubwogb2JqLXkgKz0gYml0b3BzLm8KQEAgLTQyLDcgKzQwLDcgQEAg
b2JqLXkgKz0gaHlwZXJjYWxsLm8KIG9iai15ICs9IGkzODcubwogb2JqLXkg
Kz0gaTgyNTkubwogb2JqLXkgKz0gaW9fYXBpYy5vCi1vYmotJChDT05GSUdf
TElWRVBBVENIKSArPSBhbHRlcm5hdGl2ZS5vIGxpdmVwYXRjaC5vCitvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9hbHRlcm5hdGl2ZS5jIGIveGVuL2FyY2gveDg2L2FsdGVybmF0
aXZlLmMKaW5kZXggOTBiZjlhOTJiZmY5Li5iZTE5NTc3MjM0NzIgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCkBAIC0xMzcsNiArMTM3LDIwIEBAIHZv
aWQgaW5pdF9vcl9saXZlcGF0Y2ggYWRkX25vcHModm9pZCAqaW5zbnMsIHVu
c2lnbmVkIGludCBsZW4pCiAgICAgfQogfQogCisvKgorICogUGxhY2UgYSBy
ZXR1cm4gYXQgQHB0ci4gIEBwdHIgbXVzdCBiZSBpbiB0aGUgd3JpdGFibGUg
YWxpYXMgb2YgYSBzdHViLgorICoKKyAqIFJldHVybnMgdGhlIG5leHQgcG9z
aXRpb24gdG8gd3JpdGUgaW50byB0aGUgc3R1Yi4KKyAqLwordm9pZCAqcGxh
Y2VfcmV0KHZvaWQgKnB0cikKK3sKKyAgICB1aW50OF90ICpwID0gcHRyOwor
CisgICAgKnArKyA9IDB4YzM7CisKKyAgICByZXR1cm4gcDsKK30KKwogLyoK
ICAqIHRleHRfcG9rZSAtIFVwZGF0ZSBpbnN0cnVjdGlvbnMgb24gYSBsaXZl
IGtlcm5lbCBvciBub24tZXhlY3V0ZWQgY29kZS4KICAqIEBhZGRyOiBhZGRy
ZXNzIHRvIG1vZGlmeQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2V4dGFi
bGUuYyBiL3hlbi9hcmNoL3g4Ni9leHRhYmxlLmMKaW5kZXggMTJjYzk5MzVk
ODg1Li4xNmJmMmNjNjJiODkgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9l
eHRhYmxlLmMKKysrIGIveGVuL2FyY2gveDg2L2V4dGFibGUuYwpAQCAtMTM1
LDIwICsxMzUsMjAgQEAgc2VhcmNoX2V4Y2VwdGlvbl90YWJsZShjb25zdCBz
dHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncywgdW5zaWduZWQgbG9uZyAqc3R1
Yl9yYSkKIGludCBfX2luaXQgY2ZfY2hlY2sgc3R1Yl9zZWxmdGVzdCh2b2lk
KQogewogICAgIHN0YXRpYyBjb25zdCBzdHJ1Y3QgewotICAgICAgICB1aW50
OF90IG9wY1s4XTsKKyAgICAgICAgdWludDhfdCBvcGNbN107CiAgICAgICAg
IHVpbnQ2NF90IHJheDsKICAgICAgICAgdW5pb24gc3R1Yl9leGNlcHRpb25f
dG9rZW4gcmVzOwogICAgIH0gdGVzdHNbXSBfX2luaXRjb25zdCA9IHsKICNk
ZWZpbmUgZW5kYnI2NCAweGYzLCAweDBmLCAweDFlLCAweGZhCi0gICAgICAg
IHsgLm9wYyA9IHsgZW5kYnI2NCwgMHgwZiwgMHhiOSwgMHhjMywgMHhjMyB9
LCAvKiB1ZDEgKi8KKyAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDBm
LCAweGI5LCAweDkwIH0sIC8qIHVkMSAqLwogICAgICAgICAgIC5yZXMuZmll
bGRzLnRyYXBuciA9IFg4Nl9FWENfVUQgfSwKLSAgICAgICAgeyAub3BjID0g
eyBlbmRicjY0LCAweDkwLCAweDAyLCAweDAwLCAweGMzIH0sIC8qIG5vcDsg
YWRkICglcmF4KSwlYWwgKi8KKyAgICAgICAgeyAub3BjID0geyBlbmRicjY0
LCAweDkwLCAweDAyLCAweDAwIH0sIC8qIG5vcDsgYWRkICglcmF4KSwlYWwg
Ki8KICAgICAgICAgICAucmF4ID0gMHgwMTIzNDU2Nzg5YWJjZGVmLAogICAg
ICAgICAgIC5yZXMuZmllbGRzLnRyYXBuciA9IFg4Nl9FWENfR1AgfSwKLSAg
ICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDAyLCAweDA0LCAweDA0LCAw
eGMzIH0sIC8qIGFkZCAoJXJzcCwlcmF4KSwlYWwgKi8KKyAgICAgICAgeyAu
b3BjID0geyBlbmRicjY0LCAweDAyLCAweDA0LCAweDA0IH0sIC8qIGFkZCAo
JXJzcCwlcmF4KSwlYWwgKi8KICAgICAgICAgICAucmF4ID0gMHhmZWRjYmE5
ODc2NTQzMjEwLAogICAgICAgICAgIC5yZXMuZmllbGRzLnRyYXBuciA9IFg4
Nl9FWENfU1MgfSwKLSAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweGNj
LCAweGMzLCAweGMzLCAweGMzIH0sIC8qIGludDMgKi8KKyAgICAgICAgeyAu
b3BjID0geyBlbmRicjY0LCAweGNjLCAweDkwLCAweDkwIH0sIC8qIGludDMg
Ki8KICAgICAgICAgICAucmVzLmZpZWxkcy50cmFwbnIgPSBYODZfRVhDX0JQ
IH0sCiAjdW5kZWYgZW5kYnI2NAogICAgIH07CkBAIC0xNjcsNiArMTY3LDcg
QEAgaW50IF9faW5pdCBjZl9jaGVjayBzdHViX3NlbGZ0ZXN0KHZvaWQpCiAK
ICAgICAgICAgbWVtc2V0KHB0ciwgMHhjYywgU1RVQl9CVUZfU0laRSAvIDIp
OwogICAgICAgICBtZW1jcHkocHRyLCB0ZXN0c1tpXS5vcGMsIEFSUkFZX1NJ
WkUodGVzdHNbaV0ub3BjKSk7CisgICAgICAgIHBsYWNlX3JldChwdHIgKyBB
UlJBWV9TSVpFKHRlc3RzW2ldLm9wYykpOwogICAgICAgICB1bm1hcF9kb21h
aW5fcGFnZShwdHIpOwogCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICJJTkRJ
UkVDVF9DQUxMICVbc3RiXVxuIgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2
L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmggYi94ZW4vYXJjaC94ODYvaW5j
bHVkZS9hc20vYWx0ZXJuYXRpdmUuaAppbmRleCA4OWI3YmRjYjgyZTUuLjg0
MWE2M2ViZjFiNiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLmgKQEAgLTMwLDYgKzMwLDggQEAgc3RydWN0IF9f
cGFja2VkIGFsdF9pbnN0ciB7CiAjZGVmaW5lIEFMVF9SRVBMX1BUUihhKSAg
ICAgX19BTFRfUFRSKGEsIHJlcGxfb2Zmc2V0KQogCiBleHRlcm4gdm9pZCBh
ZGRfbm9wcyh2b2lkICppbnNucywgdW5zaWduZWQgaW50IGxlbik7Cit2b2lk
ICpwbGFjZV9yZXQodm9pZCAqcHRyKTsKKwogLyogU2ltaWxhciB0byBhbHRl
cm5hdGl2ZV9pbnN0cnVjdGlvbnMgZXhjZXB0IGl0IGNhbiBiZSBydW4gd2l0
aCBJUlFzIGVuYWJsZWQuICovCiBleHRlcm4gaW50IGFwcGx5X2FsdGVybmF0
aXZlcyhzdHJ1Y3QgYWx0X2luc3RyICpzdGFydCwgc3RydWN0IGFsdF9pbnN0
ciAqZW5kKTsKIGV4dGVybiB2b2lkIGFsdGVybmF0aXZlX2luc3RydWN0aW9u
cyh2b2lkKTsKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXBy
aXYtb3AuYyBiL3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXByaXYtb3AuYwppbmRl
eCA3MDE1MGMyNzIyNzYuLmZmNWQxYzlmODYzNCAxMDA2NDQKLS0tIGEveGVu
L2FyY2gveDg2L3B2L2VtdWwtcHJpdi1vcC5jCisrKyBiL3hlbi9hcmNoL3g4
Ni9wdi9lbXVsLXByaXYtb3AuYwpAQCAtNzYsNyArNzYsNiBAQCBzdGF0aWMg
aW9fZW11bF9zdHViX3QgKmlvX2VtdWxfc3R1Yl9zZXR1cChzdHJ1Y3QgcHJp
dl9vcF9jdHh0ICpjdHh0LCB1OCBvcGNvZGUsCiAgICAgICAgIDB4NDEsIDB4
NWMsIC8qIHBvcCAlcjEyICAqLwogICAgICAgICAweDVkLCAgICAgICAvKiBw
b3AgJXJicCAgKi8KICAgICAgICAgMHg1YiwgICAgICAgLyogcG9wICVyYngg
ICovCi0gICAgICAgIDB4YzMsICAgICAgIC8qIHJldCAgICAgICAqLwogICAg
IH07CiAKICAgICBjb25zdCBzdHJ1Y3Qgc3R1YnMgKnRoaXNfc3R1YnMgPSAm
dGhpc19jcHUoc3R1YnMpOwpAQCAtMTI2LDExICsxMjUsMTMgQEAgc3RhdGlj
IGlvX2VtdWxfc3R1Yl90ICppb19lbXVsX3N0dWJfc2V0dXAoc3RydWN0IHBy
aXZfb3BfY3R4dCAqY3R4dCwgdTggb3Bjb2RlLAogCiAgICAgQVBQRU5EX0NB
TEwoc2F2ZV9ndWVzdF9ncHJzKTsKICAgICBBUFBFTkRfQlVGRihlcGlsb2d1
ZSk7CisgICAgcCA9IHBsYWNlX3JldChwKTsKIAogICAgIC8qIEJ1aWxkLXRp
bWUgYmVzdCBlZmZvcnQgYXR0ZW1wdCB0byBjYXRjaCBwcm9ibGVtcy4gKi8K
ICAgICBCVUlMRF9CVUdfT04oU1RVQl9CVUZfU0laRSAvIDIgPAogICAgICAg
ICAgICAgICAgICAoc2l6ZW9mKHByb2xvZ3VlKSArIHNpemVvZihlcGlsb2d1
ZSkgKyAxMCAvKiAyeCBjYWxsICovICsKLSAgICAgICAgICAgICAgICAgIE1B
WCgzIC8qIGRlZmF1bHQgc3R1YiAqLywgSU9FTVVMX1FVSVJLX1NUVUJfQllU
RVMpKSk7CisgICAgICAgICAgICAgICAgICBNQVgoMyAvKiBkZWZhdWx0IHN0
dWIgKi8sIElPRU1VTF9RVUlSS19TVFVCX0JZVEVTKSArCisgICAgICAgICAg
ICAgICAgICAxIC8qIHJldCAqLykpOwogICAgIC8qIFJ1bnRpbWUgY29uZmly
bWF0aW9uIHRoYXQgd2UgaGF2ZW4ndCBjbG9iYmVyZWQgYW4gYWRqYWNlbnQg
c3R1Yi4gKi8KICAgICBCVUdfT04oU1RVQl9CVUZfU0laRSAvIDIgPCAocCAt
IGN0eHQtPmlvX2VtdWxfc3R1YikpOwogCmRpZmYgLS1naXQgYS94ZW4vYXJj
aC94ODYveDg2X2VtdWxhdGUvZnB1LmMgYi94ZW4vYXJjaC94ODYveDg2X2Vt
dWxhdGUvZnB1LmMKaW5kZXggNDgwZDg3OTY1NzA1Li4wMzYxMmQwMGEyY2Ug
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfZW11bGF0ZS9mcHUuYwor
KysgYi94ZW4vYXJjaC94ODYveDg2X2VtdWxhdGUvZnB1LmMKQEAgLTMyLDM2
ICszMiw0MiBAQCBzdGF0aWMgaW5saW5lIGJvb2wgZnB1X2NoZWNrX3dyaXRl
KHZvaWQpCiAKICNkZWZpbmUgZW11bGF0ZV9mcHVfaW5zbl9tZW1kc3Qob3Bj
LCBleHQsIGFyZykgICAgICAgICAgICAgICAgICAgICAgICAgIFwKIGRvIHsg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICB2b2lkICpfcCA9IGdldF9z
dHViKHN0dWIpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICAvKiBNb2RSTTogbW9kPTAsIHJlZz1leHQsIHJtPTAs
IGkuZS4gYSAoJXJheCkgb3BlcmFuZCAqLyAgICAgICAgICAgIFwKICAgICAq
aW5zbl9ieXRlcyA9IDI7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICBtZW1jcHkoZ2V0X3N0dWIo
c3R1YiksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKLSAgICAgICAgICAgKCh1aW50OF90W10peyBvcGMsICgoZXh0
KSAmIDcpIDw8IDMsIDB4YzMgfSksIDMpOyAgICAgICAgICAgIFwKKyAgICBt
ZW1jcHkoX3AsICgodWludDhfdFtdKXsgb3BjLCAoKGV4dCkgJiA3KSA8PCAz
IH0pLCAyKTsgX3AgKz0gMjsgICAgIFwKKyAgICBwbGFjZV9yZXQoX3ApOyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKGFyZykg
OiAiYSIgKCYoYXJnKSkpOyAgICAgICAgICAgICAgICAgICAgIFwKICAgICBw
dXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKIH0gd2hpbGUgKDApCiAKICNkZWZp
bmUgZW11bGF0ZV9mcHVfaW5zbl9tZW1zcmMob3BjLCBleHQsIGFyZykgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKIGRvIHsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICB2b2lkICpfcCA9IGdldF9zdHViKHN0dWIpOyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAv
KiBNb2RSTTogbW9kPTAsIHJlZz1leHQsIHJtPTAsIGkuZS4gYSAoJXJheCkg
b3BlcmFuZCAqLyAgICAgICAgICAgIFwKLSAgICBtZW1jcHkoZ2V0X3N0dWIo
c3R1YiksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKLSAgICAgICAgICAgKCh1aW50OF90W10peyBvcGMsICgoZXh0
KSAmIDcpIDw8IDMsIDB4YzMgfSksIDMpOyAgICAgICAgICAgIFwKKyAgICBt
ZW1jcHkoX3AsICgodWludDhfdFtdKXsgb3BjLCAoKGV4dCkgJiA3KSA8PCAz
IH0pLCAyKTsgX3AgKz0gMjsgICAgIFwKKyAgICBwbGFjZV9yZXQoX3ApOyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKGR1bW15
KSA6ICJtIiAoYXJnKSwgImEiICgmKGFyZykpKTsgICAgICAgIFwKICAgICBw
dXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKIH0gd2hpbGUgKDApCiAKICNkZWZp
bmUgZW11bGF0ZV9mcHVfaW5zbl9zdHViKGJ5dGVzLi4uKSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKIGRvIHsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKKyAgICB2b2lkICpfcCA9IGdldF9zdHViKHN0dWIpOyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICB1
bnNpZ25lZCBpbnQgbnJfID0gc2l6ZW9mKCh1aW50OF90W10peyBieXRlcyB9
KTsgICAgICAgICAgICAgICAgICAgIFwKLSAgICBtZW1jcHkoZ2V0X3N0dWIo
c3R1YiksICgodWludDhfdFtdKXsgYnl0ZXMsIDB4YzMgfSksIG5yXyArIDEp
OyAgICAgIFwKKyAgICBtZW1jcHkoX3AsICgodWludDhfdFtdKXsgYnl0ZXMg
fSksIG5yXyk7IF9wICs9IG5yXzsgICAgICAgICAgICAgICAgIFwKKyAgICBw
bGFjZV9yZXQoX3ApOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKICAgICBpbnZva2Vfc3R1YigiIiwg
IiIsICI9bSIgKGR1bW15KSA6ICJpIiAoMCkpOyAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICBwdXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKIH0gd2hp
bGUgKDApCiAKICNkZWZpbmUgZW11bGF0ZV9mcHVfaW5zbl9zdHViX2VmbGFn
cyhieXRlcy4uLikgICAgICAgICAgICAgICAgICAgICAgICAgIFwKIGRvIHsg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICB2b2lkICpfcCA9IGdldF9z
dHViKHN0dWIpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFwKICAgICB1bnNpZ25lZCBpbnQgbnJfID0gc2l6ZW9mKCh1aW50
OF90W10peyBieXRlcyB9KTsgICAgICAgICAgICAgICAgICAgIFwKICAgICB1
bnNpZ25lZCBsb25nIHRtcF87ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICBtZW1jcHkoZ2V0X3N0dWIo
c3R1YiksICgodWludDhfdFtdKXsgYnl0ZXMsIDB4YzMgfSksIG5yXyArIDEp
OyAgICAgIFwKKyAgICBtZW1jcHkoX3AsICgodWludDhfdFtdKXsgYnl0ZXMg
fSksIG5yXyk7IF9wICs9IG5yXzsgICAgICAgICAgICAgICAgIFwKKyAgICBw
bGFjZV9yZXQoX3ApOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFwKICAgICBpbnZva2Vfc3R1YihfUFJF
X0VGTEFHUygiW2VmbGFnc10iLCAiW21hc2tdIiwgIlt0bXBdIiksICAgICAg
ICAgICAgIFwKICAgICAgICAgICAgICAgICBfUE9TVF9FRkxBR1MoIltlZmxh
Z3NdIiwgIlttYXNrXSIsICJbdG1wXSIpLCAgICAgICAgICAgIFwKICAgICAg
ICAgICAgICAgICBbZWZsYWdzXSAiK2ciIChyZWdzLT5lZmxhZ3MpLCBbdG1w
XSAiPSZyIiAodG1wXykgICAgICAgIFwKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni94ODZfZW11bGF0ZS94ODZfZW11bGF0ZS5jIGIveGVuL2FyY2gveDg2
L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMKaW5kZXggZWYyNTk4ZDRjYTNm
Li5kZDViNjVhZmUwNjQgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZf
ZW11bGF0ZS94ODZfZW11bGF0ZS5jCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZf
ZW11bGF0ZS94ODZfZW11bGF0ZS5jCkBAIC0xMzk2LDcgKzEzOTYsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgc3RiWzNdID0gMHg5MTsKICAgICAgICAg
c3RiWzRdID0gZXZleC5vcG1zayA8PCAzOwogICAgICAgICBpbnNuX2J5dGVz
ID0gNTsKLSAgICAgICAgc3RiWzVdID0gMHhjMzsKKyAgICAgICAgcGxhY2Vf
cmV0KCZzdGJbNV0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwg
IittIiAob3BfbWFzaykgOiAiYSIgKCZvcF9tYXNrKSk7CiAKQEAgLTM2Mjcs
NyArMzYyNyw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICB9CiAgICAgICAg
IG9wY1sxXSA9IChtb2RybSAmIDB4MzgpIHwgMHhjMDsKICAgICAgICAgaW5z
bl9ieXRlcyA9IEVWRVhfUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJd
ID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAg
ICAgIGNvcHlfRVZFWChvcGMsIGV2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1
YigiIiwgIiIsICI9ZyIgKGR1bW15KSA6ICJhIiAoc3JjLnZhbCkpOwpAQCAt
MzY5NCw3ICszNjk0LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAgICBp
bnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMjsKICAgICAgICAgICAgIGNvcHlf
UkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIH0KLSAg
ICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNb
Ml0pOwogCiAgICAgICAgIGVhLnJlZyA9IGRlY29kZV9ncHIoJl9yZWdzLCBt
b2RybV9yZWcpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9YSIg
KCplYS5yZWcpIDogImMiIChtbXZhbHApLCAibSIgKCptbXZhbHApKTsKQEAg
LTM3NjgsNyArMzc2OCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAg
aW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDI7CiAgICAgICAgICAgICBjb3B5
X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2ZXgpOwogICAgICAgICB9Ci0g
ICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzJdKTsKIAogICAgICAgICBfcmVncy5lZmxhZ3MgJj0gfkVGTEFHU19NQVNL
OwogICAgICAgICBpbnZva2Vfc3R1YigiIiwKQEAgLTQwMDQsNyArNDAwNCw3
IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBvcGNbMV0gPSBtb2RybSAmIDB4
Yzc7CiAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwogICAg
IHNpbWRfMGZfdG9fZ3ByOgotICAgICAgICBvcGNbaW5zbl9ieXRlcyAtIFBG
WF9CWVRFU10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1tpbnNu
X2J5dGVzIC0gUEZYX0JZVEVTXSk7CiAKICAgICAgICAgZ2VuZXJhdGVfZXhj
ZXB0aW9uX2lmKGVhLnR5cGUgIT0gT1BfUkVHLCBYODZfRVhDX1VEKTsKIApA
QCAtNDQwMSw3ICs0NDAxLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAg
ICB2ZXgudyA9IDA7CiAgICAgICAgIG9wY1sxXSA9IG1vZHJtICYgMHgzODsK
ICAgICAgICAgaW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDI7Ci0gICAgICAg
IG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsK
IAogICAgICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2ZXgp
OwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKHNyYy52YWwp
IDogImEiICgmc3JjLnZhbCkpOwpAQCAtNDQzOCw3ICs0NDM4LDcgQEAgeDg2
X2VtdWxhdGUoCiAgICAgICAgICAgICBldmV4LncgPSAwOwogICAgICAgICBv
cGNbMV0gPSBtb2RybSAmIDB4Mzg7CiAgICAgICAgIGluc25fYnl0ZXMgPSBF
VkVYX1BGWF9CWVRFUyArIDI7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X0VW
RVgob3BjLCBldmV4KTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAi
K20iIChzcmMudmFsKSA6ICJhIiAoJnNyYy52YWwpKTsKQEAgLTQ2MzMsNyAr
NDYzMyw3IEBAIHg4Nl9lbXVsYXRlKAogI2VuZGlmIC8qIFg4NkVNVUxfTk9f
U0lNRCAqLwogCiAgICAgc2ltZF8wZl9yZWdfb25seToKLSAgICAgICAgb3Bj
W2luc25fYnl0ZXMgLSBQRlhfQllURVNdID0gMHhjMzsKKyAgICAgICAgcGxh
Y2VfcmV0KCZvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10pOwogCiAgICAg
ICAgIGNvcHlfUkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAg
ICAgIGludm9rZV9zdHViKCIiLCAiIiwgW2R1bW15X291dF0gIj1nIiAoZHVt
bXkpIDogW2R1bW15X2luXSAiaSIgKDApICk7CkBAIC00OTY3LDcgKzQ5Njcs
NyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgaWYgKCAhbW9kZV82NGJpdCgp
ICkKICAgICAgICAgICAgIHZleC53ID0gMDsKICAgICAgICAgb3BjWzFdID0g
bW9kcm0gJiAweGY4OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAg
ICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgY29weV9WRVgob3Bj
LCB2ZXgpOwogICAgICAgICBlYS5yZWcgPSBkZWNvZGVfZ3ByKCZfcmVncywg
bW9kcm1fcm0pOwpAQCAtNTAxMCw3ICs1MDEwLDcgQEAgeDg2X2VtdWxhdGUo
CiAgICAgICAgIGlmICggIW1vZGVfNjRiaXQoKSApCiAgICAgICAgICAgICB2
ZXgudyA9IDA7CiAgICAgICAgIG9wY1sxXSA9IG1vZHJtICYgMHhjNzsKLSAg
ICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNb
Ml0pOwogCiAgICAgICAgIGNvcHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAg
aW52b2tlX3N0dWIoIiIsICIiLCAiPWEiIChkc3QudmFsKSA6IFtkdW1teV0g
ImkiICgwKSk7CkBAIC01MDQwLDcgKzUwNDAsNyBAQCB4ODZfZW11bGF0ZSgK
ICAgICAgICAgb3BjID0gaW5pdF9wcmVmaXhlcyhzdHViKTsKICAgICAgICAg
b3BjWzBdID0gYjsKICAgICAgICAgb3BjWzFdID0gbW9kcm07Ci0gICAgICAg
IG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsK
IAogICAgICAgICBjb3B5X1ZFWChvcGMsIHZleCk7CiAgICAgICAgIF9yZWdz
LmVmbGFncyAmPSB+RUZMQUdTX01BU0s7CkBAIC01NjA4LDcgKzU2MDgsNyBA
QCB4ODZfZW11bGF0ZSgKICAgICAgICAgaWYgKCAhbW9kZV82NGJpdCgpICkK
ICAgICAgICAgICAgIHZleC53ID0gMDsKICAgICAgICAgb3BjWzFdID0gbW9k
cm0gJiAweGM3OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBw
bGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgY29weV9SRVhfVkVYKG9w
YywgcmV4X3ByZWZpeCwgdmV4KTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIs
ICIiLCAiPWEiIChlYS52YWwpIDogW2R1bW15XSAiaSIgKDApKTsKQEAgLTU3
MjYsNyArNTcyNiw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAgb3Bj
WzFdICY9IDB4Mzg7CiAgICAgICAgIH0KICAgICAgICAgaW5zbl9ieXRlcyA9
IFBGWF9CWVRFUyArIDI7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAg
ICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKICAgICAgICAgaWYgKCB2ZXgub3Bj
eCA9PSB2ZXhfbm9uZSApCiAgICAgICAgIHsKICAgICAgICAgICAgIC8qIENv
dmVyIGZvciBleHRyYSBwcmVmaXggYnl0ZS4gKi8KQEAgLTYwMDYsNyArNjAw
Niw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBwdmV4LT5iID0gIW1vZGVf
NjRiaXQoKSB8fCAodmV4LnJlZyA+PiAzKTsKICAgICAgICAgb3BjWzFdID0g
MHhjMCB8ICh+dmV4LnJlZyAmIDcpOwogICAgICAgICBwdmV4LT5yZWcgPSAw
eGY7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3Jl
dCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9
YSIgKGVhLnZhbCkgOiBbZHVtbXldICJpIiAoMCkpOwogICAgICAgICBwdXRf
c3R1YihzdHViKTsKQEAgLTYyOTAsNyArNjI5MCw3IEBAIHg4Nl9lbXVsYXRl
KAogICAgICAgICAgICAgZXZleC53ID0gMDsKICAgICAgICAgb3BjWzFdID0g
bW9kcm0gJiAweGY4OwogICAgICAgICBpbnNuX2J5dGVzID0gRVZFWF9QRlhf
QllURVMgKyAyOwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBw
bGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgY29weV9FVkVYKG9wYywg
ZXZleCk7CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1nIiAoZHVt
bXkpIDogImEiIChzcmMudmFsKSk7CkBAIC02Mzg5LDcgKzYzODksNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+YiA9IDE7CiAgICAgICAgIG9w
Y1sxXSA9IChtb2RybV9yZWcgJiA3KSA8PCAzOwogICAgICAgICBwdmV4LT5y
ZWcgPSAweGY7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBs
YWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwg
IiIsICI9bSIgKCptbXZhbHApIDogImEiIChtbXZhbHApKTsKIApAQCAtNjQ1
OSw3ICs2NDU5LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHB2ZXgtPmIg
PSAxOwogICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsK
ICAgICAgICAgcHZleC0+cmVnID0gMHhmOwotICAgICAgICBvcGNbMl0gPSAw
eGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAg
aW52b2tlX3N0dWIoIiIsICIiLCAiK20iICgqbW12YWxwKSA6ICJhIiAobW12
YWxwKSk7CiAKQEAgLTY1MTUsNyArNjUxNSw3IEBAIHg4Nl9lbXVsYXRlKAog
ICAgICAgICBwZXZleC0+YiA9IDE7CiAgICAgICAgIG9wY1sxXSA9IChtb2Ry
bV9yZWcgJiA3KSA8PCAzOwogICAgICAgICBwZXZleC0+UlggPSAxOwotICAg
ICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1sy
XSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiPW0iICgqbW12
YWxwKSA6ICJhIiAobW12YWxwKSk7CiAKQEAgLTY1ODAsNyArNjU4MCw3IEBA
IHg4Nl9lbXVsYXRlKAogICAgICAgICBwZXZleC0+YiA9IDE7CiAgICAgICAg
IG9wY1sxXSA9IChtb2RybV9yZWcgJiA3KSA8PCAzOwogICAgICAgICBwZXZl
eC0+UlggPSAxOwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBw
bGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIoIiIs
ICIiLCAiK20iICgqbW12YWxwKSA6ICJhIiAobW12YWxwKSk7CiAKQEAgLTY1
OTQsNyArNjU5NCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBvcGNbMl0g
PSAweDkwOwogICAgICAgICAvKiBVc2UgKCVyYXgpIGFzIHNvdXJjZS4gKi8K
ICAgICAgICAgb3BjWzNdID0gZXZleC5vcG1zayA8PCAzOwotICAgICAgICBv
cGNbNF0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1s0XSk7CiAK
ICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiK20iIChvcF9tYXNrKSA6
ICJhIiAoJm9wX21hc2spKTsKICAgICAgICAgcHV0X3N0dWIoc3R1Yik7CkBA
IC02Njg4LDcgKzY2ODgsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcGV2
ZXgtPmIgPSAxOwogICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykg
PDwgMzsKICAgICAgICAgcGV2ZXgtPlJYID0gMTsKLSAgICAgICAgb3BjWzJd
ID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAg
ICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1tIiAoKm1tdmFscCkgOiAiYSIg
KG1tdmFscCkpOwogCkBAIC02NzY2LDcgKzY3NjYsNyBAQCB4ODZfZW11bGF0
ZSgKICAgICAgICAgb3BjWzJdID0gMHg5MDsKICAgICAgICAgLyogVXNlICgl
cmF4KSBhcyBzb3VyY2UuICovCiAgICAgICAgIG9wY1szXSA9IGV2ZXgub3Bt
c2sgPDwgMzsKLSAgICAgICAgb3BjWzRdID0gMHhjMzsKKyAgICAgICAgcGxh
Y2VfcmV0KCZvcGNbNF0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAi
IiwgIittIiAob3BfbWFzaykgOiAiYSIgKCZvcF9tYXNrKSk7CiAgICAgICAg
IHB1dF9zdHViKHN0dWIpOwpAQCAtNjg0OCw3ICs2ODQ4LDcgQEAgeDg2X2Vt
dWxhdGUoCiAgICAgICAgIHBldmV4LT5yID0gIW1vZGVfNjRiaXQoKSB8fCAh
KHN0YXRlLT5zaWJfaW5kZXggJiAweDA4KTsKICAgICAgICAgcGV2ZXgtPlIg
PSAhbW9kZV82NGJpdCgpIHx8ICEoc3RhdGUtPnNpYl9pbmRleCAmIDB4MTAp
OwogICAgICAgICBwZXZleC0+UlggPSAxOwotICAgICAgICBvcGNbMl0gPSAw
eGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAg
aW52b2tlX3N0dWIoIiIsICIiLCAiPW0iIChpbmRleCkgOiAiYSIgKCZpbmRl
eCkpOwogICAgICAgICBwdXRfc3R1YihzdHViKTsKQEAgLTcwMjYsNyArNzAy
Niw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBwdmV4LT5yZWcgPSAweGY7
IC8qIHJBWCAqLwogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZb
NF0gPSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KLSAgICAgICAg
YnVmWzVdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwog
CiAgICAgICAgIHNyYy5yZWcgPSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAm
X3JlZ3MsIGN0eHQpOwogICAgICAgICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0m
YyIgKGRzdC52YWwpLCAiW2RzdF0iICgmc3JjLnZhbCksICJhIiAoKnNyYy5y
ZWcpKTsKQEAgLTcwNjIsNyArNzA2Miw3IEBAIHg4Nl9lbXVsYXRlKAogICAg
ICAgICBwdmV4LT5yZWcgPSAweGY7IC8qIHJBWCAqLwogICAgICAgICBidWZb
M10gPSBiOwogICAgICAgICBidWZbNF0gPSAobW9kcm0gJiAweDM4KSB8IDB4
MDE7IC8qIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgIGRzdC5y
ZWcgPSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3JlZ3MsIGN0eHQpOwog
ICAgICAgICBlbXVsYXRlX3N0dWIoIj0mYSIgKGRzdC52YWwpLCAiYyIgKCZz
cmMudmFsKSk7CkBAIC03MzAzLDcgKzczMDMsNyBAQCB4ODZfZW11bGF0ZSgK
ICAgICAgICAgICAgIGV2ZXgudyA9IHZleC53ID0gMDsKICAgICAgICAgb3Bj
WzFdID0gbW9kcm0gJiAweDM4OwogICAgICAgICBvcGNbMl0gPSBpbW0xOwot
ICAgICAgICBvcGNbM10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9w
Y1szXSk7CiAgICAgICAgIGlmICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQog
ICAgICAgICB7CiAgICAgICAgICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJl
Zml4IGJ5dGUuICovCkBAIC03NDcwLDcgKzc0NzAsNyBAQCB4ODZfZW11bGF0
ZSgKICAgICAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAzOwog
ICAgICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAgICAgICB9Ci0g
ICAgICAgIG9wY1szXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzNdKTsKIAogICAgICAgICAvKiBMYXRjaCBNWENTUiAtIHdlIG1heSBuZWVk
IHRvIHJlc3RvcmUgaXQgYmVsb3cuICovCiAgICAgICAgIGludm9rZV9zdHVi
KCJzdG14Y3NyICVbbXhjc3JdIiwgIiIsCkBAIC03NzE2LDcgKzc3MTYsNyBA
QCB4ODZfZW11bGF0ZSgKICAgICAgICAgfQogICAgICAgICBvcGNbMl0gPSBp
bW0xOwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMzsKLSAg
ICAgICAgb3BjWzNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNb
M10pOwogICAgICAgICBpZiAoIHZleC5vcGN4ID09IHZleF9ub25lICkKICAg
ICAgICAgewogICAgICAgICAgICAgLyogQ292ZXIgZm9yIGV4dHJhIHByZWZp
eCBieXRlLiAqLwpAQCAtODA1Niw3ICs4MDU2LDcgQEAgeDg2X2VtdWxhdGUo
CiAgICAgICAgIHB4b3AtPnJlZyA9IDB4ZjsgLyogckFYICovCiAgICAgICAg
IGJ1ZlszXSA9IGI7CiAgICAgICAgIGJ1Zls0XSA9IChtb2RybSAmIDB4Mzgp
IHwgMHgwMTsgLyogci9tPSglckNYKSAqLwotICAgICAgICBidWZbNV0gPSAw
eGMzOworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls1XSk7CiAKICAgICAgICAg
ZHN0LnJlZyA9IGRlY29kZV92ZXhfZ3ByKHZleC5yZWcsICZfcmVncywgY3R4
dCk7CiAgICAgICAgIGVtdWxhdGVfc3R1YihbZHN0XSAiPSZhIiAoZHN0LnZh
bCksICJjIiAoJnNyYy52YWwpKTsKQEAgLTgxNjUsNyArODE2NSw3IEBAIHg4
Nl9lbXVsYXRlKAogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZb
NF0gPSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KICAgICAgICAg
Kih1aW50MzJfdCAqKShidWYgKyA1KSA9IGltbTE7Ci0gICAgICAgIGJ1Zls5
XSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzldKTsKIAogICAg
ICAgICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0mYyIgKGRzdC52YWwpLCAiW2Rz
dF0iICgmc3JjLnZhbCkpOwogCkBAIC04MjU1LDEyICs4MjU1LDEyIEBAIHg4
Nl9lbXVsYXRlKAogICAgICAgICAgICAgQlVHKCk7CiAgICAgICAgIGlmICgg
ZXZleF9lbmNvZGVkKCkgKQogICAgICAgICB7Ci0gICAgICAgICAgICBvcGNb
aW5zbl9ieXRlcyAtIEVWRVhfUEZYX0JZVEVTXSA9IDB4YzM7CisgICAgICAg
ICAgICBwbGFjZV9yZXQoJm9wY1tpbnNuX2J5dGVzIC0gRVZFWF9QRlhfQllU
RVNdKTsKICAgICAgICAgICAgIGNvcHlfRVZFWChvcGMsIGV2ZXgpOwogICAg
ICAgICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgewotICAgICAgICAgICAg
b3BjW2luc25fYnl0ZXMgLSBQRlhfQllURVNdID0gMHhjMzsKKyAgICAgICAg
ICAgIHBsYWNlX3JldCgmb3BjW2luc25fYnl0ZXMgLSBQRlhfQllURVNdKTsK
ICAgICAgICAgICAgIGNvcHlfUkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZl
eCk7CiAgICAgICAgIH0KIAo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-06.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-06.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IEJ1aWxkIFhlbiB3aXRoIFJldHVybiBUaHVua3MKClRo
ZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uIHNwZWN1bGF0aXZlIHZ1bG5l
cmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRpcmVjdApicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QgaGFsZiBv
ZiBhIGNhY2hlbGluZS4KCkluIG9yZGVyIHRvIG1pdGlnYXRlIHRoaXMsIGJ1
aWxkIHdpdGggcmV0dXJuIHRodW5rcyBhbmQgYXJyYW5nZSBmb3IKX194ODZf
cmV0dXJuX3RodW5rIHRvIGJlIChtaXMpYWxpZ25lZCBpbiB0aGUgc2FtZSBt
YW5uZXIgYXMKX194ODZfaW5kaXJlY3RfdGh1bmtfKiBzbyB0aGUgUkVUIGlu
c3RydWN0aW9uIGlzIHBsYWNlZCBpbiBhIHNhZmUgbG9jYXRpb24uCgpwbGFj
ZV9yZXQoKSBuZWVkcyB0byBjb25kaXRpb25hbGx5IGVtaXQgSk1QIF9feDg2
X3JldHVybl90aHVuayBpbnN0ZWFkIG9mIFJFVC4KClRoaXMgaXMgcGFydCBv
ZiBYU0EtNDY5IC8gQ1ZFLTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnIGIveGVu
L2FyY2gveDg2L0tjb25maWcKaW5kZXggMWFjZGZmYzUxYzIyLi45NjExYjgw
NzYxOTcgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnCisrKyBi
L3hlbi9hcmNoL3g4Ni9LY29uZmlnCkBAIC0zNSw5ICszNSwxNCBAQCBjb25m
aWcgQVJDSF9ERUZDT05GSUcKIAlkZWZhdWx0ICJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCiAKIGNvbmZpZyBDQ19IQVNfSU5ESVJFQ1Rf
VEhVTksKKwkjIEdDQyA+PSA4IG9yIENsYW5nID49IDYKIAlkZWZfYm9vbCAk
KGNjLW9wdGlvbiwtbWluZGlyZWN0LWJyYW5jaC1yZWdpc3RlcikgfHwgXAog
CSAgICAgICAgICQoY2Mtb3B0aW9uLC1tcmV0cG9saW5lLWV4dGVybmFsLXRo
dW5rKQogCitjb25maWcgQ0NfSEFTX1JFVFVSTl9USFVOSworCSMgR0NDID49
IDggb3IgQ2xhbmcgPj0gMTUKKwlkZWZfYm9vbCAkKGNjLW9wdGlvbiwtbWZ1
bmN0aW9uLXJldHVybj10aHVuay1leHRlcm4pCisKIGNvbmZpZyBIQVNfQVNf
Q0VUX1NTCiAJIyBiaW51dGlscyA+PSAyLjI5IG9yIExMVk0gPj0gNgogCWRl
Zl9ib29sICQoYXMtaW5zdHIsd3Jzc3EgJXJheCQoY29tbWEpMDtzZXRzc2Jz
eSkKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hlbi9h
cmNoL3g4Ni9NYWtlZmlsZQppbmRleCA3ZGY4NzdhMDlkM2YuLmZjOTg0ZDYy
OWVkYiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisrKyBi
L3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtNDQsNiArNDQsNyBAQCBvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KK29iai0kKENPTkZJR19SRVRV
Uk5fVEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KIG9iai0kKENPTkZJR19Q
VikgKz0gaW9wb3J0X2VtdWxhdGUubwogb2JqLXkgKz0gaXJxLm8KIG9iai0k
KENPTkZJR19LRVhFQykgKz0gbWFjaGluZV9rZXhlYy5vCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJvdC5TIGIveGVuL2FyY2gv
eDg2L2FjcGkvd2FrZXVwX3Byb3QuUwppbmRleCA2NmY3OTkzMzk5MTMuLjk3
YmQ2NzZhYWVlMiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvd2Fr
ZXVwX3Byb3QuUworKysgYi94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJv
dC5TCkBAIC0xMzMsNyArMTMzLDcgQEAgRU5UUlkoczNfcmVzdW1lKQogICAg
ICAgICBwb3AgICAgICVyMTIKICAgICAgICAgcG9wICAgICAlcmJ4CiAgICAg
ICAgIHBvcCAgICAgJXJicAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAK
IC5kYXRhCiAgICAgICAgIC5hbGlnbiAxNgpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94ODYvYWx0ZXJuYXRp
dmUuYwppbmRleCBiZTE5NTc3MjM0NzIuLmNjYjk5ODVhNzY2ZSAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKKysrIGIveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTEzNywxNiArMTM3LDQ1IEBAIHZv
aWQgaW5pdF9vcl9saXZlcGF0Y2ggYWRkX25vcHModm9pZCAqaW5zbnMsIHVu
c2lnbmVkIGludCBsZW4pCiAgICAgfQogfQogCit2b2lkIG5vY2FsbCBfX3g4
Nl9yZXR1cm5fdGh1bmsodm9pZCk7CisKIC8qCiAgKiBQbGFjZSBhIHJldHVy
biBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGluIHRoZSB3cml0YWJsZSBhbGlh
cyBvZiBhIHN0dWIuCiAgKgorICogV2hlbiBDT05GSUdfUkVUVVJOX1RIVU5L
IGlzIGFjdGl2ZSwgdGhpcyBtYXkgYmUgYSBKTVAgX194ODZfcmV0dXJuX3Ro
dW5rCisgKiBpbnN0ZWFkLCBkZXBlbmRpbmcgb24gdGhlIHNhZmV0eSBvZiBA
cHRyIHdpdGggcmVzcGVjdCB0byBJbmRpcmVjdCBUYXJnZXQKKyAqIFNlbGVj
dGlvbi4KKyAqCiAgKiBSZXR1cm5zIHRoZSBuZXh0IHBvc2l0aW9uIHRvIHdy
aXRlIGludG8gdGhlIHN0dWIuCiAgKi8KIHZvaWQgKnBsYWNlX3JldCh2b2lk
ICpwdHIpCiB7CisgICAgdW5zaWduZWQgbG9uZyBhZGRyID0gKHVuc2lnbmVk
IGxvbmcpcHRyOwogICAgIHVpbnQ4X3QgKnAgPSBwdHI7CiAKLSAgICAqcCsr
ID0gMHhjMzsKKyAgICAvKgorICAgICAqIFdoZW4gUmV0dXJuIFRodW5rcyBh
cmUgdXNlZCwgaWYgYSBSRVQgd291bGQgYmUgdW5zYWZlIGF0IHRoaXMgbG9j
YXRpb24KKyAgICAgKiB3aXRoIHJlc3BlY3QgdG8gSW5kaXJlY3QgVGFyZ2V0
IFNlbGVjdGlvbiAoaS5lLiBpZiBhZGRyIGlzIGluIHRoZSBmaXJzdAorICAg
ICAqIGhhbGYgb2YgYSBjYWNoZWxpbmUpLCBpbnNlcnQgYSBKTVAgX194ODZf
cmV0dXJuX3RodW5rIGluc3RlYWQuCisgICAgICoKKyAgICAgKiBUaGUgZGlz
cGxhY2VtZW50IG5lZWRzIHRvIGJlIHJlbGF0aXZlIHRvIHRoZSBleGVjdXRh
YmxlIGFsaWFzIG9mIHRoZQorICAgICAqIHN0dWIsIG5vdCB0byBAcHRyIHdo
aWNoIGlzIHRoZSB3cml0ZWFibGUgYWxpYXMuCisgICAgICovCisgICAgaWYg
KCBJU19FTkFCTEVEKENPTkZJR19SRVRVUk5fVEhVTkspICYmICEoYWRkciAm
IDB4MjApICkKKyAgICB7CisgICAgICAgIGxvbmcgc3R1Yl92YSA9ICh0aGlz
X2NwdShzdHVicy5hZGRyKSAmIFBBR0VfTUFTSykgKyAoYWRkciAmIH5QQUdF
X01BU0spOworICAgICAgICBsb25nIGRpc3AgPSAobG9uZylfX3g4Nl9yZXR1
cm5fdGh1bmsgLSAoc3R1Yl92YSArIDUpOworCisgICAgICAgIEJVR19PTigo
aW50MzJfdClkaXNwICE9IGRpc3ApOworCisgICAgICAgICpwKysgPSAweGU5
OworICAgICAgICAqKGludDMyX3QgKilwID0gZGlzcDsKKyAgICAgICAgcCAr
PSA0OworICAgIH0KKyAgICBlbHNlCisgICAgeworICAgICAgICAqcCsrID0g
MHhjMzsKKyAgICB9CiAKICAgICByZXR1cm4gcDsKIH0KZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rIGIveGVuL2FyY2gveDg2L2FyY2gubWsK
aW5kZXggMjgyMTdjOWFjZTQ2Li4yMWE3NTNiNjM5NGUgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rCisrKyBiL3hlbi9hcmNoL3g4Ni9hcmNo
Lm1rCkBAIC00Niw2ICs0Niw5IEBAIENGTEFHUy0kKENPTkZJR19DQ19JU19H
Q0MpICs9IC1mbm8tanVtcC10YWJsZXMKIENGTEFHUy0kKENPTkZJR19DQ19J
U19DTEFORykgKz0gLW1yZXRwb2xpbmUtZXh0ZXJuYWwtdGh1bmsKIGVuZGlm
CiAKKyMgQ29tcGlsZSB3aXRoIHJldHVybiB0aHVuayBzdXBwb3J0IGlmIHNl
bGVjdGVkLgorQ0ZMQUdTLSQoQ09ORklHX1JFVFVSTl9USFVOSykgKz0gLW1m
dW5jdGlvbi1yZXR1cm49dGh1bmstZXh0ZXJuCisKICMgRGlzYWJsZSB0aGUg
YWRkaXRpb24gb2YgYSAubm90ZS5nbnUucHJvcGVydHkgc2VjdGlvbiB0byBv
YmplY3QgZmlsZXMgd2hlbgogIyBsaXZlcGF0Y2ggc3VwcG9ydCBpcyBlbmFi
bGVkLiAgVGhlIGNvbnRlbnRzIG9mIHRoYXQgc2VjdGlvbiBjYW4gY2hhbmdl
CiAjIGRlcGVuZGluZyBvbiB0aGUgaW5zdHJ1Y3Rpb25zIHVzZWQsIGFuZCBs
aXZlcGF0Y2gtYnVpbGQtdG9vbHMgZG9lc24ndCBrbm93CmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYmhiLXRodW5rLlMgYi94ZW4vYXJjaC94ODYvYmhi
LXRodW5rLlMKaW5kZXggMDVmMTA0M2RmN2QwLi40NzJkYTQ4MWRkNDIgMTAw
NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUworKysgYi94ZW4v
YXJjaC94ODYvYmhiLXRodW5rLlMKQEAgLTIzLDcgKzIzLDcgQEAgRU5UUlko
Y2xlYXJfYmhiX3RzeCkKIDA6ICAgICAgLmJ5dGUgMHhjNiwgMHhmOCwgMCAg
ICAgICAgICAgICAvKiB4YWJvcnQgJDAgKi8KICAgICAgICAgaW50MwogMToK
LSAgICAgICAgcmV0CisgICAgICAgIFJFVAogCiAgICAgICAgIC5zaXplIGNs
ZWFyX2JoYl90c3gsIC4gLSBjbGVhcl9iaGJfdHN4CiAgICAgICAgIC50eXBl
IGNsZWFyX2JoYl90c3gsIEBmdW5jdGlvbgpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L2NsZWFyX3BhZ2UuUyBiL3hlbi9hcmNoL3g4Ni9jbGVhcl9wYWdl
LlMKaW5kZXggNWI1NjIyY2M1MjZmLi5mZDRjOGMwYjJhMjggMTAwNjQ0Ci0t
LSBhL3hlbi9hcmNoL3g4Ni9jbGVhcl9wYWdlLlMKKysrIGIveGVuL2FyY2gv
eDg2L2NsZWFyX3BhZ2UuUwpAQCAtMSw1ICsxLDYgQEAKICAgICAgICAgLmZp
bGUgX19GSUxFX18KIAorI2luY2x1ZGUgPGFzbS9hc21fZGVmbnMuaD4KICNp
bmNsdWRlIDxhc20vcGFnZS5oPgogCiBFTlRSWShjbGVhcl9wYWdlX3NzZTIp
CkBAIC0xNSw3ICsxNiw3IEBAIEVOVFJZKGNsZWFyX3BhZ2Vfc3NlMikKICAg
ICAgICAgam56ICAgICAwYgogCiAgICAgICAgIHNmZW5jZQotICAgICAgICBy
ZXQKKyAgICAgICAgUkVUCiAKICAgICAgICAgLnR5cGUgY2xlYXJfcGFnZV9z
c2UyLCBAZnVuY3Rpb24KICAgICAgICAgLnNpemUgY2xlYXJfcGFnZV9zc2Uy
LCAuIC0gY2xlYXJfcGFnZV9zc2UyCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvY29weV9wYWdlLlMgYi94ZW4vYXJjaC94ODYvY29weV9wYWdlLlMKaW5k
ZXggZGRiNmUwZWJiYjZlLi4xODQxMjdjMTFkODYgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUworKysgYi94ZW4vYXJjaC94ODYvY29w
eV9wYWdlLlMKQEAgLTEsNSArMSw2IEBACiAgICAgICAgIC5maWxlIF9fRklM
RV9fCiAKKyNpbmNsdWRlIDxhc20vYXNtX2RlZm5zLmg+CiAjaW5jbHVkZSA8
YXNtL3BhZ2UuaD4KIAogI2RlZmluZSBzcmNfcmVnICVyc2kKQEAgLTQwLDcg
KzQxLDcgQEAgRU5UUlkoY29weV9wYWdlX3NzZTIpCiAgICAgICAgIG1vdm50
aSAgdG1wNF9yZWcsIDMqV09SRF9TSVpFKGRzdF9yZWcpCiAKICAgICAgICAg
c2ZlbmNlCi0gICAgICAgIHJldAorICAgICAgICBSRVQKIAogICAgICAgICAu
dHlwZSBjb3B5X3BhZ2Vfc3NlMiwgQGZ1bmN0aW9uCiAgICAgICAgIC5zaXpl
IGNvcHlfcGFnZV9zc2UyLCAuIC0gY29weV9wYWdlX3NzZTIKZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL3g4Ni9lZmkvY2hlY2suYyBiL3hlbi9hcmNoL3g4Ni9l
ZmkvY2hlY2suYwppbmRleCA5ZTQ3M2ZhYWQzYzkuLjIzYmEzMGFiZjMzMCAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2VmaS9jaGVjay5jCisrKyBiL3hl
bi9hcmNoL3g4Ni9lZmkvY2hlY2suYwpAQCAtMyw2ICszLDkgQEAgaW50IF9f
YXR0cmlidXRlX18oKF9fbXNfYWJpX18pKSB0ZXN0KGludCBpKQogICAgIHJl
dHVybiBpOwogfQogCisvKiBJbiBjYXNlIC1tZnVuY3Rpb24tcmV0dXJuIGlz
IGluIHVzZS4gKi8KK3ZvaWQgX194ODZfcmV0dXJuX3RodW5rKHZvaWQpIHt9
OworCiAvKgogICogUG9wdWxhdGUgYW4gYXJyYXkgd2l0aCAiYWRkcmVzc2Vz
IiBvZiByZWxvY2F0YWJsZSBhbmQgYWJzb2x1dGUgdmFsdWVzLgogICogVGhp
cyBpcyB0byBwcm9iZSBsZCBmb3IgKGEpIGVtaXR0aW5nIGJhc2UgcmVsb2Nh
dGlvbnMgYXQgYWxsIGFuZCAoYikgbm90CmRpZmYgLS1naXQgYS94ZW4vYXJj
aC94ODYvaW5jbHVkZS9hc20vYXNtLWRlZm5zLmggYi94ZW4vYXJjaC94ODYv
aW5jbHVkZS9hc20vYXNtLWRlZm5zLmgKaW5kZXggMzJkNmI0NDkxMDYzLi45
N2ViZTIxMjk4YTIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRl
L2FzbS9hc20tZGVmbnMuaAorKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9h
c20vYXNtLWRlZm5zLmgKQEAgLTU4LDYgKzU4LDEyIEBACiAgICAgLmVuZGlm
CiAuZW5kbQogCisjaWZkZWYgQ09ORklHX1JFVFVSTl9USFVOSworIyBkZWZp
bmUgUkVUIGptcCBfX3g4Nl9yZXR1cm5fdGh1bmsKKyNlbHNlCisjIGRlZmlu
ZSBSRVQgcmV0CisjZW5kaWYKKwogI2lmZGVmIENPTkZJR19YRU5fSUJUCiAj
IGRlZmluZSBFTkRCUjY0IGVuZGJyNjQKICNlbHNlCmRpZmYgLS1naXQgYS94
ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9p
bmRpcmVjdC10aHVuay5TCmluZGV4IGU3ZWYxMDRkM2JkMy4uMjM5Y2Y3ZGM3
NzBiIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsu
UworKysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMTEs
NiArMTEsOSBAQAogCiAjaW5jbHVkZSA8YXNtL2FzbV9kZWZucy5oPgogCisK
KyNpZmRlZiBDT05GSUdfSU5ESVJFQ1RfVEhVTksKKwogLm1hY3JvIElORF9U
SFVOS19SRVRQT0xJTkUgcmVnOnJlcQogICAgICAgICBjYWxsIDFmCiAgICAg
ICAgIGludDMKQEAgLTYwLDMgKzYzLDI3IEBAIEVOVFJZKF9feDg2X2luZGly
ZWN0X3RodW5rX1xyZWcpCiAuaXJwIHJlZywgYXgsIGN4LCBkeCwgYngsIGJw
LCBzaSwgZGksIDgsIDksIDEwLCAxMSwgMTIsIDEzLCAxNCwgMTUKICAgICAg
ICAgR0VOX0lORElSRUNUX1RIVU5LIHJlZz1yXHJlZwogLmVuZHIKKworI2Vu
ZGlmIC8qIENPTkZJR19JTkRJUkVDVF9USFVOSyAqLworCisjaWZkZWYgQ09O
RklHX1JFVFVSTl9USFVOSworICAgICAgICAuc2VjdGlvbiAudGV4dC5lbnRy
eS5fX3g4Nl9yZXR1cm5fdGh1bmssICJheCIsIEBwcm9nYml0cworCisgICAg
ICAgIC8qCisgICAgICAgICAqIFRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdAorICAg
ICAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFy
ZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QKKyAgICAgICAgICogaGFsZiBv
ZiBhIGNhY2hlbGluZS4gIEFycmFuZ2UgZm9yIHRoZW0gdG8gYmUgaW4gdGhl
IHNlY29uZCBoYWxmLgorICAgICAgICAgKgorICAgICAgICAgKiBBbGlnbiB0
byA2NCwgdGhlbiBza2lwIDMyLgorICAgICAgICAgKi8KKyAgICAgICAgLmJh
bGlnbiA2NAorICAgICAgICAuZmlsbCAzMiwgMSwgMHhjYworCitFTlRSWShf
X3g4Nl9yZXR1cm5fdGh1bmspCisgICAgICAgIHJldAorICAgICAgICBpbnQz
IC8qIEhhbHQgc3RyYWlnaHQtbGluZSBzcGVjdWxhdGlvbiAqLworCisgICAg
ICAgIC5zaXplIF9feDg2X3JldHVybl90aHVuaywgLiAtIF9feDg2X3JldHVy
bl90aHVuaworICAgICAgICAudHlwZSBfX3g4Nl9yZXR1cm5fdGh1bmssIEBm
dW5jdGlvbgorCisjZW5kaWYgLyogQ09ORklHX1JFVFVSTl9USFVOSyAqLwpk
aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3B2L2VtdWwtcHJpdi1vcC5jIGIv
eGVuL2FyY2gveDg2L3B2L2VtdWwtcHJpdi1vcC5jCmluZGV4IGZmNWQxYzlm
ODYzNC4uMjk1ZDg0N2VhMjRjIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYv
cHYvZW11bC1wcml2LW9wLmMKKysrIGIveGVuL2FyY2gveDg2L3B2L2VtdWwt
cHJpdi1vcC5jCkBAIC0xMzEsNyArMTMxLDcgQEAgc3RhdGljIGlvX2VtdWxf
c3R1Yl90ICppb19lbXVsX3N0dWJfc2V0dXAoc3RydWN0IHByaXZfb3BfY3R4
dCAqY3R4dCwgdTggb3Bjb2RlLAogICAgIEJVSUxEX0JVR19PTihTVFVCX0JV
Rl9TSVpFIC8gMiA8CiAgICAgICAgICAgICAgICAgIChzaXplb2YocHJvbG9n
dWUpICsgc2l6ZW9mKGVwaWxvZ3VlKSArIDEwIC8qIDJ4IGNhbGwgKi8gKwog
ICAgICAgICAgICAgICAgICAgTUFYKDMgLyogZGVmYXVsdCBzdHViICovLCBJ
T0VNVUxfUVVJUktfU1RVQl9CWVRFUykgKwotICAgICAgICAgICAgICAgICAg
MSAvKiByZXQgKi8pKTsKKyAgICAgICAgICAgICAgICAgIChJU19FTkFCTEVE
KENPTkZJR19SRVRVUk5fVEhVTkspID8gNSA6IDEpIC8qIHJldCAqLykpOwog
ICAgIC8qIFJ1bnRpbWUgY29uZmlybWF0aW9uIHRoYXQgd2UgaGF2ZW4ndCBj
bG9iYmVyZWQgYW4gYWRqYWNlbnQgc3R1Yi4gKi8KICAgICBCVUdfT04oU1RV
Ql9CVUZfU0laRSAvIDIgPCAocCAtIGN0eHQtPmlvX2VtdWxfc3R1YikpOwog
CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5TIGIv
eGVuL2FyY2gveDg2L3B2L2dwcl9zd2l0Y2guUwppbmRleCBlN2Y1YmZjZDJk
MDMuLmJmODMwYTc4ZjhhZSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3B2
L2dwcl9zd2l0Y2guUworKysgYi94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRj
aC5TCkBAIC0yNiwxMiArMjYsMTEgQEAgRU5UUlkobG9hZF9ndWVzdF9ncHJz
KQogICAgICAgICBtb3ZxICBVUkVHU19yMTUoJXJkaSksICVyMTUKICAgICAg
ICAgbW92cSAgVVJFR1NfcmN4KCVyZGkpLCAlcmN4CiAgICAgICAgIG1vdnEg
IFVSRUdTX3JkaSglcmRpKSwgJXJkaQotICAgICAgICByZXQKKyAgICAgICAg
UkVUCiAKICAgICAgICAgLnNpemUgbG9hZF9ndWVzdF9ncHJzLCAuIC0gbG9h
ZF9ndWVzdF9ncHJzCiAgICAgICAgIC50eXBlIGxvYWRfZ3Vlc3RfZ3Bycywg
U1RUX0ZVTkMKIAotCiAvKiBTYXZlIGd1ZXN0IEdQUnMuICBQYXJhbWV0ZXIg
b24gdGhlIHN0YWNrIGFib3ZlIHRoZSByZXR1cm4gYWRkcmVzcy4gKi8KIEVO
VFJZKHNhdmVfZ3Vlc3RfZ3BycykKICAgICAgICAgcHVzaHEgJXJkaQpAQCAt
NTEsNyArNTAsNyBAQCBFTlRSWShzYXZlX2d1ZXN0X2dwcnMpCiAgICAgICAg
IG1vdnEgICVyYngsIFVSRUdTX3JieCglcmRpKQogICAgICAgICBtb3ZxICAl
cmR4LCBVUkVHU19yZHgoJXJkaSkKICAgICAgICAgbW92cSAgJXJjeCwgVVJF
R1NfcmN4KCVyZGkpCi0gICAgICAgIHJldAorICAgICAgICBSRVQKIAogICAg
ICAgICAuc2l6ZSBzYXZlX2d1ZXN0X2dwcnMsIC4gLSBzYXZlX2d1ZXN0X2dw
cnMKICAgICAgICAgLnR5cGUgc2F2ZV9ndWVzdF9ncHJzLCBTVFRfRlVOQwpk
aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jIGIveGVuL2Fy
Y2gveDg2L3NwZWNfY3RybC5jCmluZGV4IDUxYTY2YTE0NGU2Yy4uOGRhYTI4
ZTFlYTk3IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMK
KysrIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCkBAIC01NjksNiArNTY5
LDkgQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2RldGFpbHMoZW51bSBp
bmRfdGh1bmsgdGh1bmspCiAjaWZkZWYgQ09ORklHX0lORElSRUNUX1RIVU5L
CiAgICAgICAgICAgICAgICAiIElORElSRUNUX1RIVU5LIgogI2VuZGlmCisj
aWZkZWYgQ09ORklHX1JFVFVSTl9USFVOSworICAgICAgICAgICAgICAgIiBS
RVRVUk5fVEhVTksiCisjZW5kaWYKICNpZmRlZiBDT05GSUdfU0hBRE9XX1BB
R0lORwogICAgICAgICAgICAgICAgIiBTSEFET1dfUEFHSU5HIgogI2VuZGlm
CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRy
eS5TIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwppbmRl
eCAzYzU0NGU5YTE0ZDYuLmRmYTExNTJiNjA0OSAxMDA2NDQKLS0tIGEveGVu
L2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUworKysgYi94ZW4vYXJj
aC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCkBAIC0xODMsNyArMTgzLDcg
QEAgRU5UUlkoY3I0X3B2MzJfcmVzdG9yZSkKICAgICAgICAgbW92ICAgJXJh
eCwgJWNyNAogICAgICAgICBtb3YgICAlcmF4LCAoJXJkeCkKICAgICAgICAg
cG9wICAgJXJkeAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAwOgogI2lm
bmRlZiBOREVCVUcKICAgICAgICAgLyogQ2hlY2sgdGhhdCBfYWxsXyBvZiB0
aGUgYml0cyBpbnRlbmRlZCB0byBiZSBzZXQgYWN0dWFsbHkgYXJlLiAqLwpA
QCAtMjAyLDcgKzIwMiw3IEBAIEVOVFJZKGNyNF9wdjMyX3Jlc3RvcmUpCiAj
ZW5kaWYKICAgICAgICAgcG9wICAgJXJkeAogICAgICAgICB4b3IgICAlZWF4
LCAlZWF4Ci0gICAgICAgIHJldAorICAgICAgICBSRVQKIAogRU5UUlkoY29t
cGF0X3N5c2NhbGwpCiAgICAgICAgIC8qIEZpeCB1cCByZXBvcnRlZCAlY3Mv
JXNzIGZvciBjb21wYXQgZG9tYWlucy4gKi8KQEAgLTMyOSw3ICszMjksNyBA
QCBfX1VOTElLRUxZX0VORChjb21wYXRfYm91bmNlX251bGxfc2VsZWN0b3Ip
CiAgICAgICAgIHhvciAgICVlYXgsICVlYXgKICAgICAgICAgbW92ICAgJWF4
LCAgVFJBUEJPVU5DRV9jcyglcmR4KQogICAgICAgICBtb3YgICAlYWwsICBU
UkFQQk9VTkNFX2ZsYWdzKCVyZHgpCi0gICAgICAgIHJldAorICAgICAgICBS
RVQKIAogLnNlY3Rpb24gLmZpeHVwLCJheCIKIC5MZngxMzoKZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUyBiL3hlbi9hcmNoL3g4
Ni94ODZfNjQvZW50cnkuUwppbmRleCBkZjNmM2I0ZWE3MjMuLmNjZjA1OGFl
NTU3NSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5T
CisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwpAQCAtNTk4LDcg
KzU5OCw3IEBAIF9fVU5MSUtFTFlfRU5EKGNyZWF0ZV9ib3VuY2VfZnJhbWVf
YmFkX2JvdW5jZV9pcCkKICAgICAgICAgeG9yICAgJWVheCwgJWVheAogICAg
ICAgICBtb3YgICAlcmF4LCBUUkFQQk9VTkNFX2VpcCglcmR4KQogICAgICAg
ICBtb3YgICAlYWwsICBUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCi0gICAgICAg
IHJldAorICAgICAgICBSRVQKIAogICAgICAgICAucHVzaHNlY3Rpb24gLmZp
eHVwLCAiYXgiLCBAcHJvZ2JpdHMKICAgICAgICAgIyBOdW1lcmljIHRhZ3Mg
YmVsb3cgcmVwcmVzZW50IHRoZSBpbnRlbmRlZCBvdmVyYWxsICVyc2kgYWRq
dXN0bWVudC4KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMg
Yi94ZW4vYXJjaC94ODYveGVuLmxkcy5TCmluZGV4IDg5MzBlMTRmYzQwZS4u
YjY2ZTcwOGViZjY5IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYveGVuLmxk
cy5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMKQEAgLTg2LDYgKzg2
LDcgQEAgU0VDVElPTlMKICAgICAgICAuID0gQUxJR04oUEFHRV9TSVpFKTsK
ICAgICAgICBfc3RleHRlbnRyeSA9IC47CiAgICAgICAgKigudGV4dC5lbnRy
eSkKKyAgICAgICAqKC50ZXh0LmVudHJ5LiopCiAgICAgICAgLiA9IEFMSUdO
KFBBR0VfU0laRSk7CiAgICAgICAgX2V0ZXh0ZW50cnkgPSAuOwogCmRpZmYg
LS1naXQgYS94ZW4vY29tbW9uL0tjb25maWcgYi94ZW4vY29tbW9uL0tjb25m
aWcKaW5kZXggMzM2MWE2ZDg5MjU3Li4yYzEwM2MyYzQ3MzYgMTAwNjQ0Ci0t
LSBhL3hlbi9jb21tb24vS2NvbmZpZworKysgYi94ZW4vY29tbW9uL0tjb25m
aWcKQEAgLTEyNyw2ICsxMjcsMTcgQEAgY29uZmlnIElORElSRUNUX1RIVU5L
CiAJICBXaGVuIGVuYWJsZWQsIGluZGlyZWN0IGJyYW5jaGVzIGFyZSBpbXBs
ZW1lbnRlZCB1c2luZyBhIG5ldyBjb25zdHJ1Y3QKIAkgIGNhbGxlZCAicmV0
cG9saW5lIiB0aGF0IHByZXZlbnRzIHNwZWN1bGF0aW9uLgogCitjb25maWcg
UkVUVVJOX1RIVU5LCisJYm9vbCAiT3V0LW9mLWxpbmUgUmV0dXJucyIKKwlk
ZXBlbmRzIG9uIENDX0hBU19SRVRVUk5fVEhVTksKKwlkZWZhdWx0IElORElS
RUNUX1RIVU5LCisJaGVscAorCSAgQ29tcGlsZSBYZW4gd2l0aCBvdXQtb2Yt
bGluZSByZXR1cm5zLgorCisJICBUaGlzIGFsbG93cyBYZW4gdG8gbWl0aWdh
dGUgYSB2YXJpZXR5IG9mIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdGllcwor
CSAgYnkgY2hvb3NpbmcgYSBoYXJkd2FyZS1kZXBlbmRlbnQgaW5zdHJ1Y3Rp
b24gc2VxdWVuY2UgdG8gaW1wbGVtZW50CisJICBmdW5jdGlvbiByZXR1cm5z
IHNhZmVseS4KKwogY29uZmlnIFNQRUNVTEFUSVZFX0hBUkRFTl9BUlJBWQog
CWJvb2wgIlNwZWN1bGF0aXZlIEFycmF5IEhhcmRlbmluZyIKIAlkZWZhdWx0
IHkK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.18-07.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.18-07.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogU3ludGhlc2lzZSBJVFNfTk8g
dG8gZ3Vlc3RzIG9uIHVuYWZmZWN0ZWQgaGFyZHdhcmUKCkl0IGlzIGVhc2ll
ciB0byBleHByZXNzIGZlYXR1cmUgd29yZCAxNyBpbiB0ZXJtcyBvZiB3b3Jk
IDE2ICsgWzMyLCA2NCkgYXMKdGhhdCdzIGhvdyB0aGUgbGF5b3V0IGlzIGdp
dmVuIGluIGRvY3VtZW50YXRpb24uCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2
OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29v
cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKaW5k
ZXggM2M1N2Y1NWRlMDc1Li4xMDQ4ZjE2ZTBjNjQgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKKysrIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaApAQCAtMjExLDYg
KzIxMSw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBib290X2NwdV9oYXModW5z
aWduZWQgaW50IGZlYXQpCiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAgICAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCiAjZGVmaW5l
IGNwdV9oYXNfcmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9SRkRTX05PKQogI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIgICAg
ICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKKyNkZWZp
bmUgY3B1X2hhc19pdHNfbm8gICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX0lUU19OTykKIAogLyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5l
IGNwdV9oYXNfYXJjaF9wZXJmbW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9BUkNIX1BFUkZNT04pCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg
OGRhYTI4ZTFlYTk3Li40NjY4MWQxMGFlOTYgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMKQEAgLTE3ODEsNiArMTc4MSw5MCBAQCBzdGF0aWMgdm9pZCBfX2lu
aXQgYmhpX2NhbGN1bGF0aW9ucyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAq
IGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZl
bG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1
aWRhbmNlL2Fkdmlzb3J5LWd1aWRhbmNlL2luZGlyZWN0LXRhcmdldC1zZWxl
Y3Rpb24uaHRtbAorICovCitzdGF0aWMgdm9pZCBfX2luaXQgaXRzX2NhbGN1
bGF0aW9ucyh2b2lkKQoreworICAgIC8qCisgICAgICogSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBpcyBhIEJyYW5jaCBQcmVkaWN0aW9uIGJ1ZyB3aGVy
ZWJ5IGNlcnRhaW4KKyAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGdldCBwcmVkaWN0ZWQgdXNpbmcgYSBkaXJlY3QgYnJhbmNo
CisgICAgICogdGFyZ2V0LCByYXRoZXIgdGhhbiBhIHN1aXRhYmxlIGluZGly
ZWN0IHRhcmdldCwgYnlwYXNzaW5nIGhhcmR3YXJlCisgICAgICogaXNvbGF0
aW9uIHByb3RlY3Rpb25zLgorICAgICAqCisgICAgICogSVRTIGFmZmVjdHMg
Q29yZSAoYnV0IG5vdCBBdG9tKSBwcm9jZXNzb3JzIHN0YXJ0aW5nIGZyb20g
dGhlCisgICAgICogaW50cm9kdWN0aW9uIG9mIGVJQlJTLCB1cCB0byBidXQg
bm90IGluY2x1ZGluZyBHb2xkZW4gQ292ZSBjb3JlcworICAgICAqIChjaGVj
a2VkIGhlcmUgd2l0aCBCSElfQ1RSTCkuCisgICAgICoKKyAgICAgKiBUaGUg
SVRTX05PIGZlYXR1cmUgaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVudW1lcmF0
ZWQgYnkgaGFyZHdhcmUsIGFuZCBpcworICAgICAqIG9ubHkgZm9yIFZNTXMg
dG8gc3ludGhlc2lzZSBmb3IgZ3Vlc3RzLgorICAgICAqCisgICAgICogSVRT
IGNvbWVzIGluIDMgZmxhdm91cnM6CisgICAgICoKKyAgICAgKiAgIDEpIEFj
cm9zcy1JQlBCLiAgSW5kaXJlY3QgYnJhbmNoZXMgYWZ0ZXIgdGhlIElCUEIg
Y2FuIGJlIGNvbnRyb2xsZWQKKyAgICAgKiAgICAgIGJ5IGRpcmVjdCB0YXJn
ZXRzIHdoaWNoIGV4aXN0ZWQgcHJpb3IgdG8gdGhlIElCUEIuICBUaGlzIGlz
CisgICAgICogICAgICBhZGRyZXNzZWQgaW4gdGhlIElQVSAyMDI1LjEgbWlj
cm9jb2RlIGRyb3AsIGFuZCBoYXMgbm8gb3RoZXIKKyAgICAgKiAgICAgIHNv
ZnR3YXJlIGludGVyYWN0aW9uLgorICAgICAqCisgICAgICogICAyKSBHdWVz
dC9Ib3N0LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgZGlyZWN0IHRhcmdldHMgZnJv
bSB0aGUgZ3Vlc3QuICBUaGlzIGFwcGxpZXMgZXF1YWxseSB0byBQViBndWVz
dHMKKyAgICAgKiAgICAgIChSaW5nMykgYW5kIEhWTSBndWVzdHMgKFZNWCks
IGFuZCBhcHBsaWVzIHRvIGFsbCBTa3lsYWtlLXVhcmNoCisgICAgICogICAg
ICBjb3JlcyB3aXRoIGVJQlJTLgorICAgICAqCisgICAgICogICAzKSBJbnRy
YS1tb2RlLiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgb3RoZXIgZXhlY3V0aW9uIGlu
IHRoZSBzYW1lIG1vZGUuCisgICAgICovCisKKyAgICAvKgorICAgICAqIElm
IHdlIGNhbiBzZWUgSVRTX05PLCBvciB3ZSdyZSB2aXJ0dWFsaXNlZCwgZG8g
bm90aGluZy4gIFdlIGFyZSBvciBtYXkKKyAgICAgKiBtaWdyYXRlIHNvbWV3
aGVyZSB1bnNhZmUuCisgICAgICovCisgICAgaWYgKCBjcHVfaGFzX2l0c19u
byB8fCBjcHVfaGFzX2h5cGVydmlzb3IgKQorICAgICAgICByZXR1cm47CisK
KyAgICAvKiBJVFMgaXMgb25seSBrbm93biB0byBhZmZlY3QgSW50ZWwgcHJv
Y2Vzc29ycyBhdCB0aGlzIHRpbWUuICovCisgICAgaWYgKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9JTlRFTCApCisgICAgICAg
IHJldHVybjsKKworICAgIC8qCisgICAgICogSVRTIGRvZXMgbm90IGV4aXN0
IG9uOgorICAgICAqICAtIG5vbi1GYW1pbHkgNiBDUFVzCisgICAgICogIC0g
dGhvc2Ugd2l0aG91dCBlSUJSUworICAgICAqICAtIHRob3NlIHdpdGggQkhJ
X0NUUkwKKyAgICAgKiBidXQgd2Ugc3RpbGwgbmVlZCB0byBzeW50aGVzaXNl
IElUU19OTy4KKyAgICAgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2
ICE9IDYgfHwgIWNwdV9oYXNfZWlicnMgfHwKKyAgICAgICAgIGJvb3RfY3B1
X2hhcyhYODZfRkVBVFVSRV9CSElfQ1RSTCkgKQorICAgICAgICBnb3RvIHN5
bnRoZXNpc2U7CisKKyAgICBzd2l0Y2ggKCBib290X2NwdV9kYXRhLng4Nl9t
b2RlbCApCisgICAgeworICAgICAgICAvKiBUaGVzZSBTa3lsYWtlLXVhcmNo
IGNvcmVzIHN1ZmZlciBjYXNlcyAjMiBhbmQgIzMuICovCisgICAgY2FzZSBJ
TlRFTF9GQU02X1NLWUxBS0VfWDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FC
WUxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0U6CisgICAg
Y2FzZSBJTlRFTF9GQU02X0NPTUVUTEFLRToKKyAgICBjYXNlIElOVEVMX0ZB
TTZfQ09NRVRMQUtFX0w6CisgICAgICAgIHJldHVybjsKKworICAgICAgICAv
KiBUaGVzZSBTdW5ueS9XaWxsb3cvQ3lwcmVzcyBDb3ZlIGNvcmVzIHN1ZmZl
ciBjYXNlICMzLiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9JQ0VMQUtFX1g6
CisgICAgY2FzZSBJTlRFTF9GQU02X0lDRUxBS0VfRDoKKyAgICBjYXNlIElO
VEVMX0ZBTTZfSUNFTEFLRV9MOgorICAgIGNhc2UgSU5URUxfRkFNNl9USUdF
UkxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfVElHRVJMQUtFOgorICAg
IGNhc2UgSU5URUxfRkFNNl9ST0NLRVRMQUtFOgorICAgICAgICByZXR1cm47
CisKKyAgICBkZWZhdWx0OgorICAgICAgICBicmVhazsKKyAgICB9CisKKyAg
ICAvKiBQbGF0Zm9ybXMgcmVtYWluaW5nIGFyZSBub3QgYmVsaWV2ZWQgdG8g
YmUgdnVsbmVyYWJsZSB0byBJVFMuICovCisgc3ludGhlc2lzZToKKyAgICBz
ZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX0lUU19OTyk7Cit9CisK
IHZvaWQgc3BlY19jdHJsX2luaXRfZG9tYWluKHN0cnVjdCBkb21haW4gKmQp
CiB7CiAgICAgYm9vbCBwdiA9IGlzX3B2X2RvbWFpbihkKTsKQEAgLTIzMzEs
NiArMjQxNSw4IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0
aWdhdGlvbnModm9pZCkKIAogICAgIGJoaV9jYWxjdWxhdGlvbnMoKTsKIAor
ICAgIGl0c19jYWxjdWxhdGlvbnMoKTsKKwogICAgIHByaW50X2RldGFpbHMo
dGh1bmspOwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IDYwM2E0NDhj
YjNkMi4uNmZhNzc3NzQwOTFkIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNs
dWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTM0NCw3
ICszNDQsOCBAQCBYRU5fQ1BVRkVBVFVSRShHRFNfTk8sICAgICAgICAgICAg
IDE2KjMyKzI2KSAvKkEgIE5vIEdhdGhlciBEYXRhIFNhbXBsaW5nICovCiBY
RU5fQ1BVRkVBVFVSRShSRkRTX05PLCAgICAgICAgICAgIDE2KjMyKzI3KSAv
KkEgIE5vIFJlZ2lzdGVyIEZpbGUgRGF0YSBTYW1wbGluZyAqLwogWEVOX0NQ
VUZFQVRVUkUoUkZEU19DTEVBUiwgICAgICAgICAxNiozMisyOCkgLyohQSBS
ZWdpc3RlciBGaWxlKHMpIGNsZWFyZWQgYnkgVkVSVyAqLwogCi0vKiBJbnRl
bC1kZWZpbmVkIENQVSBmZWF0dXJlcywgTVNSX0FSQ0hfQ0FQUyAweDEwYS5l
ZHgsIHdvcmQgMTcgKi8KKy8qIEludGVsLWRlZmluZWQgQ1BVIGZlYXR1cmVz
LCBNU1JfQVJDSF9DQVBTIDB4MTBhLmVkeCwgd29yZCAxNyAoZXhwcmVzcyBp
biB0ZXJtcyBvZiB3b3JkIDE2KSAqLworWEVOX0NQVUZFQVRVUkUoSVRTX05P
LCAgICAgICAgICAgICAxNiozMis2MikgLyohQSBObyBJbmRpcmVjdCBUYXJn
ZXQgU2VsZWN0aW9uICovCiAKICNlbmRpZiAvKiBYRU5fQ1BVRkVBVFVSRSAq
LwogCmRpZmYgLS1naXQgYS94ZW4vdG9vbHMvZ2VuLWNwdWlkLnB5IGIveGVu
L3Rvb2xzL2dlbi1jcHVpZC5weQppbmRleCA0MTVkNjQ0ZGI1MTkuLjYxZDIz
NjA1OGE3OCAxMDA3NTUKLS0tIGEveGVuL3Rvb2xzL2dlbi1jcHVpZC5weQor
KysgYi94ZW4vdG9vbHMvZ2VuLWNwdWlkLnB5CkBAIC01MSw3ICs1MSw3IEBA
IGRlZiBwYXJzZV9kZWZpbml0aW9ucyhzdGF0ZSk6CiAgICAgICAgIHIiXHMr
L1wqKFtcdyFdKikgLiokIikKIAogICAgIHdvcmRfcmVnZXggPSByZS5jb21w
aWxlKAotICAgICAgICByIl4vXCogLiogd29yZCAoXGQqKSBcKi8kIikKKyAg
ICAgICAgciJeL1wqIC4qIHdvcmQgKFxkKikgLipcKi8kIikKICAgICBsYXN0
X3dvcmQgPSAtMQogCiAgICAgdGhpcyA9IHN5cy5tb2R1bGVzW19fbmFtZV9f
XQo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-01.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-01.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2FsdGVybmF0aXZlOiBTdXBwb3J0IHJlcGxhY2Vt
ZW50cyB3aGVuIGEgZmVhdHVyZSBpcyBub3QgcHJlc2VudAoKVXNlIHRoZSB0
b3AgYml0IG9mIGEtPmNwdWlkIHRvIGV4cHJlc3MgaW52ZXJ0ZWQgcG9sYXJp
dHkuICBUaGlzIHJlcXVpcmVzCnN0cmlwcGluZyB0aGUgdG9wIGJpdCBiYWNr
IG91dCB3aGVuIHBlcmZvcm1pbmcgdGhlIHNhbml0eSBjaGVja3MuCgpEZXNw
aXRlIG9ubHkgYmVpbmcgdXNlZCBvbmNlLCBjcmVhdGUgYSByZXBsYWNlIGJv
b2xlYW4gdG8gZXhwcmVzcyB0aGUgZGVjaXNpb24KbW9yZSBjbGVhcmx5IGlu
IF9hcHBseV9hbHRlcm5hdGl2ZXMoKS4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0t
Z2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94
ODYvYWx0ZXJuYXRpdmUuYwppbmRleCAxYmEzNWNiOWVkZTkuLjg4YzkwMDQ0
YzIwZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMK
KysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTE5Nyw2ICsx
OTcsOCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBseV9h
bHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAgICAg
IHVpbnQ4X3QgKnJlcGwgPSBBTFRfUkVQTF9QVFIoYSk7CiAgICAgICAgIHVp
bnQ4X3QgYnVmW01BWF9QQVRDSF9MRU5dOwogICAgICAgICB1bnNpZ25lZCBp
bnQgdG90YWxfbGVuID0gYS0+b3JpZ19sZW4gKyBhLT5wYWRfbGVuOworICAg
ICAgICB1bnNpZ25lZCBpbnQgZmVhdCA9IGEtPmNwdWlkICYgfkFMVF9GTEFH
X05PVDsKKyAgICAgICAgYm9vbCBpbnYgPSBhLT5jcHVpZCAmIEFMVF9GTEFH
X05PVCwgcmVwbGFjZTsKIAogICAgICAgICBpZiAoIGEtPnJlcGxfbGVuID4g
dG90YWxfbGVuICkKICAgICAgICAgewpAQCAtMjE0LDExICsyMTYsMTEgQEAg
c3RhdGljIGludCBpbml0X29yX2xpdmVwYXRjaCBfYXBwbHlfYWx0ZXJuYXRp
dmVzKHN0cnVjdCBhbHRfaW5zdHIgKnN0YXJ0LAogICAgICAgICAgICAgcmV0
dXJuIC1FTk9TUEM7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAoIGEtPmNw
dWlkID49IE5DQVBJTlRTICogMzIgKQorICAgICAgICBpZiAoIGZlYXQgPj0g
TkNBUElOVFMgKiAzMiApCiAgICAgICAgIHsKICAgICAgICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUgogICAgICAgICAgICAgICAgICAgICJBbHQgZm9yICVw
cywgZmVhdHVyZSAlI3ggb3V0c2lkZSBvZiBmZWF0dXJlc2V0IHJhbmdlICUj
eFxuIiwKLSAgICAgICAgICAgICAgICAgICBBTFRfT1JJR19QVFIoYSksIGEt
PmNwdWlkLCBOQ0FQSU5UUyAqIDMyKTsKKyAgICAgICAgICAgICAgICAgICBB
TFRfT1JJR19QVFIoYSksIGZlYXQsIE5DQVBJTlRTICogMzIpOwogICAgICAg
ICAgICAgcmV0dXJuIC1FUkFOR0U7CiAgICAgICAgIH0KIApAQCAtMjQzLDgg
KzI0NSwxNCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAg
ICAgICAgICBjb250aW51ZTsKICAgICAgICAgfQogCisgICAgICAgIC8qCisg
ICAgICAgICAqIFNob3VsZCBhIHJlcGxhY2VtZW50IGJlIHBlcmZvcm1lZD8g
IE1vc3QgcmVwbGFjZW1lbnRzIGhhdmUgcG9zaXRpdmUKKyAgICAgICAgICog
cG9sYXJpdHksIGJ1dCB3ZSBzdXBwb3J0IG5lZ2F0aXZlIHBvbGFyaXR5IHRv
by4KKyAgICAgICAgICovCisgICAgICAgIHJlcGxhY2UgPSBib290X2NwdV9o
YXMoZmVhdCkgXiBpbnY7CisKICAgICAgICAgLyogSWYgdGhlcmUgaXMgbm8g
cmVwbGFjZW1lbnQgdG8gbWFrZSwgc2VlIGFib3V0IG9wdGltaXNpbmcgdGhl
IG5vcHMuICovCi0gICAgICAgIGlmICggIWJvb3RfY3B1X2hhcyhhLT5jcHVp
ZCkgKQorICAgICAgICBpZiAoICFyZXBsYWNlICkKICAgICAgICAgewogICAg
ICAgICAgICAgLyogT3JpZ2luIHNpdGUgc2l0ZSBhbHJlYWR5IHRvdWNoZWQ/
ICBEb24ndCBub3AgYW55dGhpbmcuICovCiAgICAgICAgICAgICBpZiAoIGJh
c2UtPnByaXYgKQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v
YWx0ZXJuYXRpdmUuaAppbmRleCA2OTU1NWQ3ODFlZjkuLjg5YjdiZGNiODJl
NSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FsdGVy
bmF0aXZlLmgKQEAgLTEsNiArMSwxMyBAQAogI2lmbmRlZiBfX1g4Nl9BTFRF
Uk5BVElWRV9IX18KICNkZWZpbmUgX19YODZfQUxURVJOQVRJVkVfSF9fCiAK
Ky8qCisgKiBDb21tb24gdG8gYm90aCBDIGFuZCBBU00uICBFeHByZXNzIGEg
cmVwbGFjZW1lbnQgd2hlbiBhIGZlYXR1cmUgaXMgbm90CisgKiBhdmFpbGFi
bGUuCisgKi8KKyNkZWZpbmUgQUxUX0ZMQUdfTk9UICgxIDw8IDE1KQorI2Rl
ZmluZSBBTFRfTk9UKHgpIChBTFRfRkxBR19OT1QgfCAoeCkpCisKICNpZmRl
ZiBfX0FTU0VNQkxZX18KICNpbmNsdWRlIDxhc20vYWx0ZXJuYXRpdmUtYXNt
Lmg+CiAjZWxzZQpAQCAtMTEsNyArMTgsNyBAQAogc3RydWN0IF9fcGFja2Vk
IGFsdF9pbnN0ciB7CiAgICAgaW50MzJfdCAgb3JpZ19vZmZzZXQ7ICAgLyog
b3JpZ2luYWwgaW5zdHJ1Y3Rpb24gKi8KICAgICBpbnQzMl90ICByZXBsX29m
ZnNldDsgICAvKiBvZmZzZXQgdG8gcmVwbGFjZW1lbnQgaW5zdHJ1Y3Rpb24g
Ki8KLSAgICB1aW50MTZfdCBjcHVpZDsgICAgICAgICAvKiBjcHVpZCBiaXQg
c2V0IGZvciByZXBsYWNlbWVudCAqLworICAgIHVpbnQxNl90IGNwdWlkOyAg
ICAgICAgIC8qIGNwdWlkIGJpdCBzZXQgZm9yIHJlcGxhY2VtZW50ICh0b3Ag
Yml0IGlzIHBvbGFyaXR5KSAqLwogICAgIHVpbnQ4X3QgIG9yaWdfbGVuOyAg
ICAgIC8qIGxlbmd0aCBvZiBvcmlnaW5hbCBpbnN0cnVjdGlvbiAqLwogICAg
IHVpbnQ4X3QgIHJlcGxfbGVuOyAgICAgIC8qIGxlbmd0aCBvZiBuZXcgaW5z
dHJ1Y3Rpb24gKi8KICAgICB1aW50OF90ICBwYWRfbGVuOyAgICAgICAvKiBs
ZW5ndGggb2YgYnVpbGQtdGltZSBwYWRkaW5nICovCgo=

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-02.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-02.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2d1ZXN0OiBSZW1vdmUgdXNlIG9mIHRoZSBYZW4g
aHlwZXJjYWxsX3BhZ2UKCkluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCBJ
VFMsIFhlbiBuZWVkcyB0byBzdGFydCB1c2luZyByZXR1cm4gdGh1bmtzLgpU
aGVyZWZvcmUgdGhlIGFkdmljZSBpbiBYU0EtNDY2IGJlY29tZXMgcmVsZXZh
bnQsIGFuZCB0aGUgaHlwZXJjYWxsX3BhZ2UgbmVlZHMKdG8gYmUgcmVtb3Zl
ZC4KCkltcGxlbWVudCBlYXJseV9oeXBlcmNhbGwoKSwgd2l0aCBpbmZyYXN0
cnVjdHVyZSB0byBmaWd1cmUgb3V0IHRoZSBjb3JyZWN0Cmluc3RydWN0aW9u
IG9uIGZpcnN0IHVzZS4gIFVzZSBBTFRFUk5BVElWRSgpcyB0byByZXN1bHQg
aW4gaW5saW5lIGh5cGVyY2FsbHMsCmluY2x1ZGluZyB0aGUgQUxUX05PVCgp
IGZvcm0gc28gd2Ugb25seSBuZWVkIGEgc2luZ2xlIHN5bnRoZXRpYyBmZWF0
dXJlIGJpdC4KCk5vIG92ZXJhbGwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0IG9m
IFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTogQW5k
cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3
ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9ndWVzdC94ZW4vTWFrZWZp
bGUgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCmluZGV4IDI2
ZmI0YjEwMDdjMC4uOGIzMjUwYWE4ODg2IDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCisrKyBiL3hlbi9hcmNoL3g4Ni9n
dWVzdC94ZW4vTWFrZWZpbGUKQEAgLTEsNCArMSw0IEBACi1vYmoteSArPSBo
eXBlcmNhbGxfcGFnZS5vCitvYmotYmluLXkgKz0gaHlwZXJjYWxsLmluaXQu
bwogb2JqLXkgKz0geGVuLm8KIAogb2JqLWJpbi0kKENPTkZJR19QVkhfR1VF
U1QpICs9IHB2aC1ib290LmluaXQubwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGwuUyBiL3hlbi9hcmNoL3g4Ni9ndWVz
dC94ZW4vaHlwZXJjYWxsLlMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg
MDAwMDAwMDAwMDAwLi4wNWU0Mjk3OTRjYzQKLS0tIC9kZXYvbnVsbAorKysg
Yi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbC5TCkBAIC0wLDAg
KzEsNTAgQEAKKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4w
LW9yLWxhdGVyICovCisKKyNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPgorCisg
ICAgICAgIC5zZWN0aW9uIC5pbml0LnRleHQsICJheCIsIEBwcm9nYml0cwor
CisgICAgICAgIC8qCisgICAgICAgICAqIFVzZWQgZHVyaW5nIGVhcmx5IGJv
b3QsIGJlZm9yZSBhbHRlcm5hdGl2ZXMgaGF2ZSBydW4gYW5kIGlubGluZWQK
KyAgICAgICAgICogdGhlIGFwcHJvcHJpYXRlIGluc3RydWN0aW9uLiAgQ2Fs
bGVkIHVzaW5nIHRoZSBoeXBlcmNhbGwgQUJJLgorICAgICAgICAgKi8KK0ZV
TkMoZWFybHlfaHlwZXJjYWxsKQorICAgICAgICBjbXBiICAgICQwLCBlYXJs
eV9oeXBlcmNhbGxfaW5zbiglcmlwKQorICAgICAgICBqbCAgICAgIC5MX3Nl
dHVwCisgICAgICAgIGplICAgICAgMWYKKworICAgICAgICB2bW1jYWxsCisg
ICAgICAgIHJldAorCisxOiAgICAgIHZtY2FsbAorICAgICAgICByZXQKKwor
Lkxfc2V0dXA6CisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gc2V0dGlu
ZyB1cCB0aGUgZmlyc3QgdGltZSBhcm91bmQsIGFsbCByZWdpc3RlcnMgbmVl
ZAorICAgICAgICAgKiBwcmVzZXJ2aW5nLiAgU2F2ZSB0aGUgbm9uLWNhbGxl
ZS1zYXZlZCBvbmVzLgorICAgICAgICAgKi8KKyAgICAgICAgcHVzaCAgICAl
cjExCisgICAgICAgIHB1c2ggICAgJXIxMAorICAgICAgICBwdXNoICAgICVy
OQorICAgICAgICBwdXNoICAgICVyOAorICAgICAgICBwdXNoICAgICVyZGkK
KyAgICAgICAgcHVzaCAgICAlcnNpCisgICAgICAgIHB1c2ggICAgJXJkeAor
ICAgICAgICBwdXNoICAgICVyY3gKKyAgICAgICAgcHVzaCAgICAlcmF4CisK
KyAgICAgICAgY2FsbCAgICBlYXJseV9oeXBlcmNhbGxfc2V0dXAKKworICAg
ICAgICBwb3AgICAgICVyYXgKKyAgICAgICAgcG9wICAgICAlcmN4CisgICAg
ICAgIHBvcCAgICAgJXJkeAorICAgICAgICBwb3AgICAgICVyc2kKKyAgICAg
ICAgcG9wICAgICAlcmRpCisgICAgICAgIHBvcCAgICAgJXI4CisgICAgICAg
IHBvcCAgICAgJXI5CisgICAgICAgIHBvcCAgICAgJXIxMAorICAgICAgICBw
b3AgICAgICVyMTEKKworICAgICAgICBqbXAgICAgIGVhcmx5X2h5cGVyY2Fs
bAorRU5EKGVhcmx5X2h5cGVyY2FsbCkKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUyBiL3hlbi9hcmNoL3g4
Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUwpkZWxldGVkIGZpbGUgbW9k
ZSAxMDA2NDQKaW5kZXggN2FiNTVmYzFmNmU2Li4wMDAwMDAwMDAwMDAKLS0t
IGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGxfcGFnZS5TCisr
KyAvZGV2L251bGwKQEAgLTEsNzYgKzAsMCBAQAotI2luY2x1ZGUgPGFzbS9w
YWdlLmg+Ci0jaW5jbHVkZSA8YXNtL2FzbV9kZWZucy5oPgotI2luY2x1ZGUg
PHB1YmxpYy94ZW4uaD4KLQotICAgICAgICAuc2VjdGlvbiAiLnRleHQucGFn
ZV9hbGlnbmVkIiwgImF4IiwgQHByb2diaXRzCi0KLURBVEEoaHlwZXJjYWxs
X3BhZ2UsIFBBR0VfU0laRSkKLSAgICAgICAgIC8qIFBvaXNvbmVkIHdpdGgg
YHJldGAgZm9yIHNhZmV0eSBiZWZvcmUgaHlwZXJjYWxscyBhcmUgc2V0IHVw
LiAqLwotICAgICAgICAuZmlsbCBQQUdFX1NJWkUsIDEsIDB4YzMKLUVORCho
eXBlcmNhbGxfcGFnZSkKLQotLyoKLSAqIElkZW50aWZ5IGEgc3BlY2lmaWMg
aHlwZXJjYWxsIGluIHRoZSBoeXBlcmNhbGwgcGFnZQotICogQHBhcmFtIG5h
bWUgSHlwZXJjYWxsIG5hbWUuCi0gKi8KLSNkZWZpbmUgREVDTEFSRV9IWVBF
UkNBTEwobmFtZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAotICAgICAgICAuZ2xvYmwgSFlQRVJDQUxMXyAj
IyBuYW1lOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBcCi0gICAgICAgIC50eXBlICBIWVBFUkNBTExfICMjIG5hbWUs
IFNUVF9GVU5DOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFwKLSAgICAgICAgLnNpemUgIEhZUEVSQ0FMTF8gIyMgbmFtZSwgMzI7ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAotICAg
ICAgICAuc2V0ICAgSFlQRVJDQUxMXyAjIyBuYW1lLCBoeXBlcmNhbGxfcGFn
ZSArIF9fSFlQRVJWSVNPUl8gIyMgbmFtZSAqIDMyCi0KLURFQ0xBUkVfSFlQ
RVJDQUxMKHNldF90cmFwX3RhYmxlKQotREVDTEFSRV9IWVBFUkNBTEwobW11
X3VwZGF0ZSkKLURFQ0xBUkVfSFlQRVJDQUxMKHNldF9nZHQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChzdGFja19zd2l0Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChz
ZXRfY2FsbGJhY2tzKQotREVDTEFSRV9IWVBFUkNBTEwoZnB1X3Rhc2tzd2l0
Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChzY2hlZF9vcF9jb21wYXQpCi1ERUNM
QVJFX0hZUEVSQ0FMTChwbGF0Zm9ybV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxM
KHNldF9kZWJ1Z3JlZykKLURFQ0xBUkVfSFlQRVJDQUxMKGdldF9kZWJ1Z3Jl
ZykKLURFQ0xBUkVfSFlQRVJDQUxMKHVwZGF0ZV9kZXNjcmlwdG9yKQotREVD
TEFSRV9IWVBFUkNBTEwobWVtb3J5X29wKQotREVDTEFSRV9IWVBFUkNBTEwo
bXVsdGljYWxsKQotREVDTEFSRV9IWVBFUkNBTEwodXBkYXRlX3ZhX21hcHBp
bmcpCi1ERUNMQVJFX0hZUEVSQ0FMTChzZXRfdGltZXJfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTChldmVudF9jaGFubmVsX29wX2NvbXBhdCkKLURFQ0xBUkVf
SFlQRVJDQUxMKHhlbl92ZXJzaW9uKQotREVDTEFSRV9IWVBFUkNBTEwoY29u
c29sZV9pbykKLURFQ0xBUkVfSFlQRVJDQUxMKHBoeXNkZXZfb3BfY29tcGF0
KQotREVDTEFSRV9IWVBFUkNBTEwoZ3JhbnRfdGFibGVfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh2bV9hc3Npc3QpCi1ERUNMQVJFX0hZUEVSQ0FMTCh1cGRh
dGVfdmFfbWFwcGluZ19vdGhlcmRvbWFpbikKLURFQ0xBUkVfSFlQRVJDQUxM
KGlyZXQpCi1ERUNMQVJFX0hZUEVSQ0FMTCh2Y3B1X29wKQotREVDTEFSRV9I
WVBFUkNBTEwoc2V0X3NlZ21lbnRfYmFzZSkKLURFQ0xBUkVfSFlQRVJDQUxM
KG1tdWV4dF9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHhzbV9vcCkKLURFQ0xB
UkVfSFlQRVJDQUxMKG5taV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHNjaGVk
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoY2FsbGJhY2tfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh4ZW5vcHJvZl9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKGV2
ZW50X2NoYW5uZWxfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChwaHlzZGV2X29w
KQotREVDTEFSRV9IWVBFUkNBTEwoaHZtX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoc3lzY3RsKQotREVDTEFSRV9IWVBFUkNBTEwoZG9tY3RsKQotREVDTEFS
RV9IWVBFUkNBTEwoa2V4ZWNfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmdv
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoeGVucG11X29wKQotCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzEp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzIpCi1ERUNMQVJFX0hZUEVSQ0FM
TChhcmNoXzMpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzUpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzYp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzcpCi0KLS8qCi0gKiBMb2NhbCB2
YXJpYWJsZXM6Ci0gKiB0YWItd2lkdGg6IDgKLSAqIGluZGVudC10YWJzLW1v
ZGU6IG5pbAotICogRW5kOgotICovCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvZ3Vlc3QveGVuL3hlbi5jIGIveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94
ZW4uYwppbmRleCA3NDg0YjNmNzNhZDMuLjJjMzBkYjA1ZGZhNyAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94ZW4uYworKysgYi94ZW4v
YXJjaC94ODYvZ3Vlc3QveGVuL3hlbi5jCkBAIC0yNiw3ICsyNiw2IEBACiBi
b29sIF9fcmVhZF9tb3N0bHkgeGVuX2d1ZXN0OwogCiB1aW50MzJfdCBfX3Jl
YWRfbW9zdGx5IHhlbl9jcHVpZF9iYXNlOwotZXh0ZXJuIGNoYXIgaHlwZXJj
YWxsX3BhZ2VbXTsKIHN0YXRpYyBzdHJ1Y3QgcmFuZ2VzZXQgKm1lbTsKIAog
REVGSU5FX1BFUl9DUFUodW5zaWduZWQgaW50LCB2Y3B1X2lkKTsKQEAgLTM1
LDYgKzM0LDUwIEBAIHN0YXRpYyBzdHJ1Y3QgdmNwdV9pbmZvICp2Y3B1X2lu
Zm87CiBzdGF0aWMgdW5zaWduZWQgbG9uZyB2Y3B1X2luZm9fbWFwcGVkW0JJ
VFNfVE9fTE9OR1MoTlJfQ1BVUyldOwogREVGSU5FX1BFUl9DUFUoc3RydWN0
IHZjcHVfaW5mbyAqLCB2Y3B1X2luZm8pOwogCisvKgorICogV2hpY2ggaW5z
dHJ1Y3Rpb24gdG8gdXNlIGZvciBlYXJseSBoeXBlcmNhbGxzOgorICogICA8
IDAgc2V0dXAKKyAqICAgICAwIHZtY2FsbAorICogICA+IDAgdm1tY2FsbAor
ICovCitpbnQ4X3QgX19pbml0ZGF0YSBlYXJseV9oeXBlcmNhbGxfaW5zbiA9
IC0xOworCisvKgorICogQ2FsbGVkIG9uY2UgZHVyaW5nIHRoZSBmaXJzdCBo
eXBlcmNhbGwgdG8gZmlndXJlIG91dCB3aGljaCBpbnN0cnVjdGlvbiB0bwor
ICogdXNlLiAgRXJyb3IgaGFuZGxpbmcgb3B0aW9ucyBhcmUgbGltaXRlZC4K
KyAqLwordm9pZCBhc21saW5rYWdlIF9faW5pdCBlYXJseV9oeXBlcmNhbGxf
c2V0dXAodm9pZCkKK3sKKyAgICBCVUdfT04oZWFybHlfaHlwZXJjYWxsX2lu
c24gIT0gLTEpOworCisgICAgaWYgKCAhYm9vdF9jcHVfZGF0YS54ODZfdmVu
ZG9yICkKKyAgICB7CisgICAgICAgIHVuc2lnbmVkIGludCBlYXgsIGVieCwg
ZWN4LCBlZHg7CisKKyAgICAgICAgY3B1aWQoMCwgJmVheCwgJmVieCwgJmVj
eCwgJmVkeCk7CisKKyAgICAgICAgYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ID0geDg2X2NwdWlkX2xvb2t1cF92ZW5kb3IoZWJ4LCBlY3gsIGVkeCk7Cisg
ICAgfQorCisgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ICkKKyAgICB7CisgICAgY2FzZSBYODZfVkVORE9SX0lOVEVMOgorICAgIGNh
c2UgWDg2X1ZFTkRPUl9DRU5UQVVSOgorICAgIGNhc2UgWDg2X1ZFTkRPUl9T
SEFOR0hBSToKKyAgICAgICAgZWFybHlfaHlwZXJjYWxsX2luc24gPSAwOwor
ICAgICAgICBzZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpOworICAgICAgICBicmVhazsKKworICAgIGNhc2UgWDg2X1ZFTkRP
Ul9BTUQ6CisgICAgY2FzZSBYODZfVkVORE9SX0hZR09OOgorICAgICAgICBl
YXJseV9oeXBlcmNhbGxfaW5zbiA9IDE7CisgICAgICAgIGJyZWFrOworCisg
ICAgZGVmYXVsdDoKKyAgICAgICAgQlVHKCk7CisgICAgfQorfQorCiBzdGF0
aWMgdm9pZCBfX2luaXQgZmluZF94ZW5fbGVhdmVzKHZvaWQpCiB7CiAgICAg
dWludDMyX3QgZWF4LCBlYngsIGVjeCwgZWR4LCBiYXNlOwpAQCAtMzM3LDkg
KzM4MCw2IEBAIGNvbnN0IHN0cnVjdCBoeXBlcnZpc29yX29wcyAqX19pbml0
IHhnX3Byb2JlKHZvaWQpCiAgICAgaWYgKCAheGVuX2NwdWlkX2Jhc2UgKQog
ICAgICAgICByZXR1cm4gTlVMTDsKIAotICAgIC8qIEZpbGwgdGhlIGh5cGVy
Y2FsbCBwYWdlLiAqLwotICAgIHdybXNybChjcHVpZF9lYngoeGVuX2NwdWlk
X2Jhc2UgKyAyKSwgX19wYShoeXBlcmNhbGxfcGFnZSkpOwotCiAgICAgeGVu
X2d1ZXN0ID0gdHJ1ZTsKIAogICAgIHJldHVybiAmb3BzOwpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmggYi94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vY3B1ZmVhdHVyZXMuaAppbmRleCBi
YTNkZjE3NGI3NmUuLjllM2VkMjFjMDI2ZCAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKKysrIGIveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKQEAgLTQyLDYgKzQy
LDcgQEAgWEVOX0NQVUZFQVRVUkUoWEVOX1NIU1RLLCAgICAgICAgIFg4Nl9T
WU5USCgyNikpIC8qIFhlbiB1c2VzIENFVCBTaGFkb3cgU3RhY2tzICoKIFhF
Tl9DUFVGRUFUVVJFKFhFTl9JQlQsICAgICAgICAgICBYODZfU1lOVEgoMjcp
KSAvKiBYZW4gdXNlcyBDRVQgSW5kaXJlY3QgQnJhbmNoIFRyYWNraW5nICov
CiBYRU5fQ1BVRkVBVFVSRShJQlBCX0VOVFJZX1BWLCAgICAgWDg2X1NZTlRI
KDI4KSkgLyogTVNSX1BSRURfQ01EIHVzZWQgYnkgWGVuIGZvciBQViAqLwog
WEVOX0NQVUZFQVRVUkUoSUJQQl9FTlRSWV9IVk0sICAgIFg4Nl9TWU5USCgy
OSkpIC8qIE1TUl9QUkVEX0NNRCB1c2VkIGJ5IFhlbiBmb3IgSFZNICovCitY
RU5fQ1BVRkVBVFVSRShVU0VfVk1DQUxMLCAgICAgICAgWDg2X1NZTlRIKDMw
KSkgLyogVXNlIFZNQ0FMTCBpbnN0ZWFkIG9mIFZNTUNBTEwgKi8KIAogLyog
QnVnIHdvcmRzIGZvbGxvdyB0aGUgc3ludGhldGljIHdvcmRzLiAqLwogI2Rl
ZmluZSBYODZfTlJfQlVHIDEKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaCBiL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaAppbmRleCA2NjViNDcyZDA1
YWMuLjk2MDA0ZGVjOTkwOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2d1ZXN0L3hlbi1oY2FsbC5oCisrKyBiL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaApAQCAtMzAsOSArMzAs
MTEgQEAKICAgICAoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICgg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKLSAgICAgICAgICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNb
b2Zmc2V0XSIgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAg
ICAgIEFMVEVSTkFUSVZFXzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgInZtbWNhbGwiLCBBTFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwp
LCAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4
Nl9GRUFUVVJFX1VTRV9WTUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgIDogIj1hIiAocmVzKSwgIj1EIiAodG1wX18pIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgIDogW29mZnNldF0g
ImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2FsbCksICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgICAgIjEiICgobG9uZykoYTEpKSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgKHR5cGUpcmVzOyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKQEAgLTQyLDEw
ICs0NCwxMiBAQAogICAgICh7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICBsb25nIHJlcywgdG1wX187ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBhc20gdm9sYXRp
bGUgKCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgImNhbGwgaHlwZXJjYWxsX3BhZ2Ug
KyAlY1tvZmZzZXRdIiAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgQUxURVJOQVRJVkVfMigiY2FsbCBlYXJseV9oeXBlcmNhbGwi
LCAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAidm1tY2FsbCIsIEFMVF9OT1QoWDg2X0ZFQVRVUkVfVVNFX1ZN
Q0FMTCksICAgXAorICAgICAgICAgICAgICAgICAgICAgICAgICAidm1jYWxs
IiwgWDg2X0ZFQVRVUkVfVVNFX1ZNQ0FMTCkgICAgICAgICAgICAgXAogICAg
ICAgICAgICAgOiAiPWEiIChyZXMpLCAiPUQiICh0bXBfXyksICI9UyIgKHRt
cF9fKSAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICBBU01f
Q0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgOiBbb2Zmc2V0XSAiaSIgKGhjYWxs
ICogMzIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgOiAiMCIgKGhjYWxsKSwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAiMSIg
KChsb25nKShhMSkpLCAiMiIgKChsb25nKShhMikpICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgICAgICAgICAgOiAibWVtb3J5IiApOyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICAodHlwZSlyZXM7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXApAQCAtNTUsMTAgKzU5LDEyIEBA
CiAgICAgKHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGxvbmcg
cmVzLCB0bXBfXzsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICAiY2FsbCBoeXBlcmNhbGxfcGFnZSArICVjW29mZnNl
dF0iICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICBB
TFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5cGVyY2FsbCIsICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2
bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSwgICBc
CisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2bWNhbGwiLCBYODZfRkVB
VFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAgICBcCiAgICAgICAgICAgICA6
ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSwgIj1TIiAodG1wX18pLCAiPWQi
ICh0bXBfXykgICAgICBcCiAgICAgICAgICAgICAgIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiksICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICA6
ICIwIiAoaGNhbGwpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcpKGEx
KSksICIyIiAoKGxvbmcpKGEyKSksICIzIiAoKGxvbmcpKGEzKSkgICAgICBc
CiAgICAgICAgICAgICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICh0eXBl
KXJlczsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCkBAIC02OSwxMCArNzUsMTIgQEAKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgcmVnaXN0ZXIgbG9uZyBf
YTQgYXNtICgicjEwIikgPSAoKGxvbmcpKGE0KSk7ICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICggICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNbb2Zmc2V0XSIgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIEFMVEVSTkFUSVZF
XzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtbWNhbGwiLCBB
TFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwpLCAgIFwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIj1hIiAocmVz
KSwgIj1EIiAodG1wX18pLCAiPVMiICh0bXBfXyksICI9ZCIgKHRtcF9fKSwg
ICAgIFwKICAgICAgICAgICAgICAgIj0mciIgKHRtcF9fKSBBU01fQ0FMTF9D
T05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgIDogW29mZnNldF0gImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2Fs
bCksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgICAgICAgIjEiICgobG9uZykoYTEpKSwgIjIiICgo
bG9uZykoYTIpKSwgIjMiICgobG9uZykoYTMpKSwgICAgIFwKICAgICAgICAg
ICAgICAgIjQiIChfYTQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-03.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-03.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IChNaXMpYWxpZ24gX194ODZfaW5kaXJlY3RfdGh1bmtf
KiB0byBtaXRpZ2F0ZSBJVFMKClRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRp
cmVjdApicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hl
biBpbiB0aGUgZmlyc3QgaGFsZiBvZiBhIGNhY2hlbGluZS4KCkFycmFuZ2Ug
Zm9yIF9feDg2X2luZGlyZWN0X3RodW5rXyogdG8gYWx3YXlzIGJlIGluIHRo
ZSBzZWNvbmQgaGFsZi4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDY5IC8gQ1ZF
LTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TCmluZGV4IGZkNTQ5M2MyMmIxNi4uYzRiOTc4ZDY3Yjhl
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwor
KysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMTEsNiAr
MTEsMTAgQEAKIAogI2luY2x1ZGUgPGFzbS9hc21fZGVmbnMuaD4KIAorLyog
QWxpZ25tZW50IGlzIGRlYWx0IHdpdGggZXhwbGljaXRseSBoZXJlOyBvdmVy
cmlkZSB0aGUgcmVzcGVjdGl2ZSBtYWNyby4gKi8KKyN1bmRlZiBTWU1fQUxJ
R04KKyNkZWZpbmUgU1lNX0FMSUdOKGFsaWduLi4uKQorCiAubWFjcm8gSU5E
X1RIVU5LX1JFVFBPTElORSByZWc6cmVxCiAgICAgICAgIGNhbGwgMWYKICAg
ICAgICAgaW50MwpAQCAtMzUsNiArMzksMTYgQEAKIC5tYWNybyBHRU5fSU5E
SVJFQ1RfVEhVTksgcmVnOnJlcQogICAgICAgICAuc2VjdGlvbiAudGV4dC5f
X3g4Nl9pbmRpcmVjdF90aHVua19ccmVnLCAiYXgiLCBAcHJvZ2JpdHMKIAor
ICAgICAgICAvKgorICAgICAgICAgKiBUaGUgSW5kaXJlY3QgVGFyZ2V0IFNl
bGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5zIHRoYXQK
KyAgICAgICAgICogaW5kaXJlY3QgYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRz
KSBhcmUgdW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0CisgICAgICAgICAqIGhh
bGYgb2YgYSBjYWNoZWxpbmUuICBBcnJhbmdlIGZvciB0aGVtIHRvIGJlIGlu
IHRoZSBzZWNvbmQgaGFsZi4KKyAgICAgICAgICoKKyAgICAgICAgICogQWxp
Z24gdG8gNjQsIHRoZW4gc2tpcCAzMi4KKyAgICAgICAgICovCisgICAgICAg
IC5iYWxpZ24gNjQKKyAgICAgICAgLmZpbGwgMzIsIDEsIDB4Y2MKKwogRlVO
QyhfX3g4Nl9pbmRpcmVjdF90aHVua19ccmVnKQogICAgICAgICBBTFRFUk5B
VElWRV8yIF9fc3RyaW5naWZ5KElORF9USFVOS19SRVRQT0xJTkUgXHJlZyks
ICAgICAgICAgICAgICBcCiAgICAgICAgIF9fc3RyaW5naWZ5KElORF9USFVO
S19MRkVOQ0UgXHJlZyksIFg4Nl9GRUFUVVJFX0lORF9USFVOS19MRkVOQ0Us
IFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-04.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-04.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3RodW5rOiAoTWlzKWFsaWduIHRoZSBSRVRzIGlu
IGNsZWFyX2JoYl9sb29wcygpIHRvIG1pdGlnYXRlIElUUwoKVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0IGluZGlyZWN0CmJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdCBoYWxmIG9mIGEgY2Fj
aGVsaW5lLgoKY2xlYXJfYmhiX2xvb3BzKCkgaGFzIGEgcHJlY2lzZSBsYXlv
dXQgb2YgYnJhbmNoZXMuICBUaGUgYWxpZ25tZW50IGZvcgpwZXJmb3JtYW5j
ZSBjYXVzZSB0aGUgUkVUcyB0byBhbHdheXMgYmUgaW4gYW4gdW5zYWZlIHBv
c2l0aW9uLCBhbmQgY29udmVydGluZwp0aG9zZSB0byByZXR1cm4gdGh1bmtz
IGNoYW5nZXMgdGhlIGJyYW5jaGluZyBwYXR0ZXJuLiAgV2hpbGUgc3VjaCBh
IGNvbnZlcnNpb24KaXMgYmVsaWV2ZWQgdG8gYmUgc2FmZSwgY2xlYXJfYmhi
X2xvb3BzKCkgaXMgYWxzbyBhIHBlcmZvcm1hbmNlLXJlbGV2YW50CmZhc3Rw
YXRoLCBzbyAobWlzKWFsaWduIHRoZSBSRVRzIHRvIGJlIGluIGEgc2FmZSBw
b3NpdGlvbi4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0
IG9mIFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUyBi
L3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCA2NzhjMDBjNWQwNmYu
LjUyNjI1ZjRlMmMxNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2JoYi10
aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwpAQCAtNTAs
NyArNTAsMTIgQEAgRU5EKGNsZWFyX2JoYl90c3gpCiAgKiAgIHJldAogICoK
ICAqIFRoZSBDQUxML1JFVHMgYXJlIG5lY2Vzc2FyeSB0byBwcmV2ZW50IHRo
ZSBMb29wIFN0cmVhbSBEZXRlY3RvciBmcm9tCi0gKiBpbnRlcmZlcmluZy4g
IFRoZSBhbGlnbm1lbnQgaXMgZm9yIHBlcmZvcm1hbmNlIGFuZCBub3Qgc2Fm
ZXR5LgorICogaW50ZXJmZXJpbmcuCisgKgorICogVGhlIC5iYWxpZ24ncyBh
cmUgZm9yIHBlcmZvcm1hbmNlLCBidXQgdGhleSBjYXVzZSB0aGUgUkVUcyB0
byBiZSBpbiB1bnNhZmUKKyAqIHBvc2l0aW9ucyB3aXRoIHJlc3BlY3QgdG8g
SW5kaXJlY3QgVGFyZ2V0IFNlbGVjdGlvbi4gIFRoZSAuc2tpcHMgYXJlIHRv
CisgKiBtb3ZlIHRoZSBSRVRzIGludG8gSVRTLXNhZmUgcG9zaXRpb25zLCBy
YXRoZXIgdGhhbiB1c2luZyB0aGUgc2xvd3BhdGgKKyAqIHRocm91Z2ggX194
ODZfcmV0dXJuX3RodW5rLgogICoKICAqIFRoZSAic2hvcnQiIHNlcXVlbmNl
ICg1IGFuZCA1KSBpcyBmb3IgQ1BVcyBwcmlvciB0byBBbGRlciBMYWtlIC8g
U2FwcGhpcmUKICAqIFJhcGlkcyAoaS5lLiBDb3JlcyBwcmlvciB0byBHb2xk
ZW4gQ292ZSBhbmQvb3IgR3JhY2Vtb250KS4KQEAgLTY2LDEyICs3MSwxNCBA
QCBGVU5DKGNsZWFyX2JoYl9sb29wcykKICAgICAgICAgam1wICAgICA1Zgog
ICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAgICAgIC5i
YWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtICguTHIxIC0gMWYpLCAw
eGNjCiAxOiAgICAgIGNhbGwgICAgMmYKLSAgICAgICAgcmV0CisuTHIxOiAg
IHJldAogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAg
ICAgIC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtIDE4IC8qICgu
THIyIC0gMmYpIGJ1dCBDbGFuZyBJQVMgZG9lc24ndCBsaWtlIHRoaXMgKi8s
IDB4Y2MKIDI6ICAgICAgQUxURVJOQVRJVkUgIm1vdiAkNSwgJWVheCIsICJt
b3YgJDcsICVlYXgiLCBYODZfU1BFQ19CSEJfTE9PUFNfTE9ORwogCiAzOiAg
ICAgIGptcCAgICAgNGYKQEAgLTgzLDcgKzkwLDcgQEAgRlVOQyhjbGVhcl9i
aGJfbG9vcHMpCiAgICAgICAgIHN1YiAgICAgJDEsICVlY3gKICAgICAgICAg
am56ICAgICAxYgogCi0gICAgICAgIHJldAorLkxyMjogICByZXQKIDU6CiAg
ICAgICAgIC8qCiAgICAgICAgICAqIFRoZSBJbnRlbCBzZXF1ZW5jZSBoYXMg
YW4gTEZFTkNFIGhlcmUuICBUaGUgcHVycG9zZSBpcyB0byBlbnN1cmUK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-05.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-05.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3N0dWJzOiBJbnRyb2R1Y2UgcGxhY2VfcmV0KCkg
dG8gYWJzdHJhY3QgYXdheSByYXcgMHhjMydzCgpUaGUgSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5z
IHRoYXQgaW5kaXJlY3QKYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUg
dW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0IGhhbGYgb2YgYSBjYWNoZWxpbmUu
ClRoaXMgbWVhbnMgaXQncyBub3Qgc2FmZSBmb3IgbG9naWMgdXNpbmcgdGhl
IHN0dWJzIHRvIHdyaXRlIHJhdyAweGMzJ3MuCgpJbnRyb2R1Y2UgcGxhY2Vf
cmV0KCkgd2hpY2gsIGZvciBub3csIHdyaXRlcyBhIHJhdyAweGMzIGJ1dCB3
aWxsIGNvbnRhaW4KYWRkaXRpb25hbCBsb2dpYyB3aGVuIHJldHVybiB0aHVu
a3MgYXJlIGluIHVzZS4KCnN0dWJfc2VsZnRlc3QoKSBkb2Vzbid0IHN0cmlj
dGx5IG5lZWQgdG8gYmUgY29udmVydGVkIGFzIHRoZXkgb25seSBydW4gb24K
Ym9vdCwgYnV0IGRvaW5nIHNvIGdldHMgdXMgYSBwYXJ0aWFsIHRlc3Qgb2Yg
cGxhY2VfcmV0KCkgdG9vLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ2OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQt
b2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu
Y29tPgpSZXZpZXdlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvdG9vbHMvdGVzdHMveDg2X2Vt
dWxhdG9yL3g4Ni1lbXVsYXRlLmggYi90b29scy90ZXN0cy94ODZfZW11bGF0
b3IveDg2LWVtdWxhdGUuaAppbmRleCA4ZjhhY2NmZTNlNzAuLjk0NmFhYTlk
NjYwYiAxMDA2NDQKLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKKysrIGIvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKQEAgLTY4LDYgKzY4LDEyIEBACiAKICNkZWZpbmUgaXNf
Y2Fub25pY2FsX2FkZHJlc3MoeCkgKCgoaW50NjRfdCkoeCkgPj4gNDcpID09
ICgoaW50NjRfdCkoeCkgPj4gNjMpKQogCitzdGF0aWMgaW5saW5lIHZvaWQg
KnBsYWNlX3JldCh2b2lkICpwdHIpCit7CisgICAgKih1aW50OF90ICopcHRy
ID0gMHhjMzsKKyAgICByZXR1cm4gcHRyICsgMTsKK30KKwogZXh0ZXJuIHVp
bnQzMl90IG14Y3NyX21hc2s7CiBleHRlcm4gc3RydWN0IGNwdV9wb2xpY3kg
Y3A7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hl
bi9hcmNoL3g4Ni9NYWtlZmlsZQppbmRleCBjMWU2NDI3OGNlODUuLmE3ZTVh
ODI2ODlkZSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisr
KyBiL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtMTEsOSArMTEsNyBAQCBv
YmotJChDT05GSUdfUFYpICs9IHB2Lwogb2JqLXkgKz0geDg2XzY0Lwogb2Jq
LXkgKz0geDg2X2VtdWxhdGUvCiAKLWFsdGVybmF0aXZlLXkgOj0gYWx0ZXJu
YXRpdmUuaW5pdC5vCi1hbHRlcm5hdGl2ZS0kKENPTkZJR19MSVZFUEFUQ0gp
IDo9Ci1vYmotYmluLXkgKz0gJChhbHRlcm5hdGl2ZS15KQorb2JqLXkgKz0g
YWx0ZXJuYXRpdmUubwogb2JqLXkgKz0gYXBpYy5vCiBvYmoteSArPSBiaGIt
dGh1bmsubwogb2JqLXkgKz0gYml0b3BzLm8KQEAgLTQxLDcgKzM5LDcgQEAg
b2JqLXkgKz0gaHlwZXJjYWxsLm8KIG9iai15ICs9IGkzODcubwogb2JqLXkg
Kz0gaTgyNTkubwogb2JqLXkgKz0gaW9fYXBpYy5vCi1vYmotJChDT05GSUdf
TElWRVBBVENIKSArPSBhbHRlcm5hdGl2ZS5vIGxpdmVwYXRjaC5vCitvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9hbHRlcm5hdGl2ZS5jIGIveGVuL2FyY2gveDg2L2FsdGVybmF0
aXZlLmMKaW5kZXggODhjOTAwNDRjMjBkLi5lYzQ1MWQ5NjJjMTAgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCisrKyBiL3hlbi9h
cmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCkBAIC0xMzcsNiArMTM3LDIwIEBAIHZv
aWQgaW5pdF9vcl9saXZlcGF0Y2ggYWRkX25vcHModm9pZCAqaW5zbnMsIHVu
c2lnbmVkIGludCBsZW4pCiAgICAgfQogfQogCisvKgorICogUGxhY2UgYSBy
ZXR1cm4gYXQgQHB0ci4gIEBwdHIgbXVzdCBiZSBpbiB0aGUgd3JpdGFibGUg
YWxpYXMgb2YgYSBzdHViLgorICoKKyAqIFJldHVybnMgdGhlIG5leHQgcG9z
aXRpb24gdG8gd3JpdGUgaW50byB0aGUgc3R1Yi4KKyAqLwordm9pZCAqcGxh
Y2VfcmV0KHZvaWQgKnB0cikKK3sKKyAgICB1aW50OF90ICpwID0gcHRyOwor
CisgICAgKnArKyA9IDB4YzM7CisKKyAgICByZXR1cm4gcDsKK30KKwogLyoK
ICAqIHRleHRfcG9rZSAtIFVwZGF0ZSBpbnN0cnVjdGlvbnMgb24gYSBsaXZl
IGtlcm5lbCBvciBub24tZXhlY3V0ZWQgY29kZS4KICAqIEBhZGRyOiBhZGRy
ZXNzIHRvIG1vZGlmeQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2V4dGFi
bGUuYyBiL3hlbi9hcmNoL3g4Ni9leHRhYmxlLmMKaW5kZXggNzA1Y2Y5ZWI5
NGNhLi4xNTcyZWZhNjlhMDAgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9l
eHRhYmxlLmMKKysrIGIveGVuL2FyY2gveDg2L2V4dGFibGUuYwpAQCAtMTUx
LDIwICsxNTEsMjAgQEAgc2VhcmNoX2V4Y2VwdGlvbl90YWJsZShjb25zdCBz
dHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncywgdW5zaWduZWQgbG9uZyAqc3R1
Yl9yYSkKIGludCBfX2luaXQgY2ZfY2hlY2sgc3R1Yl9zZWxmdGVzdCh2b2lk
KQogewogICAgIHN0YXRpYyBjb25zdCBzdHJ1Y3QgewotICAgICAgICB1aW50
OF90IG9wY1s4XTsKKyAgICAgICAgdWludDhfdCBvcGNbN107CiAgICAgICAg
IHVpbnQ2NF90IHJheDsKICAgICAgICAgdW5pb24gc3R1Yl9leGNlcHRpb25f
dG9rZW4gcmVzOwogICAgIH0gdGVzdHNbXSBfX2luaXRjb25zdCA9IHsKICNk
ZWZpbmUgZW5kYnI2NCAweGYzLCAweDBmLCAweDFlLCAweGZhCi0gICAgICAg
IHsgLm9wYyA9IHsgZW5kYnI2NCwgMHgwZiwgMHhiOSwgMHhjMywgMHhjMyB9
LCAvKiB1ZDEgKi8KKyAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDBm
LCAweGI5LCAweDkwIH0sIC8qIHVkMSAqLwogICAgICAgICAgIC5yZXMuZmll
bGRzLnRyYXBuciA9IFg4Nl9FWENfVUQgfSwKLSAgICAgICAgeyAub3BjID0g
eyBlbmRicjY0LCAweDkwLCAweDAyLCAweDAwLCAweGMzIH0sIC8qIG5vcDsg
YWRkICglcmF4KSwlYWwgKi8KKyAgICAgICAgeyAub3BjID0geyBlbmRicjY0
LCAweDkwLCAweDAyLCAweDAwIH0sIC8qIG5vcDsgYWRkICglcmF4KSwlYWwg
Ki8KICAgICAgICAgICAucmF4ID0gMHgwMTIzNDU2Nzg5YWJjZGVmLAogICAg
ICAgICAgIC5yZXMuZmllbGRzLnRyYXBuciA9IFg4Nl9FWENfR1AgfSwKLSAg
ICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDAyLCAweDA0LCAweDA0LCAw
eGMzIH0sIC8qIGFkZCAoJXJzcCwlcmF4KSwlYWwgKi8KKyAgICAgICAgeyAu
b3BjID0geyBlbmRicjY0LCAweDAyLCAweDA0LCAweDA0IH0sIC8qIGFkZCAo
JXJzcCwlcmF4KSwlYWwgKi8KICAgICAgICAgICAucmF4ID0gMHhmZWRjYmE5
ODc2NTQzMjEwVUwsCiAgICAgICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0g
WDg2X0VYQ19TUyB9LAotICAgICAgICB7IC5vcGMgPSB7IGVuZGJyNjQsIDB4
Y2MsIDB4YzMsIDB4YzMsIDB4YzMgfSwgLyogaW50MyAqLworICAgICAgICB7
IC5vcGMgPSB7IGVuZGJyNjQsIDB4Y2MsIDB4OTAsIDB4OTAgfSwgLyogaW50
MyAqLwogICAgICAgICAgIC5yZXMuZmllbGRzLnRyYXBuciA9IFg4Nl9FWENf
QlAgfSwKICN1bmRlZiBlbmRicjY0CiAgICAgfTsKQEAgLTE4Myw2ICsxODMs
NyBAQCBpbnQgX19pbml0IGNmX2NoZWNrIHN0dWJfc2VsZnRlc3Qodm9pZCkK
IAogICAgICAgICBtZW1zZXQocHRyLCAweGNjLCBTVFVCX0JVRl9TSVpFIC8g
Mik7CiAgICAgICAgIG1lbWNweShwdHIsIHRlc3RzW2ldLm9wYywgQVJSQVlf
U0laRSh0ZXN0c1tpXS5vcGMpKTsKKyAgICAgICAgcGxhY2VfcmV0KHB0ciAr
IEFSUkFZX1NJWkUodGVzdHNbaV0ub3BjKSk7CiAgICAgICAgIHVubWFwX2Rv
bWFpbl9wYWdlKHB0cik7CiAKICAgICAgICAgYXNtIHZvbGF0aWxlICggIklO
RElSRUNUX0NBTEwgJVtzdGJdXG4iCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvaW5jbHVkZS9hc20vYWx0ZXJuYXRpdmUuaCBiL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCmluZGV4IDg5YjdiZGNiODJlNS4u
ODQxYTYzZWJmMWI2IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVk
ZS9hc20vYWx0ZXJuYXRpdmUuaAorKysgYi94ZW4vYXJjaC94ODYvaW5jbHVk
ZS9hc20vYWx0ZXJuYXRpdmUuaApAQCAtMzAsNiArMzAsOCBAQCBzdHJ1Y3Qg
X19wYWNrZWQgYWx0X2luc3RyIHsKICNkZWZpbmUgQUxUX1JFUExfUFRSKGEp
ICAgICBfX0FMVF9QVFIoYSwgcmVwbF9vZmZzZXQpCiAKIGV4dGVybiB2b2lk
IGFkZF9ub3BzKHZvaWQgKmluc25zLCB1bnNpZ25lZCBpbnQgbGVuKTsKK3Zv
aWQgKnBsYWNlX3JldCh2b2lkICpwdHIpOworCiAvKiBTaW1pbGFyIHRvIGFs
dGVybmF0aXZlX2luc3RydWN0aW9ucyBleGNlcHQgaXQgY2FuIGJlIHJ1biB3
aXRoIElSUXMgZW5hYmxlZC4gKi8KIGV4dGVybiBpbnQgYXBwbHlfYWx0ZXJu
YXRpdmVzKHN0cnVjdCBhbHRfaW5zdHIgKnN0YXJ0LCBzdHJ1Y3QgYWx0X2lu
c3RyICplbmQpOwogZXh0ZXJuIHZvaWQgYWx0ZXJuYXRpdmVfaW5zdHJ1Y3Rp
b25zKHZvaWQpOwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3B2L2VtdWwt
cHJpdi1vcC5jIGIveGVuL2FyY2gveDg2L3B2L2VtdWwtcHJpdi1vcC5jCmlu
ZGV4IDcwMTUwYzI3MjI3Ni4uZmY1ZDFjOWY4NjM0IDEwMDY0NAotLS0gYS94
ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMKKysrIGIveGVuL2FyY2gv
eDg2L3B2L2VtdWwtcHJpdi1vcC5jCkBAIC03Niw3ICs3Niw2IEBAIHN0YXRp
YyBpb19lbXVsX3N0dWJfdCAqaW9fZW11bF9zdHViX3NldHVwKHN0cnVjdCBw
cml2X29wX2N0eHQgKmN0eHQsIHU4IG9wY29kZSwKICAgICAgICAgMHg0MSwg
MHg1YywgLyogcG9wICVyMTIgICovCiAgICAgICAgIDB4NWQsICAgICAgIC8q
IHBvcCAlcmJwICAqLwogICAgICAgICAweDViLCAgICAgICAvKiBwb3AgJXJi
eCAgKi8KLSAgICAgICAgMHhjMywgICAgICAgLyogcmV0ICAgICAgICovCiAg
ICAgfTsKIAogICAgIGNvbnN0IHN0cnVjdCBzdHVicyAqdGhpc19zdHVicyA9
ICZ0aGlzX2NwdShzdHVicyk7CkBAIC0xMjYsMTEgKzEyNSwxMyBAQCBzdGF0
aWMgaW9fZW11bF9zdHViX3QgKmlvX2VtdWxfc3R1Yl9zZXR1cChzdHJ1Y3Qg
cHJpdl9vcF9jdHh0ICpjdHh0LCB1OCBvcGNvZGUsCiAKICAgICBBUFBFTkRf
Q0FMTChzYXZlX2d1ZXN0X2dwcnMpOwogICAgIEFQUEVORF9CVUZGKGVwaWxv
Z3VlKTsKKyAgICBwID0gcGxhY2VfcmV0KHApOwogCiAgICAgLyogQnVpbGQt
dGltZSBiZXN0IGVmZm9ydCBhdHRlbXB0IHRvIGNhdGNoIHByb2JsZW1zLiAq
LwogICAgIEJVSUxEX0JVR19PTihTVFVCX0JVRl9TSVpFIC8gMiA8CiAgICAg
ICAgICAgICAgICAgIChzaXplb2YocHJvbG9ndWUpICsgc2l6ZW9mKGVwaWxv
Z3VlKSArIDEwIC8qIDJ4IGNhbGwgKi8gKwotICAgICAgICAgICAgICAgICAg
TUFYKDMgLyogZGVmYXVsdCBzdHViICovLCBJT0VNVUxfUVVJUktfU1RVQl9C
WVRFUykpKTsKKyAgICAgICAgICAgICAgICAgIE1BWCgzIC8qIGRlZmF1bHQg
c3R1YiAqLywgSU9FTVVMX1FVSVJLX1NUVUJfQllURVMpICsKKyAgICAgICAg
ICAgICAgICAgIDEgLyogcmV0ICovKSk7CiAgICAgLyogUnVudGltZSBjb25m
aXJtYXRpb24gdGhhdCB3ZSBoYXZlbid0IGNsb2JiZXJlZCBhbiBhZGphY2Vu
dCBzdHViLiAqLwogICAgIEJVR19PTihTVFVCX0JVRl9TSVpFIC8gMiA8IChw
IC0gY3R4dC0+aW9fZW11bF9zdHViKSk7CiAKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni94ODZfZW11bGF0ZS9mcHUuYyBiL3hlbi9hcmNoL3g4Ni94ODZf
ZW11bGF0ZS9mcHUuYwppbmRleCA0ODBkODc5NjU3MDUuLjAzNjEyZDAwYTJj
ZSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL2ZwdS5j
CisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfZW11bGF0ZS9mcHUuYwpAQCAtMzIs
MzYgKzMyLDQyIEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBmcHVfY2hlY2tfd3Jp
dGUodm9pZCkKIAogI2RlZmluZSBlbXVsYXRlX2ZwdV9pbnNuX21lbWRzdChv
cGMsIGV4dCwgYXJnKSAgICAgICAgICAgICAgICAgICAgICAgICAgXAogZG8g
eyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIHZvaWQgKl9wID0gZ2V0
X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIC8qIE1vZFJNOiBtb2Q9MCwgcmVnPWV4dCwgcm09
MCwgaS5lLiBhICglcmF4KSBvcGVyYW5kICovICAgICAgICAgICAgXAogICAg
ICppbnNuX2J5dGVzID0gMjsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAotICAgIG1lbWNweShnZXRfc3R1
YihzdHViKSwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAoKHVpbnQ4X3RbXSl7IG9wYywgKChl
eHQpICYgNykgPDwgMywgMHhjMyB9KSwgMyk7ICAgICAgICAgICAgXAorICAg
IG1lbWNweShfcCwgKCh1aW50OF90W10peyBvcGMsICgoZXh0KSAmIDcpIDw8
IDMgfSksIDIpOyBfcCArPSAyOyAgICAgXAorICAgIHBsYWNlX3JldChfcCk7
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAoYXJn
KSA6ICJhIiAoJihhcmcpKSk7ICAgICAgICAgICAgICAgICAgICAgXAogICAg
IHB1dF9zdHViKHN0dWIpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogfSB3aGlsZSAoMCkKIAogI2Rl
ZmluZSBlbXVsYXRlX2ZwdV9pbnNuX21lbXNyYyhvcGMsIGV4dCwgYXJnKSAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogZG8geyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAorICAgIHZvaWQgKl9wID0gZ2V0X3N0dWIoc3R1Yik7ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
IC8qIE1vZFJNOiBtb2Q9MCwgcmVnPWV4dCwgcm09MCwgaS5lLiBhICglcmF4
KSBvcGVyYW5kICovICAgICAgICAgICAgXAotICAgIG1lbWNweShnZXRfc3R1
YihzdHViKSwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAoKHVpbnQ4X3RbXSl7IG9wYywgKChl
eHQpICYgNykgPDwgMywgMHhjMyB9KSwgMyk7ICAgICAgICAgICAgXAorICAg
IG1lbWNweShfcCwgKCh1aW50OF90W10peyBvcGMsICgoZXh0KSAmIDcpIDw8
IDMgfSksIDIpOyBfcCArPSAyOyAgICAgXAorICAgIHBsYWNlX3JldChfcCk7
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1tIiAoZHVt
bXkpIDogIm0iIChhcmcpLCAiYSIgKCYoYXJnKSkpOyAgICAgICAgXAogICAg
IHB1dF9zdHViKHN0dWIpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogfSB3aGlsZSAoMCkKIAogI2Rl
ZmluZSBlbXVsYXRlX2ZwdV9pbnNuX3N0dWIoYnl0ZXMuLi4pICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogZG8geyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAorICAgIHZvaWQgKl9wID0gZ2V0X3N0dWIoc3R1Yik7ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
IHVuc2lnbmVkIGludCBucl8gPSBzaXplb2YoKHVpbnQ4X3RbXSl7IGJ5dGVz
IH0pOyAgICAgICAgICAgICAgICAgICAgXAotICAgIG1lbWNweShnZXRfc3R1
YihzdHViKSwgKCh1aW50OF90W10peyBieXRlcywgMHhjMyB9KSwgbnJfICsg
MSk7ICAgICAgXAorICAgIG1lbWNweShfcCwgKCh1aW50OF90W10peyBieXRl
cyB9KSwgbnJfKTsgX3AgKz0gbnJfOyAgICAgICAgICAgICAgICAgXAorICAg
IHBsYWNlX3JldChfcCk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgIGludm9rZV9zdHViKCIi
LCAiIiwgIj1tIiAoZHVtbXkpIDogImkiICgwKSk7ICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIHB1dF9zdHViKHN0dWIpOyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogfSB3
aGlsZSAoMCkKIAogI2RlZmluZSBlbXVsYXRlX2ZwdV9pbnNuX3N0dWJfZWZs
YWdzKGJ5dGVzLi4uKSAgICAgICAgICAgICAgICAgICAgICAgICAgXAogZG8g
eyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgIHZvaWQgKl9wID0gZ2V0
X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgIHVuc2lnbmVkIGludCBucl8gPSBzaXplb2YoKHVp
bnQ4X3RbXSl7IGJ5dGVzIH0pOyAgICAgICAgICAgICAgICAgICAgXAogICAg
IHVuc2lnbmVkIGxvbmcgdG1wXzsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAotICAgIG1lbWNweShnZXRfc3R1
YihzdHViKSwgKCh1aW50OF90W10peyBieXRlcywgMHhjMyB9KSwgbnJfICsg
MSk7ICAgICAgXAorICAgIG1lbWNweShfcCwgKCh1aW50OF90W10peyBieXRl
cyB9KSwgbnJfKTsgX3AgKz0gbnJfOyAgICAgICAgICAgICAgICAgXAorICAg
IHBsYWNlX3JldChfcCk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgIGludm9rZV9zdHViKF9Q
UkVfRUZMQUdTKCJbZWZsYWdzXSIsICJbbWFza10iLCAiW3RtcF0iKSwgICAg
ICAgICAgICAgXAogICAgICAgICAgICAgICAgIF9QT1NUX0VGTEFHUygiW2Vm
bGFnc10iLCAiW21hc2tdIiwgIlt0bXBdIiksICAgICAgICAgICAgXAogICAg
ICAgICAgICAgICAgIFtlZmxhZ3NdICIrZyIgKHJlZ3MtPmVmbGFncyksIFt0
bXBdICI9JnIiICh0bXBfKSAgICAgICAgXApkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L3g4Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMgYi94ZW4vYXJjaC94
ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYwppbmRleCBiMWQxOTJjYmJm
MWUuLmY0MDcwOTY4MjQ4NCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4
Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMKKysrIGIveGVuL2FyY2gveDg2L3g4
Nl9lbXVsYXRlL3g4Nl9lbXVsYXRlLmMKQEAgLTEzOTYsNyArMTM5Niw3IEBA
IHg4Nl9lbXVsYXRlKAogICAgICAgICBzdGJbM10gPSAweDkxOwogICAgICAg
ICBzdGJbNF0gPSBldmV4Lm9wbXNrIDw8IDM7CiAgICAgICAgIGluc25fYnl0
ZXMgPSA1OwotICAgICAgICBzdGJbNV0gPSAweGMzOworICAgICAgICBwbGFj
ZV9yZXQoJnN0Yls1XSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIi
LCAiK20iIChvcF9tYXNrKSA6ICJhIiAoJm9wX21hc2spKTsKIApAQCAtMzYy
Nyw3ICszNjI3LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIH0KICAgICAg
ICAgb3BjWzFdID0gKG1vZHJtICYgMHgzOCkgfCAweGMwOwogICAgICAgICBp
bnNuX2J5dGVzID0gRVZFWF9QRlhfQllURVMgKyAyOwotICAgICAgICBvcGNb
Ml0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAg
ICAgICAgY29weV9FVkVYKG9wYywgZXZleCk7CiAgICAgICAgIGludm9rZV9z
dHViKCIiLCAiIiwgIj1nIiAoZHVtbXkpIDogImEiIChzcmMudmFsKSk7CkBA
IC0zNjk0LDcgKzM2OTQsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgICAg
IGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwogICAgICAgICAgICAgY29w
eV9SRVhfVkVYKG9wYywgcmV4X3ByZWZpeCwgdmV4KTsKICAgICAgICAgfQot
ICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9w
Y1syXSk7CiAKICAgICAgICAgZWEucmVnID0gZGVjb2RlX2dwcigmX3JlZ3Ms
IG1vZHJtX3JlZyk7CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1h
IiAoKmVhLnJlZykgOiAiYyIgKG1tdmFscCksICJtIiAoKm1tdmFscCkpOwpA
QCAtMzc2OCw3ICszNzY4LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAg
ICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMjsKICAgICAgICAgICAgIGNv
cHlfUkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIH0K
LSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbMl0pOwogCiAgICAgICAgIF9yZWdzLmVmbGFncyAmPSB+RUZMQUdTX01B
U0s7CiAgICAgICAgIGludm9rZV9zdHViKCIiLApAQCAtNDAwNCw3ICs0MDA0
LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIG9wY1sxXSA9IG1vZHJtICYg
MHhjNzsKICAgICAgICAgaW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDI7CiAg
ICAgc2ltZF8wZl90b19ncHI6Ci0gICAgICAgIG9wY1tpbnNuX2J5dGVzIC0g
UEZYX0JZVEVTXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjW2lu
c25fYnl0ZXMgLSBQRlhfQllURVNdKTsKIAogICAgICAgICBnZW5lcmF0ZV9l
eGNlcHRpb25faWYoZWEudHlwZSAhPSBPUF9SRUcsIFg4Nl9FWENfVUQpOwog
CkBAIC00NDAxLDcgKzQ0MDEsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAg
ICAgIHZleC53ID0gMDsKICAgICAgICAgb3BjWzFdID0gbW9kcm0gJiAweDM4
OwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMjsKLSAgICAg
ICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0p
OwogCiAgICAgICAgIGNvcHlfUkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZl
eCk7CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAoc3JjLnZh
bCkgOiAiYSIgKCZzcmMudmFsKSk7CkBAIC00NDM4LDcgKzQ0MzgsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgICAgIGV2ZXgudyA9IDA7CiAgICAgICAg
IG9wY1sxXSA9IG1vZHJtICYgMHgzODsKICAgICAgICAgaW5zbl9ieXRlcyA9
IEVWRVhfUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
RVZFWChvcGMsIGV2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIs
ICIrbSIgKHNyYy52YWwpIDogImEiICgmc3JjLnZhbCkpOwpAQCAtNDYzMyw3
ICs0NjMzLDcgQEAgeDg2X2VtdWxhdGUoCiAjZW5kaWYgLyogWDg2RU1VTF9O
T19TSU1EICovCiAKICAgICBzaW1kXzBmX3JlZ19vbmx5OgotICAgICAgICBv
cGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10gPSAweGMzOworICAgICAgICBw
bGFjZV9yZXQoJm9wY1tpbnNuX2J5dGVzIC0gUEZYX0JZVEVTXSk7CiAKICAg
ICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3ByZWZpeCwgdmV4KTsKICAg
ICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCBbZHVtbXlfb3V0XSAiPWciIChk
dW1teSkgOiBbZHVtbXlfaW5dICJpIiAoMCkgKTsKQEAgLTQ5NjcsNyArNDk2
Nyw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0
KCkgKQogICAgICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0g
PSBtb2RybSAmIDB4Zjg7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAg
ICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X1ZFWChv
cGMsIHZleCk7CiAgICAgICAgIGVhLnJlZyA9IGRlY29kZV9ncHIoJl9yZWdz
LCBtb2RybV9ybSk7CkBAIC01MDEwLDcgKzUwMTAsNyBAQCB4ODZfZW11bGF0
ZSgKICAgICAgICAgaWYgKCAhbW9kZV82NGJpdCgpICkKICAgICAgICAgICAg
IHZleC53ID0gMDsKICAgICAgICAgb3BjWzFdID0gbW9kcm0gJiAweGM3Owot
ICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9w
Y1syXSk7CiAKICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAgICAg
ICBpbnZva2Vfc3R1YigiIiwgIiIsICI9YSIgKGRzdC52YWwpIDogW2R1bW15
XSAiaSIgKDApKTsKQEAgLTUwNDAsNyArNTA0MCw3IEBAIHg4Nl9lbXVsYXRl
KAogICAgICAgICBvcGMgPSBpbml0X3ByZWZpeGVzKHN0dWIpOwogICAgICAg
ICBvcGNbMF0gPSBiOwogICAgICAgICBvcGNbMV0gPSBtb2RybTsKLSAgICAg
ICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0p
OwogCiAgICAgICAgIGNvcHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAgX3Jl
Z3MuZWZsYWdzICY9IH5FRkxBR1NfTUFTSzsKQEAgLTU2MDgsNyArNTYwOCw3
IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0KCkg
KQogICAgICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBt
b2RybSAmIDB4Yzc7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAg
IHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X1JFWF9WRVgo
b3BjLCByZXhfcHJlZml4LCB2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1Yigi
IiwgIiIsICI9YSIgKGVhLnZhbCkgOiBbZHVtbXldICJpIiAoMCkpOwpAQCAt
NTcyNiw3ICs1NzI2LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgICAgICBv
cGNbMV0gJj0gMHgzODsKICAgICAgICAgfQogICAgICAgICBpbnNuX2J5dGVz
ID0gUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogICAgICAgICBpZiAoIHZleC5v
cGN4ID09IHZleF9ub25lICkKICAgICAgICAgewogICAgICAgICAgICAgLyog
Q292ZXIgZm9yIGV4dHJhIHByZWZpeCBieXRlLiAqLwpAQCAtNjAwNiw3ICs2
MDA2LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHB2ZXgtPmIgPSAhbW9k
ZV82NGJpdCgpIHx8ICh2ZXgucmVnID4+IDMpOwogICAgICAgICBvcGNbMV0g
PSAweGMwIHwgKH52ZXgucmVnICYgNyk7CiAgICAgICAgIHB2ZXgtPnJlZyA9
IDB4ZjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2Vf
cmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwg
Ij1hIiAoZWEudmFsKSA6IFtkdW1teV0gImkiICgwKSk7CiAgICAgICAgIHB1
dF9zdHViKHN0dWIpOwpAQCAtNjI5MCw3ICs2MjkwLDcgQEAgeDg2X2VtdWxh
dGUoCiAgICAgICAgICAgICBldmV4LncgPSAwOwogICAgICAgICBvcGNbMV0g
PSBtb2RybSAmIDB4Zjg7CiAgICAgICAgIGluc25fYnl0ZXMgPSBFVkVYX1BG
WF9CWVRFUyArIDI7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAg
IHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X0VWRVgob3Bj
LCBldmV4KTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiPWciIChk
dW1teSkgOiAiYSIgKHNyYy52YWwpKTsKQEAgLTYzODksNyArNjM4OSw3IEBA
IHg4Nl9lbXVsYXRlKAogICAgICAgICBwdmV4LT5iID0gMTsKICAgICAgICAg
b3BjWzFdID0gKG1vZHJtX3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHB2ZXgt
PnJlZyA9IDB4ZjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAg
cGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIi
LCAiIiwgIj1tIiAoKm1tdmFscCkgOiAiYSIgKG1tdmFscCkpOwogCkBAIC02
NDU5LDcgKzY0NTksNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+
YiA9IDE7CiAgICAgICAgIG9wY1sxXSA9IChtb2RybV9yZWcgJiA3KSA8PCAz
OwogICAgICAgICBwdmV4LT5yZWcgPSAweGY7Ci0gICAgICAgIG9wY1syXSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAg
ICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKCptbXZhbHApIDogImEiICht
bXZhbHApKTsKIApAQCAtNjUxNSw3ICs2NTE1LDcgQEAgeDg2X2VtdWxhdGUo
CiAgICAgICAgIHBldmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1v
ZHJtX3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0g
ICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3Bj
WzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKCpt
bXZhbHApIDogImEiIChtbXZhbHApKTsKIApAQCAtNjU4MCw3ICs2NTgwLDcg
QEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHBldmV4LT5iID0gMTsKICAgICAg
ICAgb3BjWzFdID0gKG1vZHJtX3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHBl
dmV4LT5SWCA9IDE7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAg
IHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAgICBpbnZva2Vfc3R1Yigi
IiwgIiIsICIrbSIgKCptbXZhbHApIDogImEiIChtbXZhbHApKTsKIApAQCAt
NjU5NCw3ICs2NTk0LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIG9wY1sy
XSA9IDB4OTA7CiAgICAgICAgIC8qIFVzZSAoJXJheCkgYXMgc291cmNlLiAq
LwogICAgICAgICBvcGNbM10gPSBldmV4Lm9wbXNrIDw8IDM7Ci0gICAgICAg
IG9wY1s0XSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzRdKTsK
IAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICIrbSIgKG9wX21hc2sp
IDogImEiICgmb3BfbWFzaykpOwogICAgICAgICBwdXRfc3R1YihzdHViKTsK
QEAgLTY2ODgsNyArNjY4OCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBw
ZXZleC0+YiA9IDE7CiAgICAgICAgIG9wY1sxXSA9IChtb2RybV9yZWcgJiA3
KSA8PCAzOwogICAgICAgICBwZXZleC0+UlggPSAxOwotICAgICAgICBvcGNb
Ml0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAg
ICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiPW0iICgqbW12YWxwKSA6ICJh
IiAobW12YWxwKSk7CiAKQEAgLTY3NjYsNyArNjc2Niw3IEBAIHg4Nl9lbXVs
YXRlKAogICAgICAgICBvcGNbMl0gPSAweDkwOwogICAgICAgICAvKiBVc2Ug
KCVyYXgpIGFzIHNvdXJjZS4gKi8KICAgICAgICAgb3BjWzNdID0gZXZleC5v
cG1zayA8PCAzOwotICAgICAgICBvcGNbNF0gPSAweGMzOworICAgICAgICBw
bGFjZV9yZXQoJm9wY1s0XSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIoIiIs
ICIiLCAiK20iIChvcF9tYXNrKSA6ICJhIiAoJm9wX21hc2spKTsKICAgICAg
ICAgcHV0X3N0dWIoc3R1Yik7CkBAIC02ODQ4LDcgKzY4NDgsNyBAQCB4ODZf
ZW11bGF0ZSgKICAgICAgICAgcGV2ZXgtPnIgPSAhbW9kZV82NGJpdCgpIHx8
ICEoc3RhdGUtPnNpYl9pbmRleCAmIDB4MDgpOwogICAgICAgICBwZXZleC0+
UiA9ICFtb2RlXzY0Yml0KCkgfHwgIShzdGF0ZS0+c2liX2luZGV4ICYgMHgx
MCk7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0gICAgICAgIG9wY1syXSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJdKTsKIAogICAgICAg
ICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKGluZGV4KSA6ICJhIiAoJmlu
ZGV4KSk7CiAgICAgICAgIHB1dF9zdHViKHN0dWIpOwpAQCAtNzA1OCw3ICs3
MDU4LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHB2ZXgtPnJlZyA9IDB4
ZjsgLyogckFYICovCiAgICAgICAgIGJ1ZlszXSA9IGI7CiAgICAgICAgIGJ1
Zls0XSA9IDB4MDk7IC8qIHJlZz1yQ1ggci9tPSglckNYKSAqLwotICAgICAg
ICBidWZbNV0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls1XSk7
CiAKICAgICAgICAgc3JjLnJlZyA9IGRlY29kZV92ZXhfZ3ByKHZleC5yZWcs
ICZfcmVncywgY3R4dCk7CiAgICAgICAgIGVtdWxhdGVfc3R1YihbZHN0XSAi
PSZjIiAoZHN0LnZhbCksICJbZHN0XSIgKCZzcmMudmFsKSwgImEiICgqc3Jj
LnJlZykpOwpAQCAtNzA5NCw3ICs3MDk0LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIHB2ZXgtPnJlZyA9IDB4ZjsgLyogckFYICovCiAgICAgICAgIGJ1
ZlszXSA9IGI7CiAgICAgICAgIGJ1Zls0XSA9IChtb2RybSAmIDB4MzgpIHwg
MHgwMTsgLyogci9tPSglckNYKSAqLwotICAgICAgICBidWZbNV0gPSAweGMz
OworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls1XSk7CiAKICAgICAgICAgZHN0
LnJlZyA9IGRlY29kZV92ZXhfZ3ByKHZleC5yZWcsICZfcmVncywgY3R4dCk7
CiAgICAgICAgIGVtdWxhdGVfc3R1YigiPSZhIiAoZHN0LnZhbCksICJjIiAo
JnNyYy52YWwpKTsKQEAgLTczMzUsNyArNzMzNSw3IEBAIHg4Nl9lbXVsYXRl
KAogICAgICAgICAgICAgZXZleC53ID0gdmV4LncgPSAwOwogICAgICAgICBv
cGNbMV0gPSBtb2RybSAmIDB4Mzg7CiAgICAgICAgIG9wY1syXSA9IGltbTE7
Ci0gICAgICAgIG9wY1szXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgm
b3BjWzNdKTsKICAgICAgICAgaWYgKCB2ZXgub3BjeCA9PSB2ZXhfbm9uZSAp
CiAgICAgICAgIHsKICAgICAgICAgICAgIC8qIENvdmVyIGZvciBleHRyYSBw
cmVmaXggYnl0ZS4gKi8KQEAgLTc1MDIsNyArNzUwMiw3IEBAIHg4Nl9lbXVs
YXRlKAogICAgICAgICAgICAgaW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDM7
CiAgICAgICAgICAgICBjb3B5X1ZFWChvcGMsIHZleCk7CiAgICAgICAgIH0K
LSAgICAgICAgb3BjWzNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbM10pOwogCiAgICAgICAgIC8qIExhdGNoIE1YQ1NSIC0gd2UgbWF5IG5l
ZWQgdG8gcmVzdG9yZSBpdCBiZWxvdy4gKi8KICAgICAgICAgaW52b2tlX3N0
dWIoInN0bXhjc3IgJVtteGNzcl0iLCAiIiwKQEAgLTc3NDgsNyArNzc0OCw3
IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICB9CiAgICAgICAgIG9wY1syXSA9
IGltbTE7CiAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAzOwot
ICAgICAgICBvcGNbM10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9w
Y1szXSk7CiAgICAgICAgIGlmICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQog
ICAgICAgICB7CiAgICAgICAgICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJl
Zml4IGJ5dGUuICovCkBAIC04MDk0LDcgKzgwOTQsNyBAQCB4ODZfZW11bGF0
ZSgKICAgICAgICAgcHhvcC0+cmVnID0gMHhmOyAvKiByQVggKi8KICAgICAg
ICAgYnVmWzNdID0gYjsKICAgICAgICAgYnVmWzRdID0gKG1vZHJtICYgMHgz
OCkgfCAweDAxOyAvKiByL209KCVyQ1gpICovCi0gICAgICAgIGJ1Zls1XSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzVdKTsKIAogICAgICAg
ICBkc3QucmVnID0gZGVjb2RlX3ZleF9ncHIodmV4LnJlZywgJl9yZWdzLCBj
dHh0KTsKICAgICAgICAgZW11bGF0ZV9zdHViKFtkc3RdICI9JmEiIChkc3Qu
dmFsKSwgImMiICgmc3JjLnZhbCkpOwpAQCAtODIwMyw3ICs4MjAzLDcgQEAg
eDg2X2VtdWxhdGUoCiAgICAgICAgIGJ1ZlszXSA9IGI7CiAgICAgICAgIGJ1
Zls0XSA9IDB4MDk7IC8qIHJlZz1yQ1ggci9tPSglckNYKSAqLwogICAgICAg
ICAqKHVpbnQzMl90ICopKGJ1ZiArIDUpID0gaW1tMTsKLSAgICAgICAgYnVm
WzldID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZidWZbOV0pOwogCiAg
ICAgICAgIGVtdWxhdGVfc3R1YihbZHN0XSAiPSZjIiAoZHN0LnZhbCksICJb
ZHN0XSIgKCZzcmMudmFsKSk7CiAKQEAgLTgyOTMsMTIgKzgyOTMsMTIgQEAg
eDg2X2VtdWxhdGUoCiAgICAgICAgICAgICBCVUcoKTsKICAgICAgICAgaWYg
KCBldmV4X2VuY29kZWQoKSApCiAgICAgICAgIHsKLSAgICAgICAgICAgIG9w
Y1tpbnNuX2J5dGVzIC0gRVZFWF9QRlhfQllURVNdID0gMHhjMzsKKyAgICAg
ICAgICAgIHBsYWNlX3JldCgmb3BjW2luc25fYnl0ZXMgLSBFVkVYX1BGWF9C
WVRFU10pOwogICAgICAgICAgICAgY29weV9FVkVYKG9wYywgZXZleCk7CiAg
ICAgICAgIH0KICAgICAgICAgZWxzZQogICAgICAgICB7Ci0gICAgICAgICAg
ICBvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10gPSAweGMzOworICAgICAg
ICAgICAgcGxhY2VfcmV0KCZvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10p
OwogICAgICAgICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3ByZWZpeCwg
dmV4KTsKICAgICAgICAgfQogCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-06.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-06.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IEJ1aWxkIFhlbiB3aXRoIFJldHVybiBUaHVua3MKClRo
ZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uIHNwZWN1bGF0aXZlIHZ1bG5l
cmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRpcmVjdApicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QgaGFsZiBv
ZiBhIGNhY2hlbGluZS4KCkluIG9yZGVyIHRvIG1pdGlnYXRlIHRoaXMsIGJ1
aWxkIHdpdGggcmV0dXJuIHRodW5rcyBhbmQgYXJyYW5nZSBmb3IKX194ODZf
cmV0dXJuX3RodW5rIHRvIGJlIChtaXMpYWxpZ25lZCBpbiB0aGUgc2FtZSBt
YW5uZXIgYXMKX194ODZfaW5kaXJlY3RfdGh1bmtfKiBzbyB0aGUgUkVUIGlu
c3RydWN0aW9uIGlzIHBsYWNlZCBpbiBhIHNhZmUgbG9jYXRpb24uCgpwbGFj
ZV9yZXQoKSBuZWVkcyB0byBjb25kaXRpb25hbGx5IGVtaXQgSk1QIF9feDg2
X3JldHVybl90aHVuayBpbnN0ZWFkIG9mIFJFVC4KClRoaXMgaXMgcGFydCBv
ZiBYU0EtNDY5IC8gQ1ZFLTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnIGIveGVu
L2FyY2gveDg2L0tjb25maWcKaW5kZXggN2UwM2U0YmM1NTQ2Li40NTQyZWE4
NDA4YzcgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnCisrKyBi
L3hlbi9hcmNoL3g4Ni9LY29uZmlnCkBAIC0zNyw5ICszNywxNCBAQCBjb25m
aWcgQVJDSF9ERUZDT05GSUcKIAlkZWZhdWx0ICJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCiAKIGNvbmZpZyBDQ19IQVNfSU5ESVJFQ1Rf
VEhVTksKKwkjIEdDQyA+PSA4IG9yIENsYW5nID49IDYKIAlkZWZfYm9vbCAk
KGNjLW9wdGlvbiwtbWluZGlyZWN0LWJyYW5jaC1yZWdpc3RlcikgfHwgXAog
CSAgICAgICAgICQoY2Mtb3B0aW9uLC1tcmV0cG9saW5lLWV4dGVybmFsLXRo
dW5rKQogCitjb25maWcgQ0NfSEFTX1JFVFVSTl9USFVOSworCSMgR0NDID49
IDggb3IgQ2xhbmcgPj0gMTUKKwlkZWZfYm9vbCAkKGNjLW9wdGlvbiwtbWZ1
bmN0aW9uLXJldHVybj10aHVuay1leHRlcm4pCisKIGNvbmZpZyBIQVNfQVNf
Q0VUX1NTCiAJIyBiaW51dGlscyA+PSAyLjI5IG9yIExMVk0gPj0gNgogCWRl
Zl9ib29sICQoYXMtaW5zdHIsd3Jzc3EgJXJheCQoY29tbWEpMDtzZXRzc2Jz
eSkKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hlbi9h
cmNoL3g4Ni9NYWtlZmlsZQppbmRleCBhN2U1YTgyNjg5ZGUuLjI3ODA2YTgx
YWNhOCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisrKyBi
L3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtNDMsNiArNDMsNyBAQCBvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KK29iai0kKENPTkZJR19SRVRV
Uk5fVEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KIG9iai0kKENPTkZJR19Q
VikgKz0gaW9wb3J0X2VtdWxhdGUubwogb2JqLXkgKz0gaXJxLm8KIG9iai0k
KENPTkZJR19LRVhFQykgKz0gbWFjaGluZV9rZXhlYy5vCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJvdC5TIGIveGVuL2FyY2gv
eDg2L2FjcGkvd2FrZXVwX3Byb3QuUwppbmRleCA2NmY3OTkzMzk5MTMuLjk3
YmQ2NzZhYWVlMiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvd2Fr
ZXVwX3Byb3QuUworKysgYi94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJv
dC5TCkBAIC0xMzMsNyArMTMzLDcgQEAgRU5UUlkoczNfcmVzdW1lKQogICAg
ICAgICBwb3AgICAgICVyMTIKICAgICAgICAgcG9wICAgICAlcmJ4CiAgICAg
ICAgIHBvcCAgICAgJXJicAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAK
IC5kYXRhCiAgICAgICAgIC5hbGlnbiAxNgpkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94ODYvYWx0ZXJuYXRp
dmUuYwppbmRleCBlYzQ1MWQ5NjJjMTAuLjFiNzFhZTk1OWFiZSAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKKysrIGIveGVuL2Fy
Y2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTEzNywxNiArMTM3LDQ1IEBAIHZv
aWQgaW5pdF9vcl9saXZlcGF0Y2ggYWRkX25vcHModm9pZCAqaW5zbnMsIHVu
c2lnbmVkIGludCBsZW4pCiAgICAgfQogfQogCit2b2lkIG5vY2FsbCBfX3g4
Nl9yZXR1cm5fdGh1bmsodm9pZCk7CisKIC8qCiAgKiBQbGFjZSBhIHJldHVy
biBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGluIHRoZSB3cml0YWJsZSBhbGlh
cyBvZiBhIHN0dWIuCiAgKgorICogV2hlbiBDT05GSUdfUkVUVVJOX1RIVU5L
IGlzIGFjdGl2ZSwgdGhpcyBtYXkgYmUgYSBKTVAgX194ODZfcmV0dXJuX3Ro
dW5rCisgKiBpbnN0ZWFkLCBkZXBlbmRpbmcgb24gdGhlIHNhZmV0eSBvZiBA
cHRyIHdpdGggcmVzcGVjdCB0byBJbmRpcmVjdCBUYXJnZXQKKyAqIFNlbGVj
dGlvbi4KKyAqCiAgKiBSZXR1cm5zIHRoZSBuZXh0IHBvc2l0aW9uIHRvIHdy
aXRlIGludG8gdGhlIHN0dWIuCiAgKi8KIHZvaWQgKnBsYWNlX3JldCh2b2lk
ICpwdHIpCiB7CisgICAgdW5zaWduZWQgbG9uZyBhZGRyID0gKHVuc2lnbmVk
IGxvbmcpcHRyOwogICAgIHVpbnQ4X3QgKnAgPSBwdHI7CiAKLSAgICAqcCsr
ID0gMHhjMzsKKyAgICAvKgorICAgICAqIFdoZW4gUmV0dXJuIFRodW5rcyBh
cmUgdXNlZCwgaWYgYSBSRVQgd291bGQgYmUgdW5zYWZlIGF0IHRoaXMgbG9j
YXRpb24KKyAgICAgKiB3aXRoIHJlc3BlY3QgdG8gSW5kaXJlY3QgVGFyZ2V0
IFNlbGVjdGlvbiAoaS5lLiBpZiBhZGRyIGlzIGluIHRoZSBmaXJzdAorICAg
ICAqIGhhbGYgb2YgYSBjYWNoZWxpbmUpLCBpbnNlcnQgYSBKTVAgX194ODZf
cmV0dXJuX3RodW5rIGluc3RlYWQuCisgICAgICoKKyAgICAgKiBUaGUgZGlz
cGxhY2VtZW50IG5lZWRzIHRvIGJlIHJlbGF0aXZlIHRvIHRoZSBleGVjdXRh
YmxlIGFsaWFzIG9mIHRoZQorICAgICAqIHN0dWIsIG5vdCB0byBAcHRyIHdo
aWNoIGlzIHRoZSB3cml0ZWFibGUgYWxpYXMuCisgICAgICovCisgICAgaWYg
KCBJU19FTkFCTEVEKENPTkZJR19SRVRVUk5fVEhVTkspICYmICEoYWRkciAm
IDB4MjApICkKKyAgICB7CisgICAgICAgIGxvbmcgc3R1Yl92YSA9ICh0aGlz
X2NwdShzdHVicy5hZGRyKSAmIFBBR0VfTUFTSykgKyAoYWRkciAmIH5QQUdF
X01BU0spOworICAgICAgICBsb25nIGRpc3AgPSAobG9uZylfX3g4Nl9yZXR1
cm5fdGh1bmsgLSAoc3R1Yl92YSArIDUpOworCisgICAgICAgIEJVR19PTigo
aW50MzJfdClkaXNwICE9IGRpc3ApOworCisgICAgICAgICpwKysgPSAweGU5
OworICAgICAgICAqKGludDMyX3QgKilwID0gZGlzcDsKKyAgICAgICAgcCAr
PSA0OworICAgIH0KKyAgICBlbHNlCisgICAgeworICAgICAgICAqcCsrID0g
MHhjMzsKKyAgICB9CiAKICAgICByZXR1cm4gcDsKIH0KZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rIGIveGVuL2FyY2gveDg2L2FyY2gubWsK
aW5kZXggYjg4ZDA5N2E4NDRiLi44NWQzZTdjYmZlZWIgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9hcmNoLm1rCisrKyBiL3hlbi9hcmNoL3g4Ni9hcmNo
Lm1rCkBAIC00Niw2ICs0Niw5IEBAIENGTEFHUy0kKENPTkZJR19DQ19JU19H
Q0MpICs9IC1mbm8tanVtcC10YWJsZXMKIENGTEFHUy0kKENPTkZJR19DQ19J
U19DTEFORykgKz0gLW1yZXRwb2xpbmUtZXh0ZXJuYWwtdGh1bmsKIGVuZGlm
CiAKKyMgQ29tcGlsZSB3aXRoIHJldHVybiB0aHVuayBzdXBwb3J0IGlmIHNl
bGVjdGVkLgorQ0ZMQUdTLSQoQ09ORklHX1JFVFVSTl9USFVOSykgKz0gLW1m
dW5jdGlvbi1yZXR1cm49dGh1bmstZXh0ZXJuCisKICMgRGlzYWJsZSB0aGUg
YWRkaXRpb24gb2YgYSAubm90ZS5nbnUucHJvcGVydHkgc2VjdGlvbiB0byBv
YmplY3QgZmlsZXMgd2hlbgogIyBsaXZlcGF0Y2ggc3VwcG9ydCBpcyBlbmFi
bGVkLiAgVGhlIGNvbnRlbnRzIG9mIHRoYXQgc2VjdGlvbiBjYW4gY2hhbmdl
CiAjIGRlcGVuZGluZyBvbiB0aGUgaW5zdHJ1Y3Rpb25zIHVzZWQsIGFuZCBs
aXZlcGF0Y2gtYnVpbGQtdG9vbHMgZG9lc24ndCBrbm93CmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYmhiLXRodW5rLlMgYi94ZW4vYXJjaC94ODYvYmhi
LXRodW5rLlMKaW5kZXggNTI2MjVmNGUyYzE3Li43ZjkyMjAxYTNjYmIgMTAw
NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUworKysgYi94ZW4v
YXJjaC94ODYvYmhiLXRodW5rLlMKQEAgLTIzLDcgKzIzLDcgQEAgRlVOQyhj
bGVhcl9iaGJfdHN4KQogMDogICAgICAuYnl0ZSAweGM2LCAweGY4LCAwICAg
ICAgICAgICAgIC8qIHhhYm9ydCAkMCAqLwogICAgICAgICBpbnQzCiAxOgot
ICAgICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQoY2xlYXJfYmhiX3RzeCkK
IAogLyoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jbGVhcl9wYWdlLlMg
Yi94ZW4vYXJjaC94ODYvY2xlYXJfcGFnZS5TCmluZGV4IGQ2YzA3NmYxZDhi
Yy4uZGMzYzNjMjZiZmI3IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvY2xl
YXJfcGFnZS5TCisrKyBiL3hlbi9hcmNoL3g4Ni9jbGVhcl9wYWdlLlMKQEAg
LTEsNiArMSw4IEBACiAgICAgICAgIC5maWxlIF9fRklMRV9fCiAKICNpbmNs
dWRlIDx4ZW4vbGlua2FnZS5oPgorCisjaW5jbHVkZSA8YXNtL2FzbV9kZWZu
cy5oPgogI2luY2x1ZGUgPGFzbS9wYWdlLmg+CiAKIEZVTkMoY2xlYXJfcGFn
ZV9zc2UyKQpAQCAtMTYsNSArMTgsNSBAQCBGVU5DKGNsZWFyX3BhZ2Vfc3Nl
MikKICAgICAgICAgam56ICAgICAwYgogCiAgICAgICAgIHNmZW5jZQotICAg
ICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQoY2xlYXJfcGFnZV9zc2UyKQpk
aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2NvcHlfcGFnZS5TIGIveGVuL2Fy
Y2gveDg2L2NvcHlfcGFnZS5TCmluZGV4IGMzYzQzNjU0NWJhYy4uZTQzZTUz
NzBjODE1IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvY29weV9wYWdlLlMK
KysrIGIveGVuL2FyY2gveDg2L2NvcHlfcGFnZS5TCkBAIC0xLDYgKzEsOCBA
QAogICAgICAgICAuZmlsZSBfX0ZJTEVfXwogCiAjaW5jbHVkZSA8eGVuL2xp
bmthZ2UuaD4KKworI2luY2x1ZGUgPGFzbS9hc21fZGVmbnMuaD4KICNpbmNs
dWRlIDxhc20vcGFnZS5oPgogCiAjZGVmaW5lIHNyY19yZWcgJXJzaQpAQCAt
NDEsNSArNDMsNSBAQCBGVU5DKGNvcHlfcGFnZV9zc2UyKQogICAgICAgICBt
b3ZudGkgIHRtcDRfcmVnLCAzKldPUkRfU0laRShkc3RfcmVnKQogCiAgICAg
ICAgIHNmZW5jZQotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQoY29w
eV9wYWdlX3NzZTIpCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvZWZpL2No
ZWNrLmMgYi94ZW4vYXJjaC94ODYvZWZpL2NoZWNrLmMKaW5kZXggOWU0NzNm
YWFkM2M5Li4yM2JhMzBhYmYzMzAgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9lZmkvY2hlY2suYworKysgYi94ZW4vYXJjaC94ODYvZWZpL2NoZWNrLmMK
QEAgLTMsNiArMyw5IEBAIGludCBfX2F0dHJpYnV0ZV9fKChfX21zX2FiaV9f
KSkgdGVzdChpbnQgaSkKICAgICByZXR1cm4gaTsKIH0KIAorLyogSW4gY2Fz
ZSAtbWZ1bmN0aW9uLXJldHVybiBpcyBpbiB1c2UuICovCit2b2lkIF9feDg2
X3JldHVybl90aHVuayh2b2lkKSB7fTsKKwogLyoKICAqIFBvcHVsYXRlIGFu
IGFycmF5IHdpdGggImFkZHJlc3NlcyIgb2YgcmVsb2NhdGFibGUgYW5kIGFi
c29sdXRlIHZhbHVlcy4KICAqIFRoaXMgaXMgdG8gcHJvYmUgbGQgZm9yIChh
KSBlbWl0dGluZyBiYXNlIHJlbG9jYXRpb25zIGF0IGFsbCBhbmQgKGIpIG5v
dApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1k
ZWZucy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1kZWZucy5o
CmluZGV4IDMyZDZiNDQ5MTA2My4uOTdlYmUyMTI5OGEyIDEwMDY0NAotLS0g
YS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYXNtLWRlZm5zLmgKKysrIGIv
eGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1kZWZucy5oCkBAIC01OCw2
ICs1OCwxMiBAQAogICAgIC5lbmRpZgogLmVuZG0KIAorI2lmZGVmIENPTkZJ
R19SRVRVUk5fVEhVTksKKyMgZGVmaW5lIFJFVCBqbXAgX194ODZfcmV0dXJu
X3RodW5rCisjZWxzZQorIyBkZWZpbmUgUkVUIHJldAorI2VuZGlmCisKICNp
ZmRlZiBDT05GSUdfWEVOX0lCVAogIyBkZWZpbmUgRU5EQlI2NCBlbmRicjY0
CiAjZWxzZQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luZGlyZWN0LXRo
dW5rLlMgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwppbmRleCBj
NGI5NzhkNjdiOGUuLjI2ZGFkMTVmMTJjOSAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2luZGlyZWN0LXRodW5rLlMKKysrIGIveGVuL2FyY2gveDg2L2lu
ZGlyZWN0LXRodW5rLlMKQEAgLTE1LDYgKzE1LDggQEAKICN1bmRlZiBTWU1f
QUxJR04KICNkZWZpbmUgU1lNX0FMSUdOKGFsaWduLi4uKQogCisjaWZkZWYg
Q09ORklHX0lORElSRUNUX1RIVU5LCisKIC5tYWNybyBJTkRfVEhVTktfUkVU
UE9MSU5FIHJlZzpyZXEKICAgICAgICAgY2FsbCAxZgogICAgICAgICBpbnQz
CkBAIC02MiwzICs2NCwyNSBAQCBFTkQoX194ODZfaW5kaXJlY3RfdGh1bmtf
XHJlZykKIC5pcnAgcmVnLCBheCwgY3gsIGR4LCBieCwgYnAsIHNpLCBkaSwg
OCwgOSwgMTAsIDExLCAxMiwgMTMsIDE0LCAxNQogICAgICAgICBHRU5fSU5E
SVJFQ1RfVEhVTksgcmVnPXJccmVnCiAuZW5kcgorCisjZW5kaWYgLyogQ09O
RklHX0lORElSRUNUX1RIVU5LICovCisKKyNpZmRlZiBDT05GSUdfUkVUVVJO
X1RIVU5LCisgICAgICAgIC5zZWN0aW9uIC50ZXh0LmVudHJ5Ll9feDg2X3Jl
dHVybl90aHVuaywgImF4IiwgQHByb2diaXRzCisKKyAgICAgICAgLyoKKyAg
ICAgICAgICogVGhlIEluZGlyZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3Vs
YXRpdmUgdnVsbmVyYWJpbGl0eSBtZWFucyB0aGF0CisgICAgICAgICAqIGlu
ZGlyZWN0IGJyYW5jaGVzIChpbmNsdWRpbmcgUkVUcykgYXJlIHVuc2FmZSB3
aGVuIGluIHRoZSBmaXJzdAorICAgICAgICAgKiBoYWxmIG9mIGEgY2FjaGVs
aW5lLiAgQXJyYW5nZSBmb3IgdGhlbSB0byBiZSBpbiB0aGUgc2Vjb25kIGhh
bGYuCisgICAgICAgICAqCisgICAgICAgICAqIEFsaWduIHRvIDY0LCB0aGVu
IHNraXAgMzIuCisgICAgICAgICAqLworICAgICAgICAuYmFsaWduIDY0Cisg
ICAgICAgIC5maWxsIDMyLCAxLCAweGNjCisKK0ZVTkMoX194ODZfcmV0dXJu
X3RodW5rKQorICAgICAgICByZXQKKyAgICAgICAgaW50MyAvKiBIYWx0IHN0
cmFpZ2h0LWxpbmUgc3BlY3VsYXRpb24gKi8KK0VORChfX3g4Nl9yZXR1cm5f
dGh1bmspCisKKyNlbmRpZiAvKiBDT05GSUdfUkVUVVJOX1RIVU5LICovCmRp
ZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMgYi94
ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMKaW5kZXggZmY1ZDFjOWY4
NjM0Li4yOTVkODQ3ZWEyNGMgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9w
di9lbXVsLXByaXYtb3AuYworKysgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1w
cml2LW9wLmMKQEAgLTEzMSw3ICsxMzEsNyBAQCBzdGF0aWMgaW9fZW11bF9z
dHViX3QgKmlvX2VtdWxfc3R1Yl9zZXR1cChzdHJ1Y3QgcHJpdl9vcF9jdHh0
ICpjdHh0LCB1OCBvcGNvZGUsCiAgICAgQlVJTERfQlVHX09OKFNUVUJfQlVG
X1NJWkUgLyAyIDwKICAgICAgICAgICAgICAgICAgKHNpemVvZihwcm9sb2d1
ZSkgKyBzaXplb2YoZXBpbG9ndWUpICsgMTAgLyogMnggY2FsbCAqLyArCiAg
ICAgICAgICAgICAgICAgICBNQVgoMyAvKiBkZWZhdWx0IHN0dWIgKi8sIElP
RU1VTF9RVUlSS19TVFVCX0JZVEVTKSArCi0gICAgICAgICAgICAgICAgICAx
IC8qIHJldCAqLykpOworICAgICAgICAgICAgICAgICAgKElTX0VOQUJMRUQo
Q09ORklHX1JFVFVSTl9USFVOSykgPyA1IDogMSkgLyogcmV0ICovKSk7CiAg
ICAgLyogUnVudGltZSBjb25maXJtYXRpb24gdGhhdCB3ZSBoYXZlbid0IGNs
b2JiZXJlZCBhbiBhZGphY2VudCBzdHViLiAqLwogICAgIEJVR19PTihTVFVC
X0JVRl9TSVpFIC8gMiA8IChwIC0gY3R4dC0+aW9fZW11bF9zdHViKSk7CiAK
ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9wdi9ncHJfc3dpdGNoLlMgYi94
ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5TCmluZGV4IDU0MDlhZDNiMTQ0
Ny4uMzYyYjVkMjQxNjIzIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvcHYv
Z3ByX3N3aXRjaC5TCisrKyBiL3hlbi9hcmNoL3g4Ni9wdi9ncHJfc3dpdGNo
LlMKQEAgLTI2LDcgKzI2LDcgQEAgRlVOQyhsb2FkX2d1ZXN0X2dwcnMpCiAg
ICAgICAgIG1vdnEgIFVSRUdTX3IxNSglcmRpKSwgJXIxNQogICAgICAgICBt
b3ZxICBVUkVHU19yY3goJXJkaSksICVyY3gKICAgICAgICAgbW92cSAgVVJF
R1NfcmRpKCVyZGkpLCAlcmRpCi0gICAgICAgIHJldAorICAgICAgICBSRVQK
IEVORChsb2FkX2d1ZXN0X2dwcnMpCiAKIC8qIFNhdmUgZ3Vlc3QgR1BScy4g
IFBhcmFtZXRlciBvbiB0aGUgc3RhY2sgYWJvdmUgdGhlIHJldHVybiBhZGRy
ZXNzLiAqLwpAQCAtNDgsNSArNDgsNSBAQCBGVU5DKHNhdmVfZ3Vlc3RfZ3By
cykKICAgICAgICAgbW92cSAgJXJieCwgVVJFR1NfcmJ4KCVyZGkpCiAgICAg
ICAgIG1vdnEgICVyZHgsIFVSRUdTX3JkeCglcmRpKQogICAgICAgICBtb3Zx
ICAlcmN4LCBVUkVHU19yY3goJXJkaSkKLSAgICAgICAgcmV0CisgICAgICAg
IFJFVAogRU5EKHNhdmVfZ3Vlc3RfZ3BycykKZGlmZiAtLWdpdCBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu
YwppbmRleCAzNTM1MTA0NGY5MDEuLjAxOWEwYTgxZjRhNyAxMDA2NDQKLS0t
IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCisrKyBiL3hlbi9hcmNoL3g4
Ni9zcGVjX2N0cmwuYwpAQCAtNTY5LDYgKzU2OSw5IEBAIHN0YXRpYyB2b2lk
IF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rKQog
I2lmZGVmIENPTkZJR19JTkRJUkVDVF9USFVOSwogICAgICAgICAgICAgICAg
IiBJTkRJUkVDVF9USFVOSyIKICNlbmRpZgorI2lmZGVmIENPTkZJR19SRVRV
Uk5fVEhVTksKKyAgICAgICAgICAgICAgICIgUkVUVVJOX1RIVU5LIgorI2Vu
ZGlmCiAjaWZkZWYgQ09ORklHX1NIQURPV19QQUdJTkcKICAgICAgICAgICAg
ICAgICIgU0hBRE9XX1BBR0lORyIKICNlbmRpZgpkaWZmIC0tZ2l0IGEveGVu
L2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUyBiL3hlbi9hcmNoL3g4
Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKaW5kZXggYTk5NjQ2YzBjZDRlLi4x
OGY0NmM3OGNmYmUgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQv
Y29tcGF0L2VudHJ5LlMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl82NC9jb21w
YXQvZW50cnkuUwpAQCAtMTgwLDcgKzE4MCw3IEBAIEZVTkMoY3I0X3B2MzJf
cmVzdG9yZSkKICAgICAgICAgb3IgICAgY3I0X3B2MzJfbWFzayglcmlwKSwg
JXJheAogICAgICAgICBtb3YgICAlcmF4LCAlY3I0CiAgICAgICAgIG1vdiAg
ICVyYXgsICglcmN4KQotICAgICAgICByZXQKKyAgICAgICAgUkVUCiAwOgog
I2lmbmRlZiBOREVCVUcKICAgICAgICAgLyogQ2hlY2sgdGhhdCBfYWxsXyBv
ZiB0aGUgYml0cyBpbnRlbmRlZCB0byBiZSBzZXQgYWN0dWFsbHkgYXJlLiAq
LwpAQCAtMTk4LDcgKzE5OCw3IEBAIEZVTkMoY3I0X3B2MzJfcmVzdG9yZSkK
IDE6CiAjZW5kaWYKICAgICAgICAgeG9yICAgJWVheCwgJWVheAotICAgICAg
ICByZXQKKyAgICAgICAgUkVUCiBFTkQoY3I0X3B2MzJfcmVzdG9yZSkKIAog
RlVOQyhjb21wYXRfc3lzY2FsbCkKQEAgLTMyOSw3ICszMjksNyBAQCBfX1VO
TElLRUxZX0VORChjb21wYXRfYm91bmNlX251bGxfc2VsZWN0b3IpCiAgICAg
ICAgIHhvciAgICVlYXgsICVlYXgKICAgICAgICAgbW92ICAgJWF4LCAgVFJB
UEJPVU5DRV9jcyglcmR4KQogICAgICAgICBtb3YgICAlYWwsICBUUkFQQk9V
TkNFX2ZsYWdzKCVyZHgpCi0gICAgICAgIHJldAorICAgICAgICBSRVQKIAog
LnNlY3Rpb24gLmZpeHVwLCJheCIKIC5MZngxMzoKZGlmZiAtLWdpdCBhL3hl
bi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUyBiL3hlbi9hcmNoL3g4Ni94ODZf
NjQvZW50cnkuUwppbmRleCA5YjBjZGI3NjQwOGIuLmViNjJlN2MzMjliZCAx
MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82NC9lbnRyeS5TCisrKyBi
L3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwpAQCAtNjA0LDcgKzYwNCw3
IEBAIF9fVU5MSUtFTFlfRU5EKGNyZWF0ZV9ib3VuY2VfZnJhbWVfYmFkX2Jv
dW5jZV9pcCkKICAgICAgICAgeG9yICAgJWVheCwgJWVheAogICAgICAgICBt
b3YgICAlcmF4LCBUUkFQQk9VTkNFX2VpcCglcmR4KQogICAgICAgICBtb3Yg
ICAlYWwsICBUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCi0gICAgICAgIHJldAor
ICAgICAgICBSRVQKIAogICAgICAgICAucHVzaHNlY3Rpb24gLmZpeHVwLCAi
YXgiLCBAcHJvZ2JpdHMKICAgICAgICAgIyBOdW1lcmljIHRhZ3MgYmVsb3cg
cmVwcmVzZW50IHRoZSBpbnRlbmRlZCBvdmVyYWxsICVyc2kgYWRqdXN0bWVu
dC4KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMgYi94ZW4v
YXJjaC94ODYveGVuLmxkcy5TCmluZGV4IDlhMWRmZTFiMzQwYS4uNTA2OTkz
ODY3NTAyIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYveGVuLmxkcy5TCisr
KyBiL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMKQEAgLTgyLDYgKzgyLDcgQEAg
U0VDVElPTlMKICAgICAgICAuID0gQUxJR04oUEFHRV9TSVpFKTsKICAgICAg
ICBfc3RleHRlbnRyeSA9IC47CiAgICAgICAgKigudGV4dC5lbnRyeSkKKyAg
ICAgICAqKC50ZXh0LmVudHJ5LiopCiAgICAgICAgLiA9IEFMSUdOKFBBR0Vf
U0laRSk7CiAgICAgICAgX2V0ZXh0ZW50cnkgPSAuOwogCmRpZmYgLS1naXQg
YS94ZW4vY29tbW9uL0tjb25maWcgYi94ZW4vY29tbW9uL0tjb25maWcKaW5k
ZXggNTY1Y2VkYTc0MWI5Li5kYTBmYTc1Mjc2NDMgMTAwNjQ0Ci0tLSBhL3hl
bi9jb21tb24vS2NvbmZpZworKysgYi94ZW4vY29tbW9uL0tjb25maWcKQEAg
LTEzMCw2ICsxMzAsMTcgQEAgY29uZmlnIElORElSRUNUX1RIVU5LCiAJICBX
aGVuIGVuYWJsZWQsIGluZGlyZWN0IGJyYW5jaGVzIGFyZSBpbXBsZW1lbnRl
ZCB1c2luZyBhIG5ldyBjb25zdHJ1Y3QKIAkgIGNhbGxlZCAicmV0cG9saW5l
IiB0aGF0IHByZXZlbnRzIHNwZWN1bGF0aW9uLgogCitjb25maWcgUkVUVVJO
X1RIVU5LCisJYm9vbCAiT3V0LW9mLWxpbmUgUmV0dXJucyIKKwlkZXBlbmRz
IG9uIENDX0hBU19SRVRVUk5fVEhVTksKKwlkZWZhdWx0IElORElSRUNUX1RI
VU5LCisJaGVscAorCSAgQ29tcGlsZSBYZW4gd2l0aCBvdXQtb2YtbGluZSBy
ZXR1cm5zLgorCisJICBUaGlzIGFsbG93cyBYZW4gdG8gbWl0aWdhdGUgYSB2
YXJpZXR5IG9mIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdGllcworCSAgYnkg
Y2hvb3NpbmcgYSBoYXJkd2FyZS1kZXBlbmRlbnQgaW5zdHJ1Y3Rpb24gc2Vx
dWVuY2UgdG8gaW1wbGVtZW50CisJICBmdW5jdGlvbiByZXR1cm5zIHNhZmVs
eS4KKwogY29uZmlnIFNQRUNVTEFUSVZFX0hBUkRFTl9BUlJBWQogCWJvb2wg
IlNwZWN1bGF0aXZlIEFycmF5IEhhcmRlbmluZyIKIAlkZWZhdWx0IHkK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.19-07.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.19-07.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogU3ludGhlc2lzZSBJVFNfTk8g
dG8gZ3Vlc3RzIG9uIHVuYWZmZWN0ZWQgaGFyZHdhcmUKCkl0IGlzIGVhc2ll
ciB0byBleHByZXNzIGZlYXR1cmUgd29yZCAxNyBpbiB0ZXJtcyBvZiB3b3Jk
IDE2ICsgWzMyLCA2NCkgYXMKdGhhdCdzIGhvdyB0aGUgbGF5b3V0IGlzIGdp
dmVuIGluIGRvY3VtZW50YXRpb24uCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2
OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29v
cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKaW5k
ZXggOWJjNTUzNjgxZjRhLi4xNzI5YmEwYzMwOTcgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKKysrIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaApAQCAtMjE2LDYg
KzIxNiw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBib290X2NwdV9oYXModW5z
aWduZWQgaW50IGZlYXQpCiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAgICAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCiAjZGVmaW5l
IGNwdV9oYXNfcmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9SRkRTX05PKQogI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIgICAg
ICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKKyNkZWZp
bmUgY3B1X2hhc19pdHNfbm8gICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX0lUU19OTykKIAogLyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5l
IGNwdV9oYXNfYXJjaF9wZXJmbW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9BUkNIX1BFUkZNT04pCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg
MDE5YTBhODFmNGE3Li45NGNkYmQ1MjFjNGQgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMKQEAgLTE3ODEsNiArMTc4MSw5MCBAQCBzdGF0aWMgdm9pZCBfX2lu
aXQgYmhpX2NhbGN1bGF0aW9ucyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAq
IGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZl
bG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1
aWRhbmNlL2Fkdmlzb3J5LWd1aWRhbmNlL2luZGlyZWN0LXRhcmdldC1zZWxl
Y3Rpb24uaHRtbAorICovCitzdGF0aWMgdm9pZCBfX2luaXQgaXRzX2NhbGN1
bGF0aW9ucyh2b2lkKQoreworICAgIC8qCisgICAgICogSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBpcyBhIEJyYW5jaCBQcmVkaWN0aW9uIGJ1ZyB3aGVy
ZWJ5IGNlcnRhaW4KKyAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGdldCBwcmVkaWN0ZWQgdXNpbmcgYSBkaXJlY3QgYnJhbmNo
CisgICAgICogdGFyZ2V0LCByYXRoZXIgdGhhbiBhIHN1aXRhYmxlIGluZGly
ZWN0IHRhcmdldCwgYnlwYXNzaW5nIGhhcmR3YXJlCisgICAgICogaXNvbGF0
aW9uIHByb3RlY3Rpb25zLgorICAgICAqCisgICAgICogSVRTIGFmZmVjdHMg
Q29yZSAoYnV0IG5vdCBBdG9tKSBwcm9jZXNzb3JzIHN0YXJ0aW5nIGZyb20g
dGhlCisgICAgICogaW50cm9kdWN0aW9uIG9mIGVJQlJTLCB1cCB0byBidXQg
bm90IGluY2x1ZGluZyBHb2xkZW4gQ292ZSBjb3JlcworICAgICAqIChjaGVj
a2VkIGhlcmUgd2l0aCBCSElfQ1RSTCkuCisgICAgICoKKyAgICAgKiBUaGUg
SVRTX05PIGZlYXR1cmUgaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVudW1lcmF0
ZWQgYnkgaGFyZHdhcmUsIGFuZCBpcworICAgICAqIG9ubHkgZm9yIFZNTXMg
dG8gc3ludGhlc2lzZSBmb3IgZ3Vlc3RzLgorICAgICAqCisgICAgICogSVRT
IGNvbWVzIGluIDMgZmxhdm91cnM6CisgICAgICoKKyAgICAgKiAgIDEpIEFj
cm9zcy1JQlBCLiAgSW5kaXJlY3QgYnJhbmNoZXMgYWZ0ZXIgdGhlIElCUEIg
Y2FuIGJlIGNvbnRyb2xsZWQKKyAgICAgKiAgICAgIGJ5IGRpcmVjdCB0YXJn
ZXRzIHdoaWNoIGV4aXN0ZWQgcHJpb3IgdG8gdGhlIElCUEIuICBUaGlzIGlz
CisgICAgICogICAgICBhZGRyZXNzZWQgaW4gdGhlIElQVSAyMDI1LjEgbWlj
cm9jb2RlIGRyb3AsIGFuZCBoYXMgbm8gb3RoZXIKKyAgICAgKiAgICAgIHNv
ZnR3YXJlIGludGVyYWN0aW9uLgorICAgICAqCisgICAgICogICAyKSBHdWVz
dC9Ib3N0LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgZGlyZWN0IHRhcmdldHMgZnJv
bSB0aGUgZ3Vlc3QuICBUaGlzIGFwcGxpZXMgZXF1YWxseSB0byBQViBndWVz
dHMKKyAgICAgKiAgICAgIChSaW5nMykgYW5kIEhWTSBndWVzdHMgKFZNWCks
IGFuZCBhcHBsaWVzIHRvIGFsbCBTa3lsYWtlLXVhcmNoCisgICAgICogICAg
ICBjb3JlcyB3aXRoIGVJQlJTLgorICAgICAqCisgICAgICogICAzKSBJbnRy
YS1tb2RlLiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgb3RoZXIgZXhlY3V0aW9uIGlu
IHRoZSBzYW1lIG1vZGUuCisgICAgICovCisKKyAgICAvKgorICAgICAqIElm
IHdlIGNhbiBzZWUgSVRTX05PLCBvciB3ZSdyZSB2aXJ0dWFsaXNlZCwgZG8g
bm90aGluZy4gIFdlIGFyZSBvciBtYXkKKyAgICAgKiBtaWdyYXRlIHNvbWV3
aGVyZSB1bnNhZmUuCisgICAgICovCisgICAgaWYgKCBjcHVfaGFzX2l0c19u
byB8fCBjcHVfaGFzX2h5cGVydmlzb3IgKQorICAgICAgICByZXR1cm47CisK
KyAgICAvKiBJVFMgaXMgb25seSBrbm93biB0byBhZmZlY3QgSW50ZWwgcHJv
Y2Vzc29ycyBhdCB0aGlzIHRpbWUuICovCisgICAgaWYgKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9JTlRFTCApCisgICAgICAg
IHJldHVybjsKKworICAgIC8qCisgICAgICogSVRTIGRvZXMgbm90IGV4aXN0
IG9uOgorICAgICAqICAtIG5vbi1GYW1pbHkgNiBDUFVzCisgICAgICogIC0g
dGhvc2Ugd2l0aG91dCBlSUJSUworICAgICAqICAtIHRob3NlIHdpdGggQkhJ
X0NUUkwKKyAgICAgKiBidXQgd2Ugc3RpbGwgbmVlZCB0byBzeW50aGVzaXNl
IElUU19OTy4KKyAgICAgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2
ICE9IDYgfHwgIWNwdV9oYXNfZWlicnMgfHwKKyAgICAgICAgIGJvb3RfY3B1
X2hhcyhYODZfRkVBVFVSRV9CSElfQ1RSTCkgKQorICAgICAgICBnb3RvIHN5
bnRoZXNpc2U7CisKKyAgICBzd2l0Y2ggKCBib290X2NwdV9kYXRhLng4Nl9t
b2RlbCApCisgICAgeworICAgICAgICAvKiBUaGVzZSBTa3lsYWtlLXVhcmNo
IGNvcmVzIHN1ZmZlciBjYXNlcyAjMiBhbmQgIzMuICovCisgICAgY2FzZSBJ
TlRFTF9GQU02X1NLWUxBS0VfWDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FC
WUxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0U6CisgICAg
Y2FzZSBJTlRFTF9GQU02X0NPTUVUTEFLRToKKyAgICBjYXNlIElOVEVMX0ZB
TTZfQ09NRVRMQUtFX0w6CisgICAgICAgIHJldHVybjsKKworICAgICAgICAv
KiBUaGVzZSBTdW5ueS9XaWxsb3cvQ3lwcmVzcyBDb3ZlIGNvcmVzIHN1ZmZl
ciBjYXNlICMzLiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9JQ0VMQUtFX1g6
CisgICAgY2FzZSBJTlRFTF9GQU02X0lDRUxBS0VfRDoKKyAgICBjYXNlIElO
VEVMX0ZBTTZfSUNFTEFLRV9MOgorICAgIGNhc2UgSU5URUxfRkFNNl9USUdF
UkxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfVElHRVJMQUtFOgorICAg
IGNhc2UgSU5URUxfRkFNNl9ST0NLRVRMQUtFOgorICAgICAgICByZXR1cm47
CisKKyAgICBkZWZhdWx0OgorICAgICAgICBicmVhazsKKyAgICB9CisKKyAg
ICAvKiBQbGF0Zm9ybXMgcmVtYWluaW5nIGFyZSBub3QgYmVsaWV2ZWQgdG8g
YmUgdnVsbmVyYWJsZSB0byBJVFMuICovCisgc3ludGhlc2lzZToKKyAgICBz
ZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX0lUU19OTyk7Cit9CisK
IHZvaWQgc3BlY19jdHJsX2luaXRfZG9tYWluKHN0cnVjdCBkb21haW4gKmQp
CiB7CiAgICAgYm9vbCBwdiA9IGlzX3B2X2RvbWFpbihkKTsKQEAgLTIzMzEs
NiArMjQxNSw4IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0
aWdhdGlvbnModm9pZCkKIAogICAgIGJoaV9jYWxjdWxhdGlvbnMoKTsKIAor
ICAgIGl0c19jYWxjdWxhdGlvbnMoKTsKKwogICAgIHByaW50X2RldGFpbHMo
dGh1bmspOwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IDljOThlNDk5
Mjg2MS4uNGQ5ZTQ2OGFmNjUzIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNs
dWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTM2NSw3
ICszNjUsOCBAQCBYRU5fQ1BVRkVBVFVSRShHRFNfTk8sICAgICAgICAgICAg
IDE2KjMyKzI2KSAvKkEgIE5vIEdhdGhlciBEYXRhIFNhbXBsaW5nICovCiBY
RU5fQ1BVRkVBVFVSRShSRkRTX05PLCAgICAgICAgICAgIDE2KjMyKzI3KSAv
KkEgIE5vIFJlZ2lzdGVyIEZpbGUgRGF0YSBTYW1wbGluZyAqLwogWEVOX0NQ
VUZFQVRVUkUoUkZEU19DTEVBUiwgICAgICAgICAxNiozMisyOCkgLyohQXwg
UmVnaXN0ZXIgRmlsZShzKSBjbGVhcmVkIGJ5IFZFUlcgKi8KIAotLyogSW50
ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMsIE1TUl9BUkNIX0NBUFMgMHgxMGEu
ZWR4LCB3b3JkIDE3ICovCisvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl
cywgTVNSX0FSQ0hfQ0FQUyAweDEwYS5lZHgsIHdvcmQgMTcgKGV4cHJlc3Mg
aW4gdGVybXMgb2Ygd29yZCAxNikgKi8KK1hFTl9DUFVGRUFUVVJFKElUU19O
TywgICAgICAgICAgICAgMTYqMzIrNjIpIC8qIUEgTm8gSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiAqLwogCiAjZW5kaWYgLyogWEVOX0NQVUZFQVRVUkUg
Ki8KIApkaWZmIC0tZ2l0IGEveGVuL3Rvb2xzL2dlbi1jcHVpZC5weSBiL3hl
bi90b29scy9nZW4tY3B1aWQucHkKaW5kZXggNjAxZWVjNjA4OTgzLi5kYzMz
Y2EzMTgxYjEgMTAwNzU1Ci0tLSBhL3hlbi90b29scy9nZW4tY3B1aWQucHkK
KysrIGIveGVuL3Rvb2xzL2dlbi1jcHVpZC5weQpAQCAtNTEsNyArNTEsNyBA
QCBkZWYgcGFyc2VfZGVmaW5pdGlvbnMoc3RhdGUpOgogICAgICAgICByIlxz
Ky9cKihbXHchfF0qKSAuKiQiKQogCiAgICAgd29yZF9yZWdleCA9IHJlLmNv
bXBpbGUoCi0gICAgICAgIHIiXi9cKiAuKiB3b3JkIChcZCopIFwqLyQiKQor
ICAgICAgICByIl4vXCogLiogd29yZCAoXGQqKSAuKlwqLyQiKQogICAgIGxh
c3Rfd29yZCA9IC0xCiAKICAgICB0aGlzID0gc3lzLm1vZHVsZXNbX19uYW1l
X19dCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-01.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-01.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2FsdGVybmF0aXZlOiBTdXBwb3J0IHJlcGxhY2Vt
ZW50cyB3aGVuIGEgZmVhdHVyZSBpcyBub3QgcHJlc2VudAoKVXNlIHRoZSB0
b3AgYml0IG9mIGEtPmNwdWlkIHRvIGV4cHJlc3MgaW52ZXJ0ZWQgcG9sYXJp
dHkuICBUaGlzIHJlcXVpcmVzCnN0cmlwcGluZyB0aGUgdG9wIGJpdCBiYWNr
IG91dCB3aGVuIHBlcmZvcm1pbmcgdGhlIHNhbml0eSBjaGVja3MuCgpEZXNw
aXRlIG9ubHkgYmVpbmcgdXNlZCBvbmNlLCBjcmVhdGUgYSByZXBsYWNlIGJv
b2xlYW4gdG8gZXhwcmVzcyB0aGUgZGVjaXNpb24KbW9yZSBjbGVhcmx5IGlu
IF9hcHBseV9hbHRlcm5hdGl2ZXMoKS4KClNpZ25lZC1vZmYtYnk6IEFuZHJl
dyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmlld2Vk
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC0t
Z2l0IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94
ODYvYWx0ZXJuYXRpdmUuYwppbmRleCAxYmEzNWNiOWVkZTkuLjg4YzkwMDQ0
YzIwZCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMK
KysrIGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTE5Nyw2ICsx
OTcsOCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBseV9h
bHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAgICAg
IHVpbnQ4X3QgKnJlcGwgPSBBTFRfUkVQTF9QVFIoYSk7CiAgICAgICAgIHVp
bnQ4X3QgYnVmW01BWF9QQVRDSF9MRU5dOwogICAgICAgICB1bnNpZ25lZCBp
bnQgdG90YWxfbGVuID0gYS0+b3JpZ19sZW4gKyBhLT5wYWRfbGVuOworICAg
ICAgICB1bnNpZ25lZCBpbnQgZmVhdCA9IGEtPmNwdWlkICYgfkFMVF9GTEFH
X05PVDsKKyAgICAgICAgYm9vbCBpbnYgPSBhLT5jcHVpZCAmIEFMVF9GTEFH
X05PVCwgcmVwbGFjZTsKIAogICAgICAgICBpZiAoIGEtPnJlcGxfbGVuID4g
dG90YWxfbGVuICkKICAgICAgICAgewpAQCAtMjE0LDExICsyMTYsMTEgQEAg
c3RhdGljIGludCBpbml0X29yX2xpdmVwYXRjaCBfYXBwbHlfYWx0ZXJuYXRp
dmVzKHN0cnVjdCBhbHRfaW5zdHIgKnN0YXJ0LAogICAgICAgICAgICAgcmV0
dXJuIC1FTk9TUEM7CiAgICAgICAgIH0KIAotICAgICAgICBpZiAoIGEtPmNw
dWlkID49IE5DQVBJTlRTICogMzIgKQorICAgICAgICBpZiAoIGZlYXQgPj0g
TkNBUElOVFMgKiAzMiApCiAgICAgICAgIHsKICAgICAgICAgICAgICBwcmlu
dGsoWEVOTE9HX0VSUgogICAgICAgICAgICAgICAgICAgICJBbHQgZm9yICVw
cywgZmVhdHVyZSAlI3ggb3V0c2lkZSBvZiBmZWF0dXJlc2V0IHJhbmdlICUj
eFxuIiwKLSAgICAgICAgICAgICAgICAgICBBTFRfT1JJR19QVFIoYSksIGEt
PmNwdWlkLCBOQ0FQSU5UUyAqIDMyKTsKKyAgICAgICAgICAgICAgICAgICBB
TFRfT1JJR19QVFIoYSksIGZlYXQsIE5DQVBJTlRTICogMzIpOwogICAgICAg
ICAgICAgcmV0dXJuIC1FUkFOR0U7CiAgICAgICAgIH0KIApAQCAtMjQzLDgg
KzI0NSwxNCBAQCBzdGF0aWMgaW50IGluaXRfb3JfbGl2ZXBhdGNoIF9hcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsCiAgICAg
ICAgICAgICBjb250aW51ZTsKICAgICAgICAgfQogCisgICAgICAgIC8qCisg
ICAgICAgICAqIFNob3VsZCBhIHJlcGxhY2VtZW50IGJlIHBlcmZvcm1lZD8g
IE1vc3QgcmVwbGFjZW1lbnRzIGhhdmUgcG9zaXRpdmUKKyAgICAgICAgICog
cG9sYXJpdHksIGJ1dCB3ZSBzdXBwb3J0IG5lZ2F0aXZlIHBvbGFyaXR5IHRv
by4KKyAgICAgICAgICovCisgICAgICAgIHJlcGxhY2UgPSBib290X2NwdV9o
YXMoZmVhdCkgXiBpbnY7CisKICAgICAgICAgLyogSWYgdGhlcmUgaXMgbm8g
cmVwbGFjZW1lbnQgdG8gbWFrZSwgc2VlIGFib3V0IG9wdGltaXNpbmcgdGhl
IG5vcHMuICovCi0gICAgICAgIGlmICggIWJvb3RfY3B1X2hhcyhhLT5jcHVp
ZCkgKQorICAgICAgICBpZiAoICFyZXBsYWNlICkKICAgICAgICAgewogICAg
ICAgICAgICAgLyogT3JpZ2luIHNpdGUgc2l0ZSBhbHJlYWR5IHRvdWNoZWQ/
ICBEb24ndCBub3AgYW55dGhpbmcuICovCiAgICAgICAgICAgICBpZiAoIGJh
c2UtPnByaXYgKQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLWFzbS5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FsdGVybmF0aXZlLWFzbS5oCmluZGV4IDgzZTg1OTRmMGVhZi4uZWQz
ZjRjYjA1NWU4IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9h
c20vYWx0ZXJuYXRpdmUtYXNtLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1
ZGUvYXNtL2FsdGVybmF0aXZlLWFzbS5oCkBAIC0xMiw3ICsxMiw3IEBACiAg
KiBpbnN0cnVjdGlvbi4gU2VlIGFwcGx5X2FsdGVybmF0aXZlcygpLgogICov
CiAubWFjcm8gYWx0aW5zdHJ1Y3Rpb25fZW50cnkgb3JpZywgcmVwbCwgZmVh
dHVyZSwgb3JpZ19sZW4sIHJlcGxfbGVuLCBwYWRfbGVuCi0gICAgLmlmIFxm
ZWF0dXJlID49IE5DQVBJTlRTICogMzIKKyAgICAuaWYgKChcZmVhdHVyZSkg
JiB+QUxUX0ZMQUdfTk9UKSA+PSBOQ0FQSU5UUyAqIDMyCiAgICAgICAgIC5l
cnJvciAiYWx0ZXJuYXRpdmUgZmVhdHVyZSBvdXRzaWRlIG9mIGZlYXR1cmVz
ZXQgcmFuZ2UiCiAgICAgLmVuZGlmCiAgICAgLmxvbmcgXG9yaWcgLSAuCmRp
ZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYWx0ZXJuYXRp
dmUuaCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5o
CmluZGV4IDM4NDcyZmI1OGUyZC4uZWY2M2UyNTdhZDc4IDEwMDY0NAotLS0g
YS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYWx0ZXJuYXRpdmUuaAorKysg
Yi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYWx0ZXJuYXRpdmUuaApAQCAt
MSw2ICsxLDEzIEBACiAjaWZuZGVmIF9fWDg2X0FMVEVSTkFUSVZFX0hfXwog
I2RlZmluZSBfX1g4Nl9BTFRFUk5BVElWRV9IX18KIAorLyoKKyAqIENvbW1v
biB0byBib3RoIEMgYW5kIEFTTS4gIEV4cHJlc3MgYSByZXBsYWNlbWVudCB3
aGVuIGEgZmVhdHVyZSBpcyBub3QKKyAqIGF2YWlsYWJsZS4KKyAqLworI2Rl
ZmluZSBBTFRfRkxBR19OT1QgKDEgPDwgMTUpCisjZGVmaW5lIEFMVF9OT1Qo
eCkgKEFMVF9GTEFHX05PVCB8ICh4KSkKKwogI2lmZGVmIF9fQVNTRU1CTFlf
XwogI2luY2x1ZGUgPGFzbS9hbHRlcm5hdGl2ZS1hc20uaD4KICNlbHNlCkBA
IC0xMiw3ICsxOSw3IEBACiBzdHJ1Y3QgX19wYWNrZWQgYWx0X2luc3RyIHsK
ICAgICBpbnQzMl90ICBvcmlnX29mZnNldDsgICAvKiBvcmlnaW5hbCBpbnN0
cnVjdGlvbiAqLwogICAgIGludDMyX3QgIHJlcGxfb2Zmc2V0OyAgIC8qIG9m
ZnNldCB0byByZXBsYWNlbWVudCBpbnN0cnVjdGlvbiAqLwotICAgIHVpbnQx
Nl90IGNwdWlkOyAgICAgICAgIC8qIGNwdWlkIGJpdCBzZXQgZm9yIHJlcGxh
Y2VtZW50ICovCisgICAgdWludDE2X3QgY3B1aWQ7ICAgICAgICAgLyogY3B1
aWQgYml0IHNldCBmb3IgcmVwbGFjZW1lbnQgKHRvcCBiaXQgaXMgcG9sYXJp
dHkpICovCiAgICAgdWludDhfdCAgb3JpZ19sZW47ICAgICAgLyogbGVuZ3Ro
IG9mIG9yaWdpbmFsIGluc3RydWN0aW9uICovCiAgICAgdWludDhfdCAgcmVw
bF9sZW47ICAgICAgLyogbGVuZ3RoIG9mIG5ldyBpbnN0cnVjdGlvbiAqLwog
ICAgIHVpbnQ4X3QgIHBhZF9sZW47ICAgICAgIC8qIGxlbmd0aCBvZiBidWls
ZC10aW1lIHBhZGRpbmcgKi8KQEAgLTYwLDcgKzY3LDcgQEAgZXh0ZXJuIHZv
aWQgYWx0ZXJuYXRpdmVfYnJhbmNoZXModm9pZCk7CiAgICAgICAgICAgICAg
ICAgICAgIGFsdF9yZXBsX2xlbihuMikpICItIiBhbHRfb3JpZ19sZW4pCiAK
ICNkZWZpbmUgQUxUSU5TVFJfRU5UUlkoZmVhdHVyZSwgbnVtKSAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgIiAuaWYg
IiBTVFIoZmVhdHVyZSkgIiA+PSAiIFNUUihOQ0FQSU5UUyAqIDMyKSAiXG4i
ICAgICAgICAgICAgIFwKKyAgICAgICAgIiAuaWYgKCIgU1RSKGZlYXR1cmUg
JiB+QUxUX0ZMQUdfTk9UKSAiKSA+PSAiIFNUUihOQ0FQSU5UUyAqIDMyKSAi
XG4iIFwKICAgICAgICAgIiAuZXJyb3IgXCJhbHRlcm5hdGl2ZSBmZWF0dXJl
IG91dHNpZGUgb2YgZmVhdHVyZXNldCByYW5nZVwiXG4iIFwKICAgICAgICAg
IiAuZW5kaWZcbiIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgIiAubG9uZyAuTFhFTiU9
X29yaWdfcyAtIC5cbiIgICAgICAgICAgICAgLyogbGFiZWwgICAgICAgICAg
ICovIFwKCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-02.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-02.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L2d1ZXN0OiBSZW1vdmUgdXNlIG9mIHRoZSBYZW4g
aHlwZXJjYWxsX3BhZ2UKCkluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCBJ
VFMsIFhlbiBuZWVkcyB0byBzdGFydCB1c2luZyByZXR1cm4gdGh1bmtzLgpU
aGVyZWZvcmUgdGhlIGFkdmljZSBpbiBYU0EtNDY2IGJlY29tZXMgcmVsZXZh
bnQsIGFuZCB0aGUgaHlwZXJjYWxsX3BhZ2UgbmVlZHMKdG8gYmUgcmVtb3Zl
ZC4KCkltcGxlbWVudCBlYXJseV9oeXBlcmNhbGwoKSwgd2l0aCBpbmZyYXN0
cnVjdHVyZSB0byBmaWd1cmUgb3V0IHRoZSBjb3JyZWN0Cmluc3RydWN0aW9u
IG9uIGZpcnN0IHVzZS4gIFVzZSBBTFRFUk5BVElWRSgpcyB0byByZXN1bHQg
aW4gaW5saW5lIGh5cGVyY2FsbHMsCmluY2x1ZGluZyB0aGUgQUxUX05PVCgp
IGZvcm0gc28gd2Ugb25seSBuZWVkIGEgc2luZ2xlIHN5bnRoZXRpYyBmZWF0
dXJlIGJpdC4KCk5vIG92ZXJhbGwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0IG9m
IFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTogQW5k
cmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3
ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29t
PgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9ndWVzdC94ZW4vTWFrZWZp
bGUgYi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCmluZGV4IDI2
ZmI0YjEwMDdjMC4uOGIzMjUwYWE4ODg2IDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvZ3Vlc3QveGVuL01ha2VmaWxlCisrKyBiL3hlbi9hcmNoL3g4Ni9n
dWVzdC94ZW4vTWFrZWZpbGUKQEAgLTEsNCArMSw0IEBACi1vYmoteSArPSBo
eXBlcmNhbGxfcGFnZS5vCitvYmotYmluLXkgKz0gaHlwZXJjYWxsLmluaXQu
bwogb2JqLXkgKz0geGVuLm8KIAogb2JqLWJpbi0kKENPTkZJR19QVkhfR1VF
U1QpICs9IHB2aC1ib290LmluaXQubwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGwuUyBiL3hlbi9hcmNoL3g4Ni9ndWVz
dC94ZW4vaHlwZXJjYWxsLlMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg
MDAwMDAwMDAwMDAwLi4wNWU0Mjk3OTRjYzQKLS0tIC9kZXYvbnVsbAorKysg
Yi94ZW4vYXJjaC94ODYvZ3Vlc3QveGVuL2h5cGVyY2FsbC5TCkBAIC0wLDAg
KzEsNTAgQEAKKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4w
LW9yLWxhdGVyICovCisKKyNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPgorCisg
ICAgICAgIC5zZWN0aW9uIC5pbml0LnRleHQsICJheCIsIEBwcm9nYml0cwor
CisgICAgICAgIC8qCisgICAgICAgICAqIFVzZWQgZHVyaW5nIGVhcmx5IGJv
b3QsIGJlZm9yZSBhbHRlcm5hdGl2ZXMgaGF2ZSBydW4gYW5kIGlubGluZWQK
KyAgICAgICAgICogdGhlIGFwcHJvcHJpYXRlIGluc3RydWN0aW9uLiAgQ2Fs
bGVkIHVzaW5nIHRoZSBoeXBlcmNhbGwgQUJJLgorICAgICAgICAgKi8KK0ZV
TkMoZWFybHlfaHlwZXJjYWxsKQorICAgICAgICBjbXBiICAgICQwLCBlYXJs
eV9oeXBlcmNhbGxfaW5zbiglcmlwKQorICAgICAgICBqbCAgICAgIC5MX3Nl
dHVwCisgICAgICAgIGplICAgICAgMWYKKworICAgICAgICB2bW1jYWxsCisg
ICAgICAgIHJldAorCisxOiAgICAgIHZtY2FsbAorICAgICAgICByZXQKKwor
Lkxfc2V0dXA6CisgICAgICAgIC8qCisgICAgICAgICAqIFdoZW4gc2V0dGlu
ZyB1cCB0aGUgZmlyc3QgdGltZSBhcm91bmQsIGFsbCByZWdpc3RlcnMgbmVl
ZAorICAgICAgICAgKiBwcmVzZXJ2aW5nLiAgU2F2ZSB0aGUgbm9uLWNhbGxl
ZS1zYXZlZCBvbmVzLgorICAgICAgICAgKi8KKyAgICAgICAgcHVzaCAgICAl
cjExCisgICAgICAgIHB1c2ggICAgJXIxMAorICAgICAgICBwdXNoICAgICVy
OQorICAgICAgICBwdXNoICAgICVyOAorICAgICAgICBwdXNoICAgICVyZGkK
KyAgICAgICAgcHVzaCAgICAlcnNpCisgICAgICAgIHB1c2ggICAgJXJkeAor
ICAgICAgICBwdXNoICAgICVyY3gKKyAgICAgICAgcHVzaCAgICAlcmF4CisK
KyAgICAgICAgY2FsbCAgICBlYXJseV9oeXBlcmNhbGxfc2V0dXAKKworICAg
ICAgICBwb3AgICAgICVyYXgKKyAgICAgICAgcG9wICAgICAlcmN4CisgICAg
ICAgIHBvcCAgICAgJXJkeAorICAgICAgICBwb3AgICAgICVyc2kKKyAgICAg
ICAgcG9wICAgICAlcmRpCisgICAgICAgIHBvcCAgICAgJXI4CisgICAgICAg
IHBvcCAgICAgJXI5CisgICAgICAgIHBvcCAgICAgJXIxMAorICAgICAgICBw
b3AgICAgICVyMTEKKworICAgICAgICBqbXAgICAgIGVhcmx5X2h5cGVyY2Fs
bAorRU5EKGVhcmx5X2h5cGVyY2FsbCkKZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUyBiL3hlbi9hcmNoL3g4
Ni9ndWVzdC94ZW4vaHlwZXJjYWxsX3BhZ2UuUwpkZWxldGVkIGZpbGUgbW9k
ZSAxMDA2NDQKaW5kZXggN2FiNTVmYzFmNmU2Li4wMDAwMDAwMDAwMDAKLS0t
IGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi9oeXBlcmNhbGxfcGFnZS5TCisr
KyAvZGV2L251bGwKQEAgLTEsNzYgKzAsMCBAQAotI2luY2x1ZGUgPGFzbS9w
YWdlLmg+Ci0jaW5jbHVkZSA8YXNtL2FzbV9kZWZucy5oPgotI2luY2x1ZGUg
PHB1YmxpYy94ZW4uaD4KLQotICAgICAgICAuc2VjdGlvbiAiLnRleHQucGFn
ZV9hbGlnbmVkIiwgImF4IiwgQHByb2diaXRzCi0KLURBVEEoaHlwZXJjYWxs
X3BhZ2UsIFBBR0VfU0laRSkKLSAgICAgICAgIC8qIFBvaXNvbmVkIHdpdGgg
YHJldGAgZm9yIHNhZmV0eSBiZWZvcmUgaHlwZXJjYWxscyBhcmUgc2V0IHVw
LiAqLwotICAgICAgICAuZmlsbCBQQUdFX1NJWkUsIDEsIDB4YzMKLUVORCho
eXBlcmNhbGxfcGFnZSkKLQotLyoKLSAqIElkZW50aWZ5IGEgc3BlY2lmaWMg
aHlwZXJjYWxsIGluIHRoZSBoeXBlcmNhbGwgcGFnZQotICogQHBhcmFtIG5h
bWUgSHlwZXJjYWxsIG5hbWUuCi0gKi8KLSNkZWZpbmUgREVDTEFSRV9IWVBF
UkNBTEwobmFtZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXAotICAgICAgICAuZ2xvYmwgSFlQRVJDQUxMXyAj
IyBuYW1lOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBcCi0gICAgICAgIC50eXBlICBIWVBFUkNBTExfICMjIG5hbWUs
IFNUVF9GVU5DOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFwKLSAgICAgICAgLnNpemUgIEhZUEVSQ0FMTF8gIyMgbmFtZSwgMzI7ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAotICAg
ICAgICAuc2V0ICAgSFlQRVJDQUxMXyAjIyBuYW1lLCBoeXBlcmNhbGxfcGFn
ZSArIF9fSFlQRVJWSVNPUl8gIyMgbmFtZSAqIDMyCi0KLURFQ0xBUkVfSFlQ
RVJDQUxMKHNldF90cmFwX3RhYmxlKQotREVDTEFSRV9IWVBFUkNBTEwobW11
X3VwZGF0ZSkKLURFQ0xBUkVfSFlQRVJDQUxMKHNldF9nZHQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChzdGFja19zd2l0Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChz
ZXRfY2FsbGJhY2tzKQotREVDTEFSRV9IWVBFUkNBTEwoZnB1X3Rhc2tzd2l0
Y2gpCi1ERUNMQVJFX0hZUEVSQ0FMTChzY2hlZF9vcF9jb21wYXQpCi1ERUNM
QVJFX0hZUEVSQ0FMTChwbGF0Zm9ybV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxM
KHNldF9kZWJ1Z3JlZykKLURFQ0xBUkVfSFlQRVJDQUxMKGdldF9kZWJ1Z3Jl
ZykKLURFQ0xBUkVfSFlQRVJDQUxMKHVwZGF0ZV9kZXNjcmlwdG9yKQotREVD
TEFSRV9IWVBFUkNBTEwobWVtb3J5X29wKQotREVDTEFSRV9IWVBFUkNBTEwo
bXVsdGljYWxsKQotREVDTEFSRV9IWVBFUkNBTEwodXBkYXRlX3ZhX21hcHBp
bmcpCi1ERUNMQVJFX0hZUEVSQ0FMTChzZXRfdGltZXJfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTChldmVudF9jaGFubmVsX29wX2NvbXBhdCkKLURFQ0xBUkVf
SFlQRVJDQUxMKHhlbl92ZXJzaW9uKQotREVDTEFSRV9IWVBFUkNBTEwoY29u
c29sZV9pbykKLURFQ0xBUkVfSFlQRVJDQUxMKHBoeXNkZXZfb3BfY29tcGF0
KQotREVDTEFSRV9IWVBFUkNBTEwoZ3JhbnRfdGFibGVfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh2bV9hc3Npc3QpCi1ERUNMQVJFX0hZUEVSQ0FMTCh1cGRh
dGVfdmFfbWFwcGluZ19vdGhlcmRvbWFpbikKLURFQ0xBUkVfSFlQRVJDQUxM
KGlyZXQpCi1ERUNMQVJFX0hZUEVSQ0FMTCh2Y3B1X29wKQotREVDTEFSRV9I
WVBFUkNBTEwoc2V0X3NlZ21lbnRfYmFzZSkKLURFQ0xBUkVfSFlQRVJDQUxM
KG1tdWV4dF9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHhzbV9vcCkKLURFQ0xB
UkVfSFlQRVJDQUxMKG5taV9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKHNjaGVk
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoY2FsbGJhY2tfb3ApCi1ERUNMQVJF
X0hZUEVSQ0FMTCh4ZW5vcHJvZl9vcCkKLURFQ0xBUkVfSFlQRVJDQUxMKGV2
ZW50X2NoYW5uZWxfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChwaHlzZGV2X29w
KQotREVDTEFSRV9IWVBFUkNBTEwoaHZtX29wKQotREVDTEFSRV9IWVBFUkNB
TEwoc3lzY3RsKQotREVDTEFSRV9IWVBFUkNBTEwoZG9tY3RsKQotREVDTEFS
RV9IWVBFUkNBTEwoa2V4ZWNfb3ApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmdv
X29wKQotREVDTEFSRV9IWVBFUkNBTEwoeGVucG11X29wKQotCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzApCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzEp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzIpCi1ERUNMQVJFX0hZUEVSQ0FM
TChhcmNoXzMpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzQpCi1ERUNMQVJF
X0hZUEVSQ0FMTChhcmNoXzUpCi1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzYp
Ci1ERUNMQVJFX0hZUEVSQ0FMTChhcmNoXzcpCi0KLS8qCi0gKiBMb2NhbCB2
YXJpYWJsZXM6Ci0gKiB0YWItd2lkdGg6IDgKLSAqIGluZGVudC10YWJzLW1v
ZGU6IG5pbAotICogRW5kOgotICovCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvZ3Vlc3QveGVuL3hlbi5jIGIveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94
ZW4uYwppbmRleCBjMTdmNWM0NDdhYjYuLjVjOWYzOTNjNzUxNCAxMDA2NDQK
LS0tIGEveGVuL2FyY2gveDg2L2d1ZXN0L3hlbi94ZW4uYworKysgYi94ZW4v
YXJjaC94ODYvZ3Vlc3QveGVuL3hlbi5jCkBAIC0yNiw3ICsyNiw2IEBACiBi
b29sIF9fcmVhZF9tb3N0bHkgeGVuX2d1ZXN0OwogCiB1aW50MzJfdCBfX3Jl
YWRfbW9zdGx5IHhlbl9jcHVpZF9iYXNlOwotZXh0ZXJuIGNoYXIgaHlwZXJj
YWxsX3BhZ2VbXTsKIHN0YXRpYyBzdHJ1Y3QgcmFuZ2VzZXQgKm1lbTsKIAog
REVGSU5FX1BFUl9DUFUodW5zaWduZWQgaW50LCB2Y3B1X2lkKTsKQEAgLTM1
LDYgKzM0LDUwIEBAIHN0YXRpYyBzdHJ1Y3QgdmNwdV9pbmZvICp2Y3B1X2lu
Zm87CiBzdGF0aWMgdW5zaWduZWQgbG9uZyB2Y3B1X2luZm9fbWFwcGVkW0JJ
VFNfVE9fTE9OR1MoTlJfQ1BVUyldOwogREVGSU5FX1BFUl9DUFUoc3RydWN0
IHZjcHVfaW5mbyAqLCB2Y3B1X2luZm8pOwogCisvKgorICogV2hpY2ggaW5z
dHJ1Y3Rpb24gdG8gdXNlIGZvciBlYXJseSBoeXBlcmNhbGxzOgorICogICA8
IDAgc2V0dXAKKyAqICAgICAwIHZtY2FsbAorICogICA+IDAgdm1tY2FsbAor
ICovCitpbnQ4X3QgX19pbml0ZGF0YSBlYXJseV9oeXBlcmNhbGxfaW5zbiA9
IC0xOworCisvKgorICogQ2FsbGVkIG9uY2UgZHVyaW5nIHRoZSBmaXJzdCBo
eXBlcmNhbGwgdG8gZmlndXJlIG91dCB3aGljaCBpbnN0cnVjdGlvbiB0bwor
ICogdXNlLiAgRXJyb3IgaGFuZGxpbmcgb3B0aW9ucyBhcmUgbGltaXRlZC4K
KyAqLwordm9pZCBhc21saW5rYWdlIF9faW5pdCBlYXJseV9oeXBlcmNhbGxf
c2V0dXAodm9pZCkKK3sKKyAgICBCVUdfT04oZWFybHlfaHlwZXJjYWxsX2lu
c24gIT0gLTEpOworCisgICAgaWYgKCAhYm9vdF9jcHVfZGF0YS54ODZfdmVu
ZG9yICkKKyAgICB7CisgICAgICAgIHVuc2lnbmVkIGludCBlYXgsIGVieCwg
ZWN4LCBlZHg7CisKKyAgICAgICAgY3B1aWQoMCwgJmVheCwgJmVieCwgJmVj
eCwgJmVkeCk7CisKKyAgICAgICAgYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ID0geDg2X2NwdWlkX2xvb2t1cF92ZW5kb3IoZWJ4LCBlY3gsIGVkeCk7Cisg
ICAgfQorCisgICAgc3dpdGNoICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ICkKKyAgICB7CisgICAgY2FzZSBYODZfVkVORE9SX0lOVEVMOgorICAgIGNh
c2UgWDg2X1ZFTkRPUl9DRU5UQVVSOgorICAgIGNhc2UgWDg2X1ZFTkRPUl9T
SEFOR0hBSToKKyAgICAgICAgZWFybHlfaHlwZXJjYWxsX2luc24gPSAwOwor
ICAgICAgICBzZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpOworICAgICAgICBicmVhazsKKworICAgIGNhc2UgWDg2X1ZFTkRP
Ul9BTUQ6CisgICAgY2FzZSBYODZfVkVORE9SX0hZR09OOgorICAgICAgICBl
YXJseV9oeXBlcmNhbGxfaW5zbiA9IDE7CisgICAgICAgIGJyZWFrOworCisg
ICAgZGVmYXVsdDoKKyAgICAgICAgQlVHKCk7CisgICAgfQorfQorCiBzdGF0
aWMgdm9pZCBfX2luaXQgZmluZF94ZW5fbGVhdmVzKHZvaWQpCiB7CiAgICAg
dWludDMyX3QgZWF4LCBlYngsIGVjeCwgZWR4LCBiYXNlOwpAQCAtMzM3LDkg
KzM4MCw2IEBAIGNvbnN0IHN0cnVjdCBoeXBlcnZpc29yX29wcyAqX19pbml0
IHhnX3Byb2JlKHZvaWQpCiAgICAgaWYgKCAheGVuX2NwdWlkX2Jhc2UgKQog
ICAgICAgICByZXR1cm4gTlVMTDsKIAotICAgIC8qIEZpbGwgdGhlIGh5cGVy
Y2FsbCBwYWdlLiAqLwotICAgIHdybXNybChjcHVpZF9lYngoeGVuX2NwdWlk
X2Jhc2UgKyAyKSwgX19wYShoeXBlcmNhbGxfcGFnZSkpOwotCiAgICAgeGVu
X2d1ZXN0ID0gdHJ1ZTsKIAogICAgIHJldHVybiAmb3BzOwpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmggYi94
ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vY3B1ZmVhdHVyZXMuaAppbmRleCBi
YTNkZjE3NGI3NmUuLjllM2VkMjFjMDI2ZCAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKKysrIGIveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmgKQEAgLTQyLDYgKzQy
LDcgQEAgWEVOX0NQVUZFQVRVUkUoWEVOX1NIU1RLLCAgICAgICAgIFg4Nl9T
WU5USCgyNikpIC8qIFhlbiB1c2VzIENFVCBTaGFkb3cgU3RhY2tzICoKIFhF
Tl9DUFVGRUFUVVJFKFhFTl9JQlQsICAgICAgICAgICBYODZfU1lOVEgoMjcp
KSAvKiBYZW4gdXNlcyBDRVQgSW5kaXJlY3QgQnJhbmNoIFRyYWNraW5nICov
CiBYRU5fQ1BVRkVBVFVSRShJQlBCX0VOVFJZX1BWLCAgICAgWDg2X1NZTlRI
KDI4KSkgLyogTVNSX1BSRURfQ01EIHVzZWQgYnkgWGVuIGZvciBQViAqLwog
WEVOX0NQVUZFQVRVUkUoSUJQQl9FTlRSWV9IVk0sICAgIFg4Nl9TWU5USCgy
OSkpIC8qIE1TUl9QUkVEX0NNRCB1c2VkIGJ5IFhlbiBmb3IgSFZNICovCitY
RU5fQ1BVRkVBVFVSRShVU0VfVk1DQUxMLCAgICAgICAgWDg2X1NZTlRIKDMw
KSkgLyogVXNlIFZNQ0FMTCBpbnN0ZWFkIG9mIFZNTUNBTEwgKi8KIAogLyog
QnVnIHdvcmRzIGZvbGxvdyB0aGUgc3ludGhldGljIHdvcmRzLiAqLwogI2Rl
ZmluZSBYODZfTlJfQlVHIDEKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaCBiL3hlbi9hcmNoL3g4Ni9p
bmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaAppbmRleCA2NjViNDcyZDA1
YWMuLjk2MDA0ZGVjOTkwOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2d1ZXN0L3hlbi1oY2FsbC5oCisrKyBiL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9ndWVzdC94ZW4taGNhbGwuaApAQCAtMzAsOSArMzAs
MTEgQEAKICAgICAoeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICgg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKLSAgICAgICAgICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNb
b2Zmc2V0XSIgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAg
ICAgIEFMVEVSTkFUSVZFXzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgInZtbWNhbGwiLCBBTFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwp
LCAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4
Nl9GRUFUVVJFX1VTRV9WTUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgIDogIj1hIiAocmVzKSwgIj1EIiAodG1wX18pIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgIFwKLSAgICAgICAgICAgIDogW29mZnNldF0g
ImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2FsbCksICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAg
ICAgICAgIjEiICgobG9uZykoYTEpKSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgKHR5cGUpcmVzOyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKQEAgLTQyLDEw
ICs0NCwxMiBAQAogICAgICh7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICBsb25nIHJlcywgdG1wX187ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICBhc20gdm9sYXRp
bGUgKCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgImNhbGwgaHlwZXJjYWxsX3BhZ2Ug
KyAlY1tvZmZzZXRdIiAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgQUxURVJOQVRJVkVfMigiY2FsbCBlYXJseV9oeXBlcmNhbGwi
LCAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAidm1tY2FsbCIsIEFMVF9OT1QoWDg2X0ZFQVRVUkVfVVNFX1ZN
Q0FMTCksICAgXAorICAgICAgICAgICAgICAgICAgICAgICAgICAidm1jYWxs
IiwgWDg2X0ZFQVRVUkVfVVNFX1ZNQ0FMTCkgICAgICAgICAgICAgXAogICAg
ICAgICAgICAgOiAiPWEiIChyZXMpLCAiPUQiICh0bXBfXyksICI9UyIgKHRt
cF9fKSAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICBBU01f
Q0FMTF9DT05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgXAotICAgICAgICAgICAgOiBbb2Zmc2V0XSAiaSIgKGhjYWxs
ICogMzIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAg
ICAgICAgICAgOiAiMCIgKGhjYWxsKSwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAiMSIg
KChsb25nKShhMSkpLCAiMiIgKChsb25nKShhMikpICAgICAgICAgICAgICAg
ICAgICAgICAgXAogICAgICAgICAgICAgOiAibWVtb3J5IiApOyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg
ICAgICAodHlwZSlyZXM7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgXApAQCAtNTUsMTAgKzU5LDEyIEBA
CiAgICAgKHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgIGxvbmcg
cmVzLCB0bXBfXzsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgIGFzbSB2b2xhdGlsZSAoICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICAiY2FsbCBoeXBlcmNhbGxfcGFnZSArICVjW29mZnNl
dF0iICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICBB
TFRFUk5BVElWRV8yKCJjYWxsIGVhcmx5X2h5cGVyY2FsbCIsICAgICAgICAg
ICAgICAgICAgICAgICBcCisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2
bW1jYWxsIiwgQUxUX05PVChYODZfRkVBVFVSRV9VU0VfVk1DQUxMKSwgICBc
CisgICAgICAgICAgICAgICAgICAgICAgICAgICJ2bWNhbGwiLCBYODZfRkVB
VFVSRV9VU0VfVk1DQUxMKSAgICAgICAgICAgICBcCiAgICAgICAgICAgICA6
ICI9YSIgKHJlcyksICI9RCIgKHRtcF9fKSwgIj1TIiAodG1wX18pLCAiPWQi
ICh0bXBfXykgICAgICBcCiAgICAgICAgICAgICAgIEFTTV9DQUxMX0NPTlNU
UkFJTlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
Ci0gICAgICAgICAgICA6IFtvZmZzZXRdICJpIiAoaGNhbGwgKiAzMiksICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgICAgICAgICA6
ICIwIiAoaGNhbGwpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICIxIiAoKGxvbmcpKGEx
KSksICIyIiAoKGxvbmcpKGEyKSksICIzIiAoKGxvbmcpKGEzKSkgICAgICBc
CiAgICAgICAgICAgICA6ICJtZW1vcnkiICk7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICh0eXBl
KXJlczsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBcCkBAIC02OSwxMCArNzUsMTIgQEAKICAgICAgICAg
bG9uZyByZXMsIHRtcF9fOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgcmVnaXN0ZXIgbG9uZyBf
YTQgYXNtICgicjEwIikgPSAoKGxvbmcpKGE0KSk7ICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgYXNtIHZvbGF0aWxlICggICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgICJjYWxsIGh5cGVyY2FsbF9wYWdlICsgJWNbb2Zmc2V0XSIgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIEFMVEVSTkFUSVZF
XzIoImNhbGwgZWFybHlfaHlwZXJjYWxsIiwgICAgICAgICAgICAgICAgICAg
ICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgInZtbWNhbGwiLCBB
TFRfTk9UKFg4Nl9GRUFUVVJFX1VTRV9WTUNBTEwpLCAgIFwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgInZtY2FsbCIsIFg4Nl9GRUFUVVJFX1VTRV9W
TUNBTEwpICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIj1hIiAocmVz
KSwgIj1EIiAodG1wX18pLCAiPVMiICh0bXBfXyksICI9ZCIgKHRtcF9fKSwg
ICAgIFwKICAgICAgICAgICAgICAgIj0mciIgKHRtcF9fKSBBU01fQ0FMTF9D
T05TVFJBSU5UICAgICAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAg
ICAgIDogW29mZnNldF0gImkiIChoY2FsbCAqIDMyKSwgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgIDogIjAiIChoY2Fs
bCksICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwKICAgICAgICAgICAgICAgIjEiICgobG9uZykoYTEpKSwgIjIiICgo
bG9uZykoYTIpKSwgIjMiICgobG9uZykoYTMpKSwgICAgIFwKICAgICAgICAg
ICAgICAgIjQiIChfYTQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgIDogIm1lbW9yeSIg
KTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-03.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-03.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IChNaXMpYWxpZ24gX194ODZfaW5kaXJlY3RfdGh1bmtf
KiB0byBtaXRpZ2F0ZSBJVFMKClRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0
aW9uIHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRp
cmVjdApicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hl
biBpbiB0aGUgZmlyc3QgaGFsZiBvZiBhIGNhY2hlbGluZS4KCkFycmFuZ2Ug
Zm9yIF9feDg2X2luZGlyZWN0X3RodW5rXyogdG8gYWx3YXlzIGJlIGluIHRo
ZSBzZWNvbmQgaGFsZi4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDY5IC8gQ1ZF
LTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1
bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBC
ZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUyBiL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TCmluZGV4IGZkNTQ5M2MyMmIxNi4uYzRiOTc4ZDY3Yjhl
IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwor
KysgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3QtdGh1bmsuUwpAQCAtMTEsNiAr
MTEsMTAgQEAKIAogI2luY2x1ZGUgPGFzbS9hc21fZGVmbnMuaD4KIAorLyog
QWxpZ25tZW50IGlzIGRlYWx0IHdpdGggZXhwbGljaXRseSBoZXJlOyBvdmVy
cmlkZSB0aGUgcmVzcGVjdGl2ZSBtYWNyby4gKi8KKyN1bmRlZiBTWU1fQUxJ
R04KKyNkZWZpbmUgU1lNX0FMSUdOKGFsaWduLi4uKQorCiAubWFjcm8gSU5E
X1RIVU5LX1JFVFBPTElORSByZWc6cmVxCiAgICAgICAgIGNhbGwgMWYKICAg
ICAgICAgaW50MwpAQCAtMzUsNiArMzksMTYgQEAKIC5tYWNybyBHRU5fSU5E
SVJFQ1RfVEhVTksgcmVnOnJlcQogICAgICAgICAuc2VjdGlvbiAudGV4dC5f
X3g4Nl9pbmRpcmVjdF90aHVua19ccmVnLCAiYXgiLCBAcHJvZ2JpdHMKIAor
ICAgICAgICAvKgorICAgICAgICAgKiBUaGUgSW5kaXJlY3QgVGFyZ2V0IFNl
bGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5zIHRoYXQK
KyAgICAgICAgICogaW5kaXJlY3QgYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRz
KSBhcmUgdW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0CisgICAgICAgICAqIGhh
bGYgb2YgYSBjYWNoZWxpbmUuICBBcnJhbmdlIGZvciB0aGVtIHRvIGJlIGlu
IHRoZSBzZWNvbmQgaGFsZi4KKyAgICAgICAgICoKKyAgICAgICAgICogQWxp
Z24gdG8gNjQsIHRoZW4gc2tpcCAzMi4KKyAgICAgICAgICovCisgICAgICAg
IC5iYWxpZ24gNjQKKyAgICAgICAgLmZpbGwgMzIsIDEsIDB4Y2MKKwogRlVO
QyhfX3g4Nl9pbmRpcmVjdF90aHVua19ccmVnKQogICAgICAgICBBTFRFUk5B
VElWRV8yIF9fc3RyaW5naWZ5KElORF9USFVOS19SRVRQT0xJTkUgXHJlZyks
ICAgICAgICAgICAgICBcCiAgICAgICAgIF9fc3RyaW5naWZ5KElORF9USFVO
S19MRkVOQ0UgXHJlZyksIFg4Nl9GRUFUVVJFX0lORF9USFVOS19MRkVOQ0Us
IFwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-04.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-04.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3RodW5rOiAoTWlzKWFsaWduIHRoZSBSRVRzIGlu
IGNsZWFyX2JoYl9sb29wcygpIHRvIG1pdGlnYXRlIElUUwoKVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0IGluZGlyZWN0CmJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdCBoYWxmIG9mIGEgY2Fj
aGVsaW5lLgoKY2xlYXJfYmhiX2xvb3BzKCkgaGFzIGEgcHJlY2lzZSBsYXlv
dXQgb2YgYnJhbmNoZXMuICBUaGUgYWxpZ25tZW50IGZvcgpwZXJmb3JtYW5j
ZSBjYXVzZSB0aGUgUkVUcyB0byBhbHdheXMgYmUgaW4gYW4gdW5zYWZlIHBv
c2l0aW9uLCBhbmQgY29udmVydGluZwp0aG9zZSB0byByZXR1cm4gdGh1bmtz
IGNoYW5nZXMgdGhlIGJyYW5jaGluZyBwYXR0ZXJuLiAgV2hpbGUgc3VjaCBh
IGNvbnZlcnNpb24KaXMgYmVsaWV2ZWQgdG8gYmUgc2FmZSwgY2xlYXJfYmhi
X2xvb3BzKCkgaXMgYWxzbyBhIHBlcmZvcm1hbmNlLXJlbGV2YW50CmZhc3Rw
YXRoLCBzbyAobWlzKWFsaWduIHRoZSBSRVRzIHRvIGJlIGluIGEgc2FmZSBw
b3NpdGlvbi4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0
IG9mIFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUyBi
L3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCA2NzhjMDBjNWQwNmYu
LjUyNjI1ZjRlMmMxNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2JoYi10
aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwpAQCAtNTAs
NyArNTAsMTIgQEAgRU5EKGNsZWFyX2JoYl90c3gpCiAgKiAgIHJldAogICoK
ICAqIFRoZSBDQUxML1JFVHMgYXJlIG5lY2Vzc2FyeSB0byBwcmV2ZW50IHRo
ZSBMb29wIFN0cmVhbSBEZXRlY3RvciBmcm9tCi0gKiBpbnRlcmZlcmluZy4g
IFRoZSBhbGlnbm1lbnQgaXMgZm9yIHBlcmZvcm1hbmNlIGFuZCBub3Qgc2Fm
ZXR5LgorICogaW50ZXJmZXJpbmcuCisgKgorICogVGhlIC5iYWxpZ24ncyBh
cmUgZm9yIHBlcmZvcm1hbmNlLCBidXQgdGhleSBjYXVzZSB0aGUgUkVUcyB0
byBiZSBpbiB1bnNhZmUKKyAqIHBvc2l0aW9ucyB3aXRoIHJlc3BlY3QgdG8g
SW5kaXJlY3QgVGFyZ2V0IFNlbGVjdGlvbi4gIFRoZSAuc2tpcHMgYXJlIHRv
CisgKiBtb3ZlIHRoZSBSRVRzIGludG8gSVRTLXNhZmUgcG9zaXRpb25zLCBy
YXRoZXIgdGhhbiB1c2luZyB0aGUgc2xvd3BhdGgKKyAqIHRocm91Z2ggX194
ODZfcmV0dXJuX3RodW5rLgogICoKICAqIFRoZSAic2hvcnQiIHNlcXVlbmNl
ICg1IGFuZCA1KSBpcyBmb3IgQ1BVcyBwcmlvciB0byBBbGRlciBMYWtlIC8g
U2FwcGhpcmUKICAqIFJhcGlkcyAoaS5lLiBDb3JlcyBwcmlvciB0byBHb2xk
ZW4gQ292ZSBhbmQvb3IgR3JhY2Vtb250KS4KQEAgLTY2LDEyICs3MSwxNCBA
QCBGVU5DKGNsZWFyX2JoYl9sb29wcykKICAgICAgICAgam1wICAgICA1Zgog
ICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAgICAgIC5i
YWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtICguTHIxIC0gMWYpLCAw
eGNjCiAxOiAgICAgIGNhbGwgICAgMmYKLSAgICAgICAgcmV0CisuTHIxOiAg
IHJldAogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAg
ICAgIC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtIDE4IC8qICgu
THIyIC0gMmYpIGJ1dCBDbGFuZyBJQVMgZG9lc24ndCBsaWtlIHRoaXMgKi8s
IDB4Y2MKIDI6ICAgICAgQUxURVJOQVRJVkUgIm1vdiAkNSwgJWVheCIsICJt
b3YgJDcsICVlYXgiLCBYODZfU1BFQ19CSEJfTE9PUFNfTE9ORwogCiAzOiAg
ICAgIGptcCAgICAgNGYKQEAgLTgzLDcgKzkwLDcgQEAgRlVOQyhjbGVhcl9i
aGJfbG9vcHMpCiAgICAgICAgIHN1YiAgICAgJDEsICVlY3gKICAgICAgICAg
am56ICAgICAxYgogCi0gICAgICAgIHJldAorLkxyMjogICByZXQKIDU6CiAg
ICAgICAgIC8qCiAgICAgICAgICAqIFRoZSBJbnRlbCBzZXF1ZW5jZSBoYXMg
YW4gTEZFTkNFIGhlcmUuICBUaGUgcHVycG9zZSBpcyB0byBlbnN1cmUK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-05.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-05.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3N0dWJzOiBJbnRyb2R1Y2UgcGxhY2VfcmV0KCkg
dG8gYWJzdHJhY3QgYXdheSByYXcgMHhjMydzCgpUaGUgSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5z
IHRoYXQgaW5kaXJlY3QKYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUg
dW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0IGhhbGYgb2YgYSBjYWNoZWxpbmUu
ClRoaXMgbWVhbnMgaXQncyBub3Qgc2FmZSBmb3IgbG9naWMgdXNpbmcgdGhl
IHN0dWJzIHRvIHdyaXRlIHJhdyAweGMzJ3MuCgpJbnRyb2R1Y2UgcGxhY2Vf
cmV0KCkgd2hpY2gsIGZvciBub3csIHdyaXRlcyBhIHJhdyAweGMzIGJ1dCB3
aWxsIGNvbnRhaW4KYWRkaXRpb25hbCBsb2dpYyB3aGVuIHJldHVybiB0aHVu
a3MgYXJlIGluIHVzZS4KCnN0dWJfc2VsZnRlc3QoKSBkb2Vzbid0IHN0cmlj
dGx5IG5lZWQgdG8gYmUgY29udmVydGVkIGFzIHRoZXkgb25seSBydW4gb24K
Ym9vdCwgYnV0IGRvaW5nIHNvIGdldHMgdXMgYSBwYXJ0aWFsIHRlc3Qgb2Yg
cGxhY2VfcmV0KCkgdG9vLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ2OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQt
b2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu
Y29tPgpSZXZpZXdlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvdG9vbHMvdGVzdHMveDg2X2Vt
dWxhdG9yL3g4Ni1lbXVsYXRlLmggYi90b29scy90ZXN0cy94ODZfZW11bGF0
b3IveDg2LWVtdWxhdGUuaAppbmRleCA5MjljMWE3MmFlODguLjRjMjkyYWMz
MzhmNiAxMDA2NDQKLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKKysrIGIvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKQEAgLTc3LDYgKzc3LDEyIEBACiAKICNkZWZpbmUgaXNf
Y2Fub25pY2FsX2FkZHJlc3MoeCkgKCgoaW50NjRfdCkoeCkgPj4gNDcpID09
ICgoaW50NjRfdCkoeCkgPj4gNjMpKQogCitzdGF0aWMgaW5saW5lIHZvaWQg
KnBsYWNlX3JldCh2b2lkICpwdHIpCit7CisgICAgKih1aW50OF90ICopcHRy
ID0gMHhjMzsKKyAgICByZXR1cm4gcHRyICsgMTsKK30KKwogZXh0ZXJuIHVp
bnQzMl90IG14Y3NyX21hc2s7CiBleHRlcm4gc3RydWN0IGNwdV9wb2xpY3kg
Y3B1X3BvbGljeTsKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L01ha2Vm
aWxlIGIveGVuL2FyY2gveDg2L01ha2VmaWxlCmluZGV4IDBkZWQ2OGQwNjk1
OC4uMDJhYjIzNWRlN2ZmIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvTWFr
ZWZpbGUKKysrIGIveGVuL2FyY2gveDg2L01ha2VmaWxlCkBAIC0xMSw5ICsx
MSw3IEBAIG9iai0kKENPTkZJR19QVikgKz0gcHYvCiBvYmoteSArPSB4ODZf
NjQvCiBvYmoteSArPSB4ODZfZW11bGF0ZS8KIAotYWx0ZXJuYXRpdmUteSA6
PSBhbHRlcm5hdGl2ZS5pbml0Lm8KLWFsdGVybmF0aXZlLSQoQ09ORklHX0xJ
VkVQQVRDSCkgOj0KLW9iai1iaW4teSArPSAkKGFsdGVybmF0aXZlLXkpCitv
YmoteSArPSBhbHRlcm5hdGl2ZS5vCiBvYmoteSArPSBhcGljLm8KIG9iai15
ICs9IGJoYi10aHVuay5vCiBvYmoteSArPSBiaXRvcHMubwpAQCAtNDEsNyAr
MzksNyBAQCBvYmoteSArPSBoeXBlcmNhbGwubwogb2JqLXkgKz0gaTM4Ny5v
CiBvYmoteSArPSBpODI1OS5vCiBvYmoteSArPSBpb19hcGljLm8KLW9iai0k
KENPTkZJR19MSVZFUEFUQ0gpICs9IGFsdGVybmF0aXZlLm8gbGl2ZXBhdGNo
Lm8KK29iai0kKENPTkZJR19MSVZFUEFUQ0gpICs9IGxpdmVwYXRjaC5vCiBv
YmoteSArPSBtc2kubwogb2JqLXkgKz0gbXNyLm8KIG9iai0kKENPTkZJR19J
TkRJUkVDVF9USFVOSykgKz0gaW5kaXJlY3QtdGh1bmsubwpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94ODYv
YWx0ZXJuYXRpdmUuYwppbmRleCA4OGM5MDA0NGMyMGQuLmVjNDUxZDk2MmMx
MCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKKysr
IGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTEzNyw2ICsxMzcs
MjAgQEAgdm9pZCBpbml0X29yX2xpdmVwYXRjaCBhZGRfbm9wcyh2b2lkICpp
bnNucywgdW5zaWduZWQgaW50IGxlbikKICAgICB9CiB9CiAKKy8qCisgKiBQ
bGFjZSBhIHJldHVybiBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGluIHRoZSB3
cml0YWJsZSBhbGlhcyBvZiBhIHN0dWIuCisgKgorICogUmV0dXJucyB0aGUg
bmV4dCBwb3NpdGlvbiB0byB3cml0ZSBpbnRvIHRoZSBzdHViLgorICovCit2
b2lkICpwbGFjZV9yZXQodm9pZCAqcHRyKQoreworICAgIHVpbnQ4X3QgKnAg
PSBwdHI7CisKKyAgICAqcCsrID0gMHhjMzsKKworICAgIHJldHVybiBwOwor
fQorCiAvKgogICogdGV4dF9wb2tlIC0gVXBkYXRlIGluc3RydWN0aW9ucyBv
biBhIGxpdmUga2VybmVsIG9yIG5vbi1leGVjdXRlZCBjb2RlLgogICogQGFk
ZHI6IGFkZHJlc3MgdG8gbW9kaWZ5CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvZXh0YWJsZS5jIGIveGVuL2FyY2gveDg2L2V4dGFibGUuYwppbmRleCA3
MDVjZjllYjk0Y2EuLjE1NzJlZmE2OWEwMCAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2V4dGFibGUuYworKysgYi94ZW4vYXJjaC94ODYvZXh0YWJsZS5j
CkBAIC0xNTEsMjAgKzE1MSwyMCBAQCBzZWFyY2hfZXhjZXB0aW9uX3RhYmxl
KGNvbnN0IHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzLCB1bnNpZ25lZCBs
b25nICpzdHViX3JhKQogaW50IF9faW5pdCBjZl9jaGVjayBzdHViX3NlbGZ0
ZXN0KHZvaWQpCiB7CiAgICAgc3RhdGljIGNvbnN0IHN0cnVjdCB7Ci0gICAg
ICAgIHVpbnQ4X3Qgb3BjWzhdOworICAgICAgICB1aW50OF90IG9wY1s3XTsK
ICAgICAgICAgdWludDY0X3QgcmF4OwogICAgICAgICB1bmlvbiBzdHViX2V4
Y2VwdGlvbl90b2tlbiByZXM7CiAgICAgfSB0ZXN0c1tdIF9faW5pdGNvbnN0
ID0gewogI2RlZmluZSBlbmRicjY0IDB4ZjMsIDB4MGYsIDB4MWUsIDB4ZmEK
LSAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDBmLCAweGI5LCAweGMz
LCAweGMzIH0sIC8qIHVkMSAqLworICAgICAgICB7IC5vcGMgPSB7IGVuZGJy
NjQsIDB4MGYsIDB4YjksIDB4OTAgfSwgLyogdWQxICovCiAgICAgICAgICAg
LnJlcy5maWVsZHMudHJhcG5yID0gWDg2X0VYQ19VRCB9LAotICAgICAgICB7
IC5vcGMgPSB7IGVuZGJyNjQsIDB4OTAsIDB4MDIsIDB4MDAsIDB4YzMgfSwg
Lyogbm9wOyBhZGQgKCVyYXgpLCVhbCAqLworICAgICAgICB7IC5vcGMgPSB7
IGVuZGJyNjQsIDB4OTAsIDB4MDIsIDB4MDAgfSwgLyogbm9wOyBhZGQgKCVy
YXgpLCVhbCAqLwogICAgICAgICAgIC5yYXggPSAweDAxMjM0NTY3ODlhYmNk
ZWYsCiAgICAgICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0gWDg2X0VYQ19H
UCB9LAotICAgICAgICB7IC5vcGMgPSB7IGVuZGJyNjQsIDB4MDIsIDB4MDQs
IDB4MDQsIDB4YzMgfSwgLyogYWRkICglcnNwLCVyYXgpLCVhbCAqLworICAg
ICAgICB7IC5vcGMgPSB7IGVuZGJyNjQsIDB4MDIsIDB4MDQsIDB4MDQgfSwg
LyogYWRkICglcnNwLCVyYXgpLCVhbCAqLwogICAgICAgICAgIC5yYXggPSAw
eGZlZGNiYTk4NzY1NDMyMTBVTCwKICAgICAgICAgICAucmVzLmZpZWxkcy50
cmFwbnIgPSBYODZfRVhDX1NTIH0sCi0gICAgICAgIHsgLm9wYyA9IHsgZW5k
YnI2NCwgMHhjYywgMHhjMywgMHhjMywgMHhjMyB9LCAvKiBpbnQzICovCisg
ICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwgMHhjYywgMHg5MCwgMHg5MCB9
LCAvKiBpbnQzICovCiAgICAgICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0g
WDg2X0VYQ19CUCB9LAogI3VuZGVmIGVuZGJyNjQKICAgICB9OwpAQCAtMTgz
LDYgKzE4Myw3IEBAIGludCBfX2luaXQgY2ZfY2hlY2sgc3R1Yl9zZWxmdGVz
dCh2b2lkKQogCiAgICAgICAgIG1lbXNldChwdHIsIDB4Y2MsIFNUVUJfQlVG
X1NJWkUgLyAyKTsKICAgICAgICAgbWVtY3B5KHB0ciwgdGVzdHNbaV0ub3Bj
LCBBUlJBWV9TSVpFKHRlc3RzW2ldLm9wYykpOworICAgICAgICBwbGFjZV9y
ZXQocHRyICsgQVJSQVlfU0laRSh0ZXN0c1tpXS5vcGMpKTsKICAgICAgICAg
dW5tYXBfZG9tYWluX3BhZ2UocHRyKTsKIAogICAgICAgICBhc20gdm9sYXRp
bGUgKCAiSU5ESVJFQ1RfQ0FMTCAlW3N0Yl1cbiIKZGlmZiAtLWdpdCBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oIGIveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmgKaW5kZXggZWY2M2Uy
NTdhZDc4Li4yOGQ0ZWMwZjljNGEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCisrKyBiL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCkBAIC0zMSw2ICszMSw4IEBA
IHN0cnVjdCBfX3BhY2tlZCBhbHRfaW5zdHIgewogI2RlZmluZSBBTFRfUkVQ
TF9QVFIoYSkgICAgIF9fQUxUX1BUUihhLCByZXBsX29mZnNldCkKIAogZXh0
ZXJuIHZvaWQgYWRkX25vcHModm9pZCAqaW5zbnMsIHVuc2lnbmVkIGludCBs
ZW4pOwordm9pZCAqcGxhY2VfcmV0KHZvaWQgKnB0cik7CisKIC8qIFNpbWls
YXIgdG8gYWx0ZXJuYXRpdmVfaW5zdHJ1Y3Rpb25zIGV4Y2VwdCBpdCBjYW4g
YmUgcnVuIHdpdGggSVJRcyBlbmFibGVkLiAqLwogZXh0ZXJuIGludCBhcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsIHN0cnVj
dCBhbHRfaW5zdHIgKmVuZCk7CiBleHRlcm4gdm9pZCBhbHRlcm5hdGl2ZV9p
bnN0cnVjdGlvbnModm9pZCk7CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
cHYvZW11bC1wcml2LW9wLmMgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2
LW9wLmMKaW5kZXggNzAxNTBjMjcyMjc2Li5mZjVkMWM5Zjg2MzQgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXByaXYtb3AuYworKysgYi94
ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMKQEAgLTc2LDcgKzc2LDYg
QEAgc3RhdGljIGlvX2VtdWxfc3R1Yl90ICppb19lbXVsX3N0dWJfc2V0dXAo
c3RydWN0IHByaXZfb3BfY3R4dCAqY3R4dCwgdTggb3Bjb2RlLAogICAgICAg
ICAweDQxLCAweDVjLCAvKiBwb3AgJXIxMiAgKi8KICAgICAgICAgMHg1ZCwg
ICAgICAgLyogcG9wICVyYnAgICovCiAgICAgICAgIDB4NWIsICAgICAgIC8q
IHBvcCAlcmJ4ICAqLwotICAgICAgICAweGMzLCAgICAgICAvKiByZXQgICAg
ICAgKi8KICAgICB9OwogCiAgICAgY29uc3Qgc3RydWN0IHN0dWJzICp0aGlz
X3N0dWJzID0gJnRoaXNfY3B1KHN0dWJzKTsKQEAgLTEyNiwxMSArMTI1LDEz
IEBAIHN0YXRpYyBpb19lbXVsX3N0dWJfdCAqaW9fZW11bF9zdHViX3NldHVw
KHN0cnVjdCBwcml2X29wX2N0eHQgKmN0eHQsIHU4IG9wY29kZSwKIAogICAg
IEFQUEVORF9DQUxMKHNhdmVfZ3Vlc3RfZ3Bycyk7CiAgICAgQVBQRU5EX0JV
RkYoZXBpbG9ndWUpOworICAgIHAgPSBwbGFjZV9yZXQocCk7CiAKICAgICAv
KiBCdWlsZC10aW1lIGJlc3QgZWZmb3J0IGF0dGVtcHQgdG8gY2F0Y2ggcHJv
YmxlbXMuICovCiAgICAgQlVJTERfQlVHX09OKFNUVUJfQlVGX1NJWkUgLyAy
IDwKICAgICAgICAgICAgICAgICAgKHNpemVvZihwcm9sb2d1ZSkgKyBzaXpl
b2YoZXBpbG9ndWUpICsgMTAgLyogMnggY2FsbCAqLyArCi0gICAgICAgICAg
ICAgICAgICBNQVgoMyAvKiBkZWZhdWx0IHN0dWIgKi8sIElPRU1VTF9RVUlS
S19TVFVCX0JZVEVTKSkpOworICAgICAgICAgICAgICAgICAgTUFYKDMgLyog
ZGVmYXVsdCBzdHViICovLCBJT0VNVUxfUVVJUktfU1RVQl9CWVRFUykgKwor
ICAgICAgICAgICAgICAgICAgMSAvKiByZXQgKi8pKTsKICAgICAvKiBSdW50
aW1lIGNvbmZpcm1hdGlvbiB0aGF0IHdlIGhhdmVuJ3QgY2xvYmJlcmVkIGFu
IGFkamFjZW50IHN0dWIuICovCiAgICAgQlVHX09OKFNUVUJfQlVGX1NJWkUg
LyAyIDwgKHAgLSBjdHh0LT5pb19lbXVsX3N0dWIpKTsKIApkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL2ZwdS5jIGIveGVuL2FyY2gv
eDg2L3g4Nl9lbXVsYXRlL2ZwdS5jCmluZGV4IDU0Yzg2MjE0MjFjNi4uOWNj
MzdhMWQ4ZTNjIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYveDg2X2VtdWxh
dGUvZnB1LmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL2ZwdS5j
CkBAIC0zMiwzNiArMzIsNDIgQEAgc3RhdGljIGlubGluZSBib29sIGZwdV9j
aGVja193cml0ZSh2b2lkKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25f
bWVtZHN0KG9wYywgZXh0LCBhcmcpICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAq
X3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgLyogTW9kUk06IG1vZD0wLCByZWc9
ZXh0LCBybT0wLCBpLmUuIGEgKCVyYXgpIG9wZXJhbmQgKi8gICAgICAgICAg
ICBcCiAgICAgKmluc25fYnl0ZXMgPSAyOyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWludDhfdFtdKXsg
b3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsgICAgICAgICAg
ICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9wYywgKChleHQp
ICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisgICAgcGxhY2Vf
cmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAi
K20iIChhcmcpIDogImEiICgmKGFyZykpKTsgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9IHdoaWxlICgw
KQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fbWVtc3JjKG9wYywgZXh0
LCBhcmcpICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBkbyB7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBnZXRfc3R1Yihz
dHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgLyogTW9kUk06IG1vZD0wLCByZWc9ZXh0LCBybT0wLCBpLmUu
IGEgKCVyYXgpIG9wZXJhbmQgKi8gICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWludDhfdFtdKXsg
b3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsgICAgICAgICAg
ICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9wYywgKChleHQp
ICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisgICAgcGxhY2Vf
cmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAi
PW0iIChkdW1teSkgOiAibSIgKGFyZyksICJhIiAoJihhcmcpKSk7ICAgICAg
ICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9IHdoaWxlICgw
KQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fc3R1YihieXRlcy4uLikg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBkbyB7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBnZXRfc3R1Yihz
dHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgdW5zaWduZWQgaW50IG5yXyA9IHNpemVvZigodWludDhfdFtd
KXsgYnl0ZXMgfSk7ICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVzLCAweGMzIH0p
LCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3Rb
XSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAgICAgICAgICAg
ICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tl
X3N0dWIoIiIsICIiLCAiPW0iIChkdW1teSkgOiAiaSIgKDApKTsgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiB9IHdoaWxlICgwKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25f
c3R1Yl9lZmxhZ3MoYnl0ZXMuLi4pICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAq
X3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgdW5zaWduZWQgaW50IG5yXyA9IHNp
emVvZigodWludDhfdFtdKXsgYnl0ZXMgfSk7ICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgdW5zaWduZWQgbG9uZyB0bXBfOyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVzLCAweGMzIH0p
LCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3Rb
XSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAgICAgICAgICAg
ICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tl
X3N0dWIoX1BSRV9FRkxBR1MoIltlZmxhZ3NdIiwgIlttYXNrXSIsICJbdG1w
XSIpLCAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgX1BPU1RfRUZM
QUdTKCJbZWZsYWdzXSIsICJbbWFza10iLCAiW3RtcF0iKSwgICAgICAgICAg
ICBcCiAgICAgICAgICAgICAgICAgW2VmbGFnc10gIitnIiAocmVncy0+ZWZs
YWdzKSwgW3RtcF0gIj0mciIgKHRtcF8pICAgICAgICBcCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYyBiL3hl
bi9hcmNoL3g4Ni94ODZfZW11bGF0ZS94ODZfZW11bGF0ZS5jCmluZGV4IGU4
Y2JhNWEyN2Y1Ni4uYTZhMWM5OTM3ZjVkIDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYworKysgYi94ZW4vYXJj
aC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYwpAQCAtMTM5OCw3ICsx
Mzk4LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHN0YlszXSA9IDB4OTE7
CiAgICAgICAgIHN0Yls0XSA9IGV2ZXgub3Btc2sgPDwgMzsKICAgICAgICAg
aW5zbl9ieXRlcyA9IDU7Ci0gICAgICAgIHN0Yls1XSA9IDB4YzM7CisgICAg
ICAgIHBsYWNlX3JldCgmc3RiWzVdKTsKIAogICAgICAgICBpbnZva2Vfc3R1
YigiIiwgIiIsICIrbSIgKG9wX21hc2spIDogImEiICgmb3BfbWFzaykpOwog
CkBAIC0zNjMxLDcgKzM2MzEsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAg
fQogICAgICAgICBvcGNbMV0gPSAobW9kcm0gJiAweDM4KSB8IDB4YzA7CiAg
ICAgICAgIGluc25fYnl0ZXMgPSBFVkVYX1BGWF9CWVRFUyArIDI7Ci0gICAg
ICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJd
KTsKIAogICAgICAgICBjb3B5X0VWRVgob3BjLCBldmV4KTsKICAgICAgICAg
aW52b2tlX3N0dWIoIiIsICIiLCAiPWciIChkdW1teSkgOiAiYSIgKHNyYy52
YWwpKTsKQEAgLTM2OTgsNyArMzY5OCw3IEBAIHg4Nl9lbXVsYXRlKAogICAg
ICAgICAgICAgaW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDI7CiAgICAgICAg
ICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2ZXgpOwogICAg
ICAgICB9Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNl
X3JldCgmb3BjWzJdKTsKIAogICAgICAgICBlYS5yZWcgPSBkZWNvZGVfZ3By
KCZfcmVncywgbW9kcm1fcmVnKTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIs
ICIiLCAiPWEiICgqZWEucmVnKSA6ICJjIiAobW12YWxwKSwgIm0iICgqbW12
YWxwKSk7CkBAIC0zNzcyLDcgKzM3NzIsNyBAQCB4ODZfZW11bGF0ZSgKICAg
ICAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwogICAgICAg
ICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3ByZWZpeCwgdmV4KTsKICAg
ICAgICAgfQotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFj
ZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgX3JlZ3MuZWZsYWdzICY9IH5F
RkxBR1NfTUFTSzsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsCkBAIC00MDA4
LDcgKzQwMDgsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgb3BjWzFdID0g
bW9kcm0gJiAweGM3OwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVT
ICsgMjsKICAgICBzaW1kXzBmX3RvX2dwcjoKLSAgICAgICAgb3BjW2luc25f
Ynl0ZXMgLSBQRlhfQllURVNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0
KCZvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10pOwogCiAgICAgICAgIGdl
bmVyYXRlX2V4Y2VwdGlvbl9pZihlYS50eXBlICE9IE9QX1JFRywgWDg2X0VY
Q19VRCk7CiAKQEAgLTQ0MDUsNyArNDQwNSw3IEBAIHg4Nl9lbXVsYXRlKAog
ICAgICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2Ry
bSAmIDB4Mzg7CiAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAy
OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQo
Jm9wY1syXSk7CiAKICAgICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3By
ZWZpeCwgdmV4KTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiK20i
IChzcmMudmFsKSA6ICJhIiAoJnNyYy52YWwpKTsKQEAgLTQ0NDIsNyArNDQ0
Miw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAgZXZleC53ID0gMDsK
ICAgICAgICAgb3BjWzFdID0gbW9kcm0gJiAweDM4OwogICAgICAgICBpbnNu
X2J5dGVzID0gRVZFWF9QRlhfQllURVMgKyAyOwotICAgICAgICBvcGNbMl0g
PSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAg
ICAgY29weV9FVkVYKG9wYywgZXZleCk7CiAgICAgICAgIGludm9rZV9zdHVi
KCIiLCAiIiwgIittIiAoc3JjLnZhbCkgOiAiYSIgKCZzcmMudmFsKSk7CkBA
IC00NjM3LDcgKzQ2MzcsNyBAQCB4ODZfZW11bGF0ZSgKICNlbmRpZiAvKiBY
ODZFTVVMX05PX1NJTUQgKi8KIAogICAgIHNpbWRfMGZfcmVnX29ubHk6Ci0g
ICAgICAgIG9wY1tpbnNuX2J5dGVzIC0gUEZYX0JZVEVTXSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjW2luc25fYnl0ZXMgLSBQRlhfQllURVNd
KTsKIAogICAgICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2
ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsIFtkdW1teV9vdXRd
ICI9ZyIgKGR1bW15KSA6IFtkdW1teV9pbl0gImkiICgwKSApOwpAQCAtNDk3
MSw3ICs0OTcxLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIGlmICggIW1v
ZGVfNjRiaXQoKSApCiAgICAgICAgICAgICB2ZXgudyA9IDA7CiAgICAgICAg
IG9wY1sxXSA9IG1vZHJtICYgMHhmODsKLSAgICAgICAgb3BjWzJdID0gMHhj
MzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNv
cHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAgZWEucmVnID0gZGVjb2RlX2dw
cigmX3JlZ3MsIG1vZHJtX3JtKTsKQEAgLTUwMTQsNyArNTAxNCw3IEBAIHg4
Nl9lbXVsYXRlKAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0KCkgKQogICAg
ICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2RybSAm
IDB4Yzc7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNl
X3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X1ZFWChvcGMsIHZleCk7
CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1hIiAoZHN0LnZhbCkg
OiBbZHVtbXldICJpIiAoMCkpOwpAQCAtNTA0NCw3ICs1MDQ0LDcgQEAgeDg2
X2VtdWxhdGUoCiAgICAgICAgIG9wYyA9IGluaXRfcHJlZml4ZXMoc3R1Yik7
CiAgICAgICAgIG9wY1swXSA9IGI7CiAgICAgICAgIG9wY1sxXSA9IG1vZHJt
OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQo
Jm9wY1syXSk7CiAKICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAg
ICAgICBfcmVncy5lZmxhZ3MgJj0gfkVGTEFHU19NQVNLOwpAQCAtNTYxMiw3
ICs1NjEyLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIGlmICggIW1vZGVf
NjRiaXQoKSApCiAgICAgICAgICAgICB2ZXgudyA9IDA7CiAgICAgICAgIG9w
Y1sxXSA9IG1vZHJtICYgMHhjNzsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
UkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIGludm9r
ZV9zdHViKCIiLCAiIiwgIj1hIiAoZWEudmFsKSA6IFtkdW1teV0gImkiICgw
KSk7CkBAIC01NzMwLDcgKzU3MzAsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAg
ICAgICAgIG9wY1sxXSAmPSAweDM4OwogICAgICAgICB9CiAgICAgICAgIGlu
c25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwotICAgICAgICBvcGNbMl0gPSAw
eGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAgICAgICAgIGlm
ICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQogICAgICAgICB7CiAgICAgICAg
ICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJlZml4IGJ5dGUuICovCkBAIC02
MDEwLDcgKzYwMTAsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+
YiA9ICFtb2RlXzY0Yml0KCkgfHwgKHZleC5yZWcgPj4gMyk7CiAgICAgICAg
IG9wY1sxXSA9IDB4YzAgfCAofnZleC5yZWcgJiA3KTsKICAgICAgICAgcHZl
eC0+cmVnID0gMHhmOwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAg
ICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIo
IiIsICIiLCAiPWEiIChlYS52YWwpIDogW2R1bW15XSAiaSIgKDApKTsKICAg
ICAgICAgcHV0X3N0dWIoc3R1Yik7CkBAIC02Mjg0LDcgKzYyODQsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgICAgIGV2ZXgudyA9IDA7CiAgICAgICAg
IG9wY1sxXSA9IG1vZHJtICYgMHhmODsKICAgICAgICAgaW5zbl9ieXRlcyA9
IEVWRVhfUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
RVZFWChvcGMsIGV2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIs
ICI9ZyIgKGR1bW15KSA6ICJhIiAoc3JjLnZhbCkpOwpAQCAtNjM4Myw3ICs2
MzgzLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHB2ZXgtPmIgPSAxOwog
ICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAgICAg
ICAgcHZleC0+cmVnID0gMHhmOwotICAgICAgICBvcGNbMl0gPSAweGMzOwor
ICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgaW52b2tl
X3N0dWIoIiIsICIiLCAiPW0iICgqbW12YWxwKSA6ICJhIiAobW12YWxwKSk7
CiAKQEAgLTY0NTMsNyArNjQ1Myw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAg
ICBwdmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJtX3JlZyAm
IDcpIDw8IDM7CiAgICAgICAgIHB2ZXgtPnJlZyA9IDB4ZjsKLSAgICAgICAg
b3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwog
CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAoKm1tdmFscCkg
OiAiYSIgKG1tdmFscCkpOwogCkBAIC02NTA5LDcgKzY1MDksNyBAQCB4ODZf
ZW11bGF0ZSgKICAgICAgICAgcGV2ZXgtPmIgPSAxOwogICAgICAgICBvcGNb
MV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAgICAgICAgcGV2ZXgtPlJY
ID0gMTsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2Vf
cmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwg
Ij1tIiAoKm1tdmFscCkgOiAiYSIgKG1tdmFscCkpOwogCkBAIC02NTc0LDcg
KzY1NzQsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcGV2ZXgtPmIgPSAx
OwogICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAg
ICAgICAgcGV2ZXgtPlJYID0gMTsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9r
ZV9zdHViKCIiLCAiIiwgIittIiAoKm1tdmFscCkgOiAiYSIgKG1tdmFscCkp
OwogCkBAIC02NTg4LDcgKzY1ODgsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAg
ICAgb3BjWzJdID0gMHg5MDsKICAgICAgICAgLyogVXNlICglcmF4KSBhcyBz
b3VyY2UuICovCiAgICAgICAgIG9wY1szXSA9IGV2ZXgub3Btc2sgPDwgMzsK
LSAgICAgICAgb3BjWzRdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbNF0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAo
b3BfbWFzaykgOiAiYSIgKCZvcF9tYXNrKSk7CiAgICAgICAgIHB1dF9zdHVi
KHN0dWIpOwpAQCAtNjY2NCw3ICs2NjY0LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIHBldmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJt
X3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0gICAg
ICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJd
KTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKCptbXZh
bHApIDogImEiIChtbXZhbHApKTsKIApAQCAtNjc0MSw3ICs2NzQxLDcgQEAg
eDg2X2VtdWxhdGUoCiAgICAgICAgIG9wY1syXSA9IDB4OTA7CiAgICAgICAg
IC8qIFVzZSAoJXJheCkgYXMgc291cmNlLiAqLwogICAgICAgICBvcGNbM10g
PSBldmV4Lm9wbXNrIDw8IDM7Ci0gICAgICAgIG9wY1s0XSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjWzRdKTsKIAogICAgICAgICBpbnZva2Vf
c3R1YigiIiwgIiIsICIrbSIgKG9wX21hc2spIDogImEiICgmb3BfbWFzaykp
OwogICAgICAgICBwdXRfc3R1YihzdHViKTsKQEAgLTY5NDAsNyArNjk0MCw3
IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBwdmV4LT5yZWcgPSAweGY7IC8q
IHJBWCAqLwogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZbNF0g
PSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVm
WzVdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAg
ICAgICAgIHNyYy5yZWcgPSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3Jl
Z3MsIGN0eHQpOwogICAgICAgICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0mYyIg
KGRzdC52YWwpLCAiW2RzdF0iICgmc3JjLnZhbCksICJhIiAoKnNyYy5yZWcp
KTsKQEAgLTY5NzYsNyArNjk3Niw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAg
ICBwdmV4LT5yZWcgPSAweGY7IC8qIHJBWCAqLwogICAgICAgICBidWZbM10g
PSBiOwogICAgICAgICBidWZbNF0gPSAobW9kcm0gJiAweDM4KSB8IDB4MDE7
IC8qIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgIGRzdC5yZWcg
PSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3JlZ3MsIGN0eHQpOwogICAg
ICAgICBlbXVsYXRlX3N0dWIoIj0mYSIgKGRzdC52YWwpLCAiYyIgKCZzcmMu
dmFsKSk7CkBAIC03MjE3LDcgKzcyMTcsNyBAQCB4ODZfZW11bGF0ZSgKICAg
ICAgICAgICAgIGV2ZXgudyA9IHZleC53ID0gMDsKICAgICAgICAgb3BjWzFd
ID0gbW9kcm0gJiAweDM4OwogICAgICAgICBvcGNbMl0gPSBpbW0xOwotICAg
ICAgICBvcGNbM10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1sz
XSk7CiAgICAgICAgIGlmICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQogICAg
ICAgICB7CiAgICAgICAgICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJlZml4
IGJ5dGUuICovCkBAIC03Mzg0LDcgKzczODQsNyBAQCB4ODZfZW11bGF0ZSgK
ICAgICAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAzOwogICAg
ICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAgICAgICB9Ci0gICAg
ICAgIG9wY1szXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzNd
KTsKIAogICAgICAgICAvKiBMYXRjaCBNWENTUiAtIHdlIG1heSBuZWVkIHRv
IHJlc3RvcmUgaXQgYmVsb3cuICovCiAgICAgICAgIGludm9rZV9zdHViKCJz
dG14Y3NyICVbbXhjc3JdIiwgIiIsCkBAIC03NjMwLDcgKzc2MzAsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgfQogICAgICAgICBvcGNbMl0gPSBpbW0x
OwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMzsKLSAgICAg
ICAgb3BjWzNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbM10p
OwogICAgICAgICBpZiAoIHZleC5vcGN4ID09IHZleF9ub25lICkKICAgICAg
ICAgewogICAgICAgICAgICAgLyogQ292ZXIgZm9yIGV4dHJhIHByZWZpeCBi
eXRlLiAqLwpAQCAtNzk3Niw3ICs3OTc2LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIHB4b3AtPnJlZyA9IDB4ZjsgLyogckFYICovCiAgICAgICAgIGJ1
ZlszXSA9IGI7CiAgICAgICAgIGJ1Zls0XSA9IChtb2RybSAmIDB4MzgpIHwg
MHgwMTsgLyogci9tPSglckNYKSAqLwotICAgICAgICBidWZbNV0gPSAweGMz
OworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls1XSk7CiAKICAgICAgICAgZHN0
LnJlZyA9IGRlY29kZV92ZXhfZ3ByKHZleC5yZWcsICZfcmVncywgY3R4dCk7
CiAgICAgICAgIGVtdWxhdGVfc3R1YihbZHN0XSAiPSZhIiAoZHN0LnZhbCks
ICJjIiAoJnNyYy52YWwpKTsKQEAgLTgwODUsNyArODA4NSw3IEBAIHg4Nl9l
bXVsYXRlKAogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZbNF0g
PSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KICAgICAgICAgKih1
aW50MzJfdCAqKShidWYgKyA1KSA9IGltbTE7Ci0gICAgICAgIGJ1Zls5XSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzldKTsKIAogICAgICAg
ICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0mYyIgKGRzdC52YWwpLCAiW2RzdF0i
ICgmc3JjLnZhbCkpOwogCkBAIC04MTgxLDEyICs4MTgxLDEyIEBAIHg4Nl9l
bXVsYXRlKAogCiAgICAgICAgIGlmICggZXZleF9lbmNvZGVkKCkgKQogICAg
ICAgICB7Ci0gICAgICAgICAgICBvcGNbaW5zbl9ieXRlcyAtIEVWRVhfUEZY
X0JZVEVTXSA9IDB4YzM7CisgICAgICAgICAgICBwbGFjZV9yZXQoJm9wY1tp
bnNuX2J5dGVzIC0gRVZFWF9QRlhfQllURVNdKTsKICAgICAgICAgICAgIGNv
cHlfRVZFWChvcGMsIGV2ZXgpOwogICAgICAgICB9CiAgICAgICAgIGVsc2UK
ICAgICAgICAgewotICAgICAgICAgICAgb3BjW2luc25fYnl0ZXMgLSBQRlhf
QllURVNdID0gMHhjMzsKKyAgICAgICAgICAgIHBsYWNlX3JldCgmb3BjW2lu
c25fYnl0ZXMgLSBQRlhfQllURVNdKTsKICAgICAgICAgICAgIGNvcHlfUkVY
X1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIH0KIApAQCAt
ODUxMCw3ICs4NTEwLDcgQEAgaW50IHg4Nl9lbXVsX3JtdygKICAgICAgICAg
cHZleC0+cmVnID0gMHhmOyAvKiByQVggKi8KICAgICAgICAgYnVmWzNdID0g
Y3R4dC0+b3Bjb2RlOwogICAgICAgICBidWZbNF0gPSAweDExOyAvKiByZWc9
ckRYIHIvbT0oJVJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgICplZmxhZ3Mg
Jj0gfkVGTEFHU19NQVNLOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-06.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-06.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IEJ1aWxkIFhlbiB3aXRoIFJldHVybiBUaHVua3MKClRo
ZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uIHNwZWN1bGF0aXZlIHZ1bG5l
cmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRpcmVjdApicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QgaGFsZiBv
ZiBhIGNhY2hlbGluZS4KCkluIG9yZGVyIHRvIG1pdGlnYXRlIHRoaXMsIGJ1
aWxkIHdpdGggcmV0dXJuIHRodW5rcyBhbmQgYXJyYW5nZSBmb3IKX194ODZf
cmV0dXJuX3RodW5rIHRvIGJlIChtaXMpYWxpZ25lZCBpbiB0aGUgc2FtZSBt
YW5uZXIgYXMKX194ODZfaW5kaXJlY3RfdGh1bmtfKiBzbyB0aGUgUkVUIGlu
c3RydWN0aW9uIGlzIHBsYWNlZCBpbiBhIHNhZmUgbG9jYXRpb24uCgpwbGFj
ZV9yZXQoKSBuZWVkcyB0byBjb25kaXRpb25hbGx5IGVtaXQgSk1QIF9feDg2
X3JldHVybl90aHVuayBpbnN0ZWFkIG9mIFJFVC4KClRoaXMgaXMgcGFydCBv
ZiBYU0EtNDY5IC8gQ1ZFLTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnIGIveGVu
L2FyY2gveDg2L0tjb25maWcKaW5kZXggOWNkZDA0NzIxYWZhLi45NmZkMWMz
MjcyZDEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnCisrKyBi
L3hlbi9hcmNoL3g4Ni9LY29uZmlnCkBAIC0zOCw5ICszOCwxNCBAQCBjb25m
aWcgQVJDSF9ERUZDT05GSUcKIAlkZWZhdWx0ICJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCiAKIGNvbmZpZyBDQ19IQVNfSU5ESVJFQ1Rf
VEhVTksKKwkjIEdDQyA+PSA4IG9yIENsYW5nID49IDYKIAlkZWZfYm9vbCAk
KGNjLW9wdGlvbiwtbWluZGlyZWN0LWJyYW5jaC1yZWdpc3RlcikgfHwgXAog
CSAgICAgICAgICQoY2Mtb3B0aW9uLC1tcmV0cG9saW5lLWV4dGVybmFsLXRo
dW5rKQogCitjb25maWcgQ0NfSEFTX1JFVFVSTl9USFVOSworCSMgR0NDID49
IDggb3IgQ2xhbmcgPj0gMTUKKwlkZWZfYm9vbCAkKGNjLW9wdGlvbiwtbWZ1
bmN0aW9uLXJldHVybj10aHVuay1leHRlcm4pCisKIGNvbmZpZyBIQVNfQVNf
Q0VUX1NTCiAJIyBiaW51dGlscyA+PSAyLjI5IG9yIExMVk0gPj0gNgogCWRl
Zl9ib29sICQoYXMtaW5zdHIsd3Jzc3EgJXJheCQoY29tbWEpMDtzZXRzc2Jz
eSkKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hlbi9h
cmNoL3g4Ni9NYWtlZmlsZQppbmRleCAwMmFiMjM1ZGU3ZmYuLmEwOTU0YTZh
OGMxNCAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisrKyBi
L3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtNDMsNiArNDMsNyBAQCBvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KK29iai0kKENPTkZJR19SRVRV
Uk5fVEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KIG9iai0kKENPTkZJR19Q
VikgKz0gaW9wb3J0X2VtdWxhdGUubwogb2JqLXkgKz0gaXJxLm8KIG9iai0k
KENPTkZJR19LRVhFQykgKz0gbWFjaGluZV9rZXhlYy5vCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJvdC5TIGIveGVuL2FyY2gv
eDg2L2FjcGkvd2FrZXVwX3Byb3QuUwppbmRleCBhNzQxZDU4YjkxMTcuLjky
YWY2MjMwYjMxZiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvd2Fr
ZXVwX3Byb3QuUworKysgYi94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJv
dC5TCkBAIC0xMzMsNyArMTMzLDcgQEAgTEFCRUwoczNfcmVzdW1lKQogICAg
ICAgICBwb3AgICAgICVyMTIKICAgICAgICAgcG9wICAgICAlcmJ4CiAgICAg
ICAgIHBvcCAgICAgJXJicAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBF
TkQoZG9fc3VzcGVuZF9sb3dsZXZlbCkKIAogLmRhdGEKZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jIGIveGVuL2FyY2gveDg2L2Fs
dGVybmF0aXZlLmMKaW5kZXggZWM0NTFkOTYyYzEwLi4xYjcxYWU5NTlhYmUg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCisrKyBi
L3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCkBAIC0xMzcsMTYgKzEzNyw0
NSBAQCB2b2lkIGluaXRfb3JfbGl2ZXBhdGNoIGFkZF9ub3BzKHZvaWQgKmlu
c25zLCB1bnNpZ25lZCBpbnQgbGVuKQogICAgIH0KIH0KIAordm9pZCBub2Nh
bGwgX194ODZfcmV0dXJuX3RodW5rKHZvaWQpOworCiAvKgogICogUGxhY2Ug
YSByZXR1cm4gYXQgQHB0ci4gIEBwdHIgbXVzdCBiZSBpbiB0aGUgd3JpdGFi
bGUgYWxpYXMgb2YgYSBzdHViLgogICoKKyAqIFdoZW4gQ09ORklHX1JFVFVS
Tl9USFVOSyBpcyBhY3RpdmUsIHRoaXMgbWF5IGJlIGEgSk1QIF9feDg2X3Jl
dHVybl90aHVuaworICogaW5zdGVhZCwgZGVwZW5kaW5nIG9uIHRoZSBzYWZl
dHkgb2YgQHB0ciB3aXRoIHJlc3BlY3QgdG8gSW5kaXJlY3QgVGFyZ2V0Cisg
KiBTZWxlY3Rpb24uCisgKgogICogUmV0dXJucyB0aGUgbmV4dCBwb3NpdGlv
biB0byB3cml0ZSBpbnRvIHRoZSBzdHViLgogICovCiB2b2lkICpwbGFjZV9y
ZXQodm9pZCAqcHRyKQogeworICAgIHVuc2lnbmVkIGxvbmcgYWRkciA9ICh1
bnNpZ25lZCBsb25nKXB0cjsKICAgICB1aW50OF90ICpwID0gcHRyOwogCi0g
ICAgKnArKyA9IDB4YzM7CisgICAgLyoKKyAgICAgKiBXaGVuIFJldHVybiBU
aHVua3MgYXJlIHVzZWQsIGlmIGEgUkVUIHdvdWxkIGJlIHVuc2FmZSBhdCB0
aGlzIGxvY2F0aW9uCisgICAgICogd2l0aCByZXNwZWN0IHRvIEluZGlyZWN0
IFRhcmdldCBTZWxlY3Rpb24gKGkuZS4gaWYgYWRkciBpcyBpbiB0aGUgZmly
c3QKKyAgICAgKiBoYWxmIG9mIGEgY2FjaGVsaW5lKSwgaW5zZXJ0IGEgSk1Q
IF9feDg2X3JldHVybl90aHVuayBpbnN0ZWFkLgorICAgICAqCisgICAgICog
VGhlIGRpc3BsYWNlbWVudCBuZWVkcyB0byBiZSByZWxhdGl2ZSB0byB0aGUg
ZXhlY3V0YWJsZSBhbGlhcyBvZiB0aGUKKyAgICAgKiBzdHViLCBub3QgdG8g
QHB0ciB3aGljaCBpcyB0aGUgd3JpdGVhYmxlIGFsaWFzLgorICAgICAqLwor
ICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfUkVUVVJOX1RIVU5LKSAmJiAh
KGFkZHIgJiAweDIwKSApCisgICAgeworICAgICAgICBsb25nIHN0dWJfdmEg
PSAodGhpc19jcHUoc3R1YnMuYWRkcikgJiBQQUdFX01BU0spICsgKGFkZHIg
JiB+UEFHRV9NQVNLKTsKKyAgICAgICAgbG9uZyBkaXNwID0gKGxvbmcpX194
ODZfcmV0dXJuX3RodW5rIC0gKHN0dWJfdmEgKyA1KTsKKworICAgICAgICBC
VUdfT04oKGludDMyX3QpZGlzcCAhPSBkaXNwKTsKKworICAgICAgICAqcCsr
ID0gMHhlOTsKKyAgICAgICAgKihpbnQzMl90ICopcCA9IGRpc3A7CisgICAg
ICAgIHAgKz0gNDsKKyAgICB9CisgICAgZWxzZQorICAgIHsKKyAgICAgICAg
KnArKyA9IDB4YzM7CisgICAgfQogCiAgICAgcmV0dXJuIHA7CiB9CmRpZmYg
LS1naXQgYS94ZW4vYXJjaC94ODYvYXJjaC5tayBiL3hlbi9hcmNoL3g4Ni9h
cmNoLm1rCmluZGV4IGNiNDdkNzI5OTExZS4uZWZkYmRiNjA0NWJlIDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYvYXJjaC5taworKysgYi94ZW4vYXJjaC94
ODYvYXJjaC5tawpAQCAtNDQsNiArNDQsOSBAQCBDRkxBR1MtJChDT05GSUdf
Q0NfSVNfR0NDKSArPSAtZm5vLWp1bXAtdGFibGVzCiBDRkxBR1MtJChDT05G
SUdfQ0NfSVNfQ0xBTkcpICs9IC1tcmV0cG9saW5lLWV4dGVybmFsLXRodW5r
CiBlbmRpZgogCisjIENvbXBpbGUgd2l0aCByZXR1cm4gdGh1bmsgc3VwcG9y
dCBpZiBzZWxlY3RlZC4KK0NGTEFHUy0kKENPTkZJR19SRVRVUk5fVEhVTksp
ICs9IC1tZnVuY3Rpb24tcmV0dXJuPXRodW5rLWV4dGVybgorCiAjIERpc2Fi
bGUgdGhlIGFkZGl0aW9uIG9mIGEgLm5vdGUuZ251LnByb3BlcnR5IHNlY3Rp
b24gdG8gb2JqZWN0IGZpbGVzIHdoZW4KICMgbGl2ZXBhdGNoIHN1cHBvcnQg
aXMgZW5hYmxlZC4gIFRoZSBjb250ZW50cyBvZiB0aGF0IHNlY3Rpb24gY2Fu
IGNoYW5nZQogIyBkZXBlbmRpbmcgb24gdGhlIGluc3RydWN0aW9ucyB1c2Vk
LCBhbmQgbGl2ZXBhdGNoLWJ1aWxkLXRvb2xzIGRvZXNuJ3Qga25vdwpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2JoYi10aHVuay5TIGIveGVuL2FyY2gv
eDg2L2JoYi10aHVuay5TCmluZGV4IDUyNjI1ZjRlMmMxNy4uN2Y5MjIwMWEz
Y2JiIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvYmhiLXRodW5rLlMKKysr
IGIveGVuL2FyY2gveDg2L2JoYi10aHVuay5TCkBAIC0yMyw3ICsyMyw3IEBA
IEZVTkMoY2xlYXJfYmhiX3RzeCkKIDA6ICAgICAgLmJ5dGUgMHhjNiwgMHhm
OCwgMCAgICAgICAgICAgICAvKiB4YWJvcnQgJDAgKi8KICAgICAgICAgaW50
MwogMToKLSAgICAgICAgcmV0CisgICAgICAgIFJFVAogRU5EKGNsZWFyX2Jo
Yl90c3gpCiAKIC8qCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvY2xlYXJf
cGFnZS5TIGIveGVuL2FyY2gveDg2L2NsZWFyX3BhZ2UuUwppbmRleCBkNmMw
NzZmMWQ4YmMuLmRjM2MzYzI2YmZiNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L2NsZWFyX3BhZ2UuUworKysgYi94ZW4vYXJjaC94ODYvY2xlYXJfcGFn
ZS5TCkBAIC0xLDYgKzEsOCBAQAogICAgICAgICAuZmlsZSBfX0ZJTEVfXwog
CiAjaW5jbHVkZSA8eGVuL2xpbmthZ2UuaD4KKworI2luY2x1ZGUgPGFzbS9h
c21fZGVmbnMuaD4KICNpbmNsdWRlIDxhc20vcGFnZS5oPgogCiBGVU5DKGNs
ZWFyX3BhZ2Vfc3NlMikKQEAgLTE2LDUgKzE4LDUgQEAgRlVOQyhjbGVhcl9w
YWdlX3NzZTIpCiAgICAgICAgIGpueiAgICAgMGIKIAogICAgICAgICBzZmVu
Y2UKLSAgICAgICAgcmV0CisgICAgICAgIFJFVAogRU5EKGNsZWFyX3BhZ2Vf
c3NlMikKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUyBi
L3hlbi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUwppbmRleCBjM2M0MzY1NDViYWMu
LmU0M2U1MzcwYzgxNSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2NvcHlf
cGFnZS5TCisrKyBiL3hlbi9hcmNoL3g4Ni9jb3B5X3BhZ2UuUwpAQCAtMSw2
ICsxLDggQEAKICAgICAgICAgLmZpbGUgX19GSUxFX18KIAogI2luY2x1ZGUg
PHhlbi9saW5rYWdlLmg+CisKKyNpbmNsdWRlIDxhc20vYXNtX2RlZm5zLmg+
CiAjaW5jbHVkZSA8YXNtL3BhZ2UuaD4KIAogI2RlZmluZSBzcmNfcmVnICVy
c2kKQEAgLTQxLDUgKzQzLDUgQEAgRlVOQyhjb3B5X3BhZ2Vfc3NlMikKICAg
ICAgICAgbW92bnRpICB0bXA0X3JlZywgMypXT1JEX1NJWkUoZHN0X3JlZykK
IAogICAgICAgICBzZmVuY2UKLSAgICAgICAgcmV0CisgICAgICAgIFJFVAog
RU5EKGNvcHlfcGFnZV9zc2UyKQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2
L2VmaS9jaGVjay5jIGIveGVuL2FyY2gveDg2L2VmaS9jaGVjay5jCmluZGV4
IDllNDczZmFhZDNjOS4uMjNiYTMwYWJmMzMwIDEwMDY0NAotLS0gYS94ZW4v
YXJjaC94ODYvZWZpL2NoZWNrLmMKKysrIGIveGVuL2FyY2gveDg2L2VmaS9j
aGVjay5jCkBAIC0zLDYgKzMsOSBAQCBpbnQgX19hdHRyaWJ1dGVfXygoX19t
c19hYmlfXykpIHRlc3QoaW50IGkpCiAgICAgcmV0dXJuIGk7CiB9CiAKKy8q
IEluIGNhc2UgLW1mdW5jdGlvbi1yZXR1cm4gaXMgaW4gdXNlLiAqLwordm9p
ZCBfX3g4Nl9yZXR1cm5fdGh1bmsodm9pZCkge307CisKIC8qCiAgKiBQb3B1
bGF0ZSBhbiBhcnJheSB3aXRoICJhZGRyZXNzZXMiIG9mIHJlbG9jYXRhYmxl
IGFuZCBhYnNvbHV0ZSB2YWx1ZXMuCiAgKiBUaGlzIGlzIHRvIHByb2JlIGxk
IGZvciAoYSkgZW1pdHRpbmcgYmFzZSByZWxvY2F0aW9ucyBhdCBhbGwgYW5k
IChiKSBub3QKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9hc20tZGVmbnMuaCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hc20t
ZGVmbnMuaAppbmRleCAzMmQ2YjQ0OTEwNjMuLjk3ZWJlMjEyOThhMiAxMDA2
NDQKLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1kZWZucy5o
CisrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hc20tZGVmbnMuaApA
QCAtNTgsNiArNTgsMTIgQEAKICAgICAuZW5kaWYKIC5lbmRtCiAKKyNpZmRl
ZiBDT05GSUdfUkVUVVJOX1RIVU5LCisjIGRlZmluZSBSRVQgam1wIF9feDg2
X3JldHVybl90aHVuaworI2Vsc2UKKyMgZGVmaW5lIFJFVCByZXQKKyNlbmRp
ZgorCiAjaWZkZWYgQ09ORklHX1hFTl9JQlQKICMgZGVmaW5lIEVOREJSNjQg
ZW5kYnI2NAogI2Vsc2UKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmRp
cmVjdC10aHVuay5TIGIveGVuL2FyY2gveDg2L2luZGlyZWN0LXRodW5rLlMK
aW5kZXggYzRiOTc4ZDY3YjhlLi4yNmRhZDE1ZjEyYzkgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9pbmRpcmVjdC10aHVuay5TCisrKyBiL3hlbi9hcmNo
L3g4Ni9pbmRpcmVjdC10aHVuay5TCkBAIC0xNSw2ICsxNSw4IEBACiAjdW5k
ZWYgU1lNX0FMSUdOCiAjZGVmaW5lIFNZTV9BTElHTihhbGlnbi4uLikKIAor
I2lmZGVmIENPTkZJR19JTkRJUkVDVF9USFVOSworCiAubWFjcm8gSU5EX1RI
VU5LX1JFVFBPTElORSByZWc6cmVxCiAgICAgICAgIGNhbGwgMWYKICAgICAg
ICAgaW50MwpAQCAtNjIsMyArNjQsMjUgQEAgRU5EKF9feDg2X2luZGlyZWN0
X3RodW5rX1xyZWcpCiAuaXJwIHJlZywgYXgsIGN4LCBkeCwgYngsIGJwLCBz
aSwgZGksIDgsIDksIDEwLCAxMSwgMTIsIDEzLCAxNCwgMTUKICAgICAgICAg
R0VOX0lORElSRUNUX1RIVU5LIHJlZz1yXHJlZwogLmVuZHIKKworI2VuZGlm
IC8qIENPTkZJR19JTkRJUkVDVF9USFVOSyAqLworCisjaWZkZWYgQ09ORklH
X1JFVFVSTl9USFVOSworICAgICAgICAuc2VjdGlvbiAudGV4dC5lbnRyeS5f
X3g4Nl9yZXR1cm5fdGh1bmssICJheCIsIEBwcm9nYml0cworCisgICAgICAg
IC8qCisgICAgICAgICAqIFRoZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9u
IHNwZWN1bGF0aXZlIHZ1bG5lcmFiaWxpdHkgbWVhbnMgdGhhdAorICAgICAg
ICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVkaW5nIFJFVHMpIGFyZSB1
bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QKKyAgICAgICAgICogaGFsZiBvZiBh
IGNhY2hlbGluZS4gIEFycmFuZ2UgZm9yIHRoZW0gdG8gYmUgaW4gdGhlIHNl
Y29uZCBoYWxmLgorICAgICAgICAgKgorICAgICAgICAgKiBBbGlnbiB0byA2
NCwgdGhlbiBza2lwIDMyLgorICAgICAgICAgKi8KKyAgICAgICAgLmJhbGln
biA2NAorICAgICAgICAuZmlsbCAzMiwgMSwgMHhjYworCitGVU5DKF9feDg2
X3JldHVybl90aHVuaykKKyAgICAgICAgcmV0CisgICAgICAgIGludDMgLyog
SGFsdCBzdHJhaWdodC1saW5lIHNwZWN1bGF0aW9uICovCitFTkQoX194ODZf
cmV0dXJuX3RodW5rKQorCisjZW5kaWYgLyogQ09ORklHX1JFVFVSTl9USFVO
SyAqLwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3B2L2VtdWwtcHJpdi1v
cC5jIGIveGVuL2FyY2gveDg2L3B2L2VtdWwtcHJpdi1vcC5jCmluZGV4IGZm
NWQxYzlmODYzNC4uMjk1ZDg0N2VhMjRjIDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYvcHYvZW11bC1wcml2LW9wLmMKKysrIGIveGVuL2FyY2gveDg2L3B2
L2VtdWwtcHJpdi1vcC5jCkBAIC0xMzEsNyArMTMxLDcgQEAgc3RhdGljIGlv
X2VtdWxfc3R1Yl90ICppb19lbXVsX3N0dWJfc2V0dXAoc3RydWN0IHByaXZf
b3BfY3R4dCAqY3R4dCwgdTggb3Bjb2RlLAogICAgIEJVSUxEX0JVR19PTihT
VFVCX0JVRl9TSVpFIC8gMiA8CiAgICAgICAgICAgICAgICAgIChzaXplb2Yo
cHJvbG9ndWUpICsgc2l6ZW9mKGVwaWxvZ3VlKSArIDEwIC8qIDJ4IGNhbGwg
Ki8gKwogICAgICAgICAgICAgICAgICAgTUFYKDMgLyogZGVmYXVsdCBzdHVi
ICovLCBJT0VNVUxfUVVJUktfU1RVQl9CWVRFUykgKwotICAgICAgICAgICAg
ICAgICAgMSAvKiByZXQgKi8pKTsKKyAgICAgICAgICAgICAgICAgIChJU19F
TkFCTEVEKENPTkZJR19SRVRVUk5fVEhVTkspID8gNSA6IDEpIC8qIHJldCAq
LykpOwogICAgIC8qIFJ1bnRpbWUgY29uZmlybWF0aW9uIHRoYXQgd2UgaGF2
ZW4ndCBjbG9iYmVyZWQgYW4gYWRqYWNlbnQgc3R1Yi4gKi8KICAgICBCVUdf
T04oU1RVQl9CVUZfU0laRSAvIDIgPCAocCAtIGN0eHQtPmlvX2VtdWxfc3R1
YikpOwogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRj
aC5TIGIveGVuL2FyY2gveDg2L3B2L2dwcl9zd2l0Y2guUwppbmRleCA1NDA5
YWQzYjE0NDcuLjM2MmI1ZDI0MTYyMyAxMDA2NDQKLS0tIGEveGVuL2FyY2gv
eDg2L3B2L2dwcl9zd2l0Y2guUworKysgYi94ZW4vYXJjaC94ODYvcHYvZ3By
X3N3aXRjaC5TCkBAIC0yNiw3ICsyNiw3IEBAIEZVTkMobG9hZF9ndWVzdF9n
cHJzKQogICAgICAgICBtb3ZxICBVUkVHU19yMTUoJXJkaSksICVyMTUKICAg
ICAgICAgbW92cSAgVVJFR1NfcmN4KCVyZGkpLCAlcmN4CiAgICAgICAgIG1v
dnEgIFVSRUdTX3JkaSglcmRpKSwgJXJkaQotICAgICAgICByZXQKKyAgICAg
ICAgUkVUCiBFTkQobG9hZF9ndWVzdF9ncHJzKQogCiAvKiBTYXZlIGd1ZXN0
IEdQUnMuICBQYXJhbWV0ZXIgb24gdGhlIHN0YWNrIGFib3ZlIHRoZSByZXR1
cm4gYWRkcmVzcy4gKi8KQEAgLTQ4LDUgKzQ4LDUgQEAgRlVOQyhzYXZlX2d1
ZXN0X2dwcnMpCiAgICAgICAgIG1vdnEgICVyYngsIFVSRUdTX3JieCglcmRp
KQogICAgICAgICBtb3ZxICAlcmR4LCBVUkVHU19yZHgoJXJkaSkKICAgICAg
ICAgbW92cSAgJXJjeCwgVVJFR1NfcmN4KCVyZGkpCi0gICAgICAgIHJldAor
ICAgICAgICBSRVQKIEVORChzYXZlX2d1ZXN0X2dwcnMpCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3Bl
Y19jdHJsLmMKaW5kZXggY2VkODQ3NTAwMTVjLi5mZTI3ZTgyYTQ3MDcgMTAw
NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4v
YXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTU3MSw2ICs1NzEsOSBAQCBzdGF0
aWMgdm9pZCBfX2luaXQgcHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0
aHVuaykKICNpZmRlZiBDT05GSUdfSU5ESVJFQ1RfVEhVTksKICAgICAgICAg
ICAgICAgICIgSU5ESVJFQ1RfVEhVTksiCiAjZW5kaWYKKyNpZmRlZiBDT05G
SUdfUkVUVVJOX1RIVU5LCisgICAgICAgICAgICAgICAiIFJFVFVSTl9USFVO
SyIKKyNlbmRpZgogI2lmZGVmIENPTkZJR19TSEFET1dfUEFHSU5HCiAgICAg
ICAgICAgICAgICAiIFNIQURPV19QQUdJTkciCiAjZW5kaWYKZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMgYi94ZW4v
YXJjaC94ODYveDg2XzY0L2NvbXBhdC9lbnRyeS5TCmluZGV4IDFlODc2NTJm
NGJjYi4uZDdiMzgxZWE1NDZkIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYv
eDg2XzY0L2NvbXBhdC9lbnRyeS5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZf
NjQvY29tcGF0L2VudHJ5LlMKQEAgLTE4MCw3ICsxODAsNyBAQCBGVU5DKGNy
NF9wdjMyX3Jlc3RvcmUpCiAgICAgICAgIG9yICAgIGNyNF9wdjMyX21hc2so
JXJpcCksICVyYXgKICAgICAgICAgbW92ICAgJXJheCwgJWNyNAogICAgICAg
ICBtb3YgICAlcmF4LCAoJXJjeCkKLSAgICAgICAgcmV0CisgICAgICAgIFJF
VAogMDoKICNpZm5kZWYgTkRFQlVHCiAgICAgICAgIC8qIENoZWNrIHRoYXQg
X2FsbF8gb2YgdGhlIGJpdHMgaW50ZW5kZWQgdG8gYmUgc2V0IGFjdHVhbGx5
IGFyZS4gKi8KQEAgLTE5OCw3ICsxOTgsNyBAQCBGVU5DKGNyNF9wdjMyX3Jl
c3RvcmUpCiAxOgogI2VuZGlmCiAgICAgICAgIHhvciAgICVlYXgsICVlYXgK
LSAgICAgICAgcmV0CisgICAgICAgIFJFVAogRU5EKGNyNF9wdjMyX3Jlc3Rv
cmUpCiAKIEZVTkMoY29tcGF0X3N5c2NhbGwpCkBAIC0zMjksNyArMzI5LDcg
QEAgX19VTkxJS0VMWV9FTkQoY29tcGF0X2JvdW5jZV9udWxsX3NlbGVjdG9y
KQogICAgICAgICB4b3IgICAlZWF4LCAlZWF4CiAgICAgICAgIG1vdiAgICVh
eCwgIFRSQVBCT1VOQ0VfY3MoJXJkeCkKICAgICAgICAgbW92ICAgJWFsLCAg
VFJBUEJPVU5DRV9mbGFncyglcmR4KQotICAgICAgICByZXQKKyAgICAgICAg
UkVUCiAKIC5zZWN0aW9uIC5maXh1cCwiYXgiCiAuTGZ4MTM6CmRpZmYgLS1n
aXQgYS94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMgYi94ZW4vYXJjaC94
ODYveDg2XzY0L2VudHJ5LlMKaW5kZXggNDBkMDk0ZDViMmVlLi42ZWZjNmJh
YjFlZGIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnku
UworKysgYi94ZW4vYXJjaC94ODYveDg2XzY0L2VudHJ5LlMKQEAgLTYwNCw3
ICs2MDQsNyBAQCBfX1VOTElLRUxZX0VORChjcmVhdGVfYm91bmNlX2ZyYW1l
X2JhZF9ib3VuY2VfaXApCiAgICAgICAgIHhvciAgICVlYXgsICVlYXgKICAg
ICAgICAgbW92ICAgJXJheCwgVFJBUEJPVU5DRV9laXAoJXJkeCkKICAgICAg
ICAgbW92ICAgJWFsLCAgVFJBUEJPVU5DRV9mbGFncyglcmR4KQotICAgICAg
ICByZXQKKyAgICAgICAgUkVUCiAKICAgICAgICAgLnB1c2hzZWN0aW9uIC5m
aXh1cCwgImF4IiwgQHByb2diaXRzCiAgICAgICAgICMgTnVtZXJpYyB0YWdz
IGJlbG93IHJlcHJlc2VudCB0aGUgaW50ZW5kZWQgb3ZlcmFsbCAlcnNpIGFk
anVzdG1lbnQuCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYveGVuLmxkcy5T
IGIveGVuL2FyY2gveDg2L3hlbi5sZHMuUwppbmRleCA0MjIxN2VhZjI0ODUu
LmU2YzcxYThlM2UyMSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3hlbi5s
ZHMuUworKysgYi94ZW4vYXJjaC94ODYveGVuLmxkcy5TCkBAIC04Myw2ICs4
Myw3IEBAIFNFQ1RJT05TCiAgICAgICAgLiA9IEFMSUdOKFBBR0VfU0laRSk7
CiAgICAgICAgX3N0ZXh0ZW50cnkgPSAuOwogICAgICAgICooLnRleHQuZW50
cnkpCisgICAgICAgKigudGV4dC5lbnRyeS4qKQogICAgICAgIC4gPSBBTElH
TihQQUdFX1NJWkUpOwogICAgICAgIF9ldGV4dGVudHJ5ID0gLjsKIApkaWZm
IC0tZ2l0IGEveGVuL2NvbW1vbi9LY29uZmlnIGIveGVuL2NvbW1vbi9LY29u
ZmlnCmluZGV4IDYxNjYzMjdmNGQxNC4uN2Q5NDQyZWMwNWMxIDEwMDY0NAot
LS0gYS94ZW4vY29tbW9uL0tjb25maWcKKysrIGIveGVuL2NvbW1vbi9LY29u
ZmlnCkBAIC0xMzYsNiArMTM2LDE3IEBAIGNvbmZpZyBJTkRJUkVDVF9USFVO
SwogCSAgV2hlbiBlbmFibGVkLCBpbmRpcmVjdCBicmFuY2hlcyBhcmUgaW1w
bGVtZW50ZWQgdXNpbmcgYSBuZXcgY29uc3RydWN0CiAJICBjYWxsZWQgInJl
dHBvbGluZSIgdGhhdCBwcmV2ZW50cyBzcGVjdWxhdGlvbi4KIAorY29uZmln
IFJFVFVSTl9USFVOSworCWJvb2wgIk91dC1vZi1saW5lIFJldHVybnMiCisJ
ZGVwZW5kcyBvbiBDQ19IQVNfUkVUVVJOX1RIVU5LCisJZGVmYXVsdCBJTkRJ
UkVDVF9USFVOSworCWhlbHAKKwkgIENvbXBpbGUgWGVuIHdpdGggb3V0LW9m
LWxpbmUgcmV0dXJucy4KKworCSAgVGhpcyBhbGxvd3MgWGVuIHRvIG1pdGln
YXRlIGEgdmFyaWV0eSBvZiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXRpZXMK
KwkgIGJ5IGNob29zaW5nIGEgaGFyZHdhcmUtZGVwZW5kZW50IGluc3RydWN0
aW9uIHNlcXVlbmNlIHRvIGltcGxlbWVudAorCSAgZnVuY3Rpb24gcmV0dXJu
cyBzYWZlbHkuCisKIGNvbmZpZyBTUEVDVUxBVElWRV9IQVJERU5fQVJSQVkK
IAlib29sICJTcGVjdWxhdGl2ZSBBcnJheSBIYXJkZW5pbmciCiAJZGVmYXVs
dCB5CmRpZmYgLS1naXQgYS94ZW4vbGliL3g4Ni1nZW5lcmljLWh3ZWlnaHRs
LmMgYi94ZW4vbGliL3g4Ni1nZW5lcmljLWh3ZWlnaHRsLmMKaW5kZXggMTIz
YTViNDM5MjhkLi4xY2FiNjg5NTJhNDIgMTAwNjQ0Ci0tLSBhL3hlbi9saWIv
eDg2LWdlbmVyaWMtaHdlaWdodGwuYworKysgYi94ZW4vbGliL3g4Ni1nZW5l
cmljLWh3ZWlnaHRsLmMKQEAgLTUxLDcgKzUxLDExIEBAIGFzbSAoCiAgICAg
InBvcCAgICAlcmR4XG5cdCIKICAgICAicG9wICAgICVyZGlcblx0IgogCisj
aWZkZWYgQ09ORklHX1JFVFVSTl9USFVOSworICAgICJqbXAgICAgX194ODZf
cmV0dXJuX3RodW5rXG5cdCIKKyNlbHNlCiAgICAgInJldFxuXHQiCisjZW5k
aWYKIAogICAgICIuc2l6ZSBhcmNoX2dlbmVyaWNfaHdlaWdodGwsIC4gLSBh
cmNoX2dlbmVyaWNfaHdlaWdodGxcblx0IgogKTsK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-4.20-07.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-4.20-07.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogU3ludGhlc2lzZSBJVFNfTk8g
dG8gZ3Vlc3RzIG9uIHVuYWZmZWN0ZWQgaGFyZHdhcmUKCkl0IGlzIGVhc2ll
ciB0byBleHByZXNzIGZlYXR1cmUgd29yZCAxNyBpbiB0ZXJtcyBvZiB3b3Jk
IDE2ICsgWzMyLCA2NCkgYXMKdGhhdCdzIGhvdyB0aGUgbGF5b3V0IGlzIGdp
dmVuIGluIGRvY3VtZW50YXRpb24uCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2
OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29v
cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKaW5k
ZXggM2EwNmI2ZjI5N2I5Li4yNGIwMjFlZWZmYzggMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKKysrIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaApAQCAtMjE4LDYg
KzIxOCw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBib290X2NwdV9oYXModW5z
aWduZWQgaW50IGZlYXQpCiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAgICAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCiAjZGVmaW5l
IGNwdV9oYXNfcmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9SRkRTX05PKQogI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIgICAg
ICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKKyNkZWZp
bmUgY3B1X2hhc19pdHNfbm8gICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX0lUU19OTykKIAogLyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5l
IGNwdV9oYXNfYXJjaF9wZXJmbW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9BUkNIX1BFUkZNT04pCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg
ZmUyN2U4MmE0NzA3Li4wYTYzNTAyNWU0ODggMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMKQEAgLTE3NjAsNiArMTc2MCw5MCBAQCBzdGF0aWMgdm9pZCBfX2lu
aXQgYmhpX2NhbGN1bGF0aW9ucyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAq
IGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZl
bG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1
aWRhbmNlL2Fkdmlzb3J5LWd1aWRhbmNlL2luZGlyZWN0LXRhcmdldC1zZWxl
Y3Rpb24uaHRtbAorICovCitzdGF0aWMgdm9pZCBfX2luaXQgaXRzX2NhbGN1
bGF0aW9ucyh2b2lkKQoreworICAgIC8qCisgICAgICogSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBpcyBhIEJyYW5jaCBQcmVkaWN0aW9uIGJ1ZyB3aGVy
ZWJ5IGNlcnRhaW4KKyAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGdldCBwcmVkaWN0ZWQgdXNpbmcgYSBkaXJlY3QgYnJhbmNo
CisgICAgICogdGFyZ2V0LCByYXRoZXIgdGhhbiBhIHN1aXRhYmxlIGluZGly
ZWN0IHRhcmdldCwgYnlwYXNzaW5nIGhhcmR3YXJlCisgICAgICogaXNvbGF0
aW9uIHByb3RlY3Rpb25zLgorICAgICAqCisgICAgICogSVRTIGFmZmVjdHMg
Q29yZSAoYnV0IG5vdCBBdG9tKSBwcm9jZXNzb3JzIHN0YXJ0aW5nIGZyb20g
dGhlCisgICAgICogaW50cm9kdWN0aW9uIG9mIGVJQlJTLCB1cCB0byBidXQg
bm90IGluY2x1ZGluZyBHb2xkZW4gQ292ZSBjb3JlcworICAgICAqIChjaGVj
a2VkIGhlcmUgd2l0aCBCSElfQ1RSTCkuCisgICAgICoKKyAgICAgKiBUaGUg
SVRTX05PIGZlYXR1cmUgaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVudW1lcmF0
ZWQgYnkgaGFyZHdhcmUsIGFuZCBpcworICAgICAqIG9ubHkgZm9yIFZNTXMg
dG8gc3ludGhlc2lzZSBmb3IgZ3Vlc3RzLgorICAgICAqCisgICAgICogSVRT
IGNvbWVzIGluIDMgZmxhdm91cnM6CisgICAgICoKKyAgICAgKiAgIDEpIEFj
cm9zcy1JQlBCLiAgSW5kaXJlY3QgYnJhbmNoZXMgYWZ0ZXIgdGhlIElCUEIg
Y2FuIGJlIGNvbnRyb2xsZWQKKyAgICAgKiAgICAgIGJ5IGRpcmVjdCB0YXJn
ZXRzIHdoaWNoIGV4aXN0ZWQgcHJpb3IgdG8gdGhlIElCUEIuICBUaGlzIGlz
CisgICAgICogICAgICBhZGRyZXNzZWQgaW4gdGhlIElQVSAyMDI1LjEgbWlj
cm9jb2RlIGRyb3AsIGFuZCBoYXMgbm8gb3RoZXIKKyAgICAgKiAgICAgIHNv
ZnR3YXJlIGludGVyYWN0aW9uLgorICAgICAqCisgICAgICogICAyKSBHdWVz
dC9Ib3N0LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgZGlyZWN0IHRhcmdldHMgZnJv
bSB0aGUgZ3Vlc3QuICBUaGlzIGFwcGxpZXMgZXF1YWxseSB0byBQViBndWVz
dHMKKyAgICAgKiAgICAgIChSaW5nMykgYW5kIEhWTSBndWVzdHMgKFZNWCks
IGFuZCBhcHBsaWVzIHRvIGFsbCBTa3lsYWtlLXVhcmNoCisgICAgICogICAg
ICBjb3JlcyB3aXRoIGVJQlJTLgorICAgICAqCisgICAgICogICAzKSBJbnRy
YS1tb2RlLiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgb3RoZXIgZXhlY3V0aW9uIGlu
IHRoZSBzYW1lIG1vZGUuCisgICAgICovCisKKyAgICAvKgorICAgICAqIElm
IHdlIGNhbiBzZWUgSVRTX05PLCBvciB3ZSdyZSB2aXJ0dWFsaXNlZCwgZG8g
bm90aGluZy4gIFdlIGFyZSBvciBtYXkKKyAgICAgKiBtaWdyYXRlIHNvbWV3
aGVyZSB1bnNhZmUuCisgICAgICovCisgICAgaWYgKCBjcHVfaGFzX2l0c19u
byB8fCBjcHVfaGFzX2h5cGVydmlzb3IgKQorICAgICAgICByZXR1cm47CisK
KyAgICAvKiBJVFMgaXMgb25seSBrbm93biB0byBhZmZlY3QgSW50ZWwgcHJv
Y2Vzc29ycyBhdCB0aGlzIHRpbWUuICovCisgICAgaWYgKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9JTlRFTCApCisgICAgICAg
IHJldHVybjsKKworICAgIC8qCisgICAgICogSVRTIGRvZXMgbm90IGV4aXN0
IG9uOgorICAgICAqICAtIG5vbi1GYW1pbHkgNiBDUFVzCisgICAgICogIC0g
dGhvc2Ugd2l0aG91dCBlSUJSUworICAgICAqICAtIHRob3NlIHdpdGggQkhJ
X0NUUkwKKyAgICAgKiBidXQgd2Ugc3RpbGwgbmVlZCB0byBzeW50aGVzaXNl
IElUU19OTy4KKyAgICAgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2
ICE9IDYgfHwgIWNwdV9oYXNfZWlicnMgfHwKKyAgICAgICAgIGJvb3RfY3B1
X2hhcyhYODZfRkVBVFVSRV9CSElfQ1RSTCkgKQorICAgICAgICBnb3RvIHN5
bnRoZXNpc2U7CisKKyAgICBzd2l0Y2ggKCBib290X2NwdV9kYXRhLng4Nl9t
b2RlbCApCisgICAgeworICAgICAgICAvKiBUaGVzZSBTa3lsYWtlLXVhcmNo
IGNvcmVzIHN1ZmZlciBjYXNlcyAjMiBhbmQgIzMuICovCisgICAgY2FzZSBJ
TlRFTF9GQU02X1NLWUxBS0VfWDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FC
WUxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0U6CisgICAg
Y2FzZSBJTlRFTF9GQU02X0NPTUVUTEFLRToKKyAgICBjYXNlIElOVEVMX0ZB
TTZfQ09NRVRMQUtFX0w6CisgICAgICAgIHJldHVybjsKKworICAgICAgICAv
KiBUaGVzZSBTdW5ueS9XaWxsb3cvQ3lwcmVzcyBDb3ZlIGNvcmVzIHN1ZmZl
ciBjYXNlICMzLiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9JQ0VMQUtFX1g6
CisgICAgY2FzZSBJTlRFTF9GQU02X0lDRUxBS0VfRDoKKyAgICBjYXNlIElO
VEVMX0ZBTTZfSUNFTEFLRV9MOgorICAgIGNhc2UgSU5URUxfRkFNNl9USUdF
UkxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfVElHRVJMQUtFOgorICAg
IGNhc2UgSU5URUxfRkFNNl9ST0NLRVRMQUtFOgorICAgICAgICByZXR1cm47
CisKKyAgICBkZWZhdWx0OgorICAgICAgICBicmVhazsKKyAgICB9CisKKyAg
ICAvKiBQbGF0Zm9ybXMgcmVtYWluaW5nIGFyZSBub3QgYmVsaWV2ZWQgdG8g
YmUgdnVsbmVyYWJsZSB0byBJVFMuICovCisgc3ludGhlc2lzZToKKyAgICBz
ZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX0lUU19OTyk7Cit9CisK
IHZvaWQgc3BlY19jdHJsX2luaXRfZG9tYWluKHN0cnVjdCBkb21haW4gKmQp
CiB7CiAgICAgYm9vbCBwdiA9IGlzX3B2X2RvbWFpbihkKTsKQEAgLTIzMTYs
NiArMjQwMCw4IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0
aWdhdGlvbnModm9pZCkKIAogICAgIGJoaV9jYWxjdWxhdGlvbnMoKTsKIAor
ICAgIGl0c19jYWxjdWxhdGlvbnMoKTsKKwogICAgIHByaW50X2RldGFpbHMo
dGh1bmspOwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IDE2MjA3ZTM4
MTdiYi4uMWUwZTg3MGM1YzdkIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNs
dWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTM3OSw3
ICszNzksOCBAQCBYRU5fQ1BVRkVBVFVSRShHRFNfTk8sICAgICAgICAgICAg
IDE2KjMyKzI2KSAvKkEgIE5vIEdhdGhlciBEYXRhIFNhbXBsaW5nICovCiBY
RU5fQ1BVRkVBVFVSRShSRkRTX05PLCAgICAgICAgICAgIDE2KjMyKzI3KSAv
KkEgIE5vIFJlZ2lzdGVyIEZpbGUgRGF0YSBTYW1wbGluZyAqLwogWEVOX0NQ
VUZFQVRVUkUoUkZEU19DTEVBUiwgICAgICAgICAxNiozMisyOCkgLyohQXwg
UmVnaXN0ZXIgRmlsZShzKSBjbGVhcmVkIGJ5IFZFUlcgKi8KIAotLyogSW50
ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMsIE1TUl9BUkNIX0NBUFMgMHgxMGEu
ZWR4LCB3b3JkIDE3ICovCisvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl
cywgTVNSX0FSQ0hfQ0FQUyAweDEwYS5lZHgsIHdvcmQgMTcgKGV4cHJlc3Mg
aW4gdGVybXMgb2Ygd29yZCAxNikgKi8KK1hFTl9DUFVGRUFUVVJFKElUU19O
TywgICAgICAgICAgICAgMTYqMzIrNjIpIC8qIUEgTm8gSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiAqLwogCiAjZW5kaWYgLyogWEVOX0NQVUZFQVRVUkUg
Ki8KIApkaWZmIC0tZ2l0IGEveGVuL3Rvb2xzL2dlbi1jcHVpZC5weSBiL3hl
bi90b29scy9nZW4tY3B1aWQucHkKaW5kZXggYTc3Y2IzMGJkYjRmLi4xNjNi
MTA1YmM2YTcgMTAwNzU1Ci0tLSBhL3hlbi90b29scy9nZW4tY3B1aWQucHkK
KysrIGIveGVuL3Rvb2xzL2dlbi1jcHVpZC5weQpAQCAtNTEsNyArNTEsNyBA
QCBkZWYgcGFyc2VfZGVmaW5pdGlvbnMoc3RhdGUpOgogICAgICAgICByIlxz
Ky9cKihbXHchfF0qKSAuKiQiKQogCiAgICAgd29yZF9yZWdleCA9IHJlLmNv
bXBpbGUoCi0gICAgICAgIHIiXi9cKiAuKiB3b3JkIChcZCopIFwqLyQiKQor
ICAgICAgICByIl4vXCogLiogd29yZCAoXGQqKSAuKlwqLyQiKQogICAgIGxh
c3Rfd29yZCA9IC0xCiAKICAgICB0aGlzID0gc3lzLm1vZHVsZXNbX19uYW1l
X19dCg==

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-04.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-04.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3RodW5rOiAoTWlzKWFsaWduIHRoZSBSRVRzIGlu
IGNsZWFyX2JoYl9sb29wcygpIHRvIG1pdGlnYXRlIElUUwoKVGhlIEluZGly
ZWN0IFRhcmdldCBTZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0
eSBtZWFucyB0aGF0IGluZGlyZWN0CmJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdCBoYWxmIG9mIGEgY2Fj
aGVsaW5lLgoKY2xlYXJfYmhiX2xvb3BzKCkgaGFzIGEgcHJlY2lzZSBsYXlv
dXQgb2YgYnJhbmNoZXMuICBUaGUgYWxpZ25tZW50IGZvcgpwZXJmb3JtYW5j
ZSBjYXVzZSB0aGUgUkVUcyB0byBhbHdheXMgYmUgaW4gYW4gdW5zYWZlIHBv
c2l0aW9uLCBhbmQgY29udmVydGluZwp0aG9zZSB0byByZXR1cm4gdGh1bmtz
IGNoYW5nZXMgdGhlIGJyYW5jaGluZyBwYXR0ZXJuLiAgV2hpbGUgc3VjaCBh
IGNvbnZlcnNpb24KaXMgYmVsaWV2ZWQgdG8gYmUgc2FmZSwgY2xlYXJfYmhi
X2xvb3BzKCkgaXMgYWxzbyBhIHBlcmZvcm1hbmNlLXJlbGV2YW50CmZhc3Rw
YXRoLCBzbyAobWlzKWFsaWduIHRoZSBSRVRzIHRvIGJlIGluIGEgc2FmZSBw
b3NpdGlvbi4KCk5vIGZ1bmN0aW9uYWwgY2hhbmdlLgoKVGhpcyBpcyBwYXJ0
IG9mIFhTQS00NjkgLyBDVkUtMjAyNC0yODk1NgoKU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUyBi
L3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwppbmRleCBmNWFjNDE4MzRiYmQu
LjcxNzU3NzhiZGQxMSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2JoYi10
aHVuay5TCisrKyBiL3hlbi9hcmNoL3g4Ni9iaGItdGh1bmsuUwpAQCAtNTAs
NyArNTAsMTIgQEAgRU5EKGNsZWFyX2JoYl90c3gpCiAgKiAgIHJldAogICoK
ICAqIFRoZSBDQUxML1JFVHMgYXJlIG5lY2Vzc2FyeSB0byBwcmV2ZW50IHRo
ZSBMb29wIFN0cmVhbSBEZXRlY3RvciBmcm9tCi0gKiBpbnRlcmZlcmluZy4g
IFRoZSBhbGlnbm1lbnQgaXMgZm9yIHBlcmZvcm1hbmNlIGFuZCBub3Qgc2Fm
ZXR5LgorICogaW50ZXJmZXJpbmcuCisgKgorICogVGhlIC5iYWxpZ24ncyBh
cmUgZm9yIHBlcmZvcm1hbmNlLCBidXQgdGhleSBjYXVzZSB0aGUgUkVUcyB0
byBiZSBpbiB1bnNhZmUKKyAqIHBvc2l0aW9ucyB3aXRoIHJlc3BlY3QgdG8g
SW5kaXJlY3QgVGFyZ2V0IFNlbGVjdGlvbi4gIFRoZSAuc2tpcHMgYXJlIHRv
CisgKiBtb3ZlIHRoZSBSRVRzIGludG8gSVRTLXNhZmUgcG9zaXRpb25zLCBy
YXRoZXIgdGhhbiB1c2luZyB0aGUgc2xvd3BhdGgKKyAqIHRocm91Z2ggX194
ODZfcmV0dXJuX3RodW5rLgogICoKICAqIFRoZSAic2hvcnQiIHNlcXVlbmNl
ICg1IGFuZCA1KSBpcyBmb3IgQ1BVcyBwcmlvciB0byBBbGRlciBMYWtlIC8g
U2FwcGhpcmUKICAqIFJhcGlkcyAoaS5lLiBDb3JlcyBwcmlvciB0byBHb2xk
ZW4gQ292ZSBhbmQvb3IgR3JhY2Vtb250KS4KQEAgLTY2LDEyICs3MSwxNCBA
QCBGVU5DKGNsZWFyX2JoYl9sb29wcykKICAgICAgICAgam1wICAgICA1Zgog
ICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAgICAgIC5i
YWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtICguTHIxIC0gMWYpLCAw
eGNjCiAxOiAgICAgIGNhbGwgICAgMmYKLSAgICAgICAgcmV0CisuTHIxOiAg
IHJldAogICAgICAgICBpbnQzCiAKLSAgICAgICAgLmFsaWduIDY0CisgICAg
ICAgIC5iYWxpZ24gNjQKKyAgICAgICAgLnNraXAgICAzMiAtIDE4IC8qICgu
THIyIC0gMmYpIGJ1dCBDbGFuZyBJQVMgZG9lc24ndCBsaWtlIHRoaXMgKi8s
IDB4Y2MKIDI6ICAgICAgQUxURVJOQVRJVkUgIm1vdiAkNSwgJWVheCIsICJt
b3YgJDcsICVlYXgiLCBYODZfU1BFQ19CSEJfTE9PUFNfTE9ORwogCiAzOiAg
ICAgIGptcCAgICAgNGYKQEAgLTgzLDcgKzkwLDcgQEAgRlVOQyhjbGVhcl9i
aGJfbG9vcHMpCiAgICAgICAgIHN1YiAgICAgJDEsICVlY3gKICAgICAgICAg
am56ICAgICAxYgogCi0gICAgICAgIHJldAorLkxyMjogICByZXQKIDU6CiAg
ICAgICAgIC8qCiAgICAgICAgICAqIFRoZSBJbnRlbCBzZXF1ZW5jZSBoYXMg
YW4gTEZFTkNFIGhlcmUuICBUaGUgcHVycG9zZSBpcyB0byBlbnN1cmUK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-05.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-05.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3N0dWJzOiBJbnRyb2R1Y2UgcGxhY2VfcmV0KCkg
dG8gYWJzdHJhY3QgYXdheSByYXcgMHhjMydzCgpUaGUgSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBzcGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXR5IG1lYW5z
IHRoYXQgaW5kaXJlY3QKYnJhbmNoZXMgKGluY2x1ZGluZyBSRVRzKSBhcmUg
dW5zYWZlIHdoZW4gaW4gdGhlIGZpcnN0IGhhbGYgb2YgYSBjYWNoZWxpbmUu
ClRoaXMgbWVhbnMgaXQncyBub3Qgc2FmZSBmb3IgbG9naWMgdXNpbmcgdGhl
IHN0dWJzIHRvIHdyaXRlIHJhdyAweGMzJ3MuCgpJbnRyb2R1Y2UgcGxhY2Vf
cmV0KCkgd2hpY2gsIGZvciBub3csIHdyaXRlcyBhIHJhdyAweGMzIGJ1dCB3
aWxsIGNvbnRhaW4KYWRkaXRpb25hbCBsb2dpYyB3aGVuIHJldHVybiB0aHVu
a3MgYXJlIGluIHVzZS4KCnN0dWJfc2VsZnRlc3QoKSBkb2Vzbid0IHN0cmlj
dGx5IG5lZWQgdG8gYmUgY29udmVydGVkIGFzIHRoZXkgb25seSBydW4gb24K
Ym9vdCwgYnV0IGRvaW5nIHNvIGdldHMgdXMgYSBwYXJ0aWFsIHRlc3Qgb2Yg
cGxhY2VfcmV0KCkgdG9vLgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2UuCgpUaGlz
IGlzIHBhcnQgb2YgWFNBLTQ2OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQt
b2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXgu
Y29tPgpSZXZpZXdlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1
QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvdG9vbHMvdGVzdHMveDg2X2Vt
dWxhdG9yL3g4Ni1lbXVsYXRlLmggYi90b29scy90ZXN0cy94ODZfZW11bGF0
b3IveDg2LWVtdWxhdGUuaAppbmRleCA5MjljMWE3MmFlODguLjRjMjkyYWMz
MzhmNiAxMDA2NDQKLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKKysrIGIvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3g4
Ni1lbXVsYXRlLmgKQEAgLTc3LDYgKzc3LDEyIEBACiAKICNkZWZpbmUgaXNf
Y2Fub25pY2FsX2FkZHJlc3MoeCkgKCgoaW50NjRfdCkoeCkgPj4gNDcpID09
ICgoaW50NjRfdCkoeCkgPj4gNjMpKQogCitzdGF0aWMgaW5saW5lIHZvaWQg
KnBsYWNlX3JldCh2b2lkICpwdHIpCit7CisgICAgKih1aW50OF90ICopcHRy
ID0gMHhjMzsKKyAgICByZXR1cm4gcHRyICsgMTsKK30KKwogZXh0ZXJuIHVp
bnQzMl90IG14Y3NyX21hc2s7CiBleHRlcm4gc3RydWN0IGNwdV9wb2xpY3kg
Y3B1X3BvbGljeTsKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L01ha2Vm
aWxlIGIveGVuL2FyY2gveDg2L01ha2VmaWxlCmluZGV4IGMyZjFkY2YzMDFk
Ni4uYzMyYWJhMDI5ZDQ0IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvTWFr
ZWZpbGUKKysrIGIveGVuL2FyY2gveDg2L01ha2VmaWxlCkBAIC0xMSw5ICsx
MSw3IEBAIG9iai0kKENPTkZJR19QVikgKz0gcHYvCiBvYmoteSArPSB4ODZf
NjQvCiBvYmoteSArPSB4ODZfZW11bGF0ZS8KIAotYWx0ZXJuYXRpdmUteSA6
PSBhbHRlcm5hdGl2ZS5pbml0Lm8KLWFsdGVybmF0aXZlLSQoQ09ORklHX0xJ
VkVQQVRDSCkgOj0KLW9iai1iaW4teSArPSAkKGFsdGVybmF0aXZlLXkpCitv
YmoteSArPSBhbHRlcm5hdGl2ZS5vCiBvYmoteSArPSBhcGljLm8KIG9iai15
ICs9IGJoYi10aHVuay5vCiBvYmoteSArPSBiaXRvcHMubwpAQCAtNDEsNyAr
MzksNyBAQCBvYmoteSArPSBoeXBlcmNhbGwubwogb2JqLXkgKz0gaTM4Ny5v
CiBvYmoteSArPSBpODI1OS5vCiBvYmoteSArPSBpb19hcGljLm8KLW9iai0k
KENPTkZJR19MSVZFUEFUQ0gpICs9IGFsdGVybmF0aXZlLm8gbGl2ZXBhdGNo
Lm8KK29iai0kKENPTkZJR19MSVZFUEFUQ0gpICs9IGxpdmVwYXRjaC5vCiBv
YmoteSArPSBtc2kubwogb2JqLXkgKz0gbXNyLm8KIG9iai0kKENPTkZJR19J
TkRJUkVDVF9USFVOSykgKz0gaW5kaXJlY3QtdGh1bmsubwpkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMgYi94ZW4vYXJjaC94ODYv
YWx0ZXJuYXRpdmUuYwppbmRleCA0ZDFiYmU3MzEzZmQuLjA0NDliOWMxYjdl
NSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKKysr
IGIveGVuL2FyY2gveDg2L2FsdGVybmF0aXZlLmMKQEAgLTEzNSw2ICsxMzUs
MjAgQEAgdm9pZCBpbml0X29yX2xpdmVwYXRjaCBhZGRfbm9wcyh2b2lkICpp
bnNucywgdW5zaWduZWQgaW50IGxlbikKICAgICB9CiB9CiAKKy8qCisgKiBQ
bGFjZSBhIHJldHVybiBhdCBAcHRyLiAgQHB0ciBtdXN0IGJlIGluIHRoZSB3
cml0YWJsZSBhbGlhcyBvZiBhIHN0dWIuCisgKgorICogUmV0dXJucyB0aGUg
bmV4dCBwb3NpdGlvbiB0byB3cml0ZSBpbnRvIHRoZSBzdHViLgorICovCit2
b2lkICpwbGFjZV9yZXQodm9pZCAqcHRyKQoreworICAgIHVpbnQ4X3QgKnAg
PSBwdHI7CisKKyAgICAqcCsrID0gMHhjMzsKKworICAgIHJldHVybiBwOwor
fQorCiAvKgogICogdGV4dF9wb2tlIC0gVXBkYXRlIGluc3RydWN0aW9ucyBv
biBhIGxpdmUga2VybmVsIG9yIG5vbi1leGVjdXRlZCBjb2RlLgogICogQGFk
ZHI6IGFkZHJlc3MgdG8gbW9kaWZ5CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvZXh0YWJsZS5jIGIveGVuL2FyY2gveDg2L2V4dGFibGUuYwppbmRleCA3
MDVjZjllYjk0Y2EuLjE1NzJlZmE2OWEwMCAxMDA2NDQKLS0tIGEveGVuL2Fy
Y2gveDg2L2V4dGFibGUuYworKysgYi94ZW4vYXJjaC94ODYvZXh0YWJsZS5j
CkBAIC0xNTEsMjAgKzE1MSwyMCBAQCBzZWFyY2hfZXhjZXB0aW9uX3RhYmxl
KGNvbnN0IHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzLCB1bnNpZ25lZCBs
b25nICpzdHViX3JhKQogaW50IF9faW5pdCBjZl9jaGVjayBzdHViX3NlbGZ0
ZXN0KHZvaWQpCiB7CiAgICAgc3RhdGljIGNvbnN0IHN0cnVjdCB7Ci0gICAg
ICAgIHVpbnQ4X3Qgb3BjWzhdOworICAgICAgICB1aW50OF90IG9wY1s3XTsK
ICAgICAgICAgdWludDY0X3QgcmF4OwogICAgICAgICB1bmlvbiBzdHViX2V4
Y2VwdGlvbl90b2tlbiByZXM7CiAgICAgfSB0ZXN0c1tdIF9faW5pdGNvbnN0
ID0gewogI2RlZmluZSBlbmRicjY0IDB4ZjMsIDB4MGYsIDB4MWUsIDB4ZmEK
LSAgICAgICAgeyAub3BjID0geyBlbmRicjY0LCAweDBmLCAweGI5LCAweGMz
LCAweGMzIH0sIC8qIHVkMSAqLworICAgICAgICB7IC5vcGMgPSB7IGVuZGJy
NjQsIDB4MGYsIDB4YjksIDB4OTAgfSwgLyogdWQxICovCiAgICAgICAgICAg
LnJlcy5maWVsZHMudHJhcG5yID0gWDg2X0VYQ19VRCB9LAotICAgICAgICB7
IC5vcGMgPSB7IGVuZGJyNjQsIDB4OTAsIDB4MDIsIDB4MDAsIDB4YzMgfSwg
Lyogbm9wOyBhZGQgKCVyYXgpLCVhbCAqLworICAgICAgICB7IC5vcGMgPSB7
IGVuZGJyNjQsIDB4OTAsIDB4MDIsIDB4MDAgfSwgLyogbm9wOyBhZGQgKCVy
YXgpLCVhbCAqLwogICAgICAgICAgIC5yYXggPSAweDAxMjM0NTY3ODlhYmNk
ZWYsCiAgICAgICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0gWDg2X0VYQ19H
UCB9LAotICAgICAgICB7IC5vcGMgPSB7IGVuZGJyNjQsIDB4MDIsIDB4MDQs
IDB4MDQsIDB4YzMgfSwgLyogYWRkICglcnNwLCVyYXgpLCVhbCAqLworICAg
ICAgICB7IC5vcGMgPSB7IGVuZGJyNjQsIDB4MDIsIDB4MDQsIDB4MDQgfSwg
LyogYWRkICglcnNwLCVyYXgpLCVhbCAqLwogICAgICAgICAgIC5yYXggPSAw
eGZlZGNiYTk4NzY1NDMyMTBVTCwKICAgICAgICAgICAucmVzLmZpZWxkcy50
cmFwbnIgPSBYODZfRVhDX1NTIH0sCi0gICAgICAgIHsgLm9wYyA9IHsgZW5k
YnI2NCwgMHhjYywgMHhjMywgMHhjMywgMHhjMyB9LCAvKiBpbnQzICovCisg
ICAgICAgIHsgLm9wYyA9IHsgZW5kYnI2NCwgMHhjYywgMHg5MCwgMHg5MCB9
LCAvKiBpbnQzICovCiAgICAgICAgICAgLnJlcy5maWVsZHMudHJhcG5yID0g
WDg2X0VYQ19CUCB9LAogI3VuZGVmIGVuZGJyNjQKICAgICB9OwpAQCAtMTgz
LDYgKzE4Myw3IEBAIGludCBfX2luaXQgY2ZfY2hlY2sgc3R1Yl9zZWxmdGVz
dCh2b2lkKQogCiAgICAgICAgIG1lbXNldChwdHIsIDB4Y2MsIFNUVUJfQlVG
X1NJWkUgLyAyKTsKICAgICAgICAgbWVtY3B5KHB0ciwgdGVzdHNbaV0ub3Bj
LCBBUlJBWV9TSVpFKHRlc3RzW2ldLm9wYykpOworICAgICAgICBwbGFjZV9y
ZXQocHRyICsgQVJSQVlfU0laRSh0ZXN0c1tpXS5vcGMpKTsKICAgICAgICAg
dW5tYXBfZG9tYWluX3BhZ2UocHRyKTsKIAogICAgICAgICBhc20gdm9sYXRp
bGUgKCAiSU5ESVJFQ1RfQ0FMTCAlW3N0Yl1cbiIKZGlmZiAtLWdpdCBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oIGIveGVuL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2FsdGVybmF0aXZlLmgKaW5kZXggYjllYTQ5
YmQxYzNkLi5lMTdiZThkZGZkODIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCisrKyBiL3hlbi9hcmNoL3g4
Ni9pbmNsdWRlL2FzbS9hbHRlcm5hdGl2ZS5oCkBAIC0zMyw2ICszMyw4IEBA
IHN0cnVjdCBfX3BhY2tlZCBhbHRfaW5zdHIgewogI2RlZmluZSBBTFRfUkVQ
TF9QVFIoYSkgICAgIF9fQUxUX1BUUihhLCByZXBsX29mZnNldCkKIAogZXh0
ZXJuIHZvaWQgYWRkX25vcHModm9pZCAqaW5zbnMsIHVuc2lnbmVkIGludCBs
ZW4pOwordm9pZCAqcGxhY2VfcmV0KHZvaWQgKnB0cik7CisKIC8qIFNpbWls
YXIgdG8gYWx0ZXJuYXRpdmVfaW5zdHJ1Y3Rpb25zIGV4Y2VwdCBpdCBjYW4g
YmUgcnVuIHdpdGggSVJRcyBlbmFibGVkLiAqLwogZXh0ZXJuIGludCBhcHBs
eV9hbHRlcm5hdGl2ZXMoc3RydWN0IGFsdF9pbnN0ciAqc3RhcnQsIHN0cnVj
dCBhbHRfaW5zdHIgKmVuZCk7CiBleHRlcm4gdm9pZCBhbHRlcm5hdGl2ZV9p
bnN0cnVjdGlvbnModm9pZCk7CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
cHYvZW11bC1wcml2LW9wLmMgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2
LW9wLmMKaW5kZXggNzAxNTBjMjcyMjc2Li5mZjVkMWM5Zjg2MzQgMTAwNjQ0
Ci0tLSBhL3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXByaXYtb3AuYworKysgYi94
ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMKQEAgLTc2LDcgKzc2LDYg
QEAgc3RhdGljIGlvX2VtdWxfc3R1Yl90ICppb19lbXVsX3N0dWJfc2V0dXAo
c3RydWN0IHByaXZfb3BfY3R4dCAqY3R4dCwgdTggb3Bjb2RlLAogICAgICAg
ICAweDQxLCAweDVjLCAvKiBwb3AgJXIxMiAgKi8KICAgICAgICAgMHg1ZCwg
ICAgICAgLyogcG9wICVyYnAgICovCiAgICAgICAgIDB4NWIsICAgICAgIC8q
IHBvcCAlcmJ4ICAqLwotICAgICAgICAweGMzLCAgICAgICAvKiByZXQgICAg
ICAgKi8KICAgICB9OwogCiAgICAgY29uc3Qgc3RydWN0IHN0dWJzICp0aGlz
X3N0dWJzID0gJnRoaXNfY3B1KHN0dWJzKTsKQEAgLTEyNiwxMSArMTI1LDEz
IEBAIHN0YXRpYyBpb19lbXVsX3N0dWJfdCAqaW9fZW11bF9zdHViX3NldHVw
KHN0cnVjdCBwcml2X29wX2N0eHQgKmN0eHQsIHU4IG9wY29kZSwKIAogICAg
IEFQUEVORF9DQUxMKHNhdmVfZ3Vlc3RfZ3Bycyk7CiAgICAgQVBQRU5EX0JV
RkYoZXBpbG9ndWUpOworICAgIHAgPSBwbGFjZV9yZXQocCk7CiAKICAgICAv
KiBCdWlsZC10aW1lIGJlc3QgZWZmb3J0IGF0dGVtcHQgdG8gY2F0Y2ggcHJv
YmxlbXMuICovCiAgICAgQlVJTERfQlVHX09OKFNUVUJfQlVGX1NJWkUgLyAy
IDwKICAgICAgICAgICAgICAgICAgKHNpemVvZihwcm9sb2d1ZSkgKyBzaXpl
b2YoZXBpbG9ndWUpICsgMTAgLyogMnggY2FsbCAqLyArCi0gICAgICAgICAg
ICAgICAgICBNQVgoMyAvKiBkZWZhdWx0IHN0dWIgKi8sIElPRU1VTF9RVUlS
S19TVFVCX0JZVEVTKSkpOworICAgICAgICAgICAgICAgICAgTUFYKDMgLyog
ZGVmYXVsdCBzdHViICovLCBJT0VNVUxfUVVJUktfU1RVQl9CWVRFUykgKwor
ICAgICAgICAgICAgICAgICAgMSAvKiByZXQgKi8pKTsKICAgICAvKiBSdW50
aW1lIGNvbmZpcm1hdGlvbiB0aGF0IHdlIGhhdmVuJ3QgY2xvYmJlcmVkIGFu
IGFkamFjZW50IHN0dWIuICovCiAgICAgQlVHX09OKFNUVUJfQlVGX1NJWkUg
LyAyIDwgKHAgLSBjdHh0LT5pb19lbXVsX3N0dWIpKTsKIApkaWZmIC0tZ2l0
IGEveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL2ZwdS5jIGIveGVuL2FyY2gv
eDg2L3g4Nl9lbXVsYXRlL2ZwdS5jCmluZGV4IDU0Yzg2MjE0MjFjNi4uOWNj
MzdhMWQ4ZTNjIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYveDg2X2VtdWxh
dGUvZnB1LmMKKysrIGIveGVuL2FyY2gveDg2L3g4Nl9lbXVsYXRlL2ZwdS5j
CkBAIC0zMiwzNiArMzIsNDIgQEAgc3RhdGljIGlubGluZSBib29sIGZwdV9j
aGVja193cml0ZSh2b2lkKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25f
bWVtZHN0KG9wYywgZXh0LCBhcmcpICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAq
X3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgLyogTW9kUk06IG1vZD0wLCByZWc9
ZXh0LCBybT0wLCBpLmUuIGEgKCVyYXgpIG9wZXJhbmQgKi8gICAgICAgICAg
ICBcCiAgICAgKmluc25fYnl0ZXMgPSAyOyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWludDhfdFtdKXsg
b3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsgICAgICAgICAg
ICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9wYywgKChleHQp
ICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisgICAgcGxhY2Vf
cmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAi
K20iIChhcmcpIDogImEiICgmKGFyZykpKTsgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9IHdoaWxlICgw
KQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fbWVtc3JjKG9wYywgZXh0
LCBhcmcpICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBkbyB7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBnZXRfc3R1Yihz
dHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgLyogTW9kUk06IG1vZD0wLCByZWc9ZXh0LCBybT0wLCBpLmUu
IGEgKCVyYXgpIG9wZXJhbmQgKi8gICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCi0gICAgICAgICAgICgodWludDhfdFtdKXsg
b3BjLCAoKGV4dCkgJiA3KSA8PCAzLCAweGMzIH0pLCAzKTsgICAgICAgICAg
ICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3RbXSl7IG9wYywgKChleHQp
ICYgNykgPDwgMyB9KSwgMik7IF9wICs9IDI7ICAgICBcCisgICAgcGxhY2Vf
cmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAi
PW0iIChkdW1teSkgOiAibSIgKGFyZyksICJhIiAoJihhcmcpKSk7ICAgICAg
ICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiB9IHdoaWxlICgw
KQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25fc3R1YihieXRlcy4uLikg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiBkbyB7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAqX3AgPSBnZXRfc3R1Yihz
dHViKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgdW5zaWduZWQgaW50IG5yXyA9IHNpemVvZigodWludDhfdFtd
KXsgYnl0ZXMgfSk7ICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVzLCAweGMzIH0p
LCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3Rb
XSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAgICAgICAgICAg
ICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tl
X3N0dWIoIiIsICIiLCAiPW0iIChkdW1teSkgOiAiaSIgKDApKTsgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgcHV0X3N0dWIoc3R1Yik7ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiB9IHdoaWxlICgwKQogCiAjZGVmaW5lIGVtdWxhdGVfZnB1X2luc25f
c3R1Yl9lZmxhZ3MoYnl0ZXMuLi4pICAgICAgICAgICAgICAgICAgICAgICAg
ICBcCiBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgdm9pZCAq
X3AgPSBnZXRfc3R1YihzdHViKTsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBcCiAgICAgdW5zaWduZWQgaW50IG5yXyA9IHNp
emVvZigodWludDhfdFtdKXsgYnl0ZXMgfSk7ICAgICAgICAgICAgICAgICAg
ICBcCiAgICAgdW5zaWduZWQgbG9uZyB0bXBfOyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCi0gICAgbWVtY3B5
KGdldF9zdHViKHN0dWIpLCAoKHVpbnQ4X3RbXSl7IGJ5dGVzLCAweGMzIH0p
LCBucl8gKyAxKTsgICAgICBcCisgICAgbWVtY3B5KF9wLCAoKHVpbnQ4X3Rb
XSl7IGJ5dGVzIH0pLCBucl8pOyBfcCArPSBucl87ICAgICAgICAgICAgICAg
ICBcCisgICAgcGxhY2VfcmV0KF9wKTsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgaW52b2tl
X3N0dWIoX1BSRV9FRkxBR1MoIltlZmxhZ3NdIiwgIlttYXNrXSIsICJbdG1w
XSIpLCAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgX1BPU1RfRUZM
QUdTKCJbZWZsYWdzXSIsICJbbWFza10iLCAiW3RtcF0iKSwgICAgICAgICAg
ICBcCiAgICAgICAgICAgICAgICAgW2VmbGFnc10gIitnIiAocmVncy0+ZWZs
YWdzKSwgW3RtcF0gIj0mciIgKHRtcF8pICAgICAgICBcCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYyBiL3hl
bi9hcmNoL3g4Ni94ODZfZW11bGF0ZS94ODZfZW11bGF0ZS5jCmluZGV4IDdk
NjhlYmU3ZWEwNS4uMGE5OGI0MzQ3NjMxIDEwMDY0NAotLS0gYS94ZW4vYXJj
aC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYworKysgYi94ZW4vYXJj
aC94ODYveDg2X2VtdWxhdGUveDg2X2VtdWxhdGUuYwpAQCAtMTQwMCw3ICsx
NDAwLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHN0YlszXSA9IDB4OTE7
CiAgICAgICAgIHN0Yls0XSA9IGV2ZXgub3Btc2sgPDwgMzsKICAgICAgICAg
aW5zbl9ieXRlcyA9IDU7Ci0gICAgICAgIHN0Yls1XSA9IDB4YzM7CisgICAg
ICAgIHBsYWNlX3JldCgmc3RiWzVdKTsKIAogICAgICAgICBpbnZva2Vfc3R1
YigiIiwgIiIsICIrbSIgKG9wX21hc2spIDogImEiICgmb3BfbWFzaykpOwog
CkBAIC0zNjMzLDcgKzM2MzMsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAg
fQogICAgICAgICBvcGNbMV0gPSAobW9kcm0gJiAweDM4KSB8IDB4YzA7CiAg
ICAgICAgIGluc25fYnl0ZXMgPSBFVkVYX1BGWF9CWVRFUyArIDI7Ci0gICAg
ICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJd
KTsKIAogICAgICAgICBjb3B5X0VWRVgob3BjLCBldmV4KTsKICAgICAgICAg
aW52b2tlX3N0dWIoIiIsICIiLCAiPWciIChkdW1teSkgOiAiYSIgKHNyYy52
YWwpKTsKQEAgLTM3MDAsNyArMzcwMCw3IEBAIHg4Nl9lbXVsYXRlKAogICAg
ICAgICAgICAgaW5zbl9ieXRlcyA9IFBGWF9CWVRFUyArIDI7CiAgICAgICAg
ICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2ZXgpOwogICAg
ICAgICB9Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNl
X3JldCgmb3BjWzJdKTsKIAogICAgICAgICBlYS5yZWcgPSBkZWNvZGVfZ3By
KCZfcmVncywgbW9kcm1fcmVnKTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIs
ICIiLCAiPWEiICgqZWEucmVnKSA6ICJjIiAobW12YWxwKSwgIm0iICgqbW12
YWxwKSk7CkBAIC0zNzc0LDcgKzM3NzQsNyBAQCB4ODZfZW11bGF0ZSgKICAg
ICAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwogICAgICAg
ICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3ByZWZpeCwgdmV4KTsKICAg
ICAgICAgfQotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFj
ZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgX3JlZ3MuZWZsYWdzICY9IH5F
RkxBR1NfTUFTSzsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsCkBAIC00MDEw
LDcgKzQwMTAsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgb3BjWzFdID0g
bW9kcm0gJiAweGM3OwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVT
ICsgMjsKICAgICBzaW1kXzBmX3RvX2dwcjoKLSAgICAgICAgb3BjW2luc25f
Ynl0ZXMgLSBQRlhfQllURVNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0
KCZvcGNbaW5zbl9ieXRlcyAtIFBGWF9CWVRFU10pOwogCiAgICAgICAgIGdl
bmVyYXRlX2V4Y2VwdGlvbl9pZihlYS50eXBlICE9IE9QX1JFRywgWDg2X0VY
Q19VRCk7CiAKQEAgLTQ0MDcsNyArNDQwNyw3IEBAIHg4Nl9lbXVsYXRlKAog
ICAgICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2Ry
bSAmIDB4Mzg7CiAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAy
OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQo
Jm9wY1syXSk7CiAKICAgICAgICAgY29weV9SRVhfVkVYKG9wYywgcmV4X3By
ZWZpeCwgdmV4KTsKICAgICAgICAgaW52b2tlX3N0dWIoIiIsICIiLCAiK20i
IChzcmMudmFsKSA6ICJhIiAoJnNyYy52YWwpKTsKQEAgLTQ0NDQsNyArNDQ0
NCw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICAgICAgZXZleC53ID0gMDsK
ICAgICAgICAgb3BjWzFdID0gbW9kcm0gJiAweDM4OwogICAgICAgICBpbnNu
X2J5dGVzID0gRVZFWF9QRlhfQllURVMgKyAyOwotICAgICAgICBvcGNbMl0g
PSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAg
ICAgY29weV9FVkVYKG9wYywgZXZleCk7CiAgICAgICAgIGludm9rZV9zdHVi
KCIiLCAiIiwgIittIiAoc3JjLnZhbCkgOiAiYSIgKCZzcmMudmFsKSk7CkBA
IC00NjM5LDcgKzQ2MzksNyBAQCB4ODZfZW11bGF0ZSgKICNlbmRpZiAvKiBY
ODZFTVVMX05PX1NJTUQgKi8KIAogICAgIHNpbWRfMGZfcmVnX29ubHk6Ci0g
ICAgICAgIG9wY1tpbnNuX2J5dGVzIC0gUEZYX0JZVEVTXSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjW2luc25fYnl0ZXMgLSBQRlhfQllURVNd
KTsKIAogICAgICAgICBjb3B5X1JFWF9WRVgob3BjLCByZXhfcHJlZml4LCB2
ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsIFtkdW1teV9vdXRd
ICI9ZyIgKGR1bW15KSA6IFtkdW1teV9pbl0gImkiICgwKSApOwpAQCAtNDk3
Myw3ICs0OTczLDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIGlmICggIW1v
ZGVfNjRiaXQoKSApCiAgICAgICAgICAgICB2ZXgudyA9IDA7CiAgICAgICAg
IG9wY1sxXSA9IG1vZHJtICYgMHhmODsKLSAgICAgICAgb3BjWzJdID0gMHhj
MzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNv
cHlfVkVYKG9wYywgdmV4KTsKICAgICAgICAgZWEucmVnID0gZGVjb2RlX2dw
cigmX3JlZ3MsIG1vZHJtX3JtKTsKQEAgLTUwMTYsNyArNTAxNiw3IEBAIHg4
Nl9lbXVsYXRlKAogICAgICAgICBpZiAoICFtb2RlXzY0Yml0KCkgKQogICAg
ICAgICAgICAgdmV4LncgPSAwOwogICAgICAgICBvcGNbMV0gPSBtb2RybSAm
IDB4Yzc7Ci0gICAgICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNl
X3JldCgmb3BjWzJdKTsKIAogICAgICAgICBjb3B5X1ZFWChvcGMsIHZleCk7
CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIj1hIiAoZHN0LnZhbCkg
OiBbZHVtbXldICJpIiAoMCkpOwpAQCAtNTA0Niw3ICs1MDQ2LDcgQEAgeDg2
X2VtdWxhdGUoCiAgICAgICAgIG9wYyA9IGluaXRfcHJlZml4ZXMoc3R1Yik7
CiAgICAgICAgIG9wY1swXSA9IGI7CiAgICAgICAgIG9wY1sxXSA9IG1vZHJt
OwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQo
Jm9wY1syXSk7CiAKICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAg
ICAgICBfcmVncy5lZmxhZ3MgJj0gfkVGTEFHU19NQVNLOwpAQCAtNTYxNCw3
ICs1NjE0LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIGlmICggIW1vZGVf
NjRiaXQoKSApCiAgICAgICAgICAgICB2ZXgudyA9IDA7CiAgICAgICAgIG9w
Y1sxXSA9IG1vZHJtICYgMHhjNzsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
UkVYX1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIGludm9r
ZV9zdHViKCIiLCAiIiwgIj1hIiAoZWEudmFsKSA6IFtkdW1teV0gImkiICgw
KSk7CkBAIC01NzMyLDcgKzU3MzIsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAg
ICAgICAgIG9wY1sxXSAmPSAweDM4OwogICAgICAgICB9CiAgICAgICAgIGlu
c25fYnl0ZXMgPSBQRlhfQllURVMgKyAyOwotICAgICAgICBvcGNbMl0gPSAw
eGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAgICAgICAgIGlm
ICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQogICAgICAgICB7CiAgICAgICAg
ICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJlZml4IGJ5dGUuICovCkBAIC02
MDEyLDcgKzYwMTIsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcHZleC0+
YiA9ICFtb2RlXzY0Yml0KCkgfHwgKHZleC5yZWcgPj4gMyk7CiAgICAgICAg
IG9wY1sxXSA9IDB4YzAgfCAofnZleC5yZWcgJiA3KTsKICAgICAgICAgcHZl
eC0+cmVnID0gMHhmOwotICAgICAgICBvcGNbMl0gPSAweGMzOworICAgICAg
ICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgaW52b2tlX3N0dWIo
IiIsICIiLCAiPWEiIChlYS52YWwpIDogW2R1bW15XSAiaSIgKDApKTsKICAg
ICAgICAgcHV0X3N0dWIoc3R1Yik7CkBAIC02Mjg2LDcgKzYyODYsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgICAgIGV2ZXgudyA9IDA7CiAgICAgICAg
IG9wY1sxXSA9IG1vZHJtICYgMHhmODsKICAgICAgICAgaW5zbl9ieXRlcyA9
IEVWRVhfUEZYX0JZVEVTICsgMjsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGNvcHlf
RVZFWChvcGMsIGV2ZXgpOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIs
ICI9ZyIgKGR1bW15KSA6ICJhIiAoc3JjLnZhbCkpOwpAQCAtNjM4NSw3ICs2
Mzg1LDcgQEAgeDg2X2VtdWxhdGUoCiAgICAgICAgIHB2ZXgtPmIgPSAxOwog
ICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAgICAg
ICAgcHZleC0+cmVnID0gMHhmOwotICAgICAgICBvcGNbMl0gPSAweGMzOwor
ICAgICAgICBwbGFjZV9yZXQoJm9wY1syXSk7CiAKICAgICAgICAgaW52b2tl
X3N0dWIoIiIsICIiLCAiPW0iICgqbW12YWxwKSA6ICJhIiAobW12YWxwKSk7
CiAKQEAgLTY0NTUsNyArNjQ1NSw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAg
ICBwdmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJtX3JlZyAm
IDcpIDw8IDM7CiAgICAgICAgIHB2ZXgtPnJlZyA9IDB4ZjsKLSAgICAgICAg
b3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwog
CiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAoKm1tdmFscCkg
OiAiYSIgKG1tdmFscCkpOwogCkBAIC02NTExLDcgKzY1MTEsNyBAQCB4ODZf
ZW11bGF0ZSgKICAgICAgICAgcGV2ZXgtPmIgPSAxOwogICAgICAgICBvcGNb
MV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAgICAgICAgcGV2ZXgtPlJY
ID0gMTsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsKKyAgICAgICAgcGxhY2Vf
cmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwg
Ij1tIiAoKm1tdmFscCkgOiAiYSIgKG1tdmFscCkpOwogCkBAIC02NTc2LDcg
KzY1NzYsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAgICAgcGV2ZXgtPmIgPSAx
OwogICAgICAgICBvcGNbMV0gPSAobW9kcm1fcmVnICYgNykgPDwgMzsKICAg
ICAgICAgcGV2ZXgtPlJYID0gMTsKLSAgICAgICAgb3BjWzJdID0gMHhjMzsK
KyAgICAgICAgcGxhY2VfcmV0KCZvcGNbMl0pOwogCiAgICAgICAgIGludm9r
ZV9zdHViKCIiLCAiIiwgIittIiAoKm1tdmFscCkgOiAiYSIgKG1tdmFscCkp
OwogCkBAIC02NTkwLDcgKzY1OTAsNyBAQCB4ODZfZW11bGF0ZSgKICAgICAg
ICAgb3BjWzJdID0gMHg5MDsKICAgICAgICAgLyogVXNlICglcmF4KSBhcyBz
b3VyY2UuICovCiAgICAgICAgIG9wY1szXSA9IGV2ZXgub3Btc2sgPDwgMzsK
LSAgICAgICAgb3BjWzRdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZv
cGNbNF0pOwogCiAgICAgICAgIGludm9rZV9zdHViKCIiLCAiIiwgIittIiAo
b3BfbWFzaykgOiAiYSIgKCZvcF9tYXNrKSk7CiAgICAgICAgIHB1dF9zdHVi
KHN0dWIpOwpAQCAtNjY2Niw3ICs2NjY2LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIHBldmV4LT5iID0gMTsKICAgICAgICAgb3BjWzFdID0gKG1vZHJt
X3JlZyAmIDcpIDw8IDM7CiAgICAgICAgIHBldmV4LT5SWCA9IDE7Ci0gICAg
ICAgIG9wY1syXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzJd
KTsKIAogICAgICAgICBpbnZva2Vfc3R1YigiIiwgIiIsICI9bSIgKCptbXZh
bHApIDogImEiIChtbXZhbHApKTsKIApAQCAtNjc0Myw3ICs2NzQzLDcgQEAg
eDg2X2VtdWxhdGUoCiAgICAgICAgIG9wY1syXSA9IDB4OTA7CiAgICAgICAg
IC8qIFVzZSAoJXJheCkgYXMgc291cmNlLiAqLwogICAgICAgICBvcGNbM10g
PSBldmV4Lm9wbXNrIDw8IDM7Ci0gICAgICAgIG9wY1s0XSA9IDB4YzM7Cisg
ICAgICAgIHBsYWNlX3JldCgmb3BjWzRdKTsKIAogICAgICAgICBpbnZva2Vf
c3R1YigiIiwgIiIsICIrbSIgKG9wX21hc2spIDogImEiICgmb3BfbWFzaykp
OwogICAgICAgICBwdXRfc3R1YihzdHViKTsKQEAgLTY5NDEsNyArNjk0MSw3
IEBAIHg4Nl9lbXVsYXRlKAogICAgICAgICBwdmV4LT5yZWcgPSAweGY7IC8q
IHJBWCAqLwogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZbNF0g
PSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVm
WzVdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAg
ICAgICAgIHNyYy5yZWcgPSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3Jl
Z3MsIGN0eHQpOwogICAgICAgICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0mYyIg
KGRzdC52YWwpLCAiW2RzdF0iICgmc3JjLnZhbCksICJhIiAoKnNyYy5yZWcp
KTsKQEAgLTY5NzcsNyArNjk3Nyw3IEBAIHg4Nl9lbXVsYXRlKAogICAgICAg
ICBwdmV4LT5yZWcgPSAweGY7IC8qIHJBWCAqLwogICAgICAgICBidWZbM10g
PSBiOwogICAgICAgICBidWZbNF0gPSAobW9kcm0gJiAweDM4KSB8IDB4MDE7
IC8qIHIvbT0oJXJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgIGRzdC5yZWcg
PSBkZWNvZGVfdmV4X2dwcih2ZXgucmVnLCAmX3JlZ3MsIGN0eHQpOwogICAg
ICAgICBlbXVsYXRlX3N0dWIoIj0mYSIgKGRzdC52YWwpLCAiYyIgKCZzcmMu
dmFsKSk7CkBAIC03MjE4LDcgKzcyMTgsNyBAQCB4ODZfZW11bGF0ZSgKICAg
ICAgICAgICAgIGV2ZXgudyA9IHZleC53ID0gMDsKICAgICAgICAgb3BjWzFd
ID0gbW9kcm0gJiAweDM4OwogICAgICAgICBvcGNbMl0gPSBpbW0xOwotICAg
ICAgICBvcGNbM10gPSAweGMzOworICAgICAgICBwbGFjZV9yZXQoJm9wY1sz
XSk7CiAgICAgICAgIGlmICggdmV4Lm9wY3ggPT0gdmV4X25vbmUgKQogICAg
ICAgICB7CiAgICAgICAgICAgICAvKiBDb3ZlciBmb3IgZXh0cmEgcHJlZml4
IGJ5dGUuICovCkBAIC03Mzg1LDcgKzczODUsNyBAQCB4ODZfZW11bGF0ZSgK
ICAgICAgICAgICAgIGluc25fYnl0ZXMgPSBQRlhfQllURVMgKyAzOwogICAg
ICAgICAgICAgY29weV9WRVgob3BjLCB2ZXgpOwogICAgICAgICB9Ci0gICAg
ICAgIG9wY1szXSA9IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmb3BjWzNd
KTsKIAogICAgICAgICAvKiBMYXRjaCBNWENTUiAtIHdlIG1heSBuZWVkIHRv
IHJlc3RvcmUgaXQgYmVsb3cuICovCiAgICAgICAgIGludm9rZV9zdHViKCJz
dG14Y3NyICVbbXhjc3JdIiwgIiIsCkBAIC03NjMxLDcgKzc2MzEsNyBAQCB4
ODZfZW11bGF0ZSgKICAgICAgICAgfQogICAgICAgICBvcGNbMl0gPSBpbW0x
OwogICAgICAgICBpbnNuX2J5dGVzID0gUEZYX0JZVEVTICsgMzsKLSAgICAg
ICAgb3BjWzNdID0gMHhjMzsKKyAgICAgICAgcGxhY2VfcmV0KCZvcGNbM10p
OwogICAgICAgICBpZiAoIHZleC5vcGN4ID09IHZleF9ub25lICkKICAgICAg
ICAgewogICAgICAgICAgICAgLyogQ292ZXIgZm9yIGV4dHJhIHByZWZpeCBi
eXRlLiAqLwpAQCAtNzk3Nyw3ICs3OTc3LDcgQEAgeDg2X2VtdWxhdGUoCiAg
ICAgICAgIHB4b3AtPnJlZyA9IDB4ZjsgLyogckFYICovCiAgICAgICAgIGJ1
ZlszXSA9IGI7CiAgICAgICAgIGJ1Zls0XSA9IChtb2RybSAmIDB4MzgpIHwg
MHgwMTsgLyogci9tPSglckNYKSAqLwotICAgICAgICBidWZbNV0gPSAweGMz
OworICAgICAgICBwbGFjZV9yZXQoJmJ1Zls1XSk7CiAKICAgICAgICAgZHN0
LnJlZyA9IGRlY29kZV92ZXhfZ3ByKHZleC5yZWcsICZfcmVncywgY3R4dCk7
CiAgICAgICAgIGVtdWxhdGVfc3R1YihbZHN0XSAiPSZhIiAoZHN0LnZhbCks
ICJjIiAoJnNyYy52YWwpKTsKQEAgLTgwODYsNyArODA4Niw3IEBAIHg4Nl9l
bXVsYXRlKAogICAgICAgICBidWZbM10gPSBiOwogICAgICAgICBidWZbNF0g
PSAweDA5OyAvKiByZWc9ckNYIHIvbT0oJXJDWCkgKi8KICAgICAgICAgKih1
aW50MzJfdCAqKShidWYgKyA1KSA9IGltbTE7Ci0gICAgICAgIGJ1Zls5XSA9
IDB4YzM7CisgICAgICAgIHBsYWNlX3JldCgmYnVmWzldKTsKIAogICAgICAg
ICBlbXVsYXRlX3N0dWIoW2RzdF0gIj0mYyIgKGRzdC52YWwpLCAiW2RzdF0i
ICgmc3JjLnZhbCkpOwogCkBAIC04MTgyLDEyICs4MTgyLDEyIEBAIHg4Nl9l
bXVsYXRlKAogCiAgICAgICAgIGlmICggZXZleF9lbmNvZGVkKCkgKQogICAg
ICAgICB7Ci0gICAgICAgICAgICBvcGNbaW5zbl9ieXRlcyAtIEVWRVhfUEZY
X0JZVEVTXSA9IDB4YzM7CisgICAgICAgICAgICBwbGFjZV9yZXQoJm9wY1tp
bnNuX2J5dGVzIC0gRVZFWF9QRlhfQllURVNdKTsKICAgICAgICAgICAgIGNv
cHlfRVZFWChvcGMsIGV2ZXgpOwogICAgICAgICB9CiAgICAgICAgIGVsc2UK
ICAgICAgICAgewotICAgICAgICAgICAgb3BjW2luc25fYnl0ZXMgLSBQRlhf
QllURVNdID0gMHhjMzsKKyAgICAgICAgICAgIHBsYWNlX3JldCgmb3BjW2lu
c25fYnl0ZXMgLSBQRlhfQllURVNdKTsKICAgICAgICAgICAgIGNvcHlfUkVY
X1ZFWChvcGMsIHJleF9wcmVmaXgsIHZleCk7CiAgICAgICAgIH0KIApAQCAt
ODUxMSw3ICs4NTExLDcgQEAgaW50IHg4Nl9lbXVsX3JtdygKICAgICAgICAg
cHZleC0+cmVnID0gMHhmOyAvKiByQVggKi8KICAgICAgICAgYnVmWzNdID0g
Y3R4dC0+b3Bjb2RlOwogICAgICAgICBidWZbNF0gPSAweDExOyAvKiByZWc9
ckRYIHIvbT0oJVJDWCkgKi8KLSAgICAgICAgYnVmWzVdID0gMHhjMzsKKyAg
ICAgICAgcGxhY2VfcmV0KCZidWZbNV0pOwogCiAgICAgICAgICplZmxhZ3Mg
Jj0gfkVGTEFHU19NQVNLOwogICAgICAgICBpbnZva2Vfc3R1YigiIiwK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-06.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-06.patch"
Content-Transfer-Encoding: base64

RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0
OiB4ODYvdGh1bms6IEJ1aWxkIFhlbiB3aXRoIFJldHVybiBUaHVua3MKClRo
ZSBJbmRpcmVjdCBUYXJnZXQgU2VsZWN0aW9uIHNwZWN1bGF0aXZlIHZ1bG5l
cmFiaWxpdHkgbWVhbnMgdGhhdCBpbmRpcmVjdApicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGFyZSB1bnNhZmUgd2hlbiBpbiB0aGUgZmlyc3QgaGFsZiBv
ZiBhIGNhY2hlbGluZS4KCkluIG9yZGVyIHRvIG1pdGlnYXRlIHRoaXMsIGJ1
aWxkIHdpdGggcmV0dXJuIHRodW5rcyBhbmQgYXJyYW5nZSBmb3IKX194ODZf
cmV0dXJuX3RodW5rIHRvIGJlIChtaXMpYWxpZ25lZCBpbiB0aGUgc2FtZSBt
YW5uZXIgYXMKX194ODZfaW5kaXJlY3RfdGh1bmtfKiBzbyB0aGUgUkVUIGlu
c3RydWN0aW9uIGlzIHBsYWNlZCBpbiBhIHNhZmUgbG9jYXRpb24uCgpwbGFj
ZV9yZXQoKSBuZWVkcyB0byBjb25kaXRpb25hbGx5IGVtaXQgSk1QIF9feDg2
X3JldHVybl90aHVuayBpbnN0ZWFkIG9mIFJFVC4KClRoaXMgaXMgcGFydCBv
ZiBYU0EtNDY5IC8gQ1ZFLTIwMjQtMjg5NTYKClNpZ25lZC1vZmYtYnk6IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KU2lnbmVkLW9mZi1ieTog
QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KUmV2
aWV3ZWQtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXgu
Y29tPgoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnIGIveGVu
L2FyY2gveDg2L0tjb25maWcKaW5kZXggZGUyZmEzN2YwODhkLi43YWZlODc5
NzEwYmUgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9LY29uZmlnCisrKyBi
L3hlbi9hcmNoL3g4Ni9LY29uZmlnCkBAIC0zOSw5ICszOSwxNCBAQCBjb25m
aWcgQVJDSF9ERUZDT05GSUcKIAlkZWZhdWx0ICJhcmNoL3g4Ni9jb25maWdz
L3g4Nl82NF9kZWZjb25maWciCiAKIGNvbmZpZyBDQ19IQVNfSU5ESVJFQ1Rf
VEhVTksKKwkjIEdDQyA+PSA4IG9yIENsYW5nID49IDYKIAlkZWZfYm9vbCAk
KGNjLW9wdGlvbiwtbWluZGlyZWN0LWJyYW5jaC1yZWdpc3RlcikgfHwgXAog
CSAgICAgICAgICQoY2Mtb3B0aW9uLC1tcmV0cG9saW5lLWV4dGVybmFsLXRo
dW5rKQogCitjb25maWcgQ0NfSEFTX1JFVFVSTl9USFVOSworCSMgR0NDID49
IDggb3IgQ2xhbmcgPj0gMTUKKwlkZWZfYm9vbCAkKGNjLW9wdGlvbiwtbWZ1
bmN0aW9uLXJldHVybj10aHVuay1leHRlcm4pCisKIGNvbmZpZyBIQVNfQVNf
Q0VUX1NTCiAJIyBiaW51dGlscyA+PSAyLjI5IG9yIExMVk0gPj0gNgogCWRl
Zl9ib29sICQoYXMtaW5zdHIsd3Jzc3EgJXJheCQoY29tbWEpMDtzZXRzc2Jz
eSkKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9NYWtlZmlsZSBiL3hlbi9h
cmNoL3g4Ni9NYWtlZmlsZQppbmRleCBjMzJhYmEwMjlkNDQuLmJlZGI5N2Ni
ZWVkOSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L01ha2VmaWxlCisrKyBi
L3hlbi9hcmNoL3g4Ni9NYWtlZmlsZQpAQCAtNDMsNiArNDMsNyBAQCBvYmot
JChDT05GSUdfTElWRVBBVENIKSArPSBsaXZlcGF0Y2gubwogb2JqLXkgKz0g
bXNpLm8KIG9iai15ICs9IG1zci5vCiBvYmotJChDT05GSUdfSU5ESVJFQ1Rf
VEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KK29iai0kKENPTkZJR19SRVRV
Uk5fVEhVTkspICs9IGluZGlyZWN0LXRodW5rLm8KIG9iai0kKENPTkZJR19Q
VikgKz0gaW9wb3J0X2VtdWxhdGUubwogb2JqLXkgKz0gaXJxLm8KIG9iai0k
KENPTkZJR19LRVhFQykgKz0gbWFjaGluZV9rZXhlYy5vCmRpZmYgLS1naXQg
YS94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJvdC5TIGIveGVuL2FyY2gv
eDg2L2FjcGkvd2FrZXVwX3Byb3QuUwppbmRleCBhNzQxZDU4YjkxMTcuLjky
YWY2MjMwYjMxZiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvd2Fr
ZXVwX3Byb3QuUworKysgYi94ZW4vYXJjaC94ODYvYWNwaS93YWtldXBfcHJv
dC5TCkBAIC0xMzMsNyArMTMzLDcgQEAgTEFCRUwoczNfcmVzdW1lKQogICAg
ICAgICBwb3AgICAgICVyMTIKICAgICAgICAgcG9wICAgICAlcmJ4CiAgICAg
ICAgIHBvcCAgICAgJXJicAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBF
TkQoZG9fc3VzcGVuZF9sb3dsZXZlbCkKIAogLmRhdGEKZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jIGIveGVuL2FyY2gveDg2L2Fs
dGVybmF0aXZlLmMKaW5kZXggMDQ0OWI5YzFiN2U1Li5lY2M1Njk2NGJkOWMg
MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCisrKyBi
L3hlbi9hcmNoL3g4Ni9hbHRlcm5hdGl2ZS5jCkBAIC0xMzUsMTYgKzEzNSw0
NSBAQCB2b2lkIGluaXRfb3JfbGl2ZXBhdGNoIGFkZF9ub3BzKHZvaWQgKmlu
c25zLCB1bnNpZ25lZCBpbnQgbGVuKQogICAgIH0KIH0KIAordm9pZCBub2Nh
bGwgX194ODZfcmV0dXJuX3RodW5rKHZvaWQpOworCiAvKgogICogUGxhY2Ug
YSByZXR1cm4gYXQgQHB0ci4gIEBwdHIgbXVzdCBiZSBpbiB0aGUgd3JpdGFi
bGUgYWxpYXMgb2YgYSBzdHViLgogICoKKyAqIFdoZW4gQ09ORklHX1JFVFVS
Tl9USFVOSyBpcyBhY3RpdmUsIHRoaXMgbWF5IGJlIGEgSk1QIF9feDg2X3Jl
dHVybl90aHVuaworICogaW5zdGVhZCwgZGVwZW5kaW5nIG9uIHRoZSBzYWZl
dHkgb2YgQHB0ciB3aXRoIHJlc3BlY3QgdG8gSW5kaXJlY3QgVGFyZ2V0Cisg
KiBTZWxlY3Rpb24uCisgKgogICogUmV0dXJucyB0aGUgbmV4dCBwb3NpdGlv
biB0byB3cml0ZSBpbnRvIHRoZSBzdHViLgogICovCiB2b2lkICpwbGFjZV9y
ZXQodm9pZCAqcHRyKQogeworICAgIHVuc2lnbmVkIGxvbmcgYWRkciA9ICh1
bnNpZ25lZCBsb25nKXB0cjsKICAgICB1aW50OF90ICpwID0gcHRyOwogCi0g
ICAgKnArKyA9IDB4YzM7CisgICAgLyoKKyAgICAgKiBXaGVuIFJldHVybiBU
aHVua3MgYXJlIHVzZWQsIGlmIGEgUkVUIHdvdWxkIGJlIHVuc2FmZSBhdCB0
aGlzIGxvY2F0aW9uCisgICAgICogd2l0aCByZXNwZWN0IHRvIEluZGlyZWN0
IFRhcmdldCBTZWxlY3Rpb24gKGkuZS4gaWYgYWRkciBpcyBpbiB0aGUgZmly
c3QKKyAgICAgKiBoYWxmIG9mIGEgY2FjaGVsaW5lKSwgaW5zZXJ0IGEgSk1Q
IF9feDg2X3JldHVybl90aHVuayBpbnN0ZWFkLgorICAgICAqCisgICAgICog
VGhlIGRpc3BsYWNlbWVudCBuZWVkcyB0byBiZSByZWxhdGl2ZSB0byB0aGUg
ZXhlY3V0YWJsZSBhbGlhcyBvZiB0aGUKKyAgICAgKiBzdHViLCBub3QgdG8g
QHB0ciB3aGljaCBpcyB0aGUgd3JpdGVhYmxlIGFsaWFzLgorICAgICAqLwor
ICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfUkVUVVJOX1RIVU5LKSAmJiAh
KGFkZHIgJiAweDIwKSApCisgICAgeworICAgICAgICBsb25nIHN0dWJfdmEg
PSAodGhpc19jcHUoc3R1YnMuYWRkcikgJiBQQUdFX01BU0spICsgKGFkZHIg
JiB+UEFHRV9NQVNLKTsKKyAgICAgICAgbG9uZyBkaXNwID0gKGxvbmcpX194
ODZfcmV0dXJuX3RodW5rIC0gKHN0dWJfdmEgKyA1KTsKKworICAgICAgICBC
VUdfT04oKGludDMyX3QpZGlzcCAhPSBkaXNwKTsKKworICAgICAgICAqcCsr
ID0gMHhlOTsKKyAgICAgICAgKihpbnQzMl90ICopcCA9IGRpc3A7CisgICAg
ICAgIHAgKz0gNDsKKyAgICB9CisgICAgZWxzZQorICAgIHsKKyAgICAgICAg
KnArKyA9IDB4YzM7CisgICAgfQogCiAgICAgcmV0dXJuIHA7CiB9CmRpZmYg
LS1naXQgYS94ZW4vYXJjaC94ODYvYXJjaC5tayBiL3hlbi9hcmNoL3g4Ni9h
cmNoLm1rCmluZGV4IDA5YjZkODc1OGU5NS4uNDk5MTU0NTEyNTlmIDEwMDY0
NAotLS0gYS94ZW4vYXJjaC94ODYvYXJjaC5taworKysgYi94ZW4vYXJjaC94
ODYvYXJjaC5tawpAQCAtMzQsNiArMzQsOSBAQCBDRkxBR1MtJChDT05GSUdf
Q0NfSVNfR0NDKSArPSAtZm5vLWp1bXAtdGFibGVzCiBDRkxBR1MtJChDT05G
SUdfQ0NfSVNfQ0xBTkcpICs9IC1tcmV0cG9saW5lLWV4dGVybmFsLXRodW5r
CiBlbmRpZgogCisjIENvbXBpbGUgd2l0aCByZXR1cm4gdGh1bmsgc3VwcG9y
dCBpZiBzZWxlY3RlZC4KK0NGTEFHUy0kKENPTkZJR19SRVRVUk5fVEhVTksp
ICs9IC1tZnVuY3Rpb24tcmV0dXJuPXRodW5rLWV4dGVybgorCiAjIERpc2Fi
bGUgdGhlIGFkZGl0aW9uIG9mIGEgLm5vdGUuZ251LnByb3BlcnR5IHNlY3Rp
b24gdG8gb2JqZWN0IGZpbGVzIHdoZW4KICMgbGl2ZXBhdGNoIHN1cHBvcnQg
aXMgZW5hYmxlZC4gIFRoZSBjb250ZW50cyBvZiB0aGF0IHNlY3Rpb24gY2Fu
IGNoYW5nZQogIyBkZXBlbmRpbmcgb24gdGhlIGluc3RydWN0aW9ucyB1c2Vk
LCBhbmQgbGl2ZXBhdGNoLWJ1aWxkLXRvb2xzIGRvZXNuJ3Qga25vdwpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2JoYi10aHVuay5TIGIveGVuL2FyY2gv
eDg2L2JoYi10aHVuay5TCmluZGV4IDcxNzU3NzhiZGQxMS4uNjA2YjM3OGQ4
NGNmIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvYmhiLXRodW5rLlMKKysr
IGIveGVuL2FyY2gveDg2L2JoYi10aHVuay5TCkBAIC0yMyw3ICsyMyw3IEBA
IEZVTkMoY2xlYXJfYmhiX3RzeCkKICAgICAgICAgeGFib3J0ICAkMAogICAg
ICAgICBpbnQzCiAxOgotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQo
Y2xlYXJfYmhiX3RzeCkKIAogLyoKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4
Ni9jbGVhcl9wYWdlLlMgYi94ZW4vYXJjaC94ODYvY2xlYXJfcGFnZS5TCmlu
ZGV4IGQ2YzA3NmYxZDhiYy4uZGMzYzNjMjZiZmI3IDEwMDY0NAotLS0gYS94
ZW4vYXJjaC94ODYvY2xlYXJfcGFnZS5TCisrKyBiL3hlbi9hcmNoL3g4Ni9j
bGVhcl9wYWdlLlMKQEAgLTEsNiArMSw4IEBACiAgICAgICAgIC5maWxlIF9f
RklMRV9fCiAKICNpbmNsdWRlIDx4ZW4vbGlua2FnZS5oPgorCisjaW5jbHVk
ZSA8YXNtL2FzbV9kZWZucy5oPgogI2luY2x1ZGUgPGFzbS9wYWdlLmg+CiAK
IEZVTkMoY2xlYXJfcGFnZV9zc2UyKQpAQCAtMTYsNSArMTgsNSBAQCBGVU5D
KGNsZWFyX3BhZ2Vfc3NlMikKICAgICAgICAgam56ICAgICAwYgogCiAgICAg
ICAgIHNmZW5jZQotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQoY2xl
YXJfcGFnZV9zc2UyKQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2NvcHlf
cGFnZS5TIGIveGVuL2FyY2gveDg2L2NvcHlfcGFnZS5TCmluZGV4IGMzYzQz
NjU0NWJhYy4uZTQzZTUzNzBjODE1IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94
ODYvY29weV9wYWdlLlMKKysrIGIveGVuL2FyY2gveDg2L2NvcHlfcGFnZS5T
CkBAIC0xLDYgKzEsOCBAQAogICAgICAgICAuZmlsZSBfX0ZJTEVfXwogCiAj
aW5jbHVkZSA8eGVuL2xpbmthZ2UuaD4KKworI2luY2x1ZGUgPGFzbS9hc21f
ZGVmbnMuaD4KICNpbmNsdWRlIDxhc20vcGFnZS5oPgogCiAjZGVmaW5lIHNy
Y19yZWcgJXJzaQpAQCAtNDEsNSArNDMsNSBAQCBGVU5DKGNvcHlfcGFnZV9z
c2UyKQogICAgICAgICBtb3ZudGkgIHRtcDRfcmVnLCAzKldPUkRfU0laRShk
c3RfcmVnKQogCiAgICAgICAgIHNmZW5jZQotICAgICAgICByZXQKKyAgICAg
ICAgUkVUCiBFTkQoY29weV9wYWdlX3NzZTIpCmRpZmYgLS1naXQgYS94ZW4v
YXJjaC94ODYvZWZpL2NoZWNrLmMgYi94ZW4vYXJjaC94ODYvZWZpL2NoZWNr
LmMKaW5kZXggOWU0NzNmYWFkM2M5Li4yM2JhMzBhYmYzMzAgMTAwNjQ0Ci0t
LSBhL3hlbi9hcmNoL3g4Ni9lZmkvY2hlY2suYworKysgYi94ZW4vYXJjaC94
ODYvZWZpL2NoZWNrLmMKQEAgLTMsNiArMyw5IEBAIGludCBfX2F0dHJpYnV0
ZV9fKChfX21zX2FiaV9fKSkgdGVzdChpbnQgaSkKICAgICByZXR1cm4gaTsK
IH0KIAorLyogSW4gY2FzZSAtbWZ1bmN0aW9uLXJldHVybiBpcyBpbiB1c2Uu
ICovCit2b2lkIF9feDg2X3JldHVybl90aHVuayh2b2lkKSB7fTsKKwogLyoK
ICAqIFBvcHVsYXRlIGFuIGFycmF5IHdpdGggImFkZHJlc3NlcyIgb2YgcmVs
b2NhdGFibGUgYW5kIGFic29sdXRlIHZhbHVlcy4KICAqIFRoaXMgaXMgdG8g
cHJvYmUgbGQgZm9yIChhKSBlbWl0dGluZyBiYXNlIHJlbG9jYXRpb25zIGF0
IGFsbCBhbmQgKGIpIG5vdApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL2FzbS1kZWZucy5oIGIveGVuL2FyY2gveDg2L2luY2x1ZGUv
YXNtL2FzbS1kZWZucy5oCmluZGV4IDFiODIxZGI0OWNhMy4uOTYzNzBkZDky
YTU4IDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYXNt
LWRlZm5zLmgKKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2FzbS1k
ZWZucy5oCkBAIC0zNiw2ICszNiwxMiBAQAogICAgIC5lbmRpZgogLmVuZG0K
IAorI2lmZGVmIENPTkZJR19SRVRVUk5fVEhVTksKKyMgZGVmaW5lIFJFVCBq
bXAgX194ODZfcmV0dXJuX3RodW5rCisjZWxzZQorIyBkZWZpbmUgUkVUIHJl
dAorI2VuZGlmCisKICNpZmRlZiBDT05GSUdfWEVOX0lCVAogIyBkZWZpbmUg
RU5EQlI2NCBlbmRicjY0CiAjZWxzZQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
eDg2L2luZGlyZWN0LXRodW5rLlMgYi94ZW4vYXJjaC94ODYvaW5kaXJlY3Qt
dGh1bmsuUwppbmRleCBjNGI5NzhkNjdiOGUuLjI2ZGFkMTVmMTJjOSAxMDA2
NDQKLS0tIGEveGVuL2FyY2gveDg2L2luZGlyZWN0LXRodW5rLlMKKysrIGIv
eGVuL2FyY2gveDg2L2luZGlyZWN0LXRodW5rLlMKQEAgLTE1LDYgKzE1LDgg
QEAKICN1bmRlZiBTWU1fQUxJR04KICNkZWZpbmUgU1lNX0FMSUdOKGFsaWdu
Li4uKQogCisjaWZkZWYgQ09ORklHX0lORElSRUNUX1RIVU5LCisKIC5tYWNy
byBJTkRfVEhVTktfUkVUUE9MSU5FIHJlZzpyZXEKICAgICAgICAgY2FsbCAx
ZgogICAgICAgICBpbnQzCkBAIC02MiwzICs2NCwyNSBAQCBFTkQoX194ODZf
aW5kaXJlY3RfdGh1bmtfXHJlZykKIC5pcnAgcmVnLCBheCwgY3gsIGR4LCBi
eCwgYnAsIHNpLCBkaSwgOCwgOSwgMTAsIDExLCAxMiwgMTMsIDE0LCAxNQog
ICAgICAgICBHRU5fSU5ESVJFQ1RfVEhVTksgcmVnPXJccmVnCiAuZW5kcgor
CisjZW5kaWYgLyogQ09ORklHX0lORElSRUNUX1RIVU5LICovCisKKyNpZmRl
ZiBDT05GSUdfUkVUVVJOX1RIVU5LCisgICAgICAgIC5zZWN0aW9uIC50ZXh0
LmVudHJ5Ll9feDg2X3JldHVybl90aHVuaywgImF4IiwgQHByb2diaXRzCisK
KyAgICAgICAgLyoKKyAgICAgICAgICogVGhlIEluZGlyZWN0IFRhcmdldCBT
ZWxlY3Rpb24gc3BlY3VsYXRpdmUgdnVsbmVyYWJpbGl0eSBtZWFucyB0aGF0
CisgICAgICAgICAqIGluZGlyZWN0IGJyYW5jaGVzIChpbmNsdWRpbmcgUkVU
cykgYXJlIHVuc2FmZSB3aGVuIGluIHRoZSBmaXJzdAorICAgICAgICAgKiBo
YWxmIG9mIGEgY2FjaGVsaW5lLiAgQXJyYW5nZSBmb3IgdGhlbSB0byBiZSBp
biB0aGUgc2Vjb25kIGhhbGYuCisgICAgICAgICAqCisgICAgICAgICAqIEFs
aWduIHRvIDY0LCB0aGVuIHNraXAgMzIuCisgICAgICAgICAqLworICAgICAg
ICAuYmFsaWduIDY0CisgICAgICAgIC5maWxsIDMyLCAxLCAweGNjCisKK0ZV
TkMoX194ODZfcmV0dXJuX3RodW5rKQorICAgICAgICByZXQKKyAgICAgICAg
aW50MyAvKiBIYWx0IHN0cmFpZ2h0LWxpbmUgc3BlY3VsYXRpb24gKi8KK0VO
RChfX3g4Nl9yZXR1cm5fdGh1bmspCisKKyNlbmRpZiAvKiBDT05GSUdfUkVU
VVJOX1RIVU5LICovCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvcHYvZW11
bC1wcml2LW9wLmMgYi94ZW4vYXJjaC94ODYvcHYvZW11bC1wcml2LW9wLmMK
aW5kZXggZmY1ZDFjOWY4NjM0Li4yOTVkODQ3ZWEyNGMgMTAwNjQ0Ci0tLSBh
L3hlbi9hcmNoL3g4Ni9wdi9lbXVsLXByaXYtb3AuYworKysgYi94ZW4vYXJj
aC94ODYvcHYvZW11bC1wcml2LW9wLmMKQEAgLTEzMSw3ICsxMzEsNyBAQCBz
dGF0aWMgaW9fZW11bF9zdHViX3QgKmlvX2VtdWxfc3R1Yl9zZXR1cChzdHJ1
Y3QgcHJpdl9vcF9jdHh0ICpjdHh0LCB1OCBvcGNvZGUsCiAgICAgQlVJTERf
QlVHX09OKFNUVUJfQlVGX1NJWkUgLyAyIDwKICAgICAgICAgICAgICAgICAg
KHNpemVvZihwcm9sb2d1ZSkgKyBzaXplb2YoZXBpbG9ndWUpICsgMTAgLyog
MnggY2FsbCAqLyArCiAgICAgICAgICAgICAgICAgICBNQVgoMyAvKiBkZWZh
dWx0IHN0dWIgKi8sIElPRU1VTF9RVUlSS19TVFVCX0JZVEVTKSArCi0gICAg
ICAgICAgICAgICAgICAxIC8qIHJldCAqLykpOworICAgICAgICAgICAgICAg
ICAgKElTX0VOQUJMRUQoQ09ORklHX1JFVFVSTl9USFVOSykgPyA1IDogMSkg
LyogcmV0ICovKSk7CiAgICAgLyogUnVudGltZSBjb25maXJtYXRpb24gdGhh
dCB3ZSBoYXZlbid0IGNsb2JiZXJlZCBhbiBhZGphY2VudCBzdHViLiAqLwog
ICAgIEJVR19PTihTVFVCX0JVRl9TSVpFIC8gMiA8IChwIC0gY3R4dC0+aW9f
ZW11bF9zdHViKSk7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9wdi9n
cHJfc3dpdGNoLlMgYi94ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5TCmlu
ZGV4IDU0MDlhZDNiMTQ0Ny4uMzYyYjVkMjQxNjIzIDEwMDY0NAotLS0gYS94
ZW4vYXJjaC94ODYvcHYvZ3ByX3N3aXRjaC5TCisrKyBiL3hlbi9hcmNoL3g4
Ni9wdi9ncHJfc3dpdGNoLlMKQEAgLTI2LDcgKzI2LDcgQEAgRlVOQyhsb2Fk
X2d1ZXN0X2dwcnMpCiAgICAgICAgIG1vdnEgIFVSRUdTX3IxNSglcmRpKSwg
JXIxNQogICAgICAgICBtb3ZxICBVUkVHU19yY3goJXJkaSksICVyY3gKICAg
ICAgICAgbW92cSAgVVJFR1NfcmRpKCVyZGkpLCAlcmRpCi0gICAgICAgIHJl
dAorICAgICAgICBSRVQKIEVORChsb2FkX2d1ZXN0X2dwcnMpCiAKIC8qIFNh
dmUgZ3Vlc3QgR1BScy4gIFBhcmFtZXRlciBvbiB0aGUgc3RhY2sgYWJvdmUg
dGhlIHJldHVybiBhZGRyZXNzLiAqLwpAQCAtNDgsNSArNDgsNSBAQCBGVU5D
KHNhdmVfZ3Vlc3RfZ3BycykKICAgICAgICAgbW92cSAgJXJieCwgVVJFR1Nf
cmJ4KCVyZGkpCiAgICAgICAgIG1vdnEgICVyZHgsIFVSRUdTX3JkeCglcmRp
KQogICAgICAgICBtb3ZxICAlcmN4LCBVUkVHU19yY3goJXJkaSkKLSAgICAg
ICAgcmV0CisgICAgICAgIFJFVAogRU5EKHNhdmVfZ3Vlc3RfZ3BycykKZGlm
ZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNo
L3g4Ni9zcGVjX2N0cmwuYwppbmRleCBjZWQ4NDc1MDAxNWMuLmZlMjdlODJh
NDcwNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCisr
KyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwpAQCAtNTcxLDYgKzU3MSw5
IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5k
X3RodW5rIHRodW5rKQogI2lmZGVmIENPTkZJR19JTkRJUkVDVF9USFVOSwog
ICAgICAgICAgICAgICAgIiBJTkRJUkVDVF9USFVOSyIKICNlbmRpZgorI2lm
ZGVmIENPTkZJR19SRVRVUk5fVEhVTksKKyAgICAgICAgICAgICAgICIgUkVU
VVJOX1RIVU5LIgorI2VuZGlmCiAjaWZkZWYgQ09ORklHX1NIQURPV19QQUdJ
TkcKICAgICAgICAgICAgICAgICIgU0hBRE9XX1BBR0lORyIKICNlbmRpZgpk
aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3g4Nl82NC9jb21wYXQvZW50cnku
UyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKaW5kZXgg
MWU4NzY1MmY0YmNiLi5kN2IzODFlYTU0NmQgMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni94ODZfNjQvY29tcGF0L2VudHJ5LlMKKysrIGIveGVuL2FyY2gv
eDg2L3g4Nl82NC9jb21wYXQvZW50cnkuUwpAQCAtMTgwLDcgKzE4MCw3IEBA
IEZVTkMoY3I0X3B2MzJfcmVzdG9yZSkKICAgICAgICAgb3IgICAgY3I0X3B2
MzJfbWFzayglcmlwKSwgJXJheAogICAgICAgICBtb3YgICAlcmF4LCAlY3I0
CiAgICAgICAgIG1vdiAgICVyYXgsICglcmN4KQotICAgICAgICByZXQKKyAg
ICAgICAgUkVUCiAwOgogI2lmbmRlZiBOREVCVUcKICAgICAgICAgLyogQ2hl
Y2sgdGhhdCBfYWxsXyBvZiB0aGUgYml0cyBpbnRlbmRlZCB0byBiZSBzZXQg
YWN0dWFsbHkgYXJlLiAqLwpAQCAtMTk4LDcgKzE5OCw3IEBAIEZVTkMoY3I0
X3B2MzJfcmVzdG9yZSkKIDE6CiAjZW5kaWYKICAgICAgICAgeG9yICAgJWVh
eCwgJWVheAotICAgICAgICByZXQKKyAgICAgICAgUkVUCiBFTkQoY3I0X3B2
MzJfcmVzdG9yZSkKIAogRlVOQyhjb21wYXRfc3lzY2FsbCkKQEAgLTMyOSw3
ICszMjksNyBAQCBfX1VOTElLRUxZX0VORChjb21wYXRfYm91bmNlX251bGxf
c2VsZWN0b3IpCiAgICAgICAgIHhvciAgICVlYXgsICVlYXgKICAgICAgICAg
bW92ICAgJWF4LCAgVFJBUEJPVU5DRV9jcyglcmR4KQogICAgICAgICBtb3Yg
ICAlYWwsICBUUkFQQk9VTkNFX2ZsYWdzKCVyZHgpCi0gICAgICAgIHJldAor
ICAgICAgICBSRVQKIAogLnNlY3Rpb24gLmZpeHVwLCJheCIKIC5MZngxMzoK
ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUyBiL3hl
bi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwppbmRleCBkODFhNjI2ZDE2Njcu
LjM5YzdiOWQxN2Y5ZSAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3g4Nl82
NC9lbnRyeS5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ODZfNjQvZW50cnkuUwpA
QCAtNjA0LDcgKzYwNCw3IEBAIF9fVU5MSUtFTFlfRU5EKGNyZWF0ZV9ib3Vu
Y2VfZnJhbWVfYmFkX2JvdW5jZV9pcCkKICAgICAgICAgeG9yICAgJWVheCwg
JWVheAogICAgICAgICBtb3YgICAlcmF4LCBUUkFQQk9VTkNFX2VpcCglcmR4
KQogICAgICAgICBtb3YgICAlYWwsICBUUkFQQk9VTkNFX2ZsYWdzKCVyZHgp
Ci0gICAgICAgIHJldAorICAgICAgICBSRVQKIAogICAgICAgICAucHVzaHNl
Y3Rpb24gLmZpeHVwLCAiYXgiLCBAcHJvZ2JpdHMKICAgICAgICAgIyBOdW1l
cmljIHRhZ3MgYmVsb3cgcmVwcmVzZW50IHRoZSBpbnRlbmRlZCBvdmVyYWxs
ICVyc2kgYWRqdXN0bWVudC4KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni94
ZW4ubGRzLlMgYi94ZW4vYXJjaC94ODYveGVuLmxkcy5TCmluZGV4IDUzYmFm
Yzk4YTUzNi4uYmY5NTZiNmM1ZmMwIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94
ODYveGVuLmxkcy5TCisrKyBiL3hlbi9hcmNoL3g4Ni94ZW4ubGRzLlMKQEAg
LTg1LDYgKzg1LDcgQEAgU0VDVElPTlMKICAgICAgICAuID0gQUxJR04oUEFH
RV9TSVpFKTsKICAgICAgICBfc3RleHRlbnRyeSA9IC47CiAgICAgICAgKigu
dGV4dC5lbnRyeSkKKyAgICAgICAqKC50ZXh0LmVudHJ5LiopCiAgICAgICAg
LiA9IEFMSUdOKFBBR0VfU0laRSk7CiAgICAgICAgX2V0ZXh0ZW50cnkgPSAu
OwogCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL0tjb25maWcgYi94ZW4vY29t
bW9uL0tjb25maWcKaW5kZXggYmY3YjA4MWFkMGI3Li42ZDQzYmUyZTZlOGEg
MTAwNjQ0Ci0tLSBhL3hlbi9jb21tb24vS2NvbmZpZworKysgYi94ZW4vY29t
bW9uL0tjb25maWcKQEAgLTE3Miw2ICsxNzIsMTcgQEAgY29uZmlnIElORElS
RUNUX1RIVU5LCiAJICBieSBjaG9vc2luZyBhIGhhcmR3YXJlLWRlcGVuZGVu
dCBpbnN0cnVjdGlvbiBzZXF1ZW5jZSB0byBpbXBsZW1lbnQKIAkgIChlLmcu
IGZ1bmN0aW9uIHBvaW50ZXJzKSBzYWZlbHkuICAiUmV0cG9saW5lIiBpcyBv
bmUgc3VjaCBzZXF1ZW5jZS4KIAorY29uZmlnIFJFVFVSTl9USFVOSworCWJv
b2wgIk91dC1vZi1saW5lIFJldHVybnMiCisJZGVwZW5kcyBvbiBDQ19IQVNf
UkVUVVJOX1RIVU5LCisJZGVmYXVsdCBJTkRJUkVDVF9USFVOSworCWhlbHAK
KwkgIENvbXBpbGUgWGVuIHdpdGggb3V0LW9mLWxpbmUgcmV0dXJucy4KKwor
CSAgVGhpcyBhbGxvd3MgWGVuIHRvIG1pdGlnYXRlIGEgdmFyaWV0eSBvZiBz
cGVjdWxhdGl2ZSB2dWxuZXJhYmlsaXRpZXMKKwkgIGJ5IGNob29zaW5nIGEg
aGFyZHdhcmUtZGVwZW5kZW50IGluc3RydWN0aW9uIHNlcXVlbmNlIHRvIGlt
cGxlbWVudAorCSAgZnVuY3Rpb24gcmV0dXJucyBzYWZlbHkuCisKIGNvbmZp
ZyBTUEVDVUxBVElWRV9IQVJERU5fQVJSQVkKIAlib29sICJTcGVjdWxhdGl2
ZSBBcnJheSBIYXJkZW5pbmciCiAJZGVmYXVsdCB5CmRpZmYgLS1naXQgYS94
ZW4vbGliL3g4Ni1nZW5lcmljLWh3ZWlnaHRsLmMgYi94ZW4vbGliL3g4Ni1n
ZW5lcmljLWh3ZWlnaHRsLmMKaW5kZXggMTIzYTViNDM5MjhkLi4xY2FiNjg5
NTJhNDIgMTAwNjQ0Ci0tLSBhL3hlbi9saWIveDg2LWdlbmVyaWMtaHdlaWdo
dGwuYworKysgYi94ZW4vbGliL3g4Ni1nZW5lcmljLWh3ZWlnaHRsLmMKQEAg
LTUxLDcgKzUxLDExIEBAIGFzbSAoCiAgICAgInBvcCAgICAlcmR4XG5cdCIK
ICAgICAicG9wICAgICVyZGlcblx0IgogCisjaWZkZWYgQ09ORklHX1JFVFVS
Tl9USFVOSworICAgICJqbXAgICAgX194ODZfcmV0dXJuX3RodW5rXG5cdCIK
KyNlbHNlCiAgICAgInJldFxuXHQiCisjZW5kaWYKIAogICAgICIuc2l6ZSBh
cmNoX2dlbmVyaWNfaHdlaWdodGwsIC4gLSBhcmNoX2dlbmVyaWNfaHdlaWdo
dGxcblx0IgogKTsK

--=separator
Content-Type: application/octet-stream; name="xsa469/xsa469-07.patch"
Content-Disposition: attachment; filename="xsa469/xsa469-07.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogU3ludGhlc2lzZSBJVFNfTk8g
dG8gZ3Vlc3RzIG9uIHVuYWZmZWN0ZWQgaGFyZHdhcmUKCkl0IGlzIGVhc2ll
ciB0byBleHByZXNzIGZlYXR1cmUgd29yZCAxNyBpbiB0ZXJtcyBvZiB3b3Jk
IDE2ICsgWzMyLCA2NCkgYXMKdGhhdCdzIGhvdyB0aGUgbGF5b3V0IGlzIGdp
dmVuIGluIGRvY3VtZW50YXRpb24uCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2
OSAvIENWRS0yMDI0LTI4OTU2CgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29v
cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTog
Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+CgpkaWZm
IC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUu
aCBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKaW5k
ZXggMDUzOTlmYjljOTgyLi4zOTdhMDRhZjQxYTEgMTAwNjQ0Ci0tLSBhL3hl
bi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgKKysrIGIveGVu
L2FyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaApAQCAtMjE5LDYg
KzIxOSw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBib290X2NwdV9oYXModW5z
aWduZWQgaW50IGZlYXQpCiAjZGVmaW5lIGNwdV9oYXNfZ2RzX25vICAgICAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9HRFNfTk8pCiAjZGVmaW5l
IGNwdV9oYXNfcmZkc19ubyAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9SRkRTX05PKQogI2RlZmluZSBjcHVfaGFzX3JmZHNfY2xlYXIgICAg
ICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfUkZEU19DTEVBUikKKyNkZWZp
bmUgY3B1X2hhc19pdHNfbm8gICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9G
RUFUVVJFX0lUU19OTykKIAogLyogU3ludGhlc2l6ZWQuICovCiAjZGVmaW5l
IGNwdV9oYXNfYXJjaF9wZXJmbW9uICAgIGJvb3RfY3B1X2hhcyhYODZfRkVB
VFVSRV9BUkNIX1BFUkZNT04pCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv
c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg
ZmUyN2U4MmE0NzA3Li4wYTYzNTAyNWU0ODggMTAwNjQ0Ci0tLSBhL3hlbi9h
cmNoL3g4Ni9zcGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19j
dHJsLmMKQEAgLTE3NjAsNiArMTc2MCw5MCBAQCBzdGF0aWMgdm9pZCBfX2lu
aXQgYmhpX2NhbGN1bGF0aW9ucyh2b2lkKQogICAgIH0KIH0KIAorLyoKKyAq
IGh0dHBzOi8vd3d3LmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9kZXZl
bG9wZXIvYXJ0aWNsZXMvdGVjaG5pY2FsL3NvZnR3YXJlLXNlY3VyaXR5LWd1
aWRhbmNlL2Fkdmlzb3J5LWd1aWRhbmNlL2luZGlyZWN0LXRhcmdldC1zZWxl
Y3Rpb24uaHRtbAorICovCitzdGF0aWMgdm9pZCBfX2luaXQgaXRzX2NhbGN1
bGF0aW9ucyh2b2lkKQoreworICAgIC8qCisgICAgICogSW5kaXJlY3QgVGFy
Z2V0IFNlbGVjdGlvbiBpcyBhIEJyYW5jaCBQcmVkaWN0aW9uIGJ1ZyB3aGVy
ZWJ5IGNlcnRhaW4KKyAgICAgKiBpbmRpcmVjdCBicmFuY2hlcyAoaW5jbHVk
aW5nIFJFVHMpIGdldCBwcmVkaWN0ZWQgdXNpbmcgYSBkaXJlY3QgYnJhbmNo
CisgICAgICogdGFyZ2V0LCByYXRoZXIgdGhhbiBhIHN1aXRhYmxlIGluZGly
ZWN0IHRhcmdldCwgYnlwYXNzaW5nIGhhcmR3YXJlCisgICAgICogaXNvbGF0
aW9uIHByb3RlY3Rpb25zLgorICAgICAqCisgICAgICogSVRTIGFmZmVjdHMg
Q29yZSAoYnV0IG5vdCBBdG9tKSBwcm9jZXNzb3JzIHN0YXJ0aW5nIGZyb20g
dGhlCisgICAgICogaW50cm9kdWN0aW9uIG9mIGVJQlJTLCB1cCB0byBidXQg
bm90IGluY2x1ZGluZyBHb2xkZW4gQ292ZSBjb3JlcworICAgICAqIChjaGVj
a2VkIGhlcmUgd2l0aCBCSElfQ1RSTCkuCisgICAgICoKKyAgICAgKiBUaGUg
SVRTX05PIGZlYXR1cmUgaXMgbm90IGV4cGVjdGVkIHRvIGJlIGVudW1lcmF0
ZWQgYnkgaGFyZHdhcmUsIGFuZCBpcworICAgICAqIG9ubHkgZm9yIFZNTXMg
dG8gc3ludGhlc2lzZSBmb3IgZ3Vlc3RzLgorICAgICAqCisgICAgICogSVRT
IGNvbWVzIGluIDMgZmxhdm91cnM6CisgICAgICoKKyAgICAgKiAgIDEpIEFj
cm9zcy1JQlBCLiAgSW5kaXJlY3QgYnJhbmNoZXMgYWZ0ZXIgdGhlIElCUEIg
Y2FuIGJlIGNvbnRyb2xsZWQKKyAgICAgKiAgICAgIGJ5IGRpcmVjdCB0YXJn
ZXRzIHdoaWNoIGV4aXN0ZWQgcHJpb3IgdG8gdGhlIElCUEIuICBUaGlzIGlz
CisgICAgICogICAgICBhZGRyZXNzZWQgaW4gdGhlIElQVSAyMDI1LjEgbWlj
cm9jb2RlIGRyb3AsIGFuZCBoYXMgbm8gb3RoZXIKKyAgICAgKiAgICAgIHNv
ZnR3YXJlIGludGVyYWN0aW9uLgorICAgICAqCisgICAgICogICAyKSBHdWVz
dC9Ib3N0LiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgZGlyZWN0IHRhcmdldHMgZnJv
bSB0aGUgZ3Vlc3QuICBUaGlzIGFwcGxpZXMgZXF1YWxseSB0byBQViBndWVz
dHMKKyAgICAgKiAgICAgIChSaW5nMykgYW5kIEhWTSBndWVzdHMgKFZNWCks
IGFuZCBhcHBsaWVzIHRvIGFsbCBTa3lsYWtlLXVhcmNoCisgICAgICogICAg
ICBjb3JlcyB3aXRoIGVJQlJTLgorICAgICAqCisgICAgICogICAzKSBJbnRy
YS1tb2RlLiAgSW5kaXJlY3QgYnJhbmNoZXMgaW4gdGhlIFZNTSBjYW4gYmUg
Y29udHJvbGxlZCBieQorICAgICAqICAgICAgb3RoZXIgZXhlY3V0aW9uIGlu
IHRoZSBzYW1lIG1vZGUuCisgICAgICovCisKKyAgICAvKgorICAgICAqIElm
IHdlIGNhbiBzZWUgSVRTX05PLCBvciB3ZSdyZSB2aXJ0dWFsaXNlZCwgZG8g
bm90aGluZy4gIFdlIGFyZSBvciBtYXkKKyAgICAgKiBtaWdyYXRlIHNvbWV3
aGVyZSB1bnNhZmUuCisgICAgICovCisgICAgaWYgKCBjcHVfaGFzX2l0c19u
byB8fCBjcHVfaGFzX2h5cGVydmlzb3IgKQorICAgICAgICByZXR1cm47CisK
KyAgICAvKiBJVFMgaXMgb25seSBrbm93biB0byBhZmZlY3QgSW50ZWwgcHJv
Y2Vzc29ycyBhdCB0aGlzIHRpbWUuICovCisgICAgaWYgKCBib290X2NwdV9k
YXRhLng4Nl92ZW5kb3IgIT0gWDg2X1ZFTkRPUl9JTlRFTCApCisgICAgICAg
IHJldHVybjsKKworICAgIC8qCisgICAgICogSVRTIGRvZXMgbm90IGV4aXN0
IG9uOgorICAgICAqICAtIG5vbi1GYW1pbHkgNiBDUFVzCisgICAgICogIC0g
dGhvc2Ugd2l0aG91dCBlSUJSUworICAgICAqICAtIHRob3NlIHdpdGggQkhJ
X0NUUkwKKyAgICAgKiBidXQgd2Ugc3RpbGwgbmVlZCB0byBzeW50aGVzaXNl
IElUU19OTy4KKyAgICAgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2
ICE9IDYgfHwgIWNwdV9oYXNfZWlicnMgfHwKKyAgICAgICAgIGJvb3RfY3B1
X2hhcyhYODZfRkVBVFVSRV9CSElfQ1RSTCkgKQorICAgICAgICBnb3RvIHN5
bnRoZXNpc2U7CisKKyAgICBzd2l0Y2ggKCBib290X2NwdV9kYXRhLng4Nl9t
b2RlbCApCisgICAgeworICAgICAgICAvKiBUaGVzZSBTa3lsYWtlLXVhcmNo
IGNvcmVzIHN1ZmZlciBjYXNlcyAjMiBhbmQgIzMuICovCisgICAgY2FzZSBJ
TlRFTF9GQU02X1NLWUxBS0VfWDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FC
WUxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfS0FCWUxBS0U6CisgICAg
Y2FzZSBJTlRFTF9GQU02X0NPTUVUTEFLRToKKyAgICBjYXNlIElOVEVMX0ZB
TTZfQ09NRVRMQUtFX0w6CisgICAgICAgIHJldHVybjsKKworICAgICAgICAv
KiBUaGVzZSBTdW5ueS9XaWxsb3cvQ3lwcmVzcyBDb3ZlIGNvcmVzIHN1ZmZl
ciBjYXNlICMzLiAqLworICAgIGNhc2UgSU5URUxfRkFNNl9JQ0VMQUtFX1g6
CisgICAgY2FzZSBJTlRFTF9GQU02X0lDRUxBS0VfRDoKKyAgICBjYXNlIElO
VEVMX0ZBTTZfSUNFTEFLRV9MOgorICAgIGNhc2UgSU5URUxfRkFNNl9USUdF
UkxBS0VfTDoKKyAgICBjYXNlIElOVEVMX0ZBTTZfVElHRVJMQUtFOgorICAg
IGNhc2UgSU5URUxfRkFNNl9ST0NLRVRMQUtFOgorICAgICAgICByZXR1cm47
CisKKyAgICBkZWZhdWx0OgorICAgICAgICBicmVhazsKKyAgICB9CisKKyAg
ICAvKiBQbGF0Zm9ybXMgcmVtYWluaW5nIGFyZSBub3QgYmVsaWV2ZWQgdG8g
YmUgdnVsbmVyYWJsZSB0byBJVFMuICovCisgc3ludGhlc2lzZToKKyAgICBz
ZXR1cF9mb3JjZV9jcHVfY2FwKFg4Nl9GRUFUVVJFX0lUU19OTyk7Cit9CisK
IHZvaWQgc3BlY19jdHJsX2luaXRfZG9tYWluKHN0cnVjdCBkb21haW4gKmQp
CiB7CiAgICAgYm9vbCBwdiA9IGlzX3B2X2RvbWFpbihkKTsKQEAgLTIzMTYs
NiArMjQwMCw4IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0
aWdhdGlvbnModm9pZCkKIAogICAgIGJoaV9jYWxjdWxhdGlvbnMoKTsKIAor
ICAgIGl0c19jYWxjdWxhdGlvbnMoKTsKKwogICAgIHByaW50X2RldGFpbHMo
dGh1bmspOwogCiAgICAgLyoKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1
YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IGMyOTBkMTY2
ODM1OC4uYTZkNGEwY2JhN2Q4IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9w
dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNs
dWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTM5MSw3
ICszOTEsOCBAQCBYRU5fQ1BVRkVBVFVSRShSRkRTX0NMRUFSLCAgICAgICAg
IDE2KjMyKzI4KSAvKiFBfCBSZWdpc3RlciBGaWxlKHMpIGNsZWFyZWQgYnkg
VgogWEVOX0NQVUZFQVRVUkUoSUdOX1VNT05JVE9SLCAgICAgICAxNiozMisy
OSkgLyogICBNQ1VfT1BUX0NUUkwuSUdOX1VNT05JVE9SICovCiBYRU5fQ1BV
RkVBVFVSRShNT05fVU1PTl9NSVRHLCAgICAgIDE2KjMyKzMwKSAvKiAgIE1D
VV9PUFRfQ1RSTC5NT05fVU1PTl9NSVRHICovCiAKLS8qIEludGVsLWRlZmlu
ZWQgQ1BVIGZlYXR1cmVzLCBNU1JfQVJDSF9DQVBTIDB4MTBhLmVkeCwgd29y
ZCAxNyAqLworLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMsIE1TUl9B
UkNIX0NBUFMgMHgxMGEuZWR4LCB3b3JkIDE3IChleHByZXNzIGluIHRlcm1z
IG9mIHdvcmQgMTYpICovCitYRU5fQ1BVRkVBVFVSRShJVFNfTk8sICAgICAg
ICAgICAgIDE2KjMyKzYyKSAvKiFBIE5vIEluZGlyZWN0IFRhcmdldCBTZWxl
Y3Rpb24gKi8KIAogI2VuZGlmIC8qIFhFTl9DUFVGRUFUVVJFICovCiAKZGlm
ZiAtLWdpdCBhL3hlbi90b29scy9nZW4tY3B1aWQucHkgYi94ZW4vdG9vbHMv
Z2VuLWNwdWlkLnB5CmluZGV4IGE3N2NiMzBiZGI0Zi4uMTYzYjEwNWJjNmE3
IDEwMDc1NQotLS0gYS94ZW4vdG9vbHMvZ2VuLWNwdWlkLnB5CisrKyBiL3hl
bi90b29scy9nZW4tY3B1aWQucHkKQEAgLTUxLDcgKzUxLDcgQEAgZGVmIHBh
cnNlX2RlZmluaXRpb25zKHN0YXRlKToKICAgICAgICAgciJccysvXCooW1x3
IXxdKikgLiokIikKIAogICAgIHdvcmRfcmVnZXggPSByZS5jb21waWxlKAot
ICAgICAgICByIl4vXCogLiogd29yZCAoXGQqKSBcKi8kIikKKyAgICAgICAg
ciJeL1wqIC4qIHdvcmQgKFxkKikgLipcKi8kIikKICAgICBsYXN0X3dvcmQg
PSAtMQogCiAgICAgdGhpcyA9IHN5cy5tb2R1bGVzW19fbmFtZV9fXQo=

--=separator--


From xen-devel-bounces@lists.xenproject.org Mon May 12 17:55:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 17:55:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981986.1368465 (Exim 4.92)
	(envelope-from )
	id 1uEXND-0007tr-8S; Mon, 12 May 2025 17:55:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981986.1368465; Mon, 12 May 2025 17: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 1uEXND-0007tk-5L; Mon, 12 May 2025 17:55:31 +0000
Received: by outflank-mailman (input) for mailman id 981986;
 Mon, 12 May 2025 17:55:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEXNB-0007te-9f
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 17:55:30 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20614.outbound.protection.outlook.com
 [2a01:111:f403:240a::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 47dc736a-2f5a-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 19:55:26 +0200 (CEST)
Received: from MW3PR12MB4427.namprd12.prod.outlook.com (2603:10b6:303:52::10)
 by MW6PR12MB8952.namprd12.prod.outlook.com (2603:10b6:303:246::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.21; Mon, 12 May
 2025 17:55:20 +0000
Received: from MW3PR12MB4427.namprd12.prod.outlook.com
 ([fe80::6caf:6197:ff82:57ee]) by MW3PR12MB4427.namprd12.prod.outlook.com
 ([fe80::6caf:6197:ff82:57ee%4]) with mapi id 15.20.8722.027; Mon, 12 May 2025
 17:55: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" 
X-Inumbo-ID: 47dc736a-2f5a-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tsUHYFj1I9qIh5wElv2xFEMFO5/aGcOurxGfm5JrtO/wdXjflddn/QqjPjqrZCzxopBt/6478emO/aOm/BJrdruZ04tElAtwnew/yCHBlV9dFp/7EkJhuHacharCnsYR4HJXkdQt0OzUYcELqR/yTqb3sX2YcdGIEVX1mcen0/5R4+/dfKk16VrTiApD9XQeUG5mPxkqStH5virSr1dSiqOuaoMV91ibqMAmL8Uyx3WxzHFrIeCu0fgsk//kMOw2uhnhB1V6KkS+W3yiaKVM5apibxZ4uLTJvdXz18vrZlGC2iB9r7tsKkAo4C7uK73BfbLQpL3+fcIKlaDlO+JWsg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RHwS1VH7fByA1+Id1QIpop0fW4yXICxbUklRYFYciyM=;
 b=PcVeMZiIOR4DQ0D5XxboFGUnunyxvFOW3zB2uMDfGmzZd2PaYp/wN5So4DGE9OeMoV3C0koMGLOQxWb8WXZRrayzWLduV/Mp4Z9+x0UFjlMv8fyle2h9j+WADOJv4kW0g/nnT/bhURp90iFilvRBdwm7Hpc92uWvJ+6v52425rXevGLV/yn2ms8tKmu9bgIeQAzbtgRJ2Nc1w9NTmGsTUqAeB6Oua5vGL3wdR4p20RuTS5Dq3r/Tc774JdVITlntBKpk3SwdTlE9YU2WJ6cXliP+ac27KH9cJgu9hQhK940wgieqzqvw3S1DNSHVah+W52HTadi4CisnOcHOREjsJw==
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=RHwS1VH7fByA1+Id1QIpop0fW4yXICxbUklRYFYciyM=;
 b=h3BURXehjEx6XytYKyF9njrmKIrYzM+VhkILdu1vDDuZh3RMy2wo+STkcp/s5iJndijKwhZzp2l2qeb9IU49R8GqPKClXI+5VJran6+wLjGWIz4VRIMSqGGv1HkMklV0zPZ2lcZjQaACkKONa4I+xSe4xIbsTu5BXzDHUDIHfro=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Content-Type: multipart/mixed; boundary="------------Cpvf9nOps6Uetw0F935WFPmu"
Message-ID: <02b6f10a-119e-499c-a51f-8deac6fa6a93@amd.com>
Date: Mon, 12 May 2025 10:55:18 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC] xen/x86: allow overlaps with non-RAM regions
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Jan Beulich , Jason Andryuk ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Stefano Stabellini , xen-devel@lists.xenproject.org,
 Andrew Cooper , Xenia.Ragiadakou@amd.com,
 Alejandro.GarciaVallejo@amd.com
References: 
  
  <775d3ac0-8f43-415a-a32d-14377092b96b@amd.com>
 <554026de-bbb4-488f-95c4-8e2f034d6d0e@amd.com> 
 <2acad9ba-564a-4d18-9b09-dcabe8f7b025@suse.com>
  
 
Content-Language: en-US
From: "Lira, Victor M" 
In-Reply-To: 
X-ClientProxiedBy: BYAPR01CA0064.prod.exchangelabs.com (2603:10b6:a03:94::41)
 To MW3PR12MB4427.namprd12.prod.outlook.com (2603:10b6:303:52::10)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MW3PR12MB4427:EE_|MW6PR12MB8952:EE_
X-MS-Office365-Filtering-Correlation-Id: 1433fd91-4ebb-4619-74d5-08dd917e2905
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|4053099003;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NUVaWWdLK1VMM0VsQmZHTTRmbDlOeit4dE5ITG1RRGt1bXIyeklqZGhOa0Zh?=
 =?utf-8?B?MFg2dS9paFMzOE1wNllidFRLeitMZjdWaDVOVDA1L3lpbFN1MFNhU2ZMM2lm?=
 =?utf-8?B?SFAxa3NoNHczTzFVeENNZGdIY1BRRmZ3U3YvTHJoTXcrUjNjNjNVc2xYY1hx?=
 =?utf-8?B?T2p6WThZOVdmQUtVZVNjU3RHUm44bnkyeW0zb2Z1ZFhQUE5hV1ZhOUs5Nm9C?=
 =?utf-8?B?R0tzb2RqNllrc2pvMDVRTzc1QW45clZUVTZpM3ZRcStwcEphVThtSDV2Nkxs?=
 =?utf-8?B?a1d0OC9xUUFNWjBRcHNXSXFLeVNkQXlBcllNdkk5dUdiN1NldXVnR0k2SUZC?=
 =?utf-8?B?elA3TjdmVktUZjQ2eWhMaFJYZ2g4NFhvbGNEMVFIR0EvTERKOFZ1MklzTG5u?=
 =?utf-8?B?K29iYkZ3NGZ5Y1lMRzZHSmFqMXNCQ3hwYXRXMXJBNXNlMmQ4QjljSG9NSFJt?=
 =?utf-8?B?aXhOUmV2Y3hHQ3FCWFpoYWhBVXVYOG1XL1lFcVFHWUFCVllPeGpwMUFVTFA3?=
 =?utf-8?B?cXlOdW1MV20yTU1leFNtRXJhSjZsRllFVVdnT1RkODZ0V3JabUpiN09sbWdC?=
 =?utf-8?B?UjJkWkFtQStqanlTdUxCTzhEditnVGlPMEUxTmYwaTAyQnUyY2NiU0RRcU5x?=
 =?utf-8?B?Y2hORUhMMmVVZDZEOHVqOFRyVmx0OE1jb29BaFFZSlExM0RKU3NQSE5vVXJ4?=
 =?utf-8?B?azFoYWFBdU16dXEzWHhGNm9SSDRMbTlDeCtkOC9rWEJIT0ZSN3p2aEJEUFlC?=
 =?utf-8?B?NmozSnllakhCRW9abHJ4bGsxWVFFQXRJWC9UMklQM1FMYU1LNWowbTZpVVpR?=
 =?utf-8?B?cnlKY0prUDdNdGRwZDBSVnd0b3Q0RTR5V1hlY2pWVG1OUDMzMWt5SmF5ZzFM?=
 =?utf-8?B?bWpEb0Zma3BoLzFFQUJvdmtmUENvUjgxbEZYYlZLNnp0bzdSL2FLclRKZGR3?=
 =?utf-8?B?UXFOQVBZb2NGZlpDaFpTZkZlSlVTSzV3WEoySnNjbVZ2MFJNMmxSODVob0Iz?=
 =?utf-8?B?enpGaHlFc2lpNUlYOEhyaXpBa2dndElpU3Avazl3RjMwQm83MHloOHJubG1n?=
 =?utf-8?B?ZXhRV0VmdkZPb1gzU01EeDdCQVBDWDVHWnh1RFR1ZitUU1ZQR0FnRC82Mmhr?=
 =?utf-8?B?U1JkWFVUUXdHeVA5NmVMVDNJdmNoUWdLaFNsYWh6ZVVOT2VtdHZpOEp5S3pQ?=
 =?utf-8?B?Z25NWU5QazR5ZUhvbWtzWUc1dmNWdnEwS3FHdDJ3SjJLWWdPdFB3TEJxT2la?=
 =?utf-8?B?aEN2U2U2RjQzZTcwNWFZdHF4b1ZTcU52cmphOWZXK2F5Yjg4OXBPZDI0Ync2?=
 =?utf-8?B?VmNrZU9CL09qeW9nWVJNb2l2Y3h3b1BKb20zeWZQa1JubkRTeEdrRVZPRVY4?=
 =?utf-8?B?Z1ZCbFJYaVRYSWZJd0JKRHN5cVlHaVBSS2k5NzkxMzRNSkhjSC9hbVBBRWJa?=
 =?utf-8?B?S1haQzdxeThySGY1WHJJOE9pQ1FwQTVqNFdYYzZZdGprT05JRHdOVldwS3hu?=
 =?utf-8?B?bVNidVhJVjdRREljbUh3VnBRY01vamszZm5aUTI2OXBQYlZtR2NBVi9NcXB3?=
 =?utf-8?B?S0FrNFBDOStVY2toTnJGQ1dSQ1Fyb2o2Rm1WVy82RjdIT1BvOVJ2SytUa3hy?=
 =?utf-8?B?Mzd6dnlNcndjeFVBN2g1WHMxdW1yZHZYWWRFTjduNVNRZnFLamxCeGdaZEg2?=
 =?utf-8?B?aitXOUhrWWJSQlh5Z0FUaGl4T0czMmNlbzJ2bXowOStzblBzbTNxb3AyK0Zx?=
 =?utf-8?B?bFNLNElFZVlyaHRRamRFQ1loOEplTGp3WEZyYWVGdWk0OEl0UDIzcW1tbVFo?=
 =?utf-8?B?eWtZTlRrMjNpdnppQUt1UFhmdEJUNWJlT2JRNnRSK3piNi9MaW50VFV5a3lO?=
 =?utf-8?B?S2lVakRJWEZoeW5Wb1h6alNLTXZ4U3UrV2pmYVRiNmoyRDNTMG16UWkvOW1p?=
 =?utf-8?Q?iqUAGYWn7p4=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW3PR12MB4427.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(4053099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?cmxQVGlkN3ZvcFVyNVZHYWF3N2tjNEtaQTFpUjlJbHdjTEdDZkRHc1lUbFVX?=
 =?utf-8?B?VENwUnN1ekNVODdlbWFVcXN3Um1Cd1pmVGhuOHlaNkVQcmpDek5OSGxsbVgx?=
 =?utf-8?B?amprZFhIR1BmVGE4VjVjUGpDNElCaDdjNUZJR0xmSGRUVEdQNDNkc2xkckU3?=
 =?utf-8?B?M3JLbFN6bGJiV3JCSkNDVzUwaXAwUmVNSURrdTA5SWFmRGR4SGJHODJaQlpu?=
 =?utf-8?B?VHpHTWI4OWFjOW43MlFtSVJvRDdEQ2JMeVQwVmRLMmxndzlYdlpSS1lFOHM3?=
 =?utf-8?B?N2Zaeld4SzhEUXd2a2VwZGh0Q2NlcTFQeGk3TE8vNjlOc3UzTWMwT01XQVFM?=
 =?utf-8?B?VzQ5M1owZ2JBZFJrK2Z4VEorMGd0TVpGNzV3aElaaDlRYm8vMWdNekduRTJF?=
 =?utf-8?B?K0IxZjhnRk1FRFhLTnhsWXdqWnF2OXZBdE13ZFVKRmdtbTFKWTNIY05BbjU4?=
 =?utf-8?B?azROSFdFUjU2Y3ZUYUxwT2NJcVpVZGMraG5CenBZd1duS3lnNEwzSmZtR08x?=
 =?utf-8?B?L3h5dHc5UVlXdERPTUNya1QrVndwV0FXdDJmRCswRERoelpoOTM3OEdveWpx?=
 =?utf-8?B?MkpNMmc4OStLWko5blp3NmRGUmZuQjNJUVdmMEtiblE1ZFVWc0g1aFVqWjNp?=
 =?utf-8?B?TmYvM25MN3F5MDVwQ2h6NHVPVFpxM3JIa0lZcENaWmFUVkVxS0Z1eitLa0NV?=
 =?utf-8?B?NmlWRkhvSmhRUkFYUFBDd2U1MDN4dkp3dmtwRlFGUGxtOE0vQ0ZDSCtXdGtx?=
 =?utf-8?B?eWZMMmRHczFWK3JEZlcyMFdxeUtRclBUQXFWem41WlNHQUZFWFZIWnI5V1k0?=
 =?utf-8?B?UllvRmpDSDZiSkpYVUQxK1RsNDQ5amtlbFZ1MysyTVE5L21RdEdZL05TandE?=
 =?utf-8?B?ckRxUjFzMlBlc1ZoS2pDMmFWMzA4NURZY1BtUC9qdHE2QmVRMzZOOHNTT29i?=
 =?utf-8?B?VVI2TG1Dc2RpQWQ0cTJRSVExOFZYZzdnejM2Q0JhaDZrS0Y3SjdUczUwYlZa?=
 =?utf-8?B?T0g3eWx4MFV6MzQxNk1mMk5ZWGJiWmJOWG1TTmN4NDNua3lkclJRNGYvbE11?=
 =?utf-8?B?Tmgzb0F1TjArZXZNRGQ1TnNabGxkTUNRRlRKS3lnWDNOWFJ6enZ3bmVIcGh3?=
 =?utf-8?B?NHp2WjFmbExOSDdGTDgxWWVkZFozaHpDcEVWYm1oNTUrY244a2JJYzMwTHFO?=
 =?utf-8?B?MTRVNWNrZkdpa3JGSjVrODRYV2l5Mk9iamU0OHBrVWZEM2pwUmFEcVBnbXdY?=
 =?utf-8?B?Z1p6djNCQy9QSTdGM2lMdytLd1ZhamdwYTI5d0lpNDFmcDVLc0hWZDh0MXZi?=
 =?utf-8?B?dHc1eFN3WmhOVjhMNzQwT1p0VW04VjZFWGc2SjhxdXJXOSsySFNCYW1zWkhz?=
 =?utf-8?B?OXFZcGFjd3dmN2g1WUFCNzNQVXNuSlIvdnlvT3JBakl6ZGZ5QXNYRW5lZVZC?=
 =?utf-8?B?MklIL1lkMFd0KzNtUUc1SkFpeERtU21SU0Nva3RkTjlCYU9RRDNuWU5pT0ZK?=
 =?utf-8?B?eThpeE4vekYveVE2UW93UnJIajRFd0dFcGk4UWxLZDJaVGI0bVdVWWtqMDN0?=
 =?utf-8?B?cUVpNW4zTU5WWWFZSnVxQnFRMTJhU2NCdGV4L3VReHBESUNSUy8ySk5wTGI3?=
 =?utf-8?B?VXk3Y2NnaDkxd2NYOXV5UjY5cDQ1dVMwbVQ2MzNPU0FSOFIwWFR0V1oveG9S?=
 =?utf-8?B?S2NvakxrM1NveXZrTDl0RXFjMXVIdVRvT0JnSnQ0UDJ1TzlMQTIxaDVXRjM4?=
 =?utf-8?B?YzJWci8vQWdWR1JlTGJRSE5MN2g3dWRLU2lyajFyQ3lmWFkrTlppY2RiT1Rl?=
 =?utf-8?B?dkYwUHR2V0dLUVJ6SVM5cDRFZlBXSHhPSlN0MTRkMVkrREQrM3Zod25IU2x0?=
 =?utf-8?B?b3VrVHNYWDJMeGxSSXlYb0dRbHdlT095cWJ5dVdYWG9tdnpnNHdmemNaY3BM?=
 =?utf-8?B?NHJjbmNWSUlHVGlsbUhwZGprRitwMDM3N0E5SDNvQ1RZVlpCQnhmU21yU0g3?=
 =?utf-8?B?Q2c1YUo4QXdlWUl4MlU2VE5KL2RQWXJzMmllbVRHV2pMRm83Y3I5VXo2dFhl?=
 =?utf-8?B?eXloV1VqZGtMWVZVWjJVTHpXblBmQVkzYU1teFQzZ0RhUGxUengxTG5lK2tL?=
 =?utf-8?Q?NxXibF9MIvXUiA4WyKIx0p8Lx?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1433fd91-4ebb-4619-74d5-08dd917e2905
X-MS-Exchange-CrossTenant-AuthSource: MW3PR12MB4427.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2025 17:55:19.9034
 (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: qRNxdBBRB/JY/j63gcIFExKWb1oU/Uk1n9AKxdkEPfPXpcFmvvFNhcdo0vEXJdIeRhlXnRVyPBXSkZzaZJheUg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8952

--------------Cpvf9nOps6Uetw0F935WFPmu
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5/12/2025 9:16 AM, Roger Pau Monné wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On Fri, Apr 25, 2025 at 09:47:57AM -0700, Lira, Victor M wrote:
>> I can confirm with the patch the NVME drive can be accessed despite the "not
>> mapping BAR" warning from Xen.
>> Output log attached.
> Thanks a lot for the test, and sorry for the delay in getting back.  I
> was busy with other stuff and needed some time to figure out the best
> way to deal with this.  Can you give a try to the patch below?  I hope
> it will still fix the issue.
No worries,  I applied this patch to the latest staging c45e57f59d69, 
and the result is also successful NVME drive access.
Output log attached and I see no "failed to sanitize" warnings.


Victor
--------------Cpvf9nOps6Uetw0F935WFPmu
Content-Type: text/plain; charset=UTF-8; name="test-patched-roger.log"
Content-Disposition: attachment; filename="test-patched-roger.log"
Content-Transfer-Encoding: base64

WGVuIDQuMjEtdW5zdGFibGUNCihYRU4pIFswMDAwMDAyNWUzZjQyYjNkXSBYZW4gdmVyc2lvbiA0
LjIxLXVuc3RhYmxlIChyb290QCkgKGdjYyAoQWxwaW5lIDEyLjIuMV9naXQyMDIyMDkyNC1yMTAp
IDEyLjIuMSAyMDIyMDkyNCkgZGVidWc9eSBNb24gTWF5IDEyIDE3OjEyOjQ4IFVUQyAyMDI1DQoo
WEVOKSBbMDAwMDAwMjVlNjM2MmZkYV0gTGF0ZXN0IENoYW5nZVNldDoNCihYRU4pIFswMDAwMDAy
NWU2ZTI2OGVhXSBidWlsZC1pZDogOTVhMWQ5Y2JkZDAwNWMwYmIwODJkM2RlNDQ2NjZjNmVmNjQ5
YTExNQ0KKFhFTikgWzAwMDAwMDI1ZTgwOTJiZDJdIENvbnNvbGUgb3V0cHV0IGlzIHN5bmNocm9u
b3VzLg0KKFhFTikgWzAwMDAwMDI1ZThlMzUzNWVdIENQVSBWZW5kb3I6IEFNRCwgRmFtaWx5IDIz
ICgweDE3KSwgTW9kZWwgOTYgKDB4NjApLCBTdGVwcGluZyAxIChyYXcgMDA4NjBmMDEpDQooWEVO
KSBbMDAwMDAwMjVlYTcxNzRlMl0gQlNQIG1pY3JvY29kZSByZXZpc2lvbjogMHgwODYwMDEwYw0K
KFhFTikgWzAwMDAwMDI1ZWI1YWY5OGRdIEJvb3Rsb2FkZXI6IEdSVUIgMi4xMw0KKFhFTikgWzAw
MDAwMDI1ZWMxMjk4YmRdIENvbW1hbmQgbGluZTogY29uc29sZT1jb20xIGNvbTE9MTE1MjAwLDhu
MSwweDNGOCw0IHNjaGVkPW51bGwgbG9nbHZsPWFsbCBndWVzdF9sb2dsdmw9YWxsIGNvbnNvbGVf
dGltZXN0YW1wcz1ib290IGlvbW11PXZlcmJvc2UgZG9tMD1wdmgsdmVyYm9zZSxwZi1maXh1cCBk
b20wX21heF92Y3B1cz00IGRvbTBfbWVtPTRHIGFyZ289MSxtYWMtcGVybWlzc2l2ZT0xIHN5bmNf
Y29uc29sZSBub3JlYm9vdCB3b3cNCihYRU4pIFswMDAwMDAyNWVmZjIyMzk2XSBYZW4gaW1hZ2Ug
bG9hZCBiYXNlIGFkZHJlc3M6IDB4YzY2MDAwMDANCihYRU4pIFswMDAwMDAyNWYwZWViOWUyXSBW
aWRlbyBpbmZvcm1hdGlvbjoNCihYRU4pIFswMDAwMDAyNWYxOWFlNDM5XSAgVkdBIGlzIGdyYXBo
aWNzIG1vZGUgMTkyMHgxMjAwLCAzMiBicHANCihYRU4pIFswMDAwMDAyNWYyOTdhYzA1XSBEaXNj
IGluZm9ybWF0aW9uOg0KKFhFTikgWzAwMDAwMDI1ZjM0MDE2ZmFdICBGb3VuZCAwIE1CUiBzaWdu
YXR1cmVzDQooWEVOKSBbMDAwMDAwMjVmM2ZmNjRiYV0gIEZvdW5kIDEgRUREIGluZm9ybWF0aW9u
IHN0cnVjdHVyZXMNCihYRU4pIFswMDAwMDAyNWY0ZWNhZDZiXSBFRkkgUkFNIG1hcDoNCihYRU4p
IFswMDAwMDAyNWY1ODIwZGUyXSAgWzAwMDAwMDAwMDAwMDAwMDAsIDAwMDAwMDAwMDAwOWZmZmZd
ICh1c2FibGUpDQooWEVOKSBbMDAwMDAwMjVmNjk5NjkzZV0gIFswMDAwMDAwMDAwMGEwMDAwLCAw
MDAwMDAwMDAwMGZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbMDAwMDAwMjVmN2I4OTExMl0gIFsw
MDAwMDAwMDAwMTAwMDAwLCAwMDAwMDAwMDA5YmZlZmZmXSAodXNhYmxlKQ0KKFhFTikgWzAwMDAw
MDI1ZjhjZmVkY2FdICBbMDAwMDAwMDAwOWJmZjAwMCwgMDAwMDAwMDAwOWZmZmZmZl0gKHJlc2Vy
dmVkKQ0KKFhFTikgWzAwMDAwMDI1ZjllZjAyMjJdICBbMDAwMDAwMDAwYTAwMDAwMCwgMDAwMDAw
MDAwYTFmZmZmZl0gKHVzYWJsZSkNCihYRU4pIFswMDAwMDAyNWZiMDY4Nzg2XSAgWzAwMDAwMDAw
MGEyMDAwMDAsIDAwMDAwMDAwMGEyMGNmZmZdIChBQ1BJIE5WUykNCihYRU4pIFswMDAwMDAyNWZj
MjU4ODdlXSAgWzAwMDAwMDAwMGEyMGQwMDAsIDAwMDAwMDAwY2FiYzhmZmZdICh1c2FibGUpDQoo
WEVOKSBbMDAwMDAwMjVmZDNkMGFkMl0gIFswMDAwMDAwMGNhYmM5MDAwLCAwMDAwMDAwMGNjMTRj
ZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbMDAwMDAwMjVmZTVjMTI3YV0gIFswMDAwMDAwMGNjMTRk
MDAwLCAwMDAwMDAwMGNjMTk1ZmZmXSAoQUNQSSBkYXRhKQ0KKFhFTikgWzAwMDAwMDI1ZmY3ZjBh
Y2FdICBbMDAwMDAwMDBjYzE5NjAwMCwgMDAwMDAwMDBjYzM4OGZmZl0gKEFDUEkgTlZTKQ0KKFhF
TikgWzAwMDAwMDI2MDA5ZTEwNjhdICBbMDAwMDAwMDBjYzM4OTAwMCwgMDAwMDAwMDBjYzM4OWZm
Zl0gKHJlc2VydmVkKQ0KKFhFTikgWzAwMDAwMDI2MDFiZDI1ZmZdICBbMDAwMDAwMDBjYzM4YTAw
MCwgMDAwMDAwMDBjYzcwOWZmZl0gKEFDUEkgTlZTKQ0KKFhFTikgWzAwMDAwMDI2MDJkYzNlYTVd
ICBbMDAwMDAwMDBjYzcwYTAwMCwgMDAwMDAwMDBjZDFmZWZmZl0gKHJlc2VydmVkKQ0KKFhFTikg
WzAwMDAwMDI2MDNmYjcyYjZdICBbMDAwMDAwMDBjZDFmZjAwMCwgMDAwMDAwMDBjZGZmZmZmZl0g
KHVzYWJsZSkNCihYRU4pIFswMDAwMDAyNjA1MTJjMWYyXSAgWzAwMDAwMDAwY2UwMDAwMDAsIDAw
MDAwMDAwY2ZmZmZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAyNjA2MzFkZTM4XSAgWzAw
MDAwMDAwZjAwMDAwMDAsIDAwMDAwMDAwZjdmZmZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAw
MDAyNjA3NTEwYTVhXSAgWzAwMDAwMDAwZmQwMDAwMDAsIDAwMDAwMDAwZmZmZmZmZmZdIChyZXNl
cnZlZCkNCihYRU4pIFswMDAwMDAyNjA4NzAxNTg2XSAgWzAwMDAwMDAxMDAwMDAwMDAsIDAwMDAw
MDA4MGYzM2ZmZmZdICh1c2FibGUpDQooWEVOKSBbMDAwMDAwMjYwOTg3ODQ3YV0gIFswMDAwMDAw
ODBmMzQwMDAwLCAwMDAwMDAwODUwMWZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbMDAwMDAwMjYx
NmViMmQwMV0gQUNQSTogUlNEUCBDQzZGMzAxNCwgMDAyNCAocjIgQUxBU0tBKQ0KKFhFTikgWzAw
MDAwMDI2MTdlMDMzYzddIEFDUEk6IFhTRFQgQ0M2RjI3MjgsIDAwREMgKHIxIEFMQVNLQSAgIEEg
TSBJICAgMTA3MjAwOSBBTUkgICAxMDAwMDEzKQ0KKFhFTikgWzAwMDAwMDI2MTk0ZmIxN2FdIEFD
UEk6IEZBQ1AgQ0MxOEMwMDAsIDAxMTQgKHI2IEFMQVNLQSAgIEEgTSBJICAgMTA3MjAwOSBBTUkg
ICAgIDEwMDEzKQ0KKFhFTikgWzAwMDAwMDI2MWFiZjBhMDVdIEFDUEk6IERTRFQgQ0MxODMwMDAs
IDg3NkQgKHIyIEFMQVNLQSAgIEEgTSBJICAgMTA3MjAwOSBJTlRMIDIwMTIwOTEzKQ0KKFhFTikg
WzAwMDAwMDI2MWMyZWE0MGFdIEFDUEk6IEZBQ1MgQ0M2QzAwMDAsIDAwNDANCihYRU4pIFswMDAw
MDAyNjFjZjVhMDVhXSBBQ1BJOiBTU0RUIENDMThFMDAwLCA3MjNDIChyMiAgICBBTUQgQW1kVGFi
bGUgICAgICAgIDIgTVNGVCAgNDAwMDAwMCkNCihYRU4pIFswMDAwMDAyNjFlNjUyYTY2XSBBQ1BJ
OiBJVlJTIENDMThEMDAwLCAwMUE0IChyMiAgQU1EICAgQW1kVGFibGUgICAgICAgIDEgQU1EICAg
ICAgICAgMCkNCihYRU4pIFswMDAwMDAyNjFmZDQ5YmZhXSBBQ1BJOiBGSURUIENDMTgyMDAwLCAw
MDlDIChyMSBBTEFTS0EgICAgQSBNIEkgIDEwNzIwMDkgQU1JICAgICAxMDAxMykNCihYRU4pIFsw
MDAwMDAyNjIxNDQxOWNhXSBBQ1BJOiBNQ0ZHIENDMTgxMDAwLCAwMDNDIChyMSBBTEFTS0EgICAg
QSBNIEkgIDEwNzIwMDkgTVNGVCAgICAxMDAxMykNCihYRU4pIFswMDAwMDAyNjIyYjM3N2UyXSBB
Q1BJOiBIUEVUIENDMTgwMDAwLCAwMDM4IChyMSBBTEFTS0EgICAgQSBNIEkgIDEwNzIwMDkgQU1J
ICAgICAgICAgNSkNCihYRU4pIFswMDAwMDAyNjI0MjJmNWIyXSBBQ1BJOiBTU0RUIENDMTdGMDAw
LCAwMjI4IChyMSAgICBBTUQgICAgIFNURDMgICAgICAgIDEgSU5UTCAyMDEyMDkxMykNCihYRU4p
IFswMDAwMDAyNjI1OTI3YzkyXSBBQ1BJOiBWRkNUIENDMTcxMDAwLCBENjg0IChyMSBBTEFTS0Eg
ICBBIE0gSSAgICAgICAgIDEgIEFNRCAzMTUwNEY0NykNCihYRU4pIFswMDAwMDAyNjI3MDFmMTUy
XSBBQ1BJOiBUUE0yIENDMTZGMDAwLCAwMDRDIChyNCBBTEFTS0EgICBBIE0gSSAgICAgICAgIDEg
QU1JICAgICAgICAgMCkNCihYRU4pIFswMDAwMDAyNjI4NzE3ODMyXSBBQ1BJOiBTU0RUIENDMTZC
MDAwLCAzOUY0IChyMSAgICBBTUQgQW1kVGFibGUgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihY
RU4pIFswMDAwMDAyNjI5ZTBlY2YyXSBBQ1BJOiBDUkFUIENDMTZBMDAwLCAwRjI4IChyMSAgICBB
TUQgQW1kVGFibGUgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFswMDAwMDAyNjJiNTA2
ZTQ1XSBBQ1BJOiBDRElUIENDMTY5MDAwLCAwMDI5IChyMSAgICBBTUQgQW1kVGFibGUgICAgICAg
IDEgQU1EICAgICAgICAgMSkNCihYRU4pIFswMDAwMDAyNjJjYmZlODkyXSBBQ1BJOiBTU0RUIEND
MTY4MDAwLCAwMTM5IChyMSAgICBBTUQgQW1kVGFibGUgICAgICAgIDEgSU5UTCAyMDEyMDkxMykN
CihYRU4pIFswMDAwMDAyNjJlMmY0ZmJhXSBBQ1BJOiBTU0RUIENDMTY3MDAwLCAwMjI3IChyMSAg
ICBBTUQgQW1kVGFibGUgICAgICAgIDEgSU5UTCAyMDEyMDkxMykNCihYRU4pIFswMDAwMDAyNjJm
OWVkOWUzXSBBQ1BJOiBTU0RUIENDMTY2MDAwLCAwRDM3IChyMSAgICBBTUQgQW1kVGFibGUgICAg
ICAgIDEgSU5UTCAyMDEyMDkxMykNCihYRU4pIFswMDAwMDAyNjMxMGU0MjRhXSBBQ1BJOiBTU0RU
IENDMTY0MDAwLCAxMEE1IChyMSAgICBBTUQgQW1kVGFibGUgICAgICAgIDEgSU5UTCAyMDEyMDkx
MykNCihYRU4pIFswMDAwMDAyNjMyN2RjZDk1XSBBQ1BJOiBTU0RUIENDMTYwMDAwLCAzMEM4IChy
MSAgICBBTUQgQW1kVGFibGUgICAgICAgIDEgSU5UTCAyMDEyMDkxMykNCihYRU4pIFswMDAwMDAy
NjMzZWQzZGVhXSBBQ1BJOiBXU01UIENDMTVGMDAwLCAwMDI4IChyMSBBTEFTS0EgICBBIE0gSSAg
IDEwNzIwMDkgQU1JICAgICAxMDAxMykNCihYRU4pIFswMDAwMDAyNjM1NWNhNTEyXSBBQ1BJOiBB
UElDIENDMTVFMDAwLCAwMERFIChyMyBBTEFTS0EgICBBIE0gSSAgIDEwNzIwMDkgQU1JICAgICAx
MDAxMykNCihYRU4pIFswMDAwMDAyNjM2Y2MzOThhXSBBQ1BJOiBTU0RUIENDMTVEMDAwLCAwMDdE
IChyMSAgICBBTUQgQW1kVGFibGUgICAgICAgIDEgSU5UTCAyMDEyMDkxMykNCihYRU4pIFswMDAw
MDAyNjM4M2JhMGIyXSBBQ1BJOiBTU0RUIENDMTVDMDAwLCAwNTE3IChyMSAgICBBTUQgQW1kVGFi
bGUgICAgICAgIDEgSU5UTCAyMDEyMDkxMykNCihYRU4pIFswMDAwMDAyNjM5YWIwZmU1XSBBQ1BJ
OiBGUERUIENDMTVCMDAwLCAwMDQ0IChyMSBBTEFTS0EgICBBIE0gSSAgIDEwNzIwMDkgQU1JICAg
MTAwMDAxMykNCihYRU4pIFswMDAwMDAyNjNiMWE5YzUyXSBBQ1BJOiBCR1JUIENDMTcwMDAwLCAw
MDM4IChyMSBBTEFTS0EgICBBIE0gSSAgIDEwNzIwMDkgQU1JICAgICAxMDAxMykNCihYRU4pIFsw
MDAwMDAyNjNjOGExZGMyXSBTeXN0ZW0gUkFNOiAzMjE2OE1CICgzMjk0MDY1NmtCKQ0KKFhFTikg
WzAwMDAwMDI2NDFjNzFmM2FdIE5vIE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZA0KKFhFTikgWzAw
MDAwMDI2NDI5NWUwYzJdIEZha2luZyBhIG5vZGUgYXQgMDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAw
ODBmMzQwMDAwDQooWEVOKSBbMDAwMDAwMjY0YzI0ZTFiOV0gRG9tYWluIGhlYXAgaW5pdGlhbGlz
ZWQNCihYRU4pIFswMDAwMDAyNjRlMjc0ZDhlXSBTTUJJT1MgMy4yIHByZXNlbnQuDQooWEVOKSBb
MDAwMDAwMjY0ZWQ4ZWJhMV0gVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdA0KKFhFTikgWzAwMDAw
MDI2NGY5ZmRlYTddIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4ICgzMiBiaXRzKQ0KKFhF
TikgWzAwMDAwMDI2NTA5YzhhM2ZdIEFDUEk6IHY1IFNMRUVQIElORk86IGNvbnRyb2xbMDowXSwg
c3RhdHVzWzA6MF0NCihYRU4pIFswMDAwMDAyNjUxYjQwNmFmXSBBQ1BJOiBTTEVFUCBJTkZPOiBw
bTF4X2NudFsxOjgwNCwxOjBdLCBwbTF4X2V2dFsxOjgwMCwxOjBdDQooWEVOKSBbMDAwMDAwMjY1
MmY5NmQyZl0gQUNQSTogMzIvNjRYIEZBQ1MgYWRkcmVzcyBtaXNtYXRjaCBpbiBGQURUIC0gY2M2
YzAwMDAvMDAwMDAwMDAwMDAwMDAwMCwgdXNpbmcgMzINCihYRU4pIFswMDAwMDAyNjU0OTJlMjk3
XSBBQ1BJOiAgICAgICAgICAgICB3YWtldXBfdmVjW2NjNmMwMDBjXSwgdmVjX3NpemVbMjBdDQoo
WEVOKSBbMDAwMDAwMjY1NWMxNjUwZF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAw
MDANCihYRU4pIFswMDAwMDAyNjU2YWZmZjZmXSBPdmVycmlkaW5nIEFQSUMgZHJpdmVyIHdpdGgg
Ymlnc21wDQooWEVOKSBbMDAwMDAwMjY1Nzk5OTA5MF0gQUNQSTogSU9BUElDIChpZFsweDExXSBh
ZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KKFhFTikgWzAwMDAwMDI2NThkMzY0ZGZd
IElPQVBJQ1swXTogYXBpY19pZCAxNywgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzAwMDAwLCBH
U0kgMC0yMw0KKFhFTikgWzAwMDAwMDI2NWEyYmY2YjddIEFDUEk6IElPQVBJQyAoaWRbMHgxMl0g
YWRkcmVzc1sweGZlYzAxMDAwXSBnc2lfYmFzZVsyNF0pDQooWEVOKSBbMDAwMDAwMjY1YjY5YThj
M10gSU9BUElDWzFdOiBhcGljX2lkIDE4LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDEwMDAs
IEdTSSAyNC01NQ0KKFhFTikgWzAwMDAwMDI2NWNjNWYwM2VdIEFDUEk6IElOVF9TUkNfT1ZSIChi
dXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQooWEVOKSBbMDAwMDAwMjY1ZTAz
OWRmY10gQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93
IGxldmVsKQ0KKFhFTikgWzAwMDAwMDI2NWY0OGZiNmNdIEFDUEk6IElSUTAgdXNlZCBieSBvdmVy
cmlkZS4NCihYRU4pIFswMDAwMDAyNjYwMWI5ZDJmXSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJp
ZGUuDQooWEVOKSBbMDAwMDAwMjY2MGVlMWY1N10gQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRl
Lg0KKFhFTikgWzAwMDAwMDI2NjFjMGExN2ZdIEFDUEk6IEhQRVQgaWQ6IDB4MTAyMjgyMDEgYmFz
ZTogMHhmZWQwMDAwMA0KKFhFTikgWzAwMDAwMDI2NjJjOGM5ZmNdIFBDSTogTUNGRyBjb25maWd1
cmF0aW9uIDA6IGJhc2UgZjAwMDAwMDAgc2VnbWVudCAwMDAwIGJ1c2VzIDAwIC0gN2YNCihYRU4p
IFswMDAwMDAyNjY0MzA4ZmYyXSBQQ0k6IE1DRkcgYXJlYSBhdCBmMDAwMDAwMCByZXNlcnZlZCBp
biBFODIwDQooWEVOKSBbMDAwMDAwMjY2NTNjOGZiN10gUENJOiBVc2luZyBNQ0ZHIGZvciBzZWdt
ZW50IDAwMDAgYnVzIDAwLTdmDQooWEVOKSBbMDAwMDAwMjY2NjQ0OTg1Zl0gQUNQSTogQkdSVDog
aW52YWxpZGF0aW5nIHYxIGltYWdlIGF0IDB4YzcxNTMwMTgNCihYRU4pIFswMDAwMDAyNjY3NWZm
NTI3XSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24N
CihYRU4pIFswMDAwMDAyNjY4OGE2NTMzXSBTTVA6IEFsbG93aW5nIDE2IENQVXMgKDAgaG90cGx1
ZyBDUFVzKQ0KKFhFTikgWzAwMDAwMDI2Njk4MzQ0MjldIElSUSBsaW1pdHM6IDU2IEdTSSwgMzI3
MiBNU0kvTVNJLVgNCihYRU4pIFswMDAwMDAyNjZhNmNiNjQwXSBDUFUwOiAxNDAwIC4uLiAyOTAw
IE1Ieg0KKFhFTikgWzAwMDAwMDI2NmIyYzFmYzFdIHhzdGF0ZTogc2l6ZTogMHgzODAgYW5kIHN0
YXRlczogMHgyMDcNCihYRU4pIFswMDAwMDAyNjZjMjEzMzcxXSBDUFUwOiBBTUQgRmFtMTdoIG1h
Y2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQNCihYRU4pIFswMDAwMDAyNjZkNDA0ODIwXSBT
cGVjdWxhdGl2ZSBtaXRpZ2F0aW9uIGZhY2lsaXRpZXM6DQooWEVOKSBbMDAwMDAwMjY2ZTI5Y2M3
NF0gICBIYXJkd2FyZSBoaW50czogSUJSU19GQVNUIElCUlNfU0FNRV9NT0RFDQooWEVOKSBbMDAw
MDAwMjY2ZjMxZGU0OV0gICBIYXJkd2FyZSBmZWF0dXJlczogSUJQQiBJQlJTIFNUSUJQIFNTQkQN
CihYRU4pIFswMDAwMDAyNjcwMzYyNjM0XSAgIENvbXBpbGVkLWluIHN1cHBvcnQ6IElORElSRUNU
X1RIVU5LIFNIQURPV19QQUdJTkcgSEFSREVOX0FSUkFZIEhBUkRFTl9CUkFOQ0ggSEFSREVOX0dV
RVNUX0FDQ0VTUyBIQVJERU5fTE9DSw0KKFhFTikgWzAwMDAwMDI2NzI0MjlmYWNdICAgWGVuIHNl
dHRpbmdzOiBCVEktVGh1bms6IFJFVFBPTElORSwgU1BFQ19DVFJMOiBJQlJTLSBTVElCUCsgU1NC
RC0sIE90aGVyOiBCUkFOQ0hfSEFSREVODQooWEVOKSBbMDAwMDAwMjY3M2ZlYWExZl0gICBTdXBw
b3J0IGZvciBIVk0gVk1zOiBNU1JfU1BFQ19DVFJMIE1TUl9WSVJUX1NQRUNfQ1RSTCBSU0IgSUJQ
Qi1lbnRyeQ0KKFhFTikgWzAwMDAwMDI2NzU3MWU1MGNdICAgU3VwcG9ydCBmb3IgUFYgVk1zOiBJ
QlBCLWVudHJ5DQooWEVOKSBbMDAwMDAwMjY3NjUzY2Q4MV0gICBYUFRJICg2NC1iaXQgUFYgb25s
eSk6IERvbTAgZGlzYWJsZWQsIERvbVUgZGlzYWJsZWQgKHdpdGhvdXQgUENJRCkNCihYRU4pIFsw
MDAwMDAyNjc3YmY3NDA5XSAgIFBWIEwxVEYgc2hhZG93aW5nOiBEb20wIGRpc2FibGVkLCBEb21V
IGRpc2FibGVkDQooWEVOKSBbMDAwMDAwMjY3OGUyNTY3Y10gVXNpbmcgc2NoZWR1bGVyOiBudWxs
IFNjaGVkdWxlciAobnVsbCkNCihYRU4pIFswMDAwMDAyNjc5ZGIyMWJjXSBJbml0aWFsaXppbmcg
bnVsbCBzY2hlZHVsZXINCihYRU4pIFswMDAwMDAyNjdhYTllMzQ0XSBXQVJOSU5HOiBUaGlzIGlz
IGV4cGVyaW1lbnRhbCBzb2Z0d2FyZSBpbiBkZXZlbG9wbWVudC4NCihYRU4pIFswMDAwMDAyNjdi
ZGZkMDhjXSBVc2UgYXQgeW91ciBvd24gcmlzay4NCihYRU4pIFswMDAwMDAyNjg1MzM4YTc4XSBQ
bGF0Zm9ybSB0aW1lciBpcyAxNC4zMThNSHogSFBFVA0KKFhFTikgWyAgICAwLjk0MTgzNl0gRGV0
ZWN0ZWQgMjg5NC41NTMgTUh6IHByb2Nlc3Nvci4NCihYRU4pIFsgICAgMC45NDgyMThdIEZyZWVk
IDEwMDhrQiB1bnVzZWQgQlNTIG1lbW9yeQ0KKFhFTikgWyAgICAwLjk1MjgxM10gRUZJIG1lbW9y
eSBtYXA6DQooWEVOKSBbICAgIDAuOTU2MTA0XSAgMDAwMDAwMDAwMDAwMC0wMDAwMDAwMDAzZmZm
IHR5cGU9MiBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMC45NjMwMzldICAwMDAw
MDAwMDA0MDAwLTAwMDAwMDAwOGVmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAwLjk2OTk3MF0gIDAwMDAwMDAwOGYwMDAtMDAwMDAwMDA5ZWZmZiB0eXBlPTIgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDAuOTc2OTAzXSAgMDAwMDAwMDA5ZjAwMC0w
MDAwMDAwMDlmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMC45
ODM4MzddICAwMDAwMDAwMTAwMDAwLTAwMDAwMDBlODlmZmYgdHlwZT0yIGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAwLjk5MDc3MF0gIDAwMDAwMDBlOGEwMDAtMDAwMDAwMGZmZmZm
ZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDAuOTk3NzA2XSAgMDAw
MDAwMTAwMDAwMC0wMDAwMDAxMDFmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMS4wMDQ2MzhdICAwMDAwMDAxMDIwMDAwLTAwMDAwMDliZmVmZmYgdHlwZT03IGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjAxMTU3Ml0gIDAwMDAwMDliZmYwMDAt
MDAwMDAwOWZmZmZmZiB0eXBlPTAgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEu
MDE4NTAzXSAgMDAwMDAwYTAwMDAwMC0wMDAwMDBhMWZmZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMS4wMjU0MzldICAwMDAwMDBhMjAwMDAwLTAwMDAwMGEyMGNm
ZmYgdHlwZT0xMCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4wMzI0NThdICAw
MDAwMDBhMjBkMDAwLTAwMDAwMTZjZTBmZmYgdHlwZT0yIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAxLjAzOTM5Ml0gIDAwMDAwMTZjZTEwMDAtMDAwMDBjNGVlY2ZmZiB0eXBlPTcg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMDQ2MzI3XSAgMDAwMDBjNGVlZDAw
MC0wMDAwMGM3MDAxZmZmIHR5cGU9MSBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
MS4wNTMyNTddICAwMDAwMGM3MDAyMDAwLTAwMDAwYzcxMTdmZmYgdHlwZT03IGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjA2MDE5MV0gIDAwMDAwYzcxMTgwMDAtMDAwMDBjNzE1
MmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMDY3MTI1XSAg
MDAwMDBjNzE1MzAwMC0wMDAwMGM3MTkxZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMS4wNzQwNTddICAwMDAwMGM3MTkyMDAwLTAwMDAwYzcxOTNmZmYgdHlwZT03
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjA4MDk5Ml0gIDAwMDAwYzcxOTQw
MDAtMDAwMDBjNzE5YmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDEuMDg3OTI2XSAgMDAwMDBjNzE5YzAwMC0wMDAwMGM3MWE3ZmZmIHR5cGU9MyBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4wOTQ4NTldICAwMDAwMGM3MWE4MDAwLTAwMDAwYzcx
ZDNmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjEwMTc5M10g
IDAwMDAwYzcxZDQwMDAtMDAwMDBjNzFkY2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDEuMTA4NzI1XSAgMDAwMDBjNzFkZDAwMC0wMDAwMGM3MWUwZmZmIHR5cGU9
NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4xMTU2NTldICAwMDAwMGM3MWUx
MDAwLTAwMDAwYzcxZTVmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAxLjEyMjU5M10gIDAwMDAwYzcxZTYwMDAtMDAwMDBjNzI4M2ZmZiB0eXBlPTQgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMTI5NTI0XSAgMDAwMDBjNzI4NDAwMC0wMDAwMGM3
Mjg0ZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4xMzY0NThd
ICAwMDAwMGM3Mjg1MDAwLTAwMDAwYzcyODZmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAxLjE0MzM5Ml0gIDAwMDAwYzcyODcwMDAtMDAwMDBjNzI4OGZmZiB0eXBl
PTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMTUwMzI0XSAgMDAwMDBjNzI4
OTAwMC0wMDAwMGM3MjhhZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMS4xNTcyNTldICAwMDAwMGM3MjhiMDAwLTAwMDAwYzcyOGJmZmYgdHlwZT03IGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjE2NDE5NF0gIDAwMDAwYzcyOGMwMDAtMDAwMDBj
NzI4Y2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMTcxMTI1
XSAgMDAwMDBjNzI4ZDAwMC0wMDAwMGM3MjhkZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMS4xNzgwNTldICAwMDAwMGM3MjhlMDAwLTAwMDAwYzcyOGVmZmYgdHlw
ZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjE4NDk5NF0gIDAwMDAwYzcy
OGYwMDAtMDAwMDBjNzI4ZmZmZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDEuMTkxOTI2XSAgMDAwMDBjNzI5MDAwMC0wMDAwMGM3MjkwZmZmIHR5cGU9NCBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4xOTg4NjBdICAwMDAwMGM3MjkxMDAwLTAwMDAw
YzcyOTNmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjIwNTc5
NF0gIDAwMDAwYzcyOTQwMDAtMDAwMDBjNzI5N2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDEuMjEyNzI1XSAgMDAwMDBjNzI5ODAwMC0wMDAwMGM3MmEyZmZmIHR5
cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4yMTk2NTldICAwMDAwMGM3
MmEzMDAwLTAwMDAwYzcyYTRmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAxLjIyNjU5MV0gIDAwMDAwYzcyYTUwMDAtMDAwMDBjNzJhOGZmZiB0eXBlPTcgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMjMzNTI1XSAgMDAwMDBjNzJhOTAwMC0wMDAw
MGM3MmFhZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4yNDA0
NjBdICAwMDAwMGM3MmFiMDAwLTAwMDAwYzcyYWNmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAxLjI0NzM5MV0gIDAwMDAwYzcyYWQwMDAtMDAwMDBjNzJhZWZmZiB0
eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMjU0MzI0XSAgMDAwMDBj
NzJhZjAwMC0wMDAwMGM3MmIwZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMS4yNjEyNjFdICAwMDAwMGM3MmIxMDAwLTAwMDAwYzcyYjFmZmYgdHlwZT00IGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjI2ODE5M10gIDAwMDAwYzcyYjIwMDAtMDAw
MDBjNzJiMmZmZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMjc1
MTI3XSAgMDAwMDBjNzJiMzAwMC0wMDAwMGM3MmIzZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMS4yODIwNjBdICAwMDAwMGM3MmI0MDAwLTAwMDAwYzcyYjRmZmYg
dHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjI4ODk5MV0gIDAwMDAw
YzcyYjUwMDAtMDAwMDBjNzJiNWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDEuMjk1OTI0XSAgMDAwMDBjNzJiNjAwMC0wMDAwMGM3MmI3ZmZmIHR5cGU9NyBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4zMDI4NjBdICAwMDAwMGM3MmI4MDAwLTAw
MDAwYzcyYjhmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjMw
OTc5M10gIDAwMDAwYzcyYjkwMDAtMDAwMDBjNzM3NmZmZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDEuMzE2NzI2XSAgMDAwMDBjNzM3NzAwMC0wMDAwMGM3ODVhZmZm
IHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4zMjM2NThdICAwMDAw
MGM3ODViMDAwLTAwMDAwYzc5ZDJmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAxLjMzMDU5M10gIDAwMDAwYzc5ZDMwMDAtMDAwMDBjN2ExNGZmZiB0eXBlPTcgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMzM3NTI1XSAgMDAwMDBjN2ExNTAwMC0w
MDAwMGM3YTNkZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4z
NDQ0NjBdICAwMDAwMGM3YTNlMDAwLTAwMDAwYzdhNDJmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAxLjM1MTM5NF0gIDAwMDAwYzdhNDMwMDAtMDAwMDBjN2E0M2Zm
ZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMzU4MzI0XSAgMDAw
MDBjN2E0NDAwMC0wMDAwMGM3YTQ0ZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMS4zNjUyNjBdICAwMDAwMGM3YTQ1MDAwLTAwMDAwYzdhNDVmZmYgdHlwZT00IGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjM3MjE5MV0gIDAwMDAwYzdhNDYwMDAt
MDAwMDBjN2E0NmZmZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEu
Mzc5MTI3XSAgMDAwMDBjN2E0NzAwMC0wMDAwMGM3YTQ3ZmZmIHR5cGU9MiBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMS4zODYwNjFdICAwMDAwMGM3YTQ4MDAwLTAwMDAwYzdhNDhm
ZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjM5Mjk5NF0gIDAw
MDAwYzdhNDkwMDAtMDAwMDBjN2E0OWZmZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDEuMzk5OTI2XSAgMDAwMDBjN2E0YTAwMC0wMDAwMGM3YTRiZmZmIHR5cGU9NCBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS40MDY4NThdICAwMDAwMGM3YTRjMDAw
LTAwMDAwYzdhNGNmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAx
LjQxMzc5NF0gIDAwMDAwYzdhNGQwMDAtMDAwMDBjN2E1ZGZmZiB0eXBlPTMgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNDIwNzI3XSAgMDAwMDBjN2E1ZTAwMC0wMDAwMGM3YTk1
ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS40Mjc2NjFdICAw
MDAwMGM3YTk2MDAwLTAwMDAwYzdhOTZmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAxLjQzNDU5Ml0gIDAwMDAwYzdhOTcwMDAtMDAwMDBjN2FlN2ZmZiB0eXBlPTQg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNDQxNTI1XSAgMDAwMDBjN2FlODAw
MC0wMDAwMGM3YjA3ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
MS40NDg0NThdICAwMDAwMGM3YjA4MDAwLTAwMDAwYzdiMDhmZmYgdHlwZT00IGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjQ1NTM5NF0gIDAwMDAwYzdiMDkwMDAtMDAwMDBjN2Ix
MGZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNDYyMzI2XSAg
MDAwMDBjN2IxMTAwMC0wMDAwMGM3YjE4ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMS40NjkyNjBdICAwMDAwMGM3YjE5MDAwLTAwMDAwYzdiMzBmZmYgdHlwZT0z
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjQ3NjE5M10gIDAwMDAwYzdiMzEw
MDAtMDAwMDBjN2IzMmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDEuNDgzMTI2XSAgMDAwMDBjN2IzMzAwMC0wMDAwMGM3YjU1ZmZmIHR5cGU9MyBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS40OTAwNTldICAwMDAwMGM3YjU2MDAwLTAwMDAwYzdi
NjBmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjQ5Njk5Ml0g
IDAwMDAwYzdiNjEwMDAtMDAwMDBjN2I4Y2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDEuNTAzOTI1XSAgMDAwMDBjN2I4ZDAwMC0wMDAwMGM5MjcwZmZmIHR5cGU9
NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS41MTA4NjFdICAwMDAwMGM5Mjcx
MDAwLTAwMDAwYzkyZDdmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAxLjUxNzc5Ml0gIDAwMDAwYzkyZDgwMDAtMDAwMDBjOTJkYmZmZiB0eXBlPTQgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNTI0NzI3XSAgMDAwMDBjOTJkYzAwMC0wMDAwMGM5
MmU1ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS41MzE2NjFd
ICAwMDAwMGM5MmU2MDAwLTAwMDAwYzkzMzBmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAxLjUzODU5M10gIDAwMDAwYzkzMzEwMDAtMDAwMDBjOTM0YWZmZiB0eXBl
PTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNTQ1NTI4XSAgMDAwMDBjOTM0
YjAwMC0wMDAwMGM5MzRlZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMS41NTI0NjBdICAwMDAwMGM5MzRmMDAwLTAwMDAwYzkzNmNmZmYgdHlwZT0zIGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjU1OTM5NF0gIDAwMDAwYzkzNmQwMDAtMDAwMDBj
OTM2ZGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNTY2MzI1
XSAgMDAwMDBjOTM2ZTAwMC0wMDAwMGM5Mzc0ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMS41NzMyNjBdICAwMDAwMGM5Mzc1MDAwLTAwMDAwYzkzN2JmZmYgdHlw
ZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjU4MDE5Ml0gIDAwMDAwYzkz
N2MwMDAtMDAwMDBjOTM4OWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDEuNTg3MTI3XSAgMDAwMDBjOTM4YTAwMC0wMDAwMGM5MzhlZmZmIHR5cGU9NCBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS41OTQwNjJdICAwMDAwMGM5MzhmMDAwLTAwMDAw
YzkzOTBmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjYwMDk5
M10gIDAwMDAwYzkzOTEwMDAtMDAwMDBjOTM5MmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDEuNjA3OTI3XSAgMDAwMDBjOTM5MzAwMC0wMDAwMGM5Mzk5ZmZmIHR5
cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS42MTQ4NTldICAwMDAwMGM5
MzlhMDAwLTAwMDAwYzkzOWJmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAxLjYyMTc5NF0gIDAwMDAwYzkzOWMwMDAtMDAwMDBjOTM5Y2ZmZiB0eXBlPTMgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNjI4NzI4XSAgMDAwMDBjOTM5ZDAwMC0wMDAw
MGM5M2EwZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS42MzU2
NjJdICAwMDAwMGM5M2ExMDAwLTAwMDAwYzkzYjdmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAxLjY0MjU5NV0gIDAwMDAwYzkzYjgwMDAtMDAwMDBjOTNiOWZmZiB0
eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNjQ5NTI3XSAgMDAwMDBj
OTNiYTAwMC0wMDAwMGM5M2JiZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMS42NTY0NjFdICAwMDAwMGM5M2JjMDAwLTAwMDAwYzkzYmNmZmYgdHlwZT00IGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjY2MzM5NF0gIDAwMDAwYzkzYmQwMDAtMDAw
MDBjOTNjYmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNjcw
MzI4XSAgMDAwMDBjOTNjYzAwMC0wMDAwMGM5M2Q0ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMS42NzcyNjBdICAwMDAwMGM5M2Q1MDAwLTAwMDAwYzkzZDZmZmYg
dHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjY4NDE5NF0gIDAwMDAw
YzkzZDcwMDAtMDAwMDBjOTNkOGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDEuNjkxMTI2XSAgMDAwMDBjOTNkOTAwMC0wMDAwMGM5M2Q5ZmZmIHR5cGU9MyBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS42OTgwNjFdICAwMDAwMGM5M2RhMDAwLTAw
MDAwYzkzZGFmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjcw
NDk5M10gIDAwMDAwYzkzZGIwMDAtMDAwMDBjOTNkYmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDEuNzExOTI3XSAgMDAwMDBjOTNkYzAwMC0wMDAwMGM5NTI5ZmZm
IHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS43MTg4NjJdICAwMDAw
MGM5NTJhMDAwLTAwMDAwYzk1MzNmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAxLjcyNTc5M10gIDAwMDAwYzk1MzQwMDAtMDAwMDBjOTUzNWZmZiB0eXBlPTQgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNzMyNzI2XSAgMDAwMDBjOTUzNjAwMC0w
MDAwMGM5NTM5ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS43
Mzk2NTldICAwMDAwMGM5NTNhMDAwLTAwMDAwYzk1M2RmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAxLjc0NjU5NV0gIDAwMDAwYzk1M2UwMDAtMDAwMDBjOTU0NWZm
ZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNzUzNTI2XSAgMDAw
MDBjOTU0NjAwMC0wMDAwMGM5NTQ3ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMS43NjA0NTldICAwMDAwMGM5NTQ4MDAwLTAwMDAwYzk1NGJmZmYgdHlwZT0zIGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjc2NzM5NF0gIDAwMDAwYzk1NGMwMDAt
MDAwMDBjOTU0ZGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEu
Nzc0MzI4XSAgMDAwMDBjOTU0ZTAwMC0wMDAwMGM5NTU2ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMS43ODEyNjBdICAwMDAwMGM5NTU3MDAwLTAwMDAwYzk1NWFm
ZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjc4ODE5NV0gIDAw
MDAwYzk1NWIwMDAtMDAwMDBjOTU1Y2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDEuNzk1MTI4XSAgMDAwMDBjOTU1ZDAwMC0wMDAwMGM5NTVmZmZmIHR5cGU9NCBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS44MDIwNjFdICAwMDAwMGM5NTYwMDAw
LTAwMDAwYzk1NmNmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAx
LjgwODk5NV0gIDAwMDAwYzk1NmQwMDAtMDAwMDBjOTdmZmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDEuODE1OTI3XSAgMDAwMDBjOTgwMDAwMC0wMDAwMGM5ODFh
ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS44MjI4NjFdICAw
MDAwMGM5ODFiMDAwLTAwMDAwYzk4MmFmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAxLjgyOTc5M10gIDAwMDAwYzk4MmIwMDAtMDAwMDBjOTgzZGZmZiB0eXBlPTMg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuODM2NzI2XSAgMDAwMDBjOTgzZTAw
MC0wMDAwMGM5ODNmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
MS44NDM2NjBdICAwMDAwMGM5ODQwMDAwLTAwMDAwYzk4NDNmZmYgdHlwZT0zIGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjg1MDU5Nl0gIDAwMDAwYzk4NDQwMDAtMDAwMDBjOTg0
OGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuODU3NTI3XSAg
MDAwMDBjOTg0OTAwMC0wMDAwMGM5ODViZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMS44NjQ0NjFdICAwMDAwMGM5ODVjMDAwLTAwMDAwYzk4NjBmZmYgdHlwZT00
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjg3MTM5M10gIDAwMDAwYzk4NjEw
MDAtMDAwMDBjOTg2MWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDEuODc4MzI4XSAgMDAwMDBjOTg2MjAwMC0wMDAwMGM5ODYyZmZmIHR5cGU9NCBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS44ODUyNjJdICAwMDAwMGM5ODYzMDAwLTAwMDAwYzk4
NjNmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjg5MjE5Nl0g
IDAwMDAwYzk4NjQwMDAtMDAwMDBjOTg2NmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDEuODk5MTI5XSAgMDAwMDBjOTg2NzAwMC0wMDAwMGM5ODc0ZmZmIHR5cGU9
MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS45MDYwNjFdICAwMDAwMGM5ODc1
MDAwLTAwMDAwYzk4NzVmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAxLjkxMjk5NV0gIDAwMDAwYzk4NzYwMDAtMDAwMDBjOTg3NmZmZiB0eXBlPTMgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuOTE5OTI3XSAgMDAwMDBjOTg3NzAwMC0wMDAwMGM5
ODgyZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS45MjY4NjJd
ICAwMDAwMGM5ODgzMDAwLTAwMDAwYzk4OGJmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAxLjkzMzc5NF0gIDAwMDAwYzk4OGMwMDAtMDAwMDBjOTg4ZWZmZiB0eXBl
PTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuOTQwNzI3XSAgMDAwMDBjOTg4
ZjAwMC0wMDAwMGM5ODk0ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMS45NDc2NjBdICAwMDAwMGM5ODk1MDAwLTAwMDAwYzk4ZTFmZmYgdHlwZT00IGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjk1NDU5M10gIDAwMDAwYzk4ZTIwMDAtMDAwMDBj
OTkwZmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuOTYxNTI5
XSAgMDAwMDBjOTkxMDAwMC0wMDAwMGM5OTExZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMS45Njg0NjNdICAwMDAwMGM5OTEyMDAwLTAwMDAwYzk5MTNmZmYgdHlw
ZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjk3NTM5NV0gIDAwMDAwYzk5
MTQwMDAtMDAwMDBjOTkxNWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDEuOTgyMzI2XSAgMDAwMDBjOTkxNjAwMC0wMDAwMGM5OTJkZmZmIHR5cGU9MyBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS45ODkyNjFdICAwMDAwMGM5OTJlMDAwLTAwMDAw
Yzk5MzlmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjk5NjE5
Nl0gIDAwMDAwYzk5M2EwMDAtMDAwMDBjOTk2MGZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDIuMDAzMTI3XSAgMDAwMDBjOTk2MTAwMC0wMDAwMGM5OTY0ZmZmIHR5
cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4wMTAwNjNdICAwMDAwMGM5
OTY1MDAwLTAwMDAwYzk5NmNmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAyLjAxNjk5NV0gIDAwMDAwYzk5NmQwMDAtMDAwMDBjOTk3NGZmZiB0eXBlPTQgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMDIzOTI5XSAgMDAwMDBjOTk3NTAwMC0wMDAw
MGM5OTdlZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4wMzA4
NjBdICAwMDAwMGM5OTdmMDAwLTAwMDAwYzk5ODhmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAyLjAzNzc5Nl0gIDAwMDAwYzk5ODkwMDAtMDAwMDBjOTlhZGZmZiB0
eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMDQ0NzI4XSAgMDAwMDBj
OTlhZTAwMC0wMDAwMGM5OWI3ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMi4wNTE2NjJdICAwMDAwMGM5OWI4MDAwLTAwMDAwYzk5YjhmZmYgdHlwZT0zIGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjA1ODU5NF0gIDAwMDAwYzk5YjkwMDAtMDAw
MDBjOTliOWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMDY1
NTI5XSAgMDAwMDBjOTliYTAwMC0wMDAwMGM5OWMxZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMi4wNzI0NjFdICAwMDAwMGM5OWMyMDAwLTAwMDAwYzk5YzRmZmYg
dHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjA3OTM5NV0gIDAwMDAw
Yzk5YzUwMDAtMDAwMDBjOTljNmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDIuMDg2MzI5XSAgMDAwMDBjOTljNzAwMC0wMDAwMGM5OWM3ZmZmIHR5cGU9NCBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4wOTMyNjFdICAwMDAwMGM5OWM4MDAwLTAw
MDAwYzk5ZDVmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjEw
MDE5Nl0gIDAwMDAwYzk5ZDYwMDAtMDAwMDBjOTlkOWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDIuMTA3MTI4XSAgMDAwMDBjOTlkYTAwMC0wMDAwMGM5OWRmZmZm
IHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4xMTQwNjFdICAwMDAw
MGM5OWUwMDAwLTAwMDAwYzk5ZTVmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAyLjEyMDk5NF0gIDAwMDAwYzk5ZTYwMDAtMDAwMDBjOTllNmZmZiB0eXBlPTMgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMTI3OTI5XSAgMDAwMDBjOTllNzAwMC0w
MDAwMGM5OWU4ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4x
MzQ4NjBdICAwMDAwMGM5OWU5MDAwLTAwMDAwYzk5ZmRmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAyLjE0MTc5Nl0gIDAwMDAwYzk5ZmUwMDAtMDAwMDBjOTlmZWZm
ZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMTQ4NzI3XSAgMDAw
MDBjOTlmZjAwMC0wMDAwMGM5YTAxZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMi4xNTU2NjBdICAwMDAwMGM5YTAyMDAwLTAwMDAwYzlhMDJmZmYgdHlwZT00IGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjE2MjU5NF0gIDAwMDAwYzlhMDMwMDAt
MDAwMDBjOWExMmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIu
MTY5NTI5XSAgMDAwMDBjOWExMzAwMC0wMDAwMGM5YTE1ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMi4xNzY0NjNdICAwMDAwMGM5YTE2MDAwLTAwMDAwYzlhMTdm
ZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjE4MzM5NV0gIDAw
MDAwYzlhMTgwMDAtMDAwMDBjOWExOWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDIuMTkwMzI5XSAgMDAwMDBjOWExYTAwMC0wMDAwMGM5YTJmZmZmIHR5cGU9MyBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4xOTcyNjBdICAwMDAwMGM5YTMwMDAw
LTAwMDAwYzlhMzBmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAy
LjIwNDE5N10gIDAwMDAwYzlhMzEwMDAtMDAwMDBjOWEzMWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMjExMTMwXSAgMDAwMDBjOWEzMjAwMC0wMDAwMGM5YTMy
ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4yMTgwNjNdICAw
MDAwMGM5YTMzMDAwLTAwMDAwYzlhMzNmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAyLjIyNDk5N10gIDAwMDAwYzlhMzQwMDAtMDAwMDBjOWEzNGZmZiB0eXBlPTQg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMjMxOTI4XSAgMDAwMDBjOWEzNTAw
MC0wMDAwMGM5YTM1ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
Mi4yMzg4NjBdICAwMDAwMGM5YTM2MDAwLTAwMDAwYzlhMzZmZmYgdHlwZT00IGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjI0NTc5Nl0gIDAwMDAwYzlhMzcwMDAtMDAwMDBjOWEz
N2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMjUyNzMwXSAg
MDAwMDBjOWEzODAwMC0wMDAwMGM5YTM4ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMi4yNTk2NjRdICAwMDAwMGM5YTM5MDAwLTAwMDAwYzlhNGJmZmYgdHlwZT0z
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjI2NjU5NF0gIDAwMDAwYzlhNGMw
MDAtMDAwMDBjOWE0ZGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDIuMjczNTI4XSAgMDAwMDBjOWE0ZTAwMC0wMDAwMGM5YTUyZmZmIHR5cGU9MyBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4yODA0NjFdICAwMDAwMGM5YTUzMDAwLTAwMDAwYzlh
NTdmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjI4NzM5NV0g
IDAwMDAwYzlhNTgwMDAtMDAwMDBjOWE1Y2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDIuMjk0MzMwXSAgMDAwMDBjOWE1ZDAwMC0wMDAwMGM5YTVmZmZmIHR5cGU9
NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4zMDEyNjFdICAwMDAwMGM5YTYw
MDAwLTAwMDAwYzlhNjZmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAyLjMwODE5NF0gIDAwMDAwYzlhNjcwMDAtMDAwMDBjOWE2OWZmZiB0eXBlPTQgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMzE1MTMwXSAgMDAwMDBjOWE2YTAwMC0wMDAwMGM5
YTczZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4zMjIwNjJd
ICAwMDAwMGM5YTc0MDAwLTAwMDAwYzlhOGFmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAyLjMyODk5Nl0gIDAwMDAwYzlhOGIwMDAtMDAwMDBjOWE5Y2ZmZiB0eXBl
PTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMzM1OTI4XSAgMDAwMDBjOWE5
ZDAwMC0wMDAwMGM5YTlkZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMi4zNDI4NjNdICAwMDAwMGM5YTllMDAwLTAwMDAwYzlhOWZmZmYgdHlwZT0zIGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjM0OTc5NF0gIDAwMDAwYzlhYTAwMDAtMDAwMDBj
OWFhN2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMzU2NzI5
XSAgMDAwMDBjOWFhODAwMC0wMDAwMGM5YWE4ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMi4zNjM2NjJdICAwMDAwMGM5YWE5MDAwLTAwMDAwYzlhYTlmZmYgdHlw
ZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjM3MDU5Nl0gIDAwMDAwYzlh
YWEwMDAtMDAwMDBjOWFhYWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDIuMzc3NTI4XSAgMDAwMDBjOWFhYjAwMC0wMDAwMGM5YWFjZmZmIHR5cGU9NCBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4zODQ0NjFdICAwMDAwMGM5YWFkMDAwLTAwMDAw
YzlhYjFmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjM5MTM5
N10gIDAwMDAwYzlhYjIwMDAtMDAwMDBjOWFiM2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDIuMzk4MzI4XSAgMDAwMDBjOWFiNDAwMC0wMDAwMGM5YWI3ZmZmIHR5
cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi40MDUyNjFdICAwMDAwMGM5
YWI4MDAwLTAwMDAwYzlhYjhmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAyLjQxMjE5Nl0gIDAwMDAwYzlhYjkwMDAtMDAwMDBjOWFiZWZmZiB0eXBlPTMgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNDE5MTI5XSAgMDAwMDBjOWFiZjAwMC0wMDAw
MGM5YWJmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi40MjYw
NjJdICAwMDAwMGM5YWMwMDAwLTAwMDAwYzlhY2JmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAyLjQzMjk5N10gIDAwMDAwYzlhY2MwMDAtMDAwMDBjOWFjY2ZmZiB0
eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNDM5OTMxXSAgMDAwMDBj
OWFjZDAwMC0wMDAwMGM5YWNlZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMi40NDY4NjNdICAwMDAwMGM5YWNmMDAwLTAwMDAwYzlhZDBmZmYgdHlwZT00IGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjQ1Mzc5N10gIDAwMDAwYzlhZDEwMDAtMDAw
MDBjOWFkMWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNDYw
NzMxXSAgMDAwMDBjOWFkMjAwMC0wMDAwMGM5YWQyZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMi40Njc2NjNdICAwMDAwMGM5YWQzMDAwLTAwMDAwYzlhZWVmZmYg
dHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjQ3NDU5NV0gIDAwMDAw
YzlhZWYwMDAtMDAwMDBjOWFmMWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDIuNDgxNTMwXSAgMDAwMDBjOWFmMjAwMC0wMDAwMGM5YWYzZmZmIHR5cGU9MyBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi40ODg0NjFdICAwMDAwMGM5YWY0MDAwLTAw
MDAwYzlhZjdmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjQ5
NTM5Nl0gIDAwMDAwYzlhZjgwMDAtMDAwMDBjOWFmYmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDIuNTAyMzMxXSAgMDAwMDBjOWFmYzAwMC0wMDAwMGM5YWZkZmZm
IHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi41MDkyNjRdICAwMDAw
MGM5YWZlMDAwLTAwMDAwYzliMDdmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAyLjUxNjE5OF0gIDAwMDAwYzliMDgwMDAtMDAwMDBjOWYwN2ZmZiB0eXBlPTQgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNTIzMTMwXSAgMDAwMDBjOWYwODAwMC0w
MDAwMGM5ZjI3ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi41
MzAwNjFdICAwMDAwMGM5ZjI4MDAwLTAwMDAwYzlmMjlmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAyLjUzNjk5Nl0gIDAwMDAwYzlmMmEwMDAtMDAwMDBjOWYyYmZm
ZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNTQzOTMwXSAgMDAw
MDBjOWYyYzAwMC0wMDAwMGM5ZjJkZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMi41NTA4NjNdICAwMDAwMGM5ZjJlMDAwLTAwMDAwYzlmMmVmZmYgdHlwZT0zIGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjU1Nzc5OF0gIDAwMDAwYzlmMmYwMDAt
MDAwMDBjOWYyZmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIu
NTY0NzI5XSAgMDAwMDBjOWYzMDAwMC0wMDAwMGM5ZjMwZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMi41NzE2NjNdICAwMDAwMGM5ZjMxMDAwLTAwMDAwYzlmMzFm
ZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjU3ODU5Nl0gIDAw
MDAwYzlmMzIwMDAtMDAwMDBjOWYzNmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDIuNTg1NTMwXSAgMDAwMDBjOWYzNzAwMC0wMDAwMGM5ZjNhZmZmIHR5cGU9NCBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi41OTI0NjRdICAwMDAwMGM5ZjNiMDAw
LTAwMDAwYzlmM2JmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAy
LjU5OTM5OF0gIDAwMDAwYzlmM2MwMDAtMDAwMDBjOWYzY2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNjA2MzI5XSAgMDAwMDBjOWYzZDAwMC0wMDAwMGM5ZjNk
ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi42MTMyNjNdICAw
MDAwMGM5ZjNlMDAwLTAwMDAwY2E0MTFmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAyLjYyMDE5NV0gIDAwMDAwY2E0MTIwMDAtMDAwMDBjYTQxM2ZmZiB0eXBlPTMg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNjI3MTMwXSAgMDAwMDBjYTQxNDAw
MC0wMDAwMGNhNDE1ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
Mi42MzQwNjRdICAwMDAwMGNhNDE2MDAwLTAwMDAwY2E0MWNmZmYgdHlwZT0zIGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjY0MDk5NV0gIDAwMDAwY2E0MWQwMDAtMDAwMDBjYTQx
ZGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNjQ3OTMxXSAg
MDAwMDBjYTQxZTAwMC0wMDAwMGNhNDFlZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMi42NTQ4NjNdICAwMDAwMGNhNDFmMDAwLTAwMDAwY2E0ODhmZmYgdHlwZT00
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjY2MTc5N10gIDAwMDAwY2E0ODkw
MDAtMDAwMDBjYTQ4OWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDIuNjY4NzMxXSAgMDAwMDBjYTQ4YTAwMC0wMDAwMGNhNDhiZmZmIHR5cGU9NCBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi42NzU2NjRdICAwMDAwMGNhNDhjMDAwLTAwMDAwY2E0
OGNmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjY4MjU5N10g
IDAwMDAwY2E0OGQwMDAtMDAwMDBjYTQ5MWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDIuNjg5NTI5XSAgMDAwMDBjYTQ5MjAwMC0wMDAwMGNhNDk0ZmZmIHR5cGU9
MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi42OTY0NjRdICAwMDAwMGNhNDk1
MDAwLTAwMDAwY2FiYzhmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAyLjcwMzM5NV0gIDAwMDAwY2FiYzkwMDAtMDAwMDBjYzE0Y2ZmZiB0eXBlPTAgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNzEwMzMwXSAgMDAwMDBjYzE0ZDAwMC0wMDAwMGNj
MTk1ZmZmIHR5cGU9OSBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi43MTcyNjNd
ICAwMDAwMGNjMTk2MDAwLTAwMDAwY2MzODhmZmYgdHlwZT0xMCBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMi43MjQyODVdICAwMDAwMGNjMzg5MDAwLTAwMDAwY2MzODlmZmYgdHlw
ZT0wIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjczMTIxNl0gIDAwMDAwY2Mz
OGEwMDAtMDAwMDBjYzcwOWZmZiB0eXBlPTEwIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAyLjczODIzN10gIDAwMDAwY2M3MGEwMDAtMDAwMDBjZDE3OWZmZiB0eXBlPTYgYXR0cj04
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNzQ1MTcyXSAgMDAwMDBjZDE3YTAwMC0wMDAw
MGNkMWZlZmZmIHR5cGU9NSBhdHRyPTgwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi43NTIx
MDRdICAwMDAwMGNkMWZmMDAwLTAwMDAwY2Q3ZmZmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAyLjc1OTAzNV0gIDAwMDAwY2Q4MDAwMDAtMDAwMDBjZDhlOWZmZiB0
eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNzY1OTcxXSAgMDAwMDBj
ZDhlYTAwMC0wMDAwMGNkOWU5ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMi43NzI5MDJdICAwMDAwMGNkOWVhMDAwLTAwMDAwY2RhMDVmZmYgdHlwZT0zIGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjc3OTgzN10gIDAwMDAwY2RhMDYwMDAtMDAw
MDBjZGEzMWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNzg2
NzY5XSAgMDAwMDBjZGEzMjAwMC0wMDAwMGNkYTQ0ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMi43OTM3MDRdICAwMDAwMGNkYTQ1MDAwLTAwMDAwY2RmNTdmZmYg
dHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjgwMDYzOF0gIDAwMDAw
Y2RmNTgwMDAtMDAwMDBjZGY1YWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDIuODA3NTY5XSAgMDAwMDBjZGY1YjAwMC0wMDAwMGNkZjZkZmZmIHR5cGU9NCBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi44MTQ1MDRdICAwMDAwMGNkZjZlMDAwLTAw
MDAwY2RmNzdmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjgy
MTQzNl0gIDAwMDAwY2RmNzgwMDAtMDAwMDBjZGY5MWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDIuODI4MzcwXSAgMDAwMDBjZGY5MjAwMC0wMDAwMGNkZjk3ZmZm
IHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi44MzUzMDNdICAwMDAw
MGNkZjk4MDAwLTAwMDAwY2RmYWRmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAyLjg0MjIzOF0gIDAwMDAwY2RmYWUwMDAtMDAwMDBjZGZiMWZmZiB0eXBlPTMgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuODQ5MTcxXSAgMDAwMDBjZGZiMjAwMC0w
MDAwMGNkZmM1ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi44
NTYxMDNdICAwMDAwMGNkZmM2MDAwLTAwMDAwY2RmY2FmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAyLjg2MzAzOV0gIDAwMDAwY2RmY2IwMDAtMDAwMDBjZGZkZmZm
ZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuODY5OTcwXSAgMDAw
MDBjZGZlMDAwMC0wMDAwMGNkZmYxZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMi44NzY5MDRdICAwMDAwMGNkZmYyMDAwLTAwMDAwY2RmZjlmZmYgdHlwZT00IGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjg4MzgzNl0gIDAwMDAwY2RmZmEwMDAt
MDAwMDBjZGZmZmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIu
ODkwNzcxXSAgMDAwMDEwMDAwMDAwMC0wMDAwODBmMzNmZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMi44OTc3MDNdICAwMDAwMDAwMGEwMDAwLTAwMDAwMDAwZmZm
ZmYgdHlwZT0wIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjkwNDYzOV0gIDAw
MDAwY2UwMDAwMDAtMDAwMDBjZmZmZmZmZiB0eXBlPTAgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDIuOTExNTcyXSAgMDAwMDBmMDAwMDAwMC0wMDAwMGY3ZmZmZmZmIHR5cGU9MTEg
YXR0cj04MDAwMDAwMDAwMDAxMDBkDQooWEVOKSBbICAgIDIuOTE4NTkxXSAgMDAwMDBmZDAwMDAw
MC0wMDAwMGZlZGZmZmZmIHR5cGU9MTEgYXR0cj04MDAwMDAwMDAwMDAxMDBkDQooWEVOKSBbICAg
IDIuOTI1NjEwXSAgMDAwMDBmZWUwMDAwMC0wMDAwMGZlZTAwZmZmIHR5cGU9MTEgYXR0cj04MDAw
MDAwMDAwMDAwMDAxDQooWEVOKSBbICAgIDIuOTMyNjMyXSAgMDAwMDBmZWUwMTAwMC0wMDAwMGZm
ZmZmZmZmIHR5cGU9MTEgYXR0cj04MDAwMDAwMDAwMDAxMDBkDQooWEVOKSBbICAgIDIuOTM5NjQ5
XSAgMDAwMDgwZjM0MDAwMC0wMDAwODJmZmZmZmZmIHR5cGU9MCBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMi45NDY1ODRdICAwMDAwODMwMDAwMDAwLTAwMDA4NTAxZmZmZmYgdHlw
ZT0xMSBhdHRyPTgwMDAwMDAwMDAwMDEwMGQNCihYRU4pIFsgICAgMi45NTM2MDVdIGFsdCB0YWJs
ZSBmZmZmODJkMDQwNGExZmY4IC0+IGZmZmY4MmQwNDA0YjNlZGMNCihYRU4pIFsgICAgMi45NzI5
ODhdIEFNRC1WaTogSU9NTVUgRXh0ZW5kZWQgRmVhdHVyZXM6DQooWEVOKSBbICAgIDIuOTc3NzU1
XSAtIFBlcmlwaGVyYWwgUGFnZSBTZXJ2aWNlIFJlcXVlc3QNCihYRU4pIFsgICAgMi45ODI2MDhd
IC0geDJBUElDDQooWEVOKSBbICAgIDIuOTg1Mjk0XSAtIE5YIGJpdA0KKFhFTikgWyAgICAyLjk4
Nzk4Ml0gLSBJbnZhbGlkYXRlIEFsbCBDb21tYW5kDQooWEVOKSBbICAgIDIuOTkyMDUzXSAtIEd1
ZXN0IEFQSUMNCihYRU4pIFsgICAgMi45OTUwODhdIC0gUGVyZm9ybWFuY2UgQ291bnRlcnMNCihY
RU4pIFsgICAgMi45OTg5ODddIC0gSG9zdCBBZGRyZXNzIFRyYW5zbGF0aW9uIFNpemU6IDB4Mg0K
KFhFTikgWyAgICAzLjAwNDEwMV0gLSBHdWVzdCBBZGRyZXNzIFRyYW5zbGF0aW9uIFNpemU6IDAN
CihYRU4pIFsgICAgMy4wMDkxMjhdIC0gR3Vlc3QgQ1IzIFJvb3QgVGFibGUgTGV2ZWw6IDB4MQ0K
KFhFTikgWyAgICAzLjAxMzk4MV0gLSBNYXhpbXVtIFBBU0lEOiAweGYNCihYRU4pIFsgICAgMy4w
MTc3MDddIC0gU01JIEZpbHRlciBSZWdpc3RlcjogMHgxDQooWEVOKSBbICAgIDMuMDIxOTU1XSAt
IFNNSSBGaWx0ZXIgUmVnaXN0ZXIgQ291bnQ6IDB4MQ0KKFhFTikgWyAgICAzLjAyNjcxOV0gLSBH
dWVzdCBWaXJ0dWFsIEFQSUMgTW9kZXM6IDB4MQ0KKFhFTikgWyAgICAzLjAzMTQwMl0gLSBEdWFs
IFBQUiBMb2c6IDB4Mg0KKFhFTikgWyAgICAzLjAzNTA0MV0gLSBEdWFsIEV2ZW50IExvZzogMHgy
DQooWEVOKSBbICAgIDMuMDM4ODUzXSAtIFVzZXIgLyBTdXBlcnZpc29yIFBhZ2UgUHJvdGVjdGlv
bg0KKFhFTikgWyAgICAzLjA0Mzg4MF0gLSBEZXZpY2UgVGFibGUgU2VnbWVudGF0aW9uOiAweDMN
CihYRU4pIFsgICAgMy4wNDg2NDddIC0gUFBSIExvZyBPdmVyZmxvdyBFYXJseSBXYXJuaW5nDQoo
WEVOKSBbICAgIDMuMDUzNDE1XSAtIFBQUiBBdXRvbWF0aWMgUmVzcG9uc2UNCihYRU4pIFsgICAg
My4wNTc0ODZdIC0gTWVtb3J5IEFjY2VzcyBSb3V0aW5nIGFuZCBDb250cm9sOiAwDQooWEVOKSBb
ICAgIDMuMDYyNzc1XSAtIEJsb2NrIFN0b3BNYXJrIE1lc3NhZ2UNCihYRU4pIFsgICAgMy4wNjY4
NDddIC0gUGVyZm9ybWFuY2UgT3B0aW1pemF0aW9uDQooWEVOKSBbICAgIDMuMDcxMDkzXSAtIE1T
SSBDYXBhYmlsaXR5IE1NSU8gQWNjZXNzDQooWEVOKSBbICAgIDMuMDc1NTE1XSAtIEd1ZXN0IEkv
TyBQcm90ZWN0aW9uDQooWEVOKSBbICAgIDMuMDc5NDEzXSAtIEVuaGFuY2VkIFBQUiBIYW5kbGlu
Zw0KKFhFTikgWyAgICAzLjA4MzQwMF0gLSBBdHRyaWJ1dGUgRm9yd2FyZA0KKFhFTikgWyAgICAz
LjA4NzA0MF0gLSBJbnZhbGlkYXRlIElPVExCIFR5cGUNCihYRU4pIFsgICAgMy4wOTEwMjhdIC0g
Vk0gVGFibGUgU2l6ZTogMA0KKFhFTikgWyAgICAzLjA5NDU3OV0gLSBHdWVzdCBBY2Nlc3MgQml0
IFVwZGF0ZSBEaXNhYmxlDQooWEVOKSBbICAgIDMuMTEwNTY5XSBBTUQtVmk6IERpc2FibGVkIEhB
UCBtZW1vcnkgbWFwIHNoYXJpbmcgd2l0aCBJT01NVQ0KKFhFTikgWyAgICAzLjExNjg5M10gQU1E
LVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBbICAgIDMuMTIwOTY3XSBJL08gdmlydHVhbGlz
YXRpb24gZW5hYmxlZA0KKFhFTikgWyAgICAzLjEyNTIxM10gIC0gRG9tMCBtb2RlOiBSZWxheGVk
DQooWEVOKSBbICAgIDMuMTI5MDI2XSBJbnRlcnJ1cHQgcmVtYXBwaW5nIGVuYWJsZWQNCihYRU4p
IFsgICAgMy4xMzMzNjBdIG5yX3NvY2tldHM6IDENCihYRU4pIFsgICAgMy4xMzY0NzldIEVuYWJs
aW5nIEFQSUMgbW9kZS4gIFVzaW5nIDIgSS9PIEFQSUNzDQooWEVOKSBbICAgIDMuMTQyMzczXSBF
TkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pIFsgICAgMy4xNDYxODZdICAtPiBVc2luZyBuZXcg
QUNLIG1ldGhvZA0KKFhFTikgWyAgICAzLjE1MDI5MF0gLi5USU1FUjogdmVjdG9yPTB4RjAgYXBp
YzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0tMQ0KKFhFTikgWyAgICAzLjMwNjYzOV0gV2FsbGNs
b2NrIHNvdXJjZTogQ01PUyBSVEMNCihYRU4pIFsgICAgMy43NDMyODZdIEFsbG9jYXRlZCBjb25z
b2xlIHJpbmcgb2YgMTI4IEtpQi4NCihYRU4pIFsgICAgMy43NDgyMjZdIG13YWl0LWlkbGU6IGRv
ZXMgbm90IHJ1biBvbiBmYW1pbHkgMjMgbW9kZWwgOTYNCihYRU4pIFsgICAgMy43NTQyMDhdIEhW
TTogQVNJRHMgZW5hYmxlZC4NCihYRU4pIFsgICAgMy43NTc4NDldIFNWTTogU3VwcG9ydGVkIGFk
dmFuY2VkIGZlYXR1cmVzOg0KKFhFTikgWyAgICAzLjc2MjcwMV0gIC0gTmVzdGVkIFBhZ2UgVGFi
bGVzIChOUFQpDQooWEVOKSBbICAgIDMuNzY3MDMyXSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQgKExC
UikgVmlydHVhbGlzYXRpb24NCihYRU4pIFsgICAgMy43NzI2NjddICAtIE5leHQtUklQIFNhdmVk
IG9uICNWTUVYSVQNCihYRU4pIFsgICAgMy43NzcwODldICAtIFZNQ0IgQ2xlYW4gQml0cw0KKFhF
TikgWyAgICAzLjc4MDY0Ml0gIC0gVExCIGZsdXNoIGJ5IEFTSUQNCihYRU4pIFsgICAgMy43ODQz
NjZdICAtIERlY29kZUFzc2lzdHMNCihYRU4pIFsgICAgMy43ODc3NDhdICAtIFZpcnR1YWwgVk1M
T0FEL1ZNU0FWRQ0KKFhFTikgWyAgICAzLjc5MTgyM10gIC0gVmlydHVhbCBHSUYNCihYRU4pIFsg
ICAgMy43OTUwMjddICAtIFBhdXNlLUludGVyY2VwdCBGaWx0ZXINCihYRU4pIFsgICAgMy43OTkx
ODldICAtIFBhdXNlLUludGVyY2VwdCBGaWx0ZXIgVGhyZXNob2xkDQooWEVOKSBbICAgIDMuODA0
MjEzXSAgLSBUU0MgUmF0ZSBNU1INCihYRU4pIFsgICAgMy44MDc1MDhdICAtIE1TUl9TUEVDX0NU
UkwgdmlydHVhbGlzYXRpb24NCihYRU4pIFsgICAgMy44MTIxODZdIEhWTTogU1ZNIGVuYWJsZWQN
CihYRU4pIFsgICAgMy44MTU1NjldIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVAp
IGRldGVjdGVkDQooWEVOKSBbICAgIDMuODIxMzc1XSBIVk06IEhBUCBwYWdlIHNpemVzOiA0a0Is
IDJNQiwgMUdCDQooWEVOKSBbICAgIDQuMTMzMDUwXSBCcm91Z2h0IHVwIDE2IENQVXMNCihYRU4p
IFsgICAgNC4xMzc2OTRdIFNjaGVkdWxpbmcgZ3JhbnVsYXJpdHk6IGNwdSwgMSBDUFUgcGVyIHNj
aGVkLXJlc291cmNlDQooWEVOKSBbICAgIDQuMTQ0MjgyXSBJbml0aWFsaXppbmcgbnVsbCBzY2hl
ZHVsZXINCihYRU4pIFsgICAgNC4xNDg2MTFdIFdBUk5JTkc6IFRoaXMgaXMgZXhwZXJpbWVudGFs
IHNvZnR3YXJlIGluIGRldmVsb3BtZW50Lg0KKFhFTikgWyAgICA0LjE1NTI4OV0gVXNlIGF0IHlv
dXIgb3duIHJpc2suDQooWEVOKSBbICAgIDQuMTU5MTAyXSBtY2hlY2tfcG9sbDogTWFjaGluZSBj
aGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuDQooWEVOKSBbICAgIDQuMTY1MzQwXSBSdW5uaW5n
IHN0dWIgcmVjb3Zlcnkgc2VsZnRlc3RzLi4uDQooWEVOKSBbICAgIDQuMTcwMjc5XSBGaXh1cCAj
VURbMDAwMF06IGZmZmY4MmQwN2ZmZmUwNDQgW2ZmZmY4MmQwN2ZmZmUwNDRdIC0+IGZmZmY4MmQw
NDAzOGZmNmMNCihYRU4pIFsgICAgNC4xNzg1MTNdIEZpeHVwICNHUFswMDAwXTogZmZmZjgyZDA3
ZmZmZTA0NSBbZmZmZjgyZDA3ZmZmZTA0NV0gLT4gZmZmZjgyZDA0MDM4ZmY2Yw0KKFhFTikgWyAg
ICA0LjE4Njc0N10gRml4dXAgI1NTWzAwMDBdOiBmZmZmODJkMDdmZmZlMDQ0IFtmZmZmODJkMDdm
ZmZlMDQ0XSAtPiBmZmZmODJkMDQwMzhmZjZjDQooWEVOKSBbICAgIDQuMTk0OTc3XSBGaXh1cCAj
QlBbMDAwMF06IGZmZmY4MmQwN2ZmZmUwNDUgW2ZmZmY4MmQwN2ZmZmUwNDVdIC0+IGZmZmY4MmQw
NDAzOGZmNmMNCihYRU4pIFsgICAgNC4yMjMxNDVdIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3Rl
Y3Rpb24gYWN0aXZlDQooWEVOKSBbICAgIDQuMjI4NDMwXSBkMCBoYXMgbWF4aW11bSAzMzI4IFBJ
UlFzDQooWEVOKSBbICAgIDQuMjMyNjc4XSAqKiogQnVpbGRpbmcgYSBQVkggRG9tMCAqKioNCihY
RU4pIFsgICAgNC4yNDA1NDNdIGQwOiBpZGVudGl0eSBtYXBwaW5ncyBmb3IgSU9NTVU6DQooWEVO
KSBbICAgIDQuMjQ1MzEyXSAgWzAwMDAwMDAwYTAsIDAwMDAwMDAwZmZdIFJXDQooWEVOKSBbICAg
IDQuMjQ5NzI4XSAgWzAwMDAwMDliZmYsIDAwMDAwMDlmZmZdIFJXDQooWEVOKSBbICAgIDQuMjU0
MTU0XSAgWzAwMDAwY2FiYzksIDAwMDAwY2MxNGNdIFJXDQooWEVOKSBbICAgIDQuMjU4NzY0XSAg
WzAwMDAwY2MzODksIDAwMDAwY2MzODldIFJXDQooWEVOKSBbICAgIDQuMjYzMTg5XSAgWzAwMDAw
Y2M3MGEsIDAwMDAwY2QxZmVdIFJXDQooWEVOKSBbICAgIDQuMjY4MTExXSAgWzAwMDAwY2UwMDAs
IDAwMDAwY2ZmZmZdIFJXDQooWEVOKSBbICAgIDQuMjcyNTMxXSAgWzAwMDAwZmQwMDAsIDAwMDAw
ZmQyZmZdIFJXDQooWEVOKSBbICAgIDQuMjc3MDI1XSAgWzAwMDAwZmQzMDQsIDAwMDAwZmViZmZd
IFJXDQooWEVOKSBbICAgIDQuMjgxNTEzXSAgWzAwMDAwZmVjMDIsIDAwMDAwZmVkZmZdIFJXDQoo
WEVOKSBbICAgIDQuMjg2MjIxXSAgWzAwMDAwZmVlMDEsIDAwMDAwZmZmZmZdIFJXDQooWEVOKSBb
ICAgIDQuMjkwOTQwXSAgWzAwMDA4MGYzNDAsIDAwMDA4NTAxZmZdIFJXDQooWEVOKSBbICAgIDQu
Mjk2MzAzXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZFtJRExFXXYwIDAwMDA6MDI6MDAuMDogQkFSIGF0
IFtmZWEwMCwgZmVhMDNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAgNC4zMDU4
MzldIGFyY2gveDg2L3BjaS5jOjEwOTpkW0lETEVddjAgMDAwMDowMjowMC4wOiBCQVIgYXQgW2Zl
YTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgICA0LjMxNTM3MF0g
YXJjaC94ODYvcGNpLmM6MTA5OmRbSURMRV12MCAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MDAs
IGZlOTBmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgIDQuMzI0OTA0XSBhcmNo
L3g4Ni9wY2kuYzoxMDk6ZFtJRExFXXYwIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5
MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAgNC4zMzQ0MzldIGFyY2gveDg2
L3BjaS5jOjEwOTpkW0lETEVddjAgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTAwLCBmZTkwZl0g
bm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgICA0LjM0Mzk3NV0gYXJjaC94ODYvcGNp
LmM6MTA5OmRbSURMRV12MCAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MTAsIGZlOTEzXSBub3Qg
aW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgIDQuMzUzNTA3XSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZFtJRExFXXYwIDAwMDA6MDQ6MDAuMDogQkFSIGF0IFtmZTcwMCwgZmU3N2ZdIG5vdCBpbiBt
ZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAgNC4zNjMwNTRdIGFyY2gveDg2L3BjaS5jOjEwOTpk
W0lETEVddjAgMDAwMDowNDowMC4wOiBCQVIgYXQgW2ZlNzAwLCBmZTc3Zl0gbm90IGluIG1lbW9y
eSBtYXAgaG9sZQ0KKFhFTikgWyAgICA0LjM3MjU4Nl0gYXJjaC94ODYvcGNpLmM6MTA5OmRbSURM
RV12MCAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1h
cCBob2xlDQooWEVOKSBbICAgIDQuMzgyMTIyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZFtJRExFXXYw
IDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhv
bGUNCihYRU4pIFsgICAgNC4zOTE2NTVdIGFyY2gveDg2L3BjaS5jOjEwOTpkW0lETEVddjAgMDAw
MDowNDowMC40OiBCQVIgYXQgW2ZlNDAwLCBmZTRmZl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0K
KFhFTikgWyAgICA0LjQwMTE4M10gYXJjaC94ODYvcGNpLmM6MTA5OmRbSURMRV12MCAwMDAwOjA0
OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVO
KSBbICAgIDQuNDEwNzIyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZFtJRExFXXYwIDAwMDA6MDU6MDAu
MDogQkFSIGF0IFtmZTgwMSwgZmU4MDFdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsg
ICAgNC40MjAyNTNdIGFyY2gveDg2L3BjaS5jOjEwOTpkW0lETEVddjAgMDAwMDowNTowMC4wOiBC
QVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgICA0
LjQyOTc4OF0gYXJjaC94ODYvcGNpLmM6MTA5OmRbSURMRV12MCAwMDAwOjA1OjAwLjE6IEJBUiBh
dCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgIDQuNDM5
MzIwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZFtJRExFXXYwIDAwMDA6MDU6MDAuMTogQkFSIGF0IFtm
ZTgwMCwgZmU4MDBdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAgNC41NTcwMThd
IERvbTAgbWVtb3J5IGFsbG9jYXRpb24gc3RhdHM6DQooWEVOKSBbICAgIDQuNTYxNTI2XSBvcmRl
ciAgMCBhbGxvY2F0aW9uczogNA0KKFhFTikgWyAgICA0LjU2NTUwOF0gb3JkZXIgIDEgYWxsb2Nh
dGlvbnM6IDINCihYRU4pIFsgICAgNC41Njk1MDBdIG9yZGVyICAyIGFsbG9jYXRpb25zOiAyDQoo
WEVOKSBbICAgIDQuNTczNDgyXSBvcmRlciAgMyBhbGxvY2F0aW9uczogMg0KKFhFTikgWyAgICA0
LjU3NzQ2OF0gb3JkZXIgIDQgYWxsb2NhdGlvbnM6IDINCihYRU4pIFsgICAgNC41ODE0NTZdIG9y
ZGVyICA1IGFsbG9jYXRpb25zOiA0DQooWEVOKSBbICAgIDQuNTg1NDQyXSBvcmRlciAgNiBhbGxv
Y2F0aW9uczogMw0KKFhFTikgWyAgICA0LjU4OTQzMV0gb3JkZXIgIDcgYWxsb2NhdGlvbnM6IDUN
CihYRU4pIFsgICAgNC41OTM0MjFdIG9yZGVyICA4IGFsbG9jYXRpb25zOiA0DQooWEVOKSBbICAg
IDQuNTk3NDA3XSBvcmRlciAgOSBhbGxvY2F0aW9uczogNg0KKFhFTikgWyAgICA0LjYwMTM4OF0g
b3JkZXIgMTAgYWxsb2NhdGlvbnM6IDMNCihYRU4pIFsgICAgNC42MDUzODBdIG9yZGVyIDExIGFs
bG9jYXRpb25zOiA2DQooWEVOKSBbICAgIDQuNjA5MzYxXSBvcmRlciAxMiBhbGxvY2F0aW9uczog
Mw0KKFhFTikgWyAgICA0LjYxMzM1MV0gb3JkZXIgMTMgYWxsb2NhdGlvbnM6IDINCihYRU4pIFsg
ICAgNC42MTczNDFdIG9yZGVyIDE0IGFsbG9jYXRpb25zOiAzDQooWEVOKSBbICAgIDQuNjIxMzI4
XSBvcmRlciAxNSBhbGxvY2F0aW9uczogMQ0KKFhFTikgWyAgICA0LjYyNTMxNF0gb3JkZXIgMTYg
YWxsb2NhdGlvbnM6IDINCihYRU4pIFsgICAgNC42MjkyOThdIG9yZGVyIDE3IGFsbG9jYXRpb25z
OiAyDQooWEVOKSBbICAgIDQuNjMzMjg3XSBvcmRlciAxOCBhbGxvY2F0aW9uczogMg0KKFhFTikg
WyAgICA0LjkzMDg0NV0gRUxGOiBwaGRyOiBwYWRkcj0weDEwMDAwMDAgbWVtc3o9MHgxYjFhMDBj
DQooWEVOKSBbICAgIDQuOTM2NDc3XSBFTEY6IHBoZHI6IHBhZGRyPTB4MmMwMDAwMCBtZW1zej0w
eDg5MjAwMA0KKFhFTikgWyAgICA0Ljk0MjAyN10gRUxGOiBwaGRyOiBwYWRkcj0weDM0OTIwMDAg
bWVtc3o9MHgyZmVkOA0KKFhFTikgWyAgICA0Ljk0NzQ4NF0gRUxGOiBwaGRyOiBwYWRkcj0weDM0
YzIwMDAgbWVtc3o9MHg1NmUwMDANCihYRU4pIFsgICAgNC45NTMwMzFdIEVMRjogbWVtb3J5OiAw
eDEwMDAwMDAgLT4gMHgzYTMwMDAwDQooWEVOKSBbICAgIDQuOTU4MDU3XSBFTEY6IG5vdGU6IFBI
WVMzMl9FTlRSWSA9IDB4MTAwMDAwMA0KKFhFTikgWyAgICA0Ljk2MzA4OF0gRUxGOiBub3RlOiBH
VUVTVF9PUyA9ICJsaW51eCINCihYRU4pIFsgICAgNC45Njc1OTZdIEVMRjogbm90ZTogR1VFU1Rf
VkVSU0lPTiA9ICIyLjYiDQooWEVOKSBbICAgIDQuOTcyMzYwXSBFTEY6IG5vdGU6IFhFTl9WRVJT
SU9OID0gInhlbi0zLjAiDQooWEVOKSBbICAgIDQuOTc3Mjk5XSBFTEY6IG5vdGU6IFZJUlRfQkFT
RSA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWyAgICA0Ljk4Mjg0NV0gRUxGOiBub3RlOiBJ
TklUX1AyTSA9IDB4ODAwMDAwMDAwMA0KKFhFTikgWyAgICA0Ljk4Nzc4N10gRUxGOiBub3RlOiBF
TlRSWSA9IDB4ZmZmZmZmZmY4MzRkNDYzMA0KKFhFTikgWyAgICA0Ljk5Mjk4N10gRUxGOiBub3Rl
OiBGRUFUVVJFUyA9ICIhd3JpdGFibGVfcGFnZV90YWJsZXMiDQooWEVOKSBbICAgIDQuOTk4ODgx
XSBFTEY6IG5vdGU6IFBBRV9NT0RFID0gInllcyINCihYRU4pIFsgICAgNS4wMDMyMTRdIEVMRjog
bm90ZTogTDFfTUZOX1ZBTElEDQooWEVOKSBbICAgIDUuMDA3MTk3XSBFTEY6IG5vdGU6IE1PRF9T
VEFSVF9QRk4gPSAweDENCihYRU4pIFsgICAgNS4wMTE3OTRdIEVMRjogbm90ZTogUEFERFJfT0ZG
U0VUID0gMA0KKFhFTikgWyAgICA1LjAxNjEyOF0gRUxGOiBub3RlOiBIWVBFUkNBTExfUEFHRSA9
IDB4ZmZmZmZmZmY4MjAzNDAwMA0KKFhFTikgWyAgICA1LjAyMjEwNF0gRUxGOiBub3RlOiBTVVBQ
T1JURURfRkVBVFVSRVMgPSAweDg4MDENCihYRU4pIFsgICAgNS4wMjczOTZdIEVMRjogbm90ZTog
TE9BREVSID0gImdlbmVyaWMiDQooWEVOKSBbICAgIDUuMDMxOTAxXSBFTEY6IG5vdGU6IFNVU1BF
TkRfQ0FOQ0VMID0gMHgxDQooWEVOKSBbICAgIDUuMDM2NTgxXSBFTEY6IEZvdW5kIFBWSCBpbWFn
ZQ0KKFhFTikgWyAgICA1LjA0MDMwNl0gRUxGOiBhZGRyZXNzZXM6DQooWEVOKSBbICAgIDUuMDQz
NTk4XSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4MA0KKFhFTikgWyAgICA1LjA0Nzg0OV0gICAg
IGVsZl9wYWRkcl9vZmZzZXQgPSAweDANCihYRU4pIFsgICAgNS4wNTIwOTFdICAgICB2aXJ0X29m
ZnNldCAgICAgID0gMHgwDQooWEVOKSBbICAgIDUuMDU2MzQzXSAgICAgdmlydF9rc3RhcnQgICAg
ICA9IDB4MTAwMDAwMA0KKFhFTikgWyAgICA1LjA2MTExMF0gICAgIHZpcnRfa2VuZCAgICAgICAg
PSAweDNhMzAwMDANCihYRU4pIFsgICAgNS4wNjU4NzZdICAgICB2aXJ0X2VudHJ5ICAgICAgID0g
MHgxMDAwMDAwDQooWEVOKSBbICAgIDUuMDcwNjQyXSAgICAgcDJtX2Jhc2UgICAgICAgICA9IDB4
ODAwMDAwMDAwMA0KKFhFTikgWyAgICA1LjA3NTY2N10gRUxGOiBwaGRyIDAgYXQgMHgxMDAwMDAw
IC0+IDB4MmIxYTAwYw0KKFhFTikgWyAgICA1LjA4ODA3N10gRUxGOiBwaGRyIDEgYXQgMHgyYzAw
MDAwIC0+IDB4MzQ5MjAwMA0KKFhFTikgWyAgICA1LjA5NTQ5OV0gRUxGOiBwaGRyIDIgYXQgMHgz
NDkyMDAwIC0+IDB4MzRjMWVkOA0KKFhFTikgWyAgICA1LjEwMDY5OF0gRUxGOiBwaGRyIDMgYXQg
MHgzNGMyMDAwIC0+IDB4Mzc4OTAwMA0KKFhFTikgWyAgICA1LjE2NTQ4Nl0gRG9tMCBtZW1vcnkg
bWFwOg0KKFhFTikgWyAgICA1LjE2ODg2N10gIFswMDAwMDAwMDAwMDAwMDAwLCAwMDAwMDAwMDAw
MDlmZmZmXSAodXNhYmxlKQ0KKFhFTikgWyAgICA1LjE3NDg0N10gIFswMDAwMDAwMDAwMGEwMDAw
LCAwMDAwMDAwMDAwMGZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbICAgIDUuMTgwOTk1XSAgWzAw
MDAwMDAwMDAxMDAwMDAsIDAwMDAwMDAwMDliZmVmZmZdICh1c2FibGUpDQooWEVOKSBbICAgIDUu
MTg2OTgwXSAgWzAwMDAwMDAwMDliZmYwMDAsIDAwMDAwMDAwMDlmZmZmZmZdIChyZXNlcnZlZCkN
CihYRU4pIFsgICAgNS4xOTMxMjldICBbMDAwMDAwMDAwYTAwMDAwMCwgMDAwMDAwMDAwYTFmZmZm
Zl0gKHVzYWJsZSkNCihYRU4pIFsgICAgNS4xOTkxMTFdICBbMDAwMDAwMDAwYTIwMDAwMCwgMDAw
MDAwMDAwYTIwY2ZmZl0gKEFDUEkgTlZTKQ0KKFhFTikgWyAgICA1LjIwNTI2NV0gIFswMDAwMDAw
MDBhMjBkMDAwLCAwMDAwMDAwMGNhYmM4ZmZmXSAodXNhYmxlKQ0KKFhFTikgWyAgICA1LjIxMTI0
Nl0gIFswMDAwMDAwMGNhYmM5MDAwLCAwMDAwMDAwMGNjMTRjZmZmXSAocmVzZXJ2ZWQpDQooWEVO
KSBbICAgIDUuMjE3Mzk1XSAgWzAwMDAwMDAwY2MxNGQwMDAsIDAwMDAwMDAwY2MxOTVmZmZdIChB
Q1BJIGRhdGEpDQooWEVOKSBbICAgIDUuMjIzNjM5XSAgWzAwMDAwMDAwY2MxOTYwMDAsIDAwMDAw
MDAwY2MzODhmZmZdIChBQ1BJIE5WUykNCihYRU4pIFsgICAgNS4yMjk3OTNdICBbMDAwMDAwMDBj
YzM4OTAwMCwgMDAwMDAwMDBjYzM4OWZmZl0gKHJlc2VydmVkKQ0KKFhFTikgWyAgICA1LjIzNTk0
Nl0gIFswMDAwMDAwMGNjMzhhMDAwLCAwMDAwMDAwMGNjNzA5ZmZmXSAoQUNQSSBOVlMpDQooWEVO
KSBbICAgIDUuMjQyMTAxXSAgWzAwMDAwMDAwY2M3MGEwMDAsIDAwMDAwMDAwY2QxZmVmZmZdIChy
ZXNlcnZlZCkNCihYRU4pIFsgICAgNS4yNDgyNDldICBbMDAwMDAwMDBjZDFmZjAwMCwgMDAwMDAw
MDBjZGZmZmVhN10gKHVzYWJsZSkNCihYRU4pIFsgICAgNS4yNTQyMzBdICBbMDAwMDAwMDBjZGZm
ZmVhOCwgMDAwMDAwMDBjZGZmZmYzZl0gKEFDUEkgZGF0YSkNCihYRU4pIFsgICAgNS4yNjA0NzFd
ICBbMDAwMDAwMDBjZTAwMDAwMCwgMDAwMDAwMDBjZmZmZmZmZl0gKHJlc2VydmVkKQ0KKFhFTikg
WyAgICA1LjI2NjYyNV0gIFswMDAwMDAwMGYwMDAwMDAwLCAwMDAwMDAwMGY3ZmZmZmZmXSAocmVz
ZXJ2ZWQpDQooWEVOKSBbICAgIDUuMjcyNzgwXSAgWzAwMDAwMDAwZmQwMDAwMDAsIDAwMDAwMDAw
ZmZmZmZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFsgICAgNS4yNzg5MzJdICBbMDAwMDAwMDEwMDAw
MDAwMCwgMDAwMDAwMDEzNGFhM2ZmZl0gKHVzYWJsZSkNCihYRU4pIFsgICAgNS4yODQ5MTJdICBb
MDAwMDAwMDEzNGFhNDAwMCwgMDAwMDAwMDgwZjMzZmZmZl0gKHVudXNhYmxlKQ0KKFhFTikgWyAg
ICA1LjI5MTA2N10gIFswMDAwMDAwODBmMzQwMDAwLCAwMDAwMDAwODUwMWZmZmZmXSAocmVzZXJ2
ZWQpDQooWEVOKSBbICAgIDUuMjk3MjE5XSBJbml0aWFsIGxvdyBtZW1vcnkgdmlycSB0aHJlc2hv
bGQgc2V0IGF0IDB4NDAwMCBwYWdlcy4NCihYRU4pIFsgICAgNS4zMDM4OTRdIFNjcnViYmluZyBG
cmVlIFJBTSBpbiBiYWNrZ3JvdW5kDQooWEVOKSBbICAgIDUuMzA4NjYwXSBTdGQuIExvZ2xldmVs
OiBBbGwNCihYRU4pIFsgICAgNS4zMTIyMTJdIEd1ZXN0IExvZ2xldmVsOiBBbGwNCihYRU4pIFsg
ICAgNS4zMTU4NTFdICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKg0KKFhFTikgWyAgICA1LjMyMjI2Ml0gV0FSTklORzogQ09OU09MRSBPVVRQVVQgSVMg
U1lOQ0hST05PVVMNCihYRU4pIFsgICAgNS4zMjc1NTJdIFRoaXMgb3B0aW9uIGlzIGludGVuZGVk
IHRvIGFpZCBkZWJ1Z2dpbmcgb2YgWGVuIGJ5IGVuc3VyaW5nDQooWEVOKSBbICAgIDUuMzM0NjU5
XSB0aGF0IGFsbCBvdXRwdXQgaXMgc3luY2hyb25vdXNseSBkZWxpdmVyZWQgb24gdGhlIHNlcmlh
bCBsaW5lLg0KKFhFTikgWyAgICA1LjM0MjAyNV0gSG93ZXZlciBpdCBjYW4gaW50cm9kdWNlIFNJ
R05JRklDQU5UIGxhdGVuY2llcyBhbmQgYWZmZWN0DQooWEVOKSBbICAgIDUuMzQ4OTU3XSB0aW1l
a2VlcGluZy4gSXQgaXMgTk9UIHJlY29tbWVuZGVkIGZvciBwcm9kdWN0aW9uIHVzZSENCihYRU4p
IFsgICAgNS4zNTU2MjldICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKg0KKFhFTikgWyAgICA1LjM2MjA0Nl0gMy4uLiAyLi4uIDEuLi4NCihYRU4pIFsg
ICAgOC4zNjU0MTVdICoqKiBTZXJpYWwgaW5wdXQgdG8gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJl
ZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQpDQooWEVOKSBbICAgIDguMzczNjQzXSBjb21tb24vc2No
ZWQvbnVsbC5jOjM1NzogMCA8LS0gZDB2MA0KKFhFTikgWyAgICA4LjM3ODg3MV0gRnJlZWQgNjU2
a0IgaW5pdCBtZW1vcnkNClsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gNi4xMS4wIChyb290
QGQzNDg0NTcxY2M2MikgKGdjYyAoQWxwaW5lIDEyLjIuMV9naXQyMDIyMDkyNC1yMTApIDEyLjIu
MSAyMDIyMDkyNCwgR05VIGxkIChHTlUgQmludXRpbHMpIDIuNDApICMxIFNNUCBQUkVFTVBUX0RZ
TkFNSUMgTW9uIE1heSAxMiAxNjo1MDoyNiBVVEMgMjAyNQ0KWyAgICAwLjAwMDAwMF0gQ29tbWFu
ZCBsaW5lOiBjb25zb2xlPWh2YzAgcm9vdD0vZGV2L3JhbTAgZWFybHlwcmludGs9eGVuIGRlYnVn
IHJkaW5pdD0vYmluL3NoDQpbICAgIDAuMDAwMDAwXSBbRmlybXdhcmUgQnVnXTogVFNDIGRvZXNu
J3QgY291bnQgd2l0aCBQMCBmcmVxdWVuY3khDQpbICAgIDAuMDAwMDAwXSBCSU9TLXByb3ZpZGVk
IHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAw
MDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZmZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBC
SU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMDAwMGEwMDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVz
ZXJ2ZWQNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAt
MHgwMDAwMDAwMDA5YmZlZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21l
bSAweDAwMDAwMDAwMDliZmYwMDAtMHgwMDAwMDAwMDA5ZmZmZmZmXSByZXNlcnZlZA0KWyAgICAw
LjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDAwYTAwMDAwMC0weDAwMDAwMDAwMGEx
ZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDAw
YTIwMDAwMC0weDAwMDAwMDAwMGEyMGNmZmZdIEFDUEkgTlZTDQpbICAgIDAuMDAwMDAwXSBCSU9T
LWU4MjA6IFttZW0gMHgwMDAwMDAwMDBhMjBkMDAwLTB4MDAwMDAwMDBjYWJjOGZmZl0gdXNhYmxl
DQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMGNhYmM5MDAwLTB4MDAw
MDAwMDBjYzE0Y2ZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAw
eDAwMDAwMDAwY2MxNGQwMDAtMHgwMDAwMDAwMGNjMTk1ZmZmXSBBQ1BJIGRhdGENClsgICAgMC4w
MDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwY2MxOTYwMDAtMHgwMDAwMDAwMGNjMzg4
ZmZmXSBBQ1BJIE5WUw0KWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDBj
YzM4OTAwMC0weDAwMDAwMDAwY2MzODlmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBCSU9T
LWU4MjA6IFttZW0gMHgwMDAwMDAwMGNjMzhhMDAwLTB4MDAwMDAwMDBjYzcwOWZmZl0gQUNQSSBO
VlMNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwY2M3MGEwMDAtMHgw
MDAwMDAwMGNkMWZlZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVt
IDB4MDAwMDAwMDBjZDFmZjAwMC0weDAwMDAwMDAwY2RmZmZlYTddIHVzYWJsZQ0KWyAgICAwLjAw
MDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDBjZGZmZmVhOC0weDAwMDAwMDAwY2RmZmZm
M2ZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDBj
ZTAwMDAwMC0weDAwMDAwMDAwY2ZmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBCSU9T
LWU4MjA6IFttZW0gMHgwMDAwMDAwMGYwMDAwMDAwLTB4MDAwMDAwMDBmN2ZmZmZmZl0gcmVzZXJ2
ZWQNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwZmQwMDAwMDAtMHgw
MDAwMDAwMGZmZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVt
IDB4MDAwMDAwMDEwMDAwMDAwMC0weDAwMDAwMDA4MGYzM2ZmZmZdIHVzYWJsZQ0KWyAgICAwLjAw
MDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDgwZjM0MDAwMC0weDAwMDAwMDA4NTAxZmZm
ZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBwcmludGs6IGxlZ2FjeSBib290Y29uc29sZSBb
eGVuYm9vdDBdIGVuYWJsZWQNClsgICAgMC4wMDAwMDBdIE5YIChFeGVjdXRlIERpc2FibGUpIHBy
b3RlY3Rpb246IGFjdGl2ZQ0KWyAgICAwLjAwMDAwMF0gQVBJQzogU3RhdGljIGNhbGxzIGluaXRp
YWxpemVkDQpbICAgIDAuMDAwMDAwXSBlZmk6IEVGSSB2Mi43IGJ5IEFtZXJpY2FuIE1lZ2F0cmVu
ZHMNClsgICAgMC4wMDAwMDBdIGVmaTogQUNQST0weGNjNmYzMDAwIEFDUEkgMi4wPTB4Y2M2ZjMw
MTQgVFBNRmluYWxMb2c9MHhjYzZjMjAwMCBTTUJJT1M9MHhjY2ZkNjAwMCBTTUJJT1MgMy4wPTB4
Y2NmZDUwMDAgKE1FTUFUVFI9MHhjN2E0YjUxOCB1bnVzYWJsZSkgRVNSVD0weGNjMTVhMDE4DQpb
ICAgIDAuMDAwMDAwXSBTTUJJT1MgMy4yLjAgcHJlc2VudC4NClsgICAgMC4wMDAwMDBdIERNSTog
IC83RDc4NSAvIDdENzg2LCBCSU9TIDUuMTYgMDIvMjQvMjAyNQ0KWyAgICAwLjAwMDAwMF0gRE1J
OiBNZW1vcnkgc2xvdHMgcG9wdWxhdGVkOiAyLzINClsgICAgMC4wMDAwMDBdIEh5cGVydmlzb3Ig
ZGV0ZWN0ZWQ6IFhlbiBIVk0NClsgICAgMC4wMDAwMDBdIFhlbiB2ZXJzaW9uIDQuMjEuDQpbICAg
IDAuMDAwMDA0XSBIVk1PUF9wYWdldGFibGVfZHlpbmcgbm90IHN1cHBvcnRlZA0KWyAgICAwLjA0
OTEyOV0gdHNjOiBGYXN0IFRTQyBjYWxpYnJhdGlvbiBmYWlsZWQNClsgICAgMC4wNTMyMjldIHRz
YzogRGV0ZWN0ZWQgMjg5NC41NTIgTUh6IHByb2Nlc3Nvcg0KWyAgICAwLjA1Nzk2NF0gZTgyMDog
dXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDAwZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkDQpb
ICAgIDAuMDY0NDk1XSBlODIwOiByZW1vdmUgW21lbSAweDAwMGEwMDAwLTB4MDAwZmZmZmZdIHVz
YWJsZQ0KWyAgICAwLjA3MDA0N10gbGFzdF9wZm4gPSAweDgwZjM0MCBtYXhfYXJjaF9wZm4gPSAw
eDQwMDAwMDAwMA0KWyAgICAwLjA3NTU1N10gTVRSUiBtYXA6IDQgZW50cmllcyAoMyBmaXhlZCAr
IDEgdmFyaWFibGU7IG1heCAyMCksIGJ1aWx0IGZyb20gOSB2YXJpYWJsZSBNVFJScw0KWyAgICAw
LjA4MzgyMV0geDg2L1BBVDogQ29uZmlndXJhdGlvbiBbMC03XTogV0IgIFdDICBVQy0gVUMgIFdC
ICBXUCAgVUMtIFdUDQpbICAgIDAuMDkxNzY1XSBDUFUgTVRSUnMgYWxsIGJsYW5rIC0gdmlydHVh
bGl6ZWQgc3lzdGVtLg0KWyAgICAwLjA5NjY1NV0gbGFzdF9wZm4gPSAweGNkZmZmIG1heF9hcmNo
X3BmbiA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMTA1NzEwXSBlc3J0OiBSZXNlcnZpbmcgRVNSVCBz
cGFjZSBmcm9tIDB4MDAwMDAwMDBjYzE1YTAxOCB0byAweDAwMDAwMDAwY2MxNWEwNTAuDQpbICAg
IDAuMTEzMzY1XSBVc2luZyBHQiBwYWdlcyBmb3IgZGlyZWN0IG1hcHBpbmcNClsgICAgMC4xMTg1
MjBdIFNlY3VyZSBib290IGRpc2FibGVkDQpbICAgIDAuMTIxNTgxXSBSQU1ESVNLOiBbbWVtIDB4
MGEyMGQwMDAtMHgxNmNlMGZmZl0NClsgICAgMC4xMjY2ODhdIEFDUEk6IEVhcmx5IHRhYmxlIGNo
ZWNrc3VtIHZlcmlmaWNhdGlvbiBkaXNhYmxlZA0KWyAgICAwLjEzMjE3OV0gQUNQSTogUlNEUCAw
eDAwMDAwMDAwQ0RGRkZFQTggMDAwMDI0ICh2MDIgQUxBU0tBKQ0KWyAgICAwLjEzNzg5Nl0gQUNQ
STogWFNEVCAweDAwMDAwMDAwQ0RGRkZFQ0MgMDAwMDlDICh2MDEgQUxBU0tBIEEgTSBJICAgIDAx
MDcyMDA5IEFNSSAgMDEwMDAwMTMpDQpbICAgIDAuMTQ2MzkwXSBBQ1BJOiBBUElDIDB4MDAwMDAw
MDBDREZGRkY2OCAwMDAwOTggKHYwMyBBTEFTS0EgQSBNIEkgICAgMDEwNzIwMDkgQU1JICAwMDAx
MDAxMykNClsgICAgMC4xNTQ4ODNdIEFDUEk6IEZBQ1AgMHgwMDAwMDAwMENDMThDMDAwIDAwMDEx
NCAodjA2IEFMQVNLQSBBIE0gSSAgICAwMTA3MjAwOSBBTUkgIDAwMDEwMDEzKQ0KWyAgICAwLjE2
MzQxOF0gQUNQSTogRFNEVCAweDAwMDAwMDAwQ0MxODMwMDAgMDA4NzZEICh2MDIgQUxBU0tBIEEg
TSBJICAgIDAxMDcyMDA5IElOVEwgMjAxMjA5MTMpDQpbICAgIDAuMTcxODY3XSBBQ1BJOiBGQUNT
IDB4MDAwMDAwMDBDQzZDMDAwMCAwMDAwNDANClsgICAgMC4xNzY0NjBdIEFDUEk6IFNTRFQgMHgw
MDAwMDAwMENDMThFMDAwIDAwNzIzQyAodjAyIEFNRCAgICBBbWRUYWJsZSAwMDAwMDAwMiBNU0ZU
IDA0MDAwMDAwKQ0KWyAgICAwLjE4NDk1N10gQUNQSTogTUNGRyAweDAwMDAwMDAwQ0MxODEwMDAg
MDAwMDNDICh2MDEgQUxBU0tBIEEgTSBJICAgIDAxMDcyMDA5IE1TRlQgMDAwMTAwMTMpDQpbICAg
IDAuMTkzNDUwXSBBQ1BJOiBTU0RUIDB4MDAwMDAwMDBDQzE3RjAwMCAwMDAyMjggKHYwMSBBTUQg
ICAgU1REMyAgICAgMDAwMDAwMDEgSU5UTCAyMDEyMDkxMykNClsgICAgMC4yMDE5NDBdIEFDUEk6
IFZGQ1QgMHgwMDAwMDAwMENDMTcxMDAwIDAwRDY4NCAodjAxIEFMQVNLQSBBIE0gSSAgICAwMDAw
MDAwMSBBTUQgIDMxNTA0RjQ3KQ0KWyAgICAwLjIxMDQzNF0gQUNQSTogU1NEVCAweDAwMDAwMDAw
Q0MxNkIwMDAgMDAzOUY0ICh2MDEgQU1EICAgIEFtZFRhYmxlIDAwMDAwMDAxIEFNRCAgMDAwMDAw
MDEpDQpbICAgIDAuMjE4OTMyXSBBQ1BJOiBTU0RUIDB4MDAwMDAwMDBDQzE2ODAwMCAwMDAxMzkg
KHYwMSBBTUQgICAgQW1kVGFibGUgMDAwMDAwMDEgSU5UTCAyMDEyMDkxMykNClsgICAgMC4yMjc0
MjVdIEFDUEk6IFNTRFQgMHgwMDAwMDAwMENDMTY3MDAwIDAwMDIyNyAodjAxIEFNRCAgICBBbWRU
YWJsZSAwMDAwMDAwMSBJTlRMIDIwMTIwOTEzKQ0KWyAgICAwLjIzNTkxN10gQUNQSTogU1NEVCAw
eDAwMDAwMDAwQ0MxNjYwMDAgMDAwRDM3ICh2MDEgQU1EICAgIEFtZFRhYmxlIDAwMDAwMDAxIElO
VEwgMjAxMjA5MTMpDQpbICAgIDAuMjQ0NDA5XSBBQ1BJOiBTU0RUIDB4MDAwMDAwMDBDQzE2NDAw
MCAwMDEwQTUgKHYwMSBBTUQgICAgQW1kVGFibGUgMDAwMDAwMDEgSU5UTCAyMDEyMDkxMykNClsg
ICAgMC4yNTI5MDNdIEFDUEk6IFNTRFQgMHgwMDAwMDAwMENDMTYwMDAwIDAwMzBDOCAodjAxIEFN
RCAgICBBbWRUYWJsZSAwMDAwMDAwMSBJTlRMIDIwMTIwOTEzKQ0KWyAgICAwLjI2MTM5NV0gQUNQ
STogU1NEVCAweDAwMDAwMDAwQ0MxNUQwMDAgMDAwMDdEICh2MDEgQU1EICAgIEFtZFRhYmxlIDAw
MDAwMDAxIElOVEwgMjAxMjA5MTMpDQpbICAgIDAuMjY5ODg3XSBBQ1BJOiBTU0RUIDB4MDAwMDAw
MDBDQzE1QzAwMCAwMDA1MTcgKHYwMSBBTUQgICAgQW1kVGFibGUgMDAwMDAwMDEgSU5UTCAyMDEy
MDkxMykNClsgICAgMC4yNzgzODZdIEFDUEk6IEZQRFQgMHgwMDAwMDAwMENDMTVCMDAwIDAwMDA0
NCAodjAxIEFMQVNLQSBBIE0gSSAgICAwMTA3MjAwOSBBTUkgIDAxMDAwMDEzKQ0KWyAgICAwLjI4
Njg3MV0gQUNQSTogUmVzZXJ2aW5nIEFQSUMgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjZGZmZmY2
OC0weGNkZmZmZmZmXQ0KWyAgICAwLjI5Mzg5Ml0gQUNQSTogUmVzZXJ2aW5nIEZBQ1AgdGFibGUg
bWVtb3J5IGF0IFttZW0gMHhjYzE4YzAwMC0weGNjMThjMTEzXQ0KWyAgICAwLjMwMDkxMl0gQUNQ
STogUmVzZXJ2aW5nIERTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE4MzAwMC0weGNjMThi
NzZjXQ0KWyAgICAwLjMwNzkzNl0gQUNQSTogUmVzZXJ2aW5nIEZBQ1MgdGFibGUgbWVtb3J5IGF0
IFttZW0gMHhjYzZjMDAwMC0weGNjNmMwMDNmXQ0KWyAgICAwLjMxNDk1Ml0gQUNQSTogUmVzZXJ2
aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE4ZTAwMC0weGNjMTk1MjNiXQ0KWyAg
ICAwLjMyMTk3NV0gQUNQSTogUmVzZXJ2aW5nIE1DRkcgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhj
YzE4MTAwMC0weGNjMTgxMDNiXQ0KWyAgICAwLjMyODk5MV0gQUNQSTogUmVzZXJ2aW5nIFNTRFQg
dGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE3ZjAwMC0weGNjMTdmMjI3XQ0KWyAgICAwLjMzNjAx
NF0gQUNQSTogUmVzZXJ2aW5nIFZGQ1QgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE3MTAwMC0w
eGNjMTdlNjgzXQ0KWyAgICAwLjM0MzAzNl0gQUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVt
b3J5IGF0IFttZW0gMHhjYzE2YjAwMC0weGNjMTZlOWYzXQ0KWyAgICAwLjM1MDA1M10gQUNQSTog
UmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE2ODAwMC0weGNjMTY4MTM4
XQ0KWyAgICAwLjM1NzA3MV0gQUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFtt
ZW0gMHhjYzE2NzAwMC0weGNjMTY3MjI2XQ0KWyAgICAwLjM2NDA5MV0gQUNQSTogUmVzZXJ2aW5n
IFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE2NjAwMC0weGNjMTY2ZDM2XQ0KWyAgICAw
LjM3MTExN10gQUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE2
NDAwMC0weGNjMTY1MGE0XQ0KWyAgICAwLjM3ODEzNV0gQUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFi
bGUgbWVtb3J5IGF0IFttZW0gMHhjYzE2MDAwMC0weGNjMTYzMGM3XQ0KWyAgICAwLjM4NTE1NF0g
QUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE1ZDAwMC0weGNj
MTVkMDdjXQ0KWyAgICAwLjM5MjE3NV0gQUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5
IGF0IFttZW0gMHhjYzE1YzAwMC0weGNjMTVjNTE2XQ0KWyAgICAwLjM5OTE5N10gQUNQSTogUmVz
ZXJ2aW5nIEZQRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE1YjAwMC0weGNjMTViMDQzXQ0K
WyAgICAwLjQwNjMyM10gTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kDQpbICAgIDAuNDEwMDI1
XSBGYWtpbmcgYSBub2RlIGF0IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDgwZjMz
ZmZmZl0NClsgICAgMC40MTY3MDRdIE5PREVfREFUQSgwKSBhbGxvY2F0ZWQgW21lbSAweDEzNGE5
ZjAwMC0weDEzNGFhMmZmZl0NClsgICAgMC40MjI3MTVdIFpvbmUgcmFuZ2VzOg0KWyAgICAwLjQy
NTE5NV0gICBETUEgICAgICBbbWVtIDB4MDAwMDAwMDAwMDAwMTAwMC0weDAwMDAwMDAwMDBmZmZm
ZmZdDQpbICAgIDAuNDMxMzQ5XSAgIERNQTMyICAgIFttZW0gMHgwMDAwMDAwMDAxMDAwMDAwLTB4
MDAwMDAwMDBmZmZmZmZmZl0NClsgICAgMC40Mzc1MDFdICAgTm9ybWFsICAgW21lbSAweDAwMDAw
MDAxMDAwMDAwMDAtMHgwMDAwMDAwODBmMzNmZmZmXQ0KWyAgICAwLjQ0MzY1N10gTW92YWJsZSB6
b25lIHN0YXJ0IGZvciBlYWNoIG5vZGUNClsgICAgMC40NDc5MDRdIEVhcmx5IG1lbW9yeSBub2Rl
IHJhbmdlcw0KWyAgICAwLjQ1MTQ1Nl0gICBub2RlICAgMDogW21lbSAweDAwMDAwMDAwMDAwMDEw
MDAtMHgwMDAwMDAwMDAwMDlmZmZmXQ0KWyAgICAwLjQ1NzY5NF0gICBub2RlICAgMDogW21lbSAw
eDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDA5YmZlZmZmXQ0KWyAgICAwLjQ2MzkzMV0gICBu
b2RlICAgMDogW21lbSAweDAwMDAwMDAwMGEwMDAwMDAtMHgwMDAwMDAwMDBhMWZmZmZmXQ0KWyAg
ICAwLjQ3MDE3Nl0gICBub2RlICAgMDogW21lbSAweDAwMDAwMDAwMGEyMGQwMDAtMHgwMDAwMDAw
MGNhYmM4ZmZmXQ0KWyAgICAwLjQ3NjQxNV0gICBub2RlICAgMDogW21lbSAweDAwMDAwMDAwY2Qx
ZmYwMDAtMHgwMDAwMDAwMGNkZmZlZmZmXQ0KWyAgICAwLjQ4MjY1N10gICBub2RlICAgMDogW21l
bSAweDAwMDAwMDAxMDAwMDAwMDAtMHgwMDAwMDAwODBmMzNmZmZmXQ0KWyAgICAwLjQ4ODg5OV0g
SW5pdG1lbSBzZXR1cCBub2RlIDAgW21lbSAweDAwMDAwMDAwMDAwMDEwMDAtMHgwMDAwMDAwODBm
MzNmZmZmXQ0KWyAgICAwLjQ5NTkyMV0gT24gbm9kZSAwLCB6b25lIERNQTogMSBwYWdlcyBpbiB1
bmF2YWlsYWJsZSByYW5nZXMNClsgICAgMC41MDE3MzVdIE9uIG5vZGUgMCwgem9uZSBETUE6IDk2
IHBhZ2VzIGluIHVuYXZhaWxhYmxlIHJhbmdlcw0KWyAgICAwLjUwNzc0Ml0gT24gbm9kZSAwLCB6
b25lIERNQTMyOiAxMDI1IHBhZ2VzIGluIHVuYXZhaWxhYmxlIHJhbmdlcw0KWyAgICAwLjUxODQ1
MF0gT24gbm9kZSAwLCB6b25lIERNQTMyOiAxMyBwYWdlcyBpbiB1bmF2YWlsYWJsZSByYW5nZXMN
ClsgICAgMC41MjQ0ODZdIE9uIG5vZGUgMCwgem9uZSBETUEzMjogOTc4MiBwYWdlcyBpbiB1bmF2
YWlsYWJsZSByYW5nZXMNClsgICAgMC41NzQ0MzldIE9uIG5vZGUgMCwgem9uZSBOb3JtYWw6IDgx
OTMgcGFnZXMgaW4gdW5hdmFpbGFibGUgcmFuZ2VzDQpbICAgIDAuNTgwNjU3XSBPbiBub2RlIDAs
IHpvbmUgTm9ybWFsOiAzMjY0IHBhZ2VzIGluIHVuYXZhaWxhYmxlIHJhbmdlcw0KWyAgICAwLjU4
NzM4NF0gQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg4MDgNClsgICAgMC41OTEyNzZdIElPQVBJ
Q1swXTogYXBpY19pZCAxNywgdmVyc2lvbiAxNywgYWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0y
Mw0KWyAgICAwLjU5ODE4Nl0gSU9BUElDWzFdOiBhcGljX2lkIDE4LCB2ZXJzaW9uIDE3LCBhZGRy
ZXNzIDB4ZmVjMDEwMDAsIEdTSSAyNC01NQ0KWyAgICAwLjYwNTE3OF0gQUNQSTogSU5UX1NSQ19P
VlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNClsgICAgMC42MTE1MDNd
IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZl
bCkNClsgICAgMC42MTgwMDddIEFDUEk6IFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmln
dXJhdGlvbiBpbmZvcm1hdGlvbg0KWyAgICAwLjYyNDQxOV0gQ1BVIHRvcG86IE1heC4gbG9naWNh
bCBwYWNrYWdlczogICAxDQpbICAgIDAuNjI5MDA5XSBDUFUgdG9wbzogTWF4LiBsb2dpY2FsIGRp
ZXM6ICAgICAgIDENClsgICAgMC42MzM2MDJdIENQVSB0b3BvOiBNYXguIGRpZXMgcGVyIHBhY2th
Z2U6ICAgMQ0KWyAgICAwLjYzODIwMl0gQ1BVIHRvcG86IE1heC4gdGhyZWFkcyBwZXIgY29yZTog
ICAxDQpbICAgIDAuNjQyNzg3XSBDUFUgdG9wbzogTnVtLiBjb3JlcyBwZXIgcGFja2FnZTogICAg
IDQNClsgICAgMC42NDc2NDRdIENQVSB0b3BvOiBOdW0uIHRocmVhZHMgcGVyIHBhY2thZ2U6ICAg
NA0KWyAgICAwLjY1MjQ5Nl0gQ1BVIHRvcG86IEFsbG93aW5nIDQgcHJlc2VudCBDUFVzIHBsdXMg
MCBob3RwbHVnIENQVXMNClsgICAgMC42NTg1NzldIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJl
ZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4MDAwMDAwMDAtMHgwMDAwMGZmZl0NClsgICAgMC42NjYx
MDVdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4MDAw
YTAwMDAtMHgwMDBmZmZmZl0NClsgICAgMC42NzM2NDVdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0
ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4MDliZmYwMDAtMHgwOWZmZmZmZl0NClsgICAgMC42
ODExODVdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4
MGEyMDAwMDAtMHgwYTIwY2ZmZl0NClsgICAgMC42ODg3MjBdIFBNOiBoaWJlcm5hdGlvbjogUmVn
aXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4Y2FiYzkwMDAtMHhjYzE0Y2ZmZl0NClsgICAg
MC42OTYyNjFdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVt
IDB4Y2MxNGQwMDAtMHhjYzE5NWZmZl0NClsgICAgMC43MDM4MDRdIFBNOiBoaWJlcm5hdGlvbjog
UmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4Y2MxOTYwMDAtMHhjYzM4OGZmZl0NClsg
ICAgMC43MTEzNDBdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBb
bWVtIDB4Y2MzODkwMDAtMHhjYzM4OWZmZl0NClsgICAgMC43MTg4ODBdIFBNOiBoaWJlcm5hdGlv
bjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4Y2MzOGEwMDAtMHhjYzcwOWZmZl0N
ClsgICAgMC43MjY0MjBdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5
OiBbbWVtIDB4Y2M3MGEwMDAtMHhjZDFmZWZmZl0NClsgICAgMC43MzM5NjBdIFBNOiBoaWJlcm5h
dGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4Y2RmZmYwMDAtMHhjZGZmZmZm
Zl0NClsgICAgMC43NDE1MDFdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVt
b3J5OiBbbWVtIDB4Y2RmZmYwMDAtMHhjZGZmZmZmZl0NClsgICAgMC43NDkwNDNdIFBNOiBoaWJl
cm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4Y2UwMDAwMDAtMHhjZmZm
ZmZmZl0NClsgICAgMC43NTY1ODBdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUg
bWVtb3J5OiBbbWVtIDB4ZDAwMDAwMDAtMHhlZmZmZmZmZl0NClsgICAgMC43NjQxMjNdIFBNOiBo
aWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZjAwMDAwMDAtMHhm
N2ZmZmZmZl0NClsgICAgMC43NzE5NzJdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3Nh
dmUgbWVtb3J5OiBbbWVtIDB4ZjgwMDAwMDAtMHhmY2ZmZmZmZl0NClsgICAgMC43NzkzNjNdIFBN
OiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZmQwMDAwMDAt
MHhmZmZmZmZmZl0NClsgICAgMC43ODY5MDddIFttZW0gMHhkMDAwMDAwMC0weGVmZmZmZmZmXSBh
dmFpbGFibGUgZm9yIFBDSSBkZXZpY2VzDQpbICAgIDAuNzkyOTc0XSBCb290aW5nIGtlcm5lbCBv
biBYZW4gUFZIDQpbICAgIDAuNzk2NjEyXSBYZW4gdmVyc2lvbjogNC4yMS11bnN0YWJsZQ0KWyAg
ICAwLjgwMDMzNl0gY2xvY2tzb3VyY2U6IHJlZmluZWQtamlmZmllczogbWFzazogMHhmZmZmZmZm
ZiBtYXhfY3ljbGVzOiAweGZmZmZmZmZmLCBtYXhfaWRsZV9uczogMTkxMDk2OTk0MDM5MTQxOSBu
cw0KWyAgICAwLjgxNTU1NV0gc2V0dXBfcGVyY3B1OiBOUl9DUFVTOjY0IG5yX2NwdW1hc2tfYml0
czo0IG5yX2NwdV9pZHM6NCBucl9ub2RlX2lkczoxDQpbICAgIDAuODIzMDkxXSBwZXJjcHU6IEVt
YmVkZGVkIDU3IHBhZ2VzL2NwdSBzMTk2MzEyIHI4MTkyIGQyODk2OCB1NTI0Mjg4DQpbICAgIDAu
ODI5NDQ2XSBwY3B1LWFsbG9jOiBzMTk2MzEyIHI4MTkyIGQyODk2OCB1NTI0Mjg4IGFsbG9jPTEq
MjA5NzE1Mg0KWyAgICAwLjgzNTc3MF0gcGNwdS1hbGxvYzogWzBdIDAgMSAyIDMNClsgICAgMC44
MzkzNDldIEtlcm5lbCBjb21tYW5kIGxpbmU6IGNvbnNvbGU9aHZjMCByb290PS9kZXYvcmFtMCBl
YXJseXByaW50az14ZW4gZGVidWcgcmRpbml0PS9iaW4vc2gNClsgICAgMC44NDgyMTZdIHJhbmRv
bTogY3JuZyBpbml0IGRvbmUNClsgICAgMC44NTE4NzNdIERlbnRyeSBjYWNoZSBoYXNoIHRhYmxl
IGVudHJpZXM6IDUyNDI4OCAob3JkZXI6IDEwLCA0MTk0MzA0IGJ5dGVzLCBsaW5lYXIpDQpbICAg
IDAuODU5ODEyXSBJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDI2MjE0NCAob3JkZXI6
IDksIDIwOTcxNTIgYnl0ZXMsIGxpbmVhcikNClsgICAgMC44Njc0MDZdIEZhbGxiYWNrIG9yZGVy
IGZvciBOb2RlIDA6IDANClsgICAgMC44Njc0MTBdIEJ1aWx0IDEgem9uZWxpc3RzLCBtb2JpbGl0
eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiA4MjM1MTYyDQpbICAgIDAuODc4MjE0XSBQb2xp
Y3kgem9uZTogTm9ybWFsDQpbICAgIDAuODgxMzI5XSBtZW0gYXV0by1pbml0OiBzdGFjazphbGwo
emVybyksIGhlYXAgYWxsb2M6b2ZmLCBoZWFwIGZyZWU6b2ZmDQpbICAgIDAuODg4MDkzXSBzb2Z0
d2FyZSBJTyBUTEI6IGFyZWEgbnVtIDQuDQpbICAgIDAuOTc4OTEyXSBTTFVCOiBIV2FsaWduPTY0
LCBPcmRlcj0wLTMsIE1pbk9iamVjdHM9MCwgQ1BVcz00LCBOb2Rlcz0xDQpQb2tpbmcgS0FTTFIg
dXNpbmcgUkRSQU5EIFJEVFNDLi4uDQpbICAgIDAuOTg5NDUxXSBEeW5hbWljIFByZWVtcHQ6IHZv
bHVudGFyeQ0KWyAgICAwLjk5MzA1Nl0gcmN1OiBQcmVlbXB0aWJsZSBoaWVyYXJjaGljYWwgUkNV
IGltcGxlbWVudGF0aW9uLg0KWyAgICAwLjk5ODc1Ml0gcmN1OiAJUkNVIGV2ZW50IHRyYWNpbmcg
aXMgZW5hYmxlZC4NClsgICAgMS4wMDMyNThdIHJjdTogCVJDVSByZXN0cmljdGluZyBDUFVzIGZy
b20gTlJfQ1BVUz02NCB0byBucl9jcHVfaWRzPTQuDQpbICAgIDEuMDA5ODQ2XSAJVHJhbXBvbGlu
ZSB2YXJpYW50IG9mIFRhc2tzIFJDVSBlbmFibGVkLg0KWyAgICAxLjAxNDg3Ml0gcmN1OiBSQ1Ug
Y2FsY3VsYXRlZCB2YWx1ZSBvZiBzY2hlZHVsZXItZW5saXN0bWVudCBkZWxheSBpcyAxMDAgamlm
Zmllcy4NClsgICAgMS4wMjI0OTldIHJjdTogQWRqdXN0aW5nIGdlb21ldHJ5IGZvciByY3VfZmFu
b3V0X2xlYWY9MTYsIG5yX2NwdV9pZHM9NA0KWyAgICAxLjAyOTE3NV0gUkNVIFRhc2tzOiBTZXR0
aW5nIHNoaWZ0IHRvIDIgYW5kIGxpbSB0byAxIHJjdV90YXNrX2NiX2FkanVzdD0xLg0KWyAgICAx
LjAzNzM1NV0gVXNpbmcgTlVMTCBsZWdhY3kgUElDDQpbICAgIDEuMDQwNTAwXSBOUl9JUlFTOiA0
MzUyLCBucl9pcnFzOiAxMDAwLCBwcmVhbGxvY2F0ZWQgaXJxczogMA0KWyAgICAxLjA0NjMzMl0g
eGVuOmV2ZW50czogVXNpbmcgRklGTy1iYXNlZCBBQkkNCihYRU4pIFsgICAgOS42NjU2ODNdIGQw
djA6IHVwY2FsbCB2ZWN0b3IgZjMNClsgICAgMS4wNTQ0NThdIHhlbjpldmVudHM6IFhlbiBIVk0g
Y2FsbGJhY2sgdmVjdG9yIGZvciBldmVudCBkZWxpdmVyeSBpcyBlbmFibGVkDQpbICAgIDEuMDYx
NTg5XSByY3U6IHNyY3VfaW5pdDogU2V0dGluZyBzcmN1X3N0cnVjdCBzaXplcyBiYXNlZCBvbiBj
b250ZW50aW9uLg0KWyAgICAxLjA2ODQ0Nl0gQ29uc29sZTogY29sb3VyIGR1bW15IGRldmljZSA4
MHgyNQ0KWyAgICAxLjA3MjgyN10gcHJpbnRrOiBsZWdhY3kgY29uc29sZSBbdHR5MF0gZW5hYmxl
ZA0KWyAgICAxLjA3Nzc1NF0gcHJpbnRrOiBsZWdhY3kgY29uc29sZSBbaHZjMF0gZW5hYmxlZA0K
DQpbICAgIDEuMDc3NzU0XSBwcmludGs6IGxlZ2FjeSBjb25zb2xlIFtodmMwXSBlbmFibGVkDQpb
ICAgIDEuMDg3MDU2XSBwcmludGs6IGxlZ2FjeSBib290Y29uc29sZSBbeGVuYm9vdDBdIGRpc2Fi
bGVkDQoNClsgICAgMS4wODcwNTZdIHByaW50azogbGVnYWN5IGJvb3Rjb25zb2xlIFt4ZW5ib290
MF0gZGlzYWJsZWQNClsgICAgMS4wOTgwNjddIEFDUEk6IENvcmUgcmV2aXNpb24gMjAyNDAzMjIN
Cg0KWyAgICAxLjEyMDYxNl0gRmFpbGVkIHRvIHJlZ2lzdGVyIGxlZ2FjeSB0aW1lciBpbnRlcnJ1
cHQNCg0KWyAgICAxLjEyNTU4Ml0gQVBJQzogU3dpdGNoIHRvIHN5bW1ldHJpYyBJL08gbW9kZSBz
ZXR1cA0KDQpbICAgIDEuMTMxMzUwXSB4MmFwaWMgZW5hYmxlZA0KDQpbICAgIDEuMTM0ODQ5XSBB
UElDOiBTd2l0Y2hlZCBBUElDIHJvdXRpbmcgdG86IHBoeXNpY2FsIHgyYXBpYw0KDQpbICAgIDEu
MTQwNDI2XSBjbG9ja3NvdXJjZTogdHNjLWVhcmx5OiBtYXNrOiAweGZmZmZmZmZmZmZmZmZmZmYg
bWF4X2N5Y2xlczogMHgyOWI5Mjg5ODYwMiwgbWF4X2lkbGVfbnM6IDQ0MDc5NTM0OTkzMCBucw0K
DQpbICAgIDEuMTUwOTE0XSBDYWxpYnJhdGluZyBkZWxheSBsb29wIChza2lwcGVkKSwgdmFsdWUg
Y2FsY3VsYXRlZCB1c2luZyB0aW1lciBmcmVxdWVuY3kuLiA1Nzg5LjEwIEJvZ29NSVBTIChscGo9
Mjg5NDU1MikNCg0KWyAgICAxLjE1MTkxMl0geDg2L2NwdTogVXNlciBNb2RlIEluc3RydWN0aW9u
IFByZXZlbnRpb24gKFVNSVApIGFjdGl2YXRlZA0KDQpbICAgIDEuMTUxOTEyXSBMYXN0IGxldmVs
IGlUTEIgZW50cmllczogNEtCIDEwMjQsIDJNQiAxMDI0LCA0TUIgNTEyDQoNClsgICAgMS4xNTE5
MTJdIExhc3QgbGV2ZWwgZFRMQiBlbnRyaWVzOiA0S0IgMjA0OCwgMk1CIDIwNDgsIDRNQiAxMDI0
LCAxR0IgMA0KDQpbICAgIDEuMTUxOTEyXSBTcGVjdHJlIFYxIDogTWl0aWdhdGlvbjogdXNlcmNv
cHkvc3dhcGdzIGJhcnJpZXJzIGFuZCBfX3VzZXIgcG9pbnRlciBzYW5pdGl6YXRpb24NCg0KWyAg
ICAxLjE1MTkxMl0gU3BlY3RyZSBWMiA6IE1pdGlnYXRpb246IFJldHBvbGluZXMNCg0KWyAgICAx
LjE1MTkxMl0gU3BlY3RyZSBWMiA6IFNwZWN0cmUgdjIgLyBTcGVjdHJlUlNCIG1pdGlnYXRpb246
IEZpbGxpbmcgUlNCIG9uIGNvbnRleHQgc3dpdGNoDQoNClsgICAgMS4xNTE5MTJdIFNwZWN0cmUg
VjIgOiBTcGVjdHJlIHYyIC8gU3BlY3RyZVJTQiA6IEZpbGxpbmcgUlNCIG9uIFZNRVhJVA0KDQpb
ICAgIDEuMTUxOTEyXSBTcGVjdHJlIFYyIDogRW5hYmxpbmcgU3BlY3VsYXRpb24gQmFycmllciBm
b3IgZmlybXdhcmUgY2FsbHMNCg0KWyAgICAxLjE1MTkxMl0gUkVUQmxlZWQ6IE1pdGlnYXRpb246
IHVudHJhaW5lZCByZXR1cm4gdGh1bmsNCg0KWyAgICAxLjE1MTkxMl0gU3BlY3RyZSBWMiA6IG1p
dGlnYXRpb246IEVuYWJsaW5nIGNvbmRpdGlvbmFsIEluZGlyZWN0IEJyYW5jaCBQcmVkaWN0aW9u
IEJhcnJpZXINCg0KWyAgICAxLjE1MTkxMl0gU3BlY3VsYXRpdmUgU3RvcmUgQnlwYXNzOiBNaXRp
Z2F0aW9uOiBTcGVjdWxhdGl2ZSBTdG9yZSBCeXBhc3MgZGlzYWJsZWQgdmlhIHByY3RsDQoNClsg
ICAgMS4xNTE5MTJdIHg4Ni9mcHU6IFN1cHBvcnRpbmcgWFNBVkUgZmVhdHVyZSAweDAwMTogJ3g4
NyBmbG9hdGluZyBwb2ludCByZWdpc3RlcnMnDQoNClsgICAgMS4xNTE5MTJdIHg4Ni9mcHU6IFN1
cHBvcnRpbmcgWFNBVkUgZmVhdHVyZSAweDAwMjogJ1NTRSByZWdpc3RlcnMnDQoNClsgICAgMS4x
NTE5MTJdIHg4Ni9mcHU6IFN1cHBvcnRpbmcgWFNBVkUgZmVhdHVyZSAweDAwNDogJ0FWWCByZWdp
c3RlcnMnDQoNClsgICAgMS4xNTE5MTJdIHg4Ni9mcHU6IHhzdGF0ZV9vZmZzZXRbMl06ICA1NzYs
IHhzdGF0ZV9zaXplc1syXTogIDI1Ng0KDQpbICAgIDEuMTUxOTEyXSB4ODYvZnB1OiBFbmFibGVk
IHhzdGF0ZSBmZWF0dXJlcyAweDcsIGNvbnRleHQgc2l6ZSBpcyA4MzIgYnl0ZXMsIHVzaW5nICdj
b21wYWN0ZWQnIGZvcm1hdC4NCg0KWyAgICAxLjE1MTkxMl0gRnJlZWluZyBTTVAgYWx0ZXJuYXRp
dmVzIG1lbW9yeTogNTJLDQoNClsgICAgMS4xNTE5MTJdIHBpZF9tYXg6IGRlZmF1bHQ6IDMyNzY4
IG1pbmltdW06IDMwMQ0KDQpbICAgIDEuMTUxOTEyXSBMU006IGluaXRpYWxpemluZyBsc209Y2Fw
YWJpbGl0eSxzZWxpbnV4DQoNClsgICAgMS4xNTE5MTJdIFNFTGludXg6ICBJbml0aWFsaXppbmcu
DQoNClsgICAgMS4xNTE5MTJdIE1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogODE5MiAo
b3JkZXI6IDQsIDY1NTM2IGJ5dGVzLCBsaW5lYXIpDQoNClsgICAgMS4xNTE5MTJdIE1vdW50cG9p
bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA4MTkyIChvcmRlcjogNCwgNjU1MzYgYnl0ZXMs
IGxpbmVhcikNCg0KWyAgICAxLjE1MTkxMl0gY2xvY2tzb3VyY2U6IHhlbjogbWFzazogMHhmZmZm
ZmZmZmZmZmZmZmZmIG1heF9jeWNsZXM6IDB4MWNkNDJlNGRmZmIsIG1heF9pZGxlX25zOiA4ODE1
OTA1OTE0ODMgbnMNCg0KWyAgICAxLjE1MTkxMl0gWGVuOiB1c2luZyB2Y3B1b3AgdGltZXIgaW50
ZXJmYWNlDQoNClsgICAgMS4xNTE5MTJdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMA0K
DQpbICAgIDEuMTUxOTEyXSBzbXBib290OiBDUFUwOiBBTUQgUnl6ZW4gRW1iZWRkZWQgVjI3NDgg
d2l0aCBSYWRlb24gR3JhcGhpY3MgKGZhbWlseTogMHgxNywgbW9kZWw6IDB4NjAsIHN0ZXBwaW5n
OiAweDEpDQoNClsgICAgMS4xNTIwMzBdIFBlcmZvcm1hbmNlIEV2ZW50czogUE1VIG5vdCBhdmFp
bGFibGUgZHVlIHRvIHZpcnR1YWxpemF0aW9uLCB1c2luZyBzb2Z0d2FyZSBldmVudHMgb25seS4N
Cg0KWyAgICAxLjE1MjkzMl0gc2lnbmFsOiBtYXggc2lnZnJhbWUgc2l6ZTogMTc3Ng0KDQpbICAg
IDEuMTUzOTM1XSByY3U6IEhpZXJhcmNoaWNhbCBTUkNVIGltcGxlbWVudGF0aW9uLg0KDQpbICAg
IDEuMTU0OTE3XSByY3U6IAlNYXggcGhhc2Ugbm8tZGVsYXkgaW5zdGFuY2VzIGlzIDQwMC4NCg0K
WyAgICAxLjE1NTk0M10gVGltZXIgbWlncmF0aW9uOiAxIGhpZXJhcmNoeSBsZXZlbHM7IDggY2hp
bGRyZW4gcGVyIGdyb3VwOyAxIGNyb3Nzbm9kZSBsZXZlbA0KDQpbICAgIDEuMTU5Nzg4XSBzbXA6
IEJyaW5naW5nIHVwIHNlY29uZGFyeSBDUFVzIC4uLg0KDQpbICAgIDEuMTU5OTcwXSBpbnN0YWxs
aW5nIFhlbiB0aW1lciBmb3IgQ1BVIDENCg0KWyAgICAxLjE2MDk3OV0gc21wYm9vdDogeDg2OiBC
b290aW5nIFNNUCBjb25maWd1cmF0aW9uOg0KDQooWEVOKSBbICAgMTAuMDE4MjI3XSBjb21tb24v
c2NoZWQvbnVsbC5jOjM1NzogMSA8LS0gZDB2MQ0KWyAgICAxLjE2MTkxOF0gLi4uLiBub2RlICAj
MCwgQ1BVczogICAgICAjMQ0KDQpbICAgIDEuMTYzMzQyXSBpbnN0YWxsaW5nIFhlbiB0aW1lciBm
b3IgQ1BVIDINCg0KKFhFTikgWyAgIDEwLjAzMTc3NV0gY29tbW9uL3NjaGVkL251bGwuYzozNTc6
IDIgPC0tIGQwdjINClsgICAgMS4xNjQ5OTddICAjMg0KDQpbICAgIDEuMTY2MDM4XSBpbnN0YWxs
aW5nIFhlbiB0aW1lciBmb3IgQ1BVIDMNCg0KKFhFTikgWyAgIDEwLjA0MjgwNl0gY29tbW9uL3Nj
aGVkL251bGwuYzozNTc6IDMgPC0tIGQwdjMNClsgICAgMS4xNjgwMjRdICAjMw0KDQpbICAgIDEu
MTcxOTgyXSBzbXA6IEJyb3VnaHQgdXAgMSBub2RlLCA0IENQVXMNCg0KWyAgICAxLjE3MzkxOV0g
c21wYm9vdDogVG90YWwgb2YgNCBwcm9jZXNzb3JzIGFjdGl2YXRlZCAoMjMxNTYuNDEgQm9nb01J
UFMpDQoNClsgICAgMS4xNzU5NjNdIE1lbW9yeTogMzM0OTQ0MEsvMzI5NDA2NDhLIGF2YWlsYWJs
ZSAoMjA0ODBLIGtlcm5lbCBjb2RlLCAyOTI2SyByd2RhdGEsIDcyNzZLIHJvZGF0YSwgMjk4MEsg
aW5pdCwgMjUyNEsgYnNzLCAyOTU4NzI1MksgcmVzZXJ2ZWQsIDBLIGNtYS1yZXNlcnZlZCkNCg0K
WyAgICAxLjE3NzY3MV0gZGV2dG1wZnM6IGluaXRpYWxpemVkDQoNClsgICAgMS4xNzc5NDBdIHg4
Ni9tbTogTWVtb3J5IGJsb2NrIHNpemU6IDEyOE1CDQoNClsgICAgMS4xODA5MjBdIEFDUEk6IFBN
OiBSZWdpc3RlcmluZyBBQ1BJIE5WUyByZWdpb24gW21lbSAweDBhMjAwMDAwLTB4MGEyMGNmZmZd
ICg1MzI0OCBieXRlcykNCg0KWyAgICAxLjE4MTkxOV0gQUNQSTogUE06IFJlZ2lzdGVyaW5nIEFD
UEkgTlZTIHJlZ2lvbiBbbWVtIDB4Y2MxOTYwMDAtMHhjYzM4OGZmZl0gKDIwNDM5MDQgYnl0ZXMp
DQoNClsgICAgMS4xODI5MzZdIEFDUEk6IFBNOiBSZWdpc3RlcmluZyBBQ1BJIE5WUyByZWdpb24g
W21lbSAweGNjMzhhMDAwLTB4Y2M3MDlmZmZdICgzNjcwMDE2IGJ5dGVzKQ0KDQpbICAgIDEuMTgz
OTcxXSBjbG9ja3NvdXJjZTogamlmZmllczogbWFzazogMHhmZmZmZmZmZiBtYXhfY3ljbGVzOiAw
eGZmZmZmZmZmLCBtYXhfaWRsZV9uczogMTkxMTI2MDQ0NjI3NTAwMCBucw0KDQpbICAgIDEuMTg0
OTIxXSBmdXRleCBoYXNoIHRhYmxlIGVudHJpZXM6IDEwMjQgKG9yZGVyOiA0LCA2NTUzNiBieXRl
cywgbGluZWFyKQ0KDQpbICAgIDEuMTg1OTg1XSBQTTogUlRDIHRpbWU6IDAxOjE3OjQwLCBkYXRl
OiAyMDI1LTA1LTEzDQoNClsgICAgMS4xODcxMTNdIE5FVDogUmVnaXN0ZXJlZCBQRl9ORVRMSU5L
L1BGX1JPVVRFIHByb3RvY29sIGZhbWlseQ0KDQpbICAgIDEuMTg3OTMyXSB4ZW46Z3JhbnRfdGFi
bGU6IEdyYW50IHRhYmxlcyB1c2luZyB2ZXJzaW9uIDEgbGF5b3V0DQoNClsgICAgMS4xODg5MzVd
IEdyYW50IHRhYmxlIGluaXRpYWxpemVkDQoNClsgICAgMS4xODk5OTBdIGF1ZGl0OiBpbml0aWFs
aXppbmcgbmV0bGluayBzdWJzeXMgKGRpc2FibGVkKQ0KDQpbICAgIDEuMTkwOTMxXSBhdWRpdDog
dHlwZT0yMDAwIGF1ZGl0KDE3NDcwOTkwNjAuNjg0OjEpOiBzdGF0ZT1pbml0aWFsaXplZCBhdWRp
dF9lbmFibGVkPTAgcmVzPTENCg0KWyAgICAxLjE5MDk2N10gdGhlcm1hbF9zeXM6IFJlZ2lzdGVy
ZWQgdGhlcm1hbCBnb3Zlcm5vciAnc3RlcF93aXNlJw0KDQpbICAgIDEuMTk4OTIxXSB0aGVybWFs
X3N5czogUmVnaXN0ZXJlZCB0aGVybWFsIGdvdmVybm9yICd1c2VyX3NwYWNlJw0KDQpbICAgIDEu
MjA0OTI3XSBjcHVpZGxlOiB1c2luZyBnb3Zlcm5vciBtZW51DQoNClsgICAgMS4yMTUxMjddIFBD
STogRUNBTSBbbWVtIDB4ZjAwMDAwMDAtMHhmN2ZmZmZmZl0gKGJhc2UgMHhmMDAwMDAwMCkgZm9y
IGRvbWFpbiAwMDAwIFtidXMgMDAtN2ZdDQoNClsgICAgMS4yMjM5MzNdIFBDSTogVXNpbmcgY29u
ZmlndXJhdGlvbiB0eXBlIDEgZm9yIGJhc2UgYWNjZXNzDQoNClsgICAgMS4yMjk5NDBdIGtwcm9i
ZXM6IGtwcm9iZSBqdW1wLW9wdGltaXphdGlvbiBpcyBlbmFibGVkLiBBbGwga3Byb2JlcyBhcmUg
b3B0aW1pemVkIGlmIHBvc3NpYmxlLg0KDQpbICAgIDEuMjM5MDM5XSBIdWdlVExCOiByZWdpc3Rl
cmVkIDEuMDAgR2lCIHBhZ2Ugc2l6ZSwgcHJlLWFsbG9jYXRlZCAwIHBhZ2VzDQoNClsgICAgMS4y
NDQ5MTldIEh1Z2VUTEI6IDE2MzgwIEtpQiB2bWVtbWFwIGNhbiBiZSBmcmVlZCBmb3IgYSAxLjAw
IEdpQiBwYWdlDQoNClsgICAgMS4yNTE5MThdIEh1Z2VUTEI6IHJlZ2lzdGVyZWQgMi4wMCBNaUIg
cGFnZSBzaXplLCBwcmUtYWxsb2NhdGVkIDAgcGFnZXMNCg0KWyAgICAxLjI1ODkxOF0gSHVnZVRM
QjogMjggS2lCIHZtZW1tYXAgY2FuIGJlIGZyZWVkIGZvciBhIDIuMDAgTWlCIHBhZ2UNCg0KWyAg
ICAxLjI2NDk3Ml0gQUNQSTogQWRkZWQgX09TSShNb2R1bGUgRGV2aWNlKQ0KDQpbICAgIDEuMjY4
OTE5XSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBEZXZpY2UpDQoNClsgICAgMS4yNzM5MThd
IEFDUEk6IEFkZGVkIF9PU0koMy4wIF9TQ1AgRXh0ZW5zaW9ucykNCg0KWyAgICAxLjI3ODkxOF0g
QUNQSTogQWRkZWQgX09TSShQcm9jZXNzb3IgQWdncmVnYXRvciBEZXZpY2UpDQoNClsgICAgMS4y
OTU0NjhdIEFDUEk6IDExIEFDUEkgQU1MIHRhYmxlcyBzdWNjZXNzZnVsbHkgYWNxdWlyZWQgYW5k
IGxvYWRlZA0KDQooWEVOKSBbICAgMTAuMjc0NTM2XSBkMDogYmluZDogbV9nc2k9OSBnX2dzaT05
DQpbICAgIDEuMzA3NDE3XSBBQ1BJOiBbRmlybXdhcmUgQnVnXTogQklPUyBfT1NJKExpbnV4KSBx
dWVyeSBpZ25vcmVkDQoNClsgICAgMS4zMTkxMTBdIEFDUEk6IEludGVycHJldGVyIGVuYWJsZWQN
Cg0KWyAgICAxLjMyMjkzMV0gQUNQSTogUE06IChzdXBwb3J0cyBTMCBTMyBTNCBTNSkNCg0KWyAg
ICAxLjMyNzkyMF0gQUNQSTogVXNpbmcgSU9BUElDIGZvciBpbnRlcnJ1cHQgcm91dGluZw0KDQpb
ICAgIDEuMzMzMTQzXSBQQ0k6IFVzaW5nIGhvc3QgYnJpZGdlIHdpbmRvd3MgZnJvbSBBQ1BJOyBp
ZiBuZWNlc3NhcnksIHVzZSAicGNpPW5vY3JzIiBhbmQgcmVwb3J0IGEgYnVnDQoNClsgICAgMS4z
NDE5MjZdIFBDSTogSWdub3JpbmcgRTgyMCByZXNlcnZhdGlvbnMgZm9yIGhvc3QgYnJpZGdlIHdp
bmRvd3MNCg0KWyAgICAxLjM0ODI4M10gQUNQSTogRW5hYmxlZCA2IEdQRXMgaW4gYmxvY2sgMDAg
dG8gMUYNCg0KWyAgICAxLjM1NDQ1Ml0gQUNQSTogXF9TQl8uUDBTMDogTmV3IHBvd2VyIHJlc291
cmNlDQoNClsgICAgMS4zNTg5MzhdIEFDUEk6IFxfU0JfLlAzUzA6IE5ldyBwb3dlciByZXNvdXJj
ZQ0KDQpbICAgIDEuMzYzOTY5XSBBQ1BJOiBcX1NCXy5QMFMxOiBOZXcgcG93ZXIgcmVzb3VyY2UN
Cg0KWyAgICAxLjM2NzkzNV0gQUNQSTogXF9TQl8uUDNTMTogTmV3IHBvd2VyIHJlc291cmNlDQoN
ClsgICAgMS4zNzkyNzFdIEFDUEk6IFxfU0JfLlBSV0w6IE5ldyBwb3dlciByZXNvdXJjZQ0KDQpb
ICAgIDEuMzgzOTM2XSBBQ1BJOiBcX1NCXy5QUldCOiBOZXcgcG93ZXIgcmVzb3VyY2UNCg0KWyAg
ICAxLjM4ODI3NV0gQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kwXSAoZG9tYWluIDAwMDAgW2J1
cyAwMC1mZl0pDQoNClsgICAgMS4zOTQ5MjJdIGFjcGkgUE5QMEEwODowMDogX09TQzogT1Mgc3Vw
cG9ydHMgW0V4dGVuZGVkQ29uZmlnIEFTUE0gQ2xvY2tQTSBTZWdtZW50cyBNU0kgSFBYLVR5cGUz
XQ0KDQpbICAgIDEuNDA0MDUyXSBhY3BpIFBOUDBBMDg6MDA6IF9PU0M6IE9TIG5vdyBjb250cm9s
cyBbUE1FIFBDSWVDYXBhYmlsaXR5IExUUl0NCg0KWyAgICAxLjQxMDkyNF0gYWNwaSBQTlAwQTA4
OjAwOiBbRmlybXdhcmUgSW5mb106IEVDQU0gW21lbSAweGYwMDAwMDAwLTB4ZjdmZmZmZmZdIGZv
ciBkb21haW4gMDAwMCBbYnVzIDAwLTdmXSBvbmx5IHBhcnRpYWxseSBjb3ZlcnMgdGhpcyBicmlk
Z2UNCg0KWyAgICAxLjQyMzIwNV0gUENJIGhvc3QgYnJpZGdlIHRvIGJ1cyAwMDAwOjAwDQoNClsg
ICAgMS40MjY5MTldIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDAw
MDAtMHgwM2FmIHdpbmRvd10NCg0KWyAgICAxLjQzMzkxOV0gcGNpX2J1cyAwMDAwOjAwOiByb290
IGJ1cyByZXNvdXJjZSBbaW8gIDB4MDNlMC0weDBjZjcgd2luZG93XQ0KDQpbICAgIDEuNDQwOTE4
XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFtpbyAgMHgwM2IwLTB4MDNkZiB3
aW5kb3ddDQoNClsgICAgMS40NDY5MTldIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3Vy
Y2UgW2lvICAweDBkMDAtMHhmZmZmIHdpbmRvd10NCg0KWyAgICAxLjQ1MzkyNV0gcGNpX2J1cyAw
MDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbbWVtIDB4MDAwYTAwMDAtMHgwMDBkZmZmZiB3aW5k
b3ddDQoNClsgICAgMS40NjE5MjBdIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2Ug
W21lbSAweGQwMDAwMDAwLTB4ZmViZmZmZmYgd2luZG93XQ0KDQpbICAgIDEuNDY4OTIzXSBwY2lf
YnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHhmZWUwMDAwMC0weGZmZmZmZmZm
IHdpbmRvd10NCg0KWyAgICAxLjQ3NjkxOV0gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNv
dXJjZSBbbWVtIDB4ODMwMDAwMDAwLTB4ZmZmZmZmZmZmZiB3aW5kb3ddDQoNClsgICAgMS40ODM5
MTldIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2J1cyAwMC1mZl0NCg0KWyAg
ICAxLjQ4ODk0N10gcGNpIDAwMDA6MDA6MDAuMDogWzEwMjI6MTYzMF0gdHlwZSAwMCBjbGFzcyAw
eDA2MDAwMCBjb252ZW50aW9uYWwgUENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAxMC40NzI0OTRd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDAuMA0KWyAgICAxLjUwMDk0NV0gcGNpIDAwMDA6MDA6
MDAuMjogWzEwMjI6MTYzMV0gdHlwZSAwMCBjbGFzcyAweDA4MDYwMCBjb252ZW50aW9uYWwgUENJ
IGVuZHBvaW50DQoNCihYRU4pIFsgICAxMC40ODUxNDddIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6
MDAuMg0KWyAgICAxLjUxMzk0OV0gcGNpIDAwMDA6MDA6MDEuMDogWzEwMjI6MTYzMl0gdHlwZSAw
MCBjbGFzcyAweDA2MDAwMCBjb252ZW50aW9uYWwgUENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAx
MC40OTc4MDRdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDEuMA0KWyAgICAxLjUyNTk1M10gcGNp
IDAwMDA6MDA6MDIuMDogWzEwMjI6MTYzMl0gdHlwZSAwMCBjbGFzcyAweDA2MDAwMCBjb252ZW50
aW9uYWwgUENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAxMC41MTA0NTRdIFBDSSBhZGQgZGV2aWNl
IDAwMDA6MDA6MDIuMA0KWyAgICAxLjUzODk0N10gcGNpIDAwMDA6MDA6MDIuMTogWzEwMjI6MTYz
NF0gdHlwZSAwMSBjbGFzcyAweDA2MDQwMCBQQ0llIFJvb3QgUG9ydA0KDQpbICAgIDEuNTQ1OTcw
XSBwY2kgMDAwMDowMDowMi4xOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDFdDQoNClsgICAgMS41NTA5
NDFdIHBjaSAwMDAwOjAwOjAyLjE6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmZlMDAwMDAwMC0w
eGZmZjgwZmZmZmYgNjRiaXQgcHJlZl0NCg0KWyAgICAxLjU1OTExNV0gcGNpIDAwMDA6MDA6MDIu
MTogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCg0KKFhFTikgWyAgIDEwLjU0
MTY4N10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4xDQpbICAgIDEuNTY5OTQ4XSBwY2kgMDAw
MDowMDowMi4zOiBbMTAyMjoxNjM0XSB0eXBlIDAxIGNsYXNzIDB4MDYwNDAwIFBDSWUgUm9vdCBQ
b3J0DQoNClsgICAgMS41NzY5NjddIHBjaSAwMDAwOjAwOjAyLjM6IFBDSSBicmlkZ2UgdG8gW2J1
cyAwMl0NCg0KWyAgICAxLjU4MTkyOV0gcGNpIDAwMDA6MDA6MDIuMzogICBicmlkZ2Ugd2luZG93
IFttZW0gMHhmZWEwMDAwMC0weGZlYWZmZmZmXQ0KDQpbICAgIDEuNTg4OTQ3XSBwY2kgMDAwMDow
MDowMi4zOiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNClsgICAgMS41OTQxMDNdIHBjaSAwMDAw
OjAwOjAyLjM6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQoNCihYRU4pIFsg
ICAxMC41NzY2MDZdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDIuMw0KWyAgICAxLjYwMzk0N10g
cGNpIDAwMDA6MDA6MDIuNDogWzEwMjI6MTYzNF0gdHlwZSAwMSBjbGFzcyAweDA2MDQwMCBQQ0ll
IFJvb3QgUG9ydA0KDQpbICAgIDEuNjExOTY3XSBwY2kgMDAwMDowMDowMi40OiBQQ0kgYnJpZGdl
IHRvIFtidXMgMDNdDQoNClsgICAgMS42MTY5MjZdIHBjaSAwMDAwOjAwOjAyLjQ6ICAgYnJpZGdl
IHdpbmRvdyBbaW8gIDB4ZjAwMC0weGZmZmZdDQoNClsgICAgMS42MjI5MjJdIHBjaSAwMDAwOjAw
OjAyLjQ6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU5MDAwMDAtMHhmZTlmZmZmZl0NCg0KWyAg
ICAxLjYyODk0N10gcGNpIDAwMDA6MDA6MDIuNDogZW5hYmxpbmcgRXh0ZW5kZWQgVGFncw0KDQpb
ICAgIDEuNjM0MTA3XSBwY2kgMDAwMDowMDowMi40OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQz
aG90IEQzY29sZA0KDQooWEVOKSBbICAgMTAuNjE3NzE1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw
OjAyLjQNClsgICAgMS42NDQ5NTRdIHBjaSAwMDAwOjAwOjA4LjA6IFsxMDIyOjE2MzJdIHR5cGUg
MDAgY2xhc3MgMHgwNjAwMDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAg
MTAuNjMwMzY1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjA4LjANClsgICAgMS42NTY5NDZdIHBj
aSAwMDAwOjAwOjA4LjE6IFsxMDIyOjE2MzVdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDAgUENJZSBS
b290IFBvcnQNCg0KWyAgICAxLjY2NDk2OF0gcGNpIDAwMDA6MDA6MDguMTogUENJIGJyaWRnZSB0
byBbYnVzIDA0XQ0KDQpbICAgIDEuNjY5OTI2XSBwY2kgMDAwMDowMDowOC4xOiAgIGJyaWRnZSB3
aW5kb3cgW2lvICAweGUwMDAtMHhlZmZmXQ0KDQpbICAgIDEuNjc1OTIyXSBwY2kgMDAwMDowMDow
OC4xOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlNDAwMDAwLTB4ZmU3ZmZmZmZdDQoNClsgICAg
MS42ODI5MzJdIHBjaSAwMDAwOjAwOjA4LjE6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDAwMDAw
MDAtMHhlMDFmZmZmZiA2NGJpdCBwcmVmXQ0KDQpbICAgIDEuNjg5OTMzXSBwY2kgMDAwMDowMDow
OC4xOiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNClsgICAgMS42OTUwNzNdIHBjaSAwMDAwOjAw
OjA4LjE6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQoNCihYRU4pIFsgICAx
MC42NzkxNzFdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDguMQ0KWyAgICAxLjcwNTk0OV0gcGNp
IDAwMDA6MDA6MDguMjogWzEwMjI6MTYzNV0gdHlwZSAwMSBjbGFzcyAweDA2MDQwMCBQQ0llIFJv
b3QgUG9ydA0KDQpbICAgIDEuNzEyOTY4XSBwY2kgMDAwMDowMDowOC4yOiBQQ0kgYnJpZGdlIHRv
IFtidXMgMDVdDQoNClsgICAgMS43MTc5MjhdIHBjaSAwMDAwOjAwOjA4LjI6ICAgYnJpZGdlIHdp
bmRvdyBbbWVtIDB4ZmU4MDAwMDAtMHhmZThmZmZmZl0NCg0KWyAgICAxLjcyNDk0NV0gcGNpIDAw
MDA6MDA6MDguMjogZW5hYmxpbmcgRXh0ZW5kZWQgVGFncw0KDQpbICAgIDEuNzMwMDczXSBwY2kg
MDAwMDowMDowOC4yOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZA0KDQooWEVO
KSBbICAgMTAuNzE0MDE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjA4LjINClsgICAgMS43Mzk5
NjldIHBjaSAwMDAwOjAwOjE0LjA6IFsxMDIyOjc5MGJdIHR5cGUgMDAgY2xhc3MgMHgwYzA1MDAg
Y29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTAuNzI2NzM4XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjE0LjANClsgICAgMS43NTI5MzhdIHBjaSAwMDAwOjAwOjE0LjM6IFsx
MDIyOjc5MGVdIHR5cGUgMDAgY2xhc3MgMHgwNjAxMDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2lu
dA0KDQooWEVOKSBbICAgMTAuNzM5NDYyXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjMNClsg
ICAgMS43NjQ5NTddIHBjaSAwMDAwOjAwOjE4LjA6IFsxMDIyOjE0NDhdIHR5cGUgMDAgY2xhc3Mg
MHgwNjAwMDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTAuNzUyMTEw
XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjANClsgICAgMS43Nzc5MzZdIHBjaSAwMDAwOjAw
OjE4LjE6IFsxMDIyOjE0NDldIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAgY29udmVudGlvbmFsIFBD
SSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTAuNzY0NzY2XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw
OjE4LjENClsgICAgMS43ODk5MzVdIHBjaSAwMDAwOjAwOjE4LjI6IFsxMDIyOjE0NGFdIHR5cGUg
MDAgY2xhc3MgMHgwNjAwMDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAg
MTAuNzc3NDIyXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjINClsgICAgMS44MDI5MzVdIHBj
aSAwMDAwOjAwOjE4LjM6IFsxMDIyOjE0NGJdIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAgY29udmVu
dGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTAuNzkwMDcxXSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjE4LjMNClsgICAgMS44MTQ5MzVdIHBjaSAwMDAwOjAwOjE4LjQ6IFsxMDIyOjE0
NGNdIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQoo
WEVOKSBbICAgMTAuODAyNzI5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjQNClsgICAgMS44
Mjc5MzddIHBjaSAwMDAwOjAwOjE4LjU6IFsxMDIyOjE0NGRdIHR5cGUgMDAgY2xhc3MgMHgwNjAw
MDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTAuODE1MzgyXSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjE4LjUNClsgICAgMS44Mzg5MzVdIHBjaSAwMDAwOjAwOjE4LjY6
IFsxMDIyOjE0NGVdIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAgY29udmVudGlvbmFsIFBDSSBlbmRw
b2ludA0KDQooWEVOKSBbICAgMTAuODI4MDMwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjYN
ClsgICAgMS44NTE5MzVdIHBjaSAwMDAwOjAwOjE4Ljc6IFsxMDIyOjE0NGZdIHR5cGUgMDAgY2xh
c3MgMHgwNjAwMDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTAuODQw
Njg3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjcNClsgICAgMS44NjQwMTVdIHBjaSAwMDAw
OjAxOjAwLjA6IFsxMGVlOjU3MDBdIHR5cGUgMDAgY2xhc3MgMHgxMjAwMDAgUENJZSBFbmRwb2lu
dA0KDQpbICAgIDEuODcwOTQ3XSBwY2kgMDAwMDowMTowMC4wOiBCQVIgMCBbbWVtIDB4ZmZlMDAw
MDAwMC0weGZmZWZmZmZmZmYgNjRiaXQgcHJlZl0NCg0KWyAgICAxLjg3ODkzNl0gcGNpIDAwMDA6
MDE6MDAuMDogQkFSIDIgW21lbSAweGZmZjgwNDAwMDAtMHhmZmY4MDdmZmZmIDY0Yml0IHByZWZd
DQoNClsgICAgMS44ODYxMjRdIHBjaSAwMDAwOjAxOjAwLjA6IHN1cHBvcnRzIEQxDQoNClsgICAg
MS44ODk5MThdIHBjaSAwMDAwOjAxOjAwLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDNo
b3QgRDNjb2xkDQoNCihYRU4pIFsgICAxMC44Nzc1NzddIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDE6
MDAuMA0KWyAgICAxLjkwMDk2Ml0gcGNpIDAwMDA6MDE6MDAuMTogWzEwZWU6NTcwMV0gdHlwZSAw
MCBjbGFzcyAweDEyMDAwMCBQQ0llIEVuZHBvaW50DQoNClsgICAgMS45MDc5NDddIHBjaSAwMDAw
OjAxOjAwLjE6IEJBUiAwIFttZW0gMHhmZmY4MDAwMDAwLTB4ZmZmODAzZmZmZiA2NGJpdCBwcmVm
XQ0KDQpbICAgIDEuOTE0OTM1XSBwY2kgMDAwMDowMTowMC4xOiBCQVIgMiBbbWVtIDB4ZmZmMDAw
MDAwMC0weGZmZjdmZmZmZmYgNjRiaXQgcHJlZl0NCg0KWyAgICAxLjkyMjEwN10gcGNpIDAwMDA6
MDE6MDAuMTogc3VwcG9ydHMgRDENCg0KWyAgICAxLjkyNTkxOF0gcGNpIDAwMDA6MDE6MDAuMTog
UE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEM2hvdCBEM2NvbGQNCg0KKFhFTikgWyAgIDEwLjkx
NDM5OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMTowMC4xDQpbICAgIDEuOTM2OTQyXSBwY2kgMDAw
MDowMDowMi4xOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDFdDQoNClsgICAgMS45NDIwMTddIHBjaSAw
MDAwOjAyOjAwLjA6IFsxNDRkOmE4MDhdIHR5cGUgMDAgY2xhc3MgMHgwMTA4MDIgUENJZSBFbmRw
b2ludA0KDQooWEVOKSBbICAgMTAuOTMxMDQxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAw
OjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQoo
WEVOKSBbICAgMTAuOTQwMTQzXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6
IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAg
MTAuOTQ5MjQwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBb
ZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTAuOTU4MzQx
XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZl
YTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQpbICAgIDEuOTY3OTE3XSBwY2kgMDAwMDowMjow
MC4wOiBCQVIgMCBbbWVtIDB4ZmVhMDAwMDAtMHhmZWEwM2ZmZiA2NGJpdF0NCg0KKFhFTikgWyAg
IDEwLjk3Mzk0MV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQg
W2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEwLjk4MzA0
MV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBm
ZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEwLjk5MjEzOF0gYXJjaC94
ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90
IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjAwMTIzOF0gYXJjaC94ODYvcGNpLmM6
MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9y
eSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjAxMDM0MF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEg
MDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9s
ZQ0KKFhFTikgWyAgIDExLjAxOTQ0NF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjow
MC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikg
WyAgIDExLjAyODU0M10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIg
YXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjAz
NzYzOV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAw
LCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjA0Njc0NF0gYXJj
aC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10g
bm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjA1NTgzOF0gYXJjaC94ODYvcGNp
LmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1l
bW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjA2NDk0MV0gYXJjaC94ODYvcGNpLmM6MTA5OmQw
djEgMDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAg
aG9sZQ0KKFhFTikgWyAgIDExLjA3NDA0M10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDow
MjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhF
TikgWyAgIDExLjA4MzEzOV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBC
QVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEx
LjA5MjI0NF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQgW2Zl
YTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjEwMTM0M10g
YXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEw
M10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjExMDQzOV0gYXJjaC94ODYv
cGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGlu
IG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjExOTU0NF0gYXJjaC94ODYvcGNpLmM6MTA5
OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBt
YXAgaG9sZQ0KKFhFTikgWyAgIDExLjEyODYzOV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAw
MDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0K
KFhFTikgWyAgIDExLjEzNzc0NF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4w
OiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAg
IDExLjE0Njg0MF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMjowMC4wOiBCQVIgYXQg
W2ZlYTAwLCBmZWEwM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjE1NjM2
NV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMjowMC4wDQpbICAgIDIuMDcwOTMxXSBwY2kgMDAwMDow
MDowMi4zOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDJdDQoNClsgICAgMi4wNzYwMTldIHBjaSAwMDAw
OjAzOjAwLjA6IFsxMGVjOjgxMjVdIHR5cGUgMDAgY2xhc3MgMHgwMjAwMDAgUENJZSBFbmRwb2lu
dA0KDQooWEVOKSBbICAgMTEuMTcyOTk5XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAz
OjAwLjA6IEJBUiBhdCBbZmU5MDAsIGZlOTBmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVO
KSBbICAgMTEuMTgyMDk5XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJB
UiBhdCBbZmU5MTAsIGZlOTEzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEu
MTkxMjA1XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5
MDAsIGZlOTBmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuMjAwMjk5XSBh
cmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MTAsIGZlOTEz
XSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuMjA5NDA0XSBhcmNoL3g4Ni9w
Y2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MDAsIGZlOTBmXSBub3QgaW4g
bWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuMjE4NTAwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6
ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MTAsIGZlOTEzXSBub3QgaW4gbWVtb3J5IG1h
cCBob2xlDQooWEVOKSBbICAgMTEuMjI3NjAwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAw
OjAzOjAwLjA6IEJBUiBhdCBbZmU5MDAsIGZlOTBmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQoo
WEVOKSBbICAgMTEuMjM2NzAzXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6
IEJBUiBhdCBbZmU5MTAsIGZlOTEzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQpbICAgIDIuMTE5
OTE4XSBwY2kgMDAwMDowMzowMC4wOiBCQVIgMCBbaW8gIDB4ZjAwMC0weGYwZmZdDQoNCihYRU4p
IFsgICAxMS4yNTEwODldIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFS
IGF0IFtmZTkwMCwgZmU5MGZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS4y
NjAxODZdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkx
MCwgZmU5MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS4yNjkyODZdIGFy
Y2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwgZmU5MGZd
IG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS4yNzgzODldIGFyY2gveDg2L3Bj
aS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5vdCBpbiBt
ZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS4yODc0OTFdIGFyY2gveDg2L3BjaS5jOjEwOTpk
MHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwgZmU5MGZdIG5vdCBpbiBtZW1vcnkgbWFw
IGhvbGUNCihYRU4pIFsgICAxMS4yOTY1OTBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6
MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihY
RU4pIFsgICAxMS4zMDU2ODldIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDog
QkFSIGF0IFtmZTkwMCwgZmU5MGZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAx
MS4zMTQ3OTBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtm
ZTkxMCwgZmU5MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS4zMjM4OTJd
IGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwgZmU5
MGZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS4zMzI5OTFdIGFyY2gveDg2
L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5vdCBp
biBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS4zNDIwODldIGFyY2gveDg2L3BjaS5jOjEw
OTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwgZmU5MGZdIG5vdCBpbiBtZW1vcnkg
bWFwIGhvbGUNCihYRU4pIFsgICAxMS4zNTExOTBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAw
MDA6MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUN
CihYRU4pIFsgICAxMS4zNjAyODddIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAu
MDogQkFSIGF0IFtmZTkwMCwgZmU5MGZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsg
ICAxMS4zNjkzODddIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0
IFtmZTkxMCwgZmU5MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS4zNzg0
OTBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwg
ZmU5MGZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS4zODc1ODddIGFyY2gv
eDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5v
dCBpbiBtZW1vcnkgbWFwIGhvbGUNClsgICAgMi4xOTI5MThdIHBjaSAwMDAwOjAzOjAwLjA6IEJB
UiAyIFttZW0gMHhmZTkwMDAwMC0weGZlOTBmZmZmIDY0Yml0XQ0KDQooWEVOKSBbICAgMTEuNDAz
MTkyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MDAs
IGZlOTBmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNDEyMjkxXSBhcmNo
L3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MTAsIGZlOTEzXSBu
b3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNDIxMzg3XSBhcmNoL3g4Ni9wY2ku
YzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MDAsIGZlOTBmXSBub3QgaW4gbWVt
b3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNDMwNDkyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2
MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MTAsIGZlOTEzXSBub3QgaW4gbWVtb3J5IG1hcCBo
b2xlDQooWEVOKSBbICAgMTEuNDM5NTg4XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAz
OjAwLjA6IEJBUiBhdCBbZmU5MDAsIGZlOTBmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVO
KSBbICAgMTEuNDQ4NjkwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJB
UiBhdCBbZmU5MTAsIGZlOTEzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEu
NDU3Nzg2XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5
MDAsIGZlOTBmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNDY2ODkwXSBh
cmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MTAsIGZlOTEz
XSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQpbICAgIDIuMjM2OTE4XSBwY2kgMDAwMDowMzowMC4w
OiBCQVIgNCBbbWVtIDB4ZmU5MTAwMDAtMHhmZTkxM2ZmZiA2NGJpdF0NCg0KKFhFTikgWyAgIDEx
LjQ4MjQ4N10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2Zl
OTAwLCBmZTkwZl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjQ5MTU4Nl0g
YXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTEwLCBmZTkx
M10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjUwMDY4Nl0gYXJjaC94ODYv
cGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTAwLCBmZTkwZl0gbm90IGlu
IG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjUwOTc5MF0gYXJjaC94ODYvcGNpLmM6MTA5
OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTEwLCBmZTkxM10gbm90IGluIG1lbW9yeSBt
YXAgaG9sZQ0KKFhFTikgWyAgIDExLjUxODg5MF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAw
MDowMzowMC4wOiBCQVIgYXQgW2ZlOTAwLCBmZTkwZl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0K
KFhFTikgWyAgIDExLjUyNzk5MF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4w
OiBCQVIgYXQgW2ZlOTEwLCBmZTkxM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAg
IDExLjUzNzA4N10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQg
W2ZlOTAwLCBmZTkwZl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjU0NjE5
Ml0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTEwLCBm
ZTkxM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KWyAgICAyLjI4MTE1Ml0gcGNpIDAwMDA6MDM6
MDAuMDogc3VwcG9ydHMgRDEgRDINCg0KWyAgICAyLjI4NTkxOF0gcGNpIDAwMDA6MDM6MDAuMDog
UE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBEM2NvbGQNCg0KKFhFTikgWyAgIDEx
LjU2NjY3OF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMzowMC4wDQpbICAgIDIuMjk3MDQyXSBwY2kg
MDAwMDowMDowMi40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDNdDQoNClsgICAgMi4zMDIwMDhdIHBj
aSAwMDAwOjA0OjAwLjA6IFsxMDAyOjE2MzZdIHR5cGUgMDAgY2xhc3MgMHgwMzAwMDAgUENJZSBM
ZWdhY3kgRW5kcG9pbnQNCg0KKFhFTikgWyAgIDExLjU4MzkyNF0gYXJjaC94ODYvcGNpLmM6MTA5
OmQwdjEgMDAwMDowNDowMC4wOiBCQVIgYXQgW2ZlNzAwLCBmZTc3Zl0gbm90IGluIG1lbW9yeSBt
YXAgaG9sZQ0KKFhFTikgWyAgIDExLjU5MzQ1N10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAw
MDowNDowMC4wOiBCQVIgYXQgW2ZlNzAwLCBmZTc3Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0K
KFhFTikgWyAgIDExLjYwMjU1OF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4w
OiBCQVIgYXQgW2ZlNzAwLCBmZTc3Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAg
IDExLjYxMTY2MF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBCQVIgYXQg
W2ZlNzAwLCBmZTc3Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KWyAgICAyLjMyODkxN10gcGNp
IDAwMDA6MDQ6MDAuMDogQkFSIDAgW21lbSAweGQwMDAwMDAwLTB4ZGZmZmZmZmYgNjRiaXQgcHJl
Zl0NCg0KKFhFTikgWyAgIDExLjYyNzY5NF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDow
NDowMC4wOiBCQVIgYXQgW2ZlNzAwLCBmZTc3Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhF
TikgWyAgIDExLjYzNzIxN10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBC
QVIgYXQgW2ZlNzAwLCBmZTc3Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEx
LjY0NjMyMl0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBCQVIgYXQgW2Zl
NzAwLCBmZTc3Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjY1NTQxOF0g
YXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBCQVIgYXQgW2ZlNzAwLCBmZTc3
Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KWyAgICAyLjM1NDkxN10gcGNpIDAwMDA6MDQ6MDAu
MDogQkFSIDIgW21lbSAweGUwMDAwMDAwLTB4ZTAxZmZmZmYgNjRiaXQgcHJlZl0NCg0KKFhFTikg
WyAgIDExLjY3MTQ1MV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBCQVIg
YXQgW2ZlNzAwLCBmZTc3Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjY4
MDk4NF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBCQVIgYXQgW2ZlNzAw
LCBmZTc3Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjY5MDA4N10gYXJj
aC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBCQVIgYXQgW2ZlNzAwLCBmZTc3Zl0g
bm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjY5OTE5MF0gYXJjaC94ODYvcGNp
LmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBCQVIgYXQgW2ZlNzAwLCBmZTc3Zl0gbm90IGluIG1l
bW9yeSBtYXAgaG9sZQ0KWyAgICAyLjM4MDkxN10gcGNpIDAwMDA6MDQ6MDAuMDogQkFSIDQgW2lv
ICAweGUwMDAtMHhlMGZmXQ0KDQooWEVOKSBbICAgMTEuNzEzNTcxXSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5
IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNzIzMTA0XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAw
MDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xl
DQooWEVOKSBbICAgMTEuNzMyMjA4XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAw
LjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBb
ICAgMTEuNzQxMzA0XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBh
dCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQpbICAgIDIuNDA1OTE3XSBw
Y2kgMDAwMDowNDowMC4wOiBCQVIgNSBbbWVtIDB4ZmU3MDAwMDAtMHhmZTc3ZmZmZl0NCg0KKFhF
TikgWyAgIDExLjc1NjM5MF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBC
QVIgYXQgW2ZlNzAwLCBmZTc3Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEx
Ljc2NTkyN10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBCQVIgYXQgW2Zl
NzAwLCBmZTc3Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjc3NTAyMl0g
YXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBCQVIgYXQgW2ZlNzAwLCBmZTc3
Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjc4NDEyMl0gYXJjaC94ODYv
cGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4wOiBCQVIgYXQgW2ZlNzAwLCBmZTc3Zl0gbm90IGlu
IG1lbW9yeSBtYXAgaG9sZQ0KWyAgICAyLjQzMDkyN10gcGNpIDAwMDA6MDQ6MDAuMDogZW5hYmxp
bmcgRXh0ZW5kZWQgVGFncw0KDQpbICAgIDIuNDM2MTUwXSBwY2kgMDAwMDowNDowMC4wOiBQTUUj
IHN1cHBvcnRlZCBmcm9tIEQxIEQyIEQzaG90IEQzY29sZA0KDQpbICAgIDIuNDQzMDExXSBwY2kg
MDAwMDowNDowMC4wOiAxMjYuMDE2IEdiL3MgYXZhaWxhYmxlIFBDSWUgYmFuZHdpZHRoLCBsaW1p
dGVkIGJ5IDguMCBHVC9zIFBDSWUgeDE2IGxpbmsgYXQgMDAwMDowMDowOC4xIChjYXBhYmxlIG9m
IDI1Mi4wNDggR2IvcyB3aXRoIDE2LjAgR1QvcyBQQ0llIHgxNiBsaW5rKQ0KDQooWEVOKSBbICAg
MTEuODIwMzY4XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjANClsgICAgMi40NjI5NDddIHBj
aSAwMDAwOjA0OjAwLjE6IFsxMDAyOjE2MzddIHR5cGUgMDAgY2xhc3MgMHgwNDAzMDAgUENJZSBM
ZWdhY3kgRW5kcG9pbnQNCg0KWyAgICAyLjQ2OTkzNl0gcGNpIDAwMDA6MDQ6MDAuMTogQkFSIDAg
W21lbSAweGZlN2M4MDAwLTB4ZmU3Y2JmZmZdDQoNClsgICAgMi40NzU5NzBdIHBjaSAwMDAwOjA0
OjAwLjE6IGVuYWJsaW5nIEV4dGVuZGVkIFRhZ3MNCg0KWyAgICAyLjQ4MTAwMV0gcGNpIDAwMDA6
MDQ6MDAuMTogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMSBEMiBEM2hvdCBEM2NvbGQNCg0KKFhFTikg
WyAgIDExLjg1MDAwNV0gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4xDQpbICAgIDIuNDkxOTQ3
XSBwY2kgMDAwMDowNDowMC4yOiBbMTAyMjoxNWRmXSB0eXBlIDAwIGNsYXNzIDB4MTA4MDAwIFBD
SWUgRW5kcG9pbnQNCg0KWyAgICAyLjQ5ODk1MF0gcGNpIDAwMDA6MDQ6MDAuMjogQkFSIDIgW21l
bSAweGZlNjAwMDAwLTB4ZmU2ZmZmZmZdDQoNClsgICAgMi41MDQ5NDBdIHBjaSAwMDAwOjA0OjAw
LjI6IEJBUiA1IFttZW0gMHhmZTdjYzAwMC0weGZlN2NkZmZmXQ0KDQpbICAgIDIuNTEwOTM1XSBw
Y2kgMDAwMDowNDowMC4yOiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNCihYRU4pIFsgICAxMS44
Nzg2NjNdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMg0KWyAgICAyLjUxOTk0Nl0gcGNpIDAw
MDA6MDQ6MDAuMzogWzEwMjI6MTYzOV0gdHlwZSAwMCBjbGFzcyAweDBjMDMzMCBQQ0llIEVuZHBv
aW50DQoNCihYRU4pIFsgICAxMS44OTAyODBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6
MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihY
RU4pIFsgICAxMS44OTkzNzZdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzog
QkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAx
MS45MDg0ODBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtm
ZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS45MTc1Nzld
IGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1
ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNClsgICAgMi41NDU5MTddIHBjaSAwMDAwOjA0OjAw
LjM6IEJBUiAwIFttZW0gMHhmZTUwMDAwMC0weGZlNWZmZmZmIDY0Yml0XQ0KDQooWEVOKSBbICAg
MTEuOTMzMTgwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBb
ZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuOTQyMjc5
XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZl
NWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuOTUxMzc3XSBhcmNoL3g4
Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3Qg
aW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuOTYwNDc5XSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5
IG1hcCBob2xlDQooWEVOKSBbICAgMTEuOTY5NTgyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAw
MDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xl
DQooWEVOKSBbICAgMTEuOTc4NjgxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAw
LjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBb
ICAgMTEuOTg3Nzc5XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBh
dCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuOTk2
ODgwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAs
IGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMDA1OTgwXSBhcmNo
L3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBu
b3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMDE1MDc5XSBhcmNoL3g4Ni9wY2ku
YzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVt
b3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMDI0MTc3XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2
MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBo
b2xlDQooWEVOKSBbICAgMTIuMDMzMjgyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0
OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVO
KSBbICAgMTIuMDQyMzc3XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJB
UiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIu
MDUxNDgyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1
MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMDYwNTgxXSBh
cmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZm
XSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMDY5NjgwXSBhcmNoL3g4Ni9w
Y2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4g
bWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMDc4Nzc3XSBhcmNoL3g4Ni9wY2kuYzoxMDk6
ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1h
cCBob2xlDQooWEVOKSBbICAgMTIuMDg3ODgwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAw
OjA0OjAwLjM6IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQoo
WEVOKSBbICAgMTIuMDk2OTgwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6
IEJBUiBhdCBbZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAg
MTIuMTA2MDc3XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjM6IEJBUiBhdCBb
ZmU1MDAsIGZlNWZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQpbICAgIDIuNjQ4OTMwXSBwY2kg
MDAwMDowNDowMC4zOiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNClsgICAgMi42NTQwMTJdIHBj
aSAwMDAwOjA0OjAwLjM6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQoNCihY
RU4pIFsgICAxMi4xMjYzNThdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMw0KWyAgICAyLjY2
NDk0Nl0gcGNpIDAwMDA6MDQ6MDAuNDogWzEwMjI6MTYzOV0gdHlwZSAwMCBjbGFzcyAweDBjMDMz
MCBQQ0llIEVuZHBvaW50DQoNCihYRU4pIFsgICAxMi4xMzc5NzBdIGFyY2gveDg2L3BjaS5jOjEw
OTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkg
bWFwIGhvbGUNCihYRU4pIFsgICAxMi4xNDcwNzJdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAw
MDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUN
CihYRU4pIFsgICAxMi4xNTYxNzFdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAu
NDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsg
ICAxMi4xNjUyNzBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0
IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNClsgICAgMi42OTA5MTddIHBj
aSAwMDAwOjA0OjAwLjQ6IEJBUiAwIFttZW0gMHhmZTQwMDAwMC0weGZlNGZmZmZmIDY0Yml0XQ0K
DQooWEVOKSBbICAgMTIuMTgwODcxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAw
LjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBb
ICAgMTIuMTg5OTc2XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBh
dCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMTk5
MDcwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAs
IGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMjA4MTczXSBhcmNo
L3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBu
b3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMjE3Mjc0XSBhcmNoL3g4Ni9wY2ku
YzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVt
b3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMjI2MzcxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2
MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBo
b2xlDQooWEVOKSBbICAgMTIuMjM1NDcyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0
OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVO
KSBbICAgMTIuMjQ0NTczXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJB
UiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIu
MjUzNjcyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0
MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMjYyNzc0XSBh
cmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZm
XSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMjcxODcxXSBhcmNoL3g4Ni9w
Y2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4g
bWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMjgwOTc0XSBhcmNoL3g4Ni9wY2kuYzoxMDk6
ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1h
cCBob2xlDQooWEVOKSBbICAgMTIuMjkwMDcwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAw
OjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQoo
WEVOKSBbICAgMTIuMjk5MTc2XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6
IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAg
MTIuMzA4MjcxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBb
ZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMzE3Mzc2
XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZl
NGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMzI2NDc0XSBhcmNoL3g4
Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3Qg
aW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMzM1NTcxXSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZDB2MSAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5
IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMzQ0NjczXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAw
MDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xl
DQooWEVOKSBbICAgMTIuMzUzNzcxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAw
LjQ6IEJBUiBhdCBbZmU0MDAsIGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQpbICAgIDIu
NzkzOTMwXSBwY2kgMDAwMDowNDowMC40OiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNClsgICAg
Mi43OTkwMTJdIHBjaSAwMDAwOjA0OjAwLjQ6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3Qg
RDNjb2xkDQoNCihYRU4pIFsgICAxMi4zNzQwNTddIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAu
NA0KWyAgICAyLjgwOTk0N10gcGNpIDAwMDA6MDQ6MDAuNTogWzEwMjI6MTVlMl0gdHlwZSAwMCBj
bGFzcyAweDA0ODAwMCBQQ0llIEVuZHBvaW50DQoNClsgICAgMi44MTY5MzZdIHBjaSAwMDAwOjA0
OjAwLjU6IEJBUiAwIFttZW0gMHhmZTc4MDAwMC0weGZlN2JmZmZmXQ0KDQpbICAgIDIuODIyOTcw
XSBwY2kgMDAwMDowNDowMC41OiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNClsgICAgMi44Mjgw
MjldIHBjaSAwMDAwOjA0OjAwLjU6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xk
DQoNCihYRU4pIFsgICAxMi40MDI4MjhdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNQ0KWyAg
ICAyLjgzNzk0N10gcGNpIDAwMDA6MDQ6MDAuNjogWzEwMjI6MTVlM10gdHlwZSAwMCBjbGFzcyAw
eDA0MDMwMCBQQ0llIEVuZHBvaW50DQoNClsgICAgMi44NDQ5MzZdIHBjaSAwMDAwOjA0OjAwLjY6
IEJBUiAwIFttZW0gMHhmZTdjMDAwMC0weGZlN2M3ZmZmXQ0KDQpbICAgIDIuODUwOTcwXSBwY2kg
MDAwMDowNDowMC42OiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNClsgICAgMi44NTYwMDFdIHBj
aSAwMDAwOjA0OjAwLjY6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQoNCihY
RU4pIFsgICAxMi40MzE1OThdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNg0KWyAgICAyLjg2
Njk4Ml0gcGNpIDAwMDA6MDA6MDguMTogUENJIGJyaWRnZSB0byBbYnVzIDA0XQ0KDQpbICAgIDIu
ODcyMDA3XSBwY2kgMDAwMDowNTowMC4wOiBbMTAyMjo3OTAxXSB0eXBlIDAwIGNsYXNzIDB4MDEw
NjAxIFBDSWUgRW5kcG9pbnQNCg0KKFhFTikgWyAgIDEyLjQ0ODIzOV0gYXJjaC94ODYvcGNpLmM6
MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9y
eSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjQ1NzM0MV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEg
MDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9s
ZQ0KKFhFTikgWyAgIDEyLjQ2NjQzOV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTow
MC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikg
WyAgIDEyLjQ3NTU0MV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIg
YXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjQ4
NDY0MF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAx
LCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjQ5MzczOF0gYXJj
aC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0g
bm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjUwMjgzOF0gYXJjaC94ODYvcGNp
LmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1l
bW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjUxMTk0Ml0gYXJjaC94ODYvcGNpLmM6MTA5OmQw
djEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAg
aG9sZQ0KKFhFTikgWyAgIDEyLjUyMTA0Ml0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDow
NTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhF
TikgWyAgIDEyLjUzMDE0MF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBC
QVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEy
LjUzOTIzOF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2Zl
ODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjU0ODM0MV0g
YXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgw
MV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjU1NzQzOV0gYXJjaC94ODYv
cGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGlu
IG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjU2NjU0MV0gYXJjaC94ODYvcGNpLmM6MTA5
OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBt
YXAgaG9sZQ0KKFhFTikgWyAgIDEyLjU3NTY0M10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAw
MDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0K
KFhFTikgWyAgIDEyLjU4NDc0NF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4w
OiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAg
IDEyLjU5MzgzOF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQg
W2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjYwMjkz
OV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBm
ZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjYxMjA0NF0gYXJjaC94
ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90
IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjYyMTE0MF0gYXJjaC94ODYvcGNpLmM6
MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9y
eSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjYzMDI0MV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEg
MDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9s
ZQ0KKFhFTikgWyAgIDEyLjYzOTM0NF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTow
MC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikg
WyAgIDEyLjY0ODQzOF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIg
YXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjY1
NzU0MV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAx
LCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KWyAgICAyLjk5MzkxOF0gcGNpIDAwMDA6
MDU6MDAuMDogQkFSIDUgW21lbSAweGZlODAxMDAwLTB4ZmU4MDE3ZmZdDQoNCihYRU4pIFsgICAx
Mi42NzI2MThdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDU6MDAuMDogQkFSIGF0IFtm
ZTgwMSwgZmU4MDFdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi42ODE3MjBd
IGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDU6MDAuMDogQkFSIGF0IFtmZTgwMSwgZmU4
MDFdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi42OTA4MjRdIGFyY2gveDg2
L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDU6MDAuMDogQkFSIGF0IFtmZTgwMSwgZmU4MDFdIG5vdCBp
biBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi42OTk5MjNdIGFyY2gveDg2L3BjaS5jOjEw
OTpkMHYxIDAwMDA6MDU6MDAuMDogQkFSIGF0IFtmZTgwMSwgZmU4MDFdIG5vdCBpbiBtZW1vcnkg
bWFwIGhvbGUNClsgICAgMy4wMTg5MjldIHBjaSAwMDAwOjA1OjAwLjA6IGVuYWJsaW5nIEV4dGVu
ZGVkIFRhZ3MNCg0KWyAgICAzLjAyNTIwOF0gcGNpIDAwMDA6MDU6MDAuMDogMTI2LjAxNiBHYi9z
IGF2YWlsYWJsZSBQQ0llIGJhbmR3aWR0aCwgbGltaXRlZCBieSA4LjAgR1QvcyBQQ0llIHgxNiBs
aW5rIGF0IDAwMDA6MDA6MDguMiAoY2FwYWJsZSBvZiAyNTIuMDQ4IEdiL3Mgd2l0aCAxNi4wIEdU
L3MgUENJZSB4MTYgbGluaykNCg0KKFhFTikgWyAgIDEyLjczMDAwOF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowNTowMC4wDQpbICAgIDMuMDQzOTQ4XSBwY2kgMDAwMDowNTowMC4xOiBbMTAyMjo3OTAx
XSB0eXBlIDAwIGNsYXNzIDB4MDEwNjAxIFBDSWUgRW5kcG9pbnQNCg0KKFhFTikgWyAgIDEyLjc0
MTYyNF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAw
LCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjc1MDcyMV0gYXJj
aC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0g
bm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjc1OTgxOF0gYXJjaC94ODYvcGNp
LmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1l
bW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjc2ODkyMV0gYXJjaC94ODYvcGNpLmM6MTA5OmQw
djMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAg
aG9sZQ0KKFhFTikgWyAgIDEyLjc3ODAyMl0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDow
NTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhF
TikgWyAgIDEyLjc4NzExOF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBC
QVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEy
Ljc5NjIyNF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2Zl
ODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjgwNTMxOV0g
YXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgw
MF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjgxNDQyNF0gYXJjaC94ODYv
cGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGlu
IG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjgyMzUxOV0gYXJjaC94ODYvcGNpLmM6MTA5
OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBt
YXAgaG9sZQ0KKFhFTikgWyAgIDEyLjgzMjYyMl0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAw
MDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0K
KFhFTikgWyAgIDEyLjg0MTcyM10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4x
OiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAg
IDEyLjg1MDgxOV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQg
W2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjg1OTkx
OF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBm
ZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjg2OTAyMl0gYXJjaC94
ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90
IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjg3ODExOV0gYXJjaC94ODYvcGNpLmM6
MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9y
eSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjg4NzIxOF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMg
MDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9s
ZQ0KKFhFTikgWyAgIDEyLjg5NjMxOV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTow
MC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikg
WyAgIDEyLjkwNTQyMV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIg
YXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjkx
NDUyMl0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAw
LCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjkyMzYyNF0gYXJj
aC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0g
bm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjkzMjcyMF0gYXJjaC94ODYvcGNp
LmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1l
bW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjk0MTgyMl0gYXJjaC94ODYvcGNpLmM6MTA5OmQw
djMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAg
aG9sZQ0KKFhFTikgWyAgIDEyLjk1MDkyMl0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDow
NTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KWyAg
ICAzLjE1ODkxOV0gcGNpIDAwMDA6MDU6MDAuMTogQkFSIDUgW21lbSAweGZlODAwMDAwLTB4ZmU4
MDA3ZmZdDQoNCihYRU4pIFsgICAxMi45NjYwMDNdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYzIDAw
MDA6MDU6MDAuMTogQkFSIGF0IFtmZTgwMCwgZmU4MDBdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUN
CihYRU4pIFsgICAxMi45NzUwOTldIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYzIDAwMDA6MDU6MDAu
MTogQkFSIGF0IFtmZTgwMCwgZmU4MDBdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsg
ICAxMi45ODQxOTldIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYzIDAwMDA6MDU6MDAuMTogQkFSIGF0
IFtmZTgwMCwgZmU4MDBdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi45OTMz
MDJdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYzIDAwMDA6MDU6MDAuMTogQkFSIGF0IFtmZTgwMCwg
ZmU4MDBdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNClsgICAgMy4xODI5MjddIHBjaSAwMDAwOjA1
OjAwLjE6IGVuYWJsaW5nIEV4dGVuZGVkIFRhZ3MNCg0KKFhFTikgWyAgIDEzLjAwNzQ5M10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowNTowMC4xDQpbICAgIDMuMTkyOTU3XSBwY2kgMDAwMDowMDowOC4y
OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDVdDQoNClsgICAgMy4xOTc1NTJdIEFDUEk6IFBDSTogSW50
ZXJydXB0IGxpbmsgTE5LQSBjb25maWd1cmVkIGZvciBJUlEgMA0KDQpbICAgIDMuMjAzOTY0XSBB
Q1BJOiBQQ0k6IEludGVycnVwdCBsaW5rIExOS0IgY29uZmlndXJlZCBmb3IgSVJRIDANCg0KWyAg
ICAzLjIwOTk1N10gQUNQSTogUENJOiBJbnRlcnJ1cHQgbGluayBMTktDIGNvbmZpZ3VyZWQgZm9y
IElSUSAwDQoNClsgICAgMy4yMTQ5NjddIEFDUEk6IFBDSTogSW50ZXJydXB0IGxpbmsgTE5LRCBj
b25maWd1cmVkIGZvciBJUlEgMA0KDQpbICAgIDMuMjIwOTYxXSBBQ1BJOiBQQ0k6IEludGVycnVw
dCBsaW5rIExOS0UgY29uZmlndXJlZCBmb3IgSVJRIDANCg0KWyAgICAzLjIyNjk1M10gQUNQSTog
UENJOiBJbnRlcnJ1cHQgbGluayBMTktGIGNvbmZpZ3VyZWQgZm9yIElSUSAwDQoNClsgICAgMy4y
MzI5NTRdIEFDUEk6IFBDSTogSW50ZXJydXB0IGxpbmsgTE5LRyBjb25maWd1cmVkIGZvciBJUlEg
MA0KDQpbICAgIDMuMjM4OTU0XSBBQ1BJOiBQQ0k6IEludGVycnVwdCBsaW5rIExOS0ggY29uZmln
dXJlZCBmb3IgSVJRIDANCg0KWyAgICAzLjI0NDg3NF0geGVuOmJhbGxvb246IEluaXRpYWxpc2lu
ZyBiYWxsb29uIGRyaXZlcg0KDQpbICAgIDMuMzMyOTk1XSBpb21tdTogRGVmYXVsdCBkb21haW4g
dHlwZTogVHJhbnNsYXRlZA0KDQpbICAgIDMuMzM3OTIxXSBpb21tdTogRE1BIGRvbWFpbiBUTEIg
aW52YWxpZGF0aW9uIHBvbGljeTogbGF6eSBtb2RlDQoNClsgICAgMy4zNDM5NzNdIFNDU0kgc3Vi
c3lzdGVtIGluaXRpYWxpemVkDQoNClsgICAgMy4zNDc5MzVdIGxpYmF0YSB2ZXJzaW9uIDMuMDAg
bG9hZGVkLg0KDQpbICAgIDMuMzUwOTMxXSBBQ1BJOiBidXMgdHlwZSBVU0IgcmVnaXN0ZXJlZA0K
DQpbICAgIDMuMzU0OTI3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVy
IHVzYmZzDQoNClsgICAgMy4zNjA5MjFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFj
ZSBkcml2ZXIgaHViDQoNClsgICAgMy4zNjU5MjJdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRl
dmljZSBkcml2ZXIgdXNiDQoNClsgICAgMy4zNzA5MjZdIHBwc19jb3JlOiBMaW51eFBQUyBBUEkg
dmVyLiAxIHJlZ2lzdGVyZWQNCg0KWyAgICAzLjM3NTkxOF0gcHBzX2NvcmU6IFNvZnR3YXJlIHZl
ci4gNS4zLjYgLSBDb3B5cmlnaHQgMjAwNS0yMDA3IFJvZG9sZm8gR2lvbWV0dGkgPGdpb21ldHRp
QGxpbnV4Lml0Pg0KDQpbICAgIDMuMzg0OTIxXSBQVFAgY2xvY2sgc3VwcG9ydCByZWdpc3RlcmVk
DQoNClsgICAgMy4zODg5NjJdIGVmaXZhcnM6IFJlZ2lzdGVyZWQgZWZpdmFycyBvcGVyYXRpb25z
DQoNClsgICAgMy4zOTI5MzRdIEFkdmFuY2VkIExpbnV4IFNvdW5kIEFyY2hpdGVjdHVyZSBEcml2
ZXIgSW5pdGlhbGl6ZWQuDQoNClsgICAgMy4zOTkwMTNdIE5ldExhYmVsOiBJbml0aWFsaXppbmcN
Cg0KWyAgICAzLjQwMjkxOF0gTmV0TGFiZWw6ICBkb21haW4gaGFzaCBzaXplID0gMTI4DQoNClsg
ICAgMy40MDY5MThdIE5ldExhYmVsOiAgcHJvdG9jb2xzID0gVU5MQUJFTEVEIENJUFNPdjQgQ0FM
SVBTTw0KDQpbICAgIDMuNDEyOTI4XSBOZXRMYWJlbDogIHVubGFiZWxlZCB0cmFmZmljIGFsbG93
ZWQgYnkgZGVmYXVsdA0KDQpbICAgIDMuNDE3OTM1XSBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSBy
b3V0aW5nDQoNClsgICAgMy40Mjk4MThdIFBDSTogcGNpX2NhY2hlX2xpbmVfc2l6ZSBzZXQgdG8g
NjQgYnl0ZXMNCg0KWyAgICAzLjQzNTAzMF0gcmVzb3VyY2U6IEV4cGFuZGVkIHJlc291cmNlIFJl
c2VydmVkIGR1ZSB0byBjb25mbGljdCB3aXRoIFBDSSBCdXMgMDAwMDowMA0KDQpbICAgIDMuNDQy
OTE5XSByZXNvdXJjZTogRXhwYW5kZWQgcmVzb3VyY2UgUmVzZXJ2ZWQgZHVlIHRvIGNvbmZsaWN0
IHdpdGggUENJIEJ1cyAwMDAwOjAwDQoNClsgICAgMy40NDk5MTldIGU4MjA6IHJlc2VydmUgUkFN
IGJ1ZmZlciBbbWVtIDB4MDliZmYwMDAtMHgwYmZmZmZmZl0NCg0KWyAgICAzLjQ1NTkxOF0gZTgy
MDogcmVzZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHgwYTIwMDAwMC0weDBiZmZmZmZmXQ0KDQpbICAg
IDMuNDYxOTE4XSBlODIwOiByZXNlcnZlIFJBTSBidWZmZXIgW21lbSAweGNhYmM5MDAwLTB4Y2Jm
ZmZmZmZdDQoNClsgICAgMy40Njc5MThdIGU4MjA6IHJlc2VydmUgUkFNIGJ1ZmZlciBbbWVtIDB4
Y2RmZmZlYTgtMHhjZmZmZmZmZl0NCg0KWyAgICAzLjQ3MzkxOV0gZTgyMDogcmVzZXJ2ZSBSQU0g
YnVmZmVyIFttZW0gMHg4MGYzNDAwMDAtMHg4MGZmZmZmZmZdDQoNClsgICAgMy40Nzk5MzFdIHBj
aSAwMDAwOjA0OjAwLjA6IHZnYWFyYjogc2V0dGluZyBhcyBib290IFZHQSBkZXZpY2UNCg0KWyAg
ICAzLjQ4MDkxMl0gcGNpIDAwMDA6MDQ6MDAuMDogdmdhYXJiOiBicmlkZ2UgY29udHJvbCBwb3Nz
aWJsZQ0KDQpbICAgIDMuNDgwOTEyXSBwY2kgMDAwMDowNDowMC4wOiB2Z2FhcmI6IFZHQSBkZXZp
Y2UgYWRkZWQ6IGRlY29kZXM9aW8rbWVtLG93bnM9bm9uZSxsb2Nrcz1ub25lDQoNClsgICAgMy40
OTk5MThdIHZnYWFyYjogbG9hZGVkDQoNClsgICAgMy41MDMwMDldIGNsb2Nrc291cmNlOiBTd2l0
Y2hlZCB0byBjbG9ja3NvdXJjZSB0c2MtZWFybHkNCg0KWyAgICAzLjUwODQwMV0gVkZTOiBEaXNr
IHF1b3RhcyBkcXVvdF82LjYuMA0KDQpbICAgIDMuNTEyMzI5XSBWRlM6IERxdW90LWNhY2hlIGhh
c2ggdGFibGUgZW50cmllczogNTEyIChvcmRlciAwLCA0MDk2IGJ5dGVzKQ0KDQpbICAgIDMuNTE5
MzA1XSBwbnA6IFBuUCBBQ1BJIGluaXQNCg0KWyAgICAzLjUyMjQ2MV0gc3lzdGVtIDAwOjAwOiBb
bWVtIDB4ZjAwMDAwMDAtMHhmN2ZmZmZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjUy
OTIzN10gc3lzdGVtIDAwOjAyOiBbaW8gIDB4MGEwMC0weDBhMGZdIGhhcyBiZWVuIHJlc2VydmVk
DQoNClsgICAgMy41MzUwODldIHN5c3RlbSAwMDowMjogW2lvICAweDBhMTAtMHgwYTFmXSBoYXMg
YmVlbiByZXNlcnZlZA0KDQpbICAgIDMuNTQxMDcwXSBzeXN0ZW0gMDA6MDI6IFtpbyAgMHgwYTIw
LTB4MGEyZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjU0NzI1NV0gcG5wIDAwOjAzOiBb
ZG1hIDAgZGlzYWJsZWRdDQoNClsgICAgMy41NTEyNDRdIHBucCAwMDowNDogW2RtYSAwIGRpc2Fi
bGVkXQ0KDQpbICAgIDMuNTU1MjMwXSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwNGQwLTB4MDRkMV0g
aGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjU2MTA3OV0gc3lzdGVtIDAwOjA1OiBbaW8gIDB4
MDQwYl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjU2NjQ1MF0gc3lzdGVtIDAwOjA1OiBb
aW8gIDB4MDRkNl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjU3MTgyNl0gc3lzdGVtIDAw
OjA1OiBbaW8gIDB4MGMwMC0weDBjMDFdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAgMy41Nzc4
MDZdIHN5c3RlbSAwMDowNTogW2lvICAweDBjMTRdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAg
My41ODMxNzldIHN5c3RlbSAwMDowNTogW2lvICAweDBjNTAtMHgwYzUxXSBoYXMgYmVlbiByZXNl
cnZlZA0KDQpbICAgIDMuNTg5MTU2XSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwYzUyXSBoYXMgYmVl
biByZXNlcnZlZA0KDQpbICAgIDMuNTk0NTI3XSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwYzZjXSBo
YXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDMuNTk5OTAwXSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgw
YzZmXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDMuNjA1Mjc2XSBzeXN0ZW0gMDA6MDU6IFtp
byAgMHgwY2QwLTB4MGNkMV0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjYxMTI1N10gc3lz
dGVtIDAwOjA1OiBbaW8gIDB4MGNkMi0weDBjZDNdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAg
My42MTcyMzddIHN5c3RlbSAwMDowNTogW2lvICAweDBjZDQtMHgwY2Q1XSBoYXMgYmVlbiByZXNl
cnZlZA0KDQpbICAgIDMuNjIzMjE2XSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwY2Q2LTB4MGNkN10g
aGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjYyOTE5NF0gc3lzdGVtIDAwOjA1OiBbaW8gIDB4
MGNkOC0weDBjZGZdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAgMy42MzUxNzddIHN5c3RlbSAw
MDowNTogW2lvICAweDA4MDAtMHgwODlmXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDMuNjQx
MTU1XSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwYjAwLTB4MGIwZl0gaGFzIGJlZW4gcmVzZXJ2ZWQN
Cg0KWyAgICAzLjY0NzEzNV0gc3lzdGVtIDAwOjA1OiBbaW8gIDB4MGIyMC0weDBiM2ZdIGhhcyBi
ZWVuIHJlc2VydmVkDQoNClsgICAgMy42NTMxMTldIHN5c3RlbSAwMDowNTogW2lvICAweDA5MDAt
MHgwOTBmXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDMuNjU5MDk2XSBzeXN0ZW0gMDA6MDU6
IFtpbyAgMHgwOTEwLTB4MDkxZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjY2NTA3OF0g
c3lzdGVtIDAwOjA1OiBbbWVtIDB4ZmVjMDAwMDAtMHhmZWMwMGZmZl0gY291bGQgbm90IGJlIHJl
c2VydmVkDQoNClsgICAgMy42NzIwOTZdIHN5c3RlbSAwMDowNTogW21lbSAweGZlYzAxMDAwLTB4
ZmVjMDFmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZA0KDQpbICAgIDMuNjc5MTE4XSBzeXN0ZW0g
MDA6MDU6IFttZW0gMHhmZWRjMDAwMC0weGZlZGMwZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpb
ICAgIDMuNjg1NzkxXSBzeXN0ZW0gMDA6MDU6IFttZW0gMHhmZWUwMDAwMC0weGZlZTAwZmZmXSBo
YXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDMuNjkyNDY2XSBzeXN0ZW0gMDA6MDU6IFttZW0gMHhm
ZWQ4MDAwMC0weGZlZDhmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQNCg0KWyAgICAzLjY5OTQ4
NV0gc3lzdGVtIDAwOjA1OiBbbWVtIDB4ZmVjMTAwMDAtMHhmZWMxMGZmZl0gY291bGQgbm90IGJl
IHJlc2VydmVkDQoNClsgICAgMy43MDY1MDVdIHN5c3RlbSAwMDowNTogW21lbSAweGZmMDAwMDAw
LTB4ZmZmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAgMy43MTM4NjldIHBucDogUG5Q
IEFDUEk6IGZvdW5kIDYgZGV2aWNlcw0KDQpbICAgIDMuNzI1NTg0XSBQTS1UaW1lciBmYWlsZWQg
Y29uc2lzdGVuY3kgY2hlY2sgICgweGZmZmZmZikgLSBhYm9ydGluZy4NCg0KWyAgICAzLjczMTk2
OV0gTkVUOiBSZWdpc3RlcmVkIFBGX0lORVQgcHJvdG9jb2wgZmFtaWx5DQoNClsgICAgMy43MzY5
MzZdIElQIGlkZW50cyBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogNywgNTI0Mjg4
IGJ5dGVzLCBsaW5lYXIpDQoNClsgICAgMy43NDQ4NDBdIHRjcF9saXN0ZW5fcG9ydGFkZHJfaGFz
aCBoYXNoIHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiAzLCAzMjc2OCBieXRlcywgbGluZWFy
KQ0KDQpbICAgIDMuNzUzMjg5XSBUYWJsZS1wZXJ0dXJiIGhhc2ggdGFibGUgZW50cmllczogNjU1
MzYgKG9yZGVyOiA2LCAyNjIxNDQgYnl0ZXMsIGxpbmVhcikNCg0KWyAgICAzLjc2MTA5OV0gVENQ
IGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMzI3NjggKG9yZGVyOiA2LCAyNjIxNDQg
Ynl0ZXMsIGxpbmVhcikNCg0KWyAgICAzLjc2OTA4MF0gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRy
aWVzOiAzMjc2OCAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMsIGxpbmVhcikNCg0KWyAgICAzLjc3
NjU3Nl0gVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAzMjc2OCBiaW5k
IDMyNzY4KQ0KDQpbICAgIDMuNzgzMTE1XSBVRFAgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChv
cmRlcjogNCwgNjU1MzYgYnl0ZXMsIGxpbmVhcikNCg0KWyAgICAzLjc4OTg2MV0gVURQLUxpdGUg
aGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChvcmRlcjogNCwgNjU1MzYgYnl0ZXMsIGxpbmVhcikN
Cg0KWyAgICAzLjc5NzA3NF0gTkVUOiBSZWdpc3RlcmVkIFBGX1VOSVgvUEZfTE9DQUwgcHJvdG9j
b2wgZmFtaWx5DQoNClsgICAgMy44MDMzMjddIFJQQzogUmVnaXN0ZXJlZCBuYW1lZCBVTklYIHNv
Y2tldCB0cmFuc3BvcnQgbW9kdWxlLg0KDQpbICAgIDMuODA5MTc4XSBSUEM6IFJlZ2lzdGVyZWQg
dWRwIHRyYW5zcG9ydCBtb2R1bGUuDQoNClsgICAgMy44MTM5NDBdIFJQQzogUmVnaXN0ZXJlZCB0
Y3AgdHJhbnNwb3J0IG1vZHVsZS4NCg0KWyAgICAzLjgxODcwNF0gUlBDOiBSZWdpc3RlcmVkIHRj
cC13aXRoLXRscyB0cmFuc3BvcnQgbW9kdWxlLg0KDQpbICAgIDMuODI0MjUwXSBSUEM6IFJlZ2lz
dGVyZWQgdGNwIE5GU3Y0LjEgYmFja2NoYW5uZWwgdHJhbnNwb3J0IG1vZHVsZS4NCg0KWyAgICAz
LjgzMTM4M10gcGNpIDAwMDA6MDA6MDIuMTogUENJIGJyaWRnZSB0byBbYnVzIDAxXQ0KDQpbICAg
IDMuODM2MzAxXSBwY2kgMDAwMDowMDowMi4xOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZmZTAw
MDAwMDAtMHhmZmY4MGZmZmZmIDY0Yml0IHByZWZdDQoNClsgICAgMy44NDQ0MzJdIHBjaSAwMDAw
OjAwOjAyLjM6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMl0NCg0KWyAgICAzLjg0OTQ1Nl0gcGNpIDAw
MDA6MDA6MDIuMzogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZWEwMDAwMC0weGZlYWZmZmZmXQ0K
DQpbICAgIDMuODU2MzEwXSBwY2kgMDAwMDowMDowMi40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDNd
DQoNClsgICAgMy44NjEzMjhdIHBjaSAwMDAwOjAwOjAyLjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8g
IDB4ZjAwMC0weGZmZmZdDQoNClsgICAgMy44Njc0OTBdIHBjaSAwMDAwOjAwOjAyLjQ6ICAgYnJp
ZGdlIHdpbmRvdyBbbWVtIDB4ZmU5MDAwMDAtMHhmZTlmZmZmZl0NCg0KWyAgICAzLjg3NDMzOV0g
cGNpIDAwMDA6MDA6MDguMTogUENJIGJyaWRnZSB0byBbYnVzIDA0XQ0KDQpbICAgIDMuODc5MzU4
XSBwY2kgMDAwMDowMDowOC4xOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZmXQ0K
DQpbICAgIDMuODg1NTI3XSBwY2kgMDAwMDowMDowOC4xOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAw
eGZlNDAwMDAwLTB4ZmU3ZmZmZmZdDQoNClsgICAgMy44OTIzNjZdIHBjaSAwMDAwOjAwOjA4LjE6
ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDAwMDAwMDAtMHhlMDFmZmZmZiA2NGJpdCBwcmVmXQ0K
DQpbICAgIDMuOTAwMTY3XSBwY2kgMDAwMDowMDowOC4yOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDVd
DQoNClsgICAgMy45MDUxOTJdIHBjaSAwMDAwOjAwOjA4LjI6ICAgYnJpZGdlIHdpbmRvdyBbbWVt
IDB4ZmU4MDAwMDAtMHhmZThmZmZmZl0NCg0KWyAgICAzLjkxMjA0NF0gcGNpX2J1cyAwMDAwOjAw
OiByZXNvdXJjZSA0IFtpbyAgMHgwMDAwLTB4MDNhZiB3aW5kb3ddDQoNClsgICAgMy45MTgyNzJd
IHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNSBbaW8gIDB4MDNlMC0weDBjZjcgd2luZG93XQ0K
DQpbICAgIDMuOTI0NTE2XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDYgW2lvICAweDAzYjAt
MHgwM2RmIHdpbmRvd10NCg0KWyAgICAzLjkzMDc1M10gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJj
ZSA3IFtpbyAgMHgwZDAwLTB4ZmZmZiB3aW5kb3ddDQoNClsgICAgMy45MzY5OTBdIHBjaV9idXMg
MDAwMDowMDogcmVzb3VyY2UgOCBbbWVtIDB4MDAwYTAwMDAtMHgwMDBkZmZmZiB3aW5kb3ddDQoN
ClsgICAgMy45NDM5MjddIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgOSBbbWVtIDB4ZDAwMDAw
MDAtMHhmZWJmZmZmZiB3aW5kb3ddDQoNClsgICAgMy45NTA4NjFdIHBjaV9idXMgMDAwMDowMDog
cmVzb3VyY2UgMTAgW21lbSAweGZlZTAwMDAwLTB4ZmZmZmZmZmYgd2luZG93XQ0KDQpbICAgIDMu
OTU3ODc2XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDExIFttZW0gMHg4MzAwMDAwMDAtMHhm
ZmZmZmZmZmZmIHdpbmRvd10NCg0KWyAgICAzLjk2NTE2NF0gcGNpX2J1cyAwMDAwOjAxOiByZXNv
dXJjZSAyIFttZW0gMHhmZmUwMDAwMDAwLTB4ZmZmODBmZmZmZiA2NGJpdCBwcmVmXQ0KDQpbICAg
IDMuOTcyNzg5XSBwY2lfYnVzIDAwMDA6MDI6IHJlc291cmNlIDEgW21lbSAweGZlYTAwMDAwLTB4
ZmVhZmZmZmZdDQoNClsgICAgMy45NzkxMTVdIHBjaV9idXMgMDAwMDowMzogcmVzb3VyY2UgMCBb
aW8gIDB4ZjAwMC0weGZmZmZdDQoNClsgICAgMy45ODQ3NDNdIHBjaV9idXMgMDAwMDowMzogcmVz
b3VyY2UgMSBbbWVtIDB4ZmU5MDAwMDAtMHhmZTlmZmZmZl0NCg0KWyAgICAzLjk5MTA2OV0gcGNp
X2J1cyAwMDAwOjA0OiByZXNvdXJjZSAwIFtpbyAgMHhlMDAwLTB4ZWZmZl0NCg0KWyAgICAzLjk5
NjcwNl0gcGNpX2J1cyAwMDAwOjA0OiByZXNvdXJjZSAxIFttZW0gMHhmZTQwMDAwMC0weGZlN2Zm
ZmZmXQ0KDQpbICAgIDQuMDAzMDM0XSBwY2lfYnVzIDAwMDA6MDQ6IHJlc291cmNlIDIgW21lbSAw
eGQwMDAwMDAwLTB4ZTAxZmZmZmYgNjRiaXQgcHJlZl0NCg0KWyAgICA0LjAxMDMxMF0gcGNpX2J1
cyAwMDAwOjA1OiByZXNvdXJjZSAxIFttZW0gMHhmZTgwMDAwMC0weGZlOGZmZmZmXQ0KDQpbICAg
IDQuMDE2ODAzXSBwY2kgMDAwMDowMTowMC4wOiBDTFMgbWlzbWF0Y2ggKDY0ICE9IDQ4NCksIHVz
aW5nIDY0IGJ5dGVzDQoNClsgICAgNC4wMjMyODVdIHBjaSAwMDAwOjA0OjAwLjE6IEQwIHBvd2Vy
IHN0YXRlIGRlcGVuZHMgb24gMDAwMDowNDowMC4wDQoNClsgICAgNC4wMjk2NzddIHBjaSAwMDAw
OjA0OjAwLjM6IGV4dGVuZGluZyBkZWxheSBhZnRlciBwb3dlci1vbiBmcm9tIEQzaG90IHRvIDIw
IG1zZWMNCg0KWyAgICA0LjAzNzQ3Nl0gcGNpIDAwMDA6MDQ6MDAuNDogZXh0ZW5kaW5nIGRlbGF5
IGFmdGVyIHBvd2VyLW9uIGZyb20gRDNob3QgdG8gMjAgbXNlYw0KDQpbICAgIDQuMDQ1MDQ1XSBQ
Q0ktRE1BOiBVc2luZyBzb2Z0d2FyZSBib3VuY2UgYnVmZmVyaW5nIGZvciBJTyAoU1dJT1RMQikN
Cg0KWyAgICA0LjA0NTQ3Ml0gVW5wYWNraW5nIGluaXRyYW1mcy4uLg0KDQpbICAgIDQuMDUxNDY2
XSBzb2Z0d2FyZSBJTyBUTEI6IG1hcHBlZCBbbWVtIDB4MDAwMDAwMDBjNmJjOTAwMC0weDAwMDAw
MDAwY2FiYzkwMDBdICg2NE1CKQ0KDQpbICAgIDQuMDUxNDg1XSBjbG9ja3NvdXJjZTogdHNjOiBt
YXNrOiAweGZmZmZmZmZmZmZmZmZmZmYgbWF4X2N5Y2xlczogMHgyOWI5Mjg5ODYwMiwgbWF4X2lk
bGVfbnM6IDQ0MDc5NTM0OTkzMCBucw0KDQpbICAgIDQuMDczMDE2XSBjbG9ja3NvdXJjZTogU3dp
dGNoZWQgdG8gY2xvY2tzb3VyY2UgdHNjDQoNClsgICAgNC4wNzkxMjldIEluaXRpYWxpc2Ugc3lz
dGVtIHRydXN0ZWQga2V5cmluZ3MNCg0KWyAgICA0LjA4MzY0M10gd29ya2luZ3NldDogdGltZXN0
YW1wX2JpdHM9NTYgbWF4X29yZGVyPTIwIGJ1Y2tldF9vcmRlcj0wDQoNClsgICAgNC4wOTAxOTRd
IE5GUzogUmVnaXN0ZXJpbmcgdGhlIGlkX3Jlc29sdmVyIGtleSB0eXBlDQoNClsgICAgNC4wOTUx
OTVdIEtleSB0eXBlIGlkX3Jlc29sdmVyIHJlZ2lzdGVyZWQNCg0KWyAgICA0LjA5OTQyOF0gS2V5
IHR5cGUgaWRfbGVnYWN5IHJlZ2lzdGVyZWQNCg0KWyAgICA0LjEwMzU3Ml0gOXA6IEluc3RhbGxp
bmcgdjlmcyA5cDIwMDAgZmlsZSBzeXN0ZW0gc3VwcG9ydA0KDQpbICAgIDQuMTE4MzA2XSBLZXkg
dHlwZSBhc3ltbWV0cmljIHJlZ2lzdGVyZWQNCg0KWyAgICA0LjEyMjM1MF0gQXN5bW1ldHJpYyBr
ZXkgcGFyc2VyICd4NTA5JyByZWdpc3RlcmVkDQoNClsgICAgNC4xMjUwOTddIEZyZWVpbmcgaW5p
dHJkIG1lbW9yeTogMjA3Njk2Sw0KDQpbICAgIDQuMTI3MzExXSBCbG9jayBsYXllciBTQ1NJIGdl
bmVyaWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxvYWRlZCAobWFqb3IgMjUwKQ0KDQpbICAg
IDQuMTM4OTEwXSBpbyBzY2hlZHVsZXIgbXEtZGVhZGxpbmUgcmVnaXN0ZXJlZA0KDQpbICAgIDQu
MTQzNDg1XSBpbyBzY2hlZHVsZXIga3liZXIgcmVnaXN0ZXJlZA0KDQpbICAgIDQuMTQ3OTk4XSBw
Y2llcG9ydCAwMDAwOjAwOjAyLjE6IFBNRTogU2lnbmFsaW5nIHdpdGggSVJRIDQzDQoNClsgICAg
NC4xNTM5NjFdIHBjaWVwb3J0IDAwMDA6MDA6MDIuMzogUE1FOiBTaWduYWxpbmcgd2l0aCBJUlEg
NDQNCg0KWyAgICA0LjE1OTg5MV0gcGNpZXBvcnQgMDAwMDowMDowMi40OiBQTUU6IFNpZ25hbGlu
ZyB3aXRoIElSUSA0NQ0KDQpbICAgIDQuMTY1ODI0XSBwY2llcG9ydCAwMDAwOjAwOjA4LjE6IFBN
RTogU2lnbmFsaW5nIHdpdGggSVJRIDQ2DQoNClsgICAgNC4xNzE3ODBdIHBjaWVwb3J0IDAwMDA6
MDA6MDguMjogUE1FOiBTaWduYWxpbmcgd2l0aCBJUlEgNDcNCg0KWyAgICA0LjE3NzY3OV0gaW5w
dXQ6IFBvd2VyIEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhTWUJVUzowMC9QTlAw
QzBDOjAwL2lucHV0L2lucHV0MA0KDQpbICAgIDQuMTg1OTc3XSBBQ1BJOiBidXR0b246IFBvd2Vy
IEJ1dHRvbiBbUFdSQl0NCg0KWyAgICA0LjE5MDM5NV0gaW5wdXQ6IFBvd2VyIEJ1dHRvbiBhcyAv
ZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhQV1JCTjowMC9pbnB1dC9pbnB1dDENCg0KWyAgICA0LjE5
Nzg3Nl0gQUNQSTogYnV0dG9uOiBQb3dlciBCdXR0b24gW1BXUkZdDQoNClsgICAgNC4yMDIyODFd
IEFDUEk6IHZpZGVvOiBWaWRlbyBEZXZpY2UgW1ZHQV0gKG11bHRpLWhlYWQ6IHllcyAgcm9tOiBu
byAgcG9zdDogbm8pDQoNClsgICAgNC4yMDk3ODRdIGlucHV0OiBWaWRlbyBCdXMgYXMgL2Rldmlj
ZXMvTE5YU1lTVE06MDAvTE5YU1lCVVM6MDAvUE5QMEEwODowMC9kZXZpY2U6MGUvTE5YVklERU86
MDAvaW5wdXQvaW5wdXQyDQoNClsgICAgNC4yMjAxNTNdIFtGaXJtd2FyZSBCdWddOiBBQ1BJIE1X
QUlUIEMtc3RhdGUgMHgwIG5vdCBzdXBwb3J0ZWQgYnkgSFcgKDB4MCkNCg0KWyAgICA0LjIyNzE0
MV0gQUNQSTogXF9TQl8uUExURi5QMDAwOiBGb3VuZCAzIGlkbGUgc3RhdGVzDQoNClsgICAgNC4y
MzI0MTZdIFtGaXJtd2FyZSBCdWddOiBBQ1BJIE1XQUlUIEMtc3RhdGUgMHgwIG5vdCBzdXBwb3J0
ZWQgYnkgSFcgKDB4MCkNCg0KWyAgICA0LjIzOTQ0NV0gQUNQSTogXF9TQl8uUExURi5QMDAxOiBG
b3VuZCAzIGlkbGUgc3RhdGVzDQoNClsgICAgNC4yNDQ2OTRdIFtGaXJtd2FyZSBCdWddOiBBQ1BJ
IE1XQUlUIEMtc3RhdGUgMHgwIG5vdCBzdXBwb3J0ZWQgYnkgSFcgKDB4MCkNCg0KWyAgICA0LjI1
MTc1MV0gQUNQSTogXF9TQl8uUExURi5QMDAyOiBGb3VuZCAzIGlkbGUgc3RhdGVzDQoNClsgICAg
NC4yNTcyNzldIHRoZXJtYWwgTE5YVEhFUk06MDA6IHJlZ2lzdGVyZWQgYXMgdGhlcm1hbF96b25l
MA0KDQpbICAgIDQuMjYyODc3XSBBQ1BJOiB0aGVybWFsOiBUaGVybWFsIFpvbmUgW1RIUk1dICgy
MCBDKQ0KDQpbICAgIDQuMjY4MDU3XSB0aGVybWFsIExOWFRIRVJNOjAxOiByZWdpc3RlcmVkIGFz
IHRoZXJtYWxfem9uZTENCg0KWyAgICA0LjI3MzY5Nl0gQUNQSTogdGhlcm1hbDogVGhlcm1hbCBa
b25lIFtXRFRGXSAoMCBDKQ0KDQpbICAgIDQuMjc5MTYxXSB4ZW46eGVuX2V2dGNobjogRXZlbnQt
Y2hhbm5lbCBkZXZpY2UgaW5zdGFsbGVkDQoNClsgICAgNC4yODQ3MDFdIHhlbl9tY2Vsb2c6IEZh
aWxlZCB0byBnZXQgQ1BVIG51bWJlcnMNCg0KWyAgICA0LjI4OTM4Nl0geGVuX3BjaWJhY2s6IGJh
Y2tlbmQgaXMgdnBjaQ0KDQpbICAgIDQuMjkzNTA2XSB4ZW5fYWNwaV9wcm9jZXNzb3I6IFVwbG9h
ZGluZyBYZW4gcHJvY2Vzc29yIFBNIGluZm8NCg0KWyAgICA0LjMwMDI4NF0gU2VyaWFsOiA4MjUw
LzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZA0KDQpbICAgIDQuMzA2
NjQxXSAwMDowNDogdHR5UzEgYXQgSS9PIDB4MmY4IChpcnEgPSAzLCBiYXNlX2JhdWQgPSAxMTUy
MDApIGlzIGEgMTY1NTBBDQoNClsgICAgNC4zMTQyMTFdIGhwZXRfYWNwaV9hZGQ6IG5vIGFkZHJl
c3Mgb3IgaXJxcyBpbiBfQ1JTDQoNClsgICAgNC4zMTkyNDNdIE5vbi12b2xhdGlsZSBtZW1vcnkg
ZHJpdmVyIHYxLjMNCg0KWyAgICA0LjMyMzQ0OF0gTGludXggYWdwZ2FydCBpbnRlcmZhY2UgdjAu
MTAzDQoNClsgICAgNC4zMjc5OTRdIEFDUEk6IGJ1cyB0eXBlIGRybV9jb25uZWN0b3IgcmVnaXN0
ZXJlZA0KDQpbICAgIDQuMzM0MDI4XSBsb29wOiBtb2R1bGUgbG9hZGVkDQoNClsgICAgNC4zMzc0
NDldIGFoY2kgMDAwMDowNTowMC4wOiB2ZXJzaW9uIDMuMA0KDQpbICAgIDQuMzM3NTY4XSBudm1l
IG52bWUwOiBwY2kgZnVuY3Rpb24gMDAwMDowMjowMC4wDQoNClsgICAgNC4zNDE2NTRdIGFoY2kg
MDAwMDowNTowMC4wOiBBSENJIHZlcnMgMDAwMS4wMzAxLCAzMiBjb21tYW5kIHNsb3RzLCA2IEdi
cHMsIFNBVEEgbW9kZQ0KDQpbICAgIDQuMzUzMDMwXSBudm1lIG52bWUwOiBtaXNzaW5nIG9yIGlu
dmFsaWQgU1VCTlFOIGZpZWxkLg0KDQpbICAgIDQuMzU0MzAyXSBhaGNpIDAwMDA6MDU6MDAuMDog
MS8xIHBvcnRzIGltcGxlbWVudGVkIChwb3J0IG1hc2sgMHgxKQ0KDQpbICAgIDQuMzU0MzA0XSBh
aGNpIDAwMDA6MDU6MDAuMDogZmxhZ3M6IDY0Yml0IG5jcSBzbnRmIGlsY2sgcG0gbGVkIGNsbyBv
bmx5IHBtcCBmYnMgcGlvIHNsdW0gcGFydA0KDQpbICAgIDQuMzU0NTQwXSBzY3NpIGhvc3QwOiBh
aGNpDQoNClsgICAgNC4zNjYxMDldIG52bWUgbnZtZTA6IEQzIGVudHJ5IGxhdGVuY3kgc2V0IHRv
IDggc2Vjb25kcw0KDQpbICAgIDQuMzc0OTU2XSBhdGExOiBTQVRBIG1heCBVRE1BLzEzMyBhYmFy
IG0yMDQ4QDB4ZmU4MDEwMDAgcG9ydCAweGZlODAxMTAwIGlycSA1MCBscG0tcG9sIDMNCg0KWyAg
ICA0LjM5MTgxMF0gYWhjaSAwMDAwOjA1OjAwLjE6IEFIQ0kgdmVycyAwMDAxLjAzMDEsIDMyIGNv
bW1hbmQgc2xvdHMsIDYgR2JwcywgU0FUQSBtb2RlDQoNClsgICAgNC4zOTk3NDVdIGFoY2kgMDAw
MDowNTowMC4xOiAxLzEgcG9ydHMgaW1wbGVtZW50ZWQgKHBvcnQgbWFzayAweDEpDQoNClsgICAg
NC40MDYxNTddIGFoY2kgMDAwMDowNTowMC4xOiBmbGFnczogNjRiaXQgbmNxIHNudGYgaWxjayBw
bSBsZWQgY2xvIG9ubHkgcG1wIGZicyBwaW8gc2x1bSBwYXJ0DQoNClsgICAgNC40MTUyNTFdIHNj
c2kgaG9zdDE6IGFoY2kNCg0KWyAgICA0LjQxODEwMF0gYXRhMjogU0FUQSBtYXggVURNQS8xMzMg
YWJhciBtMjA0OEAweGZlODAwMDAwIHBvcnQgMHhmZTgwMDEwMCBpcnEgNTQgbHBtLXBvbCAzDQoN
ClsgICAgNC40MjY2ODFdIFJvdW5kaW5nIGRvd24gYWxpZ25lZCBtYXhfc2VjdG9ycyBmcm9tIDQy
OTQ5NjcyOTUgdG8gNDI5NDk2NzI4OA0KDQpbICAgIDQuNDMzNjgxXSBkYl9yb290OiBjYW5ub3Qg
b3BlbjogL2V0Yy90YXJnZXQNCg0KWyAgICA0LjQzODA5MV0gdHVuOiBVbml2ZXJzYWwgVFVOL1RB
UCBkZXZpY2UgZHJpdmVyLCAxLjYNCg0KWyAgICA0LjQ0MzE3N10gZTEwMDogSW50ZWwoUikgUFJP
LzEwMCBOZXR3b3JrIERyaXZlcg0KDQpbICAgIDQuNDQzMjc5XSBudm1lIG52bWUwOiA0LzAvMCBk
ZWZhdWx0L3JlYWQvcG9sbCBxdWV1ZXMNCg0KWyAgICA0LjQ0Nzg2N10gZTEwMDogQ29weXJpZ2h0
KGMpIDE5OTktMjAwNiBJbnRlbCBDb3Jwb3JhdGlvbg0KDQpbICAgIDQuNDQ3ODczXSBlMTAwMDog
SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBEcml2ZXINCg0KWyAgICA0LjQ2MzU2M10gZTEwMDA6
IENvcHlyaWdodCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBvcmF0aW9uLg0KDQpbICAgIDQuNDY5
MzgyXSBlMTAwMGU6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgRHJpdmVyDQoNClsgICAgNC40
NzQzOTRdIGUxMDAwZTogQ29weXJpZ2h0KGMpIDE5OTkgLSAyMDE1IEludGVsIENvcnBvcmF0aW9u
Lg0KDQpbICAgIDQuNDgwMzg2XSBJbnRlbChSKSAyLjVHIEV0aGVybmV0IExpbnV4IERyaXZlcg0K
DQpbICAgIDQuNDgyMzA5XSAgbnZtZTBuMTogcDEgcDINCg0KWyAgICA0LjQ4NDk2M10gQ29weXJp
Z2h0KGMpIDIwMTggSW50ZWwgQ29ycG9yYXRpb24uDQoNClsgICAgNC40OTI1MTFdIHNreTI6IGRy
aXZlciB2ZXJzaW9uIDEuMzANCg0KWyAgICA0LjUwNDExMV0gbW9kcHJvYmUgKDc2KSB1c2VkIGdy
ZWF0ZXN0IHN0YWNrIGRlcHRoOiAxMzczNiBieXRlcyBsZWZ0DQoNClsgICAgNC41MDQ0NjJdIHI4
MTY5IDAwMDA6MDM6MDAuMCBldGgwOiBSVEw4MTI1QiwgZGM6OWM6NTI6Mjc6YWU6YzQsIFhJRCA2
NDEsIElSUSA2MA0KDQpbICAgIDQuNTE4MDMxXSByODE2OSAwMDAwOjAzOjAwLjAgZXRoMDoganVt
Ym8gZmVhdHVyZXMgW2ZyYW1lczogOTE5NCBieXRlcywgdHggY2hlY2tzdW1taW5nOiBrb10NCg0K
WyAgICA0LjUyNjYyMl0geGVuX25ldGZyb250OiBJbml0aWFsaXNpbmcgWGVuIHZpcnR1YWwgZXRo
ZXJuZXQgZHJpdmVyDQoNClsgICAgNC41MzMwMjhdIHhoY2lfaGNkIDAwMDA6MDQ6MDAuMzogeEhD
SSBIb3N0IENvbnRyb2xsZXINCg0KWyAgICA0LjUzODI2MV0geGhjaV9oY2QgMDAwMDowNDowMC4z
OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDENCg0KWyAgICA0
LjU0NTcyNl0geGhjaV9oY2QgMDAwMDowNDowMC4zOiBoY2MgcGFyYW1zIDB4MDI2OGZmZTUgaGNp
IHZlcnNpb24gMHgxMTAgcXVpcmtzIDB4MDAwMDAyMDAwMDAwMDAxMA0KDQpbICAgIDQuNTU1MTM5
XSB4aGNpX2hjZCAwMDAwOjA0OjAwLjM6IHhIQ0kgSG9zdCBDb250cm9sbGVyDQoNClsgICAgNC41
NjAzNjRdIHhoY2lfaGNkIDAwMDA6MDQ6MDAuMzogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNz
aWduZWQgYnVzIG51bWJlciAyDQoNClsgICAgNC41Njc3NTVdIHhoY2lfaGNkIDAwMDA6MDQ6MDAu
MzogSG9zdCBzdXBwb3J0cyBVU0IgMy4xIEVuaGFuY2VkIFN1cGVyU3BlZWQNCg0KWyAgICA0LjU3
NDk4MF0gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFBy
b2R1Y3Q9MDAwMiwgYmNkRGV2aWNlPSA2LjExDQoNClsgICAgNC41ODMxNzJdIHVzYiB1c2IxOiBO
ZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0K
DQpbICAgIDQuNTkwNDQ2XSB1c2IgdXNiMTogUHJvZHVjdDogeEhDSSBIb3N0IENvbnRyb2xsZXIN
Cg0KWyAgICA0LjU5NTM4OV0gdXNiIHVzYjE6IE1hbnVmYWN0dXJlcjogTGludXggNi4xMS4wIHho
Y2ktaGNkDQoNClsgICAgNC42MDA4NDldIHVzYiB1c2IxOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDQ6
MDAuMw0KDQpbICAgIDQuNjA1Njc2XSBodWIgMS0wOjEuMDogVVNCIGh1YiBmb3VuZA0KDQpbICAg
IDQuNjA5Mzg3XSBodWIgMS0wOjEuMDogNCBwb3J0cyBkZXRlY3RlZA0KDQpbICAgIDQuNjEzNjQ3
XSB1c2IgdXNiMjogV2UgZG9uJ3Qga25vdyB0aGUgYWxnb3JpdGhtcyBmb3IgTFBNIGZvciB0aGlz
IGhvc3QsIGRpc2FibGluZyBMUE0uDQoNClsgICAgNC42MjE3NjldIHVzYiB1c2IyOiBOZXcgVVNC
IGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDMsIGJjZERldmljZT0g
Ni4xMQ0KDQpbICAgIDQuNjI5OTgyXSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczog
TWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENCg0KWyAgICA0LjYzNzI2MF0gdXNiIHVz
YjI6IFByb2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyDQoNClsgICAgNC42NDIyMDBdIHVzYiB1
c2IyOiBNYW51ZmFjdHVyZXI6IExpbnV4IDYuMTEuMCB4aGNpLWhjZA0KDQpbICAgIDQuNjQ3NjU5
XSB1c2IgdXNiMjogU2VyaWFsTnVtYmVyOiAwMDAwOjA0OjAwLjMNCg0KWyAgICA0LjY1MjU5M10g
aHViIDItMDoxLjA6IFVTQiBodWIgZm91bmQNCg0KWyAgICA0LjY1NjI4NV0gaHViIDItMDoxLjA6
IDIgcG9ydHMgZGV0ZWN0ZWQNCg0KWyAgICA0LjY2MDQ3NF0geGhjaV9oY2QgMDAwMDowNDowMC40
OiB4SENJIEhvc3QgQ29udHJvbGxlcg0KDQpbICAgIDQuNjY1NjkxXSB4aGNpX2hjZCAwMDAwOjA0
OjAwLjQ6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMw0KDQpb
ICAgIDQuNjczMTgzXSB4aGNpX2hjZCAwMDAwOjA0OjAwLjQ6IGhjYyBwYXJhbXMgMHgwMjY4ZmZl
NSBoY2kgdmVyc2lvbiAweDExMCBxdWlya3MgMHgwMDAwMDIwMDAwMDAwMDEwDQoNClsgICAgNC42
ODI1OTVdIHhoY2lfaGNkIDAwMDA6MDQ6MDAuNDogeEhDSSBIb3N0IENvbnRyb2xsZXINCg0KWyAg
ICA0LjY4Nzc5M10geGhjaV9oY2QgMDAwMDowNDowMC40OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVk
LCBhc3NpZ25lZCBidXMgbnVtYmVyIDQNCg0KWyAgICA0LjY5NTIxN10geGhjaV9oY2QgMDAwMDow
NDowMC40OiBIb3N0IHN1cHBvcnRzIFVTQiAzLjEgRW5oYW5jZWQgU3VwZXJTcGVlZA0KDQpbICAg
IDQuNzAwNjc2XSBhdGExOiBTQVRBIGxpbmsgZG93biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkN
Cg0KWyAgICA0LjcwMjMyNF0gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRv
cj0xZDZiLCBpZFByb2R1Y3Q9MDAwMiwgYmNkRGV2aWNlPSA2LjExDQoNClsgICAgNC43MTYxMDFd
IHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJp
YWxOdW1iZXI9MQ0KDQpbICAgIDQuNzIzMzY2XSB1c2IgdXNiMzogUHJvZHVjdDogeEhDSSBIb3N0
IENvbnRyb2xsZXINCg0KWyAgICA0LjcyODMwNF0gdXNiIHVzYjM6IE1hbnVmYWN0dXJlcjogTGlu
dXggNi4xMS4wIHhoY2ktaGNkDQoNClsgICAgNC43MzM3NzFdIHVzYiB1c2IzOiBTZXJpYWxOdW1i
ZXI6IDAwMDA6MDQ6MDAuNA0KDQpbICAgIDQuNzM1NzU2XSBhdGEyOiBTQVRBIGxpbmsgZG93biAo
U1N0YXR1cyAwIFNDb250cm9sIDMwMCkNCg0KWyAgICA0LjczODUyNl0gaHViIDMtMDoxLjA6IFVT
QiBodWIgZm91bmQNCg0KWyAgICA0Ljc0NzczNF0gaHViIDMtMDoxLjA6IDQgcG9ydHMgZGV0ZWN0
ZWQNCg0KWyAgICA0Ljc1MTg2NF0gdXNiIHVzYjQ6IFdlIGRvbid0IGtub3cgdGhlIGFsZ29yaXRo
bXMgZm9yIExQTSBmb3IgdGhpcyBob3N0LCBkaXNhYmxpbmcgTFBNLg0KDQpbICAgIDQuNzU5OTU0
XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVj
dD0wMDAzLCBiY2REZXZpY2U9IDYuMTENCg0KWyAgICA0Ljc2ODI2MV0gdXNiIHVzYjQ6IE5ldyBV
U0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQoNClsg
ICAgNC43NzU1NDhdIHVzYiB1c2I0OiBQcm9kdWN0OiB4SENJIEhvc3QgQ29udHJvbGxlcg0KDQpb
ICAgIDQuNzgwNDg1XSB1c2IgdXNiNDogTWFudWZhY3R1cmVyOiBMaW51eCA2LjExLjAgeGhjaS1o
Y2QNCg0KWyAgICA0Ljc4NTk1MF0gdXNiIHVzYjQ6IFNlcmlhbE51bWJlcjogMDAwMDowNDowMC40
DQoNClsgICAgNC43OTExNzNdIGh1YiA0LTA6MS4wOiBVU0IgaHViIGZvdW5kDQoNClsgICAgNC43
OTQ4NzldIGh1YiA0LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQoNClsgICAgNC43OTkxMDNdIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNibHANCg0KWyAgICA0Ljgw
NDUzOF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Itc3RvcmFn
ZQ0KDQpbICAgIDQuODExMTY0XSBpODA0MjogUE5QOiBObyBQUy8yIGNvbnRyb2xsZXIgZm91bmQu
DQoNClsgICAgNC44MTU4MDBdIGk4MDQyOiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5Lg0KDQpbICAg
IDQuODIwODM3XSBpODA0MjogTm8gY29udHJvbGxlciBmb3VuZA0KDQpbICAgIDQuODI0NzI5XSBy
dGNfY21vcyAwMDowMTogUlRDIGNhbiB3YWtlIGZyb20gUzQNCg0KWyAgICA0LjgyOTQxNF0gcnRj
X2Ntb3MgMDA6MDE6IHJlZ2lzdGVyZWQgYXMgcnRjMA0KDQpbICAgIDQuODMzODMwXSBydGNfY21v
cyAwMDowMTogbm8gYWxhcm1zLCB5M2ssIDExNCBieXRlcyBudnJhbQ0KDQpbICAgIDQuODM5NDQ4
XSBmYWlsIHRvIGluaXRpYWxpemUgcHRwX2t2bQ0KDQpbICAgIDQuODM5OTk5XSB4ZW5fd2R0IHhl
bl93ZHQ6IGluaXRpYWxpemVkICh0aW1lb3V0PTYwcywgbm93YXlvdXQ9MCkNCg0KWyAgICA0Ljg1
MDI5MF0gZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuNDguMC1pb2N0bCAoMjAyMy0wMy0wMSkgaW5p
dGlhbGlzZWQ6IGRtLWRldmVsQGxpc3RzLmxpbnV4LmRldg0KDQpbICAgIDQuODU5MTczXSBhbWRf
cHN0YXRlOiBUaGUgQ1BQQyBmZWF0dXJlIGlzIHN1cHBvcnRlZCBidXQgY3VycmVudGx5IGRpc2Fi
bGVkIGJ5IHRoZSBCSU9TLg0KDQpbICAgIDQuODU5MTczXSBQbGVhc2UgZW5hYmxlIGl0IGlmIHlv
dXIgQklPUyBoYXMgdGhlIENQUEMgb3B0aW9uLg0KDQpbICAgIDQuODczMjIzXSBhbWRfcHN0YXRl
OiB0aGUgX0NQQyBvYmplY3QgaXMgbm90IHByZXNlbnQgaW4gU0JJT1Mgb3IgQUNQSSBkaXNhYmxl
ZA0KDQpbICAgIDQuODgwNzE2XSBoaWQ6IHJhdyBISUQgZXZlbnRzIGRyaXZlciAoQykgSmlyaSBL
b3NpbmENCg0KWyAgICA0Ljg4NTkzM10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciB1c2JoaWQNCg0KWyAgICA0Ljg5MTQ5N10gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJp
dmVyDQoNClsgICAgNC44OTU4NzVdIHNuZF9oZGFfaW50ZWwgMDAwMDowNDowMC4xOiBlbmFibGlu
ZyBkZXZpY2UgKDAwMDAgLT4gMDAwMikNCg0KKFhFTikgWyAgIDE0LjcyOTI1NV0gYXJjaC94ODYv
cGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4xOiBCQVIgYXQgW2ZlN2M4LCBmZTdjYl0gbm90IGlu
IG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDE0LjczODM1NV0gYXJjaC94ODYvcGNpLmM6MTA5
OmQwdjEgMDAwMDowNDowMC4xOiBCQVIgYXQgW2ZlN2M4LCBmZTdjYl0gbm90IGluIG1lbW9yeSBt
YXAgaG9sZQ0KWyAgICA0LjkyMDc3NV0gc25kX2hkYV9pbnRlbCAwMDAwOjA0OjAwLjY6IGVuYWJs
aW5nIGRldmljZSAoMDAwMCAtPiAwMDAyKQ0KDQooWEVOKSBbICAgMTQuNzU0MTYwXSBhcmNoL3g4
Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjY6IEJBUiBhdCBbZmU3YzAsIGZlN2M3XSBub3Qg
aW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTQuNzYzMjU4XSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZDB2MSAwMDAwOjA0OjAwLjY6IEJBUiBhdCBbZmU3YzAsIGZlN2M3XSBub3QgaW4gbWVtb3J5
IG1hcCBob2xlDQpbICAgIDQuOTQ2MTM3XSBJbml0aWFsaXppbmcgWEZSTSBuZXRsaW5rIHNvY2tl
dA0KDQpbICAgIDQuOTQ4Nzc4XSBzbmRfaGRhX2ludGVsIDAwMDA6MDQ6MDAuMTogQ2Fubm90IHBy
b2JlIGNvZGVjcywgZ2l2aW5nIHVwDQoNClsgICAgNC45NTAzNTddIE4oWEVOKSBbICAgMTQuNzg1
MjQ4XSBhcmNoL3g4Ni9odm0vdm1zaS5jOjg0NTpkMHYxIDAwMDA6MDQ6MDAuMTogUElSUSAzMzEz
OiB1bnN1cHBvcnRlZCBhZGRyZXNzIDANCkVUOiBSZWdpc3RlcmVkIFAoWEVOKSBbICAgMTQuNzk1
MTI2XSBhcmNoL3g4Ni9odm0vdm1zaS5jOjg0NTpkMHYxIDAwMDA6MDQ6MDAuMTogUElSUSAzMzEz
OiB1bnN1cHBvcnRlZCBhZGRyZXNzIDANCkZfSU5FVDYgcHJvdG9jb2woWEVOKSBbICAgMTQuODA1
MDA0XSBhcmNoL3g4Ni9odm0vdm1zaS5jOjg0NTpkMHYxIDAwMDA6MDQ6MDAuMTogUElSUSAzMzEz
OiB1bnN1cHBvcnRlZCBhZGRyZXNzIDANCiBmYW1pbHkNCg0KWyAgICA0Ljk4NzcwMV0gU2VnbWVu
dCBSb3V0aW5nIHdpdGggSVB2Ng0KDQpbICAgIDQuOTkxMzA3XSBJbi1zaXR1IE9BTSAoSU9BTSkg
d2l0aCBJUHY2DQoNClsgICAgNC45OTUzNjldIHNpdDogSVB2NiwgSVB2NCBhbmQgTVBMUyBvdmVy
IElQdjQgdHVubmVsaW5nIGRyaXZlcg0KDQpbICAgIDUuMDAxNDI0XSBORVQ6IFJlZ2lzdGVyZWQg
UEZfUEFDS0VUIHByb3RvY29sIGZhbWlseQ0KDQpbICAgIDUuMDA2NDIzXSA5cG5ldDogSW5zdGFs
bGluZyA5UDIwMDAgc3VwcG9ydA0KDQpbICAgIDUuMDEwNzYzXSBLZXkgdHlwZSBkbnNfcmVzb2x2
ZXIgcmVnaXN0ZXJlZA0KDQpbICAgIDUuMDEwNzc2XSB1c2IgMy00OiBuZXcgaGlnaC1zcGVlZCBV
U0IgZGV2aWNlIG51bWJlciAyIHVzaW5nIHhoY2lfaGNkDQoNClsgICAgNS4wMjE5MTldIElQSSBz
aG9ydGhhbmQgYnJvYWRjYXN0OiBlbmFibGVkDQoNClsgICAgNS4wMjc2NjVdIHNjaGVkX2Nsb2Nr
OiBNYXJraW5nIHN0YWJsZSAoNDk0NTAwODA2NywgODI1MDYyMTkpLT4oNjIzOTMyNDE3NSwgLTEy
MTE4MDk4ODkpDQoNClsgICAgNS4wMzU5NTBdIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24g
MQ0KDQpbICAgIDUuMDM5OTkxXSBMb2FkaW5nIGNvbXBpbGVkLWluIFguNTA5IGNlcnRpZmljYXRl
cw0KDQpbICAgIDUuMDQ1NTY3XSBEZW1vdGlvbiB0YXJnZXRzIGZvciBOb2RlIDA6IG51bGwNCg0K
WyAgICA1LjA0OTk4Nl0gUE06ICAgTWFnaWMgbnVtYmVyOiA5Ojc5MToyNTUNCg0KWyAgICA1LjA1
Mzk2NV0gbWVtb3J5IG1lbW9yeTEyOTogaGFzaCBtYXRjaGVzDQoNClsgICAgNS4wNTgxMDBdIHBy
aW50azogbGVnYWN5IGNvbnNvbGUgW25ldGNvbjBdIGVuYWJsZWQNCg0KWyAgICA1LjA2MzExNV0g
bmV0Y29uc29sZTogbmV0d29yayBsb2dnaW5nIHN0YXJ0ZWQNCg0KWyAgICA1LjA2ODI2MF0gY2Zn
ODAyMTE6IExvYWRpbmcgY29tcGlsZWQtaW4gWC41MDkgY2VydGlmaWNhdGVzIGZvciByZWd1bGF0
b3J5IGRhdGFiYXNlDQoNClsgICAgNS4wNzY3MTZdIG1vZHByb2JlICg4NSkgdXNlZCBncmVhdGVz
dCBzdGFjayBkZXB0aDogMTM2ODggYnl0ZXMgbGVmdA0KDQpbICAgIDUuMDc3MzQ4XSBMb2FkZWQg
WC41MDkgY2VydCAnc2ZvcnNoZWU6IDAwYjI4ZGRmNDdhZWY5Y2VhNycNCg0KWyAgICA1LjA4ODkx
NF0gTG9hZGVkIFguNTA5IGNlcnQgJ3dlbnM6IDYxYzAzODY1MWFhYmRjZjk0YmQwYWM3ZmYwNmM3
MjQ4ZGIxOGM2MDAnDQoNClsgICAgNS4wOTYxMDJdIHBsYXRmb3JtIHJlZ3VsYXRvcnkuMDogRGly
ZWN0IGZpcm13YXJlIGxvYWQgZm9yIHJlZ3VsYXRvcnkuZGIgZmFpbGVkIHdpdGggZXJyb3IgLTIN
Cg0KWyAgICA1LjEwMTU5MV0gQUxTQSBkZXZpY2UgbGlzdDoNCg0KWyAgICA1LjEwNDc1MV0gY2Zn
ODAyMTE6IGZhaWxlZCB0byBsb2FkIHJlZ3VsYXRvcnkuZGINCg0KWyAgICA1LjExMjYzM10gICBO
byBzb3VuZGNhcmRzIGZvdW5kLg0KDQpbICAgIDUuMTE2NTcxXSBGcmVlaW5nIHVudXNlZCBrZXJu
ZWwgaW1hZ2UgKGluaXRtZW0pIG1lbW9yeTogMjk4MEsNCg0KWyAgICA1LjEyMjQyMF0gV3JpdGUg
cHJvdGVjdGluZyB0aGUga2VybmVsIHJlYWQtb25seSBkYXRhOiAyODY3MmsNCg0KWyAgICA1LjEy
ODY0OF0gRnJlZWluZyB1bnVzZWQga2VybmVsIGltYWdlIChyb2RhdGEvZGF0YSBnYXApIG1lbW9y
eTogOTE2Sw0KDQpbICAgIDUuMTU5MTA0XSB1c2IgMy00OiBOZXcgVVNCIGRldmljZSBmb3VuZCwg
aWRWZW5kb3I9MDQwMywgaWRQcm9kdWN0PTYwMTEsIGJjZERldmljZT0gOC4wMA0KDQpbICAgIDUu
MTY3MjA5XSB1c2IgMy00OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVjdD0y
LCBTZXJpYWxOdW1iZXI9Mw0KDQpbICAgIDUuMTcxNTE4XSB4ODYvbW06IENoZWNrZWQgVytYIG1h
cHBpbmdzOiBwYXNzZWQsIG5vIFcrWCBwYWdlcyBmb3VuZC4NCg0KWyAgICA1LjE3NDQwMV0gdXNi
IDMtNDogUHJvZHVjdDogVkUyMzAyDQoNClsgICAgNS4xNzQ0MDJdIHVzYiAzLTQ6IE1hbnVmYWN0
dXJlcjogWGlsaW54DQoNClsgICAgNS4xNzQ0MDNdIHVzYiAzLTQ6IFNlcmlhbE51bWJlcjogNTJI
MjUxMTAwMDAxMg0KDQpbICAgIDUuMTkzMzE0XSBSdW4gL2Jpbi9zaCBhcyBpbml0IHByb2Nlc3MN
Cg0KWyAgICA1LjE5NzIwNl0gICB3aXRoIGFyZ3VtZW50czoNCg0KWyAgICA1LjIwMDIzM10gICAg
IC9iaW4vc2gNCg0KWyAgICA1LjIwMjc1Ml0gICB3aXRoIGVudmlyb25tZW50Og0KDQpbICAgIDUu
MjA1OTUzXSAgICAgSE9NRT0vDQoNClsgICAgNS4yMDgzODJdICAgICBURVJNPWxpbnV4DQoNCi9i
aW4vc2g6IGNhbid0IGFjY2VzcyB0dHk7IGpvYiBjb250cm9sIHR1cm5lZCBvZmYNCg0KfiAjIBtb
Nm5sIHMIG1tKCBtbSggbW0ptb3VudCAtdCBwcm9jIHByb2MgL3Byb2MNCg0KeXNmcyBzeXNmcyAv
c3lzWyAgIDM3LjY4NDMyOF0gbX4gIyBvdW50ICg5MCkgdXNlZCBnbXJlYXRlc3Qgc3RhY2sgZGVv
cHRoOiAxMzUyOCBieXRlc3UgbGVmdA0KDQpudCAtdCBzeXNmcyBzeXNmcyAvc3lzDQoNClsgICAz
Ny42OTM3MzZdIG1+ICMgb3VudCAoOTEpIHVzZWQgZ21yZWF0ZXN0IHN0YWNrIGRlb3B0aDogMTMz
MzYgYnl0ZXN1IGxlZnQNCg0KbnQgLXQgZGV2dG1wZnMgZGV2dG1wZnMgL2Rldg0KDQp+ICMgG1s2
bmxzIC9kZXYvbnZtKg0KDQobWzE7MzVtL2Rldi9udm1lMBtbbSAgICAgIBtbMTszNW0vZGV2L252
bWUwbjEbW20gICAgG1sxOzM1bS9kZXYvbnZtZTBuMXAxG1ttICAbWzE7MzVtL2Rldi9udm1lMG4x
cDIbW20NCg0KfiAjIBtbNm5tb3VudCAvZGV2L25tdggbW0oIG1tKdm1lMG4xcDEIG1tKMiAvbW50
DQoNClsgICA1MS43MjMzODVdIEVYVDQtZnMgKG52bWUwbjFwMik6IHJlY292ZXJ5IGNvbXBsZXRl
DQoNClsgICA1MS43MjgxNDVdIEVYVDQtZnMgKG52bWUwbjFwMik6IG1vdW50ZWQgZmlsZXN5c3Rl
bSAwYjVkYzQwYS0xMzk0LTQyYzgtYTNhMy1kOGU0OWJlZjgwM2Mgci93IHdpdGggb3JkZXJlZCBk
YXRhIG1vZGUuIFF1b3RhIG1vZGU6IG5vbmUuDQoNClsgICA1MS43NDAzMzVdIG1+ICMgG1s2bm91
bnQgKDk0KSB1c2VkIGdyZWF0ZXN0IHN0YWNrIGRlcHRoOiAxMzI2NCBieXRlcyBsZWZ0DQoNCmxz
IC9tbnQNCg0KG1sxOzM2bWJpbhtbbSAgICAgICAgIBtbMTszNG1ob21lG1ttICAgICAgICAbWzE7
MzRtbG9zdCtmb3VuZBtbbSAgG1sxOzM0bXJvb3QbW20gICAgICAgIBtbMDswbXN3YXBmaWxlG1tt
DQoNChtbMTszNG1ib290G1ttICAgICAgICAbWzE7MzZtbGliG1ttICAgICAgICAgG1sxOzM0bW1l
ZGlhG1ttICAgICAgIBtbMTszNG1ydW4bW20gICAgICAgICAbWzE7MzRtc3lzG1ttDQoNChtbMTsz
NG1jZHJvbRtbbSAgICAgICAbWzE7MzZtbGliMzIbW20gICAgICAgG1sxOzM0bW1udBtbbSAgICAg
ICAgIBtbMTszNm1zYmluG1ttICAgICAgICAbWzE7MzRtdG1wG1ttDQoNChtbMTszNG1kZXYbW20g
ICAgICAgICAbWzE7MzZtbGliNjQbW20gICAgICAgG1sxOzM0bW9wdBtbbSAgICAgICAgIBtbMTsz
NG1zbmFwG1ttICAgICAgICAbWzE7MzRtdXNyG1ttDQoNChtbMTszNG1ldGMbW20gICAgICAgICAb
WzE7MzZtbGlieDMyG1ttICAgICAgG1sxOzM0bXByb2MbW20gICAgICAgIBtbMTszNG1zcnYbW20g
ICAgICAgICAbWzE7MzRtdmFyG1ttDQoNClsgICA1My4zODM4NDldIGx+ICMgG1s2bnMgKDk4KSB1
c2VkIGdyZWF0ZXN0IHN0YWNrIGRlcHRoOiAxMzEyOCBieXRlcyBsZWZ0DQoNCg0KVGhhbmtzIGZv
ciB1c2luZyBwaWNvY29tDQpwaWNvY29tIHYxLjcNCg0KcG9ydCBpcyAgICAgICAgOiAvZGV2L3Nl
cmlhbC9ieS1pZC91c2ItUHJvbGlmaWNfVGVjaG5vbG9neV9JbmMuX1VTQi1TZXJpYWxfQ29udHJv
bGxlci1pZjAwLXBvcnQwDQpmbG93Y29udHJvbCAgICA6IG5vbmUNCmJhdWRyYXRlIGlzICAgIDog
MTE1MjAwDQpwYXJpdHkgaXMgICAgICA6IG5vbmUNCmRhdGFiaXRzIGFyZSAgIDogOA0KZXNjYXBl
IGlzICAgICAgOiBDLWENCmxvY2FsIGVjaG8gaXMgIDogbm8NCm5vaW5pdCBpcyAgICAgIDogbm8N
Cm5vcmVzZXQgaXMgICAgIDogbm8NCm5vbG9jayBpcyAgICAgIDogbm8NCnNlbmRfY21kIGlzICAg
IDogc3ogLXZ2DQpyZWNlaXZlX2NtZCBpcyA6IHJ6IC12dg0KaW1hcCBpcyAgICAgICAgOg0Kb21h
cCBpcyAgICAgICAgOg0KZW1hcCBpcyAgICAgICAgOiBjcmNybGYsZGVsYnMsDQo=

--------------Cpvf9nOps6Uetw0F935WFPmu--


From xen-devel-bounces@lists.xenproject.org Mon May 12 18:04:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 18:04:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.981999.1368475 (Exim 4.92)
	(envelope-from )
	id 1uEXVp-0001LC-7A; Mon, 12 May 2025 18:04:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 981999.1368475; Mon, 12 May 2025 18: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 1uEXVp-0001L5-3v; Mon, 12 May 2025 18:04:25 +0000
Received: by outflank-mailman (input) for mailman id 981999;
 Mon, 12 May 2025 18:04:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEXVo-0001Kz-4D
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 18:04:24 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 87e1c8c0-2f5b-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 20:04:22 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id EE74F4A939;
 Mon, 12 May 2025 18:04:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6195FC4CEFE;
 Mon, 12 May 2025 18:04: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" 
X-Inumbo-ID: 87e1c8c0-2f5b-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747073060;
	bh=lCTxzM5mPtEqEUhqg9mBz2nbnDEbWNQdOwqtwsH/FcI=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=tdHFr2ple1FtQDh+eCd7ZUHmvPvs2hX5VFnQlrBdiUdrKgvYL92mJAAONDT9yD2Ua
	 Pv8xqo17ABe2z4+MBtL4zc7yccQa/Y4ag/mrQYNqZiYRfphY9bdt1qHoXg9q+AbkEd
	 Koae12c8mrNpA52TTCEi0J1Q0vGkXvbGrexzHkcSsDwKuiklCJKsf4E6k7lJK66gbp
	 RTO7YkC/TmmYoipmFYURJY5FBNK69aYyGkreG06UYuWZyHu6NmcDYSoIK5EZZgWId6
	 T9MaPbYDgMSyUa/bRTEbhMUaUYXz9K0l/6bTwbqU7b0sgBMY92DbVck0dHrM1KYIB2
	 kYwg9wJ8Vy8XQ==
From: Sasha Levin 
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Jason Andryuk ,
	Stefano Stabellini ,
	Juergen Gross ,
	Sasha Levin ,
	sumit.garg@kernel.org,
	gregkh@linuxfoundation.org,
	michal.orzel@amd.com,
	xin.wang2@amd.com,
	chenqiuji666@gmail.com,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.14 13/15] xenbus: Allow PVH dom0 a non-local xenstore
Date: Mon, 12 May 2025 14:03:48 -0400
Message-Id: <20250512180352.437356-13-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250512180352.437356-1-sashal@kernel.org>
References: <20250512180352.437356-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.14.6
Content-Transfer-Encoding: 8bit

From: Jason Andryuk 

[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]

Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late init path.

Ideally we'd drop the use of xen_initial_domain() and just check for the
event channel instead.  However, ARM has a xen,enhanced no-xenstore
mode, where the event channel and PFN would both be 0.  Retain the
xen_initial_domain() check, and use that for an additional check when
the event channel is 0.

Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
chance that high bits are set for the 32bit event channel.

Signed-off-by: Jason Andryuk 
Change-Id: I5506da42e4c6b8e85079fefb2f193c8de17c7437
Reviewed-by: Stefano Stabellini 
Signed-off-by: Juergen Gross 
Message-ID: <20250506204456.5220-1-jason.andryuk@amd.com>
Signed-off-by: Sasha Levin 
---
 drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 6d32ffb011365..86fe6e7790566 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -966,9 +966,15 @@ static int __init xenbus_init(void)
 	if (xen_pv_domain())
 		xen_store_domain_type = XS_PV;
 	if (xen_hvm_domain())
+	{
 		xen_store_domain_type = XS_HVM;
-	if (xen_hvm_domain() && xen_initial_domain())
-		xen_store_domain_type = XS_LOCAL;
+		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+		if (err)
+			goto out_error;
+		xen_store_evtchn = (int)v;
+		if (!v && xen_initial_domain())
+			xen_store_domain_type = XS_LOCAL;
+	}
 	if (xen_pv_domain() && !xen_start_info->store_evtchn)
 		xen_store_domain_type = XS_LOCAL;
 	if (xen_pv_domain() && xen_start_info->store_evtchn)
@@ -987,10 +993,6 @@ static int __init xenbus_init(void)
 		xen_store_interface = gfn_to_virt(xen_store_gfn);
 		break;
 	case XS_HVM:
-		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-		if (err)
-			goto out_error;
-		xen_store_evtchn = (int)v;
 		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
 		if (err)
 			goto out_error;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 12 18:04:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 18:04:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982002.1368485 (Exim 4.92)
	(envelope-from )
	id 1uEXWH-0001lH-Dc; Mon, 12 May 2025 18:04:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982002.1368485; Mon, 12 May 2025 18: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 1uEXWH-0001kl-AJ; Mon, 12 May 2025 18:04:53 +0000
Received: by outflank-mailman (input) for mailman id 982002;
 Mon, 12 May 2025 18:04:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEXWG-0001iN-3g
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 18:04:52 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 97b1ceb6-2f5b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 20:04:49 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 121CF5C3A5E;
 Mon, 12 May 2025 18:02:30 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6BCDC4CEF0;
 Mon, 12 May 2025 18:04: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" 
X-Inumbo-ID: 97b1ceb6-2f5b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747073087;
	bh=lCTxzM5mPtEqEUhqg9mBz2nbnDEbWNQdOwqtwsH/FcI=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=ENRtZKMXwWza3chzqhxjc8H8mGmRL/Bz1M+Rr6NeobL0kj/Ew6VlWjTIwLk7lPd3p
	 UC0yazS2b+t0Ha0lkfBb3NOOiwRlQMGlDZm1ZkL8XKB/gQoZxh/SJcBSMvZhfQ6dZK
	 DHtUnayTofw+quRQn+/jY0mO0655OXvB1JM0+Tmh1tExm2gudfnWPjw1zwrj0mvNHq
	 ngBI8UAjz/A5c65wJhRnhxClf85ZBKuV49Z80ejI/S43s4oEinsjoHcnU/GDZhK7FJ
	 BlPkQp0ZVdkypn0N02ukbalB6cNmYZy06lG6h8RyjxCdo/1N8f4KaY2SNxYeetGfL+
	 jS5RsK6iQH37Q==
From: Sasha Levin 
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Jason Andryuk ,
	Stefano Stabellini ,
	Juergen Gross ,
	Sasha Levin ,
	chenqiuji666@gmail.com,
	michal.orzel@amd.com,
	xin.wang2@amd.com,
	gregkh@linuxfoundation.org,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.12 09/11] xenbus: Allow PVH dom0 a non-local xenstore
Date: Mon, 12 May 2025 14:04:24 -0400
Message-Id: <20250512180426.437627-9-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250512180426.437627-1-sashal@kernel.org>
References: <20250512180426.437627-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.12.28
Content-Transfer-Encoding: 8bit

From: Jason Andryuk 

[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]

Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late init path.

Ideally we'd drop the use of xen_initial_domain() and just check for the
event channel instead.  However, ARM has a xen,enhanced no-xenstore
mode, where the event channel and PFN would both be 0.  Retain the
xen_initial_domain() check, and use that for an additional check when
the event channel is 0.

Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
chance that high bits are set for the 32bit event channel.

Signed-off-by: Jason Andryuk 
Change-Id: I5506da42e4c6b8e85079fefb2f193c8de17c7437
Reviewed-by: Stefano Stabellini 
Signed-off-by: Juergen Gross 
Message-ID: <20250506204456.5220-1-jason.andryuk@amd.com>
Signed-off-by: Sasha Levin 
---
 drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 6d32ffb011365..86fe6e7790566 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -966,9 +966,15 @@ static int __init xenbus_init(void)
 	if (xen_pv_domain())
 		xen_store_domain_type = XS_PV;
 	if (xen_hvm_domain())
+	{
 		xen_store_domain_type = XS_HVM;
-	if (xen_hvm_domain() && xen_initial_domain())
-		xen_store_domain_type = XS_LOCAL;
+		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+		if (err)
+			goto out_error;
+		xen_store_evtchn = (int)v;
+		if (!v && xen_initial_domain())
+			xen_store_domain_type = XS_LOCAL;
+	}
 	if (xen_pv_domain() && !xen_start_info->store_evtchn)
 		xen_store_domain_type = XS_LOCAL;
 	if (xen_pv_domain() && xen_start_info->store_evtchn)
@@ -987,10 +993,6 @@ static int __init xenbus_init(void)
 		xen_store_interface = gfn_to_virt(xen_store_gfn);
 		break;
 	case XS_HVM:
-		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-		if (err)
-			goto out_error;
-		xen_store_evtchn = (int)v;
 		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
 		if (err)
 			goto out_error;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 12 18:05:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 18:05:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982008.1368496 (Exim 4.92)
	(envelope-from )
	id 1uEXWZ-0002Bn-NI; Mon, 12 May 2025 18:05:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982008.1368496; Mon, 12 May 2025 18:05: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 1uEXWZ-0002Bg-IQ; Mon, 12 May 2025 18:05:11 +0000
Received: by outflank-mailman (input) for mailman id 982008;
 Mon, 12 May 2025 18:05:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEXWX-0001iN-QY
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 18:05:09 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a3002133-2f5b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 20:05:07 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 9C542614B3;
 Mon, 12 May 2025 18:05:06 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CD05C4CEEF;
 Mon, 12 May 2025 18:05: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" 
X-Inumbo-ID: a3002133-2f5b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747073106;
	bh=CUwTTRBoepiWy3eBVkjtl52xMaizXnQOALV0fmgcrHo=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=RAB63nsHcTpOzKtm2P4jVzIJJ9bHeKAG2ycXy8HkEScyMbMrSCNRI7MQvueKz1v1U
	 H79sVzfY39Fk9quxMMWnx8NmtYinU8oa+J2q6dwDKYX3wPrn4rThgGOoxJUjwL8W+E
	 HUw1D8A2F+UweffjCsB5rBnupWCoogfSQ4pa/kFHlQQEltX5Hue9Obw5hGPOXfBZjy
	 mQ18QZA1sYB/xuJZdNZC8bjE16n1JvmPzkpv9lmECm1AggAgfK0jLRvEZLPB6iZnTb
	 G3ukswHoBnyWkldW0Qa7TXtkwrC22vN4iVV3/VjKbnudHV+5nudK568SUPWRvEW84X
	 mBoyFNkPVI+JQ==
From: Sasha Levin 
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Jason Andryuk ,
	Stefano Stabellini ,
	Juergen Gross ,
	Sasha Levin ,
	elder@kernel.org,
	chenqiuji666@gmail.com,
	gregkh@linuxfoundation.org,
	xin.wang2@amd.com,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.6 5/6] xenbus: Allow PVH dom0 a non-local xenstore
Date: Mon, 12 May 2025 14:04:51 -0400
Message-Id: <20250512180452.437844-5-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250512180452.437844-1-sashal@kernel.org>
References: <20250512180452.437844-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.6.90
Content-Transfer-Encoding: 8bit

From: Jason Andryuk 

[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]

Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late init path.

Ideally we'd drop the use of xen_initial_domain() and just check for the
event channel instead.  However, ARM has a xen,enhanced no-xenstore
mode, where the event channel and PFN would both be 0.  Retain the
xen_initial_domain() check, and use that for an additional check when
the event channel is 0.

Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
chance that high bits are set for the 32bit event channel.

Signed-off-by: Jason Andryuk 
Change-Id: I5506da42e4c6b8e85079fefb2f193c8de17c7437
Reviewed-by: Stefano Stabellini 
Signed-off-by: Juergen Gross 
Message-ID: <20250506204456.5220-1-jason.andryuk@amd.com>
Signed-off-by: Sasha Levin 
---
 drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 25164d56c9d99..d3b6908110c6f 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -966,9 +966,15 @@ static int __init xenbus_init(void)
 	if (xen_pv_domain())
 		xen_store_domain_type = XS_PV;
 	if (xen_hvm_domain())
+	{
 		xen_store_domain_type = XS_HVM;
-	if (xen_hvm_domain() && xen_initial_domain())
-		xen_store_domain_type = XS_LOCAL;
+		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+		if (err)
+			goto out_error;
+		xen_store_evtchn = (int)v;
+		if (!v && xen_initial_domain())
+			xen_store_domain_type = XS_LOCAL;
+	}
 	if (xen_pv_domain() && !xen_start_info->store_evtchn)
 		xen_store_domain_type = XS_LOCAL;
 	if (xen_pv_domain() && xen_start_info->store_evtchn)
@@ -987,10 +993,6 @@ static int __init xenbus_init(void)
 		xen_store_interface = gfn_to_virt(xen_store_gfn);
 		break;
 	case XS_HVM:
-		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-		if (err)
-			goto out_error;
-		xen_store_evtchn = (int)v;
 		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
 		if (err)
 			goto out_error;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 12 18:05:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 18:05:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982013.1368505 (Exim 4.92)
	(envelope-from )
	id 1uEXWh-0002Vf-Ry; Mon, 12 May 2025 18:05:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982013.1368505; Mon, 12 May 2025 18:05: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 1uEXWh-0002VY-P5; Mon, 12 May 2025 18:05:19 +0000
Received: by outflank-mailman (input) for mailman id 982013;
 Mon, 12 May 2025 18:05:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEXWh-0001Kz-4G
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 18:05:19 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a94e4a92-2f5b-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 20:05:18 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 82434614B3;
 Mon, 12 May 2025 18:05:17 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0911C4CEE7;
 Mon, 12 May 2025 18:05: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" 
X-Inumbo-ID: a94e4a92-2f5b-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747073117;
	bh=CUwTTRBoepiWy3eBVkjtl52xMaizXnQOALV0fmgcrHo=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=j2irdoKQ1ovlV+17jJfSXbJ/8/i+TtLcyIs/53YehDBnIiGP19LFzLEFNphKTK2ea
	 Y4EGjNagxgZ/Sv29nYQi0+XN3qIypZFKOQNs79cPkTTcHNhpXY7/5PoWlWPeyFKlqN
	 dHrF3usEx5yyYf9cuWBFqol1Z0pR6WgLXUg4fYkcBz11Z7Me1OVQBkbWCapGYGbTg1
	 /I4A9LJgqFZwR4b4wfHCqa6NwoRfSrwNUNeryjk17heawIICdtTmvE+yQG8W1rA05W
	 7U862n5/sL5bDZ0N3gk1w8ZwGRkjHwZYSfBDlLgklwVYn2TEkLTfpuLY/UUZLBoQK2
	 e5K0Wh+ZJq/TQ==
From: Sasha Levin 
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Jason Andryuk ,
	Stefano Stabellini ,
	Juergen Gross ,
	Sasha Levin ,
	chenqiuji666@gmail.com,
	elder@kernel.org,
	michal.orzel@amd.com,
	gregkh@linuxfoundation.org,
	xin.wang2@amd.com,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.1 3/4] xenbus: Allow PVH dom0 a non-local xenstore
Date: Mon, 12 May 2025 14:05:06 -0400
Message-Id: <20250512180508.437991-3-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250512180508.437991-1-sashal@kernel.org>
References: <20250512180508.437991-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.1.138
Content-Transfer-Encoding: 8bit

From: Jason Andryuk 

[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]

Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late init path.

Ideally we'd drop the use of xen_initial_domain() and just check for the
event channel instead.  However, ARM has a xen,enhanced no-xenstore
mode, where the event channel and PFN would both be 0.  Retain the
xen_initial_domain() check, and use that for an additional check when
the event channel is 0.

Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
chance that high bits are set for the 32bit event channel.

Signed-off-by: Jason Andryuk 
Change-Id: I5506da42e4c6b8e85079fefb2f193c8de17c7437
Reviewed-by: Stefano Stabellini 
Signed-off-by: Juergen Gross 
Message-ID: <20250506204456.5220-1-jason.andryuk@amd.com>
Signed-off-by: Sasha Levin 
---
 drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 25164d56c9d99..d3b6908110c6f 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -966,9 +966,15 @@ static int __init xenbus_init(void)
 	if (xen_pv_domain())
 		xen_store_domain_type = XS_PV;
 	if (xen_hvm_domain())
+	{
 		xen_store_domain_type = XS_HVM;
-	if (xen_hvm_domain() && xen_initial_domain())
-		xen_store_domain_type = XS_LOCAL;
+		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+		if (err)
+			goto out_error;
+		xen_store_evtchn = (int)v;
+		if (!v && xen_initial_domain())
+			xen_store_domain_type = XS_LOCAL;
+	}
 	if (xen_pv_domain() && !xen_start_info->store_evtchn)
 		xen_store_domain_type = XS_LOCAL;
 	if (xen_pv_domain() && xen_start_info->store_evtchn)
@@ -987,10 +993,6 @@ static int __init xenbus_init(void)
 		xen_store_interface = gfn_to_virt(xen_store_gfn);
 		break;
 	case XS_HVM:
-		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-		if (err)
-			goto out_error;
-		xen_store_evtchn = (int)v;
 		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
 		if (err)
 			goto out_error;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 12 18:05:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 18:05:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982019.1368515 (Exim 4.92)
	(envelope-from )
	id 1uEXWu-000336-3z; Mon, 12 May 2025 18:05:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982019.1368515; Mon, 12 May 2025 18: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 1uEXWu-00032v-11; Mon, 12 May 2025 18:05:32 +0000
Received: by outflank-mailman (input) for mailman id 982019;
 Mon, 12 May 2025 18:05:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEXWs-0001iN-Ia
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 18:05:30 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id af53ae77-2f5b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 20:05:28 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 79B795C5507;
 Mon, 12 May 2025 18:03:09 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41088C4CEEF;
 Mon, 12 May 2025 18:05: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" 
X-Inumbo-ID: af53ae77-2f5b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747073126;
	bh=3AksgRRmkoQ6fJIncxndRZkvy/I4Fxh5QPEmqwimDJo=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=QPr255rBlHWgPuVdnQtKzCGhYS41C3JKflJ0AIgmHnuaLPxtxrkg75Am93zlAQSIp
	 HQWFb+OmaKKb8gQeMAjkFE2AXHBGEzzQIyX01rEv7GxWa56ALaPr563YhN1KcZdYKp
	 XVMLuJRFe175hsPNbv0aRLJow5otDhfGnullY0odgnWA8nGu4r1cXh4BODtSd+MRsi
	 S6pz67JVk0u8SHvVVX6ezMhV6jQRzo2Q8w3dz+gD5pfCchqjNXPNSe6IQ0f/nkMxh4
	 Ktu8BoGVbGJNnLeOmjykWoQtGFAULAo6+ROW6MXsjAPo2BNGNaz6uL3xc5RuloqQIm
	 8OQXiTJA1MetQ==
From: Sasha Levin 
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Jason Andryuk ,
	Stefano Stabellini ,
	Juergen Gross ,
	Sasha Levin ,
	gregkh@linuxfoundation.org,
	chenqiuji666@gmail.com,
	xin.wang2@amd.com,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 5.15 2/3] xenbus: Allow PVH dom0 a non-local xenstore
Date: Mon, 12 May 2025 14:05:17 -0400
Message-Id: <20250512180518.438085-2-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250512180518.438085-1-sashal@kernel.org>
References: <20250512180518.438085-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 5.15.182
Content-Transfer-Encoding: 8bit

From: Jason Andryuk 

[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]

Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late init path.

Ideally we'd drop the use of xen_initial_domain() and just check for the
event channel instead.  However, ARM has a xen,enhanced no-xenstore
mode, where the event channel and PFN would both be 0.  Retain the
xen_initial_domain() check, and use that for an additional check when
the event channel is 0.

Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
chance that high bits are set for the 32bit event channel.

Signed-off-by: Jason Andryuk 
Change-Id: I5506da42e4c6b8e85079fefb2f193c8de17c7437
Reviewed-by: Stefano Stabellini 
Signed-off-by: Juergen Gross 
Message-ID: <20250506204456.5220-1-jason.andryuk@amd.com>
Signed-off-by: Sasha Levin 
---
 drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index e680bd1adf9c4..2068f83556b78 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -927,9 +927,15 @@ static int __init xenbus_init(void)
 	if (xen_pv_domain())
 		xen_store_domain_type = XS_PV;
 	if (xen_hvm_domain())
+	{
 		xen_store_domain_type = XS_HVM;
-	if (xen_hvm_domain() && xen_initial_domain())
-		xen_store_domain_type = XS_LOCAL;
+		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+		if (err)
+			goto out_error;
+		xen_store_evtchn = (int)v;
+		if (!v && xen_initial_domain())
+			xen_store_domain_type = XS_LOCAL;
+	}
 	if (xen_pv_domain() && !xen_start_info->store_evtchn)
 		xen_store_domain_type = XS_LOCAL;
 	if (xen_pv_domain() && xen_start_info->store_evtchn)
@@ -948,10 +954,6 @@ static int __init xenbus_init(void)
 		xen_store_interface = gfn_to_virt(xen_store_gfn);
 		break;
 	case XS_HVM:
-		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-		if (err)
-			goto out_error;
-		xen_store_evtchn = (int)v;
 		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
 		if (err)
 			goto out_error;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 12 18:05:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 18:05:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982027.1368525 (Exim 4.92)
	(envelope-from )
	id 1uEXX9-0003bv-BJ; Mon, 12 May 2025 18:05:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982027.1368525; Mon, 12 May 2025 18:05: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 1uEXX9-0003bm-8e; Mon, 12 May 2025 18:05:47 +0000
Received: by outflank-mailman (input) for mailman id 982027;
 Mon, 12 May 2025 18:05:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEXX8-0001Kz-Eu
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 18:05:46 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b9ace606-2f5b-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 20:05:45 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id F3C50614B7;
 Mon, 12 May 2025 18:05:44 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DF8EC4CEE7;
 Mon, 12 May 2025 18:05: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" 
X-Inumbo-ID: b9ace606-2f5b-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747073144;
	bh=0M7b1jwuL8aGrtVgJT1veCJSLkJZ6QXbB0t/Micp/7M=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=tyuVzCWj63wXRMOHJ5MGlLunznISQVMA/lipEyRQCtMonx1NA4tgbZKzpwtNfv7/C
	 3RhMntOlyqtZGbIiUSEDZXB4882iArRoeFc+E3J+E3/ul/EMvRc8UTXS/ViB3JFtF3
	 VfGq4XembhqziMvOavLcgg/da1Pe0cX/b2asOV87qjGQxxnxrJBCPL1sB1ges1Y1Na
	 EhbHGEDiuMbo/UIJblj5zk9es2FLI1JIjy66ZO/BKu5cG0nkMFAPz7Ut3fF1wcBVpU
	 4txeuvt69xDTSAS084chd9p2koow9L/RBjnSCjWI0WCYp4sNr8yK7tPRMh2/IkVeC5
	 jTf/O886yQmUA==
From: Sasha Levin 
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Jason Andryuk ,
	Stefano Stabellini ,
	Juergen Gross ,
	Sasha Levin ,
	chenqiuji666@gmail.com,
	gregkh@linuxfoundation.org,
	xin.wang2@amd.com,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 5.4 2/3] xenbus: Allow PVH dom0 a non-local xenstore
Date: Mon, 12 May 2025 14:05:36 -0400
Message-Id: <20250512180537.438255-2-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250512180537.438255-1-sashal@kernel.org>
References: <20250512180537.438255-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 5.4.293
Content-Transfer-Encoding: 8bit

From: Jason Andryuk 

[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]

Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late init path.

Ideally we'd drop the use of xen_initial_domain() and just check for the
event channel instead.  However, ARM has a xen,enhanced no-xenstore
mode, where the event channel and PFN would both be 0.  Retain the
xen_initial_domain() check, and use that for an additional check when
the event channel is 0.

Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
chance that high bits are set for the 32bit event channel.

Signed-off-by: Jason Andryuk 
Change-Id: I5506da42e4c6b8e85079fefb2f193c8de17c7437
Reviewed-by: Stefano Stabellini 
Signed-off-by: Juergen Gross 
Message-ID: <20250506204456.5220-1-jason.andryuk@amd.com>
Signed-off-by: Sasha Levin 
---
 drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index fd686b962727a..17705f82f85fd 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -881,9 +881,15 @@ static int __init xenbus_init(void)
 	if (xen_pv_domain())
 		xen_store_domain_type = XS_PV;
 	if (xen_hvm_domain())
+	{
 		xen_store_domain_type = XS_HVM;
-	if (xen_hvm_domain() && xen_initial_domain())
-		xen_store_domain_type = XS_LOCAL;
+		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+		if (err)
+			goto out_error;
+		xen_store_evtchn = (int)v;
+		if (!v && xen_initial_domain())
+			xen_store_domain_type = XS_LOCAL;
+	}
 	if (xen_pv_domain() && !xen_start_info->store_evtchn)
 		xen_store_domain_type = XS_LOCAL;
 	if (xen_pv_domain() && xen_start_info->store_evtchn)
@@ -902,10 +908,6 @@ static int __init xenbus_init(void)
 		xen_store_interface = gfn_to_virt(xen_store_gfn);
 		break;
 	case XS_HVM:
-		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-		if (err)
-			goto out_error;
-		xen_store_evtchn = (int)v;
 		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
 		if (err)
 			goto out_error;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 12 18:15:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 18:15:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982055.1368536 (Exim 4.92)
	(envelope-from )
	id 1uEXgT-0005qH-CW; Mon, 12 May 2025 18:15:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982055.1368536; Mon, 12 May 2025 18:15: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 1uEXgT-0005qA-8I; Mon, 12 May 2025 18:15:25 +0000
Received: by outflank-mailman (input) for mailman id 982055;
 Mon, 12 May 2025 18:15:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEXX1-0001iN-M5
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 18:05:39 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b4702cbb-2f5b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 20:05:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 459B7614B4;
 Mon, 12 May 2025 18:05:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2452C4CEE7;
 Mon, 12 May 2025 18:05: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" 
X-Inumbo-ID: b4702cbb-2f5b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747073136;
	bh=tClUygEdgjrbqL6Az0SliCxYp1+a19KrR43GjyNmmfE=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=sIWqO7dcL6+H0+FDcizZdrxvtSrzg+M1wlI2sy83EV246KLXdSqqB9JNwNR5+1Oeq
	 h6fyTrfhEuS84ixdK2gb3IZMS2Rg5MQZBGixyPJKPNYaPbyvFyU38Xim6BrsBN+Tt/
	 Qx6TICpsew4Wm5p1Quqx63ujNooZgELWiDjBJdK4FkxTskFD0TNOHifZjigeJLfGq4
	 HuAILqg/i6Vr+CsBCX9yRDRUCKq1FEf6e6A1NOtp9HylDf0KqAnX8/h8qFOVH4g6Rl
	 EZqLkIZmueGkNsqQFf8UGpUODzhZ0/zj2z4Dycb0hGxV6TNyzYS5QOd5R37actUdPo
	 LHU1e70CFRqew==
From: Sasha Levin 
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Jason Andryuk ,
	Stefano Stabellini ,
	Juergen Gross ,
	Sasha Levin ,
	xin.wang2@amd.com,
	chenqiuji666@gmail.com,
	elder@kernel.org,
	gregkh@linuxfoundation.org,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 5.10 2/3] xenbus: Allow PVH dom0 a non-local xenstore
Date: Mon, 12 May 2025 14:05:27 -0400
Message-Id: <20250512180528.438177-2-sashal@kernel.org>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250512180528.438177-1-sashal@kernel.org>
References: <20250512180528.438177-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 5.10.237
Content-Transfer-Encoding: 8bit

From: Jason Andryuk 

[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]

Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late init path.

Ideally we'd drop the use of xen_initial_domain() and just check for the
event channel instead.  However, ARM has a xen,enhanced no-xenstore
mode, where the event channel and PFN would both be 0.  Retain the
xen_initial_domain() check, and use that for an additional check when
the event channel is 0.

Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
chance that high bits are set for the 32bit event channel.

Signed-off-by: Jason Andryuk 
Change-Id: I5506da42e4c6b8e85079fefb2f193c8de17c7437
Reviewed-by: Stefano Stabellini 
Signed-off-by: Juergen Gross 
Message-ID: <20250506204456.5220-1-jason.andryuk@amd.com>
Signed-off-by: Sasha Levin 
---
 drivers/xen/xenbus/xenbus_probe.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 743795d402cb0..fb5358a738204 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -864,9 +864,15 @@ static int __init xenbus_init(void)
 	if (xen_pv_domain())
 		xen_store_domain_type = XS_PV;
 	if (xen_hvm_domain())
+	{
 		xen_store_domain_type = XS_HVM;
-	if (xen_hvm_domain() && xen_initial_domain())
-		xen_store_domain_type = XS_LOCAL;
+		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+		if (err)
+			goto out_error;
+		xen_store_evtchn = (int)v;
+		if (!v && xen_initial_domain())
+			xen_store_domain_type = XS_LOCAL;
+	}
 	if (xen_pv_domain() && !xen_start_info->store_evtchn)
 		xen_store_domain_type = XS_LOCAL;
 	if (xen_pv_domain() && xen_start_info->store_evtchn)
@@ -885,10 +891,6 @@ static int __init xenbus_init(void)
 		xen_store_interface = gfn_to_virt(xen_store_gfn);
 		break;
 	case XS_HVM:
-		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-		if (err)
-			goto out_error;
-		xen_store_evtchn = (int)v;
 		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
 		if (err)
 			goto out_error;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 12 18:26:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 18:26:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982066.1368544 (Exim 4.92)
	(envelope-from )
	id 1uEXrB-0007nF-6t; Mon, 12 May 2025 18:26:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982066.1368544; Mon, 12 May 2025 18:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEXrB-0007n8-3m; Mon, 12 May 2025 18:26:29 +0000
Received: by outflank-mailman (input) for mailman id 982066;
 Mon, 12 May 2025 18:26:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEXr9-0007n2-JC
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 18:26:27 +0000
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9bf87a83-2f5e-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 20:26:24 +0200 (CEST)
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7])
 by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 54CIPtkg052256
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Mon, 12 May 2025 14:26:01 -0400 (EDT) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.18.1/8.15.2/Submit) id 54CIPrN9052255;
 Mon, 12 May 2025 11:25: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" 
X-Inumbo-ID: 9bf87a83-2f5e-11f0-9ffb-bf95429c2676
Date: Mon, 12 May 2025 11:25:53 -0700
From: Elliott Mitchell 
To: Jan Beulich 
Cc: Andrew Cooper ,
        Xen-devel ,
        Anthony PERARD ,
        Michal Orzel , Julien Grall ,
        Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
        Roberto Bagnara ,
        Nicola Vetrini ,
        "consulting @ bugseng . com" ,
        Stefano Stabellini 
Subject: Re: [PATCH] xen: Use __auto_type
Message-ID: 
References: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
 
 <548430a5-fa4a-41d1-b5ba-ba45efa90bbc@suse.com>
 <7acc83a3-2b15-4557-b293-0832b35e3680@citrix.com>
 <35826c2a-4266-49d2-b1b8-1248aac227b5@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <35826c2a-4266-49d2-b1b8-1248aac227b5@suse.com>
X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=no
	autolearn_force=no version=4.0.1
X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mattapan.m5p.com

On Mon, May 12, 2025 at 03:00:18PM +0200, Jan Beulich wrote:
> On 12.05.2025 14:09, Andrew Cooper wrote:
> > 
> > Now for the (new) controversial part. Since sending this, Linux has
> > decided to just #define auto __auto_type for C < 23, in order to start
> > writing C23 compatible code from now. It's more succinct, and has
> > better longevity.
> > 
> > We might want to consider the same, although it will introduce a new
> > example of defining a keyword, which we'd have to call out in the
> > MISRA/Eclair config.
> 
> I'm not outright opposed, as I don't think we use "auto" with its
> original semantics, but it feels somewhat odd.

Problem is "auto" already has a defined meaning in C.  Having this will
subtly break contributions from authors who weren't familiar with
everything in Xen's headers.  For anyone who does anything with projects
besides Xen this will encourage bad habits.

I believe many projects have a rule of *never* #define C keywords.  I'm
surprised such made it into the Linux kernel.  I expect it will be ripped
out in the near future.

MISRA *doesn't* absolutely forbid this?


-- 
(\___(\___(\______          --=> 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 Mon May 12 19:10:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 19:10:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982095.1368639 (Exim 4.92)
	(envelope-from )
	id 1uEYXY-0006qq-Bf; Mon, 12 May 2025 19:10:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982095.1368639; Mon, 12 May 2025 19:10: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 1uEYXY-0006qj-8o; Mon, 12 May 2025 19:10:16 +0000
Received: by outflank-mailman (input) for mailman id 982095;
 Mon, 12 May 2025 19:10:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEYXW-0006qd-8L
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 19:10:14 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20604.outbound.protection.outlook.com
 [2a01:111:f403:2612::604])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b95f982f-2f64-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 21:10:10 +0200 (CEST)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by PA4PR03MB7327.eurprd03.prod.outlook.com
 (2603:10a6:102:108::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.29; Mon, 12 May
 2025 19:10:08 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%4]) with mapi id 15.20.8722.027; Mon, 12 May 2025
 19:10: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" 
X-Inumbo-ID: b95f982f-2f64-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=o8xABaBBseaC1swSRRJ0PVBzPNxfSfXKilDAsICdzLiz54PnQdlG/Pl2FoLNZQqPiBC2EZElXG1y6pWReFdGLGrg+7V3ndR6CUAXu0Q4bi4B8YRGzmUHMh96Mj6JC5HTe3DowW9ikl4+NTv9mGdImHcws/XpeVzMnlghmjnRPa54jv+P405OzkhUHXqvDggLdY59Uj5uMFgw5FTGf88T3i3dWHkR3wBlJ4E+zEP1KLc4AXhM/MYqjyusMV3SYQQniFC8zIdbFS1ANmKHYJR97MRqfeMix5MBSH8jtypPjQKMgfEucjk3WJRXFFEo5jLGpGi53EED0jmCAD7W4+6UoQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/YMPW7tJu+uzWqePJs8vFaT2grT4+YrvXbt7LpugvS0=;
 b=pCAwffDMVbyk6rO0gtsiyuGbfNSRqu2QLRVBxFXpO2pBUOhl5RMMztSrWkjGBSX/4uKjPxEybs/zXrqU/RcK1KupYO10Tagx9V/8h1lDnB7ZTTrZA/Vg4+6/03zS5umyGzl1HqWYg5iLWDUPETmUVmvF1aj3M5A4XAxtXjhlyBLPBz4xrYVa2FzSqGgGxT1AVw9Kw0pLfWcjabaM6hXGo0Ui5kLil9IFba1crxOa5otJ1GX/zFpkKkcLyctUcuadnMODT5H2mA+IskSLu3TrmLSAri6XyTHPcRQSQWP5t07Ja/4idPMGaxHSkO3fqcDY2CmTqIncPImUVIBlIYJMQg==
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=/YMPW7tJu+uzWqePJs8vFaT2grT4+YrvXbt7LpugvS0=;
 b=YShxrAQSCoKhlULwdZkvw/pL47ZWP3h6ejXZGagPeKX6FxjzfAYlla29e30mau//uhmDiLk82W2BvQUn0ZzrmaXPhb0GQFq9lPJ/k4ryW5Wit7ALAK/h6eP/OS7KB7h/UNxacwjOioejnqDQ7Yud49lSgpn93C2S/9MfXuNED/5dS3Y7J/sprUg77T1TzxfFRQGcIFtQ+6kp7j6v2TSv0cnvuPXIaEZqtZ1XujOiO+TppRqCUtUV3A6r6BVYrmJq9NE8BmB7hY7j8ts1OZEz4EoD6sfgEWs7ZoYqB4J7/rnpPwBiQRISpiBh4PWqp00prN7IQ6FGsJTiU/dcxLsVFQ==
From: Volodymyr Babchuk 
To: Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" , Doug
 Goldstein 
Subject: Re: [RFC PATCH v3 2/2] ci: enable fuzzing for arm64
Thread-Topic: [RFC PATCH v3 2/2] ci: enable fuzzing for arm64
Thread-Index: AQHbvzX0DP4RwWsFtkCwrnnT9nV/Vg==
Date: Mon, 12 May 2025 19:10:07 +0000
Message-ID: <87plgdd4s1.fsf@epam.com>
References: <20250507095338.735228-1-volodymyr_babchuk@epam.com>
	<20250507095338.735228-3-volodymyr_babchuk@epam.com>
	
In-Reply-To:
 
	(Stefano Stabellini's message of "Fri, 9 May 2025 14:52:10 -0700	(PDT)")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|PA4PR03MB7327:EE_
x-ms-office365-filtering-correlation-id: 3b749a04-a081-47bf-f09c-08dd91889c4a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?2MOeF1SdvSuAU/DOFzvVuHrhpC2sYWd14wP+LCwkHhXe0Eh3He9WWe3v83?=
 =?iso-8859-1?Q?7q9ZliljVScM4t/FhWI0T17yXKAUmF3KtgkB1EeQ6OMkgBtPr10JW9g1yG?=
 =?iso-8859-1?Q?8fldLM3rJcQB5so1+fzqXX7hQh7aHec744sBBMDIDhFcUOL9nvbUioVboQ?=
 =?iso-8859-1?Q?zgNiJDTh60USDhVCDw7UeMmb79UyC9OVAcW+dBmkPSsX0iC1l1TzJB9nq7?=
 =?iso-8859-1?Q?lrZkdg0uyWmii7C6UNG2z8bGFNoYNiAj2KcTR4T6uObVPg8y06kFBwak4X?=
 =?iso-8859-1?Q?w9i3jlvz9jp4GLokXCmi89ADOIFFwHp/5uh1oCr6Tip10gTnQb/DZYygsE?=
 =?iso-8859-1?Q?8VHk+G2FN7iDiCfdyseqkTUmwrTFYxEog03LjXV1BSlOSHEhIXjQNnt6c7?=
 =?iso-8859-1?Q?B1dtbnvFwvDfGQtnCh7SaXFtiVFV0t40u9X4iCfY8ZUzw5fyPi/wwQ+7h2?=
 =?iso-8859-1?Q?3aEdUKFWwniOacvIjEgD1YH/2p9ckFRLo6voOLBQqzILcS+/jK6RZovppi?=
 =?iso-8859-1?Q?fcPwY7UdJCkHlnW823ehohUfmTbEKXyYmcUfNoTos3PFockO5sbpVLS0cX?=
 =?iso-8859-1?Q?SToiB6cFyfz2K444NeO/norHtbBECwQgADe+RB0dq1VccLKTxt/pGRD0rI?=
 =?iso-8859-1?Q?ysZGJASF7HtsP+xaLJxchsIaJcZDkYJG8VuZjgsA4eyAQUSjasKiLZIzH1?=
 =?iso-8859-1?Q?lXt3e2vinlEnzC+tY3rbkBQFyAknt8Cu1/5ltInoJlzykiYlq2SUCdlESd?=
 =?iso-8859-1?Q?PLzLmjm2+Ob37rKtV7MUsN8Spqk3R4m8EpOA6NI8U7IpIvLSoTq2UrULl2?=
 =?iso-8859-1?Q?NdKgCiZ1FNygC+835cODOYC8k3dcxrP6ttY82ZQzM87VXWYOQSwfI5Htb/?=
 =?iso-8859-1?Q?siLUaCKMivkze496mMWm3LMSjM7UG1h1UNga0HtIi6p7nAD0Ryy7C9+DqH?=
 =?iso-8859-1?Q?+0uhxUDnd9RANONaktMgD3hNB5ZREa56VkVull1634YCjHkmR2E6PWiJVg?=
 =?iso-8859-1?Q?e+2QjXRkCXoqDDD3LVklVLo0VWPzXkKE53Lf69JcheqYiMIrUv8I5dI0Gx?=
 =?iso-8859-1?Q?dqzbWA1euP6w8s7E2FbsWHk6LPy78d25EY3aqloB/HPUyKm3TE7Vpze0Ki?=
 =?iso-8859-1?Q?bzUIfbPnVcYm5c3v7YBSP1nVeqa+hv1iqs8TUU0hjdw8zlEEsd4zvsLceB?=
 =?iso-8859-1?Q?Nq7W3opoA7d0Vuql2B3q89eLwSWljMh6w3d4p3SGjBTEC3ZXTBMn2+MdpZ?=
 =?iso-8859-1?Q?oSqXNSkgcK9ehljPvxHp8NYdXkfh7kA3HSl+kswlJMJZSUCLsu7blfSFOr?=
 =?iso-8859-1?Q?9RkrqQ/j8AMAgdV7enSP9T5cq8GLf/ziHieQk/q/Iu2kSXvnmjsb6yC8bJ?=
 =?iso-8859-1?Q?dtMFaTQF7xp1UFrQUsuRw7l8kiTvRaLs4O5XjKQN1BqPvZ454+vsiLXPbp?=
 =?iso-8859-1?Q?Qj+dqkZYsqOw2wGi/XY/ftbhBfXL26JnbRXfojMy2+D9PzkpniR85hh2B+?=
 =?iso-8859-1?Q?JxWu7JUeImhSUmpXIljCWl/7Xag/Gqd4IqzFk/QDAkHQ=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?AneDgd8rWjFv1z+N2cIvL6jsjXchTRWatVQnUaJfbawkI4BzKn14Arqpqq?=
 =?iso-8859-1?Q?BFkkTjtFuDUgRVA7avfBDEy3kPrWEIzA4107I03Es2LYE/BWCMYyO2Z5/s?=
 =?iso-8859-1?Q?ZwoJQ4pBeNR/2acI7X/6b51+JUKnMO39mZ4l5FXvi5ToXMGVu2KB07MVFj?=
 =?iso-8859-1?Q?qX/lwDrm7BgJ2VkRWYc9NT+mVHjjvZmRUga4tlxlJ/4a7i7rDshlyl2wrq?=
 =?iso-8859-1?Q?Y1d5FnnwPXsET2x1ns+sZqTCsSS62IATpCYGPtcxS2fzlkKkIyYd70aNCD?=
 =?iso-8859-1?Q?wTgcbwtSxet6IaN75TZ3e/WDTrWPltsXD53Ldxu0NZUHvY9cPaonxWMJ/u?=
 =?iso-8859-1?Q?UqvKCFsYlkowPkf7SXnNeA+NC2g9UhEPd4k/2FT/JiAjhMsIzcjrV4Q6xj?=
 =?iso-8859-1?Q?pb46Yu50HbO1Xb/Pb1k7/hWijspYMkkU3Ry63QRTTsR4fLQHPBzk34MuxV?=
 =?iso-8859-1?Q?cSFNp7Jz0F87E13vV2p9C4IKBJyHekcU+6KRq20fDWqzHnZDxik3U32KCJ?=
 =?iso-8859-1?Q?J/R/V/+vT314fFGxTNcc6x8wdfWySGk3OPoxp1cwmoAfRkYMyxzmKTQKYd?=
 =?iso-8859-1?Q?0XvZPacsxc2RBv3mB1fFuQ1EqllONg4nnva6Gdp5pp2PwPF7yjA18rN1dr?=
 =?iso-8859-1?Q?j2Sdh60nVNjwvN5wObABMSrVFNpUYNEuVRCgabu/qGYbU+qtydxzwqee6q?=
 =?iso-8859-1?Q?4bjG9gHBSm2AFQgbNuQw+clCRZdw5TP509ZTe5LkRB4PUI54/JsbEiv9+7?=
 =?iso-8859-1?Q?ill8LOS0Rflw8iqiVo1/bAUXko+wYmP/JWkFGoxwTU1SYUuk1NKCB+OXXm?=
 =?iso-8859-1?Q?skxY3VwqNulc+sXbzVUzYGVgUwuH3qDcCkBk5hd9s6s9U2tcfaOtmF08BK?=
 =?iso-8859-1?Q?8VF3wLUjAX80+AnG25UVlHSnV39GvWDKfQZQ8u2HkIXPrY7GFlsHWv7RIG?=
 =?iso-8859-1?Q?9X4ebRlCqkQzowMQ5EtmSuetFBVOkPhSlaLjFmxJe/wmy15CW6727LouXU?=
 =?iso-8859-1?Q?+gGm3dnuOxHTNi8MDchNznPnCkZimYRiS1CoDTRKPLlopgK3txdsZWS6Nd?=
 =?iso-8859-1?Q?5N0RN2tvlDK6ygzzaJPAsOc43HS9t9QZkK+M2OEjjfvFiL/8F7ntPN6ueE?=
 =?iso-8859-1?Q?+bl2evBlmOt2w20hKSM2cPygqo1uJHp7gF71AiNwlS118aiXc6WhNMjZfD?=
 =?iso-8859-1?Q?LIiqX5BadLrk8ZONijDA/wdjs2grFLhSQSHiQWEqcUwsyiGmWuck+osrwY?=
 =?iso-8859-1?Q?QI1EyTDxNJGo8+YRXQn1vEgQT/nG0LUUV/pqGhJFh1H63qgYj7JecIHlCa?=
 =?iso-8859-1?Q?gH/0/HvRf5WfWfP9SocIL9J1VkFAea9FbF665dIAzEIF2EBbmyweP33X7k?=
 =?iso-8859-1?Q?6b4yrGzQgagFflIJ/2Dm+pXq4xQnesnsL7gH1fU1rCIk21AYsUPMdhVeID?=
 =?iso-8859-1?Q?1uIW0EnW7L0+7WhU6dKSu8pWmHf7fAgpBlwpILNLMKZo5aTWEaeZmknOdd?=
 =?iso-8859-1?Q?cLq0isIfpitVpuMdhZv7m+5I628F1Zi9k6hpFeQFX5Yy5xL6fJ4JT29Yyb?=
 =?iso-8859-1?Q?pLZ61dMleb91BtIRtdbkn8DOiLSxmH5BcVIxWHYuaXpJTcmbzTatP2PjoD?=
 =?iso-8859-1?Q?KcoytYCA+hxdr17nNmLjCARqdsrgSdt6Y9ISru3Dj+JPYEn35P/FD6Hw?=
 =?iso-8859-1?Q?=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: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b749a04-a081-47bf-f09c-08dd91889c4a
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2025 19:10:07.9854
 (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: +IqsIN5O/osL3vlIkzUO6e61n1RsVF2gu+Jtlk6sPpee4zd6d6XTvRRoBcDF3/fuKBK7aqcS3R+ExJChQCrD9RQ4A2GroJy/mBq5VIs00ho=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB7327


Hi Stefano,


Stefano Stabellini  writes:

> On Wed, 7 May 2025, Volodymyr Babchuk wrote:

>>  alpine-3.18-gcc-debug-arm64:
>> +  extends: .gcc-arm64-build-debug
>> +  variables:
>> +    CONTAINER: alpine:3.18-arm64v8
>> +    EXTRA_XEN_CONFIG: |
>> +      CONFIG_UBSAN=3Dy
>> +      CONFIG_UBSAN_FATAL=3D
>
> The diff is strange and I might be wrong, but it looks like this should
> be CONFIG_UBSAN_FATAL=3Dy

Yes, looks like a mistake from my side.

>
>> +alpine-3.18-gcc-fuzzing-arm64:
>>    extends: .gcc-arm64-build-debug
>>    variables:
>>      CONTAINER: alpine:3.18-arm64v8
>>      EXTRA_XEN_CONFIG: |
>>        CONFIG_UBSAN=3Dy
>>        CONFIG_UBSAN_FATAL=3Dy
>> +      CONFIG_FUZZING=3Dy
>> +      CONFIG_FUZZER_LIBAFL_QEMU=3Dy
>> +      CONFIG_FUZZER_PASS_BLOCKING=3Dy
>> =20
>>  alpine-3.18-gcc-arm64-randconfig:
>>    extends: .gcc-arm64-build
>> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.=
yaml
>> index a603d4039a..bb8670026f 100644
>> --- a/automation/gitlab-ci/test.yaml
>> +++ b/automation/gitlab-ci/test.yaml
>> @@ -197,6 +197,30 @@
>>    tags:
>>      - qubes-hw11
>> =20
>> +.fuzzer-arm:
>> +  stage: test
>> +  image: xentroops/xen-fuzzer:v1
>> +  variables:
>> +    HARNESS: hypercall
>> +    FUZZING_TIME: 600
>> +  rules:
>> +  - if: $SELECTED_JOBS_ONLY && $CI_JOB_NAME =3D~ $SELECTED_JOBS_ONLY
>> +  - if: $SELECTED_JOBS_ONLY
>> +    when: never
>> +  - when: on_success
>> +  script:
>> +    - cd /root/
>> +    - ./xen_fuzzer -t ${FUZZING_TIME} run ${CI_PROJECT_DIR}/binaries/xe=
n test-mmu64le-arm-${HARNESS}-fuzzer 2>&1 | tee ${CI_PROJECT_DIR}/fuzzer-${=
HARNESS}.log
>
> Can you run it from outside the directory, like this?
>
> /root/xen_fuzzer -t ...
>

Well, right now it is looking for some QEMU files, like firmware image,
relatively to ${CWD}. It is possible to provide the full QEMU
command line along with -L option and then we will be able to run
it from anywhere, but, IMO, it is easier to just change directory.


>> +  after_script:
>> +    - cd ${CI_PROJECT_DIR}
>> +    - mv /root/crashes .
>
> Also here you could probably do:
>
> mv /root/crashes ${CI_PROJECT_DIR}
>

Yes, agree.


--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Mon May 12 19:50:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 19:50:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982104.1368650 (Exim 4.92)
	(envelope-from )
	id 1uEZAN-00040I-AY; Mon, 12 May 2025 19:50:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982104.1368650; Mon, 12 May 2025 19:50: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 1uEZAN-00040B-5p; Mon, 12 May 2025 19:50:23 +0000
Received: by outflank-mailman (input) for mailman id 982104;
 Mon, 12 May 2025 19:50:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEZAM-000405-HP
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 19:50:22 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 53b2efc8-2f6a-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 21:50:17 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 2AE8BA4C85A;
 Mon, 12 May 2025 19:50:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CD54C4CEE7;
 Mon, 12 May 2025 19:50: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" 
X-Inumbo-ID: 53b2efc8-2f6a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747079415;
	bh=tzLoLPXmHPCenoM8r3SLFf2RIKA16WxDCw5Blsv9Zlw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=lAj2d16fwvaH1yY0o7wiVCiYsQRnt/Z8vaLlUHHIbh05nRBH5ki4C8rAQ4tKcalRU
	 73hH+fWdFtQL7pRTWPqKq4uNpID1thLV15ZGFwOVdCOpIjElhfgQT49szOVVQDgmuK
	 VBIOR2J1XCP9DqVTD7pbYgXUbOeKFA3JwLUc8e/04zEizy5ZGf9MnbIyX38L8QdsPQ
	 DVF7r1TRypC6gndhHrZmPRbVyww0K7LgQbBOoq1+YjDpMA2wiWzq77KoWs5kFl+NOx
	 RKsPbDfegChp1Gybc0xLLc6JJAYdJmAKLJeiLshAdeFuTxy0jboOHgjSschWH8sQwh
	 KEIkdYk+7lkoQ==
Date: Mon, 12 May 2025 12:50:08 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Volodymyr Babchuk 
cc: Stefano Stabellini , 
    "xen-devel@lists.xenproject.org" , 
    Doug Goldstein 
Subject: Re: [RFC PATCH v3 2/2] ci: enable fuzzing for arm64
In-Reply-To: <87plgdd4s1.fsf@epam.com>
Message-ID: 
References: <20250507095338.735228-1-volodymyr_babchuk@epam.com> <20250507095338.735228-3-volodymyr_babchuk@epam.com>  <87plgdd4s1.fsf@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 12 May 2025, Volodymyr Babchuk wrote:
> Hi Stefano,
> 
> 
> Stefano Stabellini  writes:
> 
> > On Wed, 7 May 2025, Volodymyr Babchuk wrote:
> 
> >>  alpine-3.18-gcc-debug-arm64:
> >> +  extends: .gcc-arm64-build-debug
> >> +  variables:
> >> +    CONTAINER: alpine:3.18-arm64v8
> >> +    EXTRA_XEN_CONFIG: |
> >> +      CONFIG_UBSAN=y
> >> +      CONFIG_UBSAN_FATAL=
> >
> > The diff is strange and I might be wrong, but it looks like this should
> > be CONFIG_UBSAN_FATAL=y
> 
> Yes, looks like a mistake from my side.
> 
> >
> >> +alpine-3.18-gcc-fuzzing-arm64:
> >>    extends: .gcc-arm64-build-debug
> >>    variables:
> >>      CONTAINER: alpine:3.18-arm64v8
> >>      EXTRA_XEN_CONFIG: |
> >>        CONFIG_UBSAN=y
> >>        CONFIG_UBSAN_FATAL=y
> >> +      CONFIG_FUZZING=y
> >> +      CONFIG_FUZZER_LIBAFL_QEMU=y
> >> +      CONFIG_FUZZER_PASS_BLOCKING=y
> >>  
> >>  alpine-3.18-gcc-arm64-randconfig:
> >>    extends: .gcc-arm64-build
> >> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
> >> index a603d4039a..bb8670026f 100644
> >> --- a/automation/gitlab-ci/test.yaml
> >> +++ b/automation/gitlab-ci/test.yaml
> >> @@ -197,6 +197,30 @@
> >>    tags:
> >>      - qubes-hw11
> >>  
> >> +.fuzzer-arm:
> >> +  stage: test
> >> +  image: xentroops/xen-fuzzer:v1
> >> +  variables:
> >> +    HARNESS: hypercall
> >> +    FUZZING_TIME: 600
> >> +  rules:
> >> +  - if: $SELECTED_JOBS_ONLY && $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY
> >> +  - if: $SELECTED_JOBS_ONLY
> >> +    when: never
> >> +  - when: on_success
> >> +  script:
> >> +    - cd /root/
> >> +    - ./xen_fuzzer -t ${FUZZING_TIME} run ${CI_PROJECT_DIR}/binaries/xen test-mmu64le-arm-${HARNESS}-fuzzer 2>&1 | tee ${CI_PROJECT_DIR}/fuzzer-${HARNESS}.log
> >
> > Can you run it from outside the directory, like this?
> >
> > /root/xen_fuzzer -t ...
> >
> 
> Well, right now it is looking for some QEMU files, like firmware image,
> relatively to ${CWD}. It is possible to provide the full QEMU
> command line along with -L option and then we will be able to run
> it from anywhere, but, IMO, it is easier to just change directory.

OK


> >> +  after_script:
> >> +    - cd ${CI_PROJECT_DIR}
> >> +    - mv /root/crashes .
> >
> > Also here you could probably do:
> >
> > mv /root/crashes ${CI_PROJECT_DIR}
> >
> 
> Yes, agree.
> 
> 
> -- 
> WBR, Volodymyr


From xen-devel-bounces@lists.xenproject.org Mon May 12 19:51:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 19:51:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982111.1368658 (Exim 4.92)
	(envelope-from )
	id 1uEZBR-0004hM-HV; Mon, 12 May 2025 19:51:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982111.1368658; Mon, 12 May 2025 19:51: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 1uEZBR-0004hF-Eg; Mon, 12 May 2025 19:51:29 +0000
Received: by outflank-mailman (input) for mailman id 982111;
 Mon, 12 May 2025 19:51:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEZBQ-0004h9-Jl
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 19:51:28 +0000
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com
 [2607:f8b0:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7ced6cc9-2f6a-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 21:51:26 +0200 (CEST)
Received: by mail-pg1-x52c.google.com with SMTP id
 41be03b00d2f7-af91fc1fa90so4071083a12.0
 for ; Mon, 12 May 2025 12: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" 
X-Inumbo-ID: 7ced6cc9-2f6a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747079485; x=1747684285; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fy55oasryzHFf+6/8nS49qGQuO8xmK/rl+QKDdDFLaA=;
        b=IM1aLO5tZ+fmZumnOJFmwLlrf7noXTVPhtELskI4e/XvF9RRFHkHkAHo5n1jvSIkV9
         UvF2H0mLCWTM0Ip0JMyJRF2fsMz5dDSm8mL8Y64Zq8u5GSSAk6aV3M++YK9e5jwugNa6
         Lp+cchPcmUN/Jj1cBWLsJgTgh10OKhHEN78HA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747079485; x=1747684285;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fy55oasryzHFf+6/8nS49qGQuO8xmK/rl+QKDdDFLaA=;
        b=P0PTAVQGFUOh5/oXzk8UdTA7YbF7XhOLPyhYlx3gcKkIPOFHLV8avNdhL7e+tXHOoi
         /W5yXp25TA5Gyhi9I7g/TqkxetXG4LUfttPXE+3y+BbyZhtn5+wL4EdmxZdGlVNyX5c4
         bYMrnp5WzoAkKEjtmzkuVUCDdWo1tk2nV/K4BNaxeC34JC3TFQ9PvOElRF03SCgW7PMj
         X8LEsHxR803Qiyldgn3o9RZmgoKtq7XgmmW75kd8X2pBm+dBl7JumtDlnpwNAXk1lBm4
         0Oegj0Af2AD0KmAD60Fm9LxjLllJ8pHUY6pEe/rRjkrw5pUfqoQjkAXgMwkbu9xvL0JM
         cf7w==
X-Forwarded-Encrypted: i=1; AJvYcCWfVg1oOa3a43/ZxdoHSgorwG9GF15IVY0j3KXi/3BQ+x8UQK3QAkDnFjRwBsOE4W5B0oZ9vj2Dzgs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzL3TUUY6nW6Ao3Efghm67jluOK/NSmuQJndYOWheg9GzoDphJA
	VFST0PcCj2XxAl+vXp3aziT2lYm/HxmcrZ6Hplh3OR6c+Hz35HrQ5FIOf6DWz2LGsBkJvmR+c7o
	WnJ4sK6gPLZhXPX+oOsbfyfjEmr95J5MGiFk/Vg==
X-Gm-Gg: ASbGnctFx3vj2GltEWRUmo9FL9vwPk6hX8MqsMwSpT2FUdhA/MFm7K2rHLK9mgzxohj
	JtAIKcn5nZxPVqnrByrC43FbfuCddORshGCfkKtmkhu+MADlVR6fqQF2QdFSCQl5E3TPmRSjPbA
	rqd2a8/d9H0VyzvWWoh0RFaL+kEQWeO4k=
X-Google-Smtp-Source: AGHT+IHMjWF9bZOpluLTAZWkfejyWmEm7tMplZsXI7HMT3url/Q+p/yPRo5o8wffOXkL+d9pQgZ6Mi0JTXUsucxCA3M=
X-Received: by 2002:a17:903:41c1:b0:22e:62c3:6990 with SMTP id
 d9443c01a7336-22fc8b33517mr182103975ad.16.1747079485041; Mon, 12 May 2025
 12:51:25 -0700 (PDT)
MIME-Version: 1.0
References: <20250506162510.1676425-1-kevin.lampis@cloud.com> 
In-Reply-To: 
From: Kevin Lampis 
Date: Mon, 12 May 2025 20:51:13 +0100
X-Gm-Features: AX0GCFvnRToYWacK64ua10lcXPyrNZliAql0Ch5T2-6fZdJ1Wz0wy6WLkmhb_NI
Message-ID: 
Subject: Re: [PATCH 3/4] Add lockdown mode
To: Jan Beulich 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 12, 2025 at 11:39=E2=80=AFAM Jan Beulich  wr=
ote:
>
> I can't spot the effect the comment mentions anywhere in this patch. Is t=
he
> description perhaps lacking some detail? It's rather odd after all to see=
 ...
>
> ... such custom token splitting ahead of normal command line handling.

If the UEFI firmware reports that secure boot mode is enabled then Xen
lockdown mode will always be enabled.

But we also have a command line argument to enable lockdown mode without se=
cure
boot. This is the thing that lockdown_init() is looking for.

It is important to know if we are in lockdown mode or not before parsing an=
y
other arguments. Otherwise there will be a race between parsing potentially
unsafe arguments and finding the lockdown enable argument.


From xen-devel-bounces@lists.xenproject.org Mon May 12 19:52:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 19:52:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982120.1368669 (Exim 4.92)
	(envelope-from )
	id 1uEZC4-0005Ei-VC; Mon, 12 May 2025 19:52:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982120.1368669; Mon, 12 May 2025 19: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 1uEZC4-0005Eb-Rc; Mon, 12 May 2025 19:52:08 +0000
Received: by outflank-mailman (input) for mailman id 982120;
 Mon, 12 May 2025 19:52:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEZC3-0004zZ-4L
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 19:52:07 +0000
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com
 [2607:f8b0:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 94bf6181-2f6a-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 21:52:06 +0200 (CEST)
Received: by mail-pg1-x531.google.com with SMTP id
 41be03b00d2f7-b1a1930a922so3571689a12.3
 for ; Mon, 12 May 2025 12:52: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" 
X-Inumbo-ID: 94bf6181-2f6a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747079525; x=1747684325; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=rGTv3/aA0s0HwZUogkKn2jUr+jH8cCBc+j6D0zSQ/PQ=;
        b=QSMCqXQNJHcoGCGYqknlfQDpiRz6qOOgdJ9zBGB/ih+dijNwi2cXLEk8na8h6/eSFR
         iqVN5XlUgVF9DvaKs60PCVnz1ZSRlqtcWq/uo9LUb26Dh11ZYIe9JvfbolsmagXjpXP0
         PJFhWgRAbDTwUydLRKAso/DOll6U5g/igMrRw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747079525; x=1747684325;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=rGTv3/aA0s0HwZUogkKn2jUr+jH8cCBc+j6D0zSQ/PQ=;
        b=BHfmGYJdqwhmnsRWVyBbKNKDm5NX6+rg55lBV0BXH2xmqHypHPSt6dE7gXWbwTPtxH
         GLtRjEaG0gCEGSOGpr5W8ZoWD3iROzBQxLSG8rT0N7S9Y/RC2wDOfKf7aXcQQ+w0Zuaa
         o+GJ6elvpUpPIwBznelbjYcmm6rv/+Q7OAqxOGTzQxZpWnXxFHG1JqAWkmC/6JLn2Seo
         ufXk+o0sR+/qB+Po3HayCxuzbh6C4Eu3UiVYWriIW0n6ekxZA9nPTorTxqLcRm9EiQI0
         DEK6IZAE55rl392+hUSl3ValMYdWmsSBKb5KpAjPZuiAFEub72yVdIucrueeD8NFDc3c
         iYFg==
X-Forwarded-Encrypted: i=1; AJvYcCW4wdqHSh/dJ9QK1XEP5LA1KqmTTfAbmy+CVka1psaBx5cBMSjuXEfsia+uNbC54zHfaxBRkeWRpkY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyDw710yGPaOsDt4jaNIJD5H0cJVkSTf0QLdHubCYFGLDjWkKo1
	spCwjRjWHihivDSSzCSpMPUhdTHw35Vuo5xQCT23M3PXyiiSTErCMod7rlhIOLBbhpWCJSGPtZz
	nZUe/b3CJK6ZZen6FcApJZp9i0cqCk4hVQhdAow==
X-Gm-Gg: ASbGncsV96B7s99doV3nCYf+kskaHjL9Gq6jnaUboEoKzOMmJnNjW1lVzSsbdXvrMCc
	XF9tjDereO8EHDlqewBCUzve24a2BE7fCewuluQbqsY0qLKz6c9/jloNG5kALJGgPzh3ylti3RU
	g7M9o4bOI0H1useSRSN1DuUopGVukSX8Y=
X-Google-Smtp-Source: AGHT+IFsWMPz3f8zOO8mOEYTFNd80BUVgatRmSmeE75kxwRXdpKaj/7wZ8rrWasZUn+qIt9cSX6y0Y5XPjhtjjRUouQ=
X-Received: by 2002:a17:902:ecd0:b0:22e:634b:14ca with SMTP id
 d9443c01a7336-22fc91aeceamr200811645ad.50.1747079525096; Mon, 12 May 2025
 12:52:05 -0700 (PDT)
MIME-Version: 1.0
References: <20250506162347.1676357-1-kevin.lampis@cloud.com>
 <10454237-2ada-4972-8e31-8ae21a6d6d22@suse.com> <33bb2c1d-0283-4cea-b1ce-84ef0ea950ad@citrix.com>
In-Reply-To: <33bb2c1d-0283-4cea-b1ce-84ef0ea950ad@citrix.com>
From: Kevin Lampis 
Date: Mon, 12 May 2025 20:51:54 +0100
X-Gm-Features: AX0GCFsaNp41-24XDxqXzlJQ-Vs6m3D4Sxow2Yl1RJMnL8qLHEGwMwCtm8cvLjU
Message-ID: 
Subject: Re: [PATCH 0/4] Add lockdown mode
To: Andrew Cooper 
Cc: Jan Beulich , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 12, 2025 at 12:51=E2=80=AFPM Andrew Cooper
 wrote:
>
> Kevin: It will be best to resend the series in full.

Ok.


From xen-devel-bounces@lists.xenproject.org Mon May 12 19:55:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 19:55:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982133.1368679 (Exim 4.92)
	(envelope-from )
	id 1uEZFY-0005r3-D6; Mon, 12 May 2025 19:55:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982133.1368679; Mon, 12 May 2025 19: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 1uEZFY-0005qw-9y; Mon, 12 May 2025 19:55:44 +0000
Received: by outflank-mailman (input) for mailman id 982133;
 Mon, 12 May 2025 19:55:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEZFW-0005qp-Rc
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 19:55:42 +0000
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com
 [2607:f8b0:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1476a591-2f6b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 21:55:40 +0200 (CEST)
Received: by mail-pl1-x62c.google.com with SMTP id
 d9443c01a7336-22fb6eda241so49893185ad.1
 for ; Mon, 12 May 2025 12: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" 
X-Inumbo-ID: 1476a591-2f6b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747079739; x=1747684539; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TC6QgwCA+pWMQ2oM+iySTdBksZruENYT9g05czYu/tk=;
        b=cU8KP4nt6GE4UTlmqMAOWEf/85hcYV5SYwQ3nH05FCumiqDyeQ2j2jtw4u+BybH/4T
         rm4o6lplUF0CqfUqV7o/RIBNDq+M67uq4JozD2npurJL2es6DgqSVD0IfXFpjfWHnELz
         v4YSqf7jF4CbJVUtJlFli1TZ8h8zomnDc0yDA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747079739; x=1747684539;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=TC6QgwCA+pWMQ2oM+iySTdBksZruENYT9g05czYu/tk=;
        b=sLk1I+ySRocJ8xCAaxq0Tr5ICtcjz1gk1ZoWNmZdMjpucC5uYRAto8SCYv/dDB1Nma
         y+OjulBZO8+j07E58CMjFMVJ9uAUHts3XFXF/zwKfT9QuciatyceE6vnc5Pq1ocaaW/Y
         By8kOiGJn+mdTgfCraV21yIR2/nNR4y7U+kyg5J03SaApe3Adkg4BUotOiAHBQKknKjO
         A41HvYZ4RQHtuFHSJDl4v45w3xQHj2zkVtDxwRS9DxmFfXFrkAP44wrgLN9EqitmVMqR
         cRHFUje7tmpXEjBQ7DzRoduKj2gv3/xWt5+5eLuWodMAJkx/0zv+0uS7evOUxkfOh6Zv
         1epA==
X-Gm-Message-State: AOJu0Yyw/Vvo6gzWPYS+G18AW/kcB5l5MYjz/h/B2gTAKd6AL5GEWHdV
	z7hCP0PSmuIZJLm38G0UfYaquPgsWyAs33/d4Z6ywl3fTPYUFA/2V82F13E7iLuwLTWBH4TPpym
	QujPre7GsQMcBAUI9ldPDgJSgro8AuI49zuLHsEhFJzYBAvlTOKg=
X-Gm-Gg: ASbGncubMcWls8vOKvpXC99qlMkF2lRdAFp3gtQ0yo5BsTa/ukcdFnujuX+YP7/WiGP
	g+MN8mfB6MwubR8dtg1859d/bSzX4pf5LWAmQ3P9+plfLn26PQj5Q7DEfcZlo+1TzQ8EpecN0uv
	O684lP3Yp2cgl/9xSE18UJoMzcBn3+vcMDVtesDsg9sQ==
X-Google-Smtp-Source: AGHT+IFKl9T9y1sJD966XrUuSqDHOkY2ht9zjfm1rUALC6ttmFO31L1VKgFTJe7J+UrqSdoGTi3Gch405WFqExqIA+0=
X-Received: by 2002:a17:902:e94d:b0:224:24d5:f20a with SMTP id
 d9443c01a7336-22fc91c2cdcmr239387365ad.48.1747079739267; Mon, 12 May 2025
 12:55:39 -0700 (PDT)
MIME-Version: 1.0
References: <20250506162347.1676357-1-kevin.lampis@cloud.com>
 <20250512090210.1718623-1-kevin.lampis@cloud.com> <3e35eeb3-c4f6-423e-9185-5d98b6d1d060@vates.tech>
In-Reply-To: <3e35eeb3-c4f6-423e-9185-5d98b6d1d060@vates.tech>
From: Kevin Lampis 
Date: Mon, 12 May 2025 20:55:27 +0100
X-Gm-Features: AX0GCFvsPgEmEPDSFsBKkCo8Zwl-tzhdXmiTpV5O3pRiJDCJUbcj7yuc3c25qdA
Message-ID: 
Subject: Re: [PATCH 4/4] Disallow most command-line options when lockdown mode
 is enabled
To: Teddy Astie 
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 12, 2025 at 12:48=E2=80=AFPM Teddy Astie  wrote:
>
>What makes max_cstate / dom0-max-vcpus / dom0-mem specifically unsafe ?

These arguments are all allowed. The *_secure_param macros mean the argumen=
t is
safe for lockdown mode.

Making PCI passthrough safe for secure boot will be handled in a
different patch.


From xen-devel-bounces@lists.xenproject.org Mon May 12 19:56:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 19:56:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982138.1368689 (Exim 4.92)
	(envelope-from )
	id 1uEZFw-0006HG-Kb; Mon, 12 May 2025 19:56:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982138.1368689; Mon, 12 May 2025 19:56:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEZFw-0006H9-HF; Mon, 12 May 2025 19:56:08 +0000
Received: by outflank-mailman (input) for mailman id 982138;
 Mon, 12 May 2025 19:56:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEZFu-0005qp-U1
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 19:56:07 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20611.outbound.protection.outlook.com
 [2a01:111:f403:2413::611])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 20ae51c4-2f6b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 21:56:02 +0200 (CEST)
Received: from CH3P220CA0025.NAMP220.PROD.OUTLOOK.COM (2603:10b6:610:1e8::14)
 by SA1PR12MB8698.namprd12.prod.outlook.com (2603:10b6:806:38b::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.30; Mon, 12 May
 2025 19:55:55 +0000
Received: from CH3PEPF00000009.namprd04.prod.outlook.com
 (2603:10b6:610:1e8:cafe::7f) by CH3P220CA0025.outlook.office365.com
 (2603:10b6:610:1e8::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.30 via Frontend Transport; Mon,
 12 May 2025 19:55:55 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH3PEPF00000009.mail.protection.outlook.com (10.167.244.36) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Mon, 12 May 2025 19:55:54 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 12 May
 2025 14:55:54 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 12 May
 2025 14:55:54 -0500
Received: from [172.31.225.170] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 12 May 2025 14:55: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" 
X-Inumbo-ID: 20ae51c4-2f6b-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HqW8LoHQU+kdPA7n5YbKZk+Jfnf4qTDtwyuLxsAKDRT9E6ZyNXhqo7tXJTyPF5SFHoZj45DnON2/4nGp+XQRePgFNgOBYMYUp/7afNunJ326Sa7FuZtAZnbdOP1GiliRdMRqboO46iiPlexpXnI/bw5T2ea8Fni/pvKnIxZoqmfdhdsOOomBjPl/J71S51NEElQfglnn9yzIHXqXg0udemYEzg+2BQT6EcBVoplwdM+R96srbcqrP8Uw31DNXtwRMhiB0e8gBx8T4u4Di3UcRPMj1QxE3ubmZDo2C6t+uxkAguoMZK7xIMdwx/oiWsY9/pwCTgXVWTPm/3VqglnZeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LYb0PTbwQxErNmiU8qGtircbIDEffozMNuruRuqBXE0=;
 b=pcyViN8p78Mkmu9W/fdZQZ16fb3BSR/wWnfkQXEjLZ2TONebi5N/RjSNaDFwo/tpYDBJsauOL1VNeZJj66hgo264IUVbmrjbCnPoUUvVVRLAh16mq/6NliXwYnuLom2+ydCCmJnGNMtV74DJvg3XSVhlXTcj6kxfkdYeAmpect+8qW3hVWz14L51FRrayxtcVLPAHT7WhcQ5YImDqBT+rDSfJfLLfMXo88nsK8f8M75WK6v6eU8nH6ST5bO9gGNBVoJJYZVGW1xLMkC9q6F4/h+zOW5Gyaz8B77cPO6ij4CypOqmuJ724LGzMTkOxdcTQDY2t9nYTS47dPXNz4DMRw==
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=LYb0PTbwQxErNmiU8qGtircbIDEffozMNuruRuqBXE0=;
 b=25q/NIvZoUokxb8PfWJPD/KMitDU/4ZhYNHijhyVAvmDxH6x7AlyhbqLcKnWheZO0gAXPYjoPEsFxVh2cMwIJfeExCm6kpHqvwb83om0tp8sdbraA9XtqX7P0T7r5jntLhsLNi37JczKKehUge8H9Z2nHSnAMRjsyZ46x3CSfAM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <56975c31-a088-43bf-80a5-65da6cc00221@amd.com>
Date: Mon, 12 May 2025 15:55:52 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/6] xen/arm: exclude xen,reg from domU extended
 regions
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?=
	
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
 <20250508132040.532898-6-stewart.hildebrand@amd.com>
 <3caa25d7-9faf-4099-a0a2-f7014c01e1ce@amd.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <3caa25d7-9faf-4099-a0a2-f7014c01e1ce@amd.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF00000009:EE_|SA1PR12MB8698:EE_
X-MS-Office365-Filtering-Correlation-Id: 2e6bf63c-6e91-4a6e-01d3-08dd918f0190
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bUdicGgxY0lNeGp5MFVHQW9GdHVoeUhmNTVqNGZoa3RjMVBRRGMzOGNZdDRZ?=
 =?utf-8?B?U1VhbU5YNlErRWlWeUYrMVBmZkloVkUzaGNyR3QvK0FZa0Z5bU53TzkwVEZi?=
 =?utf-8?B?cWJxQVNlSkdrSnVTYjk0ZmhKQW8wQWYzVHZsRlQ0WWZHM00rcTU1LzM0YzJq?=
 =?utf-8?B?cGFSOTJsNC9EMVZGM0JJODRJSWNyaFdiOWZIalplVkJ2QVJkZ2ZhWHJvNFZz?=
 =?utf-8?B?N01sNktwUmZ3WTVIT3F6MTROTEdLWGtpV3Myc0tMNDNwNzBzdkxIUW0xQkNn?=
 =?utf-8?B?Y04yclVCcGZnNFJaOU05cGZjSmVTYXNmcmZDNjNQbUNNVjB6N2RtSGVMaCtT?=
 =?utf-8?B?SFowNTlvWGJ0L1BpcjVraXZkcUR6Y0h6ZlhUOXhBNTZrdXFtYkhaRTkrTVYr?=
 =?utf-8?B?cFBVOHgrWkNiQ0liUkI3OTM2K0pqNVhOSnhlQjdHcmZ2c00xOEE2azc1VWo5?=
 =?utf-8?B?QjBmZVdnQVc4bE1SSTdhVXBYUjFPVmdHUTNMUVhsOFZnMElUaGJuT2tNZUU0?=
 =?utf-8?B?dTg3b3JrNm91MDBSR3RmK01oVnFDd0p0bFVCQWQxU2dsVDd0VG41WUVrTHJo?=
 =?utf-8?B?UVpMUjlKaC9BYlNCckRUOTJyU3JXNFgwbzJkN29xUE9XektLL2VZTXVlRGhM?=
 =?utf-8?B?VGdSNUc5OVIyK29Danc2dkFzUEN4cWlzbzFVbG1pcm8zSzRPaUxXNDh4dnJS?=
 =?utf-8?B?WnhjZkc3d2ZEWUt1N2xwWUxWNlh1amJtZG1yUEVzYnh0QzJhWUJlcmdLMHpi?=
 =?utf-8?B?YWtWS0tDSkJpQ095Sjd5dmdCN0NNejJVRFhsTDlTVDgxTG55enFNdFI2VVJy?=
 =?utf-8?B?Rzk4UkJ4YldxRW5JcnArQ0wyR0oxWjlkQzhOdDFRNXJLd0FBZ0Nib1ExWXhG?=
 =?utf-8?B?dFEyMkZHUERJRlRIT3dYbnpudXZXcFc5UmtPbXp2MndkbHptWW5qbkY4WVF1?=
 =?utf-8?B?RWdNMUZIU3lwZmR5SVkrMFAvc1lqNWoreHdaMDFKek1VdTM0TktOUDNmaGpS?=
 =?utf-8?B?Z2xiS2RpQ3Urckd3cWhrblZONlBLSW05Z01zaUVPVkRqRk5zak9oNlhKZExZ?=
 =?utf-8?B?aElKU3pZd1FjaHVobEQ5SlkwYXl4eUVXS0gwSU02WmszSXdQSEJHMzZHeGdI?=
 =?utf-8?B?NE1TbHlXcnNPM1RjSjhUbTg5RjFPUE5ZMk9veEpkUDZBYkxrS05KbkdWZVpq?=
 =?utf-8?B?M3g4eW1Fdml3b2xIRzEveUZHNnREZW9LeUVDYVdxcE9mVlozVGNqc0ZESS9M?=
 =?utf-8?B?aDRmaktDYkNDUWJGVG1HT3NtN3doNzZZUFBUbU5ocVkyZGFwK0tTTFBNQUhR?=
 =?utf-8?B?U051RTdOM1JNa1NJTnZZMXRyOVpoeVNGd0p1SC9LS0Z5STV0N1VlM2JjTUhX?=
 =?utf-8?B?WXNuR2k5M3hDT1g0a1ZSVUVROGlRT1gyTUFwcXRpNDhtZ3BJd0tnMzY4MXVC?=
 =?utf-8?B?Ly9tSVNVV1F5dk0vME5vYmRBSlE3Zjc3SFVRdlRtUGVzWTdYYjZCalc0VjdJ?=
 =?utf-8?B?TFlEZ1IyYy8zZ291K1BqbUNtMHlZay9rS2NhVCtSZVFLcit0V2JSajJlYUQw?=
 =?utf-8?B?S0RycWN0dXBKU283cWxuOHcrSjQ0cm9kN0NTLzg4amRJUkdEbzdnbmJpNjhw?=
 =?utf-8?B?SDVjcWhzNWx5ZlV3ZmhEdW1zZGRocGNuUmxockVtRVBJRWY3Q3h3aTdkMlZF?=
 =?utf-8?B?TUxkY0dxalZiTy95ZnJ0eUsyRVV4QkRMNEJJZHpFRFF1VDdPeG4wdk1rclpG?=
 =?utf-8?B?VkFsUnhvWTJoNUQyODArN0MrU2l5UEpMTit0VmFTZnBnMHZzNHVSREZSeXI0?=
 =?utf-8?B?aS9BZVZnVmM0TVRCQ1pyUHp6Ync5UTk5VTVVNVBYanF4UFBEWVB4em5aREtK?=
 =?utf-8?B?MUcwM0Jpa2Q2WEF4bWRpcWkxRnMweVp2NHpVNzdFTGNhcElzbzVDQTcvemZX?=
 =?utf-8?B?UklTbzFVU1h4OGhJZjNuazVyS2lrN084RVQyK2FvRlhuSWNIeWNsQmdKWThO?=
 =?utf-8?B?M2g5YXdtMDZkdkFLYW1FcUN1dmJjY2ExMGVXbndTc29mNFBqNzl4Ty9HK0Zh?=
 =?utf-8?Q?wHlRHR?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2025 19:55:54.8447
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e6bf63c-6e91-4a6e-01d3-08dd918f0190
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF00000009.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8698

On 5/9/25 02:54, Orzel, Michal wrote:
> On 08/05/2025 15:20, Stewart Hildebrand wrote:
>> diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
>> index 7a6cd67c22f1..1939c3ebf7dc 100644
>> --- a/xen/include/xen/fdt-kernel.h
>> +++ b/xen/include/xen/fdt-kernel.h
>> @@ -24,6 +24,7 @@ struct kernel_info {
>>  #ifdef CONFIG_STATIC_SHM
>>      struct shared_meminfo shm_mem;
>>  #endif
>> +    struct rangeset *xen_reg_assigned;
> The purpose of your newly introduced xen_reg_assigned is to keep track of these
> ranges so that we can remove them from extended regions. The concept of extended
> regions exists only for Arm today. Therefore I'm not sure why making all these
> common i.e. entry in struct, rangeset allocation, etc. The other aspect is that
> extended regions may be disabled by the user and you would still allocate
> rangeset and add xen,reg to it for no purpose - i.e. dead code.

How about an arch hook? E.g. see work-in-progress/untested patch at the
end.

> Also, what about direct-mapped domUs? We don't seem to take xen,reg into account
> there.

Right, we ought to take xen,reg into account for direct-map domUs too.
This is because, even though the domU is direct-mapped, xen,reg can
still set up a translated mapping (gfn != mfn). Also, xen,reg doesn't
need to correspond to a real device, it can be any arbitrary mapping.
I'll send a patch.

> P.S.
> After recent dom0less code movement there are some issues that I reported to
> Oleksii. Long story short, we shouldn't be making the code common (e.g. static
> mem, shmem, domain type) that is implemented for now only for one arch. If the
> need arises in the future, the feature code together with callers can be moved
> to common. At the moment, we have some features being in arch specific
> directories but callers in common code and #ifdef-ed (making the stubs
> unreachable). That's not great.
> 
> ~Michal



diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae9f..f099e27d846c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -929,6 +929,31 @@ out:
     return res;
 }
 
+int __init arch_add_xen_reg(struct kernel_info *kinfo, paddr_t gstart,
+                            paddr_t size)
+{
+    if ( !opt_ext_regions )
+        return 0;
+
+    if ( !kinfo->arch.xen_reg_assigned )
+    {
+        kinfo->arch.xen_reg_assigned = rangeset_new(NULL, NULL, 0);
+
+        if ( !kinfo->arch.xen_reg_assigned )
+            return -ENOMEM;
+    }
+
+    return rangeset_add_range(kinfo->arch.xen_reg_assigned, PFN_DOWN(gstart),
+                              PFN_DOWN(gstart + size - 1));
+}
+
+int __init arch_cleanup(struct kernel_info *kinfo)
+{
+    rangeset_destroy(kinfo->arch.xen_reg_assigned);
+
+    return 0;
+}
+
 static int __init find_domU_holes(const struct kernel_info *kinfo,
                                   struct membanks *ext_regions)
 {
@@ -973,9 +998,9 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
     if ( res )
         goto out;
 
-    if ( kinfo->xen_reg_assigned )
+    if ( kinfo->arch.xen_reg_assigned )
     {
-        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
+        res = rangeset_subtract(mem_holes, kinfo->arch.xen_reg_assigned);
         if ( res )
             goto out;
     }
diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
index 7c3b7fde5b64..8d6bd2dd77f9 100644
--- a/xen/arch/arm/include/asm/kernel.h
+++ b/xen/arch/arm/include/asm/kernel.h
@@ -16,6 +16,8 @@ struct arch_kernel_info
 
     /* Enable pl011 emulation */
     bool vpl011;
+
+    struct rangeset *xen_reg_assigned;
 };
 
 #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 2c56f13771ab..654575612744 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -146,14 +146,6 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
     int res;
     paddr_t mstart, size, gstart;
 
-    if ( !kinfo->xen_reg_assigned )
-    {
-        kinfo->xen_reg_assigned = rangeset_new(NULL, NULL, 0);
-
-        if ( !kinfo->xen_reg_assigned )
-            return -ENOMEM;
-    }
-
     /* xen,reg specifies where to map the MMIO region */
     cell = (const __be32 *)xen_reg->data;
     len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
@@ -196,8 +188,7 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
             return -EFAULT;
         }
 
-        res = rangeset_add_range(kinfo->xen_reg_assigned, PFN_DOWN(gstart),
-                                 PFN_DOWN(gstart + size - 1));
+        res = arch_add_xen_reg(kinfo, gstart, size);
         if ( res )
             return res;
     }
@@ -828,10 +819,10 @@ static int __init construct_domU(struct domain *d,
     domain_vcpu_affinity(d, node);
 
     rc = alloc_xenstore_params(&kinfo);
+    if ( rc < 0 )
+        return rc;
 
-    rangeset_destroy(kinfo.xen_reg_assigned);
-
-    return rc;
+    return arch_cleanup(&kinfo);
 }
 
 void __init create_domUs(void)
diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
index e0ad0429ec74..3e577e4dbe10 100644
--- a/xen/include/asm-generic/dom0less-build.h
+++ b/xen/include/asm-generic/dom0less-build.h
@@ -61,6 +61,10 @@ void set_domain_type(struct domain *d, struct kernel_info *kinfo);
 int init_intc_phandle(struct kernel_info *kinfo, const char *name,
                       const int node_next, const void *pfdt);
 
+int arch_add_xen_reg(struct kernel_info *kinfo, paddr_t gstart, paddr_t size);
+
+int arch_cleanup(struct kernel_info *kinfo);
+
 #else /* !CONFIG_DOM0LESS_BOOT */
 
 static inline void create_domUs(void) {}
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 1939c3ebf7dc..7a6cd67c22f1 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -24,7 +24,6 @@ struct kernel_info {
 #ifdef CONFIG_STATIC_SHM
     struct shared_meminfo shm_mem;
 #endif
-    struct rangeset *xen_reg_assigned;
 
     /* kernel entry point */
     paddr_t entry;


From xen-devel-bounces@lists.xenproject.org Mon May 12 19:56:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 19:56:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982142.1368699 (Exim 4.92)
	(envelope-from )
	id 1uEZGH-0006nI-TD; Mon, 12 May 2025 19:56:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982142.1368699; Mon, 12 May 2025 19: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 1uEZGH-0006nB-PY; Mon, 12 May 2025 19:56:29 +0000
Received: by outflank-mailman (input) for mailman id 982142;
 Mon, 12 May 2025 19:56:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEZGG-0005qp-Hg
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 19:56:28 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3054e78a-2f6b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 21:56:26 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5f3f04b5dbcso7842988a12.1
 for ; Mon, 12 May 2025 12:56:26 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197be0c5sm656407366b.153.2025.05.12.12.56.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 12:56: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" 
X-Inumbo-ID: 3054e78a-2f6b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747079786; x=1747684586; 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;
        bh=Hc2UwIOft6g44ulLRyYuoDx+xTjE0jFaTJyTkT+U7m8=;
        b=dsZP1/4tPXcaSzmw3sw1uynawBmwjyzwIBtpt6wxNXkzujDGvcFYaGQM9gFnCKJNS/
         OwGF8FVmiVBgRhH+zT3gWiyXNfVzSzMTXmPW19o0Wlaj7L/ckF8T+FAbvB0uEevm9wwv
         M5CpWDVMS1I73BhX54RLo86qk5L2Y8VHnlBwE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747079786; x=1747684586;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Hc2UwIOft6g44ulLRyYuoDx+xTjE0jFaTJyTkT+U7m8=;
        b=ejS8pxpblmPf7Nlbdjv7H2w635v56wQArdQqOzKU/QI6gWsJHw/8n69VEvQKGG75Mr
         jQPXcD9Bf4gcwmk5WCeWPj2lrlspuMjONoqI9MLsk6H14drPybdt7lnNDsm9RDvORQ9H
         uEBSv1Jrh7EpE//fYl3T4ulGeaJIuI5BM1QmLGnerBfJ4Y3lKN+NiFzqr8x0lxMdqHRE
         I7wEzBXqXO89sg0EroxVzwNKn6Sj1SFThysbbtSTM4dQVBzGVA2aOpX+V8OT0DpBMUPC
         iYn1zRg6HXCYpCRYmQlFI1XYIwF9PWOCwhIb6wdgOGhwKnqAM8fm0qPH40NIJXA5F54G
         +wlQ==
X-Gm-Message-State: AOJu0YwZ9SGuTUyZQTz2lODdibyzjkFQzPVqdLzFEOMZBH0/P/DZEiqg
	KM0m7G+byhc/hKEutWZo84a4V4fcvW7urjdfMKg478lSL1rZwYdegyPKWiypowU/FDDLHw89M5S
	g
X-Gm-Gg: ASbGnct2648/EmuICubTUfFkoa/ADU3HEYsgrOhsJyZq79z5/WVAtD5/v8vL7i476uu
	Mr8HSDQcwrpryPWf2R7QyNt/qTx2S1di08QzEtpMAPw0re2avibry1prGwLaiEBbj9iv1KD/ehI
	RM87jxEibd+tyqUKHvOdmgGD98aK0G6dSWE0TKmBhzxX9jVzwQVER5FGU+DGjgfVP0SuR3vtbX0
	CEAKnoHGa8f/djfXFSjs2rsvQzAPx8hEX3o8OuMA36hl98iYdesdsAZRDRMKJQR8VoR3FArsjW2
	93HcK8v/Ux0et78VIVGNeGg1A5U/E8mFuS9/12Gq3tPkEvNiSlt2MWbwbNAzzgrFnCOH
X-Google-Smtp-Source: AGHT+IE9pvRn/xzAKnL4oS+dppcEd/5LA1WeGBehGBHA2P6lkqTp22UHhwOgcTndSpr/HPMiJ/w8fw==
X-Received: by 2002:a17:907:968b:b0:ad2:2417:12d2 with SMTP id a640c23a62f3a-ad224173b1cmr1150435066b.42.1747079785599;
        Mon, 12 May 2025 12:56:25 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: Kevin Lampis 
Subject: [PATCH 0/3] Add lockdown mode
Date: Mon, 12 May 2025 20:56:25 +0100
Message-ID: <20250512195628.1728455-1-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The intention of lockdown mode is to prevent attacks from a rogue dom0
userspace from compromising the system. Lockdown mode can be controlled by a
Kconfig option and a command-line parameter. It is also enabled automatically
when Secure Boot is enabled and it cannot be disabled in that case.

Ross Lagerwall (2):
  efi: Add a function to check if Secure Boot mode is enabled
  Add lockdown mode

Kevin Lampis (1):
  Disallow most command-line options when lockdown mode is enabled

 xen/arch/arm/domain_build.c           |  4 +--
 xen/arch/x86/acpi/cpu_idle.c          |  2 +-
 xen/arch/x86/cpu/amd.c                |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c         |  2 +-
 xen/arch/x86/cpu/microcode/core.c     |  2 +-
 xen/arch/x86/dom0_build.c             |  4 +--
 xen/arch/x86/hvm/hvm.c                |  2 +-
 xen/arch/x86/irq.c                    |  2 +-
 xen/arch/x86/nmi.c                    |  2 +-
 xen/arch/x86/setup.c                  |  3 +-
 xen/arch/x86/traps.c                  |  2 +-
 xen/arch/x86/x86_64/mmconfig-shared.c |  2 +-
 xen/common/Kconfig                    |  8 +++++
 xen/common/Makefile                   |  1 +
 xen/common/domain.c                   |  2 +-
 xen/common/efi/boot.c                 | 23 ++++++++++++
 xen/common/efi/runtime.c              |  3 ++
 xen/common/kernel.c                   | 13 ++++++-
 xen/common/kexec.c                    |  2 +-
 xen/common/lockdown.c                 | 52 +++++++++++++++++++++++++++
 xen/common/numa.c                     |  2 +-
 xen/common/page_alloc.c               |  2 +-
 xen/common/shutdown.c                 |  2 +-
 xen/drivers/char/console.c            |  2 +-
 xen/drivers/char/ns16550.c            |  4 +--
 xen/drivers/video/vga.c               |  2 +-
 xen/include/xen/efi.h                 |  6 ++++
 xen/include/xen/lockdown.h            |  9 +++++
 xen/include/xen/param.h               | 49 +++++++++++++++++++------
 29 files changed, 176 insertions(+), 35 deletions(-)
 create mode 100644 xen/common/lockdown.c
 create mode 100644 xen/include/xen/lockdown.h

-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 19:56:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 19:56:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982145.1368709 (Exim 4.92)
	(envelope-from )
	id 1uEZGP-00076w-8L; Mon, 12 May 2025 19:56:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982145.1368709; Mon, 12 May 2025 19: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 1uEZGP-00076p-44; Mon, 12 May 2025 19:56:37 +0000
Received: by outflank-mailman (input) for mailman id 982145;
 Mon, 12 May 2025 19:56:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEZGN-0005qp-OK
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 19:56:35 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 34bb4ed2-2f6b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 21:56:34 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5fc8c68dc9fso2765686a12.1
 for ; Mon, 12 May 2025 12:56:34 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197be0c5sm656407366b.153.2025.05.12.12.56.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 12:56: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" 
X-Inumbo-ID: 34bb4ed2-2f6b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747079793; x=1747684593; 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;
        bh=vko/TdS4oIy2sjncEqYDjmf9vGJvEJOwtxlN9MhiSlw=;
        b=QpOsgWNBG+HpZdKis7dZdD+lE/2t40AiVncjF5CjFZS1k48DyNiG3QaKfOjTimXOTL
         ousaHz0LDCpUCv5SsuVhdsSOG7+iICE++aTkOsflwm4luwvb4fGv/Qieveecyd9pWSFD
         swK1tNGUXGv6S3E31LSA4L2NEInPp0899vyqQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747079793; x=1747684593;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=vko/TdS4oIy2sjncEqYDjmf9vGJvEJOwtxlN9MhiSlw=;
        b=FT2hNlcw9VMRpKgO7iFme8HvmuJeVwNT3O8XeqZzrWxekeHNwbE+YhHoXebOTl0Bhd
         yAVLU5ocS/4OTn5Fg5V5quUxFTZ2+iwa1zR+xftAxs2W4fNheIHPBI8QkllcCmWGht4C
         x/CCQXZPhi3TNuX2X1NeRx3eF6BIfJbv4aCF2G20hRybJOX1zQFFwBoUp7no2iSrxxM2
         dN6ebVmmXXrYlIkkcErqWvnYZmwvD9FXLWwnFP4NkWzgHFsgEzdxNOHdthzoxtH2Ue/U
         qZMsgyCeHKBy+f21eXoqXTdnnD67IQdfBiXrlPnB/uVaIzVo5Fcqw7dMgQBVRBqXKwoM
         R2jg==
X-Gm-Message-State: AOJu0YxiVhaZpmtIp0QQnVXARGTOOeEi22+UFRbVma5gdHk6jcinXKgV
	BdUIc24NFMSMupthr0JjCjegyTNwl0EfiWUavG5R0+5hGkx4AnWH/zJKSUerqveED377Z2/ZX61
	Y
X-Gm-Gg: ASbGnctXUmHbA9OhZs7Uj1J+yhFFQMV1lYFPijnu7Gh9ZIEDa/KTMl7yOHpXBNOm1S8
	m0pCzPosdJeLTJ/kUaZdQoS+AdqvzMORl+aWjtds61UPpacV7jdGVnYt7J7itj/KO4b4KVu58Sr
	E+sbyOsVeFjJczNNCLqHDPKIsScWMsRHeddFgULeNf6Yx67tBv7CskUjEttN42htlz4T9IHrXRU
	mIEoy0ISZ9I1lbjfVsLJJ5cCikVry5XqGvpCJn2Dvp/XbBio41uFT4jDJnQOCD33ngQgEdd/0Tt
	1Pk4NKnI/urM9aoKsb+Y004WvbrPEG8KjLydjFdE8wP2KTtMsAR0CWbldeeTb2CUNCHs
X-Google-Smtp-Source: AGHT+IFItN1eCoS5zWKnTx4R48c4D/+++0fMhAhc9k0xKuI6w1wPJMeI2tVFAUnhAnbYmnsQVjeFPg==
X-Received: by 2002:a17:907:986:b0:ad4:d9b2:6ee4 with SMTP id a640c23a62f3a-ad4d9b26f2amr35672366b.49.1747079793192;
        Mon, 12 May 2025 12:56:33 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Kevin Lampis 
Subject: [PATCH 1/3] efi: Add a function to check if Secure Boot mode is enabled
Date: Mon, 12 May 2025 20:56:26 +0100
Message-ID: <20250512195628.1728455-2-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
In-Reply-To: <20250512195628.1728455-1-kevin.lampis@cloud.com>
References: <20250512195628.1728455-1-kevin.lampis@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Ross Lagerwall 

Also cache it to avoid needing to repeatedly ask the firmware.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Kevin Lampis 
---
 xen/common/efi/boot.c    | 23 +++++++++++++++++++++++
 xen/common/efi/runtime.c |  3 +++
 xen/include/xen/efi.h    |  6 ++++++
 3 files changed, 32 insertions(+)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index e39fbc3529..7c528cd5dd 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -870,6 +870,27 @@ static void __init pre_parse(const struct file *file)
                    " last line will be ignored.\r\n");
 }
 
+static void __init init_secure_boot_mode(void)
+{
+    EFI_STATUS status;
+    EFI_GUID gv_uuid = EFI_GLOBAL_VARIABLE;
+    uint8_t data = 0;
+    UINTN size = sizeof(data);
+    UINT32 attr = 0;
+    status = efi_rs->GetVariable((CHAR16 *)L"SecureBoot", &gv_uuid, &attr,
+                                 &size, &data);
+
+    if ( status == EFI_NOT_FOUND ||
+         (status == EFI_SUCCESS &&
+          attr == (EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS) &&
+          size == 1 && data == 0) )
+        /* Platform does not support Secure Boot or it's disabled. */
+        efi_secure_boot = false;
+    else
+        /* Everything else play it safe and assume enabled. */
+        efi_secure_boot = true;
+}
+
 static void __init efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 {
     efi_ih = ImageHandle;
@@ -884,6 +905,8 @@ static void __init efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTabl
 
     StdOut = SystemTable->ConOut;
     StdErr = SystemTable->StdErr ?: StdOut;
+
+    init_secure_boot_mode();
 }
 
 static void __init efi_console_set_mode(void)
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 7e1fce291d..b63d21f16c 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -40,6 +40,9 @@ void efi_rs_leave(struct efi_rs_state *state);
 unsigned int __read_mostly efi_num_ct;
 const EFI_CONFIGURATION_TABLE *__read_mostly efi_ct;
 
+#if defined(CONFIG_X86) && !defined(CONFIG_PV_SHIM)
+bool __ro_after_init efi_secure_boot;
+#endif
 unsigned int __read_mostly efi_version;
 unsigned int __read_mostly efi_fw_revision;
 const CHAR16 *__read_mostly efi_fw_vendor;
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 160804e294..ae10ac62d0 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -40,6 +40,12 @@ static inline bool efi_enabled(unsigned int feature)
 }
 #endif
 
+#if defined(CONFIG_X86) && !defined(CONFIG_PV_SHIM)
+extern bool efi_secure_boot;
+#else
+#define efi_secure_boot false
+#endif
+
 void efi_init_memory(void);
 bool efi_boot_mem_unused(unsigned long *start, unsigned long *end);
 bool efi_rs_using_pgtables(void);
-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 19:56:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 19:56:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982148.1368719 (Exim 4.92)
	(envelope-from )
	id 1uEZGT-0007PJ-EW; Mon, 12 May 2025 19:56:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982148.1368719; Mon, 12 May 2025 19:56: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 1uEZGT-0007P8-BC; Mon, 12 May 2025 19:56:41 +0000
Received: by outflank-mailman (input) for mailman id 982148;
 Mon, 12 May 2025 19:56:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEZGR-00071g-Gy
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 19:56:39 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 37977802-2f6b-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 21:56:39 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad4ce8cc3c1so86461166b.2
 for ; Mon, 12 May 2025 12:56:39 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197be0c5sm656407366b.153.2025.05.12.12.56.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 12:56: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" 
X-Inumbo-ID: 37977802-2f6b-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747079798; x=1747684598; 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;
        bh=UIEKL1OfSXAaAmq1R0BXNcV8CCHP1Evg860PougFuy0=;
        b=XHgoMzbriWRwYW8zBTFYZtDbV7iAqa9yws6NkwjiN7kgrwXx81eJaXhLj88nKrQ+Xh
         7USXgvjKwyU10xxP3NyLgrIcR2xuk8HtJvBLt326LaiFwDjKyRJrABXIjbg/fXvTuSkI
         mtAjRC9A1SVUB8QoA/qdj4feKt6Cb6cbXBe9c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747079798; x=1747684598;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=UIEKL1OfSXAaAmq1R0BXNcV8CCHP1Evg860PougFuy0=;
        b=DJ/UiFz6qb+whJW6fITTClhPC6KNRe/PUeOiprVpBoIrB/yl5YWe+8ACfZGp0fC7bi
         ySTMwkO4sm2BZk3AWtdvOmyMDN41IoP10by7Q5DhI/3TuNGvwfrFTMymkajoNezdabfw
         jfOfJ0U1y+zwDOnslfSZf4Yu6s9BviLCeZB6RCuzXr0GpnlJb85pBrGlBQqGagmDGknU
         DdE9CvmqMizR55tTEy5nKrA+YTVyr/8iidFwoKQg/WLKCBaCZ75K+MHDiF/nVC3WZpUu
         XNcCU7OVEI7mhDSFYvLQsOW+rhrzK2VEVr05wS2T7K2yko/SMImKPMbqK2aL1VpSH7Fx
         Y5JA==
X-Gm-Message-State: AOJu0Yy9zSr7YkRQEKeo/+aN/kBtXkLw4xcd88/uX794y4bnUGYXSv6K
	NHwBXaWQz2/zspt87GV++z0mbZQXGJESwXarq2A3Nu/RrLfaqJNKm9cQ3HPq3Rzj5ouBYMf/s7o
	u
X-Gm-Gg: ASbGnctX3KBErIfNajWT8cvnpoOPaKlcJqoXBzXQbK9qdfCjZOtJ6SULTmL6TABajYB
	3ikijwk8++9YB0zBUiaq2dCB6vhz+2wkpBjFGNZ+NCbYCVZ4ckIP3HVmd0dCwzw9J1q7McQ83yN
	rhqW69SiODHRvIoViNg8inYGmCI+3C/8/ug30Do68oxQRWhQZh1YivSagmY1RjuqjFApo/VAEhx
	l6GbdyPRtWOFgu5p/12wVoPfIrlS/6kmmK1DE1l9ShzgYmV3GL80YVl7GdHSA5Krekvr2lSte2l
	TkhwtC5Jzb4prPpOVguoa5xK1235s3zfhlgZE95RwisK/vb7cSXvSYZYUChlrA22k2Wu
X-Google-Smtp-Source: AGHT+IHMfFZDeuVejZ195aNZbQ2arcgWjbG0MNXrusQtmLt8QE5A2GQX7YRk66FdDb4jFkPf96+lwA==
X-Received: by 2002:a17:907:60ca:b0:ad2:4fb6:3b93 with SMTP id a640c23a62f3a-ad24fb63e30mr666470766b.28.1747079797720;
        Mon, 12 May 2025 12:56:37 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: Kevin Lampis ,
	Ross Lagerwall 
Subject: [PATCH 3/3] Disallow most command-line options when lockdown mode is enabled
Date: Mon, 12 May 2025 20:56:28 +0100
Message-ID: <20250512195628.1728455-4-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
In-Reply-To: <20250512195628.1728455-1-kevin.lampis@cloud.com>
References: <20250512195628.1728455-1-kevin.lampis@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

A subset of command-line parameters that are specifically safe to use when
lockdown mode is enabled are annotated as such.

Signed-off-by: Kevin Lampis 
Signed-off-by: Ross Lagerwall 
---
 xen/arch/arm/domain_build.c           |  4 +--
 xen/arch/x86/acpi/cpu_idle.c          |  2 +-
 xen/arch/x86/cpu/amd.c                |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c         |  2 +-
 xen/arch/x86/cpu/microcode/core.c     |  2 +-
 xen/arch/x86/dom0_build.c             |  4 +--
 xen/arch/x86/hvm/hvm.c                |  2 +-
 xen/arch/x86/irq.c                    |  2 +-
 xen/arch/x86/nmi.c                    |  2 +-
 xen/arch/x86/setup.c                  |  2 +-
 xen/arch/x86/traps.c                  |  2 +-
 xen/arch/x86/x86_64/mmconfig-shared.c |  2 +-
 xen/common/domain.c                   |  2 +-
 xen/common/kernel.c                   | 10 +++++-
 xen/common/kexec.c                    |  2 +-
 xen/common/numa.c                     |  2 +-
 xen/common/page_alloc.c               |  2 +-
 xen/common/shutdown.c                 |  2 +-
 xen/drivers/char/console.c            |  2 +-
 xen/drivers/char/ns16550.c            |  4 +--
 xen/drivers/video/vga.c               |  2 +-
 xen/include/xen/param.h               | 49 +++++++++++++++++++++------
 22 files changed, 70 insertions(+), 35 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..ef1cba8f0f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -41,7 +41,7 @@
 #include 
 
 static unsigned int __initdata opt_dom0_max_vcpus;
-integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+integer_secure_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 /*
  * If true, the extended regions support is enabled for dom0 and
@@ -61,7 +61,7 @@ static int __init parse_dom0_mem(const char *s)
 
     return *s ? -EINVAL : 0;
 }
-custom_param("dom0_mem", parse_dom0_mem);
+custom_secure_param("dom0_mem", parse_dom0_mem);
 
 int __init parse_arch_dom0_param(const char *s, const char *e)
 {
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 1dbf15b01e..431fd0c997 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -113,7 +113,7 @@ static int __init cf_check parse_cstate(const char *s)
         max_csubstate = simple_strtoul(s + 1, NULL, 0);
     return 0;
 }
-custom_param("max_cstate", parse_cstate);
+custom_secure_param("max_cstate", parse_cstate);
 
 static bool __read_mostly local_apic_timer_c2_ok;
 boolean_param("lapic_timer_c2_ok", local_apic_timer_c2_ok);
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 37d67dd15c..c36351c968 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -47,7 +47,7 @@ integer_param("cpuid_mask_thermal_ecx", opt_cpuid_mask_thermal_ecx);
 
 /* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */
 int8_t __read_mostly opt_allow_unsafe;
-boolean_param("allow_unsafe", opt_allow_unsafe);
+boolean_secure_param("allow_unsafe", opt_allow_unsafe);
 
 /* Signal whether the ACPI C1E quirk is required. */
 bool __read_mostly amd_acpi_c1e_quirk;
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 1c348e557d..a229af6fd3 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -31,7 +31,7 @@
 #include "vmce.h"
 
 bool __read_mostly opt_mce = true;
-boolean_param("mce", opt_mce);
+boolean_secure_param("mce", opt_mce);
 bool __read_mostly mce_broadcast;
 bool is_mc_panic;
 DEFINE_PER_CPU_READ_MOSTLY(unsigned int, nr_mce_banks);
diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 34a94cd25b..b5b7304ae7 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -160,7 +160,7 @@ static int __init cf_check parse_ucode(const char *s)
 
     return rc;
 }
-custom_param("ucode", parse_ucode);
+custom_secure_param("ucode", parse_ucode);
 
 static struct microcode_ops __ro_after_init ucode_ops;
 
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0b467fd4a4..6d42acb661 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -142,7 +142,7 @@ static int __init cf_check parse_dom0_mem(const char *s)
 
     return s[-1] ? -EINVAL : ret;
 }
-custom_param("dom0_mem", parse_dom0_mem);
+custom_secure_param("dom0_mem", parse_dom0_mem);
 
 static unsigned int __initdata opt_dom0_max_vcpus_min = 1;
 static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX;
@@ -164,7 +164,7 @@ static int __init cf_check parse_dom0_max_vcpus(const char *s)
 
     return *s ? -EINVAL : 0;
 }
-custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
+custom_secure_param("dom0_max_vcpus", parse_dom0_max_vcpus);
 
 static __initdata unsigned int dom0_nr_pxms;
 static __initdata unsigned int dom0_pxms[MAX_NUMNODES] =
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4cb2e13046..97afb274fe 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -87,7 +87,7 @@ unsigned long __section(".bss.page_aligned") __aligned(PAGE_SIZE)
 
 /* Xen command-line option to enable HAP */
 static bool __initdata opt_hap_enabled = true;
-boolean_param("hap", opt_hap_enabled);
+boolean_secure_param("hap", opt_hap_enabled);
 
 #ifndef opt_hvm_fep
 /* Permit use of the Forced Emulation Prefix in HVM guests */
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 38ac0823d7..453bdb9910 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -34,7 +34,7 @@
 
 /* opt_noirqbalance: If true, software IRQ balancing/affinity is disabled. */
 bool __read_mostly opt_noirqbalance;
-boolean_param("noirqbalance", opt_noirqbalance);
+boolean_secure_param("noirqbalance", opt_noirqbalance);
 
 unsigned int __read_mostly nr_irqs_gsi = NR_ISA_IRQS;
 unsigned int __read_mostly nr_irqs;
diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 9793fa2316..3735f22e88 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -73,7 +73,7 @@ static int __init cf_check parse_watchdog(const char *s)
 
     return 0;
 }
-custom_param("watchdog", parse_watchdog);
+custom_secure_param("watchdog", parse_watchdog);
 
 /* opt_watchdog_timeout: Number of seconds to wait before panic. */
 static unsigned int opt_watchdog_timeout = 5;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 276957c4ed..1018cdb771 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -70,7 +70,7 @@
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool __initdata opt_nosmp;
-boolean_param("nosmp", opt_nosmp);
+boolean_secure_param("nosmp", opt_nosmp);
 
 /* maxcpus: maximum number of CPUs to activate. */
 static unsigned int __initdata max_cpus;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 25e0d5777e..1af67d2256 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -86,7 +86,7 @@ static char __read_mostly opt_nmi[10] = "dom0";
 #else
 static char __read_mostly opt_nmi[10] = "fatal";
 #endif
-string_param("nmi", opt_nmi);
+string_secure_param("nmi", opt_nmi);
 
 DEFINE_PER_CPU(uint64_t, efer);
 static DEFINE_PER_CPU(unsigned long, last_extable_addr);
diff --git a/xen/arch/x86/x86_64/mmconfig-shared.c b/xen/arch/x86/x86_64/mmconfig-shared.c
index f1a3d42c5b..80cdca7d77 100644
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -60,7 +60,7 @@ static int __init cf_check parse_mmcfg(const char *s)
 
     return rc;
 }
-custom_param("mmcfg", parse_mmcfg);
+custom_secure_param("mmcfg", parse_mmcfg);
 
 static const char *__init cf_check pci_mmcfg_e7520(void)
 {
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..c95988c067 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -55,7 +55,7 @@ unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
 
 /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */
 bool opt_dom0_vcpus_pin;
-boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
+boolean_secure_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
 
 /* Protect updates/reads (resp.) of domain_list and domain_hash. */
 DEFINE_SPINLOCK(domlist_update_lock);
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 6658db9514..eaa509f317 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -135,9 +137,15 @@ static int parse_params(const char *cmdline, const struct kernel_param *start,
                 }
                 continue;
             }
+            found = true;
+
+            if ( !param->is_lockdown_safe && is_locked_down() )
+            {
+              printk("Ignoring unsafe cmdline option %s in lockdown mode\n", param->name);
+              break;
+            }
 
             rctmp = 0;
-            found = true;
             switch ( param->type )
             {
             case OPT_STR:
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 84fe8c3597..790839657d 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -189,7 +189,7 @@ static int __init cf_check parse_crashkernel(const char *str)
 
     return rc;
 }
-custom_param("crashkernel", parse_crashkernel);
+custom_secure_param("crashkernel", parse_crashkernel);
 
 /* Parse command lines in the format:
  *
diff --git a/xen/common/numa.c b/xen/common/numa.c
index ad75955a16..c4981f2ff1 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -687,7 +687,7 @@ static int __init cf_check numa_setup(const char *opt)
 
     return 0;
 }
-custom_param("numa", numa_setup);
+custom_secure_param("numa", numa_setup);
 
 static void cf_check dump_numa(unsigned char key)
 {
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index e57a287133..a07690d8fd 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -235,7 +235,7 @@ static int __init cf_check parse_bootscrub_param(const char *s)
 
     return 0;
 }
-custom_param("bootscrub", parse_bootscrub_param);
+custom_secure_param("bootscrub", parse_bootscrub_param);
 
 /*
  * bootscrub_chunk -> Amount of bytes to scrub lockstep on non-SMT CPUs
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index c47341b977..231de1454a 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -13,7 +13,7 @@
 
 /* opt_noreboot: If true, machine will need manual reset on error. */
 bool __ro_after_init opt_noreboot;
-boolean_param("noreboot", opt_noreboot);
+boolean_secure_param("noreboot", opt_noreboot);
 
 static void noreturn reboot_or_halt(void)
 {
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c3150fbdb7..45a35903fe 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -43,7 +43,7 @@
 
 /* console: comma-separated list of console outputs. */
 static char __initdata opt_console[30] = OPT_CONSOLE_STR;
-string_param("console", opt_console);
+string_secure_param("console", opt_console);
 
 /* conswitch: a character pair controlling console switching. */
 /* Char 1: CTRL+ is used to switch console input between Xen and DOM0 */
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index eaeb0e09d0..fae509cbd8 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1390,8 +1390,8 @@ static void enable_exar_enhanced_bits(const struct ns16550 *uart)
  */
 static char __initdata opt_com1[128] = "";
 static char __initdata opt_com2[128] = "";
-string_param("com1", opt_com1);
-string_param("com2", opt_com2);
+string_secure_param("com1", opt_com1);
+string_secure_param("com2", opt_com2);
 
 enum serial_param_type {
     baud_rate,
diff --git a/xen/drivers/video/vga.c b/xen/drivers/video/vga.c
index b577b24619..abc6e56aa3 100644
--- a/xen/drivers/video/vga.c
+++ b/xen/drivers/video/vga.c
@@ -48,7 +48,7 @@ void (*video_puts)(const char *s, size_t nr) = vga_noop_puts;
  * control of the console to domain 0.
  */
 static char __initdata opt_vga[30] = "";
-string_param("vga", opt_vga);
+string_secure_param("vga", opt_vga);
 
 /* VGA text-mode definitions. */
 static unsigned int columns, lines;
diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h
index 1bdbab34ab..31e7326d88 100644
--- a/xen/include/xen/param.h
+++ b/xen/include/xen/param.h
@@ -25,6 +25,7 @@ struct kernel_param {
         void *var;
         int (*func)(const char *s);
     } par;
+    bool is_lockdown_safe;
 };
 
 /* Maximum length of a single parameter string. */
@@ -44,46 +45,72 @@ extern const struct kernel_param __setup_start[], __setup_end[];
 #define _TEMP_NAME(base, line) __TEMP_NAME(base, line)
 #define TEMP_NAME(base) _TEMP_NAME(base, __LINE__)
 
-#define custom_param(_name, _var) \
+#define custom_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_CUSTOM, \
-          .par.func = (_var) }
-#define boolean_param(_name, _var) \
+          .par.func = (_var), \
+          .is_lockdown_safe = (_sec) }
+#define custom_param(_name, _var) \
+    custom_param_(_name, _var, false)
+#define custom_secure_param(_name, _var) \
+    custom_param_(_name, _var, true)
+#define boolean_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_BOOL, \
           .len = sizeof(_var) + \
                  BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
-          .par.var = &(_var) }
-#define integer_param(_name, _var) \
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define boolean_param(_name, _var) \
+    boolean_param_(_name, _var, false)
+#define boolean_secure_param(_name, _var) \
+    boolean_param_(_name, _var, true)
+#define integer_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_UINT, \
           .len = sizeof(_var), \
-          .par.var = &(_var) }
-#define size_param(_name, _var) \
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define integer_param(_name, _var) \
+    integer_param_(_name, _var, false)
+#define integer_secure_param(_name, _var) \
+    integer_param_(_name, _var, true)
+#define size_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_SIZE, \
           .len = sizeof(_var), \
-          .par.var = &(_var) }
-#define string_param(_name, _var) \
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define size_param(_name, _var) \
+    size_param_(_name, _var, false)
+#define size_secure_param(_name, _var) \
+    size_param_(_name, _var, true)
+#define string_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_STR, \
           .len = sizeof(_var), \
-          .par.var = &(_var) }
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define string_param(_name, _var) \
+  string_param_(_name, _var, false)
+#define string_secure_param(_name, _var) \
+  string_param_(_name, _var, true)
 #define ignore_param(_name)                 \
     __setup_str TEMP_NAME(__setup_str_ign)[] = (_name);  \
     __kparam TEMP_NAME(__setup_ign) =                    \
         { .name = TEMP_NAME(__setup_str_ign),            \
-          .type = OPT_IGNORE }
+          .type = OPT_IGNORE,                            \
+          .is_lockdown_safe = true }
 
 #ifdef CONFIG_HYPFS
 
-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 19:58:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 19:58:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982171.1368729 (Exim 4.92)
	(envelope-from )
	id 1uEZIU-0008Vl-Qk; Mon, 12 May 2025 19:58:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982171.1368729; Mon, 12 May 2025 19: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 1uEZIU-0008Ve-NG; Mon, 12 May 2025 19:58:46 +0000
Received: by outflank-mailman (input) for mailman id 982171;
 Mon, 12 May 2025 19:58:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEZIS-0008VY-Hd
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 19:58:45 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 81303be0-2f6b-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 21:58:42 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 984894EE7BD4;
 Mon, 12 May 2025 21:58: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" 
X-Inumbo-ID: 81303be0-2f6b-11f0-9eb6-5ba50f476ded
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=1747079921;
	b=dvBOSiPd7+CC0hMUYDV6HlpdI9wxv/KSPOziqznBXXohfDeiuGrWiMrPNCIOdZHLSRZN
	 +/IHwcN3oEZcILLKeYU6BjHA4ucaMeeQXpge9oRFn2tldWooYzpJEgiLxrmEaUyC6gEVl
	 E5b11nJ3y3Lo+YP9BUCJAta0BGprcHTHYR9aVm5OxHtOGaPKCMNOLoXhdPRbbCHsz4GV9
	 N9DZd2Uus9x1EF08FSqcUyyaitSYTk5besnTdi6td3cAYX+4rOWpFwJJesslkHra8pb14
	 s7gEYWdtPsQ3YfBk4v7MPrj90HTCbdWbCyAGIlDQt/O0EDwLSr3sbNgjm00BPjJj7SnRx
	 7O2f+NUZUr3+dirI/GLJm6LXqeBwdjtMGyj/5mbfOwKBiJOqhHy2rxyggwtTaJPVKOUdH
	 SQCEGCyhwtJBJULk6hh9QJkxQR8ByIlp8EmxFS8KeSUKKz3nybJ6yydPpkl14lsEtZbyL
	 6SHO9G1UKaetRy2BMT6l28bVK/gMihLrLEoEhreLHVu3kf7/dbC74gammcZjGEjt6tU3D
	 LPS3eIExEwKxjXlJ/MR5291Cr+2+1HGANDeSP+itl4UpvNqeIlIWXduuNTSNiONuTAZCE
	 QEaVHmsY1NsaKJY+FjoE4WFPFxaY9whT0CJU6KYhAbTy8vBhDHMgrUksZgDNFSk=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1747079921;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=hR+3qkPcfLW/IX3IURdsuWso1H/te0G+BUEbl/2Gy1Q=;
	b=PPkyTUwpmGOtS7oNaz5J2vqqoAyBZ8v0UwIS+OJnsMv5J9qSjXsNvwq35DXhfBgaPk0w
	 abp9dxc6Trq1VUxTvlshU5lOo4rjHLU9ZfYEqbmnWwDvxf/C9sePCXPjsaHZij5ZFu8vP
	 uDDSqxc11b8sDSh4nPRnGkJBG0GauGK2nUqmgzyzolZBUCbuanr+/7YEgtomP5E+076vK
	 0ACc41mt4L6IJ76sOrgOYLMmu+mQh/XBNgWVMBeAyie1uiDfa/nWWriANYwRtXg4cTWtJ
	 UfuZPezH5c+XqRp5VxFRld5I7DWLpN/zlmbocg6cHT1Dxdjuz6K6u5oQhjYj5HWxX/qy9
	 wL+EvmfMCNbGl/1+cYH4wXU8MvQKYfPkl5C9w5a1iz1VTXz2juW7BcJ6DIWQVrgWAh6w8
	 UkIizazmJwauFIrKfsDlaezr0AaAgkmh8YKX1VJWKiIv+6Kr4qBB9rlRRs4rwcNd+B/dt
	 XnPxfR86pCK+dMJGsiKzXPkjqJmzYCS/ANmnUVFdbJ5viGTz6gaH06nBHZWhbMpMq/oqw
	 nb4JM4Dskzm85D9Lzi8lCPm/mG77F3iWusvhzh7vzEoTPkb4FZLmFVLJVM7cTfndWBJim
	 KqJGCLnMClqCTR8t47ZkBY+LzC7h1IuMQyu1W4WsFrE21tJb66viKhdApZdhdzU=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1747079921; bh=hcd7wQmJhh6MtgN4rwVGiFoEBqI4jUsM/KzB0GxjYII=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=P9qDIyiq4ftq+9djKYWiPSp/1ZumfA9pDUKFs01wF/YYVK6e+rBEjcU2wJvZUjSJC
	 GMJhGgdO5oMYiygdzJyNZjFDNmw+MzaJfd31YQJTvkDw5pycDx7htuKpjcYcULXe83
	 nZFsZBmH1SQZXvqeZ0vQoWEd/PRoBLKHHtcb4x+r+M84c0Jiy9LsNbYdhHq/MmSY8h
	 LgyE4SwzArlzf7P+CaYy588MIyzy03eNfHO9HlR7Zzl6dy+rV1Aj2pg2kf3rwFeiEp
	 M+41gleR3G17KX0nSPeOeGchoADQeRzc3/0E8tRw39uYbzoHVub2tsmi3wX7IrulAX
	 kC93I/HkSPVAA==
MIME-Version: 1.0
Date: Mon, 12 May 2025 21:58:41 +0200
From: Nicola Vetrini 
To: Elliott Mitchell 
Cc: Jan Beulich , Andrew Cooper
 , Xen-devel ,
 Anthony PERARD , Michal Orzel
 , Julien Grall , =?UTF-8?Q?Roger?=
 =?UTF-8?Q?_Pau_Monn=C3=A9?= , Roberto Bagnara
 , "consulting @ bugseng . com"
 , Stefano Stabellini 
Subject: Re: [PATCH] xen: Use __auto_type
In-Reply-To: 
References: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
 
 <548430a5-fa4a-41d1-b5ba-ba45efa90bbc@suse.com>
 <7acc83a3-2b15-4557-b293-0832b35e3680@citrix.com>
 <35826c2a-4266-49d2-b1b8-1248aac227b5@suse.com>
 
Message-ID: <9b616ece73d57d8bf5f524e50da14640@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2025-05-12 20:25, Elliott Mitchell wrote:
> On Mon, May 12, 2025 at 03:00:18PM +0200, Jan Beulich wrote:
>> On 12.05.2025 14:09, Andrew Cooper wrote:
>> >
>> > Now for the (new) controversial part.  Since sending this, Linux has
>> > decided to just #define auto __auto_type for C < 23, in order to start
>> > writing C23 compatible code from now.  It's more succinct, and has
>> > better longevity.
>> >
>> > We might want to consider the same, although it will introduce a new
>> > example of defining a keyword, which we'd have to call out in the
>> > MISRA/Eclair config.
>> 
>> I'm not outright opposed, as I don't think we use "auto" with its
>> original semantics, but it feels somewhat odd.
> 
> Problem is "auto" already has a defined meaning in C.  Having this will
> subtly break contributions from authors who weren't familiar with
> everything in Xen's headers.  For anyone who does anything with 
> projects
> besides Xen this will encourage bad habits.
> 
> I believe many projects have a rule of *never* #define C keywords.  I'm
> surprised such made it into the Linux kernel.  I expect it will be 
> ripped
> out in the near future.
> 
> MISRA *doesn't* absolutely forbid this?

It does, and in fact I don't think that is a wise decision (it's not 
quite UB I think because Xen does not use standard library headers, but 
still). However Xen does already #define "inline" with a specific 
rationale. I could find only [1] as a reference to the discussion in 
Linux, but perhaps I missed something. Do you have more recent thread 
@Andrew?

[1] 
https://lore.kernel.org/lkml/d4f87590-6cbb-4ee9-bead-7d958fc1fa83@p183/#R

-- 
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 May 12 20:01:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 20:01:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982190.1368739 (Exim 4.92)
	(envelope-from )
	id 1uEZKq-00022k-9R; Mon, 12 May 2025 20:01:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982190.1368739; Mon, 12 May 2025 20:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEZKq-00022d-6L; Mon, 12 May 2025 20:01:12 +0000
Received: by outflank-mailman (input) for mailman id 982190;
 Mon, 12 May 2025 20:01:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEZGQ-0005qp-AY
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 19:56:38 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 36326998-2f6b-11f0-9ffb-bf95429c2676;
 Mon, 12 May 2025 21:56:36 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad23c20f977so357194666b.2
 for ; Mon, 12 May 2025 12:56:36 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197be0c5sm656407366b.153.2025.05.12.12.56.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 12:56:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 36326998-2f6b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747079796; x=1747684596; 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;
        bh=k4Wd8lHyFqDjTXjkxHBdAOOU5VtwxpSw3GkW45s9UOA=;
        b=hW0slmy02z9nMSr6NpDMOgRKWt+vn0KEbENPvnLk8CVFOeBK1qdLfcHJZimRwj3wCN
         f6vlic5s1RG9hkMJpYEwUdH0VOoKhTScJ1pTTpwdiusdQud2W2vyRjjcJwAkpftj66eH
         hDjVhnatASd6ZdzXK6FIZvTHj4ewXRUlB3gVg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747079796; x=1747684596;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=k4Wd8lHyFqDjTXjkxHBdAOOU5VtwxpSw3GkW45s9UOA=;
        b=fppV3vpLy7lXRd1mFWwOZAmiwVPnyLLQEDMWhewlnBoonObiiaqGsZpwOabohWu2Z3
         9bv1jfb6xz53aO19LJ9cOc91n8v6fTNSHHVenW27yfNPgKDX3GpGaNH61LnDCo6wOwBl
         +kY1JQ9GeE/mrmragx+vC8yln12GdprfalppUeBEIh68nRePCWrxS5V4+mg39MWI9Gb2
         sxMEpK6x06z1l4Kp/NfQyxv7CRcapq60bJ2xT9p7c0WqXBL9ecPFyY++Mr5pxumazvyh
         vVhAQtXJSdnDbyD9psDWtc1BLxWOTfbKVqLN+2J6NreYWqfffyhe2QlYmd9GM6Q/aPcW
         e2fA==
X-Gm-Message-State: AOJu0YxrLgEeGwetfjJDHi2BQLrALYNpNxeghgebkvBXJCDjHt+ymaYV
	I/2N9G//BV3T7J8lndrlbjDagC0K6m7MB4AH1A4wnovo1AUf3c87Hg6QH8WzPQs3zbeW3M2qRV/
	3
X-Gm-Gg: ASbGncsMlGfT4aBc6Qs+2VvgN50nbnfblh1u1pVsO67m7bacYy2PbcrPhKfy5D73Y/i
	YIj0PuKxhmXALsV1q1qxnucpFDJvvHojZWqvCEFRxV0Lp8ps4pPcyS62hkcknJx13mGbC7sswjT
	v9uTNItctpet262I5GIa55tMJgC/54nz48OkBgEcqU1ENGSVn7+xKcLD+WBO8e1TAI1PK4pjM0H
	UMhYtZLdUQaumziC39wDZQvWxrPRZ0sFAiO3ZDfSR4eIp3AZ5Ef0pxG0oiFUXKISedOnZ5gJ+2B
	+2mn5eOW78+bQaugjMdCEKpUmmOR+rDE0GHEKoMn8k9RQARwEXvFLkcz5Epb/vjlfflk
X-Google-Smtp-Source: AGHT+IHzSIWCtV2mlkh4F8aroWccKmHhvvAB4iWh/zuQL3EraTvCk466NJ4QBWQ1Uke7y85jSA8Flg==
X-Received: by 2002:a17:907:a38e:b0:ad2:39a9:f1b8 with SMTP id a640c23a62f3a-ad239aa08eemr842161966b.57.1747079795633;
        Mon, 12 May 2025 12:56:35 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Kevin Lampis 
Subject: [PATCH 2/3] Add lockdown mode
Date: Mon, 12 May 2025 20:56:27 +0100
Message-ID: <20250512195628.1728455-3-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
In-Reply-To: <20250512195628.1728455-1-kevin.lampis@cloud.com>
References: <20250512195628.1728455-1-kevin.lampis@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Ross Lagerwall 

The intention of lockdown mode is to prevent attacks from a rogue dom0
userspace from compromising the system. Lockdown mode can be controlled by a
Kconfig option and a command-line parameter. It is also enabled automatically
when Secure Boot is enabled and it cannot be disabled in that case.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Kevin Lampis 
---
 xen/arch/x86/setup.c       |  1 +
 xen/common/Kconfig         |  8 ++++++
 xen/common/Makefile        |  1 +
 xen/common/kernel.c        |  3 +++
 xen/common/lockdown.c      | 52 ++++++++++++++++++++++++++++++++++++++
 xen/include/xen/lockdown.h |  9 +++++++
 6 files changed, 74 insertions(+)
 create mode 100644 xen/common/lockdown.c
 create mode 100644 xen/include/xen/lockdown.h

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2518954124..276957c4ed 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index bf7b081ad0..42b2e4e869 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -565,4 +565,12 @@ config BUDDY_ALLOCATOR_SIZE
 	  Amount of memory reserved for the buddy allocator to serve Xen heap,
 	  working alongside the colored one.
 
+config LOCKDOWN_DEFAULT
+	bool "Enable lockdown mode by default"
+	default n
+	help
+	  Lockdown mode prevents attacks from a rogue dom0 userspace from
+	  compromising the system. This is automatically enabled when Secure
+	  Boot is enabled.
+
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..b00a8a925a 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC) += kimage.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
+obj-y += lockdown.o
 obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 8b63ca55f1..6658db9514 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -216,6 +216,9 @@ static void __init _cmdline_parse(const char *cmdline)
  */
 void __init cmdline_parse(const char *cmdline)
 {
+    /* Call this early since it affects command-line parsing */
+    lockdown_init(cmdline);
+
     if ( opt_builtin_cmdline[0] )
     {
         printk("Built-in command line: %s\n", opt_builtin_cmdline);
diff --git a/xen/common/lockdown.c b/xen/common/lockdown.c
new file mode 100644
index 0000000000..935911dfd0
--- /dev/null
+++ b/xen/common/lockdown.c
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static bool __ro_after_init lockdown = IS_ENABLED(CONFIG_LOCKDOWN_DEFAULT);
+ignore_param("lockdown");
+
+bool is_locked_down(void)
+{
+    return lockdown;
+}
+
+void __init lockdown_init(const char *cmdline)
+{
+    if ( efi_secure_boot )
+    {
+        printk("Enabling lockdown mode because Secure Boot is enabled\n");
+        lockdown = true;
+    }
+    else
+    {
+        while ( *cmdline )
+        {
+            size_t param_len, name_len;
+            int ret;
+
+            cmdline += strspn(cmdline, " \n\r\t");
+            param_len = strcspn(cmdline, " \n\r\t");
+            name_len = strcspn(cmdline, "= \n\r\t");
+
+            if ( !strncmp(cmdline, "lockdown", max(name_len, strlen("lockdown"))) ||
+                 !strncmp(cmdline, "no-lockdown", max(name_len, strlen("no-lockdown"))) )
+            {
+                ret = parse_boolean("lockdown", cmdline, cmdline + param_len);
+                if ( ret >= 0 )
+                {
+                    lockdown = ret;
+                    printk("Lockdown mode set from command-line\n");
+                    break;
+                }
+            }
+
+            cmdline += param_len;
+        }
+    }
+
+    printk("Lockdown mode is %s\n", lockdown ? "enabled" : "disabled");
+}
diff --git a/xen/include/xen/lockdown.h b/xen/include/xen/lockdown.h
new file mode 100644
index 0000000000..b2baa31caa
--- /dev/null
+++ b/xen/include/xen/lockdown.h
@@ -0,0 +1,9 @@
+#ifndef XEN__LOCKDOWN_H
+#define XEN__LOCKDOWN_H
+
+#include 
+
+bool is_locked_down(void);
+void lockdown_init(const char *cmdline);
+
+#endif /* XEN__LOCKDOWN_H */
-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 21:55:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 21:55:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982202.1368748 (Exim 4.92)
	(envelope-from )
	id 1uEb6y-0000dE-28; Mon, 12 May 2025 21:55:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982202.1368748; Mon, 12 May 2025 21:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEb6x-0000d7-Vs; Mon, 12 May 2025 21:54:59 +0000
Received: by outflank-mailman (input) for mailman id 982202;
 Mon, 12 May 2025 21:54:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEb6w-0000d1-Bu
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 21:54:58 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bd937136-2f7b-11f0-9eb6-5ba50f476ded;
 Mon, 12 May 2025 23:54:56 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 1E26A61149;
 Mon, 12 May 2025 21:54:55 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5F55C4CEE7;
 Mon, 12 May 2025 21:54: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" 
X-Inumbo-ID: bd937136-2f7b-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747086894;
	bh=4x5B7a6fKHJMZ6PV1sqoeNUXHRhVpSMgwJruLge+DnE=;
	h=Date:From:To:cc:Subject:From;
	b=cjowzAc1Bm9WvC1MWYxn1GIzVoJp+m9oyobRRF320RFUBrrjFHP8WRpdhPwVBJwZA
	 FKgC6cYHcI9ADKhSsfPDoW91bPrC6XaJVW8xDQ2Y1ivcINO6yLGZpyikJx33h2/IlW
	 UGZZF3suvOx3LgRqevAXylKs4FVuRwmaBoze7Fkfe30h6nCOd1Aupuk6w6Wzi3y4CV
	 Dv/aUlaXrFzPf/drEwwyjtQKdFeSyr/j0wP3K0YKyMlwceAcLTPj6BbdJIMbCDFSOM
	 Ddbgqpayyw4QNij8YeJh5oo4i3jCnVv/6cRmrcYINGbVIW3GVXxcck02s17H4RF2G9
	 D89Bzt4LKr+nA==
Date: Mon, 12 May 2025 14:54:52 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: sstabellini@kernel.org, Juergen Gross , 
    Julien Grall , Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    linux-kernel@vger.kernel.org, stable@kernel.org
Subject: [PATCH] xen/arm: call uaccess_ttbr0_enable for dm_op hypercall
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

From: Stefano Stabellini 

dm_op hypercalls might come from userspace and pass memory addresses as
parameters. The memory addresses typically correspond to buffers
allocated in userspace to hold extra hypercall parameters.

On ARM, when CONFIG_ARM64_SW_TTBR0_PAN is enabled, they might not be
accessible by Xen, as a result ioreq hypercalls might fail. See the
existing comment in arch/arm64/xen/hypercall.S regarding privcmd_call
for reference.

For privcmd_call, Linux calls uaccess_ttbr0_enable before issuing the
hypercall thanks to commit 9cf09d68b89a. We need to do the same for
dm_op. This resolves the problem.

Signed-off-by: Stefano Stabellini 
Fixes: 9cf09d68b89a ("arm64: xen: Enable user access before a privcmd
hvc call")
Cc: stable@kernel.org
---
 arch/arm64/xen/hypercall.S | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
index 9d01361696a14..691ca70407c57 100644
--- a/arch/arm64/xen/hypercall.S
+++ b/arch/arm64/xen/hypercall.S
@@ -83,7 +83,26 @@ HYPERCALL3(vcpu_op);
 HYPERCALL1(platform_op_raw);
 HYPERCALL2(multicall);
 HYPERCALL2(vm_assist);
-HYPERCALL3(dm_op);
+
+SYM_FUNC_START(HYPERVISOR_dm_op)
+	mov x16, #__HYPERVISOR_dm_op;	\
+	/*
+	 * dm_op hypercalls are issued by the userspace. The kernel needs to
+	 * enable access to TTBR0_EL1 as the hypervisor would issue stage 1
+	 * translations to user memory via AT instructions. Since AT
+	 * instructions are not affected by the PAN bit (ARMv8.1), we only
+	 * need the explicit uaccess_enable/disable if the TTBR0 PAN emulation
+	 * is enabled (it implies that hardware UAO and PAN disabled).
+	 */
+	uaccess_ttbr0_enable x6, x7, x8
+	hvc XEN_IMM
+
+	/*
+	 * Disable userspace access from kernel once the hyp call completed.
+	 */
+	uaccess_ttbr0_disable x6, x7
+	ret
+SYM_FUNC_END(HYPERVISOR_dm_op);
 
 SYM_FUNC_START(privcmd_call)
 	mov x16, x0
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Mon May 12 23:04:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 23:04:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982211.1368759 (Exim 4.92)
	(envelope-from )
	id 1uEcC6-0001k1-Np; Mon, 12 May 2025 23:04:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982211.1368759; Mon, 12 May 2025 23:04:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEcC6-0001ju-KY; Mon, 12 May 2025 23:04:22 +0000
Received: by outflank-mailman (input) for mailman id 982211;
 Mon, 12 May 2025 23:04:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEcC4-0001jn-OC
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 23:04:20 +0000
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com
 [2607:f8b0:4864:20::b31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6d5fa82c-2f85-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 01:04:16 +0200 (CEST)
Received: by mail-yb1-xb31.google.com with SMTP id
 3f1490d57ef6-e78fc91f30dso4025084276.3
 for ; Mon, 12 May 2025 16:04:16 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 3f1490d57ef6-e79102568c5sm1725089276.54.2025.05.12.16.04.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 16: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" 
X-Inumbo-ID: 6d5fa82c-2f85-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747091055; x=1747695855; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=AioVm/a7/o2HinvhJrH8m8PE9P0GuzOXNdTGyG1SXZM=;
        b=h/atMqev2K2kgu0hYuhbH6ReifzM2gJnQxqjWNLdzdjfO+1vaP+mAfmZPWmomFixSI
         hEW6xuc1CyUuCG/7OGjK7ZFeHBMFmI4+tO+b4g0rFn3rZi/8J18KlcE3D/ay8J0B/Txc
         BJm8OzLyeMezJxt0UuFXrNL5lK/Sv3qN4OYAiCAouglx8mt6jQLzcaDUWZztdAgW95Or
         liEoXUS74NTOPlL0ujDoDDf4vtDCiUI+AcSIoE8jssW/IwooP8QFGM1OjyWGD85WMJLM
         kE/F/hiVUTNImyA/FYzTOb3mZsEe0E4/uxvJrTWJ++GmdWrn0k1jBgp8xAejU8PyRW9F
         PeXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747091055; x=1747695855;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=AioVm/a7/o2HinvhJrH8m8PE9P0GuzOXNdTGyG1SXZM=;
        b=HHCDo1g/Gr3nxR0SLQ5/DexErLRbP7WJMlM+mhCPJa9fmhWPy5qL+V1HJbYfWXsPx9
         pZvltOZsOAfk+9XED6vxqjRMuY+d1LMAmdwmhNOeTssSpxq9+2VDFfzhAeKdYSLCpJqE
         2ySZz+cph3dlKH5vBTzMPvQTqnJ7lTI02J0eobDlPqHP2OsGa9EXmznFb+QSawCNSHWD
         7mNenebxD97Cmd7ZwK9ms1iS4BaFSn57l6XfdDd7yMogsPqCr/86/vjDkvpwqG243eAD
         9+5zj5MSZFj9C7tXgQF1LtBDIWxTVCSamTbCKUsxEwpFUx5oF2mhhKdq1Zcac0oHQhf2
         1lVw==
X-Forwarded-Encrypted: i=1; AJvYcCXAOA3+HaFZQXOo00X3CcDx5ZbljEhSOaDue1XStS05xFruxrWcfVLGup3QjPYIMIQUS9eQeCjrfWQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yymz8rL/pJS/Ub2ACQqRJdA50KESxfJvLUytq/8moC4f5XbTJvu
	zgQc35dWILtiomMc7VO2gKi+PvIxkHjEgcJRHUGe5CfKpocmrwsf
X-Gm-Gg: ASbGncuasaCusEyT4+6UBS/Y6O6eWlXOcwUD2/abtTuN/l+u7MqnYj+pq5AqKIDtA22
	5emr3CFQXpFQANf385ESAVODuMooG6AEX5Q6BkKDuMXtmzDL113IJWq0b2ZLRPPdJIaqgroDRNP
	0GogaWZJF8R9LJx6fTeyFls8mCmFaFxDzqVFbhT/4ZLtZ7CvZK2nAoSCw27pQA6EhYzn/Ar18i+
	RfVRY+h3my4o0ZOs8BYSYtOB84rbUeZWEpkIL4Ha/QhhgraA8DcXqTbpMJeGcPhBk1mXW6Bh+4C
	cnV4YH6o4GotIQDuQSwkZDhvK8G5ixN6/UTjy1aTRX1YUymjaXoHKh4=
X-Google-Smtp-Source: AGHT+IH3IuxKKtH9t6rxieXA3Rx6JzzGtnb6rjmpLD1v9zmVwhAdvnHm7ym1aNGHTRJiwnXUpCUVdQ==
X-Received: by 2002:a05:6902:e92:b0:e6d:e8d4:680b with SMTP id 3f1490d57ef6-e78fdc4d093mr19816648276.6.1747091055370;
        Mon, 12 May 2025 16:04:15 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 19:04:42 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Use __auto_type
To: Elliott Mitchell , Jan Beulich 
Cc: Andrew Cooper ,
 Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Roberto Bagnara ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" ,
 Stefano Stabellini 
References: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
 
 <548430a5-fa4a-41d1-b5ba-ba45efa90bbc@suse.com>
 <7acc83a3-2b15-4557-b293-0832b35e3680@citrix.com>
 <35826c2a-4266-49d2-b1b8-1248aac227b5@suse.com>
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------P3gvecn7cwA0DNMYruBwa2sN"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------P3gvecn7cwA0DNMYruBwa2sN
Content-Type: multipart/mixed; boundary="------------xpxsExNMpLWZelSAS4nPw7kb";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Elliott Mitchell , Jan Beulich 
Cc: Andrew Cooper ,
 Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Roberto Bagnara ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" ,
 Stefano Stabellini 
Message-ID: 
Subject: Re: [PATCH] xen: Use __auto_type
References: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
 
 <548430a5-fa4a-41d1-b5ba-ba45efa90bbc@suse.com>
 <7acc83a3-2b15-4557-b293-0832b35e3680@citrix.com>
 <35826c2a-4266-49d2-b1b8-1248aac227b5@suse.com>
 
In-Reply-To: 

--------------xpxsExNMpLWZelSAS4nPw7kb
Content-Type: multipart/mixed; boundary="------------v60AvL0CkZLEDaakg9j0bbZ5"

--------------v60AvL0CkZLEDaakg9j0bbZ5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/12/25 2:25 PM, Elliott Mitchell wrote:
> On Mon, May 12, 2025 at 03:00:18PM +0200, Jan Beulich wrote:
>> On 12.05.2025 14:09, Andrew Cooper wrote:
>>>
>>> Now for the (new) controversial part.  Since sending this, Linux has
>>> decided to just #define auto __auto_type for C < 23, in order to star=
t
>>> writing C23 compatible code from now.  It's more succinct, and has
>>> better longevity.
>>>
>>> We might want to consider the same, although it will introduce a new
>>> example of defining a keyword, which we'd have to call out in the
>>> MISRA/Eclair config.
>>
>> I'm not outright opposed, as I don't think we use "auto" with its
>> original semantics, but it feels somewhat odd.
>=20
> Problem is "auto" already has a defined meaning in C.Having this will
> subtly break contributions from authors who weren't familiar with
> everything in Xen's headers.  For anyone who does anything with project=
s
> besides Xen this will encourage bad habits.
>=20
> I believe many projects have a rule of *never* #define C keywords.  I'm=

> surprised such made it into the Linux kernel.  I expect it will be ripp=
ed
> out in the near future.
>=20
> MISRA *doesn't* absolutely forbid this?

I'm no expert on the C standard, but my understanding is that "auto" was
redundant starting in C89, so it is almost entirely unused.  C++11 and la=
ter
*do* heavily use "auto", and they use it for roughly the same purpose as =
C23
does, so I suspect that contributors are far more likely to be familiar w=
ith
the C23 "auto" than they are with the pre-C23 version,=20
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------v60AvL0CkZLEDaakg9j0bbZ5
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------v60AvL0CkZLEDaakg9j0bbZ5--

--------------xpxsExNMpLWZelSAS4nPw7kb--

--------------P3gvecn7cwA0DNMYruBwa2sN
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgifpYACgkQszaHOrMp
8lMN6g//YDtbh8e0dEYsVo2EQStDYtqHSFqgRPvScup7luo0KFkHdV/TY9lN5y/F
22UfNaU7uY7eJtzHzM3h2IiCUiI6eRwaBZwXp0TUV7mVe5srlpyCuZfEWWqICliC
4MOwKCAOzwwDY3rmU5j8Way/HFeYdPZlNsrMtdKkbuAk77AUIXqjrcDaqO7kFPts
0CXvy+jg9FtfLBvjImljM05IHrQHgNBdzHic6SOMIYKRDr4PSYBy4ZM1R8WvtLKh
6awsKHd8AKNoNcXYDqnceN4xJDNogtjKJJQH4Vap7/ctOhHR3chMppC2KYYhnQom
QWdzuqt9J7oc/GBslnTQ8v/EVeHIz6q0nN18+7jIVVF7nNzZN0XW378APLLwBJZl
J+OknMXJ6FlbIQpQZ/PP9mN+NnQfrpjC/6rOY7FxldTqc4qDBJKsF8ta0ADrm3DI
AtqBopDr9D9mgABTb8+m60SRVr6WVhkFnuIW6t8Ub+ZNLmTAwKCt+dFViM6hrjR8
3WSIVJKQ2Sj0Iz/YmQqAtZYJ4qLoVgckVmhLi4v29+kVTiss6Azm4RHnvwgbvXTY
y7amPNV79OD3roJsj7JQITR9kpLOpbXS4S1QlOtm2cD0SNc7BHZSnGmj8vmiP56w
38TK0qW1Bg6oHiW2LO/cIOjOACC91+cyWG4YgeWVAv7nTyrWxDI=
=k5gy
-----END PGP SIGNATURE-----

--------------P3gvecn7cwA0DNMYruBwa2sN--


From xen-devel-bounces@lists.xenproject.org Mon May 12 23:18:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 23:18:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982224.1368769 (Exim 4.92)
	(envelope-from )
	id 1uEcPP-0003ca-T0; Mon, 12 May 2025 23:18:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982224.1368769; Mon, 12 May 2025 23:18:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEcPP-0003cT-QL; Mon, 12 May 2025 23:18:07 +0000
Received: by outflank-mailman (input) for mailman id 982224;
 Mon, 12 May 2025 23:18:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEcPO-0003bz-JU
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 23:18:06 +0000
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com
 [2607:f8b0:4864:20::b30])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5a9de7ab-2f87-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 01:18:04 +0200 (CEST)
Received: by mail-yb1-xb30.google.com with SMTP id
 3f1490d57ef6-e7569ccf04cso4411828276.0; 
 Mon, 12 May 2025 16:18:04 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-70a53c7c72csm14460777b3.74.2025.05.12.16.18.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 16:18:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5a9de7ab-2f87-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747091883; x=1747696683; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6XTVg2O1fCdquiTRKlwNHkGeiCx4N78omEs7oZELGtc=;
        b=A3p5bmdKYlCVxCFCYSf9cEB9CrZ8SmxirVObLLmL3OHLzRc6scbp8gUwHo4YJIbiou
         /iDx31QkXyc0DPmVwjPNK7u60vPg1U9nplrn/7vhF0u349G86rE1L7/OnJd5LXYsUhpI
         Rf00z7Y5pPmr7He45YlaH/IIuj8tMiYkX68LJNqyPbS+N6oOH6yfiukzOrY+hJ9tcwH0
         OcTt32P4Htj140/Vuaijh0nnUHX1WT9x3JFwPyFThmUuQ3sjSIreNDsC9VFq9cZzDuA+
         Vysa1W3ANf3YPSV9bCc+pAMKjT7zAimHXDLaEq3mhGkztRGQdKQSYbiu1jrd+FHmYxza
         rbag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747091883; x=1747696683;
        h=in-reply-to:subject:autocrypt:from:content-language:references:cc
         :to:user-agent:mime-version:date:message-id:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=6XTVg2O1fCdquiTRKlwNHkGeiCx4N78omEs7oZELGtc=;
        b=rF3jvU+gOcXc9aUJYD+UfnCbTxyHyWtaCchjyf2XpWQGB2BBaTyKniTF+y0uZXaHZS
         xGLFd8OFqmUjl4euGf5dyEawth9qKf8nkDutQtIdq5PYiKcklWkUJwhr3QO/xPnZJTgG
         wn+LiqmoOsxucsL1Xf7dxwDfqtp2D9xnxWTmkVPPCShaWVbrg1NvijU2u9bqf9Wh1YgQ
         ewuhzK4zjDhhSQ8vXYjzv2owXWouILi+T/wkUMrzfEQmbvqGWrnX9raxOt9d7yith8YW
         iInT9OcSALuRWRI127VdYgoUPFays4V119xhW0jQ8A/5xwnplnW3cvrvmlXgiOQMTof0
         FPTg==
X-Forwarded-Encrypted: i=1; AJvYcCXM8xn2OW70/f1Ul9RX7tYO7wuA2rTH+d6bwkw5HetA/LnFAQARyP+WZo+smnpfdt0SttwFb8tMNYbe@lists.xenproject.org, AJvYcCXg2MsbmIYk66DwGryYGEAulswNSrjcDski3sEByyFGnN7k74ymB/M/P5R+z2rowafMcZ4OoLOU7uF2XPtwfDcDcQ==@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzk8phKlsvhrBXdsedkjhrJJa/Ow6ewUc9cw53SCw6L5Ua1urei
	9h/Qc6D0fefsjP6jJHT5DCqDuYzCZIZ7eFlYtlpNijJc+KJmbLLe
X-Gm-Gg: ASbGncsc/eWzWlL6nxKjJcD1O5zmCA2eLJsLWz9pLBy711hJHkifQr/4iSDN8xMqJmT
	89KD+QQ7ojnWyqOHSkG6SPcz7qa3uolturwsEXWZK4elAW4deqOlkAHaFksoxfXEId23/ogaWYk
	8TWmFPameR9UmLmC070Z5q6Oq6di+3Np9o0y/ZZF9Wb2dVZ9pvLuCpq/qUQrQdHvWzo5D/Y02B0
	RD+XF68ZVotyZROzCDcM0fNyiJBl7IKFSgl1yrGbGMXKxdJXGA4zUHfwlzepLmYtctAQfmrS2zQ
	AorO+MFOGxhS7CvJYNH5+E9M8gFi6P8JMaeLDrDCNAbY9c+8a5IfHtg=
X-Google-Smtp-Source: AGHT+IGwj38nsNCLvMOXcii0qBFVwK11yXpsFDB9b4m1kVAuD1RsaSa5BXLe0Vx1aNtCYFS+G9agUA==
X-Received: by 2002:a05:690c:62ca:b0:707:e5b0:7cc9 with SMTP id 00721157ae682-70a3fb54d36mr200213617b3.34.1747091882813;
        Mon, 12 May 2025 16:18:02 -0700 (PDT)
Message-ID: <5ca4846e-8cb9-4160-9671-a12f8e5af9f9@gmail.com>
Date: Mon, 12 May 2025 19:18:48 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Alejandro Vallejo ,
 Xenia Ragiadakou ,
 Stefano Stabellini ,
 Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
References: <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
  
 
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: Mapping memory into a domain
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------mw05HYe8G3lmUugieckIt4vG"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------mw05HYe8G3lmUugieckIt4vG
Content-Type: multipart/mixed; boundary="------------ltTqQ89JH0h15yWUwWg0kg5E";
 protected-headers="v1"
From: Demi Marie Obenour 
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Alejandro Vallejo ,
 Xenia Ragiadakou ,
 Stefano Stabellini ,
 Xen developer discussion ,
 Andrew Cooper , Juergen Gross ,
 Xen-devel 
Message-ID: <5ca4846e-8cb9-4160-9671-a12f8e5af9f9@gmail.com>
Subject: Re: Mapping memory into a domain
References: <24a0a77b-e543-453d-b20b-0dbac111287c@gmail.com>
 
 
 
 <30243d25-881d-42d3-90c2-f791c3632372@gmail.com>
 
 
  
 
 
In-Reply-To: 
Autocrypt-Gossip: 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==

--------------ltTqQ89JH0h15yWUwWg0kg5E
Content-Type: multipart/mixed; boundary="------------0fxwGUxR1QigFmCKX9XeVcdE"

--------------0fxwGUxR1QigFmCKX9XeVcdE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/12/25 4:08 AM, Roger Pau Monn=C3=A9 wrote:
> On Fri, May 09, 2025 at 02:21:57PM -0400, Demi Marie Obenour wrote:
>> On 5/9/25 6:50 AM, Roger Pau Monn=C3=A9 wrote:
>>> On Fri, May 09, 2025 at 11:47:36AM +0200, Alejandro Vallejo wrote:
>>>>>>>>> A Linux driver that needs access to userspace memory
>>>>>>>>> pages can get it in two different ways:
>>>>>>>>>
>>>>>>>>> 1. It can pin the pages using the pin_user_pages family of APIs=
=2E
>>>>>>>>>    If these functions succeed, the driver is guaranteed to be a=
ble
>>>>>>>>>    to access the pages until it unpins them.  However, this als=
o
>>>>>>>>>    means that the pages cannot be paged out or migrated.  Furth=
ermore,
>>>>>>>>>    file-backed pages cannot be safely pinned, and pinning GPU m=
emory
>>>>>>>>>    isn=E2=80=99t supported.  (At a minimum, it would prevent th=
e pages from
>>>>>>>>>    migrating from system RAM to VRAM, so all access by a dGPU w=
ould
>>>>>>>>>    cross the PCIe bus, which would be very slow.)
>>>>>>>>
>>>>>>>> From a Xen p2m this is all fine - Xen will never remove pages fr=
om the
>>>>>>>> p2m unless it's requested to.  So the pining, while needed on th=
e Linux
>>>>>>>> side, doesn't need to be propagated to Xen I would think.
>>>>
>>>> It might still be helpful to have the concept of pinning to avoid th=
em
>>>> being evicted for other reasons (ballooning?). I don't think it'd be=

>>>> sane to allow returning to Xen a page that a domain ever shared with=
 a
>>>> device.
>>>
>>> If mapped using the p2m_mmio_direct type in the p2m a domain won't be=

>>> able to balloon them out.  It would also be misguided for a guest
>>> kernel to attempt to balloon out memory that I presume will be inside=

>>> of a PCI device BAR from the guest point of view.
>>
>> Indeed it will be inside a BAR.
>>
>>>> re: being requested. Are there real promises from Xen to that effect=
? I
>>>> could make a hypervisor oversubscribing on memory that swaps non-IOV=
A
>>>> mem in and out to disk, moving it around all the time and it would b=
e
>>>> compliant with the current behaviour AIUI, but it wouldn't work with=

>>>> this scheme, because the mfn's would be off more often than not.
>>>
>>> Even if Xen supported domain memory swapping, that could never be use=
d
>>> with domains that have devices attached, as it's not possible to fixu=
p
>>> the p2m on IOMMU fault and retry the access.
>>>
>>> Not sure you could even move mfns around, as you would need an atomic=

>>> way to copy the previous page contents and set the PTE to point to th=
e
>>> new page.
>>>
>>> Unless you want to get into a (IMO) complicated scheme where the
>>> domain notifies the hypervisor which ranges are being used for device=

>>> DMA accesses (and thus requires guest kernel changes), I think
>>> swapping of guest memory when there are assigned devices is a no-go.
>>>
>>> Xen has (or had? as I never actually seen it being used) a mechanism
>>> to swap domain memory to a dom0 file (see tools/xenpaging.c).  Howeve=
r
>>> more than one provider had mentioned to me that one feature they
>>> particularly preferred of Xen over KVM is that it would never swap
>>> guest memory.  Not sure if that's still the case, but some struggled
>>> to prevent KVM from swapping guest memory, and got complains of
>>> slowness from their tenants.
>>>
>>> For the purposes of getting a prototype I would suggest that you
>>> assume p2m memory cannot be randomly swapped out, unless requested by=

>>> either the guest or the control domain.
>>
>> The API being discussed here needs to support frontends that have
>> assigned PCI devices, but the pages should never be mapped into
>> the frontend domain=E2=80=99s IOMMU context.  If the frontend tries to=

>> DMA into one of these pages it=E2=80=99s a frontend bug.
>=20
> That's a detail I didn't get from your previous description.  If
> memory is not to be added to the IOMMU page-tables you will need an
> extra flag or similar to signal this, as by default all memory added
> to a guest p2m is also added to the IOMMU page-tables.  And when using
> shared page-tables between the IOMMU and the CPU there's no way to add
> mappings to the CPU only.

I suspect that in practice, shared CPU/IOMMU page tables will need to be
disabled when this API is in use, as...

> Do you really need such mappings to be added only to the p2m, and not
> the IOMMU page-tables?  I don't think the pages "should never be
> mapped", but rather "don't need to be mapped" as the implementation
> won't support DMA accesses (iow: "never" is too strong in this
> context).  IMO it is fine if for an initial prototype the pages are
> also added to the IOMMU page-tables, and later you can add a flag (or
> a new hypercall) that strictly only adds pages to the p2m and not the
> IOMMU page-tables, it's likely to also be a good performance
> improvement.

=2E..I doubt that an IOTLB flush from an MMU notifier that might be calle=
d
fairly frequently will be acceptable for anything but a prototype.
I don't have any benchmarks, though.  Also, having DMA operations succeed=

or fail non-deterministically would be much harder to debug than for them=

to always fail.

>>>>>>> If pinning were enough things would be simple, but sadly it=E2=80=
=99s not.
>>>>>>>
>>>>>>>>> 2. It can grab the *current* location of the pages and register=
 an
>>>>>>>>>    MMU notifier.  This works for GPU memory and file-backed mem=
ory.
>>>>>>>>>    However, when the invalidate_range function of this callback=
, the
>>>>>>>>>    driver *must* stop all further accesses to the pages.
>>>>>>>>>
>>>>>>>>>    The invalidate_range callback is not allowed to block for a =
long
>>>>>>>>>    period of time.  My understanding is that things like dirty =
page
>>>>>>>>>    writeback are blocked while the callback is in progress.  My=

>>>>>>>>>    understanding is also that the callback is not allowed to fa=
il.
>>>>>>>>>    I believe it can return a retryable error but I don=E2=80=99=
t think that
>>>>>>>>>    it is allowed to keep failing forever.
>>>>>>>>>
>>>>>>>>>    Linux=E2=80=99s grant table driver actually had a bug in thi=
s area, which
>>>>>>>>>    led to deadlocks.  I fixed that a while back.
>>>>>>>>>
>>>>>>>>> KVM implements the second option: it maps pages into the stage-=
2
>>>>>>>>> page tables (or shadow page tables, if that is chosen) and unma=
ps
>>>>>>>>> them when the invalidate_range callback is called.
>>>>
>>>> I'm still lost as to what is where, who initiates what and what the =
end
>>>> goal is. Is this about using userspace memory in dom0, and THEN shar=
ing
>>>> that with guests for as long as its live? And make enough magic so t=
he
>>>> guests don't notice the transitionary period in which there may not =
be
>>>> any memory?
>>>>
>>>> Or is this about using domU memory for the driver living in dom0?
>>>>
>>>> Or is this about something else entirely?
>>>>
>>>> For my own education. Is the following sequence diagram remotely acc=
urate?
>>>>
>>>> dom0                              domU
>>>>  |                                  |
>>>>  |---+                              |
>>>>  |   | use gfn3 in the driver       |
>>>>  |   | (mapped on user thread)      |
>>>>  |<--+                              |
>>>>  |                                  |
>>>>  |  map mfn(gfn3) in domU BAR       |
>>>>  |--------------------------------->|
>>>>  |                              +---|
>>>>  |              happily use BAR |   |
>>>>  |                              +-->|
>>>>  |---+                              |
>>>>  |   | mmu notifier for gfn3        |
>>>>  |   | (invalidate_range)           |
>>>>  |<--+                              |
>>>>  |                                  |
>>>>  |  unmap mfn(gfn3)                 |
>>>>  |--------------------------------->| <--- Plus some means to making=
 guest=20
>>>>  |---+                          +---|      vCPUs pause on access.
>>>>  |   | reclaim gfn3    block on |   |
>>>>  |<--+                 access   |   |
>>>>  |                              |   |
>>>>  |---+                          |   |
>>>>  |   | use gfn7 in the driver   |   |
>>>>  |   | (mapped on user thread)  |   |
>>>>  |<--+                          |   |
>>>>  |                              |   |
>>>>  |  map mfn(gfn7) in domU BAR   |   |
>>>>  |------------------------------+-->| <--- Unpause blocked domU vCPU=
s
>>>
>>> The guest vCPU will already pause on access if there's a p2m
>>> violation, until the ioreq has completed and the vCPU execution can
>>> resume.  That's in control of the ioreq server that handles the
>>> request.
>>>
>>> I don't know about the dom0 user-space part, but that's possibly of n=
o
>>> concern for the implementation side in Xen?
>>
>> I believe so, yes.
>>
>>> My understanding of the actions needed from the Xen side is:
>>>
>>>  1. Map either RAM owned by the hardware domain or an MMIO page into
>>>     a domain p2m.
>>>  2. Remove entries from a domain p2m.
>>>  3. Handle p2m violations resulting from guest accesses, using 1. and=

>>>     force a guest access retry (or emulate the access).
>>>
>>> 1. Can possibly be done with XEN_DOMCTL_memory_mapping and
>>> XENMEM_add_to_physmap_batch, but as I understood it it's not ideal.
>>> Demi would like a way to use the same hypercall to map either RAM or
>>> IOMEM into a domain p2m.
>>
>> Indeed so, and also the backend domain might be a driver domain instea=
d
>> of the hardware domain.  It needs to have privilege over the frontend,=

>> but it should not need privilege over the whole system.
>=20
> This can all be arranged for, I wouldn't get bugged down on this
> details initially.

That's good to know.

>>> 2. What hypercall to use depends on how the memory is mapped.
>>>
>>> 3. ioreq servers will already get requests for accesses to unmapped
>>> regions they have registered for.  If the access is to be retried we
>>> need to expand ioreq interface a bit to handle this case.  Adding a
>>> new ioreq state like STATE_IORESP_RETRY might be enough?  Maybe I'm
>>> being naive though.
>>
>> This is where an implementation in a real userspace emulator would
>> be very useful, to ensure that the API being implemented is actually
>> usable in practice.
>=20
> My suggestion for adding a "retry" response type to the ioreq
> interface was so that your ioreq model implementation would be
> simpler.  However if that's more hassle for you, I would initially map
> and emulate the access, as that would also be correct and shouldn't
> require any changes to the ioreq interface.  It can always be expanded
> later to support a map and retry model.
>=20
> AFAICT, from the ongoing discussion above, the only uncertainty is
> which hypercall(s) to use to map either MMIO or RAM into a guest p2m.
> I wouldn't invest a huge amount of time into prototyping something
> very complex, and rather get a very simple hypercall implemented that
> fits your needs.  You could likely make a frankenhypercall based on the=

> implementations of XEN_DOMCTL_memory_mapping and
> XENMEM_add_to_physmap, so that you can get a prototype working.
>=20
> I think at this point it's important to get a functional prototype, so
> that we know exactly the requirements of the interfaces that you need.
> I wouldn't bother to design a detailed interface until we know exactly
> that such interface is suitable for your goals, and to that end we
> need a prototype with whatever you can glue together.

I believe AMD needs this for their automotive use-case.  What is the
status of this code?  I believe it would be best to send whatever
code AMD has available right now.  Just mark it as RFC if it is
incomplete.  That allows getting upstream feedback sooner rather
than later.

Xenia, Alejandro, Stefano, would this be feasible?
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------0fxwGUxR1QigFmCKX9XeVcdE
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------0fxwGUxR1QigFmCKX9XeVcdE--

--------------ltTqQ89JH0h15yWUwWg0kg5E--

--------------mw05HYe8G3lmUugieckIt4vG
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgigdkACgkQszaHOrMp
8lMNlg//doCtALKgWu/w6qjlBPFJEHoFN9TcYxrr8I4mqJTCruQZmE0PoEP/K+82
4OfgMX/nkY3OHAT0qhGVf/0x9+u7V+C9fzS38MiR4SM7tfuiWZeG4vZPvhb/5QPU
wb5YV+Tso2N5rk1Lh+cPNw4hW+LgWjD4Nan43qZu/aJnrXWtRySG7RUN0W3xhQmC
ZdJTVqfIRydgKZDILFKZOT+vexLn6O6sPe1ChvZKY8aaZoW0vXpW7rYzfTvcV0Q5
3ufITt3nBg+iYhSrE710uDFjIbVDcBC5Ot71dR784KJRJb2FBsSynFZYlBWHO0uY
AxqDm/fs+BhW6o86o6npRH6egzGGyZ+mPVMvAQqoq/VBaDsNBL9uqrwxinOComu3
1nhP1LLdzm+zBqqdTmV/pGsc18mso8L6IxvgjAhH4F7srjWMdibvgDTi7cBA4h1L
iBHQAIqROwhkB+xkZ2oimD42XffdZxrX22ENuQdxjGN7QGWfdREJeefo6K3nsDZh
ERUZGgoOf48J3RblRK4klJIBrX4FVsoJo3QWAyeIE/covy7gK/zD+YiQn3MunA4k
DGe6OAsPAytRbGrxaXkl9QFelBUpK/smx3tqBr8AQz39egT/ZwQsydlDu4IAw+gA
swttjKKbTtq+0G+IrnuuPww7NN0Ucd70gSbuNiiFYlXfLVX1LLc=
=zfDI
-----END PGP SIGNATURE-----

--------------mw05HYe8G3lmUugieckIt4vG--


From xen-devel-bounces@lists.xenproject.org Mon May 12 23:28:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 23:28:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982237.1368779 (Exim 4.92)
	(envelope-from )
	id 1uEcZ0-0005TY-QU; Mon, 12 May 2025 23:28:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982237.1368779; Mon, 12 May 2025 23:28: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 1uEcZ0-0005TR-Ne; Mon, 12 May 2025 23:28:02 +0000
Received: by outflank-mailman (input) for mailman id 982237;
 Mon, 12 May 2025 23:28:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEcYz-0005TL-SX
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 23:28:01 +0000
Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com
 [2607:f8b0:4864:20::1130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bdc12f4e-2f88-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 01:28:00 +0200 (CEST)
Received: by mail-yw1-x1130.google.com with SMTP id
 00721157ae682-6ff4faf858cso34681947b3.2
 for ; Mon, 12 May 2025 16:27:59 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-70a3d895d7bsm21737407b3.7.2025.05.12.16.27.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 16:27:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bdc12f4e-2f88-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747092479; x=1747697279; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=WK+Ch9yZX8O9anWQ/8+vUlB5aBAmSTwuvmPKn85OuMs=;
        b=Kgyvl4mSc/lVLMFB7ieBUfezoFil2zrdtCxrjwHmL9KMmysKM7SGOo8/XpqAMDCjIH
         Q2SwwH+gVA2DoG7EEuiYsJ8Dqis+fwm1X8hS5gEgbdFbCN96iv98vI+ASyzIJ90z9F9A
         X5JYi1JtSZbmfFeTmwK2qd1escwcakPlWhpqHiEClUl+QGRUdt4LzRdzDC1jTaSivAkW
         rRb8JOqv46SccMtuIomS2zz62ZssKLtAVddsN6QGTgQVQ0rbANdznrKcZV/nIrxdrNS8
         wiIeY3WCgnHV88/51tQMjtVKuoY6mSVQYSjRIyRXWoxbhGmqhO6kpcM8Mz9Au/GWap92
         HYdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747092479; x=1747697279;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WK+Ch9yZX8O9anWQ/8+vUlB5aBAmSTwuvmPKn85OuMs=;
        b=dCRvh5GVMbM0tajQ85DR0PE02vwBz2wRzXvoKodjcwFnlq4FTeDz0wZu7855SpMewH
         ojBHL+4YeUajJO1VLeHEEmCdbRwRWWH4zVgm0nOqmOAo4b/DjocJQP3DH51tARcDYZIZ
         B5exIzKBF9CxVZvDWHSeo+YN+6RvLY6z77ycbsJEzBiSEUWIRS16xVoHzKsKrNtfyqVj
         IzwGdA7Qt6e54gEhPzsJ7H1UWZrrH5GsLQO+QKLTIRE6NmPV2//Gd4mWJfg+7Xpxgs6x
         ySdfAW5/YQWN8verGeJzsa/+pydbOCyGa8kfNGOQ9kew7QRv0pepeQBUI5w0kAr4IrKy
         TWmQ==
X-Forwarded-Encrypted: i=1; AJvYcCXTuPQ/Y+cXu/F2CFdTa5CUXr/GK2W1lMOgAprWF17402zDKJofnUvF22jS4MVC3x+A05b/X/3IljA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyUS1y33dA7/227UEKTK4PBULe6CrhqYkNmWAsjH3MJfiIG35v4
	Vwg5KH2CTS6Yiwvo2eFG9orqD9ryUNrabJWpsRTYphn35p8yLctT
X-Gm-Gg: ASbGncvzPApYKgEKbJsYRT52fOcSr439r2Q13qQHY0vcfbtem64WrU3BDRzP6/fF/S8
	WBm20lnlsibsAojw8BLdF3XTBCOSvFapBM3yLo8TFvYyIxzeXWlDyx81nBcz9KD9797q7dk0LCE
	kIEcWmT+/i7IV6VBF/tsUZRjO3kUgd/FVYu8PustAVSqKjkLL0+NacX+m/1f2/9V2LSffAVBiKp
	y/1ZyiG7OPBY9QfTogg/kMnTCZNX1jKmT+zbB+dviw9ZNlcfDVKMqZUZBJNTB9cX4GU7/SFTe6k
	zf4nZ3xb6+CTXRrGdthkS/rq7hhFN+lsUjKWyZnAiT1taQrCx4ZUa2Y=
X-Google-Smtp-Source: AGHT+IE5qx4TlHX7eBDRUyQ5bsaJUy/dapKIzUrZjvp0OZNRWSOJLE5SZUbDisgv3XayxX/3zKOGLg==
X-Received: by 2002:a05:690c:2506:b0:6f9:8605:ec98 with SMTP id 00721157ae682-70a3fb0dde7mr189342887b3.28.1747092478756;
        Mon, 12 May 2025 16:27:58 -0700 (PDT)
Message-ID: 
Date: Mon, 12 May 2025 19:28:51 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/Kconfig: Improve help test for speculative options
To: Andrew Cooper , Jan Beulich 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Xen-devel 
References: <20250508160336.2232152-1-andrew.cooper3@citrix.com>
 <18f73078-c512-416b-9406-c76f8db178eb@suse.com>
 <63652356-4b82-401f-a6ba-8eb53b2f8317@citrix.com>
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: <63652356-4b82-401f-a6ba-8eb53b2f8317@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 5/12/25 10:58 AM, Andrew Cooper wrote:
> On 12/05/2025 11:58 am, Jan Beulich wrote:
>> On 08.05.2025 18:03, Andrew Cooper wrote:
>>> The text for CONFIG_INDIRECT_THUNK isn't really correct, and was already stale
>>> by the time speculative vulnerabilities hit the headlines in 2018.  It is
>>> specifically an out-of-line-ing mechansim, and repoline is one of several
>>> safety sequences used.

Nit: retpoline, not repoline.

>>> Some of this boilerplate has been copied into all other options, and isn't
>>> interesting for the target audience given that they're all in a "Speculative
>>> Hardning" menu.
>>>
>>> Reword it to be more concise.
>>>
>>> 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 
>>>
>>> CONFIG_SPECULATIVE_HARDEN_BRANCH really ought to be named
>>> CONFIG_SPECULATIVE_HARDEN_CONDITIONAL, but this would be a (minor) functional
>>> change.
>> Hmm, so you're suggesting all the straight-line speculation changes then ought
>> to be conditional upon a separate, new Kconfig control? So far I've keyed them
>> all to this one.
> 
> Straight line speculation is complicated in multiple ways, and our
> understanding has evolved over time.
> 
> I'd forgotten that we grouped it with HARDEN_BRANCH, and it is not an
> ideal grouping.  What we have in the way of SLS protections are token at
> best.
> 
> First, in light of Branch Type Confusion on Fam17h processors, where any
> instruction can manifest as a speculative branch, there's nothing that
> can be done.  (This was demonstrated rather more thoroughly with SRSO
> than BTC.)
> 
> There is straight line decode (at least) through any branch the
> predictor doesn't know about.  Only "taken branches" get tracked, but
> also you get a higher rate of SLS immediately after leaving userspace
> for a long time (such that the branch predictor fully lost supervisor
> state).  Again, this is inherent and we cannot control it.
> 
> Intel say that a branch type mismatch (for a direct branch) will halt at
> decode.  Indirect branches are documented to potentially suffer SLS. 
> AMD Fam19h say that any branch type mismatch will halt at decode.  Also,
> with AMD IBRS, indirect branches stall dispatch until they execute.

What about Intel IBRS with an INT3 after the branch?

> Therefore, it's indirect branches which are of most concern.
> 
> Putting an INT3 after any unconditional JMP *ind is easy.  Compilers
> even support doing this.  CALL *ind on the other hand has architectural
> execution beyond it, so if protection is needed, LFENCE is the only option.

Does adding an LFENCE after every indirect call make sense?
What about RET?

As an aside, this seems like the beginning of the end for object-oriented
programming in kernels and other software that needs to be concerned with
speculative execution security vulnerabilities.  If every indirect jump
completely stalls the pipeline, it’s almost certainly much faster to use
switch/case or (if the language has it) pattern-matching.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


From xen-devel-bounces@lists.xenproject.org Mon May 12 23:31:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 23:31:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982246.1368788 (Exim 4.92)
	(envelope-from )
	id 1uEccj-00078j-8Q; Mon, 12 May 2025 23:31:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982246.1368788; Mon, 12 May 2025 23: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 1uEccj-00078c-5K; Mon, 12 May 2025 23:31:53 +0000
Received: by outflank-mailman (input) for mailman id 982246;
 Mon, 12 May 2025 23:31:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEcci-00078W-1y
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 23:31:52 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 46c116e8-2f89-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 01:31:49 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a0b933f214so2199518f8f.0
 for ; Mon, 12 May 2025 16:31:49 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f57ddd2dsm14027409f8f.9.2025.05.12.16.31.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 16:31: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" 
X-Inumbo-ID: 46c116e8-2f89-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747092709; x=1747697509; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+btDOojkAlbFtzcpa3KzqDOzCKQ2qfLl/63heWYuPdE=;
        b=R5s2sZXX0M465t3I31Uzd9zza8YtE938eSA3XIv815E/8is3Dg4CS6dOvWZDVkYhEr
         irtVa8oyzUPizDEcTWkLPU/k96WkyjWoKP+bbFqyRef9bPKPmtOJ90RurTjA5GTHAXrM
         vjYDSCHqrfCBRdHS6wtWxqykiGSyhkPV0TCf8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747092709; x=1747697509;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+btDOojkAlbFtzcpa3KzqDOzCKQ2qfLl/63heWYuPdE=;
        b=QKUlrDZ1RzZgrUlU5dWgRnbk+EJtOA8DRlxSRM19ktEku+6Ya5NcvCTzMGbtwyTLsq
         XN+1MC6bZBT8kiT9FCa0GbgwV0kE6bJztWy/E8h2JtaIWTvY3RugyMX/atRlg5tuKsXi
         j1XLz7vmmZLwYKJLDT0CKjTfQB1i9VgjmFjtDIA0D8MeQkX9a1qTYMF8RZ6hfSs9x51f
         eI1mXtbQUH7ZCwYryM2wO+cbbXsdAtwd3RKfobDDf+m4RSOQVzjw+PrsuHbf04rOgrd+
         QklXzpNKN1iH2d4/FTfNVhUBCOxz7b4ZJSkogR67eAx4SO3M6xaSQjdERf+0JcUDJYcR
         6jQg==
X-Gm-Message-State: AOJu0Yyowk7c/BOQLIdNg0LxUz9MuzzwTW0UXKkqGqUhk4UsmOnl6rh8
	N4ZNPG/vofQtWNSuf+QevXnegJOHo9rGJVPLcSUCy0sE/V2VlFfaygNylwKKYHg=
X-Gm-Gg: ASbGncuSEsjPC2CxGigr4yfrOKiapMOilBBHR3wWrkrK2fhaHwllp0CzhKkE0jn9UiV
	luXaXbFlNb6KvARhYd9nwXmhiEWNhkwNGwgQBOi2/5nrN9Z1cxj/hiRHdJ9QKREazYMdONnvVkN
	g/Bfq7y0sMnUs4VEAZzC9dp0OAZFSKvMWNzxQwRdf2/iju0WTRjC794ssmNMssrl7txTM0o/JWA
	CU0EIqS+biGAzuXa88OA+mAmN+hKo0tY/HKiMWo0FdYenEhdf6ykuU8VCLRV7RDwPOLMniq/Lmb
	BYy82/xCBD8Hw00ail3gVoTAr5CPhWZyreh7FVU4fYnZH+G/pyOuQaBSg/E6crTe/yd5RVqdFIH
	MSEGwt8NN/XddLSqU
X-Google-Smtp-Source: AGHT+IEvE1q9G3IJPP49pmVWuZgYrLbp37azE5xeqKZ8DTYLKd8N2w6fKE2ZbVu4DD6h8MsSp5+zdg==
X-Received: by 2002:a05:6000:186e:b0:39d:724f:a8f1 with SMTP id ffacd0b85a97d-3a1f64279e0mr12271078f8f.10.1747092708726;
        Mon, 12 May 2025 16:31:48 -0700 (PDT)
Message-ID: <1b6a07cf-497a-4d35-8836-5011537f1110@citrix.com>
Date: Tue, 13 May 2025 00:31:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Use __auto_type
To: Demi Marie Obenour ,
 Elliott Mitchell , Jan Beulich 
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Roberto Bagnara ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" ,
 Stefano Stabellini 
References: <20250505124646.1569767-1-andrew.cooper3@citrix.com>
 
 <548430a5-fa4a-41d1-b5ba-ba45efa90bbc@suse.com>
 <7acc83a3-2b15-4557-b293-0832b35e3680@citrix.com>
 <35826c2a-4266-49d2-b1b8-1248aac227b5@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: 8bit

On 13/05/2025 12:04 am, Demi Marie Obenour wrote:
> On 5/12/25 2:25 PM, Elliott Mitchell wrote:
>> On Mon, May 12, 2025 at 03:00:18PM +0200, Jan Beulich wrote:
>>> On 12.05.2025 14:09, Andrew Cooper wrote:
>>>> Now for the (new) controversial part.  Since sending this, Linux has
>>>> decided to just #define auto __auto_type for C < 23, in order to start
>>>> writing C23 compatible code from now.  It's more succinct, and has
>>>> better longevity.
>>>>
>>>> We might want to consider the same, although it will introduce a new
>>>> example of defining a keyword, which we'd have to call out in the
>>>> MISRA/Eclair config.
>>> I'm not outright opposed, as I don't think we use "auto" with its
>>> original semantics, but it feels somewhat odd.
>> Problem is "auto" already has a defined meaning in C.Having this will
>> subtly break contributions from authors who weren't familiar with
>> everything in Xen's headers.  For anyone who does anything with projects
>> besides Xen this will encourage bad habits.
>>
>> I believe many projects have a rule of *never* #define C keywords.  I'm
>> surprised such made it into the Linux kernel.  I expect it will be ripped
>> out in the near future.
>>
>> MISRA *doesn't* absolutely forbid this?
> I'm no expert on the C standard, but my understanding is that "auto" was
> redundant starting in C89, so it is almost entirely unused.  C++11 and later
> *do* heavily use "auto", and they use it for roughly the same purpose as C23
> does, so I suspect that contributors are far more likely to be familiar with
> the C23 "auto" than they are with the pre-C23 version, 

auto in older versions of C is a storage classifier, so grouped with
static, extern and register.

It is inherited from B, and along with K&R's having implicit int types,
was there for familiarity of code to existing programmers.  e.g. "auto
a, b, c;" was B's way of saying "I'd like 3 ints on the stack please". 
It is very rare to see in C these days.

C++11 repurposed 'auto' as a type, and C23 has followed suit.  This is
compatible with the prior meaning, and 'auto' can still be used as a
storage classifier in C23.  You can't however use 'auto auto'.  In
GCC/Clang prior to C23, the same behaviour is available from __auto_type.


So.  auto as a type inference keyword will be commonplace C in few
years, just like it is already commonplace C++ for a decade.

Right now in Xen, we can choose to either use something that is on the
brink of becoming normal, or we can use the older form which will get
changed at some point in the future.

One of these makes far more sense than the other, considering that it is
already standardised C23.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 12 23:54:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 23:54:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982255.1368798 (Exim 4.92)
	(envelope-from )
	id 1uEcyX-0001wL-RO; Mon, 12 May 2025 23:54:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982255.1368798; Mon, 12 May 2025 23:54: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 1uEcyX-0001wE-ON; Mon, 12 May 2025 23:54:25 +0000
Received: by outflank-mailman (input) for mailman id 982255;
 Mon, 12 May 2025 23:54:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEcyW-0001w8-24
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 23:54:24 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2412::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6ca86e4e-2f8c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 01:54:21 +0200 (CEST)
Received: from CH0PR13CA0044.namprd13.prod.outlook.com (2603:10b6:610:b2::19)
 by PH8PR12MB7157.namprd12.prod.outlook.com (2603:10b6:510:22b::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.28; Mon, 12 May
 2025 23:54:16 +0000
Received: from CH1PEPF0000AD79.namprd04.prod.outlook.com
 (2603:10b6:610:b2:cafe::4e) by CH0PR13CA0044.outlook.office365.com
 (2603:10b6:610:b2::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Mon,
 12 May 2025 23:54:15 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000AD79.mail.protection.outlook.com (10.167.244.57) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Mon, 12 May 2025 23:54:15 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 12 May
 2025 18:54:14 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 12 May 2025 18:54: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" 
X-Inumbo-ID: 6ca86e4e-2f8c-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=N3kzDHPIpEf5EevnDgjJoEcaI7xJ4C3ubiE8ViyT1eA2PBSt2peEzGa/cR5yd0pgIiz1SspbJR5fIMjk/Gp6xmIHy0iQDkM/Hf6+t8TmNk/262PQZFGaFdMBF5MITADqKpDpcIAz/GKNzo/rl0czspY1NV8V4YIX3aQgrT2AbIw2ziB7jTzq1w5LxSP7vDfAnG1zoYhslbB01gxN5gy+Co9gmB0Z7LV3ugdtDPnE3pxQp2dhs7+J01kQoDKa6kbwmUpXf3kINubNwRX1/WgEc8GeayZpZGXtz6E96HCOBWd3UMS5Fg677WwNVRVLJ6CWzmwWsl199gEBZale8AbYjA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=aF6YROwOuGlvpozS/KCefgc2H3PvRpkN/JGW+4Y0CPA=;
 b=xU1xSWwx7ZVIohcRScwyuqPyAUI4B4/GKCfyQ4Lhpj3Ef2lbC6xZTRWq7rogajTmaElu++RQHAxamFg+BZUY76cJKd136ydzVctRCb535MV4YPa8inTBQ8yv5bUfxen9kouQ6KTc5TQUXnDNsWHuZ+a6CKBXshqJZ1TnoM1cdo/3PbIB5A15ETBnpk8EirH22ompcajAnWv7r/SVtvYIDI4JRCxbSiMT1JKwCC+p1Y8KTRkwooKAJ0e3K7Rhv+kMibOa/tafx6m8/AUe/fFimNd4V4NoiNGbuhLL7VVmwJzh13uOBxzjiYtmwWVTtpWwfmEgnNioA4+7XQTiu2S4tw==
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=aF6YROwOuGlvpozS/KCefgc2H3PvRpkN/JGW+4Y0CPA=;
 b=0X9MIKAACl7ySVZ91FvLVWm9Onsjzjrapql63uh1ojRvVSvqG553rD/ejl6fTggA57hISZBbSPoAD47WFFV3nYL6hsOuw5fz+iUqCy/2OGAE767AqwFaKMUpG9SP7eOaUBiJ3iJFXky+zW74Glv7ArxYH04N/25wQCDeKN2J9V8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Anthony PERARD
	, Juergen Gross 
Subject: [PATCH] tools/libxl: Only access legacy altp2m on HVM
Date: Mon, 12 May 2025 19:54:07 -0400
Message-ID: <20250512235409.18545-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD79:EE_|PH8PR12MB7157:EE_
X-MS-Office365-Filtering-Correlation-Id: 9536bfef-7361-4bc2-e442-08dd91b04d44
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?m3YSaJUj3TVL/jhTDnprYriagf6IuKWqYmYTAAj3zQhMAgORb+wvZMMaNlQs?=
 =?us-ascii?Q?A9y3uJLfO9LkaL3eSE1Hw2yfrbJIU/VwVtfVkoTVcxf2M+UNoezRLbTnqVzE?=
 =?us-ascii?Q?OnO3w9AoGWHrldYn0Grgv3pas1gqCpqWRP1k2rzj4Ieyy24RqtPOWCDijCRz?=
 =?us-ascii?Q?Eb1BPjvHWOmYYdrbP1d4JXWtJMQuW3tEzTWhJL0tLxIYx+SL3zm221E8GKd/?=
 =?us-ascii?Q?A8WiRHI/VLa4lhn1yQkZElIhbrSsBhIeWaNYckcl3MNbKl7g7yqjZN83IB71?=
 =?us-ascii?Q?LgWOl3/f9kkHdsJuVoEugGEPBlBZQIJlCejvjVfDI7dutHE3Rf4psqha0/QW?=
 =?us-ascii?Q?Gc4IyLNvbaLlag45qsVVq7q/j4BN0VJwY6p6+QsVZ1yqKDiMzoaF8H1MaqYF?=
 =?us-ascii?Q?mUba+46GIzNE845pe9QzzDxfpSqZWQKYT522o164neyJUX2Ohc7Mbe9nA4CA?=
 =?us-ascii?Q?QFvrHgA7kC2iyiZQDxyvizA/tASegVZs6ftu6U0eDxsFr84YOOspu5U6+X2s?=
 =?us-ascii?Q?1FJrh+HhIcTCO6kB4DgdJNrh/RvHRC0TJX90Rkk7e5pauywkzXMaHH+h/ct7?=
 =?us-ascii?Q?CrBWdWF0pxpv4vyNntAu9JrLuU0DgCoWHgFxwdEBjy4lLKyyB69g9YLGllQD?=
 =?us-ascii?Q?kCHno6ErHxmFd2XTQvD0kh5zu3IKyjW/lBHtOk9ONnyXdPSotPVy4WpbLmOl?=
 =?us-ascii?Q?LL1aaiuGizUV6ajnrMLle20rSWlyFlxdhzxJuEphKCoQNb/SGKIyo0B4aCof?=
 =?us-ascii?Q?iuT7ba7pHJYDj7n567jQeZeAtZPBAY4tVGgO2PxC3+sUMFjwFR4Yt6678VGF?=
 =?us-ascii?Q?0tQO4pqloajPsyIK47a2Q7tcT99YAC/FJJ2Ye2yRDNVW2CP5IoWmE5HvnKgk?=
 =?us-ascii?Q?+nmc+sEIoMYVHWD40qlDzySYpOZ7IFLfOwhdzYl7M10YmM1oNytK/AKtjGdS?=
 =?us-ascii?Q?/gh0iOu9RDBTep61IqL75FhRW5aIySLQgKSTmVj/v5g2zWpQm+1nSYBqJQbJ?=
 =?us-ascii?Q?RTwiBBH1+PZMn3tQHvdL749T8nCzORkKfiAhk369lfZOAeeha20EqxmLNF2f?=
 =?us-ascii?Q?+7cfVKejnlKJgfOolHvF0cGYVVRhr8Ufhh8wfW+TSKNH2Tcj0jQhnJRG+g3P?=
 =?us-ascii?Q?tZuQ+8TJJh5gBf2vKKOYii5K6QTTG6KKq083iuJivt1KEeoKhRs1grMSwGra?=
 =?us-ascii?Q?+5KPSmQcztjOvw1b2ks6s/ZeyIv4DgdFCgK+YlhRr6WpXnK1qLJ3cmdVapVu?=
 =?us-ascii?Q?WDonMFRkxig03i4lTyXm75VdbNaCVsIlxNfgirH9i8XUJqCfedpDfir+U8bP?=
 =?us-ascii?Q?bB0K6aBGBqRv4UxsJTqgvcGgRwcvAx6Cy3aQB2dsTEIYT20dHaesJrKlqfwY?=
 =?us-ascii?Q?6YfJvid51peOPWUSJ2enm0vm0slqj211G6LfgfoJldUsRntXnshJs87OiueT?=
 =?us-ascii?Q?6hAnVKtcIRplIbxwU8yjwZHJKwWYXwqwmDAw4jshnjhEVFQoygx5TZeWHxPt?=
 =?us-ascii?Q?ltpc1ARLKbEIYBHjJF8zio2c8BAXGe0RJAuV?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2025 23:54:15.2549
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9536bfef-7361-4bc2-e442-08dd91b04d44
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000AD79.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7157

Only access the HVM union b_info->u.hvm on HVM guests.  The union
access is not guarded, so this reads and sets the default even on
non-HVM guests.  Usually this doesn't matter as PV and PVH unions are
smaller and zero-initialized, but the zero default will be re-written as
a -1 boolean.  Generally, it it could incorrectly set b_info->altp2m
through aliased data.

Fixes: 0291089f6ea8 ("xen: enable altp2m at create domain domctl")
Signed-off-by: Jason Andryuk 
Change-Id: Ifaca3533dcce3f409c2efa292c7e96fba6371d9d
---
 tools/libs/light/libxl_x86.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
index 0b1c2d3a96..b8f6663829 100644
--- a/tools/libs/light/libxl_x86.c
+++ b/tools/libs/light/libxl_x86.c
@@ -821,10 +821,12 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
      * If the legacy field info->u.hvm.altp2m is set, activate altp2m.
      * Otherwise set altp2m based on the field info->altp2m.
      */
-    libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
-    if (b_info->altp2m == LIBXL_ALTP2M_MODE_DISABLED &&
-        libxl_defbool_val(b_info->u.hvm.altp2m))
-        b_info->altp2m = libxl_defbool_val(b_info->u.hvm.altp2m);
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
+        if (b_info->altp2m == LIBXL_ALTP2M_MODE_DISABLED &&
+            libxl_defbool_val(b_info->u.hvm.altp2m))
+            b_info->altp2m = libxl_defbool_val(b_info->u.hvm.altp2m);
+    }
 
     return 0;
 }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 23:54:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 23:54:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982263.1368808 (Exim 4.92)
	(envelope-from )
	id 1uEcz3-0002RV-7v; Mon, 12 May 2025 23:54:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982263.1368808; Mon, 12 May 2025 23:54: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 1uEcz3-0002RO-3q; Mon, 12 May 2025 23:54:57 +0000
Received: by outflank-mailman (input) for mailman id 982263;
 Mon, 12 May 2025 23:54:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEcz1-0002Bc-Bl
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 23:54:55 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2408::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7f842323-2f8c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 01:54:53 +0200 (CEST)
Received: from MN2PR14CA0022.namprd14.prod.outlook.com (2603:10b6:208:23e::27)
 by LV3PR12MB9118.namprd12.prod.outlook.com (2603:10b6:408:1a1::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.29; Mon, 12 May
 2025 23:54:47 +0000
Received: from BN2PEPF000044A0.namprd02.prod.outlook.com
 (2603:10b6:208:23e:cafe::fe) by MN2PR14CA0022.outlook.office365.com
 (2603:10b6:208:23e::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.29 via Frontend Transport; Mon,
 12 May 2025 23:54:47 +0000
Received: from SATLEXMB04.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_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Mon, 12 May 2025 23:54:46 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 12 May
 2025 18:54:46 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 12 May 2025 18:54: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" 
X-Inumbo-ID: 7f842323-2f8c-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yztJB1E6jZtmrOVY5I9VlUcAvwXGM0A7lXTky+QTTmZIrgbDMeib+qw60oT2N0GTZNCpByPVehWh71k1OmRuJ7FwvrgH/0B2Bvy4fByeY2h6FPi4YxJ6GNhjEc/Wk+U7aoZgjl3mtyuAY/UTSNMoRDli/SrzGK+F/9uWdHjauxJKU+ooXNivoR0bu5274kn0+C15dRzUl7lIwZctfe9xkwuZKUNCXRs8oREXN1GgEky5o6oouj3DoW4id8BVjzPK7vfbMMpa7rOdAvrB/u6F49pjCHy8qkIWJ0aydbh7koHNBte13hy+kD1SM/vR+F4XUI1eB43wurmgDIAvx4DKHg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FWzImoHZtUsaD5LYTagTZgAmQYYnBWuK5k+u1fuPZEk=;
 b=emkViMz0FXpc9yv29gMaMtu7f/xValj61OAV1jfjvOuWBL6i27yYXnhW8ASx1+HZt+qcIBvUVF7BspiQVwmc3GY8TOmJCeBqrKSI5t7EB76IAUOqrqRIIXAMghuZ82ZmQhaDBNvr3CelgIsmlh+6kCaoA/vaairq1rsZF+2TeK8eHJDUASYBzKg8a98LjGXDjQ//x7uL/emUOCAojPS4OjFFdKBpH+8G9vvPRsmfFIIvRdrJf7U1nMmgGkibAPqhYobhX4R2+UrPFGfR0somPozXubmkhHcltURAwic94jvWRWhrPBUIxfaDleSoQ2dnZXdzp+OwhmnjUySawQMPTQ==
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=FWzImoHZtUsaD5LYTagTZgAmQYYnBWuK5k+u1fuPZEk=;
 b=40BFBm+DmCPn1SuHqLNGJPYq+jaOrI+v8UQDXLWXdEEsmglvF5UXvu8/UrR7LtrREEEvjbdb6CFLv/aMymnF7ppfd6yqdP0RQttOIe8sAMTyEDF86UmV0o9584/gC1zHOrMKqJa/ox0cQB4L4zhP6aL4SGamsw4a4xdVn/vU/S4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Anthony PERARD
	, Juergen Gross 
Subject: [PATCH] tools/libxl: Only read legacy altp2m on HVM
Date: Mon, 12 May 2025 19:54:08 -0400
Message-ID: <20250512235409.18545-2-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250512235409.18545-1-jason.andryuk@amd.com>
References: <20250512235409.18545-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A0:EE_|LV3PR12MB9118:EE_
X-MS-Office365-Filtering-Correlation-Id: 1348f7b4-4e24-4abd-8664-08dd91b06024
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?686xZexnsJM7L7P+fkLupATpuuo33P2iTSUGiYIHcb68g4Z9nvKnCyLHPIRp?=
 =?us-ascii?Q?oMYQtduucLGg6AYrXjrruLrzHaxEo5KQwG2vd7pzC6JCYZIFMKgnIHbKtqOm?=
 =?us-ascii?Q?+Lh9FiT+sBgH9bIcgfvvwUOHb+YUDDiGHUCYeyZObGFCH6DsIeDDVc+pN5QI?=
 =?us-ascii?Q?I3BBJxLC6dKnJD4bc6QQD9/mXBpmU8U9Jur3gwSpwgaS6lie779sVBhk2SNd?=
 =?us-ascii?Q?QxC5OA0nnHq68ex0AAJi7p2GIN9OI81eQdzL4NP0ZB55GhiI9ZjDvSyVSFw7?=
 =?us-ascii?Q?OieFMpykp4VBgutUlIKW7N0l1OrUqX1snTIMKxCn+Q54516bjF+JYwbMzR9H?=
 =?us-ascii?Q?wtTjXNFaK4N6LF3QlSJj4ksKQPuyJeJMPqFMCfxWduUZMNBp1B6W+fILxx6I?=
 =?us-ascii?Q?HGoz2afiUcvP4Y0BZLiuS9hzVYCu+bU3ttmXjUq38EayNkjkQzbumlMmDygv?=
 =?us-ascii?Q?KXJz4R3+OTWMwkn+rQPDl20/aiMuHZT1dmR7Ce5P5/rGbkBpNTbVC8HYOO/G?=
 =?us-ascii?Q?ZiH8x2xT3a8To5nOWfqGX+i7z8Da2aJ67MCzBwM+4Z7OHI1AGcS/6p7lQYlJ?=
 =?us-ascii?Q?AdPrez1H7xpwpC3YTbrCGiJkN8y82pP0HGqt6gFyJlbtmYjc0P369mAy3iOU?=
 =?us-ascii?Q?tJt9eYGh3biNWOpFM3IhtNVNxOSJw4ms3a/gCdvpR7fYHWZxNhmjOlzRpwup?=
 =?us-ascii?Q?uvXm5wFKqM+HaZKIufdQ9yfXM9WzPl0d/F+3jsji7ehfr8AkHhnTtkWLI/ss?=
 =?us-ascii?Q?OWWyPnD4FsI6ZIgDQLj/Nt9sGfAyzwmtl8+nn8l9eCwrtoOn6BMMKSm/hilf?=
 =?us-ascii?Q?iBCME7oWTB79cJAuSkYt4TRSbfE6ut4gN3X7Y7l2N3w2L4GQrdjf5BKRbAsJ?=
 =?us-ascii?Q?XX2G4UshrybPvsw0VCxjoq1C9NCE2v16nnJTdce3EBnl4nEKMVFGSxMXBDMq?=
 =?us-ascii?Q?Xai2Eznn5HntSgg21S8H4zdafRywGTtNHMIhCZXzqqv4j3nZLfY2v8acKfzH?=
 =?us-ascii?Q?hE7qJ6niscN3kR/wafSYoI/QGnE6fDfolKsSLtCR/C1j7yqdBSTFvsaHDjGc?=
 =?us-ascii?Q?eeh588URSqj87+RPErJtZj0rBT8wIaPs8rz+yJkENSETMBDJOIenLL1GSMRg?=
 =?us-ascii?Q?7x6DKrHvUm0DnPIiq8yNiq9j7t9LXl74CLnJUgvWJb3ljGY07D6JYXGyqOJr?=
 =?us-ascii?Q?YNlny3EvOZg1n9jns0EFUYgFBhgZ+fUMSGHFXC9ugGTRTn08bZzaehTqX+Ap?=
 =?us-ascii?Q?5rHI6mrGHxUPbnNEdhPOVr1OjFLTNUNTKqE60tAUx7V5+iBgK44KLLXhTpSu?=
 =?us-ascii?Q?Fi7pu1zYpykU18YxId/+lA07z0FDAi1ikvp6HYuNqjSeYmLYynlCz87uRw+f?=
 =?us-ascii?Q?hUBuO+GKW268AVe/NcUzOsiauyP9Cdi6L8lkC8RXXdVUGWf2FjIYRVDsdy8X?=
 =?us-ascii?Q?wOtm384VQWxiItzkrnAv65/WVPgFEpYaCjjOXqRCJNy4RLdvjsJbhoafRtVV?=
 =?us-ascii?Q?eKW6DLQDrzz0XEUtIX1ql08aMHCrG2eSvmXA?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2025 23:54:46.9326
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1348f7b4-4e24-4abd-8664-08dd91b06024
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=[SATLEXMB04.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: LV3PR12MB9118

Only read the HVM union b_info->u.hvm on HVM guests.  The union
access is not guarded, so this reads even on non-HVM guests.  Usually
this doesn't matter as PV and PVH unions are smaller and
zero-initialized.  But it could incorrectly set b_info->altp2m through
aliased data.

Fixes: 0291089f6ea8 ("xen: enable altp2m at create domain domctl")
Signed-off-by: Jason Andryuk 
---
 tools/libs/light/libxl_x86.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
index 0b1c2d3a96..b8f6663829 100644
--- a/tools/libs/light/libxl_x86.c
+++ b/tools/libs/light/libxl_x86.c
@@ -821,10 +821,12 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
      * If the legacy field info->u.hvm.altp2m is set, activate altp2m.
      * Otherwise set altp2m based on the field info->altp2m.
      */
-    libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
-    if (b_info->altp2m == LIBXL_ALTP2M_MODE_DISABLED &&
-        libxl_defbool_val(b_info->u.hvm.altp2m))
-        b_info->altp2m = libxl_defbool_val(b_info->u.hvm.altp2m);
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
+        if (b_info->altp2m == LIBXL_ALTP2M_MODE_DISABLED &&
+            libxl_defbool_val(b_info->u.hvm.altp2m))
+            b_info->altp2m = libxl_defbool_val(b_info->u.hvm.altp2m);
+    }
 
     return 0;
 }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Mon May 12 23:57:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 12 May 2025 23:57:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982277.1368819 (Exim 4.92)
	(envelope-from )
	id 1uEd1x-00034f-Kr; Mon, 12 May 2025 23:57:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982277.1368819; Mon, 12 May 2025 23:57: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 1uEd1x-00034Y-Hh; Mon, 12 May 2025 23:57:57 +0000
Received: by outflank-mailman (input) for mailman id 982277;
 Mon, 12 May 2025 23:57:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEd1v-00034R-Ed
 for xen-devel@lists.xenproject.org; Mon, 12 May 2025 23:57:55 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2418::61f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eacaa7d8-2f8c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 01:57:54 +0200 (CEST)
Received: from CY8PR12CA0046.namprd12.prod.outlook.com (2603:10b6:930:49::24)
 by LV8PR12MB9271.namprd12.prod.outlook.com (2603:10b6:408:1ff::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.28; Mon, 12 May
 2025 23:57:49 +0000
Received: from CY4PEPF0000E9D2.namprd03.prod.outlook.com
 (2603:10b6:930:49:cafe::e3) by CY8PR12CA0046.outlook.office365.com
 (2603:10b6:930:49::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.30 via Frontend Transport; Mon,
 12 May 2025 23:57:49 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000E9D2.mail.protection.outlook.com (10.167.241.137) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Mon, 12 May 2025 23:57:48 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 12 May
 2025 18:57:48 -0500
Received: from [192.168.94.239] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 12 May 2025 18:57: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" 
X-Inumbo-ID: eacaa7d8-2f8c-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lKJUvM90koNw7v4EMaW8HO4dhUV5E2mBD4qocIihCXMFmy/Ch+NogX0Jw+krYKksmMKOyYKLSkCEjUHqxLaUZEwY81FoMqnSeJOfBcFQNmlcCwodGrUbblFC6jx2Qi1JfXYM8gF3b3ExyvAQgXeDeGTfEgY5ouvZ32+nEpIeLRPfVbgCJd8BOAMdja835GD1WWSqrq30wG86CWTKSWJd4DYroPGh8FnpOx8wCaxUUUS25aw9pBjkJYseM4wSDMplksLs04UJ1RjBFmuRFCHH11qgfh7apCKj4bjV/MXxk+wrtc9i8hlUqKSkfDAvydr7CQJFF+piAjMCW7u1USQd8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=J0uKKYff5mSu6UzZWbs2UCsZ+x5hy9BC7W7cMRNo6WE=;
 b=u3GvXJFQp87bIdUWwePuWLi+taJUTw4iXf43hkI1IakJBhyQPF0lRaW207vLcP68l9aVPjx433DFLVFdpoHH9bYQxnAXiSgM5RyBQcy2ubR6GWTPW47z1PnaA5E0pa4uPDZxTi2xXIsR4AAIWCn0WRpx869djxXMmKy0SrgZuVLj0h1CSOgoftXJnTUypkKFte8ybJuDHfuUTLqiE/JR8ljY6esHQuLCW43haFBz5ffIkMkkF4nXSUvgwGRHrspDWGWBqo9j/6oa7VQJMdbARASanpNl8sgXDl9W14pW7XonHa8szRl0kzr7EHU02KHcQ8sAQjoOE3dmNXRxiDuDCA==
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=J0uKKYff5mSu6UzZWbs2UCsZ+x5hy9BC7W7cMRNo6WE=;
 b=JQ6RvTO39w5rA1JJi9sHEInfDu8TTRjaHavMsjuFCveyjKb5IaNhMnIZBteDkAXKNERTXANlXN78xIJAnxntwx3oItGn0V9ndaFmPIao5Iw0kUysU4d2wwAFMGCr1JKoVCviv8Oefmqselwq66LzmdZko/PgBDGLOPd/TIiAXdM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Mon, 12 May 2025 19:57:42 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools/libxl: Only read legacy altp2m on HVM
To: 
CC: Anthony PERARD , Juergen Gross
	
References: <20250512235409.18545-1-jason.andryuk@amd.com>
 <20250512235409.18545-2-jason.andryuk@amd.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250512235409.18545-2-jason.andryuk@amd.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D2:EE_|LV8PR12MB9271:EE_
X-MS-Office365-Filtering-Correlation-Id: 84f1c6fb-4055-4528-da22-08dd91b0cc8e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RTVxZ21YZjdZWFI4K3pFTHNvbElZVDNESHZFbjQ2ZFJXSC9od0ZlY2p1VTdS?=
 =?utf-8?B?MURBU0UzbW9ueER4VlZtdlZ2U2VkYUk5M1h4T2JrdDUvVXNVUWdKelBrL01V?=
 =?utf-8?B?TEttZWJ6bDlUaHlkUzVkeTlkNkJKb1FXd1RyQzVtSGk2TWtLWlVXbXN6U1V6?=
 =?utf-8?B?REZPNVdrSGlQMlB6TFlLNndxMUV1TVZJQyt3MXNFMGdUdDZDekYyN0wzeExK?=
 =?utf-8?B?S295VUxoazd4Z21QTzczaXppc1ZsanRSSzBHL1NvUkFOQ0tMcnk0NlFUZTFa?=
 =?utf-8?B?d0FhWnBvYml6LzduQjJFeXZwQ2xhOWhPeDZvVHF0VHNGaU9xdFlpSUdCVUFo?=
 =?utf-8?B?MTRRLzhwaFkzTURXMUs3b1cxUlc5OXhPMXdXb0lDOTNSb2N6cjZLN0ZJNHll?=
 =?utf-8?B?K2RGc3lRR3NVS1Y1VUxzNi9qUTcydU1PWkNybitveUk2KzBmMUtmNmZTQVBR?=
 =?utf-8?B?eC9vaGRCTUE5NXRkd21HcEdhb25FckNOSUtwRHZ2NmRpSS9HSjBiVDdMNVZN?=
 =?utf-8?B?anUyYlVoeGNnQkJ2bTJTVFJkbEVuYXgwaGVKd2l5d0lkMXFFT3k0dUZCckJr?=
 =?utf-8?B?NnpvaSt4TEs2VGZTd293bHZIbU9nYk40TTRkOHZRUENuUEwwMXFBZVgzN1k0?=
 =?utf-8?B?UWRaZjhxbW1GdVlmbnZ1MjIvY2hYRTdEYzIxV1BuVktqaUY0MmtabDkrMU9H?=
 =?utf-8?B?czdQSHBPbEo5Nk5yanF1TkdCeG1ZbC9zNU80SjBQMGJaNHdSd0h4aHBldnAx?=
 =?utf-8?B?ODQyWmZRZzhTNk02MUxvSmlYY2JicHNpMTVYK01udW5LSnZvNWhyVDdjNUhr?=
 =?utf-8?B?N1dBbWd1RFFweXphZFI4dHNoRlFBWERGVTNVVHl2Z3JyNEpMR2Yvcm45TlBn?=
 =?utf-8?B?MHpvaFFyUXpCTy90ME52OWcxeWlGUGhYU0xMbFlJbEV0ZG41MXNUaEdjbktG?=
 =?utf-8?B?UGJxTGowdUsrTC8vQmFFeFFpLzY4L2hxdm9ucUpmRVFTdFpINHNYd3d0UHhm?=
 =?utf-8?B?ZWQvMktPS2dJTkhXM2h1anVxYzR0dGhMN1o4WC9KMmZ3ZTRZRk5DcWxlazJ4?=
 =?utf-8?B?TzJrMjMyNi9uakM1NTYxV3VCcytCRmNvRWhOMFNKKzlTQ2ljL1V0WWQvbUJ3?=
 =?utf-8?B?V3k0WmVVdEVrRExmS3JMcjA4czRsTmVRT2ZVcEhhQTlSSnpYbVFtQlBWdWJF?=
 =?utf-8?B?bzRuWWhqMzNNQ0tPWm5YK1NPVkhrYmhjMFJkSFFDSlRTK3VPdDBHeWpJM2Jj?=
 =?utf-8?B?QS9ZZHZxMkt0TjFnbHkvM1pDelpzQzRjRHhJM2V1L2JwV2N2VGF5dEI2Z0k1?=
 =?utf-8?B?eEFoZm9seDRuWnBjM0pBZnBOYlJBTzlHbHlBRGVqWWVlUzlsVmErSXdHM3Z2?=
 =?utf-8?B?cGZEOFdybmtUTlA1UUNrWGppOTZNVzhBN3RQOGVZY1JHRkZoeitMY1V3aFdU?=
 =?utf-8?B?OG9LbnpPWklIS1NUZHkwR1dkVzdqNkhzdWQ5aUdJNytoUnR2bVpURmJ4R29P?=
 =?utf-8?B?SGNEbGJuMG40cWJQR2xJZTNiTHJwOS85Ump6MWJWa1dLT2IxWkFZUWFpUEph?=
 =?utf-8?B?UmtNKzAralYxNkI2bi9iT2RBQmU2VDc2U0xXcm4yUEJYVHhucEtRRnhGWTQ1?=
 =?utf-8?B?bjZwYWZXUnlvdDNDWXcwaDIvdElBN2FLaEFaN3N3S0MvTmhYMDlJMUpiQUNU?=
 =?utf-8?B?VjFvWFUxZk8xMGV0aUlVWk9RZjQwRG9xYkZQL1NYK3R2cGYrMkVMQ0RXWmRi?=
 =?utf-8?B?SU5Pbkl3NTRZeGQ2VmJzZGtLU1gzREp4azVkRnNJbkk4bjcxOWxucnVnU2Ey?=
 =?utf-8?B?MnNDT2o5NExiNHpGQlQwSEJQaFZCeGxZQ2g5TzFsQjR4OHdLdEVRbjZoNVUw?=
 =?utf-8?B?ZVVWNVVTZ1FieFgxb2w0ZENzS0N1SUtpQTZpeTl0TmpuenExaTBXZmIzYkhj?=
 =?utf-8?B?UUZab05LRlZ2c0RBc29vQjd6MW9SaXkxRUV3Zllsa0tJWFh4ZURQczBOeU92?=
 =?utf-8?B?cDdKUkxoRElFcHZhR0JjWmtZTUd5U0FrQmN6bzRTV2Q0bkFBQkRNWkhHNSs0?=
 =?utf-8?Q?SIFpIh?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2025 23:57:48.7656
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 84f1c6fb-4055-4528-da22-08dd91b0cc8e
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D2.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9271

On 2025-05-12 19:54, Jason Andryuk wrote:
> Only read the HVM union b_info->u.hvm on HVM guests.  The union
> access is not guarded, so this reads even on non-HVM guests.  Usually
> this doesn't matter as PV and PVH unions are smaller and
> zero-initialized.  But it could incorrectly set b_info->altp2m through
> aliased data.

Oops.  I re-phrased the commit message, but I accidentally had an old 
version in the directory.  Sorry about that.  Please disregard this one 
and review "tools/libxl: Only access legacy altp2m on HVM".

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Tue May 13 05:29:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 05:29:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982483.1368838 (Exim 4.92)
	(envelope-from )
	id 1uEiCO-0003Va-Tp; Tue, 13 May 2025 05:29:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982483.1368838; Tue, 13 May 2025 05:29:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEiCO-0003VT-Qj; Tue, 13 May 2025 05:29:04 +0000
Received: by outflank-mailman (input) for mailman id 982483;
 Tue, 13 May 2025 05:29:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEiCN-0003NS-02
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 05:29:03 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2bf58ebe-2fbb-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 07:28:59 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2bf58ebe-2fbb-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747114137; x=1747373337;
	bh=bf36XoFZ8pHmwDNnfTbiLOydmIWMr92nck/XVDPHPgc=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=RTdM19kFYdu39rtmWmCXqC+0nlr2OsVpZkH21KOdSmNUoSZBgMMIZOQSclBrR7vPm
	 nL/kKmbw0KLNaYC5RCHDzCXus7onFU+RfQw8oxoaxQcdkOAYpDCNQDfeqIEy1fb5Wt
	 4dQ4CtJVm8TEwF67VNv5Zk1W9xUMt9rs4bvvnAMwkV6ruTgXlPECqqEAEyD72My05P
	 hxkLEFE1hunnbXmBEzQEcUEKWadYfkzZmvnerNZqQcxYnFFQukYcKBZg5+sZzluCKE
	 US1Qr7ORtHxq3R+/2D5EDS1Ep/2LGpuMjwUbgAB0OZBQXfxoNv1dTSgehDTiAP14AB
	 ucyvq2wMhMx8Q==
Date: Tue, 13 May 2025 05:28:53 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, roger.pau@citrix.com, nicola.vetrini@bugseng.com, consulting@bugseng.com, dmukhin@ford.com
Subject: [PATCH v5 1/2] x86/vmx: replace __vmread() with vmread()
Message-ID: <20250513052809.3947164-2-dmukhin@ford.com>
In-Reply-To: <20250513052809.3947164-1-dmukhin@ford.com>
References: <20250513052809.3947164-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: a8fc4d77a667e971c48657b5b9063da0ea5c4a26
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Use vmread() instead of __vmread() everywhere in the VT-x code.

Suggested-by: Andrew Cooper 
Signed-off-by: Denis Mukhin 
---
 xen/arch/x86/cpu/vpmu_intel.c   |   2 +-
 xen/arch/x86/hvm/vmx/intr.c     |  12 +--
 xen/arch/x86/hvm/vmx/realmode.c |   2 +-
 xen/arch/x86/hvm/vmx/vmcs.c     |   8 +-
 xen/arch/x86/hvm/vmx/vmx.c      | 170 ++++++++++++++++----------------
 xen/arch/x86/hvm/vmx/vvmx.c     |  36 +++----
 6 files changed, 115 insertions(+), 115 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index 7ce98ee42e..e358342ac9 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -796,7 +796,7 @@ static int cf_check core2_vpmu_do_interrupt(void)
     else
     {
         /* No PMC overflow but perhaps a Trace Message interrupt. */
-        __vmread(GUEST_IA32_DEBUGCTL, &msr_content);
+        msr_content =3D vmread(GUEST_IA32_DEBUGCTL);
         if ( !(msr_content & IA32_DEBUGCTLMSR_TR) )
             return 0;
     }
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index 91b407e6bc..b622ae1e60 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -65,7 +65,7 @@ static void vmx_enable_intr_window(struct vcpu *v, struct=
 hvm_intack intack)
     {
         unsigned long intr;
=20
-        __vmread(VM_ENTRY_INTR_INFO, &intr);
+        intr =3D vmread(VM_ENTRY_INTR_INFO);
         TRACE(TRC_HVM_INTR_WINDOW, intack.vector, intack.source,
               (intr & INTR_INFO_VALID_MASK) ? intr & 0xff : -1);
     }
@@ -83,7 +83,7 @@ static void vmx_enable_intr_window(struct vcpu *v, struct=
 hvm_intack intack)
          */
         unsigned long intr_shadow;
=20
-        __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow);
+        intr_shadow =3D vmread(GUEST_INTERRUPTIBILITY_INFO);
         if ( intr_shadow & VMX_INTR_SHADOW_STI )
         {
             /* Having both STI-blocking and MOV-SS-blocking fails vmentry.=
 */
@@ -148,7 +148,7 @@ enum hvm_intblk cf_check nvmx_intr_blocked(struct vcpu =
*v)
         {
             unsigned long intr_info;
=20
-            __vmread(VM_ENTRY_INTR_INFO, &intr_info);
+            intr_info =3D vmread(VM_ENTRY_INTR_INFO);
             if ( intr_info & INTR_INFO_VALID_MASK )
                 r =3D hvm_intblk_rflags_ie;
         }
@@ -275,7 +275,7 @@ void asmlinkage vmx_intr_assist(void)
                 goto out;
             }
=20
-            __vmread(VM_ENTRY_INTR_INFO, &intr_info);
+            intr_info =3D vmread(VM_ENTRY_INTR_INFO);
             if ( intr_info & INTR_INFO_VALID_MASK )
             {
                 if ( (intack.source =3D=3D hvm_intsrc_pic) ||
@@ -299,7 +299,7 @@ void asmlinkage vmx_intr_assist(void)
         }
         else
         {
-            __vmread(VM_ENTRY_INTR_INFO, &intr_info);
+            intr_info =3D vmread(VM_ENTRY_INTR_INFO);
             if ( intr_info & INTR_INFO_VALID_MASK )
             {
                 vmx_enable_intr_window(v, intack);
@@ -377,7 +377,7 @@ void asmlinkage vmx_intr_assist(void)
         }
=20
         /* we need update the RVI field */
-        __vmread(GUEST_INTR_STATUS, &status);
+        status =3D vmread(GUEST_INTR_STATUS);
         status &=3D ~VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK;
         status |=3D VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK &
                     intack.vector;
diff --git a/xen/arch/x86/hvm/vmx/realmode.c b/xen/arch/x86/hvm/vmx/realmod=
e.c
index ff44ddcfa6..40cbc273d0 100644
--- a/xen/arch/x86/hvm/vmx/realmode.c
+++ b/xen/arch/x86/hvm/vmx/realmode.c
@@ -159,7 +159,7 @@ void vmx_realmode(struct cpu_user_regs *regs)
     unsigned int emulations =3D 0;
=20
     /* Get-and-clear VM_ENTRY_INTR_INFO. */
-    __vmread(VM_ENTRY_INTR_INFO, &intr_info);
+    intr_info =3D vmread(VM_ENTRY_INTR_INFO);
     if ( intr_info & INTR_INFO_VALID_MASK )
         __vmwrite(VM_ENTRY_INTR_INFO, 0);
=20
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index a44475ae15..f6267f65dd 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1031,7 +1031,7 @@ u64 virtual_vmcs_vmread(const struct vcpu *v, u32 vmc=
s_encoding)
     u64 res;
=20
     virtual_vmcs_enter(v);
-    __vmread(vmcs_encoding, &res);
+    res =3D vmread(vmcs_encoding);
     virtual_vmcs_exit(v);
=20
     return res;
@@ -1691,7 +1691,7 @@ void vmx_vcpu_flush_pml_buffer(struct vcpu *v)
=20
     vmx_vmcs_enter(v);
=20
-    __vmread(GUEST_PML_INDEX, &pml_idx);
+    pml_idx =3D vmread(GUEST_PML_INDEX);
=20
     /* Do nothing if PML buffer is empty. */
     if ( pml_idx =3D=3D (NR_PML_ENTRIES - 1) )
@@ -1876,7 +1876,7 @@ void vmx_vmentry_failure(void)
     struct vcpu *curr =3D current;
     unsigned long error;
=20
-    __vmread(VM_INSTRUCTION_ERROR, &error);
+    error =3D vmread(VM_INSTRUCTION_ERROR);
     gprintk(XENLOG_ERR, "VM%s error: %#lx\n",
             curr->arch.hvm.vmx.launched ? "RESUME" : "LAUNCH", error);
=20
@@ -1957,7 +1957,7 @@ void cf_check vmx_do_resume(void)
     hvm_do_resume(v);
=20
     /* Sync host CR4 in case its value has changed. */
-    __vmread(HOST_CR4, &host_cr4);
+    host_cr4 =3D vmread(HOST_CR4);
     if ( host_cr4 !=3D read_cr4() )
         __vmwrite(HOST_CR4, read_cr4());
=20
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 827db6bdd8..203ca83c16 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -902,7 +902,7 @@ int cf_check vmx_guest_x86_mode(struct vcpu *v)
         return X86_MODE_REAL;
     if ( unlikely(guest_cpu_user_regs()->eflags & X86_EFLAGS_VM) )
         return X86_MODE_VM86;
-    __vmread(GUEST_CS_AR_BYTES, &cs_ar_bytes);
+    cs_ar_bytes =3D vmread(GUEST_CS_AR_BYTES);
     if ( hvm_long_mode_active(v) &&
          likely(cs_ar_bytes & X86_SEG_AR_CS_LM_ACTIVE) )
         return X86_MODE_64BIT;
@@ -952,7 +952,7 @@ static void __restore_debug_registers(struct vcpu *v)
  */
 static void vmx_restore_dr(struct vcpu *v)
 {
-    /* NB. __vmread() is not usable here, so we cannot read from the VMCS.=
 */
+    /* NB. vmread() is not usable here, so we cannot read from the VMCS. *=
/
     if ( unlikely(v->arch.dr7 & DR7_ACTIVE_MASK) )
         __restore_debug_registers(v);
 }
@@ -963,17 +963,17 @@ static void vmx_vmcs_save(struct vcpu *v, struct hvm_=
hw_cpu *c)
=20
     vmx_vmcs_enter(v);
=20
-    __vmread(GUEST_SYSENTER_CS, &c->sysenter_cs);
-    __vmread(GUEST_SYSENTER_ESP, &c->sysenter_esp);
-    __vmread(GUEST_SYSENTER_EIP, &c->sysenter_eip);
+    c->sysenter_cs =3D vmread(GUEST_SYSENTER_CS);
+    c->sysenter_esp =3D vmread(GUEST_SYSENTER_ESP);
+    c->sysenter_eip =3D vmread(GUEST_SYSENTER_EIP);
=20
-    __vmread(VM_ENTRY_INTR_INFO, &ev);
+    ev =3D vmread(VM_ENTRY_INTR_INFO);
     if ( (ev & INTR_INFO_VALID_MASK) &&
          hvm_event_needs_reinjection(MASK_EXTR(ev, INTR_INFO_INTR_TYPE_MAS=
K),
                                      ev & INTR_INFO_VECTOR_MASK) )
     {
         c->pending_event =3D ev;
-        __vmread(VM_ENTRY_EXCEPTION_ERROR_CODE, &ev);
+        ev =3D vmread(VM_ENTRY_EXCEPTION_ERROR_CODE);
         c->error_code =3D ev;
     }
=20
@@ -1199,7 +1199,7 @@ unsigned int vmx_get_cpl(void)
 {
     unsigned long attr;
=20
-    __vmread(GUEST_SS_AR_BYTES, &attr);
+    attr =3D vmread(GUEST_SS_AR_BYTES);
=20
     return MASK_EXTR(attr, X86_SEG_AR_DPL);
 }
@@ -1271,14 +1271,14 @@ static void cf_check vmx_get_segment_register(
         fallthrough;
=20
     case x86_seg_es ... x86_seg_gs:
-        __vmread(GUEST_SEG_SELECTOR(tmp_seg), &sel);
-        __vmread(GUEST_SEG_AR_BYTES(tmp_seg), &attr);
+        sel =3D vmread(GUEST_SEG_SELECTOR(tmp_seg));
+        attr =3D vmread(GUEST_SEG_AR_BYTES(tmp_seg));
         fallthrough;
=20
     case x86_seg_gdtr:
     case x86_seg_idtr:
-        __vmread(GUEST_SEG_LIMIT(tmp_seg),    &limit);
-        __vmread(GUEST_SEG_BASE(tmp_seg),     ®->base);
+        limit =3D vmread(GUEST_SEG_LIMIT(tmp_seg));
+        reg->base =3D vmread(GUEST_SEG_BASE(tmp_seg));
         break;
=20
     default:
@@ -1436,7 +1436,7 @@ static int cf_check vmx_get_guest_pat(struct vcpu *v,=
 u64 *gpat)
         return 0;
=20
     vmx_vmcs_enter(v);
-    __vmread(GUEST_PAT, gpat);
+    *gpat =3D vmread(GUEST_PAT);
     vmx_vmcs_exit(v);
     return 1;
 }
@@ -1557,7 +1557,7 @@ static unsigned int cf_check vmx_get_interrupt_shadow=
(struct vcpu *v)
 {
     unsigned long intr_shadow;
=20
-    __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow);
+    intr_shadow =3D vmread(GUEST_INTERRUPTIBILITY_INFO);
=20
     return intr_shadow;
 }
@@ -1573,12 +1573,12 @@ static void cf_check vmx_get_nonreg_state(struct vc=
pu *v,
 {
     vmx_vmcs_enter(v);
=20
-    __vmread(GUEST_ACTIVITY_STATE, &nrs->vmx.activity_state);
-    __vmread(GUEST_INTERRUPTIBILITY_INFO, &nrs->vmx.interruptibility_info)=
;
-    __vmread(GUEST_PENDING_DBG_EXCEPTIONS, &nrs->vmx.pending_dbg);
+    nrs->vmx.activity_state =3D vmread(GUEST_ACTIVITY_STATE);
+    nrs->vmx.interruptibility_info =3D vmread(GUEST_INTERRUPTIBILITY_INFO)=
;
+    nrs->vmx.pending_dbg =3D vmread(GUEST_PENDING_DBG_EXCEPTIONS);
=20
     if ( cpu_has_vmx_virtual_intr_delivery )
-        __vmread(GUEST_INTR_STATUS, &nrs->vmx.interrupt_status);
+        nrs->vmx.interrupt_status =3D vmread(GUEST_INTR_STATUS);
=20
     vmx_vmcs_exit(v);
 }
@@ -1896,7 +1896,7 @@ static void cf_check vmx_update_guest_efer(struct vcp=
u *v)
      * The intended guest running mode is derived from VM_ENTRY_IA32E_MODE=
,
      * which (architecturally) is the guest's LMA setting.
      */
-    __vmread(VM_ENTRY_CONTROLS, &entry_ctls);
+    entry_ctls =3D vmread(VM_ENTRY_CONTROLS);
=20
     entry_ctls &=3D ~VM_ENTRY_IA32E_MODE;
     if ( guest_efer & EFER_LMA )
@@ -2063,9 +2063,9 @@ static void cf_check vmx_inject_event(const struct x8=
6_event *event)
         {
             unsigned long val;
=20
-            __vmread(GUEST_DR7, &val);
+            val =3D vmread(GUEST_DR7);
             __vmwrite(GUEST_DR7, val & ~DR_GENERAL_DETECT);
-            __vmread(GUEST_IA32_DEBUGCTL, &val);
+            val =3D vmread(GUEST_IA32_DEBUGCTL);
             __vmwrite(GUEST_IA32_DEBUGCTL, val & ~IA32_DEBUGCTLMSR_LBR);
         }
         if ( cpu_has_monitor_trap_flag )
@@ -2089,7 +2089,7 @@ static void cf_check vmx_inject_event(const struct x8=
6_event *event)
     if ( nestedhvm_vcpu_in_guestmode(curr) )
         intr_info =3D vcpu_2_nvmx(curr).intr.intr_info;
     else
-        __vmread(VM_ENTRY_INTR_INFO, &intr_info);
+        intr_info =3D vmread(VM_ENTRY_INTR_INFO);
=20
     if ( unlikely(intr_info & INTR_INFO_VALID_MASK) &&
          (MASK_EXTR(intr_info, INTR_INFO_INTR_TYPE_MASK) =3D=3D X86_ET_HW_=
EXC) )
@@ -2128,7 +2128,7 @@ static bool cf_check vmx_event_pending(const struct v=
cpu *v)
     unsigned long intr_info;
=20
     ASSERT(v =3D=3D current);
-    __vmread(VM_ENTRY_INTR_INFO, &intr_info);
+    intr_info =3D vmread(VM_ENTRY_INTR_INFO);
=20
     return intr_info & INTR_INFO_VALID_MASK;
 }
@@ -2149,7 +2149,7 @@ static void cf_check vmx_set_info_guest(struct vcpu *=
v)
      * to set the GUEST_PENDING_DBG_EXCEPTIONS.BS here incurs
      * immediately vmexit and hence make no progress.
      */
-    __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow);
+    intr_shadow =3D vmread(GUEST_INTERRUPTIBILITY_INFO);
     if ( v->domain->debugger_attached &&
          (v->arch.user_regs.eflags & X86_EFLAGS_TF) &&
          (intr_shadow & VMX_INTR_SHADOW_STI) )
@@ -2178,7 +2178,7 @@ static u8 set_svi(int isr)
     if ( isr < 0 )
         isr =3D 0;
=20
-    __vmread(GUEST_INTR_STATUS, &status);
+    status =3D vmread(GUEST_INTR_STATUS);
     old =3D status >> VMX_GUEST_INTR_STATUS_SVI_OFFSET;
     if ( isr !=3D old )
     {
@@ -2518,9 +2518,9 @@ static bool cf_check vmx_vcpu_emulate_ve(struct vcpu =
*v)
     veinfo->eptp_index =3D vcpu_altp2m(v).p2midx;
=20
     vmx_vmcs_enter(v);
-    __vmread(EXIT_QUALIFICATION, &veinfo->exit_qualification);
-    __vmread(GUEST_LINEAR_ADDRESS, &veinfo->gla);
-    __vmread(GUEST_PHYSICAL_ADDRESS, &veinfo->gpa);
+    veinfo->exit_qualification =3D vmread(EXIT_QUALIFICATION);
+    veinfo->gla =3D vmread(GUEST_LINEAR_ADDRESS);
+    veinfo->gpa =3D vmread(GUEST_PHYSICAL_ADDRESS);
     vmx_vmcs_exit(v);
=20
     hvm_inject_hw_exception(X86_EXC_VE,
@@ -2541,8 +2541,8 @@ static bool cf_check vmx_get_pending_event(
     unsigned long intr_info, error_code;
=20
     vmx_vmcs_enter(v);
-    __vmread(VM_ENTRY_INTR_INFO, &intr_info);
-    __vmread(VM_ENTRY_EXCEPTION_ERROR_CODE, &error_code);
+    intr_info =3D vmread(VM_ENTRY_INTR_INFO);
+    error_code =3D vmread(VM_ENTRY_EXCEPTION_ERROR_CODE);
     vmx_vmcs_exit(v);
=20
     if ( !(intr_info & INTR_INFO_VALID_MASK) )
@@ -2739,11 +2739,11 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v=
, unsigned int reg)
     {
     case MSR_SPEC_CTRL:
         ASSERT(cpu_has_vmx_virt_spec_ctrl);
-        __vmread(SPEC_CTRL_SHADOW, &val);
+        val =3D vmread(SPEC_CTRL_SHADOW);
         break;
=20
     case MSR_IA32_BNDCFGS:
-        __vmread(GUEST_BNDCFGS, &val);
+        val =3D vmread(GUEST_BNDCFGS);
         break;
=20
     default:
@@ -3163,7 +3163,8 @@ static int get_instruction_length(void)
 {
     unsigned long len;
=20
-    __vmread(VM_EXIT_INSTRUCTION_LEN, &len); /* Safe: callers audited */
+    /* Safe: callers audited */
+    len =3D vmread(VM_EXIT_INSTRUCTION_LEN);
     BUG_ON((len < 1) || (len > MAX_INST_LEN));
     return len;
 }
@@ -3176,7 +3177,7 @@ void update_guest_eip(void)
     regs->rip +=3D get_instruction_length(); /* Safe: callers audited */
     regs->eflags &=3D ~X86_EFLAGS_RF;
=20
-    __vmread(GUEST_INTERRUPTIBILITY_INFO, &x);
+    x =3D vmread(GUEST_INTERRUPTIBILITY_INFO);
     if ( x & (VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS) )
     {
         x &=3D ~(VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS);
@@ -3424,21 +3425,21 @@ static int cf_check vmx_msr_read_intercept(
     switch ( msr )
     {
     case MSR_IA32_SYSENTER_CS:
-        __vmread(GUEST_SYSENTER_CS, msr_content);
+        *msr_content =3D vmread(GUEST_SYSENTER_CS);
         break;
     case MSR_IA32_SYSENTER_ESP:
-        __vmread(GUEST_SYSENTER_ESP, msr_content);
+        *msr_content =3D vmread(GUEST_SYSENTER_ESP);
         break;
     case MSR_IA32_SYSENTER_EIP:
-        __vmread(GUEST_SYSENTER_EIP, msr_content);
+        *msr_content =3D vmread(GUEST_SYSENTER_EIP);
         break;
=20
     case MSR_FS_BASE:
-        __vmread(GUEST_FS_BASE, msr_content);
+        *msr_content =3D vmread(GUEST_FS_BASE);
         break;
=20
     case MSR_GS_BASE:
-        __vmread(GUEST_GS_BASE, msr_content);
+        *msr_content =3D vmread(GUEST_GS_BASE);
         break;
=20
     case MSR_SHADOW_GS_BASE:
@@ -3462,7 +3463,7 @@ static int cf_check vmx_msr_read_intercept(
         break;
=20
     case MSR_IA32_DEBUGCTLMSR:
-        __vmread(GUEST_IA32_DEBUGCTL, msr_content);
+        *msr_content =3D vmread(GUEST_IA32_DEBUGCTL);
         break;
=20
     case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_VMFUNC:
@@ -3828,7 +3829,7 @@ static void vmx_do_extint(struct cpu_user_regs *regs)
 {
     unsigned long vector;
=20
-    __vmread(VM_EXIT_INTR_INFO, &vector);
+    vector =3D vmread(VM_EXIT_INTR_INFO);
     BUG_ON(!(vector & INTR_INFO_VALID_MASK));
=20
     vector &=3D INTR_INFO_VECTOR_MASK;
@@ -3893,7 +3894,7 @@ static void ept_handle_violation(ept_qual_t q, paddr_=
t gpa)
=20
     if ( q.gla_valid )
     {
-        __vmread(GUEST_LINEAR_ADDRESS, &gla);
+        gla =3D vmread(GUEST_LINEAR_ADDRESS);
         npfec.gla_valid =3D 1;
         if( q.gla_fault )
             npfec.kind =3D npfec_kind_with_gla;
@@ -3944,7 +3945,7 @@ static void vmx_failed_vmentry(unsigned int exit_reas=
on,
     struct vcpu *curr =3D current;
=20
     printk("%pv vmentry failure (reason %#x): ", curr, exit_reason);
-    __vmread(EXIT_QUALIFICATION, &exit_qualification);
+    exit_qualification =3D vmread(EXIT_QUALIFICATION);
     switch ( failed_vmentry_reason )
     {
     case EXIT_REASON_INVALID_GUEST_STATE:
@@ -4007,7 +4008,7 @@ static int vmx_handle_eoi_write(void)
      * 1. Must be a linear access data write.
      * 2. Data write must be to the EOI register.
      */
-    __vmread(EXIT_QUALIFICATION, &exit_qualification);
+    exit_qualification =3D vmread(EXIT_QUALIFICATION);
     if ( (((exit_qualification >> 12) & 0xf) =3D=3D 1) &&
          ((exit_qualification & 0xfff) =3D=3D APIC_EOI) )
     {
@@ -4037,7 +4038,7 @@ static void vmx_propagate_intr(unsigned long intr)
=20
     if ( intr & INTR_INFO_DELIVER_CODE_MASK )
     {
-        __vmread(VM_EXIT_INTR_ERROR_CODE, &tmp);
+        tmp =3D vmread(VM_EXIT_INTR_ERROR_CODE);
         event.error_code =3D tmp;
     }
     else
@@ -4045,7 +4046,7 @@ static void vmx_propagate_intr(unsigned long intr)
=20
     if ( event.type >=3D X86_ET_SW_INT )
     {
-        __vmread(VM_EXIT_INSTRUCTION_LEN, &tmp);
+        tmp =3D vmread(VM_EXIT_INSTRUCTION_LEN);
         event.insn_len =3D tmp;
     }
     else
@@ -4071,7 +4072,7 @@ static void vmx_idtv_reinject(unsigned long idtv_info=
)
             {
                 unsigned long ec;
=20
-                __vmread(IDT_VECTORING_ERROR_CODE, &ec);
+                ec =3D vmread(IDT_VECTORING_ERROR_CODE);
                 __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, ec);
             }
         }
@@ -4086,7 +4087,7 @@ static void vmx_idtv_reinject(unsigned long idtv_info=
)
         {
             unsigned long intr_info;
=20
-            __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_info);
+            intr_info =3D vmread(GUEST_INTERRUPTIBILITY_INFO);
             __vmwrite(GUEST_INTERRUPTIBILITY_INFO,
                       intr_info & ~VMX_INTR_SHADOW_NMI);
         }
@@ -4111,8 +4112,8 @@ static void vmx_handle_descriptor_access(uint32_t exi=
t_reason)
     uint64_t exit_qualification;
     unsigned int desc;
=20
-    __vmread(EXIT_QUALIFICATION, &exit_qualification);
-    __vmread(VMX_INSTRUCTION_INFO, &instr_info);
+    exit_qualification =3D vmread(EXIT_QUALIFICATION);
+    instr_info =3D vmread(VMX_INSTRUCTION_INFO);
=20
     if ( exit_reason =3D=3D EXIT_REASON_ACCESS_GDTR_OR_IDTR )
     {
@@ -4137,7 +4138,7 @@ static int vmx_handle_apic_write(void)
     unsigned long exit_qualification;
=20
     ASSERT(cpu_has_vmx_apic_reg_virt);
-    __vmread(EXIT_QUALIFICATION, &exit_qualification);
+    exit_qualification =3D vmread(EXIT_QUALIFICATION);
=20
     return vlapic_apicv_write(current, exit_qualification & 0xfff);
 }
@@ -4146,7 +4147,7 @@ static void undo_nmis_unblocked_by_iret(void)
 {
     unsigned long guest_info;
=20
-    __vmread(GUEST_INTERRUPTIBILITY_INFO, &guest_info);
+    guest_info =3D vmread(GUEST_INTERRUPTIBILITY_INFO);
     __vmwrite(GUEST_INTERRUPTIBILITY_INFO,
               guest_info | VMX_INTR_SHADOW_NMI);
 }
@@ -4159,12 +4160,12 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_=
regs *regs)
     struct vcpu *v =3D current;
     struct domain *currd =3D v->domain;
=20
-    __vmread(GUEST_RIP,    ®s->rip);
-    __vmread(GUEST_RSP,    ®s->rsp);
-    __vmread(GUEST_RFLAGS, ®s->rflags);
+    regs->rip =3D vmread(GUEST_RIP);
+    regs->rsp =3D vmread(GUEST_RSP);
+    regs->rflags =3D vmread(GUEST_RFLAGS);
=20
     if ( hvm_long_mode_active(v) )
-        __vmread(GUEST_CS_AR_BYTES, &cs_ar_bytes);
+        cs_ar_bytes =3D vmread(GUEST_CS_AR_BYTES);
=20
     hvm_sanitize_regs_fields(regs, !(cs_ar_bytes & X86_SEG_AR_CS_LM_ACTIVE=
));
=20
@@ -4174,17 +4175,17 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_=
regs *regs)
          * Xen allows the guest to modify some CR4 bits directly, update c=
ached
          * values to match.
          */
-        __vmread(GUEST_CR4, &v->arch.hvm.hw_cr[4]);
+        v->arch.hvm.hw_cr[4] =3D vmread(GUEST_CR4);
         v->arch.hvm.guest_cr[4] &=3D v->arch.hvm.vmx.cr4_host_mask;
         v->arch.hvm.guest_cr[4] |=3D (v->arch.hvm.hw_cr[4] &
                                     ~v->arch.hvm.vmx.cr4_host_mask);
=20
-        __vmread(GUEST_CR3, &v->arch.hvm.hw_cr[3]);
+        v->arch.hvm.hw_cr[3] =3D vmread(GUEST_CR3);
         if ( vmx_unrestricted_guest(v) || hvm_paging_enabled(v) )
             v->arch.hvm.guest_cr[3] =3D v->arch.hvm.hw_cr[3];
     }
=20
-    __vmread(VM_EXIT_REASON, &exit_reason);
+    exit_reason =3D vmread(VM_EXIT_REASON);
=20
     if ( hvm_long_mode_active(v) )
         TRACE_TIME(TRC_HVM_VMX_EXIT64, exit_reason, regs->rip, regs->rip >=
> 32);
@@ -4200,7 +4201,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
         vmx_do_extint(regs);
         break;
     case EXIT_REASON_EXCEPTION_NMI:
-        __vmread(VM_EXIT_INTR_INFO, &intr_info);
+        intr_info =3D vmread(VM_EXIT_INTR_INFO);
         BUG_ON(!(intr_info & INTR_INFO_VALID_MASK));
         vector =3D intr_info & INTR_INFO_VECTOR_MASK;
         if ( vector =3D=3D X86_EXC_MC )
@@ -4237,12 +4238,12 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_=
regs *regs)
=20
         if ( v->arch.hvm.vmx.secondary_exec_control &
             SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS )
-            __vmread(EPTP_INDEX, &idx);
+            idx =3D vmread(EPTP_INDEX);
         else
         {
             unsigned long eptp;
=20
-            __vmread(EPT_POINTER, &eptp);
+            eptp =3D vmread(EPT_POINTER);
=20
             if ( (idx =3D p2m_find_altp2m_by_eptp(v->domain, eptp)) =3D=3D
                  INVALID_ALTP2M )
@@ -4261,7 +4262,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
     {
         int rc;
=20
-        __vmread(EXIT_QUALIFICATION, &exit_qualification);
+        exit_qualification =3D vmread(EXIT_QUALIFICATION);
         rc =3D hvm_monitor_vmexit(exit_reason, exit_qualification);
         if ( rc < 0 )
             goto exit_and_crash;
@@ -4327,7 +4328,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
=20
     hvm_maybe_deassert_evtchn_irq();
=20
-    __vmread(IDT_VECTORING_INFO, &idtv_info);
+    idtv_info =3D vmread(IDT_VECTORING_INFO);
     if ( exit_reason !=3D EXIT_REASON_TASK_SWITCH )
         vmx_idtv_reinject(idtv_info);
=20
@@ -4362,7 +4363,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
              * Updates DR6 where debugger can peek (See 3B 23.2.1,
              * Table 23-1, "Exit Qualification for Debug Exceptions").
              */
-            __vmread(EXIT_QUALIFICATION, &exit_qualification);
+            exit_qualification =3D vmread(EXIT_QUALIFICATION);
             TRACE(TRC_HVM_TRAP_DEBUG, exit_qualification);
             __restore_debug_registers(v);
             write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE)=
;
@@ -4390,15 +4391,14 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_=
regs *regs)
             {
                 unsigned long int_info;
=20
-                __vmread(GUEST_INTERRUPTIBILITY_INFO, &int_info);
+                int_info =3D vmread(GUEST_INTERRUPTIBILITY_INFO);
=20
                 if ( int_info & (VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV=
_SS) )
                 {
                     unsigned long pending_dbg;
=20
-                    __vmread(GUEST_PENDING_DBG_EXCEPTIONS, &pending_dbg);
-                    __vmwrite(GUEST_PENDING_DBG_EXCEPTIONS,
-                              pending_dbg | DR_STEP);
+                    pending_dbg =3D vmread(GUEST_PENDING_DBG_EXCEPTIONS);
+                    __vmwrite(GUEST_PENDING_DBG_EXCEPTIONS, pending_dbg | =
DR_STEP);
                 }
             }
=20
@@ -4410,7 +4410,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
                                                     INTR_INFO_INTR_TYPE_MA=
SK);
=20
                 if ( trap_type >=3D X86_ET_SW_INT )
-                    __vmread(VM_EXIT_INSTRUCTION_LEN, &insn_len);
+                    insn_len =3D vmread(VM_EXIT_INSTRUCTION_LEN);
=20
                 rc =3D hvm_monitor_debug(regs->rip,
                                        HVM_MONITOR_DEBUG_EXCEPTION,
@@ -4431,7 +4431,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
                 unsigned long insn_len;
                 int rc;
=20
-                __vmread(VM_EXIT_INSTRUCTION_LEN, &insn_len);
+                insn_len =3D vmread(VM_EXIT_INSTRUCTION_LEN);
                 rc =3D hvm_monitor_debug(regs->rip,
                                        HVM_MONITOR_SOFTWARE_BREAKPOINT,
                                        X86_ET_SW_EXC,
@@ -4454,8 +4454,8 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
             vmx_fpu_dirty_intercept();
             break;
         case X86_EXC_PF:
-            __vmread(EXIT_QUALIFICATION, &exit_qualification);
-            __vmread(VM_EXIT_INTR_ERROR_CODE, &ecode);
+            exit_qualification =3D vmread(EXIT_QUALIFICATION);
+            ecode =3D vmread(VM_EXIT_INTR_ERROR_CODE);
             regs->error_code =3D ecode;
=20
             HVM_DBG_LOG(DBG_LEVEL_VMMU,
@@ -4522,7 +4522,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
         };
         unsigned int inst_len, source;
=20
-        __vmread(EXIT_QUALIFICATION, &exit_qualification);
+        exit_qualification =3D vmread(EXIT_QUALIFICATION);
         source =3D (exit_qualification >> 30) & 3;
         /* Vectored event should fill in interrupt information. */
         WARN_ON((source =3D=3D 3) && !(idtv_info & INTR_INFO_VALID_MASK));
@@ -4536,7 +4536,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
                      > 3)) /* IntrType > 3? */
             ? get_instruction_length() /* Safe: SDM 3B 23.2.4 */ : 0;
         if ( (source =3D=3D 3) && (idtv_info & INTR_INFO_DELIVER_CODE_MASK=
) )
-            __vmread(IDT_VECTORING_ERROR_CODE, &ecode);
+            ecode =3D vmread(IDT_VECTORING_ERROR_CODE);
         else
              ecode =3D -1;
=20
@@ -4565,7 +4565,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
         break;
     case EXIT_REASON_INVLPG:
         update_guest_eip(); /* Safe: INVLPG */
-        __vmread(EXIT_QUALIFICATION, &exit_qualification);
+        exit_qualification =3D vmread(EXIT_QUALIFICATION);
         vmx_invlpg_intercept(exit_qualification);
         break;
     case EXIT_REASON_RDTSCP:
@@ -4591,13 +4591,13 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_=
regs *regs)
=20
     case EXIT_REASON_CR_ACCESS:
     {
-        __vmread(EXIT_QUALIFICATION, &exit_qualification);
+        exit_qualification =3D vmread(EXIT_QUALIFICATION);
         if ( vmx_cr_access(exit_qualification) =3D=3D X86EMUL_OKAY )
             update_guest_eip(); /* Safe: MOV Cn, LMSW, CLTS */
         break;
     }
     case EXIT_REASON_DR_ACCESS:
-        __vmread(EXIT_QUALIFICATION, &exit_qualification);
+        exit_qualification =3D vmread(EXIT_QUALIFICATION);
         vmx_dr_access(exit_qualification, regs);
         break;
     case EXIT_REASON_MSR_READ:
@@ -4671,7 +4671,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
         break;
=20
     case EXIT_REASON_EOI_INDUCED:
-        __vmread(EXIT_QUALIFICATION, &exit_qualification);
+        exit_qualification =3D vmread(EXIT_QUALIFICATION);
=20
         ASSERT(cpu_has_vmx_virtual_intr_delivery);
=20
@@ -4695,7 +4695,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
         unsigned int bytes;
         int rc;
=20
-        __vmread(EXIT_QUALIFICATION, &io_qual.raw);
+        io_qual.raw =3D vmread(EXIT_QUALIFICATION);
         bytes =3D io_qual.size + 1;
=20
         rc =3D hvm_monitor_io(io_qual.port, bytes, io_qual.in, io_qual.str=
);
@@ -4730,8 +4730,8 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
     {
         paddr_t gpa;
=20
-        __vmread(GUEST_PHYSICAL_ADDRESS, &gpa);
-        __vmread(EXIT_QUALIFICATION, &exit_qualification);
+        gpa =3D vmread(GUEST_PHYSICAL_ADDRESS);
+        exit_qualification =3D vmread(EXIT_QUALIFICATION);
=20
         if ( unlikely(exit_qualification & INTR_INFO_NMI_UNBLOCKED_BY_IRET=
) &&
              !(idtv_info & INTR_INFO_VALID_MASK) )
@@ -4745,7 +4745,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
     {
         paddr_t gpa;
=20
-        __vmread(GUEST_PHYSICAL_ADDRESS, &gpa);
+        gpa =3D vmread(GUEST_PHYSICAL_ADDRESS);
         if ( !ept_handle_misconfig(gpa) )
             goto exit_and_crash;
         break;
@@ -4781,7 +4781,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
         break;
=20
     case EXIT_REASON_PML_FULL:
-        __vmread(EXIT_QUALIFICATION, &exit_qualification);
+        exit_qualification =3D vmread(EXIT_QUALIFICATION);
=20
         if ( unlikely(exit_qualification & INTR_INFO_NMI_UNBLOCKED_BY_IRET=
) &&
              !(idtv_info & INTR_INFO_VALID_MASK) )
@@ -4804,7 +4804,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_re=
gs *regs)
         break;
=20
     case EXIT_REASON_NOTIFY:
-        __vmread(EXIT_QUALIFICATION, &exit_qualification);
+        exit_qualification =3D vmread(EXIT_QUALIFICATION);
=20
         if ( unlikely(exit_qualification & NOTIFY_VM_CONTEXT_INVALID) )
         {
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index ceb5e5a322..720c86aeaf 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -400,7 +400,7 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
     unsigned long base, index, seg_base, disp, offset;
     int scale, size;
=20
-    __vmread(VMX_INSTRUCTION_INFO, &offset);
+    offset =3D vmread(VMX_INSTRUCTION_INFO);
     info.word =3D offset;
=20
     if ( info.fields.memreg ) {
@@ -428,7 +428,7 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
=20
         scale =3D 1 << info.fields.scaling;
=20
-        __vmread(EXIT_QUALIFICATION, &disp);
+        disp =3D vmread(EXIT_QUALIFICATION);
=20
         size =3D 1 << (info.fields.addr_size + 1);
=20
@@ -997,7 +997,7 @@ static void vvmcs_to_shadow_bulk(struct vcpu *v, unsign=
ed int n,
=20
     virtual_vmcs_enter(v);
     for ( i =3D 0; i < n; i++ )
-        __vmread(field[i], &value[i]);
+        value[i] =3D vmread(field[i]);
     virtual_vmcs_exit(v);
=20
     for ( i =3D 0; i < n; i++ )
@@ -1036,7 +1036,7 @@ static void shadow_to_vvmcs_bulk(struct vcpu *v, unsi=
gned int n,
     }
=20
     for ( i =3D 0; i < n; i++ )
-        __vmread(field[i], &value[i]);
+        value[i] =3D vmread(field[i]);
=20
     virtual_vmcs_enter(v);
     for ( i =3D 0; i < n; i++ )
@@ -1405,7 +1405,7 @@ static void nvmx_update_apicv(struct vcpu *v)
     }
     else
        /* Keep previous SVI if there's any. */
-       __vmread(GUEST_INTR_STATUS, &status);
+       status =3D vmread(GUEST_INTR_STATUS);
=20
     rvi =3D vlapic_has_pending_irq(v);
     if ( rvi !=3D -1 )
@@ -1696,7 +1696,7 @@ static int nvmx_handle_vmresume(struct cpu_user_regs =
*regs)
         return X86EMUL_OKAY;       =20
     }
=20
-    __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow);
+    intr_shadow =3D vmread(GUEST_INTERRUPTIBILITY_INFO);
     if ( intr_shadow & VMX_INTR_SHADOW_MOV_SS )
     {
         vmfail_valid(regs, VMX_INSN_VMENTRY_BLOCKED_BY_MOV_SS);
@@ -1732,7 +1732,7 @@ static int nvmx_handle_vmlaunch(struct cpu_user_regs =
*regs)
         return X86EMUL_OKAY;
     }
=20
-    __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow);
+    intr_shadow =3D vmread(GUEST_INTERRUPTIBILITY_INFO);
     if ( intr_shadow & VMX_INTR_SHADOW_MOV_SS )
     {
         vmfail_valid(regs, VMX_INSN_VMENTRY_BLOCKED_BY_MOV_SS);
@@ -2355,7 +2355,7 @@ int cf_check nvmx_hap_walk_L1_p2m(
=20
     vmx_vmcs_enter(v);
=20
-    __vmread(EXIT_QUALIFICATION, &exit_qual);
+    exit_qual =3D vmread(EXIT_QUALIFICATION);
     rc =3D nept_translate_l2ga(v, L2_gpa, page_order, rwx_rights, &gfn, p2=
m_acc,
                              &exit_qual, &exit_reason);
     switch ( rc )
@@ -2391,7 +2391,7 @@ void nvmx_idtv_handling(void)
     struct nestedvcpu *nvcpu =3D &vcpu_nestedhvm(v);
     unsigned long idtv_info, reason;
=20
-    __vmread(IDT_VECTORING_INFO, &idtv_info);
+    idtv_info =3D vmread(IDT_VECTORING_INFO);
     if ( likely(!(idtv_info & INTR_INFO_VALID_MASK)) )
         return;
=20
@@ -2399,7 +2399,7 @@ void nvmx_idtv_handling(void)
      * If L0 can solve the fault that causes idt vectoring, it should
      * be reinjected, otherwise, pass to L1.
      */
-    __vmread(VM_EXIT_REASON, &reason);
+    reason =3D vmread(VM_EXIT_REASON);
     if ( (uint16_t)reason !=3D EXIT_REASON_EPT_VIOLATION ?
          !(nvmx->intr.intr_info & INTR_INFO_VALID_MASK) :
          !nvcpu->nv_vmexit_pending )
@@ -2407,7 +2407,7 @@ void nvmx_idtv_handling(void)
         __vmwrite(VM_ENTRY_INTR_INFO, idtv_info & ~INTR_INFO_RESVD_BITS_MA=
SK);
         if ( idtv_info & INTR_INFO_DELIVER_CODE_MASK )
         {
-            __vmread(IDT_VECTORING_ERROR_CODE, &reason);
+            reason =3D vmread(IDT_VECTORING_ERROR_CODE);
             __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, reason);
         }
         /*
@@ -2418,7 +2418,7 @@ void nvmx_idtv_handling(void)
          * This means EXIT_INSTRUCTION_LEN is always valid here, for
          * software interrupts both injected by L1, and generated in L2.
          */
-        __vmread(VM_EXIT_INSTRUCTION_LEN, &reason);
+        reason =3D vmread(VM_EXIT_INSTRUCTION_LEN);
         __vmwrite(VM_ENTRY_INSTRUCTION_LEN, reason);
    }
 }
@@ -2452,7 +2452,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs=
,
         u64 exec_bitmap;
         int vector;
=20
-        __vmread(VM_EXIT_INTR_INFO, &intr_info);
+        intr_info =3D vmread(VM_EXIT_INTR_INFO);
         vector =3D intr_info & INTR_INFO_VECTOR_MASK;
         /*
          * decided by L0 and L1 exception bitmap, if the vetor is set by
@@ -2531,7 +2531,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs=
,
             unsigned long qual;
             u16 port, size;
=20
-            __vmread(EXIT_QUALIFICATION, &qual);
+            qual =3D vmread(EXIT_QUALIFICATION);
             port =3D qual >> 16;
             size =3D (qual & 7) + 1;
             do {
@@ -2638,7 +2638,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs=
,
         cr_access_qual_t qual;
         u32 mask =3D 0;
=20
-        __vmread(EXIT_QUALIFICATION, &qual.raw);
+        qual.raw =3D vmread(EXIT_QUALIFICATION);
         /* also according to guest exec_control */
         ctrl =3D __n2_exec_control(v);
=20
@@ -2680,7 +2680,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs=
,
                 {
                     u64 cr0_gh_mask =3D get_vvmcs(v, CR0_GUEST_HOST_MASK);
=20
-                    __vmread(CR0_READ_SHADOW, &old_val);
+                    old_val =3D vmread(CR0_READ_SHADOW);
                     changed_bits =3D old_val ^ val;
                     if ( changed_bits & cr0_gh_mask )
                         nvcpu->nv_vmexit_pending =3D 1;
@@ -2696,7 +2696,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs=
,
                 {
                     u64 cr4_gh_mask =3D get_vvmcs(v, CR4_GUEST_HOST_MASK);
=20
-                    __vmread(CR4_READ_SHADOW, &old_val);
+                    old_val =3D vmread(CR4_READ_SHADOW);
                     changed_bits =3D old_val ^ val;
                     if ( changed_bits & cr4_gh_mask )
                         nvcpu->nv_vmexit_pending =3D 1;
@@ -2732,7 +2732,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs=
,
             {
                 u64 cr0_gh_mask =3D get_vvmcs(v, CR0_GUEST_HOST_MASK);
=20
-                __vmread(CR0_READ_SHADOW, &old_val);
+                old_val =3D vmread(CR0_READ_SHADOW);
                 old_val &=3D X86_CR0_PE|X86_CR0_MP|X86_CR0_EM|X86_CR0_TS;
                 val =3D qual.lmsw_data &
                       (X86_CR0_PE|X86_CR0_MP|X86_CR0_EM|X86_CR0_TS);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue May 13 05:29:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 05:29:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982482.1368829 (Exim 4.92)
	(envelope-from )
	id 1uEiCK-0003Hf-Or; Tue, 13 May 2025 05:29:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982482.1368829; Tue, 13 May 2025 05: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 1uEiCK-0003HW-K2; Tue, 13 May 2025 05:29:00 +0000
Received: by outflank-mailman (input) for mailman id 982482;
 Tue, 13 May 2025 05:29:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEiCI-0003HO-MO
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 05:29:00 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 29951e4c-2fbb-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 07:28: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" 
X-Inumbo-ID: 29951e4c-2fbb-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747114134; x=1747373334;
	bh=x6BZWh7G08S8WrxqfstLOBlPC9RhnKLrx/6y3XGUxDE=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=HDFBA2z5V36uep6cBR1uUsMy5daPgv2JSUVLJXeg6o+WfgWuJy6PQXoyFGBVp1iE4
	 L5U1QbTQhKeJ6ffg4DTQUmBPFXG9MmmAY7booaW5ngZ+Hv5VI9PkXTThrfghEDZuFV
	 0TQ0DRWIR8qOq5jo83tYuxAYbccox+u3U/cvW8TfUSJsNRBhedH6UBlsXa6y6DHoPs
	 66k015sKizxe4PZwtCwEWoV28ZWjs+SeJiGjPiLqrCtXEd/Ya7QgmT8a7oIeUosBCB
	 haDZlOlNBkT/yenL1NaDRUwzXIfcSm/RiKL53o4c+V6dv5n7sO4UWLOWhY1kd0/Hm8
	 ma8ZmC+5I8GIQ==
Date: Tue, 13 May 2025 05:28:48 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, roger.pau@citrix.com, nicola.vetrini@bugseng.com, consulting@bugseng.com, dmukhin@ford.com
Subject: [PATCH v5 0/2] x86/vmx: __vmread() cleanup
Message-ID: <20250513052809.3947164-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 64564245a46286fc62b2c46f1d123633555edf98
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Patch 1 is a straight replace of __vmread() with a new vmread() call.
Patch 2 removes __vmread() and updates ECLAIR config; depends on patch 1.

Link to v4: https://lore.kernel.org/xen-devel/20250426072819.39455-1-dmukhi=
n@ford.com/
Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1=
814196127

Denis Mukhin (2):
  x86/vmx: replace __vmread() with vmread()
  x86/vmx: remove __vmread()

 docs/misra/function-macro-properties.json |   9 --
 xen/arch/x86/cpu/vpmu_intel.c             |   2 +-
 xen/arch/x86/hvm/vmx/intr.c               |  12 +-
 xen/arch/x86/hvm/vmx/realmode.c           |   2 +-
 xen/arch/x86/hvm/vmx/vmcs.c               |   8 +-
 xen/arch/x86/hvm/vmx/vmx.c                | 170 +++++++++++-----------
 xen/arch/x86/hvm/vmx/vvmx.c               |  36 ++---
 xen/arch/x86/include/asm/hvm/vmx/vmx.h    |   5 -
 8 files changed, 115 insertions(+), 129 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue May 13 05:29:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 05:29:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982484.1368848 (Exim 4.92)
	(envelope-from )
	id 1uEiCW-0003nj-97; Tue, 13 May 2025 05:29:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982484.1368848; Tue, 13 May 2025 05: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 1uEiCW-0003na-6I; Tue, 13 May 2025 05:29:12 +0000
Received: by outflank-mailman (input) for mailman id 982484;
 Tue, 13 May 2025 05:29:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEiCU-0003NS-9W
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 05:29:10 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 32272b4c-2fbb-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 07:29: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" 
X-Inumbo-ID: 32272b4c-2fbb-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747114148; x=1747373348;
	bh=YCgDTDVez6ZCTCaxfiAeOB8ToA5/qjmuvhZmiUgLns0=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=OywzkEZuk18Dnc7U00ZyCoodlYOlJFco2JisxlPAOK+rkHNwr9GmzpybwVBsmnwlc
	 PuDJq5/UWBu7CVjmcnwVeNsqpwfiFPDPWZ1GRGGYFvtUhgC7e65Yd93fVqyNe/0YQ+
	 0lY/nbzGs1NYzc2+a+Z9kQJ1qyDBc/2DOtuEKSX/mdK8oWpn5wc43bcCL4IIGbkLpz
	 hWguR3w2TqD3d8W6x/zfRqYQrsRFwCOUy4DHxFNGpjpXwSRMtVV5BagzlpQ8CQqR3g
	 BnJvuIADVthA01Ux1NfIB4v9DkUu6k8HQCn7h7C+xMCGae/hDrb7t9/VJX645PC9j0
	 fimj1TC5j/unA==
Date: Tue, 13 May 2025 05:28:58 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, roger.pau@citrix.com, nicola.vetrini@bugseng.com, consulting@bugseng.com, dmukhin@ford.com
Subject: [PATCH v5 2/2] x86/vmx: remove __vmread()
Message-ID: <20250513052809.3947164-3-dmukhin@ford.com>
In-Reply-To: <20250513052809.3947164-1-dmukhin@ford.com>
References: <20250513052809.3947164-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: b585abc602fc0331c47ad42783e806eacff08c0f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Remove __vmread() and adjust ECLAIR configuration to account for the change=
.

Signed-off-by: Denis Mukhin 
---
 docs/misra/function-macro-properties.json | 9 ---------
 xen/arch/x86/include/asm/hvm/vmx/vmx.h    | 5 -----
 2 files changed, 14 deletions(-)

diff --git a/docs/misra/function-macro-properties.json b/docs/misra/functio=
n-macro-properties.json
index 74058297b5..59ba63626e 100644
--- a/docs/misra/function-macro-properties.json
+++ b/docs/misra/function-macro-properties.json
@@ -152,15 +152,6 @@
             "taken": ""
          }
       },
-      {
-         "type": "function",
-         "value": "^__vmread.*$",
-         "properties":{
-            "pointee_write": "2=3Dalways",
-            "pointee_read": "2=3Dnever",
-            "taken": ""
-         }
-      },
       {
          "type": "function",
          "value": "^hvm_pci_decode_addr.*$",
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/=
asm/hvm/vmx/vmx.h
index d85b52b9d5..299e2eff6b 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -336,11 +336,6 @@ static always_inline unsigned long vmread(unsigned lon=
g field)
     return value;
 }
=20
-static always_inline void __vmread(unsigned long field, unsigned long *val=
ue)
-{
-    *value =3D vmread(field);
-}
-
 static always_inline void __vmwrite(unsigned long field, unsigned long val=
ue)
 {
     asm goto ( "vmwrite %[value], %[field]\n\t"
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Tue May 13 05:56:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 05:56:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982510.1368859 (Exim 4.92)
	(envelope-from )
	id 1uEicy-00084i-Bo; Tue, 13 May 2025 05:56:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982510.1368859; Tue, 13 May 2025 05: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 1uEicy-00084b-92; Tue, 13 May 2025 05:56:32 +0000
Received: by outflank-mailman (input) for mailman id 982510;
 Tue, 13 May 2025 05:56:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEicx-00084V-EZ
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 05:56:31 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 006bed71-2fbf-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 07:56:25 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54D5trQ52161420
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Mon, 12 May 2025 22:55:54 -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" 
X-Inumbo-ID: 006bed71-2fbf-11f0-9ffb-bf95429c2676
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54D5trQ52161420
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747115755;
	bh=U6rcHZb4UW+jBgjxBhhwYGrN+qx8Tm8tX6P2roKukRQ=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=RUlxtiSSvL2zbdTxckg53o+QAfrDWf6H+yzUUXrHIYb0PPAoQ6MSHxFw6kOeUq+oG
	 KaQwRsRKDadcJVZUk4LoQ4MIDtSjEH3MpMtwbWMljIEvGit9JSB3LYtAao5NqnaxX3
	 73OkpjBHIhaCU8wAFyZtfQi/UnvDInPkne+6fTfWNJhjvGnfWd8YoEVchZUGfFJImV
	 FWYoBlTrVymscSGDsakRpQiYXvt6BwN3Ai4Frx5MvB9uLc3FZ3II0QTJImlziUnnTb
	 FZTI0Uo45mq/idyBSi8WPkEJ86WHg5azErFWd76rcZG+l/h/FwJ6OcsIrUh9XwWEp7
	 xHc1pAahRuBKA==
Message-ID: 
Date: Mon, 12 May 2025 22:55:53 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
To: Juergen Gross , linux-kernel@vger.kernel.org,
        x86@kernel.org, virtualization@lists.linux.dev
Cc: Ajay Kaher ,
        Alexey Makhalov ,
        Broadcom internal kernel review list
 ,
        Thomas Gleixner
 , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        "H. Peter Anvin" ,
        Boris Ostrovsky ,
        xen-devel@lists.xenproject.org
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
 
Content-Language: en-US
From: Xin Li 
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 5/12/2025 4:24 AM, Juergen Gross wrote:
> Now with the mentioned patch really attached. :-)
> 

Does it allow patching with an instruction more than 6 bytes long?

The immediate form MSR instructions are 9 bytes long.

Thanks!
     Xin


From xen-devel-bounces@lists.xenproject.org Tue May 13 06:06:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 06:06:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982518.1368868 (Exim 4.92)
	(envelope-from )
	id 1uEimO-0001K9-1m; Tue, 13 May 2025 06:06:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982518.1368868; Tue, 13 May 2025 06: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 1uEimN-0001K2-VX; Tue, 13 May 2025 06:06:15 +0000
Received: by outflank-mailman (input) for mailman id 982518;
 Tue, 13 May 2025 06:06:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEimM-0001Jv-LA
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 06:06:14 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ac3ee80-2fc0-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 08:06:05 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43cfba466b2so59165685e9.3
 for ; Mon, 12 May 2025 23:06:05 -0700 (PDT)
Received: from ?IPV6:2003:e5:8712:700:7979:a587:7535:c0a5?
 (p200300e5871207007979a5877535c0a5.dip0.t-ipconnect.de.
 [2003:e5:8712:700:7979:a587:7535:c0a5])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f57de0ddsm14628826f8f.7.2025.05.12.23.06.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 12 May 2025 23:06: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" 
X-Inumbo-ID: 5ac3ee80-2fc0-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747116365; x=1747721165; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=DGtCLplKUKXbSKQt37ymuwbot4atAEF9v2Sf5XSpTlc=;
        b=RcMocPNZOA6Pxn6ZsPy/KTYhI15MOLpG2tUuBLYyUjv5IIYTJM642QuB4ROziPGcE/
         whh9ZigUQJdlZa8rIZuYzH4BVW6iFe5MHurhOMviYyXDSyZGj0W0vyOabc7Enonb3JZ/
         kgbWK6CBDKZEE/kLu5fR0J9k0u1Sstq+QNJJ0+kwCV+ar8Y1VDUEi1CCfPZCHR10IALR
         nePlCJqnf9Qe+eiw0zXZsQWP0ME/H3seuWq4TtBsAc1Kb+tA5S2671PA9tp6GMd4L94b
         LXE4WV5Ahy0ylJLCuLRblG6EYqb7lVxqoGyCb4UBdrPVHy51ow4sI0N15P4GXS0bIXRQ
         zMKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747116365; x=1747721165;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=DGtCLplKUKXbSKQt37ymuwbot4atAEF9v2Sf5XSpTlc=;
        b=RXs8tuncqtNx7KHozfp7LRp0fDFqaKQJaHyBRQi+DG5hzOB/5FLQbYhGlUWvjmaotv
         JTvynNJHYa27xEEWer4dOox0DsYiK5f/on9kVpPNyr64OT8+gKKIT3EC96k8/x0gIAf/
         GY1vlQ0UJA8fE3zhgVZ/hZrco4kbnRaIOv5zTxl3QUmtuVhPJPw8RdkwVadKegdA3Urc
         LJ9KUH2Ig8DvpuiN5IwuW5onlyYuDci0R1ckR03RxkFSderdwglnb4aDfke7L6TD5LtW
         +GL0RDdPmOzXiP5ehtaH/fwdQ3lGEI1D6E646Q3dc7cWnwTPpgBUa5AWCgh1iE0/dNCD
         4zDQ==
X-Forwarded-Encrypted: i=1; AJvYcCW0fsZuvZzL18IKvkoQj+Ob5NFZiUm+SCSn2ujr3oA7q4Gd/g6GBvcTYP266+gADluTcK5rRpXrjEU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwyfzGfoWJc5FYH+2UshwgUVQCdhiZvzZx0F8y1cmRY6chhPJbi
	W1merPEJCwzuaQ7qHADbjxLAKyejBV7XLGo8ehIVXlZ/n1ZltX6Gea4xcmRFDAE=
X-Gm-Gg: ASbGnctqGHE2Nt5jqZ/ij1+2GpmZJ1bK3MFXjgH0T9nWvBpwPumXcLyPfjLTSzCDWUW
	m5oBl8reehylre0m2KVanTwFdnWoJNJF+SsD69LRekmIU2sDWUHI7RHqEI30mMsl7SOpKGrlCS8
	HtrDRfjO0jqBHQd5PmngDA1W0zpdhuTrc/9Agmv9fN0hN7dpZTNY9ok1ZiR3wCjFFWcRxXP1i2+
	l4FnlKDuWAdCnpo+cjmjWdTa85muLVAOanoPldBZmqpj1OAaJbXjL786zdrXK5vec61b7vYwApT
	HUZQ2XYm3N897sSvJVbOG3afj6NtP5eNOBr+6I7Uic/cGMtCJoq8z59EPGgd/zMjSmELS9weC2W
	d4DXbLw2qNr53ST+uBbm7Er+R5VMg5vTRo8dnebPaRbxsWDL6TJ9Uup6476KMs7ebYftbjcVFfA
	==
X-Google-Smtp-Source: AGHT+IEv3x6OnuUD8tSlxO0X21jPh7ofLW3oGg6Tf2SOgLYrIsn3YKIAIsv43QpDxgYcarE+2u6gGA==
X-Received: by 2002:a5d:588a:0:b0:3a0:b2ff:fb00 with SMTP id ffacd0b85a97d-3a1f64b4557mr10829757f8f.44.1747116364662;
        Mon, 12 May 2025 23:06:04 -0700 (PDT)
Message-ID: <6cc20ef6-d8e5-4c74-89d9-6a949c84b397@suse.com>
Date: Tue, 13 May 2025 08:06:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
To: Xin Li , linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev
Cc: Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 , Thomas Gleixner
 , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky , xen-devel@lists.xenproject.org
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
 
 
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------KVDs0RSTYDoV4udMXyJ1ZgMA"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------KVDs0RSTYDoV4udMXyJ1ZgMA
Content-Type: multipart/mixed; boundary="------------037X61wSMbHMyK1zL5Bo0Gqo";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Xin Li , linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev
Cc: Ajay Kaher ,
 Alexey Makhalov ,
 Broadcom internal kernel review list
 , Thomas Gleixner
 , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky , xen-devel@lists.xenproject.org
Message-ID: <6cc20ef6-d8e5-4c74-89d9-6a949c84b397@suse.com>
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
 
 
In-Reply-To: 

--------------037X61wSMbHMyK1zL5Bo0Gqo
Content-Type: multipart/mixed; boundary="------------vjdcwKn490L7VqapiJAC214g"

--------------vjdcwKn490L7VqapiJAC214g
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTMuMDUuMjUgMDc6NTUsIFhpbiBMaSB3cm90ZToNCj4gT24gNS8xMi8yMDI1IDQ6MjQg
QU0sIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+PiBOb3cgd2l0aCB0aGUgbWVudGlvbmVkIHBh
dGNoIHJlYWxseSBhdHRhY2hlZC4gOi0pDQo+Pg0KPiANCj4gRG9lcyBpdCBhbGxvdyBwYXRj
aGluZyB3aXRoIGFuIGluc3RydWN0aW9uIG1vcmUgdGhhbiA2IGJ5dGVzIGxvbmc/DQo+IA0K
PiBUaGUgaW1tZWRpYXRlIGZvcm0gTVNSIGluc3RydWN0aW9ucyBhcmUgOSBieXRlcyBsb25n
Lg0KDQpZZXMsIHNob3VsZG4ndCBiZSBhIHByb2JsZW0uDQoNCg0KSnVlcmdlbg0K
--------------vjdcwKn490L7VqapiJAC214g
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-----

--------------vjdcwKn490L7VqapiJAC214g--

--------------037X61wSMbHMyK1zL5Bo0Gqo--

--------------KVDs0RSTYDoV4udMXyJ1ZgMA
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/Ey8FAmgi4UoFAwAAAAAACgkQsN6d1ii/Ey/j
8AgAi5+zla5tcvAhgYRt4I5XHYB13eK8ZpXiaiXLjgkYMVuC16ud/Vge0rsHwl6ehyQtB1zXh14a
YOTKFJq4oHvzFGa6DPaHuGa9BgtRzYy5ttVWOW9qSG50rrKdEq9YMU3MfqW2yx9StBk/Q3fvfZ/u
4OsOkCYaYPlx5TY5/bchG6e+kpU7wdMH9l+yqM283YkG5Pr6Q1VRb9eeB3dJyxMPTtzksP/kfKSL
UwPInCVoTHCqkoOaOjdVjQLWHnZ/rAAtIwgjg5W+4OGQX1P0R+6IR8/YkD2Zn1l0cYY2ktfFcEoq
TVrq0MxOEULofUPFxDQr4aqRDKpcd18YIFAXxn7PYw==
=m7ZK
-----END PGP SIGNATURE-----

--------------KVDs0RSTYDoV4udMXyJ1ZgMA--


From xen-devel-bounces@lists.xenproject.org Tue May 13 06:39:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 06:39:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982528.1368878 (Exim 4.92)
	(envelope-from )
	id 1uEjIh-0005OI-JK; Tue, 13 May 2025 06:39:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982528.1368878; Tue, 13 May 2025 06:39: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 1uEjIh-0005OB-G0; Tue, 13 May 2025 06:39:39 +0000
Received: by outflank-mailman (input) for mailman id 982528;
 Tue, 13 May 2025 06:39:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEjIg-0005O5-4h
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 06:39:38 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20609.outbound.protection.outlook.com
 [2a01:111:f403:2413::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 08d8e49b-2fc5-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 08:39:35 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SJ2PR12MB9116.namprd12.prod.outlook.com (2603:10b6:a03:557::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.28; Tue, 13 May
 2025 06:39:32 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8722.027; Tue, 13 May 2025
 06:39: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" 
X-Inumbo-ID: 08d8e49b-2fc5-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pyxyruE5TDPU5Na3cue7KkhT3hTyH4dm8i4dxy2ulzzR6VlNaa2hn8hQ9HrhjeuKCRWZ9OZmXu3NzZ35ql0tQ9wo3P6xycQhu7359QBWWX2F4D53pHCvAb3aSGVXR69tL5Duynmj6n4s5lu4ltb/RsOp0Qhj/DJqPKaSIjg++X1W1Vi33G58NlSv3XyvfkTgBaJ5X9gz+sq3/YOWyJdRTDdI8yk1vq/OGvvXm00ntvdLKPfxTi3hpyrSv0wEzUDy2XwYAGBem0Mei5H/Aa0CZcvSHf355UoUP4OIP7g6ar93wAbiUctNQr3g6TdQyzeSMRD2mEzF5zpG65pd4g5MhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MRyg2/1oL9i9Set3BGWd07g/6+fRgawHIG2cKRoIQjQ=;
 b=EvjFtEjOQ4q8DhqeVzcdhb/pUp86rCLX3S9g/LDjJeOuiTt2ZjkQaYd0HUwfdMJ6cIHjdZn9IZAmq4DMWNxFQiFQnPF8Zxqwy4fj64hux4E4Asx1/pYoqL2LcCaKytpLJ2Ld5EMNZM3whTtZzRdNFDTppBMrgCc5wQaHJbX0DmA8EdlQ+IyJXJ6hg7R0HGPkiEsVe/FPHm1zTbb5qWfz+t1yoNBW/0NoJLPM+DG2Q0OpaG0GFuMkxZBbd8I7kUnf4gGsmlFSL+3/BA8/5s+FPjgP1T7gX+Ct3uEYjFMD7PakFZ+r3ixCtWuxw3khPNzTZii6Q8CyisItsa5GQPxMEg==
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=MRyg2/1oL9i9Set3BGWd07g/6+fRgawHIG2cKRoIQjQ=;
 b=hH/1Wv7jOZVzPFfO/4WjBM/xj6qrycwUNLlJ8DYdrrGXkJK7hGIfNYs6Ggn50SfaPVUk6RRJl+jOQOLhzREvAq1FfwRbt6GjwKdxL70SWR7qOhXECZnTquBA6RjkTpZ0fCUU4cdel/U1nhOJM2DvoPu4hPrtsP4nHfbw3wqR2FE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <79190663-92ae-415c-a104-29117d084e62@amd.com>
Date: Tue, 13 May 2025 08:39:28 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/6] xen/arm: exclude xen,reg from domU extended
 regions
To: Stewart Hildebrand ,
 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: <20250508132040.532898-1-stewart.hildebrand@amd.com>
 <20250508132040.532898-6-stewart.hildebrand@amd.com>
 <3caa25d7-9faf-4099-a0a2-f7014c01e1ce@amd.com>
 <56975c31-a088-43bf-80a5-65da6cc00221@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <56975c31-a088-43bf-80a5-65da6cc00221@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0148.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:b8::13) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SJ2PR12MB9116:EE_
X-MS-Office365-Filtering-Correlation-Id: 29adc267-236a-4b3c-860f-08dd91e8eaf9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UGl6VHNYY2FnUTdKMGlwdTN2SVdnZG5rV3p5OGVEQmdlTTNNMmRqNzBzUkhU?=
 =?utf-8?B?NGhDaENHQWc3RVZiUG1DbWNlbzU1VDlwWVZkVXhWL1o3aEZOVlRGUHNaUXhJ?=
 =?utf-8?B?a25EdGsycXRlRVRyRHRZUFF5SFhCR1NGYXJwY0M1SEtpVExWdFJPaU5mQkVv?=
 =?utf-8?B?TDBzRmplK1hGUjZRaGtBczk3Z0lWUXNxeVpxNDJ4dXdoRU0wVFpWR0J4N01S?=
 =?utf-8?B?ZzZOdXlEODBxTXR1WS9ZeTdsbEJUa2pvY0VqaTFMYTl4dHIzOWcybzBxNjFP?=
 =?utf-8?B?VFpJQm94M2pjWXBBZytzQmdCc0pBL1R1QzlLU2xRSDlUSXErdTkzbUNzcVBv?=
 =?utf-8?B?cUI1b3JMSG1IdS8wZ1EyVmx0ZUNIaXFuM0dObEJZMUwwbVNma2dHR0lVR2NZ?=
 =?utf-8?B?YVB5N01QMmYwbXhhQmV3VGhHOWV6VlNyTy9ZUkp6bDhJRTBHT2ZjRnYwdmpP?=
 =?utf-8?B?SHcyQmZRR21qbmpqOVBHTzFqSGlwMFVZNzAyWmlaOFFyUHdCd2RzcldpeFF1?=
 =?utf-8?B?WXJkQUp3YitnVW1sTmNVUHJTaElpdVJzS3gyVm92Q2FTbGYxVGJKaEx4UEU4?=
 =?utf-8?B?b0lTZVUzczhSQ0xrUTBNc1BzVmtHUHlSODVvNFlKY3VZT3psMW41ckZNKy9G?=
 =?utf-8?B?SHo1d0Vac0xZaHNDaG5aOGFYUVFtNCtWV283UXV4ZGcrbjAwMDUxcm9BeFVC?=
 =?utf-8?B?RGk3QWR4VGMwVXBOZTNRZURxNTdMREhzeDhRVEZydnFNNDFxWFdvQ0FZM2ZY?=
 =?utf-8?B?M2pnRnI2YWhET2hyZkxqdVJiRCtFRHdHQjJydFEvTmFucTkvbFBSNTViMVk2?=
 =?utf-8?B?YXJoc0YrbW5sUHdMd3VRQnJDeW9iaERQcktuZzVxaFVUeGVla2krUU1PeUdT?=
 =?utf-8?B?VnhUclBzcTlsOEgwMHQ5MDh3d0pyS1BrUStXaFZhZkNxTkxVZ3hpRVl5ZUR0?=
 =?utf-8?B?dUhhZ3Iyb1hQWi9UVjZBeWxnQ3U2eWFRUndkdTUxbXFtUnRuVVZJRkFkbkVi?=
 =?utf-8?B?UjBkL3VNSFdHZXYzREJLZWZBQlBoZDdkcU00c0NraWU5eTZJU3lRY2JlMWJG?=
 =?utf-8?B?YlBiMzhjUER6RTZWbVJvMjhrbVZicVBaZlByYmZMZ05MM3dCTTcxMnAzK1lX?=
 =?utf-8?B?b1FicUp4RzMvTklOWkRuYTNjQWl3c2cwNmVoRHF0cjZmSmJMVWlRQ01raWJ0?=
 =?utf-8?B?aGt1cUhyNmw1UG91RlZzOE1vclpLWlVKdWVYZ3c0c3RvcWI1LzdjZUlTblhR?=
 =?utf-8?B?RGhGaitsa1ZIZWQ4QjZ2V0Y3OTdEc3lUZTVUUXcyUVlBbmZ1aGNQeWdNaU5a?=
 =?utf-8?B?UTdvdXE5NEJOTFI2TkpKRlk2TlJ3Q3YwTk5EdEdGWVFHVFFmajMyTHZ1MVhx?=
 =?utf-8?B?cnpMcHhZV3pzTTFMc241LzdRNVd3cytQZkdwN3B6N0Y3bUEybkZwdjBEaUFU?=
 =?utf-8?B?cDRBU2dubFIvS1dKNTdaT1BsUG9zN3NEd3c0UzAwdjdqRFFZazYvVkx2a3pN?=
 =?utf-8?B?b29UeG5GY0c4WU1zUmVVUjNrM01nenNHOUV6UW1nUGNqNlVjZ21qVlduRFBx?=
 =?utf-8?B?SVhibnprOG1lWG1MelVFandDSi9QTzE0dzI2U1o1TEtNYmptVmFWazZTTWZy?=
 =?utf-8?B?TTRyVlpCZk5CSVBZZWZYRUxoSHhrTHZVeHFCUTZxSkNvRFdFMlpLcmQrVTYz?=
 =?utf-8?B?QzN0ZjRVUmhyK2FtTndoNzJiUXVwQlBHeG9FZUkrZWxKRkxSOEpxYTRMVnVC?=
 =?utf-8?B?UUs5S3l6WlBMRjRLcGdjYkxkWFNORWJ5U1BnajhDTG8rb05BdW5aUXBqV0M2?=
 =?utf-8?B?SnpQaXhvOTcxc09hTm90NUt5SFU0UHpVdmN4d2p3NXRMR2hvc1ZnU3JPUkFQ?=
 =?utf-8?B?WGcxc01VbXg5Vk9lb3FDREExeHRJZ1lUVlc3SWFpb0pFOExsMTJLT2JPRTc0?=
 =?utf-8?Q?LcOjddxpogo=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Ny82cXhrNUJjR1Q5RXl0N3UzZU5IUElmWWVxbmYxUk1iMVFweVRkTmVrdVBj?=
 =?utf-8?B?U21aYUJDVi9VOXRaa0t1SFJPcm8rZXJHNTc2MElmWTByQzlKU2I1K1luNHBN?=
 =?utf-8?B?M1hSakJKZXJYQVJxK0pVbUZrM3dsUFdyVUxhVmVmcWtySHRYVVRKUVNhbktR?=
 =?utf-8?B?WjlqMGR2RGlPL3ZzQzVqeXVzUVNVdi9qc0NqS1BjcUo3aFF4N3M1SzhMZmZ2?=
 =?utf-8?B?cFJWRlRBaFRjS1VCVHdndlhQSDFYY29zd2hpWUZhc2tjeUYrYzEybm5jZS9M?=
 =?utf-8?B?SVdpNXQ5VHF6QkQrVXpCZDgwSCtLdFJXSU1kWXpodHRNMEU1bDBqOTArSXBK?=
 =?utf-8?B?eGdqWlFQSldycTJuK3lvTU50Z1VYSXJIdXY2QWg0bnZ4dUY0Wk5zWkMrWDg1?=
 =?utf-8?B?cGozYXBGMTVlT25ZRUhrRTNJY0V1QVZsMHQvVHhnQjZ0MEZLZFhvSUc3Uis1?=
 =?utf-8?B?YVVScFBGVnhXOXJIV2JLS1pwWk41L01nbThtbEE1Z3JrK1ovS0JmSnpyS0xZ?=
 =?utf-8?B?NUpiSlhGVEQzYUdGbG1EY0VQSWFpbjFSd1owanppMDRsZFJqYys1M3NQbFN1?=
 =?utf-8?B?dDk0MFNiTHdsKzlqY1NqWXdzMmlJN0tTK2hTVE1LSzhlSTdleFZvTndCQ2t2?=
 =?utf-8?B?Z2ZHZXBxaDJnVktvTk1DRHhTbW9UQityWlNxK2hWbTB6ODlSOGJseXgxeFh4?=
 =?utf-8?B?MGJyOVFaNCsvU1dIblhMYnZ2NTN0bGFrUWNITzFybDdScFE1M2xNNTN5bkdn?=
 =?utf-8?B?eG1DejgzNXd5QWJWRS9DbXRjSk1zYnZUVDZQZlZ5ZXdqa3dhWDFiYTgzL0VY?=
 =?utf-8?B?VFlYWUtMVVNGSU5IaVhac0JScGVxZ1MvRjJVN0h2M2lncFBranpYMmhJenl4?=
 =?utf-8?B?QVlWZWhaczkrWWw2UXVZaGNRRU5mV3p3ZlFBU0wrZHc3Wll1cXJMU3I5a0xX?=
 =?utf-8?B?TEErRU5YN0dpbEZFWFZkQm5xczhYSTlsSFZkMHBoVVd5YkFUMkRkaFNPSEV1?=
 =?utf-8?B?K0FxL3ZOS0hWQmF5ZlRhSlpFdXlCMXNJT0NDQkFqaTcvdDVURkErQXlKVklN?=
 =?utf-8?B?TmNTRHl5b3VrNWpXa3Rwd1ZrSzRvWmJTaUM3MnlGZ2pkdE9ZQnVqU2U3SC8z?=
 =?utf-8?B?RGptRmdMNlhVdEY2RVRDVUJiUHhFRUhHT0piL3c2Qms1ZkYyem1DNjRPekF6?=
 =?utf-8?B?YzQxa0JNQ1BqUjR4VjMwTTZDV25sdk9HYncyTVJWK2JkNGt3TUdrMEgxc2J3?=
 =?utf-8?B?eFFneGprMGpxYllyV0tINENqTGg4ak9UZWtIU2JDSHQ2NjJ3Z2IySlBhWGlm?=
 =?utf-8?B?b1c2UXV1R2orK2U3eEExTVhWYUlwMUFPTmlwZjY4VkczQTk4ZmlnWlN2M05P?=
 =?utf-8?B?V0hTR0J2UFNFc0xZcHRIQ2pIeWRuZ1pQS1IrRG81S2owYlBrbkw2Z1hpdUFz?=
 =?utf-8?B?dVFxeStQSHBrc2RwVmo4MC8yMDFzRnV6QTBtWkhhdkxGZ3dSTG9hdnlUN1lB?=
 =?utf-8?B?TndDbldkNVJaSVRzNkt3YVJtc296bXNZUHRyLzdmOUk5c0RVTFMrOFBveERt?=
 =?utf-8?B?VzI3S24xQi9vbXVIMHBDVjRMUFA5QTB4ellsaGhhSndHNHlXZ3RXN3dYVjYw?=
 =?utf-8?B?Zm9NYmNUYmIxbHgrbC9VaDg1dTRrU1ZkaS9KVXhFU3ZsVlAxNXZhcHJkTjRl?=
 =?utf-8?B?UHFUV1pkTzFtd09yK1g4ZUNEVnZFVVZYbXk4TUdBbEZxa2RrdndEVjZpcWZk?=
 =?utf-8?B?UlFXNGU4Um5KR1Zha0R2VXFhb1I2c2x2V3hFNE5HSlRJM1pFb0FjQ0RQQlNT?=
 =?utf-8?B?K042SUpWeklBazBaTzhrUmxZZWMrSmQvUGNCaDg0NG16bGNBS2JmbkJKN3Zy?=
 =?utf-8?B?M3FBczdJcnJaWm1WVVc5Z0pvb3FsYlNoWmJXdTR5VVQ0QWdzVzdsMGx0RWtH?=
 =?utf-8?B?SEI3OHlNWG05a0JCQUVkbUtNYnhDRFBlcitiNFN1UVJrVTQ1RVpPbW5tNS9u?=
 =?utf-8?B?N2lsRUFPekFFdmZqTVJraDR5bkIvSmErdHdiYTNsSUJLanhPQzBMVVl6cnV3?=
 =?utf-8?B?N3RFK0RTb3VCcVhjSms2UnNQdlZIbEphVGNzWFJUazRWbVg0ZnZXNWJtdnpj?=
 =?utf-8?Q?Q0Bo=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 29adc267-236a-4b3c-860f-08dd91e8eaf9
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2025 06:39:31.9327
 (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: 1sS20SNgzVQFXQnI3pHM7nVnkRiepRjwdKhvjs8e5hpPrvjn1So2YYPeol2pqcWz
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9116



On 12/05/2025 21:55, Stewart Hildebrand wrote:
> On 5/9/25 02:54, Orzel, Michal wrote:
>> On 08/05/2025 15:20, Stewart Hildebrand wrote:
>>> diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
>>> index 7a6cd67c22f1..1939c3ebf7dc 100644
>>> --- a/xen/include/xen/fdt-kernel.h
>>> +++ b/xen/include/xen/fdt-kernel.h
>>> @@ -24,6 +24,7 @@ struct kernel_info {
>>>  #ifdef CONFIG_STATIC_SHM
>>>      struct shared_meminfo shm_mem;
>>>  #endif
>>> +    struct rangeset *xen_reg_assigned;
>> The purpose of your newly introduced xen_reg_assigned is to keep track of these
>> ranges so that we can remove them from extended regions. The concept of extended
>> regions exists only for Arm today. Therefore I'm not sure why making all these
>> common i.e. entry in struct, rangeset allocation, etc. The other aspect is that
>> extended regions may be disabled by the user and you would still allocate
>> rangeset and add xen,reg to it for no purpose - i.e. dead code.
> 
> How about an arch hook? E.g. see work-in-progress/untested patch at the
> end.
Still, this is only needed for extended regions and your solution a) does not
mention this fact at all and b) assumes that other arches (let's focus on RISCV
for now) have a plan to use it in the future. If b) is true (I'm not sure
because Oleksii did not move this code to common), then making the hooks global
while extended regions creation logic still being under /arm does not seem
beneficial.

> 
>> Also, what about direct-mapped domUs? We don't seem to take xen,reg into account
>> there.
> 
> Right, we ought to take xen,reg into account for direct-map domUs too.
> This is because, even though the domU is direct-mapped, xen,reg can
> still set up a translated mapping (gfn != mfn). Also, xen,reg doesn't
> need to correspond to a real device, it can be any arbitrary mapping.
> I'll send a patch.
> 
>> P.S.
>> After recent dom0less code movement there are some issues that I reported to
>> Oleksii. Long story short, we shouldn't be making the code common (e.g. static
>> mem, shmem, domain type) that is implemented for now only for one arch. If the
>> need arises in the future, the feature code together with callers can be moved
>> to common. At the moment, we have some features being in arch specific
>> directories but callers in common code and #ifdef-ed (making the stubs
>> unreachable). That's not great.
>>
>> ~Michal
> 
> 
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index b189a7cfae9f..f099e27d846c 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -929,6 +929,31 @@ out:
>      return res;
>  }
>  
> +int __init arch_add_xen_reg(struct kernel_info *kinfo, paddr_t gstart,
> +                            paddr_t size)
> +{
> +    if ( !opt_ext_regions )
> +        return 0;
> +
> +    if ( !kinfo->arch.xen_reg_assigned )
> +    {
> +        kinfo->arch.xen_reg_assigned = rangeset_new(NULL, NULL, 0);
> +
> +        if ( !kinfo->arch.xen_reg_assigned )
> +            return -ENOMEM;
> +    }
> +
> +    return rangeset_add_range(kinfo->arch.xen_reg_assigned, PFN_DOWN(gstart),
> +                              PFN_DOWN(gstart + size - 1));
> +}
> +
> +int __init arch_cleanup(struct kernel_info *kinfo)
> +{
> +    rangeset_destroy(kinfo->arch.xen_reg_assigned);
> +
> +    return 0;
> +}
> +
>  static int __init find_domU_holes(const struct kernel_info *kinfo,
>                                    struct membanks *ext_regions)
>  {
> @@ -973,9 +998,9 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>      if ( res )
>          goto out;
>  
> -    if ( kinfo->xen_reg_assigned )
> +    if ( kinfo->arch.xen_reg_assigned )
>      {
> -        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
> +        res = rangeset_subtract(mem_holes, kinfo->arch.xen_reg_assigned);
>          if ( res )
>              goto out;
>      }
> diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
> index 7c3b7fde5b64..8d6bd2dd77f9 100644
> --- a/xen/arch/arm/include/asm/kernel.h
> +++ b/xen/arch/arm/include/asm/kernel.h
> @@ -16,6 +16,8 @@ struct arch_kernel_info
>  
>      /* Enable pl011 emulation */
>      bool vpl011;
> +
> +    struct rangeset *xen_reg_assigned;
>  };
>  
>  #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 2c56f13771ab..654575612744 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -146,14 +146,6 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>      int res;
>      paddr_t mstart, size, gstart;
>  
> -    if ( !kinfo->xen_reg_assigned )
> -    {
> -        kinfo->xen_reg_assigned = rangeset_new(NULL, NULL, 0);
> -
> -        if ( !kinfo->xen_reg_assigned )
> -            return -ENOMEM;
> -    }
> -
>      /* xen,reg specifies where to map the MMIO region */
>      cell = (const __be32 *)xen_reg->data;
>      len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
> @@ -196,8 +188,7 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>              return -EFAULT;
>          }
>  
> -        res = rangeset_add_range(kinfo->xen_reg_assigned, PFN_DOWN(gstart),
> -                                 PFN_DOWN(gstart + size - 1));
> +        res = arch_add_xen_reg(kinfo, gstart, size);
>          if ( res )
>              return res;
>      }
> @@ -828,10 +819,10 @@ static int __init construct_domU(struct domain *d,
>      domain_vcpu_affinity(d, node);
>  
>      rc = alloc_xenstore_params(&kinfo);
> +    if ( rc < 0 )
> +        return rc;
>  
> -    rangeset_destroy(kinfo.xen_reg_assigned);
> -
> -    return rc;
> +    return arch_cleanup(&kinfo);
>  }
>  
>  void __init create_domUs(void)
> diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
> index e0ad0429ec74..3e577e4dbe10 100644
> --- a/xen/include/asm-generic/dom0less-build.h
> +++ b/xen/include/asm-generic/dom0less-build.h
> @@ -61,6 +61,10 @@ void set_domain_type(struct domain *d, struct kernel_info *kinfo);
>  int init_intc_phandle(struct kernel_info *kinfo, const char *name,
>                        const int node_next, const void *pfdt);
>  
> +int arch_add_xen_reg(struct kernel_info *kinfo, paddr_t gstart, paddr_t size);
> +
> +int arch_cleanup(struct kernel_info *kinfo);
> +
>  #else /* !CONFIG_DOM0LESS_BOOT */
>  
>  static inline void create_domUs(void) {}
> diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
> index 1939c3ebf7dc..7a6cd67c22f1 100644
> --- a/xen/include/xen/fdt-kernel.h
> +++ b/xen/include/xen/fdt-kernel.h
> @@ -24,7 +24,6 @@ struct kernel_info {
>  #ifdef CONFIG_STATIC_SHM
>      struct shared_meminfo shm_mem;
>  #endif
> -    struct rangeset *xen_reg_assigned;
>  
>      /* kernel entry point */
>      paddr_t entry;

~Michal



From xen-devel-bounces@lists.xenproject.org Tue May 13 06:57:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 06:57:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982541.1368889 (Exim 4.92)
	(envelope-from )
	id 1uEjZR-0008GV-2l; Tue, 13 May 2025 06:56:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982541.1368889; Tue, 13 May 2025 06: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 1uEjZR-0008GO-0A; Tue, 13 May 2025 06:56:57 +0000
Received: by outflank-mailman (input) for mailman id 982541;
 Tue, 13 May 2025 06:56:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEjZP-0008GI-0Z
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 06:56:55 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 72469789-2fc7-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 08:56:52 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54D6tvIA2197001
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Mon, 12 May 2025 23:55:57 -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" 
X-Inumbo-ID: 72469789-2fc7-11f0-9ffb-bf95429c2676
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54D6tvIA2197001
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747119359;
	bh=kL/OhRm5sWyxLOSQqQ8XEjxmBfy03Niwiuryt5Xm6Es=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=dqamJ/yBhApfjc3OSDMpxZXHHxEdMYXgbitAxwexwrXqBBWQc0yk/OmlsqGJNFVQ4
	 qZRWx/K8oPirfZq1mxMCZ+ev6j10g1Mqu95ZiSR/dEL/jUrv4Fw8B5GFQSL0h+la0n
	 j4M1P324FaSysqpxlMMUn4o83KG6jZTbRk6IdBkm/7TewUllVvgrGYm8XxbE3z4n1p
	 TFogrcSgYoGnB1GiEa9LvJECv/MGp9pmgpLFqaVPKlUtjpL1MJKmzijVAhC+VIpioB
	 diyDOWH5m8MwScIvrgCAO3Z2o/1fccOqjq1cb1/fPsXu76MuCerX9E9kxv+eMMFF8a
	 fTyhY9Dcqf9nQ==
Message-ID: <16f87dc6-75d6-4731-ac8e-fafc6e84478a@zytor.com>
Date: Mon, 12 May 2025 23:55:57 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        virtualization@lists.linux.dev
Cc: Ajay Kaher ,
        Alexey Makhalov ,
        Broadcom internal kernel review list
 ,
        Thomas Gleixner
 , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        "H. Peter Anvin" ,
        Boris Ostrovsky ,
        xen-devel@lists.xenproject.org
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
 
 
 <6cc20ef6-d8e5-4c74-89d9-6a949c84b397@suse.com>
Content-Language: en-US
From: Xin Li 
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: <6cc20ef6-d8e5-4c74-89d9-6a949c84b397@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5/12/2025 11:06 PM, Jürgen Groß wrote:
> On 13.05.25 07:55, Xin Li wrote:
>> On 5/12/2025 4:24 AM, Juergen Gross wrote:
>>> Now with the mentioned patch really attached. :-)
>>>
>>
>> Does it allow patching with an instruction more than 6 bytes long?
>>
>> The immediate form MSR instructions are 9 bytes long.
> 
> Yes, shouldn't be a problem.
> 

Excellent, I will give it a try.


From xen-devel-bounces@lists.xenproject.org Tue May 13 07:00:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 07:00:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982549.1368899 (Exim 4.92)
	(envelope-from )
	id 1uEjcj-0001Jb-HN; Tue, 13 May 2025 07:00:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982549.1368899; Tue, 13 May 2025 07: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 1uEjcj-0001JU-Da; Tue, 13 May 2025 07:00:21 +0000
Received: by outflank-mailman (input) for mailman id 982549;
 Tue, 13 May 2025 07:00:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEjci-0001JO-RQ
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 07:00:20 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ec06d2d0-2fc7-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 09:00:15 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5f7ec0e4978so2087200a12.1
 for ; Tue, 13 May 2025 00:00: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
 4fb4d7f45d1cf-5fc9d700e6fsm6772501a12.62.2025.05.13.00.00.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 00:00: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" 
X-Inumbo-ID: ec06d2d0-2fc7-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747119615; x=1747724415; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NkBNxfQQ88AqlkyHVp9Jd9bltM+w4yzjC8GBY46+yE0=;
        b=UzP5hT2SK3S0xjrFnkfW+35dkE+Biu45dfg1G5Q/H4q+0OTpqgFzl5z1LLX2hI9DoU
         YUDc21//v8/yI7Zo3vSDSG5hPhdYooegcdHlwPqt9LWGBoU05oABNdSf1z72oqrALZeG
         TwVBWVxAwn7U2b1JrgMeAiJO+ANyP/G3cvsOww80VwJ0dGEHASHvgcGKCrfyNcEuWnGy
         c/kBOgQJ81yv11+QnCMJgOVJUT1cdsO0F4H5RQDHw3lqfmg/4gTranaFX176TrDuGTPU
         kwM5perU8qdzwTdwTZ8YqSu2Th/9JHBs5c0KaeFB8RfdRaSsf4uUgsuYm2t4Z/veELOh
         YtyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747119615; x=1747724415;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NkBNxfQQ88AqlkyHVp9Jd9bltM+w4yzjC8GBY46+yE0=;
        b=fxEYUrKE78woWw6+RwoZiiuWR4PFDU6AT8UZSYIeXr4u6hxNK/R1yoMhUVLaHY0lpy
         Cj67Ri6VU5ex7x47YH4lNLP2AullHtBa6t2flEl7ksbyrbDzMLKv+lBRfIlDVzEbnPV5
         jHA0kIvipdJaKVyEyeaZbtTiCcnbBtZSkRbstITzWaots5sgVJtL3bFNdG8l5En5I5Ar
         JogTfGT5c6tQ9o29VRf6/qDLGxzNPgNhbo0MoxvcXp29m2xgtZVcYbe8VgPxpDHpdNjz
         yeBPvfxJbdnf2G2Y6wYkab6h1l0MUSQPfa4CfvsrCKUwFkUyxfzHJV5YoZNA/7/A+uai
         h3uA==
X-Forwarded-Encrypted: i=1; AJvYcCVrWOLg/XH84A+/ryaxFM/sCNtz+KpRKHh/Vdt0AOAMCRxKbp29GUInBF1BmRiBJ401iOVtYa2WgFs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwJlbzJrJfizgbJEV4BOxP88dyaB0quqKEZNkZTNeDgZBr+wY4J
	1j48RwnwRjCJCcj+wvZcYK9aqHHWAo+bobQFO0DOCDVEWmxBMx2k+Rl9rJXrAQ==
X-Gm-Gg: ASbGncvaH81BGVUW7i56j0wQRNeX60DTyZHiacN77Sn6bv78Ri4AHgrS1U6U3e7OaGn
	WFGW0H6xgEabWqCifHCz42BPpWfgl+hUi8xoq0I/P77dvKTBp1N0vZXtac+/ZxmO4N3MJB8Jw5H
	YP1+IA9kdfZqhnw2bmETgkjcSnlmUquMgeV1OgTpMB0hwfjWluppp6r3xRHVICeUnYQzfyGVbca
	EdiUJi9EroTDuebbxeGDRHe1uYBynH9s4mdRTsFrcQNf25dpH3gGeuwKNbc7mz434p+mOfrNRn6
	N5RUw3s7c3HOivZVJABCY1rvU+itzZSj9YmZ3CvbSfgxYevwucnfErV3RxnV4lyINcug8OmM4Z/
	59pj6Rk6iG9GnH4q4Q4Kgd+bqmkTJIPPV21zT
X-Google-Smtp-Source: AGHT+IELlTuv1kUCKwLFsoLQep42gHF0B5u5SDbDdmnf4Lf8TWj1atJIQWJlnlDmOE/hPkEgnCsByg==
X-Received: by 2002:a05:6402:370f:b0:5fc:994c:b6cd with SMTP id 4fb4d7f45d1cf-5fca075e225mr10919952a12.13.1747119614808;
        Tue, 13 May 2025 00:00:14 -0700 (PDT)
Message-ID: <504f0be0-91fd-4847-8fcd-505771674814@suse.com>
Date: Tue, 13 May 2025 09:00:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] Add lockdown mode
To: Kevin Lampis 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
References: <20250506162510.1676425-1-kevin.lampis@cloud.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

On 12.05.2025 21:51, Kevin Lampis wrote:
> On Mon, May 12, 2025 at 11:39 AM Jan Beulich  wrote:
>>
>> I can't spot the effect the comment mentions anywhere in this patch. Is the
>> description perhaps lacking some detail? It's rather odd after all to see ...
>>
>> ... such custom token splitting ahead of normal command line handling.
> 
> If the UEFI firmware reports that secure boot mode is enabled then Xen
> lockdown mode will always be enabled.
> 
> But we also have a command line argument to enable lockdown mode without secure
> boot. This is the thing that lockdown_init() is looking for.
> 
> It is important to know if we are in lockdown mode or not before parsing any
> other arguments. Otherwise there will be a race between parsing potentially
> unsafe arguments and finding the lockdown enable argument.

Well, there is an alternative: Require the lockdown argument to be absolutely
first. (There are further alternatives, but likely less usable.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 07:07:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 07:07:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982557.1368909 (Exim 4.92)
	(envelope-from )
	id 1uEjjL-00022l-6N; Tue, 13 May 2025 07:07:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982557.1368909; Tue, 13 May 2025 07: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 1uEjjL-00022e-2z; Tue, 13 May 2025 07:07:11 +0000
Received: by outflank-mailman (input) for mailman id 982557;
 Tue, 13 May 2025 07:07:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEjjK-00022I-6q
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 07:07:10 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e1ff236c-2fc8-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 09:07:08 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5fc7edf00b2so7230049a12.2
 for ; Tue, 13 May 2025 00:07: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
 4fb4d7f45d1cf-5fda01f4da6sm3294692a12.38.2025.05.13.00.07.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 00:07: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" 
X-Inumbo-ID: e1ff236c-2fc8-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747120027; x=1747724827; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=4gayBjEZvREEXqM82tQUjyMR6cCyOQLO8tYV9dOJ+sA=;
        b=F7JXlDrrwkwF7Yu59YE1/werN3hJY7F8MSgbdrchf2QQkToBFmnRNT095td/1oGVfk
         bbNs+2BQRflRQ1PPkYu75FjEX9Z+7UgwpNeCPcNi66hjXQzZ3l1l83mgtq5kpYWptgj8
         W+K0vnmH4pr2dBKSamqzUvz42tZLOgdWfgJZX7sbG60/zqwcaskzhUaCNQc0tWsfrcTp
         bnnhonPROKIs0gOYn+Wxw09C6p8sbA3jCuKKhlOq9GogcYDZNfzjEEx2ubNKPBsmFsYJ
         GKd1zI8oooZxJVPybN5La4Wp6qteD+eZgqgcK0icjeYt68i7PIpvXU7gS8Lr8SEWaxfl
         w2eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747120027; x=1747724827;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=4gayBjEZvREEXqM82tQUjyMR6cCyOQLO8tYV9dOJ+sA=;
        b=B7JnG9d79Jlw3XZ6kAXGQ52UKIdxwOIc4TYMwcog4vkjxorMkHWldGQ3uW0nZC9eMH
         tOK4p166Ssj3GEwdk8j8I4ryc/wdCGZtlqJi8WXcKvI38+IrpuBpyF0AMtm50pumhWsf
         2PK+uK5HrWSXXoNduvchtNVEMBFpINfYoSA3DZcWbPUXgF7lFNBuf58khvH2xehxJBEX
         kKhB6lBkMIHt1OR8SjRoDi1Q8y93e8S4G/fe55gmI25iY1wZ6hr94xhzGkMOJZa5Axh0
         Zf7aiNc4sYMacGZTBD11w5CaA8D1c+1dd5tdjsv3QflL8OSx9Fef1DeBdrqfoTPjc/9w
         la8w==
X-Gm-Message-State: AOJu0YxuJsOPh6sFtuI/kYpboxYHdlLQhR5IBvaX177kJTTh3NIgG2PM
	ybWv2+azIhP9R+y74keon9ykojHSWjmNbky5ZSQYEHcMGkwubtWVWkazmuGGlw==
X-Gm-Gg: ASbGncsOiKafpM7FSMcoEvfXCagmzMs3moVeZmMqwUxfSamOMPcN4LruWAXgAW4XZzt
	21ow8sp24/kKxJHNWg8xP29nhF9/dDXNIJExvsej1TJtz6zTsKeeD+6pLxeuZ4BK2vHbSlaxzPF
	8cKAlVwDhiNUQ0Jj+FEr8P4wftnTMfWS+Fkgi7LqMf4JPRXXoiPpozOnOqtKAvaN4SKJ/NLuvdx
	lZpEcdgW4lZXtNG40RSGV3yRUd4MmEyqwOuaWtJOMH7ylVANF9g40SryX52iwLe8GJXEnJoKBtn
	TPzAgbYozN7B3M9sJsNdCmCRIjJjRyU+3ktvHOCiWryv5MNu3qjBzxnF8OtPJ8c6FxS0/XVjTXA
	LrYE47UaFuLds9p5ZdHyGYLf+Ax+DKGHQj1d+
X-Google-Smtp-Source: AGHT+IH7kzdBLU6WMTgKNgoEdcD1UZeSWWYouxlFmBmJ2sd6bA14R2R8H8/UC6ag9OziCHUvLakVkQ==
X-Received: by 2002:a05:6402:43ce:b0:5fd:10fe:9e86 with SMTP id 4fb4d7f45d1cf-5fd10fea100mr8845709a12.28.1747120027486;
        Tue, 13 May 2025 00:07:07 -0700 (PDT)
Message-ID: 
Date: Tue, 13 May 2025 09:07:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/3] Add lockdown mode
To: Kevin Lampis 
References: <20250512195628.1728455-1-kevin.lampis@cloud.com>
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250512195628.1728455-1-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.05.2025 21:56, Kevin Lampis wrote:
> The intention of lockdown mode is to prevent attacks from a rogue dom0
> userspace from compromising the system. Lockdown mode can be controlled by a
> Kconfig option and a command-line parameter. It is also enabled automatically
> when Secure Boot is enabled and it cannot be disabled in that case.
> 
> Ross Lagerwall (2):
>   efi: Add a function to check if Secure Boot mode is enabled
>   Add lockdown mode
> 
> Kevin Lampis (1):
>   Disallow most command-line options when lockdown mode is enabled

This looks to be a plain re-posting, without addressing comments already
given. For my part, I'm not going to repeat them on this (now properly
threaded) re-submission.

Jan



From xen-devel-bounces@lists.xenproject.org Tue May 13 07:27:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 07:27:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982565.1368920 (Exim 4.92)
	(envelope-from )
	id 1uEk3D-00054I-GT; Tue, 13 May 2025 07:27:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982565.1368920; Tue, 13 May 2025 07: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 1uEk3D-00054B-Bm; Tue, 13 May 2025 07:27:43 +0000
Received: by outflank-mailman (input) for mailman id 982565;
 Tue, 13 May 2025 07:27:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEk3C-000545-FJ
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 07:27:42 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c0c2d5ee-2fcb-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 09:27:40 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad24b7e0331so359217966b.0
 for ; Tue, 13 May 2025 00:27: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
 a640c23a62f3a-ad21988d6bdsm729136366b.180.2025.05.13.00.27.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 00:27:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c0c2d5ee-2fcb-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747121260; x=1747726060; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=MSzCmzilu7/zkEIRhC3YM2VZUgiSq/7mSAbdIC4GE6Q=;
        b=bpiRHyGncA+PGF+5ZoioIvKAr8jhNCt1k8x9lMGiuS6quZ1k2sxkmKM7hCJ7kZYZtE
         by50VG0Myy890aWfMwf0JaYnGkKliQu9YTwhp/y3xhcIiS12W3xindsgbayr9UoNkgDI
         w/jP88kHLB4hu6pTDGssmSInqrjK4skDCXPh+JYIy5UXTfb1gE2Z3/6gF5JQRaL2EOyA
         Swmyv38YyBcIPvnK17rIuUBj+RxSzxBW2in7RgKeLxbsSAJbsrkMLtLFFgNbC5tJWqj6
         w3gLk4FbRQxUQh2sAp1swimuUdr6zFZtq96JqtV+wSpnQKplRxsZgLc16tSQU719ZFXJ
         x4BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747121260; x=1747726060;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=MSzCmzilu7/zkEIRhC3YM2VZUgiSq/7mSAbdIC4GE6Q=;
        b=kkbR9JR1L4J3EdM+dGMv5sNtM11MyGCrjDDc1dZ627e8E94kz0VWZ7ro66q7I3XuRC
         DtcYq2RZzmQiPtJYQpdMn/O6LeE9PqliHPHWA8qF5On8fXQSv3cB5nANvHrPI3OG3RfH
         ZNdROoZcOW57bpnNdMo6xcsaNh6XzRuKP/2oBax3Gd9PmLtTiRD3zh9fxnMg2pu5u5US
         x5lJLuXsLu71BTeNRMSeEw58OsXzSH+tSXvcJ4Aw+f1nW9ZCmDiPTswLbcxu3cGZO1Ki
         JytmW3wg+oSXYFIKJRRXJv2Rp+FM2yMfHVQKj0pKVq5t2LpOVEIFIuW+A3DQR2PgrslV
         Vfaw==
X-Forwarded-Encrypted: i=1; AJvYcCWm+OyeNhtFirB4Gf9N0fopuYdwY0sZ3ziK17uZm4SZjw8YN37GKF/wSKF4foeJJmhK2Fozz7dtBQA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyXTPS4n7RCF5J4/hZNx6vsQnKGepnZf/nnrCn8ZHQz21f8ivjc
	v7/QpGCNKDJhPbdhO9JI5ZrHoPmekeoucPtjMObk7rbgut76YRu0ZYqmX/zDdg==
X-Gm-Gg: ASbGncuom8tEjX2mH3QVPXUmhCgQYP7SgRRPwOq0gn8MXQY0M6/fvneytMhBbwZrXxi
	/RZCznAeZu8daWYY9oh9YJJ+tW1QUgW83UEEhuqvJx4s59YXhmPSswhcW1Dmj/iUZ7aXeNNNGzD
	17OTjNXQL7v3BTN1hZeE6/HhtQjnRsJhNVJhiKDkO5ZiDAZNEUopRQ7cZH5OR3RS/ABQg284l22
	SX21hgQCAdSsEHZZIjU7nxekkk5SG3QUn/sy4j223PMrDrRHe2MULi5dAR0X/2SVwt5MTHzw1tl
	u3OB9r+QO3nUI2y8HzAANlUu0xh49Kg6iIo/MsqQGfZuTODnRQFsoScKmZ0kYunAGAw3J+ECp9M
	ra5QoHmJB8ipYiTPpaVcn1Lq43u/qAzzm1/pI
X-Google-Smtp-Source: AGHT+IEFqvB1gs0Yf5YXXEYMeelmtixAOQOKGzBBiecrww3fZouJPsUqwuVuviRDPnXRRrb2L/vK/Q==
X-Received: by 2002:a17:907:7f21:b0:ac2:a50a:51ad with SMTP id a640c23a62f3a-ad218fc869emr1405766966b.14.1747121260322;
        Tue, 13 May 2025 00:27:40 -0700 (PDT)
Message-ID: 
Date: Tue, 13 May 2025 09:27:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools/libxl: Only access legacy altp2m on HVM
To: Jason Andryuk 
Cc: Anthony PERARD ,
 Juergen Gross , xen-devel@lists.xenproject.org
References: <20250512235409.18545-1-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: <20250512235409.18545-1-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.05.2025 01:54, Jason Andryuk wrote:
> Only access the HVM union b_info->u.hvm on HVM guests.  The union
> access is not guarded, so this reads and sets the default even on
> non-HVM guests.  Usually this doesn't matter as PV and PVH unions are
> smaller and zero-initialized, but the zero default will be re-written as
> a -1 boolean.  Generally, it it could incorrectly set b_info->altp2m
> through aliased data.
> 
> Fixes: 0291089f6ea8 ("xen: enable altp2m at create domain domctl")
> Signed-off-by: Jason Andryuk 
> Change-Id: Ifaca3533dcce3f409c2efa292c7e96fba6371d9d
> ---
>  tools/libs/light/libxl_x86.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
> index 0b1c2d3a96..b8f6663829 100644
> --- a/tools/libs/light/libxl_x86.c
> +++ b/tools/libs/light/libxl_x86.c
> @@ -821,10 +821,12 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
>       * If the legacy field info->u.hvm.altp2m is set, activate altp2m.
>       * Otherwise set altp2m based on the field info->altp2m.
>       */
> -    libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
> -    if (b_info->altp2m == LIBXL_ALTP2M_MODE_DISABLED &&
> -        libxl_defbool_val(b_info->u.hvm.altp2m))
> -        b_info->altp2m = libxl_defbool_val(b_info->u.hvm.altp2m);
> +    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
> +        libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
> +        if (b_info->altp2m == LIBXL_ALTP2M_MODE_DISABLED &&
> +            libxl_defbool_val(b_info->u.hvm.altp2m))
> +            b_info->altp2m = libxl_defbool_val(b_info->u.hvm.altp2m);
> +    }

I think at least the latter half of the comment wants to move inside the
if() then.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 07:44:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 07:44:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982574.1368929 (Exim 4.92)
	(envelope-from )
	id 1uEkJa-00080J-QK; Tue, 13 May 2025 07:44:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982574.1368929; Tue, 13 May 2025 07:44: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 1uEkJa-00080C-N2; Tue, 13 May 2025 07:44:38 +0000
Received: by outflank-mailman (input) for mailman id 982574;
 Tue, 13 May 2025 07:44:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEkJZ-000806-IM
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 07:44:37 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1c4a1f31-2fce-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 09:44:35 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54D7i2Hq2223737
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Tue, 13 May 2025 00:44:03 -0700
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1c4a1f31-2fce-11f0-9eb6-5ba50f476ded
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54D7i2Hq2223737
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747122244;
	bh=iTnNWYX2obU2wqvg9Uxp4/8y/l3QJ3cSHicHW0YLUMU=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=T6wPeUBXmVZWSZhZUOIDpcsrS2otEO6JGtz1qMkJLlGRVR72Q54uO4jsCdgt4rj4T
	 iOuyG+8jFrEg+B4yQKF6XzuhTK0q9q/OPlc2PraMY2ZKpE/y9efNUWXIiDU46sbf/h
	 xWYyM1N7vNC0+1CmBGyRBuVm+vCRbRTVVtL/J9CmHH6GQLrhpKGWKNR91PMG1Q4RgL
	 2tXQfuBBn+5LBa+l+qSoZ0r+AqZyIKPRar8E7z7HyIZ4i2zhrZUzyI2dhfRGnd0QZd
	 j6ep7OfZNzFNbzf2XHS9K1HZMqdPSsP+nigSi2C7trSIED3gqVXArqNa9N5QpjsWfF
	 0MBt3SSYQQM8w==
Message-ID: <2365af70-d36f-4663-b819-59d886936ef5@zytor.com>
Date: Tue, 13 May 2025 00:44:02 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        virtualization@lists.linux.dev
Cc: Ajay Kaher ,
        Broadcom internal kernel review list
 ,
        Thomas Gleixner
 , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        "H. Peter Anvin" ,
        Boris Ostrovsky ,
        xen-devel@lists.xenproject.org,
        Andrew Cooper 
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
Content-Language: en-US
From: Xin Li 
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5/12/2025 4:20 AM, Jürgen Groß wrote:
> On 09.05.25 10:18, Xin Li wrote:
>> On 5/6/2025 2:20 AM, Juergen Gross wrote:
>> I'm trying to evaluate how to add the immediate form MSR instructions
>> on top of this patch set.  And I'm close to get it done.
> 
> There is something to consider when running as a Xen PV guest, ...

Andrew said he doens't plan to expose WRMSRNS to PV guests, and doesn't
expect MSR_IMM to be useful in a PV guest either, which I fully agree.
>>>
>>> Note that in the Xen PV case the RDMSR/WRMSR patching must not happen
>>> even as an intermediate step, as this would clobber the indirect call
>>> information needed when patching in the direct call for the Xen case.
>>
>> Good point!
> 
> ... as this still needs to be true.
> 
> There are 2 different ways to deal with this:
> 
> 1. When running as a Xen PV guest disable X86_FEATURE_WRMSRNS and
>     ASM_WRMSRNS_IMM (e.g. in xen_init_capabilities()).
> 
> 2. Buffer the original instruction before patching in apply_alternatives()
>     in order to avoid the sequence limitation above (see attached patch).
> 
>> Deciding whether to retain the pvops MSR API is the responsibility of
>> the x86 maintainers, who are the ones experiencing the challenges of 
>> maintaining the code.
> 
> Well, I'm the PV ops maintainer, so it is basically me who needs to deal
> with this. OTOH I do understand that diagnosis of problems with PV ops is
> more complicated than without.

Indeed, significant improvements continue to be implemented.

> 
>>
>> tglx said @https://lore.kernel.org/lkml/87y1h81ht4.ffs@tglx/:
>>
>>  > I fundamentaly hate adding this to the PV infrastructure. We don't
>>  > want more PV ops, quite the contrary.
>>
>> That is the reason I took a different direction, i.e., removing the
>> pvops MSR APIs.  But if your approach is cleaner, they may prefer it.
> 
> In the end it isn't adding additional PV ops interfaces. It is modifying
> existing ones.
> 
>>
>>> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/ 
>>> paravirt.h
>>> index a463c747c780..df10b0e4f7b8 100644
>>> --- a/arch/x86/include/asm/paravirt.h
>>> +++ b/arch/x86/include/asm/paravirt.h
>>> @@ -175,24 +175,72 @@ static inline void __write_cr4(unsigned long x)
>>>       PVOP_VCALL1(cpu.write_cr4, x);
>>>   }
>>> -static inline u64 paravirt_read_msr(u32 msr)
>>> +static __always_inline u64 paravirt_read_msr(u32 msr)
>>>   {
>>> -    return PVOP_CALL1(u64, cpu.read_msr, msr);
>>> +    EAX_EDX_DECLARE_ARGS(val, low, high);
>>
>> This is under CONFIG_PARAVIRT_XXL, thus CONFIG_XEN_PV and CONFIG_X86_64,
>> therefore we don't need to consider 32-bit at all, no?
> 
> Right. OTOH the macros are there, so why not use them?
> 
> In the end I'm fine to open code the 64-bit case here.
> 

Here is a patch I cooked.  I added an ALTERNATIVE() hack because the new 
instructions can't be more than 6 bytes long.  But with the patch you
just sent, it shouldn't be needed.

diff --git a/arch/x86/include/asm/paravirt.h 
b/arch/x86/include/asm/paravirt.h
index df10b0e4f7b8..82ffc11d6f1f 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -177,18 +177,20 @@ static inline void __write_cr4(unsigned long x)

  static __always_inline u64 paravirt_read_msr(u32 msr)
  {
-	EAX_EDX_DECLARE_ARGS(val, low, high);
+	u64 val;

  	PVOP_TEST_NULL(cpu.read_msr);
  	asm volatile("1: "ALTERNATIVE_2(PARAVIRT_CALL,
  					"rdmsr", ALT_NOT_XEN,
  					ALT_CALL_INSTR, ALT_XENPV_CALL)
+		     ALTERNATIVE("", "shl $0x20, %%rdx; or %%rdx, %%rax", ALT_NOT_XEN)
  		     "2:\n"
  		     _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_RDMSR)
-		     : EAX_EDX_RET(val, low, high), ASM_CALL_CONSTRAINT
-		     : paravirt_ptr(cpu.read_msr), "c" (msr));
+		     : "=a" (val), ASM_CALL_CONSTRAINT
+		     : paravirt_ptr(cpu.read_msr), "c" (msr)
+		     : "rdx");

-	return EAX_EDX_VAL(val, low, high);
+	return val;
  }

  static __always_inline void paravirt_write_msr(u32 msr, u64 val)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index ea3d7d583254..cacd9c37c3bd 100644
@@ -1204,20 +1206,20 @@ __visible u64 xen_read_msr(u32 msr)

  	return xen_do_read_msr(msr, xen_msr_safe ? &err : NULL);
  }
+
  #define PV_PROLOGUE_MSR_xen_read_msr	"mov %ecx, %edi;"
-#define PV_EPILOGUE_MSR_xen_read_msr	\
-	"mov %rax, %rdx; mov %eax, %eax; shr $0x20, %rdx;"
+#define PV_EPILOGUE_MSR_xen_read_msr
  PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_read_msr);

-__visible void xen_write_msr(u32 msr, u32 low, u32 high)
+__visible void xen_write_msr(u32 msr, u64 val)
  {
  	int err;

-	xen_do_write_msr(msr, (u64)high << 32 | low,
-			 xen_msr_safe ? &err : NULL);
+	xen_do_write_msr(msr, val, xen_msr_safe ? &err : NULL);
  }
+
  #define PV_PROLOGUE_MSR_xen_write_msr	\
-	"mov %ecx, %edi; mov %eax, %esi;"
+	"mov %ecx, %edi; mov %rax, %rsi;"
  #define PV_EPILOGUE_MSR_xen_write_msr
  PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_write_msr);



>>> +__visible int xen_write_msr_safe(u32 msr, u32 low, u32 high)
>>
>> I think we can avoid splitting this u64 into two u32.
> 
> This is related to the native WRMSR interface. The WRMSR needs to be
> able to be replaced by the call of the Xen specific function.
> 
> I could handle this in the prologue helpers, but I'd prefer to keep
> those helpers as small as possible.

The above patch makes PV_EPILOGUE_MSR_xen_read_msr empty, because only
RDMSR needs to convert edx:eax into a 64-bit register, and the code is
added into paravirt_read_msr() already.

For xen_write_msr(), the change is simple enough.

Thanks!
     Xin


From xen-devel-bounces@lists.xenproject.org Tue May 13 07:49:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 07:49:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982587.1368939 (Exim 4.92)
	(envelope-from )
	id 1uEkOM-0000Ca-Dk; Tue, 13 May 2025 07:49:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982587.1368939; Tue, 13 May 2025 07:49: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 1uEkOM-0000CT-B2; Tue, 13 May 2025 07:49:34 +0000
Received: by outflank-mailman (input) for mailman id 982587;
 Tue, 13 May 2025 07:49:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEkOK-0000CN-Nj
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 07:49:32 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce15cc80-2fce-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 09:49:31 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5f5bef591d6so11120661a12.1
 for ; Tue, 13 May 2025 00:49: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
 a640c23a62f3a-ad249135303sm408760666b.100.2025.05.13.00.49.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 00:49: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" 
X-Inumbo-ID: ce15cc80-2fce-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747122571; x=1747727371; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8Q8tBFIJ/78n7IR+9ESusw22RG0woAFAfmQbfZstPms=;
        b=Qf9czHv3MfKL5jjwALFZQpBL0x4mM10i19QHrBE/P6nrqHkM9teNFN5EfzXD7uYYMr
         S1/qznF5MnpEpCEg15yygPZ/mLYEUE3jkRDp7+qeqnaV/qdB0U5Qh4HfoQVCm4g4gzgA
         3/mj867Sia7upwbxsaAP/Q3HMdwV2kY5teIVtr2Ad0ei0sjJgEaQc2a7K4MVql0s3C85
         ng581nkHCl0KUjJRxaepEHyysNwTaEQWABacHkm36HUkzuhbbp2xJSHb/koa+AJGkDl2
         YlOfqw3vB4hRm2IWdiPQhy+D1a96AYFpuwOz8HeYfwtCqVChqk53VDYrh69UJ367RwRp
         2dug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747122571; x=1747727371;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8Q8tBFIJ/78n7IR+9ESusw22RG0woAFAfmQbfZstPms=;
        b=Dk1gfSVndbkZGeYh72UskMDCJWU/fzKrMz/DHOL9/yhaW1hwBq8Xxw3DoUnvGTDi+6
         Mh+Hyivvmvvw5ssq2QZtwpg9Szw6oP+36x40cT0TJe4Jmp3cJGGqs7XRFLJEkKtXOhNi
         9qtHsRTIzBCg0fX1rBNT8uP4W6Dv3/Xaxf1bubxHgVQSuy8Fih/7fS7T04XX5Q6LIjUD
         R5Tjb/NnEcxNkegvRBnN2Xf9gCw5eye4mpcQEbgPg1dpKhqBl5Y9iwJ2wqikN4u45FRO
         FWc2YiYCuUZvLl3Sk+NISFdb6q+qOOTjvLQkt96Rkdk6tplXO689xizD1f2mcj6kcAi0
         PmdQ==
X-Forwarded-Encrypted: i=1; AJvYcCXNEULii30LnudQE/CNoOpe95ob22yFh6oXt36TxdzrwiP+21BiYcWzijAHaXoxb7rKBpb8S1eCOjA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwFOLmBQ1unxOK4Z8Uone5idywywTL5PABgmhWl9QSAiLFLq3sF
	amitFs51gXrwJIuHERTM8AspLQDOm0R18lb+mynvFawKyTINOWWr1me3QQJSBA==
X-Gm-Gg: ASbGncvLY72MSD+FlC+Kt+4zz+EJ1sCKYGZvyRggA3EgsSL4waXTKN/GJC0x5e9E9oP
	ypFtbtRV7fp8Pthms5pgBKljZzaDf+erMofwQSWZGzzDOu+qfY9R+pSWaqwmhXouRzGzY+S3rkm
	y9TOLipIjoeDD3S98X/rLeax/WJo0ORdHf4YNNRuM3pJ950KHninXchYydMwtVU+qBxD1y19PHi
	0btnuuElSUXPHPBZO3jkifpM0USHBT7Algz02rNiWlbw1XSnCeoJs3cyr+tYsSlAN1M7uNG0LnR
	fQmobO+aXNFI0FvKmCXAShNUesVzyyNIpeTJ3h8Q7EROY/YS+3g2ShxtloL8CwLVDZZNRh3297h
	GFRfMHxWwtGrsHBVLGSTUQJN4cip74HjSkyMs
X-Google-Smtp-Source: AGHT+IFUn1qEoAKekfWLxqZl0A2abQrry/W6dUKug6Gbk+68mrAR7beuwwGZe5jItNyH5t/KMfYq1A==
X-Received: by 2002:a17:907:cf46:b0:ad2:4b93:1205 with SMTP id a640c23a62f3a-ad24b9313cdmr791165866b.41.1747122571101;
        Tue, 13 May 2025 00:49:31 -0700 (PDT)
Message-ID: 
Date: Tue, 13 May 2025 09:49:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 07/15] xen/cpufreq: fix core frequency calculation for
 AMD Family 1Ah CPUs
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-8-Penny.Zheng@amd.com>
 <8b87f6c4-ebc7-4d13-8fe6-a56df6b76523@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.05.2025 08:12, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Thursday, April 17, 2025 11:23 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> --- a/xen/arch/x86/cpu/amd.c
>>> +++ b/xen/arch/x86/cpu/amd.c
>>> @@ -570,12 +573,35 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
>>>                                                            :
>>> c->cpu_core_id);  }
>>>
>>> +static uint64_t amd_parse_freq(unsigned char c, uint64_t value)
>>
>> Considering how it's used, does "value" need to be any wider than unsigned int?
>> What about the return type?
> 
> Value is the value of 64bit PstateDef MSR, although we are only using the lower 32bit to calculate frequency
> Maybe its better to leave it as uint64_t ?

I won't insist, but changing to unsigned int will, I think, produce better
code (hence why I suggested the change).

> I'll change the return type to unsigned int, and do the following check anyhow
>         #define INVAL_FREQ_MHZ  (~(unsigned int)0)
>         if ( freq >= UINT_MAX )
>                 return INVAL_FREQ_MHZ;
>         else
>                 return (unsigned int) freq;

But please avoid such unnecessary "else" (which I think I did ask for before).

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 07:55:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 07:55:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982596.1368949 (Exim 4.92)
	(envelope-from )
	id 1uEkUS-0001tl-2E; Tue, 13 May 2025 07:55:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982596.1368949; Tue, 13 May 2025 07: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 1uEkUR-0001te-Vm; Tue, 13 May 2025 07:55:51 +0000
Received: by outflank-mailman (input) for mailman id 982596;
 Tue, 13 May 2025 07:55:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEkUQ-0001tY-Bc
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 07:55:50 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id af2ad56f-2fcf-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 09:55:49 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-acae7e7587dso832624466b.2
 for ; Tue, 13 May 2025 00:55:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad219322b57sm735605066b.41.2025.05.13.00.55.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 00:55: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" 
X-Inumbo-ID: af2ad56f-2fcf-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747122949; x=1747727749; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Nv7EWyZgim7/UFpmyR8gu9/EgRayFdRE40B009wkuaw=;
        b=TOJ3KoRI/fv8siAbedYgoK6jUz056DL92ulqK9wsDDvSmgYlLsmHXb9vL9HBGcUAsN
         IOc5628WwrSMmUk5TrPC9LBkjst/LNxo3wbaa3/QETh/Rd8WU/7kZLXItcUgRQBlG4IO
         dLI2wBu7tT5oQfTWLPAtAe80hR8C+JB3j+qlIk2mqAOh3M09s0t+firmQ+E22/KlmcFc
         EB6Qa7fwhKLESi9kGroCOGfsIRKzyqha2bFq7JEwRu0cUMkOJxcBkxz+taH7JgU56m3W
         P84z/MBK+Eg8/UjTyJ5yxn/IGQq6YAA62JB4thUCjGgVyyTzp6ggP8/mLAgpq7vYL5vl
         bO4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747122949; x=1747727749;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Nv7EWyZgim7/UFpmyR8gu9/EgRayFdRE40B009wkuaw=;
        b=ncihiJxFtTli3EqQr4RLDdcT/fZZWGIh54UaOsBPoQsFWf1g/kSABYrey5wwztXIHI
         75Z94NqKZ8nhPsxQX7HjsGMkPkhBps2n1Du6xaSZa7oaglF4+B+iOHTJhv+KfOPOqzeG
         gCA5aEpFBR+4rkKZIPC2ykhLQXnOmPCwaXitocDpuweZjcIrZvq+4y0s8M2ZyqQLBtVo
         rkFh8TLeX/gxM+C9wXncREDI15m2X/NrBrC2PgVV5Lj7f0KQ502iSIOzYp1s+lpmc8tr
         1VGt4iOkWuU5+2nVJJWOWtBz8cVDFhZkkToZirlTnyqcggzpiS8My5k+wzlxZU7XhQwZ
         FkFQ==
X-Forwarded-Encrypted: i=1; AJvYcCUKklUzaByvVhcrbIwHDSXKdNsU7W4ZYLxmjbF20PmdlumO5GS5PXOqgrJmg4zHjDWglm6ggEpJdx8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxRrkeWUuLdF+UsJZCyFKs8LRRie+h3JUus3bPVB7V+ldrnuIaZ
	KGTSUanJ63BNXEL1YWReUiKRM2TrjBwo9U2+KDgrXZ7S9wKoJ5vRXSXP55KZUQ==
X-Gm-Gg: ASbGncsIHJ2dqZNDEXIALrb069yETLp2E2vCzXcFTeRVfQvUm6Ff9D4fmW+CfTkwAgy
	qzxFyt8aF32XgX2SBe1ZaOH7Uqbto19p8HDMRjs2BnUGm2sx5akEWdN0bGUdQ7Xfby2L55H3KAa
	mJxZi9TOVkpUyiBI6A1DeFIdfcEBUscgkUJsMtx5i/3N3FsCB7YwE/kvmK8eNsxnkI/DXTPBgxR
	h6mxyRrUu29LOmY3sbywPHF/IhUtaIZQcZdQMQJjjGTFUsAU2w0oRDLrXLNIlbW8h0mvkBViXXR
	IQ/+6/eB+I6mmhR3b3bO14ZSdNMIaKQN+Hl5M3SfOTBUgkq/tAAeR1+ytjnJwtGk/Y0fkjekSVK
	WIYdXe6YEsHE9yE9ReSd6dD7SqlfMi/O+7hx2
X-Google-Smtp-Source: AGHT+IH3WH6+vs185lqNL2X+6afgvMgV3fsbKDwV80d9gUiM0//4gz1AhJL2lPn7ped27Ju5Zhd9Ww==
X-Received: by 2002:a17:907:7da2:b0:ace:3a1b:d3d with SMTP id a640c23a62f3a-ad218ea82a1mr1540242066b.2.1747122948792;
        Tue, 13 May 2025 00:55:48 -0700 (PDT)
Message-ID: 
Date: Tue, 13 May 2025 09:55:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 09/15] xen/x86: introduce a new amd cppc driver for
 cpufreq scaling
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-10-Penny.Zheng@amd.com>
 <448d6036-09ad-4505-800d-47606e8a3274@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07.05.2025 11:19, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Tuesday, April 29, 2025 10:29 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
>>> +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
>>> +/*
>>> + * If CPPC lowest_freq and nominal_freq registers are exposed then we
>>> +can
>>> + * use them to convert perf to freq and vice versa. The conversion is
>>> + * extrapolated as an linear function passing by the 2 points:
>>> + *  - (Low perf, Low freq)
>>> + *  - (Nominal perf, Nominal freq)
>>> + */
>>> +static int amd_cppc_khz_to_perf(const struct amd_cppc_drv_data *data,
>>> +                                unsigned int freq, uint8_t *perf) {
>>> +    const struct xen_processor_cppc *cppc_data = data->cppc_data;
>>> +    uint64_t mul, div;
>>> +    int offset = 0, res;
>>> +
>>> +    if ( freq == (cppc_data->cpc.nominal_mhz * 1000) )
>>> +    {
>>> +        *perf = data->caps.nominal_perf;
>>> +        return 0;
>>> +    }
>>> +
>>> +    if ( freq == (cppc_data->cpc.lowest_mhz * 1000) )
>>> +    {
>>> +        *perf = data->caps.lowest_perf;
>>> +        return 0;
>>> +    }
>>
>> How likely is it that these two early return paths are taken, when the incoming
>> "freq" is 25 or 5 MHz granular? IOW - is it relevant to shortcut these two cases?
>>
> 
> Sorry, I may not understand what you mean here.
> Answering " How likely is it that these two early return paths are taken "
> It's rare ig.... maybe *ondemand* governor will frequently give frequency around nominal frequency,
> but the exact value is rare ig.
> I'm confused about " when the incoming  "freq" is 25 or 5 MHz granular ".
> Are we talking about is it worthy to have these two early return paths considering it is rarely taken

Yes - why have extra code which is expected to be hardly ever used. Things
would be different if such shortcuts covered common cases.

>>> +static int amd_get_max_freq(const struct amd_cppc_drv_data *data,
>>> +                            unsigned int *max_freq) {
>>> +    unsigned int nom_freq = 0, boost_ratio;
>>> +    int res;
>>> +
>>> +    res = amd_get_lowest_or_nominal_freq(data,
>>> +                                         data->cppc_data->cpc.nominal_mhz,
>>> +                                         data->caps.nominal_perf,
>>> +                                         &nom_freq);
>>> +    if ( res )
>>> +        return res;
>>> +
>>> +    boost_ratio = (unsigned int)(data->caps.highest_perf /
>>> +                                 data->caps.nominal_perf);
>>
>> I may have seen logic ensuring nominal_perf isn't 0, so that part may be fine. What
>> guarantees this division to yield a positive value, though?
>> If it yields zero (say 0xff / 0x80), ...
> 
> I think maybe you were saying 0x80/0xff to yield zero value. For that, we checked that highest_perf
> must not be smaller than nominal_perf during init, see ...

No, I indeed meant 0xff / 0x80, but yes, that will yield 1, not 0. My main
point though was about this calculation being pretty far off the real value
(rather closer to 2), i.e. in the overall calculation (including ...

>>> +    *max_freq = nom_freq * boost_ratio;

... this multiplication) some scaling may want introducing, or the
multiplication may want doing ahead of the division.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 08:03:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 08:03:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982608.1368958 (Exim 4.92)
	(envelope-from )
	id 1uEkbR-0004Db-Sh; Tue, 13 May 2025 08:03:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982608.1368958; Tue, 13 May 2025 08:03: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 1uEkbR-0004DU-QD; Tue, 13 May 2025 08:03:05 +0000
Received: by outflank-mailman (input) for mailman id 982608;
 Tue, 13 May 2025 08:03:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEkbQ-0004DO-TG
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 08:03:04 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b2113946-2fd0-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 10:03:03 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5faaddb09feso10576880a12.2
 for ; Tue, 13 May 2025 01:03: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
 a640c23a62f3a-ad2406eeadasm483804166b.97.2025.05.13.01.03.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 01:03: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" 
X-Inumbo-ID: b2113946-2fd0-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747123383; x=1747728183; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=m1m9swlxKhyehhxIC3pQfEf5rgn7GIpkaqgV9FzyeqQ=;
        b=ZllGngM7VShLEg3af/cGoJJjDfYW+KrFD+F697Ne53ofsyAMpHjch0GQi9F0Txc95N
         wkAAUcXO05PaxQhN1IUdCXLbf7uUjaMFTqJ/PJyT1DnXZf/Z7NXrJUoFC25Z+JQ/xV7t
         J3tJbB2Q1gnvl4MNq07ewjrAnNndtvLzD4XxFe23d+SCucMtbycCXAvndNXITxIo2qBJ
         FV0K0uWhF9QZaQTRN329o9sHnDP1Uer3tsD+whiC/9/2a0YuRENUUxJsHjW2/ovKVioY
         6OjvSYYjtAIXRITYe0Z3hCdSfKy5XPUIGWSpQZrc9/tzLfv6E/w37dzucd+dIBuorLCO
         f1XA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747123383; x=1747728183;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=m1m9swlxKhyehhxIC3pQfEf5rgn7GIpkaqgV9FzyeqQ=;
        b=KJ3vbby3aifuupeEn/y0FlL2fbNwfNJ1vFZ37r6h1mBPZNg0AdNjnAEtRg/UPl/rVr
         8zwIldgd1jVlY37luCJ4SmfB2ltvv+YCA9jgBj56Td836Y2iEG5YAPKPaPckvAMWG1NZ
         dx0lXL+rxNjwamYxDcLU36WNMzKRGA+vYhlGnErGS6tII0CHzq2Nu3TjN++XgWtM8YAc
         PUdg5LWCSobbd5GcXR+3mlzP26n2LXoRyiaX/8QILPT0RjsbEFjKrrNChTWuYpjg9/WV
         5rxwRxoIJJJGPNgmhggd/I8BqDkdIJsdk4bvhy7FDis6c0mhJfDWN5Mv2xQMF9WLHadX
         RiNQ==
X-Forwarded-Encrypted: i=1; AJvYcCW3DJmtihiWLMjyRrbzws+6tSHwxSLI5kR9BqesaIKQY3y7N4xWPCipmOqxwpiaPmb6BK8KznUWToA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzo/MsaX/cQVea3/Wnkgbx0LjO2s8kKnyW94pjLwTtpj0A4JEQ+
	6nShg3w6rcnC4JidVpruHeGlE8/cZCQYpMghUV1WtkMgrMQ3rgT9H7nVmTMcGqZNchbSVAcA7ns
	=
X-Gm-Gg: ASbGnctgwkkK4N9tfGSWzkDapFLx11/WOfc7ks4dcEcYm21gbd0lVJhSpuDI411GkGp
	ayZ2u51zwjxoz/WDfStl7IOSvlHf4MXaB3KizlHEQ64m6tYtA35id3Qs7EX5z3ES+axTjFJcOV6
	VQjNthV9MIarbg/ZZlbHiBjXbq9uuLgg7rKyyRAl98uEPnKjtB6cqjdp/OXAMuNrZJLSSEmMu/U
	QQ20NbuMvqXrgT4EKjDXm/ldgbIX3abJ3/vaffFhOKD+u/AN+Y19p6IZc73/+7ZY4ydSsaFZmYy
	eqxaUGeGErZlDe/Zbccjuiy8jVEMnr3UCn2rGozIIb0ud4YqlDOS38LZ9W5V9E1/FmqFH/MOR+b
	YCERcoALgswXjdRXR2tWcLsD/Hz+IciMjePEs
X-Google-Smtp-Source: AGHT+IH7BQaa5iSi90dldaCQe+ofINMskpGyVyQYUXrJUeyD+eWdWmx8x5W9iAHX2UzCQduapuZs0g==
X-Received: by 2002:a17:906:4ecc:b0:ad2:1b50:891b with SMTP id a640c23a62f3a-ad21b509698mr1217876466b.52.1747123383013;
        Tue, 13 May 2025 01:03:03 -0700 (PDT)
Message-ID: <75679a60-7ca0-41da-b542-c5b9d5efdfbe@suse.com>
Date: Tue, 13 May 2025 10:03:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 12/15] tools/xenpm: Print CPPC parameters for amd-cppc
 driver
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Anthony PERARD ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-13-Penny.Zheng@amd.com>
 <63b3b016-551c-4201-a3b3-db19b27ea649@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 08:36, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Wednesday, April 30, 2025 9:55 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> HWP, amd-cppc, amd-cppc-epp are all the implementation of ACPI CPPC
>>> (Collaborative Processor Performace Control), so we introduce
>>> cppc_mode flag to print CPPC-related para.
>>>
>>> And HWP and amd-cppc-epp are both governor-less driver, so we
>>> introduce hw_auto flag to bypass governor-related print.
>>
>> But in the EPP driver you use the information which governor is active.
> 
> We want to have a one-one mapping between governor and epp value, such as,
> If users choose performance governor, no matter via "xenpm" or cmdline, users want maximum performance,
> We set epp with 0 to meet the expectation.
> And if users choose powersave governor, users want the least power consumption, then we shall set
> epp with 255 to meet the expectation.

That's all fine, but completely misses the point of my question: If the
governor is relevant, why would you bypass respective printing?

> Ondemand is a tricky part, hmmmm, I don't know which value is suitable for it, the medium one? So I neglect it in the first place

Medium one may be okay-ish, but it's not really an appropriate fit. We may
want to at least consider rejecting the use of ondemand with the EPP driver.
That, however, heavily depends on how hardware would behave when using the
medium value.

>>> --- a/tools/misc/xenpm.c
>>> +++ b/tools/misc/xenpm.c
>>> @@ -790,9 +790,18 @@ static unsigned int
>>> calculate_activity_window(const xc_cppc_para_t *cppc,
>>>  /* print out parameters about cpu frequency */  static void
>>> print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
>>> {
>>> -    bool hwp = strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME)
>> == 0;
>>> +    bool cppc_mode = false, hw_auto = false;
>>>      int i;
>>>
>>> +    if ( !strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) ||
>>> +         !strcmp(p_cpufreq->scaling_driver, XEN_AMD_CPPC_DRIVER_NAME) ||
>>> +         !strcmp(p_cpufreq->scaling_driver,
>> XEN_AMD_CPPC_EPP_DRIVER_NAME) )
>>> +        cppc_mode = true;
>>> +
>>> +    if ( !strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) ||
>>> +         !strcmp(p_cpufreq->scaling_driver,
>> XEN_AMD_CPPC_EPP_DRIVER_NAME) )
>>> +        hw_auto = true;
>>
>> Please avoid doing the same strcmp()s twice. There are several ways how to, so
>> I'm not going to make a particular suggestion.
> 
> Maybe we shall use switch-case() to replace the same strcmp()s
> Since it's not easy to switch-case() string value, I had a draft idea to include an new entry in "struct xen_cppc_para",
> See:
> ```
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index fa431fd983..b872f1b66a 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -308,6 +308,10 @@ struct xen_ondemand {
> 
>  struct xen_cppc_para {
>      /* OUT */
> +#define XEN_SYSCTL_CPPC_VENDOR_HWP      1
> +#define XEN_SYSCTL_CPPC_VENDOR_AMD      2
> +#define XEN_SYSCTL_CPPC_VENDOR_AMD_EPP  3
> +    uint8_t vendor;
>      /* activity_window supported if set */
>  #define XEN_SYSCTL_CPPC_FEAT_ACT_WINDOW  (1 << 0)
>      uint32_t features; /* bit flags for features */
> 
> ```
> A new vendor filed in struct xen_cppc_para could help us differ the underlying implementation.
> Or any better suggestions?

Well, if you set hw_auto first, then you can use that variable plus one
more strcmp() to set cppc_mode.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 08:05:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 08:05:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982615.1368968 (Exim 4.92)
	(envelope-from )
	id 1uEkdX-0004k5-7I; Tue, 13 May 2025 08:05:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982615.1368968; Tue, 13 May 2025 08: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 1uEkdX-0004jy-4i; Tue, 13 May 2025 08:05:15 +0000
Received: by outflank-mailman (input) for mailman id 982615;
 Tue, 13 May 2025 08:05:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEkdW-0004jq-Bk
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 08:05:14 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id febdeaa5-2fd0-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 10:05:12 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad220f139adso668911066b.1
 for ; Tue, 13 May 2025 01:05: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
 a640c23a62f3a-ad2197bd3easm746030766b.147.2025.05.13.01.05.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 01:05: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" 
X-Inumbo-ID: febdeaa5-2fd0-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747123512; x=1747728312; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Qhc7KU2TkVmWCuYhyiKWn2JMdy9m2ONo+uhDFAimjcs=;
        b=NV4lymZWhBKIwr+/Eh0wh9igPS9hV3DBxBtW3yyBl3BAz2jZUvO3G0Zu5VftIeAP3B
         rPTRPcINRCHuH4J1eLaPr6+pjkcKMtSILbjDQ+Zb0UoU7v/I3BWDkRI+TT4FaCq0rBje
         elwo1zPBV8ooD2avU1eX8Pe3b4ZXSvvY7VwIUjgVE7QidOBnL2alaC5C49Oo5W2wiu4x
         mUwZMdRBHbhe73cp5cM8VT8HQw2FfhtO9V5L4nf0KV4/l8Fqi843ZJr9O39RrG/mZZED
         vR9dgLBjtjSG4mAydSbs0oWf6zEPUe71dUgGQ4yjI18fPLPoYUmFoKOFFidH5aOlkNoL
         Zy+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747123512; x=1747728312;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Qhc7KU2TkVmWCuYhyiKWn2JMdy9m2ONo+uhDFAimjcs=;
        b=PJa7lKgK+kIz56Fu/ylwNk2C/tI1JzgUXjmUhikrVaZ5GRFhvDyG3PEaPYfqKqguIS
         WK2CDhMVkWyMhq0TX85uQWbB3Zas6iz3RyHrEepXgqSS53XUifXFRzjbbt6ODOwi2MYk
         EvxGNING6fijnjoerZeGHM873JdCw2HDO1DBNuowjX2HJrkAMwfLlR4eoSGu2tvL7fbH
         BrfhZCb5Fiinwym1fwtCSqa4hb493k5nJHzsAWT3lLjfjYMqDqr/F+A9UeTtOtwZKFRi
         esV4BvHpTubL9xekAw8cpdXMpmobCGF3ehFVUdfaQANG60bwRMWrjeRGBB+AJcLYMr3u
         8Hqw==
X-Forwarded-Encrypted: i=1; AJvYcCVLlyk47hYZJEOv5gFFq9mSim/aJ+pxCMkgnk21gHmgE7EfRUA4LSRhhmZ85Jtw/vybORhTeO8d+aU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzY+kOIG/qthQGNBphvEcSSM0ctfRjhLmnfcDQSVBx7vMbl3d6u
	MOmtPMKQQ8IXTYKRr5GmIcyJyEBjC0781nhBoGDyN10VAK+gVGJ16MIt36vubg==
X-Gm-Gg: ASbGnctRpZs95KCgc+pby6JFyXu5a/39CFfrllopcy37p31bhb1YHFdAq3y4i7QkKxi
	W2G+arHjRYAwbm+JqR1h08EA8QG8/B10p4yfZpMQhIxvlAK93t3pX117SVAFsIzv4+qZZxhoryt
	W+9X77xcYQAwXpIaffzyGuu1mRhYiX2qvuRBc5btB/SUKxnwXf0ku+q6pps+SMP8edKujZmLAVF
	+BPDrk4P74ZQZ4A+64Tmu3g3+wMyxABBBGjLa/gj+DKpZZs6Jbd82Pn8xoNOS/SljBIBm1Mvy0h
	VEymRJevZyX5debkW3QxJwfhlz7IdOiX0euDGMKoeOFJWkk+B9ofU36/s9P6+1uG7ZwijUzP3kL
	RA/GAAXct2tjyOPiQTMvQDWCTuHetO/EMHS5p
X-Google-Smtp-Source: AGHT+IGdpkV1rXfWFW5ArV5p4x5mkMBmQVRGiazEKUYiqL7e/hqzy2KHwOgPazQM+Wj2IUhzpEiSGg==
X-Received: by 2002:a17:907:d30a:b0:ac7:3817:d8da with SMTP id a640c23a62f3a-ad2192b5b2dmr1439829566b.52.1747123511686;
        Tue, 13 May 2025 01:05:11 -0700 (PDT)
Message-ID: 
Date: Tue, 13 May 2025 10:05:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 02/12] common/hyperlaunch: introduce the domain builder
To: "Daniel P. Smith" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Jason Andryuk , Denis Mukhin ,
 Alejandro Vallejo , xen-devel@lists.xenproject.org
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-3-agarciav@amd.com>
 <9021c878-9605-4d6e-95b8-ab97da186542@apertussolutions.com>
 <29a55d44-c26e-4834-b93b-47cbd98f885e@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 21:29, Daniel P. Smith wrote:
> On 5/2/25 03:21, Jan Beulich wrote:
>> On 30.04.2025 20:56, Daniel P. Smith wrote:
>>> On 4/29/25 08:36, Alejandro Vallejo wrote:
>>>> --- a/xen/common/Makefile
>>>> +++ b/xen/common/Makefile
>>>> @@ -11,6 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
>>>>    obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
>>>>    obj-$(CONFIG_IOREQ_SERVER) += dm.o
>>>>    obj-y += domain.o
>>>> +obj-$(CONFIG_DOMAIN_BUILDER) += domain-builder/
>>>
>>> Please don't do this, use IF_ENABLED in core.c and then hide the
>>> unnecessary units in domain-builder/Makefile as I originally had it.
>>> This allows for a much easier time incrementally converting the dom0
>>> construction path into a generalized domain construction path.
>>
>> That is, are you viewing this as a transitional thing only? If the end
>> goal is to have it as Alejandro has it above, that may be acceptable
>> (even if not nice).
> 
> There is/will be shared domain construction code between dom0-only and 
> multidomain construction, with it will all living under domain builder. 
> So no, the end goal is not what Alejandro just did. The end result will 
> be the way I had it, with a different kconfig option to enable/disable 
> the multidomain construction path.

Isn't CONFIG_DOMAIN_BUILDER a misnomer then?

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 08:45:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 08:45:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982634.1369019 (Exim 4.92)
	(envelope-from )
	id 1uElGr-0002ek-W9; Tue, 13 May 2025 08:45:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982634.1369019; Tue, 13 May 2025 08: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 1uElGr-0002ed-Rs; Tue, 13 May 2025 08:45:53 +0000
Received: by outflank-mailman (input) for mailman id 982634;
 Tue, 13 May 2025 08:45:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uElGr-0001kc-6r
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 08:45:53 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id abe8feea-2fd6-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 10:45:50 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D93B7168F;
 Tue, 13 May 2025 01:45:39 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D85C33F5A1;
 Tue, 13 May 2025 01:45: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" 
X-Inumbo-ID: abe8feea-2fd6-11f0-9ffb-bf95429c2676
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v5 4/6] arm/mpu: Provide access to the MPU region from the C code
Date: Tue, 13 May 2025 09:45:30 +0100
Message-Id: <20250513084532.4059388-5-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250513084532.4059388-1-luca.fancellu@arm.com>
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement some utility function in order to access the MPU regions
from the C world.

Signed-off-by: Luca Fancellu 
---
v5 changes:
 - move MPU_REGION_RES0 to arm64, fixed typos and code style.
v4 changes:
 - moved back PRBAR0_EL2/PRLAR0_EL2 to mm.c and protect
   them with CONFIG_ARM_64, changed comments, fixed typos and code
   style
 - Add PRBAR_EL2_(n) definition, to be overriden by Arm32
 - protect prepare_selector, read_protection_region,
   write_protection_region by Arm64 to ensure compilation on both
   arm32 and arm64, Arm32 will modify that later while introducing
   the arm32 bits.
v3 changes:
 - Moved PRBAR0_EL2/PRLAR0_EL2 to arm64 specific
 - Modified prepare_selector() to be easily made a NOP
   for Arm32, which can address up to 32 region without
   changing selector and it is also its maximum amount
   of MPU regions.
---
---
 xen/arch/arm/include/asm/arm64/mpu.h |   2 +
 xen/arch/arm/include/asm/mpu/mm.h    |  34 ++++++++
 xen/arch/arm/mpu/mm.c                | 119 +++++++++++++++++++++++++++
 3 files changed, 155 insertions(+)

diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h
index d3c055a2e53b..0fed6c8e5828 100644
--- a/xen/arch/arm/include/asm/arm64/mpu.h
+++ b/xen/arch/arm/include/asm/arm64/mpu.h
@@ -5,6 +5,8 @@
 
 #ifndef __ASSEMBLY__
 
+#define MPU_REGION_RES0        (0xFFFFULL << 48)
+
 /* Protection Region Base Address Register */
 typedef union {
     struct __packed {
diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
index 409b4dd53dc6..2ee908801665 100644
--- a/xen/arch/arm/include/asm/mpu/mm.h
+++ b/xen/arch/arm/include/asm/mpu/mm.h
@@ -41,6 +41,40 @@ static inline struct page_info *virt_to_page(const void *v)
     return mfn_to_page(mfn);
 }
 
+/* Utility function to be used whenever MPU regions are modified */
+static inline void context_sync_mpu(void)
+{
+    /*
+     * ARM DDI 0600B.a, C1.7.1
+     * Writes to MPU registers are only guaranteed to be visible following a
+     * Context synchronization event and DSB operation.
+     */
+    dsb(sy);
+    isb();
+}
+
+/*
+ * The following API requires context_sync_mpu() after being used to modify MPU
+ * regions:
+ *  - write_protection_region
+ */
+
+/*
+ * Reads the MPU region with index @sel from the HW.
+ *
+ * @pr_read: mpu protection region returned by read operation.
+ * @sel: which mpu protection region to read
+ */
+void read_protection_region(pr_t *pr_read, uint8_t sel);
+
+/*
+ * Writes the MPU region with index @sel to the HW.
+ *
+ * @pr_write: mpu protection region passed through write operation.
+ * @sel: which mpu protection region to write
+ */
+void write_protection_region(const pr_t *pr_write, uint8_t sel);
+
 #endif /* __ARM_MPU_MM_H__ */
 
 /*
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index ee035a54b942..46883cbd4af9 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 struct page_info *frame_table;
 
@@ -26,6 +28,35 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
 /* EL2 Xen MPU memory region mapping table. */
 pr_t __section(".data.page_aligned") xen_mpumap[MAX_MPU_REGION_NR];
 
+#ifdef CONFIG_ARM_64
+/*
+ * The following are needed for the cases: GENERATE_WRITE_PR_REG_CASE
+ * and GENERATE_READ_PR_REG_CASE with num==0
+ */
+#define PRBAR0_EL2 PRBAR_EL2
+#define PRLAR0_EL2 PRLAR_EL2
+
+#define PRBAR_EL2_(n)   PRBAR##n##_EL2
+#define PRLAR_EL2_(n)   PRLAR##n##_EL2
+
+#endif
+
+#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
+    case num:                                                               \
+    {                                                                       \
+        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
+        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
+        break;                                                              \
+    }
+
+#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
+    case num:                                                   \
+    {                                                           \
+        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
+        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
+        break;                                                  \
+    }
+
 static void __init __maybe_unused build_assertions(void)
 {
     /*
@@ -36,6 +67,94 @@ static void __init __maybe_unused build_assertions(void)
     BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
 }
 
+#ifdef CONFIG_ARM_64
+/*
+ * Armv8-R supports direct access and indirect access to the MPU regions through
+ * registers:
+ *  - indirect access involves changing the MPU region selector, issuing an isb
+ *    barrier and accessing the selected region through specific registers
+ *  - direct access involves accessing specific registers that point to
+ *    specific MPU regions, without changing the selector, avoiding the use of
+ *    a barrier.
+ * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR_ELx (for n=1..15) are
+ * used for the direct access to the regions selected by
+ * PRSELR_EL2.REGION<7:4>:n, so 16 regions can be directly accessed when the
+ * selector is a multiple of 16, giving access to all the supported memory
+ * regions.
+ */
+static void prepare_selector(uint8_t *sel)
+{
+    uint8_t cur_sel = *sel;
+
+    /*
+     * {read,write}_protection_region works using the direct access to the 0..15
+     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
+     * only when needed, so when the upper 4 bits of the selector will change.
+     */
+    cur_sel &= 0xF0U;
+    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
+    {
+        WRITE_SYSREG(cur_sel, PRSELR_EL2);
+        isb();
+    }
+    *sel = *sel & 0xFU;
+}
+
+void read_protection_region(pr_t *pr_read, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_READ_PR_REG_CASE(0, pr_read);
+        GENERATE_READ_PR_REG_CASE(1, pr_read);
+        GENERATE_READ_PR_REG_CASE(2, pr_read);
+        GENERATE_READ_PR_REG_CASE(3, pr_read);
+        GENERATE_READ_PR_REG_CASE(4, pr_read);
+        GENERATE_READ_PR_REG_CASE(5, pr_read);
+        GENERATE_READ_PR_REG_CASE(6, pr_read);
+        GENERATE_READ_PR_REG_CASE(7, pr_read);
+        GENERATE_READ_PR_REG_CASE(8, pr_read);
+        GENERATE_READ_PR_REG_CASE(9, pr_read);
+        GENERATE_READ_PR_REG_CASE(10, pr_read);
+        GENERATE_READ_PR_REG_CASE(11, pr_read);
+        GENERATE_READ_PR_REG_CASE(12, pr_read);
+        GENERATE_READ_PR_REG_CASE(13, pr_read);
+        GENERATE_READ_PR_REG_CASE(14, pr_read);
+        GENERATE_READ_PR_REG_CASE(15, pr_read);
+    default:
+        BUG(); /* Can't happen */
+    }
+}
+
+void write_protection_region(const pr_t *pr_write, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
+    default:
+        BUG(); /* Can't happen */
+    }
+}
+#endif
+
 void __init setup_mm(void)
 {
     BUG_ON("unimplemented");
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 13 08:45:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 08:45:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982630.1368979 (Exim 4.92)
	(envelope-from )
	id 1uElGo-0001ky-4s; Tue, 13 May 2025 08:45:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982630.1368979; Tue, 13 May 2025 08:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uElGo-0001kr-27; Tue, 13 May 2025 08:45:50 +0000
Received: by outflank-mailman (input) for mailman id 982630;
 Tue, 13 May 2025 08:45:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uElGn-0001kb-1W
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 08:45:49 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id a8f38ada-2fd6-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 10:45:45 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 390F4168F;
 Tue, 13 May 2025 01:45:34 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 36F203F5A1;
 Tue, 13 May 2025 01:45: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" 
X-Inumbo-ID: a8f38ada-2fd6-11f0-9eb6-5ba50f476ded
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v5 0/6] First chunk for Arm R82 and MPU support
Date: Tue, 13 May 2025 09:45:26 +0100
Message-Id: <20250513084532.4059388-1-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi all,

This is the first chunk of work to support MPU and R82 on Xen, this serie
reaches the early boot stages just before early_fdt_map(), just to give an idea
about which stage of the boot is reached.

v5:
 - dropped patch that touches page.h, it is not needed
 - general fixes listed on each patch
v4:
 - dropped setup_mpu() patch and early_fdt_map() patch (needs rework)
 - add new patches: boot protocol and early asm MPU structure update
 - general fixes listed on each patch
v3 changes:
 - stated on each patch
v2 changes for this serie:
 - rebased serie on the MPU skeleton that allow compilation
 - removed some patches already merged in the MPU skeleton

Luca Fancellu (5):
  docs/arm: Document Xen booting protocol on Armv8-R
  arm/mpu: Provide and populate MPU C data structures
  arm/mpu: Provide access to the MPU region from the C code
  arm/mpu: Introduce utility functions for the pr_t type
  arm/mpu: Provide a constructor for pr_t type

Penny Zheng (1):
  arm/mpu: Introduce MPU memory region map structure

 docs/misc/arm/booting.txt                |  11 +-
 xen/arch/arm/arm64/mpu/head.S            |  13 ++
 xen/arch/arm/include/asm/arm32/mpu.h     |  25 +++
 xen/arch/arm/include/asm/arm64/mpu.h     |  54 ++++++
 xen/arch/arm/include/asm/bitmap-op.inc   |  67 ++++++++
 xen/arch/arm/include/asm/mpu.h           |  74 +++++++++
 xen/arch/arm/include/asm/mpu/mm.h        |  51 ++++++
 xen/arch/arm/include/asm/mpu/regions.inc |  49 ++++++
 xen/arch/arm/mpu/mm.c                    | 201 +++++++++++++++++++++++
 9 files changed, 542 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/arm/include/asm/arm32/mpu.h
 create mode 100644 xen/arch/arm/include/asm/arm64/mpu.h
 create mode 100644 xen/arch/arm/include/asm/bitmap-op.inc

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 13 08:45:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 08:45:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982636.1369039 (Exim 4.92)
	(envelope-from )
	id 1uElGv-0003Bp-J8; Tue, 13 May 2025 08:45:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982636.1369039; Tue, 13 May 2025 08:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uElGv-0003Be-FD; Tue, 13 May 2025 08:45:57 +0000
Received: by outflank-mailman (input) for mailman id 982636;
 Tue, 13 May 2025 08:45:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uElGt-0001kc-GM
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 08:45:55 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id ad61163f-2fd6-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 10:45:52 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 70EE5176A;
 Tue, 13 May 2025 01:45:42 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6F38F3F5A1;
 Tue, 13 May 2025 01:45: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" 
X-Inumbo-ID: ad61163f-2fd6-11f0-9ffb-bf95429c2676
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v5 6/6] arm/mpu: Provide a constructor for pr_t type
Date: Tue, 13 May 2025 09:45:32 +0100
Message-Id: <20250513084532.4059388-7-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250513084532.4059388-1-luca.fancellu@arm.com>
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Provide a function that creates a pr_t object from a memory
range and some attributes.

Signed-off-by: Luca Fancellu 
---
v5 changes:
 - removed AP_RW_EL2 used only by pr_of_xenaddr(), fixed
   comments and typos
 - Given some comments to the page.h flags and modifications
   to the prbar_t fields ap, xn, the constructor now takes
   flags instead of attr_idx, which I believe it's better,
   deleted PRBAR_EL2_XN_ENABLED since now the PAGE_XN_MASK()
   is used instead.
 - renamed to pr_of_addr since it will be used also in p2m
v4 changes:
 - update helper comments
 - rename XN_EL2_ENABLED to PRBAR_EL2_XN_ENABLED
 - protected pr_of_xenaddr() with #ifdef Arm64 until Arm32
   can build with it
---
 xen/arch/arm/include/asm/mpu/mm.h | 10 +++++
 xen/arch/arm/mpu/mm.c             | 66 +++++++++++++++++++++++++++++++
 2 files changed, 76 insertions(+)

diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
index 2ee908801665..f0facee51692 100644
--- a/xen/arch/arm/include/asm/mpu/mm.h
+++ b/xen/arch/arm/include/asm/mpu/mm.h
@@ -75,6 +75,16 @@ void read_protection_region(pr_t *pr_read, uint8_t sel);
  */
 void write_protection_region(const pr_t *pr_write, uint8_t sel);
 
+/*
+ * Creates a pr_t structure describing a protection region.
+ *
+ * @base: base address as base of the protection region.
+ * @limit: exclusive address as limit of the protection region.
+ * @flags: memory flags for the mapping.
+ * @return: pr_t structure describing a protection region.
+ */
+pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags);
+
 #endif /* __ARM_MPU_MM_H__ */
 
 /*
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 46883cbd4af9..ac83227e607e 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct page_info *frame_table;
@@ -153,6 +154,71 @@ void write_protection_region(const pr_t *pr_write, uint8_t sel)
         BUG(); /* Can't happen */
     }
 }
+
+pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
+{
+    unsigned int attr_idx = PAGE_AI_MASK(flags);
+    prbar_t prbar;
+    prlar_t prlar;
+    pr_t region;
+
+    /* Build up value for PRBAR_EL2. */
+    prbar = (prbar_t) {
+        .reg = {
+            .ro = PAGE_RO_MASK(flags),
+            .xn = PAGE_XN_MASK(flags),
+        }};
+
+    switch ( attr_idx )
+    {
+    /*
+     * ARM ARM: Shareable, Inner Shareable, and Outer Shareable Normal memory
+     * (DDI 0487L.a B2.10.1.1.1 Note section):
+     *
+     * Because all data accesses to Non-cacheable locations are data coherent
+     * to all observers, Non-cacheable locations are always treated as Outer
+     * Shareable
+     *
+     * ARM ARM: Device memory (DDI 0487L.a B2.10.2)
+     *
+     * All of these memory types have the following properties:
+     * [...]
+     *  - Data accesses to memory locations are coherent for all observers in
+     *    the system, and correspondingly are treated as being Outer Shareable
+     */
+    case MT_NORMAL_NC:
+        /* Fall through */
+    case MT_DEVICE_nGnRnE:
+        /* Fall through */
+    case MT_DEVICE_nGnRE:
+        prbar.reg.sh = LPAE_SH_OUTER;
+        break;
+    default:
+        /* Xen mappings are SMP coherent */
+        prbar.reg.sh = LPAE_SH_INNER;
+        break;
+    }
+
+    /* Build up value for PRLAR_EL2. */
+    prlar = (prlar_t) {
+        .reg = {
+            .ns = 0,        /* Hyp mode is in secure world */
+            .ai = attr_idx,
+            .en = 1,        /* Region enabled */
+        }};
+
+    /* Build up MPU memory region. */
+    region = (pr_t) {
+        .prbar = prbar,
+        .prlar = prlar,
+    };
+
+    /* Set base address and limit address. */
+    pr_set_base(®ion, base);
+    pr_set_limit(®ion, limit);
+
+    return region;
+}
 #endif
 
 void __init setup_mm(void)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 13 08:45:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 08:45:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982633.1369000 (Exim 4.92)
	(envelope-from )
	id 1uElGp-00024J-RT; Tue, 13 May 2025 08:45:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982633.1369000; Tue, 13 May 2025 08:45: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 1uElGp-00022G-K1; Tue, 13 May 2025 08:45:51 +0000
Received: by outflank-mailman (input) for mailman id 982633;
 Tue, 13 May 2025 08:45:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uElGp-0001kb-2u
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 08:45:51 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id ab81f1b0-2fd6-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 10:45:49 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 92A16176A;
 Tue, 13 May 2025 01:45:38 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9202E3F5A1;
 Tue, 13 May 2025 01:45: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" 
X-Inumbo-ID: ab81f1b0-2fd6-11f0-9eb6-5ba50f476ded
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v5 3/6] arm/mpu: Provide and populate MPU C data structures
Date: Tue, 13 May 2025 09:45:29 +0100
Message-Id: <20250513084532.4059388-4-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250513084532.4059388-1-luca.fancellu@arm.com>
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Provide some data structure in the C world to track the MPU
status, these structures will be filled at boot by the assembly
early code with the boot MPU regions and afterwards they will be
used at runtime.

Provide methods to update a bitmap created with DECLARE_BITMAP
from the assembly code for both Arm32 and Arm64.

Modify Arm64 assembly boot code to reset any unused MPU region,
initialise 'max_mpu_regions' with the number of supported MPU
regions and modify the common asm macro 'prepare_xen_region' to
load into xen_mpumap the MPU status and set/clear the bitmap
'xen_mpumap_mask' used to track the enabled regions.

Provide a stub implementation for the pr_t type and few asm
macro for the Arm32 to prevent compilation break, they will
be implemented later.

Signed-off-by: Luca Fancellu 
---
v5 changes:
 - changed variable name from 'max_xen_mpumap' to 'max_mpu_regions'
 - code style fixes
 - reverted back changes about parameter name of prepare_xen_region
 - optimised address computation for xen_mpumap entries
 - modified MAX_MPU_REGION_NR
v4 changes:
 - new patch
---
 xen/arch/arm/arm64/mpu/head.S            | 13 +++++
 xen/arch/arm/include/asm/arm32/mpu.h     | 25 +++++++++
 xen/arch/arm/include/asm/bitmap-op.inc   | 67 ++++++++++++++++++++++++
 xen/arch/arm/include/asm/mpu.h           |  5 ++
 xen/arch/arm/include/asm/mpu/mm.h        |  7 +++
 xen/arch/arm/include/asm/mpu/regions.inc | 49 +++++++++++++++++
 xen/arch/arm/mpu/mm.c                    | 16 ++++++
 7 files changed, 182 insertions(+)
 create mode 100644 xen/arch/arm/include/asm/arm32/mpu.h
 create mode 100644 xen/arch/arm/include/asm/bitmap-op.inc

diff --git a/xen/arch/arm/arm64/mpu/head.S b/xen/arch/arm/arm64/mpu/head.S
index 6d336cafbbaf..59ddc46526eb 100644
--- a/xen/arch/arm/arm64/mpu/head.S
+++ b/xen/arch/arm/arm64/mpu/head.S
@@ -40,6 +40,9 @@ FUNC(enable_boot_cpu_mm)
     mrs   x5, MPUIR_EL2
     and   x5, x5, #NUM_MPU_REGIONS_MASK
 
+    ldr   x0, =max_mpu_regions
+    strb  w5, [x0]
+
     /* x0: region sel */
     mov   x0, xzr
     /* Xen text section. */
@@ -74,6 +77,16 @@ FUNC(enable_boot_cpu_mm)
     prepare_xen_region x0, x1, x2, x3, x4, x5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
 #endif
 
+zero_mpu:
+    /* Reset remaining MPU regions */
+    cmp   x0, x5
+    beq   out_zero_mpu
+    mov   x1, #0
+    mov   x2, #1
+    prepare_xen_region x0, x1, x2, x3, x4, x5, attr_prlar=REGION_DISABLED_PRLAR
+    b     zero_mpu
+
+out_zero_mpu:
     b    enable_mpu
     ret
 END(enable_boot_cpu_mm)
diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
new file mode 100644
index 000000000000..1bdae4c309dc
--- /dev/null
+++ b/xen/arch/arm/include/asm/arm32/mpu.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __ARM_ARM32_MPU_H__
+#define __ARM_ARM32_MPU_H__
+
+#ifndef __ASSEMBLY__
+
+/* MPU Protection Region */
+typedef struct {
+    uint32_t prbar;
+    uint32_t prlar;
+} pr_t;
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ARM_ARM32_MPU_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/include/asm/bitmap-op.inc b/xen/arch/arm/include/asm/bitmap-op.inc
new file mode 100644
index 000000000000..ea7c8abbf6f0
--- /dev/null
+++ b/xen/arch/arm/include/asm/bitmap-op.inc
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+/*
+ * Sets a bit in a bitmap declared by DECLARE_BITMAP, symbol name passed through
+ * bitmap_symbol.
+ *
+ * bitmap_set_bit:      symbol of the bitmap declared by DECLARE_BITMAP
+ * bit:                 bit number to be set in the bitmap
+ * tmp1-tmp4:           temporary registers used for the computation
+ *
+ * Preserves bit.
+ * Output:
+ *  tmp1: Address of the word containing the changed bit.
+ * Clobbers: tmp1, tmp2, tmp3, tmp4.
+ */
+.macro bitmap_set_bit bitmap_symbol, bit, tmp1, tmp2, tmp3, tmp4
+    adr_l   \tmp1, \bitmap_symbol
+    mov     \tmp2, #(BYTES_PER_LONG - 1)
+    mvn     \tmp2, \tmp2
+    lsr     \tmp3, \bit, #3
+    and     \tmp2, \tmp3, \tmp2
+    add     \tmp1, \tmp1, \tmp2                 /* bitmap_symbol + (bit/BITS_PER_LONG)*BYTES_PER_LONG */
+    and     \tmp2, \bit, #(BITS_PER_LONG - 1)   /* bit offset inside word */
+
+    ldr     \tmp3, [\tmp1]
+    mov     \tmp4, #1
+    lsl     \tmp4, \tmp4, \tmp2                 /* (1 << offset) */
+    orr     \tmp3, \tmp3, \tmp4                 /* set the bit */
+    str     \tmp3, [\tmp1]
+.endm
+
+/*
+ * Clears a bit in a bitmap declared by DECLARE_BITMAP, symbol name passed
+ * through bitmap_symbol.
+ *
+ * bitmap_set_bit:      symbol of the bitmap declared by DECLARE_BITMAP
+ * bit:                 bit number to be set in the bitmap
+ * tmp1-tmp4:           temporary registers used for the computation
+ *
+ * Preserves bit.
+ * Output:
+ *  tmp1: Address of the word containing the changed bit.
+ * Clobbers: tmp1, tmp2, tmp3, tmp4.
+ */
+.macro bitmap_clear_bit bitmap_symbol, bit, tmp1, tmp2, tmp3, tmp4
+    adr_l   \tmp1, \bitmap_symbol
+    mov     \tmp2, #(BYTES_PER_LONG - 1)
+    mvn     \tmp2, \tmp2
+    lsr     \tmp3, \bit, #3
+    and     \tmp2, \tmp3, \tmp2
+    add     \tmp1, \tmp1, \tmp2                 /* bitmap_symbol + (bit/BITS_PER_LONG)*BYTES_PER_LONG */
+    and     \tmp2, \bit, #(BITS_PER_LONG - 1)   /* bit offset inside word */
+
+    ldr     \tmp3, [\tmp1]
+    mov     \tmp4, #1
+    lsl     \tmp4, \tmp4, \tmp2                 /* (1 << offset) */
+    mvn     \tmp4, \tmp4                        /* ~(1 << offset) */
+    and     \tmp3, \tmp3, \tmp4                 /* clear the bit */
+    str     \tmp3, [\tmp1]
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index bb83f5a5f580..fb93b8b19d24 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -8,6 +8,10 @@
 
 #if defined(CONFIG_ARM_64)
 # include 
+#elif defined(CONFIG_ARM_32)
+# include 
+#else
+# error "unknown ARM variant"
 #endif
 
 #define MPU_REGION_SHIFT  6
@@ -17,6 +21,7 @@
 #define NUM_MPU_REGIONS_SHIFT   8
 #define NUM_MPU_REGIONS         (_AC(1, UL) << NUM_MPU_REGIONS_SHIFT)
 #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
+#define MAX_MPU_REGION_NR       NUM_MPU_REGIONS_MASK
 
 #endif /* __ARM_MPU_H__ */
 
diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
index bfd840fa5d31..409b4dd53dc6 100644
--- a/xen/arch/arm/include/asm/mpu/mm.h
+++ b/xen/arch/arm/include/asm/mpu/mm.h
@@ -8,9 +8,16 @@
 #include 
 #include 
 #include 
+#include 
 
 extern struct page_info *frame_table;
 
+extern uint8_t max_mpu_regions;
+
+extern DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR);
+
+extern pr_t xen_mpumap[MAX_MPU_REGION_NR];
+
 #define virt_to_maddr(va) ((paddr_t)((vaddr_t)(va) & PADDR_MASK))
 
 #ifdef CONFIG_ARM_32
diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
index 47868a152662..ba38213ffff1 100644
--- a/xen/arch/arm/include/asm/mpu/regions.inc
+++ b/xen/arch/arm/include/asm/mpu/regions.inc
@@ -1,14 +1,42 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include 
 #include 
 #include 
 
 /* Backgroud region enable/disable */
 #define SCTLR_ELx_BR    BIT(17, UL)
 
+#define REGION_DISABLED_PRLAR   0x00    /* NS=0 ATTR=000 EN=0 */
 #define REGION_NORMAL_PRLAR     0x0f    /* NS=0 ATTR=111 EN=1 */
 #define REGION_DEVICE_PRLAR     0x09    /* NS=0 ATTR=100 EN=1 */
 
+#define PRLAR_ELx_EN            0x1
+
+#ifdef CONFIG_ARM_64
+#define XEN_MPUMAP_ENTRY_SHIFT  0x4     /* 16 byte structure */
+
+.macro store_pair reg1, reg2, dst
+    stp \reg1, \reg2, [\dst]
+.endm
+
+.macro invalidate_dcache_one reg
+    dc ivac, \reg
+.endm
+
+#else
+#define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
+
+.macro store_pair reg1, reg2, dst
+    nop
+.endm
+
+.macro invalidate_dcache_one reg
+    nop
+.endm
+
+#endif
+
 /*
  * Macro to prepare and set a EL2 MPU memory region.
  * We will also create an according MPU memory region entry, which
@@ -56,6 +84,27 @@
     isb
     WRITE_SYSREG_ASM(\prbar, PRBAR_EL2)
     WRITE_SYSREG_ASM(\prlar, PRLAR_EL2)
+
+    /* Load pair into xen_mpumap and invalidate cache */
+    adr_l \base, xen_mpumap
+    add   \base, \base, \sel, LSL #XEN_MPUMAP_ENTRY_SHIFT
+    store_pair \prbar, \prlar, \base
+    invalidate_dcache_one \base
+
+    /* Set/clear xen_mpumap_mask bitmap */
+    tst   \prlar, #PRLAR_ELx_EN
+    bne   2f
+    /* Region is disabled, clear the bit in the bitmap */
+    bitmap_clear_bit xen_mpumap_mask, \sel, \base, \limit, \prbar, \prlar
+    b     3f
+
+2:
+    /* Region is enabled, set the bit in the bitmap */
+    bitmap_set_bit xen_mpumap_mask, \sel, \base, \limit, \prbar, \prlar
+
+3:
+    invalidate_dcache_one \base
+
     dsb   sy
     isb
 
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 07c8959f4ee9..ee035a54b942 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -7,9 +7,25 @@
 #include 
 #include 
 #include 
+#include 
 
 struct page_info *frame_table;
 
+/* Maximum number of supported MPU memory regions by the EL2 MPU. */
+uint8_t __ro_after_init max_mpu_regions;
+
+/*
+ * Bitmap xen_mpumap_mask is to record the usage of EL2 MPU memory regions.
+ * Bit 0 represents MPU memory region 0, bit 1 represents MPU memory
+ * region 1, ..., and so on.
+ * If a MPU memory region gets enabled, set the according bit to 1.
+ */
+DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
+    __section(".data.page_aligned");
+
+/* EL2 Xen MPU memory region mapping table. */
+pr_t __section(".data.page_aligned") xen_mpumap[MAX_MPU_REGION_NR];
+
 static void __init __maybe_unused build_assertions(void)
 {
     /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 13 08:45:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 08:45:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982632.1368995 (Exim 4.92)
	(envelope-from )
	id 1uElGp-00021W-KD; Tue, 13 May 2025 08:45:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982632.1368995; Tue, 13 May 2025 08:45: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 1uElGp-00020p-Dm; Tue, 13 May 2025 08:45:51 +0000
Received: by outflank-mailman (input) for mailman id 982632;
 Tue, 13 May 2025 08:45:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uElGo-0001kc-0u
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 08:45:50 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id a9619977-2fd6-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 10:45:46 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9CF07176A;
 Tue, 13 May 2025 01:45:35 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7D49A3F5A1;
 Tue, 13 May 2025 01:45: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" 
X-Inumbo-ID: a9619977-2fd6-11f0-9ffb-bf95429c2676
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Ayan Kumar Halder 
Subject: [PATCH v5 1/6] docs/arm: Document Xen booting protocol on Armv8-R
Date: Tue, 13 May 2025 09:45:27 +0100
Message-Id: <20250513084532.4059388-2-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250513084532.4059388-1-luca.fancellu@arm.com>
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Document the requirement needed to boot Xen on Armv8-R platforms.

Signed-off-by: Luca Fancellu 
Reviewed-by: Ayan Kumar Halder 
Reviewed-by: Michal Orzel 
---
v5 changes:
 - restructured and removed some EL3 reference that might not
   be there on Armv8-R aarch64
 - add R-by Ayan and Michal
v4 changes:
 - New patch
---
 docs/misc/arm/booting.txt | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
index 21ae74837dcc..ca05274392be 100644
--- a/docs/misc/arm/booting.txt
+++ b/docs/misc/arm/booting.txt
@@ -56,12 +56,17 @@ image header to determine the load address, entry point, etc.
 Firmware/bootloader requirements
 --------------------------------
 
-Xen relies on some settings the firmware has to configure in EL3 before starting Xen.
+Xen relies on some settings the firmware has to configure before starting Xen.
 
-* Xen must be entered in NS EL2 mode
+* Xen must be entered in:
+  * Non-Secure EL2 mode for Armv8-A Arm64 and Arm32, Armv8-R Arm32.
+  * Secure EL2 mode for Armv8-R Arm64.
 
-* The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1.
+* When EL3 is supported, the bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must
+  be set to 1.
 
+* Xen must be entered with MMU/MPU off and data cache disabled (SCTLR_EL2.M bit
+  and SCTLR_EL2.C set to 0).
 
 [1] linux/Documentation/arm/booting.rst
 Latest version: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arch/arm/booting.rst
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 13 08:45:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 08:45:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982631.1368988 (Exim 4.92)
	(envelope-from )
	id 1uElGp-0001ya-A8; Tue, 13 May 2025 08:45:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982631.1368988; Tue, 13 May 2025 08:45: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 1uElGp-0001yS-7Y; Tue, 13 May 2025 08:45:51 +0000
Received: by outflank-mailman (input) for mailman id 982631;
 Tue, 13 May 2025 08:45:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uElGn-0001kb-No
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 08:45:49 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id aac9dae2-2fd6-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 10:45:48 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4C29222EE;
 Tue, 13 May 2025 01:45:37 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E2CFB3F5A1;
 Tue, 13 May 2025 01:45: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" 
X-Inumbo-ID: aac9dae2-2fd6-11f0-9eb6-5ba50f476ded
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Penny Zheng ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Penny Zheng ,
	Wei Chen 
Subject: [PATCH v5 2/6] arm/mpu: Introduce MPU memory region map structure
Date: Tue, 13 May 2025 09:45:28 +0100
Message-Id: <20250513084532.4059388-3-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250513084532.4059388-1-luca.fancellu@arm.com>
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Penny Zheng 

Introduce pr_t typedef which is a structure having the prbar
and prlar members, each being structured as the registers of
the AArch64 Armv8-R architecture.

Signed-off-by: Penny Zheng 
Signed-off-by: Wei Chen 
Signed-off-by: Luca Fancellu 
---
Changes in v5:
 - Given some comments on the page.h flags, I had to rework some
   fields here to better match the flags usage and avoid duplication
Changes in v4:
 - Fixed typos, changed name for reserved bitfields, add emacs bits
   to arm64/mpu.h.
   Now base and limit are 42 bits as we consider FEAT_LPA disabled,
   since we support max 1TB of memory.
   Moved data structure in commit that uses it
---
 xen/arch/arm/include/asm/arm64/mpu.h | 52 ++++++++++++++++++++++++++++
 xen/arch/arm/include/asm/mpu.h       |  4 +++
 2 files changed, 56 insertions(+)
 create mode 100644 xen/arch/arm/include/asm/arm64/mpu.h

diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h
new file mode 100644
index 000000000000..d3c055a2e53b
--- /dev/null
+++ b/xen/arch/arm/include/asm/arm64/mpu.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __ARM_ARM64_MPU_H__
+#define __ARM_ARM64_MPU_H__
+
+#ifndef __ASSEMBLY__
+
+/* Protection Region Base Address Register */
+typedef union {
+    struct __packed {
+        unsigned long xn_0:1;     /* Execute-Never XN[0] */
+        unsigned long xn:1;       /* Execute-Never XN[1] */
+        unsigned long ap_0:1;     /* Access Permission AP[0] */
+        unsigned long ro:1;       /* Access Permission AP[1] */
+        unsigned long sh:2;       /* Shareability */
+        unsigned long base:42;    /* Base Address */
+        unsigned long res0:16;    /* RES0 */
+    } reg;
+    uint64_t bits;
+} prbar_t;
+
+/* Protection Region Limit Address Register */
+typedef union {
+    struct __packed {
+        unsigned long en:1;     /* Region enable */
+        unsigned long ai:3;     /* Memory Attribute Index */
+        unsigned long ns:1;     /* Not-Secure */
+        unsigned long res0:1;   /* RES0 */
+        unsigned long limit:42; /* Limit Address */
+        unsigned long res1:16;  /* RES0 */
+    } reg;
+    uint64_t bits;
+} prlar_t;
+
+/* MPU Protection Region */
+typedef struct {
+    prbar_t prbar;
+    prlar_t prlar;
+} pr_t;
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ARM_ARM64_MPU_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index d4ec4248b62b..bb83f5a5f580 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -6,6 +6,10 @@
 #ifndef __ARM_MPU_H__
 #define __ARM_MPU_H__
 
+#if defined(CONFIG_ARM_64)
+# include 
+#endif
+
 #define MPU_REGION_SHIFT  6
 #define MPU_REGION_ALIGN  (_AC(1, UL) << MPU_REGION_SHIFT)
 #define MPU_REGION_MASK   (~(MPU_REGION_ALIGN - 1))
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 13 08:45:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 08:45:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982635.1369028 (Exim 4.92)
	(envelope-from )
	id 1uElGt-0002uq-B2; Tue, 13 May 2025 08:45:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982635.1369028; Tue, 13 May 2025 08:45: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 1uElGt-0002uf-8W; Tue, 13 May 2025 08:45:55 +0000
Received: by outflank-mailman (input) for mailman id 982635;
 Tue, 13 May 2025 08:45:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uElGs-0001kc-8g
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 08:45:54 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id acaa5753-2fd6-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 10:45:51 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2A1B822EE;
 Tue, 13 May 2025 01:45:41 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2A0BB3F5A1;
 Tue, 13 May 2025 01:45:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: acaa5753-2fd6-11f0-9ffb-bf95429c2676
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v5 5/6] arm/mpu: Introduce utility functions for the pr_t type
Date: Tue, 13 May 2025 09:45:31 +0100
Message-Id: <20250513084532.4059388-6-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250513084532.4059388-1-luca.fancellu@arm.com>
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce a few utility functions to manipulate and handle the
pr_t type.

Signed-off-by: Luca Fancellu 
---
v5 changes:
 - Don't rely on bitfield and use the mask MPU_REGION_RES0 for
   pr_set_base and pr_set_limit to make it explicit. Fixed typos
   in commit message.
v4 changes:
 - Modify comment on top of the helpers. Clarify pr_set_limit
   takes exclusive address.
   Protected common code with #ifdef Arm64 until Arm32 is ready
   with pr_t
---
 xen/arch/arm/include/asm/mpu.h | 65 ++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index fb93b8b19d24..b90ae8eab662 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -23,6 +23,71 @@
 #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
 #define MAX_MPU_REGION_NR       NUM_MPU_REGIONS_MASK
 
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_ARM_64
+/*
+ * Set base address of MPU protection region.
+ *
+ * @pr: pointer to the protection region structure.
+ * @base: base address as base of the protection region.
+ */
+static inline void pr_set_base(pr_t *pr, paddr_t base)
+{
+    pr->prbar.reg.base = ((base & ~MPU_REGION_RES0) >> MPU_REGION_SHIFT);
+}
+
+/*
+ * Set limit address of MPU protection region.
+ *
+ * @pr: pointer to the protection region structure.
+ * @limit: exclusive address as limit of the protection region.
+ */
+static inline void pr_set_limit(pr_t *pr, paddr_t limit)
+{
+    pr->prlar.reg.limit = (((limit - 1) & ~MPU_REGION_RES0)
+                           >> MPU_REGION_SHIFT);
+}
+
+/*
+ * Access to get base address of MPU protection region.
+ * The base address shall be zero extended.
+ *
+ * @pr: pointer to the protection region structure.
+ * @return: Base address configured for the passed protection region.
+ */
+static inline paddr_t pr_get_base(pr_t *pr)
+{
+    return (paddr_t)(pr->prbar.reg.base << MPU_REGION_SHIFT);
+}
+
+/*
+ * Access to get limit address of MPU protection region.
+ * The limit address shall be concatenated with 0x3f.
+ *
+ * @pr: pointer to the protection region structure.
+ * @return: Inclusive limit address configured for the passed protection region.
+ */
+static inline paddr_t pr_get_limit(pr_t *pr)
+{
+    return (paddr_t)((pr->prlar.reg.limit << MPU_REGION_SHIFT)
+                     | ~MPU_REGION_MASK);
+}
+
+/*
+ * Checks if the protection region is valid (enabled).
+ *
+ * @pr: pointer to the protection region structure.
+ * @return: True if the region is valid (enabled), false otherwise.
+ */
+static inline bool region_is_valid(pr_t *pr)
+{
+    return pr->prlar.reg.en;
+}
+#endif
+
+#endif /* __ASSEMBLY__ */
+
 #endif /* __ARM_MPU_H__ */
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 13 09:05:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 09:05:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982702.1369049 (Exim 4.92)
	(envelope-from )
	id 1uElZZ-0007be-3y; Tue, 13 May 2025 09:05:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982702.1369049; Tue, 13 May 2025 09:05: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 1uElZZ-0007bX-08; Tue, 13 May 2025 09:05:13 +0000
Received: by outflank-mailman (input) for mailman id 982702;
 Tue, 13 May 2025 09:05:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uElZX-0007bB-8O
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 09:05:11 +0000
Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com
 [2607:f8b0:4864:20::c30])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5d8d415b-2fd9-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 11:05:08 +0200 (CEST)
Received: by mail-oo1-xc30.google.com with SMTP id
 006d021491bc7-605fda00c30so2016913eaf.1
 for ; Tue, 13 May 2025 02:05:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5d8d415b-2fd9-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747127107; x=1747731907; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=P5YqzDx1E8TGH+bAdDvHfGPqVZAPBd2+UY+KXP6zMug=;
        b=AUBOOPzQuGanY3CC4rUY2GNFvkNJq58hvzrJE3noePG3LiCC3EP3XaNTqgSQk0V+a4
         mE4A2GCQW1QLkgXaa2ndCOnjj1MXIuFAqB3J9EioLmhMpqN7iv5PlYJW7aOTEz6pOkeN
         cT4kwyJermVzZ9Ar44SNXpIPYKsmFemzezgJc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747127107; x=1747731907;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=P5YqzDx1E8TGH+bAdDvHfGPqVZAPBd2+UY+KXP6zMug=;
        b=azVVB32Vb5S0WbnNhjoslBKEiugugp+HtNw0VWxy8LbA9eeUSxKxzVIetCpesYNj+K
         2BcmsWDx6MixwIcNaIreBKCNsyFcVs/sO9GSuAVuZG9YQry1U1WlhFla1y5f4JBoJ+jL
         XtXeco9ugBSRBgeA9FC/GHNgaE8H496yWsqNRy/e20Lg+uiwleU7+CSKtD+EGoCBMskr
         /I0rQE3wodAAx318CB1EmLMw1s30X2tNn5PDEBdNuoSJD/wvO98DWOCOXRiw5UAKs5eG
         EQXe+ZLZYXpkzyMCgANSltd6FIUB4gsZvnHbkvP4knD3FjyEMKidopPo2pQrnjcvy1yp
         rMbA==
X-Forwarded-Encrypted: i=1; AJvYcCVmaobk18r3JUmWRfhvPe6RLXlvsD0dXBinABnQXrC9yv8VTIh2BI5HLaiDHLt1dd3qDyK1PM/qUwE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwflHKZ44HiQO5YELWR2Hr2IAn/G+wDgGNGq0q3/KVMa95oAB22
	cw4W398L8WqbNQSkzFxu5edy2nWTeSR7aJjajAY3DPt/u+SPE8cQONxUaHud1SGanoenARwAdbh
	Kz8x3bK5+lUiJqY6TMwlbeb99BK6anI4OfbAC
X-Gm-Gg: ASbGnctpj5ymnxnoRdJgydefTsSFjyjkZw2f40S3/dT6WF89vFugz8InSI+33SDOOMp
	pTRHslCG7TH1fDmNsL/K3EJDPErahh433oUUML23QFUkrrpzvUNr2gyG60RHPyxEUHK+SqNXd8a
	BcWQswLbrMujw1un6xskuL2ZKwFMfN/wyK4ir5YJMC4w==
X-Google-Smtp-Source: AGHT+IFmmPau44n8iNx0hOeKpyiUSNa5JIMLuXHPIMsjcRoUP+MZwAHED9EHPm8XLRuthW5MM3Ztv4/bXvID9YGpk0c=
X-Received: by 2002:a05:6870:70aa:b0:2d5:296d:4ed4 with SMTP id
 586e51a60fabf-2dba4524cd2mr9907879fac.28.1747127107535; Tue, 13 May 2025
 02:05:07 -0700 (PDT)
MIME-Version: 1.0
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
 <20250509161846.45851-1-ross.lagerwall@citrix.com> <5e3a8054-53aa-490f-a60e-44ed34cbc74b@suse.com>
In-Reply-To: <5e3a8054-53aa-490f-a60e-44ed34cbc74b@suse.com>
From: Ross Lagerwall 
Date: Tue, 13 May 2025 10:04:56 +0100
X-Gm-Features: AX0GCFvv1etXaX0okBUXHL_tFfxIbkHqga8YlRf-HW7sNkl-oBWGm5BC2ERVAZw
Message-ID: 
Subject: Re: [PATCH 1/4] docs: Introduce live patch signing
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 12, 2025 at 1:19=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 09.05.2025 18:18, Ross Lagerwall wrote:
> > --- a/docs/misc/livepatch.pandoc
> > +++ b/docs/misc/livepatch.pandoc
> > @@ -917,6 +917,58 @@ The normal sequence of events is to:
> >   3. *XEN_SYSCTL_LIVEPATCH_ACTION* with *LIVEPATCH_ACTION_APPLY* to app=
ly the patch.
> >   4. *XEN_SYSCTL_LIVEPATCH_GET* to check the `->rc`. If in *-XEN_EAGAIN=
* spin. If zero exit with success.
> >
> > +## Signature Checking
> > +
> > +While loading live patches would generally be restricted to a privileg=
ed
> > +process in dom0, in certain cases signature checking in Xen may be req=
uired.
> > +For example, when Secure Boot is enabled live patches need to be verif=
ied
> > +before being loaded.
> > +
> > +Xen live patches are ELF binaries but there is no standardized mechani=
sm for
> > +signing ELF binaries. One approach used by Linux is to append a signat=
ure to
> > +the end of the binary, outside of the ELF container. While this works,=
 it tends
> > +to be fragile since tools that handle ELF binaries do not correctly ha=
ndle the
> > +signature. Instead, the approach taken here is to use an ELF note for =
the
> > +signature.
> > +
> > +The ELF note section name shall be `.note.Xen.signature` with note nam=
e `Xen`
> > +and type `0`.
> > +
> > +The note data shall contain a header followed by the signature data:
> > +
> > +    #define SIGNATURE_SUPPORTED_VERION 1
>
> I don't think this is a good name (leaving aside the typo); conceptually
> multiple versions could be supported. Otoh live patches are hypervisor
> build specific anyway, so it's hard to see why a version would be needed
> in the first place. Alternatively should version or ...

How about LIVEPATCH_SIGNATURE_VERSION (analogous to
LIVEPATCH_PAYLOAD_VERSION)?

I think keeping the version is harmless and may cover some future
scenario I haven't considered, even if it is not strictly necessary at
the moment.

>
> > +    #define SIGNATURE_ALGORITHM_RSA 0
> > +    #define SIGNATURE_HASH_SHA256 0
>
> ... these two be encoded in the note's type, instead of leaving that
> effectively unused?

That's a good idea. The version, algorithm, and hash can be encoded in
the type and the signature length can be encoded in the note descriptor
length and that would allow removing the signature header completely.

>
> > +    struct payload_signature {
> > +        uint16_t version;
> > +        uint8_t algo;        /* Public-key crypto algorithm */
> > +        uint8_t hash;        /* Digest algorithm */
> > +        uint32_t sig_len;    /* Length of signature data */
>
> Should there be a minimum length specified, to ensure security at least
> for the moment (before e.g. quantum computers can break things)?

I'd prefer to leave that policy to the distros who use this
functionality rather than trying to keep up with what is currently
considered secure.

>
> > +    };
> > +
> > +To sign a live patch:
> > +
> > +1) Add a new note section with a populated payload signature and zeroe=
d out
> > +   signature.
> > +2) Generate a detached signature over the entire binary.
> > +3) Fill in the signature in the note section.
> > +
> > +During live patch load, Xen shall verify the signature using the follo=
wing
> > +steps:
> > +
> > +1) Copy the signature out of the note section.
> > +2) Zero the signature.
> > +3) Generate a detached signature over the entire binary.
> > +4) Compare against the signature from (1).
> > +
> > +Initially, to avoid including DER / X.509 parsing of certificates, han=
dling
> > +chains, etc. Xen shall verify signatures against a compiled in RSA key=
 in
> > +exponent/modulus form.
>
> And this is sufficient to satisfy (Microsoft's?) requirements?
>

To my knowledge Microsoft has not stated explicitly how various
components in the OS should be verified / secured. However, their
current requirement is that firmware is verified using at least RSA-2048
with SHA-256 so with a sufficiently large key this would cover that,
assuming they apply the same requirement to the OS.

Ross


From xen-devel-bounces@lists.xenproject.org Tue May 13 09:46:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 09:46:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982713.1369059 (Exim 4.92)
	(envelope-from )
	id 1uEmDS-00046G-3V; Tue, 13 May 2025 09:46:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982713.1369059; Tue, 13 May 2025 09: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 1uEmDS-000469-0R; Tue, 13 May 2025 09:46:26 +0000
Received: by outflank-mailman (input) for mailman id 982713;
 Tue, 13 May 2025 09:46:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEmDR-000463-CF
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 09:46:25 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 208370c2-2fdf-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 11:46:22 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ad241baf856so511348666b.0
 for ; Tue, 13 May 2025 02:46: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
 a640c23a62f3a-ad2521cc56bsm337359766b.109.2025.05.13.02.46.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 02:46: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" 
X-Inumbo-ID: 208370c2-2fdf-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747129581; x=1747734381; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QMpSJiPGpkMcX/gDwnPI92nY1CMxR2KUxdfji6SX404=;
        b=biJ8sgBASnnezP+unJOMIEbnaP9+zbRSF/wqe2Rls89pa0cVSm/A8Pss5tGlV/wpm9
         u/v7y16BYrvZPg7hiTXgSfgPQ+cGa4iwQ50plfK1UrYqRXDOB9+NyC+56ahZZvdU/pD/
         53GyNIdIp9N52G5GOY07DOId+jZeicKzxw3mO1TXNvDXIrU+/+iTYXBFmWGgvF/emIwb
         QKmno63gDsH37ZEotJ2KPTMrqAIwHMN6u8NGcdU5wB1DjIoX+XQ0OjF/39XcEQM8sAZE
         jdeCo2fihlUWSYPOOG5/KNrn5iMoadfqXrxq3iiE9/P7+wrURQJ9BAq7zGp7AwG0PWyi
         yqNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747129581; x=1747734381;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QMpSJiPGpkMcX/gDwnPI92nY1CMxR2KUxdfji6SX404=;
        b=W7ZQ0uVRErQvfsRMihOE6s30Abri/bCq82qt3Jug4Ls04M09/L1nbMA/e5HWQ1eSUn
         XK+n0TC9XrUttjLFdEWiQWbpaR8xxHMTpp5QH2TdIXUtU7SmXaLs/FXYbaP590/DvXyq
         cWnjZsgITTfyaw8WMsQchNbndoGj67FOCKPbCY4fwJuoYEwiQBosak1Ftlmc7DF/Zd7o
         XFLUADrG0QSCVQPSDh5aya2skqAcNR7ORgz44tsxsOF/3I2cV0nxGmRzgmbISC26/Gw0
         ewoYWKIuK0hehApmmO6iUVFAtNJKKOpNdGGOry8cMehaCJdLMMmThWnsyYBEJjnTQ/nh
         jcOg==
X-Forwarded-Encrypted: i=1; AJvYcCVoGWRMRzgMhZdEoCfIyBOnkJgP5Hp18+ssJva6EVNdXUgd4gmgNAGUdQv0JFjIVy/T5miSoOBcnxQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YypcIMtm+rEG+nEvRivoPEU7eJVhHFEiDydzORMtlup/IuuNBWa
	5X2CeOPA/v5PcV9NVlu/b4LcKGOOUHk21BVQO8qk62kpr4a0HYuzdyt0j3VoUg==
X-Gm-Gg: ASbGncvOEIpgapYaNRo93prtTSVE1eRu9BaN4v2Z9oGZbzir3YQ4thBcI35svlLTxkd
	hKbS6K0YOAj65b5QLzhZlA+IzUgd6u3cOcxeDKEwaGDSfvb6zRN5A6C+aukHxsaZuQ8p0RTQDZn
	ZxBab2eX/fnLep5Zx5EDZKFAtBK/50vd/N8sI5kFTs6gkvs5JNsBm7weA1/ADsRJZ7rGtICOTRC
	aUaEbiQm2oQ5dL3TeKN5cJeGq2g3j/gI26dcdQnhFvjnNjWxVYc0quSDf1MUiarD7v8c2SnCYGV
	eeJuD3wuvyaVN5vQhOeILtrJUkTyXZaS1xcmAnMkyJ7oZDwFiZkCNsQq7nhRdEy4mkvH1IUK0kG
	1RM/SbnAc2eI3V6FSgQ/HmlnGifT6bZMHyAc1
X-Google-Smtp-Source: AGHT+IGMT9hyW6I6BK/wRB6ENseb9YyICJZFA8KXTT2iOrZq8xFunCIv4/UKil4Fq3vrz8/IdEp9+Q==
X-Received: by 2002:a17:906:f5a2:b0:ad2:3e15:844 with SMTP id a640c23a62f3a-ad4d527304fmr238841666b.22.1747129581340;
        Tue, 13 May 2025 02:46:21 -0700 (PDT)
Message-ID: <573b8a77-86d1-4e02-8b22-a36fcd2c1ff6@suse.com>
Date: Tue, 13 May 2025 11:46:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] docs: Introduce live patch signing
To: Ross Lagerwall 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
 <20250509161846.45851-1-ross.lagerwall@citrix.com>
 <5e3a8054-53aa-490f-a60e-44ed34cbc74b@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

On 13.05.2025 11:04, Ross Lagerwall wrote:
> On Mon, May 12, 2025 at 1:19 PM Jan Beulich  wrote:
>>
>> On 09.05.2025 18:18, Ross Lagerwall wrote:
>>> --- a/docs/misc/livepatch.pandoc
>>> +++ b/docs/misc/livepatch.pandoc
>>> @@ -917,6 +917,58 @@ The normal sequence of events is to:
>>>   3. *XEN_SYSCTL_LIVEPATCH_ACTION* with *LIVEPATCH_ACTION_APPLY* to apply the patch.
>>>   4. *XEN_SYSCTL_LIVEPATCH_GET* to check the `->rc`. If in *-XEN_EAGAIN* spin. If zero exit with success.
>>>
>>> +## Signature Checking
>>> +
>>> +While loading live patches would generally be restricted to a privileged
>>> +process in dom0, in certain cases signature checking in Xen may be required.
>>> +For example, when Secure Boot is enabled live patches need to be verified
>>> +before being loaded.
>>> +
>>> +Xen live patches are ELF binaries but there is no standardized mechanism for
>>> +signing ELF binaries. One approach used by Linux is to append a signature to
>>> +the end of the binary, outside of the ELF container. While this works, it tends
>>> +to be fragile since tools that handle ELF binaries do not correctly handle the
>>> +signature. Instead, the approach taken here is to use an ELF note for the
>>> +signature.
>>> +
>>> +The ELF note section name shall be `.note.Xen.signature` with note name `Xen`
>>> +and type `0`.
>>> +
>>> +The note data shall contain a header followed by the signature data:
>>> +
>>> +    #define SIGNATURE_SUPPORTED_VERION 1
>>
>> I don't think this is a good name (leaving aside the typo); conceptually
>> multiple versions could be supported. Otoh live patches are hypervisor
>> build specific anyway, so it's hard to see why a version would be needed
>> in the first place. Alternatively should version or ...
> 
> How about LIVEPATCH_SIGNATURE_VERSION (analogous to
> LIVEPATCH_PAYLOAD_VERSION)?

Fine with me.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 11:08:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 11:08:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982736.1369079 (Exim 4.92)
	(envelope-from )
	id 1uEnUL-0005LO-0U; Tue, 13 May 2025 11:07:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982736.1369079; Tue, 13 May 2025 11: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 1uEnUK-0005LH-U3; Tue, 13 May 2025 11:07:56 +0000
Received: by outflank-mailman (input) for mailman id 982736;
 Tue, 13 May 2025 11:07:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEnUJ-000551-VY
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 11:07:55 +0000
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com
 [2607:f8b0:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 84d23aa9-2fea-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 13:07:55 +0200 (CEST)
Received: by mail-pg1-x532.google.com with SMTP id
 41be03b00d2f7-7fd35b301bdso6189470a12.2
 for ; Tue, 13 May 2025 04: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" 
X-Inumbo-ID: 84d23aa9-2fea-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747134474; x=1747739274; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FWtT3Cwc4X+aVigDHquJY93P7hxQPAIPhRkOpXj2QFE=;
        b=DJnnyuIkRQIyKtIASgkKBAsHQSZlaA2s6CTfTvh69B84KF4TqeXZt1ndKMSVh13b0l
         BmLOlWWTRNMj475/YML+oKYF51A0MDEJbEfSwm+JNq5dUM00my9AyWb04+GFRIyXYMur
         4yI4YmQxt4c0nJAWEgx0cMTZUXf+G0nXSuQu8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747134474; x=1747739274;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=FWtT3Cwc4X+aVigDHquJY93P7hxQPAIPhRkOpXj2QFE=;
        b=llCcfARjVSGWtBwNCzbdZxjSrQEFwmlnoTEq1W72IzSGFWh6R7hq88Q35V+WHdxp60
         8oy6zDaldsS2eriEJNfaWgI7T8g7pXd3K8vSHP6S4kiW66l/+q0PQ3UNs3Xc7J/TgNt9
         NKASlFfIMsDokzcD3JbG14S/xbHQYak7ZjWbyPcWfZALrxBJH+FyhIVYrmcVHJ80RnHm
         uDqWiyYePIV/m7aUPUMiX2yy56yb0zHA5xmbBRrEa2o7on3uRUvS48RxnEnwP6UD8Jqb
         MBV767bWR0KYLEcPLug1Cx9P2x0XN8DLLL0fkhBUIJmQJmQ6Np60PJk9P0nrbBQfaWnr
         5mSg==
X-Gm-Message-State: AOJu0YzBYNXIv5dKL0c9fPAOjFnxNfzQPvel4HPFlWttguDae5rKCUBV
	xd4ze7ycsjRA8bV0mp+z58mAAJG+3JY0+onSbZXgG3UeXfE4pZpcBV2nhLq2dLoJF0rkv7rUsOg
	hwGWrfifZNGFvKja0T7sR85RwUdYbFoeN+eFvwKpzXXErZf2FWjc=
X-Gm-Gg: ASbGncu3oLQf5SEmx+CsWDDgTxl04etWn1fdOrbDgydzV6mzvLUrlkGfu40a0fa05si
	8bFYMOTWHZPMHYZ74EBx0UYL9UCnB/VosOAubOJ7cO6mOILGlEE5HD+WExQyWFCHBkfe6M5ElVB
	FUbEgF7xVwEPSY+gd69hF5gkg8sHbkMJg=
X-Google-Smtp-Source: AGHT+IGFhkssudvMoEV5UDej/dkEy2tsJm7UjkPESCXKUVYK08Iy9A+gPnrvRLQoLTKnXcIt3pyqzJRxlTZ9ueCDspY=
X-Received: by 2002:a17:902:e54f:b0:224:191d:8a79 with SMTP id
 d9443c01a7336-22fc8c7b6bbmr236553225ad.27.1747134474006; Tue, 13 May 2025
 04:07:54 -0700 (PDT)
MIME-Version: 1.0
References: <20250512195628.1728455-1-kevin.lampis@cloud.com> 
In-Reply-To: 
From: Kevin Lampis 
Date: Tue, 13 May 2025 12:07:42 +0100
X-Gm-Features: AX0GCFst6uEFDyH-dMAM5W1YmQhM6BJ4Hmhlsse4VB0cj5foOIm-QJFlxOz3oB4
Message-ID: 
Subject: Re: [PATCH 0/3] Add lockdown mode
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 12, 2025 at 11:41=E2=80=AFAM Jan Beulich  wr=
ote:
>
> You want to go into more detail here, specifically to describe the criter=
ia
> of "specifically safe". The command line doc may also want updating.

I do not have a quick answer for you please bear with me.


From xen-devel-bounces@lists.xenproject.org Tue May 13 11:08:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 11:08:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982735.1369070 (Exim 4.92)
	(envelope-from )
	id 1uEnUB-00055E-NM; Tue, 13 May 2025 11:07:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982735.1369070; Tue, 13 May 2025 11: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 1uEnUB-000557-Ip; Tue, 13 May 2025 11:07:47 +0000
Received: by outflank-mailman (input) for mailman id 982735;
 Tue, 13 May 2025 11:07:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEnUA-000551-5i
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 11:07:46 +0000
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com
 [2607:f8b0:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7e9f7fde-2fea-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 13:07:45 +0200 (CEST)
Received: by mail-pg1-x52b.google.com with SMTP id
 41be03b00d2f7-b239763eeddso3521858a12.1
 for ; Tue, 13 May 2025 04:07: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" 
X-Inumbo-ID: 7e9f7fde-2fea-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747134463; x=1747739263; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4OJRMkSte2lQXICBlz24HAnM77CapoFNdueqwQS1R+k=;
        b=kLlQwF7f2nQ6Xvbp3CdEiMesFOxxFUVuXyg9qUmAyo0xz8wInpIZHkrWDNaq6pHxmF
         zUlVvmsaaco/SQlm3uHuh+Togbsb/L5MtmMJ7gcQ1/vwVSNjqAcnzhxOTawbNud6C/SU
         MFBmp1tdU3SpIhE1BHP889gu7qE5rLdcP7loQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747134463; x=1747739263;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4OJRMkSte2lQXICBlz24HAnM77CapoFNdueqwQS1R+k=;
        b=bJ+6RM2GdcrZQm5ba+MVD0ZV4SfOv4rz3Cv6OxoSWqoGu7Qxlg4scWsbiZhjIQ/34f
         eQP98U7uDq0NeJBN+kQKsQdCrYZzo1gYlJj1VlvQxp4d7U/ktiU+/LVFv83IAQSmuEbF
         vIvyiN2Idc3hrN0I1WcrqKVPK6lKoxFF/EaItksZEZbEYe1ePGytb5+HY0hBbWSD7aNN
         ZdumbALLtM5Q/WL0VVaWaHwvUGi7r81seOaGzEcTZkaYW9qVCtY+n/g2vHJb7ooD0Hs8
         aTX1f3dl/3/R9xAeKpTbCGLLCOHyfXMhn+faSyEybrJ86gW0Dm6gaZgRGs299YCu9HAt
         6IPA==
X-Forwarded-Encrypted: i=1; AJvYcCVooEmzrl+h8pA6lCjm/nlxXxQoMUCUDM5efi9I00bBm4L/52nBe5t3TAmXXgZ0kOJKUKul9EaS+LY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzqnczbsHV84tgnbkmcBaX2+gGFRpspB29McgAuSbF75dvus6h3
	cYnNYGxVKSBlrFJPvARmrzDChTAMIk9P8stQ8D8gue7XooLJyHRkmO49tMFzpXkg/v+nmip8Qu9
	CNO1eXfw8RPGigtEd9545bvf1loAWr6y+RqLhBQ==
X-Gm-Gg: ASbGncsf642wyHhFwxYFZZ+ZVywx3GCN9X7tuO/Gxl58lPbJ3eLXRFtFDrNYZ9Bfsc7
	K2dSfMmV53MO8ZdRBXKyJ9uIoZvN99f2lqjbGzn4LZ3yFgBcRzDqQpxYpqhe5qphp+l1ZC8SQzY
	rHxj7RhI0DyNLVjYI1Ot2rFi1eqCRCNtD0lcOyjG7DTw==
X-Google-Smtp-Source: AGHT+IFiEMjFQpPF6YAz2RNXUU9emD9FXRiNlgWuTon7HRmyGT3j3/82Nj17lHUhHtcEb0bWM/rkj473a7Ojx0En4uc=
X-Received: by 2002:a17:902:e84d:b0:22e:62cf:498f with SMTP id
 d9443c01a7336-22fc8e961a1mr264923465ad.38.1747134463477; Tue, 13 May 2025
 04:07:43 -0700 (PDT)
MIME-Version: 1.0
References: <20250506162510.1676425-1-kevin.lampis@cloud.com>
  
 <504f0be0-91fd-4847-8fcd-505771674814@suse.com>
In-Reply-To: <504f0be0-91fd-4847-8fcd-505771674814@suse.com>
From: Kevin Lampis 
Date: Tue, 13 May 2025 12:07:31 +0100
X-Gm-Features: AX0GCFtVeRZJFoCVVCSmO8daUXfv5BX_UfOVDjoaMrytCIZRZZMJQOBBV7eDAS8
Message-ID: 
Subject: Re: [PATCH 3/4] Add lockdown mode
To: Jan Beulich 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 13, 2025 at 8:00=E2=80=AFAM Jan Beulich  wro=
te:
>
> Well, there is an alternative: Require the lockdown argument to be absolu=
tely
> first. (There are further alternatives, but likely less usable.)

Is this your recommendation?


From xen-devel-bounces@lists.xenproject.org Tue May 13 11:09:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 11:09:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982751.1369089 (Exim 4.92)
	(envelope-from )
	id 1uEnWD-00069P-Bl; Tue, 13 May 2025 11:09:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982751.1369089; Tue, 13 May 2025 11: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 1uEnWD-00069I-8g; Tue, 13 May 2025 11:09:53 +0000
Received: by outflank-mailman (input) for mailman id 982751;
 Tue, 13 May 2025 11:09:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEnWC-00067M-R6
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 11:09:52 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ca445b26-2fea-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 13:09:51 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5fbf534f8dbso8410907a12.3
 for ; Tue, 13 May 2025 04:09: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
 4fb4d7f45d1cf-5fc9d70d55bsm7051474a12.65.2025.05.13.04.09.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 04:09: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" 
X-Inumbo-ID: ca445b26-2fea-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747134591; x=1747739391; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=nNM21eq9u1oC73bbfqviyTd2L8fCDU+BOAj5ecnoVH8=;
        b=ZAbNlrAG5EJ3l91xfhEvZVz0lOchRrNRrhCNvA3DZLITlvE6FDDOJ59EHGWTT/DnSP
         NHKrfLaQtUmAGhEOL2h1Txrt6pXSB2n7xDpQo/P97m/UPkK+TXD0Sm4QayANCCsQxC8d
         DRDZijH3U8h7Yx7GK/F+WGpCnMk0VK6Yfp22EZ/4vRyrRceQNDWJq+Z53fUyn/UXHgac
         yrIsGNqBhntWpKeH3VtkDcUY91GixoCGdIa2JG1RjDbIiGXkvBpM1iYxWEzj6lt6ioLL
         Gs/QObjo4R02L9V9gN5ckIyAv6dBhfoQ7hR9IQ2/3FCFsY6n39b5tEVdh5IJwYLAEDtD
         PH+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747134591; x=1747739391;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nNM21eq9u1oC73bbfqviyTd2L8fCDU+BOAj5ecnoVH8=;
        b=hZIoMXcfrnMKmwrEBsALdVkZwTpMNnWLFHlwdj6fy51HwrFRllnWnEBHvHDtZNDcXZ
         /PtS6tw+7k6/r2gjRJyf/sRcIxKbj8jLB4PuRVjua5So9dQ4zNwFsWAvwDh3Ep5L59BG
         CeZTIt2S/Nhr49PVPvIb/8Ras7LTetIXhTnL1G6tKJSChCiXdd4tZuuCOQsdzRSaY+zJ
         xnt+nMVL2jrlDgn3QbhW408/ruGKMioD4CRwI/885HwL0vTk3xxRfOPRBlTp05SjOg85
         nAwzuLz2Rc8MjOAMMyQLHajPyY8IyojiovbyA32outKrdGqv9IQu6S5Tz8fwMvY0Vv2D
         9t4Q==
X-Forwarded-Encrypted: i=1; AJvYcCX2vxrIcGUUe6V2gBVp5b5jk7LeYOw5DwtyQLbSGdMqhCyeTW90I2eL/il1zLoh/LNDtItR4fJKLs4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx6lO5NI3Tjt8Ie05RCXdK+gcCCBrr3SYm62tA6iACSVH1b419a
	yvs2cAuc8KoaYgRYsZTbcthNeOPXKeUmcnkUmASfQBiDRfpZGDRyyFkEXnkcmA==
X-Gm-Gg: ASbGncvlW1kGe2dd2x+cH1K4lourQ68HAOz2T3wMdcEuOzMwcQoCILPR+5zIDQDBeO0
	aTr/1Q5trmCK5BC3G50124lGn4dArkLLEa1HBwv7SCG/MiZkZUm34oPSMd+tOQtPze63Dv8HvLB
	l11qckGOBlBLGBh4bYQU5Xhss7K45jiGRNhJdL+kKdPWq1efYRt3dUK5miDsezOFUJHIJWE1KnL
	y9OA838dbXh/peKnQUV7LTwXJ52NwuR/QPRGqzQJUL7qZbSIl8ugJm/IMCRdgKxtFqUox/Iang1
	9m058/eGJvoMogvWO3G3MyQiuLZwGqzqFXSg/5MnoR6JVhpuoygtqfPm5zlbVmmsOWVZR8fBtUX
	olNiG/zt+mYJ4GFFTJfS81RZvPgriDF2DUd3D
X-Google-Smtp-Source: AGHT+IGF7P+W97cyL4RKmFF8g/lAkpuY+/rwoT5TqVKVjSE+jHYA/2UOREs2lLjwvdc1vQCo11Bw8Q==
X-Received: by 2002:a05:6402:5388:b0:5f8:e6de:fd0f with SMTP id 4fb4d7f45d1cf-5fca0770801mr12781385a12.15.1747134590623;
        Tue, 13 May 2025 04:09:50 -0700 (PDT)
Message-ID: <55e73266-7727-4a1c-93e8-dd69712d64d2@suse.com>
Date: Tue, 13 May 2025 13:09:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] Add lockdown mode
To: Kevin Lampis 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
References: <20250506162510.1676425-1-kevin.lampis@cloud.com>
 
 
 <504f0be0-91fd-4847-8fcd-505771674814@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

On 13.05.2025 13:07, Kevin Lampis wrote:
> On Tue, May 13, 2025 at 8:00 AM Jan Beulich  wrote:
>>
>> Well, there is an alternative: Require the lockdown argument to be absolutely
>> first. (There are further alternatives, but likely less usable.)
> 
> Is this your recommendation?

I would like this to at least be considered. As you likely were able to guess,
I don't like that custom command line parsing very much.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 11:56:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 11:56:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982766.1369098 (Exim 4.92)
	(envelope-from )
	id 1uEoFT-0003sl-NP; Tue, 13 May 2025 11:56:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982766.1369098; Tue, 13 May 2025 11:56: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 1uEoFT-0003se-KV; Tue, 13 May 2025 11:56:39 +0000
Received: by outflank-mailman (input) for mailman id 982766;
 Tue, 13 May 2025 11:56:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEoFR-0003sY-VA
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 11:56:38 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 52889e0d-2ff1-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 13:56:36 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-441d1ed82faso38614325e9.0
 for ; Tue, 13 May 2025 04:56:36 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442d67df5ecsm163763805e9.9.2025.05.13.04.56.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 04:56:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 52889e0d-2ff1-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747137396; x=1747742196; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=uKWHcb5UhDMvTvtdTVV8vNFfjuOzkIhKzAOTGnbwEO0=;
        b=VdKo6TyeIpD1Hx0qlVP6/1k6eC6MHnsq457XRJm/B8ND46gBNjTnS1vjP2tjAZC+2A
         B2spHDCJjTfxf0bRt3QGjhH+buJxKsZdL71cQR8fssCenHTqNiCvcQDIIQIPrgTiIVWh
         BxCkeMHWDJJ9i9RjnPfy20ErV2cKcebLaUH/M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747137396; x=1747742196;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uKWHcb5UhDMvTvtdTVV8vNFfjuOzkIhKzAOTGnbwEO0=;
        b=BIJ8Ka91GGpQOPTp1r73hwBqR1jpebK7NL4FDFRyDwtaVrNnEVoUoeXL1ZGJsQnWEW
         wH9lX008Ow2gl2Ikub3lsnzW3Zx6TWUV46sJBHW/P8LTD3onE0POGjtuggoNq9SeJKWp
         pQpO6nR5k33x3vnlB4ukwnT76HrxsZu98EESPrIBeAixpp3clx7AjcMINfMkNY6V6qjV
         N7SgWxq0CTLrqn9NOBO3m7SuPW+wtepzmU73h5hoK/xBH9MVo66vCM0lbpcXkhFPdwUg
         QjQL/oUIxrps3ZRMiXOMvUDK0/vx+0aaNI3HgvxgLEHkqqWmc+H/jjylanY3zKoRVk4l
         /T1A==
X-Forwarded-Encrypted: i=1; AJvYcCVim04OunjIwjHksM4mp5CrHpUm5eVyiKnW82QoiBZaG+OaEY170NJjTVHGEsXWFFnL7LYMGD9M43k=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yws5SQF2LHN39S00ppE71gr9QZ/ymlIDTAejZxs2wnS6+DO6+OG
	B0nIdcFdDHfx+WbLvMMQpn5YfwtySTfDAAhHtKRje+R+Mjkl/HwnPL39KBSlvVI=
X-Gm-Gg: ASbGncuhsJAy6GXyWExWtu+FfkI6cN6ToSNLrI6wfeKukuaNN44lTZ7GuoBqcZ/zZon
	VUieQD4mHqFYt7+zAiELTdQlQFhWuW2Qjimdb07Qzm05j1je5Qx16fVCbqwXSmzd8OjFNN0Yp/t
	JrrB99a0drohPwpem4xtcoHQRdTuVbntp2csi3Dm31k0XNj0A6Uu9X/SRvhdyD1Tudeii5Yo3CR
	EMV7lnNBwNioUkG8PC4nKqJs2wapDSQ+sDsSO6utnHkDowAeBo8yQjhD637h49sH6Lk7aiSPq2J
	z5DToRIZPs7hWcyBftwL/y9F8kQGBcYjkwiaKVBa7Kej5QQMHHxN5t3zVzK6l1X5Oz1mD91CZw+
	Zat3xxXqA/nU2C96sX/472RMvn70=
X-Google-Smtp-Source: AGHT+IEfoGTwU2AfFnFgCbKafDs1veM3mLjPpDZUhgH/p67yibV96JvUeTV+RfHFDakIwWqTYBYxxQ==
X-Received: by 2002:a05:6000:2ce:b0:3a0:b7e7:1076 with SMTP id ffacd0b85a97d-3a1f646d9ecmr12427534f8f.11.1747137396231;
        Tue, 13 May 2025 04:56:36 -0700 (PDT)
Message-ID: 
Date: Tue, 13 May 2025 12:56:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] crypto: Add RSA support
To: Jan Beulich ,
 Ross Lagerwall 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
 <20250506143218.1782603-3-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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/05/2025 1:38 pm, Jan Beulich wrote:
>> + *	Copyright (C) 1994, 1996, 1998, 2000 Free Software Foundation, Inc.
>> + *
>> + * This file is part of GnuPG.
>> + *
>> + * GnuPG is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * GnuPG is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
>> + *
>> + * Note: This code is heavily based on the GNU MP Library.
>> + *	 Actually it's the same code with only minor changes in the
>> + *	 way the data is stored; this is to support the abstraction
>> + *	 of an optional secure memory allocation which may be used
>> + *	 to avoid revealing of sensitive data due to paging etc.
>> + *	 The GNU MP Library itself is published under the LGPL;
>> + *	 however I decided to publish this code under the plain GPL.
>> + *
>> + * mpi.c code extracted from linux @ eef0df6a5953, lib/mpi
> I fear this line would go unnoticed with future changes, and hence go stale
> rather easily. Menioning the origin in just the commit message ought to be
> sufficient.
>
> Btw - how heavily did you need to adjust the code to pass our Eclair scan?
> Depending on that I then might raise the question of converting to proper
> Xen style (it currently isn't even proper Linux style, afaict).

I've put this through Eclair.  Single R16.3 (missing break) violation. 
Happy otherwise.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 13 12:48:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 12:48:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982798.1369149 (Exim 4.92)
	(envelope-from )
	id 1uEp3T-0001xm-OW; Tue, 13 May 2025 12:48:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982798.1369149; Tue, 13 May 2025 12: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 1uEp3T-0001xf-Kh; Tue, 13 May 2025 12:48:19 +0000
Received: by outflank-mailman (input) for mailman id 982798;
 Tue, 13 May 2025 12:48:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEp3S-0001xZ-FG
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 12:48:18 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8a9dcfb0-2ff8-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 14:48:17 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-442e9c00bf4so11139275e9.3
 for ; Tue, 13 May 2025 05:48:17 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442d5cf5d6bsm170957265e9.1.2025.05.13.05.48.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 13 May 2025 05: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" 
X-Inumbo-ID: 8a9dcfb0-2ff8-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747140496; x=1747745296; 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;
        bh=EwU7cIuXAcZQkhkLVi2ursHZkv24X8sAV3YSXlpJuPw=;
        b=fvevpl8JV/THltnaPQxgH6JG8guAfC8LRQX3G9XdFLG5r9WnYhvzkKdpme/DPyMjBl
         TDL6OMLsGAYLzTJFckvVijB8kzQoesxQ3wXFW8SglUS2qS1e9P5N9/eCHlywgecNof6g
         JO8+7zlqNCfCg98vRLpxCUKx0RXRzAH4pAhEQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747140496; x=1747745296;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=EwU7cIuXAcZQkhkLVi2ursHZkv24X8sAV3YSXlpJuPw=;
        b=BlYIdnw1qNJg3li1H/MqyXjGV6gyDRvWSnX/ubo58WCFbjF6xKMKCBgKVQBmo8PnuP
         MhDXiU2yOeiJBIVcZf3Vm7CbfCCxo6nMuiv/TUFclZ/c6vCASXcCLGZ3byEmadeCx9h+
         rjMIK8/wyzjX9ZC7zkUzs4W/CYz0kCq+DPmXXNDs1ECQk44d9irrTMyhHGwDP2YKKPMc
         +SpD/oa+L13/2tP+Dfq4L2JKGIQw1qYCnVvGTw6ELe/JYlaXYnIwQoxD2FWGZpbdzS16
         tKwAGSa3QGbl6zrzgZGnco4QZwxy9qiE+S1Hkbl/QgLis9PlFxkhrGUKvVm1YEeN+SVW
         KXgQ==
X-Gm-Message-State: AOJu0Yx6Tf5/vTJRMVS7JFTJVjmJoX6c4lNBGuK/jwNlvFpgrWp1nrEp
	zkeFzFbkl2B/wJzvJ1H6l0jRcmIlEvZBFlw/65nfE/QVx9REkqxMNcQw1dILObofEx3N5PtfQsC
	Y
X-Gm-Gg: ASbGncuBaqJ7PLW8cHCnBXl9bJcWGzTKkheLuy7CV+tok36w7RDFc05VoWHtRcMINfk
	tjOUg1a99HBpKRJ2WiqIK4jbvKDYig3cwq1BvRKpb7Eq5B52IAQv5X+M0SoLX9KQLV19v7kEsG5
	vRjbGTRyVLKqdzk5AmcFsj0sK0lgkDZfcfffbXOWyZgMgG1+9Qhm069w6QfjPPUiulHV57aVrfT
	8QeePwZBkl8BJhwGuxoSAbcGop7smU9zHfa05t9ko8J2Y0yCAqO1tITV2AnIH0X1qFi57vjOYig
	5/dxz05beGdgPt1ypzZ9VpEmwVWLltH0Id98IaD2NANtsF9+mTka5aizd4O9Q/SYSr/6rubZcdB
	SkEitIgMh46qVxv8XOlY5eaoB
X-Google-Smtp-Source: AGHT+IFCknagyukqmUBlsMqarGV3XhKu5cMo7JA5t+Y0usDLHGSMDC2/Ehb0SBbA29gxnoaHoxlEwQ==
X-Received: by 2002:a05:600c:b91:b0:441:b3eb:5720 with SMTP id 5b1f17b1804b1-442d6ddeb79mr135079065e9.29.1747140496511;
        Tue, 13 May 2025 05:48:16 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/spec-ctrl: Support Intel's new PB-OPT
Date: Tue, 13 May 2025 13:48:14 +0100
Message-Id: <20250513124814.3500710-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

In IPU 2025.2 (May 2025), Intel have released an alternative mitigation for a
prior security issue (SA-00982) on Sappire and Emerald Rapids CPUs.

Intel suggest that certain workloads will benefit from using the alternative
mode.  This can be selected by booting with `spec-ctrl=ibpb-alt`.

https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/cpuid-enumeration-and-architectural-msrs.html
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

Intel have named this PBOPT (no space), but that's too close to PBRSB for my
liking.  PB_OPT (with a space) is also consistent with MCU_OPT, it's closest
neighbour.

I've chosen not to extend print_details() with this.  It's specific to two
Intel CPUs and not being continued into future ones.

I'm not sure what else to say in the cmdline docs.  Intel is very sparse on
details.  An educated guess is that in the default mode, part of the predictor
is inhibited, while in the alternative mode it's active, but at the cost of
extra scrubbing in IBPB.
---
 docs/misc/xen-command-line.pandoc           |  6 ++++-
 xen/arch/x86/acpi/power.c                   |  1 +
 xen/arch/x86/cpu/intel.c                    | 28 +++++++++++++++++++++
 xen/arch/x86/include/asm/cpufeature.h       |  1 +
 xen/arch/x86/include/asm/msr-index.h        |  3 +++
 xen/arch/x86/include/asm/processor.h        |  3 +++
 xen/arch/x86/smpboot.c                      |  1 +
 xen/arch/x86/spec_ctrl.c                    |  7 ++++++
 xen/include/public/arch-x86/cpufeatureset.h |  1 +
 9 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 89db6e83be66..b0eadd2c5d58 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2470,7 +2470,7 @@ By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
 >              {ibrs,ibpb,ssbd,psfd,
 >              eager-fpu,l1d-flush,branch-harden,srb-lock,
 >              unpriv-mmio,gds-mit,div-scrub,lock-harden,
->              bhi-dis-s,bp-spec-reduce}= ]`
+>              bhi-dis-s,bp-spec-reduce,ibpb-alt}= ]`
 
 Controls for speculative execution sidechannel mitigations.  By default, Xen
 will pick the most appropriate mitigations based on compiled in support,
@@ -2626,6 +2626,10 @@ bp-spec-reduce when available, as it is preferable to using `ibpb-entry=hvm`
 to mitigate SRSO for HVM guests, and because it is a prerequisite to advertise
 SRSO_U/S_NO to PV guests.
 
+On Sappire and Emerald Rapids CPUs with May 2025 microcode or later, the
+`ibpb-alt=` option can be used to switch to the alternative mitigation for
+Intel SA-00982.  Intel suggest that some workloads will benefit from this.
+
 ### sync_console
 > `= `
 
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 3196a33b1918..095ca391ad22 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -306,6 +306,7 @@ static int enter_state(u32 state)
     }
 
     update_mcu_opt_ctrl();
+    update_pb_opt_ctrl();
 
     /*
      * This should be before restoring CR4, but that is earlier in asm and
diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 12c3ff65e02f..ef9368167a0d 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -49,6 +49,34 @@ void __init set_in_mcu_opt_ctrl(uint32_t mask, uint32_t val)
     update_mcu_opt_ctrl();
 }
 
+static uint32_t __ro_after_init pb_opt_ctrl_mask;
+static uint32_t __ro_after_init pb_opt_ctrl_val;
+
+void update_pb_opt_ctrl(void)
+{
+    uint32_t mask = pb_opt_ctrl_mask, lo, hi;
+
+    if ( !mask )
+        return;
+
+    rdmsr(MSR_PB_OPT_CTRL, lo, hi);
+
+    lo &= ~mask;
+    lo |= pb_opt_ctrl_val;
+
+    wrmsr(MSR_PB_OPT_CTRL, lo, hi);
+}
+
+void __init set_in_pb_opt_ctrl(uint32_t mask, uint32_t val)
+{
+    pb_opt_ctrl_mask |= mask;
+
+    pb_opt_ctrl_val &= ~mask;
+    pb_opt_ctrl_val |= (val & mask);
+
+    update_pb_opt_ctrl();
+}
+
 /*
  * Processors which have self-snooping capability can handle conflicting
  * memory type across CPUs by snooping its own cache. However, there exists
diff --git a/xen/arch/x86/include/asm/cpufeature.h b/xen/arch/x86/include/asm/cpufeature.h
index 397a04af41a1..6c5f5ce0cfc5 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -219,6 +219,7 @@ static inline bool boot_cpu_has(unsigned int feat)
 #define cpu_has_gds_no          boot_cpu_has(X86_FEATURE_GDS_NO)
 #define cpu_has_rfds_no         boot_cpu_has(X86_FEATURE_RFDS_NO)
 #define cpu_has_rfds_clear      boot_cpu_has(X86_FEATURE_RFDS_CLEAR)
+#define cpu_has_pb_opt_ctrl     boot_cpu_has(X86_FEATURE_PB_OPT_CTRL)
 #define cpu_has_its_no          boot_cpu_has(X86_FEATURE_ITS_NO)
 
 /* Synthesized. */
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 22d9e76e5521..6f2c3147e343 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -56,6 +56,9 @@
 #define MSR_MISC_PACKAGE_CTRL               0x000000bc
 #define  PGK_CTRL_ENERGY_FILTER_EN          (_AC(1, ULL) <<  0)
 
+#define MSR_PB_OPT_CTRL                     0x000000bf
+#define  PB_OPT_IBPB_ALT                    (_AC(1, ULL) <<  0)
+
 #define MSR_CORE_CAPABILITIES               0x000000cf
 #define  CORE_CAPS_SPLITLOCK_DETECT         (_AC(1, ULL) <<  5)
 
diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index 75af7ea3c476..eacd425c5350 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -470,6 +470,9 @@ static inline void tsx_init(void) {}
 void update_mcu_opt_ctrl(void);
 void set_in_mcu_opt_ctrl(uint32_t mask, uint32_t val);
 
+void update_pb_opt_ctrl(void);
+void set_in_pb_opt_ctrl(uint32_t mask, uint32_t val);
+
 enum ap_boot_method {
     AP_BOOT_NORMAL,
     AP_BOOT_SKINIT,
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 54207e6d8830..80c729d74895 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -383,6 +383,7 @@ void asmlinkage start_secondary(void *unused)
         info->last_spec_ctrl = default_xen_spec_ctrl;
     }
     update_mcu_opt_ctrl();
+    update_pb_opt_ctrl();
 
     tsx_init(); /* Needs microcode.  May change HLE/RTM feature bits. */
 
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 0a635025e488..79c0a9df66f8 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -85,6 +85,8 @@ static int8_t __initdata opt_gds_mit = -1;
 static int8_t __initdata opt_div_scrub = -1;
 bool __ro_after_init opt_bp_spec_reduce = true;
 
+static __initdata bool opt_ibpb_alt;
+
 static int __init cf_check parse_spec_ctrl(const char *s)
 {
     const char *ss;
@@ -369,6 +371,8 @@ static int __init cf_check parse_spec_ctrl(const char *s)
             opt_div_scrub = val;
         else if ( (val = parse_boolean("bp-spec-reduce", s, ss)) >= 0 )
             opt_bp_spec_reduce = val;
+        else if ( (val = parse_boolean("ibpb-alt", s, ss)) >= 0 )
+            opt_ibpb_alt = val;
         else
             rc = -EINVAL;
 
@@ -2494,6 +2498,9 @@ void __init init_speculation_mitigations(void)
         wrmsrl(MSR_SPEC_CTRL, val);
         info->last_spec_ctrl = val;
     }
+
+    if ( cpu_has_pb_opt_ctrl )
+        set_in_pb_opt_ctrl(PB_OPT_IBPB_ALT, opt_ibpb_alt);
 }
 
 static void __init __maybe_unused build_assertions(void)
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index a6d4a0cba7d8..044230bfe854 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -392,6 +392,7 @@ XEN_CPUFEATURE(IGN_UMONITOR,       16*32+29) /*   MCU_OPT_CTRL.IGN_UMONITOR */
 XEN_CPUFEATURE(MON_UMON_MITG,      16*32+30) /*   MCU_OPT_CTRL.MON_UMON_MITG */
 
 /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.edx, word 17 (express in terms of word 16) */
+XEN_CPUFEATURE(PB_OPT_CTRL,        16*32+32) /*   MSR_PB_OPT_CTRL.IBPB_ALT */
 XEN_CPUFEATURE(ITS_NO,             16*32+62) /*!A No Indirect Target Selection */
 
 #endif /* XEN_CPUFEATURE */

base-commit: f6042f38e621525feff86bb101dc751d2d87cff8
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue May 13 13:02:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 13:02:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982808.1369160 (Exim 4.92)
	(envelope-from )
	id 1uEpGl-0004dS-Rb; Tue, 13 May 2025 13:02:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982808.1369160; Tue, 13 May 2025 13:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEpGl-0004dL-Nk; Tue, 13 May 2025 13:02:03 +0000
Received: by outflank-mailman (input) for mailman id 982808;
 Tue, 13 May 2025 13:02:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEpGk-0004dD-MU
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 13:02:02 +0000
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com
 [2607:f8b0:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7579791e-2ffa-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 15:02:01 +0200 (CEST)
Received: by mail-pl1-x630.google.com with SMTP id
 d9443c01a7336-2301ac32320so22155955ad.1
 for ; Tue, 13 May 2025 06:02:01 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-22fc82a16basm80004475ad.230.2025.05.13.06.01.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 13 May 2025 06:01: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" 
X-Inumbo-ID: 7579791e-2ffa-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747141320; x=1747746120; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=lc3BOQgtPalWPQo2SYdws3VVJyyUIiwl4Eaj0tViT5k=;
        b=NEGL4X5QuqN8cPvUZImTa4K75/WYkXKQlstTnO0s5y4OZQ4jCbRfVjW5FMSTfPONZX
         HYttMI5bSW50Hblr+QS41jfsxf0JduD/KWNqZW+j/U3geX0feNXfXV8kRgsTjwHRjURR
         mcOYde72e8Vjgp9GW85P6dVprQz1gOSC1wzJs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747141320; x=1747746120;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=lc3BOQgtPalWPQo2SYdws3VVJyyUIiwl4Eaj0tViT5k=;
        b=YnVcc1ljT7b3GVfm16jdsGoRaPHQwfhQbgtPqWKSmvz4lYcFkxnP8E7Othiewtb+H5
         fhbslq46q67XYDWblvTVbu2QpEcDK4aKgmI0bPdGdwU0m2oELhRbmO3kkYIZaNulYZAJ
         WuowbhJLWxp3c9QOvplStZYq3+7+xrPAnzYYQLqVaiX5A3Mxxdmx+cpZ1dG6qnXS+I/l
         B1jFNJsR4ER2TvcexX0wkSopGQ3E441Qqa1Z1VSfiWFin4zQgIEknVvcv9yr25M4ulkg
         2ZhNOgdMcMWkwrO57jrHgS6amuHz4kEwNPR8ptxcerqnY4rPGB2ViRsv9VY1SYLKOI6Z
         TVzg==
X-Gm-Message-State: AOJu0YwAPHxE0MqFhLLUgJ6rjFRmMUJ5KURh3OY/UyY4JG+wu8GJYcgg
	J0cxyBqZAUAiboTFv2JwSQciUws207DEg+1AhvBDM2CpI/ehNGp02Q9T3m/Q9ZU=
X-Gm-Gg: ASbGncuBMYoLZyQW/GrLhHiDxkG8vgeBUSBeFRx1U+0qYfxmMP0zvOJbg74FmZraIhp
	fZEog69szTuA5AqbL060Sodx11O+OWVB3MvrA1PBYzwEqbg0cRoYpFDS2EPazthOJfjgLGKQHCM
	ZZWWCwvQoU0MsMkWrEhMLJ0mqK5STYQ2AcNSQ6jzA1LNGDVEy/KqBQpaccgQgPaMNwrb0ZRFoBi
	qL2XaUTS+OVouPK1jZi1N1/Rlbyw1dbjpu0NqBw90RSERX5YGeh5/yhro7Nt4tOIAH5hMymRsCI
	FgxTG5Qt2TYzmdeD1+RZUlAC81LXblj6ju6oPNOqoQ9lji+IyL5C8/1fqpyBrA==
X-Google-Smtp-Source: AGHT+IHgAhPx5do4QHswfjkdmFRUXRGa5Si/o37pZLP+q8VQckuelOUeZwBMJn2v5Hr8IQu/tHvMQg==
X-Received: by 2002:a17:902:ce12:b0:223:3396:15e8 with SMTP id d9443c01a7336-22fc8b6cbd0mr303518315ad.22.1747141320055;
        Tue, 13 May 2025 06:02:00 -0700 (PDT)
Date: Tue, 13 May 2025 15:01:54 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu 
Subject: Re: [PATCH v2 1/6] x86: support cache-writeback in
 flush_area_local() et al
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, May 03, 2023 at 11:44:39AM +0200, Jan Beulich wrote:
> The majority of the present callers really aren't after invalidating
> cache contents, but only after writeback. Make this available by simply
> extending the FLUSH_CACHE handling accordingly. No feature checks are
> required here: cache_writeback() falls back to cache_flush() as
> necessary, while WBNOINVD degenerates to WBINVD on older hardware.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

> ---
> v2: FLUSH_WRITEBACK -> FLUSH_CACHE_WRITEBACK.
> 
> --- a/xen/arch/x86/flushtlb.c
> +++ b/xen/arch/x86/flushtlb.c
> @@ -232,7 +232,7 @@ unsigned int flush_area_local(const void
>      if ( flags & FLUSH_HVM_ASID_CORE )
>          hvm_flush_guest_tlbs();
>  
> -    if ( flags & FLUSH_CACHE )
> +    if ( flags & (FLUSH_CACHE | FLUSH_CACHE_WRITEBACK) )
>      {
>          const struct cpuinfo_x86 *c = ¤t_cpu_data;
>          unsigned long sz = 0;
> @@ -245,13 +245,16 @@ unsigned int flush_area_local(const void
>               c->x86_clflush_size && c->x86_cache_size && sz &&
>               ((sz >> 10) < c->x86_cache_size) )
>          {
> -            cache_flush(va, sz);
> -            flags &= ~FLUSH_CACHE;
> +            if ( flags & FLUSH_CACHE )
> +                cache_flush(va, sz);
> +            else
> +                cache_writeback(va, sz);
> +            flags &= ~(FLUSH_CACHE | FLUSH_CACHE_WRITEBACK);
>          }
> -        else
> -        {
> +        else if ( flags & FLUSH_CACHE )
>              wbinvd();
> -        }
> +        else
> +            wbnoinvd();
>      }
>  
>      if ( flags & FLUSH_ROOT_PGTBL )
> --- a/xen/arch/x86/include/asm/flushtlb.h
> +++ b/xen/arch/x86/include/asm/flushtlb.h
> @@ -135,6 +135,8 @@ void switch_cr3_cr4(unsigned long cr3, u
>  #else
>  # define FLUSH_NO_ASSIST 0
>  #endif
> + /* Write back data cache contents */
> +#define FLUSH_CACHE_WRITEBACK  0x10000
>  
>  /* Flush local TLBs/caches. */
>  unsigned int flush_area_local(const void *va, unsigned int flags);
> @@ -194,7 +196,11 @@ static inline int clean_and_invalidate_d
>  }
>  static inline int clean_dcache_va_range(const void *p, unsigned long size)
>  {
> -    return clean_and_invalidate_dcache_va_range(p, size);
> +    unsigned int order = get_order_from_bytes(size);
> +
> +    /* sub-page granularity support needs to be added if necessary */
> +    flush_area_local(p, FLUSH_CACHE_WRITEBACK | FLUSH_ORDER(order));
> +    return 0;
>  }

I'm planning to get rid of the clean_dcache_va_range() helper on x86,
but I don't want to force you to rebase on top of that.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 13 13:13:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 13:13:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982818.1369169 (Exim 4.92)
	(envelope-from )
	id 1uEpRK-0006IO-PQ; Tue, 13 May 2025 13:12:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982818.1369169; Tue, 13 May 2025 13: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 1uEpRK-0006IH-Lh; Tue, 13 May 2025 13:12:58 +0000
Received: by outflank-mailman (input) for mailman id 982818;
 Tue, 13 May 2025 13:12:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEpRI-0006IB-W7
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 13:12:56 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fc1694e2-2ffb-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 15:12:56 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43edecbfb46so40603265e9.0
 for ; Tue, 13 May 2025 06:12:56 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442cd32835dsm212502055e9.6.2025.05.13.06.12.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 06:12: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" 
X-Inumbo-ID: fc1694e2-2ffb-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747141976; x=1747746776; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dxbm6FfLxgSxrosKDyA/5smhaagyBlWg54myvnyjRLo=;
        b=fg1K0/pNZcJU0QXlOCnfnoBDcpg1Qix/e2pMdx20K5J+2vza6/ITx3l2H7PATmOONE
         KjHJLslIbwDGsDXh1S++57cOIbTtk+/n22O8JNLiQTNyMqCUoGnTtdRl9Lixx06U4xjK
         z9h0h6H0vyzgnTjmCvO9MTDRvUqHu/zg6GLFM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747141976; x=1747746776;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=dxbm6FfLxgSxrosKDyA/5smhaagyBlWg54myvnyjRLo=;
        b=P7qjPcnM2yzDYJBey211ombY5c61DkHQCC2jjh129ciw73/8wG0P8ItT4igRokUHwq
         BDzyCgpc9E3utF+ScnuENH7fcPuiuUcqxMBvyM8fV2Ebb17T0zvh8Ojz4drOxqrHhpnf
         Hkh9Gvmi62ufmebA+8UDj6kUiern3jA04kA7w962Z79QBsP7xvE9WFNDo7HfA32rtVcw
         8yakrjg2WE6sbEJsCGOHdhljPxUbeJback8y0Ib3y0/2QvTMzUckh6viT7hnEGMbaivV
         SqpEMePUUGu5+12p55/kLHOpvxXGvsoYYjMsnRTaCB+38kQmfYH1IEuc2VLfn1A1WVI2
         X+og==
X-Forwarded-Encrypted: i=1; AJvYcCU7nuMoz4H5wN51dz62e4PaDtgmEEtsgk+CHjYKQiR3iIh8ExSzKnxebBWEPrP0mOcWbYiT2SEOaEY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzAR/RXA0efuGkiyKhUphwyme9uGRGczK5OtM0p0XEfpVy+oMHm
	g8DyWysM0hmz5Ye6DFcf8z/QXFmoMq/nHLlXQnh2wtqRmJCBt7fAFWXAAQIKVY0=
X-Gm-Gg: ASbGnct+fqJesuw2OrwYi1tqu0z5zwjUV1HIOM32aZX45xe6qF7hrE2TBZvxeghMW2y
	Reyy4funY0h1sjtYl06GQcsNfwmCXomatWLso5miSVrdE/N6Pcd8vrAZ0Nd47rvUh/ZfU5TUKfb
	1CQAL637DAEZapd2CPmMlJ/U0IKiP/cDYXpXiYFYtlgxC5FrMIMtftAUtCJ1VfwzXR8PzMf0X80
	zB5JSy6Mwj2H7ma4RB+UViX8FRgfjFXAi304p4iyC0ySVrHHI3KKbmoRuTg4I28n/7NHsOR9+PM
	BGIVD/d9L7699eHCEPsm3Yz9wJ6RAYiyJBtMW4rOlknpVdxVoUeiE0ldGHU8aiawX8NE93ShIID
	KFa4ykWYY11oQDyTu
X-Google-Smtp-Source: AGHT+IGoUK1HQ9eR00vqS2di41ozphOsdw79AI0JKFx58TF9zGan6LhGXzr+mOn6A7AVhmzal2uHTg==
X-Received: by 2002:a05:600c:6308:b0:43d:db5:7b1a with SMTP id 5b1f17b1804b1-442d6d44a99mr167653565e9.12.1747141975621;
        Tue, 13 May 2025 06:12:55 -0700 (PDT)
Message-ID: 
Date: Tue, 13 May 2025 14:12:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache
 writeback
To: Jan Beulich ,
 "xen-devel@lists.xenproject.org" 
Cc: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
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

On 03/05/2023 10:45 am, Jan Beulich wrote:
> We allow its use for writeback purposes only anyway, so let's also carry
> these out that way on capable hardware.
>
> With it now known that WBNOINVD uses the same VM exit code as WBINVD for
> both SVM and VT-x, we can now also expose the feature that way without
> further distinguishing the specific cases of those VM exits. Note that
> on SVM this builds upon INSTR_WBINVD also covering WBNOINVD, as the
> decoder won't set prefix related bits for this encoding in the resulting
> canonicalized opcode.
>
> Signed-off-by: Jan Beulich 

I realise this is an old series, but this patch is unsafe with AMD
SEV-SNP, and with CLX devices.

Both have cases needing "genuinely evicted from the cache" semantics.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 13 13:24:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 13:24:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982829.1369179 (Exim 4.92)
	(envelope-from )
	id 1uEpco-0007yO-Og; Tue, 13 May 2025 13:24:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982829.1369179; Tue, 13 May 2025 13:24: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 1uEpco-0007yH-M5; Tue, 13 May 2025 13:24:50 +0000
Received: by outflank-mailman (input) for mailman id 982829;
 Tue, 13 May 2025 13:24:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEpcn-0007y7-2b
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 13:24:49 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9ba308b0-2ffd-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 15:24:33 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad21cc2594eso39432666b.1
 for ; Tue, 13 May 2025 06: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
 a640c23a62f3a-ad240b9eef6sm521604466b.18.2025.05.13.06.24.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 06: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" 
X-Inumbo-ID: 9ba308b0-2ffd-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747142673; x=1747747473; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Szsem0vjoKRmGaJdXPSsANG4HF1hiEVt+argooWFnto=;
        b=K6QuuTGAd4bUoghvJ+sLfzAttejSe9xVz3VfxhMLB+RmIe2a/9Tv1zuRiOhys0a3vK
         zTgdojBfSWOYJ0XYUr4r2KMZlWblQ8n81UyrpVEBJCto1SHvOun2bjctZfwRcCQMenPc
         ReCqeXpU3r7ElhrwgBNfYiq9t3R35YWYQBVgMneCL8ANhJn21wBO6GZf/q2S4hr49aSE
         XvuHit+mxkUbpAZ2OX3MgvPsSYa7IKWV1LybkbIxfy1OJhfgPv8MCjzF+XJahwDkK3Gy
         ffNFRK097DbJlHTiZ0W9SxBhggIpVu++IybPO1w5RGECY/BWQDs68piPQ84aI4eEMosr
         WYKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747142673; x=1747747473;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Szsem0vjoKRmGaJdXPSsANG4HF1hiEVt+argooWFnto=;
        b=FUiiTi8GCFqx4DhGXA2BvWvZFvkKWAn5185DxOIhagM2qN3fNZQ0u5OQMcG+H1+uG8
         Jn5abrg4QVzzRxcUWMyOhfjILCaZlg1IMG8aTPcnBReBGx4X+6xohVbDjhvkIExW4OJ1
         syChIvLHca0wEA7grMEHII00YMSa534oeKylk0dtSiQ9s8BG93gFzKv7T3ZB5aYGVMfQ
         uFi52dK9f7HX9zK02cN7rxbSsfhhNwIPt+os7W+pIn1+t2gx32REbEPWC3EWyuhBqoDn
         FStIo6GQAq1IIVZRW8Rx45jACK1NGAMvnndRZYKNZQOtUVEDXxBNq0Qe2ELli8Y5qxcd
         ieHw==
X-Forwarded-Encrypted: i=1; AJvYcCVo9hWOwkmgg8V4BxdmluaTQUtskxpsHvuwKV0iCoIB+57LeQVo9Iq75Q++PU70mXKbaFLtdJkrbic=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywr+S66sY8L5nek9XcsJ//r93fwdeEWZD8xF1sF22jC+W08xjfm
	95CMUXMj4zdJeFnMsRrKQQZdoRjMNIy20lKLGif0G0koirCNR31LGTR9MMMrbg==
X-Gm-Gg: ASbGncvIG/eCY2dbzEVXCgkiEnR2vbUO8ctN1xKx0cXS/QGIaqYVbG5vxQ17gJFPeq8
	rWBhsx4BvB4MTH42N61x9fvL5/dIvNdBuAEpW/Cup3bCufQBUS5wMdenhXZfBXWVD5Ae36RFuoa
	66Czw3LJ0EoEDgxO5uSM0+9yKCsY1Zh4rCJNYFHbq5E4SgP9HyNTkzyfpYDYxzuxZ7ZdNNru1hj
	3JCbRzJzF4sTNLOzMj/v/Gc5Ddl3LN3BCP1CztsgW2tcJ/sl1Y49WkK4sJy3bJ15XgmR/JvMbHf
	riUuTxKK6+2S4Y5iCdocSjzKqcvhzYbwnqC7nCv/Mlji47ngOR5dIJfvoz1dK3U3F959UxTusE7
	nGlD6u9wtklJKhxdFE3gnYkoNuj3LguUnmLTS
X-Google-Smtp-Source: AGHT+IFqcbwCTmFalhTMPwWfZZLf+7DaKL20v+ss4JtWCWDsvjX+VF/yo4sn/Vt6iAvYx00E9h8pwQ==
X-Received: by 2002:a17:906:5415:b0:ad2:1cd7:cefc with SMTP id a640c23a62f3a-ad21cd7d3f1mr1155521266b.13.1747142672837;
        Tue, 13 May 2025 06:24:32 -0700 (PDT)
Message-ID: <25448dec-63f1-4b24-a8be-f5d0a1e7ca6b@suse.com>
Date: Tue, 13 May 2025 15:24:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache
 writeback
To: Andrew Cooper 
Cc: Wei Liu , =?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

On 13.05.2025 15:12, Andrew Cooper wrote:
> On 03/05/2023 10:45 am, Jan Beulich wrote:
>> We allow its use for writeback purposes only anyway, so let's also carry
>> these out that way on capable hardware.

By implication of what you say ...

>> With it now known that WBNOINVD uses the same VM exit code as WBINVD for
>> both SVM and VT-x, we can now also expose the feature that way without
>> further distinguishing the specific cases of those VM exits. Note that
>> on SVM this builds upon INSTR_WBINVD also covering WBNOINVD, as the
>> decoder won't set prefix related bits for this encoding in the resulting
>> canonicalized opcode.
>>
>> Signed-off-by: Jan Beulich 
> 
> I realise this is an old series,

Well, it's old because no-one cared to look at the v2 posting in over 2
years.

> but this patch is unsafe with AMD SEV-SNP, and with CLX devices.
> 
> Both have cases needing "genuinely evicted from the cache" semantics.

... here, are you suggesting that our present behavior is wrong? We don't
have SEV-SNP support yet, so there it would only be "latently wrong" (and
hence the change here would still be correct for now). What CLX is in
this context I'm afraid I don't know (since surely you're not talking
about vapes, the closest I can spot in search results is something gaming
related, yet still not becoming very clear). I might have guessed
Cascade Lake X, but then why would just that one model be a problem?

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 13:39:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 13:39:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982843.1369189 (Exim 4.92)
	(envelope-from )
	id 1uEpqc-0001MR-3A; Tue, 13 May 2025 13:39:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982843.1369189; Tue, 13 May 2025 13:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEpqc-0001MK-0A; Tue, 13 May 2025 13:39:06 +0000
Received: by outflank-mailman (input) for mailman id 982843;
 Tue, 13 May 2025 13:39:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEpqb-0001ME-CQ
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 13:39:05 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20601.outbound.protection.outlook.com
 [2a01:111:f403:2412::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a17e3fba-2fff-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 15:39:02 +0200 (CEST)
Received: from BN0PR10CA0008.namprd10.prod.outlook.com (2603:10b6:408:143::27)
 by DS5PPF1ADAD2878.namprd12.prod.outlook.com (2603:10b6:f:fc00::646)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.34; Tue, 13 May
 2025 13:38:57 +0000
Received: from BN3PEPF0000B371.namprd21.prod.outlook.com
 (2603:10b6:408:143:cafe::25) by BN0PR10CA0008.outlook.office365.com
 (2603:10b6:408:143::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.25 via Frontend Transport; Tue,
 13 May 2025 13:38:57 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN3PEPF0000B371.mail.protection.outlook.com (10.167.243.168) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.1 via Frontend Transport; Tue, 13 May 2025 13:38:57 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 13 May
 2025 08:38:57 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 13 May
 2025 08:38:56 -0500
Received: from [192.168.94.239] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 13 May 2025 08:38: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" 
X-Inumbo-ID: a17e3fba-2fff-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=koZDTQbC3aCSbV5E8VjuMfPOacq1poNuzD4nno+Oc8eNCvRcQPkcEy72CUchFnbSiNbWPNqJRkyP7K+M4OBi+QKeoP7u5sB17B04K2dvwzojypjnqUMARMD0Bd4xCrZGLCgeemZh9w7hAfmXs7Sb0Le82QEVcWJvcAQ/vvKVMPREJnxeDmpGaftZD26YvagfR9AvsQ+oBWIC8zG/EkzsBkVIxkhvicBbkQViur4jlh8yWI+jVugq+dbTDAv1kp2opaXguR0nVKcyBzvYhddYVd6Yp5D2pxv21y+pNqx/gie4z8/RjsHgKKy544MJg3KrNxsAd6H0cEYuzgrzvbcOSA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=orluJ8TcxPOIyUFAoseuIzVylR2FrEPCWeTZIvbzfqc=;
 b=xHo2s9TJezVmlpXa1ZlxODWIJEzwhX7vrWi/6UlPDixUgxKnbkOviuadH15cuhmkDIS3Mr0IFIb+t+OerVsPfpiWOvbnIKIxLSJ82iESHI3o7K41/mGRyxiptc8zStJB7gP3xfypB/+V2G5h2W/6qnNKANyRl6Vna6LcTz6tr9IzNeqofTSlwgVeW+qRWuKgzWpM47Aw6gkYI9wYxtDUYeWNc66awbHw1PN6OGAhCCqbuM4+lb/5XuJE/ZJjLLXCEoQTY2+ZjpTvlgdt74wu0Ik5RtdUeyWRTB/3yhZr+b+YOZl4t8uNA//hSHjeWsfCmyStlFQo8eBtLgZ8VNBZNw==
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=orluJ8TcxPOIyUFAoseuIzVylR2FrEPCWeTZIvbzfqc=;
 b=xsLogA4NedjxkHVNlQ9SfEl8Vn8PCpNa9NhKLtUyveX2YE/x5WMAuEc0+6W8cIRGmCAyP9vZ3wep1l8uwSwzyRIeBnodKhg1ii4t6iTKAj+Lh/MsWTPkJSzPjNsPy/fEPx9AchG9uqh10RAsriFW1gXkWtMdo+Ukl9gLqt1B2Iw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Tue, 13 May 2025 09:38:57 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools/libxl: Only access legacy altp2m on HVM
To: Jan Beulich 
CC: Anthony PERARD , Juergen Gross
	, 
References: <20250512235409.18545-1-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: BN3PEPF0000B371:EE_|DS5PPF1ADAD2878:EE_
X-MS-Office365-Filtering-Correlation-Id: 428e8d24-2eec-4907-3ca7-08dd922382fb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bUdOYWJHMERta1NGTExjWldGU1ViblB6eVY0NEpYZXlNbkNTeWo0ZVQ3K2Vq?=
 =?utf-8?B?ZW9yY0dTSE92eTNodytaM1NiQWZ6SE1YTGVRL0NZTFY3Y1ltekJzR0hUZlFm?=
 =?utf-8?B?ZzZXL1d0MW9KTHIzYVk1NCtOdXhWQU5TR05oQzk3RzBlVXIwZ1EvUU94RStJ?=
 =?utf-8?B?cnFCQmxjNjZ4OHBnUVg4blY2ZUtPcXVDRHRydkp3REVmUDNrZkdhRnNBUkUr?=
 =?utf-8?B?TEtGZFBaZjlxRmFuVVVWQ2NKWm1hdDF0UjlxeDRrenBESDN5VVNMRE9hMFRX?=
 =?utf-8?B?ZUd6eXc4QVVrREhMVzYweC9CN1ZaTDBaYlRGejJHMUw0elRXWXVoVitLL0Iy?=
 =?utf-8?B?NU1SVm1SUzQxVW9RaVFqaytzQjhBYU9RR3NNbUxNQjlOZVRyRzZhRFBHQkZU?=
 =?utf-8?B?dmlmWFpxVVNkUVc0SnJxVzdsVWp3YWl3eDR1cmN4WEQ0Sitjd3dLWnpSaStS?=
 =?utf-8?B?VkpENW44VmlKUUtnTGZRVHhwTjQvV2ptWDFNelpCWTBGdExYbjJSeTFkSkNT?=
 =?utf-8?B?ZFc5THkrSGRtSWFjcVc2UUtUL1k5UjUxT2tOK2dJc0hSMXE2UEowU1NZWGhG?=
 =?utf-8?B?eE5qamc1YmZVRlhMKzRGWUNOeGJIUTZqZUsrMCtESjdCZUVGaUorbXdZMC9W?=
 =?utf-8?B?OWZnOEYzN3phUkkyTTFyRFZJL0xUTnkzS3JhR0wwMVlMMWpzK3VBaUU4aVY1?=
 =?utf-8?B?a2YvVVNDdGxSelFJcG5KekxBSHBTK085aEo4emg0NlE1c3k2c3VwK2ptbDNt?=
 =?utf-8?B?dU5KVXNjTUQ0cGIyaGU5UU9vejQ5SURuZVl0VllWd2lZQXpTS3U0WDltK1J0?=
 =?utf-8?B?ak9yNHV2V1VBUzJGSTBsT2x4ekRMdFJNRTRmbFFwamtCM3NRa0RwRjZQQlNP?=
 =?utf-8?B?WkQ0Y0VYMlhOVmYrL0IwMkdRY0YvVE84bFg5Qkt0TlhrSWxBa1RJbHk4VEto?=
 =?utf-8?B?YUYrN2QxQ0U2Z1VHd1hjaStWS0lLbnRiT1NQcnAxbzduaEpFWUYzcXArVEIx?=
 =?utf-8?B?dEswYjJ1OUJBSHU0a0lmYTlXbGxaclNjS0Q1L3dUSTY0eHJpMXJKNzZwWkpa?=
 =?utf-8?B?NFcwZzZ0cFRCWVBQZWhreDVvYVZrY1lyUXd2MCsyWXRiRkpkYzRiWS9ZMGFJ?=
 =?utf-8?B?UnpqR2pVUXNtZ2p4eFdaWFp1VVR3cHAzb2R3TEZEa1ZYYmYySG96dzZaMHh6?=
 =?utf-8?B?QkNVZUduM1k3clhDV01Ick9tUUI0OGY2ZnhRZkU2VzJibTI3anlnQmRpVllB?=
 =?utf-8?B?d1VjRkJINkdtSnZsdCtlOWRjZ2dUQlJzTDJRa1BIOW5kM2h4Qk05ak0rR0Vv?=
 =?utf-8?B?bVBCeG1aMDhCS1FZRzIwYlJYbmhCc25lTjVYWDBKOGdLRTV4M3M2YVFkb2h1?=
 =?utf-8?B?Wjk5Y0lOVFhNTXRPTHQ1b0R3S0JUbHJ5bk1VY1F2ZE9XZnh0S1ZwTk00eGZK?=
 =?utf-8?B?SE5kU0ErNmZZMVYvNlpET0d3VXBIWmhVL3R4ZDRxWTQwWVFGWVkzU28vam94?=
 =?utf-8?B?bHNjdWhKcUFrMGZoZ1I0L2JEUCtBN0VpWjB3Ui9kMk95TGEzbitaTDNyMUdp?=
 =?utf-8?B?NWhac2tDbEkvbk1pSHpBTmdranQ4MHB3TEJ0Z2oySXM2eFRrc3k1NU1UU3VH?=
 =?utf-8?B?T1c1TzFPRlZMOTNXUU83VDZzOHNNT2ZmVmNSQ2FhUU50QTNNbG02UmE2N2lG?=
 =?utf-8?B?UUlvUlRkZlRkb3UzbWN5dExDbHNtcHlzS3VSeG9yMkVEVlNrb3NzdnlzV0dL?=
 =?utf-8?B?KzJXeXFqNE1nQVVkK0ZGaUJablBRZTFVcktKOVhvSmRsMlA2YWI3cWpDcVpq?=
 =?utf-8?B?S2l4Y2lWNHBDajlHaUxjZWV0c3cwL1V6ZW9hRXFsSUZqb1k4UXRsTW1oMkZ0?=
 =?utf-8?B?UTNGM1doSGVSZXNQVmorbkd2ZE5yZjFibEtyS2VDRDRiUDVNdnEyM3JTUm9M?=
 =?utf-8?B?NDFSTXl6UEtUY2xMUkdSL0dFallYK3hLdmNpWmd0N0NSSVhzVU5ValBZUWhR?=
 =?utf-8?B?SzEyOW0xd0JzejhjdG0vU2VrdlJubDY4cTBDWThMcU4wVTJyMVhrUVIvelJT?=
 =?utf-8?Q?Wkgdoo?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2025 13:38:57.5070
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 428e8d24-2eec-4907-3ca7-08dd922382fb
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B371.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPF1ADAD2878

On 2025-05-13 03:27, Jan Beulich wrote:
> On 13.05.2025 01:54, Jason Andryuk wrote:
>> Only access the HVM union b_info->u.hvm on HVM guests.  The union
>> access is not guarded, so this reads and sets the default even on
>> non-HVM guests.  Usually this doesn't matter as PV and PVH unions are
>> smaller and zero-initialized, but the zero default will be re-written as
>> a -1 boolean.  Generally, it it could incorrectly set b_info->altp2m
>> through aliased data.
>>
>> Fixes: 0291089f6ea8 ("xen: enable altp2m at create domain domctl")
>> Signed-off-by: Jason Andryuk 
>> Change-Id: Ifaca3533dcce3f409c2efa292c7e96fba6371d9d
>> ---
>>   tools/libs/light/libxl_x86.c | 10 ++++++----
>>   1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
>> index 0b1c2d3a96..b8f6663829 100644
>> --- a/tools/libs/light/libxl_x86.c
>> +++ b/tools/libs/light/libxl_x86.c
>> @@ -821,10 +821,12 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
>>        * If the legacy field info->u.hvm.altp2m is set, activate altp2m.
>>        * Otherwise set altp2m based on the field info->altp2m.
>>        */
>> -    libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
>> -    if (b_info->altp2m == LIBXL_ALTP2M_MODE_DISABLED &&
>> -        libxl_defbool_val(b_info->u.hvm.altp2m))
>> -        b_info->altp2m = libxl_defbool_val(b_info->u.hvm.altp2m);
>> +    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
>> +        libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
>> +        if (b_info->altp2m == LIBXL_ALTP2M_MODE_DISABLED &&
>> +            libxl_defbool_val(b_info->u.hvm.altp2m))
>> +            b_info->altp2m = libxl_defbool_val(b_info->u.hvm.altp2m);
>> +    }
> 
> I think at least the latter half of the comment wants to move inside the
> if() then.

Yes.  Actually, I think the whole comment should move inside the if().

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Tue May 13 13:41:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 13:41:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982851.1369199 (Exim 4.92)
	(envelope-from )
	id 1uEptG-0002yV-Fv; Tue, 13 May 2025 13:41:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982851.1369199; Tue, 13 May 2025 13:41: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 1uEptG-0002yO-CS; Tue, 13 May 2025 13:41:50 +0000
Received: by outflank-mailman (input) for mailman id 982851;
 Tue, 13 May 2025 13:41:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEptF-0002yG-RS
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 13:41:49 +0000
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com
 [2607:f8b0:4864:20::432])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 01fcc3b2-3000-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 15:41:44 +0200 (CEST)
Received: by mail-pf1-x432.google.com with SMTP id
 d2e1a72fcca58-7424ccbef4eso3005006b3a.2
 for ; Tue, 13 May 2025 06:41:44 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-74237a8efa2sm7741177b3a.165.2025.05.13.06.41.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 13 May 2025 06:41: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" 
X-Inumbo-ID: 01fcc3b2-3000-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747143703; x=1747748503; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=CjBhEUReEcpnOvmXghRfokYvtQrmimmin9Z5BxHCOeM=;
        b=dJE/qxP5ubbiJ7LEWxRl1Y7641rPhErWy/reZBx7SvxSPmgkBgFcRepB4FiFssquh9
         Uj+8Ui+WslXG8GUXRNnI6VD+8u29u2ow2B8dyXO6xVHZ8IwvG7TQhPDxucc3FXOOTzF7
         50t8TjieVU7Fl2iOcv4KHzqik8HQezfwoEk7g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747143703; x=1747748503;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CjBhEUReEcpnOvmXghRfokYvtQrmimmin9Z5BxHCOeM=;
        b=gailnw3stJhKDjUZVt5edzafJtylwHhVSaAZQtWpwGdCCC6sZON1Tb4XrnFKeG3TmD
         hdfHAlTaf/TGDQkySuuQR60lBQSlwJ9UZp9Uh3gP/k9RBPfUaWQ/ZAV1b9J3lYLrApCi
         CnQluJna57PaQgv4zXl4OQksvM7fpJvoKnmZPfurmOtihLdSzah4MrjdSGkmoeJWd5yn
         89aj5g+llEi6j5vkRXmON/a76FttGVPxCGEgJiHfygKOg80BeOpHA+4QsDdPp/RHlcPJ
         aFeST/0pSFjPG/2a1dA4bInHdmhQsNOEb7Z8pvtPfO8yOMnvwww8hti4sHAdSrD+bw5k
         EWZw==
X-Gm-Message-State: AOJu0Yw2QUuLfaM5uCgsGAPH0GMurX0kjuT35m9vAQ3IB/MleFdCxjb6
	LzUhcsRof5hj7JEIeDDPOoVqGKFVBUKobzpk4Nz2+EW/sBGz7gxNE7gYJeRG8ik=
X-Gm-Gg: ASbGncvZkAbiWYB+K1YrjW2Gi2LWSu6efWqGiievZK5iO8iGaftNBapOaHVNPN9pSdp
	NbVEONQ2npOga+g9tB4nvrUtyLzcN62U4pQSP/UVnHHBSSCxB1BwRlzYc1JK8V3g5HSuHvNpUHZ
	Iw4UxeCe40VVEoWTIOLPqFWgmfXzf9kAjK+gboq4jmNmRUQ0dY/XhZ8EIA4Ao07V/nZo1n6Ys36
	0cccpy1lNM5bfFfsesPIgaYAeKAKN8oB5aYl1ZCT3f9fm2YMkGzVZGXr386Jefu/YmeEUxveFaA
	Frcmch/IAvLzihN5wV8aPfNxH16b20eTStyHMn13ml7rX8XM4/JgJYvfa5ElhQ==
X-Google-Smtp-Source: AGHT+IHPsTEwJwTw0bg9EfuNWCe6ZpabY7d2+vlVP1CkkKj5uvLszkhAwWTBnVnfbz24xZwVjBJfCg==
X-Received: by 2002:a05:6a00:4b53:b0:740:9c06:1cff with SMTP id d2e1a72fcca58-7423c0163dfmr24716454b3a.23.1747143703267;
        Tue, 13 May 2025 06:41:43 -0700 (PDT)
Date: Tue, 13 May 2025 15:41:37 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu ,
	Kevin Tian ,
	Jun Nakajima 
Subject: Re: [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache
 writeback
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Wed, May 03, 2023 at 11:45:22AM +0200, Jan Beulich wrote:
> We allow its use for writeback purposes only anyway, so let's also carry
> these out that way on capable hardware.

"for writeback purposes only" > is such the case because we cannot
guarantee the guest in which state the cache will be when resuming
from a wbinvd operation, and hence won't be "clean"?

It's my understanding that the same is possible on native, as the CPU
might speculatively pull lines into the cache.  So there's no reason
for an OS to use wbinvd if wbnoinvd is available?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 13 13:42:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 13:42:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982857.1369208 (Exim 4.92)
	(envelope-from )
	id 1uEptp-0003Qs-NN; Tue, 13 May 2025 13:42:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982857.1369208; Tue, 13 May 2025 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 1uEptp-0003Ql-Kn; Tue, 13 May 2025 13:42:25 +0000
Received: by outflank-mailman (input) for mailman id 982857;
 Tue, 13 May 2025 13:42:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEpto-0003Pl-LQ
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 13:42:24 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 19a92d64-3000-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 15:42:23 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5fbfdf7d353so7500607a12.0
 for ; Tue, 13 May 2025 06:42: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
 a640c23a62f3a-ad24085b44fsm527217966b.149.2025.05.13.06.42.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 06:42: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" 
X-Inumbo-ID: 19a92d64-3000-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747143743; x=1747748543; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=aciBqxnTTvo/SB1YxAjPCv3iLRqLC874q9dEnKOOInM=;
        b=TEngX1MHJQvcCl3Bv8OGMWI4lrPrlo/oaQAxT7jS4+wZci2rkWZNjI1I20ot9U+lQq
         uJ8wen5Y+NVD0efTY31irhKUEeIsNrIn9XYEh2yqseXLgr713AnByfdX3FAJaQ8LvxoK
         piFt4pRQg/kFUWLZef2g9CmRPVu8rAjh7LMJO4QslOHi54Al7V3p4potvFz5lMt8Eyj1
         1zPsS11piD2pC1Ai1RwxLYpWD8f1PZb9eaViM5ndfdmkJLlMQpfh5n0d0Jz7aXLP+I2a
         ey51yOM8NCY/j/I5uC8J9Jj7QeVnWe/BlmwgkhO3GMcyAS9C3CEc29rT97vJ6kMjqQTf
         gWBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747143743; x=1747748543;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aciBqxnTTvo/SB1YxAjPCv3iLRqLC874q9dEnKOOInM=;
        b=Dk3RGvUxS0qYYBhqrB2X4P1/NVSu0PwD8jij3nhk0tZFIYn0JwWUhuJQYLN+bedGGp
         +Hq+QX6Asking0VlVfGn/1VbmN4ULFw8ad8ANeVkbEzhn3EKwZtogtOUVpStrHw5qvED
         jYbzorTCDGQ7Evmj6numZkpgGKkcPqusrSlGbUS/BzKZKSogvP0l5C3w20Fkx2tnyQjr
         7lRCzVvmji4eC/+SW8PvrMZQ4/F/biBlzoo8Y7pWIl31KN2o8ChzbRQtfbzmI+GYpfB5
         M2jl+JPFvFUFTaVNDJhAMGnPc0beObW2A8oCuOkCjKtFuq2zG/J4c1Di5XLaJC/mmpdY
         tk7Q==
X-Forwarded-Encrypted: i=1; AJvYcCVmLYdVHtrwrHNmIX8e02EE47KLmUCoGNR3lrQUTq8dVjznv9vTJny/akLn8J3poKxsdkWpwn2sFeQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx/OCJB3AOqtLsNqDYXa2fFLfsGEt92f2uQRLJP3wcD3v2RKyLm
	PuQ3AfhAeKVjvMz3a1+hM1V5AYcMbUY5QtXNFLWW9os6FyvGpvBuRK0A6cD0Pg==
X-Gm-Gg: ASbGnctMzJPqPNNNHUCeaJ4HWNdDw6NZ69Gywzdo94y6sh0sheFmRNljVKGBZEhaheF
	88szYvuzzPAEte7GRB4NsuKfXyabZXIK3V8xNxqKBFAfBDsT8oTULMICFIp3D9z9+2hogCal0Wm
	/PzO/yeBZ0VhgomnEBMx1UxvPd4H5c2FC1/9tIk6wWtXmFgfUJZWxirP5CVGZBICOjP+YpAFRoF
	S+GIUPOWDFOctDLAIYt47DzAR4W1P8j09/O9xx3uuEQsGefoh9KVYHVCtFYMiY8PbJBuBI77LP/
	nOe+aqjgPQZ9amx+yCZHvBvq/2VKvBX8OYuejMu0V97y8CJjI/pz66how/SqsKvsPQKF97c9XtF
	sRF5aqHFy7skCvzcYprYrBj/wnZYD4LTewbLZ
X-Google-Smtp-Source: AGHT+IEYkZBlK8bz7t3DUVkQWcoRsd5JnCEV/Ck02NLHAPBnNAPb0Z8rb+4VGb5n26Y+moBfPczEJg==
X-Received: by 2002:a17:907:944f:b0:ad2:42f3:86e0 with SMTP id a640c23a62f3a-ad242f389f9mr1093437566b.27.1747143743224;
        Tue, 13 May 2025 06:42:23 -0700 (PDT)
Message-ID: <39eb1f57-fb2f-4c55-ac79-a6e81a1c5b40@suse.com>
Date: Tue, 13 May 2025 15:42:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/spec-ctrl: Support Intel's new PB-OPT
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250513124814.3500710-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: <20250513124814.3500710-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.05.2025 14:48, Andrew Cooper wrote:
> In IPU 2025.2 (May 2025), Intel have released an alternative mitigation for a
> prior security issue (SA-00982) on Sappire and Emerald Rapids CPUs.
> 
> Intel suggest that certain workloads will benefit from using the alternative
> mode.  This can be selected by booting with `spec-ctrl=ibpb-alt`.
> 
> https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/cpuid-enumeration-and-architectural-msrs.html
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with two nits: For one, s/Sappire/Sapphire/ throughout. And  then ...

> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -85,6 +85,8 @@ static int8_t __initdata opt_gds_mit = -1;
>  static int8_t __initdata opt_div_scrub = -1;
>  bool __ro_after_init opt_bp_spec_reduce = true;
>  
> +static __initdata bool opt_ibpb_alt;

... type and attribute would preferably be swapped here, just like it's
in context above as well as for the statics you add to cpu/intel.c.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 13:46:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 13:46:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982868.1369218 (Exim 4.92)
	(envelope-from )
	id 1uEpxr-00043n-6R; Tue, 13 May 2025 13:46:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982868.1369218; Tue, 13 May 2025 13: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 1uEpxr-00043g-3V; Tue, 13 May 2025 13:46:35 +0000
Received: by outflank-mailman (input) for mailman id 982868;
 Tue, 13 May 2025 13:46:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEpxp-00043a-GX
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 13:46:33 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de
 [2a07:de40:b251:101:10:150:64:1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id adbc939a-3000-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 15:46:32 +0200 (CEST)
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 D3FCD211F5;
 Tue, 13 May 2025 13:46:31 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 79AF31365D;
 Tue, 13 May 2025 13:46:31 +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 UqQkHDdNI2gqYgAAD6G6ig
 (envelope-from ); Tue, 13 May 2025 13:46: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" 
X-Inumbo-ID: adbc939a-3000-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1747143991; 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=tR76EuqUQ9RmOFfMWzr/dqiKVhXSESONtLn/NfETjuY=;
	b=TiRckzaehSsnYenzrJGrLLxRUi6eACFOKXoHAtz2yKikILtwP3oN7ppJilc3nPLpfotjba
	SFff2n992tIXo5vUo6wqBON6zJoWgFoe3TISDY+RZmUdZ8EwMw/GO0lva+BXOcHr2e96XV
	ewfMObmYsZATL9Gr1uIpXrEk3ps7I/o=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1747143991; 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=tR76EuqUQ9RmOFfMWzr/dqiKVhXSESONtLn/NfETjuY=;
	b=TiRckzaehSsnYenzrJGrLLxRUi6eACFOKXoHAtz2yKikILtwP3oN7ppJilc3nPLpfotjba
	SFff2n992tIXo5vUo6wqBON6zJoWgFoe3TISDY+RZmUdZ8EwMw/GO0lva+BXOcHr2e96XV
	ewfMObmYsZATL9Gr1uIpXrEk3ps7I/o=
Message-ID: <186e7924-c033-4af7-b125-9c3e9fa35b4b@suse.com>
Date: Tue, 13 May 2025 15:46:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/4] remove qemu-traditional
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Oleksii Kurochko ,
 Community Manager ,
 Samuel Thibault 
References: <20250429110636.30518-1-jgross@suse.com>
Content-Language: en-US
From: Juergen Gross 
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20250429110636.30518-1-jgross@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------nycpEwHGVIJwTi0blFid2ngj"
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-3.70 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	SUSPICIOUS_RECIPS(1.50)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	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];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[12];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[vates.tech,citrix.com,amd.com,suse.com,xen.org,kernel.org,invisiblethingslab.com,gmail.com,xenproject.org,ens-lyon.org];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo]
X-Spam-Score: -3.70

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------nycpEwHGVIJwTi0blFid2ngj
Content-Type: multipart/mixed; boundary="------------onNVJEpexbSHN7lqxE5rZJau";
 protected-headers="v1"
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Oleksii Kurochko ,
 Community Manager ,
 Samuel Thibault 
Message-ID: <186e7924-c033-4af7-b125-9c3e9fa35b4b@suse.com>
Subject: Re: [PATCH v3 0/4] remove qemu-traditional
References: <20250429110636.30518-1-jgross@suse.com>
In-Reply-To: <20250429110636.30518-1-jgross@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=

--------------onNVJEpexbSHN7lqxE5rZJau
Content-Type: multipart/mixed; boundary="------------NEpkplsOiJP0kHAPgjOAhjQc"

--------------NEpkplsOiJP0kHAPgjOAhjQc
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

UGluZz8NCg0KT24gMjkuMDQuMjUgMTM6MDYsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+IFJl
bW92ZSB0aGUgcWVtdS10cmFkaXRpb25hbCBzdXBwb3J0LiBUaGlzIGluY2x1ZGVzIHRoZSBN
aW5pLU9TDQo+IGJhc2VkIGlvZW11LXN0dWJkb20uDQo+IA0KPiBEb24ndCByZW1vdmUgUk9N
QklPUyBmb3Igbm93LCBhcyBpdCBjYW4gYmUgdXNlZCB3aXRoIHFlbXUgKFhlblNlcnZlcg0K
PiBpcyBkb2luZyB0aGF0KS4NCj4gDQo+IEFmdGVyIGFkZGluZyB0aGUgc2VyaWVzIGEgcnVu
IG9mIGF1dG9jb25mIHNob3VsZCBiZSBkb25lLg0KPiANCj4gQ2hhbmdlcyBpbiBWMjoNCj4g
LSBhZGRyZXNzZWQgY29tbWVudHMNCj4gDQo+IENoYW5nZXMgaW4gVjM6DQo+IC0gcGF0Y2hl
cyAxIGFuZCA1IG9mIFYyIGhhdmUgYmVlbiBhcHBsaWVkIGFscmVhZHkNCj4gLSBhZGRyZXNz
ZWQgY29tbWVudHMNCj4gDQo+IEp1ZXJnZW4gR3Jvc3MgKDQpOg0KPiAgICBkb2NzOiByZW1v
dmUgcWVtdS10cmFkaXRpb25hbCBzdXBwb3J0IGZyb20gZG9jdW1lbnRhdGlvbg0KPiAgICB0
b29sczogcmVtb3ZlIHN1cHBvcnQgZm9yIHJ1bm5pbmcgYSBndWVzdCB3aXRoIHFlbXUtdHJh
ZGl0aW9uYWwNCj4gICAgdG9vbHM6IHJlbW92ZSBxZW11LXRyYWRpdGlvbmFsDQo+ICAgIGJ1
aWxkOiBkb24ndCByZXF1aXJlIGZ1bGwgdG9vbHMgYnVpbGQgZm9yIGJ1aWxkaW5nIHN0dWJk
b21zDQo+IA0KPiAgIC5naXRpZ25vcmUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB8ICAgMyAtDQo+ICAgQ0hBTkdFTE9HLm1kICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwgICAxICsNCj4gICBDb25maWcubWsgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgfCAgMzggLS0NCj4gICBJTlNUQUxMICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfCAgMTMgLQ0KPiAgIE1BSU5UQUlORVJTICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgNCAtDQo+ICAgTWFrZWZpbGUgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAyICstDQo+ICAgUkVBRE1FICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAyICstDQo+ICAgU1VQ
UE9SVC5tZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDE2IC0NCj4g
ICBjb25maWcvUGF0aHMubWsuaW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDMg
Ky0NCj4gICBjb25maWcvVG9vbHMubWsuaW4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
fCAgIDEgLQ0KPiAgIGRvY3MvbWFuL3hsLXBjaS1jb25maWd1cmF0aW9uLjUucG9kICAgICAg
ICAgICB8ICAgNCArLQ0KPiAgIGRvY3MvbWFuL3hsLmNmZy41LnBvZC5pbiAgICAgICAgICAg
ICAgICAgICAgICB8ICA0OSArLS0NCj4gICBkb2NzL21pc2Mvc3R1YmRvbS50eHQgICAgICAg
ICAgICAgICAgICAgICAgICAgfCAgNTIgLS0tDQo+ICAgZG9jcy9taXNjL3hlbnN0b3JlLXBh
dGhzLnBhbmRvYyAgICAgICAgICAgICAgIHwgICAzICstDQo+ICAgZG9jcy9wcm9jZXNzL2Jy
YW5jaGluZy1jaGVja2xpc3QudHh0ICAgICAgICAgIHwgICA0IC0NCj4gICBkb2NzL3Byb2Nl
c3MvcmVsZWFzZS10ZWNobmljaWFuLWNoZWNrbGlzdC50eHQgfCAgIDMgLQ0KPiAgIGRvY3Mv
cHJvY2Vzcy94ZW4tcmVsZWFzZS1tYW5hZ2VtZW50LnBhbmRvYyAgICB8ICAgMiArLQ0KPiAg
IHN0dWJkb20vLmdpdGlnbm9yZSAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMyAt
DQo+ICAgc3R1YmRvbS9NYWtlZmlsZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
IDk3ICstLS0tLQ0KPiAgIHN0dWJkb20vY29uZmlndXJlICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8ICA4OSAtLS0tLQ0KPiAgIHN0dWJkb20vY29uZmlndXJlLmFjICAgICAgICAg
ICAgICAgICAgICAgICAgICB8ICAxNSAtDQo+ICAgc3R1YmRvbS9pb2VtdS1taW5pb3MuY2Zn
ICAgICAgICAgICAgICAgICAgICAgIHwgICA2IC0NCj4gICB0b29scy9NYWtlZmlsZSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgNTggLS0tLQ0KPiAgIHRvb2xzL1J1bGVz
Lm1rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMyAtDQo+ICAgdG9vbHMv
Y29uZmlnLmguaW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAzIC0NCj4gICB0
b29scy9jb25maWd1cmUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgNDIgKy0t
DQo+ICAgdG9vbHMvY29uZmlndXJlLmFjICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
IDIxICstDQo+ICAgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL01ha2VmaWxlICAgICAgICAg
ICAgIHwgICAzICstDQo+ICAgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3BjaS5jICAgICAg
ICAgICAgICAgIHwgIDE3ICstDQo+ICAgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL3V0aWwu
YyAgICAgICAgICAgICAgIHwgICA5ICstDQo+ICAgdG9vbHMvbGliYWNwaS9ta19kc2R0LmMg
ICAgICAgICAgICAgICAgICAgICAgIHwgMTgzICsrKy0tLS0tLS0NCj4gICB0b29scy9saWJz
L2xpZ2h0L2xpYnhsX2NyZWF0ZS5jICAgICAgICAgICAgICAgfCAgNzggKy0tLS0NCj4gICB0
b29scy9saWJzL2xpZ2h0L2xpYnhsX2RldmljZS5jICAgICAgICAgICAgICAgfCAgMTkgLQ0K
PiAgIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxfZGlzay5jICAgICAgICAgICAgICAgICB8ICAg
NyAtDQo+ICAgdG9vbHMvbGlicy9saWdodC9saWJ4bF9kbS5jICAgICAgICAgICAgICAgICAg
IHwgMzI3ICstLS0tLS0tLS0tLS0tLS0tLQ0KPiAgIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxf
ZG9tLmMgICAgICAgICAgICAgICAgICB8ICAxMCAtDQo+ICAgdG9vbHMvbGlicy9saWdodC9s
aWJ4bF9kb21fc2F2ZS5jICAgICAgICAgICAgIHwgMTQwIC0tLS0tLS0tDQo+ICAgdG9vbHMv
bGlicy9saWdodC9saWJ4bF9kb21fc3VzcGVuZC5jICAgICAgICAgIHwgIDY1IC0tLS0NCj4g
ICB0b29scy9saWJzL2xpZ2h0L2xpYnhsX2RvbWFpbi5jICAgICAgICAgICAgICAgfCAgMTUg
LQ0KPiAgIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxfZXhlYy5jICAgICAgICAgICAgICAgICB8
ICA3NSAtLS0tDQo+ICAgdG9vbHMvbGlicy9saWdodC9saWJ4bF9pbnRlcm5hbC5jICAgICAg
ICAgICAgIHwgICA2ICstDQo+ICAgdG9vbHMvbGlicy9saWdodC9saWJ4bF9pbnRlcm5hbC5o
ICAgICAgICAgICAgIHwgIDY4ICstLS0NCj4gICB0b29scy9saWJzL2xpZ2h0L2xpYnhsX3Bj
aS5jICAgICAgICAgICAgICAgICAgfCAxODMgLS0tLS0tLS0tLQ0KPiAgIHRvb2xzL2xpYnMv
bGlnaHQvbGlieGxfc3Jfc3RyZWFtX2Zvcm1hdC5oICAgICB8ICAgMiArLQ0KPiAgIHRvb2xz
L2xpYnMvbGlnaHQvbGlieGxfc3RyZWFtX3dyaXRlLmMgICAgICAgICB8ICAgNCAtDQo+ICAg
dG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwgICAgICAgICAgICAgIHwgICAyICst
DQo+ICAgdG9vbHMvcHl0aG9uL3hlbi9taWdyYXRpb24vbGlieGwucHkgICAgICAgICAgIHwg
ICAyIC0NCj4gICB0b29scy94bC94bF9wYXJzZS5jICAgICAgICAgICAgICAgICAgICAgICAg
ICAgfCAgIDUgKy0NCj4gICA0OCBmaWxlcyBjaGFuZ2VkLCAxMDMgaW5zZXJ0aW9ucygrKSwg
MTY1NCBkZWxldGlvbnMoLSkNCj4gICBkZWxldGUgbW9kZSAxMDA2NDQgc3R1YmRvbS9pb2Vt
dS1taW5pb3MuY2ZnDQo+IA0KDQo=
--------------NEpkplsOiJP0kHAPgjOAhjQc
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-----

--------------NEpkplsOiJP0kHAPgjOAhjQc--

--------------onNVJEpexbSHN7lqxE5rZJau--

--------------nycpEwHGVIJwTi0blFid2ngj
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/Ey8FAmgjTTcFAwAAAAAACgkQsN6d1ii/Ey9C
GAgAlFZb83p9/PANRvLNTlJtk3OpVc81ql945JcygUvBha69gJgsg5a7CAQTqwR6SpR5LwSPL3hd
tFEJ+hMsDah098XjiG00/RwvuQV/8JDHLvIOTPOaR0w0p1UPLd38fOQH+o0FbZXB0h0f+OmOAK+O
mFroM3zyTESoduhv4+/Bv5Wm7IR25AsWJveZ7dMhakTcz6lyckM4vgrbPCj/1jK8InyLO5ffTLq8
1J8HuV71Ai5RT50I05DGT/rfB84eRqA+G3x5+1XTn/RJVGHg2XdahFTv8jrSUZUoTbOya2LGdgB5
xxP/CQTh7SMfJSza6RQEmupWj7po06ChfPwXFJ4cfQ==
=mVjD
-----END PGP SIGNATURE-----

--------------nycpEwHGVIJwTi0blFid2ngj--


From xen-devel-bounces@lists.xenproject.org Tue May 13 13:46:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 13:46:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982870.1369229 (Exim 4.92)
	(envelope-from )
	id 1uEpy8-0004Qg-Hx; Tue, 13 May 2025 13:46:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982870.1369229; Tue, 13 May 2025 13:46: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 1uEpy8-0004QZ-ET; Tue, 13 May 2025 13:46:52 +0000
Received: by outflank-mailman (input) for mailman id 982870;
 Tue, 13 May 2025 13:46:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEpy7-0004L0-5s
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 13:46:51 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b81819f0-3000-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 15:46:49 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5fbf007ea38so9327485a12.3
 for ; Tue, 13 May 2025 06:46:49 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad21933f4e6sm787374266b.54.2025.05.13.06.46.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 06:46: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" 
X-Inumbo-ID: b81819f0-3000-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747144009; x=1747748809; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AS3DnpownWeR82CqRsAbYVA6LFIoGSSjqX5AJvW/hmI=;
        b=KYdeFhfW/7NEMpsxu/3Bb1KIu2fq1yuLoqIEJmjx4ChHsqCiO+AWtftba4/cKzUE9n
         S+xnmP2lz+qTIx8h8fcfPKpaNs5njX1+lIRUlKd3w+A8zB6RRM1wbSdb7Ofr2P/iESKy
         DDB9L4C5L412h9V+l87iqIMjRynuENWdngDz0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747144009; x=1747748809;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AS3DnpownWeR82CqRsAbYVA6LFIoGSSjqX5AJvW/hmI=;
        b=CuiD2ia5ENcTdX7Konu7cJ1AmIg90e0U8L6qxcpQKA3pS/J84Xb0PZ5bkxjPS62uCN
         CTYReu7jFGoEOM6KKvo/4OVuDUbyxdsZmIUN4Mfd2MgePyJbfLQKYH3MaEt6tlVMGJ3J
         cLs4qsHtrdoG6ah+8t9SFgxCmZD41k35cvvRKKu/OFKsiHsOjX2gsWG9Sxnq7vghTyh3
         P3uc6E8UyWOzXs22X5g5T5MephIpbUKehfOspifdALJ1bowMw2JjHU6s4EJyWz2yGUzo
         ochv5BsirwHXKjR49t0XF2J8d9ubsbwCJPpyrfKMRf5/x6DIm3WI7QiJ7yU+Z4UNB33P
         s8YQ==
X-Forwarded-Encrypted: i=1; AJvYcCXyY6QIyVUw54VO51ytNQmiWiFUcSgLNPheZ9OFzfM10z42QxwzShlYHcbdBtjnzDaGJnTepCCzYqY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyMukSwgIuwgGtWwbCZ2S1541fE9PCmLb7D5k6Jvwguh70ouL6G
	PjDo+ndkznFM1f3fgRcHrdf/lXsaN7Ot+WQUFbmxEH7gkYS+hBcudtDNuBX3AKw=
X-Gm-Gg: ASbGncv22D6a09p7SYUwdKGzBGBY48rbsjhlmpCaFAOBpAmd5M29nDo/1uBRrB4F5r7
	/I8YXaQuKlWgu8Ng1RSB6HvVKhM+1MHqGIt/xgJfy/j3ADkzTPC4tBRzrDm/0Vcl6uq/velSsje
	zRxASDEphabukKnkuSGQITjhqgEVytIP43LLY0em50vvpFBQZH/RqkK+R2nMnEq4UjIUCZclo/V
	d4LLjRpGPiZr4FmBbEqq5Aml6wfOZTX3OPxp5uKpGP9cpNIsJFMqlursY3Xo3dUQWaYWiSavq9W
	t0cJRO+R5OzUXSXbD2Ig39ZAbOi3sx58tBnGbciS48T3wXtFD3tYZbpEeEqKjfZLY70chqkJxMo
	ro/fEALW5HcsqTApn
X-Google-Smtp-Source: AGHT+IHdp+jEzdSRUP9XljIwWFKtEjWShJ2MqPEq+EFHYL7IgiY9WDoOGF0iZIF5MFDudQ1fsuYn+w==
X-Received: by 2002:a17:907:c50e:b0:ad2:23a8:c71e with SMTP id a640c23a62f3a-ad223a8ceb2mr1380964666b.27.1747144009005;
        Tue, 13 May 2025 06:46:49 -0700 (PDT)
Message-ID: <8b34653d-d83e-41f0-b4e7-58f7d5ca2b1f@citrix.com>
Date: Tue, 13 May 2025 14:46:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/spec-ctrl: Support Intel's new PB-OPT
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250513124814.3500710-1-andrew.cooper3@citrix.com>
 <39eb1f57-fb2f-4c55-ac79-a6e81a1c5b40@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: <39eb1f57-fb2f-4c55-ac79-a6e81a1c5b40@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13/05/2025 2:42 pm, Jan Beulich wrote:
> On 13.05.2025 14:48, Andrew Cooper wrote:
>> In IPU 2025.2 (May 2025), Intel have released an alternative mitigation for a
>> prior security issue (SA-00982) on Sappire and Emerald Rapids CPUs.
>>
>> Intel suggest that certain workloads will benefit from using the alternative
>> mode.  This can be selected by booting with `spec-ctrl=ibpb-alt`.
>>
>> https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/cpuid-enumeration-and-architectural-msrs.html
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 

Thanks.

> with two nits: For one, s/Sappire/Sapphire/ throughout. And  then ...
>
>> --- a/xen/arch/x86/spec_ctrl.c
>> +++ b/xen/arch/x86/spec_ctrl.c
>> @@ -85,6 +85,8 @@ static int8_t __initdata opt_gds_mit = -1;
>>  static int8_t __initdata opt_div_scrub = -1;
>>  bool __ro_after_init opt_bp_spec_reduce = true;
>>  
>> +static __initdata bool opt_ibpb_alt;
> ... type and attribute would preferably be swapped here, just like it's
> in context above as well as for the statics you add to cpu/intel.c.

Oops, both fixed.  (The public probably aren't aware, but this patch got
lost in a bit of a mad rush of the late breaking changes to XSA-469
yesterday.)

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 13 13:55:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 13:55:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982889.1369240 (Exim 4.92)
	(envelope-from )
	id 1uEq61-0006Tj-Br; Tue, 13 May 2025 13:55:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982889.1369240; Tue, 13 May 2025 13:55: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 1uEq61-0006Tc-6j; Tue, 13 May 2025 13:55:01 +0000
Received: by outflank-mailman (input) for mailman id 982889;
 Tue, 13 May 2025 13:55:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEq60-0006TW-2i
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 13:55:00 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id db4151b9-3001-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 15:54:58 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad241baf856so556828466b.0
 for ; Tue, 13 May 2025 06:54: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
 a640c23a62f3a-ad236cb21a2sm602973566b.159.2025.05.13.06.54.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 06:54: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" 
X-Inumbo-ID: db4151b9-3001-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747144497; x=1747749297; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=oyxsQtOlJqzbvOYH9xERmP88RL3iOliw5gVY/G40uZQ=;
        b=T9dzBX4TnOKQz7l2uBqpMhE5vyOTbX9srcPzlV5EyXbH80jQb0VaSc00b5CHSauL+P
         s45v4+BbUHWTM1a+T0nMIq4ric/yySg9Oasxt6IpQ+NA+Rh8Ng65aGZsqXmmSw16z821
         tUsc5W33d3R2ivpCdQwsOBozaIFpviP791fLXT7juEJ8o7HtcazQLcqm0EROFzAA0g4c
         zVtYFK6JJli6Co0yl3N1kw/YellIkNLiOKwjVlSXvMoXgHX1Z9hMhVyQXgtqSLvTAsj5
         0S8NLfHUA2vqjy7oO5QgDVZuIm4gW7fvwjj5PV+Hxkgzf0EH7yNgrhOvHTqqN7e8tlr2
         VELw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747144497; x=1747749297;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oyxsQtOlJqzbvOYH9xERmP88RL3iOliw5gVY/G40uZQ=;
        b=cq9jUTpxWT8KafSU9Y1xbQykGujRcEKU9S6jjXA2JQTvHZ9HLIKRDJ56RGrFGSD7m5
         yLMNSVATzm0MGegXXkT5+o4XlkBKVbt32YNhLUcQifkE/5kLv69uMr5XjDJ0/oUjmyk8
         5k0eVFdghtxYpLt1Az+my56DIyd1ab5sa49U4xkR3DIW9HHMj+TWPXPe0nLpBUSJoFfk
         n2CtGLplLfxJAGVPv5u4b5riFxlFcFa31IBthnzKXt8x2RHvQBdAoSBvi+Hv45rCsXQ8
         Q9GVuXO+3Kto/7ppA/iYSICg9lwwmE7P+oTxg8SFmMXziqh7E9pMGzSnpb2PiwJxLFO9
         9U+w==
X-Gm-Message-State: AOJu0Yzy9zAWQU8Sn2m922nJpzbht3VsbiqIM/ObyTgXZcVkAEo9WFh/
	hdtwTYUMny+mgMtjNMpwCv3Q7aNyx1h8LmXLWXCZkQKdjCGyYm7bVhXefAUBbK29tRjpF1hQ/4s
	=
X-Gm-Gg: ASbGncsUx1Ia5c+wGak3nHd7O1Tu5Soi6DM39DJmov+tYGes015twIgAj6O2TiTFFS1
	RCNUU50iwvfvJLS8HarhS4wkTLWCGvMlYqmOPbqYR2mnw6ppxN5RDFD11e9Fp4qr+LzEympVvrT
	WoWTzuJStw/8zOQz7hak5RgfDWAZGDxb+dZkQ2PJTCR2B3ZoqOsZb66YayVeg7pmOBETYD7GmLm
	x8bsbRhJ4eWg05gMoYREw/zLddQgtMhuz61315gyxDhnCvhHe9QBLFOp0tDpMDkMrwJEnH+w9GP
	F+Vsz91TplqaTs+3QI1vpTd/bBdrSFAHUbmGSPqAQwdcCJPzq7F+5kOqGo4VigOof5SnUxeSlO7
	JEExZEwZ9c6NLt3BqW2QlI8TE/jPQlgeMhA19
X-Google-Smtp-Source: AGHT+IFpPEqfWY1daqN5ckJL0Xw3NFizx0fyh7PZ1P7CmrKG4vIrvBfpDg8e49ErG1/Q0pVy+uZV6g==
X-Received: by 2002:a17:906:6a22:b0:ad2:16ce:7c38 with SMTP id a640c23a62f3a-ad4d4e326camr351413166b.16.1747144497551;
        Tue, 13 May 2025 06:54:57 -0700 (PDT)
Message-ID: <80ab4cdf-dbbb-4daa-831e-c6d92f5dcf13@suse.com>
Date: Tue, 13 May 2025 15:54:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache
 writeback
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Wei Liu ,
 Kevin Tian , Jun Nakajima 
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

On 13.05.2025 15:41, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 11:45:22AM +0200, Jan Beulich wrote:
>> We allow its use for writeback purposes only anyway, so let's also carry
>> these out that way on capable hardware.
> 
> "for writeback purposes only" > is such the case because we cannot
> guarantee the guest in which state the cache will be when resuming
> from a wbinvd operation, and hence won't be "clean"?

Not really, no (see below). This is inferred from us limiting flushing
operations to domains with physical hardware assigned plus the fact
that we avoid the overhead in vmx_do_resume() when the IOMMU is snoop-
capable. (Plus I did all this work over 2 years ago, and hence I now
don't recall what other commentary I may have come across saying
things along these lines.)

Which, thinking about it while writing this reply (and also taking
into consideration Andrew's earlier reply), may be all wrong.

> It's my understanding that the same is possible on native, as the CPU
> might speculatively pull lines into the cache.  So there's no reason
> for an OS to use wbinvd if wbnoinvd is available?

Speculatively pulling data into the cache is possible only when page
table entries permit caching. Hence after changing all mappings of a
certain page to UC, an OS may have a need to ensure that no data of
this page is left in any cache (and it can't be pulled back in
speculatively then).

IOW if the goal of the OS is write-back, then indeed it should prefer
WBNOINVD if available. Yet the same "replacement" isn't possible when
the goal is pruning of the cache(s).

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 14:27:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:27:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982913.1369272 (Exim 4.92)
	(envelope-from )
	id 1uEqb9-0002qP-Sh; Tue, 13 May 2025 14:27:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982913.1369272; Tue, 13 May 2025 14:27:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEqb9-0002qI-Q9; Tue, 13 May 2025 14:27:11 +0000
Received: by outflank-mailman (input) for mailman id 982913;
 Tue, 13 May 2025 14:27:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEqb8-0002qC-Sh
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:27:10 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5a840b0e-3006-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 16:27:09 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ad243cdbe98so505756766b.0
 for ; Tue, 13 May 2025 07:27: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
 a640c23a62f3a-ad2198b68dasm781774466b.181.2025.05.13.07.27.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 07:27: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" 
X-Inumbo-ID: 5a840b0e-3006-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747146429; x=1747751229; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Pab7t/HmM//a4/BkuGC4VNRQRXAmMookN/PuxnC12B8=;
        b=VZSJlu9whlde0Qu1iy2yoZervREQj+jm08ShZUsbSgbEnOOeVlT3VH6ZagSjSMc6HY
         v+25o+megeAMrU4U9Oww5qxbZP+c0tE/0zkAa1hh6THuB3pJgvoH5XRWD3HgqnW6j0wE
         22mNh+wmvHTFU/MTUzkwQVGxk5QUh1U+kHpx5zIX6Nt7w45PkaDlzsN6G7vTmo/rw+Tn
         O7/scN9Fr2lq0dl7C1ncREC54ub8pPK5VxnuQt4oOaj8ZtTp0AXCkD7SCf8cHoPEBRxo
         a6MeNja0gAX5GDFWftJd2BN0fGhgeG5niy/2vNIPdCW64qCyMNAEIreDOIoiV1BMsGsQ
         L5iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747146429; x=1747751229;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Pab7t/HmM//a4/BkuGC4VNRQRXAmMookN/PuxnC12B8=;
        b=dDXmCc8WBE9NlTIX3Ld1qLApHtZnPhxw7N3H70dVP+yP2wQwTyQDdBH5eXMdmqmzeS
         plQn3jAnh3P3YCdTTUmdpvoH/hYfhgtw64TEBrnDQdYXsRvogJqNty3gUzuIgLJwXUQf
         5ynFkRUphtCVYRj+Kgssp1GEnfCs2/TDN/EhRNHWerJ2JR+Be6oQke3y4FH3JO2mp84x
         KcLM3apw9xqcSRlQQY/xV5r64N9nwg5e6MNCCqHT1sJ/S+xBkTa8JTivzAKTSACKspNt
         scqdcspZt8QQ+ueUs1GW0E3SAKe0pva7xJDA0fOCrYy+No0OzaR9fzMIQNzbVkZqiCtp
         M0cA==
X-Gm-Message-State: AOJu0Yz8OfUEa4wO5JcbWMrocdKWyZLXksciIQJH5oUIoxjWDaxyRspn
	4CgJB/WekRVUnBOkvPZhlZ99U5Dc8b1KEElaewvG3hnhHwKhG1bXCrNYG3A8Vg==
X-Gm-Gg: ASbGnctL0HfstmRksCPl6p+87hh2UkMsDVIBs6rzYOf1y6nE2dDYJVvjaIN42CmbHsa
	gJa3SVk3g61Phg9f8VS08G/GDMSfZyr1agC/NlxRuCuGhuSf5vk9h/edi7TBt40PYD3mct3cDKD
	PVMpwsb8ZKn4lIBILE4KFX/IM/I33c8g5nZ03Bu+er0UenE5/vV2a1RllfOyIhiPUhtQD2QSNmV
	/XHO7+UUsyCnCMuuibv4EEJ64RqjufFYosyDZXhv4YBgfz+yKzdSlQ23zFU7JZSL9k9s6VNmh9q
	yRooe7mZj29wb4kdcZ6xAjxlv24HRgprThHq7RAl123QuizbgAoos2QUGPYEZSI3Y+wYRuLSFKz
	oegPiQxpiBrqcJhLXRZGbqXiGa1vqoxiHdy716zfSAxCza5I=
X-Google-Smtp-Source: AGHT+IFGUJjgx/c/psHLy8KVsszJIb81qRGrH7azlLMXp7YDmwhkMpZ5m8C3HSDtTXB39dggmTBCZg==
X-Received: by 2002:a17:907:c717:b0:ace:c505:3349 with SMTP id a640c23a62f3a-ad218e3f64fmr1749854466b.12.1747146429086;
        Tue, 13 May 2025 07:27:09 -0700 (PDT)
Message-ID: <204e177c-beba-41a1-93bf-3ae6454875cc@suse.com>
Date: Tue, 13 May 2025 16:27:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/5] x86/pmstat: Check size of PMSTAT_get_pxstat
 buffers
To: Ross Lagerwall 
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
 <20250512144656.314925-2-ross.lagerwall@citrix.com>
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250512144656.314925-2-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.05.2025 16:46, Ross Lagerwall wrote:
> Check that the total number of states passed in and hence the size of
> buffers is sufficient to avoid writing more than the caller has
> allocated.
> 
> The interface is not explicit about whether getpx.total is expected to
> be set by the caller in this case but since it is always set in
> libxenctrl it seems reasonable to check it.

Yet if we start checking the value, I think the public header should also
be made say so (in a comment).

> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> @@ -103,8 +103,10 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
>  
>          cpufreq_residency_update(op->cpuid, pxpt->u.cur);
>  
> -        ct = pmpt->perf.state_count;
> -        if ( copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct*ct) )
> +        ct = min_t(uint32_t, pmpt->perf.state_count, op->u.getpx.total);

With this, ...

> +        if ( ct <= op->u.getpx.total &&

... this is going to be always true, isn't it? Which constitutes a violation
of Misra rule 14.3.

Also it would be nice if the min_t() could become a normal min(), e.g. by
"promoting" op->u.getpx.total to unsigned int via adding 0U. This way it's
clear there's no hidden truncation (or else there might be an argument for
keeping the check above).

> +             copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct * ct) )
>          {
>              spin_unlock(cpufreq_statistic_lock);
>              ret = -EFAULT;

Why would you constrain this copy-out but not the one just out of context
below here? (The question is of course moot if the condition was dropped.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 14:28:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:28:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982921.1369282 (Exim 4.92)
	(envelope-from )
	id 1uEqcD-0003L4-5e; Tue, 13 May 2025 14:28:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982921.1369282; Tue, 13 May 2025 14:28: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 1uEqcD-0003Kx-33; Tue, 13 May 2025 14:28:17 +0000
Received: by outflank-mailman (input) for mailman id 982921;
 Tue, 13 May 2025 14:28:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEqcB-0003KU-Iu
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:28:15 +0000
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com
 [2607:f8b0:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 80b26f1e-3006-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 16:28:14 +0200 (CEST)
Received: by mail-pg1-x530.google.com with SMTP id
 41be03b00d2f7-b1fd59851baso3733209a12.0
 for ; Tue, 13 May 2025 07:28: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" 
X-Inumbo-ID: 80b26f1e-3006-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747146493; x=1747751293; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=dHN+rERbkNjNisqj0SbLVcFdYGqHAB7CnN/WtcaKnRU=;
        b=F/HnAA3UDWCR384Ci5QTOQ5OmalYLCQRjL8QU1fPAmc40RxqSDZeCEDRmbuI0aBmlc
         sxzTD1C6xxGxuBqG9dI9PtbFI+gErbvxWsZpKhre8C+UUVtogIM4lT2kuRj8qOoXczNv
         n1iSYSHLdiHp2EQrpgtp1F6bI//QzZrRfa4xQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747146493; x=1747751293;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=dHN+rERbkNjNisqj0SbLVcFdYGqHAB7CnN/WtcaKnRU=;
        b=XXZfmKlhpoaE+CsApqzTVUjxEwdgeOCzaVmxaccd5n1oFPuH0FSiHk0VAEFTAJvJLM
         KCsm6CDypi3Mo0ntD+r++HjrnN2rF6sj5qrIA92cZBoebbKjVqcVwO14dT7C4Aqc+CZd
         HgvnzAWjZJp4eR7TMqHKtO9uGqzsBLqZWR8kiWe6RkPL0dR4t04ampKQwuL+XraSGA44
         NzMOF78MGCu+VLTBVv82T9FDa6m0xrWxO6CzUFjolkb5xirSE8vDNdvoZmPdiGadPGil
         6jfoG0O13o08zL1EB2OhrM5W+L+iwIZa4yxJpeqNCov95OHEtzD4GoyiFsPHYBEoACGy
         RUng==
X-Forwarded-Encrypted: i=1; AJvYcCW/GJb+D6+yITeDyW2Zj9Ro42gXaD+9m9EucPJM0jClHciGoFyvilxM1nh8z2rwD+CwezcKd+e2rsI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzn/dKEGPDzeX49ukFR85NlUwTglpRmSleH98Gt/IqtUEi2aInL
	Stdm6MeKcFkrysW7SNtiV6rQAU3nIRrTyypwYRPV6Sgyy281q1U7rw5qAL/+/ARYSb7YyIKbI6a
	KOQ3Fg4vA0lA4mMgKOlDUrWHKlk4/OLtpzHXShQ==
X-Gm-Gg: ASbGncsLEqaZYlPvTtfpjQO++Mr2ryuNJ4aZdBgwx6SLNufpXh+Y00LqwMGvfsuLu1V
	6cb5OTmSxzIjy0kLVCb4jphS3l42Q0oEiogl1jUxXVQOObSTb4Ar0+M+Jvf10pw1W5Qb794kdLi
	h3CcRgK+43mF6Es7uQW5sCvu1/khpC7NXv3SduQ2QLDg==
X-Google-Smtp-Source: AGHT+IGyDWaqSWWeqquZR3D/gciySSJwzgvBR1qJNrT3L7QL0wdITnGw51N9cxxJeu7JzflIIKnfWGuz856TGxSsryI=
X-Received: by 2002:a17:903:230d:b0:22f:c530:10a with SMTP id
 d9443c01a7336-22fc8b417d0mr214663775ad.20.1747146492709; Tue, 13 May 2025
 07:28:12 -0700 (PDT)
MIME-Version: 1.0
References: <20250506162510.1676425-1-kevin.lampis@cloud.com>
  
 <504f0be0-91fd-4847-8fcd-505771674814@suse.com> 
 <55e73266-7727-4a1c-93e8-dd69712d64d2@suse.com>
In-Reply-To: <55e73266-7727-4a1c-93e8-dd69712d64d2@suse.com>
From: Kevin Lampis 
Date: Tue, 13 May 2025 15:28:00 +0100
X-Gm-Features: AX0GCFs2eP3siBmvRxx5ydJBqMn_ZFmovVMQb3dQqbW7aim10IbqV_kchc3iVZ4
Message-ID: 
Subject: Re: [PATCH 3/4] Add lockdown mode
To: Jan Beulich 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 13, 2025 at 12:09=E2=80=AFPM Jan Beulich  wr=
ote:
> I would like this to at least be considered.
> I don't like that custom command line parsing very much.

I understand. Parsing code can be risky.

In this case I think the code is small and simple though.

My concern with asking the user to always put the `lockdown` argument first=
 is
that it opens things up to user error.  I am not aware of any other project
that does this.


From xen-devel-bounces@lists.xenproject.org Tue May 13 14:29:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:29:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982929.1369293 (Exim 4.92)
	(envelope-from )
	id 1uEqdS-0003sG-ER; Tue, 13 May 2025 14:29:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982929.1369293; Tue, 13 May 2025 14: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 1uEqdS-0003s9-Bo; Tue, 13 May 2025 14:29:34 +0000
Received: by outflank-mailman (input) for mailman id 982929;
 Tue, 13 May 2025 14:29:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEqdR-0003s1-3O
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:29:33 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id af886120-3006-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 16:29:32 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-acbb85ce788so1055804666b.3
 for ; Tue, 13 May 2025 07:29:32 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197ca2b4sm778952466b.160.2025.05.13.07.29.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 13 May 2025 07:29: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" 
X-Inumbo-ID: af886120-3006-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747146571; x=1747751371; 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;
        bh=eR4UCFvdNW2Jmn1DjKvfq3Y5QyXctLHc7HhrMpab29k=;
        b=Fm5Il8dgxqzsX2nBozaB3ibeV8pUzGObKSGv4N+BPc/GhGi9i6RlPwWTxjwrkqRPug
         mPRRV1d88k5rjMRCOY2KNRVVJ9uQlvWnuTiZPBbartW8Lby6F/SfKFlY/Y+8RJIllIAa
         mSBLcRJhvM2BpDxPA99H+3XmprrBAX24TSGLgsGpNIFq7ly0HAiDZyzzAWunj0dIE0GI
         vrp/fPTSNVcUdL4h6yHMp2CGC1nXCth1ijmth1UhwxmbOYuzptKtGnQpYNqysIFL5tyq
         g7pB9RFIq96wdPXrm3Wrv5p1cTxtQU+nRoAKL07XUQ8zOzZZ9P8333pI/4P4Nti4UdCH
         C3qA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747146571; x=1747751371;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=eR4UCFvdNW2Jmn1DjKvfq3Y5QyXctLHc7HhrMpab29k=;
        b=Jeplp1LCLrW4qMZ+q93XdPfQUc0fy8EGNBOWv5vE7znKMtVQCE5CCrAats2yaSEBgT
         oDV2aV40BdFpoVlXYF32wLu7BfOuqiqE12pgH+jqDyuUvqOD5f1hBrwZs1Ztpq62OeOz
         2x1E/LehFno72sx9XrP3Q65mzAPRQpHqsj9Vahuty0DnKXABfaknplfeLQWnaxZb0H6R
         oUajJCOnl1k6ChKd/ij//4wiwgcXbMov1V1XcruV2NRRbqOpFD4EP10qSj18vDRst912
         HkbBKNg2O+CsyCVCmXu+NgKlI+xFyuA7/JHUGFpRNpfJct3iic9jWrO/x0YV4xjEnIqK
         RHag==
X-Gm-Message-State: AOJu0YyEFuYcKQGsxRYXGvWk8iDckvULMODjZ3VGHryHWE+j0AvGTUiC
	Fdhez2rgTmel1W5qeC7Tqjlu7GMRJ27DEa79UUIsuakPmXwTDA1b0mGlog==
X-Gm-Gg: ASbGncv0spEyJg5SCmZX3QPyvZeQd4LBqT4+fd6eSWYBWnRQgYEQ/AN6kDQ1RFWINv3
	0nnFHwfrLPihiNWlL5qafiSTQzXCHpk9r8cj4ZYzgkeymLrYrsuoLjXis2HPk9DLFxvgxo7XPTm
	VXP4bLYOFFwKaioEL1U6/HtUEyulnh5XPLg+vdZtyqqHBV5TY4KEJiyI+cqoy6TSahUwiGtkl2W
	v71DVSkh9aUxlTwO3pmkh9dCtm5bC2fOh2JPYzPDdgp5fZJLSiczNhBwvxyT35A31ApExf1IG/l
	fc5LCdtU2MZ10qeBaplCMExp8WekEx0kqacGJoU5by51kqUIIp59+u8x/PY8Ch84hrhBLvNv942
	yW1RcmhKMGKuSfMWrCGLXcLgwRvZr
X-Google-Smtp-Source: AGHT+IGLBwdYxZLtNSw/v4Tw1/xxsG+WCT6uU5+IaaxLBsTLENg0zH/5kO2UWTYgz1RN3UiFoB9/bw==
X-Received: by 2002:a17:907:9447:b0:ad4:c55e:ef9b with SMTP id a640c23a62f3a-ad4c55ef21emr651300866b.58.1747146571069;
        Tue, 13 May 2025 07:29:31 -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 v1 0/3] common dom0less updates
Date: Tue, 13 May 2025 16:29:25 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch series refactor construct_domU() by moving back some Arm-specific
changes to Arm code as they aren't used now by other architectures.

Introduce arch_contruct_domU() to cover arch specific steps of a guest
domain construction.

Add ARM dependency for CONFIG_STATIC_MEMORY as, at the moment, it it supported
only for Arm.

Move make_chosen_node() to common code as nothing Arm specific is in the
current implementation of Arm's make_chosen_node().

Xen CI testing: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1815213130

Oleksii Kurochko (3):
  xen: restrict CONFIG_STATIC_MEMORY to ARM
  xen/dom0less: refactor architecture-specific DomU construction
  xen/dom0less: move make_chosen_node() to common code

 xen/arch/arm/dom0less-build.c            | 42 +++++++++----
 xen/arch/arm/domain_build.c              | 46 --------------
 xen/common/Kconfig                       |  2 +-
 xen/common/device-tree/dom0less-build.c  | 76 +++++++++++++++---------
 xen/include/asm-generic/dom0less-build.h |  3 +-
 5 files changed, 83 insertions(+), 86 deletions(-)

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 14:29:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:29:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982930.1369302 (Exim 4.92)
	(envelope-from )
	id 1uEqdU-00047A-O3; Tue, 13 May 2025 14:29:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982930.1369302; Tue, 13 May 2025 14:29:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEqdU-000473-L2; Tue, 13 May 2025 14:29:36 +0000
Received: by outflank-mailman (input) for mailman id 982930;
 Tue, 13 May 2025 14:29:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEqdS-0003pS-Ef
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:29:34 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aff2273f-3006-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 16:29:33 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad23db02350so568886866b.1
 for ; Tue, 13 May 2025 07:29:32 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197ca2b4sm778952466b.160.2025.05.13.07.29.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 13 May 2025 07:29: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" 
X-Inumbo-ID: aff2273f-3006-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747146572; x=1747751372; 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;
        bh=R3KsIxN/HFuAUbvxsLdzJtfMwgSAXD/I7p0jaxNXAMU=;
        b=QR9ErIOIl7SwdHwqt7NCUJPeQsZn372/s+/wOzLly4LrSWRROhms4btoE2BW58gKEE
         DnSIpuN645e7SI3FEyWjAde4Rm04AS8jb9oEjg+YCQldfUt/ZwZiSXQpmUBnmU7CGsjS
         hbvm1OmlHE/2Z+hSpqHtGFojd8w6aDomnN5VAKNIaIHGGwuFfM8AW9MDEmkWf83rqMed
         ocfcVJJpnEFkidrZoqnyZVXoR0aEWc6sQRmJWKU63rVowRHWsbEODY1m9e6Y10Rl7lN+
         hLkyfVac1mTS5P9yAq4GZPFkY87wxai3mK10ko2HmOvrAqq00O+YjmvwHXmbe10CqH2b
         IxhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747146572; x=1747751372;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=R3KsIxN/HFuAUbvxsLdzJtfMwgSAXD/I7p0jaxNXAMU=;
        b=bjO72xT5PjB4OqHX2Q9DX57QuGFUex+RfwWcgdo4mB1DDPn0Ol3rHpEHCzW+dusTcO
         ECK+XbwaZdLFOv1W//iDz3DL8Tv6wXA5g1hvhkAfU1DFaXzc2YxiA+ClCLSRaiSZl5Dc
         /J8lKQ2DAM21swcZDxFeWGNrgFKinIFWgnAkVdkWbFP9h87SaF4k6MehsWpXE2XRuc/F
         z6IKl2iy2X80Bkt7oSSlCXK7QNpwmJuKSJ9N0H2xdsC2XlinT41rlnPfZHfK+YaiRIp5
         n5Q2y4aqt12EdMzV9XIB+LhwJE6idLskoSatAqfWsOPRAosXsnSfsm+C+ybOvReW7Jbm
         EfWw==
X-Gm-Message-State: AOJu0Yx0tOfbY8Fnr7SB3IzmI0A1eUF15JskMWVNTwxKwBF1wy1LpjMm
	tqnmzfMglLXCKAq8hMXqrRR9T47t28bYEv99kFav36jjn+I1q+XSkNcGRA==
X-Gm-Gg: ASbGncvGCazRnAwLl5zprHURa6iXSpBDJE253TJb5oSpCEncNnDJnBNnZA4yDLDHNps
	l417e0H/8xHjceFHafKo5YuW8JOxVanUa4FpxMtlXmlfknCgAwWziEyPpODdssqpQ4YHbyNcv5f
	25ZNbcgVbhO9fUKbrHUTySYp6dOxdR6ac9HPF2PPI6JiU2NnG/h3iYwbosG/v1aqqzCNnbs4Ubz
	SkoatGIRh58AtnmROy05cnaIKHX85lHSf19nQJQvg1gCFOfzb/UNqvfLparZB9cbt92OecBnpqg
	fK/0Ni1zP/b6knv3c5j1diPLvysw+yvAEIkjMMokVAtzBrNg3pTYrmf/e7gyAOrM9FHwtRLjoKg
	juj7/ttXt8IY9e0PEOw==
X-Google-Smtp-Source: AGHT+IHvDKrcm5EIAfWEwLCJGVdb2MtWTj4Y9h1Wt9ttaSNtX+3LeS3O1szFbN8nYpIojGfETO10dw==
X-Received: by 2002:a17:907:3f11:b0:ace:d710:a8d1 with SMTP id a640c23a62f3a-ad218f1bafcmr1609678266b.24.1747146571959;
        Tue, 13 May 2025 07:29:31 -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 
Subject: [PATCH v1 1/3] xen: restrict CONFIG_STATIC_MEMORY to ARM
Date: Tue, 13 May 2025 16:29:26 +0200
Message-ID: <7e5ae810c1cf542ea33b2a2e836e8d9d7b1749b2.1747145897.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Now that CONFIG_DOM0LESS_BOOT has been moved to common code and is planned to
be supported by other architectures (e.g., RISC-V), the dependency for
CONFIG_STATIC_MEMORY needs to be updated.
Since CONFIG_STATIC_MEMORY is currently only supported on ARM, its dependency
should explicitly reflect that.

Signed-off-by: Oleksii Kurochko 
---
 xen/common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index bf7b081ad0..5f4a16e113 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -148,7 +148,7 @@ config NUMA
 
 config STATIC_MEMORY
 	bool "Static Allocation Support (UNSUPPORTED)" if UNSUPPORTED
-	depends on DOM0LESS_BOOT
+	depends on DOM0LESS_BOOT && ARM
 	help
 	  Static Allocation refers to system or sub-system(domains) for
 	  which memory areas are pre-defined by configuration using physical
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 14:29:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:29:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982931.1369309 (Exim 4.92)
	(envelope-from )
	id 1uEqdV-0004AB-4e; Tue, 13 May 2025 14:29:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982931.1369309; Tue, 13 May 2025 14:29: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 1uEqdU-00049H-T7; Tue, 13 May 2025 14:29:36 +0000
Received: by outflank-mailman (input) for mailman id 982931;
 Tue, 13 May 2025 14:29:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEqdT-0003s1-9o
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:29:35 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b0f338a9-3006-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 16:29:34 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5f624291db6so9681958a12.3
 for ; Tue, 13 May 2025 07:29:34 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197ca2b4sm778952466b.160.2025.05.13.07.29.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 13 May 2025 07:29: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" 
X-Inumbo-ID: b0f338a9-3006-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747146574; x=1747751374; 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;
        bh=0mmaIut+bB6JzVtawKv0l2+/AbruT3la6NzpbEBxjqw=;
        b=LoSvhdw5nehZHzk/8Jbvg+yaSZYHJ5puIV0R+IWzpC4UF1ASRTYcLvsbR+We6J8Yew
         kRxEgt1UFlnbJKCfHnJnmqLralp1dlcyRiKpNnZlhOBMz/nUM1+uV22gFZjrh7ZNk74e
         Oh5bCZ3Y18YFnC+3zS/ElUnPBgwZggwrkZMPcNX9qsZm5XDCfKW0EcXVDZzJXKlObXYT
         /Bg0cxbBv9tbK4nzqJrNzZoVxdlWKk2zWaI5PpRTwVAXxFBNfNOeXAo/29uuZq3Puxqe
         xrU9vyu71oYAMkWvHKXXdEtudGl4uChDxOQ+BM+H7EWOlsvt5cfG6XnhlVrJZn5lIYjq
         S5gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747146574; x=1747751374;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=0mmaIut+bB6JzVtawKv0l2+/AbruT3la6NzpbEBxjqw=;
        b=Myx4AHioa1TR2F9vFuDgwnjAAnTcnPtPDUErRnZsBNnajLh4fHwSf7JFeABTfOp/DY
         gT2WD0G512lEE+Tbt5DdPKAcw+NKATfmWejgdS2KZQNJiPB9wI4zc6UTCnOH0aIPZLm0
         sj+HN0GQV6TUCq8iOt26MDLOUlEGUyqEyZGWCKYjNnrZzHSOD0wsc5oxe08dPnKxvtvG
         6y8YF3cPUAVn/kaOpGCQDofPF2iymRvMgHwI/VkOqJkYHmyQGsEoOvyqttpIWXZPH0uD
         qBXihwLhDDrz5XIfpXblmk/jz6YnlWtus4OoKsZ7fyvkhJxwTawS2AVzKRlR1FDy7i9O
         itag==
X-Gm-Message-State: AOJu0YxhyZvAtD6ts61LAMgr68fNxwOx3Y4o/N58KIWgWahxxlajTWoF
	Dq4FrYiv1VyL/XXXXjuL27MAmHOkA4eg8egEh5LI2LAAD7yNrSzB0o5nxg==
X-Gm-Gg: ASbGnctOwZaKI+uBxjAZbXCCgNm7+HGHO+1LEuuqbUo0BEut50puyZU1TxISCOtbbMO
	0MFU61PzIPbN0TZNRtp8gvpampeuuUFD5SOdZz14khovWCINoV0PcIR9gPtGB5OxUd3lU2alowp
	B6v9VsD3UvQBKwf7jB/VuzbZdm4A71WxIW0pJC8lGM2e+ZuGbt5zXl02rREOfOsy93rzwmCS1hE
	idFIZZxKTqQZM+tpQXG+ZxWjd9PSJuE0MIU9pbZMDEmcIQuJ5O8A5VSUAhal0Jh/2Y4NDzNSwFP
	GyamcGo2iqULEJVXui5T/xl7NArvwKRgiF+dnKblGPfwutiZZxSYG7I/cXyQFpVgVllxf6y5BL1
	mzmx7KJFZXVJ2iNz2xA==
X-Google-Smtp-Source: AGHT+IEh0F5gqDJkUU+wGo+FupnzK7UMqX/dMJXfIaRgV/WqRtMGo+DSihPvLfiV3rLxnGcd9eWeTQ==
X-Received: by 2002:a17:907:6d12:b0:ad2:5021:bf3c with SMTP id a640c23a62f3a-ad25021dcbcmr904419866b.52.1747146572983;
        Tue, 13 May 2025 07:29:32 -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 v1 2/3] xen/dom0less: refactor architecture-specific DomU construction
Date: Tue, 13 May 2025 16:29:27 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Refactor construct_domU() to improve architecture separation and reduce
reliance on ARM-specific logic in common code:
- Drop set_domain_type() from generic code. This function is specific
  to ARM and serves no purpose on other architectures like RISC-V,
  which lack the arch.type field in kernel_info.
- Introduce arch_construct_domU() to encapsulate architecture-specific
  DomU construction steps.
- Implement arch_construct_domU() for ARM. This includes:
  - Setting the domain type for CONFIG_ARM64.
  - Handling static memory allocation if xen,static-mem is present in
    the device tree.
  - Processing static shared memory.
- Move call of make_resv_memory_node() to Arm's make_arch_nodes() as
  this call is specific to CONFIG_STATIC_SHM which is ARM specific,
  at least, now.

This cleanup avoids empty stubs on other architectures and moves
ARM-specific logic into arch code where it belongs.

Also, don't loose  a return value of functions called in
Arm's make_arch_nodes().

Suggested-by: Michal Orzel 
Signed-off-by: Oleksii Kurochko 
---
 xen/arch/arm/dom0less-build.c            | 42 +++++++++++++++++-------
 xen/common/device-tree/dom0less-build.c  | 30 ++---------------
 xen/include/asm-generic/dom0less-build.h |  3 +-
 3 files changed, 36 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a49764f0ad..592173268f 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -220,9 +220,14 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
 {
     int ret;
 
+    ret = make_resv_memory_node(kinfo, GUEST_ROOT_ADDRESS_CELLS,
+                                GUEST_ROOT_SIZE_CELLS);
+    if ( ret )
+        return ret;
+
     ret = make_psci_node(kinfo->fdt);
     if ( ret )
-        return -EINVAL;
+        return ret;
 
     if ( kinfo->arch.vpl011 )
     {
@@ -230,26 +235,41 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
         ret = make_vpl011_uart_node(kinfo);
 #endif
         if ( ret )
-            return -EINVAL;
+            return ret;
     }
 
     return 0;
 }
 
-/* TODO: make arch.type generic ? */
-#ifdef CONFIG_ARM_64
-void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
+int __init arch_construct_domU(struct kernel_info *kinfo,
+                               const struct dt_device_node *node)
 {
+    int rc = 0;
+    struct domain *d = kinfo->d;
+
+#ifdef CONFIG_ARM_64
     /* type must be set before allocate memory */
     d->arch.type = kinfo->arch.type;
-}
-#else
-void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
-{
-    /* Nothing to do */
-}
 #endif
 
+    if ( !is_hardware_domain(d) )
+    {
+        if ( dt_find_property(node, "xen,static-mem", NULL) )
+        {
+            if ( !is_domain_direct_mapped(d) )
+                allocate_static_memory(d, kinfo, node);
+            else
+                assign_static_memory_11(d, kinfo, node);
+        }
+
+        rc = process_shm(d, kinfo, node);
+        if ( rc < 0 )
+            return rc;
+    }
+
+    return rc;
+}
+
 int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
                       const struct dt_device_node *node)
 {
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 2c56f13771..f6aabc2093 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -28,14 +28,6 @@
 #include 
 #include 
 
-#if __has_include()
-#   include 
-#endif
-
-#if __has_include()
-#   include 
-#endif
-
 #define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
 
 static domid_t __initdata xs_domid = DOMID_INVALID;
@@ -507,12 +499,6 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     if ( ret )
         goto err;
 
-#ifdef CONFIG_STATIC_SHM
-    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
-    if ( ret )
-        goto err;
-#endif
-
     /*
      * domain_handle_dtb_bootmodule has to be called before the rest of
      * the device tree is generated because it depends on the value of
@@ -787,7 +773,9 @@ static int __init construct_domU(struct domain *d,
     if ( rc < 0 )
         return rc;
 
-    set_domain_type(d, &kinfo);
+    rc = arch_construct_domU(&kinfo, node);
+    if ( rc )
+        return rc;
 
     if ( is_hardware_domain(d) )
     {
@@ -799,18 +787,6 @@ static int __init construct_domU(struct domain *d,
     {
         if ( !dt_find_property(node, "xen,static-mem", NULL) )
             allocate_memory(d, &kinfo);
-#ifdef CONFIG_STATIC_MEMORY
-        else if ( !is_domain_direct_mapped(d) )
-            allocate_static_memory(d, &kinfo, node);
-        else
-            assign_static_memory_11(d, &kinfo, node);
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-        rc = process_shm(d, &kinfo, node);
-        if ( rc < 0 )
-            return rc;
-#endif
 
         rc = init_vuart(d, &kinfo, node);
         if ( rc < 0 )
diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
index e0ad0429ec..78142e71ca 100644
--- a/xen/include/asm-generic/dom0less-build.h
+++ b/xen/include/asm-generic/dom0less-build.h
@@ -56,7 +56,8 @@ int init_vuart(struct domain *d, struct kernel_info *kinfo,
 int make_intc_domU_node(struct kernel_info *kinfo);
 int make_arch_nodes(struct kernel_info *kinfo);
 
-void set_domain_type(struct domain *d, struct kernel_info *kinfo);
+int arch_construct_domU(struct kernel_info *kinfo,
+                        const struct dt_device_node *node);
 
 int init_intc_phandle(struct kernel_info *kinfo, const char *name,
                       const int node_next, const void *pfdt);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 14:29:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:29:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982932.1369314 (Exim 4.92)
	(envelope-from )
	id 1uEqdV-0004E7-Ex; Tue, 13 May 2025 14:29:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982932.1369314; Tue, 13 May 2025 14:29: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 1uEqdV-0004Cn-5m; Tue, 13 May 2025 14:29:37 +0000
Received: by outflank-mailman (input) for mailman id 982932;
 Tue, 13 May 2025 14:29:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEqdT-0003s1-NE
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:29:35 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b1476b26-3006-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 16:29:35 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad24b7e0331so425349766b.0
 for ; Tue, 13 May 2025 07:29:35 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197ca2b4sm778952466b.160.2025.05.13.07.29.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 13 May 2025 07:29: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" 
X-Inumbo-ID: b1476b26-3006-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747146574; x=1747751374; 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;
        bh=UZsMZZN4khD+tCxXKeFysBlRlf4LYZbhvhNdRNB+85Q=;
        b=hrw6OBtqTLGaH//R4QOcbTI6RTrcLebiXOXMvh150bIvl6dovdVRtza9/dDCxCKyG8
         rkwo2OIantEho9HUtTtclJthlVJG3XucHnAI3X5ns4qalJL02tMrOawWbGJRoI38G+cR
         FInHK0GeeXFIwINv1USos5fpwpWz2G0nrEl7TgyDiJ9Q/EKmYzIso2om7iRNUgQ3/2Li
         qh2Xi+axYy3h6vtmMEv/x+FCqd3RvOntWMub4LpUckrzY1LF+1tmA7Wly3kD82WbzBHX
         8dPFY2pVaFTa0XYdC7N4ab4yQl8tyN1huc1jHIVVTAume7ok6paoPuyi7GfX+398J14h
         HFaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747146574; x=1747751374;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=UZsMZZN4khD+tCxXKeFysBlRlf4LYZbhvhNdRNB+85Q=;
        b=LCYY++ilYJj68KTwgz+guDVH2VsR8Koi/I4qlHqeV9ST265ZSrKXK0q6W0cCzdN4ey
         Fee1jTPvKuZPj37uo7j2A8wlMyuJwjhj/UMo3T73drO3NI9lYxOMRYKnGqYf7NsMjRTj
         mo2HMtLHMwjjv7+TO9vaiG2ZEKUtiuxbl5pCL6ycoBreW9MlbK0ZoFYOe4b/sBxhkwtn
         bCKE+OvzpdfRnwX/Cq2g8TdtCNzgw48aox86M3ylLBqDRPObyZs0l8V+ecFZLW4ITI8Y
         DlgQFUFx5/e2shxfo+ge6cnCz+bpoFOtpbG9A0uxarufXJpb0WyRoDqeAUXyRARg/k1J
         kTIQ==
X-Gm-Message-State: AOJu0YzmMHHSdR2RYAeDjVTU+56bsVcdir3Xpx74ach3X17VHejY/GSR
	A4O9UT+v4e5ZGbQYWnkIKJtE8ShxaDmIE00/p08yHMhqeexswiBNEJ/8Qg==
X-Gm-Gg: ASbGncuBqMK+U9vk/SwFcSVzdWfTArNkvBu5dDR3tEJ3qW2tBavKN/S/tIOr0fSoIL5
	XjepoVrSsuQ1poMIUx1T/usLb39tMu47mTTSWIkzu4v26n8ue0J+M0Gy1AKAHFQ1p5l9QQPad/v
	thMzcVbEHpJY+1MNpYbjag6kc2mUgdcbqTr4Hh2etms5bytqzEpPnjaCUFNg+yNpxEJOCigQ2Pa
	08q+NBL2WcyeeGBTtlmDHcR0C9Scbqlgl4veeOTvV8W+in+K1uLl2ynOcrNyfOJ6nrmpLb8oiKI
	oeMwqggAl1XZUyscEDbXbfVx8BXIOdBwnoIViLSTwZf4sxqjrcaProfnAvydIyWrIzfLibKquis
	AmJpq5YyDvCdyR0guug==
X-Google-Smtp-Source: AGHT+IE9cgPaCM7BS6Eml7ivJ9CqmHMGc3KFJlYK/ty0Ha1pBEuAv17nL210cXysSsurYIG1B7W+kg==
X-Received: by 2002:a17:907:72d0:b0:ace:6d5b:e785 with SMTP id a640c23a62f3a-ad2192b6b17mr1575576866b.47.1747146573733;
        Tue, 13 May 2025 07:29:33 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v1 3/3] xen/dom0less: move make_chosen_node() to common code
Date: Tue, 13 May 2025 16:29:28 +0200
Message-ID: <9c87738225d48bd1ee9bba6e8d4e018dfecabccd.1747145897.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The current implementation of make_chosen_node() does not contain any
architecture-specific logic. Therefore, move it from arch-specific
files to common code.

At this stage, there is no need to introduce an arch_make_chosen_node(),
as no architecture-specific customization is required.

This change avoids duplication and simplifies future maintenance for
architectures like RISC-V and ARM.

Signed-off-by: Oleksii Kurochko 
---
 xen/arch/arm/domain_build.c             | 46 -------------------------
 xen/common/device-tree/dom0less-build.c | 46 +++++++++++++++++++++++++
 2 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..9e71cc8cef 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1470,52 +1470,6 @@ int __init make_timer_node(const struct kernel_info *kinfo)
     return res;
 }
 
-/*
- * This function is used as part of the device tree generation for Dom0
- * on ACPI systems, and DomUs started directly from Xen based on device
- * tree information.
- */
-int __init make_chosen_node(const struct kernel_info *kinfo)
-{
-    int res;
-    const char *bootargs = NULL;
-    const struct bootmodule *initrd = kinfo->initrd_bootmodule;
-    void *fdt = kinfo->fdt;
-
-    dt_dprintk("Create chosen node\n");
-    res = fdt_begin_node(fdt, "chosen");
-    if ( res )
-        return res;
-
-    if ( kinfo->cmdline && kinfo->cmdline[0] )
-    {
-        bootargs = &kinfo->cmdline[0];
-        res = fdt_property(fdt, "bootargs", bootargs, strlen(bootargs) + 1);
-        if ( res )
-           return res;
-    }
-
-    /*
-     * If the bootloader provides an initrd, we must create a placeholder
-     * for the initrd properties. The values will be replaced later.
-     */
-    if ( initrd && initrd->size )
-    {
-        u64 a = 0;
-        res = fdt_property(kinfo->fdt, "linux,initrd-start", &a, sizeof(a));
-        if ( res )
-            return res;
-
-        res = fdt_property(kinfo->fdt, "linux,initrd-end", &a, sizeof(a));
-        if ( res )
-            return res;
-    }
-
-    res = fdt_end_node(fdt);
-
-    return res;
-}
-
 static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
                               struct dt_device_node *node,
                               p2m_type_t p2mt)
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index f6aabc2093..1265cadf94 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -434,6 +434,52 @@ static int __init domain_handle_dtb_bootmodule(struct domain *d,
     return res;
 }
 
+/*
+ * This function is used as part of the device tree generation for Dom0
+ * on ACPI systems, and DomUs started directly from Xen based on device
+ * tree information.
+ */
+int __init make_chosen_node(const struct kernel_info *kinfo)
+{
+    int res;
+    const char *bootargs = NULL;
+    const struct bootmodule *initrd = kinfo->initrd_bootmodule;
+    void *fdt = kinfo->fdt;
+
+    dt_dprintk("Create chosen node\n");
+    res = fdt_begin_node(fdt, "chosen");
+    if ( res )
+        return res;
+
+    if ( kinfo->cmdline && kinfo->cmdline[0] )
+    {
+        bootargs = &kinfo->cmdline[0];
+        res = fdt_property(fdt, "bootargs", bootargs, strlen(bootargs) + 1);
+        if ( res )
+           return res;
+    }
+
+    /*
+     * If the bootloader provides an initrd, we must create a placeholder
+     * for the initrd properties. The values will be replaced later.
+     */
+    if ( initrd && initrd->size )
+    {
+        u64 a = 0;
+        res = fdt_property(kinfo->fdt, "linux,initrd-start", &a, sizeof(a));
+        if ( res )
+            return res;
+
+        res = fdt_property(kinfo->fdt, "linux,initrd-end", &a, sizeof(a));
+        if ( res )
+            return res;
+    }
+
+    res = fdt_end_node(fdt);
+
+    return res;
+}
+
 /*
  * The max size for DT is 2MB. However, the generated DT is small (not including
  * domU passthrough DT nodes whose size we account separately), 4KB are enough
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 14:32:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:32:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982971.1369333 (Exim 4.92)
	(envelope-from )
	id 1uEqgC-0007PZ-QK; Tue, 13 May 2025 14:32:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982971.1369333; Tue, 13 May 2025 14:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEqgC-0007PS-NE; Tue, 13 May 2025 14:32:24 +0000
Received: by outflank-mailman (input) for mailman id 982971;
 Tue, 13 May 2025 14:32:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEqgB-0007PK-DE
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:32:23 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1463fa52-3007-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 16:32:21 +0200 (CEST)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-54fc9e3564cso5592839e87.2
 for ; Tue, 13 May 2025 07:32: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
 a640c23a62f3a-ad2192c8608sm785104966b.26.2025.05.13.07.32.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 07:32: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" 
X-Inumbo-ID: 1463fa52-3007-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747146741; x=1747751541; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tOyPmbukr/Ucl9sZNJb+v8hy5xEx+P98pxjX96YuxYg=;
        b=NUM1iIQeV2cbVvBk8gUFqigYul/RfwBByD9VmMRK51/xO95F44h30BD3Li+M+NVV+7
         Z8Fizg/Y0wTaU2CngGZam5Kifumy+siRJTtFrq+nF8M4l6iwzrWSwE5Tp6En2Z0AO3ib
         gxB5pSlYBtdG1GjA1djQolZ6o7O5k1y12mUuFIK9PACguc3mHdFRNwXXX2oSuER5PuL1
         01e47XgGIdjU3DNJBrmlfgPc1EYTdY4Y2aGnUxsZ8Q5jqef/XSLycr4Ge1l0jaDGHehA
         qkoB6OOcdNTrOQoFT2uGDJwKyM+RFKEOd9xy91Iv/S+VHOWmGhU7U3VMCsM6JVCPcczH
         pKvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747146741; x=1747751541;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tOyPmbukr/Ucl9sZNJb+v8hy5xEx+P98pxjX96YuxYg=;
        b=aWqssOshCbxCFt2m2KAP0HVX9t+c1+YYz5glWHZd2RPUktDJ1S/Sa/gViVnBgLnINt
         10rhkkCRlT4e3zP8obYM7OyV7d2dVqAUkjgxM7Ts34c8zO4koSL+FYr8e6x2imOtRVrA
         /Ru7WCZlGYSUkeMjdfYKYDZ5/8RhYfHfReEpespsxWRYT/m+qJ/LTs34vyXekmMCQ3Zo
         G7RK6/1d/n02jLr3KwHqlT6m8bijth5BrgJa6hXQYr175Y1H7Uom7iM/TFQYkJsovqf0
         1fy8dVt7U6+Rpq/iQVHbqoj2wdlRLdZoZ8BFb4TIKEQsXzF0tHMoPcp4Q4oI4qkgFq98
         ju3w==
X-Forwarded-Encrypted: i=1; AJvYcCXEraHvk2BUCYMt6t/3Aya3iWcwEvqg2YenvDSc3gphqtx9cutQojCQqRQ5nCoid7J8HSbECguxuLE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyq4PB5l52w+A4NkkUWoBxdaFK2ZFXSc29urH+vacADj8OWz91s
	FuLLPeNUot/UAmfSSS2ULAdxcgocHQYdKq0XWzOLoyzcHIEfvcNlrRHGLN652CNyfTWwnmU2PAM
	=
X-Gm-Gg: ASbGncsy2lqr3OzCDa1Fxx1yrz93J0enOJWmF8FLyWVrHRoMk3h5MR7pCc+2DnHVEg6
	TWzNH1ZP+KsyR6FqeB0niOtoGs64T8yWQoWROMfeqJLpzU3AYHILZ7J6jJmpdOd9cBLzC/7QPTC
	YHMHPLMAOXADdYJGcNI1jVYfJuDFMjGdEFlHlbAfwgmvLz3g5eQ1aI4mnRWP0DsxHXL2h0z2sKz
	yO/6SDYK/ljhKH9zjKRbEwCDTJ45QyWI5KZOGXs5/e0CD8SIJgmHXUjmgc29wUhXCFSnUs9W+/O
	IkpOOyN0chXkGKEapi+dAlgHtccO2sy5J4DNaUU9Lj7MB/Bz5BEWRhGllHOcpbZPI1TlRgTp/UG
	g54ouiSvfeT0HA6wxGn8MXytiqXMxPvMojSnE
X-Google-Smtp-Source: AGHT+IEaMEZNX6VuU1oRHLPekQF1Oy2mlC99rZzciYlr4cqC3uH3Pc2huFqD7lSwljCiNR0A0AUpwQ==
X-Received: by 2002:a17:907:3f9c:b0:ad2:3e8d:6440 with SMTP id a640c23a62f3a-ad23e8d64bbmr1240896766b.33.1747146729771;
        Tue, 13 May 2025 07:32:09 -0700 (PDT)
Message-ID: 
Date: Tue, 13 May 2025 16:32:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] Add lockdown mode
To: Kevin Lampis 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
References: <20250506162510.1676425-1-kevin.lampis@cloud.com>
 
 
 <504f0be0-91fd-4847-8fcd-505771674814@suse.com>
 
 <55e73266-7727-4a1c-93e8-dd69712d64d2@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

On 13.05.2025 16:28, Kevin Lampis wrote:
> On Tue, May 13, 2025 at 12:09 PM Jan Beulich  wrote:
>> I would like this to at least be considered.
>> I don't like that custom command line parsing very much.
> 
> I understand. Parsing code can be risky.
> 
> In this case I think the code is small and simple though.
> 
> My concern with asking the user to always put the `lockdown` argument first is
> that it opens things up to user error.  I am not aware of any other project
> that does this.

Well, it's easily possible to catch that error without any extra parsing.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 14:36:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:36:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982986.1369354 (Exim 4.92)
	(envelope-from )
	id 1uEqjk-000887-GK; Tue, 13 May 2025 14:36:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982986.1369354; Tue, 13 May 2025 14:36: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 1uEqjk-000880-DL; Tue, 13 May 2025 14:36:04 +0000
Received: by outflank-mailman (input) for mailman id 982986;
 Tue, 13 May 2025 14:36:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEqjj-00087u-8f
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:36:03 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20600.outbound.protection.outlook.com
 [2a01:111:f403:2416::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 96aee3bb-3007-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 16:36:01 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by PH7PR12MB7138.namprd12.prod.outlook.com (2603:10b6:510:1ee::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.31; Tue, 13 May
 2025 14:35:56 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8722.027; Tue, 13 May 2025
 14:35: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" 
X-Inumbo-ID: 96aee3bb-3007-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SdyugGuWLqACgswvilKNaimB+Xl18GoJkOwQyY679viOSkdDu7S/Begy/fc8ZhbdDD/njdts64ct7b1OvQR5wfEpzjpQx0dX/vtSHLnBQM9UGif++XO1CpaJWGFjoJ8xAkTe6eJI42Lvg0Xd4YOukTOfeklIH39hFF/uT+jcDINlQbTAXcLGDzgfqP1NgAig2mgif5KNcV1JMzLEsbRzZzs/spl3NJjnI6eytOhhaWMBl5XUUcgCsoXCbbLL1mzv6kwlX6lc6qUKhsHpi450IMwbknZr8cOTbQC4ORghtjNiGMNakTu9/wkBEb3DTr91mLuagzUK79y/gqvG9l3mBw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2ou+H08DgpXPdH5Fc+TEuxB0I5RyEVSYEveewH+BYlk=;
 b=hkYzAAkPA0SEmkc3URoYErUREdeu23Na6qrpwKLqW7MMtdEm5lMBIHDPRwh6jr0XJhrBFcnoTyc7GV8YS1NGZtWMmScCMgyySRDtdemMUax538iJchdnwz6O04VOj3Z2uV8aNKU0psgJUm90Qmf78YJK1mPeRbmsVw7DYiRWrtNi7ljqP01GTIlqk64G8DuMENAjGuuQcYZsCd9tT+agmueGKXBZHBE039XtdVMphoA4iVgBRHyNACrtUlKOeSPYKsjS1yRBR3TV6lS0OQkjYKX17LhtpCcDLQxPDJ5V3AtRs5i08dBpz0VePzbKkTLVjGXOZpM69xuAUkZkjoOmUg==
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=2ou+H08DgpXPdH5Fc+TEuxB0I5RyEVSYEveewH+BYlk=;
 b=A9FOyUvhICamECM/vvRprZaG1p79hLGBHTowqXBGf9Dfn+glHrIK4pV0Ab29kFOdTPL5faWrzhvHPxlyuugCka7N9ht/DWaqQHVBUM6Dem+Tz0PmmXf5fyS6gW7lpCbMxvMeePaM+ALipUl/3Fu6tPtGZROwaC/mr5DqEQ50fFU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <01ed25fd-a5bd-4f44-8e59-0f7c24738aca@amd.com>
Date: Tue, 13 May 2025 16:35:52 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/3] xen: restrict CONFIG_STATIC_MEMORY to ARM
To: Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: 
 <7e5ae810c1cf542ea33b2a2e836e8d9d7b1749b2.1747145897.git.oleksii.kurochko@gmail.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <7e5ae810c1cf542ea33b2a2e836e8d9d7b1749b2.1747145897.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR0P281CA0071.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:49::10) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|PH7PR12MB7138:EE_
X-MS-Office365-Filtering-Correlation-Id: ca913d98-3a4a-40d2-7920-08dd922b78bc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MlI2K2o2S1ovQVgzV2dSV2VYSEg1V1VlMm9sVTRINEp1VXdwMXRoR2Rna3h6?=
 =?utf-8?B?MFNnMXM3TDhqeHBJTk54ejlLajdUTGxTZjNJQXZKVU42REh6a3MxTWg1eHFt?=
 =?utf-8?B?Z3F5SWxNWC96dUxEQUdWSlpkd0pmeTlsWU4vY1V1NWRFTU1IblhWTnc4VjZV?=
 =?utf-8?B?TzdGSWxxcEhZcnlmL2pYQXBNZS9FbGNUaXNNVU1WVjU3cjA1UUV0cTVrY0Fu?=
 =?utf-8?B?R0xzaWVYOE1TaktGNFR5TmNneWo2R3Z3Szh3R29Hb2VNWFI4K2U1Ni83Z3dL?=
 =?utf-8?B?VlMxZUN6QjZTZDJyWWhPTStiSStMZ05iZHNkejdZcFVQZ2tTL09MSHVKTERw?=
 =?utf-8?B?RkpoSkJ2SnlxQ0h4amFBd0dVa0NFcWhvM2xrZnMzWDU4WTlMRzVFdE9HUjJ3?=
 =?utf-8?B?VkdKWHQ4cUlQTDRuQVJNTUdzZ0R5aFo1dFdObGRLYnQvajBFS2NMV25USUJV?=
 =?utf-8?B?TnpISkhtYzZ4UXpZS1ZoN1draVk0WTkxZm8yVzFlb3IxQjlXR0ZWUEJhOTBI?=
 =?utf-8?B?clJpVFNMVmlZUzVSUzZPOGhqWWVqdzgwa2kvaUxGK09PS0xDdGZQUmNUd2VT?=
 =?utf-8?B?YjhybG9QLzExOWh3OEVtMUZWUWE2NXRlWlk0VlJ1WmdmK2RPUEVYcVRoM0NM?=
 =?utf-8?B?TVlCdUlVQi9IYWpIZ0pCelZ2cVNoVzBaQnc2cEc5cHE2QS9Mb3JzZzczWHBz?=
 =?utf-8?B?MzFtTGN2b0ZpbWsrZDlUSkZvSytXOThxWjBJN0N3ek5xNEpqdXhPbmpXMlZJ?=
 =?utf-8?B?UzM2RjRhZWc1anc3d21uQk9xcVltRklEZSsyTm9oRVhaOFpzMmlkMldaK1RP?=
 =?utf-8?B?NytqS3pJeHAya2VFUDhzbmlKQnR6dml3WFBQRUl5T2tyRWZqL2QxYm41YTJm?=
 =?utf-8?B?cmR6dzROZkxUZGpLQ3JEbVJsSHdKTmtqcGRoT2MrRWxRV3ZVbkFLTGVHZHFn?=
 =?utf-8?B?dU9KSGJGMHpKYnZoUEpNL3cyUnRDOG5CNm8wY2RaRFNRMm1qdE9CbG5LVjln?=
 =?utf-8?B?T0FWa3RoUmRsejdEVmZ2dHo4bGNtSmFtakRjR1RzMy9iZmF5dXVXalZScHRB?=
 =?utf-8?B?cmlmNVZzR0lYT2lId09YUjAra3FFcnZoK01xcnhuRis3ekFnWTE2SUdaWU5U?=
 =?utf-8?B?UGNxSUFhdC9aSkx3L2x4REFJNzZPZFZjN2MzcnhlNlpIZWYrL3ZaWkZ2U3RF?=
 =?utf-8?B?NnlTSGFCQjRaYm5GTmc5NHIrU2dYZ05qWUtXa1dnN3FYY2ZRS3ZpU3k0UUN1?=
 =?utf-8?B?Zm9aUFJFWnlrSnpSczVXMFVCQmxLZE5ualJnUzh6TnNBQWtVSVpiMDZNSHpp?=
 =?utf-8?B?ZjdPUG1rTnp4UW5VQnBLdU91NFJWTnRqV2NQU21qU0ZRUWlBazYyWTArc2J4?=
 =?utf-8?B?d3lBVWpMR1RJU1VLSDVxVlpKenBZVk5pVTdkQzI1SW85N3dRY0RWcW5qeUtr?=
 =?utf-8?B?SDdKUUhldlpwQXpCei9SdkN0UVRtVlByNXkwVm5CaktOcHNWWm9FVU53dzMv?=
 =?utf-8?B?TE5SL0pkUGlhQkVHTGhQTWxiZXNPWFlZSWdDM3pjRHJhM1N2WFIyZ0w3V2VT?=
 =?utf-8?B?M3pVZHZ3cnRERncvNCtFWjRibnFNdUtkYnpodWN5SnV5OXRHMzZmYmV0clc2?=
 =?utf-8?B?M1U0VDdSa00vZUcydHl0Sy9PMWhEZFlVUFd0NG5NY3U5bUFJcmN2cGc2QlVv?=
 =?utf-8?B?WjRCek9MVS9hZnlvL3ZxL09oSkRPdkU0QXVjaGJtdWo3TjNoUkRxQ2ZhcEpQ?=
 =?utf-8?B?djBuRmtUQ3l2d2t2K1FjYWgrU3hNcUQ0NTJYS1NMRExwVk9CZ2tZdStKV2pu?=
 =?utf-8?B?N1ArbWJ5VEtlVHZWWXFhRUhoTDRPaS83V1QrQWczejZ2ckhDaUhKRXRWa2tU?=
 =?utf-8?B?UDR4SGIvVUM4NUNUVEQvd3ZKTzdMdDBsQkcxcExPcm56Vnc9PQ==?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UnRRMUN1S1dsR25SVFJlSFU2bXQvM2JZbW1CVjFHQzd2V3MrRENEMDlNQmZz?=
 =?utf-8?B?c0xTYTJTOUVQZzJIaGZoVUwwNHYvN2lDM2hpQXJDTGQvV1YvQk11aWdJTkhz?=
 =?utf-8?B?ZUlZSmdXbVZoSE9YSCtCNS9DOWhCdHl6clJIMUhiM3RCaUN5Z0lFZE1TSFJi?=
 =?utf-8?B?UlpKQVNuNFBOTms4Z09SQ3YxNnpERnFvZkhBckhlaWVyMnhHeGNmM0ZvdlFP?=
 =?utf-8?B?VUlOQjJYQnFqUW50NjUvWngzd2ZnRTlJdFlISkh1TjBNMlI4Z05odGNNc1Vo?=
 =?utf-8?B?L2NFQkovZHhmZko0T2xxbzFhNWNsQS9hQ3M1UlZtRHpMcFh6UUMwWmNuZXB5?=
 =?utf-8?B?Vlp0QUxBTkRVSlAvQWRWTlFrbS9QblB2QS9Dc1VZN09Lc1pQZHYzNzZQN2wr?=
 =?utf-8?B?bTZEMUJWVk8zUVYwOTNPSUxZZzB6azk0S2lrVDI2Uml2RnlGdjYrYUJ3SXdO?=
 =?utf-8?B?dUxjMThZbllGd1kxTmhjUWwraWhlVUxWMEttRkU0NVBoblN4MDdvVXBuSk13?=
 =?utf-8?B?aXAxNGxJb1Y2ZTAvVzdrN1UrdHFDRG8vSzF6cFAxbFROYjVvaFltcHF3OFF3?=
 =?utf-8?B?aE03RkwwSTdwNk1JMDJ5ZlloVE1wc3l5Ty8xakZyTFk3Q0dKL1dqaEI3TGtJ?=
 =?utf-8?B?a1REY3BGKzQ3Y2wzOGYzcExEWkRjdTVTT1JvekVOenJINXl6dG9PZkIwdC9h?=
 =?utf-8?B?QTJqaVNSVWhDRnhtdXJoSFAzL3pJRjA4KzIvNElyMjFXRmh6c0F1dWNHbWZG?=
 =?utf-8?B?TDJDVm1yUGFyWVgyaXV3Wm01bFlzSUJoVDhEcE1Kam15TTdXcXRLN3I2eVI5?=
 =?utf-8?B?RisyZzZScHkwVzFOSCs3RG9jUFZ4eDBRNVZEYzZUZkxvbWF5Z2R3RUl0TVJt?=
 =?utf-8?B?YzNHY3FnWlY5amNxMmNIOGRkMGhOK3ltNTZzQmxibExQamFpT011WTQ2VU9P?=
 =?utf-8?B?S2oxUXQ3UEREcUV1YytIckxiWmRZZXFUVzd1ZlNTdHZ0d3VseWhMelFKckZN?=
 =?utf-8?B?RERuMmVIUXgwN2dhQklaWHhEZGI5dE9LWVBCYnJWSm5wWWJVSnovZ0NSNW9E?=
 =?utf-8?B?R3NxMENQd0RiMU1DeFg0MS9Eay8wWHdEUytCMUdxMlVjYXh6bDhsamYzczdI?=
 =?utf-8?B?Y1hGMVVvRFBvTzU2ZzF3eHVPcVBCUXZLMzVIeDd3VnFpcTdDZVlTSlhodlZP?=
 =?utf-8?B?M2ZvUk95dVF5ek84bCtVdHBmcmR3Tlo0VVhpZDlBR3VQdU8vYjQxUVB2VU43?=
 =?utf-8?B?V0YxS2l4YnFmcTlERUJjVGhHKzlHa1YrYjlyMGEzcy9zS2dFNTlvRFFtWkpt?=
 =?utf-8?B?YmxYRE4xSENSaWMwOEE2azc1c0cxbnphTURrM0pPRTJ3M1BndkhvRzFXQ0Ja?=
 =?utf-8?B?QlpMZWJLeU9NTGIxamxtT0hFMnBDc01SQU5WUE5NeDMxT3MwTUZGVGdGYVFy?=
 =?utf-8?B?QlQ3Q3N0ckpJN0lIYVhKckNpZXhKYWo1Mkg0M1ZYaW9SZUFiZmQ5SjhSVVRt?=
 =?utf-8?B?ZExlb2E3UEVOaHZleHZQRTJ0aEFOZTYzdTdkeU9sOS83RkRuT1JCaDNxOHhi?=
 =?utf-8?B?SUpnZVp0d0dxaDNDR0kxTnN2VU9teDVET2VqSUFQREhGdWpxV0E4aG45eUNy?=
 =?utf-8?B?OERTck9ZZnlFNEV1cTFhd3pTU0Rja2RtNDJmbzdHN3l4aFl3M3JUMFMyZ2Y4?=
 =?utf-8?B?SFQxK2ZqMWZNenMxSE9RM1hJcUdiY2xSTXZrbzNaQnhjZjVSK3A4eEFGbERl?=
 =?utf-8?B?M1V4c3hkbnZoWVV1TFNhektGM0lYT1Z5Z011dFBZaGxKNXVwbzNxSDluQnhn?=
 =?utf-8?B?YmRGRkx5VGkrTHRCbXVLU1ZEbWNNKzVONEhBMlo5NEdUdmxvYW50U3c5QmNi?=
 =?utf-8?B?ajkvaXFwdmszOUNpNVdMOURkdTVVNzBaTDhiTzRZcmxyMnRnWFA1WnhFN0Ni?=
 =?utf-8?B?OUlQNjRXNXBmZUVLMDRxRVR4d3IxM2Nqd3BWN0RYSTZYcXhVQ0V2OVRGTksw?=
 =?utf-8?B?UnZsaHpQTm9tQnpwSVRKb09XR05kVXZVSlFLN211cFRwNUd4cVFaV0srbDVp?=
 =?utf-8?B?ZTlmSVNUYmY1M3VMZllISGI1d1BoUnExVEJtb1hJR2VsbStic0EybE5uZjBU?=
 =?utf-8?Q?zTd9VcpN2pIJacI/29Uy2yGEG?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ca913d98-3a4a-40d2-7920-08dd922b78bc
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2025 14:35:56.8141
 (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: pmm3b4F90Yubm6Pdm+iiDVcMT9t0s8qIOWJK1OxHXcLI1R7n7gNoc/ar9qGoczRb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7138



On 13/05/2025 16:29, Oleksii Kurochko wrote:
> Now that CONFIG_DOM0LESS_BOOT has been moved to common code and is planned to
> be supported by other architectures (e.g., RISC-V), the dependency for
> CONFIG_STATIC_MEMORY needs to be updated.
> Since CONFIG_STATIC_MEMORY is currently only supported on ARM, its dependency
> should explicitly reflect that.
> 
> Signed-off-by: Oleksii Kurochko 
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Tue May 13 14:43:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:43:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.982995.1369364 (Exim 4.92)
	(envelope-from )
	id 1uEqr1-0001pI-6L; Tue, 13 May 2025 14:43:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 982995.1369364; Tue, 13 May 2025 14: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 1uEqr1-0001pB-3d; Tue, 13 May 2025 14:43:35 +0000
Received: by outflank-mailman (input) for mailman id 982995;
 Tue, 13 May 2025 14:43:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEqr0-0001p5-9Q
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:43:34 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a4295bad-3008-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 16:43:32 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ad4ce8cc3c1so202038166b.2
 for ; Tue, 13 May 2025 07:43: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
 a640c23a62f3a-ad223d5c4aasm713612666b.22.2025.05.13.07.43.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 07: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" 
X-Inumbo-ID: a4295bad-3008-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747147411; x=1747752211; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=u/VH8Ia1VezyztnVWiiugzrPcq8yF4jPa0bRsEDNr5Q=;
        b=VHUsTFIohHkk2LT/dqSYwRRPv54/PJUfW6Sll603z5aTBsm/iINkVU0sePgb4cULxB
         bI36111uqzW1MaI5dyBWFgRSf1IB6Q121nOTgjzFP4yNuZ9iuRNH/O+fJl2gQUqunjh0
         p7ls7OtIQpkzW5vQMMZy1FMOVHun4gLKT8nuVciOeQiUUyT/b52OSm+gU9goxjLvddcW
         Oieo+XuVLaPO5NGmhH6YFn86yrx5CWS/Wma1b2MbieHY/7wxmaHcZZh7a8qAbnV1fJIW
         um9w1gfNRAL8dZoMPe0QOPy70mrxk0Vtgd/tnZagnTT5fr1BUDr1sWmWs35NXEjM3jPa
         /CoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747147412; x=1747752212;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=u/VH8Ia1VezyztnVWiiugzrPcq8yF4jPa0bRsEDNr5Q=;
        b=jR/Z76mdoIDAvORo6V1PlzlT0FSQIxDnqj50LjynTGgcc2/MtAo1SPPcXfT9Yr6WZY
         jMnXuT62d5oRZXml3z5EKjdD7wrFUOuQq6BFrznN+ljKoM15It7aQWb5FGfPLwgPhQCM
         qPLah0xujaRFEiuK/j6AgRjI0iZZZe+EycZ4LPymmDT6Y4SYNHyISHPfaGpykE/Weg1c
         pq7/dt75bz+JnF2wrnUxqH2d19Xbn5DYzk6dn3DSmw0EPRyZTUZiwVFJH/ocK/m3RvDE
         L2l7tb9PcUugLGuF5dD9Lv9noYQracKw3CBvLzcorXbDWLzliPQObpRu8nEUaD84MuHV
         f4fA==
X-Forwarded-Encrypted: i=1; AJvYcCWkFGlBnPWtX/4PxHVDPSQkvvjT7qsEV8gZfr1waJZZODbHJ7gO9IY27nvRblr2su7Ap/nXnnSuc9Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx06kj4sIFhgO0IDdx8Nvx3fZrbQrm/GRzKBMA59sJpTirZSGDe
	98kSqNjWrTnQbZg9RDG7K/s59YwfTEGUA5tStuocWGhqNmnJkuYGJvw/3NF7yA==
X-Gm-Gg: ASbGnctaHT12XBhQwaCGoF2lrvOFPuANmG7ROdQZsB5Gk8aTtaJqoMHPBZLUsZZ6X1x
	FOGWU87F4YSKg1exm6dcfB2mAnXhEyyKAOw6aD6jQXJkvUDwfxA/pPLxW6pYkPtVZa2AlvhZI5X
	Lcu+oVsltj0te3rMQ2v4QsYgsHe+2oNJiG/EPnfiKyCI1Lu0bpq3ipsrVF9WBK2DEcjzfhD18NR
	SR239LIN8OQ5aDAdOumqM+qnQGtURl7/p+aPYDXeBO5GEc7J0AL8i9NtJkk1MA9UvnCowt6WMWk
	x2XANCxaWH4Jl7UZf4YP89EaDUEg5+0KLpEDPRtS8lvgOtwFLS9SV2E4ogfzBNM2XKIADGh9Wvs
	WRKDTv+OH3Eb/Hd79lkuWvMjY8SHzIK1bIeJe
X-Google-Smtp-Source: AGHT+IGr+Kj+nEGhUSeMcsjAoF4nrf2lRksH3WO1ySBoibUts3UJ5ksJRRD2X24weuq1aLJfsR9G4w==
X-Received: by 2002:a17:906:620a:b0:ad2:2d74:a1b with SMTP id a640c23a62f3a-ad22d74107dmr1282709266b.45.1747147411578;
        Tue, 13 May 2025 07:43:31 -0700 (PDT)
Message-ID: <3128bda3-d655-43ae-81a7-df61928a27aa@suse.com>
Date: Tue, 13 May 2025 16:43:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/5] public/sysctl: Clarify usage of pm_{px,cx}_stat
To: Ross Lagerwall 
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: <20250512144656.314925-1-ross.lagerwall@citrix.com>
 <20250512144656.314925-3-ross.lagerwall@citrix.com>
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250512144656.314925-3-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.05.2025 16:46, Ross Lagerwall wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -215,23 +215,51 @@ typedef struct pm_px_val pm_px_val_t;
>  DEFINE_XEN_GUEST_HANDLE(pm_px_val_t);
>  
>  struct pm_px_stat {
> -    uint8_t total;        /* total Px states */
> -    uint8_t usable;       /* usable Px states */
> -    uint8_t last;         /* last Px state */
> -    uint8_t cur;          /* current Px state */
> -    XEN_GUEST_HANDLE_64(uint64) trans_pt;   /* Px transition table */
> +    /*
> +     * IN: Number of elements in pt, number of rows/columns in trans_pt
> +     *     (PMSTAT_get_pxstat)
> +     * OUT: total Px states (PMSTAT_get_max_px, PMSTAT_get_pxstat)
> +     */
> +    uint8_t total;

The part for this field ought to go in patch 1, as already indicated there.

> +    uint8_t usable;       /* OUT: usable Px states (PMSTAT_get_pxstat) */
> +    uint8_t last;         /* OUT: last Px state (PMSTAT_get_pxstat) */
> +    uint8_t cur;          /* OUT: current Px state (PMSTAT_get_pxstat) */
> +    /*
> +     * OUT: Px transition table. This should have total * total elements.
> +     *      This will not be copied if it is smaller than the hypervisor's
> +     *      Px transition table. (PMSTAT_get_pxstat)
> +     */
> +    XEN_GUEST_HANDLE_64(uint64) trans_pt;
> +    /* OUT: This should have total elements (PMSTAT_get_pxstat) */
>      XEN_GUEST_HANDLE_64(pm_px_val_t) pt;

As also indicated there, the same constraint as for trans_pt applies to this
output buffer, just that it's having only one dimension.

>  };
>  
>  struct pm_cx_stat {
> -    uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
> -    uint32_t last;  /* last Cx state */
> -    uint64_aligned_t idle_time;                 /* idle time from boot */
> -    XEN_GUEST_HANDLE_64(uint64) triggers;    /* Cx trigger counts */
> -    XEN_GUEST_HANDLE_64(uint64) residencies; /* Cx residencies */
> -    uint32_t nr_pc;                          /* entry nr in pc[] */
> -    uint32_t nr_cc;                          /* entry nr in cc[] */
>      /*
> +     * IN:  Number of elements in triggers, residencies (PMSTAT_get_cxstat)
> +     * OUT: entry nr in triggers & residencies, including C0
> +     *      (PMSTAT_get_cxstat, PMSTAT_get_max_cx)
> +     */
> +    uint32_t nr;
> +    uint32_t last;  /* OUT: last Cx state (PMSTAT_get_cxstat) */
> +    /* OUT: idle time from boot (PMSTAT_get_cxstat)*/
> +    uint64_aligned_t idle_time;
> +    /* OUT: Cx trigger counts, nr elements (PMSTAT_get_cxstat) */
> +    XEN_GUEST_HANDLE_64(uint64) triggers;
> +    /* OUT: Cx residencies, nr elements (PMSTAT_get_cxstat) */
> +    XEN_GUEST_HANDLE_64(uint64) residencies;
> +    /*
> +     * IN: entry nr in pc[] (PMSTAT_get_cxstat)
> +     * OUT: Index of highest non-zero entry set in pc[] (PMSTAT_get_cxstat)
> +     */
> +    uint32_t nr_pc;
> +    /*
> +     * IN: entry nr in cc[] (PMSTAT_get_cxstat)
> +     * OUT: Index of highest non-zero entry set in cc[] (PMSTAT_get_cxstat)
> +     */

For both of these, it's not "highest non-zero" but, according to ...

> +    uint32_t nr_cc;
> +    /*
> +     * OUT: (PMSTAT_get_cxstat)
>       * These two arrays may (and generally will) have unused slots; slots not
>       * having a corresponding hardware register will not be written by the
>       * hypervisor. It is therefore up to the caller to put a suitable sentinel

... this comment, "highest written by hypervisor". They're also not "index of",
but "one higher than the index of" (i.e. counts, not indexes).

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 14:44:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:44:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983002.1369375 (Exim 4.92)
	(envelope-from )
	id 1uEqri-0002In-ER; Tue, 13 May 2025 14:44:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983002.1369375; Tue, 13 May 2025 14:44: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 1uEqri-0002Ig-BQ; Tue, 13 May 2025 14:44:18 +0000
Received: by outflank-mailman (input) for mailman id 983002;
 Tue, 13 May 2025 14:44:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEqrh-000280-6z
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:44:17 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on20609.outbound.protection.outlook.com
 [2a01:111:f403:2614::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id be7ac4e4-3008-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 16:44:16 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DBBPR03MB10343.eurprd03.prod.outlook.com
 (2603:10a6:10:53b::13) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.27; Tue, 13 May
 2025 14:44:14 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8722.027; Tue, 13 May 2025
 14:44: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" 
X-Inumbo-ID: be7ac4e4-3008-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HTvwUvzlv74lvGYoV139le4+snn0Og8kOdo0oOB39TP4vXS2l4BbLerJ6ax4gCXqkcbiuqPq4qc2PhGjpT3+xAPueVa94cmRdihFQFu/dl2+wKwLMcm73GUuxyY055swN8BmzFVxgD3yRkm5apiY5lJvjTRDylNykjPedgkTbTcAI8edkSgSB4Jz3zufhf132AypAXFYqlhDlROO7srejM/HOWLhspBiogGLhO0iNJ3OY4rSJZA7ZzANqXEPk9Eh1Wqd4wAkpsQZicqA2nH4c4PqeCHVfCQJne1fq6Dr7EHmHSJpSyVOTAA3aKxi2EYiT5hu7FTV3lGaYkP8XShNpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XvsUbw6ZWIkiwoWdJV8DBzxgo1doyQWkVTwGoW/fpWo=;
 b=qs32OIO7yJ1Q1rAstxKtqusE/RWc8kv+132lIK4bWvpGsk54FZ312zkxZSwXiDiBO69YI32saqzV+QjR0GitO2GHNe1NTp8XfyPJ19mmSDfVPZTaizQW0t5KYwjnVofp7HRQhQXzxWGv+Al+Io3/TLgjVE87csNZqyi83LuUvi7+EB2i3bz8m9baQS1zy2cLT9ZZP4B1IjGeYc06uI/J4Amj8yDpnzsyR4YwafyIlnla1JDxuP6GYRXx4aRdlIjoElsp1ujw0oMzq3tZs2EmKLanVY7fCUpiNbkZFdoSBA8UcbdXxmPIfBRTuks3cVr6VkQg5HXsqJUyHdggbPSWHQ==
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=XvsUbw6ZWIkiwoWdJV8DBzxgo1doyQWkVTwGoW/fpWo=;
 b=uO6pxWqSHANrOkX2dbrqrwoTTgAzocgNhzNnoC2ZPt6kLRQD81mI8r/rtG0+mL4wY0ftaouSrMgmgzb3qjY0UPP1097vHB+OJUhz+j9AsE2T4NHXjcxlCY3a/jv4vhebF7zf9on1q0IJ6mIUKwlRNhKVaXcBuw/53sIR0cBuJ2ybRd6ZJUIrlFBlRiNYztYQsuTec9JDFPb4ae9GK/RuazaZry0AOLhWVWwO5ww6+Wi+AT/i+kdHt5Nrvb2oc8hiFkHGEezoc7yGf+jpriVkFeveoPAtcVjoJmM7q8wsfqmWhwaOGxOk0+JZQUhsz8thVCdlCnstOvDgE6BdVOwePw==
From: Mykyta Poturai 
To: Stewart Hildebrand ,
	"xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk 
Subject: Re: [PATCH v4 4/4] xen/arm: add support for R-Car Gen4 PCI host
 controller
Thread-Topic: [PATCH v4 4/4] xen/arm: add support for R-Car Gen4 PCI host
 controller
Thread-Index: AQHbtD/+f1IljlTzAkG+gkmGFEbJELOzM/oAgB2OgoA=
Date: Tue, 13 May 2025 14:44:13 +0000
Message-ID: <834e50d5-977f-4a41-9184-06605c8de191@epam.com>
References: 
 <98c8e00a77800e8b1163ab1efa9a60f1bced0fb9.1745402473.git.mykyta_poturai@epam.com>
 <3d2555d7-83c0-438d-8d61-ac622a662384@amd.com>
In-Reply-To: <3d2555d7-83c0-438d-8d61-ac622a662384@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|DBBPR03MB10343:EE_
x-ms-office365-filtering-correlation-id: 892d7d1d-a56c-44dd-f174-08dd922ca146
x-ld-processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?c1lBZGQ2cWt3M3NYVVR6MEJYOTJDdVFOS3hhalJvL0s2c1phQ1c0M0xKRWhX?=
 =?utf-8?B?K3dteGNJcnVvMTZsaHV6UE1YdndTNzlFUHV4LzZhNUFSVkhxZXE4bW56MmRH?=
 =?utf-8?B?aDZOZG4vbFY4eUFwR3BEaElKc3N3NnlqdGlUT3JheEpwazZERmFqdzkxaWNW?=
 =?utf-8?B?TWo5ZHErT1Q3RzNNZ3ZuSXV5RWVGUjdwQ2NjWGFCazlPU3puWmU1SFhBOGpO?=
 =?utf-8?B?cmpwQTN0R2hwdzRkMEh6bE51aUhCSXk2ZVFLQUQ3QVJuemZqV0c1Yy9zT3RL?=
 =?utf-8?B?VjBVN241azR3QlljN29HMlU1NlBQSlNLK1FBNUdMUDhZNlN1TytJNjNJL25K?=
 =?utf-8?B?VklZaDVOOXlPV2JDWWxmM3kxVVF0SXBsV0VkUVlKc1g3NUZpaHZQUmJiZFE4?=
 =?utf-8?B?SGR5WVZtdEl3Vi94aUxrdlNUNjVnN1M1L2dzN21Od2U0MEF1ZXJYNnUzLyti?=
 =?utf-8?B?aVpaL0xweXRwR2NNbE5yNlhiS2RTL3B1V1hvdUtiMlp0RXZYb3FVSDBRN1lD?=
 =?utf-8?B?RzhLV1lwSHNKeUlqYXVIY1NHL2NLSzBJbWgzTFNTRGJGc2F5R0dJYTVOMU9L?=
 =?utf-8?B?SGdDbEpLN1ZXSXdZS2lXNFdnODJvZFMwc0lvUmFvdStBQmgzVFZsckJ3OGZM?=
 =?utf-8?B?am9Oc2dJUlVYbTV2U29XMU8yQ3pvZys5T21IZUJIbjBoNjlHNisxN2FvV0dp?=
 =?utf-8?B?UFYySFhzOHFoeXlocmxCekVFekNHY0QyaTk5UmFEcDZleGhvUVpMdE1nN0lT?=
 =?utf-8?B?SHBwZ0Y1RVQxM3ExR3NuQWNqZ0o4RXNISytVZmphbEtRKzVnUGwxd0RMVzlO?=
 =?utf-8?B?TlBibmJMRXJIZFdnRXBzY2crenJCbmNsdGw0SDBubmxtaEZPYVhvSWFuWVY4?=
 =?utf-8?B?Nm9NZVNlN25FM0orTnovUk90VjQ0ak9EYis4TDRiT2Y0RmZ4TVNpZmdvbEpK?=
 =?utf-8?B?YXMycXVELzZQQTdiZUxCekp2b3Nza0VsRFJzWWpTbUE1UVFkbzN4dzVmS09r?=
 =?utf-8?B?QmlHVHFZaW8yaXE3TmovSnFqbkkwMy8wTG1DY2FuSWtsN1ZEaWV3a0d2TTd6?=
 =?utf-8?B?ZUdKUnN1NkkvU0lCRnF2NkErZ3BCbmducHRCamRMOTg5ajB3N08yNjg4Y3V2?=
 =?utf-8?B?bm45UU1GOVRBdE5rZ092K2l6U3dTTnhLRUZobmpHS1h0Q2NSNXlIb3Z1c1ZI?=
 =?utf-8?B?VWdqZ0txYUxrK1lMeDhDSHR4cEZ3N0RESjNUL1ZORWtvMWlwdU1PNEx2Q0hr?=
 =?utf-8?B?bjBaMEJEdkhkVFcwaWhwQkVUdDZkdFRla0Q2WVpaaUhEUFI3R2h4OG1vdlpX?=
 =?utf-8?B?RHJYeUlKVHJldng5SkIvVVQ0SGsvWWJnVHlkNmlFSU5KVEJDS0RYeENqczlG?=
 =?utf-8?B?L1BPRU9tOWc3SGlGWi95LzBveVlUZ3B0MWRtSWFTL0pqU1RacHVzU3U3a0N2?=
 =?utf-8?B?YzhOUEQrVWRvWkNpQkttWFQwRjluT0tSOEZicm5OSG81Y2Vqay81SENUMXBl?=
 =?utf-8?B?NVRvblFkcjB4SVNMTHVEUFB0b0VaODYyTXE5MWNUV0lKSXZBU0NrOWtWUVQ0?=
 =?utf-8?B?dS8za0l3U2NIbkpxZ2pjQkJTVUVUZmVqSWttN3kvQlB2UTJJSEh2bzMxZXNO?=
 =?utf-8?B?THJBYytqZ3lVbVBRU0ZTcU9ZdE5SYlVuNklnSnkyZkQ0eW9NemFjR1VZWU1j?=
 =?utf-8?B?aTNmYmFuWldtb3pMTDBPU3BrVWxjY2ZtT1I1cXJJZVNkeU43T1F4MU5aZDM1?=
 =?utf-8?B?dHRCY2d1akFMQ2k3NHdvRExpZHk1RHVmaGxNM2NVdHVWVkwvbFJQWS8wM05j?=
 =?utf-8?B?K25YeU9jT25RbzVXMm9RZTlacU96UTNmSWpqZUZpY2RTR2lIdGdsUnV0OHAw?=
 =?utf-8?B?aU4wa1lhNEM0RGhHS05SM2kxaVcrdTZWVUZWeDZiLzdDZHVkZERGK01VTWVB?=
 =?utf-8?B?TjN4dVBkT2p3WHlCNXVaUEpBRUpDcHVqTUwvWmMyNldoSTdPbDZwREV0Y3E5?=
 =?utf-8?B?S24zeEhlbVRnPT0=?=
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)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?M2RlVlZzQ2lHN3I5SlFZM2JDUmUrVU91QkoyaVc5bHJxRERQbXdCZ3RjYXRG?=
 =?utf-8?B?VFNBNkxsSFhaMVZDTjNZbnllajZHdjZVSFhaZHJhczdNcEJUS1RpVVpwbFE3?=
 =?utf-8?B?Q0FuZDdDd0hybzRXREZsRThWZWhzejFvZEdqMmM3eXlvd2tZbUMyVTlZSWtG?=
 =?utf-8?B?NHVzaFBNSFg2ZGcwZHJEbldYM0VRQWg3bGlvKzJXU1lLcDlTbDZFak9vME1H?=
 =?utf-8?B?eDl3UXlWZUU3c0NBRnpVK1E5MVVqR2xMd2ZOL05NTWVUSVowd0h5bXBXWnFW?=
 =?utf-8?B?TmM3R3lHcm00QWlDTXBqYWxNb0NZb294cDFIOGxhTnVodWR1cVBSUExPVFdv?=
 =?utf-8?B?TW9tWmgvNTZuMjBSaXY2dG9ITUpOMERMKzM3cDliN1BhSEQ2WlJOdExqNzla?=
 =?utf-8?B?OGZjaG1YMmdleDdNSVZURHgxSkxoSDZyWUZDMnRIRlM4UmxpOFVnZEZtbGFS?=
 =?utf-8?B?K3F4Tmowell0dzNudTc1Tk90MTl6dHN1aitrOXJCbFJuR1ZJWjBvdWJpN0FP?=
 =?utf-8?B?eExhcCtFY21VYlZ4d0NOdDhDZFdGTm5tc2VITmloSG9naVJKbGVnOGlETUsw?=
 =?utf-8?B?eG5TM0liREdqY28xQktsVjFDWEpYUThyc0NIUHVDMzY1c0VZeHh0Y3JNWm83?=
 =?utf-8?B?bThXQ1ZYMFVCdWpja2lSRHVkaFVIQ3lZdGxRUWhlNGs0VWZUaDV3ZERHWFlG?=
 =?utf-8?B?a1grZUhEeDNmVnRGeFZDd1lmVjBkOGI2b3NYT2RTTUtkTmw0M0EycXpYNFJW?=
 =?utf-8?B?RE5ZU0V4TTF5Q3lMWXJ3ZTA1WGR3eHpLL1dVdm9XdzhzZ1VSZ3orckwrZ3hs?=
 =?utf-8?B?U1NWeU4wa2lPalMwb3NKSUJPbjhVSkFFZnFZVytndXdwV0xOcTkzcTYzRXV2?=
 =?utf-8?B?cXBHZHNmL2FiZzFTL0lxdEdEdW1CSUNwSkZCTGo5cFpuMDluK2MvVkhiUWpo?=
 =?utf-8?B?Z3h6WmFLd2ZIamdsRklhZzE3QTM4OUJzQ05HT3JVNjhCaDMzaFBOU2NUSFg2?=
 =?utf-8?B?bS9HSlJKL1NmTi8vck1KY0QrVnJWUUpneWJCOUNoSTZNYmp3cnNLbzVUSnhm?=
 =?utf-8?B?K3IxclBGeDBmYWY5SmV4OEN1UDIzNzdWU1p2SUhvMzlpSFNJZlkzRTdEMDZO?=
 =?utf-8?B?eXgyK3Byc005UDNyS25weHZ6U2wvekZLOHJNM01nRDl4RjN4UjJvV0grNWRM?=
 =?utf-8?B?K1BPaCsxeXJQd0tPUFFRVFV5bHo0M2lHNVp2QmRsU1hGcHZ3aTJwOWVqWEVS?=
 =?utf-8?B?cmozZERtRjVZN21ra25wR04zM1l1WFJHbDFuQWZGWEZJVURsTi9qZktMY2Y1?=
 =?utf-8?B?MnRJWTZOMm5BQXpnVjMvZTB4QlVyWDUzODlNSlBqUFhLK3NiNm5La25NOE1S?=
 =?utf-8?B?L1htVUJhNW5WSVltL0JHL2VoTHNrR2FzbGh3aTlNSWFKN1Q5MlFtSWcwdVhn?=
 =?utf-8?B?K3djQmh0NFM0N3J5UGpiays5RzRJbkNENmYyMm1tYmpjNDhJWFFnTDRBaTE1?=
 =?utf-8?B?c09mYnJ2QkRzWkNVNFJKdmliamVyUGdjU3I4MVNCQ1RWRzN4QzUwWGpGSUFm?=
 =?utf-8?B?c2lDekNvR21EKzVqSzdFUnp5elBXc01vTmo1bTZQN0p2OVJpNm5SYmh0ZnBK?=
 =?utf-8?B?K2p6VzluOFIwWkIyUmZvbHRNK2RLKzBMK0ZEbURlTkxGR0RYVU0wOVVISlJt?=
 =?utf-8?B?ak5abjEvOWwzUHIvYzdsZ3pwYkZYMmZ4bnZFMWFrU3FtUnBzb3VyOXllWkNH?=
 =?utf-8?B?VE94ZGNraE5xZFpYZENYNW5CbEliOXFUN2NkV3JHcjUrazBqc3l5eDFKckE2?=
 =?utf-8?B?VWZic3VyMjdtZVBYSExxTEpCajN0S1puSjRmTE52OTRhNDFPaDdQQ1JRdENP?=
 =?utf-8?B?OENXajBuRmt2OEhjNmJMS2VwaFRHTE9mUTdwbzZhZ0kxYUM0eklqblY3VXhL?=
 =?utf-8?B?aEdWaWF5cWw4elBBY21kSTlkNXNmWmM3d2o3QTJFSERyZHJzSlFmenloRFVR?=
 =?utf-8?B?TmZvaGJyTXVWZG9EODJZYUYwc2hXWVlJMDJJTDRsQ1JTamVKSGdOWmhpQWRh?=
 =?utf-8?B?dWhQSllncmFramZBRFZKVitVeGp0K0x1TGZpWm8zK3FvNm1LZ1lNVlNYUTgr?=
 =?utf-8?B?Y1k4am1WQTBQNTRvMlNwdE5oWVFUSnc2N0VhUFpsZ3dac0tHRjJwY0hGQnp5?=
 =?utf-8?B?MUE9PQ==?=
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: 892d7d1d-a56c-44dd-f174-08dd922ca146
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2025 14:44:13.8280
 (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: SMpelzSrli6ZecAWcJybSi9G/WuhsEvE2uMH04WJ4AhJLzhpOwlYRwjK8VB83yArKwdayeoPrifGGH9YWlHiUg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB10343

T24gMjQuMDQuMjUgMjI6MjIsIFN0ZXdhcnQgSGlsZGVicmFuZCB3cm90ZToNCj4gT24gNC8yMy8y
NSAwNzowOCwgTXlreXRhIFBvdHVyYWkgd3JvdGU6DQo+PiBGcm9tOiBPbGVrc2FuZHIgQW5kcnVz
aGNoZW5rbyA8b2xla3NhbmRyX2FuZHJ1c2hjaGVua29AZXBhbS5jb20+DQo+Pg0KPj4gQWRkIHN1
cHBvcnQgZm9yIFJlbmVzYXMgUi1DYXIgR2VuNCBQQ0kgaG9zdCBjb250cm9sbGVyLCBzcGVjaWZp
Y2FsbHkNCj4+IHRhcmdldGluZyB0aGUgUzQgYW5kIFY0SCBTb0NzLiBUaGUgaW1wbGVtZW50YXRp
b24gaW5jbHVkZXMgY29uZmlndXJhdGlvbg0KPj4gcmVhZC93cml0ZSBvcGVyYXRpb25zIGZvciBi
b3RoIHJvb3QgYW5kIGNoaWxkIGJ1c2VzLiBGb3IgYWNjZXNzaW5nIHRoZQ0KPj4gY2hpbGQgYnVz
LCBpQVRVIGlzIHVzZWQgZm9yIGFkZHJlc3MgdHJhbnNsYXRpb24uDQo+IA0KPiBJbiBhIHN5c3Rl
bSB3aXRoIGRvbTAsIEkgYXNzdW1lIGRvbTAgcHJvZ3JhbXMgdGhlIGlBVFUsIGFuZCB3b3VsZCBk
byBzbw0KPiBiZWZvcmUgaXNzdWluZyBhbnkgUEhZU0RFVk9QX3BjaV9kZXZpY2VfYWRkIGh5cGVy
Y2FsbHMgb3IgUENJIGNvbmZpZw0KPiBzcGFjZSBhY2Nlc3Nlcy4gSXMgdGhhdCBhIGNvcnJlY3Qg
YXNzdW1wdGlvbj8gSWYgc28sIHdoYXQgaXMgdGhlIHVzZQ0KPiBjYXNlIGZvciBpQVRVIGluaXRp
YWxpemF0aW9uIGluIFhlbj8gRS5nLiBpcyBpdCB0byBndWFyZCBhZ2FpbnN0IGENCj4gbWlzY29u
ZmlndXJlZCBvciBicm9rZW4gZG9tMD8gRG8gZGlmZmVyZW50IGlBVFUgc2V0dGluZ3MgbmVlZCB0
byBiZQ0KPiBhcHBsaWVkIHdoZW4gcnVubmluZyBhcyBhIFhlbiBndWVzdCB2cyBub3Q/DQoNCmRv
bTAgY2FuIHByb2dyYW0gaUFUVSwgYnV0IGZvciBndWVzdHMsIHRoZSBwcm9ncmFtbWluZyBzaG91
bGQgYmUgZG9uZSBieSANClhlbi4NCg0KPiBGdXJ0aGVyLCBpcyB0aGlzIGRyaXZlciBzdWZmaWNp
ZW50IHRvIGluaXRpYWxpemUgdGhlIFBDSSBjb250cm9sbGVyDQo+IHdpdGhvdXQgZG9tMCBpbnZv
bHZlbWVudCAoZS5nLiB0byBlbmFibGUgZG9tMGxlc3MgUENJIHBhc3N0aHJvdWdoKT8NCg0KSW4g
dGhlIGN1cnJlbnQgc3RhdGUgbm8uIFdlIGFyZSBwbGFubmluZyB0byBhZGQgc3VwcG9ydCBmb3Ig
aXQgaW4gdGhlIA0KZnV0dXJlIHRvZ2V0aGVyIHdpdGggWGVuIGRldmljZSBlbnVtZXJhdGlvbiBi
dXQgaXQgd291bGQgYWxzbyByZXF1aXJlIA0KY2hhbmdlcyB0byB0aGUgYm9vdGxvYWRlcnMgdG8g
ZGVhbCB3aXRoIHRoZSBpbml0aWFsIGhvc3QgY29udHJvbGxlciANCnNldHVwIChjbG9ja3MsIHJl
c2V0cywgcGluY29udHJvbCwgZXRjKS4NCg0KPiBUaGVzZSB3b3VsZCBhbGwgYmUgdmFsaWQgdXNl
IGNhc2VzIElNTywgYnV0IEkgd291bGQganVzdCBsaWtlIHRvDQo+IHVuZGVyc3RhbmQgdGhlIHJh
dGlvbmFsZS4NCj4gDQo+IA0KPiBkd19wY2llX2NoaWxkX3ttYXBfYnVzLGNvbmZpZ19yZWFkLGNv
bmZpZ193cml0ZX0sIGFuZCB0aHVzDQo+IGR3X3BjaWVfcHJvZ19vdXRib3VuZF9hdHV7X3Vucm9s
bH0sIHdvdWxkIHBvdGVudGlhbGx5IGJlIGNhbGxlZCBvbiBldmVyeQ0KPiBndWVzdCBQQ0kgYWNj
ZXNzLCB3aGVyZSB0aGUgZC0+cGNpX2xvY2sgbWF5IGJlIGhlbGQuIEl0IGRvZXNuJ3Qgc2VlbQ0K
PiBhcHByb3ByaWF0ZSB0byBoYXZlIGEgYnVzeS13YWl0IHN1Y2ggYXMgdGhpcyBpbiB0aGF0IGNv
ZGUgcGF0aC4NCj4gDQo+IElmIHRoZSBidXN5LXdhaXQgaXMgbmVjZXNzYXJ5LCB0aGVuIHBlcmhh
cHMgaUFUVSBjb25maWd1cmF0aW9uIHNob3VsZA0KPiBoYXBwZW4gZHVyaW5nIGluaXQvcHJvYmUg
KGFzIHlvdXIgRklYTUUgbm90ZSBiZWxvdyBzdWdnZXN0cyksIG5vdCBhcyBhDQo+IGNvbnNlcXVl
bmNlIG9mIGd1ZXN0IFBDSSBhY2Nlc3MuDQo+IA0KPiBTYW1lIGNvbW1lbnQgYXBwbGllcyBiZWxv
dy4NCj4gDQo+IA0KPiBEb2VzIGlBVFUgY29uZmlndXJhdGlvbiByZWFsbHkgbmVlZCB0byBoYXBw
ZW4gb24gZXZlcnkgZ3Vlc3QgUENJIGFjY2Vzcz8NCg0KSXQgaXMgcG9zc2libGUgdG8gaW1wbGVt
ZW50IHNtYXJ0ZXIgYWxsb2NhdGlvbiBvZiBpQVRVIHdpbmRvd3MsIGJ1dCBpdCANCndvdWxkIHJl
cXVpcmUgYXQgbGVhc3QgYSBmdWxsIGNvbnRyb2wgb3ZlciB0aGUgUENJIGhvc3QuIEZvciBub3cg
d2UgYXJlIA0KZG9pbmcgdGhlIHNhbWUgYXBwcm9hY2ggYXMgaW4gTGludXgsIG9mIHVzaW5nIHdp
bmRvdyAwIGZvciBkeW5hbWljIA0KY29uZmlnIHNwYWNlIGFjY2VzcyBhbmQgdGhlIHJlc3QgZm9y
IHN0YXRpYyBtYXBwaW5ncyhjb25maWd1cmVkIGJ5IA0KZG9tMCkuIEJ1dCBvdmVyYWxsIHRoZXJl
IHdpbGwgYWx3YXlzIGJlIGEgbmVlZCBmb3Igc29tZSBkeW5hbWljIA0KY29uZmlndXJhdGlvbiBi
ZWNhdXNlIHRoZXJlIGNhbiBiZSBtb3JlIGRldmljZXMgdGhhbiBmcmVlIEFUVSB3aW5kb3dzLg0K
DQpJbiBwcmFjdGljZSB3aXRoIGFsbCBvZiB0aGUgaGFyZHdhcmUgd2UgdGVzdGVkIG9uIHRoZSBB
VFUgYWx3YXlzIA0KY29uZmlndXJlZCBpbiBvbmUgcGFzcyBvZiB0aGUgd2FpdCBsb29wLCBhbmQg
dGhlIGNvbmZpZyBzcGFjZSBhY2Nlc3NlcyANCmFyZSBub3QgdGhhdCBmcmVxdWVudCBzbyBpdCBz
aG91bGRuJ3QgaGF2ZSBhIGJpZyBpbXBhY3Qgb24gcGVyZm9ybWFuY2UuDQoNCj4+ICsNCj4+ICsg
ICAgLyoNCj4+ICsgICAgICogRklYTUU6IHdlIGNhbm5vdCByZWFkIGlBVFUgdW5yb2xsIGVuYWJs
ZSBub3cgYXMgdGhlIGhvc3QgYnJpZGdlJ3MNCj4+ICsgICAgICogSFcgaXMgbm90IHlldCBpbml0
aWFsaXplZCBieSBEb21haW4tMDogbGVhdmUgaXQgZm9yIGxhdGVyLg0KPj4gKyAgICAgKi8NCj4g
DQo+IElzIHRoZXJlIGEgcGxhbiB0byBhZGRyZXNzIHRoaXM/DQo+IA0KDQpXZSB3aWxsIG5lZWQg
dG8gYWRkcmVzcyB0aGlzIHRvIGVuYWJsZSBQQ0kgc2NhbiBieSBYZW4uDQoNCg0KLS0gDQpNeWt5
dGE=


From xen-devel-bounces@lists.xenproject.org Tue May 13 14:46:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:46:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983015.1369385 (Exim 4.92)
	(envelope-from )
	id 1uEqtX-0002wX-Sl; Tue, 13 May 2025 14:46:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983015.1369385; Tue, 13 May 2025 14:46: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 1uEqtX-0002wQ-Ou; Tue, 13 May 2025 14:46:11 +0000
Received: by outflank-mailman (input) for mailman id 983015;
 Tue, 13 May 2025 14:46:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEqtW-0002uf-4n
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:46:10 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2062e.outbound.protection.outlook.com
 [2a01:111:f403:200a::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fff83897-3008-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 16:46:07 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SN7PR12MB6930.namprd12.prod.outlook.com (2603:10b6:806:262::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.29; Tue, 13 May
 2025 14:46:02 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8722.027; Tue, 13 May 2025
 14:46: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" 
X-Inumbo-ID: fff83897-3008-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=edqnZ3MY/MBBtbR6XTurTeuMhN+6N3QJu/80QSyp1FAwrpLZgqIDMWvoQM76R0xiqPR8Dw3G7x2tLXO4J66+TsAWn/B3dLKW+2vLQsEqA1Max04JCa2RWLmGqmVuc5WDsnhDA66zlIxCPy/RlzauXl6dN2NuYIzQajhAAa1BgJKMU30WPfhaALbO2rOqiowcF6UxzjVc7bulqJ6FqZmpFgi1AlsPY21csXTfTa7/wgqlfHUYZqwd8cd8TGLYGfVTdfXY2GIMGlb0dwV4N0wgoBL00ZUrfpgvPdaus4FRi8AskNXeDAhbwHObGdWTTnljiDcmjfh/8QfcSZNpmk/hYg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ed5VZ817fd+x83PGoGdBckLlmamInLqMfiGZajgcKBo=;
 b=F/WX62OSPqdZKo45JleFRE7jHsM7/jXWuMNGY07J+f+uj40LGXqj9vfvBZZHxXG3rlzbmwgNIH8WOrU+/zgyX27wkJ+cIf0jB2e0eb+RtSWgA6u7DXqRYSApjisVt4KBTuKRb92MbzAPKeIXs33M9MuOv61auv9U/sfZEIFPRfb0IsQtTi8swU2LkOej84eVpDrP1De4pDCco7Jh58zMw6GIGhy7/aWFdxBtuSHAI/7K7C5BSdLEOUrnklfxRQx+QIs21FxM0ouiO2H2xuHpb+DwB6frZFOuj9Ep0CrT52j2pUhaAn4sVIECyP49lbSPz8PXyl8308JJ08mzkSCnUg==
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=ed5VZ817fd+x83PGoGdBckLlmamInLqMfiGZajgcKBo=;
 b=tN4bMkoco29rTz+eZV1jhK/V3AyBey1GznLNYuc4Ag2t6ydaI6BPMvUhzxAVPkH3VFXECNTFj5MbYywJbb3dop2tdiMq0OiF9C3tabIFmfRXmYh+otTRs8+ZVYqzsGKom0gl3ZoatEMXOJtxSbz0FhH8Np+iydEQSYlJ9D5kTGc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Tue, 13 May 2025 16:45:57 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/3] xen/dom0less: move make_chosen_node() to common
 code
To: Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: 
 <9c87738225d48bd1ee9bba6e8d4e018dfecabccd.1747145897.git.oleksii.kurochko@gmail.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <9c87738225d48bd1ee9bba6e8d4e018dfecabccd.1747145897.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0160.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:99::9) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SN7PR12MB6930:EE_
X-MS-Office365-Filtering-Correlation-Id: 5560dc0e-dd42-4102-14b7-08dd922ce1bc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?THlMazVlZzVrbndsRWFaOW9XWUJQMlF4U3ByQ2d2NVRrTEpGSlh4RUJsNFY2?=
 =?utf-8?B?ellydTlRRkEyTlNQeTNFVHlMUG9ZZGN2dGF1VWZRd05ISWVweWVsWFMybzI5?=
 =?utf-8?B?RGJyT25MRnpDcThkQktBczJCZlFFWmFPUU9KNEkyZXcvSnhvVWw1MDlXWUxJ?=
 =?utf-8?B?TEY4NnVuSGVUYm5oU25zMEFGellheUpFdDl6N2dLcWtNZ3JBaE1LNmxOMDlK?=
 =?utf-8?B?a1FFSVpzc3hsa054OXkvTmtTclJTY1EvbXNSUXd2VXJDVzU2aVEveCt4cDFS?=
 =?utf-8?B?Mnp1Vk9TTnkzTERtaFVMWDk0Q2VtSHV5NGEvTWNTRDg2QytLZkxhcXo2dnR4?=
 =?utf-8?B?alZWVEpPTEdyZkhCSzhKdUE1Z0JZcDdWVVhDdmIvTFdZS0hFNmxEYWxXRVh6?=
 =?utf-8?B?SEZDSjJwbHNvVFBRbUg0ZVNiODhqQXJaTGZmWHNHZmRmd1JxU0NHRzQyeWdF?=
 =?utf-8?B?VGlEVU81Y3o4VmhYWmZWTWw3czdVZllBZFg1L2ZHelkvcHk3Q01ldXZEc1BT?=
 =?utf-8?B?M2U5Z0d6TndCQURidW90RndhUFFnZjlnbXY0ME1Zbm80WEYydlQ0MkdBZVAv?=
 =?utf-8?B?Y0VIUktlOTlKZG5MTUpib0laUGphWmFjNTQ2dDRwWTdYNHV4S2R5NGh1VnNu?=
 =?utf-8?B?eEx6TS9ZbmZlQklrYjFhdmExK1ZtY1NCbEZDaVlETXhVQTZUNllERXpIU1Vl?=
 =?utf-8?B?Qlpsa2Z0R3ZUbEdCdU1XdWlYc3IvRlg3WURRTGVIbTZmZUl6YXdjdG44ZlY0?=
 =?utf-8?B?SXRGdXUvSUpSQVJTOEgzZjRvT0hqb0I5RVd3aFZoVFBJSCt3dldrbFAxYW1C?=
 =?utf-8?B?RU03ZllEdDAxVTdkU1VtVnRFWDljWUtCRU9HYkxJd2FEdVkveUtGbjJxZkNx?=
 =?utf-8?B?YzhMSy9uSEZKR0J4ZmdmcFRoZnByS3FrUmF6Z0FKMGw2Y3FlaHBoTkpUUnA0?=
 =?utf-8?B?VVJnL3dVRkUxeXl3bDBwbXlyaFVWY3RGR1ZkK1d6Zy9wRmw4cDVVYWRvSENJ?=
 =?utf-8?B?MThLUHNvNGFBSWhGRzF5Qk1CaDBCQ0p0VjVaUTh6bitGZHFBcFF5ZTc5TzJa?=
 =?utf-8?B?QUFwMnlYZ3o4OUcxbmFGYlJNUEpna0dvWE9pU3EycUpRTW0rSTR0M2JKOEND?=
 =?utf-8?B?K3plUGMwcEFlUWw3RCswWmFSYk8vcHBSRXZrVkFkbWdEbUNMbnJHK1Q1dmJt?=
 =?utf-8?B?ZVJWalFIY29sUmtqUnBDSkljY1Z6bjRIMktUZitSZkIrZ3BjazVqR3FwL0JR?=
 =?utf-8?B?LytZQURVRzVUeFpKakpnYlEyYXoxSTB2aEpxREl1ZW1PMXl1Q0xwMktWVkxa?=
 =?utf-8?B?ZTdZL245cTNXdlphWmpHWVl4R05sdTN5MTRkOWtzdjN3M2JTNDJWUVJldW9q?=
 =?utf-8?B?eEw0Qy9uUlRRMjl0SzBJYk9hQWhpOEVpTUliUm9xS2xPV2M4L0xXZkVCRU1M?=
 =?utf-8?B?eEIxa3hWUnJEeitBZTFQaEVDU1lJMGc0MVFIUWxBUXJnUyt2VElvelJ2QjZP?=
 =?utf-8?B?Z3M1WFMvdk1vM0ZFUWlzSVBZbjhIM0RjQzB4T3dhOEdkM3RsOWpmaFhhVThL?=
 =?utf-8?B?V1UwU1FCUTlydy82TEpZamRPb0x2RHgrZzBEWGc2a3hKNW5wN0QxNDN5Y0RS?=
 =?utf-8?B?RDVXeGd5cG9TSjBFbnVXQlFvOU9xMlZGbDRDUXZwOGNrRXMrbG9IWVFwejlR?=
 =?utf-8?B?WE4rYUpQblk5akM4dFl2N2hSMElCY3RzamlHK0RIVFFFSmQrZ0Z5bjlCbnRR?=
 =?utf-8?B?NWlQcXYzWFJzVFhTUmxhdHlWc0NtM0hKbnJkWmVRVm1DVkhFTHJ5cXk4RW4v?=
 =?utf-8?B?bCtKd3VOejJUS2IxYktCQkpWUHBhMVZtWFBwZUZySXJ1VEZZL2U4MTBMdmc4?=
 =?utf-8?B?RFBmL2gvL3A2c21hdk5kOURtbGdLbmlEdGx6TThDUzNYRzMxZ2ZMMDdLM1ZE?=
 =?utf-8?Q?phEWmPhRSC8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZVNad3NiZkQvZXU2Mkg3azB0NmVjYXRycC8rTHErZUQwSCtoaG9NYWN3dFRH?=
 =?utf-8?B?QXRWZm5QcXJMci84cVdoRE5ZU2RTQkhEOXpSV09XdjFsd0tlcGJWcndOUGlq?=
 =?utf-8?B?SmJ5UFd2NGxON3pjUGxzcm9FamxrZndnZVFIeGdIOGJTS0ZFL2dOSEZ4U0hW?=
 =?utf-8?B?OXBtcHEvL2lKUk5TS1E3L2UvZkVqaXh6Q25tcHFkY1EyQ0ZKeDhOYlgwcUJi?=
 =?utf-8?B?dFdIbC9TY3hyeTdQWlFTQ1RvcFBYZFZYeENWQTBkTUNEUGwrZTBhVkdXdyt1?=
 =?utf-8?B?UG5DeG5MTWZMdTJKb242Z1VMMXRlRkxLMXBQbDRsUVFjYWxqL3I5NFlUQXE0?=
 =?utf-8?B?RW9qbkFxM0NQdGRDNlVHN1p2dG1JK0Ryc3MvU0E1UWdWSjFIWk9SeEV2RlNF?=
 =?utf-8?B?RTRwaCtJUTE2ZUFVUjBuajZoVTgwZWdCUXNUWEVDbklpbTJReWZZVEhxTm95?=
 =?utf-8?B?TFpEd08wRmlpMGNiTFRydnpDL1ZrOUlUVGFTN0s5TWU3TDBFc001MEViNzE0?=
 =?utf-8?B?MHZobXpPQ1BDWEE2OXAxc0NycnRLUG5OcWdPQXoyb09CKzJRaThoRzh0QlJz?=
 =?utf-8?B?TU1MN0JGUzRjQzk2eHNpc3dFa3Evc0JnYkRvR213aENhK1JpMnduNDAxNzZF?=
 =?utf-8?B?cGlqbzFxWWpNYjBsall1RnJ6bzY3QUZTdjRlYkVvdnpsVmVVUFRmN1pFbTE4?=
 =?utf-8?B?YzlrdDNsYUV0VzJtUEZRalg5YnZuUkFWTjNUMk9neWhQQWFpbTBDWVNKVHZy?=
 =?utf-8?B?ZUV4emxpSXFWSFJrRzNvSkszSllYOTdBNUY5cG9KZEFGMGxEcVNqL3p4Zk9w?=
 =?utf-8?B?dW9Bd2FzOG0xQ1ErQlpOWDM3dEJFV05lRDZ1S2pGZmZRaEtWTDkrQzV4ckNu?=
 =?utf-8?B?YzVuSE1TZWtrS0lCYXJXTkJvZnYydVJpaFFEN2JQQXBUSFpnb3NxeWFSdE12?=
 =?utf-8?B?YmlkUEREQjJENCtJYU93WTV5MTNBYVV1cHhGbmlYVWlsbGVSREkzV1VkczBF?=
 =?utf-8?B?VXplT2Nacm1ZRC9VQU5VQ2p1K0w1OVJnbzhzdFdjVGIvbnFieFhhQ1FKL1V6?=
 =?utf-8?B?V2I1WVRZdHdldW4rd3MrRGFrRWVaWm9kUnNUQXVzOFQrbXQrdFVMUkVtNE9S?=
 =?utf-8?B?YnBSSDUwN0JSNDk2U3VLMjJucS96V3haZmJPb3FudVBpS1pZdEJmd3hJSDhp?=
 =?utf-8?B?SUs1OUxKeEhVZVdwUzFneXRycWlwcmYyaHBmT2pvWjhkNXpYakFpdnVpUDV1?=
 =?utf-8?B?azNhVVFNUEFIajd5T1F5MVgxdWJtWDdhME9TQXFGeEdTenJHSUlHOHpSZytM?=
 =?utf-8?B?MC84dDVESUorWXRZcHZKb2hWMXdYdTRCcFpQTnNKNCtmR0ZITTJPMW44ditw?=
 =?utf-8?B?THVFS29XR3hEZVNOdGpGRzJ0V2RyOXc5MzlHa0FOcklEVWlmcUVJMTdhUDlv?=
 =?utf-8?B?dEhOMnBZUlFiKzJDUGtYSHhzUWliZnhtQkN6YWUzbW1jbWZETytuNU1RcnJx?=
 =?utf-8?B?eHhRcVFCZ3gza1dpdnF1N1Vrd3oyQzJBMmtzRytLTHRra2tvd25XWm5zb2Zi?=
 =?utf-8?B?K2JDenRVdGhTWDRYWklab001RSt0U09FWlhoanJFb1NneDd4QXhJTnNmU1VG?=
 =?utf-8?B?MmQrUWI5UE42Q1lXbkttbis4VEEwbkhyemE0eVBxbjI4ZHM1b0pwWHlvQkdm?=
 =?utf-8?B?U2o2OWpTVWZOWXdNOHFWZ1hFNStZOWxFeHhFdEFVY1lhOWdjQkdid3kyUVhD?=
 =?utf-8?B?UzlRSDJMRTlhYk1zNEZ4S05KM3YzNytRcHAzZkpnTDB5RkFmOHRuVm9FWUVr?=
 =?utf-8?B?OWtlemVSTldUcUdSN2FIb1hNcGRtVkNnWUt2NC9mVkpGcmNLNHhjVnEvV0t1?=
 =?utf-8?B?b0hiRjAzak1jaTY2a05nMVhTM3puZlNOY0lISTVsWjJNRklLRnptMmg4K1Rs?=
 =?utf-8?B?d0JkRGNtRjZGU2xncURxMjFDWkJNSnEvMExrcU01NVc1b3J5YUZXUWd0V3dz?=
 =?utf-8?B?eWQ3NkpxbmRVejVmTUYwMURycVlKemtoNEN1MXRGdlFSTXJzYWEyNk51aGY5?=
 =?utf-8?B?SnpaRkZuMGg5SGZma2t5dUN0M3UwYWY4UmNVN0J2cWdmb1IzK09TalVVRVVP?=
 =?utf-8?Q?aZxodA2Bk6EvS1t0y7i0aZaCh?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5560dc0e-dd42-4102-14b7-08dd922ce1bc
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2025 14:46:02.1628
 (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: GotnhbBnLMVOzXJ5AgeUt8E2Snr1UBM+2uSKHOnuoGmt7/BfnxMAqc3oV1MyhCp+
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6930



On 13/05/2025 16:29, Oleksii Kurochko wrote:
> The current implementation of make_chosen_node() does not contain any
> architecture-specific logic. Therefore, move it from arch-specific
> files to common code.
> 
> At this stage, there is no need to introduce an arch_make_chosen_node(),
> as no architecture-specific customization is required.
> 
> This change avoids duplication and simplifies future maintenance for
> architectures like RISC-V and ARM.
> 
> Signed-off-by: Oleksii Kurochko 
Reviewed-by: Michal Orzel 

[snip]

> +/*
> + * This function is used as part of the device tree generation for Dom0
> + * on ACPI systems, and DomUs started directly from Xen based on device
Might be worth adding (on Arm) after 'ACPI systems'. Could be done on commit.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue May 13 14:55:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 14:55:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983025.1369395 (Exim 4.92)
	(envelope-from )
	id 1uEr22-000517-Lz; Tue, 13 May 2025 14:54:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983025.1369395; Tue, 13 May 2025 14:54: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 1uEr22-000510-Il; Tue, 13 May 2025 14:54:58 +0000
Received: by outflank-mailman (input) for mailman id 983025;
 Tue, 13 May 2025 14:54:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEr20-00050u-PH
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 14:54:56 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3b5fbd62-300a-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 16:54:55 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5fc3f0a5506so3222483a12.0
 for ; Tue, 13 May 2025 07:54: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
 4fb4d7f45d1cf-5fd1950e6dbsm4773513a12.80.2025.05.13.07.54.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 07: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" 
X-Inumbo-ID: 3b5fbd62-300a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747148095; x=1747752895; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=h+++0xaQaSV6qY7bRFJoTyZqXPWg4nujXKCNe1Ogx1k=;
        b=NZnUQnxvYF/zB7Dq8V8op1qszlezzNyJMVxAD9V0fX2Tfd0cKnZRkcHLGQRDuTpHW+
         2qt8X0C6Zl3BFevMtkgUxgXSHRNWG1e+iecphhL0iSlvgZ0NzPSGmsjycdtszTl4/3lx
         YQ0oz5HVLjEsSWWpyk2A0vgXXF497nxXBIbwNuzJroLu8u32z4E8CU2qaOvRI5Ab9RuC
         Jjb5vGaEpCgR0tozoH57yTpdma92J4eL1CfjwyX+vIPa2m/3NG5JxNL5gz6h4OfjvbK/
         ifwDfjGY8mPgM9W0TnTeCn9g8P9zqBZAnCqoMvgQRs3p59Pi+ink5IZDjyxk2TPflUjA
         VFCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747148095; x=1747752895;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=h+++0xaQaSV6qY7bRFJoTyZqXPWg4nujXKCNe1Ogx1k=;
        b=jebjOrVZVkQYDP1H5Y4huSmdRjW41+eMxFyHd2l5/iTDwfd8ui6eLTiHjcpkUuTXMO
         ekNEXnJh7nN4EdYevkwhThmq2YzzySjWOiwplGeyhkDxEEIe8dzHOs5tYSGnsnY/hHYA
         mc5yNTfZv6Ow/Tnpgiege9V5PoUwL+hxyKl2neUC/KKO2p7mq3f1Kt4LQDmw+Ckh/1+w
         wr90HjhjPqiY7Pv9etgrH1uYbmy1SaiuZ4pwi+elin4l/LJLFQXT7kKoZGhEG56zGNQO
         L+PhbxmebDrvcuU7jrOLoR6e/uLNznaGuCC7BcAO/+Q2rEB/fOkqzexx/kIaC/w2U8AE
         BSTQ==
X-Gm-Message-State: AOJu0YxvTz2/4OA+7egt9yxq+ZCDPhPpH4i1baxLSLMoyLqy35amLdmM
	lqNfNOovSXAGvsnYi53v+1imnP3nqcmOu2ol9A4mHt7HaADJa9445dDZD8sQ0g==
X-Gm-Gg: ASbGnctx5fRO694DLLtr54XUYrA7K0OZOkx8igKq3fJl68BzNVSQyxgCymIDqhziNpv
	DAspajjUfTlYWAyrA2IPezB/zG1tlj9u0eQmvH8pbH/ghC1w8HxR3Az6R7GKGxn8UnvtfyM5jSw
	8Bl44/d7K/ukkFokWWp6GdXDFpzJWyH8PpransdWy40UcXR/YPAxKb01q6pw1acSNXJdyy/cY0p
	EGShUoZUiKbvCviBXbVMPCsvjHJZsTpmztgThSk9ve/KSiVV0K3JmIuonP44NBQaWUHs2YXtMUT
	dHPsPD5xbZuMVfYiav9Cg4FihVKk6zgKAjnhgfaR0jig3FT3hRaOXcq8eB6LaePEf5jJvehj4BY
	zCLkxEzsUdO2iOUX2svgq4O43TeAHley9HxVK
X-Google-Smtp-Source: AGHT+IFepcTsJCpcjIK4yDIPBNJ6TeQDu6F1Rv4OMAZJWLC0wg/eDV/kWkCaI0wZ0+VSWBUdoq5ftA==
X-Received: by 2002:a05:6402:350d:b0:5fb:206f:784e with SMTP id 4fb4d7f45d1cf-5fca0758c0cmr15461357a12.9.1747148094782;
        Tue, 13 May 2025 07:54:54 -0700 (PDT)
Message-ID: 
Date: Tue, 13 May 2025 16:54:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/5] cpufreq: Avoid potential buffer overrun and leak
To: Ross Lagerwall 
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
 <20250512144656.314925-4-ross.lagerwall@citrix.com>
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250512144656.314925-4-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.05.2025 16:46, Ross Lagerwall wrote:
> If set_px_pminfo is called a second time with a larger state_count than
> the first call, calls to PMSTAT_get_pxstat will read beyond the end of
> the pt and trans_pt buffers allocated in cpufreq_statistic_init() since
> they would have been allocated with the original state_count.
> 
> Secondly, the states array leaks on each subsequent call of
> set_px_pminfo.
> 
> As far as I know, there is no valid reason to call set_px_pminfo
> multiple times for the same CPU so fix both these issues by disallowing
> it.

Iirc it's the processor driver in Linux which would invoke this upon being
loaded. It can be unloaded and loaded again. Will it ignore the errors in
such a case? As suggested to Penny for some of her work in this area, it
may be better to return success instead, to avoid the need for following
bad practice in drivers by ignoring errors.

> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -520,7 +520,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf)
>      if ( perf->flags & XEN_PX_PSS )
>      {
>          /* capability check */
> -        if ( perf->state_count <= 1 )
> +        if ( perf->state_count <= 1 || pxpt->states )

Even without the remark above, there probably would want to be two separate
if()s, each with a distinctive comment. The comment that's there would go
partly stale by the change you suggest. Or perhaps the extra condition could
move (inverted) into the outer if()'s clause.

>          {
>              ret = -EINVAL;
>              goto out;
> @@ -534,6 +534,8 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf)
>          }
>          if ( copy_from_guest(pxpt->states, perf->states, perf->state_count) )
>          {
> +            xfree(pxpt->states);
> +            pxpt->states = NULL;

Please avoid open-coding XFREE().

Further related to the earlier comment: Beyond the processing of PSS there's
more processing below here. If the PSS part succeeded and some later part
failed, it may actually be necessary to invoke this operation again. I.e.
even more so relevant that it won't fail just because PSS was already
processed.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 15:39:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 15:39:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983049.1369405 (Exim 4.92)
	(envelope-from )
	id 1uEriw-0002jB-QY; Tue, 13 May 2025 15:39:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983049.1369405; Tue, 13 May 2025 15:39: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 1uEriw-0002j4-Np; Tue, 13 May 2025 15:39:18 +0000
Received: by outflank-mailman (input) for mailman id 983049;
 Tue, 13 May 2025 15:39:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEriw-0002iY-0i
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 15:39:18 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6d7d7081-3010-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 17:39:16 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad1f6aa2f84so1211658266b.0
 for ; Tue, 13 May 2025 08:39: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
 4fb4d7f45d1cf-5fe8772f75bsm2995443a12.74.2025.05.13.08.39.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 08:39: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" 
X-Inumbo-ID: 6d7d7081-3010-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747150756; x=1747755556; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=kzrbVqjmBV9ls/UyKHlCvrKeI1WB3fiHrZ04Xlb8BJ8=;
        b=KDlHZgx3YquK0xvdsaM4mvz6Olp8CGEMpsqJThI1uiiWMFhIPf0zFX37HNA3g9c3vO
         cwy6j6dEQnKmiLJAEtjYvjAw44s+TNYAg3v4Yz4tXMEL7Dhc8E8q6/BA3J6p+3/EVrmu
         ycVnfb/3uxuj4HSclVJPHaw6+TWOuHB/Y/e/c8hlk/cMqqJ3SEPMg+5BD+ZOBJ6K+kVg
         4RLT13ErZOKsouY6ZGsYAYT01XMEygHcg6tfHO0EaI2XAjGozG+lULCR26nAUK8HlFkI
         Pv9VGHweZ7EKY05H2jGx7KfCxGE/2b/uoRO01ZSw+iidUjg2/+t9YLJG1pYYpktmSef3
         ybfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747150756; x=1747755556;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kzrbVqjmBV9ls/UyKHlCvrKeI1WB3fiHrZ04Xlb8BJ8=;
        b=Z5CuthnRt55RvInYLywZN6c4YbawvYv5xQN1M+vQHBj0LtCFSqfyp3AX5IG3NX+GS1
         TNhlI3btyj0xqhVF4Et2n/vj1bC0nsa1A2Ny0E+i972rEA5xpmPZz+aqrrx+YgWyhvl+
         aYqeZF7MHUsrS82o9f7pQ1Ez8HUWGlamJ+XULcHAdxYmqSdDBwxybPPw4SPx4VuoMDg0
         4QNKwNUmX+tocrT0UwuI6dvheI5iHb3qeS5WxqSVbEYize2nwvZ5ly9A73M289TaL2DH
         pub9auy+mm78QoIxh67Wgdn7ZPgQccjqXkE1TslSCyfP40X8FP9MC3SEY+TFt2NLs1Bi
         nZ+g==
X-Forwarded-Encrypted: i=1; AJvYcCUbdh1vmE2IvOvhyJXfy7p6WcxLw0CkwTQZW8NVL45s355ZXFaYIK4Akd7D1aaqlNEGo2WMyux1iLQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwJREnm0h5bHIM4VzcMHoVQUDbYBg2vbp2OdYT+M+G3NdadA4OW
	mDckvpCj6rPNJONYMnQpA9f6agUEz5vs4odUSShHNTrMhno7VO7vH/alhkiQKWHconbNfuYdMr4
	=
X-Gm-Gg: ASbGncujnOZGcKRKQNHC+mobXfSXKW6O3JK2/HmoIn/EOlMfoEuK2abLyIUwEYXgyzK
	Ccd1wYtY2xTmoK0qXh7IuwBa0/+hRhZsDgibsY26wcAf+o2NPXpzOKwpuXdluO/wX86co/2gBgT
	+4twT4RVbDC3MVybHg2y41xQ+ZEjBPmiv/43GCS6ULDwPRYT3oReIzC52bJNyoGYA7A4lfqIYcl
	R9LljdPQq/ijgnWYhJqh79Mu3s2NPNWNdXcID8Q5fThKIv1/T6R2ttFm1nXVw4IR08Mv99D5bu6
	Dgiq6q7IZhXDEtgmbgo6l4JCJhyAk8lEFb0efXU5JA0smBe6pYaTUvXny+bAaIm0PemHgxDNXb3
	S1fqXYRBjyQ5qj6scHWm+BCFyEua0HhF1LJCD
X-Google-Smtp-Source: AGHT+IGmVG1mPSrbv/cCefUCrRXB9RkY23N3EG7LDkdtJYph9TlG2DPTFx5h0J+Fa4OX16INxOlJlA==
X-Received: by 2002:a05:6402:34c5:b0:5fc:ae51:ba0 with SMTP id 4fb4d7f45d1cf-5feebe2d581mr3563195a12.14.1747150745124;
        Tue, 13 May 2025 08:39:05 -0700 (PDT)
Message-ID: <46dfb68b-7e94-40a8-9900-883ac899346e@suse.com>
Date: Tue, 13 May 2025 17:39:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/6] rangeset: introduce rangeset_subtract
To: Stewart Hildebrand ,
 Stefano Stabellini 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
 <20250508132040.532898-5-stewart.hildebrand@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: <20250508132040.532898-5-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 08.05.2025 15:20, Stewart Hildebrand wrote:
> --- a/xen/common/rangeset.c
> +++ b/xen/common/rangeset.c
> @@ -397,6 +397,18 @@ int rangeset_merge(struct rangeset *r1, struct rangeset *r2)
>      return rangeset_report_ranges(r2, 0, ~0UL, merge, r1);
>  }
>  
> +static int cf_check subtract(unsigned long s, unsigned long e, void *data)
> +{
> +    struct rangeset *r = data;
> +
> +    return rangeset_remove_range(r, s, e);
> +}
> +
> +int rangeset_subtract(struct rangeset *r1, struct rangeset *r2)
> +{
> +    return rangeset_report_ranges(r2, 0, ~0UL, subtract, r1);
> +}

I understand this was committed already, but I don't understand why: This
introduces a Misra rule 2.1 violation aiui. The rule isn't tagged as clean
yet, but it was accepted and hence I thought we would strive towards not
introducing new violations. What's the deal?

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 15:44:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 15:44:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983057.1369415 (Exim 4.92)
	(envelope-from )
	id 1uEro9-0004NX-Dh; Tue, 13 May 2025 15:44:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983057.1369415; Tue, 13 May 2025 15:44: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 1uEro9-0004NQ-Ae; Tue, 13 May 2025 15:44:41 +0000
Received: by outflank-mailman (input) for mailman id 983057;
 Tue, 13 May 2025 15:44:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEro8-0004NJ-BV
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 15:44:40 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2dea49c7-3011-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 17:44:39 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad2414a412dso485755566b.0
 for ; Tue, 13 May 2025 08:44: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
 a640c23a62f3a-ad219341d44sm806727966b.62.2025.05.13.08.44.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 08:44: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" 
X-Inumbo-ID: 2dea49c7-3011-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747151079; x=1747755879; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=vFwP/8iRTVnlCDSD6iQk1aNwKdEQiXgIzTPofz9iNJE=;
        b=DliwfiNMPfhBSrvvEZ10QgfsmlUFm2nNDsGRmVtyEkHthWYh1qYlmtoDKDFldyC1oW
         8snpUadRpnMGAJ19M7hKr12Ilaxr+sWjPdIIwzXsQlJdpIQZrWsYntH9FqBFhUc4C60Q
         tzzLvALdI3AFm2vprQBhUTNSwMD8B5lG/LHQnx0wTbu7Lap8n5+pZMLe7+O6BI2Idn+7
         TL1c+giDFPhDxie523dO+eHLE2pAIiogSrA42Xn1D5FalNUBxFCW5mrsntwU0G3EXr//
         OgOBkhBqtb2C72V3ehGOOFV2MBNklwLz2yxeXQETet/jNZ79z41cMqz/0DBwb1hX1JAc
         Ebow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747151079; x=1747755879;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=vFwP/8iRTVnlCDSD6iQk1aNwKdEQiXgIzTPofz9iNJE=;
        b=sViff6PUMa18TTEVPJRrmO9h2PKpQFtMCCyeGa7UurJVbnFzVJBmCE3KnpQy6rb7/G
         5nLnmzShRyJF/e+4ICuADr0VLVy/4/jW6wItmy6bMJaS6U3lqhNgMgYuhALI+2y0T6jV
         zqatwwuCkMdZlDgZ/Bn/vtI/cHtmNydvsK6ZRGf+nsBLjSNmcyK5x4IrCVufP8jqDvR1
         rdj4LwQr60Qz8czxMOIemcsdM+yTxUDL9JfnHvwY6zw0wgh48TvNp/o3ZTgLkJ5lGu/N
         2nYRgEZ2rihmV4f3CV6gKP1ERbDxI8q7AicxyG8AULIDhf4D6QC9EPvskANku+JGrbqD
         5Y2A==
X-Forwarded-Encrypted: i=1; AJvYcCXv6fXkSm/9qaiS9tTfx8VCGY9mLsaFW7qdfnBEnYd/YATrDMnlJ7QFhr85/ZhXynwcw2hKU6AVL7M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzfnlhsxTMBdok3k1dl/5TFiCw6EnvG0Xbbucaeds3Gpu86wcL/
	2rSKamMGfEvxcDth3Fa6GybaZrbgpHrQTyriP0eihoYgYTbRBw8sFC+CYQI3JA==
X-Gm-Gg: ASbGnctDRlZZhNM4YN2eOTFwmaFpyMfaE9zBkmmDE9PTBooJwaUJRvKI90RGyg0KTvi
	6Z9Yp4mdec5oQJUILOQEcoe6E6iWUew7waHkcNluE7zjEQeeV5R5xFP3B5Nba3wggp0F/tg61je
	T56OGQEwlrF5Ufe5n1J3Tk/ZPRFaOJ20zcwtgUe3GQaw/MDfw4DLR4sawQ96TQM61yLZVnim9Jz
	vt3awMHvvJbv1YwOhphUrOgGqId5He/G8QAAdZHTZhZRKYWdNhSK8UXKSYguPEvBEIhcGKkP85w
	Ce+aP7g5FU0OMEEEwhrN+hjXAv9PDduOGHN8DNs2aNe6WQnjw8COKhkia/RtfaVL5/xJ46DbIXc
	mU6fNwh177fMGe7wRyP3C+MCpPwXGiuvboGqx
X-Google-Smtp-Source: AGHT+IFe/xj8iNrTe37SZq8B8vGkugME0KpApANv35X3+GhnLUzU+nvYHyDscRpVyEJfuIt5iIqUOw==
X-Received: by 2002:a17:907:7b08:b0:ac7:edfb:5210 with SMTP id a640c23a62f3a-ad4f7114f16mr5798266b.20.1747151078641;
        Tue, 13 May 2025 08:44:38 -0700 (PDT)
Message-ID: <78c5a370-f17a-4940-aa5b-c18d52e4b6ea@suse.com>
Date: Tue, 13 May 2025 17:44:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/16] xen/riscv: initialize bitmap to zero in
 riscv_fill_hwcap_from_isa_string()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <21efdebac3d1c9797420a8c81fbbd6a06ecc9121.1746530883.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: <21efdebac3d1c9797420a8c81fbbd6a06ecc9121.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> The this_isa bitmap should be explicitly initialized to zero to avoid
> false positives when detecting supported ISA extensions. Without proper
> zero-initialization, the bitmap may retain non-zero values from
> uninitialized memory, causing Xen to incorrectly assume that certain
> extensions are supported.

Why "uninitialized" together with "retain values". Yes, the variable is
indeed uninitialized, like any automatic ones are when they don't have
an initializer. I'm not going to request re-wording, but to me the
above read as if you were concerned of a static variable ...

> This change ensures reliable detection of ISA capabilities.
> 
> Fixes: 0c2f717eae ("xen/riscv: identify specific ISA supported by cpu")
> Signed-off-by: Oleksii Kurochko 

Reviewed-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Tue May 13 15:44:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 15:44:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983059.1369425 (Exim 4.92)
	(envelope-from )
	id 1uEroN-0004h8-OK; Tue, 13 May 2025 15:44:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983059.1369425; Tue, 13 May 2025 15: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 1uEroN-0004gy-KC; Tue, 13 May 2025 15:44:55 +0000
Received: by outflank-mailman (input) for mailman id 983059;
 Tue, 13 May 2025 15:44:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEroM-0004dN-LP
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 15:44:54 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20619.outbound.protection.outlook.com
 [2a01:111:f403:2414::619])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 35486684-3011-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 17:44:52 +0200 (CEST)
Received: from CH2PR12CA0002.namprd12.prod.outlook.com (2603:10b6:610:57::12)
 by MN2PR12MB4406.namprd12.prod.outlook.com (2603:10b6:208:268::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.30; Tue, 13 May
 2025 15:44:46 +0000
Received: from CH3PEPF0000000C.namprd04.prod.outlook.com
 (2603:10b6:610:57:cafe::43) by CH2PR12CA0002.outlook.office365.com
 (2603:10b6:610:57::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.22 via Frontend Transport; Tue,
 13 May 2025 15:44:46 +0000
Received: from SATLEXMB03.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_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Tue, 13 May 2025 15:44:45 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 13 May
 2025 10:44:45 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 13 May 2025 10:44: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" 
X-Inumbo-ID: 35486684-3011-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NvNqk7c5V3W9kX40lc+e7i0qVLuX9U/fumAF1DPsVFHmg8f1WzYiYX3BDxU38S1H/tDFg8fmhD3bdulErXL4XRP3vNCNvUYkhCXx9GSfGXU/NOrEVn+RawjfCigUBXWUin+uazCiSKrWVDTE1HdQrURQ24mt0U+IcqR7E4Lw/B3jCcoxCSTajLjSRqC6/I4JA9oxe13dW2JVhqYPb5sqjTSdOJuJ1qtNHVcXPh+Mw/xydWWB6yo6H+BIT8CcdjrWdNWpvYsaVH/Nmzr9gz9LJkJGZUgSo5jeWkaOxtjclLM9LpaIhvlhe+pDW3dDl0NTNWajoc/SmhgH32uFQPwwdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=enXK7WDmRHrwdQGLUmkJKQ17xE1Qn3TxOFzOTixdoVc=;
 b=ZYZ7qEfQUyRmkHwCLCtWl5DZw4Ru2fFG/lWfRnTs89Ov4aCxxaWINaIYfmHAWN0rv3VMasOkVEVxrNNpgPDzWtRNWLK9nMutzd5WL9XpyKd9Eu4klO57u5TQ3tK/eiu/GSmsBvsZUuhvgYtFRzGDfZeHXCipJPUbsDvlPQlmpUwNnoCiNvQSjQ4+cINozhf9n8ZQUukne+f+cUydRHPlhMlDLX7NnXBo2NEh+hpqVew9RbpNueScHhiKlTZjl9lW8/iypObtgIVU/PChMl2/U/N3eRlphsfNGHuo3JoghiFmS/wZqWAd8iW3zvvO09752zpS3sZ3H8BzauDez81qQQ==
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=enXK7WDmRHrwdQGLUmkJKQ17xE1Qn3TxOFzOTixdoVc=;
 b=w9mKLRI221hpQe3IpuSjTDX2V0K5E2GXN/tVL21tC8X5KUiknXv6KMF0yKll5GWmdNuVhtkseTBLlN3vxC5eKPHOM/SQVI+LtKtkgjSj7FPrigwoR27qxk0PjIsmy7OM5JsX4JWyKfb29pMXtRu/ubbug+/ogMRDLXTmCoiFjNQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Anthony PERARD
	, Juergen Gross 
Subject: [PATCH v2] tools/libxl: Only access legacy altp2m on HVM
Date: Tue, 13 May 2025 11:44:19 -0400
Message-ID: <20250513154419.27860-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF0000000C:EE_|MN2PR12MB4406:EE_
X-MS-Office365-Filtering-Correlation-Id: 21cdd52e-6620-4bcd-b7fc-08dd9235160d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?2+bXlOHjG5KoAmBKjEJJrvjlOFSa1abpbOhY7MlZRSDV+WAJ0PgZMXxc+4cW?=
 =?us-ascii?Q?S47PxUmkOTwtq8LyzlprNwWlYfPrbTxBIT8SjqYs3Fo998HMXmhVTkvcszhr?=
 =?us-ascii?Q?OqYJ3ypFp2eRH8VSpvP3mVLRmaf0Fl2Z0tj/hHHKg5tBBS/Y81jMbrYPGAC9?=
 =?us-ascii?Q?rrb0a4YbD+ZasdxNoBhYFQQqltmWWY7yzglBTs6WgoKU0wZvDu1sieOxyzES?=
 =?us-ascii?Q?xG6NYuvdrKHQFrHsyjYjSQVmuIgrqyvByoHVpz/+2Fb1VJzUHNGFONp23T0Q?=
 =?us-ascii?Q?NGktSp21ewva6BJcp2e/M2oP2Bedh0scvT3u8o1JMo68McM3PTozsqlfLPqo?=
 =?us-ascii?Q?8UiJ0vjsZR9NRgsNbDvCEByIzwWDcyKMWp7cSXy4vKzl7DmAsQpfxIIceDdl?=
 =?us-ascii?Q?kLy9cR9zDJqhqtdFCTajgjVko+tTyu0gC2uCQ/X2t38pGJV4mGsOSQtnCLB6?=
 =?us-ascii?Q?MNasR96rCnguWsLbVNlQoEyErYdkAdgKZ8f11lbit97hVvvvAfnB3GHz5gXx?=
 =?us-ascii?Q?mOI23PPpLr4AIoOuY7nS/t/7PiV6LuLOd7VXesHEy2yzuirTuG5fNj2bAg2A?=
 =?us-ascii?Q?+4x3Ew1AVUOFv84n9hn7Ei7lZ4J/9mKi6N2TgY9nsP+aEOGTScbCx0YA7E65?=
 =?us-ascii?Q?bolJviP1wNs+9a9Bsfb4jMbrLfDxEBZU/AhkxrN9nLF/1V8FqFp+ijxq3q9N?=
 =?us-ascii?Q?QpJRMDxmkNmzEiiokyubci9Yut7/MZQdO73bPur0L5bfw84ctA/GQkaAFbf7?=
 =?us-ascii?Q?oiiLdofToqvREiCA1g0ePfiW2WkKI94PksD3iZvmRczAJeNCZZHlYZH4I7L+?=
 =?us-ascii?Q?XJboLI4rLxopRMgxyXQqMUCngFRnGskenCYIwKQQKGayM9O7+TwroU2YgF/e?=
 =?us-ascii?Q?DZai5Nd0+siffCB/lcdpbYs3oQQKP2+Wnr3jZpSnU8bivJh9Gyf6K5D0R9Lk?=
 =?us-ascii?Q?wIrbzMe3xPZrRK/gYyQk28StPdFUhrbMlO48HJfHQvTxRQk5XcdRNf2xjXqR?=
 =?us-ascii?Q?+j893YAGf7j6UfuSkSQNiIcLz4wWh8iSGyy1xlGIhJR2GcAwj+D8x2qjQCv+?=
 =?us-ascii?Q?vmi/w/24SNchMeYmEfRcMhAlScPs+68CAbPbOqPKdsekziVNlKguQd83USrl?=
 =?us-ascii?Q?qBG/ADcN6HJ5d07dJoQpdHGeHSUjd2ZmdYwdMMDyKd8qSy4o1YB6n2G5MLIp?=
 =?us-ascii?Q?L7Z0XdZj38bz67cB4QjYgyL3CR+3EVKHWH8YNKDssia7KqQJJ/h1kXP6KZBs?=
 =?us-ascii?Q?b1CwNi02nNUB6jw914ZSYpfSHLbef9C5DqEqF3+nBTPbbbHZzhWhEBPxmL/R?=
 =?us-ascii?Q?ph9QjN8eLXSOkhg2hNW4tdjtuM/OSEV83Q0mY+hHOwkIEMLGE+Br62XzuahN?=
 =?us-ascii?Q?dfx8oF8Fm6PuMJkHOceuWuViMMDkzIExsfN9Y19NIDj157+G84sVQLGOZ0F2?=
 =?us-ascii?Q?MFQ6Fwj21NHxo+TBm6qAPhux3erEcwvyfnK8QklcNHFEO6sv+qEcb+JetAFt?=
 =?us-ascii?Q?KpLnd5tke9zC0TgKQ9FH1zKsvkS10bC0zNcE?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2025 15:44:45.6855
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 21cdd52e-6620-4bcd-b7fc-08dd9235160d
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=[SATLEXMB03.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: MN2PR12MB4406

Only access the HVM union b_info->u.hvm on HVM guests.  The union
access is not guarded, so this reads and sets the default even on
non-HVM guests.  Usually this doesn't matter as PV and PVH unions are
smaller and zero-initialized, but the zero default will be re-written as
a -1 boolean.  Generally, it could incorrectly set b_info->altp2m
through aliased data.

Fixes: 0291089f6ea8 ("xen: enable altp2m at create domain domctl")
Signed-off-by: Jason Andryuk 
---
v2:
Move comment.
---
 tools/libs/light/libxl_x86.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
index 0b1c2d3a96..867addfcab 100644
--- a/tools/libs/light/libxl_x86.c
+++ b/tools/libs/light/libxl_x86.c
@@ -814,17 +814,19 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
     libxl_defbool_setdefault(&b_info->acpi, true);
     libxl_defbool_setdefault(&b_info->arch_x86.msr_relaxed, false);
 
-    /*
-     * The config parameter "altp2m" replaces the parameter "altp2mhvm".
-     * For legacy reasons, both parameters are accepted on x86 HVM guests.
-     *
-     * If the legacy field info->u.hvm.altp2m is set, activate altp2m.
-     * Otherwise set altp2m based on the field info->altp2m.
-     */
-    libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
-    if (b_info->altp2m == LIBXL_ALTP2M_MODE_DISABLED &&
-        libxl_defbool_val(b_info->u.hvm.altp2m))
-        b_info->altp2m = libxl_defbool_val(b_info->u.hvm.altp2m);
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        /*
+         * The config parameter "altp2m" replaces the parameter "altp2mhvm".
+         * For legacy reasons, both parameters are accepted on x86 HVM guests.
+         *
+         * If the legacy field info->u.hvm.altp2m is set, activate altp2m.
+         * Otherwise set altp2m based on the field info->altp2m.
+         */
+        libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
+        if (b_info->altp2m == LIBXL_ALTP2M_MODE_DISABLED &&
+            libxl_defbool_val(b_info->u.hvm.altp2m))
+            b_info->altp2m = libxl_defbool_val(b_info->u.hvm.altp2m);
+    }
 
     return 0;
 }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 15:48:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 15:48:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983079.1369435 (Exim 4.92)
	(envelope-from )
	id 1uErrz-0005Wn-5a; Tue, 13 May 2025 15:48:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983079.1369435; Tue, 13 May 2025 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 1uErrz-0005Wg-2M; Tue, 13 May 2025 15:48:39 +0000
Received: by outflank-mailman (input) for mailman id 983079;
 Tue, 13 May 2025 15:48:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uErrx-0005Wa-Pw
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 15:48:37 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bafbeb3b-3011-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 17:48:35 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5fbeadf2275so10086361a12.2
 for ; Tue, 13 May 2025 08:48: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
 a640c23a62f3a-ad4d5ea7689sm158996366b.135.2025.05.13.08.48.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 08:48: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" 
X-Inumbo-ID: bafbeb3b-3011-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747151315; x=1747756115; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yY6cvG7meK4Ko8EN8Av8RTqs+rI7iIF9429FCUD1FCM=;
        b=eMZyMkTP+ZB2MMOktCWJolSkHDl8ak6dYi6jwUFOhHoccnDpxeyB8FryWNCEdtvPUw
         Lgc7VvsG8gF7a2AzSfSJ5rqt1EN78rZNkIXruHAYAPH+pXAg2pbeYr/DCF9822NJ2/iL
         WNUXgFpokFIoPOX5FiXJV8BM2yKx5F0jJWftEBcw3Gy8YvbLbCntEDqFQUl0e/FzP+Vm
         aKO4LFe1af1d57bqsjml9FoXKlO0Sd3i5fOlsLL9t8WhBCGr4AI1VqPOFPZXssiE1joa
         BbgIFUozL2RTtEawhKFcHMjH0UKQNlovFow1ekRTyRi95TABQZdvmdJpdu0pPxBHSc9E
         O0ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747151315; x=1747756115;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yY6cvG7meK4Ko8EN8Av8RTqs+rI7iIF9429FCUD1FCM=;
        b=DFVh6vNoB8jb1spjuvWS3a9b/eaTF4hiG2n50XC/vrxMrQABySD9hN1RBVUmgInxTa
         9i7NbvGgLHScMTyMau2HqAo6MGtMLLmjrxvYSsyv5nSYX3KyYL8VQQM/6/2p7GYS7eh1
         c2Y3UsX6pHF8rof/uPYjaZ2ystwYAz/PufySWlq4ZDoqZpq+4odmK5XuYAnn/T+jkKZo
         TpydB3nxv4jnIZbrTy8s44ZonAEL1ZE9lVvPQ99WEH0jWypGDSJ2ywMCU9qySKNP1AKr
         2PYCMJgLFOf2lpriYmDh7SYyEIdcANuLV+EktJXlfNoS7XSAHaUWuVsaIUta7l6B2T80
         sbRA==
X-Forwarded-Encrypted: i=1; AJvYcCUoutVo7GZC0gQAhZMO9cnrpItGi/UNeR1Q612fuOKBexMKiqKVZwn9hOpWjFFebaG2vgR3CivpyhM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyH+5Yp+rItArb+Cu6yyqQuIlmMx3Wbr8dTDfQJTRUwyzmqCBmy
	L7mz8g64UyGxO7HeCQrI3ZvQHVAhfKvwOqenAw+nxxY70aTp+8ePADxJt3tZCQ==
X-Gm-Gg: ASbGncuWa9PjHAYJynwmkHptS86cYtbWEl3T2G+Z9ObKYiFYKFYdz/BYQPfPAypKvNT
	AOvp0Q7UKNErhjckN+RiF650aUfnKPEwsnIYr1DB6e5Dsjhuwi/8gVZY4FW/GOCI+PFx56TNkyq
	jKCnvWx7QPuWHEQpmS20pcSTECXuMSYK8pskFyT6ZBZWGF5fWMCyPHfkK2Cgj9zi4MtzMuOSsYY
	UEqLIwEZo8jzciN47lNdO5xoNurXRDzToWWzAwqJmbf7p5KkbgB94opdS7YiT73MlKDgNej+Nwx
	u4F8X+QFe977M7GASpuR6TFXnR11pynzVwBhEwDktbzipluL5jilYJL+8iU+JvDYBUg92FU1Fjz
	O0k3QC7rGW9HYw1+yu3xZlzjwsaRe0rqM7JL/
X-Google-Smtp-Source: AGHT+IGz7r+fZ1F+13teVQErU9GMk0fNVa+608FrDSxZsL8Tmpc2FsHGab+u5HRuAwrpPjjWrZUQgg==
X-Received: by 2002:a17:907:cf8e:b0:ad2:1cba:cf85 with SMTP id a640c23a62f3a-ad4f74c7dfemr3504266b.39.1747151315359;
        Tue, 13 May 2025 08:48:35 -0700 (PDT)
Message-ID: <3e849625-582a-4e5e-b2c2-b3eb16aae857@suse.com>
Date: Tue, 13 May 2025 17:48:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/16] xen/riscv: introduce smp_prepare_boot_cpu()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <704550ffbb34c94bfe85be928b2fcc0105552e82.1746530883.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: <704550ffbb34c94bfe85be928b2fcc0105552e82.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> @@ -72,6 +72,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>  
>      remove_identity_mapping();
>  
> +    smp_prepare_boot_cpu();
> +
>      set_processor_id(0);
>  
>      set_cpuid_to_hartid(0, bootcpu_id);

Is this a good placement? I'd think that smp_prepare_boot_cpu() ought to be
permitted to rely on set_processor_id() already having run, for example (even
if right now there's no such dependency). Alternatively the set_processor_id()
call may want to move into the new function?

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 15:59:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 15:59:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983089.1369444 (Exim 4.92)
	(envelope-from )
	id 1uEs2l-0007Oc-3Z; Tue, 13 May 2025 15:59:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983089.1369444; Tue, 13 May 2025 15:59: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 1uEs2l-0007OU-0Z; Tue, 13 May 2025 15:59:47 +0000
Received: by outflank-mailman (input) for mailman id 983089;
 Tue, 13 May 2025 15:59:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEs2i-0007OE-OH
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 15:59:44 +0000
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com
 [2607:f8b0:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 48ad9de4-3013-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 17:59:44 +0200 (CEST)
Received: by mail-pl1-x632.google.com with SMTP id
 d9443c01a7336-2302d90c7f7so31175025ad.3
 for ; Tue, 13 May 2025 08:59: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" 
X-Inumbo-ID: 48ad9de4-3013-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747151982; x=1747756782; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fyiOPlQIv7OaNEkg3KaqXanxm9PLMytrHQbLBMv3f+Q=;
        b=Qh1WFDXtZkXRcbK98sDrw3DHaA+QtEBd2M0cRLSAPO3s900ZmvS85rlLlxxxFEm9eI
         ddvp7n1Z1+ArNK7mGokWUO8N5+upf5k6fFd01k3UrM17bP4PCdsUXo1LBPEapOOmH/SA
         4bFWPolA7KUOMvKaLJH3k706gH5nyQnIeIMuU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747151982; x=1747756782;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fyiOPlQIv7OaNEkg3KaqXanxm9PLMytrHQbLBMv3f+Q=;
        b=YMNbN4WGggtTsud6z0uiI7ks+UxqdysR2yJvIposcWSEevUpzPZmpStOouONU/pNcg
         kRKMajaFNlhdOwsy0QQU+bJLw64VovDsPuQwfSaEDSf4ygROY4KtNtzUDawqrtTye5Zo
         FNDms8wemHS/7W5AKQw/2AZ9ScEOGwuts5RAXw6LImBIQoecUDilVs9g1OubeXGbxmhY
         6Ayo4wjM6wpKhKxWsmjhLKgQdd72Lrw40zUKk2V6NrOxioCu4HNronDp4XfYjSWMwVH8
         DSff9La2JVUZ17AvDVT78JIe0FSDz9eprnDzYFGIfudB6sYOGXY0tKd/ixCwCj89ZldZ
         8oZA==
X-Forwarded-Encrypted: i=1; AJvYcCVOwuce+RZ9EIkycekwQQ5Bgt8vZ2PzPzS9aGZOtfJDbu4SlUBGJW47t2YUXYibkxDkU3KtW6HpveE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyIvKcJ/GhgG8iHtyJcrGzDB8KZgelpXEZQ4Mw4qxRr5MsKiBAp
	pQwSCtNEidmu503OVgheF6KPgzo68t5RCLOllSh+0jYYXiM2j2OTPl/TYG08XPW5RJPYdXhQs6j
	Gf5vepscjAc0ftJqk6qKWnXTxUSLNnHyhnxmeRAP+DElb65lI
X-Gm-Gg: ASbGncutad+iPEDuZEWCPjoNBYxblj2NkWonmrqQdfwm6gbdzaEXfW1gq+GdaRc/dzz
	ZhVw/rzIefMx1Oz/D3LOOxLpl+Xz0oQOlkKSqbFQF7KEvZgCwbW4OoAVLsLcandaUgPFCNaTgNq
	2FEVUq2XGFVQcFR/mt4D31TsKc4Cp0uQM=
X-Google-Smtp-Source: AGHT+IG2q/PQ72NOGbkd0pXPYNREjxQGQBAZGKuMIGIrpSO0EI4HBhU/kAJSe7eJq+aQTKl7GpjVumMAi5qMdXQyYzQ=
X-Received: by 2002:a17:902:d507:b0:224:23be:c569 with SMTP id
 d9443c01a7336-22fc8b7bdeamr294218075ad.22.1747151982333; Tue, 13 May 2025
 08:59:42 -0700 (PDT)
MIME-Version: 1.0
References: <20250506162510.1676425-1-kevin.lampis@cloud.com>
  
 <504f0be0-91fd-4847-8fcd-505771674814@suse.com> 
 <55e73266-7727-4a1c-93e8-dd69712d64d2@suse.com> 
 
In-Reply-To: 
From: Kevin Lampis 
Date: Tue, 13 May 2025 16:59:29 +0100
X-Gm-Features: AX0GCFsrIBMqFaa6AK3P-pnnWD1QaPwbaJvtnj21np3_lv_jDPyVd9AelfAze-4
Message-ID: 
Subject: Re: [PATCH 3/4] Add lockdown mode
To: Jan Beulich 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 13, 2025 at 3:32=E2=80=AFPM Jan Beulich  wro=
te:
>
> Well, it's easily possible to catch that error without any extra parsing.

If `lockdown` is not the first argument then we should print a warning
to tell the user that Xen may have already parsed some insecure
arguments and lockdown mode will not be effective.

What would be a good way to check if lockdown is or isn't the first
argument? I am not sure.


From xen-devel-bounces@lists.xenproject.org Tue May 13 16:01:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 16:01:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983095.1369455 (Exim 4.92)
	(envelope-from )
	id 1uEs3x-0000y2-DV; Tue, 13 May 2025 16:01:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983095.1369455; Tue, 13 May 2025 16:01: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 1uEs3x-0000xv-AO; Tue, 13 May 2025 16:01:01 +0000
Received: by outflank-mailman (input) for mailman id 983095;
 Tue, 13 May 2025 16:01:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEs3w-0000xn-M1
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 16:01:00 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 75b54b37-3013-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 18:00:58 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-acb39c45b4eso944037066b.1
 for ; Tue, 13 May 2025 09:00: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
 a640c23a62f3a-ad23a99f9fbsm602254566b.25.2025.05.13.09.00.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 09:00: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" 
X-Inumbo-ID: 75b54b37-3013-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747152058; x=1747756858; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AE0hqb5OlK5hyIP+I7gmgtxT2HfhXK3XdJVlDu1JXKA=;
        b=enpBLHmYtw9sgIhH6IGycuJvsmw4ayXgib9JfiUZd9AWQID7ZyFi/y0P3JBnQmbtTM
         +ykv0M805ADwGzy0hhKPk88+IkKJYupkItpDNNWrHkEVWJgDIYChppdaygU06DFInP7E
         FUpzU64mm9sEUVAQ/ZLsUdg/sTE/Ekz8qdWwfmv34uqio9966Qof0l32MMrhezsiyvK+
         SBRCw/uCZhPxkkxvOw/m1RbN0wVq+TFEag4Y/LFL1wJQNcdCAhVAEOitTwodlBQWgRZ/
         mfsoFWs4BXQ199K9xCNxSpP2eFRFGQi6ub7Va2K61r6G7oTRlWQoynekmY6jnndU0VeG
         Gneg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747152058; x=1747756858;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AE0hqb5OlK5hyIP+I7gmgtxT2HfhXK3XdJVlDu1JXKA=;
        b=SLtwmwUCcA2s7nxcSIDqWFAgNBuDXI7QbBahWJMPzQ2Z/Qup0SCbTtYIY81haJdC5C
         ymAI2ZTPCnyxFr3ZYzZE9zqwSDCcfr3k0Bd5lSbBT1fcm1DiwK5a5QsUsEpFVnFBcqaG
         KGQ/EVxJmP9VTBrc49uvAbe5rzMHxcmdUupmEN/WFrmXs9x8fiPIXK8ulk5bqNieoEE/
         p1lZaF2bE48wxWBNGQloiz6hwokqVxz/UWIgJlbSsnCa1nFuSua0jZIeUOtsxxlpwdr7
         cHObhrRnSb6bhQz+cypUEZqeHiunvoOZk0djVyJQd2Xg4qStfA4vLAPfZFfaPpQUWXeF
         pMdQ==
X-Forwarded-Encrypted: i=1; AJvYcCWfIzbtYar6zUFzTZV3aSuVdMyyhgh1u/GzEXWa3vf13ALyGrpM7BqT1zc641K8y5AZNBe8+oH+8nQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwxsOXj0ZKHyGvP+Mk9R/FhFs6TKLOgY0z/RFOd3KdjDbdtsQA9
	XdSlKYA1m07CCleeU6KcEefRtWj3RvpF0LMKgC/pmp/fFn7fVZlE5OrR1FGMiA==
X-Gm-Gg: ASbGncsUjaj3eTvVmAWJHzOlx2Dyc5vd2hKu8c6C38Z454d94PdjZNr6WkU+Wps3vkR
	5u49vqYBcNXZFaqLAJ/vkksgxXqiFr60nLjmpwNu4yKCFwe516+3Om4pUCfUyP5X6koS9ErLM3G
	/7CS0TGASltBRD1e0+RQXLN+WREzOYgFp+k9uSh+W60hkB4e5nnWKuVjC3a9e1lYGQ1263Oak4M
	oO9+gJeTEFD6s1/05CgI8hJMHKX4N8rIsrAR3ZfORq4i9MQw2qpRTGZVMTcFFc20lCnrffclKdf
	JKG45imwlhjOncFHq0NoK1JsSuqmdw0yguVs3SGwND3LWusH29XQc7aQJBvIyYCu2kRkUNDHT1m
	VE7UBjDTeOlPYRWDllWoRXpdqc1v/CECWeFJu
X-Google-Smtp-Source: AGHT+IHFPVHYpTk15GgH+3kiy9gG5IO5Z7h0Q61qN8gI2xntgB2WuwXVftSuoyjLb1aKSZF/Ln0w7w==
X-Received: by 2002:a17:907:c003:b0:ad2:40e0:3e56 with SMTP id a640c23a62f3a-ad4f74d3f1amr6499266b.57.1747152058045;
        Tue, 13 May 2025 09:00:58 -0700 (PDT)
Message-ID: 
Date: Tue, 13 May 2025 18:00:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/16] xen/riscv: introduce support of Svpbmt extension
To: Oleksii Kurochko 
Cc: Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , 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

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> Svpbmt extension is necessary for chaning the memory type for a page contains
> a combination of attributes that indicate the cacheability, idempotency,
> and ordering properties for access to that page.

The title suggest use of the extension is optional.

> --- a/xen/arch/riscv/Kconfig
> +++ b/xen/arch/riscv/Kconfig
> @@ -10,11 +10,25 @@ config RISCV
>  config RISCV_64
>  	def_bool y
>  	select 64BIT
> +	select HAS_SVPBMT

Such redundant ...

>  config ARCH_DEFCONFIG
>  	string
>  	default "arch/riscv/configs/tiny64_defconfig"
>  
> +config HAS_SVPBMT
> +	bool
> +	depends on RISCV_64

... dependencies are frowned upon, afaik. And it's pretty certainly not
needed here.

> +	help
> +	  This config enables usage of Svpbmt ISA-extension ( Supervisor-mode:
> +	  page-based memory types).
> +
> +	  The memory type for a page contains a combination of attributes
> +	  that indicate the cacheability, idempotency, and ordering
> +	  properties for access to that page.
> +
> +	  The Svpbmt extension is only available on 64-bit cpus.

I don't mind the help text, but for a prompt-less option it's of little
use (beyond what a comment could also achieve).

> --- a/xen/arch/riscv/include/asm/page.h
> +++ b/xen/arch/riscv/include/asm/page.h
> @@ -46,6 +46,8 @@
>  #define PAGE_HYPERVISOR_RX          (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE)
>  
>  #define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
> +#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PMBT_IO)
> +#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PMBT_NOCACHE)

Hmm, odd - NOCACHE doesn't really mean "no cache" then? I think this
would require a comment then.

> @@ -56,8 +58,21 @@
>  #define PTE_SMALL       BIT(10, UL)
>  #define PTE_POPULATE    BIT(11, UL)
>  
> +/*
> + * [62:61] Svpbmt Memory Type definitions:
> + *
> + *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
> + *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> + *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> + *  11 - Rsvd   Reserved for future standard use
> + */
> +#define PTE_PMBT_NOCACHE    BIT(61, UL)
> +#define PTE_PMBT_IO         BIT(62, UL)

Unlike PTE_SMALL and PTE_POPULATE these are arch-defined; I think they
want to move up to where the other arch-defined bits are, thus also
maping them appear before their first use.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 16:09:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 16:09:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983111.1369465 (Exim 4.92)
	(envelope-from )
	id 1uEsC8-0001rR-9Z; Tue, 13 May 2025 16:09:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983111.1369465; Tue, 13 May 2025 16:09: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 1uEsC8-0001rK-6W; Tue, 13 May 2025 16:09:28 +0000
Received: by outflank-mailman (input) for mailman id 983111;
 Tue, 13 May 2025 16:09:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEsC7-0001rE-4Z
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 16:09:27 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a38c8a46-3014-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 18:09:25 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad1a87d93f7so885480966b.0
 for ; Tue, 13 May 2025 09:09: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
 a640c23a62f3a-ad2197bd2c0sm798346566b.130.2025.05.13.09.09.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 09:09: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" 
X-Inumbo-ID: a38c8a46-3014-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747152564; x=1747757364; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+EF/B3R6fhMuYybsaftITDkJqLfXGKGTJ0TR54IzNfQ=;
        b=B6oxkMSbrhy2ylK7y2EYUbhnbGvEd1a7H5AzHTZdpgttk4s1sUTC5I5BzTAjJ/O3vL
         nY6HTDBtaHlTfM9dHpGMK8hwKsyFH2fqTUdqIyq3uMtX894+GvIKICt38MCWF810CTCr
         CfZgxAhwF9D3//tnoToqI+7ioZIPnb1Zy7faajIikeRA3aLsD2MhMfqvLbpzdBnSnHGc
         5fxF7PuQSBpzEvuQSZM3ls8jjnlgWkZhwCfq9Ka5oHOo4uOszFjKpTO4Y31nkwHcwxb3
         vqJtQRF4zA/67XXOD3qzsftBSx15VXQw5TYWukFc5rr1MynPFVf6Xo92R1cH9xesscIX
         nIlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747152564; x=1747757364;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+EF/B3R6fhMuYybsaftITDkJqLfXGKGTJ0TR54IzNfQ=;
        b=hweiD8b2vXZH5BFpyKdz1mwpEwLukpzGGN9esGqYwFlpepkAEr8KLGfeMR/gFjHyx6
         EywWcr4KgzN0a+OgQk5i5msRls3NXUimUURIShbniXhbkc2gN5+hb8+K1jhY5mNgpIGg
         Vpsw+ImjXR4xZAK/517AImCh1h9DqJRHMcCf+Vfri3Ie5+DcYiFfKFkZFLVnwiTr882z
         xGcTiOLToQ2IWVBb+wdYxP4jyVGErQxOI6e/ry6zGF8bAxUbz5LZbmJjI+2PQZm+mtef
         oNbhkWmOIOElLZUc+KIxFFOyjARsj72Y59c2pheVB0+7FMocpSWHPz/ZldsrDx8RA7Tp
         EQzA==
X-Forwarded-Encrypted: i=1; AJvYcCU1Av9VU2iKA7J+45L05FkAsG1YdEfeOu/5O10vmxAwo6ilUxSvP3xE9pH77o8jplpMQc3i/FzjnTY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YydUomdtho0eLT7PP0RyOYslfe4q/BGd0eoJ8Mnkof3V8Gztv/w
	mhC1zCRayZMGOf3OMY1BvwWlLfF2IQrE8dYzlX//uunJGqG+vbbviRVk0Bb6hg==
X-Gm-Gg: ASbGncuj2gcRtpfzbSbDFBLpIkZwvN+XF+ZZdLDqI/6eGV/B9sEna+46SL9pVzhMLmR
	YdYih7uNPA0VPM319TzGjcxOe6iryYm8Fqav7klSh72I6O7aY7aFwqREGpjnHOieRC1Ces/NhLW
	Gx/xaCLMbhCVosrMp9Czd5QIK/oagWGAFbqFIk5IkIZ9miLuAaZ1ZqlSOsN5Tmgzucm15GDfScJ
	9HKABCic8+ZsrfbZyEJhNsFdAnc8K9PCYarF/HOaSNpHiYNKsCbKbDH1W0gY0FenQ4pLhIUMrCk
	pflsW9I6CWP2V9dzETBSLq0BKWTOWgJmpsE4rf//FrMcDUdZHapztUnZlEyn5IVezkljlIt0miy
	KRY+CXxj4xzDiqqNW8JqkbecW+JywR6i/hPr9
X-Google-Smtp-Source: AGHT+IFPpu4pfQ5TpO7rV+E6nGI8SR/dPtvjKtLLetPlJSSudg6HOgJZ/7VLC1Ml+Lxr6aSgzKLY1Q==
X-Received: by 2002:a17:906:6207:b0:ad2:5499:75a1 with SMTP id a640c23a62f3a-ad4f715873cmr14568266b.32.1747152559332;
        Tue, 13 May 2025 09:09:19 -0700 (PDT)
Message-ID: <9575eb5b-d789-4430-aafa-0b8fc5070952@suse.com>
Date: Tue, 13 May 2025 18:09:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] Add lockdown mode
To: Kevin Lampis 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
References: <20250506162510.1676425-1-kevin.lampis@cloud.com>
 
 
 <504f0be0-91fd-4847-8fcd-505771674814@suse.com>
 
 <55e73266-7727-4a1c-93e8-dd69712d64d2@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

On 13.05.2025 17:59, Kevin Lampis wrote:
> On Tue, May 13, 2025 at 3:32 PM Jan Beulich  wrote:
>>
>> Well, it's easily possible to catch that error without any extra parsing.
> 
> If `lockdown` is not the first argument then we should print a warning
> to tell the user that Xen may have already parsed some insecure
> arguments and lockdown mode will not be effective.
> 
> What would be a good way to check if lockdown is or isn't the first
> argument? I am not sure.

It'll be a little hack-ish, I suppose (yet the option is quite special,
after all), but I can see various options. For example, have the resulting
variable not be boolean, and OR in a separate flag after parsing the first
option. Then warn if the flag is clear after all options were parsed.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 13 17:01:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:01:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983130.1369475 (Exim 4.92)
	(envelope-from )
	id 1uEt0Z-00019Q-QU; Tue, 13 May 2025 17:01:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983130.1369475; Tue, 13 May 2025 17:01: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 1uEt0Z-00019J-N9; Tue, 13 May 2025 17:01:35 +0000
Received: by outflank-mailman (input) for mailman id 983130;
 Tue, 13 May 2025 17:01:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt0Y-00019D-RJ
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:01:34 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20619.outbound.protection.outlook.com
 [2a01:111:f403:2418::619])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eb172148-301b-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:01:32 +0200 (CEST)
Received: from MW4PR04CA0077.namprd04.prod.outlook.com (2603:10b6:303:6b::22)
 by IA0PPF8FC6E1236.namprd12.prod.outlook.com
 (2603:10b6:20f:fc04::bda) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.31; Tue, 13 May
 2025 17:01:27 +0000
Received: from SJ5PEPF000001CD.namprd05.prod.outlook.com
 (2603:10b6:303:6b:cafe::7d) by MW4PR04CA0077.outlook.office365.com
 (2603:10b6:303:6b::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Tue,
 13 May 2025 17:01:26 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001CD.mail.protection.outlook.com (10.167.242.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Tue, 13 May 2025 17:01:26 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 13 May
 2025 12:01:26 -0500
Received: from [172.31.225.170] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 13 May 2025 12:01: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" 
X-Inumbo-ID: eb172148-301b-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=F3jAyDo38JUsnmTZJ0ZXPUmQ+MRZpQxnDEvffTrI4A6fM204jiqd6OhWrtlFFc9hjP1fRpz0Gd+8OXkNf+c+hHrBYTMZ9zOhj4M/GTe3H7B/0dVUJF4/7zGIvwznaYLC19lpWeWIwvfj8i9cJyHGRYuNiFC+yNR+hROk8TxWhisQz2A6Vv1lGPqXLjYC7bjPKHaqJwh41GTHkXouZXJfAVxtBwQdO3nbJVf4VZS6Tx4Rz1AMl/4cQFmFa3WaOmurk4qw6Y+W2aYt2H022htsOlCXRPBexJPL9jWU88vTJ3h/G8UlTrOXx7B9BXLj988Jqk2jIzTNT3NJuR2AbdLu8Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=30MnAZhpTp4Df94mweho2LyHvUayV6y9u7bd0wWM2WA=;
 b=W7RRGS6ButxoP/TxJ/X/pq7MdNdA3p6afjwBkvHlDgpAtFI3gNdET0F4yg8hZZUs1fOrzDlmBx8qnF+3LTPDYzX7R2FqIiRvQUqTtV+tKwue6m5CwORkAaBycVhBvWBfXhBWTVoi6dbZ16l62R+8XvzHlU7Cc0Yp0IisFCXftevHpUgwQpeHqK9yamHhdkPxsrqgq9Jdb6S9DORqHc9HhKNRiLRzvG2QF1nK/+LrXAKyIfh52J8CmXN2czPJIlroFAN0LF99c4ZRLjQ3mFiVckiL1E6++GdLCnCTAuF0hzFSBP2vgCfpmfZ5s6+rgCP9EJFdLxGpB/zxoQrqP0DSpQ==
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=30MnAZhpTp4Df94mweho2LyHvUayV6y9u7bd0wWM2WA=;
 b=J3nxZiQEsrOuSbK7tbo+7uu4Gl9u1Blo1sajuTDF5kyM3uI4HHWemhRdKbZgcPoUzFLEGBad54CLW5qYDvhg2sCN+biH4o6WPCiUzxViU9R1wLJssJLOEVvgofCw8Mt8NUP0rgSvo8ud9yalTknWr46Bbs7HPgO6UK4/4T+73zo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <914a4bc2-aa18-478f-b175-b89b56beaf3b@amd.com>
Date: Tue, 13 May 2025 13:01:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/6] rangeset: introduce rangeset_subtract
To: Jan Beulich , Stefano Stabellini
	
CC: Andrew Cooper , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	, 
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
 <20250508132040.532898-5-stewart.hildebrand@amd.com>
 <46dfb68b-7e94-40a8-9900-883ac899346e@suse.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <46dfb68b-7e94-40a8-9900-883ac899346e@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CD:EE_|IA0PPF8FC6E1236:EE_
X-MS-Office365-Filtering-Correlation-Id: 876c5b43-482c-449f-cb62-08dd923fcc78
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZExYd3FFb3J0czlBaktMOEw1SThERytxNjU3cHVIVnQzTzFiUUdLYVhJY3Iv?=
 =?utf-8?B?cW8xKzZ4TjVRMDlNOW1TS1VqV2s4L2UzMDdXSG9Zd0FMdnNoaURzRHc1b3RZ?=
 =?utf-8?B?Y2ZidXUvOG1NTktsMUxJdklVM0o1QWs1dmVyQVBkeVhRaFBJSmZNNlBSTHNk?=
 =?utf-8?B?UTBObzZycHNjdWRqaTh3YVhDbmdvbC9JalMvcXpSZ0NtSkxWbVNYSXhjYzJS?=
 =?utf-8?B?Mm9Ja0ZBM1k2dG1jZjg0Z09wWkc1dXlhNUZ6QzZCemdHcW9jRkdTTFc3Z0ZJ?=
 =?utf-8?B?czhUNXk3Y3pTTm55N0VmNGg2cDRQK2hielZ2Qll1aG54VHpFOE9iWHpubVRm?=
 =?utf-8?B?bHNmVlZ5bGR0b1JHcm5JVDdubmJvdE1jTmx3WUpHT0xueUwwaHNXLzRtdUY3?=
 =?utf-8?B?cTRVU0hEOUhncGRLbG4zOW1xa3UxVUtDaVpqb3creG1pVm56NlFIa2tjTUk2?=
 =?utf-8?B?UmFGeEtmOVkvVDVkY21jTmp2ZWVvc2lZdnhOL3dVKzlUalZOdmFYUXZUc2o1?=
 =?utf-8?B?Sk9LNEVxMDlkUmVBREt4TjRTWVBwUDlQT2dtZTFXYk9SRDdZQnVJOElCdk0r?=
 =?utf-8?B?T3ovNVlmS2ZFS1FUak1VOTZWYndUSWM2bCtCcUI0Y2xhMDBSN25sQk55bi9R?=
 =?utf-8?B?eTkrTGFKQzRUWEhESC9FbENNaWVRRzNjT1plZVAvb0VlejR5bUdtRlRRcHRK?=
 =?utf-8?B?Ukd2YXkvTGNuUTdKOXE2V1ZROUN6WWFaTG41a3Qvc0E5RXV1OWo4MmJHMTY2?=
 =?utf-8?B?aTFmL3NtcWtvRkpkVndGT2QwMWs1QkRUWjVJa2dLd1dKZlBLOS9GeTRjNUxJ?=
 =?utf-8?B?Um5lUzB4V0xkMEp6eWQwRm1kYThxWnhsY0t6MWNkVU1GZ3E0cGNvdHJ5QVZQ?=
 =?utf-8?B?RERoTjROaE5aaGVhL3FSYzlCY01ieUxWM3M4V0NJVm42d0FRVzJGOHFFeWNF?=
 =?utf-8?B?NEVZRWoxSVVFY1B0MXlrdDhsdjZOREd5WGtJZHBaRHZiUzZueUF6NzRLNkFh?=
 =?utf-8?B?aU1sMCt2blNncit5azZ1WWN6YVZFQ0NKU2FtcFNOK0g0WkQyYVNvQVJpL0pI?=
 =?utf-8?B?NEplYm8wQUlBMUFFUzVXbktMYzZqd1M2T0hjOGkxQkVXaEdQN2ZDaGtyK2VP?=
 =?utf-8?B?ckNSNVk1dko3NndtUHJ3Y3NQcURLQ2E2Q3ZIZENzMFdmSXVicTlGZDYvV1Qy?=
 =?utf-8?B?U1ZGelk1VjRSZjV4RGdIOWJRcnFObXRob09BemtZa2RKa2U3TkovYTU3VEJR?=
 =?utf-8?B?WFN2YVE3ckZscFlLelpyUWk5bTN6anlWcEdzbThwU00xemorODhRMVYyamhy?=
 =?utf-8?B?VG9RZnhKcDEzUWJxSjNWdldzMzhEYVZuV2k3alhjVGZ5RFdUSjNFZnZHMDJr?=
 =?utf-8?B?MDdDTVk4NW92N2c4L1V4cUVyUVBXa1gxSTNEZEF3eEVQYjlEK3Z0N0dGdU9G?=
 =?utf-8?B?UjBhOFd1VC9JVHZUVFpUUjNLdTdnVFF6NHVxUEdiWFFSQkZRMW56MVFYMW14?=
 =?utf-8?B?M1V0eDNpSDNxS1NWZXNIVnRWdTB1ejdwRHlDVmlJbEc5Y3VOc3hVR2lCVnMw?=
 =?utf-8?B?K2F2NS9acnludzVEMElUNDBaMEYyNStVWHpPbjFDQlJmN1Ixak0rYW5IZkJW?=
 =?utf-8?B?L0NUUkhJYWpBRU9YQVl0WTVrSEFjcTJmdmZOZCtnbHlMclc1ek42QnYwTGU5?=
 =?utf-8?B?eTJtTDREejhPUUtvM1pmb3p6bUtuWnhSSTJIMklWNXZ0SytESURWYVRNWlMz?=
 =?utf-8?B?aDBJcGJQYUFtRWZpb2FhUG5qZHlwbUtibzZxeFhhc3N2T1VibDM3OVVXUzU4?=
 =?utf-8?B?YW1OVGFvc1hZYVZVOHJoUmh4VzZWOFBPMjN0NkIrK21GUUsvVFRpRnN6N2NG?=
 =?utf-8?B?VlkxdTZLeVFlbDlLMk80R2tNTElzanp5ZS96azB6OVhjOEE1c29FdjJ5OFhW?=
 =?utf-8?B?REIvcU9IaktwWnZ6SFZDTy9YMHZoSm8wdkRUR01TclJsWnlZaTBIdUduRk4v?=
 =?utf-8?B?MXh4aUdubTdnPT0=?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2025 17:01:26.6188
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 876c5b43-482c-449f-cb62-08dd923fcc78
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001CD.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF8FC6E1236

On 5/13/25 11:39, Jan Beulich wrote:
> On 08.05.2025 15:20, Stewart Hildebrand wrote:
>> --- a/xen/common/rangeset.c
>> +++ b/xen/common/rangeset.c
>> @@ -397,6 +397,18 @@ int rangeset_merge(struct rangeset *r1, struct rangeset *r2)
>>      return rangeset_report_ranges(r2, 0, ~0UL, merge, r1);
>>  }
>>  
>> +static int cf_check subtract(unsigned long s, unsigned long e, void *data)
>> +{
>> +    struct rangeset *r = data;
>> +
>> +    return rangeset_remove_range(r, s, e);
>> +}
>> +
>> +int rangeset_subtract(struct rangeset *r1, struct rangeset *r2)
>> +{
>> +    return rangeset_report_ranges(r2, 0, ~0UL, subtract, r1);
>> +}
> 
> I understand this was committed already, but I don't understand why: This
> introduces a Misra rule 2.1 violation aiui. The rule isn't tagged as clean
> yet, but it was accepted and hence I thought we would strive towards not
> introducing new violations. What's the deal?
> 
> Jan

The very next patch (also committed) makes use of the function, so the
series as a whole did not introduce a violation. Our code review
guidelines still say to organize new independent helper functions into
logically separate patches [0]. To be clear, and for future reference,
would your expectation be to squash the introduction of the helper
function into the patch where it's used? Perhaps we ought to finally
update the code review guidelines...

[0] https://xenbits.xenproject.org/governance/code-review-guide.html


From xen-devel-bounces@lists.xenproject.org Tue May 13 17:03:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:03:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983137.1369485 (Exim 4.92)
	(envelope-from )
	id 1uEt2r-0001ez-5f; Tue, 13 May 2025 17:03:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983137.1369485; Tue, 13 May 2025 17:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEt2r-0001es-2e; Tue, 13 May 2025 17:03:57 +0000
Received: by outflank-mailman (input) for mailman id 983137;
 Tue, 13 May 2025 17:03:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt2p-0001em-Ti
 for xen-devel@lists.xen.org; Tue, 13 May 2025 17:03:55 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3f61f8f5-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:03:53 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-43cf06eabdaso58467385e9.2
 for ; Tue, 13 May 2025 10:03:53 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442cd3b7dd5sm215452485e9.35.2025.05.13.10.03.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 10:03: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" 
X-Inumbo-ID: 3f61f8f5-301c-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747155832; x=1747760632; darn=lists.xen.org;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to;
        bh=CdiKmgPiB83vyJbNLyqD6vCzUOha0hDNrkNpiC/2CX8=;
        b=AQ27NaMJkxHF59O1egyWODt37+j7G6HBrm1MMp2X+9j5NEap+Z4rsIO9l+TY+eJzrb
         nTO38jIqWCQY+NIqGYCXBE7fF/r0EZegPAktimt3keZUuIn3vbhgYGZZQLxM22ns2GXq
         3ABiMN2kw9tTg9uaAUI8rtBTQOsf4nIgbx7eI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747155832; x=1747760632;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=CdiKmgPiB83vyJbNLyqD6vCzUOha0hDNrkNpiC/2CX8=;
        b=CdTTfgTljN/WfM6Xa+pxdTfKxSV/4eg4bXoQos55+90J+T3EZDknr+XH1ebBbhBLXH
         bXu5lMfywgEL/Kzf93E6sphKCCYVvv9cr6mqhsqnufpGrZm3xi8S57CZ9j/ZN7tu8XrX
         M53UhsecqyK48t6AiIDlZk+XipsPXkuFseFz1VPWcUBaBuWmZinvHR+l8vwPO2ljx0zj
         jSPrgeB1hjoJz0Gc07EIngxr6ltARp2oIAzroGC3b959dz6+w3/3o6CQa0Ogbjhm3H9M
         eY/yRiSTJTw0mryjnjZdNrNE9ColufTP9IyFlytUOfplzPSkRpv6R8AcX5+tRLlwdW5g
         iZ4w==
X-Forwarded-Encrypted: i=1; AJvYcCW6dByw8u1yvwFAN1FhMJVSJobBcJGiP1bZ1CR1DvWTstte8s+3KbKTepqbA6Lz0svyxUokfYxZEqE=@lists.xen.org
X-Gm-Message-State: AOJu0YyLUR4FI7MwKzT5XMTNeoesaXRaqoiiQLpg7+hX9BzFe5YQxq8N
	FIUFg5e149hANHlewD3sSIQbPCBAyXuR0OTOMqu8iBXbC+4P0FbgOhAiDQeQ/WeTJqYYzCrZ1Dl
	d
X-Gm-Gg: ASbGncsFWpfO+u+EVP/pSRhhGG6bLSn9z+HtdXBabGPIf4vEK5/cYRWfrpgmjECZKDN
	T1GtugUciGayC8umZivp/8lc24bIBsLLIul1dOS78LiTeA748rFpoDMQV5ByyjOQsnvwu0B3f4T
	ybD5Y57faF85yGqF5j3yAcROz4ibf82tL1Q0FRGpd7BVVVTmKm7NpDPni/a5jcb7gqUbaINH3v2
	UlgTj/6bWCFPVQncCrcfwcBZ+uDNCCjUghhFX3ORsySLNSFrUTsPrteDS6sFSWuepMiHC/TV+/3
	QOHAhNyUrFqW2hEtwjv67jrAdGqyi5AsLLSfOgaqQYDjw4bNXeTyjyYEEnMWOHphjiHXtPgnWxB
	V5eFbNnRxVhja6l69
X-Google-Smtp-Source: AGHT+IFsHFUoejrqrNdXTxQcPHJd+q6q34anRsCYXGuSkQdKkx7aDqCHjt0t1A7Bq6ooEOFq8jkq5A==
X-Received: by 2002:a05:6000:2907:b0:39c:1429:fa57 with SMTP id ffacd0b85a97d-3a34968fc0emr71795f8f.3.1747155832320;
        Tue, 13 May 2025 10:03:52 -0700 (PDT)
Message-ID: <6ff1387d-6577-455d-8a1a-0dee04907b1c@citrix.com>
Date: Tue, 13 May 2025 18:03:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: "xen-announce@lists.xen.org" ,
 Xen-devel ,
 "xen-users@lists.xen.org" ,
 "oss-security@lists.openwall.com" 
Cc: "Xen.org security team" 
From: Andrew Cooper 
Subject: Xen Security Notice 3 (CVE-2024-45332) Intel Branch Privilege
 Injection
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==
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Researchers from ETH Zurich have discovered Branch Privilege Injection,
a bug in hardware prediction-domain isolation whereby an attacker can
cause predictions to be tagged with the wrong mode/privilege, and then
use the incorrectly-tagged predictions to mount traditional Spectre-v2
attacks.

For more details, see:
https://comsec.ethz.ch/bprc
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01247.html

Intel are releasing microcode to address as part of IPU 2025.2.  There
are no software mitigations available.

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20250512

~Andrew, on behalf of the Xen Security Team.


From xen-devel-bounces@lists.xenproject.org Tue May 13 17:06:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:06:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983183.1369542 (Exim 4.92)
	(envelope-from )
	id 1uEt5K-000445-Pn; Tue, 13 May 2025 17:06:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983183.1369542; Tue, 13 May 2025 17: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 1uEt5K-00043v-Mu; Tue, 13 May 2025 17:06:30 +0000
Received: by outflank-mailman (input) for mailman id 983183;
 Tue, 13 May 2025 17:06:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5I-0003Mm-Lt
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:28 +0000
Received: from 13.mo561.mail-out.ovh.net (13.mo561.mail-out.ovh.net
 [188.165.33.202]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9b8e4925-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:06:27 +0200 (CEST)
Received: from director8.ghost.mail-out.ovh.net (unknown [10.109.148.6])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjYb1mMMz1ZyR
 for ; Tue, 13 May 2025 17:06:27 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-z24qs (unknown [10.110.96.237])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 840131FD17;
 Tue, 13 May 2025 17:06:26 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.95])
 by ghost-submission-5b5ff79f4f-z24qs with ESMTPSA
 id i0RNERJ8I2hrPQEA8ZxQ9w
 (envelope-from ); Tue, 13 May 2025 17:06: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" 
X-Inumbo-ID: 9b8e4925-301c-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-95G00170b9feb2-8969-4951-a267-a939df1fc2a3,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 02/22] include/xen/slr-table.h: Secure Launch Resource Table definitions
Date: Tue, 13 May 2025 20:05:39 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8940489685544711324
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpefhheefheduieelieekfffgfffgfedutdevleevvdfhfffgledvgfdtuddtheefieenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddrleehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheeiudgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=0z3fwA1ZiActkXXZVasH701JMmtlynrh9xlUCyNcoc8=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747155987; v=1;
 b=kKUfQ1/1trEM7JDlOS6HueY16NOnBQBwG8rbylvwQk4KPVuXA5AJnOJ+M0J9R0Hve4F2yg+V
 Y511c3GnN4HkRcL3YgLKzuREMx/dddB4YpaqXBD3zRlm1OfIB7a4sGV0hp99o+5TiEzWoafBTHQ
 aGax2gWId66WQ1ZlqGBUNjF5VQFdxtuwoFC39OOHun2l3vuOPTsEbela+GL7D0VM0835sK/krVI
 yDTYAb8e5NiNZd723cCy+5QtIBpUHUQYkm4HtKm8JFfHJd/nMg8E/+EFCmtfL3pKUEO9XdOajls
 A7c5i7T4XIFX2syUjhUhBnL1WLsCkLX79MABZZpiLet+g==

The file provides constants, structures and several helper functions for
parsing SLRT.

Signed-off-by: Ross Philipson 
Signed-off-by: Sergii Dmytruk 
---
 xen/include/xen/slr-table.h | 268 ++++++++++++++++++++++++++++++++++++
 1 file changed, 268 insertions(+)
 create mode 100644 xen/include/xen/slr-table.h

diff --git a/xen/include/xen/slr-table.h b/xen/include/xen/slr-table.h
new file mode 100644
index 0000000000..6f0018bceb
--- /dev/null
+++ b/xen/include/xen/slr-table.h
@@ -0,0 +1,268 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ *  Copyright (c) 2025 Apertus Solutions, LLC
+ *  Copyright (c) 2025 Oracle and/or its affiliates.
+ *  Copyright (c) 2025 3mdeb Sp. z o.o
+ *
+ *  Secure Launch Resource Table definitions
+ */
+
+#ifndef XEN__SLR_TABLE_H
+#define XEN__SLR_TABLE_H
+
+#include 
+
+#define UEFI_SLR_TABLE_GUID \
+    { 0x877a9b2aU, 0x0385, 0x45d1, { 0xa0, 0x34, 0x9d, 0xac, 0x9c, 0x9e, 0x56, 0x5f } }
+
+/* SLR table header values */
+#define SLR_TABLE_MAGIC         0x4452544d
+#define SLR_TABLE_REVISION      1
+
+/* Current revisions for the policy and UEFI config */
+#define SLR_POLICY_REVISION         1
+#define SLR_UEFI_CONFIG_REVISION    1
+
+/* SLR defined architectures */
+#define SLR_INTEL_TXT   1
+#define SLR_AMD_SKINIT  2
+
+/* SLR defined bootloaders */
+#define SLR_BOOTLOADER_INVALID  0
+#define SLR_BOOTLOADER_GRUB     1
+
+/* Log formats */
+#define SLR_DRTM_TPM12_LOG      1
+#define SLR_DRTM_TPM20_LOG      2
+
+/* DRTM Policy Entry Flags */
+#define SLR_POLICY_FLAG_MEASURED    0x1
+#define SLR_POLICY_IMPLICIT_SIZE    0x2
+
+/* Array Lengths */
+#define TPM_EVENT_INFO_LENGTH       32
+#define TXT_VARIABLE_MTRRS_LENGTH   32
+
+/* Tags */
+#define SLR_ENTRY_INVALID       0x0000
+#define SLR_ENTRY_DL_INFO       0x0001
+#define SLR_ENTRY_LOG_INFO      0x0002
+#define SLR_ENTRY_DRTM_POLICY   0x0003
+#define SLR_ENTRY_INTEL_INFO    0x0004
+#define SLR_ENTRY_AMD_INFO      0x0005
+#define SLR_ENTRY_ARM_INFO      0x0006
+#define SLR_ENTRY_UEFI_INFO     0x0007
+#define SLR_ENTRY_UEFI_CONFIG   0x0008
+#define SLR_ENTRY_END           0xffff
+
+/* Entity Types */
+#define SLR_ET_UNSPECIFIED        0x0000
+#define SLR_ET_SLRT               0x0001
+#define SLR_ET_BOOT_PARAMS        0x0002
+#define SLR_ET_SETUP_DATA         0x0003
+#define SLR_ET_CMDLINE            0x0004
+#define SLR_ET_UEFI_MEMMAP        0x0005
+#define SLR_ET_RAMDISK            0x0006
+#define SLR_ET_MULTIBOOT2_INFO    0x0007
+#define SLR_ET_MULTIBOOT2_MODULE  0x0008
+#define SLR_ET_TXT_OS2MLE         0x0010
+#define SLR_ET_UNUSED             0xffff
+
+/*
+ * Primary SLR Table Header
+ */
+struct slr_table
+{
+    uint32_t magic;
+    uint16_t revision;
+    uint16_t architecture;
+    uint32_t size;
+    uint32_t max_size;
+    /* entries[] */
+} __packed;
+
+/*
+ * Common SLRT Table Header
+ */
+struct slr_entry_hdr
+{
+    uint32_t tag;
+    uint32_t size;
+} __packed;
+
+/*
+ * Boot loader context
+ */
+struct slr_bl_context
+{
+    uint16_t bootloader;
+    uint16_t reserved[3];
+    uint64_t context;
+} __packed;
+
+/*
+ * Prototype of a function pointed to by slr_entry_dl_info::dl_handler.
+ */
+typedef void (*dl_handler_func)(struct slr_bl_context *bl_context);
+
+/*
+ * DRTM Dynamic Launch Configuration
+ */
+struct slr_entry_dl_info
+{
+    struct slr_entry_hdr hdr;
+    uint64_t dce_size;
+    uint64_t dce_base;
+    uint64_t dlme_size;
+    uint64_t dlme_base;
+    uint64_t dlme_entry;
+    struct slr_bl_context bl_context;
+    uint64_t dl_handler;
+} __packed;
+
+/*
+ * TPM Log Information
+ */
+struct slr_entry_log_info
+{
+    struct slr_entry_hdr hdr;
+    uint16_t format;
+    uint16_t reserved;
+    uint32_t size;
+    uint64_t addr;
+} __packed;
+
+/*
+ * DRTM Measurement Entry
+ */
+struct slr_policy_entry
+{
+    uint16_t pcr;
+    uint16_t entity_type;
+    uint16_t flags;
+    uint16_t reserved;
+    uint64_t size;
+    uint64_t entity;
+    char evt_info[TPM_EVENT_INFO_LENGTH];
+} __packed;
+
+/*
+ * DRTM Measurement Policy
+ */
+struct slr_entry_policy
+{
+    struct slr_entry_hdr hdr;
+    uint16_t reserved[2];
+    uint16_t revision;
+    uint16_t nr_entries;
+    struct slr_policy_entry policy_entries[];
+} __packed;
+
+/*
+ * Secure Launch defined MTRR saving structures
+ */
+struct slr_txt_mtrr_pair
+{
+    uint64_t mtrr_physbase;
+    uint64_t mtrr_physmask;
+} __packed;
+
+struct slr_txt_mtrr_state
+{
+    uint64_t default_mem_type;
+    uint64_t mtrr_vcnt;
+    struct slr_txt_mtrr_pair mtrr_pair[TXT_VARIABLE_MTRRS_LENGTH];
+} __packed;
+
+/*
+ * Intel TXT Info table
+ */
+struct slr_entry_intel_info
+{
+    struct slr_entry_hdr hdr;
+    uint64_t boot_params_base;
+    uint64_t txt_heap;
+    uint64_t saved_misc_enable_msr;
+    struct slr_txt_mtrr_state saved_bsp_mtrrs;
+} __packed;
+
+/*
+ * AMD SKINIT Info table
+ */
+struct slr_entry_amd_info
+{
+    struct slr_entry_hdr hdr;
+    uint64_t next;
+    uint32_t type;
+    uint32_t len;
+    uint64_t slrt_size;
+    uint64_t slrt_base;
+    uint64_t boot_params_base;
+    uint16_t psp_version;
+    uint16_t reserved[3];
+} __packed;
+
+/*
+ * UEFI config measurement entry
+ */
+struct slr_uefi_cfg_entry
+{
+    uint16_t pcr;
+    uint16_t reserved;
+    uint32_t size;
+    uint64_t cfg; /* address or value */
+    char evt_info[TPM_EVENT_INFO_LENGTH];
+} __packed;
+
+struct slr_entry_uefi_config
+{
+    struct slr_entry_hdr hdr;
+    uint16_t reserved[2];
+    uint16_t revision;
+    uint16_t nr_entries;
+    struct slr_uefi_cfg_entry uefi_cfg_entries[];
+} __packed;
+
+static inline void *
+slr_end_of_entries(struct slr_table *table)
+{
+    return (uint8_t *)table + table->size;
+}
+
+static inline struct slr_entry_hdr *
+slr_next_entry(struct slr_table *table, struct slr_entry_hdr *curr)
+{
+    struct slr_entry_hdr *next = (struct slr_entry_hdr *)
+                                 ((uint8_t *)curr + curr->size);
+
+    if ( (void *)next >= slr_end_of_entries(table) )
+        return NULL;
+    if ( next->tag == SLR_ENTRY_END )
+        return NULL;
+
+    return next;
+}
+
+static inline struct slr_entry_hdr *
+slr_next_entry_by_tag (struct slr_table *table,
+                       struct slr_entry_hdr *entry,
+                       uint16_t tag)
+{
+    if ( !entry ) /* Start from the beginning */
+        entry = (struct slr_entry_hdr *)((uint8_t *)table + sizeof(*table));
+
+    for ( ; ; )
+    {
+        if ( entry->tag == tag )
+            return entry;
+
+        entry = slr_next_entry(table, entry);
+        if ( !entry )
+            return NULL;
+    }
+
+    return NULL;
+}
+
+#endif /* XEN__SLR_TABLE_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:06:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:06:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983182.1369526 (Exim 4.92)
	(envelope-from )
	id 1uEt5H-0003cr-Co; Tue, 13 May 2025 17:06:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983182.1369526; Tue, 13 May 2025 17: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 1uEt5H-0003cM-9C; Tue, 13 May 2025 17:06:27 +0000
Received: by outflank-mailman (input) for mailman id 983182;
 Tue, 13 May 2025 17:06:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5F-0003Mm-Ve
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:26 +0000
Received: from 8.mo560.mail-out.ovh.net (8.mo560.mail-out.ovh.net
 [188.165.52.147]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 99f1d132-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:06:25 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.109.139.93])
 by mo560.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjYX3pjHz2Cc8
 for ; Tue, 13 May 2025 17:06:24 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-rfvwm (unknown [10.111.182.110])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 7816F1FD1D;
 Tue, 13 May 2025 17:06:23 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.109])
 by ghost-submission-5b5ff79f4f-rfvwm with ESMTPSA
 id MrzEDA98I2gRCwAAL8LKOQ
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: 99f1d132-301c-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-109S003822ad1ed-d2fa-42ec-900b-f5c186a334db,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Lukasz Hawrylko ,
	=?UTF-8?q?Mateusz=20M=C3=B3wka?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and accessors for TXT registers and heap
Date: Tue, 13 May 2025 20:05:38 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8939645263790388380
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpefhheefheduieelieekfffgfffgfedutdevleevvdfhfffgledvgfdtuddtheefieenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddruddtleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehiedtmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=2RbMwstbyyOU4TxQ7vyGzM7EFTqaGpSH29ZxUCa59fk=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747155984; v=1;
 b=NSA+fs3aROk+AtkBhXfQ4O3gp2O/hdfYc2sqrYiBx6Xh+EVCjArqOSmbMGT2SmM/atXFwOv1
 eNY1kfDQrznxJ7wf5gK/ZYXP8d+xUYm9Csi+5f+gcbTXgf8n+DjFqiytdKf4yRJhi0HEXrxe2ds
 utXV/cl+pAJpNs7iSiaRPEmvZExRMabceQLMkCRbB8L5yDNbM7uCRYbatZpNxUJWvc0fN7741Oh
 SvpiCNaserWyUShopMa57f8wdQ9GaWvyVSS629Pf6A0l59Zc12wWwOP98WpEueLPaAAI5yeHqwr
 9hmopJ1rZcgE/0iii3PbGbQ+VTsGp1rOHSayk/z7OasfQ==

From: Krystian Hebel 

The file contains TXT register spaces base address, registers offsets,
error codes and inline functions for accessing structures stored on
TXT heap.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/include/asm/intel-txt.h | 277 +++++++++++++++++++++++++++
 xen/arch/x86/tboot.c                 |  20 +-
 2 files changed, 279 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/intel-txt.h

diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
new file mode 100644
index 0000000000..07be43f557
--- /dev/null
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -0,0 +1,277 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef ASM__X86__INTEL_TXT_H
+#define ASM__X86__INTEL_TXT_H
+
+/*
+ * TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
+ */
+#define TXT_PUB_CONFIG_REGS_BASE        0xfed30000U
+#define TXT_PRIV_CONFIG_REGS_BASE       0xfed20000U
+
+/*
+ * The same set of registers is exposed twice (with different permissions) and
+ * they are allocated continuously with page alignment.
+ */
+#define NR_TXT_CONFIG_SIZE \
+    (TXT_PUB_CONFIG_REGS_BASE - TXT_PRIV_CONFIG_REGS_BASE)
+
+/* Offsets from pub/priv config space. */
+#define TXTCR_STS                       0x0000
+#define TXTCR_ESTS                      0x0008
+#define TXTCR_ERRORCODE                 0x0030
+#define TXTCR_CMD_RESET                 0x0038
+#define TXTCR_CMD_CLOSE_PRIVATE         0x0048
+#define TXTCR_DIDVID                    0x0110
+#define TXTCR_VER_EMIF                  0x0200
+#define TXTCR_CMD_UNLOCK_MEM_CONFIG     0x0218
+#define TXTCR_SINIT_BASE                0x0270
+#define TXTCR_SINIT_SIZE                0x0278
+#define TXTCR_MLE_JOIN                  0x0290
+#define TXTCR_HEAP_BASE                 0x0300
+#define TXTCR_HEAP_SIZE                 0x0308
+#define TXTCR_SCRATCHPAD                0x0378
+#define TXTCR_CMD_OPEN_LOCALITY1        0x0380
+#define TXTCR_CMD_CLOSE_LOCALITY1       0x0388
+#define TXTCR_CMD_OPEN_LOCALITY2        0x0390
+#define TXTCR_CMD_CLOSE_LOCALITY2       0x0398
+#define TXTCR_CMD_SECRETS               0x08e0
+#define TXTCR_CMD_NO_SECRETS            0x08e8
+#define TXTCR_E2STS                     0x08f0
+
+/*
+ * Secure Launch Defined Error Codes used in MLE-initiated TXT resets.
+ *
+ * TXT Specification
+ * Appendix I ACM Error Codes
+ */
+#define SLAUNCH_ERROR_GENERIC                0xc0008001U
+#define SLAUNCH_ERROR_TPM_INIT               0xc0008002U
+#define SLAUNCH_ERROR_TPM_INVALID_LOG20      0xc0008003U
+#define SLAUNCH_ERROR_TPM_LOGGING_FAILED     0xc0008004U
+#define SLAUNCH_ERROR_REGION_STRADDLE_4GB    0xc0008005U
+#define SLAUNCH_ERROR_TPM_EXTEND             0xc0008006U
+#define SLAUNCH_ERROR_MTRR_INV_VCNT          0xc0008007U
+#define SLAUNCH_ERROR_MTRR_INV_DEF_TYPE      0xc0008008U
+#define SLAUNCH_ERROR_MTRR_INV_BASE          0xc0008009U
+#define SLAUNCH_ERROR_MTRR_INV_MASK          0xc000800aU
+#define SLAUNCH_ERROR_MSR_INV_MISC_EN        0xc000800bU
+#define SLAUNCH_ERROR_INV_AP_INTERRUPT       0xc000800cU
+#define SLAUNCH_ERROR_INTEGER_OVERFLOW       0xc000800dU
+#define SLAUNCH_ERROR_HEAP_WALK              0xc000800eU
+#define SLAUNCH_ERROR_HEAP_MAP               0xc000800fU
+#define SLAUNCH_ERROR_REGION_ABOVE_4GB       0xc0008010U
+#define SLAUNCH_ERROR_HEAP_INVALID_DMAR      0xc0008011U
+#define SLAUNCH_ERROR_HEAP_DMAR_SIZE         0xc0008012U
+#define SLAUNCH_ERROR_HEAP_DMAR_MAP          0xc0008013U
+#define SLAUNCH_ERROR_HI_PMR_BASE            0xc0008014U
+#define SLAUNCH_ERROR_HI_PMR_SIZE            0xc0008015U
+#define SLAUNCH_ERROR_LO_PMR_BASE            0xc0008016U
+#define SLAUNCH_ERROR_LO_PMR_SIZE            0xc0008017U
+#define SLAUNCH_ERROR_LO_PMR_MLE             0xc0008018U
+#define SLAUNCH_ERROR_INITRD_TOO_BIG         0xc0008019U
+#define SLAUNCH_ERROR_HEAP_ZERO_OFFSET       0xc000801aU
+#define SLAUNCH_ERROR_WAKE_BLOCK_TOO_SMALL   0xc000801bU
+#define SLAUNCH_ERROR_MLE_BUFFER_OVERLAP     0xc000801cU
+#define SLAUNCH_ERROR_BUFFER_BEYOND_PMR      0xc000801dU
+#define SLAUNCH_ERROR_OS_SINIT_BAD_VERSION   0xc000801eU
+#define SLAUNCH_ERROR_EVENTLOG_MAP           0xc000801fU
+#define SLAUNCH_ERROR_TPM_NUMBER_ALGS        0xc0008020U
+#define SLAUNCH_ERROR_TPM_UNKNOWN_DIGEST     0xc0008021U
+#define SLAUNCH_ERROR_TPM_INVALID_EVENT      0xc0008022U
+
+#define SLAUNCH_BOOTLOADER_MAGIC             0x4c534254
+
+#ifndef __ASSEMBLY__
+
+/* Need to differentiate between pre- and post paging enabled. */
+#ifdef __EARLY_SLAUNCH__
+#include 
+#define _txt(x) _p(x)
+#else
+#include 
+#include    // __va()
+#define _txt(x) __va(x)
+#endif
+
+/*
+ * Always use private space as some of registers are either read-only or not
+ * present in public space.
+ */
+static inline uint64_t read_txt_reg(int reg_no)
+{
+    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
+    return *reg;
+}
+
+static inline void write_txt_reg(int reg_no, uint64_t val)
+{
+    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
+    *reg = val;
+    /* This serves as TXT register barrier */
+    (void)read_txt_reg(TXTCR_ESTS);
+}
+
+static inline void txt_reset(uint32_t error)
+{
+    write_txt_reg(TXTCR_ERRORCODE, error);
+    write_txt_reg(TXTCR_CMD_NO_SECRETS, 1);
+    write_txt_reg(TXTCR_CMD_UNLOCK_MEM_CONFIG, 1);
+    write_txt_reg(TXTCR_CMD_RESET, 1);
+    while (1);
+}
+
+/*
+ * Secure Launch defined OS/MLE TXT Heap table
+ */
+struct txt_os_mle_data {
+    uint32_t version;
+    uint32_t reserved;
+    uint64_t slrt;
+    uint64_t txt_info;
+    uint32_t ap_wake_block;
+    uint32_t ap_wake_block_size;
+    uint8_t mle_scratch[64];
+} __packed;
+
+/*
+ * TXT specification defined BIOS data TXT Heap table
+ */
+struct txt_bios_data {
+    uint32_t version; /* Currently 5 for TPM 1.2 and 6 for TPM 2.0 */
+    uint32_t bios_sinit_size;
+    uint64_t reserved1;
+    uint64_t reserved2;
+    uint32_t num_logical_procs;
+    /* Versions >= 3 && < 5 */
+    uint32_t sinit_flags;
+    /* Versions >= 5 with updates in version 6 */
+    uint32_t mle_flags;
+    /* Versions >= 4 */
+    /* Ext Data Elements */
+} __packed;
+
+/*
+ * TXT specification defined OS/SINIT TXT Heap table
+ */
+struct txt_os_sinit_data {
+    uint32_t version;       /* Currently 6 for TPM 1.2 and 7 for TPM 2.0 */
+    uint32_t flags;         /* Reserved in version 6 */
+    uint64_t mle_ptab;
+    uint64_t mle_size;
+    uint64_t mle_hdr_base;
+    uint64_t vtd_pmr_lo_base;
+    uint64_t vtd_pmr_lo_size;
+    uint64_t vtd_pmr_hi_base;
+    uint64_t vtd_pmr_hi_size;
+    uint64_t lcp_po_base;
+    uint64_t lcp_po_size;
+    uint32_t capabilities;
+    /* Version = 5 */
+    uint64_t efi_rsdt_ptr;  /* RSD*P* in versions >= 6 */
+    /* Versions >= 6 */
+    /* Ext Data Elements */
+} __packed;
+
+/*
+ * TXT specification defined SINIT/MLE TXT Heap table
+ */
+struct txt_sinit_mle_data {
+    uint32_t version;  /* Current values are 6 through 9 */
+    /* Versions <= 8, fields until lcp_policy_control must be 0 for >= 9 */
+    uint8_t bios_acm_id[20];
+    uint32_t edx_senter_flags;
+    uint64_t mseg_valid;
+    uint8_t sinit_hash[20];
+    uint8_t mle_hash[20];
+    uint8_t stm_hash[20];
+    uint8_t lcp_policy_hash[20];
+    uint32_t lcp_policy_control;
+    /* Versions >= 7 */
+    uint32_t rlp_wakeup_addr;
+    uint32_t reserved;
+    uint32_t num_of_sinit_mdrs;
+    uint32_t sinit_mdrs_table_offset;
+    uint32_t sinit_vtd_dmar_table_size;
+    uint32_t sinit_vtd_dmar_table_offset;
+    /* Versions >= 8 */
+    uint32_t processor_scrtm_status;
+    /* Versions >= 9 */
+    /* Ext Data Elements */
+} __packed;
+
+/*
+ * Functions to extract data from the Intel TXT Heap Memory. The layout
+ * of the heap is as follows:
+ *  +------------------------------------+
+ *  | Size of Bios Data table (uint64_t) |
+ *  +------------------------------------+
+ *  | Bios Data table                    |
+ *  +------------------------------------+
+ *  | Size of OS MLE table (uint64_t)    |
+ *  +------------------------------------+
+ *  | OS MLE table                       |
+ *  +--------------------------------    +
+ *  | Size of OS SINIT table (uint64_t)  |
+ *  +------------------------------------+
+ *  | OS SINIT table                     |
+ *  +------------------------------------+
+ *  | Size of SINIT MLE table (uint64_t) |
+ *  +------------------------------------+
+ *  | SINIT MLE table                    |
+ *  +------------------------------------+
+ *
+ *  NOTE: the table size fields include the 8 byte size field itself.
+ */
+static inline uint64_t txt_bios_data_size(void *heap)
+{
+    return *((uint64_t *)heap) - sizeof(uint64_t);
+}
+
+static inline void *txt_bios_data_start(void *heap)
+{
+    return heap + sizeof(uint64_t);
+}
+
+static inline uint64_t txt_os_mle_data_size(void *heap)
+{
+    return *((uint64_t *)(txt_bios_data_start(heap) +
+                          txt_bios_data_size(heap))) -
+        sizeof(uint64_t);
+}
+
+static inline void *txt_os_mle_data_start(void *heap)
+{
+    return txt_bios_data_start(heap) + txt_bios_data_size(heap) +
+        sizeof(uint64_t);
+}
+
+static inline uint64_t txt_os_sinit_data_size(void *heap)
+{
+    return *((uint64_t *)(txt_os_mle_data_start(heap) +
+                          txt_os_mle_data_size(heap))) -
+        sizeof(uint64_t);
+}
+
+static inline void *txt_os_sinit_data_start(void *heap)
+{
+    return txt_os_mle_data_start(heap) + txt_os_mle_data_size(heap) +
+        sizeof(uint64_t);
+}
+
+static inline uint64_t txt_sinit_mle_data_size(void *heap)
+{
+    return *((uint64_t *)(txt_os_sinit_data_start(heap) +
+                          txt_os_sinit_data_size(heap))) -
+        sizeof(uint64_t);
+}
+
+static inline void *txt_sinit_mle_data_start(void *heap)
+{
+    return txt_os_sinit_data_start(heap) + txt_os_sinit_data_size(heap) +
+        sizeof(uint64_t);
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* ASM__X86__INTEL_TXT_H */
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index d5db60d335..8a573d8c79 100644
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -35,23 +36,6 @@ static uint64_t __initdata sinit_base, __initdata sinit_size;
 
 static bool __ro_after_init is_vtd;
 
-/*
- * TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
- */
-
-#define TXT_PUB_CONFIG_REGS_BASE       0xfed30000
-#define TXT_PRIV_CONFIG_REGS_BASE      0xfed20000
-
-/* # pages for each config regs space - used by fixmap */
-#define NR_TXT_CONFIG_PAGES     ((TXT_PUB_CONFIG_REGS_BASE -                \
-                                  TXT_PRIV_CONFIG_REGS_BASE) >> PAGE_SHIFT)
-
-/* offsets from pub/priv config space */
-#define TXTCR_SINIT_BASE            0x0270
-#define TXTCR_SINIT_SIZE            0x0278
-#define TXTCR_HEAP_BASE             0x0300
-#define TXTCR_HEAP_SIZE             0x0308
-
 #define SHA1_SIZE      20
 typedef uint8_t   sha1_hash_t[SHA1_SIZE];
 
@@ -409,7 +393,7 @@ int __init tboot_protect_mem_regions(void)
 
     /* TXT Private Space */
     rc = e820_change_range_type(&e820, TXT_PRIV_CONFIG_REGS_BASE,
-                 TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SIZE,
+                 TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_SIZE,
                  E820_RESERVED, E820_UNUSABLE);
     if ( !rc )
         return 0;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:06:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:06:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983181.1369522 (Exim 4.92)
	(envelope-from )
	id 1uEt5H-0003aX-6B; Tue, 13 May 2025 17:06:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983181.1369522; Tue, 13 May 2025 17: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 1uEt5H-0003aQ-3P; Tue, 13 May 2025 17:06:27 +0000
Received: by outflank-mailman (input) for mailman id 983181;
 Tue, 13 May 2025 17:06:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5E-0003Mm-It
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:25 +0000
Received: from 14.mo582.mail-out.ovh.net (14.mo582.mail-out.ovh.net
 [46.105.56.113]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 981fcbe8-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:06:22 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.109.148.65])
 by mo582.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjYT3Fl9z1fD3
 for ; Tue, 13 May 2025 17:06:21 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-tzcrg (unknown [10.110.101.251])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 5101D1FD1D;
 Tue, 13 May 2025 17:06:19 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.96])
 by ghost-submission-5b5ff79f4f-tzcrg with ESMTPSA
 id fnX0Mgp8I2j3JwEAShSnmA
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: 981fcbe8-301c-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-96R001ee74798f-ac1a-4ede-9fca-0d0d4df457d9,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Lukasz Hawrylko ,
	=?UTF-8?q?Mateusz=20M=C3=B3wka?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Nicola Vetrini ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 00/22] x86: Trenchboot Secure Launch DRTM (Xen)
Date: Tue, 13 May 2025 20:05:37 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8938800839277393052
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -51
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnegoufhushhpvggtthffohhmrghinhculdegledmnecujfgurhephffvvefufffkofggtgfgsehtkeertdertdejnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepudehtdekieegfeffveejtddufeelleegfeevkedtgedvgeffieejjeelgeevgfegnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpghhithhlrggsrdgtohhmpdhtrhgvnhgthhgsohhothdrohhrghdpshhouhhrtggvfhhorhhgvgdrnhgvthdpkhgvrhhnvghlrdhorhhgnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukedurddujeekpdefjedrheelrddugedvrdelieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkedvmgdpmhhouggvpehsmhhtph
 houhht
DKIM-Signature: a=rsa-sha256; bh=uUInVjt0zHUzX1YlJgsoYmHPLtR542NbxOEr3R3yCWg=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747155981; v=1;
 b=B8/HTKTvXXIUoeAnuwFCNdUIbYLMSOSrQX7zxIYj6HMRWp5+MiiUKurncb10038t0oDCA5vj
 0BIUTTFeTtT/5HjIMvrVLeXRcd/BngwXSoT6s2erpQscaT/xTTUKTY06LHCn7vZC8qi4IgLQkI/
 Oh2P3FoHIMyR1K0FN29NMhwdqmRPIa4NfNuxSZE6sPrWvMc4BiwafCeDRmHMZ4NFFCjPIRy8uJp
 PLUV/b35qVcAqzFoqgMo133Dcna7ftqtNiqrgZDmLUykRe8DKVK7tW7eem20K0z1vJifLfHtP+i
 aEzPUPMpKtmjZM7H5Qm/6uebJKQ8XJMUCUl4QuD0GWnfg==

The aim of the [TrenchBoot] project is to provide an implementation of
DRTM that is generic enough to cover various use cases:
 - Intel TXT and AMD SKINIT on x86 CPUs
 - legacy and UEFI boot
 - TPM1.2 and TPM2.0
 - (in the future) DRTM on Arm CPUs

DRTM is a version of a measured launch that starts on request rather
than at the start of a boot cycle.  One of its advantages is in not
including the firmware in the chain of trust.

Xen already supports DRTM via [tboot] which targets Intel TXT only.
tboot employs encapsulates some of the DRTM details within itself while
with TrenchBoot Xen (or Linux) is meant to be a self-contained payload
for a TrenchBoot-enabled bootloader (think GRUB).  The one exception is
that UEFI case requires calling back into bootloader to initiate DRTM,
which is necessary to give Xen a chance of querying all the information
it needs from the firmware before performing DRTM start.

>From reading the above tboot might seem like a more abstracted, but the
reality is that the payload needs to have DRTM-specific knowledge either
way.  TrenchBoot in principle allows coming up with independent
implementations of bootloaders and payloads that are compatible with
each other.

The "x86/boot: choose AP stack based on APIC ID" patch is shared with
[Parallelize AP bring-up] series which is required here because Intel
TXT always releases all APs simultaneously.  The rest of the patches are
unique.

This version of the patches corresponds to this branch:
    https://github.com/TrenchBoot/xen/pull/new/aem-staging-2025-05-12-v2

With the help from Andrew Cooper v2 passes all CI tests:
    https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1815190030

-----

[TrenchBoot]: https://trenchboot.org/
[tboot]: https://sourceforge.net/p/tboot/wiki/Home/
[Parallelize AP bring-up]: https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/
[v1]: https://lore.kernel.org/xen-devel/cover.1745172094.git.sergii.dmytruk@3mdeb.com/

-----

Changes in v2:
 - using dashes instead of underscores in the names of new files
 - dropping of an extra sha256 implementation
 - rewriting sha1 implementation to be in line with already present
   sha256 implementation (simplifying it and getting rid of macros)
 - correct placement of new lines in Makefile
 - add header guards to all new files
 - use correct names for header guards in new files
 - update license of xen/include/xen/slr-table.h
 - changed fixmlehdr to search for header within 8 instead of 4 KiB file
   prefix
 - don't print DRTM-related capabilities when resuming from S3
 - forbade S3 in case of Secure Launch
 - fixed an issue with resuming from S3 caused by inappropriate use of
   __initdata
 - added a new section to MAINTAINERS
 - improved commit messages
 - fixed MISRA C violations:
   * shadowing of e820 global
   * missing U literal suffixes
   * use of ull literal suffix
   * excluded fixmlehdr from analysis (similar to other build tools)
   * use of 0 instead of NULL in one place
   * provided declarations for some definitions
   * marked asm-invoked functions with `asmlinkage`

-----

Kacper Stojek (2):
  x86/boot: add MLE header and Secure Launch entry point
  xen/arch/x86: reserve TXT memory during Slaunch

Krystian Hebel (7):
  x86/include/asm/intel-txt.h: constants and accessors for TXT registers
    and heap
  x86/boot/slaunch-early: early TXT checks and boot data retrieval
  x86/slaunch: restore boot MTRRs after Intel TXT DRTM
  xen/lib: add implementation of SHA-1
  x86/tpm.c: code for early hashing and extending PCRs (for TPM1.2)
  x86/boot: choose AP stack based on APIC ID
  x86/smpboot.c: TXT AP bringup

Michał Żygowski (2):
  x86/hvm: check for VMX in SMX if Slaunch is active
  x86/cpu: report SMX, TXT and SKINIT capabilities

Sergii Dmytruk (11):
  include/xen/slr-table.h: Secure Launch Resource Table definitions
  x86/boot/slaunch-early: implement early initialization
  x86/mtrr: expose functions for pausing caching
  x86/tpm.c: support extending PCRs of TPM2.0
  x86/tpm.c: implement event log for TPM2.0
  x86/slaunch: process DRTM policy
  x86/acpi: disallow S3 on Secure Launch boot
  x86/boot/slaunch-early: find MBI and SLRT on AMD
  x86/slaunch: support AMD SKINIT
  x86/slaunch: support EFI boot
  MAINTAINERS: add a section for TrenchBoot Slaunch

 .gitignore                                    |    1 +
 MAINTAINERS                                   |   15 +
 .../eclair_analysis/ECLAIR/out_of_scope.ecl   |    1 +
 docs/hypervisor-guide/x86/how-xen-boots.rst   |    7 +
 xen/arch/x86/Makefile                         |   12 +-
 xen/arch/x86/acpi/power.c                     |    8 +
 xen/arch/x86/boot/Makefile                    |   10 +-
 xen/arch/x86/boot/head.S                      |  250 ++++
 xen/arch/x86/boot/slaunch-early.c             |  105 ++
 xen/arch/x86/boot/trampoline.S                |   40 +-
 xen/arch/x86/boot/x86_64.S                    |   42 +-
 xen/arch/x86/cpu/amd.c                        |   16 +
 xen/arch/x86/cpu/cpu.h                        |    1 +
 xen/arch/x86/cpu/hygon.c                      |    1 +
 xen/arch/x86/cpu/intel.c                      |   46 +
 xen/arch/x86/cpu/mtrr/generic.c               |   51 +-
 xen/arch/x86/e820.c                           |    5 +
 xen/arch/x86/efi/efi-boot.h                   |   88 +-
 xen/arch/x86/efi/fixmlehdr.c                  |  127 ++
 xen/arch/x86/hvm/vmx/vmcs.c                   |    3 +-
 xen/arch/x86/include/asm/apicdef.h            |    4 +
 xen/arch/x86/include/asm/intel-txt.h          |  457 +++++++
 xen/arch/x86/include/asm/mm.h                 |    3 +
 xen/arch/x86/include/asm/msr-index.h          |    3 +
 xen/arch/x86/include/asm/mtrr.h               |    8 +
 xen/arch/x86/include/asm/processor.h          |    1 +
 xen/arch/x86/include/asm/slaunch.h            |   98 ++
 xen/arch/x86/include/asm/tpm.h                |   19 +
 xen/arch/x86/intel-txt.c                      |  188 +++
 xen/arch/x86/setup.c                          |   32 +-
 xen/arch/x86/slaunch.c                        |  465 ++++++++
 xen/arch/x86/smpboot.c                        |   63 +
 xen/arch/x86/tboot.c                          |   20 +-
 xen/arch/x86/tpm.c                            | 1056 +++++++++++++++++
 xen/common/efi/boot.c                         |    4 +
 xen/common/efi/runtime.c                      |    1 +
 xen/include/xen/efi.h                         |    1 +
 xen/include/xen/sha1.h                        |   12 +
 xen/include/xen/slr-table.h                   |  268 +++++
 xen/lib/Makefile                              |    1 +
 xen/lib/sha1.c                                |  218 ++++
 41 files changed, 3695 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/x86/boot/slaunch-early.c
 create mode 100644 xen/arch/x86/efi/fixmlehdr.c
 create mode 100644 xen/arch/x86/include/asm/intel-txt.h
 create mode 100644 xen/arch/x86/include/asm/slaunch.h
 create mode 100644 xen/arch/x86/include/asm/tpm.h
 create mode 100644 xen/arch/x86/intel-txt.c
 create mode 100644 xen/arch/x86/slaunch.c
 create mode 100644 xen/arch/x86/tpm.c
 create mode 100644 xen/include/xen/sha1.h
 create mode 100644 xen/include/xen/slr-table.h
 create mode 100644 xen/lib/sha1.c


base-commit: f6042f38e621525feff86bb101dc751d2d87cff8
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:06:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:06:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983184.1369553 (Exim 4.92)
	(envelope-from )
	id 1uEt5N-0004K5-0q; Tue, 13 May 2025 17:06:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983184.1369553; Tue, 13 May 2025 17: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 1uEt5M-0004Jt-To; Tue, 13 May 2025 17:06:32 +0000
Received: by outflank-mailman (input) for mailman id 983184;
 Tue, 13 May 2025 17:06:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5M-0003Uz-Hz
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:32 +0000
Received: from 20.mo550.mail-out.ovh.net (20.mo550.mail-out.ovh.net
 [188.165.45.168]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9d6aca18-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:06:30 +0200 (CEST)
Received: from director9.ghost.mail-out.ovh.net (unknown [10.109.148.146])
 by mo550.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjYf2Qvjz1Xq2
 for ; Tue, 13 May 2025 17:06:30 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-nlmb7 (unknown [10.110.178.147])
 by director9.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 2C12A1FD17;
 Tue, 13 May 2025 17:06:29 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.99])
 by ghost-submission-5b5ff79f4f-nlmb7 with ESMTPSA
 id AqO1NhR8I2hfugwAUpD23g
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: 9d6aca18-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-99G003d4859a46-3139-4826-a82b-8ac732a6f74e,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
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 ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 03/22] x86/boot: add MLE header and Secure Launch entry point
Date: Tue, 13 May 2025 20:05:40 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8941334113704719516
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeekudegfeduieegudeijeelleekfedvvdfhheehvefhudekjeeifeegtdduveehtdenucffohhmrghinhephhgvrggurdhssgenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddrleelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheehtdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=REsQ4rGltjGtDGspVocQv2/Sf60+XBS+U8hI4FuZ0Cs=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747155990; v=1;
 b=XO1GITo4bFnbLY0qz9ejkrqZfVNiaHNri3W3XXC8rD0zf99dHg/nOB711w5KITxRNbm6oCKu
 GE/XOcgo0bK3RbIo3OJaGixZCgL30Rk9UK1L0use5s1jXOQyCAnoKxFAwfxqiceIZzWO4RnGweF
 bSrfJfijiB+yqtAQp39K1HL/dNZEWQ9iXyGzx6iK9vs0ORC+jxd2L4d5XzbWmFo4N9B3KwNv99e
 QO8aqhvOGwRkT9O7hZoa3wEykS05ip1mViu6jsfMdLwzwY670EUzYz3xu2CNR29fCq2IZO94xOT
 damggoTG6cWkiRwPCOYAPN52hedU4WUj5gQDKMk6RVDtQ==

From: Kacper Stojek 

Signed-off-by: Kacper Stojek 
Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 docs/hypervisor-guide/x86/how-xen-boots.rst |  5 ++
 xen/arch/x86/boot/head.S                    | 53 +++++++++++++++++++++
 2 files changed, 58 insertions(+)

diff --git a/docs/hypervisor-guide/x86/how-xen-boots.rst b/docs/hypervisor-guide/x86/how-xen-boots.rst
index 8b3229005c..050fe9c61f 100644
--- a/docs/hypervisor-guide/x86/how-xen-boots.rst
+++ b/docs/hypervisor-guide/x86/how-xen-boots.rst
@@ -55,6 +55,11 @@ If ``CONFIG_PVH_GUEST`` was selected at build time, an Elf note is included
 which indicates the ability to use the PVH boot protocol, and registers
 ``__pvh_start`` as the entrypoint, entered in 32bit mode.
 
+A combination of Multiboot 2 and MLE headers is used to implement DRTM for
+legacy (BIOS) boot. The separate entry point is used mainly to differentiate
+from other kinds of boots. It moves a magic number to EAX before jumping into
+common startup code.
+
 
 xen.gz
 ~~~~~~
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 77bb7a9e21..a69107bd81 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -126,6 +127,25 @@ multiboot2_header:
         .size multiboot2_header, . - multiboot2_header
         .type multiboot2_header, @object
 
+        .balign 16
+mle_header:
+        .long   0x9082ac5a  /* UUID0 */
+        .long   0x74a7476f  /* UUID1 */
+        .long   0xa2555c0f  /* UUID2 */
+        .long   0x42b651cb  /* UUID3 */
+        .long   0x00000034  /* MLE header size */
+        .long   0x00020002  /* MLE version 2.2 */
+        .long   (slaunch_stub_entry - start)  /* Linear entry point of MLE (SINIT virt. address) */
+        .long   0x00000000  /* First valid page of MLE */
+        .long   0x00000000  /* Offset within binary of first byte of MLE */
+        .long   (_end - start)  /* Offset within binary of last byte + 1 of MLE */
+        .long   0x00000723  /* Bit vector of MLE-supported capabilities */
+        .long   0x00000000  /* Starting linear address of command line (unused) */
+        .long   0x00000000  /* Ending linear address of command line (unused) */
+
+        .size mle_header, .-mle_header
+        .type mle_header, @object
+
         .section .init.rodata, "a", @progbits
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
@@ -332,6 +352,38 @@ cs32_switch:
         /* Jump to earlier loaded address. */
         jmp     *%edi
 
+        /*
+         * Entry point for TrenchBoot Secure Launch on Intel TXT platforms.
+         *
+         * CPU is in 32b protected mode with paging disabled. On entry:
+         * - %ebx = %eip = MLE entry point,
+         * - stack pointer is undefined,
+         * - CS is flat 4GB code segment,
+         * - DS, ES, SS, FS and GS are undefined according to TXT SDG, but this
+         *   would make it impossible to initialize GDTR, because GDT base must
+         *   be relocated in the descriptor, which requires write access that
+         *   CS doesn't provide. Instead we have to assume that DS is set by
+         *   SINIT ACM as flat 4GB data segment.
+         *
+         * Additional restrictions:
+         * - some MSRs are partially cleared, among them IA32_MISC_ENABLE, so
+         *   some capabilities might be reported as disabled even if they are
+         *   supported by CPU
+         * - interrupts (including NMIs and SMIs) are disabled and must be
+         *   enabled later
+         * - trying to enter real mode results in reset
+         * - APs must be brought up by MONITOR or GETSEC[WAKEUP], depending on
+         *   which is supported by a given SINIT ACM
+         */
+slaunch_stub_entry:
+        /* Calculate the load base address. */
+        mov     %ebx, %esi
+        sub     $sym_offs(slaunch_stub_entry), %esi
+
+        /* Mark Secure Launch boot protocol and jump to common entry. */
+        mov     $SLAUNCH_BOOTLOADER_MAGIC, %eax
+        jmp     .Lset_stack
+
 #ifdef CONFIG_PVH_GUEST
 ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, .long sym_offs(__pvh_start))
 
@@ -371,6 +423,7 @@ __start:
         /* Restore the clobbered field. */
         mov     %edx, (%ebx)
 
+.Lset_stack:
         /* Set up stack. */
         lea     STACK_SIZE - CPUINFO_sizeof + sym_esi(cpu0_stack), %esp
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:06:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:06:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983187.1369563 (Exim 4.92)
	(envelope-from )
	id 1uEt5S-0004gt-Eb; Tue, 13 May 2025 17:06:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983187.1369563; Tue, 13 May 2025 17: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 1uEt5S-0004gi-BF; Tue, 13 May 2025 17:06:38 +0000
Received: by outflank-mailman (input) for mailman id 983187;
 Tue, 13 May 2025 17:06:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5Q-0003Uz-Up
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:36 +0000
Received: from 5.mo576.mail-out.ovh.net (5.mo576.mail-out.ovh.net
 [46.105.43.105]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9f880fff-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:06:34 +0200 (CEST)
Received: from director7.ghost.mail-out.ovh.net (unknown [10.108.25.209])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjYj6W4pz27TK
 for ; Tue, 13 May 2025 17:06:33 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-q2zpp (unknown [10.111.182.135])
 by director7.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 60E7C1FE55;
 Tue, 13 May 2025 17:06:32 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.113])
 by ghost-submission-5b5ff79f4f-q2zpp with ESMTPSA
 id P1daARh8I2hSAAAAOMNtBw
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: 9f880fff-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-113S0075f9b7bdb-4fc0-4d16-a0e3-1c660f845f6a,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 04/22] x86/boot/slaunch-early: implement early initialization
Date: Tue, 13 May 2025 20:05:41 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8942178535177106588
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeffjefgudevkeetudegueeihfdthfejgfeileekuefggeegtdegveehfeehfeefueenucffohhmrghinhepsggrshgvrdhmrghppdhhvggrugdrshgsnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukedurddujeekpdefjedrheelrddugedvrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheejiegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=1WE6obMWuo+KNg7UZQNZPIN6Phqk/WygHa2bFXNKWVc=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747155993; v=1;
 b=N6Rl8NbzfyJPvSMlKRuqEMHO2g8ebYlqYv78YFsBuxZwNDav4/8ngZTWaX2kmP/IPx9QBvGl
 4p1Ad+2UjqglgeDsyo8e9GWShfOwE/dWL4jbjid6f8m4+nDuaZgryfvonrpvTHasKloLYYKWQcu
 fBYmlL6LnNWn5UkRL/sqscDX7ztfwyU4DIGEGZVUxDLJ71EncWlcxlp+VQvTzGh5Pza07j8FL1a
 ew23EXbIKI2g6gzwUjRRpVrFsC9F6/FwQkppHGMU6mVOuLL3OFEKszK4UAfdoLoGF0Qco19r3tw
 +W26YWW6xkg0w6wBk3Kml3sw+q7KViKEDoFYSFglplZug==

Make head.S invoke a C function to retrieve MBI and SLRT addresses in a
platform-specific way.  This is also the place to perform sanity checks
of DRTM.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/Makefile                |  1 +
 xen/arch/x86/boot/Makefile           |  5 +++-
 xen/arch/x86/boot/head.S             | 43 ++++++++++++++++++++++++++++
 xen/arch/x86/boot/slaunch-early.c    | 41 ++++++++++++++++++++++++++
 xen/arch/x86/include/asm/intel-txt.h | 16 +++++++++++
 xen/arch/x86/include/asm/slaunch.h   | 26 +++++++++++++++++
 xen/arch/x86/slaunch.c               | 27 +++++++++++++++++
 7 files changed, 158 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/x86/boot/slaunch-early.c
 create mode 100644 xen/arch/x86/include/asm/slaunch.h
 create mode 100644 xen/arch/x86/slaunch.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index bedb97cbee..43a80be458 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_COMPAT) += x86_64/physdev.o
 obj-$(CONFIG_X86_PSR) += psr.o
 obj-y += setup.o
 obj-y += shutdown.o
+obj-y += slaunch.o
 obj-y += smp.o
 obj-y += smpboot.o
 obj-y += spec_ctrl.o
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index ff0d61d7ac..5471b966dd 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -5,6 +5,7 @@ obj-bin-y += $(obj64)
 obj32 := cmdline.32.o
 obj32 += reloc.32.o
 obj32 += reloc-trampoline.32.o
+obj32 += slaunch-early.32.o
 
 obj64 := reloc-trampoline.o
 
@@ -28,6 +29,8 @@ $(obj32): XEN_CFLAGS := $(CFLAGS_x86_32) -fpic
 $(obj)/%.32.o: $(src)/%.c FORCE
 	$(call if_changed_rule,cc_o_c)
 
+$(obj)/slaunch-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
+
 orphan-handling-$(call ld-option,--orphan-handling=error) := --orphan-handling=error
 LDFLAGS_DIRECT-$(call ld-option,--warn-rwx-segments) := --no-warn-rwx-segments
 LDFLAGS_DIRECT += $(LDFLAGS_DIRECT-y)
@@ -81,7 +84,7 @@ cmd_combine = \
               --bin1      $(obj)/built-in-32.base.bin \
               --bin2      $(obj)/built-in-32.offset.bin \
               --map       $(obj)/built-in-32.base.map \
-              --exports   cmdline_parse_early,reloc,reloc_trampoline32 \
+              --exports   cmdline_parse_early,reloc,reloc_trampoline32,slaunch_early_init \
               --output    $@
 
 targets += built-in-32.S
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index a69107bd81..b4cf423c80 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -472,6 +472,10 @@ __start:
         /* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
         xor     %edx,%edx
 
+        /* Check for TrenchBoot slaunch bootloader. */
+        cmp     $SLAUNCH_BOOTLOADER_MAGIC, %eax
+        je      .Lslaunch_proto
+
         /* Check for Multiboot2 bootloader. */
         cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
         je      .Lmultiboot2_proto
@@ -487,6 +491,45 @@ __start:
         cmovnz  MB_mem_lower(%ebx),%edx
         jmp     trampoline_bios_setup
 
+.Lslaunch_proto:
+        /*
+         * Upon reaching here, CPU state mostly matches the one setup by the
+         * bootloader with ESP, ESI and EDX being clobbered above.
+         */
+
+        /* Save information that TrenchBoot slaunch was used. */
+        movb    $1, sym_esi(slaunch_active)
+
+        /*
+         * Prepare space for output parameter of slaunch_early_init(), which is
+         * a structure of two uint32_t fields.
+         */
+        sub     $8, %esp
+
+        push    %esp                             /* pointer to output structure */
+        lea     sym_offs(__2M_rwdata_end), %ecx  /* end of target image */
+        lea     sym_offs(_start), %edx           /* target base address */
+        mov     %esi, %eax                       /* load base address */
+        /*
+         * slaunch_early_init(load/eax, tgt/edx, tgt_end/ecx, ret/stk) using
+         * fastcall calling convention.
+         */
+        call    slaunch_early_init
+        add     $4, %esp                         /* pop the fourth parameter */
+
+        /* Move outputs of slaunch_early_init() from stack into registers. */
+        pop     %eax  /* physical MBI address */
+        pop     %edx  /* physical SLRT address */
+
+        /* Save physical address of SLRT for C code. */
+        mov     %edx, sym_esi(slaunch_slrt)
+
+        /* Store MBI address in EBX where MB2 code expects it. */
+        mov     %eax, %ebx
+
+        /* Move magic number expected by Multiboot 2 to EAX and fall through. */
+        movl    $MULTIBOOT2_BOOTLOADER_MAGIC, %eax
+
 .Lmultiboot2_proto:
         /* Skip Multiboot2 information fixed part. */
         lea     (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%ebx),%ecx
diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
new file mode 100644
index 0000000000..48776ef559
--- /dev/null
+++ b/xen/arch/x86/boot/slaunch-early.c
@@ -0,0 +1,41 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+
+struct early_init_results
+{
+    uint32_t mbi_pa;
+    uint32_t slrt_pa;
+} __packed;
+
+void asmlinkage slaunch_early_init(uint32_t load_base_addr,
+                                   uint32_t tgt_base_addr,
+                                   uint32_t tgt_end_addr,
+                                   struct early_init_results *result)
+{
+    void *txt_heap;
+    struct txt_os_mle_data *os_mle;
+    struct slr_table *slrt;
+    struct slr_entry_intel_info *intel_info;
+
+    txt_heap = txt_init();
+    os_mle = txt_os_mle_data_start(txt_heap);
+
+    result->slrt_pa = os_mle->slrt;
+    result->mbi_pa = 0;
+
+    slrt = (struct slr_table *)(uintptr_t)os_mle->slrt;
+
+    intel_info = (struct slr_entry_intel_info *)
+        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+    if ( intel_info == NULL || intel_info->hdr.size != sizeof(*intel_info) )
+        return;
+
+    result->mbi_pa = intel_info->boot_params_base;
+}
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 07be43f557..7a665b7cc3 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -272,6 +272,22 @@ static inline void *txt_sinit_mle_data_start(void *heap)
         sizeof(uint64_t);
 }
 
+static inline void *txt_init(void)
+{
+    void *txt_heap;
+
+    /* Clear the TXT error register for a clean start of the day. */
+    write_txt_reg(TXTCR_ERRORCODE, 0);
+
+    txt_heap = _p(read_txt_reg(TXTCR_HEAP_BASE));
+
+    if ( txt_os_mle_data_size(txt_heap) < sizeof(struct txt_os_mle_data) ||
+         txt_os_sinit_data_size(txt_heap) < sizeof(struct txt_os_sinit_data) )
+        txt_reset(SLAUNCH_ERROR_GENERIC);
+
+    return txt_heap;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* ASM__X86__INTEL_TXT_H */
diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
new file mode 100644
index 0000000000..3fc5f00073
--- /dev/null
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -0,0 +1,26 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#ifndef ASM__X86__SLAUNCH_H
+#define ASM__X86__SLAUNCH_H
+
+#include 
+
+/* Indicates an active Secure Launch boot. */
+extern bool slaunch_active;
+
+/*
+ * Holds physical address of SLRT.  Use slaunch_get_slrt() to access SLRT
+ * instead of mapping where this points to.
+ */
+extern uint32_t slaunch_slrt;
+
+/*
+ * Retrieves pointer to SLRT.  Checks table's validity and maps it as necessary.
+ */
+struct slr_table *slaunch_get_slrt(void);
+
+#endif /* ASM__X86__SLAUNCH_H */
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
new file mode 100644
index 0000000000..a3e6ab8d71
--- /dev/null
+++ b/xen/arch/x86/slaunch.c
@@ -0,0 +1,27 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * These variables are assigned to by the code near Xen's entry point.
+ *
+ * slaunch_active is not __initdata to allow checking for an active Secure
+ * Launch boot.
+ */
+bool slaunch_active;
+uint32_t __initdata slaunch_slrt; /* physical address */
+
+/* Using slaunch_active in head.S assumes it's a single byte in size, so enforce
+ * this assumption. */
+static void __maybe_unused compile_time_checks(void)
+{
+    BUILD_BUG_ON(sizeof(slaunch_active) != 1);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:06:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:06:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983188.1369573 (Exim 4.92)
	(envelope-from )
	id 1uEt5U-000504-M7; Tue, 13 May 2025 17:06:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983188.1369573; Tue, 13 May 2025 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 1uEt5U-0004zt-Hd; Tue, 13 May 2025 17:06:40 +0000
Received: by outflank-mailman (input) for mailman id 983188;
 Tue, 13 May 2025 17:06:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5T-0003Uz-1w
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:39 +0000
Received: from 7.mo581.mail-out.ovh.net (7.mo581.mail-out.ovh.net
 [46.105.43.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a1530611-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:06:37 +0200 (CEST)
Received: from director1.ghost.mail-out.ovh.net (unknown [10.108.25.156])
 by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjYm6MKXz1Fhd
 for ; Tue, 13 May 2025 17:06:36 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-v29lk (unknown [10.110.188.76])
 by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id C1C081FE80;
 Tue, 13 May 2025 17:06:35 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.105])
 by ghost-submission-5b5ff79f4f-v29lk with ESMTPSA
 id eryDIBt8I2hUshgACLuduA
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: a1530611-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-105G0062e7951fd-12e2-49b8-a10e-061233634830,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 05/22] x86/boot/slaunch-early: early TXT checks and boot data retrieval
Date: Tue, 13 May 2025 20:05:42 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8943022961074877596
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpefhheefheduieelieekfffgfffgfedutdevleevvdfhfffgledvgfdtuddtheefieenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddruddtheenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkedumgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=tFKfUzszVh/xwE4DF75x7y3iV3k/7BaG2IaI1fkSePQ=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747155996; v=1;
 b=kA2RD/zQxREyvarndY+ACW5/XynAiaUxCEKShSot9JONW+eum6rTMfs5X1Z9PfaXnNZi2cKy
 amSc/q7Sf7bHxU3yHNAxWWQzNUnh4/MFhIN0RxNh1X8rbou8nkIlBwWPh+P91gSpRIP1Ci37olM
 gu0D1rRPkZesm7OOSAefom1czrSnsQ28BMvxXXjd36D+eb58SJX7lzBkyUX5sUYcHSD2FcMjDSN
 ZBKuVG2j3fWS6AYasmCNMJwNZp2uTG2doTDOPZPWOpAl9B3Mh3Ij3HYHTSXQZThh0tEllnnVFtB
 hXgo1P11mDZqEqbRaat9OUi5JljPgAxsz50tV/1tG2rYw==

From: Krystian Hebel 

The tests validate that important parts of memory are protected against
DMA attacks, including Xen and MBI. Modules can be tested later, when it
is possible to report issues to a user before invoking TXT reset.

TPM event log validation is temporarily disabled due to an issue with
its allocation by bootloader (GRUB) which will need to be modified to
address this. Ultimately event log will also have to be validated early
as it is used immediately after these tests to hold MBI measurements.
See larger comment in txt_verify_pmr_ranges().

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/boot/slaunch-early.c    |   6 ++
 xen/arch/x86/include/asm/intel-txt.h | 111 +++++++++++++++++++++++++++
 2 files changed, 117 insertions(+)

diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
index 48776ef559..b6f6deedc9 100644
--- a/xen/arch/x86/boot/slaunch-early.c
+++ b/xen/arch/x86/boot/slaunch-early.c
@@ -22,10 +22,13 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
     void *txt_heap;
     struct txt_os_mle_data *os_mle;
     struct slr_table *slrt;
+    struct txt_os_sinit_data *os_sinit;
     struct slr_entry_intel_info *intel_info;
+    uint32_t size = tgt_end_addr - tgt_base_addr;
 
     txt_heap = txt_init();
     os_mle = txt_os_mle_data_start(txt_heap);
+    os_sinit = txt_os_sinit_data_start(txt_heap);
 
     result->slrt_pa = os_mle->slrt;
     result->mbi_pa = 0;
@@ -38,4 +41,7 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
         return;
 
     result->mbi_pa = intel_info->boot_params_base;
+
+    txt_verify_pmr_ranges(os_mle, os_sinit, intel_info,
+                          load_base_addr, tgt_base_addr, size);
 }
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 7a665b7cc3..339c29ebef 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -84,6 +84,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include 
+
 /* Need to differentiate between pre- and post paging enabled. */
 #ifdef __EARLY_SLAUNCH__
 #include 
@@ -288,6 +290,115 @@ static inline void *txt_init(void)
     return txt_heap;
 }
 
+static inline int is_in_pmr(struct txt_os_sinit_data *os_sinit, uint64_t base,
+                            uint32_t size, int check_high)
+{
+    /* Check for size overflow. */
+    if ( base + size < base )
+        txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
+
+    /* Low range always starts at 0, so its size is also end address. */
+    if ( base >= os_sinit->vtd_pmr_lo_base &&
+         base + size <= os_sinit->vtd_pmr_lo_size )
+        return 1;
+
+    if ( check_high && os_sinit->vtd_pmr_hi_size != 0 )
+    {
+        if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <
+             os_sinit->vtd_pmr_hi_size )
+            txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
+        if ( base >= os_sinit->vtd_pmr_hi_base &&
+             base + size <= os_sinit->vtd_pmr_hi_base +
+                            os_sinit->vtd_pmr_hi_size )
+            return 1;
+    }
+
+    return 0;
+}
+
+static inline void txt_verify_pmr_ranges(struct txt_os_mle_data *os_mle,
+                                         struct txt_os_sinit_data *os_sinit,
+                                         struct slr_entry_intel_info *info,
+                                         uint32_t load_base_addr,
+                                         uint32_t tgt_base_addr,
+                                         uint32_t xen_size)
+{
+    int check_high_pmr = 0;
+
+    /* Verify the value of the low PMR base. It should always be 0. */
+    if ( os_sinit->vtd_pmr_lo_base != 0 )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_BASE);
+
+    /*
+     * Low PMR size should not be 0 on current platforms. There is an ongoing
+     * transition to TPR-based DMA protection instead of PMR-based; this is not
+     * yet supported by the code.
+     */
+    if ( os_sinit->vtd_pmr_lo_size == 0 )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_SIZE);
+
+    /* Check if regions overlap. Treat regions with no hole between as error. */
+    if ( os_sinit->vtd_pmr_hi_size != 0 &&
+         os_sinit->vtd_pmr_hi_base <= os_sinit->vtd_pmr_lo_size )
+        txt_reset(SLAUNCH_ERROR_HI_PMR_BASE);
+
+    /* All regions accessed by 32b code must be below 4G. */
+    if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <=
+         0x100000000ULL )
+        check_high_pmr = 1;
+
+    /*
+     * ACM checks that TXT heap and MLE memory is protected against DMA. We have
+     * to check if MBI and whole Xen memory is protected. The latter is done in
+     * case bootloader failed to set whole image as MLE and to make sure that
+     * both pre- and post-relocation code is protected.
+     */
+
+    /* Check if all of Xen before relocation is covered by PMR. */
+    if ( !is_in_pmr(os_sinit, load_base_addr, xen_size, check_high_pmr) )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
+
+    /* Check if all of Xen after relocation is covered by PMR. */
+    if ( load_base_addr != tgt_base_addr &&
+         !is_in_pmr(os_sinit, tgt_base_addr, xen_size, check_high_pmr) )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
+
+    /*
+     * If present, check that MBI is covered by PMR. MBI starts with 'uint32_t
+     * total_size'.
+     */
+    if ( info->boot_params_base != 0 &&
+         !is_in_pmr(os_sinit, info->boot_params_base,
+                    *(uint32_t *)(uintptr_t)info->boot_params_base,
+                    check_high_pmr) )
+        txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
+
+    /* Check if TPM event log (if present) is covered by PMR. */
+    /*
+     * FIXME: currently commented out as GRUB allocates it in a hole between
+     * PMR and reserved RAM, due to 2MB resolution of PMR. There are no other
+     * easy-to-use DMA protection mechanisms that would allow to protect that
+     * part of memory. TPR (TXT DMA Protection Range) gives 1MB resolution, but
+     * it still wouldn't be enough.
+     *
+     * One possible solution would be for GRUB to allocate log at lower address,
+     * but this would further increase memory space fragmentation. Another
+     * option is to align PMR up instead of down, making PMR cover part of
+     * reserved region, but it is unclear what the consequences may be.
+     *
+     * In tboot this issue was resolved by reserving leftover chunks of memory
+     * in e820 and/or UEFI memory map. This is also a valid solution, but would
+     * require more changes to GRUB than the ones listed above, as event log is
+     * allocated much earlier than PMRs.
+     */
+    /*
+    if ( os_mle->evtlog_addr != 0 && os_mle->evtlog_size != 0 &&
+         !is_in_pmr(os_sinit, os_mle->evtlog_addr, os_mle->evtlog_size,
+                    check_high_pmr) )
+        txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
+    */
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* ASM__X86__INTEL_TXT_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:06:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:06:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983189.1369583 (Exim 4.92)
	(envelope-from )
	id 1uEt5Y-0005Ll-2s; Tue, 13 May 2025 17:06:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983189.1369583; Tue, 13 May 2025 17: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 1uEt5X-0005LY-UN; Tue, 13 May 2025 17:06:43 +0000
Received: by outflank-mailman (input) for mailman id 983189;
 Tue, 13 May 2025 17:06:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5W-0003Uz-52
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:42 +0000
Received: from 3.mo560.mail-out.ovh.net (3.mo560.mail-out.ovh.net
 [46.105.58.226]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a32417f8-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:06:40 +0200 (CEST)
Received: from director11.ghost.mail-out.ovh.net (unknown [10.108.9.41])
 by mo560.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjYr0fnXz2608
 for ; Tue, 13 May 2025 17:06:40 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-zc9lv (unknown [10.111.182.11])
 by director11.ghost.mail-out.ovh.net (Postfix) with ESMTPS id E92D51FE93;
 Tue, 13 May 2025 17:06:38 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.97])
 by ghost-submission-5b5ff79f4f-zc9lv with ESMTPSA
 id v4giIh58I2hOCwAAwZMn8g
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: a32417f8-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-97G0027c0ea9b5-02f7-4c0b-a2ce-a4b0217a26c7,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 06/22] xen/arch/x86: reserve TXT memory during Slaunch
Date: Tue, 13 May 2025 20:05:43 +0300
Message-ID: <1de7add75db7b15f157adc89922470bed67bef09.1747155790.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8944148862897534108
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhggtgfgsehtkeertdertdejnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepgeekffeiiedtveekhfdugeffveeigefgleegvdeghefftdetheefueeliedukedvnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukedurddujeekpdefjedrheelrddugedvrdeljeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehiedtmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=NikVSRACtV+SZZqcNOgRXTNCO+PpplVigM2Tfg0XHoo=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156000; v=1;
 b=fZtKCBjbDDeZMd8KNSZTJYb/vINI0F8DKvSdgoBZUILNd4RKah16AszQefIyF12e8dIuMd0n
 yYvjQbpQOnuFQccFMO0sY94Me/3HiSSHNRUIPCRqOw7Ech47Ta6ZvzwA1/+3VeddU6InO02d2zf
 CMVb1UK1ZBNMtUcSMAeFt6fqpRRh/pJsolZjXKvrUx/swM8ReHcfhwYioDH4tp8v2pT1TBJmF63
 COz86IOfgQUiXi3Mgb2GHsHOu34gvAtNb4wZwuk+jaCC9CZJ5aZGbVPTfk1rSaqrFnmWQDQVdE3
 62WOWeTv1fe2VgogoXWvRlhYVko0BgYFj+Q72Zxe7Ruzg==

From: Kacper Stojek 

TXT heap, SINIT and TXT private space are marked as reserved or unused
in e820 to protect from unintended uses.

Signed-off-by: Kacper Stojek 
Signed-off-by: Krystian Hebel 
Signed-off-by: Michał Żygowski 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/Makefile                |   1 +
 xen/arch/x86/include/asm/intel-txt.h |   6 ++
 xen/arch/x86/include/asm/mm.h        |   3 +
 xen/arch/x86/include/asm/slaunch.h   |  44 +++++++++++
 xen/arch/x86/intel-txt.c             | 113 +++++++++++++++++++++++++++
 xen/arch/x86/setup.c                 |  10 ++-
 xen/arch/x86/slaunch.c               |  98 ++++++++++++++++++++++-
 7 files changed, 271 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/x86/intel-txt.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 43a80be458..6f15c5a87a 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_GDBSX) += gdbsx.o
 obj-y += hypercall.o
 obj-y += i387.o
 obj-y += i8259.o
+obj-y += intel-txt.o
 obj-y += io_apic.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-y += msi.o
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 339c29ebef..0126f56a6c 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -399,6 +399,12 @@ static inline void txt_verify_pmr_ranges(struct txt_os_mle_data *os_mle,
     */
 }
 
+/* Prepares for accesses to TXT-specific memory. */
+void txt_map_mem_regions(void);
+
+/* Marks TXT-specific memory as used to avoid its corruption. */
+void txt_reserve_mem_regions(void);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* ASM__X86__INTEL_TXT_H */
diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index d6e80db71c..91fa95cd90 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -106,6 +106,9 @@
 #define _PGC_need_scrub   _PGC_allocated
 #define PGC_need_scrub    PGC_allocated
 
+/* How much of the directmap is prebuilt at compile time. */
+#define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT)
+
 #ifndef CONFIG_BIGMEM
 /*
  * This definition is solely for the use in struct page_info (and
diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
index 3fc5f00073..ddc1bd2361 100644
--- a/xen/arch/x86/include/asm/slaunch.h
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -7,6 +7,7 @@
 #ifndef ASM__X86__SLAUNCH_H
 #define ASM__X86__SLAUNCH_H
 
+#include 
 #include 
 
 /* Indicates an active Secure Launch boot. */
@@ -18,9 +19,52 @@ extern bool slaunch_active;
  */
 extern uint32_t slaunch_slrt;
 
+/*
+ * evt_log is assigned a physical address and the caller must map it to
+ * virtual, if needed.
+ */
+static inline void find_evt_log(struct slr_table *slrt, void **evt_log,
+                                uint32_t *evt_log_size)
+{
+    struct slr_entry_log_info *log_info;
+
+    log_info = (struct slr_entry_log_info *)
+        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_LOG_INFO);
+    if ( log_info != NULL )
+    {
+        *evt_log = _p(log_info->addr);
+        *evt_log_size = log_info->size;
+    }
+    else
+    {
+        *evt_log = NULL;
+        *evt_log_size = 0;
+    }
+}
+
 /*
  * Retrieves pointer to SLRT.  Checks table's validity and maps it as necessary.
  */
 struct slr_table *slaunch_get_slrt(void);
 
+/*
+ * Prepares for accesses to essential data structures setup by boot environment.
+ */
+void slaunch_map_mem_regions(void);
+
+/* Marks regions of memory as used to avoid their corruption. */
+void slaunch_reserve_mem_regions(void);
+
+/*
+ * This helper function is used to map memory using L2 page tables by aligning
+ * mapped regions to 2MB. This way page allocator (which at this point isn't
+ * yet initialized) isn't needed for creating new L1 mappings. The function
+ * also checks and skips memory already mapped by the prebuilt tables.
+ *
+ * There is no unmap_l2() because the function is meant to be used by the code
+ * that accesses DRTM-related memory soon after which Xen rebuilds memory maps,
+ * effectively dropping all existing mappings.
+ */
+int slaunch_map_l2(unsigned long paddr, unsigned long size);
+
 #endif /* ASM__X86__SLAUNCH_H */
diff --git a/xen/arch/x86/intel-txt.c b/xen/arch/x86/intel-txt.c
new file mode 100644
index 0000000000..67051b0917
--- /dev/null
+++ b/xen/arch/x86/intel-txt.c
@@ -0,0 +1,113 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static uint64_t __initdata txt_heap_base, txt_heap_size;
+
+void __init txt_map_mem_regions(void)
+{
+    int rc;
+
+    rc = slaunch_map_l2(TXT_PRIV_CONFIG_REGS_BASE, NR_TXT_CONFIG_SIZE);
+    BUG_ON(rc != 0);
+
+    txt_heap_base = read_txt_reg(TXTCR_HEAP_BASE);
+    BUG_ON(txt_heap_base == 0);
+
+    txt_heap_size = read_txt_reg(TXTCR_HEAP_SIZE);
+    BUG_ON(txt_heap_size == 0);
+
+    rc = slaunch_map_l2(txt_heap_base, txt_heap_size);
+    BUG_ON(rc != 0);
+}
+
+/* Mark RAM region as RESERVED if it isn't marked that way already. */
+static int __init mark_ram_as(struct e820map *map, uint64_t start,
+                              uint64_t end, uint32_t type)
+{
+    unsigned int i;
+    uint32_t from_type = E820_RAM;
+
+    for ( i = 0; i < map->nr_map; i++ )
+    {
+        uint64_t rs = map->map[i].addr;
+        uint64_t re = rs + map->map[i].size;
+
+        /* The entry includes the range. */
+        if ( start >= rs && end <= re )
+            break;
+
+        /* The entry intersects the range. */
+        if ( end > rs && start < re )
+        {
+            /* Fatal failure. */
+            return 0;
+        }
+    }
+
+    /*
+     * If the range is not included by any entry and no entry intersects it,
+     * then it's not listed in the memory map.  Consider this case as a success
+     * since we're only preventing RAM from being used and unlisted range should
+     * not be used.
+     */
+    if ( i == map->nr_map )
+        return 1;
+
+    /*
+     * e820_change_range_type() fails if the range is already marked with the
+     * desired type.  Don't consider it an error if firmware has done it for us.
+     */
+    if ( map->map[i].type == type )
+        return 1;
+
+    /* E820_ACPI or E820_NVS are really unexpected, but others are fine. */
+    if ( map->map[i].type == E820_RESERVED ||
+         map->map[i].type == E820_UNUSABLE )
+        from_type = map->map[i].type;
+
+    return e820_change_range_type(map, start, end, from_type, type);
+}
+
+void __init txt_reserve_mem_regions(void)
+{
+    int rc;
+    uint64_t sinit_base, sinit_size;
+
+    /* TXT Heap */
+    BUG_ON(txt_heap_base == 0);
+    printk("SLAUNCH: reserving TXT heap (%#lx - %#lx)\n", txt_heap_base,
+           txt_heap_base + txt_heap_size);
+    rc = mark_ram_as(&e820_raw, txt_heap_base, txt_heap_base + txt_heap_size,
+                     E820_RESERVED);
+    BUG_ON(rc == 0);
+
+    sinit_base = read_txt_reg(TXTCR_SINIT_BASE);
+    BUG_ON(sinit_base == 0);
+
+    sinit_size = read_txt_reg(TXTCR_SINIT_SIZE);
+    BUG_ON(sinit_size == 0);
+
+    /* SINIT */
+    printk("SLAUNCH: reserving SINIT memory (%#lx - %#lx)\n", sinit_base,
+           sinit_base + sinit_size);
+    rc = mark_ram_as(&e820_raw, sinit_base, sinit_base + sinit_size,
+                     E820_RESERVED);
+    BUG_ON(rc == 0);
+
+    /* TXT Private Space */
+    rc = mark_ram_as(&e820_raw, TXT_PRIV_CONFIG_REGS_BASE,
+                     TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_SIZE,
+                     E820_UNUSABLE);
+    BUG_ON(rc == 0);
+}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2518954124..479d2d744e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1086,9 +1087,6 @@ static struct domain *__init create_dom0(struct boot_info *bi)
     return d;
 }
 
-/* How much of the directmap is prebuilt at compile time. */
-#define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT)
-
 void asmlinkage __init noreturn __start_xen(void)
 {
     const char *memmap_type = NULL;
@@ -1424,6 +1422,12 @@ void asmlinkage __init noreturn __start_xen(void)
 #endif
     }
 
+    if ( slaunch_active )
+    {
+        slaunch_map_mem_regions();
+        slaunch_reserve_mem_regions();
+    }
+
     /* Sanitise the raw E820 map to produce a final clean version. */
     max_page = raw_max_page = init_e820(memmap_type, &e820_raw);
 
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index a3e6ab8d71..ac3b43942b 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -7,14 +7,18 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 
 /*
  * These variables are assigned to by the code near Xen's entry point.
  *
  * slaunch_active is not __initdata to allow checking for an active Secure
- * Launch boot.
+ * Launch boot at any point.
  */
 bool slaunch_active;
 uint32_t __initdata slaunch_slrt; /* physical address */
@@ -25,3 +29,95 @@ static void __maybe_unused compile_time_checks(void)
 {
     BUILD_BUG_ON(sizeof(slaunch_active) != 1);
 }
+
+struct slr_table *__init slaunch_get_slrt(void)
+{
+    static struct slr_table *slrt;
+
+    if (slrt == NULL) {
+        int rc;
+
+        slrt = __va(slaunch_slrt);
+
+        rc = slaunch_map_l2(slaunch_slrt, PAGE_SIZE);
+        BUG_ON(rc != 0);
+
+        if ( slrt->magic != SLR_TABLE_MAGIC )
+            panic("SLRT has invalid magic value: %#08x!\n", slrt->magic);
+        /* XXX: are newer revisions allowed? */
+        if ( slrt->revision != SLR_TABLE_REVISION )
+            panic("SLRT is of unsupported revision: %#04x!\n", slrt->revision);
+        if ( slrt->architecture != SLR_INTEL_TXT )
+            panic("SLRT is for unexpected architecture: %#04x!\n",
+                  slrt->architecture);
+        if ( slrt->size > slrt->max_size )
+            panic("SLRT is larger than its max size: %#08x > %#08x!\n",
+                  slrt->size, slrt->max_size);
+
+        if ( slrt->size > PAGE_SIZE )
+        {
+            rc = slaunch_map_l2(slaunch_slrt, slrt->size);
+            BUG_ON(rc != 0);
+        }
+    }
+
+    return slrt;
+}
+
+void __init slaunch_map_mem_regions(void)
+{
+    void *evt_log_addr;
+    uint32_t evt_log_size;
+
+    /* Vendor-specific part. */
+    txt_map_mem_regions();
+
+    find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
+    if ( evt_log_addr != NULL )
+    {
+        int rc = slaunch_map_l2((uintptr_t)evt_log_addr, evt_log_size);
+        BUG_ON(rc != 0);
+    }
+}
+
+void __init slaunch_reserve_mem_regions(void)
+{
+    int rc;
+
+    void *evt_log_addr;
+    uint32_t evt_log_size;
+
+    /* Vendor-specific part. */
+    txt_reserve_mem_regions();
+
+    find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
+    if ( evt_log_addr != NULL )
+    {
+        printk("SLAUNCH: reserving event log (%#lx - %#lx)\n",
+               (uint64_t)evt_log_addr,
+               (uint64_t)evt_log_addr + evt_log_size);
+        rc = reserve_e820_ram(&e820_raw, (uint64_t)evt_log_addr,
+                              (uint64_t)evt_log_addr + evt_log_size);
+        BUG_ON(rc == 0);
+    }
+}
+
+int __init slaunch_map_l2(unsigned long paddr, unsigned long size)
+{
+    unsigned long aligned_paddr = paddr & ~((1ULL << L2_PAGETABLE_SHIFT) - 1);
+    unsigned long pages = ((paddr + size) - aligned_paddr);
+    pages = ROUNDUP(pages, 1ULL << L2_PAGETABLE_SHIFT) >> PAGE_SHIFT;
+
+    if ( aligned_paddr + pages * PAGE_SIZE <= PREBUILT_MAP_LIMIT )
+        return 0;
+
+    if ( aligned_paddr < PREBUILT_MAP_LIMIT )
+    {
+        pages -= (PREBUILT_MAP_LIMIT - aligned_paddr) >> PAGE_SHIFT;
+        aligned_paddr = PREBUILT_MAP_LIMIT;
+    }
+
+    return map_pages_to_xen((uintptr_t)__va(aligned_paddr),
+                            maddr_to_mfn(aligned_paddr),
+                            pages, PAGE_HYPERVISOR);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:10:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:10:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983241.1369592 (Exim 4.92)
	(envelope-from )
	id 1uEt9I-00008n-R8; Tue, 13 May 2025 17:10:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983241.1369592; Tue, 13 May 2025 17:10: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 1uEt9I-00008g-Nk; Tue, 13 May 2025 17:10:36 +0000
Received: by outflank-mailman (input) for mailman id 983241;
 Tue, 13 May 2025 17:10:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5z-0003Uz-Dp
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:07:11 +0000
Received: from 8.mo560.mail-out.ovh.net (8.mo560.mail-out.ovh.net
 [188.165.52.147]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b492ec12-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:07:09 +0200 (CEST)
Received: from director5.ghost.mail-out.ovh.net (unknown [10.109.140.28])
 by mo560.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZP2y6Jz2CdG
 for ; Tue, 13 May 2025 17:07:09 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-5c66f (unknown [10.111.182.37])
 by director5.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 4BD881FEB4;
 Tue, 13 May 2025 17:07:08 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.112])
 by ghost-submission-5b5ff79f4f-5c66f with ESMTPSA
 id p/jHNjt8I2jCEgEA7ssCzg
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: b492ec12-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-112S006ec180afd-be19-4646-b988-8bc4965c371d,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 16/22] x86/slaunch: process DRTM policy
Date: Tue, 13 May 2025 20:05:53 +0300
Message-ID: <26b47bcf5103017dc997de49904066bedf079b00.1747155790.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8952311634533528732
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpefhheefheduieelieekfffgfffgfedutdevleevvdfhfffgledvgfdtuddtheefieenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddrudduvdenucevlhhushhtvghrufhiiigvpeegnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehiedtmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=+X9Z9n8XXZ8AM34FtzeX1HW7feM15Wvjl9iFe+M3iTU=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156029; v=1;
 b=MmlD4mpqZ0r3Esi9148NHEB4KN9xanhtz+1g8xQ2FCBSyJNtu1N9BMSpZVZCqelHnE7m6xvG
 JwVVDE7IzD8aiiInSzf03UzInwS1qie+1KLn/0CYZ33qz+h7gcQAueEmQaVYMFDHxq8Mt9pAiqf
 hWjGgxJ58fFmmaC1nySIGX9Yvd6DCE0yMA9VshgI5H9pOmhlF/t0ST19rr6jlkyYGueu3pXLBTQ
 BRS8rEb3zmb+LCRqyHHjVXPEaoSZYQWxhWC+DCYAdA93/Tndu2zRystIXqj80CnVsbyAyApycta
 DGPUDdUTJwPWYwEPsrqMZRFRiOo/V7Q5p4pw9I5TOs0xg==

Go through entires in the DRTM policy of SLRT to hash and extend data
that they describe into corresponding PCRs.

Addresses are being zeroed on measuring platform-specific data to
prevent measurements from changing when the only thing that has changed
is an address.  Addresses can vary due to bootloader, firmware or user
doing something differently or just if GRUB gets bigger in size due to
inclusion of more modules and ends up offsetting newly allocated memory.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/include/asm/slaunch.h |  14 ++
 xen/arch/x86/setup.c               |  15 ++
 xen/arch/x86/slaunch.c             | 213 +++++++++++++++++++++++++++++
 3 files changed, 242 insertions(+)

diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
index 4ff1f9c7d5..1f98ec8de1 100644
--- a/xen/arch/x86/include/asm/slaunch.h
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -24,6 +24,8 @@
 #define DLE_EVTYPE_SLAUNCH_START   (DLE_EVTYPE_BASE + 0x103)
 #define DLE_EVTYPE_SLAUNCH_END     (DLE_EVTYPE_BASE + 0x104)
 
+struct boot_info;
+
 /* Indicates an active Secure Launch boot. */
 extern bool slaunch_active;
 
@@ -69,6 +71,18 @@ void slaunch_map_mem_regions(void);
 /* Marks regions of memory as used to avoid their corruption. */
 void slaunch_reserve_mem_regions(void);
 
+/* Measures essential parts of SLR table before making use of them. */
+void slaunch_measure_slrt(void);
+
+/*
+ * Takes measurements of DRTM policy entries except for MBI and SLRT which
+ * should have been measured by the time this is called. Also performs sanity
+ * checks of the policy and panics on failure. In particular, the function
+ * verifies that DRTM is consistent with modules obtained from MultibootInfo
+ * (MBI) and written to struct boot_info in setup.c.
+ */
+void slaunch_process_drtm_policy(const struct boot_info *bi);
+
 /*
  * This helper function is used to map memory using L2 page tables by aligning
  * mapped regions to 2MB. This way page allocator (which at this point isn't
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8e79d4be23..5d88cec6fc 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1425,6 +1425,13 @@ void asmlinkage __init noreturn __start_xen(void)
     if ( slaunch_active )
     {
         slaunch_map_mem_regions();
+
+        /*
+         * SLRT needs to be measured here because it is used by init_e820(), the
+         * rest is measured slightly below by slaunch_process_drtm_policy().
+         */
+        slaunch_measure_slrt();
+
         slaunch_reserve_mem_regions();
     }
 
@@ -1446,6 +1453,14 @@ void asmlinkage __init noreturn __start_xen(void)
     /* Create a temporary copy of the E820 map. */
     memcpy(&boot_e820, &e820, sizeof(e820));
 
+    /*
+     * Process all yet unmeasured DRTM entries after E820 initialization to not
+     * do this while memory is uncached (too slow). This must also happen before
+     * modules are relocated or used.
+     */
+    if ( slaunch_active )
+        slaunch_process_drtm_policy(bi);
+
     /* Early kexec reservation (explicit static start address). */
     nr_pages = 0;
     for ( i = 0; i < e820.nr_map; i++ )
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index 5f91fe5ad0..7cc1831f15 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -9,9 +9,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -107,6 +109,217 @@ void __init slaunch_reserve_mem_regions(void)
     }
 }
 
+void __init slaunch_measure_slrt(void)
+{
+    struct slr_table *slrt = slaunch_get_slrt();
+
+    if ( slrt->revision == 1 )
+    {
+        /*
+         * In revision one of the SLRT, only platform-specific info table is
+         * measured.
+         */
+        struct slr_entry_intel_info tmp;
+        struct slr_entry_intel_info *entry;
+
+        entry = (struct slr_entry_intel_info *)
+            slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+        if ( entry == NULL )
+            panic("SLRT is missing Intel-specific information!\n");
+
+        tmp = *entry;
+        tmp.boot_params_base = 0;
+        tmp.txt_heap = 0;
+
+        tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
+                        sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+    }
+    else
+    {
+        /*
+         * slaunch_get_slrt() checks that the revision is valid, so we must not get
+         * here unless the code is wrong.
+         */
+        panic("Unhandled SLRT revision: %d!\n", slrt->revision);
+    }
+}
+
+static struct slr_entry_policy *__init slr_get_policy(struct slr_table *slrt)
+{
+    struct slr_entry_policy *policy;
+
+    policy = (struct slr_entry_policy *)
+        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DRTM_POLICY);
+    if (policy == NULL)
+        panic("SLRT is missing DRTM policy!\n");
+
+    /* XXX: are newer revisions allowed? */
+    if ( policy->revision != SLR_POLICY_REVISION )
+        panic("DRTM policy in SLRT is of unsupported revision: %#04x!\n",
+              slrt->revision);
+
+    return policy;
+}
+
+static void __init
+check_slrt_policy_entry(struct slr_policy_entry *policy_entry,
+                        int idx,
+                        struct slr_table *slrt)
+{
+    if ( policy_entry->entity_type != SLR_ET_SLRT )
+        panic("Expected DRTM policy entry #%d to describe SLRT, got %#04x!\n",
+              idx, policy_entry->entity_type);
+    if ( policy_entry->pcr != DRTM_DATA_PCR )
+        panic("SLRT was measured to PCR-%d instead of PCR-%d!\n", DRTM_DATA_PCR,
+              policy_entry->pcr);
+    if ( policy_entry->entity != (uint64_t)__pa(slrt) )
+        panic("SLRT address (%#08lx) differs from its DRTM entry (%#08lx)\n",
+              __pa(slrt), policy_entry->entity);
+}
+
+/* Returns number of policy entries that were already measured. */
+static unsigned int __init
+check_drtm_policy(struct slr_table *slrt,
+                  struct slr_entry_policy *policy,
+                  struct slr_policy_entry *policy_entry,
+                  const struct boot_info *bi)
+{
+    uint32_t i;
+    uint32_t num_mod_entries;
+
+    if ( policy->nr_entries < 2 )
+        panic("DRTM policy in SLRT contains less than 2 entries (%d)!\n",
+              policy->nr_entries);
+
+    /*
+     * MBI policy entry must be the first one, so that measuring order matches
+     * policy order.
+     */
+    if ( policy_entry[0].entity_type != SLR_ET_MULTIBOOT2_INFO )
+        panic("First entry of DRTM policy in SLRT is not MBI: %#04x!\n",
+              policy_entry[0].entity_type);
+    if ( policy_entry[0].pcr != DRTM_DATA_PCR )
+        panic("MBI was measured to %d instead of %d PCR!\n", DRTM_DATA_PCR,
+              policy_entry[0].pcr);
+
+    /* SLRT policy entry must be the second one. */
+    check_slrt_policy_entry(&policy_entry[1], 1, slrt);
+
+    for ( i = 0; i < bi->nr_modules; i++ )
+    {
+        uint16_t j;
+        const struct boot_module *mod = &bi->mods[i];
+
+        if (mod->relocated || mod->released)
+        {
+            panic("Multiboot module \"%s\" (at %d) was consumed before measurement\n",
+                  (const char *)__va(mod->cmdline_pa), i);
+        }
+
+        for ( j = 2; j < policy->nr_entries; j++ )
+        {
+            if ( policy_entry[j].entity_type != SLR_ET_MULTIBOOT2_MODULE )
+                continue;
+
+            if ( policy_entry[j].entity == mod->start &&
+                 policy_entry[j].size == mod->size )
+                break;
+        }
+
+        if ( j >= policy->nr_entries )
+        {
+            panic("Couldn't find Multiboot module \"%s\" (at %d) in DRTM of Secure Launch\n",
+                  (const char *)__va(mod->cmdline_pa), i);
+        }
+    }
+
+    num_mod_entries = 0;
+    for ( i = 0; i < policy->nr_entries; i++ )
+    {
+        if ( policy_entry[i].entity_type == SLR_ET_MULTIBOOT2_MODULE )
+            num_mod_entries++;
+    }
+
+    if ( bi->nr_modules != num_mod_entries )
+    {
+        panic("Unexpected number of Multiboot modules: %d instead of %d\n",
+              (int)bi->nr_modules, (int)num_mod_entries);
+    }
+
+    /*
+     * MBI was measured in tpm_extend_mbi().
+     * SLRT was measured in tpm_measure_slrt().
+     */
+    return 2;
+}
+
+void __init slaunch_process_drtm_policy(const struct boot_info *bi)
+{
+    struct slr_table *slrt;
+    struct slr_entry_policy *policy;
+    struct slr_policy_entry *policy_entry;
+    uint16_t i;
+    unsigned int measured;
+
+    slrt = slaunch_get_slrt();
+
+    policy = slr_get_policy(slrt);
+    policy_entry = (struct slr_policy_entry *)
+        ((uint8_t *)policy + sizeof(*policy));
+
+    measured = check_drtm_policy(slrt, policy, policy_entry, bi);
+    for ( i = 0; i < measured; i++ )
+        policy_entry[i].flags |= SLR_POLICY_FLAG_MEASURED;
+
+    for ( i = measured; i < policy->nr_entries; i++ )
+    {
+        int rc;
+        uint64_t start = policy_entry[i].entity;
+        uint64_t size = policy_entry[i].size;
+
+        /* No already measured entries are expected here. */
+        if ( policy_entry[i].flags & SLR_POLICY_FLAG_MEASURED )
+            panic("DRTM entry at %d was measured out of order!\n", i);
+
+        switch ( policy_entry[i].entity_type )
+        {
+        case SLR_ET_MULTIBOOT2_INFO:
+            panic("Duplicated MBI entry in DRTM of Secure Launch at %d\n", i);
+        case SLR_ET_SLRT:
+            panic("Duplicated SLRT entry in DRTM of Secure Launch at %d\n", i);
+
+        case SLR_ET_UNSPECIFIED:
+        case SLR_ET_BOOT_PARAMS:
+        case SLR_ET_SETUP_DATA:
+        case SLR_ET_CMDLINE:
+        case SLR_ET_UEFI_MEMMAP:
+        case SLR_ET_RAMDISK:
+        case SLR_ET_MULTIBOOT2_MODULE:
+        case SLR_ET_TXT_OS2MLE:
+            /* Measure this entry below. */
+            break;
+
+        case SLR_ET_UNUSED:
+            /* Skip this entry. */
+            continue;
+        }
+
+        if ( policy_entry[i].flags & SLR_POLICY_IMPLICIT_SIZE )
+            panic("Unexpected implicitly-sized DRTM entry of Secure Launch at %d (type %d, info: %s)\n",
+                  i, policy_entry[i].entity_type, policy_entry[i].evt_info);
+
+        rc = slaunch_map_l2(start, size);
+        BUG_ON(rc != 0);
+
+        tpm_hash_extend(DRTM_LOC, policy_entry[i].pcr, __va(start), size,
+                        DLE_EVTYPE_SLAUNCH, (uint8_t *)policy_entry[i].evt_info,
+                        strnlen(policy_entry[i].evt_info,
+                                TPM_EVENT_INFO_LENGTH));
+
+        policy_entry[i].flags |= SLR_POLICY_FLAG_MEASURED;
+    }
+}
+
 int __init slaunch_map_l2(unsigned long paddr, unsigned long size)
 {
     unsigned long aligned_paddr = paddr & ~((1ULL << L2_PAGETABLE_SHIFT) - 1);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:10:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:10:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983244.1369603 (Exim 4.92)
	(envelope-from )
	id 1uEt9M-0000Tx-2z; Tue, 13 May 2025 17:10:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983244.1369603; Tue, 13 May 2025 17:10: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 1uEt9L-0000Tq-Uv; Tue, 13 May 2025 17:10:39 +0000
Received: by outflank-mailman (input) for mailman id 983244;
 Tue, 13 May 2025 17:10:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt6I-0003Uz-CQ
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:07:30 +0000
Received: from 8.mo576.mail-out.ovh.net (8.mo576.mail-out.ovh.net
 [46.105.56.233]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bffd3587-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:07:28 +0200 (CEST)
Received: from director8.ghost.mail-out.ovh.net (unknown [10.108.9.153])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZm441yz28h8
 for ; Tue, 13 May 2025 17:07:28 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-j6nvw (unknown [10.111.182.238])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 5376C1FDC4;
 Tue, 13 May 2025 17:07:27 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.104])
 by ghost-submission-5b5ff79f4f-j6nvw with ESMTPSA
 id R+r4A098I2hQCwAAwhyZVA
 (envelope-from ); Tue, 13 May 2025 17:07: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" 
X-Inumbo-ID: bffd3587-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-104R005288e3f3d-49dd-4252-a12b-c31cd32c9c22,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
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 ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 22/22] MAINTAINERS: add a section for TrenchBoot Slaunch
Date: Tue, 13 May 2025 20:05:59 +0300
Message-ID: <98bb81298fc94f38ea79975937e7a5aa81157493.1747155790.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8957659660426982556
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpefhheefheduieelieekfffgfffgfedutdevleevvdfhfffgledvgfdtuddtheefieenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddruddtgeenucevlhhushhtvghrufhiiigvpeeinecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehjeeimgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=8CU5n8sNAhVdjlvMK18YMG3nlKQ58o1NvkLmgNfIo+o=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156048; v=1;
 b=diSlDXfug1mbE2GRfMKugBPijf/YO7XvYtMYpvi+0BRi4FGdonNdHAhyoZ/aIf+mkoHxbNlO
 hXr8umbnvlw477RvgZAMb0uXDh1RM70BdI/NRyUpw5Vv3NeXa7D8NNRM+Y4WDm2B6w3xZ+1sYFa
 DeoWI9bzLk4R3UMUPZ6rbN/oKMS5TpnV7iXgm+4QqShjvCpYSkbPZqx+F85XH6ztGj0bRcEXfae
 JABLnVlg4zIw0mIeikSZIWwiVjAvPpHrV/9FiHjxy5G7/NJTU23caCPOJfE2+YQmAFVvNuPb2za
 Ebr6zRQYHtvNzX46zTnDHUR8H/NrbrliX7uWqAFfMTgLw==

Signed-off-by: Sergii Dmytruk 
---
 MAINTAINERS | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c11b82eca9..347b3bcbb0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -542,6 +542,21 @@ F:	*/configure
 F:	*/*.ac
 F:	tools/
 
+TRENCHBOOT SECURE LAUNCH
+M:	Daniel P. Smith 
+R:	Ross Philipson 
+R:	Sergii Dmytruk 
+S:	Supported
+F:	xen/include/xen/slr-table.h
+F:	xen/arch/x86/boot/slaunch-early.c
+F:	xen/arch/x86/efi/fixmlehdr.c
+F:	xen/arch/x86/include/asm/intel-txt.h
+F:	xen/arch/x86/include/asm/slaunch.h
+F:	xen/arch/x86/include/asm/tpm.h
+F:	xen/arch/x86/intel-txt.c
+F:	xen/arch/x86/slaunch.c
+F:	xen/arch/x86/tpm.c
+
 VM EVENT, MEM ACCESS and MONITOR
 M:	Tamas K Lengyel 
 R:	Alexandru Isaila 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:10:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:10:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983245.1369606 (Exim 4.92)
	(envelope-from )
	id 1uEt9M-0000XT-A0; Tue, 13 May 2025 17:10:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983245.1369606; Tue, 13 May 2025 17:10: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 1uEt9M-0000W0-66; Tue, 13 May 2025 17:10:40 +0000
Received: by outflank-mailman (input) for mailman id 983245;
 Tue, 13 May 2025 17:10:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5n-0003Uz-2u
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:59 +0000
Received: from 1.mo575.mail-out.ovh.net (1.mo575.mail-out.ovh.net
 [46.105.41.146]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ad499f14-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:06:57 +0200 (CEST)
Received: from director10.ghost.mail-out.ovh.net (unknown [10.108.17.234])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZ903vYz1sPK
 for ; Tue, 13 May 2025 17:06:56 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-frdbc (unknown [10.110.118.120])
 by director10.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 53D9C1FE02;
 Tue, 13 May 2025 17:06:56 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.114])
 by ghost-submission-5b5ff79f4f-frdbc with ESMTPSA
 id zV6+ADB8I2jomQcAYR2MaQ
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: ad499f14-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-114S00879e9d5e9-aa55-4b5a-911e-f42410b055f4,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 12/22] x86/hvm: check for VMX in SMX if Slaunch is active
Date: Tue, 13 May 2025 20:05:49 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8948652463133537436
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhggtgfgsehtkeertdertdejnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepgeekffeiiedtveekhfdugeffveeigefgleegvdeghefftdetheefueeliedukedvnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukedurddujeekpdefjedrheelrddugedvrdduudegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheejhegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=QnIKAND7PaaYiBZpdm/P7GTarwHPzvaPJ5XCEeh+pOQ=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156017; v=1;
 b=VzxWWIYxhIyfqWtPHgEDUu+GFg49EFzsOGB3xjFxv8UTm08ad5Ir1uP3XX78Kfm7N/jGXYZC
 QWqrlcWUyU37SGZxEuJ72cF4Qq5sV169PW7JihtnDDOa2TZpwNdPSVo0f0JMU+ONlpP5EEwfYRt
 2fKUVM4uM5DKQUEy4CkUdHJoq6NnBpEJVzOZiAdCQv5L4+OJ4InKO1+UA2wk+MaQSHEAXIFDleN
 7N/bbyBR3nin47UZjjY53EVqHwpVd0RHkJOzZZ1xTAIf8TVl2l/u5SFAdRX9ZkB1eaOdN11XQli
 FN63Wo8gZetsyBPrmzNrZbERO/eersj7ia+9BYB2kWPpg==

From: Michał Żygowski 

Check whther IA32_FEATURE_CONTROL has the proper bits enabled to run
VMX in SMX when slaunch is active.

Signed-off-by: Michał Żygowski 
---
 xen/arch/x86/hvm/vmx/vmcs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index a44475ae15..ef38903775 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -724,7 +725,7 @@ static int _vmx_cpu_up(bool bsp)
     bios_locked = !!(eax & IA32_FEATURE_CONTROL_LOCK);
     if ( bios_locked )
     {
-        if ( !(eax & (tboot_in_measured_env()
+        if ( !(eax & (tboot_in_measured_env() || slaunch_active
                       ? IA32_FEATURE_CONTROL_ENABLE_VMXON_INSIDE_SMX
                       : IA32_FEATURE_CONTROL_ENABLE_VMXON_OUTSIDE_SMX)) )
         {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:10:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:10:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983248.1369611 (Exim 4.92)
	(envelope-from )
	id 1uEt9M-0000c2-L2; Tue, 13 May 2025 17:10:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983248.1369611; Tue, 13 May 2025 17:10: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 1uEt9M-0000Zt-GT; Tue, 13 May 2025 17:10:40 +0000
Received: by outflank-mailman (input) for mailman id 983248;
 Tue, 13 May 2025 17:10:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5q-0003Uz-2M
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:07:02 +0000
Received: from 10.mo576.mail-out.ovh.net (10.mo576.mail-out.ovh.net
 [46.105.73.241]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aedadc13-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:07:00 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.109.176.96])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZC5nZ5z25NM
 for ; Tue, 13 May 2025 17:06:59 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-r9289 (unknown [10.111.174.38])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 0EAB51FD9F;
 Tue, 13 May 2025 17:06:58 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.102])
 by ghost-submission-5b5ff79f4f-r9289 with ESMTPSA
 id BqUzLzJ8I2geNAEAW9b/4w
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: aedadc13-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-102R004bc407770-aa6c-47a9-8912-a5c517905175,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 13/22] x86/tpm.c: implement event log for TPM2.0
Date: Tue, 13 May 2025 20:05:50 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8949496886597956764
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpefhheefheduieelieekfffgfffgfedutdevleevvdfhfffgledvgfdtuddtheefieenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddruddtvdenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehjeeimgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=zv064gKVpCT4u14nztfo5gjyl4d57jChW3ReE92Rvms=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156019; v=1;
 b=iS/E/9lBHuzdM+oyi/1VGkODzt2JG3MuXkqC3F9EYdPGvr0SfhGkHgeGSephf57lzpdjk2xQ
 j+SKHJO2leZo2RFJ26hM5MGrLRsKakDTCBgHY42jnE5BblLD+hjq9QwdurfZ+cPgl54joHL1+te
 FPxVc3MuPNYrd43XGiIt/aCFt698MGL94R5a5uRCTNMkjb1TFwuZg8+bkciqT6wtm8GSYmLTtGx
 I5ITMipDOMGSH7ZP75hJ7oCf5YEcx6tLymT1qfCO3Otpqmusrs+rM/CQDnFQdSvuCBi5p3qYyau
 kcoGjyBxB3h2LQBnulUeDcJI0fti7ob/MIZOfBLq2bSrA==

Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/include/asm/intel-txt.h |  33 ++++++
 xen/arch/x86/tpm.c                   | 169 ++++++++++++++++++++++-----
 2 files changed, 175 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index f0ec580558..bc51d2d287 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -202,6 +202,39 @@ struct txt_sinit_mle_data {
     /* Ext Data Elements */
 } __packed;
 
+/* Types of extended data. */
+#define TXT_HEAP_EXTDATA_TYPE_END                    0
+#define TXT_HEAP_EXTDATA_TYPE_BIOS_SPEC_VER          1
+#define TXT_HEAP_EXTDATA_TYPE_ACM                    2
+#define TXT_HEAP_EXTDATA_TYPE_STM                    3
+#define TXT_HEAP_EXTDATA_TYPE_CUSTOM                 4
+#define TXT_HEAP_EXTDATA_TYPE_MADT                   6
+#define TXT_HEAP_EXTDATA_TYPE_EVENT_LOG_POINTER2_1   8
+#define TXT_HEAP_EXTDATA_TYPE_MCFG                   9
+#define TXT_HEAP_EXTDATA_TYPE_TPR_REQ               13
+#define TXT_HEAP_EXTDATA_TYPE_DTPR                  14
+#define TXT_HEAP_EXTDATA_TYPE_CEDT                  15
+
+/*
+ * Self-describing data structure that is used for extensions to TXT heap
+ * tables.
+ */
+struct txt_ext_data_element {
+    uint32_t type;   /* One of TXT_HEAP_EXTDATA_TYPE_*. */
+    uint32_t size;
+    uint8_t data[0]; /* size bytes. */
+} __packed;
+
+/*
+ * Extended data describing TPM 2.0 log.
+ */
+struct heap_event_log_pointer_element2_1 {
+    uint64_t physical_address;
+    uint32_t allocated_event_container_size;
+    uint32_t first_record_offset;
+    uint32_t next_record_offset;
+} __packed;
+
 /*
  * Functions to extract data from the Intel TXT Heap Memory. The layout
  * of the heap is as follows:
diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
index ed49fe3ccf..47a9edef50 100644
--- a/xen/arch/x86/tpm.c
+++ b/xen/arch/x86/tpm.c
@@ -536,6 +536,44 @@ struct tpm2_log_hashes {
     struct tpm2_log_hash hashes[MAX_HASH_COUNT];
 };
 
+struct tpm2_pcr_event_header {
+    uint32_t pcrIndex;
+    uint32_t eventType;
+    uint32_t digestCount;
+    uint8_t digests[0];
+    /*
+     * Each hash is represented as:
+     * struct {
+     *     uint16_t hashAlg;
+     *     uint8_t hash[size of hashAlg];
+     * };
+     */
+    /* uint32_t eventSize; */
+    /* uint8_t event[0]; */
+} __packed;
+
+struct tpm2_digest_sizes {
+    uint16_t algId;
+    uint16_t digestSize;
+} __packed;
+
+struct tpm2_spec_id_event {
+    uint32_t pcrIndex;
+    uint32_t eventType;
+    uint8_t digest[20];
+    uint32_t eventSize;
+    uint8_t signature[16];
+    uint32_t platformClass;
+    uint8_t specVersionMinor;
+    uint8_t specVersionMajor;
+    uint8_t specErrata;
+    uint8_t uintnSize;
+    uint32_t digestCount;
+    struct tpm2_digest_sizes digestSizes[0]; /* variable number of members */
+    /* uint8_t vendorInfoSize; */
+    /* uint8_t vendorInfo[vendorInfoSize]; */
+} __packed;
+
 #ifdef __EARLY_SLAUNCH__
 
 union tpm2_cmd_rsp {
@@ -769,19 +807,11 @@ static uint32_t tpm2_hash_extend(unsigned loc, const uint8_t *buf,
         }
 
         if ( hash->alg == TPM_ALG_SHA1 )
-        {
             sha1_hash(hash->data, buf, size);
-        }
         else if ( hash->alg == TPM_ALG_SHA256 )
-        {
             sha2_256_digest(hash->data, buf, size);
-        }
         else
-        {
-            /* This is called "OneDigest" in TXT Software Development Guide. */
-            memset(hash->data, 0, size);
-            hash->data[0] = 1;
-        }
+            /* create_log_event20() took care of initializing the digest. */;
 
         if ( supported_hashes.count == MAX_HASH_COUNT )
         {
@@ -802,6 +832,102 @@ static uint32_t tpm2_hash_extend(unsigned loc, const uint8_t *buf,
 
 #endif /* __EARLY_SLAUNCH__ */
 
+static struct heap_event_log_pointer_element2_1 *find_evt_log_ext_data(void)
+{
+    struct txt_os_sinit_data *os_sinit;
+    struct txt_ext_data_element *ext_data;
+
+    os_sinit = txt_os_sinit_data_start(__va(read_txt_reg(TXTCR_HEAP_BASE)));
+    ext_data = (void *)((uint8_t *)os_sinit + sizeof(*os_sinit));
+
+    /*
+     * Find TXT_HEAP_EXTDATA_TYPE_EVENT_LOG_POINTER2_1 which is necessary to
+     * know where to put the next entry.
+     */
+    while ( ext_data->type != TXT_HEAP_EXTDATA_TYPE_END )
+    {
+        if ( ext_data->type == TXT_HEAP_EXTDATA_TYPE_EVENT_LOG_POINTER2_1 )
+            break;
+        ext_data = (void *)&ext_data->data[ext_data->size];
+    }
+
+    if ( ext_data->type == TXT_HEAP_EXTDATA_TYPE_END )
+        return NULL;
+
+    return (void *)&ext_data->data[0];
+}
+
+static struct tpm2_log_hashes
+create_log_event20(struct tpm2_spec_id_event *evt_log, uint32_t evt_log_size,
+                   uint32_t pcr, uint32_t type, const uint8_t *data,
+                   unsigned data_size)
+{
+    struct tpm2_log_hashes log_hashes = {0};
+
+    struct heap_event_log_pointer_element2_1 *log_ext_data;
+    struct tpm2_pcr_event_header *new_entry;
+    uint32_t entry_size;
+    unsigned i;
+    uint8_t *p;
+
+    log_ext_data = find_evt_log_ext_data();
+    if ( log_ext_data == NULL )
+        return log_hashes;
+
+    entry_size = sizeof(*new_entry);
+    for ( i = 0; i < evt_log->digestCount; ++i )
+    {
+        entry_size += sizeof(uint16_t); /* hash type */
+        entry_size += evt_log->digestSizes[i].digestSize;
+    }
+    entry_size += sizeof(uint32_t); /* data size field */
+    entry_size += data_size;
+
+    /*
+     * Check if there is enough space left for new entry.
+     * Note: it is possible to introduce a gap in event log if entry with big
+     * data_size is followed by another entry with smaller data. Maybe we should
+     * cap the event log size in such case?
+     */
+    if ( log_ext_data->next_record_offset + entry_size > evt_log_size )
+        return log_hashes;
+
+    new_entry = (void *)((uint8_t *)evt_log + log_ext_data->next_record_offset);
+    log_ext_data->next_record_offset += entry_size;
+
+    new_entry->pcrIndex = pcr;
+    new_entry->eventType = type;
+    new_entry->digestCount = evt_log->digestCount;
+
+    p = &new_entry->digests[0];
+    for ( i = 0; i < evt_log->digestCount; ++i )
+    {
+        uint16_t alg = evt_log->digestSizes[i].algId;
+        uint16_t size = evt_log->digestSizes[i].digestSize;
+
+        *(uint16_t *)p = alg;
+        p += sizeof(uint16_t);
+
+        log_hashes.hashes[i].alg = alg;
+        log_hashes.hashes[i].size = size;
+        log_hashes.hashes[i].data = p;
+        p += size;
+
+        /* This is called "OneDigest" in TXT Software Development Guide. */
+        memset(log_hashes.hashes[i].data, 0, size);
+        log_hashes.hashes[i].data[0] = 1;
+    }
+    log_hashes.count = evt_log->digestCount;
+
+    *(uint32_t *)p = data_size;
+    p += sizeof(uint32_t);
+
+    if ( data && data_size > 0 )
+        memcpy(p, data, data_size);
+
+    return log_hashes;
+}
+
 /************************** end of TPM2.0 specific ****************************/
 
 void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
@@ -832,26 +958,15 @@ void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
             printk(XENLOG_ERR "Extending PCR%u failed\n", pcr);
 #endif
         }
-    } else {
-        uint8_t sha1_digest[SHA1_DIGEST_SIZE];
-        uint8_t sha256_digest[SHA2_256_DIGEST_SIZE];
+    }
+    else
+    {
         uint32_t rc;
 
-        struct tpm2_log_hashes log_hashes = {
-            .count = 2,
-            .hashes = {
-                {
-                    .alg = TPM_ALG_SHA1,
-                    .size = SHA1_DIGEST_SIZE,
-                    .data = sha1_digest,
-                },
-                {
-                    .alg = TPM_ALG_SHA256,
-                    .size = SHA2_256_DIGEST_SIZE,
-                    .data = sha256_digest,
-                },
-            },
-        };
+        struct tpm2_spec_id_event *evt_log = evt_log_addr;
+        struct tpm2_log_hashes log_hashes =
+            create_log_event20(evt_log, evt_log_size, pcr, type, log_data,
+                               log_data_size);
 
         rc = tpm2_hash_extend(loc, buf, size, pcr, &log_hashes);
         if ( rc != 0 )
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:10:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:10:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983249.1369622 (Exim 4.92)
	(envelope-from )
	id 1uEt9N-0000iE-6H; Tue, 13 May 2025 17:10:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983249.1369622; Tue, 13 May 2025 17:10: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 1uEt9M-0000gJ-QA; Tue, 13 May 2025 17:10:40 +0000
Received: by outflank-mailman (input) for mailman id 983249;
 Tue, 13 May 2025 17:10:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt65-0003Uz-3n
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:07:17 +0000
Received: from 10.mo575.mail-out.ovh.net (10.mo575.mail-out.ovh.net
 [46.105.79.203]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b808cb69-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:07:15 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.109.140.131])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZW1VdFz1wl3
 for ; Tue, 13 May 2025 17:07:15 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-dvfkr (unknown [10.110.164.235])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 8C40F1FE68;
 Tue, 13 May 2025 17:07:14 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.109])
 by ghost-submission-5b5ff79f4f-dvfkr with ESMTPSA
 id HnomBUJ8I2jxxBEAOV1++g
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: b808cb69-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-109S0033a991904-3eb6-4068-85c9-331bc12d345b,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 18/22] x86/boot/slaunch-early: find MBI and SLRT on AMD
Date: Tue, 13 May 2025 20:05:55 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8954000486706885788
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeekudegfeduieegudeijeelleekfedvvdfhheehvefhudekjeeifeegtdduveehtdenucffohhmrghinhephhgvrggurdhssgenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddruddtleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehjeehmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=yySsErvLYNnWYhNOhBBhYnFBoZFsMFllBN/X8yrHl2s=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156035; v=1;
 b=IAUgrFh7F5GxgfDt72R0UBqjTlZF2yuEKotAKvq+W1jT0UbN/T3redg7LWwTuoQnj4elT/oP
 ivhU2XZ5Ht9Plw6CkbNCaAbKUyM3XuT3eh8Kki/Xkqdx8b4wDJdwlr+LAjvWP47h71w+2VhxcFi
 gZ8UBBcGDXO4laWhk6+NUHx+hNnEvxuCZB2QYeDSRKPT61Gdc3/bXGsmGFh3/oQGKnl9jVUueCz
 dDj5YpKUMFUc2lWqJmuv/cRr3q0zCpRJ4wL/wUBEi18EbrBDoHJLJBHErycwVc0C5HGh7lpwJ6j
 AImZZhq5C1ZEGnTwv72agIuOTW/0tbr4cYFjMBGDrKUdw==

Use slr_entry_amd_info::boot_params_base on AMD with SKINIT to get MBI
location.

Another thing of interest is the location of SLRT which is bootloader's
data after SKL.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/boot/head.S          | 38 ++++++++++++++++----
 xen/arch/x86/boot/slaunch-early.c | 58 +++++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 7376fa85d5..66e1a21033 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -354,10 +354,12 @@ cs32_switch:
         jmp     *%edi
 
         /*
-         * Entry point for TrenchBoot Secure Launch on Intel TXT platforms.
+         * Entry point for TrenchBoot Secure Launch, common for Intel TXT and
+         * AMD Secure Startup, but state is slightly different.
          *
+         * On Intel:
          * CPU is in 32b protected mode with paging disabled. On entry:
-         * - %ebx = %eip = MLE entry point,
+         * - %ebx = %eip = this entry point,
          * - stack pointer is undefined,
          * - CS is flat 4GB code segment,
          * - DS, ES, SS, FS and GS are undefined according to TXT SDG, but this
@@ -375,13 +377,34 @@ cs32_switch:
          * - trying to enter real mode results in reset
          * - APs must be brought up by MONITOR or GETSEC[WAKEUP], depending on
          *   which is supported by a given SINIT ACM
+         *
+         * On AMD (as implemented by TrenchBoot's SKL):
+         * CPU is in 32b protected mode with paging disabled. On entry:
+         * - %ebx = %eip = this entry point,
+         * - %ebp holds base address of SKL
+         * - stack pointer is treated as undefined for parity with TXT,
+         * - CS is flat 4GB code segment,
+         * - DS, ES, SS are flat 4GB data segments, but treated as undefined for
+         *   parity with TXT.
+         *
+         * Additional restrictions:
+         * - interrupts (including NMIs and SMIs) are disabled and must be
+         *   enabled later
+         * - APs must be brought up by SIPI without an INIT
          */
 slaunch_stub_entry:
         /* Calculate the load base address. */
         mov     %ebx, %esi
         sub     $sym_offs(slaunch_stub_entry), %esi
 
-        /* Mark Secure Launch boot protocol and jump to common entry. */
+        /* On AMD, %ebp holds the base address of SLB, save it for later. */
+        mov     %ebp, %ebx
+
+        /*
+         * Mark Secure Launch boot protocol and jump to common entry. Note that
+         * all general purpose registers except %ebx and %esi are clobbered
+         * between here and .Lslaunch_proto.
+         */
         mov     $SLAUNCH_BOOTLOADER_MAGIC, %eax
         jmp     .Lset_stack
 
@@ -508,15 +531,18 @@ __start:
         sub     $8, %esp
 
         push    %esp                             /* pointer to output structure */
+        push    %ebx                             /* Slaunch parameter on AMD */
         lea     sym_offs(__2M_rwdata_end), %ecx  /* end of target image */
         lea     sym_offs(_start), %edx           /* target base address */
         mov     %esi, %eax                       /* load base address */
         /*
-         * slaunch_early_init(load/eax, tgt/edx, tgt_end/ecx, ret/stk) using
-         * fastcall calling convention.
+         * slaunch_early_init(load/eax, tgt/edx, tgt_end/ecx,
+         *                     slaunch/stk, ret/stk)
+         *
+         * Uses fastcall calling convention.
          */
         call    slaunch_early_init
-        add     $4, %esp                         /* pop the fourth parameter */
+        add     $8, %esp                         /* pop last two parameters */
 
         /* Move outputs of slaunch_early_init() from stack into registers. */
         pop     %eax  /* physical MBI address */
diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
index b6f6deedc9..e886d1bba7 100644
--- a/xen/arch/x86/boot/slaunch-early.c
+++ b/xen/arch/x86/boot/slaunch-early.c
@@ -7,6 +7,20 @@
 #include 
 #include 
 #include 
+#include 
+
+/*
+ * The AMD-defined structure layout for the SLB. The last two fields are
+ * SL-specific.
+ */
+struct skinit_sl_header
+{
+    uint16_t skl_entry_point;
+    uint16_t length;
+    uint8_t reserved[62];
+    uint16_t skl_info_offset;
+    uint16_t bootloader_data_offset;
+} __packed;
 
 struct early_init_results
 {
@@ -14,9 +28,25 @@ struct early_init_results
     uint32_t slrt_pa;
 } __packed;
 
+static bool is_intel_cpu(void)
+{
+    /*
+     * asm/processor.h can't be included in early code, which means neither
+     * cpuid() function nor boot_cpu_data can be used here.
+     */
+    uint32_t eax, ebx, ecx, edx;
+    asm volatile ( "cpuid"
+          : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
+          : "0" (0), "c" (0) );
+    return ebx == X86_VENDOR_INTEL_EBX
+        && ecx == X86_VENDOR_INTEL_ECX
+        && edx == X86_VENDOR_INTEL_EDX;
+}
+
 void asmlinkage slaunch_early_init(uint32_t load_base_addr,
                                    uint32_t tgt_base_addr,
                                    uint32_t tgt_end_addr,
+                                   uint32_t slaunch_param,
                                    struct early_init_results *result)
 {
     void *txt_heap;
@@ -26,6 +56,34 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
     struct slr_entry_intel_info *intel_info;
     uint32_t size = tgt_end_addr - tgt_base_addr;
 
+    if ( !is_intel_cpu() )
+    {
+        /*
+         * Not an Intel CPU. Currently the only other option is AMD with SKINIT
+         * and secure-kernel-loader (SKL).
+         */
+        struct slr_entry_amd_info *amd_info;
+        const struct skinit_sl_header *sl_header = (void *)slaunch_param;
+
+        /*
+         * slaunch_param holds a physical address of SLB.
+         * Bootloader's data is SLRT.
+         */
+        result->slrt_pa = slaunch_param + sl_header->bootloader_data_offset;
+        result->mbi_pa = 0;
+
+        slrt = (struct slr_table *)(uintptr_t)result->slrt_pa;
+
+        amd_info = (struct slr_entry_amd_info *)
+            slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_AMD_INFO);
+        /* Basic checks only, SKL checked and consumed the rest. */
+        if ( amd_info == NULL || amd_info->hdr.size != sizeof(*amd_info) )
+            return;
+
+        result->mbi_pa = amd_info->boot_params_base;
+        return;
+    }
+
     txt_heap = txt_init();
     os_mle = txt_os_mle_data_start(txt_heap);
     os_sinit = txt_os_sinit_data_start(txt_heap);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:10:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:10:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983250.1369626 (Exim 4.92)
	(envelope-from )
	id 1uEt9N-0000rx-Hi; Tue, 13 May 2025 17:10:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983250.1369626; Tue, 13 May 2025 17:10: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 1uEt9N-0000pg-8u; Tue, 13 May 2025 17:10:41 +0000
Received: by outflank-mailman (input) for mailman id 983250;
 Tue, 13 May 2025 17:10:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt67-0003Mm-8n
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:07:19 +0000
Received: from 5.mo576.mail-out.ovh.net (5.mo576.mail-out.ovh.net
 [46.105.43.105]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b9c2dcc8-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:07:18 +0200 (CEST)
Received: from director9.ghost.mail-out.ovh.net (unknown [10.109.148.7])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZZ0sZDz27tZ
 for ; Tue, 13 May 2025 17:07:18 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-ss9cm (unknown [10.108.54.212])
 by director9.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 460481FE9A;
 Tue, 13 May 2025 17:07:17 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.114])
 by ghost-submission-5b5ff79f4f-ss9cm with ESMTPSA
 id 2DmeAEV8I2gIEQEAgzAcRQ
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: b9c2dcc8-301c-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-114S008001f1f46-d194-4037-818a-410a4b9d68a0,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 19/22] x86/slaunch: support AMD SKINIT
Date: Tue, 13 May 2025 20:05:56 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8954844911462364316
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpefhheefheduieelieekfffgfffgfedutdevleevvdfhfffgledvgfdtuddtheefieenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddruddugeenucevlhhushhtvghrufhiiigvpeehnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehjeeimgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=I4A1LgkNpCIY8hzEp8h2TJ6VL6QVw7kE9g1WIgyMW2Q=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156038; v=1;
 b=OGQxphxCyM44df28KvwcxsN4P4Ryh5QW7XoLVUAv+Ed5Q4dT7TyS0s6qjZj3zCsAOUo2spoa
 1npnk5utsMfiHhDutLoM8kUWCHE47d651KU4eAq80UYrAW6eMJr+PqmtpZtZYm6+E2SZ5h7Qv61
 NYuwvnvDGIuPVYUqOU9qc8fullaxAffJ7bN80vGFygiQplKKC0TdcBk7mCqdyCP3QnJPpTTOGUL
 GPA9O8pb+OsccKJmC0rAwgctc8L78Kik1LRix5NM8byfykk8UqiRnsEGKmUiUj/KRobQrlUHf7D
 qyil0sWm9TSSD0Neumg+4AL+wQamthMH44PwnRFHLSnQQ==

This mostly involves not running Intel-specific code when on AMD.

There are only a few new AMD-specific implementation details:
 - finding SLB start and size and then mapping and reserving it in e820
 - managing offset for adding the next TPM log entry (TXT-compatible
   data prepared by SKL is stored inside of vendor data field within TCG
   header)

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/e820.c    |  2 +-
 xen/arch/x86/slaunch.c | 90 ++++++++++++++++++++++++++++++++++--------
 xen/arch/x86/tpm.c     | 68 ++++++++++++++++++++++++++++++-
 3 files changed, 141 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index 60f00e5259..cf13ab269a 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -444,7 +444,7 @@ static uint64_t __init mtrr_top_of_ram(void)
     ASSERT(paddr_bits);
     addr_mask = ((1ULL << paddr_bits) - 1) & PAGE_MASK;
 
-    if ( slaunch_active )
+    if ( slaunch_active && boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
         txt_restore_mtrrs(e820_verbose);
 
     rdmsrl(MSR_MTRRcap, mtrr_cap);
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index 7cc1831f15..f0447f91d2 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -17,6 +17,10 @@
 #include 
 #include 
 
+/* SLB is 64k, 64k-aligned */
+#define SKINIT_SLB_SIZE   0x10000
+#define SKINIT_SLB_ALIGN  0x10000
+
 /*
  * These variables are assigned to by the code near Xen's entry point.
  *
@@ -39,6 +43,8 @@ struct slr_table *__init slaunch_get_slrt(void)
 
     if (slrt == NULL) {
         int rc;
+        bool intel_cpu = (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL);
+        uint16_t slrt_architecture = intel_cpu ? SLR_INTEL_TXT : SLR_AMD_SKINIT;
 
         slrt = __va(slaunch_slrt);
 
@@ -50,9 +56,9 @@ struct slr_table *__init slaunch_get_slrt(void)
         /* XXX: are newer revisions allowed? */
         if ( slrt->revision != SLR_TABLE_REVISION )
             panic("SLRT is of unsupported revision: %#04x!\n", slrt->revision);
-        if ( slrt->architecture != SLR_INTEL_TXT )
-            panic("SLRT is for unexpected architecture: %#04x!\n",
-                  slrt->architecture);
+        if ( slrt->architecture != slrt_architecture )
+            panic("SLRT is for unexpected architecture: %#04x != %#04x!\n",
+                  slrt->architecture, slrt_architecture);
         if ( slrt->size > slrt->max_size )
             panic("SLRT is larger than its max size: %#08x > %#08x!\n",
                   slrt->size, slrt->max_size);
@@ -67,6 +73,23 @@ struct slr_table *__init slaunch_get_slrt(void)
     return slrt;
 }
 
+static uint32_t __init get_slb_start(void)
+{
+    /*
+     * The runtime computation relies on size being a power of 2 and equal to
+     * alignment. Make sure these assumptions hold.
+     */
+    BUILD_BUG_ON(SKINIT_SLB_SIZE != SKINIT_SLB_ALIGN);
+    BUILD_BUG_ON(SKINIT_SLB_SIZE == 0);
+    BUILD_BUG_ON((SKINIT_SLB_SIZE & (SKINIT_SLB_SIZE - 1)) != 0);
+
+    /*
+     * Rounding any address within SLB down to alignment gives SLB base and
+     * SLRT is inside SLB on AMD.
+     */
+    return slaunch_slrt & ~(SKINIT_SLB_SIZE - 1);
+}
+
 void __init slaunch_map_mem_regions(void)
 {
     int rc;
@@ -77,7 +100,10 @@ void __init slaunch_map_mem_regions(void)
     BUG_ON(rc != 0);
 
     /* Vendor-specific part. */
-    txt_map_mem_regions();
+    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+        txt_map_mem_regions();
+    else if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+        slaunch_map_l2(get_slb_start(), SKINIT_SLB_SIZE);
 
     find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
     if ( evt_log_addr != NULL )
@@ -95,7 +121,18 @@ void __init slaunch_reserve_mem_regions(void)
     uint32_t evt_log_size;
 
     /* Vendor-specific part. */
-    txt_reserve_mem_regions();
+    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+    {
+        txt_reserve_mem_regions();
+    }
+    else if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+    {
+        uint64_t slb_start = get_slb_start();
+        uint64_t slb_end = slb_start + SKINIT_SLB_SIZE;
+        printk("SLAUNCH: reserving SLB (%#lx - %#lx)\n", slb_start, slb_end);
+        rc = reserve_e820_ram(&e820_raw, slb_start, slb_end);
+        BUG_ON(rc == 0);
+    }
 
     find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
     if ( evt_log_addr != NULL )
@@ -119,20 +156,41 @@ void __init slaunch_measure_slrt(void)
          * In revision one of the SLRT, only platform-specific info table is
          * measured.
          */
-        struct slr_entry_intel_info tmp;
-        struct slr_entry_intel_info *entry;
+        if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+        {
+            struct slr_entry_intel_info tmp;
+            struct slr_entry_intel_info *entry;
+
+            entry = (struct slr_entry_intel_info *)
+                slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+            if ( entry == NULL )
+                panic("SLRT is missing Intel-specific information!\n");
 
-        entry = (struct slr_entry_intel_info *)
-            slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
-        if ( entry == NULL )
-            panic("SLRT is missing Intel-specific information!\n");
+            tmp = *entry;
+            tmp.boot_params_base = 0;
+            tmp.txt_heap = 0;
 
-        tmp = *entry;
-        tmp.boot_params_base = 0;
-        tmp.txt_heap = 0;
+            tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
+                            sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+        }
+        else if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+        {
+            struct slr_entry_amd_info tmp;
+            struct slr_entry_amd_info *entry;
+
+            entry = (struct slr_entry_amd_info *)
+                slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_AMD_INFO);
+            if ( entry == NULL )
+                panic("SLRT is missing AMD-specific information!\n");
 
-        tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
-                        sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+            tmp = *entry;
+            tmp.next = 0;
+            tmp.slrt_base = 0;
+            tmp.boot_params_base = 0;
+
+            tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
+                            sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+        }
     }
     else
     {
diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
index 47a9edef50..e9ba073d55 100644
--- a/xen/arch/x86/tpm.c
+++ b/xen/arch/x86/tpm.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef __EARLY_SLAUNCH__
 
@@ -52,11 +53,31 @@ void *(memcpy)(void *dest, const void *src, size_t n)
     return dest;
 }
 
+static bool is_amd_cpu(void)
+{
+    /*
+     * asm/processor.h can't be included in early code, which means neither
+     * cpuid() function nor boot_cpu_data can be used here.
+     */
+    uint32_t eax, ebx, ecx, edx;
+    asm volatile ( "cpuid"
+          : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
+          : "0" (0), "c" (0) );
+    return ebx == X86_VENDOR_AMD_EBX
+        && ecx == X86_VENDOR_AMD_ECX
+        && edx == X86_VENDOR_AMD_EDX;
+}
+
 #else   /* __EARLY_SLAUNCH__ */
 
 #include 
 #include 
 
+static bool is_amd_cpu(void)
+{
+    return boot_cpu_data.x86_vendor == X86_VENDOR_AMD;
+}
+
 #endif  /* __EARLY_SLAUNCH__ */
 
 #define TPM_LOC_REG(loc, reg)   (0x1000 * (loc) + (reg))
@@ -241,6 +262,21 @@ struct TPM12_PCREvent {
     uint8_t Data[];
 };
 
+struct tpm1_spec_id_event {
+    uint32_t pcrIndex;
+    uint32_t eventType;
+    uint8_t digest[20];
+    uint32_t eventSize;
+    uint8_t signature[16];
+    uint32_t platformClass;
+    uint8_t specVersionMinor;
+    uint8_t specVersionMajor;
+    uint8_t specErrata;
+    uint8_t uintnSize;
+    uint8_t vendorInfoSize;
+    uint8_t vendorInfo[0];  /* variable number of members */
+} __packed;
+
 struct txt_ev_log_container_12 {
     char        Signature[20];      /* "TXT Event Container", null-terminated */
     uint8_t     Reserved[12];
@@ -384,6 +420,16 @@ static void *create_log_event12(struct txt_ev_log_container_12 *evt_log,
 {
     struct TPM12_PCREvent *new_entry;
 
+    if ( is_amd_cpu() )
+    {
+        /*
+         * On AMD, TXT-compatible structure is stored as vendor data of
+         * TCG-defined event log header.
+         */
+        struct tpm1_spec_id_event *spec_id = (void *)evt_log;
+        evt_log = (struct txt_ev_log_container_12 *)&spec_id->vendorInfo[0];
+    }
+
     new_entry = (void *)(((uint8_t *)evt_log) + evt_log->NextEventOffset);
 
     /*
@@ -832,11 +878,29 @@ static uint32_t tpm2_hash_extend(unsigned loc, const uint8_t *buf,
 
 #endif /* __EARLY_SLAUNCH__ */
 
-static struct heap_event_log_pointer_element2_1 *find_evt_log_ext_data(void)
+static struct heap_event_log_pointer_element2_1 *
+find_evt_log_ext_data(struct tpm2_spec_id_event *evt_log)
 {
     struct txt_os_sinit_data *os_sinit;
     struct txt_ext_data_element *ext_data;
 
+    if ( is_amd_cpu() )
+    {
+        /*
+         * Event log pointer is defined by TXT specification, but
+         * secure-kernel-loader provides a compatible structure in vendor data
+         * of the log.
+         */
+        const uint8_t *data_size =
+            (void *)&evt_log->digestSizes[evt_log->digestCount];
+
+        if ( *data_size != sizeof(struct heap_event_log_pointer_element2_1) )
+            return NULL;
+
+        /* Vendor data directly follows one-byte size. */
+        return (void *)(data_size + 1);
+    }
+
     os_sinit = txt_os_sinit_data_start(__va(read_txt_reg(TXTCR_HEAP_BASE)));
     ext_data = (void *)((uint8_t *)os_sinit + sizeof(*os_sinit));
 
@@ -870,7 +934,7 @@ create_log_event20(struct tpm2_spec_id_event *evt_log, uint32_t evt_log_size,
     unsigned i;
     uint8_t *p;
 
-    log_ext_data = find_evt_log_ext_data();
+    log_ext_data = find_evt_log_ext_data(evt_log);
     if ( log_ext_data == NULL )
         return log_hashes;
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:10:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:10:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983265.1369653 (Exim 4.92)
	(envelope-from )
	id 1uEt9b-0002Ol-Q3; Tue, 13 May 2025 17:10:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983265.1369653; Tue, 13 May 2025 17:10: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 1uEt9b-0002OR-Lp; Tue, 13 May 2025 17:10:55 +0000
Received: by outflank-mailman (input) for mailman id 983265;
 Tue, 13 May 2025 17:10:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5v-0003Mm-MA
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:07:07 +0000
Received: from 5.mo550.mail-out.ovh.net (5.mo550.mail-out.ovh.net
 [178.33.45.107]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b2577972-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:07:06 +0200 (CEST)
Received: from director1.ghost.mail-out.ovh.net (unknown [10.108.25.157])
 by mo550.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZK4lbhz1ZM1
 for ; Tue, 13 May 2025 17:07:05 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-tcckm (unknown [10.111.174.188])
 by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id A2E411FE80;
 Tue, 13 May 2025 17:07:04 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.101])
 by ghost-submission-5b5ff79f4f-tcckm with ESMTPSA
 id y6nVFzh8I2iTAAAAAykbXw
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: b2577972-301c-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-101G004fda5cd54-5ed0-4765-9b19-9543bb7b2daa,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 15/22] x86/smpboot.c: TXT AP bringup
Date: Tue, 13 May 2025 20:05:52 +0300
Message-ID: <8319423a25ace730472a219593d6ddbf2cc05a3f.1747155790.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8951185736398910620
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeggeeuvddvtedtteevudejjeeitdefhfetkeeggeffffelfeeivdffudeltdeihfenucffohhmrghinhepthhrrghmphholhhinhgvrdhssgenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddruddtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehhedtmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=v6gFLoGxI5ES25EOdUe8CFrJ+DdQzcda3zZtZ52Zkfg=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156025; v=1;
 b=C55d77izIIDdPTrW0zVla+Mu3KKFxdn76g52SXabSBEyNCJHRJK0neit0+90adLaZ5nQ10/5
 Dz8tKevumWtyTJnd8p3OFxaQTbCSw585ctPfUKWlSMwP0mHPZXoQNMjOTJUgQcBsUgt7IsgAYKn
 tPRCWttbrkUH3LpjjorAqzQ6ehR+0iC3OVVW5JLLsxE2XNL+zrWFrTHlJI9nFEuAVbyoNz+8VqC
 AdjFKlEH0ZSFjgZrKnAST+FnWry86vyo7sSbvkVsR9F19yr/yqZKsOs5Nf+sEalSMvxK7Djbys7
 rOtyqFexdS/7kPOcckzr1OiFmAGg1XYfeXyiayaN8mOiw==

From: Krystian Hebel 

On Intel TXT, APs are started in one of two ways, depending on ACM
which reports it in its information table. In both cases, all APs are
started simultaneously after BSP requests them to do so. Two possible
ways are:
- GETSEC[WAKEUP] instruction,
- MONITOR address.

GETSEC[WAKEUP] requires versions >= 7 of SINIT to MLE Data, but there is
no clear mapping of that version with regard to processor family and
it's not known which CPUs actually use it. It could have been designed
for TXT support on CPUs that lack MONITOR/MWAIT, because GETSEC[WAKEUP]
seems to be more complicated, in software and hardware alike.

This patch implements only MONITOR approach, GETSEC[WAKEUP] support will
be added later once more details and means of testing are available and
if there is a practical need for it.

With this patch, every AP goes through assembly part, and only when in
start_secondary() in C they re-enter MONITOR/MWAIT iff they are not the
AP that was asked to boot. The same address is reused for simplicity,
and on next wakeup call APs don't have to go through assembly part
again (GDT, paging, stack setting).

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/boot/trampoline.S       | 19 ++++++++-
 xen/arch/x86/include/asm/intel-txt.h |  6 +++
 xen/arch/x86/include/asm/processor.h |  1 +
 xen/arch/x86/smpboot.c               | 63 ++++++++++++++++++++++++++++
 4 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index ed593acc46..8cd9881828 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -58,6 +58,16 @@ GLOBAL(entry_SIPI16)
         ljmpl   $BOOT_CS32,$bootsym_rel(trampoline_protmode_entry,6)
 
         .code32
+GLOBAL(txt_ap_entry)
+        /*
+         * APs enter here in protected mode without paging. GDT is set in JOIN
+         * structure, it points to trampoline_gdt. Interrupts are disabled by
+         * TXT (including NMI and SMI), so IDT doesn't matter at this point.
+         * The only missing point is telling that we are AP by saving non-zero
+         * value in EBX.
+         */
+        mov     $1, %ebx
+
 trampoline_protmode_entry:
         /* Set up a few descriptors: on entry only CS is guaranteed good. */
         mov     $BOOT_DS,%eax
@@ -143,7 +153,7 @@ start64:
         .word   0
 idt_48: .word   0, 0, 0 # base = limit = 0
 
-trampoline_gdt:
+GLOBAL(trampoline_gdt)
         .word   0                  /* 0x0000: unused (reused for GDTR) */
 gdt_48:
         .word   .Ltrampoline_gdt_end - trampoline_gdt - 1
@@ -154,6 +164,13 @@ gdt_48:
         .quad   0x00cf93000000ffff /* 0x0018: ring 0 data */
         .quad   0x00009b000000ffff /* 0x0020: real-mode code @ BOOT_TRAMPOLINE */
         .quad   0x000093000000ffff /* 0x0028: real-mode data @ BOOT_TRAMPOLINE */
+        /*
+         * Intel TXT requires these two in exact order. This isn't compatible
+         * with order required by syscall, so we have duplicated entries...
+         * If order ever changes, update selector numbers in asm/intel-txt.h.
+         */
+        .quad   0x00cf9b000000ffff /* 0x0030: ring 0 code, 32-bit mode */
+        .quad   0x00cf93000000ffff /* 0x0038: ring 0 data */
 .Ltrampoline_gdt_end:
 
         /* Relocations for trampoline Real Mode segments. */
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index bc51d2d287..5d76443d35 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -82,6 +82,9 @@
 
 #define SLAUNCH_BOOTLOADER_MAGIC             0x4c534254
 
+#define TXT_AP_BOOT_CS                  0x0030
+#define TXT_AP_BOOT_DS                  0x0038
+
 #ifndef __ASSEMBLY__
 
 #include 
@@ -96,6 +99,9 @@
 #define _txt(x) __va(x)
 #endif
 
+extern char txt_ap_entry[];
+extern uint32_t trampoline_gdt[];
+
 /*
  * Always use private space as some of registers are either read-only or not
  * present in public space.
diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index 75af7ea3c4..9957e3cb9e 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -473,6 +473,7 @@ void set_in_mcu_opt_ctrl(uint32_t mask, uint32_t val);
 enum ap_boot_method {
     AP_BOOT_NORMAL,
     AP_BOOT_SKINIT,
+    AP_BOOT_TXT,
 };
 extern enum ap_boot_method ap_boot_method;
 
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 54207e6d88..5e53cce20b 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -325,6 +327,29 @@ void asmlinkage start_secondary(void *unused)
      */
     unsigned int cpu = booting_cpu;
 
+    if ( ap_boot_method == AP_BOOT_TXT ) {
+        uint64_t misc_enable;
+        uint32_t my_apicid;
+        struct txt_sinit_mle_data *sinit_mle =
+              txt_sinit_mle_data_start(__va(read_txt_reg(TXTCR_HEAP_BASE)));
+
+        /* TXT released us with MONITOR disabled in IA32_MISC_ENABLE. */
+        rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
+        wrmsrl(MSR_IA32_MISC_ENABLE,
+               misc_enable | MSR_IA32_MISC_ENABLE_MONITOR_ENABLE);
+
+        /* get_apic_id() reads from x2APIC if it thinks it is enabled. */
+        x2apic_ap_setup();
+        my_apicid = get_apic_id();
+
+        while ( my_apicid != x86_cpu_to_apicid[cpu] ) {
+            asm volatile ("monitor; xor %0,%0; mwait"
+                          :: "a"(__va(sinit_mle->rlp_wakeup_addr)), "c"(0),
+                          "d"(0) : "memory");
+            cpu = booting_cpu;
+        }
+    }
+
     /* Critical region without IDT or TSS.  Any fault is deadly! */
 
     set_current(idle_vcpu[cpu]);
@@ -421,6 +446,28 @@ void asmlinkage start_secondary(void *unused)
     startup_cpu_idle_loop();
 }
 
+static int wake_aps_in_txt(void)
+{
+    struct txt_sinit_mle_data *sinit_mle =
+              txt_sinit_mle_data_start(__va(read_txt_reg(TXTCR_HEAP_BASE)));
+    uint32_t *wakeup_addr = __va(sinit_mle->rlp_wakeup_addr);
+
+    uint32_t join[4] = {
+        trampoline_gdt[1],               /* GDT limit */
+        bootsym_phys(trampoline_gdt),    /* GDT base */
+        TXT_AP_BOOT_CS,                  /* CS selector, DS = CS+8 */
+        bootsym_phys(txt_ap_entry)       /* EIP */
+    };
+
+    write_txt_reg(TXTCR_MLE_JOIN, __pa(join));
+
+    smp_mb();
+
+    *wakeup_addr = 1;
+
+    return 0;
+}
+
 static int wakeup_secondary_cpu(int phys_apicid, unsigned long start_eip)
 {
     unsigned long send_status = 0, accept_status = 0;
@@ -443,6 +490,9 @@ static int wakeup_secondary_cpu(int phys_apicid, unsigned long start_eip)
     if ( tboot_in_measured_env() && !tboot_wake_ap(phys_apicid, start_eip) )
         return 0;
 
+    if ( ap_boot_method == AP_BOOT_TXT )
+        return wake_aps_in_txt();
+
     /*
      * Be paranoid about clearing APIC errors.
      */
@@ -1150,6 +1200,13 @@ static struct notifier_block cpu_smpboot_nfb = {
 
 void __init smp_prepare_cpus(void)
 {
+    /*
+     * If the platform is performing a Secure Launch via TXT, secondary
+     * CPUs (APs) will need to be woken up in a TXT-specific way.
+     */
+    if ( slaunch_active && boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+        ap_boot_method = AP_BOOT_TXT;
+
     register_cpu_notifier(&cpu_smpboot_nfb);
 
     mtrr_aps_sync_begin();
@@ -1418,6 +1475,12 @@ void __init smp_cpus_done(void)
 
     mtrr_save_state();
     mtrr_aps_sync_end();
+
+    /*
+     * After the initial startup the DRTM-specific method for booting APs
+     * should not longer be used unless DRTM sequence is started again.
+     */
+    ap_boot_method = AP_BOOT_NORMAL;
 }
 
 void __init smp_intr_init(void)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:11:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:11:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983299.1369664 (Exim 4.92)
	(envelope-from )
	id 1uEtA2-00042m-Bz; Tue, 13 May 2025 17:11:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983299.1369664; Tue, 13 May 2025 17: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 1uEtA2-00042f-5X; Tue, 13 May 2025 17:11:22 +0000
Received: by outflank-mailman (input) for mailman id 983299;
 Tue, 13 May 2025 17:11:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5a-0003Mm-Bj
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:46 +0000
Received: from 6.mo576.mail-out.ovh.net (6.mo576.mail-out.ovh.net
 [46.105.50.107]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a642e806-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:06:45 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.108.9.136])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjYx2fwnz1vvL
 for ; Tue, 13 May 2025 17:06:45 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-q2zpp (unknown [10.108.54.144])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 97F541FE68;
 Tue, 13 May 2025 17:06:44 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.109])
 by ghost-submission-5b5ff79f4f-q2zpp with ESMTPSA
 id d2EBFSR8I2hnAAAAOMNtBw
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: a642e806-301c-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-109S003cd6ad599-b8b8-4bf1-b0db-ca82d73d54a9,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 08/22] x86/slaunch: restore boot MTRRs after Intel TXT DRTM
Date: Tue, 13 May 2025 20:05:45 +0300
Message-ID: <6448e4a7535d4f74f7559e14e13c8d531cac71a0.1747155790.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8945556237201618076
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhggtgfgsehtkeertdertdejnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepgeekffeiiedtveekhfdugeffveeigefgleegvdeghefftdetheefueeliedukedvnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukedurddujeekpdefjedrheelrddugedvrddutdelnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheejiegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=nB7H7bO1BJ1ApmWbD/4F5x9yGu79QzObrwHjfTYg4+c=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156005; v=1;
 b=Yom0lwoxH0pn1G+ymjpkZJQZOSZ3mtc9IlAvv8W2QSarlH4ihT2SiRvkRbuMH4yC1rT1q9R9
 Kl4oMrM1izbpV9vv5bnk+M8QfSzsNRDetCpya3wo2ht/OXFhV7zyAJZUYXiVd6N6fU0KgTTYeXG
 ZoXbgTsMrtf+e0B2127NPm6WRu02ekitchp62Tp3EJHmHJnezpOOut02WbbDseVJisqD15nnI2d
 mQOEmT5mbWV0nBpWPRmol01UlAA9oEF8Zs0FgyB1aAo8x/4CniiJEyIR0HH+X2vCGFLVWOdk9ND
 r8LZ+1pnTZKv0zIiops1Fa/I0JblPLz2QmorAvZMyg7FA==

From: Krystian Hebel 

In preparation for TXT SENTER call, GRUB had to modify MTRR settings
to be UC for everything except SINIT ACM. Old values are restored
from SLRT where they were saved by the bootloader.

Signed-off-by: Krystian Hebel 
Signed-off-by: Michał Żygowski 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/e820.c                  |  5 ++
 xen/arch/x86/include/asm/intel-txt.h |  3 ++
 xen/arch/x86/intel-txt.c             | 75 ++++++++++++++++++++++++++++
 3 files changed, 83 insertions(+)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index ca577c0bde..60f00e5259 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /*
  * opt_mem: Limit maximum address of physical RAM.
@@ -442,6 +444,9 @@ static uint64_t __init mtrr_top_of_ram(void)
     ASSERT(paddr_bits);
     addr_mask = ((1ULL << paddr_bits) - 1) & PAGE_MASK;
 
+    if ( slaunch_active )
+        txt_restore_mtrrs(e820_verbose);
+
     rdmsrl(MSR_MTRRcap, mtrr_cap);
     rdmsrl(MSR_MTRRdefType, mtrr_def);
 
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 0126f56a6c..f0ec580558 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -405,6 +405,9 @@ void txt_map_mem_regions(void);
 /* Marks TXT-specific memory as used to avoid its corruption. */
 void txt_reserve_mem_regions(void);
 
+/* Restores original MTRR values saved by a bootloader before starting DRTM. */
+void txt_restore_mtrrs(bool e820_verbose);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* ASM__X86__INTEL_TXT_H */
diff --git a/xen/arch/x86/intel-txt.c b/xen/arch/x86/intel-txt.c
index 67051b0917..92f3e48b49 100644
--- a/xen/arch/x86/intel-txt.c
+++ b/xen/arch/x86/intel-txt.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 static uint64_t __initdata txt_heap_base, txt_heap_size;
@@ -111,3 +113,76 @@ void __init txt_reserve_mem_regions(void)
                      E820_UNUSABLE);
     BUG_ON(rc == 0);
 }
+
+void __init txt_restore_mtrrs(bool e820_verbose)
+{
+    struct slr_entry_intel_info *intel_info;
+    uint64_t mtrr_cap, mtrr_def, base, mask;
+    unsigned int i;
+    uint64_t def_type;
+    struct mtrr_pausing_state pausing_state;
+
+    rdmsrl(MSR_MTRRcap, mtrr_cap);
+    rdmsrl(MSR_MTRRdefType, mtrr_def);
+
+    if ( e820_verbose )
+    {
+        printk("MTRRs set previously for SINIT ACM:\n");
+        printk(" MTRR cap: %"PRIx64" type: %"PRIx64"\n", mtrr_cap, mtrr_def);
+
+        for ( i = 0; i < (uint8_t)mtrr_cap; i++ )
+        {
+            rdmsrl(MSR_IA32_MTRR_PHYSBASE(i), base);
+            rdmsrl(MSR_IA32_MTRR_PHYSMASK(i), mask);
+
+            printk(" MTRR[%d]: base %"PRIx64" mask %"PRIx64"\n",
+                   i, base, mask);
+        }
+    }
+
+    intel_info = (struct slr_entry_intel_info *)
+        slr_next_entry_by_tag(slaunch_get_slrt(), NULL, SLR_ENTRY_INTEL_INFO);
+
+    if ( (mtrr_cap & 0xFF) != intel_info->saved_bsp_mtrrs.mtrr_vcnt )
+    {
+        printk("Bootloader saved %ld MTRR values, but there should be %ld\n",
+               intel_info->saved_bsp_mtrrs.mtrr_vcnt, mtrr_cap & 0xFF);
+        /* Choose the smaller one to be on the safe side. */
+        mtrr_cap = (mtrr_cap & 0xFF) > intel_info->saved_bsp_mtrrs.mtrr_vcnt ?
+                   intel_info->saved_bsp_mtrrs.mtrr_vcnt : mtrr_cap;
+    }
+
+    def_type = intel_info->saved_bsp_mtrrs.default_mem_type;
+    pausing_state = mtrr_pause_caching();
+
+    for ( i = 0; i < (uint8_t)mtrr_cap; i++ )
+    {
+        base = intel_info->saved_bsp_mtrrs.mtrr_pair[i].mtrr_physbase;
+        mask = intel_info->saved_bsp_mtrrs.mtrr_pair[i].mtrr_physmask;
+        wrmsrl(MSR_IA32_MTRR_PHYSBASE(i), base);
+        wrmsrl(MSR_IA32_MTRR_PHYSMASK(i), mask);
+    }
+
+    pausing_state.def_type = def_type;
+    mtrr_resume_caching(pausing_state);
+
+    if ( e820_verbose )
+    {
+        printk("Restored MTRRs:\n"); /* Printed by caller, mtrr_top_of_ram(). */
+
+        /* If MTRRs are not enabled or WB is not a default type, MTRRs won't be printed */
+        if ( !test_bit(11, &def_type) || ((uint8_t)def_type == X86_MT_WB) )
+        {
+            for ( i = 0; i < (uint8_t)mtrr_cap; i++ )
+            {
+                rdmsrl(MSR_IA32_MTRR_PHYSBASE(i), base);
+                rdmsrl(MSR_IA32_MTRR_PHYSMASK(i), mask);
+                printk(" MTRR[%d]: base %"PRIx64" mask %"PRIx64"\n",
+                       i, base, mask);
+            }
+        }
+    }
+
+    /* Restore IA32_MISC_ENABLES */
+    wrmsrl(MSR_IA32_MISC_ENABLE, intel_info->saved_misc_enable_msr);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:11:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:11:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983304.1369673 (Exim 4.92)
	(envelope-from )
	id 1uEtA5-0004LL-HQ; Tue, 13 May 2025 17:11:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983304.1369673; Tue, 13 May 2025 17: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 1uEtA5-0004LE-E3; Tue, 13 May 2025 17:11:25 +0000
Received: by outflank-mailman (input) for mailman id 983304;
 Tue, 13 May 2025 17:11:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt6C-0003Uz-HR
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:07:24 +0000
Received: from 12.mo581.mail-out.ovh.net (12.mo581.mail-out.ovh.net
 [178.33.107.167]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bc38064f-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:07:22 +0200 (CEST)
Received: from director6.ghost.mail-out.ovh.net (unknown [10.109.176.215])
 by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZf1Yq3z1L93
 for ; Tue, 13 May 2025 17:07:22 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-2q4jk (unknown [10.108.42.75])
 by director6.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 440FB1FDC5;
 Tue, 13 May 2025 17:07:20 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.97])
 by ghost-submission-5b5ff79f4f-2q4jk with ESMTPSA
 id 9HLkNUd8I2ikAAAAzEFtag
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: bc38064f-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-97G002691fa020-5b77-4e47-953a-62ec58cd6b8e,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
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 ,
	Nicola Vetrini ,
	Doug Goldstein ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 20/22] x86/slaunch: support EFI boot
Date: Tue, 13 May 2025 20:05:57 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8955970812598596764
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeelleekkefhieekieefkefgtefhvdehkeefvdffteefgfevleelkeekvdegkeduvdenucffohhmrghinhephhgvrggurdhssgdpgiekiegpieegrdhssgenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddrleejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekudgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=Cu1xkQ6GuDdEObhFAI3AikBnobBTD4vWIFp+Q1jG7HI=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156042; v=1;
 b=EGGcy8DJmEndR66YmDIGBC6hLk1rJ6/qF/VtYajbuUedd0CDY/5Uv7bdrkReytR/gLfdVHod
 23VqD5Epj9ZqAgsnV3Lk4RvxUNxVAQZ6YwmTL064i3j3JoDvhrDr18e0+YsKp6DuJzj+2WakWpB
 S1Fu+PW35AGCPUH6sOA8h9uWAo/ix8Af3EbvzmrVu+JZjhl5AyTXbqLklSZmTZ/pKocTJ6xqBnX
 Co6ZR8w3w/R+5fTDawCs2PlZB2l1Rg6eAnyLtvKhIxeW2g+Yzn/xPXz6yrwynENJIkP+mwBCBlD
 dnjewcveW/HTOpn0R1AcCogUbtAo5S0LjZsd10NlRdAdA==

When running on an EFI-enabled system, Xen needs to have access to Boot
Services in order to initialize itself properly and reach a state in
which a dom0 kernel can operate without issues.

This means that DRTM must be started in the middle of Xen's
initialization process.  This effect is achieved via a callback into
bootloader (GRUB) which is responsible for initiating DRTM and
continuing Xen's initialization process.  The latter is done by
branching in Slaunch entry point on a flag to switch back into long mode
before calling the same function which Xen would execute as the next
step without DRTM.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 .gitignore                                    |   1 +
 .../eclair_analysis/ECLAIR/out_of_scope.ecl   |   1 +
 docs/hypervisor-guide/x86/how-xen-boots.rst   |  10 +-
 xen/arch/x86/Makefile                         |   9 +-
 xen/arch/x86/boot/head.S                      | 124 +++++++++++++++++
 xen/arch/x86/boot/x86_64.S                    |  14 +-
 xen/arch/x86/efi/efi-boot.h                   |  88 +++++++++++-
 xen/arch/x86/efi/fixmlehdr.c                  | 127 ++++++++++++++++++
 xen/arch/x86/slaunch.c                        |  74 +++++++++-
 xen/common/efi/boot.c                         |   4 +
 xen/common/efi/runtime.c                      |   1 +
 xen/include/xen/efi.h                         |   1 +
 12 files changed, 441 insertions(+), 13 deletions(-)
 create mode 100644 xen/arch/x86/efi/fixmlehdr.c

diff --git a/.gitignore b/.gitignore
index 53f5df0003..dab829d7e1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -201,6 +201,7 @@ xen/.xen.elf32
 xen/System.map
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
+xen/arch/x86/efi/fixmlehdr
 xen/arch/x86/efi/mkreloc
 xen/arch/x86/include/asm/asm-macros.h
 xen/arch/*/xen.lds
diff --git a/automation/eclair_analysis/ECLAIR/out_of_scope.ecl b/automation/eclair_analysis/ECLAIR/out_of_scope.ecl
index 9bcec4c69d..a09cf5442c 100644
--- a/automation/eclair_analysis/ECLAIR/out_of_scope.ecl
+++ b/automation/eclair_analysis/ECLAIR/out_of_scope.ecl
@@ -19,6 +19,7 @@
 
 -doc_begin="Build tools are out of scope."
 -file_tag+={out_of_scope_tools,"^xen/tools/.*$"}
+-file_tag+={out_of_scope_tools,"^xen/arch/x86/efi/fixmlehdr\\.c$"}
 -file_tag+={out_of_scope_tools,"^xen/arch/x86/efi/mkreloc\\.c$"}
 -file_tag+={out_of_scope_tools,"^xen/arch/x86/boot/mkelf32\\.c$"}
 -doc_end
diff --git a/docs/hypervisor-guide/x86/how-xen-boots.rst b/docs/hypervisor-guide/x86/how-xen-boots.rst
index 050fe9c61f..63f81a8198 100644
--- a/docs/hypervisor-guide/x86/how-xen-boots.rst
+++ b/docs/hypervisor-guide/x86/how-xen-boots.rst
@@ -55,10 +55,12 @@ If ``CONFIG_PVH_GUEST`` was selected at build time, an Elf note is included
 which indicates the ability to use the PVH boot protocol, and registers
 ``__pvh_start`` as the entrypoint, entered in 32bit mode.
 
-A combination of Multiboot 2 and MLE headers is used to implement DRTM for
-legacy (BIOS) boot. The separate entry point is used mainly to differentiate
-from other kinds of boots. It moves a magic number to EAX before jumping into
-common startup code.
+A combination of Multiboot 2 and MLE headers is used to implement DRTM. The
+separate entry point is used mainly to differentiate from other kinds of boots.
+For a legacy (BIOS) boot, it moves a magic number to EAX before jumping into
+common startup code.  For a EFI boot, it resumes execution of Xen.efi which was
+paused by handing control to a part of a bootloader responsible for initiating
+DRTM sequence.
 
 
 xen.gz
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 2527a1909c..7c2c0b5e4c 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -89,6 +89,7 @@ extra-y += xen.lds
 
 hostprogs-y += boot/mkelf32
 hostprogs-y += efi/mkreloc
+hostprogs-y += efi/fixmlehdr
 
 $(obj)/efi/mkreloc: HOSTCFLAGS += -I$(srctree)/include
 
@@ -140,6 +141,10 @@ $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
 
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
 
+ifeq ($(XEN_BUILD_EFI),y)
+XEN_AFLAGS += -DXEN_BUILD_EFI
+endif
+
 $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
 	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
 	    $(objtree)/common/symbols-dummy.o -o $(dot-target).0
@@ -209,7 +214,7 @@ note_file_option ?= $(note_file)
 
 extra-$(XEN_BUILD_PE) += efi.lds
 ifeq ($(XEN_BUILD_PE),y)
-$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
+$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc $(obj)/efi/fixmlehdr
 ifeq ($(CONFIG_DEBUG_INFO),y)
 	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
 endif
@@ -236,6 +241,8 @@ endif
 	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
 	      $(dot-target).1r.o $(dot-target).1s.o $(orphan-handling-y) \
 	      $(note_file_option) -o $@
+	# take image offset into account
+	$(obj)/efi/fixmlehdr $@ $(XEN_IMG_OFFSET)
 	$(NM) -pa --format=sysv $@ \
 		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
 		> $@.map
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 66e1a21033..5ec2a272a9 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -397,6 +397,12 @@ slaunch_stub_entry:
         mov     %ebx, %esi
         sub     $sym_offs(slaunch_stub_entry), %esi
 
+#ifdef XEN_BUILD_EFI
+        /* If the flag is already set, then Xen should continue execution. */
+        cmpb    $0, sym_esi(slaunch_active)
+        jne     slaunch_efi_jumpback
+#endif
+
         /* On AMD, %ebp holds the base address of SLB, save it for later. */
         mov     %ebp, %ebx
 
@@ -836,6 +842,124 @@ trampoline_setup:
         /* Jump into the relocated trampoline. */
         lret
 
+#ifdef XEN_BUILD_EFI
+
+        /*
+         * The state matches that of slaunch_stub_entry above, but with %esi
+         * already initialized.
+         */
+slaunch_efi_jumpback:
+        lea     STACK_SIZE - CPUINFO_sizeof + sym_esi(cpu0_stack), %esp
+
+        /* Prepare gdt and segments. */
+        add     %esi, sym_esi(gdt_boot_base)
+        lgdt    sym_esi(gdt_boot_descr)
+
+        mov     $BOOT_DS, %ecx
+        mov     %ecx, %ds
+        mov     %ecx, %es
+        mov     %ecx, %ss
+
+        push    $BOOT_CS32
+        lea     sym_esi(.Lgdt_is_set),%edx
+        push    %edx
+        lret
+.Lgdt_is_set:
+
+        /*
+         * Stash TSC as above because it was zeroed on jumping into bootloader
+         * to not interfere with measurements.
+         */
+        rdtsc
+        mov     %eax,     sym_esi(boot_tsc_stamp)
+        mov     %edx, 4 + sym_esi(boot_tsc_stamp)
+
+        /*
+         * Clear the pagetables before the use. We are loaded below 4GiB and
+         * this avoids the need for writing to higher dword of each entry.
+         * Additionally, this ensures those dwords are actually zero and the
+         * mappings aren't manipulated from outside.
+         */
+        lea     sym_esi(bootmap_start), %edi
+        lea     sym_esi(bootmap_end), %ecx
+        sub     %edi, %ecx
+        xor     %eax, %eax
+        shr     $2, %ecx
+        rep stosl
+
+        /* 1x L1 page, 512 entries mapping total of 2M. */
+        lea     sym_esi(l1_bootmap), %edi
+        mov     $512, %ecx
+        mov     $(__PAGE_HYPERVISOR + 512 * PAGE_SIZE), %edx
+.Lfill_l1_identmap:
+        sub     $PAGE_SIZE, %edx
+        /* Loop runs for ecx=[512..1] for entries [511..0], hence -8. */
+        mov     %edx, -8(%edi,%ecx,8)
+        loop    .Lfill_l1_identmap
+
+        /* 4x L2 pages, each page mapping 1G of RAM. */
+        lea     sym_esi(l2_bootmap), %edi
+        /* 1st entry points to L1. */
+        lea     (sym_offs(l1_bootmap) + __PAGE_HYPERVISOR)(%esi), %edx
+        mov     %edx, (%edi)
+        /* Other entries are 2MB pages. */
+        mov     $(4 * 512 - 1), %ecx
+        /*
+         * Value below should be 4GB + flags, which wouldn't fit in 32b
+         * register. To avoid warning from the assembler, 4GB is skipped here.
+         * Substitution in first iteration makes the value roll over and point
+         * to 4GB - 2MB + flags.
+         */
+        mov     $(_PAGE_PSE + __PAGE_HYPERVISOR), %edx
+.Lfill_l2_identmap:
+        sub     $(1 << L2_PAGETABLE_SHIFT), %edx
+        /* Loop runs for ecx=[2047..1] for entries [2047..1]. */
+        mov     %edx, (%edi,%ecx,8)
+        loop    .Lfill_l2_identmap
+
+        /* 1x L3 page, mapping the 4x L2 pages. */
+        lea     sym_esi(l3_bootmap), %edi
+        mov     $4, %ecx
+        lea     (sym_offs(l2_bootmap) + 4 * PAGE_SIZE + __PAGE_HYPERVISOR)(%esi), %edx
+.Lfill_l3_identmap:
+        sub     $PAGE_SIZE, %edx
+        /* Loop runs for ecx=[4..1] for entries [3..0], hence -8. */
+        mov     %edx, -8(%edi,%ecx,8)
+        loop    .Lfill_l3_identmap
+
+        /* 1x L4 page, mapping the L3 page. */
+        lea     (sym_offs(l3_bootmap) + __PAGE_HYPERVISOR)(%esi), %edx
+        mov     %edx, sym_esi(l4_bootmap)
+
+        /* Restore CR4, PAE must be enabled before IA-32e mode */
+        mov     %cr4, %ecx
+        or      $X86_CR4_PAE, %ecx
+        mov     %ecx, %cr4
+
+        /* Load PML4 table location into PT base register */
+        lea     sym_esi(l4_bootmap), %eax
+        mov     %eax, %cr3
+
+        /* Enable IA-32e mode and paging */
+        mov     $MSR_EFER, %ecx
+        rdmsr
+        or      $EFER_LME >> 8, %ah
+        wrmsr
+
+        mov     %cr0, %eax
+        or      $X86_CR0_PG | X86_CR0_NE | X86_CR0_TS | X86_CR0_MP, %eax
+        mov     %eax, %cr0
+
+        /* Now in IA-32e compatibility mode, use lret to jump to 64b mode */
+        lea     sym_esi(start_xen_from_efi), %ecx
+        push    $BOOT_CS64
+        push    %ecx
+        lret
+
+.global start_xen_from_efi
+
+#endif /* XEN_BUILD_EFI */
+
 ENTRY(trampoline_start)
 #include "trampoline.S"
 ENTRY(trampoline_end)
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index ac33576d8f..67896f5fe5 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -221,14 +221,22 @@ GLOBAL(__page_tables_end)
 /* Init pagetables. Enough page directories to map into 4GB. */
         .section .init.data, "aw", @progbits
 
-DATA_LOCAL(l1_bootmap, PAGE_SIZE)
+bootmap_start:
+
+DATA_LOCAL(l1_bootmap, PAGE_SIZE) /* 1x L1 page, mapping 2M of RAM. */
         .fill L1_PAGETABLE_ENTRIES, 8, 0
 END(l1_bootmap)
 
-DATA(l2_bootmap, PAGE_SIZE)
+DATA(l2_bootmap, PAGE_SIZE) /* 4x L2 pages, each mapping 1G of RAM. */
         .fill 4 * L2_PAGETABLE_ENTRIES, 8, 0
 END(l2_bootmap)
 
-DATA(l3_bootmap, PAGE_SIZE)
+DATA(l3_bootmap, PAGE_SIZE) /* 1x L3 page, mapping the 4x L2 pages. */
         .fill L3_PAGETABLE_ENTRIES, 8, 0
 END(l3_bootmap)
+
+DATA_LOCAL(l4_bootmap, PAGE_SIZE) /* 1x L4 page, mapping the L3 page. */
+        .fill L4_PAGETABLE_ENTRIES, 8, 0
+END(l4_bootmap)
+
+bootmap_end:
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 1d8902a9a7..6aaba4a966 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -5,6 +5,12 @@
  */
 #include 
 
+/*
+ * Tell  to access TXT registers without address translation
+ * which has not yet been set up.
+ */
+#define __EARLY_SLAUNCH__
+
 #include 
 #include 
 #include 
@@ -13,8 +19,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 static struct file __initdata ucode;
+static uint64_t __initdata xen_image_size;
 static multiboot_info_t __initdata mbi = {
     .flags = MBI_MODULES | MBI_LOADERNAME
 };
@@ -230,10 +239,29 @@ static void __init efi_arch_pre_exit_boot(void)
     }
 }
 
-static void __init noreturn efi_arch_post_exit_boot(void)
+void __init asmlinkage noreturn start_xen_from_efi(void)
 {
     u64 cr4 = XEN_MINIMAL_CR4 & ~X86_CR4_PGE, efer;
 
+    if ( slaunch_active )
+    {
+        struct slr_table *slrt = (struct slr_table *)efi.slr;
+        struct slr_entry_intel_info *intel_info;
+
+        intel_info = (struct slr_entry_intel_info *)
+            slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+        if ( intel_info != NULL )
+        {
+            void *txt_heap = txt_init();
+            struct txt_os_mle_data *os_mle = txt_os_mle_data_start(txt_heap);
+            struct txt_os_sinit_data *os_sinit =
+                txt_os_sinit_data_start(txt_heap);
+
+            txt_verify_pmr_ranges(os_mle, os_sinit, intel_info, xen_phys_start,
+                                  xen_phys_start, xen_image_size);
+        }
+    }
+
     efi_arch_relocate_image(__XEN_VIRT_START - xen_phys_start);
     memcpy(_p(trampoline_phys), trampoline_start, cfg.size);
 
@@ -279,6 +307,63 @@ static void __init noreturn efi_arch_post_exit_boot(void)
     unreachable();
 }
 
+static void __init attempt_secure_launch(void)
+{
+    struct slr_table *slrt;
+    struct slr_entry_dl_info *dlinfo;
+    dl_handler_func handler_callback;
+
+    /* The presence of this table indicates a Secure Launch boot. */
+    slrt = (struct slr_table *)efi.slr;
+    if ( efi.slr == EFI_INVALID_TABLE_ADDR || slrt->magic != SLR_TABLE_MAGIC ||
+         slrt->revision != SLR_TABLE_REVISION )
+        return;
+
+    /* Avoid calls into firmware after DRTM. */
+    __clear_bit(EFI_RS, &efi_flags);
+
+    /*
+     * Make measurements less sensitive to hardware-specific details.
+     *
+     * Intentionally leaving efi_ct and efi_num_ct intact.
+     */
+    efi_ih = NULL;
+    efi_bs = NULL;
+    efi_bs_revision = 0;
+    efi_rs = NULL;
+    efi_version = 0;
+    efi_fw_vendor = NULL;
+    efi_fw_revision = 0;
+    StdOut = NULL;
+    StdErr = NULL;
+    boot_tsc_stamp = 0;
+
+    slaunch_active = true;
+    slaunch_slrt = efi.slr;
+
+    /* Jump through DL stub to initiate Secure Launch. */
+    dlinfo = (struct slr_entry_dl_info *)
+        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO);
+
+    handler_callback = (dl_handler_func)dlinfo->dl_handler;
+    handler_callback(&dlinfo->bl_context);
+
+    unreachable();
+}
+
+static void __init noreturn efi_arch_post_exit_boot(void)
+{
+    /*
+     * If Secure Launch happens, attempt_secure_launch() doesn't return and
+     * start_xen_from_efi() is invoked after DRTM has been initiated.
+     * Otherwise, attempt_secure_launch() returns and execution continues as
+     * usual.
+     */
+    attempt_secure_launch();
+
+    start_xen_from_efi();
+}
+
 static void __init efi_arch_cfg_file_early(const EFI_LOADED_IMAGE *image,
                                            EFI_FILE_HANDLE dir_handle,
                                            const char *section)
@@ -775,6 +860,7 @@ static void __init efi_arch_halt(void)
 static void __init efi_arch_load_addr_check(const EFI_LOADED_IMAGE *loaded_image)
 {
     xen_phys_start = (UINTN)loaded_image->ImageBase;
+    xen_image_size = loaded_image->ImageSize;
     if ( (xen_phys_start + loaded_image->ImageSize - 1) >> 32 )
         blexit(L"Xen must be loaded below 4Gb.");
     if ( xen_phys_start & ((1 << L2_PAGETABLE_SHIFT) - 1) )
diff --git a/xen/arch/x86/efi/fixmlehdr.c b/xen/arch/x86/efi/fixmlehdr.c
new file mode 100644
index 0000000000..60a91c6b73
--- /dev/null
+++ b/xen/arch/x86/efi/fixmlehdr.c
@@ -0,0 +1,127 @@
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Depending on the toolchain and its configuration the header can end up quite
+ * far from the start of the file.
+ */
+#define PREFIX_SIZE (8*1024)
+
+struct mle_header
+{
+    uint8_t uuid[16];
+    uint32_t header_len;
+    uint32_t version;
+    uint32_t entry_point;
+    uint32_t first_valid_page;
+    uint32_t mle_start;
+    uint32_t mle_end;
+    uint32_t capabilities;
+    uint32_t cmdline_start;
+    uint32_t cmdline_end;
+} __attribute__ ((packed));
+
+static const uint8_t MLE_HEADER_UUID[] = {
+    0x5a, 0xac, 0x82, 0x90, 0x6f, 0x47, 0xa7, 0x74,
+    0x0f, 0x5c, 0x55, 0xa2, 0xcb, 0x51, 0xb6, 0x42
+};
+
+int main(int argc, char *argv[])
+{
+    FILE *fp;
+    struct mle_header header;
+    int i;
+    char *end_ptr;
+    long long correction;
+    const char *file_path;
+
+    if ( argc != 3 )
+    {
+        fprintf(stderr, "Usage: %s  \n", argv[0]);
+        return 1;
+    }
+
+    correction = strtoll(argv[2], &end_ptr, 0);
+    if ( *end_ptr != '\0' )
+    {
+        fprintf(stderr, "Failed to parse '%s' as a number\n", argv[2]);
+        return 1;
+    }
+    if ( correction < INT32_MIN  )
+    {
+        fprintf(stderr, "Correction '%s' is too small\n", argv[2]);
+        return 1;
+    }
+    if ( correction > INT32_MAX  )
+    {
+        fprintf(stderr, "Correction '%s' is too large\n", argv[2]);
+        return 1;
+    }
+
+    file_path = argv[1];
+
+    fp = fopen(file_path, "r+");
+    if ( fp == NULL )
+    {
+        fprintf(stderr, "Failed to open %s\n", file_path);
+        return 1;
+    }
+
+    for ( i = 0; i < PREFIX_SIZE; i += 16 )
+    {
+        uint8_t bytes[16];
+
+        if ( fread(bytes, sizeof(bytes), 1, fp) != 1 )
+        {
+            fprintf(stderr, "Failed to find MLE header in %s\n", file_path);
+            goto fail;
+        }
+
+        if ( memcmp(bytes, MLE_HEADER_UUID, 16) == 0 )
+        {
+            break;
+        }
+    }
+
+    if ( i >= PREFIX_SIZE )
+    {
+        fprintf(stderr, "Failed to find MLE header in %s\n", file_path);
+        goto fail;
+    }
+
+    if ( fseek(fp, -16, SEEK_CUR) )
+    {
+        fprintf(stderr, "Failed to seek back to MLE header in %s\n", file_path);
+        goto fail;
+    }
+
+    if ( fread(&header, sizeof(header), 1, fp) != 1 )
+    {
+        fprintf(stderr, "Failed to read MLE header from %s\n", file_path);
+        goto fail;
+    }
+
+    if ( fseek(fp, -(int)sizeof(header), SEEK_CUR) )
+    {
+        fprintf(stderr, "Failed to seek back again to MLE header in %s\n",
+                file_path);
+        goto fail;
+    }
+
+    header.entry_point += correction;
+
+    if ( fwrite(&header, sizeof(header), 1, fp) != 1 )
+    {
+        fprintf(stderr, "Failed to write MLE header in %s\n", file_path);
+        goto fail;
+    }
+
+    fclose(fp);
+    return 0;
+
+fail:
+    fclose(fp);
+    return 1;
+}
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index f0447f91d2..15cfe944a7 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -244,10 +245,23 @@ check_drtm_policy(struct slr_table *slrt,
 {
     uint32_t i;
     uint32_t num_mod_entries;
+    int min_entries;
 
-    if ( policy->nr_entries < 2 )
-        panic("DRTM policy in SLRT contains less than 2 entries (%d)!\n",
-              policy->nr_entries);
+    min_entries = efi_enabled(EFI_BOOT) ? 1 : 2;
+    if ( policy->nr_entries < min_entries )
+    {
+        panic("DRTM policy in SLRT contains less than %d entries (%d)!\n",
+              min_entries, policy->nr_entries);
+    }
+
+    if ( efi_enabled(EFI_BOOT) )
+    {
+        check_slrt_policy_entry(&policy_entry[0], 0, slrt);
+        /* SLRT was measured in tpm_measure_slrt(). */
+        return 1;
+    }
+
+    /* This must be legacy MultiBoot2 boot. */
 
     /*
      * MBI policy entry must be the first one, so that measuring order matches
@@ -316,6 +330,7 @@ void __init slaunch_process_drtm_policy(const struct boot_info *bi)
     struct slr_table *slrt;
     struct slr_entry_policy *policy;
     struct slr_policy_entry *policy_entry;
+    int rc;
     uint16_t i;
     unsigned int measured;
 
@@ -331,7 +346,6 @@ void __init slaunch_process_drtm_policy(const struct boot_info *bi)
 
     for ( i = measured; i < policy->nr_entries; i++ )
     {
-        int rc;
         uint64_t start = policy_entry[i].entity;
         uint64_t size = policy_entry[i].size;
 
@@ -376,6 +390,58 @@ void __init slaunch_process_drtm_policy(const struct boot_info *bi)
 
         policy_entry[i].flags |= SLR_POLICY_FLAG_MEASURED;
     }
+
+    /*
+     * On x86 EFI platforms Xen reads its command-line options and kernel/initrd
+     * from configuration files (several can be chained). Bootloader can't know
+     * contents of the configuration beforehand without parsing it, so there
+     * will be no corresponding policy entries. Instead, measure command-line
+     * and all modules here.
+     */
+    if ( efi_enabled(EFI_BOOT) )
+    {
+#define LOG_DATA(str) (uint8_t *)(str), (sizeof(str) - 1)
+
+        tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR,
+                        (const uint8_t *)bi->cmdline, strlen(bi->cmdline),
+                        DLE_EVTYPE_SLAUNCH, LOG_DATA("Xen's command line"));
+
+        for ( i = 0; i < bi->nr_modules; i++ )
+        {
+            const struct boot_module *mod = &bi->mods[i];
+
+            paddr_t string = mod->cmdline_pa;
+            paddr_t start = mod->start;
+            size_t size = mod->size;
+
+            if ( mod->relocated || mod->released )
+            {
+                panic("A module \"%s\" (#%d) was consumed before measurement\n",
+                      (const char *)__va(string), i);
+            }
+
+            /*
+             * Measuring module's name separately because module's command-line
+             * parameters are appended to its name when present.
+             *
+             * 2 MiB is minimally mapped size and it should more than suffice.
+             */
+            rc = slaunch_map_l2(string, 2 * 1024 * 1024);
+            BUG_ON(rc != 0);
+
+            tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR,
+                            __va(string), strlen(__va(string)),
+                            DLE_EVTYPE_SLAUNCH, LOG_DATA("MB module string"));
+
+            rc = slaunch_map_l2(start, size);
+            BUG_ON(rc != 0);
+
+            tpm_hash_extend(DRTM_LOC, DRTM_CODE_PCR, __va(start), size,
+                            DLE_EVTYPE_SLAUNCH, LOG_DATA("MB module"));
+        }
+
+#undef LOG_DATA
+    }
 }
 
 int __init slaunch_map_l2(unsigned long paddr, unsigned long size)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index e39fbc3529..35501ee4de 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -19,6 +19,7 @@
 #if EFI_PAGE_SIZE != PAGE_SIZE
 # error Cannot use xen/pfn.h here!
 #endif
+#include 
 #include 
 #include 
 #ifdef CONFIG_X86
@@ -1004,6 +1005,7 @@ static void __init efi_tables(void)
         static EFI_GUID __initdata mps_guid = MPS_TABLE_GUID;
         static EFI_GUID __initdata smbios_guid = SMBIOS_TABLE_GUID;
         static EFI_GUID __initdata smbios3_guid = SMBIOS3_TABLE_GUID;
+        static EFI_GUID __initdata slr_guid = UEFI_SLR_TABLE_GUID;
 
         if ( match_guid(&acpi2_guid, &efi_ct[i].VendorGuid) )
             efi.acpi20 = (unsigned long)efi_ct[i].VendorTable;
@@ -1015,6 +1017,8 @@ static void __init efi_tables(void)
             efi.smbios = (unsigned long)efi_ct[i].VendorTable;
         if ( match_guid(&smbios3_guid, &efi_ct[i].VendorGuid) )
             efi.smbios3 = (unsigned long)efi_ct[i].VendorTable;
+        if ( match_guid(&slr_guid, &efi_ct[i].VendorGuid) )
+            efi.slr = (unsigned long)efi_ct[i].VendorTable;
         if ( match_guid(&esrt_guid, &efi_ct[i].VendorGuid) )
             esrt = (UINTN)efi_ct[i].VendorTable;
     }
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 7e1fce291d..e1b339f162 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -70,6 +70,7 @@ struct efi __read_mostly efi = {
 	.mps    = EFI_INVALID_TABLE_ADDR,
 	.smbios = EFI_INVALID_TABLE_ADDR,
 	.smbios3 = EFI_INVALID_TABLE_ADDR,
+	.slr    = EFI_INVALID_TABLE_ADDR,
 };
 
 const struct efi_pci_rom *__read_mostly efi_pci_roms;
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 160804e294..614dfce66a 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -19,6 +19,7 @@ struct efi {
     unsigned long acpi20;       /* ACPI table (ACPI 2.0) */
     unsigned long smbios;       /* SM BIOS table */
     unsigned long smbios3;      /* SMBIOS v3 table */
+    unsigned long slr;          /* SLR table */
 };
 
 extern struct efi efi;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:11:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:11:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983308.1369683 (Exim 4.92)
	(envelope-from )
	id 1uEtA8-0004eF-Rn; Tue, 13 May 2025 17:11:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983308.1369683; Tue, 13 May 2025 17:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEtA8-0004e4-Ot; Tue, 13 May 2025 17:11:28 +0000
Received: by outflank-mailman (input) for mailman id 983308;
 Tue, 13 May 2025 17:11:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5d-0003Mm-VH
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:49 +0000
Received: from 6.mo560.mail-out.ovh.net (6.mo560.mail-out.ovh.net
 [87.98.165.38]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a8270440-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:06:48 +0200 (CEST)
Received: from director4.ghost.mail-out.ovh.net (unknown [10.108.17.234])
 by mo560.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZ03VpVz2Cc3
 for ; Tue, 13 May 2025 17:06:48 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-mdgms (unknown [10.110.164.75])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 854AD1FE7E;
 Tue, 13 May 2025 17:06:47 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.112])
 by ghost-submission-5b5ff79f4f-mdgms with ESMTPSA
 id rx7EDCd8I2iuSwEARrC/kw
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: a8270440-301c-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-112S006a94099e6-0d7e-4faf-ac48-888d34d6b9b3,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
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 ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 09/22] xen/lib: add implementation of SHA-1
Date: Tue, 13 May 2025 20:05:46 +0300
Message-ID: <7fcab16c3efbc0eb28e0f8ec0d9c9d3188881ad4.1747155790.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8946400661588718748
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeiteejtdffveekuddtgfegteffkefhgedujeehfeefveekvdevveevteeufeevteenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukedurddujeekpdefjedrheelrddugedvrdduuddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheeitdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=ZTbfrxWs6ho/dNB851C3HFgLhh1CDi/0mFBdC72nYUQ=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156008; v=1;
 b=MbJZuSPhvmeNTxtSVsjL9waWcfb+Z7hwFZ7ytCSwJhD8aSTY5NNh9MLQ8jDS0/U8wq5wJPp/
 UnHZEMED35xFKs7dFe6hboWE6zQOIJy3RffPEMZzbeptmheshKfyS56LyNnAOWVgVs8sz1Rc9pr
 vmkyb21nMgrIWuhaH+EP8VokpiGi3e34rzEeAZbQvlDr3q5FwFbAPrmOJcs84Xx0Y1k0ZBXMmCn
 sXTYywj6l7Tk8FVED/njUXpC37h60lqrAUXQU1uvw9kR0D5/vNN38ZB+uQ+iyrPaVyXmgvo/p+7
 E7LgEygjtzyR17Pg0IZiMqnSBjuMvP9k4rwHVFGGoDT5A==

From: Krystian Hebel 

The code comes from [1] and is licensed under GPL-2.0 license.
The initial version was a combination of:
 - include/crypto/sha1.h
 - include/crypto/sha1_base.h
 - lib/crypto/sha1.c
 - crypto/sha1_generic.c

Changes:
 - includes, formatting, naming
 - renames and splicing of some trivial functions that are called once
 - dropping of `int` return values (only zero was ever returned)
 - getting rid of references to `struct shash_desc`
 - getting rid of macros
 - getting rid of unnecessary function pointers

[1]: https://github.com/torvalds/linux/tree/afdab700f65e14070d8ab92175544b1c62b8bf03

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/include/xen/sha1.h |  12 +++
 xen/lib/Makefile       |   1 +
 xen/lib/sha1.c         | 218 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 231 insertions(+)
 create mode 100644 xen/include/xen/sha1.h
 create mode 100644 xen/lib/sha1.c

diff --git a/xen/include/xen/sha1.h b/xen/include/xen/sha1.h
new file mode 100644
index 0000000000..085f750a6a
--- /dev/null
+++ b/xen/include/xen/sha1.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef XEN__SHA1_H
+#define XEN__SHA1_H
+
+#include 
+
+#define SHA1_DIGEST_SIZE  20
+
+void sha1_hash(uint8_t digest[SHA1_DIGEST_SIZE], const void *msg, size_t len);
+
+#endif /* XEN__SHA1_H */
diff --git a/xen/lib/Makefile b/xen/lib/Makefile
index 5ccb1e5241..fd4b9ece63 100644
--- a/xen/lib/Makefile
+++ b/xen/lib/Makefile
@@ -17,6 +17,7 @@ lib-y += memset.o
 lib-y += muldiv64.o
 lib-y += parse-size.o
 lib-y += rbtree.o
+lib-$(CONFIG_X86) += sha1.o
 lib-$(CONFIG_X86) += sha2-256.o
 lib-y += sort.o
 lib-y += strcasecmp.o
diff --git a/xen/lib/sha1.c b/xen/lib/sha1.c
new file mode 100644
index 0000000000..c7a464e2cf
--- /dev/null
+++ b/xen/lib/sha1.c
@@ -0,0 +1,218 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * SHA1 routine optimized to do word accesses rather than byte accesses,
+ * and to avoid unnecessary copies into the context array.
+ *
+ * This was based on the git SHA1 implementation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * If you have 32 registers or more, the compiler can (and should)
+ * try to change the array[] accesses into registers. However, on
+ * machines with less than ~25 registers, that won't really work,
+ * and at least GCC will make an unholy mess of it.
+ *
+ * So to avoid that mess which just slows things down, we force
+ * the stores to memory to actually happen (we might be better off
+ * with a 'W(t)=(val);asm("":"+m" (W(t))' there instead, as
+ * suggested by Artur Skawina - that will also make GCC unable to
+ * try to do the silly "optimize away loads" part because it won't
+ * see what the value will be).
+ *
+ * Ben Herrenschmidt reports that on PPC, the C version comes close
+ * to the optimized asm with this (ie on PPC you don't want that
+ * 'volatile', since there are lots of registers).
+ *
+ * On ARM we get the best code generation by forcing a full memory barrier
+ * between each SHA round, otherwise GCC happily gets wild with spilling and
+ * the stack frame size simply explode and performance goes down the drain.
+ */
+
+#define SHA1_BLOCK_SIZE         64
+#define SHA1_WORKSPACE_WORDS    16
+#define SHA1_WORKSPACE_MASK     (SHA1_WORKSPACE_WORDS - 1)
+
+struct sha1_state {
+    uint32_t state[SHA1_DIGEST_SIZE / 4];
+    uint64_t count;
+    uint8_t buffer[SHA1_BLOCK_SIZE];
+};
+
+/* This "rolls" over the 512-bit array */
+static void set_w(uint32_t w[SHA1_WORKSPACE_WORDS], size_t i, uint32_t val)
+{
+#ifdef CONFIG_X86
+    *(volatile uint32_t *)&w[i & SHA1_WORKSPACE_MASK] = val;
+#else
+    w[i & SHA1_WORKSPACE_MASK] = val;
+# ifdef CONFIG_ARM
+    barrier();
+# endif
+#endif
+}
+
+static uint32_t blend(const uint32_t w[SHA1_WORKSPACE_WORDS], size_t i)
+{
+/* This "rolls" over the 512-bit array */
+#define w(i) w[(i) & SHA1_WORKSPACE_MASK]
+
+    return rol32(w(i + 13) ^ w(i + 8) ^ w(i + 2) ^ w(i), 1);
+
+#undef w
+}
+
+/**
+ * sha1_transform - single block SHA1 transform
+ *
+ * @digest: 160 bit digest to update
+ * @data:   512 bits of data to hash
+ *
+ * This function executes SHA-1's internal compression function.  It updates the
+ * 160-bit internal state (@digest) with a single 512-bit data block (@data).
+ */
+static void sha1_transform(uint32_t *digest, const uint8_t *data)
+{
+    uint32_t a, b, c, d, e, t;
+    uint32_t workspace[SHA1_WORKSPACE_WORDS];
+    unsigned int i = 0;
+
+    a = digest[0];
+    b = digest[1];
+    c = digest[2];
+    d = digest[3];
+    e = digest[4];
+
+    /* Round 1 - iterations 0-16 take their input from 'data' */
+    for ( ; i < 16; ++i ) {
+        t = get_unaligned_be32((uint32_t *)data + i);
+        set_w(workspace, i, t);
+        e += t + rol32(a, 5) + (((c ^ d) & b) ^ d) + 0x5a827999U;
+        b = ror32(b, 2);
+        t = e; e = d; d = c; c = b; b = a; a = t;
+    }
+
+    /* Round 1 - tail. Input from 512-bit mixing array */
+    for ( ; i < 20; ++i ) {
+        t = blend(workspace, i);
+        set_w(workspace, i, t);
+        e += t + rol32(a, 5) + (((c ^ d) & b) ^ d) + 0x5a827999U;
+        b = ror32(b, 2);
+        t = e; e = d; d = c; c = b; b = a; a = t;
+    }
+
+    /* Round 2 */
+    for ( ; i < 40; ++i ) {
+        t = blend(workspace, i);
+        set_w(workspace, i, t);
+        e += t + rol32(a, 5) + (b ^ c ^ d) + 0x6ed9eba1U;
+        b = ror32(b, 2);
+        t = e; e = d; d = c; c = b; b = a; a = t;
+    }
+
+    /* Round 3 */
+    for ( ; i < 60; ++i ) {
+        t = blend(workspace, i);
+        set_w(workspace, i, t);
+        e += t + rol32(a, 5) + ((b & c) + (d & (b ^ c))) + 0x8f1bbcdcU;
+        b = ror32(b, 2);
+        t = e; e = d; d = c; c = b; b = a; a = t;
+    }
+
+    /* Round 4 */
+    for ( ; i < 80; ++i ) {
+        t = blend(workspace, i);
+        set_w(workspace, i, t);
+        e += t + rol32(a, 5) + (b ^ c ^ d) + 0xca62c1d6U;
+        b = ror32(b, 2);
+        t = e; e = d; d = c; c = b; b = a; a = t;
+    }
+
+    digest[0] += a;
+    digest[1] += b;
+    digest[2] += c;
+    digest[3] += d;
+    digest[4] += e;
+}
+
+static void sha1_init(struct sha1_state *sctx)
+{
+    sctx->state[0] = 0x67452301UL;
+    sctx->state[1] = 0xefcdab89UL;
+    sctx->state[2] = 0x98badcfeUL;
+    sctx->state[3] = 0x10325476UL;
+    sctx->state[4] = 0xc3d2e1f0UL;
+    sctx->count = 0;
+}
+
+static void sha1_update(struct sha1_state *sctx, const uint8_t *msg, size_t len)
+{
+    unsigned int partial = sctx->count % SHA1_BLOCK_SIZE;
+
+    sctx->count += len;
+
+    if ( (partial + len) >= SHA1_BLOCK_SIZE )
+    {
+        if ( partial )
+        {
+            int rem = SHA1_BLOCK_SIZE - partial;
+
+            memcpy(sctx->buffer + partial, msg, rem);
+            msg += rem;
+            len -= rem;
+
+            sha1_transform(sctx->state, sctx->buffer);
+        }
+
+        for ( ; len >= SHA1_BLOCK_SIZE; len -= SHA1_BLOCK_SIZE )
+        {
+            sha1_transform(sctx->state, msg);
+            msg += SHA1_BLOCK_SIZE;
+        }
+        partial = 0;
+    }
+
+    /* Remaining data becomes partial. */
+    memcpy(sctx->buffer + partial, msg, len);
+}
+
+static void sha1_final(struct sha1_state *sctx, void *out)
+{
+    const int bit_offset = SHA1_BLOCK_SIZE - sizeof(__be64);
+    __be64 *bits = (__be64 *)(sctx->buffer + bit_offset);
+    unsigned int partial = sctx->count % SHA1_BLOCK_SIZE;
+
+    __be32 *digest = out;
+    unsigned int i;
+
+    sctx->buffer[partial++] = 0x80;
+    if ( partial > bit_offset )
+    {
+        memset(sctx->buffer + partial, 0x0, SHA1_BLOCK_SIZE - partial);
+        partial = 0;
+
+        sha1_transform(sctx->state, sctx->buffer);
+    }
+
+    memset(sctx->buffer + partial, 0x0, bit_offset - partial);
+    *bits = cpu_to_be64(sctx->count << 3);
+    sha1_transform(sctx->state, sctx->buffer);
+
+    /* Store state in digest */
+    for ( i = 0; i < SHA1_DIGEST_SIZE / sizeof(__be32); i++ )
+        put_unaligned_be32(sctx->state[i], &digest[i]);
+}
+
+void sha1_hash(uint8_t digest[SHA1_DIGEST_SIZE], const void *msg, size_t len)
+{
+    struct sha1_state sctx;
+
+    sha1_init(&sctx);
+    sha1_update(&sctx, msg, len);
+    sha1_final(&sctx, digest);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:11:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:11:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983317.1369693 (Exim 4.92)
	(envelope-from )
	id 1uEtAM-0005H7-4B; Tue, 13 May 2025 17:11:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983317.1369693; Tue, 13 May 2025 17: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 1uEtAL-0005Gt-WF; Tue, 13 May 2025 17:11:42 +0000
Received: by outflank-mailman (input) for mailman id 983317;
 Tue, 13 May 2025 17:11:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt6E-0003Uz-UH
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:07:26 +0000
Received: from 1.mo575.mail-out.ovh.net (1.mo575.mail-out.ovh.net
 [46.105.41.146]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bdf0c63c-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:07:25 +0200 (CEST)
Received: from director5.ghost.mail-out.ovh.net (unknown [10.108.2.253])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZj0tsHz1wl4
 for ; Tue, 13 May 2025 17:07:25 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-2qtvb (unknown [10.111.174.145])
 by director5.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 4F1CA1FE42;
 Tue, 13 May 2025 17:07:24 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.106])
 by ghost-submission-5b5ff79f4f-2qtvb with ESMTPSA
 id RlK5Akx8I2jSxwEAFJ2vGA
 (envelope-from ); Tue, 13 May 2025 17:07: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" 
X-Inumbo-ID: bdf0c63c-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-106R006b9d271f3-da02-4016-b3b2-a9ec1fd8f92a,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 21/22] x86/cpu: report SMX, TXT and SKINIT capabilities
Date: Tue, 13 May 2025 20:05:58 +0300
Message-ID: <7df06438d497830c646db4d32a4715e9fad729ec.1747155790.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8956815236962366620
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhggtgfgsehtkeertdertdejnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepgeekffeiiedtveekhfdugeffveeigefgleegvdeghefftdetheefueeliedukedvnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukedurddujeekpdefjedrheelrddugedvrddutdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheejhegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=xpixWV2mjLfPJBjterQJqwu+52ca0ZiJyxVq/AkKkxM=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156045; v=1;
 b=KXpwKzJca4J3oxVvPsBkDdeqPcWzz5qGHw4Ew0kWg0h7AXN2Vnz2amGTJTNY/uzFGaQw+s8h
 AvwBUWKWMn0yjMXE9VzqCX+kxafgy67m8k2ZlWgaiCRH/7Y9Aymc98G0ryJ4Q2R7CzUQeN1EL8/
 UGabTrzvs8oTLFXK8nWZDgPqei7qqBLrNKCRcGP9UuZbFhvSBjOgyTS3xMnONGge3Yh8ESaH9Fi
 KMdqHur+hVpQCy6gD2hf9SGNSrU78VeNkbjr+3XgapGIgMSeObMOP62a1SYnbhrYLMPWLcQi/7p
 zXPyeSM4a907OjKBKzFiqkRNHMizKE4wekwaqP5Ia7DOQ==

From: Michał Żygowski 

Report TXT capabilities so that dom0 can query the Intel TXT or AMD
SKINIT support information using xl dmesg.

Signed-off-by: Michał Żygowski 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/cpu/amd.c               | 16 ++++++++++
 xen/arch/x86/cpu/cpu.h               |  1 +
 xen/arch/x86/cpu/hygon.c             |  1 +
 xen/arch/x86/cpu/intel.c             | 46 ++++++++++++++++++++++++++++
 xen/arch/x86/include/asm/intel-txt.h |  5 +++
 5 files changed, 69 insertions(+)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 37d67dd15c..18b6cbb50b 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -684,6 +684,21 @@ void amd_log_freq(const struct cpuinfo_x86 *c)
 #undef FREQ
 }
 
+void amd_log_skinit(const struct cpuinfo_x86 *c)
+{
+    /*
+     * Run only on BSP and not during resume to report the capability only once.
+     */
+    if ( system_state != SYS_STATE_resume && smp_processor_id() )
+        return;
+
+    printk("CPU: SKINIT capability ");
+    if ( !test_bit(X86_FEATURE_SKINIT, &boot_cpu_data.x86_capability) )
+        printk("not supported\n");
+    else
+        printk("supported\n");
+}
+
 void cf_check early_init_amd(struct cpuinfo_x86 *c)
 {
 	if (c == &boot_cpu_data)
@@ -1333,6 +1348,7 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
 	check_syscfg_dram_mod_en();
 
 	amd_log_freq(c);
+	amd_log_skinit(c);
 }
 
 const struct cpu_dev __initconst_cf_clobber amd_cpu_dev = {
diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h
index 8be65e975a..5bcf118a93 100644
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -20,6 +20,7 @@ extern bool detect_extended_topology(struct cpuinfo_x86 *c);
 
 void cf_check early_init_amd(struct cpuinfo_x86 *c);
 void amd_log_freq(const struct cpuinfo_x86 *c);
+void amd_log_skinit(const struct cpuinfo_x86 *c);
 void amd_init_lfence(struct cpuinfo_x86 *c);
 void amd_init_ssbd(const struct cpuinfo_x86 *c);
 void amd_init_spectral_chicken(void);
diff --git a/xen/arch/x86/cpu/hygon.c b/xen/arch/x86/cpu/hygon.c
index f7508cc8fc..6ebb8b5fab 100644
--- a/xen/arch/x86/cpu/hygon.c
+++ b/xen/arch/x86/cpu/hygon.c
@@ -85,6 +85,7 @@ static void cf_check init_hygon(struct cpuinfo_x86 *c)
 	}
 
 	amd_log_freq(c);
+	amd_log_skinit(c);
 }
 
 const struct cpu_dev __initconst_cf_clobber hygon_cpu_dev = {
diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 12c3ff65e0..a99aec80ad 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cpu.h"
 
@@ -605,6 +606,49 @@ static void init_intel_perf(struct cpuinfo_x86 *c)
     }
 }
 
+/*
+ * Print out the SMX and TXT capabilties, so that dom0 can determine if the
+ * system is DRTM-capable.
+ */
+static void intel_log_smx_txt(struct cpuinfo_x86 *c)
+{
+    unsigned long cr4_val, getsec_caps;
+
+    /*
+     * Run only on BSP and not during resume to report the capability only once.
+     */
+    if ( system_state != SYS_STATE_resume && smp_processor_id() )
+        return;
+
+    printk("CPU: SMX capability ");
+    if ( !test_bit(X86_FEATURE_SMX, &boot_cpu_data.x86_capability) )
+    {
+        printk("not supported\n");
+        return;
+    }
+    printk("supported\n");
+
+    /* Can't run GETSEC without VMX and SMX */
+    if ( !test_bit(X86_FEATURE_VMX, &boot_cpu_data.x86_capability) )
+        return;
+
+    cr4_val = read_cr4();
+    if ( !(cr4_val & X86_CR4_SMXE) )
+        write_cr4(cr4_val | X86_CR4_SMXE);
+
+    asm volatile ("getsec\n"
+        : "=a" (getsec_caps)
+        : "a" (GETSEC_CAPABILITIES), "b" (0) :);
+
+    if ( getsec_caps & GETSEC_CAP_TXT_CHIPSET )
+        printk("Chipset supports TXT\n");
+    else
+        printk("Chipset does not support TXT\n");
+
+    if ( !(cr4_val & X86_CR4_SMXE) )
+        write_cr4(cr4_val & ~X86_CR4_SMXE);
+}
+
 static void cf_check init_intel(struct cpuinfo_x86 *c)
 {
 	/* Detect the extended topology information if available */
@@ -619,6 +663,8 @@ static void cf_check init_intel(struct cpuinfo_x86 *c)
 		detect_ht(c);
 	}
 
+	intel_log_smx_txt(c);
+
 	/* Work around errata */
 	Intel_errata_workarounds(c);
 
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 5d76443d35..c834e08903 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -85,6 +85,11 @@
 #define TXT_AP_BOOT_CS                  0x0030
 #define TXT_AP_BOOT_DS                  0x0038
 
+/* EAX value for GETSEC leaf functions. Intel SDM: GETSEC[CAPABILITIES] */
+#define GETSEC_CAPABILITIES             0
+/* Intel SDM: GETSEC Capability Result Encoding */
+#define GETSEC_CAP_TXT_CHIPSET          1
+
 #ifndef __ASSEMBLY__
 
 #include 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:11:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:11:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983322.1369703 (Exim 4.92)
	(envelope-from )
	id 1uEtAU-0005t2-BQ; Tue, 13 May 2025 17:11:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983322.1369703; Tue, 13 May 2025 17:11: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 1uEtAU-0005su-88; Tue, 13 May 2025 17:11:50 +0000
Received: by outflank-mailman (input) for mailman id 983322;
 Tue, 13 May 2025 17:11:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5t-0003Mm-Ls
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:07:05 +0000
Received: from 13.mo582.mail-out.ovh.net (13.mo582.mail-out.ovh.net
 [188.165.56.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b0798e6e-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:07:02 +0200 (CEST)
Received: from director7.ghost.mail-out.ovh.net (unknown [10.109.139.225])
 by mo582.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZG3qKJz1f6K
 for ; Tue, 13 May 2025 17:07:02 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-tzcrg (unknown [10.110.118.108])
 by director7.ghost.mail-out.ovh.net (Postfix) with ESMTPS id D9C691FD39;
 Tue, 13 May 2025 17:07:01 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.99])
 by ghost-submission-5b5ff79f4f-tzcrg with ESMTPSA
 id /APTKjV8I2g1KAEAShSnmA
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: b0798e6e-301c-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-99G00304773c23-a1d9-40a9-a6f8-85607a0d1f7b,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 14/22] x86/boot: choose AP stack based on APIC ID
Date: Tue, 13 May 2025 20:05:51 +0300
Message-ID: <391ebc0e786cc94e2e558bfb91383705e8998b35.1747155790.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8950341310297519260
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeevleeiheduleelgfelgeeiveetgeduhfehffefgffhledtvefhledvgfekfefhueenucffohhmrghinhephhgvrggurdhssgdpthhrrghmphholhhinhgvrdhssgdpgiekiegpieegrdhssgenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddrleelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekvdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=LFjLGOzbWGs49PySjNsQW0fv0Cb3jzfBKePmEV573e8=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156022; v=1;
 b=S4CmfvIlPVHOUxOBRXERak2n0KoEmq/QTHvFLaDEZGwxGkxEA6jb29CJ6y4iVxrpNtVWYJg0
 vDQVc9nY8fUbCoyOyUBDoKAdVobWaDRsRbVBlYQxbdMFudZd3ijCPjpDVNwcD8zBR/UgFA08EEW
 lJXa2+YqinoEcRQ5YBXb0SmfMUgUufosT9AIdNOsZyFDBWtvZ7BE5/JItvg8ONh9iyU808kvuL+
 kRtax6AzJCRRfVpmdfZ/psAnxAZSh85dhIGwZKjDCcSZFNec564dFhjbUXJS6KESgBzge2MvECe
 w+yZWgj5bPhdtP6CFF3q6/hGSx7++p0fQ9zK6erWt7s7Q==

From: Krystian Hebel 

This is made as the first step of making parallel AP bring-up possible.
It should be enough for pre-C code.

Parallel AP bring-up is necessary because TXT by design releases all APs
at once. In addition to that it reduces number of IPIs (and more
importantly, delays between them) required to start all logical
processors. This results in significant reduction of boot time, even
when DRTM is not used, with performance gain growing with the number of
logical CPUs.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/boot/head.S             |  1 +
 xen/arch/x86/boot/trampoline.S       | 21 +++++++++++++++++++++
 xen/arch/x86/boot/x86_64.S           | 28 +++++++++++++++++++++++++++-
 xen/arch/x86/include/asm/apicdef.h   |  4 ++++
 xen/arch/x86/include/asm/msr-index.h |  3 +++
 xen/arch/x86/setup.c                 |  7 +++++++
 6 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 9a272155e9..7376fa85d5 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index a92e399fbe..ed593acc46 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -71,6 +71,27 @@ trampoline_protmode_entry:
         mov     $X86_CR4_PAE,%ecx
         mov     %ecx,%cr4
 
+        /*
+         * Get APIC ID while we're in non-paged mode. Start by checking if
+         * x2APIC is enabled.
+         */
+        mov     $MSR_APIC_BASE, %ecx
+        rdmsr
+        test    $APIC_BASE_EXTD, %eax
+        jnz     .Lx2apic
+
+        /* Not x2APIC, read from MMIO */
+        and     $APIC_BASE_ADDR_MASK, %eax
+        mov     APIC_ID(%eax), %esp
+        shr     $24, %esp
+        jmp     1f
+
+.Lx2apic:
+        mov     $(MSR_X2APIC_FIRST + (APIC_ID >> MSR_X2APIC_SHIFT)), %ecx
+        rdmsr
+        mov     %eax, %esp
+1:
+
         /* Load pagetable base register. */
         mov     $sym_offs(idle_pg_table),%eax
         add     bootsym_rel(trampoline_xen_phys_start,4,%eax)
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 08ae97e261..ac33576d8f 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -15,7 +15,33 @@ ENTRY(__high_start)
         mov     $XEN_MINIMAL_CR4,%rcx
         mov     %rcx,%cr4
 
-        mov     stack_start(%rip),%rsp
+        test    %ebx,%ebx
+        cmovz   stack_start(%rip), %rsp
+        jz      .L_stack_set
+
+        /* APs only: get stack base from APIC ID saved in %esp. */
+        mov     $-1, %rax
+        lea     x86_cpu_to_apicid(%rip), %rcx
+1:
+        add     $1, %rax
+        cmp     $NR_CPUS, %eax
+        jb      2f
+        hlt
+2:
+        cmp     %esp, (%rcx, %rax, 4)
+        jne     1b
+
+        /* %eax is now Xen CPU index. */
+        lea     stack_base(%rip), %rcx
+        mov     (%rcx, %rax, 8), %rsp
+
+        test    %rsp,%rsp
+        jnz     1f
+        hlt
+1:
+        add     $(STACK_SIZE - CPUINFO_sizeof), %rsp
+
+.L_stack_set:
 
         /* Reset EFLAGS (subsumes CLI and CLD). */
         pushq   $0
diff --git a/xen/arch/x86/include/asm/apicdef.h b/xen/arch/x86/include/asm/apicdef.h
index 63dab01dde..e093a2aa3c 100644
--- a/xen/arch/x86/include/asm/apicdef.h
+++ b/xen/arch/x86/include/asm/apicdef.h
@@ -121,6 +121,10 @@
 
 #define MAX_IO_APICS 128
 
+#ifndef __ASSEMBLY__
+
 extern bool x2apic_enabled;
 
+#endif /* !__ASSEMBLY__ */
+
 #endif
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 22d9e76e55..794cf44abe 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -169,6 +169,9 @@
 #define MSR_X2APIC_FIRST                    0x00000800
 #define MSR_X2APIC_LAST                     0x000008ff
 
+/* MSR offset can be obtained by shifting MMIO offset this number of bits to the right. */
+#define MSR_X2APIC_SHIFT                    4
+
 #define MSR_X2APIC_TPR                      0x00000808
 #define MSR_X2APIC_PPR                      0x0000080a
 #define MSR_X2APIC_EOI                      0x0000080b
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 479d2d744e..8e79d4be23 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -2096,6 +2096,7 @@ void asmlinkage __init noreturn __start_xen(void)
      */
     if ( !pv_shim )
     {
+        /* Separate loop to make parallel AP bringup possible. */
         for_each_present_cpu ( i )
         {
             /* Set up cpu_to_node[]. */
@@ -2103,6 +2104,12 @@ void asmlinkage __init noreturn __start_xen(void)
             /* Set up node_to_cpumask based on cpu_to_node[]. */
             numa_add_cpu(i);
 
+            if ( stack_base[i] == NULL )
+                stack_base[i] = cpu_alloc_stack(i);
+        }
+
+        for_each_present_cpu ( i )
+        {
             if ( (park_offline_cpus || num_online_cpus() < max_cpus) &&
                  !cpu_online(i) )
             {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:11:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:11:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983328.1369713 (Exim 4.92)
	(envelope-from )
	id 1uEtAZ-0006Mf-PQ; Tue, 13 May 2025 17:11:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983328.1369713; Tue, 13 May 2025 17:11: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 1uEtAZ-0006MV-LP; Tue, 13 May 2025 17:11:55 +0000
Received: by outflank-mailman (input) for mailman id 983328;
 Tue, 13 May 2025 17:11:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5h-0003Uz-FN
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:53 +0000
Received: from 3.mo560.mail-out.ovh.net (3.mo560.mail-out.ovh.net
 [46.105.58.226]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a9a4ef0a-301c-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:06:51 +0200 (CEST)
Received: from director1.ghost.mail-out.ovh.net (unknown [10.108.25.134])
 by mo560.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZ30Ry5z2Cc3
 for ; Tue, 13 May 2025 17:06:51 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-rfbhs (unknown [10.111.174.252])
 by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 5E67C1FE80;
 Tue, 13 May 2025 17:06:50 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.114])
 by ghost-submission-5b5ff79f4f-rfbhs with ESMTPSA
 id y5GpByp8I2gnCwAAJFuK+A
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: a9a4ef0a-301c-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-114S00839dca217-85b7-48ce-9f56-8c503f8e75ef,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 10/22] x86/tpm.c: code for early hashing and extending PCRs (for TPM1.2)
Date: Tue, 13 May 2025 20:05:47 +0300
Message-ID: <71a2b0627989af93c95dc9e3ba87a9f2d5df3941.1747155790.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8947245087207961756
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeffjefgudevkeetudegueeihfdthfejgfeileekuefggeegtdegveehfeehfeefueenucffohhmrghinhepsggrshgvrdhmrghppdhhvggrugdrshgsnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukedurddujeekpdefjedrheelrddugedvrdduudegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheeitdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=tAF8MJmpMWjqKcWifvElHKEthlFJuOL3Tg/f8utxyvY=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156011; v=1;
 b=LN6L2DF9O8BUbj8fNRP041yzNsQHKGWO1vbxx86CzQjmlxdu9V75zjWvwJ1rQnIiL8H1d1Ks
 xT17EE/a8V8zpeK+7nE3rG5d36mUYKJZo7OPQPEZSHfmOIcYzLm9WM5nOBB4L/ltu1kZg58W7bp
 XDdgmxFDtSxOJo2/uqtYC3wfyPhc19oF41bYty+AsgmzOCSor14JUj4qZI7be1IO7lglqT0RyB1
 vDVLnCNH9cBk54ie4TSAgczxSSI5yZGKaX1owUjbsIeo6gTonSeARngzRIAJtsE8/bupLA+nk1d
 lP+sGCiNNMqehXZMVc5hgR/r88KRmI+ugTW/muoKJXEjQ==

From: Krystian Hebel 

This file is built twice: for early 32b mode without paging to measure
MBI and for 64b code to measure dom0 kernel and initramfs. Since MBI
is small, the first case uses TPM to do the hashing. Kernel and
initramfs on the other hand are too big, sending them to the TPM would
take multiple minutes.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/Makefile              |   1 +
 xen/arch/x86/boot/Makefile         |   7 +-
 xen/arch/x86/boot/head.S           |   3 +
 xen/arch/x86/include/asm/slaunch.h |  14 +
 xen/arch/x86/include/asm/tpm.h     |  19 ++
 xen/arch/x86/slaunch.c             |   7 +-
 xen/arch/x86/tpm.c                 | 437 +++++++++++++++++++++++++++++
 7 files changed, 486 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/tpm.h
 create mode 100644 xen/arch/x86/tpm.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 6f15c5a87a..2527a1909c 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -66,6 +66,7 @@ obj-y += spec_ctrl.o
 obj-y += srat.o
 obj-y += string.o
 obj-y += time.o
+obj-y += tpm.o
 obj-y += traps-setup.o
 obj-y += traps.o
 obj-$(CONFIG_INTEL) += tsx.o
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5471b966dd..55fbe155b6 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -6,6 +6,7 @@ obj32 := cmdline.32.o
 obj32 += reloc.32.o
 obj32 += reloc-trampoline.32.o
 obj32 += slaunch-early.32.o
+obj32 += tpm-early.32.o
 
 obj64 := reloc-trampoline.o
 
@@ -31,6 +32,10 @@ $(obj)/%.32.o: $(src)/%.c FORCE
 
 $(obj)/slaunch-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
 
+$(obj)/tpm-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
+$(obj)/tpm-early.32.o: $(src)/../tpm.c FORCE
+	$(call if_changed_rule,cc_o_c)
+
 orphan-handling-$(call ld-option,--orphan-handling=error) := --orphan-handling=error
 LDFLAGS_DIRECT-$(call ld-option,--warn-rwx-segments) := --no-warn-rwx-segments
 LDFLAGS_DIRECT += $(LDFLAGS_DIRECT-y)
@@ -84,7 +89,7 @@ cmd_combine = \
               --bin1      $(obj)/built-in-32.base.bin \
               --bin2      $(obj)/built-in-32.offset.bin \
               --map       $(obj)/built-in-32.base.map \
-              --exports   cmdline_parse_early,reloc,reloc_trampoline32,slaunch_early_init \
+              --exports   cmdline_parse_early,reloc,reloc_trampoline32,slaunch_early_init,tpm_extend_mbi \
               --output    $@
 
 targets += built-in-32.S
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index b4cf423c80..9a272155e9 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -527,6 +527,9 @@ __start:
         /* Store MBI address in EBX where MB2 code expects it. */
         mov     %eax, %ebx
 
+        /* tpm_extend_mbi(mbi/eax, slrt/edx) using fastcall. */
+        call    tpm_extend_mbi
+
         /* Move magic number expected by Multiboot 2 to EAX and fall through. */
         movl    $MULTIBOOT2_BOOTLOADER_MAGIC, %eax
 
diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
index ddc1bd2361..4ff1f9c7d5 100644
--- a/xen/arch/x86/include/asm/slaunch.h
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -10,6 +10,20 @@
 #include 
 #include 
 
+#define DRTM_LOC                   2
+#define DRTM_CODE_PCR              17
+#define DRTM_DATA_PCR              18
+
+/*
+ * Secure Launch event log entry types. The TXT specification defines the base
+ * event value as 0x400 for DRTM values, use it regardless of the DRTM for
+ * consistency.
+ */
+#define DLE_EVTYPE_BASE            0x400
+#define DLE_EVTYPE_SLAUNCH         (DLE_EVTYPE_BASE + 0x102)
+#define DLE_EVTYPE_SLAUNCH_START   (DLE_EVTYPE_BASE + 0x103)
+#define DLE_EVTYPE_SLAUNCH_END     (DLE_EVTYPE_BASE + 0x104)
+
 /* Indicates an active Secure Launch boot. */
 extern bool slaunch_active;
 
diff --git a/xen/arch/x86/include/asm/tpm.h b/xen/arch/x86/include/asm/tpm.h
new file mode 100644
index 0000000000..a3c9e24b8f
--- /dev/null
+++ b/xen/arch/x86/include/asm/tpm.h
@@ -0,0 +1,19 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#ifndef ASM__X86__TPM_H
+#define ASM__X86__TPM_H
+
+#include 
+
+#define TPM_TIS_BASE  0xfed40000U
+#define TPM_TIS_SIZE  0x00010000U
+
+void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
+                     unsigned size, uint32_t type, const uint8_t *log_data,
+                     unsigned log_data_size);
+
+#endif /* ASM__X86__TPM_H */
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index ac3b43942b..5f91fe5ad0 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * These variables are assigned to by the code near Xen's entry point.
@@ -66,16 +67,20 @@ struct slr_table *__init slaunch_get_slrt(void)
 
 void __init slaunch_map_mem_regions(void)
 {
+    int rc;
     void *evt_log_addr;
     uint32_t evt_log_size;
 
+    rc = slaunch_map_l2(TPM_TIS_BASE, TPM_TIS_SIZE);
+    BUG_ON(rc != 0);
+
     /* Vendor-specific part. */
     txt_map_mem_regions();
 
     find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
     if ( evt_log_addr != NULL )
     {
-        int rc = slaunch_map_l2((uintptr_t)evt_log_addr, evt_log_size);
+        rc = slaunch_map_l2((uintptr_t)evt_log_addr, evt_log_size);
         BUG_ON(rc != 0);
     }
 }
diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
new file mode 100644
index 0000000000..7fb19ce4fa
--- /dev/null
+++ b/xen/arch/x86/tpm.c
@@ -0,0 +1,437 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef __EARLY_SLAUNCH__
+
+#ifdef __va
+#error "__va defined in non-paged mode!"
+#endif
+
+#define __va(x)     _p(x)
+
+/* Implementation of slaunch_get_slrt() for early TPM code. */
+static uint32_t slrt_location;
+struct slr_table *slaunch_get_slrt(void)
+{
+    return __va(slrt_location);
+}
+
+/*
+ * The code is being compiled as a standalone binary without linking to any
+ * other part of Xen.  Providing implementation of builtin functions in this
+ * case is necessary if compiler chooses to not use an inline builtin.
+ */
+void *(memcpy)(void *dest, const void *src, size_t n)
+{
+    const uint8_t *s = src;
+    uint8_t *d = dest;
+
+    while ( n-- )
+        *d++ = *s++;
+
+    return dest;
+}
+
+#else   /* __EARLY_SLAUNCH__ */
+
+#include 
+#include 
+
+#endif  /* __EARLY_SLAUNCH__ */
+
+#define TPM_LOC_REG(loc, reg)   (0x1000 * (loc) + (reg))
+
+#define TPM_ACCESS_(x)          TPM_LOC_REG(x, 0x00)
+#define ACCESS_REQUEST_USE       (1 << 1)
+#define ACCESS_ACTIVE_LOCALITY   (1 << 5)
+#define TPM_INTF_CAPABILITY_(x) TPM_LOC_REG(x, 0x14)
+#define INTF_VERSION_MASK        0x70000000
+#define TPM_STS_(x)             TPM_LOC_REG(x, 0x18)
+#define TPM_FAMILY_MASK          0x0C000000
+#define STS_DATA_AVAIL           (1 << 4)
+#define STS_TPM_GO               (1 << 5)
+#define STS_COMMAND_READY        (1 << 6)
+#define STS_VALID                (1 << 7)
+#define TPM_DATA_FIFO_(x)       TPM_LOC_REG(x, 0x24)
+
+#define swap16(x)       __builtin_bswap16(x)
+#define swap32(x)       __builtin_bswap32(x)
+
+static inline volatile uint32_t tis_read32(unsigned reg)
+{
+    return *(volatile uint32_t *)__va(TPM_TIS_BASE + reg);
+}
+
+static inline volatile uint8_t tis_read8(unsigned reg)
+{
+    return *(volatile uint8_t *)__va(TPM_TIS_BASE + reg);
+}
+
+static inline void tis_write8(unsigned reg, uint8_t val)
+{
+    *(volatile uint8_t *)__va(TPM_TIS_BASE + reg) = val;
+}
+
+static inline void request_locality(unsigned loc)
+{
+    tis_write8(TPM_ACCESS_(loc), ACCESS_REQUEST_USE);
+    /* Check that locality was actually activated. */
+    while ( (tis_read8(TPM_ACCESS_(loc)) & ACCESS_ACTIVE_LOCALITY) == 0 );
+}
+
+static inline void relinquish_locality(unsigned loc)
+{
+    tis_write8(TPM_ACCESS_(loc), ACCESS_ACTIVE_LOCALITY);
+}
+
+static void send_cmd(unsigned loc, uint8_t *buf, unsigned i_size,
+                     unsigned *o_size)
+{
+    /*
+     * Value of "data available" bit counts only when "valid" field is set as
+     * well.
+     */
+    const unsigned data_avail = STS_VALID | STS_DATA_AVAIL;
+
+    unsigned i;
+
+    /* Make sure TPM can accept a command. */
+    if ( (tis_read8(TPM_STS_(loc)) & STS_COMMAND_READY) == 0 )
+    {
+        /* Abort current command. */
+        tis_write8(TPM_STS_(loc), STS_COMMAND_READY);
+        /* Wait until TPM is ready for a new one. */
+        while ( (tis_read8(TPM_STS_(loc)) & STS_COMMAND_READY) == 0 );
+    }
+
+    for ( i = 0; i < i_size; i++ )
+        tis_write8(TPM_DATA_FIFO_(loc), buf[i]);
+
+    tis_write8(TPM_STS_(loc), STS_TPM_GO);
+
+    /* Wait for the first byte of response. */
+    while ( (tis_read8(TPM_STS_(loc)) & data_avail) != data_avail);
+
+    for ( i = 0; i < *o_size && tis_read8(TPM_STS_(loc)) & data_avail; i++ )
+        buf[i] = tis_read8(TPM_DATA_FIFO_(loc));
+
+    if ( i < *o_size )
+        *o_size = i;
+
+    tis_write8(TPM_STS_(loc), STS_COMMAND_READY);
+}
+
+static inline bool is_tpm12(void)
+{
+    /*
+     * If one of these conditions is true:
+     *  - INTF_CAPABILITY_x.interfaceVersion is 0 (TIS <= 1.21)
+     *  - INTF_CAPABILITY_x.interfaceVersion is 2 (TIS == 1.3)
+     *  - STS_x.tpmFamily is 0
+     * we're dealing with TPM1.2.
+     */
+    uint32_t intf_version = tis_read32(TPM_INTF_CAPABILITY_(0))
+                          & INTF_VERSION_MASK;
+    return (intf_version == 0x00000000 || intf_version == 0x20000000 ||
+            (tis_read32(TPM_STS_(0)) & TPM_FAMILY_MASK) == 0);
+}
+
+/****************************** TPM1.2 specific *******************************/
+#define TPM_ORD_Extend              0x00000014
+#define TPM_ORD_SHA1Start           0x000000A0
+#define TPM_ORD_SHA1Update          0x000000A1
+#define TPM_ORD_SHA1CompleteExtend  0x000000A3
+
+#define TPM_TAG_RQU_COMMAND         0x00C1
+#define TPM_TAG_RSP_COMMAND         0x00C4
+
+/* All fields of following structs are big endian. */
+struct tpm_cmd_hdr {
+    uint16_t    tag;
+    uint32_t    paramSize;
+    uint32_t    ordinal;
+} __packed;
+
+struct tpm_rsp_hdr {
+    uint16_t    tag;
+    uint32_t    paramSize;
+    uint32_t    returnCode;
+} __packed;
+
+struct extend_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrNum;
+    uint8_t inDigest[SHA1_DIGEST_SIZE];
+} __packed;
+
+struct extend_rsp {
+    struct tpm_rsp_hdr h;
+    uint8_t outDigest[SHA1_DIGEST_SIZE];
+} __packed;
+
+struct sha1_start_cmd {
+    struct tpm_cmd_hdr h;
+} __packed;
+
+struct sha1_start_rsp {
+    struct tpm_rsp_hdr h;
+    uint32_t maxNumBytes;
+} __packed;
+
+struct sha1_update_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t numBytes;          /* Must be a multiple of 64 */
+    uint8_t hashData[];
+} __packed;
+
+struct sha1_update_rsp {
+    struct tpm_rsp_hdr h;
+} __packed;
+
+struct sha1_complete_extend_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrNum;
+    uint32_t hashDataSize;      /* 0-64, inclusive */
+    uint8_t hashData[];
+} __packed;
+
+struct sha1_complete_extend_rsp {
+    struct tpm_rsp_hdr h;
+    uint8_t hashValue[SHA1_DIGEST_SIZE];
+    uint8_t outDigest[SHA1_DIGEST_SIZE];
+} __packed;
+
+struct TPM12_PCREvent {
+    uint32_t PCRIndex;
+    uint32_t Type;
+    uint8_t Digest[SHA1_DIGEST_SIZE];
+    uint32_t Size;
+    uint8_t Data[];
+};
+
+struct txt_ev_log_container_12 {
+    char        Signature[20];      /* "TXT Event Container", null-terminated */
+    uint8_t     Reserved[12];
+    uint8_t     ContainerVerMajor;
+    uint8_t     ContainerVerMinor;
+    uint8_t     PCREventVerMajor;
+    uint8_t     PCREventVerMinor;
+    uint32_t    ContainerSize;      /* Allocated size */
+    uint32_t    PCREventsOffset;
+    uint32_t    NextEventOffset;
+    struct TPM12_PCREvent   PCREvents[];
+};
+
+#ifdef __EARLY_SLAUNCH__
+/*
+ * TPM1.2 is required to support commands of up to 1101 bytes, vendors rarely
+ * go above that. Limit maximum size of block of data to be hashed to 1024.
+ */
+#define MAX_HASH_BLOCK      1024
+#define CMD_RSP_BUF_SIZE    (sizeof(struct sha1_update_cmd) + MAX_HASH_BLOCK)
+
+union cmd_rsp {
+    struct sha1_start_cmd start_c;
+    struct sha1_start_rsp start_r;
+    struct sha1_update_cmd update_c;
+    struct sha1_update_rsp update_r;
+    struct sha1_complete_extend_cmd finish_c;
+    struct sha1_complete_extend_rsp finish_r;
+    uint8_t buf[CMD_RSP_BUF_SIZE];
+};
+
+/* Returns true on success. */
+static bool tpm12_hash_extend(unsigned loc, const uint8_t *buf, unsigned size,
+                              unsigned pcr, uint8_t *out_digest)
+{
+    union cmd_rsp cmd_rsp;
+    unsigned max_bytes = MAX_HASH_BLOCK;
+    unsigned o_size = sizeof(cmd_rsp);
+    bool success = false;
+
+    request_locality(loc);
+
+    cmd_rsp.start_c = (struct sha1_start_cmd) {
+        .h.tag = swap16(TPM_TAG_RQU_COMMAND),
+        .h.paramSize = swap32(sizeof(struct sha1_start_cmd)),
+        .h.ordinal = swap32(TPM_ORD_SHA1Start),
+    };
+
+    send_cmd(loc, cmd_rsp.buf, sizeof(struct sha1_start_cmd), &o_size);
+    if ( o_size < sizeof(struct sha1_start_rsp) )
+        goto error;
+
+    if ( max_bytes > swap32(cmd_rsp.start_r.maxNumBytes) )
+        max_bytes = swap32(cmd_rsp.start_r.maxNumBytes);
+
+    while ( size > 64 )
+    {
+        if ( size < max_bytes )
+            max_bytes = size & ~(64 - 1);
+
+        o_size = sizeof(cmd_rsp);
+
+        cmd_rsp.update_c = (struct sha1_update_cmd){
+            .h.tag = swap16(TPM_TAG_RQU_COMMAND),
+            .h.paramSize = swap32(sizeof(struct sha1_update_cmd) + max_bytes),
+            .h.ordinal = swap32(TPM_ORD_SHA1Update),
+            .numBytes = swap32(max_bytes),
+        };
+        memcpy(cmd_rsp.update_c.hashData, buf, max_bytes);
+
+        send_cmd(loc, cmd_rsp.buf, sizeof(struct sha1_update_cmd) + max_bytes,
+                 &o_size);
+        if ( o_size < sizeof(struct sha1_update_rsp) )
+            goto error;
+
+        size -= max_bytes;
+        buf += max_bytes;
+    }
+
+    o_size = sizeof(cmd_rsp);
+
+    cmd_rsp.finish_c = (struct sha1_complete_extend_cmd) {
+        .h.tag = swap16(TPM_TAG_RQU_COMMAND),
+        .h.paramSize = swap32(sizeof(struct sha1_complete_extend_cmd) + size),
+        .h.ordinal = swap32(TPM_ORD_SHA1CompleteExtend),
+        .pcrNum = swap32(pcr),
+        .hashDataSize = swap32(size),
+    };
+    memcpy(cmd_rsp.finish_c.hashData, buf, size);
+
+    send_cmd(loc, cmd_rsp.buf, sizeof(struct sha1_complete_extend_cmd) + size,
+             &o_size);
+    if ( o_size < sizeof(struct sha1_complete_extend_rsp) )
+        goto error;
+
+    if ( out_digest != NULL )
+        memcpy(out_digest, cmd_rsp.finish_r.hashValue, SHA1_DIGEST_SIZE);
+
+    success = true;
+
+error:
+    relinquish_locality(loc);
+    return success;
+}
+
+#else
+
+union cmd_rsp {
+    struct extend_cmd extend_c;
+    struct extend_rsp extend_r;
+};
+
+/* Returns true on success. */
+static bool tpm12_hash_extend(unsigned loc, const uint8_t *buf, unsigned size,
+                              unsigned pcr, uint8_t *out_digest)
+{
+    union cmd_rsp cmd_rsp;
+    unsigned o_size = sizeof(cmd_rsp);
+
+    sha1_hash(out_digest, buf, size);
+
+    request_locality(loc);
+
+    cmd_rsp.extend_c = (struct extend_cmd) {
+        .h.tag = swap16(TPM_TAG_RQU_COMMAND),
+        .h.paramSize = swap32(sizeof(struct extend_cmd)),
+        .h.ordinal = swap32(TPM_ORD_Extend),
+        .pcrNum = swap32(pcr),
+    };
+
+    memcpy(cmd_rsp.extend_c.inDigest, out_digest, SHA1_DIGEST_SIZE);
+
+    send_cmd(loc, (uint8_t *)&cmd_rsp, sizeof(struct extend_cmd), &o_size);
+
+    relinquish_locality(loc);
+
+    return (o_size >= sizeof(struct extend_rsp));
+}
+
+#endif /* __EARLY_SLAUNCH__ */
+
+static void *create_log_event12(struct txt_ev_log_container_12 *evt_log,
+                                uint32_t evt_log_size, uint32_t pcr,
+                                uint32_t type, const uint8_t *data,
+                                unsigned data_size)
+{
+    struct TPM12_PCREvent *new_entry;
+
+    new_entry = (void *)(((uint8_t *)evt_log) + evt_log->NextEventOffset);
+
+    /*
+     * Check if there is enough space left for new entry.
+     * Note: it is possible to introduce a gap in event log if entry with big
+     * data_size is followed by another entry with smaller data. Maybe we should
+     * cap the event log size in such case?
+     */
+    if ( evt_log->NextEventOffset + sizeof(struct TPM12_PCREvent) + data_size
+         > evt_log_size )
+        return NULL;
+
+    evt_log->NextEventOffset += sizeof(struct TPM12_PCREvent) + data_size;
+
+    new_entry->PCRIndex = pcr;
+    new_entry->Type = type;
+    new_entry->Size = data_size;
+
+    if ( data && data_size > 0 )
+        memcpy(new_entry->Data, data, data_size);
+
+    return new_entry->Digest;
+}
+
+/************************** end of TPM1.2 specific ****************************/
+
+void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
+                     unsigned size, uint32_t type, const uint8_t *log_data,
+                     unsigned log_data_size)
+{
+    void *evt_log_addr;
+    uint32_t evt_log_size;
+
+    find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
+    evt_log_addr = __va((uintptr_t)evt_log_addr);
+
+    if ( is_tpm12() )
+    {
+        uint8_t sha1_digest[SHA1_DIGEST_SIZE];
+
+        struct txt_ev_log_container_12 *evt_log = evt_log_addr;
+        void *entry_digest = create_log_event12(evt_log, evt_log_size, pcr,
+                                                type, log_data, log_data_size);
+
+        /* We still need to write computed hash somewhere. */
+        if ( entry_digest == NULL )
+            entry_digest = sha1_digest;
+
+        if ( !tpm12_hash_extend(loc, buf, size, pcr, entry_digest) )
+        {
+#ifndef __EARLY_SLAUNCH__
+            printk(XENLOG_ERR "Extending PCR%u failed\n", pcr);
+#endif
+        }
+    }
+}
+
+#ifdef __EARLY_SLAUNCH__
+void asmlinkage tpm_extend_mbi(uint32_t *mbi, uint32_t slrt_pa)
+{
+    /* Need this to implement slaunch_get_slrt() for early TPM code. */
+    slrt_location = slrt_pa;
+
+    /* MBI starts with uint32_t total_size. */
+    tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)mbi, *mbi,
+                    DLE_EVTYPE_SLAUNCH, NULL, 0);
+}
+#endif
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:12:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:12:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983343.1369723 (Exim 4.92)
	(envelope-from )
	id 1uEtAt-0007Ja-2L; Tue, 13 May 2025 17:12:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983343.1369723; Tue, 13 May 2025 17:12: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 1uEtAs-0007JP-Ui; Tue, 13 May 2025 17:12:14 +0000
Received: by outflank-mailman (input) for mailman id 983343;
 Tue, 13 May 2025 17:12:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5X-0003Mm-LE
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:43 +0000
Received: from 9.mo581.mail-out.ovh.net (9.mo581.mail-out.ovh.net
 [46.105.60.248]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a490bcf8-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:06:42 +0200 (CEST)
Received: from director7.ghost.mail-out.ovh.net (unknown [10.109.140.207])
 by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjYt3ypbz1F88
 for ; Tue, 13 May 2025 17:06:42 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-mdgms (unknown [10.110.164.115])
 by director7.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 07C2E1FD39;
 Tue, 13 May 2025 17:06:41 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.114])
 by ghost-submission-5b5ff79f4f-mdgms with ESMTPSA
 id JVrPMyF8I2ikSwEARrC/kw
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: a490bcf8-301c-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-114S0082d89efb0-7dca-433b-9db6-efa760fdab17,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 07/22] x86/mtrr: expose functions for pausing caching
Date: Tue, 13 May 2025 20:05:44 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8944711813313967260
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpefhheefheduieelieekfffgfffgfedutdevleevvdfhfffgledvgfdtuddtheefieenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddruddugeenucevlhhushhtvghrufhiiigvpeegnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkedumgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=p5/X8odYi3YN7N37QJCMftuc5hqSiV9vDM1ybqq3iiI=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156002; v=1;
 b=hGHensDJA5nIUwOWVrg1VRKg9jr4cvOCYo5VjuKrGN6AbVFlRNHhkNOCFVPK/XTOonZ1uPZw
 1Gy9IgTSIK9REdsVXBm+mwzxcZHM1QG+pkrgWozYCrVueAcCT/WST6u7gyWyqZY3Ge5e4wUv4ts
 Tc1wmPYeKYNbG2/D8w2rmISFfW1Hj/FM41MrPp6wwkULLg3sxzTj/0yhcWLrEOKi/pFCTbAMGTY
 tJnxdMnr50bxsY+/J2AGNSfr/ZaxQy/YGixIBZ233hy58iaG+lvXIMRbMsUhr+1O1KyL659V+po
 0CQL3/X7p60mEcu223kHJvL/vOgrzHIsmEW2Wk9S01uPg==

This allows the functionality to be reused by other units that need to
update MTRRs.

This also gets rid of a static variable.

Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/cpu/mtrr/generic.c | 51 ++++++++++++++++-----------------
 xen/arch/x86/include/asm/mtrr.h |  8 ++++++
 2 files changed, 33 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index c587e9140e..2a8dd1d8ff 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -396,9 +396,7 @@ static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
 	return changed;
 }
 
-static uint64_t deftype;
-
-static unsigned long set_mtrr_state(void)
+static unsigned long set_mtrr_state(uint64_t *deftype)
 /*  [SUMMARY] Set the MTRR state for this CPU.
      The MTRR state information to read.
      Some relevant CPU context.
@@ -416,14 +414,12 @@ static unsigned long set_mtrr_state(void)
 	if (mtrr_state.have_fixed && set_fixed_ranges(mtrr_state.fixed_ranges))
 		change_mask |= MTRR_CHANGE_MASK_FIXED;
 
-	/*  Set_mtrr_restore restores the old value of MTRRdefType,
-	   so to set it we fiddle with the saved value  */
-	if ((deftype & 0xff) != mtrr_state.def_type
-	    || MASK_EXTR(deftype, MTRRdefType_E) != mtrr_state.enabled
-	    || MASK_EXTR(deftype, MTRRdefType_FE) != mtrr_state.fixed_enabled) {
-		deftype = (deftype & ~0xcff) | mtrr_state.def_type |
-		          MASK_INSR(mtrr_state.enabled, MTRRdefType_E) |
-		          MASK_INSR(mtrr_state.fixed_enabled, MTRRdefType_FE);
+	if ((*deftype & 0xff) != mtrr_state.def_type
+	    || MASK_EXTR(*deftype, MTRRdefType_E) != mtrr_state.enabled
+	    || MASK_EXTR(*deftype, MTRRdefType_FE) != mtrr_state.fixed_enabled) {
+		*deftype = (*deftype & ~0xcff) | mtrr_state.def_type |
+		           MASK_INSR(mtrr_state.enabled, MTRRdefType_E) |
+		           MASK_INSR(mtrr_state.fixed_enabled, MTRRdefType_FE);
 		change_mask |= MTRR_CHANGE_MASK_DEFTYPE;
 	}
 
@@ -440,9 +436,10 @@ static DEFINE_SPINLOCK(set_atomicity_lock);
  * has been called.
  */
 
-static bool prepare_set(void)
+struct mtrr_pausing_state mtrr_pause_caching(void)
 {
 	unsigned long cr4;
+	struct mtrr_pausing_state state;
 
 	/*  Note that this is not ideal, since the cache is only flushed/disabled
 	   for this CPU while the MTRRs are changed, but changing this requires
@@ -462,7 +459,9 @@ static bool prepare_set(void)
 	alternative("wbinvd", "", X86_FEATURE_XEN_SELFSNOOP);
 
 	cr4 = read_cr4();
-	if (cr4 & X86_CR4_PGE)
+	state.pge = cr4 & X86_CR4_PGE;
+
+	if (state.pge)
 		write_cr4(cr4 & ~X86_CR4_PGE);
 	else if (use_invpcid)
 		invpcid_flush_all();
@@ -470,27 +469,27 @@ static bool prepare_set(void)
 		write_cr3(read_cr3());
 
 	/*  Save MTRR state */
-	rdmsrl(MSR_MTRRdefType, deftype);
+	rdmsrl(MSR_MTRRdefType, state.def_type);
 
 	/*  Disable MTRRs, and set the default type to uncached  */
-	mtrr_wrmsr(MSR_MTRRdefType, deftype & ~0xcff);
+	mtrr_wrmsr(MSR_MTRRdefType, state.def_type & ~0xcff);
 
 	/* Again, only flush caches if we have to. */
 	alternative("wbinvd", "", X86_FEATURE_XEN_SELFSNOOP);
 
-	return cr4 & X86_CR4_PGE;
+	return state;
 }
 
-static void post_set(bool pge)
+void mtrr_resume_caching(struct mtrr_pausing_state state)
 {
 	/* Intel (P6) standard MTRRs */
-	mtrr_wrmsr(MSR_MTRRdefType, deftype);
+	mtrr_wrmsr(MSR_MTRRdefType, state.def_type);
 
 	/*  Enable caches  */
 	write_cr0(read_cr0() & ~X86_CR0_CD);
 
 	/*  Reenable CR4.PGE (also flushes the TLB) */
-	if (pge)
+	if (state.pge)
 		write_cr4(read_cr4() | X86_CR4_PGE);
 	else if (use_invpcid)
 		invpcid_flush_all();
@@ -504,15 +503,15 @@ void mtrr_set_all(void)
 {
 	unsigned long mask, count;
 	unsigned long flags;
-	bool pge;
+	struct mtrr_pausing_state pausing_state;
 
 	local_irq_save(flags);
-	pge = prepare_set();
+	pausing_state = mtrr_pause_caching();
 
 	/* Actually set the state */
-	mask = set_mtrr_state();
+	mask = set_mtrr_state(&pausing_state.def_type);
 
-	post_set(pge);
+	mtrr_resume_caching(pausing_state);
 	local_irq_restore(flags);
 
 	/*  Use the atomic bitops to update the global mask  */
@@ -537,12 +536,12 @@ void mtrr_set(
 {
 	unsigned long flags;
 	struct mtrr_var_range *vr;
-	bool pge;
+	struct mtrr_pausing_state pausing_state;
 
 	vr = &mtrr_state.var_ranges[reg];
 
 	local_irq_save(flags);
-	pge = prepare_set();
+	pausing_state = mtrr_pause_caching();
 
 	if (size == 0) {
 		/* The invalid bit is kept in the mask, so we simply clear the
@@ -563,7 +562,7 @@ void mtrr_set(
 		mtrr_wrmsr(MSR_IA32_MTRR_PHYSMASK(reg), vr->mask);
 	}
 
-	post_set(pge);
+	mtrr_resume_caching(pausing_state);
 	local_irq_restore(flags);
 }
 
diff --git a/xen/arch/x86/include/asm/mtrr.h b/xen/arch/x86/include/asm/mtrr.h
index 25d442659d..82ea427ba0 100644
--- a/xen/arch/x86/include/asm/mtrr.h
+++ b/xen/arch/x86/include/asm/mtrr.h
@@ -66,6 +66,14 @@ extern uint8_t pat_type_2_pte_flags(uint8_t pat_type);
 extern void mtrr_aps_sync_begin(void);
 extern void mtrr_aps_sync_end(void);
 
+struct mtrr_pausing_state {
+	bool pge;
+	uint64_t def_type;
+};
+
+extern struct mtrr_pausing_state mtrr_pause_caching(void);
+extern void mtrr_resume_caching(struct mtrr_pausing_state state);
+
 extern bool mtrr_var_range_msr_set(struct domain *d, struct mtrr_state *m,
                                    uint32_t msr, uint64_t msr_content);
 extern bool mtrr_fix_range_msr_set(struct domain *d, struct mtrr_state *m,
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:12:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:12:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983344.1369726 (Exim 4.92)
	(envelope-from )
	id 1uEtAt-0007MQ-9F; Tue, 13 May 2025 17:12:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983344.1369726; Tue, 13 May 2025 17:12: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 1uEtAt-0007LN-5u; Tue, 13 May 2025 17:12:15 +0000
Received: by outflank-mailman (input) for mailman id 983344;
 Tue, 13 May 2025 17:12:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt61-0003Mm-BQ
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:07:13 +0000
Received: from 12.mo581.mail-out.ovh.net (12.mo581.mail-out.ovh.net
 [178.33.107.167]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b64bdc9d-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:07:12 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.108.9.185])
 by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZS26L1z1JCW
 for ; Tue, 13 May 2025 17:07:12 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-rmfj9 (unknown [10.110.101.129])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 9C3241FE6E;
 Tue, 13 May 2025 17:07:11 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.106])
 by ghost-submission-5b5ff79f4f-rmfj9 with ESMTPSA
 id CmLADj98I2joPwEAsHcBfw
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: b64bdc9d-301c-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-106R006702d9b2a-3705-4bfd-8582-94ee596064ad,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 17/22] x86/acpi: disallow S3 on Secure Launch boot
Date: Tue, 13 May 2025 20:05:54 +0300
Message-ID: <557fece168d8c9688338c2e69f96a8c5177ba9de.1747155790.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8953156063255704732
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpefhheefheduieelieekfffgfffgfedutdevleevvdfhfffgledvgfdtuddtheefieenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddruddtieenucevlhhushhtvghrufhiiigvpeejnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkedumgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=EAvtKdu2xXjGkeSU2J30LIKYMel3gMLXJ7rp7XGeIao=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156032; v=1;
 b=ZJvibAp/RP9cf3TbjTIQQpOXSD9rb/ppPXWSRc3YtELtSZMY6AjO6AkscSSNgPlqguJw6Bp4
 Xmc0sDhAPzS8Nsjy7sw+rrfjAajIWSp2bvxQ8UwZXsLnnjIBawDNGOeJNrqAWvGTzQgRPI31sH1
 K6APWlpripYgo3KztHzq/9ySVKUUN1NKoUOG1UxwW3RBAJTkmAc+mmT/hsH+51Gs6TXpw7av/IF
 1ODm5Gafsb1DXcuNKcEv58ate3KnNfnW+9PvB7r9SyGhJ8F3dvDrAbX3oHnuJkph2JZsGiaiOov
 AFK0vS+0NKA6cEvDVGf5Co1GlWVyAzSX38nsqDDySBAPQ==

Secure Launch won't initiate DRTM on S3 resume (the code for starting
DRTM is not part of Xen), so abort a request to perform S3 suspend to
not lose the state of DRTM PCRs.

Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/acpi/power.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 3196a33b19..81eb8f705a 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -357,6 +358,13 @@ int acpi_enter_sleep(const struct xenpf_enter_acpi_sleep *sleep)
            PAGE_SIZE - acpi_sinfo.vector_width / 8)) )
         return -EOPNOTSUPP;
 
+    /* Secure Launch won't initiate DRTM on S3 resume, so abort S3 suspend. */
+    if ( sleep->sleep_state == ACPI_STATE_S3 && slaunch_active )
+    {
+        printk(XENLOG_INFO "SLAUNCH: refusing switching into ACPI S3 state.\n");
+        return -EPERM;
+    }
+
     if ( sleep->flags & XENPF_ACPI_SLEEP_EXTENDED )
     {
         if ( !acpi_sinfo.sleep_control.address ||
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:12:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:12:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983350.1369742 (Exim 4.92)
	(envelope-from )
	id 1uEtAy-0007ze-P9; Tue, 13 May 2025 17:12:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983350.1369742; Tue, 13 May 2025 17:12:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEtAy-0007zV-MJ; Tue, 13 May 2025 17:12:20 +0000
Received: by outflank-mailman (input) for mailman id 983350;
 Tue, 13 May 2025 17:12:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEt5k-0003Mm-KV
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:06:56 +0000
Received: from 11.mo582.mail-out.ovh.net (11.mo582.mail-out.ovh.net
 [188.165.38.119]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ab8a2f5d-301c-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:06:54 +0200 (CEST)
Received: from director3.ghost.mail-out.ovh.net (unknown [10.108.2.12])
 by mo582.mail-out.ovh.net (Postfix) with ESMTP id 4ZxjZ61R8Kz1brL
 for ; Tue, 13 May 2025 17:06:54 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-2gpcv (unknown [10.111.182.17])
 by director3.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 2BD2C1FE87;
 Tue, 13 May 2025 17:06:52 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.113])
 by ghost-submission-5b5ff79f4f-2gpcv with ESMTPSA
 id 1iptLix8I2ieNAEA044U2Q
 (envelope-from ); Tue, 13 May 2025 17: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" 
X-Inumbo-ID: ab8a2f5d-301c-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-113S0078bba96bf-254c-4876-8416-b850069c454a,
                    0F27B6D195039ACFBDF5EC7F2AC12BEA7E98F15C) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v2 11/22] x86/tpm.c: support extending PCRs of TPM2.0
Date: Tue, 13 May 2025 20:05:48 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 8948089511957214364
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpedvhfehudekhfevieefffefvdefjeeggeekuefhgeehjeehgfeiieekjeeliefhffenucffohhmrghinhepuhhpuggrthgvpggtrdgurghtrgdpfhhinhhishhhpggtrdgurghtrgenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekuddrudejkedpfeejrdehledrudegvddruddufeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkedvmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=vbZBG6/p+HYIHnA6JUFYr41EnuLF4cyFkDoUUxgDG/o=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747156014; v=1;
 b=FIu7dLI4W1LZbILNxEVqcCVxsmFY/GCmIg0aHWR2m8CPULbgmLSkrqG5XJZ2RVL6yaWl1rC4
 AjCkW9MwM7asUflH9DwARbb0iuELe1xrg/gDSFMPNoVENmTbzgITiTfTwzqFJeskf09MWCLQslk
 useGRLkmX0qf3xlFFHTHyhUBhR4UwKReKTFUB1Lbd7Tf8RHqrbYpViiiofskTDi2C/5jjTA6Riz
 IgkTDZEebkBgV6zvMQDlxN32Wsl9TUVGdWkb2i3Y3iqoEf68fKDhtQdSL8JCKU4bTMb633lPIPC
 VjUg8B75j26b1dt1ir+4CZAWs5cEU1dW3NxDbqmhSJgZQ==

SHA1 and SHA256 are hard-coded here, but their support by the TPM is
checked.  Addition of event log for TPM2.0 will generalize the code
further.

Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/tpm.c | 464 +++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 452 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
index 7fb19ce4fa..ed49fe3ccf 100644
--- a/xen/arch/x86/tpm.c
+++ b/xen/arch/x86/tpm.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,15 @@ struct slr_table *slaunch_get_slrt(void)
  * other part of Xen.  Providing implementation of builtin functions in this
  * case is necessary if compiler chooses to not use an inline builtin.
  */
+void *(memset)(void *s, int c, size_t n)
+{
+    uint8_t *d = s;
+
+    while ( n-- )
+        *d++ = c;
+
+    return s;
+}
 void *(memcpy)(void *dest, const void *src, size_t n)
 {
     const uint8_t *s = src;
@@ -146,14 +156,15 @@ static inline bool is_tpm12(void)
             (tis_read32(TPM_STS_(0)) & TPM_FAMILY_MASK) == 0);
 }
 
-/****************************** TPM1.2 specific *******************************/
-#define TPM_ORD_Extend              0x00000014
-#define TPM_ORD_SHA1Start           0x000000A0
-#define TPM_ORD_SHA1Update          0x000000A1
-#define TPM_ORD_SHA1CompleteExtend  0x000000A3
+/****************************** TPM1.2 & TPM2.0 *******************************/
 
-#define TPM_TAG_RQU_COMMAND         0x00C1
-#define TPM_TAG_RSP_COMMAND         0x00C4
+/*
+ * TPM1.2 is required to support commands of up to 1101 bytes, vendors rarely
+ * go above that. Limit maximum size of block of data to be hashed to 1024.
+ *
+ * TPM2.0 should support hashing of at least 1024 bytes.
+ */
+#define MAX_HASH_BLOCK      1024
 
 /* All fields of following structs are big endian. */
 struct tpm_cmd_hdr {
@@ -168,6 +179,17 @@ struct tpm_rsp_hdr {
     uint32_t    returnCode;
 } __packed;
 
+/****************************** TPM1.2 specific *******************************/
+
+#define TPM_ORD_Extend              0x00000014
+#define TPM_ORD_SHA1Start           0x000000A0
+#define TPM_ORD_SHA1Update          0x000000A1
+#define TPM_ORD_SHA1CompleteExtend  0x000000A3
+
+#define TPM_TAG_RQU_COMMAND         0x00C1
+#define TPM_TAG_RSP_COMMAND         0x00C4
+
+/* All fields of following structs are big endian. */
 struct extend_cmd {
     struct tpm_cmd_hdr h;
     uint32_t pcrNum;
@@ -233,11 +255,6 @@ struct txt_ev_log_container_12 {
 };
 
 #ifdef __EARLY_SLAUNCH__
-/*
- * TPM1.2 is required to support commands of up to 1101 bytes, vendors rarely
- * go above that. Limit maximum size of block of data to be hashed to 1024.
- */
-#define MAX_HASH_BLOCK      1024
 #define CMD_RSP_BUF_SIZE    (sizeof(struct sha1_update_cmd) + MAX_HASH_BLOCK)
 
 union cmd_rsp {
@@ -393,6 +410,400 @@ static void *create_log_event12(struct txt_ev_log_container_12 *evt_log,
 
 /************************** end of TPM1.2 specific ****************************/
 
+/****************************** TPM2.0 specific *******************************/
+
+/*
+ * These constants are for TPM2.0 but don't have a distinct prefix to match
+ * names in the specification.
+ */
+
+#define TPM_HT_PCR   0x00
+
+#define TPM_RH_NULL  0x40000007
+#define TPM_RS_PW    0x40000009
+
+#define HR_SHIFT     24
+#define HR_PCR       (TPM_HT_PCR << HR_SHIFT)
+
+#define TPM_ST_NO_SESSIONS  0x8001
+#define TPM_ST_SESSIONS     0x8002
+
+#define TPM_ALG_SHA1        0x0004
+#define TPM_ALG_SHA256      0x000b
+#define TPM_ALG_NULL        0x0010
+
+#define TPM2_PCR_Extend                 0x00000182
+#define TPM2_PCR_HashSequenceStart      0x00000186
+#define TPM2_PCR_SequenceUpdate         0x0000015C
+#define TPM2_PCR_EventSequenceComplete  0x00000185
+
+#define PUT_BYTES(p, bytes, size)  do {  \
+        memcpy((p), (bytes), (size));    \
+        (p) += (size);                   \
+    } while ( 0 )
+
+#define PUT_16BIT(p, data) do {          \
+        *(uint16_t *)(p) = swap16(data); \
+        (p) += 2;                        \
+    } while ( 0 )
+
+/* All fields of following structs are big endian. */
+struct tpm2_session_header {
+    uint32_t handle;
+    uint16_t nonceSize;
+    uint8_t nonce[0];
+    uint8_t attrs;
+    uint16_t hmacSize;
+    uint8_t hmac[0];
+} __packed;
+
+struct tpm2_extend_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrHandle;
+    uint32_t sessionHdrSize;
+    struct tpm2_session_header pcrSession;
+    uint32_t hashCount;
+    uint8_t hashes[0];
+} __packed;
+
+struct tpm2_extend_rsp {
+    struct tpm_rsp_hdr h;
+} __packed;
+
+struct tpm2_sequence_start_cmd {
+    struct tpm_cmd_hdr h;
+    uint16_t hmacSize;
+    uint8_t hmac[0];
+    uint16_t hashAlg;
+} __packed;
+
+struct tpm2_sequence_start_rsp {
+    struct tpm_rsp_hdr h;
+    uint32_t sequenceHandle;
+} __packed;
+
+struct tpm2_sequence_update_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t sequenceHandle;
+    uint32_t sessionHdrSize;
+    struct tpm2_session_header session;
+    uint16_t dataSize;
+    uint8_t data[0];
+} __packed;
+
+struct tpm2_sequence_update_rsp {
+    struct tpm_rsp_hdr h;
+} __packed;
+
+struct tpm2_sequence_complete_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrHandle;
+    uint32_t sequenceHandle;
+    uint32_t sessionHdrSize;
+    struct tpm2_session_header pcrSession;
+    struct tpm2_session_header sequenceSession;
+    uint16_t dataSize;
+    uint8_t data[0];
+} __packed;
+
+struct tpm2_sequence_complete_rsp {
+    struct tpm_rsp_hdr h;
+    uint32_t paramSize;
+    uint32_t hashCount;
+    uint8_t hashes[0];
+    /*
+     * Each hash is represented as:
+     * struct {
+     *     uint16_t hashAlg;
+     *     uint8_t hash[size of hashAlg];
+     * };
+     */
+} __packed;
+
+/*
+ * These two structure are for convenience, they don't correspond to anything in
+ * any spec.
+ */
+struct tpm2_log_hash {
+    uint16_t alg;  /* TPM_ALG_* */
+    uint16_t size;
+    uint8_t *data; /* Non-owning reference to a buffer inside log entry. */
+};
+/* Should be more than enough for now and awhile in the future. */
+#define MAX_HASH_COUNT 8
+struct tpm2_log_hashes {
+    uint32_t count;
+    struct tpm2_log_hash hashes[MAX_HASH_COUNT];
+};
+
+#ifdef __EARLY_SLAUNCH__
+
+union tpm2_cmd_rsp {
+    uint8_t b[sizeof(struct tpm2_sequence_update_cmd) + MAX_HASH_BLOCK];
+    struct tpm_cmd_hdr c;
+    struct tpm_rsp_hdr r;
+    struct tpm2_sequence_start_cmd start_c;
+    struct tpm2_sequence_start_rsp start_r;
+    struct tpm2_sequence_update_cmd update_c;
+    struct tpm2_sequence_update_rsp update_r;
+    struct tpm2_sequence_complete_cmd finish_c;
+    struct tpm2_sequence_complete_rsp finish_r;
+};
+
+static uint32_t tpm2_hash_extend(unsigned loc, const uint8_t *buf,
+                                 unsigned size, unsigned pcr,
+                                 struct tpm2_log_hashes *log_hashes)
+{
+    uint32_t seq_handle;
+    unsigned max_bytes = MAX_HASH_BLOCK;
+
+    union tpm2_cmd_rsp cmd_rsp;
+    unsigned o_size;
+    unsigned i;
+    uint8_t *p;
+    uint32_t rc;
+
+    cmd_rsp.start_c = (struct tpm2_sequence_start_cmd) {
+        .h.tag = swap16(TPM_ST_NO_SESSIONS),
+        .h.paramSize = swap32(sizeof(cmd_rsp.start_c)),
+        .h.ordinal = swap32(TPM2_PCR_HashSequenceStart),
+        .hashAlg = swap16(TPM_ALG_NULL), /* Compute all supported hashes. */
+    };
+
+    request_locality(loc);
+
+    o_size = sizeof(cmd_rsp);
+    send_cmd(loc, cmd_rsp.b, swap32(cmd_rsp.c.paramSize), &o_size);
+
+    if ( cmd_rsp.r.tag == swap16(TPM_ST_NO_SESSIONS) &&
+         cmd_rsp.r.paramSize == swap32(10) )
+    {
+        rc = swap32(cmd_rsp.r.returnCode);
+        if ( rc != 0 )
+            goto error;
+    }
+
+    seq_handle = swap32(cmd_rsp.start_r.sequenceHandle);
+
+    while ( size > 64 )
+    {
+        if ( size < max_bytes )
+            max_bytes = size & ~(64 - 1);
+
+        cmd_rsp.update_c = (struct tpm2_sequence_update_cmd) {
+            .h.tag = swap16(TPM_ST_SESSIONS),
+            .h.paramSize = swap32(sizeof(cmd_rsp.update_c) + max_bytes),
+            .h.ordinal = swap32(TPM2_PCR_SequenceUpdate),
+            .sequenceHandle = swap32(seq_handle),
+            .sessionHdrSize = swap32(sizeof(struct tpm2_session_header)),
+            .session.handle = swap32(TPM_RS_PW),
+            .dataSize = swap16(max_bytes),
+        };
+
+        memcpy(cmd_rsp.update_c.data, buf, max_bytes);
+
+        o_size = sizeof(cmd_rsp);
+        send_cmd(loc, cmd_rsp.b, swap32(cmd_rsp.c.paramSize), &o_size);
+
+        if ( cmd_rsp.r.tag == swap16(TPM_ST_NO_SESSIONS) &&
+             cmd_rsp.r.paramSize == swap32(10) )
+        {
+            rc = swap32(cmd_rsp.r.returnCode);
+            if ( rc != 0 )
+                goto error;
+        }
+
+        size -= max_bytes;
+        buf += max_bytes;
+    }
+
+    cmd_rsp.finish_c = (struct tpm2_sequence_complete_cmd) {
+        .h.tag = swap16(TPM_ST_SESSIONS),
+        .h.paramSize = swap32(sizeof(cmd_rsp.finish_c) + size),
+        .h.ordinal = swap32(TPM2_PCR_EventSequenceComplete),
+        .pcrHandle = swap32(HR_PCR + pcr),
+        .sequenceHandle = swap32(seq_handle),
+        .sessionHdrSize = swap32(sizeof(struct tpm2_session_header)*2),
+        .pcrSession.handle = swap32(TPM_RS_PW),
+        .sequenceSession.handle = swap32(TPM_RS_PW),
+        .dataSize = swap16(size),
+    };
+
+    memcpy(cmd_rsp.finish_c.data, buf, size);
+
+    o_size = sizeof(cmd_rsp);
+    send_cmd(loc, cmd_rsp.b, swap32(cmd_rsp.c.paramSize), &o_size);
+
+    if ( cmd_rsp.r.tag == swap16(TPM_ST_NO_SESSIONS) &&
+         cmd_rsp.r.paramSize == swap32(10) )
+    {
+        rc = swap32(cmd_rsp.r.returnCode);
+        if ( rc != 0 )
+            goto error;
+    }
+
+    p = cmd_rsp.finish_r.hashes;
+    for ( i = 0; i < swap32(cmd_rsp.finish_r.hashCount); ++i )
+    {
+        unsigned j;
+        uint16_t hash_type;
+
+        hash_type = swap16(*(uint16_t *)p);
+        p += sizeof(uint16_t);
+
+        for ( j = 0; j < log_hashes->count; ++j )
+        {
+            struct tpm2_log_hash *hash = &log_hashes->hashes[j];
+            if ( hash->alg == hash_type )
+            {
+                memcpy(hash->data, p, hash->size);
+                p += hash->size;
+                break;
+            }
+        }
+
+        if ( j == log_hashes->count )
+            /* Can't continue parsing without knowing hash size. */
+            break;
+    }
+
+    rc = 0;
+
+error:
+    relinquish_locality(loc);
+    return rc;
+}
+
+#else
+
+union tpm2_cmd_rsp {
+    /* Enough space for multiple hashes. */
+    uint8_t b[sizeof(struct tpm2_extend_cmd) + 1024];
+    struct tpm_cmd_hdr c;
+    struct tpm_rsp_hdr r;
+    struct tpm2_extend_cmd extend_c;
+    struct tpm2_extend_rsp extend_r;
+};
+
+static uint32_t tpm20_pcr_extend(unsigned loc, uint32_t pcr_handle,
+                                 const struct tpm2_log_hashes *log_hashes)
+{
+    union tpm2_cmd_rsp cmd_rsp;
+    unsigned o_size;
+    unsigned i;
+    uint8_t *p;
+
+    cmd_rsp.extend_c = (struct tpm2_extend_cmd) {
+        .h.tag = swap16(TPM_ST_SESSIONS),
+        .h.ordinal = swap32(TPM2_PCR_Extend),
+        .pcrHandle = swap32(pcr_handle),
+        .sessionHdrSize = swap32(sizeof(struct tpm2_session_header)),
+        .pcrSession.handle = swap32(TPM_RS_PW),
+        .hashCount = swap32(log_hashes->count),
+    };
+
+    p = cmd_rsp.extend_c.hashes;
+    for ( i = 0; i < log_hashes->count; ++i )
+    {
+        const struct tpm2_log_hash *hash = &log_hashes->hashes[i];
+
+        if ( p + sizeof(uint16_t) + hash->size > &cmd_rsp.b[sizeof(cmd_rsp)] )
+        {
+            printk(XENLOG_ERR "Hit TPM message size implementation limit: %ld\n",
+                   sizeof(cmd_rsp));
+            return -1;
+        }
+
+        *(uint16_t *)p = swap16(hash->alg);
+        p += sizeof(uint16_t);
+
+        memcpy(p, hash->data, hash->size);
+        p += hash->size;
+    }
+
+    /* Fill in command size (size of the whole buffer). */
+    cmd_rsp.extend_c.h.paramSize = swap32(sizeof(cmd_rsp.extend_c) +
+                                          (p - cmd_rsp.extend_c.hashes)),
+
+    o_size = sizeof(cmd_rsp);
+    send_cmd(loc, cmd_rsp.b, swap32(cmd_rsp.c.paramSize), &o_size);
+
+    return swap32(cmd_rsp.r.returnCode);
+}
+
+static bool tpm_supports_hash(unsigned loc, const struct tpm2_log_hash *hash)
+{
+    uint32_t rc;
+    struct tpm2_log_hashes hashes = {
+        .count = 1,
+        .hashes[0] = *hash,
+    };
+
+    /*
+     * This is a valid way of checking hash support, using it to not implement
+     * TPM2_GetCapability().
+     */
+    rc = tpm20_pcr_extend(loc, /*pcr_handle=*/TPM_RH_NULL, &hashes);
+
+    return rc == 0;
+}
+
+static uint32_t tpm2_hash_extend(unsigned loc, const uint8_t *buf,
+                                 unsigned size, unsigned pcr,
+                                 const struct tpm2_log_hashes *log_hashes)
+{
+    uint32_t rc;
+    unsigned i;
+    struct tpm2_log_hashes supported_hashes = {0};
+
+    request_locality(loc);
+
+    for ( i = 0; i < log_hashes->count; ++i )
+    {
+        const struct tpm2_log_hash *hash = &log_hashes->hashes[i];
+        if ( !tpm_supports_hash(loc, hash) )
+        {
+            printk(XENLOG_WARNING "Skipped hash unsupported by TPM: %d\n",
+                   hash->alg);
+            continue;
+        }
+
+        if ( hash->alg == TPM_ALG_SHA1 )
+        {
+            sha1_hash(hash->data, buf, size);
+        }
+        else if ( hash->alg == TPM_ALG_SHA256 )
+        {
+            sha2_256_digest(hash->data, buf, size);
+        }
+        else
+        {
+            /* This is called "OneDigest" in TXT Software Development Guide. */
+            memset(hash->data, 0, size);
+            hash->data[0] = 1;
+        }
+
+        if ( supported_hashes.count == MAX_HASH_COUNT )
+        {
+            printk(XENLOG_ERR "Hit hash count implementation limit: %d\n",
+                   MAX_HASH_COUNT);
+            return -1;
+        }
+
+        supported_hashes.hashes[supported_hashes.count] = *hash;
+        ++supported_hashes.count;
+    }
+
+    rc = tpm20_pcr_extend(loc, HR_PCR + pcr, &supported_hashes);
+    relinquish_locality(loc);
+
+    return rc;
+}
+
+#endif /* __EARLY_SLAUNCH__ */
+
+/************************** end of TPM2.0 specific ****************************/
+
 void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
                      unsigned size, uint32_t type, const uint8_t *log_data,
                      unsigned log_data_size)
@@ -419,6 +830,35 @@ void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
         {
 #ifndef __EARLY_SLAUNCH__
             printk(XENLOG_ERR "Extending PCR%u failed\n", pcr);
+#endif
+        }
+    } else {
+        uint8_t sha1_digest[SHA1_DIGEST_SIZE];
+        uint8_t sha256_digest[SHA2_256_DIGEST_SIZE];
+        uint32_t rc;
+
+        struct tpm2_log_hashes log_hashes = {
+            .count = 2,
+            .hashes = {
+                {
+                    .alg = TPM_ALG_SHA1,
+                    .size = SHA1_DIGEST_SIZE,
+                    .data = sha1_digest,
+                },
+                {
+                    .alg = TPM_ALG_SHA256,
+                    .size = SHA2_256_DIGEST_SIZE,
+                    .data = sha256_digest,
+                },
+            },
+        };
+
+        rc = tpm2_hash_extend(loc, buf, size, pcr, &log_hashes);
+        if ( rc != 0 )
+        {
+#ifndef __EARLY_SLAUNCH__
+            printk(XENLOG_ERR "Extending PCR%u failed with TPM error: 0x%08x\n",
+                   pcr, rc);
 #endif
         }
     }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:17:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:17:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983384.1369753 (Exim 4.92)
	(envelope-from )
	id 1uEtGB-0000xO-Cu; Tue, 13 May 2025 17:17:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983384.1369753; Tue, 13 May 2025 17: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 1uEtGB-0000xH-9S; Tue, 13 May 2025 17:17:43 +0000
Received: by outflank-mailman (input) for mailman id 983384;
 Tue, 13 May 2025 17:17:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEtG9-0000xB-PT
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:17:41 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2c366bab-301e-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:17:39 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-442eb5d143eso9207585e9.0
 for ; Tue, 13 May 2025 10:17:39 -0700 (PDT)
Received: from localhost.localdomain (110.8.30.213.rev.vodafone.pt.
 [213.30.8.110]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442cd3b7e7fsm219095405e9.39.2025.05.13.10.17.38
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 13 May 2025 10:17: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" 
X-Inumbo-ID: 2c366bab-301e-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747156659; x=1747761459; 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;
        bh=92VKl5M8N6yTo/u89ILBeJrAILC8Bk1ppBFcXFhcPnA=;
        b=y8WXGc88plDzxeImPfmWsDGppio65vXCpRNa60+mtQZsP6Dmz/pR3Ss764fZNTVYPw
         vsZ4u6aCvjB4jIxL/7imbGMl8RY4RUeRuaNhUjyhMeGHYz2Ok4VmFET0x0YgXBZEQeaQ
         0nnkTnbg0AXwTJhBMRoz56SWnmHLroejL/ojVDlqsHoW4XYOY9s6U/N6j1u8MzdOgXB6
         kKflLmcQxNo6Ot+kl4OutfKnyRtzjkmLIcdB2OFmewtwwa2guRQcdLPaJxygLYl5BL9X
         xc++ga50GR+F4D1QNHtvbexQSuMhmapzWyXspG7n5raa+RmkLi7r/6+fHgTa+xgRseQe
         CpaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747156659; x=1747761459;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=92VKl5M8N6yTo/u89ILBeJrAILC8Bk1ppBFcXFhcPnA=;
        b=PB3d5JSa7YvNZsjaXwnkLDOw73CaeM8fPoJV6h149E25mffEZ2clumg/HkRsrOJmeB
         Mu8cIpex+uM1JqpVM+utJmgsIrfhhodt4cfZ1paFNc6LdGrh0MB4DVZw43VhsEl5OwyG
         NAoEU51yjBTVRS1UleerelWIkxMhGcPzuykR7soO5fQCoQItpGlW++wg0/pz0Z+pPN2o
         4lVZwpYhmLKQiQsGsdGRe4bc97G81tQMonbq+x3zsifEEqf/8zkGC9wSxCS7PUIejrCQ
         p9+Xir1JB0ltM2ahhafF6toWUKauCsaUZCtFNlv6A2ytorRxS/aAIzpWAtg5Nf3BrsCb
         pMyw==
X-Forwarded-Encrypted: i=1; AJvYcCXtTdvfjFFf7OucZq+ZDUUQDvTXaY09ym6uxHSHcsH2Pj5lp85HGZKJHgAW/Zk17DbKhYckVImi+lY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx20EyaOzCMT9k5XphV43kqvo8xAmdAl/h5FeEjS6sWI+6l4uhM
	X2fcoV1EWz8KRhaLpXBSqIiORhKJzE0wkJSo+BDJ0tqdkNWGfl490+++wGsbM7k=
X-Gm-Gg: ASbGncuxs+FUKbN7aojoUlJsimugkoo65m0MfJyJBRwwya6MSdHrdkWSD3qTlEc3lQ9
	P4sSsUBFnbSR4s/jzz9i+rePXp/4RjE5cP9MF7nuSLY4MbQrJsnPxslytqu7XkHfQgRgfruyKlw
	iiHWftJcVgeR+aAgnNTM2J8uTzDrKDHRr1oo98VWLJh0njJPueMo9s/k7fXKzZjZnjTFAncN+gE
	2CnQGnvCEvWsll7MFyK6T94w+Uy+2A6l5smGoEowuRtUfbO94stjzwVHGqUFRhhHyyP5qHJd5LM
	zsDVFdDrpz7acUHYQO/l6sDfuSq4BTVmCSGo1Z3ktotM/oos6fTgySwjggziwcrGRqQQwdxH+6x
	tGa1Zr9oWUKlRzikl2hP4+UuIBA3U
X-Google-Smtp-Source: AGHT+IGED3JpQ5xEpvL/Oky0PnXrRKLiZd+XWUI48ZshRzl+T/zGt/gx+JUq/R41rmN+QUIOmWMLfg==
X-Received: by 2002:a05:600c:4e0e:b0:43c:fdbe:4398 with SMTP id 5b1f17b1804b1-442f20bae9amr1785765e9.6.1747156659284;
        Tue, 13 May 2025 10:17:39 -0700 (PDT)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Richard Henderson ,
	xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	David Woodhouse ,
	"Edgar E. Iglesias" ,
	qemu-arm@nongnu.org,
	Stefano Stabellini ,
	Paul Durrant ,
	Pierrick Bouvier ,
	Peter Maydell ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
Subject: [PATCH] hw/xen/arch_hvm: Unify x86 and ARM variants
Date: Tue, 13 May 2025 18:17:37 +0100
Message-ID: <20250513171737.74386-1-philmd@linaro.org>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

As each target declares the same prototypes, we can
use a single header, removing the TARGET_XXX uses.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/arm/xen_arch_hvm.h  |  9 ---------
 include/hw/i386/xen_arch_hvm.h | 11 -----------
 include/hw/xen/arch_hvm.h      | 14 ++++++++++----
 hw/arm/xen-pvh.c               |  1 -
 4 files changed, 10 insertions(+), 25 deletions(-)
 delete mode 100644 include/hw/arm/xen_arch_hvm.h
 delete mode 100644 include/hw/i386/xen_arch_hvm.h

diff --git a/include/hw/arm/xen_arch_hvm.h b/include/hw/arm/xen_arch_hvm.h
deleted file mode 100644
index 8fd645e7232..00000000000
--- a/include/hw/arm/xen_arch_hvm.h
+++ /dev/null
@@ -1,9 +0,0 @@
-#ifndef HW_XEN_ARCH_ARM_HVM_H
-#define HW_XEN_ARCH_ARM_HVM_H
-
-#include 
-void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
-void arch_xen_set_memory(XenIOState *state,
-                         MemoryRegionSection *section,
-                         bool add);
-#endif
diff --git a/include/hw/i386/xen_arch_hvm.h b/include/hw/i386/xen_arch_hvm.h
deleted file mode 100644
index 1000f8f5433..00000000000
--- a/include/hw/i386/xen_arch_hvm.h
+++ /dev/null
@@ -1,11 +0,0 @@
-#ifndef HW_XEN_ARCH_I386_HVM_H
-#define HW_XEN_ARCH_I386_HVM_H
-
-#include 
-#include "hw/xen/xen-hvm-common.h"
-
-void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
-void arch_xen_set_memory(XenIOState *state,
-                         MemoryRegionSection *section,
-                         bool add);
-#endif
diff --git a/include/hw/xen/arch_hvm.h b/include/hw/xen/arch_hvm.h
index df39c819c8f..8bacaa4ec41 100644
--- a/include/hw/xen/arch_hvm.h
+++ b/include/hw/xen/arch_hvm.h
@@ -1,5 +1,11 @@
-#if defined(TARGET_I386) || defined(TARGET_X86_64)
-#include "hw/i386/xen_arch_hvm.h"
-#elif defined(TARGET_ARM) || defined(TARGET_AARCH64)
-#include "hw/arm/xen_arch_hvm.h"
+#ifndef HW_XEN_ARCH_HVM_H
+#define HW_XEN_ARCH_HVM_H
+
+#include 
+#include "hw/xen/xen-hvm-common.h"
+
+void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
+void arch_xen_set_memory(XenIOState *state,
+                         MemoryRegionSection *section,
+                         bool add);
 #endif
diff --git a/hw/arm/xen-pvh.c b/hw/arm/xen-pvh.c
index 4b26bcff7a5..1a9eeb01c8e 100644
--- a/hw/arm/xen-pvh.c
+++ b/hw/arm/xen-pvh.c
@@ -10,7 +10,6 @@
 #include "hw/boards.h"
 #include "system/system.h"
 #include "hw/xen/xen-pvh-common.h"
-#include "hw/xen/arch_hvm.h"
 
 #define TYPE_XEN_ARM  MACHINE_TYPE_NAME("xenpvh")
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:18:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:18:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983393.1369763 (Exim 4.92)
	(envelope-from )
	id 1uEtGl-0001UO-Oo; Tue, 13 May 2025 17:18:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983393.1369763; Tue, 13 May 2025 17: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 1uEtGl-0001UH-LA; Tue, 13 May 2025 17:18:19 +0000
Received: by outflank-mailman (input) for mailman id 983393;
 Tue, 13 May 2025 17:18:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEtGk-0001TD-Sa
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:18:19 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2415::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41b7bf71-301e-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 19:18:16 +0200 (CEST)
Received: from BL6PEPF00013E11.NAMP222.PROD.OUTLOOK.COM
 (2603:10b6:22e:400:0:1001:0:17) by DS7PR12MB8275.namprd12.prod.outlook.com
 (2603:10b6:8:ec::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.30; Tue, 13 May
 2025 17:18:13 +0000
Received: from BN2PEPF0000449E.namprd02.prod.outlook.com
 (2a01:111:f403:c803::9) by BL6PEPF00013E11.outlook.office365.com
 (2603:1036:903:4::4) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Tue,
 13 May 2025 17:18:12 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF0000449E.mail.protection.outlook.com (10.167.243.149) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Tue, 13 May 2025 17:18:12 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 13 May
 2025 12:18:12 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 13 May
 2025 12:18:11 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 13 May 2025 12:18: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" 
X-Inumbo-ID: 41b7bf71-301e-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GZE4kvsiteU1uYoprTkkazu6LLlP8GuJYQBg+YhVz/i8ZqY9gt69AqY5W7iQfrbkgLv5Og9qF2RU5NTnDHvckXu2w5R1bXCNBFeUy5hoaIXCli0Xcco7JthQDX7oblWLwWsnhix5qBFoWBE3EXbitJeTtr6VNKZImtH9X1APsT3UMbB4H87jmcjWkn1ifOmutySHK02Y6oGflPttoN04cmeDbXb/RkvlMDsBvL0gjZ8x3TqpKWqCMZI3ADlTEf8nInaFMaOrUIfg+U2Mwubd2cvy3X2V98NhQ6crIspIIZXTkNLmCgEX932MtRMikGx0JipNAf0Tc5+1+dbpFpAfHg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QtCYZnC/wIbWlCUdzmR/f7W11fazC+u7cNrdBzyIjWg=;
 b=FWE0x4E/LT8r6hPr6r30PJiquESS5G7bmI4cslgCXq3pS+YsAsON9Sh3Q76FJT0e9jX2zviUgwALq1iCpIt5rYTIqgwMEqeGtWO1Pldky4XnwKqeV2H3X7MHe/zxNhbCHPN9lwB7YTFYOiqv3VIEO+fr1GLkbV5Wa6YfZEmeap5AYrFoftea1F+cSKR/5qKqFLTooFVvkMPottNDIxKkxKCNoNUJXEiydEu4Pv5Ybjd4od9UYGHsQbKhVE5q+fhIn/4+CQ9Q2qXqhZtjSUmmMxOIt9hl6t025wN0iEgnv933jGxTHlyQyI/RmdtNOw6hvauT66B51QaFAtQWtof4Gg==
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=QtCYZnC/wIbWlCUdzmR/f7W11fazC+u7cNrdBzyIjWg=;
 b=xztvNNnyovRm741n64ks1KQXbOptk8CWDeKyMhNJt2RdT1taCvchYjgU1DUFip7amaGP0wtZXGkrvbMks+Ek0W5ywysJMQjGSSdVeL6B44AKNgspC5taKWl5zL0r8ftEAbL+aTk/tK2OZkDQnpHxpAmNucftKifxGYjnmcERlCE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation __init
Date: Tue, 13 May 2025 13:18:02 -0400
Message-ID: <20250513171810.668370-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF0000449E:EE_|DS7PR12MB8275:EE_
X-MS-Office365-Filtering-Correlation-Id: c602e965-903d-49e1-40e0-08dd92422405
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?cAuuOLwl2LGHZzXmbH7Yp/MQ0PATvgWJ/pYaO8D8AfB4k2e/tRoGar2rFqO9?=
 =?us-ascii?Q?Nj5rvVg8tXSd2KG/75bQ/J6RXHGVBJBqsb3Q2ftRVWhlM1QpzQNkfK1uPFMJ?=
 =?us-ascii?Q?01rBIgTHA5/cKRaGeozx2mIFpXzhMXfirqj26yZugzS94iX3YJUCWfas4G1W?=
 =?us-ascii?Q?fZYhzDupUg/sfHcYLE6JHStRKv+ot0+Ez9wDhmiHfKyjtlouE/vDRKOmWmAK?=
 =?us-ascii?Q?t0tqafSptiz2gT8xNmK1xdhnC11m5kZSoh2WzDvq1jJa835zEVZHTGR6Zvca?=
 =?us-ascii?Q?4AthpYRsfMliY1R0FBaU2vaFogXZxz/hVQe8JKEcVA6hkUp22TgDFVVId7Uj?=
 =?us-ascii?Q?w5UWTYH4WT47RqaI2OxzFWAipTVE8lax/LpFGNfF+hgIKJmjubgs1WFNAMRB?=
 =?us-ascii?Q?YldWf3ASs0SidEvvrcii4byB5PJu6WI43yc8iNjULp6lKcUtM9bvdTOP5J5L?=
 =?us-ascii?Q?Sm4z1hFCYi0Q1pGVblOXXgQGbLN1NX+iVzNH23/W8b59jN59pk9wCAb4QD+5?=
 =?us-ascii?Q?zuP7E4SFQUSC5iVUq8TDV2xHZSlzo4KLHGhUTuG/j8dRl9f+OSamUPfjSOVA?=
 =?us-ascii?Q?KxRzrj4g4yWgOPzo8I4i49PeRr2UBafOg0Tc10HWFf295SYVK+u5m2r0dfyy?=
 =?us-ascii?Q?kJ9aWb5ajOKO2sDfn6It4rUXsIqSzozXEJ/EyqyuL6NLsE4bQQP98ibnaHhO?=
 =?us-ascii?Q?N2HAW1es6zPs4LS9ikWF5swEBKPr/IrtuvUw80mg134Atgcnpk5PuMhlXg1F?=
 =?us-ascii?Q?Kshn7/XFpYhuRrzFG2hnuNlTzxUgsYcEFm7NXDz6gjMxznvYF82sV8MbrfWA?=
 =?us-ascii?Q?LhLlHZLIfMsERCMI4li5I0TuuA6pqndBOQPA0OTKXOladYoF+CWiQZLvlNmw?=
 =?us-ascii?Q?uie3ZaiFiXQ36TSqHw5LOEQAYUjIozJFjy/Vk2HjRbi4gB0CROm+0D9ssFEf?=
 =?us-ascii?Q?QXFWcWdJqcU4qb7hSY9hbX06kj3vwuHh+aTmLc4pc+riNbWT2VMoQW3mSFWI?=
 =?us-ascii?Q?cArZnZBgEoNJ1Qpuf+LKi1CjnjllX8mWULF95aE42eF9T9/cYeV/YSV4Rh8G?=
 =?us-ascii?Q?WOKfOO6yjuiOSbNwe24ZGv3IHp8n9oMalyre0pKijRJzmhpbiMN/7elolsKP?=
 =?us-ascii?Q?Axuec0hL+dT07XqbEwaYxq1QMkbLhb+RgRzvTmKnSFn0kTUmaP2daIhZZ8nW?=
 =?us-ascii?Q?XEFE/DdfjwwMGA4uAcBBUVGi5VmPyFVu1J79Nz04y64UobP6ABd/yzK/qOYM?=
 =?us-ascii?Q?iF8GY845QjX6nHhi48VXW1ziLAsfpi1DeDmx/QPIZy6url6Xl8htMyY61vNx?=
 =?us-ascii?Q?R6OSI1HQKJwf7/P9lBAnNm04LpIOguOUKYWUIicqOe0GwEm++lF751a0Wok1?=
 =?us-ascii?Q?AqCNXyRZwKPItyDC7Uf9F47EvICS1FlW9hugWHptG4Ql1HXgFIrHVUFjL9z4?=
 =?us-ascii?Q?VKDO1vkyN1BznCvuD3xvwFc5imva83zEjSkwNV91scGAYyhP7eaBLGOxMVkj?=
 =?us-ascii?Q?ZhTM6Ruqb05Fco+3J33rk9Z43xupslg5hQAc?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2025 17:18:12.5879
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c602e965-903d-49e1-40e0-08dd92422405
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF0000449E.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB8275

All functions in dom0less-build.c should be __init.

Fixes: 2705f1adb9df ("xen: introduce Kconfig ARCH_PAGING_MEMPOOL")
Signed-off-by: Stewart Hildebrand 
---
 xen/common/device-tree/dom0less-build.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 2c56f13771ab..39cb2cd5c70e 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -730,8 +730,8 @@ static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem,
     return rc;
 }
 #else /* !CONFIG_ARCH_PAGING_MEMPOOL */
-static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
-                                            const struct dt_device_node *node)
+static inline int __init domain_p2m_set_allocation(
+    struct domain *d, uint64_t mem, const struct dt_device_node *node)
 {
     return 0;
 }

base-commit: 5873740e41acb8593f92623ddd03caebda2718f6
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 17:18:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 17:18:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983394.1369773 (Exim 4.92)
	(envelope-from )
	id 1uEtGq-0001jv-05; Tue, 13 May 2025 17:18:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983394.1369773; Tue, 13 May 2025 17:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEtGp-0001jo-TJ; Tue, 13 May 2025 17:18:23 +0000
Received: by outflank-mailman (input) for mailman id 983394;
 Tue, 13 May 2025 17:18:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEtGp-0000x3-8Q
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 17:18:23 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20611.outbound.protection.outlook.com
 [2a01:111:f403:2406::611])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 44f16e1d-301e-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 19:18:22 +0200 (CEST)
Received: from BL6PEPF00013E02.NAMP222.PROD.OUTLOOK.COM
 (2603:10b6:22e:400:0:1001:0:18) by SA1PR12MB8721.namprd12.prod.outlook.com
 (2603:10b6:806:38d::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.29; Tue, 13 May
 2025 17:18:18 +0000
Received: from BN2PEPF0000449E.namprd02.prod.outlook.com
 (2a01:111:f403:c803::9) by BL6PEPF00013E02.outlook.office365.com
 (2603:1036:903:4::4) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.20 via Frontend Transport; Tue,
 13 May 2025 17:18:18 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF0000449E.mail.protection.outlook.com (10.167.243.149) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Tue, 13 May 2025 17:18:18 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 13 May
 2025 12:18:17 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 13 May 2025 12:18:17 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 44f16e1d-301e-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=O0vvh4ebZPKLSYjrwQElVea06AG2pPtXt1fLQD8K57rVGKy6B7azKrhRVSRxJsl1nfkpuERkGNEYs7o3W9L7Qqogeu+GMx8arsN7w0Gr03PK/xPCIe7RSgZPrKy3GiCyzdVt9ocusvmkY9PWiCAQ18K4jYV4/iPpVk5+ScbEdhhqtt5LS51dSJgc093x7CySTGu7ys0lXqGyqJhdwo/s3deoP+TAp/1wl0a1yysX5EbYGHfZDsV4Zadl15ny0umJrfBzrPN7AyPlRtEkMD+nIodiFg8jOUPfK08RZmrEnR8o7p23MvzmvEHJ9yPfUt0G/SRYl1Fu15NATV+A+LwBIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5V85z1ViJnkkgRl4AbkpCsiTRJxEws892rNh16MnFJo=;
 b=ZOku2oYCiN7riseQjJMWrHryRbimcIAwY3NND4UIJtRt+ZjbQIElpDFG26fExCruS3DY4qXom37PdTPEci3ESsqbwz+3b5ce0zgJnxmkGrJNTW3dPLYA5+g5e2trwdBFrfrGrZGbU/wX+nM36snVTC13CWj4obDnrEbByFxa/HpK6OajmAGiXuWYbDiNFSx4jfTMYzbuFZmqB7nRFj3fiB6rW63/q51+5IDgww6urkeeqnX7Ge+VdBempRmc3vR7TRvPdJo0dCwXVuIwWa2LFziCYB2RzM5v/OeE8DyzZrzajl8lixUrWbSX0gdtt+k/15j/ZtMEmBQcWA+DhdUqwQ==
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=5V85z1ViJnkkgRl4AbkpCsiTRJxEws892rNh16MnFJo=;
 b=McTLE7m1+eUakU3FlektKaiRjiypf4eQ2BNJz7kxleUzuDTpBSWuted3uCxK7y5f/wI+oL8hTn1qJHGGrHATtUwvkn6Hs3YNcDPBUYPrexYEzBi92m4YOomaZ19cKBSuxio8jXZV7rrSaJB/kRyEhQ+QJrcSU2ufngDBwEYvlpk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: [PATCH 2/2] xen: enforce __init in common/device-tree/*-build.c
Date: Tue, 13 May 2025 13:18:03 -0400
Message-ID: <20250513171810.668370-2-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250513171810.668370-1-stewart.hildebrand@amd.com>
References: <20250513171810.668370-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF0000449E:EE_|SA1PR12MB8721:EE_
X-MS-Office365-Filtering-Correlation-Id: d0c23c5f-4757-495b-9b45-08dd92422771
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?OKlMpFbo3mpWqjgMGQ2ASqXURZpfhRFA34im/qmfJstxbvZsmViZ9jXe9ujm?=
 =?us-ascii?Q?Jw9cP7M6zCyevrrK1VqFVfKdak02Y8z0ZvKfwjvYpbueqKOMLu99ldnYxq+C?=
 =?us-ascii?Q?zP9CF32VQ6D9AzOBKtEyo7Z5VaW//Ab6IRZqm7OURqElb0mOJjPJIbx9AhNc?=
 =?us-ascii?Q?txA0aybc9beVSigcKGGNpQkCQ0JqaVw6tEtB9bRBae1n8hOgThB8F+0Is2M0?=
 =?us-ascii?Q?u1d0t5uPjg7w+yHg0o7oXw2qUkGL0Cds6A2s1u5irOUCn6VjtfFxgEmmgYA1?=
 =?us-ascii?Q?0Pz6nVXlZhdNnAtXhlGeWtZDxnL0iSruxz2cEORxeP4+B8edRKVg8jYM4z9r?=
 =?us-ascii?Q?Nch5RktyqSXnXwDcqhPZRh1oaSrAmIX5r2bWqJ9FDa4ChqslDQxjpLhHCT5Q?=
 =?us-ascii?Q?FDC1R6rMQD/W7HNM+j7zmrxp6wxWoD17cC4dsvsSzqfn8YJb3EXOnxzfZ6ho?=
 =?us-ascii?Q?iaevApvP4K2hG7+8IxkM8CQwU1MxAAlQFsOfzUxhBWaSbUA84Q0do8YYDaQg?=
 =?us-ascii?Q?kD7a3Gvz9QFBLalXoRSOEboXYRrjMjcTx4PKGZOeORj3+l4otEErIzgp5nLI?=
 =?us-ascii?Q?OGqVH5p9Hf3tHOXdtgFnF4gdaKgJUbZE6tWP1+1L+jtX/f897VEypPfGDgfM?=
 =?us-ascii?Q?cRM+6U9DGkWFpn4NKuPwicz4Ysh91L9s41b5H+WF5VeaayYukzcAXJj56pTH?=
 =?us-ascii?Q?8idip8P+ccFA92JvwR7v0PF93RDVwVHFI8L3K3RkDnZYPxxTUgTtmfeBH5Lc?=
 =?us-ascii?Q?dKB+dIXzJtZ7SFLvvhbPL35Oov0upMXcvHnCN0rEYefGPAXviBUGnjw7AVq4?=
 =?us-ascii?Q?N7Cex9E0gu8rqOvhKyNLcZOkHv1zHL0cKBmStsBgiyLGyqz88P5pGbzeoEc/?=
 =?us-ascii?Q?g2tR4v0BtHXxLOkU8nKMVPhxHWyw0DGojeFrsAk6VVAs+hTdMkuxiMnehHPf?=
 =?us-ascii?Q?u9gW/3X3TdeaZZORBW2WH7fpx9j8UCCf9Kwp3WzTeHf0hx0k/phQd+evvQ8J?=
 =?us-ascii?Q?na2lAHzlPHStzV61/foMScOye/z6UhKWVL+v3TtOron8Ojt3cgoul3v8PzRR?=
 =?us-ascii?Q?8pI7kz2+8ag9WEpLJ8LAcdul0kMxAyY9q9AxMv3adcyzYKX0GAhWthYjFj/f?=
 =?us-ascii?Q?ZmDW8BiInR4n7PgeLa5t0QYI5wqB2dyCPUZnBucARugV+uxBxNLVX8iuCiyB?=
 =?us-ascii?Q?5l+piU8bDjSpjN15uxzWjnECJqnaay1cBVtEeMIMS6U5Xf95YKQ238VeBgl3?=
 =?us-ascii?Q?P+aSgXzElCsMocddv3AklLkK8MVqTeUFfYI/Pujoo0uX3Ndhe2zPy7jaGdoT?=
 =?us-ascii?Q?9SRtp/5kedZ3HhNV/6byUa2TQxtw1KyJZUoOsgEPSdQcreh3n+WLjOp001gV?=
 =?us-ascii?Q?2j6sbFhWKfupDPkTYDOvyKf5P3nGBeo4ZHtDXtLEajbJ0rBySjUdBqDIPxJ4?=
 =?us-ascii?Q?gA3/n2bBHsoZEDUSQ6kzbzJey/03wxqHJbzXM8VshmWe3HxXfpATulH5YMB8?=
 =?us-ascii?Q?1m3j7//WioIDoiDdr7hkKQYUr2Qn7j5IKM/7?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2025 17:18:18.3311
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d0c23c5f-4757-495b-9b45-08dd92422771
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF0000449E.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8721

Code in domain-build.c and dom0less-build.c was migrated from init-only
files. Thus, they contain only __init functions. Enforce this at build
time.

Fixes: ad03faa942b9 ("xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common")
Fixes: d07b7369aa65 ("xen/common: dom0less: introduce common domain-build.c")
Signed-off-by: Stewart Hildebrand 
---
 xen/common/device-tree/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 831b91399b74..ff54a8ef2bee 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,8 +1,8 @@
 obj-y += bootfdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
-obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.o
-obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
+obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
+obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 19:20:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 19:20:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983503.1369790 (Exim 4.92)
	(envelope-from )
	id 1uEvAo-00073C-PR; Tue, 13 May 2025 19:20:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983503.1369790; Tue, 13 May 2025 19: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 1uEvAo-000735-Mo; Tue, 13 May 2025 19:20:18 +0000
Received: by outflank-mailman (input) for mailman id 983503;
 Tue, 13 May 2025 19:20:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEvAn-00072z-8E
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 19:20:17 +0000
Received: from fout-a4-smtp.messagingengine.com
 (fout-a4-smtp.messagingengine.com [103.168.172.147])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4a44d004-302f-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 21:20:14 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfout.phl.internal (Postfix) with ESMTP id 0A49913801B5;
 Tue, 13 May 2025 15:20:11 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Tue, 13 May 2025 15:20:11 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 13 May 2025 15:20:10 -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" 
X-Inumbo-ID: 4a44d004-302f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:message-id:mime-version:reply-to
	:subject:subject:to:to; s=fm3; t=1747164011; x=1747250411; bh=iD
	qe/w7TN+oKsfF9smG7KFAElDed+5wEvRF9T0RhlQU=; b=tkRZTvJznwKWUKZgrr
	Pujk1dJjVnfVGLp57d38hhNxNfv/T/YLNqtR9rYkKmt5GviluASTMP6SwctgDwSO
	pBzdXOJrxt2wmze49Jke5LmxQw6WWDKKGSHZsX9Md8XupONsAVXJyk7dC8kLvdMN
	ji6U1sDyIll186tPymuhE1AWbYgM2r5EG2bU4auJlLrDvyHxZ9rgHxOu6WJ/rLun
	Uo7dCsfDh3IGLkVJgY6NjxfON6XTdsGHi8vX6zGLKAmAFRPumtLWz0nkGE9NT0QU
	2LzLXPYRI92cGpVfyzXDBNu5xnjt20zauL7iwyDVg3RJ0qi6BwZG9s2EmTIwr1QP
	L7DQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:message-id
	:mime-version:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1747164011; x=
	1747250411; bh=iDqe/w7TN+oKsfF9smG7KFAElDed+5wEvRF9T0RhlQU=; b=b
	FeZE0hBHtcH9eb4b6TJwso+zH8lvR/WWZwmipwECyWhPen594TsgXYaMxxn0ZtL5
	koVn/nsd1x/ZY6Ygtk0RkZZyb8N7CM8BTXYHDRNf8ZmJkFpilGFMGTOS0pMLbESH
	Ad2GpKEmuhQTco9Oa9xho+G1aBNCDRwMK6ctJ3WbNsqWvZJH9gHfNHbvwbOx0kpd
	+TLyV/O+G8ld8rPnWDevUuXszCqospfwEiPKZr+2JxGmsM56VDdZxR2FSAljCMeL
	XvIyjoUGuWaEuND0vDWRh0EmZj/TUH4GIGfj0Qk7W7hZLoHal92aILt3Ajh3PWgM
	IJ0r+jcYgEBAcudrgV28A==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdegleefucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkgggtugesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhephfetuefhiefgtddtlefggffggeevhedtvdefffeugfeiieeiheefte
    efgefggeejnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhi
    iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhish
    hisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeefpdhmohguvgep
    shhmthhpohhuthdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnph
    hrohhjvggtthdrohhrghdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidr
    tghomhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtoh
    hm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 13 May 2025 21:20:07 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Cc: Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Andrew Cooper 
Subject: Assertion 'desc->arch.creator_domid == DOMID_INVALID' failed
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="/BvfcpyxYdgDCW1s"
Content-Disposition: inline


--/BvfcpyxYdgDCW1s
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 13 May 2025 21:20:07 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Cc: Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Andrew Cooper 
Subject: Assertion 'desc->arch.creator_domid == DOMID_INVALID' failed

Hi,

When debugging CI job on Linus' master branch, I added "console=3Dvga vga=
=3D,keep" and got PV dom0 crash Xen with:

(XEN) [   40.870435] Assertion 'desc->arch.creator_domid =3D=3D DOMID_INVAL=
ID' failed at arch/x86/irq.c:294
(XEN) [   40.886925] ----[ Xen-4.21-unstable  x86_64  debug=3Dy ubsan=3Dy  =
Not tainted ]----
(XEN) [   40.903356] CPU:    10
(XEN) [   40.919824] RIP:    e008:[] create_irq+0x272/0x3=
39
(XEN) [   40.936267] RFLAGS: 0000000000010297   CONTEXT: hypervisor (d0v13)
(XEN) [   40.952709] rax: 00000000fffffff4   rbx: ffff830498007c00   rcx: 0=
000000000001899
(XEN) [   40.969147] rdx: ffff830498007c5e   rsi: 0000000000000002   rdi: f=
fff83049830e398
(XEN) [   40.985892] rbp: ffff830498307d18   rsp: ffff830498307ce8   r8:  0=
000000000000000
(XEN) [   41.003093] r9:  0000000000000000   r10: 0000000000000000   r11: 0=
000000000000000
(XEN) [   41.020279] r12: 00000000fffffff4   r13: 000000000000007c   r14: f=
fffffffffffffff
(XEN) [   41.037489] r15: 000000000000007c   cr0: 0000000080050033   cr4: 0=
000000000b526e0
(XEN) [   41.054699] cr3: 0000000492c34000   cr2: ffff8881001603f0
(XEN) [   41.071904] fsb: 0000000000000000   gsb: ffff8882365ac000   gss: 0=
000000000000000
(XEN) [   41.089116] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010  =
 cs: e008
(XEN) [   41.106320] Xen code around  (create_irq+0x272/0=
x339):
(XEN) [   41.123521]  3f d9 ff e9 cc fe ff ff <0f> 0b 48 8d 3d 5a a0 29 00 =
e8 f4 3d d9 ff c6 43
(XEN) [   41.140739] Xen stack trace from rsp=3Dffff830498307ce8:
(XEN) [   41.157931]    000000ff00000001 ffff830497faa000 ffff830498307e00 =
00000000ffffffff
(XEN) [   41.175132]    0000000000010000 ffff830497faa160 ffff830498307d70 =
ffff82d0405a6f85
(XEN) [   41.192351]    00000000000002a0 ffff830498307e24 0000000000000200 =
00000000ffffffff
(XEN) [   41.209551]    ffff830497faa000 0000000000000000 ffff830497faa168 =
0000000000010000
(XEN) [   41.226753]    ffff830497faa160 ffff830498307de0 ffff82d0405c9ea6 =
5f24a0ddbbeda194
(XEN) [   41.244062]    ffff830498307e10 0000000000000000 0000000000000001 =
ffff830498307e00
(XEN) [   41.261387]    ffff830498307e24 ffff830498307e20 ffff830497faa000 =
ffff830498307ef8
(XEN) [   41.278730]    ffff830497faa000 ffff830497f5a000 ffffc9004002ba78 =
ffff830498307e68
(XEN) [   41.296052]    ffff82d0405cbd4f ffff82d04053fc3e ffffc9004002ba78 =
00000000000000a0
(XEN) [   41.313381]    00a0fb0000000001 0000000000000000 0000000000007ff0 =
ffffffffffffffff
(XEN) [   41.330708]    000000a000000000 0000000000000000 0000000000000000 =
ffff830498307ef8
(XEN) [   41.348026]    ffff830497f5a000 0000000000000021 0000000000000000 =
ffffc9004002ba78
(XEN) [   41.365357]    ffff830498307ee8 ffff82d0405427db ffff8881d6961b40 =
0000000000000001
(XEN) [   41.382680]    000000a000000000 000000000000000d 0000000000000000 =
ffff830498307ee8
(XEN) [   41.400003]    ffff82d0405e7bc2 ffff830497f5a000 0000000000000000 =
ffff830497f5a000
(XEN) [   41.417343]    0000000000000000 0000000000000000 ffff830498307fff =
0000000000000000
(XEN) [   41.434674]    00007cfb67cf80e7 ffff82d0402012d3 ffff8881d6961b40 =
ffff888100ef30c0
(XEN) [   41.452010]    0000000000000001 0000000000000005 0000000000000000 =
ffff888100ef3000
(XEN) [   41.469342]    0000000000000202 0000000000000001 0000000000007ff0 =
ffff8881d6961b40
(XEN) [   41.486681]    0000000000000021 ffffffff8229d355 000000a000000000 =
ffffc9004002ba78
(XEN) [   41.504015] Xen call trace:
(XEN) [   41.521314]    [] R create_irq+0x272/0x339
(XEN) [   41.538636]    [] F allocate_and_map_msi_pirq+0x=
51/0x5ec
(XEN) [   41.555960]    [] F physdev_map_pirq+0xbf6/0xd30
(XEN) [   41.573282]    [] F do_physdev_op+0x1373/0x2c4c
(XEN) [   41.590618]    [] F pv_hypercall+0x6be/0x838
(XEN) [   41.607947]    [] F lstar_enter+0x143/0x150
(XEN) [   41.625269]=20
(XEN) [   41.836038]=20
(XEN) [   41.854778] ****************************************
(XEN) [   41.877320] Panic on CPU 10:
(XEN) [   41.897494] Assertion 'desc->arch.creator_domid =3D=3D DOMID_INVAL=
ID' failed at arch/x86/irq.c:294
(XEN) [   41.924180] ****************************************

I got it twice in a row already, so looks rather reliable. As you can
see by the timestamps, it's (expectedly) rather slow - I guess that's
relevant.

This is Xen staging from yesterday. It's on the ADL runner, haven't
tried this one on others yet.

Full console log at https://gist.github.com/marmarek/47d70eb68db03caff14dfb=
b936f9149b

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--/BvfcpyxYdgDCW1s
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgjm2gACgkQ24/THMrX
1yyY6gf+K3prYvoBDV7cb5nf7SQkHjpk5aHp3tzXcAkQslDCufeXS9H5m0epdOXt
V2dtEhD3MtG5wc0xY5n+2x6p79/q4t9U4LCrf1b2QkkllmrmZTHTDI7+PcbYdxEj
2XlxRkIrkeO/B16C9tGonppmwHtHeH8Z3BlcKd2nC3FAgRtoxnLVzI18mCwJzCA/
4C7GLLiS6w5dGiO4h3rs6cXj8iyQ77zvY/WxlLNGNbCQw9EhGUYvKeYozy8j2i9x
2VKL1TXQwxeIvzwhxtjmJdXoUlTLgQ9Wh0F6to4mkDVxG+G6uaHkiIf480JZKWCd
ZzeRXcK1gJd1gbYcKZviwAwgPA3PsQ==
=5Mle
-----END PGP SIGNATURE-----

--/BvfcpyxYdgDCW1s--


From xen-devel-bounces@lists.xenproject.org Tue May 13 19:55:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 19:55:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983526.1369811 (Exim 4.92)
	(envelope-from )
	id 1uEvif-0004IA-Jg; Tue, 13 May 2025 19:55:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983526.1369811; Tue, 13 May 2025 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 1uEvif-0004I3-Gx; Tue, 13 May 2025 19:55:17 +0000
Received: by outflank-mailman (input) for mailman id 983526;
 Tue, 13 May 2025 19:55:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEvid-0004HX-Mu
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 19:55:15 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2414::61f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2c19ab16-3034-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 21:55:09 +0200 (CEST)
Received: from PH8PR07CA0018.namprd07.prod.outlook.com (2603:10b6:510:2cd::15)
 by SJ2PR12MB7917.namprd12.prod.outlook.com (2603:10b6:a03:4c7::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.28; Tue, 13 May
 2025 19:55:03 +0000
Received: from SA2PEPF000015C9.namprd03.prod.outlook.com
 (2603:10b6:510:2cd:cafe::92) by PH8PR07CA0018.outlook.office365.com
 (2603:10b6:510:2cd::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.16 via Frontend Transport; Tue,
 13 May 2025 19:55:03 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SA2PEPF000015C9.mail.protection.outlook.com (10.167.241.199) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Tue, 13 May 2025 19:55:03 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 13 May
 2025 14:55:02 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 13 May 2025 14:55:01 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2c19ab16-3034-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WFEeT8afkKAomjAYG3V3V2NvrxHCroYvJeYj3AslNkRF+BGD00xXloMLi+e3jFmrYBtGt071AfnovKYDw9PJnAvJh5ngdmOBZLf2lqy5PCRWSePxfdNmf8Xgfixmgny0bQbC6wF2KYFShAKI1UtAt8eraWgG6DEo2JOa48hlLbf7tbKwpLBn0H5XOzJk5M+FoImtPKsBvSuES3GkqOr9oxQAJ1YSN8ptFSbgiYQkGimGAdcOgE71VQA6L97miNOLqZmiom21IRKJT1ro4i20hYEr/C70xqefCNADu5W7GzuU6WwkeHPx3VR50+0pqFAQbeDBiNFIY2TF1a/QoiYUwg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=x0ewlAJEI0hIyeEIlh2itiScntWQay2krF1ORaplPvc=;
 b=qBao+hnhPQvZ9Hu/0egHwpr8EOxNqck8zvPV4OjmNof/rNov+dA2QjViqJls3r3HGdQqGl55fu+ueFvxl/OXkpkXWDeu8LQoeAiRTLzVH7bWv354ZF+e0x3EOPfd9b/SbgzYsFnND9F9s4+Wi1zDZ4pZXUsJ8AEFOA6PkPEnBBSbGM39z3M1lK4DtdCwaBgb+pJmFUz7P6UlgbnMYz87nIMichJGaxCyQQDEw4fXSwSWIRrmd/1TvmD5YRVLJ2bWHTalhulJ+yfE2LMqlYjFoJZfS/nX0is8C1zMHUi+66KNFTVLfk7UMw0pzvwtTreQp1rdT5nvbSMPGRLIdwzIaQ==
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=x0ewlAJEI0hIyeEIlh2itiScntWQay2krF1ORaplPvc=;
 b=rMWJZlJn9jaz9pP8daOjIMowjOFpSwpKVQMBOst+zbyxL4nVzqqfSu44U6TjAjtbWiCs/qHsJB4hiVjs3PU5MjKplkQltnDngmSu/l+a2ZJAhamhP9/2DjJm4m+706u8S5pUUQPo6fAbztWrXNGaBSO06wwf/ZdkjJw91LzElTw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , 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 v3 1/2] xen/arm: exclude xen,reg from direct-map domU extended regions
Date: Tue, 13 May 2025 15:54:49 -0400
Message-ID: <20250513195452.699600-2-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250513195452.699600-1-stewart.hildebrand@amd.com>
References: <20250513195452.699600-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF000015C9:EE_|SJ2PR12MB7917:EE_
X-MS-Office365-Filtering-Correlation-Id: 9dabeee6-a1e5-4df3-bf97-08dd92580d7a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?FERx/En4WeVbzooEZngMr7JIbqU2Fe3kOTcItSiCCyr4JvfGnSbdCbsA8nNV?=
 =?us-ascii?Q?AgrAm5fGZ1rkZgXrE+BSrhjWgwjoNifxtQ6DGy6oHzNonOnPORU1Xoya1VfS?=
 =?us-ascii?Q?tbIjJyA5uHiFdzleAmNg6WrmBq14kiNb+qMzWBTKgtcRlkFfSQZVbkaNYUJO?=
 =?us-ascii?Q?u4XjW8UBuVAlqosna/LJAPS5zkMxLIoojRfohHvJuI9TXXFq2dsBGwyqlqIr?=
 =?us-ascii?Q?NMEmUXgCjBTt+VYXDcVl6SU3qsNUT3qQucmeGjGTS0wTptIkdpNN8PG4B7I3?=
 =?us-ascii?Q?d57CD80EUJzxeALUWtBjARfn28/fb4tmEUtv+xm2h+DL71b8FQsjdO4P46Zy?=
 =?us-ascii?Q?hLtXB1KyS72c4PBOXFsBjpVuDBlos4ZgyUzDwGqu6++KnSCgWbng0vVfVxCn?=
 =?us-ascii?Q?sbD86ZkZaA/IrqwHD/Yzbw4MSMyWshVSpcQk8/wrffFQBAFDkdyUOL+L/IFL?=
 =?us-ascii?Q?Lw3n9hrzLoL2LwJc49HB35Q3TNiCm1aeGoeB+ize2cmqRGSTUrvONuhIlAvk?=
 =?us-ascii?Q?v91dSft0j4u1vKaywH55yvwiavCllpREk76Y00ivoLjXRD1WiNwNKdmK/tS8?=
 =?us-ascii?Q?m63Dj6TGlhDCPACN/ActWCZN6CiHqhyiJXS+0asiRjAt8yWPNynWbBR3SCKv?=
 =?us-ascii?Q?YsNlXRl+p/RTLoHTUtVJAJ/oa30Nkpixq5PAWGNxI8Jw/y7aFxS02C4xDN9x?=
 =?us-ascii?Q?7nMqsXosx6q3U+vUfh9nmu0N8KIZnIK6R+vJGtCm7V5LikUztvbddKLhsiyR?=
 =?us-ascii?Q?/5MQCOkoyTTTcBJQ/uRQRVyisHMA5/jD6Gm22Rv5jwBJUVfx0PHfUVANex0P?=
 =?us-ascii?Q?h/2W3bn4Lx2OvdX5dnzsgBmdcP3XSx3VQ/TiT5W49FZ9a3CrIDqpH7fXwyH3?=
 =?us-ascii?Q?QxOJRnEexqQZGgVLeWv1Z2N2o9UK/OQavkTx0dy6CrGdk9SSeVbIuvGPsVyg?=
 =?us-ascii?Q?573mDfWd3WYpSJ6maKR/Ygh8NFLakX1Ek0z+OaGT5ngATS7sDTW4kDAAFvMV?=
 =?us-ascii?Q?ADeFVXphJqSNwUlJw44xPxK8q1PxAnXAwm5v9Xc5iZLsLszXry3lAzxFUoxn?=
 =?us-ascii?Q?85KaknH1E2xmBX2FWTCReqBfvqnSlN4mb4ZK4xrf3o7YCwNXMBgrrxcxbBPs?=
 =?us-ascii?Q?MXRqbvFJWXJe8KrHZDY9YYP5wstOdOaIYG15pTmq8m8i4L6votBAnW2emMWx?=
 =?us-ascii?Q?MnKyS02IQDikkDob+hfwlGGXoykPk/yBjEqlRgHIydgs+T3Drkj5p73zFjmM?=
 =?us-ascii?Q?DaJ3oYgLc/MDR0YV5lOhzzl+34IdPXRqDFzC/9eQ3/b0CmqpTKCTEFoaw8U7?=
 =?us-ascii?Q?XfsFoB+CM7CHW/L7D58r3AmPv9/CXbV4qD7Z8AfbJ04RvAhso2cINN/lAouE?=
 =?us-ascii?Q?c1b2kZao5ohgM1PdiCAKPfJIhhWoEoJPVZ0my/1TMose2t1O6qvgYuLFA1/d?=
 =?us-ascii?Q?EMj64s4ye3rCNKnaVINV/7EDJ6XiZmygqql57iAxgsLWSIiVtIo+w/t7v7tn?=
 =?us-ascii?Q?Hkn6uS6WqXe6tLOkQ2/3R8dw+hWS/0+t6AH+?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2025 19:55:03.6690
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9dabeee6-a1e5-4df3-bf97-08dd92580d7a
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF000015C9.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7917

Similarly to fba1b0974dd8, when a device is passed through to a
direct-map dom0less domU, the xen,reg ranges may overlap with the
extended regions. Remove xen,reg from direct-map domU extended regions.

Introduce rangeset_count_ranges().

Take the opportunity to update the comment ahead of find_memory_holes().

Signed-off-by: Stewart Hildebrand 
---
v2->v3:
* new patch
---
 xen/arch/arm/domain_build.c | 57 +++++++++++++++++++++++++++++++++----
 xen/common/rangeset.c       | 14 +++++++++
 xen/include/xen/rangeset.h  |  2 ++
 3 files changed, 68 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae9f..3cdf5839bc98 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -824,15 +824,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
 }
 
 /*
- * Find the holes in the Host DT which can be exposed to Dom0 as extended
- * regions for the special memory mappings. In order to calculate regions
- * we exclude every addressable memory region described by "reg" and "ranges"
- * properties from the maximum possible addressable physical memory range:
+ * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
+ * domU as extended regions for the special memory mappings. In order to
+ * calculate regions we exclude every addressable memory region described by
+ * "reg" and "ranges" properties from the maximum possible addressable physical
+ * memory range:
  * - MMIO
  * - Host RAM
  * - PCI aperture
  * - Static shared memory regions, which are described by special property
  *   "xen,shared-mem"
+ * - xen,reg mappings
  */
 static int __init find_memory_holes(const struct kernel_info *kinfo,
                                     struct membanks *ext_regions)
@@ -914,6 +916,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
         }
     }
 
+    if ( kinfo->xen_reg_assigned )
+    {
+        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
+        if ( res )
+            goto out;
+    }
+
     start = 0;
     end = (1ULL << p2m_ipa_bits) - 1;
     res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
@@ -994,11 +1003,30 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
     return res;
 }
 
+static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
+                                      void *data)
+{
+    struct membanks *membank = data;
+    paddr_t s = pfn_to_paddr(s_gfn);
+    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
+
+    if ( membank->nr_banks >= membank->max_banks )
+        return 0;
+
+    membank->bank[membank->nr_banks].start = s;
+    membank->bank[membank->nr_banks].size = e - s + 1;
+    membank->nr_banks++;
+
+    return 0;
+}
+
 static int __init find_host_extended_regions(const struct kernel_info *kinfo,
                                              struct membanks *ext_regions)
 {
     int res;
     struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
+    struct membanks *xen_reg = membanks_xzalloc(
+        max(1, rangeset_count_ranges(kinfo->xen_reg_assigned)), MEMORY);
 
     /*
      * Exclude the following regions:
@@ -1006,6 +1034,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
      * 2) Remove reserved memory
      * 3) Grant table assigned to domain
      * 4) Remove static shared memory (when the feature is enabled)
+     * 5) Remove xen,reg
      */
     const struct membanks *mem_banks[] = {
         kernel_info_get_mem_const(kinfo),
@@ -1014,12 +1043,27 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
 #ifdef CONFIG_STATIC_SHM
         bootinfo_get_shmem(),
 #endif
+        xen_reg,
     };
 
     dt_dprintk("Find unallocated memory for extended regions\n");
 
     if ( !gnttab )
-        return -ENOMEM;
+    {
+        res = -ENOMEM;
+        goto out;
+    }
+
+    if ( !xen_reg )
+    {
+        res = -ENOMEM;
+        goto out;
+    }
+
+    if ( kinfo->xen_reg_assigned )
+        rangeset_report_ranges(kinfo->xen_reg_assigned, 0,
+                               PFN_DOWN((1ULL << p2m_ipa_bits) - 1),
+                               rangeset_to_membank, xen_reg);
 
     gnttab->nr_banks = 1;
     gnttab->bank[0].start = kinfo->gnttab_start;
@@ -1027,6 +1071,9 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
 
     res = find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
                                   ext_regions, add_ext_regions);
+
+ out:
+    xfree(xen_reg);
     xfree(gnttab);
 
     return res;
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index b9e8912fb1c3..77b37ad9b196 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -433,6 +433,20 @@ bool rangeset_is_empty(
     return ((r == NULL) || list_empty(&r->range_list));
 }
 
+int rangeset_count_ranges(const struct rangeset *r)
+{
+    int nr = 0;
+    struct list_head *list;
+
+    if ( r == NULL )
+        return 0;
+
+    list_for_each( list, &r->range_list )
+        nr++;
+
+    return nr;
+}
+
 struct rangeset *rangeset_new(
     struct domain *d, const char *name, unsigned int flags)
 {
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index 817505badf6f..96cc0b5d7930 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -56,6 +56,8 @@ void rangeset_limit(
 bool __must_check rangeset_is_empty(
     const struct rangeset *r);
 
+int __must_check rangeset_count_ranges(const struct rangeset *r);
+
 /* Add/claim/remove/query/purge a numeric range. */
 int __must_check rangeset_add_range(
     struct rangeset *r, unsigned long s, unsigned long e);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 19:55:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 19:55:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983525.1369801 (Exim 4.92)
	(envelope-from )
	id 1uEvic-000446-CN; Tue, 13 May 2025 19:55:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983525.1369801; Tue, 13 May 2025 19: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 1uEvic-00043z-8Z; Tue, 13 May 2025 19:55:14 +0000
Received: by outflank-mailman (input) for mailman id 983525;
 Tue, 13 May 2025 19:55:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEvia-00043t-Qg
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 19:55:12 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20625.outbound.protection.outlook.com
 [2a01:111:f403:2416::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2c5094d3-3034-11f0-9ffb-bf95429c2676;
 Tue, 13 May 2025 21:55:10 +0200 (CEST)
Received: from PH8PR07CA0002.namprd07.prod.outlook.com (2603:10b6:510:2cd::9)
 by CH3PR12MB9343.namprd12.prod.outlook.com (2603:10b6:610:1c0::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.30; Tue, 13 May
 2025 19:55:02 +0000
Received: from SA2PEPF000015C9.namprd03.prod.outlook.com
 (2603:10b6:510:2cd:cafe::53) by PH8PR07CA0002.outlook.office365.com
 (2603:10b6:510:2cd::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.16 via Frontend Transport; Tue,
 13 May 2025 19:55:01 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SA2PEPF000015C9.mail.protection.outlook.com (10.167.241.199) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Tue, 13 May 2025 19:55:01 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 13 May
 2025 14:54:55 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 13 May
 2025 14:54:55 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 13 May 2025 14:54: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" 
X-Inumbo-ID: 2c5094d3-3034-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MOPZBYjV8J7MIlZWXBIGsh4tbb0Gp+QK0TAuuFmrcbMbBWBxPvnj7Ww5pFOOGLk4wMx8+f+odEjHE6pXm9YIn/6QYXfXBSVRCn0dZfsBIRVMWbGRKNSK3VatwuiaToJTq+nlQgpnzntnTLTuDUpk2co006Kwoug51fMxT3Rc6gC3VYJI6dtQm3Ml8lU86iu7KHg9zfwrJwDlNY1qmmtPEKJNw3VY9pPiiVlT8ONYQ6JWjj9oQ8WjUGIWMqsJuBqk9vbMDxiWBwnAhkCNsLmwac/tsV+mO+us/0tS4smqCFloIeteCQpP14svKjH6fSgZ1w6V7XOHqz+VtJdqClQqFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XeMyN+yqsOP3JvILcxshJukZkfGcBqCk8RqK9frElbM=;
 b=XcvycRbXev/p15pX+JjeaReO5BQFPSp/PWNkpObyWF/o/dgz1PoPA0Kvb+VNaS45dnItASbWSQjsRWTkIehOcVyx1xYAijs12WwNB4hBB7cwWZcFnvUHtVMUaVOqi6jOTnvjd2KC/sueR6u8tuKsFzkxD2TXWkDZzhnbsgc2pQHfFHxKLR6L6bjwXJfXjV9HpbN1yjUKwyHqKCPPYH/Fti76j1yEaEkgc+O+e7Q4TO1XG/5CWWxKFd43QG+UsjdqRtT0IdchsJNX6Py2rF5R478QiFRM4WGDqw8GQdjKk3bUW63CLrsmrDwWtbdMhtLZQC2i9zdlQOhBtF2hX65Ueg==
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=XeMyN+yqsOP3JvILcxshJukZkfGcBqCk8RqK9frElbM=;
 b=ps+IVtwdxIOKlRa0dh4/5UrMlEV62cWm+m+v4usWctxpD/Bi93hq3cAJvjlQydPZoQzLpzCtnjUlzN2OaH7ugk7mdTzU3QJgRZaINLkZifPbhe5mZUPlWYGiuGOTZhw4EwBBdIoMHu+wKcFtP8+RjGnhzu7X4jVvbKEis4mRVQE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Juergen Gross 
Subject: [PATCH v3 0/2] arm: extended regions fixes
Date: Tue, 13 May 2025 15:54:48 -0400
Message-ID: <20250513195452.699600-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF000015C9:EE_|CH3PR12MB9343:EE_
X-MS-Office365-Filtering-Correlation-Id: 8af2e911-3a74-4acb-1718-08dd92580bf3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|7416014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?K24Fx9ARHiotksrdOylQUUefZAE9OgHRdyCzGgIykK6GbvEl6PX5+E1tBwWS?=
 =?us-ascii?Q?xFxtteCLuQ9JVpPXrwSTsv50SdaSNXZ0YIIFtUk5VbxJbpKQr9vdAGPWvgJp?=
 =?us-ascii?Q?u3FD33IGLWeIFxnmjH3jvjLgtSJvDpsajlxLsZjTBNgFsgJEjK0ROuN7Bu8L?=
 =?us-ascii?Q?dd16TzRwdDm4+PdbgeMTbI74RrBsxg4WeE6tdS5EzzJbyGBkLK+ZTJsXO/yL?=
 =?us-ascii?Q?KbJZupRkshw59krany5p4/vf4l31/kD4ggGpENh1+3XpsgAPB0MC6Zq2S/tY?=
 =?us-ascii?Q?bNC4SjWhMfZmdabDUYodQFew9frhaEVI0zEvZES1xq81YafNO+ME5MBtXobT?=
 =?us-ascii?Q?fO2R5RyHZ5B9gqNSRnHXRUUWE9TAjE5uRCy1vJ92om868TCTkxdHdaylSCHj?=
 =?us-ascii?Q?IyJoJu0b0JxDfaOMxbcR1PlMpQCIUgrxtzSJqlJt3san9r3KXKBOSjV8gi7a?=
 =?us-ascii?Q?BkSQYZSmYe9Y6EEfZEG/HWa4H4rRvWMs1Pyj5C6xolwFvTTZoNkuBswcpZai?=
 =?us-ascii?Q?Lhb+ANxytM5fQQlcwtlvPqEM6DLtmeW3sTmyal8XFSsIEd3qBX1FGuHX2I5+?=
 =?us-ascii?Q?SbbhqcklSkS5+vIVrfqZrNCrF/JLdMPVGHYxNSnVmdybc1+88YCmNfn2fRkG?=
 =?us-ascii?Q?f4GOQRMyBorXrWNCZvXWHB/Jo2R1SAJ2RiAUifkpoKa+3xDN5j3Ux9jFKR8z?=
 =?us-ascii?Q?lPb6kNimrwAm7TOlWzqh8Y3StlpDg29PRxNwHZOga1RuYZyOrWxy587ebiEf?=
 =?us-ascii?Q?iGTSRHunVzEhP97HlooM2/3d0r3bRKbk7xg0kXC0+a3tVTxXyrniP+VI8GZN?=
 =?us-ascii?Q?MyDJnu/OnJfzZ1pV5x0oOLvUtK321KS45dJBeTNcy3QUYpOtLtvNmAkKwkhk?=
 =?us-ascii?Q?sLp0fQBewMJhztmTMJS++JWAkm3yP2tgP3JruzJe5gZtrNGGE2IQXBGRq5E3?=
 =?us-ascii?Q?J9xrGfCgKlQrEeg8k6V7MOJtnDCD0whMsEvmGqcJp/cUXdeSnqPDDld74KcG?=
 =?us-ascii?Q?iT3Hq3OjtxX75S5rZYiEgs11XOia+dCzT9D9O2obacvAlROwPSvfLWq80vSY?=
 =?us-ascii?Q?b/5xrVgk9yBqiDBDVpexpJlhX1lO3JgAXwJEv/tdP5IlJ+yLmtbkp7zClvm1?=
 =?us-ascii?Q?rbn15a9UK8YMn3F4B4yvQb22w1hUxd+0L+OmbPIN8UWUsN9MhBggHB17ebbJ?=
 =?us-ascii?Q?fisW4yUz+c2jLOnHrWLFNIdOHXhop2YFsfvBYt52+4UmF7QchX6o1FyjdmBj?=
 =?us-ascii?Q?avFkqPx8ZwqAuzIq+FNo98tNhsykeeESeV/fSNX331CIOnyrYMoCWUrJ6yJs?=
 =?us-ascii?Q?zWBotevgMxtSjiFTiwYR9O78kC3xSEsm4QUJplD5BTrF8asBo0fVOkOkr7ZX?=
 =?us-ascii?Q?1Ugs3lyfGqwW+iSA5iz1g3v+0QXUoNpZoekkOJysN0pTLTLYuETx2QtJe2nG?=
 =?us-ascii?Q?r9YgSEKiDQ8N4+vmq/EFP+34/A/+GyQmz8MsRIAQ86E9I5f02OCJnNy4VZmP?=
 =?us-ascii?Q?AyWpbFZ9h8mDDF9CFR9PzRSht+fH2ToRgAgp?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(7416014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2025 19:55:01.1043
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8af2e911-3a74-4acb-1718-08dd92580bf3
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF000015C9.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9343

v2->v3:
* drop committed patches
* add ("xen/arm: exclude xen,reg from direct-map domU extended regions")

v1->v2:
* rebase
* address feedback

Stewart Hildebrand (2):
  xen/arm: exclude xen,reg from direct-map domU extended regions
  tools/arm: exclude iomem from domU extended regions

 tools/libs/light/libxl_arm.c | 118 +++++++++++++++++++++++++++++------
 xen/arch/arm/domain_build.c  |  57 +++++++++++++++--
 xen/common/rangeset.c        |  14 +++++
 xen/include/xen/rangeset.h   |   2 +
 4 files changed, 167 insertions(+), 24 deletions(-)


base-commit: 5873740e41acb8593f92623ddd03caebda2718f6
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 19:55:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 19:55:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983527.1369816 (Exim 4.92)
	(envelope-from )
	id 1uEvif-0004La-TK; Tue, 13 May 2025 19:55:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983527.1369816; Tue, 13 May 2025 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 1uEvif-0004LF-Or; Tue, 13 May 2025 19:55:17 +0000
Received: by outflank-mailman (input) for mailman id 983527;
 Tue, 13 May 2025 19:55:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEvie-0004HX-CM
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 19:55:16 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20626.outbound.protection.outlook.com
 [2a01:111:f403:2412::626])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2ef48e13-3034-11f0-9eb6-5ba50f476ded;
 Tue, 13 May 2025 21:55:14 +0200 (CEST)
Received: from SA9PR11CA0004.namprd11.prod.outlook.com (2603:10b6:806:6e::9)
 by CY3PR12MB9554.namprd12.prod.outlook.com (2603:10b6:930:109::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.30; Tue, 13 May
 2025 19:55:10 +0000
Received: from SA2PEPF000015CC.namprd03.prod.outlook.com
 (2603:10b6:806:6e:cafe::3a) by SA9PR11CA0004.outlook.office365.com
 (2603:10b6:806:6e::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.30 via Frontend Transport; Tue,
 13 May 2025 19:55:10 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SA2PEPF000015CC.mail.protection.outlook.com (10.167.241.202) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Tue, 13 May 2025 19:55:09 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 13 May
 2025 14:55:08 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 13 May 2025 14:55:08 -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" 
X-Inumbo-ID: 2ef48e13-3034-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nCpGVmIBjn2wOkpuMNDC822wlOz1QvGWHKk3Izp0zg3gDVMW+0YR3whimP/dJrk85eKVFuVkYNvJWudATrTzgjvz9YzZUT0RTRwsCtGrI147Epn3jUvjzFiVsQV4e1TUvFMvT5prWVz8unC2MadeF6mkmgZ90Fl5nb5inSo/+mjtYe5GWLZK22wWK4LUDdo+QE1eXiEU2LsaOswLUYAXRwVUrOJbumDXqy6oxdZfykx5weRK20W/cVTKmaLlxjHP6Yn7hhKr4R0mCb8uIdRAeUBKGX/j1zLrmizZARR09A803bzjkpgBttq4XkcLZujmHBxEZxrI8+QB+0ovmSOUYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2q/AfSxkx8gwLWAIeOfpqYIVtb/6CQnpScz5R+ZxTS0=;
 b=MiTeB2klZHi85ucFX/iRX1JFfxEzBsp0T39yECVUqUb0tUoZkHVJMIXLh6UL/XeRgz7YU0QC0uYnWeWPGTNvPU2R/dwaIyTfTaj1Jd1FN3sW9Alc1//fVi9zIzVpE/DGSLrnvzIw+E7aCVoD+UKAgqz1rdrvXDA5rvWsacQSGQ3SlAIvvKPoLaou/A7vWS7YL2nqm+M23I54iSkEOvPrq6/RJyZ1IohZjzKm4OpwADYhB8EZCt0u6cMqtE3erdnaWCz3vMHAM8Q7cp7o52qHEjSt8jCGTqaFoyfZ7SsqhkVA369tqb5y+IBHNe7FUfea1ltxyq7bsDqfgl8J09gtLA==
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=2q/AfSxkx8gwLWAIeOfpqYIVtb/6CQnpScz5R+ZxTS0=;
 b=iIQS7ThyaZoN5n6YMm7EiMa5aLcIopP+DXjS2CjIikmOUzd9DJhB2gGZ8w7fBr6E92KHNeIFmm1u6HG/LtSMpET8d2NNV2B+evuwCShNfmxSJJUbkQjOV63DKgQr97YilfKQFcl6JIZaKjOlKKxBxAZWcZnzGWc3mGuN6oFeM98=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand , Anthony PERARD
	, Juergen Gross 
Subject: [PATCH v3 2/2] tools/arm: exclude iomem from domU extended regions
Date: Tue, 13 May 2025 15:54:50 -0400
Message-ID: <20250513195452.699600-3-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250513195452.699600-1-stewart.hildebrand@amd.com>
References: <20250513195452.699600-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF000015CC:EE_|CY3PR12MB9554:EE_
X-MS-Office365-Filtering-Correlation-Id: beb95c2c-6f4b-4791-996a-08dd925810b6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?i8MeGLh9iTGti8f4ipxcpLOLCSixB20FnO0wN+GSvXkGyD+Q9vROcA5oqBEe?=
 =?us-ascii?Q?87tfM/Mu0frC3MOleyugvNrdr57GWqf1XoKWFOk/gOlmHoPnchIwHCRB3TJ1?=
 =?us-ascii?Q?8JyGr/QR17k3YntvVvHxwgCIhRTgzbk/a1MWAb1SMl+sDuGxAkJhcJTymsDz?=
 =?us-ascii?Q?RpJHTniu2ryV24wFJSrIcaOdQOq+mLQmMo6aTfVS6GDUiSJC2gu0ak5e0Y3R?=
 =?us-ascii?Q?4XzwyrqD3oFBNX3dhKJ4Hr+CeMsHLHVzo4Vz2xEEfNXIhQXnj74aMdt/bFb+?=
 =?us-ascii?Q?0MnGcjdHq/cbWb4psJ+8k9ym5/jmoI1IEqwIAAKa8St8WJH+H0MmVJhrbSUS?=
 =?us-ascii?Q?v0pj1V8qtB806aO7wemUS3CK+Dhp5niKL8imTm/7Nyu7/zQEvQiPVNFMzIdM?=
 =?us-ascii?Q?N3pm+6qH9yHN7IY0zH8EqcC1nkgfpn0046ZXzRnW6ix6uMX43cXNqbx5nJQ1?=
 =?us-ascii?Q?CTJdQGNk9UvGbVCNEuedHlQbsDh/VYv42IPzJQh5ynCZKKN/4tRjJKzb+GJX?=
 =?us-ascii?Q?DgzJuc0JyjSuIfatANP2Y4ZcuzfzIh/bjuasxjAQDDJRFSwl+wyZH6BG10Sr?=
 =?us-ascii?Q?JvwEJsdET9H6ACM4jCdyO7YYsQHmSv1hlvtJmgS97YRKqjI3RISCE8ftQ08a?=
 =?us-ascii?Q?qRLt06XCMAWavTet9Wh92LjOvE1N93hncB9BSFOJpau2SXNpzsJQ2NIjqX2Y?=
 =?us-ascii?Q?o4BXPheau2AcuPgTtSzfyHhCY9xIC86Qqo0AJk7V9GudhUNris/PC/CLspsO?=
 =?us-ascii?Q?T6EZMsA2NeVlLbxyzm+Ag4STUHRYVf7AqlxKxFL3ftQ6jk872zivqldrYO+S?=
 =?us-ascii?Q?YbM2SF3Rf9eyjAwFpMopmT7NdXW1R+r8zOySft9jKaiZSzP2UpfFyQt7T5wW?=
 =?us-ascii?Q?Q7bpmgXqmFrV+dVvjTmafRjp+45nvlkTJr0HdOL+CDuUPTjH7QZaCkvaPuED?=
 =?us-ascii?Q?lH0gmcL+V4/nvqlRDNG4Qhs5kvHno9OJPZtyM252QHvFJ/yDPRPe9LEwLvMP?=
 =?us-ascii?Q?SvhtJKiuUw7MdcOauHvAH7Nfg0gGBlw26uw/tRXUE6wQ7GboEa2Sg2XJ7r0Q?=
 =?us-ascii?Q?PK3qOLrrcBLsQsL1Gj+KZ2Jcj9GLNFLF3n5x7X+KFCaC6n9CBTv8Hy1hPAUV?=
 =?us-ascii?Q?DomrOMeE1RbgyiqQfCROwNLrxFONCjr4RyB8rrXgTCwAPjM1JnUbzwkQq0W1?=
 =?us-ascii?Q?kzJT0T6kqY23kqNvcEdHY4GQ3oZVzL22P1R0TJKTv/btqXesX8INlQuw1F0K?=
 =?us-ascii?Q?yx/SWuYMZgTL9OOyFJmAa8M0My9HTazRf4ngqxbXBdOMBp31xR1RFFJcxyDl?=
 =?us-ascii?Q?OPMFOAaG1lnHo0OpaLm5Us1841g5PGfHb8XrAfo9hTAGVHpJJICH4uHhFZb5?=
 =?us-ascii?Q?eC9EQlgDSc71iM8Ca+wHQxecYXNwQ2UwcXBqdrA9IYx83Q/PEJdApIvsZjFg?=
 =?us-ascii?Q?1fUCbJ8cZgu9cJMgsWfjeH0A0IgUZ1yaM7jm0xx5ZFGURGhUsxUGMNcgcOHa?=
 =?us-ascii?Q?O4yy/UzLxgLRvdXmQO/q/A0oEgD9+ioGiD8a?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2025 19:55:09.1341
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: beb95c2c-6f4b-4791-996a-08dd925810b6
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF000015CC.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY3PR12MB9554

When a device is passed through to a xl domU, the iomem ranges may
overlap with the extended regions. Remove iomem from extended regions.

Signed-off-by: Stewart Hildebrand 
---
Not sure if we need a Fixes: tag, but if we do:
Fixes: 57f87857dc2d ("libxl/arm: Add handling of extended regions for DomU")

v2->v3:
* no change

v1->v2:
* no change
---
 tools/libs/light/libxl_arm.c | 118 +++++++++++++++++++++++++++++------
 1 file changed, 99 insertions(+), 19 deletions(-)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 75c811053c7c..8ae16a1726fc 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -798,6 +798,8 @@ static int make_timer_node(libxl__gc *gc, void *fdt,
     return 0;
 }
 
+#define MAX_NR_EXT_REGIONS   256
+
 static int make_hypervisor_node(libxl__gc *gc, void *fdt,
                                 const libxl_version_info *vers)
 {
@@ -821,7 +823,7 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
      */
     res = fdt_property_reg_placeholder(gc, fdt, GUEST_ROOT_ADDRESS_CELLS,
                                        GUEST_ROOT_SIZE_CELLS,
-                                       GUEST_RAM_BANKS + 1);
+                                       MAX_NR_EXT_REGIONS + 1);
     if (res) return res;
 
     /*
@@ -1517,17 +1519,29 @@ static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname,
 
 #define EXT_REGION_MIN_SIZE   xen_mk_ullong(0x0004000000) /* 64MB */
 
-static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
+static int compare_iomem(const void *a, const void *b)
+{
+    const libxl_iomem_range *x = a, *y = b;
+
+    if (x->gfn < y->gfn)
+        return -1;
+    if (x->gfn > y->gfn)
+        return 1;
+    return 0;
+}
+
+static int finalize_hypervisor_node(libxl__gc *gc,
+                                    libxl_domain_build_info *b_info,
+                                    struct xc_dom_image *dom)
 {
     void *fdt = dom->devicetree_blob;
-    uint64_t region_size[GUEST_RAM_BANKS] = {0}, region_base[GUEST_RAM_BANKS],
-        bankend[GUEST_RAM_BANKS];
+    uint64_t region_base[MAX_NR_EXT_REGIONS], region_size[MAX_NR_EXT_REGIONS];
     uint32_t regs[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) *
-                  (GUEST_RAM_BANKS + 1)];
+                  (MAX_NR_EXT_REGIONS + 1)];
     be32 *cells = ®s[0];
     const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
     const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
-    unsigned int i, len, nr_regions = 0;
+    unsigned int i, j, len, nr_regions = 0;
     libxl_dominfo info;
     int offset, rc;
 
@@ -1542,20 +1556,90 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
     if (info.gpaddr_bits > 64)
         return ERROR_INVAL;
 
+    qsort(b_info->iomem, b_info->num_iomem, sizeof(libxl_iomem_range),
+          compare_iomem);
+
     /*
      * Try to allocate separate 2MB-aligned extended regions from the first
      * and second RAM banks taking into the account the maximum supported
      * guest physical address space size and the amount of memory assigned
      * to the guest.
      */
-    for (i = 0; i < GUEST_RAM_BANKS; i++) {
-        region_base[i] = bankbase[i] +
+    for (i = 0; i < GUEST_RAM_BANKS && nr_regions < MAX_NR_EXT_REGIONS; i++) {
+        struct {
+            uint64_t start;
+            uint64_t end; /* inclusive */
+        } unallocated;
+        uint64_t size = 0;
+
+        unallocated.start = bankbase[i] +
             ALIGN_UP_TO_2MB((uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT);
 
-        bankend[i] = ~0ULL >> (64 - info.gpaddr_bits);
-        bankend[i] = min(bankend[i], bankbase[i] + banksize[i] - 1);
-        if (bankend[i] > region_base[i])
-            region_size[i] = bankend[i] - region_base[i] + 1;
+        unallocated.end = ~0ULL >> (64 - info.gpaddr_bits);
+        unallocated.end = min(unallocated.end, bankbase[i] + banksize[i] - 1);
+
+        if (unallocated.end > unallocated.start)
+            size = unallocated.end - unallocated.start + 1;
+
+        if (size < EXT_REGION_MIN_SIZE)
+            continue;
+
+        /* Exclude iomem */
+        for (j = 0; j < b_info->num_iomem && nr_regions < MAX_NR_EXT_REGIONS;
+             j++) {
+            struct {
+                uint64_t start;
+                uint64_t end; /* inclusive */
+            } iomem;
+
+            iomem.start = b_info->iomem[j].gfn << XC_PAGE_SHIFT;
+            iomem.end = ((b_info->iomem[j].gfn + b_info->iomem[j].number)
+                         << XC_PAGE_SHIFT) - 1;
+
+            if (iomem.end >= unallocated.start
+                && iomem.start <= unallocated.end) {
+
+                if (iomem.start <= unallocated.start) {
+                    unallocated.start = iomem.end + 1;
+
+                    if (iomem.end >= unallocated.end)
+                        /* Complete overlap, discard unallocated region */
+                        break;
+
+                    /* Beginning overlap */
+                    continue;
+                }
+
+                if (iomem.start > unallocated.start) {
+                    assert(unallocated.end > unallocated.start);
+                    size = iomem.start - unallocated.start;
+
+                    if (size >= EXT_REGION_MIN_SIZE) {
+                        region_base[nr_regions] = unallocated.start;
+                        region_size[nr_regions] = size;
+                        nr_regions++;
+                    }
+
+                    unallocated.start = iomem.end + 1;
+
+                    if (iomem.end >= unallocated.end)
+                        /* End overlap, discard remaining unallocated region */
+                        break;
+                }
+            }
+        }
+
+        if (unallocated.end > unallocated.start
+            && nr_regions < MAX_NR_EXT_REGIONS)
+        {
+            size = unallocated.end - unallocated.start + 1;
+
+            if (size >= EXT_REGION_MIN_SIZE) {
+                region_base[nr_regions] = unallocated.start;
+                region_size[nr_regions] = size;
+                nr_regions++;
+            }
+        }
     }
 
     /*
@@ -1565,16 +1649,12 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
     set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
               GUEST_GNTTAB_BASE, GUEST_GNTTAB_SIZE);
 
-    for (i = 0; i < GUEST_RAM_BANKS; i++) {
-        if (region_size[i] < EXT_REGION_MIN_SIZE)
-            continue;
-
+    for (i = 0; i < nr_regions; i++) {
         LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"",
-            nr_regions, region_base[i], region_base[i] + region_size[i]);
+            i, region_base[i], region_base[i] + region_size[i]);
 
         set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
                   region_base[i], region_size[i]);
-        nr_regions++;
     }
 
     if (!nr_regions)
@@ -1626,7 +1706,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
 
     }
 
-    res = finalize_hypervisor_node(gc, dom);
+    res = finalize_hypervisor_node(gc, &d_config->b_info, dom);
     if (res)
         return res;
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 13 22:23:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 22:23:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983588.1369830 (Exim 4.92)
	(envelope-from )
	id 1uEy29-0006go-6I; Tue, 13 May 2025 22:23:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983588.1369830; Tue, 13 May 2025 22:23: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 1uEy29-0006gh-3L; Tue, 13 May 2025 22:23:33 +0000
Received: by outflank-mailman (input) for mailman id 983588;
 Tue, 13 May 2025 22:23:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEy27-0006gW-38
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 22:23:31 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e37adb1d-3048-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 00:23:27 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 174717499037724.98380287927887;
 Tue, 13 May 2025 15:23: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" 
X-Inumbo-ID: e37adb1d-3048-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747174994; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=dnbxfO9FO9L9jHwq5lmiybVz8M4I7DPxem85dxhxHznEk7x7w0/Z2ZGtG/RLDnxTDxkR3vlhUISZtLGaXcorv7UGwVZb2ZhvXAAZZsPNtAT3PL1sXEUcKZOxOia5xTeHbxQrPY6CdC7KpX9Dy35e5SLT3OZ2/nKZpnyoYuKex6I=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747174994; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=NXg63RRzJ4hapBxJNGZiNbaJBJJTD1PtZ9P4eE9E0wc=; 
	b=Iheu5mM+XTRBV24/BjGZqHB/SiWlDpdZajRsLqfxfXhcEYEoBFhVcnCimVch0k9NePuiBhY/lubWsQ1OPv5yK7YWzLTR4YQnWuSzIV2khIOShmtmbcQaClRk1g1fvg2kHsOXB3ryYC3GL6T71poVcbMsMoItBpxVLD3w+/gmGjQ=
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=1747174994;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=NXg63RRzJ4hapBxJNGZiNbaJBJJTD1PtZ9P4eE9E0wc=;
	b=M3lNsuLX15puJACVHh8doX92RV7e0plEgvnwUS3LZ2rgZSHRjJ8fuJWXtpp6nf/Y
	g5bKGCW3jjtTHkh4urWT70bo37Zvu1bQU6/Pj8POnxLNEJM3oAgfMZbMAXpq7nBwp2j
	cbpu41wgPtPvOiw3DtoZnjGqYHCP3Nfek8xAg1dw=
Message-ID: <6e3f3727-d084-40b9-a42a-46c52e770c88@apertussolutions.com>
Date: Tue, 13 May 2025 18:23:09 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 02/12] common/hyperlaunch: introduce the domain builder
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Jason Andryuk , Denis Mukhin ,
 Alejandro Vallejo , xen-devel@lists.xenproject.org
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-3-agarciav@amd.com>
 <9021c878-9605-4d6e-95b8-ab97da186542@apertussolutions.com>
 <29a55d44-c26e-4834-b93b-47cbd98f885e@suse.com>
 
 
Content-Language: en-US
From: "Daniel P. Smith" 
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 5/13/25 04:05, Jan Beulich wrote:
> On 06.05.2025 21:29, Daniel P. Smith wrote:
>> On 5/2/25 03:21, Jan Beulich wrote:
>>> On 30.04.2025 20:56, Daniel P. Smith wrote:
>>>> On 4/29/25 08:36, Alejandro Vallejo wrote:
>>>>> --- a/xen/common/Makefile
>>>>> +++ b/xen/common/Makefile
>>>>> @@ -11,6 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
>>>>>     obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
>>>>>     obj-$(CONFIG_IOREQ_SERVER) += dm.o
>>>>>     obj-y += domain.o
>>>>> +obj-$(CONFIG_DOMAIN_BUILDER) += domain-builder/
>>>>
>>>> Please don't do this, use IF_ENABLED in core.c and then hide the
>>>> unnecessary units in domain-builder/Makefile as I originally had it.
>>>> This allows for a much easier time incrementally converting the dom0
>>>> construction path into a generalized domain construction path.
>>>
>>> That is, are you viewing this as a transitional thing only? If the end
>>> goal is to have it as Alejandro has it above, that may be acceptable
>>> (even if not nice).
>>
>> There is/will be shared domain construction code between dom0-only and
>> multidomain construction, with it will all living under domain builder.
>> So no, the end goal is not what Alejandro just did. The end result will
>> be the way I had it, with a different kconfig option to enable/disable
>> the multidomain construction path.
> 
> Isn't CONFIG_DOMAIN_BUILDER a misnomer then?

Which is why I originally had two kconfig flags, one to enable dtb 
parsing for domain configuration, which allowed dom0 construction from 
dtb. Then there was the second flag that was to enable multi-domain 
construction. I have reworked a portion of the approach in the RFC based 
on feedback, which is based off of this series. In it, I tried to 
minimize how much went into common, but you will see how I still had to 
rework the kconfig flags.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Tue May 13 22:25:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 22:25:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983597.1369840 (Exim 4.92)
	(envelope-from )
	id 1uEy3v-0007Br-FU; Tue, 13 May 2025 22:25:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983597.1369840; Tue, 13 May 2025 22: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 1uEy3v-0007Bk-Cr; Tue, 13 May 2025 22:25:23 +0000
Received: by outflank-mailman (input) for mailman id 983597;
 Tue, 13 May 2025 22:25:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uEy3t-0007BB-G3
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 22:25:21 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 26886216-3049-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 00:25:20 +0200 (CEST)
Received: from [127.0.0.1] ([76.133.66.138]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54DMOpTA2629221
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Tue, 13 May 2025 15:24:51 -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" 
X-Inumbo-ID: 26886216-3049-11f0-9eb6-5ba50f476ded
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54DMOpTA2629221
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747175093;
	bh=7lqXvgutqBhxBiqB2WRmqV45ZUWRMix0kVNa0a5yjjE=;
	h=Date:From:To:CC:Subject:In-Reply-To:References:From;
	b=jRy0VsKlS3Nvf/A+ezlJoCBAkUunwHrhNiPzC26OWpSiO3GDjxRzVP+5usgYjAIWk
	 4FbNyhxrRkEl/j9FrntXweVv7V7NhKgxIXbEFR4cSrHZghN5QHXW8xvOL1ahGOfAha
	 yfsgN1IllT6qL/n3XTuX23ybYMKX3K7jJyvYgvx7mujkTK0PdIk4SJXKIbmmrS/DwM
	 xGBftzkT6HDCYa7z4oqwVfxG6xNOgdX+bDVOKF/YLznkmBnGWkksg3pKNzqLjeTs18
	 gcIkkwKjMEK8SmckOFvoI3Wrlf8chFeD3NCcX5NUHCT9kSfqob8w7uGl9BPhSJKEAH
	 Hsq+1NLFpOPcQ==
Date: Tue, 13 May 2025 15:24:51 -0700
From: "H. Peter Anvin" 
To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= , Xin Li ,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        virtualization@lists.linux.dev
CC: Ajay Kaher ,
        Alexey Makhalov ,
        Broadcom internal kernel review list ,
        Thomas Gleixner , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        Boris Ostrovsky ,
        xen-devel@lists.xenproject.org
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_5/6=5D_x86/paravirt=3A_Switch_MSR_acce?=
 =?US-ASCII?Q?ss_pv=5Fops_functions_to_instruction_interfaces?=
User-Agent: K-9 Mail for Android
In-Reply-To: <6cc20ef6-d8e5-4c74-89d9-6a949c84b397@suse.com>
References: <20250506092015.1849-1-jgross@suse.com> <20250506092015.1849-6-jgross@suse.com> <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com> <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>   <6cc20ef6-d8e5-4c74-89d9-6a949c84b397@suse.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On May 12, 2025 11:06:02 PM PDT, "J=C3=BCrgen Gro=C3=9F"  wrote:
>On 13=2E05=2E25 07:55, Xin Li wrote:
>> On 5/12/2025 4:24 AM, Juergen Gross wrote:
>>> Now with the mentioned patch really attached=2E :-)
>>>=20
>>=20
>> Does it allow patching with an instruction more than 6 bytes long?
>>=20
>> The immediate form MSR instructions are 9 bytes long=2E
>
>Yes, shouldn't be a problem=2E
>
>
>Juergen

However, it is more than that=2E The immediate instructions have a differe=
nt interface, and it makes more sense to use the extra bytes to shuffle the=
 bits around for the legacy forms:

Write:

    mov %rax,%rdx
    shr $32,%rdx
    wrmsr(ns)

Read:

    rdmsr
    shl $32,%rdx
    or %rdx,%rax

For the write case, this also means that two separate trap points are need=
ed=2E

As far as Xen (the only user of pv msrs), note that it only paravirtualize=
s a very small number of MSRs, and some of those are fairly performance sen=
sitive, so not going through the Xen framework for MSRs known to be either =
native or null on Xen would definitely be a win=2E


From xen-devel-bounces@lists.xenproject.org Tue May 13 22:56:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 22:56:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983613.1369850 (Exim 4.92)
	(envelope-from )
	id 1uEyXd-0002qz-NG; Tue, 13 May 2025 22:56:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983613.1369850; Tue, 13 May 2025 22:56: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 1uEyXd-0002qs-Ki; Tue, 13 May 2025 22:56:05 +0000
Received: by outflank-mailman (input) for mailman id 983613;
 Tue, 13 May 2025 22:56:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEyXd-0002qm-7V
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 22:56:05 +0000
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com
 [2607:f8b0:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6cd8c795-304d-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 00:55:55 +0200 (CEST)
Received: by mail-pg1-x531.google.com with SMTP id
 41be03b00d2f7-af908bb32fdso233183a12.1
 for ; Tue, 13 May 2025 15:55:55 -0700 (PDT)
Received: from [192.168.1.87] ([38.41.223.211])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-30e33482fd3sm136941a91.37.2025.05.13.15.55.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 15: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" 
X-Inumbo-ID: 6cd8c795-304d-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747176954; x=1747781754; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=LBJDbb+g+rnG8821hA+sNUH+3t1umps8kf5QOmsN0dM=;
        b=V/Xii7LAHbEm/Yza/HOnYLYv3UQyVosETh/uIxnnFozRikhfajOkMI5RnpNNHUbGHO
         4rcriKiTeBoA9g1k8zfd/atP27caxln7kZvS/nfuHaqdF/jWKFpBGy8oJ0D0tjfuzw4c
         T4CR7Lmu5ElME2MMJd6lrXa0zf2eqcf+HtznIkYFBKHLdWlb9bTZbiyN5Q18T2ztL3FX
         tG/rvfD+A0bZMPFc8e8ebtdw6oOCy+B/8H6p2RhyuAn3F/yXWGIWFDn14qpYgAYsb0rn
         wprkC+cX687XuJyTz+9bNR9v0ryTMKOUlTWTrbuqeTdnRfu4Lmy5d4vvxIoByN21rLat
         ClXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747176954; x=1747781754;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=LBJDbb+g+rnG8821hA+sNUH+3t1umps8kf5QOmsN0dM=;
        b=AgY5CN8ogxr520G1QBOtrzv/0mZ340aUKIRY9J4OpBFz6C+f01k//hnUT/dkn5DHmt
         y6GHFWQYTe5EnlN7M+QUhAarNwfUYhEJxr0TXbw5MHbWkBfFPek1ctKxRP6uDm+cLfHe
         FzkpER+ryRqRUiqvv0Hh8dwPJ4pDyB1y4BQj2bHfjYQXlgXGb7J/DUNcLwzE85PhWxon
         BO1FuaAETitR2X7CXjMZfKrr2lBSWOQ3GFUjvd8eJZZFKrF8nW7jAwA29cntRALc6foj
         ZK62tPb5c/UZn+2/IZoA8hV0IQY3x04WkxTHO9BCZCwEHRqMCn1zZzRcqjXh2O7nHoYl
         bJdQ==
X-Forwarded-Encrypted: i=1; AJvYcCVU4vhaZkqULhFcPRikNg2q0iq/xdLR67nz46OTzoRiCEivl81tZZL15pqGbTJMVJbS1CJT5ehqQnI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YybhzRhXK45z0Ra6Dp6wqch4XG+Wfa1w3S5HlpEJT6meJf4CrBG
	pthzSN68ij3quwTeoJXyZfynbcA/yLIifC1jFoIqCDlZd9ZeC/TaSQPnFcTZp0wXPQFmrX9kgm4
	2
X-Gm-Gg: ASbGncsCl0gWnpm9WIfhhAeQ2NYdfIrLBqo8/4Ifdm2PvQ54XG7zlNeMO7HyIZDyRwV
	m1I91e8XVh22XZrpfm+d6YrK/9HkSFn2ktqUuKoy6rifgXZJ8MMWHkNrFU8o+Zab2dYgPYl8iPd
	mYsxdFJsmQCtzu2sfRRaYFrTp2LXybVonjCu0EQdw5zR5CXYRiKjTl5HZOjN6gWumKxAqAPRbQ2
	D9NiAxlmPcfWz0nfPdzLwc9fKwoMSbDJHAUI7y4Cdk0biaSMOtPP4nBmA/lTmqcR7V/uRfhv+p5
	3PPHmlQMR+AU8V8ciuVyJXcnqZkEcAyijd/HZ0+Nzgnd4jBifd9/r+hPKVTBIHqi
X-Google-Smtp-Source: AGHT+IHdeevlFHLxUccT1xfjG6u5tqxbZV9hv1bsXOwnio3wriSr/+Avu60k8tk0djcNq0ykX0Xh9w==
X-Received: by 2002:a17:90b:33c8:b0:2fa:2268:1af4 with SMTP id 98e67ed59e1d1-30e0db01419mr7180936a91.7.1747176953809;
        Tue, 13 May 2025 15:55:53 -0700 (PDT)
Message-ID: 
Date: Tue, 13 May 2025 15:55:52 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] hw/xen/arch_hvm: Unify x86 and ARM variants
Content-Language: en-US
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org
Cc: Richard Henderson ,
 xen-devel@lists.xenproject.org, Anthony PERARD ,
 David Woodhouse ,
 "Edgar E. Iglesias" , qemu-arm@nongnu.org,
 Stefano Stabellini , Paul Durrant ,
 Peter Maydell 
References: <20250513171737.74386-1-philmd@linaro.org>
From: Pierrick Bouvier 
In-Reply-To: <20250513171737.74386-1-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5/13/25 10:17 AM, Philippe Mathieu-Daudé wrote:
> As each target declares the same prototypes, we can
> use a single header, removing the TARGET_XXX uses.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>   include/hw/arm/xen_arch_hvm.h  |  9 ---------
>   include/hw/i386/xen_arch_hvm.h | 11 -----------
>   include/hw/xen/arch_hvm.h      | 14 ++++++++++----
>   hw/arm/xen-pvh.c               |  1 -
>   4 files changed, 10 insertions(+), 25 deletions(-)
>   delete mode 100644 include/hw/arm/xen_arch_hvm.h
>   delete mode 100644 include/hw/i386/xen_arch_hvm.h
> 
> diff --git a/include/hw/arm/xen_arch_hvm.h b/include/hw/arm/xen_arch_hvm.h
> deleted file mode 100644
> index 8fd645e7232..00000000000
> --- a/include/hw/arm/xen_arch_hvm.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -#ifndef HW_XEN_ARCH_ARM_HVM_H
> -#define HW_XEN_ARCH_ARM_HVM_H
> -
> -#include 
> -void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
> -void arch_xen_set_memory(XenIOState *state,
> -                         MemoryRegionSection *section,
> -                         bool add);
> -#endif
> diff --git a/include/hw/i386/xen_arch_hvm.h b/include/hw/i386/xen_arch_hvm.h
> deleted file mode 100644
> index 1000f8f5433..00000000000
> --- a/include/hw/i386/xen_arch_hvm.h
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -#ifndef HW_XEN_ARCH_I386_HVM_H
> -#define HW_XEN_ARCH_I386_HVM_H
> -
> -#include 
> -#include "hw/xen/xen-hvm-common.h"
> -
> -void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
> -void arch_xen_set_memory(XenIOState *state,
> -                         MemoryRegionSection *section,
> -                         bool add);
> -#endif
> diff --git a/include/hw/xen/arch_hvm.h b/include/hw/xen/arch_hvm.h
> index df39c819c8f..8bacaa4ec41 100644
> --- a/include/hw/xen/arch_hvm.h
> +++ b/include/hw/xen/arch_hvm.h
> @@ -1,5 +1,11 @@
> -#if defined(TARGET_I386) || defined(TARGET_X86_64)
> -#include "hw/i386/xen_arch_hvm.h"
> -#elif defined(TARGET_ARM) || defined(TARGET_AARCH64)
> -#include "hw/arm/xen_arch_hvm.h"
> +#ifndef HW_XEN_ARCH_HVM_H
> +#define HW_XEN_ARCH_HVM_H
> +
> +#include 
> +#include "hw/xen/xen-hvm-common.h"
> +
> +void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
> +void arch_xen_set_memory(XenIOState *state,
> +                         MemoryRegionSection *section,
> +                         bool add);
>   #endif
> diff --git a/hw/arm/xen-pvh.c b/hw/arm/xen-pvh.c
> index 4b26bcff7a5..1a9eeb01c8e 100644
> --- a/hw/arm/xen-pvh.c
> +++ b/hw/arm/xen-pvh.c
> @@ -10,7 +10,6 @@
>   #include "hw/boards.h"
>   #include "system/system.h"
>   #include "hw/xen/xen-pvh-common.h"
> -#include "hw/xen/arch_hvm.h"
>   
>   #define TYPE_XEN_ARM  MACHINE_TYPE_NAME("xenpvh")
>   

Reviewed-by: Pierrick Bouvier 



From xen-devel-bounces@lists.xenproject.org Tue May 13 23:58:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 13 May 2025 23:58:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983633.1369860 (Exim 4.92)
	(envelope-from )
	id 1uEzVs-00029Y-23; Tue, 13 May 2025 23:58:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983633.1369860; Tue, 13 May 2025 23:58:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEzVr-00029R-Vn; Tue, 13 May 2025 23:58:19 +0000
Received: by outflank-mailman (input) for mailman id 983633;
 Tue, 13 May 2025 23:58:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEzVq-00029K-Lu
 for xen-devel@lists.xenproject.org; Tue, 13 May 2025 23:58:18 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 228a675f-3056-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 01:58:16 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 7C44844CCA;
 Tue, 13 May 2025 23:58:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CEA7EC4CEED;
 Tue, 13 May 2025 23:58: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" 
X-Inumbo-ID: 228a675f-3056-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747180694;
	bh=mHVywJKDTHyIQaNARwPLhKXQqQyrJqyCPzAPadxHw2E=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=JHA64Bw6GN9WFiSunr6DjaHH53vSNvuNDeKD1TAgMCQaKM1eqBjpB4gq22uH1PoUA
	 msUaVHgPc1ebr3K5Rk4r8e4OqlpSKmYhI79ed6COxAXmo+J4igfqkek+0IUB6AySOO
	 ++7OFKGs6HlSSaBJi7GcujySZwlvbrEAJEuU8/TfXMcMZDjvAwSKkdupNY1A4lsYa4
	 eEsy6QFyOkQOl0WuLExB6ZpOjZOUB/bg3gj5ilz1x2npNrzutNtzSorQg0FzXlJ3K+
	 IgZpiKtUC7np5u0wl2SU8M+UW+a7K2r0+exXe/yflfmxEUG/E08+njxtapaxoRdeKs
	 Lk3wGd+cs0RKg==
Date: Tue, 13 May 2025 16:58:11 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Oleksii Kurochko 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU
 construction
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 13 May 2025, Oleksii Kurochko wrote:
> Refactor construct_domU() to improve architecture separation and reduce
> reliance on ARM-specific logic in common code:
> - Drop set_domain_type() from generic code. This function is specific
>   to ARM and serves no purpose on other architectures like RISC-V,
>   which lack the arch.type field in kernel_info.
> - Introduce arch_construct_domU() to encapsulate architecture-specific
>   DomU construction steps.
> - Implement arch_construct_domU() for ARM. This includes:
>   - Setting the domain type for CONFIG_ARM64.
>   - Handling static memory allocation if xen,static-mem is present in
>     the device tree.
>   - Processing static shared memory.
> - Move call of make_resv_memory_node() to Arm's make_arch_nodes() as
>   this call is specific to CONFIG_STATIC_SHM which is ARM specific,
>   at least, now.
> 
> This cleanup avoids empty stubs on other architectures and moves
> ARM-specific logic into arch code where it belongs.
> 
> Also, don't loose  a return value of functions called in
> Arm's make_arch_nodes().
> 
> Suggested-by: Michal Orzel 
> Signed-off-by: Oleksii Kurochko 
> ---
>  xen/arch/arm/dom0less-build.c            | 42 +++++++++++++++++-------
>  xen/common/device-tree/dom0less-build.c  | 30 ++---------------
>  xen/include/asm-generic/dom0less-build.h |  3 +-
>  3 files changed, 36 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index a49764f0ad..592173268f 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -220,9 +220,14 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
>  {
>      int ret;
>  
> +    ret = make_resv_memory_node(kinfo, GUEST_ROOT_ADDRESS_CELLS,
> +                                GUEST_ROOT_SIZE_CELLS);
> +    if ( ret )
> +        return ret;
> +
>      ret = make_psci_node(kinfo->fdt);
>      if ( ret )
> -        return -EINVAL;
> +        return ret;
>  
>      if ( kinfo->arch.vpl011 )
>      {
> @@ -230,26 +235,41 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
>          ret = make_vpl011_uart_node(kinfo);
>  #endif
>          if ( ret )
> -            return -EINVAL;
> +            return ret;
>      }
>  
>      return 0;
>  }
>  
> -/* TODO: make arch.type generic ? */
> -#ifdef CONFIG_ARM_64
> -void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
> +int __init arch_construct_domU(struct kernel_info *kinfo,
> +                               const struct dt_device_node *node)
>  {
> +    int rc = 0;
> +    struct domain *d = kinfo->d;
> +
> +#ifdef CONFIG_ARM_64
>      /* type must be set before allocate memory */
>      d->arch.type = kinfo->arch.type;
> -}
> -#else
> -void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
> -{
> -    /* Nothing to do */
> -}
>  #endif

NIT: I think it would be nicer to do 

if ( is_hardware_domain(d) )
    return rc;

but it is also OK as below

Reviewed-by: Stefano Stabellini 


> +    if ( !is_hardware_domain(d) )
> +    {
> +        if ( dt_find_property(node, "xen,static-mem", NULL) )
> +        {
> +            if ( !is_domain_direct_mapped(d) )
> +                allocate_static_memory(d, kinfo, node);
> +            else
> +                assign_static_memory_11(d, kinfo, node);
> +        }
> +
> +        rc = process_shm(d, kinfo, node);
> +        if ( rc < 0 )
> +            return rc;
> +    }
> +
> +    return rc;
> +}
> +
>  int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
>                        const struct dt_device_node *node)
>  {
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 2c56f13771..f6aabc2093 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -28,14 +28,6 @@
>  #include 
>  #include 
>  
> -#if __has_include()
> -#   include 
> -#endif
> -
> -#if __has_include()
> -#   include 
> -#endif
> -
>  #define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
>  
>  static domid_t __initdata xs_domid = DOMID_INVALID;
> @@ -507,12 +499,6 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
>      if ( ret )
>          goto err;
>  
> -#ifdef CONFIG_STATIC_SHM
> -    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
> -    if ( ret )
> -        goto err;
> -#endif
> -
>      /*
>       * domain_handle_dtb_bootmodule has to be called before the rest of
>       * the device tree is generated because it depends on the value of
> @@ -787,7 +773,9 @@ static int __init construct_domU(struct domain *d,
>      if ( rc < 0 )
>          return rc;
>  
> -    set_domain_type(d, &kinfo);
> +    rc = arch_construct_domU(&kinfo, node);
> +    if ( rc )
> +        return rc;
>  
>      if ( is_hardware_domain(d) )
>      {
> @@ -799,18 +787,6 @@ static int __init construct_domU(struct domain *d,
>      {
>          if ( !dt_find_property(node, "xen,static-mem", NULL) )
>              allocate_memory(d, &kinfo);
> -#ifdef CONFIG_STATIC_MEMORY
> -        else if ( !is_domain_direct_mapped(d) )
> -            allocate_static_memory(d, &kinfo, node);
> -        else
> -            assign_static_memory_11(d, &kinfo, node);
> -#endif
> -
> -#ifdef CONFIG_STATIC_SHM
> -        rc = process_shm(d, &kinfo, node);
> -        if ( rc < 0 )
> -            return rc;
> -#endif
>  
>          rc = init_vuart(d, &kinfo, node);
>          if ( rc < 0 )
> diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
> index e0ad0429ec..78142e71ca 100644
> --- a/xen/include/asm-generic/dom0less-build.h
> +++ b/xen/include/asm-generic/dom0less-build.h
> @@ -56,7 +56,8 @@ int init_vuart(struct domain *d, struct kernel_info *kinfo,
>  int make_intc_domU_node(struct kernel_info *kinfo);
>  int make_arch_nodes(struct kernel_info *kinfo);
>  
> -void set_domain_type(struct domain *d, struct kernel_info *kinfo);
> +int arch_construct_domU(struct kernel_info *kinfo,
> +                        const struct dt_device_node *node);
>  
>  int init_intc_phandle(struct kernel_info *kinfo, const char *name,
>                        const int node_next, const void *pfdt);
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Wed May 14 00:03:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 00:03:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983645.1369871 (Exim 4.92)
	(envelope-from )
	id 1uEzau-0004Sm-Dw; Wed, 14 May 2025 00:03:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983645.1369871; Wed, 14 May 2025 00: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 1uEzau-0004Sf-B6; Wed, 14 May 2025 00:03:32 +0000
Received: by outflank-mailman (input) for mailman id 983645;
 Wed, 14 May 2025 00:03:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEzas-0004SY-Ac
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 00:03:30 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dcb41393-3056-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 02:03:28 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 592015C4A49;
 Wed, 14 May 2025 00:01:09 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFE4EC4CEE4;
 Wed, 14 May 2025 00:03: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" 
X-Inumbo-ID: dcb41393-3056-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747181006;
	bh=V9r0H4FFmFHRbUIuzb5awbyVY/AV8w/CNxahp6ppDzw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=cak51oBcWts0nQZvhmBIFOTpaWUvxUBJUukktKF/Pke+GX7qiEBMl9OtrF26/jE3T
	 xxH0V9yTBAa6HjEtyvj0+SDps7B82kg1+pbxHUStpgQ0RfvA3CyRtjZ2XMZvSz6jIg
	 TaSBywL2pzpArbM25+PQrp0oPQKd5i9JSv1eKgelZPG/nq2A0BbraLlFWMA/eZKOvj
	 aQ71KQx9MjcBGTxhJMksqsGBGLMtF+Haky1ODud96RoOZVx9HacHLPEqUiBdIt3FY/
	 r59yBQV6f9KD83wbK+Lprqyd8gYrEaDCRaiZVEuE/yYhR0pl5RyWwYx4KMvOtBuqiR
	 qra2z5ZoKrqvw==
Date: Tue, 13 May 2025 17:03:23 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
cc: qemu-devel@nongnu.org, Richard Henderson , 
    xen-devel@lists.xenproject.org, Anthony PERARD , 
    David Woodhouse , 
    "Edgar E. Iglesias" , qemu-arm@nongnu.org, 
    Stefano Stabellini , Paul Durrant , 
    Pierrick Bouvier , 
    Peter Maydell 
Subject: Re: [PATCH] hw/xen/arch_hvm: Unify x86 and ARM variants
In-Reply-To: <20250513171737.74386-1-philmd@linaro.org>
Message-ID: 
References: <20250513171737.74386-1-philmd@linaro.org>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-946740503-1747181006=:368682"

  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-946740503-1747181006=:368682
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Tue, 13 May 2025, Philippe Mathieu-Daudé wrote:
> As each target declares the same prototypes, we can
> use a single header, removing the TARGET_XXX uses.
> 
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Stefano Stabellini 


> ---
>  include/hw/arm/xen_arch_hvm.h  |  9 ---------
>  include/hw/i386/xen_arch_hvm.h | 11 -----------
>  include/hw/xen/arch_hvm.h      | 14 ++++++++++----
>  hw/arm/xen-pvh.c               |  1 -
>  4 files changed, 10 insertions(+), 25 deletions(-)
>  delete mode 100644 include/hw/arm/xen_arch_hvm.h
>  delete mode 100644 include/hw/i386/xen_arch_hvm.h
> 
> diff --git a/include/hw/arm/xen_arch_hvm.h b/include/hw/arm/xen_arch_hvm.h
> deleted file mode 100644
> index 8fd645e7232..00000000000
> --- a/include/hw/arm/xen_arch_hvm.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -#ifndef HW_XEN_ARCH_ARM_HVM_H
> -#define HW_XEN_ARCH_ARM_HVM_H
> -
> -#include 
> -void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
> -void arch_xen_set_memory(XenIOState *state,
> -                         MemoryRegionSection *section,
> -                         bool add);
> -#endif
> diff --git a/include/hw/i386/xen_arch_hvm.h b/include/hw/i386/xen_arch_hvm.h
> deleted file mode 100644
> index 1000f8f5433..00000000000
> --- a/include/hw/i386/xen_arch_hvm.h
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -#ifndef HW_XEN_ARCH_I386_HVM_H
> -#define HW_XEN_ARCH_I386_HVM_H
> -
> -#include 
> -#include "hw/xen/xen-hvm-common.h"
> -
> -void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
> -void arch_xen_set_memory(XenIOState *state,
> -                         MemoryRegionSection *section,
> -                         bool add);
> -#endif
> diff --git a/include/hw/xen/arch_hvm.h b/include/hw/xen/arch_hvm.h
> index df39c819c8f..8bacaa4ec41 100644
> --- a/include/hw/xen/arch_hvm.h
> +++ b/include/hw/xen/arch_hvm.h
> @@ -1,5 +1,11 @@
> -#if defined(TARGET_I386) || defined(TARGET_X86_64)
> -#include "hw/i386/xen_arch_hvm.h"
> -#elif defined(TARGET_ARM) || defined(TARGET_AARCH64)
> -#include "hw/arm/xen_arch_hvm.h"
> +#ifndef HW_XEN_ARCH_HVM_H
> +#define HW_XEN_ARCH_HVM_H
> +
> +#include 
> +#include "hw/xen/xen-hvm-common.h"
> +
> +void arch_handle_ioreq(XenIOState *state, ioreq_t *req);
> +void arch_xen_set_memory(XenIOState *state,
> +                         MemoryRegionSection *section,
> +                         bool add);
>  #endif
> diff --git a/hw/arm/xen-pvh.c b/hw/arm/xen-pvh.c
> index 4b26bcff7a5..1a9eeb01c8e 100644
> --- a/hw/arm/xen-pvh.c
> +++ b/hw/arm/xen-pvh.c
> @@ -10,7 +10,6 @@
>  #include "hw/boards.h"
>  #include "system/system.h"
>  #include "hw/xen/xen-pvh-common.h"
> -#include "hw/xen/arch_hvm.h"
>  
>  #define TYPE_XEN_ARM  MACHINE_TYPE_NAME("xenpvh")
>  
> -- 
> 2.47.1
> 
--8323329-946740503-1747181006=:368682--


From xen-devel-bounces@lists.xenproject.org Wed May 14 00:07:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 00:07:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983655.1369881 (Exim 4.92)
	(envelope-from )
	id 1uEzee-00052A-SN; Wed, 14 May 2025 00:07:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983655.1369881; Wed, 14 May 2025 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 1uEzee-000523-PQ; Wed, 14 May 2025 00:07:24 +0000
Received: by outflank-mailman (input) for mailman id 983655;
 Wed, 14 May 2025 00:07:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEzed-00051x-US
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 00:07:23 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 685360d7-3057-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 02:07:23 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 42C915C5440;
 Wed, 14 May 2025 00:05:04 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83B9CC4CEE4;
 Wed, 14 May 2025 00:07: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" 
X-Inumbo-ID: 685360d7-3057-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747181241;
	bh=nDIW/ShPxys+yLgBG4/j+LA776kk54ox5muaP0Kf3NE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=sxC4hIEpoQV58+bL/vTlVQEpbfFNsAopAztJcfl1+8DwrCH2+ePMUyw3ItnB4vOYc
	 YjukCxyY4BzDr84t0/ZvhkamGWFVHisIze335xxmb54jtJRts0I7ptXkV/W52sNEUv
	 F7waLyqLnbddXP1nQ8gvs5RUriSoxoCbRO8qieSsiKcCCM/RfvH4l4i5n2viFXLCn5
	 VqgCc2TsVTPOdDF7UfUi48DC20iA/XIqk4a7+as8svYlLi50lsyT44LjWlow+wblOg
	 5j89trmeHyRNOrdESwoxVJEfU66qTtNfyms4eh4L6bjm37cRwcTcPfDBgsEE1iDCCr
	 n3YyXAKdnjfQA==
Date: Tue, 13 May 2025 17:07:19 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stewart Hildebrand 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel 
Subject: Re: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation
 __init
In-Reply-To: <20250513171810.668370-1-stewart.hildebrand@amd.com>
Message-ID: 
References: <20250513171810.668370-1-stewart.hildebrand@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 13 May 2025, Stewart Hildebrand wrote:
> All functions in dom0less-build.c should be __init.
> 
> Fixes: 2705f1adb9df ("xen: introduce Kconfig ARCH_PAGING_MEMPOOL")
> Signed-off-by: Stewart Hildebrand 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/common/device-tree/dom0less-build.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 2c56f13771ab..39cb2cd5c70e 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -730,8 +730,8 @@ static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem,
>      return rc;
>  }
>  #else /* !CONFIG_ARCH_PAGING_MEMPOOL */
> -static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
> -                                            const struct dt_device_node *node)
> +static inline int __init domain_p2m_set_allocation(
> +    struct domain *d, uint64_t mem, const struct dt_device_node *node)
>  {
>      return 0;
>  }
> 
> base-commit: 5873740e41acb8593f92623ddd03caebda2718f6
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Wed May 14 00:10:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 00:10:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983663.1369892 (Exim 4.92)
	(envelope-from )
	id 1uEzh9-0005Yl-8X; Wed, 14 May 2025 00:09:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983663.1369892; Wed, 14 May 2025 00: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 1uEzh9-0005Ye-47; Wed, 14 May 2025 00:09:59 +0000
Received: by outflank-mailman (input) for mailman id 983663;
 Wed, 14 May 2025 00:09:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEzh7-0005YY-TV
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 00:09:57 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c4217019-3057-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 02:09:56 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 4710043956;
 Wed, 14 May 2025 00:09:55 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62F19C4CEEF;
 Wed, 14 May 2025 00:09: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" 
X-Inumbo-ID: c4217019-3057-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747181395;
	bh=ylLORO7UhforemxsiCHsk7OgZlD9BpSGYVx1CI6s5nw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Wj/sk04vwAAFel9/1vRSI7s9G89ZYPzIZ4TbbPOczBFS0O3vxRMSF3H0SxLcKvM1T
	 9SmgEupyRhSegR5S65frmzcEQYDZ1s2KaCKPOnd6wB1kR0lf51cWD1RyoHTUAzO8Rl
	 sHkX5EeoY9bNTrg8SgdHCDGYK5ET1kPMP0BJIZHMLG1kuO/PAJPsnvhi23rkbpdl/1
	 cF7j/X22sfW5ZHJ6yMZWjnfs1Ecnm/E8l6qbdi6/tvGKGDBITWx4SlNfqh3/rxnJld
	 kN+8NeRjH/ynZgiFhuo7oYnTS19A0DqscRBMmx/rWgWs7506oHqnoFWdKCXxg/6KuL
	 hVthnTIxv71fg==
Date: Tue, 13 May 2025 17:09:53 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stewart Hildebrand 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel 
Subject: Re: [PATCH 2/2] xen: enforce __init in
 common/device-tree/*-build.c
In-Reply-To: <20250513171810.668370-2-stewart.hildebrand@amd.com>
Message-ID: 
References: <20250513171810.668370-1-stewart.hildebrand@amd.com> <20250513171810.668370-2-stewart.hildebrand@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 13 May 2025, Stewart Hildebrand wrote:
> Code in domain-build.c and dom0less-build.c was migrated from init-only
> files. Thus, they contain only __init functions. Enforce this at build
> time.
> 
> Fixes: ad03faa942b9 ("xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common")
> Fixes: d07b7369aa65 ("xen/common: dom0less: introduce common domain-build.c")
> Signed-off-by: Stewart Hildebrand 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/common/device-tree/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 831b91399b74..ff54a8ef2bee 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1,8 +1,8 @@
>  obj-y += bootfdt.init.o
>  obj-y += bootinfo.init.o
>  obj-y += device-tree.o
> -obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.o
> -obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
> +obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
> +obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
>  obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
>  obj-y += intc.o
>  obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Wed May 14 00:14:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 00:14:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983672.1369901 (Exim 4.92)
	(envelope-from )
	id 1uEzlY-0007KQ-OA; Wed, 14 May 2025 00:14:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983672.1369901; Wed, 14 May 2025 00:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uEzlY-0007KJ-KU; Wed, 14 May 2025 00:14:32 +0000
Received: by outflank-mailman (input) for mailman id 983672;
 Wed, 14 May 2025 00:14:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uEzlX-0007KD-Fn
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 00:14:31 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 64cbddb1-3058-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 02:14:26 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 4E18A5C3939;
 Wed, 14 May 2025 00:12:07 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB457C4CEE4;
 Wed, 14 May 2025 00:14: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" 
X-Inumbo-ID: 64cbddb1-3058-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747181664;
	bh=jDk0BvPdBOsudd297pGyGFep8goSpk+trsNoQeXfyGQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=PqKGWCg8dh3loYFuR0jSEDNpWVH6sczf9s2k3j6fH+99wPEjDU5mG84IBYH5MbgD6
	 bjR2nxsM3pC2s89muWEUGZTb5OpRY+NhJX4YTbeneW+NCPR0lCE+BFYg5zPy8Yv0vs
	 8RLxEJgzLKFwjZ6k9OyVd8HdRr+7o1BoJNcRiFq1GVK8wBC3J5GLJscsFxtzpbNeaR
	 5o7g2Tedq+gTAJ8DP6FhEoyUi8KqEgjQeehOQg9wJepzLb2012iEcqacZ+iTAFaRtW
	 MsXRcMgbsLAI8UZlKD9z2Nytq530gIRICfeorKFZ+sL0L4v+WL7V0rsSewojSI0eoA
	 J4dtDhDgnN/Rw==
Date: Tue, 13 May 2025 17:14:22 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: John Ernberg 
cc: Juergen Gross , 
    Stefano Stabellini , 
    Oleksandr Tyshchenko , 
    "xen-devel@lists.xenproject.org" , 
    "iommu@lists.linux.dev" , 
    "linux-kernel@vger.kernel.org" , 
    Christoph Hellwig , 
    "imx@lists.linux.dev" 
Subject: Re: [PATCH v2] xen: swiotlb: Wire up map_resource callback
In-Reply-To: <20250512071440.3726697-1-john.ernberg@actia.se>
Message-ID: 
References: <20250512071440.3726697-1-john.ernberg@actia.se>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 12 May 2025, John Ernberg wrote:
> When running Xen on iMX8QXP, an Arm SoC without IOMMU, DMA performed via
> its eDMA v3 DMA engine fail with a mapping error.
> 
> The eDMA performs DMA between RAM and MMIO space, and it's the MMIO side
> that cannot be mapped.
> 
> MMIO->RAM DMA access cannot be bounce buffered if it would straddle a page
> boundary and on Xen the MMIO space is 1:1 mapped for Arm, and x86 PV Dom0.
> Cases where MMIO space is not 1:1 mapped, such as x86 PVH Dom0, requires an
> IOMMU present to deal with the mapping.
> 
> Considering the above the map_resource callback can just be wired to the
> existing dma_direct_map_resource() function.
> 
> There is nothing to do for unmap so the unmap callback is not needed.
> 
> Signed-off-by: John Ernberg 

Reviewed-by: Stefano Stabellini 


> ---
> 
> v2:
>  - Just use dma_direct_map_resource() directly (Stefano Stabellini)
>  - Incorporate some of the discussion and explanations from v1 into the
>     commit message (Stefano, Christoph)
>  - General English improvements in the commit message.
>  - Just this patch now, 1/2 in the previous set was applied
> 
> v1: (series) https://lore.kernel.org/xen-devel/20250502114043.1968976-1-john.ernberg@actia.se/
> ---
>  drivers/xen/swiotlb-xen.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ef56a2500ed6..da1a7d3d377c 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -426,4 +426,5 @@ const struct dma_map_ops xen_swiotlb_dma_ops = {
>  	.alloc_pages_op = dma_common_alloc_pages,
>  	.free_pages = dma_common_free_pages,
>  	.max_mapping_size = swiotlb_max_mapping_size,
> +	.map_resource = dma_direct_map_resource,
>  };
> -- 
> 2.49.0
> 


From xen-devel-bounces@lists.xenproject.org Wed May 14 01:25:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 01:25:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983693.1369911 (Exim 4.92)
	(envelope-from )
	id 1uF0rw-00075i-FU; Wed, 14 May 2025 01:25:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983693.1369911; Wed, 14 May 2025 01: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 1uF0rw-00075b-BJ; Wed, 14 May 2025 01:25:12 +0000
Received: by outflank-mailman (input) for mailman id 983693;
 Wed, 14 May 2025 01:25:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF0rv-00075V-02
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 01:25:11 +0000
Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com
 [2607:f8b0:4864:20::1131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 463d72cc-3062-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 03:25:09 +0200 (CEST)
Received: by mail-yw1-x1131.google.com with SMTP id
 00721157ae682-7081165a238so49759207b3.1
 for ; Tue, 13 May 2025 18:25:09 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-70a3d895dd5sm27021197b3.4.2025.05.13.18.25.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 18:25: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" 
X-Inumbo-ID: 463d72cc-3062-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747185908; x=1747790708; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=JvxSME2PLVEYKGQKI5yGFrhFicWhDX3z+Va4hheB/M4=;
        b=WTX4WyULP/RzS8856V1pwxtdVblBNIFbk4zvDYKSirrOuh3hfv8bM08gd4Acd73aBK
         a+cqarjQy6Ej/3BS2yOZbE18uK1iD/v6bZtO1L5pVB4hWbY5inAwnCXtWi/Ee5xNp3co
         k0KP79pKlAcGn3m6sLJh73dUywqHBMQTxkMeUyV9eU4y8omAkKFb0Mhf5RtonfG2hp83
         XhUnQjFw708xD307WUtAeMvA0vYbKxOlU6RuHJ4hYksMX5oa1kpEgdHQT1AYGT0ExszU
         SlHnkAXuJid6tmY6WaPmbmUujcxfSdJbHXOk25rihyuFL1MTpACodNeNNLMwlmU0oY+E
         BxsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747185908; x=1747790708;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=JvxSME2PLVEYKGQKI5yGFrhFicWhDX3z+Va4hheB/M4=;
        b=DQrh6QPkKy9J9FSmVSzlatIyMg71WC2r3Wu1iGs/m0zcsYRBZJY5V9gufdEBEw85gg
         cZLONc7ouNSiKVt/z9NLiqRQN1YYJt+LX7gLSp3pxfxuQfNluVxO/iVzSjugLy/oMkSc
         ywMBDphvhqzHu7l75AWJceXfO30Dc+HkK9++XIujX+MOU7OHyusKaFBLdickQNiiVKyP
         I9/a8zNPYTZF4tyqDrsGwA+Q6bTX6NC0Sml1yO2DXD7QBw0xtT+2UVMKBNhW16wMBYe1
         G2iDPB0hy3vzFpRHnGhW9WAown0wcNaxIzwILgrcz7A8Ba7LZ69CtCG9LOipi4IL3rhm
         i7iw==
X-Forwarded-Encrypted: i=1; AJvYcCVnjxijZ6mbP/UTvKEK77quHDx5Qinh1Ye+nhmkMborCegKSSwsYucTUy5pIiMskXRvwFOFIzQRWoU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy8adcZ9dIdeDinsOBiPD3l3QsnHF1PagY1201/bVYNFsjq3q4b
	olUFBlNKyrT9mfNiv5WrOs+2yUweKO2nRkN1a7K5qkstkN90ZnwY
X-Gm-Gg: ASbGncvh+jMRTzxFHq77q28PEjs7I9YnOyQHwOB+HrCHCG13iWSnMXgku1Zv9Zv4R9Q
	+7bSX74Xj01m8YREtPGAlceOG40UBZqGLEZKrhRUfWiSpF+7zYHQYcADCfTAalG0n1Uych/6dXv
	SuYdcFKbWgAwE/SuPohNjXbM8T+90pX2lyZd6EFWCD0hbxiPpQWnQsn5jNcBxVZFlw7Cyk6Knlm
	VvoeEKRg98gLrBUP9f5z30X4C6O73w/zc/vDy3mmxyzOj1iRe4CWi1IldjIoFTB6+d30vtbrV5R
	aERXMcrHWdRWRRwTB9hVOOBSB9d86AH8unc3/8G5bFR7AX65dFtgcLuLqkUcXOMpvw==
X-Google-Smtp-Source: AGHT+IFnzj5iwWzsOE1flw/JuYlln258hVRcvOzMA9GopZSZdETHoAqmsQYPBjTQGf/XhoLQC9tmDg==
X-Received: by 2002:a05:690c:6a06:b0:700:a988:59dc with SMTP id 00721157ae682-70c7f24118fmr26828657b3.31.1747185908615;
        Tue, 13 May 2025 18:25:08 -0700 (PDT)
Message-ID: <68e5f8bb-42b2-4da8-86ba-231cb5657106@gmail.com>
Date: Tue, 13 May 2025 21:25:44 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/22] x86/slaunch: support EFI boot
To: Sergii Dmytruk , 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 ,
 Nicola Vetrini ,
 Doug Goldstein ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Ross Philipson
 , trenchboot-devel@googlegroups.com
References: 
 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------pYXbs1z3VRTy2GEqUxlVL19v"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------pYXbs1z3VRTy2GEqUxlVL19v
Content-Type: multipart/mixed; boundary="------------Z0sWh0qO2c8z5LOyHY2GWblm";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Sergii Dmytruk , 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 ,
 Nicola Vetrini ,
 Doug Goldstein ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Ross Philipson
 , trenchboot-devel@googlegroups.com
Message-ID: <68e5f8bb-42b2-4da8-86ba-231cb5657106@gmail.com>
Subject: Re: [PATCH v2 20/22] x86/slaunch: support EFI boot
References: 
 
In-Reply-To: 
Autocrypt-Gossip: addr=marmarek@invisiblethingslab.com; keydata=
 xsBNBE5j9EwBCACbYHjxDrxFAY3n1x9KBFvjzkG1qFSTVBnH4vpD/5Na4sZq4uDDMUCjivrm
 MzbWYaivYj96BygdOiw7PWxYrhuW0b2WYOeGudZyApgFz42g458s78EciuhgfuWBlxr8dOEN
 /9ueVFHcvtZmDbHhMVPcQ0O7gwh0JmwkOsf7P7WAfYXsQlhO/EBRrNXR0Je+GEpYADhRktxX
 h1d3Iz+oKYuwHioLX8ovoAT4+peOuecWUSpUWebpDbTR5i7NRP3PIblB4KzWJa2kh/f3mx4v
 SRGnHn+BfX42xSe0X7Ktl4Xf+KNq9Wkcjk2CZP57hV2v4pO0ZUOXD7IhlZtnfNj67WjdABEB
 AAHNPU1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSA8bWFybWFyZWtAaW52aXNpYmxldGhp
 bmdzbGFiLmNvbT7CwHoEEwEIACQCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFAll+l7cC
 GQEACgkQ24/THMrX1yw6kAgAiKiUhzAPXZj5ndqiQDl8u8PUK34SupLzYNMJOCBw5Wh+CPHe
 XYlQUwfULWxmzjiWCzzWDx2X/ONsYdRGKDKMqG5srOSWe1IYXv00MEutGsK+m/hmC5mqi/97
 DVNZ1VtKj5WW79IsI0/7ueHsQYNNrXyOfZvKsRE8VIUJ0tNfLFDFlNpq9jONuF+GviMWxrA5
 FoVaGmjh63xC0fOQYqhP2v8dbYS4B6bO5NZKI2cTHb9Li2iY0e7wIoNgvqgtR3Iv2U2Ry0yL
 D3mNQhwyxcWChexlymjfqLEZwKqaIOo57HOpt7OA+bMg6MvkdUTjNWf2GE6fqCcALjcToJ3L
 NDc1KM7ATQROY/RMAQgAtRWgUZ5mOy+c/qzmiVnxqDkiOJjmnIh3Pn+OqCtjcrTyPI9eVc06
 uH30Jkco0soLiG/UgwVw4XwBlm95j9n6TSUms4mPBh1YiR1hBjsjYwn8zp/Ue9xWk1N6E14H
 aj55GxmS2H3YIlOXfQLr0X3RHsmKixTOKyisrYlJu71FmettDFV7CgMXy1Bc1LbAE08asvAS
 ShHFdRiRRtkuVHvY/Ebq9L54kOxtlI6ahrflMcT0YCMON5oe4GgQRh3p2uy+d/LS2bgRcQST
 IebErj8x0lM271f97GvxV/ypHo7XVIDI5FX1u31Agzx3HQr035GHt4HV4/GVCz+V4xt4BonB
 tQARAQABwsBfBBgBAgAJBQJOY/RMAhsMAAoJENuP0xzK19cs5MgH/jWLXil2Ud4TdtWnBxc+
 2/QZZk2JCssc1PgWNzvH5wH7U+8lGSlUK8ZMOqrrF8C5rX0+xEn7deSrsZChIOnUFo8rhCZK
 y/mBV+FhkMj24FZZ0n8w3eF4KF2t68Pt+AvMjxQHwxAMdf3QftgQhD0qYkt/28eedUQ+jwz6
 kipc4qUQmqTEViQRPa3WAnKgNDQUDUwNruzthfGvHUjllf7zbPI8gkbARM0KlTkLikc9u+Ni
 VMbJTiGPB7YHyw2MIPq1n+mhSPAyXE6CVBnYkonQ7P3SLZssxC3PIarV+DTU68umQB3pfrfF
 7hMcAY5csWrK9/x/Zz4RUfgN6Q3HLrSp9UQ=

--------------Z0sWh0qO2c8z5LOyHY2GWblm
Content-Type: multipart/mixed; boundary="------------f0uyXPbVtOSvT6xFgvn95eIW"

--------------f0uyXPbVtOSvT6xFgvn95eIW
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/13/25 1:05 PM, Sergii Dmytruk wrote:
> When running on an EFI-enabled system, Xen needs to have access to Boot=

> Services in order to initialize itself properly and reach a state in
> which a dom0 kernel can operate without issues.
>=20
> This means that DRTM must be started in the middle of Xen's
> initialization process.  This effect is achieved via a callback into
> bootloader (GRUB) which is responsible for initiating DRTM and
> continuing Xen's initialization process.  The latter is done by
> branching in Slaunch entry point on a flag to switch back into long mod=
e
> before calling the same function which Xen would execute as the next
> step without DRTM.

Depending on the bootloader for this unnecessarily ties DRTM to GRUB.
Instead, it would be much better for Xen to be able to perform DRTM
itself, which would allow DRTM to work without GRUB.  Pop! OS already
uses systemd-boot and the trend seems to be from GRUB to systemd-boot.
Furthermore, this would allow DRTM with Xen launched directly from
the UEFI firmware.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------f0uyXPbVtOSvT6xFgvn95eIW
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------f0uyXPbVtOSvT6xFgvn95eIW--

--------------Z0sWh0qO2c8z5LOyHY2GWblm--

--------------pYXbs1z3VRTy2GEqUxlVL19v
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgj8SIACgkQszaHOrMp
8lNEnhAAmrRXMxq5tmmCSNvoVi8oPwIxv1KDJJ2IfBFtIkYqZI+BvhPGA2CVFw4s
QEbQDWAJrABvyHnZ69nqaV9+GIwPqxysjw2SblvdLggw8/A5TFH/fa1LlC+8zMcg
QpK3RZ2utIZmWnDCBrtpA+rMhWklQ7wXVihedM7cMUXagjo7Pcszla41jnJII2v+
Tw6M2bMuAbGdbLC6yaqY6rxeK8QvMIHUkMMcE9xUTE2vRsJK9HDj6Cq6mNIr72+2
EbNKe9KslY3JZjrqcnT07TUI11iwZGTmo0/0aa9VBWbdlG8jMJMqTf5HBKbVlvdB
khyVuRRst0kMWtZWSCCoQyQKFHKchJ+CGUBE/QccL5Cbif3BsJJyZMou0rVqLMUt
eMNURjMiTTovmb8Zgo5ek/nMwV2BKx7mt2ftcITDDShXlLEOBIXxXM4TXnzTyi+h
HAOR092poiwHJ3xVDQqSXpVQYftEMeM7KydmD1EDcxuYYG9i9DbobsqsXv5Iizro
dLUbzAAzxY8Ttk2Dl9RZG0a8K5wQixUVg41MYmJuZezUMjFpKM0rOLcTOu5UCYSt
YvRcYRvGe/XZCoo31xdyBpHLEtDFUPvmIxWdhTC2ijb9h8BvqIsR6BLJt+hZOcyY
hLc9oTNHO2wZruQLLEt03y2GsI0jKAqOFgymUfohhWb1AuO10fg=
=7tp3
-----END PGP SIGNATURE-----

--------------pYXbs1z3VRTy2GEqUxlVL19v--


From xen-devel-bounces@lists.xenproject.org Wed May 14 02:46:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 02:46:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983714.1369922 (Exim 4.92)
	(envelope-from )
	id 1uF28N-00005W-5l; Wed, 14 May 2025 02:46:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983714.1369922; Wed, 14 May 2025 02: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 1uF28N-00005N-1O; Wed, 14 May 2025 02:46:15 +0000
Received: by outflank-mailman (input) for mailman id 983714;
 Wed, 14 May 2025 02:46:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF28K-00005G-TO
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 02:46:13 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20617.outbound.protection.outlook.com
 [2a01:111:f403:2417::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 96ea1076-306d-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 04:46:10 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 PH7PR12MB6667.namprd12.prod.outlook.com (2603:10b6:510:1a9::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.29; Wed, 14 May
 2025 02:46:05 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.8722.027; Wed, 14 May 2025
 02: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" 
X-Inumbo-ID: 96ea1076-306d-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Y7j+DuSbhq/RYIAALY9ibgh3R89ttu9LSclDlkFwhzCD/s3fC3eFFPLWRuWK4usCej0XEHSdkBud0U/BrZm373WBBMAqzOVd7c0F3jFDV7PiPA5kexMa2qa8TQttUAHVd3wUYy4PukaT+KLibD5Ves4JaYwU+e0VVRyVnfynWdYEP6FJhmfwpSHatf3gYY+6B1E/gEj+FkZTREtp/14Z6asn1Ep3sp1EY9jLssvhjniOzRlhZWd5t1XXmukvmT/QmU4+CVp6t/kQCrqNR1KFhg1I56aoyreyc9xLCeuUsE84qMyuYxTGm926e0CRpnYHpPv46PDzs6DwAV2aKdMU8Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RFyHfXkgoGtX6uQDPfT80OBoYCcwhwVaK7GSHcOxXI0=;
 b=jpOykjvLpuuaI4OnjHXdDJL1bE1xnwqN9rIY6nrOUhPzK/BulnGmeuVTOeie62v+7GfKShhVwwkjQj1BvA0CpPSmnU52YQFT2g25N/zxRxJQCF687MRYtDsJX/7OjYaJr1LxKGkjazXZZmjG81V9A7JoDXkyg5GnVs/oW+v0bLOVIACerFIPn379RV+Hyph7oEIaWPaGknEXyaaYPf3nWGCwJY4S4H6HRYyRtcz7m4/EYNXuuAuKQacOIDD0nd1tA1g0q6g2E9RgE//vkceIJHjfbzNXY+YJUBDAqzuoFf1WaqrmKOaTRDP1q7CEHWkkSK68/XmCRRUSGA5MnTlciA==
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=RFyHfXkgoGtX6uQDPfT80OBoYCcwhwVaK7GSHcOxXI0=;
 b=Zv9pqXo9IcH8NZPuQh/tWqEKU2FJnvand6B6Kf1cMynJ8fybNOtBzz4Qzo8qv0hUMWc5gRlKNpqL8EDwhqBbV0JqSlV/grgEfs5lmmbSjzv3JsO8i8waK4JxYC3MuQBlf+k0kadc0/zSZn2uxMmvF7qv1J9tbW8caqp+8Kjupwk=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Topic: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Index: AQHbrRCjQUXzVZg75kKZW3IeVU/v2LO5SzoAgAvud1CAChU8gIACS2EQ
Date: Wed, 14 May 2025 02:46:05 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-3-Penny.Zheng@amd.com>
 <829e710d-d257-455a-b4fc-1746119609ef@suse.com>
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=fdb35494-bfc1-4161-a69b-d10dbde4ffff;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-14T02:45:57Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|PH7PR12MB6667:EE_
x-ms-office365-filtering-correlation-id: e63ada86-03d7-4638-dabb-08dd9291792b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?bnhoWWRMZFRqaFUzUlNLMFdKVWR0ZnVQUG9na3p6bFVGTjdnbU9CamJONTB4?=
 =?utf-8?B?ZjNid29nL1Q1QjgzVjl6cEIxU1hjTjdGUXFYMHc4RnJabUwyNU1ZOHl2K2VS?=
 =?utf-8?B?RHJ1c1d1QkdhZHhCd2k5Mmt0SDU2WVh3bE9HZkYvVC9uejNYdlNrWmhaTy9h?=
 =?utf-8?B?eGxvcFFOUTJCL2JqU2dmcUFPcGc3cDdQTDhhQjBDSGJ2V294Q1B5NU81VnJE?=
 =?utf-8?B?aDV4SGthZ1dPMkJsVzUzR29GOTNwVUpBZHcwMWtQcHdaekY4aWhkK0tjdG9W?=
 =?utf-8?B?eVRSYnlzUGcyNHFNZUZjdFBoSUZzNjY0V0ZkZUdLY0oxNmdzVnczOWlMa05D?=
 =?utf-8?B?QXRYbkVZa08vSGRXZEg4K0JpakdSQmRFN2JLQ0Q3UmRZK1lWVjRoVWVYTVB5?=
 =?utf-8?B?QVh4ZDBnQ2NFUFoxRHJVbFRGYU50bWV2Mm5OV21iK3d1WDk1UHFRM3dpa2Vk?=
 =?utf-8?B?cXU5ZVNwNFFmUFJTcUwvNmtKMjQ4Rkl5MG85N2NxaTVYZnZudEtHSFdPZHJQ?=
 =?utf-8?B?NUN4eGd1d1kxUHM4M1lDeHpIeDhGblVYUDc1NXdRd0Z1enhGc1dLbDMzRWxG?=
 =?utf-8?B?Z1JGdzc1QWZuWS9zQ1VNdFhybWJWb1VYaVc2MlVLSFlzaDl0Mmc0MDFaV2lI?=
 =?utf-8?B?aGtOL2l2WEVYaUdmTC9HMnI1Q20vbHQvTXlpL2liaGIxbDZqdW1KMlZuSmNN?=
 =?utf-8?B?Ynd4K1VQOFlZSEkyS3JzYTIrcWxqNzJxZFhZMzF5Z1VBUDM4VzJWeEZHN1Ji?=
 =?utf-8?B?eFVnWi83MzBESS9TUFNzZmhTaVNBWlFFQittYmdsc2N1WHZPd0YzQWtDUFlX?=
 =?utf-8?B?VjdqWUhqTWxmR0RpSU1UZ091OGRSeTRpaUpUUEdTN1g1U3ozbGtFVUVEY0V6?=
 =?utf-8?B?OVlyNU50TytvcnpaM2FxU1hwS0JsTHloMHZCNDF5MTNsOVlaK1RjWnp6c2hH?=
 =?utf-8?B?WmtDTmUrakd5UnE0T0JyM01MWDNmTU1JRXFreVJrZFdjYUF5RS9Nd3ZDT3JZ?=
 =?utf-8?B?bGNlVnVFSldJNnRyS3NnVWtxbUZtZ0h6RGl2SmFDY01wS2xxbmtjaEY2YURR?=
 =?utf-8?B?K0J1L0dURDdQNVFJc1JxSzBZQjBwMHJzNWdqNUdUUEErQVhHMzNUelJaYjd0?=
 =?utf-8?B?a1p2QlBwNFhRY21PR1MySkNCbEJmR0prVHY0Z2lVVUg2dW1ncm1KeVNxZEZl?=
 =?utf-8?B?Q0hCRi9QL1JWTWVwcFd0VXhtNkpjVEVhTTBOWVNJQ1Z6V1krMXhTZk5PSkwy?=
 =?utf-8?B?b1FQQVArWVE0MnRvaG04S1JCa3ltYjA1RmNMKzFkbU5zOHoxak1Ib1NpSHZh?=
 =?utf-8?B?Q1labFBubUVqVWRsZU8wSzJVbWk3dzJMVVhScTNsSVhUem5TTkJBQVNKVzU5?=
 =?utf-8?B?cnVjRC9GSm1yVU5HSVNVLzcxR0JvOXRvUU9IN1VWQllWTE52MXdjcXhxaWJh?=
 =?utf-8?B?aVRIYzNpdCthUE80SVFRZGtzL1VLTmVlbTAxRmYrRmRZcDZKd3FUS1NLYWxQ?=
 =?utf-8?B?NTRjT0sySGc1YXl2Vk44aFFhWU80SjNrMHhhRmNyL3M2UDZXUEZ3TkthS2o1?=
 =?utf-8?B?Y0hnbVhPUzRYZ1lYZWRXWUhCVUtNaXhSYkt5VDZJYXZXVlVWditJajhZYTFy?=
 =?utf-8?B?VytEMG1wM0UxVEwvZHJRd0t2R0JzNW5SMHZQS055Tll0a0I0M2pYT2pwWGwy?=
 =?utf-8?B?bXR2UGVrMGlWNkYvUkJ3bHZXZmN1REp5Y2UwbDQwNkNqODAzVisyZHBFNTFk?=
 =?utf-8?B?bStSb3gxZjRoN29GRHZGZzQ4YmE5MkhpRG1wbFR2QnVoVW85OGFxWFVna25t?=
 =?utf-8?B?Qm9McVFTRmhuZVVncDVlYXd0c0Y2NlA0T1dBYmVhczQ5ZHkrVWRhOTZvcmkx?=
 =?utf-8?B?dDRRWkV0djRLWE9OTWJ0UzZtUzVsUXRTaVNDdXhNMnk2V3lvQUpLeFRNRGV2?=
 =?utf-8?B?cTUzRGdST0M2T0J3RFBWTU8zYXp0cVZzY1pZY2RUcFNJakZGZ3NMTDZpY1lj?=
 =?utf-8?Q?8h42+pe40hGfEDuDbiehpt3RXq1zXc=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?ekxxaFFQaERUdU96NSs0VUVFUTlIczJoVERXWlM4bmZJQVlXWHU3eEFQSWJ3?=
 =?utf-8?B?Y0MwWnJjRVNSOEpvS3BxTHh0QmNCOHMvL1hVZjZTbVBCQ0xHZWlwdE1vT1ls?=
 =?utf-8?B?MHBhRDA3NWNuR3lESmhYK0dHd1Z2UVJaaW5waVM1R3UxN1dHeGFsdjhDSzJI?=
 =?utf-8?B?L1VOdFF3M1NKb3RXd2RuVzRrb0JmdHNJRTdtQ3p1Ny90NUNwZDBhL3lkQXoy?=
 =?utf-8?B?c3E1NEZEK3V0WFFETGRucWtUU1E0YXNWVzd0alBhRms1YTFSYXBMOC9nMXNw?=
 =?utf-8?B?SVFSaEx4MWZ6OXk2dEdoTWRkdzFRK2szaktzcFo0NThDNHZVNGtRNmlqenBp?=
 =?utf-8?B?dFFaNVQ1UFB5c3FzUEtzK29qT1RKbFpNeU1FbWlJTldqa0VnMUN0dmJvdisz?=
 =?utf-8?B?UjJJMmI5eVNZcHUwb01XVVZYdFhJSlNFaEl4QVN1enh6bWZOcm5IUFMwS3pv?=
 =?utf-8?B?d0UyYWFzUDFpdXlPWVYyOVYwK3owWUpUM2MxbUJyUGJhNFRuWHBSR3RBbGVl?=
 =?utf-8?B?RnZLWk1WTEZpcklCS1FManRGdjNpckhaZHVJc0xHdU9TcHVaRDFSd3hqTkhm?=
 =?utf-8?B?Z2NqbklESm9iTzRURVluT2hVTU5JamRSbXRLU1ZjUHRJN09MM2lLLzVNRjB3?=
 =?utf-8?B?VXp4SS90MFVzU09lUFdEaERjaElYNTdoOWR0ZDVOZFRySVd5N3N1S21kanR3?=
 =?utf-8?B?MWhhZUE5QjBBOFY5bFZleFoyOFU0eWxQUW1FS0FldGtienptZFkxL2U2VnNN?=
 =?utf-8?B?RDl1ck5NM0FBQjFpU214TllseGhpa3F3bXdPam9zQ0hvOTREd0xaaFhhSFZl?=
 =?utf-8?B?TzAzMjFtMElXVUs4dk5leDRpQWI5M3ppa3JYcFRCQmgwNzlJSzlJZHZ6UHQx?=
 =?utf-8?B?eVFZTllVNUVKZWYwbU1IWU5KT1BJNDJpNVBEVUdtdEZhUUVIWU9pK3pya0lN?=
 =?utf-8?B?YlNHcGozcU9Sc2Y1eTd4aWlNdVVQZ1RzejJMTFVKT01LaG1TQVp1WDFyeVBQ?=
 =?utf-8?B?NU5JeXdMU1V5YWxab2t4R3FyTGM2bXRwRXdsUjV3cUswRXF3dTJ5TVIrWDFn?=
 =?utf-8?B?YklmQThpenBBTld2aUFLdW0wOC9PN3NBTk5NblprTU1tdmhKeGRVYmRXTkJQ?=
 =?utf-8?B?bGd6VUVwWlM1SU5Va0NKUHdHbDk4aTVUWnZlMHdJVzUrK1VUVjlQVFk3NGNZ?=
 =?utf-8?B?dmxYNFFVb2ZRUnFoMTZ3elVEeU1qWEJZTW9hWTVIYVgweWNScVZzWDBHUVQz?=
 =?utf-8?B?S0RDZDRKeHlBdHhsbE9OaVZ6OUlKaHpEb2ZXSlJyUFJoVXZuZDR2eHVobTlG?=
 =?utf-8?B?YUoxWlg1cVhHeGRNWFBjRFg5Wi9lb2pQby9HNkRuYzZ3RTFiMkhwT2s4QUpM?=
 =?utf-8?B?cTNncWpsYkR4bEdQeVNQUmUzMEZmNFpRTG93MDNpRzdILzZIYWZhbWF6QUFw?=
 =?utf-8?B?QXh3Z1RUaUxGRXpKd3FuQTQ1VVl5ZVo2enVhcUxjbEkyalFKMmozM3V3VHpl?=
 =?utf-8?B?QjZMakhQQWlTakZPYmhLSVBHM3NUUE4yY2VHd0M1bi9lQVRqSGtQV1VsbnNY?=
 =?utf-8?B?SDZ0ZWdCSTdlSHlxRTVqRUw3bi9PU2xrZ3RRdnJrSHp5cXUyWFZjN0pyS2JF?=
 =?utf-8?B?RFNSaXF6a2IwNkJQNmcrU01sMGxITXZIak5mT3ZlMXRndmVMend4WjFDUDBC?=
 =?utf-8?B?SHVCT3NnOWdqM3M4ZTl2VWFWbUowR25MVWU5cUh6cVNNRHM2ajlwT2xldEZm?=
 =?utf-8?B?SktkVzQ2MFA0MlYzN1hOcVFkRzFQeHR1aFJEVmJ2bllEcEtic0d6OFh6M3Fn?=
 =?utf-8?B?RUNRRjdmc0E3L3pqNmhlR2FzV0tWb0cyOHVEZ3E0YmRLcysrRlhvT0xjUllw?=
 =?utf-8?B?Z2JmcDgweHVrRE8xVWFhbUZZVU5XT0lDWDM2TVV2RW03US9qS0ZpNm0xbHVh?=
 =?utf-8?B?T3FUMCtFbE9QM1Z4cHV4MFFsOHh1a2tKSE81VXBiZllhaUpBZUtrR2ZJcDVS?=
 =?utf-8?B?OE1Hd1FvVW5hVSs1dHRpV1p2US9RTElCL05jMmt2WHFhTzBldzFDY2V5Ri9K?=
 =?utf-8?B?M2V1U3VSa1lqaSs0bjl1b1FCTDRXQ3IvaE5od3pkVXUzMUJwK2dpN09vOW5t?=
 =?utf-8?Q?wXqw=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e63ada86-03d7-4638-dabb-08dd9291792b
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2025 02:46:05.7250
 (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: SbAMszDFO/9WyV6deTVOhpAMnQXE7bwoPZ/srDMb8pn8ptrVDUsbTC1UlsKOV0lQgmjJyDGwyyZ5nfoNoCzhWA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6667

W1B1YmxpY10NCg0KSGkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBK
YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IE1vbmRheSwgTWF5IDEyLCAy
MDI1IDExOjQzIFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+
IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4gPGFu
ZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJhcmRA
dmF0ZXMudGVjaD47DQo+IE9yemVsLCBNaWNoYWwgPE1pY2hhbC5PcnplbEBhbWQuY29tPjsgSnVs
aWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2VyIFBhdQ0KPiBNb25uw6kgPHJvZ2VyLnBh
dUBjaXRyaXguY29tPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3Jn
PjsgeGVuLQ0KPiBkZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BB
VENIIHY0IDAyLzE1XSB4ZW4vY3B1ZnJlcTogZXh0cmFjdCBfUFNEIGluZm8gZnJvbSAic3RydWN0
DQo+IHhlbl9wcm9jZXNzb3JfcGVyZm9ybWFuY2UiDQo+DQo+IE9uIDA2LjA1LjIwMjUgMDc6NTYs
IFBlbm55LCBaaGVuZyB3cm90ZToNCj4gPiBbUHVibGljXQ0KPiA+DQo+ID4gSGksDQo+ID4NCj4g
Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogSmFuIEJldWxpY2ggPGpi
ZXVsaWNoQHN1c2UuY29tPg0KPiA+PiBTZW50OiBNb25kYXksIEFwcmlsIDI4LCAyMDI1IDExOjMy
IFBNDQo+ID4+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+ID4+IENj
OiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4gPj4gPGFu
ZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRA0KPiA+PiA8YW50aG9ueS5w
ZXJhcmRAdmF0ZXMudGVjaD47IE9yemVsLCBNaWNoYWwgPE1pY2hhbC5PcnplbEBhbWQuY29tPjsN
Cj4gPj4gSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2VyIFBhdSBNb25uw6kNCj4g
Pj4gPHJvZ2VyLnBhdUBjaXRyaXguY29tPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGlu
aUBrZXJuZWwub3JnPjsNCj4gPj4geGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+ID4+
IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjQgMDIvMTVdIHhlbi9jcHVmcmVxOiBleHRyYWN0IF9QU0Qg
aW5mbyBmcm9tDQo+ID4+ICJzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9wZXJmb3JtYW5jZSINCj4gPj4N
Cj4gPj4gT24gMTQuMDQuMjAyNSAwOTo0MCwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4+PiAtLS0g
YS94ZW4vaW5jbHVkZS9wdWJsaWMvcGxhdGZvcm0uaA0KPiA+Pj4gKysrIGIveGVuL2luY2x1ZGUv
cHVibGljL3BsYXRmb3JtLmgNCj4gPj4+IEBAIC00NDAsNiArNDQwLDExIEBAIHN0cnVjdCB4ZW5f
cHNkX3BhY2thZ2Ugew0KPiA+Pj4gICAgICB1aW50NjRfdCBudW1fcHJvY2Vzc29yczsNCj4gPj4+
ICB9Ow0KPiA+Pj4NCj4gPj4+ICsvKiBDb29yZGluYXRpb24gdHlwZSB2YWx1ZSAqLw0KPiA+Pj4g
KyNkZWZpbmUgWEVOX0NQVVBFUkZfU0hBUkVEX1RZUEVfSFcgICAxIC8qIEhXIGRvZXMgbmVlZGVk
DQo+ID4+IGNvb3JkaW5hdGlvbiAqLw0KPiA+Pj4gKyNkZWZpbmUgWEVOX0NQVVBFUkZfU0hBUkVE
X1RZUEVfQUxMICAyIC8qIEFsbCBkZXBlbmRlbnQgQ1BVcw0KPiA+PiBzaG91bGQNCj4gPj4+ICtz
ZXQgZnJlcSAqLyAjZGVmaW5lIFhFTl9DUFVQRVJGX1NIQVJFRF9UWVBFX0FOWSAgMyAvKiBGcmVx
IGNhbiBiZQ0KPiA+PiBzZXQNCj4gPj4+ICtmcm9tIGFueSBkZXBlbmRlbnQgQ1BVICovDQo+ID4+
PiArDQo+ID4+PiAgc3RydWN0IHhlbl9wcm9jZXNzb3JfcGVyZm9ybWFuY2Ugew0KPiA+Pj4gICAg
ICB1aW50MzJfdCBmbGFnczsgICAgIC8qIGZsYWcgZm9yIFB4IHN1YiBpbmZvIHR5cGUgKi8NCj4g
Pj4+ICAgICAgdWludDMyX3QgcGxhdGZvcm1fbGltaXQ7ICAvKiBQbGF0Zm9ybSBsaW1pdGF0aW9u
IG9uIGZyZXEgdXNhZ2UNCj4gPj4+ICovIEBAIC00NDksMTAgKzQ1NCw3IEBAIHN0cnVjdCB4ZW5f
cHJvY2Vzc29yX3BlcmZvcm1hbmNlIHsNCj4gPj4+ICAgICAgWEVOX0dVRVNUX0hBTkRMRSh4ZW5f
cHJvY2Vzc29yX3B4X3QpIHN0YXRlczsNCj4gPj4+ICAgICAgc3RydWN0IHhlbl9wc2RfcGFja2Fn
ZSBkb21haW5faW5mbzsNCj4gPj4+ICAgICAgLyogQ29vcmRpbmF0aW9uIHR5cGUgb2YgdGhpcyBw
cm9jZXNzb3IgKi8NCj4gPj4+IC0jZGVmaW5lIFhFTl9DUFVQRVJGX1NIQVJFRF9UWVBFX0hXICAg
MSAvKiBIVyBkb2VzIG5lZWRlZA0KPiA+PiBjb29yZGluYXRpb24gKi8NCj4gPj4+IC0jZGVmaW5l
IFhFTl9DUFVQRVJGX1NIQVJFRF9UWVBFX0FMTCAgMiAvKiBBbGwgZGVwZW5kZW50IENQVXMNCj4g
Pj4gc2hvdWxkDQo+ID4+PiBzZXQgZnJlcSAqLyAtI2RlZmluZSBYRU5fQ1BVUEVSRl9TSEFSRURf
VFlQRV9BTlkgIDMgLyogRnJlcSBjYW4gYmUNCj4gPj4+IHNldA0KPiA+PiBmcm9tIGFueSBkZXBl
bmRlbnQgQ1BVICovDQo+ID4+PiAtICAgIHVpbnQzMl90IHNoYXJlZF90eXBlOw0KPiA+Pj4gKyAg
ICB1aW50MzJfdCBzaGFyZWRfdHlwZTsgLyogWEVOX0NQVVBFUkZfU0hBUkVEX1RZUEVfeHh4ICov
DQo+ID4+PiAgfTsNCj4gPj4+ICB0eXBlZGVmIHN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1h
bmNlDQo+ID4+PiB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlX3Q7DQo+ID4+PiBERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRSh4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlX3QpOw0KPiA+Pg0KPiA+PiBX
aGF0J3MgdGhpcyBtb3ZlbWVudCBhYm91dD8gSW4gdGhlIHB1YmxpYyBpbnRlcmZhY2Ugbm90aGlu
ZyBjaGFuZ2VzPw0KPiA+DQo+ID4gQXMgd2Ugd2lsbCBoYXZlIHNoYXJlZCB0eXBlIGluICJzdHJ1
Y3QgeGVuX3Byb2Nlc3Nvcl9jcHBjIiB0b28sIG1heWJlDQo+ID4gdGhlIGRlZmluaXRpb24gd291
bGQgbGlrZSB0byBsaXZlIGF0IG1vcmUgY29tbW9uIHBsYWNlLCB0aGVuIGl0IGNvdWxkIGJlIHNo
YXJlZD8NCj4gPiBMaXZpbmcgaW5zaWRlICJzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9wZXJmb3JtYW5j
ZSIgbG9va3MgbGlrZSBpbnRlcm5hbCB2YWx1ZXMgZm9yDQo+IGludGVybmFsIGZpZWxkLg0KPiA+
IElmIGl0IGJyZWFrcyB0aGUgcHVibGljIGludGVyZmFjZSBzb21lIHdheSwgSSdsbCBjaGFuZ2Ug
aXQgYmFjayBhbmQNCj4gPiBkdXBsaWNhdGUgdGhlIGRlZmluaXRpb24gaW4gInN0cnVjdCB4ZW5f
cHJvY2Vzc29yX2NwcGMiIHRvbw0KPg0KPiBJIGRvbid0IHRoaW5rIGl0IHdvdWxkIGJyZWFrIGFu
eXRoaW5nLCBidXQgSSBhbHNvIGRvbid0IHNlZSBhbnkgbmVlZCBmb3IgdGhlDQo+IG1vdmVtZW50
LiBBbmQgZ2VuZXJhbGx5IHdlIHByZWZlciB0byBhdm9pZCB1bm5lY2Vzc2FyeSBjb2RlIGNodXJu
Lg0KDQpVbmRlcnN0b29kLCB0aGVuIEknbGwgZGVsZXRlIHRoaXMgY2hhbmdlLg0KDQo+DQo+IEph
bg0K


From xen-devel-bounces@lists.xenproject.org Wed May 14 05:11:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 05:11:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983742.1369930 (Exim 4.92)
	(envelope-from )
	id 1uF4Ow-0000bX-OD; Wed, 14 May 2025 05:11:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983742.1369930; Wed, 14 May 2025 05:11: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 1uF4Ow-0000bQ-LF; Wed, 14 May 2025 05:11:30 +0000
Received: by outflank-mailman (input) for mailman id 983742;
 Wed, 14 May 2025 05:11:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF4Ov-0000bK-0x
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 05:11:29 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e13a3623-3081-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 07:11:25 +0200 (CEST)
Received: from fmviesa002.fm.intel.com ([10.60.135.142])
 by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 13 May 2025 22:11:23 -0700
Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.124.247.1])
 ([10.124.247.1])
 by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 13 May 2025 22:11:20 -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" 
X-Inumbo-ID: e13a3623-3081-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1747199485; x=1778735485;
  h=message-id:date:mime-version:subject:to:cc:references:
   from:in-reply-to:content-transfer-encoding;
  bh=UNNz5FIvJ/cXIxaiZEfi5bWCBZhv2ZCY4UIp4PhuOTU=;
  b=P0DPscn/PNCS3PSA7ljNjYDlXnQbQKfkhWi3b7kdc1swEMWoFI/wVpkw
   J8oGDqgDp6e8E6x0uZ/apsEFHhBLmP9gOr4OkglierICBdMV56KZJbvC/
   raCz6KTmt+FZjibJzJ0g9UOr/reC+ZElqw/kEML7f+YMlAajuo7JmQYGH
   wASgj0RjA91Euwfw0YFdE9689QkDQyLbxED9Rf4EAyEqyQyndO8C08q3y
   A4vCy0DlJxJI0Z+Y9Xdn5yxpgiEbY/pgJhaZq7kXbq5BmSOjwUsxX69oM
   frDbjAyAonXANfd6Scc4Zx+fbSpnAziTsOtqApLgezJZDC7wRSFguopcN
   g==;
X-CSE-ConnectionGUID: ujqEeHr4Rc+qECGRqw7eZQ==
X-CSE-MsgGUID: E6wUJWGsTN2g3v2Mm6O21A==
X-IronPort-AV: E=McAfee;i="6700,10204,11432"; a="74477111"
X-IronPort-AV: E=Sophos;i="6.15,287,1739865600"; 
   d="scan'208";a="74477111"
X-CSE-ConnectionGUID: JIMf2Mp5SKqc1Xeo6bCBcw==
X-CSE-MsgGUID: oRVSeXRaSpWBlNMRE3ptkA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.15,287,1739865600"; 
   d="scan'208";a="161221528"
Message-ID: 
Date: Wed, 14 May 2025 13:11:17 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] hw/xen/arch_hvm: Unify x86 and ARM variants
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org
Cc: Richard Henderson ,
 xen-devel@lists.xenproject.org, Anthony PERARD ,
 David Woodhouse ,
 "Edgar E. Iglesias" , qemu-arm@nongnu.org,
 Stefano Stabellini , Paul Durrant ,
 Pierrick Bouvier ,
 Peter Maydell 
References: <20250513171737.74386-1-philmd@linaro.org>
Content-Language: en-US
From: Xiaoyao Li 
In-Reply-To: <20250513171737.74386-1-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5/14/2025 1:17 AM, Philippe Mathieu-Daudé wrote:
> As each target declares the same prototypes, we can
> use a single header, removing the TARGET_XXX uses.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
...
> diff --git a/hw/arm/xen-pvh.c b/hw/arm/xen-pvh.c
> index 4b26bcff7a5..1a9eeb01c8e 100644
> --- a/hw/arm/xen-pvh.c
> +++ b/hw/arm/xen-pvh.c
> @@ -10,7 +10,6 @@
>   #include "hw/boards.h"
>   #include "system/system.h"
>   #include "hw/xen/xen-pvh-common.h"
> -#include "hw/xen/arch_hvm.h"
>   
>   #define TYPE_XEN_ARM  MACHINE_TYPE_NAME("xenpvh")
>   

This chunk seems unrelated.


From xen-devel-bounces@lists.xenproject.org Wed May 14 06:15:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 06:15:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983768.1369941 (Exim 4.92)
	(envelope-from )
	id 1uF5P4-0008RV-W2; Wed, 14 May 2025 06:15:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983768.1369941; Wed, 14 May 2025 06:15: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 1uF5P4-0008RO-SQ; Wed, 14 May 2025 06:15:42 +0000
Received: by outflank-mailman (input) for mailman id 983768;
 Wed, 14 May 2025 06:15:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uF5P3-0008RG-FF
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 06:15:41 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d92bcfe8-308a-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 08:15:36 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad24ee085a8so501608466b.0
 for ; Tue, 13 May 2025 23:15: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
 a640c23a62f3a-ad21933beabsm883188666b.43.2025.05.13.23.15.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 23:15: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" 
X-Inumbo-ID: d92bcfe8-308a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747203335; x=1747808135; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AUr3IAkqH2n8JoYNsGUM+Y9zOCesBzE+S64DV/gGzCQ=;
        b=awVKpgHcBR7q9uzZSFzKQdkCAl2HNx9Awn3T/mNORpLdnp4QnVt1hqNa+ABRa/ct/W
         VoFTbhQXRbM0QN2t0MgUw5VYZCsygWILxmhQFtRSA9IvJKM5xtHVhAoJ46T8l//bINwH
         6WeGymXFB8XaOVyu0+XulFs07CvOCVdVXc0HkCy0xrXIKcns60rw3h7UWJWbUomvxc2V
         lL4Rt/VYOTL7w4aaQozZoJdUlz2+h/BOCnhj+WUyp7PgGtLC088L7IwKGCUMbCnq3Ji+
         clEAVYgzEYcoDtBTFbCJTvuEzNfk1cGyeKIn0Mi8uon0Gv9u7IKIbIgTtzugaZpLDt1T
         XhaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747203335; x=1747808135;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AUr3IAkqH2n8JoYNsGUM+Y9zOCesBzE+S64DV/gGzCQ=;
        b=hZEQa2VCcafzXYEQkOXMDL4CHxzhwqNi1r0/PT8D7KT16cyx71DdQOjSBm+4A0VK4j
         uGjUCE28wCq08M4klhrmrB9VjqnRzydlxQFmOPXmfjSmcjQ5ViTeV22xEVs6G4VcF3tt
         4BDmGRSILGOcS7egjqAcpWsYwxzWVE1iDHOretu5w6FJRLCErwjrYNtE6ma5nQZGEfnH
         v6PxalSIXAEWo+mAnnvUc1xjiLY2AnNKR8Wh0KCrozFmsHNTu9Z2a/0OJTZUcUMlocXo
         FaKT4Co35fzM+NJvvIp7MrvlDruChY0ulf8ZTeviYWV3eNrKMKuX6fYtma0by0L+8sWJ
         lsAQ==
X-Forwarded-Encrypted: i=1; AJvYcCWgteFhj2gavUGHz6/4ley4JXV1dVWWIgOCiZPNuUwASuf9pR0Fz2RWKxJetJEk1/nllxEJJawGEcg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyQjdHdd3jFHNXvYTQjJach9EY3A0cgKB5PFW9UBwvx4/HLqVC+
	vq0GcnshyupdspTykA14Rkh+/GYbIbU6L+BNafvnMXQ5pgHTPMImhPD5cfTs+A==
X-Gm-Gg: ASbGnctXe+3JcSvA+iR7DY9wRmgzWdxw+l/N+ZlWqQoAmmXDILu3Xydfmn8UChP9asQ
	hiDZr6TAhoVLw9CSxPVZJqKuYYWT14T2DRcwUz/x9bCGKoa0zRbshenMMhUkKaNAoaKczAktU6x
	hkLl5q/gt3f/InEImIMHxKIchKZHh9uPjjUaSxb51qT97V/qd5Y7TomtZJQryD1hpU1eZjtYd7N
	8nfK+cGvMSsKwe1PKUe3wDvsp7SBsjo+U1YuO9qdKNP/3omnxFUXuZSnjb58v9HNc+Y2e8U7+D1
	bUcPb8BrHDHjv9mOfGUIyVC5Pls58y5Pz9FvxSYY4Mtt0HR5opwbbRrkTDKN9BQjcJtFvaJ5zH+
	DHnQWOEupn6HDJTZzEgc1sefJHpDmaAcrJJp8
X-Google-Smtp-Source: AGHT+IHLQq3kc+NEd4Ac1DoWeP/ZnV0cKzqrDzTgHdPRN/ckr5Y2IVIinBlCpu0FALUGCojQnViaKw==
X-Received: by 2002:a17:907:7f28:b0:acb:7105:61a5 with SMTP id a640c23a62f3a-ad4f723fff4mr191893166b.32.1747203335114;
        Tue, 13 May 2025 23:15:35 -0700 (PDT)
Message-ID: <9f50ac6d-2679-4dc9-8677-0146d5b25f66@suse.com>
Date: Wed, 14 May 2025 08:15:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/6] rangeset: introduce rangeset_subtract
To: Stewart Hildebrand ,
 Stefano Stabellini 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
 <20250508132040.532898-5-stewart.hildebrand@amd.com>
 <46dfb68b-7e94-40a8-9900-883ac899346e@suse.com>
 <914a4bc2-aa18-478f-b175-b89b56beaf3b@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: <914a4bc2-aa18-478f-b175-b89b56beaf3b@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.05.2025 19:01, Stewart Hildebrand wrote:
> On 5/13/25 11:39, Jan Beulich wrote:
>> On 08.05.2025 15:20, Stewart Hildebrand wrote:
>>> --- a/xen/common/rangeset.c
>>> +++ b/xen/common/rangeset.c
>>> @@ -397,6 +397,18 @@ int rangeset_merge(struct rangeset *r1, struct rangeset *r2)
>>>      return rangeset_report_ranges(r2, 0, ~0UL, merge, r1);
>>>  }
>>>  
>>> +static int cf_check subtract(unsigned long s, unsigned long e, void *data)
>>> +{
>>> +    struct rangeset *r = data;
>>> +
>>> +    return rangeset_remove_range(r, s, e);
>>> +}
>>> +
>>> +int rangeset_subtract(struct rangeset *r1, struct rangeset *r2)
>>> +{
>>> +    return rangeset_report_ranges(r2, 0, ~0UL, subtract, r1);
>>> +}
>>
>> I understand this was committed already, but I don't understand why: This
>> introduces a Misra rule 2.1 violation aiui. The rule isn't tagged as clean
>> yet, but it was accepted and hence I thought we would strive towards not
>> introducing new violations. What's the deal?
> 
> The very next patch (also committed) makes use of the function, so the
> series as a whole did not introduce a violation. Our code review
> guidelines still say to organize new independent helper functions into
> logically separate patches [0]. To be clear, and for future reference,
> would your expectation be to squash the introduction of the helper
> function into the patch where it's used?

Well, it's not so much my than Misra's expectation. With a small helper
like the one here folding certainly wouldn't have caused much of a
headache, yet I agree things can be different when the helper is quite
a bit larger; some re-arrangements may be necessary to make in such a
situation. And yes, imo ...

> Perhaps we ought to finally
> update the code review guidelines...
> 
> [0] https://xenbits.xenproject.org/governance/code-review-guide.html

... the guidelines better wouldn't be in conflict with Misra requirements.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 06:31:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 06:31:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983777.1369951 (Exim 4.92)
	(envelope-from )
	id 1uF5eO-0002wz-8V; Wed, 14 May 2025 06:31:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983777.1369951; Wed, 14 May 2025 06: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 1uF5eO-0002ws-4g; Wed, 14 May 2025 06:31:32 +0000
Received: by outflank-mailman (input) for mailman id 983777;
 Wed, 14 May 2025 06:31:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF5eN-0002wk-Ah
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 06:31:31 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20629.outbound.protection.outlook.com
 [2a01:111:f403:240a::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1102a852-308d-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 08:31:29 +0200 (CEST)
Received: from DM4PR12MB5277.namprd12.prod.outlook.com (2603:10b6:5:390::7) by
 SN7PR12MB6864.namprd12.prod.outlook.com (2603:10b6:806:263::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.24; Wed, 14 May
 2025 06:31:25 +0000
Received: from DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e]) by DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e%3]) with mapi id 15.20.8722.027; Wed, 14 May 2025
 06:31: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" 
X-Inumbo-ID: 1102a852-308d-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=B/KWY1YitDAgJxoYQCLc/NzO2DsjGMz7a3YsqKfAUInUJgDx0cqStNwsp/qTeelLTJBgs0zU1z6tI7YIVnLLCPajKb3efULfdw7Tu1zYgSHu9octSQoe7U2YfJ8T7RB6WoBYP4COTuYIDDHaS1zNUoR6eIO0GXGORenQ8XigX1u0qsfV5HgA/+K6Q0BkLtmqwPbgtMnVqPG7uXvvE47TVNpwtmiI6WTwMUsWC/RuAMYWkRtI9BSFaRQo/K9uftKbdmLtdkh7RYh+gh2PAD8W9AqEKqA/V/FceGVLnsmAbvK6nqHm7ElnQXNxQ0PpMjCZXHTiiT+mLypImBQoPwgcxQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=eyqIMwJgjaMMzEfSogplyejUU0rYkesUcAROsLfu/RI=;
 b=fB0hP4ZcAWQemyOmdfHcT0+1rkf3M6v4M7mEmXo235o3TdcNDg5mScmTQbu1MG+XkbNpV8qKlFVj4e9xE+FFTHM1gvM+1JaoiKwGo3oZM81wW0FSwzhEQvzvor6ql2/sVp76pZl+yJwstW77tMGvMoeQU/Lnl7R65r4S6hMLsV0dYFLMPCfshrwR3T2ctBX+Jb+SrZXKsT+im+W/xnU5dtrlfBPgegUr/uu5brOeJAZGHDGNoZnkMg3DmRJPKSfo9lWZCbHHAZrclUL5t6fjNCKk/Piw2o/0T7B1z/iAzCja0rfUXveaLJV+TB+1WkZAwpb+dPOZFtQmDWJO0uQ1Pg==
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=eyqIMwJgjaMMzEfSogplyejUU0rYkesUcAROsLfu/RI=;
 b=CJR009j2/lQo6AzbAEycJTXbAQoaORZt5qKmefRWfdG8XYeRfCqXdgpxRh2Q0Y4Mz11K4Oc0fI5I50/uueTOOZY72rtsjIduyHVR3Qcocd9lP3wf9Hg2ZwPqNdYuyJdWr4+tCIvC3oXTB0gS1IAfKtrCdElEl+UrG8CLpky6+CI=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Wed, 14 May 2025 08:31:21 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation __init
To: Stefano Stabellini ,
 Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org, Julien Grall ,
 Bertrand Marquis 
References: <20250513171810.668370-1-stewart.hildebrand@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0360.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f4::13) To DM4PR12MB5277.namprd12.prod.outlook.com
 (2603:10b6:5:390::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR12MB5277:EE_|SN7PR12MB6864:EE_
X-MS-Office365-Filtering-Correlation-Id: b7c0894f-f58b-49ef-31a9-08dd92b0f344
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RG1kdEVYOGYwM1UzZkFGSmV0SXFWWkJ3NlR6ZkZERld2bG1vTkdxZC9vYjJB?=
 =?utf-8?B?bEVLOGFPRDIvbXhqK3FSa2Uyai9pNTJVZWlJRXh6TzdjNlFDOHlRTWNLU3k4?=
 =?utf-8?B?Qk5kcDFlSWlyc1FCRmJnVGEwSHR2bDZqeEtoRW02OWJoazUzSVEydWt5M3hZ?=
 =?utf-8?B?UVczVEwxSk5RTkEzRU1BQVZpekovSTNqSHRHVFpBK0FBMjgzQUpLM1VkVjF4?=
 =?utf-8?B?Tm5qSEhiSU1LZkVvZTRseVBFRzRZVDZnSEI1YUZCeENEWjNaLzVSSEErRyto?=
 =?utf-8?B?YmJSTEZLN28wTTZHTmNSVTRKTnYvSDUyVi9qZ3ZvTXNFSGlCRVdhb0xvOWgy?=
 =?utf-8?B?SS9WZDVnT3UrT0p2dStBdnVVUGk4bEVCWExSL0NrWVJaOWJEQXNiMmhhclJn?=
 =?utf-8?B?SHJkU1N0WHE3TnhieU42UjcwYmh2Z05seU5GcU1TeWZxdjFaYTZzRXNCWlAy?=
 =?utf-8?B?UnZLK0gweURpN21yblhEenNOZnN4R3hyYTlHY05YMnAvejlrdE10NkFnaCtL?=
 =?utf-8?B?VDNwbzFXUHVDMEZoMU8yTnMzWUkvRG9VVENBNE1Ja3ZOeDNtVUdrZWI5dDh4?=
 =?utf-8?B?dTRpOVM2WXlKeEVrMnlvb25aQTVrWlBmNkpjT2xYbWRtRGJ0L3hkNjZoS0pz?=
 =?utf-8?B?bENtakJTaUpRVjNQcWQzTUd1UmFRYXp3MVVTRGZhdTdqVUgwNnJpWEFMNjRP?=
 =?utf-8?B?djdPajNFaUZ6VlFXU3d3N0tIRnBvNzk1Ni9UODJQT0RWUjU1UUZRMTVhc3NI?=
 =?utf-8?B?dDlOSjRGK1dEMHVLbWxRWHMraUNueTI1TDVwL1g4MkNCVGJCOWwwNXh5Sy9W?=
 =?utf-8?B?WEQ4bUhNd3VyN0k1L1FyR2s3RU9uMmlwWnIrT0ZSSVpOSVFUWERTeUVDSDh4?=
 =?utf-8?B?b0Z2NEQydnJLVnU3bGhEbytEVEhoSE5nZEtuZTNSTndRVVZTQUplVjZMODFP?=
 =?utf-8?B?eEdCSFBtUWs5WWEvOG96dW9hZmpYd1orT1JhYzZmaFNXVFY4VlNHQjFGV2Jo?=
 =?utf-8?B?allCVGM5aVF2eXZmb1pvMGV3U0pkdENpaytlUHpVY1liSWoxbG1wT3dCNGdh?=
 =?utf-8?B?K01GUFZMWXV6Mjc3TlhnMzlhblgzWDV1YmR3UzhSZEg4UlNwazdaUkYvcXpr?=
 =?utf-8?B?MkFPZUpibXV3UW5PRXpHSDFiMUlaNktydC81UmtQdmFZNVpRTVVCYXVJbWQ1?=
 =?utf-8?B?OHVlRFFrelRYRHNWT0ZTbm1DUXAxVTNrVG1rQXFsMHZuNlFLaTBzRXo4SndY?=
 =?utf-8?B?MnZ4bjl2UjNXRWlmcUhVTy9hK1h3QUh5MzJhS3ZqdzlCdjQ4OTNTRnFueXVE?=
 =?utf-8?B?T0hqVmNtdU1OcDEwMFNlQU9HdHdNRnJYNHlDZ2RZSzFwVlhCeWl5L2dHR3Vo?=
 =?utf-8?B?R1I3YWhwL3U5dzdxeUt3MTFpaTY5R1Rkd1dzRXRnN0d1bFRKVzF6ZWpneEMx?=
 =?utf-8?B?QWFzdzdQYUR5OUhFTjd2M2dtQkttL0JpYk5lUm5IZ0ZKSUt5VEg2VWZ3NWtK?=
 =?utf-8?B?SDFmVzV2S1g4ck9OcW9kRU0xbWJmOWdWQXJUYVVXMklTYXV6SFNoeGxuS1RV?=
 =?utf-8?B?ZHZmV25IMm9Ic1M2Qm1RR0tZN0xUeWNnMW5Zb0RGbUZjY2lsVTMyNHNoUlZp?=
 =?utf-8?B?bENzZlJNK2ZDc0hIREhFZEUwR29LclU0SWFQQVBlNENOWWFiUDJIYXV3MTRC?=
 =?utf-8?B?UFp3OUI3M0hjaldaRFhzT2QweDRhN016ejd5SHZRekgvbnZ5QXc1bTBRdjd0?=
 =?utf-8?B?ZGtzZCt4L1ppYWgrWDJNdG1pTURXVXAwK3RZU3ZvU2szOW02N015UDBBeGhO?=
 =?utf-8?B?MkxxYzI3a2tXRkxWUktiNTBhazAvbnI3aXlJallqRzRYYnkzT3FTdEFwMGRK?=
 =?utf-8?B?LzBrNmwwcE9kT2JIOW9jL3l0TmlRTkRlaUhtTTZUT2psYjNrSjI4cVZRam43?=
 =?utf-8?Q?/L65FEvvOYs=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5277.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?enBJWkphTWJWUzJmdDFvZjh4S0pVNFF4MGhPbldSd2JFbXphVGdCY3pWQXhP?=
 =?utf-8?B?dE5qWjJtRHd0ZExST3phVzZEYXFNNGtrOWduRjhja29JcXNCcG84T25tOXg3?=
 =?utf-8?B?TFdhcENsYWdZc1JHdDJuZWZPNkhWQk12U0hVWlpBK0xJUFBoMS9sVno4MW45?=
 =?utf-8?B?bndNdllGZ0FVMVBTUjRxeVpLUFkyenlkdFRneVlyR3VhcWhjK2NGQi9CMEZa?=
 =?utf-8?B?K3hwNnhYQW1SakpQRDcvZHI1THI2dG95UW9McXF1akxDNjJkYlZWSCtHL08z?=
 =?utf-8?B?T0g2MFlQZUhQQ1cyREY4UWJqRm9Ec2FKcUFlRHh0cXJwZ3R1N2RNVU51YXRh?=
 =?utf-8?B?N3NrZUo5WnJSNGhpVFlyTFp2elg4MDhPdU4xdXIyTFJYdU12bVBvVFZMaDYx?=
 =?utf-8?B?Z1BNdG9GeWRhek92RDcvZkZNaEJqNTZWZTkvQ1gxNDNzSy9udS8vZ1A3Rng0?=
 =?utf-8?B?aS9zTFJRdjBOQUJnV0MvKzVUMDExSGNsQ1ZLRXNzdEszbTVUMnd3Q3JzaTBx?=
 =?utf-8?B?QmtxNGNhNmNQY1dPTmtWTHlVVzQvZG1kcExhVWZvR0E0eUpRZk1RUzcweUh1?=
 =?utf-8?B?WjkzcmpWZkFYWXpJUEluY0FETEI3cTNGYlRjWVdJN0c4MGE3RGkwOVcxS09O?=
 =?utf-8?B?dHkxbFI4Q3pOQnd2VG1iajFMQ0lyRlFKYm1wOFZkd1VZbW1QTktEWng0NnY1?=
 =?utf-8?B?algxa1Z6bkdUTklRbkdCaStHRElJM0lKUlFpLzhFNlcyWHArUytvL3VVSCtX?=
 =?utf-8?B?elRMZHgvUmY0MWd0WnBSbkorRHNrbTZEN2E1Z1JHdHNKWldOVk40d1YwVHcv?=
 =?utf-8?B?NDJqZDl3ZGwrUURpM3VGbGxaVFlTa0JkQWhqMndkeTZ5akQyQ1dKTmZIZmxT?=
 =?utf-8?B?R3JERUUwV0xtRytzNXZGdmo4Qmx4SUFVNy9iTTV1bGN3KzFWMTQzSGUxTy9Z?=
 =?utf-8?B?QklSMFJoOW9hdkRMSkNHRGdMZmFMWE1YcnBpVVNpMlRkZ1dKeVNpbEo0OTJ3?=
 =?utf-8?B?NFVnQU9yZ1dtUzJvdGhCTmZlM0hHYUpDWmJldGdNZEpta0VRTk5jclpubWdD?=
 =?utf-8?B?Vk1IcVRXK3IwWDJzYUFEWERwY2hxaWNKVjM4UjZYSnRrSFRoYjFnell3S3FI?=
 =?utf-8?B?WHJUcWJPNGlDUHN4VmJYeWRtZWtaZ1RUSVJEZnd0UEZMa3huQVBJRFVyMnc2?=
 =?utf-8?B?TkVVdWxuVXNQdzZldWlXeHJ5TStsb3Y3SHNyWHIxakh1a1FaaTdjR3plWmZO?=
 =?utf-8?B?eS9EZW1vTk4rSHhtc0I5emd1cmlMcTRQQ3VhbnhDaUQ4YTR4aVFqYWhTQW5M?=
 =?utf-8?B?VFF6cUlFeGpRZUFzS2YxbTV1YXhLaHlaYk1rZzRHOVU5OHdhWGJvZG1wMzAx?=
 =?utf-8?B?YkVDZFBEcmhXbEJQVG9nYXJXUGxnTzRwdWwwK1VaU056WXF4M1ZkZTBTNTI0?=
 =?utf-8?B?RFFManY3WkpMdjdPcW9tWmZManh0SmExSTNJL0U0OTBhcEY0Rk1RcThBZHpJ?=
 =?utf-8?B?SzliMjVQd1NESDBld01TTEg4VEVtc0hDeFd2S0g2TUVTUXVjT0FpaEl2d2Nj?=
 =?utf-8?B?bHQzNi81ZGZGWTlRelpkb05wQ3R3d0hjRUN6OENxSlFpbzFCWndnZnllTktB?=
 =?utf-8?B?MjZIN2lnOFMvUHp5R2pLVVZKVVhoeWlPT0szRVlUaW5mQWt0b2l2SHEyamNp?=
 =?utf-8?B?SFNvaXVnMFFVY2NlOVFudXE1aXlOTUovYzZTT0x3TVhSUWplYS9wOVV3WDJ0?=
 =?utf-8?B?UmZQSUVsWDJJTTlla0YyWnlncEc5MCtUOFlkRWNHaW1FSmZFVXk0Q0VpZ1RY?=
 =?utf-8?B?V0VSeXNjS2prVHI2Y0xjRzIrT21zTUxDZXZZcS9QSmE2QldqSWpIVWgyR0dM?=
 =?utf-8?B?cDZTU1o1TURsdlRQc1RoTHFXbVIyOEVpakluMW80M2IrRGtDSERZYmxISHZn?=
 =?utf-8?B?QmxhNG1DZ090Wkdoc3lySXJJd0czS1NuZStheVR6V1VtTzFENUptTG5JZVVa?=
 =?utf-8?B?SURLSFl2cWtpVG16dldNaWxPT0FYcVZ1NE44UVVQRlNWY0VPZTdYa0JkNWpq?=
 =?utf-8?B?UnZTaENQL3ZWRDRyNTFiZVZNSGNRUUp1T0U1eDFDRTB2SXNIQndodWRDWGlh?=
 =?utf-8?Q?SD9xgUWTGkiQGqwf2WvDsaDE9?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b7c0894f-f58b-49ef-31a9-08dd92b0f344
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5277.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2025 06:31:25.2488
 (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: sxNPWLTAm52TsTSNvNx1QYF3/bgV6QFHnROFl6Vv0voUNFMV1G+ifI07QDfG7fon
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6864



On 14/05/2025 02:07, Stefano Stabellini wrote:
> On Tue, 13 May 2025, Stewart Hildebrand wrote:
>> All functions in dom0less-build.c should be __init.
Why? This patch is first in your series and by that time there is no build time
enforcement. Together with the Fixes tag it implies that this is somehow an
issue (i.e. build/runtime issue) other than inconsistency for which we surely
don't need Fixes tag.

Same for the second patch.

>>
>> Fixes: 2705f1adb9df ("xen: introduce Kconfig ARCH_PAGING_MEMPOOL")
>> Signed-off-by: Stewart Hildebrand 
> 
> Reviewed-by: Stefano Stabellini 
> 
>> ---
>>  xen/common/device-tree/dom0less-build.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
>> index 2c56f13771ab..39cb2cd5c70e 100644
>> --- a/xen/common/device-tree/dom0less-build.c
>> +++ b/xen/common/device-tree/dom0less-build.c
>> @@ -730,8 +730,8 @@ static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem,
>>      return rc;
>>  }
>>  #else /* !CONFIG_ARCH_PAGING_MEMPOOL */
>> -static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
>> -                                            const struct dt_device_node *node)
>> +static inline int __init domain_p2m_set_allocation(
>> +    struct domain *d, uint64_t mem, const struct dt_device_node *node)
>>  {
>>      return 0;
>>  }
>>
>> base-commit: 5873740e41acb8593f92623ddd03caebda2718f6
>> -- 
>> 2.49.0
>>

~Michal



From xen-devel-bounces@lists.xenproject.org Wed May 14 06:36:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 06:36:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983790.1369961 (Exim 4.92)
	(envelope-from )
	id 1uF5jP-0003di-Sm; Wed, 14 May 2025 06:36:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983790.1369961; Wed, 14 May 2025 06: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 1uF5jP-0003db-Po; Wed, 14 May 2025 06:36:43 +0000
Received: by outflank-mailman (input) for mailman id 983790;
 Wed, 14 May 2025 06:36:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uF5jP-0003dV-3S
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 06:36:43 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cbe556ab-308d-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 08:36:42 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad2414a412dso585056866b.0
 for ; Tue, 13 May 2025 23:36: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
 4fb4d7f45d1cf-5fc9cc3f5c9sm8354337a12.28.2025.05.13.23.36.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 23:36: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" 
X-Inumbo-ID: cbe556ab-308d-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747204601; x=1747809401; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3C4kAv9UftGohtooO1z/TpM9mhqQF5D44PsfKJ889fU=;
        b=FQSW16pNscuK5k3Ur+DyQ7/bVOzBlOVEE0+t69oeV4ZPcDgWBkDJQfYINjzKRBHfwY
         xy5Au9LE3s225k50/oaHHeKQX0CTXIzZOfZNHkuCZeWklFkJznr7VMLpSB77G4vn10gB
         Zplvex37vGp6yHnzGu7FqhmidHd7xaKZ2TYz90daHkWmL6hGqB3UAMPK5iRzqwiZYrjm
         Kpsea3P79xoimjZ1R+uiCOwW2ePqPDRBJgafywDGOYPlvS/l60GvV8dH/bncoDleWRvf
         UMchMCdJHNeRy9wEEKgBMSDAL/1yLTPmOZXO62b5DuBfT8GWRaLmAX8BCa0YrLPJD79R
         4tzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747204601; x=1747809401;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3C4kAv9UftGohtooO1z/TpM9mhqQF5D44PsfKJ889fU=;
        b=tAPRsQc+zUlOJ4aGUDHlxA7GhHWXMXutsJn20s+M6Ea3iOg54YHHok4qfF6YoqA5MQ
         bPv355nbVtQfatYUBNW6HZPBnYQYbjfrFnQkGn8RRj9J82vaBi2LSnPfsgCBZ2fNnQxu
         1XRvRcdjNT6fmBtkbJSjfF6XmN8YTg0dxkV2aP/skGA/HAdQp5gk0fjcAQlS95wg/eAa
         92RtEek+0V4XE8HasdbBzbzi7wqSQsjAd3fzMpNJLphxNSsezVzpfkFKvdLITVmQCI2s
         Bz7PQ+FmyucrXwhC0uLXYLTQ3/CKpaOq6tFioIJaxXHrbd0E6VvqR0KGAVD8jyaNwPOQ
         pwQw==
X-Forwarded-Encrypted: i=1; AJvYcCVRBZ3Okmx1jVFPjBhL78VhDu0c71w0Jef2wJaGIqjZmYpyJuI5Qa20MMi5iRlIaAzeqTfv1vuZyfg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJz5jISZthSpL6s50KI6/34O1Qxlpi7kP8q7e7DNmeKd37TwbD
	J23fI2I+C7eANmayZt0qp/2CV9K42f0GvG8zvxvfgvpc+iahQzBB5ggLT0RuaQ==
X-Gm-Gg: ASbGncvIbYRSdvzoVG+E3bhninnwBwNl9frh0XepgZA6VVIRkWjtxeiFef60am6mISr
	p7FvvMjexEUFqP8e4WrgvYii5W931oR7Q+waSIwBRF+sd8uXXSA95qkBulcHkGqVZahidwm0rT5
	LsrF7coSVLq/xnKymSOOd4MeGDdpIasZ++h9COTWgs5xF67EY4lVTdvcwk0UtsIYgWEXU4MKMl2
	3rWK7Rd5EvgYxOB+cS29/RLMsuXiZXlPd+TKbDJwU96Mj1SYG8KvRezh9wZqDlK9FU3T4ve5xng
	eBIQ7k8NVEV61mtzR+/v9skSTOXwD/hZdujl4YL++UYX+mehD7yXBsMv7FknCrHsNVfnpGeUMbO
	Wbhabg0nDTkjht9pWjZ2Fe9wknOW5q09YRk7l
X-Google-Smtp-Source: AGHT+IHpPdP6mcXYZQAJtUcl9LmdENtXoAe9fiSNzFEIHyVr/pnIMgrDCiNicG4lxms0ZwrMwPWRcg==
X-Received: by 2002:a17:907:2ce4:b0:ad4:d133:1771 with SMTP id a640c23a62f3a-ad4f7113e60mr217629766b.13.1747204601314;
        Tue, 13 May 2025 23:36:41 -0700 (PDT)
Message-ID: <17e575bc-2248-471f-9f64-e48ef6481180@suse.com>
Date: Wed, 14 May 2025 08:36:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 22/22] MAINTAINERS: add a section for TrenchBoot
 Slaunch
To: Sergii Dmytruk 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
References: 
 <98bb81298fc94f38ea79975937e7a5aa81157493.1747155790.git.sergii.dmytruk@3mdeb.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: <98bb81298fc94f38ea79975937e7a5aa81157493.1747155790.git.sergii.dmytruk@3mdeb.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.05.2025 19:05, Sergii Dmytruk wrote:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -542,6 +542,21 @@ F:	*/configure
>  F:	*/*.ac
>  F:	tools/
>  
> +TRENCHBOOT SECURE LAUNCH
> +M:	Daniel P. Smith 
> +R:	Ross Philipson 
> +R:	Sergii Dmytruk 
> +S:	Supported
> +F:	xen/include/xen/slr-table.h

Nit: This wants to move ...

> +F:	xen/arch/x86/boot/slaunch-early.c
> +F:	xen/arch/x86/efi/fixmlehdr.c
> +F:	xen/arch/x86/include/asm/intel-txt.h
> +F:	xen/arch/x86/include/asm/slaunch.h
> +F:	xen/arch/x86/include/asm/tpm.h
> +F:	xen/arch/x86/intel-txt.c
> +F:	xen/arch/x86/slaunch.c
> +F:	xen/arch/x86/tpm.c
> +

... to the bottom, for proper sorting.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 06:50:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 06:50:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983800.1369972 (Exim 4.92)
	(envelope-from )
	id 1uF5wC-0005UO-2C; Wed, 14 May 2025 06:49:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983800.1369972; Wed, 14 May 2025 06:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uF5wB-0005UH-UW; Wed, 14 May 2025 06:49:55 +0000
Received: by outflank-mailman (input) for mailman id 983800;
 Wed, 14 May 2025 06:49:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uF5wA-0005UA-Cq
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 06:49:54 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a2479e27-308f-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 08:49:51 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5f4d0da2d2cso12290608a12.3
 for ; Tue, 13 May 2025 23:49: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
 a640c23a62f3a-ad23da570desm664757466b.118.2025.05.13.23.49.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 23:49:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a2479e27-308f-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747205390; x=1747810190; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=B3bkkKEXdm1Ipi31r9dCGffV54KWhkwL2eW1cj/BPC4=;
        b=JNJz8QKbaFTn+WH5UIuHE9axYa2UPix2/gdFWnQ8wUepM+DiPufsHytjAWgXw6mX7A
         h6Ug1v4m9yt6jxQhRx5s0rmeb8PCvw0Td5RLrE2XjjYRsuQ1IoBHbRTMGN7lup7RkwvW
         3TgA2Fbe4fjpdBy9TZt1mwzVcVKFJC+hYGzlVZkI6O1nJ3zit38Vqp8Hf/3Hos5yA5Wj
         P9zZo6sj4rV1NiFW/Kp31WsHla4RDHAoon2qD0kU8it4jAzNiWmVpoM2Jl7vDdfSdd+9
         51PLN3g7v1l6vHd/PfnkoxSLHNDmBwbf2Spjv3Je1AoAwtGPKo4untPOcFGmI1KLXsLA
         4ihA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747205390; x=1747810190;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=B3bkkKEXdm1Ipi31r9dCGffV54KWhkwL2eW1cj/BPC4=;
        b=aIfgqXRkY/HcMqg9BwNf9kRbhwCeKZSb4myOqWwM1zjR1DkgyKWntEVHv0bPMPB4DS
         wzLRPQMpYHIS7ONbXsYf/DS0kWx3q8/4KBOv+RDCdWD3FEAbyB968CAffR6a9Dm0qwpP
         /qvOnjk9YRxIX+fSmDNk2LCWqEpLXj8mXuKCdLBIsK/FX5hB8e2pxr1tnlbQgZSXUoju
         SLjmOYmAew89gc1T83CPamjMwyna1hLG2mlGQnF20Xmea/QA91T0/2Kixs8M6EIEZYJ4
         cDiRk6qjfDOgrwGsoB2gK5eVSclxXPB62p/OVTw+PL0GFow9vHU1TBlqRNgmZi5uCtbQ
         IFxA==
X-Forwarded-Encrypted: i=1; AJvYcCXfWer2QaaTjxVoUHbS+TzEY2VcDyHL9ZoDsyO+29Qqd55CKz/Anb+R8OH7sH1DNEnZMyc61iqQIRc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwqnffkfC8M7MxxFmu4Uf046wb/q9BHzYYoFEJagLaQfj3CYEy6
	0/6IkIlmOq0e3np9g64HD083HHY887S7U8XW8tOMEgMwhlpW5yvUbQzKLMvOjQ==
X-Gm-Gg: ASbGncuLUyzHyqQctPAgCBLIrwC5onVCJ+peO7me4dLub+6rSnPBYrxDnANaytS2+n/
	+LnAYj2DZlS9jUKtYGG3J0if2LKq8AA5q935F4QKZVCkOSMI1A4mI+MfnR1hv1JsgSofMQ/BL/p
	syE7nPrFbK7/sZKHPIgYBk1kcsCsVOFBESLcQCE7hOaaFFEL6tBoFKcLsHWZZcZQxgTt2nTNnwe
	hcikWDUM/m4YMVeWQAy2ExUjzzlfiIL/amv8wdOV5GP3hZaPIRg+k8xB/jnUHyTMSw+tQF6JOU2
	n1eLLUjQqbXBO/tG7QS2epCkAH413rZt+uwYMsBTGxbFZawDMmoADCBFnTLuj/zDphu8T69LVi2
	J6JbJ03dsfXQFLaY4dYM6rW3SHR/i9EMFqkex
X-Google-Smtp-Source: AGHT+IFszv7hvi17mGx5kazwDh3l2onptVcgIt1gYwLTo9m0VvUtKSkIubrEXHJOIjM0BLEx4XuC2Q==
X-Received: by 2002:a17:907:2cc4:b0:ad4:f5ed:add2 with SMTP id a640c23a62f3a-ad4f74c8195mr205901666b.38.1747205390405;
        Tue, 13 May 2025 23:49:50 -0700 (PDT)
Message-ID: <2491389a-cd47-4917-9ade-7082f1ebc678@suse.com>
Date: Wed, 14 May 2025 08:49:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: Stewart Hildebrand 
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: <20250513195452.699600-1-stewart.hildebrand@amd.com>
 <20250513195452.699600-2-stewart.hildebrand@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: <20250513195452.699600-2-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.05.2025 21:54, Stewart Hildebrand wrote:
> --- a/xen/common/rangeset.c
> +++ b/xen/common/rangeset.c
> @@ -433,6 +433,20 @@ bool rangeset_is_empty(
>      return ((r == NULL) || list_empty(&r->range_list));
>  }
>  
> +int rangeset_count_ranges(const struct rangeset *r)
> +{
> +    int nr = 0;

Ehem - this and the function's return type want to be unsigned.

> +    struct list_head *list;
> +
> +    if ( r == NULL )
> +        return 0;
> +
> +    list_for_each( list, &r->range_list )

Nit: Either you deem list_for_each a pseudo-keyword (then a blank is
missing) or you don't (then there are excess blanks).

Further I don't think this is valid to do without holding the rangeset's
lock in read mode (irrespective of the function return value potentially
being stale by the time the caller gets to look at it, which is no
different from other functions, i.e. falls in the caller's
responsibilities).

> +        nr++;

And then, if already abstraction is wanted, wouldn't this loop better be
yet another helper (macro?) in xen/list.h?

> +    return nr;
> +}

Finally: If this is to be commonly used in several places, having such a
helper is likely fine. As it stands, the sole caller is an __init
function, and hence this is unreachable code post-init (which while not
formally a Misra violation in my eyes effectively still is one). Aiui
the same can be achieved using rangeset_report_ranges(), with a new
(__init and static) callback function.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 06:53:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 06:53:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983809.1369981 (Exim 4.92)
	(envelope-from )
	id 1uF606-00078K-Fr; Wed, 14 May 2025 06:53:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983809.1369981; Wed, 14 May 2025 06:53:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uF606-00078D-D8; Wed, 14 May 2025 06:53:58 +0000
Received: by outflank-mailman (input) for mailman id 983809;
 Wed, 14 May 2025 06:53:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uF605-000786-7J
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 06:53:57 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3473f36b-3090-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 08:53:56 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5f62d3ed994so4501548a12.2
 for ; Tue, 13 May 2025 23:53: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
 4fb4d7f45d1cf-5fd0142152bsm6243801a12.19.2025.05.13.23.53.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 23:53: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" 
X-Inumbo-ID: 3473f36b-3090-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747205636; x=1747810436; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=J/kTozl755Qv9cr9hPNKPoioNh/TJBsjvMKXLZxq5yc=;
        b=ZON1JUKaWEABuMussHaLvCPreTxQ1Wm6qYV16PjTq6/CW70A1XbST6s+AqKngKGNL+
         RABF7VBLwULdCbdEucqMUTs4bDTerJJIm6TnIXVz9TR/H3GL6W8mAVZs9Jd2fvO7fabh
         tXlfbA/KMym+r6iwBm1MxkcbKlaVJtTklI7uQrMZ72vp+UzUMKMk6TcKNBm3vMCHhUF1
         NoIOmN6qomHSVwqv5gKuuX37+WyqFkhn2SXWJgd1pgww1kBs4FPMYHdJuHpXIE7ar/Mt
         /noWyNgNZy0pGRb3zx2cM+Dn8RbuSlWwF/1yBmml5BL9+qD0y8IEhpi8KauC57Lp7d+d
         EFmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747205636; x=1747810436;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=J/kTozl755Qv9cr9hPNKPoioNh/TJBsjvMKXLZxq5yc=;
        b=Kx8Sj60y10qSbnrVB/J4pHxmwl6n2flZUwIrGJAtli3yjWxZJuJAkq1kT0yekQZVkw
         kJ9AgJMQSuJF5LCiuXGVWz6qieh29qJ96ce2SxAf6U0+qeQ1cHHl9D6D9mnqr3OHidG+
         U9T0O2Pj451EYx5pgXSptjynRBlvLwis7GIqgpCgFESuhCwjJwQp96R6JfenQGgclCTd
         ir64EaRaJgI/Gp5skHGTcEMCI0QHZgPQFo+pnEmTdSbipHi9cF94yK56iqYoB0bhmHvc
         T3oEmiNetkkeXJsAxP+Xho0UmPipPo9a9RFlkVPJlqXQ9rt62Zu9d4jPy4m4HQIk0ihE
         DBwQ==
X-Forwarded-Encrypted: i=1; AJvYcCWGtMO/R4+oWz8bDf9JOruKEUJvoVUNKlPE+uMVPA+EeF/+6NlVSDyziA3E+cIk2lGI4iWLnFbWaNI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwrulBz/3CFL0DXTx/0ZtRdq80fxfiCD09zYGpa4Cf/clMbTgbZ
	xTWkJci7K5iZfZr25mSWpsIbq2YybEUTfLxMArTPZpOUs2gnzU6v8DLn/mwzfg==
X-Gm-Gg: ASbGncsjhDqO4gHgjYoDGNowcOOfkNsJuyLbvp2AkGx4wv6p2Ci/hoPQFbRrDP4p8LM
	088ymI+yYoGLv4g2DyLlNClksp2HXs9J63J+N5jgY2hyEI7MYNJyaDUfBzdNuYMT1v6n3Y2vpsT
	82JuhhVJfyI4Ywj6NOF72+3e6UAZCx7yfWIICeEtLjoTvJgKFDfrNklU8GgRLZOeDb2E/226HZQ
	uo08mY8vOya6nAsisf7LfzKHvS4C/23uZ1QjAuTuGN8l5wU6J0VfOTpf7zv8iaGBHUJBetHES8Y
	ttCCs3G+V1b7CezE8rdKkQ3M1WiFSzBOIWp0jrP4sFa+6hDGhIlFBCqPMaZk9skPlxt32w9Zlwe
	HsMqRJalGJrUbdRPHF6pLt7NpjxzS0QLcA5pb
X-Google-Smtp-Source: AGHT+IHdDZl0DmDd9cVtLhxASmM6LQG6u5F60bGICyRUUcX6GXNuH8mj20gcP8CXMuCaMO/orYM9UQ==
X-Received: by 2002:a05:6402:5113:b0:5f6:2249:d424 with SMTP id 4fb4d7f45d1cf-5ff988d1551mr1609776a12.24.1747205635738;
        Tue, 13 May 2025 23:53:55 -0700 (PDT)
Message-ID: <50830693-c540-424d-b040-b059d8d8557a@suse.com>
Date: Wed, 14 May 2025 08:53:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation __init
To: Stewart Hildebrand 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel , xen-devel@lists.xenproject.org
References: <20250513171810.668370-1-stewart.hildebrand@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: <20250513171810.668370-1-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.05.2025 19:18, Stewart Hildebrand wrote:
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -730,8 +730,8 @@ static int __init domain_p2m_set_allocation(struct domain *d, uint64_t mem,
>      return rc;
>  }
>  #else /* !CONFIG_ARCH_PAGING_MEMPOOL */
> -static inline int domain_p2m_set_allocation(struct domain *d, uint64_t mem,
> -                                            const struct dt_device_node *node)
> +static inline int __init domain_p2m_set_allocation(
> +    struct domain *d, uint64_t mem, const struct dt_device_node *node)
>  {
>      return 0;
>  }

Imo the better fix would be to move the #ifdef into the body of a
function. That would then also get rid of the stray "inline", which
generally we want only in header files. For a (stub) function like
this one inlining should be left entirely to the discretion of the
compiler.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 06:57:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 06:57:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983817.1369990 (Exim 4.92)
	(envelope-from )
	id 1uF634-0007jJ-U8; Wed, 14 May 2025 06:57:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983817.1369990; Wed, 14 May 2025 06:57:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uF634-0007jC-RY; Wed, 14 May 2025 06:57:02 +0000
Received: by outflank-mailman (input) for mailman id 983817;
 Wed, 14 May 2025 06:57:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uF632-0007j2-VO
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 06:57:00 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a1c07a9d-3090-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 08:56:59 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5fbcd9088a7so1210168a12.0
 for ; Tue, 13 May 2025 23: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
 4fb4d7f45d1cf-5fd29f9fdc2sm4851007a12.4.2025.05.13.23.56.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 13 May 2025 23:56: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" 
X-Inumbo-ID: a1c07a9d-3090-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747205819; x=1747810619; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=azOJWAIGjMLaCm6mwRHwibEHaB/Bi0uK8s+1koMZPfU=;
        b=LaQL7Eu/apMbpSiI8qTO781m9uSW0oQoJPcm9Oehxv+q8X2id2BGA6j4ZRrlgNgAWg
         d+zRm3IzLIOlZIzY1VrppekEzn06QJaX4q/I6uhXavUAgbQb/FprlkJCcsU/dyRNEqay
         jPK74VWYERpImc21XLyR7lsargVJMpZFbw+M/ChrrUvqhEJwDjGVQib3Om7PhHv4aKFT
         M2qJoBmOuI3GTI6Sx+dqBMtVgKFIPLNlIHNth91nn2ft3snPsoLKD271sOC3yG1QnNPj
         YsrjTHLTP+OKzgb/mwyhoCfREVMgcu6djA0FT6f2Y8irciGbW29dn5CSihJBoKwrDAVD
         XSAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747205819; x=1747810619;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=azOJWAIGjMLaCm6mwRHwibEHaB/Bi0uK8s+1koMZPfU=;
        b=SpxisDdqbAzs6BRJzoD4ys66ZWDDu5ijWF8fNrc59mcV1GnXyusqOppAXP0Mj53wfR
         ggfUKZpGmsyDoAKUQnaieGqFtzP4XeJTc2kFy3uau8lBOjjpNp1zWve02eLF62m4K4Dv
         QJAPDIWRphyg4fAnORKeU12sW33dk3vMoZLLYPovbzMxKSEJ+jrVLDMRIVEfCcEaYoxu
         VLgPkHbfzCMN0ZGdhY9a9AlHEvBk/+0efieGQFUn9TRZ1yVjrvYcC4vOaU5XUgh2sDwV
         6jOY8SKsFwRYMLJtOj+eekDmZ9n43Mvy0zrFVtyvbyoQgXFM2UVw10YuT6ZWbSyfkHTB
         4DnA==
X-Gm-Message-State: AOJu0YyYYz1awlItGFEEYq4zd88FqCvE5N/boru5UHHSf5H7vxEOY1sv
	TH+nmjb5M1t2H1ObXJWdeKKttBokeZuD+Rrx50HT/5Uf0iqcHio8QShR//v9nt1v1weAiLkxfIM
	=
X-Gm-Gg: ASbGncvvOtJoQeUOK8/Hfh4rd9TSnU6fO6VjsXCdIbiFUnnFufq+afm/J+Hd6kUALQo
	/56FyU588DJvAGuDV+032IeuidTPjr+hVy/Am5n5ElDFFUkSw+ylyUby3EGBuXjyOQieAffkUy7
	G5CtnQbcOv/+M+S0Tnx0j2ga+f5t8chP6QAjPFgGjM1GfNdvIEWSlAEl330vJ+3IGK0a3Rw8bwC
	TjSXF2rzMcWXYwe2qsyolP/G9hnNpi937FpzklazUAyYkean6SHHqH9gVllPl8hXpvhgneKCYSg
	a25ia4j89LmMRZmlHvmlEffGMa/L3cPdkzIba4jdNIg5tgORgoeV310fINKZD8ScmJTqPCr7is8
	qTPHlgY7pSQ/lph7VSHLbbkUAn2l7T+qyVf0i
X-Google-Smtp-Source: AGHT+IHYVY4Ib0wmvTkl6xKXLyxOPGsUU3tuNnjnrx92yb15UUO09O/XL9nuR8O/8kOrA85A2Tjv7g==
X-Received: by 2002:a05:6402:520e:b0:5fc:ea4e:b7a9 with SMTP id 4fb4d7f45d1cf-5ff95ae878emr1959570a12.2.1747205808993;
        Tue, 13 May 2025 23:56:48 -0700 (PDT)
Message-ID: <4e684e38-ed64-4731-8f00-afba938a28a0@suse.com>
Date: Wed, 14 May 2025 08:56:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation __init
To: "Orzel, Michal" 
Cc: xen-devel@lists.xenproject.org, Julien Grall ,
 Bertrand Marquis ,
 Stefano Stabellini ,
 Stewart Hildebrand 
References: <20250513171810.668370-1-stewart.hildebrand@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

On 14.05.2025 08:31, Orzel, Michal wrote:
> On 14/05/2025 02:07, Stefano Stabellini wrote:
>> On Tue, 13 May 2025, Stewart Hildebrand wrote:
>>> All functions in dom0less-build.c should be __init.
> Why? This patch is first in your series and by that time there is no build time
> enforcement. Together with the Fixes tag it implies that this is somehow an
> issue (i.e. build/runtime issue) other than inconsistency for which we surely
> don't need Fixes tag.

I disagree: Code not called post-init should be in .init.*. While not formally
a Misra violation (and wrongly so, I think), it imo effectively is: Such code
is otherwise unreachable post-init.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 07:04:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:04:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983829.1370002 (Exim 4.92)
	(envelope-from )
	id 1uF6Aa-0001Ev-RG; Wed, 14 May 2025 07:04:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983829.1370002; Wed, 14 May 2025 07:04: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 1uF6Aa-0001Eo-M5; Wed, 14 May 2025 07:04:48 +0000
Received: by outflank-mailman (input) for mailman id 983829;
 Wed, 14 May 2025 07:04:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF6AZ-0001Ei-T4
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:04:47 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20622.outbound.protection.outlook.com
 [2a01:111:f403:2009::622])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b6bdb519-3091-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 09:04:45 +0200 (CEST)
Received: from DM4PR12MB5277.namprd12.prod.outlook.com (2603:10b6:5:390::7) 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.20.8722.29; Wed, 14 May
 2025 07:04:42 +0000
Received: from DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e]) by DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e%3]) with mapi id 15.20.8722.027; Wed, 14 May 2025
 07:04: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" 
X-Inumbo-ID: b6bdb519-3091-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fNVlcYSA+K0gGeswZCedrNU2Iv7Tz3T4fru48X1p2MFNgZOjfxlViGBDhyihTcByZOQDISSIJOT4n1NFkc1K4YDtP8yK2ulTboNOWZaiyi9vwpxAI1YCsY74aritVHPvrBY6M5rWyge6S0KWwTRP8RlBZdnu9XsfZ9y1QtP0FBFLfWZdzKnLM8h0atVz2rbvgsYWUzaLKvdOU1U0v17YUBxmTSZBdUjU18QLTmnF6AM5DRbtQlV5mR3VLrw0XhhMYepx3XpSGv7NGuAfVoExTc+A1bqEQxJqGdItmZ9kCeqPBVcjsFh8ZY8teYqPB6elPMWCej5Q4tFd3JzPxibHRw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fg0IjlIRNUhsid3cs7IM2WM++hYVZQNpG3ftDcxV+gU=;
 b=QIuE6om7Huki+FPXeLy1iY75yBztjVORVnz9TscnhP1nwzyiOIQsfk+Ky5KMknZJVMfS6sHt8b6arqomRuzk9yq2X74schgM91xy0MzA8YO7gCkmJ+RRl/Ge71uWPkN9MfNeG7flYFh6B82ku+Q/AYJg7PpKNszcwKan6p+frhM5B6Z/BPnTDPfhOiL77+Qpwc2J2XPBvuNfodtoKSbZTzZE9tsyFF8r11JVE5yCE1VVCZwGZ+QKSwv7+Pda/RlZNcPiLqU2VYsUzqG9iZijY7Pb3oPdNBs+YeMx/Tous2eewHiZWssk5ugxR+xJwEj/AKtamxKyH+raNk0HlOaUMA==
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=fg0IjlIRNUhsid3cs7IM2WM++hYVZQNpG3ftDcxV+gU=;
 b=4ZWH6HhV6w9FWgSHud1qG/iNNpu4Wan4L/29h2ev+oWjTc2UydkSQt3gqWnOfiTaq4L7P2bjNkugNboufkje+xyb62ruA3a3IyAgKtK55J576YJk5oT9XMcyTlWxpS6jnKtODLhXd7bEZ8xvufQpckdcRX235i1Ii7512yPO9Zc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <369ccaf5-5c17-4601-88b0-eb32af8608d6@amd.com>
Date: Wed, 14 May 2025 09:04:38 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation __init
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org, Julien Grall ,
 Bertrand Marquis ,
 Stefano Stabellini ,
 Stewart Hildebrand 
References: <20250513171810.668370-1-stewart.hildebrand@amd.com>
 
 
 <4e684e38-ed64-4731-8f00-afba938a28a0@suse.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <4e684e38-ed64-4731-8f00-afba938a28a0@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0098.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:9c::6) To DM4PR12MB5277.namprd12.prod.outlook.com
 (2603:10b6:5:390::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR12MB5277:EE_|IA1PR12MB8312:EE_
X-MS-Office365-Filtering-Correlation-Id: ef4a2abc-d2d9-4d22-e82c-08dd92b59965
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?N0wvNElyWHNBMHZsT25GTVRkTDM0QWNFYTRXekxRQ080Y2xvUlFVbWZ2NXZD?=
 =?utf-8?B?MDNwSzFEUE5aUzdqNGJ3cnlrZjVOV2ZqdC9EVmkvdU5HRStYRGZxYTNVK0hu?=
 =?utf-8?B?NnVxa01LU1NnL284QVhUUk83aHZ2SG9xVnJteUlBTngybjI4aU4vNkUrSkk4?=
 =?utf-8?B?TTlpNndoOVhYend0cHVSVVB6REZEZmVoc0dXeHVZaS9pUUJjR2VUb1c1dE4y?=
 =?utf-8?B?a09WT3FMZFRnKzJKOHFEcDFuT1dLbkVvZDRBRXN4V0F6ZnV3bXU2WVZVUGJG?=
 =?utf-8?B?L203OThmSjZUanRpUlVMZUNReHY3NS9KMG9YUTRXbXlwYXN2TWszQkROa2hs?=
 =?utf-8?B?U24rTFhtaG5pVWZiMnhQRnp0ZTV4NFFpVHlnOWdMUFpneVByZ1o3ZVlSNFNu?=
 =?utf-8?B?ejNmazRWTjVUaCttSld0WVNSUktONCtBODNYSUdTbS9SRWJicXVoN0ZIVlRN?=
 =?utf-8?B?dHljT0c5U1YwODNKKys5QVRKV2swMVBRU3lPNjdZZGZ2azk5T3JlZ0xMTUMv?=
 =?utf-8?B?TEpQaVg5dU5tRmpuYXNtYXZrZkZ5aUlpVCtodjFweWVsMTZhYUkvVENKRHIr?=
 =?utf-8?B?ZjVKUHNzdGl0dHlBam55OWtUSHZnKzNMOHMzVzBQNzdha01KdW5HdVBDODYz?=
 =?utf-8?B?ekVhNGt1SGJMTWJUVnh2SWw5YzRhNmZhWXBhUXFFWldZT1ZaUTFBYUtoZjNx?=
 =?utf-8?B?OWNOUHNVWEJTYkNPRGRCNkJQVncvUW4xRS9UZk1PSTN5WllhZjZhTUFiLytR?=
 =?utf-8?B?L012eWtUb0RKakRpb3JVeUM2ZWVqN1hoa1VjT0o5b0Y3MDY0MkpyS25hZlJY?=
 =?utf-8?B?MVVrZnkxcHJzdXdGSjM3YTlNRm0zQUNtZlpQTyt1KzFUeEVTeUtPcjE0QjJU?=
 =?utf-8?B?Tm5lam4rUm5qVStHeVdrd0VGVTdEUUtOWktuZ2UwMkJzeFRTdlFhSnk3MEhm?=
 =?utf-8?B?SzUvalJrdjh4NkFTUHI0bU1sc1BEWmJYTFV4Q1BqWDRoeFEvQzlwaXZKZElH?=
 =?utf-8?B?bWlnRFk2V2xIeWNIS1l3V3dWQ3YyTXQzZndZV1k5cU05ZVJCRHZRK1Z4bTZW?=
 =?utf-8?B?QnRCREVaWDNpOGV2K1dIZy9rT2NwTGs4K3hOQnBKNG1yQlNiNUR2QlV0SGt6?=
 =?utf-8?B?Z0hQK3hRL0xHdnAxbnJpcUlwV2paNlNmcm1UVG9NTnpTdGtTaUpxZFQrdjBs?=
 =?utf-8?B?M3dyNUJLL2NWNEprRDdwdlVYaHMxdzkvQkpNWmM2V2VadHNTMWx1MVNMbFYz?=
 =?utf-8?B?eGkxMXNlQVFibnhYNkUxaWRTZ0JuS0ErdUVweVd6dzZoR0xHbXpvYjNZV1Zu?=
 =?utf-8?B?SStobERqYXRFVjAvWEc1aHdoTlFJZWs5eXZiUmtqZVVsOVpwcmRQQ1JINzdJ?=
 =?utf-8?B?bVdSc3NUVDY0MjkzWVFtWjR0T0Uydjh2bXhrbE5DeEpia0pYcytpWG9SOWho?=
 =?utf-8?B?RHJRUkZqcmV3OGpkakNQbVFTSFFvQmp4VHprNndHVEd1UkdkanBlaHdtc1Rv?=
 =?utf-8?B?R1EwTms3YXZmTWlKcTk0aHZ3VUdVTS9TZENDdzA4YTFTelQ0cndUVGQyU0sw?=
 =?utf-8?B?LzMxMmxTMGhWa0ltTVdRb3VvTWJLOHFhWGtWc0ovQmdWbUh1ZlgrWFpGM3V3?=
 =?utf-8?B?NnZ6VE9PUW5XaW1jRTVzQnhSM0J0ZHRGSStzei9xaGdLcWx3Znovc0syQWR4?=
 =?utf-8?B?USt3K2VHVDVoNmNEWCtQRVVJSjFkRTlzUnNGNTNsTUpsYit1ZkxVVGJmYTBF?=
 =?utf-8?B?MStXZGllSkRqeUFhOC82NnhWQk9zMWNyMnJFZTNNRTZjNkFod2dsT0x1MVFr?=
 =?utf-8?B?YWt1ODJjaENXRlkwK2lHeittZWIweXdqVDRBbklNYVR0aW8rSVFTYmVUOE96?=
 =?utf-8?B?N1JTK1llRWZCKzA2R2pMdE0vanNDY0Z4SVA1YkhQbDlRYUo2cE5TeTZOTUQ0?=
 =?utf-8?Q?sMZx8+muVBw=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5277.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VG8xeUdGTjlITGIycVA2V2UveTRjMlFDQWZsaWs5Tm1ZSi9WSmhqYk9VNi9u?=
 =?utf-8?B?NlBFT1N0R2I5bGU4RU5jUE1PSHE5WE14c1VyK0ZsN09acEF0ZjVXc0pOdXho?=
 =?utf-8?B?R0YwMFRUVE1scnhyeDlJU0VCbjIwSzRFK2x1cENhTXB1MVhnbnd2Vm11a3dP?=
 =?utf-8?B?aGNOWnhpakgreVZsbHphN2FUdWhMZ1dnYU91dWtPSEpWRVFNSkk2Ni94UzNY?=
 =?utf-8?B?Q1Rja2RXYW9mZTY0R2c1S0hlejczMEhFV0E2NW5hQlRDSVhKMlRlZ3BoelVW?=
 =?utf-8?B?dVBDejlQSHlzdlYveDd2Rml6dXV6allUYkFGU1Avckh5dTVTZmR6SzlLMmMz?=
 =?utf-8?B?bGhvZHBuWjB4WHd0a1J3a2VjSWFMOWJWQk5qY0ZVYWZaM0trSFZ5QmRQalFM?=
 =?utf-8?B?dUZDNWZuWStHMnhpdTMvZFRuMUo3bitrUURIM295elVibmFiMjBLRmRhRWtV?=
 =?utf-8?B?LytsbWtOSGtCMDFDRkhaZlpESkhYbkJueDU4ZG5sbEdjeDhGYmJOOG9nMkxQ?=
 =?utf-8?B?dFNIek11bU8yWVd1K0RmbnlLNXU4QnBmOWdnYnduNzZtbmNEWUp2RzFyYjl2?=
 =?utf-8?B?SDJwMi9LVVdrOUxsQ2pDVzR2SjNIYzJZdk5mWnEzSXN3bkcwWkF3MnY1UE81?=
 =?utf-8?B?cHZVWDdPNFFWcDVEdlp0Yy9ibzRrRTJaYmp1UHRhU3ViK25yYm1ad1NOalVh?=
 =?utf-8?B?bkhEenVLMlRSZ3pTTFplVUREK0R0YloraXZiSHpOREFqOTJEcmxOblhzYVVl?=
 =?utf-8?B?L3crQ0ovbGxBTGNCMjNCTlhjTXI4NzRNK0xwSFRyaVFFYml1SkxQZW1ZZjlP?=
 =?utf-8?B?T28xVjBPM2p1L2ZDVWJ4RHkvUFROQmQvbVYva1JRTktzZVRiTDJCS1FEbmtD?=
 =?utf-8?B?a1dpMVlqYlROYUdsQVUwd21QU3Z1MDdYREtGRnE2eHZvS0t3M1pPZ3VKRklY?=
 =?utf-8?B?Qmt0KzI1c08rM1pyRS9UcjhyOCtnZXpIUUpwK3VkUEpGUTdXS0h6RzlWZ2ds?=
 =?utf-8?B?aE9NQW9NZFFxUWtFVHFEdzN1dTRORjU1YzRwcjJzWTk1K2xvUlRtaGVjNytF?=
 =?utf-8?B?WU9YNzBpT2V4UUt0NThDK0wrV3VHV1hzNENReUh3OE8wL1F2OXFRK213ZUY2?=
 =?utf-8?B?SG4yeUNFZGtpd1hhVDBJQXJLMUk1RkdkMnVLT3o0VkRSMjJvczRwd2JPd3Qx?=
 =?utf-8?B?b20xbWtOWVZoRGVzRE5CcVc4b0R5YW9NOVFnS1hZTTZadFRvWlZhd3prVWtx?=
 =?utf-8?B?bjdtQW9SaFNCMXVtaThPcm4zMk9jTVNEZEgvZ0c3Zy9KaDZkTnRIWCsybGt3?=
 =?utf-8?B?NjdBdVJNVWpvMHNwSWZmQ290Uk5IaHJaZzZEVHlHZ1lpQ3MzUTJTZVhQeGY5?=
 =?utf-8?B?YzRDUklHdFJLbFU5SWRaRmhPSzdLWHJQWFVGT0xoWE5jZ0N1d0VySjUwdEo4?=
 =?utf-8?B?TEJPcEUwSU1oeUY2WnNoci9HUVg4a0NWOE04djVZT2xHS0ZHT2tOVGIvTnQv?=
 =?utf-8?B?U3kram1LTkVuMXdGNEVaUmI0NzYrVTEwTWtnZmhVN3NLVTJoQ2NiajZjZlpK?=
 =?utf-8?B?OFJHK0tmYkdRVk9aaVAyN05RWmZFVlhXVVhBeUNaY1V1TG83cFZlbHA1dHc2?=
 =?utf-8?B?dk5ncXQvRjRDZEk4QUlhWTBpaDU2QzVtcUNCZmRaQXZsSzdRQ3BBWVZ2ZXpY?=
 =?utf-8?B?UmxCdnlkUmdEUlowdWphSTJBQVhPc0lWTVhyaWRzRWJaU2hPakdGWlBCTlV3?=
 =?utf-8?B?emNDYW8vK3ZYaktjR1B3V0tCa0J1L1JEZ05scDlrR3lmd0tQTVRNV1dQMndN?=
 =?utf-8?B?eVVWU0VKV3ZzK2FyVEhIM2l3QzBXQnltd01yTWttL2w0bjV4dDJFN044VE15?=
 =?utf-8?B?U1FUL1Y2dVNyVm1pQ0ZYQWoyT2h5L3ZobUUzK2c2MUora2lFUWRtY05JVW9h?=
 =?utf-8?B?cXJoY0FJT1c1bHFZOFMyd0wwb1FGdFIyV1YwUEtSZFFKQkpIaFJkZnR6T1Ry?=
 =?utf-8?B?MUt1bHc4Ykx6SzJ1MkNMVFQyV3RyNlN2Q2NIeEwvUVZEL2lCUCtLcGtWTEc3?=
 =?utf-8?B?MDBGOGdycWRsRGJPM1dtME9Bd1RFR1VIcDltVGxoUkR5QWdUT2pTNWhTNmF4?=
 =?utf-8?Q?HTaTkUl/q/bwkoOIH+xKucOub?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ef4a2abc-d2d9-4d22-e82c-08dd92b59965
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5277.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2025 07:04:41.9103
 (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: ZGPwmXvUa/1uW96acPz5ZRBPo3Vnt1fNbfYpD6GStAj43WZxXbe1oasQuBGOZ30I
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8312



On 14/05/2025 08:56, Jan Beulich wrote:
> On 14.05.2025 08:31, Orzel, Michal wrote:
>> On 14/05/2025 02:07, Stefano Stabellini wrote:
>>> On Tue, 13 May 2025, Stewart Hildebrand wrote:
>>>> All functions in dom0less-build.c should be __init.
>> Why? This patch is first in your series and by that time there is no build time
>> enforcement. Together with the Fixes tag it implies that this is somehow an
>> issue (i.e. build/runtime issue) other than inconsistency for which we surely
>> don't need Fixes tag.
> 
> I disagree: Code not called post-init should be in .init.*. While not formally
> a Misra violation (and wrongly so, I think), it imo effectively is: Such code
> is otherwise unreachable post-init.
You have a point here, I agree. Although I don't think MISRA differentiates
between unreachable in general vs pre or post init. It defines it as code that
cannot be executed. It does not go into stages of runtime execution.

I'm thinking how this is different from a function that is called e.g. only once
at specific point at runtime execution for which we did not come up with a
separate section?

~Michal



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:08:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:08:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983837.1370010 (Exim 4.92)
	(envelope-from )
	id 1uF6EP-0001qf-7U; Wed, 14 May 2025 07:08:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983837.1370010; Wed, 14 May 2025 07:08: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 1uF6EP-0001qY-4u; Wed, 14 May 2025 07:08:45 +0000
Received: by outflank-mailman (input) for mailman id 983837;
 Wed, 14 May 2025 07:08:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF6EO-0001qP-Ar
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:08:44 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20614.outbound.protection.outlook.com
 [2a01:111:f403:2413::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 44741ad4-3092-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 09:08:43 +0200 (CEST)
Received: from DM4PR12MB5277.namprd12.prod.outlook.com (2603:10b6:5:390::7) 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.20.8722.29; Wed, 14 May
 2025 07:08:40 +0000
Received: from DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e]) by DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e%3]) with mapi id 15.20.8722.027; Wed, 14 May 2025
 07: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" 
X-Inumbo-ID: 44741ad4-3092-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iWo8yapL69qsgNiC8m+AAg+50ORynp00Hxr6yI4xbGZgwHmHkQNqxIcXOs6jbCU20bZTKuJsDh8uEm85mkam4gV03G7JVkRnJTCkUc1oYNW+t5Qf6YTw/pVcNrEzHXi6q/Lmz5C7LtZM9FfRDZJ1A6exzaQ6UK7tUEy60E1Tzh+pDEbkQnxkvNttssgcdOdnNeopfimv3hzdAE5sGhF4XcmzfTNL4MY0AF+A7nAZbPqKmP6CbWXqDR3UkkD/rdi7RhnBlOnR+BZwnSn+YOY4lytkiUfyC37r3dujdhmaPT3A9cEz769dGkSxrDFS9jdVe0ZvMF/AWis8lWi4xwkR1Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XSug5UFo8aZiLYMizIuP0bAvaM6rQ3x7gEg8lrds+z4=;
 b=xVZRO9TSPVvpbX5h+ASjU9LgmS+TvOS81lruG5Wb5etiYj79ugYy0dDgaaVaPnbSOYuhp52jWgEhQWfCXHnt0p5GhsAaw0qp40iN1CsyT4HTS4l/gbZw+umGIhnBOj8Ck0FA7VclYuZpHdzJZ439Nf6SfNDPASAurlwTavDmUDewNAsNRmosGxianVXyzUMdwg4BVW8ChpiLgrhJ89VQxVanhuGCRSOlCtFwewcbr4X6P6fQ9/HbORtufwRMp4lS279rf7YIZ8H3opt4mY/dXxTRuGqASEKl3C135eZ/QvK8qlQStcYaePRft0hF+vFS+5KnhlnI+QJvSLLgNw+EFw==
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=XSug5UFo8aZiLYMizIuP0bAvaM6rQ3x7gEg8lrds+z4=;
 b=A6kd7y2cjvGKXAWtYpB/UouZEZSuJi9mStj9SDbGLVqR8sYzIH79Hd8nDXwYd0ZPX04RBRpMVEhn7f9poHQgcFnLvvy0UWE3D67f3lut/g3W/Onv4QFDaoawyYWbLG+xGVfHZfHbzWpQLq+mXWL7SUzKaGIup+K9mnhMNoG7O6o=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <62f55484-aa91-48c9-9e80-97fcd8c919de@amd.com>
Date: Wed, 14 May 2025 09:08:35 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU
 construction
To: Oleksii Kurochko ,
 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: 
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0122.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:b9::6) To DM4PR12MB5277.namprd12.prod.outlook.com
 (2603:10b6:5:390::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR12MB5277:EE_|IA1PR12MB8312:EE_
X-MS-Office365-Filtering-Correlation-Id: d134581a-2714-4e18-8e52-08dd92b6273a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|366016|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZzUzT0hyblhWcjhlbGVZOEZ0eTZTMEM5YVU1cENMWTU2SlliU1pDdkJSekhh?=
 =?utf-8?B?bzZoOUFYZElFL1dkdjBEV28vbUttUU81Q0RDRkMvUERUSnVIZGlVdlVnOHdU?=
 =?utf-8?B?ODhZeENlZzgxVms3bCtJakZqVVNOc29FRE0wdWpOYk1SMWhkVU9EUWNpSUZ5?=
 =?utf-8?B?cWZGRE5PQ2s4eGphSDRuU05CMlo0cDYxdXdacG5POTEzeGgxZzJBWWs0Q2h3?=
 =?utf-8?B?ayt2Szl4MHZ5ZXNvRHhqUCswZ2xWY2ZjaVVQVDNYbWZ4aXY3ZkNCK0JUUUlh?=
 =?utf-8?B?cTJSTEIrTHRKQVFwS0d1c3pHaWdvNWVIK3dTSCszOE5ncHFScklRQ3hmN1hu?=
 =?utf-8?B?ZjgxaGl3K3FDaHcwTWxET2ZoR0JzcGEzTFFQRGhqUUZBYzBmS3hTUXlSeXlx?=
 =?utf-8?B?ZTc1TXE0UURtWWJReWU3RlVJTmtxbGsxSjF0UXd1QjBYYVlmR3ZicGFRVmk3?=
 =?utf-8?B?NWJ1UldWVFREVlV2RS85SjNrcGZjK0NOdVk2K0RnUERPNE9LS1cvUC9UTFdx?=
 =?utf-8?B?ZlRUVld3TFpXdjVPVlIrOWNwOTFxL0NyN2hWMm5OQ283dVdoVU9IRUIyc3BO?=
 =?utf-8?B?eVAxaGlaWWROM2VjUjRLb3lYQ1orWGFtN1pkR0ZOa2ttZnlVY0Z1Y3RYQ3c2?=
 =?utf-8?B?S0s2QUIrK1hGL0lFaEZmVGVqRlpTZ3hxbFh4cDZIbkJhemJ4cEpEVlU1dDV3?=
 =?utf-8?B?anBWNXdiN21CRFFaRHhlWFZoVjNobFZ3T1VKWkwvTVkvYzNvMjFQTWYrM2VT?=
 =?utf-8?B?S2V0Ky9rWEpoNGlsWm9JdDd5K3gxYVBCZ045WmJNUmEycS9aTk1welBMbHdH?=
 =?utf-8?B?TUVKVnlTVFlqbkhvc1hzYzRjcEJZVjFXUFY5ZEMxcXFTcHZHZUxRWW9tRnI1?=
 =?utf-8?B?RTVMa3JMNzZnREVMTE1tL1ZlOWlkaVhDWjZYbjFZcnRwUzdoZlFRWVg4RUVx?=
 =?utf-8?B?YW04ZUhEOXgrcE4vQVdRWm5aVkUvb2JtQjhIeWNvUTRQN01VL2t1VGtxRW1M?=
 =?utf-8?B?bFVEKzZRd280d3JkYktkdEpvRTk0azBsYmZrZkV6MlREYWhETkt1bWoyZVpq?=
 =?utf-8?B?a3ZjUXAzN0cyODVFTDhJTkUyUklGMVNpcFRrYzhtWnIzaXlJcWVXTTQ4eHZ4?=
 =?utf-8?B?T1pRc29ZTEhtODR5dktkNTVjTGh6cUR2TFJHdkJBSE5vbFpTYlZQVFFiQmxJ?=
 =?utf-8?B?UVlPcTZ2Mi9pUHk1ejNlUFE4SzFMNHZjbjY2cExzY2VMQXAyVFRqM1VrazYv?=
 =?utf-8?B?Zm4xT2tlSGN4UklFcWxxWTdjSE11aTExZzNxVEF0OWU4em56VnNIUGdoeVBn?=
 =?utf-8?B?UXZ6emhabzRic3JWamhvdVNtSHNTRkh2YVZFVXgydnNDcXl2eFAxVkhnVG9X?=
 =?utf-8?B?TjBvN0o0cGNNR3FRODFReDVBdnlsSkRsOTEzUWNpM29rbkl5UlNmcUNRb3V5?=
 =?utf-8?B?ZzdCeHFOZ00rOGdhdnpibUZmL1pVdSsyL3EzcEZoNTBxWmdXbEU5N1ZyNUJ5?=
 =?utf-8?B?Z3ZtTDE5UG5EMCtLWXVvNHVEUUhrL3ZTODhMNVhWZk5kSnc2TXh2L1hnV3Rx?=
 =?utf-8?B?R0RBQzJjaDEyZFNuV0RUL1NLUG9YenFLU0ovQmw2VllzSGlCdVZST1dvNk1I?=
 =?utf-8?B?QzFLQjRqNmplM1Fyd2lva0xmWndxVExzTDY5WSs2L2ZvNkJJUmFvMi9DWnls?=
 =?utf-8?B?SkVRM2pFaDNEZmhNeDRBZDlIQ080R0JNb0k3RU1ndDZCV2VCckRlNFhvZmVJ?=
 =?utf-8?B?eTgzUFlSMldwM0t2UXo4U3JzcHp6MkdrNGMvM1dpU2dGdzJuR1R0T09WbFBK?=
 =?utf-8?B?L2N1dzdvSWZkcHNQaG00cHpmNVZDekxpMndiTzYzbXB4Z0NEV3FHSDJRV240?=
 =?utf-8?B?djFIc1hjNklwYnhWOUN5WGJrTkJUbVp6UnR5THVFOWF0bmlFbnBGQjNQUDM3?=
 =?utf-8?Q?IWTwgEQznEE=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5277.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Z1M0WkVqN2JmN2Q4TTgvY2Iwc2psWHZFZVFZS3JCWEpadkwyUG55SlRWUFg0?=
 =?utf-8?B?VU0vbnUvTUFsTkNPb0xNd0ZmVVd5TmNXb3NOR0x5b0NYeWVBQStQem9RK0Nh?=
 =?utf-8?B?YzN2dUh1ZytTenFLejJhVjl3YmQ5RlExeVMySERvQjFMYlhRZXIxVU9TK09W?=
 =?utf-8?B?aTlLdmxXTmR5SDAyYkF4YjlGcTNQVW1ocDZtNHhwc2h5aUFEM0ZuVFZGQ01T?=
 =?utf-8?B?Y1NMSFdOMUNGTkJWWFQrMGkwQ2FMVXdUYlExS3FaWVdlcUpqWVIzQzdab1Er?=
 =?utf-8?B?b0FZTHc4bEZ4dlkvSEpNRno1d0RYaHN6OTVnVGpSaGdNOWx0TUg5SVBJY1Rk?=
 =?utf-8?B?ZlJmRnVXVGJrZTFyNVpCZThkeWFUZHdPOFJqZnFIZlZNSjNEZzVicUIwWmVG?=
 =?utf-8?B?RFNTQUVTeFlyQjdxeGZqOUkza0MwV0lqSm9UaWI3MnhtSFhZUzlpZ25Qd3pv?=
 =?utf-8?B?cVNwZTNUQnoxbWVFb3dOYld1aTdDNmN2K3RPaG42RHJPSUpRU2owZnN4WFZK?=
 =?utf-8?B?VkFHWVduUUNLalRaSlZ1Tk44OUMwQWZTcFNxWmY0MDhBM2tYY0NSaW02RmJD?=
 =?utf-8?B?U0xzNjNhVVZlS0lTY1dEV2xWYzQ1U0NweURpeDZwWlRIdzdEN1dmZ3pvYzhG?=
 =?utf-8?B?NTNReEJIb1VCeXJwTTlEdlE3NFJjdE9pMnhDSitvVjdnVmI2VVJqTFNnS295?=
 =?utf-8?B?anJ0WUpvNjlYeFljOU9XdnZBT3U1MW9NbktOYlZ5MkxUS3V5OGRyMmlXZFdO?=
 =?utf-8?B?a283L3lacUsvZ2htTkx6NFdyeGd2dU9NK2pZM1pZdVlKcFI0SUxQM0htY3FW?=
 =?utf-8?B?OEo1c2lETDZjbEF5Vk1lZzJrdEZqZlpyL3lJWmVtY0NuSHQxYnBhc1VwQnpp?=
 =?utf-8?B?MDlzR0k1SlluZ3ZIYkl6dGFrQVV6MWQyTWN1UUg2cHIxVXRXeVROM2tLeEtH?=
 =?utf-8?B?R0p6c3hMMHdjTjlWTFlhVDFYMlBGQXdQblZndUQydS8yblM1TlRyemFpaVYz?=
 =?utf-8?B?WG04RHhnVEJrU3cyY2dGWGtwNW9ETGdNSWZvbkVWN2NKbU16Z0U3Mld2Zkha?=
 =?utf-8?B?MHJyYnB6REU5YTUwK0h1NC80VWQ1bXMzNkNxbndXOGxEaFF6V2tvZFV0aGNy?=
 =?utf-8?B?bThjMnRheU85cUpSWFR5VVZ0WDFSeFBzZW5LY2YrOENOTWdJVTJBNmJVelhG?=
 =?utf-8?B?OWx4ekJnY3puOXBSNW5QNFNjcTRmRWtxaGsvaEx6cFM5TEcxSFlRczJrc1Rm?=
 =?utf-8?B?UWpGNWxKUE0rSTVBZDVpcmtZTEFsZGZHTzk1NDRHL3ZORm5meUduMnpsbks5?=
 =?utf-8?B?TVc2ZXZMbFFlYVBYZGkxR1RHeFRxQksxeVhFQXBKL3NUcmhlK3hkNVVjaFBS?=
 =?utf-8?B?QUVtM2VySCtRQkR3NXQ2UUIzM0RySXpUZnMxVmZPQWtTKytTK2dERFltUGMr?=
 =?utf-8?B?NE1TeStDS2pEV1Z3ZllrSDM5ZHU5NlROVVo2Z3N1TEtmN0xUb1ZTQi8xRUo4?=
 =?utf-8?B?Mk1JNEU4M0E3VDhMZGFSaWpSNVpGY2F6SS9PbUxteTVQRzZiSFdHNmZYQmVW?=
 =?utf-8?B?VGY4WFRFdUhycGM3dHE5bDMwdDh3c21LZEY1SndYcHBHb3VlV21aTDNBZU1K?=
 =?utf-8?B?aFAxQ1RZK0ZodHZCcENDTkVBQjRqU0lUT1AvcVo5MUNEeU9EL0hPSGpYb3ZW?=
 =?utf-8?B?UEFwY3M1TXRjN2MvU1FqcFNyTWVuUVB3VHBPOEdhcnZyM0dkS1JtakRSaDZ5?=
 =?utf-8?B?b2tUNUNQOVIxYkd6VDVZdERnUnNMZU5Gd3RuSTVPbHlsTjEwNEFHZHp4aWJa?=
 =?utf-8?B?OExkVkJibmNDejREUU5pa3pNQW5UNmdudndUVHZ2RGhzTTg4eHQ5WFF2TUs4?=
 =?utf-8?B?cmhpbnV2V28xRnpNTENKV0x2aVpQOWh5WVlxd0tXQ3BBaURUNVpmWlhuV0Qw?=
 =?utf-8?B?cDRnWFdxK25TM0I3TmNrVEhxYlVOcC8yN2E1QzJRZGRGODZHTGU4M3k2djc1?=
 =?utf-8?B?eGVGc01iRFg0eFplN21XVmpPOFIwQXk0MjJlbVRQY1hnR3d3RG1Vd1NoaFpa?=
 =?utf-8?B?Mm9YSlE4S0EzYjg0LytOblMyakw2U1B1Z0V1NURXL2Z1VkZ4STJyQ0xVSXBR?=
 =?utf-8?Q?yThtvBeFQNdizLuahhmiZrTs2?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d134581a-2714-4e18-8e52-08dd92b6273a
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5277.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2025 07:08:39.8891
 (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: vhSxBv54Y1Xo/uiy8KOrRYQfeUWH5ZjnU0HlCDg0pwh+scT8GZhUpgo1wgQlvMb1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8312



On 13/05/2025 16:29, Oleksii Kurochko wrote:
> Refactor construct_domU() to improve architecture separation and reduce
> reliance on ARM-specific logic in common code:
> - Drop set_domain_type() from generic code. This function is specific
>   to ARM and serves no purpose on other architectures like RISC-V,
>   which lack the arch.type field in kernel_info.
> - Introduce arch_construct_domU() to encapsulate architecture-specific
>   DomU construction steps.
> - Implement arch_construct_domU() for ARM. This includes:
>   - Setting the domain type for CONFIG_ARM64.
>   - Handling static memory allocation if xen,static-mem is present in
>     the device tree.
>   - Processing static shared memory.
> - Move call of make_resv_memory_node() to Arm's make_arch_nodes() as
>   this call is specific to CONFIG_STATIC_SHM which is ARM specific,
>   at least, now.
> 
> This cleanup avoids empty stubs on other architectures and moves
> ARM-specific logic into arch code where it belongs.
> 
> Also, don't loose  a return value of functions called in
> Arm's make_arch_nodes().
> 
> Suggested-by: Michal Orzel 
Thanks, it looks better now.

> Signed-off-by: Oleksii Kurochko 
Reviewed-by: Michal Orzel 

possibly with the remark from Stefano fixed.

~Michal



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:09:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:09:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983839.1370021 (Exim 4.92)
	(envelope-from )
	id 1uF6Eq-0002Hb-Ed; Wed, 14 May 2025 07:09:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983839.1370021; Wed, 14 May 2025 07:09: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 1uF6Eq-0002Gw-Bd; Wed, 14 May 2025 07:09:12 +0000
Received: by outflank-mailman (input) for mailman id 983839;
 Wed, 14 May 2025 07:09:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uF6Ep-0001qP-AW
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:09:11 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 55842e2d-3092-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 09:09:10 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5fca2805ca4so7901535a12.1
 for ; Wed, 14 May 2025 00:09: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
 4fb4d7f45d1cf-5ff8c016a16sm1369403a12.2.2025.05.14.00.09.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 00:09: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" 
X-Inumbo-ID: 55842e2d-3092-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747206550; x=1747811350; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YoC5otRfYaoYgWdIKPd+seYGPSywRjB8myPrW0/fU1E=;
        b=Gohujve7CkhdrCQnO9RPhUXvxDabEZYCJINcWNj7Eftg45Iv266Ei7FXE26/cOuutC
         +34p1wPosbHU1ajhXVWuuPwJMvdRw4PTGoEYnNleyWJXxq7dEW3hgBYnrhErXje10+Ea
         PXp0RmcS8/mLMuiSUKN+AINg2McUhwpbBhX5fHtnXjFXYfEiOQB1M7sPj0EW5QAEhjtm
         DC8ECFIkcIHMALaPy5v/sZ0fsxbCmXFtUytNUXrYWaLHqmsCIYkiNgHSog7WuCOuDAHm
         +QKkv7POT4pKBAqOUG7E2vYMGSCOxqF3vHHkHQefcI8OV8yGhQTYYBgeJQ/1kfiL3LSr
         nQFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747206550; x=1747811350;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YoC5otRfYaoYgWdIKPd+seYGPSywRjB8myPrW0/fU1E=;
        b=RSccg5BggVfui4vovr0GYaTehnRkS00mkFpZM6wnN7JML8kwa5E9TGJIytT1JQiugb
         Dt+RDe518w7ySgYD7VtQ/gW8yaCJOqPK7UteIsqiX0Trc2vypxh65pqE9341L5plOYlN
         69vsxTbK5YhxbtQYy+fx2sfpfqJuSKLS7nopRcc/1FRZZASiHrU5IEkB7IQUuVe9K1cI
         icsV0wXU+Sr1QAyVYjcPtFioUvA9srHgGp8Wa8GDvRkKGaS5tI5wRZ9VIl6AiBABFRmi
         uVMOjgHDNlLc126PmsVClrPplHGAKe6e5LKdxNQe09T94tdiW7oYhS6JtQDSokuwbQuC
         6mwg==
X-Forwarded-Encrypted: i=1; AJvYcCWO8nJx3ppcdiQ5DVS+eesfMKSPi08eRzrMp4MdmvZUfLcBtaeqgW2KwkbrjaVCtJhS7QBgG4gGc9U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz5fezCcAafwy+MR+ZRvP/13J/a9ssJnqv5GPYXQi0IKfhXbTw5
	t+xVnDRGuTsrMokdv/vtOITbLGnIAtyqLwi+9JiXQKeXgycfYfoKuSSs0OV3DA==
X-Gm-Gg: ASbGncsP2AhUGFE+8XxzguWU2RJIAVEsK359jSknUlLWqdioZVCPnLXWvPTPfSpz8oS
	TarVWrPmIBtZoFhP7LAG3/w8jdLm9OGXqT16piMalVO/PiwlvNTt/lredlYl6oZbg069zb320Lf
	CzFF3JlFYrV36us3um0Tszs5j4Fg03MUDfTOaL+yxU/YGfD8kIijfUzeZzIyFOE1txO7jhZALfy
	N+24p4wq4F/ChmI6a3Xgl8oJV+EsCR015UQb6B/dMmV8Jfd4Lh9TiqRMjQCsunZdkExayE9FZVI
	g1jgQoIPhmPkMQretvPD1R/JgA7afOxFAvhCYd8z/Uq6Bsz/LN0KdC01sbPRHgltEhQkFnrUMNj
	jnP17pG58GHwXnOC6vvUEIpk8+0XZqSXawkIb
X-Google-Smtp-Source: AGHT+IEsBEFMZvYnDMbTKcoG1TcS2xu7UuEC3b2mQw8W3AM2ff6bEctE18HnwCeHyfvdfwc58aqoeA==
X-Received: by 2002:a17:907:728a:b0:ac2:cdcb:6a85 with SMTP id a640c23a62f3a-ad4f712bf42mr202097866b.22.1747206550049;
        Wed, 14 May 2025 00:09:10 -0700 (PDT)
Message-ID: <70e5eeee-f1fa-41b4-91eb-450edc0bcaca@suse.com>
Date: Wed, 14 May 2025 09:09:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Assertion 'desc->arch.creator_domid == DOMID_INVALID' failed
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 xen-devel 
References: 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13.05.2025 21:20, Marek Marczykowski-Górecki wrote:
> Hi,
> 
> When debugging CI job on Linus' master branch, I added "console=vga vga=,keep" and got PV dom0 crash Xen with:
> 
> (XEN) [   40.870435] Assertion 'desc->arch.creator_domid == DOMID_INVALID' failed at arch/x86/irq.c:294
> (XEN) [   40.886925] ----[ Xen-4.21-unstable  x86_64  debug=y ubsan=y  Not tainted ]----
> (XEN) [   40.903356] CPU:    10
> (XEN) [   40.919824] RIP:    e008:[] create_irq+0x272/0x339
> (XEN) [   40.936267] RFLAGS: 0000000000010297   CONTEXT: hypervisor (d0v13)
> (XEN) [   40.952709] rax: 00000000fffffff4   rbx: ffff830498007c00   rcx: 0000000000001899

There looks to be a -ENOMEM in %rax, so ...

> (XEN) [   40.969147] rdx: ffff830498007c5e   rsi: 0000000000000002   rdi: ffff83049830e398
> (XEN) [   40.985892] rbp: ffff830498307d18   rsp: ffff830498307ce8   r8:  0000000000000000
> (XEN) [   41.003093] r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) [   41.020279] r12: 00000000fffffff4   r13: 000000000000007c   r14: ffffffffffffffff
> (XEN) [   41.037489] r15: 000000000000007c   cr0: 0000000080050033   cr4: 0000000000b526e0
> (XEN) [   41.054699] cr3: 0000000492c34000   cr2: ffff8881001603f0
> (XEN) [   41.071904] fsb: 0000000000000000   gsb: ffff8882365ac000   gss: 0000000000000000
> (XEN) [   41.089116] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) [   41.106320] Xen code around  (create_irq+0x272/0x339):
> (XEN) [   41.123521]  3f d9 ff e9 cc fe ff ff <0f> 0b 48 8d 3d 5a a0 29 00 e8 f4 3d d9 ff c6 43
> (XEN) [   41.140739] Xen stack trace from rsp=ffff830498307ce8:
> (XEN) [   41.157931]    000000ff00000001 ffff830497faa000 ffff830498307e00 00000000ffffffff
> (XEN) [   41.175132]    0000000000010000 ffff830497faa160 ffff830498307d70 ffff82d0405a6f85
> (XEN) [   41.192351]    00000000000002a0 ffff830498307e24 0000000000000200 00000000ffffffff
> (XEN) [   41.209551]    ffff830497faa000 0000000000000000 ffff830497faa168 0000000000010000
> (XEN) [   41.226753]    ffff830497faa160 ffff830498307de0 ffff82d0405c9ea6 5f24a0ddbbeda194
> (XEN) [   41.244062]    ffff830498307e10 0000000000000000 0000000000000001 ffff830498307e00
> (XEN) [   41.261387]    ffff830498307e24 ffff830498307e20 ffff830497faa000 ffff830498307ef8
> (XEN) [   41.278730]    ffff830497faa000 ffff830497f5a000 ffffc9004002ba78 ffff830498307e68
> (XEN) [   41.296052]    ffff82d0405cbd4f ffff82d04053fc3e ffffc9004002ba78 00000000000000a0
> (XEN) [   41.313381]    00a0fb0000000001 0000000000000000 0000000000007ff0 ffffffffffffffff
> (XEN) [   41.330708]    000000a000000000 0000000000000000 0000000000000000 ffff830498307ef8
> (XEN) [   41.348026]    ffff830497f5a000 0000000000000021 0000000000000000 ffffc9004002ba78
> (XEN) [   41.365357]    ffff830498307ee8 ffff82d0405427db ffff8881d6961b40 0000000000000001
> (XEN) [   41.382680]    000000a000000000 000000000000000d 0000000000000000 ffff830498307ee8
> (XEN) [   41.400003]    ffff82d0405e7bc2 ffff830497f5a000 0000000000000000 ffff830497f5a000
> (XEN) [   41.417343]    0000000000000000 0000000000000000 ffff830498307fff 0000000000000000
> (XEN) [   41.434674]    00007cfb67cf80e7 ffff82d0402012d3 ffff8881d6961b40 ffff888100ef30c0
> (XEN) [   41.452010]    0000000000000001 0000000000000005 0000000000000000 ffff888100ef3000
> (XEN) [   41.469342]    0000000000000202 0000000000000001 0000000000007ff0 ffff8881d6961b40
> (XEN) [   41.486681]    0000000000000021 ffffffff8229d355 000000a000000000 ffffc9004002ba78
> (XEN) [   41.504015] Xen call trace:
> (XEN) [   41.521314]    [] R create_irq+0x272/0x339

... I'd expect the function calling init_one_irq_desc() to have caused this.
In which case, yes, the assertion is certainly valid to trigger (as it's
arch_init_one_irq_desc() which sets the field to the expected value, yet
that won't happen if one of the involved allocations fails). I'll make a
patch, but this raises the question of how you're running Xen, when
seemingly small allocations like the ones involved here end up failing.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 07:13:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:13:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983858.1370031 (Exim 4.92)
	(envelope-from )
	id 1uF6Ir-0004Jo-2V; Wed, 14 May 2025 07:13:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983858.1370031; Wed, 14 May 2025 07:13: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 1uF6Iq-0004Jh-Vb; Wed, 14 May 2025 07:13:20 +0000
Received: by outflank-mailman (input) for mailman id 983858;
 Wed, 14 May 2025 07:13:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF6Ip-0004JZ-F8
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:13:19 +0000
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net
 [130.76.144.163]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e6bffcd6-3092-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 09:13:16 +0200 (CEST)
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
 54E7DDEt014098; Wed, 14 May 2025 03:13:13 -0400
Received: from phx-av-01.mbs.boeing.net (phx-av-01.mbs.boeing.net
 [137.136.102.153])
 by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with
 ESMTPS id 54E7D3kn014026
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)
 for ; Wed, 14 May 2025 03:13:03 -0400
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
 54E7D2da008202; Wed, 14 May 2025 00:13:03 -0700
Received: from localhost.localdomain ([144.112.81.43])
 by phx-av-01.mbs.boeing.net (8.15.2/8.15.2/UPSTREAM_RELAY) with ESMTP id
 54E7CtL2007958; Wed, 14 May 2025 00:13:00 -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" 
X-Inumbo-ID: e6bffcd6-3092-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com;
	s=boeing-s1912; t=1747206793;
	bh=1Yr2jbEn9COVInZYVVMSkIcvU1ytJWJjBPVPWMZKdFM=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=ufMBdsT3MxCWE2Oj+ape6o3c/XdxqLrH1MU9VpMa5vp+/kG7tzPExKowlIGA8mw6G
	 0m38LEyRwbFgPKNvIvVb0SLXSTERW7FHbjZn68fIVSaymr+PG0lLeriw9hJAJSDhhi
	 1HsyVHnjjNUZxHBjQNYKjMHea+KCZz9boVmTsQ8AKBIcmN3ZQgECEDJMJHmV6g1RrR
	 3EN6GxjsCy3MGVD7w2RqyQOhse8Uqi+wksdYTg5PI/gtANIl+HN3KOPQNPDIERkx8c
	 MWu7fiWSZFFBWg7+Elpkg5em6fPS8gncn66T7xRQtZmiwLgVl4VKudBZum+N78V7WD
	 Sb24zWbsYRoNA==
From: Sookyung Ahn 
To: xen-devel@lists.xenproject.org
Cc: matthew.l.weber3@boeing.com, joshua.c.whitehead@boeing.com,
        Anderson.Choi@boeing.com, brian.j.wood2@boeing.com,
        haesun.kim@boeing.com, Sookyung Ahn 
Subject: [RFC PATCH 1/2] changes for minimal-xen-tools
Date: Wed, 14 May 2025 07:12:49 +0000
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00

---
 config/Tools.mk.in                   |  1 +
 tools/Makefile                       | 19 ++++++
 tools/Rules.mk                       |  9 ++-
 tools/configure.ac                   | 47 +++++---------
 tools/flask/Makefile                 |  4 ++
 tools/hotplug/Linux/Makefile         |  6 ++
 tools/hotplug/Linux/systemd/Makefile |  6 ++
 tools/libs/Makefile                  |  9 +++
 tools/libs/ctrl/Makefile.common      | 92 ++++++++++++++++------------
 tools/libs/ctrl/xc_private.c         |  6 ++
 tools/libs/ctrl/xc_private.h         |  7 ++-
 tools/libs/uselibs.mk                | 76 +++++++++++++----------
 12 files changed, 178 insertions(+), 104 deletions(-)

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 37c071961e..3880d7ada2 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -55,6 +55,7 @@ CONFIG_SYSTEMD      := @systemd@
 XEN_SYSTEMD_DIR     := @SYSTEMD_DIR@
 XEN_SYSTEMD_MODULES_LOAD := @SYSTEMD_MODULES_LOAD@
 CONFIG_9PFS         := @ninepfs@
+CONFIG_MINIMAL_TOOLS  := @minimal_xen_tools@
 
 LINUX_BACKEND_MODULES := @LINUX_BACKEND_MODULES@
 
diff --git a/tools/Makefile b/tools/Makefile
index 7d17211782..b4af073305 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -41,6 +41,24 @@ SUBDIRS-y += python
 SUBDIRS-$(CONFIG_PYGRUB) += pygrub
 SUBDIRS-$(OCAML_TOOLS) += ocaml
 
+ifeq ($(CONFIG_MINIMAL_TOOLS),y)
+SUBDIRS-y :=
+SUBDIRS-y += libs
+SUBDIRS-y += flask
+SUBDIRS-y += hotplug
+SUBDIRS-$(CONFIG_X86) += firmware
+SUBDIRS-$(CONFIG_LIBFSIMAGE) += libfsimage
+
+# do not recurse in to a dir we are about to delete
+ifneq "$(MAKECMDGOALS)" "distclean"
+SUBDIRS-$(CONFIG_QEMU_TRAD) += qemu-xen-traditional-dir
+SUBDIRS-$(CONFIG_QEMU_XEN) += qemu-xen-dir
+endif
+#SUBDIRS-y += python
+SUBDIRS-$(CONFIG_PYGRUB) += pygrub
+SUBDIRS-$(OCAML_TOOLS) += ocaml
+endif
+
 ifeq ($(CONFIG_RUMP),y)
 SUBDIRS-y := libs
 endif
@@ -55,6 +73,7 @@ endif
 
 .PHONY: build all
 build all: subdirs-all
+	echo "$(SUBDIRS-y)"
 
 .PHONY: install
 install:
diff --git a/tools/Rules.mk b/tools/Rules.mk
index cb3fd82c1f..fd4146fc7e 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -22,8 +22,11 @@ include $(XEN_ROOT)/tools/libs/uselibs.mk
 
 CFLAGS_xeninclude = -I$(XEN_INCLUDE)
 
-XENSTORE_XENSTORED ?= y
-
+ifeq ($(CONFIG_MINIMAL_TOOLS),y)
+	XENSTORE_XENSTORED ?= n
+else
+	XENSTORE_XENSTORED ?= y
+endif
 # A debug build of tools?
 debug ?= n
 debug_symbols ?= $(debug)
@@ -139,7 +142,9 @@ ifeq ($(CONFIG_Linux),y)
 xenlibs-ldlibs-store := -ldl
 endif
 
+ifeq ($(CONFIG_MINIMAL_TOOLS),n)
 CFLAGS_libxenlight += $(CFLAGS_libxenctrl)
+endif
 
 # Don't add -Werror if we are used by qemu-trad build system.
 ifndef BUILDING_QEMU_TRAD
diff --git a/tools/configure.ac b/tools/configure.ac
index 0dd6d747ab..a063bd4759 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -3,8 +3,8 @@
 
 AC_PREREQ([2.67])
 AC_INIT([Xen Hypervisor Tools], m4_esyscmd([../version.sh ../xen/Makefile]),
-    [xen-devel@lists.xen.org], [xen], [https://www.xen.org/])
-AC_CONFIG_SRCDIR([libs/light/libxl.c])
+	[xen-devel@lists.xen.org], [xen], [https://www.xen.org/])
+AC_CONFIG_SRCDIR([libs/call/core.c])
 AC_CONFIG_FILES([
 ../config/Tools.mk
 hotplug/common/hotplugpath.sh
@@ -32,7 +32,7 @@ AC_CONFIG_AUX_DIR([../])
 # Check if CFLAGS, LDFLAGS, LIBS, CPPFLAGS or CPP is set and print a warning
 
 AS_IF([test -n "$CC$CFLAGS$LDFLAGS$LIBS$CPPFLAGS$CPP"], [
-    AC_MSG_WARN(
+	AC_MSG_WARN(
 [Setting CC, CFLAGS, LDFLAGS, LIBS, CPPFLAGS or CPP is not \
 recommended, use PREPEND_INCLUDES, PREPEND_LIB, \
 APPEND_INCLUDES and APPEND_LIB instead when possible.])
@@ -90,36 +90,21 @@ AX_ARG_DEFAULT_DISABLE([ovmf], [Enable OVMF])
 AX_ARG_DEFAULT_ENABLE([seabios], [Disable SeaBIOS])
 AX_ARG_DEFAULT_ENABLE([golang], [Disable Go tools])
 AX_ARG_DEFAULT_ENABLE([pygrub], [Disable pygrub])
+AX_ARG_DEFAULT_DISABLE([minimal_xen_tools], [Enable Minimal Xen Tools])
+
+AS_IF([test "x$enable_minimal_xen_tools" = "xyes"],
+	[AC_DEFINE([ENABLE_MINIMAL_XEN_TOOLS], [1], [Enable Light Xen Tools])])
 
 AC_ARG_WITH([linux-backend-modules],
-    AS_HELP_STRING([--with-linux-backend-modules="mod1 mod2"],
-    [List of Linux backend module or modalias names to be autoloaded on startup.]),
-    [LINUX_BACKEND_MODULES="$withval"],
-    [case "$host_os" in
-*linux*)
-LINUX_BACKEND_MODULES="
-xen-evtchn
-xen-gntdev
-xen-gntalloc
-xen-blkback
-xen-netback
-xen-pciback
-evtchn
-gntdev
-netbk
-blkbk
-xen-scsibk
-usbbk
-pciback
-xen-acpi-processor
-"
-;;
-*)
-LINUX_BACKEND_MODULES=
-;;
-esac])
-LINUX_BACKEND_MODULES="`eval echo $LINUX_BACKEND_MODULES`"
-AC_SUBST(LINUX_BACKEND_MODULES)
+	AS_HELP_STRING([--with-linux-backend-modules="mod1 mod2"], 
+		[List of Linux backend module or modalias names to be autoloaded on startup.]),
+		[LINUX_BACKEND_MODULES="$withval"],
+		AS_IF([test "x$enable_minimal_xen_tools" = "xyes"], [LINUX_BACKEND_MODULES=],
+			[test "x$host_os"="xlinux"],
+				[LINUX_BACKEND_MODULES="xen-evtchn xen-gntdev xen-gntalloc xen-blkback xen-netback xen-pciback evtchn gntdev netbk blkbk xen-scsibk usbbk pciback xen-acpi-processor"],
+				[LINUX_BACKEND_MODULES=])
+)
+AC_SUBST([LINUX_BACKEND_MODULES])
 
 AC_ARG_ENABLE([qemu-traditional],
     AS_HELP_STRING([--enable-qemu-traditional],
diff --git a/tools/flask/Makefile b/tools/flask/Makefile
index 335ee2a090..07dc4ec587 100644
--- a/tools/flask/Makefile
+++ b/tools/flask/Makefile
@@ -1,7 +1,11 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+ifeq ($(CONFIG_MINIMAL_TOOLS),y)
+SUBDIRS-y :=
+else
 SUBDIRS-y := utils
+endif
 SUBDIRS-$(FLASK_POLICY) += policy
 
 .PHONY: all clean install distclean uninstall
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 9a7b3a3515..9b6d7bbed1 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -18,7 +18,9 @@ XEN_SCRIPTS += block-drbd-probe
 XEN_SCRIPTS += block-dummy
 XEN_SCRIPTS += $(XEN_SCRIPTS-y)
 XEN_SCRIPTS += colo-proxy-setup
+ifeq ($(CONFIG_MINIMAL_TOOLS),n)
 XEN_SCRIPTS += launch-xenstore
+endif
 
 SUBDIRS-$(CONFIG_SYSTEMD) += systemd
 
@@ -47,11 +49,15 @@ install-initd:
 	$(INSTALL_PROG) init.d/xendomains $(DESTDIR)$(INITD_DIR)
 	$(INSTALL_PROG) init.d/xencommons $(DESTDIR)$(INITD_DIR)
 	$(INSTALL_PROG) init.d/xendriverdomain $(DESTDIR)$(INITD_DIR)
+ifeq ($(CONFIG_MINIMAL_TOOLS),n)
 	$(INSTALL_PROG) init.d/xen-watchdog $(DESTDIR)$(INITD_DIR)
+endif
 
 .PHONY: uninstall-initd
 uninstall-initd:
+ifeq ($(CONFIG_MINIMAL_TOOLS),n)
 	rm -f $(DESTDIR)$(INITD_DIR)/xen-watchdog
+endif
 	rm -f $(DESTDIR)$(INITD_DIR)/xendriverdomain
 	rm -f $(DESTDIR)$(INITD_DIR)/xencommons
 	rm -f $(DESTDIR)$(INITD_DIR)/xendomains
diff --git a/tools/hotplug/Linux/systemd/Makefile b/tools/hotplug/Linux/systemd/Makefile
index e29889156d..4a35fcaa0e 100644
--- a/tools/hotplug/Linux/systemd/Makefile
+++ b/tools/hotplug/Linux/systemd/Makefile
@@ -5,6 +5,7 @@ XEN_SYSTEMD_MODULES := xen.conf
 
 XEN_SYSTEMD_MOUNT := proc-xen.mount
 
+ifeq ($(CONFIG_MINIMAL_TOOLS),n)
 XEN_SYSTEMD_SERVICE := xenstored.service
 XEN_SYSTEMD_SERVICE += xenconsoled.service
 XEN_SYSTEMD_SERVICE += xen-qemu-dom0-disk-backend.service
@@ -12,6 +13,11 @@ XEN_SYSTEMD_SERVICE += xendomains.service
 XEN_SYSTEMD_SERVICE += xen-watchdog.service
 XEN_SYSTEMD_SERVICE += xen-init-dom0.service
 XEN_SYSTEMD_SERVICE += xendriverdomain.service
+else
+XEN_SYSTEMD_SERVICE := xen-init-dom0.service
+XEN_SYSTEMD_SERVICE += xendomains.service
+#XEN_SYSTEMD_SERVICE += xendriverdomain.service
+endif
 
 ALL_XEN_SYSTEMD :=	$(XEN_SYSTEMD_MODULES)  \
 			$(XEN_SYSTEMD_MOUNT)	\
diff --git a/tools/libs/Makefile b/tools/libs/Makefile
index 1afcd12e2b..21dd501b4c 100644
--- a/tools/libs/Makefile
+++ b/tools/libs/Makefile
@@ -18,6 +18,15 @@ SUBDIRS-$(CONFIG_Linux) += vchan
 SUBDIRS-y += light
 SUBDIRS-y += util
 
+ifeq ($(CONFIG_MINIMAL_TOOLS),y)
+SUBDIRS-y :=
+SUBDIRS-y += toolcore
+SUBDIRS-y += toollog
+SUBDIRS-y += call
+SUBDIRS-y += foreignmemory
+SUBDIRS-y += ctrl
+endif
+
 ifeq ($(CONFIG_RUMP),y)
 SUBDIRS-y := toolcore
 endif
diff --git a/tools/libs/ctrl/Makefile.common b/tools/libs/ctrl/Makefile.common
index 247afbe5f9..cee4f6d2f7 100644
--- a/tools/libs/ctrl/Makefile.common
+++ b/tools/libs/ctrl/Makefile.common
@@ -1,41 +1,57 @@
-OBJS-y       += xc_altp2m.o
-OBJS-y       += xc_cpupool.o
-OBJS-y       += xc_domain.o
-OBJS-y       += xc_evtchn.o
-OBJS-y       += xc_gnttab.o
-OBJS-y       += xc_misc.o
-OBJS-y       += xc_flask.o
-OBJS-y       += xc_physdev.o
-OBJS-y       += xc_private.o
-OBJS-y       += xc_csched.o
-OBJS-y       += xc_csched2.o
-OBJS-y       += xc_arinc653.o
-OBJS-y       += xc_rt.o
-OBJS-y       += xc_tbuf.o
-OBJS-y       += xc_pm.o
-OBJS-y       += xc_cpu_hotplug.o
-OBJS-y       += xc_vm_event.o
-OBJS-y       += xc_vmtrace.o
-OBJS-y       += xc_monitor.o
-OBJS-y       += xc_mem_paging.o
-OBJS-y       += xc_mem_access.o
-OBJS-y       += xc_memshr.o
-OBJS-y       += xc_hcall_buf.o
-OBJS-y       += xc_foreign_memory.o
-OBJS-y       += xc_kexec.o
-OBJS-y       += xc_resource.o
-OBJS-$(CONFIG_ARM)  += xc_dt_overlay.o
-OBJS-$(CONFIG_X86) += xc_psr.o
-OBJS-$(CONFIG_X86) += xc_pagetab.o
-OBJS-$(CONFIG_Linux) += xc_linux.o
-OBJS-$(CONFIG_FreeBSD) += xc_freebsd.o
-OBJS-$(CONFIG_SunOS) += xc_solaris.o
-OBJS-$(CONFIG_NetBSD) += xc_netbsd.o
-OBJS-$(CONFIG_NetBSDRump) += xc_netbsd.o
-OBJS-$(CONFIG_MiniOS) += xc_minios.o
-OBJS-y       += xc_evtchn_compat.o
-OBJS-y       += xc_gnttab_compat.o
-OBJS-y       += xc_devicemodel_compat.o
+ifeq ($(CONFIG_MINIMAL_TOOLS),y)
+    OBJS-y       += xc_domain.o
+    OBJS-y       += xc_misc.o
+    OBJS-y       += xc_private.o
+    OBJS-y       += xc_csched2.o
+    OBJS-y       += xc_arinc653.o
+    OBJS-y       += xc_hcall_buf.o
+    OBJS-y       += xc_foreign_memory.o
+    OBJS-$(CONFIG_Linux) += xc_linux.o
+    OBJS-$(CONFIG_FreeBSD) += xc_freebsd.o
+    OBJS-$(CONFIG_SunOS) += xc_solaris.o
+    OBJS-$(CONFIG_NetBSD) += xc_netbsd.o
+    OBJS-$(CONFIG_NetBSDRump) += xc_netbsd.o
+    OBJS-$(CONFIG_MiniOS) += xc_minios.o
+else
+    OBJS-y       += xc_altp2m.o
+    OBJS-y       += xc_cpupool.o
+    OBJS-y       += xc_domain.o
+    OBJS-y       += xc_evtchn.o
+    OBJS-y       += xc_gnttab.o
+    OBJS-y       += xc_misc.o
+    OBJS-y       += xc_flask.o
+    OBJS-y       += xc_physdev.o
+    OBJS-y       += xc_private.o
+    OBJS-y       += xc_csched.o
+    OBJS-y       += xc_csched2.o
+    OBJS-y       += xc_arinc653.o
+    OBJS-y       += xc_rt.o
+    OBJS-y       += xc_tbuf.o
+    OBJS-y       += xc_pm.o
+    OBJS-y       += xc_cpu_hotplug.o
+    OBJS-y       += xc_vm_event.o
+    OBJS-y       += xc_vmtrace.o
+    OBJS-y       += xc_monitor.o
+    OBJS-y       += xc_mem_paging.o
+    OBJS-y       += xc_mem_access.o
+    OBJS-y       += xc_memshr.o
+    OBJS-y       += xc_hcall_buf.o
+    OBJS-y       += xc_foreign_memory.o
+    OBJS-y       += xc_kexec.o
+    OBJS-y       += xc_resource.o
+    OBJS-$(CONFIG_ARM)  += xc_dt_overlay.o
+    OBJS-$(CONFIG_X86) += xc_psr.o
+    OBJS-$(CONFIG_X86) += xc_pagetab.o
+    OBJS-$(CONFIG_Linux) += xc_linux.o
+    OBJS-$(CONFIG_FreeBSD) += xc_freebsd.o
+    OBJS-$(CONFIG_SunOS) += xc_solaris.o
+    OBJS-$(CONFIG_NetBSD) += xc_netbsd.o
+    OBJS-$(CONFIG_NetBSDRump) += xc_netbsd.o
+    OBJS-$(CONFIG_MiniOS) += xc_minios.o
+    OBJS-y       += xc_evtchn_compat.o
+    OBJS-y       += xc_gnttab_compat.o
+    OBJS-y       += xc_devicemodel_compat.o
+endif
 
 CFLAGS   += -D__XEN_TOOLS__
 CFLAGS	+= $(PTHREAD_CFLAGS)
diff --git a/tools/libs/ctrl/xc_private.c b/tools/libs/ctrl/xc_private.c
index abd0b0d849..4cd893a4fd 100644
--- a/tools/libs/ctrl/xc_private.c
+++ b/tools/libs/ctrl/xc_private.c
@@ -65,9 +65,11 @@ struct xc_interface_core *xc_interface_open(xentoollog_logger *logger,
     if ( xch->fmem == NULL )
         goto err;
 
+#if (ENABLE_MINIMAL_XEN_TOOLS != 1)
     xch->dmod = xendevicemodel_open(xch->error_handler, 0);
     if ( xch->dmod == NULL )
         goto err;
+#endif
 
     return xch;
 
@@ -92,8 +94,10 @@ int xc_interface_close(xc_interface *xch)
     rc = xenforeignmemory_close(xch->fmem);
     if (rc) PERROR("Could not close foreign memory interface");
 
+#if (ENABLE_MINIMAL_XEN_TOOLS != 1)
     rc = xendevicemodel_close(xch->dmod);
     if (rc) PERROR("Could not close device model interface");
+#endif
 
     xtl_logger_destroy(xch->dombuild_logger_tofree);
     xtl_logger_destroy(xch->error_handler_tofree);
@@ -107,6 +111,7 @@ xencall_handle *xc_interface_xcall_handle(xc_interface *xch)
     return xch->xcall;
 }
 
+#if (ENABLE_MINIMAL_XEN_TOOLS != 1)
 struct xenforeignmemory_handle *xc_interface_fmem_handle(xc_interface *xch)
 {
     return xch->fmem;
@@ -116,6 +121,7 @@ struct xendevicemodel_handle *xc_interface_dmod_handle(xc_interface *xch)
 {
     return xch->dmod;
 }
+#endif
 
 static pthread_key_t errbuf_pkey;
 static pthread_once_t errbuf_pkey_once = PTHREAD_ONCE_INIT;
diff --git a/tools/libs/ctrl/xc_private.h b/tools/libs/ctrl/xc_private.h
index d8b7da2805..18dffdf6fd 100644
--- a/tools/libs/ctrl/xc_private.h
+++ b/tools/libs/ctrl/xc_private.h
@@ -36,7 +36,9 @@
 
 #include 
 #include 
+#if (ENABLE_MINIMAL_XEN_TOOLS != 1)
 #include 
+#endif
 
 #include 
 
@@ -91,9 +93,10 @@ struct xc_interface_core {
 
     /* Foreign mappings */
     xenforeignmemory_handle *fmem;
-
+#if (ENABLE_MINIMAL_XEN_TOOLS != 1)
     /* Device model */
     xendevicemodel_handle *dmod;
+#endif
 };
 
 void *osdep_alloc_hypercall_buffer(xc_interface *xch, int npages);
@@ -400,6 +403,7 @@ int xc_ffs64(uint64_t x);
 #define DOMPRINTF(fmt, args...) xc_dom_printf(dom->xch, fmt, ## args)
 #define DOMPRINTF_CALLED(xch) xc_dom_printf((xch), "%s: called", __FUNCTION__)
 
+#if (ENABLE_MINIMAL_XEN_TOOLS != 1)
 /**
  * vm_event operations. Internal use only.
  */
@@ -411,6 +415,7 @@ int xc_vm_event_control(xc_interface *xch, uint32_t domain_id, unsigned int op,
  */
 void *xc_vm_event_enable(xc_interface *xch, uint32_t domain_id, int param,
                          uint32_t *port);
+#endif
 
 int do_dm_op(xc_interface *xch, uint32_t domid, unsigned int nr_bufs, ...);
 
diff --git a/tools/libs/uselibs.mk b/tools/libs/uselibs.mk
index efd7a475ba..c0ce4ef210 100644
--- a/tools/libs/uselibs.mk
+++ b/tools/libs/uselibs.mk
@@ -1,33 +1,45 @@
 # Libraries below tools/libs/ and their dependencies
-
-LIBS_LIBS += toolcore
-USELIBS_toolcore :=
-LIBS_LIBS += toollog
-USELIBS_toollog :=
-LIBS_LIBS += evtchn
-USELIBS_evtchn := toollog toolcore
-LIBS_LIBS += gnttab
-USELIBS_gnttab := toollog toolcore
-LIBS_LIBS += call
-USELIBS_call := toollog toolcore
-LIBS_LIBS += foreignmemory
-USELIBS_foreignmemory := toollog toolcore
-LIBS_LIBS += devicemodel
-USELIBS_devicemodel := toollog toolcore call
-LIBS_LIBS += hypfs
-USELIBS_hypfs := toollog toolcore call
-LIBS_LIBS += ctrl
-USELIBS_ctrl := toollog call evtchn gnttab foreignmemory devicemodel
-LIBS_LIBS += guest
-USELIBS_guest := evtchn ctrl
-LIBS_LIBS += store
-USELIBS_store := toolcore
-LIBS_LIBS += vchan
-USELIBS_vchan := toollog store gnttab evtchn
-LIBS_LIBS += stat
-USELIBS_stat := ctrl store
-LIBS_LIBS += light
-USELIBS_light := toollog evtchn toolcore ctrl store hypfs guest
-LIBS_LIBS += util
-USELIBS_util := light
-FILENAME_util := xlutil
+ifeq ($(CONFIG_MINIMAL_TOOLS),y)
+    LIBS_LIBS += toolcore
+    USELIBS_toolcore := 
+    LIBS_LIBS += toollog
+    USELIBS_toollog :=
+    LIBS_LIBS += call
+    USELIBS_call := toollog toolcore
+    LIBS_LIBS += foreignmemory
+    USELIBS_foreignmemory := toollog toolcore
+    LIBS_LIBS += ctrl
+    USELIBS_ctrl := toollog call foreignmemory
+else
+    LIBS_LIBS += toolcore
+    USELIBS_toolcore :=
+    LIBS_LIBS += toollog
+    USELIBS_toollog :=
+    LIBS_LIBS += evtchn
+    USELIBS_evtchn := toollog toolcore
+    LIBS_LIBS += gnttab
+    USELIBS_gnttab := toollog toolcore
+    LIBS_LIBS += call
+    USELIBS_call := toollog toolcore
+    LIBS_LIBS += foreignmemory
+    USELIBS_foreignmemory := toollog toolcore
+    LIBS_LIBS += devicemodel
+    USELIBS_devicemodel := toollog toolcore call
+    LIBS_LIBS += hypfs
+    USELIBS_hypfs := toollog toolcore call
+    LIBS_LIBS += ctrl
+    USELIBS_ctrl := toollog call evtchn gnttab foreignmemory devicemodel
+    LIBS_LIBS += guest
+    USELIBS_guest := evtchn ctrl
+    LIBS_LIBS += store
+    USELIBS_store := toolcore
+    LIBS_LIBS += vchan
+    USELIBS_vchan := toollog store gnttab evtchn
+    LIBS_LIBS += stat
+    USELIBS_stat := ctrl store
+    LIBS_LIBS += light
+    USELIBS_light := toollog evtchn toolcore ctrl store hypfs guest
+    LIBS_LIBS += util
+    USELIBS_util := light
+    FILENAME_util := xlutil
+endif
\ No newline at end of file
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:13:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:13:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983859.1370041 (Exim 4.92)
	(envelope-from )
	id 1uF6It-0004Xq-90; Wed, 14 May 2025 07:13:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983859.1370041; Wed, 14 May 2025 07: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 1uF6It-0004Xj-52; Wed, 14 May 2025 07:13:23 +0000
Received: by outflank-mailman (input) for mailman id 983859;
 Wed, 14 May 2025 07:13:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF6Ir-0004JZ-I2
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:13:21 +0000
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net
 [130.76.144.163]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e6bf49c3-3092-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 09:13:16 +0200 (CEST)
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
 54E7DDEr014098; Wed, 14 May 2025 03:13:13 -0400
Received: from phx-av-01.mbs.boeing.net (phx-av-01.mbs.boeing.net
 [137.136.102.153])
 by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with
 ESMTPS id 54E7D3lg014027
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)
 for ; Wed, 14 May 2025 03:13:03 -0400
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
 54E7D2dU008202; Wed, 14 May 2025 00:13:02 -0700
Received: from localhost.localdomain ([144.112.81.43])
 by phx-av-01.mbs.boeing.net (8.15.2/8.15.2/UPSTREAM_RELAY) with ESMTP id
 54E7CtL1007958; Wed, 14 May 2025 00:12:56 -0700
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e6bf49c3-3092-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com;
	s=boeing-s1912; t=1747206793;
	bh=tGgowmEjCeMgBFJGQbk9Nmldf+ksVlLvr0nD6YK9ygA=;
	h=From:To:Cc:Subject:Date:From;
	b=JEqTKCZtlm4umrdST4vnd8l3NCgMdwI32rTnQx2e6ADKpun/SugxPKjP6Y0z2tx0U
	 2CUa/xEbbYrSeUZOGae0VlecRsi1NZXcexMSU7bpiB7EMgg9TelcPM6hixExId4IrS
	 0OijPONSxUfq2FTSSw1PPbFsdw5JK26gDMlNg4cQ6mw5szQb0uVPPAoLzvo3byVr3Q
	 unk7e/ebbX8LWh/gjgFOlrVfNOmXNum0p4doIluqU/OJEW5paUejQ8H7nttY1PHZNn
	 PX5G3dP5/NaZlqByEEOawy7qwOMuDMVWW80wLcStfkBQPEHrLNHCx7x8lpMp3uLIWD
	 0BXUMkCx3MrfQ==
From: Sookyung Ahn 
To: xen-devel@lists.xenproject.org
Cc: matthew.l.weber3@boeing.com, joshua.c.whitehead@boeing.com,
        Anderson.Choi@boeing.com, brian.j.wood2@boeing.com,
        haesun.kim@boeing.com, Sookyung Ahn 
Subject: [RFC PATCH 0/2] Propose an minimal xen-tools
Date: Wed, 14 May 2025 07:12:48 +0000
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00

I am writing to propose an enhancement to the `xen-tools` for users who require only a minimal subset of its functionality, particularly in safety-critical domains like aerospace.

I believe that the addition of a new build-time option, `ENABLE_MINIMAL_XEN_TOOLS`, will significantly benefit users by allowing them to build only the essential components needed for their specific applications. 
This approach not only streamlines the toolset but also reduces the potential for unnecessary complexity in safety-critical environments.
This proposal is based on `dom0less` environment.

The proposed implementation includes:
- Introducing the `ENABLE_MINIMAL_XEN_TOOLS` configuration flag.
- Modifying the build process to selectively include only the necessary components based on the configuration.

This implementation can be effectively applied to the following use cases. 
- Minimal APIs for `dom0less` operation. This involves taking existing Xen functions and shrinking them to minimal needed parts. For example, we can use static device tree instead of XenStore. 
- By retaining `libxencall` and minimum part of `libxencrtl`, the Hypercall interface can be utilized, enabling support for the Xen ARINC653 Multiple Module Schedules service. 
- Addition of ARINC653 Part1&2 APIs and services (hosted on the domain OS.)

I would appreciate any feedback or suggestions you may have regarding this enhancement. 
Additionally, I would like to emphasize the importance of community input in refining this proposal to ensure it meets the needs of all users.

Sookyung Ahn (2):
  changes for minimal-xen-tools
  add document minimal_xen_tools.pandoc

 config/Tools.mk.in                    |   1 +
 docs/designs/minimal_xen_tools.pandoc | 147 ++++++++++++++++++++++++++
 tools/Makefile                        |  19 ++++
 tools/Rules.mk                        |   9 +-
 tools/configure.ac                    |  47 +++-----
 tools/flask/Makefile                  |   4 +
 tools/hotplug/Linux/Makefile          |   6 ++
 tools/hotplug/Linux/systemd/Makefile  |   6 ++
 tools/libs/Makefile                   |   9 ++
 tools/libs/ctrl/Makefile.common       |  92 +++++++++-------
 tools/libs/ctrl/xc_private.c          |   6 ++
 tools/libs/ctrl/xc_private.h          |   7 +-
 tools/libs/uselibs.mk                 |  76 +++++++------
 13 files changed, 325 insertions(+), 104 deletions(-)
 create mode 100644 docs/designs/minimal_xen_tools.pandoc

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:13:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:13:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983860.1370051 (Exim 4.92)
	(envelope-from )
	id 1uF6Iu-0004m7-Fe; Wed, 14 May 2025 07:13:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983860.1370051; Wed, 14 May 2025 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 1uF6Iu-0004m0-CM; Wed, 14 May 2025 07:13:24 +0000
Received: by outflank-mailman (input) for mailman id 983860;
 Wed, 14 May 2025 07:13:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF6It-0004Xa-8z
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:13:23 +0000
Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net
 [130.76.20.194]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e9142e51-3092-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 09:13:21 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by ewa-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id
 54E7DH0Y014578; Wed, 14 May 2025 00:13:17 -0700
Received: from phx-av-01.mbs.boeing.net (phx-av-01.mbs.boeing.net
 [137.136.102.153])
 by ewa-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with
 ESMTPS id 54E7DDtd014540
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)
 for ; Wed, 14 May 2025 00:13:14 -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
 54E7DDpV008750; Wed, 14 May 2025 00:13:13 -0700
Received: from localhost.localdomain ([144.112.81.43])
 by phx-av-01.mbs.boeing.net (8.15.2/8.15.2/UPSTREAM_RELAY) with ESMTP id
 54E7CtL3007958; Wed, 14 May 2025 00:13:02 -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" 
X-Inumbo-ID: e9142e51-3092-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com;
	s=boeing-s1912; t=1747206797;
	bh=SqhQ9oLNBoOgUzMMxOjrt8HiB1Bp3rr566Xpah5pmvc=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=WtyXEAkx21/9WQleAn0FTSHD1Z45whBPDqdu+nbLxqqZS1/7OoQA+AOqdnwHmwq0V
	 5AdBFg7Zc1EA535yxkEACTlVu/3zYltHK3VwZ7vRaYEznVnpZt4AsRG8glqZoIJwYn
	 XmzWfjGTu4+YX/+Iqg7tebvIP38Tj0WI3uxjhREop0IJZ89GAFq4fg0K3XQTNAScSF
	 IwVmDjkeh5nuhqYtLjdvt1+fSJH/BwT8yxeHXWItdu4HcaYnZYKNhfCL/9KahoL0V1
	 HFcI3zEjcSGOcFOZf+NYkGe1960W2l1aUP7KNKbxqubNFjHO2BO9zj7uhRSVA9CNrZ
	 sZnDMtCfFecuw==
From: Sookyung Ahn 
To: xen-devel@lists.xenproject.org
Cc: matthew.l.weber3@boeing.com, joshua.c.whitehead@boeing.com,
        Anderson.Choi@boeing.com, brian.j.wood2@boeing.com,
        haesun.kim@boeing.com, Sookyung Ahn 
Subject: [RFC PATCH 2/2] add document minimal_xen_tools.pandoc
Date: Wed, 14 May 2025 07:12:50 +0000
Message-Id: <0267d6a430a11b9387d56514f963b6a5c6033450.1747205627.git.sookyung.ahn@boeing.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00

---
 docs/designs/minimal_xen_tools.pandoc | 147 ++++++++++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 docs/designs/minimal_xen_tools.pandoc

diff --git a/docs/designs/minimal_xen_tools.pandoc b/docs/designs/minimal_xen_tools.pandoc
new file mode 100644
index 0000000000..32e0e8d002
--- /dev/null
+++ b/docs/designs/minimal_xen_tools.pandoc
@@ -0,0 +1,147 @@
+- [Minimal Xen-tools](#minimal-xen-tools)
+  - [`xen-tools` : full vs minimal](#xen-tools--full-vs-minimal)
+  - [Components of minimal `xen-tools`](#components-of-minimal-xen-tools)
+  - [How to enable minimal `xen-tools`](#how-to-enable-minimal-xen-tools)
+  - [How to include a component which is excluded](#how-to-include-a-component-which-is-excluded)
+    - [Library](#library)
+    - [Tool](#tool)
+
+# Minimal Xen-tools
+
+Purpose : To enhance `xen-tools` for users who require only a minimal subset of its functionality, particularly in safety-critical domains such as aerospace. 
+
+## `xen-tools` : full vs minimal
+
+- total size of **full** `xen-tools` and **minimal** `xen-tools`
+
+|      | full         | minimal        |
+|------| ------------ | ------------ |
+|ipks  | 8.1M (8216K) | **1.3M** (1276K) |
+|image | 26M (25944K) | **4.6M** (4664)K |
+
+## Components of minimal `xen-tools`
+
+| `xen-tools-`        | included | Rationale                                                    | remark  |
+|---------------------| -------- | ------------------------------------------------------------ | ------- |
+| libxencall          | yes      | library to provide hypercall interface                       |         |
+| libxenctrl          | yes      | library to provide interface for the ARINC 653 scheduler     | partially included |
+| libxendevicemodel   | no       | library to support device model. Not needed                  |         |
+| libxenevtchn        | no       | library to support event channel. Not needed with static event channel | |
+| libxenforeignmemory | yes      | library to support  memory management for hypercall buffer                       |         |
+| libxengnttab        | no       | library to support grant table. We are plainning to use static shared memory instaed of grant table to avoid dynamic memory allocation. | |
+| libxenguest         | no       | library to support control and manage the domUs. Not required with dom0less | |
+| libxenhypfs         | no       | library to provide interface for hypervisor fs. We don't access hypervisor fs. | |
+| libxenlight         | no       | library to support `xl`. We don't use `xl` at all            | |
+| libxenstat          | no       | library to monitor statistic data of domUs with `xentop`. We don't use it | |
+| libxenstore         | no       | library to access `XenStore`. We don't use `XenStore`. | |
+| libxenutil          | no       | library to provide common utilities. | |
+| libxenvchan         | no       | library to provide interface for vchan(vitual channel). We don't use vchan | |
+| libxentoolcore      | yes      | managing libraries' handlers                                 |         |
+| libxentoollog       | yes      | library to provide logging interface                         | can be removed |
+| 9pfsd               | no       | network file system protocol.                                | had dependency on `XenStore` |
+| consold             | no       | `ctrl-a` ×3 replaces it                                        |         |
+| dev                 | yes      | header files                                                 |         |
+| flask               | yes      | Xen security policy framework (XSM/FLASK)                    | disabled |
+| flask-tools         | yes      | tools to manage FLASK policy                                 | disabled |
+| fuzz                | no       | FUZZ test tool                                               |         |
+| fsimage             | yes      | file system image generator for domUs; depends on `pygrub`   |         |
+| hvmloader           | no       | legacy BIOS loader for HVM guests                            |         |
+| libacpi             | no       | Advanced Configuration and Power Interface                   | disabled |
+| pygrub              | yes      | bootloader parser for domU kernels                           | enabled |
+| reums               | yes      | tool for failover of domUs via periodic backup; requires `libnl3` | need to check dependency with `libxenlight` (xl) |
+| scripts-block       | yes      | scripts for block device                                     |         |
+| scripts-common      | yes      | scripts for common utilities                                 |         |
+| scripts-network     | yes      | scripts for domU network setup                               |         |
+| shim                | yes      | EFI loader to launch Xen as a bootloader                     | disabled  |
+| xenpaging           | no       | domain paging tools not used                                 |           |
+| xenpmd              | no       | xen power management daemon                                  | had dependency on `XenStore` |
+| xenstored           | no       | Xen Store Daemon providing simple tree-like database         | had dependency on `XenStore`, and event channel |
+| xenwatchdogd        | no       | watchdog daemon. Not needed                                  |           |
+| volatiles           | yes      | runtime files (e.g. sockets, pid) for Xen tools              |           |
+| xencommons          | yes      | startup script for Xen toolstack                             |           |
+| xendomains          | yes      | init scirpt to autostart and shutdown domUs at boot/shutdown |           |
+| xentrace            | no       | trace Xen internal events. kind of debugging and monitoring tool. Not needed |  |
+| xenmon              | no       | live trace monitor                                           | requires `xentrace` |
+
+## How to enable minimal `xen-tools`
+
+- Ensure the following lines are present in `local.conf`:
+
+``` conf
+# Enable minimal-xen-tools mode
+ENABLE_MINIMAL_XEN_TOOLS = "true"
+# Append minimal-xen-tools feature to xen-tools build configuration
+PACKAGECONFIG:append:pn-xen-tools = " minimal-xen-tools"
+```
+
+- `minimal-xen-tools` will be enabled if `ENABLE_MINIMAL_XEN_TOOLS` is set to `true`
+
+## How to include a component which is excluded
+
+### Library
+
+- Modify `xen/tools/libs/Makefile` and `xen/tools/libs/uselibs.mk` as follows to include the library's source code in the build
+
+@xen/tools/libs/Makefile
+
+```makefile
+ifeq ($(CONFIG_MINIMAL_TOOLS),y)
+SUBDIRS-y :=
+SUBDIRS-y += toolcore
+SUBDIRS-y += toollog
+SUBDIRS-y += call
+SUBDIRS-y += foreignmemory
+SUBDIRS-y += ctrl
+SUBDIRS-y += xxx            # include 'xxx' to build 
+endif
+```
+
+@xen/tools/libs/uselibs.mk
+
+```makefile
+ifeq ($(CONFIG_MINIMAL_TOOLS),y)
+    LIBS_LIBS += toolcore
+    USELIBS_toolcore := 
+    LIBS_LIBS += toollog
+    USELIBS_toollog :=
+    LIBS_LIBS += call
+    USELIBS_call := toollog toolcore
+    LIBS_LIBS += foreignmemory
+    USELIBS_foreignmemory := toollog toolcore
+    LIBS_LIBS += ctrl
+    USELIBS_ctrl := toollog call foreignmemory
+    LIBS_LIBS += xxx    # add 'xxx'
+    USELIBS_xxx := toollog toolcore aaa   # dependency of 'xxx'      
+else
+    LIBS_LIBS += toolcore
+
+```
+
+- Modify `xen/tools/libs/ctrl/Makefile.common` if you want to include part of `libxenctrl`
+
+### Tool
+
+- Modify `xen/tools/Makefile` as follows to include the source code in the build
+
+``` makefile
+ifeq ($(CONFIG_MINIMAL_TOOLS),y)
+SUBDIRS-y :=
+SUBDIRS-y += libs
+SUBDIRS-y += flask
+SUBDIRS-y += hotplug
+SUBDIRS-y += xxx          # include 'xxx' to build 
+SUBDIRS-$(CONFIG_X86) += firmware
+SUBDIRS-$(CONFIG_LIBFSIMAGE) += libfsimage
+
+# do not recurse in to a dir we are about to delete
+ifneq "$(MAKECMDGOALS)" "distclean"
+SUBDIRS-$(CONFIG_QEMU_TRAD) += qemu-xen-traditional-dir
+SUBDIRS-$(CONFIG_QEMU_XEN) += qemu-xen-dir
+endif
+#SUBDIRS-y += python
+SUBDIRS-$(CONFIG_PYGRUB) += pygrub
+SUBDIRS-$(OCAML_TOOLS) += ocaml
+endif
+```
+
+- The `xen/tools/configure.ac` file should also be modified appropriately as needed. In this case, you should ensure that updating `configure` file and executing it during the build.
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:23:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:23:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983891.1370061 (Exim 4.92)
	(envelope-from )
	id 1uF6SC-0007Qn-CM; Wed, 14 May 2025 07:23:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983891.1370061; Wed, 14 May 2025 07:23: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 1uF6SC-0007Qg-95; Wed, 14 May 2025 07:23:00 +0000
Received: by outflank-mailman (input) for mailman id 983891;
 Wed, 14 May 2025 07:22:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uF6SB-0007QX-6v
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:22:59 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4106f6e0-3094-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 09:22:55 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-acae7e7587dso1004108066b.2
 for ; Wed, 14 May 2025 00:22: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
 a640c23a62f3a-ad2197be6d7sm885487566b.157.2025.05.14.00.22.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 00:22: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" 
X-Inumbo-ID: 4106f6e0-3094-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747207375; x=1747812175; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to;
        bh=41miFATeZxHupvacOlvavkzA6h39zZkxJdVTAm5UTt0=;
        b=TWetoAFl2Z/53yhuE71U7u7o7jPTXHs564TxB32GUGtj9C4jKrzDc/l7XXIF77BCEt
         +T419JgacXDNu+EG5vyBPQZeL7qCRplwKggP0H3yr4w8UjQQYNN6JB8qsW5/thJO84nF
         YUFqyaKo2O22U+0bg2fhT1k7Bi/qICz5dzo5Sqe+7cInIAadSbclSc39CCcCofCyCE3+
         Dn/nopb1udkk3iX23wyg0RHdCpNeLt/TXdibhdPzwIETKNwLWx6VprvXoAiEYVK/gNWl
         WIayfzvNEtQW8poiVYTdvtygVovee5w2tNHB+oZRVWZTCgcGGR64LX5HXF9zqeG5V2Zd
         dRbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747207375; x=1747812175;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=41miFATeZxHupvacOlvavkzA6h39zZkxJdVTAm5UTt0=;
        b=cPEXmsYJnnV2Cw2wlxNF5sgj4rkDKz4524JTitYkQpZLyuTsQ0etXI8tRk4FHdZzOF
         FWGyy9okYbWqyFpNaVUd439KGpb2FnDqrXvyUNQAUKSwUl7FbiCqs6Nt0G7YOonX1vpS
         ufsxGQotRH1sxvXQpo3mXoEAolD/At0VQn6dNA2/g+wbwqI4NL+FHQrckopBa9yC4Jcy
         lgOG1y3pEWAny6EqYryZwmfQ+2GtR0ZOwfaO5hSRZdSzrRSwnIxiO3OkIeWiZvzZViCG
         +N7gPkJ52zN75Kt1p6XtlSJcP5N2kZHOBWnuuBCT2P/l/mXfDBJpv6Go1UgD7HyUbRE/
         cu8Q==
X-Gm-Message-State: AOJu0YyqEjBfq2ciTZP++Kgbqx1hu6N1GdYfVwctZQBMjYlCxNefkj8T
	eT6wUZ8O2WxKIYmmmqZkC13PXb3YD5a0+SCN/McwG2Nf3wmnp+okzOsTTU5jd7fo+QOzjm5gXIc
	=
X-Gm-Gg: ASbGncuGvfEsfbrTNrFJn/ZdGGCuemKC5xP0FrtGKEiwu5AjCZmk0KMdAz083VFAmVk
	RPfABRovFvC4y/VNn+vfX7Obu9DQ6ua+md2jYIly5/gbIwi7tQ8E/4EiT6Gl0jSZnYFfqJdSYPj
	rEtNqUxeUwj9XfPmeTPFDwcXBcQbj8hYvRaN29fifnckAWWF57pK7tY9cUuQRZ0dtz1tJROUCHx
	GYBaeRRQPsCaBdWh7DQiN7t6k01AS5e2INhOJJudaD3XSWBMkbdoovRuevQwSkGu7NDEEn3fXnn
	53JcgHPoI7yN6/wOXZH9RfRFuu5FgQQlEZVDpnzJIKPLGW7Zz9EB7BKh7Y2XFWKGG1rM42DXawJ
	ynhrvMaX0HLD945mwhKVE/a+sJc3sDQKnkE0s
X-Google-Smtp-Source: AGHT+IHCClQI09DEi9cT6JHCGyFKxMsoBdXLVYdEZYWM4XF2wOvaifvoW4EVNr2LY4DnsQs3mPjGsQ==
X-Received: by 2002:a17:907:7fa5:b0:ad2:1d12:fd68 with SMTP id a640c23a62f3a-ad4f72935d3mr248789166b.48.1747207375178;
        Wed, 14 May 2025 00:22:55 -0700 (PDT)
Message-ID: <9fc0b9d1-15e5-47e9-a532-a25e1ac32ba2@suse.com>
Date: Wed, 14 May 2025 09:22:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Marek Marczykowski 
From: Jan Beulich 
Subject: [PATCH] x86/IRQ: constrain creator-domain-ID assertion
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

If init_one_irq_desc() fails, ->arch.creator_domid won't be set to the
expected value, and hence the assertion may trigger. Limit it to just
the success case of that function call.

Fixes: 92d9101eab ("x86: allow stubdom access to irq created for msi")
Reported-by: Marek Marczykowski-Górecki 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -289,9 +289,9 @@ int create_irq(nodeid_t node, bool grant
                 mask = NULL;
         }
         ret = assign_irq_vector(irq, mask);
-    }
 
-    ASSERT(desc->arch.creator_domid == DOMID_INVALID);
+        ASSERT(desc->arch.creator_domid == DOMID_INVALID);
+    }
 
     if (ret < 0)
     {


From xen-devel-bounces@lists.xenproject.org Wed May 14 07:25:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:25:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983897.1370070 (Exim 4.92)
	(envelope-from )
	id 1uF6UA-0007yp-Md; Wed, 14 May 2025 07:25:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983897.1370070; Wed, 14 May 2025 07:25: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 1uF6UA-0007yi-K2; Wed, 14 May 2025 07:25:02 +0000
Received: by outflank-mailman (input) for mailman id 983897;
 Wed, 14 May 2025 07:25:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uF6U9-0007yb-IK
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:25:01 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8ae9156f-3094-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 09:24:59 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5fc8c68dc9fso5793461a12.1
 for ; Wed, 14 May 2025 00:24: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
 4fb4d7f45d1cf-5fc9d70f51esm8228189a12.79.2025.05.14.00.24.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 00:24: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" 
X-Inumbo-ID: 8ae9156f-3094-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747207499; x=1747812299; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dRLP3HqlbEl3Brvt/dSwvcuwAQHJmAP62JYmPmkodFg=;
        b=H7Gh9fROxXb3vAKEssEhOXYTHkxPsX+/RbLLr17st8UblQyvbU1v6FsRUsoB1IDhhT
         scTxSE0t1m3D7E0u3zoz3f6YFJbaSBThQ2SEj2rt/fYVXpp/haiRK3ICOq2kTp4Cb4Uy
         su3Bepo0sKG2TicPWDpLPqxYjZYR/yYboJAofow8qPXJVb6jj7rcR8+b5Z57FhZynMDq
         9t7qGV08ySUdlhUSYQ5hBlBQkIy+RErV8Phh1Glo0xUvKWbvt5/oBfosIbDnuH3Tj3BF
         7Zctq28iuQWOllTFbG8R/2GOsQ2kBOQZaCccv5dX245L3l3X3tVdfTsyvdlWHMuKQ3px
         iJWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747207499; x=1747812299;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=dRLP3HqlbEl3Brvt/dSwvcuwAQHJmAP62JYmPmkodFg=;
        b=gCfzmhUKuVkgzJ6c6RGQNkG8knd+CXAdJjI11CykEzeJpN2HQQCWrPxtJsG0bXcHcj
         Eg4sreXJWsHADXF3irqGjevh9tRIyDGrhe3ydqjkIs/9dOB7Nzaaezs2w1jegdkylVdz
         rWYfIccoV/jhEyqcLA3o48gwZC5/SvhLlwtb471f9zWnAK5beStApTQkuX0FcQV/gP+m
         lfCYUgWlwrGqk+ETOIRA+Y7zJnk0x7+KeMYbKOhiNken4+/hxH8hs7RsCBRa07zmiLti
         8lvlufwdnjHzAgiiZWUs8cQidr13FVP5s7V9QpVWbw5qYfBSN4C/+ae1INJOxneCgkts
         HulQ==
X-Forwarded-Encrypted: i=1; AJvYcCXBbsuryZNwbErk7rp+VPfCEcgJR8U98yGpnD0DrMlfyQZ8ePqPKvdF+4u90BI1Eo+n6JcpfNR+YYA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxySwfE3ROb2wSIYner+5KJHSZR8om7DEtmaRESTLIbhWPydRVv
	uTblGmJunawRdjJtxyg9HvZRZHYITrkX4MLVKSlWCJ+MPXxAuOTYkExTN1wN9w==
X-Gm-Gg: ASbGnctdxS3XWUwnjwqT4PQC0Go/8h6e42RF7oMQzBtCnFu2oFTQb4RPpC/6AoYIiYw
	T9S2USfJX2dLEgbcWQAk2JGj4CzD1wxamh3xDeUeEUXEGPkdTX/E/ZQZB2F0JlDxcGZhrwCTDwJ
	M09WR/+2lpq1Z+NIZVzxzdy/O7KFL3JwFa0uodThKz/zAbXwU6j/lhKy9+Z82gC6l7qQz4PlP6B
	N7HxFsTX6dvZVROleURJ9hd/J0IEeE6qg/XizWK2/edSx5BmE9kSsBEKx955UinEO0CI3xvMF8L
	bUlpqXlIM87VMkk7xdK57sBGHyn5B6hCobBErZZTVnSmEhyCQzqeRl86XfkUw4kaNbT4DEECgvC
	jaa5nY0HnY09rzUQKjxJ6YUKkVFddvLFkoanA
X-Google-Smtp-Source: AGHT+IEDY7hQGDED6kpRBJkQyn9oqmJM+DVaR/Ps9sGCqAmyEGNgsFKhdoRFB9JLmFT4RB8G6YAhGA==
X-Received: by 2002:a05:6402:50d3:b0:5fd:1696:3c24 with SMTP id 4fb4d7f45d1cf-5ff988d3449mr1800146a12.16.1747207499113;
        Wed, 14 May 2025 00:24:59 -0700 (PDT)
Message-ID: 
Date: Wed, 14 May 2025 09:24:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 0/2] Propose an minimal xen-tools
To: Sookyung Ahn , xen-devel@lists.xenproject.org
Cc: matthew.l.weber3@boeing.com, joshua.c.whitehead@boeing.com,
 Anderson.Choi@boeing.com, brian.j.wood2@boeing.com, haesun.kim@boeing.com
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

On 14.05.2025 09:12, Sookyung Ahn wrote:
> I am writing to propose an enhancement to the `xen-tools` for users who require only a minimal subset of its functionality, particularly in safety-critical domains like aerospace.
> 
> I believe that the addition of a new build-time option, `ENABLE_MINIMAL_XEN_TOOLS`, will significantly benefit users by allowing them to build only the essential components needed for their specific applications. 
> This approach not only streamlines the toolset but also reduces the potential for unnecessary complexity in safety-critical environments.
> This proposal is based on `dom0less` environment.
> 
> The proposed implementation includes:
> - Introducing the `ENABLE_MINIMAL_XEN_TOOLS` configuration flag.
> - Modifying the build process to selectively include only the necessary components based on the configuration.
> 
> This implementation can be effectively applied to the following use cases. 
> - Minimal APIs for `dom0less` operation. This involves taking existing Xen functions and shrinking them to minimal needed parts. For example, we can use static device tree instead of XenStore. 
> - By retaining `libxencall` and minimum part of `libxencrtl`, the Hypercall interface can be utilized, enabling support for the Xen ARINC653 Multiple Module Schedules service. 
> - Addition of ARINC653 Part1&2 APIs and services (hosted on the domain OS.)
> 
> I would appreciate any feedback or suggestions you may have regarding this enhancement. 
> Additionally, I would like to emphasize the importance of community input in refining this proposal to ensure it meets the needs of all users.
> 
> Sookyung Ahn (2):
>   changes for minimal-xen-tools
>   add document minimal_xen_tools.pandoc
> 
>  config/Tools.mk.in                    |   1 +
>  docs/designs/minimal_xen_tools.pandoc | 147 ++++++++++++++++++++++++++

Just one nit here: Like you have it in the subject, please prefer dashes over
underscores in the names of new files.

Jan

>  tools/Makefile                        |  19 ++++
>  tools/Rules.mk                        |   9 +-
>  tools/configure.ac                    |  47 +++-----
>  tools/flask/Makefile                  |   4 +
>  tools/hotplug/Linux/Makefile          |   6 ++
>  tools/hotplug/Linux/systemd/Makefile  |   6 ++
>  tools/libs/Makefile                   |   9 ++
>  tools/libs/ctrl/Makefile.common       |  92 +++++++++-------
>  tools/libs/ctrl/xc_private.c          |   6 ++
>  tools/libs/ctrl/xc_private.h          |   7 +-
>  tools/libs/uselibs.mk                 |  76 +++++++------
>  13 files changed, 325 insertions(+), 104 deletions(-)
>  create mode 100644 docs/designs/minimal_xen_tools.pandoc
> 



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:25:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:25:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983906.1370080 (Exim 4.92)
	(envelope-from )
	id 1uF6V2-0008Um-Uv; Wed, 14 May 2025 07:25:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983906.1370080; Wed, 14 May 2025 07:25: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 1uF6V2-0008Uf-S4; Wed, 14 May 2025 07:25:56 +0000
Received: by outflank-mailman (input) for mailman id 983906;
 Wed, 14 May 2025 07:25:55 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uF6V1-0008UW-Tb
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:25:55 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uF6V1-008GI3-0u;
 Wed, 14 May 2025 07:25:55 +0000
Received: from [2a02:8012:3a1:0:51a6:3d91:4273:769]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uF6V0-00DC2q-1K;
 Wed, 14 May 2025 07:25: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=Wh6cCxySR+znIGOb8CBHhWfKFkfCOTetRj7E2RyU2MI=; b=J8ye3vxXSYOfXfMQnd+pdW7DYr
	PGAtDX6g7wiHjYDWKfO1qjLge3Wv+hF2Z7ghBXZpxlPlBhykurF76n6vQLE9Tv7AM4eQw16yBWnFV
	4DZ9NOBIWgHE1QwHKZNuY6N7KfYAcl729iwhQK26YkXQ4gnscofMvwcpgoU29Qe9kMuk=;
Message-ID: <0acae8dd-d4d6-4d65-909d-637c4a283ea7@xen.org>
Date: Wed, 14 May 2025 08:25:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU
 construction
Content-Language: en-GB
To: Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Oleksii,

On 13/05/2025 15:29, Oleksii Kurochko wrote:
> Refactor construct_domU() to improve architecture separation and reduce
> reliance on ARM-specific logic in common code:
> - Drop set_domain_type() from generic code. This function is specific
>    to ARM and serves no purpose on other architectures like RISC-V,
>    which lack the arch.type field in kernel_info.

So you will only ever boot one type of domain on RISC-V? IOW, no 32-bit
or else?

> - Introduce arch_construct_domU() to encapsulate architecture-specific
>    DomU construction steps.
> - Implement arch_construct_domU() for ARM. This includes:
>    - Setting the domain type for CONFIG_ARM64.
>    - Handling static memory allocation if xen,static-mem is present in
>      the device tree.
>    - Processing static shared memory.
> - Move call of make_resv_memory_node() to Arm's make_arch_nodes() as
>    this call is specific to CONFIG_STATIC_SHM which is ARM specific,
>    at least, now.

This looks shortsighted. If there is a plan to use CONFIG_STATIC_SHM on 
RISC-V (I don't see why not today), then
I think the code should stick in common/ even if it is not fully usable
yet (that's the whole point of have CONFIG_* options).

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:27:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:27:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983919.1370091 (Exim 4.92)
	(envelope-from )
	id 1uF6WT-0000e4-9V; Wed, 14 May 2025 07:27:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983919.1370091; Wed, 14 May 2025 07: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 1uF6WT-0000dt-5C; Wed, 14 May 2025 07:27:25 +0000
Received: by outflank-mailman (input) for mailman id 983919;
 Wed, 14 May 2025 07:27:23 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uF6WR-0000dm-SE
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:27:23 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uF6WR-008GJc-0A;
 Wed, 14 May 2025 07:27:22 +0000
Received: from [2a02:8012:3a1:0:51a6:3d91:4273:769]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uF6WQ-00DHDT-1X;
 Wed, 14 May 2025 07:27: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=FFgHX7Hxlr6R5EInDXp7psHC0AE2IOCWulPq80+3EhI=; b=5k6nhsMi5n3qPOKbqVRwfX8rGe
	p7sQOZfLCungIVSVNzi7Mg63TscrqjADycBbVcYYOWt18gJP7eaQ3kQwevxVhKoWrXGzMVQSJ8YfZ
	vL1ELNTGgRk9I6AEDbVOpPDG2F6KqqKagdpPKiEKj1GrOXpOx1WSPx/M0+ZW4rwzExxE=;
Message-ID: <15bf8cad-2114-48e4-9b10-4b4a725eea33@xen.org>
Date: Wed, 14 May 2025 08:27:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/3] xen/dom0less: move make_chosen_node() to common
 code
Content-Language: en-GB
To: "Orzel, Michal" ,
 Oleksii Kurochko , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: 
 <9c87738225d48bd1ee9bba6e8d4e018dfecabccd.1747145897.git.oleksii.kurochko@gmail.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 13/05/2025 15:45, Orzel, Michal wrote:
> 
> 
> On 13/05/2025 16:29, Oleksii Kurochko wrote:
>> The current implementation of make_chosen_node() does not contain any
>> architecture-specific logic. Therefore, move it from arch-specific
>> files to common code.
>>
>> At this stage, there is no need to introduce an arch_make_chosen_node(),
>> as no architecture-specific customization is required.
>>
>> This change avoids duplication and simplifies future maintenance for
>> architectures like RISC-V and ARM.
>>
>> Signed-off-by: Oleksii Kurochko 
> Reviewed-by: Michal Orzel 
> 
> [snip]
> 
>> +/*
>> + * This function is used as part of the device tree generation for Dom0
>> + * on ACPI systems, and DomUs started directly from Xen based on device
> Might be worth adding (on Arm) after 'ACPI systems'. Could be done on commit.

Please don't. This will become stale otherwise as soon as RISC-V is 
started to use it. Instead, we should say (on platform where CONFIG_ACPI=y).

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:28:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:28:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983928.1370100 (Exim 4.92)
	(envelope-from )
	id 1uF6Xh-0001Az-J7; Wed, 14 May 2025 07:28:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983928.1370100; Wed, 14 May 2025 07: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 1uF6Xh-0001As-Ga; Wed, 14 May 2025 07:28:41 +0000
Received: by outflank-mailman (input) for mailman id 983928;
 Wed, 14 May 2025 07:28:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uF6Xg-00018z-GW
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:28:40 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0e41cb6e-3095-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 09:28:39 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad257009e81so479877766b.2
 for ; Wed, 14 May 2025 00:28: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
 a640c23a62f3a-ad2197be6d7sm886207066b.157.2025.05.14.00.28.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 00:28:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0e41cb6e-3095-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747207719; x=1747812519; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=BLBSZT9jCqo5EgJyDOHLa06HyInJkTH3Ca+Zk5y857Q=;
        b=UkqrtX/En8QfEp6YXqxJQQBzNgJLhrMOkwzNvJksNHYEEdckam3x50Bv95bxkzYFF0
         RCGK8d5wiSr6D5DNyoNe4k4AAdMnp2XPxi5zNDLXlp2Ncu5scoSgnHB4Ax395fakGHc7
         DRTMnurRif7ygY5liJTqztNyMMCG5ge6LLRnRxp13S8wrPKv/YN4bC2ajCvwbTLw8L8U
         rpkNkxcRJs0HxTGkV5sOqu4Pm0s1nkVk3bSEd5zFDg7x9L9D+qLLTRJQicKyrpchVPcw
         w6n81rB5X6V9bQlvuhxKsmkJtXBonq6tUGWrYG3znB3d99na//SHQGjjhfGsFlDpUpqt
         IoMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747207719; x=1747812519;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BLBSZT9jCqo5EgJyDOHLa06HyInJkTH3Ca+Zk5y857Q=;
        b=T58SUpST3sp8v27jPd4ENU2ElHVihdF/whcn1V1u7FA/a7D9+X2d6Y8TBNLPJ+1Yet
         yYthjPLDR3I98luMQWNj6XidP6rNEZxf3Non1YQ+pjkjy/X39VM08igmNnQTWxN25G/o
         IxSvcFiba8ggMMeIhKJw9VBQSAKA/u78d8y+uDfQyB4eQ05cDoMPBJe58ua3Ol62hWit
         a1b1jNj2MxmjuT8pNX0NcIHWXkHpTWhRyr5Wy1FL4cQEzT5G2H11Y8HjiAY89X6V9boq
         NRFmZ5f1DVq9GdH/Sxo7wFVGT0H1mX9OuukAUmYXDbuhBH9DwRBN3p+qbg+uOuBmG7Hg
         sqGw==
X-Forwarded-Encrypted: i=1; AJvYcCXze0vit/ud7zSb8nldzn2RRjQTacUi6MI6CgvNu1lymwrw8+93cdw45pbwExpjfqp+wSDXepSXFm4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyt1jiRsX+EmZiOoSkCED4kUs1/sx2qj/GYtTZDjfBvUJGK0AcP
	oGLEX4INJxL47JvNS5KLHxAbpbxcgo/A6zXC6wWDRN5shwPfcet606pXesppVQ==
X-Gm-Gg: ASbGncsa5zZMnqCLAEqpkdCKvsnBr1XKGeO/7tTpDThfnWIPaXgYliIQeMd1X0IxkIx
	CL6S7dlcPVFAfDjmPNEtEsplcK13MybbboBV5WHaABKnYAwivkOa7WKaYcdaYCvY1ngZhmt3ztb
	lJdfQpOYxTOTPhYw7DfMp7+GDQw+F3tAhRx6J+wszBMP4IuxwXTO6fOAbwfFQhXMcPWmwaVizvP
	syaK46GK2jV/W1BWr14m25lhjKW0hPSq40x4tFqaVNdhNDH0akOBPeYoXHj6zKack8N/s0Dl7Lu
	PpoJbd1rc+GFOOHecqZNZ+unofpeAUW7Dz4nUeNRKMErftU+m0GKDuRZtrp7A5O3Ai8+8JAbvAt
	iOZ7hjhdx9F7JPEuexVbRnLXONafmShryLxGC
X-Google-Smtp-Source: AGHT+IGzmkelpaqvEeUelEP3FN6dSpznyCK03uamJsA9TOJbs4I9e6LKjkdQdqviX3aLC2IOmSq8hA==
X-Received: by 2002:a17:907:940a:b0:ad2:3fa9:751f with SMTP id a640c23a62f3a-ad4f72706efmr206013166b.38.1747207718887;
        Wed, 14 May 2025 00:28:38 -0700 (PDT)
Message-ID: 
Date: Wed, 14 May 2025 09:28:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 2/2] add document minimal_xen_tools.pandoc
To: Sookyung Ahn 
Cc: matthew.l.weber3@boeing.com, joshua.c.whitehead@boeing.com,
 Anderson.Choi@boeing.com, brian.j.wood2@boeing.com, haesun.kim@boeing.com,
 xen-devel@lists.xenproject.org
References: 
 <0267d6a430a11b9387d56514f963b6a5c6033450.1747205627.git.sookyung.ahn@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: <0267d6a430a11b9387d56514f963b6a5c6033450.1747205627.git.sookyung.ahn@boeing.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14.05.2025 09:12, Sookyung Ahn wrote:
> --- /dev/null
> +++ b/docs/designs/minimal_xen_tools.pandoc
> @@ -0,0 +1,147 @@
> +- [Minimal Xen-tools](#minimal-xen-tools)
> +  - [`xen-tools` : full vs minimal](#xen-tools--full-vs-minimal)
> +  - [Components of minimal `xen-tools`](#components-of-minimal-xen-tools)
> +  - [How to enable minimal `xen-tools`](#how-to-enable-minimal-xen-tools)
> +  - [How to include a component which is excluded](#how-to-include-a-component-which-is-excluded)
> +    - [Library](#library)
> +    - [Tool](#tool)
> +
> +# Minimal Xen-tools
> +
> +Purpose : To enhance `xen-tools` for users who require only a minimal subset of its functionality, particularly in safety-critical domains such as aerospace. 
> +
> +## `xen-tools` : full vs minimal
> +
> +- total size of **full** `xen-tools` and **minimal** `xen-tools`
> +
> +|      | full         | minimal        |
> +|------| ------------ | ------------ |
> +|ipks  | 8.1M (8216K) | **1.3M** (1276K) |
> +|image | 26M (25944K) | **4.6M** (4664)K |
> +
> +## Components of minimal `xen-tools`
> +
> +| `xen-tools-`        | included | Rationale                                                    | remark  |
> +|---------------------| -------- | ------------------------------------------------------------ | ------- |
> +| libxencall          | yes      | library to provide hypercall interface                       |         |
> +| libxenctrl          | yes      | library to provide interface for the ARINC 653 scheduler     | partially included |
> +| libxendevicemodel   | no       | library to support device model. Not needed                  |         |
> +| libxenevtchn        | no       | library to support event channel. Not needed with static event channel | |
> +| libxenforeignmemory | yes      | library to support  memory management for hypercall buffer                       |         |
> +| libxengnttab        | no       | library to support grant table. We are plainning to use static shared memory instaed of grant table to avoid dynamic memory allocation. | |
> +| libxenguest         | no       | library to support control and manage the domUs. Not required with dom0less | |
> +| libxenhypfs         | no       | library to provide interface for hypervisor fs. We don't access hypervisor fs. | |
> +| libxenlight         | no       | library to support `xl`. We don't use `xl` at all            | |
> +| libxenstat          | no       | library to monitor statistic data of domUs with `xentop`. We don't use it | |
> +| libxenstore         | no       | library to access `XenStore`. We don't use `XenStore`. | |
> +| libxenutil          | no       | library to provide common utilities. | |
> +| libxenvchan         | no       | library to provide interface for vchan(vitual channel). We don't use vchan | |
> +| libxentoolcore      | yes      | managing libraries' handlers                                 |         |
> +| libxentoollog       | yes      | library to provide logging interface                         | can be removed |
> +| 9pfsd               | no       | network file system protocol.                                | had dependency on `XenStore` |
> +| consold             | no       | `ctrl-a` ×3 replaces it                                        |         |
> +| dev                 | yes      | header files                                                 |         |
> +| flask               | yes      | Xen security policy framework (XSM/FLASK)                    | disabled |
> +| flask-tools         | yes      | tools to manage FLASK policy                                 | disabled |
> +| fuzz                | no       | FUZZ test tool                                               |         |
> +| fsimage             | yes      | file system image generator for domUs; depends on `pygrub`   |         |
> +| hvmloader           | no       | legacy BIOS loader for HVM guests                            |         |
> +| libacpi             | no       | Advanced Configuration and Power Interface                   | disabled |
> +| pygrub              | yes      | bootloader parser for domU kernels                           | enabled |
> +| reums               | yes      | tool for failover of domUs via periodic backup; requires `libnl3` | need to check dependency with `libxenlight` (xl) |
> +| scripts-block       | yes      | scripts for block device                                     |         |
> +| scripts-common      | yes      | scripts for common utilities                                 |         |
> +| scripts-network     | yes      | scripts for domU network setup                               |         |
> +| shim                | yes      | EFI loader to launch Xen as a bootloader                     | disabled  |
> +| xenpaging           | no       | domain paging tools not used                                 |           |
> +| xenpmd              | no       | xen power management daemon                                  | had dependency on `XenStore` |
> +| xenstored           | no       | Xen Store Daemon providing simple tree-like database         | had dependency on `XenStore`, and event channel |
> +| xenwatchdogd        | no       | watchdog daemon. Not needed                                  |           |
> +| volatiles           | yes      | runtime files (e.g. sockets, pid) for Xen tools              |           |
> +| xencommons          | yes      | startup script for Xen toolstack                             |           |
> +| xendomains          | yes      | init scirpt to autostart and shutdown domUs at boot/shutdown |           |
> +| xentrace            | no       | trace Xen internal events. kind of debugging and monitoring tool. Not needed |  |
> +| xenmon              | no       | live trace monitor                                           | requires `xentrace` |

While I trust you that this properly summarizes what patch 1 does, I wonder
whether this simple "full" vs "minimal" can really cover everyone's needs.
Furthermore, is it really a requirement to limit what's being _built_? I.e.
isn't what you care about what ends up on the target system(s)? In e.g. the
RPM world that would be controlled by the .spec file, not by changes to the
build infrastructure.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 07:31:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:31:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983943.1370110 (Exim 4.92)
	(envelope-from )
	id 1uF6aT-00034X-35; Wed, 14 May 2025 07:31:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983943.1370110; Wed, 14 May 2025 07: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 1uF6aT-00034Q-0O; Wed, 14 May 2025 07:31:33 +0000
Received: by outflank-mailman (input) for mailman id 983943;
 Wed, 14 May 2025 07:31:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF6aR-00032z-Kl
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:31:31 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20602.outbound.protection.outlook.com
 [2a01:111:f403:2409::602])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 72b15429-3095-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 09:31:29 +0200 (CEST)
Received: from DM4PR12MB5277.namprd12.prod.outlook.com (2603:10b6:5:390::7) by
 SJ2PR12MB8157.namprd12.prod.outlook.com (2603:10b6:a03:4fa::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.29; Wed, 14 May
 2025 07:31:25 +0000
Received: from DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e]) by DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e%3]) with mapi id 15.20.8722.027; Wed, 14 May 2025
 07:31: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" 
X-Inumbo-ID: 72b15429-3095-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ci9Uc4f8+ABlY6srFOig2CjCsFBAPDw1yA4GFaS4YSYwn4PMagW29QmaWXNXU+RhZYGc5lLHNuDlvddNRnmDrGLtQr108s3rxAVmo6a7zlcCOGkjbAHQWmHRzPBgblA6KoDsaq6tu7aw6l8rldEMTLLc9fh9TwWBCPITtlWOT49GqbxPMu040DDEjQ7ztsupGe21eKr9gCWJs3tRQwRJkNcxi1KqEJiQSiN8XXppHchUq0rwnqInyJ4s+VvnpwJ6cHJWnTleOM7xr2GeCRCUQeVvIfWaUbPv+oKP1lOODIMHE9DaVhcqA31K9G4uycU3ExRBtVkWtrJKOZkl1cQEFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3AqlBrdYVDavF0r1GKooR0hPssOYR3Cbd6f90ss7/3M=;
 b=mTrvR1wUzF1UFkPjsA/cTFPN9WBmQ3Y9iwS3ub7YLDolepCCOAoBZ7aPxCX2tkH9E7TuB9gmdzgdC79pYZ5rz5a92cH3CA9brVw4d7/Bo1wWMzbP11rA0+KbLzOK/ZTrD/4Y1vDqcy8u7VxGfXSmRd/J2ps4K8uaTFumotoY2k+Ek9Xa/52CxVcSZ7enWrWXTQRqnSJJdliXPpakVEX2OwPzYCKxT9mLwWPPCZYMLm5TFz1VqcES83Bky70NqLX68kOXG7g7dl3HOwfsDZ16Rp8QuFwxCCLNjK2V2PvvK2z5MmJ/RMOfIFo/C6c1rNoc63bWogL14U6yyUfr896jgw==
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=3AqlBrdYVDavF0r1GKooR0hPssOYR3Cbd6f90ss7/3M=;
 b=Ha9BI6YvPddyuGBMV+yuQ30qeuBLUzHG+BW/noCJjyTe+ps7La9i5ackVgdRACpfDw8bPA6rg1VutVrHkiXExHvTB/uPHDItarLuDs0ZD6hEOOJLxjUJQKyGOHPPqtozkHlUmQYU5x8Z7kX67qOAZppGSAVJOLGGc6DIluwu1po=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <54c3d341-1d7f-428d-89a7-ce4fcae8a5db@amd.com>
Date: Wed, 14 May 2025 09:31:20 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen/arm: exclude xen,reg from direct-map domU
 extended regions
To: Stewart Hildebrand ,
 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: <20250513195452.699600-1-stewart.hildebrand@amd.com>
 <20250513195452.699600-2-stewart.hildebrand@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250513195452.699600-2-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR0P281CA0133.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:97::11) To DM4PR12MB5277.namprd12.prod.outlook.com
 (2603:10b6:5:390::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR12MB5277:EE_|SJ2PR12MB8157:EE_
X-MS-Office365-Filtering-Correlation-Id: 771f2dff-f455-41c6-6aef-08dd92b9551e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TEpIc3V1YTBvd25tM3FBYWhrMklMOW11eW9EK1NFUkNZUTBHK0taQ0JMNGpI?=
 =?utf-8?B?STI5Qi94VHNyeUE5OHhEWFgwZUhtU0Z6SUJrY0lOQXo1L01nL21yUWRZcGhI?=
 =?utf-8?B?U0o4ZDhmektUUzV4M0Q5S1NWKzFxNlNBRWJ1ZC9Yb1JleTRoaW1jaFhQdG1m?=
 =?utf-8?B?Vk1sRFdpNWoydkxJOGNSdmR5dHVoUGRVTWdlR2lyUXE4ZFFCeHRBZE9xTnVt?=
 =?utf-8?B?b2ZQR1JRU0tqQmppaXArSWZnUVlpZEQxVWN6R2t2WXZ5aUc1aU1GbWVuVkxV?=
 =?utf-8?B?UW9ISE5mRDBURUIvSXJNUUZ1VjVaV1dpazdXYUZFcng0NW94TUc3dWZud2FK?=
 =?utf-8?B?K21JN1M0VWFUSG42TVlicEtWcUdUYXZUKzk1NTg4NWRkOWc5U0ZUOUhHMjYw?=
 =?utf-8?B?YVZ5cnRrSGlTWWE5cC9ldktibEg0bzZkaDZXczFobmlZTm1NMGFmb09QNUVx?=
 =?utf-8?B?SHM0dnhDZDN4eHplL1VhUkJFVnIvNzZuMlAxdE5uekw2cmJhU0lqK1dJNXpO?=
 =?utf-8?B?anljekx5bDRtUG1TZ0RCUHdWMmhxaHBLUURjdWdvcmxaR0svOTc1MnNLTVVo?=
 =?utf-8?B?K3ZoZjFDcVBLSnBjaWJmSFNwM0g1czNaYlBJcWZyaDhFWTNVN3hidWVLRDF5?=
 =?utf-8?B?Wk42cEl4dit3NTlzTW1DYWVSQWU2SUw2cTRlU2N3WGk5ZVgvbVI1bUNhVlQ1?=
 =?utf-8?B?dUtyZTk2WnNCK1M2ZVFnVFFXSkNQV0lRRVp5K3lTWFFNQmhlTUxWZ1NMOHRj?=
 =?utf-8?B?L0dzUXlURVM4QW9qb1hpdmRaWUExU1QzUWpGdENnWFVWYUpvU2JDVlF5WFN3?=
 =?utf-8?B?Yjc3dmJWVnNMS21vZXk1czNiZnp3L0FaSzJrV0NMRXp1VnpkZjBpODJLOG11?=
 =?utf-8?B?RnQxb3YvV1VYMlBiNUJWeU1KM0kwMnNRTzl5OG56NXBVRkVkbU0zdGxLcUJj?=
 =?utf-8?B?eTRLQXdSRnlEZFpaWGVtRk5mQm16OWNvbTNabUFib0RyRE1EMDVnaWFvbHFj?=
 =?utf-8?B?dGhIdElEVEZFdlVuMCtDVUpoak14UjgyQWlyM04xcy8vREE0S1JucnhodW9q?=
 =?utf-8?B?V1VqZnNBOWl1Tkk1SlU5N29tS1lDK1BkcXlnS0luYnUyQ1l4R0F2c0d5YWh1?=
 =?utf-8?B?NEs3R0FVNE1takIweWRYNHpOdFZyNlVwQ0FUajF3c290cDhrdWk4d2N4YVlz?=
 =?utf-8?B?V3lXV3RQQW5YV21Mc0l5OE1OUUNrSkNjYkJqdyt1MUV6SSt3aXdIU3gvRE51?=
 =?utf-8?B?eXdFTnFWd29pS0xVQjFQTHd1RkJzbmtnakEydnIzdk9ZQ2s2bStseTlXb3Nw?=
 =?utf-8?B?UWZnbFVVV0gvWk1jT3RLV25RUzVsdS8wNE8zR1QxYzlLekJDenpGajZubVZ5?=
 =?utf-8?B?QkdzTndTaWlrcWFIdnIyN0F4ZU42NDl5STkxaXV2dXp1c3UvZzJWalE2a1E0?=
 =?utf-8?B?WE01U1FvNVNlRSs5NFVpTTNrUXlOMlFWUm9Xb24wWjNRdCtIVURtOFZjK1FG?=
 =?utf-8?B?d2JWOTROMHo1N0hPQ0FUQU5QWkkxM2hYUklWMnFLYmxkTEtra044SUdpY1lx?=
 =?utf-8?B?aytZRHloUkJWakN0emF3Wm0zREVBRGxBQXpuaDE1MmRBbWJpNDRaUG9kUklD?=
 =?utf-8?B?T082d3kvQWMzVkRjNVY3MlZYbFZyWDNIdWNLcjlHckxvU3pXN1p2TVlPY3dk?=
 =?utf-8?B?RDY3NmdOaWVtY0JrSFU1cG1zeGNFelgyYWJCTjBuNy9McURudXJVY1MrSmJV?=
 =?utf-8?B?ZUZHbW56a0pJSmxQTDZBdml0VG9oUUxGVXViaERFTm12MnVNc2FWSnYvV3dX?=
 =?utf-8?B?MUJxdkpkVE8wM1p2WklkcnN3YTIvU2hZa3JMVXgvWDNCVnVxRnR1ZnlrUXMw?=
 =?utf-8?B?OVo3WE53RTcvVE1BTVBVcENVNUlZdHA1Vmk3S3Z4elpucVlpRDJaSERpNTBU?=
 =?utf-8?Q?+KkDDbeJ63s=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5277.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NHhNenZoZFpNQkk3dDkweEtKcjZFNTd1NWNTRmNQTzh4Rzh0bXhOOVhOYTFM?=
 =?utf-8?B?TTJIbWNqanpDZzlMTlNKNmVvQ21uWGR5dGVQVHF4ZWZYTGpTQisxcmRjRURh?=
 =?utf-8?B?bzc4cEl2V2t3SWRtVkNYMmtPby9ib3kwTG13YjdDUVR3cndKSklxYWJTQW5T?=
 =?utf-8?B?MG1hWm1Lc0hTT25MNndWRm9ndStmSXpSVm1KSWlLODBvQ21Kb0V5S1FmaThX?=
 =?utf-8?B?TDdpYnNJc0RwSDkxbDY2am9SRHQ2UGZxV0MvRk9adTNrTDFndFNwWmVxZ0JY?=
 =?utf-8?B?MDFaSlRaVmJ3SjgyYnFIVmJONTM2N0lNb3NUMWpURFUrVCtSRkZ3L2pCSjM5?=
 =?utf-8?B?am1xVHFGYVY4TE96clFHcUNGVHlQN1JDUW9uWHEyeDRJOTRKM2U3SWpvc0Jp?=
 =?utf-8?B?WE5laHRkM0FCaWxZVm1TZEVzQjFndXB1NVJBd0cxZTdwQjgxNkpqRVVpZUlV?=
 =?utf-8?B?RkZFZStFZ0VmdHhlWVNYNlZ4dDlROG1TSVU3aFQ5WnFtZi84Rit1d05yS0Ey?=
 =?utf-8?B?b05EOW5SRTNsYWVsNGQ4Q2NWdGcyT291dDc2UzVPb3E4RGN1d0lQQlJSaHlu?=
 =?utf-8?B?MzlCMHk0bHBTY2Z6TW01R0o2M3c1N2hCd1ZxcFloT2hwN3NQbFhaalliYTNq?=
 =?utf-8?B?b0lCVmUwV2k5V2lQSWFqam9rNlliMm5xQTZhOGhKWGVoSFdvYnEyL3VNbHpR?=
 =?utf-8?B?ZklKcndXbFNkOW5CSVlUQW9ycmRwbnpSNFBRNCtuQ3dpL1FLSjVmRFkxWko0?=
 =?utf-8?B?bzEwOTA5YVlLQ1UySHJUckdLVC9MdU5keUlMd0F4cTJvZjM2WStoUFQ2MWor?=
 =?utf-8?B?T1grbjRHU1VyMUZ0RExnMEJKRE5aNHZzY3k1YS9OWE0vOFhYU012OWdRNE1D?=
 =?utf-8?B?b3dSRXlOY3dMVmJLR1pYWW1WV0xzUENvN2FqdDJaUFlla2o3OUhqZVdnQzlT?=
 =?utf-8?B?ak1iTDhHNVJpRFlUY05odGlMdXdidVRtKzR0NHQydTZDNHpOeXBwYXhYRkFC?=
 =?utf-8?B?OWJvL2RoNHowNGt5N0FmZHZ0WHZxa0NxOU1ySm80MVhGSkxuVjE3UzN2cWpH?=
 =?utf-8?B?L2htdEtWTTdlRVZXVW9tYVQ1YWgzOTFkdUdXbC9aZ2lxVHZJdThkWjBOY2xO?=
 =?utf-8?B?Q1JTbzRjS28vd2l5TlgybUVWcW5rSWJsdm83NG5XajhDa2NMWGpaRXVObDBs?=
 =?utf-8?B?WFhGUXNZMHJmN2ZMYm9VN2dCSkRULzhoWStaZlRqM1kxakw0K2V0V0dNeEhE?=
 =?utf-8?B?WmNZbys4dmpRdjVTN2c5dWZzSUFjMXMvZ0tzbHVsM3dPR0FRY1FRWGc4NzJ0?=
 =?utf-8?B?NlB0UG4zZGlhVW9iMGhSZGdzVWdxUGk5ZmEveTllb1N2clRFY1J1N2RpYmk5?=
 =?utf-8?B?bHMxZWxyd0cvTlpZaTUvTThmWktoamcxU1lNbVEvSDZCZGxHTGN6YzVFMFR6?=
 =?utf-8?B?ZEVmKzJZV0xFeGZTUXRUTWNKcjdIeU5mTDB0aTZzcExqVHVlWUh4bVM3Q3Zx?=
 =?utf-8?B?RDE4Q0RKNTFwQnJDTFhuRloxaVdjbjNJcnRFZEZPT3U4RUdCWlMyWW5vbGps?=
 =?utf-8?B?NUJoZjl2SzdXZGl3N081U09IRVVvTGhjMDJteXpQUnZLemo3ZlE4N3NBV1hZ?=
 =?utf-8?B?MXkwMDBHK2xnSE9EbUJJS1RHT29leVFJbVEyMm9UK2RCL01KTVRvVDVZMnFE?=
 =?utf-8?B?TmVhOXIrQ3h3U0JkbzhSYWVadGFieEQ0aGprNys0bk1wM29qY0F1Z0xuOG1W?=
 =?utf-8?B?MnduS0tUYUtpdW0rUFBvRUVsUDM4ck9HWVgyTHhRNkZaMFdVRGdHMHI2MHpK?=
 =?utf-8?B?OTRqalhjQmxkQ01Fdi92cGNWVnFJa211SldzY3FBTzhxQ25jT3diaXNNMytF?=
 =?utf-8?B?SWE0b0lVWHhwaS83OFBMVVBPTWJzK0o0enhlblZqcXRqd1ZqcS9GOS9EQnMr?=
 =?utf-8?B?bkRhbENLL2dKQ3oxajVuZ095aDJiazAvby9VWXN0K3h3UXNtakY4N254VlRS?=
 =?utf-8?B?TlZ5NU1rc2VUTEU2VGFBQ0lTOFQ1emlpR21PYkd5bnBnSUlEb09YMVZueGVS?=
 =?utf-8?B?dzFkVGZzbzE0RFZrMUs4Z3ZLT3NidHhtNTJtbzhXNGJ5TjRUb05neFE1eU0z?=
 =?utf-8?Q?c5V6n9XC+U27acjmz8Y+PoFcW?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 771f2dff-f455-41c6-6aef-08dd92b9551e
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5277.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2025 07:31:25.3924
 (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: E7qfP3QFC0dCyCrUAfgSafUgGb7av0v4E9pIbnLDXuaJLlBynOtK9qUNeOD9ztSX
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8157



On 13/05/2025 21:54, Stewart Hildebrand wrote:
> Similarly to fba1b0974dd8, when a device is passed through to a
> direct-map dom0less domU, the xen,reg ranges may overlap with the
> extended regions. Remove xen,reg from direct-map domU extended regions.
> 
> Introduce rangeset_count_ranges().
> 
> Take the opportunity to update the comment ahead of find_memory_holes().
> 
> Signed-off-by: Stewart Hildebrand 
> ---
> v2->v3:
> * new patch
> ---
>  xen/arch/arm/domain_build.c | 57 +++++++++++++++++++++++++++++++++----
>  xen/common/rangeset.c       | 14 +++++++++
>  xen/include/xen/rangeset.h  |  2 ++
>  3 files changed, 68 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index b189a7cfae9f..3cdf5839bc98 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -824,15 +824,17 @@ static int __init handle_pci_range(const struct dt_device_node *dev,
>  }
>  
>  /*
> - * Find the holes in the Host DT which can be exposed to Dom0 as extended
> - * regions for the special memory mappings. In order to calculate regions
> - * we exclude every addressable memory region described by "reg" and "ranges"
> - * properties from the maximum possible addressable physical memory range:
> + * Find the holes in the Host DT which can be exposed to Dom0 or a direct-map
> + * domU as extended regions for the special memory mappings. In order to
> + * calculate regions we exclude every addressable memory region described by
> + * "reg" and "ranges" properties from the maximum possible addressable physical
> + * memory range:
>   * - MMIO
>   * - Host RAM
>   * - PCI aperture
>   * - Static shared memory regions, which are described by special property
>   *   "xen,shared-mem"
> + * - xen,reg mappings
>   */
>  static int __init find_memory_holes(const struct kernel_info *kinfo,
>                                      struct membanks *ext_regions)
> @@ -914,6 +916,13 @@ static int __init find_memory_holes(const struct kernel_info *kinfo,
>          }
>      }
>  
> +    if ( kinfo->xen_reg_assigned )
> +    {
> +        res = rangeset_subtract(mem_holes, kinfo->xen_reg_assigned);
> +        if ( res )
> +            goto out;
> +    }
> +
>      start = 0;
>      end = (1ULL << p2m_ipa_bits) - 1;
>      res = rangeset_report_ranges(mem_holes, PFN_DOWN(start), PFN_DOWN(end),
> @@ -994,11 +1003,30 @@ static int __init find_domU_holes(const struct kernel_info *kinfo,
>      return res;
>  }
>  
> +static int __init rangeset_to_membank(unsigned long s_gfn, unsigned long e_gfn,
> +                                      void *data)
> +{
> +    struct membanks *membank = data;
> +    paddr_t s = pfn_to_paddr(s_gfn);
> +    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;
> +
> +    if ( membank->nr_banks >= membank->max_banks )
> +        return 0;
> +
> +    membank->bank[membank->nr_banks].start = s;
> +    membank->bank[membank->nr_banks].size = e - s + 1;
> +    membank->nr_banks++;
> +
> +    return 0;
> +}
> +
>  static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>                                               struct membanks *ext_regions)
>  {
>      int res;
>      struct membanks *gnttab = membanks_xzalloc(1, MEMORY);
> +    struct membanks *xen_reg = membanks_xzalloc(
> +        max(1, rangeset_count_ranges(kinfo->xen_reg_assigned)), MEMORY);
You allocate at least 1 membank even though xen_reg_assigned may be empty because:
 - this function is called for hwdom - no xen,reg
 - there may be no xen,reg i.e. no passthrough

~Michal



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:36:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:36:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983953.1370120 (Exim 4.92)
	(envelope-from )
	id 1uF6fD-0003w5-LF; Wed, 14 May 2025 07:36:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983953.1370120; Wed, 14 May 2025 07:36:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uF6fD-0003vy-IU; Wed, 14 May 2025 07:36:27 +0000
Received: by outflank-mailman (input) for mailman id 983953;
 Wed, 14 May 2025 07:36:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uF6fC-0003vX-5N
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:36:26 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 22e192db-3096-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 09:36:23 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad1f6aa2f84so135695466b.0
 for ; Wed, 14 May 2025 00:36:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5fe86b239d1sm3897297a12.35.2025.05.14.00.36.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 00:36: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" 
X-Inumbo-ID: 22e192db-3096-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747208183; x=1747812983; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tSZqls8tlSS3jOxVyex5ucGJihf1GprkiyKwcEsHybc=;
        b=Xycvq+RN93ltwZmpcbqfOZEAxdb5IBRpwgD99wd1iwxy7czLTyEHSK6zvKa8B5E/Da
         3XMOlqBkybL+FFEJiyYcIezCDNkCEktjjxcZE/Pk74I0AUDHRzsZfq39Evzxr8Z7BKty
         MfwdgEHjNMsHfkhyFUv/gKeORsKe4WUiy1duWs4l3U1bBV9PgUxt6ycWWYxbYf9NafJN
         EnUU+gKfyO+ra2gcSjdAVSnZU9XQVb+1yAxZEfWMTGorYSWzh0E/9yReyGSBCelwPhh4
         8P+CEHr2u91AouA1e5Pd8qrOwa4B7/TyrK7C5WYpc573cLemq4BZXy3EoFIw8l4AAKjx
         hzXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747208183; x=1747812983;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tSZqls8tlSS3jOxVyex5ucGJihf1GprkiyKwcEsHybc=;
        b=M8z4ptASqayWQxydauiGDvypEFEtJu0jdHlAqFAIALVd9F2KjbLAvpsHhRBcApQ2A1
         91XnElwZUwabv+fSkTbJme8eOBUQKzrciKd1+HeXwSrKMhCw7flhN0+YYolzYr8nsqEc
         5anwUMd2qBmcIQUrqQ8u3lg4/nhs4uUHaH8ZEVx0puiAKhH3RD9tfAhEvmle23M1eG8Y
         bGUVGx5Ey/Nn0dbI5PYsgY59sFfOm2RN7XyYYpZsN4vpR/0la8I6CHXTm9d3Rj/pUu1D
         hU+vq6th/8zk7mOYvN2MMHZc1PABojwY9aO9U/si3UD/C7OFR9huJTJTzIKZbMTkxmHg
         v+5w==
X-Gm-Message-State: AOJu0YwjkeELi5PFTGcVrKpF7fdgbFFzVh4RcNQmeRZtwXlE2M8UrTmC
	KHQJGNzZ8Rvky5dc+ZupKVnb8kPIpgQKQ6VBcRY5o+S5vOq3BXQTMHZaLD+2DDFxIj5QV/qX2Uc
	=
X-Gm-Gg: ASbGncsc+4asDlsqKZkdS4B0RyDRdUaVTFhScwZQGXirNVpGKGxpHINuy9dy2tH6rRE
	KW+/AVRQZEZdhRtWpa0ZDxtZjrgw1Er2fra0TI9UF3pJNbfzGhZDcD6ptlj90Q9nMy/raufclPR
	cg+dhmSJvtXk0247KPGn/bc1lVa0xGibRY6Qa5W3pt8PXTtAnSlZUNJknh9RIeVKMblO2kaCVT5
	f6JQhUPHno4O0wLJMEV0f7qqnrfFaXHOxYfzIxDUOTZMzpnP6x+sdJY9wDpBLEeOfjki9uWyGFD
	0s+0ReTYsu0XC2HX1uNz89pojKjdRA9hZL7SvSHZS56zSIGeSiZGsHuJ+nm+bi5iPyFbJvOlgPN
	sTZhzjTR/WL8KLqX6d2EiDTyBsJpCooGVvKOX
X-Google-Smtp-Source: AGHT+IGcXPgePM/t+9C/r1iw+pKfOEY5fUWr29to6rxJEDgbzRM8vQZ53DrpNT8iIYDIRoxRx5ttCw==
X-Received: by 2002:a17:906:6a19:b0:ad2:27e6:7e62 with SMTP id a640c23a62f3a-ad4d52bf2b4mr562013366b.27.1747208183572;
        Wed, 14 May 2025 00:36:23 -0700 (PDT)
Message-ID: <080883ed-a1eb-43fd-80e1-1653859b2eba@suse.com>
Date: Wed, 14 May 2025 09:36:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation __init
To: "Orzel, Michal" 
Cc: xen-devel@lists.xenproject.org, Julien Grall ,
 Bertrand Marquis ,
 Stefano Stabellini ,
 Stewart Hildebrand 
References: <20250513171810.668370-1-stewart.hildebrand@amd.com>
 
 
 <4e684e38-ed64-4731-8f00-afba938a28a0@suse.com>
 <369ccaf5-5c17-4601-88b0-eb32af8608d6@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: <369ccaf5-5c17-4601-88b0-eb32af8608d6@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14.05.2025 09:04, Orzel, Michal wrote:
> On 14/05/2025 08:56, Jan Beulich wrote:
>> On 14.05.2025 08:31, Orzel, Michal wrote:
>>> On 14/05/2025 02:07, Stefano Stabellini wrote:
>>>> On Tue, 13 May 2025, Stewart Hildebrand wrote:
>>>>> All functions in dom0less-build.c should be __init.
>>> Why? This patch is first in your series and by that time there is no build time
>>> enforcement. Together with the Fixes tag it implies that this is somehow an
>>> issue (i.e. build/runtime issue) other than inconsistency for which we surely
>>> don't need Fixes tag.
>>
>> I disagree: Code not called post-init should be in .init.*. While not formally
>> a Misra violation (and wrongly so, I think), it imo effectively is: Such code
>> is otherwise unreachable post-init.
> You have a point here, I agree. Although I don't think MISRA differentiates
> between unreachable in general vs pre or post init. It defines it as code that
> cannot be executed. It does not go into stages of runtime execution.

Right, hence how I wrote my earlier reply. Elsewhere, however, Misra (or at
least our interpretation of it) does appear to care about init vs runtime,
in e.g. desiring no runtime allocations.

> I'm thinking how this is different from a function that is called e.g. only once
> at specific point at runtime execution for which we did not come up with a
> separate section?

With enough effort such could also be covered, I expect, yet at the same time the
ultimate result may be coming close to getting out of control. Whereas for init
vs post-init we already have a pretty clear boundary, with memory used merely for
init actually properly reclaimed.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 07:37:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:37:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983960.1370130 (Exim 4.92)
	(envelope-from )
	id 1uF6g2-0004RR-TN; Wed, 14 May 2025 07:37:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983960.1370130; Wed, 14 May 2025 07:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uF6g2-0004RK-Qm; Wed, 14 May 2025 07:37:18 +0000
Received: by outflank-mailman (input) for mailman id 983960;
 Wed, 14 May 2025 07:37:17 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uF6g1-0004R3-Bn
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:37:17 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uF6g1-008GVW-05;
 Wed, 14 May 2025 07:37:16 +0000
Received: from [2a02:8012:3a1:0:51a6:3d91:4273:769]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uF6g0-00Dnw7-14;
 Wed, 14 May 2025 07:37: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=R7EPf/0icVS5SlThLUzul6WFjSikm8pGFtrDo+OCv70=; b=fMVboIvjaBsp/5CTV0gly0vH9l
	+d+aKGPiNY4bCDciDhJDHjDCUUtuDo+KWYlCwuQ2RnaCEXIP1Z4Oi8yMPB59Y8jHmD3UHCh4MAraw
	KQzedvXapuUWcKUJN8ImAe+jJ3fw4WbC4EsI0HugcjdqJk6HstniJUTwxYfVdXt3ohas=;
Message-ID: 
Date: Wed, 14 May 2025 08:37:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation __init
Content-Language: en-GB
To: "Orzel, Michal" , Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
 Bertrand Marquis ,
 Stefano Stabellini ,
 Stewart Hildebrand 
References: <20250513171810.668370-1-stewart.hildebrand@amd.com>
 
 
 <4e684e38-ed64-4731-8f00-afba938a28a0@suse.com>
 <369ccaf5-5c17-4601-88b0-eb32af8608d6@amd.com>
From: Julien Grall 
In-Reply-To: <369ccaf5-5c17-4601-88b0-eb32af8608d6@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 14/05/2025 08:04, Orzel, Michal wrote:
> 
> 
> On 14/05/2025 08:56, Jan Beulich wrote:
>> On 14.05.2025 08:31, Orzel, Michal wrote:
>>> On 14/05/2025 02:07, Stefano Stabellini wrote:
>>>> On Tue, 13 May 2025, Stewart Hildebrand wrote:
>>>>> All functions in dom0less-build.c should be __init.
>>> Why? This patch is first in your series and by that time there is no build time
>>> enforcement. Together with the Fixes tag it implies that this is somehow an
>>> issue (i.e. build/runtime issue) other than inconsistency for which we surely
>>> don't need Fixes tag.
>>
>> I disagree: Code not called post-init should be in .init.*. While not formally
>> a Misra violation (and wrongly so, I think), it imo effectively is: Such code
>> is otherwise unreachable post-init.
> You have a point here, I agree. Although I don't think MISRA differentiates
> between unreachable in general vs pre or post init. It defines it as code that
> cannot be executed. It does not go into stages of runtime execution.
> 
> I'm thinking how this is different from a function that is called e.g. only once
> at specific point at runtime execution for which we did not come up with a
> separate section?

Along with what Jan said, in general there is some relaxation for the 
boot code. For instance, we could accept if it panic.

There is at least one of the place in domain_build.c which panic() and 
the parsing is not meant to be fully robust. So this code either need to 
be __init (as this was the intention from when the feature was created) 
or you need to fully harden the code.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:47:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:47:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983971.1370141 (Exim 4.92)
	(envelope-from )
	id 1uF6pf-0006ic-Oh; Wed, 14 May 2025 07:47:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983971.1370141; Wed, 14 May 2025 07: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 1uF6pf-0006iV-M8; Wed, 14 May 2025 07:47:15 +0000
Received: by outflank-mailman (input) for mailman id 983971;
 Wed, 14 May 2025 07:47:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uF6pe-0006iM-2I
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:47:14 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uF6pd-008Gh4-2a;
 Wed, 14 May 2025 07:47:13 +0000
Received: from [2a02:8012:3a1:0:51a6:3d91:4273:769]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uF6pd-00EMS5-0Q;
 Wed, 14 May 2025 07:47:13 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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=/078umx2RcIJo6GXPagYmwwWL++os7oP3MDUW2NSR5o=; b=Pu76PZ+2W7k8ZCzOqUBtC/5dCu
	zdwe9P4eGZdN6tYUCMXmGbVgValHXg3MSxglzaF74YYYxOKNMDp4xpQ/dpgakdSzHcRVqHHJT9B7C
	DbfFLCctr3GCMiJnt51QN2ITExNEHtAHGemWhjrhdo7LL22PdtWqmBVMNN+j1pLXAOXs=;
Message-ID: <73d064d2-1358-4e5d-9d7d-740a22a711ba@xen.org>
Date: Wed, 14 May 2025 08:47:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/6] xen/arm: fix math in add_ext_regions
Content-Language: en-GB
To: Stewart Hildebrand ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Ayan Kumar Halder 
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
 <20250508132040.532898-2-stewart.hildebrand@amd.com>
From: Julien Grall 
In-Reply-To: <20250508132040.532898-2-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Stewart,

On 08/05/2025 14:20, Stewart Hildebrand wrote:
> In commit f37a59813979, the arguments to add_ext_regions() were switched
> from addresses to frame numbers. add_ext_regions() converts the frame
> numbers back to addresses, but the end address (e) is rounded down to
> page size alignment. The logic to calculate the size assumes e points to
> the last address, not page, effectively leading to the region size being
> erroneously calculated to be 2M smaller than the actual size of the
> region.
> 
> Fix by adding 1 to the frame number before converting back to address.
> 
> Fixes: f37a59813979 ("xen/arm: domain_build: Track unallocated pages using the frame number")
> Signed-off-by: Stewart Hildebrand 
> Acked-by: Michal Orzel 
> ---
> v1->v2:
> * add Michal's A-b
> ---
>   xen/arch/arm/domain_build.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index df29619c4007..2f2b021dec3e 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -761,7 +761,7 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
>       struct membanks *ext_regions = data;
>       paddr_t start, size;
>       paddr_t s = pfn_to_paddr(s_gfn);
> -    paddr_t e = pfn_to_paddr(e_gfn);
> +    paddr_t e = pfn_to_paddr(e_gfn + 1) - 1;

I noticed this patch. While reading the function, I noticed this would 
result to some confusing code:


     if ( start > e )
         return 0;

     [...]

     /*
      * e is actually "end-1" because it is called by rangeset functions
      * which are inclusive of the last address.
      */
     e += 1;
     size = (e - start) & ~(SZ_2M - 1);

So substract 1, but then re-add after. Is there any reason we didn't 
adjust the rest of the code?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:52:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:52:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983983.1370150 (Exim 4.92)
	(envelope-from )
	id 1uF6uV-0008Sw-D2; Wed, 14 May 2025 07:52:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983983.1370150; Wed, 14 May 2025 07: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 1uF6uV-0008Sp-AO; Wed, 14 May 2025 07:52:15 +0000
Received: by outflank-mailman (input) for mailman id 983983;
 Wed, 14 May 2025 07:52:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uF6uU-0008Sj-O7
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:52:14 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uF6uU-008Gmn-1r;
 Wed, 14 May 2025 07:52:14 +0000
Received: from [2a02:8012:3a1:0:51a6:3d91:4273:769]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uF6uT-00Ee5q-2i;
 Wed, 14 May 2025 07:52: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=Sductja8UUY6rnUsKg/TzWmvUR/B80JRIQkzTurD8Vg=; b=uK78uNoHtr+4Hg7oNWo6mXxCld
	CEfzDzo6L2hnLRUMyxPZ3Aravw8eHnTrCM055r++MN0mKSMZT1F8N6bJi/SdoiUCq3pVVnLGlXmkq
	yM8831dmJVkTqeIzr5BMuRbXZsU9rVCEsdNBz32clMxYZpsIaPhZOFw16ovUHxcyA7OI=;
Message-ID: <8d603bce-09c3-4c9f-a31a-0cf3bdc20b39@xen.org>
Date: Wed, 14 May 2025 08:52:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/6] docs/arm: Document Xen booting protocol on Armv8-R
Content-Language: en-GB
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Ayan Kumar Halder 
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-2-luca.fancellu@arm.com>
From: Julien Grall 
In-Reply-To: <20250513084532.4059388-2-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Luca,

On 13/05/2025 09:45, Luca Fancellu wrote:
> Document the requirement needed to boot Xen on Armv8-R platforms.
> 
> Signed-off-by: Luca Fancellu 
> Reviewed-by: Ayan Kumar Halder 
> Reviewed-by: Michal Orzel 
 > ---> v5 changes:
>   - restructured and removed some EL3 reference that might not
>     be there on Armv8-R aarch64
>   - add R-by Ayan and Michal
> v4 changes:
>   - New patch
> ---
>   docs/misc/arm/booting.txt | 11 ++++++++---
>   1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
> index 21ae74837dcc..ca05274392be 100644
> --- a/docs/misc/arm/booting.txt
> +++ b/docs/misc/arm/booting.txt
> @@ -56,12 +56,17 @@ image header to determine the load address, entry point, etc.
>   Firmware/bootloader requirements
>   --------------------------------
>   
> -Xen relies on some settings the firmware has to configure in EL3 before starting Xen.
> +Xen relies on some settings the firmware has to configure before starting Xen.
>   
> -* Xen must be entered in NS EL2 mode
> +* Xen must be entered in:
> +  * Non-Secure EL2 mode for Armv8-A Arm64 and Arm32, Armv8-R Arm32.
> +  * Secure EL2 mode for Armv8-R Arm64.
>   
> -* The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1.
> +* When EL3 is supported, the bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must
> +  be set to 1.
>   
> +* Xen must be entered with MMU/MPU off and data cache disabled (SCTLR_EL2.M bit
> +  and SCTLR_EL2.C set to 0).

The document read much better. Thanks for the update:

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:52:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:52:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.983987.1370161 (Exim 4.92)
	(envelope-from )
	id 1uF6uy-0000ih-LV; Wed, 14 May 2025 07:52:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 983987.1370161; Wed, 14 May 2025 07: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 1uF6uy-0000iY-HV; Wed, 14 May 2025 07:52:44 +0000
Received: by outflank-mailman (input) for mailman id 983987;
 Wed, 14 May 2025 07:52:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF6ux-0000N9-6U
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:52:43 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20614.outbound.protection.outlook.com
 [2a01:111:f403:2418::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 67afc43c-3098-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 09:52:38 +0200 (CEST)
Received: from DM4PR12MB5277.namprd12.prod.outlook.com (2603:10b6:5:390::7) by
 SN7PR12MB8145.namprd12.prod.outlook.com (2603:10b6:806:350::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.29; Wed, 14 May
 2025 07:52:34 +0000
Received: from DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e]) by DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e%3]) with mapi id 15.20.8722.027; Wed, 14 May 2025
 07:52: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" 
X-Inumbo-ID: 67afc43c-3098-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WYtQ30D6Otf0yL9iMv+AaJkJNDWZBZ4w0JGnJQBfX679o4mHf4XNcfCjSAsPGoil0jV19X1g7Fg2S39+wb+Razl/IjPmWyALThjF8ohHf2rFo/Pi/KRb3cBIp9wi6/Q2GZOoIOEhkKLw3OuGxPjssCexZBuYi5t9aOOYTLiVNaoMht63oDT0LRopMgDATIjjTbSVMZHsf31bGf+aZrFJKJwrYOKEpSJd7O2BG8vqNn1Oa2UPVm09ucfcdt0LLsZFjFtfLXRNy027J0kg+yMp0y9+e+Ec6Wb6lro+6SilkBv31oDHucVklt++f8imJ8M/bojrzdVASUv/pBYkvCePEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xskFxAND+mKE9jnX/6RFcSqSC/GCZJP9IjwpEoUVXc0=;
 b=vwi+QO4j+bGWKyOq//E4ZYApxQffUsmPj7GQNMZyTeMKH2VsZvaZ077/JcqF8r4LU9UwMBDv7vbmBTraZPa8V9v0KH0A1/pQrgS9yfspanN7Y9o5kW1YzJWKGfaoh+fVvy1tlacgNQWPatVqwcpo+m1fJwUbLI73xZ2su3ZOOYcdPOmufUj2DNQuNp3CuSeKQM+bIR6nXXPUKGvUaL+Kv/DaEqy0hZmXJ9YcorB/0+817YFxIivkNCN4z/cwuIywWBKOsIFVdBgtxDydoZSRhp/j3It22is2mbfblPK/fJDp/z19tUpcKUrLRApUXuR9ChTbJXKGhW5RpYqp9Orldw==
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=xskFxAND+mKE9jnX/6RFcSqSC/GCZJP9IjwpEoUVXc0=;
 b=Y6oMEivOtU/Vowx1J5MAOvQPSvQ3/3dt9lQAcIfKgbmTarsE3lm9e4GykiDJstyJSmlOL/6m1U0+bVDA0f92YjoctR+fZhufMY+I/CbDz3nkJlN4C3TQAIWhlIekhL6ZwPgXR5SVV8PWxCFdOCWTz0Nm8JDKVVVJ2/R7fWp4/Zo=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Wed, 14 May 2025 09:52:30 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation __init
To: Julien Grall , Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
 Bertrand Marquis ,
 Stefano Stabellini ,
 Stewart Hildebrand 
References: <20250513171810.668370-1-stewart.hildebrand@amd.com>
 
 
 <4e684e38-ed64-4731-8f00-afba938a28a0@suse.com>
 <369ccaf5-5c17-4601-88b0-eb32af8608d6@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0014.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:c8::12) To DM4PR12MB5277.namprd12.prod.outlook.com
 (2603:10b6:5:390::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR12MB5277:EE_|SN7PR12MB8145:EE_
X-MS-Office365-Filtering-Correlation-Id: 467e4bcd-3ebe-4369-a19d-08dd92bc49ca
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VFV1d2FTaFVJNHRNTDRyczVmUEVQTllnazl1SWsxQkZBVnh2MzlkakhuMjg4?=
 =?utf-8?B?UVlMUjNFdWFoUUNLcGZHbHVwNzdwNFhHU1MrMGR0RHhoRGw3NkZXeWJNMTFm?=
 =?utf-8?B?WGJXMkl3d2hTRnFBdEthZFpkbXoyM0RQajhIZzJCNlo1NnM0VjhTUXdVSUNQ?=
 =?utf-8?B?M3BiR2VoQWU2Tmc3bW04ejZvaEo4bEVYUkVmVWxJNUhIdFJEUktDZnNsTUcx?=
 =?utf-8?B?QS9vSWFWOGI5RVJYZ2RLTGZUMFdoNXp3QWx6VDZmeWJmdW9valBpUDI5d1Z1?=
 =?utf-8?B?TmRqMzd1OGh1TXg1WHZ3U0NORy9wakpiZlJTLy8yb21XdkZ5QzhoL3dXN2lu?=
 =?utf-8?B?dHhTSzhKVW9UNDJmWTI0M2VYTllOU29lUlkya0JSang1eDNidUFvUDhGMTVo?=
 =?utf-8?B?VWR5VEEyb01JZmFXRHd1aXpIc2xxVWlhSE0rbFNCZVpyMGVDc2VSaTJkOVpB?=
 =?utf-8?B?bURpWHJMY2piV3BUVC9veVVPOVlYNCt6VUh2NzkxMk9LQktwdW1VQUVyK01Q?=
 =?utf-8?B?eUJiYWdZc2ZNaFJ6Qk9WNm9sbGt1ZGVQdE1ZZXdyd0tYM0N3bXBtMUh4RExw?=
 =?utf-8?B?eURpc1FWZk9xR0ZpVHlzMk1JTWQ0ODdqVElLMnc5cUNEUDRGNmhrcWVwQzhK?=
 =?utf-8?B?U004Yit5MmxGUTNYeHdxWXlnOVRlcHNzZVREQ3dIMGo4QkIrQmNuMENCL2ZL?=
 =?utf-8?B?TEc2RXpaOFloUmpuZURUTGhZcW9GUTh5MDRjdjc2WllJTktWelFRNzFRMTln?=
 =?utf-8?B?SG5kajQvak04K2dHb1puSmdLVWRkVEdlUzRUZmhLMGVGRE5XcjBKQ2NWaU5m?=
 =?utf-8?B?bmkrNXg4TGhQVWRPRlM1WE44Wm56aCtWMGNvZ1dOTzBEMEozWVRCWTlXaFBr?=
 =?utf-8?B?KyswdkVwT3RkU1F1QWw1eStESCtMRWlzOTlmS3FCZFVUbjgxaFZpUWV3WEM1?=
 =?utf-8?B?REliNVVkRmJTZ0YzaUpKV0FmemJXOFViTlIyRHpleC8xYU82R2t6aFpiRlJu?=
 =?utf-8?B?M3E3TERkYjNCSVlod01HdTJkM3pNbmhqc2RmODQyRGJRVGNUS0hLL1JITm9P?=
 =?utf-8?B?ODIxSWw4U2UyYnErc3F0eWY3bDZybFdxMUU4ejBQNzB5d2lxOEw3ZWxGYkcw?=
 =?utf-8?B?UjNXeEdjenB6Z2xabkVnSW51clpwNmpDSzVkazNSNVN3UW0xR0RQVUI1VkhB?=
 =?utf-8?B?V1FzQ1FZc1FYUG4yMFRJRDlQWENDdFJQUHE5Tlh0STNxSWNnVm8xTXcrUURD?=
 =?utf-8?B?ZTIvZFlaTkIwdGJkbFloYVBpbFFWL1ZEcS9DVk9lLzVzYzJZRngyRThqTGR4?=
 =?utf-8?B?QlVlVkNzcTR1OVplbjB1VDNGUXFCWWpPVVUyMmZNM0hkdDhsNzlhb05YQ3pa?=
 =?utf-8?B?Z2lMTEc4ajZlOG84M0NOMjBUeWt0ZWgvN01OR1hXbWliOXp4ZjA5UGtucUJ6?=
 =?utf-8?B?N0gwM3RSb2x3Y2N3SjFnQm5kd2NSVWcwTWhEckQ4K1h4SS9GOCtCNkpIdjZt?=
 =?utf-8?B?by9rN3hlWGY0OElFT2Z4REVlNndnUEZHb2dXT01TWkNDc3h4KzBKWGc1dzBV?=
 =?utf-8?B?SmlnN1NwdHRobzhRemtJL3dLczBDN3lXN2cvaEdYVzQzTXhDRC80NW0wTEw2?=
 =?utf-8?B?UkxiWmpqMk92VHJxM2VUc0lxd0tyc3E3KzVrTGdFWm1hUWEvQjVRV0ZrQjRW?=
 =?utf-8?B?dEhlc0dnbmxncmtyTko2LzduM2VzRTl3VWdzcVFnZ2tOUG45d2dobmhnVVkx?=
 =?utf-8?B?b2RkYVcrNzR3ZFk0UkFKVlUwQnJhUHdTRHpLV3pUc042ZFNoOE1DUXk5YmEx?=
 =?utf-8?B?TGlDWVAzNkw5cGNoeWhtRGl0Y0J6N21rN2svSmY2Rjh5U2pQRmJXNWFvTGg5?=
 =?utf-8?B?Y213MWZmUEdZaG5LSEt2OVhXb1pNOUVwVytDRVFTOVpYNWpEZERvbjl3WVhh?=
 =?utf-8?Q?c78rQzuNRH4=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5277.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QUVuMnBGeXVXZVBvWlFsaHdPS3JteXdEb1hteHFhM2ZDNTRBM3ZMMmZFZFBs?=
 =?utf-8?B?UU96OG51ajZzbFpJZlhOYktIYkFLMFZyQ251eWRvQXRVN1YrcnZqbFZsNHZa?=
 =?utf-8?B?SVB2K2ZONW9sazFqZ1hrWFZrT0xFY3NyOStpZ1hsT3MvRnFXYXFDdnd5VEVC?=
 =?utf-8?B?aXlxZnZMNmZQNjNQZDkxTkIvRE1xdlBJZUJIdWJXQUhKWXU3QXNwWG9sRStO?=
 =?utf-8?B?Q3JUUHJkQVlpTTU3MFZZb1YvdGtHL0NrcjRZVTE2d3dSbVVJMHhpUHNKNnFZ?=
 =?utf-8?B?Sk5mMVQ3SUEzRENPSmw2Ry9FNHBqSmYrendrb1JhNDduRmNMZVY1NFRQYkoz?=
 =?utf-8?B?VUw4ZjA0UWgrdjVUdDg1djRNcFJlTmFkWXhFeStvekpGWnVJRVpqNlg4M0hs?=
 =?utf-8?B?VzB1b0FRUlJieGNsK2VOUnJvZ2tUT255WWozZVRnOXZrNy9hTVJTUnYvZC9F?=
 =?utf-8?B?RERtTFByZVJuM2J3Y0F4bHFaY0xjVkorZ3FrN1BqWFBRbkliSFc5bDY1WnhF?=
 =?utf-8?B?blVsMk5Qa091MUp6WDg5dk9RemZjN09KN1JxODVtMjVPeWhrV0tkUGR6clFk?=
 =?utf-8?B?c0I3UjczOW5PcTJxY2lqT05UanhSQk9hcmlaQzgyN1RTMDQzVFRybi9jdVk3?=
 =?utf-8?B?czdGV2dtNVNiMjZlMjlyT1FUeEFrdHpVZlBtc0tCVGFCMmJDTUlTTTRwNWRC?=
 =?utf-8?B?bnVidnFzL0owRHFRMzBJdUswTnhTczFqT2JhalRGTWdndGRhZXgrc3hFRGFL?=
 =?utf-8?B?ZXRpY3dMVUtBbTRpVkVLeTBtRExyeUVSblZUL3BHUldWS05hVzN3WHVsZk9H?=
 =?utf-8?B?VDJGc204YVlWc0lWTGZPbEx3ZjZkRnhSZUs3M1NiK01OYW9HSjQ1c2VENS9D?=
 =?utf-8?B?RjQyUGxDL09XSnJKZ1NlMHZrWjFQZUNNS2lrblN1MmhTRVRmUXF1WGNNcjNN?=
 =?utf-8?B?SElhQWl5bEdSVkJ3eis4clY3V2tIOUFzZWE4WkNEL1IyUlhCQnFkbGpSQVdN?=
 =?utf-8?B?cWE1N1dja3lxbS9Hb0sxR01iSlBWTVgzYk1JZ1J1eWlPYityQmU1NFJ3dG9l?=
 =?utf-8?B?WGMwWjJZUkZMU21KMnE1MU1PMkdyRmMzNFNoSmhrRFhLeXBpYmw1WW5iUVI3?=
 =?utf-8?B?Z0lLNlhCTldJL1Vaa2tBdjc3MjlqMHc0RTgzU2JXWXVyT1B4R2FBRW5PVXFr?=
 =?utf-8?B?bjZKdjYxb1VJemlFS0JTMnVzVklmWGEzOVFTRDluL0lQcmEvNnZXQzFtOXor?=
 =?utf-8?B?bks3NkN3bnhaalpTaGdldWFSckdyTFJRa1pxamlSWTF5bk5GbVZmQnpmaS9o?=
 =?utf-8?B?Z1BRcU15TzV4YkRZb1NWVFVhTTY1VUkyWFNkNFhOYVhtc1FoMEMyU0JZYllm?=
 =?utf-8?B?eGtQRGRMYkNUL3d5NTZRRWQ0R0lXNG5sdnN4bXZiaVdrVmtGZGFCZldnc0tJ?=
 =?utf-8?B?ZXkrajAzY1RUTFAyTEYza0Fsd25KYXNtb1h2TjR3Q3prY1FJZnlqam1OSUFz?=
 =?utf-8?B?RXBNN0srSmxHUXhoN2NoRnlBbHpKL0JRaEJhRWl2UC91c1plMWpTd04zSGhQ?=
 =?utf-8?B?aDVLQTYwN29YMzBrUXN3YnFpTnJteW9WZy8rb1RnSlQwczNvVnBrVy9JenpS?=
 =?utf-8?B?cVpndStVVGcwdnY4K2dSUXZ1S0ZEaDBnQ2dkK28yMEZhZEVscHgrbEU3MzdW?=
 =?utf-8?B?ODBVMnlFWkJLOWYySk01WXpzOXdTNlI2elpjOUFIQlFZR2J6S3hSZGY4Tnda?=
 =?utf-8?B?ZzR6b3dvRk1nTFQyeVo4RlB4djNVaWxoTXZxdHpJTTlVaTZPayttdlo2ZDIy?=
 =?utf-8?B?M1Vwc3Y2azdNY3JHbnJDbm5yZ0dsMnpqdHJpTTdhLzRkUEJXcEZJb2tEOXhK?=
 =?utf-8?B?cnJ1Ujl5dTd0dVlTbThTNkp1WHIraGh2Smp0T3J6S1NySi9RcEVwOUhPSmVJ?=
 =?utf-8?B?WXZtRHJZVkdOK3JMR3dYaEZLVkpxektxeHZiZnhBcVlsSmt0bmZnVENvWVFP?=
 =?utf-8?B?UlRyVUkxWVZuWVNpcEVPTFNYdW5sT1c1UEdXVTNhVytGb0NoYWxTTVBxdGxL?=
 =?utf-8?B?ODZIWnBFOW9WdUxvVHdJMU8zZGluaE1tTWpPNDZRTWFicGdCOTZwV3lKajBJ?=
 =?utf-8?Q?TBQRgn9xepE11srPPdJtn+Dq0?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 467e4bcd-3ebe-4369-a19d-08dd92bc49ca
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5277.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2025 07:52:34.8784
 (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: Uor2NkWQU1DzYjZzcNW+/AhEbxQXvVwMPM9uNP+q0qqAi40bYLmrBBtK8vDXj9ry
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8145



On 14/05/2025 09:37, Julien Grall wrote:
> Hi Michal,
> 
> On 14/05/2025 08:04, Orzel, Michal wrote:
>>
>>
>> On 14/05/2025 08:56, Jan Beulich wrote:
>>> On 14.05.2025 08:31, Orzel, Michal wrote:
>>>> On 14/05/2025 02:07, Stefano Stabellini wrote:
>>>>> On Tue, 13 May 2025, Stewart Hildebrand wrote:
>>>>>> All functions in dom0less-build.c should be __init.
>>>> Why? This patch is first in your series and by that time there is no build time
>>>> enforcement. Together with the Fixes tag it implies that this is somehow an
>>>> issue (i.e. build/runtime issue) other than inconsistency for which we surely
>>>> don't need Fixes tag.
>>>
>>> I disagree: Code not called post-init should be in .init.*. While not formally
>>> a Misra violation (and wrongly so, I think), it imo effectively is: Such code
>>> is otherwise unreachable post-init.
>> You have a point here, I agree. Although I don't think MISRA differentiates
>> between unreachable in general vs pre or post init. It defines it as code that
>> cannot be executed. It does not go into stages of runtime execution.
>>
>> I'm thinking how this is different from a function that is called e.g. only once
>> at specific point at runtime execution for which we did not come up with a
>> separate section?
> 
> Along with what Jan said, in general there is some relaxation for the 
> boot code. For instance, we could accept if it panic.
> 
> There is at least one of the place in domain_build.c which panic() and 
> the parsing is not meant to be fully robust. So this code either need to 
> be __init (as this was the intention from when the feature was created) 
> or you need to fully harden the code.
What is this place?

~Michal



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:55:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:55:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984000.1370171 (Exim 4.92)
	(envelope-from )
	id 1uF6xK-0001Xk-W7; Wed, 14 May 2025 07:55:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984000.1370171; Wed, 14 May 2025 07:55:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uF6xK-0001Xd-T4; Wed, 14 May 2025 07:55:10 +0000
Received: by outflank-mailman (input) for mailman id 984000;
 Wed, 14 May 2025 07:55:09 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uF6xJ-0001XN-OV
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:55:09 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uF6xJ-008GrA-18;
 Wed, 14 May 2025 07:55:09 +0000
Received: from [2a02:8012:3a1:0:51a6:3d91:4273:769]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uF6xI-00EmhB-2e;
 Wed, 14 May 2025 07:55: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=ZfNXrx6WdzfrBWvamI+O7NHB/VyVm098wMltiYB1f10=; b=dVyPxSswZ+1P276Ac/ZB/hn1cm
	XjaZa94/zeeLruxwV0UoVagBxhApt5rjk/dPdPDaFikuyzeXTxyzs7fFMMZCDtVQ4Yh4/aqyX0TWu
	t8XMV7CenUdzgfTbLWxWu+b3impfIhX+Ivyiz8R1wpd8hfcBK3wRJ8RsrDCVhHs9fvAw=;
Message-ID: <00cc8940-9a6d-44b9-ba8b-18fe34e6d6d1@xen.org>
Date: Wed, 14 May 2025 08:55:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation __init
Content-Language: en-GB
To: "Orzel, Michal" , Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
 Bertrand Marquis ,
 Stefano Stabellini ,
 Stewart Hildebrand 
References: <20250513171810.668370-1-stewart.hildebrand@amd.com>
 
 
 <4e684e38-ed64-4731-8f00-afba938a28a0@suse.com>
 <369ccaf5-5c17-4601-88b0-eb32af8608d6@amd.com>
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 14/05/2025 08:52, Orzel, Michal wrote:
> 
> 
> On 14/05/2025 09:37, Julien Grall wrote:
>> Hi Michal,
>>
>> On 14/05/2025 08:04, Orzel, Michal wrote:
>>>
>>>
>>> On 14/05/2025 08:56, Jan Beulich wrote:
>>>> On 14.05.2025 08:31, Orzel, Michal wrote:
>>>>> On 14/05/2025 02:07, Stefano Stabellini wrote:
>>>>>> On Tue, 13 May 2025, Stewart Hildebrand wrote:
>>>>>>> All functions in dom0less-build.c should be __init.
>>>>> Why? This patch is first in your series and by that time there is no build time
>>>>> enforcement. Together with the Fixes tag it implies that this is somehow an
>>>>> issue (i.e. build/runtime issue) other than inconsistency for which we surely
>>>>> don't need Fixes tag.
>>>>
>>>> I disagree: Code not called post-init should be in .init.*. While not formally
>>>> a Misra violation (and wrongly so, I think), it imo effectively is: Such code
>>>> is otherwise unreachable post-init.
>>> You have a point here, I agree. Although I don't think MISRA differentiates
>>> between unreachable in general vs pre or post init. It defines it as code that
>>> cannot be executed. It does not go into stages of runtime execution.
>>>
>>> I'm thinking how this is different from a function that is called e.g. only once
>>> at specific point at runtime execution for which we did not come up with a
>>> separate section?
>>
>> Along with what Jan said, in general there is some relaxation for the
>> boot code. For instance, we could accept if it panic.
>>
>> There is at least one of the place in domain_build.c which panic() and
>> the parsing is not meant to be fully robust. So this code either need to
>> be __init (as this was the intention from when the feature was created)
>> or you need to fully harden the code.
> What is this place?

static void __init initialize_domU_xenstore(void)
{
[...]
         rc = alloc_xenstore_evtchn(d);
         if ( rc < 0 )
             panic("%pd: Failed to allocate xenstore_evtchn\n", d);
}

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 07:56:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 07:56:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984008.1370181 (Exim 4.92)
	(envelope-from )
	id 1uF6yV-000267-9e; Wed, 14 May 2025 07:56:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984008.1370181; Wed, 14 May 2025 07:56: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 1uF6yV-000260-5k; Wed, 14 May 2025 07:56:23 +0000
Received: by outflank-mailman (input) for mailman id 984008;
 Wed, 14 May 2025 07:56:21 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uF6yT-00025o-Q6
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:56:21 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uF6yT-008Gs5-1r;
 Wed, 14 May 2025 07:56:21 +0000
Received: from [2a02:8012:3a1:0:51a6:3d91:4273:769]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uF6yT-00EqjY-08;
 Wed, 14 May 2025 07:56: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=tnCLJ72ZR6IPMAha1TMyk5FpG8G37Vq1CT8bERcPWoA=; b=gR2hlEjerJc7XIVllFh0EjxMhE
	xwc003lyYSl3YUS2kXokyGfYmOmeQM3IUvUJYMJ6zKPbxNbniY8WJlffps3XBkFKlv0Mg8SWzGAro
	jYQrjqieJCosmu23Yivyu11gstqsmPnoj3Q1RRSd84lXgMbLO44kh5BMHc/oCEuWMStw=;
Message-ID: 
Date: Wed, 14 May 2025 08:56:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 2/6] arm/mpu: Introduce MPU memory region map structure
Content-Language: en-GB
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Penny Zheng ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk , Wei Chen 
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-3-luca.fancellu@arm.com>
From: Julien Grall 
In-Reply-To: <20250513084532.4059388-3-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Luca,

On 13/05/2025 09:45, Luca Fancellu wrote:
> From: Penny Zheng 
> 
> Introduce pr_t typedef which is a structure having the prbar
> and prlar members, each being structured as the registers of
> the AArch64 Armv8-R architecture.
> 
> Signed-off-by: Penny Zheng 
> Signed-off-by: Wei Chen 
> Signed-off-by: Luca Fancellu 

Acked-by: Julien Grall 

Cheers,

> ---
> Changes in v5:
>   - Given some comments on the page.h flags, I had to rework some
>     fields here to better match the flags usage and avoid duplication
> Changes in v4:
>   - Fixed typos, changed name for reserved bitfields, add emacs bits
>     to arm64/mpu.h.
>     Now base and limit are 42 bits as we consider FEAT_LPA disabled,
>     since we support max 1TB of memory.
>     Moved data structure in commit that uses it
> ---
>   xen/arch/arm/include/asm/arm64/mpu.h | 52 ++++++++++++++++++++++++++++
>   xen/arch/arm/include/asm/mpu.h       |  4 +++
>   2 files changed, 56 insertions(+)
>   create mode 100644 xen/arch/arm/include/asm/arm64/mpu.h
> 
> diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h
> new file mode 100644
> index 000000000000..d3c055a2e53b
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/arm64/mpu.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __ARM_ARM64_MPU_H__
> +#define __ARM_ARM64_MPU_H__
> +
> +#ifndef __ASSEMBLY__
> +
> +/* Protection Region Base Address Register */
> +typedef union {
> +    struct __packed {
> +        unsigned long xn_0:1;     /* Execute-Never XN[0] */
> +        unsigned long xn:1;       /* Execute-Never XN[1] */
> +        unsigned long ap_0:1;     /* Access Permission AP[0] */
> +        unsigned long ro:1;       /* Access Permission AP[1] */
> +        unsigned long sh:2;       /* Shareability */
> +        unsigned long base:42;    /* Base Address */
> +        unsigned long res0:16;    /* RES0 */
> +    } reg;
> +    uint64_t bits;
> +} prbar_t;
> +
> +/* Protection Region Limit Address Register */
> +typedef union {
> +    struct __packed {
> +        unsigned long en:1;     /* Region enable */
> +        unsigned long ai:3;     /* Memory Attribute Index */
> +        unsigned long ns:1;     /* Not-Secure */
> +        unsigned long res0:1;   /* RES0 */
> +        unsigned long limit:42; /* Limit Address */
> +        unsigned long res1:16;  /* RES0 */
> +    } reg;
> +    uint64_t bits;
> +} prlar_t;
> +
> +/* MPU Protection Region */
> +typedef struct {
> +    prbar_t prbar;
> +    prlar_t prlar;
> +} pr_t;
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* __ARM_ARM64_MPU_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
> index d4ec4248b62b..bb83f5a5f580 100644
> --- a/xen/arch/arm/include/asm/mpu.h
> +++ b/xen/arch/arm/include/asm/mpu.h
> @@ -6,6 +6,10 @@
>   #ifndef __ARM_MPU_H__
>   #define __ARM_MPU_H__
>   
> +#if defined(CONFIG_ARM_64)
> +# include 
> +#endif
> +
>   #define MPU_REGION_SHIFT  6
>   #define MPU_REGION_ALIGN  (_AC(1, UL) << MPU_REGION_SHIFT)
>   #define MPU_REGION_MASK   (~(MPU_REGION_ALIGN - 1))

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 08:00:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 08:00:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984020.1370191 (Exim 4.92)
	(envelope-from )
	id 1uF71w-0002k1-OW; Wed, 14 May 2025 07:59:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984020.1370191; Wed, 14 May 2025 07: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 1uF71w-0002ju-Ki; Wed, 14 May 2025 07:59:56 +0000
Received: by outflank-mailman (input) for mailman id 984020;
 Wed, 14 May 2025 07:59:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF71v-0002jj-E3
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 07:59:55 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20618.outbound.protection.outlook.com
 [2a01:111:f403:2407::618])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6a5ef98f-3099-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 09:59:53 +0200 (CEST)
Received: from DM4PR12MB5277.namprd12.prod.outlook.com (2603:10b6:5:390::7) by
 SA1PR12MB8986.namprd12.prod.outlook.com (2603:10b6:806:375::8) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8722.28; Wed, 14 May 2025 07:59:48 +0000
Received: from DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e]) by DM4PR12MB5277.namprd12.prod.outlook.com
 ([fe80::9ab:5367:ba51:af6e%3]) with mapi id 15.20.8722.027; Wed, 14 May 2025
 07:59: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" 
X-Inumbo-ID: 6a5ef98f-3099-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XsuZRKs89S2qSUO2xPZmRvD0QEKtKs1hZaFV4v2geDLnhnSdxfOuQh4DT5NHbGYxV33QYDUk6DuJEERpcA8L7FgPU/R2mrwVOfj3JaleYTBcmK3YgI2khpJpRpgwGRmUCB4ZxRIwzmUl7K6WeYstpyHjC9yZDlL+H/mASacKdByTLXpfCM25l7NJzAp6lJogpNT1INhQz6kCVqskGr0nTbgOdIAvnsTcRccI7V5FiXYJopVGcxy+TlOgp5ihg6RV5dVQLfHHWRUJRqs3/DqlaoZ1YM7O1RSwMwhijoKveETVxLUh9SiR1sdwmlr88xBAoqp4uhyma6NuX/UWWVymVw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fYGQKwvDMibWlZyTnauyqqfrjFM0hj1b3c2yT7Z/Eeg=;
 b=Xi2KWf2Lv5VJTIm7DzuxfCKK2Yda//4zvuFABJR05p/iOXrk0e55070vtJisbvhLtuLYxXIi0jZ13PaDxk7rPxCgYVIjXfoPLnLoPBPAqhmPl7VUM2K/FA74AL0ezcWhOiN9FVCj99hA8qnOOM108w71jMSwTHY+vYpJ/RqSBmwWp1y339hpJMnCUd2GI81u0QPLLRqMK64VGKge+8DRJ30HPbjg6IyPkknFeVSuHcHjbNX+hKATxkuAacnq5VC8S7hNPN7GTKgZs78KLGP01JIDSzUjjPFhyjvsPOa63RJNT5i2GgOhO/iBv3Vn6RFXEfR+xrKO0b10JsVhXB1JqA==
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=fYGQKwvDMibWlZyTnauyqqfrjFM0hj1b3c2yT7Z/Eeg=;
 b=ooyNsAUHPGDA4sibd/xBofF3hvpQkeHSxM1c0hVWpfSYdvRmfqKhebszXRGkNzNTs+m/yDfvQtoHywVXJOuuFqKBhUCcsl5urEL0MR+TTO5uac2Xi5KfQ4uE01FP1kIIewRrG0ceAF9tCGZjLlhUyqiGkDjTjWQD6CYf0hjCvTw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <61f60a77-637b-488b-b101-1ac0296a7e96@amd.com>
Date: Wed, 14 May 2025 09:59:43 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation __init
To: Julien Grall , Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
 Bertrand Marquis ,
 Stefano Stabellini ,
 Stewart Hildebrand 
References: <20250513171810.668370-1-stewart.hildebrand@amd.com>
 
 
 <4e684e38-ed64-4731-8f00-afba938a28a0@suse.com>
 <369ccaf5-5c17-4601-88b0-eb32af8608d6@amd.com>
 
 
 <00cc8940-9a6d-44b9-ba8b-18fe34e6d6d1@xen.org>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <00cc8940-9a6d-44b9-ba8b-18fe34e6d6d1@xen.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR0P281CA0068.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:49::13) To DM4PR12MB5277.namprd12.prod.outlook.com
 (2603:10b6:5:390::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR12MB5277:EE_|SA1PR12MB8986:EE_
X-MS-Office365-Filtering-Correlation-Id: 203ff0ed-9ec3-4c42-e220-08dd92bd4c11
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?QjFGRy9FWk5UeEQzeEN4Y3lRVUJxMEllUmREV25pSVpNU0VHaFJjRUFqZUpB?=
 =?utf-8?B?VS9kOUNST3h0cG45SWdlVTE4MjJWWUU0SXRwTHRTZHQzaEpqaEd1ZWFtak5D?=
 =?utf-8?B?akRsMjlKcmxMME9GZkxpUXMxa1ZGRW5rZmtocDBRWWFpTkpjUkczMmp2M0xt?=
 =?utf-8?B?cGJCZTltQ2Q0Um9NZkliajRLaVdiV1UvcG1TbXZ5bTNsd0ZJZHFEV3Rmcm81?=
 =?utf-8?B?ZVJNeUc5dWpiMWZiUUczL1FnQ0tEOW0zblA1ZVIwWmRmbmRJd00zbEhHMnA3?=
 =?utf-8?B?L3JaaG10SmtiSmNrRWNTTVhGWUVHaDZhdTVtMXJhTnVRSXd2TzFia0EwdEFM?=
 =?utf-8?B?VHR3dlh5Ym92eVZvWWdLSTZkb2FBWmdsQTBUUVZTdVR5MFJoVGgvaUY0cTRp?=
 =?utf-8?B?ZkJseWNHczhZQmtEZXFzU3BvZzI1S3ZEVHQzZytaMFhjZFFjSnJFRFFqOGlH?=
 =?utf-8?B?QTU0d0pUREpzT2huUm9HcnRyb0p6QzdTTnZweVZKMkdFaEJXU0RNTkhadmNW?=
 =?utf-8?B?dlRKbExUcFBwWDJFMkJ2YVVKUXlJUERpOFl6RktseTZVTjJ3QzZqdWt3Y1Ju?=
 =?utf-8?B?VW5jU3pJUnJDMm43K3BsSHdBbmZBMXpYSHhSZmpkR0NoYzR6UmhJbjcxQWp6?=
 =?utf-8?B?VmM5a0JwR2JTM2FMcVNrcjY3NnN3cUJLcEtOZmhLVFRNWU40emQ5V0ZqS3k1?=
 =?utf-8?B?TzhWdTFtbVRhK2xGSFhZWGk0SlIvbnBOMFlXZ2lsb2w2cTliRWZqUVM5OUxV?=
 =?utf-8?B?cWdPMDhiOTNjaFFySkJrM0cyMmVpOEU2eS9NVGdrUTJtUkdWYmRWQk91SFF2?=
 =?utf-8?B?UW1XeE5BL3RndkMvOWJwdzNMMEo4VHJseThZckxuVGNGR3JWM0JldWhjOW9n?=
 =?utf-8?B?cjFKcnlQZTczK3NrMVlWOWJEQUs3YUVadXRPb0RzRnhWR21UbmdSMGtjd3Nl?=
 =?utf-8?B?QmFWTW9IUmpTNm40RndxSGJyb2VBcWl2Y1pPQTFZajZnVHA3Q2R4OTg5Vm9P?=
 =?utf-8?B?anNBd3VMQndCY0diUVl2TFZRaHF4Q0hJU3JQSHgvMzNqSDBYT1hhWWpkYlFQ?=
 =?utf-8?B?OVpuQVdOVE9pRjJFNDNSaTJyZC9JaTdWYXdidDFMUEcvRGhqbGN3cWZqMzl1?=
 =?utf-8?B?OVpVWUFSSHh0WVBwdDhTRlhvbXF1OHNhZFpxWWNFNHAzcjh1cVRackFoeGZ6?=
 =?utf-8?B?T01vYzg4bHhKeTUxdlJneFpZeVNWVklneDBKaG1zMGtLZytSRktuRlhUSVFC?=
 =?utf-8?B?VlVKTXF5MDVCb0M0Q0dDUzZYeWk4eEFmTjV1MGVHNk1FVW9FWTVQeWxlNktm?=
 =?utf-8?B?dVM4NmZkTThXKzVFQWI5bjBkM0JLbGV0eHIrMFNLMm1XY1NqbDBrd1U2MlYv?=
 =?utf-8?B?bVp0dlZoQzdKaWhiRS8zKzNEalpoK3ZpTGxZdE5iSlZGUWZ3NkRZNjhsZWd4?=
 =?utf-8?B?OVVpSVVwZU5obXBpeTdTdWxmTG1kaGtCQ1ZESU4yVDFvNWMwMzlqSkxZSGpZ?=
 =?utf-8?B?bnJGN1pzQU4zQU1RYzVDK3BERk5QVW5BdXJjTy9wbnFTdU1vN0tlZ2M1S2Vy?=
 =?utf-8?B?SEpZaEZ0VWR2SXBwR2h4cE1KVThjcWZJbXFwN004MnFKYUZjOGlCQzROazVT?=
 =?utf-8?B?RVUyRlFBcWRpQmluYUNxV0hYaC9DMkU1Rm5hU0FITXRoZlJtWUFNUWdhQUw5?=
 =?utf-8?B?NFcrbEJZTWJ5UlFSZ09QTDBjd1lud0VqK1BuZnphZ09IdWRKeTh2VkJpQUgz?=
 =?utf-8?B?V0xKbHNBSkRrcWVuTXVmQUdvbmNzN05wR3djVTZwWW9ockZlb2lFbm5CQW1a?=
 =?utf-8?B?TW9iZG56SWpmTEt4TTI0ckgyZEltcmZFVEtwV2llQllJUEFnUTNNeWNWZ2JD?=
 =?utf-8?B?M3lXU1VUN3RGQlRRZlFTL2dRUkN6VEgvNFJvdEtPVC92VVJ6L0c0ZnZ0NzBX?=
 =?utf-8?Q?4KdTI8x14M4=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5277.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Q1BsUDJicjZTRVhxYUttZHVBQWJ5U1VWWFMrdEZZK29uRWd2Ukl1c3YvZ0F2?=
 =?utf-8?B?c2tuSUtWZVNNV0JCVUtqaGdQSnhKYTM4TVd4ZXZnM0k5dzNLMWFZUWVDYzVL?=
 =?utf-8?B?NG1zOC9HUEVPYWRLQjMwRW1YRVhKY0x0eGp0RlNZaW5NU1d3UW1YVTM0T2ti?=
 =?utf-8?B?SmhsOWRldlYydXdvQmVXcFUyL3JCQ0FCb1hhZUVZcnZDTWVhYXg1bTd2aFpl?=
 =?utf-8?B?UHkrRGY3VW96eUVZMEtCVzBNZmVoampndnByenl2MmJ6NXNUb3M1a1FCLzM1?=
 =?utf-8?B?dkZxTlJ3REYvWStkRkFKbHpwdmVJZmJpU0szTWVEcm5TQ29CUkRTN0RHOW8w?=
 =?utf-8?B?eHhHNStvNDFEQW5KbVFKRFNXZDJUT3YvU1hSa3B0YTlWU2ZkNGp6dG1Ua1Bp?=
 =?utf-8?B?TXFTL0VmdHBFbEhZNFlGTTBVWXZKdERKVi9PaWYzSWc1YkNrUDhRSGNWUXVB?=
 =?utf-8?B?UTI0ZnRJblBqWjc5TzZueldOYnQ1a3RaMmhkZUlkWnpkTVVpVEVyQlFHdG9P?=
 =?utf-8?B?eVk2YlpZYkZiU1Jqa2R3UXhtUS9HUTNCYzZ0SlBRR3ZWSm1oVjNuVVl0d0lG?=
 =?utf-8?B?K25VbXJoZnkvcTZ5MHRrekFxUFM5NURlRSt4Umw4aTdoc1hZUXZlZ1VJQ2lF?=
 =?utf-8?B?YlZjV2RIaXJPc2ZQK2VtZVlCMVM3SXViclpXKzJKR1RDOTN4R0h1NXRWKzRp?=
 =?utf-8?B?TUhHN0kxK0RHODU1eGkvdEZjZUlCdGU5UVYreHF3NVhCenlhQnkyeWpsckVl?=
 =?utf-8?B?Tzl4a1F2bGNsc01KSGV1a3pNMkFQS2tPUHNxaWl2ajY5a09EUUhFR1hPd3lp?=
 =?utf-8?B?bnpKMW44MnpsR3VaV2s4dTloNG40WVBYZ2NBYUlzdklXUXVmSERLN2JvalB0?=
 =?utf-8?B?eGFqS2RGSmZiNEkwKzRvbG1CNG80bE0rZ1QwaFhBb2JkVTNiQzFKbTlMMzV4?=
 =?utf-8?B?NUNYc2lxUUNUTHpnVGJsaUZXdFZlQ29FSWxlalg5UUxWdUFsQU0yVk5FbjlV?=
 =?utf-8?B?Z21IZ1ExUDVOZURRTVlRSEF1UGtTVGdmZWt1Y3h0aUUySXJrdkdsbGxDcGJT?=
 =?utf-8?B?WUg3ejIvNjBoOHl1VHU4MzEzR2E0c1RMWmdPWkVOemRWdHozQmY0Yit1QVl6?=
 =?utf-8?B?TXRHQ252MWttV1FYTmI1TG1vTFlkM3ZaWVhEUC9tQ1pXNGNzSFYwTk9IN1Vm?=
 =?utf-8?B?NnJWOEFCSFlMOE56eVg3TEJIaG1WYndKcmcxbEdIbUQ4OHdBemZ2V1QvTnMy?=
 =?utf-8?B?TGlHUlMxaHQwOURCQ1NtbnExNlRZSzJGQzYwWDFnRUUxelBHSjQxVVBNM1E2?=
 =?utf-8?B?YjBabnZHa0VvQ25pcWZjejJjMGIxVS83VTQwQkJQMlZzZWlSbUhqemp0Tkdx?=
 =?utf-8?B?TmpLUTRpSmgxVWtTc2I2ck1QWnBWVzg5aXVyRmpJSUUyQjRlUkpNWmxPWXU2?=
 =?utf-8?B?TllxSm5OeXM4RWZLeXlrU2x5R2dzVzBVSlRqdkl6bzJqRDVhSjI0SDNuZGt3?=
 =?utf-8?B?NDdaUHBMdzNwQ2pxUE8rNUZXZFM1eVBEZEpJNDZ5WHBKbHE1YldtK1NmbnBL?=
 =?utf-8?B?MDZDZWdoQjNFcWFWYkZ0cDU2THo1WHJDSDJjcG1kTFpkTGhNWEJvOEdWanhv?=
 =?utf-8?B?Wm9BNUJJckZDb0xSWTZtQ0VsNG5Za3MwODR5V0d5eE5TZytiN2xFWFZJMlIw?=
 =?utf-8?B?QmozbzRtU2VMK0JxOWdRcjN3aCsvRFdsZ1N2UXNHa0o0ZnBvQWhKSS8rRy9P?=
 =?utf-8?B?NFl4NHpoeVBNc3BEcFdDT1JTeU56VGxCRVM0NzlKb0VHUGQ0d2NobE1DbjJT?=
 =?utf-8?B?ZzdER2FaTFBkQWpHTmN3NlRFbUQ5N0szdjhBK0M0WHJxMEhIcllodlFybmF6?=
 =?utf-8?B?MlV6eDdNUytQTE96YXY1M0l2ckpUMnVndzNwVU9JcEJwZjdBUlZ1Slh5em1T?=
 =?utf-8?B?U0tsSkllWk5OUWtqbXluYTBvS3JWMWdLT3Z1aGxIcXZzNkVtV2JTTmNiRHNN?=
 =?utf-8?B?ZitUbS9BTjBORnk2MEFQRFl1L2Erb2lKREVMaUlPdS9tVkZwVktWRE9sWTdh?=
 =?utf-8?B?Zm5GTUs3L1NjZGRCNTZQWEk1aFpUYTBjdnJJZ0pwTFZ2T1gzcUZ1aGtuTGoy?=
 =?utf-8?Q?vqDAGefvohBolGMJaCwJpSmYN?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 203ff0ed-9ec3-4c42-e220-08dd92bd4c11
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5277.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2025 07:59:48.2273
 (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: /zFjkjvYOGjJdAW4v3cRS8C+eAKPRgiuZmLIjnCdQ+ca/HawHQFhk5o0AML1LwNr
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8986



On 14/05/2025 09:55, Julien Grall wrote:
> 
> 
> On 14/05/2025 08:52, Orzel, Michal wrote:
>>
>>
>> On 14/05/2025 09:37, Julien Grall wrote:
>>> Hi Michal,
>>>
>>> On 14/05/2025 08:04, Orzel, Michal wrote:
>>>>
>>>>
>>>> On 14/05/2025 08:56, Jan Beulich wrote:
>>>>> On 14.05.2025 08:31, Orzel, Michal wrote:
>>>>>> On 14/05/2025 02:07, Stefano Stabellini wrote:
>>>>>>> On Tue, 13 May 2025, Stewart Hildebrand wrote:
>>>>>>>> All functions in dom0less-build.c should be __init.
>>>>>> Why? This patch is first in your series and by that time there is no build time
>>>>>> enforcement. Together with the Fixes tag it implies that this is somehow an
>>>>>> issue (i.e. build/runtime issue) other than inconsistency for which we surely
>>>>>> don't need Fixes tag.
>>>>>
>>>>> I disagree: Code not called post-init should be in .init.*. While not formally
>>>>> a Misra violation (and wrongly so, I think), it imo effectively is: Such code
>>>>> is otherwise unreachable post-init.
>>>> You have a point here, I agree. Although I don't think MISRA differentiates
>>>> between unreachable in general vs pre or post init. It defines it as code that
>>>> cannot be executed. It does not go into stages of runtime execution.
>>>>
>>>> I'm thinking how this is different from a function that is called e.g. only once
>>>> at specific point at runtime execution for which we did not come up with a
>>>> separate section?
>>>
>>> Along with what Jan said, in general there is some relaxation for the
>>> boot code. For instance, we could accept if it panic.
>>>
>>> There is at least one of the place in domain_build.c which panic() and
>>> the parsing is not meant to be fully robust. So this code either need to
>>> be __init (as this was the intention from when the feature was created)
>>> or you need to fully harden the code.
>> What is this place?
> 
> static void __init initialize_domU_xenstore(void)
> {
> [...]
>          rc = alloc_xenstore_evtchn(d);
>          if ( rc < 0 )
>              panic("%pd: Failed to allocate xenstore_evtchn\n", d);
> }
Sorry, I am a bit lost, maybe I don't understand your reply. Do you mean we need
to do sth about it (I can see it's __init and we have panic) or this is just an
example?

~Michal



From xen-devel-bounces@lists.xenproject.org Wed May 14 08:02:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 08:02:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984036.1370201 (Exim 4.92)
	(envelope-from )
	id 1uF74E-0005We-CL; Wed, 14 May 2025 08:02:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984036.1370201; Wed, 14 May 2025 08:02: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 1uF74E-0005WX-8y; Wed, 14 May 2025 08:02:18 +0000
Received: by outflank-mailman (input) for mailman id 984036;
 Wed, 14 May 2025 08:02:17 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uF74D-0005Vt-1S
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 08:02:17 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uF74C-008HVr-1y;
 Wed, 14 May 2025 08:02:16 +0000
Received: from [2a02:8012:3a1:0:51a6:3d91:4273:769]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uF74B-00F8B5-2w;
 Wed, 14 May 2025 08:02: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=jT2lqUZoz7zBZkRttb4zUM3DhizvcmqXr0HGFHC5DVQ=; b=Uk7k5U8OjLJsTk7Y4kYMIQBNZ9
	bARPMfAAbc7JNmjaMaYilMTjQzVZW5t2zxQ33j5iL31qwqXApPej2dVq0MqU3RA7SBtMewoeyZ3A4
	6li02I2f42h4EnRqG6TyorloPK9pY0Quah9tvZcf1E6nCeE70wMyq+Eqf3GARtd3H36E=;
Message-ID: 
Date: Wed, 14 May 2025 09:02:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/dom0less: mark domain_p2m_set_allocation __init
Content-Language: en-GB
To: "Orzel, Michal" , Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
 Bertrand Marquis ,
 Stefano Stabellini ,
 Stewart Hildebrand 
References: <20250513171810.668370-1-stewart.hildebrand@amd.com>
 
 
 <4e684e38-ed64-4731-8f00-afba938a28a0@suse.com>
 <369ccaf5-5c17-4601-88b0-eb32af8608d6@amd.com>
 
 
 <00cc8940-9a6d-44b9-ba8b-18fe34e6d6d1@xen.org>
 <61f60a77-637b-488b-b101-1ac0296a7e96@amd.com>
From: Julien Grall 
In-Reply-To: <61f60a77-637b-488b-b101-1ac0296a7e96@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 14/05/2025 08:59, Orzel, Michal wrote:
> 
> 
> On 14/05/2025 09:55, Julien Grall wrote:
>>
>>
>> On 14/05/2025 08:52, Orzel, Michal wrote:
>>>
>>>
>>> On 14/05/2025 09:37, Julien Grall wrote:
>>>> Hi Michal,
>>>>
>>>> On 14/05/2025 08:04, Orzel, Michal wrote:
>>>>>
>>>>>
>>>>> On 14/05/2025 08:56, Jan Beulich wrote:
>>>>>> On 14.05.2025 08:31, Orzel, Michal wrote:
>>>>>>> On 14/05/2025 02:07, Stefano Stabellini wrote:
>>>>>>>> On Tue, 13 May 2025, Stewart Hildebrand wrote:
>>>>>>>>> All functions in dom0less-build.c should be __init.
>>>>>>> Why? This patch is first in your series and by that time there is no build time
>>>>>>> enforcement. Together with the Fixes tag it implies that this is somehow an
>>>>>>> issue (i.e. build/runtime issue) other than inconsistency for which we surely
>>>>>>> don't need Fixes tag.
>>>>>>
>>>>>> I disagree: Code not called post-init should be in .init.*. While not formally
>>>>>> a Misra violation (and wrongly so, I think), it imo effectively is: Such code
>>>>>> is otherwise unreachable post-init.
>>>>> You have a point here, I agree. Although I don't think MISRA differentiates
>>>>> between unreachable in general vs pre or post init. It defines it as code that
>>>>> cannot be executed. It does not go into stages of runtime execution.
>>>>>
>>>>> I'm thinking how this is different from a function that is called e.g. only once
>>>>> at specific point at runtime execution for which we did not come up with a
>>>>> separate section?
>>>>
>>>> Along with what Jan said, in general there is some relaxation for the
>>>> boot code. For instance, we could accept if it panic.
>>>>
>>>> There is at least one of the place in domain_build.c which panic() and
>>>> the parsing is not meant to be fully robust. So this code either need to
>>>> be __init (as this was the intention from when the feature was created)
>>>> or you need to fully harden the code.
>>> What is this place?
>>
>> static void __init initialize_domU_xenstore(void)
>> {
>> [...]
>>           rc = alloc_xenstore_evtchn(d);
>>           if ( rc < 0 )
>>               panic("%pd: Failed to allocate xenstore_evtchn\n", d);
>> }
> Sorry, I am a bit lost, maybe I don't understand your reply. Do you mean we need
> to do sth about it (I can see it's __init and we have panic) or this is just an
> example?

I was providing an example of why we enforce to enforce __init for 
dom0-build.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 08:04:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 08:04:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984045.1370210 (Exim 4.92)
	(envelope-from )
	id 1uF76a-00069p-NF; Wed, 14 May 2025 08:04:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984045.1370210; Wed, 14 May 2025 08: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 1uF76a-00069i-KJ; Wed, 14 May 2025 08:04:44 +0000
Received: by outflank-mailman (input) for mailman id 984045;
 Wed, 14 May 2025 08:04:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF76Z-00069Y-9a
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 08:04:43 +0000
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com
 [2607:f8b0:4864:20::430])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 16d8b748-309a-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 10:04:42 +0200 (CEST)
Received: by mail-pf1-x430.google.com with SMTP id
 d2e1a72fcca58-7423fadbe77so4954408b3a.3
 for ; Wed, 14 May 2025 01:04:42 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 41be03b00d2f7-b235252c7bdsm8426426a12.78.2025.05.14.01.04.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 01: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" 
X-Inumbo-ID: 16d8b748-309a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747209881; x=1747814681; 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;
        bh=1r1q9j/NiqaxCVnQX79fx6ZSieyvy37ernzXHZca/GE=;
        b=ftxImUPBV+uZ1D+TzyGBitsh5PYAWoNMiAEL8dYndNKIoIuOol35qLlNE+U4o/9Du2
         C81mTiudnOWjLuI8Kb2zW0aDVhN50KJODSFsydGEH42f54ORVvG8DDY/rAqkJ3l9u5U9
         4zzCdgqzMHP0Vox9Oovqoug1BUMDyrJXggFbo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747209881; x=1747814681;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=1r1q9j/NiqaxCVnQX79fx6ZSieyvy37ernzXHZca/GE=;
        b=Cl6EqyyOCts4LaIESzTM2JzSHEdsSa0hac8sOmGyWGZo0E0SxcDZGdUiU5AmZwLBAb
         k0Io2XAN2l5xmtLdegxyzcJNzcUfsGgTTQZWkhzGjR+chCw3GqT7enLj2pCaekACC4+P
         wZY4VczsK2OhPyS3wvH3UK6lGeqWDwEn4pKHr5PbNWEx6UTNYgVTeI0/YAaHWzZMY092
         IXik8MBe8KcWG15uDb1agqYngLpKrMurgnnV7lu6RFrqb+edd6RMcXLHJ1MwHbRL2vJb
         SBdj4egcYrtAbYeTKt0Gv0qqeEki1FSEJOvekckln31P9fH+NvD99PWJR5WTa4DuVOYI
         L7DQ==
X-Forwarded-Encrypted: i=1; AJvYcCVVPDYfxRPRe1ztHZeQbABCK41Vi/PaA14sXPI9iX1sDbeF6o4F/pwmZ1iE4wH995E/ypNmfoZhvA4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwNhpsD2kbAbnatyaiWY0dgFWM9dDZr68C7HCsR2KEAz0tPoFBG
	WdgOFIn4YY8abFJ+VDtK/jbdh2ruNkicWFim6jINbeVSv86mUj2Q/kYUX4Khyvg=
X-Gm-Gg: ASbGncujPJpzALGQho0l2RXRlPFP5jxfCn8LnYPQZCwYs8Daid8ThK4EPEmSNGXr5qy
	fPZ+UISxbDVFRNfU/Zb4qsjizHabj4wO2nT1y3XSocKGsAq+AEDP0c34asfXXuAI2t+2nRnvrG+
	CdmbflDdMq/V0diBbzEfM4JbTqXqnzNW1INE6as+dELCNgBhtqLKFgLUJWbnk2Z9YHVu/1WeZAL
	F7Cfenno4Alejl2docTObSu6FQz6yloUqZno8huMaB54VnKfoZE+MmFiJoDC7U/06mf1/1eEyEe
	JPnu6HsVCni9YGuXkwplyTK0m0E4gRbP3C9bwjMo3eBW4P5qv4yzW9xxxh27bwoIQW8=
X-Google-Smtp-Source: AGHT+IGjjnzREvj/FCp6iOWskek++QwmkIK4fblbdLCYyxcvDMW5FxY5l8ARHhqFi5/9zGZiCAVtFA==
X-Received: by 2002:a05:6a21:6f13:b0:1f5:8e94:2e83 with SMTP id adf61e73a8af0-215ff093380mr4072477637.8.1747209880749;
        Wed, 14 May 2025 01:04:40 -0700 (PDT)
From: Roger Pau Monne 
To: Juergen Gross ,
	Roger Pau Monne ,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Cc: jason.andryuk@amd.com,
	John ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko 
Subject: [PATCH] xen/x86: fix initial memory balloon target
Date: Wed, 14 May 2025 10:04:26 +0200
Message-ID: <20250514080427.28129-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When adding extra memory regions as ballooned pages also adjust the balloon
target, otherwise when the balloon driver is started it will populate
memory to match the target value and consume all the extra memory regions
added.

This made the usage of the Xen `dom0_mem=,max:` command line parameter for
dom0 not work as expected, as the target won't be adjusted and when the
balloon is started it will populate memory straight to the 'max:' value.
It would equally affect domUs that have memory != maxmem.

Kernels built with CONFIG_XEN_UNPOPULATED_ALLOC are not affected, because
the extra memory regions are consumed by the unpopulated allocation driver,
and then balloon_add_regions() becomes a no-op.

Reported-by: John 
Fixes: 87af633689ce ('x86/xen: fix balloon target initialization for PVH dom0')
Signed-off-by: Roger Pau Monné 
---
 drivers/xen/balloon.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 8c852807ba1c..2de37dcd7556 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -704,15 +704,18 @@ static int __init balloon_add_regions(void)
 
 		/*
 		 * Extra regions are accounted for in the physmap, but need
-		 * decreasing from current_pages to balloon down the initial
-		 * allocation, because they are already accounted for in
-		 * total_pages.
+		 * decreasing from current_pages and target_pages to balloon
+		 * down the initial allocation, because they are already
+		 * accounted for in total_pages.
 		 */
-		if (extra_pfn_end - start_pfn >= balloon_stats.current_pages) {
+		pages = extra_pfn_end - start_pfn;
+		if (pages >= balloon_stats.current_pages ||
+		    pages >= balloon_stats.target_pages) {
 			WARN(1, "Extra pages underflow current target");
 			return -ERANGE;
 		}
-		balloon_stats.current_pages -= extra_pfn_end - start_pfn;
+		balloon_stats.current_pages -= pages;
+		balloon_stats.target_pages -= pages;
 	}
 
 	return 0;
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Wed May 14 08:28:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 08:28:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984062.1370221 (Exim 4.92)
	(envelope-from )
	id 1uF7Tb-0001oy-Jz; Wed, 14 May 2025 08:28:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984062.1370221; Wed, 14 May 2025 08: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 1uF7Tb-0001or-Gu; Wed, 14 May 2025 08:28:31 +0000
Received: by outflank-mailman (input) for mailman id 984062;
 Wed, 14 May 2025 08:28:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF7TZ-0001oa-UJ
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 08:28:29 +0000
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com
 [2607:f8b0:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 65e9b29f-309d-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 10:28:23 +0200 (CEST)
Received: by mail-pl1-x632.google.com with SMTP id
 d9443c01a7336-22e033a3a07so72241045ad.0
 for ; Wed, 14 May 2025 01:28:23 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-22fc82a4cecsm93382525ad.238.2025.05.14.01.28.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 01:28:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 65e9b29f-309d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747211302; x=1747816102; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=n6hXb6nZTewSpDRaehqeYINgtvWu4WtI2dXs2UdVQZo=;
        b=P+ZLpFFvhqgi7+EIUbbYuei6qG+JxL44eaa8L2X+X9PW+j+ZZBC3xxer6pwxQazHaj
         cw6y49uyhyDXAOv2O1aqvACYHDNtgyKISrsUW8/BgoLdkIhNlr6ZO+c5+mS/2beIkrWi
         SCMQHFFrdA36xEIyU/BH8fJ2yiLEuDaZawDPk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747211302; x=1747816102;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=n6hXb6nZTewSpDRaehqeYINgtvWu4WtI2dXs2UdVQZo=;
        b=NDIOs7psoGpPC8PV9tEeLQKRpFP4iqgCGtgTaXgEX53l+Dleb1f9NZpujHt8m6DuUk
         6Aco6wI27bBErDUXczOn1E5KPWbmBT64hVxC7ADQFuDZyCR17C3e5uVhSL1vjpW1HsHj
         fjliqxexHvhu/oS+SVySpy834vNBs7PS3GB/O/z6KwCNI5LPstONnKF0QkTTSUoE1gp2
         JS2AsH+hH8uVsP5LUzHC+S4Wu6c93L5Xvu3xvGv6fFGHhOQRHvNzKn+ISD5HX4hnafoe
         cXS/Ae2FxD16Vg6gsryKXnYNEsrj49sdCxiE8SuEuEjdD+5co9/3FH/e1wOsZaCq8S6p
         G22g==
X-Gm-Message-State: AOJu0YzxYJxm81obzirb7ZbmCEs2p66CdVOepAVTTpl+nzHwuNpyZq/p
	nVXCSdOR9PvN8xZwqMKglqn0HPjSUIihxAIHn1FoAnFpL8+awctMMTGuXlHCQt0=
X-Gm-Gg: ASbGncu1QSDWPyBVqE1FAwEljrcqyPTWNlQykq9tNGByJZkXNkcfi5UezFyBKg2Lw2+
	2H36sIYT5w6MLliqCSDGEKDObpTUX/6L10riWbRcrnPGr2hSAHp9z6yVhsrl86sS6rPV9WSVlHm
	l0T9Imn6vR63pk/nVXr4t+umYlUTaw+VF1KsVEOCAfKjJqkzKyIhmRFP5rdLSjcu6KMV+PKV9Gy
	7mPEk9DWb22OmaQ/ijGYhiPG5yuRD6BOjle5FtVL/TPFtn8zCsA6wKvQ1aRYqBrRO0UYxlanOHb
	28ebrnU3fhBWVmMU4l6KR/Qa5+dE91HJMBGvkS9Wk2vLRoUFeKca2KK+Uo1IoxQCMFQ=
X-Google-Smtp-Source: AGHT+IHDjvIlmPOt+Z7lHj5X4OY/y+be8tbv6JpXFsfaSKCN2hA4sXUUvbZpgnSwdprAAz2qHkI17A==
X-Received: by 2002:a17:903:166e:b0:22e:566f:bca7 with SMTP id d9443c01a7336-231980e4093mr34543545ad.17.1747211301956;
        Wed, 14 May 2025 01:28:21 -0700 (PDT)
Date: Wed, 14 May 2025 10:28:16 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper ,
	Marek Marczykowski 
Subject: Re: [PATCH] x86/IRQ: constrain creator-domain-ID assertion
Message-ID: 
References: <9fc0b9d1-15e5-47e9-a532-a25e1ac32ba2@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9fc0b9d1-15e5-47e9-a532-a25e1ac32ba2@suse.com>

On Wed, May 14, 2025 at 09:22:54AM +0200, Jan Beulich wrote:
> If init_one_irq_desc() fails, ->arch.creator_domid won't be set to the
> expected value, and hence the assertion may trigger. Limit it to just
> the success case of that function call.
> 
> Fixes: 92d9101eab ("x86: allow stubdom access to irq created for msi")
> Reported-by: Marek Marczykowski-Górecki 
> Signed-off-by: Jan Beulich 

Hm, the logic in that function is convoluted to say the least.

Reviewed-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 14 08:40:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 08:40:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984070.1370231 (Exim 4.92)
	(envelope-from )
	id 1uF7f5-0004og-Ki; Wed, 14 May 2025 08:40:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984070.1370231; Wed, 14 May 2025 08:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uF7f5-0004oZ-Gr; Wed, 14 May 2025 08:40:23 +0000
Received: by outflank-mailman (input) for mailman id 984070;
 Wed, 14 May 2025 08:40:21 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uF7f3-0004oS-LT
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 08:40:21 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uF7f3-008ICd-0a;
 Wed, 14 May 2025 08:40:20 +0000
Received: from [2a02:8012:3a1:0:51a6:3d91:4273:769]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uF7f2-00H2xd-1D;
 Wed, 14 May 2025 08:40: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=8E3vtllW2E08wNN0soZYmkPmUal69SPq7QJ97EQJxhQ=; b=BLn6VnE9M6xMchFtfEgC6qSMHA
	Yrl5VvGPVrv/KaoHP1UOmAXBiIwkh9HwG0K6bjtze7reoMDnQFB2H/tmrCEFqCJmNmkr3y2S9G6eM
	PCs8ie/kKjTwNuVvpEjYOB0+/oYkgZ3/NCA2k4iVFYBi9ZsN99ufqdC+5+PvkW0iouTE=;
Message-ID: <1e56c7e8-5302-4280-a48d-d1e958eeadc9@xen.org>
Date: Wed, 14 May 2025 09:40:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/6] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-4-luca.fancellu@arm.com>
From: Julien Grall 
In-Reply-To: <20250513084532.4059388-4-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Luca,

On 13/05/2025 09:45, Luca Fancellu wrote:
> Provide some data structure in the C world to track the MPU
> status, these structures will be filled at boot by the assembly
> early code with the boot MPU regions and afterwards they will be
> used at runtime.
> 
> Provide methods to update a bitmap created with DECLARE_BITMAP
> from the assembly code for both Arm32 and Arm64.
> 
> Modify Arm64 assembly boot code to reset any unused MPU region,
> initialise 'max_mpu_regions' with the number of supported MPU
> regions and modify the common asm macro 'prepare_xen_region' to
> load into xen_mpumap the MPU status and set/clear the bitmap
> 'xen_mpumap_mask' used to track the enabled regions.
> 
> Provide a stub implementation for the pr_t type and few asm
> macro for the Arm32 to prevent compilation break, they will
> be implemented later.
> 
> Signed-off-by: Luca Fancellu 
> ---
> v5 changes:
>   - changed variable name from 'max_xen_mpumap' to 'max_mpu_regions'
>   - code style fixes
>   - reverted back changes about parameter name of prepare_xen_region
>   - optimised address computation for xen_mpumap entries
>   - modified MAX_MPU_REGION_NR
> v4 changes:
>   - new patch
> ---
>   xen/arch/arm/arm64/mpu/head.S            | 13 +++++
>   xen/arch/arm/include/asm/arm32/mpu.h     | 25 +++++++++
>   xen/arch/arm/include/asm/bitmap-op.inc   | 67 ++++++++++++++++++++++++
>   xen/arch/arm/include/asm/mpu.h           |  5 ++
>   xen/arch/arm/include/asm/mpu/mm.h        |  7 +++
>   xen/arch/arm/include/asm/mpu/regions.inc | 49 +++++++++++++++++
>   xen/arch/arm/mpu/mm.c                    | 16 ++++++
>   7 files changed, 182 insertions(+)
>   create mode 100644 xen/arch/arm/include/asm/arm32/mpu.h
>   create mode 100644 xen/arch/arm/include/asm/bitmap-op.inc
> 
> diff --git a/xen/arch/arm/arm64/mpu/head.S b/xen/arch/arm/arm64/mpu/head.S
> index 6d336cafbbaf..59ddc46526eb 100644
> --- a/xen/arch/arm/arm64/mpu/head.S
> +++ b/xen/arch/arm/arm64/mpu/head.S
> @@ -40,6 +40,9 @@ FUNC(enable_boot_cpu_mm)
>       mrs   x5, MPUIR_EL2
>       and   x5, x5, #NUM_MPU_REGIONS_MASK
>   
> +    ldr   x0, =max_mpu_regions
> +    strb  w5, [x0]

Below you are handling cache invalidation when writing to the bitmap. 
But you don't do one here. Is this just an overlook?

> +
>       /* x0: region sel */
>       mov   x0, xzr
>       /* Xen text section. */
> @@ -74,6 +77,16 @@ FUNC(enable_boot_cpu_mm)
>       prepare_xen_region x0, x1, x2, x3, x4, x5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
>   #endif
>   
> +zero_mpu:
> +    /* Reset remaining MPU regions */
> +    cmp   x0, x5
> +    beq   out_zero_mpu
> +    mov   x1, #0
> +    mov   x2, #1
> +    prepare_xen_region x0, x1, x2, x3, x4, x5, attr_prlar=REGION_DISABLED_PRLAR
> +    b     zero_mpu
> +
> +out_zero_mpu:
>       b    enable_mpu
>       ret
>   END(enable_boot_cpu_mm)
> diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
> new file mode 100644
> index 000000000000..1bdae4c309dc
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/arm32/mpu.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __ARM_ARM32_MPU_H__
> +#define __ARM_ARM32_MPU_H__
> +
> +#ifndef __ASSEMBLY__
> +
> +/* MPU Protection Region */
> +typedef struct {
> +    uint32_t prbar;
> +    uint32_t prlar;
> +} pr_t;
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* __ARM_ARM32_MPU_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/arm/include/asm/bitmap-op.inc b/xen/arch/arm/include/asm/bitmap-op.inc
> new file mode 100644
> index 000000000000..ea7c8abbf6f0
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/bitmap-op.inc
> @@ -0,0 +1,67 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +/*
> + * Sets a bit in a bitmap declared by DECLARE_BITMAP, symbol name passed through
> + * bitmap_symbol.
> + *
> + * bitmap_set_bit:      symbol of the bitmap declared by DECLARE_BITMAP
> + * bit:                 bit number to be set in the bitmap
> + * tmp1-tmp4:           temporary registers used for the computation
> + *
> + * Preserves bit.
> + * Output:
> + *  tmp1: Address of the word containing the changed bit.

If the register is used for output, then I think it needs a better name.
But looking at the code, it is not entirely clear how the output will be 
used.

> + * Clobbers: tmp1, tmp2, tmp3, tmp4.
> + */
> +.macro bitmap_set_bit bitmap_symbol, bit, tmp1, tmp2, tmp3, tmp4
 > +    adr_l   \tmp1, \bitmap_symbol> +    mov     \tmp2, 
#(BYTES_PER_LONG - 1)
> +    mvn     \tmp2, \tmp2
> +    lsr     \tmp3, \bit, #3
> +    and     \tmp2, \tmp3, \tmp2
> +    add     \tmp1, \tmp1, \tmp2                 /* bitmap_symbol + (bit/BITS_PER_LONG)*BYTES_PER_LONG */

Style: missing some spaces.

But is the comment explaining the logic above? If so, I think I would 
put it right at the beginning to make easier to understand the logic. I 
would also consider to split in smaller comments on each line e.g.:

* ... = ... + ...

> +    and     \tmp2, \bit, #(BITS_PER_LONG - 1)   /* bit offset inside word */
> +
> +    ldr     \tmp3, [\tmp1]
> +    mov     \tmp4, #1
> +    lsl     \tmp4, \tmp4, \tmp2                 /* (1 << offset) */
> +    orr     \tmp3, \tmp3, \tmp4                 /* set the bit */
> +    str     \tmp3, [\tmp1]
> +.endm
> +
> +/*
> + * Clears a bit in a bitmap declared by DECLARE_BITMAP, symbol name passed
> + * through bitmap_symbol.
> + *
> + * bitmap_set_bit:      symbol of the bitmap declared by DECLARE_BITMAP
> + * bit:                 bit number to be set in the bitmap
> + * tmp1-tmp4:           temporary registers used for the computation
> + *
> + * Preserves bit.
> + * Output:
> + *  tmp1: Address of the word containing the changed bit.
> + * Clobbers: tmp1, tmp2, tmp3, tmp4.
> + */
> +.macro bitmap_clear_bit bitmap_symbol, bit, tmp1, tmp2, tmp3, tmp4
> +    adr_l   \tmp1, \bitmap_symbol
> +    mov     \tmp2, #(BYTES_PER_LONG - 1)
> +    mvn     \tmp2, \tmp2
> +    lsr     \tmp3, \bit, #3
> +    and     \tmp2, \tmp3, \tmp2
> +    add     \tmp1, \tmp1, \tmp2                 /* bitmap_symbol + (bit/BITS_PER_LONG)*BYTES_PER_LONG */
> +    and     \tmp2, \bit, #(BITS_PER_LONG - 1)   /* bit offset inside word */
> +
> +    ldr     \tmp3, [\tmp1]
> +    mov     \tmp4, #1
> +    lsl     \tmp4, \tmp4, \tmp2                 /* (1 << offset) */
> +    mvn     \tmp4, \tmp4                        /* ~(1 << offset) */
> +    and     \tmp3, \tmp3, \tmp4                 /* clear the bit */
> +    str     \tmp3, [\tmp1]
> +.endm
> +
> +/*
> + * Local variables:
> + * mode: ASM
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
> index bb83f5a5f580..fb93b8b19d24 100644
> --- a/xen/arch/arm/include/asm/mpu.h
> +++ b/xen/arch/arm/include/asm/mpu.h
> @@ -8,6 +8,10 @@
>   
>   #if defined(CONFIG_ARM_64)
>   # include 
> +#elif defined(CONFIG_ARM_32)
> +# include 
> +#else
> +# error "unknown ARM variant"
>   #endif
>   
>   #define MPU_REGION_SHIFT  6
> @@ -17,6 +21,7 @@
>   #define NUM_MPU_REGIONS_SHIFT   8
>   #define NUM_MPU_REGIONS         (_AC(1, UL) << NUM_MPU_REGIONS_SHIFT)
>   #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
> +#define MAX_MPU_REGION_NR       NUM_MPU_REGIONS_MASK
>   
>   #endif /* __ARM_MPU_H__ */
>   
> diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
> index bfd840fa5d31..409b4dd53dc6 100644
> --- a/xen/arch/arm/include/asm/mpu/mm.h
> +++ b/xen/arch/arm/include/asm/mpu/mm.h
> @@ -8,9 +8,16 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   extern struct page_info *frame_table;
>   
> +extern uint8_t max_mpu_regions;
> +
> +extern DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR);
> +
> +extern pr_t xen_mpumap[MAX_MPU_REGION_NR];
> +
>   #define virt_to_maddr(va) ((paddr_t)((vaddr_t)(va) & PADDR_MASK))
>   
>   #ifdef CONFIG_ARM_32
> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
> index 47868a152662..ba38213ffff1 100644
> --- a/xen/arch/arm/include/asm/mpu/regions.inc
> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
> @@ -1,14 +1,42 @@
>   /* SPDX-License-Identifier: GPL-2.0-only */
>   
> +#include 
>   #include 
>   #include 
>   
>   /* Backgroud region enable/disable */
>   #define SCTLR_ELx_BR    BIT(17, UL)
>   
> +#define REGION_DISABLED_PRLAR   0x00    /* NS=0 ATTR=000 EN=0 */
>   #define REGION_NORMAL_PRLAR     0x0f    /* NS=0 ATTR=111 EN=1 */
>   #define REGION_DEVICE_PRLAR     0x09    /* NS=0 ATTR=100 EN=1 */
>   
> +#define PRLAR_ELx_EN            0x1
> +
> +#ifdef CONFIG_ARM_64
> +#define XEN_MPUMAP_ENTRY_SHIFT  0x4     /* 16 byte structure */
> +
> +.macro store_pair reg1, reg2, dst
> +    stp \reg1, \reg2, [\dst]
> +.endm
> +
> +.macro invalidate_dcache_one reg
> +    dc ivac, \reg
> +.endm
> +
> +#else
> +#define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
> +
> +.macro store_pair reg1, reg2, dst
> +    nop

Can we use a function that will trigger a fault? So we will remember 
this will needed to be updated. Maybe re-use the BUG_OPCODE?

> +.endm
> +
> +.macro invalidate_dcache_one reg
> +    nop

Same here.

> +.endm
 > +> +#endif
> +
>   /*
>    * Macro to prepare and set a EL2 MPU memory region.
>    * We will also create an according MPU memory region entry, which
> @@ -56,6 +84,27 @@
>       isb
>       WRITE_SYSREG_ASM(\prbar, PRBAR_EL2)
>       WRITE_SYSREG_ASM(\prlar, PRLAR_EL2)
> +
> +    /* Load pair into xen_mpumap and invalidate cache */

To confirm my understanding, xen_mpumap is part of the loaded binary. So 
we expect the bootloader to have clean the cache for us. Therefore, we
only need to invalidate the entries afterwards. Is it correct?

> +    adr_l \base, xen_mpumap
> +    add   \base, \base, \sel, LSL #XEN_MPUMAP_ENTRY_SHIFT
> +    store_pair \prbar, \prlar, \base

I think you want a comment on top of pr_t to mention the structure
will not changed and

> +    invalidate_dcache_one \base

This will invalidate a single line in the data cache. The size depends 
on the HW, but typically it will be 64 - 128 bytes. Do we have any check
that will confirm the data will fit in an cache line?

> +
> +    /* Set/clear xen_mpumap_mask bitmap */
> +    tst   \prlar, #PRLAR_ELx_EN
> +    bne   2f
> +    /* Region is disabled, clear the bit in the bitmap */
> +    bitmap_clear_bit xen_mpumap_mask, \sel, \base, \limit, \prbar, \prlar
> +    b     3f
> +
> +2:
> +    /* Region is enabled, set the bit in the bitmap */
> +    bitmap_set_bit xen_mpumap_mask, \sel, \base, \limit, \prbar, \prlar
> +
> +3:
> +    invalidate_dcache_one \base

You want to a comment to explain what this invalidate does. AFAICT, this 
is for the bitmap. But given the bitmap will be typically small, 
wouldn't it better to do it in one go at the end?

Same comment here.

> +
>       dsb   sy
>       isb
>   
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index 07c8959f4ee9..ee035a54b942 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -7,9 +7,25 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   struct page_info *frame_table;
>   
> +/* Maximum number of supported MPU memory regions by the EL2 MPU. */
> +uint8_t __ro_after_init max_mpu_regions;
> +
> +/*
> + * Bitmap xen_mpumap_mask is to record the usage of EL2 MPU memory regions.
> + * Bit 0 represents MPU memory region 0, bit 1 represents MPU memory
> + * region 1, ..., and so on.
> + * If a MPU memory region gets enabled, set the according bit to 1.
> + */
> +DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
> +    __section(".data.page_aligned");

Why does this need to be page_aligned?

> +
> +/* EL2 Xen MPU memory region mapping table. */
> +pr_t __section(".data.page_aligned") xen_mpumap[MAX_MPU_REGION_NR];

I guess for this one this is mandated by the HW?

> +
>   static void __init __maybe_unused build_assertions(void)
>   {
>       /*

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 08:44:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 08:44:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984085.1370248 (Exim 4.92)
	(envelope-from )
	id 1uF7jI-0005pM-8N; Wed, 14 May 2025 08:44:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984085.1370248; Wed, 14 May 2025 08:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uF7jI-0005pF-5q; Wed, 14 May 2025 08:44:44 +0000
Received: by outflank-mailman (input) for mailman id 984085;
 Wed, 14 May 2025 08:44:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF7jG-0005p9-Ma
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 08:44:42 +0000
Received: from fhigh-b1-smtp.messagingengine.com
 (fhigh-b1-smtp.messagingengine.com [202.12.124.152])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ac249de2-309f-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 10:44:40 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.stl.internal (Postfix) with ESMTP id CEA4E25401A7;
 Wed, 14 May 2025 04:44:38 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Wed, 14 May 2025 04:44:38 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 14 May 2025 04:44: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" 
X-Inumbo-ID: ac249de2-309f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1747212278;
	 x=1747298678; bh=PixPq2A5C5ojjRkw3+Yp0ohQCFr6NmwRCmKaQG1C4t4=; b=
	Y7kWdbnOmCUDl9w+eKe/WPf9S1XHDHzKGkX1DWKroGV4NXu4IZAFvdt2zikYGQDB
	JyGcSk/LJDDe3qIfAWh3Ak7r0wppsO0+UfY80hhxxuPBH28nEV7aka7YnkZQnlr/
	Lp7IP5XhG/ShdzGiWYvSgyPRtpTNNIwgCVlH7vTRlE17LVxpg0SFxIGr1wX6Jf7G
	SHeaAxq+vVEQ2Bycz+PGUbTuXmR8p794nljaXejfE0J9PU6rHLnCEHvkpoflYQBB
	yuWCV3yeW85UnDs5jhZss6EBw8cAuaVAPLb3diZ543x7CfLgogQX8GODzWoNlD2/
	AGStHdLTDBAPArXteZqrIg==
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=fm3; t=
	1747212278; x=1747298678; bh=PixPq2A5C5ojjRkw3+Yp0ohQCFr6NmwRCmK
	aQG1C4t4=; b=l5zala0AgaUiCdz4WSLEgUClJLbtinwpngAljiOmFSYGV+b2e34
	u/OhltWvkIuPh0mEUekSA+6EdvYOueyId3AKBv3NmTb7hYIlx4YZ4k0swbmn2Dt8
	ea7mWkvBZM5k7YkmhUfSQU6vIC/Pz3wMQwnJcU3PnlWkTUjpo0hX0eZdvUobDlw/
	aoQEnYZSko7XYC2+eNX3hh6rs04tbk1iCwT0DdX5VYhtHkDMVu1HGpMyICyemYPO
	LTn3Vn7x1H4R5L652l77Jfal0t7yrAkuUqoC7POKX3WDq/DRuHFJhbFvJTJ2ElJE
	3IMWldeTjKE6QG4fDa09cR/n022HkaBqglQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdeiheegucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettd
    dvgeeuteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf
    rhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
    dpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgs
    vghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopehrohhgvghrrdhprghusegtih
    htrhhigidrtghomhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhr
    ihigrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprh
    hojhgvtghtrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 14 May 2025 10:44:34 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Andrew Cooper ,
	xen-devel 
Subject: Re: Assertion 'desc->arch.creator_domid == DOMID_INVALID' failed
Message-ID: 
References: 
 <70e5eeee-f1fa-41b4-91eb-450edc0bcaca@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="4VF5uyez0qQDMClv"
Content-Disposition: inline
In-Reply-To: <70e5eeee-f1fa-41b4-91eb-450edc0bcaca@suse.com>


--4VF5uyez0qQDMClv
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 May 2025 10:44:34 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Jan Beulich 
Cc: Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Andrew Cooper ,
	xen-devel 
Subject: Re: Assertion 'desc->arch.creator_domid == DOMID_INVALID' failed

On Wed, May 14, 2025 at 09:09:08AM +0200, Jan Beulich wrote:
> On 13.05.2025 21:20, Marek Marczykowski-G=C3=B3recki wrote:
> > Hi,
> >=20
> > When debugging CI job on Linus' master branch, I added "console=3Dvga v=
ga=3D,keep" and got PV dom0 crash Xen with:
> >=20
> > (XEN) [   40.870435] Assertion 'desc->arch.creator_domid =3D=3D DOMID_I=
NVALID' failed at arch/x86/irq.c:294
> > (XEN) [   40.886925] ----[ Xen-4.21-unstable  x86_64  debug=3Dy ubsan=
=3Dy  Not tainted ]----
> > (XEN) [   40.903356] CPU:    10
> > (XEN) [   40.919824] RIP:    e008:[] create_irq+0x272=
/0x339
> > (XEN) [   40.936267] RFLAGS: 0000000000010297   CONTEXT: hypervisor (d0=
v13)
> > (XEN) [   40.952709] rax: 00000000fffffff4   rbx: ffff830498007c00   rc=
x: 0000000000001899
>=20
> There looks to be a -ENOMEM in %rax, so ...
>=20
> > (XEN) [   40.969147] rdx: ffff830498007c5e   rsi: 0000000000000002   rd=
i: ffff83049830e398
> > (XEN) [   40.985892] rbp: ffff830498307d18   rsp: ffff830498307ce8   r8=
:  0000000000000000
> > (XEN) [   41.003093] r9:  0000000000000000   r10: 0000000000000000   r1=
1: 0000000000000000
> > (XEN) [   41.020279] r12: 00000000fffffff4   r13: 000000000000007c   r1=
4: ffffffffffffffff
> > (XEN) [   41.037489] r15: 000000000000007c   cr0: 0000000080050033   cr=
4: 0000000000b526e0
> > (XEN) [   41.054699] cr3: 0000000492c34000   cr2: ffff8881001603f0
> > (XEN) [   41.071904] fsb: 0000000000000000   gsb: ffff8882365ac000   gs=
s: 0000000000000000
> > (XEN) [   41.089116] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e0=
10   cs: e008
> > (XEN) [   41.106320] Xen code around  (create_irq+0x2=
72/0x339):
> > (XEN) [   41.123521]  3f d9 ff e9 cc fe ff ff <0f> 0b 48 8d 3d 5a a0 29=
 00 e8 f4 3d d9 ff c6 43
> > (XEN) [   41.140739] Xen stack trace from rsp=3Dffff830498307ce8:
> > (XEN) [   41.157931]    000000ff00000001 ffff830497faa000 ffff830498307=
e00 00000000ffffffff
> > (XEN) [   41.175132]    0000000000010000 ffff830497faa160 ffff830498307=
d70 ffff82d0405a6f85
> > (XEN) [   41.192351]    00000000000002a0 ffff830498307e24 0000000000000=
200 00000000ffffffff
> > (XEN) [   41.209551]    ffff830497faa000 0000000000000000 ffff830497faa=
168 0000000000010000
> > (XEN) [   41.226753]    ffff830497faa160 ffff830498307de0 ffff82d0405c9=
ea6 5f24a0ddbbeda194
> > (XEN) [   41.244062]    ffff830498307e10 0000000000000000 0000000000000=
001 ffff830498307e00
> > (XEN) [   41.261387]    ffff830498307e24 ffff830498307e20 ffff830497faa=
000 ffff830498307ef8
> > (XEN) [   41.278730]    ffff830497faa000 ffff830497f5a000 ffffc9004002b=
a78 ffff830498307e68
> > (XEN) [   41.296052]    ffff82d0405cbd4f ffff82d04053fc3e ffffc9004002b=
a78 00000000000000a0
> > (XEN) [   41.313381]    00a0fb0000000001 0000000000000000 0000000000007=
ff0 ffffffffffffffff
> > (XEN) [   41.330708]    000000a000000000 0000000000000000 0000000000000=
000 ffff830498307ef8
> > (XEN) [   41.348026]    ffff830497f5a000 0000000000000021 0000000000000=
000 ffffc9004002ba78
> > (XEN) [   41.365357]    ffff830498307ee8 ffff82d0405427db ffff8881d6961=
b40 0000000000000001
> > (XEN) [   41.382680]    000000a000000000 000000000000000d 0000000000000=
000 ffff830498307ee8
> > (XEN) [   41.400003]    ffff82d0405e7bc2 ffff830497f5a000 0000000000000=
000 ffff830497f5a000
> > (XEN) [   41.417343]    0000000000000000 0000000000000000 ffff830498307=
fff 0000000000000000
> > (XEN) [   41.434674]    00007cfb67cf80e7 ffff82d0402012d3 ffff8881d6961=
b40 ffff888100ef30c0
> > (XEN) [   41.452010]    0000000000000001 0000000000000005 0000000000000=
000 ffff888100ef3000
> > (XEN) [   41.469342]    0000000000000202 0000000000000001 0000000000007=
ff0 ffff8881d6961b40
> > (XEN) [   41.486681]    0000000000000021 ffffffff8229d355 000000a000000=
000 ffffc9004002ba78
> > (XEN) [   41.504015] Xen call trace:
> > (XEN) [   41.521314]    [] R create_irq+0x272/0x339
>=20
> ... I'd expect the function calling init_one_irq_desc() to have caused th=
is.
> In which case, yes, the assertion is certainly valid to trigger (as it's
> arch_init_one_irq_desc() which sets the field to the expected value, yet
> that won't happen if one of the involved allocations fails). I'll make a
> patch, but this raises the question of how you're running Xen, when
> seemingly small allocations like the ones involved here end up failing.

That's weird, there should be plenty of memory. Xen is started with
dom0_mem=3D4G and it's a 16GB system.

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--4VF5uyez0qQDMClv
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgkV/MACgkQ24/THMrX
1ywF1wf8CMvCc6ajaKmjbmjMfgVz0xDXTJSoVFMQZJq90shTFLGmeE94tEG3c/yA
ap5zcLd3sSI28igXS0ltPkx+JpKOjjenIU9w0C/M9ofdnmDw5jTpe8/cPjIbYFOi
DuyGZKYYkrhLwBZ0cjZFKQ5pafcPqFqZ7iEtPFsKiwexPi1UWOxUS2njj+SCne/s
9VSs92tMvnq5Y2sle9AMkJosKjAevpXndsFko9H0QUpP8TpPPeMdcEO2Z0/1sCoH
ui/PCTxvszEHIDuNqhAooS6iwJVSqJmevDi+hbdQbxuwdANTDLekPeOcKR9QSnKN
C6em0TSYS0P1jaz+UfGiZgDJVqreDQ==
=Gcsr
-----END PGP SIGNATURE-----

--4VF5uyez0qQDMClv--


From xen-devel-bounces@lists.xenproject.org Wed May 14 08:55:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 08:55:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984095.1370259 (Exim 4.92)
	(envelope-from )
	id 1uF7tY-0007iE-6M; Wed, 14 May 2025 08:55:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984095.1370259; Wed, 14 May 2025 08: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 1uF7tY-0007i7-2m; Wed, 14 May 2025 08:55:20 +0000
Received: by outflank-mailman (input) for mailman id 984095;
 Wed, 14 May 2025 08:55:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF7tX-0007i1-5q
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 08:55:19 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 28239835-30a1-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 10:55:17 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ad238c68b35so827603466b.1
 for ; Wed, 14 May 2025 01:55:17 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad24085b44fsm649720766b.149.2025.05.14.01.55.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 01:55: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" 
X-Inumbo-ID: 28239835-30a1-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747212916; x=1747817716; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=1gkk0wjy3CX7r6hFn26WQaLAfJ0MqdkdVFt32jCHUD0=;
        b=YhuT2YrsU/vvjxGTgaIpOzWUX/02IOwCiQ+x1uJIFsfyINhcuGfAVuijMoBrGKjBGz
         X/WblRRzsz3i/OS88K9fmd7HBDb8Hqxa2cWe3DJxHhr6EgbASS/9LeylEh8mB5rlhyAY
         BIuJawU6c6aOS8b15gOVHJKI82dtaCEsNsEUM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747212916; x=1747817716;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=1gkk0wjy3CX7r6hFn26WQaLAfJ0MqdkdVFt32jCHUD0=;
        b=e+ohWzpR16aR15s3rHGE3DAC6oZ9o3dIjt7kksks+l21M3vPP2pbpkfstuV+9N/OCX
         liWH1eII8aIFmBYlXWpTlt8jdjq6+O2Jo6v6zDJxnFiCd5vLuijP6WvyDkMwvTZGQ1Gv
         B0FJ7lK3rmOJVwIVGD6HS9eXK0F7cK8rte80Y58L2vRNg1xG2HFN/UDjRdb8l98dGCBH
         jRv1x1S8jZducJDli/GFx0GykmMMPf3a5nAU1XCr3ZUHSsvvHi1uoNdrv87mI47G9c9o
         tWV87IOWMl84A0XwuwN/V5W3zVsCCmyOnsDECkvSwKGWvbFn0CIjpqHV2oMoYETSdDfS
         Wl7A==
X-Forwarded-Encrypted: i=1; AJvYcCXu48TsUWXRD1KN+ZW7aB+WgTTnbkbie29xRWtihLe3vS6MkXDEQiF9Wg2Tp6/g5yZ1ckleVNymhEs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxUzra/p0aqF7W1XELJwyDrVNW43pjlQGRdMDXthieB1ehTZ4kT
	gLSKC4F6W6tKgINwkrWOZymai7X8BDIKJBTbood9ZACcaU9Q/s28qXhb9IJiz5I=
X-Gm-Gg: ASbGncsKl7Q++WjJSki/o1kpFzpFv+D2qkG33V22mMB2p0g/rcLZLlTPHd2tTwp9GDD
	Y/JTN/vnYWXezMoBjrNSv4WxTVU3TYpAtvtEB6hdM2VdruWzkIU0+i+ZF7Vz45RW96w0ZBB2WwO
	aHF8c/kYt7TZcevlh6q8mqOtvO6RwvZyM3dgmfl/6b/2NNIDBtSoffRWQ+m4o1mctF2OgKP73PX
	J0OhMlO++Mhg/a0FblfhxK0Hrek1Hp1KXcJlrpdWI0qwf82UPDuet+fzrdPOdkOcmZtbHkq4eky
	pgR8V/ZlbJVEGa0q9gxktt1ksnS79peicYLA2/eO/WTKDEUGXQLX/05oeBwx0A==
X-Google-Smtp-Source: AGHT+IFUfCb1uSxL8jjqyrM6Qr8rR2Eeu0NbVFgp5i6RBkqRSCBZzSrjHkBo6Et1CgE8i/cGiqMQJg==
X-Received: by 2002:a17:907:7d90:b0:ad2:4a32:f173 with SMTP id a640c23a62f3a-ad4f717dc54mr251809566b.14.1747212916451;
        Wed, 14 May 2025 01:55:16 -0700 (PDT)
Date: Wed, 14 May 2025 10:55:15 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
Cc: Jan Beulich ,
	Andrew Cooper ,
	xen-devel 
Subject: Re: Assertion 'desc->arch.creator_domid == DOMID_INVALID' failed
Message-ID: 
References: 
 <70e5eeee-f1fa-41b4-91eb-450edc0bcaca@suse.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 14, 2025 at 10:44:34AM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, May 14, 2025 at 09:09:08AM +0200, Jan Beulich wrote:
> > On 13.05.2025 21:20, Marek Marczykowski-Górecki wrote:
> > > Hi,
> > > 
> > > When debugging CI job on Linus' master branch, I added "console=vga vga=,keep" and got PV dom0 crash Xen with:
> > > 
> > > (XEN) [   40.870435] Assertion 'desc->arch.creator_domid == DOMID_INVALID' failed at arch/x86/irq.c:294
> > > (XEN) [   40.886925] ----[ Xen-4.21-unstable  x86_64  debug=y ubsan=y  Not tainted ]----
> > > (XEN) [   40.903356] CPU:    10
> > > (XEN) [   40.919824] RIP:    e008:[] create_irq+0x272/0x339
> > > (XEN) [   40.936267] RFLAGS: 0000000000010297   CONTEXT: hypervisor (d0v13)
> > > (XEN) [   40.952709] rax: 00000000fffffff4   rbx: ffff830498007c00   rcx: 0000000000001899
> > 
> > There looks to be a -ENOMEM in %rax, so ...
> > 
> > > (XEN) [   40.969147] rdx: ffff830498007c5e   rsi: 0000000000000002   rdi: ffff83049830e398
> > > (XEN) [   40.985892] rbp: ffff830498307d18   rsp: ffff830498307ce8   r8:  0000000000000000
> > > (XEN) [   41.003093] r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> > > (XEN) [   41.020279] r12: 00000000fffffff4   r13: 000000000000007c   r14: ffffffffffffffff
> > > (XEN) [   41.037489] r15: 000000000000007c   cr0: 0000000080050033   cr4: 0000000000b526e0
> > > (XEN) [   41.054699] cr3: 0000000492c34000   cr2: ffff8881001603f0
> > > (XEN) [   41.071904] fsb: 0000000000000000   gsb: ffff8882365ac000   gss: 0000000000000000
> > > (XEN) [   41.089116] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> > > (XEN) [   41.106320] Xen code around  (create_irq+0x272/0x339):
> > > (XEN) [   41.123521]  3f d9 ff e9 cc fe ff ff <0f> 0b 48 8d 3d 5a a0 29 00 e8 f4 3d d9 ff c6 43
> > > (XEN) [   41.140739] Xen stack trace from rsp=ffff830498307ce8:
> > > (XEN) [   41.157931]    000000ff00000001 ffff830497faa000 ffff830498307e00 00000000ffffffff
> > > (XEN) [   41.175132]    0000000000010000 ffff830497faa160 ffff830498307d70 ffff82d0405a6f85
> > > (XEN) [   41.192351]    00000000000002a0 ffff830498307e24 0000000000000200 00000000ffffffff
> > > (XEN) [   41.209551]    ffff830497faa000 0000000000000000 ffff830497faa168 0000000000010000
> > > (XEN) [   41.226753]    ffff830497faa160 ffff830498307de0 ffff82d0405c9ea6 5f24a0ddbbeda194
> > > (XEN) [   41.244062]    ffff830498307e10 0000000000000000 0000000000000001 ffff830498307e00
> > > (XEN) [   41.261387]    ffff830498307e24 ffff830498307e20 ffff830497faa000 ffff830498307ef8
> > > (XEN) [   41.278730]    ffff830497faa000 ffff830497f5a000 ffffc9004002ba78 ffff830498307e68
> > > (XEN) [   41.296052]    ffff82d0405cbd4f ffff82d04053fc3e ffffc9004002ba78 00000000000000a0
> > > (XEN) [   41.313381]    00a0fb0000000001 0000000000000000 0000000000007ff0 ffffffffffffffff
> > > (XEN) [   41.330708]    000000a000000000 0000000000000000 0000000000000000 ffff830498307ef8
> > > (XEN) [   41.348026]    ffff830497f5a000 0000000000000021 0000000000000000 ffffc9004002ba78
> > > (XEN) [   41.365357]    ffff830498307ee8 ffff82d0405427db ffff8881d6961b40 0000000000000001
> > > (XEN) [   41.382680]    000000a000000000 000000000000000d 0000000000000000 ffff830498307ee8
> > > (XEN) [   41.400003]    ffff82d0405e7bc2 ffff830497f5a000 0000000000000000 ffff830497f5a000
> > > (XEN) [   41.417343]    0000000000000000 0000000000000000 ffff830498307fff 0000000000000000
> > > (XEN) [   41.434674]    00007cfb67cf80e7 ffff82d0402012d3 ffff8881d6961b40 ffff888100ef30c0
> > > (XEN) [   41.452010]    0000000000000001 0000000000000005 0000000000000000 ffff888100ef3000
> > > (XEN) [   41.469342]    0000000000000202 0000000000000001 0000000000007ff0 ffff8881d6961b40
> > > (XEN) [   41.486681]    0000000000000021 ffffffff8229d355 000000a000000000 ffffc9004002ba78
> > > (XEN) [   41.504015] Xen call trace:
> > > (XEN) [   41.521314]    [] R create_irq+0x272/0x339
> > 
> > ... I'd expect the function calling init_one_irq_desc() to have caused this.
> > In which case, yes, the assertion is certainly valid to trigger (as it's
> > arch_init_one_irq_desc() which sets the field to the expected value, yet
> > that won't happen if one of the involved allocations fails). I'll make a
> > patch, but this raises the question of how you're running Xen, when
> > seemingly small allocations like the ones involved here end up failing.
> 
> That's weird, there should be plenty of memory. Xen is started with
> dom0_mem=4G and it's a 16GB system.

I wouldn't be surprised that you are impacted by:

https://lore.kernel.org/xen-devel/20250514080427.28129-1-roger.pau@citrix.com/

If the kernel is built without CONFIG_XEN_UNPOPULATED_ALLOC.  Sorry,
that was my fault.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 14 09:21:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 09:21:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984111.1370285 (Exim 4.92)
	(envelope-from )
	id 1uF8IV-0003Xy-8A; Wed, 14 May 2025 09:21:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984111.1370285; Wed, 14 May 2025 09: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 1uF8IV-0003Xr-5K; Wed, 14 May 2025 09:21:07 +0000
Received: by outflank-mailman (input) for mailman id 984111;
 Wed, 14 May 2025 09:21:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF8IT-0003Xl-UG
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 09:21:05 +0000
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com
 [2607:f8b0:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bfae7d4b-30a4-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 11:21:00 +0200 (CEST)
Received: by mail-pf1-x42f.google.com with SMTP id
 d2e1a72fcca58-72d3b48d2ffso6606738b3a.2
 for ; Wed, 14 May 2025 02:21:00 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-22fc753fe13sm94696225ad.14.2025.05.14.02.20.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 02: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" 
X-Inumbo-ID: bfae7d4b-30a4-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747214459; x=1747819259; 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;
        bh=ibOaHY58habuMEQUy1e1j8bMM1DI8FzR+feZU4NgPsg=;
        b=L0wct/wuZboJK4OJKME3LKHSYPZ/aznuaVfCStHjEdIrUSD8SnTQrvHhzVqt4kBuJd
         qFkObVUWWzzHSj4EegnnbK7HhDkaFlNg0elw/jKzzHtyAFnHiMtup2DSmKQTei01NVHl
         0AXZ3esx5+55wkm8xif399nnwC2+B55Ta71mo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747214459; x=1747819259;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ibOaHY58habuMEQUy1e1j8bMM1DI8FzR+feZU4NgPsg=;
        b=F6OVF+vb6JpE8wH65k3KnuWPPkOEEX0GraLab9TxMMYk86Bv+/LZxilPqCrCVbVC6r
         FuZhmrNElItgsdtyEMBEDjyEfwHaIr4zin9vUIQCIQx1YrM7yNbmiHIjBLZVGltDCKP8
         eXMoqtC5xcc3wKeGk9y/6W7t7TZwK2WMuE0L5P2FKVMZYeRLkizyr/cgErmNd0yjByD3
         MmyohULWb9KJItui/y8c6VUiWRhZ0RxABpe+EgKN6hcIPKj9j2KpuIivLoAX5p5sMjW2
         MHvC/UCv/JsjHICjZQBkl3d8c5gtUx1G+CprMnpF1XkC5V8EulYdCw/Q5VjMqJsg1LWk
         BBaQ==
X-Gm-Message-State: AOJu0YzG3ZVBArq1QH+cj3V/1h02ldQKKEZrWuc+bbdPjfD0mJO16WFQ
	vtFn0Oscq2GJ6qu/pisnSrgwcWcPHMJ5UJD5HET6cJFqoMuAOcCf+XnodE3Dx468aBizKND3GtG
	5
X-Gm-Gg: ASbGnctW81kr1MbHxRWVEHqJY0H/vzBhQCbBpADHblZEOIbQUgpRkhpkhS4MdGiUZKG
	P6dtmVXTQdl841PJDy2F8lTLaGH79QmtMpat3XOf60RSQLDm4GPUMxoFJzWQOVZLbI4bPPexgy3
	1w4EE3Yb6bo/4PvhAWZarl7LvYEzTnbiZmVFE1Anuzsp0/JIG+mN09UHXNptVAG21cLP51L28bF
	+9lvT4xqebMhY9KmutfLKqtLaaiy5iJaEzpoA7N0OVqQwP9TyI51ZkqthSSKzacLS/GGjeh18eS
	6EgYkjDlAV+i7m8pu7rHYJZLdiEzHfD1e5VUfn66rNY9wWKO7H+1vgNlKh0S9u17ihU=
X-Google-Smtp-Source: AGHT+IGSWLVb97SerQP51yUp7nrx2ZnEYwBo9CbV8YH53jj0P/avx90b8Y2UNutxqjPaGH7wgrsK6g==
X-Received: by 2002:a17:903:120c:b0:215:8d49:e2a7 with SMTP id d9443c01a7336-231983e5c25mr35466905ad.50.1747214458567;
        Wed, 14 May 2025 02:20:58 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Cc: jason.andryuk@amd.com,
	Roger Pau Monne ,
	Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko 
Subject: [PATCH] xen: enable XEN_UNPOPULATED_ALLOC as part of xen.config
Date: Wed, 14 May 2025 11:20:36 +0200
Message-ID: <20250514092037.28970-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

PVH dom0 is useless without XEN_UNPOPULATED_ALLOC, as otherwise it will
very likely balloon out all dom0 memory to map foreign and grant pages.

Enable it by default as part of xen.config.  This also requires enabling
MEMORY_HOTREMOVE and ZONE_DEVICE.

Signed-off-by: Roger Pau Monné 
---
 kernel/configs/xen.config | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
index 6878b9a49be8..1875a0a5047a 100644
--- a/kernel/configs/xen.config
+++ b/kernel/configs/xen.config
@@ -13,6 +13,8 @@ CONFIG_SCSI=y
 CONFIG_FB=y
 CONFIG_INPUT_MISC=y
 CONFIG_MEMORY_HOTPLUG=y
+CONFIG_MEMORY_HOTREMOVE=y
+CONFIG_ZONE_DEVICE=y
 CONFIG_TTY=y
 # Technically not required but otherwise produces
 # pretty useless systems starting from allnoconfig
@@ -47,3 +49,4 @@ CONFIG_XEN_GNTDEV=m
 CONFIG_XEN_GRANT_DEV_ALLOC=m
 CONFIG_SWIOTLB_XEN=y
 CONFIG_XEN_PRIVCMD=m
+CONFIG_XEN_UNPOPULATED_ALLOC=y
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Wed May 14 09:40:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 09:40:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984122.1370294 (Exim 4.92)
	(envelope-from )
	id 1uF8b8-0006Pq-M8; Wed, 14 May 2025 09:40:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984122.1370294; Wed, 14 May 2025 09: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 1uF8b8-0006Pj-JZ; Wed, 14 May 2025 09:40:22 +0000
Received: by outflank-mailman (input) for mailman id 984122;
 Wed, 14 May 2025 09:40:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF8b6-0006PZ-TF
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 09:40:21 +0000
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com
 [2a00:1450:4864:20::12c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 732c8f9b-30a7-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 11:40:19 +0200 (CEST)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-54b166fa41bso8478812e87.0
 for ; Wed, 14 May 2025 02:40:19 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-54fc644fa78sm2172536e87.32.2025.05.14.02.40.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 02: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" 
X-Inumbo-ID: 732c8f9b-30a7-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747215619; x=1747820419; darn=lists.xenproject.org;
        h=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;
        bh=aTZv9xz8utWEC72UJb52B2n2tOeCs396jJK9ywvIQTU=;
        b=bD3Azx+rO5Ub3wx6Y7lJEC6N6Vb3bfmrGjrAi82NoxmKTGyUvZtLCsBH+9herRxZqF
         vtrZyvFX+SXI9+RLLF4DSRPaaFoG8bjBfRY/AQMib1R2osAy9igRQEpEZHGI74iuIDem
         ZVWXalj360xlLE6HEHFiFNrokQq4PhceDR+GbrpxGE4R263g1WPctHzYV1NvH+h2lKaW
         gNN6tlK1OrN2/+fPPbMsi0MpZ/lnhDsqo7y01dsX6dTgqCiGX1nbAMRqk4QngVt18AaQ
         hrATf1ubG8kK2y/WcDkUpH01eol5k+lMzdsUXAM/Zgnr/ZtTFM+WHA+xq+n+MXLke1Q1
         k20A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747215619; x=1747820419;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=aTZv9xz8utWEC72UJb52B2n2tOeCs396jJK9ywvIQTU=;
        b=P5C+Yi/b+xyyyQwBRwcGCC8hTbZRhI7Rh5bE0pCr/qnqlq19uAI7bZhgEwFx3qcxSp
         ItXm8g+mPXE3VZ7/1UurZxT4u6CWaGFHdSseJdlP7ZfCCoVbGqxOvv5F6x6sdV6dD2cO
         0XKZFU7vG52T+h+NBMYnjWh4V49G62ddDunMknI31VrRViDgyGTH14f3R01+baiYf7W+
         StHMUl04gU1sG98ArT2AGuuzd5ia6qcNUsjhSgsgDsxcMCpdon9a8eliwroP30M7sGyY
         FuFADSEusry8lZ3xWa0tG0yaReon4hoH1iLzU51C8xVO0XBlbjEk98xJgC2t+h7f4dCI
         fV+g==
X-Gm-Message-State: AOJu0YzWttIMSTmf3U1e/jhrtVLcxJxDh4Gi4AoZztLBKW/JJH0G6dY2
	dZfA7nH0Xu3h+WkGJeob7Rqp86u3bbAdlKF6s/F2wjt86wOB52Iu
X-Gm-Gg: ASbGnct8eBlWag/lP8YKu15rzyGQhCiY4bAnjshNZlSCCzsuVOnpDwyG06gF6RF2tE6
	LyARnfygHxMX5/SHuPNTZcpNh8LsZIRCc3gwzT97wYDZk6RzXnOgwmR5UBoG7tq+m+/d3qpdRTa
	3aIrX+cXWCuYFao+e8uNzKoADGy6nfYAkiBUgWrMLp/Bvrg6H9yLdUk/CfW68EkQexmG0V8KMPb
	bawhUT1+AzyS7FQNyz86zvk8dMwLov9l9Iy0wTmxuT4oDDhpRanYj2ac89wRfaECt/iKhLuYQPm
	dr74130B9NqMB165bgDRhMjC6N8ujwn05Yq/NfZcNLyEyLi3wh1eRmf09epYOPQDc0mVhcojPkC
	/FUE2Q8yzCn4qUJSadIeYS2aA
X-Google-Smtp-Source: AGHT+IF1TaC8qYOKC9g0zpa14eMMbL/vyMMjV5msM/JCJ9yU1+CwhMWi3KSaTKzA6CSm6bLIpwcliQ==
X-Received: by 2002:a05:6512:228e:b0:545:f1d:6f2c with SMTP id 2adb3069b0e04-550d5fa35b5mr1043551e87.18.1747215618935;
        Wed, 14 May 2025 02:40:18 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------uGiua9zkPM0WYozkwo5Ku0Ml"
Message-ID: <3f1ad6d6-a03f-4f3a-85f7-a154f1aa7852@gmail.com>
Date: Wed, 14 May 2025 11:40:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU
 construction
To: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org, Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------uGiua9zkPM0WYozkwo5Ku0Ml
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/14/25 1:58 AM, Stefano Stabellini wrote:
> On Tue, 13 May 2025, Oleksii Kurochko wrote:
>> Refactor construct_domU() to improve architecture separation and reduce
>> reliance on ARM-specific logic in common code:
>> - Drop set_domain_type() from generic code. This function is specific
>>    to ARM and serves no purpose on other architectures like RISC-V,
>>    which lack the arch.type field in kernel_info.
>> - Introduce arch_construct_domU() to encapsulate architecture-specific
>>    DomU construction steps.
>> - Implement arch_construct_domU() for ARM. This includes:
>>    - Setting the domain type for CONFIG_ARM64.
>>    - Handling static memory allocation if xen,static-mem is present in
>>      the device tree.
>>    - Processing static shared memory.
>> - Move call of make_resv_memory_node() to Arm's make_arch_nodes() as
>>    this call is specific to CONFIG_STATIC_SHM which is ARM specific,
>>    at least, now.
>>
>> This cleanup avoids empty stubs on other architectures and moves
>> ARM-specific logic into arch code where it belongs.
>>
>> Also, don't loose  a return value of functions called in
>> Arm's make_arch_nodes().
>>
>> Suggested-by: Michal Orzel
>> Signed-off-by: Oleksii Kurochko
>> ---
>>   xen/arch/arm/dom0less-build.c            | 42 +++++++++++++++++-------
>>   xen/common/device-tree/dom0less-build.c  | 30 ++---------------
>>   xen/include/asm-generic/dom0less-build.h |  3 +-
>>   3 files changed, 36 insertions(+), 39 deletions(-)
>>
>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
>> index a49764f0ad..592173268f 100644
>> --- a/xen/arch/arm/dom0less-build.c
>> +++ b/xen/arch/arm/dom0less-build.c
>> @@ -220,9 +220,14 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
>>   {
>>       int ret;
>>   
>> +    ret = make_resv_memory_node(kinfo, GUEST_ROOT_ADDRESS_CELLS,
>> +                                GUEST_ROOT_SIZE_CELLS);
>> +    if ( ret )
>> +        return ret;
>> +
>>       ret = make_psci_node(kinfo->fdt);
>>       if ( ret )
>> -        return -EINVAL;
>> +        return ret;
>>   
>>       if ( kinfo->arch.vpl011 )
>>       {
>> @@ -230,26 +235,41 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
>>           ret = make_vpl011_uart_node(kinfo);
>>   #endif
>>           if ( ret )
>> -            return -EINVAL;
>> +            return ret;
>>       }
>>   
>>       return 0;
>>   }
>>   
>> -/* TODO: make arch.type generic ? */
>> -#ifdef CONFIG_ARM_64
>> -void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
>> +int __init arch_construct_domU(struct kernel_info *kinfo,
>> +                               const struct dt_device_node *node)
>>   {
>> +    int rc = 0;
>> +    struct domain *d = kinfo->d;
>> +
>> +#ifdef CONFIG_ARM_64
>>       /* type must be set before allocate memory */
>>       d->arch.type = kinfo->arch.type;
>> -}
>> -#else
>> -void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
>> -{
>> -    /* Nothing to do */
>> -}
>>   #endif
> NIT: I think it would be nicer to do
>
> if ( is_hardware_domain(d) )
>      return rc;
>
> but it is also OK as below
>
> Reviewed-by: Stefano Stabellini

Thanks.

It would be really nicer, I'll update  that in the next one version.

~ Oleksii

>
>
>> +    if ( !is_hardware_domain(d) )
>> +    {
>> +        if ( dt_find_property(node, "xen,static-mem", NULL) )
>> +        {
>> +            if ( !is_domain_direct_mapped(d) )
>> +                allocate_static_memory(d, kinfo, node);
>> +            else
>> +                assign_static_memory_11(d, kinfo, node);
>> +        }
>> +
>> +        rc = process_shm(d, kinfo, node);
>> +        if ( rc < 0 )
>> +            return rc;
>> +    }
>> +
>> +    return rc;
>> +}
>> +
>>   int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
>>                         const struct dt_device_node *node)
>>   {
>> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
>> index 2c56f13771..f6aabc2093 100644
>> --- a/xen/common/device-tree/dom0less-build.c
>> +++ b/xen/common/device-tree/dom0less-build.c
>> @@ -28,14 +28,6 @@
>>   #include 
>>   #include 
>>   
>> -#if __has_include()
>> -#   include 
>> -#endif
>> -
>> -#if __has_include()
>> -#   include 
>> -#endif
>> -
>>   #define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
>>   
>>   static domid_t __initdata xs_domid = DOMID_INVALID;
>> @@ -507,12 +499,6 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
>>       if ( ret )
>>           goto err;
>>   
>> -#ifdef CONFIG_STATIC_SHM
>> -    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
>> -    if ( ret )
>> -        goto err;
>> -#endif
>> -
>>       /*
>>        * domain_handle_dtb_bootmodule has to be called before the rest of
>>        * the device tree is generated because it depends on the value of
>> @@ -787,7 +773,9 @@ static int __init construct_domU(struct domain *d,
>>       if ( rc < 0 )
>>           return rc;
>>   
>> -    set_domain_type(d, &kinfo);
>> +    rc = arch_construct_domU(&kinfo, node);
>> +    if ( rc )
>> +        return rc;
>>   
>>       if ( is_hardware_domain(d) )
>>       {
>> @@ -799,18 +787,6 @@ static int __init construct_domU(struct domain *d,
>>       {
>>           if ( !dt_find_property(node, "xen,static-mem", NULL) )
>>               allocate_memory(d, &kinfo);
>> -#ifdef CONFIG_STATIC_MEMORY
>> -        else if ( !is_domain_direct_mapped(d) )
>> -            allocate_static_memory(d, &kinfo, node);
>> -        else
>> -            assign_static_memory_11(d, &kinfo, node);
>> -#endif
>> -
>> -#ifdef CONFIG_STATIC_SHM
>> -        rc = process_shm(d, &kinfo, node);
>> -        if ( rc < 0 )
>> -            return rc;
>> -#endif
>>   
>>           rc = init_vuart(d, &kinfo, node);
>>           if ( rc < 0 )
>> diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
>> index e0ad0429ec..78142e71ca 100644
>> --- a/xen/include/asm-generic/dom0less-build.h
>> +++ b/xen/include/asm-generic/dom0less-build.h
>> @@ -56,7 +56,8 @@ int init_vuart(struct domain *d, struct kernel_info *kinfo,
>>   int make_intc_domU_node(struct kernel_info *kinfo);
>>   int make_arch_nodes(struct kernel_info *kinfo);
>>   
>> -void set_domain_type(struct domain *d, struct kernel_info *kinfo);
>> +int arch_construct_domU(struct kernel_info *kinfo,
>> +                        const struct dt_device_node *node);
>>   
>>   int init_intc_phandle(struct kernel_info *kinfo, const char *name,
>>                         const int node_next, const void *pfdt);
>> -- 
>> 2.49.0
>>
--------------uGiua9zkPM0WYozkwo5Ku0Ml
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/14/25 1:58 AM, Stefano Stabellini
      wrote:
    
    
    
    
    
      
    On Tue, 13 May 2025, Oleksii Kurochko wrote:

    
      
    
        
    Refactor construct_domU() to improve architecture separation and reduce
reliance on ARM-specific logic in common code:
- Drop set_domain_type() from generic code. This function is specific
  to ARM and serves no purpose on other architectures like RISC-V,
  which lack the arch.type field in kernel_info.
- Introduce arch_construct_domU() to encapsulate architecture-specific
  DomU construction steps.
- Implement arch_construct_domU() for ARM. This includes:
  - Setting the domain type for CONFIG_ARM64.
  - Handling static memory allocation if xen,static-mem is present in
    the device tree.
  - Processing static shared memory.
- Move call of make_resv_memory_node() to Arm's make_arch_nodes() as
  this call is specific to CONFIG_STATIC_SHM which is ARM specific,
  at least, now.

This cleanup avoids empty stubs on other architectures and moves
ARM-specific logic into arch code where it belongs.

Also, don't loose  a return value of functions called in
Arm's make_arch_nodes().

Suggested-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/arm/dom0less-build.c            | 42 +++++++++++++++++-------
 xen/common/device-tree/dom0less-build.c  | 30 ++---------------
 xen/include/asm-generic/dom0less-build.h |  3 +-
 3 files changed, 36 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a49764f0ad..592173268f 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -220,9 +220,14 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
 {
     int ret;
 
+    ret = make_resv_memory_node(kinfo, GUEST_ROOT_ADDRESS_CELLS,
+                                GUEST_ROOT_SIZE_CELLS);
+    if ( ret )
+        return ret;
+
     ret = make_psci_node(kinfo->fdt);
     if ( ret )
-        return -EINVAL;
+        return ret;
 
     if ( kinfo->arch.vpl011 )
     {
@@ -230,26 +235,41 @@ int __init make_arch_nodes(struct kernel_info *kinfo)
         ret = make_vpl011_uart_node(kinfo);
 #endif
         if ( ret )
-            return -EINVAL;
+            return ret;
     }
 
     return 0;
 }
 
-/* TODO: make arch.type generic ? */
-#ifdef CONFIG_ARM_64
-void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
+int __init arch_construct_domU(struct kernel_info *kinfo,
+                               const struct dt_device_node *node)
 {
+    int rc = 0;
+    struct domain *d = kinfo->d;
+
+#ifdef CONFIG_ARM_64
     /* type must be set before allocate memory */
     d->arch.type = kinfo->arch.type;
-}
-#else
-void __init set_domain_type(struct domain *d, struct kernel_info *kinfo)
-{
-    /* Nothing to do */
-}
 #endif

    
      
    
      
    NIT: I think it would be nicer to do 

if ( is_hardware_domain(d) )
    return rc;

but it is also OK as below

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    
    
    
    
    Thanks.

It would be really nicer, I'll update  that in the next one version.

~ Oleksii

    
    
    
      
    


    
      
    
        
    +    if ( !is_hardware_domain(d) )
+    {
+        if ( dt_find_property(node, "xen,static-mem", NULL) )
+        {
+            if ( !is_domain_direct_mapped(d) )
+                allocate_static_memory(d, kinfo, node);
+            else
+                assign_static_memory_11(d, kinfo, node);
+        }
+
+        rc = process_shm(d, kinfo, node);
+        if ( rc < 0 )
+            return rc;
+    }
+
+    return rc;
+}
+
 int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
                       const struct dt_device_node *node)
 {
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 2c56f13771..f6aabc2093 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -28,14 +28,6 @@
 #include <asm/dom0less-build.h>
 #include <asm/setup.h>
 
-#if __has_include(<asm/static-memory.h>)
-#   include <asm/static-memory.h>
-#endif
-
-#if __has_include(<asm/static-shmem.h>)
-#   include <asm/static-shmem.h>
-#endif
-
 #define XENSTORE_PFN_LATE_ALLOC UINT64_MAX
 
 static domid_t __initdata xs_domid = DOMID_INVALID;
@@ -507,12 +499,6 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
     if ( ret )
         goto err;
 
-#ifdef CONFIG_STATIC_SHM
-    ret = make_resv_memory_node(kinfo, addrcells, sizecells);
-    if ( ret )
-        goto err;
-#endif
-
     /*
      * domain_handle_dtb_bootmodule has to be called before the rest of
      * the device tree is generated because it depends on the value of
@@ -787,7 +773,9 @@ static int __init construct_domU(struct domain *d,
     if ( rc < 0 )
         return rc;
 
-    set_domain_type(d, &kinfo);
+    rc = arch_construct_domU(&kinfo, node);
+    if ( rc )
+        return rc;
 
     if ( is_hardware_domain(d) )
     {
@@ -799,18 +787,6 @@ static int __init construct_domU(struct domain *d,
     {
         if ( !dt_find_property(node, "xen,static-mem", NULL) )
             allocate_memory(d, &kinfo);
-#ifdef CONFIG_STATIC_MEMORY
-        else if ( !is_domain_direct_mapped(d) )
-            allocate_static_memory(d, &kinfo, node);
-        else
-            assign_static_memory_11(d, &kinfo, node);
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-        rc = process_shm(d, &kinfo, node);
-        if ( rc < 0 )
-            return rc;
-#endif
 
         rc = init_vuart(d, &kinfo, node);
         if ( rc < 0 )
diff --git a/xen/include/asm-generic/dom0less-build.h b/xen/include/asm-generic/dom0less-build.h
index e0ad0429ec..78142e71ca 100644
--- a/xen/include/asm-generic/dom0less-build.h
+++ b/xen/include/asm-generic/dom0less-build.h
@@ -56,7 +56,8 @@ int init_vuart(struct domain *d, struct kernel_info *kinfo,
 int make_intc_domU_node(struct kernel_info *kinfo);
 int make_arch_nodes(struct kernel_info *kinfo);
 
-void set_domain_type(struct domain *d, struct kernel_info *kinfo);
+int arch_construct_domU(struct kernel_info *kinfo,
+                        const struct dt_device_node *node);
 
 int init_intc_phandle(struct kernel_info *kinfo, const char *name,
                       const int node_next, const void *pfdt);
-- 
2.49.0


    
      
    
    
    
  


--------------uGiua9zkPM0WYozkwo5Ku0Ml--


From xen-devel-bounces@lists.xenproject.org Wed May 14 09:58:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 09:58:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984150.1370328 (Exim 4.92)
	(envelope-from )
	id 1uF8sC-0000hd-Ev; Wed, 14 May 2025 09:58:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984150.1370328; Wed, 14 May 2025 09: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 1uF8sC-0000hW-Bz; Wed, 14 May 2025 09:58:00 +0000
Received: by outflank-mailman (input) for mailman id 984150;
 Wed, 14 May 2025 09:57:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF8sB-0000hK-12
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 09:57:59 +0000
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
 [2a00:1450:4864:20::131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e9c4c630-30a9-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 11:57:57 +0200 (CEST)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-54fd1650afdso4222286e87.3
 for ; Wed, 14 May 2025 02:57:57 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-54fc64bf27bsm2196622e87.165.2025.05.14.02.57.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 02:57: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" 
X-Inumbo-ID: e9c4c630-30a9-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747216677; x=1747821477; darn=lists.xenproject.org;
        h=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;
        bh=AXniUx/KT412fF1BPzq5BCIASDQb+3bIl9LzRcy84aw=;
        b=eml7vPScIEFDg/63eECUDZV1LSheq4Hg8Nvp1FaBQlS1atzs+FLMJsyMiot/4DLlLL
         RsoNLxxJxYnjErwSYnM7T4c/WKNLYy9dhBpsVpZmo9azA10fjMGIFQ9U3CwLTv2U3xRO
         LCgKI78sr08WJkxOaWZ4aDFpKfTpqcvLqBKfp2I8SO1SHcpeJFG2nTdU5yv+c/h7iGpF
         vN6XQLMJJyWBQPJoxDA1sCCPMfYiPBtXU3lD9pYy85cJQuQhyThIB0MDF8fNph+pPvg1
         0H5BYOgF2hb9imCSX+fzvzf3S7eUwTmyz9cp2KOhHbwy0/SASbrAFBfpi1SV4yottMSm
         yrhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747216677; x=1747821477;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=AXniUx/KT412fF1BPzq5BCIASDQb+3bIl9LzRcy84aw=;
        b=TEBmLhuJlaSE3tSLh4mXCv1D/giQaDjSt3x2ZYx5PcO5JW41f91E/A+YWM2KnDexrF
         qo/qo2Eir1O0Vgmkf5CCFaM81wMwbTPeZdErFk60LjTd8PDFFq1jyK1TxdlI8yiHT4iN
         77mMZcHfrANfNsqul8Z1ZpnfZnBmGWe8GQOiyuCpkEErw5NJb4aX9lFI493YlwO9Gjuo
         T/VbTi74funuqDP2mGSHE2hSGrMcU4d0A+ffdUqjCbh6/mGee8ElpuBXRgLgqUW2PlM8
         gUkkde1ryYX5ap+n+4lyrmlIIaCGSFyAlziBmzY8NnOmpqemVehd6CvqkMll9AiAcyix
         Ifww==
X-Forwarded-Encrypted: i=1; AJvYcCWGyQAQAB6PPEHTJFjyiqqgdmrWIGr9U1UYrH/eeUiGVqHbMH3Ilbo8b77T1OodLaZxgQ01YhATwgI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx6GJYNluBbqFRqGntd0USLewK7lQh0x7FfMZGWF6qLvU0W5Cc6
	PO16jQCxhHJSihlnYolvlD6Ns1OjrwJ8ZeKht4ymhOiU3LAaS7JL
X-Gm-Gg: ASbGncuGdgp0RnwetM3vd2fRCbxxUnlftdgFUu8Yta9KY8I8+7F206kICKiM0lNuNWE
	jkNWheZKw6eW+o11hYYCKbiLFWexG5B54moekuA4h5TpsMFDXeUEOJFJVAtCraP8VXTQreid4UE
	q2fJ7mku6hC16YauSyBKLl6S93hc62bDvqt/KYEHV7y54uF5kCjVV7rMsu7JXVVQLZUibJTvCrD
	htZBl/aOPr2UlKpadEcwaW4eLwt+4bWds3fu2dfN9AG3XZu72SNHASW9G25lPlYmdoLvFtk2ED4
	FQhl87VsqYF5W2F8e15vblaqRXkcAgIf0tTP9znt3+s1mStZCO+ZqJqUSv0GIyLsXwYcpnFnGgn
	a8OudTjppt5tZgzsjb1fzxSFr
X-Google-Smtp-Source: AGHT+IH+WQlUdnU4tRN8t69VgUcXLhmjnMQFLwvZLwhO5DUYYWSEX4x8qPowyYNp/EPUP90qGtKJKA==
X-Received: by 2002:a05:6512:6514:b0:54f:c616:ee28 with SMTP id 2adb3069b0e04-550d61ee326mr832264e87.47.1747216676927;
        Wed, 14 May 2025 02:57:56 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------X0mI5EF3kOEh06vj711U0VIw"
Message-ID: <6ec7c286-a6c4-491b-8733-42037ba3b91a@gmail.com>
Date: Wed, 14 May 2025 11:57:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU
 construction
To: Julien Grall , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
 <0acae8dd-d4d6-4d65-909d-637c4a283ea7@xen.org>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <0acae8dd-d4d6-4d65-909d-637c4a283ea7@xen.org>

This is a multi-part message in MIME format.
--------------X0mI5EF3kOEh06vj711U0VIw
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/14/25 9:25 AM, Julien Grall wrote:
> Hi Oleksii,
>
> On 13/05/2025 15:29, Oleksii Kurochko wrote:
>> Refactor construct_domU() to improve architecture separation and reduce
>> reliance on ARM-specific logic in common code:
>> - Drop set_domain_type() from generic code. This function is specific
>>    to ARM and serves no purpose on other architectures like RISC-V,
>>    which lack the arch.type field in kernel_info.
>
> So you will only ever boot one type of domain on RISC-V? IOW, no 32-bit
> or else?

The bitness of the guest and host should match. So, an RV32 host should run
RV32 guests, and an RV64 host should run RV64 guests and so on.
(I'm not really sure that on RISC-V it is possible to run with RV64 host
an RV32 guest, but need to double-check)

Therefore, my plan for RISC-V is to have the following:
   #ifdef CONFIG_RISCV_64
   #define is_32bit_domain(d) (0)
   #define is_64bit_domain(d) (1)
   #else
   #define is_32bit_domain(d) (1)
   #define is_64bit_domain(d) (0)
   #endif

With this definition, there's no need to use|(d)->arch.type| for RISC-V.

>
>> - Introduce arch_construct_domU() to encapsulate architecture-specific
>>    DomU construction steps.
>> - Implement arch_construct_domU() for ARM. This includes:
>>    - Setting the domain type for CONFIG_ARM64.
>>    - Handling static memory allocation if xen,static-mem is present in
>>      the device tree.
>>    - Processing static shared memory.
>> - Move call of make_resv_memory_node() to Arm's make_arch_nodes() as
>>    this call is specific to CONFIG_STATIC_SHM which is ARM specific,
>>    at least, now.
>
> This looks shortsighted. If there is a plan to use CONFIG_STATIC_SHM 
> on RISC-V (I don't see why not today), then
> I think the code should stick in common/ even if it is not fully usable
> yet (that's the whole point of have CONFIG_* options).

We don't use this feature in the downstream repo, but I can imagine some cases where it could be useful. So, for now, its
use is purely theoretical and it is a reason why I agreed with Michal and returned back these changes to Arm.

~ Oleksii

--------------X0mI5EF3kOEh06vj711U0VIw
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    

    
    
    
    
    On 5/14/25 9:25 AM, Julien Grall wrote:
    
    
    
    
    Hi
      Oleksii,
      
    
      
    
      On 13/05/2025 15:29, Oleksii Kurochko wrote:
      
    
      
    Refactor construct_domU() to improve
        architecture separation and reduce
        
    
        reliance on ARM-specific logic in common code:
        
    
        - Drop set_domain_type() from generic code. This function is
        specific
        
    
           to ARM and serves no purpose on other architectures like
        RISC-V,
        
    
           which lack the arch.type field in kernel_info.
        
    
      
    
      
    
      So you will only ever boot one type of domain on RISC-V? IOW, no
      32-bit
      
    
      or else?
      
    
    
    
    
    The bitness of the guest and host should match. So, an RV32 host should run
RV32 guests, and an RV64 host should run RV64 guests and so on.
(I'm not really sure that on RISC-V it is possible to run with RV64 host
an RV32 guest, but need to double-check)

    
    
    Therefore, my plan for RISC-V is to have the following:
  #ifdef CONFIG_RISCV_64
  #define is_32bit_domain(d) (0)
  #define is_64bit_domain(d) (1)
  #else
  #define is_32bit_domain(d) (1)
  #define is_64bit_domain(d) (0)
  #endif

With this definition, there's no need to use (d)->arch.type for RISC-V.
    
    
    
      
    
      
    - Introduce arch_construct_domU() to
        encapsulate architecture-specific
        
    
           DomU construction steps.
        
    
        - Implement arch_construct_domU() for ARM. This includes:
        
    
           - Setting the domain type for CONFIG_ARM64.
        
    
           - Handling static memory allocation if xen,static-mem is
        present in
        
    
             the device tree.
        
    
           - Processing static shared memory.
        
    
        - Move call of make_resv_memory_node() to Arm's
        make_arch_nodes() as
        
    
           this call is specific to CONFIG_STATIC_SHM which is ARM
        specific,
        
    
           at least, now.
        
    
      
    
      
    
      This looks shortsighted. If there is a plan to use
      CONFIG_STATIC_SHM on RISC-V (I don't see why not today), then
      
    
      I think the code should stick in common/ even if it is not fully
      usable
      
    
      yet (that's the whole point of have CONFIG_* options).
      
    
    
    
    
    We don't use this feature in the downstream repo, but I can imagine some cases where it could be useful. So, for now, its
use is purely theoretical and it is a reason why I agreed with Michal and returned back these changes to Arm.

~ Oleksii

    
  


--------------X0mI5EF3kOEh06vj711U0VIw--


From xen-devel-bounces@lists.xenproject.org Wed May 14 10:06:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 10:06:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984160.1370338 (Exim 4.92)
	(envelope-from )
	id 1uF90Z-0002i9-7J; Wed, 14 May 2025 10:06:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984160.1370338; Wed, 14 May 2025 10: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 1uF90Z-0002i2-4H; Wed, 14 May 2025 10:06:39 +0000
Received: by outflank-mailman (input) for mailman id 984160;
 Wed, 14 May 2025 10:06:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uF90X-0002ht-Jr
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 10:06:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uF90W-008JsH-35;
 Wed, 14 May 2025 10:06:36 +0000
Received: from [15.248.2.24] (helo=[10.24.67.208])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uF90W-004cNH-0D;
 Wed, 14 May 2025 10: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=TYcgA3hc1azkRLtk2iA1LVAAHk7xja4a9yhWvKCOSw4=; b=q3mgjbK7dhy68Z8fvGcOxAp2X7
	LGeX6+66a3CMaHI60oRUm3I6Z92aT0ijltNwjZyv2umA6S6iRVeaJCKLSjjT1AF5Wa4FuPkyl1fKy
	iy6Rvxu6M14b5+DTHLe0kYyDXsK0hvJIi9MDGYgnSKUcBui/nyMHRVzEyKBGIQo+JrWE=;
Message-ID: <44143db1-1766-4851-9a0c-7428dce9087d@xen.org>
Date: Wed, 14 May 2025 11:06:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU
 construction
Content-Language: en-GB
To: Oleksii Kurochko ,
 xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
 <0acae8dd-d4d6-4d65-909d-637c4a283ea7@xen.org>
 <6ec7c286-a6c4-491b-8733-42037ba3b91a@gmail.com>
From: Julien Grall 
In-Reply-To: <6ec7c286-a6c4-491b-8733-42037ba3b91a@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 14/05/2025 10:57, Oleksii Kurochko wrote:
> 
> On 5/14/25 9:25 AM, Julien Grall wrote:
>> Hi Oleksii,
>>
>> On 13/05/2025 15:29, Oleksii Kurochko wrote:
>>> Refactor construct_domU() to improve architecture separation and reduce
>>> reliance on ARM-specific logic in common code:
>>> - Drop set_domain_type() from generic code. This function is specific
>>>    to ARM and serves no purpose on other architectures like RISC-V,
>>>    which lack the arch.type field in kernel_info.
>>
>> So you will only ever boot one type of domain on RISC-V? IOW, no 32-bit
>> or else?
> 
> The bitness of the guest and host should match. So, an RV32 host should run
> RV32 guests, and an RV64 host should run RV64 guests and so on.
> (I'm not really sure that on RISC-V it is possible to run with RV64 host
> an RV32 guest, but need to double-check)
> 
> Therefore, my plan for RISC-V is to have the following:
>    #ifdef CONFIG_RISCV_64
>    #define is_32bit_domain(d) (0)
>    #define is_64bit_domain(d) (1)
>    #else
>    #define is_32bit_domain(d) (1)
>    #define is_64bit_domain(d) (0)
>    #endif
> 
> With this definition, there's no need to use|(d)->arch.type| for RISC-V.
> 
>>
>>> - Introduce arch_construct_domU() to encapsulate architecture-specific
>>>    DomU construction steps.
>>> - Implement arch_construct_domU() for ARM. This includes:
>>>    - Setting the domain type for CONFIG_ARM64.
>>>    - Handling static memory allocation if xen,static-mem is present in
>>>      the device tree.
>>>    - Processing static shared memory.
>>> - Move call of make_resv_memory_node() to Arm's make_arch_nodes() as
>>>    this call is specific to CONFIG_STATIC_SHM which is ARM specific,
>>>    at least, now.
>>
>> This looks shortsighted. If there is a plan to use CONFIG_STATIC_SHM 
>> on RISC-V (I don't see why not today), then
>> I think the code should stick in common/ even if it is not fully usable
>> yet (that's the whole point of have CONFIG_* options).
> 
> We don't use this feature in the downstream repo, but I can imagine some 
> cases where it could be useful. So, for now, its
> use is purely theoretical and it is a reason why I agreed with Michal 
> and returned back these changes to Arm.

I strongly disagree with this statement. If a feature is not 
architecture specific (like static shared memory), then the code ought 
to be in common code so it can be re-used by others.

Also, AFAIK, the bulk of the static shared memory code is in common. So 
it would be rather easy to add support for RISC-V if we wanted to.

Given the code is already in common, it is rather silly to move the code 
back to Arm for then moving back to common potentially in a few weeks time.

So:

Nacked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 10:22:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 10:22:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984169.1370350 (Exim 4.92)
	(envelope-from )
	id 1uF9FS-00060H-Er; Wed, 14 May 2025 10:22:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984169.1370350; Wed, 14 May 2025 10:22: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 1uF9FS-00060A-A7; Wed, 14 May 2025 10:22:02 +0000
Received: by outflank-mailman (input) for mailman id 984169;
 Wed, 14 May 2025 10:22:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uF9FR-000600-3A
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 10:22:01 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 44cf3d69-30ad-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 12:21:59 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5efe8d9ebdfso12355133a12.3
 for ; Wed, 14 May 2025 03:21: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
 a640c23a62f3a-ad2192c8535sm911701566b.8.2025.05.14.03.21.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 03:21: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" 
X-Inumbo-ID: 44cf3d69-30ad-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747218118; x=1747822918; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to;
        bh=8DJucFn8jQPJRmsvoZ29DnHutiXDNc9NAieB+LH9yaI=;
        b=PpNo4yx++OOC78cjxUiDmZ7F5wRo0CHOd6ZZ516nAw4s36xQrtcYZ98QHFhbCdfzR6
         pCPcldC+LBfRF8NDS7KgNh7qwi5h1hbq8DQMUeNLG0oamXTNllqHf4+fOtR7AgArn4W4
         Onxb9VnVI8HUYdoiT4CN9of98tfNCkZikqJqhF/2Uk5v2SiswP3X1maPEU/DE4hBqzyv
         Ms5swAwOFBG8rTY1szj8azd7my0ySijV/fNA+Tps98LJ9BQms4cigPVZN7Dq2jTC/qfH
         TWGHyCjKdwGLMW2ORGMsIf9gV7diI2JmCfLNgyo5D1DnzXxbsu3fK/Nj9q9adbhOPFm/
         TT6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747218118; x=1747822918;
        h=content-transfer-encoding:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=8DJucFn8jQPJRmsvoZ29DnHutiXDNc9NAieB+LH9yaI=;
        b=CGJz+WphjoUlj/WLXRh/JoIhdCljYl1jDK2dP/xoKnEZwsZx/zxiudK1C4+S9NhTvR
         nOgcZIKuvqRkf32pg1qrtIw7Vd0cdjhB+5ugVZGNejQcozJv1dB4clD4i+WPNrjCpjeO
         5UD+6+Bz31hEsXioXJxpyeuOCFqbUim7bgmw2X74fA68z3FfoXDoLcMlfWx6z9SsVUrq
         Z80KD8GIHcyHAeyW3wH/d3pRjmwOIqF6e+P+Yzk52lLSqMJapU0VnDvbbNE9XFwF/2sE
         qRm5BK5fJqXxNCtXbHCxTPS2or0OcSw/kCuljOFxvv1OBfUZ98ZD4NPh0cyYGLzUay/4
         /kTQ==
X-Gm-Message-State: AOJu0Yx455O0f0XJFfFm8IO8BAysD2cndTxDhJaqKlvFAU2L4CTdf/xX
	S4dqPdslOOtUku0h58XxBIFY0R1Yosork/bX3FOmOvMtXxITEwLuo6++9OzEt4/4Jxkp0THDFd8
	=
X-Gm-Gg: ASbGncuAtOwF7Fld09qwQN4aGWxo2zWwDDMGhDhR+r9AAWhFOpeLR4knLvGKSPmyY7Q
	8HBv5UdkYFKnzvrol+SC1X5OwHNmGczSXXyAuzJckDtakdbc3DYsl79MLJw9yyIy2R2RmB2mejd
	i1CzRhP+YLs3IprFwNx7ZARjR1hmubTZh3EkxwofjIQZeiTcIeWTw76MdUTH3Ok3DqMnJDUT6mL
	/fQAD/BAkOwizCMhcxAwDIrRxyY851XgvUEFDCmRnSuu8Eboh6tK0VBulPQNRgDJ5Wft3hkMZZn
	cmaLvAp375F9TzFXeVsGTjrEoIOpLdeMopXw1r81h8c6YB/RlJCWhfWLYrlWWB5cNA2WVDK7o5X
	/Kjy636IP8Fa4Mn88MQMFS+xs+BREv0AMeMi3L31A2jhFObA=
X-Google-Smtp-Source: AGHT+IF/NrIiXqK83X/mnLgxn3wohHytRvw+TLELdhCz7PVoiUNCyJIzp4zt9hEXgRzc2WQdcOevYg==
X-Received: by 2002:a17:907:72c9:b0:acb:b267:436b with SMTP id a640c23a62f3a-ad4f7153c35mr294155566b.25.1747218118521;
        Wed, 14 May 2025 03:21:58 -0700 (PDT)
Message-ID: 
Date: Wed, 14 May 2025 12:21:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" 
Cc: Marek Marczykowski ,
 Daniel Smith 
From: Jan Beulich 
Subject: [PATCH] x86/EFI: purge a stray semicolon
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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

Aiui in principle this constitutes a Misra C:2012 rule 2.2 violation.
Just that we didn't adopt this rule (yet?).

Fixes: afcb4a06c740 ("x86/thunk: Build Xen with Return Thunks")
Signed-off-by: Jan Beulich 
---
Noticed while backporting to 4.14, where patch context changes.

--- a/xen/arch/x86/efi/check.c
+++ b/xen/arch/x86/efi/check.c
@@ -4,7 +4,7 @@ int __attribute__((__ms_abi__)) test(int
 }
 
 /* In case -mfunction-return is in use. */
-void __x86_return_thunk(void) {};
+void __x86_return_thunk(void) {}
 
 /*
  * Populate an array with "addresses" of relocatable and absolute values.


From xen-devel-bounces@lists.xenproject.org Wed May 14 10:52:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 10:52:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984179.1370359 (Exim 4.92)
	(envelope-from )
	id 1uF9iG-0002Pf-IR; Wed, 14 May 2025 10:51:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984179.1370359; Wed, 14 May 2025 10:51: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 1uF9iG-0002PY-Ei; Wed, 14 May 2025 10:51:48 +0000
Received: by outflank-mailman (input) for mailman id 984179;
 Wed, 14 May 2025 10:51:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF9iE-0002PN-VN
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 10:51:47 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2413::61c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6c33531a-30b1-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 12:51:44 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by PH0PR12MB5607.namprd12.prod.outlook.com (2603:10b6:510:142::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.21; Wed, 14 May
 2025 10:51:40 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%4]) with mapi id 15.20.8722.031; Wed, 14 May 2025
 10:51: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" 
X-Inumbo-ID: 6c33531a-30b1-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=D0h18L1D4Y6n/JIuov0tDnYNuvg6FoIxSGDe5i9Vs14h0rW5RTF04n6FiOrknVnWwLzNX6N+WdL+XtcsXQ+J9hej5rgup5V6DnS+vZULueWygTdvMMrANkYPA4c9Bs2lKW8mCTTO8ipTEoXn8Jz7hFlA57bWtJV4uAauZmkjp4Nx7ueJswcwWer9gZzd+vGGg8VBIVijBzWofmWsfDm6t7fZp+9Iwx5GHE9gRynNxP4zBAtVl9dXsTovFiRGVacPhFU0rtnX53LWi1VAt+jdlGEkLJq0JkWt9HLQwjiBw8hmgzhhO23Pjt4MU5w4gOyUFpJu8MxxlYSGDb6wBMhIiA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mIHjq5yAZkayvYvPPVAUGfkiWqVNM4CUGFrjqG4ULZU=;
 b=lK98vN/0Q4HORxmyD7H7XAWrk1RRyF0moh5GlEKcdmDk+XHnC5cLOdvbVqjSjCnA8dGiJfZwiHddBWIBDSifwSCMeOUBRD9i6OLGfI72jXR0ODgzpKBwT1fkE8xl8A49gwt6EipbKzzTbhGWWsHjlCKcrwAtrV1ZIupodOrGZuqNhzXSwar7x8qWGdgSBTo2idLReo4d8iJubcPbgFzdyv+e9xR4q/rvUs4Q6mERQPSn6rjx38nq2AC1yEHto1BJOG3rRSDuXAxiOOjBpivfti9p8cTqI4dod1sIzjZOzQzM2DnKzTI2Mgv23KNs92nJFX/d24stwFxQc4+c5aYu/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=mIHjq5yAZkayvYvPPVAUGfkiWqVNM4CUGFrjqG4ULZU=;
 b=fU9qbazOy+2W0FSMBjiSpy/M5war12tyflrvjZrJVR92ruzRHc6h3WyiJshfShSHZo6pF6chMVu4XHEoVO5Fy13xWVNTIHwT03d6aWG5isIWYZce3x6KxHOYQrk1gvAz/H8pknnraBGHciBTY791YUoBxunpTPjOqrrniT3W++0=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Wed, 14 May 2025 12:51:36 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU
 construction
To: Julien Grall ,
 Oleksii Kurochko , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
 <0acae8dd-d4d6-4d65-909d-637c4a283ea7@xen.org>
 <6ec7c286-a6c4-491b-8733-42037ba3b91a@gmail.com>
 <44143db1-1766-4851-9a0c-7428dce9087d@xen.org>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <44143db1-1766-4851-9a0c-7428dce9087d@xen.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR2P281CA0005.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:a::15) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|PH0PR12MB5607:EE_
X-MS-Office365-Filtering-Correlation-Id: 7467e6dd-0c92-41fe-0805-08dd92d54eaf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?enk3azVKcDlOZi9QNVYyc3lWSk9raXB4VkN2aTFjN2RncUptTVcvVU14aVhP?=
 =?utf-8?B?RUh5UG5HY2NGK0M1ZERSTVVHY0p6a0RJaS8vV0xWb1llNHU0OTYxQjBrbWFI?=
 =?utf-8?B?VWJRTzZYeFYvbEo0VDFjUVRSUW5YREgxZ3E1T3p0MWlXMzdDdUtYdTVHRDll?=
 =?utf-8?B?Qm5QZkR5dUFNV1hNQ2RnVEJ5UlVOdktCYWV3ODlySHNpSk5zQ2tLUkhseDVy?=
 =?utf-8?B?WXFBYjhreWxFM05RL2ZTQytBU0g5bWJSQlBmMy9MTXp3ajlZd2NnZ2NIUVFl?=
 =?utf-8?B?bjloZ25ubHRCQWExYjZRbm4vOFVCTnJzbUwwZTMvaDVGaThvS1IwZGtCUm1X?=
 =?utf-8?B?bFFRbjZURUI0cURmcGpsaGFkSTNhNStueTYwMGthSEZRaVRwMEhTUEJreHk4?=
 =?utf-8?B?c2txNnhrTFVJemJZN09RMFlSMGtUb2lzTS93b09WZlFJa3Zad1JxVkU2Z0JY?=
 =?utf-8?B?enN6K3FxT3paVXJjaS81eDFtd0hjdlpkSDlCVWcxMkxYdERFdHlFV1RBYnVu?=
 =?utf-8?B?ZkFYRmRSUWxUUFNjNVJhM0FpL3FCMXdhRGk5c2t4WG5ETEZnWGM3RTJuZURP?=
 =?utf-8?B?czJHbFFPM0JwbHdKSmZ6emYvSjV1ZGkzaG8vSlBidTZMbFE1Q0JyRktDRkho?=
 =?utf-8?B?Nzd0YXlyVkJJTHhmUldFYmJNRHVySVFuWW54WkRMTktrNHBBbEFpSDZFYzhU?=
 =?utf-8?B?N2tPRDVNK3dzRWxXMW9YMUJvWlFqemZITjNUbWZGSkg3THdKaU03bHlaVEdt?=
 =?utf-8?B?RmhzdEhTdFhZak1ycmo2VkQxdm5mQTBSdndKcWd1VXZHZ216ZU41cytnL3Fu?=
 =?utf-8?B?RElHbEZ2ZXpPcFZFdXBHbzR2S3lySzhZUzlUS2c1TERXbFNoeklzYWR4UmFH?=
 =?utf-8?B?SUdwQ1R1NmVIb0w2UGh0cGxCN3RaZStrSTlOY25aOGNBNHYzWUF2QlpvUWdx?=
 =?utf-8?B?bEdJODIyYlVZVk1XOGFMckNLZ0tENDZydVdiVXR1ZDA3S3duRlhRWENaNm50?=
 =?utf-8?B?dDNPd3A0djg5cmNGR3RTdWtYVStnVFpjMkhUVW1pUitDRG81djloNTgxeUlO?=
 =?utf-8?B?QWZIbjZFOFF2Mmo1aG9CR1MvazEzSlZmODJKNmt6TmI0K25oaEo5cFpzK3hL?=
 =?utf-8?B?RDBqVHAyTUJIUStnVE5oQnJQVXJvL2tpelVTTjZTcGJhcjZnOFVQQktQTklW?=
 =?utf-8?B?ZFlnQkdDNjAxbFcvOWZ2OWgraHBKaVAyM3JzWm00NTduc1h0STB1SDVwK3E5?=
 =?utf-8?B?OWkxNExkWEQxeVJaOW4rSnRmMnJXQWFpZFhCV1dVL1l5azNDSU9SVkd5Vys2?=
 =?utf-8?B?NHcwc0NKRnl6MGkrakQ3V2t2TDI2UlRmNFdud2R5NEp4NEg3bU9xWXZ2elNw?=
 =?utf-8?B?WTNwVXg4Sis3a3I0Ly9BSXB5WGg0TWpsVFVTbnptdkpXYjNLb1pGMWZKYnhs?=
 =?utf-8?B?SHlwSXE3UXRZeUIwN3RHQ2lCM240d2YyZ2JiUkZPL0h3ZXhHVkVnMW1KenBi?=
 =?utf-8?B?N0creDFCRUtqckVuTm5CTE9FeDJRRXFQR1BoUHM4cWh3aEM4N1JuV1lySmZD?=
 =?utf-8?B?WVdQOWJQSXg1Yml4VzAxc0Y3NnljS3dOZzdhTGg4bm1EMVVFd0w3dUxYTDFv?=
 =?utf-8?B?Y0luNnVjejVoNmxEWFgxQ0NadXlicU9KbHowa2xYTGhpYW1EbDMyanBUOHBS?=
 =?utf-8?B?U2xkR0R4cjYzekZScTA3RVB6d1lvcHMraGVLdGMzbmgySjVNdEJhUU9jeDJT?=
 =?utf-8?B?ZHlZZTVrRk42MTRiTW5ZRFVZeTU2Wi8rZWF6a1piclE0dVh2dWkvbGIyYUtM?=
 =?utf-8?B?eVdybUJMZysyclEvUEVrZE9EZWFac1hHOXpaSTF3NFhOcGplY0lXWHkzVDMr?=
 =?utf-8?B?SUJtYUdGaXJDRGZkQ2pYNCtadGZHY1RQWG5lNXNBcitNRjVYd2RHakNwSlRW?=
 =?utf-8?Q?rBQLvP3U6GQ=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VEdCamszMlh5QlBqcVpHSUMxL0pKaEtHRVo4VHVvaEJsUE96VkwyOHAxamNq?=
 =?utf-8?B?N0J5WWJBTlNXWjhjcDlRcXJiWlIvYzdNalkrZlJnMjlxMFRCTEQvMjlWckpZ?=
 =?utf-8?B?VFlxV2ZjS0pSNzR4d1kzUGV2bmw0dEtpTVBoc283Z2lTRFJDbEs5TTAwcDlL?=
 =?utf-8?B?OVJ3Tm5Kelg2bVhrcUJMYWFoK0p6MHVCVWVJUUExejBxRXMzM0NTcGxnajFL?=
 =?utf-8?B?UUpRZjFLd1FleUVmTUFsQlR6OXpRWWxpbUtiNHVlZnBrWmhCOGRYbkp0eEJy?=
 =?utf-8?B?cHpHYitnSEpHS0NocERnWVY1MUQ4ejZZd0FNa2RST0lqOWdvRXVtMGFhd1p6?=
 =?utf-8?B?R04wdml6N0Rta084QzcvUWk3YW96U3F0ZUVVeFA4Q2F1TDdEaExXOEZDK2I0?=
 =?utf-8?B?bFdhZ1NCOVBWK3BHSFZMZ0NQcVVXRE83RkM0SXIyMk5RWmw4ak9EWTNiS205?=
 =?utf-8?B?ekFUWXNLSXpIMmJ4OUxodndUQXJHRzdzYStJNTBVY1Zjc01FaGw5Q2lBQXhp?=
 =?utf-8?B?NE93TEFiSVpaa1UxWXYrd2JPTXVnOUpzRnZKUGRSYUxBSmY1citvQ2VQc1Fk?=
 =?utf-8?B?Q3VPeWpyTks0YWkzakxHSHV2bzZtT0JMR0FDSFB4dzVoSGJtMk8yQ2VyeWFU?=
 =?utf-8?B?YmhVRkZ4a1BGWlRyZ1ZIZ3QzNmFYMStVa01wUFl6TEtjampxLzAzdlNtcjFT?=
 =?utf-8?B?UEZqblB1UGh1SG90cXBUdVRKUnpROG1IZFg3elk2YUZPS1VKV3BBb1ZmMnRy?=
 =?utf-8?B?cm44V3R3ZHl4Y3BESVdzQVJ5MGdPTjk5MTJZYWJ0L1g3OTViRWJMYjlEV3pL?=
 =?utf-8?B?V0xCTUk4TW5hSmdlaThZcUtvcHdTTlR2Zmx1d2ZGdFRSM0tBQ0FqZkdobGdt?=
 =?utf-8?B?TmlRMmZuSmxLZWZncmRtRHBoSTRwcm5sdjRkZXp4ZENJWHdhNEJ5NnBiVHhM?=
 =?utf-8?B?cmxidnFjTm41MFU0V0NYanNDS3ZIaHJkR3JyNGp1MHp0dzFtOEdSb3pWOS8z?=
 =?utf-8?B?ZllXY0tGUFloQ1oyQ3lUeksvdkdteCtVck1yZGZYVkE2NTJneXBtM3BEQWRG?=
 =?utf-8?B?dUZoNmR0U1hPSXRDWTgzVWU1OWpTbnZCN3BzYlZGT2J1clNmU0RBb1p2V0la?=
 =?utf-8?B?SGxmSVRmanF2YTVpNHhaalA0Y0hrUVhLYWtBVjI4YnhIa3lZanhSeGFabmRD?=
 =?utf-8?B?c1pzUUxZSGNTRTlOQllTWjdFMjcydkRUcDJ6VG82Sm1Wc2d4Tm5kTWJhNDYr?=
 =?utf-8?B?Q296c3NLS0lTMGFwZWtVRU02VTF1SWt5elRhNVdza3JPKzh3UHNNc1laOUVq?=
 =?utf-8?B?QmcyVE1BeFFCOEdWLzZ3bjgxVjZTZTd4SHRVUElabnpVRVAxcSsxak5BTGQz?=
 =?utf-8?B?OUg3WmQ4cU8wTlJXL0F1ZkFCcURCTDFrTGVFNDBtb0FFVld3WEd1dERraVUy?=
 =?utf-8?B?V3NtU0dtaFAzWGtHYWVuQ1ZaWFIrUG91dXAzSVBKWWRDVjF1TGZnQkVjeXln?=
 =?utf-8?B?NW1NdzJVSkljRHBiWjVUV2JRb2xGcW9HT1BIS3d2VkFFNkdkQk5jQkRsMEVk?=
 =?utf-8?B?TXFJdUNQOWgvd0Z5N1QwRm5XeW9tRzZMUVo5VlV0UmJzQlNmNzBBQjBYUEpv?=
 =?utf-8?B?dkdyam5VeHExUzBUbzVDbHdiWlNMSTVmSVR6UEhESVdESk4zOXZjc0JrTnZH?=
 =?utf-8?B?K1g4UXIvSzd2bTVydHUwUEJPbVdCVFVZOUZpcWFKNUtWS01vUkVtQzl4cXdx?=
 =?utf-8?B?bmZ6U1RzWmNUeE05cFlqeW9QNElnRzhmekRZaE8vTUlEanR2MlRyamFMQ1lO?=
 =?utf-8?B?clgrckJFYmFzdUpnM0FCUmhiYTZLNmdIb25IekVIMExncXZvd3J4Y0hnckNY?=
 =?utf-8?B?NHU0c0hBOFk0R0U2Vi8rSE1kRlNHVW5uem02OTgwUWZ4RmYyQzFCTEpGMjRI?=
 =?utf-8?B?a3FWOXNPZ2hOWnR5M3NEQXpnN2JYY3ptZWlRUnhtTG1sbXZiakJuM090Qlo1?=
 =?utf-8?B?QXBTcEYyYmN4MjJ5ODFkSnIvcGVPUzg3cDRUNFE4eGFXRXhqc2RZVFdsTFl5?=
 =?utf-8?B?Rjl5V1RSYmgyUGZnemVldkFRQm5kTWtNQ3h5eVo4VXB0c2drMUdhb1JtMFJN?=
 =?utf-8?Q?0j22kfzVFcbW9BVQBAfNKDK7m?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7467e6dd-0c92-41fe-0805-08dd92d54eaf
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2025 10:51:40.4229
 (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: GNRbS6mX6P6HJTE3XTMp9NXkLJvwaZqF8L2Et0C8KHrwP5viIg6kZcfLOa0TUuHn
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB5607



On 14/05/2025 12:06, Julien Grall wrote:
> Hi,
> 
> On 14/05/2025 10:57, Oleksii Kurochko wrote:
>>
>> On 5/14/25 9:25 AM, Julien Grall wrote:
>>> Hi Oleksii,
>>>
>>> On 13/05/2025 15:29, Oleksii Kurochko wrote:
>>>> Refactor construct_domU() to improve architecture separation and reduce
>>>> reliance on ARM-specific logic in common code:
>>>> - Drop set_domain_type() from generic code. This function is specific
>>>>    to ARM and serves no purpose on other architectures like RISC-V,
>>>>    which lack the arch.type field in kernel_info.
>>>
>>> So you will only ever boot one type of domain on RISC-V? IOW, no 32-bit
>>> or else?
>>
>> The bitness of the guest and host should match. So, an RV32 host should run
>> RV32 guests, and an RV64 host should run RV64 guests and so on.
>> (I'm not really sure that on RISC-V it is possible to run with RV64 host
>> an RV32 guest, but need to double-check)
>>
>> Therefore, my plan for RISC-V is to have the following:
>>    #ifdef CONFIG_RISCV_64
>>    #define is_32bit_domain(d) (0)
>>    #define is_64bit_domain(d) (1)
>>    #else
>>    #define is_32bit_domain(d) (1)
>>    #define is_64bit_domain(d) (0)
>>    #endif
>>
>> With this definition, there's no need to use|(d)->arch.type| for RISC-V.
>>
>>>
>>>> - Introduce arch_construct_domU() to encapsulate architecture-specific
>>>>    DomU construction steps.
>>>> - Implement arch_construct_domU() for ARM. This includes:
>>>>    - Setting the domain type for CONFIG_ARM64.
>>>>    - Handling static memory allocation if xen,static-mem is present in
>>>>      the device tree.
>>>>    - Processing static shared memory.
>>>> - Move call of make_resv_memory_node() to Arm's make_arch_nodes() as
>>>>    this call is specific to CONFIG_STATIC_SHM which is ARM specific,
>>>>    at least, now.
>>>
>>> This looks shortsighted. If there is a plan to use CONFIG_STATIC_SHM 
>>> on RISC-V (I don't see why not today), then
>>> I think the code should stick in common/ even if it is not fully usable
>>> yet (that's the whole point of have CONFIG_* options).
>>
>> We don't use this feature in the downstream repo, but I can imagine some 
>> cases where it could be useful. So, for now, its
>> use is purely theoretical and it is a reason why I agreed with Michal 
>> and returned back these changes to Arm.
> 
> I strongly disagree with this statement. If a feature is not 
> architecture specific (like static shared memory), then the code ought 
> to be in common code so it can be re-used by others.
But the code is not common. There are still 900 lines in arch spec dir.

> 
> Also, AFAIK, the bulk of the static shared memory code is in common. So 
> it would be rather easy to add support for RISC-V if we wanted to.
> 
> Given the code is already in common, it is rather silly to move the code 
IMO it should not be made common in the first place. I don't like exposing
callers with the big chunk of code sitting in the arch specific directory. My
opinion is that they should be exposed at once when the support for other arches
appear. Today we ended up with caller protected with #ifdef and the majority of
code in arch dir.

> back to Arm for then moving back to common potentially in a few weeks time.
What about static memory code? With the recent Oleksii code movement, the inline
helpers like allocate_static_memory() became unreachable when the feature is
disabled and the main purpose for helpers was to avoid ifdefery.

> 
> So:
> 
> Nacked-by: Julien Grall 
Ok. No more discussion from my side then.

~Michal



From xen-devel-bounces@lists.xenproject.org Wed May 14 10:52:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 10:52:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984184.1370369 (Exim 4.92)
	(envelope-from )
	id 1uF9im-0002uD-Tg; Wed, 14 May 2025 10:52:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984184.1370369; Wed, 14 May 2025 10:52: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 1uF9im-0002tm-Q2; Wed, 14 May 2025 10:52:20 +0000
Received: by outflank-mailman (input) for mailman id 984184;
 Wed, 14 May 2025 10:52:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uF9il-0002PN-Dx
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 10:52:19 +0000
Received: from fhigh-b3-smtp.messagingengine.com
 (fhigh-b3-smtp.messagingengine.com [202.12.124.154])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 802d1885-30b1-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 12:52:17 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 12D3F2540125;
 Wed, 14 May 2025 06:52:16 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Wed, 14 May 2025 06:52:16 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 14 May 2025 06:52:14 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 802d1885-30b1-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1747219935;
	 x=1747306335; bh=233wQiFQhCEA3GqilV0zOcKakDfKEZGWRfw9wwU7uVw=; b=
	jth0kBYxnAOQs6CFZFOZXX3P5NuB8m2T7EjLFWck79vrMnt1MzO3YXGORVyHF3kd
	IlHMVMeSh91lEgdO9p+3iCNE3gjQ68ql/puJmUTyKaUWTwYl3p+YE0Gn9CB3JVI5
	dJAtRIN2/AnQnfNbpXsXapvUshyd7mtv4RyShszSk5grTg1EbSPDz4mHdWkTVtq+
	OJxy9+ppXjTK39TXFsPIhOD1AZzQzZWNjXn1cd4FZJtJbNTEgjFTVoePlYzhmtH0
	1/yvp+yCha0lMo6crwWKrRdjE4cN1G9XijLiwvdm1GJTFMcz7JKkP652WOnjdme/
	8aWyjyWBOYG4Hv6IKovD1Q==
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=fm3; t=
	1747219935; x=1747306335; bh=233wQiFQhCEA3GqilV0zOcKakDfKEZGWRfw
	9wwU7uVw=; b=sMOKELqf/JWWLXJZYVznX3lE6FNQnZ53pULHPRRlq+FiIIXW4vA
	dag0+3rmewrt6zAvkYeAQGZCxqWfiCxCFV0SNKiqNcG3PB7539XCE3+pCukMGE9N
	DOKVPH0iVNsgHC8kedELMZK8lQCyrSzctQzTGUO0gU7j/fhgSKn2Z7V3A8dRNl17
	QbMdmsO7wlF4oQBIuuCgvQWLeSyKoQ4gwtPambaT0WljfOmpJHeKS/36JrFl+8Ym
	7un20ohJMqUqGNh79/cNLavLZFGrQ4rQJYuh2Qrg+ix6RQRSn8eQ4tbwA/+k1/gB
	sJzUAhcwmyZr5VVsWhe8xOfLLb+h9KtLB6Q==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdeijeelucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiuceomhgrrhhmrghrvg
    hksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghr
    nhepgfekuddtffettefhieeuheffkeeuffelvdffuddtteetledtveekfeekleehjefgne
    cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhm
    rghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpth
    htohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghulhhitghhsehs
    uhhsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnph
    hrohhjvggtthdrohhrghdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshho
    lhhuthhiohhnshdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 14 May 2025 12:52:12 +0200
From: Marek Marczykowski 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Daniel Smith 
Subject: Re: [PATCH] x86/EFI: purge a stray semicolon
Message-ID: 
References: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="r+fbsk94B5i2H0P/"
Content-Disposition: inline
In-Reply-To: 


--r+fbsk94B5i2H0P/
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 May 2025 12:52:12 +0200
From: Marek Marczykowski 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Daniel Smith 
Subject: Re: [PATCH] x86/EFI: purge a stray semicolon

On Wed, May 14, 2025 at 12:21:57PM +0200, Jan Beulich wrote:
> Aiui in principle this constitutes a Misra C:2012 rule 2.2 violation.
> Just that we didn't adopt this rule (yet?).
>=20
> Fixes: afcb4a06c740 ("x86/thunk: Build Xen with Return Thunks")
> Signed-off-by: Jan Beulich 

Reviewed-by: Marek Marczykowski-G=C3=B3recki 

> ---
> Noticed while backporting to 4.14, where patch context changes.
>=20
> --- a/xen/arch/x86/efi/check.c
> +++ b/xen/arch/x86/efi/check.c
> @@ -4,7 +4,7 @@ int __attribute__((__ms_abi__)) test(int
>  }
> =20
>  /* In case -mfunction-return is in use. */
> -void __x86_return_thunk(void) {};
> +void __x86_return_thunk(void) {}
> =20
>  /*
>   * Populate an array with "addresses" of relocatable and absolute values.

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--r+fbsk94B5i2H0P/
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgkddwACgkQ24/THMrX
1yzbowgAjBWlLtCROwmyPxTStOKRmjYFh4xlFxmdgGOJcgfSCYhENqTYnANbOLfy
iSF8Pke1qvUMke61Q6DjXa/ntIgpTVyoTVlLOUmxfmVTfKVxrpVoV0rOEvFXTnd5
VgL3w2ffseG6Fsvw13Y4T/UFmwW7Qmaobcuq9G/X0itqywtL88h0jcadbDr2sevw
oZGym7tO9DaNBj87qqb/RXgdgj31FV/RKbUeuOQBrbHUu00l0ppiJJ5kKVWwJo6W
xws5z5RknBGDQzFrxbQJpInszLZQDd9i2wGHkBDHksxb0iMSkCb1dx/FbnWrVwXS
jtnVGLUl15GeAmCOGZcPZMVDMO+/DQ==
=pW3W
-----END PGP SIGNATURE-----

--r+fbsk94B5i2H0P/--


From xen-devel-bounces@lists.xenproject.org Wed May 14 11:18:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 11:18:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984203.1370379 (Exim 4.92)
	(envelope-from )
	id 1uFA7j-00064t-RE; Wed, 14 May 2025 11:18:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984203.1370379; Wed, 14 May 2025 11:18:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFA7j-00064m-OH; Wed, 14 May 2025 11:18:07 +0000
Received: by outflank-mailman (input) for mailman id 984203;
 Wed, 14 May 2025 11:18:06 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uFA7i-00064g-5r
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 11:18:06 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uFA7g-008L8m-23;
 Wed, 14 May 2025 11:18:04 +0000
Received: from [15.248.2.24] (helo=[10.24.67.208])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uFA7f-009Hqb-2S;
 Wed, 14 May 2025 11:18: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=lp0M8qg0MRgs4b0+XgfVnH84uKA4AYIc1AZIJ+Tqas0=; b=FOLjVg0bJiHYg+cfytXPtm/ZT4
	4uV5hVV1V+S25Oqq/4O8XLKBUF/MlauR8p3ChJqQvQXtQvFAjlvfs32vfPoUEvL2O7VspeTHH328r
	MhkxcnGNPXNnQ4wM7m4BpsmIwJIotgx4DNxvokM4qIn8N1885s3Lcys01s+74phLc5qU=;
Message-ID: 
Date: Wed, 14 May 2025 12:18:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU
 construction
Content-Language: en-GB
To: "Orzel, Michal" ,
 Oleksii Kurochko , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
 <0acae8dd-d4d6-4d65-909d-637c4a283ea7@xen.org>
 <6ec7c286-a6c4-491b-8733-42037ba3b91a@gmail.com>
 <44143db1-1766-4851-9a0c-7428dce9087d@xen.org>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 14/05/2025 11:51, Orzel, Michal wrote:
> 
> 
> On 14/05/2025 12:06, Julien Grall wrote:
>> Hi,
>>
>> On 14/05/2025 10:57, Oleksii Kurochko wrote:
>>>
>>> On 5/14/25 9:25 AM, Julien Grall wrote:
>>>> Hi Oleksii,
>>>>
>>>> On 13/05/2025 15:29, Oleksii Kurochko wrote:
>>>>> Refactor construct_domU() to improve architecture separation and reduce
>>>>> reliance on ARM-specific logic in common code:
>>>>> - Drop set_domain_type() from generic code. This function is specific
>>>>>     to ARM and serves no purpose on other architectures like RISC-V,
>>>>>     which lack the arch.type field in kernel_info.
>>>>
>>>> So you will only ever boot one type of domain on RISC-V? IOW, no 32-bit
>>>> or else?
>>>
>>> The bitness of the guest and host should match. So, an RV32 host should run
>>> RV32 guests, and an RV64 host should run RV64 guests and so on.
>>> (I'm not really sure that on RISC-V it is possible to run with RV64 host
>>> an RV32 guest, but need to double-check)
>>>
>>> Therefore, my plan for RISC-V is to have the following:
>>>     #ifdef CONFIG_RISCV_64
>>>     #define is_32bit_domain(d) (0)
>>>     #define is_64bit_domain(d) (1)
>>>     #else
>>>     #define is_32bit_domain(d) (1)
>>>     #define is_64bit_domain(d) (0)
>>>     #endif
>>>
>>> With this definition, there's no need to use|(d)->arch.type| for RISC-V.
>>>
>>>>
>>>>> - Introduce arch_construct_domU() to encapsulate architecture-specific
>>>>>     DomU construction steps.
>>>>> - Implement arch_construct_domU() for ARM. This includes:
>>>>>     - Setting the domain type for CONFIG_ARM64.
>>>>>     - Handling static memory allocation if xen,static-mem is present in
>>>>>       the device tree.
>>>>>     - Processing static shared memory.
>>>>> - Move call of make_resv_memory_node() to Arm's make_arch_nodes() as
>>>>>     this call is specific to CONFIG_STATIC_SHM which is ARM specific,
>>>>>     at least, now.
>>>>
>>>> This looks shortsighted. If there is a plan to use CONFIG_STATIC_SHM
>>>> on RISC-V (I don't see why not today), then
>>>> I think the code should stick in common/ even if it is not fully usable
>>>> yet (that's the whole point of have CONFIG_* options).
>>>
>>> We don't use this feature in the downstream repo, but I can imagine some
>>> cases where it could be useful. So, for now, its
>>> use is purely theoretical and it is a reason why I agreed with Michal
>>> and returned back these changes to Arm.
>>
>> I strongly disagree with this statement. If a feature is not
>> architecture specific (like static shared memory), then the code ought
>> to be in common code so it can be re-used by others.
> But the code is not common. There are still 900 lines in arch spec dir.

Sure. But my point is rather more that static memory is not a feature 
described by the Arm Arm. Instead, it is a feature of Xen that is ti to 
device-tree. So inherently there is no reason to be implemented in arch/arm.

>>
>> Also, AFAIK, the bulk of the static shared memory code is in common. So
>> it would be rather easy to add support for RISC-V if we wanted to.
>>
>> Given the code is already in common, it is rather silly to move the code
> IMO it should not be made common in the first place. I don't like exposing
> callers with the big chunk of code sitting in the arch specific directory.

So the concern is we didn't go far enough rather than the feature should 
not be implemented in common for other archs, correct?

> 
>> back to Arm for then moving back to common potentially in a few weeks time.
> What about static memory code? With the recent Oleksii code movement, the inline
> helpers like allocate_static_memory() became unreachable when the feature is
> disabled and the main purpose for helpers was to avoid ifdefery.

Sorry I am not sure which part you are referring to.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 11:30:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 11:30:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984212.1370389 (Exim 4.92)
	(envelope-from )
	id 1uFAJc-0000DZ-R9; Wed, 14 May 2025 11:30:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984212.1370389; Wed, 14 May 2025 11:30: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 1uFAJc-0000DS-OC; Wed, 14 May 2025 11:30:24 +0000
Received: by outflank-mailman (input) for mailman id 984212;
 Wed, 14 May 2025 11:30:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFAJb-0000DM-4V
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 11:30:23 +0000
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com
 [2607:f8b0:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d105a49f-30b6-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 13:30:20 +0200 (CEST)
Received: by mail-pl1-x636.google.com with SMTP id
 d9443c01a7336-23198fcdeb0so7458635ad.2
 for ; Wed, 14 May 2025 04:30:20 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-22fc680515esm97298155ad.0.2025.05.14.04.30.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 04:30: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" 
X-Inumbo-ID: d105a49f-30b6-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747222219; x=1747827019; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=nHSq0f3BjhfKhNt4nQQupbzpr4wf+pehGJ7jwaLBkzg=;
        b=dz9bxLEICPMQfWtX0S2ZxVprnn9HhD6bLTtsKUrRTSrBQrM2lxVj0P5bXtvmW6dDPd
         hpJmEtQWXeevBCyh2/YeIM+Rx7u3lXOLCMZMrMq4XsGhORFHN/TEcWc1B07tmvZ6p9tL
         LpExI5kJqKYEKXmVuCncWa5BzpNEAlXg2aVzk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747222219; x=1747827019;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=nHSq0f3BjhfKhNt4nQQupbzpr4wf+pehGJ7jwaLBkzg=;
        b=VnljqaGP4ligZDlEcC3Mm+/Xckf+matZAf4k/E6H3NIpKgewdLdQEYfMUMwU2mZvPl
         4zDzfyx4+/Fh9XaQzfUeKbaw9PPdTARt8RrgGdAU5AMFvXF0qn9/7LYAWXvcO/uCIzZR
         XLEjV1Pvfc7rJQBi/3JtaEOu/a54WGWlvbv50Gr+NWtcRiNDeiu3QrtcC8jg2SYIC+E5
         k+yelRNzUQeP+xYavpZZ+Yn9sdsfNiMzE50J26a7vCG0j9xQeUMYowIx3hPoNeJJ0ZTx
         iOyO83IKFQTklU93MeT8l3sZEuMcAOhmTvFQoy+mJdPTOij9C294CWGwxWTaMcE2DGzW
         SbWg==
X-Gm-Message-State: AOJu0Yww/P8EznjUnc0bVvvGhO5H7Z6oyWNxVjixvLz7nLbHwy2LRfJP
	9ubjhtX81owCmKifh+7fu6mewdhhUKdYgoR2zA8xtg4uCJC0BlWpkNswkbnUUBg=
X-Gm-Gg: ASbGncsz8sLA0/FQ13uC8uUvia9CL+0D8uasEXHOaPLs8/WMLwMY5D/j+EzZ2y0o8iB
	6mGc7v0O29gO+Dn+5PduK5OutLAoXJ/BEqR8h7hQsTbzqHx1iQ+yOxUXzTD4fRirA6HGmvSvQy/
	cC9cRJ2+m8L9e0F/eKR2ILmP7VLTPMItJlV5aCAkBsnZP7f6P694A1iu7TIM7EVcSUw7aknR5F8
	M1Gle8RgkLySxPBGE41IVGWYgvGIAz0Ox/y6I7NsPVt1od0kzmOgCAgoV3PDDumTRo0ZPCZ7LIK
	ognDjaykTv/ZBGY9CvZg59EXUps0oGVcxw0PqMIvOttw+9dyo92SwNFh
X-Google-Smtp-Source: AGHT+IF1V9hP0WGJ4eQhJSnXj108XtX4n2i+3aRlISq9h0hE6SDaQoLkfCex5MNS+ikZ5pgtZWOIlQ==
X-Received: by 2002:a17:902:c952:b0:223:5e54:c521 with SMTP id d9443c01a7336-23198013ceamr49369695ad.0.1747222219268;
        Wed, 14 May 2025 04:30:19 -0700 (PDT)
Date: Wed, 14 May 2025 13:30:13 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu ,
	Kevin Tian ,
	Jun Nakajima 
Subject: Re: [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache
 writeback
Message-ID: 
References: 
 
 
 <80ab4cdf-dbbb-4daa-831e-c6d92f5dcf13@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <80ab4cdf-dbbb-4daa-831e-c6d92f5dcf13@suse.com>

On Tue, May 13, 2025 at 03:54:56PM +0200, Jan Beulich wrote:
> On 13.05.2025 15:41, Roger Pau Monné wrote:
> > On Wed, May 03, 2023 at 11:45:22AM +0200, Jan Beulich wrote:
> >> We allow its use for writeback purposes only anyway, so let's also carry
> >> these out that way on capable hardware.
> > 
> > "for writeback purposes only" > is such the case because we cannot
> > guarantee the guest in which state the cache will be when resuming
> > from a wbinvd operation, and hence won't be "clean"?
> 
> Not really, no (see below). This is inferred from us limiting flushing
> operations to domains with physical hardware assigned plus the fact
> that we avoid the overhead in vmx_do_resume() when the IOMMU is snoop-
> capable. (Plus I did all this work over 2 years ago, and hence I now
> don't recall what other commentary I may have come across saying
> things along these lines.)
> 
> Which, thinking about it while writing this reply (and also taking
> into consideration Andrew's earlier reply), may be all wrong.

As part of my series I was introducing a new option to allow guests
cache control even when no devices are assigned.  My intention was
that whether a guest needs cache control or not is known at creation
time and stays immutable, and to also allow easier testing of the
cache control code without a physical device assigned.

> > It's my understanding that the same is possible on native, as the CPU
> > might speculatively pull lines into the cache.  So there's no reason
> > for an OS to use wbinvd if wbnoinvd is available?
> 
> Speculatively pulling data into the cache is possible only when page
> table entries permit caching. Hence after changing all mappings of a
> certain page to UC, an OS may have a need to ensure that no data of
> this page is left in any cache (and it can't be pulled back in
> speculatively then).

Is this realistic taking into account the OS is running virtualized?

At least with Xen there's the direct map, so once context is switched
back to Xen (for example to execute the wbinvd itself) there's no
guarantee the CPU won't speculatively populate the cache with entries
from the direct map.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 14 11:33:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 11:33:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984221.1370399 (Exim 4.92)
	(envelope-from )
	id 1uFAMU-0000tk-7o; Wed, 14 May 2025 11:33:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984221.1370399; Wed, 14 May 2025 11:33: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 1uFAMU-0000td-4q; Wed, 14 May 2025 11:33:22 +0000
Received: by outflank-mailman (input) for mailman id 984221;
 Wed, 14 May 2025 11:33:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFAMS-0000tX-N9
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 11:33:20 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2060b.outbound.protection.outlook.com
 [2a01:111:f403:2405::60b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3b4cf6de-30b7-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 13:33:19 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by PH7PR12MB7307.namprd12.prod.outlook.com (2603:10b6:510:20b::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.29; Wed, 14 May
 2025 11:33:15 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%4]) with mapi id 15.20.8722.031; Wed, 14 May 2025
 11:33: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" 
X-Inumbo-ID: 3b4cf6de-30b7-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cw4RVuhmoZVCZEEJaifMe0nqkdmU90v6+Mbfo7RiUNqX5sNpVOjflgLACqs+wd5o0KNDvaaR1rXpoXqmkNUFhQHPMEfBezsKFiBSfRaM2mxuwLDVtogIwJgrWAKqFS1nn0RbvMgrB2IbO1j5aAtwEF2vrbOzjXh3YufZL48J+gbxEyiukN90o16UjnWadbFz7v8ge0crw0kRbSUHNIh8tl5lvp17hJmNkhaRoAI2DWRMFpJIHC2nBbvlpMAcukwl4FutBmWTKC/+6xNDxvSbhxcfMX7Aq9/bGvQuFWJLiY78QOXhmJKrxEhnEm1phgmtU7+roBdvhW6DZcNA/DIoxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BEwRZZmcwzQtIiNRE0bNc/XBc5E21easpUXT1BfBnM0=;
 b=CAJwFb5VGMso+YUDzc56FAz5OpReWYYDuyD/tUfjAQ+3cHxawKHsEth/bYPDly98UdSQ5DQeGwPTFbYfwjQV5BtKm5oHbRf5IdQMXk9IUSuEj6BB8T9mf20HP7VgwxbDKI4OHC0aV3iB5Az2PZc6A+nDH7t1N7oponP0ibxRp60T3ORUobWdiuKnd+2RZaMJ5cRYWCGxGzDrH6QER5T1WMuo9k2I5JKqkey0NQfQbFmpzgpOGRRhLv36ZK4Vbm2QIT8TCyl2IVkIRhlL/ysIcK4I1PsCfff1jnez354excE0cYkUoHSj/TFooK5H2OrkpQwaXXPFdGS+c/3qoxtn1w==
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=BEwRZZmcwzQtIiNRE0bNc/XBc5E21easpUXT1BfBnM0=;
 b=DipKQnLLLJeBZpJ+VUZ3tN4m82KGacGopmx1cjV9XjR4H2BPmHJ0IZUzGjqjrRn4MgMt+7GeUsfioNz8TTEvPI0B4S+29GrAq+uikncWEiP+Mlj4WOS6WW+Q3+UqTEbfjVt8/DqHfOxw61PrbRF7qX4D7u3nSaPzIX5yefZ1wAU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Wed, 14 May 2025 13:33:10 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU
 construction
To: Julien Grall ,
 Oleksii Kurochko , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
 <0acae8dd-d4d6-4d65-909d-637c4a283ea7@xen.org>
 <6ec7c286-a6c4-491b-8733-42037ba3b91a@gmail.com>
 <44143db1-1766-4851-9a0c-7428dce9087d@xen.org>
 
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR4P281CA0051.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:cc::19) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|PH7PR12MB7307:EE_
X-MS-Office365-Filtering-Correlation-Id: ab19fff5-2be8-46fc-cdc8-08dd92db1d9a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|366016;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?K3V4K0xqUWlMM0JQUHBrUmI0dWxwcTJadUo0VEhFZDZMR1lvU1ZOU0N0TGhp?=
 =?utf-8?B?UGlRWDFmbEY4Y1dPbDlZbUFUSDBvMC9ZdjdBSDdYcGVJTE15a1hRbU91T3hj?=
 =?utf-8?B?QlV1Z0RJUTlpcENqRHFpdy9sMUZMellFaURPZ2Z0aThjSTlaVDYzREhBblhz?=
 =?utf-8?B?K1BOOCtwKzd3a2dqck1LVG11eGY3LzVQZkZLK3dRQzFWeEgzSG5PQUJieGN2?=
 =?utf-8?B?WlFCeW16VzBCT09uM214Z3NFeWhJV3Z4QzZKd09wNXZlWStpNk1QamhnUlZM?=
 =?utf-8?B?RHdpUmxRVzh3YUFMRnNqcm1IejN6WDVaT0VKQ3hIcy9HYUdHOUoyaFdFdjFi?=
 =?utf-8?B?bVI0Q0xwREpraUZPZEJYcXFUazM1Sldac1pCeklNZXZ0WU9FWU5NOVpQUXBF?=
 =?utf-8?B?cWFQQnhuNkZSQVUvK205L3RiVCt3N0MzVHA4QjNwc3FFZjVkZDZ1eXFtTTY4?=
 =?utf-8?B?T0x2TjErVUVSYlFNZjhQaTdNSWdiR0hqS2V5ZjlhSHhKSm9uQTZOdEtRTjNQ?=
 =?utf-8?B?VjgrK3p6b28rTDlOcklxZk5zWEU1TFFoaXdrTWpHZWRoU1JaV1FtdUtmR3gx?=
 =?utf-8?B?eEI5N3d5UjMxRGYrMXpLUFJkc3R2eDlTckdxK3FiRkFKZ3BKekFjRWQ4T1lp?=
 =?utf-8?B?OW5nQjBra2RsdUdpODNjalpzcjZmTkl2RCtoa093d05LTnYxdEJPbkZxR25B?=
 =?utf-8?B?b2tUQTVUeExoWEpTQUk0L0Y3dUxtdCtQLy9ZZ3RPT2pPOURKRjQveHpuLzVY?=
 =?utf-8?B?b29aYmVBZ1lNK1JtVElHYXEwM2tXS2NqYkR2RVU2V1BJZ1VOMi9BSVREVjBD?=
 =?utf-8?B?WHNyTkd1WVlQeU94aG1ZcHpINmNFOGlqZStVTGJLT3N6ZnFsM243SzhDSUEv?=
 =?utf-8?B?NktoSnEwOFY2R3AzdmZVSzVZWEVrejJVMUxCamFhUklqRU9HYlVoSEJzTW5C?=
 =?utf-8?B?MEFKRUNpR3R6TlQ1Z2VuOG04Yy9IMWZQU2l4NDdmWFhnTlRkemtlYW1ZUjZP?=
 =?utf-8?B?REk0QzBkbXQ3bHNFbXNmTEtpb3JudGdJeTV6L1B6QjlzS2JJYityS1FSZ3Ey?=
 =?utf-8?B?bkIrTHNaeGtNT3dhQjRGY2VKR1A2QUFVWlduZU5CemhPelBPWXJOWXlWcEla?=
 =?utf-8?B?Umo4K3Fvdm4wOXJlcjUrNTNkVkJValdZVkxZSkNUNDh4YStrSEVaUGIxbTRW?=
 =?utf-8?B?Y244NndLeis1elY2bVJlaXk1RVphZ0ltVFB3ODVIV044dzRHaERkQ1RiTDVP?=
 =?utf-8?B?Z1BITXBGdkUzVWZ5NzFqdzY4Mnd5YlptWDVxRmRWMllYbWwxZHVkLyt0L0s0?=
 =?utf-8?B?clpFZksrODJaZnZtc21FaWxKSk5kNXRUQ2NpMFZBSmQwdWRiRFpsY2dQTnJu?=
 =?utf-8?B?ZXhPRFNnVThTWTEyQXdPQVc3VmJTZ24vQnFaTHM0RTQ2eEJZRGZ6bnhlVDJF?=
 =?utf-8?B?U0V6ODFRckY5VEdHaEZKbkxPMk1PQitIT1E0cFNGR2Z3ZGZBRFBKZi9taVA4?=
 =?utf-8?B?ck1vUEY3azVhaHJpZ0RmQnE4eW5TQ2pNeTlVZXU0VmxJMmx1R0E0N3E0dTho?=
 =?utf-8?B?cVB3U1RzTVNHV211UHNvcW90cVIydkw3bkl6WnlyczEwRXZPb0dCL0hFUzlv?=
 =?utf-8?B?NE56aGFybndNbjQ5anpFeXVoMmd2Y2k1YS9RemdXbUpOaFN5cmNYNjJXMHBk?=
 =?utf-8?B?SEIyRGp5dHRUcXlERDU4bnF3Rm9tQlRVQmlzb2NBVlBGTE82bG02azUxWGZO?=
 =?utf-8?B?UDVtdGx1aVk1aExBTDZVOUZSQi91STl3N3ZxZjc1blp4WUR0V0N0aStKbmds?=
 =?utf-8?B?Q0t2Mm1rTXRxMk94Rk1DazRpMXlJcnE1RU8zQ0lUckxvenJ0UjlkdnhGV3Ez?=
 =?utf-8?B?eXorRW9NWitzRHdJdkZiRjFLMXFtZUJYckdNejZwd0ZOV3RjVi8vS053Nkh1?=
 =?utf-8?Q?vLqtpSZDcuI=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?a1lUUFpKejBiaXlabE9TenRrRjdmVDgzV3JNVVVUY3dQeUtsbGRDQzBaMWds?=
 =?utf-8?B?VFJRcmVDcVR1VFNnRzJ5TDlPZ3NGN2JIWWgxQ2NzejhYcSs4SENJUmdxSHJh?=
 =?utf-8?B?NGFnbjhuL1hiVTkyNkJ6OVNUeHhsR01sdS9QcThZOXdpVXFiZ2t6MUZPOGMr?=
 =?utf-8?B?Z0tSQzUwSEFUOUJES3NIellyUzJnS0l1eGtWSys3eHlRV2MyYzJxVEJqd0hn?=
 =?utf-8?B?bHhBcE0wOFoweTNMRXpwbktsN1lFYTJpcy9Bb0FWcXdvQlFsdHpYa0t0UkxY?=
 =?utf-8?B?a0JVdG5sSlkrTDRqUFhUMFUrektBMFFBZXBHSC9FZmxjdlhJSXAyVmlKR3gw?=
 =?utf-8?B?QmtQcEVNQzczSGg3b0JSck02YlVuZzRNRGtHMlpOSUR0dkhjSzZIdm9ONTFl?=
 =?utf-8?B?dmpXYkNIREx2V01WdVN3RGFucHI0QWNvQ1VVKzUyNUg5ZUhYVy9YTzZCNTMw?=
 =?utf-8?B?M25sUXlFWm04aEVVcjcyMGI3THhYRmUrdXl6MHZLMzNBWTFWSVhkQmJxQXVl?=
 =?utf-8?B?cFpiWDZCcW15T2g1TG5MTkkrcFN6dVhmQVZtNDhoTTJMWHB5N0xQT1pteGY3?=
 =?utf-8?B?MGlIL1FrUDdwZXNvSkZIN05PWHFxYjdWK1ZnZDVFUS9UdGdZcUw0cC9vWTUr?=
 =?utf-8?B?bHZBYlV5V3B6V2txbm5ETm9sb1QzeDlVd1kwZHdCQ3l3R0ltMXA0RnBCbFlJ?=
 =?utf-8?B?RDE5b0licDhHeVNOTk0wTmdyc2x0QzdWT1BaNS9SRDdKRjhuMkx4K3pkYnZB?=
 =?utf-8?B?c0JvNzRobytrNXY0MTRWT1NacHBheHJGakRPb0RVUkRKdWh6TjRESWNZVHlO?=
 =?utf-8?B?Nm1QcFg3eUNSNFVweE9ZNHR0ZmFPYVd5dUdxaWdiVWV6bWhMcFM1ZVA3N3F6?=
 =?utf-8?B?bUpCTk5mYzh2YmFtNGtXYXd2UUJQa0Z1SzVmNXVVM1Npb05zMWFyU09WRWw1?=
 =?utf-8?B?QnQ1WkJ2ZjY4QndrQVdqNjJzV2dBS1hIRUF4aFErV1gzK2t6cFFGd09jSWdH?=
 =?utf-8?B?bUFUSjhnV2RCTFRtMmdOci9UQXNBRGxydVhLcUlZaWIrNG9lc0VkYVZoQ29t?=
 =?utf-8?B?QjZwQWY2cHlpeUxWczgxSEpjWDY1d3VTcGd2aDVWb2tLT0FDbk4rdzBKZGNj?=
 =?utf-8?B?alB4bVFwbXdZZkxndzc4MGJZWlAzd0lmd0FoNGY1RVNmRzk1TmRSY0syVVhx?=
 =?utf-8?B?VEJFYmdJVzVaMVBVeGQ2VjBqREp1TjNjV1lCQ1lCV1hMOENSUEQ2bkNuUkYx?=
 =?utf-8?B?cXpyVFdHMGJRa0VUSHB1RGZjTG91bjJTL1QyenRMTnlmVXlhNjEzaTdjRklZ?=
 =?utf-8?B?SzFWRXRHRG1waEtjODBmZ1NqT2N6TkxDWnUvemZQQmdtZUN3ZGhVbXpkWkxP?=
 =?utf-8?B?cnhwRHhuK3JFM1JNK1VGVFFkbFJ3eElITnFOYTI5Sm9LZDNxZ25jQlQ4OVk0?=
 =?utf-8?B?alJWbFhCa1drU3FyRlN4NDcvcUhqUzhFbWptK0JrdWdUS1ZETU1wa1ExVDBY?=
 =?utf-8?B?YUtmb0RhS3BlNUUvc214WFhwTG02bks0a0dYSkttWXRvN2FrbWJ2Q2xPMU9O?=
 =?utf-8?B?Mis0QkhFQTFLaXhaVUpKNEc0WEhCaE9YVlNXWndBQnlqdlVWV1lURjNqdmI3?=
 =?utf-8?B?YWVRWXA0V2tneEtYS2R1L3NuVDJmcWkrQ1N4Mi9Gb3VNWGQyeHE2aHljbHdW?=
 =?utf-8?B?NWJCWWNIb2VGQmlIQXUvQmJ4VGVuU2lFVk5ZTEdIbXo5bjBGcTQ5YXFvY2RP?=
 =?utf-8?B?ai9SaDAzM3gxQkxwQTQzN0pvMmdWeU5HV2VhK3FYaDRPYXEzS0tDV3NycmxT?=
 =?utf-8?B?UDY4NzY0Z243ejdKbUdNUEZVS2FObGpDWlR3R0hrRjREeElTVFVSbGhwY0o1?=
 =?utf-8?B?Rk5JSk1XNzZUSmRrNkJSMjAvN2hvUDlROGt2Tit1SW1VUnJPbCsyVUx0Q3lq?=
 =?utf-8?B?TDZmcy9INjRkamJCSjR6TGVheFRjMUMwMU5RcFdSVVJNUjB4Sm4wL243WHFs?=
 =?utf-8?B?RzJndGU5MEI3VXN2YTFIT0pUNVgzU2orRlRRa2IrWEtDWlVWNzVOaDhUak0x?=
 =?utf-8?B?NWo2eDg3ZExIWnFrcHE3NW1IQjM1bTVEMllDbUNHY3lESlhCZ2dvaUVkbXA0?=
 =?utf-8?Q?nWnciV/BEhg2r/ZJy/peMJ2UZ?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ab19fff5-2be8-46fc-cdc8-08dd92db1d9a
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2025 11:33:15.1205
 (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: URbZ+iluBH926m27iWPLcCReu6RrRQHfL8aBoBQrTjzmODLsur2KKixrKF1a4rnQ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7307



On 14/05/2025 13:18, Julien Grall wrote:
> 
> 
> On 14/05/2025 11:51, Orzel, Michal wrote:
>>
>>
>> On 14/05/2025 12:06, Julien Grall wrote:
>>> Hi,
>>>
>>> On 14/05/2025 10:57, Oleksii Kurochko wrote:
>>>>
>>>> On 5/14/25 9:25 AM, Julien Grall wrote:
>>>>> Hi Oleksii,
>>>>>
>>>>> On 13/05/2025 15:29, Oleksii Kurochko wrote:
>>>>>> Refactor construct_domU() to improve architecture separation and reduce
>>>>>> reliance on ARM-specific logic in common code:
>>>>>> - Drop set_domain_type() from generic code. This function is specific
>>>>>>     to ARM and serves no purpose on other architectures like RISC-V,
>>>>>>     which lack the arch.type field in kernel_info.
>>>>>
>>>>> So you will only ever boot one type of domain on RISC-V? IOW, no 32-bit
>>>>> or else?
>>>>
>>>> The bitness of the guest and host should match. So, an RV32 host should run
>>>> RV32 guests, and an RV64 host should run RV64 guests and so on.
>>>> (I'm not really sure that on RISC-V it is possible to run with RV64 host
>>>> an RV32 guest, but need to double-check)
>>>>
>>>> Therefore, my plan for RISC-V is to have the following:
>>>>     #ifdef CONFIG_RISCV_64
>>>>     #define is_32bit_domain(d) (0)
>>>>     #define is_64bit_domain(d) (1)
>>>>     #else
>>>>     #define is_32bit_domain(d) (1)
>>>>     #define is_64bit_domain(d) (0)
>>>>     #endif
>>>>
>>>> With this definition, there's no need to use|(d)->arch.type| for RISC-V.
>>>>
>>>>>
>>>>>> - Introduce arch_construct_domU() to encapsulate architecture-specific
>>>>>>     DomU construction steps.
>>>>>> - Implement arch_construct_domU() for ARM. This includes:
>>>>>>     - Setting the domain type for CONFIG_ARM64.
>>>>>>     - Handling static memory allocation if xen,static-mem is present in
>>>>>>       the device tree.
>>>>>>     - Processing static shared memory.
>>>>>> - Move call of make_resv_memory_node() to Arm's make_arch_nodes() as
>>>>>>     this call is specific to CONFIG_STATIC_SHM which is ARM specific,
>>>>>>     at least, now.
>>>>>
>>>>> This looks shortsighted. If there is a plan to use CONFIG_STATIC_SHM
>>>>> on RISC-V (I don't see why not today), then
>>>>> I think the code should stick in common/ even if it is not fully usable
>>>>> yet (that's the whole point of have CONFIG_* options).
>>>>
>>>> We don't use this feature in the downstream repo, but I can imagine some
>>>> cases where it could be useful. So, for now, its
>>>> use is purely theoretical and it is a reason why I agreed with Michal
>>>> and returned back these changes to Arm.
>>>
>>> I strongly disagree with this statement. If a feature is not
>>> architecture specific (like static shared memory), then the code ought
>>> to be in common code so it can be re-used by others.
>> But the code is not common. There are still 900 lines in arch spec dir.
> 
> Sure. But my point is rather more that static memory is not a feature 
> described by the Arm Arm. Instead, it is a feature of Xen that is ti to 
> device-tree. So inherently there is no reason to be implemented in arch/arm.
I agree, it can and should be made common. But exposing only callers makes no
sense at all for me. Callers should be exposed together with feature code movement.

> 
>>>
>>> Also, AFAIK, the bulk of the static shared memory code is in common. So
>>> it would be rather easy to add support for RISC-V if we wanted to.
>>>
>>> Given the code is already in common, it is rather silly to move the code
>> IMO it should not be made common in the first place. I don't like exposing
>> callers with the big chunk of code sitting in the arch specific directory.
> 
> So the concern is we didn't go far enough rather than the feature should 
> not be implemented in common for other archs, correct?
Yes. Oleksii exposed only callers. His intention was not to make static feature
common.

> 
>>
>>> back to Arm for then moving back to common potentially in a few weeks time.
>> What about static memory code? With the recent Oleksii code movement, the inline
>> helpers like allocate_static_memory() became unreachable when the feature is
>> disabled and the main purpose for helpers was to avoid ifdefery.
> 
> Sorry I am not sure which part you are referring to.
With the current code, allocate_static_memory(), assign_static_memory_11()
callers (that were moved to common) are protected with #ifdef. This causes the
helpers defined in case CONFIG_STATIC_MEMORY is not defined to be unreachable
(see static-memory.h).

~Michal



From xen-devel-bounces@lists.xenproject.org Wed May 14 11:40:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 11:40:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984234.1370409 (Exim 4.92)
	(envelope-from )
	id 1uFATA-0002T8-2O; Wed, 14 May 2025 11:40:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984234.1370409; Wed, 14 May 2025 11:40: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 1uFAT9-0002T1-UD; Wed, 14 May 2025 11:40:15 +0000
Received: by outflank-mailman (input) for mailman id 984234;
 Wed, 14 May 2025 11:40:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFAT8-0002Sv-4B
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 11:40:14 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 31e8229d-30b8-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 13:40:11 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5fbed53b421so10773434a12.0
 for ; Wed, 14 May 2025 04:40:12 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 4fb4d7f45d1cf-5fc9cbe523bsm8609530a12.12.2025.05.14.04.40.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 04:40: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" 
X-Inumbo-ID: 31e8229d-30b8-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747222811; x=1747827611; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=76/ZpruyteBOTo/HH+V7/R55KG/PtJdx07J+uWIDU5M=;
        b=GjgLPlCSB4IeaqvtWlbnNF6ZRqL/p9vv3Y7wbbO0rEQEIPKhSZzC+C3/ZAS9TwZ8EC
         u37jdwVDEnfQuY+vAtaWmiUOiA8rQy5b0t8eQIqAa+hBcU1bD1LGhmSPH36F/MVn8k9k
         6+5YF5qqf/8uGBq9aAGnaSALeT87PHjBEMwFU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747222811; x=1747827611;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=76/ZpruyteBOTo/HH+V7/R55KG/PtJdx07J+uWIDU5M=;
        b=mwTXI3Kr7cgHorECkfX3H+Y7LmPAkzjdsG8vld2T6juIQocMsoDisY01ft1dNCSsxR
         PDOFeQ0p35K1SjCykc5p/HhOE4SvkJ6sz5fRpnHK9mhPGYZHeX5s/WwWLH+ErR9Ej5HJ
         bRWB9YgRy9rKWBoozxavi90FxRVPOhy0lYOES/kPFvLg1bkW3VilyZKqiNCWNzsgpFeK
         ArqREficjEtgvgZ8T0kHli2gerd7ZD9NTd4U6n1BGduZ56jiDQc+wA5wTe7oT5WljWfQ
         d8rddZnALbM2BQYtfJqQ9dGE3ZeKNtZ5fToU7ySuzy1l/yX9fNyVl7pN3apoY+2cKcKy
         Fykg==
X-Gm-Message-State: AOJu0YwhkXtDqcPnbJufb295QUkNlUl4CxZDCgOT9tab54y6zw7e8VKH
	yGDJC+g0Squbow7ICP1CM5UvDr6uTYqzjSGCRjls6mGNd/eU/TEc1KEEayxQ8Uc=
X-Gm-Gg: ASbGnct4XTZaXng4qKTBvZ8EL4Ap+vE29GagTEL9v6ILngTpgZ74vjDF7I92sSMNxKS
	Vn4VQVLQlHLrdPAv3X78CYwqA1awDNW+ZCj22kY9MQwt9uovVaf9ANORJ6u4IKIU8Q/hWsrOiu2
	FPL3JCSq7NVpAk20L7N7zV9iTW3608PQ6qYFx4IYYh3IpClAA6sA2DA5LpHBgbl69VxrmaQ4Ii8
	403fYsTrkXH0S5BSCqYRaOxsahnwxrS+97EBPyklhgdqOmAicbPbzHL/P1UiyyeVttl3gu3Z6/R
	VdekGNuRm0M9NUQEOaiCa+/PRjWU+QPQu7SAR2ySDD3fooUVEnYQcHzz8kSulA==
X-Google-Smtp-Source: AGHT+IE86edRmkMFGLEcQIu2Q2fvgzwfLfaHKaZ1CS7RwoHmJ5OSIDOeMJ9eUuX0vsUZq2qCg4O2dA==
X-Received: by 2002:a05:6402:1d4c:b0:5fc:a51c:21a3 with SMTP id 4fb4d7f45d1cf-5ff986a68ddmr2170743a12.4.1747222811548;
        Wed, 14 May 2025 04:40:11 -0700 (PDT)
Date: Wed, 14 May 2025 13:40:10 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu ,
	Kevin Tian 
Subject: Re: [PATCH v2 4/6] VT-d: restrict iommu_flush_all() to cache
 writeback
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Wed, May 03, 2023 at 11:46:11AM +0200, Jan Beulich wrote:
> We don't need to invalidate caches here; all we're after is that earlier
> writes have made it to main memory (and aiui even that just in case).
> 
> Signed-off-by: Jan Beulich 
> ---
> This, aiui, being an analogue to uses of iommu_sync_cache() (just not
> range restricted), I wonder whether it shouldn't be conditional upon
> iommu_non_coherent. Then again I'm vaguely under the impression that
> we had been here before, possibly even as far as questioning the need
> for this call altogether.

I think yes, it would better be only done for iommu_non_coherent.  Yet
in that case I wonder why we need this wide flush.  In principle all
accesses should already have their own write-back calls if the IOMMU
is non-coherent?

There's maybe the call from vtd_crash_shutdown() which I guess could
trigger in the middle of some interaction with the IOMMU, but at that
point do we really care to flush anyway if Xen is going to crash?

Otherwise it seems fine to switch to write-back.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 14 11:45:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 11:45:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984242.1370419 (Exim 4.92)
	(envelope-from )
	id 1uFAXn-0003GO-FL; Wed, 14 May 2025 11:45:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984242.1370419; Wed, 14 May 2025 11:45: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 1uFAXn-0003GH-Cb; Wed, 14 May 2025 11:45:03 +0000
Received: by outflank-mailman (input) for mailman id 984242;
 Wed, 14 May 2025 11:45:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFAXl-0003GA-71
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 11:45:01 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id da9e5d43-30b8-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 13:44:55 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ad23db02350so755626466b.1
 for ; Wed, 14 May 2025 04:44:55 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad2197bd3a6sm920246866b.131.2025.05.14.04.44.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 04:44: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" 
X-Inumbo-ID: da9e5d43-30b8-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747223095; x=1747827895; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=ubg3h8wapkFGfWHn3cyifpLCAoAOZacgNEoyNgrU1GU=;
        b=nG1huWmt+LWBvqRsunzP6cJqJEtLd0/cepmrgYlBZrZDYex5Mj2CCkbkG7UGbIVGHZ
         smbCUwJq3ypCmuH7jGnTFK4zeRlTuIyy8i6cGA3QVE1cbyuV1RO5t9FSi8N6ZeJ4RAta
         fuZv/gNJpQMXRGEtFoAfFFMQ00IX7DyKrCjzo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747223095; x=1747827895;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ubg3h8wapkFGfWHn3cyifpLCAoAOZacgNEoyNgrU1GU=;
        b=k5VXpHcdxkz34c24+37DTdfkH12wT+/w+5yoY3xY7gJDavfldoxVptqpPYpnSY14NX
         FqZXHVqBhjQ0Hb4wY08H0Dhk89KSi59GE9K865EclOXjvDLPBcmhVMMQrRSb+9HSaAN4
         ePM5VZTBuSaE06S6120j7s7WpkWY01tGp6v+PLO4jRA6SCouqsPhY8+g++5A7OMoYMA9
         pYcw86rUJTh4wPqrvQ+iuiXf4f8Ku8z85FhDy8tnJFvN4xbFxhsOmc7PFBcLixsSyTHS
         l8rmJm/B5gO7CwowWx8BTCslhkFUiV+CZci8rp2g/uAlqlBPh6t4oHsUoxBSYbqSwrKW
         C+wQ==
X-Gm-Message-State: AOJu0YwJLolFvdpLfOhhesO95ED3sBirchCUFLmhFFTCSGLSbfkDKL2f
	1LqIiUEO0ngTsNQtpH9VvGfyaNY5VPmiXJEXmjonSCiH8nKvgoHNbLjZq5Vr4ZmfiWUkSftmMvF
	v
X-Gm-Gg: ASbGncsoKb2au2IO5Yl86JBez2IKH4gg81EFYuNeFVEJwAggNm8T6PcUOw9JJkyjbus
	ixDn/HM+81PPfBDuF79I6r26n4oZpt1mFkOkl5fYxDSFCEAO3zFzKpVEkptCgI/5DkpF2BaTzgo
	sZrxiaMTd7dQPYvhp+c8Ae31Nc0MGPPLSyMaJH4iA76HFJ1Qft0C0aUFkVU5XLTAICeg2FItdp9
	i+yYEMfU+EBd8KNTMiJvvNIy7DELDF/R8zrHOnbM6/UBtheGw4KEwFdyx0H4+x3PqivuqXg1HQj
	KCgsl4U8yddlJWTKDr+5MRP4BupgwgQdAUP9k9SpMy8wKYokqZ0QgkQWJ+49YA==
X-Google-Smtp-Source: AGHT+IHtLZx8Z4NJ8Zv1aoUaU1ItOuWpsyFGODCigS/C6X+SmOKaBJaL7LP4vMA/8RcvcAh//KovAQ==
X-Received: by 2002:a17:907:3ea8:b0:ad2:e683:a776 with SMTP id a640c23a62f3a-ad4f70f6322mr304684066b.1.1747223094667;
        Wed, 14 May 2025 04:44:54 -0700 (PDT)
Date: Wed, 14 May 2025 13:44:53 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu 
Subject: Re: [PATCH v2 5/6] x86: FLUSH_CACHE -> FLUSH_CACHE_EVICT
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, May 03, 2023 at 11:46:41AM +0200, Jan Beulich wrote:
> This is to make the difference to FLUSH_CACHE_WRITEBACK more explicit.
> 
> Requested-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 

Acked-by: Roger Pau Monné 

This is however missing the previous calls from SVM/VMX that at this
point in the series have already been switched to write-back instead
of evict.  Maybe this patch should be the 1st of 2nd, so that changes
from evict to write-back are done afterwards?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 14 12:46:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 12:46:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984280.1370430 (Exim 4.92)
	(envelope-from )
	id 1uFBVR-0002vf-3j; Wed, 14 May 2025 12:46:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984280.1370430; Wed, 14 May 2025 12:46: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 1uFBVQ-0002vY-Uh; Wed, 14 May 2025 12:46:40 +0000
Received: by outflank-mailman (input) for mailman id 984280;
 Wed, 14 May 2025 12:46:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFBVP-0002vS-Bq
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 12:46:39 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7787b03a-30c1-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 14:46:34 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5fcab0243b5so8832173a12.1
 for ; Wed, 14 May 2025 05:46: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
 4fb4d7f45d1cf-5fe81b89783sm4532387a12.77.2025.05.14.05.46.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 05:46: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" 
X-Inumbo-ID: 7787b03a-30c1-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747226794; x=1747831594; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=39VJnEzZq5zx5B2cbA2O9GgONBerbNrB5HncvGGaEtY=;
        b=KxyXmdtcgd4uIwUVXqSjI32/fz5MUG5pTykTOu1SUVcnIm5yvko65O8TSZmigxDe4x
         jeLKKMXkt8sn+TK3Y+wBJdkl0fV+264u7Wp01IB2WCwuAM7lyQWeUMDSWERKMotBm07g
         UTJJAjggzw2wVV2alPgZ5rQTL8Bk3N+tT9a5bhIUg1Kp7vOiIld6EbPb6g4K/qTHYzQW
         EtlllkiHb7wyzzHCtdx9nrFBIBB/wNtFEYnfUr4ETYeupbq6O3u6fCgiz4J/VtD8LEvE
         ioxakiDc4Q4eGo6zKX0dk+tOAmv/Xx455wDI+ZDXuInQSXwH4z/LEtDFhgtjZqhdXtmB
         u+6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747226794; x=1747831594;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=39VJnEzZq5zx5B2cbA2O9GgONBerbNrB5HncvGGaEtY=;
        b=h35NIXKbV9luEP8ObihMBvwVcJVTuFfgZ0IDOub2qgywFwb+D/IXyQIS0MIxQn9dTQ
         4clLdD/6fvcBmDzvKu7H+RLBAhffsIZ5n1BB9zixhdA7e4d8DGntYE1XFnDmMTPnKgXl
         I1k85jsepySVWm7gM6TKsDUGxnkm1qt02FF1y7Y0E8b9gUNu+a9qQxa4LmFvALbntmov
         emz6l2ecK44HgdDyIavs6AAXR8csz6FEYsnC6vxJAm1Gfkpz1tbZXuQ3BbPFnI3s6P6O
         YD1dQtJMuXMAWUrbsOAQkt4vbpUF+DzxL+jyqM4Bf/mwr+YDZwejnl+XCz5usDF0/mL6
         g3hw==
X-Gm-Message-State: AOJu0YzjWS5DNzlCsKLfa4d0gnu0stTplG9cE9X6dihNNx80rrbYeM8X
	SjD9ZFhzjNpdlGOpkvx49ElpV5j/8QC6bDoIDKML923xuSwT+MpUyN9sY6b5xw==
X-Gm-Gg: ASbGncvDgRLWhWPmIw7bEakOuLpolK0AhrPAKSaKXQRBr8Y8xGwd4WMzHBXUhLmi84n
	ro2MRFv+3nf3RzoffFnwd32omiBbhSBw9MwBG7gBQgdkDqNHGxbNvwbocNbA0uTwFv+rNeTsnGl
	+NL1G8Ya22yhifrkHG0Mh3tITb0g1MV81J5kSInLtGeuCCie6U5MO4H22S3hMWWBcb+Zaqu2f+z
	TcI+pN7KLCNmuFQU96xd88dQtaQIciJJ36CDUngNVfXXHT7nTMhQ9Sl18gUbu9SRYSkZkGQgg0c
	ntzNVDZt6pv3ooVT+StAhRcUrgCUomkPCLmivjRyQawLplw6ItwS3ZHmH757RA+Xs4TAWlqidQm
	mgB3Ds0E73aXkXIZHqDVgZxaTzyjiai6aGciRCx3hav6Shok=
X-Google-Smtp-Source: AGHT+IHlTMSYyYJ2ZoAcBustTQppqE8+w7jhHLVRWjkZL242Oj8ksgPBVZKg+o8Fhm3WrUc2Tvd4AA==
X-Received: by 2002:a05:6402:1d4c:b0:5fb:1c13:3685 with SMTP id 4fb4d7f45d1cf-5ff98891591mr2672682a12.5.1747226793658;
        Wed, 14 May 2025 05:46:33 -0700 (PDT)
Message-ID: <66603689-429b-4bf6-8792-e4feae346a13@suse.com>
Date: Wed, 14 May 2025 14:46:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache
 writeback
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
References: 
 
 
 <80ab4cdf-dbbb-4daa-831e-c6d92f5dcf13@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

On 14.05.2025 13:30, Roger Pau Monné wrote:
> On Tue, May 13, 2025 at 03:54:56PM +0200, Jan Beulich wrote:
>> On 13.05.2025 15:41, Roger Pau Monné wrote:
>>> It's my understanding that the same is possible on native, as the CPU
>>> might speculatively pull lines into the cache.  So there's no reason
>>> for an OS to use wbinvd if wbnoinvd is available?
>>
>> Speculatively pulling data into the cache is possible only when page
>> table entries permit caching. Hence after changing all mappings of a
>> certain page to UC, an OS may have a need to ensure that no data of
>> this page is left in any cache (and it can't be pulled back in
>> speculatively then).
> 
> Is this realistic taking into account the OS is running virtualized?
> 
> At least with Xen there's the direct map, so once context is switched
> back to Xen (for example to execute the wbinvd itself) there's no
> guarantee the CPU won't speculatively populate the cache with entries
> from the direct map.

Well, we've been knowing for a long time that we're not doing things fully
correctly there. Once a guest has changed all mappings of a page it owns,
we ought to make the direct map one follow suit (or simply unmap it from
there).

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 12:49:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 12:49:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984287.1370439 (Exim 4.92)
	(envelope-from )
	id 1uFBYB-0003SS-E8; Wed, 14 May 2025 12:49:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984287.1370439; Wed, 14 May 2025 12:49: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 1uFBYB-0003SL-BN; Wed, 14 May 2025 12:49:31 +0000
Received: by outflank-mailman (input) for mailman id 984287;
 Wed, 14 May 2025 12:49:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFBY9-0003Rz-Ht
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 12:49:29 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id df4c0dcd-30c1-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 14:49:28 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5fbf007ea38so11148489a12.3
 for ; Wed, 14 May 2025 05:49: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
 a640c23a62f3a-ad2197ca2b4sm921532466b.160.2025.05.14.05.49.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 05:49: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" 
X-Inumbo-ID: df4c0dcd-30c1-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747226968; x=1747831768; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GFKRJMuYPqJDDAMbiCEkqUZfsCK1lahX934dXOGYlzA=;
        b=DmzVT/KNIvg35XiyTmtxbVV1mWV9e4N+MaKv0COt8SBuHmpKlzXy8cR9EwtfBhDKFL
         lmHBF9IwJRK69xpbq3Snd8yig6WLqqlCyJIjNdcybnHTLX3tnHwVlP5Axq5IZ4lhvBmE
         d7Mvc7zmFK1R+THDKj0S8l85C+fFx8FxqlgMNCVSEi9PA9q+5UIouCLBC9fh/Rdn25hW
         iQLzDJ8mcBUIaxxXONGnsg6SXGzbnltUW32d52cmkTeQAIekamFvhvEymuWylC4rq821
         WE9Wkxo6onOVFKt+9CaIX4oSBzLLe5JjDRb1EmV0gTsf64yRagYmtgGnuQePjLeiDOrf
         IGxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747226968; x=1747831768;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GFKRJMuYPqJDDAMbiCEkqUZfsCK1lahX934dXOGYlzA=;
        b=Zoq5ZO2Fqle5F4KDzgi7q5VA923mXBR982iX2e+3r6AbUnX6ubdeuvU46OoOZT1gWM
         CCMkJObKgH/d6cabroyDEoy2vkCQkRqbvJMRj/UX0tvNtayF+CiAwjP+4Xfa2vVQM6Bw
         443QODwtWXAirhOsvLJjrq1Xhd4m/pVXC2E7zxKS+IcA6SxlR9aNdS13I1vAFHjHotTV
         /K2YYViL3DCRzvXV9mLEpzo4r+RP3dOLPXH+ft1vSrREdXwyUN+YFuwNVCIAZM5Wy6wI
         b/eEkrrHKn2BvoEkhB7pOv2ZyCsOJzhY2raE6gL6LEmpNyeHCfB1M0kqZemgeN+3bcV6
         JK4Q==
X-Gm-Message-State: AOJu0YwEseL6mOMa4B9FSB/n4RG2Z6Ofhfv5hn3TVpzMpSQQ7k8YfIb0
	Nf6QcNvND3PzjtSS5qBlWjehsc95S1RK7L7zmQvhdWxGEqV+zYeZ1ArL1S3vprftv/LyyNZMO4Q
	=
X-Gm-Gg: ASbGncvWFCzRSdQVSPrmEReOtG1lynKhjyGRvtvQiGOZivINjW6EGfXr5l59eSJzUyF
	pkXUoBABBxZ1j+DZSxCRN9pEjkbcagSw8YgyEdFUs0leovXi95LqY2/+pUHRjqH6RQiciF7/Ks5
	6NMdQxDMnqLxpaobW7TrjF1sLxBnqBEfmWMK7ilf7d0y1lWt4H/tsohoUf52E9x+WgKroluQtLG
	mFxpA+jdwBYC3adq1e8X4c3aTWpNR46ObieRc+ZpINGoMbCBSlBi6vJoN7kZvPEr9N+OU+OJAd5
	XNo2nm28R9IUz10c4Lz6MZdojyb1h4/jJFnGJNgsectdcmGXJUUUPw1iG9/W3B1s2JuDnn5JHxC
	SZYla79pnicEIQqrtOBf0Fhm7Qt64BnHbJbxw
X-Google-Smtp-Source: AGHT+IEUyJ3ZfwCZz4AgHlX3975sReeOpIIrMfJvXaIQHFXP9s03auWO0qgnbYDA6PQi7U1tPTW1pQ==
X-Received: by 2002:a17:907:97c9:b0:ad1:766a:9441 with SMTP id a640c23a62f3a-ad4f71a9f6dmr349111966b.23.1747226967923;
        Wed, 14 May 2025 05:49:27 -0700 (PDT)
Message-ID: 
Date: Wed, 14 May 2025 14:49:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/6] VT-d: restrict iommu_flush_all() to cache
 writeback
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
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

On 14.05.2025 13:40, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 11:46:11AM +0200, Jan Beulich wrote:
>> We don't need to invalidate caches here; all we're after is that earlier
>> writes have made it to main memory (and aiui even that just in case).
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> This, aiui, being an analogue to uses of iommu_sync_cache() (just not
>> range restricted), I wonder whether it shouldn't be conditional upon
>> iommu_non_coherent. Then again I'm vaguely under the impression that
>> we had been here before, possibly even as far as questioning the need
>> for this call altogether.
> 
> I think yes, it would better be only done for iommu_non_coherent.  Yet
> in that case I wonder why we need this wide flush.  In principle all
> accesses should already have their own write-back calls if the IOMMU
> is non-coherent?
> 
> There's maybe the call from vtd_crash_shutdown() which I guess could
> trigger in the middle of some interaction with the IOMMU, but at that
> point do we really care to flush anyway if Xen is going to crash?
> 
> Otherwise it seems fine to switch to write-back.

In which case why don't we do it in two steps: This patch, and then one
removing the call altogether. Just in case the latter one turns out wrong
for whatever reason.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 12:52:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 12:52:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984298.1370449 (Exim 4.92)
	(envelope-from )
	id 1uFBbH-00054n-Rr; Wed, 14 May 2025 12:52:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984298.1370449; Wed, 14 May 2025 12:52: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 1uFBbH-00054g-Oe; Wed, 14 May 2025 12:52:43 +0000
Received: by outflank-mailman (input) for mailman id 984298;
 Wed, 14 May 2025 12:52:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFBbG-00054a-Il
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 12:52:42 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 52660867-30c2-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 14:52:41 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad1b94382b8so1092488766b.0
 for ; Wed, 14 May 2025 05:52: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
 a640c23a62f3a-ad2197bd2c0sm931739266b.130.2025.05.14.05.52.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 05:52: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" 
X-Inumbo-ID: 52660867-30c2-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747227161; x=1747831961; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ePKQMdg0HfkFJRMwMJzfA4x2E8fptY8CYBTRd6KUVxA=;
        b=MWN1C80BlVr/afbFbBsaLDUxpCEW0evvsc+s6UOSZRTrLc4JiTpjzb8sta+7DCgit7
         VhmcuyEymsXw5jEl3989R+EF6wzJPd2JR++V/iynAnbJngMEkXwdkhXpYfwZpThtxcf3
         AldhuLgCmBme1Q9CitUkZPTeeqp/nXUB6uqZDs/aGLUt2UYx6vgcck/pLoD2/p4i/mgl
         +Nll30uZrCkwW6cvfqP29hj0+euNbrG2xQ528ibm4sONqsk9vPA9YjCtDyGV9m8i6XOy
         6amZWtcV3DOt06e3u2Z1z5CNO4h1q4EhQ5aXP59k/RSKHAYpn69ygHHB4graNVo1ox+d
         7ptw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747227161; x=1747831961;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ePKQMdg0HfkFJRMwMJzfA4x2E8fptY8CYBTRd6KUVxA=;
        b=Hskxh2hsQjdf4KQf/msRMxRtQV5fMM+IADxAd0Sgf3PYXY3xEvDsh/EV+XwYgi9wiG
         L2ViV7D3HwmFg2VHEk2VSN8I2oIqyrvKFQID3TrWyFPfJ5Hu1lYvX01JGfCyh0OXY8dN
         GR1NdEVd2mD8acmsTX/LjZnZPVoJ/BcGl0/WSUXN7z9+PYNi/bLlEryABdRGFbrnDNDT
         PbTIN7n//HtiNU7XGkkTRx6frBgonR18UTKZVO9sgWdy6WDqsRfyTjzG5vIKF90QHsvw
         aXQrnMvnZn7jF6J9shKtKjj/mugdCDxml36TLt8cnfRkQpYLTXyWBSrKXyLByKmiT7Jg
         Y2MQ==
X-Gm-Message-State: AOJu0YySu6fl0oR9qswiqAXGnppipEY9O/hEx9KeetBJjs63xXM+7PYr
	dYZcgKYtGb/ezslGvuwQeG5Dqop5YxeQG4AGp0PwdW3/Il/MLn4e4MNVSqi5WIiKZYqWuUd9ZEg
	=
X-Gm-Gg: ASbGnctv3p6JCSgX5r5LG1U607VD6wjg19sGFeP0avYunQCy/DqyszDvL7uwttmk7Wg
	pXjjYWQq9zMPJbum9hK95Qw+yI/sjF6iJMYE3ua1KLQ0j+aVqS4K6lNlAi92O6fAKNpY+KBEdQo
	WvbhleNlVTcG1WtoqNH9iCIaCRKK38Zvq3wXcYxeA7gs+TDEHycvEp9zlh7ySffHpGBf8gkEBeT
	7KxFaQ3KhAieYay9QAPQDx5mcfWAjnHfzUitZFWBzgrIW4j4x8ZNuXCsxUaa0yRUHV1OD+7H5TN
	VsiaZPZ1v7pWATJZ0Q7YlSc+jAWdUyoFVBNTNubTZ9zoRVj7Eahjku6jIJO4U5QC5NJ9jgrZYkI
	9mBGqg1IAn/mFGKdudVaE3IO4Nh93qwZXeyts
X-Google-Smtp-Source: AGHT+IFUDbpPYhHLaAwWhcFAxMnHAB2gDj8LuI1AsP0GOC1zALwos7nmOVnN2b75vLF3iEs/Stmg8A==
X-Received: by 2002:a17:906:dc92:b0:ad2:50ef:492e with SMTP id a640c23a62f3a-ad4f717e01dmr340251866b.32.1747227161096;
        Wed, 14 May 2025 05:52:41 -0700 (PDT)
Message-ID: <5aeca684-4ff1-4299-ab07-95d02be12f46@suse.com>
Date: Wed, 14 May 2025 14:52:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/6] x86: FLUSH_CACHE -> FLUSH_CACHE_EVICT
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Wei Liu 
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

On 14.05.2025 13:44, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 11:46:41AM +0200, Jan Beulich wrote:
>> This is to make the difference to FLUSH_CACHE_WRITEBACK more explicit.
>>
>> Requested-by: Andrew Cooper 
>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Roger Pau Monné 

Thanks.

> This is however missing the previous calls from SVM/VMX that at this
> point in the series have already been switched to write-back instead
> of evict.

Hence why it's this late in the series, i.e. ...

>  Maybe this patch should be the 1st of 2nd, so that changes
> from evict to write-back are done afterwards?

... I wanted to avoid touching those places twice. (IOW re-ordering would
be possible, with the extra changes you mention, but I'd prefer not to.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 13:00:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 13:00:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984306.1370460 (Exim 4.92)
	(envelope-from )
	id 1uFBie-0006cL-KQ; Wed, 14 May 2025 13:00:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984306.1370460; Wed, 14 May 2025 13:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFBie-0006cE-FX; Wed, 14 May 2025 13:00:20 +0000
Received: by outflank-mailman (input) for mailman id 984306;
 Wed, 14 May 2025 13:00:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFBid-0006c8-Nf
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 13:00:19 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 621f42d1-30c3-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 15:00:17 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5fcc96b6a64so8792082a12.0
 for ; Wed, 14 May 2025 06:00:17 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad219374753sm934144266b.75.2025.05.14.06.00.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 06: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" 
X-Inumbo-ID: 621f42d1-30c3-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747227617; x=1747832417; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=Cp44VPrCe7E0iWOoeiEtYivPM+pYB3ZZmZRGKLCzlrI=;
        b=VCVWQQGCwQ8O3LOGe1cGhmw1UqymIpSJA/c3KkfNQ5ypVJrXW9PoabZiKqG/a/Jayc
         gV1i257gl42whFjMIZLd4rMlb8qleDbEc0HWnfSjVPLjTIlE51kdkiubZJRnYXTWm1bH
         s6iFip5aDOeVVuYiPAlKT9eG/VfgdYEfuHP3I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747227617; x=1747832417;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Cp44VPrCe7E0iWOoeiEtYivPM+pYB3ZZmZRGKLCzlrI=;
        b=XvkDkRRufIyFpDpTJBtQvUA6zSpfw5RZCXlO9Q96RPLIZRnh1gfrrMiQrhO3wobOn9
         cN+O6we7Tqf1OLhxG3xQdgRLkW9ErqDWhv1UhREUqlc4VMwb4EcPfKc7G9tFcuJhKwHi
         Ou+8LjJMBkox6Nz2w7DELp2hQEgcQxu9+zRURKZmj/cU2tUeaRFiObbMLGIFNsu51YEd
         tk+gtGHT2dL4j4EhSvUHZULWViSmKQGXylCF4Hle8v0uBnBSOJ/uTFMcSMEWNszKB4sC
         13P1P0Ye1I1DA9TrBKhft1lSxs3ugeErr5zK7V75LCMEM/XnNPFedi1AT+eWa1sZpp9f
         jwTw==
X-Gm-Message-State: AOJu0Yz2Op1BkhVBUotwyrd0WrTTMDey6r+kAN6GFjdQzwrJKeuCI/0p
	k0YEoUera2AeSgY/xZhy+gy0NrN+rrM0Chu9VCexUp7SR+29PX2Ybn6cGaMKHFU=
X-Gm-Gg: ASbGncuds0sQIrrCQdgz3nCicMsz19tocqAAY9CLln4I9FirixyY3cH4M6lYjCSZLKe
	Fki7wqXqxtHMyxNKOUieHUFUG/P9SsVku3ULaxNUn3UPi1FsNt2i7fBazLheH+WZ774Q/3ID3Zr
	zt3P1vy3b0Av8SJHNdiF98mU9vCrtSBiQdTqPCfV6o+1NoLF18eax2pNYWrF1d4CKwq34yyBUnz
	eQ39Ey7u8l9XsTljqtFIBfY9U/hj9d4HBsSZ71n9drFqVXZwmQA5ZtavdsKyarcJ0AoqTI8zl2n
	JBUbRLBX1s3iMBWpYU5v47wJtf0/1/AOCe1oxQULADKSuIN//HBJtL9KJxcHVA==
X-Google-Smtp-Source: AGHT+IGZwpSNYc6qsBP4ojzmSjul57P5titEfYFu+ylbKb3LqpSDyM9J4/bLG0wyrqZh9i9tu0xg4Q==
X-Received: by 2002:a17:907:198c:b0:ad2:2fe0:6310 with SMTP id a640c23a62f3a-ad4f75a0de0mr350862766b.57.1747227616693;
        Wed, 14 May 2025 06:00:16 -0700 (PDT)
Date: Wed, 14 May 2025 15:00:15 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu ,
	Kevin Tian ,
	Jun Nakajima 
Subject: Re: [PATCH v2 6/6] x86/HVM: limit cache writeback overhead
Message-ID: 
References: 
 <9274fbb1-c1be-9570-ecfc-8f0ac9a1f42b@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9274fbb1-c1be-9570-ecfc-8f0ac9a1f42b@suse.com>

On Wed, May 03, 2023 at 11:47:18AM +0200, Jan Beulich wrote:
> There's no need to write back caches on all CPUs upon seeing a WBINVD
> exit; ones that a vCPU hasn't run on since the last writeback (or since
> it was started) can't hold data which may need writing back.

Couldn't you do the same with PV mode, and hence put the cpumask in
arch_vcpu rather than hvm_vcpu?

> Signed-off-by: Jan Beulich 
> ---
> With us not running AMD IOMMUs in non-coherent ways, I wonder whether
> svm_wbinvd_intercept() really needs to do anything (or whether it
> couldn't check iommu_snoop just like VMX does, knowing that as of
> c609108b2190 ["x86/shadow: make iommu_snoop usage consistent with
> HAP's"] that's always set; this would largely serve as grep fodder then,
> to make sure this code is updated once / when we do away with this
> global variable, and it would be the penultimate step to being able to
> fold SVM's and VT-x'es functions).

On my series I expand cache_flush_permitted() to also account for
iommu_snoop, I think it's easier to have a single check that signals
whether cache control is allowed for a domain, rather that having to
check multiple different conditions.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 14 13:21:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 13:21:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984321.1370468 (Exim 4.92)
	(envelope-from )
	id 1uFC2e-0001K5-5D; Wed, 14 May 2025 13:21:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984321.1370468; Wed, 14 May 2025 13:21: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 1uFC2e-0001Jy-23; Wed, 14 May 2025 13:21:00 +0000
Received: by outflank-mailman (input) for mailman id 984321;
 Wed, 14 May 2025 13:20:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFC2c-0001Js-Tm
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 13:20:58 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 452c15fd-30c6-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 15:20:57 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5f7ec0e4978so5057790a12.1
 for ; Wed, 14 May 2025 06:20: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
 4fb4d7f45d1cf-5fc9d7016b4sm8809548a12.49.2025.05.14.06.20.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 06:20: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" 
X-Inumbo-ID: 452c15fd-30c6-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747228857; x=1747833657; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/mFWFbt80HwFSS8XBsPFC4uEs/obwm5wBL/ZDKhx6WA=;
        b=HWV3ouWD8+R6o42zIx6tzbFH0jI5y0/B7ek/wOqgxEJ25QPcB+vk5yeOAR2S6OnhH7
         RMDbJOfqd7j+aDFLChnwuS4DK+mJ9PpoZnBl+smmc4oumA1CyklzSeXSHWmYpMyqDi3F
         W9qmGXdCOka3G+AEYQ2ill4dKMx8XwACPxy1W/2w5LsBwPv8Pj907aE6rK2D2Nv+B818
         ppCy3w460JhRk1xb5uVeINTpY+L+ePVgjrxLZwB9WTwSfi3etUCbK+/8IgUVUsQ0EPmO
         XX+H6AkvyQLjKOZSSMS1k28r7CBZBuRGlB5VjIy2QRGxd59UM2bzWzfh2VJec6ILE7Gw
         teFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747228857; x=1747833657;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/mFWFbt80HwFSS8XBsPFC4uEs/obwm5wBL/ZDKhx6WA=;
        b=grZxdSNXvO93yOpmx0a3yX/+cyx/SWO8AJcECJ2FJr0ogDUBY43B4TbSo2rbe+RLfE
         cG+sDz67GiAeZBDIeNu2wIn+2mAd9AjbpcXBaorLjehqwhQqVrxl1VADItEFp5NIAm39
         EjfcUx0gWt5rVdvDHj05dNrKvN75uTtCqOy1Yf9TyLcDZOBzrXjpycCMqk705f9MOAtY
         QKVg/sArkU71YWyZHIwSSka8Fti/5WUJp+ioPemYUDJ5SPGK4d1CdM8ThyPVOGqpFgLW
         HJxdBj6SJkJkMZHt4NSKoEwfrJdNT8rCaw57L0Y+ZBMkvt54j2rSbUiUzGAZjlWixPc/
         UFMw==
X-Gm-Message-State: AOJu0YzkS8wndEdigiXRnVqy60fSQdqpfiS1L28s0Ecgytqp7U7zYjS/
	WnEvOGimMqg5qpVFS544yIt0Cqbruo5N2GmQxIUgE4PP3o93f+3zQ9U+wWFohQ==
X-Gm-Gg: ASbGnctW3255O8bM8UboaBkSexEGy7BH4Tsnd5oBXoEOivROLrjHR8SWs/8JwwVqYlE
	UGYIKtL+epbXneWUpVZu6Y2XUtXPg2GNKd1BG2POM0Nbdef2i3Swv4J7AIR5HvMpGFM6YKopANn
	w5bIjFuytQJo//9CA1GHSrTSXLljYz97wCEZ22+itXqGZMZR+DkXWYgxF9TcZxBL8WnCQnwk2rz
	sGFWa8XMdQ0iiy2wUJB7nqdcMhfjm1Ih6A8mRehCiR/hE42K4PU51uZ0KzgO0Lw/4NB5SvuE3x0
	BRCY2h7W4eVYCiMqUVCSC6cmZqgwMwcUmEYMVKJNEV3Ww3cF8iPhHNk3qzKzX81jy0T78dgJ5+l
	zB3dEbecy3unIiL5ygRU458PansqqZd2GItl78UFQFs0j2L8=
X-Google-Smtp-Source: AGHT+IEf8npOC9j5qFNGmxRUhzlEedfVagFPxEpncaFs2jfte7ehe0nBbOuLACFnpf5A0Tz6lvlzBQ==
X-Received: by 2002:a05:6402:358e:b0:5f8:e6de:fd0f with SMTP id 4fb4d7f45d1cf-5ff988acc0amr2810920a12.15.1747228857187;
        Wed, 14 May 2025 06:20:57 -0700 (PDT)
Message-ID: 
Date: Wed, 14 May 2025 15:20:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 6/6] x86/HVM: limit cache writeback overhead
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
References: 
 <9274fbb1-c1be-9570-ecfc-8f0ac9a1f42b@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

On 14.05.2025 15:00, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 11:47:18AM +0200, Jan Beulich wrote:
>> There's no need to write back caches on all CPUs upon seeing a WBINVD
>> exit; ones that a vCPU hasn't run on since the last writeback (or since
>> it was started) can't hold data which may need writing back.
> 
> Couldn't you do the same with PV mode, and hence put the cpumask in
> arch_vcpu rather than hvm_vcpu?

We could in principle, but there's no use of flush_all() there right now
(i.e. nothing to "win").

>> Signed-off-by: Jan Beulich 
>> ---
>> With us not running AMD IOMMUs in non-coherent ways, I wonder whether
>> svm_wbinvd_intercept() really needs to do anything (or whether it
>> couldn't check iommu_snoop just like VMX does, knowing that as of
>> c609108b2190 ["x86/shadow: make iommu_snoop usage consistent with
>> HAP's"] that's always set; this would largely serve as grep fodder then,
>> to make sure this code is updated once / when we do away with this
>> global variable, and it would be the penultimate step to being able to
>> fold SVM's and VT-x'es functions).
> 
> On my series I expand cache_flush_permitted() to also account for
> iommu_snoop, I think it's easier to have a single check that signals
> whether cache control is allowed for a domain, rather that having to
> check multiple different conditions.

Right, adjustments here would want making (in whichever series goes in
later).

For both of the responses: I think with patch 1 of this series having
gone in and with in particular Andrew's concern over patch 2 (which
may extend to patch 3), it may make sense for your series to go next.
I shall then re-base, while considering what to do with patches 2 and 3
(they may need dropping in the end).

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 14:25:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 14:25:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984339.1370479 (Exim 4.92)
	(envelope-from )
	id 1uFD2g-0000c1-Ex; Wed, 14 May 2025 14:25:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984339.1370479; Wed, 14 May 2025 14: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 1uFD2g-0000bu-BI; Wed, 14 May 2025 14:25:06 +0000
Received: by outflank-mailman (input) for mailman id 984339;
 Wed, 14 May 2025 14:25:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFD2d-0000bo-Vr
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 14:25:04 +0000
Received: from 1.mo576.mail-out.ovh.net (1.mo576.mail-out.ovh.net
 [178.33.251.173]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3899cca8-30cf-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 16:25:01 +0200 (CEST)
Received: from director11.ghost.mail-out.ovh.net (unknown [10.108.17.160])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4ZyFws0LHXz29rc
 for ; Wed, 14 May 2025 14:25:00 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-skcxt (unknown [10.108.42.32])
 by director11.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 52D871FEE2;
 Wed, 14 May 2025 14:24:58 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.113])
 by ghost-submission-5b5ff79f4f-skcxt with ESMTPSA
 id 9crYArqnJGhoSgAA5d7/iw
 (envelope-from ); Wed, 14 May 2025 14:24:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3899cca8-30cf-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-113S00752e3d6b3-b61f-45c4-985f-1d64059a3d14,
                    1A2B554256F610091AB5939E0627E839E0136BDA) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
Date: Wed, 14 May 2025 17:24:50 +0300
From: Sergii Dmytruk 
To: Demi Marie Obenour 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	Nicola Vetrini ,
	Doug Goldstein ,
	"Daniel P. Smith" ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v2 20/22] x86/slaunch: support EFI boot
Message-ID: 
References: 
 
 <68e5f8bb-42b2-4da8-86ba-231cb5657106@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <68e5f8bb-42b2-4da8-86ba-231cb5657106@gmail.com>
X-Ovh-Tracer-Id: 12086535502388966556
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdejvddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpedttdeufffggfeuheevfeehieeijeekkeehheefjeejvdetjedvvdegkeevgedtffenucffohhmrghinhepthhrvghntghhsghoohhtrdhorhhgnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukedurddujeekpdefjedrheelrddugedvrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheejiegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=yh1mOuB14GzOR//G2ZQJD8Cg8dSYcEr4wknQDgmfohw=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747232701; v=1;
 b=Qf2fP+vqL7ZGsqLI1AbSlpDShDoZCTHVkuhpv0vwHLFNtXftKT/lYQQYa8wtFwEWu/MeAMuj
 zGgBZlyuoMv0y4+WhO5LYCY2dgXZ//2Ku9nCCRrySD8ih8uph2LJZLRGaM+N7IyLdBZ5BhFQ+cx
 /d4AgXl8QL9zhMTUbHbU0WtnTZvWpqNbU3rERppbLFsoY/Pnsq6/lfQOEUcI8HpFCcHq+ACXHZw
 0KBeb456ij7ZDRbE9DfSPgV4tgPgxVPL34gWWqiTKEf/WmyDE4mNbmJwT9XZ7ftHlasgUwfDBVo
 JiCw8d30f9083qW9SamkIiUVPlFKiIUVu0+3rylV2/pow==

On Tue, May 13, 2025 at 09:25:44PM -0400, Demi Marie Obenour wrote:
> On 5/13/25 1:05 PM, Sergii Dmytruk wrote:
> > When running on an EFI-enabled system, Xen needs to have access to Boot
> > Services in order to initialize itself properly and reach a state in
> > which a dom0 kernel can operate without issues.
> >
> > This means that DRTM must be started in the middle of Xen's
> > initialization process.  This effect is achieved via a callback into
> > bootloader (GRUB) which is responsible for initiating DRTM and
> > continuing Xen's initialization process.  The latter is done by
> > branching in Slaunch entry point on a flag to switch back into long mode
> > before calling the same function which Xen would execute as the next
> > step without DRTM.
>
> Depending on the bootloader for this unnecessarily ties DRTM to GRUB.
> Instead, it would be much better for Xen to be able to perform DRTM
> itself, which would allow DRTM to work without GRUB.  Pop! OS already
> uses systemd-boot and the trend seems to be from GRUB to systemd-boot.
> Furthermore, this would allow DRTM with Xen launched directly from
> the UEFI firmware.
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)

That sentence in the commit message is worth rewording.  GRUB isn't a
requirement, any TrenchBoot-enabled bootloader (or anything that wants
to act as a bootloader) can be used.  systemd-boot could implement
Secure Launch specification [0] and start Xen/Linux/something else via
DRTM.  Usage without a real bootloader could be implemented similarly
via some EFI stub that has binaries embedded into it or that can load
them from a drive.

Mind that at least Intel and AMD DRTM implementations require a DCE [1]
binary that depends on a vendor, firmware version or a CPU generation.
So even embedding all code into every kernel-like software won't produce
self-contained DRTM-capable images.

[0]: https://trenchboot.org/specifications/Secure_Launch/
[1]: https://trenchboot.org/theory/Glossary/#dynamic-configuration-environment-dce

Regards


From xen-devel-bounces@lists.xenproject.org Wed May 14 14:28:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 14:28:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984347.1370489 (Exim 4.92)
	(envelope-from )
	id 1uFD63-00019a-St; Wed, 14 May 2025 14:28:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984347.1370489; Wed, 14 May 2025 14:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFD63-00019T-PH; Wed, 14 May 2025 14:28:35 +0000
Received: by outflank-mailman (input) for mailman id 984347;
 Wed, 14 May 2025 14:28:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFD62-00019N-8y
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 14:28:34 +0000
Received: from DUZPR83CU001.outbound.protection.outlook.com
 (mail-northeuropeazlp170130004.outbound.protection.outlook.com
 [2a01:111:f403:c200::4])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b56e90a8-30cf-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 16:28:31 +0200 (CEST)
Received: from AS9PR06CA0099.eurprd06.prod.outlook.com (2603:10a6:20b:465::34)
 by AS8PR08MB8706.eurprd08.prod.outlook.com (2603:10a6:20b:564::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.31; Wed, 14 May
 2025 14:28:24 +0000
Received: from AM1PEPF000252DB.eurprd07.prod.outlook.com
 (2603:10a6:20b:465:cafe::84) by AS9PR06CA0099.outlook.office365.com
 (2603:10a6:20b:465::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.28 via Frontend Transport; Wed,
 14 May 2025 14:28:13 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM1PEPF000252DB.mail.protection.outlook.com (10.167.16.53) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.18
 via Frontend Transport; Wed, 14 May 2025 14:28:11 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 PAWPR08MB9542.eurprd08.prod.outlook.com (2603:10a6:102:2ed::9) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8722.29; Wed, 14 May 2025 14:27:38 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8722.027; Wed, 14 May 2025
 14:27: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" 
X-Inumbo-ID: b56e90a8-30cf-11f0-9eb6-5ba50f476ded
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=vbTZp731xIQitgZlcdf7WvwxLfZBprQPV9GNorSBPkrO7XKsVdSiftLXusbPqwUQor0R5wuHCnLbaTsYtyBBd7iLm2lFY+QtMtur7xe3LF6GDo0Br2n7pC3nPUquHmBnCHIzqPsoEjM7E0Vi8dVNNU/37Xq3GryBJSS3ibAiLtErMCxHlTTD8qf4lA4YD5DUV9lNhnOxqlaFSugFmYiWzV4sIFFJ6Xm0qYqa4CJdRqDFfQdQJLJRcO5okF36ZEMRHZSX9YxhGqA2PhpjuquXr32mbtqHibPNSo9c9tqb6kX6JumSvbKciE8MJ3E9yvAoEFRxxM/GUAj80yZIe/i8UA==
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=LTrrrbM77KNeqeVQJm2I0wmbQ8tBjHiWW/yCH0bPAJk=;
 b=w+14iVAC/9HyO5ZcfAKV+FYMBU2HyHjLfieZZY1pByZ9lEn994+7Zw0L3PrI21PL2Tz6Zm81wWOWPUjlDbtIL1pzxIb/NDK/IzMknFY/7pqp1pwefaglQtNpbR0GDzpFmrrwe8kamarP5PmLJQ81uSOYd5QQuuccu7ZCvoWlqtlXS4FpksH6Jd3Av+7vmX04sBuYwY3lisnN2k+OaNA5bu/R0+mdJm95cMEivjtva2lHAgcKgJnPRWR0qQBJA7VijoiOAhv2jKUafZXnIKmdLlmuUxKabO0C40MrAaXIY3f+2UzYFZiDm1HRwkaZdcN++Pvn8YEuxF7Q+0ZxL3Yq9A==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=xen.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LTrrrbM77KNeqeVQJm2I0wmbQ8tBjHiWW/yCH0bPAJk=;
 b=cpE/drlgtLE9tHWp+uX0kzwkhlwSKmLolW+lVvJBgjY0rU9XTLNwJZ+kgzgnK4eFSSI/fXqYpDwFeHAevkZdkvRXS1JUpWLJQvdAX3FRrMsRxkdbxBcmyBZYZrAo/1QfNfVOBw8uwbjfvD75GeZt/lZ/ivFrf/CiUiTYZY6iosQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XCvGZKKjcbT6a+IBDP7bOVaASjn+Dn+Nk2b1O6okNEAF47dBgnPjszRgcMP/DDRUL3P1XgwQo+DzrsU5arb3vcs8+7B+DRs7vPU6iPqViOD3T9ntbhMOTvUlRvAcdzHe2EhXrc7rHcjBtA2kLWJpR92Gu1k9rrLISK9fuf2giJ4WcMxaWegmgvDQUeD3ONDunr664SZE69xwm7KQM/dFDD6cuF4V6UJgN4sKnWO9gCSyjBhDfp4Cxd10lomIC6NdpwxZEYuUTETTYeo1vtDFy0QVOcHI997pSD69RJrCx+/4xL2ZabSRQqwRWhEdz0+M9R7wFVwIzmEM48IgKdc2YQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LTrrrbM77KNeqeVQJm2I0wmbQ8tBjHiWW/yCH0bPAJk=;
 b=v19uLf/O8Jk4PlB1E77xQHG5plwID7UvguzNnWiUvrPd0uHxhpcX0gp+LaGCdVGdix7rzrlI3NhOmSSWrmJD+A8iPqhNSIBhZFVipBK/otjIScBH4ii7VKKHwk5o/9zgKbcnwMmeb/QT4RliZKoncNi7cQCvpB+iC+1i51asiHGAtqkSS0YWAes5cxpE4e/Zw6PffI2QIBygNLVXSqL7vnTTlVMQ4YJ89QFMwMlOy1MEpONAJmzizcKkbD41jUwuyO7wjE0qDNqBGyU2K+kqDJEEZxzdRqi3hFmh0wqtrNYD+9sgOpNk72drx7QoZX9yFKeuDXUy5cm4VxWeEdGofQ==
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=LTrrrbM77KNeqeVQJm2I0wmbQ8tBjHiWW/yCH0bPAJk=;
 b=cpE/drlgtLE9tHWp+uX0kzwkhlwSKmLolW+lVvJBgjY0rU9XTLNwJZ+kgzgnK4eFSSI/fXqYpDwFeHAevkZdkvRXS1JUpWLJQvdAX3FRrMsRxkdbxBcmyBZYZrAo/1QfNfVOBw8uwbjfvD75GeZt/lZ/ivFrf/CiUiTYZY6iosQ=
From: Luca Fancellu 
To: Julien Grall 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: Re: [PATCH v5 3/6] arm/mpu: Provide and populate MPU C data
 structures
Thread-Topic: [PATCH v5 3/6] arm/mpu: Provide and populate MPU C data
 structures
Thread-Index: AQHbw+N7OQ17lZ1szkalxBxuriXrX7PRz90AgABg5wA=
Date: Wed, 14 May 2025 14:27:38 +0000
Message-ID: <112E7D85-7BDB-490D-98E9-75D03397567D@arm.com>
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-4-luca.fancellu@arm.com>
 <1e56c7e8-5302-4280-a48d-d1e958eeadc9@xen.org>
In-Reply-To: <1e56c7e8-5302-4280-a48d-d1e958eeadc9@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|PAWPR08MB9542:EE_|AM1PEPF000252DB:EE_|AS8PR08MB8706:EE_
X-MS-Office365-Filtering-Correlation-Id: e98d77fa-afc7-458c-6dff-08dd92f38e4f
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|1800799024|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?Ynp4TE8zai9TdGxscHpvejJISHZLZjV0c202allVeHpreGFBMHc1Wkk4Y1JN?=
 =?utf-8?B?U1NoT2tKYStlZzJSVFRkNk1iUFdDSENDekNtMEVmKytBenltOGcrNnlzZEFx?=
 =?utf-8?B?a0h1Z2tLSkhveG9wUWJMZnp2R2dnTGg4dHpRd0h2Yml4ZDlJUWEzMFNHU0do?=
 =?utf-8?B?QjYvTmE3cW5CU05QbTJudTBvTmZYSERMcnNobjEvbURXU3RxNE1BaEFWNVht?=
 =?utf-8?B?TnZYTHFQaURCNjN0UnpQK044OFdpVDE5UTRKZUZOeXZZVVVYQnhUNStyT1o1?=
 =?utf-8?B?VjI1MTdQdFQ4dHg2cjd1UzFqMWhJM3FmRndEQ2tzQmR6N0tON1V5cnV6TGhX?=
 =?utf-8?B?cUFZWjdxeTM3RHRhblV3bkdwYXJuYkRTdkhvUHJVTFUxeXdWWkJ1cGlacU1D?=
 =?utf-8?B?MDJpN0FNUjNYOWMwaWl3VW5JS0pYSFJzTTh0UEdyc3lXTkluY21HUXhBamlt?=
 =?utf-8?B?alp0ME9VL2tEcTlxYlJQeEhEL1pkYTgwVHIzN09iY0hvdm9ZeFcydE8vcDRo?=
 =?utf-8?B?UzZpVWZ0U0F3c2h1YmsyODdDTzMxSjV4NDFYK1dHVGpPTFdIZk5aV3l5QkUw?=
 =?utf-8?B?UEpCQ1ZlOXhYbDJwZzMyUXRFRzBqUVhUSWdScWRtdHFCbXZYcDM2K0oxOUxt?=
 =?utf-8?B?MjR0MnhKZnZSUi9XQzRWOTAzL2VVNHUxbG1TcitjRlJnRUVyTTRxM0RjRUlH?=
 =?utf-8?B?OHp3ZE9pVEppVllUb2ZTdm90U1lhT0M3NjJXMW8vQkFIakZlaXdyMUs0cllE?=
 =?utf-8?B?MEhFYlBjRkVBV2VUT1ZGRklOc0xISkVJU0xvbUdKd3dvd0d3b1JDNkNJRGxm?=
 =?utf-8?B?ai9NZHVkbjBiVjY5czQzMktOMzRRQmFUT3hiN2M0dDZONHFZWmJ3Z3RlTWlC?=
 =?utf-8?B?TU1TbEFWYzRCa3JYNU1iVUxRNUU1RkxvSE5zZTVqWXZMdUY1b05rMUFpTm1Y?=
 =?utf-8?B?K0pYRFhIaHhka3U4YWNGeitpbnhsTWJuSnRQUmRmU2RLNisyVExTdUd1bjBz?=
 =?utf-8?B?OS9HTDRWK3NzYkZBUU85VlMrUUpOSCswNm4wbnJiUzd5MFhxd0d5eElDMGJ0?=
 =?utf-8?B?ZklrWlM5TWszbnl0M0pHVVIzbFZPRWI5L2k1WGFpbjhOUG5NRmpZOWY3dDZY?=
 =?utf-8?B?Y0tQcjAvUWZ1aSt2VG5zTlBoZHFkZ3dFdXg3V0ZLcGVWMGhvMmxJWDVEcFJU?=
 =?utf-8?B?UElhVFVRckR5c1A2Rm9jZWJweWE4TThyZi9qTkhVV3FydzZmMGJZZVM4NUJX?=
 =?utf-8?B?R2VSeGpTWkkvbnlNWFpITnVBQVpncGJHQ1NXOWhyZitqTWM0OW5LYzNDU1pX?=
 =?utf-8?B?WUFoT1ZYRU1NOENLcnBrSHo2enhZcFFNellpWlF4ekhGeWpDdWF6UGZJOEti?=
 =?utf-8?B?cktlMWs5TmpZdGtFNjNSeW9mdzR1YzVGbFdhdEp6K3QzZm5nZHBBOHJpbXND?=
 =?utf-8?B?Zzk2VHRUNTVySW9TdjYzd0lKOWFKSzFKTUtJZlhHOTRFajFnRmRxemZtZzhm?=
 =?utf-8?B?YnhSODMyMDE0Mno5UUFGM0pXYXJkQjJIbzl2WHpybE5Gc09iYlpWL01iUnhF?=
 =?utf-8?B?OWdQZkI5RklramQzZ1JsdlJxUjRNUy9NOE9rS1JkUjVQdFg5dXNrYStRQ0Vj?=
 =?utf-8?B?cTd3RWhLNElTTGVXQk5BblFxSjZ1Q0hydk5zM2pnVFU1NG9mVThVNDZmcVZB?=
 =?utf-8?B?UzJTVU5lbVVob3dNMTJHaUI3VWowLzBVVzZPSFFiRHk5YzRmOUl2QVltNHln?=
 =?utf-8?B?Vk5UaWNxcUhFNmNtZUtUalZQVTQ4K2RnQkVuVGd5S1FQZFg2bzkxMUNmM2Ry?=
 =?utf-8?B?NTBVcDV1RXoyWEdQM3lMMlpGOU1EdzdPMkh4VWp1Mm1OZzgzTUtlTmtLOU56?=
 =?utf-8?B?NFNHUUhrVHZFSGQ0cG9LdHpTUm0rSTdRWG8vTzRkNlY3Y050SFZ3blQwOUJj?=
 =?utf-8?B?YUhKSDVUbzZxamxkU2l4Qm5XTFVKd3A0UWxXaEpVT0IvZ3FQWlh0Q2ZvMTZs?=
 =?utf-8?Q?SaflBMeoG3XRGmUYKZemZgV2rexweA=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <0E38C57B0F8AE047BAFC012A0C98D112@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB9542
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM1PEPF000252DB.eurprd07.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	3d9b24bc-42fa-4d6a-2da8-08dd92f37a83
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|14060799003|35042699022|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OHVheS9IakFELzFuR2NqT0JXVlEvUm1RM3dHMXd4UkZDKzVkTG51QWRjeDBX?=
 =?utf-8?B?ZUtZcDhFb0tyU0h2OCtqaXBBN0kxNlU4T1ltZjRkNG1Pd1JZT1dmRmlyaTFD?=
 =?utf-8?B?OGZDN21zdGJhS1BkNkVtY24ydlU2SWtoUEJjWTVhbzNoUFM2dHZ3Y0M3bnhW?=
 =?utf-8?B?MktuaEVFcHFJNENtZ1dsRERDTHRudW1lYWdOV1NGQ2h3ZFNkRW42RThGSWlq?=
 =?utf-8?B?VDdZTE8zdmR6MlN2Y0pQYStuOEtnQ1hNTnpxRVdTN0dhOUdrSFRIK1FpWWFk?=
 =?utf-8?B?dytBUlBxcmhmditHNGJBS0FtQUJocnpLbUlDbStpUUw2Q1FjUXpTTi9OMjhF?=
 =?utf-8?B?OUhWQVM1TE8xb2VOR2EwSlg3ZXkwSXVrRzZxZHpZUzcvUHJ1cDJ3NVRHakNN?=
 =?utf-8?B?WEYrVUlqQmphU1hMZzlDTnpIVG12bE80RS9xdlRvUTNpRXNyVXlsNVF0M2M2?=
 =?utf-8?B?T2pybHlYbG9RRkIyZUxwSDdYT2ZZcmh5b3NPb2VXeG5pNmxiVnU3RVU1cm8w?=
 =?utf-8?B?RlN5Q0JHaFY0bTl2REN1a2poRG9NRlBoNTVKRHFwcDJxcXlTU1JvUjVJK09t?=
 =?utf-8?B?Ny9mY0RrNFJ4SVUvZXJJN2RlVU1PNDhIQTU1bkdBRlhQdXZIb2VESE51QkNB?=
 =?utf-8?B?c3JkR2VESk1DMW9ZV0RJWlF3M3JjR2E0WHJ3blVRdm53ejU3SmI4TnV1bFZ3?=
 =?utf-8?B?RzFJdG9hQ3NRVEtHRmlGSmx3dnR5a1lSa0NpRDNMRkVPK3ZSYUZZS2R6QjVs?=
 =?utf-8?B?MnAxdzlqUE5jcEptaHl1Z3VFdHhUNXYwM2c1ZTVCcDUxaC82MmtNSURDUjdw?=
 =?utf-8?B?a0RCUjNGazIzam1tbk5MYlVicnB1NXRRWnJKVHovVEFPakhlVnZjOGJwNmtT?=
 =?utf-8?B?R3d1MEpoMThLR0x3d0lTbFROcjZYVzljL2JXMFQrdHpheStJV2hCbE9vclVn?=
 =?utf-8?B?NTVNTktSdThPRzVaM2xoaGRrWGl6QUkwYWMwL2xxbmRyQXZ0QXVPSHczb29F?=
 =?utf-8?B?cmw5Y3dmK05SV1MwN3FmYkdLZHMvVnUzT20zL2ZEVHQ0S2wvWmtkaEdkQTZB?=
 =?utf-8?B?N0FCelFNdUJXem5XNnNDM0RmaDZTQWRXUDBibFd4OFhkZ0lXSWdOUVB5c3Rx?=
 =?utf-8?B?MjV0Z1hmRHNmUkJnbVJPTFhMRE5aWFdsbnNZWjBjN1RLdUh5cUVVNVdEaEJs?=
 =?utf-8?B?ZmcybmJXOUxITnllRTBuTXFqSWt3bWhaRHVhUUJIOFRMaEJCTkhjcDBLZFl3?=
 =?utf-8?B?Nzl2VDM0OWgvakEzYlVjTjRUcFhsVzhva1Bwd0V5TDUvMXRiT0d5eHdydjIy?=
 =?utf-8?B?WlYwdFNoVVB4VUorSjBXYTNhSU81bmlWWUdmcGw1LzFvSDF4bzRDSEJVSmo3?=
 =?utf-8?B?K0UrZ3liM0hSeXZRam9VTzZVc3NnSE41Z05MUGdHZkc2KzlvT2s1eGgwTkJo?=
 =?utf-8?B?Wk5kZFpBMzc4Y1gvdDYwMC9lUmo1NGxYSGRnelVuMkkveWVPZXcvY2lad01y?=
 =?utf-8?B?aUJ1d05sZXgrM2ljTnFqWWY5K25QdUZEZWFqYlduYnJ3RGppMzU0SFdKZmF4?=
 =?utf-8?B?TW5hV08xd280L0YyRkIyb0F0b1RyWGJ1MEc3djFxaEhkUitOcjNjVFNEcWFh?=
 =?utf-8?B?OTZHd1dWRXExN1BBOGMwUC9kbEtvb3Qxc3d5andyeTNWbEJzRjlscnFrQlVi?=
 =?utf-8?B?OXlhMjZzZXdQRmgyNTlFRkVYcjVESCt5Mk85OWhJUnJVOXRyVHRpeWxUelRu?=
 =?utf-8?B?Z3YzUjFTQzZUeXFqT2pLK1pGdjFqdVBXVjZ2Z2FxY0ZCM2M4b1RLZFpuZHFE?=
 =?utf-8?B?ekFtY1B5dStGRVNmUU9mMXBLUGc4Sk9hNG9BajZDMEJWUytNLzlMalkveGlF?=
 =?utf-8?B?d3U3SXk2V1FWSWxRWWh6cGtzekxHRGkyV1Z5RnNDS081WGl4SGV6bFN6bmtS?=
 =?utf-8?B?Mm9ybDhxT2lwQTdZalVLU3Y4ZkJ6VE1FbGp6Vm5xNGczK2djU2NhaU9ESEhj?=
 =?utf-8?B?aC8zQmtyZGdqcHVKelFBaUZHeC9TZHBuakRkbkRCbTcwcXBTV0VNRnNtRmxl?=
 =?utf-8?Q?czNoZ1?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(14060799003)(35042699022)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2025 14:28:11.7804
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e98d77fa-afc7-458c-6dff-08dd92f38e4f
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:
	AM1PEPF000252DB.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8706

SGkgSnVsaWVuLA0KDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2FybTY0L21wdS9oZWFk
LlMgYi94ZW4vYXJjaC9hcm0vYXJtNjQvbXB1L2hlYWQuUw0KPj4gaW5kZXggNmQzMzZjYWZiYmFm
Li41OWRkYzQ2NTI2ZWIgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vYXJtNjQvbXB1L2hl
YWQuUw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2FybTY0L21wdS9oZWFkLlMNCj4+IEBAIC00MCw2
ICs0MCw5IEBAIEZVTkMoZW5hYmxlX2Jvb3RfY3B1X21tKQ0KPj4gICAgICBtcnMgICB4NSwgTVBV
SVJfRUwyDQo+PiAgICAgIGFuZCAgIHg1LCB4NSwgI05VTV9NUFVfUkVHSU9OU19NQVNLDQo+PiAg
KyAgICBsZHIgICB4MCwgPW1heF9tcHVfcmVnaW9ucw0KPj4gKyAgICBzdHJiICB3NSwgW3gwXQ0K
PiANCj4gQmVsb3cgeW91IGFyZSBoYW5kbGluZyBjYWNoZSBpbnZhbGlkYXRpb24gd2hlbiB3cml0
aW5nIHRvIHRoZSBiaXRtYXAuIEJ1dCB5b3UgZG9uJ3QgZG8gb25lIGhlcmUuIElzIHRoaXMganVz
dCBhbiBvdmVybG9vaz8NCg0Kb2ggeWVzLCBvdmVybG9va2VkLCB0aGFua3MNCg0KPj4gDQo+PiBk
aWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2JpdG1hcC1vcC5pbmMgYi94ZW4v
YXJjaC9hcm0vaW5jbHVkZS9hc20vYml0bWFwLW9wLmluYw0KPj4gbmV3IGZpbGUgbW9kZSAxMDA2
NDQNCj4+IGluZGV4IDAwMDAwMDAwMDAwMC4uZWE3YzhhYmJmNmYwDQo+PiAtLS0gL2Rldi9udWxs
DQo+PiArKysgYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vYml0bWFwLW9wLmluYw0KPj4gQEAg
LTAsMCArMSw2NyBAQA0KPj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9u
bHkgKi8NCj4+ICsNCj4+ICsvKg0KPj4gKyAqIFNldHMgYSBiaXQgaW4gYSBiaXRtYXAgZGVjbGFy
ZWQgYnkgREVDTEFSRV9CSVRNQVAsIHN5bWJvbCBuYW1lIHBhc3NlZCB0aHJvdWdoDQo+PiArICog
Yml0bWFwX3N5bWJvbC4NCj4+ICsgKg0KPj4gKyAqIGJpdG1hcF9zZXRfYml0OiAgICAgIHN5bWJv
bCBvZiB0aGUgYml0bWFwIGRlY2xhcmVkIGJ5IERFQ0xBUkVfQklUTUFQDQo+PiArICogYml0OiAg
ICAgICAgICAgICAgICAgYml0IG51bWJlciB0byBiZSBzZXQgaW4gdGhlIGJpdG1hcA0KPj4gKyAq
IHRtcDEtdG1wNDogICAgICAgICAgIHRlbXBvcmFyeSByZWdpc3RlcnMgdXNlZCBmb3IgdGhlIGNv
bXB1dGF0aW9uDQo+PiArICoNCj4+ICsgKiBQcmVzZXJ2ZXMgYml0Lg0KPj4gKyAqIE91dHB1dDoN
Cj4+ICsgKiAgdG1wMTogQWRkcmVzcyBvZiB0aGUgd29yZCBjb250YWluaW5nIHRoZSBjaGFuZ2Vk
IGJpdC4NCj4gDQo+IElmIHRoZSByZWdpc3RlciBpcyB1c2VkIGZvciBvdXRwdXQsIHRoZW4gSSB0
aGluayBpdCBuZWVkcyBhIGJldHRlciBuYW1lLg0KPiBCdXQgbG9va2luZyBhdCB0aGUgY29kZSwg
aXQgaXMgbm90IGVudGlyZWx5IGNsZWFyIGhvdyB0aGUgb3V0cHV0IHdpbGwgYmUgdXNlZC4NCg0K
U28gY3VycmVudGx5IGl0IHdpbGwgZ2l2ZSB0aGUgYWRkcmVzcyBvZiB0aGUgd29yZCBjb250YWlu
aW5nIHRoZSBiaXQsIHNvIHRoYXQgd2Ugd2lsbA0KcGFzcyBpdCB0byB0aGUgaW52YWxpZGF0ZSBj
YWNoZSBmdW5jdGlvbi4NCg0KPiANCj4+ICsgKiBDbG9iYmVyczogdG1wMSwgdG1wMiwgdG1wMywg
dG1wNC4NCj4+ICsgKi8NCj4+ICsubWFjcm8gYml0bWFwX3NldF9iaXQgYml0bWFwX3N5bWJvbCwg
Yml0LCB0bXAxLCB0bXAyLCB0bXAzLCB0bXA0DQo+ID4gKyAgICBhZHJfbCAgIFx0bXAxLCBcYml0
bWFwX3N5bWJvbD4gKyAgICBtb3YgICAgIFx0bXAyLCAjKEJZVEVTX1BFUl9MT05HIC0gMSkNCj4+
ICsgICAgbXZuICAgICBcdG1wMiwgXHRtcDINCj4+ICsgICAgbHNyICAgICBcdG1wMywgXGJpdCwg
IzMNCj4+ICsgICAgYW5kICAgICBcdG1wMiwgXHRtcDMsIFx0bXAyDQo+PiArICAgIGFkZCAgICAg
XHRtcDEsIFx0bXAxLCBcdG1wMiAgICAgICAgICAgICAgICAgLyogYml0bWFwX3N5bWJvbCArIChi
aXQvQklUU19QRVJfTE9ORykqQllURVNfUEVSX0xPTkcgKi8NCj4gDQo+IFN0eWxlOiBtaXNzaW5n
IHNvbWUgc3BhY2VzLg0KPiANCj4gQnV0IGlzIHRoZSBjb21tZW50IGV4cGxhaW5pbmcgdGhlIGxv
Z2ljIGFib3ZlPyBJZiBzbywgSSB0aGluayBJIHdvdWxkIHB1dCBpdCByaWdodCBhdCB0aGUgYmVn
aW5uaW5nIHRvIG1ha2UgZWFzaWVyIHRvIHVuZGVyc3RhbmQgdGhlIGxvZ2ljLiBJIHdvdWxkIGFs
c28gY29uc2lkZXIgdG8gc3BsaXQgaW4gc21hbGxlciBjb21tZW50cyBvbiBlYWNoIGxpbmUgZS5n
LjoNCj4gDQo+ICogLi4uID0gLi4uICsgLi4uDQoNCk9rIEnigJlsbCBkbyBhIGxpbmUgYnkgbGlu
ZSBleHBsYW5hdGlvbg0KPj4gDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUv
YXNtL21wdS9yZWdpb25zLmluYyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9tcHUvcmVnaW9u
cy5pbmMNCj4+IGluZGV4IDQ3ODY4YTE1MjY2Mi4uYmEzODIxM2ZmZmYxIDEwMDY0NA0KPj4gLS0t
IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL21wdS9yZWdpb25zLmluYw0KPj4gKysrIGIveGVu
L2FyY2gvYXJtL2luY2x1ZGUvYXNtL21wdS9yZWdpb25zLmluYw0KPj4gQEAgLTEsMTQgKzEsNDIg
QEANCj4+ICAvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+PiAg
KyNpbmNsdWRlIDxhc20vYml0bWFwLW9wLmluYz4NCj4+ICAjaW5jbHVkZSA8YXNtL21wdS5oPg0K
Pj4gICNpbmNsdWRlIDxhc20vc3lzcmVncy5oPg0KPj4gICAgLyogQmFja2dyb3VkIHJlZ2lvbiBl
bmFibGUvZGlzYWJsZSAqLw0KPj4gICNkZWZpbmUgU0NUTFJfRUx4X0JSICAgIEJJVCgxNywgVUwp
DQo+PiAgKyNkZWZpbmUgUkVHSU9OX0RJU0FCTEVEX1BSTEFSICAgMHgwMCAgICAvKiBOUz0wIEFU
VFI9MDAwIEVOPTAgKi8NCj4+ICAjZGVmaW5lIFJFR0lPTl9OT1JNQUxfUFJMQVIgICAgIDB4MGYg
ICAgLyogTlM9MCBBVFRSPTExMSBFTj0xICovDQo+PiAgI2RlZmluZSBSRUdJT05fREVWSUNFX1BS
TEFSICAgICAweDA5ICAgIC8qIE5TPTAgQVRUUj0xMDAgRU49MSAqLw0KPj4gICsjZGVmaW5lIFBS
TEFSX0VMeF9FTiAgICAgICAgICAgIDB4MQ0KPj4gKw0KPj4gKyNpZmRlZiBDT05GSUdfQVJNXzY0
DQo+PiArI2RlZmluZSBYRU5fTVBVTUFQX0VOVFJZX1NISUZUICAweDQgICAgIC8qIDE2IGJ5dGUg
c3RydWN0dXJlICovDQo+PiArDQo+PiArLm1hY3JvIHN0b3JlX3BhaXIgcmVnMSwgcmVnMiwgZHN0
DQo+PiArICAgIHN0cCBccmVnMSwgXHJlZzIsIFtcZHN0XQ0KPj4gKy5lbmRtDQo+PiArDQo+PiAr
Lm1hY3JvIGludmFsaWRhdGVfZGNhY2hlX29uZSByZWcNCj4+ICsgICAgZGMgaXZhYywgXHJlZw0K
Pj4gKy5lbmRtDQo+PiArDQo+PiArI2Vsc2UNCj4+ICsjZGVmaW5lIFhFTl9NUFVNQVBfRU5UUllf
U0hJRlQgIDB4MyAgICAgLyogOCBieXRlIHN0cnVjdHVyZSAqLw0KPj4gKw0KPj4gKy5tYWNybyBz
dG9yZV9wYWlyIHJlZzEsIHJlZzIsIGRzdA0KPj4gKyAgICBub3ANCj4gDQo+IENhbiB3ZSB1c2Ug
YSBmdW5jdGlvbiB0aGF0IHdpbGwgdHJpZ2dlciBhIGZhdWx0PyBTbyB3ZSB3aWxsIHJlbWVtYmVy
IHRoaXMgd2lsbCBuZWVkZWQgdG8gYmUgdXBkYXRlZC4gTWF5YmUgcmUtdXNlIHRoZSBCVUdfT1BD
T0RFPw0KDQpTdXJlLCBJ4oCZbGwgbG9vayBpbnRvIGl0DQoNCj4gDQo+PiArLmVuZG0NCj4+ICsN
Cj4+ICsubWFjcm8gaW52YWxpZGF0ZV9kY2FjaGVfb25lIHJlZw0KPj4gKyAgICBub3ANCj4gDQo+
IFNhbWUgaGVyZS4NCj4gDQo+PiArLmVuZG0NCj4gPiArPiArI2VuZGlmDQo+PiArDQo+PiAgLyoN
Cj4+ICAgKiBNYWNybyB0byBwcmVwYXJlIGFuZCBzZXQgYSBFTDIgTVBVIG1lbW9yeSByZWdpb24u
DQo+PiAgICogV2Ugd2lsbCBhbHNvIGNyZWF0ZSBhbiBhY2NvcmRpbmcgTVBVIG1lbW9yeSByZWdp
b24gZW50cnksIHdoaWNoDQo+PiBAQCAtNTYsNiArODQsMjcgQEANCj4+ICAgICAgaXNiDQo+PiAg
ICAgIFdSSVRFX1NZU1JFR19BU00oXHByYmFyLCBQUkJBUl9FTDIpDQo+PiAgICAgIFdSSVRFX1NZ
U1JFR19BU00oXHBybGFyLCBQUkxBUl9FTDIpDQo+PiArDQo+PiArICAgIC8qIExvYWQgcGFpciBp
bnRvIHhlbl9tcHVtYXAgYW5kIGludmFsaWRhdGUgY2FjaGUgKi8NCj4gDQo+IFRvIGNvbmZpcm0g
bXkgdW5kZXJzdGFuZGluZywgeGVuX21wdW1hcCBpcyBwYXJ0IG9mIHRoZSBsb2FkZWQgYmluYXJ5
LiBTbyB3ZSBleHBlY3QgdGhlIGJvb3Rsb2FkZXIgdG8gaGF2ZSBjbGVhbiB0aGUgY2FjaGUgZm9y
IHVzLiBUaGVyZWZvcmUsIHdlDQo+IG9ubHkgbmVlZCB0byBpbnZhbGlkYXRlIHRoZSBlbnRyaWVz
IGFmdGVyd2FyZHMuIElzIGl0IGNvcnJlY3Q/DQoNCnllcyB4ZW5fbXB1bWFwIGlzIHBhcnQgb2Yg
dGhlIGJpbmFyeSwgYXJlIHlvdSBzdWdnZXN0aW5nIHdlIHNob3VsZCB1c2UgY2xlYW4gYW5kIGlu
dmFsaWRhdGUgaGVyZT8gU28gZm9yIGV4YW1wbGUgYm9vdC13cmFwcGVyLWFhcmNoNjQgaXMgbm90
DQpjbGVhbmluZyB0aGUgY2FjaGUuDQoNCj4gDQo+PiArICAgIGFkcl9sIFxiYXNlLCB4ZW5fbXB1
bWFwDQo+PiArICAgIGFkZCAgIFxiYXNlLCBcYmFzZSwgXHNlbCwgTFNMICNYRU5fTVBVTUFQX0VO
VFJZX1NISUZUDQo+PiArICAgIHN0b3JlX3BhaXIgXHByYmFyLCBccHJsYXIsIFxiYXNlDQo+IA0K
PiBJIHRoaW5rIHlvdSB3YW50IGEgY29tbWVudCBvbiB0b3Agb2YgcHJfdCB0byBtZW50aW9uIHRo
ZSBzdHJ1Y3R1cmUNCj4gd2lsbCBub3QgY2hhbmdlZCBhbmQNCg0KY2FuIHlvdSBleHBsYWluIGJl
dHRlciB0aGlzIHBhcnQsIHdoYXQgc2hvdWxkIEkgd3JpdGUgb24gdG9wIG9mIHRoZSB0eXBlZGVm
IHN0cnVjdCB7Li4ufSBwdF90Pw0KDQo+IA0KPj4gKyAgICBpbnZhbGlkYXRlX2RjYWNoZV9vbmUg
XGJhc2UNCj4gDQo+IFRoaXMgd2lsbCBpbnZhbGlkYXRlIGEgc2luZ2xlIGxpbmUgaW4gdGhlIGRh
dGEgY2FjaGUuIFRoZSBzaXplIGRlcGVuZHMgb24gdGhlIEhXLCBidXQgdHlwaWNhbGx5IGl0IHdp
bGwgYmUgNjQgLSAxMjggYnl0ZXMuIERvIHdlIGhhdmUgYW55IGNoZWNrDQo+IHRoYXQgd2lsbCBj
b25maXJtIHRoZSBkYXRhIHdpbGwgZml0IGluIGFuIGNhY2hlIGxpbmU/DQoNCllvdSBhcmUgcmln
aHQsIHNvIHdlIGFyZSBnb25uYSB3cml0ZSAxNiBieXRlcyBhdCBtb3N0IGZvciBBcm02NCBhbmQg
KGZvciBub3cpIDggYnl0ZXMgZm9yIEFybTMyLCBzbyBJIHRoaW5rIHdlIHdpbGwgYmUgd2F5IGJl
bG93IDY0IGJ5dGVzLA0Kc2hhbGwgd2UgaGF2ZSBhIEJVSUxEX0JVR19PTiBpbnNpZGUgYnVpbGRf
YXNzZXJ0aW9ucygpIGluIGFybS9tcHUvbW0uYyB0byBjaGVjayBzaXplb2YocHJfdCkgPD0gNjQ/
DQoNCj4gDQo+PiArDQo+PiArICAgIC8qIFNldC9jbGVhciB4ZW5fbXB1bWFwX21hc2sgYml0bWFw
ICovDQo+PiArICAgIHRzdCAgIFxwcmxhciwgI1BSTEFSX0VMeF9FTg0KPj4gKyAgICBibmUgICAy
Zg0KPj4gKyAgICAvKiBSZWdpb24gaXMgZGlzYWJsZWQsIGNsZWFyIHRoZSBiaXQgaW4gdGhlIGJp
dG1hcCAqLw0KPj4gKyAgICBiaXRtYXBfY2xlYXJfYml0IHhlbl9tcHVtYXBfbWFzaywgXHNlbCwg
XGJhc2UsIFxsaW1pdCwgXHByYmFyLCBccHJsYXINCj4+ICsgICAgYiAgICAgM2YNCj4+ICsNCj4+
ICsyOg0KPj4gKyAgICAvKiBSZWdpb24gaXMgZW5hYmxlZCwgc2V0IHRoZSBiaXQgaW4gdGhlIGJp
dG1hcCAqLw0KPj4gKyAgICBiaXRtYXBfc2V0X2JpdCB4ZW5fbXB1bWFwX21hc2ssIFxzZWwsIFxi
YXNlLCBcbGltaXQsIFxwcmJhciwgXHBybGFyDQo+PiArDQo+PiArMzoNCj4+ICsgICAgaW52YWxp
ZGF0ZV9kY2FjaGVfb25lIFxiYXNlDQo+IA0KPiBZb3Ugd2FudCB0byBhIGNvbW1lbnQgdG8gZXhw
bGFpbiB3aGF0IHRoaXMgaW52YWxpZGF0ZSBkb2VzLiBBRkFJQ1QsIHRoaXMgaXMgZm9yIHRoZSBi
aXRtYXAuIEJ1dCBnaXZlbiB0aGUgYml0bWFwIHdpbGwgYmUgdHlwaWNhbGx5IHNtYWxsLCB3b3Vs
ZG4ndCBpdCBiZXR0ZXIgdG8gZG8gaXQgaW4gb25lIGdvIGF0IHRoZSBlbmQ/DQoNClllcyB0aGlz
IGludmFsaWRhdGUgaXMgYSBiaXQgb3ZlcmtpbGwgYmVjYXVzZSBpdCB3aWxsIGludmFsaWRhdGUg
NjQtMTI4IGJ5dGVzIHN0YXJ0aW5nIGZyb20gdGhlIGFkZHJlc3Mgb2YgdGhlIGxhc3QgY2hhbmdl
ZCB3b3JkIHdoZXJlIHRoZSBiaXQgd2FzLg0KDQpTaG91bGQgSSBpbnZhbGlkYXRlIGV2ZXJ5dGhp
bmcgb3V0c2lkZSB0aGlzIG1hY3JvLCBpbnNpZGUgZW5hYmxlX2Jvb3RfY3B1X21tIGluIGFybTY0
L21wdS9oZWFkLlMgaW5zdGVhZD8NCg0KPiANCj4gU2FtZSBjb21tZW50IGhlcmUuDQo+IA0KPj4g
Kw0KPj4gICAgICBkc2IgICBzeQ0KPj4gICAgICBpc2INCj4+ICBkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gvYXJtL21wdS9tbS5jIGIveGVuL2FyY2gvYXJtL21wdS9tbS5jDQo+PiBpbmRleCAwN2M4OTU5
ZjRlZTkuLmVlMDM1YTU0Yjk0MiAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9tcHUvbW0u
Yw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL21wdS9tbS5jDQo+PiBAQCAtNyw5ICs3LDI1IEBADQo+
PiAgI2luY2x1ZGUgPHhlbi9tbS5oPg0KPj4gICNpbmNsdWRlIDx4ZW4vc2l6ZXMuaD4NCj4+ICAj
aW5jbHVkZSA8eGVuL3R5cGVzLmg+DQo+PiArI2luY2x1ZGUgPGFzbS9tcHUuaD4NCj4+ICAgIHN0
cnVjdCBwYWdlX2luZm8gKmZyYW1lX3RhYmxlOw0KPj4gICsvKiBNYXhpbXVtIG51bWJlciBvZiBz
dXBwb3J0ZWQgTVBVIG1lbW9yeSByZWdpb25zIGJ5IHRoZSBFTDIgTVBVLiAqLw0KPj4gK3VpbnQ4
X3QgX19yb19hZnRlcl9pbml0IG1heF9tcHVfcmVnaW9uczsNCj4+ICsNCj4+ICsvKg0KPj4gKyAq
IEJpdG1hcCB4ZW5fbXB1bWFwX21hc2sgaXMgdG8gcmVjb3JkIHRoZSB1c2FnZSBvZiBFTDIgTVBV
IG1lbW9yeSByZWdpb25zLg0KPj4gKyAqIEJpdCAwIHJlcHJlc2VudHMgTVBVIG1lbW9yeSByZWdp
b24gMCwgYml0IDEgcmVwcmVzZW50cyBNUFUgbWVtb3J5DQo+PiArICogcmVnaW9uIDEsIC4uLiwg
YW5kIHNvIG9uLg0KPj4gKyAqIElmIGEgTVBVIG1lbW9yeSByZWdpb24gZ2V0cyBlbmFibGVkLCBz
ZXQgdGhlIGFjY29yZGluZyBiaXQgdG8gMS4NCj4+ICsgKi8NCj4+ICtERUNMQVJFX0JJVE1BUCh4
ZW5fbXB1bWFwX21hc2ssIE1BWF9NUFVfUkVHSU9OX05SKSBcDQo+PiArICAgIF9fc2VjdGlvbigi
LmRhdGEucGFnZV9hbGlnbmVkIik7DQo+IA0KPiBXaHkgZG9lcyB0aGlzIG5lZWQgdG8gYmUgcGFn
ZV9hbGlnbmVkPw0KDQpJIHNlZSBmcm9tIHRoZSBsaW5rZXIgZmlsZSB0aGF0IHRoaXMgc2VjdGlv
biBpcyBhbGlnbmVkIHRvIFNNUF9DQUNIRV9CWVRFUywgd2hpY2ggaXMgTDFfQ0FDSEVfQllURVMN
CmZvciBBcm0sIGJlY2F1c2Ugd2UgYXJlIHVzaW5nIHRoZSBpbnZhbGlkYXRlIGNhY2hlIEkgd2Fz
IHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgaXTigJlzIGJldHRlciB0byBoYXZlIGl0DQphbGln
bmVkIG9uIHRoZSBjYWNoZSBsaW5lDQoNCj4gDQo+PiArDQo+PiArLyogRUwyIFhlbiBNUFUgbWVt
b3J5IHJlZ2lvbiBtYXBwaW5nIHRhYmxlLiAqLw0KPj4gK3ByX3QgX19zZWN0aW9uKCIuZGF0YS5w
YWdlX2FsaWduZWQiKSB4ZW5fbXB1bWFwW01BWF9NUFVfUkVHSU9OX05SXTsNCj4gDQo+IEkgZ3Vl
c3MgZm9yIHRoaXMgb25lIHRoaXMgaXMgbWFuZGF0ZWQgYnkgdGhlIEhXPw0KDQpzYW1lIHJlYXNv
biBhYm92ZSwgbm8gb3RoZXIgcmVhc29uIChJ4oCZbSBhd2FyZSBvZikuDQoNCkNoZWVycywNCkx1
Y2ENCg0K


From xen-devel-bounces@lists.xenproject.org Wed May 14 14:32:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 14:32:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984361.1370499 (Exim 4.92)
	(envelope-from )
	id 1uFD9S-0002qi-Eh; Wed, 14 May 2025 14:32:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984361.1370499; Wed, 14 May 2025 14:32:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFD9S-0002qb-B6; Wed, 14 May 2025 14:32:06 +0000
Received: by outflank-mailman (input) for mailman id 984361;
 Wed, 14 May 2025 14:32:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFD9R-0002qV-8I
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 14:32:05 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3473e21f-30d0-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 16:32:04 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad2216ef31cso895491566b.1
 for ; Wed, 14 May 2025 07:32: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
 a640c23a62f3a-ad238b66188sm764781066b.173.2025.05.14.07.32.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 07:32: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" 
X-Inumbo-ID: 3473e21f-30d0-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747233123; x=1747837923; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=AXiMn2waGFGE2aCtWgcKf/2y80/Pq5qkn9qEzVeTGXQ=;
        b=BDnKn4U7Ih4bofytPSVBFC0AFG0mQ0pLcWJHDqipkl9mKfuw5jar0isAWTo4ImkfeB
         w9bZV3LM0mreRaIYNlF/H18n8bDgtH/JOT5QiFWKoQ4ezx5P/LyDe3KRvNv7Ll4fBTtL
         iYHr5Jqa4Y8y9/Kzq5wX+6pC4w3zLztJEbMoRm6AZn8TLAyIemETATRBOKdNR/ImNZCj
         WRPo480Il+kUWzjkDxSHCHF6YxOgvDLX3kozMCjmq0byxQWBlxojtsk9b5jRm+YrS0xk
         ADyQEkx2Ngp4tTFNcTZFc2Jj4Ks3cnj6BwBhl4NseIQEGnhkssumZO6fYp5pIXLn466w
         u84A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747233123; x=1747837923;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AXiMn2waGFGE2aCtWgcKf/2y80/Pq5qkn9qEzVeTGXQ=;
        b=QUa4NCFefwvqT1XYr6e4aZBedOXRnhZWpE8YdO69nzoMjcOKqb8oWK0khdMo1sw5cb
         rh0FMnKOGwM2YMqOCg1T8Y+heirCJfJGVSJtxrBrxduIslGhGXCWMbYb1wyhVYCfVf7U
         NPyfcnLIOK9ivuhLEod7K03Eml+/PBuL/GNLpLDAbZ6PbP3A440WQw/XprZfvVtNZrU/
         b9F+eDLLGj/XCHSR6+sCIWfBZuh7jIGK1jxNjdspyrk2+WnS8V3/KS4DOSGiE06rZxIC
         uTds7m6wCrmAN1+lLjH3LHZ4aXtKTlJVZYOjwhHfrOsvgU9vPwz+oCncxE1OXKZaQO/Z
         agLA==
X-Forwarded-Encrypted: i=1; AJvYcCU/th0RUZeSotq9xlhn4B/7f7vPtSECgvnaBVMEnbMI5XNQH6uIPPeXQM2GPu870qy7j53Hn1hWfuY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YySEE9pqeYo4Bx5gxDPBqMDgG4LMMDqL1ME/gtMh0r+FxNxVOpZ
	ogjvJoI0D8XzycxNL+2ujVNl32M78zRk4zgT5Djryv3CBJ947LRB5RmX0e7Weg==
X-Gm-Gg: ASbGnctxJpcaUQ7JpBJj8kkKAdV71iL9meyt3E/U7r4ytQTd2U2FQXPrjTxSQYVEH3W
	a5GLIWd/EjTsH4nwO72oZ0+1wHD6HgelGz1f7dwg9EST37M52/zGVjqchCJ6+EwODyINtJlukBt
	FevUlrelcVj+ByQXEULn/tvGgOZYp5YCunIqYrKSNuX5j6xFfYSIKKVWmyxWDgmm3qiFrnesmic
	Dw7y5PgklUniM1Mn5Aouj7Xdqkjjq38p0TOGUgodZpuL2Y8y7QgPD2lh7b8UZsWwcvNLNN/UPx6
	b3K2+uSbzqXabftgY2FYf7gKlpsf7MMN5QF+Qv2RX0XeZgst+hXQzNucJNtBlS+HRDTuG4T7e84
	owTYgAirzXqrTXfrG/lr/GoidAf0XSe2Jo7Oo
X-Google-Smtp-Source: AGHT+IEq9yKSJ93qAmMcKCd+hUSc8APMXaH2ruSUrBpApV1rrvO+RBRbQBc00MbRJDzdxsDXqB4Kng==
X-Received: by 2002:a17:907:d40d:b0:ad2:40ee:5e26 with SMTP id a640c23a62f3a-ad4f70f62camr360266566b.4.1747233123566;
        Wed, 14 May 2025 07:32:03 -0700 (PDT)
Message-ID: <0fbe380e-2011-4238-9847-a007c754af6f@suse.com>
Date: Wed, 14 May 2025 16:32:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/16] xen/riscv: add ioremap_*() variants using
 ioremap_attr()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <0258c1ac04a73b7d3f9f849507539a329b2998e3.1746530883.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: <0258c1ac04a73b7d3f9f849507539a329b2998e3.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> @@ -583,3 +584,36 @@ void *__init arch_vmap_virt_end(void)
>  {
>      return (void *)(VMAP_VIRT_START + VMAP_VIRT_SIZE);
>  }
> +
> +static void *ioremap_attr(paddr_t start, size_t len, pte_attr_t attributes)
> +{
> +    mfn_t mfn = _mfn(PFN_DOWN(start));
> +    unsigned int offs = start & (PAGE_SIZE - 1);
> +    unsigned int nr = PFN_UP(offs + len);
> +    void *ptr = __vmap(&mfn, nr, 1, 1, attributes, VMAP_DEFAULT);
> +
> +    if ( ptr == NULL )
> +        return NULL;
> +
> +    return ptr + offs;
> +}
> +
> +void __iomem *ioremap_nocache(paddr_t start, size_t len)
> +{
> +    return ioremap_attr(start, len, PAGE_HYPERVISOR_NOCACHE);
> +}

Why do you need both this and ...

> +void __iomem *ioremap_cache(paddr_t start, size_t len)
> +{
> +    return ioremap_attr(start, len, PAGE_HYPERVISOR);
> +}
> +
> +void __iomem *ioremap_wc(paddr_t start, size_t len)
> +{
> +    return ioremap_attr(start, len, PAGE_HYPERVISOR_WC);
> +}
> +
> +void *ioremap(paddr_t pa, size_t len)
> +{
> +    return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
> +}

... this? And why's the 1st parameter named differently for this last
one? Can't they all be in sync in this regard?

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 14:36:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 14:36:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984371.1370510 (Exim 4.92)
	(envelope-from )
	id 1uFDDs-0003Q7-VO; Wed, 14 May 2025 14:36:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984371.1370510; Wed, 14 May 2025 14:36: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 1uFDDs-0003Q0-RN; Wed, 14 May 2025 14:36:40 +0000
Received: by outflank-mailman (input) for mailman id 984371;
 Wed, 14 May 2025 14:36:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFDDr-0003Pu-BN
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 14:36:39 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d7efb414-30d0-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 16:36:38 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad1f6aa2f84so218940266b.0
 for ; Wed, 14 May 2025 07:36: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
 a640c23a62f3a-ad2192c8ac2sm946663666b.27.2025.05.14.07.36.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 07:36:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d7efb414-30d0-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747233398; x=1747838198; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=BXLcGL1xN+qlBvUwYYBOUGEDXze3nPBsHdQ0+6HdSqU=;
        b=CnLQVW2qJtTCYZDxZ7YoIU3UN4njQBzVU79cgRjW86TPhnigN/D5bIVLXLtOYpUNR8
         PUcwnMp7mOnihz69G9Z0PylY2WG3w763TicsZkcYzdMi2l0bQlysxHz1jblwvLon5GZK
         IIAvOLpD9F36czVJLJ46WbbmUrSlwit5R0jx4EhDeIHqci3Wy34DC1341WtI7lxK9EBN
         W4FtQUw7WUIRDTKjdz+tG0UI+JRsK5CPkkb2ymM6o6wNpLUdX1Jq66yAFJoPSuoXBtdh
         I/ByKxm23PjyByJmx5ZW9apjj6MEnCO7PYVlpWVkbTe0Hs0yWv3yu16iBcSEoyCCHQv1
         Er0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747233398; x=1747838198;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BXLcGL1xN+qlBvUwYYBOUGEDXze3nPBsHdQ0+6HdSqU=;
        b=HVRNRKL0MXwREzhBR5Gki0307+IaebC+Qf8D7vJZ6GgqQTA2MD9tKHLZ71hwxSNRi7
         /kzyc62YQeDYPneeGC1hPRcr67GqpQQmKf9TCnStGo53h0e3NOY6vZ2xmEbXo4Vypq+B
         aTFrGWzZYoBm7hgDPoxMhMp/GlLy3/WYQjL0rQybR01e+AAQbrVQqSKXEaZ2cGohJcT6
         leLqInmowgAwzqw3v1+QlJ3VIwtGgEBreZvNwn/HEV4bOZt0BxrUro3d0cz8+vzYXOOJ
         lA5ILkps3dLhyrmjEd2Oub+9mKNZmUqOLgGVEHh6tZmK2ZOR4abjsseUX0vOj90rO3bg
         NvAA==
X-Forwarded-Encrypted: i=1; AJvYcCXxHiNlk9pFgLCKE8Zz5HFgyG0pRIMETPuPCTioaXVgPcspD4P2Z+WgQC+hmAci2gJ3NAhPW3rKny8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhjCEK/3VZaLLObOFbY9ZETXI2vpnTXzyFjo0L9nxMAnKPiEYa
	FsDQ0mK5P8qSfh4vm/2uFDjswCkrZUm9UHlXB2S+Mk31ZF+GqTZYx+PduXScAQ==
X-Gm-Gg: ASbGncv47KzJnM69D98tv394mAzLgkDufx8uf/Aj82RWrTxJtG+0nu/y/yayKaf/Pt0
	Oj/wEcV8gccO8VOle4WdthCqY0VSvXZkB7424naCoRkTRfZkxZB4DEz+SH296jJ73HP//FGXY+Q
	2rWDm2yModX3RTRNxawFYCQKepFRs1B1Z6TJnZ25gFbeObxX1vvE9UKnCfo9cyAs/wJfZ2u/MeL
	+prW5qGl4iMi7/ZujoP+Iyb2ZKRpZ1URekd2TVPMJjQ58jpDBQ/FYW5779rTMUahJRyH/AqFb5o
	X+pNb1MTkIyyC1L1IKvTftPQ38x/Itf5bMFk6Y4N3W5/qSgPp3HCvL9L7pzFq1s5WHgQyvLHH83
	JbCjDmEdkisdak9iCvFPp8G0kiUGKU6pdg9bt
X-Google-Smtp-Source: AGHT+IG5s5wU8+rfC66N5yXQmElbW7RsDukJ63d+Rn2X7RATkCHJbDwHHkaJWwAY9O7AAwAnqhyMKw==
X-Received: by 2002:a17:907:2ce4:b0:ad2:2f9f:d4e6 with SMTP id a640c23a62f3a-ad4d4cd6734mr851506466b.5.1747233397885;
        Wed, 14 May 2025 07:36:37 -0700 (PDT)
Message-ID: <74c6872a-7221-4656-8655-16b53f9b2bd7@suse.com>
Date: Wed, 14 May 2025 16:36:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/16] xen/asm-generic: introduce asm-generic/irq-dt.h
To: Oleksii Kurochko 
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: 
 <35c68e57e5348c6610e030890802e967f6be4230.1746530883.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: <35c68e57e5348c6610e030890802e967f6be4230.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> Introduce defintions of IRQ_TYPE_* which correspond to the Xen internal
> representation of the IRQ types and make them the same asthe existing
> device tree defintions for convenience.
> 
> These defines are going to be re-used, at least, by RISC-V architecture.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 

Assuming an Arm ack would arrive, this looks like it's independent of the
earlier patches, and hence could go in right away?

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 14:43:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 14:43:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984379.1370519 (Exim 4.92)
	(envelope-from )
	id 1uFDJw-00057F-Ha; Wed, 14 May 2025 14:42:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984379.1370519; Wed, 14 May 2025 14:42: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 1uFDJw-000578-F1; Wed, 14 May 2025 14:42:56 +0000
Received: by outflank-mailman (input) for mailman id 984379;
 Wed, 14 May 2025 14:42:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFDJv-000572-5W
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 14:42:55 +0000
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com
 [2607:f8b0:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b4c258bf-30d1-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 16:42:49 +0200 (CEST)
Received: by mail-pl1-x62b.google.com with SMTP id
 d9443c01a7336-22d95f0dda4so79415085ad.2
 for ; Wed, 14 May 2025 07:42:49 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-22fc7546b48sm100735775ad.30.2025.05.14.07.42.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 07:42: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" 
X-Inumbo-ID: b4c258bf-30d1-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747233768; x=1747838568; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=/WoDEQKYgW7h3xnKILE8E0cz6YzU9mr4wqOGsmFK9dQ=;
        b=o2RkTSbFu0HKFpSy0dBFHaS2Qs4fy53xLgJ2+JgSi4oNduJogqPSDw18eRww/kHfev
         lrgmZpWItigK8R4rLvgnY+9Y/24zCPr8A//MrImcLqMP6cgaewR6HuXcRxfJYNJPgSxy
         w6Hx8IC+utCBSNW/mD7lytXpkZJaWia79NePA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747233768; x=1747838568;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=/WoDEQKYgW7h3xnKILE8E0cz6YzU9mr4wqOGsmFK9dQ=;
        b=Zy5wUkZVSGy+rJgKKzSkqRQc12/hovr1Ewj30igIOOhRhy+NVaBIAVu8eq9cOWDZ5v
         yACYI5ssItugu+rJcEFXcbkr9CJKLavXuPULMI7IqrANQqbSagiDibr3QeZ0e+Sh4Yyq
         3ZKKaZEWOvniYfnxl8fekp7vJhfvwIN+ZKmKsXyQd8y1+MSx8NEjWobhEDO7aPrcKNTS
         gomRDo4KB2BqAhB4GHa7YYtBnN3IXuvHnTAD0mt+iqigaoiZIjxvB6lvr5llevzgVQyy
         bttBzyS9+u0A95S4FiZNUkq4naafNmxXh5cufk4fHpCToI8japoJ8wDh+im7aZzIf8JU
         dwdQ==
X-Gm-Message-State: AOJu0YySCO0nif3TkmKTGLBreKLeBcwITvKHr5yqx1ixxerCjWDP8m5W
	7t/Y4g5907wgJaH4f+PHSmI42S5rWEiQsheDzanDgEhvOXQF7GysluTLeiJaAEY=
X-Gm-Gg: ASbGnctaX3c+fTGzSbOnLa2MjqJFQj2WhCwnV16kPYk0JHJUT3yvlQPTHYVS6Hz7iMW
	chxVCLw7HvT8kxZ+qnkMWwuiYTClw1ApSczuUtk6o8uxmS4MFGd961BukdnxV5K+w19Bkt7njrt
	l21Ii4yl41O6DUEAIIcXlzC7CpH1GCVhS41rLf4tCOuxsf43AoraBALjoa9kJ+f8rtmZWGtJ1OH
	aEkIVKpolD5a+gQOXZII2siNs6o8N7dsMv6eXvnjJVzMZfhtqnW3YNd8p2jPpnwBXoWMu/yJNZY
	pSguCGqjcjHUiRX6zU58XUECAWBxT/pD8H0hHIRB4DOko1eDFDx2+n5nTwErHA==
X-Google-Smtp-Source: AGHT+IFeSGKNji/QSEGK222NxtXC17g2vNM1VYsYMqhmLemPHZXCWUfdXaCaq2VS8Ifq45kgO7LaSg==
X-Received: by 2002:a17:902:ecc1:b0:220:faa2:c911 with SMTP id d9443c01a7336-231980cf801mr54281865ad.14.1747233767929;
        Wed, 14 May 2025 07:42:47 -0700 (PDT)
Date: Wed, 14 May 2025 16:42:42 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper 
Subject: Re: [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache
 writeback
Message-ID: 
References: 
 
 
 <80ab4cdf-dbbb-4daa-831e-c6d92f5dcf13@suse.com>
 
 <66603689-429b-4bf6-8792-e4feae346a13@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <66603689-429b-4bf6-8792-e4feae346a13@suse.com>

On Wed, May 14, 2025 at 02:46:32PM +0200, Jan Beulich wrote:
> On 14.05.2025 13:30, Roger Pau Monné wrote:
> > On Tue, May 13, 2025 at 03:54:56PM +0200, Jan Beulich wrote:
> >> On 13.05.2025 15:41, Roger Pau Monné wrote:
> >>> It's my understanding that the same is possible on native, as the CPU
> >>> might speculatively pull lines into the cache.  So there's no reason
> >>> for an OS to use wbinvd if wbnoinvd is available?
> >>
> >> Speculatively pulling data into the cache is possible only when page
> >> table entries permit caching. Hence after changing all mappings of a
> >> certain page to UC, an OS may have a need to ensure that no data of
> >> this page is left in any cache (and it can't be pulled back in
> >> speculatively then).
> > 
> > Is this realistic taking into account the OS is running virtualized?
> > 
> > At least with Xen there's the direct map, so once context is switched
> > back to Xen (for example to execute the wbinvd itself) there's no
> > guarantee the CPU won't speculatively populate the cache with entries
> > from the direct map.
> 
> Well, we've been knowing for a long time that we're not doing things fully
> correctly there. Once a guest has changed all mappings of a page it owns,
> we ought to make the direct map one follow suit (or simply unmap it from
> there).

Keeping track of guests mappings seems extremely complicated - maybe
doable for PV, but not for HVM with HAP I would think?

Also we would need to do something similar if guest enables CR0.CD and
switch all the direct map entries to uncached?

Address Space Isolation (and the removal of the direct map) might
solve part of this, but still I don't think we can fully guarantee Xen
won't have any mapping of guest pages with a different set of cache
attributes.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 14 14:44:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 14:44:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984388.1370529 (Exim 4.92)
	(envelope-from )
	id 1uFDLd-0005dN-S5; Wed, 14 May 2025 14:44:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984388.1370529; Wed, 14 May 2025 14:44: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 1uFDLd-0005dG-PV; Wed, 14 May 2025 14:44:41 +0000
Received: by outflank-mailman (input) for mailman id 984388;
 Wed, 14 May 2025 14:44:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFDLc-0005dA-TU
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 14:44:40 +0000
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com
 [2607:f8b0:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f66b02f9-30d1-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 16:44:39 +0200 (CEST)
Received: by mail-pg1-x529.google.com with SMTP id
 41be03b00d2f7-b2093aef78dso6886006a12.0
 for ; Wed, 14 May 2025 07:44:39 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-74237a3d856sm9824080b3a.144.2025.05.14.07.44.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 07:44:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f66b02f9-30d1-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747233878; x=1747838678; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=guZ5oDobsJQTu2/Ss2S+FqqntL707+qTlLJKiycuulY=;
        b=Me9kFroXm5v0TnwDqGxpK7T5b4T4sK6ZH8wmylDEFgSu9iQFDmlQsgJvGi1KR7LSxF
         MJO1uYDQtwlqCyVY8gbHL/0enPXSpid+ufOCtb7mZugqUOJAP1k/JDq4khZyugXNyujM
         W7eeUT4nAlfF5z5fKEOHckHuKIIXyJr3FzTC0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747233878; x=1747838678;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=guZ5oDobsJQTu2/Ss2S+FqqntL707+qTlLJKiycuulY=;
        b=fZe2z+FxAz/ZVNJ4MUJkuHn0AAQ2ZtthawumI83KFqgGGlKdgTITxRt+sS0mLXeqYP
         t0INgjD4Da7Gh+K8VWAaAtK0PIiITAqLJpJ7kwkDApqw6pHLcwjhXIYtp4jVWszDK+5L
         6UN5eESEwosrt6UE8B9Y6Skq1dFcGUGLQ5bjvZGAsXFqt6CzT6JlKFrv76KpncndHcnc
         32YRQOXiMQJgkqCnx3WajTjmMTX6Z5b7UN84xgjnnzA4i6Qsibu8aPuJUCX1eRDw0xR0
         qH2amKmX/QXcMSVhi4JASD2/8fsx6PKrNF4M8uyMrTpvJ2Oz5fhdBecLdAnhgPVUh7oI
         niGA==
X-Gm-Message-State: AOJu0YwZCZnWy5LzvgXbpjSLOdzQ1rirJyp6wTAL7a/MNIE8kPyRR11X
	kry0jDJQa6Upc1V/Z2w8kGSy+/BLWqPRTsB9svW4kFRtxxCM0O1ZJ9o2GwC7wu8=
X-Gm-Gg: ASbGncvAz64WSMOV+W8BEiwx4BLATo488CYRkD92K7Lh+bCz2pyCHCoxvDG0PWrZfN0
	Wb1EKqxA2d/NXXbFdZvkmbgHlcSbZJ7A7SJkkuilHiwd93b84J9ugkNv+pEjDUaFRrUSNKPPWh+
	otF5WPgwJfypMj73dNxnl/abaEPwlIHTAAtk7AGxaa3nKEckG3hTntB+bBFhkMf1cijaN3hUyhn
	cC63AtQUZak98JkzUr0Fqomc6lN3TXoUEol7N79Oe8H5JJoZfZkBVAdGnRUCbCDyFtFa7minJnS
	d1AKVHvFSb17+weg78SRoPYxXN24laHx46OZgp9tH4NfTYFwzKRUfnd3JqeNRg==
X-Google-Smtp-Source: AGHT+IHImPD9w7qiY7xcBhGbsln/T3FlEAGKomz/gzcQmLvLUWXv7GjurojyZ/LFC3yqE4xNwsTjHQ==
X-Received: by 2002:a05:6a20:d045:b0:1ee:d418:f764 with SMTP id adf61e73a8af0-215ff1b63admr5156371637.38.1747233878227;
        Wed, 14 May 2025 07:44:38 -0700 (PDT)
Date: Wed, 14 May 2025 16:44:32 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu ,
	Kevin Tian 
Subject: Re: [PATCH v2 4/6] VT-d: restrict iommu_flush_all() to cache
 writeback
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, May 03, 2023 at 11:46:11AM +0200, Jan Beulich wrote:
> We don't need to invalidate caches here; all we're after is that earlier
> writes have made it to main memory (and aiui even that just in case).
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

I wouldn't mind if you gated the flush to iommu_non_coherent, but
that's not very relevant if we plan to remove the call anyway.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 14 14:46:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 14:46:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984397.1370539 (Exim 4.92)
	(envelope-from )
	id 1uFDMu-00068y-5y; Wed, 14 May 2025 14:46:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984397.1370539; Wed, 14 May 2025 14:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFDMu-00068r-2r; Wed, 14 May 2025 14:46:00 +0000
Received: by outflank-mailman (input) for mailman id 984397;
 Wed, 14 May 2025 14:45:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFDMt-00068j-4t
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 14:45:59 +0000
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com
 [2607:f8b0:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 22ca80ba-30d2-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 16:45:54 +0200 (CEST)
Received: by mail-pf1-x42f.google.com with SMTP id
 d2e1a72fcca58-74248a3359fso4842428b3a.2
 for ; Wed, 14 May 2025 07:45:54 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-742522ce81asm7083365b3a.46.2025.05.14.07.45.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 07:45: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" 
X-Inumbo-ID: 22ca80ba-30d2-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747233953; x=1747838753; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=66svDGfT8F6rDYcFQhRugCuC20JT6oBv1oEMQtpL+k4=;
        b=V4jl6NPOw+ii4HqH2cfURVCn1OkrIHdXc+jCogrU48bMOuIeZ+i0diPX9ON6GQn96c
         1V6lG8Wlfu8Pv+JzWxo0ByceSpJxk1D9ArQKvzMXZBY3fTDKS5cKNbTDDZTZYK71HJlR
         AJsB7uXnqyALSk4mk0ySgYb8Jqpn+t5mOeTFg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747233953; x=1747838753;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=66svDGfT8F6rDYcFQhRugCuC20JT6oBv1oEMQtpL+k4=;
        b=LL7KIXHoCIEXEKdagZDM1/kfHQFFLX1RpmpqKbY7EAg4SE/NFHZs7V9zjcWhjFFRbR
         EgqBqGoDsUxM4jiUSEg6ZXVS/Lgx7sZaxLlRgsMg4D6v5BCSsgEHh0KFhjIOoFacFpyn
         FeQ2j8dklh2mK1ejcQnzgoJpVQLFpBDkKGt+jBokkBm32BJQ6YN7uZ81GefNNjMAqKAL
         Ft97zvn5CQOBvbsmk9AfgR8Y2/LKxTxO/FsNufJ3kS436gVHyLfIUUcF+nIBV6Y+AYQW
         PpYJUreTbVb1AzkH9mGPUsY1uJ9YxzCO81W+O/zimTf+taHwAMh5dy6urdTjUL+mSRcL
         kLVQ==
X-Gm-Message-State: AOJu0Yy5lNC1F6+gmn6T0OiprKvL4PEcaG0VwLAnLSHxEYET8EzZVeBh
	abej3LUYwCNjbbhnNQnTf/BxW06oqehc87zRkE1BwflBjGUjdMLjp2DvWWFWbVg=
X-Gm-Gg: ASbGncsNXvI3GSUeQ3kEnhDxYp8St1rWLBdZZbwh3Ccguu9HVEB0Jxm+QCMm/yVlny2
	j+qCDrsHrz5WdnurSlTY/+WiMB22WQPkauMk1dDfTxhyhU94dAgnCdpjkuDFJvTnFJhTj7y/V11
	Cks3wJpXbfCGOzkuN/h/IlLaHE3Ty1ji5GRizj8bvu9Fj661y/4HMXiTCyCBUyfXb7s1RhoOwVO
	ctYia7kMHK1YpelkN20ztw9kwkZ551TgeTHFFlXzzgRceEP/z4mcUuos0zEwx5OcfT3dUtDz2bz
	jtQzE0yUzVNr9JttDNvTa+QftRUpJlwSN+TcweFsKwTx/V8deIWtBQp/N1i2aA==
X-Google-Smtp-Source: AGHT+IGqrXbls0SknW+UxVWAXGnCQKqwE7hV9HWwb0lOsNB7NlPVn1jESZRTomQM3lechPQ8Aes7xQ==
X-Received: by 2002:a05:6a00:3d16:b0:736:53ce:a32c with SMTP id d2e1a72fcca58-74289348adcmr4594246b3a.17.1747233949183;
        Wed, 14 May 2025 07:45:49 -0700 (PDT)
Date: Wed, 14 May 2025 16:45:44 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu 
Subject: Re: [PATCH v2 5/6] x86: FLUSH_CACHE -> FLUSH_CACHE_EVICT
Message-ID: 
References: 
 
 
 <5aeca684-4ff1-4299-ab07-95d02be12f46@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5aeca684-4ff1-4299-ab07-95d02be12f46@suse.com>

On Wed, May 14, 2025 at 02:52:39PM +0200, Jan Beulich wrote:
> On 14.05.2025 13:44, Roger Pau Monné wrote:
> > On Wed, May 03, 2023 at 11:46:41AM +0200, Jan Beulich wrote:
> >> This is to make the difference to FLUSH_CACHE_WRITEBACK more explicit.
> >>
> >> Requested-by: Andrew Cooper 
> >> Signed-off-by: Jan Beulich 
> > 
> > Acked-by: Roger Pau Monné 
> 
> Thanks.
> 
> > This is however missing the previous calls from SVM/VMX that at this
> > point in the series have already been switched to write-back instead
> > of evict.
> 
> Hence why it's this late in the series, i.e. ...
> 
> >  Maybe this patch should be the 1st of 2nd, so that changes
> > from evict to write-back are done afterwards?
> 
> ... I wanted to avoid touching those places twice. (IOW re-ordering would
> be possible, with the extra changes you mention, but I'd prefer not to.)

Given the concerns with patch 2 I think some re-ordering will be
needed?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 14 14:50:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 14:50:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984411.1370549 (Exim 4.92)
	(envelope-from )
	id 1uFDQp-0007GB-Q4; Wed, 14 May 2025 14:50:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984411.1370549; Wed, 14 May 2025 14:50: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 1uFDQp-0007FT-LO; Wed, 14 May 2025 14:50:03 +0000
Received: by outflank-mailman (input) for mailman id 984411;
 Wed, 14 May 2025 14:50:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFDQo-0006zF-KU
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 14:50:02 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id af01ce12-30d2-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 16:49:48 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5fc5bc05f99so13264941a12.3
 for ; Wed, 14 May 2025 07:49: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
 a640c23a62f3a-ad2192c8535sm945119366b.8.2025.05.14.07.49.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 07:49:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: af01ce12-30d2-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747234188; x=1747838988; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pXyJ5Bzu0ZDjZyDZyQpx3cuxULLT79rv8reETj6Wz4U=;
        b=ZNFnM8CN6tkknng5ltyFmNo/wke/x3AXQfmK20WhQqDPdanFASAhm/ltLiTF16t6m9
         8D8OsGTMk4l7k33LDHCT56iY1CVBg3DNjCH+vr4zGDn5U8/Ur6ZTZZLQZbWk+wjyTJCa
         ylUoH9AQXQzQttnxto1ojVGEy8k55IjxgL2BUNLsg1z6oDxsYr7PgKHBtoD6jLuNe8LU
         gzCPPZ8eExvqxFQjdrEFf+3myL8sQ1lwTrVrsXLEX9qIN5jWkp2uHIRETzuBGmQL+6WZ
         NnQTPj1SbXvfg7H/tD/FY4ZVpYAH8+97VX4lO5+Oq7/dPorpK8B8ksgZVtJlxwOpqu9c
         fCyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747234188; x=1747838988;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pXyJ5Bzu0ZDjZyDZyQpx3cuxULLT79rv8reETj6Wz4U=;
        b=sqYiFvPjVjZQCthhghdwYBwNlQPGtnDDQE/gfDcHyODMQBbivXIvN/lFsHfVyFLRxt
         +LaiItRFl7GGeQSGNDbg3K6vRuENO9Fv4UZu0NPMGCZ33MuTaVbaIoF3XP8gyRT5EtRp
         3xFodw71+mwUlP9GFC4Oh8GUMB3i3b2/uq04yntxuBcI10nMmGGEi0xeTiOlOHujeebN
         U02HaDtR5D1isCB1TK+q6n9oYt/+EmwfXJ+vfCzviBrcP5XlAAnxEN38SY03bAoZE/mx
         JE6t/Dzvsqpk0jSmpjkmeIuu/lRLHMV6hl0VubWnxIYlb98aTSYcd9ewULKQflXTACZn
         Q1Qg==
X-Forwarded-Encrypted: i=1; AJvYcCWe4c3ZCfVu+O2KtY900tbOHhz1krytUYvzSm6NpEH55pkfI25eoCKY74ink5EyzffiJafV4LM5cNw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw5bUaNZQLFYjabrIqGeyoumq7FKO/pa7ZXLHK35XAz5cEr9RF0
	oJNHIhvq3a0iH3qhLK9UcAlgAqOm+aLWjic5eFkiKDW1piMdoorwkXIGs//m+A==
X-Gm-Gg: ASbGncvzsTs2t9TlkggSHbIeqHYodVMpRjPfzO7DXTJfUy7B259/dp2Eegg+3dji3TK
	+DwMhKWRG/45CfCfRe1XZeqqZB6/mj95PIgY+b5tsMPx+QjTmNNMGPdCdbKI2+2VvNM/idrvAqR
	1yfi/RPB4Md4Lu1CdeXOsfTCMM47NdMos04B9blY/eN8J/rn54dT1BfTQXlNnHgWkbGDExigOfS
	8KFF9QYQSw1MMciCGS0JwAwYfF02xUQ0tQc9EJ2S39E+5HFe6OqPzOdfEMP9EGCQKBLGEIpsTpJ
	cZrWrHQ180HRoG+SIdzRk3k6jSx8lIsrqdL4OGk1vGXcAsGYIYNVSQm6PcWLFwEXesEp2EXy8wM
	LmAJ2hghGbGY+SGm+XI3pGow4U7V8Jb00vCfu
X-Google-Smtp-Source: AGHT+IHsw0WfsUy/w9cMXj2QwWU4GQZcK+c+nDG7sVKsmseDqIFEX02mW66t04Gc7f5N4mK8CrtfqA==
X-Received: by 2002:a17:906:9c87:b0:ad2:2e45:41ac with SMTP id a640c23a62f3a-ad4f74d0782mr329738866b.50.1747234188132;
        Wed, 14 May 2025 07:49:48 -0700 (PDT)
Message-ID: <86738265-1137-45f0-ae9e-0db7f0451c08@suse.com>
Date: Wed, 14 May 2025 16:49:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 06/16] xen/riscv: introduce init_IRQ()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <2a57200785c710a5203a116bf9a933b4ea12d112.1746530883.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: <2a57200785c710a5203a116bf9a933b4ea12d112.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/irq.h
> +++ b/xen/arch/riscv/include/asm/irq.h
> @@ -3,6 +3,11 @@
>  #define ASM__RISCV__IRQ_H
>  
>  #include 
> +#include 
> +
> +#include 
> +
> +#define NR_IRQS 1024

Is this arbitrary or arch-induced? Imo it wants saying in a brief comment either
way. Then again maybe it's entirely obvious for a RISC-V person ...

> --- /dev/null
> +++ b/xen/arch/riscv/irq.c
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +/*
> + * RISC-V Trap handlers
> + *
> + * Copyright (c) 2024 Vates
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +static irq_desc_t irq_desc[NR_IRQS];
> +
> +int arch_init_one_irq_desc(struct irq_desc *desc)
> +{
> +    desc->arch.type = IRQ_TYPE_INVALID;
> +
> +    return 0;
> +}
> +
> +static int __init init_irq_data(void)
> +{
> +    unsigned int irq;
> +
> +    for ( irq = 0; irq < NR_IRQS; irq++ )
> +    {
> +        struct irq_desc *desc = irq_to_desc(irq);
> +        int rc = init_one_irq_desc(desc);
> +
> +        if ( rc )
> +            return rc;
> +
> +        desc->irq = irq;
> +        desc->action  = NULL;

Nit: You copied a stray blank from Arm code. Actually I wonder why it isn't
init_one_irq_desc() that clears this field. It also feels like ->irq would
better be set ahead of calling that function, like x86 has it.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 14:53:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 14:53:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984420.1370559 (Exim 4.92)
	(envelope-from )
	id 1uFDUE-0000Bz-6h; Wed, 14 May 2025 14:53:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984420.1370559; Wed, 14 May 2025 14:53: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 1uFDUE-0000Bs-3U; Wed, 14 May 2025 14:53:34 +0000
Received: by outflank-mailman (input) for mailman id 984420;
 Wed, 14 May 2025 14:53:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFDUB-0000BV-Vn
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 14:53:31 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 32ceddb9-30d3-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 16:53:29 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5fd1f7f8b25so7737913a12.0
 for ; Wed, 14 May 2025 07:53: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
 a640c23a62f3a-ad4feab49absm103137666b.110.2025.05.14.07.53.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 07:53: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" 
X-Inumbo-ID: 32ceddb9-30d3-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747234409; x=1747839209; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ceAguSr653GAv4wg7Y0WeCfpzvoB1roHPqu+hG0j7ms=;
        b=KRTtjFEjNZivx/vjkwQjKrlXhLc9jHK0gsSQE8Fq5Kh4QZGHE/qPl7m/eof+22Jxxx
         zVZ3zSe5x8DDJrbIcXunYNIZ7+2DuhIesEC6IUASSMoAQIMG4mqWmQ6+w+kdeaZJQ+jo
         N32L51dU23Bw2RHaO21/E5u7P+UW1tVl8X9+vkCvzaTp7Yu97JkqfV/9pztSn9lDujpI
         TnYLs9XVDAGi99bNBkcziIS4MRzTPshbUQ+ir5zR82s9F0u2AUKPsX02XJAJyKa/egOv
         csrp7NQhQO9Wg+sGuXtqSgNzyu9IkXQMK0KSNnnZ1kVjzI5vIwvsaUtA4rkcgf0kiGns
         pF1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747234409; x=1747839209;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ceAguSr653GAv4wg7Y0WeCfpzvoB1roHPqu+hG0j7ms=;
        b=SB97V9YOydXItH2Lgcq1w6rgZZehWvjgUqVoVVMo2HVneD6RLrbFXlPf/poDAcUOgl
         FW3C0SvHo5eVKXmhZnIRxkCLyY2ZcrCqgwl4slCXSpMaUIKwRplXCe+TSqyDpiqML/0a
         5ThqUXDYKqkOlTE4Aou0q35kgaRMK7CKAQXD2OiQmdhNJ98z7jroeSImX+2Qk63+/Z42
         fFw5RZncywXRMvmyra8hsbaM3UArTPOnXhur+OOXzucdNLWGVRBS8TWhFxld3vpSuZBi
         dQvMqgPqs8G7kCa8gd0yRz2HvblceM8zNrBklZXJD4i7tyV9PqmBTOOmbgDqeEBzjAZA
         9uSQ==
X-Gm-Message-State: AOJu0YxtbyyTTgquq/i1zTHnlYlrSBw60E8k01nnLkbCLtrfI0GgjYZx
	gXYjBlclUaTT0qmEB6fJalkZjmvMtnSzMZnsaAvMxr0ZFKOX4qEC0pUyebJ/LtFjDbAazZc5dOE
	=
X-Gm-Gg: ASbGncuE7Se/mL00mmHLVU+TRMn1W3c3BbpuKfC270zp8t5te0x+b59XsY5MmWorXOL
	phtHMl8oAx5y0yALk8IYedt9I0ik0uokVjY7ri/RxX5wwY8/jw9eg5fprPz8ver78UZnBPa7GU3
	B+9n/PFKFGjyzsCdm/YfaMMKTJTuaj4WmDtZROSskMexRktMSXc8HPAJ6Q5HVF+0WEUXBB9VCpr
	IlGnxnZPcI9JyaemamAZHWyWelZGrckYFl5+fCl1QiGVaYzQQSJPdlGUFjSyWSZUM/sV2/vwDT+
	dW4/yRqv2dgH6xJWk9vWpkVIUA5Pe5qLOdUbqjq6ucaLTZ8eFOKq5bQIkmg/5NsbUuQ3CKc9/Yh
	L4U1i3Do2u3RpvLYBl94R7FRqYDXBwNfB2Zgm
X-Google-Smtp-Source: AGHT+IGGpZ6vTR2vEV2E5QJFD7GbHIiwI+pC+AD7o92sf7QpHAPOKwRw+/TnDWVNU5rjf1dJoikqqA==
X-Received: by 2002:a17:907:97c2:b0:ad2:51d8:7931 with SMTP id a640c23a62f3a-ad4f71164c3mr340334366b.21.1747234409271;
        Wed, 14 May 2025 07:53:29 -0700 (PDT)
Message-ID: <915f3134-3095-4a70-bdfe-a8fdfdb031b6@suse.com>
Date: Wed, 14 May 2025 16:53:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache
 writeback
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
References: 
 
 
 <80ab4cdf-dbbb-4daa-831e-c6d92f5dcf13@suse.com>
 
 <66603689-429b-4bf6-8792-e4feae346a13@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

On 14.05.2025 16:42, Roger Pau Monné wrote:
> On Wed, May 14, 2025 at 02:46:32PM +0200, Jan Beulich wrote:
>> On 14.05.2025 13:30, Roger Pau Monné wrote:
>>> On Tue, May 13, 2025 at 03:54:56PM +0200, Jan Beulich wrote:
>>>> On 13.05.2025 15:41, Roger Pau Monné wrote:
>>>>> It's my understanding that the same is possible on native, as the CPU
>>>>> might speculatively pull lines into the cache.  So there's no reason
>>>>> for an OS to use wbinvd if wbnoinvd is available?
>>>>
>>>> Speculatively pulling data into the cache is possible only when page
>>>> table entries permit caching. Hence after changing all mappings of a
>>>> certain page to UC, an OS may have a need to ensure that no data of
>>>> this page is left in any cache (and it can't be pulled back in
>>>> speculatively then).
>>>
>>> Is this realistic taking into account the OS is running virtualized?
>>>
>>> At least with Xen there's the direct map, so once context is switched
>>> back to Xen (for example to execute the wbinvd itself) there's no
>>> guarantee the CPU won't speculatively populate the cache with entries
>>> from the direct map.
>>
>> Well, we've been knowing for a long time that we're not doing things fully
>> correctly there. Once a guest has changed all mappings of a page it owns,
>> we ought to make the direct map one follow suit (or simply unmap it from
>> there).
> 
> Keeping track of guests mappings seems extremely complicated - maybe
> doable for PV, but not for HVM with HAP I would think?

Indeed.

> Also we would need to do something similar if guest enables CR0.CD and
> switch all the direct map entries to uncached?

Likely, yes.

> Address Space Isolation (and the removal of the direct map) might
> solve part of this, but still I don't think we can fully guarantee Xen
> won't have any mapping of guest pages with a different set of cache
> attributes.

Yet for correctness we ought to, I fear.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 14:55:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 14:55:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984428.1370570 (Exim 4.92)
	(envelope-from )
	id 1uFDWU-0000ia-Jj; Wed, 14 May 2025 14:55:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984428.1370570; Wed, 14 May 2025 14:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFDWU-0000iT-Fm; Wed, 14 May 2025 14:55:54 +0000
Received: by outflank-mailman (input) for mailman id 984428;
 Wed, 14 May 2025 14:55:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFDWT-0000iN-SU
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 14:55:53 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 881ae6bb-30d3-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 16:55:53 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a1b8e8b2b2so3845501f8f.2
 for ; Wed, 14 May 2025 07:55:53 -0700 (PDT)
Received: from [10.81.43.161] ([46.149.103.13])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a1f58f28f7sm19715832f8f.41.2025.05.14.07.55.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 07: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" 
X-Inumbo-ID: 881ae6bb-30d3-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747234552; x=1747839352; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9TtX17OyTAXFFybJLHpCO/hSZpr2EGnj/QvLJiIkJpo=;
        b=MpEZ0F88GPwVDI2QRSXrYy89Y49pOOX1mgC3ECgB1HRy8xxLteptS7+xnB00WP0OmO
         fdxOAHdbL0AL75WEL3DcE9quIU9r+3A12rFs/9sfwxqZma4ylQ9h6lcdJFMtOu0lxvAO
         KWo5yfO0o2/WxufGjjAfAbGFu1qkN561c+JfE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747234552; x=1747839352;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9TtX17OyTAXFFybJLHpCO/hSZpr2EGnj/QvLJiIkJpo=;
        b=ZSy/noOSMrqoLwuJHQL/bAcqes7I8wC7wwz8zrHKfujhkIQuTebISESY3aICVTpxoI
         6DOH8nM+IljO87DWGqWJfqTZlVHtPWeIqqSAiuX/3uMVVu42xt084DVxfH0WPX3auf6M
         KYBjSYXirFIC5fnHDG6Lrk13dKbkJkL8jd3RmF8r9qeFTB3alkI/cGsOTXFlzLJexNwP
         lzGUGoVXRia57g6V+7JAm+Pbl0hiitaDzF+DCP5K/1Fu1JotPSyLdkHHbc0oIXYTo4Xi
         fbEH0Vk8nVr6XHcTZLvAQ2RUweLWlwMZBoRXusXaPM5RPuSc3LJ6kj0vF3cqYFEEWpdj
         6AGw==
X-Forwarded-Encrypted: i=1; AJvYcCXnHcX82BJXZMVkYuxPoqwBZ+wRbO8ibfgKKQgvuWyJr9IPXNy9EG0WD50D7jclHZFD9w8yiiuCtnw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyATTMbzw+yaFNCVxp7n0S4tneCamCzwUziIxMvQaqNzIenxpVs
	GftcnurHQYX3TvhCUjMNoX+liPz5TexP0LmTVCXUmCZy5xhyMkVF5Muz8pAgJ8U=
X-Gm-Gg: ASbGncuAWvO3FvsNoBclvsNf3dimRA+MMQB9ytf+odE7jXN+9FwRUPznZm/zF5yRYXk
	mtRF9XoaaBslx2jx3sgnCZNZ1G0HDWww9UPwKh/ufExlggFXCyO5BoGHjsFFiQfg5I6gMQnEDHT
	uTIJAsuIM8wty5t9jmX5iOcdjluaEaXPIipXSU2FoFask6N2zEjz21fYAkcrOHTkQAQc/YJKNMh
	jHUV/V6QSi172d2P7mpsg9bNji4YsuR4TgMRu++sMs8ZwXd0OroOA6RtTH0cQupmC4jd6AlewlS
	qjVRJes/FaOhN1YBxKfT+ln1tqIkvRiQx4yv4WbcudhTQnewwp5/kcHLJmE8Wg==
X-Google-Smtp-Source: AGHT+IEysw4tsW8QvPsyJHgl0/T+/Xsy/I6JuU7dKncQ4UEbd7qYR8wCWHTM3HljkJTiJ0O5au/EDA==
X-Received: by 2002:a05:6000:c08:b0:3a3:4ba4:e8ac with SMTP id ffacd0b85a97d-3a34ba4e906mr1543256f8f.8.1747234552394;
        Wed, 14 May 2025 07:55:52 -0700 (PDT)
Message-ID: 
Date: Wed, 14 May 2025 15:55:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
To: Sergii Dmytruk , xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
 Ross Philipson , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Lukasz Hawrylko , =?UTF-8?Q?Mateusz_M=C3=B3wka?=
 , trenchboot-devel@googlegroups.com
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

On 13/05/2025 6:05 pm, Sergii Dmytruk wrote:
> diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
> new file mode 100644
> index 0000000000..07be43f557
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/intel-txt.h
> @@ -0,0 +1,277 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +

Please have at least a one-liner introduction to what TXT is.  Is there
a stable URL for the TXT spec?  (I can't spot an obvious one, googling
around)

> +#ifndef ASM__X86__INTEL_TXT_H
> +#define ASM__X86__INTEL_TXT_H

I realise this is what the documentation currently says, but we're just
in the process of finalising some changes.  Please make this
X86_INTEL_TXT_H.

> +
> +/*
> + * TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
> + */
> +#define TXT_PUB_CONFIG_REGS_BASE        0xfed30000U
> +#define TXT_PRIV_CONFIG_REGS_BASE       0xfed20000U
> +
> +/*
> + * The same set of registers is exposed twice (with different permissions) and
> + * they are allocated continuously with page alignment.
> + */
> +#define NR_TXT_CONFIG_SIZE \
> +    (TXT_PUB_CONFIG_REGS_BASE - TXT_PRIV_CONFIG_REGS_BASE)

Commit message needs to note that you're swapping NR_TXT_CONFIG_PAGES
for NR_TXT_CONFIG_SIZE, hence the change in logic in
tboot_protect_mem_regions().

> +#ifndef __ASSEMBLY__
> +
> +/* Need to differentiate between pre- and post paging enabled. */
> +#ifdef __EARLY_SLAUNCH__
> +#include 
> +#define _txt(x) _p(x)
> +#else
> +#include 
> +#include    // __va()
> +#define _txt(x) __va(x)
> +#endif

I have to admit that I'm rather suspicious of this, but I'm going to
have to wait to see later patches before making a suggestion.  (I highly
suspect we'll want a fixmap entry).

> +
> +/*
> + * Always use private space as some of registers are either read-only or not
> + * present in public space.
> + */
> +static inline uint64_t read_txt_reg(int reg_no)

unsigned int reg

I'd be tempted to name it simply txt_read().  I don't think the extra
"_reg" is a helpful suffix, and it makes the APIs consistent with
txt_reset().  But I expect others may have opinions here.

> +{
> +    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
> +    return *reg;
> +}
> +
> +static inline void write_txt_reg(int reg_no, uint64_t val)
> +{
> +    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
> +    *reg = val;
> +    /* This serves as TXT register barrier */
> +    (void)read_txt_reg(TXTCR_ESTS);

What is this barrier for?

It's not for anything in the CPU side of things, because UC accesses are
strictly ordered.

I presume it's for LPC bus ordering then, but making every write be a
write/read pair seems very expensive.

> +}
> +
> +static inline void txt_reset(uint32_t error)
> +{
> +    write_txt_reg(TXTCR_ERRORCODE, error);
> +    write_txt_reg(TXTCR_CMD_NO_SECRETS, 1);
> +    write_txt_reg(TXTCR_CMD_UNLOCK_MEM_CONFIG, 1);
> +    write_txt_reg(TXTCR_CMD_RESET, 1);
> +    while (1);

for ( ;; )
    cpu_relax();

please.

Will the write to CMD_RESET try to initiate a platform reset, or will we
just hang here forever?


> +/*
> + * Functions to extract data from the Intel TXT Heap Memory. The layout
> + * of the heap is as follows:
> + *  +------------------------------------+
> + *  | Size of Bios Data table (uint64_t) |
> + *  +------------------------------------+
> + *  | Bios Data table                    |
> + *  +------------------------------------+
> + *  | Size of OS MLE table (uint64_t)    |
> + *  +------------------------------------+
> + *  | OS MLE table                       |
> + *  +--------------------------------    +
> + *  | Size of OS SINIT table (uint64_t)  |
> + *  +------------------------------------+
> + *  | OS SINIT table                     |
> + *  +------------------------------------+
> + *  | Size of SINIT MLE table (uint64_t) |
> + *  +------------------------------------+
> + *  | SINIT MLE table                    |
> + *  +------------------------------------+
> + *
> + *  NOTE: the table size fields include the 8 byte size field itself.
> + */
> +static inline uint64_t txt_bios_data_size(void *heap)
> +{
> +    return *((uint64_t *)heap) - sizeof(uint64_t);
> +}

This is quite horrible, but I presume this is as specified by TXT?

To confirm, it's a tightly packed data structure where each of the 4
blobs is variable size?  Are there any alignment requirements on the
table sizes?  I suspect not, given the __packed attributes.

> diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
> index d5db60d335..8a573d8c79 100644
> --- a/xen/arch/x86/tboot.c
> +++ b/xen/arch/x86/tboot.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 

I'll send a prep patch to fix tboot.c, but we're trying to keep includes
sorted (for sanity of backports).

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 14 14:57:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 14:57:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984437.1370579 (Exim 4.92)
	(envelope-from )
	id 1uFDYD-0001Fu-TK; Wed, 14 May 2025 14:57:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984437.1370579; Wed, 14 May 2025 14:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFDYD-0001Fn-Q2; Wed, 14 May 2025 14:57:41 +0000
Received: by outflank-mailman (input) for mailman id 984437;
 Wed, 14 May 2025 14:57:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFDYC-0001Fh-IL
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 14:57:40 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c545a1bd-30d3-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 16:57:35 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ad24677aaf6so526104066b.2
 for ; Wed, 14 May 2025 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
 a640c23a62f3a-ad23fc53229sm696421766b.48.2025.05.14.07.57.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 07:57: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" 
X-Inumbo-ID: c545a1bd-30d3-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747234655; x=1747839455; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QBd4G/MOG0bU8pvYoIqINAcQ6RQ0A9v9Lj3F43GU4EM=;
        b=TfzKWDGjZczl58BAXVfdSDBzNTfVMe1NBZ6tLUfm/+SzrdMwyJWbOv/VKCCxgm6VwE
         zHaxOILOYA2WZBkf/iwAIg6KKNo4MjDeVJ5VtyeJ/nNsIoyGvXjl5parj0o9hL5aEh7p
         LETzboMGehZUY4NyvQoS0hd8kID8gD3xByQDPybdkmCV2iLxzLklDlq99Z42zXwsU31S
         BjEH0Bklk2aMEGvTiu02ICXmj7uaw5+NsYARc3F4vVznil3fmqptykow6fG0W5kP8yrJ
         B/ZQchaQ5m7Sex034TK156kRI8eXaWhvn33lQSNe3rS4P2dwRQuI/JgSnJEbg9sRZFpB
         ObWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747234655; x=1747839455;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QBd4G/MOG0bU8pvYoIqINAcQ6RQ0A9v9Lj3F43GU4EM=;
        b=gNw/eRZqDBn1OOaIPPp/m5Z6zv3WqAl6xUMTU3u71TEylBfjzbybLKpPPw/0qTq+Q1
         KoOcgaonEAn6fS57o/2LoxVJ4qEWi89GoM610g/HqWwTB+f4F+Dgaayej0gkQg4RGZ+O
         G+lxxK+5/bcnrn6dPts87y8PCm/y2z7CnGl7f6bbpyz7shyqrgkkYCod/O/etKQBvsyD
         YnBBAu6KhsHG5pIaYYTNAlDN0E+bMTViqKglVpyGAl+j39mL5luJr5cxVVdfJ4zbnBEW
         CKMhOjDjavESaerXzbz7v6aVTGIGY3HDlIEZ9Rkgp85p2xTnWkcDpI/63PIUVPiACwIJ
         MepA==
X-Gm-Message-State: AOJu0YwATVvBnE+Buq5jhTiNaVAuXxS83xCWw7ZHt0z8+W1B6BGsOqH3
	yWXXOH0OzROvuwEt7aOXk/oqO2QO24y/mM9ISzIf2AQTyxyhwhJ/BKRsX2n5ew==
X-Gm-Gg: ASbGncty0rLYszkXP0x5JWa8KBM1LfOdRChFVi/pn/hTLCiK5mKr4EGGcVExcVDNNoR
	pT1UUMAT9Z/tUXqC5CG+FrHbBV1vPZR/Vcrc8Tx60NoHz+96rPbNsV95t8r1NpAJC+hhUxYxby2
	groGipRgE3b+6yFkOw74ybXvwod3ubym8l2dGWYFJ4IAcRdbr+IKsMqWr7D+FlW/bkwmrlJXQtS
	QN0OxqQn8B7Tu8/20nAPFs6gTfP3vBRhXOo5P4pVXMMt17oKSx4LKmGNH3WjfXVsgMWDM2NjPOh
	wBX7DVuzxjwNRB7vFgkDndjOgSVyTbeEF5RM8C5UVvG690URNZyRHL9k8fl5fTzPepBInFR+3WM
	67aiGIA6Z+uLS7dCn1hRCbt3AwApd8p0wrHz0
X-Google-Smtp-Source: AGHT+IFhVZrHsYVM5adqPKOmMBNyNMaHZThcTwIeNBq+XmltwHYsmN/d8j+nXrIU1QNfgikP/DkJYg==
X-Received: by 2002:a17:907:970f:b0:ad2:23a8:c71e with SMTP id a640c23a62f3a-ad4f71e1f7fmr359601966b.27.1747234654908;
        Wed, 14 May 2025 07:57:34 -0700 (PDT)
Message-ID: <222117f6-d430-4915-9693-50215760d986@suse.com>
Date: Wed, 14 May 2025 16:57:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/6] VT-d: restrict iommu_flush_all() to cache
 writeback
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Wei Liu ,
 Kevin Tian 
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

On 14.05.2025 16:44, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 11:46:11AM +0200, Jan Beulich wrote:
>> We don't need to invalidate caches here; all we're after is that earlier
>> writes have made it to main memory (and aiui even that just in case).
>>
>> Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Roger Pau Monné 

Thanks.

> I wouldn't mind if you gated the flush to iommu_non_coherent, but
> that's not very relevant if we plan to remove the call anyway.

Actually I think I'll do that. Then for a fair number of systems it
won't matter anymore whether we remove this call sooner vs later.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 14 15:12:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 15:12:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984450.1370590 (Exim 4.92)
	(envelope-from )
	id 1uFDmd-0004lI-6o; Wed, 14 May 2025 15:12:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984450.1370590; Wed, 14 May 2025 15: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 1uFDmd-0004lB-25; Wed, 14 May 2025 15:12:35 +0000
Received: by outflank-mailman (input) for mailman id 984450;
 Wed, 14 May 2025 15:12:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFDmb-0004l5-Ns
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 15:12:33 +0000
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com
 [2607:f8b0:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id da21ec0e-30d5-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 17:12:30 +0200 (CEST)
Received: by mail-pf1-x42b.google.com with SMTP id
 d2e1a72fcca58-72d3b48d2ffso6967291b3a.2
 for ; Wed, 14 May 2025 08:12:30 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 41be03b00d2f7-b2349dd2b3esm9108227a12.17.2025.05.14.08.12.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 14 May 2025 08:12: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" 
X-Inumbo-ID: da21ec0e-30d5-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747235549; x=1747840349; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=3kxtWbon+xp78lamArIAzNYIEA5KZzrX4X0Kxp5vIKc=;
        b=DZp2UMnLH9ERFH2kd9g77a9YRLwjsRbF6vRAExj7ASyfMVYC1mra3guu+OTWzOiLRf
         q0tI52Y0a0Etrc1tRLQAf9ksnHy4IoKvMqD0idDrO335hnnt4GLxIHiN+pHEZbLF+29m
         kIgpMV4oTXsxgsB7M3wl/LcPh/KHtaNq3fPaE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747235549; x=1747840349;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3kxtWbon+xp78lamArIAzNYIEA5KZzrX4X0Kxp5vIKc=;
        b=OMpSuLE7IapYoY9sqUl8NqHVoRntOapWP8eUR3w/rYbsw38wW/w4ZOeWSClbiRQgAH
         kKFsbKxgRv+TYErlp5b2t5ga2l8syPZKV0fc6USOVIYGUSsB+IjHgX72dX7fv3S9CE0I
         7LzGdGmA7G1h2viQTFYT+b+Ms61r0wkpzK7KrC//rJ+icyJ7HwbhZQjTDvsSpsPh0iDO
         PBzh0BY/jcsOOoDuvdQsffKrn1mH83XlluZrEK6exc/JImUIihhKXU/3ddU/W56Yhm6T
         ce4qfXogq+efxKD41Egy3pDqXJYt1U4pKL9ZbkFLkROO+f7X6LSCyCy3oaWUrvq52uin
         /rHQ==
X-Gm-Message-State: AOJu0YyAK8M/Ne2UPc2WGxfzQPDhxLEasYYAraNFLHKpbY77ig092h8w
	IbeVyDxDI/xcXcWSOmtdsxhgA54Qi4+v4/27P+AVIhXYAQsJTmP+sM0ZM98bHes=
X-Gm-Gg: ASbGncvg/ZWIAqu11hDEiylXr+CBisE07J0oQBa2nrM9W5LrM9jJdVXk1wpMwWtySK/
	lh1grsLgWi0AKhqf+yy5s1KvWi9gfOdbfMN3ZwH558MdOdd6JMvSaa76M5R6MtJxnu7TeMB4bJ7
	y5Abk8+zbFgGlUtG202oJ+NCQyoieXUOx+J1zkWsnf0CXGpDupnz89R8hpsCYt7kA+qCrkeSjwA
	432ljA1vAyupmeVd8akKWRJ49KYmsfqQKzc9XarnjikCebQt3ZrECvUyY83cQGIy95sWf86CPyO
	vAkGACl7bDW3rrzQgFia8Xiu9dwkna8KYjdApwJz7Q3uzV4bcQFeHZkt
X-Google-Smtp-Source: AGHT+IF9Vg/XQIKNLyhJ1bqekJyy8/rtFAj8uIoUwUfIMNHKXj8w7MCo3imU41keNG3b19sPNd/njQ==
X-Received: by 2002:a05:6a21:6d94:b0:215:f656:6632 with SMTP id adf61e73a8af0-215ff1890d6mr6415706637.29.1747235548687;
        Wed, 14 May 2025 08:12:28 -0700 (PDT)
Date: Wed, 14 May 2025 17:12:22 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper 
Subject: Re: [PATCH v2 6/6] x86/HVM: limit cache writeback overhead
Message-ID: 
References: 
 <9274fbb1-c1be-9570-ecfc-8f0ac9a1f42b@suse.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 14, 2025 at 03:20:56PM +0200, Jan Beulich wrote:
> On 14.05.2025 15:00, Roger Pau Monné wrote:
> > On Wed, May 03, 2023 at 11:47:18AM +0200, Jan Beulich wrote:
> >> There's no need to write back caches on all CPUs upon seeing a WBINVD
> >> exit; ones that a vCPU hasn't run on since the last writeback (or since
> >> it was started) can't hold data which may need writing back.
> > 
> > Couldn't you do the same with PV mode, and hence put the cpumask in
> > arch_vcpu rather than hvm_vcpu?
> 
> We could in principle, but there's no use of flush_all() there right now
> (i.e. nothing to "win").

Yes, that will get "fixed" if we take patch 2 from my series.  That
fixes the lack of broadcasting of wb{,no}invd when emulating it for
PV domains.

I think this patch would be better after my fix to cache_op(), and
then the uncertainty around patch 2 makes it unclear whether we want
this.

> >> Signed-off-by: Jan Beulich 
> >> ---
> >> With us not running AMD IOMMUs in non-coherent ways, I wonder whether
> >> svm_wbinvd_intercept() really needs to do anything (or whether it
> >> couldn't check iommu_snoop just like VMX does, knowing that as of
> >> c609108b2190 ["x86/shadow: make iommu_snoop usage consistent with
> >> HAP's"] that's always set; this would largely serve as grep fodder then,
> >> to make sure this code is updated once / when we do away with this
> >> global variable, and it would be the penultimate step to being able to
> >> fold SVM's and VT-x'es functions).
> > 
> > On my series I expand cache_flush_permitted() to also account for
> > iommu_snoop, I think it's easier to have a single check that signals
> > whether cache control is allowed for a domain, rather that having to
> > check multiple different conditions.
> 
> Right, adjustments here would want making (in whichever series goes in
> later).
> 
> For both of the responses: I think with patch 1 of this series having
> gone in and with in particular Andrew's concern over patch 2 (which
> may extend to patch 3), it may make sense for your series to go next.
> I shall then re-base, while considering what to do with patches 2 and 3
> (they may need dropping in the end).

Makes sense, I still need to get over your feedback on my series, I've
been distracted with other stuff.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 14 15:55:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 15:55:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984464.1370599 (Exim 4.92)
	(envelope-from )
	id 1uFERz-0001zv-BV; Wed, 14 May 2025 15:55:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984464.1370599; Wed, 14 May 2025 15: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 1uFERz-0001zo-8C; Wed, 14 May 2025 15:55:19 +0000
Received: by outflank-mailman (input) for mailman id 984464;
 Wed, 14 May 2025 15:55:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFERx-0001zi-Re
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 15:55:17 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d43f66be-30db-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 17:55:16 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5fc8c68dc9fso6767402a12.1
 for ; Wed, 14 May 2025 08:55:16 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2192cc449sm950899866b.20.2025.05.14.08.55.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 08:55: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" 
X-Inumbo-ID: d43f66be-30db-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747238116; x=1747842916; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=Ryo/5460jXyba+2N6cmiEE74Onl1UW5ECCK42iBOj64=;
        b=CcfhEd0Dkk+gYYnA+djBdSVS3NhyrRbZA6s6uajcKXEP3P+nPwXa2GjSI8HG86GKDJ
         XxSHHfToRf1SUQ9bL7piRSnr44blxSg8++Fq9qvXs1+FS704CcJIXncsKtRWTjupiG9b
         jdbwNlLEOSh30L4MQKBJEBfw0sjxQBij+Yi+nbXZnvRzqxA2Ia2T2Ef4Jk3zUX72zHSV
         K3DYQrerYZD+95IU3BcK2NJUS6L4F7CIqWJjb9vQvA8C1smG4UD3iH1t/KGmx65ivxLY
         m9EjpOSgs5QOKlJW1VUzNuB5ddBHZ/nvDxipeZMeF1+6BoGHnjyEiZTy8jQc1vqAgmRb
         tl1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747238116; x=1747842916;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Ryo/5460jXyba+2N6cmiEE74Onl1UW5ECCK42iBOj64=;
        b=mINUSzZcmowQ7+dzvzx7Lf0xy1j6ZA+cmsJI62JlkAvOIXgjlt2t74Mr5irqXzq8wM
         tMH0Hxn3xkdmAJlk2Zb1gIaGl5p4tB648hnuvfCn9PyXruIgdnKMVN2FPiQ8vKFvUhYf
         1w+0aUn8h9GcbLGNkrLPX2s3aQTuhRwgMwPoVj+vBA8hi7ezAIgAJ4Pveo8VNRdOb6nz
         x5dgy0/Oq9TKp2h+up/R4Emmc1Qc06TZenEy0lK7tRFCcRwUSmrCupWjZz/6y5OWbl/l
         T386JcOhxgkSZW/tOPVMiT+uSO5IqtjPs+QnP+f8A4W88RH0IZJXTEqEdZGP70pdjSIO
         f0Jg==
X-Forwarded-Encrypted: i=1; AJvYcCWVyGmpgQw7hAxWlWRhOfe2NQ2GmZ8g18vjAGzSvb7l0WYSoSgwlXCISFAiPgtTfAL/0WwXW88mK8M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJE4DCO1+Kkp6L5cw5G7rELWZvSD7BhsHOzezSlWg/E22G/Lwl
	GvVc9TA9JgFwN8pw/Q/RIXCq7cwZs0iCje0AdV/sWSE0XZaL4oIWlbQlK10U76w=
X-Gm-Gg: ASbGncsbXyHaxDiPOqsR9Q6Ro3jp+Hvs1HSo9Ws4hqN7cbi1EAbPoAtfh1Xpz5ajX3D
	ICwsUWdlCN0MUBV35imq/i3D/p18gML18JQp3j8fZJDXVGUbTWFvMH7OaWRmz6dLHxMOo/LZNeV
	UxYt+w+1JeCArPhRWCuSDEvM2nukiJB4x9us3EdhrbzYAkyoy8Y2PxN8R760h8loJfOBv2fLTgC
	U5EpfxI3TaPegDCwqJr2Hh84H6yRqyh4qIXo5ZkbHe6rYbNRxUXc2Yn3JY2gGgkwhTtF8tGab4J
	JaDEUeUGjQFXrnJ0sw6DdLUvL9YiXVyjGrqNwRhTARehFL0iwCqb5/ewInImPX5yS8FqMt5+c27
	4b1VF+iMerzXnJNeVaXCZloPyOBhwWnI87iOBfKc1WJq5mulCh1qzmBgl03f4nDft1XmNgePLpf
	Rq
X-Google-Smtp-Source: AGHT+IHh182S4qNrzpec68cB0pQSx8HaaxuNG0Bm4xeTqtlXZzaRN237QiP3XSyy3bxxeKHYt1bRNA==
X-Received: by 2002:a17:907:168a:b0:acb:52cb:415f with SMTP id a640c23a62f3a-ad4f752d0b6mr375090966b.48.1747238116072;
        Wed, 14 May 2025 08:55:16 -0700 (PDT)
Message-ID: <203ec9a5-01cc-4d5a-bb47-054d4a7f41a3@suse.com>
Date: Wed, 14 May 2025 17:55:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: enable XEN_UNPOPULATED_ALLOC as part of xen.config
To: Roger Pau Monne , xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org
Cc: jason.andryuk@amd.com, Stefano Stabellini ,
 Oleksandr Tyshchenko 
References: <20250514092037.28970-1-roger.pau@citrix.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: <20250514092037.28970-1-roger.pau@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------0m6ZejlMWcAxvEGCTIVoj8jX"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------0m6ZejlMWcAxvEGCTIVoj8jX
Content-Type: multipart/mixed; boundary="------------Xh7Zg4lQ3ytXl0jkpXXQoIrG";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Roger Pau Monne , xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org
Cc: jason.andryuk@amd.com, Stefano Stabellini ,
 Oleksandr Tyshchenko 
Message-ID: <203ec9a5-01cc-4d5a-bb47-054d4a7f41a3@suse.com>
Subject: Re: [PATCH] xen: enable XEN_UNPOPULATED_ALLOC as part of xen.config
References: <20250514092037.28970-1-roger.pau@citrix.com>
In-Reply-To: <20250514092037.28970-1-roger.pau@citrix.com>

--------------Xh7Zg4lQ3ytXl0jkpXXQoIrG
Content-Type: multipart/mixed; boundary="------------rV35Z4Fn70QA3DmRJ7r0OHqR"

--------------rV35Z4Fn70QA3DmRJ7r0OHqR
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTQuMDUuMjUgMTE6MjAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToNCj4gUFZIIGRvbTAg
aXMgdXNlbGVzcyB3aXRob3V0IFhFTl9VTlBPUFVMQVRFRF9BTExPQywgYXMgb3RoZXJ3aXNl
IGl0IHdpbGwNCj4gdmVyeSBsaWtlbHkgYmFsbG9vbiBvdXQgYWxsIGRvbTAgbWVtb3J5IHRv
IG1hcCBmb3JlaWduIGFuZCBncmFudCBwYWdlcy4NCj4gDQo+IEVuYWJsZSBpdCBieSBkZWZh
dWx0IGFzIHBhcnQgb2YgeGVuLmNvbmZpZy4gIFRoaXMgYWxzbyByZXF1aXJlcyBlbmFibGlu
Zw0KPiBNRU1PUllfSE9UUkVNT1ZFIGFuZCBaT05FX0RFVklDRS4NCj4gDQo+IFNpZ25lZC1v
ZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KDQpSZXZp
ZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4N
Cg==
--------------rV35Z4Fn70QA3DmRJ7r0OHqR
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-----

--------------rV35Z4Fn70QA3DmRJ7r0OHqR--

--------------Xh7Zg4lQ3ytXl0jkpXXQoIrG--

--------------0m6ZejlMWcAxvEGCTIVoj8jX
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/Ey8FAmgkvOMFAwAAAAAACgkQsN6d1ii/Ey9g
LggAkkh8UL8M1FJdEcLDvHyLfK23UDnyDuZyQXhhAzD1AlK+NrmN7ip8dkQ+Z38nAPa+j3ZrPqfE
hIidDa72iZBdCM/u4o9zdI+CF7U6vlRUjt2Euf1GANxJ1xEvhckKfUDCM8SxmRdm3WcgkcScK+ey
8F/5RiY2S2CREkikeQvIenq8FhOR2i3pGhDsE3I0eyVFVlKthhlA5w8IIJzHkf/70v6YMc/9nINm
JOKLK0Qg2ADNF7aMAA09ZVi+0JApPs6vSI4OZCrxB/q0gz03AmC9xE31MsqiKXYnedHUeGM3djwW
mk7Ce/z4aakxotnZ7REsSe5wtYy3NrOOoLJjbZEGKw==
=376d
-----END PGP SIGNATURE-----

--------------0m6ZejlMWcAxvEGCTIVoj8jX--


From xen-devel-bounces@lists.xenproject.org Wed May 14 15:56:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 15:56:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984471.1370609 (Exim 4.92)
	(envelope-from )
	id 1uFETA-0002VV-Kn; Wed, 14 May 2025 15:56:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984471.1370609; Wed, 14 May 2025 15: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 1uFETA-0002VO-Hi; Wed, 14 May 2025 15:56:32 +0000
Received: by outflank-mailman (input) for mailman id 984471;
 Wed, 14 May 2025 15:56:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFET9-0002Ux-7W
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 15:56:31 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ff758d34-30db-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 17:56:29 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5fbda5a8561so9760126a12.2
 for ; Wed, 14 May 2025 08:56:29 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5fc9d70f51esm8799706a12.79.2025.05.14.08.56.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 08:56: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" 
X-Inumbo-ID: ff758d34-30db-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747238188; x=1747842988; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=jZGT1lD5+P8o4surXWhjLhMIFTmAgabakL1I8TIT7s4=;
        b=c88S4/NB2kZ12FHY18/CSiC76Y1bmTeo0NTH3YkDJ5SNpg2CXxUIlypqp7m6+LrGCw
         4yiElVpPVtfBEBrzaI8NiPfY0bc1YSs/6F7Tftto8TpL4LfKPd9fuIo/eW0h9NHRdEoi
         1icb/3v0VfefTGEDwe9M21e8rBMe2HqFvX0R/YcSfo/4BUCELLM0PTm+VzWnU50ymZHg
         NJgSaMb+6V2/WRYnLxCOY3kKDwvP+xpjD4Myi8ak2k+WOCaa5tE/J0Kah8OIqlCoUhq2
         PluovND061nt662EgngvZayhtshFf0Q9jVmcirmQe3u1A5Lj9w6AIeJfo/WM5ci9p5xU
         PVkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747238188; x=1747842988;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=jZGT1lD5+P8o4surXWhjLhMIFTmAgabakL1I8TIT7s4=;
        b=WdqsjxtOZEgUqYt2vq3XpIT7Dwc5fKT+v3Ps2gR24dK4jDIPhkhnF1elHQUOH1whzu
         eEHr5etgL/wg9el8A5w0Nmw8ifluo7auQWyf/vkUCXku4/9iMh46u9th5/3f2B1P1t74
         qdBKpOOz1SHh7hUA/txTm1gQHQ6OUFEac5Oe/XQDKcX5sjc1zx/pka0+avuE8DzDiYPV
         b/IiqX2hnFiFPL5jplDsYVNuszvrmYRBv4useCXia0IDSn1NkIoYxdRVjxhulIb5xgLM
         BVbmTqrQRTBHqQjV3EnjpdswWhhS0xezDxv3Xvyp1RkCg5SXtCaB4i26Ve0vQvlA41lQ
         XSpg==
X-Forwarded-Encrypted: i=1; AJvYcCWmaWiyj1WlhYDyd/zs/MbHo9IrU1rYFpC0BhrnlpFIYN5d+Ra6JdXYKuI/gE0zeN81Dc//lXSzv8w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxFG2zrr5XbnboCQ9K066DSSIBuERM0ApfjKlDijBNMARg9FslU
	yEp9WvIC9L1zmiMKXFcjMP8Rzur/u5mDEwyjkeguh5+/gPs1La0QHdenU9nYFE0=
X-Gm-Gg: ASbGncvnRn3PXnyinYAJVg3W71Rk+EZ3Jd5Ky4uQPwnxCO+my7GWQKncVJW4j62sn71
	aVhaHnVIF8Dloa1OBV694F2tW6F/rDr1hF7hRtjBpMHEXPDbEZzHiZOxfKI4IpLIRM9W8ycl3El
	VJfKZNyZuSc9QvsHIsD8QAMSgI2bBQbB+Rv74d14nNc25tgs1jZcy4g2dXg8hT7ysI3nziKulKF
	kA/SajkFn65d67W+FGvlg9akoNeQVd9mnjfCYEUGUwoRjEwmGAjaOJ02U/OPMH2g489AQec891Z
	WTcBknPpT8vcKish0+YHd/lWRj4uBcCgFEgdsNMgsudhwcvgbTk/DUCYS23c9M/QMfsWzpQ8SuD
	mMu7VNHxSLSAKVPTTGWqtC3GCkue/R4OTMoHdc4UXI04+njt/l01h7ybV9RvjE/aMxQVaVMj9HA
	Wq
X-Google-Smtp-Source: AGHT+IGazqnyNdtpYvI2ZUK+d3wGphF/qroGz/5XaD/CJq/YwGfOc1xEFgU6NcJCQdpGjg+xcG/nQg==
X-Received: by 2002:a05:6402:2811:b0:5fc:9759:379c with SMTP id 4fb4d7f45d1cf-5ff988a59c3mr3613418a12.10.1747238188539;
        Wed, 14 May 2025 08:56:28 -0700 (PDT)
Message-ID: 
Date: Wed, 14 May 2025 17:56:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/x86: fix initial memory balloon target
To: Roger Pau Monne , xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org
Cc: jason.andryuk@amd.com, John ,
 Stefano Stabellini ,
 Oleksandr Tyshchenko 
References: <20250514080427.28129-1-roger.pau@citrix.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: <20250514080427.28129-1-roger.pau@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------nqgFyaDVTJItwI4Ej6SU2P0D"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------nqgFyaDVTJItwI4Ej6SU2P0D
Content-Type: multipart/mixed; boundary="------------SMFpqtK4r85d3Z43p0E5K1wt";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Roger Pau Monne , xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org
Cc: jason.andryuk@amd.com, John ,
 Stefano Stabellini ,
 Oleksandr Tyshchenko 
Message-ID: 
Subject: Re: [PATCH] xen/x86: fix initial memory balloon target
References: <20250514080427.28129-1-roger.pau@citrix.com>
In-Reply-To: <20250514080427.28129-1-roger.pau@citrix.com>

--------------SMFpqtK4r85d3Z43p0E5K1wt
Content-Type: multipart/mixed; boundary="------------e0BN0WPbep9uHu6k0l4JliVs"

--------------e0BN0WPbep9uHu6k0l4JliVs
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTQuMDUuMjUgMTA6MDQsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToNCj4gV2hlbiBhZGRp
bmcgZXh0cmEgbWVtb3J5IHJlZ2lvbnMgYXMgYmFsbG9vbmVkIHBhZ2VzIGFsc28gYWRqdXN0
IHRoZSBiYWxsb29uDQo+IHRhcmdldCwgb3RoZXJ3aXNlIHdoZW4gdGhlIGJhbGxvb24gZHJp
dmVyIGlzIHN0YXJ0ZWQgaXQgd2lsbCBwb3B1bGF0ZQ0KPiBtZW1vcnkgdG8gbWF0Y2ggdGhl
IHRhcmdldCB2YWx1ZSBhbmQgY29uc3VtZSBhbGwgdGhlIGV4dHJhIG1lbW9yeSByZWdpb25z
DQo+IGFkZGVkLg0KPiANCj4gVGhpcyBtYWRlIHRoZSB1c2FnZSBvZiB0aGUgWGVuIGBkb20w
X21lbT0sbWF4OmAgY29tbWFuZCBsaW5lIHBhcmFtZXRlciBmb3INCj4gZG9tMCBub3Qgd29y
ayBhcyBleHBlY3RlZCwgYXMgdGhlIHRhcmdldCB3b24ndCBiZSBhZGp1c3RlZCBhbmQgd2hl
biB0aGUNCj4gYmFsbG9vbiBpcyBzdGFydGVkIGl0IHdpbGwgcG9wdWxhdGUgbWVtb3J5IHN0
cmFpZ2h0IHRvIHRoZSAnbWF4OicgdmFsdWUuDQo+IEl0IHdvdWxkIGVxdWFsbHkgYWZmZWN0
IGRvbVVzIHRoYXQgaGF2ZSBtZW1vcnkgIT0gbWF4bWVtLg0KPiANCj4gS2VybmVscyBidWls
dCB3aXRoIENPTkZJR19YRU5fVU5QT1BVTEFURURfQUxMT0MgYXJlIG5vdCBhZmZlY3RlZCwg
YmVjYXVzZQ0KPiB0aGUgZXh0cmEgbWVtb3J5IHJlZ2lvbnMgYXJlIGNvbnN1bWVkIGJ5IHRo
ZSB1bnBvcHVsYXRlZCBhbGxvY2F0aW9uIGRyaXZlciwNCj4gYW5kIHRoZW4gYmFsbG9vbl9h
ZGRfcmVnaW9ucygpIGJlY29tZXMgYSBuby1vcC4NCj4gDQo+IFJlcG9ydGVkLWJ5OiBKb2hu
IDxqd0BudWNsZWFyZmFsbG91dC5uZXQ+DQo+IEZpeGVzOiA4N2FmNjMzNjg5Y2UgKCd4ODYv
eGVuOiBmaXggYmFsbG9vbiB0YXJnZXQgaW5pdGlhbGl6YXRpb24gZm9yIFBWSCBkb20wJykN
Cj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j
b20+DQoNClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoN
Cg0KSnVlcmdlbg0K
--------------e0BN0WPbep9uHu6k0l4JliVs
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-----

--------------e0BN0WPbep9uHu6k0l4JliVs--

--------------SMFpqtK4r85d3Z43p0E5K1wt--

--------------nqgFyaDVTJItwI4Ej6SU2P0D
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/Ey8FAmgkvSsFAwAAAAAACgkQsN6d1ii/Ey+p
QQf/ZAvSSRLcI4Yh8O3g2SlYkobHbcWTYkNnIAbgL9miZ9mAwaX2THYDL0fwatYrIofEh+ryNc8A
LhqZ+9lBEofTM0+gQZrmpcdvBTYrq4akOo9vOVRMZ2doXN0BoFM3iSWncQ6Wy7VouGpAdfZzE5G1
THAAl8jEnfpb5iBK0YtBHn68i58VPFyWT5zoS3uBL+NKS9dEThORWvyk4j9IdmjNRN3tQGU6VFCL
u7ph4z9HIpe56Rg+nsq0a1MV7BhA9BWU5WApiSPvHE4R0gVgMkYtiBBPHS3ojD2kXeb0sy3v4++E
V7fCsi2RPcpGy8l96VEm0N0TzENQ22JwzYNxJKFTkw==
=xJm3
-----END PGP SIGNATURE-----

--------------nqgFyaDVTJItwI4Ej6SU2P0D--


From xen-devel-bounces@lists.xenproject.org Wed May 14 15:58:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 15:58:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984486.1370618 (Exim 4.92)
	(envelope-from )
	id 1uFEUq-00037E-22; Wed, 14 May 2025 15:58:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984486.1370618; Wed, 14 May 2025 15:58: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 1uFEUp-000377-Vj; Wed, 14 May 2025 15:58:15 +0000
Received: by outflank-mailman (input) for mailman id 984486;
 Wed, 14 May 2025 15:58:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFEUo-00036w-P3
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 15:58:14 +0000
Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com
 [2607:f8b0:4864:20::1130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3d557c5b-30dc-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 17:58:13 +0200 (CEST)
Received: by mail-yw1-x1130.google.com with SMTP id
 00721157ae682-70a57a8ffc3so40010947b3.0
 for ; Wed, 14 May 2025 08:58:13 -0700 (PDT)
Received: from [10.138.7.94] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-70a3d9cb5ccsm29661027b3.90.2025.05.14.08.58.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 08: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" 
X-Inumbo-ID: 3d557c5b-30dc-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747238292; x=1747843092; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=eVwpeDLPQa7Q+8iaxWcQp+bHADTpuKScmqBHTTIncyU=;
        b=KCb5s75jBE9SsG15iVyXeLDGy+WzifxX9LVWETn+hNogvfCNetJk/LtUcZeP4HlgUx
         Nme68ATMujsY8Cz27s+Iaysb6XoZbmx+uUxZM/E2XvlFIMF6NvteVfRWMsQkyMNHVB0k
         sdwbLTvj3/1BcW22b+roZymYXIqxuGUsqJK3ZJGFAsQ19e8BlvMxoREY3eyMSTjHSbz+
         EzQ/cClB1SknIu3eMEDlS8WdRYIZZLA/ki6RcBwPR7G9n7c8rne5nzFp5jHmxT+V6T7h
         eE3UhpDizBNoIdj96CVarSeMLxH2JbCcAClefB+ph64fuR/doXRcDQS6cEJnmYnUMG3g
         Bdzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747238292; x=1747843092;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=eVwpeDLPQa7Q+8iaxWcQp+bHADTpuKScmqBHTTIncyU=;
        b=osZMSWMy8SziYtOfip7+lpnFoQr4BoRM2UcZgIOXPzRb/EClfmcFEoBkNdF+KPcuO9
         9XnSHKeqP2hEEqUxPUGhysM2y37+dk7EY8b9jnz6HD6Rz22xqmuqtx84e1PQKGmQtEgQ
         KhzrCrvOmJxmHNCenz+dKNbqFcfZatDpabHvsdjICcDoKnfskYh/eWDv0o07fJfBhPNP
         suMrPHsFpQ2Mz17TvrFy8+y4gQdH5jef9t3AQZYwYLT16+nan+37phmbe9fLxBiD9lCv
         zwm24MiRh0hOK6QMZHH1N2gK3A9GuYhOs4ZAiufk3y9HJGgXTOhphJVEuX9+IfiPFJTa
         Lojw==
X-Gm-Message-State: AOJu0Yyy/TTqALJJC2loxYlKHraGKarPajRnBEG4Cbvrs0JlFjo9gflT
	WlgelCld2SrP1Od+RMsAHLpmXZ8Kx93A4qWCrQPnfl+SQcGrYMuL
X-Gm-Gg: ASbGnctt6rBNbhbUTGGjgZb+4Bs3M+QCRL7LdVJMAYcZ5RcP3ynrjkGR21Wp/n/HfTI
	G1cjK3+1wO7Um9yVdnNubdKFph1vEk5zUT9kDt9w/QwF5VtDhKgMvEke01MO+8Iju9xgB81UDf3
	lGDsXbLBkZZgh+SI8kx4C0mkZ1mrdr7GhHkC2VoClBxFcUjNEF0RFIyt97zi4a4R3caRPcgaNiF
	GA8cwfqblW+xJe51JeHUOpz483EoJ+tQiQw4zMQ8jqRAgtgR3nwsYtN7IiHw+XXyVuY2tk1Za1i
	LfTjLAxW+EcKKtJGA8U4xfpk/rTGiwK6ORis2dSQ51Xr6ein66Dm8s0=
X-Google-Smtp-Source: AGHT+IGPqPJZFIkWmpT0ZRCEhQripGVqnSv64E1VTJc5J+YeaGok0rYwQrY7RIRP1E7Yl1eASr/0Rg==
X-Received: by 2002:a05:690c:c94:b0:708:bb8e:38b5 with SMTP id 00721157ae682-70c7f145149mr54183277b3.8.1747238292153;
        Wed, 14 May 2025 08:58:12 -0700 (PDT)
Message-ID: <1ba433ce-44b6-4d70-a232-f5f83f1fbaf8@gmail.com>
Date: Wed, 14 May 2025 11:58:49 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/22] x86/slaunch: support EFI boot
To: Sergii Dmytruk 
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 ,
 Nicola Vetrini ,
 Doug Goldstein ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Ross Philipson
 , trenchboot-devel@googlegroups.com
References: 
 
 <68e5f8bb-42b2-4da8-86ba-231cb5657106@gmail.com> 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------0EhTxHAH6z1eaWW8WilzX5d3"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------0EhTxHAH6z1eaWW8WilzX5d3
Content-Type: multipart/mixed; boundary="------------AKxkCOdhq8P0HsNdQ6SqCSNG";
 protected-headers="v1"
From: Demi Marie Obenour 
To: Sergii Dmytruk 
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 ,
 Nicola Vetrini ,
 Doug Goldstein ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Ross Philipson
 , trenchboot-devel@googlegroups.com
Message-ID: <1ba433ce-44b6-4d70-a232-f5f83f1fbaf8@gmail.com>
Subject: Re: [PATCH v2 20/22] x86/slaunch: support EFI boot
References: 
 
 <68e5f8bb-42b2-4da8-86ba-231cb5657106@gmail.com> 
In-Reply-To: 
Autocrypt-Gossip: addr=marmarek@invisiblethingslab.com; keydata=
 xsBNBE5j9EwBCACbYHjxDrxFAY3n1x9KBFvjzkG1qFSTVBnH4vpD/5Na4sZq4uDDMUCjivrm
 MzbWYaivYj96BygdOiw7PWxYrhuW0b2WYOeGudZyApgFz42g458s78EciuhgfuWBlxr8dOEN
 /9ueVFHcvtZmDbHhMVPcQ0O7gwh0JmwkOsf7P7WAfYXsQlhO/EBRrNXR0Je+GEpYADhRktxX
 h1d3Iz+oKYuwHioLX8ovoAT4+peOuecWUSpUWebpDbTR5i7NRP3PIblB4KzWJa2kh/f3mx4v
 SRGnHn+BfX42xSe0X7Ktl4Xf+KNq9Wkcjk2CZP57hV2v4pO0ZUOXD7IhlZtnfNj67WjdABEB
 AAHNPU1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSA8bWFybWFyZWtAaW52aXNpYmxldGhp
 bmdzbGFiLmNvbT7CwHoEEwEIACQCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFAll+l7cC
 GQEACgkQ24/THMrX1yw6kAgAiKiUhzAPXZj5ndqiQDl8u8PUK34SupLzYNMJOCBw5Wh+CPHe
 XYlQUwfULWxmzjiWCzzWDx2X/ONsYdRGKDKMqG5srOSWe1IYXv00MEutGsK+m/hmC5mqi/97
 DVNZ1VtKj5WW79IsI0/7ueHsQYNNrXyOfZvKsRE8VIUJ0tNfLFDFlNpq9jONuF+GviMWxrA5
 FoVaGmjh63xC0fOQYqhP2v8dbYS4B6bO5NZKI2cTHb9Li2iY0e7wIoNgvqgtR3Iv2U2Ry0yL
 D3mNQhwyxcWChexlymjfqLEZwKqaIOo57HOpt7OA+bMg6MvkdUTjNWf2GE6fqCcALjcToJ3L
 NDc1KM7ATQROY/RMAQgAtRWgUZ5mOy+c/qzmiVnxqDkiOJjmnIh3Pn+OqCtjcrTyPI9eVc06
 uH30Jkco0soLiG/UgwVw4XwBlm95j9n6TSUms4mPBh1YiR1hBjsjYwn8zp/Ue9xWk1N6E14H
 aj55GxmS2H3YIlOXfQLr0X3RHsmKixTOKyisrYlJu71FmettDFV7CgMXy1Bc1LbAE08asvAS
 ShHFdRiRRtkuVHvY/Ebq9L54kOxtlI6ahrflMcT0YCMON5oe4GgQRh3p2uy+d/LS2bgRcQST
 IebErj8x0lM271f97GvxV/ypHo7XVIDI5FX1u31Agzx3HQr035GHt4HV4/GVCz+V4xt4BonB
 tQARAQABwsBfBBgBAgAJBQJOY/RMAhsMAAoJENuP0xzK19cs5MgH/jWLXil2Ud4TdtWnBxc+
 2/QZZk2JCssc1PgWNzvH5wH7U+8lGSlUK8ZMOqrrF8C5rX0+xEn7deSrsZChIOnUFo8rhCZK
 y/mBV+FhkMj24FZZ0n8w3eF4KF2t68Pt+AvMjxQHwxAMdf3QftgQhD0qYkt/28eedUQ+jwz6
 kipc4qUQmqTEViQRPa3WAnKgNDQUDUwNruzthfGvHUjllf7zbPI8gkbARM0KlTkLikc9u+Ni
 VMbJTiGPB7YHyw2MIPq1n+mhSPAyXE6CVBnYkonQ7P3SLZssxC3PIarV+DTU68umQB3pfrfF
 7hMcAY5csWrK9/x/Zz4RUfgN6Q3HLrSp9UQ=

--------------AKxkCOdhq8P0HsNdQ6SqCSNG
Content-Type: multipart/mixed; boundary="------------mC1Rw1PtH7qvvFEdykjPjGvt"

--------------mC1Rw1PtH7qvvFEdykjPjGvt
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/14/25 10:24 AM, Sergii Dmytruk wrote:
> On Tue, May 13, 2025 at 09:25:44PM -0400, Demi Marie Obenour wrote:
>> On 5/13/25 1:05 PM, Sergii Dmytruk wrote:
>>> When running on an EFI-enabled system, Xen needs to have access to Bo=
ot
>>> Services in order to initialize itself properly and reach a state in
>>> which a dom0 kernel can operate without issues.
>>>
>>> This means that DRTM must be started in the middle of Xen's
>>> initialization process.  This effect is achieved via a callback into
>>> bootloader (GRUB) which is responsible for initiating DRTM and
>>> continuing Xen's initialization process.  The latter is done by
>>> branching in Slaunch entry point on a flag to switch back into long m=
ode
>>> before calling the same function which Xen would execute as the next
>>> step without DRTM.
>>
>> Depending on the bootloader for this unnecessarily ties DRTM to GRUB.
>> Instead, it would be much better for Xen to be able to perform DRTM
>> itself, which would allow DRTM to work without GRUB.  Pop! OS already
>> uses systemd-boot and the trend seems to be from GRUB to systemd-boot.=

>> Furthermore, this would allow DRTM with Xen launched directly from
>> the UEFI firmware.
>> --
>> Sincerely,
>> Demi Marie Obenour (she/her/hers)
>=20
> That sentence in the commit message is worth rewording.  GRUB isn't a
> requirement, any TrenchBoot-enabled bootloader (or anything that wants
> to act as a bootloader) can be used.  systemd-boot could implement
> Secure Launch specification [0] and start Xen/Linux/something else via
> DRTM.  Usage without a real bootloader could be implemented similarly
> via some EFI stub that has binaries embedded into it or that can load
> them from a drive.
>=20
> Mind that at least Intel and AMD DRTM implementations require a DCE [1]=

> binary that depends on a vendor, firmware version or a CPU generation.
> So even embedding all code into every kernel-like software won't produc=
e
> self-contained DRTM-capable images.
>=20
> [0]: https://trenchboot.org/specifications/Secure_Launch/
> [1]: https://trenchboot.org/theory/Glossary/#dynamic-configuration-envi=
ronment-dce

Why is it better for Xen to rely on the bootloader to implement the
specification, instead of xen.efi itself implementing secure launch?
That would make secure launch significantly more usable.  For an
initial implementation it makes sense to rely on the bootloader, but
in the future it would be better for xen.efi to have its own
implementation.

Is the code being added to GRUB for secure launch under a license
that would allow it to be used in Xen as well?
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------mC1Rw1PtH7qvvFEdykjPjGvt
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------mC1Rw1PtH7qvvFEdykjPjGvt--

--------------AKxkCOdhq8P0HsNdQ6SqCSNG--

--------------0EhTxHAH6z1eaWW8WilzX5d3
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgkvcMACgkQszaHOrMp
8lMFwxAAijaBrr785T/hC4YQGlDOBydJlZrh0QC8/fm3MgAHHhwhP30aFXD5yvdx
Eh1A91oYqmUvZ0Gyx8qHz50/GF0fjeJISnDGGqbtvvQxQiokdU8kIacGxfMCB9r7
ZsnBenOKJPgFRcrjfN96uf5X4nsBf/JUMePSvSRLgKkT8llNiym4WM45wCUAu7Jd
byENmYLiLW6WUgLJ2mfJsDEBEZHjmkz2ncPmY3I92dxVgW/YGoP87QnUTcQ6iy84
ZCpvGbHehqCG0GyM0My6PNYh08LskvZCiYrXCuJQ6K2wU6ra84cUGPmM0o0MeAqI
gF392v4nW4i5DTvaAmMXTj3m+RYCtVOJQQuJjp2yonkmQ484R51RQQBFgN0T8kJQ
Q8oNCnaC0ACnh39cmGQ0IWDjINwxZ71aaPXqLCC7r+Se/sOboCpmjfpnTvqkouM8
RN4F4AtIgVwRiFk51HEPY0661K0zoF5g1ipDtyamQkMlPWV9bOzirhi5xiqRbnms
Se3QiRAzv3E9gVl+d1SC0FdDvHae6b7FgYoTSEH5H4Xh1Mq2UCv8N6MUS933reXd
T/U8rOuZ2rYFiLxbE3g7d+QLOtkaIsTmMskV65jFB3yMVXl7k7VdYSXWIM0T2Jia
i6sfUUqV75eoYuGScBhtOp+M+Gbi/PZ8MTP4RSdNLwdM8NFXgHA=
=fMQu
-----END PGP SIGNATURE-----

--------------0EhTxHAH6z1eaWW8WilzX5d3--


From xen-devel-bounces@lists.xenproject.org Wed May 14 16:12:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 16:12:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984502.1370628 (Exim 4.92)
	(envelope-from )
	id 1uFEiK-0006NG-6l; Wed, 14 May 2025 16:12:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984502.1370628; Wed, 14 May 2025 16:12: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 1uFEiK-0006N9-4B; Wed, 14 May 2025 16:12:12 +0000
Received: by outflank-mailman (input) for mailman id 984502;
 Wed, 14 May 2025 16:12:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFEiI-0006N3-5W
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 16:12:10 +0000
Received: from fout-a1-smtp.messagingengine.com
 (fout-a1-smtp.messagingengine.com [103.168.172.144])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2e99e793-30de-11f0-9eb6-5ba50f476ded;
 Wed, 14 May 2025 18:12:08 +0200 (CEST)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfout.phl.internal (Postfix) with ESMTP id 9A2591380187;
 Wed, 14 May 2025 12:12:06 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-04.internal (MEProxy); Wed, 14 May 2025 12:12:06 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 14 May 2025 12:12:03 -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" 
X-Inumbo-ID: 2e99e793-30de-11f0-9eb6-5ba50f476ded
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
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm3; t=1747239126; x=1747325526; bh=GLr7pDypCW
	ihRHk+2e8io55bym6ARNiPcchrD+X7oF0=; b=AiFSrsOdfqFx/TTpEi+Fi/ArV3
	9Dh4nDm9pV4SB6WVk4FgYmJIMh4xZQsLD7F6/PU9hH/m3D5/WdH0MNEjc4zjqNLp
	dsqe7xas7LhZzEtS8qZXZnUNOJaJ5baQRL6fNXQGeW55aGT3jD6uTs/cQ8rYUMFB
	xlhG2jc+2LRQuoTa+lPsv70mVuJFpjUSAr6FMFe+vfwK20GPAQOlGpMpwDfKBVeP
	TBpbEbc24/Lu5Fn6lG3Lo5WP/T2NYYJ93SIHs26heQj5DvgfZIWa8r7SdVDS/KUH
	hLfnrMPjznwT708zTzkeSlacBo+91CWbvWC09bkNnVxsO36wFVnhSUmemwAw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1747239126; x=
	1747325526; bh=GLr7pDypCWihRHk+2e8io55bym6ARNiPcchrD+X7oF0=; b=Z
	7ajOJzZiLZhv1Pl3ZkC+dRYBMbnlz6bq+vd0eYtFr1i+6a1J/FsYdKb/Rw2z/G56
	0tUdYlQbEEoUVLfm4+LXymqaKfyCq41ecp7qUuOIgon1ck9ve02ampuxdWAdcm4A
	FutDXAZ+s8/vksMlxt7vGPptflZbTrA3kh/A+QD8CiNZ9u7YCSqux6WgmFOfww/Q
	u2HCX8OkqB9YQa5ZFOEyRw7bz+ImFOZT0IvVL8jEVh+4MbK0+CXVPIPy/xPMj6Sg
	inZIYO/pHXi+3hslYKYHf1j2MlhmiOmr4/fTT1yUJX4w3/8H30n1mxrpWCLaKkia
	x/Zrj1SGdpQ0qLG3oy7Fg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdejgeefucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtgfgjgesthekredttddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhephefgteevgfefgeetteefueeuvefhfeektdelhfeuffeuleefhf
    dvgeffkefgieegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf
    rhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
    dpnhgspghrtghpthhtohepudehpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegu
    vghmihhosggvnhhouhhrsehgmhgrihhlrdgtohhmpdhrtghpthhtohepshgvrhhgihhird
    gumhihthhruhhkseefmhguvggsrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlhes
    lhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprghnughrvgifrd
    gtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhp
    vghrrghrugesvhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivg
    hlsegrmhgurdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdp
    rhgtphhtthhopehjuhhlihgvnhesgigvnhdrohhrghdprhgtphhtthhopehrohhgvghrrd
    hprghusegtihhtrhhigidrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 14 May 2025 18:12:01 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Demi Marie Obenour 
Cc: Sergii Dmytruk ,
	xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Stefano Stabellini ,
	Nicola Vetrini ,
	Doug Goldstein ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v2 20/22] x86/slaunch: support EFI boot
Message-ID: 
References: 
 
 <68e5f8bb-42b2-4da8-86ba-231cb5657106@gmail.com>
 
 <1ba433ce-44b6-4d70-a232-f5f83f1fbaf8@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; x-action=pgp-signed
Content-Transfer-Encoding: 8bit
In-Reply-To: <1ba433ce-44b6-4d70-a232-f5f83f1fbaf8@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, May 14, 2025 at 11:58:49AM -0400, Demi Marie Obenour wrote:
> Why is it better for Xen to rely on the bootloader to implement the
> specification, instead of xen.efi itself implementing secure launch?
> That would make secure launch significantly more usable.  For an
> initial implementation it makes sense to rely on the bootloader, but
> in the future it would be better for xen.efi to have its own
> implementation.

That might be true when looking at the very limited use case. But if you
look at the broader ecosystem, having a common part in the bootloader
makes much more sense, as it can be reused for different kernels without
duplicating a lot of work.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgkwNEACgkQ24/THMrX
1yypmggAiBWdTT3yTZKYA/28IVhTXRPemEGGqdDcqyC2mDQt102kgF7m46LwSv5I
eK1xY7Hz6AG3Mp9pRH4Jltx5j7SMZ0zzesYuADEpDTNIEWx6Xh+W6AQ5ttAKco1M
tcUFiYaDujesLwRNHJpjH1D9Ih82d1SbUoNyjBgnn1cmX2hXXntVDyXttz6P+xUy
Vl8eF3NYC90+sdc0g8aaKKWe6GqDzsBRj+heISYtymiWRcePWgFWMVMrIDB4Yqmo
+KnDYWsDTQn4Bddu1O6AVVVhvlnhgzP8sHWb20gjQpZG2jwJd1DQcNwQy2Ae04xS
Fxx8mBC75utOGNqnft/Pv098BnmYqQ==
=AulS
-----END PGP SIGNATURE-----


From xen-devel-bounces@lists.xenproject.org Wed May 14 16:59:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 16:59:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984523.1370639 (Exim 4.92)
	(envelope-from )
	id 1uFFRg-0003NU-L5; Wed, 14 May 2025 16:59:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984523.1370639; Wed, 14 May 2025 16:59:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFFRg-0003NN-IU; Wed, 14 May 2025 16:59:04 +0000
Received: by outflank-mailman (input) for mailman id 984523;
 Wed, 14 May 2025 16:59:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFFRf-0003NH-U6
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 16:59:04 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bc1ffb9c-30e4-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 18:59:01 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43d2d952eb1so412935e9.1
 for ; Wed, 14 May 2025 09:59:01 -0700 (PDT)
Received: from [10.81.43.161] ([46.149.103.9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442f39794cdsm38529135e9.38.2025.05.14.09.59.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 09:59: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" 
X-Inumbo-ID: bc1ffb9c-30e4-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747241941; x=1747846741; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yCNbJSZ5Nk0lUiLImtFaDgJu7pm6RRt7/86hksyiolk=;
        b=XFr0InmyGKufLEAYptRGRvBenVrHkM/OUt28mQJRuKk9vFaTRjUpKVshaYmIX/ggzK
         kIt3rAS6fydqEupuxC0nuYWtTVW+1z01DeOZPG724UxJtPSrYGVdRHQOXZZszjtxNxLH
         kfxAQWveNi/PpXaZDiWZgcL6Bz77XAK6QfrHw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747241941; x=1747846741;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yCNbJSZ5Nk0lUiLImtFaDgJu7pm6RRt7/86hksyiolk=;
        b=tQ5hcck4tgnmAzqjaF+Dr3c46tfjKnMGzYCC3e7/+tluJHB3q57fo3lP/pn9lR1xtQ
         1Xk1mNCjeBHHLaUYVOOVmVKpA+FDE713VYMH0BeXGaDvGIlgdhhGEXL9MGlYsayOW77u
         MYJvO8CaZAy7hBcTM3exUQS+j8wiIQT3llT3vH6doemG1fMfBEwMtGAprsa9JPz92f1j
         aUe7NmFKeKj6Wyp8J3k7rxbYIGldE4wRDw39YJVlG55MePpwVsOrVf96h+FsJ0hswbKh
         08vbTu/DR4pN0AIKMJA4QuaYYeAjrqaF1k76pDrXE8B8ltcDVvjbAb0uW8bMNDhqTStm
         l0dA==
X-Forwarded-Encrypted: i=1; AJvYcCWDDbWLd4RKs3Vx5QfQi/E2hoJd9kPtHWYiMjYdWjeQx0mjnVsxDGn3/66bOxeApRs5iAapc+GHHAk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyUm+Y8i4tSKMA88UGpR+Hjvt1EEk0f7BI9T0Z3vgOolp2FC2Z6
	+2wEekm5jaGhEti+CYG3C3yjEEdKej3HuBkIllLFaQo4I1vpronGUpEuANwwO4Q=
X-Gm-Gg: ASbGncvxcVPeoMwd5w37/I1/zWSWkXioMjYFzn04X89S+aPa+ZPOIL1q1M/UxMu7ytN
	V7f1ZAOX9wR9onqkrEU9QGktI7AXTAS1zGpqvWaold8KTVOgpMjTB0wSDgh476sGYVMZgEqvbB7
	eGRlb/oVK/5XOfcWWokj65q9owafNfLZTKp0EYRWHki/D8MMxn9uEP4Os+J8gwn+rBu1qrcqMqR
	5vzKWbAeRxvuibus8E7FwMucRH6NsczL25bCm9Q0zdzKfWtHr4ZboCuZRM1LvYkWq7bqFVhA8ZW
	BKintZcgG9N0ud4lK/K686YqdeAAB/mJYsrKHMRB8hxbYfWBjyhjB2A0r9Hk
X-Google-Smtp-Source: AGHT+IHLw6IeRlDQEKt1WCqZoAtIChJ1hxP/NjMT9TYgGEwuuiRhtvI+sYbmk5r/QwZDz+DpJnTvtA==
X-Received: by 2002:a05:600c:1e09:b0:440:66c5:26f4 with SMTP id 5b1f17b1804b1-442f4c3d3ddmr23417485e9.1.1747241940913;
        Wed, 14 May 2025 09:59:00 -0700 (PDT)
Message-ID: 
Date: Wed, 14 May 2025 17:58:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/22] xen/lib: add implementation of SHA-1
To: Sergii Dmytruk , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 trenchboot-devel@googlegroups.com
References: 
 <7fcab16c3efbc0eb28e0f8ec0d9c9d3188881ad4.1747155790.git.sergii.dmytruk@3mdeb.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: <7fcab16c3efbc0eb28e0f8ec0d9c9d3188881ad4.1747155790.git.sergii.dmytruk@3mdeb.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13/05/2025 6:05 pm, Sergii Dmytruk wrote:
> diff --git a/xen/include/xen/sha1.h b/xen/include/xen/sha1.h
> new file mode 100644
> index 0000000000..085f750a6a
> --- /dev/null
> +++ b/xen/include/xen/sha1.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef XEN__SHA1_H
> +#define XEN__SHA1_H
> +
> +#include 

Please crib from sha2.h as much as you can.  Use xen/types.h, drop the
double underscore in the guard, and provide a link to the spec.

I think it's https://csrc.nist.gov/pubs/fips/180-1/final

The rest of the header is fine; I don't think we need split-update()
support yet.

> +
> +#define SHA1_DIGEST_SIZE  20
> +
> +void sha1_hash(uint8_t digest[SHA1_DIGEST_SIZE], const void *msg, size_t len);
> +
> +#endif /* XEN__SHA1_H */
> diff --git a/xen/lib/Makefile b/xen/lib/Makefile
> index 5ccb1e5241..fd4b9ece63 100644
> --- a/xen/lib/Makefile
> +++ b/xen/lib/Makefile
> @@ -17,6 +17,7 @@ lib-y += memset.o
>  lib-y += muldiv64.o
>  lib-y += parse-size.o
>  lib-y += rbtree.o
> +lib-$(CONFIG_X86) += sha1.o
>  lib-$(CONFIG_X86) += sha2-256.o
>  lib-y += sort.o
>  lib-y += strcasecmp.o
> diff --git a/xen/lib/sha1.c b/xen/lib/sha1.c
> new file mode 100644
> index 0000000000..c7a464e2cf
> --- /dev/null
> +++ b/xen/lib/sha1.c
> @@ -0,0 +1,218 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * SHA1 routine optimized to do word accesses rather than byte accesses,
> + * and to avoid unnecessary copies into the context array.
> + *
> + * This was based on the git SHA1 implementation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * If you have 32 registers or more, the compiler can (and should)
> + * try to change the array[] accesses into registers. However, on
> + * machines with less than ~25 registers, that won't really work,
> + * and at least GCC will make an unholy mess of it.
> + *
> + * So to avoid that mess which just slows things down, we force
> + * the stores to memory to actually happen (we might be better off
> + * with a 'W(t)=(val);asm("":"+m" (W(t))' there instead, as
> + * suggested by Artur Skawina - that will also make GCC unable to
> + * try to do the silly "optimize away loads" part because it won't
> + * see what the value will be).
> + *
> + * Ben Herrenschmidt reports that on PPC, the C version comes close
> + * to the optimized asm with this (ie on PPC you don't want that
> + * 'volatile', since there are lots of registers).
> + *
> + * On ARM we get the best code generation by forcing a full memory barrier
> + * between each SHA round, otherwise GCC happily gets wild with spilling and
> + * the stack frame size simply explode and performance goes down the drain.
> + */
> +
> +#define SHA1_BLOCK_SIZE         64
> +#define SHA1_WORKSPACE_WORDS    16
> +#define SHA1_WORKSPACE_MASK     (SHA1_WORKSPACE_WORDS - 1)
> +
> +struct sha1_state {
> +    uint32_t state[SHA1_DIGEST_SIZE / 4];
> +    uint64_t count;
> +    uint8_t buffer[SHA1_BLOCK_SIZE];
> +};

As it's uint64_t, the count field needs to be first to avoid padding.

> +
> +/* This "rolls" over the 512-bit array */
> +static void set_w(uint32_t w[SHA1_WORKSPACE_WORDS], size_t i, uint32_t val)
> +{
> +#ifdef CONFIG_X86
> +    *(volatile uint32_t *)&w[i & SHA1_WORKSPACE_MASK] = val;
> +#else
> +    w[i & SHA1_WORKSPACE_MASK] = val;
> +# ifdef CONFIG_ARM
> +    barrier();
> +# endif
> +#endif

This is horrible.  I think the problems discussed are created by having
the loops in sha1_transform() broken in a wrong (read, unhelpful) way.  
The 5-way shuffle of the chaining variables probably is beyond the
compilers' ability to unroll given the multiples of 4 currently used.

See the implementation in SKL where I spent a while optimising the code
generation.  Admittedly that was optimising for size rather than speed,
but the end result look to be good for both.

> +}
> +
> +static uint32_t blend(const uint32_t w[SHA1_WORKSPACE_WORDS], size_t i)
> +{
> +/* This "rolls" over the 512-bit array */
> +#define w(i) w[(i) & SHA1_WORKSPACE_MASK]
> +
> +    return rol32(w(i + 13) ^ w(i + 8) ^ w(i + 2) ^ w(i), 1);
> +
> +#undef w
> +}
> +
> +/**
> + * sha1_transform - single block SHA1 transform
> + *
> + * @digest: 160 bit digest to update
> + * @data:   512 bits of data to hash
> + *
> + * This function executes SHA-1's internal compression function.  It updates the
> + * 160-bit internal state (@digest) with a single 512-bit data block (@data).
> + */
> +static void sha1_transform(uint32_t *digest, const uint8_t *data)
> +{
> +    uint32_t a, b, c, d, e, t;
> +    uint32_t workspace[SHA1_WORKSPACE_WORDS];
> +    unsigned int i = 0;
> +
> +    a = digest[0];
> +    b = digest[1];
> +    c = digest[2];
> +    d = digest[3];
> +    e = digest[4];
> +
> +    /* Round 1 - iterations 0-16 take their input from 'data' */
> +    for ( ; i < 16; ++i ) {

Xen style has this { on the next line.

> +        t = get_unaligned_be32((uint32_t *)data + i);
> +        set_w(workspace, i, t);
> +        e += t + rol32(a, 5) + (((c ^ d) & b) ^ d) + 0x5a827999U;
> +        b = ror32(b, 2);
> +        t = e; e = d; d = c; c = b; b = a; a = t;
> +    }
> +
> +    /* Round 1 - tail. Input from 512-bit mixing array */
> +    for ( ; i < 20; ++i ) {
> +        t = blend(workspace, i);
> +        set_w(workspace, i, t);
> +        e += t + rol32(a, 5) + (((c ^ d) & b) ^ d) + 0x5a827999U;
> +        b = ror32(b, 2);
> +        t = e; e = d; d = c; c = b; b = a; a = t;
> +    }
> +
> +    /* Round 2 */
> +    for ( ; i < 40; ++i ) {
> +        t = blend(workspace, i);
> +        set_w(workspace, i, t);
> +        e += t + rol32(a, 5) + (b ^ c ^ d) + 0x6ed9eba1U;
> +        b = ror32(b, 2);
> +        t = e; e = d; d = c; c = b; b = a; a = t;
> +    }
> +
> +    /* Round 3 */
> +    for ( ; i < 60; ++i ) {
> +        t = blend(workspace, i);
> +        set_w(workspace, i, t);
> +        e += t + rol32(a, 5) + ((b & c) + (d & (b ^ c))) + 0x8f1bbcdcU;
> +        b = ror32(b, 2);
> +        t = e; e = d; d = c; c = b; b = a; a = t;
> +    }
> +
> +    /* Round 4 */
> +    for ( ; i < 80; ++i ) {
> +        t = blend(workspace, i);
> +        set_w(workspace, i, t);
> +        e += t + rol32(a, 5) + (b ^ c ^ d) + 0xca62c1d6U;
> +        b = ror32(b, 2);
> +        t = e; e = d; d = c; c = b; b = a; a = t;
> +    }
> +
> +    digest[0] += a;
> +    digest[1] += b;
> +    digest[2] += c;
> +    digest[3] += d;
> +    digest[4] += e;
> +}
> +
> +static void sha1_init(struct sha1_state *sctx)
> +{
> +    sctx->state[0] = 0x67452301UL;
> +    sctx->state[1] = 0xefcdab89UL;
> +    sctx->state[2] = 0x98badcfeUL;
> +    sctx->state[3] = 0x10325476UL;
> +    sctx->state[4] = 0xc3d2e1f0UL;
> +    sctx->count = 0;
> +}
> +
> +static void sha1_update(struct sha1_state *sctx, const uint8_t *msg, size_t len)
> +{
> +    unsigned int partial = sctx->count % SHA1_BLOCK_SIZE;
> +
> +    sctx->count += len;
> +
> +    if ( (partial + len) >= SHA1_BLOCK_SIZE )
> +    {
> +        if ( partial )
> +        {
> +            int rem = SHA1_BLOCK_SIZE - partial;

Unsigned int please.

> +
> +            memcpy(sctx->buffer + partial, msg, rem);
> +            msg += rem;
> +            len -= rem;
> +
> +            sha1_transform(sctx->state, sctx->buffer);
> +        }
> +
> +        for ( ; len >= SHA1_BLOCK_SIZE; len -= SHA1_BLOCK_SIZE )
> +        {
> +            sha1_transform(sctx->state, msg);
> +            msg += SHA1_BLOCK_SIZE;
> +        }
> +        partial = 0;
> +    }
> +
> +    /* Remaining data becomes partial. */
> +    memcpy(sctx->buffer + partial, msg, len);
> +}
> +
> +static void sha1_final(struct sha1_state *sctx, void *out)

Please make this uint8_t digest[SHA1_DIGEST_SIZE] straight away.  This
was an oversight of mine in sha2-256.c which was fixed when exposing the
function (c/s aea52ce607fe).

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 14 19:16:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 19:16:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984561.1370649 (Exim 4.92)
	(envelope-from )
	id 1uFHa6-0002RK-Qt; Wed, 14 May 2025 19:15:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984561.1370649; Wed, 14 May 2025 19:15: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 1uFHa6-0002RD-N6; Wed, 14 May 2025 19:15:54 +0000
Received: by outflank-mailman (input) for mailman id 984561;
 Wed, 14 May 2025 19:15:54 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uFHa6-0002R7-9f
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 19:15:54 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uFHa5-008Uh6-2h;
 Wed, 14 May 2025 19:15:53 +0000
Received: from [2a02:8012:3a1:0:51a6:3d91:4273:769]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uFHa4-00CGAg-3A;
 Wed, 14 May 2025 19:15: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" 
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=iTVHY09+GiI6Qw4uTxeuWjeKB5WTrGC3oQDchQZXTpQ=; b=QTyM8/3hnbNAvlEeXNh/qYEfpJ
	A+ALPt5pv3vOInOXZikGASD0RRMXBwucuVqCrzIgr5ISUZPdd3jBzWMOgG4O6YXBZdn0CXtOvH0cx
	jlHGr97h9GOKdcFYKQXrCpzKCbTxeQd3Cuzfh8xcaurrsKzkDkR6lbxm9j7gMwm7z/9s=;
Message-ID: <10e84bdc-9e6a-4512-8731-605e58d5b855@xen.org>
Date: Wed, 14 May 2025 20:15:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/6] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
To: Luca Fancellu 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-4-luca.fancellu@arm.com>
 <1e56c7e8-5302-4280-a48d-d1e958eeadc9@xen.org>
 <112E7D85-7BDB-490D-98E9-75D03397567D@arm.com>
From: Julien Grall 
In-Reply-To: <112E7D85-7BDB-490D-98E9-75D03397567D@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Luca,

On 14/05/2025 15:27, Luca Fancellu wrote:
>>
>>> +.endm
>>> +
>>> +.macro invalidate_dcache_one reg
>>> +    nop
>>
>> Same here.
>>
>>> +.endm
>>> +> +#endif
>>> +
>>>   /*
>>>    * Macro to prepare and set a EL2 MPU memory region.
>>>    * We will also create an according MPU memory region entry, which
>>> @@ -56,6 +84,27 @@
>>>       isb
>>>       WRITE_SYSREG_ASM(\prbar, PRBAR_EL2)
>>>       WRITE_SYSREG_ASM(\prlar, PRLAR_EL2)
>>> +
>>> +    /* Load pair into xen_mpumap and invalidate cache */
>>
>> To confirm my understanding, xen_mpumap is part of the loaded binary. So we expect the bootloader to have clean the cache for us. Therefore, we
>> only need to invalidate the entries afterwards. Is it correct?
> 
> yes xen_mpumap is part of the binary, are you suggesting we should use clean and invalidate here? So for example boot-wrapper-aarch64 is not
> cleaning the cache.

I am mainly asking clarification of the expected state of the cache 
before the write. From what you wrote, the cache line will be cleaned.
So we only need to invalidate it after the write and there is no cache 
maintenance necessary before writing.

> 
>>
>>> +    adr_l \base, xen_mpumap
>>> +    add   \base, \base, \sel, LSL #XEN_MPUMAP_ENTRY_SHIFT
>>> +    store_pair \prbar, \prlar, \base
>>
>> I think you want a comment on top of pr_t to mention the structure
>> will not changed and
> 
> can you explain better this part, what should I write on top of the typedef struct {...} pt_t?

Hmm, my previous sentence made no sense. Let me retry. Today, you are 
relying on the layout of pr_t to never change. But this is not obvious 
when someone is reading the structure pr_t. So it would be good to have 
a comment such as below on top of pr_t:

"
/!\ The assembly code (see ...) relies on the pr_t. If the structure is 
modified, then the assembly code mostly likely needs to be updated
"

> 
>>
>>> +    invalidate_dcache_one \base
>>
>> This will invalidate a single line in the data cache. The size depends on the HW, but typically it will be 64 - 128 bytes. Do we have any check
>> that will confirm the data will fit in an cache line?
> 
> You are right, so we are gonna write 16 bytes at most for Arm64 and (for now) 8 bytes for Arm32, so I think we will be way below 64 bytes,
> shall we have a BUILD_BUG_ON inside build_assertions() in arm/mpu/mm.c to check sizeof(pr_t) <= 64?

I wrote "typically" because there is no guarantee that the cache line 
will be equal or bigger than 64-byte. Looking at the Arm Arm 
(CTR_EL0.DminLine), if I am not mistaken, the minimum is 16-byte, so you 
could check that sizeof() is always smaller or equal to 16-byte (should 
be the case today).

Alternatively, you could implement another helper in cache.S that would 
invalidate the cache and then don't rely on the size or alignment of the 
structure.

> 
>>
>>> +
>>> +    /* Set/clear xen_mpumap_mask bitmap */
>>> +    tst   \prlar, #PRLAR_ELx_EN
>>> +    bne   2f
>>> +    /* Region is disabled, clear the bit in the bitmap */
>>> +    bitmap_clear_bit xen_mpumap_mask, \sel, \base, \limit, \prbar, \prlar
>>> +    b     3f
>>> +
>>> +2:
>>> +    /* Region is enabled, set the bit in the bitmap */
>>> +    bitmap_set_bit xen_mpumap_mask, \sel, \base, \limit, \prbar, \prlar
>>> +
>>> +3:
>>> +    invalidate_dcache_one \base
>>
>> You want to a comment to explain what this invalidate does. AFAICT, this is for the bitmap. But given the bitmap will be typically small, wouldn't it better to do it in one go at the end?
> 
> Yes this invalidate is a bit overkill because it will invalidate 64-128 bytes starting from the address of the last changed word where the bit was.
> 
> Should I invalidate everything outside this macro, inside enable_boot_cpu_mm in arm64/mpu/head.S instead?

Yes. I think it will be easier if we end up to use a function to clean 
the cache as I suggested above.

> 
>>
>> Same comment here.
>>
>>> +
>>>       dsb   sy
>>>       isb
>>>   diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
>>> index 07c8959f4ee9..ee035a54b942 100644
>>> --- a/xen/arch/arm/mpu/mm.c
>>> +++ b/xen/arch/arm/mpu/mm.c
>>> @@ -7,9 +7,25 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>     struct page_info *frame_table;
>>>   +/* Maximum number of supported MPU memory regions by the EL2 MPU. */
>>> +uint8_t __ro_after_init max_mpu_regions;
>>> +
>>> +/*
>>> + * Bitmap xen_mpumap_mask is to record the usage of EL2 MPU memory regions.
>>> + * Bit 0 represents MPU memory region 0, bit 1 represents MPU memory
>>> + * region 1, ..., and so on.
>>> + * If a MPU memory region gets enabled, set the according bit to 1.
>>> + */
>>> +DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
>>> +    __section(".data.page_aligned");
>>
>> Why does this need to be page_aligned?
> 
> I see from the linker file that this section is aligned to SMP_CACHE_BYTES

The start of the section is cache aligned. But that may not be the case 
for the content within the section itself.

Also, .data.page_aligned is used for data that are page size aligned 
(currently 4KB). So everything within that section needs to be declared 
with __aligned(PAGE_SIZE). But AFAIU, the bitmap is only going to be a 
few bytes, correct?. So  think it would be a bad idea for this variable 
to be page aligned because it would end up to be a massive waste of memory.

> , which is L1_CACHE_BYTES
> for Arm, because we are using the invalidate cache I was under the impression that it’s better to have it
> aligned on the cache line

To clarify, L1_CACHE_BYTES is fixed to 128-byte. If I got correctly, 
this is less than the maximum cache line that could exist (256-bytes).

L1_CACHE_BYTES is mainly used as a hint for Xen to try to allocate 
structure in separate cache line. But when cleaning/invalidating a cache 
line, the code can't rely on the data not crossing a cache line. So you 
need a loop to invalidate each line.

Anyway, I think it would make sense to use __cacheline_aligned for both 
as the two variables are going to be used often. We should also make 
force the section to be .data, otherwise the compiler will typically put 
the variable in .bss which cannot be used during early boot. This is 
because the BSS region is not loaded in memory by the bootloader and the 
Image protocol doesn't specify the state of the region, so for 
simplicity, it is zeroed after the MMU/MPU and cache is turned on.

> 
>>
>>> +
>>> +/* EL2 Xen MPU memory region mapping table. */
>>> +pr_t __section(".data.page_aligned") xen_mpumap[MAX_MPU_REGION_NR];
>>
>> I guess for this one this is mandated by the HW?
> 
> same reason above, no other reason (I’m aware of).

.data..page_aligned makes a bit more sense here (along with 
__aligned(PAGE_SIZE)). However, it seems a bit overkill when we only 
need the region to be cache aligned. So I would follow same approach as 
I suggested for the bitmap.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 14 20:09:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 20:09:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984585.1370658 (Exim 4.92)
	(envelope-from )
	id 1uFIPf-0000Nl-Iz; Wed, 14 May 2025 20:09:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984585.1370658; Wed, 14 May 2025 20:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFIPf-0000Ne-G8; Wed, 14 May 2025 20:09:11 +0000
Received: by outflank-mailman (input) for mailman id 984585;
 Wed, 14 May 2025 20:09:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFIPd-0000NY-65
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 20:09:10 +0000
Received: from 1.mo576.mail-out.ovh.net (1.mo576.mail-out.ovh.net
 [178.33.251.173]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4978ee46-30ff-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 22:09:06 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.108.9.253])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4ZyPYs1fnQz2G3j
 for ; Wed, 14 May 2025 20:09:05 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-x5dkc (unknown [10.110.118.120])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 7FECD1FD2E;
 Wed, 14 May 2025 20:09:03 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.111])
 by ghost-submission-5b5ff79f4f-x5dkc with ESMTPSA
 id XSQSDF/4JGgm9hsAasCC5w
 (envelope-from ); Wed, 14 May 2025 20:09: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" 
X-Inumbo-ID: 4978ee46-30ff-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-111S00554af65ee-9925-471f-9134-38fabac865d4,
                    9B436DAC6DFFFB54EA311452D2E4A14E2CA829B8) smtp.auth=krystian.hebel@3mdeb.com
X-OVh-ClientIp:217.171.54.142
Content-Type: multipart/alternative;
 boundary="------------hvjD3qBJB9sl4JxYqxVTCmgZ"
Message-ID: <5aca7ae5-1237-461c-a336-d1c62f3d5c06@3mdeb.com>
Date: Wed, 14 May 2025 22:09:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
To: Andrew Cooper ,
 Sergii Dmytruk , xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
 Ross Philipson , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Lukasz Hawrylko , =?UTF-8?Q?Mateusz_M=C3=B3wka?=
 , trenchboot-devel@googlegroups.com
References: 
 
 
Content-Language: en-US
From: Krystian Hebel 
In-Reply-To: 
X-Ovh-Tracer-Id: 17897586395426367900
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdejleduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptgfkffggfgfuvfevfhfhjgesrgdtreertddvjeenucfhrhhomhepmfhrhihsthhirghnucfjvggsvghluceokhhrhihsthhirghnrdhhvggsvghlseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeehheefhfeiffffledvfeeuvdfgteeiteekvdfhgeegheevleeuvdfgieekteetgfenucffohhmrghinhepkhhisgdrkhhivghvrdhurgdpfehmuggvsgdrtghomhenucfkphepuddvjedrtddrtddruddpvddujedrudejuddrheegrddugedvpdefjedrheelrddugedvrdduuddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehkrhihshhtihgrnhdrhhgvsggvlhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheejiegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=QU1v89ODndJ21lqfMdqKnpKQv3A4VOjyU/XmaEsRvkw=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747253345; v=1;
 b=mkW8TFTereGv0NAirNsZwG+XNMs8QaNObpbtyZ5R3gfLjPN4lknsmIeEDTVUEG0WMQPwLNYM
 70IVKHjzoYlHD8cSwYjFqF5JurKoXS4yRPX/avHBF8eTq4rNvEUhlbDV5Hjk0ecrIWAi4FgY5xz
 g6OO/Y7K4Hf+6IMtb2CAAmFUiZCwnBKaLdPnROxuwHMIa/RtL/3FRJ4Z1sUNh1jy4+g5hoKT3KI
 8hTUKjV+nyzHny96tluxKYpiDdVJOo1JX3Yp/Y6Gkxf92/IXC9Dwweyl4pbOQWDRBdKbrufFVY5
 u2rg/2zfSwDdGYEMnt5CE93u3QRDqud5UJjGMiVWNcDRg==

This is a multi-part message in MIME format.
--------------hvjD3qBJB9sl4JxYqxVTCmgZ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 14.05.2025 16:55, 'Andrew Cooper' via trenchboot-devel wrote:
> On 13/05/2025 6:05 pm, Sergii Dmytruk wrote:
>> diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
>> new file mode 100644
>> index 0000000000..07be43f557
>> --- /dev/null
>> +++ b/xen/arch/x86/include/asm/intel-txt.h
>> @@ -0,0 +1,277 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +
> Please have at least a one-liner introduction to what TXT is.  Is there
> a stable URL for the TXT spec?  (I can't spot an obvious one, googling
> around)
Not an official source and I don't know if it would be OK to use it
here, but my go-to source is https://kib.kiev.ua/x86docs/Intel/TXT/,
it even has previous versions, which may be helpful in understanding
some of deprecated (e.g. related to TPM 1.2) intricacies of
implementation.
>> +{
>> +    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
>> +    return *reg;
>> +}
>> +
>> +static inline void write_txt_reg(int reg_no, uint64_t val)
>> +{
>> +    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
>> +    *reg = val;
>> +    /* This serves as TXT register barrier */
>> +    (void)read_txt_reg(TXTCR_ESTS);
> What is this barrier for?
>
> It's not for anything in the CPU side of things, because UC accesses are
> strictly ordered.
>
> I presume it's for LPC bus ordering then, but making every write be a
> write/read pair seems very expensive.
According to TXT spec, it is required only for TXT.CMD.CLOSE-PRIVATE
and TXT.CMD.UNLOCK-MEM-CONFIG, and it probably could be changed to any
other serializing instruction. IIRC, those registers are written to
only in txt_reset(), so maybe adding a barrier there would suffice.
>> +/*
>> + * Functions to extract data from the Intel TXT Heap Memory. The layout
>> + * of the heap is as follows:
>> + *  +------------------------------------+
>> + *  | Size of Bios Data table (uint64_t) |
>> + *  +------------------------------------+
>> + *  | Bios Data table                    |
>> + *  +------------------------------------+
>> + *  | Size of OS MLE table (uint64_t)    |
>> + *  +------------------------------------+
>> + *  | OS MLE table                       |
>> + *  +--------------------------------    +
>> + *  | Size of OS SINIT table (uint64_t)  |
>> + *  +------------------------------------+
>> + *  | OS SINIT table                     |
>> + *  +------------------------------------+
>> + *  | Size of SINIT MLE table (uint64_t) |
>> + *  +------------------------------------+
>> + *  | SINIT MLE table                    |
>> + *  +------------------------------------+
>> + *
>> + *  NOTE: the table size fields include the 8 byte size field itself.
>> + */
>> +static inline uint64_t txt_bios_data_size(void *heap)
>> +{
>> +    return *((uint64_t *)heap) - sizeof(uint64_t);
>> +}
> This is quite horrible, but I presume this is as specified by TXT?
Yes.
> To confirm, it's a tightly packed data structure where each of the 4
> blobs is variable size?  Are there any alignment requirements on the
> table sizes?  I suspect not, given the __packed attributes.
Yes, those are all of variable sizes. TXT specification notes that all
of the sizes must be a multiple of 8 bytes, but we've seen platforms
where BiosData (filled by BIOS ACM, so beyond our control) isn't
aligned, which makes following fields also unaligned. Because of that,
we treated it as if there was no such requirement.

-- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com  | @3mdeb_com

--------------hvjD3qBJB9sl4JxYqxVTCmgZ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    
    On 14.05.2025 16:55, 'Andrew Cooper'
      via trenchboot-devel wrote:
    
    
    
    
    
      
    On 13/05/2025 6:05 pm, Sergii Dmytruk wrote:

    
      
    
        
    diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
new file mode 100644
index 0000000000..07be43f557
--- /dev/null
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -0,0 +1,277 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+

    
      
    
      
    Please have at least a one-liner introduction to what TXT is.  Is there
a stable URL for the TXT spec?  (I can't spot an obvious one, googling
around)
    
    
    
    Not an official source and I don't know if it would be OK to use it
    
    here, but my go-to source is https://kib.kiev.ua/x86docs/Intel/TXT/,
    
    it even has previous versions, which may be helpful in understanding
    
    some of deprecated (e.g. related to TPM 1.2) intricacies of
    
    implementation.
    
    
    


      
    
        
    +{
+    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
+    return *reg;
+}
+
+static inline void write_txt_reg(int reg_no, uint64_t val)
+{
+    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
+    *reg = val;
+    /* This serves as TXT register barrier */
+    (void)read_txt_reg(TXTCR_ESTS);

    
      
    
      
    What is this barrier for?

It's not for anything in the CPU side of things, because UC accesses are
strictly ordered.

I presume it's for LPC bus ordering then, but making every write be a
write/read pair seems very expensive.
    
    
    
    According to TXT spec, it is required only for TXT.CMD.CLOSE-PRIVATE
    
    and TXT.CMD.UNLOCK-MEM-CONFIG, and it probably could be changed to
    any
    
    other serializing instruction. IIRC, those registers are written to
    
    only in txt_reset(), so maybe adding a barrier there would suffice.
    
    
    


      
    
        
    +/*
+ * Functions to extract data from the Intel TXT Heap Memory. The layout
+ * of the heap is as follows:
+ *  +------------------------------------+
+ *  | Size of Bios Data table (uint64_t) |
+ *  +------------------------------------+
+ *  | Bios Data table                    |
+ *  +------------------------------------+
+ *  | Size of OS MLE table (uint64_t)    |
+ *  +------------------------------------+
+ *  | OS MLE table                       |
+ *  +--------------------------------    +
+ *  | Size of OS SINIT table (uint64_t)  |
+ *  +------------------------------------+
+ *  | OS SINIT table                     |
+ *  +------------------------------------+
+ *  | Size of SINIT MLE table (uint64_t) |
+ *  +------------------------------------+
+ *  | SINIT MLE table                    |
+ *  +------------------------------------+
+ *
+ *  NOTE: the table size fields include the 8 byte size field itself.
+ */
+static inline uint64_t txt_bios_data_size(void *heap)
+{
+    return *((uint64_t *)heap) - sizeof(uint64_t);
+}

    
      
    
      
    This is quite horrible, but I presume this is as specified by TXT?
    
    
    
    Yes.


    
    
      
    To confirm, it's a tightly packed data structure where each of the 4
blobs is variable size?  Are there any alignment requirements on the
table sizes?  I suspect not, given the __packed attributes.
    
    
    
    Yes, those are all of variable sizes. TXT specification notes that
    all
    
    of the sizes must be a multiple of 8 bytes, but we've seen platforms
    
    where BiosData (filled by BIOS ACM, so beyond our control) isn't
    
    aligned, which makes following fields also unaligned. Because of
    that,
    
    we treated it as if there was no such requirement.
    
    
    -- 
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com
    
  


--------------hvjD3qBJB9sl4JxYqxVTCmgZ--


From xen-devel-bounces@lists.xenproject.org Wed May 14 20:45:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 20:45:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984598.1370668 (Exim 4.92)
	(envelope-from )
	id 1uFIyF-0005Od-AN; Wed, 14 May 2025 20:44:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984598.1370668; Wed, 14 May 2025 20: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 1uFIyF-0005OW-7n; Wed, 14 May 2025 20:44:55 +0000
Received: by outflank-mailman (input) for mailman id 984598;
 Wed, 14 May 2025 20:44:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFIyD-0005OQ-De
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 20:44:53 +0000
Received: from fout-a3-smtp.messagingengine.com
 (fout-a3-smtp.messagingengine.com [103.168.172.146])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 47468fa0-3104-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 22:44:50 +0200 (CEST)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfout.phl.internal (Postfix) with ESMTP id E9547138013A;
 Wed, 14 May 2025 16:44:48 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-11.internal (MEProxy); Wed, 14 May 2025 16:44:48 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 14 May 2025 16:44:47 -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" 
X-Inumbo-ID: 47468fa0-3104-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1747255488;
	 x=1747341888; bh=iJ0vJqhIGZJBpwt+D86/46QK11/UU8qOT/wKD4IEqYo=; b=
	nGWWn745aAlieKM+nFCwNOjXt3T9eltcGFK9+xyD9S7rhg7/pgQAKZdn/cR9W381
	3swkiKd70lumuxz/cy4XJBfxZtkC5F25MeFXF7ZJ0U6ScuQ25WBURlE0K/sGqsPn
	1AOGA1952r7t4MbTTQMlbAJAHSU3l8mUeaGv9jZhe/cpyH7KtxZjZGvcL3tlIjNt
	Z5w5G61G4f4wLYDT2n3SXryTI235R05W97uLSqPs1MetEYInD4tgt826Ozvz9pUU
	m2Mk0tSMHy6ql6xHPgYH1j5FSEX3152ZyJNMF/CD2qdOqexl1RnXJHbxvNP463oj
	2t4Eu+aoZkbAygWFuchaJQ==
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=fm3; t=
	1747255488; x=1747341888; bh=iJ0vJqhIGZJBpwt+D86/46QK11/UU8qOT/w
	KD4IEqYo=; b=Y5mDe9MZzmwPKcMzPKGGZk23OZcCTrBYwu0rroduEV9ceXWgVXS
	lcGIyuenccUsQ/GJsMp/WL9bHokcCe/p+SgEUixvCjNp87vZmlGihnYm7KZ9cld0
	0ycKMraFkdEEvAdgY0hYErzBBlJmxHvaSrSTAUqAEU10QMRCky4AxnLGVVagOrpg
	xiNzb85di4DRvFr2mm75gB3VUXW4r734oGTvY2zCUhEjy1rqrfnXqacZEQZ5TgvR
	6j5q1Y7y+hdkn/yh3z5gYDq7GH26DRymMFo6AOw6G56wArPEjsBy0NIEwOvXgEPf
	8sS0Ir2z4zDU6Qc+o5MqQ8D2swWBM49zlNg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdejleekucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepieeluddvkeejueekhfffteegfeeiffefjeejvdeijedvgfejhe
    etuddvkeffudeinecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghr
    ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvh
    hishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeegpdhmohgu
    vgepshhmthhpohhuthdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg
    homhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtohep
    rghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopeigvg
    hnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 14 May 2025 22:44:45 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: Jan Beulich ,
	Andrew Cooper ,
	xen-devel 
Subject: Re: Assertion 'desc->arch.creator_domid == DOMID_INVALID' failed
Message-ID: 
References: 
 <70e5eeee-f1fa-41b4-91eb-450edc0bcaca@suse.com>
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="089t04zKiO2x5yFC"
Content-Disposition: inline
In-Reply-To: 


--089t04zKiO2x5yFC
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 May 2025 22:44:45 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: Jan Beulich ,
	Andrew Cooper ,
	xen-devel 
Subject: Re: Assertion 'desc->arch.creator_domid == DOMID_INVALID' failed

On Wed, May 14, 2025 at 10:55:15AM +0200, Roger Pau Monn=C3=A9 wrote:
> On Wed, May 14, 2025 at 10:44:34AM +0200, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > On Wed, May 14, 2025 at 09:09:08AM +0200, Jan Beulich wrote:
> > > On 13.05.2025 21:20, Marek Marczykowski-G=C3=B3recki wrote:
> > > > Hi,
> > > >=20
> > > > When debugging CI job on Linus' master branch, I added "console=3Dv=
ga vga=3D,keep" and got PV dom0 crash Xen with:
> > > >=20
> > > > (XEN) [   40.870435] Assertion 'desc->arch.creator_domid =3D=3D DOM=
ID_INVALID' failed at arch/x86/irq.c:294
> > > > (XEN) [   40.886925] ----[ Xen-4.21-unstable  x86_64  debug=3Dy ubs=
an=3Dy  Not tainted ]----
> > > > (XEN) [   40.903356] CPU:    10
> > > > (XEN) [   40.919824] RIP:    e008:[] create_irq+0=
x272/0x339
> > > > (XEN) [   40.936267] RFLAGS: 0000000000010297   CONTEXT: hypervisor=
 (d0v13)
> > > > (XEN) [   40.952709] rax: 00000000fffffff4   rbx: ffff830498007c00 =
  rcx: 0000000000001899
> > >=20
> > > There looks to be a -ENOMEM in %rax, so ...
> > >=20
> > > > (XEN) [   40.969147] rdx: ffff830498007c5e   rsi: 0000000000000002 =
  rdi: ffff83049830e398
> > > > (XEN) [   40.985892] rbp: ffff830498307d18   rsp: ffff830498307ce8 =
  r8:  0000000000000000
> > > > (XEN) [   41.003093] r9:  0000000000000000   r10: 0000000000000000 =
  r11: 0000000000000000
> > > > (XEN) [   41.020279] r12: 00000000fffffff4   r13: 000000000000007c =
  r14: ffffffffffffffff
> > > > (XEN) [   41.037489] r15: 000000000000007c   cr0: 0000000080050033 =
  cr4: 0000000000b526e0
> > > > (XEN) [   41.054699] cr3: 0000000492c34000   cr2: ffff8881001603f0
> > > > (XEN) [   41.071904] fsb: 0000000000000000   gsb: ffff8882365ac000 =
  gss: 0000000000000000
> > > > (XEN) [   41.089116] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss=
: e010   cs: e008
> > > > (XEN) [   41.106320] Xen code around  (create_irq=
+0x272/0x339):
> > > > (XEN) [   41.123521]  3f d9 ff e9 cc fe ff ff <0f> 0b 48 8d 3d 5a a=
0 29 00 e8 f4 3d d9 ff c6 43
> > > > (XEN) [   41.140739] Xen stack trace from rsp=3Dffff830498307ce8:
> > > > (XEN) [   41.157931]    000000ff00000001 ffff830497faa000 ffff83049=
8307e00 00000000ffffffff
> > > > (XEN) [   41.175132]    0000000000010000 ffff830497faa160 ffff83049=
8307d70 ffff82d0405a6f85
> > > > (XEN) [   41.192351]    00000000000002a0 ffff830498307e24 000000000=
0000200 00000000ffffffff
> > > > (XEN) [   41.209551]    ffff830497faa000 0000000000000000 ffff83049=
7faa168 0000000000010000
> > > > (XEN) [   41.226753]    ffff830497faa160 ffff830498307de0 ffff82d04=
05c9ea6 5f24a0ddbbeda194
> > > > (XEN) [   41.244062]    ffff830498307e10 0000000000000000 000000000=
0000001 ffff830498307e00
> > > > (XEN) [   41.261387]    ffff830498307e24 ffff830498307e20 ffff83049=
7faa000 ffff830498307ef8
> > > > (XEN) [   41.278730]    ffff830497faa000 ffff830497f5a000 ffffc9004=
002ba78 ffff830498307e68
> > > > (XEN) [   41.296052]    ffff82d0405cbd4f ffff82d04053fc3e ffffc9004=
002ba78 00000000000000a0
> > > > (XEN) [   41.313381]    00a0fb0000000001 0000000000000000 000000000=
0007ff0 ffffffffffffffff
> > > > (XEN) [   41.330708]    000000a000000000 0000000000000000 000000000=
0000000 ffff830498307ef8
> > > > (XEN) [   41.348026]    ffff830497f5a000 0000000000000021 000000000=
0000000 ffffc9004002ba78
> > > > (XEN) [   41.365357]    ffff830498307ee8 ffff82d0405427db ffff8881d=
6961b40 0000000000000001
> > > > (XEN) [   41.382680]    000000a000000000 000000000000000d 000000000=
0000000 ffff830498307ee8
> > > > (XEN) [   41.400003]    ffff82d0405e7bc2 ffff830497f5a000 000000000=
0000000 ffff830497f5a000
> > > > (XEN) [   41.417343]    0000000000000000 0000000000000000 ffff83049=
8307fff 0000000000000000
> > > > (XEN) [   41.434674]    00007cfb67cf80e7 ffff82d0402012d3 ffff8881d=
6961b40 ffff888100ef30c0
> > > > (XEN) [   41.452010]    0000000000000001 0000000000000005 000000000=
0000000 ffff888100ef3000
> > > > (XEN) [   41.469342]    0000000000000202 0000000000000001 000000000=
0007ff0 ffff8881d6961b40
> > > > (XEN) [   41.486681]    0000000000000021 ffffffff8229d355 000000a00=
0000000 ffffc9004002ba78
> > > > (XEN) [   41.504015] Xen call trace:
> > > > (XEN) [   41.521314]    [] R create_irq+0x272/0x3=
39
> > >=20
> > > ... I'd expect the function calling init_one_irq_desc() to have cause=
d this.
> > > In which case, yes, the assertion is certainly valid to trigger (as i=
t's
> > > arch_init_one_irq_desc() which sets the field to the expected value, =
yet
> > > that won't happen if one of the involved allocations fails). I'll mak=
e a
> > > patch, but this raises the question of how you're running Xen, when
> > > seemingly small allocations like the ones involved here end up failin=
g.
> >=20
> > That's weird, there should be plenty of memory. Xen is started with
> > dom0_mem=3D4G and it's a 16GB system.
>=20
> I wouldn't be surprised that you are impacted by:
>=20
> https://lore.kernel.org/xen-devel/20250514080427.28129-1-roger.pau@citrix=
=2Ecom/
>=20
> If the kernel is built without CONFIG_XEN_UNPOPULATED_ALLOC.  Sorry,
> that was my fault.

This appears to have helped, thanks!

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--089t04zKiO2x5yFC
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmglAL0ACgkQ24/THMrX
1yy6VQf/WsuUnwvnstQAbbtr14cD6/1nxjrxN3jIzS1x5XZXlltWQUsreUr5zMLT
fLade9aEQVdDwMdblppeKJdLslno2IlPC2xNEIvCsW5CwZDXSgQP+eU2imosR33C
OsPBrT7mhNK8pLfuXmjSALflKjtqtOtcUbZtrZChtIIwLMgzkUcaswtWev9561kw
TV10mAC4yfMS2RXbrvGQBXuFaFGrvR1lh54ygoT2NjiuwW53pAHbdlQ0eGkLacF6
ZCprBU8hlw1N/nTG2C/vyIDM/oyZPROy2AtpPMjqc3NGO7Fl+oq48uruRdUz8Ce5
97qfdyrJCImWjIqDPI9et6yoe8WN0Q==
=Mxj4
-----END PGP SIGNATURE-----

--089t04zKiO2x5yFC--


From xen-devel-bounces@lists.xenproject.org Wed May 14 21:12:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 21:12:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984618.1370678 (Exim 4.92)
	(envelope-from )
	id 1uFJOu-0000vq-Dk; Wed, 14 May 2025 21:12:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984618.1370678; Wed, 14 May 2025 21:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFJOu-0000vj-AV; Wed, 14 May 2025 21:12:28 +0000
Received: by outflank-mailman (input) for mailman id 984618;
 Wed, 14 May 2025 21:12:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFJOt-0000vb-AZ
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 21:12:27 +0000
Received: from fhigh-a6-smtp.messagingengine.com
 (fhigh-a6-smtp.messagingengine.com [103.168.172.157])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2141cc3c-3108-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 23:12:24 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 2B01F11400B4;
 Wed, 14 May 2025 17:12:23 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Wed, 14 May 2025 17:12:23 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 14 May 2025 17:12:22 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2141cc3c-3108-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1747257143;
	 x=1747343543; bh=L2ZpPPDQO4CfCu7s+vmi058egKPHsQJqKSoUVSUvTQg=; b=
	jFLD+riX2vThFbCrHWPHoaX8RXngNUc23+OHK/Y/XHQUcLKiSdfJlofHHeC6wLZZ
	O95JMZQGPaMRqs+/z4TWrJD9cx8PTDzaii3U2DbtiV0Lsxm4UPHgTpbtYEUkZyYl
	zreW+uAq3KcFOqkDezKNQ9Gx7GsiCLJ7L6cndbRf4zksx2PsRYvHFn8SotUUyKbn
	1QEHbNbSnR2tVKLVLCGk9wmwAIZGlXlQ3Y+DmWBZwZMg70l1x9cPLaqjBRq9j4aU
	RNISNK+eKhPIndKuTfh0BI6JKaq65v8sO/kA+F0O6NfYl9uyksvVxheW4ivfRfXM
	jQBIe9SLW8kLPea1FLiiNA==
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=fm3; t=
	1747257143; x=1747343543; bh=L2ZpPPDQO4CfCu7s+vmi058egKPHsQJqKSo
	UVSUvTQg=; b=bfCnB5ddW6ZTfVGoKI8rU7MQ2JdT5RyWexsDLaaDBJH81N4K/6z
	si0JwQymkU05Eb/COBH2tj2NztdPms+2xL9moy+7AxE3J0vtnJIH1RWJqd/2UDnL
	8y5Qvx0rBGwjGAN2gpHKsY2KlxqyVBh+n/8i4dxAK0a14MkETG7BaQD3Ci7Ot+4o
	DPoTdqjgXItQ1GBxHGwa8BHb049SPngaGB1jDowiUP87v5CayyqCtypupR6AKK6V
	gRqMzyD0LObM9PMk8ld+onRyHTuBjDN/Fz4A+uQh1hY1u6v0V+aWdfuVZYwMDb+S
	Xd7Upwt7RrDLiSGtImMT3ZxbPy8VqTuEHfQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdektdefucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepveeujeetgeelleetudeuvefhtefgffejvedtvdfgieevheethe
    elgeeuledvjeevnecuffhomhgrihhnpehgihhtlhgrsgdrtghomhenucevlhhushhtvghr
    ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvh
    hishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedvpdhmohgu
    vgepshhmthhpohhuthdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg
    homhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggt
    thdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 14 May 2025 23:12:20 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner
Message-ID: 
References: 
 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="a0Lb7Tr47sSMdF5s"
Content-Disposition: inline
In-Reply-To: 


--a0Lb7Tr47sSMdF5s
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 May 2025 23:12:20 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner

On Mon, May 12, 2025 at 05:11:53PM +0200, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Mon, May 12, 2025 at 04:50:22PM +0200, Roger Pau Monn=C3=A9 wrote:
> > On Mon, May 12, 2025 at 04:40:29PM +0200, Marek Marczykowski-G=C3=B3rec=
ki wrote:
> > > On Mon, May 12, 2025 at 04:19:59PM +0200, Roger Pau Monn=C3=A9 wrote:
> > > > On Mon, May 12, 2025 at 03:31:19PM +0200, Marek Marczykowski-G=C3=
=B3recki wrote:
> > > > > On Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monn=C3=A9 wr=
ote:
> > > > > > On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-G=
=C3=B3recki wrote:
> > > > > > > Hi,
> > > > > > >=20
> > > > > > > I wanted to post another revision of the series adding hw12 r=
unner,
> > > > > > > hoping that all known issues are fixed now, but unfortunately=
 there is
> > > > > > > still something broken. I've rebased my series on top of stag=
ing
> > > > > > > (ed9488a0d) and got this pipeline:
> > > > > > >=20
> > > > > > > https://gitlab.com/xen-project/people/marmarek/xen/-/pipeline=
s/1807819142
> > > > > > > (note due to some added debugging, some tests are incorrectly=
 marked as
> > > > > > > success even if they failed...)
> > > > > > >=20
> > > > > > > 1. USB ethernet doesn't work on PVH dom0: https://gitlab.com/=
xen-project/people/marmarek/xen/-/jobs/9978694739
> > > > > > > There supposed to be an USB ethernet device connected to the =
USB
> > > > > > > controller at c3:00.4. In the PV dom0 case it's detected as:
> > > > > > >=20
> > > > > > >     [    3.911555] usb 7-1.4: new high-speed USB device numbe=
r 3 using xhci_hcd
> > > > > > >     [    4.004201] usb 7-1.4: New USB device found, idVendor=
=3D0bda, idProduct=3D8153, bcdDevice=3D30.00
> > > > > > >     [    4.004675] usb 7-1.4: New USB device strings: Mfr=3D1=
, Product=3D2, SerialNumber=3D6
> > > > > > >     [    4.005079] usb 7-1.4: Product: USB 10/100/1000 LAN
> > > > > > >     [    4.005349] usb 7-1.4: Manufacturer: Realtek
> > > > > > >     [    4.005599] usb 7-1.4: SerialNumber: 684D35
> > > > > > >=20
> > > > > > > But it's not there on PVH. The USB controller itself is detec=
ted, just
> > > > > > > not device(s) connected to it. This applies to other controll=
ers too
> > > > > > > (there should be about 3 or 4 other USB devices - none of the=
m show up).
> > > > > > >=20
> > > > > > > 2. There is a bunch of "unhandled memory read" errors during =
PVH dom0
> > > > > > > startup: https://gitlab.com/xen-project/people/marmarek/xen/-=
/jobs/9978694739
> > > > > > >=20
> > > > > > >     (XEN) [    4.026323] arch/x86/hvm/emulate.c:417:d0v0 unha=
ndled memory read from 0xfedc0020 size 1
> > > > > > >     (XEN) [    4.026789] arch/x86/hvm/emulate.c:417:d0v0 unha=
ndled memory read from 0xfedc0021 size 1
> > > > > > >     (XEN) [    4.027247] arch/x86/hvm/emulate.c:417:d0v0 unha=
ndled memory read from 0xfedc0020 size 1
> > > > > > >     (XEN) [    4.027671] arch/x86/hvm/emulate.c:417:d0v0 unha=
ndled memory read from 0xfedc0021 size 1
> > > > > > >     ...
> > > > > > >=20
> > > > > > > This repeats several times. Could be related to the USB issue=
 above?
> > > > > >=20
> > > > > > Can you try with dom0=3Dpf-fixup?  Those unhandled accesses mig=
ht be the
> > > > > > cause of the USB issues.
> > > > >=20
> > > > > It did got rid of those messages, but USB still doesn't work:
> > > > > https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/1000658=
0289
> > > >=20
> > > > Hm, is it possible that the usage of console=3Dxhci is interfering =
with
> > > > USB devices?  Could you try to boot without console=3Dxhci and see =
if
> > > > you can still reproduce the issue?  You will need the physical devi=
ce
> > > > by your side, which I'm not sure it's possible.  Don't know if you
> > > > host those remotely somewhere.
> > >=20
> > > I can try, but will need a proper driver there (in dom0?) - AFAIR VGA
> > > nor efifb doesn't output to HDMI there (and eDP is not connected).
> > > Anyway, it's IMO unlikely, given it works just fine with PV dom0...
> >=20
> > Oh, I see, that's a good data point that it works with PV dom0.
> > Handling of r/o subpage accesses is still different between PV and PVH
> > which could maybe explain this, but it's less likely.
> >=20
> > Maybe I'm not spotting it, but I don't see any specific errors (like
> > timeouts) from the XHCI controller on the log?  Neither there seems to
> > be any errors or warnings from Xen.
>=20
> I don't see any either...

Roger, it looks like your balloon patch fixes the USB case too :)

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--a0Lb7Tr47sSMdF5s
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmglBzQACgkQ24/THMrX
1ywRLgf+OhDxM87oIt4TdU8ldQchCfEpn6pJqOomhURVC1SHuKOyhfqnrywC9c3h
6MEMzABbiSFkZjVT/tYEWqWv8QYBK5M6nVaKyTdoKcVr/C1hXLAm2ykTIvcRa93B
wbkO4o1AdhdCVXZ1/wF6uQWi2PN92F1wwuyIZKnAD581SBn/pKzbG+PBUBKdurXw
cG0w0Wp2D+LyT6Ge6nsoHPCvArf1lo/oy9Vt0nuzt6VZ0kfYE24un/EIuoEAVLl8
BeWQP0z83+InWhxdsa+UXTpFrqOp2/WLX5ydOkPIMx0G48IEb5mE11j3pNjLozW0
rXxjlfEAHiKm0ecY5XK5OE7b5QwJww==
=v/w7
-----END PGP SIGNATURE-----

--a0Lb7Tr47sSMdF5s--


From xen-devel-bounces@lists.xenproject.org Wed May 14 21:17:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 14 May 2025 21:17:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984627.1370688 (Exim 4.92)
	(envelope-from )
	id 1uFJTt-0001Vl-SU; Wed, 14 May 2025 21:17:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984627.1370688; Wed, 14 May 2025 21:17:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFJTt-0001Ve-Po; Wed, 14 May 2025 21:17:37 +0000
Received: by outflank-mailman (input) for mailman id 984627;
 Wed, 14 May 2025 21:17:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFJTt-0001VY-5L
 for xen-devel@lists.xenproject.org; Wed, 14 May 2025 21:17:37 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id da3a0319-3108-11f0-9ffb-bf95429c2676;
 Wed, 14 May 2025 23:17:35 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id CDB775C688D;
 Wed, 14 May 2025 21:15:15 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25D29C4CEE3;
 Wed, 14 May 2025 21:17: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" 
X-Inumbo-ID: da3a0319-3108-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747257452;
	bh=gD2MfOwcb20uzAPPjK9S+mJGWOBbAOo1BETu6Sl594c=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=VE2a1TaP9sWrpRd4/5crwFRDW5CCT/j/IcFPJPzfkEoxuwSRjboZy0h/z8733FSL9
	 HLaLCE8UnOjzucx65mymFB9GLFmFYgS83Ohpm3uWW/2zn5kUaj0czMBTXDZ9hwZhDh
	 Z04QKIQgn5V+j+aIz9llBj3Ggy8faKGKxxFU0QpCyshTP/GRTGQzCErHflyztColMR
	 vAZCE2yAHpzL84QF9RhlmiMKE9F85i8GfqT+4VvMpPxGO5TScl6bCIQfEsvc5geX8V
	 0eYAtE/0E2zST4TTqY0lav76Q6DIBU6Lpb86wTqVGZi2XvyKADMZ/p6QlbJgro8/0K
	 h2ITgFw17Yh1w==
Date: Wed, 14 May 2025 14:17:29 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Oleksii Kurochko , 
    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
Subject: Re: [PATCH v2 05/16] xen/asm-generic: introduce
 asm-generic/irq-dt.h
In-Reply-To: <74c6872a-7221-4656-8655-16b53f9b2bd7@suse.com>
Message-ID: 
References:  <35c68e57e5348c6610e030890802e967f6be4230.1746530883.git.oleksii.kurochko@gmail.com> <74c6872a-7221-4656-8655-16b53f9b2bd7@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 14 May 2025, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
> > Introduce defintions of IRQ_TYPE_* which correspond to the Xen internal
> > representation of the IRQ types and make them the same asthe existing
> > device tree defintions for convenience.
> > 
> > These defines are going to be re-used, at least, by RISC-V architecture.
> > 
> > Signed-off-by: Oleksii Kurochko 
> 
> Acked-by: Jan Beulich 
> 
> Assuming an Arm ack would arrive, this looks like it's independent of the
> earlier patches, and hence could go in right away?

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Thu May 15 00:07:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 00:07:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984671.1370699 (Exim 4.92)
	(envelope-from )
	id 1uFM8N-0004jQ-M2; Thu, 15 May 2025 00:07:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984671.1370699; Thu, 15 May 2025 00:07: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 1uFM8N-0004jJ-Ig; Thu, 15 May 2025 00:07:35 +0000
Received: by outflank-mailman (input) for mailman id 984671;
 Thu, 15 May 2025 00:07:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFM8M-0004jD-C2
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 00:07:34 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 98362e31-3120-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 02:07:32 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 69CD74A4F7;
 Thu, 15 May 2025 00:07:30 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD763C4CEE3;
 Thu, 15 May 2025 00:07: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" 
X-Inumbo-ID: 98362e31-3120-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747267650;
	bh=1U6oYZJvUXRtgGFH1POvW7251fxzm9OGOMX59lSq5rM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=jMt9vZw1FUjNbamBZrlQkOapp9zPMSIMujAEzbtv4xuBHniO86WtbZcSmq56PIbXR
	 FfmKVzVX/LLjsXR1q+rafpS14aIPIp8+Hy+tsOE3Tq81S8yfm/mAwusGEfuyAkVpkx
	 TjCRx3fvRkbrWVuLOdk7MZwZkA/0ICbUu3PkNmVIIjkHwgG7pluFAWSkrxd9y1IQ83
	 LaJwMrGUxKfqJCQoQwV8b68XDcGLaDFRKH2SgsaEIUuJmtiacg9wxZOidyRfv+Lcl8
	 k/pX92p/w0CCz+eN6x7cL1rIv2nUmzRhPmOZtYrCIrU/DLGm7zVUnUhhLl9a03pVGh
	 9tsI7+R757RKA==
Date: Wed, 14 May 2025 17:07:27 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "Orzel, Michal" 
cc: Julien Grall , 
    Oleksii Kurochko , 
    xen-devel@lists.xenproject.org, 
    Stefano Stabellini , 
    Bertrand Marquis , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU
 construction
In-Reply-To: 
Message-ID: 
References:   <0acae8dd-d4d6-4d65-909d-637c4a283ea7@xen.org> <6ec7c286-a6c4-491b-8733-42037ba3b91a@gmail.com>
 <44143db1-1766-4851-9a0c-7428dce9087d@xen.org>   
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 14 May 2025, Orzel, Michal wrote:
> > Sure. But my point is rather more that static memory is not a feature 
> > described by the Arm Arm. Instead, it is a feature of Xen that is ti to 
> > device-tree. So inherently there is no reason to be implemented in arch/arm.
> I agree, it can and should be made common. But exposing only callers makes no
> sense at all for me. Callers should be exposed together with feature code movement.

[...]

> >>> back to Arm for then moving back to common potentially in a few weeks time.
> >> What about static memory code? With the recent Oleksii code movement, the inline
> >> helpers like allocate_static_memory() became unreachable when the feature is
> >> disabled and the main purpose for helpers was to avoid ifdefery.
> > 
> > Sorry I am not sure which part you are referring to.
> With the current code, allocate_static_memory(), assign_static_memory_11()
> callers (that were moved to common) are protected with #ifdef. This causes the
> helpers defined in case CONFIG_STATIC_MEMORY is not defined to be unreachable
> (see static-memory.h).

At a high level I agree with Julien, this is the kind of feature that
should be common. In fact, I would even say that I consider the related
device tree bindings common.  But looking at the code movements and the
#ifdef's, I think that as of today, this patch series is improving
things.

So my Ack was not at all a statement to say that the feature should be
Arm-only. To the contrary. But it was only a practical consideration
about the state of the code right now.

I do think that RISC-V should gain support for it at some point and we
should share the code as much as possible.


From xen-devel-bounces@lists.xenproject.org Thu May 15 06:46:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 06:46:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984779.1370709 (Exim 4.92)
	(envelope-from )
	id 1uFSMM-0006lW-0d; Thu, 15 May 2025 06:46:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984779.1370709; Thu, 15 May 2025 06:46: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 1uFSML-0006lK-Sp; Thu, 15 May 2025 06:46:25 +0000
Received: by outflank-mailman (input) for mailman id 984779;
 Thu, 15 May 2025 06:46:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFSMK-0006in-RJ
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 06:46:24 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4eca9434-3158-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 08:46:19 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ad4d03700e6so89701166b.3
 for ; Wed, 14 May 2025 23:46: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
 a640c23a62f3a-ad2197bd37dsm1051599466b.124.2025.05.14.23.46.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 23:46: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" 
X-Inumbo-ID: 4eca9434-3158-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747291581; x=1747896381; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=1YpvPcSjXKUHMYH8M2xEo9gcgitIwHrVEuJEATILAng=;
        b=RaTKUe71Y6aNWgCEHdLrZ/2dXFKqKomxU4j3QvYxW9AGZnwktE+gshbC4dDUTp2gZy
         yciVtQK48MC3WbOGkzgIeKZC5MycYUq0JgOWv9icchHSgJ4LdbXqhUKH5rVx2ghf6vm1
         6qP9qsWACj8tRadqy41QeEC/0GcXyUJE4B4wx8Is1t1sCZ4NkslVVy8ccTkDvXNNfZXg
         lrYpLQiEkJe45oUSv5BDUHkjd12Npu9f2P9/3h38sQUVe9wNYAV2Wb3w0hOa3Yo3jZp3
         4ZYZECNaY/7+VY6VVB/cRFd68xHWRIY9wK14RyuowrXIVogQZYa8jvlX9iUD0ONotaXz
         eo7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747291581; x=1747896381;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1YpvPcSjXKUHMYH8M2xEo9gcgitIwHrVEuJEATILAng=;
        b=dCfpaeYAwz0MrscQ67wMAc6oWKrxgvm7h1HNhcu4x0AqQY6dyGhYL+yDpFVDaEVnE8
         nNIc84xNlyJfAGzf+9vwZVwyChzhvkkX3YpMNNyPB3cVkstnbIpQ3LjaMoMmSNREY6H/
         PwUbbRodvjsoghxONt+qHfKLB+BhQN07h42jpCnDsL6/HR3R2xAsbChY0WD4wgoAVzGS
         4XP1LSA6V+lXW+pqaO/BJeEb9p5eOCy7E3rPtl4bf5LaK1Ie9uuJbBgitMMVcLxcqH9+
         7z/6vgPlrNIXEodbA9GCVH55ZxwiuVN3NHZdCyqRT3JIV71+c7Ym7Q4Fl0HIsksQ9pho
         G+ew==
X-Gm-Message-State: AOJu0Yw3cmNc4ljV+ozE54rHumGoj3nFlBBe2Zr4IoligqHwBdaSreoq
	JJa+5Ebamw3v5ZlQh/fWhikkJn5i0VUfVFh/nJsbEyYHGs+h11npfsHJ2AjJMezQrEtdXw/z/y0
	=
X-Gm-Gg: ASbGncuFnNLY677EG4q0pz1s7pePjZWb5H4e5NM7ohVJdCYfyyX9ms4IynR1WMteV7h
	PrNJKXvTxWGc+yfL2UywFosU2+bwlwevixx77wSpvOXSpEGTDQ7vodxqUF/7d7+vmfNlfqxO+ai
	kyz4ibftA6rZ9OQ7TPodvXjl1rWYVaPy76pvZJcBHVXZgIj65TRqHN4d0dOCuBWqewckEa34/wb
	hY7hgfwsj4Ub/AGV1x+IhZJLA6SIlQx7A0hF96gyqFlK3YxOvn64P5ycKCGdF8CDO4ySfh/ehWs
	4VsQZwbFNqHBNeUmFTb0Bgp46hnW3VBv2Q7ZmZ+dLnKQxlQLfbV+6fPHKvKBQSK5fqryhyHgPJf
	IRbiMxiQpteiUawHjsMiu3Kc3MKQGK+6cA4di
X-Google-Smtp-Source: AGHT+IFGtS2aIoEVSzVMWVIt8HJtC/bOKKFjkseGTfp4sNj7xLr3cwlqvh2ZW/LXb9dtAnTcYIvSuw==
X-Received: by 2002:a17:907:97c9:b0:ad1:766a:9441 with SMTP id a640c23a62f3a-ad4f71a9f6dmr638296966b.23.1747291581540;
        Wed, 14 May 2025 23:46:21 -0700 (PDT)
Message-ID: <3aa40c42-8f46-499b-8427-d79b25e8bb01@suse.com>
Date: Thu, 15 May 2025 08:46:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/6] x86: FLUSH_CACHE -> FLUSH_CACHE_EVICT
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Wei Liu 
References: 
 
 
 <5aeca684-4ff1-4299-ab07-95d02be12f46@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

On 14.05.2025 16:45, Roger Pau Monné wrote:
> On Wed, May 14, 2025 at 02:52:39PM +0200, Jan Beulich wrote:
>> On 14.05.2025 13:44, Roger Pau Monné wrote:
>>> On Wed, May 03, 2023 at 11:46:41AM +0200, Jan Beulich wrote:
>>>> This is to make the difference to FLUSH_CACHE_WRITEBACK more explicit.
>>>>
>>>> Requested-by: Andrew Cooper 
>>>> Signed-off-by: Jan Beulich 
>>>
>>> Acked-by: Roger Pau Monné 
>>
>> Thanks.
>>
>>> This is however missing the previous calls from SVM/VMX that at this
>>> point in the series have already been switched to write-back instead
>>> of evict.
>>
>> Hence why it's this late in the series, i.e. ...
>>
>>>  Maybe this patch should be the 1st of 2nd, so that changes
>>> from evict to write-back are done afterwards?
>>
>> ... I wanted to avoid touching those places twice. (IOW re-ordering would
>> be possible, with the extra changes you mention, but I'd prefer not to.)
> 
> Given the concerns with patch 2 I think some re-ordering will be
> needed?

Well, if patches 2 and 3 need dropping, this one would naturally move forwards
of course. The more that 1 was already committed, and 4 is soon going to be (as
being independent of 2 and 3).

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 06:46:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 06:46:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984785.1370719 (Exim 4.92)
	(envelope-from )
	id 1uFSMj-00077L-7s; Thu, 15 May 2025 06:46:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984785.1370719; Thu, 15 May 2025 06: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 1uFSMj-00077E-4f; Thu, 15 May 2025 06:46:49 +0000
Received: by outflank-mailman (input) for mailman id 984785;
 Thu, 15 May 2025 06:46:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFSMh-0006in-PY
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 06:46:47 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20602.outbound.protection.outlook.com
 [2a01:111:f403:2415::602])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5cc7f4ab-3158-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 08:46:43 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by MN0PR12MB5858.namprd12.prod.outlook.com (2603:10b6:208:379::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.32; Thu, 15 May
 2025 06:46:42 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%4]) with mapi id 15.20.8722.031; Thu, 15 May 2025
 06:46: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" 
X-Inumbo-ID: 5cc7f4ab-3158-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iMplpcBxrK6kQqARv4FaC7Rkw7CxR3uGfZU8haLro7zdC4ZscZQdNMECkbm0MxhtyO2c9miUI97LKdaB37fNZMs8uuD40pYcBlYxShITLIFGx5nW7zexorutM8j5eJciXi80Rjz8uPLji1P+8y3U2vykRsGNJsJuzFNcmkVbydDhtGbFBzBf0DeC1ZBIqv1myx4BrtuTiIPPRbqTIgR21AJH3q0ztRmTDpwGT3YBqEX00qtzM7sWhztsyu1AegSV8IjtzxW/vWtYcse0BnVsXnZu36aulk9dpKqfOyYCU3vUwTf0JDjgi8qG8bc/7rEvJjur5Pmkrm/ZdVbhE95KBA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SxxI1N4Y+6xmDawm3ZS8BKZzhQdt9UuahaoFkuRjb6w=;
 b=ER85F/EjG1QGKHUUGFqTA2xi5R5ZMOMAqd+Y2Aw6Ag64IDIc/AlyMYzofKzZjkhhmZGmjLebpIb8ByJ/QuahZLFers4XlLGSd3II9bBEJh0IU/sRb8y3E0dkJTm7iP0gcaKtc007mMgplw/lME2wujHKf6uK/SuUQdTvx1TtCAQ3yuGt0vMqAg3NQQY10dFo93ulVTXRaoINHeSjwVPZY4+bcx7RQrw+7KvxAigNyIjyClNkHbT7GGlEfR7KMXw9ibTESjUVAcKhR2E+qF+HCng7uA6gfq88eEUGhwIt2JeKNDhhhpXbn6VhcoD/AYD06i1ImX/W6YmC+cbJa/2vuQ==
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=SxxI1N4Y+6xmDawm3ZS8BKZzhQdt9UuahaoFkuRjb6w=;
 b=mAexZxRl16FqiCw9z9VZubIkQ5rWofaUuWFWALe+XEEARVqusVcH/kRedM+tmCjBAyruW+YHrgp4glVMg3/EiwFyaKcI9cK/cLjVgaXay52v+K2KmbC9+gQVq2QzZBr+1dhUmMOjOJlVBGOHRZUq3mrHvZ+RYd+3qBCy0ZZpoA4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <0c750c15-50f9-4702-9dce-a1122cf60783@amd.com>
Date: Thu, 15 May 2025 08:46:38 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU
 construction
To: Stefano Stabellini 
Cc: Julien Grall ,
 Oleksii Kurochko ,
 xen-devel@lists.xenproject.org, Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 
 <0acae8dd-d4d6-4d65-909d-637c4a283ea7@xen.org>
 <6ec7c286-a6c4-491b-8733-42037ba3b91a@gmail.com>
 <44143db1-1766-4851-9a0c-7428dce9087d@xen.org>
 
 
 
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0350.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:f4::12) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|MN0PR12MB5858:EE_
X-MS-Office365-Filtering-Correlation-Id: 2cb0ca1c-5530-4e9e-c5da-08dd937c4002
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bWo2eTZocCtMSWxkUVlxbEVldFRtTzd5UnpscElKbXByS2wwWklqVGUwSU9D?=
 =?utf-8?B?RjNPcmMwN3V0SnZBQWdNeWQwVUxMM0FEa3lBRzIwWGNGWFhMd3dYbjFMSkhY?=
 =?utf-8?B?T0ROSmc4OUZzc0JBZTI3dnEwdTdxVXdxdnJvTlJNZ0pUVXhEVHhWcHphVVdj?=
 =?utf-8?B?SU9TZUJmWWlaL2VORlJkOXo2eWVQWWJ3V2U0ZUZMeW52UkFsdkV4REExdTdz?=
 =?utf-8?B?ZUtVMlhoNURRMkdpaWErUE8yRXJ6M2p0V1AxSm5qVjFNMGdnS05sQ2RDdHph?=
 =?utf-8?B?KzFBcFczME1xbjJnSEJYa3JIK1U0ZWlzZjFwSFhXTVFNNUcwVC90U215NHM4?=
 =?utf-8?B?dUVEVEllV2FaVXo4ZHpKdVhWcGVWUVVhN2RBRVNCREJwQXhDTGZ6K3JqSW1R?=
 =?utf-8?B?dFlPQzRTRnNvRGtOYWQ4Yk1rSjl1TnlvRHltdkZuNzFGT1RxVVVrS1hvNkhR?=
 =?utf-8?B?T2dUSWxnTUxBaU1MQitpY2xJTTdVdGdmSVVEcDFIb2E0Rk9zdnJyaUo5ODVK?=
 =?utf-8?B?NGF3RElJVzVtKzRpTWdGalZMbFJPZFFVR1I5WjA0WWkwK2VYd2w3cHpPWklY?=
 =?utf-8?B?aVNkSmtnd0t5Z1JWS05sQlBsR1NkWGZlSUtZL3d1MmlhaFRQZXJoOVZyUjhY?=
 =?utf-8?B?WUtiUS9RZWhJSk5RQXNVSEpIMUluSER4YUpJZVpaQUpjUjhhVFhZWU0xU05E?=
 =?utf-8?B?MGNySjJ3bUorU25YNmZCOXZkUDBKNzVYRHlUYTMvNWtEMzFYdWJNQzBBZWVX?=
 =?utf-8?B?ekwyUWsydXpjbnd5TFBZY1JWaG42Z3FrN0dVSVhTUk4zZm8xLzBCeXNzZ3pv?=
 =?utf-8?B?T1B4R2FYaStoOVRBZXBHYUtSN0tteVN3d094WnRHRnM4ejI2bXB3YWNkTTNO?=
 =?utf-8?B?ZzhaQk9oTTZwaDdZR0pCdFNVWmg2UHBrc2dUOXNRSDVJK3c0L2lUajFYbUZo?=
 =?utf-8?B?alZQM3FQUTBWZWJtWmovSEVEVzczdWN4Q1hZZ0FCQW45NDRuNkFOTHA4di9B?=
 =?utf-8?B?ZzNlekJ5YkIwczF3UTIzMCtleGJVcDNZUnFweUo2bmJ3NDVWMHZOSVB6YmtT?=
 =?utf-8?B?UmhBdUcyeFhkZkdCU1FqKzJZZFB3MVZwUDlUVlN1UFBaZ1F2TEs0RlpvUDkw?=
 =?utf-8?B?REM1cTVUdEVzdGU5YXBOWGZHU0pFczVKRkh1bGRzbFZVbUdjakpIbGRiNWZi?=
 =?utf-8?B?NTVyemRKVXZ2VW9iNlVsUmRIMWI1bDk2ZmxZb0RkSWdoWURSM2plbFZzZTdS?=
 =?utf-8?B?VjZaUHRFUDNuTXk4c2M2aWYzRGgvdXRNRTVybUd3cE9BM09HbjhiWlAzVjE5?=
 =?utf-8?B?empuMXBxdmpQWER1ckp4K2k3dXl4UGhLanVrSVNGNE5nVXpDVE1qU3ZhVFF3?=
 =?utf-8?B?OHFBbDVuYW5nUCs0YVBZQWc5eGhmZ1pIT1c4dkRpaGRUZkJPK2tPbm10YVE1?=
 =?utf-8?B?Rm81bGF3bjRJcHVNYUx2dDI1ZkR5NjdvK0xDeEpWSERnVWhoSDBkeFVpSzVu?=
 =?utf-8?B?c3cyc3dXcFVrOHVJQnF0bndoNlZmK3VSMnA1MWYzdzNBZy9rVEEyRTJlNTdF?=
 =?utf-8?B?L2pTc04zcGIrS2Z1STVqY0J4VlFEOTZ4NDVwTU51SFZJYzVuTGxuZFhTSnlB?=
 =?utf-8?B?TWZlc3J1b3A2Ui8rWW5FVVMvdDExQ0RKbTlra1d0TTQvYjVSakJxNjMwNkh4?=
 =?utf-8?B?M28zdUZBcTFkdVBWanZpbGJmYUZ4SlEzTFlBQVdOR2gvek92cU5pWjRYKy9s?=
 =?utf-8?B?cjA2eExTWW9iWHM3NmRsZjdHUVNGTHdabzdYY0VJNmliZld4ZHc0L2dzVGUv?=
 =?utf-8?B?ZXdyT1I5eUpYajFXUjJzdGhVMFpqRmNJV2k4QkpQVU91c20wVXZTSXlDcWYx?=
 =?utf-8?B?WE9wZC9qdHg1anFQMlRGVlNyN1lqeGZIcm45Zy9pZStOTGtZSjNBN2xPOHNT?=
 =?utf-8?Q?j6SbdlMCsFI=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?OTNlbW9mQmVXanFBcmdhMUVkZHZPSlpITG0yOFVNOHc1bjFBNjNEVHducnpZ?=
 =?utf-8?B?VXJLWXBxTEozUWc1TWlvS3NUZFNoRHRyem1BUW9DL1BPWWVDaXN0VzhlTDRJ?=
 =?utf-8?B?ZkcraE5Qa0FaSGkvVURKOGZ4Vkx3Tjl5T2FtSU1nQ0JCRFQrb0F6QWdaQlhz?=
 =?utf-8?B?cG5lY3JMV0E0dTlHbjlEOVNWSTZ4OTdxR2tHUXVHU0R2ckRLeEpXUlhiWER1?=
 =?utf-8?B?bFFKOHorcnBnUldWcitDM3kvenE0Y2YyTkt3UmdKK3RnMVl5L2ttTTA1Rlpi?=
 =?utf-8?B?Z3BEekxEeEdFU0xMWnJxU29tNlVTYXE2Q25HanRQaG8rMnZRMVFUdEJJOFBI?=
 =?utf-8?B?NENBczAyOXI4K216dUVmSS9pOUNpQjNEV292YjZkZkNMdXh4TUFTUXNyem8z?=
 =?utf-8?B?OXZZUTVhbkZXa21oNm1GVUhMbGdRNk8yc1BiandhWFpQWXVNVHZvUlFBTWhw?=
 =?utf-8?B?L3NNRmZxL1RpNjJ6WWdLVGJ1TElrOFBHaEl2Vm5DM1ZndHZnWTBHekFhWndz?=
 =?utf-8?B?VkMwTitKd3BWVEllUGNzN1pQVVhVdEZxekJYTENrQ25DTG5BNThvM21sVEg2?=
 =?utf-8?B?YzA3RmRKbitKMk5pZHlDd0IrdUlERGVMRUNieE16ZEhhMkRldWNZT0VSYitX?=
 =?utf-8?B?Zmx1MjJCZEdkNHBzcVltTjFOaUpCb0NPRHJ0ekRDODdkSGNZQ1hvMGFoOXd6?=
 =?utf-8?B?NzZuUDN1aGwwdldRSXpYMUlsK1g5KzgxbGI3VEY5cmpVdVhVaDdnVU9tYVFz?=
 =?utf-8?B?em5mWmZGbzNCV3hCUXF1bzR4ZHg5YTBDNzRxWDZLM25HV3E2dGNOMWFNajMy?=
 =?utf-8?B?NnordzI5dHJ5WVZNZVpZenRjdEp1Z0JSZmJhbExjNnluUEJ3MnU5Y0tyeVBP?=
 =?utf-8?B?dFhOV3VZRW9WWUNtVDBlT0VFSWNVOXdRTkJIYVJkTXV2VDBsY3Vhbi9qckRX?=
 =?utf-8?B?UGVQUE5sZWZ3a0VmNVd6ZGd3MkUrRVd2NUIxN2t0dEYyWExkaUh1SExxS1E1?=
 =?utf-8?B?OXhEUHZEY0lsVjNPWjBCOTNmS3hySW5iZDZFMWVlRUYrN3NVZTR1VVRVRzlp?=
 =?utf-8?B?Slo5eTJ3eGFuU2NRcDJhdE80azlKYk1FcWNsS2hUZ2xNbGh3aUxqTGhjejcw?=
 =?utf-8?B?Z1g3VVFwcUlNb1pnOEFVcVIxNHhCMGJqclYybTZ2VWZLZllQNDlpMENvb0tW?=
 =?utf-8?B?VTlmcSsxcWV2VlJ1U3p5bkNNUktzN3E2YzU4K3k5VHRBR0VIOC9pUnJRT2dD?=
 =?utf-8?B?YmZaSkFQNllUOHpGOVplZ0lPNUxNb0YzL0cvY1NWeHZLMVpROWJBMlVwQy9Z?=
 =?utf-8?B?TEpmQUtiN2g1TDFEZzV1Q0RHSVp5R25CUWZPUzZ5dTVXMEFRbmF1eUtDRzNl?=
 =?utf-8?B?Tk00Nk4vSlNFWXBCWS8wQlRTWjVKNTNlVXUvT0ZYVFFZRzdoQXcxVkF5dSsw?=
 =?utf-8?B?TDdWQzFHaUFnRkFLSjRSQkg1SnIzeXRmbm4wS3c2OTRUSndMVHFZcnk4NjhB?=
 =?utf-8?B?NFgwVFpPSy9UTG42Z2J2eVEybVN5SlpPdmpqYkpoWWhqSEV0L04xQXdJSFpo?=
 =?utf-8?B?bURVbTUxRGFDcUY5MU1YekptWHQrL1JpREZmVkQ3UllMNU42c3hFSW9rYnFE?=
 =?utf-8?B?T2tNQmc0Rm5sckw0cmtLckU5UVlYMUUyRndTRFBrODlOZDA0Zi9QaFJQMEp2?=
 =?utf-8?B?d0J4RDc4MUhiVWVhRklub0tYL1lBay9YeVdXQlpUUzduTUxteDl2bWtUdWxl?=
 =?utf-8?B?ZTNLcTdzSFpTUGYrZGV4SHZUK0p2ZDVxQlM2ZTdOaTl3WkJwVzhPZHhic0Vi?=
 =?utf-8?B?M0hvUkhrdmxmN211SVA0OEZ1aXFyUmg3dEtKMUpWaEdiakxRcEpKSDJuSW82?=
 =?utf-8?B?ZHBBRVdmY2kyZWllYlh3VWlCZEdSMmM4aUpMaHVFKzVuMTMwTGVtSUlCTWxQ?=
 =?utf-8?B?bU8vb3kxWUxuQndOb0xPUFNuajFRem5CRnh6RGcvYnZ6YTNYWU82MCtWdkJr?=
 =?utf-8?B?ZWhLM29ZUGpld1RnUXVtWUVJWkxDV0lxRW8rTDFoei9qWkFOTVlYcDVVaWI4?=
 =?utf-8?B?L0labkxTQUNLTDhPMW9penBSUHloaVdBbmJldUswbDM1ZStlNjZNRkZtbC9V?=
 =?utf-8?Q?vUU8+i/uPmBpJuuPrCXJW7zGO?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2cb0ca1c-5530-4e9e-c5da-08dd937c4002
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2025 06:46:41.7310
 (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: iczzTwRuZo0RWmIs3bAEUVuJd6dXJ7FQ/GtPSCTYuIDoz7nLrM1r5bbZaRHMGyE5
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5858



On 15/05/2025 02:07, Stefano Stabellini wrote:
> On Wed, 14 May 2025, Orzel, Michal wrote:
>>> Sure. But my point is rather more that static memory is not a feature 
>>> described by the Arm Arm. Instead, it is a feature of Xen that is ti to 
>>> device-tree. So inherently there is no reason to be implemented in arch/arm.
>> I agree, it can and should be made common. But exposing only callers makes no
>> sense at all for me. Callers should be exposed together with feature code movement.
> 
> [...]
> 
>>>>> back to Arm for then moving back to common potentially in a few weeks time.
>>>> What about static memory code? With the recent Oleksii code movement, the inline
>>>> helpers like allocate_static_memory() became unreachable when the feature is
>>>> disabled and the main purpose for helpers was to avoid ifdefery.
>>>
>>> Sorry I am not sure which part you are referring to.
>> With the current code, allocate_static_memory(), assign_static_memory_11()
>> callers (that were moved to common) are protected with #ifdef. This causes the
>> helpers defined in case CONFIG_STATIC_MEMORY is not defined to be unreachable
>> (see static-memory.h).
> 
> At a high level I agree with Julien, this is the kind of feature that
> should be common. In fact, I would even say that I consider the related
> device tree bindings common.  But looking at the code movements and the
> #ifdef's, I think that as of today, this patch series is improving
> things.
I've said multiple times already that I also agree that static mem/shmem should
be common. It was not the point of this discussion. My only concern is that it
should be done in a proper way and not in 5% like it was done recently that also
resulted in issues I mentioned above. Therefore I also (hence my tag) believe we
should accept it.

~Michal



From xen-devel-bounces@lists.xenproject.org Thu May 15 06:47:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 06:47:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984790.1370729 (Exim 4.92)
	(envelope-from )
	id 1uFSNi-0007h2-Hh; Thu, 15 May 2025 06:47:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984790.1370729; Thu, 15 May 2025 06:47:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFSNi-0007gv-EA; Thu, 15 May 2025 06:47:50 +0000
Received: by outflank-mailman (input) for mailman id 984790;
 Thu, 15 May 2025 06:47:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFSNh-0007gl-E3
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 06:47:49 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8383a8b4-3158-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 08:47:48 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5fcc96b6a64so1167970a12.0
 for ; Wed, 14 May 2025 23:47: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
 a640c23a62f3a-ad21985340fsm1045211066b.167.2025.05.14.23.47.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 14 May 2025 23:47: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" 
X-Inumbo-ID: 8383a8b4-3158-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747291668; x=1747896468; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=B4F3dvZtX8E/G76kxLLrrIEWmKyp7XFxWuNqrIQdBfw=;
        b=SmGjAIVahKKcEG17WZnPkSAKmtm+astC5DoYppwqMuTWNSahRJxUR0iMV/QCzvtive
         sIofFz/V9mwk6zZXF0/nvVhtHzndxcYZXVady+UA57cd2K7z8JFxPqg7uWBYs1qvTJDd
         UXTK3ZYg4Q9VgyNC4rbJLM5PhymfkuEPW2kzGfmQhTIpeUA/pNeyCwfFuQrxBnQ0TSli
         FMfiWcBguQUltfwNyT1hiGib0dmus7N2KIvC/Gyug/E2Uzh9p8xML0CqbvkfQN2Q4vpB
         tIdiFGOX8xmMFztvnj3a06IHYwRl6XXOMYBVIPBEHSWsyVJ/T2wrONBdq9qHrgY3zrzh
         vQyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747291668; x=1747896468;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=B4F3dvZtX8E/G76kxLLrrIEWmKyp7XFxWuNqrIQdBfw=;
        b=WYq1IQCZdsflcxwP652RB8wHvEgzwT+5Ygg6srf2m2nF04ZCRq7j0LfOfqdryXbw3C
         iAFrYLokJYv8syYnLNeBpg6W8n1EYhCg3bMxLVzX5oIT+IJvENJFipGx89eP1gRy1HGF
         Cd7lOPBjwxpmT6N96IgoGnTpqe7LgXd+MY3MbchsxONbqyuA+UsmnUrFQjveMzewwzx3
         q9OaqwnJWPPoAe2lxBZZj3q4+xgzzjNKst1j/DNgRpAYWZmlVtxiivlSR6KM0kYxfzB9
         XZQSdt0clZswaveERRKEUdg9Na/WG8CG6h19mStV37A2rANzilnsogHx0AwaBjETjf4q
         Ucqw==
X-Gm-Message-State: AOJu0YwufxWdjurd8XyVhOCC1mmscrjy+/1ELYYRrhKZYLpasaIjHNDr
	J/jsgY8DVu6GJMd5UlhBOiza0jJkZBixs5ivSTj5YvBjgxtxIp79t4yZNrWmVw==
X-Gm-Gg: ASbGncs3oHk0nnVegHIrLRr0qGWCg8hb07ATQdfU4G6zD6Dz0nREimUBNvgHBP7VqsH
	dlfL7bWgetZQRRSu9rFo5XRKSYck9lDeCScK2e8TlL6WSqQ1ocO0daYU6pW7FeZTNKuLKGTozhZ
	NI6AmM8uWO59ip0Ps3AAsTc9tSTA7ejVaVC/BGmr+It5SJHvKbvNF7kLc+rmmXqcS44xviQITv1
	5mPdlzISsy9Eo7ybwdSVweHixIBu5nUqWF9/jwdQ4Q2L6nwgV/rRdiyXbZoxNcw3AehYO6M1ao5
	VIr7xZh6r7TOt3U/LK3LoKWob/lh8V5nbvN26kJ9hQabBq9f7v0wuWgXnTJyy6G868Tu9rExgGh
	jF28EuH20ABVZzNLLWLnLFWftSqwjFo5owpVg
X-Google-Smtp-Source: AGHT+IH/DcKcCEfnMxN+9dSFioIPzt2CNm63hHKM0S6Q4N+Ag95ko9F9ytFqiYLb/om5tzLnm+zU3A==
X-Received: by 2002:a17:907:7f28:b0:ac3:3cff:268 with SMTP id a640c23a62f3a-ad4f723fd41mr598650866b.30.1747291667677;
        Wed, 14 May 2025 23:47:47 -0700 (PDT)
Message-ID: 
Date: Thu, 15 May 2025 08:47:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 6/6] x86/HVM: limit cache writeback overhead
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper 
References: 
 <9274fbb1-c1be-9570-ecfc-8f0ac9a1f42b@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

On 14.05.2025 17:12, Roger Pau Monné wrote:
> On Wed, May 14, 2025 at 03:20:56PM +0200, Jan Beulich wrote:
>> On 14.05.2025 15:00, Roger Pau Monné wrote:
>>> On Wed, May 03, 2023 at 11:47:18AM +0200, Jan Beulich wrote:
>>>> There's no need to write back caches on all CPUs upon seeing a WBINVD
>>>> exit; ones that a vCPU hasn't run on since the last writeback (or since
>>>> it was started) can't hold data which may need writing back.
>>>
>>> Couldn't you do the same with PV mode, and hence put the cpumask in
>>> arch_vcpu rather than hvm_vcpu?
>>
>> We could in principle, but there's no use of flush_all() there right now
>> (i.e. nothing to "win").
> 
> Yes, that will get "fixed" if we take patch 2 from my series.  That
> fixes the lack of broadcasting of wb{,no}invd when emulating it for
> PV domains.
> 
> I think this patch would be better after my fix to cache_op(),

Right, this matches what I said ...

> and
> then the uncertainty around patch 2 makes it unclear whether we want
> this.
> 
>>>> Signed-off-by: Jan Beulich 
>>>> ---
>>>> With us not running AMD IOMMUs in non-coherent ways, I wonder whether
>>>> svm_wbinvd_intercept() really needs to do anything (or whether it
>>>> couldn't check iommu_snoop just like VMX does, knowing that as of
>>>> c609108b2190 ["x86/shadow: make iommu_snoop usage consistent with
>>>> HAP's"] that's always set; this would largely serve as grep fodder then,
>>>> to make sure this code is updated once / when we do away with this
>>>> global variable, and it would be the penultimate step to being able to
>>>> fold SVM's and VT-x'es functions).
>>>
>>> On my series I expand cache_flush_permitted() to also account for
>>> iommu_snoop, I think it's easier to have a single check that signals
>>> whether cache control is allowed for a domain, rather that having to
>>> check multiple different conditions.
>>
>> Right, adjustments here would want making (in whichever series goes in
>> later).
>>
>> For both of the responses: I think with patch 1 of this series having
>> gone in and with in particular Andrew's concern over patch 2 (which
>> may extend to patch 3), it may make sense for your series to go next.
>> I shall then re-base, while considering what to do with patches 2 and 3
>> (they may need dropping in the end).

... here.

Jan

> Makes sense, I still need to get over your feedback on my series, I've
> been distracted with other stuff.
> 
> Thanks, Roger.



From xen-devel-bounces@lists.xenproject.org Thu May 15 07:33:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 07:33:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984834.1370763 (Exim 4.92)
	(envelope-from )
	id 1uFT5l-0006CD-1I; Thu, 15 May 2025 07:33:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984834.1370763; Thu, 15 May 2025 07: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 1uFT5k-0006C6-Ua; Thu, 15 May 2025 07:33:20 +0000
Received: by outflank-mailman (input) for mailman id 984834;
 Thu, 15 May 2025 07:33:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFT5j-0006Bv-79
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 07:33:19 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dd6eafab-315e-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 09:33:17 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54F7WfsF3336298
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Thu, 15 May 2025 00:32:41 -0700
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dd6eafab-315e-11f0-9eb6-5ba50f476ded
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54F7WfsF3336298
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747294363;
	bh=FTKlSsiJd9+jpos7AVLXF8LAqgwtfl1Qy7H7vRzCDXE=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=OeZftPa4P2RcLNrfq7mYvwL9TgxRMcLlkVGZC6h8vETFbJVCjpBbzmpzH5AR13wKx
	 15mv9dkcpvv5ouP63h6d4FyAbbBv4ahXZZT/mJEs0YcVe4dSsuiidCYyb5eLIFmmab
	 KZh7WExvvM7f5dcUXiiH4kI087BVfYMnwIxDBqPfWZBau2sgqY1q7vFYn0CwCYjxM9
	 k2IdZTAsWYVBOheuyRj88cuKgPcjoyTQbvMyOTslRINSkfMVXRDIiVGVCAqieKjmOF
	 vIstWyCK+xY4GqiDXwaoMJ8FcLhCdyf9Y7Wv9kaBeH/qOTfV0h+xsRne4kDWAibHx3
	 4HrOazqt1wu0g==
Message-ID: <652dfd63-e41c-4d7a-8fea-40509e8191ef@zytor.com>
Date: Thu, 15 May 2025 00:32:40 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
To: "H. Peter Anvin" ,
        =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 ,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        virtualization@lists.linux.dev, Peter Zijlstra 
Cc: Ajay Kaher ,
        Alexey Makhalov ,
        Broadcom internal kernel review list
 ,
        Thomas Gleixner
 , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        Boris Ostrovsky ,
        xen-devel@lists.xenproject.org
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
 
 
 <6cc20ef6-d8e5-4c74-89d9-6a949c84b397@suse.com>
 
Content-Language: en-US
From: Xin Li 
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5/13/2025 3:24 PM, H. Peter Anvin wrote:
> On May 12, 2025 11:06:02 PM PDT, "Jürgen Groß"  wrote:
>> On 13.05.25 07:55, Xin Li wrote:
>>> On 5/12/2025 4:24 AM, Juergen Gross wrote:
>>>> Now with the mentioned patch really attached. :-)
>>>>
>>>
>>> Does it allow patching with an instruction more than 6 bytes long?
>>>
>>> The immediate form MSR instructions are 9 bytes long.
>>
>> Yes, shouldn't be a problem.
>>
>>
>> Juergen
> 
> However, it is more than that. The immediate instructions have a different interface, and it makes more sense to use the extra bytes to shuffle the bits around for the legacy forms:
> 
> Write:
> 
>      mov %rax,%rdx
>      shr $32,%rdx
>      wrmsr(ns)
> 
> Read:
> 
>      rdmsr
>      shl $32,%rdx
>      or %rdx,%rax
> 
> For the write case, this also means that two separate trap points are needed.
> 
> As far as Xen (the only user of pv msrs), note that it only paravirtualizes a very small number of MSRs, and some of those are fairly performance sensitive, so not going through the Xen framework for MSRs known to be either native or null on Xen would definitely be a win.
> 
> 

Hi Juergen,

I have some update on this thread while working on it.

If we continue down the path of maintaining pvops MSR APIs as this patch
series does, it seems we’ll need to duplicate the ALTERNATIVE code in
three different places.

1) The MSR access primitives defined in , which is used when
    CONFIG_PARAVIRT=n.

2) The pvops native MSR functions pv_native_{rd,wr}msr{,_safe}() defined
    in arch/x86/kernel/paravirt.c, used when CONFIG_PARAVIRT=y on bare
    metal.

3) The pvops Xen MSR functions paravirt_{read,write}_msr{,_safe}()
    defined in , used when CONFIG_PARAVIRT_XXL=y.

hpa had mentioned to me earlier that this would be a maintenance burden
— something I only truly realized once I got hands-on with it.

Maybe you have something in mind to address it?

Also add PeterZ to the To list because he cares it.

Thanks!
     Xin


From xen-devel-bounces@lists.xenproject.org Thu May 15 07:33:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 07:33:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984837.1370772 (Exim 4.92)
	(envelope-from )
	id 1uFT66-0006WP-B1; Thu, 15 May 2025 07:33:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984837.1370772; Thu, 15 May 2025 07:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFT66-0006WI-8Q; Thu, 15 May 2025 07:33:42 +0000
Received: by outflank-mailman (input) for mailman id 984837;
 Thu, 15 May 2025 07:33:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFT64-0006Vu-TD
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 07:33:40 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eaf13d1f-315e-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 09:33:39 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad238c68b35so112684766b.1
 for ; Thu, 15 May 2025 00:33: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
 a640c23a62f3a-ad21934d4acsm1066120766b.71.2025.05.15.00.33.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 00:33:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eaf13d1f-315e-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747294418; x=1747899218; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=couxgbisf2m6uHPvhGCaE8zKqYTKOdns6VUmWWn2dLU=;
        b=HiBg+AN5VIDrLLKIJD6FUFy0OOhDPibff9kBopUGgbP+23ZMrI57wDX3asTq7JkYJo
         S/VIdW46TOz4tPV8yYLJEfQLhoBuWX3eiYojhzvqXdgdA1/6CQKffjDZnYIzc3nePjz0
         iJrzkFBIVWHktHOsVQW8Rd6LmQGWCtpq6ybV3BdNnS6UREPObEEf6UKm2mkbnBzBmViF
         esQMImE8QyrqCv6nb4xQUcxbyQBTtceRS+Hg6m6de/Oz2mhvu2gh/yTYvkEiBYvUSGzx
         sm/FPnAONrzXfG+NAXBuNmp6gYJyjiTXNPVgyuTH+eWrSMA+gOsbF7He5NxCpGQSwPHn
         joXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747294418; x=1747899218;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=couxgbisf2m6uHPvhGCaE8zKqYTKOdns6VUmWWn2dLU=;
        b=auHku5ovxGI/ToQqAJAdK2r/pNhdQPrvEGB/sKR64dYuFae6hFJ7GH8BDiUWfSvC2G
         W6EeTjlxsf29eK/xGbug5yEjWy7WEYNyJLxDoiyPrwwOUlSaMJB3bK5euI97FvraJl2K
         LqDGe0pNs0O+A4q8tgRidizeu45L6+4DRFrkHk/tjWCW4cJ7CRTOKDkvP6GDhy+fFSrO
         CIXTSKhiyquKxNtgccpoQ21D7iIRS2aDIXtX1qWXTCGRgtTi9ZBaTJSX4pxELFazz7Le
         ZP6xmM2Vmlq53mPsJunyEQty7gUrCooo5HTl+B2Y+3wk8QPvoTVElHI3u45WyXYrTw0a
         mzLw==
X-Forwarded-Encrypted: i=1; AJvYcCU6SVFCUThGE/M82Jjx1kh5oqbKX4bdxWH3AzT3xH96cQ87cYFU1rMpFnoDl8I38gTyaItvbwzj8gM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyWOzzNpyb2qDWIjkjoYG+1aQGLUHwZS8xWHNH3RIqKwgFLgKYa
	17WGQwDr2k4cGfQ8aHJgRu20w9e3MthhwxHuiuwdeqiROitDQMj3xY5bS4hJEA==
X-Gm-Gg: ASbGnctRb00CJUdbOpx5TYx/8AcG5Dt2XNYhCV+MInHX3sph2hPVWOJiAZw1o6L9GVp
	H2eAg714pDzacGKNCN6Spa+0udOO/oLzEKzjcYxIuL7kv4zK+Xwvq+GFaGWTQ5xt+NEJ9QRHV2i
	SDavbSQbe8WJJDwIQhjqn3m+K2m1Y/SLpR6zRmFBEWSSLCzBfrCklgTS1rPIEUaM8qwOdbyqZlk
	R9O9MQc8RVdo6z52NRsOb9TfXlTcoCc2Rib8CjKSFXrRsxJnKFD4ZWm5bmiB0kjCx07W/vb+zzM
	LWTWaObeCWjMtLw0Sl3l65H4A6EZsNmR6cCUDvLe+ctNdU8FiO1xdNVf/wJQ9sdGs2k+yqiZurY
	lBzD0PofRhjw7Pp2B2CsKl4WtO+mMNB7ozH4C
X-Google-Smtp-Source: AGHT+IHSHEBDxdtvOPJwOIi00oUOn1o25/sTjMRu5u+rb8iNbV5tCOqBGG2z3xOfpWaAn4IYzHoV5A==
X-Received: by 2002:a17:907:6c14:b0:ad4:f5ed:add2 with SMTP id a640c23a62f3a-ad516050d15mr101164666b.38.1747294418175;
        Thu, 15 May 2025 00:33:38 -0700 (PDT)
Message-ID: 
Date: Thu, 15 May 2025 09:33:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/16] xen/riscv: introduce platform_get_irq()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , 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

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> platform_get_irq() recieves information about device's irq ( type
> and irq number ) from device tree node and using this information
> update irq descriptor in irq_desc[] array.
> 
> Introduce dt_irq_xlate and initialize with aplic_irq_xlate() as
> it is used by dt_device_get_irq() which is called by
> platform_get_irq().
> 
> Co-developed-by: Romain Caritey 
> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in V2:
>  - Add cf_check for aplic_irq_xlate().
>  - Ident label in irq_set_type().
>  - Return proper -E... values for platform_get_irq().
> ---
>  xen/arch/riscv/aplic.c           | 20 +++++++++++++++
>  xen/arch/riscv/include/asm/irq.h |  3 +++
>  xen/arch/riscv/irq.c             | 42 ++++++++++++++++++++++++++++++++
>  3 files changed, 65 insertions(+)
> 
> diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
> index caba8f8993..10ae81f7ac 100644
> --- a/xen/arch/riscv/aplic.c
> +++ b/xen/arch/riscv/aplic.c
> @@ -11,6 +11,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -21,6 +22,23 @@ static struct intc_info __ro_after_init aplic_info = {
>      .hw_version = INTC_APLIC,
>  };
>  
> +static int cf_check aplic_irq_xlate(const uint32_t *intspec,
> +                                    unsigned int intsize,
> +                                    unsigned int *out_hwirq,
> +                                    unsigned int *out_type)
> +{
> +    if ( intsize < 2 )
> +        return -EINVAL;
> +
> +    /* Mapping 1:1 */
> +    *out_hwirq = intspec[0];
> +
> +    if ( out_type )
> +        *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
> +
> +    return 0;
> +}
> +
>  static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
>  {
>      if ( aplic_info.node )
> @@ -35,6 +53,8 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
>  
>      aplic_info.node = node;
>  
> +    dt_irq_xlate = aplic_irq_xlate;
> +
>      return 0;
>  }
>  
> diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
> index f609df466e..6223bbbed5 100644
> --- a/xen/arch/riscv/include/asm/irq.h
> +++ b/xen/arch/riscv/include/asm/irq.h
> @@ -30,6 +30,9 @@ static inline void arch_move_irqs(struct vcpu *v)
>      BUG_ON("unimplemented");
>  }
>  
> +struct dt_device_node;
> +int platform_get_irq(const struct dt_device_node *device, int index);
> +
>  void init_IRQ(void);
>  
>  #endif /* ASM__RISCV__IRQ_H */
> diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
> index 26a8556b2c..4c518bbd97 100644
> --- a/xen/arch/riscv/irq.c
> +++ b/xen/arch/riscv/irq.c
> @@ -7,11 +7,53 @@
>   */
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  
>  static irq_desc_t irq_desc[NR_IRQS];
>  
> +static bool irq_validate_new_type(unsigned int curr, unsigned int new)
> +{
> +    return (curr == IRQ_TYPE_INVALID || curr == new );

Nit: Stray blank. In fact you could omit the parentheses as well.

> +}
> +
> +static int irq_set_type(unsigned int irq, unsigned int type)
> +{
> +    unsigned long flags;
> +    struct irq_desc *desc = irq_to_desc(irq);
> +    int ret = -EBUSY;
> +
> +    spin_lock_irqsave(&desc->lock, flags);
> +
> +    if ( !irq_validate_new_type(desc->arch.type, type) )
> +        goto err;
> +
> +    desc->arch.type = type;
> +
> +    ret = 0;
> +
> + err:
> +    spin_unlock_irqrestore(&desc->lock, flags);
> +
> +    return ret;
> +}
> +
> +int platform_get_irq(const struct dt_device_node *device, int index)
> +{
> +    struct dt_irq dt_irq;
> +    int ret;
> +
> +    if ( (ret = dt_device_get_irq(device, index, &dt_irq)) != 0 )
> +        return ret;
> +
> +    if ( (ret = irq_set_type(dt_irq.irq, dt_irq.type)) != 0 )
> +        return ret;
> +
> +    return dt_irq.irq;

What guarantees the value to be at most INT_MAX (i.e. no silent conversion to
a negative value, signaling an error to the caller)? Actually, looking at
irq_set_type(), what guarantees irq_to_desc() there to not overrun irq_desc[]?
There are no bounds checks in aplic_irq_xlate().

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 07:57:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 07:57:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984858.1370783 (Exim 4.92)
	(envelope-from )
	id 1uFTSb-0001Nc-59; Thu, 15 May 2025 07:56:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984858.1370783; Thu, 15 May 2025 07: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 1uFTSb-0001NV-1x; Thu, 15 May 2025 07:56:57 +0000
Received: by outflank-mailman (input) for mailman id 984858;
 Thu, 15 May 2025 07:56:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFTSZ-0001NP-Ey
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 07:56:55 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2a282cc2-3162-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 09:56:53 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5f5bef591d6so1282907a12.1
 for ; Thu, 15 May 2025 00:56: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
 4fb4d7f45d1cf-5fff0cde389sm389443a12.17.2025.05.15.00.56.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 00:56: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" 
X-Inumbo-ID: 2a282cc2-3162-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747295813; x=1747900613; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=YeK56Adq5vSSVWRg/BGj/yQlkl1aU3vMjnhbTKKe8ek=;
        b=aT5ifZF07Ia+sWfUqmapQxji7SAeD6IYqUBzymLUThpKTTu1i7B/KCazbW/xxAkble
         RW87JJ8mFevSvM/Kq15/wgRLiA7nvssyRjqEEZopxRbAeOrLt7SKUKFS15/QK1R1twww
         7IWzSVDl30nppu/YSLGRrLRR163RxE+/vhBn06wlsJbcOmyopTbO6ABaSsHSS1b6+Xwg
         CPTzrQVpW6TcISFv91+s4ULufDQ6SrXcHCO5w00X4JYgZy14oOqqHSW/g2tx7uzIlh6/
         PwiuqD1rJHiQ7O5nX2KuMyYQu8FyLuZf093y3HzsfGSYTTEM/6mkwK2+10EFUJeqN2ux
         WS4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747295813; x=1747900613;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YeK56Adq5vSSVWRg/BGj/yQlkl1aU3vMjnhbTKKe8ek=;
        b=XrI2aej2omcqAymh4UEw6XVD/KQgmnzjN01m0ppU2N6KCmxJdMtjqM1HDGSQH01lRQ
         f8Yx3t/fBvahQGxSQ53EvMgcQoMZwLt2riU8SKuakMKO0UDWCCxDHFA2Vk4/w60EPSK7
         xXQCUpIoInxKC7xbWl6FJni085trBBiMUbbEIsFV9YjW8ITVstj3uKX682QyU++vYycP
         fK8d/HwNOOHKvVEbRrdlct9q9E8ZTyrDKBvFv4fVIqj1QJPIkJgTPAErsyScmvh4NssJ
         7UDLy74ZUBU0qwVHpwtgz9Hj88uK1F06ebB+f9jvmkAQ1c7vuosxj/DMC6ApmnMoV8Fb
         QoOA==
X-Forwarded-Encrypted: i=1; AJvYcCUa/pIbsYnbzqLNyPPmD2yToJGRl78Llsn4c+plb5zdcKE5V/uGXmp0fpWziAjWPaidxdPuieGglWI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwzPekBJ0psJCflqUoK57npcV2O5EV6FudFosFdU/YmFV/lqSnW
	i+6x2wsb8nVw6Paecm7uWyWdKDrXyrU4R9wTl/40nZkhSIwpHnqyFP+SoA/isw==
X-Gm-Gg: ASbGncv8VTCRfh7awVoowWw6MzRudCao8LKMi1g5d1Y6tvccR12COlKrjpYEt5lsSUa
	8kdiLXTKndPF8kZqmQdqM3XliQZnlVEqNQq66DxsWZb3CI2nmACKLYoxZKahdc8Jd5BWhgxZXhS
	nO7UKQ5DnX27XQBrrze0woN+lIydZt9OspOSx+iphiXCg2KXYFLI7D5668fniepel8RfVC96KZL
	SuR7hNMdUFquIaX6YAQjEhehOXRPNEyXIJXt9fUNgYtJvuFwr0xXCM7JZi7FsRPAoNDNCKdJc0t
	bNM8W+MHN7fnZAR2S3CC1//77eFjfEVpb0N+WKp+k9CRHUxam1N3hUiZJRTRfjK8EdE4PakrYcb
	awWaapnE7TanqruCxYtUiJrctux/nXMswR3x6
X-Google-Smtp-Source: AGHT+IGRIHz2iS/A66gqpX2g+js7fRNFX7SfZcZjcAx/2OWsra+1FHuT0yQIIazgSmJPCqPI5VDgew==
X-Received: by 2002:a05:6402:1ed1:b0:5ff:712a:bab2 with SMTP id 4fb4d7f45d1cf-5ff988b9ae6mr4891380a12.18.1747295812691;
        Thu, 15 May 2025 00:56:52 -0700 (PDT)
Message-ID: 
Date: Thu, 15 May 2025 09:56:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/16] xen/riscv: dt_processor_cpuid() implementation
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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,
 Bertrand Marquis 
References: 
 <4e4b3a018e8dacbe85cc080d9209e2ba3cdf4330.1746530883.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: <4e4b3a018e8dacbe85cc080d9209e2ba3cdf4330.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

(adding Bertrand as the one further DT maintainer, for a respective question
below)

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> Implements dt_processor_hartid()

There's no such function (anymore).

> to get the hart ID of the given
> device tree node and do some checks if CPU is available and given device
> tree node has proper riscv,isa property.
> 
> As a helper function dt_get_cpuid() is introduced to deal specifically
> with reg propery of a CPU device node.
> 
> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in V2:
>  - s/of_get_cpu_hwid()/dt_get_cpu_id().
>  - Update prototype of dt_get_cpu_hwid(), use pointer-to-const for cpun arg.
>  - Add empty line before last return in dt_get_cpu_hwid().
>  - s/riscv_of_processor_hartid/dt_processor_cpuid().
>  - Use pointer-to_const for node argument of dt_processor_cpuid().
>  - Use for hart_id unsigned long type as according to the spec for RV128
>    mhartid register will be 128 bit long.
>  - Update commit message and subject.
>  - use 'CPU' instead of 'HART'.

Was this is good move? What is returned ...

> --- a/xen/arch/riscv/include/asm/smp.h
> +++ b/xen/arch/riscv/include/asm/smp.h
> @@ -26,6 +26,9 @@ static inline void set_cpuid_to_hartid(unsigned long cpuid,
>  
>  void setup_tp(unsigned int cpuid);
>  
> +struct dt_device_node;
> +int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid);

... here isn't a number in Xen's CPU numbering space. From earlier discussions I'm
not sure it's a hart ID either, so it may need further clarification (and I'd
expect RISC-V to have suitable terminology to tell apart the different entities).

> @@ -10,3 +13,66 @@ void __init smp_prepare_boot_cpu(void)
>      cpumask_set_cpu(0, &cpu_possible_map);
>      cpumask_set_cpu(0, &cpu_online_map);
>  }
> +
> +/**
> + * dt_get_cpuid - Get the cpuid from a CPU device node
> + *
> + * @cpun: CPU number(logical index) for which device node is required
> + *
> + * Return: The cpuid for the CPU node or ~0ULL if not found.
> + */
> +static unsigned long dt_get_cpuid(const struct dt_device_node *cpun)
> +{
> +    const __be32 *cell;
> +    int ac;

This is bogus (should be unsigned int afaict), but dictated by ...

> +    uint32_t len;
> +
> +    ac = dt_n_addr_cells(cpun);

... the return value here and ...

> +    cell = dt_get_property(cpun, "reg", &len);
> +    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
> +        return ~0ULL;

(Nit: This doesn't match the return type of the function; same for
the function comment. Also, what if sizeof(*cell) * ac < len?)

> +    return dt_read_number(cell, ac);

... the function parameter type here. In fact, that function is raising
another question: If the "size" argument is outside of [0, 2], the value
returned is silently truncated.

More generally - are there any plans to make DT code signed-ness-correct?

> +/*
> + * Returns the cpuid of the given device tree node, or -ENODEV if the node
> + * isn't an enabled and valid RISC-V hart node.
> + */
> +int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
> +{
> +    const char *isa;
> +
> +    if ( !dt_device_is_compatible(node, "riscv") )
> +    {
> +        printk("Found incompatible CPU\n");
> +        return -ENODEV;
> +    }
> +
> +    *cpuid = dt_get_cpuid(node);
> +    if ( *cpuid == ~0UL )
> +    {
> +        printk("Found CPU without CPU ID\n");
> +        return -ENODEV;
> +    }
> +
> +    if ( !dt_device_is_available(node))
> +    {
> +        printk("CPU with cpuid=%lu is not available\n", *cpuid);
> +        return -ENODEV;
> +    }
> +
> +    if ( dt_property_read_string(node, "riscv,isa", &isa) )
> +    {
> +        printk("CPU with cpuid=%lu has no \"riscv,isa\" property\n", *cpuid);
> +        return -ENODEV;
> +    }
> +
> +    if ( isa[0] != 'r' || isa[1] != 'v' )
> +    {
> +        printk("CPU with cpuid=%lu has an invalid ISA of \"%s\"\n", *cpuid, isa);
> +        return -ENODEV;
> +    }
> +
> +    return 0;
> +}

I view it as unhelpful that all errors result in -ENODEV. Yes, there are log
messages for all of the cases, but surely there are errno values better
representing the individual failure reasons?

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 08:06:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 08:06:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984874.1370804 (Exim 4.92)
	(envelope-from )
	id 1uFTcA-0003m1-BF; Thu, 15 May 2025 08:06:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984874.1370804; Thu, 15 May 2025 08: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 1uFTcA-0003lu-8c; Thu, 15 May 2025 08:06:50 +0000
Received: by outflank-mailman (input) for mailman id 984874;
 Thu, 15 May 2025 08:06:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFTc8-0003lo-UU
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 08:06:48 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8c6d3400-3163-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 10:06:47 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5f62d3ed994so1258834a12.2
 for ; Thu, 15 May 2025 01: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
 a640c23a62f3a-ad251f4c04fsm650927166b.171.2025.05.15.01.06.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 01:06: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" 
X-Inumbo-ID: 8c6d3400-3163-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747296407; x=1747901207; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=f0WAsoHkiPEv93dWwVsjrvRhTOkvhP/JrXk89RJOIw8=;
        b=eu056mshuIiVz1tZprmZtwPFbWC4KHNtcvr0mdi4/7SKW6DxKIlKt4ZH1T7eSnMQ0Y
         yWLqKCJpp/NLtr7m0L3cKDVyjGnt6WTK7R+pagxJrJeiN5YmHmvkUUTMXDk39lwKwTbS
         mkoM1pW7+Ii1j5iw0P0PHp8CNdx0IQhuuKCOJs8xxI9G82Fg7ezd3M0WeJAsZObTCHqK
         CnGq7i6Oqe1uD13p1DHtUO9a9ftyPTWDBwsgBm4ULxYf6VT9vWIF1KURCIfdyrIlAPTE
         ly4pGsdYeQnCTdku9+ke6cwTz2XMuY9xHYymFCofDmtnhsx5ylPj7L5147N7DDgezbXd
         Af3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747296407; x=1747901207;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=f0WAsoHkiPEv93dWwVsjrvRhTOkvhP/JrXk89RJOIw8=;
        b=jsRykeCpmJX1NZP87l6h+en6X6hwmgQSO4jwsU+aMM0nxc4F3d8XuQ7wQtv1pbaFHR
         rgLm2jW6gBrdeIVgZu4ObLASUGzQr2Qd5PrlFP/JzERl5u7hmcLnOIynb2cPfn0UNYwK
         2kWBJ/Z6HGanhryeuHGqtoCmh1ERzEyapa8hNyQdVlXSWeHJSfz6TzI0EmV+Lj/fO42U
         VBodLgWTfimaU4esH7dsCxLkCdOwDAl1y1FklF1bdwOq32mXjHEWzI/6JlLZ4dvFRIdw
         cnDxxN0tXuduaiwZ6oJVkTTysnlkDG6umpPB5TPdXdPI4xw1usmfGcabFAmlSLfjx2F0
         WxXg==
X-Forwarded-Encrypted: i=1; AJvYcCUABIqX7WfAJKEuUyL3g08Zf007MXtK/kXUeYyfY5zL4D9col3Sl44FFrwsP5IFClciFpPVkEQ4lok=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzMZVQyA0UT8Pg4gYwQ3ods4cKJ8pTwXK5fygMq5uOUBgKD0Oqf
	6sLK6MSBMdAotMOUcivtndgcvV+W0tEh1NRGh543RZBnF/NFyB32sSfb0SizXA==
X-Gm-Gg: ASbGnctYk7aaCtrbRrpl5IZQsIztcnWcOoXpZAL8lJ0+FqFSe72nsLwRBWlZe3bPykA
	FFUqmdE/3mvE7xn2tT8kn88aEwB/OMRSrC4jvxX21cmzTRpmZCJvwA9QJi1hbfIqmy+ERFZTSBy
	I9fzs5EMdXa4rTILPNih/xFhcZdOhcgM4LQqVqc9bJd7XwzEsSTFq9z0snNpup7aTHjni6opzkv
	sYHEMqFz/I/XG2ofPxhkItATIRMRC/DzCCG2SzV8p7jrvozX5wtvk5wQZwQNqQ2Nja85hgq8nZu
	HPgiyEpQetEGO8n+D4398fM/GLWnu2OReHO816xH5BbIXiBPnBKk8mulVi7sxJ6wxjaV4iFsDxX
	jdK8FGBOGHQ2iFsVaj6KFkDbrp/NcEjTjEpgm
X-Google-Smtp-Source: AGHT+IHkAuX3C9u2vEITuY2mp7ttsyPlPZGcxcI8rQDmzZg5pcb+259xXCdUXT61dga7amCVfsysbQ==
X-Received: by 2002:a17:907:9997:b0:ad1:8dde:5b7a with SMTP id a640c23a62f3a-ad4f747da01mr602790066b.43.1747296407105;
        Thu, 15 May 2025 01:06:47 -0700 (PDT)
Message-ID: <2436be2e-28d4-4e48-a391-84b21651b339@suse.com>
Date: Thu, 15 May 2025 10:06:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/16] xen/riscv: introduce register_intc_ops() and
 intc_hw_ops.
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <7cd7d3780bb6db45b92c971ff8bcf2634570431f.1746530883.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: <7cd7d3780bb6db45b92c971ff8bcf2634570431f.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/intc.h
> +++ b/xen/arch/riscv/include/asm/intc.h
> @@ -8,6 +8,8 @@
>  #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
>  #define ASM__RISCV__INTERRUPT_CONTOLLER_H
>  
> +#include 

If you need this include anyway, why ...

> @@ -17,6 +19,26 @@ struct intc_info {
>      const struct dt_device_node *node;
>  };
>  
> +struct irq_desc;

... this "forward" decl for something that's then already fully defined?
I can't, however, spot why xen/irq.h would be needed for anything ...

> +struct intc_hw_operations {
> +    /* Hold intc hw information */
> +    const struct intc_info *info;
> +    /* Initialize the intc and the boot CPU */
> +    int (*init)(void);
> +
> +    /* hw_irq_controller to enable/disable/eoi host irq */
> +    const hw_irq_controller *host_irq_type;
> +
> +    /* Set IRQ type */
> +    void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
> +    /* Set IRQ priority */
> +    void (*set_irq_priority)(struct irq_desc *desc, unsigned int priority);
> +
> +};
> +
>  void intc_preinit(void);
>  
> +void register_intc_ops(struct intc_hw_operations *ops);
> +
>  #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */

... throughout here.

> --- a/xen/arch/riscv/intc.c
> +++ b/xen/arch/riscv/intc.c
> @@ -5,6 +5,15 @@
>  #include 
>  #include 
>  
> +#include 
> +
> +static struct __ro_after_init intc_hw_operations *intc_hw_ops;

Nit: Attributes between type and identifier please. Also shouldn't both
this and ...

> +void __init register_intc_ops(struct intc_hw_operations *ops)

... the parameter here be pointer-to-const?

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 08:07:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 08:07:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984877.1370815 (Exim 4.92)
	(envelope-from )
	id 1uFTcV-0004CN-Ld; Thu, 15 May 2025 08:07:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984877.1370815; Thu, 15 May 2025 08: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 1uFTcV-0004CG-IW; Thu, 15 May 2025 08:07:11 +0000
Received: by outflank-mailman (input) for mailman id 984877;
 Thu, 15 May 2025 08:07:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFTcT-0003lo-PY
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 08:07:09 +0000
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com
 [2607:f8b0:4864:20::430])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 98c2ed40-3163-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 10:07:09 +0200 (CEST)
Received: by mail-pf1-x430.google.com with SMTP id
 d2e1a72fcca58-7410c18bb00so933851b3a.3
 for ; Thu, 15 May 2025 01:07:09 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 41be03b00d2f7-b23b521b709sm9775379a12.10.2025.05.15.01.07.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 01:07: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" 
X-Inumbo-ID: 98c2ed40-3163-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747296427; x=1747901227; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=zJNWzpEPEoWleDHoP7ApvrE9rksrKufzgl30z/65ImU=;
        b=qp7SF0YO3ZhuJVHTuM4HE5pRCoyLl9rX9oIdrMM5cj53iuYWDAbyGoRkRSmpj+gf97
         4Uf5a+aJXoo7KoDskXhb0fOgIlv7uuSGm9wHnGt7C7IUDVUqq082uXDgQFxmqlFmz3tM
         DcOtHFuNvSR9KaQ/j8tmGtRC6p+j/qmjrIMMs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747296427; x=1747901227;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=zJNWzpEPEoWleDHoP7ApvrE9rksrKufzgl30z/65ImU=;
        b=RsmJDGbaALvgFu/rX1tQ0fCEwu1bmwPy7SUeIgbvf0Mxr1fa17VFjYJ+ZMWTbHhDR/
         lbD32Myz2jywI2LY06uVE8576paSR5cP+KEQ5m4l2L9l/qaxv80RSu68CtobxNxcClip
         R3nXCzqjA3z3qRgINgt9ouVESZg33dgOLAY10iOv66h0SKndaKA+jirdRVwaNcswH5dk
         fn0e1HQdxWPoPAPjwjNxNNZeMDwOrGV/QG6VTMIKkTrEpBzIa6nOhM012F+jQYWKBJMe
         f0m1zjbaVEKVW0vvBzzZT/wFnwm2gwE40KI7ffohB0FBctk1wBgTndxRajMoRMS9cxuC
         P08Q==
X-Gm-Message-State: AOJu0YxbEVkqkVn5HSFKgM2y2gGhoB536MiGOIeB1ePEbw8C0gXTIPTq
	qERoBhPiTQiqOFFOXhx6+CSPLVLyVtJf2vOHQAFUjGZhFtElgEcwNDwJsZYRNdnl08xcGuEGVeI
	E
X-Gm-Gg: ASbGncuPkamJlDch7IxHOBJsDTCOyACFlcHYq41YitaP1OfvZm9N9POL6dZPTozIAcu
	oLXQ6Xx9UokrGa3pPvJBY63OiIlVI27fOIWIuG2NZPLqHHuGbfxswdFllsFRhEDnj2lrMLItUvP
	lJDojmLYjtehMSWxduSpXc74eQjRxTFDuuUQL7u86c4cHCHt1b7pL2Rj4lrBhOvZ2xfBnZ/RZSm
	pShoVUSeOh02qslMPLTco1B1jKYNRtJlvnDEO+nA9LYgfnkm70oXLpQ1tOdm9h9pb2a3oEqZkCa
	WjATd+ONCEhF9wmR1/HRmexeIuzj3gcwf66rotNfpwsJEShZXryYDMAS
X-Google-Smtp-Source: AGHT+IGvDCm1yH+jcYC5l3+0jZfp+rn1Zq681CmTbvTAGh4Wn7WrDEvIuLa8WZYjv10F/b7opi4GsQ==
X-Received: by 2002:a05:6a21:6da3:b0:1fd:f8eb:d232 with SMTP id adf61e73a8af0-216115573b2mr2195766637.24.1747296427591;
        Thu, 15 May 2025 01:07:07 -0700 (PDT)
Date: Thu, 15 May 2025 10:07:02 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
Cc: xen-devel 
Subject: Re: Issues on Zen4 (hw12) runner
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, May 14, 2025 at 11:12:20PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, May 12, 2025 at 05:11:53PM +0200, Marek Marczykowski-Górecki wrote:
> > On Mon, May 12, 2025 at 04:50:22PM +0200, Roger Pau Monné wrote:
> > > On Mon, May 12, 2025 at 04:40:29PM +0200, Marek Marczykowski-Górecki wrote:
> > > > On Mon, May 12, 2025 at 04:19:59PM +0200, Roger Pau Monné wrote:
> > > > > On Mon, May 12, 2025 at 03:31:19PM +0200, Marek Marczykowski-Górecki wrote:
> > > > > > On Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monné wrote:
> > > > > > > On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-Górecki wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I wanted to post another revision of the series adding hw12 runner,
> > > > > > > > hoping that all known issues are fixed now, but unfortunately there is
> > > > > > > > still something broken. I've rebased my series on top of staging
> > > > > > > > (ed9488a0d) and got this pipeline:
> > > > > > > > 
> > > > > > > > https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/1807819142
> > > > > > > > (note due to some added debugging, some tests are incorrectly marked as
> > > > > > > > success even if they failed...)
> > > > > > > > 
> > > > > > > > 1. USB ethernet doesn't work on PVH dom0: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739
> > > > > > > > There supposed to be an USB ethernet device connected to the USB
> > > > > > > > controller at c3:00.4. In the PV dom0 case it's detected as:
> > > > > > > > 
> > > > > > > >     [    3.911555] usb 7-1.4: new high-speed USB device number 3 using xhci_hcd
> > > > > > > >     [    4.004201] usb 7-1.4: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
> > > > > > > >     [    4.004675] usb 7-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
> > > > > > > >     [    4.005079] usb 7-1.4: Product: USB 10/100/1000 LAN
> > > > > > > >     [    4.005349] usb 7-1.4: Manufacturer: Realtek
> > > > > > > >     [    4.005599] usb 7-1.4: SerialNumber: 684D35
> > > > > > > > 
> > > > > > > > But it's not there on PVH. The USB controller itself is detected, just
> > > > > > > > not device(s) connected to it. This applies to other controllers too
> > > > > > > > (there should be about 3 or 4 other USB devices - none of them show up).
> > > > > > > > 
> > > > > > > > 2. There is a bunch of "unhandled memory read" errors during PVH dom0
> > > > > > > > startup: https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/9978694739
> > > > > > > > 
> > > > > > > >     (XEN) [    4.026323] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0020 size 1
> > > > > > > >     (XEN) [    4.026789] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0021 size 1
> > > > > > > >     (XEN) [    4.027247] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0020 size 1
> > > > > > > >     (XEN) [    4.027671] arch/x86/hvm/emulate.c:417:d0v0 unhandled memory read from 0xfedc0021 size 1
> > > > > > > >     ...
> > > > > > > > 
> > > > > > > > This repeats several times. Could be related to the USB issue above?
> > > > > > > 
> > > > > > > Can you try with dom0=pf-fixup?  Those unhandled accesses might be the
> > > > > > > cause of the USB issues.
> > > > > > 
> > > > > > It did got rid of those messages, but USB still doesn't work:
> > > > > > https://gitlab.com/xen-project/people/marmarek/xen/-/jobs/10006580289
> > > > > 
> > > > > Hm, is it possible that the usage of console=xhci is interfering with
> > > > > USB devices?  Could you try to boot without console=xhci and see if
> > > > > you can still reproduce the issue?  You will need the physical device
> > > > > by your side, which I'm not sure it's possible.  Don't know if you
> > > > > host those remotely somewhere.
> > > > 
> > > > I can try, but will need a proper driver there (in dom0?) - AFAIR VGA
> > > > nor efifb doesn't output to HDMI there (and eDP is not connected).
> > > > Anyway, it's IMO unlikely, given it works just fine with PV dom0...
> > > 
> > > Oh, I see, that's a good data point that it works with PV dom0.
> > > Handling of r/o subpage accesses is still different between PV and PVH
> > > which could maybe explain this, but it's less likely.
> > > 
> > > Maybe I'm not spotting it, but I don't see any specific errors (like
> > > timeouts) from the XHCI controller on the log?  Neither there seems to
> > > be any errors or warnings from Xen.
> > 
> > I don't see any either...
> 
> Roger, it looks like your balloon patch fixes the USB case too :)

Oh, that's great to hear.  I hope I can merge that one together with
the xen.config change soon.  Would you mind giving a Tested-by to the
balloon patch?

https://lore.kernel.org/xen-devel/20250514080427.28129-1-roger.pau@citrix.com/

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 15 08:09:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 08:09:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984893.1370825 (Exim 4.92)
	(envelope-from )
	id 1uFTf0-0004tc-1k; Thu, 15 May 2025 08:09:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984893.1370825; Thu, 15 May 2025 08: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 1uFTez-0004tV-VF; Thu, 15 May 2025 08:09:45 +0000
Received: by outflank-mailman (input) for mailman id 984893;
 Thu, 15 May 2025 08:09:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFTey-0004tN-RI
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 08:09:44 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f59d4a13-3163-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 10:09:44 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5fd1f7f8b25so1356386a12.0
 for ; Thu, 15 May 2025 01:09:44 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad23fc53241sm820639266b.51.2025.05.15.01.09.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 01:09: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" 
X-Inumbo-ID: f59d4a13-3163-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747296584; x=1747901384; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=pi8iuPk0+2M6t7OVDj8Jh6pIaO7j0K24pod54S5dZBc=;
        b=UmwStStIdufp9cyR9U6Ygbc3MLXlyYTh8VyGtUoEIjWD75xlVSPRNkQTyvnhqWCjal
         Y/hZkeNEKyHFEQpTy65ke+aSiSP8/PljQnPFIdPxhzZGKwMIUp6gnyJmOrQHPLYOLWEC
         PbCohDUo2otSf8BAnskuQs69S1wL9+SiDN/aI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747296584; x=1747901384;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=pi8iuPk0+2M6t7OVDj8Jh6pIaO7j0K24pod54S5dZBc=;
        b=pV09L1G8thBBVGSQB1TZB/jO7z3btlCLYl6ADgfFqHR9229QPL6BJDE1P+/Fq/xtNb
         goGkxc6dd+LvfqqaoqruK74o6HA9eQRAUxOdR9oPheFtOM+kA9w8QMz0kJrK0EWaGeyM
         7S1NZPO15VZCg7TKFO0yB68NdI9guqSVAyXBfBrvDq0JTuVaLnu2Bhd0Wm3vzH0sKaZA
         Tvz2kJx0LXkB60HpDCyLzisy9CgX5YG9pVisi3Lb9S14itklmO0mLiLKcs4qvJ2x0eo1
         lNWwzRIpl+U+XWZ8YJX0sWQyWaCOdVBPB5BWYJl/q6qewfI+8EzDwoeNA5uspqC1zmtX
         s1/w==
X-Gm-Message-State: AOJu0Yyl/5/IiRjuDrinMwSwCVmuGBX3LXYLnDSVlX/FSkMoLahC8BP/
	tFN/45s3+yN3Qyx9XFXzH05Cf5xWWVJGewZv9Y8/rA1mwwRtp6/cX2jzyyKD9qU=
X-Gm-Gg: ASbGncv14+qZ9r/G1SbmX/shDStQ0HOFkDyaDOvxG8CRsFV5uXr2BEBchxdmpltwL49
	OzYwXwg+mey0npjMpaUBM3cd5RUvQKZroprducncpuBnJHTQFBetpUGxy5XnTkBaCf+5HaEGerx
	RfflNfImupVpeWqiZWtHsVYjFKxBIj7/qFoN0ZQFJq65QQwfZO2hOwFH79Mu2lzQoGsdkkElIYj
	k5PzL/1Odb/BQhWcd0mgQyM8bji+IYsOxva4GcxqvfMRMti1YamffuDHawEhliePsUALP6iWRpV
	nkucu4HXiXwSEcUZa3A7isqOQA9r6Gr0hhV+zIHIJTZIZFCH1oiMkFlf
X-Google-Smtp-Source: AGHT+IG1G1UhibaXX0EiV6SuXL1lD3hLTofnCUYsFVepUmEzbYXaVBxMwU+OuvIGZmeBrARfepO5hg==
X-Received: by 2002:a17:907:da9:b0:ad2:4787:f1f4 with SMTP id a640c23a62f3a-ad515dc8325mr127918066b.15.1747296583579;
        Thu, 15 May 2025 01:09:43 -0700 (PDT)
Date: Thu, 15 May 2025 10:09:42 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper 
Subject: Re: [PATCH v2 6/6] x86/HVM: limit cache writeback overhead
Message-ID: 
References: 
 <9274fbb1-c1be-9570-ecfc-8f0ac9a1f42b@suse.com>
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, May 15, 2025 at 08:47:46AM +0200, Jan Beulich wrote:
> On 14.05.2025 17:12, Roger Pau Monné wrote:
> > On Wed, May 14, 2025 at 03:20:56PM +0200, Jan Beulich wrote:
> >> On 14.05.2025 15:00, Roger Pau Monné wrote:
> >>> On Wed, May 03, 2023 at 11:47:18AM +0200, Jan Beulich wrote:
> >>>> There's no need to write back caches on all CPUs upon seeing a WBINVD
> >>>> exit; ones that a vCPU hasn't run on since the last writeback (or since
> >>>> it was started) can't hold data which may need writing back.
> >>>
> >>> Couldn't you do the same with PV mode, and hence put the cpumask in
> >>> arch_vcpu rather than hvm_vcpu?
> >>
> >> We could in principle, but there's no use of flush_all() there right now
> >> (i.e. nothing to "win").
> > 
> > Yes, that will get "fixed" if we take patch 2 from my series.  That
> > fixes the lack of broadcasting of wb{,no}invd when emulating it for
> > PV domains.
> > 
> > I think this patch would be better after my fix to cache_op(),
> 
> Right, this matches what I said ...
> 
> > and
> > then the uncertainty around patch 2 makes it unclear whether we want
> > this.
> > 
> >>>> Signed-off-by: Jan Beulich 
> >>>> ---
> >>>> With us not running AMD IOMMUs in non-coherent ways, I wonder whether
> >>>> svm_wbinvd_intercept() really needs to do anything (or whether it
> >>>> couldn't check iommu_snoop just like VMX does, knowing that as of
> >>>> c609108b2190 ["x86/shadow: make iommu_snoop usage consistent with
> >>>> HAP's"] that's always set; this would largely serve as grep fodder then,
> >>>> to make sure this code is updated once / when we do away with this
> >>>> global variable, and it would be the penultimate step to being able to
> >>>> fold SVM's and VT-x'es functions).
> >>>
> >>> On my series I expand cache_flush_permitted() to also account for
> >>> iommu_snoop, I think it's easier to have a single check that signals
> >>> whether cache control is allowed for a domain, rather that having to
> >>> check multiple different conditions.
> >>
> >> Right, adjustments here would want making (in whichever series goes in
> >> later).
> >>
> >> For both of the responses: I think with patch 1 of this series having
> >> gone in and with in particular Andrew's concern over patch 2 (which
> >> may extend to patch 3), it may make sense for your series to go next.
> >> I shall then re-base, while considering what to do with patches 2 and 3
> >> (they may need dropping in the end).
> 
> ... here.

By the time I saw your paragraph, I had already written mine, so I
just left it, we reached the same conclusion which is good IMO :).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 15 08:41:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 08:41:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984912.1370875 (Exim 4.92)
	(envelope-from )
	id 1uFU9q-00028P-P7; Thu, 15 May 2025 08:41:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984912.1370875; Thu, 15 May 2025 08:41: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 1uFU9q-00028I-M5; Thu, 15 May 2025 08:41:38 +0000
Received: by outflank-mailman (input) for mailman id 984912;
 Thu, 15 May 2025 08:41:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFU9p-00028C-WE
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 08:41:38 +0000
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com
 [2607:f8b0:4864:20::435])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 695747d2-3168-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 10:41:37 +0200 (CEST)
Received: by mail-pf1-x435.google.com with SMTP id
 d2e1a72fcca58-7398d65476eso553183b3a.1
 for ; Thu, 15 May 2025 01:41:37 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-7423772752csm10507891b3a.45.2025.05.15.01.41.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 01:41: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" 
X-Inumbo-ID: 695747d2-3168-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747298495; x=1747903295; 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;
        bh=WqRMEPLxqZX/utGkKcFlYQHVQ4/IIk7nsedjFNrB0b0=;
        b=Mk8a2L54H0nBfNQXkPbMMJbAEErjdZEgshR0WWedF+XpNbwqQBkvrDW4/QmcnySEW+
         yvqOE4kYl6VwJZdKDpQyAzTls5CS2wReTWwACmdZZGURlUa0IL1fePa/Zemd1oP1nmTO
         tsQex9vSSNtiF2LcEIt6fAYa1cpAxuwFaCFsM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747298495; x=1747903295;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=WqRMEPLxqZX/utGkKcFlYQHVQ4/IIk7nsedjFNrB0b0=;
        b=Z2IQs7z2mdm4BDhf6r0IWvsbV/8bOCMWCSnyd4jrb/qhrxQRwxpKRLYBPOk3zfYw0s
         qCa0RBiaSamcspQm5T1IHyg/ffNBlW965G+qn/aQYeM+XBJdWLvH/ueFfmcpaaubqB2p
         L729x+6LXKjVpyzZGzkBiq7/YWke3cyNzJ7CUnzT5d+GZukmvvE4LLrU8WyBqjwoFXZc
         1H7vK/tZdLULH2Vzp4dqVcw0DSfVHAUff8G6oGaLgyr5OukQ0rS/gkKNU96yiJeHgxOG
         5kPFHK2QNIaLFI2DOYcNJeOshh1+Uc0393GgJIgsM0Ea8ZgV/uSrKwXIQfsYdiO38Icx
         RdNw==
X-Gm-Message-State: AOJu0YwPt+QFxggMOwa+ADxKfBoCDPyqrARVhjLcDBXhDpmv8qCfThnC
	vNzIXKdvzohgfc7Cr+5dJvgS42vW1TOj1DkKZEdjgDrcYJxxAGMM5Cdq/ZflECKybmFYhE0S4O4
	g
X-Gm-Gg: ASbGncv7hMZp052J+fG2Dq5ggyl0LXJqwxXGqx+t0It90eLrscqUf67vXcVU0emI6UY
	AkY8TigCHVxu5drBHZdfJscSPu0VA82G0HyyNl6oIgDik7RPgx8uybOz+0K5sTYEsOM5N91quI0
	gxXyO5WyWo+F2Yxmih+0PduxcZtlsPA+IdJ2qRhmNqmGdld7HrAr8NB7XYRo2E8rKSky9FG3be3
	YsFhooXu+zUi4xtrx+1zg7wjEXdqxKFZGb59r1DAJ6zMfLG8fasu0R5tL6kBgjKUuoOyh1R2ucO
	glYyEZrBH4jaXAOCJEzO5z663eXqhKcVs1B5rHGhq1YWKM/+ITpjqhs2
X-Google-Smtp-Source: AGHT+IG42YuSndUT6fbaWN3j55pDUxRF9q12AgzIQzFnztBZAObLPZ7lAt0mFUImHIjgAxxrIqEJgA==
X-Received: by 2002:a05:6a00:2d25:b0:736:4e14:8ec5 with SMTP id d2e1a72fcca58-742962219damr3655823b3a.11.1747298494568;
        Thu, 15 May 2025 01:41:34 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Jan Beulich ,
	Andrew Cooper ,
	Stefano Stabellini 
Subject: [PATCH] x86/vpci: fix handling of BAR overlaps with non-hole regions
Date: Thu, 15 May 2025 10:41:23 +0200
Message-ID: <20250515084123.43289-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

For once the message printed when a BAR overlaps with a non-hole regions is
not accurate on x86.  While the BAR won't be mapped by the vPCI logic, it
is quite likely overlapping with a reserved region in the memory map, and
already mapped as by default all reserved regions are identity mapped in
the p2m.  Fix the message so it just warns about the overlap, without
mentioning that the BAR won't be mapped, as this has caused confusion in
the past.

Secondly, when an overlap is detected the BAR 'enabled' field is not set,
hence other vPCI code that depends on it like vPCI MSI-X handling won't
function properly, as it sees the BAR as disabled, even when memory
decoding is enabled for the device and the BAR is likely mapped in the
p2m.  Change the handling of BARs that overlap non-hole regions to instead
remove any overlapped regions from the rangeset, so the resulting ranges to
map just contain the hole regions.  This requires introducing a new
pci_sanitize_bar_memory() that's implemented per-arch and sanitizes the
address range to add to the p2m.

For x86 pci_sanitize_bar_memory() removes any regions present in the host
memory map, for ARM this is currently left as a dummy handler to not change
existing behavior.

Ultimately the above changes should fix the vPCI MSI-X handlers not working
correctly when the BAR that contains the MSI-X table overlaps with a
non-hole region, as then the 'enabled' BAR bit won't be set and the MSI-X
traps won't handle accesses as expected.

Reported-by: Stefano Stabellini 
Fixes: 53d9133638c3 ('pci: do not disable memory decoding for devices')
Signed-off-by: Roger Pau Monné 
---
 xen/arch/arm/include/asm/pci.h |  3 ++
 xen/arch/x86/include/asm/pci.h | 12 ++------
 xen/arch/x86/pci.c             | 50 ++++++++++++++++++++++++++++++++++
 xen/drivers/vpci/header.c      |  9 ++++++
 4 files changed, 65 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
index 7f77226c9bbf..1605ec660d0b 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -128,6 +128,9 @@ int pci_host_bridge_mappings(struct domain *d);
 
 bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
 
+static inline int pci_sanitize_bar_memory(struct rangeset *r)
+{ return 0; }
+
 #else   /*!CONFIG_HAS_PCI*/
 
 struct pci_dev;
diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h
index fd5480d67d43..d2701f2deb62 100644
--- a/xen/arch/x86/include/asm/pci.h
+++ b/xen/arch/x86/include/asm/pci.h
@@ -2,6 +2,7 @@
 #define __X86_PCI_H__
 
 #include 
+#include 
 
 #define CF8_BDF(cf8)     (  ((cf8) & 0x00ffff00U) >> 8)
 #define CF8_ADDR_LO(cf8) (   (cf8) & 0x000000fcU)
@@ -57,14 +58,7 @@ static always_inline bool is_pci_passthrough_enabled(void)
 
 void arch_pci_init_pdev(struct pci_dev *pdev);
 
-static inline bool pci_check_bar(const struct pci_dev *pdev,
-                                 mfn_t start, mfn_t end)
-{
-    /*
-     * Check if BAR is not overlapping with any memory region defined
-     * in the memory map.
-     */
-    return is_memory_hole(start, end);
-}
+bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
+int pci_sanitize_bar_memory(struct rangeset *r);
 
 #endif /* __X86_PCI_H__ */
diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
index 97b792e578f1..afaf9fe1c053 100644
--- a/xen/arch/x86/pci.c
+++ b/xen/arch/x86/pci.c
@@ -98,3 +98,53 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
 
     return rc;
 }
+
+bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
+{
+    /*
+     * Check if BAR is not overlapping with any memory region defined
+     * in the memory map.
+     */
+    if ( !is_memory_hole(start, end) )
+        gdprintk(XENLOG_WARNING,
+                 "%pp: BAR at [%"PRI_mfn", %"PRI_mfn"] not in memory map hole\n",
+                 &pdev->sbdf, mfn_x(start), mfn_x(end));
+
+    /*
+     * Unconditionally return true, pci_sanitize_bar_memory() will remove any
+     * non-hole regions.
+     */
+    return true;
+}
+
+/* Remove overlaps with any ranges defined in the host memory map. */
+int pci_sanitize_bar_memory(struct rangeset *r)
+{
+    unsigned int i;
+
+    for ( i = 0; i < e820.nr_map; i++ )
+    {
+        const struct e820entry *entry = &e820.map[i];
+        int rc;
+
+        if ( !entry->size )
+            continue;
+
+        rc = rangeset_remove_range(r, PFN_DOWN(entry->addr),
+                                   PFN_UP(entry->addr + entry->size - 1));
+        if ( rc )
+            return rc;
+    }
+
+    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/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index ef6c965c081c..1f48f2aac64e 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -394,6 +394,15 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
                 return rc;
             }
         }
+
+        rc = pci_sanitize_bar_memory(bar->mem);
+        if ( rc )
+        {
+            gprintk(XENLOG_WARNING,
+                    "%pp: failed to sanitize BAR#%u memory: %d\n",
+                    &pdev->sbdf, i, rc);
+            return rc;
+        }
     }
 
     /* Remove any MSIX regions if present. */
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu May 15 08:43:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 08:43:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984919.1370885 (Exim 4.92)
	(envelope-from )
	id 1uFUBD-0002d0-2v; Thu, 15 May 2025 08:43:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984919.1370885; Thu, 15 May 2025 08:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFUBC-0002ct-VP; Thu, 15 May 2025 08:43:02 +0000
Received: by outflank-mailman (input) for mailman id 984919;
 Thu, 15 May 2025 08:43:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFUBC-0002cl-1R
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 08:43:02 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9b207458-3168-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 10:42:59 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-acbb85ce788so136238166b.3
 for ; Thu, 15 May 2025 01: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
 a640c23a62f3a-ad2197bd3a6sm1067101166b.131.2025.05.15.01.42.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 01: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" 
X-Inumbo-ID: 9b207458-3168-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747298579; x=1747903379; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=c54MK/hnu+A4PUQDWcJ32gWT8lwT2BxEF066k6TXkdE=;
        b=SBF+qnnN8bNqO0FUCoOIkSxKv40vHmwNIybUA6BdD0Sh9Jyp+2yIOCe3BhL3injLsE
         +ubtHGDvGKdBkVKhaiobBm2WDmPYb/7QD9SiOQmntcLknvzeQSfgU6/ZuGqB2GPnusFf
         kLMnWXqZhzWv7kPg5imFcZMteKQF2d6oCMl+1GjgISEQ4wqyOs07K35AlBrHNVa9xSeO
         d0eygF+0e7I94/NTDLJQ+y3JKwmPTuzz7KzvtWhIbJC9N6Nw6chQtJP7a5yjqWQFRDEe
         9GZ8nlV7l60yQZAJobs1/TThMlN7rG4kasqn/mKG5MEj6bT7qBWJGx4Cpsb+H5uR05gI
         ecLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747298579; x=1747903379;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=c54MK/hnu+A4PUQDWcJ32gWT8lwT2BxEF066k6TXkdE=;
        b=mlrw8zlCTwfgxsOt/F9I/Jt//HSa5NnGOH+LrWdBnwZyrCy9g1CCtGG5MZ9L9PBbkL
         uvB1K3MG1m8Zr19fUQPondptuLw5PuZ6eTryXzyb1Y8D8cd5adCcaKv+vGKElcVf5EIH
         Zru18vAVEGpICcoZ4aL0iN+VhOsP3QLxEBxJo/gw7jkRRakrTRST0J6EXMGAL6jdknK4
         hb591LauNC8KlkF39lFhrLWzUemYDT1543KBxFWVo7jThGS5oEh1y/M00m3JkfuRl13l
         0Vu+QmEwq0DCvPzvPIQGOM+5ufBKGO/JO16HakE878cEwC2esow59/Wf72ifxdUGoBTI
         Kfrw==
X-Forwarded-Encrypted: i=1; AJvYcCVRz6EGAVUwSd7yUtc9XFnr+kgKND1pWTDN62Yzse+CbaaIiGxhvUITUMAYZe2Wj3aq8a1HjSiK6Tw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywa5wHA1ls9C7UGJknFslcVYFoy/qdMa6HgTmOlf+9aRNTHX62R
	BchYuXHZOIA9gTQr9/1Jkhw8umzYo5A1+xByTb9zmO7bL2AU+xjd51ybfuEwtQ==
X-Gm-Gg: ASbGncvC1Ib0oX2YEY9OMx6xav9moFQyU9BwYt2l1QjYcComEunpTqANWpSLOtp8w70
	59uK+wj2d+sFF0VYhX9wiMnFBy/RQbWdcglbiZUugIvU2Z+zAxTqGSK0vMooW13I40HC5F192Ua
	13PWlo3jmXrOezaUdMbViaazyaMP8Xft8Fu1XS9Y5NO5HhpPlLclRgJJl97M2DTIaNLmryP/8Dt
	Vx5yaG7gH7m4PoOgz4EyQwZDBqp4hlqN2Wq2LZhTNBypZmM2QnV/bXwjuLuuEs/TBsvfY0Fu3mO
	NLIOfOCaj4D9Z3YYloyQuHj68Rc94ktkgGgYQT2cZLkusdaZPT+DZz7PB6i93irIsqXJvKQdEMk
	xVka5ip6eYadT+qS9jlMNbpcFD6d7dZc/5yCl
X-Google-Smtp-Source: AGHT+IGOJTko5rOcHYaHvbtw7SSIbRdSXDiy4/b6lLdUVFtgRZbI0ZKFZ6aqe2yXFE6rlXE2HboKvQ==
X-Received: by 2002:a17:907:86a1:b0:ad2:4374:84a2 with SMTP id a640c23a62f3a-ad4f70f61eamr622003766b.6.1747298579162;
        Thu, 15 May 2025 01:42:59 -0700 (PDT)
Message-ID: <0d9a9a9e-3454-465f-ac1d-cd65ba4a5792@suse.com>
Date: Thu, 15 May 2025 10:42:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/16] xen/riscv: imsic_init() implementation
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , 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

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> imsic_init() is introduced to parse device tree node, which has the following
> bindings [2], and based on the parsed information update IMSIC configuration
> which is stored in imsic_cfg.
> 
> The following helpers are introduces for imsic_init() usage:
>   - imsic_parse_node() parses IMSIC node from DTS
>   - imsic_get_parent_cpuid() returns the hart ( CPU ) ID of the given device
>     tree node.
> 
> This patch is based on the code from [1].
> 
> Since Microchip originally developed imsic.{c,h}, an internal discussion with
> them led to the decision to use the MIT license.
> 
> [1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/0b1a94f2bc3bb1a81cd26bb75f0bf578f84cb4d4
> [2] https://elixir.bootlin.com/linux/v6.12/source/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
> 
> Co-developed-by: Romain Caritey 
> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in V2:
>  - Drop years in copyrights.

Did you, really?

>  - s/riscv_of_processor_hartid/dt_processor_cpuid.
>  - s/imsic_get_parent_hartid/imsic_get_parent_cpuid.
>    Rename argument hartid to cpuid.
>    Make node argument const.
>    Return res instead of -EINVAL for the failure case of dt_processor_cpuid().
>    Drop local variable hart and use cpuid argument instead.
>    Drop useless return res;
>  - imsic_parse_node() changes:
>    - Make node argument const.
>    - Check the return value of dt_property_read_u32() directly instead of
>      saving it to rc variable.
>    - Update tmp usage, use short form "-=".
>    - Update a check (imsic_cfg.nr_ids >= IMSIC_MAX_ID) to (imsic_cfg.nr_ids > IMSIC_MAX_ID)
>      as IMSIC_MAX_ID is changed to maximum valid value, not just the firsr out-of-range.
>    - Use `rc` to return value instead of explicitly use -EINVAL.
>    - Use do {} while() to find number of MMIO register sets.
>  - Set IMSIC_MAX_ID to 2047 (maximum possible IRQ number).
>  - imsic_init() changes:
>    - Use unsigned int in for's expression1.
>    - s/xfree/XFEE.
>    - Allocate msi and cpus array dynamically.
>  - Drop forward declaration before declaration of imsic_get_config() in asm/imsic.h
>    as it is not used as parameter type.
>  - Align declaration of imisic_init with defintion.
>  - s/harts/cpus in imisic_mmios.
>    Also, change type from bool harts[NR_CPUS] to unsigned long *cpus.
>  - Allocate msi member of imsic_config dynamically to save some memory.
>  - Code style fixes.
>  - Update the commit message.
> ---
>  xen/arch/riscv/Makefile            |   1 +
>  xen/arch/riscv/imsic.c             | 286 +++++++++++++++++++++++++++++
>  xen/arch/riscv/include/asm/imsic.h |  65 +++++++
>  3 files changed, 352 insertions(+)
>  create mode 100644 xen/arch/riscv/imsic.c
>  create mode 100644 xen/arch/riscv/include/asm/imsic.h
> 
> diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
> index a1c145c506..e2b8aa42c8 100644
> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -2,6 +2,7 @@ obj-y += aplic.o
>  obj-y += cpufeature.o
>  obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
>  obj-y += entry.o
> +obj-y += imsic.o
>  obj-y += intc.o
>  obj-y += irq.o
>  obj-y += mm.o
> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
> new file mode 100644
> index 0000000000..43d0c92cbd
> --- /dev/null
> +++ b/xen/arch/riscv/imsic.c
> @@ -0,0 +1,286 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/imsic.c
> + *
> + * RISC-V Incoming MSI Controller support
> + *
> + * (c) Microchip Technology Inc.
> + * (c) Vates
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +static struct imsic_config imsic_cfg;
> +
> +/* Callers aren't expected to changed imsic_cfg so return const. */
> +const struct imsic_config *imsic_get_config(void)
> +{
> +    return &imsic_cfg;
> +}
> +
> +static int __init imsic_get_parent_cpuid(const struct dt_device_node *node,
> +                                         unsigned int index,
> +                                         unsigned long *cpuid)
> +{
> +    int res;
> +    struct dt_phandle_args args;
> +
> +    res = dt_parse_phandle_with_args(node, "interrupts-extended",
> +                                     "#interrupt-cells", index, &args);
> +    if ( !res )
> +        res = dt_processor_cpuid(args.np->parent, cpuid);
> +
> +    return res;
> +}
> +
> +static int imsic_parse_node(const struct dt_device_node *node,
> +                            unsigned int *nr_parent_irqs)
> +{
> +    int rc;
> +    unsigned int tmp;
> +    paddr_t base_addr;
> +
> +    /* Find number of parent interrupts */
> +    *nr_parent_irqs = dt_number_of_irq(node);
> +    if ( !*nr_parent_irqs )
> +    {
> +        printk(XENLOG_ERR "%s: no parent irqs available\n", node->name);
> +        return -ENOENT;
> +    }
> +
> +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
> +                               &imsic_cfg.guest_index_bits) )
> +        imsic_cfg.guest_index_bits = 0;
> +    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
> +    if ( tmp < imsic_cfg.guest_index_bits )
> +    {
> +        printk(XENLOG_ERR "%s: guest index bits too big\n", node->name);
> +        return -ENOENT;
> +    }
> +
> +    /* Find number of HART index bits */
> +    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
> +                               &imsic_cfg.hart_index_bits) )
> +    {
> +        /* Assume default value */
> +        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
> +        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
> +            imsic_cfg.hart_index_bits++;
> +    }
> +    tmp -= imsic_cfg.guest_index_bits;
> +    if ( tmp < imsic_cfg.hart_index_bits )
> +    {
> +        printk(XENLOG_ERR "%s: HART index bits too big\n", node->name);
> +        return -ENOENT;
> +    }
> +
> +    /* Find number of group index bits */
> +    if ( !dt_property_read_u32(node, "riscv,group-index-bits",
> +                               &imsic_cfg.group_index_bits) )
> +        imsic_cfg.group_index_bits = 0;
> +    tmp -= imsic_cfg.hart_index_bits;
> +    if ( tmp < imsic_cfg.group_index_bits )
> +    {
> +        printk(XENLOG_ERR "%s: group index bits too big\n", node->name);
> +        return -ENOENT;
> +    }
> +
> +    /* Find first bit position of group index */
> +    tmp = IMSIC_MMIO_PAGE_SHIFT * 2;
> +    if ( !dt_property_read_u32(node, "riscv,group-index-shift",
> +                               &imsic_cfg.group_index_shift) )
> +        imsic_cfg.group_index_shift = tmp;
> +    if ( imsic_cfg.group_index_shift < tmp )
> +    {
> +        printk(XENLOG_ERR "%s: group index shift too small\n", node->name);
> +        return -ENOENT;
> +    }
> +    tmp = imsic_cfg.group_index_bits + imsic_cfg.group_index_shift - 1;
> +    if ( tmp >= BITS_PER_LONG )
> +    {
> +        printk(XENLOG_ERR "%s: group index shift too big\n", node->name);
> +        return -EINVAL;
> +    }
> +
> +    /* Find number of interrupt identities */
> +    if ( !dt_property_read_u32(node, "riscv,num-ids", &imsic_cfg.nr_ids) )
> +    {
> +        printk(XENLOG_ERR "%s: number of interrupt identities not found\n",
> +               node->name);
> +        return -ENOENT;
> +    }
> +
> +    if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) ||
> +         (imsic_cfg.nr_ids > IMSIC_MAX_ID) ||
> +         ((imsic_cfg.nr_ids & IMSIC_MIN_ID) != IMSIC_MIN_ID) )
> +    {
> +        printk(XENLOG_ERR "%s: invalid number of interrupt identities\n",
> +               node->name);
> +        return -EINVAL;
> +    }
> +
> +    /* Compute base address */
> +    imsic_cfg.nr_mmios = 0;
> +    rc = dt_device_get_address(node, imsic_cfg.nr_mmios, &base_addr, NULL);
> +    if ( rc )
> +    {
> +        printk(XENLOG_ERR "%s: first MMIO resource not found\n", node->name);
> +        return rc;
> +    }
> +
> +    imsic_cfg.base_addr = base_addr;
> +    imsic_cfg.base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
> +                           imsic_cfg.hart_index_bits +
> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);

Nit: indentation, similarly ...

> +    imsic_cfg.base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
> +                           imsic_cfg.group_index_shift);

... here.

> +    /* Find number of MMIO register sets */
> +    do {
> +        imsic_cfg.nr_mmios++;
> +    } while ( !dt_device_get_address(node, imsic_cfg.nr_mmios, &base_addr, NULL) );
> +
> +    return 0;
> +}
> +
> +int __init imsic_init(const struct dt_device_node *node)
> +{
> +    int rc;
> +    unsigned long reloff, cpuid;
> +    uint32_t nr_parent_irqs, index, nr_handlers = 0;

I can't spot why unsigned int wouldn't be suitable here. In fact e.g. ...

> +    paddr_t base_addr;
> +    unsigned int nr_mmios;
> +
> +    /* Parse IMSIC node */
> +    rc = imsic_parse_node(node, &nr_parent_irqs);

... this one wants to yield unsigned int * according to the function parameter's
type.

> +    if ( rc )
> +        return rc;
> +
> +    nr_mmios = imsic_cfg.nr_mmios;
> +
> +    /* Allocate MMIO resource array */
> +    imsic_cfg.mmios = xzalloc_array(struct imsic_mmios, nr_mmios);
> +    if ( !imsic_cfg.mmios )
> +        return -ENOMEM;
> +
> +    imsic_cfg.msi = xzalloc_array(struct imsic_msi, nr_parent_irqs);
> +    if ( !imsic_cfg.msi )
> +        return -ENOMEM;

Leaking the earlier successful allocation?

> +    /* Check MMIO register sets */
> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
> +    {
> +        imsic_cfg.mmios[i].cpus = xzalloc_array(unsigned long,
> +                                                BITS_TO_LONGS(nr_parent_irqs));
> +        if ( !imsic_cfg.mmios[i].cpus )
> +            return -ENOMEM;

Leaking all earlier successful allocations?

> +        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
> +                                   &imsic_cfg.mmios[i].size);
> +        if ( rc )
> +        {
> +            printk(XENLOG_ERR "%s:  unable to parse MMIO regset %d\n",

Nit: Excess blank.

> +                   node->name, i);
> +            goto imsic_init_err;
> +        }
> +
> +        base_addr = imsic_cfg.mmios[i].base_addr;
> +        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
> +                     imsic_cfg.hart_index_bits +
> +                     IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
> +                     imsic_cfg.group_index_shift);

As above, indentation again.

> +        if ( base_addr != imsic_cfg.base_addr )
> +        {
> +            rc = -EINVAL;
> +            printk(XENLOG_ERR "%s: address mismatch for regset %d\n",
> +                   node->name, i);
> +            goto imsic_init_err;
> +        }
> +    }
> +
> +    /* Configure handlers for target CPUs */
> +    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
> +    {
> +        rc = imsic_get_parent_cpuid(node, i, &cpuid);

Coming back to a comment I gave on the respective earlier patch: What you get back
here is a DT value, aiui. There's no translation to Xen CPU numbering space, as
would be required for e.g. ...

> +        if ( rc )
> +        {
> +            printk(XENLOG_WARNING "%s: cpu ID for parent irq%d not found\n",
> +                   node->name, i);
> +            continue;
> +        }
> +
> +        if ( cpuid >= num_possible_cpus() )

... this. Are you using DT numbering without any translation, no matter that it
(I suppose) could be very sparse?

> +        {
> +            printk(XENLOG_WARNING "%s: unsupported cpu ID=%lu for parent irq%d\n",
> +                   node->name, cpuid, i);

Nit: i is unsigned int, so wants formatting with %u (also applicable elsewhere).

> +            continue;
> +        }
> +
> +        /* Find MMIO location of MSI page */
> +        index = nr_mmios;
> +        reloff = i * BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ;
> +        for ( unsigned int j = 0; nr_mmios; j++ )

DYM "j < nr_mmios"?

> +        {
> +            if ( reloff < imsic_cfg.mmios[j].size )
> +            {
> +                index = j;
> +                break;
> +            }
> +
> +            /*
> +             * MMIO region size may not be aligned to
> +             * BIT(global->guest_index_bits) * IMSIC_MMIO_PAGE_SZ
> +             * if holes are present.
> +             */
> +            reloff -= ROUNDUP(imsic_cfg.mmios[j].size,
> +                BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ);
> +        }
> +
> +        if ( index >= nr_mmios )

Why is it that you need both "index" and "j"?

> +        {
> +            printk(XENLOG_WARNING "%s: MMIO not found for parent irq%d\n",
> +                   node->name, i);
> +            continue;
> +        }
> +
> +        if ( !IS_ALIGNED(imsic_cfg.msi[cpuid].base_addr + reloff, PAGE_SIZE) )
> +        {
> +            printk(XENLOG_WARNING "%s: MMIO address 0x%lx is not aligned on a page\n",

Please prefer to use %#lx, as we do elsewhere.

> +                   node->name, imsic_cfg.msi[cpuid].base_addr + reloff);
> +            imsic_cfg.msi[cpuid].offset = 0;
> +            imsic_cfg.msi[cpuid].base_addr = 0;
> +            continue;
> +        }
> +
> +        bitmap_set(imsic_cfg.mmios[index].cpus, cpuid, 1);

Depending on clarification on the number space used, this may want to be
cpumask_set_cpu() instead. Else I think this is simply __set_bit().

> +        imsic_cfg.msi[cpuid].base_addr = imsic_cfg.mmios[index].base_addr;
> +        imsic_cfg.msi[cpuid].offset = reloff;

How come it's cpuid that's used as array index here? Shouldn't this be i,
seeing that the array allocation is using nr_parent_irqs?

> +        nr_handlers++;
> +    }
> +
> +    if ( !nr_handlers )
> +    {
> +        printk(XENLOG_ERR "%s: No CPU handlers found\n", node->name);
> +        rc = -ENODEV;
> +        goto imsic_init_err;
> +    }
> +
> +    return 0;
> +
> + imsic_init_err:
> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
> +        XFREE(imsic_cfg.mmios[i].cpus);

This can be just xfree(), as the array itself ...

> +    XFREE(imsic_cfg.mmios);

... is then also freed.

> +    XFREE(imsic_cfg.msi);
> +
> +    return rc;
> +}
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/imsic.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/imsic.h
> + *
> + * RISC-V Incoming MSI Controller support
> + *
> + * (c) 2023 Microchip Technology Inc.
> + */
> +
> +#ifndef ASM__RISCV__IMSIC_H
> +#define ASM__RISCV__IMSIC_H
> +
> +#include 
> +
> +#define IMSIC_MMIO_PAGE_SHIFT   12
> +#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
> +
> +#define IMSIC_MIN_ID            63

This isn't the "minimum ID", but the "minimum permissible number of IDs" as per
its first use in imsic_parse_node(). Further uses there consider it a mask,
which makes me wonder whether the imsic_cfg.nr_ids field name is actually
correct: Isn't this the maximum valid ID rather than their count/number?

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 08:53:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 08:53:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984951.1370894 (Exim 4.92)
	(envelope-from )
	id 1uFUKz-0004S6-2s; Thu, 15 May 2025 08:53:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984951.1370894; Thu, 15 May 2025 08: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 1uFUKz-0004Rz-0K; Thu, 15 May 2025 08:53:09 +0000
Received: by outflank-mailman (input) for mailman id 984951;
 Thu, 15 May 2025 08:53:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFUKx-0004Rt-7k
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 08:53:07 +0000
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com
 [2607:f8b0:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fb4f894a-3169-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 10:52:51 +0200 (CEST)
Received: by mail-pf1-x42b.google.com with SMTP id
 d2e1a72fcca58-7406c6dd2b1so1543983b3a.0
 for ; Thu, 15 May 2025 01:52:51 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-22fc7546aefsm113085255ad.37.2025.05.15.01.52.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 01:52:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fb4f894a-3169-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747299170; x=1747903970; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=nQJIFPkZ1E2RYkoyUNZqDnBF0F0qsw5TjA12sLk+xz0=;
        b=vysPlycJ9KWV6bPFFBr9PFe9AoOVkcqc6+rUv6QYMOGrZCB7Hlfrt7fNdFc09lHedC
         5PqsRShjgbOI3ScvadratRTFXaeT3kOr6cJ3wyn39OIcAeZiT9ns73yc843W+prF4mXu
         bbbQeqIYy5FTxRy/iSwLLRC5HylIAdQrpwcaM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747299170; x=1747903970;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nQJIFPkZ1E2RYkoyUNZqDnBF0F0qsw5TjA12sLk+xz0=;
        b=q8NcNXEbettfW9FjQR+79c8VrYM84UIj0V6Z88ljjSkGI8kYJbOvCq865yLL2Rjmfg
         3ziwiml1tlJGwdU9ryCUejyCRc6kQRuktZ9znSeiA+xoaOQemTcEEAMD9SybJ5Xr3xma
         og4eTNpFXsKwDdmqNeH1PpR+T7cpYziNfF62zF3/H8yur6xQacRuAg9fbFhRo81lLpVW
         /5hOwv6i3dy9wpp8obFrdU0KZ+VmA0f1sZOl+N8lY3Wlf3RaLZQ73qUyJVrV92kygWep
         jRfVpf8QJDqj2SuFX+cDegU26byQpYI1vnXcBUAVFxyLnNPO5e2GhcpFh3e1yPZJWOhD
         f7ng==
X-Gm-Message-State: AOJu0YxfULe36Pmq83nCU8m7NImjaLs5Awl4NQLuXWdYT+UlLlGi7ROU
	G3Vklf/hScZH/MPCFfgQNkndjnVJxF8qApO+z/K4u6WjQjjfRRybzBSW7VUg4pu/FEQ=
X-Gm-Gg: ASbGncuM1f+NNET5iKNFYPh7uve342F9Hkw0++Nktv6A8g0C8wI8E0PfhIK7imGnL5x
	Z6nHY6qR77QXslffgs5XDs9J53D4xthwT2bpciirzsxhhm9KHhwsXn30HA0DkdCshOr28ngQtdT
	/zn5UQu1pB4yNGvh1WpiNHPyOflG0gkR6omtdO/stc9lsg5pWmcGWs1LIIfEg0SVOghG1nsgvcN
	5hwoQz704m7IywGjVoMTausOS1XdyPTpP4Nx27fJ61N6i02iltBtxYxElOR/ZVE7IGsnXLTV3tP
	7ABUkZh09dwecXbqHTZ7Y2ZorSJSMVjE+s0CU5h8qHipwJ/gbO/sOeTm
X-Google-Smtp-Source: AGHT+IHVkJDQsSPJoZ1Aqwp7Co47f/qgm1ZodGe1JlzhpAhPibMdI9Jdxl+iPVJ8RcNBRxSA9sA3fw==
X-Received: by 2002:a17:902:f68f:b0:224:3994:8a8c with SMTP id d9443c01a7336-231b3959febmr40012325ad.8.1747299169964;
        Thu, 15 May 2025 01:52:49 -0700 (PDT)
Date: Thu, 15 May 2025 10:52:44 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 4/6] rangeset: introduce rangeset_subtract
Message-ID: 
References: <20250508132040.532898-1-stewart.hildebrand@amd.com>
 <20250508132040.532898-5-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250508132040.532898-5-stewart.hildebrand@amd.com>

On Thu, May 08, 2025 at 09:20:33AM -0400, Stewart Hildebrand wrote:
> Introduce rangeset_subtract() to remove regions in r2 from r1.

Oh, you could have replaced the code in arch_iommu_hwdom_init() to
make use of this new helper.  I will prepare a patch now.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 15 08:58:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 08:58:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984961.1370905 (Exim 4.92)
	(envelope-from )
	id 1uFUPW-00052F-OK; Thu, 15 May 2025 08:57:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984961.1370905; Thu, 15 May 2025 08: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 1uFUPW-000528-LP; Thu, 15 May 2025 08:57:50 +0000
Received: by outflank-mailman (input) for mailman id 984961;
 Thu, 15 May 2025 08:57:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFUPW-00051B-8W
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 08:57:50 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ada68be8-316a-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 10:57:49 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5ff8f218c44so1159145a12.2
 for ; Thu, 15 May 2025 01:57:49 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 4fb4d7f45d1cf-5fd2b82297esm6725667a12.44.2025.05.15.01.57.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 01: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" 
X-Inumbo-ID: ada68be8-316a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747299469; x=1747904269; 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;
        bh=dPMC2a32nfUHx7ydYxaYGIrNsdP6VcsU+I3gbxfq+8I=;
        b=j5Z8XiuQNl5LSpDts5JGvawpDW71V6cgx+Zhhku6+ausYPliSaurAwdNVV0S+CAdtz
         HZ5gvsfyS5vrwfnJW6ztCOVFymlxfSxryCTgcvpYR0N+iolk0N4XEZ4LM2eGyP5Zl0/M
         P788lNre0cxgFU8dZxdoi7L8fmgotTb02LtYs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747299469; x=1747904269;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=dPMC2a32nfUHx7ydYxaYGIrNsdP6VcsU+I3gbxfq+8I=;
        b=csK25hrMutgHl3XztdzJQjt5u7om8X/lzecr2/VG1rAwatUwIzL+GIB82qe9JGETqd
         QeGneAq/Ge9JCoAGhcmT5FaFCXiO7R3EYPOpLP3Zb9V0NOQgRN/MQCsCzsf8FGeAUDMT
         wCf/rvhEmA4dr4M0e5AuNwAnFLyyycJM9WnGJK0RVFxXraSJPpdrpfGmo2f7AiKDMggM
         cvWgTn6amFOkzodjCSXPTkBH4OcARUQ7ycU3yAsOpIIzJT9U1s1qTc1/1BkSWw7pvXim
         2P+Kq00LjFMIkN3vknVZUP4tO4OnWEe3hqwIcUF/0gHkNoL0uEaj1GPp4AQvmp9NnL6u
         glYg==
X-Gm-Message-State: AOJu0Yx5MkbMnyXkkhEcTGfdD4Nn8AZF7ffWTkCcENGlkP0ZZ1SLxuOE
	U6uy11oUn0y0H+7jqCqTeAqpZkyffpFuU7DW5y9ND7qTPhPLNm6EBdjlT0sEv2Zx3F9MCaOayIh
	W
X-Gm-Gg: ASbGnct9dNkkNtK9LifrdM//o8FILVRw55yqnMj0/T0bI6dC85Qwkj7eRUcwWHnjHpT
	nkSnfIwVB4oXpjL7Ba0VBcR9qdUgTvBoZf+CgVJsGUkjZ0E5wbOTs+1GKezDIwf1C+jgB1BEMOX
	TmMYwVCMVqGVEet9OCU1tioNnQmeIXiFLzHu3VjniteZs18ENXGEo71k7etETL5Netxeb0eOmJI
	KUVfhg0qTweUlsEUPOVmcdZubo2PKwGojvazcKwOwVydxjLNch/9oCLjCK3CTpM/8VIGXd02ACo
	qwUZW5qh6CGske0HEJ0/BBDcCAqoSM9F/3R/kjJGtw3AmkfpHyzCAOo+
X-Google-Smtp-Source: AGHT+IGNC+zHkAkvn9BNql+izQ4gohj5dhZo8dIh6XaT66QGHRYD2wgVCXwWSReGHdTO4FEaD8M5rQ==
X-Received: by 2002:a05:6402:1851:b0:5ff:ef06:1c42 with SMTP id 4fb4d7f45d1cf-5ffef061f64mr714082a12.22.1747299469016;
        Thu, 15 May 2025 01:57:49 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich 
Subject: [PATCH] x86/iommu: use rangeset_subtract() in arch_iommu_hwdom_init()
Date: Thu, 15 May 2025 10:57:46 +0200
Message-ID: <20250515085746.43498-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Remove an open-coded instance of rangeset_subtract().  No functional change
intended.

Signed-off-by: Roger Pau Monné 
---
 xen/drivers/passthrough/x86/iommu.c | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/xen/drivers/passthrough/x86/iommu.c b/xen/drivers/passthrough/x86/iommu.c
index 67f025c1ec6a..0954cc49225e 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -312,14 +312,6 @@ void iommu_identity_map_teardown(struct domain *d)
     }
 }
 
-static int __hwdom_init cf_check map_subtract(unsigned long s, unsigned long e,
-                                              void *data)
-{
-    struct rangeset *map = data;
-
-    return rangeset_remove_range(map, s, e);
-}
-
 struct handle_iomemcap {
     struct rangeset *r;
     unsigned long last;
@@ -505,7 +497,7 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
          * since ranges in mmio_ro_ranges are already explicitly mapped below
          * in read-only mode.
          */
-        rc = rangeset_report_ranges(mmio_ro_ranges, 0, ~0UL, map_subtract, map);
+        rc = rangeset_subtract(map, mmio_ro_ranges);
         if ( rc )
             panic("IOMMU failed to remove read-only regions: %d\n", rc);
     }
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu May 15 09:01:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:01:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984970.1370915 (Exim 4.92)
	(envelope-from )
	id 1uFUT7-0006kT-8b; Thu, 15 May 2025 09:01:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984970.1370915; Thu, 15 May 2025 09:01: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 1uFUT7-0006kM-4m; Thu, 15 May 2025 09:01:33 +0000
Received: by outflank-mailman (input) for mailman id 984970;
 Thu, 15 May 2025 09:01:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFUT6-0006kG-Bu
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:01:32 +0000
Received: from fhigh-a6-smtp.messagingengine.com
 (fhigh-a6-smtp.messagingengine.com [103.168.172.157])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 309f34f2-316b-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 11:01:30 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.phl.internal (Postfix) with ESMTP id ED83C11400DC;
 Thu, 15 May 2025 05:01:28 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Thu, 15 May 2025 05:01:28 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 15 May 2025 05:01:27 -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" 
X-Inumbo-ID: 309f34f2-316b-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1747299688;
	 x=1747386088; bh=b3ahQN5lr3oJ3AfF2prxpnWCbluc8OWnhn+4dKgtlLk=; b=
	WGazDp6KJG2+O5Usk60OKAsQXW5VQAIoXfpcjdwtXrC5twsO4vG+z5zYdwOsQuw9
	CTngWy3kiE/YAU6PF+0MOZ9zgyWJIsn1TzEHz+Lk+5p+K4QO+dvUTZF7pLj29t9G
	GDZkXS6CjjvGSfLgspqcWxY3NPlEXnfl4aQLXcS0lvwvw9pH6x9Nl34pDaTnHY+R
	E5R7kRWiLnYA6893zlhjrBF3KlbPTPHZtq0XGRYxmunSAg68M/2pOu/XJ90gT396
	fsrkQiYXOL+umHj0O20l/3I2xpfcMvdBwGqtukt71VNyk/N7e3RWGn6Qq89AK7nd
	6F7i4fA5PEaIYy9kyfbUSQ==
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=fm3; t=
	1747299688; x=1747386088; bh=b3ahQN5lr3oJ3AfF2prxpnWCbluc8OWnhn+
	4dKgtlLk=; b=OCi1vLgqf7GZMOqBeIFRplqOk8bZ7H3jv1gswlI7geazPJp90zi
	/W5ndMUBTtUwn6Cd0C/2q4aStcct32CjuHr+EKT3ztlCoxT8ts0jy2oc+5cfoQHW
	knjG8C4PZ/Smk5UUSVhUkHWD8FA1CfyR7JQM+XF5/66HbS7KNL3NLPT0v7VPjw0l
	TA/XWpt6xmzrWV5ypkVClxkCChOUeDezezm6wPt8++QyyEwi/A2p8fI2CW6ziDH8
	G2bXyaaiEb7dIhYTBvs/y+BCe5+sj8uTUrI95A/4XP3oJNjKhLThl2KbcCcTtAY3
	azcuA7U9o5PLIC9jnBcqDdfSxT+YN0qeBng==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeftdelgeehucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddt
    jeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuc
    eomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecu
    ggftrfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettd
    dvgeeuteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf
    rhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh
    dpnhgspghrtghpthhtohepkedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprhho
    ghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtohepjhhgrhhoshhssehsuh
    hsvgdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhr
    ohhjvggtthdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrd
    hkvghrnhgvlhdrohhrghdprhgtphhtthhopehjrghsohhnrdgrnhgurhihuhhksegrmhgu
    rdgtohhmpdhrtghpthhtohepjhifsehnuhgtlhgvrghrfhgrlhhlohhuthdrnhgvthdprh
    gtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthho
    peholhgvkhhsrghnughrpghthihshhgthhgvnhhkohesvghprghmrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 15 May 2025 11:01:24 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau Monne 
Cc: Juergen Gross , xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org, jason.andryuk@amd.com,
	John ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko 
Subject: Re: [PATCH] xen/x86: fix initial memory balloon target
Message-ID: 
References: <20250514080427.28129-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="HYAuCMW0ZFMoY7vd"
Content-Disposition: inline
In-Reply-To: <20250514080427.28129-1-roger.pau@citrix.com>


--HYAuCMW0ZFMoY7vd
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 15 May 2025 11:01:24 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau Monne 
Cc: Juergen Gross , xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org, jason.andryuk@amd.com,
	John ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko 
Subject: Re: [PATCH] xen/x86: fix initial memory balloon target

On Wed, May 14, 2025 at 10:04:26AM +0200, Roger Pau Monne wrote:
> When adding extra memory regions as ballooned pages also adjust the ballo=
on
> target, otherwise when the balloon driver is started it will populate
> memory to match the target value and consume all the extra memory regions
> added.
>=20
> This made the usage of the Xen `dom0_mem=3D,max:` command line parameter =
for
> dom0 not work as expected, as the target won't be adjusted and when the
> balloon is started it will populate memory straight to the 'max:' value.
> It would equally affect domUs that have memory !=3D maxmem.
>=20
> Kernels built with CONFIG_XEN_UNPOPULATED_ALLOC are not affected, because
> the extra memory regions are consumed by the unpopulated allocation drive=
r,
> and then balloon_add_regions() becomes a no-op.
>=20
> Reported-by: John 
> Fixes: 87af633689ce ('x86/xen: fix balloon target initialization for PVH =
dom0')
> Signed-off-by: Roger Pau Monn=C3=A9 

Tested-by: Marek Marczykowski-G=C3=B3recki 

> ---
>  drivers/xen/balloon.c | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
>=20
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 8c852807ba1c..2de37dcd7556 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -704,15 +704,18 @@ static int __init balloon_add_regions(void)
> =20
>  		/*
>  		 * Extra regions are accounted for in the physmap, but need
> -		 * decreasing from current_pages to balloon down the initial
> -		 * allocation, because they are already accounted for in
> -		 * total_pages.
> +		 * decreasing from current_pages and target_pages to balloon
> +		 * down the initial allocation, because they are already
> +		 * accounted for in total_pages.
>  		 */
> -		if (extra_pfn_end - start_pfn >=3D balloon_stats.current_pages) {
> +		pages =3D extra_pfn_end - start_pfn;
> +		if (pages >=3D balloon_stats.current_pages ||
> +		    pages >=3D balloon_stats.target_pages) {
>  			WARN(1, "Extra pages underflow current target");
>  			return -ERANGE;
>  		}
> -		balloon_stats.current_pages -=3D extra_pfn_end - start_pfn;
> +		balloon_stats.current_pages -=3D pages;
> +		balloon_stats.target_pages -=3D pages;
>  	}
> =20
>  	return 0;
> --=20
> 2.48.1
>=20
>=20

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--HYAuCMW0ZFMoY7vd
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmglrWQACgkQ24/THMrX
1yzk4gf9HepcWZO18gT+Ey7O+UqEd6psGfUZ6g1aP24bzNDa9nFkSLInQxPcIIZj
s/vVZBJ3lrEfvjRLqWlvAeWVOmeVU2LpkZIE/E19LKMrPtd0Zr+VU4ZohnnqIqvC
prnVJ+WviPbYg4vzrOuOKeGWjaawdotzfDmCTYvDogRClNyg1f8FdnmFmEqNGjo7
yQKThrXzVJTRUJ02SrqVZ4l7iS8fci8hszheWWPR33SYyWIrt7ec2qq1zrp2DjkC
87p7vaLceSmWN2fN9uZ2GCSjx+56Y9ZmKa1UjxzMLE1FNs1y3NBYeX+Vkh4XpRvy
Ubzw36nzSY/HbzBmmHcjaRir5qY91A==
=sqjV
-----END PGP SIGNATURE-----

--HYAuCMW0ZFMoY7vd--


From xen-devel-bounces@lists.xenproject.org Thu May 15 09:07:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:07:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984978.1370925 (Exim 4.92)
	(envelope-from )
	id 1uFUYM-0007KA-RO; Thu, 15 May 2025 09:06:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984978.1370925; Thu, 15 May 2025 09: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 1uFUYM-0007K3-Ns; Thu, 15 May 2025 09:06:58 +0000
Received: by outflank-mailman (input) for mailman id 984978;
 Thu, 15 May 2025 09:06:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFUYL-0007Jx-L7
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:06:57 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f35b9212-316b-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 11:06:56 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5fbfdf7d353so916165a12.0
 for ; Thu, 15 May 2025 02:06: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
 a640c23a62f3a-ad503e3f65esm204338966b.6.2025.05.15.02.06.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 02: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" 
X-Inumbo-ID: f35b9212-316b-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747300016; x=1747904816; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NBx8Oe3ymnLl1c5WuSuXHwGtzlWPF6LmHmV05T4Qiz8=;
        b=Pc7OMihkVenlBQ54RrbGoNQqqhezWWXLQbFRP3IjhkasdS8PD4iWak65X446fTo1F1
         LAHF6o5Iwsghil3FFCDqIaIl81hlevlpRapUvZUnKrcFrWFPQ4eSWrwMPK7EmY5n2X+i
         qTEdrxwzyhNXaR/hHNEzbDT9BED9omogrnpfQnrSnsPWrr/NBE4FUY025BLQjc1Q+Qaa
         eE56mkDgVf1tUcYrj2NfETvJFh6FkLFSwgy/F22PcAhgwutGJMXHmiT7sxgvdjpNOWzk
         AJDQKCCQpp0JobTDP4YXi5xxg6eriDSWYjbXXTbVJa2lslxcBdHuG5eatR8hvOCFJrBY
         9M7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747300016; x=1747904816;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NBx8Oe3ymnLl1c5WuSuXHwGtzlWPF6LmHmV05T4Qiz8=;
        b=XMq9qa3id3MZ+S9dIoqOUKoNo0p2HBbyFjDP0M+kN07juATvJBrsRyTLnCl/2NKUt8
         d0jIvdohcDgP8/T7JkSjDHMLaQRbDm++TCoC/y0CQDvS6YU907NC95o6X2/lS6EIOU8U
         S7D3PbVwN1JlekJiRyqddoW9OGt1KndaMku8/LKBF+2PjK7xyVcXJ+nGNOawMC2vWfRq
         wnN60vUpYT9HzI0V5EHbYXvwhphecKmTIHL7xFegipyWWS/9TQEHowgRGYzfJla52EF1
         52qIlZCoACzQntsaoAzuUfpsafvT83m1Fh725CgYMfj1LbZe5kRa4GP+xRfhvEynIPX0
         MaAQ==
X-Forwarded-Encrypted: i=1; AJvYcCWto0YTq/egla09nyIeGMRlaC8TtKhcwLvd874fGl82pMKT+Wr7lG+5gfY7OeqDrHb1NqUHFBLpQ2o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyzd9Sk+k0N+FxwEgfIrHUFluVeXE2DaudFOSg10Tl68Rg+qvXr
	rya9dX9jPuIBr030Ehok1ARTO5z4aJP+WdNgOyYy+PWrJ19sE/dKNfI1rJKbXg==
X-Gm-Gg: ASbGnctVmkfK//KkBC7ezNJ2pXKJzuzNEip5dmuKFnTiSbDf6SNADRMVPXlAHHv3Ocp
	IabIqr7fidbVlR8718fvUPEN3hdUO28MK3+1jb7T7RkXsOm07YYp9bt0m42iMfS4XLkeZSVDGWM
	8ulRgKSX9JQl2gysXtRM1Amh+eav6uaCwNoy3FmXF2D67EriL5P/4PmJEEE7M1kUvMWZ0084C0h
	IJIpJBZDOtqQjcyArmHbq+a0DFu33bdTE7pmoqyIzV9oG7x/L54m8GwNM4rDr8XHj80UOosE5t2
	7oksA/61vMdPcn1rYVmTctZoPVga90n9D84RKdNUR6Cr4yDcoOfBvPes/m6u05/hKg4BT18fcwm
	gqd2CzmTPk4FxiY7/ZfGErzq4MNspCrFp9FfEdbP4VDnVYiI=
X-Google-Smtp-Source: AGHT+IFB4x3yNW3+PX1J+ptQeYR922si1KC3PKQbdEdL6a6nd3XTr77Yg3QS2j2qyZFEBvLzyHDBBA==
X-Received: by 2002:a17:907:72c7:b0:aca:95e7:9977 with SMTP id a640c23a62f3a-ad4f7150549mr647844666b.28.1747300009560;
        Thu, 15 May 2025 02:06:49 -0700 (PDT)
Message-ID: <057fc2ce-d4d6-4e14-987d-bef6f909eaff@suse.com>
Date: Thu, 15 May 2025 11:06:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 11/16] xen/riscv: aplic_init() implementation
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <9129b10432dfc7ff8ba451842204342171da7dc1.1746530883.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: <9129b10432dfc7ff8ba451842204342171da7dc1.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/aplic-priv.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/aplic.h

If already you have such in a comment, please have it be correct.

> + * Private part of aplic.h header.
> + *
> + * RISC-V Advanced Platform-Level Interrupt Controller support
> + *
> + * Copyright (c) Microchip.
> + * Copyright (c) Vates.
> + */
> +
> +#ifndef ASM__RISCV_PRIV_APLIC_H
> +#define ASM__RISCV_PRIV_APLIC_H
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +struct aplic_priv {
> +    /* base physical address and size */
> +    paddr_t paddr_start;
> +    size_t  size;
> +
> +    /* registers */
> +    volatile struct aplic_regs *regs;

This looks to also want __iomem.

> --- a/xen/arch/riscv/aplic.c
> +++ b/xen/arch/riscv/aplic.c
> @@ -9,19 +9,121 @@
>   * Copyright (c) 2024-2025 Vates
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +
> +#include "aplic-priv.h"

Besides this, are there going to be any other files including this private
header? If not, why have the header in the first place?

>  #include 
> +#include 
>  #include 
> +#include 
> +
> +#define APLIC_DEFAULT_PRIORITY  1
> +
> +static struct aplic_priv aplic;
>  
>  static struct intc_info __ro_after_init aplic_info = {
>      .hw_version = INTC_APLIC,
>  };
>  
> +static void __init aplic_init_hw_interrupts(void)
> +{
> +    unsigned int i;
> +
> +    /* Disable all interrupts */
> +    for ( i = 0; i < ARRAY_SIZE(aplic.regs->clrie); i++)
> +        writel(-1U, &aplic.regs->clrie[i]);

Imo it's better to use ~0U.

> +    /* Set interrupt type and default priority for all interrupts */
> +    for ( i = 1; i <= aplic_info.num_irqs; i++ )
> +    {
> +        writel(0, &aplic.regs->sourcecfg[i - 1]);

What guarantees the loop to not run past the array's size?

> +        /*
> +         * 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.
> +         */
> +        writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i - 1]);
> +    }

Seeing the subtractions of 1 here, why's the loop header not simply

    for ( i = 0; i < aplic_info.num_irqs; i++ )

(i.e. the more conventional form)?

> +    writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg);
> +}
> +
> +static int __init cf_check aplic_init(void)
> +{
> +    int rc;
> +    dt_phandle imsic_phandle;
> +    uint32_t irq_range[num_possible_cpus() * 2];

Are you going to have enough stack space when num_possible_cpus() is pretty
large?

> +    const __be32 *prop;
> +    uint64_t size, paddr;
> +    struct dt_device_node *imsic_node;

Pointer-to-const?

> +    const struct dt_device_node *node = aplic_info.node;
> +
> +    /* Check for associated imsic node */
> +    rc = dt_property_read_u32(node, "msi-parent", &imsic_phandle);
> +    if ( !rc )
> +        panic("%s: IDC mode not supported\n", node->full_name);
> +
> +    imsic_node = dt_find_node_by_phandle(imsic_phandle);
> +    if ( !imsic_node )
> +        panic("%s: unable to find IMSIC node\n", node->full_name);
> +
> +    rc = dt_property_read_u32_array(imsic_node, "interrupts-extended",
> +                                    irq_range, ARRAY_SIZE(irq_range));
> +    if ( rc )
> +        panic("%s: unable to find interrupt-extended in %s node\n",
> +              __func__, imsic_node->full_name);
> +
> +    if ( irq_range[1] == IRQ_M_EXT )

How do you know the array has had 2 or ...

> +        /* Machine mode imsic node, ignore this aplic node */
> +        return 0;
> +
> +    for ( unsigned int i = 0; i < ARRAY_SIZE(irq_range); i += 2 )
> +    {
> +        if ( irq_range[i + 1] != irq_range[1] )
> +            panic("%s: mode[%d] != %d\n", __func__, i + 1, irq_range[1]);
> +    }

... or even all of the slots populated? Anything not populated by the DT
function will still have the stack contents that had been left by earlier
call chains. (The loop also makes little sense to start from 0.)

I'm also puzzled by there not being any further use of the values later
in the function.

> +    rc = imsic_init(imsic_node);
> +    if ( rc )
> +        panic("%s: Failded to initialize IMSIC\n", node->full_name);
> +
> +    /* Find out number of interrupt sources */
> +    rc = dt_property_read_u32(node, "riscv,num-sources", &aplic_info.num_irqs);
> +    if ( !rc )

Assigning a bool return value to an int local var, which generally hold
error codes, is confusing. I don't think you really need to use a local
variable here.

> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/aplic.h
> @@ -0,0 +1,64 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/asm/include/aplic.h
> + *
> + * RISC-V Advanced Platform-Level Interrupt Controller support
> + *
> + * Copyright (c) Microchip.
> + */
> +
> +#ifndef ASM__RISCV__APLIC_H
> +#define ASM__RISCV__APLIC_H
> +
> +#include 
> +
> +#include 
> +
> +#define APLIC_DOMAINCFG_IE      BIT(8, UL)
> +#define APLIC_DOMAINCFG_DM      BIT(2, UL)
> +
> +struct aplic_regs {
> +    uint32_t domaincfg;
> +    uint32_t sourcecfg[1023];
> +    uint8_t _reserved1[0xBC0];
> +
> +    uint32_t mmsiaddrcfg;
> +    uint32_t mmsiaddrcfgh;
> +    uint32_t smsiaddrcfg;
> +    uint32_t smsiaddrcfgh;
> +    uint8_t _reserved2[0x30];
> +
> +    uint32_t setip[32];
> +    uint8_t _reserved3[92];
> +
> +    uint32_t setipnum;
> +    uint8_t _reserved4[0x20];
> +
> +    uint32_t in_clrip[32];
> +    uint8_t _reserved5[92];
> +
> +    uint32_t clripnum;
> +    uint8_t _reserved6[32];
> +
> +    uint32_t setie[32];
> +    uint8_t _reserved7[92];
> +
> +    uint32_t setienum;
> +    uint8_t _reserved8[32];
> +
> +    uint32_t clrie[32];
> +    uint8_t _reserved9[92];
> +
> +    uint32_t clrienum;
> +    uint8_t _reserved10[32];
> +
> +    uint32_t setipnum_le;
> +    uint32_t setipnum_be;
> +    uint8_t _reserved11[4088];

I think you want to be consistent with the dimensions of at least all the
_reserved*[] fields - use decimal or use hex everywhere. Even better would
be if that was consistent across all array dimensions.

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 09:08:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:08:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984989.1370935 (Exim 4.92)
	(envelope-from )
	id 1uFUZQ-0007ss-7B; Thu, 15 May 2025 09:08:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984989.1370935; Thu, 15 May 2025 09: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 1uFUZQ-0007sl-49; Thu, 15 May 2025 09:08:04 +0000
Received: by outflank-mailman (input) for mailman id 984989;
 Thu, 15 May 2025 09:08:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFUZO-0007cX-7L
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:08:02 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 19a78a38-316c-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 11:08:00 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5fbed53b421so1376841a12.0
 for ; Thu, 15 May 2025 02:08: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
 4fb4d7f45d1cf-5ff8c016a16sm3065106a12.2.2025.05.15.02.07.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 02:07: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" 
X-Inumbo-ID: 19a78a38-316c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747300080; x=1747904880; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Co3mP4MRmKEmiQSsN6o3xAsOnisHaBVo9FVhf728+hM=;
        b=azE8KtA9QKUC0m4oJ6Rib1jNshyQaEDBuqe59uj+Rj1172ZJtE3qnxWWwHj2I0ah2Q
         zc89CXtXspAwpPIaVsD/3fQb4WJdM217waGgu+xHficui3sKsMRkZCj7BWncVoCUzF7R
         5EzYyr5WOCxucB9qiwReRAywW5SikoEPi6Q6cRIPfAHp5ydQJ2rpORGqwDloZC5jNH9b
         hw0NanmTiw080MApHYP1LqtSqHQBWhYQi1J77EyT/mpOVUnDtrh98ft8RFwYrtwOsmaD
         HAMa511VB0VIeOi4sd10Bj+6KpRktQYBVNuFqDmb42RQqlLKiEu2xRpg5m6kOLKaZrwN
         QMbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747300080; x=1747904880;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Co3mP4MRmKEmiQSsN6o3xAsOnisHaBVo9FVhf728+hM=;
        b=bcViCATDR9KneLG4pDm/Y2QPnZAgMoWvJmWP8shXHOsugn2QvVfRd823AP2GGvTQIU
         9OV/IB2+RBCSAikNClprv3bN5D/MqRh6EoRds81v7cTMG4c9v/CeH7Xc1xg2wYMwSY3D
         gEhu1Ha3Q/uAQ/L5mR9IXJi+DkmYa+5+lk+QQuAeOLhndEFYjOaA8a8692tQpSzXgdAQ
         JashCUs9Npu3u/MCUSPKFXDWffWZNX6Cs4fCoVsr0SV/FjIm6Fd3vEE2BJXaE/V3lhbn
         dKWuExCbZiiC1KujVqtuG58JjVjpWB3fZdyljSumAswxkY6iULdJqMU4eDBgdpw7Uqc+
         HlVA==
X-Gm-Message-State: AOJu0Yxn0kwhqm8Hjy22YdzJLF+dqGvatqWCBnnLFGQL8Hw5yGpL3OV0
	3gxizBdebmduHsQwUqGU6Lu8X/oGWGun+fPejVV2/U2Izo1JNKiJLLjnX/5vww==
X-Gm-Gg: ASbGncu/qSkqVspF0P/mxWl7vsHGhaS7AA7tOvfRg3CJyCrI53LcTs0VQY/Db+XN4QI
	fVh3xYLpwbKBVsVmE9qCFYEaPKWIiZigitLNR3xa4kIZqdIoVKuXFBxgDuVtahxWp6XppkKLg2B
	8U57HSl5mPghl9aBlYfuI4ZGJ4QpPSW1LzlJhhpq7EcZ3gigv/Du2VQi41yc6o6vf8M6D/QdzM8
	HUULS+O90tuT0pDVLvtdp7bhB3cu1zhJ4EKfvGbejHBRS4xvFGDOTaTbj13mEDIYjjZFIUzQa2n
	1BlHi9Ap84SPi6IuYZEiDRfXCfe61RVx/PobM6QLM5CSypV7Rf6kvbLoxWelSxcspQ3OWpGjsvq
	uAXGuoABwWjmSXu2Dws9CMWMoEbJMaLds0X0YYrtS/NeFnWI=
X-Google-Smtp-Source: AGHT+IEirQ+6HDHZKRfQjrQ8v6wygF3uRg2cqPJOKhUK0wqt/pqjJYpNz5nH/Tqs7lLKNJXL6sCkOg==
X-Received: by 2002:a05:6402:27d0:b0:5ec:da2e:6f4d with SMTP id 4fb4d7f45d1cf-5ff988b0e6emr5200531a12.18.1747300080006;
        Thu, 15 May 2025 02:08:00 -0700 (PDT)
Message-ID: <52da0231-3f0d-4470-838c-84705787249c@suse.com>
Date: Thu, 15 May 2025 11:07:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/iommu: use rangeset_subtract() in
 arch_iommu_hwdom_init()
To: Roger Pau Monne 
References: <20250515085746.43498-1-roger.pau@citrix.com>
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20250515085746.43498-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 15.05.2025 10:57, Roger Pau Monne wrote:
> Remove an open-coded instance of rangeset_subtract().  No functional change
> intended.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu May 15 09:13:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:13:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.984997.1370945 (Exim 4.92)
	(envelope-from )
	id 1uFUey-0001E5-Q5; Thu, 15 May 2025 09:13:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 984997.1370945; Thu, 15 May 2025 09:13: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 1uFUey-0001Dy-NM; Thu, 15 May 2025 09:13:48 +0000
Received: by outflank-mailman (input) for mailman id 984997;
 Thu, 15 May 2025 09:13:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFUew-0001Ds-LB
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:13:46 +0000
Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com
 [2607:f8b0:4864:20::c2e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e46c1d31-316c-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 11:13:41 +0200 (CEST)
Received: by mail-oo1-xc2e.google.com with SMTP id
 006d021491bc7-609e7f3caf3so520356eaf.1
 for ; Thu, 15 May 2025 02:13:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e46c1d31-316c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747300420; x=1747905220; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QC33JsX1S+wWQYg3/7wllIJJHQiR6cDdGbMyi83Riok=;
        b=WZ7fVx11z6RW8WuhjbRj9Hlxik6kHwAZ37sfE3icQ0d96RbBc8fQyjaMsdP6qUwfxy
         8U9ZbOuFDphv0CSfUnZ8c85q2/hP65NLKL+6v8U8p5bjrNl8uYAFcwF1H9eRkj+Hqw2v
         BjSNosT3shps/uIo2/Oqe+bWTNQIqu4PWhYEs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747300420; x=1747905220;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=QC33JsX1S+wWQYg3/7wllIJJHQiR6cDdGbMyi83Riok=;
        b=EqHy7utP6p/9T4Ffh+ZMv5DCTW9Skf+yHwV1Iy+XwHwxjJu57x9Tq3PvsmMG6N5AX1
         mEcDTJ2TyLeEsJFeNUzA9RAt6DBKSVNjbcwPQNImkNIYnjZd12cc0osY3cKZiHTX50Mj
         KwsUipsKrbrZLdXMSjqv4Cf4R5VjLLvq3vEyAss6FWEE7zOiSOlLCckq7+ZX7YPakCe0
         SI2UbUmwdKodH7OrnKl8B81Ojij5Ia2ehnlR6qggCyiWYXHP6HPzmbnasjvIVSRW88Vm
         pmBP3VL/R46jHin2eZTJCm9OjwGRaKI4w6pOvfroHkqMP2oWaFEgZa0c+KdcF5l6FlrV
         T3hA==
X-Forwarded-Encrypted: i=1; AJvYcCVK0KLEUQ7Bhku9SitXMJNzgwnJ+qTTo8kwhNzIRVDmYwIKQwnqEPBT1MNulbViqOV9KunAiGaI1y4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw56ebjXuWXJ1iaGMSwTaTAgJO99IlNs7Q5kGWYP+9JAxR7JXhI
	Isxi8TTLQbUfIGtzl23IQHifLXbGEwVc5xM25Rkbj46GYnvPta4bFPzlNrZJE7eEoXgn1DDx5T6
	jGh1aKigrFx1co4pXqzOhJwb/Crqivgn1luU5
X-Gm-Gg: ASbGncvBchiOAHL/QcXiakl2GVqut7BZOhU7bChbIMtzGdAGX2LOUAllRUxdsII9hRX
	8ONz5DE9366IOmQpGQdNRuszJgC2KAoYiFQybYUJHq/yzbSBP4/fQhQx4wjfXpyse7Eyvsurjfa
	RA1+P5keDcDpfHbhTeaeGe4ZXnIMDQf5Q=
X-Google-Smtp-Source: AGHT+IEPDqaJkWHnd9s0CiA/JU6Wqro0JC3BzQfIR/OyUh8VnYcmZ1nhWjRH5zEIpTxNNcTTFVPNoAiS1OLBNbEC2h0=
X-Received: by 2002:a05:6820:3094:b0:609:dc81:684 with SMTP id
 006d021491bc7-609df23f684mr3400918eaf.4.1747300419940; Thu, 15 May 2025
 02:13:39 -0700 (PDT)
MIME-Version: 1.0
References: <20250506143218.1782603-1-ross.lagerwall@citrix.com>
 <20250506143218.1782603-3-ross.lagerwall@citrix.com> 
In-Reply-To: 
From: Ross Lagerwall 
Date: Thu, 15 May 2025 10:13:28 +0100
X-Gm-Features: AX0GCFvmaX7qmwe5eQBuNmbwKwV364TpxSB-eiuXMmkmdlcIOqRRraXSn4zt0HY
Message-ID: 
Subject: Re: [PATCH 2/4] crypto: Add RSA support
To: Jan Beulich 
Cc: Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 12, 2025 at 1:38=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 06.05.2025 16:32, Ross Lagerwall wrote:
> > In preparation for adding support for livepatch signing, add support fo=
r
> > RSA crypto.
>
> If this is needed just for live-patch, ...
>
> > --- a/xen/common/Makefile
> > +++ b/xen/common/Makefile
> > @@ -28,6 +28,7 @@ obj-$(CONFIG_LIVEPATCH) +=3D livepatch.o livepatch_el=
f.o
> >  obj-$(CONFIG_LLC_COLORING) +=3D llc-coloring.o
> >  obj-$(CONFIG_VM_EVENT) +=3D mem_access.o
> >  obj-y +=3D memory.o
> > +obj-y +=3D mpi.o
>
> ... why would this be obj-y? Same for rsa.o further down.
>
> > --- /dev/null
> > +++ b/xen/common/mpi.c
> > @@ -0,0 +1,1724 @@
> > +/* mpi-pow.c  -  MPI functions
>
> Nit: This doesn't match the filename.
>
> > + *   Copyright (C) 1994, 1996, 1998, 2000 Free Software Foundation, In=
c.
> > + *
> > + * This file is part of GnuPG.
> > + *
> > + * GnuPG is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published b=
y
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * GnuPG is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-130=
7, USA
> > + *
> > + * Note: This code is heavily based on the GNU MP Library.
> > + *    Actually it's the same code with only minor changes in the
> > + *    way the data is stored; this is to support the abstraction
> > + *    of an optional secure memory allocation which may be used
> > + *    to avoid revealing of sensitive data due to paging etc.
> > + *    The GNU MP Library itself is published under the LGPL;
> > + *    however I decided to publish this code under the plain GPL.
> > + *
> > + * mpi.c code extracted from linux @ eef0df6a5953, lib/mpi
>
> I fear this line would go unnoticed with future changes, and hence go sta=
le
> rather easily. Menioning the origin in just the commit message ought to b=
e
> sufficient.
>
> Btw - how heavily did you need to adjust the code to pass our Eclair scan=
?
> Depending on that I then might raise the question of converting to proper
> Xen style (it currently isn't even proper Linux style, afaict).

Few changes were needed to the code in this file so I preferred to keep
it in the original style.

Since a lot more adjustments were made to rsa.c, I opted to change that
to the Xen style.

>
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>
> Please sort alphabetically. Same for the other new files.
>
> > +#define MAX_EXTERN_MPI_BITS 16384
> > +
> > +/* Define it to a value which is good on most machines.
> > + * tested 4, 16, 32 and 64, where 16 gave the best performance when
> > + * checking a 768 and a 1024 bit ElGamal signature.
> > + * (wk 22.12.97) */
> > +#define KARATSUBA_THRESHOLD 16
> > +
> > +typedef mpi_limb_t *mpi_ptr_t;       /* pointer to a limb */
> > +typedef int mpi_size_t;              /* (must be a signed type) */
> > +
> > +/* Copy N limbs from S to D.  */
> > +#define MPN_COPY(d, s, n) \
> > +     do {                                    \
> > +             mpi_size_t _i;                  \
>
> With this and ...
>
> > +             for (_i =3D 0; _i < (n); _i++)    \
> > +                     (d)[_i] =3D (s)[_i];      \
> > +     } while (0)
> > +
> > +#define MPN_COPY_DECR(d, s, n) \
> > +     do {                                    \
> > +             mpi_size_t _i;                  \
>
> ... this I wonder why ...
>
> > +             for (_i =3D (n)-1; _i >=3D 0; _i--) \
> > +                     (d)[_i] =3D (s)[_i];      \
> > +     } while (0)
> > +
> > +/* Zero N limbs at D */
> > +#define MPN_ZERO(d, n) \
> > +     do {                                    \
> > +             int  _i;                        \
>
> ... this is plain int. There are apparently many similar issue.
>
> >[...]
> > +leave:
>
> Here and elsewhere - labels indented by at least one blank, please.
>
> > --- /dev/null
> > +++ b/xen/crypto/rsa.c
> > @@ -0,0 +1,194 @@
> > +/* rsa.c
> > +
> > +   The RSA publickey algorithm.
> > +
> > +   Copyright (C) 2001 Niels M=C3=B6ller
> > +
> > +   This file is part of GNU Nettle.
> > +
> > +   GNU Nettle is free software: you can redistribute it and/or
> > +   modify it under the terms of either:
> > +
> > +     * the GNU Lesser General Public License as published by the Free
> > +       Software Foundation; either version 3 of the License, or (at yo=
ur
> > +       option) any later version.
> > +
> > +   or
> > +
> > +     * the GNU General Public License as published by the Free
> > +       Software Foundation; either version 2 of the License, or (at yo=
ur
> > +       option) any later version.
> > +
> > +   or both in parallel, as here.
> > +
> > +   GNU Nettle is distributed in the hope that it will be useful,
> > +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > +   General Public License for more details.
> > +
> > +   You should have received copies of the GNU General Public License a=
nd
> > +   the GNU Lesser General Public License along with this program.  If
> > +   not, see http://www.gnu.org/licenses/.
> > +*/
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +void rsa_public_key_init(struct rsa_public_key *key)
> > +{
> > +    key->n =3D NULL;
> > +    key->e =3D NULL;
> > +    key->size =3D 0;
> > +}
> > +
> > +/*
> > + * Computes the size, in octets, of the modulo. Returns 0 if the
> > + * modulo is too small to be useful, or otherwise appears invalid.
> > + */
> > +static size_t rsa_check_size(MPI n)
> > +{
> > +    /* Round upwards */
> > +    size_t size;
> > +
> > +    /* Even moduli are invalid */
> > +    if ( mpi_test_bit(n, 0) =3D=3D 0 )
> > +        return 0;
> > +
> > +    size =3D (mpi_get_nbits(n) + 7) / 8;
> > +
> > +    if ( size < RSA_MINIMUM_N_OCTETS )
> > +        return 0;
> > +
> > +    return size;
> > +}
> > +
> > +int rsa_public_key_prepare(struct rsa_public_key *key)
> > +{
> > +    if ( !key->n || !key->e || key->size )
> > +        return -EINVAL;
> > +
> > +    key->size =3D rsa_check_size(key->n);
> > +
> > +    return key->size > 0 ? 0 : -EINVAL;
> > +}
> > +
> > +/*
> > + * Formats the PKCS#1 padding, of the form
> > + *
> > + *   0x00 0x01 0xff ... 0xff 0x00 id ...digest...
> > + *
> > + * where the 0xff ... 0xff part consists of at least 8 octets. The
> > + * total size equals the octet size of n.
> > + */
> > +static uint8_t *pkcs1_signature_prefix(unsigned int key_size, uint8_t =
*buffer,
> > +                                       unsigned int id_size, const uin=
t8_t *id,
> > +                                       unsigned int digest_size)
> > +{
> > +    unsigned int j;
> > +
> > +    if ( key_size < 11 + id_size + digest_size )
> > +        return NULL;
> > +
> > +    j =3D key_size - digest_size - id_size;
> > +
> > +    memcpy(buffer + j, id, id_size);
> > +    buffer[0] =3D 0;
> > +    buffer[1] =3D 1;
> > +    buffer[j - 1] =3D 0;
> > +
> > +    ASSERT(j >=3D 11);
> > +    memset(buffer + 2, 0xff, j - 3);
> > +
> > +    return buffer + j + id_size;
> > +}
> > +
> > +/*
> > + * From RFC 3447, Public-Key Cryptography Standards (PKCS) #1: RSA
> > + * Cryptography Specifications Version 2.1.
> > + *
> > + *     id-sha256    OBJECT IDENTIFIER ::=3D
> > + *       {joint-iso-itu-t(2) country(16) us(840) organization(1)
> > + *         gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1}
> > + */
> > +static const uint8_t
> > +sha256_prefix[] =3D
> > +{
> > +  /* 19 octets prefix, 32 octets hash, total 51 */
> > +  0x30,      49, /* SEQUENCE */
> > +    0x30,    13, /* SEQUENCE */
> > +      0x06,   9, /* OBJECT IDENTIFIER */
> > +        0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01,
> > +      0x05,   0, /* NULL */
> > +    0x04,    32  /* OCTET STRING */
> > +      /* Here comes the raw hash value */
> > +};
> > +
> > +static int pkcs1_rsa_sha256_encode(MPI *m, size_t key_size,
> > +                                   struct sha2_256_state *hash)
> > +{
> > +    uint8_t *ptr;
> > +    uint8_t *buf;
> > +
> > +    buf =3D xmalloc_bytes(key_size);
> > +    if ( !buf )
> > +        return -ENOMEM;
> > +
> > +    ptr =3D pkcs1_signature_prefix(key_size, buf,
> > +                                 sizeof(sha256_prefix), sha256_prefix,
> > +                                 SHA2_256_DIGEST_SIZE);
> > +    if ( !ptr )
> > +    {
> > +        xfree(buf);
> > +        return -EINVAL;
> > +    }
> > +
> > +    sha2_256_final(hash, ptr);
> > +    *m =3D mpi_read_raw_data(buf, key_size);
> > +    xfree(buf);
> > +    return 0;
> > +}
> > +
> > +static int rsa_verify(const struct rsa_public_key *key, MPI m, MPI s)
> > +{
> > +    int ret;
> > +    MPI m1;
> > +
> > +    /* (1) Validate 0 <=3D s < n */
> > +    if ( mpi_cmp_ui(s, 0) < 0 || mpi_cmp(s, key->n) >=3D 0 )
> > +        return -EINVAL;
> > +
> > +    m1 =3D mpi_alloc(key->size / BYTES_PER_MPI_LIMB);
> > +    if ( !m1 )
> > +        return -ENOMEM;
> > +
> > +    /* (2) m =3D s^e mod n */
> > +    ret =3D mpi_powm(m1, s, key->e, key->n);
> > +    if ( ret )
> > +        goto out;
> > +
> > +    ret =3D mpi_cmp (m, m1) ? -EINVAL : 0;
>
> You look to have striven to convert this file to Xen style; there's a str=
ay
> blank here, though.
>
> > --- /dev/null
> > +++ b/xen/include/xen/mpi.h
> > @@ -0,0 +1,63 @@
> > +/* mpi.h  -  Multi Precision Integers
> > + *        Copyright (C) 1994, 1996, 1998, 1999,
> > + *                    2000, 2001 Free Software Foundation, Inc.
> > + *
> > + * This file is part of GNUPG.
> > + *
> > + * GNUPG is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published b=
y
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
>
> While this may want to remain, accompany it with an SPDX header? (Same
> elsewhere perhaps.)

Sure.

>
> > + * GNUPG is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-130=
7, USA
> > + *
> > + * Note: This code is heavily based on the GNU MP Library.
> > + *         Actually it's the same code with only minor changes in the
> > + *         way the data is stored; this is to support the abstraction
> > + *         of an optional secure memory allocation which may be used
> > + *         to avoid revealing of sensitive data due to paging etc.
> > + *         The GNU MP Library itself is published under the LGPL;
> > + *         however I decided to publish this code under the plain GPL.
> > + */
> > +
> > +#ifndef MPI_H
> > +#define MPI_H
>
> This imo wants at least a XEN_ prefix. Same in rsa.h.
>
> > +#include 
> > +
> > +#define BYTES_PER_MPI_LIMB      (BITS_PER_LONG / 8)
> > +#define BITS_PER_MPI_LIMB       BITS_PER_LONG
> > +
> > +typedef unsigned long int mpi_limb_t;
> > +typedef signed long int mpi_limb_signed_t;
> > +
> > +struct mpi {
> > +    int alloced;        /* array size (# of allocated limbs) */
> > +    int nlimbs;         /* number of valid limbs */
> > +    int nbits;          /* the real number of valid bits (info only) *=
/
>
> I understand the goal likely is to not meaningfully change the original, =
but
> none of these look like they can hold negative values, and ...
>
> > +    int sign;           /* indicates a negative number */
>
> ... this one looks like it's a boolean.
>
> > +    unsigned flags;     /* bit 0: array must be allocated in secure me=
mory space */
>
> In Xen we use "unsigned int", not plain "unsigned".

I'd prefer not to change the type from int to something else but I'll
fix the unsigned style issue.

Ross


From xen-devel-bounces@lists.xenproject.org Thu May 15 09:25:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:25:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985025.1370955 (Exim 4.92)
	(envelope-from )
	id 1uFUq3-00034Y-Og; Thu, 15 May 2025 09:25:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985025.1370955; Thu, 15 May 2025 09:25: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 1uFUq3-00034R-Lh; Thu, 15 May 2025 09:25:15 +0000
Received: by outflank-mailman (input) for mailman id 985025;
 Thu, 15 May 2025 09:25:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFUq2-000343-Eb
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:25:14 +0000
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com
 [2a00:1450:4864:20::22e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 80e19074-316e-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 11:25:12 +0200 (CEST)
Received: by mail-lj1-x22e.google.com with SMTP id
 38308e7fff4ca-326c1795b8bso21019061fa.1
 for ; Thu, 15 May 2025 02:25: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
 a640c23a62f3a-ad517293728sm78312766b.22.2025.05.15.02.25.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 02:25:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 80e19074-316e-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747301112; x=1747905912; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=ODTUbsP+3x4qGj8EevNb80Ywf/WIQ/JGQbYi03Bq3Po=;
        b=LkBckQUoupdjsLFKuNuPrUF7t12pKeOhUoXdeh7TfbiO7QaV0sBzVkentJ/fK2k/Fv
         H57qZ4JLNM3MMRSTqMVaDAIZ9jb/fAqIXAoVzV2lQ6cP/CEvxeKueDuo7LFFLyn9koXv
         ypIxb+91SuOyGk8C+MsnV7nXGciCkkpIX6J0QmRzlQ/tTOn7cMBG6+NdtawvsJt668iV
         hsUV98YuMmde7yt0vdcjTX2fTyUfmD9FdOYSahE6k/YuAQbmJRMFFVlNaFO8phPVoWg5
         /09DrsQnrsF2fwIKgzyBUnszrDOnybZ0ah5qeVlXY+HoG5wkbUyt2mOnqZ3vIIoub5g+
         VCpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747301112; x=1747905912;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ODTUbsP+3x4qGj8EevNb80Ywf/WIQ/JGQbYi03Bq3Po=;
        b=RmBiMqTIZvJ1MAGUFtNVzBxJjX8UJcWLU7JDyTdrBEfGAw5+YglScHO5iyEqWvo8FA
         F0IQVjRjX3nuHEdZwqyFRb57UBMUOfqJxHrNZs2Z6QbfvYH8uflPFcFcBkNGOZZg7cOe
         Y625UQv5KySBZhFgM/IG5FO/QDf8hsVB2U9lKjVev0Re1KOyMr7h96aWKYp18rj2B5P5
         Wde0/n9w05/1jW2j8pVfZhWdIvBJPKpln6mKca9jw8l9+nYl/Pnf2uBpOicM2sZjIHjL
         v8wfdtQUrvFTMP2D7HQRRdx+iL1af8yyotivjEG2XRqWjk1KqWyokvFhHa5jcOGHf7pK
         AbKA==
X-Forwarded-Encrypted: i=1; AJvYcCXhB34MCpoE64aoAEI+izlCyXLuYGfuqS80jl/MTl7tSXxYscgWqtisdIZQF4hVbsP4CMx0ymwtOEQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyEV9/EpuUr7WJmoRaou72YKyXvahHStt0qzdLUN7ySEtEafO/w
	vSSbdfg7m7IuaMpF0WfYZrncvKB6OWqUd+I+FjCbwyr+LymSLZPePLw3aaJ9/nF4KTZa72LxzDo
	=
X-Gm-Gg: ASbGncuvIe+smigP5BNtw0crQSrrdmXB9ADZcX43L2Nu7znzQVkYJo3fKp9aRfxe+c1
	+KSnwemk7bIVarhW8JOqR0uJq9HinvJUoeI33g3hapXvgVJonfXAVmz0tpITs35jQoPwaGhMkfn
	+rpqQ3J4SHXjfKA5NmXG8cOaUJ27WnvY+mNvpEDOA9APnXf280cfEg1XQFJ9tN1NjxtloJT0nEr
	d/jmvhDcI9hXb8uJPeC9afkNA0dEVlqT9/aaSVHCgn1f9rJtbFegyRJ4DSRWdXUXKPc953Irtof
	BBY+h0bIXH1lptiboFaEcAH0ItjRYp1KC0J8r/OHxocvSdudGHJUdXHYAKTmoA0VQogyFmMtZCZ
	AWueXbUB1VICEcfDixkU//nMpiio+wJZiIZ46
X-Google-Smtp-Source: AGHT+IG/31xuYP0PLknjHs8fa/H/gacwymnVUO6M45OZmLBiqCW3otCn+zp64Eirc2ZHifc45WZBoQ==
X-Received: by 2002:a17:907:3f92:b0:aca:c699:8d3c with SMTP id a640c23a62f3a-ad50f613040mr279788566b.2.1747301101222;
        Thu, 15 May 2025 02:25:01 -0700 (PDT)
Message-ID: <8b0fa959-6d00-4bfb-bef0-b3d1ae7ce7e0@suse.com>
Date: Thu, 15 May 2025 11:24:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vpci: fix handling of BAR overlaps with non-hole
 regions
To: Roger Pau Monne 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20250515084123.43289-1-roger.pau@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: <20250515084123.43289-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.05.2025 10:41, Roger Pau Monne wrote:
> For once the message printed when a BAR overlaps with a non-hole regions is
> not accurate on x86.  While the BAR won't be mapped by the vPCI logic, it
> is quite likely overlapping with a reserved region in the memory map, and
> already mapped as by default all reserved regions are identity mapped in
> the p2m.  Fix the message so it just warns about the overlap, without
> mentioning that the BAR won't be mapped, as this has caused confusion in
> the past.
> 
> Secondly, when an overlap is detected the BAR 'enabled' field is not set,
> hence other vPCI code that depends on it like vPCI MSI-X handling won't
> function properly, as it sees the BAR as disabled, even when memory
> decoding is enabled for the device and the BAR is likely mapped in the
> p2m.  Change the handling of BARs that overlap non-hole regions to instead
> remove any overlapped regions from the rangeset, so the resulting ranges to
> map just contain the hole regions.  This requires introducing a new
> pci_sanitize_bar_memory() that's implemented per-arch and sanitizes the
> address range to add to the p2m.
> 
> For x86 pci_sanitize_bar_memory() removes any regions present in the host
> memory map, for ARM this is currently left as a dummy handler to not change
> existing behavior.
> 
> Ultimately the above changes should fix the vPCI MSI-X handlers not working
> correctly when the BAR that contains the MSI-X table overlaps with a
> non-hole region, as then the 'enabled' BAR bit won't be set and the MSI-X
> traps won't handle accesses as expected.

While all of this reads plausible, I may need to look at this again later,
to hopefully grok the connections and implications.

> --- a/xen/arch/x86/include/asm/pci.h
> +++ b/xen/arch/x86/include/asm/pci.h
> @@ -2,6 +2,7 @@
>  #define __X86_PCI_H__
>  
>  #include 
> +#include 

Please don't, ...

> @@ -57,14 +58,7 @@ static always_inline bool is_pci_passthrough_enabled(void)
>  
>  void arch_pci_init_pdev(struct pci_dev *pdev);
>  
> -static inline bool pci_check_bar(const struct pci_dev *pdev,
> -                                 mfn_t start, mfn_t end)
> -{
> -    /*
> -     * Check if BAR is not overlapping with any memory region defined
> -     * in the memory map.
> -     */
> -    return is_memory_hole(start, end);
> -}
> +bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
> +int pci_sanitize_bar_memory(struct rangeset *r);

... all you need is a struct forward decl here.

> --- a/xen/arch/x86/pci.c
> +++ b/xen/arch/x86/pci.c
> @@ -98,3 +98,53 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
>  
>      return rc;
>  }
> +
> +bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
> +{
> +    /*
> +     * Check if BAR is not overlapping with any memory region defined
> +     * in the memory map.
> +     */
> +    if ( !is_memory_hole(start, end) )
> +        gdprintk(XENLOG_WARNING,
> +                 "%pp: BAR at [%"PRI_mfn", %"PRI_mfn"] not in memory map hole\n",
> +                 &pdev->sbdf, mfn_x(start), mfn_x(end));
> +
> +    /*
> +     * Unconditionally return true, pci_sanitize_bar_memory() will remove any
> +     * non-hole regions.
> +     */
> +    return true;
> +}
> +
> +/* Remove overlaps with any ranges defined in the host memory map. */
> +int pci_sanitize_bar_memory(struct rangeset *r)
> +{
> +    unsigned int i;
> +
> +    for ( i = 0; i < e820.nr_map; i++ )
> +    {
> +        const struct e820entry *entry = &e820.map[i];
> +        int rc;
> +
> +        if ( !entry->size )
> +            continue;
> +
> +        rc = rangeset_remove_range(r, PFN_DOWN(entry->addr),
> +                                   PFN_UP(entry->addr + entry->size - 1));
> +        if ( rc )
> +            return rc;

Perhaps better continue the loop in a best effort manner, only accumulating
the error to then ...

> +    }
> +
> +    return 0;
> +}

... return here?

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 09:29:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:29:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985039.1370964 (Exim 4.92)
	(envelope-from )
	id 1uFUuR-0003hw-DA; Thu, 15 May 2025 09:29:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985039.1370964; Thu, 15 May 2025 09:29: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 1uFUuR-0003hp-AZ; Thu, 15 May 2025 09:29:47 +0000
Received: by outflank-mailman (input) for mailman id 985039;
 Thu, 15 May 2025 09:29:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFUuQ-0003hj-1w
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:29:46 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 230dd234-316f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 11:29:45 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5fc7edf00b2so1137678a12.2
 for ; Thu, 15 May 2025 02:29: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
 4fb4d7f45d1cf-5fd20468681sm6949032a12.72.2025.05.15.02.29.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 02:29: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" 
X-Inumbo-ID: 230dd234-316f-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747301384; x=1747906184; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=w0fEFJI2iPu7OcostgjGGnqne2GJ06gyFujB+O+5/yI=;
        b=d20V5bidGyFVRNWtFjqZBL5rO2M2Oyi3SYYoHsl615N3M3lU6BKm4eQf5CGjTQZJPz
         YmPEYth2XuBnU1yz6TK5ZnVyuPqqkY8f3msBN1qe5iUVSsW8qq6FuXMAvKZtC8rH6nAF
         DKmSu58G7RC7MGnM8jPS5hqaXc5HSA56rXWCgW46NcVBLGbEjaT1lgcuazBSotdpipMF
         AJ5NkSEpPOXPe/HBwh1EtxPKyx/rxrT3TEmT5bEdcJ/efRU0h9fgJsUm1nmF9DAIFDve
         R6g1VDKMWnfHAmUVuOvgrmrhJK+nJZ20Au3z9QMP39ESz9ngE3oXnFdwegEjnOYj3p/h
         RNXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747301384; x=1747906184;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=w0fEFJI2iPu7OcostgjGGnqne2GJ06gyFujB+O+5/yI=;
        b=B2Tx8VfHtRSgkjPDvNAJrBRKp1aqjOfB5WXie6kjAAEl6M/PifBB8NN+ReOU0Wqjd/
         OrpiA0VArdgae1bNNQpxpr7E9r7X9sEVSnUk2mvFdIaGBICrJUmXqTc/hSqCKUw81gy3
         n3qG7wc3pog0SIWXBA18DBJ4q3UOcUCY4RHis75xMPwAPef+Pda2UOKOcYiHUigML9h0
         0/j+/YHt17pjtELbr4w+Owg2OC9AeW3V2CANZRpOspVmTHyEX1sfKLlMBQrTGPKONqsM
         UrBkSGFE/EWfGcsBNxNVGa0iEJHuyM03RNUXQ0AJATKoomkcAFqKtjvOXLw6EaPE6VE2
         I0sA==
X-Forwarded-Encrypted: i=1; AJvYcCX8Jm3LuelNpJmUMeVLIJJFXZ4b4Myt+w/eS4KOue1lEa1nAxRYHMQxLLYChS5B4bkk6fLs+F/QPBI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyey5z/QI1feKpLb9FHCNCPw0NyGaoiWnoFEM32jjo2mL3yjg+6
	KknOxNfvPapRzxTYYPCKh+bZIQKznGkFWUTRpRhbU8VmsNtLLRL5pL+vwJlwOA==
X-Gm-Gg: ASbGnct0gHFdh/VJwN1Fs4LWeuZEIwKyWLto5ULWcheepdZm46V82IdcVQHecyRHIKE
	5zi8OvC1vYnBu2T/OIPUbTHTipKzdwlYuSr2GBrT0wjyWDGnCu5TTRvKpBP++V1CgMFD0CvPCvt
	bjdmL1OdLDYiT2nC8bFWeqir3uS/yE1GsqtdPLjAj8dz6eEPxbLIoy35SFy9KLdb2lBWtjS9ddj
	n6D78N7LddzehJ+1q2fGK1FgQYjynhq48QuGYf8KsyxvZOB7lfyRMXZ3rRQK66iDjB81tV7wc8h
	lth63KTs7D+GZdzgTLamAp7XY3ElFB8v+lSRAilJqAK4z5bHUa/VsGyh5bZBUo6IZejEfXrZkOt
	38vvoR5dPjrPKgjuv2UIdZOjuvWT3GPmTnwcG
X-Google-Smtp-Source: AGHT+IH4wZXXZhQ0rneHsIMCpKJSrTeJph8jVsntOfPNb1rRahc3PkxNznxpKEwxDCc3gEhoZz336A==
X-Received: by 2002:a05:6402:1e94:b0:5f4:9017:c6a1 with SMTP id 4fb4d7f45d1cf-5ffd065a7a0mr1412682a12.25.1747301384254;
        Thu, 15 May 2025 02:29:44 -0700 (PDT)
Message-ID: <6883f364-fc29-4c43-897d-c24207b64b26@suse.com>
Date: Thu, 15 May 2025 11:29:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 12/16] xen/riscv: introduce intc_init() and helpers
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <13ce98ce580b6d1a38dcdcd711a6bcf92f4eb0cd.1746530883.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: <13ce98ce580b6d1a38dcdcd711a6bcf92f4eb0cd.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> Introduce intc_init() to initialize the interrupt controller using the
> registered hardware ops.
> Also add intc_route_irq_to_xen() to route IRQs to Xen, with support for
> setting IRQ type and priority via new internal helpers intc_set_irq_type()
> and intc_set_irq_priority().
> 
> Call intc_init() to do basic initialization steps for APLIC and IMSIC.
> 
> Co-developed-by: Romain Caritey 
> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in V2:
>  - This patch was part of "xen/riscv: Introduce intc_hw_operations abstraction"
>    and splitted to have ability to merge patch "xen/riscv: initialize interrupt
>    controller" to the current patch (where intc_init() call is actually
>    introduced).
>  - Add checks of that callbacks aren't set to NULL in intc_set_irq_priority()
>    and intc_set_irq_type().
>  - add num_irqs member to struct intc_info as it is used now in
>    intc_route_irq_to_xen().
>  - Add ASSERT(spin_is_locked(&desc->lock)) to intc_set_irq_priority() in
>    the case this function will be called outside intc_route_irq_to_xen().
> ---
>  xen/arch/riscv/include/asm/intc.h |  4 +++
>  xen/arch/riscv/intc.c             | 45 +++++++++++++++++++++++++++++++
>  xen/arch/riscv/setup.c            |  2 ++
>  3 files changed, 51 insertions(+)
> 
> diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
> index 2d55d74a2e..45a41147a6 100644
> --- a/xen/arch/riscv/include/asm/intc.h
> +++ b/xen/arch/riscv/include/asm/intc.h
> @@ -44,4 +44,8 @@ void intc_preinit(void);
>  
>  void register_intc_ops(struct intc_hw_operations *ops);
>  
> +void intc_init(void);
> +
> +void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
> +
>  #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
> diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
> index 122e7b32b5..15f358601d 100644
> --- a/xen/arch/riscv/intc.c
> +++ b/xen/arch/riscv/intc.c
> @@ -1,9 +1,12 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -21,3 +24,45 @@ void __init intc_preinit(void)
>      else
>          panic("ACPI interrupt controller preinit() isn't implemented\n");
>  }
> +
> +void __init intc_init(void)
> +{
> +    ASSERT(intc_hw_ops);

What's the goal of this check (also elsewhere below)? You'll crash anyway ...

> +    if ( intc_hw_ops->init() )

... here if the point is still NULL, just like you will if the function
pointer is unpopulated (and hence NULL).

Preferably with all of these (but not the other assertions) dropped
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 09:38:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:38:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985049.1370974 (Exim 4.92)
	(envelope-from )
	id 1uFV33-0005X1-6k; Thu, 15 May 2025 09:38:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985049.1370974; Thu, 15 May 2025 09: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 1uFV33-0005Wu-40; Thu, 15 May 2025 09:38:41 +0000
Received: by outflank-mailman (input) for mailman id 985049;
 Thu, 15 May 2025 09:38:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFV31-0005Wo-HE
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:38:39 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 60b03bb2-3170-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 11:38:37 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5fc5bc05f99so1521018a12.3
 for ; Thu, 15 May 2025 02:38:37 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad23ad2b386sm895152066b.104.2025.05.15.02.38.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 02: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" 
X-Inumbo-ID: 60b03bb2-3170-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747301917; x=1747906717; 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;
        bh=ra3Af8iHOGAhRe8Msi9f22YdlWPBGx9XtxlgTPr25PQ=;
        b=Fln9s8n3Z8umh4atYd8I2nrvWcuXgagdVDoRXEH8stQ+G3fFCgCBPYGwKdZohasKSY
         E+Dgc3YyPJ8eVytI3UlGv7wjbvP5Vr8W4LTIVf0gbLWe5JXQDG/+WzwENIjDwhhnO/vF
         B6JoYebvyqHTbA+ssWm0NhlqlR5Mlmv6NP3w0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747301917; x=1747906717;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ra3Af8iHOGAhRe8Msi9f22YdlWPBGx9XtxlgTPr25PQ=;
        b=aNwKxrW08Sc136jBxVkzG1qmsWhe8URC6fzx2tI0Q424Lu8b0SjB6TMuzDpl6hb1pq
         1FRubY/yYHR9yrGxfeejnQGj8OitioejHpT3Goe4EixLG4RoaZBwNK0RUb/Qmh0ayUUp
         GqcqZUUGoeIChpk/mMdC6FRWTdY7qqWFroo5DuXGKbREKRTt3wSz0lJPFnGuVpjsxvhx
         WogqjVzVbQ6pNVqAXZgbkaghhxqZ+hPYO5fdTy4bgkv4IJQDq998diK2ZkjKizE90N/X
         Lm7Y63P31RMUDi9CkUOXcjhAAUhsPyJEBZ/qLS/ad9OCIjDiYc6LjyZh0rFa9I3WXofD
         730g==
X-Gm-Message-State: AOJu0YwZNHODvhY/TBlWshCKvM9BOLqqSdmLckZJm2VQGPMXuDx5nVeH
	uGc/cTzLGQRHFmetqSvgKmwZH/VW/RjF0V0avlOFCR08okBFAUx/+dh74nqJDg6zzE5p3Ds0/78
	=
X-Gm-Gg: ASbGncv4LXw/kwV2zv4wZKmgSJvtyIENUScr0yEbBO1//bT3mE9qCDR8H+tuxmU16iT
	+tFRn9alJsZo8ZdrBrfmYAk0vVcXXAqMpuE7RufiaxoNbNCm1dsfWNwuUYq+xN1SJ4dBedSf133
	oHh5hjFgml6uQaA+bvOeNPC4xucJAqOi9JTvFQkZz836iBAKQ1o+HNp+zcMFfBZkLInnf0GEZAr
	r9TbPeJ9zos/v5ofSYhMjN/Hmtf2nIHuBtZeZ7hDiRVBRJtBgZW+Lud7yt7R/XOE3ZSd0RCJLvE
	qACM/Fu5iUKcTFrsxmRTII1mPTWO+7EXld9DF7t5yFIz7aFMGcaE+zqLBJyAM30pujDs9qyqoyx
	uRlCk+bBOwA==
X-Google-Smtp-Source: AGHT+IFGadtjS10+DB0YdgBSo3n/4vmWf5gQA3da8bQt8VFRxhYOMOmktzkr8YepWOULhidwUwnEqA==
X-Received: by 2002:a17:907:868c:b0:ad2:28a0:4248 with SMTP id a640c23a62f3a-ad4f70fb96cmr707716566b.3.1747301912306;
        Thu, 15 May 2025 02:38:32 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 0/5] LivePatch signing support
Date: Thu, 15 May 2025 10:38:15 +0100
Message-ID: <20250515093822.659916-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Live patch signing support was mentioned as future work in the design
document several years ago. This series finally implements support for
it since it is a requirement of Secure Boot to prevent loading unsigned
code into Xen.

See the individual patches for what has changed in v2.

Jennifer Herbert (1):
  livepatch: Verify livepatch signatures

Kevin Lampis (1):
  livepatch: Embed public key in Xen

Ross Lagerwall (3):
  docs: Introduce live patch signing
  crypto: Add RSA support
  livepatch: Load built-in key during boot

 docs/misc/livepatch.pandoc      |  106 +-
 xen/common/Kconfig              |   18 +
 xen/common/Makefile             |    1 +
 xen/common/livepatch.c          |  145 +++
 xen/common/livepatch_elf.c      |   55 +
 xen/common/mpi.c                | 1729 +++++++++++++++++++++++++++++++
 xen/crypto/Makefile             |   14 +
 xen/crypto/rsa.c                |  196 ++++
 xen/include/xen/livepatch.h     |   16 +
 xen/include/xen/livepatch_elf.h |   18 +
 xen/include/xen/mpi.h           |   68 ++
 xen/include/xen/rsa.h           |   74 ++
 xen/tools/extract-key.py        |   37 +
 13 files changed, 2425 insertions(+), 52 deletions(-)
 create mode 100644 xen/common/mpi.c
 create mode 100644 xen/crypto/rsa.c
 create mode 100644 xen/include/xen/mpi.h
 create mode 100644 xen/include/xen/rsa.h
 create mode 100755 xen/tools/extract-key.py

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 15 09:38:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:38:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985050.1370984 (Exim 4.92)
	(envelope-from )
	id 1uFV37-0005lh-Do; Thu, 15 May 2025 09:38:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985050.1370984; Thu, 15 May 2025 09:38: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 1uFV37-0005la-BC; Thu, 15 May 2025 09:38:45 +0000
Received: by outflank-mailman (input) for mailman id 985050;
 Thu, 15 May 2025 09:38:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFV36-0005Wo-Am
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:38:44 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 63a9bdcd-3170-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 11:38:42 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad1f6aa2f84so155071666b.0
 for ; Thu, 15 May 2025 02:38:42 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad23ad2b386sm895152066b.104.2025.05.15.02.38.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 02:38: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" 
X-Inumbo-ID: 63a9bdcd-3170-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747301922; x=1747906722; 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;
        bh=C2YHsd33az4IEQZXfpbWWt/V02BA69yDMw7arHlEWzs=;
        b=krVBeBxOPYRGFb+F9301t/XpI9Rd2+8mbAjzmdIauqOmk+PvABoJs3vsU2ufYldPKt
         1S3AiZjkEinvH0qLZeEKiVSosNtJlnqSN68+hSUPdOxpNEbWFKm7/LmMheBjzZjbRuNq
         3dANTAIWGB+cPJqS+wqrXNNgInDlUP1oQbVXA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747301922; x=1747906722;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=C2YHsd33az4IEQZXfpbWWt/V02BA69yDMw7arHlEWzs=;
        b=C3mO4+60HfCDpnyTRvoU9YJkYonCvKIK/dxTKho0YRlC1yIwLAVO0Pr+DggSloFfcy
         LJ4zTFgJjwNqYUn1gQdlqLvlg/SNWOYW/P64mqJTU9s7ftzohK658nFUB0fWidr9w0fb
         ILU9bZF0f3zHENT+QRR4Lwc0rXAZ1RzfKchZskVIu7FqLsxXzvgGrmJOYubEVW31w+II
         NeOHiONvSmrQKXppwLTe+YOnUp31tVKSU/KAv7g2lu5iZv1J8Apq7yYycIHaVFDzFqdz
         9bbQtlxdDUWQ3pWrLpfr0FluPOFDPChg3+bD95VBuGoOlw6ARDHq8ak6cdQCIx1gQtSn
         qRig==
X-Gm-Message-State: AOJu0YxhT1feX3vmdFJQXz7RnYW7wvjG8VZHg0iyuKdU+F7PKeTX1Avi
	v72kpI0pZgcvPvup97+NzVP9U2JCmYdBvnSt7rmsp2wFhjgnS19YVPMwweVwwD5TIiG07xt6zwk
	=
X-Gm-Gg: ASbGncvxO9NSsP7RlNkEqJkhHA8xUTVt1T1Z7TRCcGK+pnhgjo0A1cZirMqDYM4ZcFF
	oi20jzztu/fvurYRKQ2fzqP4wMwnPp+G9kLh2+vJWGZOu6pwDVE47JuA8kGK44HStLDU0VJngBz
	8tJXtW6BNPdQ8z6uoR6cb/XTXPxASvUGDzMswID3DAUVjkNe02jEmZcn2aW9mS1pfPSCdJn4H4x
	0OV3cFCHVn5Cb0QyYWBFjZGGK2N0fSB1XJ7shbzgRIRgeRkjciFEXIXpqg+oeWc4R5v8KM0K/Bb
	kLNBHy6U3FQV6XA8SOUZTkdHuOrbJ+eKxXPXLa06NwpUNab4gWg02H3zPzK3xZNXvg3opwp6dk4
	=
X-Google-Smtp-Source: AGHT+IF+f/RtLS/hvRlt47H9AFouG2ljmzVe92Nty3OLMq+adiQ7hLsqzwfllbyPq84XBTD5fLGNbg==
X-Received: by 2002:a17:907:c00f:b0:ad5:112:490b with SMTP id a640c23a62f3a-ad50f59115cmr249485466b.9.1747301921819;
        Thu, 15 May 2025 02:38:41 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 1/5] docs: Introduce live patch signing
Date: Thu, 15 May 2025 10:38:16 +0100
Message-ID: <20250515093822.659916-2-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250515093822.659916-1-ross.lagerwall@citrix.com>
References: <20250515093822.659916-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Remove a never-implemented description of live patch signing from the
TODO section and document signing as implemented by the following
patches.

Signed-off-by: Ross Lagerwall 
---

In v2:

* Use ELF note type and descriptor length rather than a custom header.
* Rename SIGNATURE_SUPPORTED_VERION

 docs/misc/livepatch.pandoc | 106 +++++++++++++++++++------------------
 1 file changed, 54 insertions(+), 52 deletions(-)

diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
index 04dd5ed7b271..f36de449e992 100644
--- a/docs/misc/livepatch.pandoc
+++ b/docs/misc/livepatch.pandoc
@@ -917,6 +917,60 @@ The normal sequence of events is to:
  3. *XEN_SYSCTL_LIVEPATCH_ACTION* with *LIVEPATCH_ACTION_APPLY* to apply the patch.
  4. *XEN_SYSCTL_LIVEPATCH_GET* to check the `->rc`. If in *-XEN_EAGAIN* spin. If zero exit with success.
 
+## Signature Checking
+
+While loading live patches would generally be restricted to a privileged
+process in dom0, in certain cases signature checking in Xen may be required.
+For example, when Secure Boot is enabled live patches need to be verified
+before being loaded.
+
+Xen live patches are ELF binaries but there is no standardized mechanism for
+signing ELF binaries. One approach used by Linux is to append a signature to
+the end of the binary, outside of the ELF container. While this works, it tends
+to be fragile since tools that handle ELF binaries do not correctly handle the
+signature. Instead, the approach taken here is to use an ELF note for the
+signature.
+
+The ELF note section name shall be `.note.Xen.signature` with note name `Xen`.
+The note type shall encode the signature version, algorithm, and hash:
+
+* version - uint16_t, bits 0-15
+* algorithm - uint8_t, bits 16-23
+* hash - uint8_t, bits 24-31
+
+All other bits of the note type shall be zero.
+
+The known values for the above fields are:
+
+    #define LIVEPATCH_SIGNATURE_VERSION 1
+    #define SIGNATURE_ALGORITHM_RSA 0
+    #define SIGNATURE_HASH_SHA256 0
+
+The note descriptor length defines the length of the signature.
+
+To sign a live patch:
+
+1) Add a new note section with a populated payload signature and zeroed out
+   signature.
+2) Generate a detached signature over the entire binary.
+3) Fill in the signature in the note section.
+
+During live patch load, Xen shall verify the signature using the following
+steps:
+
+1) Copy the signature out of the note section.
+2) Zero the signature.
+3) Generate a detached signature over the entire binary.
+4) Compare against the signature from (1).
+
+Initially, to avoid including DER / X.509 parsing of certificates, handling
+chains, etc. Xen shall verify signatures against a compiled in RSA key in
+exponent/modulus form. However, it may be extended in future to support other
+types of signatures and key types.
+
+Support of signatures in Xen and in live patches is optional. However, certain
+features such as Secure Boot may require live patches to be signed.
+
 
 ## Addendum
 
@@ -1178,58 +1232,6 @@ the function itself.
 Similar considerations are true to a lesser extent for \__FILE__, but it
 could be argued that file renaming should be done outside of hotpatches.
 
-## Signature checking requirements.
-
-The signature checking requires that the layout of the data in memory
-**MUST** be same for signature to be verified. This means that the payload
-data layout in ELF format **MUST** match what the hypervisor would be
-expecting such that it can properly do signature verification.
-
-The signature is based on the all of the payloads continuously laid out
-in memory. The signature is to be appended at the end of the ELF payload
-prefixed with the string '`~Module signature appended~\n`', followed by
-an signature header then followed by the signature, key identifier, and signers
-name.
-
-Specifically the signature header would be:
-
-    #define PKEY_ALGO_DSA       0
-    #define PKEY_ALGO_RSA       1
-
-    #define PKEY_ID_PGP         0 /* OpenPGP generated key ID */
-    #define PKEY_ID_X509        1 /* X.509 arbitrary subjectKeyIdentifier */
-
-    #define HASH_ALGO_MD4          0
-    #define HASH_ALGO_MD5          1
-    #define HASH_ALGO_SHA1         2
-    #define HASH_ALGO_RIPE_MD_160  3
-    #define HASH_ALGO_SHA256       4
-    #define HASH_ALGO_SHA384       5
-    #define HASH_ALGO_SHA512       6
-    #define HASH_ALGO_SHA224       7
-    #define HASH_ALGO_RIPE_MD_128  8
-    #define HASH_ALGO_RIPE_MD_256  9
-    #define HASH_ALGO_RIPE_MD_320 10
-    #define HASH_ALGO_WP_256      11
-    #define HASH_ALGO_WP_384      12
-    #define HASH_ALGO_WP_512      13
-    #define HASH_ALGO_TGR_128     14
-    #define HASH_ALGO_TGR_160     15
-    #define HASH_ALGO_TGR_192     16
-
-    struct elf_payload_signature {
-	    u8	algo;		/* Public-key crypto algorithm PKEY_ALGO_*. */
-	    u8	hash;		/* Digest algorithm: HASH_ALGO_*. */
-	    u8	id_type;	/* Key identifier type PKEY_ID*. */
-	    u8	signer_len;	/* Length of signer's name */
-	    u8	key_id_len;	/* Length of key identifier */
-	    u8	__pad[3];
-	    __be32	sig_len;	/* Length of signature data */
-    };
-
-(Note that this has been borrowed from Linux module signature code.).
-
-
 ### .bss and .data sections.
 
 In place patching writable data is not suitable as it is unclear what should be done
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 15 09:38:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:38:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985051.1370994 (Exim 4.92)
	(envelope-from )
	id 1uFV3G-00065a-MC; Thu, 15 May 2025 09:38:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985051.1370994; Thu, 15 May 2025 09:38: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 1uFV3G-00065T-J3; Thu, 15 May 2025 09:38:54 +0000
Received: by outflank-mailman (input) for mailman id 985051;
 Thu, 15 May 2025 09:38:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFV3F-00064K-1R
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:38:53 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 69327bd5-3170-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 11:38:52 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad21c5d9db2so120347566b.3
 for ; Thu, 15 May 2025 02:38:52 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad23ad2b386sm895152066b.104.2025.05.15.02.38.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 02:38: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" 
X-Inumbo-ID: 69327bd5-3170-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747301931; x=1747906731; 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;
        bh=YnUmUgPgbFUnQx+UmkBslLpd+DBmQmjpaU9WoTpKlxU=;
        b=lF+H3Vy3oZUyX9JanVx471H3ImbEILtFLmQNoCFVJfdGK+45KFOOxhQt6QdD/OrKjt
         72IquznOyB3OZrG62DbdryFdqAyPtyb0Hj+akpAf2BluMvq+YBYi0UF6q1FgEi4EADbh
         dwoyDLBInsqZ+TbGn1YMRP0uSVjmcTXa3jzxw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747301931; x=1747906731;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=YnUmUgPgbFUnQx+UmkBslLpd+DBmQmjpaU9WoTpKlxU=;
        b=H2qsBHpNeZqLA+XHzZzXhDviOlUMtYK5Mb4qdOC7vY1SaumYUqc8H/KBPd3TkcFq7C
         PyfjGoyY+CEXbmEJy5wcDTr6b4gYQuNQG1uprs4OOahUVWkBy+nTpM1xwTo4BgcTzgtT
         t9mrizB759IS4WlVjQKpkjNLx0b53YgIxnilhuewd/2Au625CZm7snVJOvivkr2PeAUs
         q9wQmfWGgbjp2N8lf/g208YSN5og3QG+QoI7n19jQBsKYloIZyUIUM96qPIEjgJ2aQzX
         nBLDEsRdM7u1+Y5ClFVpq5Hv7qJHGooKFYlOxqvnvIGuHMB48BKqi/I14SXx0VcpLtKV
         c2wg==
X-Gm-Message-State: AOJu0YwDvqtiiIqZ48IVRyVP7KnJGrHZyCJFRX5E/cigLmsk7creKrGe
	C0448N+2fOzg8FXrkQPu1SDIPB9DI08fAt43OYnzij8K9AbWwQkYbP5ZRZqIWGGhuJisRlbdxUM
	=
X-Gm-Gg: ASbGncvz3Xv6QBcpdKrLdq9t/qqRypi27ouUD3JjNk+QT3KhU2ZNOoo/oGF5HAjkXuh
	4jdtQaCBNgzw3JbNXCuQeTghmOYyroFKBpWDgmS4mVm9LA/PGxYp6Dzr9nfCddlK1yPEccj64L8
	x80RVdBUZxzqaGWPIC2yH254D+ZFwVpx1rB3lRIlHGut3fHLh/iZa/hwHOgC9v1RleFmSxkScJW
	xtvMNFhgZnxlxZ2Av8jMuGeEoTpnNGPHfCYxoJ3JggF6edfkjwvbw6CQw/jSpO69sxV35K0UgWs
	lvZxjgAV2kP3/KVLrOD6jE8FvLwOWawGWkXi9GRzIGS0PKpO3+afSb0g6N8CR+gxiTmDNiHRJEM
	=
X-Google-Smtp-Source: AGHT+IGRWh68cUopTkqb1BDANPJN1q3jPMaZLmkx2hsvch8+1Hi85IEWsO+4dZw9hR0RFC/hAxk3cw==
X-Received: by 2002:a17:907:7211:b0:ac7:3912:5ea5 with SMTP id a640c23a62f3a-ad4f7517d14mr702335266b.58.1747301930190;
        Thu, 15 May 2025 02:38:50 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 3/5] crypto: Add RSA support
Date: Thu, 15 May 2025 10:38:18 +0100
Message-ID: <20250515093822.659916-4-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250515093822.659916-1-ross.lagerwall@citrix.com>
References: <20250515093822.659916-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In preparation for adding support for livepatch signing, add support for
RSA crypto.

The RSA code is extracted from Nettle at tag nettle_3.2_release_20160128
(https://git.lysator.liu.se/nettle/nettle).

The MPI code is extracted from Linux at commit eef0df6a5953 (lib/mpi/*).

Signed-off-by: Ross Lagerwall 
---

In v2:

* Fix MISRA complaint.
* Address some style and other minor issues.

 xen/common/Makefile   |    1 +
 xen/common/mpi.c      | 1729 +++++++++++++++++++++++++++++++++++++++++
 xen/crypto/Makefile   |    1 +
 xen/crypto/rsa.c      |  196 +++++
 xen/include/xen/mpi.h |   68 ++
 xen/include/xen/rsa.h |   74 ++
 6 files changed, 2069 insertions(+)
 create mode 100644 xen/common/mpi.c
 create mode 100644 xen/crypto/rsa.c
 create mode 100644 xen/include/xen/mpi.h
 create mode 100644 xen/include/xen/rsa.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f08730563f..aa533859479a 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-y += memory.o
+obj-$(CONFIG_PAYLOAD_VERIFY) += mpi.o
 obj-y += multicall.o
 obj-y += notifier.o
 obj-$(CONFIG_NUMA) += numa.o
diff --git a/xen/common/mpi.c b/xen/common/mpi.c
new file mode 100644
index 000000000000..94010d14b3d0
--- /dev/null
+++ b/xen/common/mpi.c
@@ -0,0 +1,1729 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/* mpi.c  -  MPI functions
+ * Copyright (C) 1994, 1996, 1998, 2000 Free Software Foundation, Inc.
+ *
+ * This file is part of GnuPG.
+ *
+ * GnuPG is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * GnuPG is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ *
+ * Note: This code is heavily based on the GNU MP Library.
+ *	 Actually it's the same code with only minor changes in the
+ *	 way the data is stored; this is to support the abstraction
+ *	 of an optional secure memory allocation which may be used
+ *	 to avoid revealing of sensitive data due to paging etc.
+ *	 The GNU MP Library itself is published under the LGPL;
+ *	 however I decided to publish this code under the plain GPL.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_EXTERN_MPI_BITS 16384
+
+/* Define it to a value which is good on most machines.
+ * tested 4, 16, 32 and 64, where 16 gave the best performance when
+ * checking a 768 and a 1024 bit ElGamal signature.
+ * (wk 22.12.97) */
+#define KARATSUBA_THRESHOLD 16
+
+typedef mpi_limb_t *mpi_ptr_t;	/* pointer to a limb */
+typedef int mpi_size_t;		/* (must be a signed type) */
+
+/* Copy N limbs from S to D.  */
+#define MPN_COPY(d, s, n) \
+	do {					\
+		mpi_size_t _i;			\
+		for (_i = 0; _i < (n); _i++)	\
+			(d)[_i] = (s)[_i];	\
+	} while (0)
+
+#define MPN_COPY_DECR(d, s, n) \
+	do {					\
+		mpi_size_t _i;			\
+		for (_i = (n)-1; _i >= 0; _i--) \
+			(d)[_i] = (s)[_i];	\
+	} while (0)
+
+/* Zero N limbs at D */
+#define MPN_ZERO(d, n) \
+	do {					\
+		mpi_size_t  _i;			\
+		for (_i = 0; _i < (n); _i++)	\
+			(d)[_i] = 0;		\
+	} while (0)
+
+#define MPN_NORMALIZE(d, n)  \
+	do {					\
+		while ((n) > 0) {		\
+			if ((d)[(n)-1])		\
+				break;		\
+			(n)--;			\
+		}				\
+	} while (0)
+
+#define MPN_MUL_N_RECURSE(prodp, up, vp, size, tspace)		\
+	do {							\
+		if ((size) < KARATSUBA_THRESHOLD)		\
+			mul_n_basecase(prodp, up, vp, size);	\
+		else						\
+			mul_n(prodp, up, vp, size, tspace);	\
+	} while (0);
+
+#define MPN_SQR_N_RECURSE(prodp, up, size, tspace)		\
+	do {							\
+		if ((size) < KARATSUBA_THRESHOLD)		\
+			mpih_sqr_n_basecase(prodp, up, size);	\
+		else						\
+			mpih_sqr_n(prodp, up, size, tspace);	\
+	} while (0);
+
+#define add_ssaaaa(sh, sl, ah, al, bh, bl) \
+do { \
+	mpi_limb_t __x; \
+	__x = (al) + (bl); \
+	(sh) = (ah) + (bh) + (__x < (al)); \
+	(sl) = __x; \
+} while (0)
+
+#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
+do { \
+	mpi_limb_t __x; \
+	__x = (al) - (bl); \
+	(sh) = (ah) - (bh) - (__x > (al)); \
+	(sl) = __x; \
+} while (0)
+
+#define __ll_B ((mpi_limb_t) 1 << (BITS_PER_MPI_LIMB / 2))
+#define __ll_lowpart(t) ((mpi_limb_t) (t) & (__ll_B - 1))
+#define __ll_highpart(t) ((mpi_limb_t) (t) >> (BITS_PER_MPI_LIMB / 2))
+
+#define umul_ppmm(w1, w0, u, v) \
+do { \
+	mpi_limb_t __x0, __x1, __x2, __x3; \
+	unsigned int __ul, __vl, __uh, __vh; \
+	mpi_limb_t __u = (u), __v = (v); \
+	\
+	__ul = __ll_lowpart(__u); \
+	__uh = __ll_highpart(__u); \
+	__vl = __ll_lowpart(__v); \
+	__vh = __ll_highpart(__v); \
+	\
+	__x0 = (mpi_limb_t) __ul * __vl; \
+	__x1 = (mpi_limb_t) __ul * __vh; \
+	__x2 = (mpi_limb_t) __uh * __vl; \
+	__x3 = (mpi_limb_t) __uh * __vh; \
+	\
+	__x1 += __ll_highpart(__x0);/* this can't give carry */ \
+	__x1 += __x2;		/* but this indeed can */ \
+	if (__x1 < __x2)		/* did we get it? */ \
+	__x3 += __ll_B;		/* yes, add it in the proper pos. */ \
+	\
+	(w1) = __x3 + __ll_highpart(__x1); \
+	(w0) = (__ll_lowpart(__x1) << BITS_PER_MPI_LIMB/2) + __ll_lowpart(__x0); \
+} while (0)
+
+#define udiv_qrnnd(q, r, n1, n0, d) \
+do { \
+	mpi_limb_t __d1, __d0, __q1, __q0, __r1, __r0, __m; \
+	__d1 = __ll_highpart(d); \
+	__d0 = __ll_lowpart(d); \
+	\
+	__r1 = (n1) % __d1; \
+	__q1 = (n1) / __d1; \
+	__m = (mpi_limb_t) __q1 * __d0; \
+	__r1 = __r1 * __ll_B | __ll_highpart(n0); \
+	if (__r1 < __m) { \
+		__q1--, __r1 += (d); \
+		if (__r1 >= (d)) /* i.e. we didn't get carry when adding to __r1 */ \
+		if (__r1 < __m) \
+			__q1--, __r1 += (d); \
+	} \
+	__r1 -= __m; \
+	\
+	__r0 = __r1 % __d1; \
+	__q0 = __r1 / __d1; \
+	__m = (mpi_limb_t) __q0 * __d0; \
+	__r0 = __r0 * __ll_B | __ll_lowpart(n0); \
+	if (__r0 < __m) { \
+		__q0--, __r0 += (d); \
+		if (__r0 >= (d)) \
+			if (__r0 < __m) \
+				__q0--, __r0 += (d); \
+	} \
+	__r0 -= __m; \
+	\
+	(q) = (mpi_limb_t) __q1 * __ll_B | __q0; \
+	(r) = __r0; \
+} while (0)
+
+struct karatsuba_ctx {
+	struct karatsuba_ctx *next;
+	mpi_ptr_t tspace;
+	mpi_size_t tspace_size;
+	mpi_ptr_t tp;
+	mpi_size_t tp_size;
+};
+
+static void mpi_normalize(MPI a);
+static mpi_limb_t mpihelp_submul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			    mpi_size_t s1_size, mpi_limb_t s2_limb);
+static mpi_limb_t mpihelp_divrem(mpi_ptr_t qp, mpi_size_t qextra_limbs,
+			  mpi_ptr_t np, mpi_size_t nsize,
+			  mpi_ptr_t dp, mpi_size_t dsize);
+static mpi_limb_t mpihelp_rshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize,
+			  unsigned cnt);
+static void mpi_assign_limb_space(MPI a, mpi_ptr_t ap, unsigned nlimbs);
+static mpi_ptr_t mpi_alloc_limb_space(unsigned nlimbs);
+static void mpi_free_limb_space(mpi_ptr_t a);
+static mpi_limb_t mpihelp_addmul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			    mpi_size_t s1_size, mpi_limb_t s2_limb);
+static int mpihelp_mul(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t usize,
+		mpi_ptr_t vp, mpi_size_t vsize, mpi_limb_t *_result);
+static mpi_limb_t mpihelp_lshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize,
+			  unsigned cnt);
+static int mpihelp_cmp(mpi_ptr_t op1_ptr, mpi_ptr_t op2_ptr, mpi_size_t size);
+static void mpih_sqr_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size,
+		mpi_ptr_t tspace);
+static mpi_limb_t mpihelp_add_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			 mpi_ptr_t s2_ptr, mpi_size_t size);
+static mpi_limb_t mpihelp_sub_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			 mpi_ptr_t s2_ptr, mpi_size_t size);
+static mpi_limb_t mpihelp_mul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+			 mpi_size_t s1_size, mpi_limb_t s2_limb);
+static void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx *ctx);
+static void mpih_sqr_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size);
+static int mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,
+			       mpi_ptr_t up, mpi_size_t usize,
+			       mpi_ptr_t vp, mpi_size_t vsize,
+			       struct karatsuba_ctx *ctx);
+static int mpi_resize(MPI a, unsigned nlimbs);
+
+/**
+ * count_leading_zeros - Count the number of zeros from the MSB back
+ * @x: The value
+ *
+ * Count the number of leading zeros from the MSB going towards the LSB in @x.
+ *
+ * If the MSB of @x is set, the result is 0.
+ * If only the LSB of @x is set, then the result is BITS_PER_LONG-1.
+ * If @x is 0 then the result is BITS_PER_LONG.
+ */
+static inline int count_leading_zeros(unsigned long x)
+{
+	if (sizeof(x) == 4)
+		return BITS_PER_LONG - fls(x);
+	else
+		return BITS_PER_LONG - fls64(x);
+}
+
+static mpi_limb_t
+mpihelp_add_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t x;
+
+	x = *s1_ptr++;
+	s2_limb += x;
+	*res_ptr++ = s2_limb;
+	if (s2_limb < x) {	/* sum is less than the left operand: handle carry */
+		while (--s1_size) {
+			x = *s1_ptr++ + 1;	/* add carry */
+			*res_ptr++ = x;	/* and store */
+			if (x)	/* not 0 (no overflow): we can stop */
+				goto leave;
+		}
+		return 1;	/* return carry (size of s1 to small) */
+	}
+
+ leave:
+	if (res_ptr != s1_ptr) {	/* not the same variable */
+		mpi_size_t i;	/* copy the rest */
+		for (i = 0; i < s1_size - 1; i++)
+			res_ptr[i] = s1_ptr[i];
+	}
+	return 0;		/* no carry */
+}
+
+static mpi_limb_t
+mpihelp_sub_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t x;
+
+	x = *s1_ptr++;
+	s2_limb = x - s2_limb;
+	*res_ptr++ = s2_limb;
+	if (s2_limb > x) {
+		while (--s1_size) {
+			x = *s1_ptr++;
+			*res_ptr++ = x - 1;
+			if (x)
+				goto leave;
+		}
+		return 1;
+	}
+
+ leave:
+	if (res_ptr != s1_ptr) {
+		mpi_size_t i;
+		for (i = 0; i < s1_size - 1; i++)
+			res_ptr[i] = s1_ptr[i];
+	}
+	return 0;
+}
+
+static mpi_limb_t
+mpihelp_sub(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size,
+	    mpi_ptr_t s2_ptr, mpi_size_t s2_size)
+{
+	mpi_limb_t cy = 0;
+
+	if (s2_size)
+		cy = mpihelp_sub_n(res_ptr, s1_ptr, s2_ptr, s2_size);
+
+	if (s1_size - s2_size)
+		cy = mpihelp_sub_1(res_ptr + s2_size, s1_ptr + s2_size,
+				   s1_size - s2_size, cy);
+	return cy;
+}
+
+static mpi_ptr_t mpi_alloc_limb_space(unsigned nlimbs)
+{
+	size_t len = nlimbs * sizeof(mpi_limb_t);
+
+	if (!len)
+		return NULL;
+
+	return xmalloc_bytes(len);
+}
+
+static void mpi_free_limb_space(mpi_ptr_t a)
+{
+	if (!a)
+		return;
+
+	xfree(a);
+}
+
+/****************
+ * Resize the array of A to NLIMBS. the additional space is cleared
+ * (set to 0) [done by m_realloc()]
+ */
+static int mpi_resize(MPI a, unsigned nlimbs)
+{
+	void *p;
+
+	if (nlimbs <= a->alloced)
+		return 0;	/* no need to do it */
+
+	if (a->d) {
+		p = xmalloc_array(mpi_limb_t, nlimbs);
+		if (!p)
+			return -ENOMEM;
+		memcpy(p, a->d, a->alloced * sizeof(mpi_limb_t));
+		xfree(a->d);
+		a->d = p;
+	} else {
+		a->d = xzalloc_array(mpi_limb_t, nlimbs);
+		if (!a->d)
+			return -ENOMEM;
+	}
+	a->alloced = nlimbs;
+	return 0;
+}
+
+/****************
+ * RES = BASE ^ EXP mod MOD
+ */
+int mpi_powm(MPI res, MPI base, MPI exp, MPI mod)
+{
+	mpi_ptr_t mp_marker = NULL, bp_marker = NULL, ep_marker = NULL;
+	mpi_ptr_t xp_marker = NULL;
+	mpi_ptr_t tspace = NULL;
+	mpi_ptr_t rp, ep, mp, bp;
+	mpi_size_t esize, msize, bsize, rsize;
+	int msign, bsign, rsign;
+	mpi_size_t size;
+	int mod_shift_cnt;
+	int negative_result;
+	int assign_rp = 0;
+	mpi_size_t tsize = 0;	/* to avoid compiler warning */
+	/* fixme: we should check that the warning is void */
+	int rc = -ENOMEM;
+
+	esize = exp->nlimbs;
+	msize = mod->nlimbs;
+	size = 2 * msize;
+	msign = mod->sign;
+
+	rp = res->d;
+	ep = exp->d;
+
+	if (!msize)
+		return -EINVAL;
+
+	if (!esize) {
+		/* Exponent is zero, result is 1 mod MOD, i.e., 1 or 0
+		 * depending on if MOD equals 1.  */
+		res->nlimbs = (msize == 1 && mod->d[0] == 1) ? 0 : 1;
+		if (res->nlimbs) {
+			if (mpi_resize(res, 1) < 0)
+				goto enomem;
+			rp = res->d;
+			rp[0] = 1;
+		}
+		res->sign = 0;
+		goto leave;
+	}
+
+	/* Normalize MOD (i.e. make its most significant bit set) as required by
+	 * mpn_divrem.  This will make the intermediate values in the calculation
+	 * slightly larger, but the correct result is obtained after a final
+	 * reduction using the original MOD value.  */
+	mp = mp_marker = mpi_alloc_limb_space(msize);
+	if (!mp)
+		goto enomem;
+	mod_shift_cnt = count_leading_zeros(mod->d[msize - 1]);
+	if (mod_shift_cnt)
+		mpihelp_lshift(mp, mod->d, msize, mod_shift_cnt);
+	else
+		MPN_COPY(mp, mod->d, msize);
+
+	bsize = base->nlimbs;
+	bsign = base->sign;
+	if (bsize > msize) {	/* The base is larger than the module. Reduce it. */
+		/* Allocate (BSIZE + 1) with space for remainder and quotient.
+		 * (The quotient is (bsize - msize + 1) limbs.)  */
+		bp = bp_marker = mpi_alloc_limb_space(bsize + 1);
+		if (!bp)
+			goto enomem;
+		MPN_COPY(bp, base->d, bsize);
+		/* We don't care about the quotient, store it above the remainder,
+		 * at BP + MSIZE.  */
+		mpihelp_divrem(bp + msize, 0, bp, bsize, mp, msize);
+		bsize = msize;
+		/* Canonicalize the base, since we are going to multiply with it
+		 * quite a few times.  */
+		MPN_NORMALIZE(bp, bsize);
+	} else
+		bp = base->d;
+
+	if (!bsize) {
+		res->nlimbs = 0;
+		res->sign = 0;
+		goto leave;
+	}
+
+	if (res->alloced < size) {
+		/* We have to allocate more space for RES.  If any of the input
+		 * parameters are identical to RES, defer deallocation of the old
+		 * space.  */
+		if (rp == ep || rp == mp || rp == bp) {
+			rp = mpi_alloc_limb_space(size);
+			if (!rp)
+				goto enomem;
+			assign_rp = 1;
+		} else {
+			if (mpi_resize(res, size) < 0)
+				goto enomem;
+			rp = res->d;
+		}
+	} else {		/* Make BASE, EXP and MOD not overlap with RES.  */
+		if (rp == bp) {
+			/* RES and BASE are identical.  Allocate temp. space for BASE.  */
+			BUG_ON(bp_marker);
+			bp = bp_marker = mpi_alloc_limb_space(bsize);
+			if (!bp)
+				goto enomem;
+			MPN_COPY(bp, rp, bsize);
+		}
+		if (rp == ep) {
+			/* RES and EXP are identical.  Allocate temp. space for EXP.  */
+			ep = ep_marker = mpi_alloc_limb_space(esize);
+			if (!ep)
+				goto enomem;
+			MPN_COPY(ep, rp, esize);
+		}
+		if (rp == mp) {
+			/* RES and MOD are identical.  Allocate temporary space for MOD. */
+			BUG_ON(mp_marker);
+			mp = mp_marker = mpi_alloc_limb_space(msize);
+			if (!mp)
+				goto enomem;
+			MPN_COPY(mp, rp, msize);
+		}
+	}
+
+	MPN_COPY(rp, bp, bsize);
+	rsize = bsize;
+	rsign = bsign;
+
+	{
+		mpi_size_t i;
+		mpi_ptr_t xp;
+		int c;
+		mpi_limb_t e;
+		mpi_limb_t carry_limb;
+		struct karatsuba_ctx karactx;
+
+		xp = xp_marker = mpi_alloc_limb_space(2 * (msize + 1));
+		if (!xp)
+			goto enomem;
+
+		memset(&karactx, 0, sizeof karactx);
+		negative_result = (ep[0] & 1) && base->sign;
+
+		i = esize - 1;
+		e = ep[i];
+		c = count_leading_zeros(e);
+		e = (e << c) << 1;	/* shift the exp bits to the left, lose msb */
+		c = BITS_PER_MPI_LIMB - 1 - c;
+
+		/* Main loop.
+		 *
+		 * Make the result be pointed to alternately by XP and RP.  This
+		 * helps us avoid block copying, which would otherwise be necessary
+		 * with the overlap restrictions of mpihelp_divmod. With 50% probability
+		 * the result after this loop will be in the area originally pointed
+		 * by RP (==RES->d), and with 50% probability in the area originally
+		 * pointed to by XP.
+		 */
+
+		for (;;) {
+			while (c) {
+				mpi_ptr_t tp;
+				mpi_size_t xsize;
+
+				/*if (mpihelp_mul_n(xp, rp, rp, rsize) < 0) goto enomem */
+				if (rsize < KARATSUBA_THRESHOLD)
+					mpih_sqr_n_basecase(xp, rp, rsize);
+				else {
+					if (!tspace) {
+						tsize = 2 * rsize;
+						tspace =
+						    mpi_alloc_limb_space(tsize);
+						if (!tspace)
+							goto enomem;
+					} else if (tsize < (2 * rsize)) {
+						mpi_free_limb_space(tspace);
+						tsize = 2 * rsize;
+						tspace =
+						    mpi_alloc_limb_space(tsize);
+						if (!tspace)
+							goto enomem;
+					}
+					mpih_sqr_n(xp, rp, rsize, tspace);
+				}
+
+				xsize = 2 * rsize;
+				if (xsize > msize) {
+					mpihelp_divrem(xp + msize, 0, xp, xsize,
+						       mp, msize);
+					xsize = msize;
+				}
+
+				tp = rp;
+				rp = xp;
+				xp = tp;
+				rsize = xsize;
+
+				if ((mpi_limb_signed_t) e < 0) {
+					/*mpihelp_mul( xp, rp, rsize, bp, bsize ); */
+					if (bsize < KARATSUBA_THRESHOLD) {
+						mpi_limb_t tmp;
+						if (mpihelp_mul
+						    (xp, rp, rsize, bp, bsize,
+						     &tmp) < 0)
+							goto enomem;
+					} else {
+						if (mpihelp_mul_karatsuba_case
+						    (xp, rp, rsize, bp, bsize,
+						     &karactx) < 0)
+							goto enomem;
+					}
+
+					xsize = rsize + bsize;
+					if (xsize > msize) {
+						mpihelp_divrem(xp + msize, 0,
+							       xp, xsize, mp,
+							       msize);
+						xsize = msize;
+					}
+
+					tp = rp;
+					rp = xp;
+					xp = tp;
+					rsize = xsize;
+				}
+				e <<= 1;
+				c--;
+			}
+
+			i--;
+			if (i < 0)
+				break;
+			e = ep[i];
+			c = BITS_PER_MPI_LIMB;
+		}
+
+		/* We shifted MOD, the modulo reduction argument, left MOD_SHIFT_CNT
+		 * steps.  Adjust the result by reducing it with the original MOD.
+		 *
+		 * Also make sure the result is put in RES->d (where it already
+		 * might be, see above).
+		 */
+		if (mod_shift_cnt) {
+			carry_limb =
+			    mpihelp_lshift(res->d, rp, rsize, mod_shift_cnt);
+			rp = res->d;
+			if (carry_limb) {
+				rp[rsize] = carry_limb;
+				rsize++;
+			}
+		} else {
+			MPN_COPY(res->d, rp, rsize);
+			rp = res->d;
+		}
+
+		if (rsize >= msize) {
+			mpihelp_divrem(rp + msize, 0, rp, rsize, mp, msize);
+			rsize = msize;
+		}
+
+		/* Remove any leading zero words from the result.  */
+		if (mod_shift_cnt)
+			mpihelp_rshift(rp, rp, rsize, mod_shift_cnt);
+		MPN_NORMALIZE(rp, rsize);
+
+		mpihelp_release_karatsuba_ctx(&karactx);
+	}
+
+	if (negative_result && rsize) {
+		if (mod_shift_cnt)
+			mpihelp_rshift(mp, mp, msize, mod_shift_cnt);
+		mpihelp_sub(rp, mp, msize, rp, rsize);
+		rsize = msize;
+		rsign = msign;
+		MPN_NORMALIZE(rp, rsize);
+	}
+	res->nlimbs = rsize;
+	res->sign = rsign;
+
+ leave:
+	rc = 0;
+ enomem:
+	if (assign_rp)
+		mpi_assign_limb_space(res, rp, size);
+	if (mp_marker)
+		mpi_free_limb_space(mp_marker);
+	if (bp_marker)
+		mpi_free_limb_space(bp_marker);
+	if (ep_marker)
+		mpi_free_limb_space(ep_marker);
+	if (xp_marker)
+		mpi_free_limb_space(xp_marker);
+	if (tspace)
+		mpi_free_limb_space(tspace);
+	return rc;
+}
+
+/* Multiply the natural numbers u (pointed to by UP) and v (pointed to by VP),
+ * both with SIZE limbs, and store the result at PRODP.  2 * SIZE limbs are
+ * always stored.  Return the most significant limb.
+ *
+ * Argument constraints:
+ * 1. PRODP != UP and PRODP != VP, i.e. the destination
+ *    must be distinct from the multiplier and the multiplicand.
+ *
+ *
+ * Handle simple cases with traditional multiplication.
+ *
+ * This is the most critical code of multiplication.  All multiplies rely
+ * on this, both small and huge.  Small ones arrive here immediately.  Huge
+ * ones arrive here as this is the base case for Karatsuba's recursive
+ * algorithm below.
+ */
+
+static mpi_limb_t
+mul_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_ptr_t vp, mpi_size_t size)
+{
+	mpi_size_t i;
+	mpi_limb_t cy;
+	mpi_limb_t v_limb;
+
+	/* Multiply by the first limb in V separately, as the result can be
+	 * stored (not added) to PROD.  We also avoid a loop for zeroing.  */
+	v_limb = vp[0];
+	if (v_limb <= 1) {
+		if (v_limb == 1)
+			MPN_COPY(prodp, up, size);
+		else
+			MPN_ZERO(prodp, size);
+		cy = 0;
+	} else
+		cy = mpihelp_mul_1(prodp, up, size, v_limb);
+
+	prodp[size] = cy;
+	prodp++;
+
+	/* For each iteration in the outer loop, multiply one limb from
+	 * U with one limb from V, and add it to PROD.  */
+	for (i = 1; i < size; i++) {
+		v_limb = vp[i];
+		if (v_limb <= 1) {
+			cy = 0;
+			if (v_limb == 1)
+				cy = mpihelp_add_n(prodp, prodp, up, size);
+		} else
+			cy = mpihelp_addmul_1(prodp, up, size, v_limb);
+
+		prodp[size] = cy;
+		prodp++;
+	}
+
+	return cy;
+}
+
+static void
+mul_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_ptr_t vp,
+		mpi_size_t size, mpi_ptr_t tspace)
+{
+	if (size & 1) {
+		/* The size is odd, and the code below doesn't handle that.
+		 * Multiply the least significant (size - 1) limbs with a recursive
+		 * call, and handle the most significant limb of S1 and S2
+		 * separately.
+		 * A slightly faster way to do this would be to make the Karatsuba
+		 * code below behave as if the size were even, and let it check for
+		 * odd size in the end.  I.e., in essence move this code to the end.
+		 * Doing so would save us a recursive call, and potentially make the
+		 * stack grow a lot less.
+		 */
+		mpi_size_t esize = size - 1;	/* even size */
+		mpi_limb_t cy_limb;
+
+		MPN_MUL_N_RECURSE(prodp, up, vp, esize, tspace);
+		cy_limb = mpihelp_addmul_1(prodp + esize, up, esize, vp[esize]);
+		prodp[esize + esize] = cy_limb;
+		cy_limb = mpihelp_addmul_1(prodp + esize, vp, size, up[esize]);
+		prodp[esize + size] = cy_limb;
+	} else {
+		/* Anatolij Alekseevich Karatsuba's divide-and-conquer algorithm.
+		 *
+		 * Split U in two pieces, U1 and U0, such that
+		 * U = U0 + U1*(B**n),
+		 * and V in V1 and V0, such that
+		 * V = V0 + V1*(B**n).
+		 *
+		 * UV is then computed recursively using the identity
+		 *
+		 *        2n   n          n                     n
+		 * UV = (B  + B )U V  +  B (U -U )(V -V )  +  (B + 1)U V
+		 *                1 1        1  0   0  1              0 0
+		 *
+		 * Where B = 2**BITS_PER_MP_LIMB.
+		 */
+		mpi_size_t hsize = size >> 1;
+		mpi_limb_t cy;
+		int negflg;
+
+		/* Product H.      ________________  ________________
+		 *                |_____U1 x V1____||____U0 x V0_____|
+		 * Put result in upper part of PROD and pass low part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_MUL_N_RECURSE(prodp + size, up + hsize, vp + hsize, hsize,
+				  tspace);
+
+		/* Product M.      ________________
+		 *                |_(U1-U0)(V0-V1)_|
+		 */
+		if (mpihelp_cmp(up + hsize, up, hsize) >= 0) {
+			mpihelp_sub_n(prodp, up + hsize, up, hsize);
+			negflg = 0;
+		} else {
+			mpihelp_sub_n(prodp, up, up + hsize, hsize);
+			negflg = 1;
+		}
+		if (mpihelp_cmp(vp + hsize, vp, hsize) >= 0) {
+			mpihelp_sub_n(prodp + hsize, vp + hsize, vp, hsize);
+			negflg ^= 1;
+		} else {
+			mpihelp_sub_n(prodp + hsize, vp, vp + hsize, hsize);
+			/* No change of NEGFLG.  */
+		}
+		/* Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_MUL_N_RECURSE(tspace, prodp, prodp + hsize, hsize,
+				  tspace + size);
+
+		/* Add/copy product H. */
+		MPN_COPY(prodp + hsize, prodp + size, hsize);
+		cy = mpihelp_add_n(prodp + size, prodp + size,
+				   prodp + size + hsize, hsize);
+
+		/* Add product M (if NEGFLG M is a negative number) */
+		if (negflg)
+			cy -=
+			    mpihelp_sub_n(prodp + hsize, prodp + hsize, tspace,
+					  size);
+		else
+			cy +=
+			    mpihelp_add_n(prodp + hsize, prodp + hsize, tspace,
+					  size);
+
+		/* Product L.      ________________  ________________
+		 *                |________________||____U0 x V0_____|
+		 * Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_MUL_N_RECURSE(tspace, up, vp, hsize, tspace + size);
+
+		/* Add/copy Product L (twice) */
+
+		cy += mpihelp_add_n(prodp + hsize, prodp + hsize, tspace, size);
+		if (cy)
+			mpihelp_add_1(prodp + hsize + size,
+				      prodp + hsize + size, hsize, cy);
+
+		MPN_COPY(prodp, tspace, hsize);
+		cy = mpihelp_add_n(prodp + hsize, prodp + hsize, tspace + hsize,
+				   hsize);
+		if (cy)
+			mpihelp_add_1(prodp + size, prodp + size, size, 1);
+	}
+}
+
+static void mpih_sqr_n_basecase(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size)
+{
+	mpi_size_t i;
+	mpi_limb_t cy_limb;
+	mpi_limb_t v_limb;
+
+	/* Multiply by the first limb in V separately, as the result can be
+	 * stored (not added) to PROD.  We also avoid a loop for zeroing.  */
+	v_limb = up[0];
+	if (v_limb <= 1) {
+		if (v_limb == 1)
+			MPN_COPY(prodp, up, size);
+		else
+			MPN_ZERO(prodp, size);
+		cy_limb = 0;
+	} else
+		cy_limb = mpihelp_mul_1(prodp, up, size, v_limb);
+
+	prodp[size] = cy_limb;
+	prodp++;
+
+	/* For each iteration in the outer loop, multiply one limb from
+	 * U with one limb from V, and add it to PROD.  */
+	for (i = 1; i < size; i++) {
+		v_limb = up[i];
+		if (v_limb <= 1) {
+			cy_limb = 0;
+			if (v_limb == 1)
+				cy_limb = mpihelp_add_n(prodp, prodp, up, size);
+		} else
+			cy_limb = mpihelp_addmul_1(prodp, up, size, v_limb);
+
+		prodp[size] = cy_limb;
+		prodp++;
+	}
+}
+
+static void
+mpih_sqr_n(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t size, mpi_ptr_t tspace)
+{
+	if (size & 1) {
+		/* The size is odd, and the code below doesn't handle that.
+		 * Multiply the least significant (size - 1) limbs with a recursive
+		 * call, and handle the most significant limb of S1 and S2
+		 * separately.
+		 * A slightly faster way to do this would be to make the Karatsuba
+		 * code below behave as if the size were even, and let it check for
+		 * odd size in the end.  I.e., in essence move this code to the end.
+		 * Doing so would save us a recursive call, and potentially make the
+		 * stack grow a lot less.
+		 */
+		mpi_size_t esize = size - 1;	/* even size */
+		mpi_limb_t cy_limb;
+
+		MPN_SQR_N_RECURSE(prodp, up, esize, tspace);
+		cy_limb = mpihelp_addmul_1(prodp + esize, up, esize, up[esize]);
+		prodp[esize + esize] = cy_limb;
+		cy_limb = mpihelp_addmul_1(prodp + esize, up, size, up[esize]);
+
+		prodp[esize + size] = cy_limb;
+	} else {
+		mpi_size_t hsize = size >> 1;
+		mpi_limb_t cy;
+
+		/* Product H.      ________________  ________________
+		 *                |_____U1 x U1____||____U0 x U0_____|
+		 * Put result in upper part of PROD and pass low part of TSPACE
+		 * as new TSPACE.
+		 */
+		MPN_SQR_N_RECURSE(prodp + size, up + hsize, hsize, tspace);
+
+		/* Product M.      ________________
+		 *                |_(U1-U0)(U0-U1)_|
+		 */
+		if (mpihelp_cmp(up + hsize, up, hsize) >= 0)
+			mpihelp_sub_n(prodp, up + hsize, up, hsize);
+		else
+			mpihelp_sub_n(prodp, up, up + hsize, hsize);
+
+		/* Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.  */
+		MPN_SQR_N_RECURSE(tspace, prodp, hsize, tspace + size);
+
+		/* Add/copy product H  */
+		MPN_COPY(prodp + hsize, prodp + size, hsize);
+		cy = mpihelp_add_n(prodp + size, prodp + size,
+				   prodp + size + hsize, hsize);
+
+		/* Add product M (if NEGFLG M is a negative number).  */
+		cy -= mpihelp_sub_n(prodp + hsize, prodp + hsize, tspace, size);
+
+		/* Product L.      ________________  ________________
+		 *                |________________||____U0 x U0_____|
+		 * Read temporary operands from low part of PROD.
+		 * Put result in low part of TSPACE using upper part of TSPACE
+		 * as new TSPACE.  */
+		MPN_SQR_N_RECURSE(tspace, up, hsize, tspace + size);
+
+		/* Add/copy Product L (twice).  */
+		cy += mpihelp_add_n(prodp + hsize, prodp + hsize, tspace, size);
+		if (cy)
+			mpihelp_add_1(prodp + hsize + size,
+				      prodp + hsize + size, hsize, cy);
+
+		MPN_COPY(prodp, tspace, hsize);
+		cy = mpihelp_add_n(prodp + hsize, prodp + hsize, tspace + hsize,
+				   hsize);
+		if (cy)
+			mpihelp_add_1(prodp + size, prodp + size, size, 1);
+	}
+}
+
+static int
+mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,
+			   mpi_ptr_t up, mpi_size_t usize,
+			   mpi_ptr_t vp, mpi_size_t vsize,
+			   struct karatsuba_ctx *ctx)
+{
+	mpi_limb_t cy;
+
+	if (!ctx->tspace || ctx->tspace_size < vsize) {
+		if (ctx->tspace)
+			mpi_free_limb_space(ctx->tspace);
+		ctx->tspace = mpi_alloc_limb_space(2 * vsize);
+		if (!ctx->tspace)
+			return -ENOMEM;
+		ctx->tspace_size = vsize;
+	}
+
+	MPN_MUL_N_RECURSE(prodp, up, vp, vsize, ctx->tspace);
+
+	prodp += vsize;
+	up += vsize;
+	usize -= vsize;
+	if (usize >= vsize) {
+		if (!ctx->tp || ctx->tp_size < vsize) {
+			if (ctx->tp)
+				mpi_free_limb_space(ctx->tp);
+			ctx->tp = mpi_alloc_limb_space(2 * vsize);
+			if (!ctx->tp) {
+				if (ctx->tspace)
+					mpi_free_limb_space(ctx->tspace);
+				ctx->tspace = NULL;
+				return -ENOMEM;
+			}
+			ctx->tp_size = vsize;
+		}
+
+		do {
+			MPN_MUL_N_RECURSE(ctx->tp, up, vp, vsize, ctx->tspace);
+			cy = mpihelp_add_n(prodp, prodp, ctx->tp, vsize);
+			mpihelp_add_1(prodp + vsize, ctx->tp + vsize, vsize,
+				      cy);
+			prodp += vsize;
+			up += vsize;
+			usize -= vsize;
+		} while (usize >= vsize);
+	}
+
+	if (usize) {
+		if (usize < KARATSUBA_THRESHOLD) {
+			mpi_limb_t tmp;
+			if (mpihelp_mul(ctx->tspace, vp, vsize, up, usize, &tmp)
+			    < 0)
+				return -ENOMEM;
+		} else {
+			if (!ctx->next) {
+				ctx->next = xzalloc(struct karatsuba_ctx);
+				if (!ctx->next)
+					return -ENOMEM;
+			}
+			if (mpihelp_mul_karatsuba_case(ctx->tspace,
+						       vp, vsize,
+						       up, usize,
+						       ctx->next) < 0)
+				return -ENOMEM;
+		}
+
+		cy = mpihelp_add_n(prodp, prodp, ctx->tspace, vsize);
+		mpihelp_add_1(prodp + vsize, ctx->tspace + vsize, usize, cy);
+	}
+
+	return 0;
+}
+
+static void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx *ctx)
+{
+	struct karatsuba_ctx *ctx2;
+
+	if (ctx->tp)
+		mpi_free_limb_space(ctx->tp);
+	if (ctx->tspace)
+		mpi_free_limb_space(ctx->tspace);
+	for (ctx = ctx->next; ctx; ctx = ctx2) {
+		ctx2 = ctx->next;
+		if (ctx->tp)
+			mpi_free_limb_space(ctx->tp);
+		if (ctx->tspace)
+			mpi_free_limb_space(ctx->tspace);
+		xfree(ctx);
+	}
+}
+
+/* Multiply the natural numbers u (pointed to by UP, with USIZE limbs)
+ * and v (pointed to by VP, with VSIZE limbs), and store the result at
+ * PRODP.  USIZE + VSIZE limbs are always stored, but if the input
+ * operands are normalized.  Return the most significant limb of the
+ * result.
+ *
+ * NOTE: The space pointed to by PRODP is overwritten before finished
+ * with U and V, so overlap is an error.
+ *
+ * Argument constraints:
+ * 1. USIZE >= VSIZE.
+ * 2. PRODP != UP and PRODP != VP, i.e. the destination
+ *    must be distinct from the multiplier and the multiplicand.
+ */
+
+static int
+mpihelp_mul(mpi_ptr_t prodp, mpi_ptr_t up, mpi_size_t usize,
+	    mpi_ptr_t vp, mpi_size_t vsize, mpi_limb_t *_result)
+{
+	mpi_ptr_t prod_endp = prodp + usize + vsize - 1;
+	mpi_limb_t cy;
+	struct karatsuba_ctx ctx;
+
+	if (vsize < KARATSUBA_THRESHOLD) {
+		mpi_size_t i;
+		mpi_limb_t v_limb;
+
+		if (!vsize) {
+			*_result = 0;
+			return 0;
+		}
+
+		/* Multiply by the first limb in V separately, as the result can be
+		 * stored (not added) to PROD.  We also avoid a loop for zeroing.  */
+		v_limb = vp[0];
+		if (v_limb <= 1) {
+			if (v_limb == 1)
+				MPN_COPY(prodp, up, usize);
+			else
+				MPN_ZERO(prodp, usize);
+			cy = 0;
+		} else
+			cy = mpihelp_mul_1(prodp, up, usize, v_limb);
+
+		prodp[usize] = cy;
+		prodp++;
+
+		/* For each iteration in the outer loop, multiply one limb from
+		 * U with one limb from V, and add it to PROD.  */
+		for (i = 1; i < vsize; i++) {
+			v_limb = vp[i];
+			if (v_limb <= 1) {
+				cy = 0;
+				if (v_limb == 1)
+					cy = mpihelp_add_n(prodp, prodp, up,
+							   usize);
+			} else
+				cy = mpihelp_addmul_1(prodp, up, usize, v_limb);
+
+			prodp[usize] = cy;
+			prodp++;
+		}
+
+		*_result = cy;
+		return 0;
+	}
+
+	memset(&ctx, 0, sizeof ctx);
+	if (mpihelp_mul_karatsuba_case(prodp, up, usize, vp, vsize, &ctx) < 0)
+		return -ENOMEM;
+	mpihelp_release_karatsuba_ctx(&ctx);
+	*_result = *prod_endp;
+	return 0;
+}
+
+static mpi_limb_t
+mpihelp_mul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr, mpi_size_t s1_size,
+	      mpi_limb_t s2_limb)
+{
+	mpi_limb_t cy_limb;
+	mpi_size_t j;
+	mpi_limb_t prod_high, prod_low;
+
+	/* The loop counter and index J goes from -S1_SIZE to -1.  This way
+	 * the loop becomes faster.  */
+	j = -s1_size;
+
+	/* Offset the base pointers to compensate for the negative indices.  */
+	s1_ptr -= j;
+	res_ptr -= j;
+
+	cy_limb = 0;
+	do {
+		umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
+		prod_low += cy_limb;
+		cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high;
+		res_ptr[j] = prod_low;
+	} while (++j);
+
+	return cy_limb;
+}
+
+static mpi_limb_t
+mpihelp_add_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_ptr_t s2_ptr, mpi_size_t size)
+{
+	mpi_limb_t x, y, cy;
+	mpi_size_t j;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	   the loop becomes faster.  */
+	j = -size;
+
+	/* Offset the base pointers to compensate for the negative indices. */
+	s1_ptr -= j;
+	s2_ptr -= j;
+	res_ptr -= j;
+
+	cy = 0;
+	do {
+		y = s2_ptr[j];
+		x = s1_ptr[j];
+		y += cy;	/* add previous carry to one addend */
+		cy = y < cy;	/* get out carry from that addition */
+		y += x;		/* add other addend */
+		cy += y < x;	/* get out carry from that add, combine */
+		res_ptr[j] = y;
+	} while (++j);
+
+	return cy;
+}
+
+/* Shift U (pointed to by UP and USIZE digits long) CNT bits to the left
+ * and store the USIZE least significant digits of the result at WP.
+ * Return the bits shifted out from the most significant digit.
+ *
+ * Argument constraints:
+ * 1. 0 < CNT < BITS_PER_MP_LIMB
+ * 2. If the result is to be written over the input, WP must be >= UP.
+ */
+
+static mpi_limb_t
+mpihelp_lshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize, unsigned int cnt)
+{
+	mpi_limb_t high_limb, low_limb;
+	unsigned sh_1, sh_2;
+	mpi_size_t i;
+	mpi_limb_t retval;
+
+	sh_1 = cnt;
+	wp += 1;
+	sh_2 = BITS_PER_MPI_LIMB - sh_1;
+	i = usize - 1;
+	low_limb = up[i];
+	retval = low_limb >> sh_2;
+	high_limb = low_limb;
+	while (--i >= 0) {
+		low_limb = up[i];
+		wp[i] = (high_limb << sh_1) | (low_limb >> sh_2);
+		high_limb = low_limb;
+	}
+	wp[i] = high_limb << sh_1;
+
+	return retval;
+}
+
+static mpi_limb_t
+mpihelp_addmul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+		 mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t cy_limb;
+	mpi_size_t j;
+	mpi_limb_t prod_high, prod_low;
+	mpi_limb_t x;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	 * the loop becomes faster.  */
+	j = -s1_size;
+	res_ptr -= j;
+	s1_ptr -= j;
+
+	cy_limb = 0;
+	do {
+		umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
+
+		prod_low += cy_limb;
+		cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high;
+
+		x = res_ptr[j];
+		prod_low = x + prod_low;
+		cy_limb += prod_low < x ? 1 : 0;
+		res_ptr[j] = prod_low;
+	} while (++j);
+	return cy_limb;
+}
+
+static mpi_limb_t
+mpihelp_sub_n(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+	      mpi_ptr_t s2_ptr, mpi_size_t size)
+{
+	mpi_limb_t x, y, cy;
+	mpi_size_t j;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	   the loop becomes faster.  */
+	j = -size;
+
+	/* Offset the base pointers to compensate for the negative indices.  */
+	s1_ptr -= j;
+	s2_ptr -= j;
+	res_ptr -= j;
+
+	cy = 0;
+	do {
+		y = s2_ptr[j];
+		x = s1_ptr[j];
+		y += cy;	/* add previous carry to subtrahend */
+		cy = y < cy;	/* get out carry from that addition */
+		y = x - y;	/* main subtract */
+		cy += y > x;	/* get out carry from the subtract, combine */
+		res_ptr[j] = y;
+	} while (++j);
+
+	return cy;
+}
+
+/****************
+ * Compare OP1_PTR/OP1_SIZE with OP2_PTR/OP2_SIZE.
+ * There are no restrictions on the relative sizes of
+ * the two arguments.
+ * Return 1 if OP1 > OP2, 0 if they are equal, and -1 if OP1 < OP2.
+ */
+static int mpihelp_cmp(mpi_ptr_t op1_ptr, mpi_ptr_t op2_ptr, mpi_size_t size)
+{
+	mpi_size_t i;
+	mpi_limb_t op1_word, op2_word;
+
+	for (i = size - 1; i >= 0; i--) {
+		op1_word = op1_ptr[i];
+		op2_word = op2_ptr[i];
+		if (op1_word != op2_word)
+			goto diff;
+	}
+	return 0;
+
+ diff:
+	/* This can *not* be simplified to
+	 *   op2_word - op2_word
+	 * since that expression might give signed overflow.  */
+	return (op1_word > op2_word) ? 1 : -1;
+}
+
+static void mpi_assign_limb_space(MPI a, mpi_ptr_t ap, unsigned nlimbs)
+{
+	mpi_free_limb_space(a->d);
+	a->d = ap;
+	a->alloced = nlimbs;
+}
+
+/* Shift U (pointed to by UP and USIZE limbs long) CNT bits to the right
+ * and store the USIZE least significant limbs of the result at WP.
+ * The bits shifted out to the right are returned.
+ *
+ * Argument constraints:
+ * 1. 0 < CNT < BITS_PER_MP_LIMB
+ * 2. If the result is to be written over the input, WP must be <= UP.
+ */
+
+static mpi_limb_t
+mpihelp_rshift(mpi_ptr_t wp, mpi_ptr_t up, mpi_size_t usize, unsigned cnt)
+{
+	mpi_limb_t high_limb, low_limb;
+	unsigned sh_1, sh_2;
+	mpi_size_t i;
+	mpi_limb_t retval;
+
+	sh_1 = cnt;
+	wp -= 1;
+	sh_2 = BITS_PER_MPI_LIMB - sh_1;
+	high_limb = up[0];
+	retval = high_limb << sh_2;
+	low_limb = high_limb;
+	for (i = 1; i < usize; i++) {
+		high_limb = up[i];
+		wp[i] = (low_limb >> sh_1) | (high_limb << sh_2);
+		low_limb = high_limb;
+	}
+	wp[i] = low_limb >> sh_1;
+
+	return retval;
+}
+
+/* Divide num (NP/NSIZE) by den (DP/DSIZE) and write
+ * the NSIZE-DSIZE least significant quotient limbs at QP
+ * and the DSIZE long remainder at NP.	If QEXTRA_LIMBS is
+ * non-zero, generate that many fraction bits and append them after the
+ * other quotient limbs.
+ * Return the most significant limb of the quotient, this is always 0 or 1.
+ *
+ * Preconditions:
+ * 0. NSIZE >= DSIZE.
+ * 1. The most significant bit of the divisor must be set.
+ * 2. QP must either not overlap with the input operands at all, or
+ *    QP + DSIZE >= NP must hold true.	(This means that it's
+ *    possible to put the quotient in the high part of NUM, right after the
+ *    remainder in NUM.
+ * 3. NSIZE >= DSIZE, even if QEXTRA_LIMBS is non-zero.
+ */
+
+static mpi_limb_t
+mpihelp_divrem(mpi_ptr_t qp, mpi_size_t qextra_limbs,
+	       mpi_ptr_t np, mpi_size_t nsize, mpi_ptr_t dp, mpi_size_t dsize)
+{
+	mpi_limb_t most_significant_q_limb = 0;
+
+	switch (dsize) {
+	case 0:
+		/* We are asked to divide by zero, so go ahead and do it!  (To make
+		   the compiler not remove this statement, return the value.)  */
+		/*
+		 * existing clients of this function have been modified
+		 * not to call it with dsize == 0, so this should not happen
+		 */
+		return 1 / dsize;
+
+	case 1:
+		{
+			mpi_size_t i;
+			mpi_limb_t n1;
+			mpi_limb_t d;
+
+			d = dp[0];
+			n1 = np[nsize - 1];
+
+			if (n1 >= d) {
+				n1 -= d;
+				most_significant_q_limb = 1;
+			}
+
+			qp += qextra_limbs;
+			for (i = nsize - 2; i >= 0; i--)
+				udiv_qrnnd(qp[i], n1, n1, np[i], d);
+			qp -= qextra_limbs;
+
+			for (i = qextra_limbs - 1; i >= 0; i--)
+				udiv_qrnnd(qp[i], n1, n1, 0, d);
+
+			np[0] = n1;
+		}
+		break;
+
+	case 2:
+		{
+			mpi_size_t i;
+			mpi_limb_t n1, n0, n2;
+			mpi_limb_t d1, d0;
+
+			np += nsize - 2;
+			d1 = dp[1];
+			d0 = dp[0];
+			n1 = np[1];
+			n0 = np[0];
+
+			if (n1 >= d1 && (n1 > d1 || n0 >= d0)) {
+				sub_ddmmss(n1, n0, n1, n0, d1, d0);
+				most_significant_q_limb = 1;
+			}
+
+			for (i = qextra_limbs + nsize - 2 - 1; i >= 0; i--) {
+				mpi_limb_t q;
+				mpi_limb_t r;
+
+				if (i >= qextra_limbs)
+					np--;
+				else
+					np[0] = 0;
+
+				if (n1 == d1) {
+					/* Q should be either 111..111 or 111..110.  Need special
+					 * treatment of this rare case as normal division would
+					 * give overflow.  */
+					q = ~(mpi_limb_t) 0;
+
+					r = n0 + d1;
+					if (r < d1) {	/* Carry in the addition? */
+						add_ssaaaa(n1, n0, r - d0,
+							   np[0], 0, d0);
+						qp[i] = q;
+						continue;
+					}
+					n1 = d0 - (d0 != 0 ? 1 : 0);
+					n0 = -d0;
+				} else {
+					udiv_qrnnd(q, r, n1, n0, d1);
+					umul_ppmm(n1, n0, d0, q);
+				}
+
+				n2 = np[0];
+ q_test:
+				if (n1 > r || (n1 == r && n0 > n2)) {
+					/* The estimated Q was too large.  */
+					q--;
+					sub_ddmmss(n1, n0, n1, n0, 0, d0);
+					r += d1;
+					if (r >= d1)	/* If not carry, test Q again.  */
+						goto q_test;
+				}
+
+				qp[i] = q;
+				sub_ddmmss(n1, n0, r, n2, n1, n0);
+			}
+			np[1] = n1;
+			np[0] = n0;
+		}
+		break;
+
+	default:
+		{
+			mpi_size_t i;
+			mpi_limb_t dX, d1, n0;
+
+			np += nsize - dsize;
+			dX = dp[dsize - 1];
+			d1 = dp[dsize - 2];
+			n0 = np[dsize - 1];
+
+			if (n0 >= dX) {
+				if (n0 > dX
+				    || mpihelp_cmp(np, dp, dsize - 1) >= 0) {
+					mpihelp_sub_n(np, np, dp, dsize);
+					n0 = np[dsize - 1];
+					most_significant_q_limb = 1;
+				}
+			}
+
+			for (i = qextra_limbs + nsize - dsize - 1; i >= 0; i--) {
+				mpi_limb_t q;
+				mpi_limb_t n1, n2;
+				mpi_limb_t cy_limb;
+
+				if (i >= qextra_limbs) {
+					np--;
+					n2 = np[dsize];
+				} else {
+					n2 = np[dsize - 1];
+					MPN_COPY_DECR(np + 1, np, dsize - 1);
+					np[0] = 0;
+				}
+
+				if (n0 == dX) {
+					/* This might over-estimate q, but it's probably not worth
+					 * the extra code here to find out.  */
+					q = ~(mpi_limb_t) 0;
+				} else {
+					mpi_limb_t r;
+
+					udiv_qrnnd(q, r, n0, np[dsize - 1], dX);
+					umul_ppmm(n1, n0, d1, q);
+
+					while (n1 > r
+					       || (n1 == r
+						   && n0 > np[dsize - 2])) {
+						q--;
+						r += dX;
+						if (r < dX)	/* I.e. "carry in previous addition?" */
+							break;
+						n1 -= n0 < d1;
+						n0 -= d1;
+					}
+				}
+
+				/* Possible optimization: We already have (q * n0) and (1 * n1)
+				 * after the calculation of q.  Taking advantage of that, we
+				 * could make this loop make two iterations less.  */
+				cy_limb = mpihelp_submul_1(np, dp, dsize, q);
+
+				if (n2 != cy_limb) {
+					mpihelp_add_n(np, np, dp, dsize);
+					q--;
+				}
+
+				qp[i] = q;
+				n0 = np[dsize - 1];
+			}
+		}
+		break;
+	}
+
+	return most_significant_q_limb;
+}
+
+static mpi_limb_t
+mpihelp_submul_1(mpi_ptr_t res_ptr, mpi_ptr_t s1_ptr,
+		 mpi_size_t s1_size, mpi_limb_t s2_limb)
+{
+	mpi_limb_t cy_limb;
+	mpi_size_t j;
+	mpi_limb_t prod_high, prod_low;
+	mpi_limb_t x;
+
+	/* The loop counter and index J goes from -SIZE to -1.  This way
+	 * the loop becomes faster.  */
+	j = -s1_size;
+	res_ptr -= j;
+	s1_ptr -= j;
+
+	cy_limb = 0;
+	do {
+		umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
+
+		prod_low += cy_limb;
+		cy_limb = (prod_low < cy_limb ? 1 : 0) + prod_high;
+
+		x = res_ptr[j];
+		prod_low = x - prod_low;
+		cy_limb += prod_low > x ? 1 : 0;
+		res_ptr[j] = prod_low;
+	} while (++j);
+
+	return cy_limb;
+}
+
+/**
+ * mpi_read_raw_data - Read a raw byte stream as a positive integer
+ * @xbuffer: The data to read
+ * @nbytes: The amount of data to read
+ */
+MPI mpi_read_raw_data(const void *xbuffer, size_t nbytes)
+{
+	const uint8_t *buffer = xbuffer;
+	int i, j;
+	unsigned nbits, nlimbs;
+	mpi_limb_t a;
+	MPI val = NULL;
+
+	while (nbytes > 0 && buffer[0] == 0) {
+		buffer++;
+		nbytes--;
+	}
+
+	nbits = nbytes * 8;
+	if (nbits > MAX_EXTERN_MPI_BITS) {
+		printk("MPI: mpi too large (%u bits)\n", nbits);
+		return NULL;
+	}
+	if (nbytes > 0)
+		nbits -= count_leading_zeros(buffer[0]) - (BITS_PER_LONG - 8);
+
+	nlimbs = DIV_ROUND_UP(nbytes, BYTES_PER_MPI_LIMB);
+	val = mpi_alloc(nlimbs);
+	if (!val)
+		return NULL;
+	val->nbits = nbits;
+	val->sign = 0;
+	val->nlimbs = nlimbs;
+
+	if (nbytes > 0) {
+		i = BYTES_PER_MPI_LIMB - nbytes % BYTES_PER_MPI_LIMB;
+		i %= BYTES_PER_MPI_LIMB;
+		for (j = nlimbs; j > 0; j--) {
+			a = 0;
+			for (; i < BYTES_PER_MPI_LIMB; i++) {
+				a <<= 8;
+				a |= *buffer++;
+			}
+			i = 0;
+			val->d[j - 1] = a;
+		}
+	}
+	return val;
+}
+
+/****************
+ * Note:  It was a bad idea to use the number of limbs to allocate
+ *	  because on a alpha the limbs are large but we normally need
+ *	  integers of n bits - So we should chnage this to bits (or bytes).
+ *
+ *	  But mpi_alloc is used in a lot of places :-)
+ */
+MPI mpi_alloc(unsigned nlimbs)
+{
+	MPI a;
+
+	a = xmalloc(struct mpi);
+	if (!a)
+		return a;
+
+	if (nlimbs) {
+		a->d = mpi_alloc_limb_space(nlimbs);
+		if (!a->d) {
+			xfree(a);
+			return NULL;
+		}
+	} else {
+		a->d = NULL;
+	}
+
+	a->alloced = nlimbs;
+	a->nlimbs = 0;
+	a->sign = 0;
+	a->flags = 0;
+	a->nbits = 0;
+	return a;
+}
+
+void mpi_free(MPI a)
+{
+	if (!a)
+		return;
+
+	if (a->flags & MPI_FLAG_PTR_ALLOC)
+		xfree(a->d);
+	else
+		mpi_free_limb_space(a->d);
+
+	if (a->flags & ~MPI_FLAG_MASK)
+		printk("invalid flag value in mpi\n");
+	xfree(a);
+}
+
+int mpi_cmp_ui(MPI u, unsigned long v)
+{
+	mpi_limb_t limb = v;
+
+	mpi_normalize(u);
+	if (!u->nlimbs && !limb)
+		return 0;
+	if (u->sign)
+		return -1;
+	if (u->nlimbs > 1)
+		return 1;
+
+	if (u->d[0] == limb)
+		return 0;
+	else if (u->d[0] > limb)
+		return 1;
+	else
+		return -1;
+}
+
+int mpi_cmp(MPI u, MPI v)
+{
+	mpi_size_t usize, vsize;
+	int cmp;
+
+	mpi_normalize(u);
+	mpi_normalize(v);
+	usize = u->nlimbs;
+	vsize = v->nlimbs;
+	if (!u->sign && v->sign)
+		return 1;
+	if (u->sign && !v->sign)
+		return -1;
+	if (usize != vsize && !u->sign && !v->sign)
+		return usize - vsize;
+	if (usize != vsize && u->sign && v->sign)
+		return vsize - usize;
+	if (!usize)
+		return 0;
+	cmp = mpihelp_cmp(u->d, v->d, usize);
+	if (u->sign)
+		return -cmp;
+	return cmp;
+}
+
+/****************
+ * Sometimes we have MSL (most significant limbs) which are 0;
+ * this is for some reasons not good, so this function removes them.
+ */
+static void mpi_normalize(MPI a)
+{
+	for (; a->nlimbs && !a->d[a->nlimbs - 1]; a->nlimbs--)
+		;
+}
+
+/****************
+ * Return the number of bits in A.
+ */
+unsigned mpi_get_nbits(MPI a)
+{
+	unsigned n;
+
+	mpi_normalize(a);
+
+	if (a->nlimbs) {
+		mpi_limb_t alimb = a->d[a->nlimbs - 1];
+		if (alimb)
+			n = count_leading_zeros(alimb);
+		else
+			n = BITS_PER_MPI_LIMB;
+		n = BITS_PER_MPI_LIMB - n + (a->nlimbs - 1) * BITS_PER_MPI_LIMB;
+	} else
+		n = 0;
+	return n;
+}
+
+int mpi_test_bit(MPI a, unsigned int n)
+{
+	unsigned int limbno, bitno;
+	mpi_limb_t limb;
+
+	limbno = n / BITS_PER_MPI_LIMB;
+	bitno  = n % BITS_PER_MPI_LIMB;
+
+	if (limbno >= a->nlimbs)
+		return 0; /* too far left: this is a 0 */
+	limb = a->d[limbno];
+	return (limb & (((mpi_limb_t)1) << bitno))? 1: 0;
+}
diff --git a/xen/crypto/Makefile b/xen/crypto/Makefile
index 64ed90ba55b1..581b6ab3c6e1 100644
--- a/xen/crypto/Makefile
+++ b/xen/crypto/Makefile
@@ -1,4 +1,5 @@
 obj-y += rijndael.o
+obj-$(CONFIG_PAYLOAD_VERIFY) += rsa.o
 obj-y += vmac.o
 
 obj-$(CONFIG_PAYLOAD_VERIFY) += builtin_payload_key.o
diff --git a/xen/crypto/rsa.c b/xen/crypto/rsa.c
new file mode 100644
index 000000000000..bd78c65f7393
--- /dev/null
+++ b/xen/crypto/rsa.c
@@ -0,0 +1,196 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR LGPL-3.0-or-later */
+/* rsa.c
+
+   The RSA publickey algorithm.
+
+   Copyright (C) 2001 Niels Möller
+
+   This file is part of GNU Nettle.
+
+   GNU Nettle is free software: you can redistribute it and/or
+   modify it under the terms of either:
+
+     * the GNU Lesser General Public License as published by the Free
+       Software Foundation; either version 3 of the License, or (at your
+       option) any later version.
+
+   or
+
+     * the GNU General Public License as published by the Free
+       Software Foundation; either version 2 of the License, or (at your
+       option) any later version.
+
+   or both in parallel, as here.
+
+   GNU Nettle is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received copies of the GNU General Public License and
+   the GNU Lesser General Public License along with this program.  If
+   not, see http://www.gnu.org/licenses/.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void rsa_public_key_init(struct rsa_public_key *key)
+{
+    key->n = NULL;
+    key->e = NULL;
+    key->size = 0;
+}
+
+/*
+ * Computes the size, in octets, of the modulo. Returns 0 if the
+ * modulo is too small to be useful, or otherwise appears invalid.
+ */
+static size_t rsa_check_size(MPI n)
+{
+    /* Round upwards */
+    size_t size;
+
+    /* Even moduli are invalid */
+    if ( mpi_test_bit(n, 0) == 0 )
+        return 0;
+
+    size = (mpi_get_nbits(n) + 7) / 8;
+
+    if ( size < RSA_MINIMUM_N_OCTETS )
+        return 0;
+
+    return size;
+}
+
+int rsa_public_key_prepare(struct rsa_public_key *key)
+{
+    if ( !key->n || !key->e || key->size )
+        return -EINVAL;
+
+    key->size = rsa_check_size(key->n);
+
+    return key->size > 0 ? 0 : -EINVAL;
+}
+
+/*
+ * Formats the PKCS#1 padding, of the form
+ *
+ *   0x00 0x01 0xff ... 0xff 0x00 id ...digest...
+ *
+ * where the 0xff ... 0xff part consists of at least 8 octets. The
+ * total size equals the octet size of n.
+ */
+static uint8_t *pkcs1_signature_prefix(unsigned int key_size, uint8_t *buffer,
+                                       unsigned int id_size, const uint8_t *id,
+                                       unsigned int digest_size)
+{
+    unsigned int j;
+
+    if ( key_size < 11 + id_size + digest_size )
+        return NULL;
+
+    j = key_size - digest_size - id_size;
+
+    memcpy(buffer + j, id, id_size);
+    buffer[0] = 0;
+    buffer[1] = 1;
+    buffer[j - 1] = 0;
+
+    ASSERT(j >= 11);
+    memset(buffer + 2, 0xff, j - 3);
+
+    return buffer + j + id_size;
+}
+
+/*
+ * From RFC 3447, Public-Key Cryptography Standards (PKCS) #1: RSA
+ * Cryptography Specifications Version 2.1.
+ *
+ *     id-sha256    OBJECT IDENTIFIER ::=
+ *       {joint-iso-itu-t(2) country(16) us(840) organization(1)
+ *         gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1}
+ */
+static const uint8_t
+sha256_prefix[] =
+{
+  /* 19 octets prefix, 32 octets hash, total 51 */
+  0x30,      49, /* SEQUENCE */
+    0x30,    13, /* SEQUENCE */
+      0x06,   9, /* OBJECT IDENTIFIER */
+        0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01,
+      0x05,   0, /* NULL */
+    0x04,    32  /* OCTET STRING */
+      /* Here comes the raw hash value */
+};
+
+static int pkcs1_rsa_sha256_encode(MPI *m, size_t key_size,
+                                   struct sha2_256_state *hash)
+{
+    uint8_t *ptr;
+    uint8_t *buf;
+
+    buf = xmalloc_bytes(key_size);
+    if ( !buf )
+        return -ENOMEM;
+
+    ptr = pkcs1_signature_prefix(key_size, buf,
+                                 sizeof(sha256_prefix), sha256_prefix,
+                                 SHA2_256_DIGEST_SIZE);
+    if ( !ptr )
+    {
+        xfree(buf);
+        return -EINVAL;
+    }
+
+    sha2_256_final(hash, ptr);
+    *m = mpi_read_raw_data(buf, key_size);
+    xfree(buf);
+    return 0;
+}
+
+static int rsa_verify(const struct rsa_public_key *key, MPI m, MPI s)
+{
+    int ret;
+    MPI m1;
+
+    /* (1) Validate 0 <= s < n */
+    if ( mpi_cmp_ui(s, 0) < 0 || mpi_cmp(s, key->n) >= 0 )
+        return -EINVAL;
+
+    m1 = mpi_alloc(key->size / BYTES_PER_MPI_LIMB);
+    if ( !m1 )
+        return -ENOMEM;
+
+    /* (2) m = s^e mod n */
+    ret = mpi_powm(m1, s, key->e, key->n);
+    if ( ret )
+        goto out;
+
+    ret = mpi_cmp(m, m1) ? -EINVAL : 0;
+
+ out:
+    mpi_free(m1);
+    return ret;
+}
+
+int rsa_sha256_verify(const struct rsa_public_key *key,
+                      struct sha2_256_state *hash, MPI s)
+{
+    int ret;
+    MPI m;
+
+    ret = pkcs1_rsa_sha256_encode(&m, key->size, hash);
+    if ( ret )
+        return ret;
+
+    ret = rsa_verify(key, m, s);
+
+    mpi_free(m);
+
+    return ret;
+}
diff --git a/xen/include/xen/mpi.h b/xen/include/xen/mpi.h
new file mode 100644
index 000000000000..56d50541d7bd
--- /dev/null
+++ b/xen/include/xen/mpi.h
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/* mpi.h  -  Multi Precision Integers
+ *        Copyright (C) 1994, 1996, 1998, 1999,
+ *                    2000, 2001 Free Software Foundation, Inc.
+ *
+ * This file is part of GNUPG.
+ *
+ * GNUPG is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * GNUPG is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ *
+ * Note: This code is heavily based on the GNU MP Library.
+ *         Actually it's the same code with only minor changes in the
+ *         way the data is stored; this is to support the abstraction
+ *         of an optional secure memory allocation which may be used
+ *         to avoid revealing of sensitive data due to paging etc.
+ *         The GNU MP Library itself is published under the LGPL;
+ *         however I decided to publish this code under the plain GPL.
+ */
+
+#ifndef XEN__MPI_H
+#define XEN__MPI_H
+
+#include 
+
+#define BYTES_PER_MPI_LIMB      (BITS_PER_LONG / 8)
+#define BITS_PER_MPI_LIMB       BITS_PER_LONG
+
+typedef unsigned long int mpi_limb_t;
+typedef signed long int mpi_limb_signed_t;
+
+struct mpi {
+    int alloced;        /* array size (# of allocated limbs) */
+    int nlimbs;         /* number of valid limbs */
+    int nbits;          /* the real number of valid bits (info only) */
+    int sign;           /* indicates a negative number */
+#define MPI_FLAG_SECURE_MEM (1 << 0)
+#define MPI_FLAG_UNUSED     (1 << 1)
+#define MPI_FLAG_PTR_ALLOC  (1 << 4)
+#define MPI_FLAG_MASK       7
+    unsigned int flags; /* bit 0: array must be allocated in secure memory space */
+                        /* bit 1: not used */
+                        /* bit 2: the limb is a pointer to some m_alloced data */
+    mpi_limb_t *d;      /* array with the limbs */
+};
+
+typedef struct mpi *MPI;
+
+MPI mpi_alloc(unsigned nlimbs);
+void mpi_free(MPI a);
+MPI mpi_read_raw_data(const void *xbuffer, size_t nbytes);
+int mpi_powm(MPI res, MPI base, MPI exp, MPI mod);
+int mpi_cmp_ui(MPI u, unsigned long v);
+int mpi_cmp(MPI u, MPI v);
+unsigned mpi_get_nbits(MPI a);
+int mpi_test_bit(MPI a, unsigned int n);
+
+#endif /* XEN__MPI_H */
diff --git a/xen/include/xen/rsa.h b/xen/include/xen/rsa.h
new file mode 100644
index 000000000000..f5436d0d12c6
--- /dev/null
+++ b/xen/include/xen/rsa.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR LGPL-3.0-or-later */
+/* rsa.h
+
+   The RSA publickey algorithm.
+
+   Copyright (C) 2001, 2002 Niels Möller
+
+   This file is part of GNU Nettle.
+
+   GNU Nettle is free software: you can redistribute it and/or
+   modify it under the terms of either:
+
+     * the GNU Lesser General Public License as published by the Free
+       Software Foundation; either version 3 of the License, or (at your
+       option) any later version.
+
+   or
+
+     * the GNU General Public License as published by the Free
+       Software Foundation; either version 2 of the License, or (at your
+       option) any later version.
+
+   or both in parallel, as here.
+
+   GNU Nettle is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received copies of the GNU General Public License and
+   the GNU Lesser General Public License along with this program.  If
+   not, see http://www.gnu.org/licenses/.
+*/
+ 
+#ifndef XEN__RSA_H
+#define XEN__RSA_H
+
+#include 
+#include 
+
+struct sha2_256_state;
+
+/*
+ * This limit is somewhat arbitrary. Technically, the smallest modulo
+ * which makes sense at all is 15 = 3*5, phi(15) = 8, size 4 bits. But
+ * for ridiculously small keys, not all odd e are possible (e.g., for
+ * 5 bits, the only possible modulo is 3*7 = 21, phi(21) = 12, and e =
+ * 3 don't work). The smallest size that makes sense with pkcs#1, and
+ * which allows RSA encryption of one byte messages, is 12 octets, 89
+ * bits.
+ */
+#define RSA_MINIMUM_N_OCTETS 12
+#define RSA_MINIMUM_N_BITS (8 * RSA_MINIMUM_N_OCTETS - 7)
+
+struct rsa_public_key
+{
+    /*
+     * Size of the modulo, in octets. This is also the size of all
+     * signatures that are created or verified with this key.
+     */
+    size_t size;
+    MPI n; /* Modulo */
+    MPI e; /* Public exponent */
+};
+
+void rsa_public_key_init(struct rsa_public_key *key);
+
+int rsa_public_key_prepare(struct rsa_public_key *key);
+
+int rsa_sha256_verify(const struct rsa_public_key *key,
+                      struct sha2_256_state *hash,
+                      MPI signature);
+
+#endif /* XEN__RSA_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 15 09:38:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:38:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985052.1371005 (Exim 4.92)
	(envelope-from )
	id 1uFV3L-0006P7-2j; Thu, 15 May 2025 09:38:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985052.1371005; Thu, 15 May 2025 09:38: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 1uFV3L-0006Oz-0B; Thu, 15 May 2025 09:38:59 +0000
Received: by outflank-mailman (input) for mailman id 985052;
 Thu, 15 May 2025 09:38:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFV3J-00064K-RB
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:38:57 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6c734429-3170-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 11:38:57 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5f4d0da2d2cso1336216a12.3
 for ; Thu, 15 May 2025 02:38:57 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad23ad2b386sm895152066b.104.2025.05.15.02.38.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 02:38: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" 
X-Inumbo-ID: 6c734429-3170-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747301937; x=1747906737; 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;
        bh=mI8pwGmu4+lpXzloXzs62CfY/4mwVbPPP3HB7j9Crbc=;
        b=LIOymE3HvUV6fV5iIeb/R+4iKaEvQjewGW5P3w5+L+sbDJxs7t/NfPpD6LCLG1dhjR
         i9zYR9s7YNnM5BBCESwp/yKdtQccmi6+aM74GQRm2XMZLWXS5XwIH/vlNnN7jC7VTLjI
         JrXQ89NfWIIxQh/jHiNc2FTfqQQkAQRNkrR4Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747301937; x=1747906737;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=mI8pwGmu4+lpXzloXzs62CfY/4mwVbPPP3HB7j9Crbc=;
        b=nobgdEIxPWPerVEi7WUkpYf91CevOhGlq7TmLb0kwgXWuRvI65/Lz2S+bYzrZF5haK
         etEeIZ6I0N0+LpphDLpp3XlRLas4LmCQu4qgHMzQ4walm/EouQceSNqnwTvOUKVRUZ+g
         9xI0NFyOM9w7oJD+dQrEvcdRyV+RkITQQ1KLwbXba9amd+E8rL4t3xitqOijP/yQ/87+
         z4HSpl86fvSGFApG9jYjOwpFR+CcY+OMG39v7S5TJ7tFQF0W3BJnC6lzGmJ0gFthbjrs
         RZqy07GWMgzuGyjCTfVvDad3IEnKSD3U0pbaP4ZT9wW3mz0Hg7/V8eedHAZ7lbicMMHU
         /4bQ==
X-Gm-Message-State: AOJu0YzTO/w5EDvE+4TmSRtB99k6N3JJTC5GUGIaHHSlJCflLzBA99c7
	LMQV/G92AfdDXydH5aVdWqobLiFh8DbsU0iA+LBMa2NgI8anS9UrhgtVXsMFHqucwQzQbp/3/Cc
	=
X-Gm-Gg: ASbGncvyt69qTOIpI0etAxKlfzVw09/hr7FEDR8ISNovwAYbjpwDhm+x7XTLFTsSCmj
	lRghvngGb6FzmhyNZ3mVLrPOtBnZdhE/p5tm8tvWZuPYyBXVzM9bFBwGW98gIbSBevbQKzlqA8L
	S237t40M4p8yokoRxhGeSX7Gtsix3Zh/Ko9bjUpuLncaN3ysaOG3PfVK+2r/ENerElvx8oifHtA
	/OxZv9Cwq8RA5AymlacxLjiO54yq/7P4ZF+Z7K2CDZcsyKAQkmRKPNUzJdvWisZEbWNNxO8I0at
	8O6twg8ZLdmOs8stRfvNjvpwKtOuEXXtw3xn7ohsH2q9ekbIair096xFnGuDOWihE4iqZ7pCt0s
	=
X-Google-Smtp-Source: AGHT+IEc0aCKX8aM831QI5j5in052DGx5TrDoOOTTvkREwyfXgYPfKZpNrkdblEGBzby2dBNg5eLVA==
X-Received: by 2002:a17:907:7ba3:b0:aca:cac8:1cf9 with SMTP id a640c23a62f3a-ad515e73b6bmr140690166b.33.1747301925861;
        Thu, 15 May 2025 02:38:45 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Kevin Lampis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Ross Lagerwall 
Subject: [PATCH v2 2/5] livepatch: Embed public key in Xen
Date: Thu, 15 May 2025 10:38:17 +0100
Message-ID: <20250515093822.659916-3-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250515093822.659916-1-ross.lagerwall@citrix.com>
References: <20250515093822.659916-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Kevin Lampis 

Make it possible to embed a public key in Xen to be used when verifying
live patch payloads. Inclusion of the public key is optional.

To avoid needing to include a DER / X.509 parser in the hypervisor, the
public key is unpacked at build time and included in a form that is
convenient for the hypervisor to consume. This is different approach
from that used by Linux which embeds the entire X.509 certificate and
builds in a parser for it.

A suitable key can be created using openssl:

openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \
    -sha256 -days 3650 -nodes \
    -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out verify_key.pem

Signed-off-by: Kevin Lampis 
Signed-off-by: Ross Lagerwall 
---

In v2:

* Split the loading part into a separate patch.
* Expect public key in object tree rather than source tree.
* Rename Kconfig symbols and others to reflect that it is used for
  verification in Xen rather than signing.
* Move extern declaration to a header.
* Move raw key data to init.rodata.

 xen/common/Kconfig          | 18 ++++++++++++++++++
 xen/crypto/Makefile         | 13 +++++++++++++
 xen/include/xen/livepatch.h |  6 ++++++
 xen/tools/extract-key.py    | 37 +++++++++++++++++++++++++++++++++++++
 4 files changed, 74 insertions(+)
 create mode 100755 xen/tools/extract-key.py

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6d43be2e6e8a..e4466db595c2 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -461,6 +461,24 @@ config LIVEPATCH
 
 	  If unsure, say Y.
 
+config PAYLOAD_VERIFY
+	bool "Verify signed LivePatch payloads"
+	depends on LIVEPATCH
+	select CRYPTO
+	help
+	  Verify signed LivePatch payloads using an RSA public key built
+	  into the Xen hypervisor. Selecting this option requires a
+	  public key in PEM format to be available for embedding during
+	  the build.
+
+config PAYLOAD_VERIFY_KEY
+	string "File name of public key used to verify payloads"
+	default "verify_key.pem"
+	depends on PAYLOAD_VERIFY
+	help
+	  The file name of an RSA public key in PEM format to be used for
+	  verifying signed LivePatch payloads.
+
 config FAST_SYMBOL_LOOKUP
 	bool "Fast symbol lookup (bigger binary)"
 	default y
diff --git a/xen/crypto/Makefile b/xen/crypto/Makefile
index db29655333a3..64ed90ba55b1 100644
--- a/xen/crypto/Makefile
+++ b/xen/crypto/Makefile
@@ -1,2 +1,15 @@
 obj-y += rijndael.o
 obj-y += vmac.o
+
+obj-$(CONFIG_PAYLOAD_VERIFY) += builtin_payload_key.o
+
+ifeq ($(CONFIG_PAYLOAD_VERIFY),y)
+key_path := $(objtree)/$(patsubst "%",%,$(CONFIG_PAYLOAD_VERIFY_KEY))
+$(obj)/builtin_payload_key.bin: $(key_path) $(srctree)/tools/extract-key.py
+	$(srctree)/tools/extract-key.py < $< > $@.new
+	$(call move-if-changed,$@.new,$@)
+
+$(obj)/builtin_payload_key.S: BINFILE_FLAGS := -i
+$(obj)/builtin_payload_key.S: $(srctree)/tools/binfile $(obj)/builtin_payload_key.bin FORCE
+	$(call if_changed,binfile,$(obj)/builtin_payload_key.bin xen_livepatch_key_data)
+endif
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index d074a5bebecc..0265f1fce057 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -18,6 +18,7 @@ struct xen_sysctl_livepatch_op;
 
 #ifdef CONFIG_LIVEPATCH
 
+#include 
 #include 
 
 /*
@@ -143,6 +144,11 @@ struct payload;
 int revert_payload(struct payload *data);
 void revert_payload_tail(struct payload *data);
 
+#ifdef CONFIG_PAYLOAD_VERIFY
+/* The public key data contained with Xen used to verify payload signatures. */
+extern const uint8_t __initconst xen_livepatch_key_data[];
+#endif
+
 #else
 
 /*
diff --git a/xen/tools/extract-key.py b/xen/tools/extract-key.py
new file mode 100755
index 000000000000..2980264b757d
--- /dev/null
+++ b/xen/tools/extract-key.py
@@ -0,0 +1,37 @@
+#!/usr/bin/env python3
+
+# SPDX-License-Identifier: GPL-2.0
+
+import binascii
+import struct
+import sys
+import subprocess
+import re
+
+# Decode a certificate into a format suitable for embedding in Xen.
+
+out = subprocess.check_output(['openssl', 'rsa', '-pubin', '-inform', 'PEM',
+                               '-noout', '-text'], stdin=sys.stdin,
+                               universal_newlines=True)
+combined = ''
+for line in out.split('\n'):
+    line = line.rstrip()
+    if line.startswith('    '):
+        combined += line.strip().replace(':', '')
+    match = re.match(r'Exponent: .* \(0x(.*)\)', line)
+    if match:
+        e = match.group(1)
+
+n = combined.lstrip('0')
+if len(n) % 2 == 1:
+    n = '0' + n
+n = binascii.unhexlify(n)
+e = e.lstrip('0')
+if len(e) % 2 == 1:
+    e = '0' + e
+e = binascii.unhexlify(e)
+
+sys.stdout.buffer.write(struct.pack('I', len(n)))
+sys.stdout.buffer.write(n)
+sys.stdout.buffer.write(struct.pack('I', len(e)))
+sys.stdout.buffer.write(e)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 15 09:38:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:38:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985053.1371012 (Exim 4.92)
	(envelope-from )
	id 1uFV3L-0006SQ-GW; Thu, 15 May 2025 09:38:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985053.1371012; Thu, 15 May 2025 09:38: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 1uFV3L-0006RN-7J; Thu, 15 May 2025 09:38:59 +0000
Received: by outflank-mailman (input) for mailman id 985053;
 Thu, 15 May 2025 09:38:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFV3K-0005Wo-9m
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:38:58 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6c0137ca-3170-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 11:38:56 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad51ba0af48so58362966b.0
 for ; Thu, 15 May 2025 02:38:56 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad23ad2b386sm895152066b.104.2025.05.15.02.38.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 02:38:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6c0137ca-3170-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747301936; x=1747906736; 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;
        bh=okbZGT2Jgvj2XKdLpr7X/vM9N54wOcCp6yj7ItvaHiA=;
        b=U4RgSM7f7+/6g1bNjKKaUMxvJBHiT/0ygXUFiu4B4gXPpNUmFhJetQjoyQ03wOofIa
         rJ2rrpOHkh7h9RD58cSb0kqBtRX74GR85Rd2+JBC9nQ/yrJfPFDfnGXNV0zeBof3sHf7
         YvHl1Nr4nmhlIxaObqsUMPjuY+EsXiyRND1Kg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747301936; x=1747906736;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=okbZGT2Jgvj2XKdLpr7X/vM9N54wOcCp6yj7ItvaHiA=;
        b=ZAXSg25WcqFHtlOhVmGN1dSFTMbGl6DmcHMxsowTi02aEo56NhFL3yWes/Sq7SdmZ3
         4oDLyRFUAPSxoeOxrqNDrEqcU6GZF13475YRaYaz0F5vGq02ZYUUleK99F4Qr02wG1Qa
         +zidlrPNnJADWYSeRrq2Rk6v1Z6I/iyCFGt/s7pqDHP9LVJL7H3pmzNPrf+N4cdVh/8N
         CzODUt+SEa2IR/inzUQ93k0lXepuuuNd+dMdPRYYnDDsXuZr5VBDX5S8ppBI/Qy4LWV7
         tUXekCgAZW6XKWA6diRGYXjKVw62tsj7KhH9dmDKkaJxN290MIDeQRg3435rIsKzDF7o
         GZdQ==
X-Gm-Message-State: AOJu0YxyB0d2az7W4XftelZB0/mU3gRl5bRqDSIyKp/PnGw+Mk3UeEOJ
	sUFHJsqMY7Otdoie/Y6YaCZs43F3OTX/5o+Fm+Y06GLDRBF/PeO7aJsoyK0e3uDWvATC9FEGqTo
	E6Q8=
X-Gm-Gg: ASbGncs10YgBLm977riUgL7UbSW3QWkBmNVouPRoq1qardJHzN625lOLOgpdzq8sjjo
	Mx3ImkHCcP5Tadv9Zvq4qk5Z0CtsaF/m6OYtJpr6uMzlgT7KykmJTAKXZmUAWwnAUDs1K/isNL/
	JWfu9dnlee9+7bUVDCFizcnAGEXOACBtzqwFsv3WZF+c5c2paX25wNkUVq6kQ4Ro0vCVJv6HmTI
	lv2rtD0Er/koTwR0Wo8WsDfuZG8P0dbQ6AB5EQWmhcWmga/79QtAUUhVFA80Hn2ouANhBa+pwVX
	yBKePIQ1VS3yE4wYJXU0m8BfcIaIdKrennma5SGCnTV/LqK7551BmhAUr3RebTNrZxNwG4W+YZo
	=
X-Google-Smtp-Source: AGHT+IFctHIRcQo3bF2A5ibn3Ijwsfd3cMMmC3cFjPJqYXvmIPs9A36jyg0GXBexdQxZnyE3pCSXIg==
X-Received: by 2002:a17:907:7289:b0:ad2:3fec:7e99 with SMTP id a640c23a62f3a-ad50f7c1bcemr239810966b.21.1747301935991;
        Thu, 15 May 2025 02:38:55 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 4/5] livepatch: Load built-in key during boot
Date: Thu, 15 May 2025 10:38:19 +0100
Message-ID: <20250515093822.659916-5-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250515093822.659916-1-ross.lagerwall@citrix.com>
References: <20250515093822.659916-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Parse the raw data of the embedded RSA key into a form that can be later
used for verifying live patch signatures.

Signed-off-by: Ross Lagerwall 
---

In v2:

* Split out from "livepatch: Embed public key in Xen"

 xen/common/livepatch.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index be9b7e367553..bc158971b4bf 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -73,6 +75,10 @@ static struct livepatch_work livepatch_work;
 static DEFINE_PER_CPU(bool, work_to_do);
 static DEFINE_PER_CPU(struct tasklet, livepatch_tasklet);
 
+#ifdef CONFIG_PAYLOAD_VERIFY
+static struct rsa_public_key builtin_payload_key;
+#endif
+
 static int get_name(const struct xen_livepatch_name *name, char *n)
 {
     if ( !name->size || name->size > XEN_LIVEPATCH_NAME_SIZE )
@@ -2287,6 +2293,31 @@ static void cf_check livepatch_printall(unsigned char key)
     spin_unlock(&payload_lock);
 }
 
+static int __init load_builtin_payload_key(void)
+{
+#ifdef CONFIG_PAYLOAD_VERIFY
+    const uint8_t *ptr;
+    uint32_t len;
+
+    rsa_public_key_init(&builtin_payload_key);
+
+    ptr = xen_livepatch_key_data;
+
+    memcpy(&len, ptr, sizeof(len));
+    ptr += sizeof(len);
+    builtin_payload_key.n = mpi_read_raw_data(ptr, len);
+    ptr += len;
+
+    memcpy(&len, ptr, sizeof(len));
+    ptr += sizeof(len);
+    builtin_payload_key.e = mpi_read_raw_data(ptr, len);
+
+    return rsa_public_key_prepare(&builtin_payload_key);
+#else
+    return 0;
+#endif
+}
+
 static int cf_check cpu_callback(
     struct notifier_block *nfb, unsigned long action, void *hcpu)
 {
@@ -2305,6 +2336,11 @@ static struct notifier_block cpu_nfb = {
 static int __init cf_check livepatch_init(void)
 {
     unsigned int cpu;
+    int err;
+
+    err = load_builtin_payload_key();
+    if (err)
+        return err;
 
     for_each_online_cpu ( cpu )
     {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 15 09:39:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:39:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985056.1371025 (Exim 4.92)
	(envelope-from )
	id 1uFV3Q-00076L-L2; Thu, 15 May 2025 09:39:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985056.1371025; Thu, 15 May 2025 09:39: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 1uFV3Q-00076A-HP; Thu, 15 May 2025 09:39:04 +0000
Received: by outflank-mailman (input) for mailman id 985056;
 Thu, 15 May 2025 09:39:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFV3O-0005Wo-MK
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:39:02 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6e841e5f-3170-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 11:39:01 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-acbb85ce788so145398266b.3
 for ; Thu, 15 May 2025 02:39:01 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad23ad2b386sm895152066b.104.2025.05.15.02.38.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 02:38: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" 
X-Inumbo-ID: 6e841e5f-3170-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747301940; x=1747906740; 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;
        bh=aRxfQHGUaM2bVrY5MoSx7hsp7Lwa7FAJBo/pdIXsvMI=;
        b=u0bVDa5VNiH0A9KZyo8YuyIecbJjlB93AIk/WLr/NCGwZBo7TImnHi5/MycaAifznK
         AHd04iGYTL+RhZp2Wef46I0AcyqnDYCZhtgit+mn+aV7Ia4UXMYQguxh0eciPZQ06ANE
         ofsyI/ZU1U1ZQDV9pHUF1URwhmPLbyWhcCdgE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747301940; x=1747906740;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=aRxfQHGUaM2bVrY5MoSx7hsp7Lwa7FAJBo/pdIXsvMI=;
        b=KV14lyDZKb98oaGA0iiwENP/+KcZip0OGepYClkm3+ZW2jbxBRh/sa8+p1IjgzsvcR
         e+u5UIs8Jyfeac38rRwazUR0JSPnlY9pqJfGir/im7XnsF7h9qhBlEh3jEyNoewp4peT
         kxiVBBZQCoMxOfcO/gES+EZ8RzC/6/AunonKTwpmStj4PNlHOiJty9rcYUWN0KyqTjVM
         vzbo2avz6cs6ffI9uoPO+MpeOKum6jiuIWQP918EP7L+7lSbmFJaP49Ie6LmEhxCSVcT
         J8B001Znbe7IPuCf996HB3EUvbrZmkpS0p93cnIfOkmtyLknTXfejGrji9ViMFMH+/eh
         koZQ==
X-Gm-Message-State: AOJu0YyewOmI6KP2AsmUcIsRJbV3y1U6QSwvjS1msa1BM/bD95oiKvKV
	skl4tfkXG3O77rWNhb+Z3IUpc7HG2ghKP1BFoLK/IvYpd5+uQH2lEo4CzOZGvV7s6KzNu8C3FXQ
	=
X-Gm-Gg: ASbGncuw72VRhWu2l5gDv1U3Dfa0iZX7y9458MXFqPR94+hDGWr0Ru/An6QKYPddDQl
	YadIXwkPZUGohiI34B0bITIxCJd7d34Vu0I6gKSVi20AQTgPbUleFyR+Pn3anFnCoy7zkWhq1Q+
	FdwVI2rwEIBLrpIJp7I1IN8lD7skZZBSEWD897ZMVeDd0Kbyy9m4BYG9byUHgvJb2CMaRyNGwZ6
	60roG916XBA3zQ6vSbh4n3goUy3bC1gt4sHxQ3yg972UT+IYfEyxLM9wIaT/MAfkS6WDiADS+E2
	ddbrJFTOmK9cn9a/3eiWN4icsfPuiSC8ncOnG/xXsDwEn/qim1cOicxgWGaJlICDKnARUXwsP0c
	=
X-Google-Smtp-Source: AGHT+IHgmGS6dPuTLipWb6cw/6Fs3w9jLG9+8Qa0x10kxJOwpfb5vJN4OT3sfkoIIZeGgwmJFmtvCw==
X-Received: by 2002:a17:907:86a1:b0:ad2:4374:84a2 with SMTP id a640c23a62f3a-ad4f70f61eamr636239566b.6.1747301940038;
        Thu, 15 May 2025 02:39:00 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Jennifer Herbert ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Ross Lagerwall 
Subject: [PATCH v2 5/5] livepatch: Verify livepatch signatures
Date: Thu, 15 May 2025 10:38:20 +0100
Message-ID: <20250515093822.659916-6-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250515093822.659916-1-ross.lagerwall@citrix.com>
References: <20250515093822.659916-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Jennifer Herbert 

Verify livepatch signatures against the embedded public key in Xen.
Failing to verify does not prevent the livepatch from being loaded.
In future, this will be changed for certain cases (e.g. when Secure Boot
is enabled).

Signed-off-by: Jennifer Herbert 
Signed-off-by: Ross Lagerwall 
---

In v2:

* Adjust according to design tweaks.

 xen/common/livepatch.c          | 109 ++++++++++++++++++++++++++++++++
 xen/common/livepatch_elf.c      |  55 ++++++++++++++++
 xen/include/xen/livepatch.h     |  10 +++
 xen/include/xen/livepatch_elf.h |  18 ++++++
 4 files changed, 192 insertions(+)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index bc158971b4bf..7b7a2434e5c3 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -79,6 +80,9 @@ static DEFINE_PER_CPU(struct tasklet, livepatch_tasklet);
 static struct rsa_public_key builtin_payload_key;
 #endif
 
+static int check_signature(const struct livepatch_elf *elf, void *raw,
+                           size_t size);
+
 static int get_name(const struct xen_livepatch_name *name, char *n)
 {
     if ( !name->size || name->size > XEN_LIVEPATCH_NAME_SIZE )
@@ -1162,6 +1166,8 @@ static int load_payload_data(struct payload *payload, void *raw, size_t len)
     if ( rc )
        goto out;
 
+    check_signature(&elf, raw, len);
+
     rc = move_payload(payload, &elf);
     if ( rc )
         goto out;
@@ -1202,6 +1208,109 @@ static int load_payload_data(struct payload *payload, void *raw, size_t len)
     return rc;
 }
 
+#ifdef CONFIG_PAYLOAD_VERIFY
+#define MAX_SIG_NOTE_SIZE 1024
+
+static int check_rsa_sha256_signature(void *data, size_t datalen,
+                                      void *sig, uint32_t siglen)
+{
+    struct sha2_256_state hash;
+    MPI s;
+    int rc;
+
+    s = mpi_read_raw_data(sig, siglen);
+    if ( !s )
+    {
+        printk(XENLOG_ERR LIVEPATCH "Failed to mpi_read_raw_data\n");
+        return -ENOMEM;
+    }
+
+    sha2_256_init(&hash);
+    sha2_256_update(&hash, data, datalen);
+
+    rc = rsa_sha256_verify(&builtin_payload_key, &hash, s);
+    if ( rc )
+        printk(XENLOG_ERR LIVEPATCH "rsa_sha256_verify failed: %d\n", rc);
+
+    mpi_free(s);
+
+    return rc;
+}
+
+static int check_signature(const struct livepatch_elf *elf, void *raw,
+                           size_t size)
+{
+    static const char notename[] = "Xen";
+    void *sig;
+    livepatch_elf_note note;
+    int rc;
+
+    rc = livepatch_elf_note_by_names(elf, ELF_XEN_SIGNATURE, notename, -1,
+                                     ¬e);
+    if ( rc )
+    {
+        dprintk(XENLOG_DEBUG, LIVEPATCH "%s: Signature not present\n",
+                elf->name);
+        return rc;
+    }
+
+    /* We expect only one signature, find a second is an error! */
+    rc = livepatch_elf_next_note_by_name(notename, -1, ¬e);
+    if ( rc != -ENOENT )
+    {
+        if ( rc )
+        {
+            printk(XENLOG_ERR LIVEPATCH
+                   "Error while checking for notes! err = %d\n", rc);
+            return rc;
+        }
+        else
+        {
+            printk(XENLOG_ERR LIVEPATCH
+                   "Error, found second signature note! There can be only one!\n");
+            return -EINVAL;
+        }
+    }
+
+    if ( SIGNATURE_VERSION(note.type) != LIVEPATCH_SIGNATURE_VERSION ||
+         SIGNATURE_ALGORITHM(note.type) != SIGNATURE_ALGORITHM_RSA ||
+         SIGNATURE_HASH(note.type) != SIGNATURE_HASH_SHA256 )
+    {
+        printk(XENLOG_ERR LIVEPATCH
+               "Unsupported signature type: v:%u, a:%u, h:%u\n",
+               SIGNATURE_VERSION(note.type), SIGNATURE_ALGORITHM(note.type),
+               SIGNATURE_HASH(note.type));
+        return -EINVAL;
+    }
+
+    if ( note.size == 0 || note.size >= MAX_SIG_NOTE_SIZE )
+    {
+        printk(XENLOG_ERR LIVEPATCH "Invalid signature note size: %u\n",
+               note.size);
+        return -EINVAL;
+    }
+
+    sig = xmalloc_bytes(note.size);
+    if ( !sig )
+        return -ENOMEM;
+
+    memcpy(sig, note.data, note.size);
+
+    /* Remove signature from data, as can't be verified with it. */
+    memset((void *)note.data, 0, note.size);
+    rc = check_rsa_sha256_signature(raw, size, sig, note.size);
+
+    xfree(sig);
+    return rc;
+}
+#else
+static int check_signature(const struct livepatch_elf *elf, void *raw,
+                           size_t size)
+{
+    return -EINVAL;
+}
+#endif
+
 static int livepatch_upload(struct xen_sysctl_livepatch_upload *upload)
 {
     struct payload *data, *found;
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index 25ce1bd5a0ad..b27c4524611d 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -23,6 +23,61 @@ livepatch_elf_sec_by_name(const struct livepatch_elf *elf,
     return NULL;
 }
 
+int livepatch_elf_note_by_names(const struct livepatch_elf *elf,
+                                const char *sec_name, const char *note_name,
+                                const unsigned int type,
+                                livepatch_elf_note *note)
+{
+     const struct livepatch_elf_sec *sec = livepatch_elf_sec_by_name(elf,
+                                                                     sec_name);
+     if ( !sec )
+           return -ENOENT;
+
+     note->end = sec->addr + sec->sec->sh_size;
+     note->next = sec->addr;
+
+     return livepatch_elf_next_note_by_name(note_name, type, note);
+}
+
+int livepatch_elf_next_note_by_name(const char *note_name,
+                                    const unsigned int type,
+                                    livepatch_elf_note *note)
+{
+     const Elf_Note *pkd_note = note->next;
+     size_t notenamelen = strlen(note_name) + 1;
+     size_t note_hd_size;
+     size_t note_size;
+     size_t remaining;
+
+     while ( (void *)pkd_note < note->end )
+     {
+
+         remaining = note->end - (void *)pkd_note;
+         if ( remaining < sizeof(livepatch_elf_note) )
+             return -EINVAL;
+
+         note_hd_size = sizeof(Elf_Note) + ((pkd_note->namesz + 3) & ~0x3);
+         note_size = note_hd_size + ((pkd_note->descsz + 3) & ~0x3);
+         if ( remaining < note_size )
+             return -EINVAL;
+
+         if ( notenamelen == pkd_note->namesz &&
+              !memcmp(note_name, (const void *) pkd_note + sizeof(Elf_Note),
+                      notenamelen) &&
+              (type == -1 || pkd_note->type == type) )
+         {
+             note->size = pkd_note->descsz;
+             note->type = pkd_note->type;
+             note->data = (void *)pkd_note + note_hd_size;
+             note->next = (void *)pkd_note + note_size;
+             return 0;
+         }
+         pkd_note = (void *)pkd_note + note_size;
+     }
+
+     return -ENOENT;
+}
+
 static int elf_verify_strtab(const struct livepatch_elf_sec *sec)
 {
     const Elf_Shdr *s;
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 0265f1fce057..a06be3ab61bc 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -39,6 +39,7 @@ struct xen_sysctl_livepatch_op;
 #define ELF_LIVEPATCH_DEPENDS     ".livepatch.depends"
 #define ELF_LIVEPATCH_XEN_DEPENDS ".livepatch.xen_depends"
 #define ELF_BUILD_ID_NOTE         ".note.gnu.build-id"
+#define ELF_XEN_SIGNATURE         ".note.Xen.signature"
 #define ELF_LIVEPATCH_LOAD_HOOKS      ".livepatch.hooks.load"
 #define ELF_LIVEPATCH_UNLOAD_HOOKS    ".livepatch.hooks.unload"
 #define ELF_LIVEPATCH_PREAPPLY_HOOK   ".livepatch.hooks.preapply"
@@ -50,6 +51,15 @@ struct xen_sysctl_livepatch_op;
 /* Arbitrary limit for payload size and .bss section size. */
 #define LIVEPATCH_MAX_SIZE     MB(2)
 
+#define SIGNATURE_VERSION(type) ((type) & 0xffff)
+#define LIVEPATCH_SIGNATURE_VERSION 1
+
+#define SIGNATURE_ALGORITHM(type) (((type) >> 16) & 0xff)
+#define SIGNATURE_ALGORITHM_RSA 0
+
+#define SIGNATURE_HASH(type) (((type) >> 24) & 0xff)
+#define SIGNATURE_HASH_SHA256 0
+
 struct livepatch_symbol {
     const char *name;
     unsigned long value;
diff --git a/xen/include/xen/livepatch_elf.h b/xen/include/xen/livepatch_elf.h
index 842111e14518..04611bac410e 100644
--- a/xen/include/xen/livepatch_elf.h
+++ b/xen/include/xen/livepatch_elf.h
@@ -39,6 +39,16 @@ struct livepatch_elf {
     unsigned int symtab_idx;
 };
 
+typedef struct {
+    uint32_t size;                       /* Note size */
+    uint32_t type;                       /* Note type */
+    const void *data;                    /* Pointer to note */
+
+    /* Private */
+    const Elf_Note *next;
+    const void *end;
+} livepatch_elf_note;
+
 const struct livepatch_elf_sec *
 livepatch_elf_sec_by_name(const struct livepatch_elf *elf,
                           const char *name);
@@ -48,6 +58,14 @@ void livepatch_elf_free(struct livepatch_elf *elf);
 int livepatch_elf_resolve_symbols(struct livepatch_elf *elf);
 int livepatch_elf_perform_relocs(struct livepatch_elf *elf);
 
+int livepatch_elf_note_by_names(const struct livepatch_elf *elf,
+                                const char *sec_name, const char *note_name,
+                                const unsigned int type,
+                                livepatch_elf_note *note);
+int livepatch_elf_next_note_by_name(const char *note_name,
+                                    const unsigned int type,
+                                    livepatch_elf_note *note);
+
 static inline bool livepatch_elf_ignore_section(const Elf_Shdr *sec)
 {
     return !(sec->sh_flags & SHF_ALLOC);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 15 09:44:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:44:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985100.1371034 (Exim 4.92)
	(envelope-from )
	id 1uFV8h-0001gD-8X; Thu, 15 May 2025 09:44:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985100.1371034; Thu, 15 May 2025 09: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 1uFV8h-0001g6-5V; Thu, 15 May 2025 09:44:31 +0000
Received: by outflank-mailman (input) for mailman id 985100;
 Thu, 15 May 2025 09:44:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFV8f-0001g0-CS
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:44:29 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 316f2d77-3171-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 11:44:28 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5f62d3ed994so1424045a12.2
 for ; Thu, 15 May 2025 02:44: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
 4fb4d7f45d1cf-5fc9d700e7csm9901963a12.64.2025.05.15.02.44.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 02:44: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" 
X-Inumbo-ID: 316f2d77-3171-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747302267; x=1747907067; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XnaLqIzvB2VepRjJNZ921o6jCIyEtyXOvZEYuyCEd6I=;
        b=Nz9bH4hSSH65NyXfHM4Ua6OQvfy4kPGi5ofxMb1bCKPXV/3EKN7XFalQaCPEUed1V0
         AZBUBRjslBkQ1wb5XsCKYozKAZA9dpygM00wyOmRqugE+uRtsB7KqLJDhjQAbNGv9mce
         66CO2mDqbzl3cU8rAKzcVUtMrxPv8WaMJcrj781nMQSbB36RjlQetj43nqHRaFUmi7H/
         RGPBkl6+PMKDUrJpBdYLBxWSDgVCVoDc1/ba6tU6utTD8qS7BZuzkCJlbtrZfyRmqPxU
         60/slFt7k0oxAxLLQ7BrWCqCpONRAvMTuCLxbgKHXeup3+gNDwTIHRX+VlGcog4CHEHp
         GHTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747302267; x=1747907067;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XnaLqIzvB2VepRjJNZ921o6jCIyEtyXOvZEYuyCEd6I=;
        b=uuGbM1Co9ZmbqQrOsyoLfD3oNzWHVGBDl6LmRlaWPt3YZEHyOqsDnDqUoInEA0J+/p
         +SoHmFJypkrHQnavmO2Z7wMUKq2E+c5FpiXYeyFTgsF3QU53mHS+XxhTEUqJmRWOKS0k
         /Jr19uy8FlLH4ASGh8THEJ1D1HLxE+/m+divPAKKfC21l6g/7EM6vY/6RT5qy2x92Oky
         anV8vkFSZSdfHPk6uegxAiRodZW8xDxG+/BJNyeLq2MuapNxNQCQhQEEMyjLXbLdyIqZ
         oiLBfgm32iwJPc37B8e43GzSi+S1PSEJBUBNQz+AUCM3abHVQu8hRe2stNGSmdl7S1pV
         aD1w==
X-Forwarded-Encrypted: i=1; AJvYcCUv5X3ajsWWWdtofWrsh7/aKOSJn6H1T/hg7cgT2tLxehldLp6shFHELSlEGsINyVZlBO8SILFUuyo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwjlbGRvh1tj8tfmM6qkkhQwsk92OqGgPsqPPgAx2KG0JEYdVaZ
	vo882Z9Wf24vJcaVxR3ljNsPn43+E8yp4eM1ThsIQnvf7Oh/WjseKAq5K240vg==
X-Gm-Gg: ASbGnct5XXXffidrFZ5G3r2N4s1mpu/gNiN8moKmqa3dVcbJO0dpsQdoNvomSrQpFx0
	EIPkXgpqr5BrKh+Z/sV/cmNvdzhbTjki1NWS2uRUEwnjhZ1OyHfp2RKHSRp2E4xkRpJCMQO/s1V
	rCHmREM98F8h3bXXv60Qr+3XinVuw7+LNknJAlgl1aFvl4EVzIrLl+NGOjk1r3e9kEv6j+9FZxu
	MUv4tp/m7iEYCZ2BJIyvhPZtJ4gkhvnKmlXKeIjfZgquEl1najoKg5J0aLmZkIsmxlNPnemTlY9
	CeoXDKJKRs0YRq2SdBsxn7vnWheujwGHecGM2IBtgZ1Xtw6AT4guoztQcN5E4vPDTpkn5fizOM8
	J1gPUR6/3XJ0lHzM/K52suaOm1vwvbNWjhRyf
X-Google-Smtp-Source: AGHT+IHIEyqVQ02tIp0rP3KTcCckfA4od3Hg57J4f/Z0Rkvp3UTfRi0HWsLPb48Q90jV66fhXH6seA==
X-Received: by 2002:a05:6402:d0e:b0:5fb:206f:784e with SMTP id 4fb4d7f45d1cf-5ff988a1ed8mr5121327a12.9.1747302267390;
        Thu, 15 May 2025 02:44:27 -0700 (PDT)
Message-ID: 
Date: Thu, 15 May 2025 11:44:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 13/16] xen/riscv: implementation of aplic and imsic
 operations
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <37d309520a0adb8bb3f4e51a985a2d56b669ba9e.1746530883.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: <37d309520a0adb8bb3f4e51a985a2d56b669ba9e.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/aplic-priv.h
> +++ b/xen/arch/riscv/aplic-priv.h
> @@ -14,6 +14,7 @@
>  #ifndef ASM__RISCV_PRIV_APLIC_H
>  #define ASM__RISCV_PRIV_APLIC_H
>  
> +#include 
>  #include 
>  
>  #include 
> @@ -27,6 +28,9 @@ struct aplic_priv {
>      /* registers */
>      volatile struct aplic_regs *regs;
>  
> +    /* lock */
> +    spinlock_t lock;

Nit: I don't see much value in such entirely redundant comments. Useful
contents might be to say what the lock actually is intended to guard.

> @@ -119,9 +121,118 @@ static int __init cf_check aplic_init(void)
>      return 0;
>  }
>  
> +static void aplic_irq_enable(struct irq_desc *desc)
> +{
> +    unsigned long flags;
> +
> +    /*
> +     * TODO: Currently, APLIC is supported only with MSI interrupts.
> +     *       If APLIC without MSI interrupts is required in the future,
> +     *       this function will need to be updated accordingly.
> +     */
> +    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
> +
> +    ASSERT(spin_is_locked(&desc->lock));

Iirc I said so before: This being an IRQ-safe lock, ...

> +    spin_lock_irqsave(&aplic.lock, flags);

... there's no need to use spin_lock_irqsave() here; plain spin_lock()
will do (and avoid the need for the local variable). Same elsewhere,
obviously.

> +static void 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;
> +
> +    /*
> +     * TODO: Currently, APLIC is supported only with MSI interrupts.
> +     *       If APLIC without MSI interrupts is required in the future,
> +     *       this function will need to be updated accordingly.
> +     */
> +    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
> +
> +    ASSERT(!cpumask_empty(mask));
> +
> +    cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask));
> +    hhxw = imsic->group_index_bits;
> +    lhxw = imsic->hart_index_bits;
> +    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) ;
> +
> +    spin_lock(&aplic.lock);
> +
> +    writel(value, &aplic.regs->target[desc->irq - 1]);
> +
> +    spin_unlock(&aplic.lock);

Hmm, interesting, here you use the plain functions, but there's no
assertion as to desc->lock being held. Such aspects would better be
consistent throughout all hooks.

> @@ -159,6 +270,8 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
>  
>      dt_irq_xlate = aplic_irq_xlate;
>  
> +    spin_lock_init(&aplic.lock);

Can't you have the struct field have a suitable initializer?

> +static void imsic_local_eix_update(unsigned long base_id, unsigned long num_id,
> +                                   bool pend, bool val)
> +{
> +    unsigned long id = base_id, last_id = base_id + num_id;
> +
> +    while ( id < last_id )
> +    {
> +        unsigned long isel, ireg;
> +        unsigned long start_id = id & (__riscv_xlen - 1);
> +        unsigned long chunk = __riscv_xlen - start_id;
> +        unsigned long count = (last_id - id < chunk) ? last_id - id : chunk;
> +
> +        isel = id / __riscv_xlen;
> +        isel *= __riscv_xlen / IMSIC_EIPx_BITS;
> +        isel += pend ? IMSIC_EIP0 : IMSIC_EIE0;
> +
> +        ireg = GENMASK(start_id + count - 1, start_id);
> +
> +        id += count;
> +
> +        if ( val )
> +            imsic_csr_set(isel, ireg);
> +        else
> +            imsic_csr_clear(isel, ireg);
> +    }
> +}
> +
> +void imsic_irq_enable(unsigned int irq)
> +{
> +    unsigned long flags;
> +
> +    spin_lock_irqsave(&imsic_cfg.lock, flags);
> +    /*
> +     * There is no irq - 1 here (look at aplic_set_irq_type()) because:
> +     * From the spec:
> +     *   When an interrupt file supports distinct interrupt identities,
> +     *   valid identity numbers are between 1 and inclusive. The identity
> +     *   numbers within this range are said to be implemented by the interrupt
> +     *   file; numbers outside this range are not implemented. The number zero
> +     *   is never a valid interrupt identity.
> +     *   ...
> +     *   Bit positions in a valid eiek register that don’t correspond to a
> +     *   supported interrupt identity (such as bit 0 of eie0) are read-only zeros.
> +     *
> +     * So in EIx registers interrupt i corresponds to bit i in comparison wiht
> +     * APLIC's sourcecfg which starts from 0. (l)

What's this 'l' in parentheses here to indicate?

> +     */
> +    imsic_local_eix_update(irq, 1, false, true);
> +    spin_unlock_irqrestore(&imsic_cfg.lock, flags);
> +}
> +
> +void imsic_irq_disable(unsigned int irq)
> +{
> +    unsigned long flags;
> +
> +    spin_lock_irqsave(&imsic_cfg.lock, flags);
> +    imsic_local_eix_update(irq, 1, false, false);
> +    spin_unlock_irqrestore(&imsic_cfg.lock, flags);
> +}

The sole caller of the function has doubly turned off IRQs already; perhaps
no need to it a 3rd time, unless other callers are to appear? Same for
imsic_irq_enable() as it looks.

> @@ -274,6 +373,11 @@ int __init imsic_init(const struct dt_device_node *node)
>          goto imsic_init_err;
>      }
>  
> +    spin_lock_init(&imsic_cfg.lock);

Again - suitable initializer for the field instead?

> --- a/xen/arch/riscv/include/asm/aplic.h
> +++ b/xen/arch/riscv/include/asm/aplic.h
> @@ -1,7 +1,7 @@
>  /* SPDX-License-Identifier: MIT */
>  
>  /*
> - * xen/arch/riscv/asm/include/aplic.h
> + * xen/arch/riscv/aplic.h

Please get this right when/where the file is introduced.

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 09:54:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:54:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985113.1371044 (Exim 4.92)
	(envelope-from )
	id 1uFVIN-0003oH-89; Thu, 15 May 2025 09:54:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985113.1371044; Thu, 15 May 2025 09: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 1uFVIN-0003oA-57; Thu, 15 May 2025 09:54:31 +0000
Received: by outflank-mailman (input) for mailman id 985113;
 Thu, 15 May 2025 09:54:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFVIM-0003o4-7q
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:54:30 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 957a4238-3172-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 11:54:25 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-acb39c45b4eso107232666b.1
 for ; Thu, 15 May 2025 02:54: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
 a640c23a62f3a-ad22562ed61sm987136966b.31.2025.05.15.02.54.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 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" 
X-Inumbo-ID: 957a4238-3172-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747302865; x=1747907665; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Zk560i6SJnRty0xcdm0Tr4hUCdi0a1YYgcQMFFm97ys=;
        b=NvKocEO9+xOCO1gWlgE6oLKowmXLZ5iimcInIShWlqE7EoeT3tbCAC2L7PHrTmcZAo
         p/5eXvU8jnUkJolH9lujPL7Sm4U817nB0xq7AoNPo6qrJf3tTJEk+34b7CqxOV37dAoR
         3L8kZlAqKNsF54sjlDUC1x/ngy+jZ5khXCMXsph4xeeWzLh92sMgz0JKzTIUwtzl0n3F
         jxFP6s+KfHhXpwwTQdkNGXA08s9J1NGYMCcpdB7JbyvoGeyHj8iV/NGQB3PJ5sotg3QJ
         13q1XgaZ/1EI5GKdOye+8LXpf8aQWm/cK66BG4Y9qdZSPBtB8tp2P+G2c0+P66u9Ncxo
         X9XA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747302865; x=1747907665;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Zk560i6SJnRty0xcdm0Tr4hUCdi0a1YYgcQMFFm97ys=;
        b=Bi+FYKAnTE02TRy/L5e1U46wcNrv/Zuv0koc2eIbo4n5OrF7zLdJV+SydWL61OLop7
         IQQRTeARXXRYMc/wN2rXP5HhD/tIQQRNmr3kI4PAz9lvHwCJFAumMBZI5Lqr4q4jcrXw
         qJ8StXrdYyETjsvdNIgBm60LlVIbjTZpmaDir/EyMD6kvfkFkoJ1u+LE8u7tapkh1Z4L
         pUfyJQ79N+XCIYWpv1NdwdmRMpQf/XVcZbT49j6sb2vp0szJNbEkOm+VzXYrgm4EJYIQ
         67ormWXB+R1AhE1brTF+yT+pF75VDO1CU36buj/HGEoWzFQCRJ7dr1BjJOGw7tesqsfJ
         9XKA==
X-Forwarded-Encrypted: i=1; AJvYcCV/sTdmwk8YsRgTwUgCWpmtTXWlCZwM1+8uiRVRJVKHsUqSLBJo2CGrfm7U6i+Wxv0bafnxupCfEu8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz1UOMzosmG86pxph1aIE0Ss8vapIqS3fDTMxON4+oMuNasU1dh
	qH9OeJxmYDEnV0aYtHvf3clcF75L/1+2W0NLMGhkcClnmzH35J5NynLh7V65pQ==
X-Gm-Gg: ASbGncvXHQV5LZdL7PwmJnuES2AYKV86SoMEtxn6a8jRYiFka3JfxAYlEQuHVhrBKC/
	jzk6FOUPxRwWTLWSrwpc51mHsCoRhu5MKUxH+hhRTR+jlAO18WgT3TJ5Vf1+fVmazaQZs94kmkD
	12fI3yOvKLuSEjN9gMCiQze4IdQ2fqBF6KZz9eF7NA0xHbK9viue9Vzw/75dPtMtLmuQBGf7bYb
	zwFeh7iaMN582d3XIftj7IZZr500t9drq78nOT48CuN9e0/nFkh6s358Oo8Yh/UNCKbqgDXO6N6
	nVPh5b0h7TDhXyvbAr483jBnt/OKtl18gCwLubnWVlIouFedb3USoC2PBBLU01eGTDRtW5KtwWm
	6NLG3eE0UvFaL/+wR1DOWY7mjChU5qTKFG8TS
X-Google-Smtp-Source: AGHT+IGLBojilIdHsatJKVv+PcQ3rfurAV87meLx+GFX7Q2XEGsmYjw5CsabDt+vCX8a+TX+jWt2gA==
X-Received: by 2002:a17:906:4e84:b0:ad5:1497:48ae with SMTP id a640c23a62f3a-ad514974a31mr133606066b.61.1747302864771;
        Thu, 15 May 2025 02:54:24 -0700 (PDT)
Message-ID: <1ca8df48-7e2d-4ad3-b1ad-8b4530fd22be@suse.com>
Date: Thu, 15 May 2025 11:54:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 14/16] xen/riscv: add external interrupt handling for
 hypervisor mode
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <5688ed044febf734d9c75aa2e6f52affccd3fce9.1746530883.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: <5688ed044febf734d9c75aa2e6f52affccd3fce9.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> +static void cf_check aplic_set_irq_type(struct irq_desc *desc, unsigned int type)
> +{
> +    /*
> +    * Interrupt 0 isn't possible based on the spec:
> +    *   Each of an APLIC’s interrupt sources has a fixed unique identity number in the range 1 to N,
> +    *   where N is the total number of sources at the APLIC. The number zero is not a valid interrupt
> +    *   identity number at an APLIC. The maximum number of interrupt sources an APLIC may support
> +    *   is 1023.
> +    *
> +    * Thereby interrupt 1 will correspond to bit 0 in sourcecfg[] register,
> +    * interrupt 2 ->sourcecfg[1] and so on.
> +    *
> +    * And that is the reason why we need -1.
> +    */
> +    unsigned int irq_bit = desc->irq - 1;
> +
> +    spin_lock(&aplic.lock);
> +
> +    switch(type)

Nit: style

> +    {
> +    case IRQ_TYPE_EDGE_RISING:
> +        writel(APLIC_SOURCECFG_SM_EDGE_RISE, &aplic.regs->sourcecfg[irq_bit]);
> +        break;
> +
> +    case IRQ_TYPE_EDGE_FALLING:
> +        writel(APLIC_SOURCECFG_SM_EDGE_FALL, &aplic.regs->sourcecfg[irq_bit]);
> +        break;
> +
> +    case IRQ_TYPE_LEVEL_HIGH:
> +        writel(APLIC_SOURCECFG_SM_LEVEL_HIGH, &aplic.regs->sourcecfg[irq_bit]);
> +        break;
> +
> +    case IRQ_TYPE_LEVEL_LOW:
> +        writel(APLIC_SOURCECFG_SM_LEVEL_LOW, &aplic.regs->sourcecfg[irq_bit]);
> +        break;
> +
> +    case IRQ_TYPE_NONE:
> +        fallthrough;

This is pointless (and hampering readability) when there are no other statements.

With both taken care of:
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 09:57:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:57:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985123.1371054 (Exim 4.92)
	(envelope-from )
	id 1uFVLJ-0004Nf-Kt; Thu, 15 May 2025 09:57:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985123.1371054; Thu, 15 May 2025 09:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFVLJ-0004NY-IH; Thu, 15 May 2025 09:57:33 +0000
Received: by outflank-mailman (input) for mailman id 985123;
 Thu, 15 May 2025 09:57:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFVLI-0004NG-22
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:57:32 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 03d9e706-3173-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 11:57:30 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-acb39c45b4eso107636266b.1
 for ; Thu, 15 May 2025 02:57: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
 a640c23a62f3a-ad236cb21a2sm899774066b.159.2025.05.15.02.57.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 02:57: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" 
X-Inumbo-ID: 03d9e706-3173-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747303050; x=1747907850; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XPNXpks1FLUZUm/Ssr6yCnVSVUh8hwwVt+UGkvE7YzU=;
        b=Ms1x13u8GW4/E3b5fbFneIH4Qpm226SBglGjaOmRX+wCrDLNB+siYP+vAKkd9ODMoz
         JQqtNp6xLhQIYPgkdlJ6J9hyTZ6rTCTRWkjs1juL5gEznmuofRCVpwGMc7v0yGBd+tDo
         +pj6iE+zVdJl528R9BoMqjtp2CjyD7nuZZWXlvvMy0ci66v01pzGqJrQpERjC5cgtOy6
         M/qH09IgD87Sse0Y02LcpS0VapY5QwxLGuXhgAavIUcpUVRGwGkq0ZWX05MXAlY82/84
         WkfLfBd4maBMQV/e4/jBpXbVpsuM7kApfYz2WNuYXHmyGBS/pWpW9yomITF3XDrA6/sp
         llPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747303050; x=1747907850;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XPNXpks1FLUZUm/Ssr6yCnVSVUh8hwwVt+UGkvE7YzU=;
        b=H0/Mcg+y1KFT6U5957oXRC9RTFx9PUS6donfyFZ1h4k35nN964uFYaNVUGTxsF9T0O
         VG6hVViooZwXwCLlbqAKeX6Ihq3IEvsPYaNFsGOs6GIbJyRUctMwxsFFew+D3/OZxBO+
         i0I+9ehhTILUEd8kQnXekFGrnDTmOkDl3RpkpJZLPUtJcKtLv6oUa1quq0aaWEkpu0XM
         KcgNGL3vIZi9Fj1q4cp+oyNX3STgmqcSOM0o+fGy51+vaZVLkRE6Bbynl3uOHSYzkUdR
         W1zGu9dvLAkorrLNixO7N6SWdb9oLmciaaXgyMhsPXCIAkMttmdKwq6M+u077uxpr/FE
         brZA==
X-Forwarded-Encrypted: i=1; AJvYcCVcBaTnE78EIGeRz9REGmHcFpqdWW9v7Gq0Zfyz4iti3glOjLPiUpqogiMMBEaj+4vxycTPciz9RSk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyK+7w0Oljh1GhnaA/SxtiVxuFbkmsr4OKC6cNwXLdHgCGrJoEA
	YNqiXw46xgCqW4e9hL86EIQINu+ftN60SR65vkh4esy0o5BTv7GKBYxgiUmpyA==
X-Gm-Gg: ASbGncuCAN26CawMRcICRGVgotcobqGgQEgHrjG4D6qeh7lZjvosm8qUVLBxvmCRimZ
	OVqDBJiArJsnNqaHoO2TXjyz9F2EUSB4/9ZsEbWJgTqFiCSd1ZqbNcO9u9SgzNC2BbHwANFv57x
	NS4p20phD5kcQT9xf6TlLxOAbLk9iRef+as90dKc/FLXJuUqJ8cL7p6zsVRttOAxuTSHnwmYw8z
	XCWxaqsSTjZBFLLwO1N2QCfCXqLo8n02C+/s+Q6liajq5SxKdahL5EROgdnY/FdE9PBpPzSBaV/
	L7Kk3POPqqwytizNlTYkUyizEP9gIcKZC4Q2VqGA20z7865j3l0FoCJc9eXytyptbGHnEdDsRrB
	P01mM4Aor9p1sSaNMuWZ6MbWb9tl3Ldz1KkG1
X-Google-Smtp-Source: AGHT+IFggB8uGPpAMLv+GkVnXYg7zYm2kaiTFhvZE5yo92vueMt5Z2JY2Mj6qwUaxb7mzsxfxNo6Cg==
X-Received: by 2002:a17:907:d106:b0:ad2:39f2:3aa1 with SMTP id a640c23a62f3a-ad4f72924e3mr686147866b.44.1747303049978;
        Thu, 15 May 2025 02:57:29 -0700 (PDT)
Message-ID: <5f8a2840-2080-4b04-8298-0f5e22eaf5c0@suse.com>
Date: Thu, 15 May 2025 11:57:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 15/16] xen/riscv: implement setup_irq()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <6f17bbf0eb6240d7389d389f0973af6fda5cce29.1746530883.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: <6f17bbf0eb6240d7389d389f0973af6fda5cce29.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> @@ -58,6 +59,89 @@ int platform_get_irq(const struct dt_device_node *device, int index)
>      return dt_irq.irq;
>  }
>  
> +static int _setup_irq(struct irq_desc *desc, unsigned int irqflags,
> +                      struct irqaction *new)
> +{
> +    bool shared = irqflags & IRQF_SHARED;
> +
> +    ASSERT(new != NULL);
> +
> +    /*
> +     * Sanity checks:
> +     *  - if the IRQ is marked as shared
> +     *  - dev_id is not NULL when IRQF_SHARED is set
> +     */
> +    if ( desc->action != NULL && (!(desc->status & IRQF_SHARED) || !shared) )
> +        return -EINVAL;
> +    if ( shared && new->dev_id == NULL )
> +        return -EINVAL;
> +
> +    if ( shared )
> +        desc->status |= IRQF_SHARED;
> +
> +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
> +    new->next = desc->action;
> +#endif

Didn't you indicate you'd drop this?

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 09:59:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 09:59:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985131.1371064 (Exim 4.92)
	(envelope-from )
	id 1uFVN9-0004ul-0G; Thu, 15 May 2025 09:59:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985131.1371064; Thu, 15 May 2025 09:59: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 1uFVN8-0004ue-Tv; Thu, 15 May 2025 09:59:26 +0000
Received: by outflank-mailman (input) for mailman id 985131;
 Thu, 15 May 2025 09:59:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFVN7-0004uN-TU
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 09:59:25 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4839d77d-3173-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 11:59:25 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ad21c5d9db2so123488066b.3
 for ; Thu, 15 May 2025 02:59: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
 a640c23a62f3a-ad2197bd479sm1078443966b.151.2025.05.15.02.59.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 02:59: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" 
X-Inumbo-ID: 4839d77d-3173-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747303165; x=1747907965; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=s6RtDKy54m9dkYd4udXg1KJZIBZr79kJV4uoqATV6Pw=;
        b=DAzW78B+ds/ndgsYttAOkEtLYyJNWcQzDzj/P8UyGeCJ1BOJbsq77H0YGJXfwwdy13
         bNfsc5ABP7h2aQchLRoe6bJW4d9KYdnattsNJv2naA4wQE6HrXWerYO+retDsOTFjsFH
         zIIdtDUp8qQcl6/6qUYnnCMFVaBGmYS3EvMostOMbIn7JH8GfZ5tedUCsAUXlW7qRkog
         FX8TETRM1So/zVZ6KAfPzWo7AEh05JutpF/aKDSpqhI+d10raB5EOycW5WmUu0DnmPI6
         7C/U8s+xu0u64mhbB5FWFaX3h8PtDBmZ5AKJd8rCMe9JVZlAKb9SxqHxT48V7Non6WTO
         pZbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747303165; x=1747907965;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=s6RtDKy54m9dkYd4udXg1KJZIBZr79kJV4uoqATV6Pw=;
        b=c115nk/6rSuOf31mj79H+w5rt7avlDCoVDvDGJLfsZwUgFarlhIkbDD/G2qywYXWCl
         LE44O0l4mOwoxVo69LBSpjlUNKKTZfonlGfPZPzKRId8So74v28edCUftN2Ke+R6tQYx
         1ninPfJ6D/lyK6FpLUq77ssn0IQ+Sjkh3J9PIV/vc8akWFvVVNnaobF5CS/7U9ajPAkI
         8cw2gkF739hi0p5Ag4kfY00exUWEEbaEk7FSzg6fuYLyz2radzROy33w2aix9zkM47gm
         Zmq+ZTvs8D2AxufEIUTU5OrcuWouPanUeUdaQAUHl+A3h8xo1RCwBjyNC8grlT1Uy89m
         CGOQ==
X-Forwarded-Encrypted: i=1; AJvYcCUKAJq5nEID+OKUU3XmenI2pKA91qEg2PQtXWhBhXVXgP44fn1xIXOLFchATvxU4XFtsBx5tDjXtWI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2855yOH5x7zS6Y02LUlhwrJIhiTCjuBym888r4/upoxlskXFn
	YJPwRw8x7k/ZBzMZYiWVGwnbGy5NXv1Fd9lDpl+eRN2kSyLsc3bbMWa/ehBdiQ==
X-Gm-Gg: ASbGncty57HVaVSpxteR++rGlrzDeg+TKBejPyM5iWZ69aR5njZHMOtrn/umuHEvWEa
	E4NwjpW2sLuq4JIuELNig92QRB56cCYzi5jSW4cwpPfnHeMF254dRNeiLYTjNBXNRLvtYCGitL8
	eX9hfZiNB8rt9opFGdUf1OIKivMsIoas1wGB27jfVMgVLOQD36ouifOrk6XaNouKN7dowpSKLWt
	Y5WK/KFvlWXGQ39NxDX6UwW9EMiJct99P0oWvST7m0tlRNFfyoOEVcMpI7o0kqANnvYoHN6NjmU
	Nu0KHSnYhyq4AubZj4B9zHnv6l7XFTasxj7g7B1tVtaHe1HayGOW3rFM8tPNv9LALgJlJetJwLr
	tDg2Hg0izc2FeOqvtgF7+vTOtjzC/H5xA0EPE
X-Google-Smtp-Source: AGHT+IFDDEQGoBAYuj1z8MfpC0CTI8va5irYHNnt7w9SQItIW1ojoGAhmQRxr59ArtXm5F+qtlLPJA==
X-Received: by 2002:a17:906:340a:b0:ad5:e0a:5891 with SMTP id a640c23a62f3a-ad50e0a5b7amr253922366b.1.1747303164655;
        Thu, 15 May 2025 02:59:24 -0700 (PDT)
Message-ID: 
Date: Thu, 15 May 2025 11:59:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 16/16] xen/riscv: add basic UART support
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <9fbcd17751fb0b7925d622631acb0030ee110465.1746530883.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: <9fbcd17751fb0b7925d622631acb0030ee110465.1746530883.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 18:51, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/setup.c
> +++ b/xen/arch/riscv/setup.c
> @@ -4,12 +4,16 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 

Why's this needed? I can't spot anything ...

> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -136,8 +140,17 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>  
>      intc_preinit();
>  
> +    uart_init();
> +    console_init_preirq();
> +
>      intc_init();
>  
> +    timer_init();
> +
> +    local_irq_enable();
> +
> +    console_init_postirq();
> +
>      printk("All set up\n");
>  
>      machine_halt();

... relevant here. With the need clarified or with the #include dropped:
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 10:05:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 10:05:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985140.1371074 (Exim 4.92)
	(envelope-from )
	id 1uFVSV-0006rF-K0; Thu, 15 May 2025 10:04:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985140.1371074; Thu, 15 May 2025 10:04: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 1uFVSV-0006r8-HT; Thu, 15 May 2025 10:04:59 +0000
Received: by outflank-mailman (input) for mailman id 985140;
 Thu, 15 May 2025 10:04:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFVST-0006r2-Sd
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 10:04:57 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0cbdc55b-3174-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 12:04:54 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad51ba0af48so62479066b.0
 for ; Thu, 15 May 2025 03:04:54 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad21f2145d6sm1049688166b.95.2025.05.15.03.04.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 03:04: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" 
X-Inumbo-ID: 0cbdc55b-3174-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747303494; x=1747908294; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=I1EiFZSk7YxyIKZ3rKPdt3+1uIek19CdmA9y/W1+PFk=;
        b=nZ5J4GnKBoTOfUeW8QG5Xve89qf8EmXkK10UYr13t4TWt0TXTgv7s1RFYNqxBKgHD2
         tMfv22kSWxrjnEty5n5QUhIJ4p7mxkhGzVIWsJo3rMeh8o31bJhoTvbSNowFTV3lnLl/
         iL3UM7g6e0UbOHLXEUzw+ahtJ7HtQFvuMnces=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747303494; x=1747908294;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=I1EiFZSk7YxyIKZ3rKPdt3+1uIek19CdmA9y/W1+PFk=;
        b=fJYBaL8AnFsetXl32jAUHYR/rPYqE7AiVjQT0BIOcixi7PwAm4i5XrkJK0KT8/ZkRr
         +GqT/ewOHrbbPsCAye0MhEFq6c9hmLz7HtKcbfu4tCyx0xFNz4u8+5WcaPWECiVsU/oa
         bykc3kbE5+0+4m3AatIgGIn753sysHS1bdr8N/QvLOgat+DaFJQBByt1MRiO/NS3R29s
         bP71oOnifF5tMgFlybt7RxKxinazRjWfKVUdvxt+kRC/tC1+Ac3SwJAf77zibYCarcTT
         HdxmfMGW6W4ZsfcKL0g1JDctI9wsvqBX6WXPzT30k7SKIXMcJ1BkfUTFuy+jPwJJUmg7
         X4Gg==
X-Gm-Message-State: AOJu0Yw1XJ6ADmeEq/cTpdlIHUE8jwfOOGaR1hynHIF+jD+o17X4JANO
	pHxyYeE4yrEOOSNL8JSLYREoV1l19akmUkaJZziV1hagAkfwC3dzpqjVL0yUXmmOSkY=
X-Gm-Gg: ASbGncukk1W1r/kr6lPVge8AhV/v3/SpBhtrMfOPfsKy0aYFI1AHE6SUhc+55A6Hf7a
	YSAadgeKny9HKJzY/bBwQ8VWnz6RtBSj/5I9kLNoK/B6lSklQhfz6L1YDCqu3OJTWWfP3JuIxnk
	jRZMkvhoPadz0EIN3wof70WGyF2aYduQ1uiARftB8rUViYlnasy+NGO0A1pIsKI/2NcmvVRbbKN
	gDUvkhzDPRUNLKTj2/YPkc8E8KqVCiY5xjzjQ3CU/Mg7uQR3WslSnhSQpm0TldgN2zxx+JlNAGW
	dhKyknuomUMQOh8zgrMnCSAxkRHS5a3hiOxXOGwyFfW/9n43+/BHEzkQ
X-Google-Smtp-Source: AGHT+IHv2A0WoEXFWc1D7d8HzAu4V982lFbmTcduASSjtx8vH44LKy9axbVEfiOoH4II8F4LCuTTbA==
X-Received: by 2002:a17:907:9712:b0:ad1:ff5f:1460 with SMTP id a640c23a62f3a-ad50f611e40mr321007666b.6.1747303494345;
        Thu, 15 May 2025 03:04:54 -0700 (PDT)
Date: Thu, 15 May 2025 12:04:52 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu 
Subject: Re: [PATCH] x86/HVM: restrict use of pinned cache attributes as well
 as associated flushing
Message-ID: 
References: <42d40da1-bc38-82fb-154a-e1fc876b0c24@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <42d40da1-bc38-82fb-154a-e1fc876b0c24@suse.com>

On Wed, Mar 22, 2023 at 07:50:09AM +0100, Jan Beulich wrote:
> We don't permit use of uncachable memory types elsewhere unless a domain
> meets certain criteria. Enforce this also during registration of pinned
> cache attribute ranges.
> 
> Furthermore restrict cache flushing to just uncachable range registration.
> While there, also
> - take CPU self-snoop as well as IOMMU snoop into account (albeit the
>   latter still is a global property rather than a per-domain one),
> - avoid flushes when the domain isn't running yet (which ought to be the
>   common case).
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
> ---
> At the expense of yet larger a diff it would be possible to get away
> without any "goto", by moving the whole "new entry" handling into the
> switch(). Personally I'd prefer that, but the larger diff may be
> unwelcome.
> 
> I have to admit that I can't spot what part of epte_get_entry_emt() the
> comment refers to that is being deleted. The function does use
> hvm_get_mem_pinned_cacheattr(), yes, but there's nothing there that talks
> about cache flushes (and their avoiding) in any way.
> 
> Is it really sensible to add/remove ranges once the guest is already
> running? (If it is, limiting the scope of the flush would be nice, but
> would require knowing dirtyness for the domain wrt the caches, which
> currently we don't track.)
> 
> This is kind of amending XSA-428.
> 
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -589,6 +589,7 @@ int hvm_set_mem_pinned_cacheattr(struct
>  {
>      struct hvm_mem_pinned_cacheattr_range *range, *newr;
>      unsigned int nr = 0;
> +    bool flush = false;
>      int rc = 1;
>  
>      if ( !is_hvm_domain(d) )
> @@ -612,31 +613,35 @@ int hvm_set_mem_pinned_cacheattr(struct
>  
>                  type = range->type;
>                  call_rcu(&range->rcu, free_pinned_cacheattr_entry);
> -                p2m_memory_type_changed(d);
>                  switch ( type )
>                  {
> -                case X86_MT_UCM:
> +                case X86_MT_WB:
> +                case X86_MT_WP:
> +                case X86_MT_WT:
>                      /*
> -                     * For EPT we can also avoid the flush in this case;
> -                     * see epte_get_entry_emt().
> +                     * Flush since we don't know what the cachability is going
> +                     * to be.
>                       */
> -                    if ( hap_enabled(d) && cpu_has_vmx )
> -                case X86_MT_UC:
> -                        break;
> -                    /* fall through */
> -                default:
> -                    flush_all(FLUSH_CACHE);
> +                    if ( is_iommu_enabled(d) || cache_flush_permitted(d) )
> +                        flush = true;
>                      break;
>                  }
> -                return 0;
> +                rc = 0;
> +                goto finish;
>              }
>          domain_unlock(d);
>          return -ENOENT;
>  
>      case X86_MT_UCM:
>      case X86_MT_UC:
> -    case X86_MT_WB:
>      case X86_MT_WC:
> +        /* Flush since we don't know what the cachability was. */
> +        if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
> +            return -EPERM;
> +        flush = true;
> +        break;
> +
> +    case X86_MT_WB:
>      case X86_MT_WP:
>      case X86_MT_WT:
>          break;
> @@ -689,8 +694,12 @@ int hvm_set_mem_pinned_cacheattr(struct
>  
>      xfree(newr);
>  
> + finish:
>      p2m_memory_type_changed(d);
> -    if ( type != X86_MT_WB )
> +
> +    if ( flush && d->creation_finished &&
> +         (!boot_cpu_has(X86_FEATURE_XEN_SELFSNOOP) ||
> +          (is_iommu_enabled(d) && !iommu_snoop)) )
>          flush_all(FLUSH_CACHE);

I think it would be better if we could add those checks to
memory_type_changed() rather than open-coding them here, and just call
memory_type_changed() then, which would also avoid the goto AFAICT.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 15 10:08:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 10:08:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985152.1371085 (Exim 4.92)
	(envelope-from )
	id 1uFVW6-0007U1-6q; Thu, 15 May 2025 10:08:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985152.1371085; Thu, 15 May 2025 10: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 1uFVW6-0007Tu-4B; Thu, 15 May 2025 10:08:42 +0000
Received: by outflank-mailman (input) for mailman id 985152;
 Thu, 15 May 2025 10:08:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFVW5-0007To-Ky
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 10:08:41 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92b7ed27-3174-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 12:08:39 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5fbc736f0c7so1148606a12.2
 for ; Thu, 15 May 2025 03:08: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
 4fb4d7f45d1cf-5fd2b82297esm6812713a12.44.2025.05.15.03.08.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 03:08: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" 
X-Inumbo-ID: 92b7ed27-3174-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747303719; x=1747908519; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=isIMdZ8Pin1EYuoK9HNbdwiEJU+o8JaDPxr2CJqfkkI=;
        b=VXrTg0fn9AtzdLUHqY9yFDuEaD9XPx2ySf30RI9vMD9cVskFMzHfWB/nEmHxlyTVmX
         6rRzba512lLWIgpLCI2q7uWy1QP1eLkJblEVoVwgTDnWtULXh5UonBSzF6pehHX4D87P
         TONKAw8e22L6wm3jlwtmjjIAcTqVSq6ooLxiRdjARLzheWvbhsRFbIuYADsXjbSu7Sd2
         88AjOc0/vEQi2BZLxgEaXTGhk+8uWBVj5R3rUOK+gnW2g4NzOzq86EBrTAInrdyp1fCd
         vvMHnbOfK7Xu1qnruszuhtlU+vxAqS2mFPCMqpdIvBHcTi7XneSiXkx7/Udrp0Shpbc9
         TzQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747303719; x=1747908519;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=isIMdZ8Pin1EYuoK9HNbdwiEJU+o8JaDPxr2CJqfkkI=;
        b=LgxdGpkTS9N78xkMof6LnSfqfkcrFKHuC/T6n0OjnMkwO7KyzyAx7kKDXxPJWHGPe3
         ofPd3ymAN2iPhtktSjiyWVbmyr+JE+0TD1Ts9GbPshF2WJWZsT/YCE+2VVBLZCSadY8e
         TeP+ezorUsQ9SZEzeXuVSRqQ1m/b92o2szZoYWs2BA2O2RZC7R7ei4hamXbTavCVDESe
         gmrnj9+bq5KxBwfGeJbSEK8YxFwBOXUPcelTr0UzT3b00XurhfB5ajAEvaYTYFg8yutk
         kEeCX5XFTXtknJav7JAEpOMCOsaR6h+GE7C8Tez1aM7uXN/Q47RldKx/5x/ta3sKG5/S
         JoyA==
X-Forwarded-Encrypted: i=1; AJvYcCXUzjatsbKTuCm0AUzZcCov13+BGSGO6E0eguB0DTzDd/Ue/m/icEaQkKPvFa+PcmCa8rPO00t1mYM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy4AuhMeXvgCLQNV5pJVr8c6n2c2KeJEwzErpgceCF2hw9lxOt9
	agV6T6YOxdivJhgcpTLk5OI1MKwBEmB9Xrq8xn+cglFI0Pj412u1dNO2r2wc8w==
X-Gm-Gg: ASbGncuOON/BEmanQaqaSMQilR2SQeIvS1TSr+ZoTl28wIiph/KdXaTQEkNgaQagh3w
	KlRy8c4SJCBj05OjfQEoJ28ChfKLWt5rb+hQy1ovdFdikIoqvjw4N5kEwD3suR3E0Efe7hT/m5k
	AMqzew7hs8PcaP6FLnNk2SYfLS5Ptrvz8630J8bw2psXDlembbbiSPNREQ+1U2+08QaKF7uzqN8
	BMnnFzrdjwaC+OleHQ0sZfkV9x2ytibidJ19gj9+zgOH4ORI6a9n41UE4YSqxaQ+n8zSXRYGiLP
	WOVVUWg3mNVeXaOGt78COzKHUR0H4q1SbIzDSK/DG57FKcwORglVV7/8LAasZg+ClcyYHmKW7Gg
	61ddvNxhaFkazQcyfCHDvhPfS/NG4I5/hpqQK
X-Google-Smtp-Source: AGHT+IFX+uG785reGbuu72hta70J2BQu/hSXGonvstXIvJ+/JG0Hm0AMjjiSVUSdN6ce8FrrzIpyzg==
X-Received: by 2002:a05:6402:520b:b0:5ff:7175:a6f6 with SMTP id 4fb4d7f45d1cf-5ff988ad823mr5585751a12.19.1747303719145;
        Thu, 15 May 2025 03:08:39 -0700 (PDT)
Message-ID: 
Date: Thu, 15 May 2025 12:08:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen/riscv: add initialization support for virtual SBI
 UART (vSBI UART)
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: <1f380b7061496f999d4d60a60b58f494dae886e1.1747064551.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: <1f380b7061496f999d4d60a60b58f494dae886e1.1747064551.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.05.2025 17:55, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -1,5 +1,6 @@
>  obj-y += aplic.o
>  obj-y += cpufeature.o
> +obj-y += dom0less-build.o

Arm uses

obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o

Why the two differences?

> --- /dev/null
> +++ b/xen/arch/riscv/dom0less-build.c
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
> +                      const struct dt_device_node *node)
> +{
> +    int rc = -EINVAL;
> +
> +    kinfo->arch.vsbi_uart = dt_property_read_bool(node, "vsbi_uart");
> +
> +    if ( kinfo->arch.vsbi_uart )
> +    {
> +        rc = domain_vsbi_uart_init(d, NULL);
> +        if ( rc < 0 )
> +            return rc;
> +    }
> +
> +    if ( rc )
> +        panic("%s: what a domain should use as an UART?\n", __func__);

Is this a reason to panic()? Isn't it possible for domains to be fine
without any UART?

> --- /dev/null
> +++ b/xen/arch/riscv/vsbi-uart.c
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +int domain_vsbi_uart_init(struct domain *d, struct vsbi_uart_init_info *info)
> +{
> +    int rc;
> +    struct vsbi_uart *vsbi_uart = &d->arch.vsbi_uart;
> +
> +    if ( vsbi_uart->backend.dom.ring_buf )
> +    {
> +        printk("%s: ring_buf != 0\n", __func__);
> +        return -EINVAL;
> +    }
> +
> +    /*
> +     * info is NULL when the backend is in Xen.
> +     * info is != NULL when the backend is in a domain.
> +     */
> +    if ( info != NULL )
> +    {
> +        printk("%s: vsbi_uart backend in a domain isn't supported\n", __func__);
> +        rc = -EOPNOTSUPP;
> +        goto out;
> +    }
> +    else

Pointless "else" after "goto".

> +    {
> +        vsbi_uart->backend_in_domain = false;
> +
> +        vsbi_uart->backend.xen = xzalloc(struct vsbi_uart_xen_backend);
> +        if ( vsbi_uart->backend.xen == NULL )
> +        {
> +            rc = -ENOMEM;
> +            goto out;
> +        }
> +    }
> +
> +    spin_lock_init(&vsbi_uart->lock);
> +
> +    return 0;
> +
> +out:

Nit (you know what, I suppose).

> +    domain_vsbi_uart_deinit(d);
> +
> +    return rc;
> +}
> +
> +void domain_vsbi_uart_deinit(struct domain *d)
> +{
> +    struct vsbi_uart *vsbi_uart = &d->arch.vsbi_uart;
> +
> +    if ( vsbi_uart->backend_in_domain )
> +        printk("%s: backed in a domain isn't supported\n", __func__);

Is this relevant in a de-init function?

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 15 10:11:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 10:11:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985160.1371095 (Exim 4.92)
	(envelope-from )
	id 1uFVYY-0000ho-In; Thu, 15 May 2025 10:11:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985160.1371095; Thu, 15 May 2025 10:11: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 1uFVYY-0000hh-F3; Thu, 15 May 2025 10:11:14 +0000
Received: by outflank-mailman (input) for mailman id 985160;
 Thu, 15 May 2025 10:11:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFVYX-0000ha-L3
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 10:11:13 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed136b25-3174-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 12:11:11 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5f7ec0e4978so1537096a12.1
 for ; Thu, 15 May 2025 03:11:11 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad22ba47376sm967964766b.53.2025.05.15.03.11.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 03:11: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" 
X-Inumbo-ID: ed136b25-3174-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747303871; x=1747908671; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=cCZUFsZ4M11UEvy/3qp0CrrveNe+eVtvPPVzg5V55JA=;
        b=Ubl6fPYLmGoGk+MvLddmhS/56ivG/0+ByhuEJ6aQT02AeaLq2fikHKaQNMERPlapLN
         0gCKP5zBJ7JS9joqPi3d0Hv+4iNYwJ7moGfi77WcuwQxRc7z2oV2FFz5IFQcRXLlupUC
         BfRU1Q00/Uigq8OWzkMKVIX08p4RWsA8d13hM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747303871; x=1747908671;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=cCZUFsZ4M11UEvy/3qp0CrrveNe+eVtvPPVzg5V55JA=;
        b=vK22rxlUNlOSXy3ewODM01cQVH8ZOtqwSd458FA8zdygq3HRMtttTbNNyyXucS6XbQ
         slXqUwiYVuJ7iFgfo1EQ4rA/f3yDieOHTdMb//rX4R4d2r8wArwYh/6FYm5GBJLVknZ0
         jdLiHJXmr0iH+UpZWjxEvr48wRP8sSkDvBRwSYlE2FFNmM4ceoBkCoVNm2G9X/JXAmjl
         RhWilUktwO0VbisKPho9OJYFik/4TfxSaxK2g8vhhyjVaDxGCWAsT5wegDMfe8OfMxaq
         JwCMvife0eO7xn+WUK1yoJyZ8JX2PK5+Mq+46MFCJLvCjtpbRs2R+eNdpkN8wmsmgOP4
         PMgA==
X-Forwarded-Encrypted: i=1; AJvYcCU4P7fKaEj+/qI0uF+tu1AJSuGBIRPZU2Px6crEuEROlOpRnnL4Z/hYkWu2Gx123CG2lUEP8fMQOi8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwfiJNuOKeLpBC4HulaENiDUX07UZqEh1xaWyjgrnQ0Q756xbY9
	t4Oa9aEYxPaGaq9oL660OKCKxp0zlY/JBBiOapNzKtYOgZUyyLVReMAPjq1LyOo=
X-Gm-Gg: ASbGncvwlX4Gj5AEUoKJtjY0/AtKYv4XYhN7oU9DLqSE+yoTz5mxPD1CWgVkPrkBthi
	azgGIeZa/WjUdQUUeojXF41VME0pL1qLcoF5t38aEGlK8rxV3O1SUNjraLkDFAOkJBCSDiXg79K
	1NGTPOBMVCXvR8UnDRj+An8MXukTOgykCSCsZYnAyE9API7CpNujMG/S4nuPnXzxMAWRl00Mpvh
	XE4jkYEFLMA7IeRn13+U1JZ7DPJshQQha/WTHZCPbwm8CGiM57uwYwFJXTRToqVYAb67KqOmImT
	CfDPGuiURKwGvXDTdJmXCDcA3MzxYX5XOA1MgksNTnHfxKy0EYoBu9f0
X-Google-Smtp-Source: AGHT+IH21ruOMB6qTLHzUfW6AvN6IB2MjY53frGKBi97aUqDPGO0ghy/AsqK4j3PyhDlcYpCeu6rTQ==
X-Received: by 2002:a17:907:3947:b0:ac7:e5c4:1187 with SMTP id a640c23a62f3a-ad4f70f6179mr524336766b.11.1747303870683;
        Thu, 15 May 2025 03:11:10 -0700 (PDT)
Date: Thu, 15 May 2025 12:11:09 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] x86/vpci: fix handling of BAR overlaps with non-hole
 regions
Message-ID: 
References: <20250515084123.43289-1-roger.pau@citrix.com>
 <8b0fa959-6d00-4bfb-bef0-b3d1ae7ce7e0@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <8b0fa959-6d00-4bfb-bef0-b3d1ae7ce7e0@suse.com>

On Thu, May 15, 2025 at 11:24:59AM +0200, Jan Beulich wrote:
> On 15.05.2025 10:41, Roger Pau Monne wrote:
> > For once the message printed when a BAR overlaps with a non-hole regions is
> > not accurate on x86.  While the BAR won't be mapped by the vPCI logic, it
> > is quite likely overlapping with a reserved region in the memory map, and
> > already mapped as by default all reserved regions are identity mapped in
> > the p2m.  Fix the message so it just warns about the overlap, without
> > mentioning that the BAR won't be mapped, as this has caused confusion in
> > the past.
> > 
> > Secondly, when an overlap is detected the BAR 'enabled' field is not set,
> > hence other vPCI code that depends on it like vPCI MSI-X handling won't
> > function properly, as it sees the BAR as disabled, even when memory
> > decoding is enabled for the device and the BAR is likely mapped in the
> > p2m.  Change the handling of BARs that overlap non-hole regions to instead
> > remove any overlapped regions from the rangeset, so the resulting ranges to
> > map just contain the hole regions.  This requires introducing a new
> > pci_sanitize_bar_memory() that's implemented per-arch and sanitizes the
> > address range to add to the p2m.
> > 
> > For x86 pci_sanitize_bar_memory() removes any regions present in the host
> > memory map, for ARM this is currently left as a dummy handler to not change
> > existing behavior.
> > 
> > Ultimately the above changes should fix the vPCI MSI-X handlers not working
> > correctly when the BAR that contains the MSI-X table overlaps with a
> > non-hole region, as then the 'enabled' BAR bit won't be set and the MSI-X
> > traps won't handle accesses as expected.
> 
> While all of this reads plausible, I may need to look at this again later,
> to hopefully grok the connections and implications.

Thanks, it's indeed not trivial to follow.  I've attempted to write
this as best as I could.

I think the fix is far easier to understand than the description of
the issue and the connection with vPCI MSI-X handling.

> > --- a/xen/arch/x86/include/asm/pci.h
> > +++ b/xen/arch/x86/include/asm/pci.h
> > @@ -2,6 +2,7 @@
> >  #define __X86_PCI_H__
> >  
> >  #include 
> > +#include 
> 
> Please don't, ...
> 
> > @@ -57,14 +58,7 @@ static always_inline bool is_pci_passthrough_enabled(void)
> >  
> >  void arch_pci_init_pdev(struct pci_dev *pdev);
> >  
> > -static inline bool pci_check_bar(const struct pci_dev *pdev,
> > -                                 mfn_t start, mfn_t end)
> > -{
> > -    /*
> > -     * Check if BAR is not overlapping with any memory region defined
> > -     * in the memory map.
> > -     */
> > -    return is_memory_hole(start, end);
> > -}
> > +bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
> > +int pci_sanitize_bar_memory(struct rangeset *r);
> 
> ... all you need is a struct forward decl here.

Hm, but any user that makes use of pci_sanitize_bar_memory() will need
to include rangeset.h anyway, hence it seemed better to just include
the header rather that pollute the current one by adding forward
declarations.

> 
> > --- a/xen/arch/x86/pci.c
> > +++ b/xen/arch/x86/pci.c
> > @@ -98,3 +98,53 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
> >  
> >      return rc;
> >  }
> > +
> > +bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
> > +{
> > +    /*
> > +     * Check if BAR is not overlapping with any memory region defined
> > +     * in the memory map.
> > +     */
> > +    if ( !is_memory_hole(start, end) )
> > +        gdprintk(XENLOG_WARNING,
> > +                 "%pp: BAR at [%"PRI_mfn", %"PRI_mfn"] not in memory map hole\n",
> > +                 &pdev->sbdf, mfn_x(start), mfn_x(end));
> > +
> > +    /*
> > +     * Unconditionally return true, pci_sanitize_bar_memory() will remove any
> > +     * non-hole regions.
> > +     */
> > +    return true;
> > +}
> > +
> > +/* Remove overlaps with any ranges defined in the host memory map. */
> > +int pci_sanitize_bar_memory(struct rangeset *r)
> > +{
> > +    unsigned int i;
> > +
> > +    for ( i = 0; i < e820.nr_map; i++ )
> > +    {
> > +        const struct e820entry *entry = &e820.map[i];
> > +        int rc;
> > +
> > +        if ( !entry->size )
> > +            continue;
> > +
> > +        rc = rangeset_remove_range(r, PFN_DOWN(entry->addr),
> > +                                   PFN_UP(entry->addr + entry->size - 1));
> > +        if ( rc )
> > +            return rc;
> 
> Perhaps better continue the loop in a best effort manner, only accumulating
> the error to then ...
> 
> > +    }
> > +
> > +    return 0;
> > +}
> 
> ... return here?

I think for the usage here, any error should be fatal, and should
result in the contents of the rangeset not being mapped.  Failure to
remove sensitive ranges from the rangeset cannot be worked around IMO,
hence accumulating errors doesn't seem helpful.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 15 10:19:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 10:19:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985168.1371104 (Exim 4.92)
	(envelope-from )
	id 1uFVgW-0001ZZ-9J; Thu, 15 May 2025 10:19:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985168.1371104; Thu, 15 May 2025 10: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 1uFVgW-0001ZS-6f; Thu, 15 May 2025 10:19:28 +0000
Received: by outflank-mailman (input) for mailman id 985168;
 Thu, 15 May 2025 10:19:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFVgU-0001ZM-N5
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 10:19:26 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 113e1e26-3176-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 12:19:21 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ad4d03700e6so119924266b.3
 for ; Thu, 15 May 2025 03:19:21 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad521ab59d2sm31639166b.67.2025.05.15.03.19.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 03:19: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" 
X-Inumbo-ID: 113e1e26-3176-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747304361; x=1747909161; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=0G2qg8u54S5JI1oEeq9DQJ3lFKLCjHo68wGdPMvKetk=;
        b=rcnWj1k+avKakFY347c6UU/MApr1yK2kxHyOfaALRUENQSL8nSs9kHYamfdUae2nwb
         85VO2mMdZ2PgGOyBGaZ5KmxbdIufB4jE6tFJOmh725mB0YWSmYaTEb0nloESzj7FUwYL
         vCOm8PZPO0WCygEpqbgCOSB067uLV4OcL8owY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747304361; x=1747909161;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=0G2qg8u54S5JI1oEeq9DQJ3lFKLCjHo68wGdPMvKetk=;
        b=UDGEH9KpjTAexkR17BIC87eHztYUUkLMdRkrlgn8txEXuFibNLJgP544nRD9XieKOz
         gMRrT5cXyqh2YtMEwxOfA9bafjcn7WYsyaD3IJkjF/QJRkWXByLBpGJY8dubTaTns6Kk
         uyuWsQE3ZszTf5uGk4mX0oySDmwUEShSfxk8g68njnKCuSaHvfqncQntxeCiZKFBj5ma
         7bx75IKio3dBAQmjZSiZJzKolSL5vqG4p+bvTnc//W4y/wL5iqit3zeFMaoboI9vsHZA
         cEnwBwjVqWAJmaETVFwi+ehKED/n4uUriUE2+fjq8sspmmFrWluCmWS+AMJ9K5uHD0Bp
         w02w==
X-Forwarded-Encrypted: i=1; AJvYcCWBnXtpqmPB5HJnwOd8E+CODGFZNTGZ3suAed6rMhYVTcrFzD5vQZDQcjCnNvu49VF8h+JH/173vYE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx4vkRser2SbCIEiGPHGi3+A6W64xk1zB3SX2ZOJUdrKh2yXXZ9
	XKNPp3ZZU4p6NFwShoiMkrbZv++sPxLRTlL57i6qusu4HWEobVNzTmrhOmnbBnA=
X-Gm-Gg: ASbGncsW8zEGrrcvSEARo/1gnG3RAy4b3wOK0I/D4+d9cFpDwSUi4DoS4rW178No7Ln
	Ai2juFKVk6U6m3/3faBxWuGNcY6fSFLRBj5rbTFR4Fa6TclO9OIAHZfZpUgMOv6edrC3jtdKoP5
	6uvG5Xq868/tMWFAF26CrlHDVNdUZQtLZVwSYwg7I2LEYhBsHX/ern2cGS+IcGbc9xWqx/N+0Yi
	y31+gg+hgtoltEmQLNmE+q9Nn5mDXpZT1C21eFOeHwLKDsCDkhX6PyHAyHwd6fLf1dfGiEiQaf6
	rx2Heza2mJEmjrcLXMOLJ6bbQTJhawelrJi7dT1bb3Czg70DKXeAl+1m
X-Google-Smtp-Source: AGHT+IHvevzTlzQgsde2WTdQAYRroAXo5QhdwEokbHLbtisW1qP8keKH0i6KQNZdkcuDeaBzuTrAAg==
X-Received: by 2002:a17:907:9625:b0:ad2:4785:c4ac with SMTP id a640c23a62f3a-ad4f751b693mr720205266b.40.1747304360799;
        Thu, 15 May 2025 03:19:20 -0700 (PDT)
Date: Thu, 15 May 2025 12:19:19 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Lira, Victor M" 
Cc: Jan Beulich , Jason Andryuk ,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org,
	Andrew Cooper , Xenia.Ragiadakou@amd.com,
	Alejandro.GarciaVallejo@amd.com
Subject: Re: [RFC] xen/x86: allow overlaps with non-RAM regions
Message-ID: 
References: 
 
 <775d3ac0-8f43-415a-a32d-14377092b96b@amd.com>
 <554026de-bbb4-488f-95c4-8e2f034d6d0e@amd.com>
 
 <2acad9ba-564a-4d18-9b09-dcabe8f7b025@suse.com>
 
 
 
 <02b6f10a-119e-499c-a51f-8deac6fa6a93@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <02b6f10a-119e-499c-a51f-8deac6fa6a93@amd.com>

On Mon, May 12, 2025 at 10:55:18AM -0700, Lira, Victor M wrote:
> On 5/12/2025 9:16 AM, Roger Pau Monné wrote:
> > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> > 
> > 
> > On Fri, Apr 25, 2025 at 09:47:57AM -0700, Lira, Victor M wrote:
> > > I can confirm with the patch the NVME drive can be accessed despite the "not
> > > mapping BAR" warning from Xen.
> > > Output log attached.
> > Thanks a lot for the test, and sorry for the delay in getting back.  I
> > was busy with other stuff and needed some time to figure out the best
> > way to deal with this.  Can you give a try to the patch below?  I hope
> > it will still fix the issue.
> No worries,  I applied this patch to the latest staging c45e57f59d69, and
> the result is also successful NVME drive access.
> Output log attached and I see no "failed to sanitize" warnings.

Thanks for the testing.

I've formally submitted this as:

https://lore.kernel.org/xen-devel/20250515084123.43289-1-roger.pau@citrix.com/

Functionality wise I think it should be the same as the last patch you
tried.  Could you give it a spin and maybe provide a Tested-by if
suitable?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 15 10:22:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 10:22:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985180.1371130 (Exim 4.92)
	(envelope-from )
	id 1uFVjb-0003MV-SG; Thu, 15 May 2025 10:22:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985180.1371130; Thu, 15 May 2025 10:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFVjb-0003MO-P9; Thu, 15 May 2025 10:22:39 +0000
Received: by outflank-mailman (input) for mailman id 985180;
 Thu, 15 May 2025 10:22:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFVjZ-0003M3-Si
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 10:22:37 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 852e0ebf-3176-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 12:22:36 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43cf06eabdaso7112895e9.2
 for ; Thu, 15 May 2025 03:22:36 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442f33691bbsm66930295e9.7.2025.05.15.03.22.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 03:22: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" 
X-Inumbo-ID: 852e0ebf-3176-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747304555; x=1747909355; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=rN3JTxQbLMU1yugwZ1vPhpcRsorTmqyL+jws3GLwN28=;
        b=BWA9+IWZVxr2wRM1xobowUD7OhQCSSlPQaOPJjAJiqGT0B3tSTOBPM7arim8O665da
         6Pc0dwxgpWQs5564/hsphAVfDYSZYzsIYo0Ik2NCYCRhxyYDB8DnVReaoDAD5IUwJKnN
         hCXOPM6us4/iS6UbsHiKSBOrVnLu0kUSbmUow=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747304555; x=1747909355;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=rN3JTxQbLMU1yugwZ1vPhpcRsorTmqyL+jws3GLwN28=;
        b=iM13mMstq/5oA7uV3M01JmtdJxRHMofE9hJXZA0xmOvQgMID1jMsrGPO0XXLRm+cLT
         VuRTuPy+YKS4jmdVsRb2qW2AWAyUvN0XUOwvJKRW0BF6AHHoNitdLX1SF24SS47noVhV
         wxUjx2VWDWm7NRq2qWWic1dHxVCEp1sirOrGmmEecon8wOD3F5qQQLwDAqlE5MEQHTuA
         nLgr5S3HhfCqqXOXpGvMVVwVxLNnI/8uETLMzCX9p94gwjCuyVuO69ZaVAcSEb5ZWIye
         hc4VlDTnw48qsf1oNVn7zYAlOkBtRpd7Lo7KhGijOvs8HzfuheD25Qh8uNHCEJMPI9G2
         8zpg==
X-Forwarded-Encrypted: i=1; AJvYcCUXYlMGkwaeEd7D6nCLhzGHGdah/MoTH79aSglhlRXMVeTyiNe/+Q2d0WVQKCohJrea9Ye6QeE2eAg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxp9aSBAPbhq+4dmSjectCB0ejRr7BE3jZRQzMgUOi30E0w1dOr
	9tzmFKuDWM9bP4/9E/35PxTUgdINAp1rZgLjO1nm+akgaPG9YJz59/Zfut2DhVA=
X-Gm-Gg: ASbGncuT57FBcHQWgItp2NJA+VUmFz3ZtBVhKxIKNGBb0eB1bBEpxoqEXBBdL26o5lM
	3VazanVTrdgFhh/NU5NJ3102qknepRD2ItG0pAlhqH+wHy27ixrHj3QqtKSD7ENPQRQ9u9dL2bJ
	t5WI21sH97rhW5lrLt7g1Q1P8mbp89JmpYa85BfThdTFKR/ErrnJPrY7xwBmWFw4Io6bcu4evnS
	lJn6+CQG68QbA7JXoHx71e7HHY29bekw/GXUS3mWS5AIA4rPKxymbJoSicnVHTrpkwBcA8CMbNB
	FSUAPzocdAp+zRCXtdBkBCBG9HxOW2QLrd4xGIQHiQ/GFuUDdjTE6aaM
X-Google-Smtp-Source: AGHT+IFlHbuwqPKYHxsH7eTVdzzM/XOLPIV1kXLHns5NQwTRDKgN8/u1J0GfPRQ9CVnckOrfInEeRg==
X-Received: by 2002:a05:600c:1da9:b0:43d:fa59:be39 with SMTP id 5b1f17b1804b1-442f971a7c1mr16734015e9.33.1747304555453;
        Thu, 15 May 2025 03:22:35 -0700 (PDT)
Date: Thu, 15 May 2025 12:22:34 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 5/9] x86/mtrr: use memory_type_changed() in
 hvm_set_mem_pinned_cacheattr()
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-6-roger.pau@citrix.com>
 <853ffc16-f14b-44fa-9e71-4fae8377fa95@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <853ffc16-f14b-44fa-9e71-4fae8377fa95@suse.com>

On Mon, May 12, 2025 at 05:04:56PM +0200, Jan Beulich wrote:
> On 06.05.2025 10:31, Roger Pau Monne wrote:
> > The current logic partially open-codes memory_type_changed(), but doesn't
> > check whether the type change or the cache flush is actually needed.
> > Instead switch to using memory_type_changed(), at possibly a higher expense
> > cost of not exclusively issuing cache flushes when limiting cacheability.
> > 
> > However using memory_type_changed() has the benefit of limiting
> > recalculations and cache flushes to strictly only when it's meaningful due
> > to the guest configuration, like having devices or IO regions assigned.
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> Hmm, I'm not convinced this is a win. This operation isn't normally used on
> a running guest, aiui.
> 
> What's more, this heavily conflicts with a patch posted (again) over 2 years
> ago [1]. Unless there's something severely wrong with that (and unless your
> patch would make that old one unnecessary), I'm again of the opinion that
> that one should go in first. It is becoming increasingly noticeable that it's
> unhelpful if posted patches aren't being looked at.

I'm happy for your change to go in first, but I think that
memory_type_changed() should be adjusted to contain the extra checks
that you add in your patch, and then hvm_set_mem_pinned_cacheattr()
should be switched to use memory_type_changed() rather than
open-coding it.  For once it would miss the adjustment done to
memory_type_changed() to only flush the cache when there's a
meaningful change to the p2m (iow: p2m_memory_type_changed() is not a
no-op).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 15 10:29:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 10:29:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985194.1371148 (Exim 4.92)
	(envelope-from )
	id 1uFVpj-0004KC-MY; Thu, 15 May 2025 10:28:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985194.1371148; Thu, 15 May 2025 10:28:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFVpj-0004K5-K2; Thu, 15 May 2025 10:28:59 +0000
Received: by outflank-mailman (input) for mailman id 985194;
 Thu, 15 May 2025 10:28:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFVpj-0004Jz-7d
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 10:28:59 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 68d84737-3177-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 12:28:58 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-441c99459e9so4966525e9.3
 for ; Thu, 15 May 2025 03:28:58 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442eb8c92d9sm50550685e9.2.2025.05.15.03.28.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 03:28:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 68d84737-3177-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747304937; x=1747909737; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=83ukkjGSozxeq111dikbc9RWgGdmH0Nw4voTK63QNPQ=;
        b=u4GKMQ1eAwtadiked7u/bKpRYyY/bcDNHoSPabYQ6S27//odwZjFUyiZ7s4spE1FzT
         F89pHrEsOJTmkDoQpAZzlWCP1uJnIfVLjrHzzZd45UIqA4h+xRB/7kyDa/y3kh77anHh
         rAzZ9XRxhHm4c+CDbbYEkF3W6V3X0HsaldKII=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747304937; x=1747909737;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=83ukkjGSozxeq111dikbc9RWgGdmH0Nw4voTK63QNPQ=;
        b=gPVquYF7p5NzbaDZAhm7DdMwjyBN6L24zN60ksrNrs7B2nb6ryHSSdndf/2K+mtUe6
         kUTjiXTegPF6rNxy/w1etUkTxQBUD5C6SJLwVslFdwMvvOfhbKPxLhMvuZjgLLvsXKQ0
         /kbdCJxZUb12i5kV5dAH5DfbFU+fT5byWeD2XclwVtF71S8DL8sMXKCtdR+d0wscbEbx
         S3FXZQaOFywskBgdURRAvc7ccT8dOT6MJtx0X5CALd9hp0crpUAMcrJx53q17jFWsL+2
         zSYVY22U/srL40VsWN2hV02wkW+FAGvEOva09wZ4vUNYza+XGyD4u1Og3RBKz2s7z14b
         sEfw==
X-Forwarded-Encrypted: i=1; AJvYcCUGZamTjd5m39qZzyvzPdX3vqPEEspYsoYilOE8+Uw/BiyYgaI+dXs9hRJONeP327Rouxbq1tmeSzM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzveJZQkOHcL2GeN69aU086dNv2Gn+7r0+Nd+Sj+GrGkkLR1Pu5
	ajBr4BxPZ+JhTmJTBIcxE1pj9RCzGLva0i8tHGAB+u53Mil/gY3ECSfrGKDLKJM=
X-Gm-Gg: ASbGncvpXX0H0s31W5oOr7rdIAFe7QXz2IrtgUW87UpFNf5X7UDUnrZs+VNrNfqarPg
	k/F8/Zkf7Na0Q09VVnC8vhRFIAJFFwQ3WCtq1vb04Olk0dQI/BdXDUeghhcGyEgbyP9nZml3x84
	x4Hyx6mF7p6RzX3yovPiT2JHjeo5ry8hiWI9i2qh7+3OLGTwmBpDGmf57k8ZzU6KPQ1tGhzp4ZB
	fTpkPbnlczO6/hLsKW0T/EhfSr1qza6y5egemUmKOpc4BiIahny0wvzl/xbR2fR/A6+KztWrX35
	9wB0VjLNRFycpWu1+Wj3EIQOXKyMZLQ4TONNSYfS+62F95AT7D4Pe9YM
X-Google-Smtp-Source: AGHT+IFcMuAcvk+FEj1nEvjWsPn5WPwC/MaGL8i4T+JbdBBPHtz995ExrU5heh5ti0YNBzpP8XwMCg==
X-Received: by 2002:a05:600c:3f08:b0:442:e0f9:394d with SMTP id 5b1f17b1804b1-442f216961dmr71380645e9.24.1747304937351;
        Thu, 15 May 2025 03:28:57 -0700 (PDT)
Date: Thu, 15 May 2025 12:28:55 +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 7/9] xen/x86: rename cache_flush_permitted() to
 has_arch_io_resources()
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-8-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Mon, May 12, 2025 at 05:16:02PM +0200, Jan Beulich wrote:
> On 06.05.2025 10:31, Roger Pau Monne wrote:
> > To better describe the underlying implementation.  Define
> > cache_flush_permitted() as an alias of has_arch_io_resources(), so that
> > current users of cache_flush_permitted() are not effectively modified.
> > 
> > With the introduction of the new handler, change some of the call sites of
> > cache_flush_permitted() to instead use has_arch_io_resources() as such
> > callers are not after whether cache flush is enabled, but rather whether
> > the domain has any IO resources assigned.
> > 
> > Take the opportunity to adjust l1_disallow_mask() to use the newly
> > introduced has_arch_io_resources() macro.
> 
> While I'm happy with everything else here, to me it's at least on the
> edge whether cache_flush_permitted() wouldn't be the better predicate
> to use there, for this being about ...
> 
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -172,8 +172,7 @@ static DEFINE_SPINLOCK(subpage_ro_lock);
> >  
> >  #define l1_disallow_mask(d)                                     \
> >      (((d) != dom_io) &&                                         \
> > -     (rangeset_is_empty((d)->iomem_caps) &&                     \
> > -      rangeset_is_empty((d)->arch.ioport_caps) &&               \
> > +     (!has_arch_io_resources(d) &&                              \
> >        !has_arch_pdevs(d) &&                                     \
> >        is_pv_domain(d)) ?                                        \
> >       L1_DISALLOW_MASK : (L1_DISALLOW_MASK & ~PAGE_CACHE_ATTRS))
> 
> ... cachability, which goes hand in hand with the ability to also
> flush cache contents.

Hm, I was on the edge here, in fact I've previously coded this using
cache_flush_permitted(), just to the change back to
has_arch_io_resources().  If you think cache_flush_permitted() is
better I'm fine with that.

> Tangentially - is it plausible for has_arch_io_resources() to return
> false when has_arch_pdevs() returns true? Perhaps there are exotic
> PCI devices (but non-bridges) which work with no BARs at all ...

I guess it's technically possible, albeit very unlikely?  How would
the OS interact with such device then, exclusively with PCI config
space accesses?

I'm happy to just use cache_flush_permitted() which is likely more
correct given the context here.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 15 10:44:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 10:44:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985202.1371159 (Exim 4.92)
	(envelope-from )
	id 1uFW4R-0007IN-Vd; Thu, 15 May 2025 10:44:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985202.1371159; Thu, 15 May 2025 10:44: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 1uFW4R-0007IG-SA; Thu, 15 May 2025 10:44:11 +0000
Received: by outflank-mailman (input) for mailman id 985202;
 Thu, 15 May 2025 10:44:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFW4R-0007IA-2r
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 10:44:11 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8855d6ea-3179-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 12:44:09 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43cf257158fso5371395e9.2
 for ; Thu, 15 May 2025 03:44:09 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442f39e852fsm67759265e9.27.2025.05.15.03.44.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 03:44: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" 
X-Inumbo-ID: 8855d6ea-3179-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747305849; x=1747910649; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=N5A5ze9++jixZm+Ncscv5mJmZLzS6LZbUHutAhH+rzQ=;
        b=chvoF52OZQVzSoFI8e998uS2fmlCA/n5V1U2kbKh20E4OeYgJqkuef2WKRfTqs+k6H
         0ZbUACaMNSvtJnCAbXElcN69FLopicGl6gtTNIGS2j1a1XNT3rrrtfH9RzN17Kjg2y1R
         6HrQ48XuMwCR6xMSXHb63oSGfMKd2ViQ7aK9Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747305849; x=1747910649;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=N5A5ze9++jixZm+Ncscv5mJmZLzS6LZbUHutAhH+rzQ=;
        b=n9rZ25FkDvb5mZPDJkB8wZRLNDOqgbtuqmaojfOSuWme4F/Vr1ExjUgvo55zZey/51
         +3O6EFbAQqvxhco1/w5ICZe7btZtj3wtMX1NsH2PqD8S39kB23bFEjq6+DglgS2I7rqw
         TWiH0hVaMT1qo27HweMZ4/JAl3UyCyIxSLb4NtbdyTPKGJE8YFs7rvHU6LkWI9jxUjHV
         8l2ojvzvYw6koiCseVreTERHInqqEvec/1+PN2JN1FUubeY7Y+iDrixd7lKjmN6aX1eo
         HO7BmwJ0pXENuSB7bL7roG8eDc0VFyTuCVl/WOWLiKqsHslBevljFuIUwXI73ys4V1MK
         9kKQ==
X-Forwarded-Encrypted: i=1; AJvYcCWXyOCvGHYCFg1jQCu1XO3QyTI/9N/5pSz22F9K930UuDkx+w75KdHBWq9Ny3Cwutv+DoVy6vfvD4I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxcJk7iQRPtXM32XjrQ1eElyoh9sR/7za9n7VVicpRJ3CWMMxnM
	/3yxoqKTTg0+aeh8S2lRNCHbCreBFASdtv7IuFwdVx91owPFmomtyUX2jZ4mWf4=
X-Gm-Gg: ASbGncsaS53vxOWWdSNPBn51rvZ9XShrbYxMOG1WYuQ5rB6d0ON7mfudONGk7AtwFyt
	WNbCCYJWDF8Mh4NdB0KhoUQlI0nOozvSkEBF9H8L4R3OXXNKuYGmsxJVZazYim05iPJe+RWb+l1
	Jdq90+KzvZ+1yGvRHxvqzRbyHFw8r2+ezn2bc1PlvoMpXKxPeIdokvWH+9iycHa8DYtIoiCu098
	wtrgxnVdKFcjZ4IPBn004H8xwEnHPGTUrQuFluT2niyfb7w+RZHlnX5JoguLjxCyJ2ePkZ1NHsT
	O3dPYNGsqfNyqBdTE2e0mjpHqAvcZrarZ4m7y1HhnFj14sJDmjkuP0VN
X-Google-Smtp-Source: AGHT+IGBYei+d349jZv3zDg10rwljFD6NsKvgunQvWuYu6rmKk45N7oLZyEsJimcejTqH+Bk6zIWDA==
X-Received: by 2002:a05:600c:1f15:b0:43b:ce36:7574 with SMTP id 5b1f17b1804b1-442f96e70f7mr16998615e9.11.1747305849210;
        Thu, 15 May 2025 03:44:09 -0700 (PDT)
Date: Thu, 15 May 2025 12:44:08 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Christian Lindig ,
	David Scott ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 8/9] xen: introduce flag when a domain requires cache
 control
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-9-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Mon, May 12, 2025 at 05:24:01PM +0200, Jan Beulich wrote:
> On 06.05.2025 10:31, Roger Pau Monne wrote:
> > Such flag is added to the domain create hypercall, and a matching option is
> > added to xl and libxl to set the flag: `cache_control`.  When the flag is
> > set, the domain is allowed the usage of cache control operations.  If the
> > flag is not explicitly set, libxl will set it if the domain has any `iomem`
> > or `ioports` ranges assigned.
> > 
> > Modify cache_flush_permitted() helper so that it's return value is no
> > longer based on the IO resources assigned to the domain, but rather whether
> > the domain has been explicitly allowed control over the cache, or if it has
> > IOMMU support and there's a single IOMMU in the system that doesn't allow
> > forcing snooping behind the guest back.  As a result of this, the return of
> > cache_flush_permitted() is constant for the lifetime of a domain, based on
> > the domain creation flags and the capabilities of the IOMMU if enabled
> > for the domain.
> 
> This then further emphasizes the remark made for patch 7.

Hm, I think you are referring to the remark about how PCI device
without IO resources would be handled then, and what would
cache_flush_permitted() return then?

IMO the benefit of the approach presented here is that it aims to know
whether a domain needs cache control to be set at creation time, and
not altered during it's runtime.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 15 10:53:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 10:53:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985227.1371169 (Exim 4.92)
	(envelope-from )
	id 1uFWCu-0000ks-O4; Thu, 15 May 2025 10:52:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985227.1371169; Thu, 15 May 2025 10:52: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 1uFWCu-0000kl-LK; Thu, 15 May 2025 10:52:56 +0000
Received: by outflank-mailman (input) for mailman id 985227;
 Thu, 15 May 2025 10:52:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFWCt-0000kf-48
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 10:52:55 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1006885-317a-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 12:52:54 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-442eb5d143eso7964295e9.0
 for ; Thu, 15 May 2025 03:52:54 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442f39790afsm67884525e9.33.2025.05.15.03.52.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 03:52: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" 
X-Inumbo-ID: c1006885-317a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747306374; x=1747911174; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=0Bjpx8xeuIKdKe0E9Jue5bQGOeyoMaCdb+CniORXdxA=;
        b=UFeADO0cTrf0Cn5U0cPPtl8rWFiwdeDzWrRZT6o2/DWdpLxrSAozQQgRB8ee2//SWk
         q3e31ltGSqwd1qCxy3ag+di1q7DowDhhSNWPfK4FNFo1Mwm2NnsVjtgyfbM1bc6arYEt
         c3iE6WBA1Lx8jR+ufrmbjL2LDqndAZ6H+tVH8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747306374; x=1747911174;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=0Bjpx8xeuIKdKe0E9Jue5bQGOeyoMaCdb+CniORXdxA=;
        b=V4CYmj0A7Kx2EkiisTWwmVIp88cyVdy4b+VvLMe6qE51NpwWo3boLlunJVn/TBBYga
         9CrMZkDx7nKmIkQTUCNkcV7j8z1Csz1HBNsG8GAKUW5hacoDp/qIAfyFZuf4cSVDY3p1
         yn2ac2KjUj7gLEmnQYI/CcI1dn8aHPENutEAgAtAi9dGcBupKwHnjHYAs77UzRQ87GdO
         BNBz9zLvBXgkTi4rAQcaYATC/3exKjrA7+diZILq1ASS/V56oqTLQ7MGamSe4y2CdzQj
         JdEcaRWW3e8DhiehpEyOwBGQdexK72Cy7R1Yz+nsCmquDTs4lXjqA3nXfeVVVUND+OEX
         cB+w==
X-Gm-Message-State: AOJu0YyLWbzPPjzH/nPOPqyKkGZ2DynHjEYkwSJ0aslHpKS8kDEsa9J9
	ntw/kb9vYvI5bdfzL0ObFY8kYuso+ZwtxbQUumgqC5B2ckEMrbJAT+kYauOu1r0=
X-Gm-Gg: ASbGncsp0xd1XDdo2oIEaNSy6U/19gROYdiBGbe2DrddWMLDdSH4m70rXjtKkxbPAY9
	JSa9RXb3BhcWPH2UC+ZQbawYW2sGereIukG97VGUSSTRgHPZzfKq7lUh9ymI4Xosj6QTOCbu7EC
	EB3oRyPedCsb25sNdLp8pjuX3iy4vjo99NyxDQw8reN627gECuY2U/trcRVytBf8EmuM/Oz4zLQ
	GqS77QZsS/Ce6Gkxkc5w2QIqTJw8cvbBawwLDeI0wNrJ5i/Nc22kReKEa8GP/2R6Q4ntnnVzdwA
	VOXGixxENBkB+dN4JOWrtoKjuVXq+epzdGeqXy3l5ao0beROdQWJmgks
X-Google-Smtp-Source: AGHT+IFoIlvaDZtEjSlz1mEDOFQUxUYAUunagWi6gl1znQsJVyBfETmsffu9wkNRelMux2CT6mEGKA==
X-Received: by 2002:a05:600c:3b02:b0:43c:ee3f:2c3 with SMTP id 5b1f17b1804b1-442f20bae1emr59186435e9.7.1747306373780;
        Thu, 15 May 2025 03:52:53 -0700 (PDT)
Date: Thu, 15 May 2025 12:52:52 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper 
Subject: Re: [PATCH 9/9] xen/x86: track dirty pCPU caches for a given vCPU
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-10-roger.pau@citrix.com>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Mon, May 12, 2025 at 05:38:07PM +0200, Jan Beulich wrote:
> On 06.05.2025 14:55, Roger Pau Monné wrote:
> > On Tue, May 06, 2025 at 12:16:00PM +0100, Andrew Cooper wrote:
> >> On 06/05/2025 9:31 am, Roger Pau Monne wrote:
> >>> When a guest is allowed access to cache control operations such tracking
> >>> prevents having to issue a system-wide cache flush, and rather just flush
> >>> the pCPUs where the vCPU has been scheduled since the last flush.
> >>>
> >>> Note that domain-wide flushes accumulate the dirty caches from all the
> >>> vCPUs, but clearing the vCPU masks will require pausing all vCPUs, which
> >>> seems overkill.  Instead leave the vCPU dirty masks as-is, worse case it
> >>> will result in redundant flushes in further calls.
> >>>
> >>> Signed-off-by: Roger Pau Monné 
> >>
> >> I'm afraid this doesn't work.
> >>
> >> Unlike TLBs, dirty cacheline can move sideways, e.g. by foreign or grant
> >> mapping, but also naturally because of how cache coherency works.
> > 
> > Does such sideway moving also imply that local WB{NO,}INVD on native
> > could be equally bogus?
> > 
> > According to the SDM, cache lines can indeed move between processor
> > caches, but the memory controller must always snoop such moves and
> > flush the data to memory:
> > 
> > "Here, the processor with the valid data may pass the data to the
> > other processors without actually writing it to system memory;
> > however, it is the responsibility of the memory controller to snoop
> > this operation and update memory."
> > 
> > So a cache line moving sideways will always be propagated to memory as
> > part of the move, and hence the data in the previous pCPU cache will
> > always hit memory.
> 
> But that's only one of the two aspects of a flush. The other is to ensure
> respective data isn't in any (covered) cache anymore. IOW dirty-ness (as
> the title has it) isn't a criteria, unless of course you mean "dirty" in
> a sense different from what it means in the cache coherency model.

Given the direct map, and the fact that the CPU can speculatively load
entries in the cache, I'm not sure there's much Xen can effectively do
ATM to ensure a certain cache line it's not in any cache anymore.

It would possibly get better if/when the direct map is removed, but
even then Xen (or dom0) might map guest memory for emulation or IO
purposes.  Then Xen/dom0 would need to issue a wbinvd after unmapping
the memory, to ensure the cache is clean in case a vCPU from a domain
is scheduled there.

IMO being realistic it is very unlikely for Xen to be able to ensure
that after a guest wbinvd there are no guest owned cache lines in any
CPU cache, even if such wbinvd is propagated to all host CPUs.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 15 11:33:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 11:33:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985265.1371187 (Exim 4.92)
	(envelope-from )
	id 1uFWq3-00066S-Pq; Thu, 15 May 2025 11:33:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985265.1371187; Thu, 15 May 2025 11:33: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 1uFWq3-00066L-Mt; Thu, 15 May 2025 11:33:23 +0000
Received: by outflank-mailman (input) for mailman id 985265;
 Thu, 15 May 2025 11:33:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFWq2-00066F-9v
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 11:33:22 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6776e12a-3180-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 13:33:21 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ac2bb7ca40bso130919866b.3
 for ; Thu, 15 May 2025 04:33:21 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad2197463e2sm1104637266b.108.2025.05.15.04.33.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 04:33: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" 
X-Inumbo-ID: 6776e12a-3180-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747308800; x=1747913600; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=/uPC8op9eqfgshTJO3VMTtIZaMAGH6UK0WN0vRIaoxw=;
        b=TprzGvc2S+n8A17ALwg6VpoEK4eAzo5ZzvaVVTuixYTrtJtpmpSbfXYneqWi7znEaW
         UgQuvKsK6IzrUTpvV+qYsZjjLYmgpa2tWpwI09kPNVITqOtXH4ulTV4TZRR2TAf9YsY4
         N+4wHTavuYgigvlZoRR/xoYSin9AoW2W+e2gMFVTm+DbK8nSvk0PDHDm+WVLc8SLWZo/
         uyzn5zVxFlu0h41tkLAgn2pFT76h5971Dul1cEPj340lTubTNg61bn1wCvhrXfitidY9
         MM3PC6scZYQuF/WJZZP+Lgfy8dL4p0ihKEfQOkZj9YPD66W15im+u74UGcBCtY6i41HP
         LrXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747308800; x=1747913600;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=/uPC8op9eqfgshTJO3VMTtIZaMAGH6UK0WN0vRIaoxw=;
        b=pm8XBpjBVj0YQa4cZYJZotN7vny0kmCscHxUax/7sa7BO6FEceQOuvNXYuXiMiMaV0
         0RQBU0HHIS7BogFOdsNuOoWvfaioj39wjaLf3Kcei7aYocgXVZdF+1HyOyvmtwFrcsRZ
         +mxog/6NLIlmwFa6PwS1LeM7Zf3aJZ6eY40vZ4S33qLY2jN22NEwnKh3tlTl37VsWjvV
         ufvDHvmTvDVWSeG21pUWGqXarkq3IIr/X+HO+s4u4F2LPCYJktYgljXU6l1FUDMOnsq7
         f7I+GOyWtjttPE8tPjUomZ/oNHRru08qkmipV4FkkeXXjznLRY8YK6Mx2YBtwyS0scJP
         wp8w==
X-Forwarded-Encrypted: i=1; AJvYcCX5GwPNzYxy93ISNVceXh8YX/ORvkAgIWheV9ZiYbODgx80VN5WcGY2Ww+S8urRg5bqhbOXEhgU2Cc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxHDK+4N3BGqUcUranJblk7zRA3u98FF+YDRp8KCdjmHYIUbttt
	1rNYp1vfuHKOp5Snx72X1lwc0+fug0fkEKaBHiSEH9x7ptHRC8JT8Vjo+fXH490=
X-Gm-Gg: ASbGncsN5pUx36AxGVFFvG85zbypywHMqv0rLP0JwsoN+eF0FaGlYmCg0GSBSel0rgb
	9D3sYHanX7YVEYZ4OtK4kYkS1RBFI0S2ODlQkR2yUlgO5n/KjUn7HcJMUGQ8+ZVbyR4pY6KBr/j
	/w4sDzZ4SHaKtBQrEojqzxgd4caGfUSuvYz4f9sTdEpuBjZ735hc2GzcJBmLbVfkepCVdTIjbrM
	CkqW+vYBCtH27AJ7NPEWb5C2s0sj2YCnxMjU8WRKmhTHBVQPsuT/72xO8rrHavVZB0pxt39F59h
	FXu/99vRySYOCYzSUOhV/V69Iu8NH4a7ybTkR4TgyhDjQLnzHIovENJKQQQWuavBdMN4HQUHsPG
	mQ5s+cl1Y+UgpeMBQhPlghmWAAgOB1An83XrDaW2yyED+mIXq/45WDj81lE13TVodMx07YZmDTE
	MH
X-Google-Smtp-Source: AGHT+IHlGVedvpqU0DF0OZhYlDd8LjUzHMxDqxeKfjY7SYS5goDcj5zWvFEkZaJCi2ymr6WdWH6jRA==
X-Received: by 2002:a17:907:60cc:b0:ad4:d069:324b with SMTP id a640c23a62f3a-ad4f70fba45mr731369166b.10.1747308800472;
        Thu, 15 May 2025 04:33:20 -0700 (PDT)
Message-ID: <212b2be3-5841-4e7f-84d7-4b3653054481@suse.com>
Date: Thu, 15 May 2025 13:33:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: call uaccess_ttbr0_enable for dm_op hypercall
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: Julien Grall , Bertrand Marquis
 , Michal Orzel ,
 Volodymyr Babchuk ,
 linux-kernel@vger.kernel.org, stable@kernel.org
References: 
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------2dPoy037AoV5uWm6Nw8JM3Na"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------2dPoy037AoV5uWm6Nw8JM3Na
Content-Type: multipart/mixed; boundary="------------y5MlRn3dT02iY3thmAEmeFaC";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: Julien Grall , Bertrand Marquis
 , Michal Orzel ,
 Volodymyr Babchuk ,
 linux-kernel@vger.kernel.org, stable@kernel.org
Message-ID: <212b2be3-5841-4e7f-84d7-4b3653054481@suse.com>
Subject: Re: [PATCH] xen/arm: call uaccess_ttbr0_enable for dm_op hypercall
References: 
In-Reply-To: 

--------------y5MlRn3dT02iY3thmAEmeFaC
Content-Type: multipart/mixed; boundary="------------k87NbxI1LBnN02LDBuwpuKIA"

--------------k87NbxI1LBnN02LDBuwpuKIA
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTIuMDUuMjUgMjM6NTQsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gRnJvbTog
U3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxpbmlAYW1kLmNvbT4NCj4gDQo+
IGRtX29wIGh5cGVyY2FsbHMgbWlnaHQgY29tZSBmcm9tIHVzZXJzcGFjZSBhbmQgcGFzcyBt
ZW1vcnkgYWRkcmVzc2VzIGFzDQo+IHBhcmFtZXRlcnMuIFRoZSBtZW1vcnkgYWRkcmVzc2Vz
IHR5cGljYWxseSBjb3JyZXNwb25kIHRvIGJ1ZmZlcnMNCj4gYWxsb2NhdGVkIGluIHVzZXJz
cGFjZSB0byBob2xkIGV4dHJhIGh5cGVyY2FsbCBwYXJhbWV0ZXJzLg0KPiANCj4gT24gQVJN
LCB3aGVuIENPTkZJR19BUk02NF9TV19UVEJSMF9QQU4gaXMgZW5hYmxlZCwgdGhleSBtaWdo
dCBub3QgYmUNCj4gYWNjZXNzaWJsZSBieSBYZW4sIGFzIGEgcmVzdWx0IGlvcmVxIGh5cGVy
Y2FsbHMgbWlnaHQgZmFpbC4gU2VlIHRoZQ0KPiBleGlzdGluZyBjb21tZW50IGluIGFyY2gv
YXJtNjQveGVuL2h5cGVyY2FsbC5TIHJlZ2FyZGluZyBwcml2Y21kX2NhbGwNCj4gZm9yIHJl
ZmVyZW5jZS4NCj4gDQo+IEZvciBwcml2Y21kX2NhbGwsIExpbnV4IGNhbGxzIHVhY2Nlc3Nf
dHRicjBfZW5hYmxlIGJlZm9yZSBpc3N1aW5nIHRoZQ0KPiBoeXBlcmNhbGwgdGhhbmtzIHRv
IGNvbW1pdCA5Y2YwOWQ2OGI4OWEuIFdlIG5lZWQgdG8gZG8gdGhlIHNhbWUgZm9yDQo+IGRt
X29wLiBUaGlzIHJlc29sdmVzIHRoZSBwcm9ibGVtLg0KPiANCj4gU2lnbmVkLW9mZi1ieTog
U3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxpbmlAYW1kLmNvbT4NCj4gRml4
ZXM6IDljZjA5ZDY4Yjg5YSAoImFybTY0OiB4ZW46IEVuYWJsZSB1c2VyIGFjY2VzcyBiZWZv
cmUgYSBwcml2Y21kDQo+IGh2YyBjYWxsIikNCj4gQ2M6IHN0YWJsZUBrZXJuZWwub3JnDQoN
CkknbSBub3QgYW4gQXJtIHNwZWNpYWxpc3QsIGJ1dCBsb29raW5nIGF0IHRoZSBzdXJyb3Vu
ZGluZyBjb2RlIHRoaXMNCnNlZW1zIHRvIGJlIGNvcnJlY3QuDQoNClJldmlld2VkLWJ5OiBK
dWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K
--------------k87NbxI1LBnN02LDBuwpuKIA
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-----

--------------k87NbxI1LBnN02LDBuwpuKIA--

--------------y5MlRn3dT02iY3thmAEmeFaC--

--------------2dPoy037AoV5uWm6Nw8JM3Na
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/Ey8FAmgl0P8FAwAAAAAACgkQsN6d1ii/Ey9y
9gf/Q9/eu+UxUlKAd28X7c6Fc1sPSNE6RyrAYzJaD0oVh8qFklBk4lzk4U8aDHndUYIgEfLRCdwC
ijJfQAApS6wm1ef5ryzET4AV8St1ZDe8mM9vdMq/Qypu1+vKtvKEJyHajPkr+C0IKtdIqmDe8h3B
+r66WqJaFWMZ9j5ViL7wTx0wDa3BKPXzGzIVU3uwnP0jzeemEFnPjwKKDV3A8xpNx1dbF9ajTQQI
DEskoh6X+JYoBCemAeyiqF1G2WGxHcrpaIg6PiKeye8bKIETZl1Gb0opKFMpzbAC1Vr2cqSFFN62
wlOuP2L/MpQWBXZLQkLCjaglGRRfK7PqGot+u+eZWw==
=p318
-----END PGP SIGNATURE-----

--------------2dPoy037AoV5uWm6Nw8JM3Na--


From xen-devel-bounces@lists.xenproject.org Thu May 15 13:17:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:17:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985302.1371196 (Exim 4.92)
	(envelope-from )
	id 1uFYSk-0000sk-On; Thu, 15 May 2025 13:17:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985302.1371196; Thu, 15 May 2025 13:17: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 1uFYSk-0000sd-M5; Thu, 15 May 2025 13:17:26 +0000
Received: by outflank-mailman (input) for mailman id 985302;
 Thu, 15 May 2025 13:17:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYSj-0000sX-Us
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:17:26 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id efa6b602-318e-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:17:24 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 17473150271861007.3349597653466;
 Thu, 15 May 2025 06:17:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: efa6b602-318e-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315029; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=kZZSd+V3O1JfJRs4z1zVVzbz8IXBzyImXeOGJR6ssFtmX1WEoP2pV26oafydzGyM9/R0tp6/QlxRuGetHa8YHVLgasNwysLtrjWRXJQpuOmP/SfCbDlEJJ8q02S76wBl/VOkwSSL1zJdvlL/Ogg+vkUbU/dhtfOsYRo9Q0ElvxQ=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315029; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=jiLbtrMvncYayUl29uENdWFWd2gbfaEXU+v4Q4UEHzA=; 
	b=BhJh2uJcnYMrYQk7RVuVOvSb7M7D8wWUXyaaKK2T4lZFaMsfeKy+6YbzmTwxL4k3LzaSf4Nz1S0DMMRO8UAa2Nk0HdCnExaVeMsnYvCqSHzzO7WcVfnaQKMi4e3qucdW8JnVOzdlKg54Lw7jQpZH5qK5KWgrjKjIAiJ+BDUrj/E=
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=1747315029;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=jiLbtrMvncYayUl29uENdWFWd2gbfaEXU+v4Q4UEHzA=;
	b=jiyh8dvdmn7HMojU9W2sUfrpKvWrY5g8lIJCES04zrn7FZEU7OWopEWCd8QkNGd/
	lfxZMnMsVNkNNgcyq1wzhrvIdFHB4lS1Kn/NNQoGGDMh5gCx3wq/l0GzYUyk6Ez9aww
	sep+z1FFAkqXUfuClIfD0ix+8NPEMqdnHahL2oRk=
Message-ID: 
Date: Thu, 15 May 2025 09:17:05 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 02/12] common/hyperlaunch: introduce the domain builder
Content-Language: en-US
To: Jan Beulich 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Jason Andryuk , Denis Mukhin ,
 Alejandro Vallejo , xen-devel@lists.xenproject.org
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-3-agarciav@amd.com>
 <9021c878-9605-4d6e-95b8-ab97da186542@apertussolutions.com>
 <29a55d44-c26e-4834-b93b-47cbd98f885e@suse.com>
From: "Daniel P. Smith" 
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: <29a55d44-c26e-4834-b93b-47cbd98f885e@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 5/2/25 03:21, Jan Beulich wrote:
> On 30.04.2025 20:56, Daniel P. Smith wrote:
>> On 4/29/25 08:36, Alejandro Vallejo wrote:
>>> --- a/xen/common/Makefile
>>> +++ b/xen/common/Makefile
>>> @@ -11,6 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
>>>    obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
>>>    obj-$(CONFIG_IOREQ_SERVER) += dm.o
>>>    obj-y += domain.o
>>> +obj-$(CONFIG_DOMAIN_BUILDER) += domain-builder/
>>
>> Please don't do this, use IF_ENABLED in core.c and then hide the
>> unnecessary units in domain-builder/Makefile as I originally had it.
>> This allows for a much easier time incrementally converting the dom0
>> construction path into a generalized domain construction path.
> 
> That is, are you viewing this as a transitional thing only? If the end
> goal is to have it as Alejandro has it above, that may be acceptable
> (even if not nice).

In the end, it became too much of a mess to keep the core builder 
functions with the fdt code in common. So I left this as is, and kept 
all the builder logic in x86/domain-builer/core.c.

v/r,
dps




From xen-devel-bounces@lists.xenproject.org Thu May 15 13:18:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:18:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985306.1371207 (Exim 4.92)
	(envelope-from )
	id 1uFYTL-0001JT-1J; Thu, 15 May 2025 13:18:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985306.1371207; Thu, 15 May 2025 13: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 1uFYTK-0001JM-Ud; Thu, 15 May 2025 13:18:02 +0000
Received: by outflank-mailman (input) for mailman id 985306;
 Thu, 15 May 2025 13:18:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYTJ-0001J6-UA
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:18:01 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0596ba8e-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:18:00 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315071104666.9716373647635;
 Thu, 15 May 2025 06:17: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" 
X-Inumbo-ID: 0596ba8e-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315073; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=faX6nSsGO58O1nIxYucS98oBwIQly17YAiRMmQ1WNCdjvR7Z9FrGErfV778wGoAei7f6wMULXQopzcnDp7rRXwXrAWo/4SpT/p90f52BmCgmvZKgwKHs75swWecRk9h6bbGc9bzDPDcK5wytpJtue1YGkPxCw0ZtfqCRboZZra4=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315073; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=Q/A32VJqv7n9/PtkY06URGkF1PXb70iXPAI3jSPTTiQ=; 
	b=kBYC+3ZiKOaLO5vPLX9sh1u0n8xWIEGzffbuOqB8QFyx5ix+jWweTf4zFT2NtfrtLiDdMUKvTHjunBF+UjCh4zWOjgrH/SPCJtYJBQiskrp6gdDTDEYddemI8HttNPOv4pBfi4eJTxFrO2iESzrlfKcK8ZcrbKndbQ+0v1ySYVI=
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=1747315073;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=Q/A32VJqv7n9/PtkY06URGkF1PXb70iXPAI3jSPTTiQ=;
	b=d6qIUR3OWFtSzfRoAetJlMAA5mN2e+Y/4aCDC4DOufih1tJPmzHvNcLWhxdHU+VY
	Ye1q6V6cJo0Icc1nGFNTEmIM9Zo8dlV3Qp0BJlYS3TklTx20u1nMEyqyr7vNPd2Qqjk
	zER5/ZOoYAxFB5Rrh1V98yrl2OQb0cK9C3DYt5wc=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com
Subject: [RFCv2 00/38]  Hyperlaunch domain builder
Date: Thu, 15 May 2025 09:17:06 -0400
Message-Id: <20250515131744.3843-1-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

NOTE: Sending this series as an RFC as it is a follow-on to the hyperlaunch
dom0 device tree series going through rounds of review right now. This
iteration of the RFC series is based off of v6 of the dom0 device tree series.

The Hyperlaunch domain builder series is the third split out for the
introduction of the Hyperlaunch domain builder logic. These changes focus on
introducing the ability to create multiple PVH domains at boot. The definition
for those domains will come from the Device Tree capability introduced in the
dom0 device tree series.

Significant Changes in v2:
- bzimage renetrant was dropped for a proper refactoring of kernel headroom and
  expansion
- While there is concern on the affect for pv construction, event channel
  allocation has been delayed to a newly introduced builder_finalize function
  called after all construction has completed


Documentation on Hyperlaunch:
https://wiki.xenproject.org/wiki/Hyperlaunch

Original Hyperlaunch v1 patch series:
https://lists.xenproject.org/archives/html/xen-devel/2022-07/msg00345.html

V/r,
Daniel P. Smith

Daniel P. Smith (38):
  maintainers: add new section for hyperlaunch
  x86/hyperlaunch: correct the naming of domain ramdisk field
  x86/hyperlaunch: convert max vcpu determination to domain builder
  x86/hyperlaunch: convert vcpu0 creation to domain builder
  x86/hyperlaunch: move dom0 cpuid policy behind capability check
  x86/hyperlaunch: introduce pvh domain builder
  x86/hyperlaunch: move initial hwdom setup to dom_construct_pvh
  x86/boot: convert dom0 page calculation to use boot domain
  x86/boot: refactor dom0 page calculation
  x86/boot: generalize paging pages calculation
  x86/boot: generalize compute number of domain pages
  x86/hyperlaunch: move page computation to domain builder
  x86/hyperlaunch: move pvh p2m init to domain builder
  x86/hyperlaunch: move iommu init to domain builder
  x86/boot: move and rename sched_setup_dom0_vcpus
  x86/hyperlaunch: move pvh_setup_cpus to domain builder
  x86/boot: rename pvh acpi setup function
  x86/hyperlaunch: add domu memory map construction
  x86/hyperlaunch: move populating p2m under domain builder
  x86/hyperlaunch: move remaining pvh dom0 construction
  x86/hyperlaunch: relocate pvh_steal_ram to domain builder
  x86/hyperlaunch: add domu acpi construction
  x86/boot: export command line processing
  x86/hyperlaunch: convert create_dom0 to arch_create_dom
  x86/hyperlaunch: remove dom0-isms from arch_create_dom
  x86/hyperlaunch: introduce domain builder general dom creation
  x86/hyperlaunch: introduce arch builder finalize
  x86/hyperlaunch: allocate xenstore for domu
  x86/hyperlaunch: allocate console for domu
  x86/hyperlaunch: introduce concept of core domains
  common/gzip: add function to read isize field
  x86/hyperlaunch: move headroom under domain builder
  x86/hyperlaunch: move kernel extraction under domain builder
  x86/hyperlaunch: introduce multidomain kconfig option
  x86/hyperlaunch: add multidomain construction logic
  x86/hyperlaunch: enable unpausing mulitple domains
  x86/hyperlaunch: generalize domid assignment
  tools: introduce hyperlaunch domain late init

 .gitignore                                |    1 +
 MAINTAINERS                               |   11 +
 tools/helpers/Makefile                    |   12 +
 tools/helpers/late-init-domains.c         |  364 +++++++
 tools/helpers/late-init-domains.h         |   18 +
 tools/helpers/xs-helpers.c                |  117 +++
 tools/helpers/xs-helpers.h                |   26 +
 xen/arch/x86/Makefile                     |    1 +
 xen/arch/x86/bzimage.c                    |   87 +-
 xen/arch/x86/dom0_build.c                 |  120 +--
 xen/arch/x86/domain-builder/Makefile      |    2 +
 xen/arch/x86/domain-builder/core.c        |  140 +++
 xen/arch/x86/domain-builder/domain.c      |  480 ++++++++++
 xen/arch/x86/hvm/Makefile                 |    1 +
 xen/arch/x86/hvm/dom0_build.c             |  600 +-----------
 xen/arch/x86/hvm/dom_build.c              | 1047 +++++++++++++++++++++
 xen/arch/x86/include/asm/boot-domain.h    |   24 +-
 xen/arch/x86/include/asm/bootinfo.h       |   28 +-
 xen/arch/x86/include/asm/bzimage.h        |    6 +-
 xen/arch/x86/include/asm/dom0_build.h     |   19 +-
 xen/arch/x86/include/asm/domain-builder.h |   33 +
 xen/arch/x86/include/asm/setup.h          |    4 +-
 xen/arch/x86/pv/dom0_build.c              |   21 +-
 xen/arch/x86/setup.c                      |  214 +----
 xen/common/domain-builder/Kconfig         |   12 +
 xen/common/domain-builder/fdt.c           |   40 +-
 xen/common/gzip/gunzip.c                  |   12 +
 xen/common/sched/core.c                   |   12 -
 xen/include/xen/domain-builder.h          |   14 +
 xen/include/xen/gunzip.h                  |   12 +
 xen/include/xen/sched.h                   |    1 -
 31 files changed, 2526 insertions(+), 953 deletions(-)
 create mode 100644 tools/helpers/late-init-domains.c
 create mode 100644 tools/helpers/late-init-domains.h
 create mode 100644 tools/helpers/xs-helpers.c
 create mode 100644 tools/helpers/xs-helpers.h
 create mode 100644 xen/arch/x86/domain-builder/Makefile
 create mode 100644 xen/arch/x86/domain-builder/core.c
 create mode 100644 xen/arch/x86/domain-builder/domain.c
 create mode 100644 xen/arch/x86/hvm/dom_build.c
 create mode 100644 xen/arch/x86/include/asm/domain-builder.h

-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:18:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:18:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985310.1371217 (Exim 4.92)
	(envelope-from )
	id 1uFYTT-0001bS-7a; Thu, 15 May 2025 13:18:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985310.1371217; Thu, 15 May 2025 13:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFYTT-0001bF-4H; Thu, 15 May 2025 13:18:11 +0000
Received: by outflank-mailman (input) for mailman id 985310;
 Thu, 15 May 2025 13:18:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYTR-0001J6-Ib
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:18:09 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0a53f416-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:18:08 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315072278892.8921462394743;
 Thu, 15 May 2025 06:17:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0a53f416-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315073; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=hgZ7ZOrNk4bGYFFTOrgv5Rn+VkpogqoYv56NnOp6KxXKhwxIBQw2HNHhOUdz1X1g9vKDTDfxNzg+oOCehVU2GklEln66YNtonMX9B2Kd46CxbgXNSIOc7+Yx0foVCDmzZypFQ0CBigtr6PL6UZRmM5IcOHnQYIXTrozT7H+S9/k=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315073; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=6MJtagRP8j/7OOUbmkIpnGDxrpbtsZXN/la+TvFmy3A=; 
	b=hhwyvUiYERcheefM1uZxGSM+TXZHbgZzD/nH/rhM/DKMyT/tgge+AsAL3r98eEK8KdxWu1r3DTxL15XCtDfA//bynzTAqTC5c1iy+Hj3o8wMEyOEXCyG0rBIsWfTGISerjq4bbfmKZp1vU1a0srAb+pl3Mc7wr66JnZ/kgLXNig=
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=1747315073;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=6MJtagRP8j/7OOUbmkIpnGDxrpbtsZXN/la+TvFmy3A=;
	b=B4QHmkofDqWuc3u2dHhiEnRGmdvxOpNgHfoz1kiFVY4tYnSZWkiBzyK4SuBWfvRv
	CoqVM7VZNJcSkozWp+OAvbfWEwW9ABeZ7M+XesFoD7HOgDvghu56thPPB+33ZVHcAwH
	Mb283HZPisIHG+CEOyz6SG7Bj45dJlYmGW9zKogc=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [RFCv2 01/38] maintainers: add new section for hyperlaunch
Date: Thu, 15 May 2025 09:17:07 -0400
Message-Id: <20250515131744.3843-2-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Add new section to MAINTAINERS for hyperlaunch, including the files
specifically added to this point under the hyperlaunch work.

Signed-off-by: Daniel P. Smith 
---
 MAINTAINERS | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c11b82eca98f..d9a85a0b818c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -343,6 +343,17 @@ F:	tools/misc/xenhypfs.c
 F:	xen/common/hypfs.c
 F:	xen/include/xen/hypfs.h
 
+HYPERLAUNCH
+M:	Daniel P. Smith 
+M:	Christopher Clark 
+S:	Supported
+F:	xen/common/domain-builder
+F:	xen/include/xen/domain-builder.h
+F:	xen/x86/domain-builder/
+F:	xen/x86/include/asm/bootinfo.h
+F:	xen/x86/include/asm/boot-domain.h
+F:	xen/x86/include/asm/domain-builder.h
+
 IMX8QM/QXP SUPPORT
 R:	John Ernberg 
 F:	xen/arch/arm/platforms/imx8qm.c
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:18:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:18:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985317.1371226 (Exim 4.92)
	(envelope-from )
	id 1uFYTl-00029I-F2; Thu, 15 May 2025 13:18:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985317.1371226; Thu, 15 May 2025 13:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFYTl-00029B-C0; Thu, 15 May 2025 13:18:29 +0000
Received: by outflank-mailman (input) for mailman id 985317;
 Thu, 15 May 2025 13:18:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYTj-0001J6-RS
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:18:27 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 15408a81-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:18:26 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315074222738.0540513286182;
 Thu, 15 May 2025 06: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" 
X-Inumbo-ID: 15408a81-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315075; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=L41bRSVDjkTH520YjWtEtAS+i8aZVraqdrGabqLvWiHr/Vtnylr5G0YZ6UnTs+5PWzcJl60jLOgkRE8UpTrK8S1kXMrLt2opVPP/p0hOZ/qng62jojDH02f0AdXWynBehr8hfHc/AfmfbUZj/vfn4eUW4s0w1aNX1JXElFeYFHU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315075; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=kTwQ0VDMzd1npZEkVq0RJCKCjq57ZhEZ7/qXtfJRi5k=; 
	b=KP5U69NMn4dyQAJPDUn+6duOI8pyO2bdI+ak0rgAffitfSBDUBC+uRbe21vzt3HBBgfPd5xQ2regKi0qkY0rXc10CZ1ZRs+UNUMqYa8rKzBkVDngupMzhqnzaI4w4egNyI9d2+WO8FXoSg6qT0HBlyJn09C+e3dhe3i5CIliMi0=
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=1747315075;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=kTwQ0VDMzd1npZEkVq0RJCKCjq57ZhEZ7/qXtfJRi5k=;
	b=JeGkgy6SrJYIsRID1FWmfO6hbdLqNgV7++WojRzASUdF1roeiFUB2bPczyb9ERx3
	+uqZRVhO/ZDNVI48D9WYiD/bTizavWu60QC3orLKh27GRDjX6X1Bzl9mF+FQB8qgxwm
	V1WtI4WGyAq0H+fhUgppaomzcpeeZY+FHy8xoWRM=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Christopher Clark 
Subject: [RFCv2 03/38] x86/hyperlaunch: convert max vcpu determination to domain builder
Date: Thu, 15 May 2025 09:17:09 -0400
Message-Id: <20250515131744.3843-4-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The domain configuration may request more vcpus than are present in the system.
For dom0, the function dom0_max_vcpus() was used to clamp down to physically
available vcpus. Here we are introducing a generalized version,
dom_max_vcpus(), that takes a boot domain and sets the max vcpus based on the
lesser of the requested max and the available vcpus.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/Makefile                |  1 +
 xen/arch/x86/domain-builder/Makefile |  1 +
 xen/arch/x86/domain-builder/domain.c | 40 ++++++++++++++++++++++++++++
 xen/arch/x86/setup.c                 |  4 +--
 xen/include/xen/domain-builder.h     |  3 +++
 5 files changed, 47 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/x86/domain-builder/Makefile
 create mode 100644 xen/arch/x86/domain-builder/domain.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index c2f1dcf301d6..80269c5e6b45 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -31,6 +31,7 @@ obj-y += desc.o
 obj-bin-y += dmi_scan.init.o
 obj-y += domain.o
 obj-bin-y += dom0_build.init.o
+obj-y += domain-builder/
 obj-y += domain_page.o
 obj-y += e820.o
 obj-y += emul-i8254.o
diff --git a/xen/arch/x86/domain-builder/Makefile b/xen/arch/x86/domain-builder/Makefile
new file mode 100644
index 000000000000..0c2e7085e21b
--- /dev/null
+++ b/xen/arch/x86/domain-builder/Makefile
@@ -0,0 +1 @@
+obj-y += domain.init.o
diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
new file mode 100644
index 000000000000..d8eba73dac28
--- /dev/null
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2025, Apertus Solutions, LLC
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+unsigned int __init dom_max_vcpus(struct boot_domain *bd)
+{
+    unsigned int limit = bd->mode & BUILD_MODE_PARAVIRT ?
+                                    MAX_VIRT_CPUS : HVM_MAX_VCPUS;
+
+    if ( bd->capabilities & DOMAIN_CAPS_CONTROL )
+        limit = dom0_max_vcpus();
+    else
+        limit = min(limit,
+                    (uint32_t)cpumask_weight(cpupool_valid_cpus(cpupool0)));
+
+    if ( bd->max_vcpus == 0 || bd->max_vcpus > limit )
+        bd->max_vcpus = limit;
+
+    return bd->max_vcpus;
+}
+
+/*
+ * 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/x86/setup.c b/xen/arch/x86/setup.c
index afc133b4d562..d3bde6c43e8d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1020,18 +1020,18 @@ static struct domain *__init create_dom0(struct boot_info *bi)
 {
     char *cmdline = NULL;
     size_t cmdline_size;
+    struct boot_domain *bd = &bi->domains[0];
     struct xen_domctl_createdomain dom0_cfg = {
         .flags = IS_ENABLED(CONFIG_TBOOT) ? XEN_DOMCTL_CDF_s3_integrity : 0,
         .max_evtchn_port = -1,
         .max_grant_frames = -1,
         .max_maptrack_frames = -1,
         .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
-        .max_vcpus = dom0_max_vcpus(),
+        .max_vcpus = dom_max_vcpus(bd),
         .arch = {
             .misc_flags = opt_dom0_msr_relaxed ? XEN_X86_MSR_RELAXED : 0,
         },
     };
-    struct boot_domain *bd = &bi->domains[0];
     struct domain *d;
 
     if ( opt_dom0_pvh ||
diff --git a/xen/include/xen/domain-builder.h b/xen/include/xen/domain-builder.h
index 350e2eb2af8c..82c929cc48a1 100644
--- a/xen/include/xen/domain-builder.h
+++ b/xen/include/xen/domain-builder.h
@@ -5,6 +5,7 @@
 #include 
 
 struct boot_info;
+struct boot_domain;
 
 /* Return status of builder_init(). Shows which boot mechanism was detected */
 enum fdt_kind
@@ -34,4 +35,6 @@ size_t builder_get_cmdline_size(const struct boot_info *bi, int offset);
 int builder_get_cmdline(const struct boot_info *bi, int offset,
                         char *cmdline, size_t size);
 
+unsigned int dom_max_vcpus(struct boot_domain *bd);
+
 #endif /* __XEN_DOMAIN_BUILDER_H__ */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:18:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:18:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985322.1371238 (Exim 4.92)
	(envelope-from )
	id 1uFYTv-0002VV-PS; Thu, 15 May 2025 13:18:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985322.1371238; Thu, 15 May 2025 13: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 1uFYTv-0002VM-Ji; Thu, 15 May 2025 13:18:39 +0000
Received: by outflank-mailman (input) for mailman id 985322;
 Thu, 15 May 2025 13:18:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYTt-0001J6-Sv
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:18:37 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1b438928-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:18:37 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315073180787.6888291264746;
 Thu, 15 May 2025 06:17: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" 
X-Inumbo-ID: 1b438928-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315075; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=AWzYI7A9X+nkqZGc27q9xk8SmHzOEcLUeMSHEjDhirwuflVQYAjVWRqHI01jDo3ivJJp43SA6MdKBlqt0+pRE2JUDc6Yhf21QTahc6W0k3xLh3ZK6FQZVaiJ3TvxFxg7EaxGpCAhfsAT62qHIIP+6i2gi345dYWAeAapkv3Lw4I=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315075; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=qJ7uYx+Z7nGp4Os0P7DvdOGEpmcyi7yC0rtUJHH0a2w=; 
	b=Y0coMV4kcMOO6Bv041Kh3ve5uB+I0x0cxWz0P3ZiTq+G+yjZd9AqVAhKNdc+8xxmLi/FWUjRf0o0c/c5mH2YyLwV27wMJV3MzuI9101gZEcZ5/RN6Vc3gPqWBJw82rwty3DA7/ashTBMWlAS8tIYPx1LlH7uVKXF/XF/oowQEk4=
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=1747315075;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=qJ7uYx+Z7nGp4Os0P7DvdOGEpmcyi7yC0rtUJHH0a2w=;
	b=f09z7cTM547DK0mM1HXtQd8HsqEhh+iIsqOdWTys7MUVhNes6Ak3nFGTUhNvyALS
	FpaFQpozV1dxEfI+IxbYhya6zTU2uDu1Uc7vWGv9i2ONEVuLo62cu8mJoyn46YAoJLy
	pk8W6cos5d/ECj6TVPgrjTRbLRvDQCxjF4L57EOU=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Christopher Clark 
Subject: [RFCv2 02/38] x86/hyperlaunch: correct the naming of domain ramdisk field
Date: Thu, 15 May 2025 09:17:08 -0400
Message-Id: <20250515131744.3843-3-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The ramdisk field was incorrectly renamed to module without providing a sound
justification. Doing so creates an unnecessary indirection that can cause more
confusion than utility. The only way the field is populated is via a match of a
boot module of type BOOTMOD_RAMDISK. All usages of the field are cast into a
variables named initrd. The attempt to generalize the field name under the
guise that it could be multiplexed for other module types did so without a
valid usage. The result is there is no consideration of how that multiplexing
would even work or be deconflict with the simultaneous presence of a ramdisk.

Moving the field name back to ramdisk to make the current code flow logical. At
a later time should there be a use case that arises where additional modules
need to be passed to a domain, a more appropriate framework will be crafted
that will like be more complicated than just renaming the field to something
other than ramdisk.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/hvm/dom0_build.c          | 2 +-
 xen/arch/x86/include/asm/boot-domain.h | 2 +-
 xen/arch/x86/pv/dom0_build.c           | 2 +-
 xen/arch/x86/setup.c                   | 2 +-
 xen/common/domain-builder/fdt.c        | 8 ++++----
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index a038e58c118b..0664f0543fd6 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -648,7 +648,7 @@ static int __init pvh_load_kernel(
 {
     struct domain *d = bd->d;
     struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->module;
+    struct boot_module *initrd = bd->ramdisk;
     void *image_base = bootstrap_map_bm(image);
     void *image_start = image_base + image->headroom;
     unsigned long image_len = image->size;
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index cb5351241a62..740bfb74121c 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -28,7 +28,7 @@ struct boot_domain {
     unsigned int max_vcpus;
 
     struct boot_module *kernel;
-    struct boot_module *module;
+    struct boot_module *ramdisk;
     const char *cmdline;
 
     struct domain *d;
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e1b78d47c218..3b2baf057b75 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -375,7 +375,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
     struct vcpu *v = d->vcpu[0];
 
     struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->module;
+    struct boot_module *initrd = bd->ramdisk;
     void *image_base;
     unsigned long image_len;
     void *image_start;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 6a1e874b2ecf..afc133b4d562 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -2187,7 +2187,7 @@ void asmlinkage __init noreturn __start_xen(void)
     if ( !bi->hyperlaunch_enabled && initrdidx < MAX_NR_BOOTMODS )
     {
         bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
-        bi->domains[0].module = &bi->mods[initrdidx];
+        bi->domains[0].ramdisk = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
                    "Multiple initrd candidates, picking module #%u\n",
diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index 232621ae46f9..1b3492571b15 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -374,10 +374,10 @@ static int __init fdt_process_domain_node(
         {
             int idx;
 
-            if ( bd->module )
+            if ( bd->ramdisk )
             {
                 printk(XENLOG_WARNING
-                       "Duplicate module for domain %s\n", name);
+                       "Duplicate multiboot,ramdisk for domain %s\n", name);
                 continue;
             }
 
@@ -390,9 +390,9 @@ static int __init fdt_process_domain_node(
                 return idx;
             }
 
-            printk(XENLOG_INFO "  module: multiboot-index=%d\n", idx);
+            printk(XENLOG_INFO "  ramdisk: multiboot-index=%d\n", idx);
             bi->mods[idx].type = BOOTMOD_RAMDISK;
-            bd->module = &bi->mods[idx];
+            bd->ramdisk = &bi->mods[idx];
         }
     }
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:18:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:18:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985327.1371247 (Exim 4.92)
	(envelope-from )
	id 1uFYU4-0002sz-2J; Thu, 15 May 2025 13:18:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985327.1371247; Thu, 15 May 2025 13: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 1uFYU3-0002sB-VK; Thu, 15 May 2025 13:18:47 +0000
Received: by outflank-mailman (input) for mailman id 985327;
 Thu, 15 May 2025 13:18:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYU3-0001J6-6x
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:18:47 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 20d9c2ed-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:18:46 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315076250162.1941233290696;
 Thu, 15 May 2025 06:17: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" 
X-Inumbo-ID: 20d9c2ed-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315077; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=VN/R52rVkWfwpPWfVt6XrX9JArsO+VWgXu6R734zNdSNBU0QSw6eBnDnEAzQNTh9wfq3xeVnJq4Bv+zll41AAMvlicUcajSUtOWHgRSOnR1eStBT6IJX9A6EChO3IPK6SjK2uVhWOMpJjLSL1i6/GErchJ9D0jtrdZmOPJKHNgE=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315077; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=iHVvaVi4MhX0h9Mwr6nanEd/O/4lHAF3yTF25jOYNb8=; 
	b=H6r7318QdVqAqxRxFqjkpFAIdUWuax8OzHSzrS57PHJzBKNMlmd3gPX+4fg2k6SW/+bYVWU3ZcHUDCnn3v1ozsLwe/Tjl03orptP1KU+y15cjKBZMF3F5x4tlZVFBNXhjoQUS/Fj39u/LW6vFM2yIeWjSMRQPOF4pbWi/let9r4=
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=1747315077;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=iHVvaVi4MhX0h9Mwr6nanEd/O/4lHAF3yTF25jOYNb8=;
	b=P9TiwOaJdN59afatcwL+eam3nKCfTbKgdKP0Q86vefHCLzl07BHD+uFbLcrAkT7D
	xWt/rLqhJ0v/O9jAkgd9kzwg2dana28T/9SvtCdeNA+fJ/5f+Da/0qnQC34umTF8PKZ
	Jll+QAdPK0qRfe9GYXWFe9i90LY2phMIAsrRuRGc=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 05/38] x86/hyperlaunch: move dom0 cpuid policy behind capability check
Date: Thu, 15 May 2025 09:17:11 -0400
Message-Id: <20250515131744.3843-6-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

To incrementally convert create_dom0() into being a generalized domain
construction function, move the dom0 specific cpuid policy behind the control
domain capability.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/setup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 409630089d29..298e27848dda 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1059,7 +1059,8 @@ static struct domain *__init create_dom0(struct boot_info *bi)
 
     bd->d = d;
 
-    init_dom0_cpuid_policy(d);
+    if ( has_dom0_caps(bd) )
+        init_dom0_cpuid_policy(bd->d);
 
     if ( domain_vcpu0_create(bd) == NULL )
         panic("Error creating %pdv0\n", d);
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985338.1371267 (Exim 4.92)
	(envelope-from )
	id 1uFYVq-00057o-KI; Thu, 15 May 2025 13:20:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985338.1371267; Thu, 15 May 2025 13:20:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFYVq-00057h-Fs; Thu, 15 May 2025 13:20:38 +0000
Received: by outflank-mailman (input) for mailman id 985338;
 Thu, 15 May 2025 13:20:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYV7-00017p-4P
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:19:53 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 47941257-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:19:51 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315098202984.3426957289753;
 Thu, 15 May 2025 06:18: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" 
X-Inumbo-ID: 47941257-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315100; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=DDaCQpNU5vXVFWmAPsXgXr4Op2rq11veWQkILgSuI+APThUUvQL+8dtU5ZfHcJEWpzqedT63S0sq1aSH5M54gmSdIVZOG5SO8md9UyANTuu1VuvOjJTqufL9Ifbv22CnEjhLFZ7EGfH7gID56LmkaD2SXPGHNSos0w9IToArXo8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315100; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=NCBJ/pAlIVIbNcyeaOcg2oqbWODaJtv/R9aCM8gYWrY=; 
	b=XG1JkUj2yccNEHiRFSBPfG+OXHhFWUb2FzQdVWtPQVFEUs4QTqNBMkQLhTByNmTL3dd2Va+ZnSySsj6s8F7pp8MBaTpXqSfowUEi3NrsVZVdwIl7MA1CDhDJwVA8TbtdyM7K4ZyQvhiaCmPVpAEZqIKm4abenYqxKt/M+mg8BUg=
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=1747315099;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=NCBJ/pAlIVIbNcyeaOcg2oqbWODaJtv/R9aCM8gYWrY=;
	b=kO7n4vFyt7X419lIYOKxbXNAYpEgZAQwkUnevJNn102FDSr4S65SWafbNbMSZpOf
	O5eLXzuDH5+XCxUlnBX8D75OBYSdkTSRYeyLmfk9UxKCcoHQzfjZ/PKu0o5MGDYflWs
	LbPguoDQFYRpYee3TafUr+0M7lUX6wQpQJL51OJI=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 12/38] x86/hyperlaunch: move page computation to domain builder
Date: Thu, 15 May 2025 09:17:18 -0400
Message-Id: <20250515131744.3843-13-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The function dom_compute_nr_pages() is being moved to the domain builder. For
this to happen, the variable dom0_nodes, and the functions
calculate_dom0_pages() and dom0_pv_restrict_pages() must be exported.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/dom0_build.c                 | 75 +----------------------
 xen/arch/x86/domain-builder/domain.c      | 71 +++++++++++++++++++++
 xen/arch/x86/include/asm/dom0_build.h     |  4 +-
 xen/arch/x86/include/asm/domain-builder.h |  4 ++
 4 files changed, 81 insertions(+), 73 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 2a22cd4e125e..75969887b933 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -209,7 +209,7 @@ static int __init cf_check parse_dom0_nodes(const char *s)
 custom_param("dom0_nodes", parse_dom0_nodes);
 
 cpumask_t __initdata dom0_cpus;
-static nodemask_t __initdata dom0_nodes;
+nodemask_t __initdata dom0_nodes;
 
 unsigned int __init dom0_max_vcpus(void)
 {
@@ -315,8 +315,7 @@ static unsigned long __init default_nr_pages(unsigned long avail)
                             : min(avail / 16, 128UL << (20 - PAGE_SHIFT)));
 }
 
-static void __init calculate_dom0_pages(
-    struct boot_domain *bd, unsigned long avail)
+void __init calculate_dom0_pages(struct boot_domain *bd, unsigned long avail)
 {
     unsigned long nr_pages = bd->mem_pages ?: default_nr_pages(avail);
 
@@ -338,7 +337,7 @@ static void __init calculate_dom0_pages(
     bd->mem_pages = nr_pages;
 }
 
-static void __init dom0_pv_restrict_pages(
+void __init dom0_pv_restrict_pages(
     struct boot_domain *bd, struct elf_dom_parms *parms)
 {
     if ( (parms->p2m_base == UNSET_ADDR) && !memsize_gt_zero(&dom0_size) &&
@@ -377,74 +376,6 @@ static void __init dom0_pv_restrict_pages(
     }
 }
 
-unsigned long __init dom_compute_nr_pages(
-    struct boot_domain *bd, struct elf_dom_parms *parms)
-{
-    nodeid_t node;
-    nodemask_t nodes = { 0 };
-    struct domain *d = bd->d;
-    unsigned long avail = 0, iommu_pages = 0;
-
-    nodes_or(nodes, nodes, node_online_map);
-
-    /* If building dom0 or hwdom, apply command line restriction. */
-    if ( has_dom0_caps(bd) )
-        nodes_and(nodes, nodes, dom0_nodes);
-
-    ASSERT(nodes_weight(nodes) != 0);
-
-    for_each_node_mask ( node, nodes )
-        avail += avail_domheap_pages_region(node, 0, 0) +
-                 initial_images_nrpages(node);
-
-    /* Reserve memory for further dom0 vcpu-struct allocations... */
-    avail -= (d->max_vcpus - 1UL)
-             << get_order_from_bytes(sizeof(struct vcpu));
-    /* ...and compat_l4's, if needed. */
-    if ( is_pv_32bit_domain(d) )
-        avail -= d->max_vcpus - 1;
-
-    /* Reserve memory for iommu_dom0_init() (rough estimate). */
-    if ( is_hardware_domain(d) && is_iommu_enabled(d)
-         && !iommu_hwdom_passthrough )
-    {
-        unsigned int s;
-
-        for ( s = 9; s < BITS_PER_LONG; s += 9 )
-            iommu_pages += max_pdx >> s;
-
-        avail -= iommu_pages;
-    }
-
-    if ( paging_mode_enabled(d) || opt_dom0_shadow || opt_pv_l1tf_hwdom )
-    {
-        unsigned long cpu_pages;
-
-        /*
-         * Clamp according to min/max limits and available memory
-         * (preliminary).
-         */
-        calculate_dom0_pages(bd, avail);
-
-        cpu_pages = dom_paging_pages(bd, bd->mem_pages);
-
-        if ( !iommu_use_hap_pt(d) )
-            avail -= cpu_pages;
-        else if ( cpu_pages > iommu_pages )
-            avail -= cpu_pages - iommu_pages;
-    }
-
-    /* Clamp according to min/max limits and available memory (final). */
-    calculate_dom0_pages(bd, avail);
-
-    if ( is_pv_domain(d) )
-        dom0_pv_restrict_pages(bd, parms);
-
-    d->max_pages = min_t(unsigned long, bd->max_pages, UINT_MAX);
-
-    return bd->mem_pages;
-}
-
 static void __init process_dom0_ioports_disable(struct domain *dom0)
 {
     unsigned long io_from, io_to;
diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index a2e5807b60a5..258f777cd9ee 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -6,6 +6,9 @@
 #include 
 #include 
 #include 
+#include  /* get types.h for libefl.h */
+#include 
+#include 
 #include 
 
 #include 
@@ -60,6 +63,74 @@ unsigned long __init dom_paging_pages(
     return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT);
 }
 
+unsigned long __init dom_compute_nr_pages(
+    struct boot_domain *bd, struct elf_dom_parms *parms)
+{
+    nodeid_t node;
+    nodemask_t nodes = { 0 };
+    struct domain *d = bd->d;
+    unsigned long avail = 0, iommu_pages = 0;
+
+    nodes_or(nodes, nodes, node_online_map);
+
+    /* If building dom0 or hwdom, apply command line restriction. */
+    if ( has_dom0_caps(bd) )
+        nodes_and(nodes, nodes, dom0_nodes);
+
+    ASSERT(nodes_weight(nodes) != 0);
+
+    for_each_node_mask ( node, nodes )
+        avail += avail_domheap_pages_region(node, 0, 0) +
+                 initial_images_nrpages(node);
+
+    /* Reserve memory for further dom0 vcpu-struct allocations... */
+    avail -= (d->max_vcpus - 1UL)
+             << get_order_from_bytes(sizeof(struct vcpu));
+    /* ...and compat_l4's, if needed. */
+    if ( is_pv_32bit_domain(d) )
+        avail -= d->max_vcpus - 1;
+
+    /* Reserve memory for iommu_dom0_init() (rough estimate). */
+    if ( is_hardware_domain(d) && is_iommu_enabled(d)
+         && !iommu_hwdom_passthrough )
+    {
+        unsigned int s;
+
+        for ( s = 9; s < BITS_PER_LONG; s += 9 )
+            iommu_pages += max_pdx >> s;
+
+        avail -= iommu_pages;
+    }
+
+    if ( paging_mode_enabled(d) || opt_dom0_shadow || opt_pv_l1tf_hwdom )
+    {
+        unsigned long cpu_pages;
+
+        /*
+         * Clamp according to min/max limits and available memory
+         * (preliminary).
+         */
+        calculate_dom0_pages(bd, avail);
+
+        cpu_pages = dom_paging_pages(bd, bd->mem_pages);
+
+        if ( !iommu_use_hap_pt(d) )
+            avail -= cpu_pages;
+        else if ( cpu_pages > iommu_pages )
+            avail -= cpu_pages - iommu_pages;
+    }
+
+    /* Clamp according to min/max limits and available memory (final). */
+    calculate_dom0_pages(bd, avail);
+
+    if ( is_pv_domain(d) )
+        dom0_pv_restrict_pages(bd, parms);
+
+    d->max_pages = min_t(unsigned long, bd->max_pages, UINT_MAX);
+
+    return bd->mem_pages;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index 7275bcf9ba6b..43a402af15b7 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -7,13 +7,15 @@
 #include 
 
 extern unsigned int dom0_memflags;
+extern nodemask_t dom0_nodes;
 
 void dom0_set_affinity(struct domain *dom0);
 
 int dom0_setup_permissions(struct domain *d);
 
 struct boot_domain;
-unsigned long dom_compute_nr_pages(
+void calculate_dom0_pages(struct boot_domain *bd, unsigned long avail);
+void dom0_pv_restrict_pages(
     struct boot_domain *bd, struct elf_dom_parms *parms);
 
 int dom0_construct_pv(struct boot_domain *bd);
diff --git a/xen/arch/x86/include/asm/domain-builder.h b/xen/arch/x86/include/asm/domain-builder.h
index c5a71fae5ccb..243ca09c045a 100644
--- a/xen/arch/x86/include/asm/domain-builder.h
+++ b/xen/arch/x86/include/asm/domain-builder.h
@@ -2,10 +2,14 @@
 #define __XEN_X86_DOMBUILDER_H__
 
 struct boot_domain;
+struct elf_dom_parms;
 
 unsigned long dom_paging_pages(
     const struct boot_domain *d, unsigned long nr_pages);
 
+unsigned long dom_compute_nr_pages(
+    struct boot_domain *bd, struct elf_dom_parms *parms);
+
 int dom_construct_pvh(struct boot_domain *bd);
 
 #endif
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985333.1371258 (Exim 4.92)
	(envelope-from )
	id 1uFYVp-0004tv-Dy; Thu, 15 May 2025 13:20:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985333.1371258; Thu, 15 May 2025 13:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFYVp-0004sT-9S; Thu, 15 May 2025 13:20:37 +0000
Received: by outflank-mailman (input) for mailman id 985333;
 Thu, 15 May 2025 13:20:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYUR-0001J6-Bp
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:19:11 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2f50c843-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:19:10 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315077086430.3181831510035;
 Thu, 15 May 2025 06:17: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" 
X-Inumbo-ID: 2f50c843-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315080; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=NtT9ACVh181HluxxaVMaxLDS+33yLsG964fBTaurRrQt57veOSD4fbxCn/ji2z+uFBIvm2E3OzUskUjl5zzSjipibQxzgBGbDNamPzK36oFyFfEg7ug75QcQu8ucx3WuuV36o/HQeyd/va2HN8WAvh+0O96zRfc0ELoF8uQRGXA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315080; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=SXbug0DKOX8Y5Ce3k9H738ujkJ9TrrqxK2HK+AOKWG0=; 
	b=Oj9hx0dX01pSU8sBn83Lr95z4ck9C/ivXQ80c8rROZJqv23PUDouIXsAaMTEEdD4OSnjSZ2BEPY7k+oITozDE/HOHssi5PkGwEI6h7A5xuxCgtAnYbaajJdhpJw7eb2d01NT7qXJxC6/bhk23rGb5NJO+GNSIydEdFeHTDR7Q98=
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=1747315080;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=SXbug0DKOX8Y5Ce3k9H738ujkJ9TrrqxK2HK+AOKWG0=;
	b=usvFGD3YlUOfTBKfXZmtpGiQ7Aq31A5sMn6A3Pz/OQHWbqIAR6W271T4LTbwpcx1
	//jDF/JiZk+BXqx6EjsgsEH/DsZLu7LJqHgI0AyTnO42lLs+6t6ncZ2cFIaN3/+QKmu
	kK/Vr1vOrzAznobQNIsKNnkPPc9575BMoSFNHW1Y=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 06/38] x86/hyperlaunch: introduce pvh domain builder
Date: Thu, 15 May 2025 09:17:12 -0400
Message-Id: <20250515131744.3843-7-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Introduce dom_construct_pvh() as a wrapper around dom0_construct_pvh(). This
function will be expanded as dom0 specific construction functions are
generalized.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/dom0_build.c                 |  5 ++--
 xen/arch/x86/hvm/Makefile                 |  1 +
 xen/arch/x86/hvm/dom_build.c              | 31 +++++++++++++++++++++++
 xen/arch/x86/include/asm/domain-builder.h |  8 ++++++
 xen/arch/x86/include/asm/setup.h          |  2 +-
 5 files changed, 44 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/x86/hvm/dom_build.c
 create mode 100644 xen/arch/x86/include/asm/domain-builder.h

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 22d9ff3f1e8c..2cf6535ce190 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -613,7 +614,7 @@ int __init dom0_setup_permissions(struct domain *d)
     return rc;
 }
 
-int __init construct_dom0(const struct boot_domain *bd)
+int __init construct_dom0(struct boot_domain *bd)
 {
     int rc;
     const struct domain *d = bd->d;
@@ -637,7 +638,7 @@ int __init construct_dom0(const struct boot_domain *bd)
         opt_dom0_max_vcpus_max = bd->max_vcpus;
 
     if ( is_hvm_domain(d) )
-        rc = dom0_construct_pvh(bd);
+        rc = dom_construct_pvh(bd);
     else if ( is_pv_domain(d) )
         rc = dom0_construct_pv(bd);
     else
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 6ec2c8f2db56..0830a5b2a56f 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -5,6 +5,7 @@ obj-y += viridian/
 obj-y += asid.o
 obj-y += dm.o
 obj-bin-y += dom0_build.init.o
+obj-bin-y += dom_build.init.o
 obj-y += domain.o
 obj-y += emulate.o
 obj-$(CONFIG_GRANT_TABLE) += grant_table.o
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
new file mode 100644
index 000000000000..8546cfff1fbf
--- /dev/null
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * hvm/dom_build.c
+ *
+ * Dom builder for PVH guest.
+ *
+ * Copyright (C) 2017 Citrix Systems R&D
+ * Copyright (C) 2025 Apertus Solutions, LLC
+ */
+
+#include 
+
+#include 
+#include 
+
+int __init dom_construct_pvh(struct boot_domain *bd)
+{
+    printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", bd->domid);
+
+    return dom0_construct_pvh(bd);
+}
+
+/*
+ * 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/x86/include/asm/domain-builder.h b/xen/arch/x86/include/asm/domain-builder.h
new file mode 100644
index 000000000000..dd429fc9ff8b
--- /dev/null
+++ b/xen/arch/x86/include/asm/domain-builder.h
@@ -0,0 +1,8 @@
+#ifndef __XEN_X86_DOMBUILDER_H__
+#define __XEN_X86_DOMBUILDER_H__
+
+struct boot_domain;
+
+int dom_construct_pvh(struct boot_domain *bd);
+
+#endif
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index ac34c698551e..b517da6144de 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -27,7 +27,7 @@ void subarch_init_memory(void);
 void init_IRQ(void);
 
 struct boot_domain;
-int construct_dom0(const struct boot_domain *bd);
+int construct_dom0(struct boot_domain *bd);
 
 void setup_io_bitmap(struct domain *d);
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985339.1371273 (Exim 4.92)
	(envelope-from )
	id 1uFYVr-0005BU-14; Thu, 15 May 2025 13:20:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985339.1371273; Thu, 15 May 2025 13:20:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFYVq-0005Af-PO; Thu, 15 May 2025 13:20:38 +0000
Received: by outflank-mailman (input) for mailman id 985339;
 Thu, 15 May 2025 13:20:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYVF-00017p-Bu
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:20:01 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c85656f-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:19:59 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315099866282.80562315486736;
 Thu, 15 May 2025 06: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" 
X-Inumbo-ID: 4c85656f-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315101; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=aRh+yUXQmYU+RmfETNdrkEGzca5UOD2tTQn91CdoLUbD8mzZZZfp7pt1s+72++uLolHTzggwg7WirPXBxoz/RiWDt7CNZOWfn0zv9JOrOzC7uvevXl+se5Fl2W6QEy7LM+iVtSj6yiLKGw06hOi10iYUzmwig7gLKY7hXalBbv8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315101; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=ICDJmXNIOhJuI8oO8RsNDdgf3Sl+EcMlmuMMxu1kPpc=; 
	b=XCQ1nlQpw37XY25Nk5IXUvZL+aHSb3GGvwMU9Ofj839UtXzrctl94wykUpwwuS0LRc4Fk0z/Ih/AFR1jBtz2jhmCoxQRs8m1qG363GnLNvw8fU1QUDEL1rFQ1PVdpP5yTwtYSIuSyedvk0UT6PcCFI6VZldnMnSf2ZZAocjFB68=
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=1747315101;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=ICDJmXNIOhJuI8oO8RsNDdgf3Sl+EcMlmuMMxu1kPpc=;
	b=U3dpzQzKKLq6sicjzC9VB2uizzorWqiLbMUFzAVoaMb2WJCp2FC7wvunfWxIB3MT
	ZT+Zu0sAUtDaT4ud22yFvnePDhYHod9cV7p8Nuno0wmMQnk537Lw4aW+lQz8tlIMyGx
	l16NWHjx91bhUUy75NCSyPXyyWE7lFbxnGHpRauk=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 14/38] x86/hyperlaunch: move iommu init to domain builder
Date: Thu, 15 May 2025 09:17:20 -0400
Message-Id: <20250515131744.3843-15-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Move invocation of iommu_hwdom_init() to dom_construct_pvh() and guard it
with a hardware domain check.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/hvm/dom0_build.c | 2 --
 xen/arch/x86/hvm/dom_build.c  | 4 ++++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 378a1f29fb1b..6990c1d3a882 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -1304,8 +1304,6 @@ int __init dom0_construct_pvh(struct boot_domain *bd)
     struct domain *d = bd->d;
     int rc;
 
-    iommu_hwdom_init(d);
-
     rc = pvh_populate_p2m(d);
     if ( rc )
     {
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index eec65e3e805e..450e77d190a2 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -9,6 +9,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -92,6 +93,9 @@ int __init dom_construct_pvh(struct boot_domain *bd)
      */
     pvh_init_p2m(bd);
 
+    if ( is_hardware_domain(bd->d) )
+        iommu_hwdom_init(bd->d);
+
     return dom0_construct_pvh(bd);
 }
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985341.1371278 (Exim 4.92)
	(envelope-from )
	id 1uFYVr-0005F8-9k; Thu, 15 May 2025 13:20:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985341.1371278; Thu, 15 May 2025 13:20: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 1uFYVr-0005Cq-1p; Thu, 15 May 2025 13:20:39 +0000
Received: by outflank-mailman (input) for mailman id 985341;
 Thu, 15 May 2025 13:20:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYUZ-0001J6-Ma
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:19:19 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 341bbdc6-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:19:18 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315079782580.7063259387406;
 Thu, 15 May 2025 06:17:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 341bbdc6-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315081; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=dc5/a+7nd99mo+A/pV6W9eFXyHt+6cZB6ukowXZSI6up/t0WujVEktWTJvgPi+J/cfN2tVPk13yDKqGfa6T9GvW10GLPBDnN9GahnqjQCmGItg3P4hYNVHPl9h2MMiIAXPIVCgjWVIzFy2Bm2cfaoo2wI0asJ5G3qJ5adUX6fn0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315081; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=MXwElwy2ea4EYXzf8tWnzaA3L9VVZ1JQGx/m4TNLx/Q=; 
	b=ErrrdEYPwrwq7hhzHPDpDunIlLI80AASTEF2mSOu7RzbuNnWOtoJRfAHrjyH/Dmox+gxUunIg7627PtK3WOIR7gYVuFEtu1oHP7H+qa15AG926waHoLf9J/doqyxjmgvLF8STfKuummW4dG3X+jpz1ZuM+CnxQXZ24Te7rym9G8=
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=1747315081;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=MXwElwy2ea4EYXzf8tWnzaA3L9VVZ1JQGx/m4TNLx/Q=;
	b=BHkExP0JTjLJ5tFDxrgxJTNa4C3E6sku9rFZPk1jhpt6GabeS0GP/sHXUTN/TGRD
	YtOzcR1Kf223DgVKWoPeKaWuUxkKkOfk5rHYXjhXSabHprHWcKQ1h3pRjdli1sAVO8S
	/xMWaIS+VjX5RLWAGlbgYoiqflJyQuJ4z4gCtdGY=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 09/38] x86/boot: refactor dom0 page calculation
Date: Thu, 15 May 2025 09:17:15 -0400
Message-Id: <20250515131744.3843-10-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Caution is needed when dom0 is being constructed as PV using an older kernel
that does not have the elf note XEN_ELFNOTE_INIT_P2M. The logic for handling
this situation is embedded directly and takes into account whether dom0 memory
parameters were specified using the negative allocation syntax. To prepare for
generalizing domain page allocation, isolate this logic to a separate handling
function.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/dom0_build.c | 76 +++++++++++++++++++++------------------
 1 file changed, 41 insertions(+), 35 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 02a3c2d249c3..a72064fbae80 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -353,12 +353,50 @@ static void __init calculate_dom0_pages(
     bd->mem_pages = nr_pages;
 }
 
+static void __init dom0_pv_restrict_pages(
+    struct boot_domain *bd, struct elf_dom_parms *parms)
+{
+    if ( (parms->p2m_base == UNSET_ADDR) && !memsize_gt_zero(&dom0_size) &&
+         (!memsize_gt_zero(&dom0_min_size) || (bd->mem_pages > bd->min_pages)) )
+    {
+        /*
+         * Legacy Linux kernels (i.e. such without a XEN_ELFNOTE_INIT_P2M
+         * note) require that there is enough virtual space beyond the initial
+         * allocation to set up their initial page tables. This space is
+         * roughly the same size as the p2m table, so make sure the initial
+         * allocation doesn't consume more than about half the space that's
+         * available between params.virt_base and the address space end.
+         */
+        unsigned long vstart, vend, end;
+        unsigned long initrd_len = bd->ramdisk ? bd->ramdisk->size : 0;
+        size_t sizeof_long = is_pv_32bit_domain(bd->d) ? sizeof(int) : sizeof(long);
+
+        vstart = parms->virt_base;
+        vend = round_pgup(parms->virt_kend);
+        if ( !parms->unmapped_initrd )
+            vend += round_pgup(initrd_len);
+        end = vend + bd->mem_pages * sizeof_long;
+
+        if ( end > vstart )
+            end += end - vstart;
+        if ( end <= vstart ||
+             (sizeof_long < sizeof(end) && end > (1UL << (8 * sizeof_long))) )
+        {
+            end = sizeof_long >= sizeof(end) ? 0 : 1UL << (8 * sizeof_long);
+            bd->mem_pages = (end - vend) / (2 * sizeof_long);
+            if ( memsize_gt_zero(&dom0_min_size) &&
+                 bd->mem_pages < bd->min_pages )
+                bd->mem_pages = bd->min_pages;
+            printk("Dom0 memory clipped to %lu pages\n", bd->mem_pages);
+        }
+    }
+}
+
 unsigned long __init dom0_compute_nr_pages(
     struct boot_domain *bd, struct elf_dom_parms *parms)
 {
     nodeid_t node;
     struct domain *d = bd->d;
-    unsigned long initrd_len = bd->ramdisk ? bd->ramdisk->size : 0;
     unsigned long avail = 0, iommu_pages = 0;
 
     for_each_node_mask ( node, dom0_nodes )
@@ -404,40 +442,8 @@ unsigned long __init dom0_compute_nr_pages(
     /* Clamp according to min/max limits and available memory (final). */
     calculate_dom0_pages(bd, avail);
 
-    if ( is_pv_domain(d) &&
-         (parms->p2m_base == UNSET_ADDR) && !memsize_gt_zero(&dom0_size) &&
-         (!memsize_gt_zero(&dom0_min_size) || (bd->mem_pages > bd->min_pages)) )
-    {
-        /*
-         * Legacy Linux kernels (i.e. such without a XEN_ELFNOTE_INIT_P2M
-         * note) require that there is enough virtual space beyond the initial
-         * allocation to set up their initial page tables. This space is
-         * roughly the same size as the p2m table, so make sure the initial
-         * allocation doesn't consume more than about half the space that's
-         * available between params.virt_base and the address space end.
-         */
-        unsigned long vstart, vend, end;
-        size_t sizeof_long = is_pv_32bit_domain(d) ? sizeof(int) : sizeof(long);
-
-        vstart = parms->virt_base;
-        vend = round_pgup(parms->virt_kend);
-        if ( !parms->unmapped_initrd )
-            vend += round_pgup(initrd_len);
-        end = vend + bd->mem_pages * sizeof_long;
-
-        if ( end > vstart )
-            end += end - vstart;
-        if ( end <= vstart ||
-             (sizeof_long < sizeof(end) && end > (1UL << (8 * sizeof_long))) )
-        {
-            end = sizeof_long >= sizeof(end) ? 0 : 1UL << (8 * sizeof_long);
-            bd->mem_pages = (end - vend) / (2 * sizeof_long);
-            if ( memsize_gt_zero(&dom0_min_size) &&
-                 bd->mem_pages < bd->min_pages )
-                bd->mem_pages = bd->min_pages;
-            printk("Dom0 memory clipped to %lu pages\n", bd->mem_pages);
-        }
-    }
+    if ( is_pv_domain(d) )
+        dom0_pv_restrict_pages(bd, parms);
 
     d->max_pages = min_t(unsigned long, bd->max_pages, UINT_MAX);
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985343.1371296 (Exim 4.92)
	(envelope-from )
	id 1uFYVs-0005sw-R1; Thu, 15 May 2025 13:20:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985343.1371296; Thu, 15 May 2025 13: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 1uFYVs-0005rs-Kw; Thu, 15 May 2025 13:20:40 +0000
Received: by outflank-mailman (input) for mailman id 985343;
 Thu, 15 May 2025 13:20:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYUh-0001J6-8N
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:19:27 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3899edc5-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:19:26 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315078938524.299577443265;
 Thu, 15 May 2025 06:17:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3899edc5-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315081; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=H0kdt6vrxbF0nAS1/mnHJ+osvSfOYGegAgB7hDaoqx63epzKd98km1qYbZcwiBKKD/aHQCuYRU+9OWeQMxy1pmWkJ+Oo+iXIB9NmqnJLm+vyAMLwhgbCfgRp7BhnwtgVpypYWqrT0Gd+4e1CTYBtJTFBwnEwiSpo3KjsojSzUeg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315081; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=O7tpnN57teXG8tXpvkkoZVFgo7fwQyPiYThILjAm6aQ=; 
	b=UTR9UFqv3otjnFQztPiS3XVca7bMkxlKFmeAaz6RK91/U7tvbkeq5fqcUyRvZPRp4KE9v/HNgPhRucFsK8YTiqSZl4uJJezvk5Nq6ojTVfgniN8v6qma+9pgejb+Monc71pnpUXcxCyuoRDjrlTYXOgCpzh50Wht6Jrgk1wcIFA=
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=1747315081;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=O7tpnN57teXG8tXpvkkoZVFgo7fwQyPiYThILjAm6aQ=;
	b=hTNsw0SMT1Cb0KRpxyJ15PQkKx5TPyBjgQva+ggAoNoZSm27Jk47mvIEoqCrqybp
	OtALBhxieYv126P44aJ54iaSzPDDvqFW8cnHfJLcALlBMXCe4CxvvXX+cgQHSRWF/to
	a8/Y7e3y4xzQSJgWddxGbfHru2zMl21bVkqu/sEM=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 08/38] x86/boot: convert dom0 page calculation to use boot domain
Date: Thu, 15 May 2025 09:17:14 -0400
Message-Id: <20250515131744.3843-9-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

This commit seeks to rework the dom0_compute_nr_pages() function to consume a
boot domain structure that may contain requested memory pages, min pages, max
pages, and the reference for the initrd. With the passing of the boot domain
struct, the initrd_size parameter is dropped. This takes into account the PVH
case, where the value 0 was passed, which is safe as initrd_size is only used
behind the is_pv_domain() check.

It introduces the calculate_dom0_pages() function that handles the command line
override of the memory pages, min pages, and max pages values. The function
also applies a clamping of memory pages to the min/max pages value.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/dom0_build.c             | 62 ++++++++++++++++-----------
 xen/arch/x86/hvm/dom0_build.c         | 12 +++---
 xen/arch/x86/include/asm/dom0_build.h | 10 ++---
 xen/arch/x86/pv/dom0_build.c          |  6 +--
 4 files changed, 51 insertions(+), 39 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 2cf6535ce190..02a3c2d249c3 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -330,16 +330,37 @@ static unsigned long __init default_nr_pages(unsigned long avail)
                             : min(avail / 16, 128UL << (20 - PAGE_SHIFT)));
 }
 
-unsigned long __init dom0_compute_nr_pages(
-    struct domain *d, struct elf_dom_parms *parms, unsigned long initrd_len)
+static void __init calculate_dom0_pages(
+    struct boot_domain *bd, unsigned long avail)
 {
-    nodeid_t node;
-    unsigned long avail = 0, nr_pages, min_pages, max_pages, iommu_pages = 0;
+    unsigned long nr_pages = bd->mem_pages ?: default_nr_pages(avail);
 
     /* The ordering of operands is to work around a clang5 issue. */
     if ( CONFIG_DOM0_MEM[0] && !dom0_mem_set )
         parse_dom0_mem(CONFIG_DOM0_MEM);
 
+    if ( dom0_mem_set )
+    {
+        nr_pages = get_memsize(&dom0_size, avail) ?: default_nr_pages(avail);
+        bd->min_pages = get_memsize(&dom0_min_size, avail);
+        bd->max_pages = get_memsize(&dom0_max_size, avail);
+    }
+
+    nr_pages = max(nr_pages, bd->min_pages);
+    nr_pages = min(nr_pages, bd->max_pages);
+    nr_pages = min(nr_pages, avail);
+
+    bd->mem_pages = nr_pages;
+}
+
+unsigned long __init dom0_compute_nr_pages(
+    struct boot_domain *bd, struct elf_dom_parms *parms)
+{
+    nodeid_t node;
+    struct domain *d = bd->d;
+    unsigned long initrd_len = bd->ramdisk ? bd->ramdisk->size : 0;
+    unsigned long avail = 0, iommu_pages = 0;
+
     for_each_node_mask ( node, dom0_nodes )
         avail += avail_domheap_pages_region(node, 0, 0) +
                  initial_images_nrpages(node);
@@ -366,17 +387,13 @@ unsigned long __init dom0_compute_nr_pages(
     {
         unsigned long cpu_pages;
 
-        nr_pages = get_memsize(&dom0_size, avail) ?: default_nr_pages(avail);
-
         /*
          * Clamp according to min/max limits and available memory
          * (preliminary).
          */
-        nr_pages = max(nr_pages, get_memsize(&dom0_min_size, avail));
-        nr_pages = min(nr_pages, get_memsize(&dom0_max_size, avail));
-        nr_pages = min(nr_pages, avail);
+        calculate_dom0_pages(bd, avail);
 
-        cpu_pages = dom0_paging_pages(d, nr_pages);
+        cpu_pages = dom0_paging_pages(d, bd->mem_pages);
 
         if ( !iommu_use_hap_pt(d) )
             avail -= cpu_pages;
@@ -384,18 +401,12 @@ unsigned long __init dom0_compute_nr_pages(
             avail -= cpu_pages - iommu_pages;
     }
 
-    nr_pages = get_memsize(&dom0_size, avail) ?: default_nr_pages(avail);
-    min_pages = get_memsize(&dom0_min_size, avail);
-    max_pages = get_memsize(&dom0_max_size, avail);
-
     /* Clamp according to min/max limits and available memory (final). */
-    nr_pages = max(nr_pages, min_pages);
-    nr_pages = min(nr_pages, max_pages);
-    nr_pages = min(nr_pages, avail);
+    calculate_dom0_pages(bd, avail);
 
     if ( is_pv_domain(d) &&
          (parms->p2m_base == UNSET_ADDR) && !memsize_gt_zero(&dom0_size) &&
-         (!memsize_gt_zero(&dom0_min_size) || (nr_pages > min_pages)) )
+         (!memsize_gt_zero(&dom0_min_size) || (bd->mem_pages > bd->min_pages)) )
     {
         /*
          * Legacy Linux kernels (i.e. such without a XEN_ELFNOTE_INIT_P2M
@@ -412,7 +423,7 @@ unsigned long __init dom0_compute_nr_pages(
         vend = round_pgup(parms->virt_kend);
         if ( !parms->unmapped_initrd )
             vend += round_pgup(initrd_len);
-        end = vend + nr_pages * sizeof_long;
+        end = vend + bd->mem_pages * sizeof_long;
 
         if ( end > vstart )
             end += end - vstart;
@@ -420,16 +431,17 @@ unsigned long __init dom0_compute_nr_pages(
              (sizeof_long < sizeof(end) && end > (1UL << (8 * sizeof_long))) )
         {
             end = sizeof_long >= sizeof(end) ? 0 : 1UL << (8 * sizeof_long);
-            nr_pages = (end - vend) / (2 * sizeof_long);
-            if ( memsize_gt_zero(&dom0_min_size) && nr_pages < min_pages )
-                nr_pages = min_pages;
-            printk("Dom0 memory clipped to %lu pages\n", nr_pages);
+            bd->mem_pages = (end - vend) / (2 * sizeof_long);
+            if ( memsize_gt_zero(&dom0_min_size) &&
+                 bd->mem_pages < bd->min_pages )
+                bd->mem_pages = bd->min_pages;
+            printk("Dom0 memory clipped to %lu pages\n", bd->mem_pages);
         }
     }
 
-    d->max_pages = min_t(unsigned long, max_pages, UINT_MAX);
+    d->max_pages = min_t(unsigned long, bd->max_pages, UINT_MAX);
 
-    return nr_pages;
+    return bd->mem_pages;
 }
 
 static void __init process_dom0_ioports_disable(struct domain *dom0)
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 4f2eb0f97aba..1f229d7bded1 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -398,15 +398,15 @@ static __init void pvh_setup_e820(struct domain *d, unsigned long nr_pages)
     ASSERT(cur_pages == nr_pages);
 }
 
-static void __init pvh_init_p2m(struct domain *d)
+static void __init pvh_init_p2m(struct boot_domain *bd)
 {
-    unsigned long nr_pages = dom0_compute_nr_pages(d, NULL, 0);
+    unsigned long nr_pages = dom0_compute_nr_pages(bd, NULL);
     bool preempted;
 
-    pvh_setup_e820(d, nr_pages);
+    pvh_setup_e820(bd->d, nr_pages);
     do {
         preempted = false;
-        paging_set_allocation(d, dom0_paging_pages(d, nr_pages),
+        paging_set_allocation(bd->d, dom0_paging_pages(bd->d, nr_pages),
                               &preempted);
         process_pending_softirqs();
     } while ( preempted );
@@ -1311,7 +1311,7 @@ static int __init pvh_setup_acpi(struct domain *d, paddr_t start_info)
     return 0;
 }
 
-int __init dom0_construct_pvh(const struct boot_domain *bd)
+int __init dom0_construct_pvh(struct boot_domain *bd)
 {
     paddr_t entry, start_info;
     struct domain *d = bd->d;
@@ -1322,7 +1322,7 @@ int __init dom0_construct_pvh(const struct boot_domain *bd)
      * be done before the iommu initializion, since iommu initialization code
      * will likely add mappings required by devices to the p2m (ie: RMRRs).
      */
-    pvh_init_p2m(d);
+    pvh_init_p2m(bd);
 
     iommu_hwdom_init(d);
 
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index 426def4115ce..dcf71c032a17 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -10,14 +10,14 @@ extern unsigned int dom0_memflags;
 
 void dom0_set_affinity(struct domain *dom0);
 
-unsigned long dom0_compute_nr_pages(struct domain *d,
-                                    struct elf_dom_parms *parms,
-                                    unsigned long initrd_len);
 int dom0_setup_permissions(struct domain *d);
 
 struct boot_domain;
-int dom0_construct_pv(const struct boot_domain *bd);
-int dom0_construct_pvh(const struct boot_domain *bd);
+unsigned long dom0_compute_nr_pages(
+    struct boot_domain *bd, struct elf_dom_parms *parms);
+
+int dom0_construct_pv(struct boot_domain *bd);
+int dom0_construct_pvh(struct boot_domain *bd);
 
 unsigned long dom0_paging_pages(const struct domain *d,
                                 unsigned long nr_pages);
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 3b2baf057b75..350a60b1e8fd 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -355,7 +355,7 @@ static struct page_info * __init alloc_chunk(struct domain *d,
     return page;
 }
 
-static int __init dom0_construct(const struct boot_domain *bd)
+static int __init dom0_construct(struct boot_domain *bd)
 {
     unsigned int i;
     int rc, order, machine;
@@ -503,7 +503,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
         }
     }
 
-    nr_pages = dom0_compute_nr_pages(d, &parms, initrd_len);
+    nr_pages = dom0_compute_nr_pages(bd, &parms);
 
 #ifdef CONFIG_PV32
     if ( elf_32bit(&elf) )
@@ -1070,7 +1070,7 @@ out:
     return rc;
 }
 
-int __init dom0_construct_pv(const struct boot_domain *bd)
+int __init dom0_construct_pv(struct boot_domain *bd)
 {
     unsigned long cr4 = read_cr4();
     int rc;
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985348.1371307 (Exim 4.92)
	(envelope-from )
	id 1uFYVv-0006H9-2z; Thu, 15 May 2025 13:20:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985348.1371307; Thu, 15 May 2025 13: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 1uFYVu-0006Gq-WB; Thu, 15 May 2025 13:20:42 +0000
Received: by outflank-mailman (input) for mailman id 985348;
 Thu, 15 May 2025 13:20:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYVW-0001J6-J2
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:20:18 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 56dac482-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:20:17 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315101958426.96570090883506;
 Thu, 15 May 2025 06:18: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" 
X-Inumbo-ID: 56dac482-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315103; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=cSRlrUsmWPREwCa4N7HxQYaC3W2T0L4LVb4/dfh6vswe3ZI6TFU6gNvI9ytWa1hwNXVJIrWG+wo9Rw9Z8wQqjHM5KxqwW2HD8C5DKGiGPuADTiqbBybMoig7Q9D3zSCnCvvIRmU/6T9ZicKUV2m5RUhWe7+VX0LxQBNofluk8Lk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315103; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=QN3ttUmNuXyhgf0DOzYzQqGUZSfR2qHn+gtTdXGDOj4=; 
	b=cGVrXtEzGtwsO/avZUTes4oe38HhvKafjkCnXhE+troKujn8WDlaID3bPogsE4inLTVnIyUbbv7g2cb0+go8vhTCAttKeoyO7v4EoW5LqKcZgmnGavbWbo7nKN3LZZv1b+/pVr9JEcN/umEUF8GtomvlThAN2uHKJiOG+lXlUdk=
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=1747315103;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=QN3ttUmNuXyhgf0DOzYzQqGUZSfR2qHn+gtTdXGDOj4=;
	b=Y5uZ6lk30edG+ZiMmanVYVOH1SusoWp4P7ZNVXQFPxBItQGlHUdj6wgxh9mj2m/o
	RxI68POmnmFRm7AducGVJAM4gey4n0VG5zNP8Ow0wYiQY5OOJU+WKkWZOCxDWBTUFYK
	kq9SprP8dPJJYxBQjnpBH5t9eSraeJlYY6sH+FwM=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 16/38] x86/hyperlaunch: move pvh_setup_cpus to domain builder
Date: Thu, 15 May 2025 09:17:22 -0400
Message-Id: <20250515131744.3843-17-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The function pvh_setup_cpus() is a very general function that is usable by all
HVM domains, not just PVH. As such, renaming to hvm_setup_cpus during move.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/hvm/dom0_build.c             | 45 +---------------------
 xen/arch/x86/hvm/dom_build.c              | 46 +++++++++++++++++++++++
 xen/arch/x86/include/asm/domain-builder.h |  2 +
 3 files changed, 49 insertions(+), 44 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index a900138b0311..7b9a2cccabce 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -808,49 +808,6 @@ static int __init pvh_load_kernel(
     return 0;
 }
 
-static int __init pvh_setup_cpus(struct domain *d, paddr_t entry,
-                                 paddr_t start_info)
-{
-    struct vcpu *v = d->vcpu[0];
-    int rc;
-    /*
-     * This sets the vCPU state according to the state described in
-     * docs/misc/pvh.pandoc.
-     */
-    vcpu_hvm_context_t cpu_ctx = {
-        .mode = VCPU_HVM_MODE_32B,
-        .cpu_regs.x86_32.ebx = start_info,
-        .cpu_regs.x86_32.eip = entry,
-        .cpu_regs.x86_32.cr0 = X86_CR0_PE | X86_CR0_ET,
-        .cpu_regs.x86_32.cs_limit = ~0u,
-        .cpu_regs.x86_32.ds_limit = ~0u,
-        .cpu_regs.x86_32.es_limit = ~0u,
-        .cpu_regs.x86_32.ss_limit = ~0u,
-        .cpu_regs.x86_32.tr_limit = 0x67,
-        .cpu_regs.x86_32.cs_ar = 0xc9b,
-        .cpu_regs.x86_32.ds_ar = 0xc93,
-        .cpu_regs.x86_32.es_ar = 0xc93,
-        .cpu_regs.x86_32.ss_ar = 0xc93,
-        .cpu_regs.x86_32.tr_ar = 0x8b,
-    };
-
-    domain_vcpus_create(d);
-
-    rc = arch_set_info_hvm_guest(v, &cpu_ctx);
-    if ( rc )
-    {
-        printk("Unable to setup Dom0 BSP context: %d\n", rc);
-        return rc;
-    }
-
-    update_domain_wallclock_time(d);
-
-    v->is_initialised = 1;
-    clear_bit(_VPF_down, &v->pause_flags);
-
-    return 0;
-}
-
 static int __init cf_check acpi_count_intr_ovr(
     struct acpi_subtable_header *header, const unsigned long end)
 {
@@ -1319,7 +1276,7 @@ int __init dom0_construct_pvh(struct boot_domain *bd)
         return rc;
     }
 
-    rc = pvh_setup_cpus(d, entry, start_info);
+    rc = hvm_setup_cpus(bd->d, entry, start_info);
     if ( rc )
     {
         printk("Failed to setup Dom0 CPUs: %d\n", rc);
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index 450e77d190a2..c182847147b0 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -9,6 +9,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -16,6 +17,8 @@
 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
@@ -55,6 +58,49 @@ static void __init pvh_init_p2m(struct boot_domain *bd)
     } while ( preempted );
 }
 
+int __init hvm_setup_cpus(
+    struct domain *d, paddr_t entry, paddr_t start_info)
+{
+    struct vcpu *v = d->vcpu[0];
+    int rc;
+    /*
+     * This sets the vCPU state according to the state described in
+     * docs/misc/pvh.pandoc.
+     */
+    vcpu_hvm_context_t cpu_ctx = {
+        .mode = VCPU_HVM_MODE_32B,
+        .cpu_regs.x86_32.ebx = start_info,
+        .cpu_regs.x86_32.eip = entry,
+        .cpu_regs.x86_32.cr0 = X86_CR0_PE | X86_CR0_ET,
+        .cpu_regs.x86_32.cs_limit = ~0u,
+        .cpu_regs.x86_32.ds_limit = ~0u,
+        .cpu_regs.x86_32.es_limit = ~0u,
+        .cpu_regs.x86_32.ss_limit = ~0u,
+        .cpu_regs.x86_32.tr_limit = 0x67,
+        .cpu_regs.x86_32.cs_ar = 0xc9b,
+        .cpu_regs.x86_32.ds_ar = 0xc93,
+        .cpu_regs.x86_32.es_ar = 0xc93,
+        .cpu_regs.x86_32.ss_ar = 0xc93,
+        .cpu_regs.x86_32.tr_ar = 0x8b,
+    };
+
+    domain_vcpus_create(d);
+
+    rc = arch_set_info_hvm_guest(v, &cpu_ctx);
+    if ( rc )
+    {
+        printk("Unable to setup Dom0 BSP context: %d\n", rc);
+        return rc;
+    }
+
+    update_domain_wallclock_time(d);
+
+    v->is_initialised = 1;
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    return 0;
+}
+
 int __init dom_construct_pvh(struct boot_domain *bd)
 {
     int rc;
diff --git a/xen/arch/x86/include/asm/domain-builder.h b/xen/arch/x86/include/asm/domain-builder.h
index 243ca09c045a..a27413edb380 100644
--- a/xen/arch/x86/include/asm/domain-builder.h
+++ b/xen/arch/x86/include/asm/domain-builder.h
@@ -4,6 +4,8 @@
 struct boot_domain;
 struct elf_dom_parms;
 
+int hvm_setup_cpus(struct domain *d, paddr_t entry, paddr_t start_info);
+
 unsigned long dom_paging_pages(
     const struct boot_domain *d, unsigned long nr_pages);
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985349.1371311 (Exim 4.92)
	(envelope-from )
	id 1uFYVv-0006KI-Hn; Thu, 15 May 2025 13:20:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985349.1371311; Thu, 15 May 2025 13: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 1uFYVv-0006J2-9O; Thu, 15 May 2025 13:20:43 +0000
Received: by outflank-mailman (input) for mailman id 985349;
 Thu, 15 May 2025 13:20:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYVN-00017p-NM
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:20:09 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 517e167a-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:20:07 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315099026106.2457133486572;
 Thu, 15 May 2025 06: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" 
X-Inumbo-ID: 517e167a-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315102; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=S2Vv39itenXABDymFTOf14AheY3HTytBFZplCNisvLIHShGMmBofXiqLax7nQptNXe4cFQmL2Ejk42iJvnlxKuSqwh6kpbGlh+1qQrg6Nz8GoBwwQUUx7urzeCqI+XnTDNgKpT/76PISkpDN433+rQR9rY7lYBdXXH3RSQyIjCQ=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315102; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=QHkJY28JGQK8XLqjv1ZElUqF+VLP60wun/RyWvaCxRs=; 
	b=T3tkbTTVhAwJ3Hvq50XB+RCf7+g7bD9h9whNyG3sZXNyc1t3F93mpVzQcL2bkjZnJA/E5JGTP6Ykor53dTw6ZMgudsoP+BCZVtLfQup4vFMesy73Ru/PKTkWtKY/Cc5U/mmiE9YxkrYiPyzMlPQFB4ynNWjMl/CCJL8COJMeNfM=
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=1747315102;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=QHkJY28JGQK8XLqjv1ZElUqF+VLP60wun/RyWvaCxRs=;
	b=JHgdMa78NkgkzzJH93iJWs5aBES1FyPQVGmkfwdO+Yg7uWTqUhCl2T5hpsVONnkz
	WFyValXx4uMVRFhlFEciR0pBV4cgM0+/LwIx/zEKistb72qvGNpP1q62LBM9f9DE97p
	bU+ARzQk5IxAHZYp6Bvec4j//dLykHC0zMEB439M=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 13/38] x86/hyperlaunch: move pvh p2m init to domain builder
Date: Thu, 15 May 2025 09:17:19 -0400
Message-Id: <20250515131744.3843-14-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Generalize pvh_init_p2m() for use on domU and relocate under the domain
builder. To support moving the function, dom0_pvh_setup_e820() was exported.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/hvm/dom0_build.c         | 23 +----------------------
 xen/arch/x86/hvm/dom_build.c          | 25 +++++++++++++++++++++++++
 xen/arch/x86/include/asm/dom0_build.h |  2 ++
 3 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 1e63e19589a1..378a1f29fb1b 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -323,7 +323,7 @@ static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
     return 0;
 }
 
-static __init void pvh_setup_e820(struct domain *d, unsigned long nr_pages)
+void __init dom0_pvh_setup_e820(struct domain *d, unsigned long nr_pages)
 {
     struct e820entry *entry, *entry_guest;
     unsigned int i;
@@ -399,20 +399,6 @@ static __init void pvh_setup_e820(struct domain *d, unsigned long nr_pages)
     ASSERT(cur_pages == nr_pages);
 }
 
-static void __init pvh_init_p2m(struct boot_domain *bd)
-{
-    unsigned long nr_pages = dom_compute_nr_pages(bd, NULL);
-    bool preempted;
-
-    pvh_setup_e820(bd->d, nr_pages);
-    do {
-        preempted = false;
-        paging_set_allocation(bd->d, dom_paging_pages(bd, nr_pages),
-                              &preempted);
-        process_pending_softirqs();
-    } while ( preempted );
-}
-
 static int __init pvh_populate_p2m(struct domain *d)
 {
     struct vcpu *v = d->vcpu[0];
@@ -1318,13 +1304,6 @@ int __init dom0_construct_pvh(struct boot_domain *bd)
     struct domain *d = bd->d;
     int rc;
 
-    /*
-     * Craft dom0 physical memory map and set the paging allocation. This must
-     * be done before the iommu initializion, since iommu initialization code
-     * will likely add mappings required by devices to the p2m (ie: RMRRs).
-     */
-    pvh_init_p2m(bd);
-
     iommu_hwdom_init(d);
 
     rc = pvh_populate_p2m(d);
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index a5f259b6352d..eec65e3e805e 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -10,13 +10,16 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 
 static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
@@ -37,6 +40,20 @@ static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
     }
 }
 
+static void __init pvh_init_p2m(struct boot_domain *bd)
+{
+    unsigned long nr_pages = dom_compute_nr_pages(bd, NULL);
+    bool preempted;
+
+    dom0_pvh_setup_e820(bd->d, nr_pages);
+    do {
+        preempted = false;
+        paging_set_allocation(bd->d, dom_paging_pages(bd, nr_pages),
+                              &preempted);
+        process_pending_softirqs();
+    } while ( preempted );
+}
+
 int __init dom_construct_pvh(struct boot_domain *bd)
 {
     int rc;
@@ -67,6 +84,14 @@ int __init dom_construct_pvh(struct boot_domain *bd)
         }
     }
 
+    /*
+     * Craft domain physical memory map and set the paging allocation. This
+     * must be done before the iommu initializion, since iommu initialization
+     * code will likely add mappings required by devices to the p2m (ie:
+     * RMRRs).
+     */
+    pvh_init_p2m(bd);
+
     return dom0_construct_pvh(bd);
 }
 
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index 43a402af15b7..e5debd5adf9f 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -18,6 +18,8 @@ void calculate_dom0_pages(struct boot_domain *bd, unsigned long avail);
 void dom0_pv_restrict_pages(
     struct boot_domain *bd, struct elf_dom_parms *parms);
 
+void dom0_pvh_setup_e820(struct domain *d, unsigned long nr_pages);
+
 int dom0_construct_pv(struct boot_domain *bd);
 int dom0_construct_pvh(struct boot_domain *bd);
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985353.1371324 (Exim 4.92)
	(envelope-from )
	id 1uFYVw-0006hq-Uh; Thu, 15 May 2025 13:20:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985353.1371324; Thu, 15 May 2025 13: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 1uFYVw-0006hC-Pr; Thu, 15 May 2025 13:20:44 +0000
Received: by outflank-mailman (input) for mailman id 985353;
 Thu, 15 May 2025 13:20:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYUo-0001J6-Ky
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:19:34 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3d113bde-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:19:33 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 174731509630273.38398534579699;
 Thu, 15 May 2025 06:18: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" 
X-Inumbo-ID: 3d113bde-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315098; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=OJxzRQrjwDkpNugjFrZKyKIogbqfB3eoPGxzfBg4VBD9pKOlMZSF5Nl7Xb3+7iqHt8JVgAwWUNgdW9Vkt1t5SGJ77+lrkOFcUSkp6orPfBGF54/75MD23LyrpsvRU22/FAEZQ9Jth3ukVuLfG4MQNf16I2EEgtC1kxbojjXSufk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315098; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=eXY38uR+ClozR264xARbkqWPGdDGpnoE2oYFJfosS80=; 
	b=foyKZW9cbPwtaGzUO6Om5IKo8/xKw8+7GQziRl+fF3Szr6YFhoc8qptUijGPDTFecgZbF8FYPwlA7xUQMdurXAecwLW12g1rOJlgcpA9XVUlJf0BX1jZKAea9GvqcmY/0gSZEIzZSz2+haG2ka9bndWSokktF4OnNdVN31ltg84=
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=1747315098;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=eXY38uR+ClozR264xARbkqWPGdDGpnoE2oYFJfosS80=;
	b=ElGpb5Hk32Rs5F+tPD9XHQhEoDvDRO1iK5IYXK6Fu0StBJgm2nule59YKp/64S0B
	eT/rJAvPeIFS0jvSVe1qve1209D9QC9gKZ1KtexQQ6/X3gDSqPLDraAu8jI8bW++mAR
	cnR8P0cBdUTLLyDSWQX9LN3cRVFI1uqWzE9imyq0=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 10/38] x86/boot: generalize paging pages calculation
Date: Thu, 15 May 2025 09:17:16 -0400
Message-Id: <20250515131744.3843-11-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Modeling after libxl__get_required_paging_memory(), refactor
dom0_paging_pages() to calculate the number of paging pages required for a
domain that is not the control or hardware domain. As the function is being
refactored, rename to dom_paging_pages() and move under the domain builder.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/dom0_build.c                 | 17 +----------------
 xen/arch/x86/domain-builder/domain.c      | 20 ++++++++++++++++++++
 xen/arch/x86/hvm/dom0_build.c             |  3 ++-
 xen/arch/x86/include/asm/dom0_build.h     |  3 ---
 xen/arch/x86/include/asm/domain-builder.h |  3 +++
 xen/arch/x86/pv/dom0_build.c              |  3 ++-
 6 files changed, 28 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index a72064fbae80..0bcdfcb97e6c 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -305,21 +305,6 @@ boolean_param("ro-hpet", ro_hpet);
 
 unsigned int __initdata dom0_memflags = MEMF_no_dma|MEMF_exact_node;
 
-unsigned long __init dom0_paging_pages(const struct domain *d,
-                                       unsigned long nr_pages)
-{
-    /* Keep in sync with libxl__get_required_paging_memory(). */
-    unsigned long memkb = nr_pages * (PAGE_SIZE / 1024);
-
-    memkb = 4 * (256 * d->max_vcpus +
-                 (is_pv_domain(d) ? opt_dom0_shadow || opt_pv_l1tf_hwdom
-                                  : 1 + opt_dom0_shadow) *
-                 (memkb / 1024));
-
-    return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT);
-}
-
-
 /*
  * If allocation isn't specified, reserve 1/16th of available memory for
  * things like DMA buffers. This reservation is clamped to a maximum of 128MB.
@@ -431,7 +416,7 @@ unsigned long __init dom0_compute_nr_pages(
          */
         calculate_dom0_pages(bd, avail);
 
-        cpu_pages = dom0_paging_pages(d, bd->mem_pages);
+        cpu_pages = dom_paging_pages(bd, bd->mem_pages);
 
         if ( !iommu_use_hap_pt(d) )
             avail -= cpu_pages;
diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index 0512dde54746..a2e5807b60a5 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -12,6 +12,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 unsigned int __init dom_max_vcpus(struct boot_domain *bd)
 {
@@ -40,6 +42,24 @@ struct vcpu *__init domain_vcpu0_create(struct boot_domain *bd)
     return vcpu_create(bd->d, 0);
 }
 
+unsigned long __init dom_paging_pages(
+    const struct boot_domain *bd, unsigned long nr_pages)
+{
+    /* Keep in sync with libxl__get_required_paging_memory(). */
+    unsigned long memkb = bd->mem_pages * (PAGE_SIZE / 1024);
+    unsigned long factor = 0;
+
+    if ( has_dom0_caps(bd) )
+        factor = is_pv_domain(bd->d) ? opt_dom0_shadow || opt_pv_l1tf_hwdom
+                                     : 1 + opt_dom0_shadow;
+    else
+        factor = !is_pv_domain(bd->d) + !paging_mode_hap(bd->d);
+
+    memkb = 4 * (256 * bd->d->max_vcpus + (factor * (memkb / 1024)));
+
+    return DIV_ROUND_UP(memkb, 1024) << (20 - PAGE_SHIFT);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 1f229d7bded1..3f0d157f82c8 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -406,7 +407,7 @@ static void __init pvh_init_p2m(struct boot_domain *bd)
     pvh_setup_e820(bd->d, nr_pages);
     do {
         preempted = false;
-        paging_set_allocation(bd->d, dom0_paging_pages(bd->d, nr_pages),
+        paging_set_allocation(bd->d, dom_paging_pages(bd, nr_pages),
                               &preempted);
         process_pending_softirqs();
     } while ( preempted );
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index dcf71c032a17..81717b49b4ae 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -19,9 +19,6 @@ unsigned long dom0_compute_nr_pages(
 int dom0_construct_pv(struct boot_domain *bd);
 int dom0_construct_pvh(struct boot_domain *bd);
 
-unsigned long dom0_paging_pages(const struct domain *d,
-                                unsigned long nr_pages);
-
 void dom0_update_physmap(bool compat, unsigned long pfn,
                          unsigned long mfn, unsigned long vphysmap_s);
 
diff --git a/xen/arch/x86/include/asm/domain-builder.h b/xen/arch/x86/include/asm/domain-builder.h
index dd429fc9ff8b..c5a71fae5ccb 100644
--- a/xen/arch/x86/include/asm/domain-builder.h
+++ b/xen/arch/x86/include/asm/domain-builder.h
@@ -3,6 +3,9 @@
 
 struct boot_domain;
 
+unsigned long dom_paging_pages(
+    const struct boot_domain *d, unsigned long nr_pages);
+
 int dom_construct_pvh(struct boot_domain *bd);
 
 #endif
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 350a60b1e8fd..f8844b858082 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1043,7 +1044,7 @@ static int __init dom0_construct(struct boot_domain *bd)
     {
         bool preempted;
 
-        nr_pt_pages = dom0_paging_pages(d, nr_pages);
+        nr_pt_pages = dom_paging_pages(bd, nr_pages);
 
         do {
             preempted = false;
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985355.1371329 (Exim 4.92)
	(envelope-from )
	id 1uFYVx-0006n4-H9; Thu, 15 May 2025 13:20:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985355.1371329; Thu, 15 May 2025 13:20: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 1uFYVx-0006l0-87; Thu, 15 May 2025 13:20:45 +0000
Received: by outflank-mailman (input) for mailman id 985355;
 Thu, 15 May 2025 13:20:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYUx-00017p-Hy
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:19:43 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41dbf349-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:19:41 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315097354586.0403943507807;
 Thu, 15 May 2025 06:18: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" 
X-Inumbo-ID: 41dbf349-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315099; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=JdYvBziTVWjWTFYBegVcX+IzShCyC+X155hYeHgEpGDOvPdJv8pDv8wb6CMU5Cr3YfxezzpexdvIBWd9G3cq0Kx4adDDiSHw8nztGyM0z9xL6hsAhZNsld/xd4OrTxau7r/finCcMJnJ4wrTtFKjveVqyaJZBteWant18LGuAjA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315099; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=v4ElrvJwVqKGFdrvp3sAV006I3hq5RDG2Yj4oVYTqa0=; 
	b=cy9kZn1CCRfxyZUnMjLNDKQB5EAIEIgqVwgC8iNCGPdAl5v7AmT1jOKN41JMqamNsjqMWKBX+RQE4tENkJQogJUsXMwGmjbtULOmCbU762Wn82c3qCRKim/zrZ7EoZHGwvPoUt8Wp5qsPcgAESs78vLFkKZDp5dbQJ7jsH61jiQ=
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=1747315099;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=v4ElrvJwVqKGFdrvp3sAV006I3hq5RDG2Yj4oVYTqa0=;
	b=dcb7Z2X4NsYdXGn2UEKxjZHbOom8dbg+D3t/kF11YVtrzQvsh7h99DItzdwGsvre
	3DLtwyuAmfmF9DKCnsMosprfnv5rCkHZ1uDl5N6SgoTTfZNLsNF0dOxPCJRHJCfC1HP
	+CLSN/WepdXkiSwQYiJlZoft8wZyYaGxlFwr8Puc=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 11/38] x86/boot: generalize compute number of domain pages
Date: Thu, 15 May 2025 09:17:17 -0400
Message-Id: <20250515131744.3843-12-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The amount of pages for a domain to be allocated is based on the physical nodes
a domain may be scheduled. For dom0, this can be restricted down from available
nodes via the dom0_nodes command line parameter.

Refactor dom0_compute_nr_pages() such that only apply the dom0_nodes
restriction only if the domain has the control domain or hardware domain
capability flag set. In doing so, also rename the function to
dom_compute_nr_pages().

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/dom0_build.c             | 16 +++++++++++++---
 xen/arch/x86/hvm/dom0_build.c         |  2 +-
 xen/arch/x86/include/asm/dom0_build.h |  2 +-
 xen/arch/x86/pv/dom0_build.c          |  2 +-
 4 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0bcdfcb97e6c..2a22cd4e125e 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -377,14 +377,23 @@ static void __init dom0_pv_restrict_pages(
     }
 }
 
-unsigned long __init dom0_compute_nr_pages(
+unsigned long __init dom_compute_nr_pages(
     struct boot_domain *bd, struct elf_dom_parms *parms)
 {
     nodeid_t node;
+    nodemask_t nodes = { 0 };
     struct domain *d = bd->d;
     unsigned long avail = 0, iommu_pages = 0;
 
-    for_each_node_mask ( node, dom0_nodes )
+    nodes_or(nodes, nodes, node_online_map);
+
+    /* If building dom0 or hwdom, apply command line restriction. */
+    if ( has_dom0_caps(bd) )
+        nodes_and(nodes, nodes, dom0_nodes);
+
+    ASSERT(nodes_weight(nodes) != 0);
+
+    for_each_node_mask ( node, nodes )
         avail += avail_domheap_pages_region(node, 0, 0) +
                  initial_images_nrpages(node);
 
@@ -396,7 +405,8 @@ unsigned long __init dom0_compute_nr_pages(
         avail -= d->max_vcpus - 1;
 
     /* Reserve memory for iommu_dom0_init() (rough estimate). */
-    if ( is_iommu_enabled(d) && !iommu_hwdom_passthrough )
+    if ( is_hardware_domain(d) && is_iommu_enabled(d)
+         && !iommu_hwdom_passthrough )
     {
         unsigned int s;
 
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 3f0d157f82c8..1e63e19589a1 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -401,7 +401,7 @@ static __init void pvh_setup_e820(struct domain *d, unsigned long nr_pages)
 
 static void __init pvh_init_p2m(struct boot_domain *bd)
 {
-    unsigned long nr_pages = dom0_compute_nr_pages(bd, NULL);
+    unsigned long nr_pages = dom_compute_nr_pages(bd, NULL);
     bool preempted;
 
     pvh_setup_e820(bd->d, nr_pages);
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index 81717b49b4ae..7275bcf9ba6b 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -13,7 +13,7 @@ void dom0_set_affinity(struct domain *dom0);
 int dom0_setup_permissions(struct domain *d);
 
 struct boot_domain;
-unsigned long dom0_compute_nr_pages(
+unsigned long dom_compute_nr_pages(
     struct boot_domain *bd, struct elf_dom_parms *parms);
 
 int dom0_construct_pv(struct boot_domain *bd);
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index f8844b858082..ad4d1cc3520c 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -504,7 +504,7 @@ static int __init dom0_construct(struct boot_domain *bd)
         }
     }
 
-    nr_pages = dom0_compute_nr_pages(bd, &parms);
+    nr_pages = dom_compute_nr_pages(bd, &parms);
 
 #ifdef CONFIG_PV32
     if ( elf_32bit(&elf) )
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985359.1371337 (Exim 4.92)
	(envelope-from )
	id 1uFYVy-0006xs-OB; Thu, 15 May 2025 13:20:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985359.1371337; Thu, 15 May 2025 13:20:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFYVy-0006wk-3Z; Thu, 15 May 2025 13:20:46 +0000
Received: by outflank-mailman (input) for mailman id 985359;
 Thu, 15 May 2025 13:20:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYUA-0001J6-KY
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:18:54 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 253d6082-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:18:53 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 174731507512669.1061206550686;
 Thu, 15 May 2025 06:17:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 253d6082-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315077; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=JggVgT3lkhZnwh/lXQswfZt0u90GkW/A9ov0/OEVMLTIpP2VPtjUGEA/ALiBzjoSGB4xiOQtGbYBwjnlKS0CGx3btI0gXBVTv3+oc5/Oydohwfv9ydzOaG0EdNx2bpPMCJbBSZ9rpIubHAAm+P80h/SyH55agHdOh9ylalVRv2g=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315077; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=kXLeQEafuzmZpUwx/voiihs2CzxduoImnIkTGOhkmHM=; 
	b=hPdd6gPGBZiqr48sk54TJm8JZpv+PfCrbMaSR7JSuXUkxf1J4Q9MJMuaa49nfpWc4RuCDvSXfuqlKKot4YI9HlUwjHykBZn/3IhYWxHW4CMrsjE+U8qmlEQiknwM/9VXDZAlFiKMcCnqWj4Jyf+C7Xl7idrmW+E4s9Izrmt+T0w=
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=1747315077;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=kXLeQEafuzmZpUwx/voiihs2CzxduoImnIkTGOhkmHM=;
	b=ebNAr9yM6RPtTe6bdKIPMI8oEXh5SECfk71UbQW6abeDbkcm+q4O98SxO/sLueHx
	ubaWXqnC1a91+OxDoSnawgImzqAybJ1JCULizwCzbAC2gYQ5eEL29wYQU1Tz+rYTVPG
	XPIqCG1TyAJNfI5mDV8BpLULUaQ+cRk921Cv/qvE=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Christopher Clark 
Subject: [RFCv2 04/38] x86/hyperlaunch: convert vcpu0 creation to domain builder
Date: Thu, 15 May 2025 09:17:10 -0400
Message-Id: <20250515131744.3843-5-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Convert alloc_dom0_vcpu0() to dom0_set_affinity(), making it only set up the
node affinity based on command line parameters passed. At the same time,
introduce alloc_dom_vcpu0() as the replacement for alloc_dom0_vcpu(). Then have
alloc_dom_vcpu0() call dom0_set_affinity() when the boot domain is the control
domain, otherwise set the affinity to auto.

Signed-off-by: Daniel P. Smith 

---

Changes in v2:
- name vcpu0 allocation function domain_vcpu0_create()
---
 xen/arch/x86/dom0_build.c              |  4 +---
 xen/arch/x86/domain-builder/domain.c   | 11 +++++++++++
 xen/arch/x86/include/asm/boot-domain.h |  9 +++++++++
 xen/arch/x86/include/asm/dom0_build.h  |  2 ++
 xen/arch/x86/setup.c                   |  5 +++--
 xen/include/xen/domain-builder.h       |  1 +
 6 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index f734104c7488..22d9ff3f1e8c 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -254,12 +254,10 @@ unsigned int __init dom0_max_vcpus(void)
     return max_vcpus;
 }
 
-struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
+void __init dom0_set_affinity(struct domain *dom0)
 {
     dom0->node_affinity = dom0_nodes;
     dom0->auto_node_affinity = !dom0_nr_pxms;
-
-    return vcpu_create(dom0, 0);
 }
 
 #ifdef CONFIG_SHADOW_PAGING
diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index d8eba73dac28..0512dde54746 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -11,6 +11,7 @@
 #include 
 
 #include 
+#include 
 
 unsigned int __init dom_max_vcpus(struct boot_domain *bd)
 {
@@ -29,6 +30,16 @@ unsigned int __init dom_max_vcpus(struct boot_domain *bd)
     return bd->max_vcpus;
 }
 
+struct vcpu *__init domain_vcpu0_create(struct boot_domain *bd)
+{
+    if ( has_dom0_caps(bd) )
+        dom0_set_affinity(bd->d);
+    else
+        bd->d->auto_node_affinity = true;
+
+    return vcpu_create(bd->d, 0);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index 740bfb74121c..c60b19c58aef 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -9,6 +9,7 @@
 #define __XEN_X86_BOOTDOMAIN_H__
 
 #include 
+#include 
 
 struct boot_domain {
     domid_t domid;
@@ -34,6 +35,14 @@ struct boot_domain {
     struct domain *d;
 };
 
+static inline bool __init has_dom0_caps(const struct boot_domain *bd)
+{
+    unsigned int dom0_caps = (DOMAIN_CAPS_CONTROL | DOMAIN_CAPS_HARDWARE | \
+                             DOMAIN_CAPS_XENSTORE);
+
+    return (bd->capabilities & dom0_caps) == dom0_caps;
+}
+
 #endif
 
 /*
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index ff021c24af9d..426def4115ce 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -8,6 +8,8 @@
 
 extern unsigned int dom0_memflags;
 
+void dom0_set_affinity(struct domain *dom0);
+
 unsigned long dom0_compute_nr_pages(struct domain *d,
                                     struct elf_dom_parms *parms,
                                     unsigned long initrd_len);
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index d3bde6c43e8d..409630089d29 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1057,9 +1057,11 @@ static struct domain *__init create_dom0(struct boot_info *bi)
     if ( IS_ERR(d) )
         panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
 
+    bd->d = d;
+
     init_dom0_cpuid_policy(d);
 
-    if ( alloc_dom0_vcpu0(d) == NULL )
+    if ( domain_vcpu0_create(bd) == NULL )
         panic("Error creating %pdv0\n", d);
 
     cmdline_size = domain_cmdline_size(bi, bd);
@@ -1102,7 +1104,6 @@ static struct domain *__init create_dom0(struct boot_info *bi)
         bd->cmdline = cmdline;
     }
 
-    bd->d = d;
     if ( construct_dom0(bd) != 0 )
         panic("Could not construct domain 0\n");
 
diff --git a/xen/include/xen/domain-builder.h b/xen/include/xen/domain-builder.h
index 82c929cc48a1..d3390d368afb 100644
--- a/xen/include/xen/domain-builder.h
+++ b/xen/include/xen/domain-builder.h
@@ -36,5 +36,6 @@ int builder_get_cmdline(const struct boot_info *bi, int offset,
                         char *cmdline, size_t size);
 
 unsigned int dom_max_vcpus(struct boot_domain *bd);
+struct vcpu *domain_vcpu0_create(struct boot_domain *bd);
 
 #endif /* __XEN_DOMAIN_BUILDER_H__ */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985362.1371347 (Exim 4.92)
	(envelope-from )
	id 1uFYW0-0007P3-3B; Thu, 15 May 2025 13:20:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985362.1371347; Thu, 15 May 2025 13: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 1uFYVz-0007O0-ST; Thu, 15 May 2025 13:20:47 +0000
Received: by outflank-mailman (input) for mailman id 985362;
 Thu, 15 May 2025 13:20:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYUJ-0001J6-SL
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:19:03 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2abc81b3-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:19:03 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315078114574.6524687166536;
 Thu, 15 May 2025 06:17:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2abc81b3-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315079; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=hle0EpaELWUygU6XbrjlF59XLBthTuCteNf6Ld1uOz9UM2wJMwgRKhOh0iRkSKeOtOr7mC4XQFPR1zWRXsUuUN/wZglyZn+hGp9LhV2yCsj03k0YzQmVSMpJDOb5PiAzX2DSkhVKRMXYwEJYFNFfI+6UPwoyTSKZxpLcDRACFZE=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315079; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=NrJIZ2u422M+EChC7p2J5b2ccR+5W2E9ih6TToJru2U=; 
	b=KA0tkxPStjrLBlUPeH7mt2YLq4WoqD++wViQQHxSOky3sF1kuKVuEkSDeCnoX/uEitLTAvpFENySdS2Dxxy8KDdB9ypc7yAOzD8eypEIAqQ24IFWR/a/PPxCsdAL6fddBOfgcLAtPzBl8PAKdqNaQ25+Vt3w4ef7H43i3Zd4ANs=
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=1747315079;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=NrJIZ2u422M+EChC7p2J5b2ccR+5W2E9ih6TToJru2U=;
	b=JW6jg3Rn3IG0WAucVS/OrK66+Be5Xm1fKyIVwYdP4kHhiVgf0nAhBWeBOl6GQja0
	SobCmtDRlzMV4CU5U8bkycW3shfTuzPZNlZrVB6VoDIXCddVhKyb5dAUruiqOq0ak3k
	FC/aLVXYuNbLttQJ0zVUY+zDQFlyKv8yh0YvA4w0=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 07/38] x86/hyperlaunch: move initial hwdom setup to dom_construct_pvh
Date: Thu, 15 May 2025 09:17:13 -0400
Message-Id: <20250515131744.3843-8-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Relocate the initial block of hwdom setup code from dom0_construct_pvh() over
to dom_construct_pvh().

No functional change.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/hvm/dom0_build.c | 44 ------------------------------
 xen/arch/x86/hvm/dom_build.c  | 50 +++++++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+), 44 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 0664f0543fd6..4f2eb0f97aba 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -1311,56 +1311,12 @@ static int __init pvh_setup_acpi(struct domain *d, paddr_t start_info)
     return 0;
 }
 
-static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
-{
-    unsigned int i;
-    int rc;
-
-    for ( i = 0; i < pci_mmcfg_config_num; i++ )
-    {
-        rc = register_vpci_mmcfg_handler(d, pci_mmcfg_config[i].address,
-                                         pci_mmcfg_config[i].start_bus_number,
-                                         pci_mmcfg_config[i].end_bus_number,
-                                         pci_mmcfg_config[i].pci_segment);
-        if ( rc )
-            printk("Unable to setup MMCFG handler at %#lx for segment %u\n",
-                   pci_mmcfg_config[i].address,
-                   pci_mmcfg_config[i].pci_segment);
-    }
-}
-
 int __init dom0_construct_pvh(const struct boot_domain *bd)
 {
     paddr_t entry, start_info;
     struct domain *d = bd->d;
     int rc;
 
-    printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id);
-
-    if ( bd->kernel == NULL )
-        panic("Missing kernel boot module for %pd construction\n", d);
-
-    if ( is_hardware_domain(d) )
-    {
-        /*
-         * MMCFG initialization must be performed before setting domain
-         * permissions, as the MCFG areas must not be part of the domain IOMEM
-         * accessible regions.
-         */
-        pvh_setup_mmcfg(d);
-
-        /*
-         * Setup permissions early so that calls to add MMIO regions to the
-         * p2m as part of vPCI setup don't fail due to permission checks.
-         */
-        rc = dom0_setup_permissions(d);
-        if ( rc )
-        {
-            printk("%pd unable to setup permissions: %d\n", d, rc);
-            return rc;
-        }
-    }
-
     /*
      * Craft dom0 physical memory map and set the paging allocation. This must
      * be done before the iommu initializion, since iommu initialization code
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index 8546cfff1fbf..a5f259b6352d 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -8,15 +8,65 @@
  * Copyright (C) 2025 Apertus Solutions, LLC
  */
 
+#include 
 #include 
+#include 
+
+#include 
 
 #include 
 #include 
+#include 
+#include 
+
+static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
+{
+    unsigned int i;
+    int rc;
+
+    for ( i = 0; i < pci_mmcfg_config_num; i++ )
+    {
+        rc = register_vpci_mmcfg_handler(d, pci_mmcfg_config[i].address,
+                                         pci_mmcfg_config[i].start_bus_number,
+                                         pci_mmcfg_config[i].end_bus_number,
+                                         pci_mmcfg_config[i].pci_segment);
+        if ( rc )
+            printk("Unable to setup MMCFG handler at %#lx for segment %u\n",
+                   pci_mmcfg_config[i].address,
+                   pci_mmcfg_config[i].pci_segment);
+    }
+}
 
 int __init dom_construct_pvh(struct boot_domain *bd)
 {
+    int rc;
+
     printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", bd->domid);
 
+    if ( bd->kernel == NULL )
+        panic("Missing kernel boot module for %pd construction\n", bd->d);
+
+    if ( is_hardware_domain(bd->d) )
+    {
+        /*
+         * MMCFG initialization must be performed before setting domain
+         * permissions, as the MCFG areas must not be part of the domain IOMEM
+         * accessible regions.
+         */
+        pvh_setup_mmcfg(bd->d);
+
+        /*
+         * Setup permissions early so that calls to add MMIO regions to the
+         * p2m as part of vPCI setup don't fail due to permission checks.
+         */
+        rc = dom0_setup_permissions(bd->d);
+        if ( rc )
+        {
+            printk("%pd unable to setup permissions: %d\n", bd->d, rc);
+            return rc;
+        }
+    }
+
     return dom0_construct_pvh(bd);
 }
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985366.1371354 (Exim 4.92)
	(envelope-from )
	id 1uFYW1-0007Wy-0q; Thu, 15 May 2025 13:20:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985366.1371354; Thu, 15 May 2025 13: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 1uFYW0-0007UC-BW; Thu, 15 May 2025 13:20:48 +0000
Received: by outflank-mailman (input) for mailman id 985366;
 Thu, 15 May 2025 13:20:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYVk-0001J6-21
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:20:32 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5f41ec04-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:20:31 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 174731510102267.71929642819794;
 Thu, 15 May 2025 06:18: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" 
X-Inumbo-ID: 5f41ec04-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315103; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=ZjErjESZmQCdzQGcYKz/tDHTWN/O7qERZsfm2lP4q2LWGD/mwbQV5twK5bvlkGkfkXs8JkQonozwFjbkiNhcI9NdpwH+B9Y608fnafaxiTF98oYkYTtMQKBC/PyzRSdz2sXKjcRGOSRjaW3vBe4XO31m1oJqt1eZnHF2XiWMTpo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315103; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=vJ85DDGywMQZu37DcdO2L0xHkt6GG4rEFGjp+TkyIGY=; 
	b=gY+cVlJXaBORRxSKnaGBm+d07xr0XSbj59GTSAwhqbkEQ47AjMrh0jWLhqmUjTbNsX9MSsbHjph1zo+9lR7GfHRNUDeHW9azY3K0EdRS7kxuYAsclHbHR80FNQKjc2jDGw4yzxVx95ER3cKhBcvpHYi0i1zW1IW4NfCEQNcj8Ss=
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=1747315103;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=vJ85DDGywMQZu37DcdO2L0xHkt6GG4rEFGjp+TkyIGY=;
	b=D9p8SELWqo0wCv97+ADoLWaHggOGrqxhjotCIXUr+vMztfmNFV5PPeM/DQksGmyK
	Ggr5xxPNlmCJeOqVMG8kZg+rrW9XSgAGGABNSo16rlfqe9h8G87ANV11fBSQWTYSg3G
	XpYdezxcaXnR+5UN9dbeoglwZCEgEfIiz42FODKw=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Dario Faggioli ,
	Juergen Gross ,
	George Dunlap ,
	Christopher Clark 
Subject: [RFCv2 15/38] x86/boot: move and rename sched_setup_dom0_vcpus
Date: Thu, 15 May 2025 09:17:21 -0400
Message-Id: <20250515131744.3843-16-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Relocated the function sched_setup_dom0_vcpus(), which was protected by an
ifdef CONFIG_X86, from common/sched to the hyperlaunch domain builder. Rename
it to alloc_dom_vcpus() to better reflect the purpose of the function.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/domain-builder/domain.c | 10 ++++++++++
 xen/arch/x86/hvm/dom0_build.c        |  3 ++-
 xen/arch/x86/pv/dom0_build.c         |  3 ++-
 xen/common/sched/core.c              | 12 ------------
 xen/include/xen/domain-builder.h     |  2 ++
 xen/include/xen/sched.h              |  1 -
 6 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index 258f777cd9ee..d934b240229f 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -45,6 +45,16 @@ struct vcpu *__init domain_vcpu0_create(struct boot_domain *bd)
     return vcpu_create(bd->d, 0);
 }
 
+void __init domain_vcpus_create(struct domain *d)
+{
+    unsigned int i;
+
+    for ( i = 1; i < d->max_vcpus; i++ )
+        vcpu_create(d, i);
+
+    domain_update_node_affinity(d);
+}
+
 unsigned long __init dom_paging_pages(
     const struct boot_domain *bd, unsigned long nr_pages)
 {
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 6990c1d3a882..a900138b0311 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -833,7 +834,7 @@ static int __init pvh_setup_cpus(struct domain *d, paddr_t entry,
         .cpu_regs.x86_32.tr_ar = 0x8b,
     };
 
-    sched_setup_dom0_vcpus(d);
+    domain_vcpus_create(d);
 
     rc = arch_set_info_hvm_guest(v, &cpu_ctx);
     if ( rc )
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index ad4d1cc3520c..195c0902d5a1 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -827,7 +828,7 @@ static int __init dom0_construct(struct boot_domain *bd)
 
     printk("Dom%u has maximum %u VCPUs\n", d->domain_id, d->max_vcpus);
 
-    sched_setup_dom0_vcpus(d);
+    domain_vcpus_create(d);
 
     d->arch.paging.mode = 0;
 
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 9043414290a8..d679d766a4b6 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -3479,18 +3479,6 @@ void wait(void)
     schedule();
 }
 
-#ifdef CONFIG_X86
-void __init sched_setup_dom0_vcpus(struct domain *d)
-{
-    unsigned int i;
-
-    for ( i = 1; i < d->max_vcpus; i++ )
-        vcpu_create(d, i);
-
-    domain_update_node_affinity(d);
-}
-#endif
-
 #ifdef CONFIG_COMPAT
 #include "compat.c"
 #endif
diff --git a/xen/include/xen/domain-builder.h b/xen/include/xen/domain-builder.h
index d3390d368afb..79e4c50ddf85 100644
--- a/xen/include/xen/domain-builder.h
+++ b/xen/include/xen/domain-builder.h
@@ -6,6 +6,7 @@
 
 struct boot_info;
 struct boot_domain;
+struct domain;
 
 /* Return status of builder_init(). Shows which boot mechanism was detected */
 enum fdt_kind
@@ -37,5 +38,6 @@ int builder_get_cmdline(const struct boot_info *bi, int offset,
 
 unsigned int dom_max_vcpus(struct boot_domain *bd);
 struct vcpu *domain_vcpu0_create(struct boot_domain *bd);
+void domain_vcpus_create(struct domain *d);
 
 #endif /* __XEN_DOMAIN_BUILDER_H__ */
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 559d201e0c7e..4f184cd76206 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1084,7 +1084,6 @@ static inline bool sched_has_urgent_vcpu(void)
 }
 
 void vcpu_set_periodic_timer(struct vcpu *v, s_time_t value);
-void sched_setup_dom0_vcpus(struct domain *d);
 int vcpu_temporary_affinity(struct vcpu *v, unsigned int cpu, uint8_t reason);
 int vcpu_set_hard_affinity(struct vcpu *v, const cpumask_t *affinity);
 int vcpu_affinity_domctl(struct domain *d, uint32_t cmd,
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:20:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:20:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985377.1371377 (Exim 4.92)
	(envelope-from )
	id 1uFYWB-0000qi-I7; Thu, 15 May 2025 13:20:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985377.1371377; Thu, 15 May 2025 13: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 1uFYWB-0000qG-CM; Thu, 15 May 2025 13:20:59 +0000
Received: by outflank-mailman (input) for mailman id 985377;
 Thu, 15 May 2025 13:20:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYWA-0006hT-Os
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:20:58 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6e759868-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:20:56 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315104638519.7623353843491;
 Thu, 15 May 2025 06:18: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" 
X-Inumbo-ID: 6e759868-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315107; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=eqRz7MHW8ElvQYgJIsqplWEPyVf9fWZE0cV0OUnLmlTni7ODxB3GuHX0lREvPxrEgvcEKBxmxm6yc2TuEjVvWOs6j94THdfkiKTcPv58hoDwqaqruDdFBoahpTCRUnsY0598Exg41v8cTP3U1Rb/3BZjhdI5codUIyHrwdxFoTY=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315107; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=TSv4qvsiTicFq/fqTWX6HfFCXcyJ+7TZ4TAASla3DBM=; 
	b=fRc+7y6ZQvxUxR6sV6OE5UVRxSyriCUoJRSH9mdnNb4ezz2PTTI8WwDipZ69Xu8M/9Ip1UpAIEPohtXLCuG9y/Xg0wNgV1RyT58GJPPL6aU3NPO7deyzjrFVu1ujXACLEfTIQlKr2M4mAeNN3RnJBVrjhWIGiV++fE+ZRY85NXU=
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=1747315107;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=TSv4qvsiTicFq/fqTWX6HfFCXcyJ+7TZ4TAASla3DBM=;
	b=OaP3wSLMZcMJpqZwDtCsr0O8oqiVhbqDiZsijHSm/KtJAdCOr/KdQ7oNImpa90jE
	dMr+C0vWBWAyuBBXWt1OYC16i1fi3s4q++5jwOF2WueKhtOkUa6+3kFNjujLlAgUaZe
	HRHRz+EWzTqhmEkc+FnFBcxfLr1yQVhZjlJaqORU=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 19/38] x86/hyperlaunch: move populating p2m under domain builder
Date: Thu, 15 May 2025 09:17:25 -0400
Message-Id: <20250515131744.3843-20-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Introduce hvm_populate_p2m() for populating domU p2m maps. Rename
pvh_populate_p2m() to dom0_pvh_populate_p2m() and export it. With these
adjustments, move the calls to populate the p2m maps under domain builder.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/hvm/dom0_build.c             | 14 ++------
 xen/arch/x86/hvm/dom_build.c              | 39 +++++++++++++++++++++++
 xen/arch/x86/include/asm/dom0_build.h     |  1 +
 xen/arch/x86/include/asm/domain-builder.h |  2 ++
 4 files changed, 45 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 9ea8acbb5a02..36d2e7e13948 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -89,9 +89,8 @@ static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
 }
 
 /* Populate a HVM memory range using the biggest possible order. */
-static int __init pvh_populate_memory_range(struct domain *d,
-                                            unsigned long start,
-                                            unsigned long nr_pages)
+int __init pvh_populate_memory_range(
+    struct domain *d, unsigned long start, unsigned long nr_pages)
 {
     static const struct {
         unsigned long align;
@@ -400,7 +399,7 @@ void __init dom0_pvh_setup_e820(struct domain *d, unsigned long nr_pages)
     ASSERT(cur_pages == nr_pages);
 }
 
-static int __init pvh_populate_p2m(struct domain *d)
+int __init dom0_pvh_populate_p2m(struct domain *d)
 {
     struct vcpu *v = d->vcpu[0];
     unsigned int i;
@@ -1262,13 +1261,6 @@ int __init dom0_construct_pvh(struct boot_domain *bd)
     struct domain *d = bd->d;
     int rc;
 
-    rc = pvh_populate_p2m(d);
-    if ( rc )
-    {
-        printk("Failed to setup Dom0 physical memory map\n");
-        return rc;
-    }
-
     rc = pvh_load_kernel(bd, &entry, &start_info);
     if ( rc )
     {
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index e724d578c5d4..4bbd5d2b8e24 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -248,6 +250,33 @@ int __init hvm_setup_cpus(
     return 0;
 }
 
+static int __init hvm_populate_p2m(struct domain *d)
+{
+    unsigned int i;
+
+    /* Populate memory map. */
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        int rc;
+        unsigned long addr, size;
+
+        if ( d->arch.e820[i].type != E820_RAM &&
+             d->arch.e820[i].type != E820_ACPI &&
+             PFN_DOWN(d->arch.e820[i].addr) != START_SPECIAL_REGION )
+                continue;
+
+        addr = PFN_DOWN(d->arch.e820[i].addr);
+        size = PFN_DOWN(d->arch.e820[i].size);
+
+        rc = pvh_populate_memory_range(d, addr, size);
+        if ( rc )
+            return rc;
+
+    }
+
+    return 0;
+}
+
 int __init dom_construct_pvh(struct boot_domain *bd)
 {
     int rc;
@@ -289,6 +318,16 @@ int __init dom_construct_pvh(struct boot_domain *bd)
     if ( is_hardware_domain(bd->d) )
         iommu_hwdom_init(bd->d);
 
+    if ( is_control_domain(bd->d) || is_hardware_domain(bd->d) )
+        rc = dom0_pvh_populate_p2m(bd->d);
+    else
+        rc = hvm_populate_p2m(bd->d);
+    if ( rc )
+    {
+        printk("Failed to setup HVM/PVH %pd physical memory map\n", bd->d);
+        return rc;
+    }
+
     return dom0_construct_pvh(bd);
 }
 
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index 36f563bd9d5b..3819b3f4e7a4 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -21,6 +21,7 @@ void dom0_pv_restrict_pages(
 void dom0_pvh_setup_e820(struct domain *d, unsigned long nr_pages);
 
 int dom0_pvh_setup_acpi(struct domain *d, paddr_t start_info);
+int dom0_pvh_populate_p2m(struct domain *d);
 
 int dom0_construct_pv(struct boot_domain *bd);
 int dom0_construct_pvh(struct boot_domain *bd);
diff --git a/xen/arch/x86/include/asm/domain-builder.h b/xen/arch/x86/include/asm/domain-builder.h
index a27413edb380..2de73117cb7f 100644
--- a/xen/arch/x86/include/asm/domain-builder.h
+++ b/xen/arch/x86/include/asm/domain-builder.h
@@ -5,6 +5,8 @@ struct boot_domain;
 struct elf_dom_parms;
 
 int hvm_setup_cpus(struct domain *d, paddr_t entry, paddr_t start_info);
+int pvh_populate_memory_range(
+    struct domain *d, unsigned long start, unsigned long nr_pages);
 
 unsigned long dom_paging_pages(
     const struct boot_domain *d, unsigned long nr_pages);
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:23:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:23:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985410.1371387 (Exim 4.92)
	(envelope-from )
	id 1uFYYA-0003Fg-TK; Thu, 15 May 2025 13:23:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985410.1371387; Thu, 15 May 2025 13: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 1uFYYA-0003FZ-QT; Thu, 15 May 2025 13:23:02 +0000
Received: by outflank-mailman (input) for mailman id 985410;
 Thu, 15 May 2025 13:23:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYY9-0003FO-Qr
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:23:01 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b8718002-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:23:00 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 174731520599024.49651166654428;
 Thu, 15 May 2025 06:20:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b8718002-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315208; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=dV1p4NYjrYg/Vnx5/k3yl+dgPiaquQyz36AD5QxaXuIjQCdRAraLFfpHybW83+wnUGkZsVUPYoLoMA5IYnd6k150YXu8UPrOKmGO1I5jF+eV9pcEAXpq7EOG5uVYj7cmRUBPAia+Bi3hmYLyab/YTL4ISvaTxW8SDMY9t0Wo1sU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315208; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=imigURWHglyWIuq1A0YkYk/udC9gzexmxl5Bel/xCFE=; 
	b=HK8kM3SgmQK4el2y3e/8lj42h8DqjNzhdzFlFkC0VJM2WekmXG9kfQCMF2yeuauvAUngyxHgSmK+4cZfPRPSdaU8XQ3+sTk5j1Na04EQDsEsjiRtuIcc2bJZ+VrfC4yUzWAzPD+iWpQsn5TGnYI6ZUwWDb+jDADMePMTSrlDOpY=
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=1747315208;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=imigURWHglyWIuq1A0YkYk/udC9gzexmxl5Bel/xCFE=;
	b=Hjok7mmJZNP8X5xQ386/sN4YX5jMO0U1dJbH74qHVr7fyI/jaCLu3OcxpsJgaWzV
	cjY9CGfG2glrvJdguvWYc0RmEJd2rGnJmsrcwrPhe3wyHS3qZkH+BkZxEZbqLyS5C9R
	ZgcDpCcex15UEWtPRUWmzTA+OIxgtek8ErNWeGIg=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [RFCv2 32/38] x86/hyperlaunch: move headroom under domain builder
Date: Thu, 15 May 2025 09:19:44 -0400
Message-Id: <20250515131951.5594-3-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131951.5594-1-dpsmith@apertussolutions.com>
References: <20250515131951.5594-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The function bzimage_headroom attempted to determine the necessary headroom for
all supported kernel types, not just bzImage. The result was convoluted logic
to handle three kernel image types, and then within the bzImage type, also
handle three types of payloads.

This commit moves the generalized headroom determination for the three kernel
types to the domain builder and scopes bziamge_headroom to only doing headroom
calculations for bzimage payload types.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/bzimage.c                    | 43 +++++++++++------------
 xen/arch/x86/domain-builder/domain.c      | 24 +++++++++++++
 xen/arch/x86/include/asm/bzimage.h        |  1 +
 xen/arch/x86/include/asm/domain-builder.h |  2 ++
 xen/arch/x86/setup.c                      |  6 ++--
 xen/include/xen/gunzip.h                  |  9 +++++
 6 files changed, 58 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c
index eaea64b9c014..ba090b3ef9d6 100644
--- a/xen/arch/x86/bzimage.c
+++ b/xen/arch/x86/bzimage.c
@@ -47,8 +47,10 @@ struct __packed setup_header {
         uint32_t        payload_length;
     };
 
-static __init int bzimage_check(struct setup_header *hdr, unsigned long len)
+int __init bzimage_check(void *image, unsigned long len)
 {
+    struct setup_header *hdr = (struct setup_header *)image;
+
     if ( len < sizeof(struct setup_header) )
         return 0;
 
@@ -56,9 +58,10 @@ static __init int bzimage_check(struct setup_header *hdr, unsigned long len)
         return 0;
 
     if ( hdr->version < VERSION(2,8) ) {
-        printk("Cannot load bzImage v%d.%02d at least v2.08 is required\n",
-           hdr->version >> 8, hdr->version & 0xff);
-        return -EINVAL;
+        printk(XENLOG_ERR
+               "Cannot load bzImage v%d.%02d at least v2.08 is required\n",
+               hdr->version >> 8, hdr->version & 0xff);
+        return 0;
     }
     return 1;
 }
@@ -69,34 +72,28 @@ unsigned long __init bzimage_headroom(void *image_start,
                                       unsigned long image_length)
 {
     struct setup_header *hdr = (struct setup_header *)image_start;
-    int err;
     unsigned long headroom;
 
-    err = bzimage_check(hdr, image_length);
-    if ( err < 0 )
-        return 0;
-
-    if ( err > 0 )
-    {
-        image_start += (hdr->setup_sects + 1) * 512 + hdr->payload_offset;
-        image_length = hdr->payload_length;
-    }
-
-    if ( elf_is_elfbinary(image_start, image_length) )
-        return 0;
+    image_start += (hdr->setup_sects + 1) * 512 + hdr->payload_offset;
+    image_length = hdr->payload_length;
 
     orig_image_len = image_length;
     /* Linux build system mimics gzip isize field for bzip2/lzma algos */
     headroom = gzip_isize(image_start, image_length);
+    /*
+     * Final headroom:
+     *  - gzip: original size + heuristically derived value
+     *  - uncompressed kernel: zero the headroom
+     *  - bzip2 & lzma: original size + payload size
+     */
     if (gzip_check(image_start, image_length))
-    {
-        headroom += headroom >> 12; /* Add 8 bytes for every 32K input block */
-        headroom += (32768 + 18); /* Add 32K + 18 bytes of extra headroom */
-    } else
+        headroom = gzip_headroom(headroom);
+    else if ( elf_is_elfbinary(image_start, image_length) )
+        headroom = 0;
+    else
         headroom += image_length;
-    headroom = (headroom + 4095) & ~4095;
 
-    return headroom;
+    return ROUNDUP(headroom, PAGE_SIZE);
 }
 
 int __init bzimage_parse(void *image_base, void **image_start,
diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index 673fc5b16ed3..9c2f30eee8bd 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include  /* get types.h for libefl.h */
 #include 
@@ -20,6 +21,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -247,6 +249,28 @@ static size_t __init domain_cmdline_size(const struct boot_info *bi,
     return s;
 }
 
+/* Xen x86 supports two kernel types that requires headroom:
+ *  - Linux bzImage
+ *  - Linux vmlinuz aka vmlinux.gz
+ */
+void __init arch_builder_headroom(struct boot_domain *bd)
+{
+    void *image = bootstrap_map_bm(bd->kernel);
+    unsigned long length = bd->kernel->size;
+
+    if ( bzimage_check(image, length) )
+        bd->kernel->headroom = bzimage_headroom(image, length);
+    else if ( gzip_check(image, length) )
+    {
+        unsigned long headroom = gzip_isize(image, length);
+        bd->kernel->headroom = gzip_headroom(headroom);
+    }
+    else
+        bd->kernel->headroom = 0;
+
+    bootstrap_unmap();
+}
+
 struct domain *__init arch_create_dom(
     struct boot_info *bi, struct boot_domain *bd)
 {
diff --git a/xen/arch/x86/include/asm/bzimage.h b/xen/arch/x86/include/asm/bzimage.h
index 7ed69d39103d..c3a042f177ac 100644
--- a/xen/arch/x86/include/asm/bzimage.h
+++ b/xen/arch/x86/include/asm/bzimage.h
@@ -3,6 +3,7 @@
 
 #include 
 
+int bzimage_check(void *image, unsigned long len);
 unsigned long bzimage_headroom(void *image_start, unsigned long image_length);
 
 int bzimage_parse(void *image_base, void **image_start,
diff --git a/xen/arch/x86/include/asm/domain-builder.h b/xen/arch/x86/include/asm/domain-builder.h
index 6ef4776faf9a..f1749d2786c6 100644
--- a/xen/arch/x86/include/asm/domain-builder.h
+++ b/xen/arch/x86/include/asm/domain-builder.h
@@ -20,6 +20,8 @@ int hvm_alloc_xenstore_page(struct boot_domain *bd, xen_pfn_t *xs_gfn);
 unsigned long dom_paging_pages(
     const struct boot_domain *d, unsigned long nr_pages);
 
+void arch_builder_headroom(struct boot_domain *bd);
+
 unsigned long dom_compute_nr_pages(
     struct boot_domain *bd, struct elf_dom_parms *parms);
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index b2c7846be18f..36e6ba11ddcd 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1330,10 +1331,7 @@ void asmlinkage __init noreturn __start_xen(void)
         xen->size  = __2M_rwdata_end - _stext;
     }
 
-    bi->domains[0].kernel->headroom =
-        bzimage_headroom(bootstrap_map_bm(bi->domains[0].kernel),
-                         bi->domains[0].kernel->size);
-    bootstrap_unmap();
+    arch_builder_headroom(&bi->domains[0]);
 
 #ifndef highmem_start
     /* Don't allow split below 4Gb. */
diff --git a/xen/include/xen/gunzip.h b/xen/include/xen/gunzip.h
index 1b45350c195f..c8a0d59eef9d 100644
--- a/xen/include/xen/gunzip.h
+++ b/xen/include/xen/gunzip.h
@@ -1,10 +1,19 @@
 #ifndef __XEN_GUNZIP_H
 #define __XEN_GUNZIP_H
 
+#include 
+#include 
 #include 
 
 int gzip_check(char *image, unsigned long image_len);
 uint32_t gzip_isize(char *image, unsigned long image_len);
 int perform_gunzip(char *output, char *image, unsigned long image_len);
 
+static inline unsigned long gzip_headroom(unsigned long headroom)
+{
+    headroom += headroom >> 12; /* Add 8 bytes for every 32K input block */
+    headroom += (32768 + 18); /* Add 32K + 18 bytes of extra headroom */
+
+    return ROUNDUP(headroom, PAGE_SIZE);
+}
 #endif
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:23:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:23:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985414.1371397 (Exim 4.92)
	(envelope-from )
	id 1uFYYU-0003eK-4Z; Thu, 15 May 2025 13:23:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985414.1371397; Thu, 15 May 2025 13: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 1uFYYU-0003eB-1B; Thu, 15 May 2025 13:23:22 +0000
Received: by outflank-mailman (input) for mailman id 985414;
 Thu, 15 May 2025 13:23:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYYT-0003FO-7O
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:23:21 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c43d0db4-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:23:20 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315204898137.1461395774836;
 Thu, 15 May 2025 06:20: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" 
X-Inumbo-ID: c43d0db4-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315208; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=BzxyQjXRY00clL21ob1gVJLY385JcYVyBn1Hx/iww+l7hoZBGVRkpPQieqc/VxVACzL4Vevu7RVzqcQCyYxMf9vBB/DPDzJwMyOzYOu9Uzd9YO2DrHfAfxEvHb4YvAd1RUp06ZoEodfeLckRC5NLir+cKosDbkApxcb2GektUeY=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315208; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=TH0TMFdedjMThleKM+wTQxxJrcskN+YzfLSHIdAn7Rk=; 
	b=KLs05idmmBdlzfIwimUS5Hb49kjwHEonBlp5vATQ5rH2gp0tNkCxUCOUXaER0FLen2LbtphFGcMJkCV4hPGi0Gns1fNDa1oRsDkeUGOcHzFPpvr2BvZV+tDPsmMAR9VN4mYtVaUVnQ8W2xLoWeHdlHs8Vzj1YhkGS23ptwFqRNg=
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=1747315208;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=TH0TMFdedjMThleKM+wTQxxJrcskN+YzfLSHIdAn7Rk=;
	b=pDUcIuL5WktDikVhom0GsRJ5sWMuWIc5Vrycr6AEk52cILKY4X0DpCwZyZEVu8IJ
	T/a+klYONmKS4Oeux8QqeANFYc5vDNcJ7JuDFzFWXs3G3eIInDC9T6yPKAsHqoxWNf9
	Rp5rha7YVsXOcmPOJlhVQg0QskRcjz9A4gLnJG5I=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [RFCv2 31/38] common/gzip: add function to read isize field
Date: Thu, 15 May 2025 09:19:43 -0400
Message-Id: <20250515131951.5594-2-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131951.5594-1-dpsmith@apertussolutions.com>
References: <20250515131951.5594-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The gzip specification dictates that the last four bytes of a gzip
file will contain the modulo 2^32 of the original image size. Since
this is a function of gzip, relocate the logic under a gzip function.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/bzimage.c   | 10 +++-------
 xen/common/gzip/gunzip.c | 12 ++++++++++++
 xen/include/xen/gunzip.h |  3 +++
 3 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c
index 66f648f311e4..eaea64b9c014 100644
--- a/xen/arch/x86/bzimage.c
+++ b/xen/arch/x86/bzimage.c
@@ -8,11 +8,6 @@
 #include 
 #include 
 
-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;
@@ -91,7 +86,8 @@ unsigned long __init bzimage_headroom(void *image_start,
         return 0;
 
     orig_image_len = image_length;
-    headroom = output_length(image_start, image_length);
+    /* Linux build system mimics gzip isize field for bzip2/lzma algos */
+    headroom = gzip_isize(image_start, image_length);
     if (gzip_check(image_start, image_length))
     {
         headroom += headroom >> 12; /* Add 8 bytes for every 32K input block */
@@ -124,7 +120,7 @@ int __init bzimage_parse(void *image_base, void **image_start,
 
     BUG_ON(!(image_base < *image_start));
 
-    output_len = output_length(*image_start, orig_image_len);
+    output_len = gzip_isize(*image_start, orig_image_len);
 
     if ( (err = perform_gunzip(image_base, *image_start, orig_image_len)) > 0 )
         err = decompress(*image_start, orig_image_len, image_base);
diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c
index 89f45d4050ba..0963fe7bbd17 100644
--- a/xen/common/gzip/gunzip.c
+++ b/xen/common/gzip/gunzip.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define WSIZE           0x80000000U
 
@@ -106,6 +107,17 @@ __init int gzip_check(char *image, unsigned long image_len)
     return (magic0 == 0x1f) && ((magic1 == 0x8b) || (magic1 == 0x9e));
 }
 
+/*
+ * RFC 1952 specifies the last four bytes as the isize field, the size of the
+ * original (uncompressed) input data modulo 2^32.
+ */
+__init uint32_t gzip_isize(char *image, unsigned long image_len)
+{
+    uint32_t *ptr = (uint32_t *)(image + image_len - 4);
+
+    return get_unaligned(ptr);
+}
+
 __init int perform_gunzip(char *output, char *image, unsigned long image_len)
 {
     struct gunzip_state *s;
diff --git a/xen/include/xen/gunzip.h b/xen/include/xen/gunzip.h
index 805833127aba..1b45350c195f 100644
--- a/xen/include/xen/gunzip.h
+++ b/xen/include/xen/gunzip.h
@@ -1,7 +1,10 @@
 #ifndef __XEN_GUNZIP_H
 #define __XEN_GUNZIP_H
 
+#include 
+
 int gzip_check(char *image, unsigned long image_len);
+uint32_t gzip_isize(char *image, unsigned long image_len);
 int perform_gunzip(char *output, char *image, unsigned long image_len);
 
 #endif
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:30:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:30:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985451.1371407 (Exim 4.92)
	(envelope-from )
	id 1uFYfV-0005bW-Qp; Thu, 15 May 2025 13:30:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985451.1371407; Thu, 15 May 2025 13:30: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 1uFYfV-0005bP-O0; Thu, 15 May 2025 13:30:37 +0000
Received: by outflank-mailman (input) for mailman id 985451;
 Thu, 15 May 2025 13:30:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYZV-0006hT-20
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:24:25 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e98c8d77-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:24:23 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315211563443.9388785299774;
 Thu, 15 May 2025 06:20: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" 
X-Inumbo-ID: e98c8d77-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315214; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=Lrl/iWV4LZ/VZwxor6BQyIVOaqxm2Hp9USrEpLEurxPhutLPnVS3cK5JjZEuwi/hn9h9oSBEq6vVDzai2SKyw1sfu2U9HBQDkXXqoZsdSMGKu1w48cXIchx1B4dWoYnr47lRtijXxU5yO4i8g81fuxA6eUGFhcOv2O70G7DbhMM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315214; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=Mw5Odp6bgq0ypnGyk6hZln2JaXDA/NCzGFeI/Jyp6zU=; 
	b=HHT5CMszLeNgz1Bv/XPj1CKyjh+fSwJoqe+1Lk59/GU5gJXsOjWWg7A3EWb6mWFW36pcGNy+igYn6n0QkEGJpNVW33s73VDSVaAMoEIQHnqqJg0J6v8uGfdMjho4xBLNVK3cI60ig8bVlhlOD6i5azGccpOp2QiEF35Z8OAraRQ=
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=1747315214;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=Mw5Odp6bgq0ypnGyk6hZln2JaXDA/NCzGFeI/Jyp6zU=;
	b=tYPbNdOlonZ0xHNBgWW40Daz51zlponrA9NG2bji8R8gGNVB6mYNaCWpKAqAG7qE
	LIeRM+x2h6dwwamSYepeuvPD79FeTjTRT/4xTpnImW2Fz8YtTPqAKyjS68a2kCJWivL
	Kz1QtURdaNFeZqXhYx1CD5lsWz6Cx53ZRFd0cjUI=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [RFCv2 38/38] tools: introduce hyperlaunch domain late init
Date: Thu, 15 May 2025 09:19:50 -0400
Message-Id: <20250515131951.5594-9-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131951.5594-1-dpsmith@apertussolutions.com>
References: <20250515131951.5594-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The late domain init helper is a helper tool for late setup of Xenstore for a
domain that was created by the hypervisor using hyperlaunch.

Signed-off-by: Daniel P. Smith 
---
 .gitignore                        |   1 +
 tools/helpers/Makefile            |  12 +
 tools/helpers/late-init-domains.c | 364 ++++++++++++++++++++++++++++++
 tools/helpers/late-init-domains.h |  18 ++
 tools/helpers/xs-helpers.c        | 117 ++++++++++
 tools/helpers/xs-helpers.h        |  26 +++
 6 files changed, 538 insertions(+)
 create mode 100644 tools/helpers/late-init-domains.c
 create mode 100644 tools/helpers/late-init-domains.h
 create mode 100644 tools/helpers/xs-helpers.c
 create mode 100644 tools/helpers/xs-helpers.h

diff --git a/.gitignore b/.gitignore
index 53f5df000383..7b0c390dbe0d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -122,6 +122,7 @@ tools/flask/utils/flask-label-pci
 tools/helpers/init-dom0less
 tools/helpers/init-xenstore-domain
 tools/helpers/xen-init-dom0
+tools/helpers/late-init-domains
 tools/hotplug/common/hotplugpath.sh
 tools/hotplug/FreeBSD/rc.d/xencommons
 tools/hotplug/FreeBSD/rc.d/xendriverdomain
diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
index 09590eb5b6f0..26fa079e8b1f 100644
--- a/tools/helpers/Makefile
+++ b/tools/helpers/Makefile
@@ -14,6 +14,7 @@ ifeq ($(CONFIG_ARM),y)
 TARGETS += init-dom0less
 endif
 endif
+TARGETS += late-init-domains
 
 XEN_INIT_DOM0_OBJS = xen-init-dom0.o init-dom-json.o
 $(XEN_INIT_DOM0_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
@@ -39,6 +40,14 @@ $(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
 $(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
 init-dom0less: LDLIBS += $(call xenlibs-ldlibs,ctrl evtchn toollog store light guest foreignmemory)
 
+LATE_INIT_DOMAINS_OBJS = late-init-domains.o xs-helpers.o init-dom-json.o
+$(LATE_INIT_DOMAINS_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
+$(LATE_INIT_DOMAINS_OBJS): CFLAGS += $(CFLAGS_libxenguest)
+$(LATE_INIT_DOMAINS_OBJS): CFLAGS += $(CFLAGS_libxenlight)
+$(LATE_INIT_DOMAINS_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
+$(LATE_INIT_DOMAINS_OBJS): CFLAGS += $(CFLAGS_libxenstore)
+late-init-domains: LDLIBS += $(call xenlibs-ldlibs,ctrl toollog store light guest)
+
 .PHONY: all
 all: $(TARGETS)
 
@@ -51,6 +60,9 @@ init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS)
 init-dom0less: $(INIT_DOM0LESS_OBJS)
 	$(CC) $(LDFLAGS) -o $@ $(INIT_DOM0LESS_OBJS) $(LDLIBS) $(APPEND_LDFLAGS)
 
+late-init-domains: $(LATE_INIT_DOMAINS_OBJS)
+	$(CC) $(LDFLAGS) -o $@ $(LATE_INIT_DOMAINS_OBJS) $(LDLIBS)  $(APPEND_LDFLAGS)
+
 .PHONY: install
 install: all
 	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
diff --git a/tools/helpers/late-init-domains.c b/tools/helpers/late-init-domains.c
new file mode 100644
index 000000000000..06911d2e93d1
--- /dev/null
+++ b/tools/helpers/late-init-domains.c
@@ -0,0 +1,364 @@
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "init-dom-json.h"
+#include "late-init-domains.h"
+#include "xs-helpers.h"
+
+static struct option options[] = {
+    { "console", 0, NULL, 'c' },
+    { "xenstore", 1, NULL, 'x' },
+    { "force", 0, NULL, 'f' },
+    { "verbose", 0, NULL, 'v' },
+    { "help", 0, NULL, 'h' },
+    { NULL, 0, NULL, 0 }
+};
+
+static void usage(void)
+{
+    fprintf(stderr,
+"Usage:\n"
+"\n"
+"late-init-domains \n"
+"\n"
+"where options may include:\n"
+"\n"
+"  --console     configure the console\n"
+"  --xenstore     domain id of the xenstore domain\n"
+"  --force                  force domain introduction even if xenstore entries exist\n"
+"  -v[v[v]]                 verbosity constructing xenstore tree\n"
+"  --help                   help message\n");
+}
+
+#define XS_DOM_PERM(x, d, k, v)                                             \
+    ret = do_xs_write_dom_with_perm(x, d, k, v, perms, num_perms);          \
+    if ( ret != 0 ) return ret                                              \
+
+#define XS_DIR_PERM(x, p, k, v)                                             \
+    ret = do_xs_write_dir_node_with_perm(x, p, k, v, perms, num_perms);     \
+    if ( ret != 0 ) return ret                                              \
+
+static int pages_from_hvm_params(
+    struct xc_interface_core *xch, libxl_dominfo *info,
+    struct system_pages *pgs)
+{
+    int ret;
+    domid_t domid = info->domid;
+
+    ret = xc_hvm_param_get(xch, domid, HVM_PARAM_STORE_EVTCHN,
+                           &pgs->store.evtchn);
+    if (ret != 0) {
+        fprintf(stderr, "err: failed to get dom%d store evtchn\n", domid);
+        return ret;
+    }
+
+    ret = xc_hvm_param_get(xch, domid, HVM_PARAM_STORE_PFN,
+                           &pgs->store.pfn);
+    if (ret < 0) {
+        fprintf(stderr, "err: failed to get dom%d store pfn\n", domid);
+        return ret;
+    }
+
+    if ( pgs->console.enabled )
+    {
+        ret = xc_hvm_param_get(xch, domid, HVM_PARAM_CONSOLE_EVTCHN,
+                              &pgs->console.evtchn);
+        if (ret != 0) {
+            fprintf(stderr, "warn: console for dom%d not configured\n", domid);
+            pgs->console.evtchn = pgs->console.pfn = 0;
+            return 0;
+        }
+
+        ret = xc_hvm_param_get(xch, domid, HVM_PARAM_CONSOLE_PFN,
+                               &pgs->console.pfn);
+        if (ret < 0) {
+            fprintf(stderr, "warn: console for dom%d not configured\n", domid);
+            pgs->console.evtchn = pgs->console.pfn = 0;
+            return 0;
+        }
+    }
+
+    return 0;
+}
+
+static int create_xs_entries(
+    struct xs_handle *xsh, struct system_pages *pgs, libxl_dominfo *di)
+{
+    char path[128], value[16];
+    struct xs_permissions perms[2] = {
+        {.id = pgs->store.be_domid, .perms = XS_PERM_NONE},
+        {.id = di->domid, .perms = XS_PERM_READ},
+    };
+    uint32_t num_perms = (sizeof(perms) / sizeof((perms)[0]));
+    int ret = 0;
+
+    while ( do_xs_start_transaction(xsh) == 0 )
+    {
+        XS_DOM_PERM(xsh, di->domid, "", "");
+
+        snprintf(value, 16, "%d", di->domid);
+        XS_DOM_PERM(xsh, di->domid, "domid", value);
+
+        XS_DOM_PERM(xsh, di->domid, "memory", "");
+        snprintf(value, 16, "%" PRIu64, di->current_memkb);
+        XS_DOM_PERM(xsh, di->domid, "memory/target", value);
+
+        snprintf(value, 16, "%" PRIu64, di->max_memkb);
+        XS_DOM_PERM(xsh, di->domid, "memory/static-max", value);
+
+        XS_DOM_PERM(xsh, di->domid, "store", "");
+        snprintf(value, 16, "%" PRIu64, pgs->store.evtchn);
+        XS_DOM_PERM(xsh, di->domid, "store/port", value);
+
+        snprintf(value, 16, "%" PRIu64, pgs->store.pfn);
+        XS_DOM_PERM(xsh, di->domid, "store/ring-ref", value);
+
+        if ( pgs->console.enabled && pgs->console.evtchn )
+        {
+            char be_path[64], fe_path[64];
+
+            snprintf(fe_path, 64, "/local/domain/%d/console", di->domid);
+            snprintf(be_path, 64, "/local/domain/%d/backend/console/%d/0",
+                     pgs->console.be_domid, di->domid);
+
+            /* Backend entries */
+            XS_DIR_PERM(xsh, be_path, "", "");
+            snprintf(value, 16, "%d", di->domid);
+            XS_DIR_PERM(xsh, be_path, "frontend-id", value);
+            XS_DIR_PERM(xsh, be_path, "frontend", fe_path);
+            XS_DIR_PERM(xsh, be_path, "online", "1");
+            XS_DIR_PERM(xsh, be_path, "protocol", "vt100");
+
+            snprintf(value, 16, "%d", XenbusStateInitialising);
+            XS_DIR_PERM(xsh, be_path, "state", value);
+
+            /* Frontend entries */
+            XS_DOM_PERM(xsh, di->domid, "console", "");
+            snprintf(value, 16, "%d", pgs->console.be_domid);
+            XS_DIR_PERM(xsh, fe_path, "backend", be_path);
+            XS_DIR_PERM(xsh, fe_path, "backend-id", value);
+            XS_DIR_PERM(xsh, fe_path, "limit", "1048576");
+            XS_DIR_PERM(xsh, fe_path, "type", "xenconsoled");
+            XS_DIR_PERM(xsh, fe_path, "output", "pty");
+            XS_DIR_PERM(xsh, fe_path, "tty", "");
+
+            snprintf(value, 16, "%" PRIu64, pgs->console.evtchn);
+            XS_DIR_PERM(xsh, fe_path, "port", value);
+
+            snprintf(value, 16, "%" PRIu64, pgs->console.pfn);
+            XS_DIR_PERM(xsh, fe_path, "ring-ref", value);
+
+        }
+
+        snprintf(path, 128, "/libxl/%u", di->domid);
+        switch ( di->domain_type )
+        {
+        case LIBXL_DOMAIN_TYPE_PV:
+            XS_DIR_PERM(xsh, path, "type", "pv");
+            break;
+        case LIBXL_DOMAIN_TYPE_PVH:
+            XS_DIR_PERM(xsh, path, "type", "pvh");
+            break;
+        case LIBXL_DOMAIN_TYPE_HVM:
+            XS_DIR_PERM(xsh, path, "type", "hvm");
+            break;
+        default:
+            break;
+        }
+
+        ret = do_xs_end_transaction(xsh);
+        switch ( ret )
+        {
+        case 0:
+            break; /* proceed to loop break */
+        case -EAGAIN:
+            continue; /* try again */
+        default:
+            return ret; /* failed */
+        }
+
+        break;
+    }
+
+    return ret;
+}
+
+static bool init_domain(
+    struct xc_interface_core *xch, struct xs_handle *xsh,
+    struct system_pages *pgs, libxl_dominfo *di)
+{
+    xen_pfn_t con_pfn = 0L;
+    /*xc_dom_gnttab_seed will do nothing if front == back */
+    uint32_t con_domid = di->domid;
+    bool is_hvm = (di->domain_type == LIBXL_DOMAIN_TYPE_HVM ||
+                   di->domain_type == LIBXL_DOMAIN_TYPE_PVH);
+    int ret;
+
+    if ( (ret = pages_from_hvm_params(xch, di, pgs)) != 0 )
+    {
+        fprintf(stderr, "error(%d): unable to fetch dom%d system pages\n", ret,
+                di->domid);
+        return false;
+    }
+
+    if ( pgs->console.enabled && pgs->console.evtchn )
+    {
+        con_domid = pgs->console.be_domid;
+        con_pfn = pgs->console.pfn;
+    }
+
+    ret = xc_dom_gnttab_seed(xch, di->domid, is_hvm, con_pfn,
+            pgs->store.pfn, con_domid, pgs->store.be_domid);
+    if ( ret != 0 )
+    {
+        fprintf(stderr, "error (%d) setting up grant tables for dom%d\n",
+                ret, di->domid);
+        return false;
+    }
+
+    libxl_uuid_generate(&di->uuid);
+    xc_domain_sethandle(xch, di->domid,
+                        libxl_uuid_bytearray(&di->uuid));
+
+    if ( (ret = gen_stub_json_config(di->domid, &di->uuid)) != 0 )
+        fprintf(stderr, "warn(%d): unable generate dom%d json stub\n", ret,
+                di->domid);
+
+    if ( (ret = create_xs_entries(xsh, pgs, di)) != 0 )
+    {
+        fprintf(stderr, "error(%d): unable create dom%d xenstore entries\n",
+                ret, di->domid);
+        return false;
+    }
+
+    if ( !xs_introduce_domain(xsh, di->domid, pgs->store.pfn,
+                              pgs->store.evtchn) )
+    {
+        fprintf(stderr, "error introducing dom%d\n", di->domid);
+        return false;
+    }
+
+    return true;
+}
+
+int main(int argc, char** argv)
+{
+    int opt, ret, i, nb_vm = 0, count = 0;
+    bool force = false;
+    struct xs_handle *xsh = NULL;
+    struct xc_interface_core *xch = NULL;
+    xentoollog_level minmsglevel = XTL_PROGRESS;
+    xentoollog_logger *logger = NULL;
+    libxl_dominfo *info = NULL;
+    libxl_ctx *ctx;
+    struct system_pages pages = { {0} };
+
+    while ( (opt = getopt_long(argc, argv, "c:x:fv", options, NULL)) != -1 )
+    {
+        switch ( opt )
+        {
+        case 'c':
+            pages.console.be_domid = strtol(optarg, NULL, 10);
+            pages.console.enabled = true;
+            break;
+        case 'x':
+            pages.store.be_domid = strtol(optarg, NULL, 10);
+            break;
+        case 'f':
+            force = true;
+            break;
+        case 'v':
+            if ( minmsglevel > 1 )
+                minmsglevel--;
+            break;
+        case 'h':
+            usage();
+            return 0;
+        default:
+            usage();
+            return 2;
+        }
+    }
+
+    if ( optind != argc )
+    {
+        usage();
+        return 1;
+    }
+
+    logger = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr,
+                                                               minmsglevel, 0);
+
+    xsh = xs_open(0);
+    xch = xc_interface_open(0, 0, 0);
+    if ( xsh == NULL || xch == NULL )
+    {
+        fprintf(stderr, "error: unable to connect to xs and/or xc interface\n");
+        ret = 1;
+        goto out;
+    }
+
+    ret = libxl_ctx_alloc(&ctx, LIBXL_VERSION, 0, NULL);
+    if (ret) {
+        fprintf(stderr, "cannot init xl context\n");
+        goto out;
+    }
+
+    info = libxl_list_domain(ctx, &nb_vm);
+    if (!info) {
+        fprintf(stderr, "libxl_list_vm failed.\n");
+        ret = 1;
+        goto out;
+    }
+
+    for (i = 0; i < nb_vm; i++) {
+        domid_t domid = info[i].domid;
+
+        /* Don't need to check for Dom0 */
+        if (!domid)
+            continue;
+
+        if ( xs_is_domain_introduced(xsh, domid) )
+        {
+            if ( !force )
+                continue;
+
+            fprintf(stderr, "warning: re-introducting domain %d\n", domid);
+        }
+
+        if ( init_domain(xch, xsh, &pages, &info[i]) )
+            count++;
+    }
+
+    printf("initialized %d out of %d domains\n", count, nb_vm);
+
+    ret = 0;
+
+out:
+    if ( info )
+        libxl_dominfo_list_free(info, nb_vm);
+
+    if ( xsh )
+        xs_close(xsh);
+
+    if ( xch )
+        xc_interface_close(xch);
+
+    if ( logger )
+        xtl_logger_destroy(logger);
+
+    return ret;
+}
diff --git a/tools/helpers/late-init-domains.h b/tools/helpers/late-init-domains.h
new file mode 100644
index 000000000000..8d071ef82ea0
--- /dev/null
+++ b/tools/helpers/late-init-domains.h
@@ -0,0 +1,18 @@
+#ifndef __LATE_INIT_PV_H
+#define __LATE_INIT_PV_H
+
+struct system_pages {
+    struct {
+        uint16_t be_domid;
+        uint64_t evtchn;
+        uint64_t pfn;
+    } store;
+    struct {
+        bool enabled;
+        uint16_t be_domid;
+        uint64_t evtchn;
+        uint64_t pfn;
+    } console;
+};
+
+#endif
diff --git a/tools/helpers/xs-helpers.c b/tools/helpers/xs-helpers.c
new file mode 100644
index 000000000000..a4d2bebbbd54
--- /dev/null
+++ b/tools/helpers/xs-helpers.c
@@ -0,0 +1,117 @@
+
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_XS_PAATH 100
+
+static xs_transaction_t t_id = XBT_NULL;
+
+int do_xs_start_transaction(struct xs_handle *xsh)
+{
+    t_id = xs_transaction_start(xsh);
+    if (t_id == XBT_NULL)
+        return -errno;
+
+    return 0;
+}
+
+int do_xs_end_transaction(struct xs_handle *xsh)
+{
+    if ( t_id == XBT_NULL )
+        return -EINVAL;
+
+    if (!xs_transaction_end(xsh, t_id, false))
+        return -errno;
+
+    return 0;
+}
+
+int do_xs_write(struct xs_handle *xsh, char *path, char *val)
+{
+    if ( !xs_write(xsh, t_id, path, val, strlen(val)) )
+    {
+        fprintf(stderr, "failed write: %s\n", path);
+        return -errno;
+    }
+
+    return 0;
+}
+
+int do_xs_perms(
+    struct xs_handle *xsh, char *path, struct xs_permissions *perms,
+    uint32_t num_perms)
+{
+    if ( !xs_set_permissions(xsh, t_id, path, perms, num_perms) )
+    {
+        fprintf(stderr, "failed set perm: %s\n", path);
+        return -errno;
+    }
+
+    return 0;
+}
+
+int do_xs_write_dir_node_with_perm(
+    struct xs_handle *xsh, char *dir, char *node, char *val,
+    struct xs_permissions *perms, uint32_t num_perms)
+{
+    char full_path[MAX_XS_PAATH];
+    int ret = 0;
+
+    /*
+     * mainly for creating a value holding node, but
+     * also support creating directory nodes.
+     */
+    if ( strlen(node) != 0 )
+        snprintf(full_path, MAX_XS_PAATH, "%s/%s", dir, node);
+    else
+        snprintf(full_path, MAX_XS_PAATH, "%s", dir);
+
+    ret = do_xs_write(xsh, full_path, val);
+    if ( ret < 0 )
+        return ret;
+
+    if ( perms != NULL && num_perms > 0 )
+        ret = do_xs_perms(xsh, full_path, perms, num_perms);
+
+    return ret;
+}
+
+int do_xs_write_dir_node(
+    struct xs_handle *xsh, char *dir, char *node, char *val)
+{
+    return do_xs_write_dir_node_with_perm(xsh, dir, node, val, NULL, 0);
+}
+
+int do_xs_write_dom_with_perm(
+    struct xs_handle *xsh, uint32_t domid, char *path, char *val,
+    struct xs_permissions *perms, uint32_t num_perms)
+{
+    char full_path[MAX_XS_PAATH];
+    int ret = 0;
+
+    /*
+     * mainly for creating a value holding node, but
+     * also support creating directory nodes.
+     */
+    if ( strlen(path) != 0 )
+        snprintf(full_path, MAX_XS_PAATH, "/local/domain/%d/%s", domid, path);
+    else
+        snprintf(full_path, MAX_XS_PAATH, "/local/domain/%d", domid);
+
+    ret = do_xs_write(xsh, full_path, val);
+    if ( ret < 0 )
+        return ret;
+
+    if ( perms != NULL && num_perms > 0 )
+        ret = do_xs_perms(xsh, full_path, perms, num_perms);
+
+    return ret;
+}
+
+int do_xs_write_dom(
+    struct xs_handle *xsh, uint32_t domid, char *path, char *val)
+{
+    return do_xs_write_dom_with_perm(xsh, domid, path, val, NULL, 0);
+}
diff --git a/tools/helpers/xs-helpers.h b/tools/helpers/xs-helpers.h
new file mode 100644
index 000000000000..89585637d4bb
--- /dev/null
+++ b/tools/helpers/xs-helpers.h
@@ -0,0 +1,26 @@
+#ifndef __XS_HELPERS_H
+#define __XS_HELPERS_H
+
+#include 
+
+int do_xs_start_transaction(struct xs_handle *xsh);
+int do_xs_end_transaction(struct xs_handle *xsh);
+
+int do_xs_write(struct xs_handle *xsh, char *path, char *val);
+int do_xs_perms(
+    struct xs_handle *xsh, char *path, struct xs_permissions *perms,
+    uint32_t num_perms);
+
+int do_xs_write_dir_node_with_perm(
+    struct xs_handle *xsh, char *dir, char *node, char *val,
+    struct xs_permissions *perms, uint32_t num_perms);
+int do_xs_write_dir_node(
+    struct xs_handle *xsh, char *dir, char *node, char *val);
+
+int do_xs_write_dom_with_perm(
+    struct xs_handle *xsh, uint32_t domid, char *path, char *val,
+    struct xs_permissions *perms, uint32_t num_perms);
+int do_xs_write_dom(
+    struct xs_handle *xsh, uint32_t domid, char *path, char *val);
+
+#endif
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:30:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:30:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985454.1371418 (Exim 4.92)
	(envelope-from )
	id 1uFYfj-0005zo-8O; Thu, 15 May 2025 13:30:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985454.1371418; Thu, 15 May 2025 13:30:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFYfj-0005zd-2j; Thu, 15 May 2025 13:30:51 +0000
Received: by outflank-mailman (input) for mailman id 985454;
 Thu, 15 May 2025 13:30:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYWm-0006hT-1V
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:21:36 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 83af8a54-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:21:32 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315169742869.1914971672236;
 Thu, 15 May 2025 06:19: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" 
X-Inumbo-ID: 83af8a54-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315172; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=gySeR3xZdn/C2DTKC2yYnEj5AVglZjEUXelTvjQOqA9A5yjCxO/dYeTFioVJvzRKfvvxmEtyxh7JkNCkym7SWRsgulO3XjTdfa79r4TSKCJNpEanGDmJOU0XSpy9j0MgrHRx60c5R6BhswxiHErd3sskSQRyCX5kyNhAX2Y/R44=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315172; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=lPwQqu2YZX/b272zm9ZL/KuLa6EJ8BsjBWcWBspQd9I=; 
	b=MUerFAvA5M6VUeaEJ2MXN+cvS9LvRYOCsLqTCqvyYsnDCpECYIkMlDzQ9g5R3Og+7wCarHf8ehiEcJc2J659KTd0KopRIo28QcLzTapkOSEmVNL6NWHya7QJ/kfx21rGiY6TZV6p8fOQB7cLtsSL2Bglwvql8CZ1v5AB5dxXFgM=
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=1747315172;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=lPwQqu2YZX/b272zm9ZL/KuLa6EJ8BsjBWcWBspQd9I=;
	b=E0iyFxofJ6jyi/+Jw6y0QWOBsGMnpxi1Tns2UcXFteDeuFpiCF4EOfg9jRrJnjjc
	zqPW+FrdH4U2r1DYujq4p+yQ8XSbuXEZEu4TptigeThFyDY4+8Opk5ZEE9k6IwzdXZ8
	zftuJ+1WNvNjbKs1HSP3wFSRJTtA3eE2foEu0pag=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 23/38] x86/boot: export command line processing
Date: Thu, 15 May 2025 09:19:06 -0400
Message-Id: <20250515131912.5019-4-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131912.5019-1-dpsmith@apertussolutions.com>
References: <20250515131912.5019-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Export the function cmdline_cook() so that it can be called outside of setup.c.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/include/asm/setup.h | 2 ++
 xen/arch/x86/setup.c             | 4 +---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index b517da6144de..4b8fbdc67e05 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -29,6 +29,8 @@ void init_IRQ(void);
 struct boot_domain;
 int construct_dom0(struct boot_domain *bd);
 
+const char *cmdline_cook(const char *p, const char *loader_name);
+
 void setup_io_bitmap(struct domain *d);
 
 extern struct boot_info xen_boot_info;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 298e27848dda..b03284428bb3 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -293,8 +293,6 @@ static int __init cf_check parse_acpi_param(const char *s)
 }
 custom_param("acpi", parse_acpi_param);
 
-static const char *cmdline_cook(const char *p, const char *loader_name);
-
 struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
@@ -952,7 +950,7 @@ static bool __init loader_is_grub2(const char *loader_name)
  *
  * Always returns a pointer within @p.
  */
-static const char *__init cmdline_cook(const char *p, const char *loader_name)
+const char *__init cmdline_cook(const char *p, const char *loader_name)
 {
     /* Strip leading whitespace. */
     while ( *p == ' ' )
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:31:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:31:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985472.1371428 (Exim 4.92)
	(envelope-from )
	id 1uFYgK-0006on-F1; Thu, 15 May 2025 13:31:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985472.1371428; Thu, 15 May 2025 13:31:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFYgK-0006og-AU; Thu, 15 May 2025 13:31:28 +0000
Received: by outflank-mailman (input) for mailman id 985472;
 Thu, 15 May 2025 13:31:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYVz-0001J6-Dt
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:20:47 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6874c8f3-318f-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 15:20:46 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315102766617.7586421581187;
 Thu, 15 May 2025 06:18: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" 
X-Inumbo-ID: 6874c8f3-318f-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; t=1747315107; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=V62vozW4fixzn4GmMXPxn8QV5qJOjO6ZwgDWgZvDU8uei34mLHFqYc64BfV06ecCliHwTbcfv/OugmzthwbnOwb1Ve74kBd8mU3z2mM/fVcCvp9krxq8YkJReVC1j3guYXCPM/OjOX22GmAOTmc2b2/BWWLCYxlLuQdqAl9tyvw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315107; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=P3H/9i2KknvPDFh0EQzL+jlxmzJaWhM9u6fW8uCKxIU=; 
	b=MOHzUXcjnZfXTX5Cz9rUqE51TqVhlUuIXi6Ven7MrQPd22mRuAEPI0uv4aF/5lOsVPOCFSgqyrxjqppdRH/TNYkW/HVkSXTYSsX1nIzDzBVMVsS2DNi34Q415o9D2Ezp9/RzCbL/D9FkrVzm9RKwzaIpEPw6RNH6t34dhdv9u6k=
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=1747315106;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=P3H/9i2KknvPDFh0EQzL+jlxmzJaWhM9u6fW8uCKxIU=;
	b=oQFn78u8Kzs/c1IQAdJZwu+cT4wVjUKekT3PdUmbofD1lwL8gadrsKL55XuvqDuj
	aYAj1uOKOwDryc3Asz88hgDIFiGocOC2DYe267BqTGkCJv66Hm+tvXZiuHNREBnK8wI
	Eqa1f8tHYFr6d4ZbgbOQfy0/Ss8ZQtNZewadgnC8=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 17/38] x86/boot: rename pvh acpi setup function
Date: Thu, 15 May 2025 09:17:23 -0400
Message-Id: <20250515131744.3843-18-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The function pvh_setup_acpi() is dom0 specific, renaming it to
dom0_pvh_setup_acpi(). Now export the function so that it may be called by the
domain builder.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/hvm/dom0_build.c         | 4 ++--
 xen/arch/x86/include/asm/dom0_build.h | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 7b9a2cccabce..9ea8acbb5a02 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -1125,7 +1125,7 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, paddr_t madt_addr,
     return rc;
 }
 
-static int __init pvh_setup_acpi(struct domain *d, paddr_t start_info)
+int __init dom0_pvh_setup_acpi(struct domain *d, paddr_t start_info)
 {
     unsigned long pfn, nr_pages;
     paddr_t madt_paddr, xsdt_paddr, rsdp_paddr;
@@ -1283,7 +1283,7 @@ int __init dom0_construct_pvh(struct boot_domain *bd)
         return rc;
     }
 
-    rc = pvh_setup_acpi(d, start_info);
+    rc = dom0_pvh_setup_acpi(bd->d, start_info);
     if ( rc )
     {
         printk("Failed to setup Dom0 ACPI tables: %d\n", rc);
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index e5debd5adf9f..36f563bd9d5b 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -20,6 +20,8 @@ void dom0_pv_restrict_pages(
 
 void dom0_pvh_setup_e820(struct domain *d, unsigned long nr_pages);
 
+int dom0_pvh_setup_acpi(struct domain *d, paddr_t start_info);
+
 int dom0_construct_pv(struct boot_domain *bd);
 int dom0_construct_pvh(struct boot_domain *bd);
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:31:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:31:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985474.1371437 (Exim 4.92)
	(envelope-from )
	id 1uFYgZ-0007D7-L0; Thu, 15 May 2025 13:31:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985474.1371437; Thu, 15 May 2025 13:31: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 1uFYgZ-0007Cy-I5; Thu, 15 May 2025 13:31:43 +0000
Received: by outflank-mailman (input) for mailman id 985474;
 Thu, 15 May 2025 13:31:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYWS-0006hT-1g
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:21:16 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78f53c52-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:21:14 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 174731516815094.66533661486642;
 Thu, 15 May 2025 06:19: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" 
X-Inumbo-ID: 78f53c52-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315170; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=ehnRpR6rvHOWR2yDbSP0FkXCojYi4YLEf1XuSItEKSHxne4YeuaOpVp6Iib24woqulTmoQKUtF5ykJcNfkmUyjLB352PntOY3Evdu7aT6GDXVCCdKnDTEM+vj4Nw0JYCE7YMqyYY2ZNJ7ZxkpwKhQOc0dUsEQmc8rr57MRyIVmo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315170; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=vOIQ5k3ttEx9/mkvbELUIg9KG/lF3PK9LAheb8twtJc=; 
	b=BIMhkGTxC8t2othyEGncHHfh7SH9KVgc0tzQu7CLJVKSVTXmYtDE/gSbMRuZ/+5jQAKrcpZ18qR90emtgNUQWyCZke3HaH+EBu2rfhNvzyDZ9LSSclakiwdvlJjwaCqrfKWqpydnH1K73NQG8TkwLic7054xbv8RIUQZRWh1oJU=
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=1747315170;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=vOIQ5k3ttEx9/mkvbELUIg9KG/lF3PK9LAheb8twtJc=;
	b=AaBXl1SjiEoaEhQLgZuORnwigZtXI+WwWh3AcqqKyLFqo5hcIqOjslp2SRgKpQDR
	2E2raoG+XUrLhxDhyCjqkKCpCMRclIDiNaRosPZpklHDJhJxwuXgYeAuLE+im81o4LQ
	rJX5HbmDSltcdC6d33gU0ja/1JAcdwmNEI3GXrfk=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 21/38] x86/hyperlaunch: relocate pvh_steal_ram to domain builder
Date: Thu, 15 May 2025 09:19:04 -0400
Message-Id: <20250515131912.5019-2-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131912.5019-1-dpsmith@apertussolutions.com>
References: <20250515131912.5019-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The function pvh_steal_ram() is not pvh specific and can be used on any HVM
domain. Move to the domain builder and rename to hvm_steal_ram.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/hvm/dom0_build.c             | 106 +++-------------------
 xen/arch/x86/hvm/dom_build.c              |  84 +++++++++++++++++
 xen/arch/x86/include/asm/domain-builder.h |   7 ++
 3 files changed, 102 insertions(+), 95 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index ffe198d94d9e..d379383d3096 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -183,90 +183,6 @@ int __init pvh_populate_memory_range(
     return 0;
 }
 
-/* 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,
-                                paddr_t *addr)
-{
-    unsigned int i = d->arch.nr_e820;
-
-    /*
-     * Alignment 0 should be set to 1, so it doesn't wrap around in the
-     * calculations below.
-     */
-    align = align ? : 1;
-    while ( i-- )
-    {
-        struct e820entry *entry = &d->arch.e820[i];
-
-        if ( entry->type != E820_RAM || entry->addr + entry->size > limit )
-            continue;
-
-        *addr = (entry->addr + entry->size - size) & ~(align - 1);
-        if ( *addr < entry->addr ||
-             /* Don't steal from the low 1MB due to the copying done there. */
-             *addr < MB(1) )
-            continue;
-
-        entry->size = *addr - entry->addr;
-        return 0;
-    }
-
-    return -ENOMEM;
-}
-
-/* NB: memory map must be sorted at all times for this to work correctly. */
-static int __init pvh_add_mem_range(struct domain *d, uint64_t s, uint64_t e,
-                                    unsigned int type)
-{
-    struct e820entry *map;
-    unsigned int i;
-
-    for ( i = 0; i < d->arch.nr_e820; i++ )
-    {
-        uint64_t rs = d->arch.e820[i].addr;
-        uint64_t re = rs + d->arch.e820[i].size;
-
-        if ( rs == e && d->arch.e820[i].type == type )
-        {
-            d->arch.e820[i].addr = s;
-            return 0;
-        }
-
-        if ( re == s && d->arch.e820[i].type == type &&
-             (i + 1 == d->arch.nr_e820 || d->arch.e820[i + 1].addr >= e) )
-        {
-            d->arch.e820[i].size += e - s;
-            return 0;
-        }
-
-        if ( rs >= e )
-            break;
-
-        if ( re > s )
-            return -EEXIST;
-    }
-
-    map = xzalloc_array(struct e820entry, d->arch.nr_e820 + 1);
-    if ( !map )
-    {
-        printk(XENLOG_WARNING "E820: out of memory to add region\n");
-        return -ENOMEM;
-    }
-
-    memcpy(map, d->arch.e820, i * sizeof(*d->arch.e820));
-    memcpy(map + i + 1, d->arch.e820 + i,
-           (d->arch.nr_e820 - i) * sizeof(*d->arch.e820));
-    map[i].addr = s;
-    map[i].size = e - s;
-    map[i].type = type;
-    xfree(d->arch.e820);
-    d->arch.e820 = map;
-    d->arch.nr_e820++;
-
-    return 0;
-}
-
 static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
 {
     uint32_t rc, *ident_pt;
@@ -280,14 +196,14 @@ static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
      * 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_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;
-        if ( pvh_add_mem_range(d, gaddr, gaddr + HVM_VM86_TSS_SIZE,
+        if ( hvm_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");
     }
@@ -295,7 +211,7 @@ static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
         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 ( hvm_steal_ram(d, PAGE_SIZE, PAGE_SIZE, GB(4), &gaddr) )
     {
         printk("Unable to find memory to stash the identity page tables\n");
         return -ENOMEM;
@@ -317,7 +233,7 @@ static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
     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) )
+    if ( hvm_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;
@@ -582,7 +498,7 @@ static int __init pvh_setup_acpi_madt(struct domain *d, paddr_t *addr)
     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) )
+    if ( hvm_steal_ram(d, size, 0, GB(4), addr) )
     {
         printk("Unable to steal guest RAM for MADT\n");
         rc = -ENOMEM;
@@ -590,7 +506,7 @@ static int __init pvh_setup_acpi_madt(struct domain *d, paddr_t *addr)
     }
 
     /* Mark this region as E820_ACPI. */
-    if ( pvh_add_mem_range(d, *addr, *addr + size, E820_ACPI) )
+    if ( hvm_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]);
@@ -770,7 +686,7 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, paddr_t madt_addr,
     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) )
+    if ( hvm_steal_ram(d, size, 0, GB(4), addr) )
     {
         printk("Unable to find guest RAM for XSDT\n");
         rc = -ENOMEM;
@@ -778,7 +694,7 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, paddr_t madt_addr,
     }
 
     /* Mark this region as E820_ACPI. */
-    if ( pvh_add_mem_range(d, *addr, *addr + size, E820_ACPI) )
+    if ( hvm_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]);
@@ -824,7 +740,7 @@ int __init dom0_pvh_setup_acpi(struct domain *d, paddr_t start_info)
         if ( strncmp(sig, ACPI_SIG_MADT, ACPI_NAME_SIZE)
              ? pvh_acpi_table_allowed(sig, addr, size)
              : !acpi_memory_banned(addr, size) )
-             pvh_add_mem_range(d, addr, addr + size, E820_ACPI);
+             hvm_add_mem_range(d, addr, addr + size, E820_ACPI);
     }
 
     /* Identity map ACPI e820 regions. */
@@ -893,14 +809,14 @@ int __init dom0_pvh_setup_acpi(struct domain *d, paddr_t start_info)
      * 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) )
+    if ( hvm_steal_ram(d, sizeof(rsdp), 0, GB(4), &rsdp_paddr) )
     {
         printk("Unable to allocate guest RAM for RSDP\n");
         return -ENOMEM;
     }
 
     /* Mark this region as E820_ACPI. */
-    if ( pvh_add_mem_range(d, rsdp_paddr, rsdp_paddr + sizeof(rsdp),
+    if ( hvm_add_mem_range(d, rsdp_paddr, rsdp_paddr + sizeof(rsdp),
                            E820_ACPI) )
         printk("Unable to add RSDP region to memory map\n");
 
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index bf361ba3f3f6..2157340335d2 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -279,6 +279,38 @@ static int __init hvm_populate_p2m(struct domain *d)
     return 0;
 }
 
+/* Steal RAM from the end of a memory region. */
+int __init hvm_steal_ram(
+    struct domain *d, unsigned long size, unsigned long align, paddr_t limit,
+    paddr_t *addr)
+{
+    unsigned int i = d->arch.nr_e820;
+
+    /*
+     * Alignment 0 should be set to 1, so it doesn't wrap around in the
+     * calculations below.
+     */
+    align = align ? : 1;
+    while ( i-- )
+    {
+        struct e820entry *entry = &d->arch.e820[i];
+
+        if ( entry->type != E820_RAM || entry->addr + entry->size > limit )
+            continue;
+
+        *addr = (entry->addr + entry->size - size) & ~(align - 1);
+        if ( *addr < entry->addr ||
+             /* Don't steal from the low 1MB due to the copying done there. */
+             *addr < MB(1) )
+            continue;
+
+        entry->size = *addr - entry->addr;
+        return 0;
+    }
+
+    return -ENOMEM;
+}
+
 static paddr_t __init find_memory(
     const struct domain *d, const struct elf_binary *elf, size_t size)
 {
@@ -325,6 +357,58 @@ static paddr_t __init find_memory(
     return INVALID_PADDR;
 }
 
+/* NB: memory map must be sorted at all times for this to work correctly. */
+int __init hvm_add_mem_range(
+    struct domain *d, uint64_t s, uint64_t e, unsigned int type)
+{
+    struct e820entry *map;
+    unsigned int i;
+
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        uint64_t rs = d->arch.e820[i].addr;
+        uint64_t re = rs + d->arch.e820[i].size;
+
+        if ( rs == e && d->arch.e820[i].type == type )
+        {
+            d->arch.e820[i].addr = s;
+            return 0;
+        }
+
+        if ( re == s && d->arch.e820[i].type == type &&
+             (i + 1 == d->arch.nr_e820 || d->arch.e820[i + 1].addr >= e) )
+        {
+            d->arch.e820[i].size += e - s;
+            return 0;
+        }
+
+        if ( rs >= e )
+            break;
+
+        if ( re > s )
+            return -EEXIST;
+    }
+
+    map = xzalloc_array(struct e820entry, d->arch.nr_e820 + 1);
+    if ( !map )
+    {
+        printk(XENLOG_WARNING "E820: out of memory to add region\n");
+        return -ENOMEM;
+    }
+
+    memcpy(map, d->arch.e820, i * sizeof(*d->arch.e820));
+    memcpy(map + i + 1, d->arch.e820 + i,
+           (d->arch.nr_e820 - i) * sizeof(*d->arch.e820));
+    map[i].addr = s;
+    map[i].size = e - s;
+    map[i].type = type;
+    xfree(d->arch.e820);
+    d->arch.e820 = map;
+    d->arch.nr_e820++;
+
+    return 0;
+}
+
 static bool __init check_load_address(
     const struct domain *d, const struct elf_binary *elf)
 {
diff --git a/xen/arch/x86/include/asm/domain-builder.h b/xen/arch/x86/include/asm/domain-builder.h
index 2de73117cb7f..15a0e3b12c02 100644
--- a/xen/arch/x86/include/asm/domain-builder.h
+++ b/xen/arch/x86/include/asm/domain-builder.h
@@ -4,10 +4,17 @@
 struct boot_domain;
 struct elf_dom_parms;
 
+int hvm_add_mem_range(
+    struct domain *d, uint64_t s, uint64_t e, unsigned int type);
+
 int hvm_setup_cpus(struct domain *d, paddr_t entry, paddr_t start_info);
 int pvh_populate_memory_range(
     struct domain *d, unsigned long start, unsigned long nr_pages);
 
+int hvm_steal_ram(
+    struct domain *d, unsigned long size, unsigned long align, paddr_t limit,
+    paddr_t *addr);
+
 unsigned long dom_paging_pages(
     const struct boot_domain *d, unsigned long nr_pages);
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:33:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:33:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985494.1371447 (Exim 4.92)
	(envelope-from )
	id 1uFYhv-0008Aj-VW; Thu, 15 May 2025 13:33:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985494.1371447; Thu, 15 May 2025 13:33: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 1uFYhv-0008Ac-SX; Thu, 15 May 2025 13:33:07 +0000
Received: by outflank-mailman (input) for mailman id 985494;
 Thu, 15 May 2025 13:33:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYXy-0006hT-1k
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:22:50 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b0ef87a9-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:22:48 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315203898774.28914981641;
 Thu, 15 May 2025 06:20: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" 
X-Inumbo-ID: b0ef87a9-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315206; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=d+cKlHslB97Fgzmkuw8WVae7Gg0J20oOIGKDvPqOUaw9s4iah9L52ZwOsIcUwLnX8HED62SK6MspQ1kIqt2AMZ0QOx0v7ICnD6cLa8xpejfFA0JcRUnkJ/ZvpAbbdcOCDk95niqj1ZKNWT2pPHmAQEbECtmUSCssxWYG+Cmc3Iw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315206; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=WDa/Mkj3Tjniuh016pru5/pfbd3GRCwENfg6jnawTYA=; 
	b=dEi1MSi66N0PSmn3KTiyv6qzJVY8RtkBZhUVDGknlPUi+DFz5r6RsYA7cHeMZbWulAcZg2qrfuRcKhAt1hVwVYFu8O2gLuROtBmY7Cy+wzJLaeqyyc1YyDpHbBrw4xHKuTXU9v+VQn1x3+WuS+oxSbY1Mysu2Nxiq7JAgs25cVE=
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=1747315206;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=WDa/Mkj3Tjniuh016pru5/pfbd3GRCwENfg6jnawTYA=;
	b=SMJPI1sNgt0DPze3WNar++exrUJ8OEoGESbyIwBnGs3UbhTR60z8wBl5svugpywh
	cuZQ3fvB+jScFo9SY0RFkmhKaSgzNaHVOTQX9cYDClDyCOTMA4XpwD+g/4QSP3JWo+E
	HbQt4o8yHwaLmIjbcfXHp4ouD/dtx7CU84s9+4Go=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 30/38] x86/hyperlaunch: introduce concept of core domains
Date: Thu, 15 May 2025 09:19:42 -0400
Message-Id: <20250515131951.5594-1-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

When constructing a disaggregated Xen system, there are certain domains with
particular capabilities that must be present and running at start-of-day. The
hardware domain is absolutely required, while a xenstore domain is mostly
required.

The function build_core_domains is introduced to encapsulate the construction
of the core domains.

Signed-off-by: Daniel P. Smith 

---

Changes in RFCv2:
- rewrote build_core_domains due address the reordering event channel creation
---
 xen/arch/x86/domain-builder/core.c     | 66 +++++++++++++++++++++++---
 xen/arch/x86/include/asm/boot-domain.h |  2 +
 2 files changed, 61 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/domain-builder/core.c b/xen/arch/x86/domain-builder/core.c
index 4eaf3a111208..af79792b5316 100644
--- a/xen/arch/x86/domain-builder/core.c
+++ b/xen/arch/x86/domain-builder/core.c
@@ -3,24 +3,76 @@
  * Copyright (C) 2025, Apertus Solutions, LLC
  */
 
+#include 
 #include 
 #include 
 #include 
 
 #include 
+#include 
+
+static int  __init build_core_domains(struct boot_info *bi)
+{
+    int count = 0;
+    struct boot_domain *bd;
+    int hw, xs;
+
+    hw = first_boot_domain_index(bi, DOMAIN_CAPS_HARDWARE);
+    if ( hw > MAX_NR_BOOTDOMS )
+        panic("%s: hardware domain missing\n", __func__);
+    else
+    {
+        bd = &bi->domains[hw];
+
+        arch_create_dom(bi, bd);
+        if ( bd->d )
+        {
+            bd->constructed = true;
+            count++;
+        }
+    }
+
+    xs = first_boot_domain_index(bi, DOMAIN_CAPS_XENSTORE);
+    if ( xs > MAX_NR_BOOTDOMS )
+        printk(XENLOG_WARNING "No xenstore domain was defined\n");
+    else
+    {
+        if ( !bi->domains[xs].constructed )
+        {
+            bd = &bi->domains[xs];
+
+            arch_create_dom(bi, bd);
+            if ( bd->d )
+            {
+                bd->constructed = true;
+                count++;
+            }
+        }
+    }
+
+    ASSERT(count <= bi->nr_domains);
+
+    return count;
+}
 
 unsigned int __init builder_create_domains(struct boot_info *bi)
 {
     unsigned int build_count = 0;
-    struct boot_domain *bd = &bi->domains[0];
-
-    if ( bd->capabilities & DOMAIN_CAPS_HARDWARE && bd->kernel == NULL )
-        panic("%s: hardware domain missing kernel\n", __func__);
 
+    if ( bi->nr_domains == 0 )
+        panic("%s: no domains defined\n", __func__);
 
-    arch_create_dom(bi, bd);
-    if ( bd->d )
-        build_count++;
+    if ( pv_shim )
+    {
+        arch_create_dom(bi, &bi->domains[0]);
+        if ( bi->domains[0].d )
+        {
+            bi->domains[0].constructed = true;
+            build_count++;
+        }
+    }
+    else
+        build_count = build_core_domains(bi);
 
     arch_builder_finalize(bi);
 
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index 66f3a71fd597..41246f31acce 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -36,6 +36,8 @@ struct boot_domain {
     struct domain *d;
 
     xen_pfn_t xs_page, cons_page;
+
+    bool constructed;
 };
 
 static inline bool __init has_dom0_caps(const struct boot_domain *bd)
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:33:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:33:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985499.1371456 (Exim 4.92)
	(envelope-from )
	id 1uFYi6-000051-82; Thu, 15 May 2025 13:33:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985499.1371456; Thu, 15 May 2025 13:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFYi6-0008WV-56; Thu, 15 May 2025 13:33:18 +0000
Received: by outflank-mailman (input) for mailman id 985499;
 Thu, 15 May 2025 13:33:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYXn-0006hT-Mc
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:22:39 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aac4ca46-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:22:37 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 17473151748641009.1612467793848;
 Thu, 15 May 2025 06:19: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" 
X-Inumbo-ID: aac4ca46-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315178; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=RGp/50pqPKu5D8LmRJqPf2A7s3rFWp7UgP0ImR6+IvRugIYxm+NPvatduNRVxqukKK29JdobvQ8L8AoDhKiDLVHW2oSXgAFhh8wrXKAqvw/Tg1+BBmV3FJie4tujAykq67KYPyGJ6wqD1QLjXe0CftILHgNq6TpzoEmMf4D5xdE=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315178; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=6T1Z5XGS9ysURjGTHl7V7vt25/W8+XJnWeYBM57YXlo=; 
	b=g3OuP1e/3kiufNc6opq1dJnYQcLgkhbRIPeqnZCY0gmoVAPN/tmTxitz84B1YHwwnjEx/cQkLT1658jC5VqbhfIDotqXlXLqbKMpJppL0EScpW0NfNgM0M2GXdVBUutQd4drGrfUMKY+16718xMV7D8vwfwcwAeCIDcosrpsnhg=
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=1747315178;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=6T1Z5XGS9ysURjGTHl7V7vt25/W8+XJnWeYBM57YXlo=;
	b=oRn9wqcT5C3pNHULn2uIaxjHgKrgXlDXUo9qLJEo1IzYvprvplwjrfVtBHTTXPYs
	UdqZyMvvyhIrD+RLjK0n7TZBj/eTTQW5uuW2+ggbuU1AOHSnG18UE5n5OaTz72PONNF
	gW7hor+9z9KdQFR1CPoPjIZRK8f2PqLJpKGdbYmc=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 29/38] x86/hyperlaunch: allocate console for domu
Date: Thu, 15 May 2025 09:19:12 -0400
Message-Id: <20250515131912.5019-10-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131912.5019-1-dpsmith@apertussolutions.com>
References: <20250515131912.5019-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

During domU construction, a page of memory and an event channel must be setup
for the console connection. In this commit, a page from the special page region
of domU is setup as the console page along with an event channel. The page
address and event channel are published in the HVM parameters, so they may be
published in Xenstore once it is online.

Signed-off-by: Daniel P. Smith 

---

Changes in RFCv2:
- rewrote inline with xenstore changes for event chan
---
 xen/arch/x86/domain-builder/domain.c   | 24 +++++++++++++++++++++++-
 xen/arch/x86/hvm/dom_build.c           | 24 ++++++++++++++++++++++++
 xen/arch/x86/include/asm/boot-domain.h |  2 +-
 3 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index de0ee0fcd62c..673fc5b16ed3 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -355,7 +355,7 @@ struct domain *__init arch_create_dom(
 int __init arch_builder_finalize(struct boot_info *bi)
 {
     unsigned int i;
-    struct boot_domain *xs_bd = NULL;
+    struct boot_domain *xs_bd = NULL, *hw_bd = NULL;
 
     i = first_boot_domain_index(bi, DOMAIN_CAPS_XENSTORE);
     if ( i > MAX_NR_BOOTDOMS )
@@ -363,6 +363,12 @@ int __init arch_builder_finalize(struct boot_info *bi)
     else
         xs_bd = &bi->domains[i];
 
+    i = first_boot_domain_index(bi, DOMAIN_CAPS_HARDWARE);
+    if ( i > MAX_NR_BOOTDOMS )
+        printk(XENLOG_WARNING "No xenstore domain configured\n");
+    else
+        hw_bd = &bi->domains[i];
+
     for ( i = 0; i < bi->nr_domains; i++ )
     {
         struct boot_domain *bd = &bi->domains[i];
@@ -382,6 +388,22 @@ int __init arch_builder_finalize(struct boot_info *bi)
                 params[HVM_PARAM_STORE_EVTCHN] = xs_evtchn;
             }
         }
+
+        if ( hw_bd && hw_bd->d && (bd != hw_bd) && bd->cons_page )
+        {
+            evtchn_port_t ec = 0;
+
+            if ( alloc_dom_evtchn(bd, hw_bd, &ec) < 0 )
+                continue;
+
+            /* Is HVM/PVH */
+            if ( !(bd->mode & BUILD_MODE_PARAVIRT) )
+            {
+                uint64_t *params = bd->d->arch.hvm.params;
+                params[HVM_PARAM_CONSOLE_PFN] = bd->cons_page;
+                params[HVM_PARAM_CONSOLE_EVTCHN] = ec;
+            }
+        }
     }
 
     /* Free temporary buffers. */
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index aec356cb2e46..3eab97b5288b 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -919,6 +919,27 @@ static int __init alloc_xenstore_page(struct boot_domain *bd)
     return 0;
 }
 
+static int __init alloc_console_page(struct boot_domain *bd)
+{
+    paddr_t con_addr = special_pfn(SPECIALPAGE_CONSOLE) << PAGE_SHIFT;
+    uint32_t fields[4] = { 0 };
+
+    /*
+     * Clear the xencons_interface fields that are located after a 1024 rx and
+     * a 2048 tx buffer, 3072 bytes.
+     */
+    if ( hvm_copy_to_guest_phys(con_addr + 3072, fields, sizeof(fields),
+                                bd->d->vcpu[0]) )
+    {
+        printk("Unable to set xenstore connection state\n");
+        return -EFAULT;
+    }
+
+    bd->cons_page = PFN_DOWN(con_addr);
+
+    return 0;
+}
+
 int __init dom_construct_pvh(struct boot_domain *bd)
 {
     paddr_t entry, start_info;
@@ -998,6 +1019,9 @@ int __init dom_construct_pvh(struct boot_domain *bd)
     if ( !is_xenstore_domain(bd->d) )
         alloc_xenstore_page(bd);
 
+    if ( !is_hardware_domain(bd->d) )
+        alloc_console_page(bd);
+
     if ( opt_dom0_verbose )
     {
         printk("Dom%u memory map:\n", bd->domid);
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index a527342768de..66f3a71fd597 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -35,7 +35,7 @@ struct boot_domain {
 
     struct domain *d;
 
-    xen_pfn_t xs_page;
+    xen_pfn_t xs_page, cons_page;
 };
 
 static inline bool __init has_dom0_caps(const struct boot_domain *bd)
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:33:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:33:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985501.1371468 (Exim 4.92)
	(envelope-from )
	id 1uFYiD-0000Ri-I3; Thu, 15 May 2025 13:33:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985501.1371468; Thu, 15 May 2025 13: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 1uFYiD-0000RZ-Cf; Thu, 15 May 2025 13:33:25 +0000
Received: by outflank-mailman (input) for mailman id 985501;
 Thu, 15 May 2025 13:33:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYWM-0006hT-Qe
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:21:10 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 73edea6f-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:21:05 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315103566363.29787566925177;
 Thu, 15 May 2025 06:18: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" 
X-Inumbo-ID: 73edea6f-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315107; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=h/8SfCi/q6inf5hS1mt/6cSpaKpPtklfhIigIpCmJdfAM0R1cu1ydlGCXunnglVpmEWHuaDrtNBcAu5kR8VVyz6bP9IV0chgaMpntomlHHHv0iKWLnsU3ecFBDg/xoRGbib0JBFtz01cKqN2+2waO0hZvvpv8zdT6OhKVtTde40=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315107; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=+GzD7/fP7kG1xQPJZ8ioOdU2IvSPsjxcOM1xI/p7exg=; 
	b=ZilSYlCY6nCs9JVXVBNBiR4hSMF5/aWy9UexHr+wdd9+KeG0ruIYQwx41UwaRZJhyEuXE1NXgOw4wRaP5J60TxANsR9bzJO1gFtixurn+sM/Jf3m5fyEDfBb76qU3qAQaIyriryVPgWzIF6/hmdNvrn4Rqlbzwx5MPSx8OgQo/g=
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=1747315107;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=+GzD7/fP7kG1xQPJZ8ioOdU2IvSPsjxcOM1xI/p7exg=;
	b=WNEACyy91uOFtNyo/EYzWz7UB/4xQDa/2XHTKi3O6cH6foShp7eonP0EJ35+oJM6
	5D1McVEkmv0SbfMn5/0le7L/OCKKrgGplF5RqIAkgk7sqveZMVodEtCw5iA3lmbuBmo
	lcVqlh21J1L3x94aZWyu17492Li0/mPRZ74vwHto=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 18/38] x86/hyperlaunch: add domu memory map construction
Date: Thu, 15 May 2025 09:17:24 -0400
Message-Id: <20250515131744.3843-19-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131744.3843-1-dpsmith@apertussolutions.com>
References: <20250515131744.3843-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Introduce hvm_setup_e820() that will build the e820 memory map for a general
domU. To populate the ACPI entry, ACPI table size helpers are introduced. A
conditional is added to the domain builder to select between calling
hvm_setup_e820() and dom0_pvh_setup_e820() depending on if it is building dom0
or a domU.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/hvm/dom_build.c | 149 ++++++++++++++++++++++++++++++++++-
 1 file changed, 148 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index c182847147b0..e724d578c5d4 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -17,6 +17,7 @@
 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -44,12 +45,158 @@ static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
     }
 }
 
+static unsigned long __init hvm_size_acpi_madt(struct domain *d)
+{
+    unsigned long size = sizeof(struct acpi_table_madt);
+
+    size += sizeof(struct acpi_madt_local_apic) * d->max_vcpus;
+
+    return size;
+}
+
+static unsigned long __init hvm_size_acpi_xsdt(struct domain *d)
+{
+    unsigned long size = sizeof(struct acpi_table_xsdt);
+    /* Only adding the MADT table to the XSDT. */
+    unsigned int num_tables = 1;
+
+    /*
+     * No need to add or subtract anything because struct acpi_table_xsdt
+     * includes one array slot already.
+     */
+    size += num_tables * sizeof(uint64_t);
+
+    return size;
+}
+
+static unsigned long __init hvm_size_acpi_region(struct domain *d)
+{
+    unsigned long size = sizeof(struct acpi_table_rsdp);
+
+    size += hvm_size_acpi_xsdt(d);
+    size += hvm_size_acpi_madt(d);
+
+    return ROUNDUP(size, PAGE_SIZE);
+}
+
+/* From xenguest lib */
+#define END_SPECIAL_REGION   0xff000U
+#define NR_SPECIAL_PAGES     8
+#define START_SPECIAL_REGION (END_SPECIAL_REGION - NR_SPECIAL_PAGES)
+
+#define SPECIALPAGE_PAGING   0
+#define SPECIALPAGE_ACCESS   1
+#define SPECIALPAGE_SHARING  2
+#define SPECIALPAGE_BUFIOREQ 3
+#define SPECIALPAGE_XENSTORE 4
+#define SPECIALPAGE_IOREQ    5
+#define SPECIALPAGE_IDENT_PT 6
+#define SPECIALPAGE_CONSOLE  7
+#define special_pfn(x)       (START_SPECIAL_REGION + (x))
+
+/*
+ * Allocation scheme, derived from xenlight/xenguest:
+ *
+ *                                  |  <4G MMIO Hole  |
+ * [ Low Mem ][ RDM Mem ][ >1M Mem ][ ACPI ][ Special ][ High Mem ]
+ *
+ */
+static void __init hvm_setup_e820(struct domain *d, unsigned long nr_pages)
+{
+    const uint32_t lowmem_reserved_base = 0x9e000;
+    const uint32_t rdm_base = 0xa0000, rdm_size = 0x60;
+    unsigned long low_pages, ext_pages, mmio_pages, acpi_pages, high_pages = 0;
+    unsigned long max_ext_pages = (HVM_BELOW_4G_MMIO_START - MB(1)) >> PAGE_SHIFT,
+                  page_count = 0;
+    unsigned nr = 0, e820_entries = 5;
+
+    /* low pages: below 1MB */
+    low_pages = lowmem_reserved_base >> PAGE_SHIFT;
+    if ( low_pages > nr_pages )
+        panic("Insufficient memory for HVM/PVH domain (%pd)\n", d);
+
+    acpi_pages = hvm_size_acpi_region(d) >> PAGE_SHIFT;
+    mmio_pages = acpi_pages + NR_SPECIAL_PAGES;
+
+    /* ext pages: from 1MB to mmio hole */
+    ext_pages = nr_pages - (low_pages + mmio_pages);
+    if ( ext_pages > max_ext_pages )
+        ext_pages = max_ext_pages;
+
+    /* high pages: above 4GB */
+    if ( nr_pages > (low_pages + mmio_pages + ext_pages) )
+        high_pages = nr_pages - (low_pages + mmio_pages + ext_pages);
+
+    /* If we should have a highmem range, add one more e820 entry */
+    if ( high_pages )
+        e820_entries++;
+
+    ASSERT(e820_entries < E820MAX);
+
+    d->arch.e820 = xzalloc_array(struct e820entry, e820_entries);
+    if ( !d->arch.e820 )
+        panic("Unable to allocate memory for boot domain e820 map\n");
+
+    /* usable: Low memory */
+    d->arch.e820[nr].addr = 0x000000;
+    d->arch.e820[nr].size = low_pages << PAGE_SHIFT;
+    d->arch.e820[nr].type = E820_RAM;
+    page_count += d->arch.e820[nr].size >> PAGE_SHIFT;
+    nr++;
+
+    /* reserved: lowmem reserved device memory */
+    d->arch.e820[nr].addr = rdm_base;
+    d->arch.e820[nr].size = rdm_size;
+    d->arch.e820[nr].type = E820_RESERVED;
+    nr++;
+
+    /* usable: extended memory from 1MB */
+    d->arch.e820[nr].addr = 0x100000;
+    d->arch.e820[nr].size = ext_pages << PAGE_SHIFT;
+    d->arch.e820[nr].type = E820_RAM;
+    page_count += d->arch.e820[nr].size >> PAGE_SHIFT;
+    nr++;
+
+    /* reserved: ACPI entry, ACPI_INFO_PHYSICAL_ADDRESS */
+    d->arch.e820[nr].addr = 0xFC000000;
+    d->arch.e820[nr].size = acpi_pages << PAGE_SHIFT;
+    d->arch.e820[nr].type = E820_ACPI;
+    page_count += d->arch.e820[nr].size >> PAGE_SHIFT;
+    nr++;
+
+    /* reserved: HVM special pages, X86_HVM_END_SPECIAL_REGION */
+    d->arch.e820[nr].addr = START_SPECIAL_REGION << PAGE_SHIFT;
+    d->arch.e820[nr].size = NR_SPECIAL_PAGES << PAGE_SHIFT;
+    d->arch.e820[nr].type = E820_RESERVED;
+    page_count += d->arch.e820[nr].size >> PAGE_SHIFT;
+    nr++;
+
+    /* usable: highmem */
+    if ( high_pages )
+    {
+        d->arch.e820[nr].addr = 0x100000000;
+        d->arch.e820[nr].size = high_pages << PAGE_SHIFT;
+        d->arch.e820[nr].type = E820_RAM;
+        page_count += d->arch.e820[nr].size >> PAGE_SHIFT;
+        nr++;
+    }
+
+    d->arch.nr_e820 = nr;
+
+    ASSERT(nr == e820_entries);
+    ASSERT(nr_pages == page_count);
+}
+
 static void __init pvh_init_p2m(struct boot_domain *bd)
 {
     unsigned long nr_pages = dom_compute_nr_pages(bd, NULL);
     bool preempted;
 
-    dom0_pvh_setup_e820(bd->d, nr_pages);
+    if ( bd->capabilities & DOMAIN_CAPS_HARDWARE )
+        dom0_pvh_setup_e820(bd->d, nr_pages);
+    else
+        hvm_setup_e820(bd->d, nr_pages);
+
     do {
         preempted = false;
         paging_set_allocation(bd->d, dom_paging_pages(bd, nr_pages),
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:33:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:33:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985517.1371477 (Exim 4.92)
	(envelope-from )
	id 1uFYiY-0001Bg-Ny; Thu, 15 May 2025 13:33:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985517.1371477; Thu, 15 May 2025 13:33: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 1uFYiY-0001BZ-Kp; Thu, 15 May 2025 13:33:46 +0000
Received: by outflank-mailman (input) for mailman id 985517;
 Thu, 15 May 2025 13:33:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYYg-0006hT-QA
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:23:34 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cbd39df7-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:23:33 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 174731520773082.3377972809584;
 Thu, 15 May 2025 06:20:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: cbd39df7-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315210; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=nR7df+HcgBiLj27QZVJKsv+MjKGQBvRdHKlomAHuYqg4vmXdw0q9PLEQN/criklGSUKQA+gR0KQ3+8VoTL6EFyzNyjM9QZeOa0NmPleaULKYIIB5pxPdrGcCQ189nv5L/z7BHz1p/8QqlZIkn1wx0v+O54491o9OrIWMWwrA8i0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315210; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=70vSR3+LOWhc2kZFcDiKYHYh5u4bPgYcG0obDnNvaLQ=; 
	b=jY6pw3b2JWwl4hDQqxq0/SUfx8WrG5vEN23bB+B8yMOmDUdQ71xXTg0vA4kr24sTfSAhXJujV7FBFRjnUrT62JIYuwxCtTvfXru31GrDrt9f97niA/s1n06yCe2oU+wYX6VJtnZ1NRiBoDs7SgGIkrG66Tj8LICV9wuzZNtMVTk=
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=1747315210;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=70vSR3+LOWhc2kZFcDiKYHYh5u4bPgYcG0obDnNvaLQ=;
	b=TH5AJREHDt+6JxG/AnYRVJ+6W5ANoArKpRYS3EhUXbctyYtlSI6k9WEUAFWPYY3d
	ZPGLEeQIt//8GXd1TdgpZS4ySK1ZqL7dsKpf8N6TtiQ2uyNDZH9s4Qpt2Ief83PRM6s
	gBnZGhZu3+qaG35U4tEj3h+iQcsVnQBe3LgXRXg4=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Christopher Clark 
Subject: [RFCv2 34/38] x86/hyperlaunch: introduce multidomain kconfig option
Date: Thu, 15 May 2025 09:19:46 -0400
Message-Id: <20250515131951.5594-5-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131951.5594-1-dpsmith@apertussolutions.com>
References: <20250515131951.5594-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

This adds the MULTIDOMAIN_BUILDER kconfig option that will be used to enable
the domain construction path to be called multiple times. With the idea of
being able to construct multiple domains now introduced, rename construct_dom0()
to construct_dom().

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/dom0_build.c            |  9 +++++----
 xen/arch/x86/domain-builder/domain.c |  2 +-
 xen/arch/x86/include/asm/bootinfo.h  |  2 +-
 xen/arch/x86/include/asm/setup.h     |  2 +-
 xen/common/domain-builder/Kconfig    | 12 ++++++++++++
 5 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 75969887b933..8f7615afb3f2 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -558,15 +558,16 @@ int __init dom0_setup_permissions(struct domain *d)
     return rc;
 }
 
-int __init construct_dom0(struct boot_domain *bd)
+int __init construct_dom(struct boot_domain *bd)
 {
     int rc;
     const struct domain *d = bd->d;
 
     /* Sanity! */
-    BUG_ON(!pv_shim && d->domain_id != 0);
-    BUG_ON(d->vcpu[0] == NULL);
-    BUG_ON(d->vcpu[0]->is_initialised);
+    if ( ! IS_ENABLED(CONFIG_MULTIDOMAIN_BUILDER) )
+        BUG_ON(!pv_shim && bd->d->domain_id != 0);
+    BUG_ON(bd->d->vcpu[0] == NULL);
+    BUG_ON(bd->d->vcpu[0]->is_initialised);
 
     process_pending_softirqs();
 
diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index deff6c8efaf1..c453629700c1 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -397,7 +397,7 @@ struct domain *__init arch_create_dom(
         bd->cmdline = cmdline;
     }
 
-    if ( construct_dom0(bd) != 0 )
+    if ( construct_dom(bd) != 0 )
         panic("Could not construct domain 0\n");
 
     bd->cmdline = NULL;
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 430ae08cf5ef..298cff303673 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -17,7 +17,7 @@
 #define MAX_NR_BOOTMODS 63
 
 /* Max number of boot domains that Xen can construct */
-#define MAX_NR_BOOTDOMS 1
+#define MAX_NR_BOOTDOMS 64
 
 /* Boot module binary type / purpose */
 enum bootmod_type {
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index 4b8fbdc67e05..3f6850d40d04 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -27,7 +27,7 @@ void subarch_init_memory(void);
 void init_IRQ(void);
 
 struct boot_domain;
-int construct_dom0(struct boot_domain *bd);
+int construct_dom(struct boot_domain *bd);
 
 const char *cmdline_cook(const char *p, const char *loader_name);
 
diff --git a/xen/common/domain-builder/Kconfig b/xen/common/domain-builder/Kconfig
index 44b8351af8ab..898a592a6340 100644
--- a/xen/common/domain-builder/Kconfig
+++ b/xen/common/domain-builder/Kconfig
@@ -12,4 +12,16 @@ config DOMAIN_BUILDER
 
 	  If unsure, say N.
 
+config MULTIDOMAIN_BUILDER
+	bool "Multiple domain building (UNSUPPORTED)" if UNSUPPORTED
+	depends on DOMAIN_BUILDER
+	default n
+	help
+      Enables the domain builder capability to build multiple domains
+	  using a flattened device tree.
+
+	  This feature is currently experimental.
+
+	  If unsure, say N.
+
 endmenu
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:34:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:34:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985527.1371487 (Exim 4.92)
	(envelope-from )
	id 1uFYim-0001iF-0b; Thu, 15 May 2025 13:34:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985527.1371487; Thu, 15 May 2025 13:33: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 1uFYil-0001i2-Sp; Thu, 15 May 2025 13:33:59 +0000
Received: by outflank-mailman (input) for mailman id 985527;
 Thu, 15 May 2025 13:33:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYWs-0006hT-Fr
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:21:42 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 88c57ca4-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:21:40 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315168934810.2700415584003;
 Thu, 15 May 2025 06:19: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" 
X-Inumbo-ID: 88c57ca4-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315172; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=bZnXRPcKo0wcH8yr1SybE13nsDoHoa0ZNq9Tnmrr8jYN+O5HYkXoInRtDaQSxCO7upm1RfCJEGPgsZM1DeA/o1DDVTZ8ukMGzk1rzJUA6diLF4/JaRyr6wRt0mNTn8P9yeeB9xnodv3cc/6jqU3bvm6eKpAoLVDkcFJjOn/53Ak=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315172; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=szift5nr4RwxcY6KS6NmBQOllT78PfzrUTES2oF68ac=; 
	b=JA5j43aOAP2sRYcTyXX6hsq7QjamKCzlYO0sJ0WVkDNN7jdZaRhYzxY3XL8Q98KioTeOm4FWqzGgsmkAU+9nk4WMx4khzj2DGsizZvNK0fgnLzOwrPwcw/6uDd1AHZCFvL9dIzXIM3TNpTMyCZ7zx562RTfMg9qbb5UOS+L9Gzs=
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=1747315172;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=szift5nr4RwxcY6KS6NmBQOllT78PfzrUTES2oF68ac=;
	b=JwVYNyBbDIvgHO7dLCeTDsxu06mNQOnjlI6YmXs5uKkre54Fk//X3IbfHhhzERnL
	b66wR+X6vHSV19Mr9KvI8w64wBRsEAv3e5/yQ3fqCeOOIF43/7ft1sFGpTr+EFjHk4a
	4lE2X7+jRWxajnfS6v2AvjkfOCHbcd2j0L9iqoCg=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 22/38] x86/hyperlaunch: add domu acpi construction
Date: Thu, 15 May 2025 09:19:05 -0400
Message-Id: <20250515131912.5019-3-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131912.5019-1-dpsmith@apertussolutions.com>
References: <20250515131912.5019-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Introduce hvm_setup_acpi() that will construct an APCI table for a general HVM
domU guest.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/hvm/dom_build.c | 213 ++++++++++++++++++++++++++++++++++-
 1 file changed, 212 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index 2157340335d2..e73a3950b30e 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -409,6 +409,214 @@ int __init hvm_add_mem_range(
     return 0;
 }
 
+static int __init hvm_setup_acpi_madt(
+    struct domain *d, struct acpi_table_madt *madt)
+{
+    struct acpi_table_header *table;
+    struct acpi_madt_local_apic *lapic;
+    acpi_status status;
+    unsigned long size = hvm_size_acpi_madt(d);
+    int i;
+
+    /* Copy the native MADT table header. */
+    status = acpi_get_table(ACPI_SIG_MADT, 0, &table);
+    if ( !ACPI_SUCCESS(status) )
+    {
+        printk("Failed to get MADT ACPI table, aborting.\n");
+        return -EINVAL;
+    }
+    madt->header = *table;
+    madt->address = APIC_DEFAULT_PHYS_BASE;
+    /*
+     * NB: this is currently set to 4, which is the revision in the ACPI
+     * spec 6.1. Sadly ACPICA doesn't provide revision numbers for the
+     * tables described in the headers.
+     */
+    madt->header.revision = min_t(unsigned char, table->revision, 4);
+
+    lapic = (void *)(madt + 1);
+
+    for ( i = 0; i < d->max_vcpus; i++ )
+    {
+        lapic->header.type = ACPI_MADT_TYPE_LOCAL_APIC;
+        lapic->header.length = sizeof(*lapic);
+        lapic->id = i * 2;
+        lapic->processor_id = i;
+        lapic->lapic_flags = ACPI_MADT_ENABLED;
+
+        lapic++;
+    }
+
+    madt->header.length = size;
+    /*
+     * Calling acpi_tb_checksum here is a layering violation, but
+     * introducing a wrapper for such simple usage seems overkill.
+     */
+    madt->header.checksum -= acpi_tb_checksum(ACPI_CAST_PTR(u8, madt), size);
+
+    return 0;
+}
+
+static int __init hvm_setup_acpi_xsdt(
+    struct domain *d, struct acpi_table_xsdt *xsdt, paddr_t madt_addr)
+{
+    struct acpi_table_header *table;
+    struct acpi_table_rsdp *rsdp;
+    unsigned long size = hvm_size_acpi_xsdt(d);
+    paddr_t xsdt_paddr;
+
+    /*
+     * Restore original DMAR table signature, we are going to filter it from
+     * the new XSDT that is presented to the guest, so it is no longer
+     * necessary to have it's signature zapped.
+     */
+    acpi_dmar_reinstate();
+
+    /* Copy the native XSDT table header. */
+    rsdp = acpi_os_map_memory(acpi_os_get_root_pointer(), sizeof(*rsdp));
+    if ( !rsdp )
+    {
+        printk("Unable to map RSDP\n");
+        return -EINVAL;
+    }
+    xsdt_paddr = rsdp->xsdt_physical_address;
+    acpi_os_unmap_memory(rsdp, sizeof(*rsdp));
+    table = acpi_os_map_memory(xsdt_paddr, sizeof(*table));
+    if ( !table )
+    {
+        printk("Unable to map XSDT\n");
+        return -EINVAL;
+    }
+    xsdt->header = *table;
+    acpi_os_unmap_memory(table, sizeof(*table));
+
+    /* Add the custom MADT. */
+    xsdt->table_offset_entry[0] = madt_addr;
+
+    xsdt->header.revision = 1;
+    xsdt->header.length = size;
+    /*
+     * Calling acpi_tb_checksum here is a layering violation, but
+     * introducing a wrapper for such simple usage seems overkill.
+     */
+    xsdt->header.checksum -= acpi_tb_checksum(ACPI_CAST_PTR(u8, xsdt), size);
+
+    return 0;
+}
+
+static int __init hvm_alloc_acpi_region(
+    struct domain *d, void **region, unsigned long size, paddr_t *addr)
+{
+    int i;
+
+    *addr = 0;
+
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        if ( d->arch.e820[i].type == E820_ACPI )
+        {
+            if ( d->arch.e820[i].size < size )
+                break;
+
+            *addr = d->arch.e820[i].addr;
+            break;
+        }
+    }
+
+    /* The e820 setup did not allocate ACPI region, steal one instead. */
+    if ( *addr == 0 )
+    {
+        if ( hvm_steal_ram(d, size, 0, GB(4), addr) )
+        {
+            printk("Unable to allocate guest RAM for RSDP\n");
+            return -ENOMEM;
+        }
+        if ( hvm_add_mem_range(d, *addr, *addr + size, E820_ACPI) )
+        {
+            printk("Unable to add RSDP region to memory map\n");
+            return -EFAULT;
+        }
+    }
+
+    *region = xzalloc_bytes(size);
+    if ( !region )
+        return -ENOMEM;
+
+    return 0;
+}
+
+static int __init hvm_setup_acpi(struct domain *d, paddr_t start_info)
+{
+    paddr_t rsdp_paddr, xsdt_paddr, madt_paddr;
+    struct acpi_table_rsdp *rsdp;
+    unsigned long size = hvm_size_acpi_region(d);
+    void *table;
+    int rc;
+
+    rc = hvm_alloc_acpi_region(d, &table, size, &rsdp_paddr);
+    if ( rc < 0 )
+        return rc;
+
+    /* RSDP */
+    rsdp = table;
+    xsdt_paddr = rsdp_paddr + sizeof(struct acpi_table_rsdp);
+
+    *rsdp = (struct acpi_table_rsdp){
+        .signature = ACPI_SIG_RSDP,
+        .revision = 2,
+        .length = sizeof(struct acpi_table_rsdp),
+        .oem_id = "XenHL\0", /* Xen Hyperlaunch */
+        .xsdt_physical_address = xsdt_paddr,
+    };
+
+    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));
+
+    /* XSDT */
+    table += sizeof(struct acpi_table_rsdp);
+    madt_paddr = xsdt_paddr + hvm_size_acpi_xsdt(d);
+
+    rc = hvm_setup_acpi_xsdt(d, table, madt_paddr);
+    if ( rc )
+    {
+        printk("Unable to construct XSDT\n");
+        goto out;
+    }
+
+
+    /* MADT */
+    table += hvm_size_acpi_xsdt(d);
+    rc = hvm_setup_acpi_madt(d, table);
+    if ( rc )
+    {
+        printk("Unable to construct MADT\n");
+        goto out;
+    }
+
+    /* Copy ACPI region into guest memory. */
+    rc = hvm_copy_to_guest_phys(rsdp_paddr, rsdp, size, d->vcpu[0]);
+    if ( rc )
+    {
+        printk("Unable to copy RSDP into guest memory\n");
+        goto out;
+    }
+
+    /* Copy RSDP address to start_info. */
+    rc = hvm_copy_to_guest_phys(
+        start_info + offsetof(struct hvm_start_info, rsdp_paddr), &rsdp_paddr,
+        sizeof(((struct hvm_start_info *) 0)->rsdp_paddr), d->vcpu[0]);
+    if ( rc )
+        printk("Unable to copy RSDP address to start info\n");
+
+ out:
+    if ( rsdp )
+        xfree(rsdp);
+
+    return rc;
+}
+
 static bool __init check_load_address(
     const struct domain *d, const struct elf_binary *elf)
 {
@@ -757,7 +965,10 @@ int __init dom_construct_pvh(struct boot_domain *bd)
         return rc;
     }
 
-    rc = dom0_pvh_setup_acpi(bd->d, start_info);
+    if ( is_control_domain(bd->d) || is_hardware_domain(bd->d) )
+        rc = dom0_pvh_setup_acpi(bd->d, start_info);
+    else
+        rc = hvm_setup_acpi(bd->d, start_info);
     if ( rc )
     {
         printk("Failed to setup Dom0 ACPI tables: %d\n", rc);
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:34:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:34:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985545.1371496 (Exim 4.92)
	(envelope-from )
	id 1uFYjO-0002eY-BD; Thu, 15 May 2025 13:34:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985545.1371496; Thu, 15 May 2025 13:34: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 1uFYjO-0002eR-8f; Thu, 15 May 2025 13:34:38 +0000
Received: by outflank-mailman (input) for mailman id 985545;
 Thu, 15 May 2025 13:34:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYX1-0006hT-Ct
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:21:51 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8e2ef4b1-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:21:49 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 174731517142646.630844721220456;
 Thu, 15 May 2025 06:19: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" 
X-Inumbo-ID: 8e2ef4b1-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315174; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=HNLkXWqKxMVgiodQy1c4fQpDO8VNarf/emWmgTbK0HOaf1Pgp7C2fGzivi5cVMVRHW8RZxtWqrsWmw0h1mJi5frgcvpK2nf/M0y095HVPX6KJTNP7iPPrWVTLFKKeAkz8/DkFs/Ug81nX6TLw7O5DP/hAFDnN6B720E8HsObcs8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315174; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=ctYdl98sf4D3+IQ7cSA7+ZkM59QI9KYHD8HOsUqDsmo=; 
	b=DSgn8DtJXWqa3DDKeKXt0KOBzMQvJyJAVJPk9bat94PaMNUJd40nUwHz7jaRGjdRWQU2bY5+5bweUux4b7y2X1nonJ6B2RrWlPPp7naqOupv5ItF+IqDoHQfPSqQvs3qVGnSQ/PrkT3+HtC4gqTEPcy88+xw8m4W8Mk+GgLhqDA=
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=1747315174;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=ctYdl98sf4D3+IQ7cSA7+ZkM59QI9KYHD8HOsUqDsmo=;
	b=pEmFQJXvjhLYrOQokSfnHu00kCFHYL79TA2G40G3CrRh1ShIDKvgbHzah9qbn/JE
	N5i11gA6Za0gWPmGE6xzCuebHLMI6Yrd9DWywlg8rftbciu41iGOHuBzeVAhdFbhvAw
	VDSe9HmD1xHl9oE5QhjQl33kMdoR/yER0AIOx554=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 25/38] x86/hyperlaunch: remove dom0-isms from arch_create_dom
Date: Thu, 15 May 2025 09:19:08 -0400
Message-Id: <20250515131912.5019-6-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131912.5019-1-dpsmith@apertussolutions.com>
References: <20250515131912.5019-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Removes the dom0 naming from variables and isolates control/hardware
domain specific logic behind capabilities check.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/domain-builder/domain.c | 47 +++++++++++++++-------------
 1 file changed, 26 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index 0a7b40c9a746..2c01705ebe4f 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -228,7 +228,7 @@ struct domain *__init arch_create_dom(
 {
     char *cmdline = NULL;
     size_t cmdline_size;
-    struct xen_domctl_createdomain dom0_cfg = {
+    struct xen_domctl_createdomain dom_cfg = {
         .flags = IS_ENABLED(CONFIG_TBOOT) ? XEN_DOMCTL_CDF_s3_integrity : 0,
         .max_evtchn_port = -1,
         .max_grant_frames = -1,
@@ -244,21 +244,21 @@ struct domain *__init arch_create_dom(
     if ( opt_dom0_pvh ||
          (bi->hyperlaunch_enabled && !(bd->mode & BUILD_MODE_PARAVIRT)) )
     {
-        dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm |
+        dom_cfg.flags |= (XEN_DOMCTL_CDF_hvm |
                            ((hvm_hap_supported() && !opt_dom0_shadow) ?
                             XEN_DOMCTL_CDF_hap : 0));
 
-        dom0_cfg.arch.emulation_flags |=
+        dom_cfg.arch.emulation_flags |=
             XEN_X86_EMU_LAPIC | XEN_X86_EMU_IOAPIC | XEN_X86_EMU_VPCI;
     }
 
     if ( iommu_enabled && (bd->capabilities & DOMAIN_CAPS_HARDWARE) )
-        dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+        dom_cfg.flags |= XEN_DOMCTL_CDF_iommu;
 
     if ( bd->domid == DOMID_INVALID )
         /* Create initial domain.  Not d0 for pvshim. */
         bd->domid = get_initial_domain_id();
-    d = domain_create(bd->domid, &dom0_cfg,
+    d = domain_create(bd->domid, &dom_cfg,
             ((bd->capabilities & DOMAIN_CAPS_CONTROL)  ? CDF_privileged : 0) |
             ((bd->capabilities & DOMAIN_CAPS_HARDWARE) ? CDF_hardware   : 0));
     if ( IS_ERR(d) )
@@ -289,25 +289,30 @@ struct domain *__init arch_create_dom(
                     cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
                     cmdline_size);
 
-        if ( bi->kextra )
-            /* kextra always includes exactly one leading space. */
-            strlcat(cmdline, bi->kextra, cmdline_size);
-
-        /* Append any extra parameters. */
-        if ( skip_ioapic_setup && !strstr(cmdline, "noapic") )
-            strlcat(cmdline, " noapic", cmdline_size);
-
-        if ( (strlen(acpi_param) == 0) && acpi_disabled )
+        /* Params from Xen cmd line apply only to classic dom0 */
+        if ( has_dom0_caps(bd) )
         {
-            printk("ACPI is disabled, notifying Domain 0 (acpi=off)\n");
-            safe_strcpy(acpi_param, "off");
+            if ( bi->kextra )
+                /* kextra always includes exactly one leading space. */
+                strlcat(cmdline, bi->kextra, cmdline_size);
+
+            /* Append any extra parameters. */
+            if ( skip_ioapic_setup && !strstr(cmdline, "noapic") )
+                strlcat(cmdline, " noapic", cmdline_size);
+
+            if ( (strlen(acpi_param) == 0) && acpi_disabled )
+            {
+                printk("ACPI is disabled, notifying Domain 0 (acpi=off)\n");
+                safe_strcpy(acpi_param, "off");
+            }
+
+            if ( (strlen(acpi_param) != 0) && !strstr(cmdline, "acpi=") )
+            {
+                strlcat(cmdline, " acpi=", cmdline_size);
+                strlcat(cmdline, acpi_param, cmdline_size);
+            }
         }
 
-        if ( (strlen(acpi_param) != 0) && !strstr(cmdline, "acpi=") )
-        {
-            strlcat(cmdline, " acpi=", cmdline_size);
-            strlcat(cmdline, acpi_param, cmdline_size);
-        }
         bd->kernel->cmdline_pa = 0;
         bd->cmdline = cmdline;
     }
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:34:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:34:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985547.1371503 (Exim 4.92)
	(envelope-from )
	id 1uFYjO-0002hx-Kb; Thu, 15 May 2025 13:34:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985547.1371503; Thu, 15 May 2025 13:34: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 1uFYjO-0002h3-F5; Thu, 15 May 2025 13:34:38 +0000
Received: by outflank-mailman (input) for mailman id 985547;
 Thu, 15 May 2025 13:34:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYXK-0006hT-P5
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:22:10 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9923e92f-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:22:08 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315170626583.7198539212203;
 Thu, 15 May 2025 06:19: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" 
X-Inumbo-ID: 9923e92f-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315174; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=GeZrkLgy9Z+TEccRyIq7edi4Snl86Jz1BJ4K6B289ZoCZOaahk8PNMDVt72ZuBeKwZYMwcj9E6MTRNHte1WEsQml5dCpVJSzczi1qGnobPkmYIft8DqWn0rbKjK1pfpAx3nZoasCFDHYrMM/yEw4tVXy4DXs3Win5eZE/j4awwQ=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315174; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=pe3ywFf454HRDAAca+YGTm4pcdc3mvF9zfiQ+NSlMjk=; 
	b=n3sLr9u/ol/2zfN2a1rbYciH65vi8x6M4KJJ/xZRP0u8op8JMOBv2r0OD5XOYE3DVXNy5nzKZnNjYVaktvp4CfnQmnR3487Wfz0kNm+SBEwF0sPxLNmosi/Ike9ywHUji8O8LUCi+yApocl7fBQszqSg5bYNBLIjOD/gxCI2lGg=
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=1747315174;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=pe3ywFf454HRDAAca+YGTm4pcdc3mvF9zfiQ+NSlMjk=;
	b=tvalZ1wNMULr3vq3Onr+LL6N0kweIOaIGI78b8w0q5X/dvBMOYYtc4VEU54JfNze
	NbKuDvLfPthn88Dp8lPHBzOmNlpbVagD0/+Cj1iYc5jf6XuVzB1uzKzTEsdGXPC/I40
	+oSgSw+7ZfFExsCgd/BoxFAUrBWQut+DXT2m+YVc=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Christopher Clark 
Subject: [RFCv2 24/38] x86/hyperlaunch: convert create_dom0 to arch_create_dom
Date: Thu, 15 May 2025 09:19:07 -0400
Message-Id: <20250515131912.5019-5-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131912.5019-1-dpsmith@apertussolutions.com>
References: <20250515131912.5019-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The only consumer of the function domain_cmdline_size() and the acpi_param
parameter is create_dom(). It is therefore reasonable to move
domain_cmdline_size() and the acpi_param parameter along with its parsing code
at the same time as create_dom0() is moved under the domain builder. While
moving create_dom0(), rename it to arch_create_dom() as the function is now
generalized.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/domain-builder/Makefile |   2 +-
 xen/arch/x86/domain-builder/domain.c | 180 +++++++++++++++++++++++++++
 xen/arch/x86/setup.c                 | 174 +-------------------------
 xen/include/xen/domain-builder.h     |   3 +
 4 files changed, 185 insertions(+), 174 deletions(-)

diff --git a/xen/arch/x86/domain-builder/Makefile b/xen/arch/x86/domain-builder/Makefile
index 0c2e7085e21b..69a7c574a8d8 100644
--- a/xen/arch/x86/domain-builder/Makefile
+++ b/xen/arch/x86/domain-builder/Makefile
@@ -1 +1 @@
-obj-y += domain.init.o
+obj-y += domain.o
diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index d934b240229f..0a7b40c9a746 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -5,17 +5,25 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include  /* get types.h for libefl.h */
 #include 
 #include 
+#include 
 #include 
 
 #include 
 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
 
 unsigned int __init dom_max_vcpus(struct boot_domain *bd)
@@ -55,6 +63,48 @@ void __init domain_vcpus_create(struct domain *d)
     domain_update_node_affinity(d);
 }
 
+bool __read_mostly acpi_disabled;
+bool __initdata acpi_force;
+static char __initdata acpi_param[10] = "";
+
+static int __init cf_check parse_acpi_param(const char *s)
+{
+    /* Interpret the parameter for use within Xen. */
+    if ( !parse_bool(s, NULL) )
+    {
+        disable_acpi();
+    }
+    else if ( !strcmp(s, "force") )
+    {
+        acpi_force = true;
+        acpi_ht = 1;
+        acpi_disabled = false;
+    }
+    else if ( !strcmp(s, "ht") )
+    {
+        if ( !acpi_force )
+            disable_acpi();
+        acpi_ht = 1;
+    }
+    else if ( !strcmp(s, "noirq") )
+    {
+        acpi_noirq_set();
+    }
+    else if ( !strcmp(s, "verbose") )
+    {
+        opt_acpi_verbose = true;
+        return 0;
+    }
+    else
+        return -EINVAL;
+
+    /* Save the parameter so it can be propagated to domain0. */
+    safe_strcpy(acpi_param, s);
+
+    return 0;
+}
+custom_param("acpi", parse_acpi_param);
+
 unsigned long __init dom_paging_pages(
     const struct boot_domain *bd, unsigned long nr_pages)
 {
@@ -141,6 +191,136 @@ unsigned long __init dom_compute_nr_pages(
     return bd->mem_pages;
 }
 
+static size_t __init domain_cmdline_size(const struct boot_info *bi,
+                                         const struct boot_domain *bd)
+{
+    size_t s = bi->kextra ? strlen(bi->kextra) : 0;
+
+
+    /*
+     * Bootloader cmdline takes precedence and replaces the DT provided one.
+     *
+     * In that case, fdt_cmdline is not be populated at all.
+     */
+    if ( bd->kernel->fdt_cmdline )
+    {
+        BUG_ON(!IS_ENABLED(CONFIG_DOMAIN_BUILDER));
+        s += builder_get_cmdline_size(bi, bd->kernel->cmdline_pa);
+    }
+    else if ( bd->kernel->cmdline_pa )
+        s += strlen(__va(bd->kernel->cmdline_pa));
+
+    if ( s == 0 )
+        return s;
+
+    /*
+     * Certain parameters from the Xen command line may be added to the dom0
+     * command line. Add additional space for the possible cases along with one
+     * extra char to hold \0.
+     */
+    s += strlen(" noapic") + strlen(" acpi=") + sizeof(acpi_param) + 1;
+
+    return s;
+}
+
+struct domain *__init arch_create_dom(
+    struct boot_info *bi, struct boot_domain *bd)
+{
+    char *cmdline = NULL;
+    size_t cmdline_size;
+    struct xen_domctl_createdomain dom0_cfg = {
+        .flags = IS_ENABLED(CONFIG_TBOOT) ? XEN_DOMCTL_CDF_s3_integrity : 0,
+        .max_evtchn_port = -1,
+        .max_grant_frames = -1,
+        .max_maptrack_frames = -1,
+        .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
+        .max_vcpus = dom_max_vcpus(bd),
+        .arch = {
+            .misc_flags = opt_dom0_msr_relaxed ? XEN_X86_MSR_RELAXED : 0,
+        },
+    };
+    struct domain *d;
+
+    if ( opt_dom0_pvh ||
+         (bi->hyperlaunch_enabled && !(bd->mode & BUILD_MODE_PARAVIRT)) )
+    {
+        dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm |
+                           ((hvm_hap_supported() && !opt_dom0_shadow) ?
+                            XEN_DOMCTL_CDF_hap : 0));
+
+        dom0_cfg.arch.emulation_flags |=
+            XEN_X86_EMU_LAPIC | XEN_X86_EMU_IOAPIC | XEN_X86_EMU_VPCI;
+    }
+
+    if ( iommu_enabled && (bd->capabilities & DOMAIN_CAPS_HARDWARE) )
+        dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+
+    if ( bd->domid == DOMID_INVALID )
+        /* Create initial domain.  Not d0 for pvshim. */
+        bd->domid = get_initial_domain_id();
+    d = domain_create(bd->domid, &dom0_cfg,
+            ((bd->capabilities & DOMAIN_CAPS_CONTROL)  ? CDF_privileged : 0) |
+            ((bd->capabilities & DOMAIN_CAPS_HARDWARE) ? CDF_hardware   : 0));
+    if ( IS_ERR(d) )
+        panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
+
+    bd->d = d;
+
+    if ( has_dom0_caps(bd) )
+        init_dom0_cpuid_policy(bd->d);
+
+    if ( domain_vcpu0_create(bd) == NULL )
+        panic("Error creating %pdv0\n", d);
+
+    cmdline_size = domain_cmdline_size(bi, bd);
+    if ( cmdline_size )
+    {
+        if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
+            panic("Error allocating cmdline buffer for %pd\n", d);
+
+        if ( bd->kernel->fdt_cmdline )
+        {
+            BUG_ON(!IS_ENABLED(CONFIG_DOMAIN_BUILDER));
+            builder_get_cmdline(
+                bi, bd->kernel->cmdline_pa, cmdline, cmdline_size);
+        }
+        else if ( bd->kernel->cmdline_pa )
+            strlcpy(cmdline,
+                    cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
+                    cmdline_size);
+
+        if ( bi->kextra )
+            /* kextra always includes exactly one leading space. */
+            strlcat(cmdline, bi->kextra, cmdline_size);
+
+        /* Append any extra parameters. */
+        if ( skip_ioapic_setup && !strstr(cmdline, "noapic") )
+            strlcat(cmdline, " noapic", cmdline_size);
+
+        if ( (strlen(acpi_param) == 0) && acpi_disabled )
+        {
+            printk("ACPI is disabled, notifying Domain 0 (acpi=off)\n");
+            safe_strcpy(acpi_param, "off");
+        }
+
+        if ( (strlen(acpi_param) != 0) && !strstr(cmdline, "acpi=") )
+        {
+            strlcat(cmdline, " acpi=", cmdline_size);
+            strlcat(cmdline, acpi_param, cmdline_size);
+        }
+        bd->kernel->cmdline_pa = 0;
+        bd->cmdline = cmdline;
+    }
+
+    if ( construct_dom0(bd) != 0 )
+        panic("Could not construct domain 0\n");
+
+    bd->cmdline = NULL;
+    xfree(cmdline);
+
+    return d;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index b03284428bb3..2458a43902e6 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -251,48 +251,6 @@ static int __init cf_check parse_smap_param(const char *s)
 }
 custom_param("smap", parse_smap_param);
 
-bool __read_mostly acpi_disabled;
-bool __initdata acpi_force;
-static char __initdata acpi_param[10] = "";
-
-static int __init cf_check parse_acpi_param(const char *s)
-{
-    /* Interpret the parameter for use within Xen. */
-    if ( !parse_bool(s, NULL) )
-    {
-        disable_acpi();
-    }
-    else if ( !strcmp(s, "force") )
-    {
-        acpi_force = true;
-        acpi_ht = 1;
-        acpi_disabled = false;
-    }
-    else if ( !strcmp(s, "ht") )
-    {
-        if ( !acpi_force )
-            disable_acpi();
-        acpi_ht = 1;
-    }
-    else if ( !strcmp(s, "noirq") )
-    {
-        acpi_noirq_set();
-    }
-    else if ( !strcmp(s, "verbose") )
-    {
-        opt_acpi_verbose = true;
-        return 0;
-    }
-    else
-        return -EINVAL;
-
-    /* Save the parameter so it can be propagated to domain0. */
-    safe_strcpy(acpi_param, s);
-
-    return 0;
-}
-custom_param("acpi", parse_acpi_param);
-
 struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
@@ -982,136 +940,6 @@ static unsigned int __init copy_bios_e820(struct e820entry *map, unsigned int li
     return n;
 }
 
-static size_t __init domain_cmdline_size(const struct boot_info *bi,
-                                         const struct boot_domain *bd)
-{
-    size_t s = bi->kextra ? strlen(bi->kextra) : 0;
-
-
-    /*
-     * Bootloader cmdline takes precedence and replaces the DT provided one.
-     *
-     * In that case, fdt_cmdline is not be populated at all.
-     */
-    if ( bd->kernel->fdt_cmdline )
-    {
-        BUG_ON(!IS_ENABLED(CONFIG_DOMAIN_BUILDER));
-        s += builder_get_cmdline_size(bi, bd->kernel->cmdline_pa);
-    }
-    else if ( bd->kernel->cmdline_pa )
-        s += strlen(__va(bd->kernel->cmdline_pa));
-
-    if ( s == 0 )
-        return s;
-
-    /*
-     * Certain parameters from the Xen command line may be added to the dom0
-     * command line. Add additional space for the possible cases along with one
-     * extra char to hold \0.
-     */
-    s += strlen(" noapic") + strlen(" acpi=") + sizeof(acpi_param) + 1;
-
-    return s;
-}
-
-static struct domain *__init create_dom0(struct boot_info *bi)
-{
-    char *cmdline = NULL;
-    size_t cmdline_size;
-    struct boot_domain *bd = &bi->domains[0];
-    struct xen_domctl_createdomain dom0_cfg = {
-        .flags = IS_ENABLED(CONFIG_TBOOT) ? XEN_DOMCTL_CDF_s3_integrity : 0,
-        .max_evtchn_port = -1,
-        .max_grant_frames = -1,
-        .max_maptrack_frames = -1,
-        .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
-        .max_vcpus = dom_max_vcpus(bd),
-        .arch = {
-            .misc_flags = opt_dom0_msr_relaxed ? XEN_X86_MSR_RELAXED : 0,
-        },
-    };
-    struct domain *d;
-
-    if ( opt_dom0_pvh ||
-         (bi->hyperlaunch_enabled && !(bd->mode & BUILD_MODE_PARAVIRT)) )
-    {
-        dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm |
-                           ((hvm_hap_supported() && !opt_dom0_shadow) ?
-                            XEN_DOMCTL_CDF_hap : 0));
-
-        dom0_cfg.arch.emulation_flags |=
-            XEN_X86_EMU_LAPIC | XEN_X86_EMU_IOAPIC | XEN_X86_EMU_VPCI;
-    }
-
-    if ( iommu_enabled && (bd->capabilities & DOMAIN_CAPS_HARDWARE) )
-        dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
-
-    if ( bd->domid == DOMID_INVALID )
-        /* Create initial domain.  Not d0 for pvshim. */
-        bd->domid = get_initial_domain_id();
-    d = domain_create(bd->domid, &dom0_cfg,
-            ((bd->capabilities & DOMAIN_CAPS_CONTROL)  ? CDF_privileged : 0) |
-            ((bd->capabilities & DOMAIN_CAPS_HARDWARE) ? CDF_hardware   : 0));
-    if ( IS_ERR(d) )
-        panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
-
-    bd->d = d;
-
-    if ( has_dom0_caps(bd) )
-        init_dom0_cpuid_policy(bd->d);
-
-    if ( domain_vcpu0_create(bd) == NULL )
-        panic("Error creating %pdv0\n", d);
-
-    cmdline_size = domain_cmdline_size(bi, bd);
-    if ( cmdline_size )
-    {
-        if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
-            panic("Error allocating cmdline buffer for %pd\n", d);
-
-        if ( bd->kernel->fdt_cmdline )
-        {
-            BUG_ON(!IS_ENABLED(CONFIG_DOMAIN_BUILDER));
-            builder_get_cmdline(
-                bi, bd->kernel->cmdline_pa, cmdline, cmdline_size);
-        }
-        else if ( bd->kernel->cmdline_pa )
-            strlcpy(cmdline,
-                    cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
-                    cmdline_size);
-
-        if ( bi->kextra )
-            /* kextra always includes exactly one leading space. */
-            strlcat(cmdline, bi->kextra, cmdline_size);
-
-        /* Append any extra parameters. */
-        if ( skip_ioapic_setup && !strstr(cmdline, "noapic") )
-            strlcat(cmdline, " noapic", cmdline_size);
-
-        if ( (strlen(acpi_param) == 0) && acpi_disabled )
-        {
-            printk("ACPI is disabled, notifying Domain 0 (acpi=off)\n");
-            safe_strcpy(acpi_param, "off");
-        }
-
-        if ( (strlen(acpi_param) != 0) && !strstr(cmdline, "acpi=") )
-        {
-            strlcat(cmdline, " acpi=", cmdline_size);
-            strlcat(cmdline, acpi_param, cmdline_size);
-        }
-        bd->kernel->cmdline_pa = 0;
-        bd->cmdline = cmdline;
-    }
-
-    if ( construct_dom0(bd) != 0 )
-        panic("Could not construct domain 0\n");
-
-    bd->cmdline = NULL;
-    xfree(cmdline);
-
-    return d;
-}
-
 /* How much of the directmap is prebuilt at compile time. */
 #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT)
 
@@ -2198,7 +2026,7 @@ void asmlinkage __init noreturn __start_xen(void)
      * We're going to setup domain0 using the module(s) that we stashed safely
      * above our heap. The second module, if present, is an initrd ramdisk.
      */
-    dom0 = create_dom0(bi);
+    dom0 = arch_create_dom(bi, &bi->domains[0]);
     if ( !dom0 )
         panic("Could not set up DOM0 guest OS\n");
 
diff --git a/xen/include/xen/domain-builder.h b/xen/include/xen/domain-builder.h
index 79e4c50ddf85..a9df326682ac 100644
--- a/xen/include/xen/domain-builder.h
+++ b/xen/include/xen/domain-builder.h
@@ -40,4 +40,7 @@ unsigned int dom_max_vcpus(struct boot_domain *bd);
 struct vcpu *domain_vcpu0_create(struct boot_domain *bd);
 void domain_vcpus_create(struct domain *d);
 
+struct domain *arch_create_dom(
+    struct boot_info *bi, struct boot_domain *bd);
+
 #endif /* __XEN_DOMAIN_BUILDER_H__ */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:34:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:34:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985548.1371517 (Exim 4.92)
	(envelope-from )
	id 1uFYjS-00039k-SO; Thu, 15 May 2025 13:34:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985548.1371517; Thu, 15 May 2025 13:34: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 1uFYjS-00039b-Ph; Thu, 15 May 2025 13:34:42 +0000
Received: by outflank-mailman (input) for mailman id 985548;
 Thu, 15 May 2025 13:34:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYZH-0006hT-Sm
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:24:11 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e1ee5744-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:24:10 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315208582495.21756854934097;
 Thu, 15 May 2025 06:20: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" 
X-Inumbo-ID: e1ee5744-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315212; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=aDKHUYwn6EnhWEW7vXwM2kfigr2OjwHCQFnjtUQuGLfwDmeKj1Q5rHgV/7b4FXhDWb8FNbaarL8Hz36ZHtcCZuAZUGuebsMsUE5hFwXDlAS0SEgaWu3oQ1CH81WHFv9wcbU0AOYhRlJ5XLNxURrniG21rnWQz74LQwx+CrqfSc0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315212; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=xFWh0LIwTnqw7AT+3wLll5s9wldVWcR9OTEyPHJ0MOc=; 
	b=g8eOj7p8x8FBJC/h/cWO2AorkOt3qfiqna/WpQUQy0laDRnZkQifMne0d6tF0+ec8lZL1IVHQ+FgtOoTc4sbcoZt58ZTxBkLPrQdXDgEKzpr6Vi7pjpy5xwIJFtIqb/4umLxB44a2tVfOS/qGO3qeMbuVE/MEB5enwu4E1DQr4s=
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=1747315212;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=xFWh0LIwTnqw7AT+3wLll5s9wldVWcR9OTEyPHJ0MOc=;
	b=hwb5d7sQrKfQKrKwbLjjh9IwFbcMxuW3i8S7W2OqYksBH829xF9RdBCtE/wYIF2Q
	a5WZ178TCJEisKhupgTu6jCCvcBySeO7IBzMo1RggBgJAhg8endT0CFoY2H7oqcwbTW
	lO7S5Ncqfy3b75FXJvJbsRuvJJ3S3eqJHT2PeUT8=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 35/38] x86/hyperlaunch: add multidomain construction logic
Date: Thu, 15 May 2025 09:19:47 -0400
Message-Id: <20250515131951.5594-6-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131951.5594-1-dpsmith@apertussolutions.com>
References: <20250515131951.5594-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Introduce the logic to loop over boot_info->domains and construct
each valid entry in the array.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/domain-builder/core.c   | 30 ++++++++++++++++++++++++++++
 xen/arch/x86/domain-builder/domain.c |  7 +++++--
 xen/arch/x86/hvm/dom_build.c         |  5 ++++-
 xen/arch/x86/setup.c                 |  3 ++-
 4 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/domain-builder/core.c b/xen/arch/x86/domain-builder/core.c
index af79792b5316..367c0de33cfb 100644
--- a/xen/arch/x86/domain-builder/core.c
+++ b/xen/arch/x86/domain-builder/core.c
@@ -58,6 +58,7 @@ static int  __init build_core_domains(struct boot_info *bi)
 unsigned int __init builder_create_domains(struct boot_info *bi)
 {
     unsigned int build_count = 0;
+    int i;
 
     if ( bi->nr_domains == 0 )
         panic("%s: no domains defined\n", __func__);
@@ -70,10 +71,39 @@ unsigned int __init builder_create_domains(struct boot_info *bi)
             bi->domains[0].constructed = true;
             build_count++;
         }
+
+        goto out;
     }
     else
         build_count = build_core_domains(bi);
 
+    if ( !IS_ENABLED(CONFIG_MULTIDOMAIN_BUILDER) )
+        goto out;
+
+    for ( i = 0; i < bi->nr_domains; i++ )
+    {
+        struct boot_domain *bd = &bi->domains[i];
+
+        if ( bd->constructed )
+            continue;
+
+        if ( bd->mode & BUILD_MODE_PARAVIRT )
+        {
+            printk(XENLOG_WARNING "don't support PV DomU, skipping %d\n", i);
+            continue;
+        }
+
+        arch_create_dom(bi, bd);
+        if ( bd->d )
+        {
+            bd->constructed = true;
+            build_count++;
+        }
+        else
+            printk(XENLOG_WARNING "failed to construct build domain %d\n", i);
+    }
+
+ out:
     arch_builder_finalize(bi);
 
     return build_count;
diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index c453629700c1..9d9901fad505 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -326,8 +326,11 @@ struct domain *__init arch_create_dom(
                            ((hvm_hap_supported() && !opt_dom0_shadow) ?
                             XEN_DOMCTL_CDF_hap : 0));
 
-        dom_cfg.arch.emulation_flags |=
-            XEN_X86_EMU_LAPIC | XEN_X86_EMU_IOAPIC | XEN_X86_EMU_VPCI;
+        if ( bd->capabilities & DOMAIN_CAPS_HARDWARE )
+            dom_cfg.arch.emulation_flags |=
+                XEN_X86_EMU_LAPIC | XEN_X86_EMU_IOAPIC | XEN_X86_EMU_VPCI;
+        else
+            dom_cfg.arch.emulation_flags |= X86_EMU_LAPIC;
     }
 
     if ( iommu_enabled && (bd->capabilities & DOMAIN_CAPS_HARDWARE) )
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index 170caac6716e..3118e3483e46 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -885,7 +885,10 @@ static int __init pvh_load_kernel(
     }
 
     start_info.magic = XEN_HVM_START_MAGIC_VALUE;
-    start_info.flags = SIF_PRIVILEGED | SIF_INITDOMAIN;
+    if ( is_control_domain(d) )
+        start_info.flags = SIF_PRIVILEGED;
+    if ( is_hardware_domain(d) )
+        start_info.flags = SIF_INITDOMAIN;
     rc = hvm_copy_to_guest_phys(last_addr, &start_info, sizeof(start_info), v);
     if ( rc )
     {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 36e6ba11ddcd..422fef7ce02a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1331,7 +1331,8 @@ void asmlinkage __init noreturn __start_xen(void)
         xen->size  = __2M_rwdata_end - _stext;
     }
 
-    arch_builder_headroom(&bi->domains[0]);
+    for ( i = 0; i < bi->nr_domains; i++ )
+        arch_builder_headroom(&bi->domains[i]);
 
 #ifndef highmem_start
     /* Don't allow split below 4Gb. */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:35:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:35:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985564.1371527 (Exim 4.92)
	(envelope-from )
	id 1uFYkP-0004Ph-9Z; Thu, 15 May 2025 13:35:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985564.1371527; Thu, 15 May 2025 13:35: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 1uFYkP-0004Pa-5g; Thu, 15 May 2025 13:35:41 +0000
Received: by outflank-mailman (input) for mailman id 985564;
 Thu, 15 May 2025 13:35:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYYz-0006hT-5L
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:23:53 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d6af808e-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:23:51 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315210534223.5685233894054;
 Thu, 15 May 2025 06:20: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" 
X-Inumbo-ID: d6af808e-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315212; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=MaZQZVgSGmBm0AONeCXNoLnW18Jojn047+kvWN/Bmf/4I570pEckVQEUY3y8oIZOfUtmpRl4CjG1nb9UDXNmus+P1M+zBfqdtlzOBxSohRT0kodbGZpzh4aZoMu/VNb76Lg66c9ZQXohI1/m9k0DsncXu/QEGw8CFxOOEm8+sbc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315212; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=TCd5wTbVXQm1/qDiCEzXOZKvySaWqAmfH5oNFsGkQLM=; 
	b=DceaBjWZoB04mP2wLMWNXvihLUqJew91/CMRqGrqhEMnJl5aKE/IJczStqtGlUiStGfiWzkSl4jHxrz93F1Gkf4QHSe1jzQ9dLyyeGBfO/OL5T4RXneytU9fTQXf3Urc+f50Nb8tFlTJ+mR3oo/gsYaWpxsL4d9CywbKKiOEj4M=
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=1747315212;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=TCd5wTbVXQm1/qDiCEzXOZKvySaWqAmfH5oNFsGkQLM=;
	b=c14VD8cjBb999JMp5VY5wIet/8z75JR/2F4BJ7UJezZuQh7RMJOPcC2WMhHfawcw
	UG4LU4HWwLsBlsVmYRUnt8ucATVYAm9QuamS6VVgUrQ1GmGhlfYmlB+Z8Ef0UA33oIX
	/551IEoglB00T7SzMBumd0UqC2Nkgei213EeUE94=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Christopher Clark 
Subject: [RFCv2 37/38] x86/hyperlaunch: generalize domid assignment
Date: Thu, 15 May 2025 09:19:49 -0400
Message-Id: <20250515131951.5594-8-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131951.5594-1-dpsmith@apertussolutions.com>
References: <20250515131951.5594-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Signed-off-by: Daniel P. Smith 
---
 xen/common/domain-builder/fdt.c | 32 +++++++++++++++++++++++---------
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/xen/common/domain-builder/fdt.c b/xen/common/domain-builder/fdt.c
index 1b3492571b15..414bbf5d9fb1 100644
--- a/xen/common/domain-builder/fdt.c
+++ b/xen/common/domain-builder/fdt.c
@@ -16,6 +16,21 @@
 
 #include "fdt.h"
 
+#define MAX_DOMID  DOMID_FIRST_RESERVED
+static __initdata DECLARE_BITMAP(domid_alloc, MAX_DOMID);
+
+static domid_t __init find_next_domid(void)
+{
+    unsigned long n = find_next_zero_bit(domid_alloc, MAX_DOMID, 1);
+
+    if ( n == MAX_DOMID )
+        return DOMID_INVALID;
+
+    set_bit(n, domid_alloc);
+
+    return (domid_t) n;
+}
+
 static int __init fdt_prop_as_u32(const struct fdt_property *prop,
                                   uint32_t *val)
 {
@@ -231,18 +246,17 @@ static int __init fdt_process_domain_node(
 
             if ( val >= DOMID_FIRST_RESERVED )
             {
-                printk(XENLOG_ERR "  invalid domain id for domain %s\n", name);
-                return -EINVAL;
-            }
-
-            for ( unsigned int i = 0; i < bi->nr_domains; i++ )
-            {
-                if ( bi->domains[i].domid == val )
+                if ( (val = find_next_domid()) == DOMID_INVALID )
                 {
-                    printk(XENLOG_ERR "  duplicate id for domain %s\n", name);
-                    return -EINVAL;
+                    printk("  unable to allocate domid for domain %s\n", name);
+                    return -EFAULT;
                 }
             }
+            else if ( test_and_set_bit(val, domid_alloc) )
+            {
+                printk(XENLOG_ERR "  duplicate id for domain %s\n", name);
+                return -EINVAL;
+            }
 
             bd->domid = val;
             printk(XENLOG_INFO "  domid: %d\n", bd->domid);
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:35:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:35:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985573.1371547 (Exim 4.92)
	(envelope-from )
	id 1uFYkX-0004yC-NQ; Thu, 15 May 2025 13:35:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985573.1371547; Thu, 15 May 2025 13: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 1uFYkX-0004y5-KJ; Thu, 15 May 2025 13:35:49 +0000
Received: by outflank-mailman (input) for mailman id 985573;
 Thu, 15 May 2025 13:35:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYXd-0006hT-Ui
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:22:29 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a50a2967-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:22:28 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315173970122.38765931630746;
 Thu, 15 May 2025 06:19:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a50a2967-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315176; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=cuq8qduxl/hBaTXhwcGw+1cUGIkYyY9sflAeS/u1rJjJPnLjMf8MqCA9wdAigLF4Y9J885hSIJmRdQ8gyrJboJd3pfzyf2YdMS6ptXeiILfctg1IoCL/NpvAoAUxG5YxpOd41/syULdexblF3Y/UBdKFZjU2PjU+31AZdze9dO8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315176; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=gYB4y96SIDLxZLUe6mZw8W86OeBS41ZZGc8WGg8cXnk=; 
	b=kPuYUvAwBi7Gv3k3wrlTdQb2QuM3xEk/PGHPrC2MckHcSv+80RuJ/lVxzrnV3ONoDsr0zs20MhxMkPRMgAI9bbvQQMD0+i7RrCrcY1YGlvLkIa2Ywo3xWC0fo3Ujn9WTZWKQG6ymd/IM3MW9/9mOOFEUG3Zd/Eeg1HFZBtfgjYI=
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=1747315176;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=gYB4y96SIDLxZLUe6mZw8W86OeBS41ZZGc8WGg8cXnk=;
	b=gvee8Gq3Z+fOhB8geVfFd4S3muzJKHOHmpZmsBIv6Ykn9gb7zmnwtyuuXu6061Ak
	kGSUdkycpSLubcjf4p3FCH0AxlZirm2d8zCtURsXwUZnotDpICdNem5Ls80x6WJkTCi
	4j8uzYaPw6CLME1Yuz7vJDCIEcDvSlQQ+tX+rNXk=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 28/38] x86/hyperlaunch: allocate xenstore for domu
Date: Thu, 15 May 2025 09:19:11 -0400
Message-Id: <20250515131912.5019-9-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131912.5019-1-dpsmith@apertussolutions.com>
References: <20250515131912.5019-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

During domU construction, a page of memory and an event channel must be setup
for xenstore connection. In this commit, a page from the special page region of
domU is setup as the xenstore page along with an event channel. The page
address and event channel are published in the HVM parameters, so the domain
can be announced to Xenstore.

Signed-off-by: Daniel P. Smith 

---

Changes for RFCv2:
- rewrote to setup event chan after construction has finished
- merged the setting of xenstore boot capabilities flag commit
---
 xen/arch/x86/domain-builder/domain.c      | 56 +++++++++++++++++++++++
 xen/arch/x86/hvm/dom_build.c              | 26 +++++++++++
 xen/arch/x86/include/asm/boot-domain.h    |  3 ++
 xen/arch/x86/include/asm/domain-builder.h |  2 +
 4 files changed, 87 insertions(+)

diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index 5b03e3dce228..de0ee0fcd62c 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include  /* get types.h for libefl.h */
@@ -16,6 +17,7 @@
 #include 
 
 #include 
+#include 
 
 #include 
 #include 
@@ -191,6 +193,28 @@ unsigned long __init dom_compute_nr_pages(
     return bd->mem_pages;
 }
 
+static int __init alloc_dom_evtchn(
+    const struct boot_domain *d, const struct boot_domain *r,
+    evtchn_port_t *port)
+{
+    int rc;
+    evtchn_alloc_unbound_t ec = {
+        .dom = d->domid,
+        .remote_dom = r->domid,
+    };
+
+    rc = evtchn_alloc_unbound(&ec, 0);
+    if ( rc )
+    {
+        printk(XENLOG_WARNING "Failed allocating event channel for %pd\n",
+               d->d);
+        return rc;
+    }
+
+    *port = ec.port;
+    return 0;
+}
+
 static size_t __init domain_cmdline_size(const struct boot_info *bi,
                                          const struct boot_domain *bd)
 {
@@ -258,6 +282,8 @@ struct domain *__init arch_create_dom(
     if ( bd->domid == DOMID_INVALID )
         /* Create initial domain.  Not d0 for pvshim. */
         bd->domid = get_initial_domain_id();
+    if ( bd->capabilities & DOMAIN_CAPS_XENSTORE )
+        dom_cfg.flags |= XEN_DOMCTL_CDF_xs_domain;
     d = domain_create(bd->domid, &dom_cfg,
             ((bd->capabilities & DOMAIN_CAPS_CONTROL)  ? CDF_privileged : 0) |
             ((bd->capabilities & DOMAIN_CAPS_HARDWARE) ? CDF_hardware   : 0));
@@ -328,6 +354,36 @@ struct domain *__init arch_create_dom(
 
 int __init arch_builder_finalize(struct boot_info *bi)
 {
+    unsigned int i;
+    struct boot_domain *xs_bd = NULL;
+
+    i = first_boot_domain_index(bi, DOMAIN_CAPS_XENSTORE);
+    if ( i > MAX_NR_BOOTDOMS )
+        printk(XENLOG_WARNING "No xenstore domain configured\n");
+    else
+        xs_bd = &bi->domains[i];
+
+    for ( i = 0; i < bi->nr_domains; i++ )
+    {
+        struct boot_domain *bd = &bi->domains[i];
+
+        if ( xs_bd && xs_bd->d && (bd != xs_bd) && bd->xs_page )
+        {
+            evtchn_port_t xs_evtchn = 0;
+
+            if ( alloc_dom_evtchn(bd, xs_bd, &xs_evtchn) < 0 )
+                continue;
+
+            /* Is HVM/PVH */
+            if ( !(bd->mode & BUILD_MODE_PARAVIRT) )
+            {
+                uint64_t *params = bd->d->arch.hvm.params;
+                params[HVM_PARAM_STORE_PFN] = bd->xs_page;
+                params[HVM_PARAM_STORE_EVTCHN] = xs_evtchn;
+            }
+        }
+    }
+
     /* Free temporary buffers. */
     free_boot_modules();
 
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index 58fc40916df5..aec356cb2e46 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -20,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -896,6 +898,27 @@ static int __init pvh_load_kernel(
     return 0;
 }
 
+static int __init alloc_xenstore_page(struct boot_domain *bd)
+{
+    paddr_t xs_addr = special_pfn(SPECIALPAGE_XENSTORE) << PAGE_SHIFT;
+    uint32_t fields[7] = { 0, 0, 0, 0, 0, 1, 0};
+
+    /*
+     * Set connection field to XENSTORE_RECONNECT, the
+     * xenstore_domain_interface fields are located after the two 1024 buffers.
+     */
+    if ( hvm_copy_to_guest_phys(xs_addr + 2048, fields, sizeof(fields),
+                                bd->d->vcpu[0]) )
+    {
+        printk("Unable to set xenstore connection state\n");
+        return -EFAULT;
+    }
+
+    bd->xs_page = gfn_x(gaddr_to_gfn(xs_addr));
+
+    return 0;
+}
+
 int __init dom_construct_pvh(struct boot_domain *bd)
 {
     paddr_t entry, start_info;
@@ -972,6 +995,9 @@ int __init dom_construct_pvh(struct boot_domain *bd)
         return rc;
     }
 
+    if ( !is_xenstore_domain(bd->d) )
+        alloc_xenstore_page(bd);
+
     if ( opt_dom0_verbose )
     {
         printk("Dom%u memory map:\n", bd->domid);
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index c60b19c58aef..a527342768de 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 
 struct boot_domain {
     domid_t domid;
@@ -33,6 +34,8 @@ struct boot_domain {
     const char *cmdline;
 
     struct domain *d;
+
+    xen_pfn_t xs_page;
 };
 
 static inline bool __init has_dom0_caps(const struct boot_domain *bd)
diff --git a/xen/arch/x86/include/asm/domain-builder.h b/xen/arch/x86/include/asm/domain-builder.h
index 15a0e3b12c02..6ef4776faf9a 100644
--- a/xen/arch/x86/include/asm/domain-builder.h
+++ b/xen/arch/x86/include/asm/domain-builder.h
@@ -15,6 +15,8 @@ int hvm_steal_ram(
     struct domain *d, unsigned long size, unsigned long align, paddr_t limit,
     paddr_t *addr);
 
+int hvm_alloc_xenstore_page(struct boot_domain *bd, xen_pfn_t *xs_gfn);
+
 unsigned long dom_paging_pages(
     const struct boot_domain *d, unsigned long nr_pages);
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:35:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:35:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985568.1371538 (Exim 4.92)
	(envelope-from )
	id 1uFYkW-0004iH-Hx; Thu, 15 May 2025 13:35:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985568.1371538; Thu, 15 May 2025 13:35: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 1uFYkW-0004i4-DD; Thu, 15 May 2025 13:35:48 +0000
Received: by outflank-mailman (input) for mailman id 985568;
 Thu, 15 May 2025 13:35:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYZ7-0006hT-Bs
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:24:01 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dba7a068-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:23:59 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315209798429.1071845469214;
 Thu, 15 May 2025 06:20: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" 
X-Inumbo-ID: dba7a068-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315212; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=KGwhecJPrAyzXiI+rPL2Hgkpv+VCL4N7U/F9kNGD4XivV/Jx7sZYZj4YtGg4l2z8h9FHtF58kP9UDLHVNQp3oAwWJkqY1wO+DQ9yl5Ahi4kGdKKVPwoa9QMBEctDTEcbSxiBMEGmB9Ni6VOk1MtTYu4Srg4gajbTxIKbGyXdf2w=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315212; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=3Eyu8lLx+Tyc3aIxfZMaVPXRhgaSBDm19yKWfpBW1Pg=; 
	b=OfwDoneWbh6SnJgV24/faAS/UD9KBKwHL1WtU7L9Vqsw4KEEHBUSiALnlX52FxotTPeM8Ocbq3wH1J3xOztIQO3ono8ZW5XyzTjPZg1psAw7p3hvGGemvWi2j7P7kBwEN0nwogGI+Y/zG3yYMzHr7P+N7Qp+nngnd1tcBqAIZ3Q=
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=1747315212;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=3Eyu8lLx+Tyc3aIxfZMaVPXRhgaSBDm19yKWfpBW1Pg=;
	b=o0hySsnKfpvfqvjO0PDYx4W2AlUosmI0Vjd3/GZ730ciPyc6P8wPxjKWPk4g2Ikb
	w+fhj5DZIU8svle3EucU6wzMZtVRKeNz6NYD/tzR3S5sg9t8B286mRXsbus2yGY1eea
	dbSF/kxd+/0tkAWtOa1WqxE59wWBP+1aZd/YMiuo=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Christopher Clark 
Subject: [RFCv2 36/38] x86/hyperlaunch: enable unpausing mulitple domains
Date: Thu, 15 May 2025 09:19:48 -0400
Message-Id: <20250515131951.5594-7-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131951.5594-1-dpsmith@apertussolutions.com>
References: <20250515131951.5594-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

This commit enables the domain builder to unpause all domains
that have been flagged to start on boot.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/domain-builder/core.c     | 20 ++++++++++++++++++++
 xen/arch/x86/include/asm/boot-domain.h |  8 +++++---
 xen/arch/x86/setup.c                   |  8 +++++++-
 xen/include/xen/domain-builder.h       |  1 +
 4 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/domain-builder/core.c b/xen/arch/x86/domain-builder/core.c
index 367c0de33cfb..dbe547ff0a87 100644
--- a/xen/arch/x86/domain-builder/core.c
+++ b/xen/arch/x86/domain-builder/core.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -109,6 +110,25 @@ unsigned int __init builder_create_domains(struct boot_info *bi)
     return build_count;
 }
 
+int __init builder_unpause_domains(struct boot_info *bi)
+{
+    int i, count = 0;
+
+    for ( i = 0; i < bi->nr_domains; i++ )
+    {
+        struct boot_domain *bd = &bi->domains[i];
+
+        if ( bd->capabilities & DOMAIN_CAPS_HARDWARE ||
+             bd->mode & BUILD_MODE_START_ON_BOOT )
+        {
+            domain_unpause_by_systemcontroller(bd->d);
+            count++;
+        }
+    }
+
+    return count;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index 41246f31acce..b04d48010799 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -18,9 +18,11 @@ struct boot_domain {
     /* Bitmap. See DOMAIN_CAPS_MASK for a list */
     uint32_t capabilities;
 
-                                          /* On     | Off    */
-#define BUILD_MODE_PARAVIRT      (1 << 0) /* PV     | PVH/HVM */
-#define BUILD_MODE_ENABLE_DM     (1 << 1) /* HVM    | PVH     */
+                                          /* On       | Off     */
+#define BUILD_MODE_PARAVIRT      (1 << 0) /* PV       | PVH/HVM */
+#define BUILD_MODE_ENABLE_DM     (1 << 1) /* HVM      | PVH     */
+#define BUILD_MODE_LONG          (1 << 2) /* 64 BIT   | 32 BIT  */
+#define BUILD_MODE_START_ON_BOOT (1 << 3) /* UNPAUSED | PAUSED  */
     uint32_t mode;
 
     unsigned long mem_pages;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 422fef7ce02a..b55a1da9db91 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -790,6 +790,7 @@ static inline bool using_2M_mapping(void)
 
 static void noreturn init_done(void)
 {
+    struct boot_info *bi = &xen_boot_info;
     void *va;
     unsigned long start, end;
     int err;
@@ -803,7 +804,12 @@ static void noreturn init_done(void)
     if ( IS_ENABLED(CONFIG_SELF_TESTS) && cpu_has_xen_shstk )
         stub_selftest();
 
-    domain_unpause_by_systemcontroller(dom0);
+    err = builder_unpause_domains(bi);
+    if ( err == 0 )
+        panic("domain builder: failed to schedule any domain to start\n");
+    else
+        printk("domain builder: unpaused %d of %d domains at boot\n", err,
+               bi->nr_domains);
 
     /* MUST be done prior to removing .init data. */
     unregister_init_virtual_region();
diff --git a/xen/include/xen/domain-builder.h b/xen/include/xen/domain-builder.h
index ca9d9032b35b..eb8f5773b17e 100644
--- a/xen/include/xen/domain-builder.h
+++ b/xen/include/xen/domain-builder.h
@@ -46,5 +46,6 @@ struct domain *arch_create_dom(
 int arch_builder_finalize(struct boot_info *bi);
 
 unsigned int builder_create_domains(struct boot_info *bi);
+int builder_unpause_domains(struct boot_info *bi);
 
 #endif /* __XEN_DOMAIN_BUILDER_H__ */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:36:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:36:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985607.1371556 (Exim 4.92)
	(envelope-from )
	id 1uFYle-0006Hj-0o; Thu, 15 May 2025 13:36:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985607.1371556; Thu, 15 May 2025 13:36:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFYld-0006Hc-U9; Thu, 15 May 2025 13:36:57 +0000
Received: by outflank-mailman (input) for mailman id 985607;
 Thu, 15 May 2025 13:36:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYWb-0006hT-18
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:21:25 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7e38fbc0-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:21:23 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315167326469.1984760802285;
 Thu, 15 May 2025 06:19: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" 
X-Inumbo-ID: 7e38fbc0-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315170; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=LIsiTvus/7lIraYv5/5ONUaDCFUkuH2L1DIcFZTZFp7EJlLMnBiXXqORM4DLbY2OJPMhrhCsrv3VdAsEhzkI7MQ33ThOBKizpSzengq5hHGDhNEf6LyUZa8EGpEIPWa5opvDI0qVAKGnJiVxu/JN4TdFmVXAjCKs+LPTv6DRCVg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315170; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=pjzso79b1Hh0AD35a0okYSWdf+zqgRgxBJl4x7g9TJo=; 
	b=Mm6xg7jCOPEVSaysYrIOaCG3PDwE3/m0LYswKXIH42rXJ3IH/191Hw3Hfw5TbDpnE+ks0MJjUgFVyDFP89wZD78R606iw066EX1HPPsSFRXGHOibBmROzQ2wuawxMg+7vv0bhWxUU/opB190xrufkXiCpF7SGa4HCbp5k85yDN8=
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=1747315170;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=pjzso79b1Hh0AD35a0okYSWdf+zqgRgxBJl4x7g9TJo=;
	b=cG5QLHNVAvYDp613eb054D+IEWGxvw0daNkoUv7jK2xHa96ChXvcGJRMtaVD3nSi
	VwbIWjRegL6LoZS3tdh25BF/DlrraXHyKHZPd2PUSwBvnAQ0fEctyd7eiZSzf/tS2qg
	y7tL5p1VcX26JTcBTm4ZgDBh1cRkBrRGsCipOcXA=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 20/38] x86/hyperlaunch: move remaining pvh dom0 construction
Date: Thu, 15 May 2025 09:19:03 -0400
Message-Id: <20250515131912.5019-1-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Move pvh_load_kernel() and its helper functions to the domain builder. With
this move, it is now possible to move the remaining logic of
dom0_construct_pvh() to the domain builder. With all the logic moved, the
function can be dropped.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/hvm/dom0_build.c         | 364 --------------------------
 xen/arch/x86/hvm/dom_build.c          | 361 ++++++++++++++++++++++++-
 xen/arch/x86/include/asm/dom0_build.h |   1 -
 3 files changed, 360 insertions(+), 366 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 36d2e7e13948..ffe198d94d9e 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -479,334 +479,6 @@ int __init dom0_pvh_populate_p2m(struct domain *d)
 #undef MB1_PAGES
 }
 
-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);
-    unsigned int i;
-
-    /*
-     * The memory map is sorted and all RAM regions starts and sizes are
-     * aligned to page boundaries.
-     */
-    for ( i = 0; i < d->arch.nr_e820; i++ )
-    {
-        paddr_t start, end = d->arch.e820[i].addr + d->arch.e820[i].size;
-
-        /* Don't use memory below 1MB, as it could overwrite BDA/EBDA/IBFT. */
-        if ( end <= MB(1) || d->arch.e820[i].type != E820_RAM )
-            continue;
-
-        start = MAX(ROUNDUP(d->arch.e820[i].addr, PAGE_SIZE), MB(1));
-
-        ASSERT(IS_ALIGNED(start, PAGE_SIZE) && IS_ALIGNED(end, 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;
-    }
-
-    return INVALID_PADDR;
-}
-
-static bool __init check_load_address(
-    const struct domain *d, const struct elf_binary *elf)
-{
-    paddr_t kernel_start = (uintptr_t)elf->dest_base;
-    paddr_t kernel_end = kernel_start + elf->dest_size;
-    unsigned int i;
-
-    /* Relies on a sorted memory map with adjacent entries merged. */
-    for ( i = 0; i < d->arch.nr_e820; i++ )
-    {
-        paddr_t start = d->arch.e820[i].addr;
-        paddr_t end = start + d->arch.e820[i].size;
-
-        if ( start >= kernel_end )
-            return false;
-
-        if ( d->arch.e820[i].type == E820_RAM &&
-             start <= kernel_start &&
-             end >= kernel_end )
-            return true;
-    }
-
-    return false;
-}
-
-/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
-static paddr_t __init find_kernel_memory(
-    const struct domain *d, struct elf_binary *elf,
-    const struct elf_dom_parms *parms)
-{
-    paddr_t kernel_size = elf->dest_size;
-    unsigned int align;
-    unsigned int i;
-
-    if ( parms->phys_align != UNSET_ADDR32 )
-        align = parms->phys_align;
-    else if ( elf->palign >= PAGE_SIZE )
-        align = elf->palign;
-    else
-        align = MB(2);
-
-    /* Search backwards to find the highest address. */
-    for ( i = d->arch.nr_e820; i--; )
-    {
-        paddr_t start = d->arch.e820[i].addr;
-        paddr_t end = start + d->arch.e820[i].size;
-        paddr_t kstart, kend;
-
-        if ( d->arch.e820[i].type != E820_RAM ||
-             d->arch.e820[i].size < kernel_size )
-            continue;
-
-        if ( start > parms->phys_max )
-            continue;
-
-        if ( end - 1 > parms->phys_max )
-            end = parms->phys_max + 1;
-
-        kstart = (end - kernel_size) & ~(align - 1);
-        kend = kstart + kernel_size;
-
-        if ( kstart < parms->phys_min )
-            return 0;
-
-        if ( kstart >= start && kend <= end )
-            return kstart;
-    }
-
-    return 0;
-}
-
-/* Check the kernel load address, and adjust if necessary and possible. */
-static bool __init check_and_adjust_load_address(
-    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
-{
-    paddr_t reloc_base;
-
-    if ( check_load_address(d, elf) )
-        return true;
-
-    if ( !parms->phys_reloc )
-    {
-        printk("%pd kernel: Address conflict and not relocatable\n", d);
-        return false;
-    }
-
-    reloc_base = find_kernel_memory(d, elf, parms);
-    if ( !reloc_base )
-    {
-        printk("%pd kernel: Failed find a load address\n", d);
-        return false;
-    }
-
-    if ( opt_dom0_verbose )
-        printk("%pd kernel: Moving [%p, %p] -> [%"PRIpaddr", %"PRIpaddr"]\n", d,
-               elf->dest_base, elf->dest_base + elf->dest_size - 1,
-               reloc_base, reloc_base + elf->dest_size - 1);
-
-    parms->phys_entry =
-        reloc_base + (parms->phys_entry - (uintptr_t)elf->dest_base);
-    elf->dest_base = (char *)reloc_base;
-
-    return true;
-}
-
-static int __init pvh_load_kernel(
-    const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
-{
-    struct domain *d = bd->d;
-    struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->ramdisk;
-    void *image_base = bootstrap_map_bm(image);
-    void *image_start = image_base + image->headroom;
-    unsigned long image_len = image->size;
-    unsigned long initrd_len = initrd ? initrd->size : 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 )
-    {
-        printk("Error trying to detect bz compressed kernel\n");
-        return rc;
-    }
-
-    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 )
-    {
-        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));
-        return rc;
-    }
-
-    if ( parms.phys_entry == UNSET_ADDR32 )
-    {
-        printk("Unable to find XEN_ELFNOTE_PHYS32_ENTRY address\n");
-        return -EINVAL;
-    }
-
-    /* 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;
-
-    if ( !check_and_adjust_load_address(d, &elf, &parms) )
-        return -ENOSPC;
-
-    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));
-        return rc;
-    }
-
-    /*
-     * 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.
-     */
-    extra_space = sizeof(start_info);
-
-    if ( initrd )
-    {
-        size_t initrd_space = elf_round_up(&elf, initrd_len);
-
-        if ( initrd->cmdline_pa )
-        {
-            initrd_cmdline = __va(initrd->cmdline_pa);
-            if ( !*initrd_cmdline )
-                initrd_cmdline = NULL;
-        }
-        if ( initrd_cmdline )
-            initrd_space += strlen(initrd_cmdline) + 1;
-
-        if ( initrd_space )
-            extra_space += ROUNDUP(initrd_space, PAGE_SIZE) + sizeof(mod);
-        else
-            initrd = NULL;
-    }
-
-    extra_space += elf_round_up(&elf, cmdline_len);
-
-    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");
-        return -ENOMEM;
-    }
-
-    if ( initrd != NULL )
-    {
-        rc = hvm_copy_to_guest_phys(last_addr, __va(initrd->start),
-                                    initrd_len, v);
-        if ( rc )
-        {
-            printk("Unable to copy initrd to guest\n");
-            return rc;
-        }
-
-        mod.paddr = last_addr;
-        mod.size = initrd_len;
-        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();
-
-    rc = hvm_copy_to_guest_phys(last_addr, bd->cmdline, cmdline_len, v);
-    if ( rc )
-    {
-        printk("Unable to copy guest command line\n");
-        return rc;
-    }
-
-    start_info.cmdline_paddr = cmdline_len ? last_addr : 0;
-
-    /*
-     * 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);
-
-    if ( initrd != NULL )
-    {
-        rc = hvm_copy_to_guest_phys(last_addr, &mod, sizeof(mod), v);
-        if ( rc )
-        {
-            printk("Unable to copy guest modules\n");
-            return rc;
-        }
-        start_info.modlist_paddr = last_addr;
-        start_info.nr_modules = 1;
-        last_addr += sizeof(mod);
-    }
-
-    start_info.magic = XEN_HVM_START_MAGIC_VALUE;
-    start_info.flags = SIF_PRIVILEGED | SIF_INITDOMAIN;
-    rc = hvm_copy_to_guest_phys(last_addr, &start_info, sizeof(start_info), v);
-    if ( rc )
-    {
-        printk("Unable to copy start info to guest\n");
-        return rc;
-    }
-
-    *entry = parms.phys_entry;
-    *start_info_addr = last_addr;
-
-    return 0;
-}
-
 static int __init cf_check acpi_count_intr_ovr(
     struct acpi_subtable_header *header, const unsigned long end)
 {
@@ -1255,42 +927,6 @@ int __init dom0_pvh_setup_acpi(struct domain *d, paddr_t start_info)
     return 0;
 }
 
-int __init dom0_construct_pvh(struct boot_domain *bd)
-{
-    paddr_t entry, start_info;
-    struct domain *d = bd->d;
-    int rc;
-
-    rc = pvh_load_kernel(bd, &entry, &start_info);
-    if ( rc )
-    {
-        printk("Failed to load Dom0 kernel\n");
-        return rc;
-    }
-
-    rc = hvm_setup_cpus(bd->d, entry, start_info);
-    if ( rc )
-    {
-        printk("Failed to setup Dom0 CPUs: %d\n", rc);
-        return rc;
-    }
-
-    rc = dom0_pvh_setup_acpi(bd->d, start_info);
-    if ( rc )
-    {
-        printk("Failed to setup Dom0 ACPI tables: %d\n", 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;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index 4bbd5d2b8e24..bf361ba3f3f6 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -17,10 +17,12 @@
 
 #include 
 
+#include 
 #include 
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -277,8 +279,337 @@ static int __init hvm_populate_p2m(struct domain *d)
     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);
+    unsigned int i;
+
+    /*
+     * The memory map is sorted and all RAM regions starts and sizes are
+     * aligned to page boundaries.
+     */
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        paddr_t start, end = d->arch.e820[i].addr + d->arch.e820[i].size;
+
+        /* Don't use memory below 1MB, as it could overwrite BDA/EBDA/IBFT. */
+        if ( end <= MB(1) || d->arch.e820[i].type != E820_RAM )
+            continue;
+
+        start = MAX(ROUNDUP(d->arch.e820[i].addr, PAGE_SIZE), MB(1));
+
+        ASSERT(IS_ALIGNED(start, PAGE_SIZE) && IS_ALIGNED(end, 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;
+    }
+
+    return INVALID_PADDR;
+}
+
+static bool __init check_load_address(
+    const struct domain *d, const struct elf_binary *elf)
+{
+    paddr_t kernel_start = (uintptr_t)elf->dest_base;
+    paddr_t kernel_end = kernel_start + elf->dest_size;
+    unsigned int i;
+
+    /* Relies on a sorted memory map with adjacent entries merged. */
+    for ( i = 0; i < d->arch.nr_e820; i++ )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = start + d->arch.e820[i].size;
+
+        if ( start >= kernel_end )
+            return false;
+
+        if ( d->arch.e820[i].type == E820_RAM &&
+             start <= kernel_start &&
+             end >= kernel_end )
+            return true;
+    }
+
+    return false;
+}
+
+/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
+static paddr_t __init find_kernel_memory(
+    const struct domain *d, struct elf_binary *elf,
+    const struct elf_dom_parms *parms)
+{
+    paddr_t kernel_size = elf->dest_size;
+    unsigned int align;
+    unsigned int i;
+
+    if ( parms->phys_align != UNSET_ADDR32 )
+        align = parms->phys_align;
+    else if ( elf->palign >= PAGE_SIZE )
+        align = elf->palign;
+    else
+        align = MB(2);
+
+    /* Search backwards to find the highest address. */
+    for ( i = d->arch.nr_e820; i--; )
+    {
+        paddr_t start = d->arch.e820[i].addr;
+        paddr_t end = start + d->arch.e820[i].size;
+        paddr_t kstart, kend;
+
+        if ( d->arch.e820[i].type != E820_RAM ||
+             d->arch.e820[i].size < kernel_size )
+            continue;
+
+        if ( start > parms->phys_max )
+            continue;
+
+        if ( end - 1 > parms->phys_max )
+            end = parms->phys_max + 1;
+
+        kstart = (end - kernel_size) & ~(align - 1);
+        kend = kstart + kernel_size;
+
+        if ( kstart < parms->phys_min )
+            return 0;
+
+        if ( kstart >= start && kend <= end )
+            return kstart;
+    }
+
+    return 0;
+}
+
+/* Check the kernel load address, and adjust if necessary and possible. */
+static bool __init check_and_adjust_load_address(
+    const struct domain *d, struct elf_binary *elf, struct elf_dom_parms *parms)
+{
+    paddr_t reloc_base;
+
+    if ( check_load_address(d, elf) )
+        return true;
+
+    if ( !parms->phys_reloc )
+    {
+        printk("%pd kernel: Address conflict and not relocatable\n", d);
+        return false;
+    }
+
+    reloc_base = find_kernel_memory(d, elf, parms);
+    if ( !reloc_base )
+    {
+        printk("%pd kernel: Failed find a load address\n", d);
+        return false;
+    }
+
+    if ( opt_dom0_verbose )
+        printk("%pd kernel: Moving [%p, %p] -> [%"PRIpaddr", %"PRIpaddr"]\n", d,
+               elf->dest_base, elf->dest_base + elf->dest_size - 1,
+               reloc_base, reloc_base + elf->dest_size - 1);
+
+    parms->phys_entry =
+        reloc_base + (parms->phys_entry - (uintptr_t)elf->dest_base);
+    elf->dest_base = (char *)reloc_base;
+
+    return true;
+}
+
+static int __init pvh_load_kernel(
+    const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
+{
+    struct domain *d = bd->d;
+    struct boot_module *image = bd->kernel;
+    struct boot_module *initrd = bd->ramdisk;
+    void *image_base = bootstrap_map_bm(image);
+    void *image_start = image_base + image->headroom;
+    unsigned long image_len = image->size;
+    unsigned long initrd_len = initrd ? initrd->size : 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 )
+    {
+        printk("Error trying to detect bz compressed kernel\n");
+        return rc;
+    }
+
+    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 )
+    {
+        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));
+        return rc;
+    }
+
+    if ( parms.phys_entry == UNSET_ADDR32 )
+    {
+        printk("Unable to find XEN_ELFNOTE_PHYS32_ENTRY address\n");
+        return -EINVAL;
+    }
+
+    /* 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;
+
+    if ( !check_and_adjust_load_address(d, &elf, &parms) )
+        return -ENOSPC;
+
+    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));
+        return rc;
+    }
+
+    /*
+     * 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.
+     */
+    extra_space = sizeof(start_info);
+
+    if ( initrd )
+    {
+        size_t initrd_space = elf_round_up(&elf, initrd_len);
+
+        if ( initrd->cmdline_pa )
+        {
+            initrd_cmdline = __va(initrd->cmdline_pa);
+            if ( !*initrd_cmdline )
+                initrd_cmdline = NULL;
+        }
+        if ( initrd_cmdline )
+            initrd_space += strlen(initrd_cmdline) + 1;
+
+        if ( initrd_space )
+            extra_space += ROUNDUP(initrd_space, PAGE_SIZE) + sizeof(mod);
+        else
+            initrd = NULL;
+    }
+
+    extra_space += elf_round_up(&elf, cmdline_len);
+
+    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");
+        return -ENOMEM;
+    }
+
+    if ( initrd != NULL )
+    {
+        rc = hvm_copy_to_guest_phys(last_addr, __va(initrd->start),
+                                    initrd_len, v);
+        if ( rc )
+        {
+            printk("Unable to copy initrd to guest\n");
+            return rc;
+        }
+
+        mod.paddr = last_addr;
+        mod.size = initrd_len;
+        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();
+
+    rc = hvm_copy_to_guest_phys(last_addr, bd->cmdline, cmdline_len, v);
+    if ( rc )
+    {
+        printk("Unable to copy guest command line\n");
+        return rc;
+    }
+
+    start_info.cmdline_paddr = cmdline_len ? last_addr : 0;
+
+    /*
+     * 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);
+
+    if ( initrd != NULL )
+    {
+        rc = hvm_copy_to_guest_phys(last_addr, &mod, sizeof(mod), v);
+        if ( rc )
+        {
+            printk("Unable to copy guest modules\n");
+            return rc;
+        }
+        start_info.modlist_paddr = last_addr;
+        start_info.nr_modules = 1;
+        last_addr += sizeof(mod);
+    }
+
+    start_info.magic = XEN_HVM_START_MAGIC_VALUE;
+    start_info.flags = SIF_PRIVILEGED | SIF_INITDOMAIN;
+    rc = hvm_copy_to_guest_phys(last_addr, &start_info, sizeof(start_info), v);
+    if ( rc )
+    {
+        printk("Unable to copy start info to guest\n");
+        return rc;
+    }
+
+    *entry = parms.phys_entry;
+    *start_info_addr = last_addr;
+
+    return 0;
+}
+
 int __init dom_construct_pvh(struct boot_domain *bd)
 {
+    paddr_t entry, start_info;
     int rc;
 
     printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", bd->domid);
@@ -328,7 +659,35 @@ int __init dom_construct_pvh(struct boot_domain *bd)
         return rc;
     }
 
-    return dom0_construct_pvh(bd);
+    rc = pvh_load_kernel(bd, &entry, &start_info);
+    if ( rc )
+    {
+        printk("Failed to load Dom0 kernel\n");
+        return rc;
+    }
+
+    rc = hvm_setup_cpus(bd->d, entry, start_info);
+    if ( rc )
+    {
+        printk("Failed to setup Dom0 CPUs: %d\n", rc);
+        return rc;
+    }
+
+    rc = dom0_pvh_setup_acpi(bd->d, start_info);
+    if ( rc )
+    {
+        printk("Failed to setup Dom0 ACPI tables: %d\n", rc);
+        return rc;
+    }
+
+    if ( opt_dom0_verbose )
+    {
+        printk("Dom%u memory map:\n", bd->domid);
+        print_e820_memory_map(bd->d->arch.e820, bd->d->arch.nr_e820);
+    }
+
+    printk("WARNING: PVH is an experimental mode with limited functionality\n");
+    return 0;
 }
 
 /*
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index 3819b3f4e7a4..6947aaa1dce3 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -24,7 +24,6 @@ int dom0_pvh_setup_acpi(struct domain *d, paddr_t start_info);
 int dom0_pvh_populate_p2m(struct domain *d);
 
 int dom0_construct_pv(struct boot_domain *bd);
-int dom0_construct_pvh(struct boot_domain *bd);
 
 void dom0_update_physmap(bool compat, unsigned long pfn,
                          unsigned long mfn, unsigned long vphysmap_s);
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:38:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:38:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985626.1371567 (Exim 4.92)
	(envelope-from )
	id 1uFYmp-00078B-Et; Thu, 15 May 2025 13:38:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985626.1371567; Thu, 15 May 2025 13:38: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 1uFYmp-000784-BT; Thu, 15 May 2025 13:38:11 +0000
Received: by outflank-mailman (input) for mailman id 985626;
 Thu, 15 May 2025 13:38:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYYq-0006hT-Cx
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:23:44 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d15f04a2-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:23:42 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 174731520685435.04435821717914;
 Thu, 15 May 2025 06:20:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d15f04a2-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315210; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=Kxcq2eaFIHbcjQbUBLOECM9KYNss9ShGDJq16IPwqbpAVv0V9uJx8ACTSHG973hAVhm5jYYY8MufnWrMN4DlQq17ZpNsn73UfGvfcpYqI0UG4lnHYYhZo2vxf6kmAgk1Ka7QKt9A0mTqK55jCb7Jfp5FxuG6h/vEEqbotgrVcjM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315210; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=96dkUqvgm/7UIRL7jRGOzfsQUACLFlErwk/VB4OugJM=; 
	b=TQN0GsXSjDaRuXgqpHOVnBug9+0dD9GGj2RNkw57uZ9fiuj1Am6nYkSCLqwKl6JZy6Db2o4JYMohzI3A8iuwXYN1U4L8YfGVq5vleP26GpzXvpsYvTLyZJ8tpSemq+lNxw9I9kkaGaXFE2OCKeay5sqeAk5OyE06/3ErWGA4nQ4=
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=1747315210;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=96dkUqvgm/7UIRL7jRGOzfsQUACLFlErwk/VB4OugJM=;
	b=Od1+a5Mxbc8jzMsajg+SwvQNiVcFgESgXxOBa1EtBzPY2dBaWbppSTCr1u5+bXsv
	QJMEZrx+w62sYRcaNBt/zFs7uTTI/dwoH42BVKa010EAlXIoEta22NYwoNJ3Oypy1H9
	dBhBbNaZ8Ol18VxnNSfQKhLiEzCNavdxsCaHoltg=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [RFCv2 33/38] x86/hyperlaunch: move kernel extraction under domain builder
Date: Thu, 15 May 2025 09:19:45 -0400
Message-Id: <20250515131951.5594-4-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131951.5594-1-dpsmith@apertussolutions.com>
References: <20250515131951.5594-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The function bzimage_parse attempted to prepare the kernel image for copying
into the guest for all supported kernel types, not just bzImage. The result was
convoluted logic to handle three kernel image types, and then within the
bzImage type, also handle three types of payloads.

This commit moves the generalized kernel preparation for the three kernel types
to the domain builder. It descopes bziamge_parse to only handling bzImages.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/bzimage.c                    | 34 ++++++++++-------------
 xen/arch/x86/domain-builder/domain.c      | 30 ++++++++++++++++++++
 xen/arch/x86/hvm/dom_build.c              |  3 +-
 xen/arch/x86/include/asm/bzimage.h        |  5 ++--
 xen/arch/x86/include/asm/domain-builder.h |  3 ++
 xen/arch/x86/pv/dom0_build.c              |  4 ++-
 6 files changed, 55 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c
index ba090b3ef9d6..65ee0eef029a 100644
--- a/xen/arch/x86/bzimage.c
+++ b/xen/arch/x86/bzimage.c
@@ -66,8 +66,6 @@ int __init bzimage_check(void *image, unsigned long len)
     return 1;
 }
 
-static unsigned long __initdata orig_image_len;
-
 unsigned long __init bzimage_headroom(void *image_start,
                                       unsigned long image_length)
 {
@@ -77,7 +75,6 @@ unsigned long __init bzimage_headroom(void *image_start,
     image_start += (hdr->setup_sects + 1) * 512 + hdr->payload_offset;
     image_length = hdr->payload_length;
 
-    orig_image_len = image_length;
     /* Linux build system mimics gzip isize field for bzip2/lzma algos */
     headroom = gzip_isize(image_start, image_length);
     /*
@@ -96,31 +93,28 @@ unsigned long __init bzimage_headroom(void *image_start,
     return ROUNDUP(headroom, PAGE_SIZE);
 }
 
-int __init bzimage_parse(void *image_base, void **image_start,
-                         unsigned long *image_len)
+int __init bzimage_parse(
+    void *image_base, void **image_start, unsigned long headroom,
+    unsigned long *image_len)
 {
     struct setup_header *hdr = (struct setup_header *)(*image_start);
-    int err = bzimage_check(hdr, *image_len);
+    int err = 0;
     unsigned long output_len;
 
-    if ( err < 0 )
-        return err;
-
-    if ( err > 0 )
-    {
-        *image_start += (hdr->setup_sects + 1) * 512 + hdr->payload_offset;
-        *image_len = hdr->payload_length;
-    }
+    *image_start += (hdr->setup_sects + 1) * 512 + hdr->payload_offset;
+    *image_len = hdr->payload_length;
 
     if ( elf_is_elfbinary(*image_start, *image_len) )
-        return 0;
+        return err;
 
-    BUG_ON(!(image_base < *image_start));
+    output_len = gzip_isize(*image_start, *image_len);
 
-    output_len = gzip_isize(*image_start, orig_image_len);
+    BUG_ON(!(image_base < *image_start));
 
-    if ( (err = perform_gunzip(image_base, *image_start, orig_image_len)) > 0 )
-        err = decompress(*image_start, orig_image_len, image_base);
+    if ( gzip_check(*image_start, *image_len) )
+        err = perform_gunzip(image_base, *image_start, *image_len);
+    else
+        err = decompress(*image_start, *image_len, image_base);
 
     if ( !err )
     {
@@ -128,7 +122,7 @@ int __init bzimage_parse(void *image_base, void **image_start,
         *image_len = output_len;
     }
 
-    return err > 0 ? 0 : err;
+    return err;
 }
 
 /*
diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index 9c2f30eee8bd..deff6c8efaf1 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -271,6 +271,36 @@ void __init arch_builder_headroom(struct boot_domain *bd)
     bootstrap_unmap();
 }
 
+int __init arch_builder_prepare_kernel(
+    void *image_base, void **image_start, unsigned long headroom,
+    unsigned long *image_len)
+{
+    int rc = 0;
+
+    *image_start = image_base + headroom;
+    *image_len -= headroom;
+
+    if ( bzimage_check(*image_start, *image_len) )
+        rc = bzimage_parse(image_base, image_start, headroom, image_len);
+    else if ( gzip_check(*image_start, *image_len) )
+    {
+        unsigned long len = gzip_isize(*image_start, *image_len);
+        rc = perform_gunzip(image_base, *image_start, *image_len);
+        if ( !rc )
+        {
+            *image_start = image_base;
+            *image_len = len;
+        }
+    }
+    else if ( elf_is_elfbinary(*image_start, *image_len) )
+        rc = 0;
+    else
+        rc = -EINVAL;
+
+    return rc;
+}
+
+
 struct domain *__init arch_create_dom(
     struct boot_info *bi, struct boot_domain *bd)
 {
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index 3eab97b5288b..170caac6716e 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -745,7 +745,8 @@ static int __init pvh_load_kernel(
     struct vcpu *v = d->vcpu[0];
     int rc;
 
-    if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
+    if ( (rc = arch_builder_prepare_kernel(image_base, &image_start,
+                                           image->headroom, &image_len)) != 0 )
     {
         printk("Error trying to detect bz compressed kernel\n");
         return rc;
diff --git a/xen/arch/x86/include/asm/bzimage.h b/xen/arch/x86/include/asm/bzimage.h
index c3a042f177ac..ebe4f9325c4f 100644
--- a/xen/arch/x86/include/asm/bzimage.h
+++ b/xen/arch/x86/include/asm/bzimage.h
@@ -6,7 +6,8 @@
 int bzimage_check(void *image, unsigned long len);
 unsigned long bzimage_headroom(void *image_start, unsigned long image_length);
 
-int bzimage_parse(void *image_base, void **image_start,
-                  unsigned long *image_len);
+int bzimage_parse(
+    void *image_base, void **image_start, unsigned long headroom,
+    unsigned long *image_len);
 
 #endif /* __X86_BZIMAGE_H__ */
diff --git a/xen/arch/x86/include/asm/domain-builder.h b/xen/arch/x86/include/asm/domain-builder.h
index f1749d2786c6..3adeadc15423 100644
--- a/xen/arch/x86/include/asm/domain-builder.h
+++ b/xen/arch/x86/include/asm/domain-builder.h
@@ -21,6 +21,9 @@ unsigned long dom_paging_pages(
     const struct boot_domain *d, unsigned long nr_pages);
 
 void arch_builder_headroom(struct boot_domain *bd);
+int arch_builder_prepare_kernel(
+    void *image_base, void **image_start, unsigned long headroom,
+    unsigned long *image_len);
 
 unsigned long dom_compute_nr_pages(
     struct boot_domain *bd, struct elf_dom_parms *parms);
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 21cb0b11748e..72319c31fa0e 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -428,7 +428,9 @@ static int __init dom0_construct(struct boot_domain *bd)
 
     d->max_pages = ~0U;
 
-    if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
+    if ( (rc = arch_builder_prepare_kernel(image_base, &image_start,
+                                           bd->kernel->headroom,
+                                           &image_len)) != 0 )
         return rc;
 
     if ( (rc = elf_init(&elf, image_start, image_len)) != 0 )
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:39:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:39:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985641.1371577 (Exim 4.92)
	(envelope-from )
	id 1uFYnp-0007tK-Oj; Thu, 15 May 2025 13:39:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985641.1371577; Thu, 15 May 2025 13:39: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 1uFYnp-0007tD-M7; Thu, 15 May 2025 13:39:13 +0000
Received: by outflank-mailman (input) for mailman id 985641;
 Thu, 15 May 2025 13:39:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYXT-0006hT-Ug
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:22:19 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9f1ba848-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:22:18 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315173142393.942667038713;
 Thu, 15 May 2025 06:19:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9f1ba848-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315176; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=NZBxKFLc6I/FFdo2eQajsV65yLItatKjMNG2BsTPPE5xNCLxYj9XvxDGsvcWK4CL4bTlvYjLXRzqHX7idrc8ztSdd+uAM7E0wCLQrPNmx79GhwbYvcMOu/0ep91baAJHa1S71f6NngSjtzZknjQvtS323PTUsPLk/0tMGyveIj8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315176; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=dok5mCKGcvhcJcoUDY82s5z4bmExib11eYAieKaC4x4=; 
	b=ZtUrLxSywqzIrWxm8OZ/RuyXCrnIxLhgSyFhLNUdTrXBSgycmgPYTn6TPaE6LONGY/CdR96uWcpzbvBFp+K9dmYm8wSvZGVJGWjHqqXP9HkPkD8TYDJCHxILkWXEj9nV09Y/qsHDNFzewwLvu97Irz5EJNJBrEXR5Jvt45DtA0k=
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=1747315176;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=dok5mCKGcvhcJcoUDY82s5z4bmExib11eYAieKaC4x4=;
	b=IXP6sts2bp2m053tZO4YXzfDi3sf5C2DPWtoqKaiSTCmv9hZH97/hZYi+zw4emE7
	vwxNnYv+zywE/nnVt1cq5UdJMbDe6LqIWuePJZ7vp9D2uXkCJMFJlr8t5h+3BuyIz3E
	67OHIZ4GIA/e0Qz98FxtOPrgZ2+QQQYbxn60SkBQ=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Christopher Clark 
Subject: [RFCv2 27/38] x86/hyperlaunch: introduce arch builder finalize
Date: Thu, 15 May 2025 09:19:10 -0400
Message-Id: <20250515131912.5019-8-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131912.5019-1-dpsmith@apertussolutions.com>
References: <20250515131912.5019-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

This commit introduces a per arch builder finalize method where all
post-construction finalization and cleanup can be handled. The call to discard
boot modules relocated from inside the two x86 domain construction paths to the
x86 domain builder finalize method. This will ensure modules are not discarded
until after all domains have been constructed.

Signed-off-by: Daniel P. Smith 

---

Changes since RFC v1:
- reworked the commit to introduce builder finalize
- renamed the commit to refelect builder finalize
---
 xen/arch/x86/domain-builder/core.c   | 2 ++
 xen/arch/x86/domain-builder/domain.c | 8 ++++++++
 xen/arch/x86/hvm/dom_build.c         | 3 ---
 xen/arch/x86/pv/dom0_build.c         | 3 ---
 xen/include/xen/domain-builder.h     | 2 ++
 5 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/domain-builder/core.c b/xen/arch/x86/domain-builder/core.c
index 3b315e59b188..4eaf3a111208 100644
--- a/xen/arch/x86/domain-builder/core.c
+++ b/xen/arch/x86/domain-builder/core.c
@@ -22,6 +22,8 @@ unsigned int __init builder_create_domains(struct boot_info *bi)
     if ( bd->d )
         build_count++;
 
+    arch_builder_finalize(bi);
+
     return build_count;
 }
 
diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/domain-builder/domain.c
index 2c01705ebe4f..5b03e3dce228 100644
--- a/xen/arch/x86/domain-builder/domain.c
+++ b/xen/arch/x86/domain-builder/domain.c
@@ -326,6 +326,14 @@ struct domain *__init arch_create_dom(
     return d;
 }
 
+int __init arch_builder_finalize(struct boot_info *bi)
+{
+    /* Free temporary buffers. */
+    free_boot_modules();
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/dom_build.c b/xen/arch/x86/hvm/dom_build.c
index e73a3950b30e..58fc40916df5 100644
--- a/xen/arch/x86/hvm/dom_build.c
+++ b/xen/arch/x86/hvm/dom_build.c
@@ -853,9 +853,6 @@ static int __init pvh_load_kernel(
         last_addr = ROUNDUP(last_addr, PAGE_SIZE);
     }
 
-    /* Free temporary buffers. */
-    free_boot_modules();
-
     rc = hvm_copy_to_guest_phys(last_addr, bd->cmdline, cmdline_len, v);
     if ( rc )
     {
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 195c0902d5a1..21cb0b11748e 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -866,9 +866,6 @@ static int __init dom0_construct(struct boot_domain *bd)
         init_hypercall_page(d, _p(parms.virt_hypercall));
     }
 
-    /* Free temporary buffers. */
-    free_boot_modules();
-
     /* Set up start info area. */
     si = (start_info_t *)vstartinfo_start;
     clear_page(si);
diff --git a/xen/include/xen/domain-builder.h b/xen/include/xen/domain-builder.h
index c26f670d4f66..ca9d9032b35b 100644
--- a/xen/include/xen/domain-builder.h
+++ b/xen/include/xen/domain-builder.h
@@ -43,6 +43,8 @@ void domain_vcpus_create(struct domain *d);
 struct domain *arch_create_dom(
     struct boot_info *bi, struct boot_domain *bd);
 
+int arch_builder_finalize(struct boot_info *bi);
+
 unsigned int builder_create_domains(struct boot_info *bi);
 
 #endif /* __XEN_DOMAIN_BUILDER_H__ */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 13:39:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 13:39:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985644.1371586 (Exim 4.92)
	(envelope-from )
	id 1uFYnw-0008BJ-VS; Thu, 15 May 2025 13:39:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985644.1371586; Thu, 15 May 2025 13: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 1uFYnw-0008BA-Sm; Thu, 15 May 2025 13:39:20 +0000
Received: by outflank-mailman (input) for mailman id 985644;
 Thu, 15 May 2025 13:39:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFYXA-0006hT-BB
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 13:22:00 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9369a08a-318f-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 15:21:58 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747315172286991.1892485678771;
 Thu, 15 May 2025 06:19: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" 
X-Inumbo-ID: 9369a08a-318f-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747315174; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=cpHNUiAY0CXjmYiDxn5XFLJkzsx4euGYMAwAntvWgZHSMVqu1SiN/JmNbWox+1Hr+n7+BaDHTAkQ0aUrt5O5jrRnXvma+PGiZc8nQD60tfF/pjJ+5TRzPenVx/sO/quoOpWdfc9BCkbdM7PXeQoEWcsn5lq0rtmvd4VBauPajVA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747315174; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=VOh8i0DwJY/ONOyYgGyBDIv1dAYbBsfMWmmDU6GMhcQ=; 
	b=YJopmnY5r4QbMcNLTv23ZUGN+Ic8qnGsM4fSN1uIqzS30MLxcefMnkyZej6WI+RMnZodr6oxBsNc4jizpAKedKT+ZEqo6e6Jgk5rOI7pS6dlJi/nR0c4tbbEARNtXqiMhXPIIZZznxjTVGwL3jANRsqOiZKISBJyLRC0xlK+e/w=
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=1747315174;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=VOh8i0DwJY/ONOyYgGyBDIv1dAYbBsfMWmmDU6GMhcQ=;
	b=L2hO5WThLR1QAwQZCfuboaJGAYqccttrrOgRSHX3yY+mXif6LkQl817BfbLW+6I7
	4Z4FbuG+qH3py7W16yTzPrV6m2HZoOsKbGcFkqN1kawlmnsP0dknjyzA/y6pz4pR7h3
	FuMYcyPkffA2C6/xJhvhC/jzJIrB7T2wWDfB9WXU=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	stefano.stabellini@amd.com,
	agarciav@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Christopher Clark 
Subject: [RFCv2 26/38] x86/hyperlaunch: introduce domain builder general dom creation
Date: Thu, 15 May 2025 09:19:09 -0400
Message-Id: <20250515131912.5019-7-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20250515131912.5019-1-dpsmith@apertussolutions.com>
References: <20250515131912.5019-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Introduce the builder_create_domains() function that provides the general
domain construction abstraction that selects between classic dom0 construction
and the hyperlaunch domain builder.

Signed-off-by: Daniel P. Smith 
---
 xen/arch/x86/domain-builder/Makefile |  1 +
 xen/arch/x86/domain-builder/core.c   | 36 ++++++++++++++++++++++++++++
 xen/arch/x86/include/asm/bootinfo.h  | 26 ++++++++++++++++++++
 xen/arch/x86/setup.c                 | 23 +++++++++++++++---
 xen/include/xen/domain-builder.h     |  2 ++
 5 files changed, 85 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/x86/domain-builder/core.c

diff --git a/xen/arch/x86/domain-builder/Makefile b/xen/arch/x86/domain-builder/Makefile
index 69a7c574a8d8..96040bf66a04 100644
--- a/xen/arch/x86/domain-builder/Makefile
+++ b/xen/arch/x86/domain-builder/Makefile
@@ -1 +1,2 @@
+obj-y += core.o
 obj-y += domain.o
diff --git a/xen/arch/x86/domain-builder/core.c b/xen/arch/x86/domain-builder/core.c
new file mode 100644
index 000000000000..3b315e59b188
--- /dev/null
+++ b/xen/arch/x86/domain-builder/core.c
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2025, Apertus Solutions, LLC
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+unsigned int __init builder_create_domains(struct boot_info *bi)
+{
+    unsigned int build_count = 0;
+    struct boot_domain *bd = &bi->domains[0];
+
+    if ( bd->capabilities & DOMAIN_CAPS_HARDWARE && bd->kernel == NULL )
+        panic("%s: hardware domain missing kernel\n", __func__);
+
+
+    arch_create_dom(bi, bd);
+    if ( bd->d )
+        build_count++;
+
+    return build_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/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 5b2c93b1ef9e..430ae08cf5ef 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -132,6 +132,32 @@ static inline unsigned int __init next_boot_module_index(
           (i) <= (b)->nr_modules;                       \
           (i) = next_boot_module_index(b, t, i + 1) )
 
+/*
+ * next_boot_domain_index:
+ *     Finds the next boot domain with capability cap, starting at array index
+ *     start.
+ *
+ * Returns:
+ *      Success - index in boot_domains array
+ *      Failure - a value greater than MAX_NR_BOOTDOMS
+ */
+static inline unsigned int __init next_boot_domain_index(
+    const struct boot_info *bi, uint32_t cap, unsigned int start)
+{
+    int i;
+
+    for ( i = start; i < bi->nr_domains; i++ )
+    {
+        if ( bi->domains[i].capabilities & cap )
+            return i;
+    }
+
+    return MAX_NR_BOOTDOMS + 1;
+}
+
+#define first_boot_domain_index(bi, cap)              \
+    next_boot_domain_index(bi, cap, 0)
+
 #endif /* X86_BOOTINFO_H */
 
 /*
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2458a43902e6..b2c7846be18f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -2026,9 +2026,26 @@ void asmlinkage __init noreturn __start_xen(void)
      * We're going to setup domain0 using the module(s) that we stashed safely
      * above our heap. The second module, if present, is an initrd ramdisk.
      */
-    dom0 = arch_create_dom(bi, &bi->domains[0]);
-    if ( !dom0 )
-        panic("Could not set up DOM0 guest OS\n");
+    ret = builder_create_domains(bi);
+    if ( ret <= 0 )
+        panic("Could not set up boot-time domains\n");
+    else
+        printk(XENLOG_INFO "Constructed %d boot-time domains\n", ret);
+
+    /* Selection order: hardware domain, control domain, first domain */
+    i = first_boot_domain_index(bi, DOMAIN_CAPS_HARDWARE);
+    if ( i >= MAX_NR_BOOTDOMS )
+    {
+        i = first_boot_domain_index(bi, DOMAIN_CAPS_CONTROL);
+        if ( i >= MAX_NR_BOOTDOMS )
+        {
+            printk(XENLOG_WARNING
+                   "A hwdom/ctrldom not detected, using 0th domain\n");
+            i = 0;
+        }
+    }
+
+    dom0 = bi->domains[i].d;
 
     heap_init_late();
 
diff --git a/xen/include/xen/domain-builder.h b/xen/include/xen/domain-builder.h
index a9df326682ac..c26f670d4f66 100644
--- a/xen/include/xen/domain-builder.h
+++ b/xen/include/xen/domain-builder.h
@@ -43,4 +43,6 @@ void domain_vcpus_create(struct domain *d);
 struct domain *arch_create_dom(
     struct boot_info *bi, struct boot_domain *bd);
 
+unsigned int builder_create_domains(struct boot_info *bi);
+
 #endif /* __XEN_DOMAIN_BUILDER_H__ */
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu May 15 14:39:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 14:39:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985692.1371597 (Exim 4.92)
	(envelope-from )
	id 1uFZk1-0000oV-7E; Thu, 15 May 2025 14:39:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985692.1371597; Thu, 15 May 2025 14:39: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 1uFZk1-0000oO-4Z; Thu, 15 May 2025 14:39:21 +0000
Received: by outflank-mailman (input) for mailman id 985692;
 Thu, 15 May 2025 14:39:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFZjz-0000nA-1X
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 14:39:20 +0000
Received: from 13.mo584.mail-out.ovh.net (13.mo584.mail-out.ovh.net
 [178.33.251.8]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5f55a715-319a-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 16:39:14 +0200 (CEST)
Received: from director8.ghost.mail-out.ovh.net (unknown [10.108.17.183])
 by mo584.mail-out.ovh.net (Postfix) with ESMTP id 4ZytBp0Cffz1XWN
 for ; Thu, 15 May 2025 14:39:13 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-qbmbj (unknown [10.111.182.20])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 9C1F81FEBD;
 Thu, 15 May 2025 14:39:11 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.101])
 by ghost-submission-5b5ff79f4f-qbmbj with ESMTPSA
 id lBGEFI/8JWh3AwEA6WhilQ
 (envelope-from ); Thu, 15 May 2025 14:39: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" 
X-Inumbo-ID: 5f55a715-319a-11f0-9eb6-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-101G0046098e410-b8c9-4abb-8407-df55a892e50a,
                    387E45D97A4461B8A9D628297587A76108926964) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.178
Date: Thu, 15 May 2025 17:39:05 +0300
From: Sergii Dmytruk 
To: Demi Marie Obenour 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	Nicola Vetrini ,
	Doug Goldstein ,
	"Daniel P. Smith" ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v2 20/22] x86/slaunch: support EFI boot
Message-ID: 
References: 
 
 <68e5f8bb-42b2-4da8-86ba-231cb5657106@gmail.com>
 
 <1ba433ce-44b6-4d70-a232-f5f83f1fbaf8@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1ba433ce-44b6-4d70-a232-f5f83f1fbaf8@gmail.com>
X-Ovh-Tracer-Id: 18199327573151233180
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdefuddtudefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpedttdeufffggfeuheevfeehieeijeekkeehheefjeejvdetjedvvdegkeevgedtffenucffohhmrghinhepthhrvghntghhsghoohhtrdhorhhgnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukedurddujeekpdefjedrheelrddugedvrddutddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekgegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=mALPy3UReUIH7bnvPUR5x/ZByWKTIsJbX7SfOPJTfdY=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747319954; v=1;
 b=duAciFfM5lzWmfq7+AS7of3ED1XIV3DFWBvbJ/z6jz0TNaUBmge5Uqw+ynw5ld93usbpo+G3
 AMmG2d/hqZJoyKhq+Yo36t1YubcOQDehI79Z6UrE5htULqY4iBo8JFPHIJNS1tZQ4oHIHwCWd6U
 RVF0q4zm7NA4LG8hf3cEceJabKFY0kUm3z9/cZixtwOgWSmPT17JCL/NFQUXW1+G3GGm1I5/uzj
 e+FsIeeDNasoISXO46Sv8TTlObOWtjTVfL0tOQSyy89kGuMtloX3BeSNjrILjEjRfmMRnDDApKI
 RrK0lWtE92lzwEhwuIWCB5YFnvr6qSauqbdLvNAPBmiXA==

On Wed, May 14, 2025 at 11:58:49AM -0400, Demi Marie Obenour wrote:
> On 5/14/25 10:24 AM, Sergii Dmytruk wrote:
> > On Tue, May 13, 2025 at 09:25:44PM -0400, Demi Marie Obenour wrote:
> >> On 5/13/25 1:05 PM, Sergii Dmytruk wrote:
> > That sentence in the commit message is worth rewording.  GRUB isn't a
> > requirement, any TrenchBoot-enabled bootloader (or anything that wants
> > to act as a bootloader) can be used.  systemd-boot could implement
> > Secure Launch specification [0] and start Xen/Linux/something else via
> > DRTM.  Usage without a real bootloader could be implemented similarly
> > via some EFI stub that has binaries embedded into it or that can load
> > them from a drive.
> >
> > Mind that at least Intel and AMD DRTM implementations require a DCE [1]
> > binary that depends on a vendor, firmware version or a CPU generation.
> > So even embedding all code into every kernel-like software won't produce
> > self-contained DRTM-capable images.
> >
> > [0]: https://trenchboot.org/specifications/Secure_Launch/
> > [1]: https://trenchboot.org/theory/Glossary/#dynamic-configuration-environment-dce
>
> Why is it better for Xen to rely on the bootloader to implement the
> specification, instead of xen.efi itself implementing secure launch?
> That would make secure launch significantly more usable.  For an
> initial implementation it makes sense to rely on the bootloader, but
> in the future it would be better for xen.efi to have its own
> implementation.

That specification is not exactly about DRTM, which is specified by CPU
vendors.  It's about an interface between what starts DRTM (a bootloader
in a broad sense) and what uses on it (kernels, hypervisors, etc.).  If
the whole process is performed by a single entity, there is no need
for the specification.

What starts DRTM needs to ensure the system supports DRTM and should
then put it in a state suitable for DRTM start.  What uses DRTM
needs to know much less and can heavily rely on the information from a
bootloader.  Ideally, Xen/Linux would be able to handle DRTM uniformly
on different hardware, but the reality is that abstracting away some
differences is nearly impossible.

> Is the code being added to GRUB for secure launch under a license
> that would allow it to be used in Xen as well?

GRUB's changes are GPL3-or-later, but that shouldn't be a problem,
authors will likely agree to relicense it as GPL2-or-later for Xen.

Regards


From xen-devel-bounces@lists.xenproject.org Thu May 15 15:27:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 15:27:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985744.1371607 (Exim 4.92)
	(envelope-from )
	id 1uFaUW-0004KK-Pb; Thu, 15 May 2025 15:27:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985744.1371607; Thu, 15 May 2025 15: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 1uFaUW-0004KD-Mw; Thu, 15 May 2025 15:27:24 +0000
Received: by outflank-mailman (input) for mailman id 985744;
 Thu, 15 May 2025 15:27:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFaUV-00046l-8t
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 15:27:23 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 17af7269-31a1-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 17:27:21 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id F421C5C5BC8;
 Thu, 15 May 2025 15:25:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id DFDA8C4CEE7;
 Thu, 15 May 2025 15:27: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" 
X-Inumbo-ID: 17af7269-31a1-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747322839;
	bh=wUTLgYYkilNyjrqWEPSf4YmaWt7G2OS/5f8TggVtdRU=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=om0/Zf9oiHVqLN0g5Kt02BQodrs6owd0Bp9mPs3280ydfOkMjNs6d/0BQXVBnRvRy
	 N3wuaoPa6ZbFG+RCk6e+VgdwKN/Io/tnCPkU4aMwslcaNM8/u6fXYJZsgp3j6rP5Hl
	 Xeu2i8CwYOQ6DFXKCmg79L6hRtHEe7h0laqaOySbmv5KG322vpDufDFP+skHwFAqgl
	 0wa4UL7aXfxKa9XMFgjZy0C82i6OZenxiRUQ+qjmnFbyfEZ+d8S3c9ffGQYdoiFtzZ
	 bQBBdD/+agD8A9+mMY1MXm6QeDMlSoYf7PO4WSTfzXkZVYyEjH2/Egg4lKb/Z9x5pH
	 WYcbEP5rOlD6w==
Date: Thu, 15 May 2025 17:27:13 +0200
From: Ingo Molnar 
To: "Xin Li (Intel)" 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
	rafael@kernel.org, lenb@kernel.org
Subject: Re: [PATCH v1 3/3] x86/msr: Convert a native_wrmsr() use to
 native_wrmsrq()
Message-ID: 
References: <20250512084552.1586883-1-xin@zytor.com>
 <20250512084552.1586883-4-xin@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250512084552.1586883-4-xin@zytor.com>


* Xin Li (Intel)  wrote:

> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
> conversions when a u64 MSR value is splitted into two u32.
> 
> Signed-off-by: Xin Li (Intel) 
> ---
>  arch/x86/coco/sev/core.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
> index ff82151f7718..b3ce6fc8b62d 100644
> --- a/arch/x86/coco/sev/core.c
> +++ b/arch/x86/coco/sev/core.c
> @@ -282,12 +282,7 @@ static inline u64 sev_es_rd_ghcb_msr(void)
>  
>  static __always_inline void sev_es_wr_ghcb_msr(u64 val)
>  {
> -	u32 low, high;
> -
> -	low  = (u32)(val);
> -	high = (u32)(val >> 32);
> -
> -	native_wrmsr(MSR_AMD64_SEV_ES_GHCB, low, high);
> +	native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, val);

BTW., at this point we should probably just replace 
sev_es_wr_ghcb_msr() calls with direct calls to:

	native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);

as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().

Thanks,

	Ingo


From xen-devel-bounces@lists.xenproject.org Thu May 15 15:30:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 15:30:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985751.1371617 (Exim 4.92)
	(envelope-from )
	id 1uFaX2-0004rP-5D; Thu, 15 May 2025 15:30:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985751.1371617; Thu, 15 May 2025 15:30: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 1uFaX2-0004rI-2E; Thu, 15 May 2025 15:30:00 +0000
Received: by outflank-mailman (input) for mailman id 985751;
 Thu, 15 May 2025 15:29:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFaX1-0004rA-BM
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 15:29:59 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 74b299ae-31a1-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 17:29:57 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 03DAF614BC;
 Thu, 15 May 2025 15:29:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88415C4CEE7;
 Thu, 15 May 2025 15:29: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" 
X-Inumbo-ID: 74b299ae-31a1-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747322995;
	bh=r+vgoHyPQBXrDnAequwJxZxOTi6XM4s7SidDK1toDMU=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=UzEkXjNfRDfzQ5GSc7NDBYXzLq2U2bw/Gp4vlC7jEmo5kdO/vJmkmRqKjBbvtvSHE
	 IpmoYfwa4Yw2qifam3LOs0zBS1KEzYLQhiFDffdShYwPtRqVZdiEycadwv7r+PYk5h
	 F4VQ5ffWzzIpOVhb5ugdL/SHgPikVYUBu3BQB8RlWW9b5RVdNuZdwYR/j3G2vIqYqj
	 326h4/FYdiMslKMxeL1TVkHX4WyXFkMbVQsztMT2WgWln04f/pMRIiiyzSARV6zxqK
	 9VzzFrxMxdRi85vDhkSPA6Gs6VcIhSvLUzfyL3pZKhpVKV1IfIDw4C5nguWIlY7ZYC
	 lGmUajFVTt6Uw==
Date: Thu, 15 May 2025 17:29:50 +0200
From: Ingo Molnar 
To: "Xin Li (Intel)" 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
	rafael@kernel.org, lenb@kernel.org
Subject: Re: [PATCH v1 2/3] x86/xen/msr: Fix uninitialized symbol 'err'
Message-ID: 
References: <20250512084552.1586883-1-xin@zytor.com>
 <20250512084552.1586883-3-xin@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250512084552.1586883-3-xin@zytor.com>


* Xin Li (Intel)  wrote:

> xen_read_msr_safe() currently passes an uninitialized argument err to
> xen_do_read_msr().  But as xen_do_read_msr() may not set the argument,
> xen_read_msr_safe() could return err with an unpredictable value.
> 
> To ensure correctness, initialize err to 0 (representing success)
> in xen_read_msr_safe().
> 
> Because xen_read_msr_safe() is essentially a wrapper of xen_do_read_msr(),
> the latter should be responsible for initializing the value of *err to 0.
> Thus initialize *err to 0 in xen_do_read_msr().
> 
> Fixes: 502ad6e5a619 ("x86/msr: Change the function type of native_read_msr_safe()")
> Reported-by: Dan Carpenter 
> Closes: https://lore.kernel.org/xen-devel/aBxNI_Q0-MhtBSZG@stanley.mountain/
> Signed-off-by: Xin Li (Intel) 
> ---
>  arch/x86/xen/enlighten_pv.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 3be38350f044..01f1d441347e 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -1091,6 +1091,9 @@ static u64 xen_do_read_msr(u32 msr, int *err)
>  {
>  	u64 val = 0;	/* Avoid uninitialized value for safe variant. */
>  
> +	if (err)
> +		*err = 0;
> +
>  	if (pmu_msr_chk_emulated(msr, &val, true))
>  		return val;
>  
> @@ -1162,7 +1165,7 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err)
>  
>  static int xen_read_msr_safe(u32 msr, u64 *val)
>  {
> -	int err;
> +	int err = 0;
>  
>  	*val = xen_do_read_msr(msr, &err);
>  	return err;

So why not initialize 'err' with 0 in both callers, xen_read_msr_safe() 
and xen_read_msr(), and avoid all the initialization trouble in 
xen_do_read_msr()?

Thanks,

	Ingo


From xen-devel-bounces@lists.xenproject.org Thu May 15 16:24:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 16:24:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985775.1371627 (Exim 4.92)
	(envelope-from )
	id 1uFbNi-0008Ke-V5; Thu, 15 May 2025 16:24:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985775.1371627; Thu, 15 May 2025 16:24: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 1uFbNi-0008KX-SB; Thu, 15 May 2025 16:24:26 +0000
Received: by outflank-mailman (input) for mailman id 985775;
 Thu, 15 May 2025 16:24:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFbNh-0008KR-RO
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 16:24:25 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20621.outbound.protection.outlook.com
 [2a01:111:f403:2009::621])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0ef93084-31a9-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 18:24:23 +0200 (CEST)
Received: from MN2PR12MB4423.namprd12.prod.outlook.com (2603:10b6:208:24f::18)
 by DM4PR12MB6351.namprd12.prod.outlook.com (2603:10b6:8:a2::6) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8722.32; Thu, 15 May 2025 16:24:14 +0000
Received: from MN2PR12MB4423.namprd12.prod.outlook.com
 ([fe80::a078:ead1:2186:41df]) by MN2PR12MB4423.namprd12.prod.outlook.com
 ([fe80::a078:ead1:2186:41df%7]) with mapi id 15.20.8722.031; Thu, 15 May 2025
 16:24: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" 
X-Inumbo-ID: 0ef93084-31a9-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Hbm21j+DxUS8+7R5UNS8AvCkKRT8rxOsZ6DJO6TuvIVIqiCANqvHQx1Z55l51MXu/f8arQpj1H5raY6oc8rUT9JYtWJA18xgBp45cV7lIMz/3hoJww6430ehlbBUHo+BZf01VVssGSIidBpCnwCOT3CWk2u4OeAlWtoseKD8QywMM36YTjkAdLKCfumArMcp4gQCUGZonH1wuoHgTqpLWn+e9dTSimMsQnWsujkYQFPnrk80U87Iv2DVCnYqFuYGWASsHzCWoJJd9Xcllsomg9HVN/KulXR4lC8V1aC3b2hV2EIM4PCMx6QPX7mM1wBMQjomnX6yoEZBcOgBqU6tCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CQQp6ph4YBzlQqLR0nqaP9KRnP2CAg29N8pAUIEqT1U=;
 b=kyH0J1UgWr/ppqkGaNVViX0lQmKZeP98GeITsdA4JmpX53dEhmAO0UgTTuvmRHFh8jx+OQ1S7RkfYAUtNc9boEQZr4oep1SWOFHKmqtBv+4VPv07IhYLKKYY6Mk/yD4Gb+jxQtKacyRngIuSxUcOsTu+D8TLLT6+jymUqNIbwIzyOQGHbzesY7+eEMEw1BBnwQZxIREEdc3n/IcayaShxSyd+AtpuNpveElFYO3lrz86Z8pOqpk8muTyBJeBPQTKBdg9nOehJTQfXu8xiL9QrSzdkKugUFF8yE4URb/HApWGxNbgIF6BA8Zxvwy1cdYvGwfxYA2VTI4n7e7CJn391Q==
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=CQQp6ph4YBzlQqLR0nqaP9KRnP2CAg29N8pAUIEqT1U=;
 b=myC5d0Qizt1tL20hWR8wK4W01BQr47YHRWL/WZDKUYyijShumAu99d3jg0iX/L5z3c7gAPhvu3hGtUOCZJERAdZ+JtzUgQ7KsnbiIoqpAqBRkT55caLsx0LsMUu9AJr504ThjHfkerEYhAqZ5PmgB00xPTXmPTJuIw+uHVNP7kk=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <9befc286-2c45-4cca-aa54-0f205afc4239@amd.com>
Date: Thu, 15 May 2025 09:24:11 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC] xen/x86: allow overlaps with non-RAM regions
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Jan Beulich , Jason Andryuk ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 ,
 Stefano Stabellini , xen-devel@lists.xenproject.org,
 Andrew Cooper , Xenia.Ragiadakou@amd.com,
 Alejandro.GarciaVallejo@amd.com
References:  
 <775d3ac0-8f43-415a-a32d-14377092b96b@amd.com>
 <554026de-bbb4-488f-95c4-8e2f034d6d0e@amd.com> 
 <2acad9ba-564a-4d18-9b09-dcabe8f7b025@suse.com>
  
  <02b6f10a-119e-499c-a51f-8deac6fa6a93@amd.com>
 
Content-Language: en-US
From: "Lira, Victor M" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: BYAPR04CA0024.namprd04.prod.outlook.com
 (2603:10b6:a03:40::37) To MN2PR12MB4423.namprd12.prod.outlook.com
 (2603:10b6:208:24f::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN2PR12MB4423:EE_|DM4PR12MB6351:EE_
X-MS-Office365-Filtering-Correlation-Id: 95ba6fbe-3056-4f1b-951d-08dd93ccee2e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?alQyYi9tWkNVOFd4WXFiTUhScW1hSDFTbVloS09UR29PRXBVcFR4N0pEL2Z3?=
 =?utf-8?B?VXRRSXRDT0lFR25FRnNYbTRZV2JpYjFIVkV1c21NMXF1dkZqZ2ZJcGI1T0pl?=
 =?utf-8?B?NHpnV1V1ODJIQjV4TEpxYi9uem1nc2M2UDg4cFFXMklLN0w1QnZ6aUZjbGl4?=
 =?utf-8?B?a3pYdlZxZDJGU1loNURsQ2lObHY5NDZmM2FtU2VxWG5tcHFGQVNOeGZjK2o1?=
 =?utf-8?B?bGJyVjR0WXkzeStBTm9HSU9iSUhQSGpNN1pQRWh2R3c3UlRkSnY4dGxqUU5p?=
 =?utf-8?B?YnI4OXh5bCtKWm1vN09yS3JVMm10TlJKSGM0dWU2UlhJaUQ2UElFOEJxb2lR?=
 =?utf-8?B?QWsrZWRLRXgrdEZETzEyc0t5OUZ4ZU1KYTNZNy9NQXM0UFNJMWVLWTczVG1P?=
 =?utf-8?B?NXlzb2lobzZlR0cvYWNCbmlrQUhhVnk4aUFJQzh5T2dDNzh5Uld6bGw2Lzdn?=
 =?utf-8?B?K3dTR0pvSm41ODlQb1RDQmlzeHVtQWN6MWxBQ3pQNkoxMWRSNzRScXloQ2ow?=
 =?utf-8?B?cDN3dllVYzc3ZlBLT3VHTFN6NnhjNlRqdHFpMXVBaldrZ2kzdm0rOXFUeUZr?=
 =?utf-8?B?NllLRGFIbUNZTndPOGc2TGJNcG1kLzJ6QUxnekUrc2lqWUk4ZFlYb0V1Wkdt?=
 =?utf-8?B?KytwQlZCbHNIQ2FxLys3RloxQ0ZuekhGbjlwU0o4TnhkTkNUWkw0TXpKTEhS?=
 =?utf-8?B?U2xnd1VoaGd1dEtMS21wL2tUYkRQVWlpZ05qZGdXOFdaMU5BOGtOanRBcVVh?=
 =?utf-8?B?ZCtsOWZ3dUdvV3VjYnJHeVlZK21pYjNMMDVmZUVkem1ZTklZeVhMbzdmQXlq?=
 =?utf-8?B?UVBJVVlpMmZvSjhpOXlmVkJJSTZqWURmSVY0Smx0WmhjR3R4eHVEQ1FvalFs?=
 =?utf-8?B?OWQvR0J6UGtJMUxmTmhXK2NjbUNpcXphZk1sa1h0YzJtbW1kMzlTWGttU1I3?=
 =?utf-8?B?cmFTcmtVdTVJKzh0Ym5pODBnQzk5NGYvTW0wYUtUd2w2ZE85czZmTHZIRFRL?=
 =?utf-8?B?cnJoeHFHZ3dGNTBZK3JGVkMvU3QzdldSNEQrYk5yZ1BDZ3lPTDNJQmtSRzIx?=
 =?utf-8?B?U0o1VWdvZ3VEZ2R5blU0U3FVaEJGTjBSTW5RMTh3NWFib2Z4S0VuMmFkY05x?=
 =?utf-8?B?K1UxcUl1NDZNSkNBd2FweHUzQ3c1bm5kdHpKTW9mOWlLb0xkS1ZiRmJaM0U2?=
 =?utf-8?B?dmRWaWkwYWppYUtOd284RmxNVDYxVGtXWGxDUmdTekxQenp5ZGlXSUJObHIy?=
 =?utf-8?B?Vk5CNXpQdEdVdHFWbjAyd0Mzb2pBQW5WajYrbGFkYllKbFNuZkV2b0FxNXMr?=
 =?utf-8?B?TlNNYTBvWTdXMlROUzhSSXdqcG5QN2NNY2toc3JmQkN6OHJCVVpkekprdEtR?=
 =?utf-8?B?ZnE5UmN2YzFnQUVBYVpwRVF5RWpjNmxlTUlDVlBKTGtBeWJRRHhqa2JaZHdC?=
 =?utf-8?B?c241WmpZeVNDOXFqSERSSEcxMlJsQk9xZVhZK3ByNldNMFU4aVVRRGpINVl3?=
 =?utf-8?B?ZXdWT09aYnQ2NWkwdDlEdDF0dXJ3WlUrQ0tVVUM5cDVta2xLU3VDeHVLM0wx?=
 =?utf-8?B?L2p5WXkrTWlwZFNCN3V2bHg1RG1lN3N5MXp2SCszWVBIakQzOFJXbFRONDhj?=
 =?utf-8?B?SDZBcDJyNC9vdklrS3RpTm1xWTFFZ05oVmE2Zjkza2hETUhZaHVucVYxbTJH?=
 =?utf-8?B?L1UvTmdwSnU2OG43SkR5dDVFbWc2dklCK0I4K2hraWVhRWlTSmh0NWllazZz?=
 =?utf-8?B?bjAxdW1Idk5za2JRMFZyYlkzYytFVmpzUmVRbGdOTjVlelZlVnpwU3BSYkxp?=
 =?utf-8?B?TzFLY2E5UTA0Y2NUdW9ibmM1VTdsN1VGNy90ZldpYUNHbU9UajljcDZmd3BM?=
 =?utf-8?B?NlI4ZnNRYjZ5UWtCWHF1cWdRcEoyY2plTERiajZlTjMzKzZ3ckJMY0ZWeUFW?=
 =?utf-8?Q?V01I2b6FGHI=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR12MB4423.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZDI4MEx6WmVhY0Jpb0gyWUVDL2Uyb0F0NklOYmZQN0UxOTFERWRvbUk0WDZG?=
 =?utf-8?B?M1h4enBRM1daeGlIZUNCR09UdmlUOFhSQWludFhZTTR5UVlOdU0yRzhsZFBC?=
 =?utf-8?B?cS95TlcxMFVkM3IzdnBESEM5VzhyeUZORkJXWG1KOVR3enpudm5yM1pZS1Nl?=
 =?utf-8?B?NWowdXZSM2JlV01kWXBYV1JUd3I3c0lCdm9mZkQ2R0Q0ZkNOa25Xenl1VUl0?=
 =?utf-8?B?U25FYXpuZ3dObGp1WUZacytpSmlqckNPQXgxL0FhK0k1eEFDVFU2MzNSUXVI?=
 =?utf-8?B?enNqMFBvRGdkNEpOeGRjTFUzTll3QjRZd0JuRlExSWJBZkpqYVBLeVJUZm5k?=
 =?utf-8?B?MjBodFN2S05xdlZ1ejEydkwvL1B5OThRd3ppZ3pnMmVKWkVvaFZDdWZiM0gy?=
 =?utf-8?B?ZUdhY3A5c0lvMHlsRHJaemMwNjJqSWM1ZXlSbTNIQ3FoWFErUU40enh0eHE3?=
 =?utf-8?B?ZEJoOXZjbzNTU2hEd1hpQUpCSHhSQXFRRzNBMkpuZ0pUWFhraUZSTitJcUU4?=
 =?utf-8?B?SGpodjhjVm1TTFFxZDJkTUJPSHJlMFlsOUlzY0RvWHNIMEV2dzh2elZ4d3kr?=
 =?utf-8?B?OVJLTmxjZEcwYkM4V1pTeWIwZlR2K2hwaE5yTDAxUnhqR0w5UWRzeTdjbUl5?=
 =?utf-8?B?R2JWdVFuRmZ1Nks4ektad1R4Qk04cFNvV2o5WDEvQTkzTjVEWUxVMFBHdnlW?=
 =?utf-8?B?aDdOeldtSlBGaVU4SEZwSWxnaklrMnpIZGkvWDk4SHRSMlFiRnR6Q0h2OFNZ?=
 =?utf-8?B?VUR3NVVYNEN4T2Q0VzFPYlpUdjEzRktHelFhWkd6d1l4bjg2dEZ3QUc0Ukwy?=
 =?utf-8?B?MmVFeGxBSVYvSXVZeStFZ2lwb0hDNlRzYWlDQzYvTmZVWDV1dmF5NGlQbEtP?=
 =?utf-8?B?RDhDR05ISXZGdGd4Z1lzUUR6QlM5TDVLZkdNeFh0bUw5WmF1U1hzcU1kNS9P?=
 =?utf-8?B?Qng5OXVMbDNEM2dZdHFwVlBSdEJQeTcvS0hKQmxjZUQ0M2VXS0dTSXVERmJP?=
 =?utf-8?B?cktlaEpJZ244R0NodlBkemZsQUpEK1JLaXEvQ2ZkMGFESktxaWdJeWs0MVV1?=
 =?utf-8?B?UUM0Nkx2ai9EaERVSkEzbEhVekRIdDlUSFZySjJwb3I0TjA1aUhlc2NJclli?=
 =?utf-8?B?Z2RaRVVNNmErVHlxUjV0ME0wd1owUVpsWnIwd2RMa0xkQ0RaM0NyejFReldD?=
 =?utf-8?B?empMcktBdytLRHNtU2RONnlTVkRycm11NGc5eEJQVGt4NmxKL2RHNWNSVzFE?=
 =?utf-8?B?c0U2T0Z5c25GWnVkeTkyTGZrMXZVejZGVHR4MGdtSXRNYWxyVnJPc3lXT2VC?=
 =?utf-8?B?N1NhM04wdGlocjhpemI4dXpJMUdMaVhUay90cWVFZjFPUTV0UkhxRWtQZnNC?=
 =?utf-8?B?dkpGZVh5TFdYTmZTbzUrUzkzZVNOS1NzdElsb3UvU3VES2F6dEhvSml2bnhR?=
 =?utf-8?B?Y2FIUFNtSUx4ZFlsZ2xjTkd4ZE9Sa1VoK0o2S0VCVU1lczBEWFRTZzNFbUxP?=
 =?utf-8?B?MHNQUHJ1ZG5HUFAwTWVXayt1ejE2b3RoYVFCdHBUeUhNNlBud25ESFJUbGw2?=
 =?utf-8?B?M1FKS2FuWG9raU9FU0V0azZYVWM4TWUvSDR5cEcvNjdQNlQrYjlzalNTdzZw?=
 =?utf-8?B?UEl6dUEvMHJPNm5reW85eks0eFR5Zy93bHFZbkswTzBHRWE0S0VWVXgzdjYz?=
 =?utf-8?B?K2Z2NExzQWpUaytHZmR2dE5walRtSXlZbHNHeW5Pa0xJaTNVV1E2b0RBaFhQ?=
 =?utf-8?B?Zmt0Nm4wcGZURmZmZTBtV1IxMDJEUzVnWEVEdDJkNGcvekEyU2dRU3VXbkg5?=
 =?utf-8?B?Wmk2NVVYUUFqdTdBSkk1cjZyejlIbjVXUlk3YlpKZjlsUzFCR3BXMmN5VzBS?=
 =?utf-8?B?d0UzMnZIczE5Q3F0amNYODdDNkVoRDMrbWNTU0l5aVlQYmJXc0VYTUNOaWlE?=
 =?utf-8?B?aTdERGxDc0NEUzNMMXZJM2tzTXhabHo2T3FZWVZUN0M0SzRUTVVTRmVFc2Ni?=
 =?utf-8?B?RkNaL3VMK3hQTVh5K243QkpxWnVIWTZSTlYwOFJzT1JnaEp6Y0c4aThHSTZC?=
 =?utf-8?B?bms2NnF4Yk1VYU1zSU5JL3lkNlhQSWpUVVU1WU1YK2J5MVhPMWFlUTZ6YjlR?=
 =?utf-8?Q?P+Wr9k2pDZK/iLH0401b3mPAj?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 95ba6fbe-3056-4f1b-951d-08dd93ccee2e
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4423.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2025 16:24:13.7561
 (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: hnA7C4fS/wWm/9i3MKni56pm41BaDcwtQkmp1F4WZgjnudEGBSYDAAiRkmWRTQiDFoaLpBF62S9hnZG3jihtKQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6351

> Thanks for the testing.
>
> I've formally submitted this as:
>
> https://lore.kernel.org/xen-devel/20250515084123.43289-1-roger.pau@citrix.com/
>
> Functionality wise I think it should be the same as the last patch you
> tried.  Could you give it a spin and maybe provide a Tested-by if
> suitable?
>
> Thanks, Roger.
OK, I'll give it a test.


Victor


From xen-devel-bounces@lists.xenproject.org Thu May 15 16:26:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 16:26:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985781.1371638 (Exim 4.92)
	(envelope-from )
	id 1uFbPi-0000QL-Ch; Thu, 15 May 2025 16:26:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985781.1371638; Thu, 15 May 2025 16:26: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 1uFbPi-0000QE-7k; Thu, 15 May 2025 16:26:30 +0000
Received: by outflank-mailman (input) for mailman id 985781;
 Thu, 15 May 2025 16:26:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFbPg-0000Q6-9W
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 16:26:28 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 599e416f-31a9-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 18:26:27 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43cf257158fso8514845e9.2
 for ; Thu, 15 May 2025 09:26:27 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442fd583f20sm1789335e9.28.2025.05.15.09.26.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 09:26: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" 
X-Inumbo-ID: 599e416f-31a9-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747326387; x=1747931187; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Axzu3Z6DIMypLpgL5z0lHcJ61JxQHZsQJbcqk4I7bK8=;
        b=DNLB1wlqv59GPjCW8sFdiQUgOBNeuD9B6coLctfxHTlVBXv87tgLd3yu8g71d02yVz
         A/e/AFTTwW4BPzForKMNOHnmZSgeTc7XJ80PP94OPSVIyFftFXKl2OBNG5ZYkoN8P1DH
         zwJGAK3sAsyG0yhCE6juoBDcjfj0LnPkyXaR8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747326387; x=1747931187;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Axzu3Z6DIMypLpgL5z0lHcJ61JxQHZsQJbcqk4I7bK8=;
        b=TuVhtIlikFlBuH6cG8xKePHot6pNN3o4UdjEvoy4Kv8Nq5hoUXTzFMZUy1hrm9AdiG
         igH7XJn7hN9gr4Lnpx5iHf5unhkz9IGtg2by5WXOJ4SEc+UIMlha/RXiARgdzl6NhaBX
         xBnb4h5sDJKDcMGjgJ0NgiStU0jIgAaKo7/q1oyXTX0sTFfYk6fybxC1T1bPwnylgCdA
         CGZQOniu5FwO6uSwNuZrrVlxHcAWwNqo2msA09SKX1WxHuQ+wOy/dBs1tDV+rLullKzB
         9teIK7/ibhi3+bIw9EI17q6Bxajl6x9XDwjZH3zq1K9hZbx9s9kQAJyTwZ/E+kT6ogdI
         anoQ==
X-Forwarded-Encrypted: i=1; AJvYcCVOF+HDVm1Nx6aPl0iQPLhoszF2AMbH9bmx6d0orAETs8IC8heXhmCxbj8cZLQhZSBeYrmZLjJ+MBU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyXoDQS4LUbRH4bm17gMl0ZSB/S9AAGYbFkmnLePrp2H+hm9Q8a
	u0reOeWrfm6IU2xU9nOnd8clZveu8KXd+2vW1nMpQBxJnzxtvHMC0YjEQCEiZ5rtJD0=
X-Gm-Gg: ASbGncvrGuTXOF9zlOdwidU5RCaoOcm1wIJYVcZ5qG6AZ+rL0CKCNSzISi2+3XhlsK0
	VHdFr4KXN/kreLtA4Z8dasr+svMonSrYKrIGcysTnAlzC+CqoqvQvFNhUGwIuER2uBhayDXX+2w
	TKP/DWrHsIHrcchUvpWaI6HwEKVMOrkEy1DzmYqQ53Nwyuheo+ah4ZSL3oHhnfxIP6fOjNtJhxL
	V5bDkZ6UhX1jfVnVoyEoaBS5bo1AASE/UJNhUcAfvMrJgH6+cI7E0Bywz4D9dEtBKUFwtAo9zfS
	J2uWhp845/MhLspEZq5Xl23qWn2FtMlxRPoyu28YJJ2Ih5N7gqBXTOP5quBsQsefLI/fu+4UNXp
	k6J2CnW7jVIhInCw+
X-Google-Smtp-Source: AGHT+IFrevEW2g7e/p4qRW4+kBmDYA9OR4nICLPNyUzESMNi52XYwG9SVYN5Qi2jdCAhgmpMPq9xBA==
X-Received: by 2002:a05:600c:4688:b0:43d:abd:ad0e with SMTP id 5b1f17b1804b1-442fd64e354mr2219335e9.18.1747326386572;
        Thu, 15 May 2025 09:26:26 -0700 (PDT)
Message-ID: <22da07ea-a2da-4d8c-970d-0ca2020c27f7@citrix.com>
Date: Thu, 15 May 2025 17:26:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Use asm inline when available for alternatives
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , Julien Grall ,
 Volodymyr Babchuk ,
 Bertrand Marquis ,
 Michal Orzel ,
 Xen-devel 
References: <20250422113957.1289290-1-andrew.cooper3@citrix.com>
 <9990d438-6ebf-4308-89f5-ecacf04ea89b@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: <9990d438-6ebf-4308-89f5-ecacf04ea89b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22/04/2025 1:52 pm, Jan Beulich wrote:
> On 22.04.2025 13:39, Andrew Cooper wrote:
>> Compilers estimate the size of an asm() block for inlining purposes.
>>
>> Constructs such as ALTERNATIVE appear large due to the metadata, depsite often
>> only being a handful of instructions.  asm inline() overrides the estimation
>> to identify the block as being small.
>>
>> This has a substantial impact on inlining decisions, expected to be for the
>> better given that the compiler has a more accurate picture to work with.
>>
>> Signed-off-by: Andrew Cooper 
> So this is effectively a generalized version of
> https://lists.xen.org/archives/html/xen-devel/2022-08/msg00712.html

I'm sorry I missed this patch, but my feedback would have been "that's
not specific to altcall".

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu May 15 16:30:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 16:30:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985789.1371647 (Exim 4.92)
	(envelope-from )
	id 1uFbT8-0001As-Q7; Thu, 15 May 2025 16:30:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985789.1371647; Thu, 15 May 2025 16:30:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFbT8-0001Ad-MR; Thu, 15 May 2025 16:30:02 +0000
Received: by outflank-mailman (input) for mailman id 985789;
 Thu, 15 May 2025 16:30:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFbT7-0000yf-70
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 16:30:01 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d89c68e1-31a9-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 18:30:00 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-6000f2f217dso1103979a12.1
 for ; Thu, 15 May 2025 09:30:00 -0700 (PDT)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d27192dsm12479566b.71.2025.05.15.09.29.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 09:29: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" 
X-Inumbo-ID: d89c68e1-31a9-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747326600; x=1747931400; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=UQojJnZ/ObWeMzCKGcC9gHfHHtjUiLkOYNoJimNKpXI=;
        b=ddzs2FXUnzzJUglD2zy8bsdcrqhuGRFw6zDOa9t8kwpyOTgdzKoHBVExRo1VK5w5Yf
         gFtF1aBVJ7OVywvUx0pPdegaN2muPRGzLn5QxyTX56HdkhoMMYrrbxg+yeAPfM+BSY8f
         Mi656scdeixRmaPdEdVNAuJ1+YJMc54MUCF74=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747326600; x=1747931400;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=UQojJnZ/ObWeMzCKGcC9gHfHHtjUiLkOYNoJimNKpXI=;
        b=I0cqcgR0RnMEtpH9yt1hW6Wn2fSq7iB9yG/kXKYHPvVtQWMPgW60uy4wSw05mrye0a
         K0PrN3gPFmiNGugR0lJ7sxXe9+SgKe23TAN4Sh4ND6iXtUdZHNm5m9hKflMCoQvm+YMS
         UB4/akX/5eetmG8uYR832OgX+yYKAZBf+ggr9ULnSXrJsUAySjW3pMYbkTzyMf0uRpqh
         l1BPB/kSzalkk0Tb1oTGZ8VbbY6Hfyp9kMt40dLrtXqTv0MQX9Ono5cIStH81kCrWvI7
         xs65Yy8u2kNe6A1GGrfmGqNHzmNScJTzLnwjw+m6wB1LlyjZYm6RvKy8DhX0b6vn/6YQ
         Xlwg==
X-Gm-Message-State: AOJu0YwEQwQw0QDXWyt9aF+PQVYrBt7h27bQ5uzNRXt0jTEpsv+SznDX
	SZcyw3kWa9yfN7ZDHycEnYYHvh1hfC9OCX8lJpR4+ok8WI+q8MCWorFpUymYkN0RL55U9zWng3s
	Q7h1S
X-Gm-Gg: ASbGncv/Jig0+bfDVLdLcebTLRUtfN3pL8YRFDoIZCXibkcWkH1Xai5gB66bA9yjscV
	m6qeLxb0SgGXZW1h4krg3ykfkqWIIlcnCnBcaFb8VGOjC7zESF7nyLR9AVMToXID87hjThGQQV2
	QzmloNBMXAp8t+ixWRWYuBhk+Mfve0WihIfYU6olBjSjiSBh9n6czGIlf6VQ1eZRftNc+XtTyUf
	iM1lv9tfhqmktpYFdIXhwQtEectvsgAUpk17cZOCRxCZEI2YmdlXa5y7S4jvPGVnUWWYx9N8758
	n9w0HbEwZfmCzpC6wl4nGYmAZp5/ZXOcOKi6BwiuXDFCJQG5fmJvVSfMwR1GK6WKR54=
X-Google-Smtp-Source: AGHT+IFKqIoLrdcbAWLckgeD5/v9eFY1cp7VHhr9m0K/M7erqe/eawOBo+F5rhw33tYxcnMDS01XXA==
X-Received: by 2002:a17:907:72c3:b0:ad2:48f4:5968 with SMTP id a640c23a62f3a-ad52d517091mr45880666b.25.1747326599572;
        Thu, 15 May 2025 09:29:59 -0700 (PDT)
Date: Thu, 15 May 2025 18:29:58 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org, Huang Rui 
Subject: Re: [PATCH v4 02/10] vpci/header: Emulate legacy capability list for
 dom0
Message-ID: 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-3-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250509090542.2199676-3-Jiqian.Chen@amd.com>

On Fri, May 09, 2025 at 05:05:34PM +0800, Jiqian Chen wrote:
> Current logic of emulating legacy capability list is only for domU.
> So, expand it to emulate for dom0 too. Then it will be easy to hide
> a capability whose initialization fails in a function.
> 
> And restrict adding PCI_STATUS register only for domU since dom0
> has no limitation to access that register.
> 
> Signed-off-by: Jiqian Chen 
> ---
> cc: "Roger Pau Monné" 
> ---
> v3->v4 changes:
> * Also pass supported_caps to pci_find_next_cap_ttl() for dom0 since the n is zero when dom0,
>   and add a comment to explain it.
> * Restrict adding PCI_STATUS register only for domU since dom0 has no limitation to access that register.
> * For dom0 register handler, set vpci_hw_write8 to it instead of NULL.
> 
> v2->v3 changes:
> * Not to add handler of PCI_CAP_LIST_ID when domain is dom0.
> 
> v1->v2 changes:
> new patch.
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/header.c | 53 ++++++++++++++++++++++++---------------
>  xen/drivers/vpci/vpci.c   |  6 +++++
>  xen/include/xen/vpci.h    |  2 ++
>  3 files changed, 41 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index 3e9b44454b43..a06c518c506c 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -749,9 +749,9 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>  {
>      int rc;
>      bool mask_cap_list = false;
> +    bool is_hwdom = is_hardware_domain(pdev->domain);
>  
> -    if ( !is_hardware_domain(pdev->domain) &&
> -         pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
> +    if ( pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
>      {
>          /* Only expose capabilities to the guest that vPCI can handle. */
>          unsigned int next, ttl = 48;
> @@ -759,12 +759,18 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>              PCI_CAP_ID_MSI,
>              PCI_CAP_ID_MSIX,
>          };
> +        /*
> +         * For dom0, we should expose all capabilities instead of a fixed
> +         * capabilities array, so setting n to 0 here is to get the next
> +         * capability position directly in pci_find_next_cap_ttl.
> +         */
> +        const unsigned int n = is_hwdom ? 0 : ARRAY_SIZE(supported_caps);
>  
>          next = pci_find_next_cap_ttl(pdev->sbdf, PCI_CAPABILITY_LIST,
> -                                     supported_caps,
> -                                     ARRAY_SIZE(supported_caps), &ttl);
> +                                     supported_caps, n, &ttl);
>  
> -        rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
> +        rc = vpci_add_register(pdev->vpci, vpci_read_val,
> +                               is_hwdom ? vpci_hw_write8 : NULL,
>                                 PCI_CAPABILITY_LIST, 1,
>                                 (void *)(uintptr_t)next);
>          if ( rc )
> @@ -772,7 +778,7 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>  
>          next &= ~3;
>  
> -        if ( !next )
> +        if ( !next && !is_hwdom )
>              /*
>               * If we don't have any supported capabilities to expose to the
>               * guest, mask the PCI_STATUS_CAP_LIST bit in the status
> @@ -786,15 +792,18 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>  
>              next = pci_find_next_cap_ttl(pdev->sbdf,
>                                           pos + PCI_CAP_LIST_NEXT,
> -                                         supported_caps,
> -                                         ARRAY_SIZE(supported_caps), &ttl);
> +                                         supported_caps, n, &ttl);
>  
> -            rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
> -                                   pos + PCI_CAP_LIST_ID, 1, NULL);
> -            if ( rc )
> -                return rc;
> +            if ( !is_hwdom )
> +            {
> +                rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
> +                                       pos + PCI_CAP_LIST_ID, 1, NULL);
> +                if ( rc )
> +                    return rc;
> +            }
>  
> -            rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
> +            rc = vpci_add_register(pdev->vpci, vpci_read_val,
> +                                   is_hwdom ? vpci_hw_write8 : NULL,
>                                     pos + PCI_CAP_LIST_NEXT, 1,
>                                     (void *)(uintptr_t)next);
>              if ( rc )
> @@ -805,13 +814,17 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>      }
>  
>      /* Utilize rsvdp_mask to hide PCI_STATUS_CAP_LIST from the guest. */
> -    return vpci_add_register_mask(pdev->vpci, vpci_hw_read16, vpci_hw_write16,
> -                                  PCI_STATUS, 2, NULL,
> -                                  PCI_STATUS_RO_MASK &
> -                                    ~(mask_cap_list ? PCI_STATUS_CAP_LIST : 0),
> -                                  PCI_STATUS_RW1C_MASK,
> -                                  mask_cap_list ? PCI_STATUS_CAP_LIST : 0,
> -                                  PCI_STATUS_RSVDZ_MASK);
> +    return is_hwdom ? 0 : vpci_add_register_mask(pdev->vpci, vpci_hw_read16,
> +                                                 vpci_hw_write16, PCI_STATUS,
> +                                                 2, NULL,
> +                                                 PCI_STATUS_RO_MASK &
> +                                                    ~(mask_cap_list ?
> +                                                        PCI_STATUS_CAP_LIST :
> +                                                        0),
> +                                                 PCI_STATUS_RW1C_MASK,
> +                                                 mask_cap_list ?
> +                                                    PCI_STATUS_CAP_LIST : 0,
> +                                                 PCI_STATUS_RSVDZ_MASK);

Wow, that's a bit too much indentation for my taste.  Do you think you
could do:

/* Return early for the hw domain, no masking of PCI_STATUS. */
if ( is_hwdom )
    return 0;
...

So that you don't have to touch the current return chunk?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 15 17:55:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 17:55:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985848.1371657 (Exim 4.92)
	(envelope-from )
	id 1uFcnj-0003jE-Le; Thu, 15 May 2025 17:55:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985848.1371657; Thu, 15 May 2025 17: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 1uFcnj-0003j7-Ia; Thu, 15 May 2025 17:55:23 +0000
Received: by outflank-mailman (input) for mailman id 985848;
 Thu, 15 May 2025 17:55:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFcni-0003j0-0H
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 17:55:22 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c37b0a09-31b5-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 19:55:20 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54FHsVpw3601639
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Thu, 15 May 2025 10:54:31 -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" 
X-Inumbo-ID: c37b0a09-31b5-11f0-9eb6-5ba50f476ded
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54FHsVpw3601639
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747331672;
	bh=G7ieaLLHFbx+QEHyWYMyrA/SFOLf3DqlbM1dcfxnafw=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=Pci5Cm4AkZKrjtNgbD9kIEvofugHGu9rQStIB8I6HlP0P5GmfcK8dxy26SYPqu53l
	 iUM4QoaUoo5QxDSCvgasxn5a9QUGr0D1Ql8K0jbLDLd6g03vlF4gw+h31ZHoeUtVay
	 nLaR3PRAokolM4ZGUQbkNlu38pWzS8eCeMWnDvWNDSy7m9+87WxIlRTiVMXpmSFy5T
	 7VtfMfoWjJQ/T85JinrErAMrTP4HXKdE71rn54Q+Ov9SzSwCPPZ64mi3rjtV8dMYPF
	 5UOeboDxuVCnoqosEg4VSZBW7Cg1EJT2ZfxCtgvATt/5g83VQycjJC3x7Yge2GFBwO
	 NtO5Ryz7YKzsA==
Message-ID: <68dba45c-a677-4f6d-b7ec-e896aef3d27b@zytor.com>
Date: Thu, 15 May 2025 10:54:31 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/3] x86/msr: Convert a native_wrmsr() use to
 native_wrmsrq()
To: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
        rafael@kernel.org, lenb@kernel.org
References: <20250512084552.1586883-1-xin@zytor.com>
 <20250512084552.1586883-4-xin@zytor.com> 
Content-Language: en-US
From: Xin Li 
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 5/15/2025 8:27 AM, Ingo Molnar wrote:
> 
> * Xin Li (Intel)  wrote:
> 
>> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
>> conversions when a u64 MSR value is splitted into two u32.
>>
> 
> BTW., at this point we should probably just replace
> sev_es_wr_ghcb_msr() calls with direct calls to:
> 
> 	native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);
> 
> as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().
> 

I thought about it, however it looks to me that current code prefers not
to spread MSR_AMD64_SEV_ES_GHCB in 17 callsites.  And anyway it's a 
__always_inline function.

But as you have asked, I will make the change unless someone objects.

Thanks!
     Xin


From xen-devel-bounces@lists.xenproject.org Thu May 15 18:11:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 18:11:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985859.1371667 (Exim 4.92)
	(envelope-from )
	id 1uFd3W-0007Jk-Sh; Thu, 15 May 2025 18:11:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985859.1371667; Thu, 15 May 2025 18: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 1uFd3W-0007Jd-Pw; Thu, 15 May 2025 18:11:42 +0000
Received: by outflank-mailman (input) for mailman id 985859;
 Thu, 15 May 2025 18:11:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFd3V-0007JX-7K
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 18:11:41 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0aaaad6d-31b8-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 20:11:38 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54FIBA613610523
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Thu, 15 May 2025 11:11:10 -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" 
X-Inumbo-ID: 0aaaad6d-31b8-11f0-9ffb-bf95429c2676
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54FIBA613610523
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747332671;
	bh=9c1R4oy3soG5VO6mIRJI3CqW6DmwJ6Mep1AU0zB8N4A=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=DG3BzwQ2BWylwPDcl7KrfGhx2mIF7dLUmwl61g76BeleGjxlXwR4RDqh1sN4AbaLj
	 LCiKCPNKKZn+A3q/x0AZAtwJwqjQspJXZq6Gj4MU6eeg51aUBJC8fVM+e53znk7u7i
	 OQoSxfM434A9LxtAKAO1Jlmfa/R0vptHUyiea5Xf3GDQSRfEJR1UQIXvaqBBKtOpcy
	 AVto//EUOxjmaJK2YYQKuOz5qz8i2tTQuKWYati/DUVFmup3bEHu0inyoANKIPOidS
	 StXvbk7nGpNOH4+MoZQIgOsZzrfgFScQn6oJjgAvI1D78ZdQ87LB/YAc3eQv2WkUMF
	 EniWYTJqe8v3A==
Message-ID: <30affad5-4f26-4e22-9d64-b8ece1199773@zytor.com>
Date: Thu, 15 May 2025 11:11:09 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] x86/xen/msr: Fix uninitialized symbol 'err'
To: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
        rafael@kernel.org, lenb@kernel.org
References: <20250512084552.1586883-1-xin@zytor.com>
 <20250512084552.1586883-3-xin@zytor.com> 
Content-Language: en-US
From: Xin Li 
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 5/15/2025 8:29 AM, Ingo Molnar wrote:
> 
> * Xin Li (Intel)  wrote:
> 
>> xen_read_msr_safe() currently passes an uninitialized argument err to
>> xen_do_read_msr().  But as xen_do_read_msr() may not set the argument,
>> xen_read_msr_safe() could return err with an unpredictable value.
>>
>> To ensure correctness, initialize err to 0 (representing success)
>> in xen_read_msr_safe().
>>
>> Because xen_read_msr_safe() is essentially a wrapper of xen_do_read_msr(),
>> the latter should be responsible for initializing the value of *err to 0.
>> Thus initialize *err to 0 in xen_do_read_msr().
>>
>> Fixes: 502ad6e5a619 ("x86/msr: Change the function type of native_read_msr_safe()")
>> Reported-by: Dan Carpenter 
>> Closes: https://lore.kernel.org/xen-devel/aBxNI_Q0-MhtBSZG@stanley.mountain/
>> Signed-off-by: Xin Li (Intel) 
>> ---
>>   arch/x86/xen/enlighten_pv.c | 5 ++++-
>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
>> index 3be38350f044..01f1d441347e 100644
>> --- a/arch/x86/xen/enlighten_pv.c
>> +++ b/arch/x86/xen/enlighten_pv.c
>> @@ -1091,6 +1091,9 @@ static u64 xen_do_read_msr(u32 msr, int *err)
>>   {
>>   	u64 val = 0;	/* Avoid uninitialized value for safe variant. */
>>   
>> +	if (err)
>> +		*err = 0;
>> +
>>   	if (pmu_msr_chk_emulated(msr, &val, true))
>>   		return val;
>>   
>> @@ -1162,7 +1165,7 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err)
>>   
>>   static int xen_read_msr_safe(u32 msr, u64 *val)
>>   {
>> -	int err;
>> +	int err = 0;
>>   
>>   	*val = xen_do_read_msr(msr, &err);
>>   	return err;
> 
> So why not initialize 'err' with 0 in both callers, xen_read_msr_safe()
> and xen_read_msr(), and avoid all the initialization trouble in
> xen_do_read_msr()?

Yeah, I should make the change in xen_read_msr() too.

However xen_do_read_msr() should be implemented in a defensive way to
set *err properly as it's part of its return value.  Actually it was so,
but one of my previous cleanup patch removed it because err is no longer
passed to pmu_msr_chk_emulated().

Thanks!
     Xin


From xen-devel-bounces@lists.xenproject.org Thu May 15 19:51:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 19:51:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985912.1371677 (Exim 4.92)
	(envelope-from )
	id 1uFebh-0003UX-IV; Thu, 15 May 2025 19:51:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985912.1371677; Thu, 15 May 2025 19:51: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 1uFebh-0003UQ-FX; Thu, 15 May 2025 19:51:05 +0000
Received: by outflank-mailman (input) for mailman id 985912;
 Thu, 15 May 2025 19:51:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFebf-0003UK-Al
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 19:51:03 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id edcb4ead-31c5-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 21:51:02 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43ede096d73so9602105e9.2
 for ; Thu, 15 May 2025 12:51:02 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca5a03fsm440925f8f.22.2025.05.15.12.50.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 12: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" 
X-Inumbo-ID: edcb4ead-31c5-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747338661; x=1747943461; 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;
        bh=wZCZBNec/jVK5fwnZ+1Uw9LNKLMvJb8VoV7F4Xuquk0=;
        b=tMzsb8N9LRsPiA6RTj8MZwxp2XIOUY9CwVNlymS2DU6Uat0d3AQd4hnWAepHE1hG3o
         upjHPoS6k+WmeFYUcyF7xlGBYMhI+ErYNAfxEqRcnuTGU8ygSKwXmO9IT6SVUf9jwNw9
         NZEO1SreiVVrDTdnchFbJrck8CL6VoAOEbPss=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747338661; x=1747943461;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=wZCZBNec/jVK5fwnZ+1Uw9LNKLMvJb8VoV7F4Xuquk0=;
        b=UC9KQ9l+r4n79hq2WF18eBwbMP7F3FDzzi4mbKGWKdavuByww5dEc+4SCplwpbnMGK
         Om5i/cnuz3eQI6+ym7BWteGLzYl3FokkeTowjc1tsEDThNY51mukEoq5fijK5UHhXQrT
         mataS+31izLuebuh2P59/hdzSqJSSkwhWvd3TRSRl+pL4cWM8RmilhAaeYj2+jR4PrLO
         hEhQRZbmpzwF7bS6WwzYG9F7omeKmSFvgIVT+ef2HmUbctXlppojwcNT8Rzy/c+5hiFk
         cQam3KgRTnbhO3R4phsvxflDs5DkC9eu005YjwqUeKYCMjZP0rEupx1ZSagBfHz0Qiao
         X0iw==
X-Gm-Message-State: AOJu0YxDZwr424gswtoxYK6PmrDemc+9wk5JUQgab6RE3aNtXoLuAOH+
	08rQkYKwBBINLB39diZ8vSkbWFRSm8RVg+IrI9VZjMlKAx/jpAw7oKsTpMnwgFcVap8qca2iIzW
	ZSJXC
X-Gm-Gg: ASbGncv7SzlLOq0IsP3skVo5qtqtPPq14kCkNlq0qgFrDkZXTI1aP2OO7wJMSgSIUEa
	Moev18peMewzbi0hPGKCSknS5fYX6ukcvXe8TzNa+NpJRYsulCc6/1woZph/E5OPZFc8tUEtzt1
	nq6HRuetgUvZIH+yKvann7ZojRNZviaxm2RL27UVx5nUJ6k2quXyJN6YxrvkAYAvskM8XeoJ3nC
	yVLGsGfQhJMMuTeFpRnVNYCrRXnoAPUoOUMEA8YhkD6+xNmQeoHNcs9uAh5u4P21fEmuQrCexuq
	x8VFvXivIrvrdrJaq5yCgFKerqYra174y/ofTzwW28YwB8dockcCezCHKYHc2nDBKazAzMdGSlr
	Ixc1hTeIpWX/MTZ9BYaFOVNFQ
X-Google-Smtp-Source: AGHT+IFszA5YjZ5ZvW5f7Xazk+EHALOzN3nZl0b1KoykWFrj8R2/CkzPzeyUlp8lWJcY2IrT38QAdw==
X-Received: by 2002:a05:600c:4e52:b0:43d:db5:7af8 with SMTP id 5b1f17b1804b1-442fd665cd3mr6535455e9.21.1747338660834;
        Thu, 15 May 2025 12:51:00 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Nicola Vetrini ,
	"consulting @ bugseng . com" 
Subject: [PATCH for-4.20] x86/emul: Fix emulation of RDSEED with older toolchains
Date: Thu, 15 May 2025 20:50:58 +0100
Message-Id: <20250515195058.3702872-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

This is reported as a MISRA R16.3 (missing break) violation, but turns out to
be substantially more complicated than expected.

In commit a8fe4ec5320a ("x86emul: support RDRAND/RDSEED"), the switch()
statement had a default case going to cannot_emulate, with both the case 6 and
case 7 labels being fully within #ifdef HAVE_GAS_RD{RAND,SEED}.

Therefore, when the toolchain didn't understand the RDRAND/RDSEED
instructions, attempts to emulate them suffered #UD.  (This is arguably a
problem as there's no interlock to prevent RDRAND/RDSEED being advertied to
the guest, but as instructions with only register encodings, they can only end
up being emulated with VM Introspection is in use.)

In commit 58f1bba44033 ("x86emul: support RDPID"), case 7 was taken outside of
HAVE_GAS_RDSEED, meaning that emulating an RDSEED instruction no longer hit
the default case when the toolchain was too old.

Instead, it would fall out of the switch statment and be completed normally,
behaving as a NOP to the guest.

Retrofit a "return X86EMUL_UNIMPLEMENTED" in the case that the toolchain
doesn't know the RDRAND instruction, matching how RDRAND work.

Note that this has been fixed differently in Xen 4.21.  Commit
05bf9f1f0f52 ("x86/emulate: Remove HAVE_AS_RDRAND and HAVE_AS_RDSEED") has
removed the problematic condition due to the toolchain baseline upgrade.

Fixes: 58f1bba44033 ("x86emul: support RDPID")
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Nicola Vetrini 
CC: consulting@bugseng.com 

This will unblock the staging-4.20 branch.

I'm still concerned as to why this regression has shown up unexpected in the
4.20 branch.  In 4.19, the rule isn't marked clean, hence why that passes.

However, something changed in the Eclair environment to cause this to happen,
and given how HAVE_AS_RDSEED works, it's apparently to do with probing the
toolchain capabitilies, and now failing to probe correctly.
---
 xen/arch/x86/x86_emulate/0fc7.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/x86/x86_emulate/0fc7.c b/xen/arch/x86/x86_emulate/0fc7.c
index 5268d5cafd7b..2b6b444bab94 100644
--- a/xen/arch/x86/x86_emulate/0fc7.c
+++ b/xen/arch/x86/x86_emulate/0fc7.c
@@ -102,6 +102,8 @@ int x86emul_0fc7(struct x86_emulate_state *s,
             if ( carry )
                 regs->eflags |= X86_EFLAGS_CF;
             break;
+#else
+            return X86EMUL_UNIMPLEMENTED;
 #endif
         }
     }

base-commit: 612cfd7215568fe8a7e8939dfcc4bf53d986e482
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 15 19:55:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 19:55:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985920.1371686 (Exim 4.92)
	(envelope-from )
	id 1uFegO-00043i-2W; Thu, 15 May 2025 19:55:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985920.1371686; Thu, 15 May 2025 19:55: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 1uFegN-00043b-Vg; Thu, 15 May 2025 19:55:55 +0000
Received: by outflank-mailman (input) for mailman id 985920;
 Thu, 15 May 2025 19:55:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFegN-00043V-1E
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 19:55:55 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9b7e9830-31c6-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 21:55:53 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-442ea341570so9087865e9.1
 for ; Thu, 15 May 2025 12:55:53 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442ebd6fe86sm78320035e9.0.2025.05.15.12.55.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 12: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" 
X-Inumbo-ID: 9b7e9830-31c6-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747338952; x=1747943752; 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;
        bh=2ulHZr/ATKsZOEJSJ1e98CTHaG9QuXdMXhbSEfB/e34=;
        b=r3ArmG3FcDJOtUj0R5YxrDgHf0mL/2E+p3CA63PnsaKEsJpdtG1IEIlQ7S00yJRAWb
         IWhdN2DmBAH5qicKg5sm7p7nHyURedvmvNyAee4t4yleXi91GgX1wmK8QRNWa+UkyNfv
         +uR1ODKUktZjZvLgT/OVWyU4NojTyP9d5f/go=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747338952; x=1747943752;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=2ulHZr/ATKsZOEJSJ1e98CTHaG9QuXdMXhbSEfB/e34=;
        b=Noo6oyt2v5SvUSNq4ho7buAtH4MOuUvOZGaR3yOUz429CTyHu0MnOvhBrBLppwguH4
         vKSv8rqAkNhRdRjKs+w+7vnxjAkljA3i2wbdLQlHX23dvaMswhwr20vJKvvsXz1cbWDC
         mDNKYJHB1p56O4ep5xshu+qvmRGsgw8QkMLC11Gkh3iHVSz/xaPj72jwZiJiaWLvvIHB
         srEogJKGo9HlNhlCgw+1bIpNVobhtof+PQG4Q7HK8yuEBQLlXKw/ALz9/a7sVJDoRsnp
         Dn+ks0Z+Yyhi1xGFWUzo1oEIij7PzGm1ZNJJ+MWbwIXlSwX4xSYR/sBxuYIA4YxsMquL
         VQMA==
X-Gm-Message-State: AOJu0Yypina3g2EQviuPZN6JEIun2+td7KmBfDUb24mmWbWGG1rzUYPZ
	d2HGSf6Ooxjx8aAYasmCsjfZ2mjUuUoZHjr3NWj9iT3373M9C8hMNEHZxzr8Brf3GSr4I8FSRw+
	7yeoW
X-Gm-Gg: ASbGncvbkA0xCGGYtA+KtjVmCujBMYglY86F7q1DlHIk9VzgbGxG8ASjN2uR2uRoD4B
	bZHdlzpaoUeZumilpcmM0VXs7RfgR11nf5ShZERhFggiLkJM7paN8K5xQiSBK3REQzeN+Q75SXl
	GzIhRKJIFJOkhjuefoO3rYfggo6l5cvqHi1wUq23PMCfoNu7sEXlCIXwQEL7l1bpMAIhKMVXaS0
	KaMyeHTqct+8UR6kMiBQA8PkHnLAr9/X2o/D0jvrr8ZD4B0pbO84RvF92R8tvS57AcdDjNwKdoC
	Qi7WXYerHAXbrS6ru3J5CEXtNHGqDvwkuGCYzbuHZ7sfn6/U9efQmrOgC3vYKRXECzhBWLhpELw
	fI9KlU6lgTYZOXJCfmde0Wzx7
X-Google-Smtp-Source: AGHT+IHdf39d959XKmbL7CjNE1gJ1OdQXf+rjE6/pSKfp4P3O/AFL65LvPL4XGBqlwWvumCC99ohHQ==
X-Received: by 2002:a05:600c:1f15:b0:43c:f513:9591 with SMTP id 5b1f17b1804b1-442fd6276b6mr8269825e9.14.1747338952324;
        Thu, 15 May 2025 12:55:52 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [PATCH 0/3] xen: Use asm inline
Date: Thu, 15 May 2025 20:55:46 +0100
Message-Id: <20250515195549.3703017-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

Since v1, split into multiple patches.  Extend to BUG_FRAME and EXTABLE too.

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1819941756

Andrew Cooper (3):
  xen: Introduce asm inline and use it for BUG_FRAME
  x86: Use asm_inline for ALTERNATIVE() and EXTABLE
  ARM: Use asm_inline for ALTERNATIVE()

 xen/Kconfig                                 |  4 ++
 xen/arch/arm/include/asm/alternative.h      |  4 +-
 xen/arch/arm/include/asm/arm64/flushtlb.h   |  4 +-
 xen/arch/arm/include/asm/arm64/io.h         | 43 ++++++++++-------
 xen/arch/arm/include/asm/bug.h              |  6 ++-
 xen/arch/arm/include/asm/cpuerrata.h        |  8 ++--
 xen/arch/arm/include/asm/cpufeature.h       |  8 ++--
 xen/arch/arm/include/asm/page.h             | 12 +++--
 xen/arch/arm/include/asm/processor.h        |  7 +--
 xen/arch/arm/include/asm/sysregs.h          | 10 ++--
 xen/arch/arm/mmu/p2m.c                      |  3 +-
 xen/arch/x86/cpu/amd.c                      | 52 +++++++++++----------
 xen/arch/x86/domain.c                       | 21 +++++----
 xen/arch/x86/extable.c                      | 21 +++++----
 xen/arch/x86/hvm/vmx/vmcs.c                 | 15 +++---
 xen/arch/x86/i387.c                         |  4 +-
 xen/arch/x86/include/asm/alternative-call.h |  3 +-
 xen/arch/x86/include/asm/alternative.h      | 36 ++++++++------
 xen/arch/x86/include/asm/hvm/vmx/vmx.h      | 15 +++---
 xen/arch/x86/include/asm/uaccess.h          |  4 +-
 xen/arch/x86/pv/misc-hypercalls.c           | 19 ++++----
 xen/arch/x86/traps.c                        | 48 ++++++++++---------
 xen/arch/x86/usercopy.c                     |  6 +--
 xen/include/xen/bug.h                       | 11 +++--
 xen/include/xen/compiler.h                  | 15 ++++++
 25 files changed, 219 insertions(+), 160 deletions(-)


-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 15 19:55:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 19:55:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985921.1371697 (Exim 4.92)
	(envelope-from )
	id 1uFegQ-0004J1-9z; Thu, 15 May 2025 19:55:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985921.1371697; Thu, 15 May 2025 19:55:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFegQ-0004Iu-6S; Thu, 15 May 2025 19:55:58 +0000
Received: by outflank-mailman (input) for mailman id 985921;
 Thu, 15 May 2025 19:55:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFegP-00043V-Jz
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 19:55:57 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9d0a4fb8-31c6-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 21:55:55 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43cf848528aso11051245e9.2
 for ; Thu, 15 May 2025 12:55:55 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442ebd6fe86sm78320035e9.0.2025.05.15.12.55.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 12: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" 
X-Inumbo-ID: 9d0a4fb8-31c6-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747338955; x=1747943755; 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;
        bh=gFY+crOJ6uli3zRfjr13DW1h8fGEztjSlHefAA2118A=;
        b=EvzktjRkGRTNKA2frJwF7icapIoR5y/ec+njt3zMebHQ1bD165p6RSz7pRt+LpwRiz
         mWK5TLIzdLU1dx+1r/bphv1FyDppyBg55RUUdy1n/rPkPXCodw9m0sc9Ccn2h5iFWohY
         ELJeTfjvSYVBULp8X6xQKdvpLAcGtPmAucnKY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747338955; x=1747943755;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=gFY+crOJ6uli3zRfjr13DW1h8fGEztjSlHefAA2118A=;
        b=Dhbsod/4ukqT3f1eFdbAsp5I+8vutTazMZL5NfulswNIYXMDUVfWXXJZnPa+1Kp5L0
         FOsxJup06FN88pGQF5cIE+X7vIZBuGzzJtCR1J4PK5sBoverV2ENzOoC4/BbJH8M6zgA
         ApwN2DP5FIeYov9FHgqG1goG0RFNe3nD9dpu36SUgWRMfMS9ANy1n+bK1pxfXVIve7Gf
         dggTf7ILSRwLplE/1j9uw/fqW6V6afiJUTV3dms93lT5Ob7v3FqMFVoe+SHaWrcuenFY
         IFjvtbnBHxB3Gg0AxcUoHDIQ1ZfhYeiy9Wuk5kEqfOdc0A+h6EBFag+ZfcJQJRLhOwDx
         ZPKQ==
X-Gm-Message-State: AOJu0Ywi/6YZueub9OLmNaivihIkk/g7x3m8dsRt8+XBF2Z2WMbV9s/9
	YZHXmQNjubvLcSI314kSR1+3NPmRW8RI3MLbVIE2xzKLgu39fz8jCNd4N+spWokuYkUvYUMsLUt
	LxFuG
X-Gm-Gg: ASbGncuW64HwaZoUGv5ktyFO3G0WrWagZbb9zpyWVmBi2u+qdBIGhw0nWlCUoMauvqW
	BY8RVPyuxMQ2XKvnRoqESy99itJ5SPOcmvvNwAtZUmQbjy4n4YezQdfh+zRNAnI2MVJrhLMlQ1b
	yEgkFM/a49S354IakqPjhfXguftOraHnYhHpMOL7DPt8ar6FVsjh6iYmwh3jqIcOOd9Y/5SXQ79
	4xPIOBuewPUJ04q27hDm/QmyQi1Qg19jvNULpFdMHg01jZ/jD2ks3yAfP5vScWlRRB3Z4iSwPPO
	5qiO9w1xEOPxxefjdy/NxQMxx9Phtri+CKAySWVET3+mDZPk9AJhTkwO5Jn0y7iUfD1kp5I60KE
	aJTNK/w774i4YNZyLHSZ1hvqD
X-Google-Smtp-Source: AGHT+IEo6SRUhBVfLLFYMkghRkXLjLJFU7gt1APsW7jxNCCW/d2OIsYmRGE0cyza9+Q+T3HfSs7D4g==
X-Received: by 2002:a05:600c:384b:b0:43c:f8fc:f6a6 with SMTP id 5b1f17b1804b1-442fd6100famr8204345e9.9.1747338954976;
        Thu, 15 May 2025 12:55:54 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [PATCH 1/3] xen: Introduce asm inline and use it for BUG_FRAME
Date: Thu, 15 May 2025 20:55:47 +0100
Message-Id: <20250515195549.3703017-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250515195549.3703017-1-andrew.cooper3@citrix.com>
References: <20250515195549.3703017-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Compilers estimate the size of an asm() block for inlining purposes.

Constructs with embedded metadata (BUG_FRAME, ALTERNATIVE, EXTABLE, etc)
appear large, depsite often only being a handful of instructions.  asm
inline() overrides the estimation to identify the block as being small.

This has a substantial impact on inlining decisions, expected to be for the
better given that the compiler has a more accurate picture to work with.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 

v2:
 * Split into multiple patches
 * Start with BUG().

The full bloat-o-meter for this on x86 is https://termbin.com/27we although
the saving is better than reported.

Note the pairs such as:

  vmx_update_secondary_exec_control.part         2       -      -2
  vmx_update_secondary_exec_control             60      57      -3

This is becuse the UD2 was out-of-lined, and was CALL'd.  When inlined, the 5
byte CALL instruction in is replace with the 2 byte UD2.  Further than
reported, we save another 14 bytes due to the 16 byte function alignment.

This undoes an unanticipated side effect of starting to use asm goto().
---
 xen/Kconfig                    |  4 ++++
 xen/arch/arm/include/asm/bug.h |  6 ++++--
 xen/include/xen/bug.h          | 11 ++++++-----
 xen/include/xen/compiler.h     | 15 +++++++++++++++
 4 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/xen/Kconfig b/xen/Kconfig
index 1b24e8f3c0cd..07c4accf881c 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -29,6 +29,10 @@ config LD_IS_GNU
 config LD_IS_LLVM
 	def_bool $(success,$(LD) --version | head -n 1 | grep -q "^LLD")
 
+config CC_HAS_ASM_INLINE
+	# GCC >= 9, Clang >= 11
+	def_bool $(success,echo 'void foo(void) { asm inline (""); }' | $(CC) -x c - -c -o /dev/null)
+
 # Use -f{function,data}-sections compiler parameters
 config CC_SPLIT_SECTIONS
 	bool
diff --git a/xen/arch/arm/include/asm/bug.h b/xen/arch/arm/include/asm/bug.h
index 8bf71587bea1..0f436df63f26 100644
--- a/xen/arch/arm/include/asm/bug.h
+++ b/xen/arch/arm/include/asm/bug.h
@@ -34,7 +34,8 @@ struct bug_frame {
 #define BUG_FRAME(type, line, file, has_msg, msg) do {                      \
     BUILD_BUG_ON((line) >> 16);                                             \
     BUILD_BUG_ON((type) >= BUGFRAME_NR);                                    \
-    asm ("1:"BUG_INSTR"\n"                                                  \
+    asm_inline (                                                            \
+         "1:"BUG_INSTR"\n"                                                  \
          ".pushsection .rodata.str, \"aMS\", %progbits, 1\n"                \
          "2:\t.asciz " __stringify(file) "\n"                               \
          "3:\n"                                                             \
@@ -60,7 +61,8 @@ struct bug_frame {
  */
 #define  run_in_exception_handler(fn) do {                                  \
     register unsigned long _fn asm (STR(BUG_FN_REG)) = (unsigned long)(fn); \
-    asm ("1:"BUG_INSTR"\n"                                                  \
+    asm_inline (                                                            \
+         "1:"BUG_INSTR"\n"                                                  \
          ".pushsection .bug_frames." __stringify(BUGFRAME_run_fn) ","       \
          "             \"a\", %%progbits\n"                                 \
          "2:\n"                                                             \
diff --git a/xen/include/xen/bug.h b/xen/include/xen/bug.h
index 99814c4bef36..0cabdba37992 100644
--- a/xen/include/xen/bug.h
+++ b/xen/include/xen/bug.h
@@ -89,11 +89,12 @@ struct bug_frame {
 #ifndef BUG_FRAME
 
 #define BUG_FRAME(type, line, ptr, second_frame, msg) do {                   \
-    BUG_CHECK_LINE_WIDTH(line);                                           \
-    BUILD_BUG_ON((type) >= BUGFRAME_NR);                                     \
-    asm volatile ( _ASM_BUGFRAME_TEXT(second_frame)                          \
-                   :: _ASM_BUGFRAME_INFO(type, line, ptr, msg) );            \
-} while ( false )
+        BUG_CHECK_LINE_WIDTH(line);                                          \
+        BUILD_BUG_ON((type) >= BUGFRAME_NR);                                 \
+        asm_inline volatile (                                                \
+            _ASM_BUGFRAME_TEXT(second_frame)                                 \
+            :: _ASM_BUGFRAME_INFO(type, line, ptr, msg) );                   \
+    } while ( false )
 
 #endif
 
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index c68fab189154..735c844d2d15 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -53,6 +53,21 @@
 #define unreachable() __builtin_unreachable()
 #endif
 
+/*
+ * Compilers estimate the size of an asm() block for inlining purposes.
+ *
+ * Constructs with embedded metadata (BUG_FRAME, ALTERNATIVE, EXTABLE, etc)
+ * appear large, depsite typically only being a handful of instructions.  asm
+ * inline() overrides the estimation to identify the block as being small.
+ *
+ * Note: __inline is needed to avoid getting caught up in INIT_SECTIONS_ONLY.
+ */
+#if CONFIG_CC_HAS_ASM_INLINE
+# define asm_inline asm __inline
+#else
+# define asm_inline asm
+#endif
+
 /*
  * Add the pseudo keyword 'fallthrough' so case statement blocks
  * must end with any of these keywords:
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 15 19:55:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 19:55:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985922.1371707 (Exim 4.92)
	(envelope-from )
	id 1uFegR-0004Y5-JQ; Thu, 15 May 2025 19:55:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985922.1371707; Thu, 15 May 2025 19:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFegR-0004Xv-GC; Thu, 15 May 2025 19:55:59 +0000
Received: by outflank-mailman (input) for mailman id 985922;
 Thu, 15 May 2025 19:55:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFegQ-00043V-HR
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 19:55:58 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9da64d0e-31c6-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 21:55:56 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43cf680d351so14712645e9.0
 for ; Thu, 15 May 2025 12:55:56 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442ebd6fe86sm78320035e9.0.2025.05.15.12.55.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 12:55:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9da64d0e-31c6-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747338956; x=1747943756; 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;
        bh=78lwAjTVEfFZKXkvQFxXqM7GZdpZLNr3fAkXr5zqCcs=;
        b=DpbHiMQF5fBrdkjr2ZvkkDp6T+3bxf/+9NmbjvUdBO4vDwa3bZx8KI9U0Dowc/6BaM
         2vTU1NLlkJUA1fqjZN2F9iZfSmoK9gTQBUhaH1H/mChsoZVcuvxd1LZXaSp25hESSEtR
         TJCZNIBJe8D0Vwx3B+sOwBiZomwv391HUlsio=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747338956; x=1747943756;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=78lwAjTVEfFZKXkvQFxXqM7GZdpZLNr3fAkXr5zqCcs=;
        b=KFEmyLPcoMsTXuYR6yYwOxLPth5EiR8VaAwYHwQXPnUghHOYcMLHe9C9TvchPxBOvC
         HUK83NfCDfeG7/anFUbYe/H655XZtXWnHX/vn8ZUM7aAM4c4DzlD0h4nz/wDn9FO/8ra
         cdEkRggWtN4vdsfbF7JRJCqcy3+1UyHUH+/T9BZBGOji4PPOq143eiLnX+rNLuPUuEVG
         owsxm+7BKdzVfUrYTpTW0DhT9fCMSnNHwwbXAImcCPg4WdAjVOoiq7kt3ir7IDvK2gku
         AlX2ZCJCZKjA5qMaAXM2ecpFH7CvgFsbtx+Xk0kIdUexcbHFkOi91dT3uiHb8+0rP4Wx
         PcBg==
X-Gm-Message-State: AOJu0YxSKiYjIHgvC+thIqG8F2/pLmr0n9+4meLUaDhkGO/hcjd3Ry0A
	Dg1EC2GGqC1S1NkWd5HQyz+Y2VJ9VuuiXQw3HMxwmihNcxh9JN2nrnWr6/dYeYd59jpTOrs1xU7
	4aefd
X-Gm-Gg: ASbGncs2aVlxjSGhE7vum4yj0DylQpgzIuTosdGuzKssFkBe8TsTkjromnov7lap3NE
	vD9Wjzija4wkaRSrjcXmK8cV2OhaX/M0YNO0FA6BTL41kdDorLsx4PeoUPfIBA+2flsImjXSve8
	1A9eShpwrgQJchmz3CtGzPPzVv1hhvJhu3N8EaKLIfnm8UlxLkAhLOfQaXusbQN5zgSNRqaOVox
	ouYS6+9NHykqgKd0CoSayPd+QNg7eN6NwwbTZPYX/UKGibnh1PUjJC00Beml5NJ+J5HnqdzvFmk
	F5VGZH0+Fgici52n5CP5PfJuZo9+Iyl3GKJ6JgoRLGhKlMA5jAY+sQgva5sJevNEX4hCaCXwB1x
	OZNOfkfey0cA/AVgSlIozuroaNXblzCP5zhs=
X-Google-Smtp-Source: AGHT+IF3How/2DZVnEKz0UT2FxoFJbzP/0XrdjvWYJ0uNhdGqw3ZlmHN9uoKmy9iREMsNxkVxVpMjA==
X-Received: by 2002:a05:600c:46c9:b0:442:f8f6:48e5 with SMTP id 5b1f17b1804b1-442f8f6494fmr43419715e9.8.1747338955876;
        Thu, 15 May 2025 12:55:55 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [PATCH 2/3] x86: Use asm_inline for ALTERNATIVE() and EXTABLE
Date: Thu, 15 May 2025 20:55:48 +0100
Message-Id: <20250515195549.3703017-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250515195549.3703017-1-andrew.cooper3@citrix.com>
References: <20250515195549.3703017-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

... when there really are only a few instructions in line.

In some cases, reformat to reduce left-hand margine space.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 

v2:
 * New, split out of previous single patch
 * Include EXTABLE

There are some uses of _ASM_EXTABLE() which are in blocks with many
instructions which are left unconverted.  There are also a couple for which I
already have pending cleanup, which I've left alone to reduce churn.
---
 xen/arch/x86/cpu/amd.c                      | 52 +++++++++++----------
 xen/arch/x86/domain.c                       | 21 +++++----
 xen/arch/x86/extable.c                      | 21 +++++----
 xen/arch/x86/hvm/vmx/vmcs.c                 | 15 +++---
 xen/arch/x86/i387.c                         |  4 +-
 xen/arch/x86/include/asm/alternative-call.h |  3 +-
 xen/arch/x86/include/asm/alternative.h      | 36 ++++++++------
 xen/arch/x86/include/asm/hvm/vmx/vmx.h      | 15 +++---
 xen/arch/x86/include/asm/uaccess.h          |  4 +-
 xen/arch/x86/pv/misc-hypercalls.c           | 19 ++++----
 xen/arch/x86/traps.c                        | 48 ++++++++++---------
 xen/arch/x86/usercopy.c                     |  6 +--
 12 files changed, 132 insertions(+), 112 deletions(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 37d67dd15c89..27ae16780857 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -60,41 +60,45 @@ static inline int rdmsr_amd_safe(unsigned int msr, unsigned int *lo,
 				 unsigned int *hi)
 {
 #ifdef CONFIG_CC_HAS_ASM_GOTO_OUTPUT
-    asm goto ( "1: rdmsr\n\t"
-               _ASM_EXTABLE(1b, %l[fault])
-               : "=a" (*lo), "=d" (*hi)
-               : "c" (msr), "D" (0x9c5a203a)
-               :
-               : fault );
+    asm_inline goto (
+        "1: rdmsr\n\t"
+        _ASM_EXTABLE(1b, %l[fault])
+        : "=a" (*lo), "=d" (*hi)
+        : "c" (msr), "D" (0x9c5a203a)
+        :
+        : fault );
+
     return 0;
 
  fault:
     return -EFAULT;
 #else
-	int err;
-
-	asm volatile("1: rdmsr\n2:\n"
-		     ".section .fixup,\"ax\"\n"
-		     "3: movl %6,%2\n"
-		     "   jmp 2b\n"
-		     ".previous\n"
-		     _ASM_EXTABLE(1b, 3b)
-		     : "=a" (*lo), "=d" (*hi), "=r" (err)
-		     : "c" (msr), "D" (0x9c5a203a), "2" (0), "i" (-EFAULT));
-
-	return err;
+    int err;
+
+    asm_inline volatile (
+        "1: rdmsr\n2:\n"
+        ".section .fixup,\"ax\"\n"
+        "3: movl %6,%2\n"
+        "   jmp 2b\n"
+        ".previous\n"
+        _ASM_EXTABLE(1b, 3b)
+        : "=a" (*lo), "=d" (*hi), "=r" (err)
+        : "c" (msr), "D" (0x9c5a203a), "2" (0), "i" (-EFAULT) );
+
+    return err;
 #endif
 }
 
 static inline int wrmsr_amd_safe(unsigned int msr, unsigned int lo,
                                  unsigned int hi)
 {
-    asm goto ( "1: wrmsr\n\t"
-               _ASM_EXTABLE(1b, %l[fault])
-               :
-               : "c" (msr), "a" (lo), "d" (hi), "D" (0x9c5a203a)
-               :
-               : fault );
+    asm_inline goto (
+        "1: wrmsr\n\t"
+        _ASM_EXTABLE(1b, %l[fault])
+        :
+        : "c" (msr), "a" (lo), "d" (hi), "D" (0x9c5a203a)
+        :
+        : fault );
 
     return 0;
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index f197dad4c0cd..7536b6c8717e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1706,16 +1706,17 @@ static void load_segments(struct vcpu *n)
      * @all_segs_okay in function scope, and load NUL into @sel.
      */
 #define TRY_LOAD_SEG(seg, val)                          \
-    asm volatile ( "1: mov %k[_val], %%" #seg "\n\t"    \
-                   "2:\n\t"                             \
-                   ".section .fixup, \"ax\"\n\t"        \
-                   "3: xor %k[ok], %k[ok]\n\t"          \
-                   "   mov %k[ok], %%" #seg "\n\t"      \
-                   "   jmp 2b\n\t"                      \
-                   ".previous\n\t"                      \
-                   _ASM_EXTABLE(1b, 3b)                 \
-                   : [ok] "+r" (all_segs_okay)          \
-                   : [_val] "rm" (val) )
+    asm_inline volatile (                               \
+        "1: mov %k[_val], %%" #seg "\n\t"               \
+        "2:\n\t"                                        \
+        ".section .fixup, \"ax\"\n\t"                   \
+        "3: xor %k[ok], %k[ok]\n\t"                     \
+        "   mov %k[ok], %%" #seg "\n\t"                 \
+        "   jmp 2b\n\t"                                 \
+        ".previous\n\t"                                 \
+        _ASM_EXTABLE(1b, 3b)                            \
+        : [ok] "+r" (all_segs_okay)                     \
+        : [_val] "rm" (val) )
 
     if ( !compat )
     {
diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 1572efa69a00..de392024527c 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -186,16 +186,17 @@ int __init cf_check stub_selftest(void)
         place_ret(ptr + ARRAY_SIZE(tests[i].opc));
         unmap_domain_page(ptr);
 
-        asm volatile ( "INDIRECT_CALL %[stb]\n"
-                       ".Lret%=:\n\t"
-                       ".pushsection .fixup,\"ax\"\n"
-                       ".Lfix%=:\n\t"
-                       "pop %[exn]\n\t"
-                       "jmp .Lret%=\n\t"
-                       ".popsection\n\t"
-                       _ASM_EXTABLE(.Lret%=, .Lfix%=)
-                       : [exn] "+m" (res) ASM_CALL_CONSTRAINT
-                       : [stb] "r" (addr), "a" (tests[i].rax));
+        asm_inline volatile (
+            "INDIRECT_CALL %[stb]\n"
+            ".Lret%=:\n\t"
+            ".pushsection .fixup,\"ax\"\n"
+            ".Lfix%=:\n\t"
+            "pop %[exn]\n\t"
+            "jmp .Lret%=\n\t"
+            ".popsection\n\t"
+            _ASM_EXTABLE(.Lret%=, .Lfix%=)
+            : [exn] "+m" (res) ASM_CALL_CONSTRAINT
+            : [stb] "r" (addr), "a" (tests[i].rax) );
 
         if ( res.raw != tests[i].res.raw )
         {
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index a44475ae15bd..59f4d1d86f02 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -749,13 +749,14 @@ static int _vmx_cpu_up(bool bsp)
     if ( bsp && (rc = vmx_cpu_up_prepare(cpu)) != 0 )
         return rc;
 
-    asm goto ( "1: vmxon %[addr]\n\t"
-               "   jbe %l[vmxon_fail]\n\t"
-               _ASM_EXTABLE(1b, %l[vmxon_fault])
-               :
-               : [addr] "m" (this_cpu(vmxon_region))
-               : "memory"
-               : vmxon_fail, vmxon_fault );
+    asm_inline goto (
+        "1: vmxon %[addr]\n\t"
+        "   jbe %l[vmxon_fail]\n\t"
+        _ASM_EXTABLE(1b, %l[vmxon_fault])
+        :
+        : [addr] "m" (this_cpu(vmxon_region))
+        : "memory"
+        : vmxon_fail, vmxon_fault );
 
     this_cpu(vmxon) = 1;
 
diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
index 5429531ddd5f..b84cd6f7a9e1 100644
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -62,7 +62,7 @@ static inline void fpu_fxrstor(struct vcpu *v)
     switch ( __builtin_expect(fpu_ctxt->x[FPU_WORD_SIZE_OFFSET], 8) )
     {
     default:
-        asm volatile (
+        asm_inline volatile (
             "1: fxrstorq %0\n"
             ".section .fixup,\"ax\"   \n"
             "2: push %%"__OP"ax       \n"
@@ -82,7 +82,7 @@ static inline void fpu_fxrstor(struct vcpu *v)
             : "m" (*fpu_ctxt), "i" (sizeof(*fpu_ctxt) / 4) );
         break;
     case 4: case 2:
-        asm volatile (
+        asm_inline volatile (
             "1: fxrstor %0         \n"
             ".section .fixup,\"ax\"\n"
             "2: push %%"__OP"ax    \n"
diff --git a/xen/arch/x86/include/asm/alternative-call.h b/xen/arch/x86/include/asm/alternative-call.h
index bbc49a5274d9..b22c10c32283 100644
--- a/xen/arch/x86/include/asm/alternative-call.h
+++ b/xen/arch/x86/include/asm/alternative-call.h
@@ -87,7 +87,8 @@ struct alt_call {
     rettype ret_;                                                  \
     register unsigned long r10_ asm("r10");                        \
     register unsigned long r11_ asm("r11");                        \
-    asm volatile ("1: call *%c[addr](%%rip)\n\t"                   \
+    asm_inline volatile (                                          \
+                  "1: call *%c[addr](%%rip)\n\t"                   \
                   ".pushsection .alt_call_sites, \"a\", @progbits\n\t"  \
                   ".long 1b - .\n\t"                               \
                   ".popsection"                                    \
diff --git a/xen/arch/x86/include/asm/alternative.h b/xen/arch/x86/include/asm/alternative.h
index e17be8ddfd82..0482bbf7cbf1 100644
--- a/xen/arch/x86/include/asm/alternative.h
+++ b/xen/arch/x86/include/asm/alternative.h
@@ -126,12 +126,15 @@ extern void alternative_instructions(void);
  * without volatile and memory clobber.
  */
 #define alternative(oldinstr, newinstr, feature)                        \
-        asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) : : : "memory")
+    asm_inline volatile (                                               \
+        ALTERNATIVE(oldinstr, newinstr, feature)                        \
+        ::: "memory" )
 
 #define alternative_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \
-	asm volatile (ALTERNATIVE_2(oldinstr, newinstr1, feature1,	\
-				    newinstr2, feature2)		\
-		      : : : "memory")
+    asm_inline volatile (                                               \
+        ALTERNATIVE_2(oldinstr, newinstr1, feature1,                    \
+                      newinstr2, feature2)                              \
+        ::: "memory" )
 
 /*
  * Alternative inline assembly with input.
@@ -143,14 +146,16 @@ extern void alternative_instructions(void);
  * If you use variable sized constraints like "m" or "g" in the
  * replacement make sure to pad to the worst case length.
  */
-#define alternative_input(oldinstr, newinstr, feature, input...)	\
-	asm volatile (ALTERNATIVE(oldinstr, newinstr, feature)		\
-		      : : input)
+#define alternative_input(oldinstr, newinstr, feature, input...)        \
+    asm_inline volatile (                                               \
+        ALTERNATIVE(oldinstr, newinstr, feature)                        \
+        :: input )
 
 /* Like alternative_input, but with a single output argument */
-#define alternative_io(oldinstr, newinstr, feature, output, input...)	\
-	asm volatile (ALTERNATIVE(oldinstr, newinstr, feature)		\
-		      : output : input)
+#define alternative_io(oldinstr, newinstr, feature, output, input...)   \
+    asm_inline volatile (                                               \
+        ALTERNATIVE(oldinstr, newinstr, feature)                        \
+        : output : input )
 
 /*
  * This is similar to alternative_io. But it has two features and
@@ -160,11 +165,12 @@ extern void alternative_instructions(void);
  * Otherwise, if CPU has feature1, newinstr1 is used.
  * Otherwise, oldinstr is used.
  */
-#define alternative_io_2(oldinstr, newinstr1, feature1, newinstr2,	\
-			 feature2, output, input...)			\
-	asm volatile(ALTERNATIVE_2(oldinstr, newinstr1, feature1,	\
-				   newinstr2, feature2)			\
-		     : output : input)
+#define alternative_io_2(oldinstr, newinstr1, feature1, newinstr2,      \
+                         feature2, output, input...)                    \
+    asm_inline volatile (                                               \
+        ALTERNATIVE_2(oldinstr, newinstr1, feature1,                    \
+                      newinstr2, feature2)                              \
+        : output : input )
 
 /* Use this macro(s) if you need more than one output parameter. */
 #define ASM_OUTPUT2(a...) a
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index d85b52b9d522..56bea252cc5a 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -431,13 +431,14 @@ static always_inline void __invvpid(unsigned long type, u16 vpid, u64 gva)
     }  operand = {vpid, 0, gva};
 
     /* Fix up #UD exceptions which occur when TLBs are flushed before VMXON. */
-    asm goto ( "1: invvpid %[operand], %[type]\n\t"
-               "   jbe %l[vmfail]\n\t"
-               "2:" _ASM_EXTABLE(1b, 2b)
-               :
-               : [operand] "m" (operand), [type] "r" (type)
-               : "memory"
-               : vmfail );
+    asm_inline goto (
+        "1: invvpid %[operand], %[type]\n\t"
+        "   jbe %l[vmfail]\n\t"
+        "2:" _ASM_EXTABLE(1b, 2b)
+        :
+        : [operand] "m" (operand), [type] "r" (type)
+        : "memory"
+        : vmfail );
     return;
 
  vmfail:
diff --git a/xen/arch/x86/include/asm/uaccess.h b/xen/arch/x86/include/asm/uaccess.h
index 2d01669b9610..719d053936b9 100644
--- a/xen/arch/x86/include/asm/uaccess.h
+++ b/xen/arch/x86/include/asm/uaccess.h
@@ -154,7 +154,7 @@ struct __large_struct { unsigned long buf[100]; };
  * aliasing issues.
  */
 #define put_unsafe_asm(x, addr, GUARD, err, itype, rtype, ltype, errret) \
-	__asm__ __volatile__(						\
+	asm_inline volatile (						\
 		GUARD(							\
 		"	guest_access_mask_ptr %[ptr], %[scr1], %[scr2]\n" \
 		)							\
@@ -171,7 +171,7 @@ struct __large_struct { unsigned long buf[100]; };
 		  "[ptr]" (addr), [errno] "i" (errret))
 
 #define get_unsafe_asm(x, addr, GUARD, err, rtype, ltype, errret)	\
-	__asm__ __volatile__(						\
+	asm_inline volatile (						\
 		GUARD(							\
 		"	guest_access_mask_ptr %[ptr], %[scr1], %[scr2]\n" \
 		)							\
diff --git a/xen/arch/x86/pv/misc-hypercalls.c b/xen/arch/x86/pv/misc-hypercalls.c
index b529f00ea127..17030d800d1b 100644
--- a/xen/arch/x86/pv/misc-hypercalls.c
+++ b/xen/arch/x86/pv/misc-hypercalls.c
@@ -230,15 +230,16 @@ long do_set_segment_base(unsigned int which, unsigned long base)
          * Anyone wanting to check for errors from this hypercall should
          * re-read %gs and compare against the input.
          */
-        asm volatile ( "1: mov %[sel], %%gs\n\t"
-                       ".section .fixup, \"ax\", @progbits\n\t"
-                       "2: mov %k[flat], %%gs\n\t"
-                       "   xor %[sel], %[sel]\n\t"
-                       "   jmp 1b\n\t"
-                       ".previous\n\t"
-                       _ASM_EXTABLE(1b, 2b)
-                       : [sel] "+r" (sel)
-                       : [flat] "r" (FLAT_USER_DS32) );
+        asm_inline volatile (
+            "1: mov %[sel], %%gs\n\t"
+            ".section .fixup, \"ax\", @progbits\n\t"
+            "2: mov %k[flat], %%gs\n\t"
+            "   xor %[sel], %[sel]\n\t"
+            "   jmp 1b\n\t"
+            ".previous\n\t"
+            _ASM_EXTABLE(1b, 2b)
+            : [sel] "+r" (sel)
+            : [flat] "r" (FLAT_USER_DS32) );
 
         /* Update the cache of the inactive base, as read from the GDT/LDT. */
         v->arch.pv.gs_base_user = read_gs_base();
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 25e0d5777e6e..c94779b4ad4f 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -126,27 +126,29 @@ void show_code(const struct cpu_user_regs *regs)
      * Copy forward from regs->rip.  In the case of a fault, %ecx contains the
      * number of bytes remaining to copy.
      */
-    asm volatile ("1: rep movsb; 2:"
-                  _ASM_EXTABLE(1b, 2b)
-                  : "=&c" (missing_after),
-                    "=&D" (tmp), "=&S" (tmp)
-                  : "0" (ARRAY_SIZE(insns_after)),
-                    "1" (insns_after),
-                    "2" (regs->rip));
+    asm_inline volatile (
+        "1: rep movsb; 2:"
+        _ASM_EXTABLE(1b, 2b)
+        : "=&c" (missing_after),
+          "=&D" (tmp), "=&S" (tmp)
+        : "0" (ARRAY_SIZE(insns_after)),
+          "1" (insns_after),
+          "2" (regs->rip) );
 
     /*
      * Copy backwards from regs->rip - 1.  In the case of a fault, %ecx
      * contains the number of bytes remaining to copy.
      */
-    asm volatile ("std;"
-                  "1: rep movsb;"
-                  "2: cld;"
-                  _ASM_EXTABLE(1b, 2b)
-                  : "=&c" (missing_before),
-                    "=&D" (tmp), "=&S" (tmp)
-                  : "0" (ARRAY_SIZE(insns_before)),
-                    "1" (insns_before + ARRAY_SIZE(insns_before) - 1),
-                    "2" (regs->rip - 1));
+    asm_inline volatile (
+        "std;"
+        "1: rep movsb;"
+        "2: cld;"
+        _ASM_EXTABLE(1b, 2b)
+        : "=&c" (missing_before),
+          "=&D" (tmp), "=&S" (tmp)
+        : "0" (ARRAY_SIZE(insns_before)),
+          "1" (insns_before + ARRAY_SIZE(insns_before) - 1),
+          "2" (regs->rip - 1) );
     clac();
 
     printk("Xen code around <%p> (%ps)%s:\n",
@@ -524,12 +526,14 @@ static void show_trace(const struct cpu_user_regs *regs)
     printk("Xen call trace:\n");
 
     /* Guarded read of the stack top. */
-    asm ( "1: mov %[data], %[tos]; 2:\n"
-          ".pushsection .fixup,\"ax\"\n"
-          "3: movb $1, %[fault]; jmp 2b\n"
-          ".popsection\n"
-          _ASM_EXTABLE(1b, 3b)
-          : [tos] "+r" (tos), [fault] "+qm" (fault) : [data] "m" (*sp) );
+    asm_inline (
+        "1: mov %[data], %[tos]; 2:\n"
+        ".pushsection .fixup,\"ax\"\n"
+        "3: movb $1, %[fault]; jmp 2b\n"
+        ".popsection\n"
+        _ASM_EXTABLE(1b, 3b)
+        : [tos] "+r" (tos), [fault] "+qm" (fault)
+        : [data] "m" (*sp) );
 
     /*
      * If RIP looks sensible, or the top of the stack doesn't, print RIP at
diff --git a/xen/arch/x86/usercopy.c b/xen/arch/x86/usercopy.c
index 7ab2009efe4c..a24b52cc66c1 100644
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -19,7 +19,7 @@ unsigned int copy_to_guest_ll(void __user *to, const void *from, unsigned int n)
     GUARD(unsigned dummy);
 
     stac();
-    asm volatile (
+    asm_inline volatile (
         GUARD(
         "    guest_access_mask_ptr %[to], %q[scratch1], %q[scratch2]\n"
         )
@@ -39,7 +39,7 @@ unsigned int copy_from_guest_ll(void *to, const void __user *from, unsigned int
     unsigned dummy;
 
     stac();
-    asm volatile (
+    asm_inline volatile (
         GUARD(
         "    guest_access_mask_ptr %[from], %q[scratch1], %q[scratch2]\n"
         )
@@ -101,7 +101,7 @@ unsigned int clear_guest_pv(void __user *to, unsigned int n)
         long dummy;
 
         stac();
-        asm volatile (
+        asm_inline volatile (
             "    guest_access_mask_ptr %[to], %[scratch1], %[scratch2]\n"
             "1:  rep stosb\n"
             "2:\n"
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 15 19:56:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 19:56:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985923.1371717 (Exim 4.92)
	(envelope-from )
	id 1uFegS-0004nW-Rq; Thu, 15 May 2025 19:56:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985923.1371717; Thu, 15 May 2025 19:56: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 1uFegS-0004nN-OE; Thu, 15 May 2025 19:56:00 +0000
Received: by outflank-mailman (input) for mailman id 985923;
 Thu, 15 May 2025 19:55:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFegQ-0004Ph-Ui
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 19:55:59 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9e81310e-31c6-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 21:55:58 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-43cfe63c592so13898975e9.2
 for ; Thu, 15 May 2025 12:55:58 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442ebd6fe86sm78320035e9.0.2025.05.15.12.55.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 15 May 2025 12:55: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" 
X-Inumbo-ID: 9e81310e-31c6-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747338957; x=1747943757; 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;
        bh=4W3bFdSiNP3j+BlDRwES7FFOKrPIgmWmQytxBIEpGDk=;
        b=OYnQy+LVL05zUwsCKJ2B19kpdyeOHooqHfXCtQc+bF6KnJRBVo3IpSldsUuWRwuHrQ
         hCHMoR65jTvgGSysHBjZQmaeMZmBo3B+wa5y8IDunwjV+8s0aOCluBwSKNEGNcH+fTW9
         pCxO76wpGy17LUO7Rt7ghH+3gka2c33Xejai8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747338957; x=1747943757;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4W3bFdSiNP3j+BlDRwES7FFOKrPIgmWmQytxBIEpGDk=;
        b=ptm6ZY7iLu2Qt9Rr7vPMTXtg46bbnASj/h+ih/Xqx/WkD/u1EyXC0NdnKhtenRATdA
         ypS9+kKXhHfA9Ro/KIBCOhD6HZPvlF6OnNTxxsHRH0PutgoO1eE0YwAil9LizeeJdaMb
         3JW4crwB98iOpgOFQHfPppbCkv+zzESnTMUOOG7CBtyJxPAyfR+Br/rgdgg4aQN5T0Mq
         gv5A/7pMgsQZCR2ORii6rwioqqjJc56oFgAyI/LXdy/X/dqPMI60mNyagz19pEvA7cmp
         hFX29vLG9070JVnBJ/dYa5Q+BW1NnXbM67jIasnt+lU7zXz3D1GANiN7CFb7LLK5ZCkO
         14ng==
X-Gm-Message-State: AOJu0YxeiM7X6wJwDeTw22G7ApLX91pVKbwiaqT2dKb0XLIFTQJUdmbO
	hxhBnQRICkkhM/Qxz34gMnTwhLD4fbBWQNPcqORATa1cTv1mVch0fbdLtXMbGS7E7DpSYDGPUdj
	Wwkeg
X-Gm-Gg: ASbGncssngoMbIU5UpSoyhWEP/MskKH04dWFvnNGSMbnrwjYnsmx/7Jr+Z5T5SIeJcU
	5LpfL8323JGqMELT404A2ZEbpnYwSJNCQ4czCDrNmrzYty1Uedi/KyL/ABAx0msEo6rUQO5FL/E
	/hzVDTBqO3b1d70eGzDZIipCgu/QCRcb21Yb3Xnhdmqaj1V+/7gaiSOTcAM1tCz7/oNitu4rvDg
	LEy+EQWEgUrCe0tyc7WaBvZ5ftKhy2dL4LJolq5bQBvfllx6k4610gQPh5f4xoXH0Y0GU/DYrPZ
	62GRAya2ykjrScGSmk+2UyO5rnCRUbyGuBI0820VpVQp9BiS4PiEqsKCUzIiq5Fb/ouh4Xn6pZP
	KPS22EBHwKL4WzmpkKF5W+/ax
X-Google-Smtp-Source: AGHT+IFb/jz0BthZ+Z/YQ0baZ3psCUhHZOTo012R1k35FNTiqHBqK3W60z9v8M45Gfe9/WL06DMbEQ==
X-Received: by 2002:a05:600c:a105:b0:441:ac58:eb31 with SMTP id 5b1f17b1804b1-442fda3038amr4765735e9.20.1747338957328;
        Thu, 15 May 2025 12:55:57 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [PATCH 3/3] ARM: Use asm_inline for ALTERNATIVE()
Date: Thu, 15 May 2025 20:55:49 +0100
Message-Id: <20250515195549.3703017-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250515195549.3703017-1-andrew.cooper3@citrix.com>
References: <20250515195549.3703017-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

... when there really are only a few instructions in line.

In some cases, reformat to reduce left-hand margine space.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 

v2:
 * New, split out of previous single patch
---
 xen/arch/arm/include/asm/alternative.h    |  4 +--
 xen/arch/arm/include/asm/arm64/flushtlb.h |  4 +--
 xen/arch/arm/include/asm/arm64/io.h       | 43 ++++++++++++++---------
 xen/arch/arm/include/asm/cpuerrata.h      |  8 ++---
 xen/arch/arm/include/asm/cpufeature.h     |  8 ++---
 xen/arch/arm/include/asm/page.h           | 12 ++++---
 xen/arch/arm/include/asm/processor.h      |  7 ++--
 xen/arch/arm/include/asm/sysregs.h        | 10 +++---
 xen/arch/arm/mmu/p2m.c                    |  3 +-
 9 files changed, 58 insertions(+), 41 deletions(-)

diff --git a/xen/arch/arm/include/asm/alternative.h b/xen/arch/arm/include/asm/alternative.h
index 22477d9497a3..1563f03a0f5a 100644
--- a/xen/arch/arm/include/asm/alternative.h
+++ b/xen/arch/arm/include/asm/alternative.h
@@ -209,9 +209,9 @@ alternative_endif
 #endif  /*  __ASSEMBLY__  */
 
 /*
- * Usage: asm(ALTERNATIVE(oldinstr, newinstr, feature));
+ * Usage: asm_inline (ALTERNATIVE(oldinstr, newinstr, feature));
  *
- * Usage: asm(ALTERNATIVE(oldinstr, newinstr, feature, CONFIG_FOO));
+ * Usage: asm_inline (ALTERNATIVE(oldinstr, newinstr, feature, CONFIG_FOO));
  * N.B. If CONFIG_FOO is specified, but not selected, the whole block
  *      will be omitted, including oldinstr.
  */
diff --git a/xen/arch/arm/include/asm/arm64/flushtlb.h b/xen/arch/arm/include/asm/arm64/flushtlb.h
index 45642201d147..3b99c11b50d1 100644
--- a/xen/arch/arm/include/asm/arm64/flushtlb.h
+++ b/xen/arch/arm/include/asm/arm64/flushtlb.h
@@ -31,7 +31,7 @@
 #define TLB_HELPER(name, tlbop, sh)              \
 static inline void name(void)                    \
 {                                                \
-    asm volatile(                                \
+    asm_inline volatile (                        \
         "dsb  "  # sh  "st;"                     \
         "tlbi "  # tlbop  ";"                    \
         ALTERNATIVE(                             \
@@ -55,7 +55,7 @@ static inline void name(void)                    \
 #define TLB_HELPER_VA(name, tlbop)               \
 static inline void name(vaddr_t va)              \
 {                                                \
-    asm volatile(                                \
+    asm_inline volatile (                        \
         "tlbi "  # tlbop  ", %0;"                \
         ALTERNATIVE(                             \
             "nop; nop;",                         \
diff --git a/xen/arch/arm/include/asm/arm64/io.h b/xen/arch/arm/include/asm/arm64/io.h
index 7d5959877759..ac90b729c44d 100644
--- a/xen/arch/arm/include/asm/arm64/io.h
+++ b/xen/arch/arm/include/asm/arm64/io.h
@@ -51,40 +51,51 @@ static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
 static inline u8 __raw_readb(const volatile void __iomem *addr)
 {
         u8 val;
-        asm volatile(ALTERNATIVE("ldrb %w0, [%1]",
-                                 "ldarb %w0, [%1]",
-                                 ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
-                     : "=r" (val) : "r" (addr));
+
+        asm_inline volatile (
+            ALTERNATIVE("ldrb %w0, [%1]",
+                        "ldarb %w0, [%1]",
+                        ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
+            : "=r" (val) : "r" (addr) );
+
         return val;
 }
 
 static inline u16 __raw_readw(const volatile void __iomem *addr)
 {
         u16 val;
-        asm volatile(ALTERNATIVE("ldrh %w0, [%1]",
-                                 "ldarh %w0, [%1]",
-                                 ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
-                     : "=r" (val) : "r" (addr));
+        asm_inline volatile (
+            ALTERNATIVE("ldrh %w0, [%1]",
+                        "ldarh %w0, [%1]",
+                        ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
+            : "=r" (val) : "r" (addr) );
+
         return val;
 }
 
 static inline u32 __raw_readl(const volatile void __iomem *addr)
 {
         u32 val;
-        asm volatile(ALTERNATIVE("ldr %w0, [%1]",
-                                 "ldar %w0, [%1]",
-                                 ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
-                     : "=r" (val) : "r" (addr));
+
+        asm_inline volatile (
+            ALTERNATIVE("ldr %w0, [%1]",
+                        "ldar %w0, [%1]",
+                        ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
+            : "=r" (val) : "r" (addr) );
+
         return val;
 }
 
 static inline u64 __raw_readq(const volatile void __iomem *addr)
 {
         u64 val;
-        asm volatile(ALTERNATIVE("ldr %0, [%1]",
-                                 "ldar %0, [%1]",
-                                 ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
-                     : "=r" (val) : "r" (addr));
+
+        asm_inline volatile (
+            ALTERNATIVE("ldr %0, [%1]",
+                        "ldar %0, [%1]",
+                        ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
+            : "=r" (val) : "r" (addr) );
+
         return val;
 }
 
diff --git a/xen/arch/arm/include/asm/cpuerrata.h b/xen/arch/arm/include/asm/cpuerrata.h
index 8d7e7b9375bd..1799a16d7e7f 100644
--- a/xen/arch/arm/include/asm/cpuerrata.h
+++ b/xen/arch/arm/include/asm/cpuerrata.h
@@ -16,10 +16,10 @@ static inline bool check_workaround_##erratum(void)             \
     {                                                           \
         register_t ret;                                         \
                                                                 \
-        asm volatile (ALTERNATIVE("mov %0, #0",                 \
-                                  "mov %0, #1",                 \
-                                  feature)                      \
-                      : "=r" (ret));                            \
+        asm_inline volatile (                                   \
+            ALTERNATIVE("mov %0, #0",                           \
+                        "mov %0, #1", feature)                  \
+            : "=r" (ret) );                                     \
                                                                 \
         return unlikely(ret);                                   \
     }                                                           \
diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
index 50297e53d90e..b6df18801166 100644
--- a/xen/arch/arm/include/asm/cpufeature.h
+++ b/xen/arch/arm/include/asm/cpufeature.h
@@ -102,10 +102,10 @@ static inline bool cpus_have_cap(unsigned int num)
 #define cpus_have_const_cap(num) ({                 \
         register_t __ret;                           \
                                                     \
-        asm volatile (ALTERNATIVE("mov %0, #0",     \
-                                  "mov %0, #1",     \
-                                  num)              \
-                      : "=r" (__ret));              \
+        asm_inline volatile (                       \
+            ALTERNATIVE("mov %0, #0",               \
+                        "mov %0, #1", num)          \
+            : "=r" (__ret) );                       \
                                                     \
         unlikely(__ret);                            \
         })
diff --git a/xen/arch/arm/include/asm/page.h b/xen/arch/arm/include/asm/page.h
index 69f817d1e68a..27bc96b9f401 100644
--- a/xen/arch/arm/include/asm/page.h
+++ b/xen/arch/arm/include/asm/page.h
@@ -176,7 +176,8 @@ static inline int invalidate_dcache_va_range(const void *p, unsigned long size)
     {
         size -= dcache_line_bytes - ((uintptr_t)p & cacheline_mask);
         p = (void *)((uintptr_t)p & ~cacheline_mask);
-        asm volatile (__clean_and_invalidate_dcache_one(0) : : "r" (p));
+        asm_inline volatile (
+            __clean_and_invalidate_dcache_one(0) :: "r" (p) );
         p += dcache_line_bytes;
     }
 
@@ -185,7 +186,8 @@ static inline int invalidate_dcache_va_range(const void *p, unsigned long size)
         asm volatile (__invalidate_dcache_one(0) : : "r" (p + idx));
 
     if ( size > 0 )
-        asm volatile (__clean_and_invalidate_dcache_one(0) : : "r" (p + idx));
+        asm_inline volatile (
+            __clean_and_invalidate_dcache_one(0) :: "r" (p + idx) );
 
     dsb(sy);           /* So we know the flushes happen before continuing */
 
@@ -209,7 +211,7 @@ static inline int clean_dcache_va_range(const void *p, unsigned long size)
     p = (void *)((uintptr_t)p & ~cacheline_mask);
     for ( ; size >= dcache_line_bytes;
             idx += dcache_line_bytes, size -= dcache_line_bytes )
-        asm volatile (__clean_dcache_one(0) : : "r" (p + idx));
+        asm_inline volatile ( __clean_dcache_one(0) : : "r" (p + idx) );
     dsb(sy);           /* So we know the flushes happen before continuing */
     /* ARM callers assume that dcache_* functions cannot fail. */
     return 0;
@@ -247,7 +249,7 @@ static inline int clean_and_invalidate_dcache_va_range
     if ( sizeof(x) > MIN_CACHELINE_BYTES || sizeof(x) > alignof(x) )    \
         clean_dcache_va_range(_p, sizeof(x));                           \
     else                                                                \
-        asm volatile (                                                  \
+        asm_inline volatile (                                           \
             "dsb sy;"   /* Finish all earlier writes */                 \
             __clean_dcache_one(0)                                       \
             "dsb sy;"   /* Finish flush before continuing */            \
@@ -259,7 +261,7 @@ static inline int clean_and_invalidate_dcache_va_range
     if ( sizeof(x) > MIN_CACHELINE_BYTES || sizeof(x) > alignof(x) )    \
         clean_and_invalidate_dcache_va_range(_p, sizeof(x));            \
     else                                                                \
-        asm volatile (                                                  \
+        asm_inline volatile (                                           \
             "dsb sy;"   /* Finish all earlier writes */                 \
             __clean_and_invalidate_dcache_one(0)                        \
             "dsb sy;"   /* Finish flush before continuing */            \
diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
index 60b587db697f..9cbc4f911061 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -607,9 +607,10 @@ register_t get_default_cptr_flags(void);
 #define SYNCHRONIZE_SERROR(feat)                                  \
     do {                                                          \
         ASSERT(local_abort_is_enabled());                         \
-        asm volatile(ALTERNATIVE("dsb sy; isb",                   \
-                                 "nop; nop", feat)                \
-                                 : : : "memory");                 \
+        asm_inline volatile (                                     \
+            ALTERNATIVE("dsb sy; isb",                            \
+                        "nop; nop", feat)                         \
+            ::: "memory" );                                       \
     } while (0)
 
 /*
diff --git a/xen/arch/arm/include/asm/sysregs.h b/xen/arch/arm/include/asm/sysregs.h
index 61e30c9e517c..5c2d362be3d8 100644
--- a/xen/arch/arm/include/asm/sysregs.h
+++ b/xen/arch/arm/include/asm/sysregs.h
@@ -22,11 +22,13 @@ static inline register_t read_sysreg_par(void)
      * DMB SY before and after accessing it, as part of the workaround for the
      * errata 1508412.
      */
-    asm volatile(ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412,
-                 CONFIG_ARM64_ERRATUM_1508412));
+    asm_inline volatile (
+        ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412,
+                    CONFIG_ARM64_ERRATUM_1508412) );
     par_el1 = READ_SYSREG64(PAR_EL1);
-    asm volatile(ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412,
-                 CONFIG_ARM64_ERRATUM_1508412));
+    asm_inline volatile (
+        ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412,
+                    CONFIG_ARM64_ERRATUM_1508412) );
 
     return par_el1;
 }
diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
index 7642dbc7c55b..d96078f547d5 100644
--- a/xen/arch/arm/mmu/p2m.c
+++ b/xen/arch/arm/mmu/p2m.c
@@ -228,7 +228,8 @@ void p2m_restore_state(struct vcpu *n)
      * registers associated to EL1/EL0 translations regime have been
      * synchronized.
      */
-    asm volatile(ALTERNATIVE("nop", "isb", ARM64_WORKAROUND_AT_SPECULATE));
+    asm_inline volatile (
+        ALTERNATIVE("nop", "isb", ARM64_WORKAROUND_AT_SPECULATE) );
     WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
 
     last_vcpu_ran = &p2m->last_vcpu_ran[smp_processor_id()];
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 15 20:13:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 20:13:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985966.1371727 (Exim 4.92)
	(envelope-from )
	id 1uFews-0000Od-DS; Thu, 15 May 2025 20:12:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985966.1371727; Thu, 15 May 2025 20: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 1uFews-0000OW-Ar; Thu, 15 May 2025 20:12:58 +0000
Received: by outflank-mailman (input) for mailman id 985966;
 Thu, 15 May 2025 20:12:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFewq-0000ON-U3
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 20:12:57 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2405::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id faca22a6-31c8-11f0-9ffb-bf95429c2676;
 Thu, 15 May 2025 22:12:54 +0200 (CEST)
Received: from SJ0PR13CA0206.namprd13.prod.outlook.com (2603:10b6:a03:2c3::31)
 by SJ0PR12MB7008.namprd12.prod.outlook.com (2603:10b6:a03:486::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.32; Thu, 15 May
 2025 20:12:49 +0000
Received: from SJ5PEPF000001ED.namprd05.prod.outlook.com
 (2603:10b6:a03:2c3:cafe::d0) by SJ0PR13CA0206.outlook.office365.com
 (2603:10b6:a03:2c3::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.19 via Frontend Transport; Thu,
 15 May 2025 20:12:49 +0000
Received: from SATLEXMB04.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_128_GCM_SHA256) id
 15.20.8722.18 via Frontend Transport; Thu, 15 May 2025 20:12:49 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 15 May
 2025 15:12:47 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 15 May
 2025 15:12:47 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 15 May 2025 15:12: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" 
X-Inumbo-ID: faca22a6-31c8-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Tk66sZPBRraqtp+2D0sUrsgGQR0/cKRqlI69sfiXH/Pz0dujCOjdc/HIswhvbCqHUsPqOWl3ssJ1JTJMC+A32BfuAgKWCTqW6orG6brWnamJK7sNWQw6N90CIgZbHho7glShs+5gZuVT4c9RA53p2HFttccaVfWScG6Zhty4UfviGYeveknCNZ8G/MKRIbzRES/2TT3+WqIRNhEntUrFj6sIY2KjpYRoBh/mVB9JkEGfAqtLGJUXEaoiL7ZLUa6sponMEDI+2IdXzyyMjRLp6Srhy/MwZq3a6Mdl2pxaGP1zx71/ihviAkMNyeRFIJpyp/lQT6wkL9x2w4Zep2QSIA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YbjAW9090cd/bjSRbjftgw3ADh8FbS19dgg6yyE6XXs=;
 b=Shl/YlGbOIkcMm902EsFnjpxmO22G2wROc3i8TgIg/Qo21+LEqGrNqQk0IvfMHAPgHOeLXbFDy3kSTktllDRbDz5oJ7Hj/Htstu3je1dHP17tHfls9uobVb1WhNEu+t/eeeFmckrhIFS9TFG7+fXj5r+hdSYviFPMGs0KFc7s3st7IvfIVUHooq5c2+DTOcpHetaIFHSqEaRV9Hf6pUhysauBL/Kb8HRfB3cMOnAlR4aXDFL0DxyZlqxxq7ad2EUZ5xUNdTcYemKLXxuRhJ2oPkSktYccJkJyE3ZWz7DnbTkxnzgdjH4cQODOXTQ1G+MJzZSWfc2+ECrdAsk3XCA2g==
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=YbjAW9090cd/bjSRbjftgw3ADh8FbS19dgg6yyE6XXs=;
 b=gkn4UQjtDD8xRU0dv5bQD5qLU3W+NRgQEWsFrzlAEZ8LeCJwLMiFdzO2saThboeQ9uTM2DYJ8SbcgEGNl83/VdqrTkplwoXhj1sdm18kFz2ZtJ8hmr2X4/cBkkcw/lcDJFABRXat9eVh3BHVCyTTpLKKcdvR4dc4FCmHKCqsCZ4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Anthony PERARD
	, Juergen Gross 
Subject: [RFC PATCH v3] xenconsole: Add connected flag
Date: Thu, 15 May 2025 16:12:45 -0400
Message-ID: <20250515201245.80612-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001ED:EE_|SJ0PR12MB7008:EE_
X-MS-Office365-Filtering-Correlation-Id: 16ae0ad1-216b-4ad2-fd69-08dd93ecdd61
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?WHVYJLCNR6zVgP9350kci3qrbzEm2N1cub0Y87IjrE6ueLUx/hxNsbWoLQrY?=
 =?us-ascii?Q?J2lvTZucJfuJb8dkwJEtSwSQpuJF/94t5exSILYHs3ASlc0rbXbqejlDPrzG?=
 =?us-ascii?Q?yaXngYzVINE/6pij1ogjgCYWe9F1WoC0a1fwowIxaCAF7XI7Pa3xHlDcAkJZ?=
 =?us-ascii?Q?I/Dahs1/WbTKgD5L+DuxQI2v8w/sjYtUHKHuv+8HxipSbaLDRjZa7XEhYJfP?=
 =?us-ascii?Q?I4RjsikwkKp9Up6nXT7PXXgzg4FMeiLhFJTxojPow+u3RU2ZZmgIaSelEJF4?=
 =?us-ascii?Q?a4nfgorHkXTCun7q9chPSBTiXR/4K6v740NcVTfcoXOeytdG7bDeHL70/OIa?=
 =?us-ascii?Q?QU4SGW4SPIraNv5qUfbQjie34h8rzfifwK9o/gpmHzO+jr3YXWednxUny8oB?=
 =?us-ascii?Q?1CnRliZ2zO2VG1WtsiNPX24hCItefVKJEW0j36e57C24msL8B8HVThV/MPFm?=
 =?us-ascii?Q?bjS+ay4WILfCRqPaghmowA75EvkMsAhi7CXxYcHyXyCuBWsleHXFUwSHrmER?=
 =?us-ascii?Q?sRalFvFWfsOeWl399b8ZuDwXulxwuTZq4Eo+E6PCztJ90xWkMPBWLQrUUXY5?=
 =?us-ascii?Q?t7pelji/3UnFwEWm/4uflCMvWqvGb9MgdBYD+gdyQecqw4LIvAIBJJjHoVay?=
 =?us-ascii?Q?d6DsVctUKpgcgJ2iuC14T9rZUGV6JAKSIrc/rKN4fOD6NpqwybZ+gFPypB5g?=
 =?us-ascii?Q?aBJwogyTxDGUrogbUfBfLgmvXifMlcgGqvUODz/U7L28AM7wlm15Swuhx3r/?=
 =?us-ascii?Q?FqcmDWtUy5L4P5Vi7IWkd5UXb4CRWV6nbRh2ry3PJ/KewdxQHGYkhyvCIaBy?=
 =?us-ascii?Q?6Unzx8aYIkCCphWX5MY/bSkwQhCvQzSQqh0Y7FmqBau/rNHeAOsCS3/YgUh2?=
 =?us-ascii?Q?qzAKuQ0wDmvhjncSfy/OZlVyLSKHHR/oBLffwTgPzuAF6m2sOaCZwz6iwX6t?=
 =?us-ascii?Q?IgqOLgceNlw33una+3GKicFZNNGESQSe8gCmO29EScGgrXWWl7DrwWNweed0?=
 =?us-ascii?Q?hX5U0CXHRpBij8Xb/AoWTRSw8TNcpDfD5kHEhPL3PQf4zEAb2rRd69PzNoU0?=
 =?us-ascii?Q?WuBaY9+OcYRawEfYJZH6m9EdzfdbGb1mPlNj95dIP3WCq3hDN8cn6TCK+EQk?=
 =?us-ascii?Q?rYquNjmyeiAqKTzjnnpgMi4Ku7/0kPg4va1LJHViFr3kgvY4C0bLjbeySTEw?=
 =?us-ascii?Q?kygJirl8g8jqAzDi8dCMwv4zI9Zx/O4WJBqA/NfJd/KgFPBNNIowif8Gk1bN?=
 =?us-ascii?Q?fNiqVOncaTwu20rbToXPiIvJri1y7GMHAjYvZMRi1np8yH0bh7Gn+bl/kSx7?=
 =?us-ascii?Q?eM/vzUL+wF9W60q1vut7EGryHvHmd+6PJP2e5c1ZxptgmNJEoCdZfefO1FJ4?=
 =?us-ascii?Q?GME9rqEJXecmUQppggMfEYzPE3Yms8XitGw5WVjY4LwgPtlcKYusK5tSkSmG?=
 =?us-ascii?Q?0bvzPmhav4WP5xUqi5kAoQB6v8ifNg5l+g7vXCpZrK1CI3X6L9yTeM0qXfH9?=
 =?us-ascii?Q?zrACeY3HHEGzhvcqN0j+AQJbLsQEKwBX7EOA?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2025 20:12:49.0965
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 16ae0ad1-216b-4ad2-fd69-08dd93ecdd61
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=[SATLEXMB04.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: SJ0PR12MB7008

Sending again with an expanded description.  RFC to have a discussion
about the approach.

With hyperlaunch, a domU can start before its console ring is connected
by xenconsoled.  With nothing emptying the ring, it can quickly fill
during boot.  In domU_write_console(), __write_console returns 0 when
the ring is full.  This loops spins until xenconsoled starts emptying
the ring:

        while (len) {
                ssize_t sent = __write_console(cons, data, len);

                if (sent < 0)
                        return sent;

                data += sent;
                len -= sent;

                if (unlikely(len))
                        HYPERVISOR_sched_op(SCHEDOP_yield, NULL);
        }

The goal of this patch is to add a way for the frontend to know when a
console is connected.  This patch adds a new flag to the end of the
console ring structure.  It is used for the backend to indicate that it
has connected and started servicing the page.

The two values are
XENCONSOLE_DISCONNECTED 1
XENCONSOLE_CONNECTED    0

XENCONSOLE_DISCONNECTED indicates to the guest that ring is
disconnected, so it will not be serviced.  The guest can avoid writing
into it in that case.  A domU can use console hypercalls and only
transition to the ring when it is connected and won't fill and block.

Once the backend (xenconsoled) maps and starts servicing the
console, the flag will be set to XENCONSOLE_CONNECTED (0) to indicate
the backend state to the frontend.

With the flag change, the backend sends an event channel notification so
the frontend can check the state.  Though this is not strictly
necessary.

The connected value as 0 will be match the default of a zero-ed console
page.  Hyperlaunch can set the flag to XENCONSOLE_DISCONNECTED and let
xenconsoled set to XENCONSOLE_CONNECTED.

In terms of compatibility:
Old domU drivers won't check the flag, so no change.
New domU running on a new xen/xenconsoled will wait for the flag.
New domU on an old xen/xenconsoled should only see a 0 for the flag and
behave as if connected.

Signed-off-by: Jason Andryuk 
---
v3:
Flip flag values so 0 is connected.

The other option would be to add distinct features and connected fields:
uint32_t features
uint32_t connected

New domUs would check features for a magic value or flag to then know
they can rely on connected transitioning.

I think making XENCONSOLE_CONNECTED == 0 side steps the need for
an additional features field.  As long as assuming zero-ed memory is
acceptable.  However, this only matters for a hyperlaunched guest -
xenconsoled will normally readily connect the console and set the value.

This assumes that existing frontends are not using the flag space for
some other use.

The idea of the event channel notification is to let the domU receive an
indication that xenconsoled is connected.  For xenstore, the xenstore
driver owns the event channel/irq and can rebind it.  For hvc_xen, the
hvc subsystem owns the irq, so it isn't readily available for rebinding.
Maybe this should just be dropped.

I had the idea for the kernel to use a static key and switch writing
from the hypercall to the PV ring once connected.  It didn't actually
work in my short attempt - I think changing the static key from within
an interupt was wrong.  I fell back to just checking the flag directly
without an optimization.  That would work and would make the event
channel notification unnecessary.
---
 tools/console/daemon/io.c       |  6 ++++++
 xen/include/public/io/console.h | 13 +++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index bb739bdb8c..10524eead7 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -731,6 +731,9 @@ static int console_create_ring(struct console *con)
 		con->ring_ref = ring_ref;
 	}
 
+	/* Mark the console as connected. */
+	con->interface->flag = XENCONSOLE_CONNECTED;
+
 	/* Go no further if port has not changed and we are still bound. */
 	if (remote_port == con->remote_port) {
 		xc_evtchn_status_t status = {
@@ -780,6 +783,9 @@ static int console_create_ring(struct console *con)
 	if (log_guest && (con->log_fd == -1))
 		con->log_fd = create_console_log(con);
 
+	/* Notify to check flags field. */
+	xenevtchn_notify(con->xce_handle, con->local_port);
+
  out:
 	return err;
 }
diff --git a/xen/include/public/io/console.h b/xen/include/public/io/console.h
index 4509b4b689..c16ef42ef4 100644
--- a/xen/include/public/io/console.h
+++ b/xen/include/public/io/console.h
@@ -19,6 +19,19 @@ struct xencons_interface {
     char out[2048];
     XENCONS_RING_IDX in_cons, in_prod;
     XENCONS_RING_IDX out_cons, out_prod;
+/*
+ * Flag values signaling from backend to frontend whether the console is
+ * connected.  i.e. Whether it will be serviced and emptied.
+ *
+ * The flag starts as disconnected.
+ */
+#define XENCONSOLE_DISCONNECTED 1
+/*
+ * The flag is set to connected when the backend connects and the console
+ * will be serviced.
+ */
+#define XENCONSOLE_CONNECTED    0
+    uint32_t flag;
 };
 
 #ifdef XEN_WANT_FLEX_CONSOLE_RING
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 15 20:25:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 15 May 2025 20:25:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.985974.1371736 (Exim 4.92)
	(envelope-from )
	id 1uFf8s-00029r-BJ; Thu, 15 May 2025 20:25:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 985974.1371736; Thu, 15 May 2025 20:25: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 1uFf8s-00029k-8l; Thu, 15 May 2025 20:25:22 +0000
Received: by outflank-mailman (input) for mailman id 985974;
 Thu, 15 May 2025 20:25:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFf8r-00029e-C7
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 20:25:21 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b77b061e-31ca-11f0-9eb6-5ba50f476ded;
 Thu, 15 May 2025 22:25:19 +0200 (CEST)
Received: from [172.27.3.244] ([76.133.66.138]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54FKOiar3684076
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Thu, 15 May 2025 13:24:45 -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" 
X-Inumbo-ID: b77b061e-31ca-11f0-9eb6-5ba50f476ded
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54FKOiar3684076
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747340686;
	bh=wKRRKSoScdWzuK4LlPzka9ZNoM1J1rtc/6+sJ4Fs1a4=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=gJKDU4MfBzkQmOtQ+brwkqwBjCxpL4Aoh5vuHM2zX07AMP1wouqPEkZ8t8Zginx95
	 wrmSUhstmpIg3W+8NMVN1RGPGaCkTLgFMExrIr20QNTYQRF46w1HKoY9N6cJgNIhyK
	 YfMXFT27hXu6tuIYlmOvWObaWramdivO/S6ueWlBtJVzLXf7gEn2jGGveuRTSOLWRj
	 ITIda0Xuqsd0g1cIxraDOX6VAsxa53a1lW4KgwnGcozRFvWOR9nw+SD9cjfC3VTvtl
	 a476jFIreR9+e7oW2CgniF1eXFe20zxaA95VXTbYl8aUxx0lJ3rvMXY0vwewtm9KAu
	 aiJHfA6ipWCUA==
Message-ID: <8d61e7a2-5eba-43c8-a38d-ca6ae59172b5@zytor.com>
Date: Thu, 15 May 2025 13:24:44 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to
 instruction interfaces
To: Xin Li ,
        =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 ,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        virtualization@lists.linux.dev, Peter Zijlstra 
Cc: Ajay Kaher ,
        Alexey Makhalov ,
        Broadcom internal kernel review list
 ,
        Thomas Gleixner
 , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        Boris Ostrovsky ,
        xen-devel@lists.xenproject.org
References: <20250506092015.1849-1-jgross@suse.com>
 <20250506092015.1849-6-jgross@suse.com>
 <722f5b30-20e9-4540-98e4-d211d7c44cbe@zytor.com>
 <9f4e33d5-9cb3-4079-b764-87a15265fd52@suse.com>
 
 
 <6cc20ef6-d8e5-4c74-89d9-6a949c84b397@suse.com>
 
 <652dfd63-e41c-4d7a-8fea-40509e8191ef@zytor.com>
Content-Language: en-US
From: "H. Peter Anvin" 
In-Reply-To: <652dfd63-e41c-4d7a-8fea-40509e8191ef@zytor.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5/15/25 00:32, Xin Li wrote:
> 
> Hi Juergen,
> 
> I have some update on this thread while working on it.
> 
> If we continue down the path of maintaining pvops MSR APIs as this patch
> series does, it seems we’ll need to duplicate the ALTERNATIVE code in
> three different places.
> 
> 1) The MSR access primitives defined in , which is used when
>     CONFIG_PARAVIRT=n.
> 
> 2) The pvops native MSR functions pv_native_{rd,wr}msr{,_safe}() defined
>     in arch/x86/kernel/paravirt.c, used when CONFIG_PARAVIRT=y on bare
>     metal.
> 
> 3) The pvops Xen MSR functions paravirt_{read,write}_msr{,_safe}()
>     defined in , used when CONFIG_PARAVIRT_XXL=y.
> 
> hpa had mentioned to me earlier that this would be a maintenance burden
> — something I only truly realized once I got hands-on with it.
> 
> Maybe you have something in mind to address it?
> 
> Also add PeterZ to the To list because he cares it.
> 

Having the code being duplicated is definitely not a good thing; 
although I'm not one of the x86 maintainers anymore, I would consider it 
a strong reason to NAK such a patchset.

At one point I was considering augmenting the alternatives framework to 
be able to call an ad hoc subroutine to generate the code. It would be 
useful in cases like this, where if PV is enabled it can make a callout 
to the currently-active PV code to query the desired code to be output.

There are 16 unused bits in the alternatives table (not counting the 14 
unused flag bits), which could be used for an enumeration of such 
subroutines, optionally split into 8 bits of function enumeration and 8 
bits of private data. In this case, the "replacement" pointer becomes 
available as a private pointer; possibly to a metadata structure used by 
the subroutine.

This could also be used to significantly enhance the static-immediate 
framework, by being able to have explicit code which handles the 
transformations instead of needing to rely on assembly hacks. That way 
we might even be able to do that kind of transformations for any 
ro_after_init value.

I think the biggest concern is how this would affect objtool, since 
objtool would now not have any kind of direct visibility into the 
possibly generated code. How to best feed the information objtool needs 
to it would be my biggest question (in part because I don't know what 
objtool would actually need.)

	-hpa



From xen-devel-bounces@lists.xenproject.org Fri May 16 00:21:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 00:21:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986064.1371747 (Exim 4.92)
	(envelope-from )
	id 1uFiox-0005gS-34; Fri, 16 May 2025 00:21:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986064.1371747; Fri, 16 May 2025 00: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 1uFiow-0005gL-VM; Fri, 16 May 2025 00:21:02 +0000
Received: by outflank-mailman (input) for mailman id 986064;
 Fri, 16 May 2025 00:21:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFiou-0005gF-3G
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 00:21:01 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2009::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a0e5cbd1-31eb-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 02:20:54 +0200 (CEST)
Received: from MW3PR12MB4427.namprd12.prod.outlook.com (2603:10b6:303:52::10)
 by LV8PR12MB9230.namprd12.prod.outlook.com (2603:10b6:408:186::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.29; Fri, 16 May
 2025 00:20:47 +0000
Received: from MW3PR12MB4427.namprd12.prod.outlook.com
 ([fe80::6caf:6197:ff82:57ee]) by MW3PR12MB4427.namprd12.prod.outlook.com
 ([fe80::6caf:6197:ff82:57ee%4]) with mapi id 15.20.8722.027; Fri, 16 May 2025
 00:20: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" 
X-Inumbo-ID: a0e5cbd1-31eb-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FSsI6KPfSmp1mbUGt3u24nomHRgRBQg0dcEN8dQV2davABOfRDUiV+NcOMgpALZRIU8+lPemrP0Y3clpUAle/MXo+0OaeOVoBqdbUlVLF/5whFm/0basuy/oICWEa99zLkpAF2St31bv22Y3p9bDM+jUHFs7TE9MptkpclHLLCXrb1pHapMhnwjNOsvY6hZs1YUQfGeYxC425F+rkGSvaUtdrrFWfgsD9Lds88WQCJe0dFrgptWsoU2td0OE3oo/tdUUDPj0OTznr5JHaqOfSLQFuJZNoS/QEc24z/hK3JrKXkYP0HJzEIzuSa5qbxHhH/ryp+W2NSrjizVdsgPn1g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=J4UoW+ElyrLamU1QNwkP9fZsIA5Jpidk1OM/4It0UQg=;
 b=NVss8rcKQbVwcv4zj7NXMR57lzaBio1PUHvHmIsI+5JZlgh5nYB6ScxWphCXK/BXNviuHzm7lcyh9MkxElfA2Nkl5CoDoRZc03xFfHFBbCjlH6WtXpN5IH08rT48BwxnkWaVuKJ0A3YY6ahkUayBjHxgQVainsWyF3AkwHu/EUYdGmdB37xC+WPEyGre0cEMvrmKtNPbzOuGPu7gz/WQGKAKb9Ou4yg7pjafzETg7Iz+0yFUdbfMFRiACKXtmD8IQR9bgiwhUdWBn2qpUaIGjVe6u443FaITiD1wFjtdjwAoK/+1VSTESJM70mPrURdK+ZbwomWPXPprR/3GRQPbtA==
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=J4UoW+ElyrLamU1QNwkP9fZsIA5Jpidk1OM/4It0UQg=;
 b=3ifptVDF057Fr6jJ3XUEh4s7ipj0RPcXhNNgUSC3WukSI3ygKSShKXP2bQYzhZRcJNB/pbFtBNvHc1hVw08ZUIqXC5fDHOrtXeR+lUL6/+RrXr0knJ3QIQK9C7N0/UkCuEaVlN+fHWe+If10VlcIPDqd9cDZs0uabCNfNnEdrX4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Content-Type: multipart/mixed; boundary="------------4vcTr0KMHNAmZnYteqWrR3WQ"
Message-ID: <87cefd87-4636-49f5-bf41-73709e3f9e93@amd.com>
Date: Thu, 15 May 2025 17:20:42 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vpci: fix handling of BAR overlaps with non-hole
 regions
To: xen-devel@lists.xenproject.org
References: <20250515084123.43289-1-roger.pau@citrix.com>
 <8b0fa959-6d00-4bfb-bef0-b3d1ae7ce7e0@suse.com>
 
Content-Language: en-US
From: "Lira, Victor M" 
In-Reply-To: 
X-ClientProxiedBy: SJ0PR13CA0163.namprd13.prod.outlook.com
 (2603:10b6:a03:2c7::18) To MW3PR12MB4427.namprd12.prod.outlook.com
 (2603:10b6:303:52::10)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MW3PR12MB4427:EE_|LV8PR12MB9230:EE_
X-MS-Office365-Filtering-Correlation-Id: 7334b420-ffe2-4fd4-e4ef-08dd940f8056
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|4053099003;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VEFpTWQ5d2hiVGpuVFdKZWxueGZKbEZNRjNlL3d2bzhqcTIrK3Q3SStQaVdz?=
 =?utf-8?B?cXc2dUhrU29XREtzT3NrdEVwM2FCZUFNL3pDaUxyWlQ0VythNm9YWFMxdW13?=
 =?utf-8?B?aS95RnZqREZKUmNheWcrb0tnTE42RlRJYWtaN0RsRlM2d3ErTVd4YmxXQ2Fa?=
 =?utf-8?B?RWdTdWtjS0lEZzR4citXb3lYL2lmYWM1dWRWSlUzWmZ1VEJySEw1c2hrN2w3?=
 =?utf-8?B?ZFNQZ2ZwR0E1SUJmRk9FeHN2MGM1Qi9nQVN1VjFrZ3lBdDV6MDhoc0ZSTnRV?=
 =?utf-8?B?UHgwL1RYM1lKWGRiM0tRWndVbTBvMkpaNDF4b3RXWjBpS0xnLzZ2bjJMSDZj?=
 =?utf-8?B?WVJncm5MZlprU29uVWh5cGpkRU1VQzlSOEhqclZlK3NZbUczSVNHTkVzZm9n?=
 =?utf-8?B?dXEvR2QrOVBEaE02NEkzR3JoNTBHaFV1c2pha1ZzRjVvam5HSUxBVHpaTzlP?=
 =?utf-8?B?a2o3elBsU010bnMrdTVyMjZnb3hqUVdnaHBSM0tYSHdBQlUrd0pabklTN1h2?=
 =?utf-8?B?NytMOUxIVm12b28vQVd1UmM1U0wyb3hyejlBbXNDRzlmb3NHUndobERDMGFn?=
 =?utf-8?B?N2MyRzB2aURKN3d4VnB3ZEE2RFFBVGdzbnp2TDdaUWFjaWtmUjBzNXNXenFK?=
 =?utf-8?B?em1OV1MzT1JhWmJGUnNNQ0REaXlFVjJ3Q3lKM2ZCb0YwR2h4T2FsUHQyTWwz?=
 =?utf-8?B?UXMwS2RtV05XL0pQLzNQN0VFYzk2b3VCS3J1TEVySFpRa2ZHeUI3dGxFekY5?=
 =?utf-8?B?MTlSUi94L21rZk9MVno0ZWx5SWVLbk1YazJkUXRsdHdUU3BLUWp0bzdXVlFU?=
 =?utf-8?B?eHI0d041NDhmZnZFaldRbGhVSUpnVHlGMFV1WWE1QkZBcG03UkxnZkZXeU1k?=
 =?utf-8?B?dE1XU2N0dTVtN1hUR0pONEp3ckdrbHJWcE1JTVBEOWRwSUhiZ3FGRTZsbHc2?=
 =?utf-8?B?V3hKUkw0TkNSNUpUYlNKWkZtcXM5TTIzTDlIREtydlc4bHVQbFVZUFdKQlVO?=
 =?utf-8?B?VXhEZy9iYi9ad0RGY3ZNY2pxWWNtQkErSVpldm9PUk94RVZERFkzL0lCU0F2?=
 =?utf-8?B?Tk1lZks4N3J6a0h5R1lTd25iL0JjSGRXdFVhSkIxMS81eWV1R3FyNmg0R0dj?=
 =?utf-8?B?b2ZZTWtHUGwxYW9vMU1INFNWL3VvcUNpa3Z1RkdaaTIva1ZqaURFV0w3b294?=
 =?utf-8?B?c1doLzJHYVNqOFVNZVpOSndOaEF0MC9DcEhQaitlQTgrbWlYU2VDbTVWK3pY?=
 =?utf-8?B?Yk1Ndm5IWVVxaVBsRlNaTEduMlU4Y0Ftem0rcDNGQ2xqZ2h2d1BmNTVqdG1C?=
 =?utf-8?B?SnVobnlDNWw1QWQrMktROFRmaGdrVVhBNkRLd3pzTzN1REsxYVNzVmtkSjRp?=
 =?utf-8?B?T1dDM2dpMDl6S2oxdHo3ekh2ZEladzRmMmxvaDh2eVo0TzQ1K3hDVk54UVFn?=
 =?utf-8?B?MmJ1RE5aanlaLzRRejhZMm54NXEzNFk4RzVtcTBKZ3JJK0JXY3JpRGlFUkhU?=
 =?utf-8?B?LzZVRzlwKzhjQU53VnVxcDJ6ak40ajMvQWw5U2NuaWoybW1RN3hYbW1JYlhn?=
 =?utf-8?B?aStSK0tFTjFVeDRlenlhZ1drdmp5QS9zelRvNDQ3ZDFneXJPODRtVHo2V25u?=
 =?utf-8?B?cUVlWXhhWm9UeWkzUHl6a0lYTjU3VHhrNXE2WXVJb2dXRjNpWTUwVi9pSEJi?=
 =?utf-8?B?U2plZ2NJVC80WTd3WUdQZEtiMGVkVG9kS3Q4c0g5VDhoQ3I4K3pWYUhGUnlJ?=
 =?utf-8?B?c3k5QjJPYjV6TFBIaVllSWtHWVdoWkRTZjc1VGVtVHVwSWFOYzdjRDV3U2Vk?=
 =?utf-8?B?ZDc4QnMzbno3M1NvUEh3WjZUd2J1dHhwTVFEeU4ydWwyUGNRc29jRVBMcnhE?=
 =?utf-8?B?SGZSdnpMMnVsTWVaWGRSOXM5UGxjVEZUa2NkWHl2L3Y5WE12Mi9xQlc4UnpL?=
 =?utf-8?Q?Z6at+FMgKwE=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW3PR12MB4427.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(4053099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?SVd3aHJwWnFTZEJ4UWF3MFFxTWZua2pxcVMxaDFEa3ZVMThjQnRCejBhRHJI?=
 =?utf-8?B?d1NOTkYrN1hIYzcrSzlVb1dXVGdRUmJaS1VXZEpSVzlremp4MVRVMjJaT3VT?=
 =?utf-8?B?MXRjZlFqMlhWeHNMOWRPb2JOR2lHTTdkbEVjNFNCci95UFVraTBTMGxxZkwy?=
 =?utf-8?B?Q3k0SmxFc0c0NkpobEVNdXd4ek8yeDZLUXh4Y1ZUQTVaamFzZDFwQnVXejRx?=
 =?utf-8?B?bFhTVXpza2oyQkFJMWJDVS9TRm5Mc2Zac2tCZVB3bi9SY2lwTU1MajgyeUVO?=
 =?utf-8?B?MTdma3puZWFwYitQREVXVUI5OWxEeTZ5VTJaNWdDcG0zMXA3Y01SODVaZWo1?=
 =?utf-8?B?SjNqdkI1YnBTQ2dPdHBnVk4vNi9ramlvNlp2YmtEc29aeS9nK2xjMFNNbFRw?=
 =?utf-8?B?RzRXalN6N3VyaE16a0tzN3lwSzRnRWg4K1RzajkxYXB2ZnBOTUZxZkJTeVBy?=
 =?utf-8?B?azFYQnRKZnpmT2tNRzBHVGQ5WFZJOFluSTRLQmFrZzVLZHUyRlpHTmFRYURn?=
 =?utf-8?B?aFRTTURLMDIyZ2lEU2FwVkN0TzlnMFgwRUdLRzVWRnNMakFQVjJyLzMxTWpN?=
 =?utf-8?B?YTRObFdzRTJWYkJMeXBzK2Y0dUh4TmhUbXUwSGU5V1Z1QU1tc09vUWg4MWZO?=
 =?utf-8?B?Qkp2bkp1SnV4VFBvYzJ1ckFhL0tYNTYvNlJOT2N2RTdyVTZxUlZqYU1HZjV6?=
 =?utf-8?B?QUlVSzRIdGEvUGNVV24vbEhBZnBndEEwUHFzUnBka1hrM2pFRnloMXFiaWJ2?=
 =?utf-8?B?YWx6U1pQRDE4VkdhU1lza2hybkZqQjlqaDBGKytjYktjeW9ROVpyZ005SDB0?=
 =?utf-8?B?SE5hR3NuTUk0TG92T242Tk5KaHJ3QTluT3VhTGZrQ0xvMWdJZnhmR29xL1NH?=
 =?utf-8?B?TTBWZ2wwSkZWaG1GdFZGVTczenhEKzBWS1F2VmdCRkVBSk1pVjZaVzhXcVZZ?=
 =?utf-8?B?eUluaDdMWVE1UFIyV2pWK1RnZ2pkUXRJTkZSOHE4UXY1WmR5N1IvZ0pTczJt?=
 =?utf-8?B?ZHRVZngvSEMzWWxzRTcwUnF4VUZBQnF0b1NxNU5kZjRueDB5dllkbEdqa2lX?=
 =?utf-8?B?Ynk5bVJrYjIxRXlPeVByM0J1dGU3dytHcVZsVVpnZ1cyRlpPbXNkQ0l5TGRw?=
 =?utf-8?B?dnJzN3VQNzdDY1RpZ2dmRDdiZWNKZC81TlJxQXNNWVZVVHRTRmUwZDZxYzhZ?=
 =?utf-8?B?MjRFTDIvdW5ldncrQjVvaVlPRDJTN2ZwTnlZb09HNk5hZFFLQkVqdFFhcDVM?=
 =?utf-8?B?My9Rejg3UGk3alZkbTVmZ1R3MTFjWVAyNytDbW1WZjZnVitTTUZ2ekl2L2R1?=
 =?utf-8?B?R1RXaUE2cFFRZmljM3Vjb2w3cXA4NFg0TWZmMXVxN1lsa0dOTnpYQnhHaGg5?=
 =?utf-8?B?QmdpMHY4U3h6MnA0QmJ4b0hWNWlWNWdkb1ZlZlZCL01qT05RUzR6MnZZTitk?=
 =?utf-8?B?WGxINDF3RUh5VmZaR0Qyc0hMQ2dGdjVJL09QVDFySWF0V2xwdGFpWWNSQlcw?=
 =?utf-8?B?ajhEZ05Dd1UwcVFGRkRXWFczWTRiYUJDUVR2V2xXSThjTVVwT1JyTkJUUXpX?=
 =?utf-8?B?TGhNS1VZOEFySThwUnM2ejIyU2NsYno3bWZBbENSNWl6V1AyWGNJRldEbDha?=
 =?utf-8?B?SjU1a3ZnbTFqSGFZTUFTK0drTVd5bi9yYmJPSnpFQi92ZVloWkp4aWxWdWhp?=
 =?utf-8?B?YjVUbWpERllNMXpKUlhqNTBldjUxeXFzNm4wTzE4OForTUUzdDg4QTQ2dTN3?=
 =?utf-8?B?cG80V1hKd2NQU0Q1K1ZyVlZNdldUOHZGREgyT1ZoMnlwbXNNdHVMQUlSUEFy?=
 =?utf-8?B?cm43RDkrUVdlN3RjYldFTHR4Rk5ZVEQrRVVtckNYVEJYMEgzZmJQaldNQ2l4?=
 =?utf-8?B?aG4vaWxNTVcrNlE4VHVvMEZvdWtXWTJUNDlvQUFFQ3psbzUycWFRamtGb1pG?=
 =?utf-8?B?R0tmaWgvNEN0bnprRGd2bVNRU2NiVk8rUUVVbS9hYlBUTXhXT1Z4SGV5V0xp?=
 =?utf-8?B?UkN6RVl3aW1TcXNiQXVwVE54RDRNaHdqZ2c3V1JIeTVnalNpd01HOEl4T0pH?=
 =?utf-8?B?aUd2amhMUGRlaDF4MXoxRkxjbFVLa2RiNVNGcDRmaUdDZm12YTVRYS91S3JK?=
 =?utf-8?Q?oRfow7dmI2V41+OZAjOuc/sYr?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7334b420-ffe2-4fd4-e4ef-08dd940f8056
X-MS-Exchange-CrossTenant-AuthSource: MW3PR12MB4427.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2025 00:20:46.6916
 (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: Gz67aXBuhASHrYdDQ/g+HgFW0OgKLDnoOlpKDs3g24tUzzun47C+U6rd/s7TxFrRTj8EIjbdZutdz2zldTlOzA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9230

--------------4vcTr0KMHNAmZnYteqWrR3WQ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello,

I tested the patch based on staging (f1f351df0309) on hardware that has 
the issue of the overlap (0xfea00000 in the logs attached).

Linux 6.11 defconfig + CONFIG_BLK_DEV_NVME

Without the patch we see these messages and the NVME is not accessible:
> [  313.438979] nvme nvme0: I/O tag 4 (2004) QID 0 timeout, completion 
> polled
>
> (XEN) [  322.972867] arch/x86/hvm/emulate.c:417:d0v1 unhandled memory 
> write to 0xfea0300c size 4
With the patch we see only the added warning and the NVME is accessible:
> (XEN) [    4.746374] arch/x86/pci.c:109:d[IDLE]v0 0000:02:00.0: BAR at 
> [fea00, fea03] not in memory map hole

Tested-by: Victor M Lira 


Victor
--------------4vcTr0KMHNAmZnYteqWrR3WQ
Content-Type: text/plain; charset=UTF-8; name="test-without.log"
Content-Disposition: attachment; filename="test-without.log"
Content-Transfer-Encoding: base64

WGVuIDQuMjEtdW5zdGFibGUNCihYRU4pIFswMDAwMDAyNzg5YTBjYzdiXSBYZW4gdmVyc2lvbiA0
LjIxLXVuc3RhYmxlIChyb290QCkgKGdjYyAoQWxwaW5lIDEyLjIuMV9naXQyMDIyMDkyNC1yMTAp
IDEyLjIuMSAyMDIyMDkyNCkgZGVidWc9eSBUaHUgTWF5IDE1IDE2OjM2OjM1IFVUQyAyMDI1DQoo
WEVOKSBbMDAwMDAwMjc4YmUyYmUyZF0gTGF0ZXN0IENoYW5nZVNldDoNCihYRU4pIFswMDAwMDAy
NzhjOGYxNmY1XSBidWlsZC1pZDogMDYyZmFlNWJjNDIyYjY4MmFmM2U4ZDJlZTljNzllNjc0YzZk
NWU2Yw0KKFhFTikgWzAwMDAwMDI3OGRiNWMyZGVdIENvbnNvbGUgb3V0cHV0IGlzIHN5bmNocm9u
b3VzLg0KKFhFTikgWzAwMDAwMDI3OGU4ZmZjYzNdIENQVSBWZW5kb3I6IEFNRCwgRmFtaWx5IDIz
ICgweDE3KSwgTW9kZWwgOTYgKDB4NjApLCBTdGVwcGluZyAxIChyYXcgMDA4NjBmMDEpDQooWEVO
KSBbMDAwMDAwMjc5MDFlMTUxYl0gQlNQIG1pY3JvY29kZSByZXZpc2lvbjogMHgwODYwMDEwYw0K
KFhFTikgWzAwMDAwMDI3OTEwNzkxMGRdIEJvb3Rsb2FkZXI6IEdSVUIgMi4xMw0KKFhFTikgWzAw
MDAwMDI3OTFiZjRiMzNdIENvbW1hbmQgbGluZTogY29uc29sZT1jb20xIGNvbTE9MTE1MjAwLDhu
MSwweDNGOCw0IHNjaGVkPW51bGwgbG9nbHZsPWFsbCBndWVzdF9sb2dsdmw9YWxsIGNvbnNvbGVf
dGltZXN0YW1wcz1ib290IGlvbW11PXZlcmJvc2UgZG9tMD1wdmgsdmVyYm9zZSBkb20wX21heF92
Y3B1cz00IGRvbTBfbWVtPTRHIGFyZ289MSxtYWMtcGVybWlzc2l2ZT0xIHN5bmNfY29uc29sZSBu
b3JlYm9vdCB3b3cNCihYRU4pIFswMDAwMDAyNzk1N2MzYzk2XSBYZW4gaW1hZ2UgbG9hZCBiYXNl
IGFkZHJlc3M6IDB4YzY4MDAwMDANCihYRU4pIFswMDAwMDAyNzk2NzhkZjFlXSBWaWRlbyBpbmZv
cm1hdGlvbjoNCihYRU4pIFswMDAwMDAyNzk3MjUxODJlXSAgVkdBIGlzIHRleHQgbW9kZSA4MHgy
NSwgZm9udCA4eDE2DQooWEVOKSBbMDAwMDAwMjc5ODBlYTFiOF0gRGlzYyBpbmZvcm1hdGlvbjoN
CihYRU4pIFswMDAwMDAyNzk4YjcwYzkwXSAgRm91bmQgMCBNQlIgc2lnbmF0dXJlcw0KKFhFTikg
WzAwMDAwMDI3OTk3NjdlNzNdICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzDQoo
WEVOKSBbMDAwMDAwMjc5YTYzZDYxOF0gRUZJIFJBTSBtYXA6DQooWEVOKSBbMDAwMDAwMjc5YWY5
MWM2NF0gIFswMDAwMDAwMDAwMDAwMDAwLCAwMDAwMDAwMDAwMDlmZmZmXSAodXNhYmxlKQ0KKFhF
TikgWzAwMDAwMDI3OWMxMDg4ZjhdICBbMDAwMDAwMDAwMDBhMDAwMCwgMDAwMDAwMDAwMDBmZmZm
Zl0gKHJlc2VydmVkKQ0KKFhFTikgWzAwMDAwMDI3OWQyZjk0MjNdICBbMDAwMDAwMDAwMDEwMDAw
MCwgMDAwMDAwMDAwOWJmZWZmZl0gKHVzYWJsZSkNCihYRU4pIFswMDAwMDAyNzllNDZmZWFkXSAg
WzAwMDAwMDAwMDliZmYwMDAsIDAwMDAwMDAwMDlmZmZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFsw
MDAwMDAyNzlmNjYyOWFkXSAgWzAwMDAwMDAwMGEwMDAwMDAsIDAwMDAwMDAwMGExZmZmZmZdICh1
c2FibGUpDQooWEVOKSBbMDAwMDAwMjdhMDdkOTNjM10gIFswMDAwMDAwMDBhMjAwMDAwLCAwMDAw
MDAwMDBhMjBjZmZmXSAoQUNQSSBOVlMpDQooWEVOKSBbMDAwMDAwMjdhMTljYTNjZF0gIFswMDAw
MDAwMDBhMjBkMDAwLCAwMDAwMDAwMGNhYmM4ZmZmXSAodXNhYmxlKQ0KKFhFTikgWzAwMDAwMDI3
YTJiNDEyYTVdICBbMDAwMDAwMDBjYWJjOTAwMCwgMDAwMDAwMDBjYzE0Y2ZmZl0gKHJlc2VydmVk
KQ0KKFhFTikgWzAwMDAwMDI3YTNkMzJmYjZdICBbMDAwMDAwMDBjYzE0ZDAwMCwgMDAwMDAwMDBj
YzE5NWZmZl0gKEFDUEkgZGF0YSkNCihYRU4pIFswMDAwMDAyN2E0ZjYyOTQ1XSAgWzAwMDAwMDAw
Y2MxOTYwMDAsIDAwMDAwMDAwY2MzODhmZmZdIChBQ1BJIE5WUykNCihYRU4pIFswMDAwMDAyN2E2
MTUzOGRiXSAgWzAwMDAwMDAwY2MzODkwMDAsIDAwMDAwMDAwY2MzODlmZmZdIChyZXNlcnZlZCkN
CihYRU4pIFswMDAwMDAyN2E3MzQzZmI4XSAgWzAwMDAwMDAwY2MzOGEwMDAsIDAwMDAwMDAwY2M3
MDlmZmZdIChBQ1BJIE5WUykNCihYRU4pIFswMDAwMDAyN2E4NTM1ODVlXSAgWzAwMDAwMDAwY2M3
MGEwMDAsIDAwMDAwMDAwY2QxZmVmZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAyN2E5NzI2
ODY4XSAgWzAwMDAwMDAwY2QxZmYwMDAsIDAwMDAwMDAwY2RmZmZmZmZdICh1c2FibGUpDQooWEVO
KSBbMDAwMDAwMjdhYTg5ZDI3ZV0gIFswMDAwMDAwMGNlMDAwMDAwLCAwMDAwMDAwMGNmZmZmZmZm
XSAocmVzZXJ2ZWQpDQooWEVOKSBbMDAwMDAwMjdhYmE4ZmRkNV0gIFswMDAwMDAwMGYwMDAwMDAw
LCAwMDAwMDAwMGY3ZmZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbMDAwMDAwMjdhY2M4MTIyZF0g
IFswMDAwMDAwMGZkMDAwMDAwLCAwMDAwMDAwMGZmZmZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBb
MDAwMDAwMjdhZGU3MWQ3NV0gIFswMDAwMDAwMTAwMDAwMDAwLCAwMDAwMDAwODBmMzNmZmZmXSAo
dXNhYmxlKQ0KKFhFTikgWzAwMDAwMDI3YWVmZTg3OGJdICBbMDAwMDAwMDgwZjM0MDAwMCwgMDAw
MDAwMDg1MDFmZmZmZl0gKHJlc2VydmVkKQ0KKFhFTikgWzAwMDAwMDI3YmM2MzQyNTNdIEFDUEk6
IFJTRFAgQ0M2RjMwMTQsIDAwMjQgKHIyIEFMQVNLQSkNCihYRU4pIFswMDAwMDAyN2JkNTgyMjc4
XSBBQ1BJOiBYU0RUIENDNkYyNzI4LCAwMEQ0IChyMSBBTEFTS0EgICBBIE0gSSAgIDEwNzIwMDkg
QU1JICAgMTAwMDAxMykNCihYRU4pIFswMDAwMDAyN2JlYzdiNzBkXSBBQ1BJOiBGQUNQIENDMThD
MDAwLCAwMTE0IChyNiBBTEFTS0EgICBBIE0gSSAgIDEwNzIwMDkgQU1JICAgICAxMDAxMykNCihY
RU4pIFswMDAwMDAyN2MwMzcyNzYyXSBBQ1BJOiBEU0RUIENDMTgzMDAwLCA4NzZEIChyMiBBTEFT
S0EgICBBIE0gSSAgIDEwNzIwMDkgSU5UTCAyMDEyMDkxMykNCihYRU4pIFswMDAwMDAyN2MxYTZh
OTlkXSBBQ1BJOiBGQUNTIENDNkMwMDAwLCAwMDQwDQooWEVOKSBbMDAwMDAwMjdjMjZkYTEyYl0g
QUNQSTogU1NEVCBDQzE4RTAwMCwgNzIzQyAocjIgICAgQU1EIEFtZFRhYmxlICAgICAgICAyIE1T
RlQgIDQwMDAwMDApDQooWEVOKSBbMDAwMDAwMjdjM2RkMjNiZF0gQUNQSTogSVZSUyBDQzE4RDAw
MCwgMDFBNCAocjIgIEFNRCAgIEFtZFRhYmxlICAgICAgICAxIEFNRCAgICAgICAgIDApDQooWEVO
KSBbMDAwMDAwMjdjNTRjYTVkYl0gQUNQSTogRklEVCBDQzE4MjAwMCwgMDA5QyAocjEgQUxBU0tB
ICAgIEEgTSBJICAxMDcyMDA5IEFNSSAgICAgMTAwMTMpDQooWEVOKSBbMDAwMDAwMjdjNmJjMGJl
MV0gQUNQSTogTUNGRyBDQzE4MTAwMCwgMDAzQyAocjEgQUxBU0tBICAgIEEgTSBJICAxMDcyMDA5
IE1TRlQgICAgMTAwMTMpDQooWEVOKSBbMDAwMDAwMjdjODJiODY4NV0gQUNQSTogSFBFVCBDQzE4
MDAwMCwgMDAzOCAocjEgQUxBU0tBICAgIEEgTSBJICAxMDcyMDA5IEFNSSAgICAgICAgIDUpDQoo
WEVOKSBbMDAwMDAwMjdjOTlhZjY4M10gQUNQSTogU1NEVCBDQzE3RjAwMCwgMDIyOCAocjEgICAg
QU1EICAgICBTVEQzICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAwMjdjYjBh
NmZlOF0gQUNQSTogVkZDVCBDQzE3MTAwMCwgRDY4NCAocjEgQUxBU0tBICAgQSBNIEkgICAgICAg
ICAxICBBTUQgMzE1MDRGNDcpDQooWEVOKSBbMDAwMDAwMjdjYzc5ZmIzM10gQUNQSTogVFBNMiBD
QzE3MDAwMCwgMDA0QyAocjQgQUxBU0tBICAgQSBNIEkgICAgICAgICAxIEFNSSAgICAgICAgIDAp
DQooWEVOKSBbMDAwMDAwMjdjZGU5N2RjNV0gQUNQSTogU1NEVCBDQzE2QzAwMCwgMzlGNCAocjEg
ICAgQU1EIEFtZFRhYmxlICAgICAgICAxIEFNRCAgICAgICAgIDEpDQooWEVOKSBbMDAwMDAwMjdj
ZjU4ZGJkZF0gQUNQSTogQ1JBVCBDQzE2QjAwMCwgMEYyOCAocjEgICAgQU1EIEFtZFRhYmxlICAg
ICAgICAxIEFNRCAgICAgICAgIDEpDQooWEVOKSBbMDAwMDAwMjdkMGM4NTlhZF0gQUNQSTogQ0RJ
VCBDQzE2QTAwMCwgMDAyOSAocjEgICAgQU1EIEFtZFRhYmxlICAgICAgICAxIEFNRCAgICAgICAg
IDEpDQooWEVOKSBbMDAwMDAwMjdkMjM3ZTAzNl0gQUNQSTogU1NEVCBDQzE2OTAwMCwgMDEzOSAo
cjEgICAgQU1EIEFtZFRhYmxlICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAw
MjdkM2E3NDc3Yl0gQUNQSTogU1NEVCBDQzE2ODAwMCwgMDIyNyAocjEgICAgQU1EIEFtZFRhYmxl
ICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAwMjdkNTE2ZDMxZF0gQUNQSTog
U1NEVCBDQzE2NzAwMCwgMEQzNyAocjEgICAgQU1EIEFtZFRhYmxlICAgICAgICAxIElOVEwgMjAx
MjA5MTMpDQooWEVOKSBbMDAwMDAwMjdkNjg2MzllZV0gQUNQSTogU1NEVCBDQzE2NTAwMCwgMTBB
NSAocjEgICAgQU1EIEFtZFRhYmxlICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAw
MDAwMjdkN2Y1YWYwNV0gQUNQSTogU1NEVCBDQzE2MTAwMCwgMzBDOCAocjEgICAgQU1EIEFtZFRh
YmxlICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAwMjdkOTY1NDM3ZF0gQUNQ
STogV1NNVCBDQzE2MDAwMCwgMDAyOCAocjEgQUxBU0tBICAgQSBNIEkgICAxMDcyMDA5IEFNSSAg
ICAgMTAwMTMpDQooWEVOKSBbMDAwMDAwMjdkYWQ0YzE0ZF0gQUNQSTogQVBJQyBDQzE1RjAwMCwg
MDBERSAocjMgQUxBU0tBICAgQSBNIEkgICAxMDcyMDA5IEFNSSAgICAgMTAwMTMpDQooWEVOKSBb
MDAwMDAwMjdkYzQ0MzVmMF0gQUNQSTogU1NEVCBDQzE1RTAwMCwgMDA3RCAocjEgICAgQU1EIEFt
ZFRhYmxlICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAwMjdkZGIzOTg1N10g
QUNQSTogU1NEVCBDQzE1RDAwMCwgMDUxNyAocjEgICAgQU1EIEFtZFRhYmxlICAgICAgICAxIElO
VEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAwMjdkZjIzMTFkOF0gQUNQSTogRlBEVCBDQzE1QzAw
MCwgMDA0NCAocjEgQUxBU0tBICAgQSBNIEkgICAxMDcyMDA5IEFNSSAgIDEwMDAwMTMpDQooWEVO
KSBbMDAwMDAwMjdlMDkyYTI3N10gU3lzdGVtIFJBTTogMzIxNjhNQiAoMzI5NDA2NTZrQikNCihY
RU4pIFswMDAwMDAyN2U1YzI3NjMxXSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQNCihYRU4p
IFswMDAwMDAyN2U2OTEyMWRiXSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAw
MDAwMDgwZjM0MDAwMA0KKFhFTikgWzAwMDAwMDI3ZjBhYTVlMTJdIERvbWFpbiBoZWFwIGluaXRp
YWxpc2VkDQooWEVOKSBbMDAwMDAwMjdmMmE5OTU0Yl0gU01CSU9TIDMuMiBwcmVzZW50Lg0KKFhF
TikgWzAwMDAwMDI3ZjM1YWY2MzJdIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4pIFsw
MDAwMDAyN2Y0MjFmNzBhXSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgwOCAoMzIgYml0cykN
CihYRU4pIFswMDAwMDAyN2Y1MWVhMjg2XSBBQ1BJOiB2NSBTTEVFUCBJTkZPOiBjb250cm9sWzA6
MF0sIHN0YXR1c1swOjBdDQooWEVOKSBbMDAwMDAwMjdmNjM2MWEzM10gQUNQSTogU0xFRVAgSU5G
TzogcG0xeF9jbnRbMTo4MDQsMTowXSwgcG0xeF9ldnRbMTo4MDAsMTowXQ0KKFhFTikgWzAwMDAw
MDI3Zjc3YjZlZWFdIEFDUEk6IDMyLzY0WCBGQUNTIGFkZHJlc3MgbWlzbWF0Y2ggaW4gRkFEVCAt
IGNjNmMwMDAwLzAwMDAwMDAwMDAwMDAwMDAsIHVzaW5nIDMyDQooWEVOKSBbMDAwMDAwMjdmOTE1
MTcxMl0gQUNQSTogICAgICAgICAgICAgd2FrZXVwX3ZlY1tjYzZjMDAwY10sIHZlY19zaXplWzIw
XQ0KKFhFTikgWzAwMDAwMDI3ZmE0Mzc5ZWRdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZl
ZTAwMDAwDQooWEVOKSBbMDAwMDAwMjdmYjMyMTdkM10gT3ZlcnJpZGluZyBBUElDIGRyaXZlciB3
aXRoIGJpZ3NtcA0KKFhFTikgWzAwMDAwMDI3ZmMxYjkzNmRdIEFDUEk6IElPQVBJQyAoaWRbMHgx
MV0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNCihYRU4pIFswMDAwMDAyN2ZkNTU3
NDE1XSBJT0FQSUNbMF06IGFwaWNfaWQgMTcsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAw
MCwgR1NJIDAtMjMNCihYRU4pIFswMDAwMDAyN2ZlYWRlYWEwXSBBQ1BJOiBJT0FQSUMgKGlkWzB4
MTJdIGFkZHJlc3NbMHhmZWMwMTAwMF0gZ3NpX2Jhc2VbMjRdKQ0KKFhFTikgWzAwMDAwMDI3ZmZl
YmFjZGZdIElPQVBJQ1sxXTogYXBpY19pZCAxOCwgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzAx
MDAwLCBHU0kgMjQtNTUNCihYRU4pIFswMDAwMDAyODAxNDgwMmExXSBBQ1BJOiBJTlRfU1JDX09W
UiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgWzAwMDAwMDI4
MDI4NWM4MGJdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5
IGxvdyBsZXZlbCkNCihYRU4pIFswMDAwMDAyODAzY2IyYTNkXSBBQ1BJOiBJUlEwIHVzZWQgYnkg
b3ZlcnJpZGUuDQooWEVOKSBbMDAwMDAwMjgwNDlkOTExOF0gQUNQSTogSVJRMiB1c2VkIGJ5IG92
ZXJyaWRlLg0KKFhFTikgWzAwMDAwMDI4MDU3MDI1N2RdIEFDUEk6IElSUTkgdXNlZCBieSBvdmVy
cmlkZS4NCihYRU4pIFswMDAwMDAyODA2NDJhMzU3XSBBQ1BJOiBIUEVUIGlkOiAweDEwMjI4MjAx
IGJhc2U6IDB4ZmVkMDAwMDANCihYRU4pIFswMDAwMDAyODA3NGFkNDcwXSBQQ0k6IE1DRkcgY29u
ZmlndXJhdGlvbiAwOiBiYXNlIGYwMDAwMDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIDdmDQoo
WEVOKSBbMDAwMDAwMjgwOGIyOTFhZV0gUENJOiBNQ0ZHIGFyZWEgYXQgZjAwMDAwMDAgcmVzZXJ2
ZWQgaW4gRTgyMA0KKFhFTikgWzAwMDAwMDI4MDliZTllZWRdIFBDSTogVXNpbmcgTUNGRyBmb3Ig
c2VnbWVudCAwMDAwIGJ1cyAwMC03Zg0KKFhFTikgWzAwMDAwMDI4MGFjNmE3OTZdIFVzaW5nIEFD
UEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgWzAwMDAw
MDI4MGJmMTUzZTVdIFNNUDogQWxsb3dpbmcgMTYgQ1BVcyAoMCBob3RwbHVnIENQVXMpDQooWEVO
KSBbMDAwMDAwMjgwY2VhMTE4ZF0gSVJRIGxpbWl0czogNTYgR1NJLCAzMjcyIE1TSS9NU0ktWA0K
KFhFTikgWzAwMDAwMDI4MGRkMzhlMmRdIENQVTA6IDE0MDAgLi4uIDI5MDAgTUh6DQooWEVOKSBb
MDAwMDAwMjgwZTkzMGRmZl0geHN0YXRlOiBzaXplOiAweDM4MCBhbmQgc3RhdGVzOiAweDIwNw0K
KFhFTikgWzAwMDAwMDI4MGY4N2ZjODddIENQVTA6IEFNRCBGYW0xN2ggbWFjaGluZSBjaGVjayBy
ZXBvcnRpbmcgZW5hYmxlZA0KKFhFTikgWzAwMDAwMDI4MTBhNzE1ODRdIFNwZWN1bGF0aXZlIG1p
dGlnYXRpb24gZmFjaWxpdGllczoNCihYRU4pIFswMDAwMDAyODExOTA3ZGMwXSAgIEhhcmR3YXJl
IGhpbnRzOiBJQlJTX0ZBU1QgSUJSU19TQU1FX01PREUNCihYRU4pIFswMDAwMDAyODEyOThhMmY0
XSAgIEhhcmR3YXJlIGZlYXR1cmVzOiBJQlBCIElCUlMgU1RJQlAgU1NCRA0KKFhFTikgWzAwMDAw
MDI4MTM5Y2ZjYThdICAgQ29tcGlsZWQtaW4gc3VwcG9ydDogSU5ESVJFQ1RfVEhVTksgUkVUVVJO
X1RIVU5LIFNIQURPV19QQUdJTkcgSEFSREVOX0FSUkFZIEhBUkRFTl9CUkFOQ0ggSEFSREVOX0dV
RVNUX0FDQ0VTUyBIQVJERU5fTE9DSw0KKFhFTikgWzAwMDAwMDI4MTVkYjJhMzddICAgWGVuIHNl
dHRpbmdzOiBCVEktVGh1bms6IFJFVFBPTElORSwgU1BFQ19DVFJMOiBJQlJTLSBTVElCUCsgU1NC
RC0sIE90aGVyOiBCUkFOQ0hfSEFSREVODQooWEVOKSBbMDAwMDAwMjgxNzk3M2U4NV0gICBTdXBw
b3J0IGZvciBIVk0gVk1zOiBNU1JfU1BFQ19DVFJMIE1TUl9WSVJUX1NQRUNfQ1RSTCBSU0IgSUJQ
Qi1lbnRyeQ0KKFhFTikgWzAwMDAwMDI4MTkwYTg2MjJdICAgU3VwcG9ydCBmb3IgUFYgVk1zOiBJ
QlBCLWVudHJ5DQooWEVOKSBbMDAwMDAwMjgxOWVjNWM1YV0gICBYUFRJICg2NC1iaXQgUFYgb25s
eSk6IERvbTAgZGlzYWJsZWQsIERvbVUgZGlzYWJsZWQgKHdpdGhvdXQgUENJRCkNCihYRU4pIFsw
MDAwMDAyODFiNTdmZTc3XSAgIFBWIEwxVEYgc2hhZG93aW5nOiBEb20wIGRpc2FibGVkLCBEb21V
IGRpc2FibGVkDQooWEVOKSBbMDAwMDAwMjgxYzdhZDM4Y10gVXNpbmcgc2NoZWR1bGVyOiBudWxs
IFNjaGVkdWxlciAobnVsbCkNCihYRU4pIFswMDAwMDAyODFkNzNiOWMyXSBJbml0aWFsaXppbmcg
bnVsbCBzY2hlZHVsZXINCihYRU4pIFswMDAwMDAyODFlNDI1NzI3XSBXQVJOSU5HOiBUaGlzIGlz
IGV4cGVyaW1lbnRhbCBzb2Z0d2FyZSBpbiBkZXZlbG9wbWVudC4NCihYRU4pIFswMDAwMDAyODFm
Nzg3YjdkXSBVc2UgYXQgeW91ciBvd24gcmlzay4NCihYRU4pIFswMDAwMDAyODI4Y2MzOGVjXSBQ
bGF0Zm9ybSB0aW1lciBpcyAxNC4zMThNSHogSFBFVA0KKFhFTikgWyAgICAwLjkyOTc4OV0gRGV0
ZWN0ZWQgMjg5NC41NzMgTUh6IHByb2Nlc3Nvci4NCihYRU4pIFsgICAgMC45MzYyNjRdIEZyZWVk
IDEwMDhrQiB1bnVzZWQgQlNTIG1lbW9yeQ0KKFhFTikgWyAgICAwLjk0MDg1N10gRUZJIG1lbW9y
eSBtYXA6DQooWEVOKSBbICAgIDAuOTQ0MTUwXSAgMDAwMDAwMDAwMDAwMC0wMDAwMDAwMDAzZmZm
IHR5cGU9MiBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMC45NTEwODJdICAwMDAw
MDAwMDA0MDAwLTAwMDAwMDAwOGVmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAwLjk1ODAxN10gIDAwMDAwMDAwOGYwMDAtMDAwMDAwMDA5ZWZmZiB0eXBlPTIgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDAuOTY0OTUxXSAgMDAwMDAwMDA5ZjAwMC0w
MDAwMDAwMDlmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMC45
NzE4ODJdICAwMDAwMDAwMTAwMDAwLTAwMDAwMDBlODlmZmYgdHlwZT0yIGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAwLjk3ODgxN10gIDAwMDAwMDBlOGEwMDAtMDAwMDAwMGZmZmZm
ZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDAuOTg1NzQ5XSAgMDAw
MDAwMTAwMDAwMC0wMDAwMDAxMDFmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMC45OTI2ODVdICAwMDAwMDAxMDIwMDAwLTAwMDAwMDliZmVmZmYgdHlwZT03IGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAwLjk5OTYxOF0gIDAwMDAwMDliZmYwMDAt
MDAwMDAwOWZmZmZmZiB0eXBlPTAgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEu
MDA2NTUwXSAgMDAwMDAwYTAwMDAwMC0wMDAwMDBhMWZmZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMS4wMTM0ODJdICAwMDAwMDBhMjAwMDAwLTAwMDAwMGEyMGNm
ZmYgdHlwZT0xMCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4wMjA1MDJdICAw
MDAwMDBhMjBkMDAwLTAwMDAwMTZkMDNmZmYgdHlwZT0yIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAxLjAyNzQzNV0gIDAwMDAwMTZkMDQwMDAtMDAwMDBjNGY4N2ZmZiB0eXBlPTcg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMDM0MzcwXSAgMDAwMDBjNGY4ODAw
MC0wMDAwMGM3MDljZmZmIHR5cGU9MSBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
MS4wNDEzMDJdICAwMDAwMGM3MDlkMDAwLTAwMDAwYzcxYjJmZmYgdHlwZT03IGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjA0ODIzNV0gIDAwMDAwYzcxYjMwMDAtMDAwMDBjNzFk
YmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMDU1MTY4XSAg
MDAwMDBjNzFkYzAwMC0wMDAwMGM3MjE2ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMS4wNjIxMDNdICAwMDAwMGM3MjE3MDAwLTAwMDAwYzcyMThmZmYgdHlwZT03
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjA2OTAzNl0gIDAwMDAwYzcyMTkw
MDAtMDAwMDBjNzIxOWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDEuMDc1OTcxXSAgMDAwMDBjNzIxYTAwMC0wMDAwMGM3MjI1ZmZmIHR5cGU9MyBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4wODI5MDNdICAwMDAwMGM3MjI2MDAwLTAwMDAwYzcy
MjdmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjA4OTgzN10g
IDAwMDAwYzcyMjgwMDAtMDAwMDBjNzIyY2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDEuMDk2NzcwXSAgMDAwMDBjNzIyZDAwMC0wMDAwMGM3MjMyZmZmIHR5cGU9
NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4xMDM3MDRdICAwMDAwMGM3MjMz
MDAwLTAwMDAwYzcyMzNmZmYgdHlwZT0yIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAxLjExMDYzNl0gIDAwMDAwYzcyMzQwMDAtMDAwMDBjNzIzNWZmZiB0eXBlPTcgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMTE3NTY4XSAgMDAwMDBjNzIzNjAwMC0wMDAwMGM3
MjM4ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4xMjQ1MDNd
ICAwMDAwMGM3MjM5MDAwLTAwMDAwYzcyM2NmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAxLjEzMTQzOF0gIDAwMDAwYzcyM2QwMDAtMDAwMDBjNzI1MWZmZiB0eXBl
PTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMTM4MzcwXSAgMDAwMDBjNzI1
MjAwMC0wMDAwMGM3MjVmZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMS4xNDUzMDJdICAwMDAwMGM3MjYwMDAwLTAwMDAwYzcyOWRmZmYgdHlwZT00IGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjE1MjIzN10gIDAwMDAwYzcyOWUwMDAtMDAwMDBj
NzI5ZmZmZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMTU5MTY5
XSAgMDAwMDBjNzJhMDAwMC0wMDAwMGM3MmExZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMS4xNjYxMDFdICAwMDAwMGM3MmEyMDAwLTAwMDAwYzcyYTNmZmYgdHlw
ZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjE3MzAzN10gIDAwMDAwYzcy
YTQwMDAtMDAwMDBjNzJhNGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDEuMTc5OTY5XSAgMDAwMDBjNzJhNTAwMC0wMDAwMGM3MmE1ZmZmIHR5cGU9NyBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4xODY5MDNdICAwMDAwMGM3MmE2MDAwLTAwMDAw
YzcyYTdmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjE5Mzgz
NF0gIDAwMDAwYzcyYTgwMDAtMDAwMDBjNzJhYWZmZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDEuMjAwNzcwXSAgMDAwMDBjNzJhYjAwMC0wMDAwMGM3MmFiZmZmIHR5
cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4yMDc3MDJdICAwMDAwMGM3
MmFjMDAwLTAwMDAwYzcyYWRmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAxLjIxNDYzN10gIDAwMDAwYzcyYWUwMDAtMDAwMDBjNzJiMGZmZiB0eXBlPTQgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMjIxNTY5XSAgMDAwMDBjNzJiMTAwMC0wMDAw
MGM3MmJiZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4yMjg1
MDRdICAwMDAwMGM3MmJjMDAwLTAwMDAwYzcyYmVmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAxLjIzNTQzNV0gIDAwMDAwYzcyYmYwMDAtMDAwMDBjNzJjMmZmZiB0
eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMjQyMzY5XSAgMDAwMDBj
NzJjMzAwMC0wMDAwMGM3MmM0ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMS4yNDkzMDRdICAwMDAwMGM3MmM1MDAwLTAwMDAwYzcyYzZmZmYgdHlwZT03IGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjI1NjIzNl0gIDAwMDAwYzcyYzcwMDAtMDAw
MDBjNzJjOGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMjYz
MTY3XSAgMDAwMDBjNzJjOTAwMC0wMDAwMGM3MmNhZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMS4yNzAxMDNdICAwMDAwMGM3MmNiMDAwLTAwMDAwYzcyY2JmZmYg
dHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjI3NzAzNV0gIDAwMDAw
YzcyY2MwMDAtMDAwMDBjNzJjY2ZmZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDEuMjgzOTY5XSAgMDAwMDBjNzJjZDAwMC0wMDAwMGM3MmNlZmZmIHR5cGU9NCBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4yOTA5MDFdICAwMDAwMGM3MmNmMDAwLTAw
MDAwYzcyZDFmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjI5
NzgzNl0gIDAwMDAwYzcyZDIwMDAtMDAwMDBjNzJkM2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDEuMzA0NzY4XSAgMDAwMDBjNzJkNDAwMC0wMDAwMGM3Mzc2ZmZm
IHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4zMTE3MDNdICAwMDAw
MGM3Mzc3MDAwLTAwMDAwYzc4NWFmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAxLjMxODYzNl0gIDAwMDAwYzc4NWIwMDAtMDAwMDBjNzlkMmZmZiB0eXBlPTMgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMzI1NTY4XSAgMDAwMDBjNzlkMzAwMC0w
MDAwMGM3YTJlZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4z
MzI1MDNdICAwMDAwMGM3YTJmMDAwLTAwMDAwYzdhNGNmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAxLjMzOTQzNF0gIDAwMDAwYzdhNGQwMDAtMDAwMDBjN2E1ZGZm
ZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMzQ2MzY5XSAgMDAw
MDBjN2E1ZTAwMC0wMDAwMGM3YWU3ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMS4zNTMzMDFdICAwMDAwMGM3YWU4MDAwLTAwMDAwYzdiMDdmZmYgdHlwZT0zIGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjM2MDIzNF0gIDAwMDAwYzdiMDgwMDAt
MDAwMDBjN2IwOGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEu
MzY3MTY3XSAgMDAwMDBjN2IwOTAwMC0wMDAwMGM3YjEwZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMS4zNzQxMDFdICAwMDAwMGM3YjExMDAwLTAwMDAwYzdiMThm
ZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjM4MTAzNV0gIDAw
MDAwYzdiMTkwMDAtMDAwMDBjN2IzMGZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDEuMzg3OTY4XSAgMDAwMDBjN2IzMTAwMC0wMDAwMGM3YjMyZmZmIHR5cGU9NCBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4zOTQ5MDBdICAwMDAwMGM3YjMzMDAw
LTAwMDAwYzdiNTVmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAx
LjQwMTgzNF0gIDAwMDAwYzdiNTYwMDAtMDAwMDBjN2I2MGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNDA4NzY4XSAgMDAwMDBjN2I2MTAwMC0wMDAwMGM3Yjhj
ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS40MTU3MDBdICAw
MDAwMGM3YjhkMDAwLTAwMDAwYzkyNzBmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAxLjQyMjYzN10gIDAwMDAwYzkyNzEwMDAtMDAwMDBjOTJkN2ZmZiB0eXBlPTMg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNDI5NTY4XSAgMDAwMDBjOTJkODAw
MC0wMDAwMGM5MmRiZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
MS40MzY1MDJdICAwMDAwMGM5MmRjMDAwLTAwMDAwYzkyZTVmZmYgdHlwZT0zIGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjQ0MzQzNF0gIDAwMDAwYzkyZTYwMDAtMDAwMDBjOTMz
MGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNDUwMzY5XSAg
MDAwMDBjOTMzMTAwMC0wMDAwMGM5MzRhZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMS40NTczMDFdICAwMDAwMGM5MzRiMDAwLTAwMDAwYzkzNGVmZmYgdHlwZT00
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjQ2NDIzNl0gIDAwMDAwYzkzNGYw
MDAtMDAwMDBjOTM2Y2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDEuNDcxMTY4XSAgMDAwMDBjOTM2ZDAwMC0wMDAwMGM5MzZkZmZmIHR5cGU9NCBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS40NzgxMDNdICAwMDAwMGM5MzZlMDAwLTAwMDAwYzkz
NzRmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjQ4NTAzNF0g
IDAwMDAwYzkzNzUwMDAtMDAwMDBjOTM3YmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDEuNDkxOTY5XSAgMDAwMDBjOTM3YzAwMC0wMDAwMGM5Mzg5ZmZmIHR5cGU9
MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS40OTg5MDJdICAwMDAwMGM5Mzhh
MDAwLTAwMDAwYzkzOGVmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAxLjUwNTgzNl0gIDAwMDAwYzkzOGYwMDAtMDAwMDBjOTM5MGZmZiB0eXBlPTMgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNTEyNzY3XSAgMDAwMDBjOTM5MTAwMC0wMDAwMGM5
MzkyZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS41MTk3MDJd
ICAwMDAwMGM5MzkzMDAwLTAwMDAwYzkzOTlmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAxLjUyNjYzM10gIDAwMDAwYzkzOWEwMDAtMDAwMDBjOTM5YmZmZiB0eXBl
PTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNTMzNTY5XSAgMDAwMDBjOTM5
YzAwMC0wMDAwMGM5MzljZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMS41NDA1MDBdICAwMDAwMGM5MzlkMDAwLTAwMDAwYzkzYTBmZmYgdHlwZT00IGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjU0NzQzNV0gIDAwMDAwYzkzYTEwMDAtMDAwMDBj
OTNiN2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNTU0MzY3
XSAgMDAwMDBjOTNiODAwMC0wMDAwMGM5M2I5ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMS41NjEzMDBdICAwMDAwMGM5M2JhMDAwLTAwMDAwYzkzYmJmZmYgdHlw
ZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjU2ODIzNF0gIDAwMDAwYzkz
YmMwMDAtMDAwMDBjOTNiY2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDEuNTc1MTY4XSAgMDAwMDBjOTNiZDAwMC0wMDAwMGM5M2NiZmZmIHR5cGU9MyBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS41ODIxMDJdICAwMDAwMGM5M2NjMDAwLTAwMDAw
YzkzZDRmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjU4OTAz
NF0gIDAwMDAwYzkzZDUwMDAtMDAwMDBjOTNkNmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDEuNTk1OTY5XSAgMDAwMDBjOTNkNzAwMC0wMDAwMGM5M2Q4ZmZmIHR5
cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS42MDI5MDBdICAwMDAwMGM5
M2Q5MDAwLTAwMDAwYzkzZDlmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAxLjYwOTgzNF0gIDAwMDAwYzkzZGEwMDAtMDAwMDBjOTNkYWZmZiB0eXBlPTQgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNjE2NzY3XSAgMDAwMDBjOTNkYjAwMC0wMDAw
MGM5M2RiZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS42MjM3
MDJdICAwMDAwMGM5M2RjMDAwLTAwMDAwYzk1MjlmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAxLjYzMDYzNl0gIDAwMDAwYzk1MmEwMDAtMDAwMDBjOTUzM2ZmZiB0
eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNjM3NTY4XSAgMDAwMDBj
OTUzNDAwMC0wMDAwMGM5NTM1ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMS42NDQ0OTldICAwMDAwMGM5NTM2MDAwLTAwMDAwYzk1MzlmZmYgdHlwZT0zIGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjY1MTQzM10gIDAwMDAwYzk1M2EwMDAtMDAw
MDBjOTUzZGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNjU4
MzY4XSAgMDAwMDBjOTUzZTAwMC0wMDAwMGM5NTQ1ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMS42NjUyOTldICAwMDAwMGM5NTQ2MDAwLTAwMDAwYzk1NDdmZmYg
dHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjY3MjIzNV0gIDAwMDAw
Yzk1NDgwMDAtMDAwMDBjOTU0YmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDEuNjc5MTY2XSAgMDAwMDBjOTU0YzAwMC0wMDAwMGM5NTRkZmZmIHR5cGU9NCBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS42ODYwOTldICAwMDAwMGM5NTRlMDAwLTAw
MDAwYzk1NTZmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjY5
MzAzMl0gIDAwMDAwYzk1NTcwMDAtMDAwMDBjOTU1YWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDEuNjk5OTY3XSAgMDAwMDBjOTU1YjAwMC0wMDAwMGM5NTVjZmZm
IHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS43MDY5MDJdICAwMDAw
MGM5NTVkMDAwLTAwMDAwYzk1NWZmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAxLjcxMzgzM10gIDAwMDAwYzk1NjAwMDAtMDAwMDBjOTU2Y2ZmZiB0eXBlPTMgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNzIwNzY4XSAgMDAwMDBjOTU2ZDAwMC0w
MDAwMGM5N2ZmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS43
Mjc2OTldICAwMDAwMGM5ODAwMDAwLTAwMDAwYzk4MWFmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAxLjczNDYzNF0gIDAwMDAwYzk4MWIwMDAtMDAwMDBjOTgyYWZm
ZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNzQxNTY2XSAgMDAw
MDBjOTgyYjAwMC0wMDAwMGM5ODNkZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMS43NDg1MDFdICAwMDAwMGM5ODNlMDAwLTAwMDAwYzk4M2ZmZmYgdHlwZT00IGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjc1NTQzM10gIDAwMDAwYzk4NDAwMDAt
MDAwMDBjOTg0M2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEu
NzYyMzY2XSAgMDAwMDBjOTg0NDAwMC0wMDAwMGM5ODQ4ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMS43NjkzMDBdICAwMDAwMGM5ODQ5MDAwLTAwMDAwYzk4NWJm
ZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjc3NjIzNF0gIDAw
MDAwYzk4NWMwMDAtMDAwMDBjOTg2MGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDEuNzgzMTY2XSAgMDAwMDBjOTg2MTAwMC0wMDAwMGM5ODYxZmZmIHR5cGU9MyBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS43OTAxMDFdICAwMDAwMGM5ODYyMDAw
LTAwMDAwYzk4NjJmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAx
Ljc5NzAzM10gIDAwMDAwYzk4NjMwMDAtMDAwMDBjOTg2M2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDEuODAzOTY4XSAgMDAwMDBjOTg2NDAwMC0wMDAwMGM5ODY2
ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS44MTA4OTldICAw
MDAwMGM5ODY3MDAwLTAwMDAwYzk4NzRmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAxLjgxNzgzNF0gIDAwMDAwYzk4NzUwMDAtMDAwMDBjOTg3NWZmZiB0eXBlPTQg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuODI0NzY2XSAgMDAwMDBjOTg3NjAw
MC0wMDAwMGM5ODc2ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
MS44MzE3MDFdICAwMDAwMGM5ODc3MDAwLTAwMDAwYzk4ODJmZmYgdHlwZT00IGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjgzODYzM10gIDAwMDAwYzk4ODMwMDAtMDAwMDBjOTg4
YmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuODQ1NTY1XSAg
MDAwMDBjOTg4YzAwMC0wMDAwMGM5ODhlZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMS44NTI1MDFdICAwMDAwMGM5ODhmMDAwLTAwMDAwYzk4OTRmZmYgdHlwZT0z
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjg1OTQzM10gIDAwMDAwYzk4OTUw
MDAtMDAwMDBjOThlMWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDEuODY2MzY4XSAgMDAwMDBjOThlMjAwMC0wMDAwMGM5OTBmZmZmIHR5cGU9MyBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS44NzMzMDBdICAwMDAwMGM5OTEwMDAwLTAwMDAwYzk5
MTFmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjg4MDIzMl0g
IDAwMDAwYzk5MTIwMDAtMDAwMDBjOTkxM2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDEuODg3MTY1XSAgMDAwMDBjOTkxNDAwMC0wMDAwMGM5OTE1ZmZmIHR5cGU9
NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS44OTQxMDBdICAwMDAwMGM5OTE2
MDAwLTAwMDAwYzk5MmRmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAxLjkwMTAzMl0gIDAwMDAwYzk5MmUwMDAtMDAwMDBjOTkzOWZmZiB0eXBlPTQgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuOTA3OTY3XSAgMDAwMDBjOTkzYTAwMC0wMDAwMGM5
OTYwZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS45MTQ4OThd
ICAwMDAwMGM5OTYxMDAwLTAwMDAwYzk5NjRmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAxLjkyMTgzNF0gIDAwMDAwYzk5NjUwMDAtMDAwMDBjOTk2Y2ZmZiB0eXBl
PTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuOTI4NzY2XSAgMDAwMDBjOTk2
ZDAwMC0wMDAwMGM5OTc0ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMS45MzU2OThdICAwMDAwMGM5OTc1MDAwLTAwMDAwYzk5N2VmZmYgdHlwZT0zIGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjk0MjYzMl0gIDAwMDAwYzk5N2YwMDAtMDAwMDBj
OTk4OGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuOTQ5NTY1
XSAgMDAwMDBjOTk4OTAwMC0wMDAwMGM5OWFkZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMS45NTY0OThdICAwMDAwMGM5OWFlMDAwLTAwMDAwYzk5YjdmZmYgdHlw
ZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjk2MzQzM10gIDAwMDAwYzk5
YjgwMDAtMDAwMDBjOTliOGZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDEuOTcwMzY3XSAgMDAwMDBjOTliOTAwMC0wMDAwMGM5OWI5ZmZmIHR5cGU9NCBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS45NzcyOTldICAwMDAwMGM5OWJhMDAwLTAwMDAw
Yzk5YzFmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjk4NDIz
NF0gIDAwMDAwYzk5YzIwMDAtMDAwMDBjOTljNGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDEuOTkxMTY2XSAgMDAwMDBjOTljNTAwMC0wMDAwMGM5OWM2ZmZmIHR5
cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS45OTgxMDFdICAwMDAwMGM5
OWM3MDAwLTAwMDAwYzk5YzdmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAyLjAwNTAzMl0gIDAwMDAwYzk5YzgwMDAtMDAwMDBjOTlkNWZmZiB0eXBlPTMgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMDExOTY2XSAgMDAwMDBjOTlkNjAwMC0wMDAw
MGM5OWQ5ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4wMTg4
OThdICAwMDAwMGM5OWRhMDAwLTAwMDAwYzk5ZGZmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAyLjAyNTgzMl0gIDAwMDAwYzk5ZTAwMDAtMDAwMDBjOTllNWZmZiB0
eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMDMyNzY3XSAgMDAwMDBj
OTllNjAwMC0wMDAwMGM5OWU2ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMi4wMzk2OThdICAwMDAwMGM5OWU3MDAwLTAwMDAwYzk5ZThmZmYgdHlwZT00IGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjA0NjYzM10gIDAwMDAwYzk5ZTkwMDAtMDAw
MDBjOTlmZGZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMDUz
NTY1XSAgMDAwMDBjOTlmZTAwMC0wMDAwMGM5OWZlZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMi4wNjA0OThdICAwMDAwMGM5OWZmMDAwLTAwMDAwYzlhMDFmZmYg
dHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjA2NzQzM10gIDAwMDAw
YzlhMDIwMDAtMDAwMDBjOWEwMmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDIuMDc0MzY1XSAgMDAwMDBjOWEwMzAwMC0wMDAwMGM5YTEyZmZmIHR5cGU9MyBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4wODEyOThdICAwMDAwMGM5YTEzMDAwLTAw
MDAwYzlhMTVmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjA4
ODIzMl0gIDAwMDAwYzlhMTYwMDAtMDAwMDBjOWExN2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDIuMDk1MTY3XSAgMDAwMDBjOWExODAwMC0wMDAwMGM5YTE5ZmZm
IHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4xMDIwOThdICAwMDAw
MGM5YTFhMDAwLTAwMDAwYzlhMmZmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAyLjEwOTAzM10gIDAwMDAwYzlhMzAwMDAtMDAwMDBjOWEzMGZmZiB0eXBlPTQgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMTE1OTY1XSAgMDAwMDBjOWEzMTAwMC0w
MDAwMGM5YTMxZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4x
MjI5MDBdICAwMDAwMGM5YTMyMDAwLTAwMDAwYzlhMzJmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAyLjEyOTgzM10gIDAwMDAwYzlhMzMwMDAtMDAwMDBjOWEzM2Zm
ZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMTM2NzY1XSAgMDAw
MDBjOWEzNDAwMC0wMDAwMGM5YTM0ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMi4xNDM2OThdICAwMDAwMGM5YTM1MDAwLTAwMDAwYzlhMzVmZmYgdHlwZT0zIGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjE1MDYzM10gIDAwMDAwYzlhMzYwMDAt
MDAwMDBjOWEzNmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIu
MTU3NTY1XSAgMDAwMDBjOWEzNzAwMC0wMDAwMGM5YTM3ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMi4xNjQ0OTldICAwMDAwMGM5YTM4MDAwLTAwMDAwYzlhMzhm
ZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjE3MTQzMl0gIDAw
MDAwYzlhMzkwMDAtMDAwMDBjOWE0YmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDIuMTc4MzY0XSAgMDAwMDBjOWE0YzAwMC0wMDAwMGM5YTRkZmZmIHR5cGU9NCBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4xODUzMDBdICAwMDAwMGM5YTRlMDAw
LTAwMDAwYzlhNTJmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAy
LjE5MjIzMV0gIDAwMDAwYzlhNTMwMDAtMDAwMDBjOWE1N2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMTk5MTY2XSAgMDAwMDBjOWE1ODAwMC0wMDAwMGM5YTVj
ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4yMDYwOTldICAw
MDAwMGM5YTVkMDAwLTAwMDAwYzlhNWZmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAyLjIxMzAzM10gIDAwMDAwYzlhNjAwMDAtMDAwMDBjOWE2NmZmZiB0eXBlPTMg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMjE5OTY2XSAgMDAwMDBjOWE2NzAw
MC0wMDAwMGM5YTY5ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
Mi4yMjY4OTddICAwMDAwMGM5YTZhMDAwLTAwMDAwYzlhNzNmZmYgdHlwZT0zIGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjIzMzgzMl0gIDAwMDAwYzlhNzQwMDAtMDAwMDBjOWE4
YWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMjQwNzY0XSAg
MDAwMDBjOWE4YjAwMC0wMDAwMGM5YTljZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMi4yNDc2OTldICAwMDAwMGM5YTlkMDAwLTAwMDAwYzlhOWRmZmYgdHlwZT00
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjI1NDYzM10gIDAwMDAwYzlhOWUw
MDAtMDAwMDBjOWE5ZmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDIuMjYxNTY1XSAgMDAwMDBjOWFhMDAwMC0wMDAwMGM5YWE3ZmZmIHR5cGU9NCBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4yNjg0OTddICAwMDAwMGM5YWE4MDAwLTAwMDAwYzlh
YThmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjI3NTQzMV0g
IDAwMDAwYzlhYTkwMDAtMDAwMDBjOWFhOWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDIuMjgyMzY2XSAgMDAwMDBjOWFhYTAwMC0wMDAwMGM5YWFhZmZmIHR5cGU9
MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4yODkyOTddICAwMDAwMGM5YWFi
MDAwLTAwMDAwYzlhYWNmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAyLjI5NjIzM10gIDAwMDAwYzlhYWQwMDAtMDAwMDBjOWFiMWZmZiB0eXBlPTMgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMzAzMTY1XSAgMDAwMDBjOWFiMjAwMC0wMDAwMGM5
YWIzZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4zMTAwOTld
ICAwMDAwMGM5YWI0MDAwLTAwMDAwYzlhYjdmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAyLjMxNzAzMV0gIDAwMDAwYzlhYjgwMDAtMDAwMDBjOWFiOGZmZiB0eXBl
PTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMzIzOTY2XSAgMDAwMDBjOWFi
OTAwMC0wMDAwMGM5YWJlZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMi4zMzA5MDBdICAwMDAwMGM5YWJmMDAwLTAwMDAwYzlhYmZmZmYgdHlwZT00IGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjMzNzgzMV0gIDAwMDAwYzlhYzAwMDAtMDAwMDBj
OWFjYmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMzQ0NzY2
XSAgMDAwMDBjOWFjYzAwMC0wMDAwMGM5YWNjZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMi4zNTE2OThdICAwMDAwMGM5YWNkMDAwLTAwMDAwYzlhY2VmZmYgdHlw
ZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjM1ODYzM10gIDAwMDAwYzlh
Y2YwMDAtMDAwMDBjOWFkMGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDIuMzY1NTY1XSAgMDAwMDBjOWFkMTAwMC0wMDAwMGM5YWQxZmZmIHR5cGU9MyBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4zNzI0OTldICAwMDAwMGM5YWQyMDAwLTAwMDAw
YzlhZDJmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjM3OTQz
MF0gIDAwMDAwYzlhZDMwMDAtMDAwMDBjOWFlZWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDIuMzg2MzY0XSAgMDAwMDBjOWFlZjAwMC0wMDAwMGM5YWYxZmZmIHR5
cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4zOTMyOThdICAwMDAwMGM5
YWYyMDAwLTAwMDAwYzlhZjNmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAyLjQwMDIzMV0gIDAwMDAwYzlhZjQwMDAtMDAwMDBjOWFmN2ZmZiB0eXBlPTQgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNDA3MTY1XSAgMDAwMDBjOWFmODAwMC0wMDAw
MGM5YWZiZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi40MTQw
OTddICAwMDAwMGM5YWZjMDAwLTAwMDAwYzlhZmRmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAyLjQyMTAzM10gIDAwMDAwYzlhZmUwMDAtMDAwMDBjOWIwN2ZmZiB0
eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNDI3OTYzXSAgMDAwMDBj
OWIwODAwMC0wMDAwMGM5ZjA3ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMi40MzQ4OTddICAwMDAwMGM5ZjA4MDAwLTAwMDAwYzlmMjdmZmYgdHlwZT0zIGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjQ0MTgzMl0gIDAwMDAwYzlmMjgwMDAtMDAw
MDBjOWYyOWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNDQ4
NzYzXSAgMDAwMDBjOWYyYTAwMC0wMDAwMGM5ZjJiZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMi40NTU2OThdICAwMDAwMGM5ZjJjMDAwLTAwMDAwYzlmMmRmZmYg
dHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjQ2MjYzMl0gIDAwMDAw
YzlmMmUwMDAtMDAwMDBjOWYyZWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDIuNDY5NTYzXSAgMDAwMDBjOWYyZjAwMC0wMDAwMGM5ZjJmZmZmIHR5cGU9NCBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi40NzY0OThdICAwMDAwMGM5ZjMwMDAwLTAw
MDAwYzlmMzBmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjQ4
MzQzMl0gIDAwMDAwYzlmMzEwMDAtMDAwMDBjOWYzMWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDIuNDkwMzYzXSAgMDAwMDBjOWYzMjAwMC0wMDAwMGM5ZjM2ZmZm
IHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi40OTcyOThdICAwMDAw
MGM5ZjM3MDAwLTAwMDAwYzlmM2FmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAyLjUwNDIzMF0gIDAwMDAwYzlmM2IwMDAtMDAwMDBjOWYzYmZmZiB0eXBlPTMgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNTExMTYzXSAgMDAwMDBjOWYzYzAwMC0w
MDAwMGM5ZjNjZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi41
MTgwOTZdICAwMDAwMGM5ZjNkMDAwLTAwMDAwYzlmM2RmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAyLjUyNTAzMV0gIDAwMDAwYzlmM2UwMDAtMDAwMDBjYTQxMWZm
ZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNTMxOTYzXSAgMDAw
MDBjYTQxMjAwMC0wMDAwMGNhNDEzZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMi41Mzg4OThdICAwMDAwMGNhNDE0MDAwLTAwMDAwY2E0MTVmZmYgdHlwZT00IGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjU0NTgzMl0gIDAwMDAwY2E0MTYwMDAt
MDAwMDBjYTQxY2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIu
NTUyNzYyXSAgMDAwMDBjYTQxZDAwMC0wMDAwMGNhNDFkZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMi41NTk2OTZdICAwMDAwMGNhNDFlMDAwLTAwMDAwY2E0MWVm
ZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjU2NjYzMl0gIDAw
MDAwY2E0MWYwMDAtMDAwMDBjYTQ4OGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDIuNTczNTY0XSAgMDAwMDBjYTQ4OTAwMC0wMDAwMGNhNDg5ZmZmIHR5cGU9MyBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi41ODA0OThdICAwMDAwMGNhNDhhMDAw
LTAwMDAwY2E0OGJmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAy
LjU4NzQzMl0gIDAwMDAwY2E0OGMwMDAtMDAwMDBjYTQ4Y2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNTk0MzYzXSAgMDAwMDBjYTQ4ZDAwMC0wMDAwMGNhNDkx
ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi42MDEyOTZdICAw
MDAwMGNhNDkyMDAwLTAwMDAwY2E0OTRmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAyLjYwODIzMV0gIDAwMDAwY2E0OTUwMDAtMDAwMDBjYWJjOGZmZiB0eXBlPTQg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNjE1MTYzXSAgMDAwMDBjYWJjOTAw
MC0wMDAwMGNjMTRjZmZmIHR5cGU9MCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
Mi42MjIwOTddICAwMDAwMGNjMTRkMDAwLTAwMDAwY2MxOTVmZmYgdHlwZT05IGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjYyOTAzMF0gIDAwMDAwY2MxOTYwMDAtMDAwMDBjYzM4
OGZmZiB0eXBlPTEwIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjYzNjA1MV0g
IDAwMDAwY2MzODkwMDAtMDAwMDBjYzM4OWZmZiB0eXBlPTAgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDIuNjQyOTgzXSAgMDAwMDBjYzM4YTAwMC0wMDAwMGNjNzA5ZmZmIHR5cGU9
MTAgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNjUwMDA0XSAgMDAwMDBjYzcw
YTAwMC0wMDAwMGNkMTc5ZmZmIHR5cGU9NiBhdHRyPTgwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMi42NTY5MzddICAwMDAwMGNkMTdhMDAwLTAwMDAwY2QxZmVmZmYgdHlwZT01IGF0dHI9ODAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjY2Mzg3MV0gIDAwMDAwY2QxZmYwMDAtMDAwMDBj
ZDdmZmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNjcwODAz
XSAgMDAwMDBjZDgwMDAwMC0wMDAwMGNkOGU5ZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMi42Nzc3MzhdICAwMDAwMGNkOGVhMDAwLTAwMDAwY2Q5ZTlmZmYgdHlw
ZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjY4NDY2OV0gIDAwMDAwY2Q5
ZWEwMDAtMDAwMDBjZGEwNWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDIuNjkxNjA0XSAgMDAwMDBjZGEwNjAwMC0wMDAwMGNkYTMxZmZmIHR5cGU9NCBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi42OTg1MzZdICAwMDAwMGNkYTMyMDAwLTAwMDAw
Y2RhNDRmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjcwNTQ3
MV0gIDAwMDAwY2RhNDUwMDAtMDAwMDBjZGY1N2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDIuNzEyNDAzXSAgMDAwMDBjZGY1ODAwMC0wMDAwMGNkZjVhZmZmIHR5
cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi43MTkzMzVdICAwMDAwMGNk
ZjViMDAwLTAwMDAwY2RmNmRmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAyLjcyNjI3MV0gIDAwMDAwY2RmNmUwMDAtMDAwMDBjZGY3N2ZmZiB0eXBlPTMgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNzMzMjAyXSAgMDAwMDBjZGY3ODAwMC0wMDAw
MGNkZjkxZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi43NDAx
MzhdICAwMDAwMGNkZjkyMDAwLTAwMDAwY2RmOTdmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAyLjc0NzA2OV0gIDAwMDAwY2RmOTgwMDAtMDAwMDBjZGZhZGZmZiB0
eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNzU0MDA1XSAgMDAwMDBj
ZGZhZTAwMC0wMDAwMGNkZmIxZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMi43NjA5MzZdICAwMDAwMGNkZmIyMDAwLTAwMDAwY2RmYzVmZmYgdHlwZT00IGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjc2Nzg2OV0gIDAwMDAwY2RmYzYwMDAtMDAw
MDBjZGZjYWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNzc0
ODAzXSAgMDAwMDBjZGZjYjAwMC0wMDAwMGNkZmRmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMi43ODE3MzhdICAwMDAwMGNkZmUwMDAwLTAwMDAwY2RmZjFmZmYg
dHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjc4ODY2OV0gIDAwMDAw
Y2RmZjIwMDAtMDAwMDBjZGZmOWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDIuNzk1NjA0XSAgMDAwMDBjZGZmYTAwMC0wMDAwMGNkZmZmZmZmIHR5cGU9MyBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi44MDI1MzVdICAwMDAwMTAwMDAwMDAwLTAw
MDA4MGYzM2ZmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjgw
OTQ3MF0gIDAwMDAwMDAwYTAwMDAtMDAwMDAwMDBmZmZmZiB0eXBlPTAgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDIuODE2NDAyXSAgMDAwMDBjZTAwMDAwMC0wMDAwMGNmZmZmZmZm
IHR5cGU9MCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi44MjMzMzVdICAwMDAw
MGYwMDAwMDAwLTAwMDAwZjdmZmZmZmYgdHlwZT0xMSBhdHRyPTgwMDAwMDAwMDAwMDEwMGQNCihY
RU4pIFsgICAgMi44MzAzNTddICAwMDAwMGZkMDAwMDAwLTAwMDAwZmVkZmZmZmYgdHlwZT0xMSBh
dHRyPTgwMDAwMDAwMDAwMDEwMGQNCihYRU4pIFsgICAgMi44MzczNzddICAwMDAwMGZlZTAwMDAw
LTAwMDAwZmVlMDBmZmYgdHlwZT0xMSBhdHRyPTgwMDAwMDAwMDAwMDAwMDENCihYRU4pIFsgICAg
Mi44NDQzOTddICAwMDAwMGZlZTAxMDAwLTAwMDAwZmZmZmZmZmYgdHlwZT0xMSBhdHRyPTgwMDAw
MDAwMDAwMDEwMGQNCihYRU4pIFsgICAgMi44NTE0MTZdICAwMDAwODBmMzQwMDAwLTAwMDA4MmZm
ZmZmZmYgdHlwZT0wIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjg1ODM1MV0g
IDAwMDA4MzAwMDAwMDAtMDAwMDg1MDFmZmZmZiB0eXBlPTExIGF0dHI9ODAwMDAwMDAwMDAwMTAw
ZA0KKFhFTikgWyAgICAyLjg2NTM3MV0gYWx0IHRhYmxlIGZmZmY4MmQwNDA0YTIwMTggLT4gZmZm
ZjgyZDA0MDRiM2VmYw0KKFhFTikgWyAgICAyLjg4NDc2Nl0gQU1ELVZpOiBJT01NVSBFeHRlbmRl
ZCBGZWF0dXJlczoNCihYRU4pIFsgICAgMi44ODk1MzFdIC0gUGVyaXBoZXJhbCBQYWdlIFNlcnZp
Y2UgUmVxdWVzdA0KKFhFTikgWyAgICAyLjg5NDM4NF0gLSB4MkFQSUMNCihYRU4pIFsgICAgMi44
OTcwNzFdIC0gTlggYml0DQooWEVOKSBbICAgIDIuODk5NzU5XSAtIEludmFsaWRhdGUgQWxsIENv
bW1hbmQNCihYRU4pIFsgICAgMi45MDM4MzFdIC0gR3Vlc3QgQVBJQw0KKFhFTikgWyAgICAyLjkw
Njg2Nl0gLSBQZXJmb3JtYW5jZSBDb3VudGVycw0KKFhFTikgWyAgICAyLjkxMDc2NF0gLSBIb3N0
IEFkZHJlc3MgVHJhbnNsYXRpb24gU2l6ZTogMHgyDQooWEVOKSBbICAgIDIuOTE1ODc4XSAtIEd1
ZXN0IEFkZHJlc3MgVHJhbnNsYXRpb24gU2l6ZTogMA0KKFhFTikgWyAgICAyLjkyMDkwNl0gLSBH
dWVzdCBDUjMgUm9vdCBUYWJsZSBMZXZlbDogMHgxDQooWEVOKSBbICAgIDIuOTI1NzU5XSAtIE1h
eGltdW0gUEFTSUQ6IDB4Zg0KKFhFTikgWyAgICAyLjkyOTQ4NV0gLSBTTUkgRmlsdGVyIFJlZ2lz
dGVyOiAweDENCihYRU4pIFsgICAgMi45MzM3MzJdIC0gU01JIEZpbHRlciBSZWdpc3RlciBDb3Vu
dDogMHgxDQooWEVOKSBbICAgIDIuOTM4NDk5XSAtIEd1ZXN0IFZpcnR1YWwgQVBJQyBNb2Rlczog
MHgxDQooWEVOKSBbICAgIDIuOTQzMTc3XSAtIER1YWwgUFBSIExvZzogMHgyDQooWEVOKSBbICAg
IDIuOTQ2ODE5XSAtIER1YWwgRXZlbnQgTG9nOiAweDINCihYRU4pIFsgICAgMi45NTA2MzFdIC0g
VXNlciAvIFN1cGVydmlzb3IgUGFnZSBQcm90ZWN0aW9uDQooWEVOKSBbICAgIDIuOTU1NjU4XSAt
IERldmljZSBUYWJsZSBTZWdtZW50YXRpb246IDB4Mw0KKFhFTikgWyAgICAyLjk2MDQyNV0gLSBQ
UFIgTG9nIE92ZXJmbG93IEVhcmx5IFdhcm5pbmcNCihYRU4pIFsgICAgMi45NjUxOTJdIC0gUFBS
IEF1dG9tYXRpYyBSZXNwb25zZQ0KKFhFTikgWyAgICAyLjk2OTI2Nl0gLSBNZW1vcnkgQWNjZXNz
IFJvdXRpbmcgYW5kIENvbnRyb2w6IDANCihYRU4pIFsgICAgMi45NzQ1NTJdIC0gQmxvY2sgU3Rv
cE1hcmsgTWVzc2FnZQ0KKFhFTikgWyAgICAyLjk3ODYyNF0gLSBQZXJmb3JtYW5jZSBPcHRpbWl6
YXRpb24NCihYRU4pIFsgICAgMi45ODI4NzJdIC0gTVNJIENhcGFiaWxpdHkgTU1JTyBBY2Nlc3MN
CihYRU4pIFsgICAgMi45ODcyOTNdIC0gR3Vlc3QgSS9PIFByb3RlY3Rpb24NCihYRU4pIFsgICAg
Mi45OTExOTBdIC0gRW5oYW5jZWQgUFBSIEhhbmRsaW5nDQooWEVOKSBbICAgIDIuOTk1MTc4XSAt
IEF0dHJpYnV0ZSBGb3J3YXJkDQooWEVOKSBbICAgIDIuOTk4ODE3XSAtIEludmFsaWRhdGUgSU9U
TEIgVHlwZQ0KKFhFTikgWyAgICAzLjAwMjgwNV0gLSBWTSBUYWJsZSBTaXplOiAwDQooWEVOKSBb
ICAgIDMuMDA2MzU3XSAtIEd1ZXN0IEFjY2VzcyBCaXQgVXBkYXRlIERpc2FibGUNCihYRU4pIFsg
ICAgMy4wMjI2NjldIEFNRC1WaTogRGlzYWJsZWQgSEFQIG1lbW9yeSBtYXAgc2hhcmluZyB3aXRo
IElPTU1VDQooWEVOKSBbICAgIDMuMDI4OTk2XSBBTUQtVmk6IElPTU1VIDAgRW5hYmxlZC4NCihY
RU4pIFsgICAgMy4wMzMwNzBdIEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVkDQooWEVOKSBbICAg
IDMuMDM3MzE2XSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQNCihYRU4pIFsgICAgMy4wNDExMjddIElu
dGVycnVwdCByZW1hcHBpbmcgZW5hYmxlZA0KKFhFTikgWyAgICAzLjA0NTQ2Ml0gbnJfc29ja2V0
czogMQ0KKFhFTikgWyAgICAzLjA0ODU4M10gRW5hYmxpbmcgQVBJQyBtb2RlLiAgVXNpbmcgMiBJ
L08gQVBJQ3MNCihYRU4pIFsgICAgMy4wNTQ0NzFdIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhF
TikgWyAgICAzLjA1ODI4Nl0gIC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9kDQooWEVOKSBbICAgIDMu
MDYyMzgzXSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4y
PS0xDQooWEVOKSBbICAgIDMuMjE4NzM1XSBXYWxsY2xvY2sgc291cmNlOiBDTU9TIFJUQw0KKFhF
TikgWyAgICAzLjk4OTEzM10gQWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiAxMjggS2lCLg0KKFhF
TikgWyAgICAzLjk5NDA3NF0gbXdhaXQtaWRsZTogZG9lcyBub3QgcnVuIG9uIGZhbWlseSAyMyBt
b2RlbCA5Ng0KKFhFTikgWyAgICA0LjAwMDA1Ml0gSFZNOiBBU0lEcyBlbmFibGVkLg0KKFhFTikg
WyAgICA0LjAwMzY5M10gU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBb
ICAgIDQuMDA4NTQ2XSAgLSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkNCihYRU4pIFsgICAgNC4w
MTI4ODFdICAtIExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBWaXJ0dWFsaXNhdGlvbg0KKFhFTikg
WyAgICA0LjAxODUxM10gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVA0KKFhFTikgWyAgICA0
LjAyMjkzNF0gIC0gVk1DQiBDbGVhbiBCaXRzDQooWEVOKSBbICAgIDQuMDI2NDg2XSAgLSBUTEIg
Zmx1c2ggYnkgQVNJRA0KKFhFTikgWyAgICA0LjAzMDIxM10gIC0gRGVjb2RlQXNzaXN0cw0KKFhF
TikgWyAgICA0LjAzMzU5NF0gIC0gVmlydHVhbCBWTUxPQUQvVk1TQVZFDQooWEVOKSBbICAgIDQu
MDM3NjY1XSAgLSBWaXJ0dWFsIEdJRg0KKFhFTikgWyAgICA0LjA0MDg3Ml0gIC0gUGF1c2UtSW50
ZXJjZXB0IEZpbHRlcg0KKFhFTikgWyAgICA0LjA0NTAzMV0gIC0gUGF1c2UtSW50ZXJjZXB0IEZp
bHRlciBUaHJlc2hvbGQNCihYRU4pIFsgICAgNC4wNTAwNjBdICAtIFRTQyBSYXRlIE1TUg0KKFhF
TikgWyAgICA0LjA1MzM1NF0gIC0gTVNSX1NQRUNfQ1RSTCB2aXJ0dWFsaXNhdGlvbg0KKFhFTikg
WyAgICA0LjA1ODAzM10gSFZNOiBTVk0gZW5hYmxlZA0KKFhFTikgWyAgICA0LjA2MTQxMl0gSFZN
OiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsgICAgNC4w
NjcyMTldIEhWTTogSEFQIHBhZ2Ugc2l6ZXM6IDRrQiwgMk1CLCAxR0INCihYRU4pIFsgICAgNC4z
Nzg3MTNdIEJyb3VnaHQgdXAgMTYgQ1BVcw0KKFhFTikgWyAgICA0LjM4MzQzOV0gU2NoZWR1bGlu
ZyBncmFudWxhcml0eTogY3B1LCAxIENQVSBwZXIgc2NoZWQtcmVzb3VyY2UNCihYRU4pIFsgICAg
NC4zOTAwMjFdIEluaXRpYWxpemluZyBudWxsIHNjaGVkdWxlcg0KKFhFTikgWyAgICA0LjM5NDM1
N10gV0FSTklORzogVGhpcyBpcyBleHBlcmltZW50YWwgc29mdHdhcmUgaW4gZGV2ZWxvcG1lbnQu
DQooWEVOKSBbICAgIDQuNDAxMDI3XSBVc2UgYXQgeW91ciBvd24gcmlzay4NCihYRU4pIFsgICAg
NC40MDQ4NDRdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRl
ZC4NCihYRU4pIFsgICAgNC40MTEwODVdIFJ1bm5pbmcgc3R1YiByZWNvdmVyeSBzZWxmdGVzdHMu
Li4NCihYRU4pIFsgICAgNC40MTYwMjNdIEZpeHVwICNVRFswMDAwXTogZmZmZjgyZDA3ZmZmZTA0
NCBbZmZmZjgyZDA3ZmZmZTA0NF0gLT4gZmZmZjgyZDA0MDM5NTUwMg0KKFhFTikgWyAgICA0LjQy
NDI1N10gRml4dXAgI0dQWzAwMDBdOiBmZmZmODJkMDdmZmZlMDQ1IFtmZmZmODJkMDdmZmZlMDQ1
XSAtPiBmZmZmODJkMDQwMzk1NTAyDQooWEVOKSBbICAgIDQuNDMyNDkwXSBGaXh1cCAjU1NbMDAw
MF06IGZmZmY4MmQwN2ZmZmUwNDQgW2ZmZmY4MmQwN2ZmZmUwNDRdIC0+IGZmZmY4MmQwNDAzOTU1
MDINCihYRU4pIFsgICAgNC40NDA3MjFdIEZpeHVwICNCUFswMDAwXTogZmZmZjgyZDA3ZmZmZTA0
NSBbZmZmZjgyZDA3ZmZmZTA0NV0gLT4gZmZmZjgyZDA0MDM5NTUwMg0KKFhFTikgWyAgICA0LjQ2
ODg3OF0gTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbiBhY3RpdmUNCihYRU4pIFsgICAg
NC40NzQxNjZdIGQwIGhhcyBtYXhpbXVtIDMzMjggUElSUXMNCihYRU4pIFsgICAgNC40Nzg0OTBd
ICoqKiBCdWlsZGluZyBhIFBWSCBEb20wICoqKg0KKFhFTikgWyAgICA0LjQ4NjkxMl0gZDA6IGlk
ZW50aXR5IG1hcHBpbmdzIGZvciBJT01NVToNCihYRU4pIFsgICAgNC40OTE2NzldICBbMDAwMDAw
MDBhMCwgMDAwMDAwMDBmZl0gUlcNCihYRU4pIFsgICAgNC40OTYxMDBdICBbMDAwMDAwOWJmZiwg
MDAwMDAwOWZmZl0gUlcNCihYRU4pIFsgICAgNC41MDA1MTldICBbMDAwMDBjYWJjOSwgMDAwMDBj
YzE0Y10gUlcNCihYRU4pIFsgICAgNC41MDUyNDBdICBbMDAwMDBjYzM4OSwgMDAwMDBjYzM4OV0g
UlcNCihYRU4pIFsgICAgNC41MDk2NjFdICBbMDAwMDBjYzcwYSwgMDAwMDBjZDFmZV0gUlcNCihY
RU4pIFsgICAgNC41MTQ3ODBdICBbMDAwMDBjZTAwMCwgMDAwMDBjZmZmZl0gUlcNCihYRU4pIFsg
ICAgNC41MTkyMDBdICBbMDAwMDBmZDAwMCwgMDAwMDBmZDJmZl0gUlcNCihYRU4pIFsgICAgNC41
MjM3NzBdICBbMDAwMDBmZDMwNCwgMDAwMDBmZWJmZl0gUlcNCihYRU4pIFsgICAgNC41MjgzNDFd
ICBbMDAwMDBmZWMwMiwgMDAwMDBmZWRmZl0gUlcNCihYRU4pIFsgICAgNC41MzMxOTVdICBbMDAw
MDBmZWUwMSwgMDAwMDBmZmZmZl0gUlcNCihYRU4pIFsgICAgNC41MzgwNDZdICBbMDAwMDgwZjM0
MCwgMDAwMDg1MDFmZl0gUlcNCihYRU4pIFsgICAgNC41NDM2NjBdIDAwMDA6MDI6MDAuMDogbm90
IG1hcHBpbmcgQkFSIFtmZWEwMCwgZmVhMDNdIGludmFsaWQgcG9zaXRpb24NCihYRU4pIFsgICAg
NC41NTA5NDhdIDAwMDA6MDM6MDAuMDogbm90IG1hcHBpbmcgQkFSIFtmZTkwMCwgZmU5MGZdIGlu
dmFsaWQgcG9zaXRpb24NCihYRU4pIFsgICAgNC41NTgyMjhdIDAwMDA6MDM6MDAuMDogbm90IG1h
cHBpbmcgQkFSIFtmZTkxMCwgZmU5MTNdIGludmFsaWQgcG9zaXRpb24NCihYRU4pIFsgICAgNC41
NjU1MDNdIDAwMDA6MDQ6MDAuMDogbm90IG1hcHBpbmcgQkFSIFtmZTcwMCwgZmU3N2ZdIGludmFs
aWQgcG9zaXRpb24NCihYRU4pIFsgICAgNC41NzI5NjJdIDAwMDA6MDQ6MDAuMzogbm90IG1hcHBp
bmcgQkFSIFtmZTUwMCwgZmU1ZmZdIGludmFsaWQgcG9zaXRpb24NCihYRU4pIFsgICAgNC41ODAy
NDVdIDAwMDA6MDQ6MDAuNDogbm90IG1hcHBpbmcgQkFSIFtmZTQwMCwgZmU0ZmZdIGludmFsaWQg
cG9zaXRpb24NCihYRU4pIFsgICAgNC41ODc1MjFdIDAwMDA6MDU6MDAuMDogbm90IG1hcHBpbmcg
QkFSIFtmZTgwMSwgZmU4MDFdIGludmFsaWQgcG9zaXRpb24NCihYRU4pIFsgICAgNC41OTQ4MDBd
IDAwMDA6MDU6MDAuMTogbm90IG1hcHBpbmcgQkFSIFtmZTgwMCwgZmU4MDBdIGludmFsaWQgcG9z
aXRpb24NCihYRU4pIFsgICAgNC43MzQ3OTFdIERvbTAgbWVtb3J5IGFsbG9jYXRpb24gc3RhdHM6
DQooWEVOKSBbICAgIDQuNzM5Mjk5XSBvcmRlciAgMCBhbGxvY2F0aW9uczogNA0KKFhFTikgWyAg
ICA0Ljc0MzI4N10gb3JkZXIgIDEgYWxsb2NhdGlvbnM6IDINCihYRU4pIFsgICAgNC43NDcyNzJd
IG9yZGVyICAyIGFsbG9jYXRpb25zOiAyDQooWEVOKSBbICAgIDQuNzUxMjU1XSBvcmRlciAgMyBh
bGxvY2F0aW9uczogMg0KKFhFTikgWyAgICA0Ljc1NTI0NF0gb3JkZXIgIDQgYWxsb2NhdGlvbnM6
IDINCihYRU4pIFsgICAgNC43NTkyMzFdIG9yZGVyICA1IGFsbG9jYXRpb25zOiA0DQooWEVOKSBb
ICAgIDQuNzYzMjE2XSBvcmRlciAgNiBhbGxvY2F0aW9uczogMw0KKFhFTikgWyAgICA0Ljc2NzIw
NV0gb3JkZXIgIDcgYWxsb2NhdGlvbnM6IDUNCihYRU4pIFsgICAgNC43NzExOTNdIG9yZGVyICA4
IGFsbG9jYXRpb25zOiA0DQooWEVOKSBbICAgIDQuNzc1MTc4XSBvcmRlciAgOSBhbGxvY2F0aW9u
czogNg0KKFhFTikgWyAgICA0Ljc3OTE2Ml0gb3JkZXIgMTAgYWxsb2NhdGlvbnM6IDMNCihYRU4p
IFsgICAgNC43ODMxNTNdIG9yZGVyIDExIGFsbG9jYXRpb25zOiA2DQooWEVOKSBbICAgIDQuNzg3
MTM2XSBvcmRlciAxMiBhbGxvY2F0aW9uczogMw0KKFhFTikgWyAgICA0Ljc5MTEyN10gb3JkZXIg
MTMgYWxsb2NhdGlvbnM6IDINCihYRU4pIFsgICAgNC43OTUxMTJdIG9yZGVyIDE0IGFsbG9jYXRp
b25zOiAzDQooWEVOKSBbICAgIDQuNzk5MDk1XSBvcmRlciAxNSBhbGxvY2F0aW9uczogMQ0KKFhF
TikgWyAgICA0LjgwMzA4MV0gb3JkZXIgMTYgYWxsb2NhdGlvbnM6IDINCihYRU4pIFsgICAgNC44
MDcwNzFdIG9yZGVyIDE3IGFsbG9jYXRpb25zOiAyDQooWEVOKSBbICAgIDQuODExMDYwXSBvcmRl
ciAxOCBhbGxvY2F0aW9uczogMg0KKFhFTikgWyAgICA1LjE1Njk4MV0gRUxGOiBwaGRyOiBwYWRk
cj0weDEwMDAwMDAgbWVtc3o9MHgxYjFhMDBjDQooWEVOKSBbICAgIDUuMTYyNjE0XSBFTEY6IHBo
ZHI6IHBhZGRyPTB4MmMwMDAwMCBtZW1zej0weDg5MjAwMA0KKFhFTikgWyAgICA1LjE2ODE1OF0g
RUxGOiBwaGRyOiBwYWRkcj0weDM0OTIwMDAgbWVtc3o9MHgyZmVkOA0KKFhFTikgWyAgICA1LjE3
MzYyMl0gRUxGOiBwaGRyOiBwYWRkcj0weDM0YzIwMDAgbWVtc3o9MHg1NmUwMDANCihYRU4pIFsg
ICAgNS4xNzkxNjldIEVMRjogbWVtb3J5OiAweDEwMDAwMDAgLT4gMHgzYTMwMDAwDQooWEVOKSBb
ICAgIDUuMTg0MTk4XSBFTEY6IG5vdGU6IFBIWVMzMl9FTlRSWSA9IDB4MTAwMDAwMA0KKFhFTikg
WyAgICA1LjE4OTIyMV0gRUxGOiBub3RlOiBHVUVTVF9PUyA9ICJsaW51eCINCihYRU4pIFsgICAg
NS4xOTM3MzFdIEVMRjogbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiDQooWEVOKSBbICAgIDUu
MTk4NDk0XSBFTEY6IG5vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiDQooWEVOKSBbICAgIDUu
MjAzNDM1XSBFTEY6IG5vdGU6IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikg
WyAgICA1LjIwODk3OV0gRUxGOiBub3RlOiBJTklUX1AyTSA9IDB4ODAwMDAwMDAwMA0KKFhFTikg
WyAgICA1LjIxMzkxOV0gRUxGOiBub3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4MzRkNDYzMA0KKFhF
TikgWyAgICA1LjIxOTExOV0gRUxGOiBub3RlOiBGRUFUVVJFUyA9ICIhd3JpdGFibGVfcGFnZV90
YWJsZXMiDQooWEVOKSBbICAgIDUuMjI1MDEyXSBFTEY6IG5vdGU6IFBBRV9NT0RFID0gInllcyIN
CihYRU4pIFsgICAgNS4yMjkzNDZdIEVMRjogbm90ZTogTDFfTUZOX1ZBTElEDQooWEVOKSBbICAg
IDUuMjMzMzM2XSBFTEY6IG5vdGU6IE1PRF9TVEFSVF9QRk4gPSAweDENCihYRU4pIFsgICAgNS4y
Mzc5MjZdIEVMRjogbm90ZTogUEFERFJfT0ZGU0VUID0gMA0KKFhFTikgWyAgICA1LjI0MjI1OV0g
RUxGOiBub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MjAzNDAwMA0KKFhFTikgWyAg
ICA1LjI0ODIzOV0gRUxGOiBub3RlOiBTVVBQT1JURURfRkVBVFVSRVMgPSAweDg4MDENCihYRU4p
IFsgICAgNS4yNTM1MjVdIEVMRjogbm90ZTogTE9BREVSID0gImdlbmVyaWMiDQooWEVOKSBbICAg
IDUuMjU4MDMyXSBFTEY6IG5vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxDQooWEVOKSBbICAgIDUu
MjYyNzEyXSBFTEY6IEZvdW5kIFBWSCBpbWFnZQ0KKFhFTikgWyAgICA1LjI2NjQ0MV0gRUxGOiBh
ZGRyZXNzZXM6DQooWEVOKSBbICAgIDUuMjY5NzM0XSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4
MA0KKFhFTikgWyAgICA1LjI3Mzk4Ml0gICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDANCihYRU4p
IFsgICAgNS4yNzgyMjldICAgICB2aXJ0X29mZnNldCAgICAgID0gMHgwDQooWEVOKSBbICAgIDUu
MjgyNDczXSAgICAgdmlydF9rc3RhcnQgICAgICA9IDB4MTAwMDAwMA0KKFhFTikgWyAgICA1LjI4
NzIzOF0gICAgIHZpcnRfa2VuZCAgICAgICAgPSAweDNhMzAwMDANCihYRU4pIFsgICAgNS4yOTIw
MTBdICAgICB2aXJ0X2VudHJ5ICAgICAgID0gMHgxMDAwMDAwDQooWEVOKSBbICAgIDUuMjk2Nzcy
XSAgICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ODAwMDAwMDAwMA0KKFhFTikgWyAgICA1LjMwMTc5
OV0gRUxGOiBwaGRyIDAgYXQgMHgxMDAwMDAwIC0+IDB4MmIxYTAwYw0KKFhFTikgWyAgICA1LjMx
NDE5OF0gRUxGOiBwaGRyIDEgYXQgMHgyYzAwMDAwIC0+IDB4MzQ5MjAwMA0KKFhFTikgWyAgICA1
LjMyMTU3NV0gRUxGOiBwaGRyIDIgYXQgMHgzNDkyMDAwIC0+IDB4MzRjMWVkOA0KKFhFTikgWyAg
ICA1LjMyNjc3Nl0gRUxGOiBwaGRyIDMgYXQgMHgzNGMyMDAwIC0+IDB4Mzc4OTAwMA0KKFhFTikg
WyAgICA1LjM4OTU1M10gRG9tMCBtZW1vcnkgbWFwOg0KKFhFTikgWyAgICA1LjM5MjkyOF0gIFsw
MDAwMDAwMDAwMDAwMDAwLCAwMDAwMDAwMDAwMDlmZmZmXSAodXNhYmxlKQ0KKFhFTikgWyAgICA1
LjM5ODkxMl0gIFswMDAwMDAwMDAwMGEwMDAwLCAwMDAwMDAwMDAwMGZmZmZmXSAocmVzZXJ2ZWQp
DQooWEVOKSBbICAgIDUuNDA1MDY2XSAgWzAwMDAwMDAwMDAxMDAwMDAsIDAwMDAwMDAwMDliZmVm
ZmZdICh1c2FibGUpDQooWEVOKSBbICAgIDUuNDExMDQ3XSAgWzAwMDAwMDAwMDliZmYwMDAsIDAw
MDAwMDAwMDlmZmZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFsgICAgNS40MTcxOTVdICBbMDAwMDAw
MDAwYTAwMDAwMCwgMDAwMDAwMDAwYTFmZmZmZl0gKHVzYWJsZSkNCihYRU4pIFsgICAgNS40MjMx
NzVdICBbMDAwMDAwMDAwYTIwMDAwMCwgMDAwMDAwMDAwYTIwY2ZmZl0gKEFDUEkgTlZTKQ0KKFhF
TikgWyAgICA1LjQyOTMzMV0gIFswMDAwMDAwMDBhMjBkMDAwLCAwMDAwMDAwMGNhYmM4ZmZmXSAo
dXNhYmxlKQ0KKFhFTikgWyAgICA1LjQzNTMxMV0gIFswMDAwMDAwMGNhYmM5MDAwLCAwMDAwMDAw
MGNjMTRjZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbICAgIDUuNDQxNDY0XSAgWzAwMDAwMDAwY2Mx
NGQwMDAsIDAwMDAwMDAwY2MxOTVmZmZdIChBQ1BJIGRhdGEpDQooWEVOKSBbICAgIDUuNDQ3NzAy
XSAgWzAwMDAwMDAwY2MxOTYwMDAsIDAwMDAwMDAwY2MzODhmZmZdIChBQ1BJIE5WUykNCihYRU4p
IFsgICAgNS40NTM4NTddICBbMDAwMDAwMDBjYzM4OTAwMCwgMDAwMDAwMDBjYzM4OWZmZl0gKHJl
c2VydmVkKQ0KKFhFTikgWyAgICA1LjQ2MDAxMl0gIFswMDAwMDAwMGNjMzhhMDAwLCAwMDAwMDAw
MGNjNzA5ZmZmXSAoQUNQSSBOVlMpDQooWEVOKSBbICAgIDUuNDY2MTY0XSAgWzAwMDAwMDAwY2M3
MGEwMDAsIDAwMDAwMDAwY2QxZmVmZmZdIChyZXNlcnZlZCkNCihYRU4pIFsgICAgNS40NzIzMThd
ICBbMDAwMDAwMDBjZDFmZjAwMCwgMDAwMDAwMDBjZGZmZmVhN10gKHVzYWJsZSkNCihYRU4pIFsg
ICAgNS40NzgyOTZdICBbMDAwMDAwMDBjZGZmZmVhOCwgMDAwMDAwMDBjZGZmZmYzZl0gKEFDUEkg
ZGF0YSkNCihYRU4pIFsgICAgNS40ODQ1MzRdICBbMDAwMDAwMDBjZTAwMDAwMCwgMDAwMDAwMDBj
ZmZmZmZmZl0gKHJlc2VydmVkKQ0KKFhFTikgWyAgICA1LjQ5MDY5Ml0gIFswMDAwMDAwMGYwMDAw
MDAwLCAwMDAwMDAwMGY3ZmZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbICAgIDUuNDk2ODQ2XSAg
WzAwMDAwMDAwZmQwMDAwMDAsIDAwMDAwMDAwZmZmZmZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFsg
ICAgNS41MDI5OTddICBbMDAwMDAwMDEwMDAwMDAwMCwgMDAwMDAwMDEzNGFhM2ZmZl0gKHVzYWJs
ZSkNCihYRU4pIFsgICAgNS41MDg5ODBdICBbMDAwMDAwMDEzNGFhNDAwMCwgMDAwMDAwMDgwZjMz
ZmZmZl0gKHVudXNhYmxlKQ0KKFhFTikgWyAgICA1LjUxNTEyOF0gIFswMDAwMDAwODBmMzQwMDAw
LCAwMDAwMDAwODUwMWZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbICAgIDUuNTIxMjgxXSBJbml0
aWFsIGxvdyBtZW1vcnkgdmlycSB0aHJlc2hvbGQgc2V0IGF0IDB4NDAwMCBwYWdlcy4NCihYRU4p
IFsgICAgNS41Mjc5NTddIFNjcnViYmluZyBGcmVlIFJBTSBpbiBiYWNrZ3JvdW5kDQooWEVOKSBb
ICAgIDUuNTMyNzI2XSBTdGQuIExvZ2xldmVsOiBBbGwNCihYRU4pIFsgICAgNS41MzYyNzhdIEd1
ZXN0IExvZ2xldmVsOiBBbGwNCihYRU4pIFsgICAgNS41Mzk5MThdICoqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKFhFTikgWyAgICA1LjU0NjMyN10g
V0FSTklORzogQ09OU09MRSBPVVRQVVQgSVMgU1lOQ0hST05PVVMNCihYRU4pIFsgICAgNS41NTE2
MTVdIFRoaXMgb3B0aW9uIGlzIGludGVuZGVkIHRvIGFpZCBkZWJ1Z2dpbmcgb2YgWGVuIGJ5IGVu
c3VyaW5nDQooWEVOKSBbICAgIDUuNTU4NzI1XSB0aGF0IGFsbCBvdXRwdXQgaXMgc3luY2hyb25v
dXNseSBkZWxpdmVyZWQgb24gdGhlIHNlcmlhbCBsaW5lLg0KKFhFTikgWyAgICA1LjU2NjA4N10g
SG93ZXZlciBpdCBjYW4gaW50cm9kdWNlIFNJR05JRklDQU5UIGxhdGVuY2llcyBhbmQgYWZmZWN0
DQooWEVOKSBbICAgIDUuNTczMDI2XSB0aW1la2VlcGluZy4gSXQgaXMgTk9UIHJlY29tbWVuZGVk
IGZvciBwcm9kdWN0aW9uIHVzZSENCihYRU4pIFsgICAgNS41Nzk2OTVdICoqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKFhFTikgWyAgICA1LjU4NjI2
N10gMy4uLiAyLi4uIDEuLi4NCihYRU4pIFsgICAgOC41ODkyOTVdICoqKiBTZXJpYWwgaW5wdXQg
dG8gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQpDQooWEVO
KSBbICAgIDguNTk3NTI3XSBjb21tb24vc2NoZWQvbnVsbC5jOjM1NzogMCA8LS0gZDB2MA0KKFhF
TikgWyAgICA4LjYwMjc0N10gRnJlZWQgNjM2a0IgaW5pdCBtZW1vcnkNClsgICAgMC4wMDAwMDBd
IExpbnV4IHZlcnNpb24gNi4xMS4wIChyb290QGQzNDg0NTcxY2M2MikgKGdjYyAoQWxwaW5lIDEy
LjIuMV9naXQyMDIyMDkyNC1yMTApIDEyLjIuMSAyMDIyMDkyNCwgR05VIGxkIChHTlUgQmludXRp
bHMpIDIuNDApICMxIFNNUCBQUkVFTVBUX0RZTkFNSUMgTW9uIE1heSAxMiAxNjo1MDoyNiBVVEMg
MjAyNQ0KWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiBjb25zb2xlPWh2YzAgcm9vdD0vZGV2
L3JhbTAgZWFybHlwcmludGs9eGVuIGRlYnVnIHJkaW5pdD0vYmluL3NoDQpbICAgIDAuMDAwMDAw
XSBbRmlybXdhcmUgQnVnXTogVFNDIGRvZXNuJ3QgY291bnQgd2l0aCBQMCBmcmVxdWVuY3khDQpb
ICAgIDAuMDAwMDAwXSBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAw
MDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZmZm
Zl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMDAwMGEw
MDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgy
MDogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDA5YmZlZmZmXSB1c2FibGUNClsg
ICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwMDliZmYwMDAtMHgwMDAwMDAw
MDA5ZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAw
MDAwMDAwYTAwMDAwMC0weDAwMDAwMDAwMGExZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0g
QklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDAwYTIwMDAwMC0weDAwMDAwMDAwMGEyMGNmZmZdIEFD
UEkgTlZTDQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMDBhMjBkMDAw
LTB4MDAwMDAwMDBjYWJjOGZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFtt
ZW0gMHgwMDAwMDAwMGNhYmM5MDAwLTB4MDAwMDAwMDBjYzE0Y2ZmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwY2MxNGQwMDAtMHgwMDAwMDAwMGNj
MTk1ZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAw
MDAwY2MxOTYwMDAtMHgwMDAwMDAwMGNjMzg4ZmZmXSBBQ1BJIE5WUw0KWyAgICAwLjAwMDAwMF0g
QklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDBjYzM4OTAwMC0weDAwMDAwMDAwY2MzODlmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMGNjMzhhMDAw
LTB4MDAwMDAwMDBjYzcwOWZmZl0gQUNQSSBOVlMNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDog
W21lbSAweDAwMDAwMDAwY2M3MGEwMDAtMHgwMDAwMDAwMGNkMWZlZmZmXSByZXNlcnZlZA0KWyAg
ICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDBjZDFmZjAwMC0weDAwMDAwMDAw
Y2RmZmZlYTddIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAw
MDBjZGZmZmVhOC0weDAwMDAwMDAwY2RmZmZmM2ZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0g
QklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDBjZTAwMDAwMC0weDAwMDAwMDAwY2ZmZmZmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMGYwMDAwMDAw
LTB4MDAwMDAwMDBmN2ZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDog
W21lbSAweDAwMDAwMDAwZmQwMDAwMDAtMHgwMDAwMDAwMGZmZmZmZmZmXSByZXNlcnZlZA0KWyAg
ICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDEwMDAwMDAwMC0weDAwMDAwMDA4
MGYzM2ZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAw
MDgwZjM0MDAwMC0weDAwMDAwMDA4NTAxZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBw
cmludGs6IGxlZ2FjeSBib290Y29uc29sZSBbeGVuYm9vdDBdIGVuYWJsZWQNClsgICAgMC4wMDAw
MDBdIE5YIChFeGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQ0KWyAgICAwLjAwMDAw
MF0gQVBJQzogU3RhdGljIGNhbGxzIGluaXRpYWxpemVkDQpbICAgIDAuMDAwMDAwXSBlZmk6IEVG
SSB2Mi43IGJ5IEFtZXJpY2FuIE1lZ2F0cmVuZHMNClsgICAgMC4wMDAwMDBdIGVmaTogQUNQST0w
eGNjNmYzMDAwIEFDUEkgMi4wPTB4Y2M2ZjMwMTQgVFBNRmluYWxMb2c9MHhjYzZjMjAwMCBTTUJJ
T1M9MHhjY2ZkNjAwMCBTTUJJT1MgMy4wPTB4Y2NmZDUwMDAgKE1FTUFUVFI9MHhjNzIzNjUxOCB1
bnVzYWJsZSkgRVNSVD0weGNjMTViMDE4DQpbICAgIDAuMDAwMDAwXSBTTUJJT1MgMy4yLjAgcHJl
c2VudC4NClsgICAgMC4wMDAwMDBdIERNSTogIC83RDc4NSAvIDdENzg2LCBCSU9TIDUuMTYgMDIv
MjQvMjAyNQ0KWyAgICAwLjAwMDAwMF0gRE1JOiBNZW1vcnkgc2xvdHMgcG9wdWxhdGVkOiAyLzIN
ClsgICAgMC4wMDAwMDBdIEh5cGVydmlzb3IgZGV0ZWN0ZWQ6IFhlbiBIVk0NClsgICAgMC4wMDAw
MDBdIFhlbiB2ZXJzaW9uIDQuMjEuDQpbICAgIDAuMDAwMDA0XSBIVk1PUF9wYWdldGFibGVfZHlp
bmcgbm90IHN1cHBvcnRlZA0KWyAgICAwLjA1MTEwOF0gdHNjOiBGYXN0IFRTQyBjYWxpYnJhdGlv
biBmYWlsZWQNClsgICAgMC4wNTUyMDldIHRzYzogRGV0ZWN0ZWQgMjg5NC41NzIgTUh6IHByb2Nl
c3Nvcg0KWyAgICAwLjA1OTkzOV0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDAw
ZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkDQpbICAgIDAuMDY2NDc3XSBlODIwOiByZW1vdmUgW21l
bSAweDAwMGEwMDAwLTB4MDAwZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjA3MjAyOF0gbGFzdF9wZm4g
PSAweDgwZjM0MCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMA0KWyAgICAwLjA3NzUzMl0gTVRS
UiBtYXA6IDQgZW50cmllcyAoMyBmaXhlZCArIDEgdmFyaWFibGU7IG1heCAyMCksIGJ1aWx0IGZy
b20gOSB2YXJpYWJsZSBNVFJScw0KWyAgICAwLjA4NTgwNl0geDg2L1BBVDogQ29uZmlndXJhdGlv
biBbMC03XTogV0IgIFdDICBVQy0gVUMgIFdCICBXUCAgVUMtIFdUDQpbICAgIDAuMDkzMjk1XSBD
UFUgTVRSUnMgYWxsIGJsYW5rIC0gdmlydHVhbGl6ZWQgc3lzdGVtLg0KWyAgICAwLjA5ODE4NF0g
bGFzdF9wZm4gPSAweGNkZmZmIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMTA3
MjMzXSBlc3J0OiBSZXNlcnZpbmcgRVNSVCBzcGFjZSBmcm9tIDB4MDAwMDAwMDBjYzE1YjAxOCB0
byAweDAwMDAwMDAwY2MxNWIwNTAuDQpbICAgIDAuMTE0ODkxXSBVc2luZyBHQiBwYWdlcyBmb3Ig
ZGlyZWN0IG1hcHBpbmcNClsgICAgMC4xMjAwNDVdIFNlY3VyZSBib290IGRpc2FibGVkDQpbICAg
IDAuMTIzMTAxXSBSQU1ESVNLOiBbbWVtIDB4MGEyMGQwMDAtMHgxNmQwM2ZmZl0NClsgICAgMC4x
MjgyMzNdIEFDUEk6IEVhcmx5IHRhYmxlIGNoZWNrc3VtIHZlcmlmaWNhdGlvbiBkaXNhYmxlZA0K
WyAgICAwLjEzMzcyNV0gQUNQSTogUlNEUCAweDAwMDAwMDAwQ0RGRkZFQTggMDAwMDI0ICh2MDIg
QUxBU0tBKQ0KWyAgICAwLjEzOTQ0M10gQUNQSTogWFNEVCAweDAwMDAwMDAwQ0RGRkZFQ0MgMDAw
MDlDICh2MDEgQUxBU0tBIEEgTSBJICAgIDAxMDcyMDA5IEFNSSAgMDEwMDAwMTMpDQpbICAgIDAu
MTQ3OTM3XSBBQ1BJOiBBUElDIDB4MDAwMDAwMDBDREZGRkY2OCAwMDAwOTggKHYwMyBBTEFTS0Eg
QSBNIEkgICAgMDEwNzIwMDkgQU1JICAwMDAxMDAxMykNClsgICAgMC4xNTY0MjddIEFDUEk6IEZB
Q1AgMHgwMDAwMDAwMENDMThDMDAwIDAwMDExNCAodjA2IEFMQVNLQSBBIE0gSSAgICAwMTA3MjAw
OSBBTUkgIDAwMDEwMDEzKQ0KWyAgICAwLjE2NDk1OV0gQUNQSTogRFNEVCAweDAwMDAwMDAwQ0Mx
ODMwMDAgMDA4NzZEICh2MDIgQUxBU0tBIEEgTSBJICAgIDAxMDcyMDA5IElOVEwgMjAxMjA5MTMp
DQpbICAgIDAuMTczNDEzXSBBQ1BJOiBGQUNTIDB4MDAwMDAwMDBDQzZDMDAwMCAwMDAwNDANClsg
ICAgMC4xNzgwMTJdIEFDUEk6IFNTRFQgMHgwMDAwMDAwMENDMThFMDAwIDAwNzIzQyAodjAyIEFN
RCAgICBBbWRUYWJsZSAwMDAwMDAwMiBNU0ZUIDA0MDAwMDAwKQ0KWyAgICAwLjE4NjUwM10gQUNQ
STogTUNGRyAweDAwMDAwMDAwQ0MxODEwMDAgMDAwMDNDICh2MDEgQUxBU0tBIEEgTSBJICAgIDAx
MDcyMDA5IE1TRlQgMDAwMTAwMTMpDQpbICAgIDAuMTk0OTk4XSBBQ1BJOiBTU0RUIDB4MDAwMDAw
MDBDQzE3RjAwMCAwMDAyMjggKHYwMSBBTUQgICAgU1REMyAgICAgMDAwMDAwMDEgSU5UTCAyMDEy
MDkxMykNClsgICAgMC4yMDM0ODldIEFDUEk6IFZGQ1QgMHgwMDAwMDAwMENDMTcxMDAwIDAwRDY4
NCAodjAxIEFMQVNLQSBBIE0gSSAgICAwMDAwMDAwMSBBTUQgIDMxNTA0RjQ3KQ0KWyAgICAwLjIx
MTk4MF0gQUNQSTogU1NEVCAweDAwMDAwMDAwQ0MxNkMwMDAgMDAzOUY0ICh2MDEgQU1EICAgIEFt
ZFRhYmxlIDAwMDAwMDAxIEFNRCAgMDAwMDAwMDEpDQpbICAgIDAuMjIwNDc1XSBBQ1BJOiBTU0RU
IDB4MDAwMDAwMDBDQzE2OTAwMCAwMDAxMzkgKHYwMSBBTUQgICAgQW1kVGFibGUgMDAwMDAwMDEg
SU5UTCAyMDEyMDkxMykNClsgICAgMC4yMjg5NzJdIEFDUEk6IFNTRFQgMHgwMDAwMDAwMENDMTY4
MDAwIDAwMDIyNyAodjAxIEFNRCAgICBBbWRUYWJsZSAwMDAwMDAwMSBJTlRMIDIwMTIwOTEzKQ0K
WyAgICAwLjIzNzQ2M10gQUNQSTogU1NEVCAweDAwMDAwMDAwQ0MxNjcwMDAgMDAwRDM3ICh2MDEg
QU1EICAgIEFtZFRhYmxlIDAwMDAwMDAxIElOVEwgMjAxMjA5MTMpDQpbICAgIDAuMjQ1OTU2XSBB
Q1BJOiBTU0RUIDB4MDAwMDAwMDBDQzE2NTAwMCAwMDEwQTUgKHYwMSBBTUQgICAgQW1kVGFibGUg
MDAwMDAwMDEgSU5UTCAyMDEyMDkxMykNClsgICAgMC4yNTQ0NTBdIEFDUEk6IFNTRFQgMHgwMDAw
MDAwMENDMTYxMDAwIDAwMzBDOCAodjAxIEFNRCAgICBBbWRUYWJsZSAwMDAwMDAwMSBJTlRMIDIw
MTIwOTEzKQ0KWyAgICAwLjI2Mjk0MV0gQUNQSTogU1NEVCAweDAwMDAwMDAwQ0MxNUUwMDAgMDAw
MDdEICh2MDEgQU1EICAgIEFtZFRhYmxlIDAwMDAwMDAxIElOVEwgMjAxMjA5MTMpDQpbICAgIDAu
MjcxNDMzXSBBQ1BJOiBTU0RUIDB4MDAwMDAwMDBDQzE1RDAwMCAwMDA1MTcgKHYwMSBBTUQgICAg
QW1kVGFibGUgMDAwMDAwMDEgSU5UTCAyMDEyMDkxMykNClsgICAgMC4yNzk5MjddIEFDUEk6IEZQ
RFQgMHgwMDAwMDAwMENDMTVDMDAwIDAwMDA0NCAodjAxIEFMQVNLQSBBIE0gSSAgICAwMTA3MjAw
OSBBTUkgIDAxMDAwMDEzKQ0KWyAgICAwLjI4ODQxN10gQUNQSTogUmVzZXJ2aW5nIEFQSUMgdGFi
bGUgbWVtb3J5IGF0IFttZW0gMHhjZGZmZmY2OC0weGNkZmZmZmZmXQ0KWyAgICAwLjI5NTQ0MF0g
QUNQSTogUmVzZXJ2aW5nIEZBQ1AgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE4YzAwMC0weGNj
MThjMTEzXQ0KWyAgICAwLjMwMjQ2Ml0gQUNQSTogUmVzZXJ2aW5nIERTRFQgdGFibGUgbWVtb3J5
IGF0IFttZW0gMHhjYzE4MzAwMC0weGNjMThiNzZjXQ0KWyAgICAwLjMwOTQ3OV0gQUNQSTogUmVz
ZXJ2aW5nIEZBQ1MgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzZjMDAwMC0weGNjNmMwMDNmXQ0K
WyAgICAwLjMxNjUwMF0gQUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0g
MHhjYzE4ZTAwMC0weGNjMTk1MjNiXQ0KWyAgICAwLjMyMzUyMF0gQUNQSTogUmVzZXJ2aW5nIE1D
RkcgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE4MTAwMC0weGNjMTgxMDNiXQ0KWyAgICAwLjMz
MDU0MF0gQUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE3ZjAw
MC0weGNjMTdmMjI3XQ0KWyAgICAwLjMzNzU2Ml0gQUNQSTogUmVzZXJ2aW5nIFZGQ1QgdGFibGUg
bWVtb3J5IGF0IFttZW0gMHhjYzE3MTAwMC0weGNjMTdlNjgzXQ0KWyAgICAwLjM0NDU4MV0gQUNQ
STogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE2YzAwMC0weGNjMTZm
OWYzXQ0KWyAgICAwLjM1MTYwMF0gQUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0
IFttZW0gMHhjYzE2OTAwMC0weGNjMTY5MTM4XQ0KWyAgICAwLjM1ODYyMl0gQUNQSTogUmVzZXJ2
aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE2ODAwMC0weGNjMTY4MjI2XQ0KWyAg
ICAwLjM2NTYzOV0gQUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhj
YzE2NzAwMC0weGNjMTY3ZDM2XQ0KWyAgICAwLjM3MjY2Ml0gQUNQSTogUmVzZXJ2aW5nIFNTRFQg
dGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE2NTAwMC0weGNjMTY2MGE0XQ0KWyAgICAwLjM3OTY3
N10gQUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE2MTAwMC0w
eGNjMTY0MGM3XQ0KWyAgICAwLjM4NjY5Nl0gQUNQSTogUmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVt
b3J5IGF0IFttZW0gMHhjYzE1ZTAwMC0weGNjMTVlMDdjXQ0KWyAgICAwLjM5MzcxNl0gQUNQSTog
UmVzZXJ2aW5nIFNTRFQgdGFibGUgbWVtb3J5IGF0IFttZW0gMHhjYzE1ZDAwMC0weGNjMTVkNTE2
XQ0KWyAgICAwLjQwMDc0MV0gQUNQSTogUmVzZXJ2aW5nIEZQRFQgdGFibGUgbWVtb3J5IGF0IFtt
ZW0gMHhjYzE1YzAwMC0weGNjMTVjMDQzXQ0KWyAgICAwLjQwNzg2N10gTm8gTlVNQSBjb25maWd1
cmF0aW9uIGZvdW5kDQpbICAgIDAuNDExNTczXSBGYWtpbmcgYSBub2RlIGF0IFttZW0gMHgwMDAw
MDAwMDAwMDAwMDAwLTB4MDAwMDAwMDgwZjMzZmZmZl0NClsgICAgMC40MTgyNDddIE5PREVfREFU
QSgwKSBhbGxvY2F0ZWQgW21lbSAweDEzNGE5ZjAwMC0weDEzNGFhMmZmZl0NClsgICAgMC40MjQy
NTldIFpvbmUgcmFuZ2VzOg0KWyAgICAwLjQyNjczNl0gICBETUEgICAgICBbbWVtIDB4MDAwMDAw
MDAwMDAwMTAwMC0weDAwMDAwMDAwMDBmZmZmZmZdDQpbICAgIDAuNDMyODkzXSAgIERNQTMyICAg
IFttZW0gMHgwMDAwMDAwMDAxMDAwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0NClsgICAgMC40Mzkw
NDVdICAgTm9ybWFsICAgW21lbSAweDAwMDAwMDAxMDAwMDAwMDAtMHgwMDAwMDAwODBmMzNmZmZm
XQ0KWyAgICAwLjQ0NTE5Nl0gTW92YWJsZSB6b25lIHN0YXJ0IGZvciBlYWNoIG5vZGUNClsgICAg
MC40NDk0NDVdIEVhcmx5IG1lbW9yeSBub2RlIHJhbmdlcw0KWyAgICAwLjQ1Mjk5Nl0gICBub2Rl
ICAgMDogW21lbSAweDAwMDAwMDAwMDAwMDEwMDAtMHgwMDAwMDAwMDAwMDlmZmZmXQ0KWyAgICAw
LjQ1OTI0MV0gICBub2RlICAgMDogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDA5
YmZlZmZmXQ0KWyAgICAwLjQ2NTQ3OV0gICBub2RlICAgMDogW21lbSAweDAwMDAwMDAwMGEwMDAw
MDAtMHgwMDAwMDAwMDBhMWZmZmZmXQ0KWyAgICAwLjQ3MTcxOV0gICBub2RlICAgMDogW21lbSAw
eDAwMDAwMDAwMGEyMGQwMDAtMHgwMDAwMDAwMGNhYmM4ZmZmXQ0KWyAgICAwLjQ3Nzk1OV0gICBu
b2RlICAgMDogW21lbSAweDAwMDAwMDAwY2QxZmYwMDAtMHgwMDAwMDAwMGNkZmZlZmZmXQ0KWyAg
ICAwLjQ4NDE5OF0gICBub2RlICAgMDogW21lbSAweDAwMDAwMDAxMDAwMDAwMDAtMHgwMDAwMDAw
ODBmMzNmZmZmXQ0KWyAgICAwLjQ5MDQ0MV0gSW5pdG1lbSBzZXR1cCBub2RlIDAgW21lbSAweDAw
MDAwMDAwMDAwMDEwMDAtMHgwMDAwMDAwODBmMzNmZmZmXQ0KWyAgICAwLjQ5NzQ2NV0gT24gbm9k
ZSAwLCB6b25lIERNQTogMSBwYWdlcyBpbiB1bmF2YWlsYWJsZSByYW5nZXMNClsgICAgMC41MDMy
ODNdIE9uIG5vZGUgMCwgem9uZSBETUE6IDk2IHBhZ2VzIGluIHVuYXZhaWxhYmxlIHJhbmdlcw0K
WyAgICAwLjUwOTI4MV0gT24gbm9kZSAwLCB6b25lIERNQTMyOiAxMDI1IHBhZ2VzIGluIHVuYXZh
aWxhYmxlIHJhbmdlcw0KWyAgICAwLjUxOTkzM10gT24gbm9kZSAwLCB6b25lIERNQTMyOiAxMyBw
YWdlcyBpbiB1bmF2YWlsYWJsZSByYW5nZXMNClsgICAgMC41MjU5NzJdIE9uIG5vZGUgMCwgem9u
ZSBETUEzMjogOTc4MiBwYWdlcyBpbiB1bmF2YWlsYWJsZSByYW5nZXMNClsgICAgMC41NzUzMzld
IE9uIG5vZGUgMCwgem9uZSBOb3JtYWw6IDgxOTMgcGFnZXMgaW4gdW5hdmFpbGFibGUgcmFuZ2Vz
DQpbICAgIDAuNTgxNTYwXSBPbiBub2RlIDAsIHpvbmUgTm9ybWFsOiAzMjY0IHBhZ2VzIGluIHVu
YXZhaWxhYmxlIHJhbmdlcw0KWyAgICAwLjU4ODI5OV0gQUNQSTogUE0tVGltZXIgSU8gUG9ydDog
MHg4MDgNClsgICAgMC41OTIxOTRdIElPQVBJQ1swXTogYXBpY19pZCAxNywgdmVyc2lvbiAxNywg
YWRkcmVzcyAweGZlYzAwMDAwLCBHU0kgMC0yMw0KWyAgICAwLjU5OTEwN10gSU9BUElDWzFdOiBh
cGljX2lkIDE4LCB2ZXJzaW9uIDE3LCBhZGRyZXNzIDB4ZmVjMDEwMDAsIEdTSSAyNC01NQ0KWyAg
ICAwLjYwNjA4OV0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJx
IDIgZGZsIGRmbCkNClsgICAgMC42MTI0MTddIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNf
aXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZlbCkNClsgICAgMC42MTg5MTldIEFDUEk6IFVzaW5n
IEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KWyAgICAwLjYy
NTMzNF0gQ1BVIHRvcG86IE1heC4gbG9naWNhbCBwYWNrYWdlczogICAxDQpbICAgIDAuNjI5OTIx
XSBDUFUgdG9wbzogTWF4LiBsb2dpY2FsIGRpZXM6ICAgICAgIDENClsgICAgMC42MzQ1MThdIENQ
VSB0b3BvOiBNYXguIGRpZXMgcGVyIHBhY2thZ2U6ICAgMQ0KWyAgICAwLjYzOTExNV0gQ1BVIHRv
cG86IE1heC4gdGhyZWFkcyBwZXIgY29yZTogICAxDQpbICAgIDAuNjQzNzA1XSBDUFUgdG9wbzog
TnVtLiBjb3JlcyBwZXIgcGFja2FnZTogICAgIDQNClsgICAgMC42NDg1NTldIENQVSB0b3BvOiBO
dW0uIHRocmVhZHMgcGVyIHBhY2thZ2U6ICAgNA0KWyAgICAwLjY1MzQxM10gQ1BVIHRvcG86IEFs
bG93aW5nIDQgcHJlc2VudCBDUFVzIHBsdXMgMCBob3RwbHVnIENQVXMNClsgICAgMC42NTk0ODld
IFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4MDAwMDAw
MDAtMHgwMDAwMGZmZl0NClsgICAgMC42NjcwMThdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJl
ZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4MDAwYTAwMDAtMHgwMDBmZmZmZl0NClsgICAgMC42NzQ1
NThdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4MDli
ZmYwMDAtMHgwOWZmZmZmZl0NClsgICAgMC42ODIwOTVdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0
ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4MGEyMDAwMDAtMHgwYTIwY2ZmZl0NClsgICAgMC42
ODk2MzRdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4
Y2FiYzkwMDAtMHhjYzE0Y2ZmZl0NClsgICAgMC42OTcxNzRdIFBNOiBoaWJlcm5hdGlvbjogUmVn
aXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4Y2MxNGQwMDAtMHhjYzE5NWZmZl0NClsgICAg
MC43MDQ3MTldIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVt
IDB4Y2MxOTYwMDAtMHhjYzM4OGZmZl0NClsgICAgMC43MTIyNTddIFBNOiBoaWJlcm5hdGlvbjog
UmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4Y2MzODkwMDAtMHhjYzM4OWZmZl0NClsg
ICAgMC43MTk3OTldIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBb
bWVtIDB4Y2MzOGEwMDAtMHhjYzcwOWZmZl0NClsgICAgMC43MjczMzRdIFBNOiBoaWJlcm5hdGlv
bjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4Y2M3MGEwMDAtMHhjZDFmZWZmZl0N
ClsgICAgMC43MzQ4ODBdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5
OiBbbWVtIDB4Y2RmZmYwMDAtMHhjZGZmZmZmZl0NClsgICAgMC43NDI0MTldIFBNOiBoaWJlcm5h
dGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4Y2RmZmYwMDAtMHhjZGZmZmZm
Zl0NClsgICAgMC43NDk5NTRdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVt
b3J5OiBbbWVtIDB4Y2UwMDAwMDAtMHhjZmZmZmZmZl0NClsgICAgMC43NTc0OTldIFBNOiBoaWJl
cm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZDAwMDAwMDAtMHhlZmZm
ZmZmZl0NClsgICAgMC43NjUwMzRdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUg
bWVtb3J5OiBbbWVtIDB4ZjAwMDAwMDAtMHhmN2ZmZmZmZl0NClsgICAgMC43NzI4NzVdIFBNOiBo
aWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiBbbWVtIDB4ZjgwMDAwMDAtMHhm
Y2ZmZmZmZl0NClsgICAgMC43ODAyNjZdIFBNOiBoaWJlcm5hdGlvbjogUmVnaXN0ZXJlZCBub3Nh
dmUgbWVtb3J5OiBbbWVtIDB4ZmQwMDAwMDAtMHhmZmZmZmZmZl0NClsgICAgMC43ODc4MDhdIFtt
ZW0gMHhkMDAwMDAwMC0weGVmZmZmZmZmXSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2VzDQpbICAg
IDAuNzkzODc5XSBCb290aW5nIGtlcm5lbCBvbiBYZW4gUFZIDQpbICAgIDAuNzk3NTE1XSBYZW4g
dmVyc2lvbjogNC4yMS11bnN0YWJsZQ0KWyAgICAwLjgwMTI0MV0gY2xvY2tzb3VyY2U6IHJlZmlu
ZWQtamlmZmllczogbWFzazogMHhmZmZmZmZmZiBtYXhfY3ljbGVzOiAweGZmZmZmZmZmLCBtYXhf
aWRsZV9uczogMTkxMDk2OTk0MDM5MTQxOSBucw0KWyAgICAwLjgxNjQ1OF0gc2V0dXBfcGVyY3B1
OiBOUl9DUFVTOjY0IG5yX2NwdW1hc2tfYml0czo0IG5yX2NwdV9pZHM6NCBucl9ub2RlX2lkczox
DQpbICAgIDAuODIzOTkzXSBwZXJjcHU6IEVtYmVkZGVkIDU3IHBhZ2VzL2NwdSBzMTk2MzEyIHI4
MTkyIGQyODk2OCB1NTI0Mjg4DQpbICAgIDAuODMwMzUxXSBwY3B1LWFsbG9jOiBzMTk2MzEyIHI4
MTkyIGQyODk2OCB1NTI0Mjg4IGFsbG9jPTEqMjA5NzE1Mg0KWyAgICAwLjgzNjY3NF0gcGNwdS1h
bGxvYzogWzBdIDAgMSAyIDMNClsgICAgMC44NDAyNTBdIEtlcm5lbCBjb21tYW5kIGxpbmU6IGNv
bnNvbGU9aHZjMCByb290PS9kZXYvcmFtMCBlYXJseXByaW50az14ZW4gZGVidWcgcmRpbml0PS9i
aW4vc2gNClsgICAgMC44NDkxMTddIHJhbmRvbTogY3JuZyBpbml0IGRvbmUNClsgICAgMC44NTI3
NjhdIERlbnRyeSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUyNDI4OCAob3JkZXI6IDEwLCA0
MTk0MzA0IGJ5dGVzLCBsaW5lYXIpDQpbICAgIDAuODYwNzAxXSBJbm9kZS1jYWNoZSBoYXNoIHRh
YmxlIGVudHJpZXM6IDI2MjE0NCAob3JkZXI6IDksIDIwOTcxNTIgYnl0ZXMsIGxpbmVhcikNClsg
ICAgMC44NjgzMDBdIEZhbGxiYWNrIG9yZGVyIGZvciBOb2RlIDA6IDANClsgICAgMC44NjgzMDNd
IEJ1aWx0IDEgem9uZWxpc3RzLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiA4
MjM1MTYyDQpbICAgIDAuODc5MTA1XSBQb2xpY3kgem9uZTogTm9ybWFsDQpbICAgIDAuODgyMjI0
XSBtZW0gYXV0by1pbml0OiBzdGFjazphbGwoemVybyksIGhlYXAgYWxsb2M6b2ZmLCBoZWFwIGZy
ZWU6b2ZmDQpbICAgIDAuODg4OTg5XSBzb2Z0d2FyZSBJTyBUTEI6IGFyZWEgbnVtIDQuDQpbICAg
IDAuOTc5MDkyXSBTTFVCOiBIV2FsaWduPTY0LCBPcmRlcj0wLTMsIE1pbk9iamVjdHM9MCwgQ1BV
cz00LCBOb2Rlcz0xDQpQb2tpbmcgS0FTTFIgdXNpbmcgUkRSQU5EIFJEVFNDLi4uDQpbICAgIDAu
OTg5NjI1XSBEeW5hbWljIFByZWVtcHQ6IHZvbHVudGFyeQ0KWyAgICAwLjk5MzIyNl0gcmN1OiBQ
cmVlbXB0aWJsZSBoaWVyYXJjaGljYWwgUkNVIGltcGxlbWVudGF0aW9uLg0KWyAgICAwLjk5ODky
Nl0gcmN1OiAJUkNVIGV2ZW50IHRyYWNpbmcgaXMgZW5hYmxlZC4NClsgICAgMS4wMDM0MzBdIHJj
dTogCVJDVSByZXN0cmljdGluZyBDUFVzIGZyb20gTlJfQ1BVUz02NCB0byBucl9jcHVfaWRzPTQu
DQpbICAgIDEuMDEwMDE0XSAJVHJhbXBvbGluZSB2YXJpYW50IG9mIFRhc2tzIFJDVSBlbmFibGVk
Lg0KWyAgICAxLjAxNTA0NF0gcmN1OiBSQ1UgY2FsY3VsYXRlZCB2YWx1ZSBvZiBzY2hlZHVsZXIt
ZW5saXN0bWVudCBkZWxheSBpcyAxMDAgamlmZmllcy4NClsgICAgMS4wMjI2NjddIHJjdTogQWRq
dXN0aW5nIGdlb21ldHJ5IGZvciByY3VfZmFub3V0X2xlYWY9MTYsIG5yX2NwdV9pZHM9NA0KWyAg
ICAxLjAyOTM0NV0gUkNVIFRhc2tzOiBTZXR0aW5nIHNoaWZ0IHRvIDIgYW5kIGxpbSB0byAxIHJj
dV90YXNrX2NiX2FkanVzdD0xLg0KWyAgICAxLjAzNzUyNl0gVXNpbmcgTlVMTCBsZWdhY3kgUElD
DQpbICAgIDEuMDQwNjcwXSBOUl9JUlFTOiA0MzUyLCBucl9pcnFzOiAxMDAwLCBwcmVhbGxvY2F0
ZWQgaXJxczogMA0KWyAgICAxLjA0NjQ5N10geGVuOmV2ZW50czogVXNpbmcgRklGTy1iYXNlZCBB
QkkNCihYRU4pIFsgICAgOS44ODk2NzJdIGQwdjA6IHVwY2FsbCB2ZWN0b3IgZjMNClsgICAgMS4w
NTQ2MzFdIHhlbjpldmVudHM6IFhlbiBIVk0gY2FsbGJhY2sgdmVjdG9yIGZvciBldmVudCBkZWxp
dmVyeSBpcyBlbmFibGVkDQpbICAgIDEuMDYxNzU5XSByY3U6IHNyY3VfaW5pdDogU2V0dGluZyBz
cmN1X3N0cnVjdCBzaXplcyBiYXNlZCBvbiBjb250ZW50aW9uLg0KWyAgICAxLjA2ODk1MF0gQ29u
c29sZTogY29sb3VyIGR1bW15IGRldmljZSA4MHgyNQ0KWyAgICAxLjA3MzIyNV0gcHJpbnRrOiBs
ZWdhY3kgY29uc29sZSBbdHR5MF0gZW5hYmxlZA0KWyAgICAxLjA3ODE1NF0gcHJpbnRrOiBsZWdh
Y3kgY29uc29sZSBbaHZjMF0gZW5hYmxlZA0KDQpbICAgIDEuMDc4MTU0XSBwcmludGs6IGxlZ2Fj
eSBjb25zb2xlIFtodmMwXSBlbmFibGVkDQpbICAgIDEuMDg3NDUxXSBwcmludGs6IGxlZ2FjeSBi
b290Y29uc29sZSBbeGVuYm9vdDBdIGRpc2FibGVkDQoNClsgICAgMS4wODc0NTFdIHByaW50azog
bGVnYWN5IGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZGlzYWJsZWQNClsgICAgMS4wOTg0NjddIEFD
UEk6IENvcmUgcmV2aXNpb24gMjAyNDAzMjINCg0KWyAgICAxLjEyMTExNF0gRmFpbGVkIHRvIHJl
Z2lzdGVyIGxlZ2FjeSB0aW1lciBpbnRlcnJ1cHQNCg0KWyAgICAxLjEyNjA4MV0gQVBJQzogU3dp
dGNoIHRvIHN5bW1ldHJpYyBJL08gbW9kZSBzZXR1cA0KDQpbICAgIDEuMTMxODk0XSB4MmFwaWMg
ZW5hYmxlZA0KDQpbICAgIDEuMTM1NDQwXSBBUElDOiBTd2l0Y2hlZCBBUElDIHJvdXRpbmcgdG86
IHBoeXNpY2FsIHgyYXBpYw0KDQpbICAgIDEuMTQxMDE3XSBjbG9ja3NvdXJjZTogdHNjLWVhcmx5
OiBtYXNrOiAweGZmZmZmZmZmZmZmZmZmZmYgbWF4X2N5Y2xlczogMHgyOWI5M2I0YmIyMSwgbWF4
X2lkbGVfbnM6IDQ0MDc5NTI4ODM0NiBucw0KDQpbICAgIDEuMTUxNTAzXSBDYWxpYnJhdGluZyBk
ZWxheSBsb29wIChza2lwcGVkKSwgdmFsdWUgY2FsY3VsYXRlZCB1c2luZyB0aW1lciBmcmVxdWVu
Y3kuLiA1Nzg5LjE0IEJvZ29NSVBTIChscGo9Mjg5NDU3MikNCg0KWyAgICAxLjE1MjUwMV0geDg2
L2NwdTogVXNlciBNb2RlIEluc3RydWN0aW9uIFByZXZlbnRpb24gKFVNSVApIGFjdGl2YXRlZA0K
DQpbICAgIDEuMTUyNTAxXSBMYXN0IGxldmVsIGlUTEIgZW50cmllczogNEtCIDEwMjQsIDJNQiAx
MDI0LCA0TUIgNTEyDQoNClsgICAgMS4xNTI1MDFdIExhc3QgbGV2ZWwgZFRMQiBlbnRyaWVzOiA0
S0IgMjA0OCwgMk1CIDIwNDgsIDRNQiAxMDI0LCAxR0IgMA0KDQpbICAgIDEuMTUyNTAxXSBTcGVj
dHJlIFYxIDogTWl0aWdhdGlvbjogdXNlcmNvcHkvc3dhcGdzIGJhcnJpZXJzIGFuZCBfX3VzZXIg
cG9pbnRlciBzYW5pdGl6YXRpb24NCg0KWyAgICAxLjE1MjUwMV0gU3BlY3RyZSBWMiA6IE1pdGln
YXRpb246IFJldHBvbGluZXMNCg0KWyAgICAxLjE1MjUwMV0gU3BlY3RyZSBWMiA6IFNwZWN0cmUg
djIgLyBTcGVjdHJlUlNCIG1pdGlnYXRpb246IEZpbGxpbmcgUlNCIG9uIGNvbnRleHQgc3dpdGNo
DQoNClsgICAgMS4xNTI1MDFdIFNwZWN0cmUgVjIgOiBTcGVjdHJlIHYyIC8gU3BlY3RyZVJTQiA6
IEZpbGxpbmcgUlNCIG9uIFZNRVhJVA0KDQpbICAgIDEuMTUyNTAxXSBTcGVjdHJlIFYyIDogRW5h
YmxpbmcgU3BlY3VsYXRpb24gQmFycmllciBmb3IgZmlybXdhcmUgY2FsbHMNCg0KWyAgICAxLjE1
MjUwMV0gUkVUQmxlZWQ6IE1pdGlnYXRpb246IHVudHJhaW5lZCByZXR1cm4gdGh1bmsNCg0KWyAg
ICAxLjE1MjUwMV0gU3BlY3RyZSBWMiA6IG1pdGlnYXRpb246IEVuYWJsaW5nIGNvbmRpdGlvbmFs
IEluZGlyZWN0IEJyYW5jaCBQcmVkaWN0aW9uIEJhcnJpZXINCg0KWyAgICAxLjE1MjUwMV0gU3Bl
Y3VsYXRpdmUgU3RvcmUgQnlwYXNzOiBNaXRpZ2F0aW9uOiBTcGVjdWxhdGl2ZSBTdG9yZSBCeXBh
c3MgZGlzYWJsZWQgdmlhIHByY3RsDQoNClsgICAgMS4xNTI1MDFdIHg4Ni9mcHU6IFN1cHBvcnRp
bmcgWFNBVkUgZmVhdHVyZSAweDAwMTogJ3g4NyBmbG9hdGluZyBwb2ludCByZWdpc3RlcnMnDQoN
ClsgICAgMS4xNTI1MDFdIHg4Ni9mcHU6IFN1cHBvcnRpbmcgWFNBVkUgZmVhdHVyZSAweDAwMjog
J1NTRSByZWdpc3RlcnMnDQoNClsgICAgMS4xNTI1MDFdIHg4Ni9mcHU6IFN1cHBvcnRpbmcgWFNB
VkUgZmVhdHVyZSAweDAwNDogJ0FWWCByZWdpc3RlcnMnDQoNClsgICAgMS4xNTI1MDFdIHg4Ni9m
cHU6IHhzdGF0ZV9vZmZzZXRbMl06ICA1NzYsIHhzdGF0ZV9zaXplc1syXTogIDI1Ng0KDQpbICAg
IDEuMTUyNTAxXSB4ODYvZnB1OiBFbmFibGVkIHhzdGF0ZSBmZWF0dXJlcyAweDcsIGNvbnRleHQg
c2l6ZSBpcyA4MzIgYnl0ZXMsIHVzaW5nICdjb21wYWN0ZWQnIGZvcm1hdC4NCg0KWyAgICAxLjE1
MjUwMV0gRnJlZWluZyBTTVAgYWx0ZXJuYXRpdmVzIG1lbW9yeTogNTJLDQoNClsgICAgMS4xNTI1
MDFdIHBpZF9tYXg6IGRlZmF1bHQ6IDMyNzY4IG1pbmltdW06IDMwMQ0KDQpbICAgIDEuMTUyNTAx
XSBMU006IGluaXRpYWxpemluZyBsc209Y2FwYWJpbGl0eSxzZWxpbnV4DQoNClsgICAgMS4xNTI1
MDFdIFNFTGludXg6ICBJbml0aWFsaXppbmcuDQoNClsgICAgMS4xNTI1MDFdIE1vdW50LWNhY2hl
IGhhc2ggdGFibGUgZW50cmllczogODE5MiAob3JkZXI6IDQsIDY1NTM2IGJ5dGVzLCBsaW5lYXIp
DQoNClsgICAgMS4xNTI1MDFdIE1vdW50cG9pbnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA4
MTkyIChvcmRlcjogNCwgNjU1MzYgYnl0ZXMsIGxpbmVhcikNCg0KWyAgICAxLjE1MjUwMV0gY2xv
Y2tzb3VyY2U6IHhlbjogbWFzazogMHhmZmZmZmZmZmZmZmZmZmZmIG1heF9jeWNsZXM6IDB4MWNk
NDJlNGRmZmIsIG1heF9pZGxlX25zOiA4ODE1OTA1OTE0ODMgbnMNCg0KWyAgICAxLjE1MjUwMV0g
WGVuOiB1c2luZyB2Y3B1b3AgdGltZXIgaW50ZXJmYWNlDQoNClsgICAgMS4xNTI1MDFdIGluc3Rh
bGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMA0KDQpbICAgIDEuMTUyNTAxXSBzbXBib290OiBDUFUw
OiBBTUQgUnl6ZW4gRW1iZWRkZWQgVjI3NDggd2l0aCBSYWRlb24gR3JhcGhpY3MgKGZhbWlseTog
MHgxNywgbW9kZWw6IDB4NjAsIHN0ZXBwaW5nOiAweDEpDQoNClsgICAgMS4xNTI2MTldIFBlcmZv
cm1hbmNlIEV2ZW50czogUE1VIG5vdCBhdmFpbGFibGUgZHVlIHRvIHZpcnR1YWxpemF0aW9uLCB1
c2luZyBzb2Z0d2FyZSBldmVudHMgb25seS4NCg0KWyAgICAxLjE1MzUyMl0gc2lnbmFsOiBtYXgg
c2lnZnJhbWUgc2l6ZTogMTc3Ng0KDQpbICAgIDEuMTU0NTIyXSByY3U6IEhpZXJhcmNoaWNhbCBT
UkNVIGltcGxlbWVudGF0aW9uLg0KDQpbICAgIDEuMTU1NTA2XSByY3U6IAlNYXggcGhhc2Ugbm8t
ZGVsYXkgaW5zdGFuY2VzIGlzIDQwMC4NCg0KWyAgICAxLjE1NjUzM10gVGltZXIgbWlncmF0aW9u
OiAxIGhpZXJhcmNoeSBsZXZlbHM7IDggY2hpbGRyZW4gcGVyIGdyb3VwOyAxIGNyb3Nzbm9kZSBs
ZXZlbA0KDQpbICAgIDEuMTYwMzkwXSBzbXA6IEJyaW5naW5nIHVwIHNlY29uZGFyeSBDUFVzIC4u
Lg0KDQpbICAgIDEuMTYwNTYxXSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDENCg0KWyAg
ICAxLjE2MTU3MV0gc21wYm9vdDogeDg2OiBCb290aW5nIFNNUCBjb25maWd1cmF0aW9uOg0KDQoo
WEVOKSBbICAgMTAuMjQyNTA3XSBjb21tb24vc2NoZWQvbnVsbC5jOjM1NzogMSA8LS0gZDB2MQ0K
WyAgICAxLjE2MjUwN10gLi4uLiBub2RlICAjMCwgQ1BVczogICAgICAjMQ0KDQpbICAgIDEuMTYz
OTE4XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDINCg0KKFhFTikgWyAgIDEwLjI1NjA0
Nl0gY29tbW9uL3NjaGVkL251bGwuYzozNTc6IDIgPC0tIGQwdjINClsgICAgMS4xNjU1OTJdICAj
Mg0KDQpbICAgIDEuMTY2NjI3XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDMNCg0KKFhF
TikgWyAgIDEwLjI2NzA3N10gY29tbW9uL3NjaGVkL251bGwuYzozNTc6IDMgPC0tIGQwdjMNClsg
ICAgMS4xNjg2MTNdICAjMw0KDQpbICAgIDEuMTcyNTczXSBzbXA6IEJyb3VnaHQgdXAgMSBub2Rl
LCA0IENQVXMNCg0KWyAgICAxLjE3NDUwOF0gc21wYm9vdDogVG90YWwgb2YgNCBwcm9jZXNzb3Jz
IGFjdGl2YXRlZCAoMjMxNTYuNTcgQm9nb01JUFMpDQoNClsgICAgMS4xNzY1NTFdIE1lbW9yeTog
MzM0OTMwMEsvMzI5NDA2NDhLIGF2YWlsYWJsZSAoMjA0ODBLIGtlcm5lbCBjb2RlLCAyOTI2SyBy
d2RhdGEsIDcyNzZLIHJvZGF0YSwgMjk4MEsgaW5pdCwgMjUyNEsgYnNzLCAyOTU4NzM5MksgcmVz
ZXJ2ZWQsIDBLIGNtYS1yZXNlcnZlZCkNCg0KWyAgICAxLjE3ODI1NV0gZGV2dG1wZnM6IGluaXRp
YWxpemVkDQoNClsgICAgMS4xNzg1MjhdIHg4Ni9tbTogTWVtb3J5IGJsb2NrIHNpemU6IDEyOE1C
DQoNClsgICAgMS4xODE1MjZdIEFDUEk6IFBNOiBSZWdpc3RlcmluZyBBQ1BJIE5WUyByZWdpb24g
W21lbSAweDBhMjAwMDAwLTB4MGEyMGNmZmZdICg1MzI0OCBieXRlcykNCg0KWyAgICAxLjE4MjUw
OF0gQUNQSTogUE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJlZ2lvbiBbbWVtIDB4Y2MxOTYwMDAt
MHhjYzM4OGZmZl0gKDIwNDM5MDQgYnl0ZXMpDQoNClsgICAgMS4xODM1MjVdIEFDUEk6IFBNOiBS
ZWdpc3RlcmluZyBBQ1BJIE5WUyByZWdpb24gW21lbSAweGNjMzhhMDAwLTB4Y2M3MDlmZmZdICgz
NjcwMDE2IGJ5dGVzKQ0KDQpbICAgIDEuMTg0NTYyXSBjbG9ja3NvdXJjZTogamlmZmllczogbWFz
azogMHhmZmZmZmZmZiBtYXhfY3ljbGVzOiAweGZmZmZmZmZmLCBtYXhfaWRsZV9uczogMTkxMTI2
MDQ0NjI3NTAwMCBucw0KDQpbICAgIDEuMTg1NTExXSBmdXRleCBoYXNoIHRhYmxlIGVudHJpZXM6
IDEwMjQgKG9yZGVyOiA0LCA2NTUzNiBieXRlcywgbGluZWFyKQ0KDQpbICAgIDEuMTg2NTc4XSBQ
TTogUlRDIHRpbWU6IDAyOjQwOjI3LCBkYXRlOiAyMDI1LTA1LTE2DQoNClsgICAgMS4xODc3MDRd
IE5FVDogUmVnaXN0ZXJlZCBQRl9ORVRMSU5LL1BGX1JPVVRFIHByb3RvY29sIGZhbWlseQ0KDQpb
ICAgIDEuMTg4NTIyXSB4ZW46Z3JhbnRfdGFibGU6IEdyYW50IHRhYmxlcyB1c2luZyB2ZXJzaW9u
IDEgbGF5b3V0DQoNClsgICAgMS4xODk1MjVdIEdyYW50IHRhYmxlIGluaXRpYWxpemVkDQoNClsg
ICAgMS4xOTA1NzldIGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0bGluayBzdWJzeXMgKGRpc2FibGVk
KQ0KDQpbICAgIDEuMTkxNTIwXSBhdWRpdDogdHlwZT0yMDAwIGF1ZGl0KDE3NDczNjMyMjcuOTk2
OjEpOiBzdGF0ZT1pbml0aWFsaXplZCBhdWRpdF9lbmFibGVkPTAgcmVzPTENCg0KWyAgICAxLjE5
MTU1Nl0gdGhlcm1hbF9zeXM6IFJlZ2lzdGVyZWQgdGhlcm1hbCBnb3Zlcm5vciAnc3RlcF93aXNl
Jw0KDQpbICAgIDEuMTk5NTEwXSB0aGVybWFsX3N5czogUmVnaXN0ZXJlZCB0aGVybWFsIGdvdmVy
bm9yICd1c2VyX3NwYWNlJw0KDQpbICAgIDEuMjA1NTE3XSBjcHVpZGxlOiB1c2luZyBnb3Zlcm5v
ciBtZW51DQoNClsgICAgMS4yMTU3MTldIFBDSTogRUNBTSBbbWVtIDB4ZjAwMDAwMDAtMHhmN2Zm
ZmZmZl0gKGJhc2UgMHhmMDAwMDAwMCkgZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtN2ZdDQoNClsg
ICAgMS4yMjQ1MjJdIFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9yIGJhc2UgYWNj
ZXNzDQoNClsgICAgMS4yMzA1MjhdIGtwcm9iZXM6IGtwcm9iZSBqdW1wLW9wdGltaXphdGlvbiBp
cyBlbmFibGVkLiBBbGwga3Byb2JlcyBhcmUgb3B0aW1pemVkIGlmIHBvc3NpYmxlLg0KDQpbICAg
IDEuMjM5NjIzXSBIdWdlVExCOiByZWdpc3RlcmVkIDEuMDAgR2lCIHBhZ2Ugc2l6ZSwgcHJlLWFs
bG9jYXRlZCAwIHBhZ2VzDQoNClsgICAgMS4yNDU1MDhdIEh1Z2VUTEI6IDE2MzgwIEtpQiB2bWVt
bWFwIGNhbiBiZSBmcmVlZCBmb3IgYSAxLjAwIEdpQiBwYWdlDQoNClsgICAgMS4yNTI1MDddIEh1
Z2VUTEI6IHJlZ2lzdGVyZWQgMi4wMCBNaUIgcGFnZSBzaXplLCBwcmUtYWxsb2NhdGVkIDAgcGFn
ZXMNCg0KWyAgICAxLjI1OTUwN10gSHVnZVRMQjogMjggS2lCIHZtZW1tYXAgY2FuIGJlIGZyZWVk
IGZvciBhIDIuMDAgTWlCIHBhZ2UNCg0KWyAgICAxLjI2NTU2MV0gQUNQSTogQWRkZWQgX09TSShN
b2R1bGUgRGV2aWNlKQ0KDQpbICAgIDEuMjY5NTA4XSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3Nv
ciBEZXZpY2UpDQoNClsgICAgMS4yNzQ1MDddIEFDUEk6IEFkZGVkIF9PU0koMy4wIF9TQ1AgRXh0
ZW5zaW9ucykNCg0KWyAgICAxLjI3OTUwN10gQUNQSTogQWRkZWQgX09TSShQcm9jZXNzb3IgQWdn
cmVnYXRvciBEZXZpY2UpDQoNClsgICAgMS4yOTYwNzFdIEFDUEk6IDExIEFDUEkgQU1MIHRhYmxl
cyBzdWNjZXNzZnVsbHkgYWNxdWlyZWQgYW5kIGxvYWRlZA0KDQooWEVOKSBbICAgMTAuNDk4NzA2
XSBkMDogYmluZDogbV9nc2k9OSBnX2dzaT05DQpbICAgIDEuMzA4MDE4XSBBQ1BJOiBbRmlybXdh
cmUgQnVnXTogQklPUyBfT1NJKExpbnV4KSBxdWVyeSBpZ25vcmVkDQoNClsgICAgMS4zMTgyNTVd
IEFDUEk6IEludGVycHJldGVyIGVuYWJsZWQNCg0KWyAgICAxLjMyMTUyMV0gQUNQSTogUE06IChz
dXBwb3J0cyBTMCBTMyBTNCBTNSkNCg0KWyAgICAxLjMyNTUwOV0gQUNQSTogVXNpbmcgSU9BUElD
IGZvciBpbnRlcnJ1cHQgcm91dGluZw0KDQpbICAgIDEuMzMwNzY4XSBQQ0k6IFVzaW5nIGhvc3Qg
YnJpZGdlIHdpbmRvd3MgZnJvbSBBQ1BJOyBpZiBuZWNlc3NhcnksIHVzZSAicGNpPW5vY3JzIiBh
bmQgcmVwb3J0IGEgYnVnDQoNClsgICAgMS4zNDA1MTZdIFBDSTogSWdub3JpbmcgRTgyMCByZXNl
cnZhdGlvbnMgZm9yIGhvc3QgYnJpZGdlIHdpbmRvd3MNCg0KWyAgICAxLjM0Njg3OF0gQUNQSTog
RW5hYmxlZCA2IEdQRXMgaW4gYmxvY2sgMDAgdG8gMUYNCg0KWyAgICAxLjM1MzA0NV0gQUNQSTog
XF9TQl8uUDBTMDogTmV3IHBvd2VyIHJlc291cmNlDQoNClsgICAgMS4zNTc1MjddIEFDUEk6IFxf
U0JfLlAzUzA6IE5ldyBwb3dlciByZXNvdXJjZQ0KDQpbICAgIDEuMzYyNTU4XSBBQ1BJOiBcX1NC
Xy5QMFMxOiBOZXcgcG93ZXIgcmVzb3VyY2UNCg0KWyAgICAxLjM2NjUyNV0gQUNQSTogXF9TQl8u
UDNTMTogTmV3IHBvd2VyIHJlc291cmNlDQoNClsgICAgMS4zNzc4ODBdIEFDUEk6IFxfU0JfLlBS
V0w6IE5ldyBwb3dlciByZXNvdXJjZQ0KDQpbICAgIDEuMzgyNTI1XSBBQ1BJOiBcX1NCXy5QUldC
OiBOZXcgcG93ZXIgcmVzb3VyY2UNCg0KWyAgICAxLjM4Njg2Nl0gQUNQSTogUENJIFJvb3QgQnJp
ZGdlIFtQQ0kwXSAoZG9tYWluIDAwMDAgW2J1cyAwMC1mZl0pDQoNClsgICAgMS4zOTM1MTBdIGFj
cGkgUE5QMEEwODowMDogX09TQzogT1Mgc3VwcG9ydHMgW0V4dGVuZGVkQ29uZmlnIEFTUE0gQ2xv
Y2tQTSBTZWdtZW50cyBNU0kgSFBYLVR5cGUzXQ0KDQpbICAgIDEuNDAyNjQzXSBhY3BpIFBOUDBB
MDg6MDA6IF9PU0M6IE9TIG5vdyBjb250cm9scyBbUE1FIFBDSWVDYXBhYmlsaXR5IExUUl0NCg0K
WyAgICAxLjQwOTUxM10gYWNwaSBQTlAwQTA4OjAwOiBbRmlybXdhcmUgSW5mb106IEVDQU0gW21l
bSAweGYwMDAwMDAwLTB4ZjdmZmZmZmZdIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLTdmXSBvbmx5
IHBhcnRpYWxseSBjb3ZlcnMgdGhpcyBicmlkZ2UNCg0KWyAgICAxLjQyMDc5OV0gUENJIGhvc3Qg
YnJpZGdlIHRvIGJ1cyAwMDAwOjAwDQoNClsgICAgMS40MjQ1MDldIHBjaV9idXMgMDAwMDowMDog
cm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDAwMDAtMHgwM2FmIHdpbmRvd10NCg0KWyAgICAxLjQz
MTUwOF0gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbaW8gIDB4MDNlMC0weDBj
Zjcgd2luZG93XQ0KDQpbICAgIDEuNDM4NTA4XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJl
c291cmNlIFtpbyAgMHgwM2IwLTB4MDNkZiB3aW5kb3ddDQoNClsgICAgMS40NDU1MDhdIHBjaV9i
dXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDBkMDAtMHhmZmZmIHdpbmRvd10N
Cg0KWyAgICAxLjQ1MTUxNF0gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbbWVt
IDB4MDAwYTAwMDAtMHgwMDBkZmZmZiB3aW5kb3ddDQoNClsgICAgMS40NTk1MTBdIHBjaV9idXMg
MDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW21lbSAweGQwMDAwMDAwLTB4ZmViZmZmZmYgd2lu
ZG93XQ0KDQpbICAgIDEuNDY2NTEyXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNl
IFttZW0gMHhmZWUwMDAwMC0weGZmZmZmZmZmIHdpbmRvd10NCg0KWyAgICAxLjQ3NDUwOF0gcGNp
X2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbbWVtIDB4ODMwMDAwMDAwLTB4ZmZmZmZm
ZmZmZiB3aW5kb3ddDQoNClsgICAgMS40ODE1MDhdIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMg
cmVzb3VyY2UgW2J1cyAwMC1mZl0NCg0KWyAgICAxLjQ4NzUzOF0gcGNpIDAwMDA6MDA6MDAuMDog
WzEwMjI6MTYzMF0gdHlwZSAwMCBjbGFzcyAweDA2MDAwMCBjb252ZW50aW9uYWwgUENJIGVuZHBv
aW50DQoNCihYRU4pIFsgICAxMC42OTQ2MTZdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDAuMA0K
WyAgICAxLjQ5ODUzNV0gcGNpIDAwMDA6MDA6MDAuMjogWzEwMjI6MTYzMV0gdHlwZSAwMCBjbGFz
cyAweDA4MDYwMCBjb252ZW50aW9uYWwgUENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAxMC43MDcy
NzNdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDAuMg0KWyAgICAxLjUxMTUzOV0gcGNpIDAwMDA6
MDA6MDEuMDogWzEwMjI6MTYzMl0gdHlwZSAwMCBjbGFzcyAweDA2MDAwMCBjb252ZW50aW9uYWwg
UENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAxMC43MTk5MzRdIFBDSSBhZGQgZGV2aWNlIDAwMDA6
MDA6MDEuMA0KWyAgICAxLjUyMzU0Ml0gcGNpIDAwMDA6MDA6MDIuMDogWzEwMjI6MTYzMl0gdHlw
ZSAwMCBjbGFzcyAweDA2MDAwMCBjb252ZW50aW9uYWwgUENJIGVuZHBvaW50DQoNCihYRU4pIFsg
ICAxMC43MzI1OTFdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDIuMA0KWyAgICAxLjUzNjUzNl0g
cGNpIDAwMDA6MDA6MDIuMTogWzEwMjI6MTYzNF0gdHlwZSAwMSBjbGFzcyAweDA2MDQwMCBQQ0ll
IFJvb3QgUG9ydA0KDQpbICAgIDEuNTQzNTU2XSBwY2kgMDAwMDowMDowMi4xOiBQQ0kgYnJpZGdl
IHRvIFtidXMgMDFdDQoNClsgICAgMS41NDg1MzFdIHBjaSAwMDAwOjAwOjAyLjE6ICAgYnJpZGdl
IHdpbmRvdyBbbWVtIDB4ZmZlMDAwMDAwMC0weGZmZjgwZmZmZmYgNjRiaXQgcHJlZl0NCg0KWyAg
ICAxLjU1NjcxMl0gcGNpIDAwMDA6MDA6MDIuMTogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hv
dCBEM2NvbGQNCg0KKFhFTikgWyAgIDEwLjc2Mzg1Ml0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDow
Mi4xDQpbICAgIDEuNTY3NTM4XSBwY2kgMDAwMDowMDowMi4zOiBbMTAyMjoxNjM0XSB0eXBlIDAx
IGNsYXNzIDB4MDYwNDAwIFBDSWUgUm9vdCBQb3J0DQoNClsgICAgMS41NzQ1NTVdIHBjaSAwMDAw
OjAwOjAyLjM6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMl0NCg0KWyAgICAxLjU3OTUxOF0gcGNpIDAw
MDA6MDA6MDIuMzogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZWEwMDAwMC0weGZlYWZmZmZmXQ0K
DQpbICAgIDEuNTg2NTM3XSBwY2kgMDAwMDowMDowMi4zOiBlbmFibGluZyBFeHRlbmRlZCBUYWdz
DQoNClsgICAgMS41OTE2OThdIHBjaSAwMDAwOjAwOjAyLjM6IFBNRSMgc3VwcG9ydGVkIGZyb20g
RDAgRDNob3QgRDNjb2xkDQoNCihYRU4pIFsgICAxMC43OTg3ODJdIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDA6MDIuMw0KWyAgICAxLjYwMTUzNl0gcGNpIDAwMDA6MDA6MDIuNDogWzEwMjI6MTYzNF0g
dHlwZSAwMSBjbGFzcyAweDA2MDQwMCBQQ0llIFJvb3QgUG9ydA0KDQpbICAgIDEuNjA5NTU0XSBw
Y2kgMDAwMDowMDowMi40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDNdDQoNClsgICAgMS42MTM1MThd
IHBjaSAwMDAwOjAwOjAyLjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZjAwMC0weGZmZmZdDQoN
ClsgICAgMS42MjA1MTFdIHBjaSAwMDAwOjAwOjAyLjQ6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4
ZmU5MDAwMDAtMHhmZTlmZmZmZl0NCg0KWyAgICAxLjYyNjUzN10gcGNpIDAwMDA6MDA6MDIuNDog
ZW5hYmxpbmcgRXh0ZW5kZWQgVGFncw0KDQpbICAgIDEuNjMxNjk3XSBwY2kgMDAwMDowMDowMi40
OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZA0KDQooWEVOKSBbICAgMTAuODM5
OTAzXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAyLjQNClsgICAgMS42NDI1NDVdIHBjaSAwMDAw
OjAwOjA4LjA6IFsxMDIyOjE2MzJdIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAgY29udmVudGlvbmFs
IFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTAuODUyNTU5XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjA4LjANClsgICAgMS42NTQ1MzVdIHBjaSAwMDAwOjAwOjA4LjE6IFsxMDIyOjE2MzVdIHR5
cGUgMDEgY2xhc3MgMHgwNjA0MDAgUENJZSBSb290IFBvcnQNCg0KWyAgICAxLjY2MjU1NV0gcGNp
IDAwMDA6MDA6MDguMTogUENJIGJyaWRnZSB0byBbYnVzIDA0XQ0KDQpbICAgIDEuNjY3NTE1XSBw
Y2kgMDAwMDowMDowOC4xOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZmXQ0KDQpb
ICAgIDEuNjczNTEwXSBwY2kgMDAwMDowMDowOC4xOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZl
NDAwMDAwLTB4ZmU3ZmZmZmZdDQoNClsgICAgMS42Nzk1MjBdIHBjaSAwMDAwOjAwOjA4LjE6ICAg
YnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDAwMDAwMDAtMHhlMDFmZmZmZiA2NGJpdCBwcmVmXQ0KDQpb
ICAgIDEuNjg3NTIyXSBwY2kgMDAwMDowMDowOC4xOiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoN
ClsgICAgMS42OTI2NjddIHBjaSAwMDAwOjAwOjA4LjE6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAg
RDNob3QgRDNjb2xkDQoNCihYRU4pIFsgICAxMC45MDEzNzldIFBDSSBhZGQgZGV2aWNlIDAwMDA6
MDA6MDguMQ0KWyAgICAxLjcwMzU0MF0gcGNpIDAwMDA6MDA6MDguMjogWzEwMjI6MTYzNV0gdHlw
ZSAwMSBjbGFzcyAweDA2MDQwMCBQQ0llIFJvb3QgUG9ydA0KDQpbICAgIDEuNzEwNTU1XSBwY2kg
MDAwMDowMDowOC4yOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDVdDQoNClsgICAgMS43MTU1MTddIHBj
aSAwMDAwOjAwOjA4LjI6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU4MDAwMDAtMHhmZThmZmZm
Zl0NCg0KWyAgICAxLjcyMjUzNV0gcGNpIDAwMDA6MDA6MDguMjogZW5hYmxpbmcgRXh0ZW5kZWQg
VGFncw0KDQpbICAgIDEuNzI3NjY3XSBwY2kgMDAwMDowMDowOC4yOiBQTUUjIHN1cHBvcnRlZCBm
cm9tIEQwIEQzaG90IEQzY29sZA0KDQooWEVOKSBbICAgMTAuOTM2MjQ1XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjA4LjINClsgICAgMS43Mzc1NTldIHBjaSAwMDAwOjAwOjE0LjA6IFsxMDIyOjc5
MGJdIHR5cGUgMDAgY2xhc3MgMHgwYzA1MDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQoo
WEVOKSBbICAgMTAuOTQ4OTQxXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjANClsgICAgMS43
NTA1MjhdIHBjaSAwMDAwOjAwOjE0LjM6IFsxMDIyOjc5MGVdIHR5cGUgMDAgY2xhc3MgMHgwNjAx
MDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTAuOTYxNjUyXSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjE0LjMNClsgICAgMS43NjI1NDZdIHBjaSAwMDAwOjAwOjE4LjA6
IFsxMDIyOjE0NDhdIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAgY29udmVudGlvbmFsIFBDSSBlbmRw
b2ludA0KDQooWEVOKSBbICAgMTAuOTc0MzA0XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjAN
ClsgICAgMS43NzU1MjRdIHBjaSAwMDAwOjAwOjE4LjE6IFsxMDIyOjE0NDldIHR5cGUgMDAgY2xh
c3MgMHgwNjAwMDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTAuOTg2
OTU3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjENClsgICAgMS43ODc1MjVdIHBjaSAwMDAw
OjAwOjE4LjI6IFsxMDIyOjE0NGFdIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAgY29udmVudGlvbmFs
IFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTAuOTk5NjEyXSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjE4LjINClsgICAgMS44MDA1MjddIHBjaSAwMDAwOjAwOjE4LjM6IFsxMDIyOjE0NGJdIHR5
cGUgMDAgY2xhc3MgMHgwNjAwMDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBb
ICAgMTEuMDEyMjY0XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjMNClsgICAgMS44MTI1MjVd
IHBjaSAwMDAwOjAwOjE4LjQ6IFsxMDIyOjE0NGNdIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAgY29u
dmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTEuMDI0OTE4XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjE4LjQNClsgICAgMS44MjU1MjVdIHBjaSAwMDAwOjAwOjE4LjU6IFsxMDIy
OjE0NGRdIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0K
DQooWEVOKSBbICAgMTEuMDM3NTcxXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjUNClsgICAg
MS44Mzc1MjVdIHBjaSAwMDAwOjAwOjE4LjY6IFsxMDIyOjE0NGVdIHR5cGUgMDAgY2xhc3MgMHgw
NjAwMDAgY29udmVudGlvbmFsIFBDSSBlbmRwb2ludA0KDQooWEVOKSBbICAgMTEuMDUwMjI0XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjYNClsgICAgMS44NTA1MjVdIHBjaSAwMDAwOjAwOjE4
Ljc6IFsxMDIyOjE0NGZdIHR5cGUgMDAgY2xhc3MgMHgwNjAwMDAgY29udmVudGlvbmFsIFBDSSBl
bmRwb2ludA0KDQooWEVOKSBbICAgMTEuMDYyODgxXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4
LjcNClsgICAgMS44NjI2MDddIHBjaSAwMDAwOjAxOjAwLjA6IFsxMGVlOjU3MDBdIHR5cGUgMDAg
Y2xhc3MgMHgxMjAwMDAgUENJZSBFbmRwb2ludA0KDQpbICAgIDEuODY5NTM2XSBwY2kgMDAwMDow
MTowMC4wOiBCQVIgMCBbbWVtIDB4ZmZlMDAwMDAwMC0weGZmZWZmZmZmZmYgNjRiaXQgcHJlZl0N
Cg0KWyAgICAxLjg3NzUyNV0gcGNpIDAwMDA6MDE6MDAuMDogQkFSIDIgW21lbSAweGZmZjgwNDAw
MDAtMHhmZmY4MDdmZmZmIDY0Yml0IHByZWZdDQoNClsgICAgMS44ODQ3MTldIHBjaSAwMDAwOjAx
OjAwLjA6IHN1cHBvcnRzIEQxDQoNClsgICAgMS44ODg1MDddIHBjaSAwMDAwOjAxOjAwLjA6IFBN
RSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDNob3QgRDNjb2xkDQoNCihYRU4pIFsgICAxMS4wOTk3
ODNdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDE6MDAuMA0KWyAgICAxLjg5OTU1NV0gcGNpIDAwMDA6
MDE6MDAuMTogWzEwZWU6NTcwMV0gdHlwZSAwMCBjbGFzcyAweDEyMDAwMCBQQ0llIEVuZHBvaW50
DQoNClsgICAgMS45MDY1MzZdIHBjaSAwMDAwOjAxOjAwLjE6IEJBUiAwIFttZW0gMHhmZmY4MDAw
MDAwLTB4ZmZmODAzZmZmZiA2NGJpdCBwcmVmXQ0KDQpbICAgIDEuOTEzNTI1XSBwY2kgMDAwMDow
MTowMC4xOiBCQVIgMiBbbWVtIDB4ZmZmMDAwMDAwMC0weGZmZjdmZmZmZmYgNjRiaXQgcHJlZl0N
Cg0KWyAgICAxLjkyMDcwMl0gcGNpIDAwMDA6MDE6MDAuMTogc3VwcG9ydHMgRDENCg0KWyAgICAx
LjkyNDUwN10gcGNpIDAwMDA6MDE6MDAuMTogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEM2hv
dCBEM2NvbGQNCg0KKFhFTikgWyAgIDExLjEzNjYxNl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMTow
MC4xDQpbICAgIDEuOTM1NTMxXSBwY2kgMDAwMDowMDowMi4xOiBQQ0kgYnJpZGdlIHRvIFtidXMg
MDFdDQoNClsgICAgMS45NDA2MTFdIHBjaSAwMDAwOjAyOjAwLjA6IFsxNDRkOmE4MDhdIHR5cGUg
MDAgY2xhc3MgMHgwMTA4MDIgUENJZSBFbmRwb2ludA0KDQooWEVOKSBbICAgMTEuMTUzMjU2XSAw
MDAwOjAyOjAwLjA6IG5vdCBtYXBwaW5nIEJBUiBbZmVhMDAsIGZlYTAzXSBpbnZhbGlkIHBvc2l0
aW9uDQpbICAgIDEuOTQ3NTA3XSBwY2kgMDAwMDowMjowMC4wOiBCQVIgMCBbbWVtIDB4ZmVhMDAw
MDAtMHhmZWEwM2ZmZiA2NGJpdF0NCg0KKFhFTikgWyAgIDExLjE2NzAzM10gMDAwMDowMjowMC4w
OiBub3QgbWFwcGluZyBCQVIgW2ZlYTAwLCBmZWEwM10gaW52YWxpZCBwb3NpdGlvbg0KKFhFTikg
WyAgIDExLjE3NDMxM10gMDAwMDowMjowMC4wOiBub3QgbWFwcGluZyBCQVIgW2ZlYTAwLCBmZWEw
M10gaW52YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAgIDExLjE4MTU5OF0gMDAwMDowMjowMC4wOiBu
b3QgbWFwcGluZyBCQVIgW2ZlYTAwLCBmZWEwM10gaW52YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAg
IDExLjE4ODg3M10gMDAwMDowMjowMC4wOiBub3QgbWFwcGluZyBCQVIgW2ZlYTAwLCBmZWEwM10g
aW52YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAgIDExLjE5NjE1OF0gMDAwMDowMjowMC4wOiBub3Qg
bWFwcGluZyBCQVIgW2ZlYTAwLCBmZWEwM10gaW52YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAgIDEx
LjIwMzg3M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMjowMC4wDQpbICAgIDEuOTYzNTIwXSBwY2kg
MDAwMDowMDowMi4zOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDJdDQoNClsgICAgMS45Njg2MTJdIHBj
aSAwMDAwOjAzOjAwLjA6IFsxMGVjOjgxMjVdIHR5cGUgMDAgY2xhc3MgMHgwMjAwMDAgUENJZSBF
bmRwb2ludA0KDQooWEVOKSBbICAgMTEuMjIwNTEyXSAwMDAwOjAzOjAwLjA6IG5vdCBtYXBwaW5n
IEJBUiBbZmU5MDAsIGZlOTBmXSBpbnZhbGlkIHBvc2l0aW9uDQooWEVOKSBbICAgMTEuMjI3Nzkz
XSAwMDAwOjAzOjAwLjA6IG5vdCBtYXBwaW5nIEJBUiBbZmU5MTAsIGZlOTEzXSBpbnZhbGlkIHBv
c2l0aW9uDQpbICAgIDEuOTc1NTA3XSBwY2kgMDAwMDowMzowMC4wOiBCQVIgMCBbaW8gIDB4ZjAw
MC0weGYwZmZdDQoNCihYRU4pIFsgICAxMS4yNDAzNTddIDAwMDA6MDM6MDAuMDogbm90IG1hcHBp
bmcgQkFSIFtmZTkwMCwgZmU5MGZdIGludmFsaWQgcG9zaXRpb24NCihYRU4pIFsgICAxMS4yNDc2
NDBdIDAwMDA6MDM6MDAuMDogbm90IG1hcHBpbmcgQkFSIFtmZTkxMCwgZmU5MTNdIGludmFsaWQg
cG9zaXRpb24NCihYRU4pIFsgICAxMS4yNTQ5MThdIDAwMDA6MDM6MDAuMDogbm90IG1hcHBpbmcg
QkFSIFtmZTkwMCwgZmU5MGZdIGludmFsaWQgcG9zaXRpb24NCihYRU4pIFsgICAxMS4yNjIyMDBd
IDAwMDA6MDM6MDAuMDogbm90IG1hcHBpbmcgQkFSIFtmZTkxMCwgZmU5MTNdIGludmFsaWQgcG9z
aXRpb24NClsgICAgMS45ODM1MDZdIHBjaSAwMDAwOjAzOjAwLjA6IEJBUiAyIFttZW0gMHhmZTkw
MDAwMC0weGZlOTBmZmZmIDY0Yml0XQ0KDQooWEVOKSBbICAgMTEuMjc1OTc2XSAwMDAwOjAzOjAw
LjA6IG5vdCBtYXBwaW5nIEJBUiBbZmU5MDAsIGZlOTBmXSBpbnZhbGlkIHBvc2l0aW9uDQooWEVO
KSBbICAgMTEuMjgzMjU3XSAwMDAwOjAzOjAwLjA6IG5vdCBtYXBwaW5nIEJBUiBbZmU5MTAsIGZl
OTEzXSBpbnZhbGlkIHBvc2l0aW9uDQpbICAgIDEuOTg5NTA3XSBwY2kgMDAwMDowMzowMC4wOiBC
QVIgNCBbbWVtIDB4ZmU5MTAwMDAtMHhmZTkxM2ZmZiA2NGJpdF0NCg0KKFhFTikgWyAgIDExLjI5
NzA0Ml0gMDAwMDowMzowMC4wOiBub3QgbWFwcGluZyBCQVIgW2ZlOTAwLCBmZTkwZl0gaW52YWxp
ZCBwb3NpdGlvbg0KKFhFTikgWyAgIDExLjMwNDMxN10gMDAwMDowMzowMC4wOiBub3QgbWFwcGlu
ZyBCQVIgW2ZlOTEwLCBmZTkxM10gaW52YWxpZCBwb3NpdGlvbg0KWyAgICAxLjk5Nzc0N10gcGNp
IDAwMDA6MDM6MDAuMDogc3VwcG9ydHMgRDEgRDINCg0KWyAgICAyLjAwMTUwN10gcGNpIDAwMDA6
MDM6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBEM2NvbGQNCg0KKFhF
TikgWyAgIDExLjMyMzAwMl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMzowMC4wDQpbICAgIDIuMDEy
NjM0XSBwY2kgMDAwMDowMDowMi40OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDNdDQoNClsgICAgMi4w
MTc2MDFdIHBjaSAwMDAwOjA0OjAwLjA6IFsxMDAyOjE2MzZdIHR5cGUgMDAgY2xhc3MgMHgwMzAw
MDAgUENJZSBMZWdhY3kgRW5kcG9pbnQNCg0KKFhFTikgWyAgIDExLjM0MDc5NF0gMDAwMDowNDow
MC4wOiBub3QgbWFwcGluZyBCQVIgW2ZlNzAwLCBmZTc3Zl0gaW52YWxpZCBwb3NpdGlvbg0KWyAg
ICAyLjAyNjUwNl0gcGNpIDAwMDA6MDQ6MDAuMDogQkFSIDAgW21lbSAweGQwMDAwMDAwLTB4ZGZm
ZmZmZmYgNjRiaXQgcHJlZl0NCg0KKFhFTikgWyAgIDExLjM1NTUyOF0gMDAwMDowNDowMC4wOiBu
b3QgbWFwcGluZyBCQVIgW2ZlNzAwLCBmZTc3Zl0gaW52YWxpZCBwb3NpdGlvbg0KWyAgICAyLjAz
NDUwNl0gcGNpIDAwMDA6MDQ6MDAuMDogQkFSIDIgW21lbSAweGUwMDAwMDAwLTB4ZTAxZmZmZmYg
NjRiaXQgcHJlZl0NCg0KKFhFTikgWyAgIDExLjM3MDI2NV0gMDAwMDowNDowMC4wOiBub3QgbWFw
cGluZyBCQVIgW2ZlNzAwLCBmZTc3Zl0gaW52YWxpZCBwb3NpdGlvbg0KWyAgICAyLjA0MjUwNl0g
cGNpIDAwMDA6MDQ6MDAuMDogQkFSIDQgW2lvICAweGUwMDAtMHhlMGZmXQ0KDQooWEVOKSBbICAg
MTEuMzgzMzMxXSAwMDAwOjA0OjAwLjA6IG5vdCBtYXBwaW5nIEJBUiBbZmU3MDAsIGZlNzdmXSBp
bnZhbGlkIHBvc2l0aW9uDQpbICAgIDIuMDQ4NTA1XSBwY2kgMDAwMDowNDowMC4wOiBCQVIgNSBb
bWVtIDB4ZmU3MDAwMDAtMHhmZTc3ZmZmZl0NCg0KKFhFTikgWyAgIDExLjM5NzEyMF0gMDAwMDow
NDowMC4wOiBub3QgbWFwcGluZyBCQVIgW2ZlNzAwLCBmZTc3Zl0gaW52YWxpZCBwb3NpdGlvbg0K
WyAgICAyLjA1NTUxNV0gcGNpIDAwMDA6MDQ6MDAuMDogZW5hYmxpbmcgRXh0ZW5kZWQgVGFncw0K
DQpbICAgIDIuMDU5NzQ4XSBwY2kgMDAwMDowNDowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQx
IEQyIEQzaG90IEQzY29sZA0KDQpbICAgIDIuMDY2NjAyXSBwY2kgMDAwMDowNDowMC4wOiAxMjYu
MDE2IEdiL3MgYXZhaWxhYmxlIFBDSWUgYmFuZHdpZHRoLCBsaW1pdGVkIGJ5IDguMCBHVC9zIFBD
SWUgeDE2IGxpbmsgYXQgMDAwMDowMDowOC4xIChjYXBhYmxlIG9mIDI1Mi4wNDggR2IvcyB3aXRo
IDE2LjAgR1QvcyBQQ0llIHgxNiBsaW5rKQ0KDQooWEVOKSBbICAgMTEuNDMxNTYzXSBQQ0kgYWRk
IGRldmljZSAwMDAwOjA0OjAwLjANClsgICAgMi4wODY1MzddIHBjaSAwMDAwOjA0OjAwLjE6IFsx
MDAyOjE2MzddIHR5cGUgMDAgY2xhc3MgMHgwNDAzMDAgUENJZSBMZWdhY3kgRW5kcG9pbnQNCg0K
WyAgICAyLjA5MzUyNV0gcGNpIDAwMDA6MDQ6MDAuMTogQkFSIDAgW21lbSAweGZlN2M4MDAwLTB4
ZmU3Y2JmZmZdDQoNClsgICAgMi4wOTk1NjFdIHBjaSAwMDAwOjA0OjAwLjE6IGVuYWJsaW5nIEV4
dGVuZGVkIFRhZ3MNCg0KWyAgICAyLjEwNDU5Ml0gcGNpIDAwMDA6MDQ6MDAuMTogUE1FIyBzdXBw
b3J0ZWQgZnJvbSBEMSBEMiBEM2hvdCBEM2NvbGQNCg0KKFhFTikgWyAgIDExLjQ2MTIwMV0gUENJ
IGFkZCBkZXZpY2UgMDAwMDowNDowMC4xDQpbICAgIDIuMTE1NTM3XSBwY2kgMDAwMDowNDowMC4y
OiBbMTAyMjoxNWRmXSB0eXBlIDAwIGNsYXNzIDB4MTA4MDAwIFBDSWUgRW5kcG9pbnQNCg0KWyAg
ICAyLjEyMjU0MF0gcGNpIDAwMDA6MDQ6MDAuMjogQkFSIDIgW21lbSAweGZlNjAwMDAwLTB4ZmU2
ZmZmZmZdDQoNClsgICAgMi4xMjg1MzBdIHBjaSAwMDAwOjA0OjAwLjI6IEJBUiA1IFttZW0gMHhm
ZTdjYzAwMC0weGZlN2NkZmZmXQ0KDQpbICAgIDIuMTM0NTI0XSBwY2kgMDAwMDowNDowMC4yOiBl
bmFibGluZyBFeHRlbmRlZCBUYWdzDQoNCihYRU4pIFsgICAxMS40ODk4NjVdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDQ6MDAuMg0KWyAgICAyLjE0MzUzN10gcGNpIDAwMDA6MDQ6MDAuMzogWzEwMjI6
MTYzOV0gdHlwZSAwMCBjbGFzcyAweDBjMDMzMCBQQ0llIEVuZHBvaW50DQoNCihYRU4pIFsgICAx
MS41MDE0NzhdIDAwMDA6MDQ6MDAuMzogbm90IG1hcHBpbmcgQkFSIFtmZTUwMCwgZmU1ZmZdIGlu
dmFsaWQgcG9zaXRpb24NClsgICAgMi4xNTA1MDZdIHBjaSAwMDAwOjA0OjAwLjM6IEJBUiAwIFtt
ZW0gMHhmZTUwMDAwMC0weGZlNWZmZmZmIDY0Yml0XQ0KDQooWEVOKSBbICAgMTEuNTE1MjU5XSAw
MDAwOjA0OjAwLjM6IG5vdCBtYXBwaW5nIEJBUiBbZmU1MDAsIGZlNWZmXSBpbnZhbGlkIHBvc2l0
aW9uDQooWEVOKSBbICAgMTEuNTIyNTM4XSAwMDAwOjA0OjAwLjM6IG5vdCBtYXBwaW5nIEJBUiBb
ZmU1MDAsIGZlNWZmXSBpbnZhbGlkIHBvc2l0aW9uDQooWEVOKSBbICAgMTEuNTI5ODIyXSAwMDAw
OjA0OjAwLjM6IG5vdCBtYXBwaW5nIEJBUiBbZmU1MDAsIGZlNWZmXSBpbnZhbGlkIHBvc2l0aW9u
DQooWEVOKSBbICAgMTEuNTM3MTA0XSAwMDAwOjA0OjAwLjM6IG5vdCBtYXBwaW5nIEJBUiBbZmU1
MDAsIGZlNWZmXSBpbnZhbGlkIHBvc2l0aW9uDQooWEVOKSBbICAgMTEuNTQ0MzgxXSAwMDAwOjA0
OjAwLjM6IG5vdCBtYXBwaW5nIEJBUiBbZmU1MDAsIGZlNWZmXSBpbnZhbGlkIHBvc2l0aW9uDQpb
ICAgIDIuMTYxNTE3XSBwY2kgMDAwMDowNDowMC4zOiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoN
ClsgICAgMi4xNjY2MDVdIHBjaSAwMDAwOjA0OjAwLjM6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAg
RDNob3QgRDNjb2xkDQoNCihYRU4pIFsgICAxMS41NjI4NDFdIFBDSSBhZGQgZGV2aWNlIDAwMDA6
MDQ6MDAuMw0KWyAgICAyLjE3NzUzN10gcGNpIDAwMDA6MDQ6MDAuNDogWzEwMjI6MTYzOV0gdHlw
ZSAwMCBjbGFzcyAweDBjMDMzMCBQQ0llIEVuZHBvaW50DQoNCihYRU4pIFsgICAxMS41NzQ0NTRd
IDAwMDA6MDQ6MDAuNDogbm90IG1hcHBpbmcgQkFSIFtmZTQwMCwgZmU0ZmZdIGludmFsaWQgcG9z
aXRpb24NClsgICAgMi4xODQ1MDddIHBjaSAwMDAwOjA0OjAwLjQ6IEJBUiAwIFttZW0gMHhmZTQw
MDAwMC0weGZlNGZmZmZmIDY0Yml0XQ0KDQooWEVOKSBbICAgMTEuNTg4MjMyXSAwMDAwOjA0OjAw
LjQ6IG5vdCBtYXBwaW5nIEJBUiBbZmU0MDAsIGZlNGZmXSBpbnZhbGlkIHBvc2l0aW9uDQooWEVO
KSBbICAgMTEuNTk1NTE1XSAwMDAwOjA0OjAwLjQ6IG5vdCBtYXBwaW5nIEJBUiBbZmU0MDAsIGZl
NGZmXSBpbnZhbGlkIHBvc2l0aW9uDQooWEVOKSBbICAgMTEuNjAyNzk0XSAwMDAwOjA0OjAwLjQ6
IG5vdCBtYXBwaW5nIEJBUiBbZmU0MDAsIGZlNGZmXSBpbnZhbGlkIHBvc2l0aW9uDQooWEVOKSBb
ICAgMTEuNjEwMDc3XSAwMDAwOjA0OjAwLjQ6IG5vdCBtYXBwaW5nIEJBUiBbZmU0MDAsIGZlNGZm
XSBpbnZhbGlkIHBvc2l0aW9uDQooWEVOKSBbICAgMTEuNjE3MzU0XSAwMDAwOjA0OjAwLjQ6IG5v
dCBtYXBwaW5nIEJBUiBbZmU0MDAsIGZlNGZmXSBpbnZhbGlkIHBvc2l0aW9uDQpbICAgIDIuMTk1
NTE4XSBwY2kgMDAwMDowNDowMC40OiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNClsgICAgMi4y
MDA2MDNdIHBjaSAwMDAwOjA0OjAwLjQ6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNj
b2xkDQoNCihYRU4pIFsgICAxMS42MzU4MTFdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNA0K
WyAgICAyLjIxMTUzN10gcGNpIDAwMDA6MDQ6MDAuNTogWzEwMjI6MTVlMl0gdHlwZSAwMCBjbGFz
cyAweDA0ODAwMCBQQ0llIEVuZHBvaW50DQoNClsgICAgMi4yMTg1MjVdIHBjaSAwMDAwOjA0OjAw
LjU6IEJBUiAwIFttZW0gMHhmZTc4MDAwMC0weGZlN2JmZmZmXQ0KDQpbICAgIDIuMjI0NTYxXSBw
Y2kgMDAwMDowNDowMC41OiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNClsgICAgMi4yMjk1OTFd
IHBjaSAwMDAwOjA0OjAwLjU6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQoN
CihYRU4pIFsgICAxMS42NjQ1ODVdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNQ0KWyAgICAy
LjIzOTUzNl0gcGNpIDAwMDA6MDQ6MDAuNjogWzEwMjI6MTVlM10gdHlwZSAwMCBjbGFzcyAweDA0
MDMwMCBQQ0llIEVuZHBvaW50DQoNClsgICAgMi4yNDY1MjVdIHBjaSAwMDAwOjA0OjAwLjY6IEJB
UiAwIFttZW0gMHhmZTdjMDAwMC0weGZlN2M3ZmZmXQ0KDQpbICAgIDIuMjUyNTYxXSBwY2kgMDAw
MDowNDowMC42OiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNClsgICAgMi4yNTc1OTRdIHBjaSAw
MDAwOjA0OjAwLjY6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQoNCihYRU4p
IFsgICAxMS42OTMzNTldIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNg0KWyAgICAyLjI2ODU3
M10gcGNpIDAwMDA6MDA6MDguMTogUENJIGJyaWRnZSB0byBbYnVzIDA0XQ0KDQpbICAgIDIuMjcz
NjAwXSBwY2kgMDAwMDowNTowMC4wOiBbMTAyMjo3OTAxXSB0eXBlIDAwIGNsYXNzIDB4MDEwNjAx
IFBDSWUgRW5kcG9pbnQNCg0KKFhFTikgWyAgIDExLjcxMDAwMV0gMDAwMDowNTowMC4wOiBub3Qg
bWFwcGluZyBCQVIgW2ZlODAxLCBmZTgwMV0gaW52YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAgIDEx
LjcxNzI4MF0gMDAwMDowNTowMC4wOiBub3QgbWFwcGluZyBCQVIgW2ZlODAxLCBmZTgwMV0gaW52
YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAgIDExLjcyNDU1N10gMDAwMDowNTowMC4wOiBub3QgbWFw
cGluZyBCQVIgW2ZlODAxLCBmZTgwMV0gaW52YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAgIDExLjcz
MTgzN10gMDAwMDowNTowMC4wOiBub3QgbWFwcGluZyBCQVIgW2ZlODAxLCBmZTgwMV0gaW52YWxp
ZCBwb3NpdGlvbg0KKFhFTikgWyAgIDExLjczOTExN10gMDAwMDowNTowMC4wOiBub3QgbWFwcGlu
ZyBCQVIgW2ZlODAxLCBmZTgwMV0gaW52YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAgIDExLjc0NjQw
Ml0gMDAwMDowNTowMC4wOiBub3QgbWFwcGluZyBCQVIgW2ZlODAxLCBmZTgwMV0gaW52YWxpZCBw
b3NpdGlvbg0KWyAgICAyLjI4NTUwN10gcGNpIDAwMDA6MDU6MDAuMDogQkFSIDUgW21lbSAweGZl
ODAxMDAwLTB4ZmU4MDE3ZmZdDQoNCihYRU4pIFsgICAxMS43NTk2NTddIDAwMDA6MDU6MDAuMDog
bm90IG1hcHBpbmcgQkFSIFtmZTgwMSwgZmU4MDFdIGludmFsaWQgcG9zaXRpb24NClsgICAgMi4y
OTE1MTddIHBjaSAwMDAwOjA1OjAwLjA6IGVuYWJsaW5nIEV4dGVuZGVkIFRhZ3MNCg0KWyAgICAy
LjI5Njc2OF0gcGNpIDAwMDA6MDU6MDAuMDogMTI2LjAxNiBHYi9zIGF2YWlsYWJsZSBQQ0llIGJh
bmR3aWR0aCwgbGltaXRlZCBieSA4LjAgR1QvcyBQQ0llIHgxNiBsaW5rIGF0IDAwMDA6MDA6MDgu
MiAoY2FwYWJsZSBvZiAyNTIuMDQ4IEdiL3Mgd2l0aCAxNi4wIEdUL3MgUENJZSB4MTYgbGluaykN
Cg0KKFhFTikgWyAgIDExLjc4NzY0Ml0gUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4wDQpbICAg
IDIuMzE2NTM2XSBwY2kgMDAwMDowNTowMC4xOiBbMTAyMjo3OTAxXSB0eXBlIDAwIGNsYXNzIDB4
MDEwNjAxIFBDSWUgRW5kcG9pbnQNCg0KKFhFTikgWyAgIDExLjc5OTI1OF0gMDAwMDowNTowMC4x
OiBub3QgbWFwcGluZyBCQVIgW2ZlODAwLCBmZTgwMF0gaW52YWxpZCBwb3NpdGlvbg0KKFhFTikg
WyAgIDExLjgwNjUzOF0gMDAwMDowNTowMC4xOiBub3QgbWFwcGluZyBCQVIgW2ZlODAwLCBmZTgw
MF0gaW52YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAgIDExLjgxMzgxNV0gMDAwMDowNTowMC4xOiBu
b3QgbWFwcGluZyBCQVIgW2ZlODAwLCBmZTgwMF0gaW52YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAg
IDExLjgyMTA5NV0gMDAwMDowNTowMC4xOiBub3QgbWFwcGluZyBCQVIgW2ZlODAwLCBmZTgwMF0g
aW52YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAgIDExLjgyODM4MF0gMDAwMDowNTowMC4xOiBub3Qg
bWFwcGluZyBCQVIgW2ZlODAwLCBmZTgwMF0gaW52YWxpZCBwb3NpdGlvbg0KKFhFTikgWyAgIDEx
LjgzNTY1N10gMDAwMDowNTowMC4xOiBub3QgbWFwcGluZyBCQVIgW2ZlODAwLCBmZTgwMF0gaW52
YWxpZCBwb3NpdGlvbg0KWyAgICAyLjMyODUwNl0gcGNpIDAwMDA6MDU6MDAuMTogQkFSIDUgW21l
bSAweGZlODAwMDAwLTB4ZmU4MDA3ZmZdDQoNCihYRU4pIFsgICAxMS44NDg5MTVdIDAwMDA6MDU6
MDAuMTogbm90IG1hcHBpbmcgQkFSIFtmZTgwMCwgZmU4MDBdIGludmFsaWQgcG9zaXRpb24NClsg
ICAgMi4zMzQ1MTddIHBjaSAwMDAwOjA1OjAwLjE6IGVuYWJsaW5nIEV4dGVuZGVkIFRhZ3MNCg0K
KFhFTikgWyAgIDExLjg2MTMwMV0gUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4xDQpbICAgIDIu
MzQ0NTQ2XSBwY2kgMDAwMDowMDowOC4yOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDVdDQoNClsgICAg
Mi4zNTAxMzZdIEFDUEk6IFBDSTogSW50ZXJydXB0IGxpbmsgTE5LQSBjb25maWd1cmVkIGZvciBJ
UlEgMA0KDQpbICAgIDIuMzU1NTUzXSBBQ1BJOiBQQ0k6IEludGVycnVwdCBsaW5rIExOS0IgY29u
ZmlndXJlZCBmb3IgSVJRIDANCg0KWyAgICAyLjM2MTU0Nl0gQUNQSTogUENJOiBJbnRlcnJ1cHQg
bGluayBMTktDIGNvbmZpZ3VyZWQgZm9yIElSUSAwDQoNClsgICAgMi4zNjc1NTVdIEFDUEk6IFBD
STogSW50ZXJydXB0IGxpbmsgTE5LRCBjb25maWd1cmVkIGZvciBJUlEgMA0KDQpbICAgIDIuMzcz
NTUxXSBBQ1BJOiBQQ0k6IEludGVycnVwdCBsaW5rIExOS0UgY29uZmlndXJlZCBmb3IgSVJRIDAN
Cg0KWyAgICAyLjM3OTU0M10gQUNQSTogUENJOiBJbnRlcnJ1cHQgbGluayBMTktGIGNvbmZpZ3Vy
ZWQgZm9yIElSUSAwDQoNClsgICAgMi4zODU1NDNdIEFDUEk6IFBDSTogSW50ZXJydXB0IGxpbmsg
TE5LRyBjb25maWd1cmVkIGZvciBJUlEgMA0KDQpbICAgIDIuMzkxNTQzXSBBQ1BJOiBQQ0k6IElu
dGVycnVwdCBsaW5rIExOS0ggY29uZmlndXJlZCBmb3IgSVJRIDANCg0KWyAgICAyLjM5ODQ2Nl0g
eGVuOmJhbGxvb246IEluaXRpYWxpc2luZyBiYWxsb29uIGRyaXZlcg0KDQpbICAgIDIuNDg2NTc3
XSBpb21tdTogRGVmYXVsdCBkb21haW4gdHlwZTogVHJhbnNsYXRlZA0KDQpbICAgIDIuNDkxNTEw
XSBpb21tdTogRE1BIGRvbWFpbiBUTEIgaW52YWxpZGF0aW9uIHBvbGljeTogbGF6eSBtb2RlDQoN
ClsgICAgMi40OTc1NTldIFNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkDQoNClsgICAgMi41MDE1
MjBdIGxpYmF0YSB2ZXJzaW9uIDMuMDAgbG9hZGVkLg0KDQpbICAgIDIuNTA1NTIyXSBBQ1BJOiBi
dXMgdHlwZSBVU0IgcmVnaXN0ZXJlZA0KDQpbICAgIDIuNTA5NTE1XSB1c2Jjb3JlOiByZWdpc3Rl
cmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmZzDQoNClsgICAgMi41MTQ1MTBdIHVzYmNvcmU6
IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgaHViDQoNClsgICAgMi41MTk1MTBdIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRldmljZSBkcml2ZXIgdXNiDQoNClsgICAgMi41MjQ1MTVd
IHBwc19jb3JlOiBMaW51eFBQUyBBUEkgdmVyLiAxIHJlZ2lzdGVyZWQNCg0KWyAgICAyLjUyOTUw
N10gcHBzX2NvcmU6IFNvZnR3YXJlIHZlci4gNS4zLjYgLSBDb3B5cmlnaHQgMjAwNS0yMDA3IFJv
ZG9sZm8gR2lvbWV0dGkgPGdpb21ldHRpQGxpbnV4Lml0Pg0KDQpbICAgIDIuNTM3NTEwXSBQVFAg
Y2xvY2sgc3VwcG9ydCByZWdpc3RlcmVkDQoNClsgICAgMi41NDE1NTRdIGVmaXZhcnM6IFJlZ2lz
dGVyZWQgZWZpdmFycyBvcGVyYXRpb25zDQoNClsgICAgMi41NDY1MjNdIEFkdmFuY2VkIExpbnV4
IFNvdW5kIEFyY2hpdGVjdHVyZSBEcml2ZXIgSW5pdGlhbGl6ZWQuDQoNClsgICAgMi41NTI2MDNd
IE5ldExhYmVsOiBJbml0aWFsaXppbmcNCg0KWyAgICAyLjU1NjUwN10gTmV0TGFiZWw6ICBkb21h
aW4gaGFzaCBzaXplID0gMTI4DQoNClsgICAgMi41NjA1MDddIE5ldExhYmVsOiAgcHJvdG9jb2xz
ID0gVU5MQUJFTEVEIENJUFNPdjQgQ0FMSVBTTw0KDQpbICAgIDIuNTY2NTE4XSBOZXRMYWJlbDog
IHVubGFiZWxlZCB0cmFmZmljIGFsbG93ZWQgYnkgZGVmYXVsdA0KDQpbICAgIDIuNTcxNTMzXSBQ
Q0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nDQoNClsgICAgMi41ODM0NjNdIFBDSTogcGNp
X2NhY2hlX2xpbmVfc2l6ZSBzZXQgdG8gNjQgYnl0ZXMNCg0KWyAgICAyLjU4ODYyNF0gcmVzb3Vy
Y2U6IEV4cGFuZGVkIHJlc291cmNlIFJlc2VydmVkIGR1ZSB0byBjb25mbGljdCB3aXRoIFBDSSBC
dXMgMDAwMDowMA0KDQpbICAgIDIuNTk2NTA4XSByZXNvdXJjZTogRXhwYW5kZWQgcmVzb3VyY2Ug
UmVzZXJ2ZWQgZHVlIHRvIGNvbmZsaWN0IHdpdGggUENJIEJ1cyAwMDAwOjAwDQoNClsgICAgMi42
MDQ1MDhdIGU4MjA6IHJlc2VydmUgUkFNIGJ1ZmZlciBbbWVtIDB4MDliZmYwMDAtMHgwYmZmZmZm
Zl0NCg0KWyAgICAyLjYxMDUwN10gZTgyMDogcmVzZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHgwYTIw
MDAwMC0weDBiZmZmZmZmXQ0KDQpbICAgIDIuNjE2NTA3XSBlODIwOiByZXNlcnZlIFJBTSBidWZm
ZXIgW21lbSAweGNhYmM5MDAwLTB4Y2JmZmZmZmZdDQoNClsgICAgMi42MjI1MDddIGU4MjA6IHJl
c2VydmUgUkFNIGJ1ZmZlciBbbWVtIDB4Y2RmZmZlYTgtMHhjZmZmZmZmZl0NCg0KWyAgICAyLjYy
ODUwN10gZTgyMDogcmVzZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHg4MGYzNDAwMDAtMHg4MGZmZmZm
ZmZdDQoNClsgICAgMi42MzQ1MjBdIHBjaSAwMDAwOjA0OjAwLjA6IHZnYWFyYjogc2V0dGluZyBh
cyBib290IFZHQSBkZXZpY2UNCg0KWyAgICAyLjYzNTUwMV0gcGNpIDAwMDA6MDQ6MDAuMDogdmdh
YXJiOiBicmlkZ2UgY29udHJvbCBwb3NzaWJsZQ0KDQpbICAgIDIuNjM1NTAxXSBwY2kgMDAwMDow
NDowMC4wOiB2Z2FhcmI6IFZHQSBkZXZpY2UgYWRkZWQ6IGRlY29kZXM9aW8rbWVtLG93bnM9bm9u
ZSxsb2Nrcz1ub25lDQoNClsgICAgMi42NTQ1MDddIHZnYWFyYjogbG9hZGVkDQoNClsgICAgMi42
NTc2MDZdIGNsb2Nrc291cmNlOiBTd2l0Y2hlZCB0byBjbG9ja3NvdXJjZSB0c2MtZWFybHkNCg0K
WyAgICAyLjY2MzE5N10gVkZTOiBEaXNrIHF1b3RhcyBkcXVvdF82LjYuMA0KDQpbICAgIDIuNjY3
MDU2XSBWRlM6IERxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTEyIChvcmRlciAwLCA0
MDk2IGJ5dGVzKQ0KDQpbICAgIDIuNjc0MDE2XSBwbnA6IFBuUCBBQ1BJIGluaXQNCg0KWyAgICAy
LjY3NzE4MV0gc3lzdGVtIDAwOjAwOiBbbWVtIDB4ZjAwMDAwMDAtMHhmN2ZmZmZmZl0gaGFzIGJl
ZW4gcmVzZXJ2ZWQNCg0KWyAgICAyLjY4Mzk4M10gc3lzdGVtIDAwOjAyOiBbaW8gIDB4MGEwMC0w
eDBhMGZdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAgMi42ODk4MzddIHN5c3RlbSAwMDowMjog
W2lvICAweDBhMTAtMHgwYTFmXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDIuNjk1ODE0XSBz
eXN0ZW0gMDA6MDI6IFtpbyAgMHgwYTIwLTB4MGEyZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAg
ICAyLjcwMjAyOV0gcG5wIDAwOjAzOiBbZG1hIDAgZGlzYWJsZWRdDQoNClsgICAgMi43MDYwNDhd
IHBucCAwMDowNDogW2RtYSAwIGRpc2FibGVkXQ0KDQpbICAgIDIuNzEwMDU4XSBzeXN0ZW0gMDA6
MDU6IFtpbyAgMHgwNGQwLTB4MDRkMV0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAyLjcxNTkx
MV0gc3lzdGVtIDAwOjA1OiBbaW8gIDB4MDQwYl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAy
LjcyMTI4Nl0gc3lzdGVtIDAwOjA1OiBbaW8gIDB4MDRkNl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0K
WyAgICAyLjcyNjY1M10gc3lzdGVtIDAwOjA1OiBbaW8gIDB4MGMwMC0weDBjMDFdIGhhcyBiZWVu
IHJlc2VydmVkDQoNClsgICAgMi43MzI2MzVdIHN5c3RlbSAwMDowNTogW2lvICAweDBjMTRdIGhh
cyBiZWVuIHJlc2VydmVkDQoNClsgICAgMi43MzgwMDldIHN5c3RlbSAwMDowNTogW2lvICAweDBj
NTAtMHgwYzUxXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDIuNzQzOTkwXSBzeXN0ZW0gMDA6
MDU6IFtpbyAgMHgwYzUyXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDIuNzQ5MzY0XSBzeXN0
ZW0gMDA6MDU6IFtpbyAgMHgwYzZjXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDIuNzU0NzQ0
XSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwYzZmXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDIu
NzYwMTA2XSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwY2QwLTB4MGNkMV0gaGFzIGJlZW4gcmVzZXJ2
ZWQNCg0KWyAgICAyLjc2NjA4NV0gc3lzdGVtIDAwOjA1OiBbaW8gIDB4MGNkMi0weDBjZDNdIGhh
cyBiZWVuIHJlc2VydmVkDQoNClsgICAgMi43NzIwNjZdIHN5c3RlbSAwMDowNTogW2lvICAweDBj
ZDQtMHgwY2Q1XSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDIuNzc4MDQ5XSBzeXN0ZW0gMDA6
MDU6IFtpbyAgMHgwY2Q2LTB4MGNkN10gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAyLjc4NDAz
MF0gc3lzdGVtIDAwOjA1OiBbaW8gIDB4MGNkOC0weDBjZGZdIGhhcyBiZWVuIHJlc2VydmVkDQoN
ClsgICAgMi43OTAwMDZdIHN5c3RlbSAwMDowNTogW2lvICAweDA4MDAtMHgwODlmXSBoYXMgYmVl
biByZXNlcnZlZA0KDQpbICAgIDIuNzk1OTg3XSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwYjAwLTB4
MGIwZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAyLjgwMTk3Ml0gc3lzdGVtIDAwOjA1OiBb
aW8gIDB4MGIyMC0weDBiM2ZdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAgMi44MDc5NDldIHN5
c3RlbSAwMDowNTogW2lvICAweDA5MDAtMHgwOTBmXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAg
IDIuODEzOTQwXSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwOTEwLTB4MDkxZl0gaGFzIGJlZW4gcmVz
ZXJ2ZWQNCg0KWyAgICAyLjgxOTkxMV0gc3lzdGVtIDAwOjA1OiBbbWVtIDB4ZmVjMDAwMDAtMHhm
ZWMwMGZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkDQoNClsgICAgMi44MjY5MzddIHN5c3RlbSAw
MDowNTogW21lbSAweGZlYzAxMDAwLTB4ZmVjMDFmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZA0K
DQpbICAgIDIuODMzOTQ2XSBzeXN0ZW0gMDA6MDU6IFttZW0gMHhmZWRjMDAwMC0weGZlZGMwZmZm
XSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDIuODQwNjE5XSBzeXN0ZW0gMDA6MDU6IFttZW0g
MHhmZWUwMDAwMC0weGZlZTAwZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDIuODQ3Mjkz
XSBzeXN0ZW0gMDA6MDU6IFttZW0gMHhmZWQ4MDAwMC0weGZlZDhmZmZmXSBjb3VsZCBub3QgYmUg
cmVzZXJ2ZWQNCg0KWyAgICAyLjg1NDMxMl0gc3lzdGVtIDAwOjA1OiBbbWVtIDB4ZmVjMTAwMDAt
MHhmZWMxMGZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkDQoNClsgICAgMi44NjEzMzVdIHN5c3Rl
bSAwMDowNTogW21lbSAweGZmMDAwMDAwLTB4ZmZmZmZmZmZdIGhhcyBiZWVuIHJlc2VydmVkDQoN
ClsgICAgMi44Njg2OTddIHBucDogUG5QIEFDUEk6IGZvdW5kIDYgZGV2aWNlcw0KDQpbICAgIDIu
ODgwODEzXSBQTS1UaW1lciBmYWlsZWQgY29uc2lzdGVuY3kgY2hlY2sgICgweGZmZmZmZikgLSBh
Ym9ydGluZy4NCg0KWyAgICAyLjg4NzE5N10gTkVUOiBSZWdpc3RlcmVkIFBGX0lORVQgcHJvdG9j
b2wgZmFtaWx5DQoNClsgICAgMi44OTIxNzBdIElQIGlkZW50cyBoYXNoIHRhYmxlIGVudHJpZXM6
IDY1NTM2IChvcmRlcjogNywgNTI0Mjg4IGJ5dGVzLCBsaW5lYXIpDQoNClsgICAgMi45MDAwNzld
IHRjcF9saXN0ZW5fcG9ydGFkZHJfaGFzaCBoYXNoIHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVy
OiAzLCAzMjc2OCBieXRlcywgbGluZWFyKQ0KDQpbICAgIDIuOTA4NTMzXSBUYWJsZS1wZXJ0dXJi
IGhhc2ggdGFibGUgZW50cmllczogNjU1MzYgKG9yZGVyOiA2LCAyNjIxNDQgYnl0ZXMsIGxpbmVh
cikNCg0KWyAgICAyLjkxNjMzM10gVENQIGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczog
MzI3NjggKG9yZGVyOiA2LCAyNjIxNDQgYnl0ZXMsIGxpbmVhcikNCg0KWyAgICAyLjkyNDMyM10g
VENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVzOiAzMjc2OCAob3JkZXI6IDgsIDEwNDg1NzYgYnl0
ZXMsIGxpbmVhcikNCg0KWyAgICAyLjkzMTgwOV0gVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVk
IChlc3RhYmxpc2hlZCAzMjc2OCBiaW5kIDMyNzY4KQ0KDQpbICAgIDIuOTM4MzQ5XSBVRFAgaGFz
aCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChvcmRlcjogNCwgNjU1MzYgYnl0ZXMsIGxpbmVhcikNCg0K
WyAgICAyLjk0NTA5OF0gVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChvcmRlcjog
NCwgNjU1MzYgYnl0ZXMsIGxpbmVhcikNCg0KWyAgICAyLjk1MjMyMF0gTkVUOiBSZWdpc3RlcmVk
IFBGX1VOSVgvUEZfTE9DQUwgcHJvdG9jb2wgZmFtaWx5DQoNClsgICAgMi45NTgyNTZdIFJQQzog
UmVnaXN0ZXJlZCBuYW1lZCBVTklYIHNvY2tldCB0cmFuc3BvcnQgbW9kdWxlLg0KDQpbICAgIDIu
OTY0MTExXSBSUEM6IFJlZ2lzdGVyZWQgdWRwIHRyYW5zcG9ydCBtb2R1bGUuDQoNClsgICAgMi45
Njg4NzRdIFJQQzogUmVnaXN0ZXJlZCB0Y3AgdHJhbnNwb3J0IG1vZHVsZS4NCg0KWyAgICAyLjk3
MzY0Ml0gUlBDOiBSZWdpc3RlcmVkIHRjcC13aXRoLXRscyB0cmFuc3BvcnQgbW9kdWxlLg0KDQpb
ICAgIDIuOTc5MTg3XSBSUEM6IFJlZ2lzdGVyZWQgdGNwIE5GU3Y0LjEgYmFja2NoYW5uZWwgdHJh
bnNwb3J0IG1vZHVsZS4NCg0KWyAgICAyLjk4Njg1OV0gcGNpIDAwMDA6MDA6MDIuMTogUENJIGJy
aWRnZSB0byBbYnVzIDAxXQ0KDQpbICAgIDIuOTkxNzgwXSBwY2kgMDAwMDowMDowMi4xOiAgIGJy
aWRnZSB3aW5kb3cgW21lbSAweGZmZTAwMDAwMDAtMHhmZmY4MGZmZmZmIDY0Yml0IHByZWZdDQoN
ClsgICAgMi45OTk5MTVdIHBjaSAwMDAwOjAwOjAyLjM6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMl0N
Cg0KWyAgICAzLjAwNDkzNV0gcGNpIDAwMDA6MDA6MDIuMzogICBicmlkZ2Ugd2luZG93IFttZW0g
MHhmZWEwMDAwMC0weGZlYWZmZmZmXQ0KDQpbICAgIDMuMDExNzg2XSBwY2kgMDAwMDowMDowMi40
OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDNdDQoNClsgICAgMy4wMTY4MDddIHBjaSAwMDAwOjAwOjAy
LjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZjAwMC0weGZmZmZdDQoNClsgICAgMy4wMjI5NzFd
IHBjaSAwMDAwOjAwOjAyLjQ6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU5MDAwMDAtMHhmZTlm
ZmZmZl0NCg0KWyAgICAzLjAyOTgxNF0gcGNpIDAwMDA6MDA6MDguMTogUENJIGJyaWRnZSB0byBb
YnVzIDA0XQ0KDQpbICAgIDMuMDM0ODM2XSBwY2kgMDAwMDowMDowOC4xOiAgIGJyaWRnZSB3aW5k
b3cgW2lvICAweGUwMDAtMHhlZmZmXQ0KDQpbICAgIDMuMDQwOTkzXSBwY2kgMDAwMDowMDowOC4x
OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlNDAwMDAwLTB4ZmU3ZmZmZmZdDQoNClsgICAgMy4w
NDc4MzRdIHBjaSAwMDAwOjAwOjA4LjE6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDAwMDAwMDAt
MHhlMDFmZmZmZiA2NGJpdCBwcmVmXQ0KDQpbICAgIDMuMDU1NjQyXSBwY2kgMDAwMDowMDowOC4y
OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDVdDQoNClsgICAgMy4wNjA2NjldIHBjaSAwMDAwOjAwOjA4
LjI6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU4MDAwMDAtMHhmZThmZmZmZl0NCg0KWyAgICAz
LjA2NzUxN10gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA0IFtpbyAgMHgwMDAwLTB4MDNhZiB3
aW5kb3ddDQoNClsgICAgMy4wNzM3NDNdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNSBbaW8g
IDB4MDNlMC0weDBjZjcgd2luZG93XQ0KDQpbICAgIDMuMDc5OTg3XSBwY2lfYnVzIDAwMDA6MDA6
IHJlc291cmNlIDYgW2lvICAweDAzYjAtMHgwM2RmIHdpbmRvd10NCg0KWyAgICAzLjA4NjIyOV0g
cGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA3IFtpbyAgMHgwZDAwLTB4ZmZmZiB3aW5kb3ddDQoN
ClsgICAgMy4wOTI0NjldIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgOCBbbWVtIDB4MDAwYTAw
MDAtMHgwMDBkZmZmZiB3aW5kb3ddDQoNClsgICAgMy4wOTk0MDNdIHBjaV9idXMgMDAwMDowMDog
cmVzb3VyY2UgOSBbbWVtIDB4ZDAwMDAwMDAtMHhmZWJmZmZmZiB3aW5kb3ddDQoNClsgICAgMy4x
MDYzMzFdIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgMTAgW21lbSAweGZlZTAwMDAwLTB4ZmZm
ZmZmZmYgd2luZG93XQ0KDQpbICAgIDMuMTEzMzU1XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNl
IDExIFttZW0gMHg4MzAwMDAwMDAtMHhmZmZmZmZmZmZmIHdpbmRvd10NCg0KWyAgICAzLjEyMDYz
MV0gcGNpX2J1cyAwMDAwOjAxOiByZXNvdXJjZSAyIFttZW0gMHhmZmUwMDAwMDAwLTB4ZmZmODBm
ZmZmZiA2NGJpdCBwcmVmXQ0KDQpbICAgIDMuMTI4MjYwXSBwY2lfYnVzIDAwMDA6MDI6IHJlc291
cmNlIDEgW21lbSAweGZlYTAwMDAwLTB4ZmVhZmZmZmZdDQoNClsgICAgMy4xMzQ1ODldIHBjaV9i
dXMgMDAwMDowMzogcmVzb3VyY2UgMCBbaW8gIDB4ZjAwMC0weGZmZmZdDQoNClsgICAgMy4xNDAy
MTZdIHBjaV9idXMgMDAwMDowMzogcmVzb3VyY2UgMSBbbWVtIDB4ZmU5MDAwMDAtMHhmZTlmZmZm
Zl0NCg0KWyAgICAzLjE0NjU0NV0gcGNpX2J1cyAwMDAwOjA0OiByZXNvdXJjZSAwIFtpbyAgMHhl
MDAwLTB4ZWZmZl0NCg0KWyAgICAzLjE1MjE3OV0gcGNpX2J1cyAwMDAwOjA0OiByZXNvdXJjZSAx
IFttZW0gMHhmZTQwMDAwMC0weGZlN2ZmZmZmXQ0KDQpbICAgIDMuMTU4NTA2XSBwY2lfYnVzIDAw
MDA6MDQ6IHJlc291cmNlIDIgW21lbSAweGQwMDAwMDAwLTB4ZTAxZmZmZmYgNjRiaXQgcHJlZl0N
Cg0KWyAgICAzLjE2NTc5NF0gcGNpX2J1cyAwMDAwOjA1OiByZXNvdXJjZSAxIFttZW0gMHhmZTgw
MDAwMC0weGZlOGZmZmZmXQ0KDQpbICAgIDMuMTcyMTg1XSBwY2kgMDAwMDowMTowMC4wOiBDTFMg
bWlzbWF0Y2ggKDY0ICE9IDQ4NCksIHVzaW5nIDY0IGJ5dGVzDQoNClsgICAgMy4xNzg3MTZdIHBj
aSAwMDAwOjA0OjAwLjE6IEQwIHBvd2VyIHN0YXRlIGRlcGVuZHMgb24gMDAwMDowNDowMC4wDQoN
ClsgICAgMy4xODUxMTldIHBjaSAwMDAwOjA0OjAwLjM6IGV4dGVuZGluZyBkZWxheSBhZnRlciBw
b3dlci1vbiBmcm9tIEQzaG90IHRvIDIwIG1zZWMNCg0KWyAgICAzLjE5MjkyMF0gcGNpIDAwMDA6
MDQ6MDAuNDogZXh0ZW5kaW5nIGRlbGF5IGFmdGVyIHBvd2VyLW9uIGZyb20gRDNob3QgdG8gMjAg
bXNlYw0KDQpbICAgIDMuMjAwNDkxXSBQQ0ktRE1BOiBVc2luZyBzb2Z0d2FyZSBib3VuY2UgYnVm
ZmVyaW5nIGZvciBJTyAoU1dJT1RMQikNCg0KWyAgICAzLjIwMDc4N10gVW5wYWNraW5nIGluaXRy
YW1mcy4uLg0KDQpbICAgIDMuMjA2OTEzXSBzb2Z0d2FyZSBJTyBUTEI6IG1hcHBlZCBbbWVtIDB4
MDAwMDAwMDBjNmJjOTAwMC0weDAwMDAwMDAwY2FiYzkwMDBdICg2NE1CKQ0KDQpbICAgIDMuMjA2
OTMzXSBjbG9ja3NvdXJjZTogdHNjOiBtYXNrOiAweGZmZmZmZmZmZmZmZmZmZmYgbWF4X2N5Y2xl
czogMHgyOWI5M2I0YmIyMSwgbWF4X2lkbGVfbnM6IDQ0MDc5NTI4ODM0NiBucw0KDQpbICAgIDMu
MjI4NDYzXSBjbG9ja3NvdXJjZTogU3dpdGNoZWQgdG8gY2xvY2tzb3VyY2UgdHNjDQoNClsgICAg
My4yMzQ1NjFdIEluaXRpYWxpc2Ugc3lzdGVtIHRydXN0ZWQga2V5cmluZ3MNCg0KWyAgICAzLjIz
OTA3MV0gd29ya2luZ3NldDogdGltZXN0YW1wX2JpdHM9NTYgbWF4X29yZGVyPTIwIGJ1Y2tldF9v
cmRlcj0wDQoNClsgICAgMy4yNDU2NjZdIE5GUzogUmVnaXN0ZXJpbmcgdGhlIGlkX3Jlc29sdmVy
IGtleSB0eXBlDQoNClsgICAgMy4yNTA2NjJdIEtleSB0eXBlIGlkX3Jlc29sdmVyIHJlZ2lzdGVy
ZWQNCg0KWyAgICAzLjI1NDg5M10gS2V5IHR5cGUgaWRfbGVnYWN5IHJlZ2lzdGVyZWQNCg0KWyAg
ICAzLjI1OTA0NF0gOXA6IEluc3RhbGxpbmcgdjlmcyA5cDIwMDAgZmlsZSBzeXN0ZW0gc3VwcG9y
dA0KDQpbICAgIDMuMjczNzEyXSBLZXkgdHlwZSBhc3ltbWV0cmljIHJlZ2lzdGVyZWQNCg0KWyAg
ICAzLjI3Nzc1Nl0gQXN5bW1ldHJpYyBrZXkgcGFyc2VyICd4NTA5JyByZWdpc3RlcmVkDQoNClsg
ICAgMy4yODA1MDRdIEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogMjA3ODM2Sw0KDQpbICAgIDMuMjgy
NzE0XSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40IGxv
YWRlZCAobWFqb3IgMjUwKQ0KDQpbICAgIDMuMjk0MzEyXSBpbyBzY2hlZHVsZXIgbXEtZGVhZGxp
bmUgcmVnaXN0ZXJlZA0KDQpbICAgIDMuMjk4ODk1XSBpbyBzY2hlZHVsZXIga3liZXIgcmVnaXN0
ZXJlZA0KDQpbICAgIDMuMzAzNDExXSBwY2llcG9ydCAwMDAwOjAwOjAyLjE6IFBNRTogU2lnbmFs
aW5nIHdpdGggSVJRIDQzDQoNClsgICAgMy4zMDkzNzBdIHBjaWVwb3J0IDAwMDA6MDA6MDIuMzog
UE1FOiBTaWduYWxpbmcgd2l0aCBJUlEgNDQNCg0KWyAgICAzLjMxNTMwMl0gcGNpZXBvcnQgMDAw
MDowMDowMi40OiBQTUU6IFNpZ25hbGluZyB3aXRoIElSUSA0NQ0KDQpbICAgIDMuMzIxMjMwXSBw
Y2llcG9ydCAwMDAwOjAwOjA4LjE6IFBNRTogU2lnbmFsaW5nIHdpdGggSVJRIDQ2DQoNClsgICAg
My4zMjcxODJdIHBjaWVwb3J0IDAwMDA6MDA6MDguMjogUE1FOiBTaWduYWxpbmcgd2l0aCBJUlEg
NDcNCg0KWyAgICAzLjMzMzA2NF0gaW5wdXQ6IFBvd2VyIEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhT
WVNUTTowMC9MTlhTWUJVUzowMC9QTlAwQzBDOjAwL2lucHV0L2lucHV0MA0KDQpbICAgIDMuMzQx
MzUzXSBBQ1BJOiBidXR0b246IFBvd2VyIEJ1dHRvbiBbUFdSQl0NCg0KWyAgICAzLjM0NTc2OV0g
aW5wdXQ6IFBvd2VyIEJ1dHRvbiBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhQV1JCTjowMC9p
bnB1dC9pbnB1dDENCg0KWyAgICAzLjM1MzI2OF0gQUNQSTogYnV0dG9uOiBQb3dlciBCdXR0b24g
W1BXUkZdDQoNClsgICAgMy4zNTc2NTldIEFDUEk6IHZpZGVvOiBWaWRlbyBEZXZpY2UgW1ZHQV0g
KG11bHRpLWhlYWQ6IHllcyAgcm9tOiBubyAgcG9zdDogbm8pDQoNClsgICAgMy4zNjUxNjZdIGlu
cHV0OiBWaWRlbyBCdXMgYXMgL2RldmljZXMvTE5YU1lTVE06MDAvTE5YU1lCVVM6MDAvUE5QMEEw
ODowMC9kZXZpY2U6MGUvTE5YVklERU86MDAvaW5wdXQvaW5wdXQyDQoNClsgICAgMy4zNzUyOTFd
IFtGaXJtd2FyZSBCdWddOiBBQ1BJIE1XQUlUIEMtc3RhdGUgMHgwIG5vdCBzdXBwb3J0ZWQgYnkg
SFcgKDB4MCkNCg0KWyAgICAzLjM4MjI3Nl0gQUNQSTogXF9TQl8uUExURi5QMDAwOiBGb3VuZCAz
IGlkbGUgc3RhdGVzDQoNClsgICAgMy4zODc1NDFdIFtGaXJtd2FyZSBCdWddOiBBQ1BJIE1XQUlU
IEMtc3RhdGUgMHgwIG5vdCBzdXBwb3J0ZWQgYnkgSFcgKDB4MCkNCg0KWyAgICAzLjM5NDU3OV0g
QUNQSTogXF9TQl8uUExURi5QMDAxOiBGb3VuZCAzIGlkbGUgc3RhdGVzDQoNClsgICAgMy4zOTk4
NDNdIFtGaXJtd2FyZSBCdWddOiBBQ1BJIE1XQUlUIEMtc3RhdGUgMHgwIG5vdCBzdXBwb3J0ZWQg
YnkgSFcgKDB4MCkNCg0KWyAgICAzLjQwNjg4NF0gQUNQSTogXF9TQl8uUExURi5QMDAyOiBGb3Vu
ZCAzIGlkbGUgc3RhdGVzDQoNClsgICAgMy40MTIzOTldIHRoZXJtYWwgTE5YVEhFUk06MDA6IHJl
Z2lzdGVyZWQgYXMgdGhlcm1hbF96b25lMA0KDQpbICAgIDMuNDE3OTg5XSBBQ1BJOiB0aGVybWFs
OiBUaGVybWFsIFpvbmUgW1RIUk1dICgyMCBDKQ0KDQpbICAgIDMuNDIzMTc0XSB0aGVybWFsIExO
WFRIRVJNOjAxOiByZWdpc3RlcmVkIGFzIHRoZXJtYWxfem9uZTENCg0KWyAgICAzLjQyODgxN10g
QUNQSTogdGhlcm1hbDogVGhlcm1hbCBab25lIFtXRFRGXSAoMCBDKQ0KDQpbICAgIDMuNDM0MjI5
XSB4ZW46eGVuX2V2dGNobjogRXZlbnQtY2hhbm5lbCBkZXZpY2UgaW5zdGFsbGVkDQoNClsgICAg
My40Mzk3NzBdIHhlbl9tY2Vsb2c6IEZhaWxlZCB0byBnZXQgQ1BVIG51bWJlcnMNCg0KWyAgICAz
LjQ0NDQ2MV0geGVuX3BjaWJhY2s6IGJhY2tlbmQgaXMgdnBjaQ0KDQpbICAgIDMuNDQ4NTc5XSB4
ZW5fYWNwaV9wcm9jZXNzb3I6IFVwbG9hZGluZyBYZW4gcHJvY2Vzc29yIFBNIGluZm8NCg0KWyAg
ICAzLjQ1NTMxNF0gU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJp
bmcgZW5hYmxlZA0KDQpbICAgIDMuNDYxNjU3XSAwMDowNDogdHR5UzEgYXQgSS9PIDB4MmY4IChp
cnEgPSAzLCBiYXNlX2JhdWQgPSAxMTUyMDApIGlzIGEgMTY1NTBBDQoNClsgICAgMy40NjkyNTNd
IGhwZXRfYWNwaV9hZGQ6IG5vIGFkZHJlc3Mgb3IgaXJxcyBpbiBfQ1JTDQoNClsgICAgMy40NzQy
ODBdIE5vbi12b2xhdGlsZSBtZW1vcnkgZHJpdmVyIHYxLjMNCg0KWyAgICAzLjQ3ODQ4Ml0gTGlu
dXggYWdwZ2FydCBpbnRlcmZhY2UgdjAuMTAzDQoNClsgICAgMy40ODMwNThdIEFDUEk6IGJ1cyB0
eXBlIGRybV9jb25uZWN0b3IgcmVnaXN0ZXJlZA0KDQpbICAgIDMuNDg5MTAxXSBsb29wOiBtb2R1
bGUgbG9hZGVkDQoNClsgICAgMy40OTI1MjddIGFoY2kgMDAwMDowNTowMC4wOiB2ZXJzaW9uIDMu
MA0KDQpbICAgIDMuNDkyNjQwXSBudm1lIG52bWUwOiBwY2kgZnVuY3Rpb24gMDAwMDowMjowMC4w
DQoNClsgICAgMy40OTY3MDZdIGEoWEVOKSBbICAgMTMuMDI5Njc0XSBhcmNoL3g4Ni9odm0vZW11
bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgcmVhZCBmcm9tIDB4ZmVhMDMwMGMgc2l6
ZSA0DQpoY2kgMDAwMDowNTowMC4wKFhFTikgWyAgIDEzLjAzOTYzNl0gYXJjaC94ODYvaHZtL2Vt
dWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwMDAgc2l6
ZSA0DQo6IEFIQ0kgdmVycyAwMDAxKFhFTikgWyAgIDEzLjA0OTUxNl0gYXJjaC94ODYvaHZtL2Vt
dWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwMDQgc2l6
ZSA0DQouMDMwMSwgMzIgY29tbWFuKFhFTikgWyAgIDEzLjA1OTQwMF0gYXJjaC94ODYvaHZtL2Vt
dWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwMDggc2l6
ZSA0DQpkIHNsb3RzLCA2IEdicHMsKFhFTikgWyAgIDEzLjA2OTI3OV0gYXJjaC94ODYvaHZtL2Vt
dWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlYTAzMDA4IHNp
emUgNA0KIFNBVEEgbW9kZQ0KDQooWEVOKSBbICAgMTMuMDc4OTg5XSBhcmNoL3g4Ni9odm0vZW11
bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzAwYyBzaXpl
IDQNCihYRU4pIFsgICAxMy4wODc0NzldIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEg
dW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDFjIHNpemUgNA0KWyAgICAzLjU2MDUx
OV0gYShYRU4pIFsgICAxMy4wOTczNjBdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEg
dW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDJjIHNpemUgNA0KaGNpIDAwMDA6MDU6
MDAuMChYRU4pIFsgICAxMy4xMDcyMzZdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEg
dW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDNjIHNpemUgNA0KOiAxLzEgcG9ydHMg
aW1wbChYRU4pIFsgICAxMy4xMTcxMTldIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEg
dW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDRjIHNpemUgNA0KZW1lbnRlZCAocG9y
dCBtYShYRU4pIFsgICAxMy4xMjcwMDJdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEg
dW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDVjIHNpemUgNA0Kc2sgMHgxKQ0KDQoo
WEVOKSBbICAgMTMuMTM2MzYwXSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFu
ZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzA2YyBzaXplIDQNCihYRU4pIFsgICAxMy4xNDQ4
NTVdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0
ZSB0byAweGZlYTAzMDdjIHNpemUgNA0KWyAgICAzLjYxNzg4OF0gYShYRU4pIFsgICAxMy4xNTQ3
MzVdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0
ZSB0byAweGZlYTAzMDhjIHNpemUgNA0KaGNpIDAwMDA6MDU6MDAuMChYRU4pIFsgICAxMy4xNjQ2
MTJdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0
ZSB0byAweGZlYTAzMDljIHNpemUgNA0KOiBmbGFnczogNjRiaXQgbihYRU4pIFsgICAxMy4xNzQ0
OTJdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0
ZSB0byAweGZlYTAzMGFjIHNpemUgNA0KY3Egc250ZiBpbGNrIHBtIChYRU4pIFsgICAxMy4xODQz
NzFdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0
ZSB0byAweGZlYTAzMGJjIHNpemUgNA0KbGVkIGNsbyBvbmx5IHBtcChYRU4pIFsgICAxMy4xOTQy
NTFdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0
ZSB0byAweGZlYTAzMGNjIHNpemUgNA0KIGZicyBwaW8gc2x1bSBwYShYRU4pIFsgICAxMy4yMDQx
MzNdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0
ZSB0byAweGZlYTAzMGRjIHNpemUgNA0KcnQNCg0KKFhFTikgWyAgIDEzLjIxMzE0Nl0gYXJjaC94
ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVh
MDMwZWMgc2l6ZSA0DQooWEVOKSBbICAgMTMuMjIxNjM5XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5j
OjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzBmYyBzaXplIDQNCihY
RU4pIFsgICAxMy4yMzAxMzBdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5k
bGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMTBjIHNpemUgNA0KKFhFTikgWyAgIDEzLjIzODYy
OF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRl
IHRvIDB4ZmVhMDMxMWMgc2l6ZSA0DQooWEVOKSBbICAgMTMuMjQ3MTE5XSBhcmNoL3g4Ni9odm0v
ZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzEyYyBz
aXplIDQNCihYRU4pIFsgICAxMy4yNTU2MTBdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQw
djEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMTNjIHNpemUgNA0KKFhFTikgWyAg
IDEzLjI2NDEwNV0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVt
b3J5IHdyaXRlIHRvIDB4ZmVhMDMxNGMgc2l6ZSA0DQooWEVOKSBbICAgMTMuMjcyNTk5XSBhcmNo
L3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhm
ZWEwMzE1YyBzaXplIDQNCihYRU4pIFsgICAxMy4yODEwOTBdIGFyY2gveDg2L2h2bS9lbXVsYXRl
LmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMTZjIHNpemUgNA0K
KFhFTikgWyAgIDEzLjI4OTU4Ml0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhh
bmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMxN2Mgc2l6ZSA0DQooWEVOKSBbICAgMTMuMjk4
MDgwXSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3Jp
dGUgdG8gMHhmZWEwMzE4YyBzaXplIDQNCihYRU4pIFsgICAxMy4zMDY1NzVdIGFyY2gveDg2L2h2
bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMTlj
IHNpemUgNA0KKFhFTikgWyAgIDEzLjMxNTA2Ml0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6
ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMxYWMgc2l6ZSA0DQooWEVOKSBb
ICAgMTMuMzIzNTU5XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBt
ZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzFiYyBzaXplIDQNCihYRU4pIFsgICAxMy4zMzIwNTJdIGFy
Y2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAw
eGZlYTAzMWNjIHNpemUgNA0KKFhFTikgWyAgIDEzLjM0MDU0Ml0gYXJjaC94ODYvaHZtL2VtdWxh
dGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMxZGMgc2l6ZSA0
DQpbICAgIDMuODEzNjA2XSBzKFhFTikgWyAgIDEzLjM1MDQyMl0gYXJjaC94ODYvaHZtL2VtdWxh
dGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMxZWMgc2l6ZSA0
DQpjc2kgaG9zdDA6IGFoY2kNCihYRU4pIFsgICAxMy4zNjAzMDJdIGFyY2gveDg2L2h2bS9lbXVs
YXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMWZjIHNpemUg
NA0KDQooWEVOKSBbICAgMTMuMzY4OTcyXSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYx
IHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzIwYyBzaXplIDQNClsgICAgMy44NTA1
MjNdIGF0YTE6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmZTgwMTAwMCBwb3IoWEVO
KSBbICAgMTMuMzgzMDE0XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxl
ZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzAwMCBzaXplIDQNCihYRU4pIFsgICAxMy4zOTE1MDJd
IGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0
byAweGZlYTAzMDA0IHNpemUgNA0KdCAweGZlODAxMTAwIGlycShYRU4pIFsgICAxMy40MDEzODVd
IGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0
byAweGZlYTAzMDA4IHNpemUgNA0KKFhFTikgWyAgIDEzLjQwOTg3N10gYXJjaC94ODYvaHZtL2Vt
dWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlYTAzMDA4IHNp
emUgNA0KIDUwIGxwbS1wb2wgMw0KDQooWEVOKSBbICAgMTMuNDE5ODQ1XSBhcmNoL3g4Ni9odm0v
ZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzAwMCBz
aXplIDQNCihYRU4pIFsgICAxMy40MjgzMzldIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQw
djEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDA0IHNpemUgNA0KKFhFTikgWyAg
IDEzLjQzNjgzMV0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVt
b3J5IHdyaXRlIHRvIDB4ZmVhMDMwMDggc2l6ZSA0DQooWEVOKSBbICAgMTMuNDQ1MzIyXSBhcmNo
L3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgcmVhZCBmcm9tIDB4
ZmVhMDMwMDggc2l6ZSA0DQooWEVOKSBbICAgMTMuNDUzOTA0XSBhcmNoL3g4Ni9odm0vZW11bGF0
ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzAwYyBzaXplIDQN
ClsgICAgMy45MzU1NDZdIGFoY2kgMDAwMDowNTowMC4xOiBBSENJIHZlcnMgMDAwMS4wMzAxLCAz
MiBjb21tYW5kIHNsb3RzLCA2IEdicHMsIFNBVEEgbW9kZQ0KDQpbICAgIDMuOTQzNDk2XSBhaGNp
IDAwMDA6MDU6MDAuMTogMS8xIHBvcnRzIGltcGxlbWVudGVkIChwb3J0IG1hc2sgMHgxKQ0KDQpb
ICAgIDMuOTQ5ODk3XSBhaGNpIDAwMDA6MDU6MDAuMTogZmxhZ3M6IDY0Yml0IG5jcSBzbnRmIGls
Y2sgcG0gbGVkIGNsbyBvbmx5IHBtcCBmYnMgcGlvIHNsdW0gcGFydA0KDQpbICAgIDMuOTU5MDI3
XSBzY3NpIGhvc3QxOiBhaGNpDQoNClsgICAgMy45NjE4NjhdIGF0YTI6IFNBVEEgbWF4IFVETUEv
MTMzIGFiYXIgbTIwNDhAMHhmZTgwMDAwMCBwb3J0IDB4ZmU4MDAxMDAgaXJxIDU0IGxwbS1wb2wg
Mw0KDQpbICAgIDMuOTcwNDQzXSBSb3VuZGluZyBkb3duIGFsaWduZWQgbWF4X3NlY3RvcnMgZnJv
bSA0Mjk0OTY3Mjk1IHRvIDQyOTQ5NjcyODgNCg0KWyAgICAzLjk3NzQ3NV0gZGJfcm9vdDogY2Fu
bm90IG9wZW46IC9ldGMvdGFyZ2V0DQoNClsgICAgMy45ODE4NjddIHR1bjogVW5pdmVyc2FsIFRV
Ti9UQVAgZGV2aWNlIGRyaXZlciwgMS42DQoNClsgICAgMy45ODcyNjddIGUxMDA6IEludGVsKFIp
IFBSTy8xMDAgTmV0d29yayBEcml2ZXINCg0KWyAgICAzLjk5MTkwMl0gZTEwMDogQ29weXJpZ2h0
KGMpIDE5OTktMjAwNiBJbnRlbCBDb3Jwb3JhdGlvbg0KDQpbICAgIDMuOTk3NDUzXSBlMTAwMDog
SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBEcml2ZXINCg0KWyAgICA0LjAwMjM4OV0gZTEwMDA6
IENvcHlyaWdodCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBvcmF0aW9uLg0KDQpbICAgIDQuMDA4
MjAxXSBlMTAwMGU6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgRHJpdmVyDQoNClsgICAgNC4w
MTMyMjNdIGUxMDAwZTogQ29weXJpZ2h0KGMpIDE5OTkgLSAyMDE1IEludGVsIENvcnBvcmF0aW9u
Lg0KDQpbICAgIDQuMDE5MjEwXSBJbnRlbChSKSAyLjVHIEV0aGVybmV0IExpbnV4IERyaXZlcg0K
DQpbICAgIDQuMDIzNzkxXSBDb3B5cmlnaHQoYykgMjAxOCBJbnRlbCBDb3Jwb3JhdGlvbi4NCg0K
WyAgICA0LjAyODQ3OV0gc2t5MjogZHJpdmVyIHZlcnNpb24gMS4zMA0KDQooWEVOKSBbICAgMTMu
NTY1OTI5XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkg
cmVhZCBmcm9tIDB4ZmU5MTAwMGMgc2l6ZSA0DQooWEVOKSBbICAgMTMuNTc0NTEyXSBhcmNoL3g4
Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTkx
MDAwMCBzaXplIDQNCihYRU4pIFsgICAxMy41ODMwMDNdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6
NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlOTEwMDA0IHNpemUgNA0KKFhF
TikgWyAgIDEzLjU5MTQ5N10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRs
ZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU5MTAwMDggc2l6ZSA0DQooWEVOKSBbICAgMTMuNTk5OTkw
XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgcmVhZCBm
cm9tIDB4ZmU5MTAwMDggc2l6ZSA0DQooWEVOKSBbICAgMTMuNjA4NTY4XSBhcmNoL3g4Ni9odm0v
ZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTkxMDAwYyBz
aXplIDQNCihYRU4pIFsgICAxMy42MTcwNjVdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQw
djAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlOTEwMDFjIHNpemUgNA0KKFhFTikgWyAg
IDEzLjYyNTcwM10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVt
b3J5IHdyaXRlIHRvIDB4ZmU5MTAwMmMgc2l6ZSA0DQooWEVOKSBbICAgMTMuNjM0MTk3XSBhcmNo
L3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhm
ZTkxMDAzYyBzaXplIDQNCihYRU4pIFsgICAxMy42NDI2OTFdIGFyY2gveDg2L2h2bS9lbXVsYXRl
LmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlOTEwMDRjIHNpemUgNA0K
KFhFTikgWyAgIDEzLjY1MTE4Nl0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhh
bmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU5MTAwNWMgc2l6ZSA0DQooWEVOKSBbICAgMTMuNjU5
NjgwXSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3Jp
dGUgdG8gMHhmZTkxMDA2YyBzaXplIDQNCihYRU4pIFsgICAxMy42NjgxNjhdIGFyY2gveDg2L2h2
bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlOTEwMDdj
IHNpemUgNA0KKFhFTikgWyAgIDEzLjY3NjY2M10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6
ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU5MTAwOGMgc2l6ZSA0DQooWEVOKSBb
ICAgMTMuNjg1MTU0XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBt
ZW1vcnkgd3JpdGUgdG8gMHhmZTkxMDA5YyBzaXplIDQNCihYRU4pIFsgICAxMy42OTM2NTFdIGFy
Y2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAw
eGZlOTEwMGFjIHNpemUgNA0KKFhFTikgWyAgIDEzLjcwMjE0Nl0gYXJjaC94ODYvaHZtL2VtdWxh
dGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU5MTAwYmMgc2l6ZSA0
DQooWEVOKSBbICAgMTMuNzEwNjM0XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVu
aGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTkxMDBjYyBzaXplIDQNCihYRU4pIFsgICAxMy43
MTkxMzFdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3
cml0ZSB0byAweGZlOTEwMGRjIHNpemUgNA0KKFhFTikgWyAgIDEzLjcyNzYyNl0gYXJjaC94ODYv
aHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU5MTAw
ZWMgc2l6ZSA0DQooWEVOKSBbICAgMTMuNzM2MTE4XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQx
NzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTkxMDBmYyBzaXplIDQNCihYRU4p
IFsgICAxMy43NDQ2MDldIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVk
IG1lbW9yeSB3cml0ZSB0byAweGZlOTEwMTBjIHNpemUgNA0KKFhFTikgWyAgIDEzLjc1MzEwM10g
YXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRv
IDB4ZmU5MTAxMWMgc2l6ZSA0DQooWEVOKSBbICAgMTMuNzYxNTk0XSBhcmNoL3g4Ni9odm0vZW11
bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTkxMDEyYyBzaXpl
IDQNCihYRU4pIFsgICAxMy43NzAwOTJdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAg
dW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlOTEwMTNjIHNpemUgNA0KKFhFTikgWyAgIDEz
Ljc3ODU4Nl0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5
IHdyaXRlIHRvIDB4ZmU5MTAxNGMgc2l6ZSA0DQooWEVOKSBbICAgMTMuNzg3MDc0XSBhcmNoL3g4
Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTkx
MDE1YyBzaXplIDQNCihYRU4pIFsgICAxMy43OTU1NjldIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6
NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlOTEwMTZjIHNpemUgNA0KWyAg
ICA0LjI2MTEwMl0gYShYRU4pIFsgICAxMy44MDU0NTBdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6
NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlOTEwMTdjIHNpemUgNA0KdGEx
OiBTQVRBIGxpbmsgZChYRU4pIFsgICAxMy44MTUzMjddIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6
NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlOTEwMThjIHNpemUgNA0Kb3du
IChTU3RhdHVzIDAgUyhYRU4pIFsgICAxMy44MjUyMDddIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6
NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlOTEwMTljIHNpemUgNA0KQ29u
dHJvbCAzMDApDQoNCihYRU4pIFsgICAxMy44MzUwMDBdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6
NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlOTEwMWFjIHNpemUgNA0KKFhF
TikgWyAgIDEzLjg0MzQ5NF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRs
ZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU5MTAxYmMgc2l6ZSA0DQpbICAgIDQuMjk2ODgxXSBhKFhF
TikgWyAgIDEzLjg1MzM3NV0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRs
ZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU5MTAxY2Mgc2l6ZSA0DQp0YTI6IFNBVEEgbGluayBkKFhF
TikgWyAgIDEzLjg2MzI1N10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRs
ZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU5MTAxZGMgc2l6ZSA0DQpvd24gKFNTdGF0dXMgMCBTKFhF
TikgWyAgIDEzLjg3MzEzNl0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRs
ZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU5MTAxZWMgc2l6ZSA0DQpDb250cm9sIDMwMCkNCg0KKFhF
TikgWyAgIDEzLjg4MjkzMl0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRs
ZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU5MTAxZmMgc2l6ZSA0DQpbICAgIDQuMzY0ODg0XSBtb2Rw
cm9iZSAoNzUpIHVzZWQgZ3JlYXRlc3Qgc3RhY2sgZGVwdGg6IDE0MTg0IGJ5dGVzIGxlZnQNCg0K
WyAgICA0LjM2NTA4M10gcjgxNjkgMDAwMDowMzowMC4wIGV0aDA6IFJUTDgxMjVCLCBkYzo5Yzo1
MjoyNzphZTpjNCwgWElEIDY0MSwgSVJRIDU2DQoNClsgICAgNC4zNzg3OTldIHI4MTY5IDAwMDA6
MDM6MDAuMCBldGgwOiBqdW1ibyBmZWF0dXJlcyBbZnJhbWVzOiA5MTk0IGJ5dGVzLCB0eCBjaGVj
a3N1bW1pbmc6IGtvXQ0KDQpbICAgIDQuMzg3Mzg2XSB4ZW5fbmV0ZnJvbnQ6IEluaXRpYWxpc2lu
ZyBYZW4gdmlydHVhbCBldGhlcm5ldCBkcml2ZXINCg0KWyAgICA0LjM5Mzc5OV0geGhjaV9oY2Qg
MDAwMDowNDowMC4zOiB4SENJIEhvc3QgQ29udHJvbGxlcg0KDQpbICAgIDQuMzk5MDE4XSB4aGNp
X2hjZCAwMDAwOjA0OjAwLjM6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBu
dW1iZXIgMQ0KDQpbICAgIDQuNDA2NTAyXSB4aGNpX2hjZCAwMDAwOjA0OjAwLjM6IGhjYyBwYXJh
bXMgMHgwMjY4ZmZlNSBoY2kgdmVyc2lvbiAweDExMCBxdWlya3MgMHgwMDAwMDIwMDAwMDAwMDEw
DQoNCihYRU4pIFsgICAxMy45NDI1NTldIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAg
dW5oYW5kbGVkIG1lbW9yeSByZWFkIGZyb20gMHhmZTVmZTAwYyBzaXplIDQNCihYRU4pIFsgICAx
My45NTExMzddIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9y
eSByZWFkIGZyb20gMHhmZTVmZTAxYyBzaXplIDQNCihYRU4pIFsgICAxMy45NTk3MTldIGFyY2gv
eDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSByZWFkIGZyb20gMHhm
ZTVmZTAyYyBzaXplIDQNCihYRU4pIFsgICAxMy45NjgyOTddIGFyY2gveDg2L2h2bS9lbXVsYXRl
LmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSByZWFkIGZyb20gMHhmZTVmZTAzYyBzaXplIDQN
CihYRU4pIFsgICAxMy45NzY4NzddIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5o
YW5kbGVkIG1lbW9yeSByZWFkIGZyb20gMHhmZTVmZTA0YyBzaXplIDQNCihYRU4pIFsgICAxMy45
ODU0NThdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3
cml0ZSB0byAweGZlNWZlMDAwIHNpemUgNA0KKFhFTikgWyAgIDEzLjk5Mzk1M10gYXJjaC94ODYv
aHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU1ZmUw
MDQgc2l6ZSA0DQooWEVOKSBbICAgMTQuMDAyNDQ3XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQx
NzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTVmZTAwOCBzaXplIDQNCihYRU4p
IFsgICAxNC4wMTA5MzldIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVk
IG1lbW9yeSByZWFkIGZyb20gMHhmZTVmZTAwOCBzaXplIDQNCihYRU4pIFsgICAxNC4wMTk1MTdd
IGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0
byAweGZlNWZlMDEwIHNpemUgNA0KKFhFTikgWyAgIDE0LjAyODAxNF0gYXJjaC94ODYvaHZtL2Vt
dWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU1ZmUwMTQgc2l6
ZSA0DQooWEVOKSBbICAgMTQuMDM2NTA0XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYw
IHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTVmZTAxOCBzaXplIDQNCihYRU4pIFsgICAx
NC4wNDQ5OTddIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9y
eSByZWFkIGZyb20gMHhmZTVmZTAxOCBzaXplIDQNCihYRU4pIFsgICAxNC4wNTM1ODFdIGFyY2gv
eDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZl
NWZlMDIwIHNpemUgNA0KKFhFTikgWyAgIDE0LjA2MjA3NV0gYXJjaC94ODYvaHZtL2VtdWxhdGUu
Yzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU1ZmUwMjQgc2l6ZSA0DQoo
WEVOKSBbICAgMTQuMDcwNTY2XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFu
ZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTVmZTAyOCBzaXplIDQNCihYRU4pIFsgICAxNC4wNzkw
NTddIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSByZWFk
IGZyb20gMHhmZTVmZTAyOCBzaXplIDQNCihYRU4pIFsgICAxNC4wODc2MzldIGFyY2gveDg2L2h2
bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNWZlMDMw
IHNpemUgNA0KKFhFTikgWyAgIDE0LjA5NjEzMF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6
ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU1ZmUwMzQgc2l6ZSA0DQooWEVOKSBb
ICAgMTQuMTA0NjI3XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBt
ZW1vcnkgd3JpdGUgdG8gMHhmZTVmZTAzOCBzaXplIDQNCihYRU4pIFsgICAxNC4xMTMxMTddIGFy
Y2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSByZWFkIGZyb20g
MHhmZTVmZTAzOCBzaXplIDQNCihYRU4pIFsgICAxNC4xMjE2OTddIGFyY2gveDg2L2h2bS9lbXVs
YXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNWZlMDQwIHNpemUg
NA0KKFhFTikgWyAgIDE0LjEzMDE5Ml0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1
bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU1ZmUwNDQgc2l6ZSA0DQooWEVOKSBbICAgMTQu
MTM4NjgzXSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkg
d3JpdGUgdG8gMHhmZTVmZTA0OCBzaXplIDQNCihYRU4pIFsgICAxNC4xNDcxNzZdIGFyY2gveDg2
L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSByZWFkIGZyb20gMHhmZTVm
ZTA0OCBzaXplIDQNCihYRU4pIFsgICAxNC4xNTU3NTZdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6
NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNWZlMDBjIHNpemUgNA0KKFhF
TikgWyAgIDE0LjE2NDI1MF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRs
ZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU1ZmUwMWMgc2l6ZSA0DQooWEVOKSBbICAgMTQuMTcyNzQ0
XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUg
dG8gMHhmZTVmZTAyYyBzaXplIDQNCihYRU4pIFsgICAxNC4xODEyMzldIGFyY2gveDg2L2h2bS9l
bXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNWZlMDNjIHNp
emUgNA0KKFhFTikgWyAgIDE0LjE4OTczMF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2
MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU1ZmUwNGMgc2l6ZSA0DQooWEVOKSBbICAg
MTQuMTk4MjI0XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1v
cnkgd3JpdGUgdG8gMHhmZTVmZTA1YyBzaXplIDQNCihYRU4pIFsgICAxNC4yMDY3MTZdIGFyY2gv
eDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZl
NWZlMDZjIHNpemUgNA0KKFhFTikgWyAgIDE0LjIxNTIwOV0gYXJjaC94ODYvaHZtL2VtdWxhdGUu
Yzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU1ZmUwN2Mgc2l6ZSA0DQoo
WEVOKSBbICAgMTQuMjIzNzA0XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFu
ZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTVmZTAwMCBzaXplIDQNCihYRU4pIFsgICAxNC4yMzIx
OTldIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0
ZSB0byAweGZlNWZlMDA0IHNpemUgNA0KKFhFTikgWyAgIDE0LjI0MDY5MF0gYXJjaC94ODYvaHZt
L2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU1ZmUwMDgg
c2l6ZSA0DQooWEVOKSBbICAgMTQuMjQ5MTg3XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpk
MHYwIHVuaGFuZGxlZCBtZW1vcnkgcmVhZCBmcm9tIDB4ZmU1ZmUwMDggc2l6ZSA0DQooWEVOKSBb
ICAgMTQuMjU3NzYzXSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBt
ZW1vcnkgd3JpdGUgdG8gMHhmZTVmZTAwMCBzaXplIDQNCihYRU4pIFsgICAxNC4yNjYyNTZdIGFy
Y2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAw
eGZlNWZlMDA0IHNpemUgNA0KKFhFTikgWyAgIDE0LjI3NDc1MV0gYXJjaC94ODYvaHZtL2VtdWxh
dGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU1ZmUwMDggc2l6ZSA0
DQooWEVOKSBbICAgMTQuMjgzMjQyXSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVu
aGFuZGxlZCBtZW1vcnkgcmVhZCBmcm9tIDB4ZmU1ZmUwMDggc2l6ZSA0DQooWEVOKSBbICAgMTQu
MjkxODI2XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkg
d3JpdGUgdG8gMHhmZTVmZTAwYyBzaXplIDQNClsgICAgNC43NzM0MTldIHhoY2lfaGNkIDAwMDA6
MDQ6MDAuMzogeEhDSSBIb3N0IENvbnRyb2xsZXINCg0KWyAgICA0Ljc3ODcxOV0geGhjaV9oY2Qg
MDAwMDowNDowMC4zOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVy
IDINCg0KWyAgICA0Ljc4NjEwMl0geGhjaV9oY2QgMDAwMDowNDowMC4zOiBIb3N0IHN1cHBvcnRz
IFVTQiAzLjEgRW5oYW5jZWQgU3VwZXJTcGVlZA0KDQpbICAgIDQuNzkzNDAzXSB1c2IgdXNiMTog
TmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyLCBiY2RE
ZXZpY2U9IDYuMTENCg0KWyAgICA0LjgwMTYxM10gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIHN0
cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQoNClsgICAgNC44MDg4Nzdd
IHVzYiB1c2IxOiBQcm9kdWN0OiB4SENJIEhvc3QgQ29udHJvbGxlcg0KDQpbICAgIDQuODEzODE0
XSB1c2IgdXNiMTogTWFudWZhY3R1cmVyOiBMaW51eCA2LjExLjAgeGhjaS1oY2QNCg0KWyAgICA0
LjgxOTI3OF0gdXNiIHVzYjE6IFNlcmlhbE51bWJlcjogMDAwMDowNDowMC4zDQoNClsgICAgNC44
MjQxNDBdIGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kDQoNClsgICAgNC44Mjc4OTJdIGh1YiAx
LTA6MS4wOiA0IHBvcnRzIGRldGVjdGVkDQoNClsgICAgNC44MzIxMDhdIHVzYiB1c2IyOiBXZSBk
b24ndCBrbm93IHRoZSBhbGdvcml0aG1zIGZvciBMUE0gZm9yIHRoaXMgaG9zdCwgZGlzYWJsaW5n
IExQTS4NCg0KWyAgICA0Ljg0MDE0Nl0gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBp
ZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMywgYmNkRGV2aWNlPSA2LjExDQoNClsgICAgNC44
NDg0NDddIHVzYiB1c2IyOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0y
LCBTZXJpYWxOdW1iZXI9MQ0KDQpbICAgIDQuODU1NzMyXSB1c2IgdXNiMjogUHJvZHVjdDogeEhD
SSBIb3N0IENvbnRyb2xsZXINCg0KWyAgICA0Ljg2MDY2OF0gdXNiIHVzYjI6IE1hbnVmYWN0dXJl
cjogTGludXggNi4xMS4wIHhoY2ktaGNkDQoNClsgICAgNC44NjYxMzJdIHVzYiB1c2IyOiBTZXJp
YWxOdW1iZXI6IDAwMDA6MDQ6MDAuMw0KDQpbICAgIDQuODcxMTg2XSBodWIgMi0wOjEuMDogVVNC
IGh1YiBmb3VuZA0KDQpbICAgIDQuODc0ODkxXSBodWIgMi0wOjEuMDogMiBwb3J0cyBkZXRlY3Rl
ZA0KDQpbICAgIDQuODc5MTA2XSB4aGNpX2hjZCAwMDAwOjA0OjAwLjQ6IHhIQ0kgSG9zdCBDb250
cm9sbGVyDQoNClsgICAgNC44ODQzMTBdIHhoY2lfaGNkIDAwMDA6MDQ6MDAuNDogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAzDQoNClsgICAgNC44OTE4MDVdIHho
Y2lfaGNkIDAwMDA6MDQ6MDAuNDogaGNjIHBhcmFtcyAweDAyNjhmZmU1IGhjaSB2ZXJzaW9uIDB4
MTEwIHF1aXJrcyAweDAwMDAwMjAwMDAwMDAwMTANCg0KKFhFTikgWyAgIDE0LjQyNzg2OF0gYXJj
aC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MyB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAw
eGZlNGZlMDBjIHNpemUgNA0KKFhFTikgWyAgIDE0LjQzNjQ0Nl0gYXJjaC94ODYvaHZtL2VtdWxh
dGUuYzo0MTc6ZDB2MyB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlNGZlMDFjIHNpemUg
NA0KKFhFTikgWyAgIDE0LjQ0NTAyN10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MyB1
bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlNGZlMDJjIHNpemUgNA0KKFhFTikgWyAgIDE0
LjQ1MzYwOF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MyB1bmhhbmRsZWQgbWVtb3J5
IHJlYWQgZnJvbSAweGZlNGZlMDNjIHNpemUgNA0KKFhFTikgWyAgIDE0LjQ2MjE4Nl0gYXJjaC94
ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MyB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZl
NGZlMDRjIHNpemUgNA0KKFhFTikgWyAgIDE0LjQ3MDc2NF0gYXJjaC94ODYvaHZtL2VtdWxhdGUu
Yzo0MTc6ZDB2MyB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU0ZmUwMDAgc2l6ZSA0DQoo
WEVOKSBbICAgMTQuNDc5MjU3XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYzIHVuaGFu
ZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTRmZTAwNCBzaXplIDQNCihYRU4pIFsgICAxNC40ODc3
NTNdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjMgdW5oYW5kbGVkIG1lbW9yeSB3cml0
ZSB0byAweGZlNGZlMDA4IHNpemUgNA0KKFhFTikgWyAgIDE0LjQ5NjI0OF0gYXJjaC94ODYvaHZt
L2VtdWxhdGUuYzo0MTc6ZDB2MyB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlNGZlMDA4
IHNpemUgNA0KKFhFTikgWyAgIDE0LjUwNDgyNV0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6
ZDB2MyB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU0ZmUwMTAgc2l6ZSA0DQooWEVOKSBb
ICAgMTQuNTEzMzE5XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYzIHVuaGFuZGxlZCBt
ZW1vcnkgd3JpdGUgdG8gMHhmZTRmZTAxNCBzaXplIDQNCihYRU4pIFsgICAxNC41MjE4MTRdIGFy
Y2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjMgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAw
eGZlNGZlMDE4IHNpemUgNA0KKFhFTikgWyAgIDE0LjUzMDMwNl0gYXJjaC94ODYvaHZtL2VtdWxh
dGUuYzo0MTc6ZDB2MyB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlNGZlMDE4IHNpemUg
NA0KKFhFTikgWyAgIDE0LjUzODkxMl0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1
bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU0ZmUwMjAgc2l6ZSA0DQooWEVOKSBbICAgMTQu
NTQ3NDA2XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkg
d3JpdGUgdG8gMHhmZTRmZTAyNCBzaXplIDQNCihYRU4pIFsgICAxNC41NTU5MDBdIGFyY2gveDg2
L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNGZl
MDI4IHNpemUgNA0KKFhFTikgWyAgIDE0LjU2NDM5N10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0
MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlNGZlMDI4IHNpemUgNA0KKFhF
TikgWyAgIDE0LjU3Mjk3Nl0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRs
ZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU0ZmUwMzAgc2l6ZSA0DQooWEVOKSBbICAgMTQuNTgxNDY3
XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUg
dG8gMHhmZTRmZTAzNCBzaXplIDQNCihYRU4pIFsgICAxNC41ODk5NTldIGFyY2gveDg2L2h2bS9l
bXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNGZlMDM4IHNp
emUgNA0KKFhFTikgWyAgIDE0LjU5ODQ1M10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2
MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlNGZlMDM4IHNpemUgNA0KKFhFTikgWyAg
IDE0LjYwNzAzOF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVt
b3J5IHdyaXRlIHRvIDB4ZmU0ZmUwNDAgc2l6ZSA0DQooWEVOKSBbICAgMTQuNjE1NTI5XSBhcmNo
L3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhm
ZTRmZTA0NCBzaXplIDQNCihYRU4pIFsgICAxNC42MjQwMjBdIGFyY2gveDg2L2h2bS9lbXVsYXRl
LmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNGZlMDQ4IHNpemUgNA0K
KFhFTikgWyAgIDE0LjYzMjUxN10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhh
bmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlNGZlMDQ4IHNpemUgNA0KKFhFTikgWyAgIDE0LjY0
MTA5OF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdy
aXRlIHRvIDB4ZmU0ZmUwMGMgc2l6ZSA0DQooWEVOKSBbICAgMTQuNjQ5NTkwXSBhcmNoL3g4Ni9o
dm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTRmZTAx
YyBzaXplIDQNCihYRU4pIFsgICAxNC42NTgwODRdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3
OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNGZlMDJjIHNpemUgNA0KKFhFTikg
WyAgIDE0LjY2NjU3NV0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQg
bWVtb3J5IHdyaXRlIHRvIDB4ZmU0ZmUwM2Mgc2l6ZSA0DQooWEVOKSBbICAgMTQuNjc1MDY2XSBh
cmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8g
MHhmZTRmZTA0YyBzaXplIDQNCihYRU4pIFsgICAxNC42ODM1NjRdIGFyY2gveDg2L2h2bS9lbXVs
YXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNGZlMDVjIHNpemUg
NA0KKFhFTikgWyAgIDE0LjY5MjA1NV0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1
bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU0ZmUwNmMgc2l6ZSA0DQooWEVOKSBbICAgMTQu
NzAwNTQ2XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkg
d3JpdGUgdG8gMHhmZTRmZTA3YyBzaXplIDQNCihYRU4pIFsgICAxNC43MDkwMzhdIGFyY2gveDg2
L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNGZl
MDAwIHNpemUgNA0KKFhFTikgWyAgIDE0LjcxNzUzMl0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0
MTc6ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU0ZmUwMDQgc2l6ZSA0DQooWEVO
KSBbICAgMTQuNzI2MDI2XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxl
ZCBtZW1vcnkgd3JpdGUgdG8gMHhmZTRmZTAwOCBzaXplIDQNCihYRU4pIFsgICAxNC43MzQ1MjFd
IGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSByZWFkIGZy
b20gMHhmZTRmZTAwOCBzaXplIDQNCihYRU4pIFsgICAxNC43NDMwOTldIGFyY2gveDg2L2h2bS9l
bXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNGZlMDAwIHNp
emUgNA0KKFhFTikgWyAgIDE0Ljc1MTU5MV0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2
MCB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmU0ZmUwMDQgc2l6ZSA0DQooWEVOKSBbICAg
MTQuNzYwMDg4XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1v
cnkgd3JpdGUgdG8gMHhmZTRmZTAwOCBzaXplIDQNCihYRU4pIFsgICAxNC43Njg1ODJdIGFyY2gv
eDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSByZWFkIGZyb20gMHhm
ZTRmZTAwOCBzaXplIDQNCihYRU4pIFsgICAxNC43NzcxNjRdIGFyY2gveDg2L2h2bS9lbXVsYXRl
LmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlNGZlMDBjIHNpemUgNA0K
WyAgICA1LjI1ODg2MV0geGhjaV9oY2QgMDAwMDowNDowMC40OiB4SENJIEhvc3QgQ29udHJvbGxl
cg0KDQpbICAgIDUuMjY0NjQzXSB4aGNpX2hjZCAwMDAwOjA0OjAwLjQ6IG5ldyBVU0IgYnVzIHJl
Z2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNA0KDQpbICAgIDUuMjcxOTc1XSB4aGNpX2hj
ZCAwMDAwOjA0OjAwLjQ6IEhvc3Qgc3VwcG9ydHMgVVNCIDMuMSBFbmhhbmNlZCBTdXBlclNwZWVk
DQoNClsgICAgNS4yNzk3NjldIHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5k
b3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDIsIGJjZERldmljZT0gNi4xMQ0KDQpbICAgIDUuMjg3OTY0
XSB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2Vy
aWFsTnVtYmVyPTENCg0KWyAgICA1LjI5NTI1M10gdXNiIHVzYjM6IFByb2R1Y3Q6IHhIQ0kgSG9z
dCBDb250cm9sbGVyDQoNClsgICAgNS4zMDAxODJdIHVzYiB1c2IzOiBNYW51ZmFjdHVyZXI6IExp
bnV4IDYuMTEuMCB4aGNpLWhjZA0KDQpbICAgIDUuMzA1NjQ1XSB1c2IgdXNiMzogU2VyaWFsTnVt
YmVyOiAwMDAwOjA0OjAwLjQNCg0KWyAgICA1LjMxMDQ3Nl0gaHViIDMtMDoxLjA6IFVTQiBodWIg
Zm91bmQNCg0KWyAgICA1LjMxNDIyNl0gaHViIDMtMDoxLjA6IDQgcG9ydHMgZGV0ZWN0ZWQNCg0K
WyAgICA1LjMxODU5MV0gdXNiIHVzYjQ6IFdlIGRvbid0IGtub3cgdGhlIGFsZ29yaXRobXMgZm9y
IExQTSBmb3IgdGhpcyBob3N0LCBkaXNhYmxpbmcgTFBNLg0KDQpbICAgIDUuMzI2NzcyXSB1c2Ig
dXNiNDogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAz
LCBiY2REZXZpY2U9IDYuMTENCg0KWyAgICA1LjMzNDk2Ml0gdXNiIHVzYjQ6IE5ldyBVU0IgZGV2
aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQoNClsgICAgNS4z
NDIyMzhdIHVzYiB1c2I0OiBQcm9kdWN0OiB4SENJIEhvc3QgQ29udHJvbGxlcg0KDQpbICAgIDUu
MzQ3MTcyXSB1c2IgdXNiNDogTWFudWZhY3R1cmVyOiBMaW51eCA2LjExLjAgeGhjaS1oY2QNCg0K
WyAgICA1LjM1MjYzMl0gdXNiIHVzYjQ6IFNlcmlhbE51bWJlcjogMDAwMDowNDowMC40DQoNClsg
ICAgNS4zNTc5MjddIGh1YiA0LTA6MS4wOiBVU0IgaHViIGZvdW5kDQoNClsgICAgNS4zNjE2NDRd
IGh1YiA0LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQoNClsgICAgNS4zNjU5MTFdIHVzYmNvcmU6
IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNibHANCg0KWyAgICA1LjM3MTM0Nl0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Itc3RvcmFnZQ0KDQpb
ICAgIDUuMzc3ODc4XSBpODA0MjogUE5QOiBObyBQUy8yIGNvbnRyb2xsZXIgZm91bmQuDQoNClsg
ICAgNS4zODI1MTNdIGk4MDQyOiBQcm9iaW5nIHBvcnRzIGRpcmVjdGx5Lg0KDQpbICAgIDUuMzg3
NTM4XSBpODA0MjogTm8gY29udHJvbGxlciBmb3VuZA0KDQpbICAgIDUuMzkxNzE0XSBydGNfY21v
cyAwMDowMTogUlRDIGNhbiB3YWtlIGZyb20gUzQNCg0KWyAgICA1LjM5NjQzMl0gcnRjX2Ntb3Mg
MDA6MDE6IHJlZ2lzdGVyZWQgYXMgcnRjMA0KDQpbICAgIDUuNDAwODM0XSBydGNfY21vcyAwMDow
MTogbm8gYWxhcm1zLCB5M2ssIDExNCBieXRlcyBudnJhbQ0KDQpbICAgIDUuNDA2NDY5XSBmYWls
IHRvIGluaXRpYWxpemUgcHRwX2t2bQ0KDQpbICAgIDUuNDA2NjQ3XSB4ZW5fd2R0IHhlbl93ZHQ6
IGluaXRpYWxpemVkICh0aW1lb3V0PTYwcywgbm93YXlvdXQ9MCkNCg0KWyAgICA1LjQxNjk5M10g
ZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuNDguMC1pb2N0bCAoMjAyMy0wMy0wMSkgaW5pdGlhbGlz
ZWQ6IGRtLWRldmVsQGxpc3RzLmxpbnV4LmRldg0KDQpbICAgIDUuNDI1ODAwXSBhbWRfcHN0YXRl
OiBUaGUgQ1BQQyBmZWF0dXJlIGlzIHN1cHBvcnRlZCBidXQgY3VycmVudGx5IGRpc2FibGVkIGJ5
IHRoZSBCSU9TLg0KDQpbICAgIDUuNDI1ODAwXSBQbGVhc2UgZW5hYmxlIGl0IGlmIHlvdXIgQklP
UyBoYXMgdGhlIENQUEMgb3B0aW9uLg0KDQpbICAgIDUuNDM5OTI3XSBhbWRfcHN0YXRlOiB0aGUg
X0NQQyBvYmplY3QgaXMgbm90IHByZXNlbnQgaW4gU0JJT1Mgb3IgQUNQSSBkaXNhYmxlZA0KDQpb
ICAgIDUuNDQ3NDA4XSBoaWQ6IHJhdyBISUQgZXZlbnRzIGRyaXZlciAoQykgSmlyaSBLb3NpbmEN
Cg0KWyAgICA1LjQ1MjYzOV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZl
ciB1c2JoaWQNCg0KWyAgICA1LjQ1ODIwM10gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJpdmVyDQoN
ClsgICAgNS40NjI0NzldIHNuZF9oZGFfaW50ZWwgMDAwMDowNDowMC4xOiBlbmFibGluZyBkZXZp
Y2UgKDAwMDAgLT4gMDAwMikNCg0KKFhFTikgWyAgIDE0Ljk5NTkwMV0gMDAwMDowNDowMC4xOiBu
b3QgbWFwcGluZyBCQVIgW2ZlN2M4LCBmZTdjYl0gaW52YWxpZCBwb3NpdGlvbg0KWyAgICA1LjQ3
NjI3Nl0gc25kX2hkYV9pbnRlbCAwMDAwOjA0OjAwLjY6IGVuYWJsaW5nIGRldmljZSAoMDAwMCAt
PiAwMDAyKQ0KDQooWEVOKSBbICAgMTUuMDA5NzY1XSAwMDAwOjA0OjAwLjY6IG5vdCBtYXBwaW5n
IEJBUiBbZmU3YzAsIGZlN2M3XSBpbnZhbGlkIHBvc2l0aW9uDQpbICAgIDUuNDkwNTYwXSBJbml0
aWFsaXppbmcgWEZSTSBuZXRsaW5rIHNvY2tldA0KDQpbICAgIDUuNDk0NzkzXSBORVQ6IFJlZ2lz
dGVyZWQgUEZfSU5FVDYgcHJvdG9jb2wgZmFtaWx5DQoNClsgICAgNS41MDA2MThdIFNlZ21lbnQg
Um91dGluZyB3aXRoIElQdjYNCg0KWyAgICA1LjUwMTQzNV0gc25kX2hkYV9pbnRlbCAwMDAwOjA0
OjAwLjE6IENhbm5vdCBwcm9iZSBjb2RlY3MsIGdpdmluZyB1cA0KDQpbICAgIDUuNTA0MjI0XSBJ
KFhFTikgWyAgIDE1LjAzOTE1OV0gYXJjaC94ODYvaHZtL3Ztc2kuYzo4NDU6ZDB2MCAwMDAwOjA0
OjAwLjE6IFBJUlEgMzMyMDogdW5zdXBwb3J0ZWQgYWRkcmVzcyAwDQpuLXNpdHUgT0FNIChJT0FN
KFhFTikgWyAgIDE1LjA0OTA0MF0gYXJjaC94ODYvaHZtL3Ztc2kuYzo4NDU6ZDB2MCAwMDAwOjA0
OjAwLjE6IFBJUlEgMzMyMDogdW5zdXBwb3J0ZWQgYWRkcmVzcyAwDQopIHdpdGggSVB2Ng0KDQoo
WEVOKSBbICAgMTUuMDU4NzQ2XSBhcmNoL3g4Ni9odm0vdm1zaS5jOjg0NTpkMHYwIDAwMDA6MDQ6
MDAuMTogUElSUSAzMzIwOiB1bnN1cHBvcnRlZCBhZGRyZXNzIDANClsgICAgNS41NDAyODldIHNp
dDogSVB2NiwgSVB2NCBhbmQgTVBMUyBvdmVyIElQdjQgdHVubmVsaW5nIGRyaXZlcg0KDQpbICAg
IDUuNTQ2MzE5XSBORVQ6IFJlZ2lzdGVyZWQgUEZfUEFDS0VUIHByb3RvY29sIGZhbWlseQ0KDQpb
ICAgIDUuNTUxMzc2XSA5cG5ldDogSW5zdGFsbGluZyA5UDIwMDAgc3VwcG9ydA0KDQpbICAgIDUu
NTU1NzA0XSBLZXkgdHlwZSBkbnNfcmVzb2x2ZXIgcmVnaXN0ZXJlZA0KDQpbICAgIDUuNTYwMzIx
XSBJUEkgc2hvcnRoYW5kIGJyb2FkY2FzdDogZW5hYmxlZA0KDQpbICAgIDUuNTY2MDY4XSBzY2hl
ZF9jbG9jazogTWFya2luZyBzdGFibGUgKDU0ODMwMDg3NzksIDgyOTIxNDE4KS0+KDYyNTM5NTg3
NjMsIC02ODgwMjg1NjYpDQoNClsgICAgNS41NzQyNDFdIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZl
cnNpb24gMQ0KDQpbICAgIDUuNTc4MjY5XSBMb2FkaW5nIGNvbXBpbGVkLWluIFguNTA5IGNlcnRp
ZmljYXRlcw0KDQpbICAgIDUuNTgzODcwXSBEZW1vdGlvbiB0YXJnZXRzIGZvciBOb2RlIDA6IG51
bGwNCg0KWyAgICA1LjU4ODI3Nl0gUE06ICAgTWFnaWMgbnVtYmVyOiA5OjUzNzo2NjINCg0KWyAg
ICA1LjU5MjI4MV0gcHJpbnRrOiBsZWdhY3kgY29uc29sZSBbbmV0Y29uMF0gZW5hYmxlZA0KDQpb
ICAgIDUuNTk3Mjc1XSBuZXRjb25zb2xlOiBuZXR3b3JrIGxvZ2dpbmcgc3RhcnRlZA0KDQpbICAg
IDUuNjAyNDQyXSBjZmc4MDIxMTogTG9hZGluZyBjb21waWxlZC1pbiBYLjUwOSBjZXJ0aWZpY2F0
ZXMgZm9yIHJlZ3VsYXRvcnkgZGF0YWJhc2UNCg0KWyAgICA1LjYxMDgzMF0gbW9kcHJvYmUgKDg3
KSB1c2VkIGdyZWF0ZXN0IHN0YWNrIGRlcHRoOiAxMzY4OCBieXRlcyBsZWZ0DQoNClsgICAgNS42
MTE0NzNdIExvYWRlZCBYLjUwOSBjZXJ0ICdzZm9yc2hlZTogMDBiMjhkZGY0N2FlZjljZWE3Jw0K
DQpbICAgIDUuNjIzMDQ2XSBMb2FkZWQgWC41MDkgY2VydCAnd2VuczogNjFjMDM4NjUxYWFiZGNm
OTRiZDBhYzdmZjA2YzcyNDhkYjE4YzYwMCcNCg0KWyAgICA1LjYzMDIxNV0gQUxTQSBkZXZpY2Ug
bGlzdDoNCg0KWyAgICA1LjYzMzI0NF0gcGxhdGZvcm0gcmVndWxhdG9yeS4wOiBEaXJlY3QgZmly
bXdhcmUgbG9hZCBmb3IgcmVndWxhdG9yeS5kYiBmYWlsZWQgd2l0aCBlcnJvciAtMg0KDQpbICAg
IDUuNjMzOTQ0XSAgIE5vIHNvdW5kY2FyZHMgZm91bmQuDQoNClsgICAgNS42NDE5MTBdIGNmZzgw
MjExOiBmYWlsZWQgdG8gbG9hZCByZWd1bGF0b3J5LmRiDQoNClsgICAxMi44OTUwOTRdIHhoY2lf
aGNkIDAwMDA6MDQ6MDAuNDogRXJyb3Igd2hpbGUgYXNzaWduaW5nIGRldmljZSBzbG90IElEOiBD
b21tYW5kIEFib3J0ZWQNCg0KWyAgIDEyLjkwMzEyNF0geGhjaV9oY2QgMDAwMDowNDowMC40OiBN
YXggbnVtYmVyIG9mIGRldmljZXMgdGhpcyB4SENJIGhvc3Qgc3VwcG9ydHMgaXMgNjQuDQoNClsg
ICAxMi45MTExODJdIHVzYiB1c2IzLXBvcnQ0OiBjb3VsZG4ndCBhbGxvY2F0ZSB1c2JfZGV2aWNl
DQoNClsgICA2NS45NTA5NjldIHNuZF9oZGFfaW50ZWwgMDAwMDowNDowMC42OiBDYW5ub3QgcHJv
YmUgY29kZWNzLCBnaXZpbmcgdXANCg0KKFhFTikgWyAgIDc1LjQ4NDU2NV0gYXJjaC94ODYvaHZt
L3Ztc2kuYzo4NDU6ZDB2MyAwMDAwOjA0OjAwLjY6IFBJUlEgMzMxOTogdW5zdXBwb3J0ZWQgYWRk
cmVzcyAwDQooWEVOKSBbICAgNzUuNDkzMDU2XSBhcmNoL3g4Ni9odm0vdm1zaS5jOjg0NTpkMHYz
IDAwMDA6MDQ6MDAuNjogUElSUSAzMzE5OiB1bnN1cHBvcnRlZCBhZGRyZXNzIDANCihYRU4pIFsg
ICA3NS41MDE1NTRdIGFyY2gveDg2L2h2bS92bXNpLmM6ODQ1OmQwdjMgMDAwMDowNDowMC42OiBQ
SVJRIDMzMTk6IHVuc3VwcG9ydGVkIGFkZHJlc3MgMA0KWyAgIDY3LjY4MDY2Nl0gbnZtZSBudm1l
MDogSS9PIHRhZyA0ICgxMDA0KSBRSUQgMCB0aW1lb3V0LCBjb21wbGV0aW9uIHBvbGxlZA0KDQpb
ICAgNjcuNjgwNjkwXSBudm1lIG52bWUwOiBtaXNzaW5nIG9yIGludmFsaWQgU1VCTlFOIGZpZWxk
Lg0KDQpbICAxMjkuMTE5MTY4XSBudm1lIG52bWUwOiBJL08gdGFnIDUgKDEwMDUpIFFJRCAwIHRp
bWVvdXQsIGNvbXBsZXRpb24gcG9sbGVkDQoNClsgIDEyOS4xMjU5ODBdIG52bWUgbnZtZTA6IEQz
IGVudHJ5IGxhdGVuY3kgc2V0IHRvIDggc2Vjb25kcw0KDQpbICAxOTAuNTYwNjM3XSBudm1lIG52
bWUwOiBJL08gdGFnIDYgKDEwMDYpIFFJRCAwIHRpbWVvdXQsIGNvbXBsZXRpb24gcG9sbGVkDQoN
ClsgIDI1Mi4wMDA2MzBdIG52bWUgbnZtZTA6IEkvTyB0YWcgNyAoMTAwNykgUUlEIDAgdGltZW91
dCwgY29tcGxldGlvbiBwb2xsZWQNCg0KWyAgMzEzLjQzODk3OV0gbnZtZSBudm1lMDogSS9PIHRh
ZyA0ICgyMDA0KSBRSUQgMCB0aW1lb3V0LCBjb21wbGV0aW9uIHBvbGxlZA0KDQooWEVOKSBbICAz
MjIuOTcyODY3XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1v
cnkgd3JpdGUgdG8gMHhmZWEwMzAwYyBzaXplIDQNCihYRU4pIFsgIDMyMi45ODEzNjVdIGFyY2gv
eDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSByZWFkIGZyb20gMHhm
ZWEwMzAwMCBzaXplIDQNCihYRU4pIFsgIDMyMi45ODk5NDNdIGFyY2gveDg2L2h2bS9lbXVsYXRl
LmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDAwIHNpemUgNA0K
KFhFTikgWyAgMzIyLjk5ODQzN10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhh
bmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwMDQgc2l6ZSA0DQooWEVOKSBbICAzMjMuMDA2
OTI2XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3Jp
dGUgdG8gMHhmZWEwMzAwOCBzaXplIDQNCihYRU4pIFsgIDMyMy4wMTU0MjBdIGFyY2gveDg2L2h2
bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSByZWFkIGZyb20gMHhmZWEwMzAw
OCBzaXplIDQNCihYRU4pIFsgIDMyMy4wMjQwMDJdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3
OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDBjIHNpemUgNA0KKFhFTikg
WyAgMzIzLjAzMjQ5Nl0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQg
bWVtb3J5IHJlYWQgZnJvbSAweGZlYTAzMDAwIHNpemUgNA0KKFhFTikgWyAgMzIzLjA0MTA3N10g
YXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJv
bSAweGZlYTAzMDBjIHNpemUgNA0KKFhFTikgWyAgMzIzLjA0OTY1M10gYXJjaC94ODYvaHZtL2Vt
dWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlYTAzMDFjIHNp
emUgNA0KKFhFTikgWyAgMzIzLjA1ODIzOV0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2
MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlYTAzMDJjIHNpemUgNA0KKFhFTikgWyAg
MzIzLjA2NjgxNF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVt
b3J5IHJlYWQgZnJvbSAweGZlYTAzMDNjIHNpemUgNA0KKFhFTikgWyAgMzIzLjA3NTM5OF0gYXJj
aC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAw
eGZlYTAzMDRjIHNpemUgNA0KKFhFTikgWyAgMzIzLjA4Mzk3M10gYXJjaC94ODYvaHZtL2VtdWxh
dGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwMDAgc2l6ZSA0
DQooWEVOKSBbICAzMjMuMDkyNDcyXSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVu
aGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzAwNCBzaXplIDQNCihYRU4pIFsgIDMyMy4x
MDA5NjBdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3
cml0ZSB0byAweGZlYTAzMDA4IHNpemUgNA0KKFhFTikgWyAgMzIzLjEwOTQ1Nl0gYXJjaC94ODYv
aHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlYTAz
MDA4IHNpemUgNA0KKFhFTikgWyAgMzIzLjExODAzOF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0
MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwMTAgc2l6ZSA0DQooWEVO
KSBbICAzMjMuMTI2NTI5XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxl
ZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzAxNCBzaXplIDQNCihYRU4pIFsgIDMyMy4xMzUwMjBd
IGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0
byAweGZlYTAzMDE4IHNpemUgNA0KKFhFTikgWyAgMzIzLjE0MzUxNV0gYXJjaC94ODYvaHZtL2Vt
dWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlYTAzMDE4IHNp
emUgNA0KKFhFTikgWyAgMzIzLjE1MjA5M10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2
MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwMjAgc2l6ZSA0DQooWEVOKSBbICAz
MjMuMTYwNTkwXSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1v
cnkgd3JpdGUgdG8gMHhmZWEwMzAyNCBzaXplIDQNCihYRU4pIFsgIDMyMy4xNjkwODJdIGFyY2gv
eDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZl
YTAzMDI4IHNpemUgNA0KKFhFTikgWyAgMzIzLjE3NzU3M10gYXJjaC94ODYvaHZtL2VtdWxhdGUu
Yzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlYTAzMDI4IHNpemUgNA0K
KFhFTikgWyAgMzIzLjE4NjE1M10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhh
bmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwMzAgc2l6ZSA0DQooWEVOKSBbICAzMjMuMTk0
NjQ2XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3Jp
dGUgdG8gMHhmZWEwMzAzNCBzaXplIDQNCihYRU4pIFsgIDMyMy4yMDMxNDBdIGFyY2gveDg2L2h2
bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDM4
IHNpemUgNA0KKFhFTikgWyAgMzIzLjIxMTYzNF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6
ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlYTAzMDM4IHNpemUgNA0KKFhFTikg
WyAgMzIzLjIyMDIxNl0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQg
bWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwNDAgc2l6ZSA0DQooWEVOKSBbICAzMjMuMjI4NzA2XSBh
cmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8g
MHhmZWEwMzA0NCBzaXplIDQNCihYRU4pIFsgIDMyMy4yMzcyMDRdIGFyY2gveDg2L2h2bS9lbXVs
YXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDQ4IHNpemUg
NA0KKFhFTikgWyAgMzIzLjI0NTY5OF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1
bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlYTAzMDQ4IHNpemUgNA0KKFhFTikgWyAgMzIz
LjI1NDI3M10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5
IHdyaXRlIHRvIDB4ZmVhMDMwMGMgc2l6ZSA0DQooWEVOKSBbICAzMjMuMjYyNzY4XSBhcmNoL3g4
Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEw
MzAxYyBzaXplIDQNCihYRU4pIFsgIDMyMy4yNzEyNTldIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6
NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDJjIHNpemUgNA0KKFhF
TikgWyAgMzIzLjI3OTc1M10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRs
ZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwM2Mgc2l6ZSA0DQooWEVOKSBbICAzMjMuMjg4MjUx
XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUg
dG8gMHhmZWEwMzA0YyBzaXplIDQNCihYRU4pIFsgIDMyMy4yOTY3MzldIGFyY2gveDg2L2h2bS9l
bXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDVjIHNp
emUgNA0KKFhFTikgWyAgMzIzLjMwNTIzM10gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2
MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwNmMgc2l6ZSA0DQooWEVOKSBbICAz
MjMuMzEzNzI2XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1v
cnkgd3JpdGUgdG8gMHhmZWEwMzA3YyBzaXplIDQNCihYRU4pIFsgIDMyMy4zMjIyMjJdIGFyY2gv
eDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZl
YTAzMDhjIHNpemUgNA0KKFhFTikgWyAgMzIzLjMzMDcxNV0gYXJjaC94ODYvaHZtL2VtdWxhdGUu
Yzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwOWMgc2l6ZSA0DQoo
WEVOKSBbICAzMjMuMzM5MjExXSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFu
ZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzBhYyBzaXplIDQNCihYRU4pIFsgIDMyMy4zNDc3
MDJdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0
ZSB0byAweGZlYTAzMGJjIHNpemUgNA0KKFhFTikgWyAgMzIzLjM1NjE5M10gYXJjaC94ODYvaHZt
L2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwY2Mg
c2l6ZSA0DQooWEVOKSBbICAzMjMuMzY0Njg1XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpk
MHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzBkYyBzaXplIDQNCihYRU4pIFsg
IDMyMy4zNzMxODNdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1l
bW9yeSB3cml0ZSB0byAweGZlYTAzMGVjIHNpemUgNA0KKFhFTikgWyAgMzIzLjM4MTY3OF0gYXJj
aC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4
ZmVhMDMwZmMgc2l6ZSA0DQooWEVOKSBbICAzMjMuMzkwMTY4XSBhcmNoL3g4Ni9odm0vZW11bGF0
ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzEwYyBzaXplIDQN
CihYRU4pIFsgIDMyMy4zOTg2NjNdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5o
YW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMTFjIHNpemUgNA0KKFhFTikgWyAgMzIzLjQw
NzE1NV0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdy
aXRlIHRvIDB4ZmVhMDMxMmMgc2l6ZSA0DQooWEVOKSBbICAzMjMuNDE1NjQ2XSBhcmNoL3g4Ni9o
dm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzEz
YyBzaXplIDQNCihYRU4pIFsgIDMyMy40MjQxMzldIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3
OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMTRjIHNpemUgNA0KKFhFTikg
WyAgMzIzLjQzMjYzNF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQg
bWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMxNWMgc2l6ZSA0DQooWEVOKSBbICAzMjMuNDQxMTI1XSBh
cmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8g
MHhmZWEwMzE2YyBzaXplIDQNCihYRU4pIFsgIDMyMy40NDk2MTldIGFyY2gveDg2L2h2bS9lbXVs
YXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMTdjIHNpemUg
NA0KKFhFTikgWyAgMzIzLjQ1ODExMV0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1
bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMxOGMgc2l6ZSA0DQooWEVOKSBbICAzMjMu
NDY2NjA1XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkg
d3JpdGUgdG8gMHhmZWEwMzE5YyBzaXplIDQNCihYRU4pIFsgIDMyMy40NzUwOTldIGFyY2gveDg2
L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAz
MWFjIHNpemUgNA0KKFhFTikgWyAgMzIzLjQ4MzU5NF0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0
MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMxYmMgc2l6ZSA0DQooWEVO
KSBbICAzMjMuNDkyMDg1XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYxIHVuaGFuZGxl
ZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzFjYyBzaXplIDQNCihYRU4pIFsgIDMyMy41MDA1Nzhd
IGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0
byAweGZlYTAzMWRjIHNpemUgNA0KKFhFTikgWyAgMzIzLjUwOTA3NF0gYXJjaC94ODYvaHZtL2Vt
dWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMxZWMgc2l6
ZSA0DQooWEVOKSBbICAzMjMuNTE3NTY1XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYx
IHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzFmYyBzaXplIDQNCihYRU4pIFsgIDMy
My41MjYwNThdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1lbW9y
eSB3cml0ZSB0byAweGZlYTAzMjBjIHNpemUgNA0KKFhFTikgWyAgMzIzLjUzNDU1N10gYXJjaC94
ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVh
MDMwMDAgc2l6ZSA0DQooWEVOKSBbICAzMjMuNTQzMDQ3XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5j
OjQxNzpkMHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzAwNCBzaXplIDQNCihY
RU4pIFsgIDMyMy41NTE1MzhdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5k
bGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDA4IHNpemUgNA0KKFhFTikgWyAgMzIzLjU2MDAz
MV0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQg
ZnJvbSAweGZlYTAzMDA4IHNpemUgNA0KKFhFTikgWyAgMzIzLjU2ODYxNF0gYXJjaC94ODYvaHZt
L2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwMDAg
c2l6ZSA0DQooWEVOKSBbICAzMjMuNTc3MTEwXSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpk
MHYxIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzAwNCBzaXplIDQNCihYRU4pIFsg
IDMyMy41ODU1OThdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3OmQwdjEgdW5oYW5kbGVkIG1l
bW9yeSB3cml0ZSB0byAweGZlYTAzMDA4IHNpemUgNA0KKFhFTikgWyAgMzIzLjU5NDA5NF0gYXJj
aC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAw
eGZlYTAzMDA4IHNpemUgNA0KKFhFTikgWyAgMzIzLjYwMjY3M10gYXJjaC94ODYvaHZtL2VtdWxh
dGUuYzo0MTc6ZDB2MSB1bmhhbmRsZWQgbWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwMGMgc2l6ZSA0
DQpbICAzNzQuODc5MDA1XSBudm1lIG52bWUwOiBJL08gdGFnIDUgKDIwMDUpIFFJRCAwIHRpbWVv
dXQsIGNvbXBsZXRpb24gcG9sbGVkDQoNClsgIDQzNi4zMTg5ODBdIG4oWEVOKSBbICA0NDUuODQ3
MjE2XSBhcmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3Jp
dGUgdG8gMHhmZWEwMzAxMCBzaXplIDQNCihYRU4pIFsgIDQ0NS44NTU3MDldIGFyY2gveDg2L2h2
bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDE0
IHNpemUgNA0Kdm1lIG52bWUwOiBJL08gdChYRU4pIFsgIDQ0NS44NjU1ODhdIGFyY2gveDg2L2h2
bS9lbXVsYXRlLmM6NDE3OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDE4
IHNpemUgNA0KKFhFTikgWyAgNDQ1Ljg3NDA4Nl0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6
ZDB2MCB1bmhhbmRsZWQgbWVtb3J5IHJlYWQgZnJvbSAweGZlYTAzMDE4IHNpemUgNA0KYWcgMjAg
KDEwMTQpIFFJRChYRU4pIFsgIDQ0NS44ODQwNDhdIGFyY2gveDg2L2h2bS9lbXVsYXRlLmM6NDE3
OmQwdjAgdW5oYW5kbGVkIG1lbW9yeSB3cml0ZSB0byAweGZlYTAzMDEwIHNpemUgNA0KKFhFTikg
WyAgNDQ1Ljg5MjU0Nl0gYXJjaC94ODYvaHZtL2VtdWxhdGUuYzo0MTc6ZDB2MCB1bmhhbmRsZWQg
bWVtb3J5IHdyaXRlIHRvIDB4ZmVhMDMwMTQgc2l6ZSA0DQooWEVOKSBbICA0NDUuOTAxMDM3XSBh
cmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8g
MHhmZWEwMzAxOCBzaXplIDQNCiAwIHRpbWVvdXQsIGNvbXAoWEVOKSBbICA0NDUuOTEwOTE4XSBh
cmNoL3g4Ni9odm0vZW11bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgcmVhZCBmcm9t
IDB4ZmVhMDMwMTggc2l6ZSA0DQooWEVOKSBbICA0NDUuOTE5NDk3XSBhcmNoL3g4Ni9odm0vZW11
bGF0ZS5jOjQxNzpkMHYwIHVuaGFuZGxlZCBtZW1vcnkgd3JpdGUgdG8gMHhmZWEwMzAxYyBzaXpl
IDQNCmxldGlvbiBwb2xsZWQNCg==

--------------4vcTr0KMHNAmZnYteqWrR3WQ
Content-Type: text/plain; charset=UTF-8; name="test-patched.log"
Content-Disposition: attachment; filename="test-patched.log"
Content-Transfer-Encoding: base64

WGVuIDQuMjEtdW5zdGFibGUNCihYRU4pIFswMDAwMDAyYWFjYjQxN2FlXSBYZW4gdmVyc2lvbiA0
LjIxLXVuc3RhYmxlIChyb290QCkgKGdjYyAoQWxwaW5lIDEyLjIuMV9naXQyMDIyMDkyNC1yMTAp
IDEyLjIuMSAyMDIyMDkyNCkgZGVidWc9eSBUaHUgTWF5IDE1IDE4OjUxOjA0IFVUQyAyMDI1DQoo
WEVOKSBbMDAwMDAwMmFhZWY2MDZlMl0gTGF0ZXN0IENoYW5nZVNldDoNCihYRU4pIFswMDAwMDAy
YWFmYTIzZmYyXSBidWlsZC1pZDogZjkyYWRkMDkyYmMwZWRlMDMwZmM1ZWZiNTNjMDhiY2IxNDM3
ODBkYg0KKFhFTikgWzAwMDAwMDJhYjBjOTE5ZDldIENvbnNvbGUgb3V0cHV0IGlzIHN5bmNocm9u
b3VzLg0KKFhFTikgWzAwMDAwMDJhYjFhMzNjYmZdIENQVSBWZW5kb3I6IEFNRCwgRmFtaWx5IDIz
ICgweDE3KSwgTW9kZWwgOTYgKDB4NjApLCBTdGVwcGluZyAxIChyYXcgMDA4NjBmMDEpDQooWEVO
KSBbMDAwMDAwMmFiMzMxNGJlYV0gQlNQIG1pY3JvY29kZSByZXZpc2lvbjogMHgwODYwMDEwYw0K
KFhFTikgWzAwMDAwMDJhYjQxYWM3ZGNdIEJvb3Rsb2FkZXI6IEdSVUIgMi4xMw0KKFhFTikgWzAw
MDAwMDJhYjRkMjk4YWFdIENvbW1hbmQgbGluZTogY29uc29sZT1jb20xIGNvbTE9MTE1MjAwLDhu
MSwweDNGOCw0IHNjaGVkPW51bGwgbG9nbHZsPWFsbCBndWVzdF9sb2dsdmw9YWxsIGNvbnNvbGVf
dGltZXN0YW1wcz1ib290IGlvbW11PXZlcmJvc2UgZG9tMD1wdmgsdmVyYm9zZSBkb20wX21heF92
Y3B1cz00IGRvbTBfbWVtPTRHIGFyZ289MSxtYWMtcGVybWlzc2l2ZT0xIHN5bmNfY29uc29sZSBu
b3JlYm9vdCB3b3cNCihYRU4pIFswMDAwMDAyYWI4OGY4YTY1XSBYZW4gaW1hZ2UgbG9hZCBiYXNl
IGFkZHJlc3M6IDB4YzY4MDAwMDANCihYRU4pIFswMDAwMDAyYWI5OGMyY2VjXSBWaWRlbyBpbmZv
cm1hdGlvbjoNCihYRU4pIFswMDAwMDAyYWJhMzg2MTU3XSAgVkdBIGlzIHRleHQgbW9kZSA4MHgy
NSwgZm9udCA4eDE2DQooWEVOKSBbMDAwMDAwMmFiYjIxZWFjNF0gRGlzYyBpbmZvcm1hdGlvbjoN
CihYRU4pIFswMDAwMDAyYWJiY2E1YTA3XSAgRm91bmQgMCBNQlIgc2lnbmF0dXJlcw0KKFhFTikg
WzAwMDAwMDJhYmM4OWM5ZTBdICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzDQoo
WEVOKSBbMDAwMDAwMmFiZDc3MDg5OV0gRUZJIFJBTSBtYXA6DQooWEVOKSBbMDAwMDAwMmFiZTBj
NTBlZl0gIFswMDAwMDAwMDAwMDAwMDAwLCAwMDAwMDAwMDAwMDlmZmZmXSAodXNhYmxlKQ0KKFhF
TikgWzAwMDAwMDJhYmYyM2JiNzldICBbMDAwMDAwMDAwMDBhMDAwMCwgMDAwMDAwMDAwMDBmZmZm
Zl0gKHJlc2VydmVkKQ0KKFhFTikgWzAwMDAwMDJhYzA0MmQ0MWZdICBbMDAwMDAwMDAwMDEwMDAw
MCwgMDAwMDAwMDAwOWJmZWZmZl0gKHVzYWJsZSkNCihYRU4pIFswMDAwMDAyYWMxNWE1OTlmXSAg
WzAwMDAwMDAwMDliZmYwMDAsIDAwMDAwMDAwMDlmZmZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFsw
MDAwMDAyYWMyNzk3NzI0XSAgWzAwMDAwMDAwMGEwMDAwMDAsIDAwMDAwMDAwMGExZmZmZmZdICh1
c2FibGUpDQooWEVOKSBbMDAwMDAwMmFjMzkwZTEzYV0gIFswMDAwMDAwMDBhMjAwMDAwLCAwMDAw
MDAwMDBhMjBjZmZmXSAoQUNQSSBOVlMpDQooWEVOKSBbMDAwMDAwMmFjNGFmZmViZl0gIFswMDAw
MDAwMDBhMjBkMDAwLCAwMDAwMDAwMGNhYmM4ZmZmXSAodXNhYmxlKQ0KKFhFTikgWzAwMDAwMDJh
YzVjNzViNWFdICBbMDAwMDAwMDBjYWJjOTAwMCwgMDAwMDAwMDBjYzE0Y2ZmZl0gKHJlc2VydmVk
KQ0KKFhFTikgWzAwMDAwMDJhYzZlNjZiNjRdICBbMDAwMDAwMDBjYzE0ZDAwMCwgMDAwMDAwMDBj
YzE5NWZmZl0gKEFDUEkgZGF0YSkNCihYRU4pIFswMDAwMDAyYWM4MDk0ZGQ3XSAgWzAwMDAwMDAw
Y2MxOTYwMDAsIDAwMDAwMDAwY2MzODhmZmZdIChBQ1BJIE5WUykNCihYRU4pIFswMDAwMDAyYWM5
Mjg2ZmFhXSAgWzAwMDAwMDAwY2MzODkwMDAsIDAwMDAwMDAwY2MzODlmZmZdIChyZXNlcnZlZCkN
CihYRU4pIFswMDAwMDAyYWNhNDc3YjQ5XSAgWzAwMDAwMDAwY2MzOGEwMDAsIDAwMDAwMDAwY2M3
MDlmZmZdIChBQ1BJIE5WUykNCihYRU4pIFswMDAwMDAyYWNiNjZhNjQ5XSAgWzAwMDAwMDAwY2M3
MGEwMDAsIDAwMDAwMDAwY2QxZmVmZmZdIChyZXNlcnZlZCkNCihYRU4pIFswMDAwMDAyYWNjODVh
ODY0XSAgWzAwMDAwMDAwY2QxZmYwMDAsIDAwMDAwMDAwY2RmZmZmZmZdICh1c2FibGUpDQooWEVO
KSBbMDAwMDAwMmFjZDlkMjA2OV0gIFswMDAwMDAwMGNlMDAwMDAwLCAwMDAwMDAwMGNmZmZmZmZm
XSAocmVzZXJ2ZWQpDQooWEVOKSBbMDAwMDAwMmFjZWJjM2RkMV0gIFswMDAwMDAwMGYwMDAwMDAw
LCAwMDAwMDAwMGY3ZmZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbMDAwMDAwMmFjZmRiNWFlMl0g
IFswMDAwMDAwMGZkMDAwMDAwLCAwMDAwMDAwMGZmZmZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBb
MDAwMDAwMmFkMGZhNmFlY10gIFswMDAwMDAwMTAwMDAwMDAwLCAwMDAwMDAwODBmMzNmZmZmXSAo
dXNhYmxlKQ0KKFhFTikgWzAwMDAwMDJhZDIxMWQ1MDJdICBbMDAwMDAwMDgwZjM0MDAwMCwgMDAw
MDAwMDg1MDFmZmZmZl0gKHJlc2VydmVkKQ0KKFhFTikgWzAwMDAwMDJhZGY5MDYzYWRdIEFDUEk6
IFJTRFAgQ0M2RjMwMTQsIDAwMjQgKHIyIEFMQVNLQSkNCihYRU4pIFswMDAwMDAyYWUwODU0MzQx
XSBBQ1BJOiBYU0RUIENDNkYyNzI4LCAwMEQ0IChyMSBBTEFTS0EgICBBIE0gSSAgIDEwNzIwMDkg
QU1JICAgMTAwMDAxMykNCihYRU4pIFswMDAwMDAyYWUxZjRjMGY0XSBBQ1BJOiBGQUNQIENDMThD
MDAwLCAwMTE0IChyNiBBTEFTS0EgICBBIE0gSSAgIDEwNzIwMDkgQU1JICAgICAxMDAxMykNCihY
RU4pIFswMDAwMDAyYWUzNjQyYzg3XSBBQ1BJOiBEU0RUIENDMTgzMDAwLCA4NzZEIChyMiBBTEFT
S0EgICBBIE0gSSAgIDEwNzIwMDkgSU5UTCAyMDEyMDkxMykNCihYRU4pIFswMDAwMDAyYWU0ZDNi
Yzk0XSBBQ1BJOiBGQUNTIENDNkMwMDAwLCAwMDQwDQooWEVOKSBbMDAwMDAwMmFlNTlhYjQ3YV0g
QUNQSTogU1NEVCBDQzE4RTAwMCwgNzIzQyAocjIgICAgQU1EIEFtZFRhYmxlICAgICAgICAyIE1T
RlQgIDQwMDAwMDApDQooWEVOKSBbMDAwMDAwMmFlNzBhMzI0YV0gQUNQSTogSVZSUyBDQzE4RDAw
MCwgMDFBNCAocjIgIEFNRCAgIEFtZFRhYmxlICAgICAgICAxIEFNRCAgICAgICAgIDApDQooWEVO
KSBbMDAwMDAwMmFlODc5YjQ4NF0gQUNQSTogRklEVCBDQzE4MjAwMCwgMDA5QyAocjEgQUxBU0tB
ICAgIEEgTSBJICAxMDcyMDA5IEFNSSAgICAgMTAwMTMpDQooWEVOKSBbMDAwMDAwMmFlOWU5MzZh
Ml0gQUNQSTogTUNGRyBDQzE4MTAwMCwgMDAzQyAocjEgQUxBU0tBICAgIEEgTSBJICAxMDcyMDA5
IE1TRlQgICAgMTAwMTMpDQooWEVOKSBbMDAwMDAwMmFlYjU4OTRiYV0gQUNQSTogSFBFVCBDQzE4
MDAwMCwgMDAzOCAocjEgQUxBU0tBICAgIEEgTSBJICAxMDcyMDA5IEFNSSAgICAgICAgIDUpDQoo
WEVOKSBbMDAwMDAwMmFlY2M4MjRjN10gQUNQSTogU1NEVCBDQzE3RjAwMCwgMDIyOCAocjEgICAg
QU1EICAgICBTVEQzICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAwMmFlZTM3
ODdhMV0gQUNQSTogVkZDVCBDQzE3MTAwMCwgRDY4NCAocjEgQUxBU0tBICAgQSBNIEkgICAgICAg
ICAxICBBTUQgMzE1MDRGNDcpDQooWEVOKSBbMDAwMDAwMmFlZmE3MDlkY10gQUNQSTogVFBNMiBD
QzE3MDAwMCwgMDA0QyAocjQgQUxBU0tBICAgQSBNIEkgICAgICAgICAxIEFNSSAgICAgICAgIDAp
DQooWEVOKSBbMDAwMDAwMmFmMTE2OTBiY10gQUNQSTogU1NEVCBDQzE2QzAwMCwgMzlGNCAocjEg
ICAgQU1EIEFtZFRhYmxlICAgICAgICAxIEFNRCAgICAgICAgIDEpDQooWEVOKSBbMDAwMDAwMmFm
Mjg1ZjgwMV0gQUNQSTogQ1JBVCBDQzE2QjAwMCwgMEYyOCAocjEgICAgQU1EIEFtZFRhYmxlICAg
ICAgICAxIEFNRCAgICAgICAgIDEpDQooWEVOKSBbMDAwMDAwMmFmM2Y1NzVkMV0gQUNQSTogQ0RJ
VCBDQzE2QTAwMCwgMDAyOSAocjEgICAgQU1EIEFtZFRhYmxlICAgICAgICAxIEFNRCAgICAgICAg
IDEpDQooWEVOKSBbMDAwMDAwMmFmNTY0ZjdlZl0gQUNQSTogU1NEVCBDQzE2OTAwMCwgMDEzOSAo
cjEgICAgQU1EIEFtZFRhYmxlICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAw
MmFmNmQ0N2E4MV0gQUNQSTogU1NEVCBDQzE2ODAwMCwgMDIyNyAocjEgICAgQU1EIEFtZFRhYmxl
ICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAwMmFmODQzZTE1Ml0gQUNQSTog
U1NEVCBDQzE2NzAwMCwgMEQzNyAocjEgICAgQU1EIEFtZFRhYmxlICAgICAgICAxIElOVEwgMjAx
MjA5MTMpDQooWEVOKSBbMDAwMDAwMmFmOWIzNTY2OV0gQUNQSTogU1NEVCBDQzE2NTAwMCwgMTBB
NSAocjEgICAgQU1EIEFtZFRhYmxlICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAw
MDAwMmFmYjIyZGNmMl0gQUNQSTogU1NEVCBDQzE2MTAwMCwgMzBDOCAocjEgICAgQU1EIEFtZFRh
YmxlICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAwMmFmYzkyNWY4NF0gQUNQ
STogV1NNVCBDQzE2MDAwMCwgMDAyOCAocjEgQUxBU0tBICAgQSBNIEkgICAxMDcyMDA5IEFNSSAg
ICAgMTAwMTMpDQooWEVOKSBbMDAwMDAwMmFmZTAxYzIwN10gQUNQSTogQVBJQyBDQzE1RjAwMCwg
MDBERSAocjMgQUxBU0tBICAgQSBNIEkgICAxMDcyMDA5IEFNSSAgICAgMTAwMTMpDQooWEVOKSBb
MDAwMDAwMmFmZjcxMzZhYV0gQUNQSTogU1NEVCBDQzE1RTAwMCwgMDA3RCAocjEgICAgQU1EIEFt
ZFRhYmxlICAgICAgICAxIElOVEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAwMmIwMGUwYjAyY10g
QUNQSTogU1NEVCBDQzE1RDAwMCwgMDUxNyAocjEgICAgQU1EIEFtZFRhYmxlICAgICAgICAxIElO
VEwgMjAxMjA5MTMpDQooWEVOKSBbMDAwMDAwMmIwMjUwMzI0YV0gQUNQSTogRlBEVCBDQzE1QzAw
MCwgMDA0NCAocjEgQUxBU0tBICAgQSBNIEkgICAxMDcyMDA5IEFNSSAgIDEwMDAwMTMpDQooWEVO
KSBbMDAwMDAwMmIwM2JmYTMzMF0gU3lzdGVtIFJBTTogMzIxNjhNQiAoMzI5NDA2NTZrQikNCihY
RU4pIFswMDAwMDAyYjA4ZWYzZmY5XSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQNCihYRU4p
IFswMDAwMDAyYjA5YmRkZWQ3XSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAw
MDAwMDgwZjM0MDAwMA0KKFhFTikgWzAwMDAwMDJiMTNjZDk4YTRdIERvbWFpbiBoZWFwIGluaXRp
YWxpc2VkDQooWEVOKSBbMDAwMDAwMmIxNWNkNmE2MV0gU01CSU9TIDMuMiBwcmVzZW50Lg0KKFhF
TikgWzAwMDAwMDJiMTY3ZTllYzNdIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4pIFsw
MDAwMDAyYjE3NDVjODYzXSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgwOCAoMzIgYml0cykN
CihYRU4pIFswMDAwMDAyYjE4NDI2ZjM5XSBBQ1BJOiB2NSBTTEVFUCBJTkZPOiBjb250cm9sWzA6
MF0sIHN0YXR1c1swOjBdDQooWEVOKSBbMDAwMDAwMmIxOTU5Y2JkNF0gQUNQSTogU0xFRVAgSU5G
TzogcG0xeF9jbnRbMTo4MDQsMTowXSwgcG0xeF9ldnRbMTo4MDAsMTowXQ0KKFhFTikgWzAwMDAw
MDJiMWE5ZjFiYzldIEFDUEk6IDMyLzY0WCBGQUNTIGFkZHJlc3MgbWlzbWF0Y2ggaW4gRkFEVCAt
IGNjNmMwMDAwLzAwMDAwMDAwMDAwMDAwMDAsIHVzaW5nIDMyDQooWEVOKSBbMDAwMDAwMmIxYzM4
YmExNl0gQUNQSTogICAgICAgICAgICAgd2FrZXVwX3ZlY1tjYzZjMDAwY10sIHZlY19zaXplWzIw
XQ0KKFhFTikgWzAwMDAwMDJiMWQ2NzJmZGNdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZl
ZTAwMDAwDQooWEVOKSBbMDAwMDAwMmIxZTU1OTc5Yl0gT3ZlcnJpZGluZyBBUElDIGRyaXZlciB3
aXRoIGJpZ3NtcA0KKFhFTikgWzAwMDAwMDJiMWYzZjIwOTRdIEFDUEk6IElPQVBJQyAoaWRbMHgx
MV0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNCihYRU4pIFswMDAwMDAyYjIwNzkw
MTNjXSBJT0FQSUNbMF06IGFwaWNfaWQgMTcsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAw
MCwgR1NJIDAtMjMNCihYRU4pIFswMDAwMDAyYjIxZDE4YTA0XSBBQ1BJOiBJT0FQSUMgKGlkWzB4
MTJdIGFkZHJlc3NbMHhmZWMwMTAwMF0gZ3NpX2Jhc2VbMjRdKQ0KKFhFTikgWzAwMDAwMDJiMjMw
ZjJiNjldIElPQVBJQ1sxXTogYXBpY19pZCAxOCwgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzAx
MDAwLCBHU0kgMjQtNTUNCihYRU4pIFswMDAwMDAyYjI0NmI5OGY0XSBBQ1BJOiBJTlRfU1JDX09W
UiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgWzAwMDAwMDJi
MjVhOTUwYzhdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5
IGxvdyBsZXZlbCkNCihYRU4pIFswMDAwMDAyYjI2ZWU5MzVlXSBBQ1BJOiBJUlEwIHVzZWQgYnkg
b3ZlcnJpZGUuDQooWEVOKSBbMDAwMDAwMmIyN2MxMmMxMV0gQUNQSTogSVJRMiB1c2VkIGJ5IG92
ZXJyaWRlLg0KKFhFTikgWzAwMDAwMDJiMjg5M2IyYTRdIEFDUEk6IElSUTkgdXNlZCBieSBvdmVy
cmlkZS4NCihYRU4pIFswMDAwMDAyYjI5NjYzZGY5XSBBQ1BJOiBIUEVUIGlkOiAweDEwMjI4MjAx
IGJhc2U6IDB4ZmVkMDAwMDANCihYRU4pIFswMDAwMDAyYjJhNmU1ZDJkXSBQQ0k6IE1DRkcgY29u
ZmlndXJhdGlvbiAwOiBiYXNlIGYwMDAwMDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIDdmDQoo
WEVOKSBbMDAwMDAwMmIyYmQ2MWVmMl0gUENJOiBNQ0ZHIGFyZWEgYXQgZjAwMDAwMDAgcmVzZXJ2
ZWQgaW4gRTgyMA0KKFhFTikgWzAwMDAwMDJiMmNlMjIzMDRdIFBDSTogVXNpbmcgTUNGRyBmb3Ig
c2VnbWVudCAwMDAwIGJ1cyAwMC03Zg0KKFhFTikgWzAwMDAwMDJiMmRlYTQyYzhdIFVzaW5nIEFD
UEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgWzAwMDAw
MDJiMmYxNGM1YmZdIFNNUDogQWxsb3dpbmcgMTYgQ1BVcyAoMCBob3RwbHVnIENQVXMpDQooWEVO
KSBbMDAwMDAwMmIzMDBkYTg1NV0gSVJRIGxpbWl0czogNTYgR1NJLCAzMjcyIE1TSS9NU0ktWA0K
KFhFTikgWzAwMDAwMDJiMzBmNzI0NjRdIENQVTA6IDE0MDAgLi4uIDI5MDAgTUh6DQooWEVOKSBb
MDAwMDAwMmIzMWI2OTE0Yl0geHN0YXRlOiBzaXplOiAweDM4MCBhbmQgc3RhdGVzOiAweDIwNw0K
KFhFTikgWzAwMDAwMDJiMzJhYjc3YzhdIENQVTA6IEFNRCBGYW0xN2ggbWFjaGluZSBjaGVjayBy
ZXBvcnRpbmcgZW5hYmxlZA0KKFhFTikgWzAwMDAwMDJiMzNjYTk1MzBdIFNwZWN1bGF0aXZlIG1p
dGlnYXRpb24gZmFjaWxpdGllczoNCihYRU4pIFswMDAwMDAyYjM0YjQyMmIxXSAgIEhhcmR3YXJl
IGhpbnRzOiBJQlJTX0ZBU1QgSUJSU19TQU1FX01PREUNCihYRU4pIFswMDAwMDAyYjM1YmM0MjU4
XSAgIEhhcmR3YXJlIGZlYXR1cmVzOiBJQlBCIElCUlMgU1RJQlAgU1NCRA0KKFhFTikgWzAwMDAw
MDJiMzZjMDhlYWVdICAgQ29tcGlsZWQtaW4gc3VwcG9ydDogSU5ESVJFQ1RfVEhVTksgUkVUVVJO
X1RIVU5LIFNIQURPV19QQUdJTkcgSEFSREVOX0FSUkFZIEhBUkRFTl9CUkFOQ0ggSEFSREVOX0dV
RVNUX0FDQ0VTUyBIQVJERU5fTE9DSw0KKFhFTikgWzAwMDAwMDJiMzhmZWFlMzFdICAgWGVuIHNl
dHRpbmdzOiBCVEktVGh1bms6IFJFVFBPTElORSwgU1BFQ19DVFJMOiBJQlJTLSBTVElCUCsgU1NC
RC0sIE90aGVyOiBCUkFOQ0hfSEFSREVODQooWEVOKSBbMDAwMDAwMmIzYWJhYzJmM10gICBTdXBw
b3J0IGZvciBIVk0gVk1zOiBNU1JfU1BFQ19DVFJMIE1TUl9WSVJUX1NQRUNfQ1RSTCBSU0IgSUJQ
Qi1lbnRyeQ0KKFhFTikgWzAwMDAwMDJiM2MyZGY4NTNdICAgU3VwcG9ydCBmb3IgUFYgVk1zOiBJ
QlBCLWVudHJ5DQooWEVOKSBbMDAwMDAwMmIzZDBmZTk4MV0gICBYUFRJICg2NC1iaXQgUFYgb25s
eSk6IERvbTAgZGlzYWJsZWQsIERvbVUgZGlzYWJsZWQgKHdpdGhvdXQgUENJRCkNCihYRU4pIFsw
MDAwMDAyYjNlN2I3MDUxXSAgIFBWIEwxVEYgc2hhZG93aW5nOiBEb20wIGRpc2FibGVkLCBEb21V
IGRpc2FibGVkDQooWEVOKSBbMDAwMDAwMmIzZjllN2JjNl0gVXNpbmcgc2NoZWR1bGVyOiBudWxs
IFNjaGVkdWxlciAobnVsbCkNCihYRU4pIFswMDAwMDAyYjQwOTc0NzQwXSBJbml0aWFsaXppbmcg
bnVsbCBzY2hlZHVsZXINCihYRU4pIFswMDAwMDAyYjQxNjVkZmUzXSBXQVJOSU5HOiBUaGlzIGlz
IGV4cGVyaW1lbnRhbCBzb2Z0d2FyZSBpbiBkZXZlbG9wbWVudC4NCihYRU4pIFswMDAwMDAyYjQy
OWJlZGFlXSBVc2UgYXQgeW91ciBvd24gcmlzay4NCihYRU4pIFswMDAwMDAyYjRiZWZhNjc4XSBQ
bGF0Zm9ybSB0aW1lciBpcyAxNC4zMThNSHogSFBFVA0KKFhFTikgWyAgICAwLjkzMDE2NV0gRGV0
ZWN0ZWQgMjg5NC41NDggTUh6IHByb2Nlc3Nvci4NCihYRU4pIFsgICAgMC45MzY2MzNdIEZyZWVk
IDEwMDhrQiB1bnVzZWQgQlNTIG1lbW9yeQ0KKFhFTikgWyAgICAwLjk0MTIyN10gRUZJIG1lbW9y
eSBtYXA6DQooWEVOKSBbICAgIDAuOTQ0NTIyXSAgMDAwMDAwMDAwMDAwMC0wMDAwMDAwMDAzZmZm
IHR5cGU9MiBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMC45NTE0NTVdICAwMDAw
MDAwMDA0MDAwLTAwMDAwMDAwOGVmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAwLjk1ODM4Nl0gIDAwMDAwMDAwOGYwMDAtMDAwMDAwMDA5ZWZmZiB0eXBlPTIgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDAuOTY1MzIwXSAgMDAwMDAwMDA5ZjAwMC0w
MDAwMDAwMDlmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMC45
NzIyNTNdICAwMDAwMDAwMTAwMDAwLTAwMDAwMDBlODlmZmYgdHlwZT0yIGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAwLjk3OTE4Nl0gIDAwMDAwMDBlOGEwMDAtMDAwMDAwMGZmZmZm
ZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDAuOTg2MTIxXSAgMDAw
MDAwMTAwMDAwMC0wMDAwMDAxMDFmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMC45OTMwNTVdICAwMDAwMDAxMDIwMDAwLTAwMDAwMDliZmVmZmYgdHlwZT03IGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAwLjk5OTk4N10gIDAwMDAwMDliZmYwMDAt
MDAwMDAwOWZmZmZmZiB0eXBlPTAgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEu
MDA2OTIyXSAgMDAwMDAwYTAwMDAwMC0wMDAwMDBhMWZmZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMS4wMTM4NTRdICAwMDAwMDBhMjAwMDAwLTAwMDAwMGEyMGNm
ZmYgdHlwZT0xMCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4wMjA4NzRdICAw
MDAwMDBhMjBkMDAwLTAwMDAwMTZkMDVmZmYgdHlwZT0yIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAxLjAyNzgwOV0gIDAwMDAwMTZkMDYwMDAtMDAwMDBjNGY4N2ZmZiB0eXBlPTcg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMDM0NzQwXSAgMDAwMDBjNGY4ODAw
MC0wMDAwMGM3MDljZmZmIHR5cGU9MSBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
MS4wNDE2NzVdICAwMDAwMGM3MDlkMDAwLTAwMDAwYzcxYjJmZmYgdHlwZT03IGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjA0ODYwOV0gIDAwMDAwYzcxYjMwMDAtMDAwMDBjNzFk
YmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMDU1NTQxXSAg
MDAwMDBjNzFkYzAwMC0wMDAwMGM3MjE2ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMS4wNjI0NzZdICAwMDAwMGM3MjE3MDAwLTAwMDAwYzcyMThmZmYgdHlwZT03
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjA2OTQwOF0gIDAwMDAwYzcyMTkw
MDAtMDAwMDBjNzIxOWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDEuMDc2MzQxXSAgMDAwMDBjNzIxYTAwMC0wMDAwMGM3MjI1ZmZmIHR5cGU9MyBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4wODMyNzRdICAwMDAwMGM3MjI2MDAwLTAwMDAwYzcy
MjdmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjA5MDIwOV0g
IDAwMDAwYzcyMjgwMDAtMDAwMDBjNzIyY2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDEuMDk3MTQxXSAgMDAwMDBjNzIyZDAwMC0wMDAwMGM3MjMyZmZmIHR5cGU9
NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4xMDQwNzZdICAwMDAwMGM3MjMz
MDAwLTAwMDAwYzcyMzNmZmYgdHlwZT0yIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAxLjExMTAwN10gIDAwMDAwYzcyMzQwMDAtMDAwMDBjNzIzNWZmZiB0eXBlPTcgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMTE3OTQwXSAgMDAwMDBjNzIzNjAwMC0wMDAwMGM3
MjM4ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4xMjQ4NzZd
ICAwMDAwMGM3MjM5MDAwLTAwMDAwYzcyM2NmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAxLjEzMTgwOV0gIDAwMDAwYzcyM2QwMDAtMDAwMDBjNzI1MWZmZiB0eXBl
PTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMTM4NzQxXSAgMDAwMDBjNzI1
MjAwMC0wMDAwMGM3MjVmZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMS4xNDU2NzZdICAwMDAwMGM3MjYwMDAwLTAwMDAwYzcyOWRmZmYgdHlwZT00IGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjE1MjYwOF0gIDAwMDAwYzcyOWUwMDAtMDAwMDBj
NzI5ZmZmZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMTU5NTQz
XSAgMDAwMDBjNzJhMDAwMC0wMDAwMGM3MmExZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMS4xNjY0NzRdICAwMDAwMGM3MmEyMDAwLTAwMDAwYzcyYTNmZmYgdHlw
ZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjE3MzQwOV0gIDAwMDAwYzcy
YTQwMDAtMDAwMDBjNzJhNGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDEuMTgwMzQzXSAgMDAwMDBjNzJhNTAwMC0wMDAwMGM3MmE1ZmZmIHR5cGU9NyBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4xODcyNzRdICAwMDAwMGM3MmE2MDAwLTAwMDAw
YzcyYTdmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjE5NDIx
MF0gIDAwMDAwYzcyYTgwMDAtMDAwMDBjNzJhYWZmZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDEuMjAxMTQyXSAgMDAwMDBjNzJhYjAwMC0wMDAwMGM3MmFiZmZmIHR5
cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4yMDgwNzRdICAwMDAwMGM3
MmFjMDAwLTAwMDAwYzcyYWRmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAxLjIxNTAwN10gIDAwMDAwYzcyYWUwMDAtMDAwMDBjNzJiMGZmZiB0eXBlPTQgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMjIxOTQzXSAgMDAwMDBjNzJiMTAwMC0wMDAw
MGM3MmJiZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4yMjg4
NzRdICAwMDAwMGM3MmJjMDAwLTAwMDAwYzcyYmVmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAxLjIzNTgxMF0gIDAwMDAwYzcyYmYwMDAtMDAwMDBjNzJjMmZmZiB0
eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMjQyNzQ0XSAgMDAwMDBj
NzJjMzAwMC0wMDAwMGM3MmM0ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMS4yNDk2NzRdICAwMDAwMGM3MmM1MDAwLTAwMDAwYzcyYzZmZmYgdHlwZT03IGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjI1NjYwOV0gIDAwMDAwYzcyYzcwMDAtMDAw
MDBjNzJjOGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMjYz
NTQxXSAgMDAwMDBjNzJjOTAwMC0wMDAwMGM3MmNhZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMS4yNzA0NzddICAwMDAwMGM3MmNiMDAwLTAwMDAwYzcyY2JmZmYg
dHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjI3NzQwOV0gIDAwMDAw
YzcyY2MwMDAtMDAwMDBjNzJjY2ZmZiB0eXBlPTcgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDEuMjg0MzQyXSAgMDAwMDBjNzJjZDAwMC0wMDAwMGM3MmNlZmZmIHR5cGU9NCBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4yOTEyNzddICAwMDAwMGM3MmNmMDAwLTAw
MDAwYzcyZDFmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjI5
ODIxMF0gIDAwMDAwYzcyZDIwMDAtMDAwMDBjNzJkM2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDEuMzA1MTQ0XSAgMDAwMDBjNzJkNDAwMC0wMDAwMGM3Mzc2ZmZm
IHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4zMTIwNzZdICAwMDAw
MGM3Mzc3MDAwLTAwMDAwYzc4NWFmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAxLjMxOTAxMV0gIDAwMDAwYzc4NWIwMDAtMDAwMDBjNzlkMmZmZiB0eXBlPTMgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMzI1OTQzXSAgMDAwMDBjNzlkMzAwMC0w
MDAwMGM3YTJlZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4z
MzI4NzVdICAwMDAwMGM3YTJmMDAwLTAwMDAwYzdhNGNmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAxLjMzOTgxMF0gIDAwMDAwYzdhNGQwMDAtMDAwMDBjN2E1ZGZm
ZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuMzQ2NzQxXSAgMDAw
MDBjN2E1ZTAwMC0wMDAwMGM3YWU3ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMS4zNTM2NzVdICAwMDAwMGM3YWU4MDAwLTAwMDAwYzdiMDdmZmYgdHlwZT0zIGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjM2MDYwOF0gIDAwMDAwYzdiMDgwMDAt
MDAwMDBjN2IwOGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEu
MzY3NTQ0XSAgMDAwMDBjN2IwOTAwMC0wMDAwMGM3YjEwZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMS4zNzQ0NzVdICAwMDAwMGM3YjExMDAwLTAwMDAwYzdiMThm
ZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjM4MTQwOV0gIDAw
MDAwYzdiMTkwMDAtMDAwMDBjN2IzMGZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDEuMzg4MzQ0XSAgMDAwMDBjN2IzMTAwMC0wMDAwMGM3YjMyZmZmIHR5cGU9NCBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS4zOTUyNzVdICAwMDAwMGM3YjMzMDAw
LTAwMDAwYzdiNTVmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAx
LjQwMjIxMF0gIDAwMDAwYzdiNTYwMDAtMDAwMDBjN2I2MGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNDA5MTQ0XSAgMDAwMDBjN2I2MTAwMC0wMDAwMGM3Yjhj
ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS40MTYwNzVdICAw
MDAwMGM3YjhkMDAwLTAwMDAwYzkyNzBmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAxLjQyMzAwOV0gIDAwMDAwYzkyNzEwMDAtMDAwMDBjOTJkN2ZmZiB0eXBlPTMg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNDI5OTQ0XSAgMDAwMDBjOTJkODAw
MC0wMDAwMGM5MmRiZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
MS40MzY4NzhdICAwMDAwMGM5MmRjMDAwLTAwMDAwYzkyZTVmZmYgdHlwZT0zIGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjQ0MzgwOV0gIDAwMDAwYzkyZTYwMDAtMDAwMDBjOTMz
MGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNDUwNzQ0XSAg
MDAwMDBjOTMzMTAwMC0wMDAwMGM5MzRhZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMS40NTc2NzZdICAwMDAwMGM5MzRiMDAwLTAwMDAwYzkzNGVmZmYgdHlwZT00
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjQ2NDYxMV0gIDAwMDAwYzkzNGYw
MDAtMDAwMDBjOTM2Y2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDEuNDcxNTQyXSAgMDAwMDBjOTM2ZDAwMC0wMDAwMGM5MzZkZmZmIHR5cGU9NCBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS40Nzg0NzddICAwMDAwMGM5MzZlMDAwLTAwMDAwYzkz
NzRmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjQ4NTQwOV0g
IDAwMDAwYzkzNzUwMDAtMDAwMDBjOTM3YmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDEuNDkyMzQ1XSAgMDAwMDBjOTM3YzAwMC0wMDAwMGM5Mzg5ZmZmIHR5cGU9
MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS40OTkyNzVdICAwMDAwMGM5Mzhh
MDAwLTAwMDAwYzkzOGVmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAxLjUwNjIwOV0gIDAwMDAwYzkzOGYwMDAtMDAwMDBjOTM5MGZmZiB0eXBlPTMgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNTEzMTQzXSAgMDAwMDBjOTM5MTAwMC0wMDAwMGM5
MzkyZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS41MjAwNzVd
ICAwMDAwMGM5MzkzMDAwLTAwMDAwYzkzOTlmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAxLjUyNzAwOV0gIDAwMDAwYzkzOWEwMDAtMDAwMDBjOTM5YmZmZiB0eXBl
PTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNTMzOTQ0XSAgMDAwMDBjOTM5
YzAwMC0wMDAwMGM5MzljZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMS41NDA4NzhdICAwMDAwMGM5MzlkMDAwLTAwMDAwYzkzYTBmZmYgdHlwZT00IGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjU0NzgwOV0gIDAwMDAwYzkzYTEwMDAtMDAwMDBj
OTNiN2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNTU0NzQz
XSAgMDAwMDBjOTNiODAwMC0wMDAwMGM5M2I5ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMS41NjE2NzhdICAwMDAwMGM5M2JhMDAwLTAwMDAwYzkzYmJmZmYgdHlw
ZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjU2ODYxMV0gIDAwMDAwYzkz
YmMwMDAtMDAwMDBjOTNiY2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDEuNTc1NTQ1XSAgMDAwMDBjOTNiZDAwMC0wMDAwMGM5M2NiZmZmIHR5cGU9MyBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS41ODI0NzZdICAwMDAwMGM5M2NjMDAwLTAwMDAw
YzkzZDRmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjU4OTQx
MV0gIDAwMDAwYzkzZDUwMDAtMDAwMDBjOTNkNmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDEuNTk2MzQzXSAgMDAwMDBjOTNkNzAwMC0wMDAwMGM5M2Q4ZmZmIHR5
cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS42MDMyNzhdICAwMDAwMGM5
M2Q5MDAwLTAwMDAwYzkzZDlmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAxLjYxMDIwOV0gIDAwMDAwYzkzZGEwMDAtMDAwMDBjOTNkYWZmZiB0eXBlPTQgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNjE3MTQ2XSAgMDAwMDBjOTNkYjAwMC0wMDAw
MGM5M2RiZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS42MjQw
NzZdICAwMDAwMGM5M2RjMDAwLTAwMDAwYzk1MjlmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAxLjYzMTAxMl0gIDAwMDAwYzk1MmEwMDAtMDAwMDBjOTUzM2ZmZiB0
eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNjM3OTQ0XSAgMDAwMDBj
OTUzNDAwMC0wMDAwMGM5NTM1ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMS42NDQ4NzhdICAwMDAwMGM5NTM2MDAwLTAwMDAwYzk1MzlmZmYgdHlwZT0zIGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjY1MTgwOV0gIDAwMDAwYzk1M2EwMDAtMDAw
MDBjOTUzZGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNjU4
NzQ1XSAgMDAwMDBjOTUzZTAwMC0wMDAwMGM5NTQ1ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMS42NjU2NzZdICAwMDAwMGM5NTQ2MDAwLTAwMDAwYzk1NDdmZmYg
dHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjY3MjYxMV0gIDAwMDAw
Yzk1NDgwMDAtMDAwMDBjOTU0YmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDEuNjc5NTQ2XSAgMDAwMDBjOTU0YzAwMC0wMDAwMGM5NTRkZmZmIHR5cGU9NCBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS42ODY0NzddICAwMDAwMGM5NTRlMDAwLTAw
MDAwYzk1NTZmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjY5
MzQxMl0gIDAwMDAwYzk1NTcwMDAtMDAwMDBjOTU1YWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDEuNzAwMzQ1XSAgMDAwMDBjOTU1YjAwMC0wMDAwMGM5NTVjZmZm
IHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS43MDcyNzZdICAwMDAw
MGM5NTVkMDAwLTAwMDAwYzk1NWZmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAxLjcxNDIxMl0gIDAwMDAwYzk1NjAwMDAtMDAwMDBjOTU2Y2ZmZiB0eXBlPTMgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNzIxMTQ0XSAgMDAwMDBjOTU2ZDAwMC0w
MDAwMGM5N2ZmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS43
MjgwNzZdICAwMDAwMGM5ODAwMDAwLTAwMDAwYzk4MWFmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAxLjczNTAxMl0gIDAwMDAwYzk4MWIwMDAtMDAwMDBjOTgyYWZm
ZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuNzQxOTQzXSAgMDAw
MDBjOTgyYjAwMC0wMDAwMGM5ODNkZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMS43NDg4NzldICAwMDAwMGM5ODNlMDAwLTAwMDAwYzk4M2ZmZmYgdHlwZT00IGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjc1NTgxMV0gIDAwMDAwYzk4NDAwMDAt
MDAwMDBjOTg0M2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEu
NzYyNzQ2XSAgMDAwMDBjOTg0NDAwMC0wMDAwMGM5ODQ4ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMS43Njk2NzddICAwMDAwMGM5ODQ5MDAwLTAwMDAwYzk4NWJm
ZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjc3NjYxMl0gIDAw
MDAwYzk4NWMwMDAtMDAwMDBjOTg2MGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDEuNzgzNTQ0XSAgMDAwMDBjOTg2MTAwMC0wMDAwMGM5ODYxZmZmIHR5cGU9MyBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS43OTA0NzldICAwMDAwMGM5ODYyMDAw
LTAwMDAwYzk4NjJmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAx
Ljc5NzQxMl0gIDAwMDAwYzk4NjMwMDAtMDAwMDBjOTg2M2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDEuODA0MzQ2XSAgMDAwMDBjOTg2NDAwMC0wMDAwMGM5ODY2
ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS44MTEyNzddICAw
MDAwMGM5ODY3MDAwLTAwMDAwYzk4NzRmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAxLjgxODIxM10gIDAwMDAwYzk4NzUwMDAtMDAwMDBjOTg3NWZmZiB0eXBlPTQg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuODI1MTQ1XSAgMDAwMDBjOTg3NjAw
MC0wMDAwMGM5ODc2ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
MS44MzIwNzldICAwMDAwMGM5ODc3MDAwLTAwMDAwYzk4ODJmZmYgdHlwZT00IGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjgzOTAxMV0gIDAwMDAwYzk4ODMwMDAtMDAwMDBjOTg4
YmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuODQ1OTQ2XSAg
MDAwMDBjOTg4YzAwMC0wMDAwMGM5ODhlZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMS44NTI4NzldICAwMDAwMGM5ODhmMDAwLTAwMDAwYzk4OTRmZmYgdHlwZT0z
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjg1OTgxMV0gIDAwMDAwYzk4OTUw
MDAtMDAwMDBjOThlMWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDEuODY2NzQ0XSAgMDAwMDBjOThlMjAwMC0wMDAwMGM5OTBmZmZmIHR5cGU9MyBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS44NzM2ODBdICAwMDAwMGM5OTEwMDAwLTAwMDAwYzk5
MTFmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjg4MDYxM10g
IDAwMDAwYzk5MTIwMDAtMDAwMDBjOTkxM2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDEuODg3NTQ0XSAgMDAwMDBjOTkxNDAwMC0wMDAwMGM5OTE1ZmZmIHR5cGU9
NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS44OTQ0NzldICAwMDAwMGM5OTE2
MDAwLTAwMDAwYzk5MmRmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAxLjkwMTQxMV0gIDAwMDAwYzk5MmUwMDAtMDAwMDBjOTkzOWZmZiB0eXBlPTQgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuOTA4MzQ0XSAgMDAwMDBjOTkzYTAwMC0wMDAwMGM5
OTYwZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS45MTUyNzld
ICAwMDAwMGM5OTYxMDAwLTAwMDAwYzk5NjRmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAxLjkyMjIxM10gIDAwMDAwYzk5NjUwMDAtMDAwMDBjOTk2Y2ZmZiB0eXBl
PTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuOTI5MTQ0XSAgMDAwMDBjOTk2
ZDAwMC0wMDAwMGM5OTc0ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMS45MzYwNzhdICAwMDAwMGM5OTc1MDAwLTAwMDAwYzk5N2VmZmYgdHlwZT0zIGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjk0MzAxMl0gIDAwMDAwYzk5N2YwMDAtMDAwMDBj
OTk4OGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDEuOTQ5OTQ3
XSAgMDAwMDBjOTk4OTAwMC0wMDAwMGM5OWFkZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMS45NTY4NzldICAwMDAwMGM5OWFlMDAwLTAwMDAwYzk5YjdmZmYgdHlw
ZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjk2MzgxMV0gIDAwMDAwYzk5
YjgwMDAtMDAwMDBjOTliOGZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDEuOTcwNzQ2XSAgMDAwMDBjOTliOTAwMC0wMDAwMGM5OWI5ZmZmIHR5cGU9NCBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS45Nzc2ODBdICAwMDAwMGM5OWJhMDAwLTAwMDAw
Yzk5YzFmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAxLjk4NDYx
Ml0gIDAwMDAwYzk5YzIwMDAtMDAwMDBjOTljNGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDEuOTkxNTQ2XSAgMDAwMDBjOTljNTAwMC0wMDAwMGM5OWM2ZmZmIHR5
cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMS45OTg0NzhdICAwMDAwMGM5
OWM3MDAwLTAwMDAwYzk5YzdmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAyLjAwNTQxMl0gIDAwMDAwYzk5YzgwMDAtMDAwMDBjOTlkNWZmZiB0eXBlPTMgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMDEyMzQ1XSAgMDAwMDBjOTlkNjAwMC0wMDAw
MGM5OWQ5ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4wMTky
NzhdICAwMDAwMGM5OWRhMDAwLTAwMDAwYzk5ZGZmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAyLjAyNjIxMl0gIDAwMDAwYzk5ZTAwMDAtMDAwMDBjOTllNWZmZiB0
eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMDMzMTQ3XSAgMDAwMDBj
OTllNjAwMC0wMDAwMGM5OWU2ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMi4wNDAwNzldICAwMDAwMGM5OWU3MDAwLTAwMDAwYzk5ZThmZmYgdHlwZT00IGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjA0NzAxMl0gIDAwMDAwYzk5ZTkwMDAtMDAw
MDBjOTlmZGZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMDUz
OTQ1XSAgMDAwMDBjOTlmZTAwMC0wMDAwMGM5OWZlZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMi4wNjA4ODBdICAwMDAwMGM5OWZmMDAwLTAwMDAwYzlhMDFmZmYg
dHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjA2NzgxMl0gIDAwMDAw
YzlhMDIwMDAtMDAwMDBjOWEwMmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDIuMDc0NzQ3XSAgMDAwMDBjOWEwMzAwMC0wMDAwMGM5YTEyZmZmIHR5cGU9MyBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4wODE2NzhdICAwMDAwMGM5YTEzMDAwLTAw
MDAwYzlhMTVmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjA4
ODYxMV0gIDAwMDAwYzlhMTYwMDAtMDAwMDBjOWExN2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDIuMDk1NTQ3XSAgMDAwMDBjOWExODAwMC0wMDAwMGM5YTE5ZmZm
IHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4xMDI0NzldICAwMDAw
MGM5YTFhMDAwLTAwMDAwYzlhMmZmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAyLjEwOTQxMV0gIDAwMDAwYzlhMzAwMDAtMDAwMDBjOWEzMGZmZiB0eXBlPTQgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMTE2MzQ3XSAgMDAwMDBjOWEzMTAwMC0w
MDAwMGM5YTMxZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4x
MjMyNzhdICAwMDAwMGM5YTMyMDAwLTAwMDAwYzlhMzJmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAyLjEzMDIxM10gIDAwMDAwYzlhMzMwMDAtMDAwMDBjOWEzM2Zm
ZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMTM3MTQ3XSAgMDAw
MDBjOWEzNDAwMC0wMDAwMGM5YTM0ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMi4xNDQwNzhdICAwMDAwMGM5YTM1MDAwLTAwMDAwYzlhMzVmZmYgdHlwZT0zIGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjE1MTAxMl0gIDAwMDAwYzlhMzYwMDAt
MDAwMDBjOWEzNmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIu
MTU3OTQ2XSAgMDAwMDBjOWEzNzAwMC0wMDAwMGM5YTM3ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMi4xNjQ4ODFdICAwMDAwMGM5YTM4MDAwLTAwMDAwYzlhMzhm
ZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjE3MTgxMl0gIDAw
MDAwYzlhMzkwMDAtMDAwMDBjOWE0YmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDIuMTc4NzQ2XSAgMDAwMDBjOWE0YzAwMC0wMDAwMGM5YTRkZmZmIHR5cGU9NCBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4xODU2ODBdICAwMDAwMGM5YTRlMDAw
LTAwMDAwYzlhNTJmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAy
LjE5MjYxMl0gIDAwMDAwYzlhNTMwMDAtMDAwMDBjOWE1N2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMTk5NTQ3XSAgMDAwMDBjOWE1ODAwMC0wMDAwMGM5YTVj
ZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4yMDY0NzldICAw
MDAwMGM5YTVkMDAwLTAwMDAwYzlhNWZmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAyLjIxMzQxMl0gIDAwMDAwYzlhNjAwMDAtMDAwMDBjOWE2NmZmZiB0eXBlPTMg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMjIwMzQ3XSAgMDAwMDBjOWE2NzAw
MC0wMDAwMGM5YTY5ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
Mi4yMjcyODBdICAwMDAwMGM5YTZhMDAwLTAwMDAwYzlhNzNmZmYgdHlwZT0zIGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjIzNDIxNF0gIDAwMDAwYzlhNzQwMDAtMDAwMDBjOWE4
YWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMjQxMTQ2XSAg
MDAwMDBjOWE4YjAwMC0wMDAwMGM5YTljZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYN
CihYRU4pIFsgICAgMi4yNDgwNzldICAwMDAwMGM5YTlkMDAwLTAwMDAwYzlhOWRmZmYgdHlwZT00
IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjI1NTAxNV0gIDAwMDAwYzlhOWUw
MDAtMDAwMDBjOWE5ZmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAg
IDIuMjYxOTQ2XSAgMDAwMDBjOWFhMDAwMC0wMDAwMGM5YWE3ZmZmIHR5cGU9NCBhdHRyPTAwMDAw
MDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4yNjg4ODBdICAwMDAwMGM5YWE4MDAwLTAwMDAwYzlh
YThmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjI3NTgxNV0g
IDAwMDAwYzlhYTkwMDAtMDAwMDBjOWFhOWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDIuMjgyNzQ2XSAgMDAwMDBjOWFhYTAwMC0wMDAwMGM5YWFhZmZmIHR5cGU9
MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4yODk2ODFdICAwMDAwMGM5YWFi
MDAwLTAwMDAwYzlhYWNmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAg
ICAyLjI5NjYxNV0gIDAwMDAwYzlhYWQwMDAtMDAwMDBjOWFiMWZmZiB0eXBlPTMgYXR0cj0wMDAw
MDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMzAzNTQ2XSAgMDAwMDBjOWFiMjAwMC0wMDAwMGM5
YWIzZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4zMTA0ODFd
ICAwMDAwMGM5YWI0MDAwLTAwMDAwYzlhYjdmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAw
Zg0KKFhFTikgWyAgICAyLjMxNzQxNV0gIDAwMDAwYzlhYjgwMDAtMDAwMDBjOWFiOGZmZiB0eXBl
PTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMzI0MzQ2XSAgMDAwMDBjOWFi
OTAwMC0wMDAwMGM5YWJlZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMi4zMzEyNzldICAwMDAwMGM5YWJmMDAwLTAwMDAwYzlhYmZmZmYgdHlwZT00IGF0dHI9MDAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjMzODIxNF0gIDAwMDAwYzlhYzAwMDAtMDAwMDBj
OWFjYmZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuMzQ1MTQ3
XSAgMDAwMDBjOWFjYzAwMC0wMDAwMGM5YWNjZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMi4zNTIwODBdICAwMDAwMGM5YWNkMDAwLTAwMDAwYzlhY2VmZmYgdHlw
ZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjM1OTAxM10gIDAwMDAwYzlh
Y2YwMDAtMDAwMDBjOWFkMGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDIuMzY1OTQ4XSAgMDAwMDBjOWFkMTAwMC0wMDAwMGM5YWQxZmZmIHR5cGU9MyBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4zNzI4NzldICAwMDAwMGM5YWQyMDAwLTAwMDAw
YzlhZDJmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjM3OTgx
NF0gIDAwMDAwYzlhZDMwMDAtMDAwMDBjOWFlZWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDIuMzg2NzQ5XSAgMDAwMDBjOWFlZjAwMC0wMDAwMGM5YWYxZmZmIHR5
cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi4zOTM2ODFdICAwMDAwMGM5
YWYyMDAwLTAwMDAwYzlhZjNmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAyLjQwMDYxNV0gIDAwMDAwYzlhZjQwMDAtMDAwMDBjOWFmN2ZmZiB0eXBlPTQgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNDA3NTQ2XSAgMDAwMDBjOWFmODAwMC0wMDAw
MGM5YWZiZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi40MTQ0
ODBdICAwMDAwMGM5YWZjMDAwLTAwMDAwYzlhZmRmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAyLjQyMTQxM10gIDAwMDAwYzlhZmUwMDAtMDAwMDBjOWIwN2ZmZiB0
eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNDI4MzQ3XSAgMDAwMDBj
OWIwODAwMC0wMDAwMGM5ZjA3ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMi40MzUyODFdICAwMDAwMGM5ZjA4MDAwLTAwMDAwYzlmMjdmZmYgdHlwZT0zIGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjQ0MjIxNF0gIDAwMDAwYzlmMjgwMDAtMDAw
MDBjOWYyOWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNDQ5
MTQ4XSAgMDAwMDBjOWYyYTAwMC0wMDAwMGM5ZjJiZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMi40NTYwODBdICAwMDAwMGM5ZjJjMDAwLTAwMDAwYzlmMmRmZmYg
dHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjQ2MzAxNV0gIDAwMDAw
YzlmMmUwMDAtMDAwMDBjOWYyZWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDIuNDY5OTQ3XSAgMDAwMDBjOWYyZjAwMC0wMDAwMGM5ZjJmZmZmIHR5cGU9NCBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi40NzY4ODJdICAwMDAwMGM5ZjMwMDAwLTAw
MDAwYzlmMzBmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjQ4
MzgxM10gIDAwMDAwYzlmMzEwMDAtMDAwMDBjOWYzMWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDIuNDkwNzQ5XSAgMDAwMDBjOWYzMjAwMC0wMDAwMGM5ZjM2ZmZm
IHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi40OTc2ODBdICAwMDAw
MGM5ZjM3MDAwLTAwMDAwYzlmM2FmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhF
TikgWyAgICAyLjUwNDYxNV0gIDAwMDAwYzlmM2IwMDAtMDAwMDBjOWYzYmZmZiB0eXBlPTMgYXR0
cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNTExNTQ4XSAgMDAwMDBjOWYzYzAwMC0w
MDAwMGM5ZjNjZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi41
MTg0ODNdICAwMDAwMGM5ZjNkMDAwLTAwMDAwYzlmM2RmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAw
MDAwMDAwZg0KKFhFTikgWyAgICAyLjUyNTQxNF0gIDAwMDAwYzlmM2UwMDAtMDAwMDBjYTQxMWZm
ZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNTMyMzQ4XSAgMDAw
MDBjYTQxMjAwMC0wMDAwMGNhNDEzZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihY
RU4pIFsgICAgMi41MzkyODNdICAwMDAwMGNhNDE0MDAwLTAwMDAwY2E0MTVmZmYgdHlwZT00IGF0
dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjU0NjIxNF0gIDAwMDAwY2E0MTYwMDAt
MDAwMDBjYTQxY2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIu
NTUzMTQ3XSAgMDAwMDBjYTQxZDAwMC0wMDAwMGNhNDFkZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAw
MDAwMDAwMGYNCihYRU4pIFsgICAgMi41NjAwODJdICAwMDAwMGNhNDFlMDAwLTAwMDAwY2E0MWVm
ZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjU2NzAxN10gIDAw
MDAwY2E0MWYwMDAtMDAwMDBjYTQ4OGZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQoo
WEVOKSBbICAgIDIuNTczOTQ5XSAgMDAwMDBjYTQ4OTAwMC0wMDAwMGNhNDg5ZmZmIHR5cGU9MyBh
dHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi41ODA4ODFdICAwMDAwMGNhNDhhMDAw
LTAwMDAwY2E0OGJmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAy
LjU4NzgxNl0gIDAwMDAwY2E0OGMwMDAtMDAwMDBjYTQ4Y2ZmZiB0eXBlPTMgYXR0cj0wMDAwMDAw
MDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNTk0NzQ3XSAgMDAwMDBjYTQ4ZDAwMC0wMDAwMGNhNDkx
ZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi42MDE2ODNdICAw
MDAwMGNhNDkyMDAwLTAwMDAwY2E0OTRmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0K
KFhFTikgWyAgICAyLjYwODYxNl0gIDAwMDAwY2E0OTUwMDAtMDAwMDBjYWJjOGZmZiB0eXBlPTQg
YXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNjE1NTQ4XSAgMDAwMDBjYWJjOTAw
MC0wMDAwMGNjMTRjZmZmIHR5cGU9MCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAg
Mi42MjI0ODNdICAwMDAwMGNjMTRkMDAwLTAwMDAwY2MxOTVmZmYgdHlwZT05IGF0dHI9MDAwMDAw
MDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjYyOTQxNF0gIDAwMDAwY2MxOTYwMDAtMDAwMDBjYzM4
OGZmZiB0eXBlPTEwIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjYzNjQzNF0g
IDAwMDAwY2MzODkwMDAtMDAwMDBjYzM4OWZmZiB0eXBlPTAgYXR0cj0wMDAwMDAwMDAwMDAwMDBm
DQooWEVOKSBbICAgIDIuNjQzMzY3XSAgMDAwMDBjYzM4YTAwMC0wMDAwMGNjNzA5ZmZmIHR5cGU9
MTAgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNjUwMzg5XSAgMDAwMDBjYzcw
YTAwMC0wMDAwMGNkMTc5ZmZmIHR5cGU9NiBhdHRyPTgwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsg
ICAgMi42NTczMjJdICAwMDAwMGNkMTdhMDAwLTAwMDAwY2QxZmVmZmYgdHlwZT01IGF0dHI9ODAw
MDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjY2NDI1Nl0gIDAwMDAwY2QxZmYwMDAtMDAwMDBj
ZDdmZmZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNjcxMTg5
XSAgMDAwMDBjZDgwMDAwMC0wMDAwMGNkOGU5ZmZmIHR5cGU9NyBhdHRyPTAwMDAwMDAwMDAwMDAw
MGYNCihYRU4pIFsgICAgMi42NzgxMjNdICAwMDAwMGNkOGVhMDAwLTAwMDAwY2Q5ZTlmZmYgdHlw
ZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjY4NTA1Nl0gIDAwMDAwY2Q5
ZWEwMDAtMDAwMDBjZGEwNWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBb
ICAgIDIuNjkxOTkwXSAgMDAwMDBjZGEwNjAwMC0wMDAwMGNkYTMxZmZmIHR5cGU9NCBhdHRyPTAw
MDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi42OTg5MjNdICAwMDAwMGNkYTMyMDAwLTAwMDAw
Y2RhNDRmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjcwNTg1
N10gIDAwMDAwY2RhNDUwMDAtMDAwMDBjZGY1N2ZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAw
MDBmDQooWEVOKSBbICAgIDIuNzEyNzg5XSAgMDAwMDBjZGY1ODAwMC0wMDAwMGNkZjVhZmZmIHR5
cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi43MTk3MjRdICAwMDAwMGNk
ZjViMDAwLTAwMDAwY2RmNmRmZmYgdHlwZT00IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikg
WyAgICAyLjcyNjY1NF0gIDAwMDAwY2RmNmUwMDAtMDAwMDBjZGY3N2ZmZiB0eXBlPTMgYXR0cj0w
MDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNzMzNTkwXSAgMDAwMDBjZGY3ODAwMC0wMDAw
MGNkZjkxZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi43NDA1
MjJdICAwMDAwMGNkZjkyMDAwLTAwMDAwY2RmOTdmZmYgdHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAw
MDAwZg0KKFhFTikgWyAgICAyLjc0NzQ1N10gIDAwMDAwY2RmOTgwMDAtMDAwMDBjZGZhZGZmZiB0
eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNzU0Mzg4XSAgMDAwMDBj
ZGZhZTAwMC0wMDAwMGNkZmIxZmZmIHR5cGU9MyBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4p
IFsgICAgMi43NjEzMjNdICAwMDAwMGNkZmIyMDAwLTAwMDAwY2RmYzVmZmYgdHlwZT00IGF0dHI9
MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjc2ODI1Nl0gIDAwMDAwY2RmYzYwMDAtMDAw
MDBjZGZjYWZmZiB0eXBlPTMgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVOKSBbICAgIDIuNzc1
MTg4XSAgMDAwMDBjZGZjYjAwMC0wMDAwMGNkZmRmZmZmIHR5cGU9NCBhdHRyPTAwMDAwMDAwMDAw
MDAwMGYNCihYRU4pIFsgICAgMi43ODIxMjNdICAwMDAwMGNkZmUwMDAwLTAwMDAwY2RmZjFmZmYg
dHlwZT0zIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjc4OTA1NV0gIDAwMDAw
Y2RmZjIwMDAtMDAwMDBjZGZmOWZmZiB0eXBlPTQgYXR0cj0wMDAwMDAwMDAwMDAwMDBmDQooWEVO
KSBbICAgIDIuNzk1OTg5XSAgMDAwMDBjZGZmYTAwMC0wMDAwMGNkZmZmZmZmIHR5cGU9MyBhdHRy
PTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi44MDI5MjJdICAwMDAwMTAwMDAwMDAwLTAw
MDA4MGYzM2ZmZmYgdHlwZT03IGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjgw
OTg1N10gIDAwMDAwMDAwYTAwMDAtMDAwMDAwMDBmZmZmZiB0eXBlPTAgYXR0cj0wMDAwMDAwMDAw
MDAwMDBmDQooWEVOKSBbICAgIDIuODE2NzkwXSAgMDAwMDBjZTAwMDAwMC0wMDAwMGNmZmZmZmZm
IHR5cGU9MCBhdHRyPTAwMDAwMDAwMDAwMDAwMGYNCihYRU4pIFsgICAgMi44MjM3MjJdICAwMDAw
MGYwMDAwMDAwLTAwMDAwZjdmZmZmZmYgdHlwZT0xMSBhdHRyPTgwMDAwMDAwMDAwMDEwMGQNCihY
RU4pIFsgICAgMi44MzA3NDJdICAwMDAwMGZkMDAwMDAwLTAwMDAwZmVkZmZmZmYgdHlwZT0xMSBh
dHRyPTgwMDAwMDAwMDAwMDEwMGQNCihYRU4pIFsgICAgMi44Mzc3NjJdICAwMDAwMGZlZTAwMDAw
LTAwMDAwZmVlMDBmZmYgdHlwZT0xMSBhdHRyPTgwMDAwMDAwMDAwMDAwMDENCihYRU4pIFsgICAg
Mi44NDQ3ODNdICAwMDAwMGZlZTAxMDAwLTAwMDAwZmZmZmZmZmYgdHlwZT0xMSBhdHRyPTgwMDAw
MDAwMDAwMDEwMGQNCihYRU4pIFsgICAgMi44NTE4MDJdICAwMDAwODBmMzQwMDAwLTAwMDA4MmZm
ZmZmZmYgdHlwZT0wIGF0dHI9MDAwMDAwMDAwMDAwMDAwZg0KKFhFTikgWyAgICAyLjg1ODczN10g
IDAwMDA4MzAwMDAwMDAtMDAwMDg1MDFmZmZmZiB0eXBlPTExIGF0dHI9ODAwMDAwMDAwMDAwMTAw
ZA0KKFhFTikgWyAgICAyLjg2NTc1Nl0gYWx0IHRhYmxlIGZmZmY4MmQwNDA0YTIwMTggLT4gZmZm
ZjgyZDA0MDRiM2VmYw0KKFhFTikgWyAgICAyLjg4NTE0Nl0gQU1ELVZpOiBJT01NVSBFeHRlbmRl
ZCBGZWF0dXJlczoNCihYRU4pIFsgICAgMi44ODk5MTBdIC0gUGVyaXBoZXJhbCBQYWdlIFNlcnZp
Y2UgUmVxdWVzdA0KKFhFTikgWyAgICAyLjg5NDc2M10gLSB4MkFQSUMNCihYRU4pIFsgICAgMi44
OTc0NTBdIC0gTlggYml0DQooWEVOKSBbICAgIDIuOTAwMTM2XSAtIEludmFsaWRhdGUgQWxsIENv
bW1hbmQNCihYRU4pIFsgICAgMi45MDQyMTFdIC0gR3Vlc3QgQVBJQw0KKFhFTikgWyAgICAyLjkw
NzI0M10gLSBQZXJmb3JtYW5jZSBDb3VudGVycw0KKFhFTikgWyAgICAyLjkxMTE0NF0gLSBIb3N0
IEFkZHJlc3MgVHJhbnNsYXRpb24gU2l6ZTogMHgyDQooWEVOKSBbICAgIDIuOTE2MjU3XSAtIEd1
ZXN0IEFkZHJlc3MgVHJhbnNsYXRpb24gU2l6ZTogMA0KKFhFTikgWyAgICAyLjkyMTI4NF0gLSBH
dWVzdCBDUjMgUm9vdCBUYWJsZSBMZXZlbDogMHgxDQooWEVOKSBbICAgIDIuOTI2MTM4XSAtIE1h
eGltdW0gUEFTSUQ6IDB4Zg0KKFhFTikgWyAgICAyLjkyOTg2M10gLSBTTUkgRmlsdGVyIFJlZ2lz
dGVyOiAweDENCihYRU4pIFsgICAgMi45MzQxMTBdIC0gU01JIEZpbHRlciBSZWdpc3RlciBDb3Vu
dDogMHgxDQooWEVOKSBbICAgIDIuOTM4ODc3XSAtIEd1ZXN0IFZpcnR1YWwgQVBJQyBNb2Rlczog
MHgxDQooWEVOKSBbICAgIDIuOTQzNTU3XSAtIER1YWwgUFBSIExvZzogMHgyDQooWEVOKSBbICAg
IDIuOTQ3MTk5XSAtIER1YWwgRXZlbnQgTG9nOiAweDINCihYRU4pIFsgICAgMi45NTEwMTBdIC0g
VXNlciAvIFN1cGVydmlzb3IgUGFnZSBQcm90ZWN0aW9uDQooWEVOKSBbICAgIDIuOTU2MDM5XSAt
IERldmljZSBUYWJsZSBTZWdtZW50YXRpb246IDB4Mw0KKFhFTikgWyAgICAyLjk2MDgwNF0gLSBQ
UFIgTG9nIE92ZXJmbG93IEVhcmx5IFdhcm5pbmcNCihYRU4pIFsgICAgMi45NjU1NzFdIC0gUFBS
IEF1dG9tYXRpYyBSZXNwb25zZQ0KKFhFTikgWyAgICAyLjk2OTY0M10gLSBNZW1vcnkgQWNjZXNz
IFJvdXRpbmcgYW5kIENvbnRyb2w6IDANCihYRU4pIFsgICAgMi45NzQ5MzBdIC0gQmxvY2sgU3Rv
cE1hcmsgTWVzc2FnZQ0KKFhFTikgWyAgICAyLjk3OTAwNV0gLSBQZXJmb3JtYW5jZSBPcHRpbWl6
YXRpb24NCihYRU4pIFsgICAgMi45ODMyNTJdIC0gTVNJIENhcGFiaWxpdHkgTU1JTyBBY2Nlc3MN
CihYRU4pIFsgICAgMi45ODc2NzNdIC0gR3Vlc3QgSS9PIFByb3RlY3Rpb24NCihYRU4pIFsgICAg
Mi45OTE1NzNdIC0gRW5oYW5jZWQgUFBSIEhhbmRsaW5nDQooWEVOKSBbICAgIDIuOTk1NTU3XSAt
IEF0dHJpYnV0ZSBGb3J3YXJkDQooWEVOKSBbICAgIDIuOTk5MTk5XSAtIEludmFsaWRhdGUgSU9U
TEIgVHlwZQ0KKFhFTikgWyAgICAzLjAwMzE4NF0gLSBWTSBUYWJsZSBTaXplOiAwDQooWEVOKSBb
ICAgIDMuMDA2NzM2XSAtIEd1ZXN0IEFjY2VzcyBCaXQgVXBkYXRlIERpc2FibGUNCihYRU4pIFsg
ICAgMy4wMjI5OTZdIEFNRC1WaTogRGlzYWJsZWQgSEFQIG1lbW9yeSBtYXAgc2hhcmluZyB3aXRo
IElPTU1VDQooWEVOKSBbICAgIDMuMDI5MzE4XSBBTUQtVmk6IElPTU1VIDAgRW5hYmxlZC4NCihY
RU4pIFsgICAgMy4wMzMzOTNdIEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVkDQooWEVOKSBbICAg
IDMuMDM3NjM4XSAgLSBEb20wIG1vZGU6IFJlbGF4ZWQNCihYRU4pIFsgICAgMy4wNDE0NTRdIElu
dGVycnVwdCByZW1hcHBpbmcgZW5hYmxlZA0KKFhFTikgWyAgICAzLjA0NTc4Nl0gbnJfc29ja2V0
czogMQ0KKFhFTikgWyAgICAzLjA0ODkwN10gRW5hYmxpbmcgQVBJQyBtb2RlLiAgVXNpbmcgMiBJ
L08gQVBJQ3MNCihYRU4pIFsgICAgMy4wNTQ3OTZdIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhF
TikgWyAgICAzLjA1ODYwN10gIC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9kDQooWEVOKSBbICAgIDMu
MDYyNzA4XSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4y
PS0xDQooWEVOKSBbICAgIDMuMjE5MDU2XSBXYWxsY2xvY2sgc291cmNlOiBDTU9TIFJUQw0KKFhF
TikgWyAgICA0LjE5MzQ3MF0gQWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiAxMjggS2lCLg0KKFhF
TikgWyAgICA0LjE5ODQxMF0gbXdhaXQtaWRsZTogZG9lcyBub3QgcnVuIG9uIGZhbWlseSAyMyBt
b2RlbCA5Ng0KKFhFTikgWyAgICA0LjIwNDM5MV0gSFZNOiBBU0lEcyBlbmFibGVkLg0KKFhFTikg
WyAgICA0LjIwODAzMF0gU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBb
ICAgIDQuMjEyODg1XSAgLSBOZXN0ZWQgUGFnZSBUYWJsZXMgKE5QVCkNCihYRU4pIFsgICAgNC4y
MTcyMTZdICAtIExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBWaXJ0dWFsaXNhdGlvbg0KKFhFTikg
WyAgICA0LjIyMjg1MF0gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVA0KKFhFTikgWyAgICA0
LjIyNzI2OV0gIC0gVk1DQiBDbGVhbiBCaXRzDQooWEVOKSBbICAgIDQuMjMwODIzXSAgLSBUTEIg
Zmx1c2ggYnkgQVNJRA0KKFhFTikgWyAgICA0LjIzNDU1Ml0gIC0gRGVjb2RlQXNzaXN0cw0KKFhF
TikgWyAgICA0LjIzNzkzMF0gIC0gVmlydHVhbCBWTUxPQUQvVk1TQVZFDQooWEVOKSBbICAgIDQu
MjQyMDA0XSAgLSBWaXJ0dWFsIEdJRg0KKFhFTikgWyAgICA0LjI0NTIxMl0gIC0gUGF1c2UtSW50
ZXJjZXB0IEZpbHRlcg0KKFhFTikgWyAgICA0LjI0OTM3MF0gIC0gUGF1c2UtSW50ZXJjZXB0IEZp
bHRlciBUaHJlc2hvbGQNCihYRU4pIFsgICAgNC4yNTQzOTddICAtIFRTQyBSYXRlIE1TUg0KKFhF
TikgWyAgICA0LjI1NzY5Ml0gIC0gTVNSX1NQRUNfQ1RSTCB2aXJ0dWFsaXNhdGlvbg0KKFhFTikg
WyAgICA0LjI2MjM3MV0gSFZNOiBTVk0gZW5hYmxlZA0KKFhFTikgWyAgICA0LjI2NTc1MF0gSFZN
OiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsgICAgNC4y
NzE1NTddIEhWTTogSEFQIHBhZ2Ugc2l6ZXM6IDRrQiwgMk1CLCAxR0INCihYRU4pIFsgICAgNC41
ODMwMDFdIEJyb3VnaHQgdXAgMTYgQ1BVcw0KKFhFTikgWyAgICA0LjU4NzYxNF0gU2NoZWR1bGlu
ZyBncmFudWxhcml0eTogY3B1LCAxIENQVSBwZXIgc2NoZWQtcmVzb3VyY2UNCihYRU4pIFsgICAg
NC41OTQyMDZdIEluaXRpYWxpemluZyBudWxsIHNjaGVkdWxlcg0KKFhFTikgWyAgICA0LjU5ODUz
N10gV0FSTklORzogVGhpcyBpcyBleHBlcmltZW50YWwgc29mdHdhcmUgaW4gZGV2ZWxvcG1lbnQu
DQooWEVOKSBbICAgIDQuNjA1MjA3XSBVc2UgYXQgeW91ciBvd24gcmlzay4NCihYRU4pIFsgICAg
NC42MDkwMjVdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRl
ZC4NCihYRU4pIFsgICAgNC42MTUyNjNdIFJ1bm5pbmcgc3R1YiByZWNvdmVyeSBzZWxmdGVzdHMu
Li4NCihYRU4pIFsgICAgNC42MjAyMDNdIEZpeHVwICNVRFswMDAwXTogZmZmZjgyZDA3ZmZmZTA0
NCBbZmZmZjgyZDA3ZmZmZTA0NF0gLT4gZmZmZjgyZDA0MDM5NTYyNA0KKFhFTikgWyAgICA0LjYy
ODQzOV0gRml4dXAgI0dQWzAwMDBdOiBmZmZmODJkMDdmZmZlMDQ1IFtmZmZmODJkMDdmZmZlMDQ1
XSAtPiBmZmZmODJkMDQwMzk1NjI0DQooWEVOKSBbICAgIDQuNjM2NjY4XSBGaXh1cCAjU1NbMDAw
MF06IGZmZmY4MmQwN2ZmZmUwNDQgW2ZmZmY4MmQwN2ZmZmUwNDRdIC0+IGZmZmY4MmQwNDAzOTU2
MjQNCihYRU4pIFsgICAgNC42NDQ5MDJdIEZpeHVwICNCUFswMDAwXTogZmZmZjgyZDA3ZmZmZTA0
NSBbZmZmZjgyZDA3ZmZmZTA0NV0gLT4gZmZmZjgyZDA0MDM5NTYyNA0KKFhFTikgWyAgICA0LjY3
MzA2NF0gTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbiBhY3RpdmUNCihYRU4pIFsgICAg
NC42NzgzNDhdIGQwIGhhcyBtYXhpbXVtIDMzMjggUElSUXMNCihYRU4pIFsgICAgNC42ODI2Mjdd
ICoqKiBCdWlsZGluZyBhIFBWSCBEb20wICoqKg0KKFhFTikgWyAgICA0LjY5MDUyMl0gZDA6IGlk
ZW50aXR5IG1hcHBpbmdzIGZvciBJT01NVToNCihYRU4pIFsgICAgNC42OTUyODddICBbMDAwMDAw
MDBhMCwgMDAwMDAwMDBmZl0gUlcNCihYRU4pIFsgICAgNC42OTk3MTBdICBbMDAwMDAwOWJmZiwg
MDAwMDAwOWZmZl0gUlcNCihYRU4pIFsgICAgNC43MDQxMjRdICBbMDAwMDBjYWJjOSwgMDAwMDBj
YzE0Y10gUlcNCihYRU4pIFsgICAgNC43MDg3NDhdICBbMDAwMDBjYzM4OSwgMDAwMDBjYzM4OV0g
UlcNCihYRU4pIFsgICAgNC43MTMxNjhdICBbMDAwMDBjYzcwYSwgMDAwMDBjZDFmZV0gUlcNCihY
RU4pIFsgICAgNC43MTgxMTddICBbMDAwMDBjZTAwMCwgMDAwMDBjZmZmZl0gUlcNCihYRU4pIFsg
ICAgNC43MjI1MzhdICBbMDAwMDBmZDAwMCwgMDAwMDBmZDJmZl0gUlcNCihYRU4pIFsgICAgNC43
MjcwMzZdICBbMDAwMDBmZDMwNCwgMDAwMDBmZWJmZl0gUlcNCihYRU4pIFsgICAgNC43MzE1MzRd
ICBbMDAwMDBmZWMwMiwgMDAwMDBmZWRmZl0gUlcNCihYRU4pIFsgICAgNC43MzYyNjFdICBbMDAw
MDBmZWUwMSwgMDAwMDBmZmZmZl0gUlcNCihYRU4pIFsgICAgNC43NDA5ODhdICBbMDAwMDgwZjM0
MCwgMDAwMDg1MDFmZl0gUlcNCihYRU4pIFsgICAgNC43NDYzNzRdIGFyY2gveDg2L3BjaS5jOjEw
OTpkW0lETEVddjAgMDAwMDowMjowMC4wOiBCQVIgYXQgW2ZlYTAwLCBmZWEwM10gbm90IGluIG1l
bW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgICA0Ljc1NTkwOF0gYXJjaC94ODYvcGNpLmM6MTA5OmRb
SURMRV12MCAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5
IG1hcCBob2xlDQooWEVOKSBbICAgIDQuNzY1NDQ3XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZFtJRExF
XXYwIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwgZmU5MGZdIG5vdCBpbiBtZW1vcnkgbWFw
IGhvbGUNCihYRU4pIFsgICAgNC43NzQ5ODBdIGFyY2gveDg2L3BjaS5jOjEwOTpkW0lETEVddjAg
MDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTEwLCBmZTkxM10gbm90IGluIG1lbW9yeSBtYXAgaG9s
ZQ0KKFhFTikgWyAgICA0Ljc4NDUxMF0gYXJjaC94ODYvcGNpLmM6MTA5OmRbSURMRV12MCAwMDAw
OjAzOjAwLjA6IEJBUiBhdCBbZmU5MDAsIGZlOTBmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQoo
WEVOKSBbICAgIDQuNzk0MDQ1XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZFtJRExFXXYwIDAwMDA6MDM6
MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4p
IFsgICAgNC44MDM1NzhdIGFyY2gveDg2L3BjaS5jOjEwOTpkW0lETEVddjAgMDAwMDowNDowMC4w
OiBCQVIgYXQgW2ZlNzAwLCBmZTc3Zl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAg
ICA0LjgxMzY1MF0gYXJjaC94ODYvcGNpLmM6MTA5OmRbSURMRV12MCAwMDAwOjA0OjAwLjA6IEJB
UiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgIDQu
ODIzMTg2XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZFtJRExFXXYwIDAwMDA6MDQ6MDAuMzogQkFSIGF0
IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAgNC44MzI3
MjJdIGFyY2gveDg2L3BjaS5jOjEwOTpkW0lETEVddjAgMDAwMDowNDowMC4zOiBCQVIgYXQgW2Zl
NTAwLCBmZTVmZl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgICA0Ljg0MjI1MV0g
YXJjaC94ODYvcGNpLmM6MTA5OmRbSURMRV12MCAwMDAwOjA0OjAwLjQ6IEJBUiBhdCBbZmU0MDAs
IGZlNGZmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgIDQuODUxNzg0XSBhcmNo
L3g4Ni9wY2kuYzoxMDk6ZFtJRExFXXYwIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0
ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAgNC44NjEzMjFdIGFyY2gveDg2
L3BjaS5jOjEwOTpkW0lETEVddjAgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0g
bm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgICA0Ljg3MDg1M10gYXJjaC94ODYvcGNp
LmM6MTA5OmRbSURMRV12MCAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3Qg
aW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgIDQuODgwMzg2XSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZFtJRExFXXYwIDAwMDA6MDU6MDAuMTogQkFSIGF0IFtmZTgwMCwgZmU4MDBdIG5vdCBpbiBt
ZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAgNC44ODk5MThdIGFyY2gveDg2L3BjaS5jOjEwOTpk
W0lETEVddjAgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9y
eSBtYXAgaG9sZQ0KKFhFTikgWyAgICA1LjAxMjM4MV0gRG9tMCBtZW1vcnkgYWxsb2NhdGlvbiBz
dGF0czoNCihYRU4pIFsgICAgNS4wMTY4ODVdIG9yZGVyICAwIGFsbG9jYXRpb25zOiA0DQooWEVO
KSBbICAgIDUuMDIwODcxXSBvcmRlciAgMSBhbGxvY2F0aW9uczogMg0KKFhFTikgWyAgICA1LjAy
NDg2MV0gb3JkZXIgIDIgYWxsb2NhdGlvbnM6IDINCihYRU4pIFsgICAgNS4wMjg4NDVdIG9yZGVy
ICAzIGFsbG9jYXRpb25zOiAyDQooWEVOKSBbICAgIDUuMDMyODMzXSBvcmRlciAgNCBhbGxvY2F0
aW9uczogMg0KKFhFTikgWyAgICA1LjAzNjgxOF0gb3JkZXIgIDUgYWxsb2NhdGlvbnM6IDQNCihY
RU4pIFsgICAgNS4wNDA4MDddIG9yZGVyICA2IGFsbG9jYXRpb25zOiAzDQooWEVOKSBbICAgIDUu
MDQ0Nzk1XSBvcmRlciAgNyBhbGxvY2F0aW9uczogNQ0KKFhFTikgWyAgICA1LjA0ODc4MV0gb3Jk
ZXIgIDggYWxsb2NhdGlvbnM6IDQNCihYRU4pIFsgICAgNS4wNTI3NjRdIG9yZGVyICA5IGFsbG9j
YXRpb25zOiA2DQooWEVOKSBbICAgIDUuMDU2NzU3XSBvcmRlciAxMCBhbGxvY2F0aW9uczogMw0K
KFhFTikgWyAgICA1LjA2MDc0MF0gb3JkZXIgMTEgYWxsb2NhdGlvbnM6IDYNCihYRU4pIFsgICAg
NS4wNjQ3MjhdIG9yZGVyIDEyIGFsbG9jYXRpb25zOiAzDQooWEVOKSBbICAgIDUuMDY4NzE0XSBv
cmRlciAxMyBhbGxvY2F0aW9uczogMg0KKFhFTikgWyAgICA1LjA3MjY5OV0gb3JkZXIgMTQgYWxs
b2NhdGlvbnM6IDMNCihYRU4pIFsgICAgNS4wNzY2ODhdIG9yZGVyIDE1IGFsbG9jYXRpb25zOiAx
DQooWEVOKSBbICAgIDUuMDgwNjcyXSBvcmRlciAxNiBhbGxvY2F0aW9uczogMg0KKFhFTikgWyAg
ICA1LjA4NDY2Ml0gb3JkZXIgMTcgYWxsb2NhdGlvbnM6IDINCihYRU4pIFsgICAgNS4wODg2NDdd
IG9yZGVyIDE4IGFsbG9jYXRpb25zOiAyDQooWEVOKSBbICAgIDUuMzk4OTIyXSBFTEY6IHBoZHI6
IHBhZGRyPTB4MTAwMDAwMCBtZW1zej0weDFiMWEwMGMNCihYRU4pIFsgICAgNS40MDQ1NThdIEVM
RjogcGhkcjogcGFkZHI9MHgyYzAwMDAwIG1lbXN6PTB4ODkyMDAwDQooWEVOKSBbICAgIDUuNDEw
MTAzXSBFTEY6IHBoZHI6IHBhZGRyPTB4MzQ5MjAwMCBtZW1zej0weDJmZWQ4DQooWEVOKSBbICAg
IDUuNDE1NTY0XSBFTEY6IHBoZHI6IHBhZGRyPTB4MzRjMjAwMCBtZW1zej0weDU2ZTAwMA0KKFhF
TikgWyAgICA1LjQyMTEwOF0gRUxGOiBtZW1vcnk6IDB4MTAwMDAwMCAtPiAweDNhMzAwMDANCihY
RU4pIFsgICAgNS40MjYxMzhdIEVMRjogbm90ZTogUEhZUzMyX0VOVFJZID0gMHgxMDAwMDAwDQoo
WEVOKSBbICAgIDUuNDMxMTY3XSBFTEY6IG5vdGU6IEdVRVNUX09TID0gImxpbnV4Ig0KKFhFTikg
WyAgICA1LjQzNTY3MF0gRUxGOiBub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiINCihYRU4pIFsg
ICAgNS40NDA0MzZdIEVMRjogbm90ZTogWEVOX1ZFUlNJT04gPSAieGVuLTMuMCINCihYRU4pIFsg
ICAgNS40NDUzNzVdIEVMRjogbm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwDQoo
WEVOKSBbICAgIDUuNDUwOTIzXSBFTEY6IG5vdGU6IElOSVRfUDJNID0gMHg4MDAwMDAwMDAwDQoo
WEVOKSBbICAgIDUuNDU1ODY2XSBFTEY6IG5vdGU6IEVOVFJZID0gMHhmZmZmZmZmZjgzNGQ0NjMw
DQooWEVOKSBbICAgIDUuNDYxMDYxXSBFTEY6IG5vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9w
YWdlX3RhYmxlcyINCihYRU4pIFsgICAgNS40NjY5NThdIEVMRjogbm90ZTogUEFFX01PREUgPSAi
eWVzIg0KKFhFTikgWyAgICA1LjQ3MTI5NF0gRUxGOiBub3RlOiBMMV9NRk5fVkFMSUQNCihYRU4p
IFsgICAgNS40NzUyNzhdIEVMRjogbm90ZTogTU9EX1NUQVJUX1BGTiA9IDB4MQ0KKFhFTikgWyAg
ICA1LjQ3OTg2OV0gRUxGOiBub3RlOiBQQUREUl9PRkZTRVQgPSAwDQooWEVOKSBbICAgIDUuNDg0
MjAyXSBFTEY6IG5vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZmZjgyMDM0MDAwDQooWEVO
KSBbICAgIDUuNDkwMTgyXSBFTEY6IG5vdGU6IFNVUFBPUlRFRF9GRUFUVVJFUyA9IDB4ODgwMQ0K
KFhFTikgWyAgICA1LjQ5NTQ2OV0gRUxGOiBub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyINCihYRU4p
IFsgICAgNS40OTk5NzhdIEVMRjogbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDENCihYRU4pIFsg
ICAgNS41MDQ2NjBdIEVMRjogRm91bmQgUFZIIGltYWdlDQooWEVOKSBbICAgIDUuNTA4MzgyXSBF
TEY6IGFkZHJlc3NlczoNCihYRU4pIFsgICAgNS41MTE2NzZdICAgICB2aXJ0X2Jhc2UgICAgICAg
ID0gMHgwDQooWEVOKSBbICAgIDUuNTE1OTIzXSAgICAgZWxmX3BhZGRyX29mZnNldCA9IDB4MA0K
KFhFTikgWyAgICA1LjUyMDE2OV0gICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweDANCihYRU4pIFsg
ICAgNS41MjQ0MTZdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHgxMDAwMDAwDQooWEVOKSBbICAg
IDUuNTI5MTg2XSAgICAgdmlydF9rZW5kICAgICAgICA9IDB4M2EzMDAwMA0KKFhFTikgWyAgICA1
LjUzMzk0OF0gICAgIHZpcnRfZW50cnkgICAgICAgPSAweDEwMDAwMDANCihYRU4pIFsgICAgNS41
Mzg3MTZdICAgICBwMm1fYmFzZSAgICAgICAgID0gMHg4MDAwMDAwMDAwDQooWEVOKSBbICAgIDUu
NTQzNzQ1XSBFTEY6IHBoZHIgMCBhdCAweDEwMDAwMDAgLT4gMHgyYjFhMDBjDQooWEVOKSBbICAg
IDUuNTU1OTI1XSBFTEY6IHBoZHIgMSBhdCAweDJjMDAwMDAgLT4gMHgzNDkyMDAwDQooWEVOKSBb
ICAgIDUuNTYzMjI2XSBFTEY6IHBoZHIgMiBhdCAweDM0OTIwMDAgLT4gMHgzNGMxZWQ4DQooWEVO
KSBbICAgIDUuNTY4NDI1XSBFTEY6IHBoZHIgMyBhdCAweDM0YzIwMDAgLT4gMHgzNzg5MDAwDQoo
WEVOKSBbICAgIDUuNjI5MjQ1XSBEb20wIG1lbW9yeSBtYXA6DQooWEVOKSBbICAgIDUuNjMyNjI2
XSAgWzAwMDAwMDAwMDAwMDAwMDAsIDAwMDAwMDAwMDAwOWZmZmZdICh1c2FibGUpDQooWEVOKSBb
ICAgIDUuNjM4NjA3XSAgWzAwMDAwMDAwMDAwYTAwMDAsIDAwMDAwMDAwMDAwZmZmZmZdIChyZXNl
cnZlZCkNCihYRU4pIFsgICAgNS42NDQ3NTddICBbMDAwMDAwMDAwMDEwMDAwMCwgMDAwMDAwMDAw
OWJmZWZmZl0gKHVzYWJsZSkNCihYRU4pIFsgICAgNS42NTA3MzddICBbMDAwMDAwMDAwOWJmZjAw
MCwgMDAwMDAwMDAwOWZmZmZmZl0gKHJlc2VydmVkKQ0KKFhFTikgWyAgICA1LjY1Njg5NF0gIFsw
MDAwMDAwMDBhMDAwMDAwLCAwMDAwMDAwMDBhMWZmZmZmXSAodXNhYmxlKQ0KKFhFTikgWyAgICA1
LjY2Mjg3Nl0gIFswMDAwMDAwMDBhMjAwMDAwLCAwMDAwMDAwMDBhMjBjZmZmXSAoQUNQSSBOVlMp
DQooWEVOKSBbICAgIDUuNjY5MDI5XSAgWzAwMDAwMDAwMGEyMGQwMDAsIDAwMDAwMDAwY2FiYzhm
ZmZdICh1c2FibGUpDQooWEVOKSBbICAgIDUuNjc1MDA0XSAgWzAwMDAwMDAwY2FiYzkwMDAsIDAw
MDAwMDAwY2MxNGNmZmZdIChyZXNlcnZlZCkNCihYRU4pIFsgICAgNS42ODExNTddICBbMDAwMDAw
MDBjYzE0ZDAwMCwgMDAwMDAwMDBjYzE5NWZmZl0gKEFDUEkgZGF0YSkNCihYRU4pIFsgICAgNS42
ODczOTddICBbMDAwMDAwMDBjYzE5NjAwMCwgMDAwMDAwMDBjYzM4OGZmZl0gKEFDUEkgTlZTKQ0K
KFhFTikgWyAgICA1LjY5MzU1MF0gIFswMDAwMDAwMGNjMzg5MDAwLCAwMDAwMDAwMGNjMzg5ZmZm
XSAocmVzZXJ2ZWQpDQooWEVOKSBbICAgIDUuNjk5NzA3XSAgWzAwMDAwMDAwY2MzOGEwMDAsIDAw
MDAwMDAwY2M3MDlmZmZdIChBQ1BJIE5WUykNCihYRU4pIFsgICAgNS43MDU4NTldICBbMDAwMDAw
MDBjYzcwYTAwMCwgMDAwMDAwMDBjZDFmZWZmZl0gKHJlc2VydmVkKQ0KKFhFTikgWyAgICA1Ljcx
MjAxNF0gIFswMDAwMDAwMGNkMWZmMDAwLCAwMDAwMDAwMGNkZmZmZWE3XSAodXNhYmxlKQ0KKFhF
TikgWyAgICA1LjcxNzk5Ml0gIFswMDAwMDAwMGNkZmZmZWE4LCAwMDAwMDAwMGNkZmZmZjNmXSAo
QUNQSSBkYXRhKQ0KKFhFTikgWyAgICA1LjcyNDIzNl0gIFswMDAwMDAwMGNlMDAwMDAwLCAwMDAw
MDAwMGNmZmZmZmZmXSAocmVzZXJ2ZWQpDQooWEVOKSBbICAgIDUuNzMwMzg3XSAgWzAwMDAwMDAw
ZjAwMDAwMDAsIDAwMDAwMDAwZjdmZmZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFsgICAgNS43MzY1
MzddICBbMDAwMDAwMDBmZDAwMDAwMCwgMDAwMDAwMDBmZmZmZmZmZl0gKHJlc2VydmVkKQ0KKFhF
TikgWyAgICA1Ljc0MjY5NV0gIFswMDAwMDAwMTAwMDAwMDAwLCAwMDAwMDAwMTM0YWEzZmZmXSAo
dXNhYmxlKQ0KKFhFTikgWyAgICA1Ljc0ODY3MF0gIFswMDAwMDAwMTM0YWE0MDAwLCAwMDAwMDAw
ODBmMzNmZmZmXSAodW51c2FibGUpDQooWEVOKSBbICAgIDUuNzU0ODMwXSAgWzAwMDAwMDA4MGYz
NDAwMDAsIDAwMDAwMDA4NTAxZmZmZmZdIChyZXNlcnZlZCkNCihYRU4pIFsgICAgNS43NjA5ODFd
IEluaXRpYWwgbG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLg0K
KFhFTikgWyAgICA1Ljc2NzY1NF0gU2NydWJiaW5nIEZyZWUgUkFNIGluIGJhY2tncm91bmQNCihY
RU4pIFsgICAgNS43NzI0MjNdIFN0ZC4gTG9nbGV2ZWw6IEFsbA0KKFhFTikgWyAgICA1Ljc3NTk3
NF0gR3Vlc3QgTG9nbGV2ZWw6IEFsbA0KKFhFTikgWyAgICA1Ljc3OTYxNl0gKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQooWEVOKSBbICAgIDUuNzg2
MDI3XSBXQVJOSU5HOiBDT05TT0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUw0KKFhFTikgWyAgICA1
Ljc5MTMxNV0gVGhpcyBvcHRpb24gaXMgaW50ZW5kZWQgdG8gYWlkIGRlYnVnZ2luZyBvZiBYZW4g
YnkgZW5zdXJpbmcNCihYRU4pIFsgICAgNS43OTg0MjNdIHRoYXQgYWxsIG91dHB1dCBpcyBzeW5j
aHJvbm91c2x5IGRlbGl2ZXJlZCBvbiB0aGUgc2VyaWFsIGxpbmUuDQooWEVOKSBbICAgIDUuODA1
NzkwXSBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNBTlQgbGF0ZW5jaWVzIGFuZCBh
ZmZlY3QNCihYRU4pIFsgICAgNS44MTI3MThdIHRpbWVrZWVwaW5nLiBJdCBpcyBOT1QgcmVjb21t
ZW5kZWQgZm9yIHByb2R1Y3Rpb24gdXNlIQ0KKFhFTikgWyAgICA1LjgxOTM5Ml0gKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQooWEVOKSBbICAgIDUu
ODI1ODEwXSAzLi4uIDIuLi4gMS4uLg0KKFhFTikgWyAgICA4LjgyODUyNF0gKioqIFNlcmlhbCBp
bnB1dCB0byBET00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCkN
CihYRU4pIFsgICAgOC44MzY4NDZdIGNvbW1vbi9zY2hlZC9udWxsLmM6MzU3OiAwIDwtLSBkMHYw
DQooWEVOKSBbICAgIDguODQyMzM1XSBGcmVlZCA2MzZrQiBpbml0IG1lbW9yeQ0KWyAgICAwLjAw
MDAwMF0gTGludXggdmVyc2lvbiA2LjExLjAgKHJvb3RAZDM0ODQ1NzFjYzYyKSAoZ2NjIChBbHBp
bmUgMTIuMi4xX2dpdDIwMjIwOTI0LXIxMCkgMTIuMi4xIDIwMjIwOTI0LCBHTlUgbGQgKEdOVSBC
aW51dGlscykgMi40MCkgIzEgU01QIFBSRUVNUFRfRFlOQU1JQyBNb24gTWF5IDEyIDE2OjUwOjI2
IFVUQyAyMDI1DQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxpbmU6IGNvbnNvbGU9aHZjMCByb290
PS9kZXYvcmFtMCBlYXJseXByaW50az14ZW4gZGVidWcgcmRpbml0PS9iaW4vc2gNClsgICAgMC4w
MDAwMDBdIFtGaXJtd2FyZSBCdWddOiBUU0MgZG9lc24ndCBjb3VudCB3aXRoIFAwIGZyZXF1ZW5j
eSENClsgICAgMC4wMDAwMDBdIEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoNClsgICAg
MC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAwMDAwMDAw
MDlmZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAw
MDAwYTAwMDAtMHgwMDAwMDAwMDAwMGZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gQklP
Uy1lODIwOiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAwMDAwMDliZmVmZmZdIHVzYWJs
ZQ0KWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDAwOWJmZjAwMC0weDAw
MDAwMDAwMDlmZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0g
MHgwMDAwMDAwMDBhMDAwMDAwLTB4MDAwMDAwMDAwYTFmZmZmZl0gdXNhYmxlDQpbICAgIDAuMDAw
MDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMDBhMjAwMDAwLTB4MDAwMDAwMDAwYTIwY2Zm
Zl0gQUNQSSBOVlMNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwMGEy
MGQwMDAtMHgwMDAwMDAwMGNhYmM4ZmZmXSB1c2FibGUNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgy
MDogW21lbSAweDAwMDAwMDAwY2FiYzkwMDAtMHgwMDAwMDAwMGNjMTRjZmZmXSByZXNlcnZlZA0K
WyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4MDAwMDAwMDBjYzE0ZDAwMC0weDAwMDAw
MDAwY2MxOTVmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gQklPUy1lODIwOiBbbWVtIDB4
MDAwMDAwMDBjYzE5NjAwMC0weDAwMDAwMDAwY2MzODhmZmZdIEFDUEkgTlZTDQpbICAgIDAuMDAw
MDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMGNjMzg5MDAwLTB4MDAwMDAwMDBjYzM4OWZm
Zl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwY2Mz
OGEwMDAtMHgwMDAwMDAwMGNjNzA5ZmZmXSBBQ1BJIE5WUw0KWyAgICAwLjAwMDAwMF0gQklPUy1l
ODIwOiBbbWVtIDB4MDAwMDAwMDBjYzcwYTAwMC0weDAwMDAwMDAwY2QxZmVmZmZdIHJlc2VydmVk
DQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMGNkMWZmMDAwLTB4MDAw
MDAwMDBjZGZmZmVhN10gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgw
MDAwMDAwMGNkZmZmZWE4LTB4MDAwMDAwMDBjZGZmZmYzZl0gQUNQSSBkYXRhDQpbICAgIDAuMDAw
MDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMGNlMDAwMDAwLTB4MDAwMDAwMDBjZmZmZmZm
Zl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwZjAw
MDAwMDAtMHgwMDAwMDAwMGY3ZmZmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gQklPUy1l
ODIwOiBbbWVtIDB4MDAwMDAwMDBmZDAwMDAwMC0weDAwMDAwMDAwZmZmZmZmZmZdIHJlc2VydmVk
DQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMTAwMDAwMDAwLTB4MDAw
MDAwMDgwZjMzZmZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBCSU9TLWU4MjA6IFttZW0gMHgw
MDAwMDAwODBmMzQwMDAwLTB4MDAwMDAwMDg1MDFmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIHByaW50azogbGVnYWN5IGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAw
LjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlDQpbICAgIDAu
MDAwMDAwXSBBUElDOiBTdGF0aWMgY2FsbHMgaW5pdGlhbGl6ZWQNClsgICAgMC4wMDAwMDBdIGVm
aTogRUZJIHYyLjcgYnkgQW1lcmljYW4gTWVnYXRyZW5kcw0KWyAgICAwLjAwMDAwMF0gZWZpOiBB
Q1BJPTB4Y2M2ZjMwMDAgQUNQSSAyLjA9MHhjYzZmMzAxNCBUUE1GaW5hbExvZz0weGNjNmMyMDAw
IFNNQklPUz0weGNjZmQ2MDAwIFNNQklPUyAzLjA9MHhjY2ZkNTAwMCAoTUVNQVRUUj0weGM3MjM2
NTE4IHVudXNhYmxlKSBFU1JUPTB4Y2MxNWIwMTgNClsgICAgMC4wMDAwMDBdIFNNQklPUyAzLjIu
MCBwcmVzZW50Lg0KWyAgICAwLjAwMDAwMF0gRE1JOiAgLzdENzg1IC8gN0Q3ODYsIEJJT1MgNS4x
NiAwMi8yNC8yMDI1DQpbICAgIDAuMDAwMDAwXSBETUk6IE1lbW9yeSBzbG90cyBwb3B1bGF0ZWQ6
IDIvMg0KWyAgICAwLjAwMDAwMF0gSHlwZXJ2aXNvciBkZXRlY3RlZDogWGVuIEhWTQ0KWyAgICAw
LjAwMDAwMF0gWGVuIHZlcnNpb24gNC4yMS4NClsgICAgMC4wMDAwMDRdIEhWTU9QX3BhZ2V0YWJs
ZV9keWluZyBub3Qgc3VwcG9ydGVkDQpbICAgIDAuMDUxODYwXSB0c2M6IEZhc3QgVFNDIGNhbGli
cmF0aW9uIGZhaWxlZA0KWyAgICAwLjA1NTk2MV0gdHNjOiBEZXRlY3RlZCAyODk0LjU0OCBNSHog
cHJvY2Vzc29yDQpbICAgIDAuMDYwNjkzXSBlODIwOiB1cGRhdGUgW21lbSAweDAwMDAwMDAwLTB4
MDAwMDBmZmZdIHVzYWJsZSA9PT4gcmVzZXJ2ZWQNClsgICAgMC4wNjcyMjldIGU4MjA6IHJlbW92
ZSBbbWVtIDB4MDAwYTAwMDAtMHgwMDBmZmZmZl0gdXNhYmxlDQpbICAgIDAuMDcyNzgxXSBsYXN0
X3BmbiA9IDB4ODBmMzQwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDc4Mjky
XSBNVFJSIG1hcDogNCBlbnRyaWVzICgzIGZpeGVkICsgMSB2YXJpYWJsZTsgbWF4IDIwKSwgYnVp
bHQgZnJvbSA5IHZhcmlhYmxlIE1UUlJzDQpbICAgIDAuMDg2NTU1XSB4ODYvUEFUOiBDb25maWd1
cmF0aW9uIFswLTddOiBXQiAgV0MgIFVDLSBVQyAgV0IgIFdQICBVQy0gV1QNClsgICAgMC4wOTQw
MTFdIENQVSBNVFJScyBhbGwgYmxhbmsgLSB2aXJ0dWFsaXplZCBzeXN0ZW0uDQpbICAgIDAuMDk4
OTAwXSBsYXN0X3BmbiA9IDB4Y2RmZmYgbWF4X2FyY2hfcGZuID0gMHg0MDAwMDAwMDANClsgICAg
MC4xMDc5NDhdIGVzcnQ6IFJlc2VydmluZyBFU1JUIHNwYWNlIGZyb20gMHgwMDAwMDAwMGNjMTVi
MDE4IHRvIDB4MDAwMDAwMDBjYzE1YjA1MC4NClsgICAgMC4xMTU2MDddIFVzaW5nIEdCIHBhZ2Vz
IGZvciBkaXJlY3QgbWFwcGluZw0KWyAgICAwLjEyMDc2Nl0gU2VjdXJlIGJvb3QgZGlzYWJsZWQN
ClsgICAgMC4xMjM4MjVdIFJBTURJU0s6IFttZW0gMHgwYTIwZDAwMC0weDE2ZDA1ZmZmXQ0KWyAg
ICAwLjEyODk1OF0gQUNQSTogRWFybHkgdGFibGUgY2hlY2tzdW0gdmVyaWZpY2F0aW9uIGRpc2Fi
bGVkDQpbICAgIDAuMTM0NDQ2XSBBQ1BJOiBSU0RQIDB4MDAwMDAwMDBDREZGRkVBOCAwMDAwMjQg
KHYwMiBBTEFTS0EpDQpbICAgIDAuMTQwMTYyXSBBQ1BJOiBYU0RUIDB4MDAwMDAwMDBDREZGRkVD
QyAwMDAwOUMgKHYwMSBBTEFTS0EgQSBNIEkgICAgMDEwNzIwMDkgQU1JICAwMTAwMDAxMykNClsg
ICAgMC4xNDg2NjNdIEFDUEk6IEFQSUMgMHgwMDAwMDAwMENERkZGRjY4IDAwMDA5OCAodjAzIEFM
QVNLQSBBIE0gSSAgICAwMTA3MjAwOSBBTUkgIDAwMDEwMDEzKQ0KWyAgICAwLjE1NzE1N10gQUNQ
STogRkFDUCAweDAwMDAwMDAwQ0MxOEMwMDAgMDAwMTE0ICh2MDYgQUxBU0tBIEEgTSBJICAgIDAx
MDcyMDA5IEFNSSAgMDAwMTAwMTMpDQpbICAgIDAuMTY1Njg2XSBBQ1BJOiBEU0RUIDB4MDAwMDAw
MDBDQzE4MzAwMCAwMDg3NkQgKHYwMiBBTEFTS0EgQSBNIEkgICAgMDEwNzIwMDkgSU5UTCAyMDEy
MDkxMykNClsgICAgMC4xNzQxNDNdIEFDUEk6IEZBQ1MgMHgwMDAwMDAwMENDNkMwMDAwIDAwMDA0
MA0KWyAgICAwLjE3ODczNV0gQUNQSTogU1NEVCAweDAwMDAwMDAwQ0MxOEUwMDAgMDA3MjNDICh2
MDIgQU1EICAgIEFtZFRhYmxlIDAwMDAwMDAyIE1TRlQgMDQwMDAwMDApDQpbICAgIDAuMTg3MjI0
XSBBQ1BJOiBNQ0ZHIDB4MDAwMDAwMDBDQzE4MTAwMCAwMDAwM0MgKHYwMSBBTEFTS0EgQSBNIEkg
ICAgMDEwNzIwMDkgTVNGVCAwMDAxMDAxMykNClsgICAgMC4xOTU3MThdIEFDUEk6IFNTRFQgMHgw
MDAwMDAwMENDMTdGMDAwIDAwMDIyOCAodjAxIEFNRCAgICBTVEQzICAgICAwMDAwMDAwMSBJTlRM
IDIwMTIwOTEzKQ0KWyAgICAwLjIwNDIxMl0gQUNQSTogVkZDVCAweDAwMDAwMDAwQ0MxNzEwMDAg
MDBENjg0ICh2MDEgQUxBU0tBIEEgTSBJICAgIDAwMDAwMDAxIEFNRCAgMzE1MDRGNDcpDQpbICAg
IDAuMjEyNzA3XSBBQ1BJOiBTU0RUIDB4MDAwMDAwMDBDQzE2QzAwMCAwMDM5RjQgKHYwMSBBTUQg
ICAgQW1kVGFibGUgMDAwMDAwMDEgQU1EICAwMDAwMDAwMSkNClsgICAgMC4yMjEyMDFdIEFDUEk6
IFNTRFQgMHgwMDAwMDAwMENDMTY5MDAwIDAwMDEzOSAodjAxIEFNRCAgICBBbWRUYWJsZSAwMDAw
MDAwMSBJTlRMIDIwMTIwOTEzKQ0KWyAgICAwLjIyOTY5Ml0gQUNQSTogU1NEVCAweDAwMDAwMDAw
Q0MxNjgwMDAgMDAwMjI3ICh2MDEgQU1EICAgIEFtZFRhYmxlIDAwMDAwMDAxIElOVEwgMjAxMjA5
MTMpDQpbICAgIDAuMjM4MTg3XSBBQ1BJOiBTU0RUIDB4MDAwMDAwMDBDQzE2NzAwMCAwMDBEMzcg
KHYwMSBBTUQgICAgQW1kVGFibGUgMDAwMDAwMDEgSU5UTCAyMDEyMDkxMykNClsgICAgMC4yNDY2
ODJdIEFDUEk6IFNTRFQgMHgwMDAwMDAwMENDMTY1MDAwIDAwMTBBNSAodjAxIEFNRCAgICBBbWRU
YWJsZSAwMDAwMDAwMSBJTlRMIDIwMTIwOTEzKQ0KWyAgICAwLjI1NTE3Ml0gQUNQSTogU1NEVCAw
eDAwMDAwMDAwQ0MxNjEwMDAgMDAzMEM4ICh2MDEgQU1EICAgIEFtZFRhYmxlIDAwMDAwMDAxIElO
VEwgMjAxMjA5MTMpDQpbICAgIDAuMjYzNjY0XSBBQ1BJOiBTU0RUIDB4MDAwMDAwMDBDQzE1RTAw
MCAwMDAwN0QgKHYwMSBBTUQgICAgQW1kVGFibGUgMDAwMDAwMDEgSU5UTCAyMDEyMDkxMykNClsg
ICAgMC4yNzIxNjJdIEFDUEk6IFNTRFQgMHgwMDAwMDAwMENDMTVEMDAwIDAwMDUxNyAodjAxIEFN
RCAgICBBbWRUYWJsZSAwMDAwMDAwMSBJTlRMIDIwMTIwOTEzKQ0KWyAgICAwLjI4MDY1MV0gQUNQ
STogRlBEVCAweDAwMDAwMDAwQ0MxNUMwMDAgMDAwMDQ0ICh2MDEgQUxBU0tBIEEgTSBJICAgIDAx
MDcyMDA5IEFNSSAgMDEwMDAwMTMpDQpbICAgIDAuMjg5MTQ4XSBBQ1BJOiBSZXNlcnZpbmcgQVBJ
QyB0YWJsZSBtZW1vcnkgYXQgW21lbSAweGNkZmZmZjY4LTB4Y2RmZmZmZmZdDQpbICAgIDAuMjk2
MTY1XSBBQ1BJOiBSZXNlcnZpbmcgRkFDUCB0YWJsZSBtZW1vcnkgYXQgW21lbSAweGNjMThjMDAw
LTB4Y2MxOGMxMTNdDQpbICAgIDAuMzAzMTgyXSBBQ1BJOiBSZXNlcnZpbmcgRFNEVCB0YWJsZSBt
ZW1vcnkgYXQgW21lbSAweGNjMTgzMDAwLTB4Y2MxOGI3NmNdDQpbICAgIDAuMzEwMjAyXSBBQ1BJ
OiBSZXNlcnZpbmcgRkFDUyB0YWJsZSBtZW1vcnkgYXQgW21lbSAweGNjNmMwMDAwLTB4Y2M2YzAw
M2ZdDQpbICAgIDAuMzE3MjIyXSBBQ1BJOiBSZXNlcnZpbmcgU1NEVCB0YWJsZSBtZW1vcnkgYXQg
W21lbSAweGNjMThlMDAwLTB4Y2MxOTUyM2JdDQpbICAgIDAuMzI0MjQ3XSBBQ1BJOiBSZXNlcnZp
bmcgTUNGRyB0YWJsZSBtZW1vcnkgYXQgW21lbSAweGNjMTgxMDAwLTB4Y2MxODEwM2JdDQpbICAg
IDAuMzMxMjYyXSBBQ1BJOiBSZXNlcnZpbmcgU1NEVCB0YWJsZSBtZW1vcnkgYXQgW21lbSAweGNj
MTdmMDAwLTB4Y2MxN2YyMjddDQpbICAgIDAuMzM4Mjg2XSBBQ1BJOiBSZXNlcnZpbmcgVkZDVCB0
YWJsZSBtZW1vcnkgYXQgW21lbSAweGNjMTcxMDAwLTB4Y2MxN2U2ODNdDQpbICAgIDAuMzQ1MzA1
XSBBQ1BJOiBSZXNlcnZpbmcgU1NEVCB0YWJsZSBtZW1vcnkgYXQgW21lbSAweGNjMTZjMDAwLTB4
Y2MxNmY5ZjNdDQpbICAgIDAuMzUyMzIyXSBBQ1BJOiBSZXNlcnZpbmcgU1NEVCB0YWJsZSBtZW1v
cnkgYXQgW21lbSAweGNjMTY5MDAwLTB4Y2MxNjkxMzhdDQpbICAgIDAuMzU5MzQ0XSBBQ1BJOiBS
ZXNlcnZpbmcgU1NEVCB0YWJsZSBtZW1vcnkgYXQgW21lbSAweGNjMTY4MDAwLTB4Y2MxNjgyMjZd
DQpbICAgIDAuMzY2MzY2XSBBQ1BJOiBSZXNlcnZpbmcgU1NEVCB0YWJsZSBtZW1vcnkgYXQgW21l
bSAweGNjMTY3MDAwLTB4Y2MxNjdkMzZdDQpbICAgIDAuMzczMzg2XSBBQ1BJOiBSZXNlcnZpbmcg
U1NEVCB0YWJsZSBtZW1vcnkgYXQgW21lbSAweGNjMTY1MDAwLTB4Y2MxNjYwYTRdDQpbICAgIDAu
MzgwNDA4XSBBQ1BJOiBSZXNlcnZpbmcgU1NEVCB0YWJsZSBtZW1vcnkgYXQgW21lbSAweGNjMTYx
MDAwLTB4Y2MxNjQwYzddDQpbICAgIDAuMzg3NDI4XSBBQ1BJOiBSZXNlcnZpbmcgU1NEVCB0YWJs
ZSBtZW1vcnkgYXQgW21lbSAweGNjMTVlMDAwLTB4Y2MxNWUwN2NdDQpbICAgIDAuMzk0NDQ2XSBB
Q1BJOiBSZXNlcnZpbmcgU1NEVCB0YWJsZSBtZW1vcnkgYXQgW21lbSAweGNjMTVkMDAwLTB4Y2Mx
NWQ1MTZdDQpbICAgIDAuNDAxNDY2XSBBQ1BJOiBSZXNlcnZpbmcgRlBEVCB0YWJsZSBtZW1vcnkg
YXQgW21lbSAweGNjMTVjMDAwLTB4Y2MxNWMwNDNdDQpbICAgIDAuNDA4NTk1XSBObyBOVU1BIGNv
bmZpZ3VyYXRpb24gZm91bmQNClsgICAgMC40MTIyOTZdIEZha2luZyBhIG5vZGUgYXQgW21lbSAw
eDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAwMDAwODBmMzNmZmZmXQ0KWyAgICAwLjQxODk3NF0gTk9E
RV9EQVRBKDApIGFsbG9jYXRlZCBbbWVtIDB4MTM0YTlmMDAwLTB4MTM0YWEyZmZmXQ0KWyAgICAw
LjQyNDk4MV0gWm9uZSByYW5nZXM6DQpbICAgIDAuNDI3NDY2XSAgIERNQSAgICAgIFttZW0gMHgw
MDAwMDAwMDAwMDAxMDAwLTB4MDAwMDAwMDAwMGZmZmZmZl0NClsgICAgMC40MzM2MTldICAgRE1B
MzIgICAgW21lbSAweDAwMDAwMDAwMDEwMDAwMDAtMHgwMDAwMDAwMGZmZmZmZmZmXQ0KWyAgICAw
LjQzOTc3MF0gICBOb3JtYWwgICBbbWVtIDB4MDAwMDAwMDEwMDAwMDAwMC0weDAwMDAwMDA4MGYz
M2ZmZmZdDQpbICAgIDAuNDQ1OTI4XSBNb3ZhYmxlIHpvbmUgc3RhcnQgZm9yIGVhY2ggbm9kZQ0K
WyAgICAwLjQ1MDE3NF0gRWFybHkgbWVtb3J5IG5vZGUgcmFuZ2VzDQpbICAgIDAuNDUzNzI4XSAg
IG5vZGUgICAwOiBbbWVtIDB4MDAwMDAwMDAwMDAwMTAwMC0weDAwMDAwMDAwMDAwOWZmZmZdDQpb
ICAgIDAuNDU5OTY0XSAgIG5vZGUgICAwOiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAw
MDAwMDliZmVmZmZdDQpbICAgIDAuNDY2MjA4XSAgIG5vZGUgICAwOiBbbWVtIDB4MDAwMDAwMDAw
YTAwMDAwMC0weDAwMDAwMDAwMGExZmZmZmZdDQpbICAgIDAuNDcyNDQzXSAgIG5vZGUgICAwOiBb
bWVtIDB4MDAwMDAwMDAwYTIwZDAwMC0weDAwMDAwMDAwY2FiYzhmZmZdDQpbICAgIDAuNDc4Njg2
XSAgIG5vZGUgICAwOiBbbWVtIDB4MDAwMDAwMDBjZDFmZjAwMC0weDAwMDAwMDAwY2RmZmVmZmZd
DQpbICAgIDAuNDg0OTIzXSAgIG5vZGUgICAwOiBbbWVtIDB4MDAwMDAwMDEwMDAwMDAwMC0weDAw
MDAwMDA4MGYzM2ZmZmZdDQpbICAgIDAuNDkxMTY1XSBJbml0bWVtIHNldHVwIG5vZGUgMCBbbWVt
IDB4MDAwMDAwMDAwMDAwMTAwMC0weDAwMDAwMDA4MGYzM2ZmZmZdDQpbICAgIDAuNDk4MTkxXSBP
biBub2RlIDAsIHpvbmUgRE1BOiAxIHBhZ2VzIGluIHVuYXZhaWxhYmxlIHJhbmdlcw0KWyAgICAw
LjUwNDAwNV0gT24gbm9kZSAwLCB6b25lIERNQTogOTYgcGFnZXMgaW4gdW5hdmFpbGFibGUgcmFu
Z2VzDQpbICAgIDAuNTEwMDExXSBPbiBub2RlIDAsIHpvbmUgRE1BMzI6IDEwMjUgcGFnZXMgaW4g
dW5hdmFpbGFibGUgcmFuZ2VzDQpbICAgIDAuNTIwNjY4XSBPbiBub2RlIDAsIHpvbmUgRE1BMzI6
IDEzIHBhZ2VzIGluIHVuYXZhaWxhYmxlIHJhbmdlcw0KWyAgICAwLjUyNjcwOF0gT24gbm9kZSAw
LCB6b25lIERNQTMyOiA5NzgyIHBhZ2VzIGluIHVuYXZhaWxhYmxlIHJhbmdlcw0KWyAgICAwLjU3
NjA4OV0gT24gbm9kZSAwLCB6b25lIE5vcm1hbDogODE5MyBwYWdlcyBpbiB1bmF2YWlsYWJsZSBy
YW5nZXMNClsgICAgMC41ODIzMDhdIE9uIG5vZGUgMCwgem9uZSBOb3JtYWw6IDMyNjQgcGFnZXMg
aW4gdW5hdmFpbGFibGUgcmFuZ2VzDQpbICAgIDAuNTg5MDUwXSBBQ1BJOiBQTS1UaW1lciBJTyBQ
b3J0OiAweDgwOA0KWyAgICAwLjU5Mjk0NF0gSU9BUElDWzBdOiBhcGljX2lkIDE3LCB2ZXJzaW9u
IDE3LCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuNTk5ODYzXSBJT0FQSUNb
MV06IGFwaWNfaWQgMTgsIHZlcnNpb24gMTcsIGFkZHJlc3MgMHhmZWMwMTAwMCwgR1NJIDI0LTU1
DQpbICAgIDAuNjA2ODQyXSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2Jh
bF9pcnEgMiBkZmwgZGZsKQ0KWyAgICAwLjYxMzE2OV0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAw
IGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQ0KWyAgICAwLjYxOTY3MV0gQUNQSTog
VXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uDQpbICAg
IDAuNjI2MDkyXSBDUFUgdG9wbzogTWF4LiBsb2dpY2FsIHBhY2thZ2VzOiAgIDENClsgICAgMC42
MzA2NzldIENQVSB0b3BvOiBNYXguIGxvZ2ljYWwgZGllczogICAgICAgMQ0KWyAgICAwLjYzNTI2
OV0gQ1BVIHRvcG86IE1heC4gZGllcyBwZXIgcGFja2FnZTogICAxDQpbICAgIDAuNjM5ODcxXSBD
UFUgdG9wbzogTWF4LiB0aHJlYWRzIHBlciBjb3JlOiAgIDENClsgICAgMC42NDQ0NjFdIENQVSB0
b3BvOiBOdW0uIGNvcmVzIHBlciBwYWNrYWdlOiAgICAgNA0KWyAgICAwLjY0OTMxNF0gQ1BVIHRv
cG86IE51bS4gdGhyZWFkcyBwZXIgcGFja2FnZTogICA0DQpbICAgIDAuNjU0MTY3XSBDUFUgdG9w
bzogQWxsb3dpbmcgNCBwcmVzZW50IENQVXMgcGx1cyAwIGhvdHBsdWcgQ1BVcw0KWyAgICAwLjY2
MDI0M10gUE06IGhpYmVybmF0aW9uOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHgw
MDAwMDAwMC0weDAwMDAwZmZmXQ0KWyAgICAwLjY2Nzc3NV0gUE06IGhpYmVybmF0aW9uOiBSZWdp
c3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHgwMDBhMDAwMC0weDAwMGZmZmZmXQ0KWyAgICAw
LjY3NTMxNV0gUE06IGhpYmVybmF0aW9uOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0g
MHgwOWJmZjAwMC0weDA5ZmZmZmZmXQ0KWyAgICAwLjY4Mjg0OV0gUE06IGhpYmVybmF0aW9uOiBS
ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHgwYTIwMDAwMC0weDBhMjBjZmZmXQ0KWyAg
ICAwLjY5MDM5Ml0gUE06IGhpYmVybmF0aW9uOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFtt
ZW0gMHhjYWJjOTAwMC0weGNjMTRjZmZmXQ0KWyAgICAwLjY5NzkzMl0gUE06IGhpYmVybmF0aW9u
OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHhjYzE0ZDAwMC0weGNjMTk1ZmZmXQ0K
WyAgICAwLjcwNTQ3Ml0gUE06IGhpYmVybmF0aW9uOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6
IFttZW0gMHhjYzE5NjAwMC0weGNjMzg4ZmZmXQ0KWyAgICAwLjcxMzAxMl0gUE06IGhpYmVybmF0
aW9uOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHhjYzM4OTAwMC0weGNjMzg5ZmZm
XQ0KWyAgICAwLjcyMDU0OV0gUE06IGhpYmVybmF0aW9uOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1v
cnk6IFttZW0gMHhjYzM4YTAwMC0weGNjNzA5ZmZmXQ0KWyAgICAwLjcyODA5NF0gUE06IGhpYmVy
bmF0aW9uOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHhjYzcwYTAwMC0weGNkMWZl
ZmZmXQ0KWyAgICAwLjczNTYzNV0gUE06IGhpYmVybmF0aW9uOiBSZWdpc3RlcmVkIG5vc2F2ZSBt
ZW1vcnk6IFttZW0gMHhjZGZmZjAwMC0weGNkZmZmZmZmXQ0KWyAgICAwLjc0MzE3NF0gUE06IGhp
YmVybmF0aW9uOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHhjZGZmZjAwMC0weGNk
ZmZmZmZmXQ0KWyAgICAwLjc1MDcxMV0gUE06IGhpYmVybmF0aW9uOiBSZWdpc3RlcmVkIG5vc2F2
ZSBtZW1vcnk6IFttZW0gMHhjZTAwMDAwMC0weGNmZmZmZmZmXQ0KWyAgICAwLjc1ODI0OV0gUE06
IGhpYmVybmF0aW9uOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHhkMDAwMDAwMC0w
eGVmZmZmZmZmXQ0KWyAgICAwLjc2NTc5M10gUE06IGhpYmVybmF0aW9uOiBSZWdpc3RlcmVkIG5v
c2F2ZSBtZW1vcnk6IFttZW0gMHhmMDAwMDAwMC0weGY3ZmZmZmZmXQ0KWyAgICAwLjc3MzY2Nl0g
UE06IGhpYmVybmF0aW9uOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IFttZW0gMHhmODAwMDAw
MC0weGZjZmZmZmZmXQ0KWyAgICAwLjc4MTA2MF0gUE06IGhpYmVybmF0aW9uOiBSZWdpc3RlcmVk
IG5vc2F2ZSBtZW1vcnk6IFttZW0gMHhmZDAwMDAwMC0weGZmZmZmZmZmXQ0KWyAgICAwLjc4ODYw
Ml0gW21lbSAweGQwMDAwMDAwLTB4ZWZmZmZmZmZdIGF2YWlsYWJsZSBmb3IgUENJIGRldmljZXMN
ClsgICAgMC43OTQ2NzJdIEJvb3Rpbmcga2VybmVsIG9uIFhlbiBQVkgNClsgICAgMC43OTgzMDNd
IFhlbiB2ZXJzaW9uOiA0LjIxLXVuc3RhYmxlDQpbICAgIDAuODAyMDM0XSBjbG9ja3NvdXJjZTog
cmVmaW5lZC1qaWZmaWVzOiBtYXNrOiAweGZmZmZmZmZmIG1heF9jeWNsZXM6IDB4ZmZmZmZmZmYs
IG1heF9pZGxlX25zOiAxOTEwOTY5OTQwMzkxNDE5IG5zDQpbICAgIDAuODE3MjUwXSBzZXR1cF9w
ZXJjcHU6IE5SX0NQVVM6NjQgbnJfY3B1bWFza19iaXRzOjQgbnJfY3B1X2lkczo0IG5yX25vZGVf
aWRzOjENClsgICAgMC44MjQ3ODldIHBlcmNwdTogRW1iZWRkZWQgNTcgcGFnZXMvY3B1IHMxOTYz
MTIgcjgxOTIgZDI4OTY4IHU1MjQyODgNClsgICAgMC44MzExNDddIHBjcHUtYWxsb2M6IHMxOTYz
MTIgcjgxOTIgZDI4OTY4IHU1MjQyODggYWxsb2M9MSoyMDk3MTUyDQpbICAgIDAuODM3NDY5XSBw
Y3B1LWFsbG9jOiBbMF0gMCAxIDIgMw0KWyAgICAwLjg0MTA0NV0gS2VybmVsIGNvbW1hbmQgbGlu
ZTogY29uc29sZT1odmMwIHJvb3Q9L2Rldi9yYW0wIGVhcmx5cHJpbnRrPXhlbiBkZWJ1ZyByZGlu
aXQ9L2Jpbi9zaA0KWyAgICAwLjg0OTkxNV0gcmFuZG9tOiBjcm5nIGluaXQgZG9uZQ0KWyAgICAw
Ljg1MzU2Nl0gRGVudHJ5IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTI0Mjg4IChvcmRlcjog
MTAsIDQxOTQzMDQgYnl0ZXMsIGxpbmVhcikNClsgICAgMC44NjE0OTZdIElub2RlLWNhY2hlIGhh
c2ggdGFibGUgZW50cmllczogMjYyMTQ0IChvcmRlcjogOSwgMjA5NzE1MiBieXRlcywgbGluZWFy
KQ0KWyAgICAwLjg2OTA5Nl0gRmFsbGJhY2sgb3JkZXIgZm9yIE5vZGUgMDogMA0KWyAgICAwLjg2
OTA5OV0gQnVpbHQgMSB6b25lbGlzdHMsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFn
ZXM6IDgyMzUxNjINClsgICAgMC44Nzk4OTZdIFBvbGljeSB6b25lOiBOb3JtYWwNClsgICAgMC44
ODMwMjBdIG1lbSBhdXRvLWluaXQ6IHN0YWNrOmFsbCh6ZXJvKSwgaGVhcCBhbGxvYzpvZmYsIGhl
YXAgZnJlZTpvZmYNClsgICAgMC44ODk3ODJdIHNvZnR3YXJlIElPIFRMQjogYXJlYSBudW0gNC4N
ClsgICAgMC45Nzk2NjBdIFNMVUI6IEhXYWxpZ249NjQsIE9yZGVyPTAtMywgTWluT2JqZWN0cz0w
LCBDUFVzPTQsIE5vZGVzPTENClBva2luZyBLQVNMUiB1c2luZyBSRFJBTkQgUkRUU0MuLi4NClsg
ICAgMC45OTAxODZdIER5bmFtaWMgUHJlZW1wdDogdm9sdW50YXJ5DQpbICAgIDAuOTkzNzg5XSBy
Y3U6IFByZWVtcHRpYmxlIGhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDAu
OTk5NDg3XSByY3U6IAlSQ1UgZXZlbnQgdHJhY2luZyBpcyBlbmFibGVkLg0KWyAgICAxLjAwMzk5
NV0gcmN1OiAJUkNVIHJlc3RyaWN0aW5nIENQVXMgZnJvbSBOUl9DUFVTPTY0IHRvIG5yX2NwdV9p
ZHM9NC4NClsgICAgMS4wMTA1ODBdIAlUcmFtcG9saW5lIHZhcmlhbnQgb2YgVGFza3MgUkNVIGVu
YWJsZWQuDQpbICAgIDEuMDE1NjAzXSByY3U6IFJDVSBjYWxjdWxhdGVkIHZhbHVlIG9mIHNjaGVk
dWxlci1lbmxpc3RtZW50IGRlbGF5IGlzIDEwMCBqaWZmaWVzLg0KWyAgICAxLjAyMzIzM10gcmN1
OiBBZGp1c3RpbmcgZ2VvbWV0cnkgZm9yIHJjdV9mYW5vdXRfbGVhZj0xNiwgbnJfY3B1X2lkcz00
DQpbICAgIDEuMDI5OTExXSBSQ1UgVGFza3M6IFNldHRpbmcgc2hpZnQgdG8gMiBhbmQgbGltIHRv
IDEgcmN1X3Rhc2tfY2JfYWRqdXN0PTEuDQpbICAgIDEuMDM4MDc5XSBVc2luZyBOVUxMIGxlZ2Fj
eSBQSUMNClsgICAgMS4wNDEyMjJdIE5SX0lSUVM6IDQzNTIsIG5yX2lycXM6IDEwMDAsIHByZWFs
bG9jYXRlZCBpcnFzOiAwDQpbICAgIDEuMDQ3MDUyXSB4ZW46ZXZlbnRzOiBVc2luZyBGSUZPLWJh
c2VkIEFCSQ0KKFhFTikgWyAgIDEwLjEyOTc4M10gZDB2MDogdXBjYWxsIHZlY3RvciBmMw0KWyAg
ICAxLjA1NTE4N10geGVuOmV2ZW50czogWGVuIEhWTSBjYWxsYmFjayB2ZWN0b3IgZm9yIGV2ZW50
IGRlbGl2ZXJ5IGlzIGVuYWJsZWQNClsgICAgMS4wNjIzMTNdIHJjdTogc3JjdV9pbml0OiBTZXR0
aW5nIHNyY3Vfc3RydWN0IHNpemVzIGJhc2VkIG9uIGNvbnRlbnRpb24uDQpbICAgIDEuMDY5NTA0
XSBDb25zb2xlOiBjb2xvdXIgZHVtbXkgZGV2aWNlIDgweDI1DQpbICAgIDEuMDczNzc2XSBwcmlu
dGs6IGxlZ2FjeSBjb25zb2xlIFt0dHkwXSBlbmFibGVkDQpbICAgIDEuMDc4NzEyXSBwcmludGs6
IGxlZ2FjeSBjb25zb2xlIFtodmMwXSBlbmFibGVkDQoNClsgICAgMS4wNzg3MTJdIHByaW50azog
bGVnYWN5IGNvbnNvbGUgW2h2YzBdIGVuYWJsZWQNClsgICAgMS4wODgwMTRdIHByaW50azogbGVn
YWN5IGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZGlzYWJsZWQNCg0KWyAgICAxLjA4ODAxNF0gcHJp
bnRrOiBsZWdhY3kgYm9vdGNvbnNvbGUgW3hlbmJvb3QwXSBkaXNhYmxlZA0KWyAgICAxLjA5OTAy
OV0gQUNQSTogQ29yZSByZXZpc2lvbiAyMDI0MDMyMg0KDQpbICAgIDEuMTIxNjczXSBGYWlsZWQg
dG8gcmVnaXN0ZXIgbGVnYWN5IHRpbWVyIGludGVycnVwdA0KDQpbICAgIDEuMTI2NjQxXSBBUElD
OiBTd2l0Y2ggdG8gc3ltbWV0cmljIEkvTyBtb2RlIHNldHVwDQoNClsgICAgMS4xMzI0NDldIHgy
YXBpYyBlbmFibGVkDQoNClsgICAgMS4xMzU5OTNdIEFQSUM6IFN3aXRjaGVkIEFQSUMgcm91dGlu
ZyB0bzogcGh5c2ljYWwgeDJhcGljDQoNClsgICAgMS4xNDE1NzFdIGNsb2Nrc291cmNlOiB0c2Mt
ZWFybHk6IG1hc2s6IDB4ZmZmZmZmZmZmZmZmZmZmZiBtYXhfY3ljbGVzOiAweDI5YjkyNGM1Mjhi
LCBtYXhfaWRsZV9uczogNDQwNzk1MzMxNDU0IG5zDQoNClsgICAgMS4xNTIwNjNdIENhbGlicmF0
aW5nIGRlbGF5IGxvb3AgKHNraXBwZWQpLCB2YWx1ZSBjYWxjdWxhdGVkIHVzaW5nIHRpbWVyIGZy
ZXF1ZW5jeS4uIDU3ODkuMDkgQm9nb01JUFMgKGxwaj0yODk0NTQ4KQ0KDQpbICAgIDEuMTUzMDYx
XSB4ODYvY3B1OiBVc2VyIE1vZGUgSW5zdHJ1Y3Rpb24gUHJldmVudGlvbiAoVU1JUCkgYWN0aXZh
dGVkDQoNClsgICAgMS4xNTMwNjFdIExhc3QgbGV2ZWwgaVRMQiBlbnRyaWVzOiA0S0IgMTAyNCwg
Mk1CIDEwMjQsIDRNQiA1MTINCg0KWyAgICAxLjE1MzA2MV0gTGFzdCBsZXZlbCBkVExCIGVudHJp
ZXM6IDRLQiAyMDQ4LCAyTUIgMjA0OCwgNE1CIDEwMjQsIDFHQiAwDQoNClsgICAgMS4xNTMwNjFd
IFNwZWN0cmUgVjEgOiBNaXRpZ2F0aW9uOiB1c2VyY29weS9zd2FwZ3MgYmFycmllcnMgYW5kIF9f
dXNlciBwb2ludGVyIHNhbml0aXphdGlvbg0KDQpbICAgIDEuMTUzMDYxXSBTcGVjdHJlIFYyIDog
TWl0aWdhdGlvbjogUmV0cG9saW5lcw0KDQpbICAgIDEuMTUzMDYxXSBTcGVjdHJlIFYyIDogU3Bl
Y3RyZSB2MiAvIFNwZWN0cmVSU0IgbWl0aWdhdGlvbjogRmlsbGluZyBSU0Igb24gY29udGV4dCBz
d2l0Y2gNCg0KWyAgICAxLjE1MzA2MV0gU3BlY3RyZSBWMiA6IFNwZWN0cmUgdjIgLyBTcGVjdHJl
UlNCIDogRmlsbGluZyBSU0Igb24gVk1FWElUDQoNClsgICAgMS4xNTMwNjFdIFNwZWN0cmUgVjIg
OiBFbmFibGluZyBTcGVjdWxhdGlvbiBCYXJyaWVyIGZvciBmaXJtd2FyZSBjYWxscw0KDQpbICAg
IDEuMTUzMDYxXSBSRVRCbGVlZDogTWl0aWdhdGlvbjogdW50cmFpbmVkIHJldHVybiB0aHVuaw0K
DQpbICAgIDEuMTUzMDYxXSBTcGVjdHJlIFYyIDogbWl0aWdhdGlvbjogRW5hYmxpbmcgY29uZGl0
aW9uYWwgSW5kaXJlY3QgQnJhbmNoIFByZWRpY3Rpb24gQmFycmllcg0KDQpbICAgIDEuMTUzMDYx
XSBTcGVjdWxhdGl2ZSBTdG9yZSBCeXBhc3M6IE1pdGlnYXRpb246IFNwZWN1bGF0aXZlIFN0b3Jl
IEJ5cGFzcyBkaXNhYmxlZCB2aWEgcHJjdGwNCg0KWyAgICAxLjE1MzA2MV0geDg2L2ZwdTogU3Vw
cG9ydGluZyBYU0FWRSBmZWF0dXJlIDB4MDAxOiAneDg3IGZsb2F0aW5nIHBvaW50IHJlZ2lzdGVy
cycNCg0KWyAgICAxLjE1MzA2MV0geDg2L2ZwdTogU3VwcG9ydGluZyBYU0FWRSBmZWF0dXJlIDB4
MDAyOiAnU1NFIHJlZ2lzdGVycycNCg0KWyAgICAxLjE1MzA2MV0geDg2L2ZwdTogU3VwcG9ydGlu
ZyBYU0FWRSBmZWF0dXJlIDB4MDA0OiAnQVZYIHJlZ2lzdGVycycNCg0KWyAgICAxLjE1MzA2MV0g
eDg2L2ZwdTogeHN0YXRlX29mZnNldFsyXTogIDU3NiwgeHN0YXRlX3NpemVzWzJdOiAgMjU2DQoN
ClsgICAgMS4xNTMwNjFdIHg4Ni9mcHU6IEVuYWJsZWQgeHN0YXRlIGZlYXR1cmVzIDB4NywgY29u
dGV4dCBzaXplIGlzIDgzMiBieXRlcywgdXNpbmcgJ2NvbXBhY3RlZCcgZm9ybWF0Lg0KDQpbICAg
IDEuMTUzMDYxXSBGcmVlaW5nIFNNUCBhbHRlcm5hdGl2ZXMgbWVtb3J5OiA1MksNCg0KWyAgICAx
LjE1MzA2MV0gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTogMzAxDQoNClsgICAgMS4x
NTMwNjFdIExTTTogaW5pdGlhbGl6aW5nIGxzbT1jYXBhYmlsaXR5LHNlbGludXgNCg0KWyAgICAx
LjE1MzA2MV0gU0VMaW51eDogIEluaXRpYWxpemluZy4NCg0KWyAgICAxLjE1MzA2MV0gTW91bnQt
Y2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA4MTkyIChvcmRlcjogNCwgNjU1MzYgYnl0ZXMsIGxp
bmVhcikNCg0KWyAgICAxLjE1MzA2MV0gTW91bnRwb2ludC1jYWNoZSBoYXNoIHRhYmxlIGVudHJp
ZXM6IDgxOTIgKG9yZGVyOiA0LCA2NTUzNiBieXRlcywgbGluZWFyKQ0KDQpbICAgIDEuMTUzMDYx
XSBjbG9ja3NvdXJjZTogeGVuOiBtYXNrOiAweGZmZmZmZmZmZmZmZmZmZmYgbWF4X2N5Y2xlczog
MHgxY2Q0MmU0ZGZmYiwgbWF4X2lkbGVfbnM6IDg4MTU5MDU5MTQ4MyBucw0KDQpbICAgIDEuMTUz
MDYxXSBYZW46IHVzaW5nIHZjcHVvcCB0aW1lciBpbnRlcmZhY2UNCg0KWyAgICAxLjE1MzA2MV0g
aW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAwDQoNClsgICAgMS4xNTMwNjFdIHNtcGJvb3Q6
IENQVTA6IEFNRCBSeXplbiBFbWJlZGRlZCBWMjc0OCB3aXRoIFJhZGVvbiBHcmFwaGljcyAoZmFt
aWx5OiAweDE3LCBtb2RlbDogMHg2MCwgc3RlcHBpbmc6IDB4MSkNCg0KWyAgICAxLjE1MzE4MF0g
UGVyZm9ybWFuY2UgRXZlbnRzOiBQTVUgbm90IGF2YWlsYWJsZSBkdWUgdG8gdmlydHVhbGl6YXRp
b24sIHVzaW5nIHNvZnR3YXJlIGV2ZW50cyBvbmx5Lg0KDQpbICAgIDEuMTU0MDgyXSBzaWduYWw6
IG1heCBzaWdmcmFtZSBzaXplOiAxNzc2DQoNClsgICAgMS4xNTUwODNdIHJjdTogSGllcmFyY2hp
Y2FsIFNSQ1UgaW1wbGVtZW50YXRpb24uDQoNClsgICAgMS4xNTYwNjddIHJjdTogCU1heCBwaGFz
ZSBuby1kZWxheSBpbnN0YW5jZXMgaXMgNDAwLg0KDQpbICAgIDEuMTU3MDkxXSBUaW1lciBtaWdy
YXRpb246IDEgaGllcmFyY2h5IGxldmVsczsgOCBjaGlsZHJlbiBwZXIgZ3JvdXA7IDEgY3Jvc3Nu
b2RlIGxldmVsDQoNClsgICAgMS4xNjA5MzRdIHNtcDogQnJpbmdpbmcgdXAgc2Vjb25kYXJ5IENQ
VXMgLi4uDQoNClsgICAgMS4xNjExMjBdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMQ0K
DQpbICAgIDEuMTYyMTMwXSBzbXBib290OiB4ODY6IEJvb3RpbmcgU01QIGNvbmZpZ3VyYXRpb246
DQoNCihYRU4pIFsgICAxMC40ODI3ODFdIGNvbW1vbi9zY2hlZC9udWxsLmM6MzU3OiAxIDwtLSBk
MHYxDQpbICAgIDEuMTYzMDY4XSAuLi4uIG5vZGUgICMwLCBDUFVzOiAgICAgICMxDQoNClsgICAg
MS4xNjQ1NTZdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMg0KDQooWEVOKSBbICAgMTAu
NDk2MzgyXSBjb21tb24vc2NoZWQvbnVsbC5jOjM1NzogMiA8LS0gZDB2Mg0KWyAgICAxLjE2NjE1
MF0gICMyDQoNClsgICAgMS4xNjcxODhdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMw0K
DQooWEVOKSBbICAgMTAuNTA3NDIxXSBjb21tb24vc2NoZWQvbnVsbC5jOjM1NzogMyA8LS0gZDB2
Mw0KWyAgICAxLjE2OTE3NV0gICMzDQoNClsgICAgMS4xNzMxMzRdIHNtcDogQnJvdWdodCB1cCAx
IG5vZGUsIDQgQ1BVcw0KDQpbICAgIDEuMTc1MDY5XSBzbXBib290OiBUb3RhbCBvZiA0IHByb2Nl
c3NvcnMgYWN0aXZhdGVkICgyMzE1Ni4zOCBCb2dvTUlQUykNCg0KWyAgICAxLjE3NzExMV0gTWVt
b3J5OiAzMzQ5MjkySy8zMjk0MDY0OEsgYXZhaWxhYmxlICgyMDQ4MEsga2VybmVsIGNvZGUsIDI5
MjZLIHJ3ZGF0YSwgNzI3Nksgcm9kYXRhLCAyOTgwSyBpbml0LCAyNTI0SyBic3MsIDI5NTg3NDAw
SyByZXNlcnZlZCwgMEsgY21hLXJlc2VydmVkKQ0KDQpbICAgIDEuMTc4ODE0XSBkZXZ0bXBmczog
aW5pdGlhbGl6ZWQNCg0KWyAgICAxLjE3OTA4OV0geDg2L21tOiBNZW1vcnkgYmxvY2sgc2l6ZTog
MTI4TUINCg0KWyAgICAxLjE4MjA4N10gQUNQSTogUE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJl
Z2lvbiBbbWVtIDB4MGEyMDAwMDAtMHgwYTIwY2ZmZl0gKDUzMjQ4IGJ5dGVzKQ0KDQpbICAgIDEu
MTgzMDY5XSBBQ1BJOiBQTTogUmVnaXN0ZXJpbmcgQUNQSSBOVlMgcmVnaW9uIFttZW0gMHhjYzE5
NjAwMC0weGNjMzg4ZmZmXSAoMjA0MzkwNCBieXRlcykNCg0KWyAgICAxLjE4NDA4Nl0gQUNQSTog
UE06IFJlZ2lzdGVyaW5nIEFDUEkgTlZTIHJlZ2lvbiBbbWVtIDB4Y2MzOGEwMDAtMHhjYzcwOWZm
Zl0gKDM2NzAwMTYgYnl0ZXMpDQoNClsgICAgMS4xODUxMjJdIGNsb2Nrc291cmNlOiBqaWZmaWVz
OiBtYXNrOiAweGZmZmZmZmZmIG1heF9jeWNsZXM6IDB4ZmZmZmZmZmYsIG1heF9pZGxlX25zOiAx
OTExMjYwNDQ2Mjc1MDAwIG5zDQoNClsgICAgMS4xODYwNzFdIGZ1dGV4IGhhc2ggdGFibGUgZW50
cmllczogMTAyNCAob3JkZXI6IDQsIDY1NTM2IGJ5dGVzLCBsaW5lYXIpDQoNClsgICAgMS4xODcx
MzRdIFBNOiBSVEMgdGltZTogMDY6MzU6MDMsIGRhdGU6IDIwMjUtMDUtMTYNCg0KWyAgICAxLjE4
ODI0NF0gTkVUOiBSZWdpc3RlcmVkIFBGX05FVExJTksvUEZfUk9VVEUgcHJvdG9jb2wgZmFtaWx5
DQoNClsgICAgMS4xODkwODJdIHhlbjpncmFudF90YWJsZTogR3JhbnQgdGFibGVzIHVzaW5nIHZl
cnNpb24gMSBsYXlvdXQNCg0KWyAgICAxLjE5MDA4NV0gR3JhbnQgdGFibGUgaW5pdGlhbGl6ZWQN
Cg0KWyAgICAxLjE5MTE0MF0gYXVkaXQ6IGluaXRpYWxpemluZyBuZXRsaW5rIHN1YnN5cyAoZGlz
YWJsZWQpDQoNClsgICAgMS4xOTIwNzldIGF1ZGl0OiB0eXBlPTIwMDAgYXVkaXQoMTc0NzM3NzMw
NC4yMzY6MSk6IHN0YXRlPWluaXRpYWxpemVkIGF1ZGl0X2VuYWJsZWQ9MCByZXM9MQ0KDQpbICAg
IDEuMTkyMTE4XSB0aGVybWFsX3N5czogUmVnaXN0ZXJlZCB0aGVybWFsIGdvdmVybm9yICdzdGVw
X3dpc2UnDQoNClsgICAgMS4yMDAwNzFdIHRoZXJtYWxfc3lzOiBSZWdpc3RlcmVkIHRoZXJtYWwg
Z292ZXJub3IgJ3VzZXJfc3BhY2UnDQoNClsgICAgMS4yMDYwNzhdIGNwdWlkbGU6IHVzaW5nIGdv
dmVybm9yIG1lbnUNCg0KWyAgICAxLjIxNjI4MV0gUENJOiBFQ0FNIFttZW0gMHhmMDAwMDAwMC0w
eGY3ZmZmZmZmXSAoYmFzZSAweGYwMDAwMDAwKSBmb3IgZG9tYWluIDAwMDAgW2J1cyAwMC03Zl0N
Cg0KWyAgICAxLjIyNTA4M10gUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgYmFz
ZSBhY2Nlc3MNCg0KWyAgICAxLjIzMTA4OV0ga3Byb2Jlczoga3Byb2JlIGp1bXAtb3B0aW1pemF0
aW9uIGlzIGVuYWJsZWQuIEFsbCBrcHJvYmVzIGFyZSBvcHRpbWl6ZWQgaWYgcG9zc2libGUuDQoN
ClsgICAgMS4yNDAxNjldIEh1Z2VUTEI6IHJlZ2lzdGVyZWQgMS4wMCBHaUIgcGFnZSBzaXplLCBw
cmUtYWxsb2NhdGVkIDAgcGFnZXMNCg0KWyAgICAxLjI0NjA2OV0gSHVnZVRMQjogMTYzODAgS2lC
IHZtZW1tYXAgY2FuIGJlIGZyZWVkIGZvciBhIDEuMDAgR2lCIHBhZ2UNCg0KWyAgICAxLjI1MzA2
OF0gSHVnZVRMQjogcmVnaXN0ZXJlZCAyLjAwIE1pQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQg
MCBwYWdlcw0KDQpbICAgIDEuMjYwMDY5XSBIdWdlVExCOiAyOCBLaUIgdm1lbW1hcCBjYW4gYmUg
ZnJlZWQgZm9yIGEgMi4wMCBNaUIgcGFnZQ0KDQpbICAgIDEuMjY2MTIyXSBBQ1BJOiBBZGRlZCBf
T1NJKE1vZHVsZSBEZXZpY2UpDQoNClsgICAgMS4yNzAwNjhdIEFDUEk6IEFkZGVkIF9PU0koUHJv
Y2Vzc29yIERldmljZSkNCg0KWyAgICAxLjI3NTA2OV0gQUNQSTogQWRkZWQgX09TSSgzLjAgX1ND
UCBFeHRlbnNpb25zKQ0KDQpbICAgIDEuMjgwMDY3XSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3Nv
ciBBZ2dyZWdhdG9yIERldmljZSkNCg0KWyAgICAxLjI5NjY1OV0gQUNQSTogMTEgQUNQSSBBTUwg
dGFibGVzIHN1Y2Nlc3NmdWxseSBhY3F1aXJlZCBhbmQgbG9hZGVkDQoNCihYRU4pIFsgICAxMC43
MzkwOTJdIGQwOiBiaW5kOiBtX2dzaT05IGdfZ3NpPTkNClsgICAgMS4zMDg1ODFdIEFDUEk6IFtG
aXJtd2FyZSBCdWddOiBCSU9TIF9PU0koTGludXgpIHF1ZXJ5IGlnbm9yZWQNCg0KWyAgICAxLjMx
ODgxOV0gQUNQSTogSW50ZXJwcmV0ZXIgZW5hYmxlZA0KDQpbICAgIDEuMzIyMDgyXSBBQ1BJOiBQ
TTogKHN1cHBvcnRzIFMwIFMzIFM0IFM1KQ0KDQpbICAgIDEuMzI3MDY5XSBBQ1BJOiBVc2luZyBJ
T0FQSUMgZm9yIGludGVycnVwdCByb3V0aW5nDQoNClsgICAgMS4zMzIzMjRdIFBDSTogVXNpbmcg
aG9zdCBicmlkZ2Ugd2luZG93cyBmcm9tIEFDUEk7IGlmIG5lY2Vzc2FyeSwgdXNlICJwY2k9bm9j
cnMiIGFuZCByZXBvcnQgYSBidWcNCg0KWyAgICAxLjM0MTA3Nl0gUENJOiBJZ25vcmluZyBFODIw
IHJlc2VydmF0aW9ucyBmb3IgaG9zdCBicmlkZ2Ugd2luZG93cw0KDQpbICAgIDEuMzQ3NDM2XSBB
Q1BJOiBFbmFibGVkIDYgR1BFcyBpbiBibG9jayAwMCB0byAxRg0KDQpbICAgIDEuMzUzNjA4XSBB
Q1BJOiBcX1NCXy5QMFMwOiBOZXcgcG93ZXIgcmVzb3VyY2UNCg0KWyAgICAxLjM1ODA4N10gQUNQ
STogXF9TQl8uUDNTMDogTmV3IHBvd2VyIHJlc291cmNlDQoNClsgICAgMS4zNjMxMTldIEFDUEk6
IFxfU0JfLlAwUzE6IE5ldyBwb3dlciByZXNvdXJjZQ0KDQpbICAgIDEuMzY3MDg2XSBBQ1BJOiBc
X1NCXy5QM1MxOiBOZXcgcG93ZXIgcmVzb3VyY2UNCg0KWyAgICAxLjM3ODQzNl0gQUNQSTogXF9T
Ql8uUFJXTDogTmV3IHBvd2VyIHJlc291cmNlDQoNClsgICAgMS4zODMwODddIEFDUEk6IFxfU0Jf
LlBSV0I6IE5ldyBwb3dlciByZXNvdXJjZQ0KDQpbICAgIDEuMzg3NDI3XSBBQ1BJOiBQQ0kgUm9v
dCBCcmlkZ2UgW1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkNCg0KWyAgICAxLjM5NDA3
MV0gYWNwaSBQTlAwQTA4OjAwOiBfT1NDOiBPUyBzdXBwb3J0cyBbRXh0ZW5kZWRDb25maWcgQVNQ
TSBDbG9ja1BNIFNlZ21lbnRzIE1TSSBIUFgtVHlwZTNdDQoNClsgICAgMS40MDMyMDNdIGFjcGkg
UE5QMEEwODowMDogX09TQzogT1Mgbm93IGNvbnRyb2xzIFtQTUUgUENJZUNhcGFiaWxpdHkgTFRS
XQ0KDQpbICAgIDEuNDEwMDc0XSBhY3BpIFBOUDBBMDg6MDA6IFtGaXJtd2FyZSBJbmZvXTogRUNB
TSBbbWVtIDB4ZjAwMDAwMDAtMHhmN2ZmZmZmZl0gZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtN2Zd
IG9ubHkgcGFydGlhbGx5IGNvdmVycyB0aGlzIGJyaWRnZQ0KDQpbICAgIDEuNDIxMzYyXSBQQ0kg
aG9zdCBicmlkZ2UgdG8gYnVzIDAwMDA6MDANCg0KWyAgICAxLjQyNTA2OV0gcGNpX2J1cyAwMDAw
OjAwOiByb290IGJ1cyByZXNvdXJjZSBbaW8gIDB4MDAwMC0weDAzYWYgd2luZG93XQ0KDQpbICAg
IDEuNDMyMDY4XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFtpbyAgMHgwM2Uw
LTB4MGNmNyB3aW5kb3ddDQoNClsgICAgMS40MzkwNjhdIHBjaV9idXMgMDAwMDowMDogcm9vdCBi
dXMgcmVzb3VyY2UgW2lvICAweDAzYjAtMHgwM2RmIHdpbmRvd10NCg0KWyAgICAxLjQ0NjA2OV0g
cGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbaW8gIDB4MGQwMC0weGZmZmYgd2lu
ZG93XQ0KDQpbICAgIDEuNDUyMDc0XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNl
IFttZW0gMHgwMDBhMDAwMC0weDAwMGRmZmZmIHdpbmRvd10NCg0KWyAgICAxLjQ2MDA3MF0gcGNp
X2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbbWVtIDB4ZDAwMDAwMDAtMHhmZWJmZmZm
ZiB3aW5kb3ddDQoNClsgICAgMS40NjcwNzJdIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVz
b3VyY2UgW21lbSAweGZlZTAwMDAwLTB4ZmZmZmZmZmYgd2luZG93XQ0KDQpbICAgIDEuNDc1MDY4
XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFttZW0gMHg4MzAwMDAwMDAtMHhm
ZmZmZmZmZmZmIHdpbmRvd10NCg0KWyAgICAxLjQ4MjA3MV0gcGNpX2J1cyAwMDAwOjAwOiByb290
IGJ1cyByZXNvdXJjZSBbYnVzIDAwLWZmXQ0KDQpbICAgIDEuNDg4MDk4XSBwY2kgMDAwMDowMDow
MC4wOiBbMTAyMjoxNjMwXSB0eXBlIDAwIGNsYXNzIDB4MDYwMDAwIGNvbnZlbnRpb25hbCBQQ0kg
ZW5kcG9pbnQNCg0KKFhFTikgWyAgIDEwLjkzNTA2NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDow
MC4wDQpbICAgIDEuNDk5MDk2XSBwY2kgMDAwMDowMDowMC4yOiBbMTAyMjoxNjMxXSB0eXBlIDAw
IGNsYXNzIDB4MDgwNjAwIGNvbnZlbnRpb25hbCBQQ0kgZW5kcG9pbnQNCg0KKFhFTikgWyAgIDEw
Ljk0NzcxNl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yDQpbICAgIDEuNTEyMDk5XSBwY2kg
MDAwMDowMDowMS4wOiBbMTAyMjoxNjMyXSB0eXBlIDAwIGNsYXNzIDB4MDYwMDAwIGNvbnZlbnRp
b25hbCBQQ0kgZW5kcG9pbnQNCg0KKFhFTikgWyAgIDEwLjk2MDM3OF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDowMS4wDQpbICAgIDEuNTI0MTAzXSBwY2kgMDAwMDowMDowMi4wOiBbMTAyMjoxNjMy
XSB0eXBlIDAwIGNsYXNzIDB4MDYwMDAwIGNvbnZlbnRpb25hbCBQQ0kgZW5kcG9pbnQNCg0KKFhF
TikgWyAgIDEwLjk3MzAzNl0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wDQpbICAgIDEuNTM3
MDk3XSBwY2kgMDAwMDowMDowMi4xOiBbMTAyMjoxNjM0XSB0eXBlIDAxIGNsYXNzIDB4MDYwNDAw
IFBDSWUgUm9vdCBQb3J0DQoNClsgICAgMS41NDQxMjFdIHBjaSAwMDAwOjAwOjAyLjE6IFBDSSBi
cmlkZ2UgdG8gW2J1cyAwMV0NCg0KWyAgICAxLjU0OTA5Ml0gcGNpIDAwMDA6MDA6MDIuMTogICBi
cmlkZ2Ugd2luZG93IFttZW0gMHhmZmUwMDAwMDAwLTB4ZmZmODBmZmZmZiA2NGJpdCBwcmVmXQ0K
DQpbICAgIDEuNTU3MjcxXSBwY2kgMDAwMDowMDowMi4xOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQw
IEQzaG90IEQzY29sZA0KDQooWEVOKSBbICAgMTEuMDA0Mjk2XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjAyLjENClsgICAgMS41NjgwOTldIHBjaSAwMDAwOjAwOjAyLjM6IFsxMDIyOjE2MzRdIHR5
cGUgMDEgY2xhc3MgMHgwNjA0MDAgUENJZSBSb290IFBvcnQNCg0KWyAgICAxLjU3NTExOV0gcGNp
IDAwMDA6MDA6MDIuMzogUENJIGJyaWRnZSB0byBbYnVzIDAyXQ0KDQpbICAgIDEuNTgwMDc4XSBw
Y2kgMDAwMDowMDowMi4zOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlYTAwMDAwLTB4ZmVhZmZm
ZmZdDQoNClsgICAgMS41ODcwOThdIHBjaSAwMDAwOjAwOjAyLjM6IGVuYWJsaW5nIEV4dGVuZGVk
IFRhZ3MNCg0KWyAgICAxLjU5MjI2MF0gcGNpIDAwMDA6MDA6MDIuMzogUE1FIyBzdXBwb3J0ZWQg
ZnJvbSBEMCBEM2hvdCBEM2NvbGQNCg0KKFhFTikgWyAgIDExLjAzOTIyNF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDowMi4zDQpbICAgIDEuNjAyMDk3XSBwY2kgMDAwMDowMDowMi40OiBbMTAyMjox
NjM0XSB0eXBlIDAxIGNsYXNzIDB4MDYwNDAwIFBDSWUgUm9vdCBQb3J0DQoNClsgICAgMS42MTAx
MThdIHBjaSAwMDAwOjAwOjAyLjQ6IFBDSSBicmlkZ2UgdG8gW2J1cyAwM10NCg0KWyAgICAxLjYx
NDA3N10gcGNpIDAwMDA6MDA6MDIuNDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhmMDAwLTB4ZmZm
Zl0NCg0KWyAgICAxLjYyMTA3MV0gcGNpIDAwMDA6MDA6MDIuNDogICBicmlkZ2Ugd2luZG93IFtt
ZW0gMHhmZTkwMDAwMC0weGZlOWZmZmZmXQ0KDQpbICAgIDEuNjI3MDk4XSBwY2kgMDAwMDowMDow
Mi40OiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNClsgICAgMS42MzIyNTVdIHBjaSAwMDAwOjAw
OjAyLjQ6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQoNCihYRU4pIFsgICAx
MS4wODAzNDddIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MDIuNA0KWyAgICAxLjY0MzEwNl0gcGNp
IDAwMDA6MDA6MDguMDogWzEwMjI6MTYzMl0gdHlwZSAwMCBjbGFzcyAweDA2MDAwMCBjb252ZW50
aW9uYWwgUENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAxMS4wOTMwMDhdIFBDSSBhZGQgZGV2aWNl
IDAwMDA6MDA6MDguMA0KWyAgICAxLjY1NTA5Nl0gcGNpIDAwMDA6MDA6MDguMTogWzEwMjI6MTYz
NV0gdHlwZSAwMSBjbGFzcyAweDA2MDQwMCBQQ0llIFJvb3QgUG9ydA0KDQpbICAgIDEuNjYzMTE5
XSBwY2kgMDAwMDowMDowOC4xOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDRdDQoNClsgICAgMS42Njgw
NzVdIHBjaSAwMDAwOjAwOjA4LjE6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZTAwMC0weGVmZmZd
DQoNClsgICAgMS42NzQwNzFdIHBjaSAwMDAwOjAwOjA4LjE6ICAgYnJpZGdlIHdpbmRvdyBbbWVt
IDB4ZmU0MDAwMDAtMHhmZTdmZmZmZl0NCg0KWyAgICAxLjY4MDA4MV0gcGNpIDAwMDA6MDA6MDgu
MTogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkMDAwMDAwMC0weGUwMWZmZmZmIDY0Yml0IHByZWZd
DQoNClsgICAgMS42ODgwODNdIHBjaSAwMDAwOjAwOjA4LjE6IGVuYWJsaW5nIEV4dGVuZGVkIFRh
Z3MNCg0KWyAgICAxLjY5MzIyOF0gcGNpIDAwMDA6MDA6MDguMTogUE1FIyBzdXBwb3J0ZWQgZnJv
bSBEMCBEM2hvdCBEM2NvbGQNCg0KKFhFTikgWyAgIDExLjE0MTgyMF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDowOC4xDQpbICAgIDEuNzA0MTAwXSBwY2kgMDAwMDowMDowOC4yOiBbMTAyMjoxNjM1
XSB0eXBlIDAxIGNsYXNzIDB4MDYwNDAwIFBDSWUgUm9vdCBQb3J0DQoNClsgICAgMS43MTExMjJd
IHBjaSAwMDAwOjAwOjA4LjI6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNV0NCg0KWyAgICAxLjcxNjA3
OF0gcGNpIDAwMDA6MDA6MDguMjogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZTgwMDAwMC0weGZl
OGZmZmZmXQ0KDQpbICAgIDEuNzIzMDk2XSBwY2kgMDAwMDowMDowOC4yOiBlbmFibGluZyBFeHRl
bmRlZCBUYWdzDQoNClsgICAgMS43MjgyMjldIHBjaSAwMDAwOjAwOjA4LjI6IFBNRSMgc3VwcG9y
dGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQoNCihYRU4pIFsgICAxMS4xNzY2NzhdIFBDSSBhZGQg
ZGV2aWNlIDAwMDA6MDA6MDguMg0KWyAgICAxLjczODExOV0gcGNpIDAwMDA6MDA6MTQuMDogWzEw
MjI6NzkwYl0gdHlwZSAwMCBjbGFzcyAweDBjMDUwMCBjb252ZW50aW9uYWwgUENJIGVuZHBvaW50
DQoNCihYRU4pIFsgICAxMS4xODk0MDBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuMA0KWyAg
ICAxLjc1MTA4OF0gcGNpIDAwMDA6MDA6MTQuMzogWzEwMjI6NzkwZV0gdHlwZSAwMCBjbGFzcyAw
eDA2MDEwMCBjb252ZW50aW9uYWwgUENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAxMS4yMDIxMjNd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuMw0KWyAgICAxLjc2MzEwOF0gcGNpIDAwMDA6MDA6
MTguMDogWzEwMjI6MTQ0OF0gdHlwZSAwMCBjbGFzcyAweDA2MDAwMCBjb252ZW50aW9uYWwgUENJ
IGVuZHBvaW50DQoNCihYRU4pIFsgICAxMS4yMTQ3ODJdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6
MTguMA0KWyAgICAxLjc3NjA4Nl0gcGNpIDAwMDA6MDA6MTguMTogWzEwMjI6MTQ0OV0gdHlwZSAw
MCBjbGFzcyAweDA2MDAwMCBjb252ZW50aW9uYWwgUENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAx
MS4yMjc0MzZdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMQ0KWyAgICAxLjc4ODA4N10gcGNp
IDAwMDA6MDA6MTguMjogWzEwMjI6MTQ0YV0gdHlwZSAwMCBjbGFzcyAweDA2MDAwMCBjb252ZW50
aW9uYWwgUENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAxMS4yNDAwODldIFBDSSBhZGQgZGV2aWNl
IDAwMDA6MDA6MTguMg0KWyAgICAxLjgwMTA4Nl0gcGNpIDAwMDA6MDA6MTguMzogWzEwMjI6MTQ0
Yl0gdHlwZSAwMCBjbGFzcyAweDA2MDAwMCBjb252ZW50aW9uYWwgUENJIGVuZHBvaW50DQoNCihY
RU4pIFsgICAxMS4yNTI3MzldIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMw0KWyAgICAxLjgx
MzA4NV0gcGNpIDAwMDA6MDA6MTguNDogWzEwMjI6MTQ0Y10gdHlwZSAwMCBjbGFzcyAweDA2MDAw
MCBjb252ZW50aW9uYWwgUENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAxMS4yNjUzOTNdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDA6MTguNA0KWyAgICAxLjgyNjA4NV0gcGNpIDAwMDA6MDA6MTguNTog
WzEwMjI6MTQ0ZF0gdHlwZSAwMCBjbGFzcyAweDA2MDAwMCBjb252ZW50aW9uYWwgUENJIGVuZHBv
aW50DQoNCihYRU4pIFsgICAxMS4yNzgwNDldIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguNQ0K
WyAgICAxLjgzODA4NV0gcGNpIDAwMDA6MDA6MTguNjogWzEwMjI6MTQ0ZV0gdHlwZSAwMCBjbGFz
cyAweDA2MDAwMCBjb252ZW50aW9uYWwgUENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAxMS4yOTA2
OTZdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguNg0KWyAgICAxLjg1MTA4NV0gcGNpIDAwMDA6
MDA6MTguNzogWzEwMjI6MTQ0Zl0gdHlwZSAwMCBjbGFzcyAweDA2MDAwMCBjb252ZW50aW9uYWwg
UENJIGVuZHBvaW50DQoNCihYRU4pIFsgICAxMS4zMDMzNTNdIFBDSSBhZGQgZGV2aWNlIDAwMDA6
MDA6MTguNw0KWyAgICAxLjg2MzE2OF0gcGNpIDAwMDA6MDE6MDAuMDogWzEwZWU6NTcwMF0gdHlw
ZSAwMCBjbGFzcyAweDEyMDAwMCBQQ0llIEVuZHBvaW50DQoNClsgICAgMS44NzAwOTddIHBjaSAw
MDAwOjAxOjAwLjA6IEJBUiAwIFttZW0gMHhmZmUwMDAwMDAwLTB4ZmZlZmZmZmZmZiA2NGJpdCBw
cmVmXQ0KDQpbICAgIDEuODc4MDg1XSBwY2kgMDAwMDowMTowMC4wOiBCQVIgMiBbbWVtIDB4ZmZm
ODA0MDAwMC0weGZmZjgwN2ZmZmYgNjRiaXQgcHJlZl0NCg0KWyAgICAxLjg4NTI4MF0gcGNpIDAw
MDA6MDE6MDAuMDogc3VwcG9ydHMgRDENCg0KWyAgICAxLjg4OTA2OF0gcGNpIDAwMDA6MDE6MDAu
MDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEM2hvdCBEM2NvbGQNCg0KKFhFTikgWyAgIDEx
LjM0MDI2MV0gUENJIGFkZCBkZXZpY2UgMDAwMDowMTowMC4wDQpbICAgIDEuOTAwMTEzXSBwY2kg
MDAwMDowMTowMC4xOiBbMTBlZTo1NzAxXSB0eXBlIDAwIGNsYXNzIDB4MTIwMDAwIFBDSWUgRW5k
cG9pbnQNCg0KWyAgICAxLjkwNzA5N10gcGNpIDAwMDA6MDE6MDAuMTogQkFSIDAgW21lbSAweGZm
ZjgwMDAwMDAtMHhmZmY4MDNmZmZmIDY0Yml0IHByZWZdDQoNClsgICAgMS45MTQwODVdIHBjaSAw
MDAwOjAxOjAwLjE6IEJBUiAyIFttZW0gMHhmZmYwMDAwMDAwLTB4ZmZmN2ZmZmZmZiA2NGJpdCBw
cmVmXQ0KDQpbICAgIDEuOTIxMjY0XSBwY2kgMDAwMDowMTowMC4xOiBzdXBwb3J0cyBEMQ0KDQpb
ICAgIDEuOTI1MDY3XSBwY2kgMDAwMDowMTowMC4xOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQx
IEQzaG90IEQzY29sZA0KDQooWEVOKSBbICAgMTEuMzc3MDkzXSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAxOjAwLjENClsgICAgMS45MzYwOTJdIHBjaSAwMDAwOjAwOjAyLjE6IFBDSSBicmlkZ2UgdG8g
W2J1cyAwMV0NCg0KWyAgICAxLjk0MTE3Ml0gcGNpIDAwMDA6MDI6MDAuMDogWzE0NGQ6YTgwOF0g
dHlwZSAwMCBjbGFzcyAweDAxMDgwMiBQQ0llIEVuZHBvaW50DQoNCihYRU4pIFsgICAxMS4zOTM3
MzJdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDI6MDAuMDogQkFSIGF0IFtmZWEwMCwg
ZmVhMDNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS40MDI4MzFdIGFyY2gv
eDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDI6MDAuMDogQkFSIGF0IFtmZWEwMCwgZmVhMDNdIG5v
dCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS40MTE5MzZdIGFyY2gveDg2L3BjaS5j
OjEwOTpkMHYxIDAwMDA6MDI6MDAuMDogQkFSIGF0IFtmZWEwMCwgZmVhMDNdIG5vdCBpbiBtZW1v
cnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS40MjEwMzVdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYx
IDAwMDA6MDI6MDAuMDogQkFSIGF0IFtmZWEwMCwgZmVhMDNdIG5vdCBpbiBtZW1vcnkgbWFwIGhv
bGUNClsgICAgMS45NjcwNjZdIHBjaSAwMDAwOjAyOjAwLjA6IEJBUiAwIFttZW0gMHhmZWEwMDAw
MC0weGZlYTAzZmZmIDY0Yml0XQ0KDQooWEVOKSBbICAgMTEuNDM2NjMyXSBhcmNoL3g4Ni9wY2ku
YzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVt
b3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNDQ1NzM0XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2
MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBo
b2xlDQooWEVOKSBbICAgMTEuNDU0ODM1XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAy
OjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVO
KSBbICAgMTEuNDYzOTMxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJB
UiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEu
NDczMDMxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVh
MDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNDgyMTM0XSBh
cmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAz
XSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNDkxMjM3XSBhcmNoL3g4Ni9w
Y2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4g
bWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNTAwMzMyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6
ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1h
cCBob2xlDQooWEVOKSBbICAgMTEuNTA5NDM3XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAw
OjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQoo
WEVOKSBbICAgMTEuNTE4NTM0XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6
IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAg
MTEuNTI3NjMxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBb
ZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNTM2NzM3
XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZl
YTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNTQ1ODMyXSBhcmNoL3g4
Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3Qg
aW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNTU0OTM1XSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5
IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNTY0MDMxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAw
MDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xl
DQooWEVOKSBbICAgMTEuNTczMTMyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAw
LjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBb
ICAgMTEuNTgyMjM3XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBh
dCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNTkx
MzM1XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAs
IGZlYTAzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNjAwNDM3XSBhcmNo
L3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBu
b3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNjA5NTMyXSBhcmNoL3g4Ni9wY2ku
YzoxMDk6ZDB2MSAwMDAwOjAyOjAwLjA6IEJBUiBhdCBbZmVhMDAsIGZlYTAzXSBub3QgaW4gbWVt
b3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuNjE5MDcwXSBQQ0kgYWRkIGRldmljZSAwMDAwOjAy
OjAwLjANClsgICAgMi4wNzYwODBdIHBjaSAwMDAwOjAwOjAyLjM6IFBDSSBicmlkZ2UgdG8gW2J1
cyAwMl0NCg0KWyAgICAyLjA4MTE3M10gcGNpIDAwMDA6MDM6MDAuMDogWzEwZWM6ODEyNV0gdHlw
ZSAwMCBjbGFzcyAweDAyMDAwMCBQQ0llIEVuZHBvaW50DQoNCihYRU4pIFsgICAxMS42MzU3MTBd
IGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwgZmU5
MGZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS42NDQ4MTRdIGFyY2gveDg2
L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5vdCBp
biBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS42NTM5MTJdIGFyY2gveDg2L3BjaS5jOjEw
OTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwgZmU5MGZdIG5vdCBpbiBtZW1vcnkg
bWFwIGhvbGUNCihYRU4pIFsgICAxMS42NjMwMTJdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAw
MDA6MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUN
CihYRU4pIFsgICAxMS42NzIxMTRdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAu
MDogQkFSIGF0IFtmZTkwMCwgZmU5MGZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsg
ICAxMS42ODEyMTBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0
IFtmZTkxMCwgZmU5MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS42OTAz
MDldIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwg
ZmU5MGZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS42OTk0MTVdIGFyY2gv
eDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5v
dCBpbiBtZW1vcnkgbWFwIGhvbGUNClsgICAgMi4xMjQwNjddIHBjaSAwMDAwOjAzOjAwLjA6IEJB
UiAwIFtpbyAgMHhmMDAwLTB4ZjBmZl0NCg0KKFhFTikgWyAgIDExLjcxMzc5OV0gYXJjaC94ODYv
cGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTAwLCBmZTkwZl0gbm90IGlu
IG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjcyMjkwMF0gYXJjaC94ODYvcGNpLmM6MTA5
OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTEwLCBmZTkxM10gbm90IGluIG1lbW9yeSBt
YXAgaG9sZQ0KKFhFTikgWyAgIDExLjczMjAwMl0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAw
MDowMzowMC4wOiBCQVIgYXQgW2ZlOTAwLCBmZTkwZl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0K
KFhFTikgWyAgIDExLjc0MTA5OF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4w
OiBCQVIgYXQgW2ZlOTEwLCBmZTkxM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAg
IDExLjc1MDE5N10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQg
W2ZlOTAwLCBmZTkwZl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjc1OTI5
OF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTEwLCBm
ZTkxM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjc2ODQwMF0gYXJjaC94
ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTAwLCBmZTkwZl0gbm90
IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjc3NzQ5N10gYXJjaC94ODYvcGNpLmM6
MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTEwLCBmZTkxM10gbm90IGluIG1lbW9y
eSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjc4NjU5N10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEg
MDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTAwLCBmZTkwZl0gbm90IGluIG1lbW9yeSBtYXAgaG9s
ZQ0KKFhFTikgWyAgIDExLjc5NTY5N10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzow
MC4wOiBCQVIgYXQgW2ZlOTEwLCBmZTkxM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikg
WyAgIDExLjgwNDc5OV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIg
YXQgW2ZlOTAwLCBmZTkwZl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjgx
MzkwMF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTEw
LCBmZTkxM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjgyMjk5N10gYXJj
aC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTAwLCBmZTkwZl0g
bm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjgzMjA5N10gYXJjaC94ODYvcGNp
LmM6MTA5OmQwdjEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTEwLCBmZTkxM10gbm90IGluIG1l
bW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDExLjg0MTIwMl0gYXJjaC94ODYvcGNpLmM6MTA5OmQw
djEgMDAwMDowMzowMC4wOiBCQVIgYXQgW2ZlOTAwLCBmZTkwZl0gbm90IGluIG1lbW9yeSBtYXAg
aG9sZQ0KKFhFTikgWyAgIDExLjg1MDI5N10gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDow
MzowMC4wOiBCQVIgYXQgW2ZlOTEwLCBmZTkxM10gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KWyAg
ICAyLjE5ODA2N10gcGNpIDAwMDA6MDM6MDAuMDogQkFSIDIgW21lbSAweGZlOTAwMDAwLTB4ZmU5
MGZmZmYgNjRiaXRdDQoNCihYRU4pIFsgICAxMS44NjU4OTddIGFyY2gveDg2L3BjaS5jOjEwOTpk
MHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwgZmU5MGZdIG5vdCBpbiBtZW1vcnkgbWFw
IGhvbGUNCihYRU4pIFsgICAxMS44NzQ5OTddIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6
MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihY
RU4pIFsgICAxMS44ODQxMDBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDog
QkFSIGF0IFtmZTkwMCwgZmU5MGZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAx
MS44OTMxOThdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtm
ZTkxMCwgZmU5MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS45MDIzMDNd
IGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwgZmU5
MGZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS45MTEzOThdIGFyY2gveDg2
L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5vdCBp
biBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMS45MjA1MDNdIGFyY2gveDg2L3BjaS5jOjEw
OTpkMHYxIDAwMDA6MDM6MDAuMDogQkFSIGF0IFtmZTkwMCwgZmU5MGZdIG5vdCBpbiBtZW1vcnkg
bWFwIGhvbGUNCihYRU4pIFsgICAxMS45Mjk2MDBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAw
MDA6MDM6MDAuMDogQkFSIGF0IFtmZTkxMCwgZmU5MTNdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUN
ClsgICAgMi4yNDIwNjddIHBjaSAwMDAwOjAzOjAwLjA6IEJBUiA0IFttZW0gMHhmZTkxMDAwMC0w
eGZlOTEzZmZmIDY0Yml0XQ0KDQooWEVOKSBbICAgMTEuOTQ1MjAzXSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MDAsIGZlOTBmXSBub3QgaW4gbWVtb3J5
IG1hcCBob2xlDQooWEVOKSBbICAgMTEuOTU0Mjk4XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAw
MDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MTAsIGZlOTEzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xl
DQooWEVOKSBbICAgMTEuOTYzMzk4XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAw
LjA6IEJBUiBhdCBbZmU5MDAsIGZlOTBmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBb
ICAgMTEuOTcyNTAwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBh
dCBbZmU5MTAsIGZlOTEzXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuOTgx
NjAxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MDAs
IGZlOTBmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuOTkwNzAzXSBhcmNo
L3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MTAsIGZlOTEzXSBu
b3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTEuOTk5ODAyXSBhcmNoL3g4Ni9wY2ku
YzoxMDk6ZDB2MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MDAsIGZlOTBmXSBub3QgaW4gbWVt
b3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMDA4OTAxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2
MSAwMDAwOjAzOjAwLjA6IEJBUiBhdCBbZmU5MTAsIGZlOTEzXSBub3QgaW4gbWVtb3J5IG1hcCBo
b2xlDQpbICAgIDIuMjg1MzA3XSBwY2kgMDAwMDowMzowMC4wOiBzdXBwb3J0cyBEMSBEMg0KDQpb
ICAgIDIuMjkwMDY4XSBwY2kgMDAwMDowMzowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQx
IEQyIEQzaG90IEQzY29sZA0KDQooWEVOKSBbICAgMTIuMDI5NDA4XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjAzOjAwLjANClsgICAgMi4zMDExOTVdIHBjaSAwMDAwOjAwOjAyLjQ6IFBDSSBicmlkZ2Ug
dG8gW2J1cyAwM10NCg0KWyAgICAyLjMwNjE2MV0gcGNpIDAwMDA6MDQ6MDAuMDogWzEwMDI6MTYz
Nl0gdHlwZSAwMCBjbGFzcyAweDAzMDAwMCBQQ0llIExlZ2FjeSBFbmRwb2ludA0KDQooWEVOKSBb
ICAgMTIuMDQ2NjU4XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBh
dCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMDU4
NTA5XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAs
IGZlNzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMDY3NjA3XSBhcmNo
L3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBu
b3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMDc3MTIyXSBhcmNoL3g4Ni9wY2ku
YzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVt
b3J5IG1hcCBob2xlDQpbICAgIDIuMzM2MDY3XSBwY2kgMDAwMDowNDowMC4wOiBCQVIgMCBbbWVt
IDB4ZDAwMDAwMDAtMHhkZmZmZmZmZiA2NGJpdCBwcmVmXQ0KDQooWEVOKSBbICAgMTIuMDkzMTU2
XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZl
NzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMTA0OTgxXSBhcmNoL3g4
Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3Qg
aW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMTE0MDgzXSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5
IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMTIzNTg0XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAw
MDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xl
DQpbICAgIDIuMzY1MDY3XSBwY2kgMDAwMDowNDowMC4wOiBCQVIgMiBbbWVtIDB4ZTAwMDAwMDAt
MHhlMDFmZmZmZiA2NGJpdCBwcmVmXQ0KDQooWEVOKSBbICAgMTIuMTM5NjIzXSBhcmNoL3g4Ni9w
Y2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4g
bWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMTUxNDU0XSBhcmNoL3g4Ni9wY2kuYzoxMDk6
ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5IG1h
cCBob2xlDQooWEVOKSBbICAgMTIuMTYwNTQ5XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAw
OjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQoo
WEVOKSBbICAgMTIuMTcwMDYwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjA6
IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQpbICAgIDIuMzk0
MDY2XSBwY2kgMDAwMDowNDowMC4wOiBCQVIgNCBbaW8gIDB4ZTAwMC0weGUwZmZdDQoNCihYRU4p
IFsgICAxMi4xODQ0NDhdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMDogQkFS
IGF0IFtmZTcwMCwgZmU3N2ZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi4x
OTYyOTNdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMDogQkFSIGF0IFtmZTcw
MCwgZmU3N2ZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi4yMDUzOTVdIGFy
Y2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMDogQkFSIGF0IFtmZTcwMCwgZmU3N2Zd
IG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi4yMTQ5MDRdIGFyY2gveDg2L3Bj
aS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMDogQkFSIGF0IFtmZTcwMCwgZmU3N2ZdIG5vdCBpbiBt
ZW1vcnkgbWFwIGhvbGUNClsgICAgMi40MjEwNjZdIHBjaSAwMDAwOjA0OjAwLjA6IEJBUiA1IFtt
ZW0gMHhmZTcwMDAwMC0weGZlNzdmZmZmXQ0KDQooWEVOKSBbICAgMTIuMjI5OTg3XSBhcmNoL3g4
Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3Qg
aW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMjQxNzk5XSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZDB2MSAwMDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5
IG1hcCBob2xlDQooWEVOKSBbICAgMTIuMjUwOTAyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAw
MDAwOjA0OjAwLjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xl
DQooWEVOKSBbICAgMTIuMjYwNDA5XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA0OjAw
LjA6IEJBUiBhdCBbZmU3MDAsIGZlNzdmXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQpbICAgIDIu
NDQ5MDc2XSBwY2kgMDAwMDowNDowMC4wOiBlbmFibGluZyBFeHRlbmRlZCBUYWdzDQoNClsgICAg
Mi40NTQzMDRdIHBjaSAwMDAwOjA0OjAwLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDEgRDIgRDNo
b3QgRDNjb2xkDQoNClsgICAgMi40NjAxNjNdIHBjaSAwMDAwOjA0OjAwLjA6IDEyNi4wMTYgR2Iv
cyBhdmFpbGFibGUgUENJZSBiYW5kd2lkdGgsIGxpbWl0ZWQgYnkgOC4wIEdUL3MgUENJZSB4MTYg
bGluayBhdCAwMDAwOjAwOjA4LjEgKGNhcGFibGUgb2YgMjUyLjA0OCBHYi9zIHdpdGggMTYuMCBH
VC9zIFBDSWUgeDE2IGxpbmspDQoNCihYRU4pIFsgICAxMi4yOTY2NjZdIFBDSSBhZGQgZGV2aWNl
IDAwMDA6MDQ6MDAuMA0KWyAgICAyLjQ4MDA5OF0gcGNpIDAwMDA6MDQ6MDAuMTogWzEwMDI6MTYz
N10gdHlwZSAwMCBjbGFzcyAweDA0MDMwMCBQQ0llIExlZ2FjeSBFbmRwb2ludA0KDQpbICAgIDIu
NDg4MDg2XSBwY2kgMDAwMDowNDowMC4xOiBCQVIgMCBbbWVtIDB4ZmU3YzgwMDAtMHhmZTdjYmZm
Zl0NCg0KWyAgICAyLjQ5NDEyMl0gcGNpIDAwMDA6MDQ6MDAuMTogZW5hYmxpbmcgRXh0ZW5kZWQg
VGFncw0KDQpbICAgIDIuNDk5MTU0XSBwY2kgMDAwMDowNDowMC4xOiBQTUUjIHN1cHBvcnRlZCBm
cm9tIEQxIEQyIEQzaG90IEQzY29sZA0KDQooWEVOKSBbICAgMTIuMzI2MzA3XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjA0OjAwLjENClsgICAgMi41MDkwOTddIHBjaSAwMDAwOjA0OjAwLjI6IFsxMDIy
OjE1ZGZdIHR5cGUgMDAgY2xhc3MgMHgxMDgwMDAgUENJZSBFbmRwb2ludA0KDQpbICAgIDIuNTE2
MTAxXSBwY2kgMDAwMDowNDowMC4yOiBCQVIgMiBbbWVtIDB4ZmU2MDAwMDAtMHhmZTZmZmZmZl0N
Cg0KWyAgICAyLjUyMjA5MV0gcGNpIDAwMDA6MDQ6MDAuMjogQkFSIDUgW21lbSAweGZlN2NjMDAw
LTB4ZmU3Y2RmZmZdDQoNClsgICAgMi41MjgwODVdIHBjaSAwMDAwOjA0OjAwLjI6IGVuYWJsaW5n
IEV4dGVuZGVkIFRhZ3MNCg0KKFhFTikgWyAgIDEyLjM1NDk3Ml0gUENJIGFkZCBkZXZpY2UgMDAw
MDowNDowMC4yDQpbICAgIDIuNTM4MDk3XSBwY2kgMDAwMDowNDowMC4zOiBbMTAyMjoxNjM5XSB0
eXBlIDAwIGNsYXNzIDB4MGMwMzMwIFBDSWUgRW5kcG9pbnQNCg0KKFhFTikgWyAgIDEyLjM2NjU4
NV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4zOiBCQVIgYXQgW2ZlNTAwLCBm
ZTVmZl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjM3NTY4NF0gYXJjaC94
ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC4zOiBCQVIgYXQgW2ZlNTAwLCBmZTVmZl0gbm90
IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjM4NDc4NV0gYXJjaC94ODYvcGNpLmM6
MTA5OmQwdjEgMDAwMDowNDowMC4zOiBCQVIgYXQgW2ZlNTAwLCBmZTVmZl0gbm90IGluIG1lbW9y
eSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjM5Mzg4NV0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEg
MDAwMDowNDowMC4zOiBCQVIgYXQgW2ZlNTAwLCBmZTVmZl0gbm90IGluIG1lbW9yeSBtYXAgaG9s
ZQ0KWyAgICAyLjU2NDA2N10gcGNpIDAwMDA6MDQ6MDAuMzogQkFSIDAgW21lbSAweGZlNTAwMDAw
LTB4ZmU1ZmZmZmYgNjRiaXRdDQoNCihYRU4pIFsgICAxMi40MDk0ODZdIGFyY2gveDg2L3BjaS5j
OjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1v
cnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi40MTg1ODJdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYx
IDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhv
bGUNCihYRU4pIFsgICAxMi40Mjc2ODZdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6
MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4p
IFsgICAxMi40MzY3ODVdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFS
IGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi40
NDU4ODVdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUw
MCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi40NTQ5ODJdIGFy
Y2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZd
IG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi40NjQwODRdIGFyY2gveDg2L3Bj
aS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBt
ZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi40NzMxODhdIGFyY2gveDg2L3BjaS5jOjEwOTpk
MHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFw
IGhvbGUNCihYRU4pIFsgICAxMi40ODIyODhdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6
MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihY
RU4pIFsgICAxMi40OTEzODZdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzog
QkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAx
Mi41MDA0ODVdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtm
ZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi41MDk1ODRd
IGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1
ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi41MTg2ODhdIGFyY2gveDg2
L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBp
biBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi41Mjc3ODNdIGFyY2gveDg2L3BjaS5jOjEw
OTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkg
bWFwIGhvbGUNCihYRU4pIFsgICAxMi41MzY4ODhdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAw
MDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUN
CihYRU4pIFsgICAxMi41NDU5ODhdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAu
MzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsg
ICAxMi41NTUwODRdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0
IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi41NjQx
ODNdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwg
ZmU1ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi41NzMyODZdIGFyY2gv
eDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5v
dCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi41ODIzODNdIGFyY2gveDg2L3BjaS5j
OjEwOTpkMHYxIDAwMDA6MDQ6MDAuMzogQkFSIGF0IFtmZTUwMCwgZmU1ZmZdIG5vdCBpbiBtZW1v
cnkgbWFwIGhvbGUNClsgICAgMi42NjYwNzZdIHBjaSAwMDAwOjA0OjAwLjM6IGVuYWJsaW5nIEV4
dGVuZGVkIFRhZ3MNCg0KWyAgICAyLjY3MTE2N10gcGNpIDAwMDA6MDQ6MDAuMzogUE1FIyBzdXBw
b3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCg0KKFhFTikgWyAgIDEyLjYwMjY2M10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowNDowMC4zDQpbICAgIDIuNjgyMDk4XSBwY2kgMDAwMDowNDowMC40OiBb
MTAyMjoxNjM5XSB0eXBlIDAwIGNsYXNzIDB4MGMwMzMwIFBDSWUgRW5kcG9pbnQNCg0KKFhFTikg
WyAgIDEyLjYxNDI4MF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC40OiBCQVIg
YXQgW2ZlNDAwLCBmZTRmZl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjYy
MzM4MF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC40OiBCQVIgYXQgW2ZlNDAw
LCBmZTRmZl0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjYzMjQ3Nl0gYXJj
aC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNDowMC40OiBCQVIgYXQgW2ZlNDAwLCBmZTRmZl0g
bm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEyLjY0MTU4MF0gYXJjaC94ODYvcGNp
LmM6MTA5OmQwdjEgMDAwMDowNDowMC40OiBCQVIgYXQgW2ZlNDAwLCBmZTRmZl0gbm90IGluIG1l
bW9yeSBtYXAgaG9sZQ0KWyAgICAyLjcwODA2OF0gcGNpIDAwMDA6MDQ6MDAuNDogQkFSIDAgW21l
bSAweGZlNDAwMDAwLTB4ZmU0ZmZmZmYgNjRiaXRdDQoNCihYRU4pIFsgICAxMi42NTcxNzZdIGFy
Y2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZd
IG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi42NjYyODJdIGFyY2gveDg2L3Bj
aS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBt
ZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi42NzUzNzldIGFyY2gveDg2L3BjaS5jOjEwOTpk
MHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFw
IGhvbGUNCihYRU4pIFsgICAxMi42ODQ0ODBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6
MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihY
RU4pIFsgICAxMi42OTM1NzldIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDog
QkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAx
Mi43MDI2NzddIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtm
ZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi43MTE3Nzld
IGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0
ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi43MjA4ODJdIGFyY2gveDg2
L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBp
biBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi43Mjk5ODBdIGFyY2gveDg2L3BjaS5jOjEw
OTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkg
bWFwIGhvbGUNCihYRU4pIFsgICAxMi43MzkwNzddIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAw
MDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUN
CihYRU4pIFsgICAxMi43NDgxODBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAu
NDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsg
ICAxMi43NTcyNzddIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0
IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi43NjYz
ODNdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwg
ZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi43NzU0ODBdIGFyY2gv
eDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5v
dCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi43ODQ1NzddIGFyY2gveDg2L3BjaS5j
OjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1v
cnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi43OTM2ODBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYx
IDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhv
bGUNCihYRU4pIFsgICAxMi44MDI3ODBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6
MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4p
IFsgICAxMi44MTE4NzddIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFS
IGF0IFtmZTQwMCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi44
MjA5ODFdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQw
MCwgZmU0ZmZdIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4pIFsgICAxMi44MzAwODBdIGFy
Y2gveDg2L3BjaS5jOjEwOTpkMHYxIDAwMDA6MDQ6MDAuNDogQkFSIGF0IFtmZTQwMCwgZmU0ZmZd
IG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNClsgICAgMi44MDgwNzhdIHBjaSAwMDAwOjA0OjAwLjQ6
IGVuYWJsaW5nIEV4dGVuZGVkIFRhZ3MNCg0KWyAgICAyLjgxMzE2Nl0gcGNpIDAwMDA6MDQ6MDAu
NDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCg0KKFhFTikgWyAgIDEyLjg1
MDM2Ml0gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC40DQpbICAgIDIuODI0MDk3XSBwY2kgMDAw
MDowNDowMC41OiBbMTAyMjoxNWUyXSB0eXBlIDAwIGNsYXNzIDB4MDQ4MDAwIFBDSWUgRW5kcG9p
bnQNCg0KWyAgICAyLjgzMDA4Nl0gcGNpIDAwMDA6MDQ6MDAuNTogQkFSIDAgW21lbSAweGZlNzgw
MDAwLTB4ZmU3YmZmZmZdDQoNClsgICAgMi44MzYxMjJdIHBjaSAwMDAwOjA0OjAwLjU6IGVuYWJs
aW5nIEV4dGVuZGVkIFRhZ3MNCg0KWyAgICAyLjg0MTE1Ml0gcGNpIDAwMDA6MDQ6MDAuNTogUE1F
IyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCg0KKFhFTikgWyAgIDEyLjg3OTEzNl0g
UENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC41DQpbICAgIDIuODUxMDk3XSBwY2kgMDAwMDowNDow
MC42OiBbMTAyMjoxNWUzXSB0eXBlIDAwIGNsYXNzIDB4MDQwMzAwIFBDSWUgRW5kcG9pbnQNCg0K
WyAgICAyLjg1OTA4Nl0gcGNpIDAwMDA6MDQ6MDAuNjogQkFSIDAgW21lbSAweGZlN2MwMDAwLTB4
ZmU3YzdmZmZdDQoNClsgICAgMi44NjQxMjZdIHBjaSAwMDAwOjA0OjAwLjY6IGVuYWJsaW5nIEV4
dGVuZGVkIFRhZ3MNCg0KWyAgICAyLjg2OTE1N10gcGNpIDAwMDA6MDQ6MDAuNjogUE1FIyBzdXBw
b3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQNCg0KKFhFTikgWyAgIDEyLjkwNzkwOF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowNDowMC42DQpbICAgIDIuODgwMTMzXSBwY2kgMDAwMDowMDowOC4xOiBQ
Q0kgYnJpZGdlIHRvIFtidXMgMDRdDQoNClsgICAgMi44ODUxNjFdIHBjaSAwMDAwOjA1OjAwLjA6
IFsxMDIyOjc5MDFdIHR5cGUgMDAgY2xhc3MgMHgwMTA2MDEgUENJZSBFbmRwb2ludA0KDQooWEVO
KSBbICAgMTIuOTI0NTUwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJB
UiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIu
OTMzNjQ4XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4
MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuOTQyNzQ4XSBh
cmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAx
XSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuOTUxODUwXSBhcmNoL3g4Ni9w
Y2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4g
bWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuOTYwOTQ4XSBhcmNoL3g4Ni9wY2kuYzoxMDk6
ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1h
cCBob2xlDQooWEVOKSBbICAgMTIuOTcwMDUwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAw
OjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQoo
WEVOKSBbICAgMTIuOTc5MTQ1XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6
IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAg
MTIuOTg4MjUwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBb
ZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTIuOTk3MzUw
XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZl
ODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMDA2NDQ5XSBhcmNoL3g4
Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3Qg
aW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMDE1NTQ1XSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5
IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMDI0NjQ1XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAw
MDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xl
DQooWEVOKSBbICAgMTMuMDMzNzUxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAw
LjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBb
ICAgMTMuMDQyODQ1XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBh
dCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMDUx
OTQ4XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEs
IGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMDYxMDQ3XSBhcmNo
L3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBu
b3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMDcwMTQ4XSBhcmNoL3g4Ni9wY2ku
YzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVt
b3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMDc5MjUxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2
MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBo
b2xlDQooWEVOKSBbICAgMTMuMDg4MzQ3XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1
OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVO
KSBbICAgMTMuMDk3NDQ1XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJB
UiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMu
MTA2NTQ1XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4
MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMTE1NjQ1XSBh
cmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAx
XSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMTI0NzQ4XSBhcmNoL3g4Ni9w
Y2kuYzoxMDk6ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4g
bWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMTMzODQ2XSBhcmNoL3g4Ni9wY2kuYzoxMDk6
ZDB2MSAwMDAwOjA1OjAwLjA6IEJBUiBhdCBbZmU4MDEsIGZlODAxXSBub3QgaW4gbWVtb3J5IG1h
cCBob2xlDQpbICAgIDMuMDA3MDY3XSBwY2kgMDAwMDowNTowMC4wOiBCQVIgNSBbbWVtIDB4ZmU4
MDEwMDAtMHhmZTgwMTdmZl0NCg0KKFhFTikgWyAgIDEzLjE0ODkyNl0gYXJjaC94ODYvcGNpLmM6
MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9y
eSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEzLjE1ODAyOF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEg
MDAwMDowNTowMC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9s
ZQ0KKFhFTikgWyAgIDEzLjE2NzEzMF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTow
MC4wOiBCQVIgYXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikg
WyAgIDEzLjE3NjIyOF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjEgMDAwMDowNTowMC4wOiBCQVIg
YXQgW2ZlODAxLCBmZTgwMV0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KWyAgICAzLjAzMTA3OF0g
cGNpIDAwMDA6MDU6MDAuMDogZW5hYmxpbmcgRXh0ZW5kZWQgVGFncw0KDQpbICAgIDMuMDM3Mzc3
XSBwY2kgMDAwMDowNTowMC4wOiAxMjYuMDE2IEdiL3MgYXZhaWxhYmxlIFBDSWUgYmFuZHdpZHRo
LCBsaW1pdGVkIGJ5IDguMCBHVC9zIFBDSWUgeDE2IGxpbmsgYXQgMDAwMDowMDowOC4yIChjYXBh
YmxlIG9mIDI1Mi4wNDggR2IvcyB3aXRoIDE2LjAgR1QvcyBQQ0llIHgxNiBsaW5rKQ0KDQooWEVO
KSBbICAgMTMuMjA2MzM0XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA1OjAwLjANClsgICAgMy4wNTYw
OTddIHBjaSAwMDAwOjA1OjAwLjE6IFsxMDIyOjc5MDFdIHR5cGUgMDAgY2xhc3MgMHgwMTA2MDEg
UENJZSBFbmRwb2ludA0KDQooWEVOKSBbICAgMTMuMjE3OTUyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6
ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1h
cCBob2xlDQooWEVOKSBbICAgMTMuMjI3MDQ4XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAw
OjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQoo
WEVOKSBbICAgMTMuMjM2MTQ3XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6
IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAg
MTMuMjQ1MjUyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBb
ZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMjU0MzUx
XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZl
ODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMjYzNDUwXSBhcmNoL3g4
Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3Qg
aW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMjcyNTQ5XSBhcmNoL3g4Ni9wY2kuYzox
MDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5
IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMjgxNjUwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAw
MDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xl
DQooWEVOKSBbICAgMTMuMjkwNzUwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAw
LjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBb
ICAgMTMuMjk5ODUxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBh
dCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMzA4
OTUyXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAs
IGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMzE4MDQ3XSBhcmNo
L3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBu
b3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMzI3MTQ4XSBhcmNoL3g4Ni9wY2ku
YzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVt
b3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMzM2MjUwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2
MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBo
b2xlDQooWEVOKSBbICAgMTMuMzQ1MzQ3XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1
OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVO
KSBbICAgMTMuMzU0NDUwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJB
UiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMu
MzYzNTUxXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4
MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMzcyNjUwXSBh
cmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAw
XSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMzgxNzQ4XSBhcmNoL3g4Ni9w
Y2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4g
bWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuMzkwODUwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6
ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1h
cCBob2xlDQooWEVOKSBbICAgMTMuMzk5OTUwXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAw
OjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQoo
WEVOKSBbICAgMTMuNDA5MDQ4XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6
IEJBUiBhdCBbZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAg
MTMuNDE4MTQ4XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBb
ZmU4MDAsIGZlODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBbICAgMTMuNDI3MjQ4
XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA1OjAwLjE6IEJBUiBhdCBbZmU4MDAsIGZl
ODAwXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQpbICAgIDMuMTcxMDY4XSBwY2kgMDAwMDowNTow
MC4xOiBCQVIgNSBbbWVtIDB4ZmU4MDAwMDAtMHhmZTgwMDdmZl0NCg0KKFhFTikgWyAgIDEzLjQ0
MjMyOF0gYXJjaC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAw
LCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEzLjQ1MTQzMV0gYXJj
aC94ODYvcGNpLmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0g
bm90IGluIG1lbW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEzLjQ2MDUzMF0gYXJjaC94ODYvcGNp
LmM6MTA5OmQwdjMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1l
bW9yeSBtYXAgaG9sZQ0KKFhFTikgWyAgIDEzLjQ2OTYzMl0gYXJjaC94ODYvcGNpLmM6MTA5OmQw
djMgMDAwMDowNTowMC4xOiBCQVIgYXQgW2ZlODAwLCBmZTgwMF0gbm90IGluIG1lbW9yeSBtYXAg
aG9sZQ0KWyAgICAzLjE5NTA3N10gcGNpIDAwMDA6MDU6MDAuMTogZW5hYmxpbmcgRXh0ZW5kZWQg
VGFncw0KDQooWEVOKSBbICAgMTMuNDgzODI3XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA1OjAwLjEN
ClsgICAgMy4yMDUxMDhdIHBjaSAwMDAwOjAwOjA4LjI6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNV0N
Cg0KWyAgICAzLjIwOTcwMV0gQUNQSTogUENJOiBJbnRlcnJ1cHQgbGluayBMTktBIGNvbmZpZ3Vy
ZWQgZm9yIElSUSAwDQoNClsgICAgMy4yMTYxMTNdIEFDUEk6IFBDSTogSW50ZXJydXB0IGxpbmsg
TE5LQiBjb25maWd1cmVkIGZvciBJUlEgMA0KDQpbICAgIDMuMjIxMTA2XSBBQ1BJOiBQQ0k6IElu
dGVycnVwdCBsaW5rIExOS0MgY29uZmlndXJlZCBmb3IgSVJRIDANCg0KWyAgICAzLjIyNzExNl0g
QUNQSTogUENJOiBJbnRlcnJ1cHQgbGluayBMTktEIGNvbmZpZ3VyZWQgZm9yIElSUSAwDQoNClsg
ICAgMy4yMzMxMTBdIEFDUEk6IFBDSTogSW50ZXJydXB0IGxpbmsgTE5LRSBjb25maWd1cmVkIGZv
ciBJUlEgMA0KDQpbICAgIDMuMjM5MTAzXSBBQ1BJOiBQQ0k6IEludGVycnVwdCBsaW5rIExOS0Yg
Y29uZmlndXJlZCBmb3IgSVJRIDANCg0KWyAgICAzLjI0NTEwNF0gQUNQSTogUENJOiBJbnRlcnJ1
cHQgbGluayBMTktHIGNvbmZpZ3VyZWQgZm9yIElSUSAwDQoNClsgICAgMy4yNTAxMDRdIEFDUEk6
IFBDSTogSW50ZXJydXB0IGxpbmsgTE5LSCBjb25maWd1cmVkIGZvciBJUlEgMA0KDQpbICAgIDMu
MjU3MDI4XSB4ZW46YmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24gZHJpdmVyDQoNClsgICAg
My4zNDQxMDddIGlvbW11OiBEZWZhdWx0IGRvbWFpbiB0eXBlOiBUcmFuc2xhdGVkDQoNClsgICAg
My4zNDkwNzBdIGlvbW11OiBETUEgZG9tYWluIFRMQiBpbnZhbGlkYXRpb24gcG9saWN5OiBsYXp5
IG1vZGUNCg0KWyAgICAzLjM1NTEyMl0gU0NTSSBzdWJzeXN0ZW0gaW5pdGlhbGl6ZWQNCg0KWyAg
ICAzLjM1OTA4M10gbGliYXRhIHZlcnNpb24gMy4wMCBsb2FkZWQuDQoNClsgICAgMy4zNjIwODFd
IEFDUEk6IGJ1cyB0eXBlIFVTQiByZWdpc3RlcmVkDQoNClsgICAgMy4zNjYwNzZdIHVzYmNvcmU6
IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiZnMNCg0KWyAgICAzLjM3MjA3MV0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBodWINCg0KWyAgICAzLjM3
NzA3Ml0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRyaXZlciB1c2INCg0KWyAgICAz
LjM4MjA3NV0gcHBzX2NvcmU6IExpbnV4UFBTIEFQSSB2ZXIuIDEgcmVnaXN0ZXJlZA0KDQpbICAg
IDMuMzg3MDY4XSBwcHNfY29yZTogU29mdHdhcmUgdmVyLiA1LjMuNiAtIENvcHlyaWdodCAyMDA1
LTIwMDcgUm9kb2xmbyBHaW9tZXR0aSA8Z2lvbWV0dGlAbGludXguaXQ+DQoNClsgICAgMy4zOTYw
NzBdIFBUUCBjbG9jayBzdXBwb3J0IHJlZ2lzdGVyZWQNCg0KWyAgICAzLjQwMDExMV0gZWZpdmFy
czogUmVnaXN0ZXJlZCBlZml2YXJzIG9wZXJhdGlvbnMNCg0KWyAgICAzLjQwNTA4NV0gQWR2YW5j
ZWQgTGludXggU291bmQgQXJjaGl0ZWN0dXJlIERyaXZlciBJbml0aWFsaXplZC4NCg0KWyAgICAz
LjQxMTE2NV0gTmV0TGFiZWw6IEluaXRpYWxpemluZw0KDQpbICAgIDMuNDE0MDY3XSBOZXRMYWJl
bDogIGRvbWFpbiBoYXNoIHNpemUgPSAxMjgNCg0KWyAgICAzLjQxODA2N10gTmV0TGFiZWw6ICBw
cm90b2NvbHMgPSBVTkxBQkVMRUQgQ0lQU092NCBDQUxJUFNPDQoNClsgICAgMy40MjQwNzhdIE5l
dExhYmVsOiAgdW5sYWJlbGVkIHRyYWZmaWMgYWxsb3dlZCBieSBkZWZhdWx0DQoNClsgICAgMy40
MjkwODRdIFBDSTogVXNpbmcgQUNQSSBmb3IgSVJRIHJvdXRpbmcNCg0KWyAgICAzLjQ0MTE5NV0g
UENJOiBwY2lfY2FjaGVfbGluZV9zaXplIHNldCB0byA2NCBieXRlcw0KDQpbICAgIDMuNDQ2MTgz
XSByZXNvdXJjZTogRXhwYW5kZWQgcmVzb3VyY2UgUmVzZXJ2ZWQgZHVlIHRvIGNvbmZsaWN0IHdp
dGggUENJIEJ1cyAwMDAwOjAwDQoNClsgICAgMy40NTQwNjldIHJlc291cmNlOiBFeHBhbmRlZCBy
ZXNvdXJjZSBSZXNlcnZlZCBkdWUgdG8gY29uZmxpY3Qgd2l0aCBQQ0kgQnVzIDAwMDA6MDANCg0K
WyAgICAzLjQ2MjA2OV0gZTgyMDogcmVzZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHgwOWJmZjAwMC0w
eDBiZmZmZmZmXQ0KDQpbICAgIDMuNDY4MDY4XSBlODIwOiByZXNlcnZlIFJBTSBidWZmZXIgW21l
bSAweDBhMjAwMDAwLTB4MGJmZmZmZmZdDQoNClsgICAgMy40NzQwNjhdIGU4MjA6IHJlc2VydmUg
UkFNIGJ1ZmZlciBbbWVtIDB4Y2FiYzkwMDAtMHhjYmZmZmZmZl0NCg0KWyAgICAzLjQ3OTA2OF0g
ZTgyMDogcmVzZXJ2ZSBSQU0gYnVmZmVyIFttZW0gMHhjZGZmZmVhOC0weGNmZmZmZmZmXQ0KDQpb
ICAgIDMuNDg1MDY5XSBlODIwOiByZXNlcnZlIFJBTSBidWZmZXIgW21lbSAweDgwZjM0MDAwMC0w
eDgwZmZmZmZmZl0NCg0KWyAgICAzLjQ5MjA4Ml0gcGNpIDAwMDA6MDQ6MDAuMDogdmdhYXJiOiBz
ZXR0aW5nIGFzIGJvb3QgVkdBIGRldmljZQ0KDQpbICAgIDMuNDkzMDYxXSBwY2kgMDAwMDowNDow
MC4wOiB2Z2FhcmI6IGJyaWRnZSBjb250cm9sIHBvc3NpYmxlDQoNClsgICAgMy40OTMwNjFdIHBj
aSAwMDAwOjA0OjAwLjA6IHZnYWFyYjogVkdBIGRldmljZSBhZGRlZDogZGVjb2Rlcz1pbyttZW0s
b3ducz1ub25lLGxvY2tzPW5vbmUNCg0KWyAgICAzLjUxMTA2OF0gdmdhYXJiOiBsb2FkZWQNCg0K
WyAgICAzLjUxNDE2Ml0gY2xvY2tzb3VyY2U6IFN3aXRjaGVkIHRvIGNsb2Nrc291cmNlIHRzYy1l
YXJseQ0KDQpbICAgIDMuNTE5NTgwXSBWRlM6IERpc2sgcXVvdGFzIGRxdW90XzYuNi4wDQoNClsg
ICAgMy41MjM0NzhdIFZGUzogRHF1b3QtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9y
ZGVyIDAsIDQwOTYgYnl0ZXMpDQoNClsgICAgMy41MzA0NDNdIHBucDogUG5QIEFDUEkgaW5pdA0K
DQpbICAgIDMuNTMzNjA5XSBzeXN0ZW0gMDA6MDA6IFttZW0gMHhmMDAwMDAwMC0weGY3ZmZmZmZm
XSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDMuNTQwMzg2XSBzeXN0ZW0gMDA6MDI6IFtpbyAg
MHgwYTAwLTB4MGEwZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjU0NjIzOV0gc3lzdGVt
IDAwOjAyOiBbaW8gIDB4MGExMC0weDBhMWZdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAgMy41
NTIyMTRdIHN5c3RlbSAwMDowMjogW2lvICAweDBhMjAtMHgwYTJmXSBoYXMgYmVlbiByZXNlcnZl
ZA0KDQpbICAgIDMuNTU4NDEwXSBwbnAgMDA6MDM6IFtkbWEgMCBkaXNhYmxlZF0NCg0KWyAgICAz
LjU2MjQwNV0gcG5wIDAwOjA0OiBbZG1hIDAgZGlzYWJsZWRdDQoNClsgICAgMy41NjYzODZdIHN5
c3RlbSAwMDowNTogW2lvICAweDA0ZDAtMHgwNGQxXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAg
IDMuNTcyMjM1XSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwNDBiXSBoYXMgYmVlbiByZXNlcnZlZA0K
DQpbICAgIDMuNTc3NjAxXSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwNGQ2XSBoYXMgYmVlbiByZXNl
cnZlZA0KDQpbICAgIDMuNTgyOTc3XSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwYzAwLTB4MGMwMV0g
aGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjU4ODk1OF0gc3lzdGVtIDAwOjA1OiBbaW8gIDB4
MGMxNF0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjU5NDMyOV0gc3lzdGVtIDAwOjA1OiBb
aW8gIDB4MGM1MC0weDBjNTFdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAgMy42MDAzMDddIHN5
c3RlbSAwMDowNTogW2lvICAweDBjNTJdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAgMy42MDU2
ODZdIHN5c3RlbSAwMDowNTogW2lvICAweDBjNmNdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAg
My42MTEwNTRdIHN5c3RlbSAwMDowNTogW2lvICAweDBjNmZdIGhhcyBiZWVuIHJlc2VydmVkDQoN
ClsgICAgMy42MTY0MzJdIHN5c3RlbSAwMDowNTogW2lvICAweDBjZDAtMHgwY2QxXSBoYXMgYmVl
biByZXNlcnZlZA0KDQpbICAgIDMuNjIyNDEyXSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwY2QyLTB4
MGNkM10gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjYyODM5M10gc3lzdGVtIDAwOjA1OiBb
aW8gIDB4MGNkNC0weDBjZDVdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAgMy42MzQzNzFdIHN5
c3RlbSAwMDowNTogW2lvICAweDBjZDYtMHgwY2Q3XSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAg
IDMuNjQwMzQ5XSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHgwY2Q4LTB4MGNkZl0gaGFzIGJlZW4gcmVz
ZXJ2ZWQNCg0KWyAgICAzLjY0NjMzMV0gc3lzdGVtIDAwOjA1OiBbaW8gIDB4MDgwMC0weDA4OWZd
IGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAgMy42NTIzMTFdIHN5c3RlbSAwMDowNTogW2lvICAw
eDBiMDAtMHgwYjBmXSBoYXMgYmVlbiByZXNlcnZlZA0KDQpbICAgIDMuNjU4Mjg5XSBzeXN0ZW0g
MDA6MDU6IFtpbyAgMHgwYjIwLTB4MGIzZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNCg0KWyAgICAzLjY2
NDI2OV0gc3lzdGVtIDAwOjA1OiBbaW8gIDB4MDkwMC0weDA5MGZdIGhhcyBiZWVuIHJlc2VydmVk
DQoNClsgICAgMy42NzAyNTNdIHN5c3RlbSAwMDowNTogW2lvICAweDA5MTAtMHgwOTFmXSBoYXMg
YmVlbiByZXNlcnZlZA0KDQpbICAgIDMuNjc2MjI5XSBzeXN0ZW0gMDA6MDU6IFttZW0gMHhmZWMw
MDAwMC0weGZlYzAwZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQNCg0KWyAgICAzLjY4MzI1M10g
c3lzdGVtIDAwOjA1OiBbbWVtIDB4ZmVjMDEwMDAtMHhmZWMwMWZmZl0gY291bGQgbm90IGJlIHJl
c2VydmVkDQoNClsgICAgMy42OTAyNzJdIHN5c3RlbSAwMDowNTogW21lbSAweGZlZGMwMDAwLTB4
ZmVkYzBmZmZdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAgMy42OTY5NDddIHN5c3RlbSAwMDow
NTogW21lbSAweGZlZTAwMDAwLTB4ZmVlMDBmZmZdIGhhcyBiZWVuIHJlc2VydmVkDQoNClsgICAg
My43MDM2MTZdIHN5c3RlbSAwMDowNTogW21lbSAweGZlZDgwMDAwLTB4ZmVkOGZmZmZdIGNvdWxk
IG5vdCBiZSByZXNlcnZlZA0KDQpbICAgIDMuNzEwNjM5XSBzeXN0ZW0gMDA6MDU6IFttZW0gMHhm
ZWMxMDAwMC0weGZlYzEwZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQNCg0KWyAgICAzLjcxNzY1
OF0gc3lzdGVtIDAwOjA1OiBbbWVtIDB4ZmYwMDAwMDAtMHhmZmZmZmZmZl0gaGFzIGJlZW4gcmVz
ZXJ2ZWQNCg0KWyAgICAzLjcyNTAzMl0gcG5wOiBQblAgQUNQSTogZm91bmQgNiBkZXZpY2VzDQoN
ClsgICAgMy43MzcwNjFdIFBNLVRpbWVyIGZhaWxlZCBjb25zaXN0ZW5jeSBjaGVjayAgKDB4ZmZm
ZmZmKSAtIGFib3J0aW5nLg0KDQpbICAgIDMuNzQzNDQyXSBORVQ6IFJlZ2lzdGVyZWQgUEZfSU5F
VCBwcm90b2NvbCBmYW1pbHkNCg0KWyAgICAzLjc0ODQxNF0gSVAgaWRlbnRzIGhhc2ggdGFibGUg
ZW50cmllczogNjU1MzYgKG9yZGVyOiA3LCA1MjQyODggYnl0ZXMsIGxpbmVhcikNCg0KWyAgICAz
Ljc1NjMxNl0gdGNwX2xpc3Rlbl9wb3J0YWRkcl9oYXNoIGhhc2ggdGFibGUgZW50cmllczogMjA0
OCAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzLCBsaW5lYXIpDQoNClsgICAgMy43NjQ3NzJdIFRhYmxl
LXBlcnR1cmIgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDYsIDI2MjE0NCBieXRl
cywgbGluZWFyKQ0KDQpbICAgIDMuNzcyNTY5XSBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBl
bnRyaWVzOiAzMjc2OCAob3JkZXI6IDYsIDI2MjE0NCBieXRlcywgbGluZWFyKQ0KDQpbICAgIDMu
NzgwNTUzXSBUQ1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjogOCwgMTA0
ODU3NiBieXRlcywgbGluZWFyKQ0KDQpbICAgIDMuNzg4MDQ0XSBUQ1A6IEhhc2ggdGFibGVzIGNv
bmZpZ3VyZWQgKGVzdGFibGlzaGVkIDMyNzY4IGJpbmQgMzI3NjgpDQoNClsgICAgMy43OTQ1OTJd
IFVEUCBoYXNoIHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiA0LCA2NTUzNiBieXRlcywgbGlu
ZWFyKQ0KDQpbICAgIDMuODAxMzM3XSBVRFAtTGl0ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDIwNDgg
KG9yZGVyOiA0LCA2NTUzNiBieXRlcywgbGluZWFyKQ0KDQpbICAgIDMuODA4NTQ3XSBORVQ6IFJl
Z2lzdGVyZWQgUEZfVU5JWC9QRl9MT0NBTCBwcm90b2NvbCBmYW1pbHkNCg0KWyAgICAzLjgxNDgx
NF0gUlBDOiBSZWdpc3RlcmVkIG5hbWVkIFVOSVggc29ja2V0IHRyYW5zcG9ydCBtb2R1bGUuDQoN
ClsgICAgMy44MjA2NjBdIFJQQzogUmVnaXN0ZXJlZCB1ZHAgdHJhbnNwb3J0IG1vZHVsZS4NCg0K
WyAgICAzLjgyNTQyNl0gUlBDOiBSZWdpc3RlcmVkIHRjcCB0cmFuc3BvcnQgbW9kdWxlLg0KDQpb
ICAgIDMuODMwMTkyXSBSUEM6IFJlZ2lzdGVyZWQgdGNwLXdpdGgtdGxzIHRyYW5zcG9ydCBtb2R1
bGUuDQoNClsgICAgMy44MzU3MzRdIFJQQzogUmVnaXN0ZXJlZCB0Y3AgTkZTdjQuMSBiYWNrY2hh
bm5lbCB0cmFuc3BvcnQgbW9kdWxlLg0KDQpbICAgIDMuODQyNjM5XSBwY2kgMDAwMDowMDowMi4x
OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDFdDQoNClsgICAgMy44NDc1NDRdIHBjaSAwMDAwOjAwOjAy
LjE6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmZlMDAwMDAwMC0weGZmZjgwZmZmZmYgNjRiaXQg
cHJlZl0NCg0KWyAgICAzLjg1NTY4Nl0gcGNpIDAwMDA6MDA6MDIuMzogUENJIGJyaWRnZSB0byBb
YnVzIDAyXQ0KDQpbICAgIDMuODYwNzA4XSBwY2kgMDAwMDowMDowMi4zOiAgIGJyaWRnZSB3aW5k
b3cgW21lbSAweGZlYTAwMDAwLTB4ZmVhZmZmZmZdDQoNClsgICAgMy44Njc1NTddIHBjaSAwMDAw
OjAwOjAyLjQ6IFBDSSBicmlkZ2UgdG8gW2J1cyAwM10NCg0KWyAgICAzLjg3MjU3OF0gcGNpIDAw
MDA6MDA6MDIuNDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhmMDAwLTB4ZmZmZl0NCg0KWyAgICAz
Ljg3ODczNV0gcGNpIDAwMDA6MDA6MDIuNDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZTkwMDAw
MC0weGZlOWZmZmZmXQ0KDQpbICAgIDMuODg1NTgzXSBwY2kgMDAwMDowMDowOC4xOiBQQ0kgYnJp
ZGdlIHRvIFtidXMgMDRdDQoNClsgICAgMy44OTA2MDFdIHBjaSAwMDAwOjAwOjA4LjE6ICAgYnJp
ZGdlIHdpbmRvdyBbaW8gIDB4ZTAwMC0weGVmZmZdDQoNClsgICAgMy44OTY3NTddIHBjaSAwMDAw
OjAwOjA4LjE6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZmU0MDAwMDAtMHhmZTdmZmZmZl0NCg0K
WyAgICAzLjkwMzYwNV0gcGNpIDAwMDA6MDA6MDguMTogICBicmlkZ2Ugd2luZG93IFttZW0gMHhk
MDAwMDAwMC0weGUwMWZmZmZmIDY0Yml0IHByZWZdDQoNClsgICAgMy45MTE0MDldIHBjaSAwMDAw
OjAwOjA4LjI6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNV0NCg0KWyAgICAzLjkxNjQzN10gcGNpIDAw
MDA6MDA6MDguMjogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmZTgwMDAwMC0weGZlOGZmZmZmXQ0K
DQpbICAgIDMuOTIzMjg2XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDQgW2lvICAweDAwMDAt
MHgwM2FmIHdpbmRvd10NCg0KWyAgICAzLjkyOTUxNl0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJj
ZSA1IFtpbyAgMHgwM2UwLTB4MGNmNyB3aW5kb3ddDQoNClsgICAgMy45MzU3NTJdIHBjaV9idXMg
MDAwMDowMDogcmVzb3VyY2UgNiBbaW8gIDB4MDNiMC0weDAzZGYgd2luZG93XQ0KDQpbICAgIDMu
OTQxOTkzXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDcgW2lvICAweDBkMDAtMHhmZmZmIHdp
bmRvd10NCg0KWyAgICAzLjk0ODIzMl0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA4IFttZW0g
MHgwMDBhMDAwMC0weDAwMGRmZmZmIHdpbmRvd10NCg0KWyAgICAzLjk1NTE3M10gcGNpX2J1cyAw
MDAwOjAwOiByZXNvdXJjZSA5IFttZW0gMHhkMDAwMDAwMC0weGZlYmZmZmZmIHdpbmRvd10NCg0K
WyAgICAzLjk2MjEwM10gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSAxMCBbbWVtIDB4ZmVlMDAw
MDAtMHhmZmZmZmZmZiB3aW5kb3ddDQoNClsgICAgMy45NjkxMjVdIHBjaV9idXMgMDAwMDowMDog
cmVzb3VyY2UgMTEgW21lbSAweDgzMDAwMDAwMC0weGZmZmZmZmZmZmYgd2luZG93XQ0KDQpbICAg
IDMuOTc2NDA1XSBwY2lfYnVzIDAwMDA6MDE6IHJlc291cmNlIDIgW21lbSAweGZmZTAwMDAwMDAt
MHhmZmY4MGZmZmZmIDY0Yml0IHByZWZdDQoNClsgICAgMy45ODQwMjhdIHBjaV9idXMgMDAwMDow
MjogcmVzb3VyY2UgMSBbbWVtIDB4ZmVhMDAwMDAtMHhmZWFmZmZmZl0NCg0KWyAgICAzLjk5MDM2
MF0gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSAwIFtpbyAgMHhmMDAwLTB4ZmZmZl0NCg0KWyAg
ICAzLjk5NTk4OF0gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSAxIFttZW0gMHhmZTkwMDAwMC0w
eGZlOWZmZmZmXQ0KDQpbICAgIDQuMDAyMzE4XSBwY2lfYnVzIDAwMDA6MDQ6IHJlc291cmNlIDAg
W2lvICAweGUwMDAtMHhlZmZmXQ0KDQpbICAgIDQuMDA3OTQ2XSBwY2lfYnVzIDAwMDA6MDQ6IHJl
c291cmNlIDEgW21lbSAweGZlNDAwMDAwLTB4ZmU3ZmZmZmZdDQoNClsgICAgNC4wMTQyNzRdIHBj
aV9idXMgMDAwMDowNDogcmVzb3VyY2UgMiBbbWVtIDB4ZDAwMDAwMDAtMHhlMDFmZmZmZiA2NGJp
dCBwcmVmXQ0KDQpbICAgIDQuMDIxNTU1XSBwY2lfYnVzIDAwMDA6MDU6IHJlc291cmNlIDEgW21l
bSAweGZlODAwMDAwLTB4ZmU4ZmZmZmZdDQoNClsgICAgNC4wMjc5NjddIHBjaSAwMDAwOjAxOjAw
LjA6IENMUyBtaXNtYXRjaCAoNjQgIT0gNDg0KSwgdXNpbmcgNjQgYnl0ZXMNCg0KWyAgICA0LjAz
NDQ4NF0gcGNpIDAwMDA6MDQ6MDAuMTogRDAgcG93ZXIgc3RhdGUgZGVwZW5kcyBvbiAwMDAwOjA0
OjAwLjANCg0KWyAgICA0LjA0MDg4M10gcGNpIDAwMDA6MDQ6MDAuMzogZXh0ZW5kaW5nIGRlbGF5
IGFmdGVyIHBvd2VyLW9uIGZyb20gRDNob3QgdG8gMjAgbXNlYw0KDQpbICAgIDQuMDQ4NjkwXSBw
Y2kgMDAwMDowNDowMC40OiBleHRlbmRpbmcgZGVsYXkgYWZ0ZXIgcG93ZXItb24gZnJvbSBEM2hv
dCB0byAyMCBtc2VjDQoNClsgICAgNC4wNTYyNjJdIFBDSS1ETUE6IFVzaW5nIHNvZnR3YXJlIGJv
dW5jZSBidWZmZXJpbmcgZm9yIElPIChTV0lPVExCKQ0KDQpbICAgIDQuMDU2NjExXSBVbnBhY2tp
bmcgaW5pdHJhbWZzLi4uDQoNClsgICAgNC4wNjI2NzhdIHNvZnR3YXJlIElPIFRMQjogbWFwcGVk
IFttZW0gMHgwMDAwMDAwMGM2YmM5MDAwLTB4MDAwMDAwMDBjYWJjOTAwMF0gKDY0TUIpDQoNClsg
ICAgNC4wNjI2OTldIGNsb2Nrc291cmNlOiB0c2M6IG1hc2s6IDB4ZmZmZmZmZmZmZmZmZmZmZiBt
YXhfY3ljbGVzOiAweDI5YjkyNGM1MjhiLCBtYXhfaWRsZV9uczogNDQwNzk1MzMxNDU0IG5zDQoN
ClsgICAgNC4wODQyNDVdIGNsb2Nrc291cmNlOiBTd2l0Y2hlZCB0byBjbG9ja3NvdXJjZSB0c2MN
Cg0KWyAgICA0LjA5MDU1MV0gSW5pdGlhbGlzZSBzeXN0ZW0gdHJ1c3RlZCBrZXlyaW5ncw0KDQpb
ICAgIDQuMDk1MDY3XSB3b3JraW5nc2V0OiB0aW1lc3RhbXBfYml0cz01NiBtYXhfb3JkZXI9MjAg
YnVja2V0X29yZGVyPTANCg0KWyAgICA0LjEwMTY2NV0gTkZTOiBSZWdpc3RlcmluZyB0aGUgaWRf
cmVzb2x2ZXIga2V5IHR5cGUNCg0KWyAgICA0LjEwNjY2Ml0gS2V5IHR5cGUgaWRfcmVzb2x2ZXIg
cmVnaXN0ZXJlZA0KDQpbICAgIDQuMTEwODkwXSBLZXkgdHlwZSBpZF9sZWdhY3kgcmVnaXN0ZXJl
ZA0KDQpbICAgIDQuMTE1MDQ3XSA5cDogSW5zdGFsbGluZyB2OWZzIDlwMjAwMCBmaWxlIHN5c3Rl
bSBzdXBwb3J0DQoNClsgICAgNC4xMjk1OTldIEtleSB0eXBlIGFzeW1tZXRyaWMgcmVnaXN0ZXJl
ZA0KDQpbICAgIDQuMTMzNjM5XSBBc3ltbWV0cmljIGtleSBwYXJzZXIgJ3g1MDknIHJlZ2lzdGVy
ZWQNCg0KWyAgICA0LjEzNjQ4MF0gRnJlZWluZyBpbml0cmQgbWVtb3J5OiAyMDc4NDRLDQoNClsg
ICAgNC4xMzg1OTJdIEJsb2NrIGxheWVyIFNDU0kgZ2VuZXJpYyAoYnNnKSBkcml2ZXIgdmVyc2lv
biAwLjQgbG9hZGVkIChtYWpvciAyNTApDQoNClsgICAgNC4xNTAxOTRdIGlvIHNjaGVkdWxlciBt
cS1kZWFkbGluZSByZWdpc3RlcmVkDQoNClsgICAgNC4xNTQ3NzldIGlvIHNjaGVkdWxlciBreWJl
ciByZWdpc3RlcmVkDQoNClsgICAgNC4xNTkyODRdIHBjaWVwb3J0IDAwMDA6MDA6MDIuMTogUE1F
OiBTaWduYWxpbmcgd2l0aCBJUlEgNDMNCg0KWyAgICA0LjE2NTI0MV0gcGNpZXBvcnQgMDAwMDow
MDowMi4zOiBQTUU6IFNpZ25hbGluZyB3aXRoIElSUSA0NA0KDQpbICAgIDQuMTcxMTgzXSBwY2ll
cG9ydCAwMDAwOjAwOjAyLjQ6IFBNRTogU2lnbmFsaW5nIHdpdGggSVJRIDQ1DQoNClsgICAgNC4x
NzcxMjVdIHBjaWVwb3J0IDAwMDA6MDA6MDguMTogUE1FOiBTaWduYWxpbmcgd2l0aCBJUlEgNDYN
Cg0KWyAgICA0LjE4MzA3MF0gcGNpZXBvcnQgMDAwMDowMDowOC4yOiBQTUU6IFNpZ25hbGluZyB3
aXRoIElSUSA0Nw0KDQpbICAgIDQuMTg4OTU3XSBpbnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZp
Y2VzL0xOWFNZU1RNOjAwL0xOWFNZQlVTOjAwL1BOUDBDMEM6MDAvaW5wdXQvaW5wdXQwDQoNClsg
ICAgNC4xOTcyNDZdIEFDUEk6IGJ1dHRvbjogUG93ZXIgQnV0dG9uIFtQV1JCXQ0KDQpbICAgIDQu
MjAxNjY1XSBpbnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL0xOWFBX
UkJOOjAwL2lucHV0L2lucHV0MQ0KDQpbICAgIDQuMjA5MTgyXSBBQ1BJOiBidXR0b246IFBvd2Vy
IEJ1dHRvbiBbUFdSRl0NCg0KWyAgICA0LjIxMzU1NF0gQUNQSTogdmlkZW86IFZpZGVvIERldmlj
ZSBbVkdBXSAobXVsdGktaGVhZDogeWVzICByb206IG5vICBwb3N0OiBubykNCg0KWyAgICA0LjIy
MTA1NV0gaW5wdXQ6IFZpZGVvIEJ1cyBhcyAvZGV2aWNlcy9MTlhTWVNUTTowMC9MTlhTWUJVUzow
MC9QTlAwQTA4OjAwL2RldmljZTowZS9MTlhWSURFTzowMC9pbnB1dC9pbnB1dDINCg0KWyAgICA0
LjIzMTE4MV0gW0Zpcm13YXJlIEJ1Z106IEFDUEkgTVdBSVQgQy1zdGF0ZSAweDAgbm90IHN1cHBv
cnRlZCBieSBIVyAoMHgwKQ0KDQpbICAgIDQuMjM4MTcwXSBBQ1BJOiBcX1NCXy5QTFRGLlAwMDA6
IEZvdW5kIDMgaWRsZSBzdGF0ZXMNCg0KWyAgICA0LjI0MzQ4OF0gW0Zpcm13YXJlIEJ1Z106IEFD
UEkgTVdBSVQgQy1zdGF0ZSAweDAgbm90IHN1cHBvcnRlZCBieSBIVyAoMHgwKQ0KDQpbICAgIDQu
MjUwNDc2XSBBQ1BJOiBcX1NCXy5QTFRGLlAwMDE6IEZvdW5kIDMgaWRsZSBzdGF0ZXMNCg0KWyAg
ICA0LjI1NTcyNV0gW0Zpcm13YXJlIEJ1Z106IEFDUEkgTVdBSVQgQy1zdGF0ZSAweDAgbm90IHN1
cHBvcnRlZCBieSBIVyAoMHgwKQ0KDQpbICAgIDQuMjYyNzg3XSBBQ1BJOiBcX1NCXy5QTFRGLlAw
MDI6IEZvdW5kIDMgaWRsZSBzdGF0ZXMNCg0KWyAgICA0LjI2ODI5MV0gdGhlcm1hbCBMTlhUSEVS
TTowMDogcmVnaXN0ZXJlZCBhcyB0aGVybWFsX3pvbmUwDQoNClsgICAgNC4yNzM4ODNdIEFDUEk6
IHRoZXJtYWw6IFRoZXJtYWwgWm9uZSBbVEhSTV0gKDIwIEMpDQoNClsgICAgNC4yNzkwNjldIHRo
ZXJtYWwgTE5YVEhFUk06MDE6IHJlZ2lzdGVyZWQgYXMgdGhlcm1hbF96b25lMQ0KDQpbICAgIDQu
Mjg0NzA5XSBBQ1BJOiB0aGVybWFsOiBUaGVybWFsIFpvbmUgW1dEVEZdICgwIEMpDQoNClsgICAg
NC4yOTAwMjddIHhlbjp4ZW5fZXZ0Y2huOiBFdmVudC1jaGFubmVsIGRldmljZSBpbnN0YWxsZWQN
Cg0KWyAgICA0LjI5NTU3MV0geGVuX21jZWxvZzogRmFpbGVkIHRvIGdldCBDUFUgbnVtYmVycw0K
DQpbICAgIDQuMzAwMjQ5XSB4ZW5fcGNpYmFjazogYmFja2VuZCBpcyB2cGNpDQoNClsgICAgNC4z
MDQzNzldIHhlbl9hY3BpX3Byb2Nlc3NvcjogVXBsb2FkaW5nIFhlbiBwcm9jZXNzb3IgUE0gaW5m
bw0KDQpbICAgIDQuMzExMTUzXSBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCA0IHBvcnRzLCBJ
UlEgc2hhcmluZyBlbmFibGVkDQoNClsgICAgNC4zMTc1MDBdIDAwOjA0OiB0dHlTMSBhdCBJL08g
MHgyZjggKGlycSA9IDMsIGJhc2VfYmF1ZCA9IDExNTIwMCkgaXMgYSAxNjU1MEENCg0KWyAgICA0
LjMyNTA5M10gaHBldF9hY3BpX2FkZDogbm8gYWRkcmVzcyBvciBpcnFzIGluIF9DUlMNCg0KWyAg
ICA0LjMzMDEyN10gTm9uLXZvbGF0aWxlIG1lbW9yeSBkcml2ZXIgdjEuMw0KDQpbICAgIDQuMzM0
MzIwXSBMaW51eCBhZ3BnYXJ0IGludGVyZmFjZSB2MC4xMDMNCg0KWyAgICA0LjMzODkwNV0gQUNQ
STogYnVzIHR5cGUgZHJtX2Nvbm5lY3RvciByZWdpc3RlcmVkDQoNClsgICAgNC4zNDQ5ODhdIGxv
b3A6IG1vZHVsZSBsb2FkZWQNCg0KWyAgICA0LjM0ODQxMV0gYWhjaSAwMDAwOjA1OjAwLjA6IHZl
cnNpb24gMy4wDQoNClsgICAgNC4zNDg1MzFdIG52bWUgbnZtZTA6IHBjaSBmdW5jdGlvbiAwMDAw
OjAyOjAwLjANCg0KWyAgICA0LjM1MjU5N10gYWhjaSAwMDAwOjA1OjAwLjA6IEFIQ0kgdmVycyAw
MDAxLjAzMDEsIDMyIGNvbW1hbmQgc2xvdHMsIDYgR2JwcywgU0FUQSBtb2RlDQoNClsgICAgNC4z
NjUyODJdIGFoY2kgMDAwMDowNTowMC4wOiAxLzEgcG9ydHMgaW1wbGVtZW50ZWQgKHBvcnQgbWFz
ayAweDEpDQoNClsgICAgNC4zNjUyODRdIG52bWUgbnZtZTA6IG1pc3Npbmcgb3IgaW52YWxpZCBT
VUJOUU4gZmllbGQuDQoNClsgICAgNC4zNzE2NzhdIGFoY2kgMDAwMDowNTowMC4wOiBmbGFnczog
NjRiaXQgbmNxIHNudGYgaWxjayBwbSBsZWQgY2xvIG9ubHkgcG1wIGZicyBwaW8gc2x1bSBwYXJ0
DQoNClsgICAgNC4zODU5MTZdIG52bWUgbnZtZTA6IEQzIGVudHJ5IGxhdGVuY3kgc2V0IHRvIDgg
c2Vjb25kcw0KDQpbICAgIDQuMzg2MTkyXSBzY3NpIGhvc3QwOiBhaGNpDQoNClsgICAgNC4zOTQz
MzRdIGF0YTE6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTIwNDhAMHhmZTgwMTAwMCBwb3J0IDB4
ZmU4MDExMDAgaXJxIDUwIGxwbS1wb2wgMw0KDQpbICAgIDQuNDAyNzYyXSBhaGNpIDAwMDA6MDU6
MDAuMTogQUhDSSB2ZXJzIDAwMDEuMDMwMSwgMzIgY29tbWFuZCBzbG90cywgNiBHYnBzLCBTQVRB
IG1vZGUNCg0KWyAgICA0LjQxMDcwNl0gYWhjaSAwMDAwOjA1OjAwLjE6IDEvMSBwb3J0cyBpbXBs
ZW1lbnRlZCAocG9ydCBtYXNrIDB4MSkNCg0KWyAgICA0LjQxNzExMF0gYWhjaSAwMDAwOjA1OjAw
LjE6IGZsYWdzOiA2NGJpdCBuY3Egc250ZiBpbGNrIHBtIGxlZCBjbG8gb25seSBwbXAgZmJzIHBp
byBzbHVtIHBhcnQNCg0KWyAgICA0LjQyNjIzOF0gc2NzaSBob3N0MTogYWhjaQ0KDQpbICAgIDQu
NDI5MDg3XSBhdGEyOiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0yMDQ4QDB4ZmU4MDAwMDAgcG9y
dCAweGZlODAwMTAwIGlycSA1NCBscG0tcG9sIDMNCg0KWyAgICA0LjQzNzY4Ml0gUm91bmRpbmcg
ZG93biBhbGlnbmVkIG1heF9zZWN0b3JzIGZyb20gNDI5NDk2NzI5NSB0byA0Mjk0OTY3Mjg4DQoN
ClsgICAgNC40Mzg1NzddIG52bWUgbnZtZTA6IDQvMC8wIGRlZmF1bHQvcmVhZC9wb2xsIHF1ZXVl
cw0KDQpbICAgIDQuNDQ0NjI5XSBkYl9yb290OiBjYW5ub3Qgb3BlbjogL2V0Yy90YXJnZXQNCg0K
WyAgICA0LjQ1MzAzMF0gIG52bWUwbjE6IHAxIHAyDQoNClsgICAgNC40NTQzMDZdIHR1bjogVW5p
dmVyc2FsIFRVTi9UQVAgZGV2aWNlIGRyaXZlciwgMS42DQoNClsgICAgNC40NjIyNDddIGUxMDA6
IEludGVsKFIpIFBSTy8xMDAgTmV0d29yayBEcml2ZXINCg0KWyAgICA0LjQ2Njk0Ml0gZTEwMDog
Q29weXJpZ2h0KGMpIDE5OTktMjAwNiBJbnRlbCBDb3Jwb3JhdGlvbg0KDQpbICAgIDQuNDcyNTAx
XSBlMTAwMDogSW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBEcml2ZXINCg0KWyAgICA0LjQ3NzQy
NF0gZTEwMDA6IENvcHlyaWdodCAoYykgMTk5OS0yMDA2IEludGVsIENvcnBvcmF0aW9uLg0KDQpb
ICAgIDQuNDgzMjQ0XSBlMTAwMGU6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgRHJpdmVyDQoN
ClsgICAgNC40ODgyNTldIGUxMDAwZTogQ29weXJpZ2h0KGMpIDE5OTkgLSAyMDE1IEludGVsIENv
cnBvcmF0aW9uLg0KDQpbICAgIDQuNDk0MjU1XSBJbnRlbChSKSAyLjVHIEV0aGVybmV0IExpbnV4
IERyaXZlcg0KDQpbICAgIDQuNDk4ODI2XSBDb3B5cmlnaHQoYykgMjAxOCBJbnRlbCBDb3Jwb3Jh
dGlvbi4NCg0KWyAgICA0LjUwMzUyM10gc2t5MjogZHJpdmVyIHZlcnNpb24gMS4zMA0KDQpbICAg
IDQuNTE2NTY1XSBtb2Rwcm9iZSAoNzYpIHVzZWQgZ3JlYXRlc3Qgc3RhY2sgZGVwdGg6IDE0MTg0
IGJ5dGVzIGxlZnQNCg0KWyAgICA0LjUxNzAwMl0gcjgxNjkgMDAwMDowMzowMC4wIGV0aDA6IFJU
TDgxMjVCLCBkYzo5Yzo1MjoyNzphZTpjNCwgWElEIDY0MSwgSVJRIDYwDQoNClsgICAgNC41MzA0
ODldIHI4MTY5IDAwMDA6MDM6MDAuMCBldGgwOiBqdW1ibyBmZWF0dXJlcyBbZnJhbWVzOiA5MTk0
IGJ5dGVzLCB0eCBjaGVja3N1bW1pbmc6IGtvXQ0KDQpbICAgIDQuNTM5MDczXSB4ZW5fbmV0ZnJv
bnQ6IEluaXRpYWxpc2luZyBYZW4gdmlydHVhbCBldGhlcm5ldCBkcml2ZXINCg0KWyAgICA0LjU0
NTQ1Ml0geGhjaV9oY2QgMDAwMDowNDowMC4zOiB4SENJIEhvc3QgQ29udHJvbGxlcg0KDQpbICAg
IDQuNTUwNjYxXSB4aGNpX2hjZCAwMDAwOjA0OjAwLjM6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs
IGFzc2lnbmVkIGJ1cyBudW1iZXIgMQ0KDQpbICAgIDQuNTU4MTUzXSB4aGNpX2hjZCAwMDAwOjA0
OjAwLjM6IGhjYyBwYXJhbXMgMHgwMjY4ZmZlNSBoY2kgdmVyc2lvbiAweDExMCBxdWlya3MgMHgw
MDAwMDIwMDAwMDAwMDEwDQoNClsgICAgNC41Njc1ODFdIHhoY2lfaGNkIDAwMDA6MDQ6MDAuMzog
eEhDSSBIb3N0IENvbnRyb2xsZXINCg0KWyAgICA0LjU3Mjc4Ml0geGhjaV9oY2QgMDAwMDowNDow
MC4zOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDINCg0KWyAg
ICA0LjU4MDE4OV0geGhjaV9oY2QgMDAwMDowNDowMC4zOiBIb3N0IHN1cHBvcnRzIFVTQiAzLjEg
RW5oYW5jZWQgU3VwZXJTcGVlZA0KDQpbICAgIDQuNTg3MzEzXSB1c2IgdXNiMTogTmV3IFVTQiBk
ZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyLCBiY2REZXZpY2U9IDYu
MTENCg0KWyAgICA0LjU5NTYxOF0gdXNiIHVzYjE6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQoNClsgICAgNC42MDI5MDBdIHVzYiB1c2Ix
OiBQcm9kdWN0OiB4SENJIEhvc3QgQ29udHJvbGxlcg0KDQpbICAgIDQuNjA3ODMzXSB1c2IgdXNi
MTogTWFudWZhY3R1cmVyOiBMaW51eCA2LjExLjAgeGhjaS1oY2QNCg0KWyAgICA0LjYxMzI5NV0g
dXNiIHVzYjE6IFNlcmlhbE51bWJlcjogMDAwMDowNDowMC4zDQoNClsgICAgNC42MTgwNjJdIGh1
YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kDQoNClsgICAgNC42MjE4MDBdIGh1YiAxLTA6MS4wOiA0
IHBvcnRzIGRldGVjdGVkDQoNClsgICAgNC42MjU5NzRdIHVzYiB1c2IyOiBXZSBkb24ndCBrbm93
IHRoZSBhbGdvcml0aG1zIGZvciBMUE0gZm9yIHRoaXMgaG9zdCwgZGlzYWJsaW5nIExQTS4NCg0K
WyAgICA0LjYzNDAxNV0gdXNiIHVzYjI6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0x
ZDZiLCBpZFByb2R1Y3Q9MDAwMywgYmNkRGV2aWNlPSA2LjExDQoNClsgICAgNC42NDIzMjZdIHVz
YiB1c2IyOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxO
dW1iZXI9MQ0KDQpbICAgIDQuNjQ5NjA5XSB1c2IgdXNiMjogUHJvZHVjdDogeEhDSSBIb3N0IENv
bnRyb2xsZXINCg0KWyAgICA0LjY1NDU0N10gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGludXgg
Ni4xMS4wIHhoY2ktaGNkDQoNClsgICAgNC42NjAwMTBdIHVzYiB1c2IyOiBTZXJpYWxOdW1iZXI6
IDAwMDA6MDQ6MDAuMw0KDQpbICAgIDQuNjY1MzY2XSBodWIgMi0wOjEuMDogVVNCIGh1YiBmb3Vu
ZA0KDQpbICAgIDQuNjY5MDc2XSBodWIgMi0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZA0KDQpbICAg
IDQuNjczMjg5XSB4aGNpX2hjZCAwMDAwOjA0OjAwLjQ6IHhIQ0kgSG9zdCBDb250cm9sbGVyDQoN
ClsgICAgNC42Nzg0OTldIHhoY2lfaGNkIDAwMDA6MDQ6MDAuNDogbmV3IFVTQiBidXMgcmVnaXN0
ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAzDQoNClsgICAgNC42ODYwMDJdIHhoY2lfaGNkIDAw
MDA6MDQ6MDAuNDogaGNjIHBhcmFtcyAweDAyNjhmZmU1IGhjaSB2ZXJzaW9uIDB4MTEwIHF1aXJr
cyAweDAwMDAwMjAwMDAwMDAwMTANCg0KWyAgICA0LjY5NTM5OF0geGhjaV9oY2QgMDAwMDowNDow
MC40OiB4SENJIEhvc3QgQ29udHJvbGxlcg0KDQpbICAgIDQuNzAwNTkzXSB4aGNpX2hjZCAwMDAw
OjA0OjAwLjQ6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNA0K
DQpbICAgIDQuNzA4MDEzXSB4aGNpX2hjZCAwMDAwOjA0OjAwLjQ6IEhvc3Qgc3VwcG9ydHMgVVNC
IDMuMSBFbmhhbmNlZCBTdXBlclNwZWVkDQoNClsgICAgNC43MTUyNjddIHVzYiB1c2IzOiBOZXcg
VVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDIsIGJjZERldmlj
ZT0gNi4xMQ0KDQpbICAgIDQuNzE5OTgwXSBhdGExOiBTQVRBIGxpbmsgZG93biAoU1N0YXR1cyAw
IFNDb250cm9sIDMwMCkNCg0KWyAgICA0LjcyMzQ2Ml0gdXNiIHVzYjM6IE5ldyBVU0IgZGV2aWNl
IHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQoNClsgICAgNC43MzYy
MDhdIHVzYiB1c2IzOiBQcm9kdWN0OiB4SENJIEhvc3QgQ29udHJvbGxlcg0KDQpbICAgIDQuNzQx
MTI5XSB1c2IgdXNiMzogTWFudWZhY3R1cmVyOiBMaW51eCA2LjExLjAgeGhjaS1oY2QNCg0KWyAg
ICA0Ljc0NjU5NF0gdXNiIHVzYjM6IFNlcmlhbE51bWJlcjogMDAwMDowNDowMC40DQoNClsgICAg
NC43NTE0ODRdIGh1YiAzLTA6MS4wOiBVU0IgaHViIGZvdW5kDQoNClsgICAgNC43NTM5MDldIGF0
YTI6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQ0KDQpbICAgIDQuNzU1
MTg5XSBodWIgMy0wOjEuMDogNCBwb3J0cyBkZXRlY3RlZA0KDQpbICAgIDQuNzY0OTE0XSB1c2Ig
dXNiNDogV2UgZG9uJ3Qga25vdyB0aGUgYWxnb3JpdGhtcyBmb3IgTFBNIGZvciB0aGlzIGhvc3Qs
IGRpc2FibGluZyBMUE0uDQoNClsgICAgNC43NzMwNDhdIHVzYiB1c2I0OiBOZXcgVVNCIGRldmlj
ZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDMsIGJjZERldmljZT0gNi4xMQ0K
DQpbICAgIDQuNzgxMjU1XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMs
IFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENCg0KWyAgICA0Ljc4ODUzMl0gdXNiIHVzYjQ6IFBy
b2R1Y3Q6IHhIQ0kgSG9zdCBDb250cm9sbGVyDQoNClsgICAgNC43OTM0NjldIHVzYiB1c2I0OiBN
YW51ZmFjdHVyZXI6IExpbnV4IDYuMTEuMCB4aGNpLWhjZA0KDQpbICAgIDQuNzk4OTM0XSB1c2Ig
dXNiNDogU2VyaWFsTnVtYmVyOiAwMDAwOjA0OjAwLjQNCg0KWyAgICA0LjgwMzc3Ml0gaHViIDQt
MDoxLjA6IFVTQiBodWIgZm91bmQNCg0KWyAgICA0LjgwNzUxN10gaHViIDQtMDoxLjA6IDIgcG9y
dHMgZGV0ZWN0ZWQNCg0KWyAgICA0LjgxMTY3M10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50
ZXJmYWNlIGRyaXZlciB1c2JscA0KDQpbICAgIDQuODE3MTA4XSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdlDQoNClsgICAgNC44MjMzNDldIGk4MDQy
OiBQTlA6IE5vIFBTLzIgY29udHJvbGxlciBmb3VuZC4NCg0KWyAgICA0LjgyNzk4MV0gaTgwNDI6
IFByb2JpbmcgcG9ydHMgZGlyZWN0bHkuDQoNClsgICAgNC44MzMwMjNdIGk4MDQyOiBObyBjb250
cm9sbGVyIGZvdW5kDQoNClsgICAgNC44Mzc1NjVdIHJ0Y19jbW9zIDAwOjAxOiBSVEMgY2FuIHdh
a2UgZnJvbSBTNA0KDQpbICAgIDQuODQyMjczXSBydGNfY21vcyAwMDowMTogcmVnaXN0ZXJlZCBh
cyBydGMwDQoNClsgICAgNC44NDY3OTRdIHJ0Y19jbW9zIDAwOjAxOiBubyBhbGFybXMsIHkzaywg
MTE0IGJ5dGVzIG52cmFtDQoNClsgICAgNC44NTIzMTJdIGZhaWwgdG8gaW5pdGlhbGl6ZSBwdHBf
a3ZtDQoNClsgICAgNC44NTI3NDJdIHhlbl93ZHQgeGVuX3dkdDogaW5pdGlhbGl6ZWQgKHRpbWVv
dXQ9NjBzLCBub3dheW91dD0wKQ0KDQpbICAgIDQuODYzMTQ3XSBkZXZpY2UtbWFwcGVyOiBpb2N0
bDogNC40OC4wLWlvY3RsICgyMDIzLTAzLTAxKSBpbml0aWFsaXNlZDogZG0tZGV2ZWxAbGlzdHMu
bGludXguZGV2DQoNClsgICAgNC44NzIxMTZdIGFtZF9wc3RhdGU6IFRoZSBDUFBDIGZlYXR1cmUg
aXMgc3VwcG9ydGVkIGJ1dCBjdXJyZW50bHkgZGlzYWJsZWQgYnkgdGhlIEJJT1MuDQoNClsgICAg
NC44NzIxMTZdIFBsZWFzZSBlbmFibGUgaXQgaWYgeW91ciBCSU9TIGhhcyB0aGUgQ1BQQyBvcHRp
b24uDQoNClsgICAgNC44ODYxMjFdIGFtZF9wc3RhdGU6IHRoZSBfQ1BDIG9iamVjdCBpcyBub3Qg
cHJlc2VudCBpbiBTQklPUyBvciBBQ1BJIGRpc2FibGVkDQoNClsgICAgNC44OTM2OTddIGhpZDog
cmF3IEhJRCBldmVudHMgZHJpdmVyIChDKSBKaXJpIEtvc2luYQ0KDQpbICAgIDQuODk4ODQwXSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmhpZA0KDQpbICAgIDQu
OTA0Mzk3XSB1c2JoaWQ6IFVTQiBISUQgY29yZSBkcml2ZXINCg0KWyAgICA0LjkwOTA1M10gc25k
X2hkYV9pbnRlbCAwMDAwOjA0OjAwLjE6IGVuYWJsaW5nIGRldmljZSAoMDAwMCAtPiAwMDAyKQ0K
DQooWEVOKSBbICAgMTUuMjA3Njk5XSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA0OjAw
LjE6IEJBUiBhdCBbZmU3YzgsIGZlN2NiXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQooWEVOKSBb
ICAgMTUuMjE2NzkzXSBhcmNoL3g4Ni9wY2kuYzoxMDk6ZDB2MyAwMDAwOjA0OjAwLjE6IEJBUiBh
dCBbZmU3YzgsIGZlN2NiXSBub3QgaW4gbWVtb3J5IG1hcCBob2xlDQpbICAgIDQuOTMzNzg3XSBz
bmRfaGRhX2ludGVsIDAwMDA6MDQ6MDAuNjogZW5hYmxpbmcgZGV2aWNlICgwMDAwIC0+IDAwMDIp
DQoNCihYRU4pIFsgICAxNS4yMzI0ODBdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYyIDAwMDA6MDQ6
MDAuNjogQkFSIGF0IFtmZTdjMCwgZmU3YzddIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNCihYRU4p
IFsgICAxNS4yNDE1ODNdIGFyY2gveDg2L3BjaS5jOjEwOTpkMHYyIDAwMDA6MDQ6MDAuNjogQkFS
IGF0IFtmZTdjMCwgZmU3YzddIG5vdCBpbiBtZW1vcnkgbWFwIGhvbGUNClsgICAgNC45NTkwODhd
IEluaXRpYWxpemluZyBYRlJNIG5ldGxpbmsgc29ja2V0DQoNClsgICAgNC45NjMzMTBdIE5FVDog
UmVnaXN0ZXJlZCBQRl9JTkVUNiBwcm90b2NvbCBmYW1pbHkNCg0KWyAgICA0Ljk2ODg4MV0gU2Vn
bWVudCBSb3V0aW5nIHdpdGggSVB2Ng0KDQpbICAgIDQuOTY5NTgxXSBzbmRfaGRhX2ludGVsIDAw
MDA6MDQ6MDAuMTogQ2Fubm90IHByb2JlIGNvZGVjcywgZ2l2aW5nIHVwDQoNClsgICAgNC45NzI1
MDJdIEkoWEVOKSBbICAgMTUuMjcyNjM2XSBhcmNoL3g4Ni9odm0vdm1zaS5jOjg0NTpkMHYyIDAw
MDA6MDQ6MDAuMTogUElSUSAzMzEzOiB1bnN1cHBvcnRlZCBhZGRyZXNzIDANCm4tc2l0dSBPQU0g
KElPQU0oWEVOKSBbICAgMTUuMjgyNTEzXSBhcmNoL3g4Ni9odm0vdm1zaS5jOjg0NTpkMHYyIDAw
MDA6MDQ6MDAuMTogUElSUSAzMzEzOiB1bnN1cHBvcnRlZCBhZGRyZXNzIDANCihYRU4pIFsgICAx
NS4yOTEwMTFdIGFyY2gveDg2L2h2bS92bXNpLmM6ODQ1OmQwdjIgMDAwMDowNDowMC4xOiBQSVJR
IDMzMTM6IHVuc3VwcG9ydGVkIGFkZHJlc3MgMA0KKSB3aXRoIElQdjYNCg0KWyAgICA1LjAwODcw
Nl0gc2l0OiBJUHY2LCBJUHY0IGFuZCBNUExTIG92ZXIgSVB2NCB0dW5uZWxpbmcgZHJpdmVyDQoN
ClsgICAgNS4wMTQ3MjZdIE5FVDogUmVnaXN0ZXJlZCBQRl9QQUNLRVQgcHJvdG9jb2wgZmFtaWx5
DQoNClsgICAgNS4wMTk3NjZdIDlwbmV0OiBJbnN0YWxsaW5nIDlQMjAwMCBzdXBwb3J0DQoNClsg
ICAgNS4wMjQwNTFdIHVzYiAzLTQ6IG5ldyBoaWdoLXNwZWVkIFVTQiBkZXZpY2UgbnVtYmVyIDIg
dXNpbmcgeGhjaV9oY2QNCg0KWyAgICA1LjAyNzAwOV0gS2V5IHR5cGUgZG5zX3Jlc29sdmVyIHJl
Z2lzdGVyZWQNCg0KWyAgICA1LjAzNTI3NV0gSVBJIHNob3J0aGFuZCBicm9hZGNhc3Q6IGVuYWJs
ZWQNCg0KWyAgICA1LjA0MTAxMF0gc2NoZWRfY2xvY2s6IE1hcmtpbmcgc3RhYmxlICg0OTU4MDA3
Nzk4LCA4MjkyOTgxOCktPig2MjU0NjI0NDg1LCAtMTIxMzY4Njg2OSkNCg0KWyAgICA1LjA0OTM5
MV0gcmVnaXN0ZXJlZCB0YXNrc3RhdHMgdmVyc2lvbiAxDQoNClsgICAgNS4wNTM0MjJdIExvYWRp
bmcgY29tcGlsZWQtaW4gWC41MDkgY2VydGlmaWNhdGVzDQoNClsgICAgNS4wNTkwNTRdIERlbW90
aW9uIHRhcmdldHMgZm9yIE5vZGUgMDogbnVsbA0KDQpbICAgIDUuMDYzNDQzXSBQTTogICBNYWdp
YyBudW1iZXI6IDk6ODU4OjU2OQ0KDQpbICAgIDUuMDY3NDcxXSBwcmludGs6IGxlZ2FjeSBjb25z
b2xlIFtuZXRjb24wXSBlbmFibGVkDQoNClsgICAgNS4wNzI0NTJdIG5ldGNvbnNvbGU6IG5ldHdv
cmsgbG9nZ2luZyBzdGFydGVkDQoNClsgICAgNS4wNzczNjFdIGNmZzgwMjExOiBMb2FkaW5nIGNv
bXBpbGVkLWluIFguNTA5IGNlcnRpZmljYXRlcyBmb3IgcmVndWxhdG9yeSBkYXRhYmFzZQ0KDQpb
ICAgIDUuMDg1MzIyXSBtb2Rwcm9iZSAoODcpIHVzZWQgZ3JlYXRlc3Qgc3RhY2sgZGVwdGg6IDEz
OTI4IGJ5dGVzIGxlZnQNCg0KWyAgICA1LjA4NjE4MF0gTG9hZGVkIFguNTA5IGNlcnQgJ3Nmb3Jz
aGVlOiAwMGIyOGRkZjQ3YWVmOWNlYTcnDQoNClsgICAgNS4wOTc1MTldIExvYWRlZCBYLjUwOSBj
ZXJ0ICd3ZW5zOiA2MWMwMzg2NTFhYWJkY2Y5NGJkMGFjN2ZmMDZjNzI0OGRiMThjNjAwJw0KDQpb
ICAgIDUuMTA0NzA0XSBBTFNBIGRldmljZSBsaXN0Og0KDQpbICAgIDUuMTA3NzMxXSBwbGF0Zm9y
bSByZWd1bGF0b3J5LjA6IERpcmVjdCBmaXJtd2FyZSBsb2FkIGZvciByZWd1bGF0b3J5LmRiIGZh
aWxlZCB3aXRoIGVycm9yIC0yDQoNClsgICAgNS4xMDg5NDNdICAgTm8gc291bmRjYXJkcyBmb3Vu
ZC4NCg0KWyAgICA1LjExNjM5Ml0gY2ZnODAyMTE6IGZhaWxlZCB0byBsb2FkIHJlZ3VsYXRvcnku
ZGINCg0KWyAgICA1LjEyNTI2N10gRnJlZWluZyB1bnVzZWQga2VybmVsIGltYWdlIChpbml0bWVt
KSBtZW1vcnk6IDI5ODBLDQoNClsgICAgNS4xMzExMzJdIFdyaXRlIHByb3RlY3RpbmcgdGhlIGtl
cm5lbCByZWFkLW9ubHkgZGF0YTogMjg2NzJrDQoNClsgICAgNS4xMzczODRdIEZyZWVpbmcgdW51
c2VkIGtlcm5lbCBpbWFnZSAocm9kYXRhL2RhdGEgZ2FwKSBtZW1vcnk6IDkxNksNCg0KWyAgICA1
LjE3OTQ4Ml0geDg2L21tOiBDaGVja2VkIFcrWCBtYXBwaW5nczogcGFzc2VkLCBubyBXK1ggcGFn
ZXMgZm91bmQuDQoNClsgICAgNS4xODU4ODhdIFJ1biAvYmluL3NoIGFzIGluaXQgcHJvY2Vzcw0K
DQpbICAgIDUuMTg5NzU0XSAgIHdpdGggYXJndW1lbnRzOg0KDQpbICAgIDUuMTkyNzcyXSAgICAg
L2Jpbi9zaA0KDQpbICAgIDUuMTk1MjkxXSAgIHdpdGggZW52aXJvbm1lbnQ6DQoNClsgICAgNS4x
OTg1MDBdICAgICBIT01FPS8NCg0KWyAgICA1LjIwMDkyNF0gICAgIFRFUk09bGludXgNCg0KL2Jp
bi9zaDogWyAgICA1LjIwNDM0NF0gdWNhbid0IGFjY2VzcyB0dHk7IGpvYiBjb250cm9sIHR1cm5l
ZCBvZmZzYiAzLTQ6IE5ldyBVU0INCg0KZGV2aWNlIGZvdW5kLCBpZH4gIyAbWzZuVmVuZG9yPTA0
MDMsIGlkUHJvZHVjdD02MDExLCBiY2REZXZpY2U9IDguMDANCg0KWyAgICA1LjIxNzI1OF0gdXNi
IDMtNDogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTEsIFByb2R1Y3Q9MiwgU2VyaWFsTnVt
YmVyPTMNCg0KWyAgICA1LjIyNDQ0OV0gdXNiIDMtNDogUHJvZHVjdDogVkUyMzAyDQoNClsgICAg
NS4yMjgwODZdIHVzYiAzLTQ6IE1hbnVmYWN0dXJlcjogWGlsaW54DQoNClsgICAgNS4yMzIxNTNd
IHVzYiAzLTQ6IFNlcmlhbE51bWJlcjogNTJIMjUxMTAwMDAxMg0KDQpyb290DQoNCi9iaW4vc2g6
IHJvb3Q6IG5vdCBmb3VuZA0KDQp+ICMgG1s2blsgICA2NS40NDA5OTZdIHNuZF9oZGFfaW50ZWwg
MDAwMDowNDowMC42OiBDYW5ub3QgcHJvYmUgY29kZWNzLCBnaXZpbmcgdXANCg0KKFhFTikgWyAg
IDc1LjczOTc0OV0gYXJjaC94ODYvaHZtL3Ztc2kuYzo4NDU6ZDB2MyAwMDAwOjA0OjAwLjY6IFBJ
UlEgMzMxMjogdW5zdXBwb3J0ZWQgYWRkcmVzcyAwDQooWEVOKSBbICAgNzUuNzQ4MjQ3XSBhcmNo
L3g4Ni9odm0vdm1zaS5jOjg0NTpkMHYzIDAwMDA6MDQ6MDAuNjogUElSUSAzMzEyOiB1bnN1cHBv
cnRlZCBhZGRyZXNzIDANCihYRU4pIFsgICA3NS43NTY3MzldIGFyY2gveDg2L2h2bS92bXNpLmM6
ODQ1OmQwdjMgMDAwMDowNDowMC42OiBQSVJRIDMzMTI6IHVuc3VwcG9ydGVkIGFkZHJlc3MgMA0K
DQoNCn4gIyAbWzZubW91bnQgLXQgcHJvYyBwcm9jIC9wcm9jDQoNCi10IHN5c2ZzIHN5c2ZzIFsg
ICA4MC43MzcwOTddIG0vb3VudCAoOTEpIHVzZWQgZ3NyZWF0ZXN0IHN0YWNrIGRleXB0aDogMTMz
MzYgYnl0ZXNzIGxlZnQNCg0KDQoNCm1vdW50IC10IGRldnRtcGZzIGRldnRtcGZzIC9kZXZ+ICMg
bW91bnQgLXQgc3lzZnMgc3lzZnMgL3N5cw0KDQp+ICMgbW91bnQgLXQgZGV2dG1wZnMgZGV2dG1w
ZnMgL2Rldg0KDQp+ICMgG1s2bmxzIC1sIC9kZXYvbnZtKg0KDQpjcnctLS0tLS0tICAgIDEgcm9v
dCAgICAgcm9vdCAgICAgIDI0OCwgICAwIE1heSAxNiAwNjozNSAbWzE7MzVtL2Rldi9udm1lMBtb
bQ0KDQpicnctLS0tLS0tICAgIDEgcm9vdCAgICAgcm9vdCAgICAgIDI1OSwgICAwIE1heSAxNiAw
NjozNSAbWzE7MzVtL2Rldi9udm1lMG4xG1ttDQoNCmJydy0tLS0tLS0gICAgMSByb290ICAgICBy
b290ICAgICAgMjU5LCAgIDEgTWF5IDE2IDA2OjM1IBtbMTszNW0vZGV2L252bWUwbjFwMRtbbQ0K
DQpicnctLS0tLS0tICAgIDEgcm9vdCAgICAgcm9vdCAgICAgIDI1OSwgICAyIE1heSAxNiAwNjoz
NSAbWzE7MzVtL2Rldi9udm1lMG4xcDIbW20NCg0KfiAjIBtbNm5tb3VudCAvZGV2L252bWUwbjFw
MiAvbW50DQoNClsgIDEwNC43ODcwMjJdIEVYVDQtZnMgKG52bWUwbjFwMik6IHJlY292ZXJ5IGNv
bXBsZXRlDQoNClsgIDEwNC43OTM0OTNdIEVYVDQtZnMgKG52bWUwbjFwMik6IG1vdW50ZWQgZmls
ZXN5c3RlbSAwYjVkYzQwYS0xMzk0LTQyYzgtYTNhMy1kOGU0OWJlZjgwM2Mgci93IHdpdGggb3Jk
ZXJlZCBkYXRhIG1vZGUuIFF1b3RhIG1vZGU6IG5vbmUuDQoNClsgIDEwNC44MDU1NjddIG1+ICMg
G1s2bm91bnQgKDk1KSB1c2VkIGdyZWF0ZXN0IHN0YWNrIGRlcHRoOiAxMzI2NCBieXRlcyBsZWZ0
DQoNCmxzIC9tbnQNCg0KG1sxOzM2bWJpbhtbbSAgICAgICAgIBtbMTszNG1ob21lG1ttICAgICAg
ICAbWzE7MzRtbG9zdCtmb3VuZBtbbSAgG1sxOzM0bXJvb3QbW20gICAgICAgIBtbMDswbXN3YXBm
aWxlG1ttDQoNChtbMTszNG1ib290G1ttICAgICAgICAbWzE7MzZtbGliG1ttICAgICAgICAgG1sx
OzM0bW1lZGlhG1ttICAgICAgIBtbMTszNG1ydW4bW20gICAgICAgICAbWzE7MzRtc3lzG1ttDQoN
ChtbMTszNG1jZHJvbRtbbSAgICAgICAbWzE7MzZtbGliMzIbW20gICAgICAgG1sxOzM0bW1udBtb
bSAgICAgICAgIBtbMTszNm1zYmluG1ttICAgICAgICAbWzE7MzRtdG1wG1ttDQoNChtbMTszNG1k
ZXYbW20gICAgICAgICAbWzE7MzZtbGliNjQbW20gICAgICAgG1sxOzM0bW9wdBtbbSAgICAgICAg
IBtbMTszNG1zbmFwG1ttICAgICAgICAbWzE7MzRtdXNyG1ttDQoNChtbMTszNG1ldGMbW20gICAg
ICAgICAbWzE7MzZtbGlieDMyG1ttICAgICAgG1sxOzM0bXByb2MbW20gICAgICAgIBtbMTszNG1z
cnYbW20gICAgICAgICAbWzE7MzRtdmFyG1ttDQoNCn4gIyAbWzZuDQpUZXJtaW5hdGluZy4uLg0K
VGhhbmtzIGZvciB1c2luZyBwaWNvY29tDQo=

--------------4vcTr0KMHNAmZnYteqWrR3WQ--


From xen-devel-bounces@lists.xenproject.org Fri May 16 01:35:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 01:35:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986096.1371777 (Exim 4.92)
	(envelope-from )
	id 1uFjzI-0005Kw-0y; Fri, 16 May 2025 01:35:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986096.1371777; Fri, 16 May 2025 01:35: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 1uFjzH-0005Kp-Ug; Fri, 16 May 2025 01:35:47 +0000
Received: by outflank-mailman (input) for mailman id 986096;
 Fri, 16 May 2025 01:35:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFjzH-0005KH-Cm
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 01:35:47 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1672aa21-31f6-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 03:35: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" 
X-Inumbo-ID: 1672aa21-31f6-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747359344; x=1747618544;
	bh=YLJPaNABsIwENcDaL+iG2W/DLfM18i/ShIkVvcQ4h/M=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=gZGchZl9IuhowWMyu574K2TtVB3X5YLSHN9xUEk+m492jZwgDnFVNAcopDi4I9KfQ
	 1DB3TfWj4JQx0rEJ6ztEuM8HC/Xk2sieL6GioeQA5WmC+ktsTyRWR+ohVRJnFZFozq
	 p82OQ/qXbFvETRjUauTszsPvgCLA34SYF5MEVh7nvTu1xBR1OglH2rbOqsTNXXREvv
	 WD59YmHv5Yku7N+E3QfXKF4YdCBV8H7eQmPaxyaNmCb4eIzX9zCj8FDo+XBJL7GUaO
	 ibI6miqGCzrKUJkagyMzb3vfnfDbZH6mVBzNWUcIhaEoZ0VQ/KYE78jycUnw9QpEfQ
	 GfIAv0+EgTGUQ==
Date: Fri, 16 May 2025 01:35:40 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v4 2/3] xen/console: introduce console_send()
Message-ID: <20250516013508.1144162-3-dmukhin@ford.com>
In-Reply-To: <20250516013508.1144162-1-dmukhin@ford.com>
References: <20250516013508.1144162-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: c53bf2be734480f0cd9bcc7c89a1b05e62df36cc
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

guest_console_write() duplicates the code from __putstr(), eliminate code
duplication.

Introduce console_send() for sending a message on console devices.

Also, introduce internal console flags to control which console devices
should be used.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v3:
- renamed console_puts() to console_send()
---
 xen/drivers/char/console.c | 131 +++++++++++++++++++++++--------------
 1 file changed, 82 insertions(+), 49 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index b4757844e6..3420e9630a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -41,6 +41,28 @@
 #include 
 #endif
=20
+/* Internal console flags. */
+enum {
+    CONSOLE_SERIAL          =3D BIT(0, U),    /* Use serial device. */
+    CONSOLE_PV              =3D BIT(1, U),    /* Use PV console. */
+    CONSOLE_VIDEO           =3D BIT(2, U),    /* Use video device. */
+    CONSOLE_DEBUG           =3D BIT(3, U),    /* Use debug device. */
+    CONSOLE_RING            =3D BIT(4, U),    /* Use console ring. */
+    CONSOLE_RING_VIRQ       =3D BIT(5, U),    /* Use console ring VIRQ. */
+
+    /* Default console flags. */
+    CONSOLE_DEFAULT         =3D CONSOLE_SERIAL |
+                              CONSOLE_PV |
+                              CONSOLE_VIDEO |
+                              CONSOLE_RING_VIRQ |
+                              CONSOLE_DEBUG,
+
+    /* Use all known console devices. */
+    CONSOLE_ALL             =3D CONSOLE_DEFAULT | CONSOLE_RING,
+};
+
+static void console_send(const char *str, size_t len, unsigned int flags);
+
 /* console: comma-separated list of console outputs. */
 static char __initdata opt_console[30] =3D OPT_CONSOLE_STR;
 string_param("console", opt_console);
@@ -428,9 +450,6 @@ void console_serial_puts(const char *s, size_t nr)
         serial_steal_fn(s, nr);
     else
         serial_puts(sercon_handle, s, nr);
-
-    /* Copy all serial output into PV console */
-    pv_console_puts(s, nr);
 }
=20
 static void cf_check dump_console_ring_key(unsigned char key)
@@ -464,8 +483,7 @@ static void cf_check dump_console_ring_key(unsigned cha=
r key)
         c +=3D len;
     }
=20
-    console_serial_puts(buf, sofar);
-    video_puts(buf, sofar);
+    console_send(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
=20
     free_xenheap_pages(buf, order);
 }
@@ -614,11 +632,69 @@ static inline void xen_console_write_debug_port(const=
 char *buf, size_t len)
 }
 #endif
=20
+static inline void console_debug_puts(const char *str, size_t len)
+{
+#ifdef CONFIG_X86
+    if ( opt_console_xen )
+    {
+        if ( xen_guest )
+            xen_hypercall_console_write(str, len);
+        else
+            xen_console_write_debug_port(str, len);
+    }
+#endif
+}
+
+/*
+ * Send a message on console device(s).
+ *
+ * That will handle all possible scenarios working w/ console
+ * - physical console (serial console, VGA console (x86 only));
+ * - PV console;
+ * - debug console (x86 only): debug I/O port or __HYPERVISOR_console_io
+ *   hypercall;
+ * - console ring.
+ */
+static void console_send(const char *str, size_t len, unsigned int flags)
+{
+    if ( flags & CONSOLE_SERIAL )
+        console_serial_puts(str, len);
+
+    if ( flags & CONSOLE_PV )
+        pv_console_puts(str, len);
+
+    if ( flags & CONSOLE_VIDEO )
+        video_puts(str, len);
+
+    if ( flags & CONSOLE_DEBUG )
+        console_debug_puts(str, len);
+
+    if ( flags & CONSOLE_RING )
+        conring_puts(str, len);
+
+    if ( flags & CONSOLE_RING_VIRQ )
+        tasklet_schedule(&conring_tasklet);
+}
+
+static inline void __putstr(const char *str)
+{
+    unsigned int flags =3D CONSOLE_ALL;
+
+    ASSERT(rspin_is_locked(&console_lock));
+
+    if ( conring_no_notify )
+        flags &=3D ~CONSOLE_RING_VIRQ;
+
+    console_send(str, strlen(str), flags);
+}
+
 static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
                                 unsigned int count)
 {
     char kbuf[128];
     unsigned int kcount =3D 0;
+    unsigned int flags =3D opt_console_to_ring
+                         ? CONSOLE_ALL : CONSOLE_DEFAULT;
     struct domain *cd =3D current->domain;
=20
     while ( count > 0 )
@@ -636,26 +712,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM=
(char) buffer,
         {
             /* Use direct console output as it could be interactive */
             nrspin_lock_irq(&console_lock);
-
-            console_serial_puts(kbuf, kcount);
-            video_puts(kbuf, kcount);
-
-#ifdef CONFIG_X86
-            if ( opt_console_xen )
-            {
-                if ( xen_guest )
-                    xen_hypercall_console_write(kbuf, kcount);
-                else
-                    xen_console_write_debug_port(kbuf, kcount);
-            }
-#endif
-
-            if ( opt_console_to_ring )
-            {
-                conring_puts(kbuf, kcount);
-                tasklet_schedule(&conring_tasklet);
-            }
-
+            console_send(kbuf, kcount, flags);
             nrspin_unlock_irq(&console_lock);
         }
         else
@@ -756,30 +813,6 @@ long do_console_io(
  * *****************************************************
  */
=20
-static void __putstr(const char *str)
-{
-    size_t len =3D strlen(str);
-
-    ASSERT(rspin_is_locked(&console_lock));
-
-    console_serial_puts(str, len);
-    video_puts(str, len);
-
-#ifdef CONFIG_X86
-    if ( opt_console_xen )
-    {
-        if ( xen_guest )
-            xen_hypercall_console_write(str, len);
-        else
-            xen_console_write_debug_port(str, len);
-    }
-#endif
-
-    conring_puts(str, len);
-    if ( !conring_no_notify )
-        tasklet_schedule(&conring_tasklet);
-}
-
 static int printk_prefix_check(char *p, char **pp)
 {
     int loglvl =3D -1;
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 16 01:35:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 01:35:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986094.1371757 (Exim 4.92)
	(envelope-from )
	id 1uFjz9-0004r7-KV; Fri, 16 May 2025 01:35:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986094.1371757; Fri, 16 May 2025 01: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 1uFjz9-0004r0-GR; Fri, 16 May 2025 01:35:39 +0000
Received: by outflank-mailman (input) for mailman id 986094;
 Fri, 16 May 2025 01:35:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFjz6-0004qs-UN
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 01:35:38 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0d9130f1-31f6-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 03:35: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" 
X-Inumbo-ID: 0d9130f1-31f6-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747359329; x=1747618529;
	bh=Rkth2alHQQ+ODaS2FsPGzdQJwFsYzELi5LADKzDkptw=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=J5UOez6+TXaqRdrBqTGIfOcVjRroKAlbyS+iRbTW80rhzaeNMvKDn4N+Ioy8G/3nv
	 xetkaU4rgWgvVLt+5MsgYi6zAVBX4TE27qNnP5i1hVR6N+VtSSqS0A/4dlw4i825ZB
	 w7eENduIGfPv1macli1mgLRYva/gkySajF99eKqTej1apz0bKBLGOHFaT+Q/sy7A5G
	 7KbxNExWc+XR5AfZcrZ1vFFEzuVfyH1CtdI+xJVBQGS9+o5IjQ0Wb9WkEkOxtpKnJ8
	 nCSL1miUaXC+yeUs3f/FquaBZvB1WJ3OTsxHQxk+IIyY4PiQPf/pYQhzx5FtHsOE3G
	 4Rdpc+f08/mWA==
Date: Fri, 16 May 2025 01:35:24 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v4 0/3] xen/console: few cleanups in console driver
Message-ID: <20250516013508.1144162-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 6fb10cea83077c4d5f3113336f242a8034a394ea
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The patch series introduces a few cleanups aimed at reducing code duplicati=
on
in the console driver and improving readability.

Originally, patches 2 and 3 were part of NS16550 emulator v3 series [1].

Patch 1 performs a cleanup in conring console.

Patch 2 (see [2]) removes code duplication between __putstr() and the rest =
of
the driver. It also introduces private flags to select console devices for
printout which simplifies some code paths.

Patch 3 (see [3]) adds conring_flush() to send contents of conring to all
currently available console devices.

[1] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b3=
1d66c@ford.com/
[2] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-16-c5d36b=
31d66c@ford.com/
[3] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-17-c5d36b=
31d66c@ford.com/
[4] Link to v3: https://lore.kernel.org/xen-devel/20250504181423.2302345-1-=
dmukhin@ford.com/
[5] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1820247737

Denis Mukhin (3):
  xen/console: cleanup conring management
  xen/console: introduce console_send()
  xen/console: introduce conring_flush()

 xen/drivers/char/console.c | 184 +++++++++++++++++++++++--------------
 1 file changed, 114 insertions(+), 70 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 16 01:35:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 01:35:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986095.1371767 (Exim 4.92)
	(envelope-from )
	id 1uFjzB-00054g-QX; Fri, 16 May 2025 01:35:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986095.1371767; Fri, 16 May 2025 01:35: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 1uFjzB-00054Z-Mg; Fri, 16 May 2025 01:35:41 +0000
Received: by outflank-mailman (input) for mailman id 986095;
 Fri, 16 May 2025 01:35:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFjzA-0004qs-A0
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 01:35:40 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 123205fe-31f6-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 03: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" 
X-Inumbo-ID: 123205fe-31f6-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747359337; x=1747618537;
	bh=588O4GM8EEzhJrMlBVlwjFWXPjQseR1Cqietx9RCUyg=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=BWfjOXeca2km+7qA2auql6I/fwAPuL6GwuCPeNHUdFpodKYrPPIVsVF8xmkKjFyrE
	 9DMJF/PHz4J7fOZj1nYpLuInhJ2iI8DB84h1pwlAfbuore4tYZgInACu8GYdL/d4Xi
	 HW+Ck0lSYT6CZYrONOzzDxyfDfnNzuCnUnrlAg68uqCWTHnvt0SCPNdBLS4ELPIT+x
	 lm8cKU9LRwbL8vsTqGNL8dP5qcLxb3cAAa6VSy8ghTpyJuKTbTU8o2jqfqWJKZfRJq
	 5Y+pbO9OVgUBLDAS6ELsk+MZPPnT0O+x53SkyTLzvkIO+x3yP/Fty7lVJ3AHc31wOO
	 +zUlq6m8A4fYQ==
Date: Fri, 16 May 2025 01:35:31 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v4 1/3] xen/console: cleanup conring management
Message-ID: <20250516013508.1144162-2-dmukhin@ford.com>
In-Reply-To: <20250516013508.1144162-1-dmukhin@ford.com>
References: <20250516013508.1144162-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 89c55eeaebf7879c275c6691463f530a174a1ed8
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Move conring tasklet code close to conring definitions in the console drive=
r
and rename conring tasklet variables by adding conring_ prefix for better
readability.

No functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v3:
- dropped 3rd argument from conring_puts()
---
 xen/drivers/char/console.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c3150fbdb7..b4757844e6 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -325,6 +325,16 @@ static void cf_check do_dec_thresh(unsigned char key, =
bool unused)
  * ********************************************************
  */
=20
+static void cf_check conring_notify(void *unused)
+{
+    send_global_virq(VIRQ_CON_RING);
+}
+
+static DECLARE_SOFTIRQ_TASKLET(conring_tasklet, conring_notify, NULL);
+
+/* NB: Do not send conring VIRQs during panic. */
+static bool conring_no_notify;
+
 static void conring_puts(const char *str, size_t len)
 {
     ASSERT(rspin_is_locked(&console_lock));
@@ -594,13 +604,6 @@ static void cf_check serial_rx(char c)
     __serial_rx(c);
 }
=20
-static void cf_check notify_dom0_con_ring(void *unused)
-{
-    send_global_virq(VIRQ_CON_RING);
-}
-static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
-                               notify_dom0_con_ring, NULL);
-
 #ifdef CONFIG_X86
 static inline void xen_console_write_debug_port(const char *buf, size_t le=
n)
 {
@@ -650,7 +653,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(=
char) buffer,
             if ( opt_console_to_ring )
             {
                 conring_puts(kbuf, kcount);
-                tasklet_schedule(¬ify_dom0_con_ring_tasklet);
+                tasklet_schedule(&conring_tasklet);
             }
=20
             nrspin_unlock_irq(&console_lock);
@@ -753,8 +756,6 @@ long do_console_io(
  * *****************************************************
  */
=20
-static bool console_locks_busted;
-
 static void __putstr(const char *str)
 {
     size_t len =3D strlen(str);
@@ -775,9 +776,8 @@ static void __putstr(const char *str)
 #endif
=20
     conring_puts(str, len);
-
-    if ( !console_locks_busted )
-        tasklet_schedule(¬ify_dom0_con_ring_tasklet);
+    if ( !conring_no_notify )
+        tasklet_schedule(&conring_tasklet);
 }
=20
 static int printk_prefix_check(char *p, char **pp)
@@ -1171,7 +1171,7 @@ void console_force_unlock(void)
     spin_debug_disable();
     rspin_lock_init(&console_lock);
     serial_force_unlock(sercon_handle);
-    console_locks_busted =3D 1;
+    conring_no_notify =3D true;
     console_start_sync();
 }
=20
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 16 01:35:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 01:35:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986098.1371788 (Exim 4.92)
	(envelope-from )
	id 1uFjzT-0005pE-AO; Fri, 16 May 2025 01:35:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986098.1371788; Fri, 16 May 2025 01:35: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 1uFjzT-0005ou-5s; Fri, 16 May 2025 01:35:59 +0000
Received: by outflank-mailman (input) for mailman id 986098;
 Fri, 16 May 2025 01:35:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFjzS-0004qs-5b
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 01:35:58 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1ce2e1bb-31f6-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 03:35: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" 
X-Inumbo-ID: 1ce2e1bb-31f6-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=pssu35x7p5ei7ltfjlh3oyl46y.protonmail; t=1747359355; x=1747618555;
	bh=v1HpdEG9MwONSRwSXD9E5J2+52J+MPn8gkPntIhkjwQ=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=PBYDAOznvDuTZz4SSTmfUdkVL/E0P1cZQXE/0vlwK4C9bb1H9A28onnL4W8pIoFiH
	 u3N1USZ6/cWiv6OI2Uq7Bi+8HwVupnWvO/o/bjFfjf2wwgdqtUgJ5lvl0JlRdTt01e
	 KZRotpf2/apGAh1uHdA3jNdbPxPOBAxdeO5dCZdzCHSF9ZgA4n0rNrBwVPCuoJIS6W
	 9eMQXAuFrlKyoXRcSZ+GB3AcrY+urTQY7IJ8MUyTUUi4K4QvShNRLx/Ag5Mv/5oI15
	 35pFOfQZouvKixOj+wU/ACNUCRV6YpLso4pt9qy6V0GayCF1B4+y8tLKijmJErO7qF
	 FJIY2fXykC9fA==
Date: Fri, 16 May 2025 01:35:49 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v4 3/3] xen/console: introduce conring_flush()
Message-ID: <20250516013508.1144162-4-dmukhin@ford.com>
In-Reply-To: <20250516013508.1144162-1-dmukhin@ford.com>
References: <20250516013508.1144162-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: ea23409224c8193f8ec1cd1eb166cd5e784b9da8
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Introduce conring_flush() to ensure all messages kept in the internal
console ring are sent to all physical consoles (serial, VGA (x86))
after their initialization is completed.

Rename dump_console_ring_key to conring_dump_keyhandler to match the
notation for conring management symbols.

Resolves: https://gitlab.com/xen-project/xen/-/issues/184
Signed-off-by: Denis Mukhin 
Reviewed-by: Stefano Stabellini 
---
Changes since v3:
- rebased, kept R-b
---
 xen/drivers/char/console.c | 31 +++++++++++++++++++++----------
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 3420e9630a..a3b59a7ffc 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -452,23 +452,19 @@ void console_serial_puts(const char *s, size_t nr)
         serial_puts(sercon_handle, s, nr);
 }
=20
-static void cf_check dump_console_ring_key(unsigned char key)
+/*
+ * Flush contents of the conring to the physical console devices.
+ */
+static int conring_flush(void)
 {
     uint32_t idx, len, sofar, c;
     unsigned int order;
     char *buf;
=20
-    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
-
-    /* create a buffer in which we'll copy the ring in the correct
-       order and NUL terminate */
     order =3D get_order_from_bytes(conring_size + 1);
     buf =3D alloc_xenheap_pages(order, 0);
     if ( buf =3D=3D NULL )
-    {
-        printk("unable to allocate memory!\n");
-        return;
-    }
+        return -ENOMEM;
=20
     c =3D conringc;
     sofar =3D 0;
@@ -486,6 +482,18 @@ static void cf_check dump_console_ring_key(unsigned ch=
ar key)
     console_send(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
=20
     free_xenheap_pages(buf, order);
+
+    return 0;
+}
+
+static void cf_check conring_dump_keyhandler(unsigned char key)
+{
+    int rc;
+
+    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
+    rc =3D conring_flush();
+    if ( rc )
+        printk("failed to dump console ring buffer: %d\n", rc);
 }
=20
 /*
@@ -1058,6 +1066,9 @@ void __init console_init_preirq(void)
     serial_set_rx_handler(sercon_handle, serial_rx);
     pv_console_set_rx_handler(serial_rx);
=20
+    /* NB: send conring contents to all enabled physical consoles, if any =
*/
+    conring_flush();
+
     /* HELLO WORLD --- start-of-day banner text. */
     nrspin_lock(&console_lock);
     __putstr(xen_banner());
@@ -1148,7 +1159,7 @@ void __init console_endboot(void)
     if ( opt_conswitch[1] =3D=3D 'x' )
         console_rx =3D max_console_rx;
=20
-    register_keyhandler('w', dump_console_ring_key,
+    register_keyhandler('w', conring_dump_keyhandler,
                         "synchronously dump console ring buffer (dmesg)", =
0);
     register_irq_keyhandler('+', &do_inc_thresh,
                             "increase log level threshold", 0);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 16 02:00:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 02:00:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986028.1371797 (Exim 4.92)
	(envelope-from )
	id 1uFkN6-00020g-3h; Fri, 16 May 2025 02:00:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986028.1371797; Fri, 16 May 2025 02: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 1uFkN6-00020Z-0n; Fri, 16 May 2025 02:00:24 +0000
Received: by outflank-mailman (input) for mailman id 986028;
 Thu, 15 May 2025 23:03:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFhbn-0004tS-0I
 for xen-devel@lists.xenproject.org; Thu, 15 May 2025 23:03:23 +0000
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de
 [85.215.255.25]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ca6c2fcd-31e0-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 01:03:19 +0200 (CEST)
Received: from dmzmail.linux.bogus by smtp.strato.de (RZmta 51.3.0 DYNA|AUTH)
 with ESMTPSA id 6293ac14FN3IBrs
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
 (Client did not present a certificate)
 for ;
 Fri, 16 May 2025 01:03:18 +0200 (CEST)
Received: from [192.168.5.100] (p5081988a.dip0.t-ipconnect.de [80.129.152.138])
 (authenticated bits=0)
 by dmzmail.linux.bogus (8.17.1.9/8.17.1.9/Debian-2+deb12u2) with ESMTPSA id
 54FN38kG191780
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT);
 Fri, 16 May 2025 01:03:16 +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" 
X-Inumbo-ID: ca6c2fcd-31e0-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747350198; cv=none;
    d=strato.com; s=strato-dkim-0002;
    b=gnqLKZjo2+SI0J0JvgVGZmS2e/6SYoOPVlF/UAa4tV++feygAUrI6XL5XSMxcr5rze
    iUZ0RvLoZGVTd9zrh2kZGhCQLMAKexaSOIb2xis1bel+/9RORUjFT6UQYYvuK7jnH5z0
    KYMwwVtvIqnO8ydRtPRb+2ztU4wxTMKa3ZDE/Cs2v/Uo8aI+aCm4G56pY7NAQ8KPwb87
    Aht+eVenV5lqOuJR1jF6CMvQiW/DytybsCi3ICv4TUqOVonJkkgw70u0yopzV6h1f3au
    RyAsSLqbIoVuB9wOqGexsRugab9cTFnMZg85z/3YVafycaecMPSgpPwt5Ze6LPhu63QJ
    dP4A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1747350198;
    s=strato-dkim-0002; d=strato.com;
    h=Cc:To:Subject:From:Reply-To:Date:Message-ID:Cc:Date:From:Subject:
    Sender;
    bh=0FXnIEHjYxqW8hyrXxxMV/ZdkaLrnI8X5H5zMmAGqPU=;
    b=h2Ansqa+IKAczNyDnMh6ivC2ZqZj6NA6bCD1zl3jH6J1WtcRfaAgQCWCV8L/tmQytj
    eFaGB9QBgJec34c0g+BrbkpKmRJQN4z3gpStl21waycyLuqabpxVxmg2gFjC672gxMIk
    rMk4OWc76QbhUKSRDkXj0YTDzd1rC257YEnbgENhyp+fwvjaRH9jFeLOVo6qzPv9nNbo
    JPpkRtpj7qFWk63KLEnskUNxA98LKMRRSf7F9MpYjypzB4blLmUNApXtwkJEl9JV58HR
    10hCe5ONxnoXaiRmcXlMuaA9LOLoyycPswZAEUD5vaSTG9m/lf32mnfCuhyNdyHv6JgM
    mBxw==
ARC-Authentication-Results: i=1; strato.com;
    arc=none;
    dkim=none
X-RZG-CLASS-ID: mo00
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1747350198;
    s=strato-dkim-0002; d=a-greve.de;
    h=Cc:To:Subject:From:Reply-To:Date:Message-ID:Cc:Date:From:Subject:
    Sender;
    bh=0FXnIEHjYxqW8hyrXxxMV/ZdkaLrnI8X5H5zMmAGqPU=;
    b=ro0/zogdUaDWT/EE7/UhWaYIIrmC4iQcBoUkq/3ccRsBPkgLxIBWZlVmORgUb5q5JZ
    YqysZRGc4CL376U3lu3DTLy2rcrHQJleYKK0Flb/dgTm5ve0nxREP6JkBSTIqExmDAC8
    cYFkrft9dlcGseFRSB2IniL1IXrC8anaos4MYVsyrUsHNBWfTofU7JbjC+9UAYSG8aOO
    o1Lm2EA8ODRi76TQ96bGzRtTnFZ1EmYONCigMUULRr44vNbV8q3pKCp50UuZlz2IWDbD
    SMZRyTmLtlENFb+Srdje90ltUtRBQVaqwjXcBCmpkqoLOuUJm8jozaZvavGzsoPluZDF
    JGbg==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1747350198;
    s=strato-dkim-0003; d=a-greve.de;
    h=Cc:To:Subject:From:Reply-To:Date:Message-ID:Cc:Date:From:Subject:
    Sender;
    bh=0FXnIEHjYxqW8hyrXxxMV/ZdkaLrnI8X5H5zMmAGqPU=;
    b=Jejqc1SXphtQ8h9gzCM31bQ+0qNtrH7AzXFD9msjT01VYoHzlbLiFsS7joJPlqJppT
    NZEjo0o3mK+rRvz5pgCA==
X-RZG-AUTH: ":I3kQck+hdfi/FoX876SYvGxtQu+BXCDuSQ9UENFBFhpuMtcK2yjIjEY8XWHyellWhOLE"
Content-Type: multipart/alternative;
 boundary="------------J0QUdqluwGoGMIdUgmpyUTtv"
Message-ID: 
Date: Fri, 16 May 2025 01:03:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Reply-To: andreas.greve@a-greve.de
Content-Language: en-US
From: Andreas Greve 
Subject: BUG kernel 6.12.19 defautl_swiotlb_limit() returns wrong value for
 CONFIG_SWIOTLB_DYNAMIC=y effects atm only under XEN dom0
To: xen-devel@lists.xenproject.org
Cc: andreas.greve@a-greve.de
Content-Transfer-Encoding: 8bit

This is a multi-part message in MIME format.
--------------J0QUdqluwGoGMIdUgmpyUTtv
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello to all,

please excuse my bad English and I hope this is the right List.

In Xen 4.20 kernel 6.12.19  Xen with CONFIG_SWIOTLB_DYNAMIC enabled I 
could not load the xhci driver for  my ASMEDIA ASM1042 usb3 controller 
in dom0.

it always failes with -EOI (-5) in dma_set_mask (struct device *dev, u64 
mask) from kernel/dma/mapping.c when it is called with mask = 
DMA_BIT_MASK(32). dma_set_mask is called by xhci_gen_setup(struct 
usb_hcd *hcd, xhci_get_quirks_t get_quirks) from drivers/usb/host/xhci.c

The reason is that the function dma_supported(dev, mask) from mapping.c 
calling ops->dma_supported(dev, mask) which is 
xen_swiotlb_dma_supported(struct device *hwdev, u64 mask) in 
drivers/xen/swiotlb-xen.c failed.

The function xen_swiotlb_dma_supported fails at return 
xen_phys_to_dma(hwdev, default_swiotlb_limit()) <= mask ; because
xen_phys_to_dma(hwdev, default_swiotlb_limit()) returns 
INVALID_P2M_ENTRY which is greater then mask (DMA_BIT_MASK(32)).

The reason is that the function default_swiottlb_limit() defined in 
./kernel/dma/swiotlb.c as

/**
  * default_swiotlb_limit() - get the address limit of the default SWIOTLB
  *
  * Get the highest physical address used by the default software IO TLB 
pool.
  */
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;
#endif
}

returns in case of CONFIG_SWIOTLB_DYNAMIC=y io_tlb_default_mem.phys_limit.

io_tlb_default_mem.phys_limit points to the end (0x83effffff) of the 
highest Xen usable memory region which is on my system 83effffff

BIOS-provided physical RAM map:
[....]
Xen: [mem 0x0000000100001000-0x000000083effffff] usable
[....]

In the boot phase this address is always mapped in p2m to 
INVALID_P2M_ENTRY. I have never seen that it is mapped to a valid 
machine address.

When  CONFIG_SWIOTLB_DYNAMIC  is not set the function 
default_swiotlb_limit() returns io_tlb_default_mem.defpool.end - 1 which 
maps to a value less than DAM_BIT_MASK(32).

In a non -Xen environment, the error for my system does not occur 
because the ASM1042 is there handled via an IOMMU path. IMO the problem 
described above also exists there.

Also my radeon (Radeon HD 4550 RV710) driver compiled in  coming from  
radeon_device_init  over dma_set_mask fails with -EOI (-5) .

  I see 2 possible solutions:

Atm the function default_swiotlb_limit() is only used at one place in 
swiotlb-xen.c (fgrep over  kernel source today master branch)

1) if I take the function comment

* Get the highest physical address used by the default software IO TLB pool.

of default_swiotlb_limit() literally I would replace return 
io_tlb_default_mem.phys_limit; with return 
io_tlb_default_mem.defpool.end - 1;

or writing a new function default_swiotlb_current_limit() with that content.

2) I would have to iterate over the list io_tlb_default_mem.pools to 
find the highest mapped address or writing a new function 
default_swiotlb_current_limit() with that content.

I would prefer 1) I because less work, less errors susceptible and more 
efficient. Since I do not have the necessary overview and there could be 
side effects, I need your help with the decision.

Thanks in advance

Andreas

--------------J0QUdqluwGoGMIdUgmpyUTtv
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  

    
  
  
    
    Hello to all,
    
    
    please excuse my bad English and I hope this
        is the right List.
    
    
    In Xen 4.20 kernel 6.12.19  Xen with CONFIG_SWIOTLB_DYNAMIC
      enabled I could not load the xhci driver for  my ASMEDIA ASM1042
      usb3 controller in dom0.
    
    
    it always failes with -EOI (-5) in dma_set_mask (struct device
      *dev, u64 mask) from kernel/dma/mapping.c when it is called with
      mask = DMA_BIT_MASK(32). dma_set_mask is called by
      xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
      from drivers/usb/host/xhci.c
    
    
    The reason is that the function dma_supported(dev, mask) from mapping.c
      calling ops->dma_supported(dev, mask) which is
      xen_swiotlb_dma_supported(struct device *hwdev, u64 mask) in
      drivers/xen/swiotlb-xen.c failed.
    
    
    
    
    The function xen_swiotlb_dma_supported fails at return
      xen_phys_to_dma(hwdev, default_swiotlb_limit()) <= mask ; 
      because
    
      xen_phys_to_dma(hwdev, default_swiotlb_limit()) returns
      INVALID_P2M_ENTRY which is greater then mask (DMA_BIT_MASK(32)).
    
    
    The reason is that the function default_swiottlb_limit() defined
      in ./kernel/dma/swiotlb.c as
    
    
    
    
    /**
    
       * default_swiotlb_limit() - get the address limit of the default
      SWIOTLB
    
       *
    
       * Get the highest physical address used by the default software
      IO TLB pool.
    
       */
    
      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;
    
      #endif
    
      }
    
    
    
    
    returns in case of CONFIG_SWIOTLB_DYNAMIC=y  
      io_tlb_default_mem.phys_limit.
    
    
    io_tlb_default_mem.phys_limit points to the end (0x83effffff) of
      the highest Xen usable memory region which is on my system
      83effffff
    
    
    BIOS-provided physical RAM map:
    
      [....]
    
      Xen: [mem 0x0000000100001000-0x000000083effffff] usable 
    
      [....]
    
      
    
      In the boot phase this address is always mapped in p2m to 
      INVALID_P2M_ENTRY. I have never seen that it is mapped to a valid
      machine address.
    
      
    
      When  CONFIG_SWIOTLB_DYNAMIC  is not set the function
      default_swiotlb_limit() returns io_tlb_default_mem.defpool.end - 1
      which maps to a value less than DAM_BIT_MASK(32).
    
    
    In a non -Xen environment, the error for my system does not occur
      because the ASM1042 is there handled via an IOMMU path. IMO the problem described above also exists
        there. 
    
    
    Also my radeon (Radeon HD 4550 RV710) driver compiled in  coming
      from  radeon_device_init  over dma_set_mask fails with -EOI (-5) .
    
    
     I see 2 possible solutions:
    
    
    Atm the function default_swiotlb_limit() is only used at one
      place in swiotlb-xen.c (fgrep over  kernel source today master
      branch)
    
    
    
    
    1) if I take the function comment 
    
    
    * Get the highest physical address used by the default software
      IO TLB pool.
    
    
    of default_swiotlb_limit() literally I would replace return
      io_tlb_default_mem.phys_limit; with return
      io_tlb_default_mem.defpool.end - 1;
    
    
    or writing a new function default_swiotlb_current_limit() with
      that content.
    
    
    
    
    2) I would have to iterate over the list io_tlb_default_mem.pools
      to find the highest mapped address or writing a new function
      default_swiotlb_current_limit() with that content.
    
    
    I would prefer 1) I because less work, less errors susceptible
      and more efficient. Since I do not have the
        necessary overview and there could be side effects, I need your
        help with the decision.
    
    
    Thanks in advance 
    
      
    
    
    Andreas
    
           
    
  


--------------J0QUdqluwGoGMIdUgmpyUTtv--


From xen-devel-bounces@lists.xenproject.org Fri May 16 02:04:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 02:04:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986161.1371806 (Exim 4.92)
	(envelope-from )
	id 1uFkRP-0002fL-Mc; Fri, 16 May 2025 02:04:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986161.1371806; Fri, 16 May 2025 02:04: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 1uFkRP-0002fE-Js; Fri, 16 May 2025 02:04:51 +0000
Received: by outflank-mailman (input) for mailman id 986161;
 Fri, 16 May 2025 02:04:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFkRN-0002f4-II
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 02:04:50 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 246eee67-31fa-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 04:04: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" 
X-Inumbo-ID: 246eee67-31fa-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747361086; x=1747620286;
	bh=ujB9BJYsKZ+Zv1s7n6SYafFdRfwsB3dYGvVFgIhtplQ=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=YcTazPrTvtsP02h07/3srkl8/7rYWk7zqjZL5oE+kdBMTVWxBTVp4kHZ159slQ7hm
	 9WsDbry/sIrc1Ql7D6yEQCGE9h9RO/KO2Bx/yI+87a0Okyu0kdGTU6Hn2QC1rxfucr
	 CLqAamYhjkf51VQeKSNhsO1aCETOLYRaHw+D7uDhiWQdBcxc+166U5ltwHDWFkfYoa
	 t9m6rv3+A7oKPyaafo7JfykhDQuwyILUVTBzMoQQfBLcrhhuuy7la3qJ/nEQn/V1Rs
	 O45sCercVEIyQfgKAKt4S91IJ4tIZ0s6p4cgRENlxC5D334x8o8BiLOhi7yEeRb7i2
	 Y2ReeFtsgviEQ==
Date: Fri, 16 May 2025 02:04:42 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v6 0/2] xen/domain: domain ID allocation
Message-ID: <20250516020434.1145337-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 5fd36bd739f417e13c2f893dd30086a26f18b27e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The patch series adds new library calls for allocating domain IDs.
Patch 1 introduces new domid_{init,alloc,free} calls.
Patch 2 adjusts hardware domain ID treatment on Arm.

Link to v5: https://lore.kernel.org/xen-devel/20250504135544.730906-1-dmukh=
in@ford.com/
Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1=
820251194

Denis Mukhin (2):
  xen/domain: unify domain ID allocation
  xen/domain: adjust domain ID allocation for Arm

 xen/arch/arm/domain_build.c             | 17 ++++--
 xen/arch/arm/setup.c                    |  2 +
 xen/arch/x86/setup.c                    | 13 +++--
 xen/common/device-tree/dom0less-build.c | 17 +++---
 xen/common/domain.c                     | 73 +++++++++++++++++++++++++
 xen/common/domctl.c                     | 41 ++------------
 xen/include/xen/domain.h                |  4 ++
 7 files changed, 112 insertions(+), 55 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 16 02:05:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 02:05:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986163.1371817 (Exim 4.92)
	(envelope-from )
	id 1uFkRZ-0002xI-TV; Fri, 16 May 2025 02:05:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986163.1371817; Fri, 16 May 2025 02:05: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 1uFkRZ-0002xB-QI; Fri, 16 May 2025 02:05:01 +0000
Received: by outflank-mailman (input) for mailman id 986163;
 Fri, 16 May 2025 02:05:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFkRY-0002f4-Fa
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 02:05:00 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2b4bc337-31fa-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 04:04:58 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2b4bc337-31fa-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747361097; x=1747620297;
	bh=LZKu9PKx4dtqX7PeXKBL32LGFgu0BUSOKhh4ehWsGu4=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=PCn3rcD1oOwFvLcOiFMIMBxDVXOEUuBEGQA/rm3HgSeWjymEBUFH/6sUncB/Atmi7
	 AVNRR6rLIuTd5/gN91yEcwv02ICgfzM0oR5kt/1CQKLea5CGxzsg4VHDgIENJOccLK
	 BzNKvW2I1P0a6qcEGA4X6t8G+P5wVmq6YyVHh8+I3J46dxS2qSjQ+5TX7ZCz+1J1Yo
	 Yluu9ENZMuRlP0dan1vgfEjQXmTlZQ9/piYu8+n7K0HaXKH3ZN2h2Xoc2OTlof8FiX
	 /Blw7pvpMmsXsdWOCcBDXJ7j+h6nPCLGBvKwsR9wtHz3hVONo3opq4wkvZCyZQ7c/F
	 vYr/AJK5qt79Q==
Date: Fri, 16 May 2025 02:04:50 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v6 1/2] xen/domain: unify domain ID allocation
Message-ID: <20250516020434.1145337-2-dmukhin@ford.com>
In-Reply-To: <20250516020434.1145337-1-dmukhin@ford.com>
References: <20250516020434.1145337-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: c7c644690939b4f8b4ff424fb10d205e32659ebe
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Currently, hypervisor code has two different non-system domain ID allocatio=
n
implementations:

  (a) Sequential IDs allocation in dom0less Arm code based on max_init_domi=
d;

  (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
      max_init_domid (both Arm and x86).

It makes sense to have a common helper code for such task across architectu=
res
(Arm and x86) and between dom0less / toolstack domU allocation.

Wrap the domain ID allocation as an arch-independent function domid_alloc()=
 in
common/domain.c based on rangeset.

Allocation algorithm:
- If an explicit domain ID is provided, verify its availability and
  use it if ID is not used;
- Otherwise, perform an exhaustive search starting from the end of the used
  domain ID range. domid_alloc() guarantees that two subsequent calls will
  result in different IDs allocation.

Initialize the domain IDs rangeset from the new domid_init() which is calle=
d
from arch setup code.

Also, remove is_free_domid() helper as it is not needed now.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- rebased
---
 xen/arch/arm/domain_build.c             | 17 ++++--
 xen/arch/arm/setup.c                    |  2 +
 xen/arch/x86/setup.c                    | 13 +++--
 xen/common/device-tree/dom0less-build.c | 10 ++--
 xen/common/domain.c                     | 70 +++++++++++++++++++++++++
 xen/common/domctl.c                     | 41 ++-------------
 xen/include/xen/domain.h                |  4 ++
 7 files changed, 107 insertions(+), 50 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..e9d563c269 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2010,6 +2010,7 @@ void __init create_dom0(void)
         .grant_opts =3D XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
     };
     unsigned int flags =3D CDF_privileged | CDF_hardware;
+    domid_t domid;
     int rc;
=20
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
@@ -2034,19 +2035,25 @@ void __init create_dom0(void)
     if ( !llc_coloring_enabled )
         flags |=3D CDF_directmap;
=20
-    dom0 =3D domain_create(0, &dom0_cfg, flags);
+    domid =3D domid_alloc(0);
+    if ( domid =3D=3D DOMID_INVALID )
+        panic("Error allocating domain ID 0\n");
+
+    dom0 =3D domain_create(domid, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
-        panic("Error creating domain 0 (rc =3D %ld)\n", PTR_ERR(dom0));
+        panic("Error creating domain %d (rc =3D %ld)\n", domid, PTR_ERR(do=
m0));
=20
     if ( llc_coloring_enabled && (rc =3D dom0_set_llc_colors(dom0)) )
-        panic("Error initializing LLC coloring for domain 0 (rc =3D %d)\n"=
, rc);
+        panic("Error initializing LLC coloring for domain %pd (rc =3D %d)\=
n",
+              dom0, rc);
=20
     if ( alloc_dom0_vcpu0(dom0) =3D=3D NULL )
-        panic("Error creating domain 0 vcpu0\n");
+        panic("Error creating domain %pdv0\n", dom0);
=20
     rc =3D construct_dom0(dom0);
     if ( rc )
-        panic("Could not set up DOM0 guest OS (rc =3D %d)\n", rc);
+        panic("Could not set up guest OS for domain %pd (rc =3D %d)\n",
+              dom0, rc);
=20
     set_xs_domain(dom0);
 }
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 10b46d0684..c3959e8d8e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -418,6 +418,8 @@ void asmlinkage __init start_xen(unsigned long fdt_padd=
r)
=20
     timer_init();
=20
+    domid_init();
+
     init_idle_domain();
=20
     rcu_init();
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2518954124..02f665f520 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1030,8 +1030,11 @@ static struct domain *__init create_dom0(struct boot=
_info *bi)
     if ( iommu_enabled )
         dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu;
=20
-    /* Create initial domain.  Not d0 for pvshim. */
-    bd->domid =3D get_initial_domain_id();
+    /* Allocate initial domain ID. Not d0 for pvshim. */
+    bd->domid =3D domid_alloc(get_initial_domain_id());
+    if ( bd->domid =3D=3D DOMID_INVALID )
+        panic("Error allocating domain ID %d\n", get_initial_domain_id());
+
     d =3D domain_create(bd->domid, &dom0_cfg,
                       pv_shim ? 0 : CDF_privileged | CDF_hardware);
     if ( IS_ERR(d) )
@@ -1063,7 +1066,7 @@ static struct domain *__init create_dom0(struct boot_=
info *bi)
=20
         if ( (strlen(acpi_param) =3D=3D 0) && acpi_disabled )
         {
-            printk("ACPI is disabled, notifying Domain 0 (acpi=3Doff)\n");
+            printk("ACPI is disabled, notifying domain %pd (acpi=3Doff)\n"=
, d);
             safe_strcpy(acpi_param, "off");
         }
=20
@@ -1078,7 +1081,7 @@ static struct domain *__init create_dom0(struct boot_=
info *bi)
=20
     bd->d =3D d;
     if ( construct_dom0(bd) !=3D 0 )
-        panic("Could not construct domain 0\n");
+        panic("Could not construct domain %pd\n", d);
=20
     bd->cmdline =3D NULL;
     xfree(cmdline);
@@ -1915,6 +1918,8 @@ void asmlinkage __init noreturn __start_xen(void)
     mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",
                                   RANGESETF_prettyprint_hex);
=20
+    domid_init();
+
     xsm_multiboot_init(bi);
=20
     /*
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index 2c56f13771..9236dbae11 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -850,15 +850,13 @@ void __init create_domUs(void)
         struct xen_domctl_createdomain d_cfg =3D {0};
         unsigned int flags =3D 0U;
         bool has_dtb =3D false;
+        domid_t domid;
         uint32_t val;
         int rc;
=20
         if ( !dt_device_is_compatible(node, "xen,domain") )
             continue;
=20
-        if ( (max_init_domid + 1) >=3D DOMID_FIRST_RESERVED )
-            panic("No more domain IDs available\n");
-
         d_cfg.max_evtchn_port =3D 1023;
         d_cfg.max_grant_frames =3D -1;
         d_cfg.max_maptrack_frames =3D -1;
@@ -981,7 +979,11 @@ void __init create_domUs(void)
          * very important to use the pre-increment operator to call
          * domain_create() with a domid > 0. (domid =3D=3D 0 is reserved f=
or Dom0)
          */
-        d =3D domain_create(++max_init_domid, &d_cfg, flags);
+        domid =3D domid_alloc(++max_init_domid);
+        if ( domid =3D=3D DOMID_INVALID )
+            panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
+
+        d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
             panic("Error creating domain %s (rc =3D %ld)\n",
                   dt_node_name(node), PTR_ERR(d));
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..0ba3cdc47d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -66,6 +66,74 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
 static struct domain *domain_hash[DOMAIN_HASH_SIZE];
 struct domain *domain_list;
=20
+/* Non-system domain ID allocator. */
+static DEFINE_SPINLOCK(domid_lock);
+static struct rangeset *domid_rangeset;
+static unsigned int domid_last;
+
+void __init domid_init(void)
+{
+    domid_rangeset =3D rangeset_new(NULL, "domid", RANGESETF_prettyprint_h=
ex);
+    if ( !domid_rangeset )
+        panic("cannot allocate domain ID rangeset\n");
+
+    rangeset_limit(domid_rangeset, DOMID_FIRST_RESERVED);
+}
+
+/*
+ * Allocate new non-system domain ID based on the hint.
+ *
+ * If hint is outside of valid [0..DOMID_FIRST_RESERVED - 1] range of IDs,
+ * perform an exhaustive search starting from the end of the used domain I=
D
+ * range.
+ */
+domid_t domid_alloc(domid_t domid)
+{
+    spin_lock(&domid_lock);
+
+    if ( domid < DOMID_FIRST_RESERVED )
+    {
+        if ( rangeset_contains_singleton(domid_rangeset, domid) )
+            domid =3D DOMID_INVALID;
+    }
+    else
+    {
+        for ( domid =3D domid_last + 1; domid !=3D domid_last; domid++ )
+        {
+            if ( domid =3D=3D DOMID_FIRST_RESERVED )
+                domid =3D 0;
+
+            if ( !rangeset_contains_singleton(domid_rangeset, domid) )
+                break;
+        }
+
+        if ( domid =3D=3D domid_last )
+            domid =3D DOMID_INVALID;
+    }
+
+    if ( domid !=3D DOMID_INVALID )
+    {
+        ASSERT(!rangeset_add_singleton(domid_rangeset, domid));
+
+        if ( domid !=3D domid_last )
+            domid_last =3D domid;
+    }
+
+    spin_unlock(&domid_lock);
+
+    return domid;
+}
+
+void domid_free(domid_t domid)
+{
+    spin_lock(&domid_lock);
+
+    if ( rangeset_contains_singleton(domid_rangeset, domid) )
+        ASSERT(!rangeset_remove_singleton(domid_rangeset, domid));
+
+    spin_unlock(&domid_lock);
+}
+
 /*
  * Insert a domain into the domlist/hash.  This allows the domain to be lo=
oked
  * up by domid, and therefore to be the subject of hypercalls/etc.
@@ -1449,6 +1517,8 @@ void domain_destroy(struct domain *d)
=20
     TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id);
=20
+    domid_free(d->domain_id);
+
     /* Remove from the domlist/hash. */
     domlist_remove(d);
=20
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index bfe2e1f9f0..2e02139660 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -49,20 +49,6 @@ static int xenctl_bitmap_to_nodemask(nodemask_t *nodemas=
k,
                                    MAX_NUMNODES);
 }
=20
-static inline int is_free_domid(domid_t dom)
-{
-    struct domain *d;
-
-    if ( dom >=3D DOMID_FIRST_RESERVED )
-        return 0;
-
-    if ( (d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL )
-        return 1;
-
-    rcu_unlock_domain(d);
-    return 0;
-}
-
 void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info=
)
 {
     struct vcpu *v;
@@ -421,34 +407,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u=
_domctl)
=20
     case XEN_DOMCTL_createdomain:
     {
-        domid_t        dom;
-        static domid_t rover =3D 0;
+        domid_t domid =3D domid_alloc(op->domain);
=20
-        dom =3D op->domain;
-        if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) )
+        if ( domid =3D=3D DOMID_INVALID )
         {
             ret =3D -EEXIST;
-            if ( !is_free_domid(dom) )
-                break;
-        }
-        else
-        {
-            for ( dom =3D rover + 1; dom !=3D rover; dom++ )
-            {
-                if ( dom =3D=3D DOMID_FIRST_RESERVED )
-                    dom =3D 1;
-                if ( is_free_domid(dom) )
-                    break;
-            }
-
-            ret =3D -ENOMEM;
-            if ( dom =3D=3D rover )
-                break;
-
-            rover =3D dom;
+            break;
         }
=20
-        d =3D domain_create(dom, &op->u.createdomain, false);
+        d =3D domain_create(domid, &op->u.createdomain, false);
         if ( IS_ERR(d) )
         {
             ret =3D PTR_ERR(d);
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index e10baf2615..039bb7eeaf 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -38,6 +38,10 @@ void arch_get_domain_info(const struct domain *d,
=20
 domid_t get_initial_domain_id(void);
=20
+void domid_init(void);
+void domid_free(domid_t domid);
+domid_t domid_alloc(domid_t domid);
+
 /* CDF_* constant. Internal flags for domain creation. */
 /* Is this a privileged domain? */
 #define CDF_privileged           (1U << 0)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 16 02:05:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 02:05:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986164.1371826 (Exim 4.92)
	(envelope-from )
	id 1uFkRf-0003Fv-4M; Fri, 16 May 2025 02:05:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986164.1371826; Fri, 16 May 2025 02:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFkRf-0003Fm-1Z; Fri, 16 May 2025 02:05:07 +0000
Received: by outflank-mailman (input) for mailman id 986164;
 Fri, 16 May 2025 02:05:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFkRd-0002f4-Ns
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 02:05:05 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2e906ed1-31fa-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 04:05: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" 
X-Inumbo-ID: 2e906ed1-31fa-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747361103; x=1747620303;
	bh=UNygIiQeosiEp8EG38J9RJGGNELDAURW7bNhwd6Excg=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=fd9fsyh9x7EwAubpvGzyVC5NuYM0OXWmRbv+QcV50I7bWWpQ5MJ15F1+7P0MXAsyI
	 xR5zZm597/cSdcSY8W0nzrQof4GFsK+Zf7GP9h1REDaCPntAvJZpSj//ftlrcfsFtw
	 5Yspj80qVb5kEE6X0+R2mfGWhJfvvFQzsWWRzPz9kJw5t/XJxRmODDSSTS7+rcw/xd
	 c7H/3QtaIzRUC/1gdvSicR8aVnMq//Z/r0r3w9ARkLt5w6XI+Qxpi5VOYBmtWHvXTj
	 lsg/MJNtA3hoox1TTh7z8dTuhtmoVfju5bnLqswU+bzkPlooDNEXKBqpn1ta1oa+b+
	 uNzo9wHiC0vnw==
Date: Fri, 16 May 2025 02:04:58 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v6 2/2] xen/domain: adjust domain ID allocation for Arm
Message-ID: <20250516020434.1145337-3-dmukhin@ford.com>
In-Reply-To: <20250516020434.1145337-1-dmukhin@ford.com>
References: <20250516020434.1145337-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 30aae9b71305ff1fe0734ae0f3f19f0d659dac6f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Remove the hardcoded domain ID 0 allocation for hardware domain and replace=
 it
with a call to get_initial_domain_id() (returns the value of hardware_domid=
 on
Arm).

Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_domain_id=
()
ID is skipped during domain ID allocation to cover domU case.

Signed-off-by: Denis Mukhin 
---
Changes since v5:
- rebased
---
 xen/arch/arm/domain_build.c             | 4 ++--
 xen/common/device-tree/dom0less-build.c | 9 +++------
 xen/common/domain.c                     | 5 ++++-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e9d563c269..0ad80b020a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2035,9 +2035,9 @@ void __init create_dom0(void)
     if ( !llc_coloring_enabled )
         flags |=3D CDF_directmap;
=20
-    domid =3D domid_alloc(0);
+    domid =3D domid_alloc(get_initial_domain_id());
     if ( domid =3D=3D DOMID_INVALID )
-        panic("Error allocating domain ID 0\n");
+        panic("Error allocating domain ID %d\n", get_initial_domain_id());
=20
     dom0 =3D domain_create(domid, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index 9236dbae11..8e38affd0c 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -974,14 +974,11 @@ void __init create_domUs(void)
=20
         arch_create_domUs(node, &d_cfg, flags);
=20
-        /*
-         * The variable max_init_domid is initialized with zero, so here i=
t's
-         * very important to use the pre-increment operator to call
-         * domain_create() with a domid > 0. (domid =3D=3D 0 is reserved f=
or Dom0)
-         */
-        domid =3D domid_alloc(++max_init_domid);
+        domid =3D domid_alloc(DOMID_INVALID);
         if ( domid =3D=3D DOMID_INVALID )
             panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
+        if ( max_init_domid < domid )
+            max_init_domid =3D domid;
=20
         d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 0ba3cdc47d..055397b5aa 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -85,7 +85,7 @@ void __init domid_init(void)
  *
  * If hint is outside of valid [0..DOMID_FIRST_RESERVED - 1] range of IDs,
  * perform an exhaustive search starting from the end of the used domain I=
D
- * range.
+ * range, excluding get_initial_domain_id() ID.
  */
 domid_t domid_alloc(domid_t domid)
 {
@@ -103,6 +103,9 @@ domid_t domid_alloc(domid_t domid)
             if ( domid =3D=3D DOMID_FIRST_RESERVED )
                 domid =3D 0;
=20
+            if ( domid =3D=3D get_initial_domain_id() )
+                continue;
+
             if ( !rangeset_contains_singleton(domid_rangeset, domid) )
                 break;
         }
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 16 02:29:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 02:29:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986190.1371846 (Exim 4.92)
	(envelope-from )
	id 1uFkp5-0006eA-4G; Fri, 16 May 2025 02:29:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986190.1371846; Fri, 16 May 2025 02: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 1uFkp5-0006e3-1U; Fri, 16 May 2025 02:29:19 +0000
Received: by outflank-mailman (input) for mailman id 986190;
 Fri, 16 May 2025 02:29:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFkp3-0006Ps-Jc
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 02:29:17 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8fe4790b-31fd-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 04:29: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" 
X-Inumbo-ID: 8fe4790b-31fd-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747362555; x=1747621755;
	bh=h5EcJl/sF6rW1//mlhgDFyvsZGHFJmMNHZYVn0i9SSc=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=IsOeSgljnitiwxzLY+Mm65+VdfNqwUHMczWk757b9RfbWTEr6IF68CBhrAvgTP3vM
	 N+S02HJDj/ZoQMtDqc3iJIeG6xxm5+X+WXPMMQA+3cllxeWe1fUJhNAandKv55lerg
	 GkvRzzeg+G0YUtD/ht5PGlGOnjxW6WoGYgadR140v6fQkYaHFbLLJ+1psAgCWvnm/A
	 l4vG6J1BMLVRsE0z4E+c7K7LBO0KxZzIGsq3JSI6uIAJEySdB39ChWEQGTYn2hJmE7
	 n0+PJho4uMFlKRS9GcH7zVNsjNkzJj4LvSngIIzfSwGJFAAq9dLIaFVb3ZucpckJS5
	 I2mCHPxFKW6Kw==
Date: Fri, 16 May 2025 02:29:09 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v2 1/2] xen/domain: introduce non-x86 hardware emulation flags
Message-ID: <20250516022855.1146121-2-dmukhin@ford.com>
In-Reply-To: <20250516022855.1146121-1-dmukhin@ford.com>
References: <20250516022855.1146121-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 30a6354a2881bec5fbb4828e4ff7ea5ce265ac01
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Define per-architecture emulation_flags for configuring domain emulation
features.

Print d->arch.emulation_flags from 'q' keyhandler for better traceability
while debugging.

Signed-off-by: Denis Mukhin 
---
Changes since v1:
- dropped comments
---
 xen/arch/arm/include/asm/domain.h   | 1 +
 xen/arch/ppc/include/asm/domain.h   | 1 +
 xen/arch/riscv/include/asm/domain.h | 1 +
 xen/common/keyhandler.c             | 1 +
 4 files changed, 4 insertions(+)

diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d=
omain.h
index a3487ca713..70e6e7d49b 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -121,6 +121,7 @@ struct arch_domain
     void *tee;
 #endif
=20
+    uint32_t emulation_flags;
 }  __cacheline_aligned;
=20
 struct arch_vcpu
diff --git a/xen/arch/ppc/include/asm/domain.h b/xen/arch/ppc/include/asm/d=
omain.h
index 3a447272c6..001116a0ab 100644
--- a/xen/arch/ppc/include/asm/domain.h
+++ b/xen/arch/ppc/include/asm/domain.h
@@ -21,6 +21,7 @@ struct arch_vcpu {
=20
 struct arch_domain {
     struct hvm_domain hvm;
+    uint32_t emulation_flags;
 };
=20
 #include 
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/a=
sm/domain.h
index c3d965a559..7bc242da55 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -18,6 +18,7 @@ struct arch_vcpu {
=20
 struct arch_domain {
     struct hvm_domain hvm;
+    uint32_t emulation_flags;
 };
=20
 #include 
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 0bb842ec00..73f5134b68 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -306,6 +306,7 @@ static void cf_check dump_domains(unsigned char key)
             if ( test_bit(i, &d->watchdog_inuse_map) )
                 printk("    watchdog %d expires in %d seconds\n",
                        i, (u32)((d->watchdog_timer[i].expires - NOW()) >> =
30));
+        printk("    emulation_flags %#x\n", d->arch.emulation_flags);
=20
         arch_dump_domain_info(d);
=20
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 16 02:29:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 02:29:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986189.1371836 (Exim 4.92)
	(envelope-from )
	id 1uFkp0-0006Q7-UU; Fri, 16 May 2025 02:29:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986189.1371836; Fri, 16 May 2025 02: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 1uFkp0-0006Q0-Ry; Fri, 16 May 2025 02:29:14 +0000
Received: by outflank-mailman (input) for mailman id 986189;
 Fri, 16 May 2025 02:29:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFkoy-0006Ps-CC
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 02:29:13 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8c1426f8-31fd-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 04:29: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" 
X-Inumbo-ID: 8c1426f8-31fd-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=imedksexubfk5coe2xwez3mdjq.protonmail; t=1747362548; x=1747621748;
	bh=/BEUwhhP72BtvkVKFKsbgSbbCNM2TCebK6uJAiCil08=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=RHDhQN1k6mQpt3G+gtoqDn66xiB8JSwtgeazA6klZbMd44O8CG7detoJPoeaBcnsl
	 eyJwQvq1FdkOxmZHRhzETSVSdIpgD0ZZVE/fVP5CjeZGD4DWmyBIkITfc6AHlG+E9S
	 LhPPayFP2VUv3m6BChYGO1RBpkqyiVJ+2mJOZSkMNZObDddvO9Nb5kUso/DL5rY1sQ
	 wn4gig83VfDeILX3Cz8fXxpUEeuxsB0Du3oYS0p8UJZKVHLAHwXR07QohgsTaSJfF7
	 6Lqgj4DwjOOWpUH/NGS/br5b8uv+809VvqGAcRG5O+arqaz1P/H4F+dKRplzGiSWmh
	 m8bYnWP9Hngxg==
Date: Fri, 16 May 2025 02:29:02 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v2 0/2] xen/domain: updates to hardware emulation flags
Message-ID: <20250516022855.1146121-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: ab2bc2529e178cc3b1adb026cb919c31d21ed593
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Patch 1 introduces use of d->arch.emulation_flags for non-x86 platforms and
hooks emulation_flags to 'q' keyhandler for debugging. emulation_flags on
non-x86 systems can be used for enabling domain emulation features.

Patch 2 rewrites emulation_flags_ok() on x86 with a goal of improving
readability of the code.

Originally, the code was part of [1], part of NS16550 emulator v3 series.

[1] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-6-c5d36b3=
1d66c@ford.com/
[2] Link to v1: https://lore.kernel.org/xen-devel/20250401005224.461325-1-d=
mukhin@ford.com/
[3] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1820121879=20

Denis Mukhin (2):
  xen/domain: introduce non-x86 hardware emulation flags
  xen/domain: rewrite emulation_flags_ok()

 xen/arch/arm/include/asm/domain.h   |  1 +
 xen/arch/ppc/include/asm/domain.h   |  1 +
 xen/arch/riscv/include/asm/domain.h |  1 +
 xen/arch/x86/domain.c               | 29 +++++++++++------------------
 xen/arch/x86/include/asm/domain.h   |  6 ++++++
 xen/common/keyhandler.c             |  1 +
 6 files changed, 21 insertions(+), 18 deletions(-)

--=20
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 02:29:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 02:29:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986191.1371857 (Exim 4.92)
	(envelope-from )
	id 1uFkpA-0006vN-FQ; Fri, 16 May 2025 02:29:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986191.1371857; Fri, 16 May 2025 02:29: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 1uFkpA-0006vG-CU; Fri, 16 May 2025 02:29:24 +0000
Received: by outflank-mailman (input) for mailman id 986191;
 Fri, 16 May 2025 02:29:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFkp8-0006te-Pk
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 02:29:22 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 92f3ed54-31fd-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 04:29: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" 
X-Inumbo-ID: 92f3ed54-31fd-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747362560; x=1747621760;
	bh=v1vn8ef3G4X58jhWf4vJUvPbMgDk9COkx7mA/B+hxO0=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=TyJxbmrhxNM9N4pdybXCxOjZcXHLylq1QtjamuDFe4f7UzkFU0vBZrqAV2dYr1AVQ
	 NPRloJiwr+w6przTXjCYQQ3EVVgcHSDPEoYgidSfpehzRxio4N/dOXc0WyuddnECXo
	 1chTJsIKF8Zm7svDD85SlvkMczz6/CYRmHvk2O5P+Ly004Q5RBiJGOQ8be6pAtrRpw
	 +uhvNhudv8hoWY+O9byS5s58uB+uxvMXSNng6lVCwDkAMovjdb8g0Sfpu5x0gmNiZq
	 80cbF8fTcGBlgm0tu3splgnKgrFePnsYYss92SN00sk2W0+Paqp/GdGlIw7EB/l+8N
	 P4QWJF1LGvSsQ==
Date: Fri, 16 May 2025 02:29:16 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v2 2/2] xen/domain: rewrite emulation_flags_ok()
Message-ID: <20250516022855.1146121-3-dmukhin@ford.com>
In-Reply-To: <20250516022855.1146121-1-dmukhin@ford.com>
References: <20250516022855.1146121-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: b6b8864594d38da9accff697830df3459e336910
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Rewrite emulation_flags_ok() to simplify future modifications.

Also, introduce X86_EMU_{BASELINE,OPTIONAL} helper macros.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v1:
- kept use of non-public X86_EMU_XXX flags
- corrected some comments and macro definitions
---
 xen/arch/x86/domain.c             | 29 +++++++++++------------------
 xen/arch/x86/include/asm/domain.h |  6 ++++++
 2 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index f197dad4c0..c64c2c6fef 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -750,25 +750,18 @@ static bool emulation_flags_ok(const struct domain *d=
, uint32_t emflags)
     BUILD_BUG_ON(X86_EMU_ALL !=3D XEN_X86_EMU_ALL);
 #endif
=20
-    if ( is_hvm_domain(d) )
-    {
-        if ( is_hardware_domain(d) &&
-             emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) =
)
-            return false;
-        if ( !is_hardware_domain(d) &&
-             /* HVM PIRQ feature is user-selectable. */
-             (emflags & ~X86_EMU_USE_PIRQ) !=3D
-             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
-             emflags !=3D X86_EMU_LAPIC )
-            return false;
-    }
-    else if ( emflags !=3D 0 && emflags !=3D X86_EMU_PIT )
-    {
-        /* PV or classic PVH. */
-        return false;
-    }
+    /* PV */
+    if ( !is_hvm_domain(d) )
+        return emflags =3D=3D 0 || emflags =3D=3D X86_EMU_PIT;
=20
-    return true;
+    /* HVM */
+    if ( is_hardware_domain(d) )
+        return emflags =3D=3D (X86_EMU_LAPIC |
+                           X86_EMU_IOAPIC |
+                           X86_EMU_VPCI);
+
+    return (emflags & ~X86_EMU_OPTIONAL) =3D=3D X86_EMU_BASELINE ||
+            emflags =3D=3D X86_EMU_LAPIC;
 }
=20
 void __init arch_init_idle_domain(struct domain *d)
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/d=
omain.h
index 8c0dea12a5..3a9a9fd80d 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -494,6 +494,12 @@ struct arch_domain
                                  X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
                                  X86_EMU_VPCI)
=20
+/* User-selectable features. */
+#define X86_EMU_OPTIONAL        (X86_EMU_USE_PIRQ)
+
+#define X86_EMU_BASELINE        (X86_EMU_ALL & ~(X86_EMU_VPCI | \
+                                                 X86_EMU_OPTIONAL))
+
 #define has_vlapic(d)      (!!((d)->arch.emulation_flags & X86_EMU_LAPIC))
 #define has_vhpet(d)       (!!((d)->arch.emulation_flags & X86_EMU_HPET))
 #define has_vpm(d)         (!!((d)->arch.emulation_flags & X86_EMU_PM))
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 16 02:33:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 02:33:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986214.1371867 (Exim 4.92)
	(envelope-from )
	id 1uFksy-0000ZD-0Y; Fri, 16 May 2025 02:33:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986214.1371867; Fri, 16 May 2025 02:33: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 1uFksx-0000Z6-TT; Fri, 16 May 2025 02:33:19 +0000
Received: by outflank-mailman (input) for mailman id 986214;
 Fri, 16 May 2025 02:33:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFksw-0000Z0-W4
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 02:33:19 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20601.outbound.protection.outlook.com
 [2a01:111:f403:2408::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1ed14744-31fe-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 04:33:16 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA1PR12MB8919.namprd12.prod.outlook.com (2603:10b6:806:38e::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Fri, 16 May
 2025 02:33:12 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8722.031; Fri, 16 May 2025
 02:33:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1ed14744-31fe-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=c4QfWh27naPFYKhwhhV0fUv9rBAtEPZN+623FtsUUP20cT6NWDl1B5qlTFpKOaT/fv6R9cvKmoc07xsSeY/oYjVzaXFVmoTHFsO3Qkov6ztzq5DgVZJ7BgTaN/ECQcrsAqbDR5dnecpyR/rzfpRntOaI4zgqFc46y6KmFFVZoI6HO/qGvJOjx0HS5VN3SfsEaa/leCSNpPm7sOwRhgMLVq7rAiEbj973y61awB9WZq1vMiSZH6/vjW8yTJYnUwjeDnzTtY7e9wrTOL8Q8+doweNJDWMqGSLrJu5qM+r7HHVVuLnuSEM2MR2IQrT4mRtvHmMP0yvXS4zdzEr/1kUsWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2ZqNs414xL42DZ7mgbjBvRRvoYPvUF7v77FMMIzldLQ=;
 b=TCIt4HQsFGYcoVpMH7IxW8y1oKvspmv/wTAd2Nswbar1GFW6MjSmIOLVLRBMqCgmPLLGu/oWqf/NGrbfAVP9lsxcCjlF/AbhZ9aNbiP4I79ebQNPPyHavrB0W8xBqU4y6e9PS3/QnbtV09CNW/vUaSMnzCMbAaXAZpmd6zPnVscFVcAd0nQ190/qhODOQxHA6AVyJ9JLJx+AUGxoshJv47excTTyHRYfmyabC6/KtppA/xqm5fIyRGyGDAw/5Uy3BbLUArx8hQpAw2R4dVX4Ra5iEdGLBl7SaPIkiTlaD+QW1ayyW8DnPepnio/x9Xq3HDmcMNxS6WqlaGw8oMd9Ug==
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=2ZqNs414xL42DZ7mgbjBvRRvoYPvUF7v77FMMIzldLQ=;
 b=yNujdZQksDMeCWLielbmSF8eM2pC+DHP+KkM7lUsj+n1Tn4xA0dh4fPhhSjFy1S3q55gNQBUCYp4ZGTXIc5wCK5Glgc5WVtoKTUeqgtZxN+d9IbzI2hkcEedHMlV6J1JYN1irPAcyJVra6I7In3QZz97mUK9129ZhMA0wFq9oq8=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v4 02/10] vpci/header: Emulate legacy capability list for
 dom0
Thread-Topic: [PATCH v4 02/10] vpci/header: Emulate legacy capability list for
 dom0
Thread-Index: AQHbwMGa1FMptcF6w0qNJxVZG2xD+7PT664AgAEtSIA=
Date: Fri, 16 May 2025 02:33:12 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-3-Jiqian.Chen@amd.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8722.027)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SA1PR12MB8919:EE_
x-ms-office365-filtering-correlation-id: e8ffcd90-3950-451d-0d86-08dd942200ec
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?azdFOWtUelgyMXN6T054WmtNZjJiN0ZmVnRMOGJPaHUxeDl4dTcvTEJDTGtI?=
 =?utf-8?B?ZEhKMGtyWHF0T3pWOHd2WC9ZRWlyRG91bWdpVXFMSFF6Y1lvQS9HR1NuYlBa?=
 =?utf-8?B?NW1YSlh0VGhMWHhBVk8vMDZESGY5eGs5NWt5UHk5S3ltUnRwVUh1OVJ2SWF1?=
 =?utf-8?B?eXl3VGZ5R2xHSVZ2UE1rY2QzNFVrVi9sb28xUHU5S3hicS82ZWlGbk5JRjkx?=
 =?utf-8?B?d0h5R1U2TTFuSEd0QlI3M0J0bXg0K1hOQUtrWlBHNEpxTUxDMlNTM3RacjZk?=
 =?utf-8?B?UCtFUEpSdENWaUdWUFZWVktXZGpvNVBUMVdWcVh0Q0xHTmpJb3RaY0U2bkt2?=
 =?utf-8?B?aDJTZ24rbU5YTEJUakVmZzNVNHhmM3krSDdHR2pubkRUWjRnSGNTTHpWZUVv?=
 =?utf-8?B?SGhSdkJNeXozV2F4a2R0b3hmUFA5bFJ0Z0hrQkZjVS9YbFROWTRTb21lTmg3?=
 =?utf-8?B?a0pHOGp3eEZ5WUlpeTRUZjg0ejJ5ZHZGV3h1VVFhand0a1dqV2xyaE1wekJS?=
 =?utf-8?B?Qzhud0xwNHl1T3V3dXVnS2VjZngrMTBZbHJpQlo2TmRsVFdGMUxGQTA2aTJp?=
 =?utf-8?B?UGltbW1Uc2xuaW05ekFJdDNPQXNqVGNnTjJ1Q2Vzc09ESmEwdEtuT3Q0NzlU?=
 =?utf-8?B?MnZ4T0lKL1BwUFYxdk9ON29oZWpSYlR3ZzgzZWpLTGRQTStFYllFVnZGUTJ6?=
 =?utf-8?B?dFJ6NU95QWJUODJlcGxOcUhBdFNpV0UwZVowT2JNN1VaczBaa0UxMGY3amFF?=
 =?utf-8?B?TFJCbjllT0wydUZsclpSc0F3TTc0dXZ4Q2pGanllQ1hSR3hjUjZMaWpQRE5p?=
 =?utf-8?B?czNmYWZLZUM5TWdsMnZ4OHBjTnlQblNrSzg1Zmd2aDh0enh6NVJNR1RPdTdX?=
 =?utf-8?B?bEltL0MrcUhlMkFQZlU5a094L09PU0VIa2YyODluazRydmZIVk5YV0lMYkVF?=
 =?utf-8?B?NkZkaDI3Uk1FWGo1bDJHMHVXVEtlM1RKUnJDNkFrdlRaTDJvbHo5SXB3cEtw?=
 =?utf-8?B?c0E4SmhneGhlbFVUS05SWkJHTXNHTFNBNG9OZzFyZ1NadkFwUGYxUUZybGE3?=
 =?utf-8?B?ZkFBVDFocWlCSE9yQng4c2VqbkllVkNacGRVUDJ5d2lFNWY5VVo1dzI4S2Fn?=
 =?utf-8?B?dzA4QXFoVmo5bzkza0xEQnNkMHFwRHRmWWlURkZXcG94SlZtT1JlRzNkQWM0?=
 =?utf-8?B?bzJnRitrQ05rNDRtR2UvS0s3NVF0OVJRdXlEc1R3VnZ1a242VWQrcE8wSHJl?=
 =?utf-8?B?UHd4UUhSelJjSy9KdnhoV25rSFlGVjlvSmZBbzQ2ZGJGRFY0UFk4TW9jMUdP?=
 =?utf-8?B?UGtqSXQxS21Oa1U4YUk5TlVGR2N6dTlqY0FSTzRGWWVicnN2Zm5FNEJUQmIv?=
 =?utf-8?B?Q1BXcHlsYjVVSmdFOTNFZ2tmc0hjSjcxdkhBNVI0YjB1R3hueUFLK2RWMmh3?=
 =?utf-8?B?L2lFbTAwYjEyb2pPWENCY3ZObFYzSVRoMGdxYmk5bThPKzUyc1RHa2Z0QTZP?=
 =?utf-8?B?VG5rekJzZFRLTEY1dlgvbjEzNDJHalBKcDlId1BRalZRRHByQ3hqQ25NRko0?=
 =?utf-8?B?azBOc1ZadlVVRWlJUElERW5rMWR2Z0tHNXhaa3pkYTZqbk9tZVE2UjJiSWtM?=
 =?utf-8?B?TlhyS2FwMXR4TjFEaXZQQUVLcUczQmtQYkh4N290ODk2ZzNVSWw3M08zN3dB?=
 =?utf-8?B?STlFY2YrK0FKQkJqa08vcTJMMlVqakIwU3VVYTRYZmJWK0JIQyszd00yeXFT?=
 =?utf-8?B?V0FMMmQ3Sll3RWszRlVCNmthbGpoS21tQVlNL3dINDhOZUE4RXdJNDZIeXVK?=
 =?utf-8?B?bUdXZWh1OHBwbFk5Y2ZUN1lCdkw5cHE0UXllaHhOSys1QXUvd0d2N3pSS0Vp?=
 =?utf-8?B?cURraGpwQUp5RE9XbENWVm1kN0RYT2NXdzBtU2hzZUs2S0hBbXA0cTYwTEU3?=
 =?utf-8?B?b0dYZ1VFSWc3MzZyQnNGdFRRMXZQMjREdzF5WUtFNWlqSlk2N0JmSmMvL25p?=
 =?utf-8?B?WnU5UW10L3BnPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?U3JZSzZhY1V0SU5yZ2VHM2VVanQ5R1RleTVIQVNEU1FrTWk0TjE3NGRXaWhD?=
 =?utf-8?B?WGFwNUhLMzZBSHU2aERDYXl5aHp4SkNKa0ZrYzhTODJDYVVsQjJPVHE3K3BK?=
 =?utf-8?B?NkJmaUp2ZC9qM1VSU2lNTURhTktwQWdKKzE0K1ovUm81VUFtNE5XcytpVGw0?=
 =?utf-8?B?d0MzQnBleEpPT3lSdDNPSCtUdHlVNlp2dTg4K25rYlVEdm9wNFlwekVxVjNC?=
 =?utf-8?B?NUwxempqVlB5elovbDdaUTBNVER0Q0RnNG4ySG8zS0d6TitnZzk2Nk9sUkNx?=
 =?utf-8?B?enlUakM5bG9tbytsR1NNVXZqdW44SzQ3UzNtWU4vMS91WUpWT20vZTV1ZERw?=
 =?utf-8?B?c1pOSUYwSmo0ODlxYnlqdWc5b1FUY1RmTDNLa1B4OWZPblBzclJ3b0xLem1L?=
 =?utf-8?B?eHY2elgxTVdMZWdCczZ3Z3FDNFh2YWtFWGVQOHdKN2RZN3RIK0VaZ0NkR0VC?=
 =?utf-8?B?VEJjb1RNUTh0a09ZenV3QU5Fa3hGNlVtTGJoR0VvdmJxVXg1ZDdvY3ZaTFdP?=
 =?utf-8?B?RVpBMnpVdisyaEkrOGZsVmdPRWZVKzE4aE5OMmhDUW9VcjBrQ3RVcit0UjQ5?=
 =?utf-8?B?SHMxL2tsdlB2ZTJWQm9GWDZRWmdUam82bEg3S2pDcE9LSmdjblE5NTBVVTFW?=
 =?utf-8?B?eHNVL241OWNhRlBpMFBCNXFkU24yckVKUDJhaXI1RmpUYVB0NEJHNGtub1hD?=
 =?utf-8?B?aThOcVBTRUhxdXpZbjFmdTdVNHJkZk1zMUw4UnVDMHZXRU1FdEFLNEJFTTEw?=
 =?utf-8?B?eUxNT0NiRWM0aHMvakt6Y0gxMUJIM1J6U3V4V1NxQmxlRnJkWEN5UzZLSHBV?=
 =?utf-8?B?R0RlVlk5TnhuVGl3UVZVUUI0Z2ZNM2pWQXlRYk1MVVczSzlnQk1yN25md3k3?=
 =?utf-8?B?MnFaRERoTEpaNld5YU5Yd0NwQXhBVVZZYzFxOVMwcUJweklNY0xvb1Q5ZWZ6?=
 =?utf-8?B?bmQrM3pIZUhIejR4dVZrSFNqUUlMSlhjSTZMWFRhemlGSVlSNXNsUUlUNUtz?=
 =?utf-8?B?VEROUGNVTUIvMnQ1VjRNOFRKL04yd3JKeENDbEIxR3lTNkI0N3gyQ2FjaDdx?=
 =?utf-8?B?RzQ1QnJkbjhCdFA5bWMwM0pXM2NiWlBHSHJSTWVLMk1NdFFjbktBMWZFQyt5?=
 =?utf-8?B?Y1ZkQ2dXNDhYajhpdVFEek11ZFE1TlYvM3JDQW5LVWZWVUdqQklCSFBscmtY?=
 =?utf-8?B?bzJzb25SMTVqNjVyWUs3K0VpTVF6dGFvWmVVM1A0Y1FaVGkxTmVNbmpiT1VN?=
 =?utf-8?B?NVJTRS8rOWxIc2JreTlZT3Z5bnN1Z0F6WTVTcFVnQ1h6SVdjUnE0eEJIVFcz?=
 =?utf-8?B?UStPVW93bkJQNHFzRGtheCtsd05EYzBxWmlIY2hPRmIzTHpqNzR6NFVtWk9B?=
 =?utf-8?B?NGQzbU51dlFkWlF5NU0zNDBGbHpvRGk3dWFaTmxlc203TENtVWV2Nm41elVH?=
 =?utf-8?B?SHpreUFQUDBDellpSHhxOWlRTEtPd3Y1Z0FCUVM4ZTN0R1pramo3Q0dyK2Ix?=
 =?utf-8?B?dlhxSGpZeDd0bm80YkxNVWFiL2dHRG0vT3NVcUtJQm5aODh0L0lSVElTVkpF?=
 =?utf-8?B?d1dSZUUvWkZZSG9ZRUZwUkIzTjBJdXJHd212b3JqaDczQjZSaURJejViYmJo?=
 =?utf-8?B?VjhobUY3R1pWaWI5aXBKU2kyOVkwU3o4QWM3NTcxdTJiYUYvaWNtNUVnTkVp?=
 =?utf-8?B?ck1sQ2RtOVN1YkFncERMa2ZMcVIzaTZXbm1VRWdGQmpRL0tPNVdNTGt3QXZ1?=
 =?utf-8?B?anpIK1VQejVIa2dFbEJGVzVkZGQzbUlsNGluWlJZcHdsUm1iSC9nbVBrUDNK?=
 =?utf-8?B?bDNVbFlDTFVKOERwSnRkcEc5ZHNLbnFwaHJ6YUI0cUdWMnVCOVJTWHRDU0xx?=
 =?utf-8?B?R0ZTcXBuR1JyejB4ZUJTTG82YU05L01QRm85T21PeUxmR1IzTEpIdExrQk5P?=
 =?utf-8?B?RkplMTFlYUQ2UmpOQ21zcVdVQllwQkVQam40VHRlRjJOa0diUzRseEFwdHBu?=
 =?utf-8?B?YWtnNTRxK2xhYVBpSWNZUkpZYjhEWGRNR2s1VHFRYjVsUWJpOXZCK0tnak1a?=
 =?utf-8?B?UzZWY1dIQ1lIQjRnajVJNHhSUzNSbmFOSzVxVkY4OXhPalBKUlFQMFdUNnJq?=
 =?utf-8?Q?d2tU=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <902A8A6D77E1D144BAB9BC7EAB9B4C7A@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e8ffcd90-3950-451d-0d86-08dd942200ec
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2025 02:33:12.1364
 (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: 6QKq5BK9uA1QS1i7qIzatq5BLJUwG/izIvV75bqPizOTDc2RZuIMY4h7IlzwMOQTd60QFnwDtqVyJSwbsDl0HQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8919

T24gMjAyNS81LzE2IDAwOjI5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPiBPbiBGcmksIE1h
eSAwOSwgMjAyNSBhdCAwNTowNTozNFBNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+IEBA
IC03ODYsMTUgKzc5MiwxOCBAQCBzdGF0aWMgaW50IHZwY2lfaW5pdF9jYXBhYmlsaXR5X2xpc3Qo
c3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAgDQo+PiAgICAgICAgICAgICAgbmV4dCA9IHBjaV9m
aW5kX25leHRfY2FwX3R0bChwZGV2LT5zYmRmLA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgcG9zICsgUENJX0NBUF9MSVNUX05FWFQsDQo+PiAtICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdXBwb3J0ZWRfY2FwcywNCj4+IC0gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFSUkFZX1NJWkUoc3VwcG9ydGVk
X2NhcHMpLCAmdHRsKTsNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHN1cHBvcnRlZF9jYXBzLCBuLCAmdHRsKTsNCj4+ICANCj4+IC0gICAgICAgICAgICByYyA9
IHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfaHdfcmVhZDgsIE5VTEwsDQo+PiAt
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwb3MgKyBQQ0lfQ0FQX0xJU1RfSUQs
IDEsIE5VTEwpOw0KPj4gLSAgICAgICAgICAgIGlmICggcmMgKQ0KPj4gLSAgICAgICAgICAgICAg
ICByZXR1cm4gcmM7DQo+PiArICAgICAgICAgICAgaWYgKCAhaXNfaHdkb20gKQ0KPj4gKyAgICAg
ICAgICAgIHsNCj4+ICsgICAgICAgICAgICAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3RlcihwZGV2
LT52cGNpLCB2cGNpX2h3X3JlYWQ4LCBOVUxMLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHBvcyArIFBDSV9DQVBfTElTVF9JRCwgMSwgTlVMTCk7DQo+PiArICAg
ICAgICAgICAgICAgIGlmICggcmMgKQ0KPj4gKyAgICAgICAgICAgICAgICAgICAgcmV0dXJuIHJj
Ow0KPj4gKyAgICAgICAgICAgIH0NCj4+ICANCj4+IC0gICAgICAgICAgICByYyA9IHZwY2lfYWRk
X3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfcmVhZF92YWwsIE5VTEwsDQo+PiArICAgICAgICAg
ICAgcmMgPSB2cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2cGNpX3JlYWRfdmFsLA0KPj4g
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXNfaHdkb20gPyB2cGNpX2h3X3dy
aXRlOCA6IE5VTEwsDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwb3Mg
KyBQQ0lfQ0FQX0xJU1RfTkVYVCwgMSwNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICh2b2lkICopKHVpbnRwdHJfdCluZXh0KTsNCj4+ICAgICAgICAgICAgICBpZiAoIHJj
ICkNCj4+IEBAIC04MDUsMTMgKzgxNCwxNyBAQCBzdGF0aWMgaW50IHZwY2lfaW5pdF9jYXBhYmls
aXR5X2xpc3Qoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAgICAgIH0NCj4+ICANCj4+ICAgICAg
LyogVXRpbGl6ZSByc3ZkcF9tYXNrIHRvIGhpZGUgUENJX1NUQVRVU19DQVBfTElTVCBmcm9tIHRo
ZSBndWVzdC4gKi8NCj4+IC0gICAgcmV0dXJuIHZwY2lfYWRkX3JlZ2lzdGVyX21hc2socGRldi0+
dnBjaSwgdnBjaV9od19yZWFkMTYsIHZwY2lfaHdfd3JpdGUxNiwNCj4+IC0gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgUENJX1NUQVRVUywgMiwgTlVMTCwNCj4+IC0gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgUENJX1NUQVRVU19ST19NQVNLICYNCj4+IC0gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+KG1hc2tfY2FwX2xpc3QgPyBQQ0lfU1RBVFVT
X0NBUF9MSVNUIDogMCksDQo+PiAtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBD
SV9TVEFUVVNfUlcxQ19NQVNLLA0KPj4gLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBtYXNrX2NhcF9saXN0ID8gUENJX1NUQVRVU19DQVBfTElTVCA6IDAsDQo+PiAtICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFBDSV9TVEFUVVNfUlNWRFpfTUFTSyk7DQo+PiArICAg
IHJldHVybiBpc19od2RvbSA/IDAgOiB2cGNpX2FkZF9yZWdpc3Rlcl9tYXNrKHBkZXYtPnZwY2ks
IHZwY2lfaHdfcmVhZDE2LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB2cGNpX2h3X3dyaXRlMTYsIFBDSV9TVEFUVVMsDQo+PiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIsIE5VTEwsDQo+PiArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBDSV9TVEFUVVNf
Uk9fTUFTSyAmDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIH4obWFza19jYXBfbGlzdCA/DQo+PiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQQ0lfU1RBVFVTX0NBUF9MSVNUIDoNCj4+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDApLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBQQ0lfU1RBVFVTX1JXMUNfTUFTSywNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgbWFza19jYXBfbGlzdCA/DQo+PiArICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBDSV9TVEFUVVNfQ0FQX0xJU1Qg
OiAwLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBQQ0lfU1RBVFVTX1JTVkRaX01BU0spOw0KPiANCj4gV293LCB0aGF0J3MgYSBiaXQgdG9vIG11
Y2ggaW5kZW50YXRpb24gZm9yIG15IHRhc3RlLiAgRG8geW91IHRoaW5rIHlvdQ0KPiBjb3VsZCBk
bzoNCj4gDQo+IC8qIFJldHVybiBlYXJseSBmb3IgdGhlIGh3IGRvbWFpbiwgbm8gbWFza2luZyBv
ZiBQQ0lfU1RBVFVTLiAqLw0KPiBpZiAoIGlzX2h3ZG9tICkNCj4gICAgIHJldHVybiAwOw0KPiAu
Li4NCj4gDQo+IFNvIHRoYXQgeW91IGRvbid0IGhhdmUgdG8gdG91Y2ggdGhlIGN1cnJlbnQgcmV0
dXJuIGNodW5rPw0KSXQgc2VlbXMgYmV0dGVyLg0KV2lsbCBkbyBpbiBuZXh0IHZlcnNpb24uDQoN
Cj4gDQo+IFRoYW5rcywgUm9nZXIuDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4u
DQo=


From xen-devel-bounces@lists.xenproject.org Fri May 16 06:20:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 06:20:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986302.1371877 (Exim 4.92)
	(envelope-from )
	id 1uFoQc-00020c-DD; Fri, 16 May 2025 06:20:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986302.1371877; Fri, 16 May 2025 06: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 1uFoQc-00020V-9a; Fri, 16 May 2025 06:20:18 +0000
Received: by outflank-mailman (input) for mailman id 986302;
 Fri, 16 May 2025 06:20:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFoQa-00020P-7t
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 06:20:16 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20618.outbound.protection.outlook.com
 [2a01:111:f403:2412::618])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d29f7d5d-321d-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 08:20:13 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH3PR12MB8904.namprd12.prod.outlook.com (2603:10b6:610:167::9) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8722.23; Fri, 16 May 2025 06:20:08 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%6]) with mapi id 15.20.8722.027; Fri, 16 May 2025
 06:20: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" 
X-Inumbo-ID: d29f7d5d-321d-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=k2Np5no9uGuDHcutzpApYfO9LiyoriaQK3q+HG57l8ubOtbVmuCq5Q1nAmzlKV6Cxf4nIMFME8m0PQIcBM9EUZ5YPkFvtIFv7qcESdowKfP7LDnx492CwuxFlKYA0YlGyLoRxJ3davSTuq2QU4vaKSTMENRM3Wmeyk5rX74IsPwbAYxp0+jG4pmAXbD+FS0bnXiaBEWcR4hTUQOosD4FEQ9BFtE3XdNcvbA3bc89zptxep5iGqNLf1qnOOR0pzS9HEHT7Um6/qrJ/XeJITwsDJqkBwc5GLSvgxCXNKC1JyKnRHGLwIxwEEcVYrcE6X7pDY/tm9oFzLGdXP8Io3m6UA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=D1gER049XH5tfAxH57l+8H5nqgqxlb0iHbjwo8NwD00=;
 b=Ysca3WoFgJOJMMLQ33Gfzb7VOlsqfMWm4n1TULd1sje9otvXDUuxRzd+Y/g4icyUZbhqyOzFB6uOKJnTQP4+loYlBklD4C9DHFS/xoWqRec01pjo+0Os8IMLVs4TeVFg2pvOeYooFyuPossUFwowBfF5GyUf8aF+NVZiGGsCNvbXcXac1B42wiv+YWu7ZKa63PR8uTOIC6TNb1CutnPNrQ/10V52s4zbhdDKPTlWIdXFJV8TilUUnZxgrtwOlMgFgAMdZp3Q7izkflHK0buuH5+ga53fKgvZK9gXC/g/NevrD9eyChy4l5j4lTpt4rkck6t/bZ+bm46q7hG82m0qRA==
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=D1gER049XH5tfAxH57l+8H5nqgqxlb0iHbjwo8NwD00=;
 b=ynbWbbY9OaRn2VRPkoddqQIX5XopuoEvAezZRZHv+pe4ZXmEvj9KjkT5SfbyFb/HZ4xkf2z+M+HIk4AQJG/KY4xPAx26iLIS2aPYBjD6ma6kdcohU1HZGhYt0mgYmxyuY9RheecYEiUEaDjcEMyyLJJnlD4shdfjXk+QVf1Q90Y=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Topic: [PATCH v4 02/15] xen/cpufreq: extract _PSD info from "struct
 xen_processor_performance"
Thread-Index: AQHbrRCjQUXzVZg75kKZW3IeVU/v2LO5SzoAgAv/ooCACgTDgIAFqcOw
Date: Fri, 16 May 2025 06:20:07 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-3-Penny.Zheng@amd.com>
 <829e710d-d257-455a-b4fc-1746119609ef@suse.com>
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=26c142fd-afdb-428e-8017-6090b17d9672;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-16T06:18:47Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|CH3PR12MB8904:EE_
x-ms-office365-filtering-correlation-id: 71a60421-204c-4c67-f967-08dd9441b49c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?M1pNdTFnbnU4UnptOVBMNmZEYndVZ1Q4dDVRcXJiUmk0R2dZMmw1Q0huK3ln?=
 =?utf-8?B?OHZ1U1FIUWdHRDNURzJmc0NHYnhZMlFGTXR5TmhYY1hCb1lHcWFCYkZ2NEtl?=
 =?utf-8?B?dDRUNjA1eGw4ejdJV0lvQyt0dlpxb0IzUFJMbENNc2Y5aUdVRlZGNmdJTm1M?=
 =?utf-8?B?ZnY0RHMwTWpKTlpobUJ0YmltL0tiS2poUXEwZDM3NENwNGQ2UHUxbkkxR3Uz?=
 =?utf-8?B?TGdYL3hCOUl2dHZLN3ZnUmR5dU1Bb3dDS3BvWmp2bUJOYWtyYUlveEZuRm9H?=
 =?utf-8?B?dFJNOVVTTDBIL2dVNjZOUnBkR0JVY1lvS1M1MUJScCtWaTg2N211aHJIS2dh?=
 =?utf-8?B?MzJXdlRUTWpKemlOL1VQbFQwdVR2NXl3VXAyZk1tTi8wQW12Mm5acE5OazEv?=
 =?utf-8?B?L1pYVmlnQnY0TGxRbVRJRUxmY0ZPeVA0SHFMUjlOeks3UlpZSzJhRDdjOE80?=
 =?utf-8?B?TlpPWjlYa1kvdVRyekRXYmNOZlgzcWpxZjBsSTBTMFJLQ3BSd1VIRllpTWdK?=
 =?utf-8?B?dkhVN05idUN4VFFSV1NuRktsSlI0Vkxzcyt4L3JEeld0cFBPck5oOWpmeGRW?=
 =?utf-8?B?VGk2QzV1VmNMV2JEK0R3d3RZWGFtS1JYcGg2SlpVckw4Q0pnSVZ3Yjh1eWF2?=
 =?utf-8?B?YSs3ZitOeFZvR1pOY21mVURVeWhOZWpJUkFuUnEzeXYxWUV3YUNjNmVQOWhY?=
 =?utf-8?B?bFQvUmtJSFB4aVBOSk9FUHZpbFhtUFJpd09nUUZURVh4cmRnSHU4MGhMNjZx?=
 =?utf-8?B?SlEvUTV0d3dFQVpoeTFUTUxOY2V2M1VOZ3NhY20vTU92T0I3ZXZ3SzhaV1pr?=
 =?utf-8?B?OFZEQnZHbzBvUW1QaUtOektNZ0hlNXc1ZURpdUFRc0daUzdnVjFQVnAydDRt?=
 =?utf-8?B?UkF1MnJxNDVtbXpzcERTY3htNFRrc0hLUkE1RDY0a0R3MkRYMmgwUERiZ3pz?=
 =?utf-8?B?bXdySmJGMm9rRjk0NjgrRkhXZ21ubmwyQlJ1dG14VHB2c1ZFb1N3WnVIbUpv?=
 =?utf-8?B?Tjg5WDQvK2pHQnZpWEk3ZVFCYVpZdFpGcXVUODJSN0hJM2Uza2RjOHJmWGZ6?=
 =?utf-8?B?UWtuM2tLeUxiSjJ3a0d6bUJPQ1JEN3ExQ01OZWlsbXgvbGNhSUcwalBwU2Iv?=
 =?utf-8?B?SEVNenNmUmRVOUN3WStxRjhqY1V5Slh4QkpoQzcvbCtXSFc2YkZzSUZMZ3JZ?=
 =?utf-8?B?aEVFK05WRm9McE4wS3Q1akZtRU44OWVTaGVIN2FRekwyMHk3dkp2bWh0VTQ2?=
 =?utf-8?B?OGJVUVFXdzM2U0VZMGc2Y29uQ1N4TTlaRU52SFZWdmxibytxMTF4SUZWRXU0?=
 =?utf-8?B?bXA2VjFscUE3eU9ZT3ZwUE1IWWE4SzNnQWQvdCtNUGJrNkp1cGZhVERXQkcz?=
 =?utf-8?B?YU5IQjNZMHJqZDE2cUp2cWorNnRIbHUyaUtid1dzZzU0VzR4SXh6bklLd1Vz?=
 =?utf-8?B?V0ZySzlId3psMll1UTZFOVlxN2FzM1p4eGYvT3U5NlZTRFE1anpZWDhMTTQy?=
 =?utf-8?B?NjFPcFpWOXJlV3R1b0twcC9zaFhzQWEwdDhaZHJQakNZQVRaVmI4L0hlN1p4?=
 =?utf-8?B?UmlVdXk0WlNMTFI2N0JOVk1tbjhCQ0pjNVVSZXB1UkFtSC80QzFEc296NTFx?=
 =?utf-8?B?NFdZR0FDNngzL2MrUmhFd2FhN2dxUm5DcjYrSmhjaGx0dVcyQ2IyTERaODRD?=
 =?utf-8?B?ODlYQkRSMWo0ZDlGMVJTQUphRzBnMDlrYjVNbUw2VDdsOTIvb3YrNnJjZHlw?=
 =?utf-8?B?a0VSZnJzbXhLbkl0Sk1DcENEcXNKRWhyVVMzdmRjVkFXWFplYjZDWnZhSUMr?=
 =?utf-8?B?d3ZlMUd1UXVqOTJweWpJZ0dnZEJvNjB0YkFONHM3YUhDclg2b0JuclIwRjVJ?=
 =?utf-8?B?ZW5BemNiejdlbm5BOE1jOFhUYzFpcGNzOWpFWWlqbWx5UHhsV21BRmg2RXhJ?=
 =?utf-8?B?YzVLUVZHMjRLS3IyVFZDVzA2dWgybUFyeXNFOHhGUEtmUHd5dkx0OWtFVGtw?=
 =?utf-8?B?OFEzQnhWMTVBPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VHlsbElUSkY2Vjl0YnNFbHVoUVdYZU56UjlITVBINGNIbHlOMzVvbVVONGk4?=
 =?utf-8?B?ZnpFNG1lVGdHL3Z5bEZkVUFIdHZsdUxyamN4QnZDbWdCZ3E4UWVhQzFLcWh6?=
 =?utf-8?B?N2NhSzhjSDl4MjBMbUwxT3Qzc2hrTkJhR1BBL0JGWllQRHVia2N0dzdQV2p5?=
 =?utf-8?B?eE10dTlkem1JMTQ0aWo4S0VoVjNsNGR2aEJBR3NHdXp2WCtQTW90b254MitY?=
 =?utf-8?B?Q0JXUTVRcGZSSm5JOFFhQW4xbW81OXVYcVFlWGVkWU5jalA5WDJzZUtZbTdM?=
 =?utf-8?B?OUlIYlVNaHlJNFNUdVVyQmpVaHBQcXJnNWg3ZzNzSGtUOUJqb0FuaFlFbDg0?=
 =?utf-8?B?UDFnWXhmdlk2OEtGOFlHM2ltZ2RDRTkvS0c0Vmk1dU1KcndxNDhpMGFERmdC?=
 =?utf-8?B?Y0RPc3plWW9aUUVRZXlEZ00vWWVDZjNHMTJwZnhVekFNS0ZkTW0yVlFkZXZr?=
 =?utf-8?B?WXJTb25vOXNJMVd5cHF3NU1qZHVUSjZpSXJ0YSt0ekFVdXdlNVhhTkRQdllB?=
 =?utf-8?B?cHJibGNxTUw5cTJPb3pGQ1FCUkNOVUNkaU1ORmtPa0lSazA2UGNXcGNwWE5j?=
 =?utf-8?B?akhYRjRmZlVoZG1ydjhvUHAvbUw3cVU0YW9PZGtMSDdSc0E5enlPQ2QzeEF2?=
 =?utf-8?B?QXJEeENZb3UzR1F5aWFRcUFMTUtRLzgrcm5NblFhRFlpWmhwZHlOZUdTRU00?=
 =?utf-8?B?L016SlN0eUNPMU91RS9VYUFDeCtpR005ajZtOFhqRlM1KzVOZDIvTlY5SThD?=
 =?utf-8?B?cVh1aTNoWEROWXBiUzA2aU41Z0V0MFhBLzIwV011QXhaSkJPT3NScGdOcmJ5?=
 =?utf-8?B?a1NOcVpaRENucWVRaGtoYi9sWFppVFVvVEpzNlNrMjNGcGNJZWtVU1lxMUdB?=
 =?utf-8?B?bzd5bHNPYTRYbEN3RXd6UVN2M0VTWmJkUmhjRUpoYWZuMXMzMHF1RU94aGFL?=
 =?utf-8?B?VUVESWMraHJEV3FKVnBEUjBmNUo3eGFrMGlnL28wQmUvN0d4MllpWWdxWU9k?=
 =?utf-8?B?U1UxUGEzZUo5bm5CYkFhTFZvcjlZN1BOK2YzV1M2RHBxZmdBTFFvNzB3a0pN?=
 =?utf-8?B?aisvc2xnWUpWRkowSCt5Q2JNMmNYWS8xZEtBb1kyRnY3OWdPK3RkS0xLT3Rz?=
 =?utf-8?B?RWllNmUySXRibFdqR2R4TSsxM1lDR0oxYjZQTTFzeHZ2VGs2cjBZTDhkRFow?=
 =?utf-8?B?T2cwQUpFNHpQOHhpdG1kYnFlelMvWXRzOTNoNy9tUUNtd0hPVHpZdE8vNUVu?=
 =?utf-8?B?blRTK3Q4Z0NaZ2VEdWJaK0U0MGFzay94aEVQUEZpUnBlSkZpazcxZnM5TmdU?=
 =?utf-8?B?ZlFTbjFva0ZKcGJBdW1wc2lrTStWY3FXN1MvZ0kxWng5QmlmOVZpSnBLMW9v?=
 =?utf-8?B?S2NsTlVia0JxYjlkdE51WHAzTVFSUjJZWUE5S1FuRmNsMzU1bTdNZTM5UUY2?=
 =?utf-8?B?cXQ2ck81Z2FOczNZUCtmNVJhZWdxZ3NQV21OTzVpK3lYM25lRy9ndDlFREkv?=
 =?utf-8?B?RTE4RXp1a1p4elM4U0RSYlJGaHVyaVNsTFJjK3ZITjlOblNQV2VWeXV4Lzd3?=
 =?utf-8?B?UTRaTkc5VURtOVNtQ1dpYUxJcFludE1mSlpBZkJXNnIyMWxFZm83MUFBQXIx?=
 =?utf-8?B?TGZROU5qWUppWHF6bXQvTDU0ZGY0cEoxVm1LOHdwbVIzT1NYZm8rQXFSbjM3?=
 =?utf-8?B?M3NodHExVU9Pa0QvY21wdlZhdzRpNHFmRTdWV3ZyU2cxKzFaaisyZXVnRE5C?=
 =?utf-8?B?NGNsUmY0UzNYRnpHT2J1ZEYrOExFbm5LbEMrN0cwdmtjT2R0aG1iME9MM05T?=
 =?utf-8?B?MWtpeVltMnlSbkluKzRaSXpTdlRGeVhoNVZubFNZZURaQzNaZWtxUlpMRkh4?=
 =?utf-8?B?ZDIwcjVCVUUwd1ZVcXpsVWJvbmdxRzhiN2lKV21FdHdzcWRsSUhzcE9jYnA1?=
 =?utf-8?B?NjkvZWVzKzI0Y0ErZFVXWGczMlc3ZEtxR1pjVVk5SzF1Q1UxeGpJbmNTU2R4?=
 =?utf-8?B?ZXpFRHlrWnFiTndGL29GRWpCay9RelYyV3h4dUwzNy9WMmJIV01wdUxmT3dM?=
 =?utf-8?B?WnVhRW9rZWQ1V3U0UHgvKzVqZCs4T3FjcmJ5QVRRYTAzZitRU2YwcEh3aE9j?=
 =?utf-8?Q?lwoY=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 71a60421-204c-4c67-f967-08dd9441b49c
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2025 06:20:08.0204
 (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: hvan8mZXu0Ka+XYSxiA2pSJsTN7Ec5qx+o1XMVerNk8Cgxvc2Wv00qnZbqdHM+uugN6mClW2yP5m50BbcdzLHg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8904

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IE1vbmRheSwgTWF5IDEyLCAyMDI1IDEx
OjQ1IFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+IENjOiBI
dWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5j
b29wZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJhcmRAdmF0ZXMu
dGVjaD47DQo+IE9yemVsLCBNaWNoYWwgPE1pY2hhbC5PcnplbEBhbWQuY29tPjsgSnVsaWVuIEdy
YWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2VyIFBhdQ0KPiBNb25uw6kgPHJvZ2VyLnBhdUBjaXRy
aXguY29tPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPjsgeGVu
LQ0KPiBkZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY0
IDAyLzE1XSB4ZW4vY3B1ZnJlcTogZXh0cmFjdCBfUFNEIGluZm8gZnJvbSAic3RydWN0DQo+IHhl
bl9wcm9jZXNzb3JfcGVyZm9ybWFuY2UiDQo+DQo+IE9uIDA2LjA1LjIwMjUgMDk6MjIsIFBlbm55
LCBaaGVuZyB3cm90ZToNCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJv
bTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiA+PiBTZW50OiBNb25kYXksIEFw
cmlsIDI4LCAyMDI1IDExOjMyIFBNDQo+ID4+DQo+ID4+IE9uIDE0LjA0LjIwMjUgMDk6NDAsIFBl
bm55IFpoZW5nIHdyb3RlOg0KPiA+Pj4gLS0tIGEveGVuL2RyaXZlcnMvY3B1ZnJlcS9jcHVmcmVx
LmMNCj4gPj4+ICsrKyBiL3hlbi9kcml2ZXJzL2NwdWZyZXEvY3B1ZnJlcS5jDQo+ID4+PiArICAg
IHsNCj4gPj4+ICsgICAgY2FzZSBYRU5fUFhfSU5JVDoNCj4gPj4+ICsgICAgICAgIGlmICggc2hh
cmVkX3R5cGUgKQ0KPiA+Pj4gKyAgICAgICAgICAgICpzaGFyZWRfdHlwZSA9IHByb2Nlc3Nvcl9w
bWluZm9bY3B1XS0+cGVyZi5zaGFyZWRfdHlwZTsNCj4gPj4+ICsgICAgICAgIGlmICggZG9tYWlu
X2luZm8gKQ0KPiA+Pj4gKyAgICAgICAgICAgICpkb21haW5faW5mbyA9IHByb2Nlc3Nvcl9wbWlu
Zm9bY3B1XS0+cGVyZi5kb21haW5faW5mbzsNCj4gPj4NCj4gPj4gRG9lcyB0aGlzIG5lZWQgdG8g
YmUgYSBzdHJ1Y3R1cmUgY29weT8gQ2FuJ3QgeW91IGhhbmQgYmFjayBqdXN0IGENCj4gPj4gcG9p
bnRlciwgd2l0aCB0aGUgZnVuY3Rpb24gcGFyYW1ldGVyIGJlaW5nIGNvbnN0IHN0cnVjdCB4ZW5f
cHNkX3BhY2thZ2UgKio/DQo+ID4+DQo+ID4NCj4gPiBJJ3ZlIGNvbnNpZGVyZWQgaGFuZGluZyBi
YWNraW5nIGEgcG9pbnRlciwgdGhlbiBtYXliZSB3ZSBuZWVkIHRvDQo+ID4gYWxsb2NhdGUgc3Bh
Y2UgZm9yICJzdHJ1Y3QgeGVuX3BzZF9wYWNrYWdlICoqZG9tYWluX2luZm8gPQ0KPiA+IHh2emFs
bG9jKHN0cnVjdCB4ZW5fcHNkX3BhY2thZ2UgKik7IiwgYW5kIFhWRlJFRSh4eHgpIGl0IGluIGVh
Y2ggZXhpdCwNCj4gZXNwZWNpYWxseSBjcHVmcmVxX2FkZF9jcHUoKSBoYXMgYSBsb3QgZXhpdHMs
IHdoaWNoIGNvdWxkIGJlIGEgZmV3IGNvZGUgY2h1cm4uDQo+ID4gU28gSSBjaG9zZSB0aGUgc3Ry
dWN0IGNvcHkgdG8gaGF2ZSB0aGUgc21hbGxlc3QgY2hhbmdlLg0KPg0KPiBJIGZlYXIgSSBkb24n
dCBzZWUgd2h5IHN1Y2ggYWxsb2NhdGlvbnMgKG9mIHNwYWNlIGhvbGRpbmcgYSBzaW5nbGUgcG9p
bnRlcikgd291bGQgYmUNCj4gbmVjZXNzYXJ5LiBBZmFpY3QgYWxsIHlvdSBuZWVkIGlzIGEgbG9j
YWwgdmFyaWFibGUgb2YgdGhlIHNwZWNpZmljDQo+IChwb2ludGVyKSB0eXBlLCB0aGUgYWRkcmVz
cyBvZiB3aGljaCB5b3UgcGFzcyBpbnRvIGhlcmUuDQo+DQoNCg0KYGBgDQogICAgICAgIHN0cnVj
dCB4ZW5fcHNkX3BhY2thZ2UgKmRvbWFpbl9pbmZvOw0KICAgICAgICBzdHJ1Y3QgeGVuX3BzZF9w
YWNrYWdlICoqZG9tYWluX2luZm9fcHRyID0gJmRvbWFpbl9pbmZvOw0KYGBgDQpPaCwgcmlnaHQs
IEkgY291bGQgY3JlYXRlIGEgbG9jYWwgdmFyaWFibGUgdG8gYXZvaWQgbnVsbHB0ciBpbml0aWFs
aXphdGlvbi4NCg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Fri May 16 06:55:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 06:55:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986328.1371887 (Exim 4.92)
	(envelope-from )
	id 1uFoy9-00062V-UH; Fri, 16 May 2025 06:54:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986328.1371887; Fri, 16 May 2025 06:54: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 1uFoy9-00062O-RK; Fri, 16 May 2025 06:54:57 +0000
Received: by outflank-mailman (input) for mailman id 986328;
 Fri, 16 May 2025 06:54:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFoy9-00062I-43
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 06:54:57 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ac207467-3222-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 08:54:54 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5fbf52aad74so5485062a12.1
 for ; Thu, 15 May 2025 23:54: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
 a640c23a62f3a-ad52d4d27e8sm102157166b.174.2025.05.15.23.54.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 23:54: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" 
X-Inumbo-ID: ac207467-3222-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747378494; x=1747983294; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=H+ueh+xRWH9F0Fp0CCy3syRXy2wWNOh7EahesQF6JGw=;
        b=C9USGKREEeGaTgDmHeJZBqbRvZRonGMd+yhv1fZ+WJcGZlpOL5msm3idDZ/CCuW1y9
         wk1ghCWyDoZ/+rFPEjA2PPVey/Qgj5+5Ctnf7VycP9lBka4spGggpklMZdlxGWEvx1zG
         0VXK4lYFXBTPN0+j2CMNNVYH1oLE7sF/UyhQiqv0HhU+hAoTHNUqFkVk6ecQlEbDvbEb
         FchS8FnJqa+KcjVLnzHZ30GSrysU7n2bSMzQjyLSFKu94ZlX8RAF2EFnDXSyckgDawMh
         pjqObBtQAyekZwXJhdvTeC5AanqukhYZ43IhZQjCw9Z6OPHf43RmjrNMAMwaqJO+0ZoJ
         aLyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747378494; x=1747983294;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=H+ueh+xRWH9F0Fp0CCy3syRXy2wWNOh7EahesQF6JGw=;
        b=VraKrLt+6npO1SXQZebBX7SDy7G3PsWR/6HJSd+g27BmB6El4kyNVrGcj+zc8fKBGI
         uH6RipSH0oN34qD6BGr2qim04aH+sbiFHfLCbMPZOp9jTA7f30BBbAkX3VdwGQ3J6w7J
         gq/8DPOhPuDdUzxapUp4Ertc2usDplvrwmYcPKkq4UwtfK3t9rOpJeNfvZMmbGejRPkn
         fErm54mzghVLDep+H0CC4PEjOBe42YUyFb16Tr1un2g3zMRbOfHZyhYVRTUclG84uHVR
         HhOAwrz4BUPfPzmz2+FQc55LC3K+w+sWILxmVPcotiJ0Q7MOccKH91twFmiMIUTBqywF
         4xEg==
X-Gm-Message-State: AOJu0Yxr3hZMI1Rv1UVQlLeAdNpG30CkYubibt08hv8xs5HVKooHYhYn
	4PwMRV29AmXY8lRubHqG32N/+Qu78yXzIEGd7KNfnYV5h2Oq2teemD3/JSoLOvGiGQ==
X-Gm-Gg: ASbGncvLqDmnhFxk4iSS+vQiEjQ7h59vat6yUwDG4QsOIBbuBq0+5+3VSDAViunem5c
	IXoZR1yzWtrKmy5ts4kjOuZsTSTrbq/rtanfWhYwcA1Eqdp5RfDa0m9cMZpML7aWfxy7uWwaSRY
	K+rftKUDitt98MWj3AefKcTGoDJq0qmimSAP2Dfr136m5/d9V5A8GVxlh8YvuWfSzqOtontdq4z
	eSaKcowH2VyI06Cr/7sz0bwRb23LzO413owInfl/I4VoAcdzsn2Ailps7v4QTMQmoSDueIHDe1n
	bDJ7ZG9RZ4tn8Ozmx7lSS79qTnGK1yoyIWqggpM3qXkulhxmvYAkBc1QLkutJRtwbjaUu0uz5rk
	hgwLn/wDGXNJSg1rb9XLDLi8N5QHtCwBl/uHeeES4UitguFc=
X-Google-Smtp-Source: AGHT+IHlZHaWe4BLNCVr+ft24X9TYMIVhcZ4UNBWRInFxrljBHnZgwBzW6HopMxyADLwpcyBgryBtg==
X-Received: by 2002:a17:907:c21:b0:ad5:1b14:15f4 with SMTP id a640c23a62f3a-ad52fbfa34fmr171977566b.25.1747378494152;
        Thu, 15 May 2025 23:54:54 -0700 (PDT)
Message-ID: <2032431f-fa8b-47ec-8879-29baadd266bd@suse.com>
Date: Fri, 16 May 2025 08:54:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/HVM: restrict use of pinned cache attributes as well
 as associated flushing
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Wei Liu 
References: <42d40da1-bc38-82fb-154a-e1fc876b0c24@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

On 15.05.2025 12:04, Roger Pau Monné wrote:
> On Wed, Mar 22, 2023 at 07:50:09AM +0100, Jan Beulich wrote:
>> We don't permit use of uncachable memory types elsewhere unless a domain
>> meets certain criteria. Enforce this also during registration of pinned
>> cache attribute ranges.
>>
>> Furthermore restrict cache flushing to just uncachable range registration.
>> While there, also
>> - take CPU self-snoop as well as IOMMU snoop into account (albeit the
>>   latter still is a global property rather than a per-domain one),
>> - avoid flushes when the domain isn't running yet (which ought to be the
>>   common case).
>>
>> Reported-by: Andrew Cooper 
>> Signed-off-by: Jan Beulich 
>> ---
>> At the expense of yet larger a diff it would be possible to get away
>> without any "goto", by moving the whole "new entry" handling into the
>> switch(). Personally I'd prefer that, but the larger diff may be
>> unwelcome.
>>
>> I have to admit that I can't spot what part of epte_get_entry_emt() the
>> comment refers to that is being deleted. The function does use
>> hvm_get_mem_pinned_cacheattr(), yes, but there's nothing there that talks
>> about cache flushes (and their avoiding) in any way.
>>
>> Is it really sensible to add/remove ranges once the guest is already
>> running? (If it is, limiting the scope of the flush would be nice, but
>> would require knowing dirtyness for the domain wrt the caches, which
>> currently we don't track.)
>>
>> This is kind of amending XSA-428.
>>
>> --- a/xen/arch/x86/hvm/mtrr.c
>> +++ b/xen/arch/x86/hvm/mtrr.c
>> @@ -589,6 +589,7 @@ int hvm_set_mem_pinned_cacheattr(struct
>>  {
>>      struct hvm_mem_pinned_cacheattr_range *range, *newr;
>>      unsigned int nr = 0;
>> +    bool flush = false;
>>      int rc = 1;
>>  
>>      if ( !is_hvm_domain(d) )
>> @@ -612,31 +613,35 @@ int hvm_set_mem_pinned_cacheattr(struct
>>  
>>                  type = range->type;
>>                  call_rcu(&range->rcu, free_pinned_cacheattr_entry);
>> -                p2m_memory_type_changed(d);
>>                  switch ( type )
>>                  {
>> -                case X86_MT_UCM:
>> +                case X86_MT_WB:
>> +                case X86_MT_WP:
>> +                case X86_MT_WT:
>>                      /*
>> -                     * For EPT we can also avoid the flush in this case;
>> -                     * see epte_get_entry_emt().
>> +                     * Flush since we don't know what the cachability is going
>> +                     * to be.
>>                       */
>> -                    if ( hap_enabled(d) && cpu_has_vmx )
>> -                case X86_MT_UC:
>> -                        break;
>> -                    /* fall through */
>> -                default:
>> -                    flush_all(FLUSH_CACHE);
>> +                    if ( is_iommu_enabled(d) || cache_flush_permitted(d) )
>> +                        flush = true;
>>                      break;
>>                  }
>> -                return 0;
>> +                rc = 0;
>> +                goto finish;
>>              }
>>          domain_unlock(d);
>>          return -ENOENT;
>>  
>>      case X86_MT_UCM:
>>      case X86_MT_UC:
>> -    case X86_MT_WB:
>>      case X86_MT_WC:
>> +        /* Flush since we don't know what the cachability was. */
>> +        if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
>> +            return -EPERM;
>> +        flush = true;
>> +        break;
>> +
>> +    case X86_MT_WB:
>>      case X86_MT_WP:
>>      case X86_MT_WT:
>>          break;
>> @@ -689,8 +694,12 @@ int hvm_set_mem_pinned_cacheattr(struct
>>  
>>      xfree(newr);
>>  
>> + finish:
>>      p2m_memory_type_changed(d);
>> -    if ( type != X86_MT_WB )
>> +
>> +    if ( flush && d->creation_finished &&
>> +         (!boot_cpu_has(X86_FEATURE_XEN_SELFSNOOP) ||
>> +          (is_iommu_enabled(d) && !iommu_snoop)) )
>>          flush_all(FLUSH_CACHE);
> 
> I think it would be better if we could add those checks to
> memory_type_changed() rather than open-coding them here, and just call
> memory_type_changed() then, which would also avoid the goto AFAICT.

Hmm, with this last remark, what does "those checks" cover then? I first
read it as meaning the conditions in just this if(), but the "goto" is
needed for a different reason.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 06:58:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 06:58:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986336.1371897 (Exim 4.92)
	(envelope-from )
	id 1uFp1m-0006bw-C3; Fri, 16 May 2025 06:58:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986336.1371897; Fri, 16 May 2025 06:58:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFp1m-0006bp-9H; Fri, 16 May 2025 06:58:42 +0000
Received: by outflank-mailman (input) for mailman id 986336;
 Fri, 16 May 2025 06:58:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFp1l-0006bj-TL
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 06:58:41 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 33063bfd-3223-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 08:58:41 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad2452e877aso271414766b.3
 for ; Thu, 15 May 2025 23:58: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
 a640c23a62f3a-ad52d4395d0sm101717166b.114.2025.05.15.23.58.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 15 May 2025 23: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" 
X-Inumbo-ID: 33063bfd-3223-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747378720; x=1747983520; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mhHzUW5qreKMj8C/BBkmNTtLljVXYRajZEMEwIYR/gs=;
        b=A06zAz/ZhxkFF7+oYxi85RA/c91gbT24pdWRwH4LwDdp83+sWrCK6cwfnYsBO74MtH
         olcTcE4n5UgG1MxeNRF/PPeo/0yr9OyX7hvnjGOs4EdYgA7oahPXIsxYuChylZcV41Wa
         zPW7/BJ/USQ7sdIOP4PMJ6kwY45L1s2gDr8BTWEonND5ivNGqW78EBSvVlqivlIKuvXH
         3y0343snD5Mglvwy8A/Fig+QhrfN0Osla0B9ebhv9cMoWEWQ+tMjHJ2xIzVAp53YTjfL
         4InMy9mAHmCKLGR9R3Ayartk7wDSvIL7CDwer3OqwKtVwllWdnIpAmGtS2ZSE+VHbr/X
         f01A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747378720; x=1747983520;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mhHzUW5qreKMj8C/BBkmNTtLljVXYRajZEMEwIYR/gs=;
        b=gGSR+vMMJVHZ6FEFcsqE9mCdwaQm+jF5hG2zXHWjCAvVkIxPcilC3/JSPp7TTk0KXa
         BqGxPj9M2ZqNX4J7WLVzOXSal7Fr+jn8h2Ct19nw0Y+PBsjBwHGSgnUx6erpvXZy8w7X
         6aqK9PI8jDe9sZlyxeYtyM1kWaxJbl0Zwf0ITg3CWL5ouGwq9eLodnspdx77hVe/zwLr
         k4JhO3k+jx9kguNLI2RQ6NjIX5hRykMJ8CLem18MqWPZwdUl8C0DpoEDpy06g5PAk3SS
         umqT6eBnKENexUfbEeCGBHGOWR4ZvBVK5K7jfklVNFlnNe3CvSGRAiKdkL2EServEMcA
         zRfQ==
X-Forwarded-Encrypted: i=1; AJvYcCVz+qZC75f0nnc3JKJ+fbDJvRKQU4dwekkVbzifCSlhQu6qH2IpnayIpxQOShspayvxRXUfQ94Fvb4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyCZvZ62UhYp8IROMmFvdxZaslx1Ruc3j/07EQy6RdEaLRzDV77
	tSLFm2IQCs5tGtYoAgdyAUZ8ZT1HFtEPPURpLWMz+qDNvkuqDVLtG7FvaKbEAFHD3w==
X-Gm-Gg: ASbGncuTORQt5O7ICfYYkBUJQP+KyPsEOYYu4I/a1Ds29XX1uvNqxp3DdxzYze9p4iH
	W9NEJ1v6WEun1t/WjDXFTmS7G+UeNTunDi6MFXLB88g0Yq/+gAwyBKj7iOWpfhmJTVSHhz0BIHJ
	E8GTVjpNTOtapuNXqRQDjYHXfehtduVm7TgxBPbmUD4kNWTJdq9e+QghVkjtLRmeH0NmUctI/PR
	47i4d+OKJSucd7TNNUnHmply9TLripHpLX5k+wSXPS+yDH0wDBCLHsw5UL6vlzdczBjp9w/+Cgf
	bJ1cdkNjEUhnAU0GhdytUTZlET0QuQ0pwF99l0X/5G51v24hRUTST89SFLTb0ogfCt8V83IJJbn
	tH5wYEzAMjrQT005svAtZDdfUGj3t5wz1JFvZTF7UOi+fdGE=
X-Google-Smtp-Source: AGHT+IHOAx3tt8Q2meyMwbignKMpEcTOs2MjpAnMHsW8Upqe+TPueXfJOFvCgH6tQO++tswBVJPcCQ==
X-Received: by 2002:a17:907:7da2:b0:ad5:2656:ee58 with SMTP id a640c23a62f3a-ad536dcd6e9mr115686166b.43.1747378720530;
        Thu, 15 May 2025 23:58:40 -0700 (PDT)
Message-ID: 
Date: Fri, 16 May 2025 08:58:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/9] x86/mtrr: use memory_type_changed() in
 hvm_set_mem_pinned_cacheattr()
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-6-roger.pau@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: <20250506083148.34963-6-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.05.2025 10:31, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -605,22 +605,8 @@ int hvm_set_mem_pinned_cacheattr(struct domain *d, uint64_t gfn_start,
>  
>                  type = range->type;
>                  call_rcu(&range->rcu, free_pinned_cacheattr_entry);
> -                p2m_memory_type_changed(d);
> -                switch ( type )
> -                {
> -                case X86_MT_UCM:
> -                    /*
> -                     * For EPT we can also avoid the flush in this case;
> -                     * see epte_get_entry_emt().
> -                     */
> -                    if ( hap_enabled(d) && cpu_has_vmx )
> -                case X86_MT_UC:
> -                        break;
> -                    /* fall through */
> -                default:
> -                    flush_all(FLUSH_CACHE);
> -                    break;
> -                }
> +                memory_type_changed(d);
> +
>                  return 0;
>              }

Hmm, so your consideration to avoid the "goto" in my patch was perhaps this
part of your change, where you expect the "return 0" could then stay here.
Maybe. However, you removing the switch() means we'd then also flush in
cases where currently (or with my change) we avoid doing so.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 07:00:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 07:00:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986343.1371908 (Exim 4.92)
	(envelope-from )
	id 1uFp3o-000860-P9; Fri, 16 May 2025 07:00:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986343.1371908; Fri, 16 May 2025 07: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 1uFp3o-00085t-KW; Fri, 16 May 2025 07:00:48 +0000
Received: by outflank-mailman (input) for mailman id 986343;
 Fri, 16 May 2025 07:00:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFp3n-00085n-6U
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 07:00:47 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7d839c0f-3223-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 09:00:46 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ad23db02350so333165966b.1
 for ; Fri, 16 May 2025 00:00: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
 a640c23a62f3a-ad52d04b08bsm104613566b.13.2025.05.16.00.00.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 00:00: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" 
X-Inumbo-ID: 7d839c0f-3223-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747378845; x=1747983645; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=T/Tv9B5GhecA35qF0zqlg0woin4T7hWRvPEm3cJfOQY=;
        b=RGFDusls9F6bJpc7m6Gg2uFQDOgOdwtBdtJjWZQ20kB8ykM6pBDCW7FNJBSfbhfq+a
         BIcHMWtQcHedMid0b59+A7lfY6ACaVwC7wRo3d5PdpK4EMMXsG/aNAYYjLXKcBrPFpD1
         hB1r0mZoga0oeRuPoGtE8LnaxcwSvCzL803Dv6OY84g0nVuFdpToe1ZJUAMe8Ag3K6v4
         wxVzJvQlh4wZpEcma/rItNbJn91FZ4TSWJRTQjpEsm2G4ATx4mzQZwZqdXzw9v0BUKD8
         mnqpeeCH+Kwl8cUOZFGTSEyYk4tTmKqP1FYT0S7XtsSJDegar71RL3rax0Gcubz5Rcq5
         KoYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747378845; x=1747983645;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=T/Tv9B5GhecA35qF0zqlg0woin4T7hWRvPEm3cJfOQY=;
        b=wcejfPW2yxZj5w2zsexvIYBoOv3zlxv3gFYVE91XB5e5yb1Li/zXkwXlo18qtnpfda
         IKk24nekDY9xQ7miYYGhA3+Uw/YtekvZpJfvtYpapsUfjyd85gtWwyaoehfIGcf0L21+
         q4+wjqycPNNaCqMNH9GB3aiDvhCqXcNYKkASyflWHEKYCVthR2Uhpv1+5DSipsmfrubj
         0FuRlfKs3dKygH0ez+eeckQAGrZYV/yI5knzbmp2vACSvUKOoux6JOeeNSMroOE+zOft
         yFtgCEx7jIDfYS59eLOdSwQLqrs4xj8D2whJ0Mk6WNyvhd4L8pYln074H+y6f8EnkGLr
         +fKQ==
X-Forwarded-Encrypted: i=1; AJvYcCWxSQZ2YjTeLQAwdySh9k3GhVlErQo6NxC/LL+e9Cu7XJdggCP/c4SZnWUFZxB4oXYyj3YTY1YQQy0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxUW8cNsBOqk1Rf7l+6pMftNbvf2ocYOK3zDp8QW6X7e1SyCUZ6
	1YQ+1d9ppx3CPtAoeo6OKg1LVsS7Rn+ZN6I4aLuDOxaB5TQ6alKOfVAwy8TryEJehZ65jsNjYAg
	lQkc=
X-Gm-Gg: ASbGncseCrefrWgIGBzZ/ua9ggMT7R9jTKwclMcy5xcLOFcCiWJvMNd1aD/T/4dbkFc
	e3kJfeZL6kk03JXt6PlBCygiyX8teDOScl03ylh2c+IrLB0m5dBvBh7+8oQuUMPrYS7+BW1Skym
	fcHY0oeaidSaFs8/p8dt83D5t7ntjPn6HZaFEyITClPDciZ1duHDF9HWAzTNijQBZoz2znyMVeQ
	2oLvEAOMnaMOvw3DFk/XIySOLCzTsJel4dyXx8NGCiOCg8qvhAHP1OcDMoeTKTq7v1h6bMzhgIh
	3SQUwTCRX5jFztYE9vn5NeZxkMgy57aod4W+L8GGdRaryJeXjd/tXKkS3ObSRf23ExK8dpOLVCa
	YBKd3ZPwgrXr/BXJNloM7rdXWS+Y9nRLfRgPa
X-Google-Smtp-Source: AGHT+IEfMcATbyC8N5V8tAl79JlqcWUFJNlOMkTT0Sdq4guNUqgAT22I01qYOiXYrBKvFQ8OQbGkPw==
X-Received: by 2002:a17:907:1c0a:b0:ad2:38e3:2919 with SMTP id a640c23a62f3a-ad52d45c75cmr233992866b.7.1747378845272;
        Fri, 16 May 2025 00:00:45 -0700 (PDT)
Message-ID: <91058f6f-0b87-4958-aa09-749df4de3a9f@suse.com>
Date: Fri, 16 May 2025 09:00:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/9] x86/mtrr: use memory_type_changed() in
 hvm_set_mem_pinned_cacheattr()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-6-roger.pau@citrix.com>
 <853ffc16-f14b-44fa-9e71-4fae8377fa95@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

On 15.05.2025 12:22, Roger Pau Monné wrote:
> On Mon, May 12, 2025 at 05:04:56PM +0200, Jan Beulich wrote:
>> On 06.05.2025 10:31, Roger Pau Monne wrote:
>>> The current logic partially open-codes memory_type_changed(), but doesn't
>>> check whether the type change or the cache flush is actually needed.
>>> Instead switch to using memory_type_changed(), at possibly a higher expense
>>> cost of not exclusively issuing cache flushes when limiting cacheability.
>>>
>>> However using memory_type_changed() has the benefit of limiting
>>> recalculations and cache flushes to strictly only when it's meaningful due
>>> to the guest configuration, like having devices or IO regions assigned.
>>>
>>> Signed-off-by: Roger Pau Monné 
>>
>> Hmm, I'm not convinced this is a win. This operation isn't normally used on
>> a running guest, aiui.
>>
>> What's more, this heavily conflicts with a patch posted (again) over 2 years
>> ago [1]. Unless there's something severely wrong with that (and unless your
>> patch would make that old one unnecessary), I'm again of the opinion that
>> that one should go in first. It is becoming increasingly noticeable that it's
>> unhelpful if posted patches aren't being looked at.
> 
> I'm happy for your change to go in first, but I think that
> memory_type_changed() should be adjusted to contain the extra checks
> that you add in your patch, and then hvm_set_mem_pinned_cacheattr()
> should be switched to use memory_type_changed() rather than
> open-coding it.

Maybe, but see my other reply to your patch.

>  For once it would miss the adjustment done to
> memory_type_changed() to only flush the cache when there's a
> meaningful change to the p2m (iow: p2m_memory_type_changed() is not a
> no-op).

That could also be mirrored here, if there were (remaining) reasons to avoid
use of memory_type_changed() for this function.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 07:07:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 07:07:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986352.1371917 (Exim 4.92)
	(envelope-from )
	id 1uFpAa-0000Rn-Co; Fri, 16 May 2025 07:07:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986352.1371917; Fri, 16 May 2025 07:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFpAa-0000Rg-9w; Fri, 16 May 2025 07:07:48 +0000
Received: by outflank-mailman (input) for mailman id 986352;
 Fri, 16 May 2025 07:07:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFpAZ-0000Ra-If
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 07:07:47 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 778a78fc-3224-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 09:07:45 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ad21a5466f6so563717066b.1
 for ; Fri, 16 May 2025 00:07: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
 a640c23a62f3a-ad52d4967e2sm102738566b.128.2025.05.16.00.07.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 00:07: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" 
X-Inumbo-ID: 778a78fc-3224-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747379265; x=1747984065; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=R39dlZ5xJXFuRZquO6BMI9obJIby4ZZBfBzfAzBxbuc=;
        b=f8GuzoXMQ2a4INaDZwRA4+0JUv5rSyJ98F4ZkoyknAm9Gc1g6LJRy5gIQiJCpwBPOk
         2Jw2bmkBd6YMOsb/WDhREOaoc3R+hY4xAOwYq7XiZ/u8Un70CNqEkaaFXLF0r463xjxV
         QGBzcg8go500SPGG6zYE6lyvpRcOzs1v0TZ3dakBKiprQ+9sB1xJw6X5LEVn4J79yyhV
         AvXpog0E9+lvrmCkf8/ZifXWqeNeSB8OT1xCvQi9vOyeDE5JyXneYB2LGLs66JANwk6p
         vOWCNZu4Hkn0vMpdj5cyvxnNgy5EmfSsdwPzx8GkijMjp4J5/S4VXFL3qGOZghd2BZA9
         9VLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747379265; x=1747984065;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=R39dlZ5xJXFuRZquO6BMI9obJIby4ZZBfBzfAzBxbuc=;
        b=PmenmX/Lv0/j53t0ofDiANKN270ZqkHrGD7neDxzbPy4MUZAXBN4VZX51D2Olz+ifM
         vrw7nC88/RZF7JTbhbe/caTaDmQ+XNApWA0lJwH0xDEU1gz4DYdxilU8xhpZvqklfTXK
         QaA5mXoqO5Sbc5SYtw9nLjz78nZQBf45AtHd79nM2OLLkYy9/v/1okWpXV06jfEPv7JY
         9kp7NbzxcGFCz4Ho5GZEHbdNWa1Rn1kq7xSWmv59jBFn9MyIQJYZ4BUG6wcya/nnBurr
         gsG/K/ht2hTaF6zfKlNPAcpXpUOrB7Iu6G6KQwrK4FYH4WabMJYeWz7+S60ThYn/6e7h
         PVZA==
X-Forwarded-Encrypted: i=1; AJvYcCVvxvP6GequwQ0AJDNSC+gnBvp+Cgr98TOsUIHeMXvNIIOZgkwSirUkxq3I9eZ4JIPsSsGn5P+8Qjk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwG506buaXprTUI8PSeZ7QQ4EMS6e6qgFqeJX7eDDa3LbVlzLrJ
	PB/25dWhdFfJFgQlPYCHW/deBtzMzgYok9Ff2n865i3i3WBhlgaHzVIxLye/FPTTBA==
X-Gm-Gg: ASbGncs3taQibLftl5GOKXSpJp8kIb9WfwPV02u2K4CfD3DQ5QY9Wc+fEQgCIUrMdqO
	QWy1q2YjVLzrnTNs6/JbiB/u28Rixm9pCId28wCmchD89oaNmRT3WHOUXSj/rO3YLzZOqt02jia
	SX5A0G+Wow5qcmLVjhkU5GHXEp2A59bYU6z0g1/8UgIp82eWt/rpsoX7IYUu0l23QpLbBVEUisa
	ii47VSj3IhfgzpLt65enAPlt9Rj23zwtH9/VrwAUD6ANbjRAJfVFFO2o8SXJoqQiq1MVsypoqpj
	20IrYIn352RKKK/2KUY7rIPjLEhF8yj8OeLo5PMPdJ7iTSReZcR0R0fMGBsdElPp8+pMVhPpFjV
	Iw8rc2q5SwZjLMhAamtoCaVIs6ClYz+NaSi/w/+4Y5p8F3A4=
X-Google-Smtp-Source: AGHT+IHXV7uveMgIFqiiWjkrPPuIvnLjW712xNGSvnD1w6AZENafZvDavqB+p7QzA7GAvZKXhKHceA==
X-Received: by 2002:a17:907:7d93:b0:acb:a7cc:4102 with SMTP id a640c23a62f3a-ad50f611f20mr538656466b.4.1747379264961;
        Fri, 16 May 2025 00:07:44 -0700 (PDT)
Message-ID: <205a65d3-92bd-4281-8605-758ca03fcac5@suse.com>
Date: Fri, 16 May 2025 09:07:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 7/9] xen/x86: rename cache_flush_permitted() to
 has_arch_io_resources()
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: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-8-roger.pau@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

On 15.05.2025 12:28, Roger Pau Monné wrote:
> On Mon, May 12, 2025 at 05:16:02PM +0200, Jan Beulich wrote:
>> On 06.05.2025 10:31, Roger Pau Monne wrote:
>>> To better describe the underlying implementation.  Define
>>> cache_flush_permitted() as an alias of has_arch_io_resources(), so that
>>> current users of cache_flush_permitted() are not effectively modified.
>>>
>>> With the introduction of the new handler, change some of the call sites of
>>> cache_flush_permitted() to instead use has_arch_io_resources() as such
>>> callers are not after whether cache flush is enabled, but rather whether
>>> the domain has any IO resources assigned.
>>>
>>> Take the opportunity to adjust l1_disallow_mask() to use the newly
>>> introduced has_arch_io_resources() macro.
>>
>> While I'm happy with everything else here, to me it's at least on the
>> edge whether cache_flush_permitted() wouldn't be the better predicate
>> to use there, for this being about ...
>>
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -172,8 +172,7 @@ static DEFINE_SPINLOCK(subpage_ro_lock);
>>>  
>>>  #define l1_disallow_mask(d)                                     \
>>>      (((d) != dom_io) &&                                         \
>>> -     (rangeset_is_empty((d)->iomem_caps) &&                     \
>>> -      rangeset_is_empty((d)->arch.ioport_caps) &&               \
>>> +     (!has_arch_io_resources(d) &&                              \
>>>        !has_arch_pdevs(d) &&                                     \
>>>        is_pv_domain(d)) ?                                        \
>>>       L1_DISALLOW_MASK : (L1_DISALLOW_MASK & ~PAGE_CACHE_ATTRS))
>>
>> ... cachability, which goes hand in hand with the ability to also
>> flush cache contents.
> 
> Hm, I was on the edge here, in fact I've previously coded this using
> cache_flush_permitted(), just to the change back to
> has_arch_io_resources().  If you think cache_flush_permitted() is
> better I'm fine with that.

I think that would be better here, yet as you say - it's not entirely
clear cut either way.

>> Tangentially - is it plausible for has_arch_io_resources() to return
>> false when has_arch_pdevs() returns true? Perhaps there are exotic
>> PCI devices (but non-bridges) which work with no BARs at all ...
> 
> I guess it's technically possible, albeit very unlikely?  How would
> the OS interact with such device then, exclusively with PCI config
> space accesses?

Yes, that's what I'd expect for such devices. Looking around, there
are numerous such devices (leaving aside bridges). Just that it looks
implausible to me that one would want to pass those through to a guest.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 07:16:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 07:16:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986365.1371927 (Exim 4.92)
	(envelope-from )
	id 1uFpIn-0002J6-7z; Fri, 16 May 2025 07:16:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986365.1371927; Fri, 16 May 2025 07: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 1uFpIn-0002Iz-5G; Fri, 16 May 2025 07:16:17 +0000
Received: by outflank-mailman (input) for mailman id 986365;
 Fri, 16 May 2025 07:16:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFpIl-0002Il-Gc
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 07:16:15 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a5e35b31-3225-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 09:16:12 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ad238c68b35so326204566b.1
 for ; Fri, 16 May 2025 00:16: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
 a640c23a62f3a-ad52d442069sm106230766b.103.2025.05.16.00.16.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 00:16: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" 
X-Inumbo-ID: a5e35b31-3225-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747379772; x=1747984572; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=EPuN4A8qZuSPbQNnYDinMdAiRz36z3O3U1gltDJApmw=;
        b=aYSc1PwmoFgkAtp+C+paOAI0XrLsWmwkEts39bwjIhF25VGq0DCnZ3GGKKdr1S0P1C
         XBtGbEa7yXJhzO5NOIhGaCF+xALq916PckxKX9mxnFJkClFExBbaJ+7BpYxiqyvR4gAT
         IytHggR776QkALx3taWr7osqdAy1yzh507zm54B/TTbJTtmcsGWvvV7w4FIgBTN2b9G9
         QE4R+Gp0tLaa9qk6vfIzMJZcTugzt7/A6PBukqxAIzA+L20/SvCTny/tJ8cx8nkePVap
         cS6ZSldTE6mSe+7cBnZuR4/JEb1bjNifQ9EYOFZ1asJlfBYSiGy2ogp9g4vP39kE1I1P
         9VcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747379772; x=1747984572;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EPuN4A8qZuSPbQNnYDinMdAiRz36z3O3U1gltDJApmw=;
        b=MdJo5y33sQNSQHT5LoFhgRuMjEhRRJhlmxYoVamXx+TN28DVe9G502UQfcNDDmpVuN
         12L3t/hzA9fzy4OkKQqLAVFCJ9neeevBmWetuJoLwRhp7MK1QpmxLWQstnYM5L/e2eBH
         B3CfMe4v/ogLUeX+S0WCSeOd7i0N55rDA1J/t6rC8wNmOmXqbaxfpL42Ib6LqGcMILI/
         BhUg0wfUTsBTiO5HEWnsowfwFEe+XxDqOxjiyQfehzTEpU3cxsl5/9R+CvFP5lvjFYnC
         Cx4OV+y6TWrsfujVQh/FvCtnmQwCU7wbM706Gyg4S1cQpItjUx7VQJVANsLWkOYrKEBL
         zxrA==
X-Forwarded-Encrypted: i=1; AJvYcCWr6f7jQexBBuGFnPHb8k6UZ6hNYkvc+9EPkuQgl35Z4spe76M5vtwg0SoeJJdNt1YZWXQVAz79omQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwtLJ0Sfr1C8C2ubWIAFjRSRIHkDfQ6atPcR78UhoWXnR7ez59q
	57vFvwJA3knS83FB14jYIBxDk5NU2h6J2vCBK9OMesF1XlQ1KrPPJ4WuCFiSq0rVig==
X-Gm-Gg: ASbGncvqH33MyowxKL2vWFnh9BLvcdEK3wNf7+ResVmTLyeh+m3O1U3/EM9ZeBoBCFW
	cLqkcsCDqOabM7mKWrllsaLa95tx8phdBROFOzyhIXl1H/ucLWymKJ84UTdRsZKQVShTuDIoqOf
	F7XYOK58xMXzwWxsD9zaDxcCiAuhdbjOoCIql/gBZbC/C5edeuh1yJNse8V/G7K09g1R3YKlusN
	FaS5b57RVhf9xpaVUiwGamqZSv2dPiNBAZgCy1+nmer7Z43bspEAq/QBSjevwU1NINWRd5KXaNU
	rDqndS9ggyCxWy0EwO30p0EwlYilzjgCpVIZ8DNqbvkwiJZKsbXDLnYkwXKUjHyRt5/qDuYXM8m
	InZoMlnP+5GG9XkVNLlNriRxcVVX1QoYug81z
X-Google-Smtp-Source: AGHT+IHhtz8kZegkRQ9494A/1oKKH/QDrLYmTtwMUTunreIDmSxHo2K2PKa2OYbCeBI2o5LhBmtrhw==
X-Received: by 2002:a17:907:940f:b0:acf:c:22ca with SMTP id a640c23a62f3a-ad536b5a48dmr123129766b.1.1747379772303;
        Fri, 16 May 2025 00:16:12 -0700 (PDT)
Message-ID: <8f7beebc-643b-4308-b8ff-c0b812eb8d02@suse.com>
Date: Fri, 16 May 2025 09:16:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 8/9] xen: introduce flag when a domain requires cache
 control
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , Juergen Gross
 , Christian Lindig ,
 David Scott , Bertrand Marquis ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-9-roger.pau@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

On 15.05.2025 12:44, Roger Pau Monné wrote:
> On Mon, May 12, 2025 at 05:24:01PM +0200, Jan Beulich wrote:
>> On 06.05.2025 10:31, Roger Pau Monne wrote:
>>> Such flag is added to the domain create hypercall, and a matching option is
>>> added to xl and libxl to set the flag: `cache_control`.  When the flag is
>>> set, the domain is allowed the usage of cache control operations.  If the
>>> flag is not explicitly set, libxl will set it if the domain has any `iomem`
>>> or `ioports` ranges assigned.
>>>
>>> Modify cache_flush_permitted() helper so that it's return value is no
>>> longer based on the IO resources assigned to the domain, but rather whether
>>> the domain has been explicitly allowed control over the cache, or if it has
>>> IOMMU support and there's a single IOMMU in the system that doesn't allow
>>> forcing snooping behind the guest back.  As a result of this, the return of
>>> cache_flush_permitted() is constant for the lifetime of a domain, based on
>>> the domain creation flags and the capabilities of the IOMMU if enabled
>>> for the domain.
>>
>> This then further emphasizes the remark made for patch 7.
> 
> Hm, I think you are referring to the remark about how PCI device
> without IO resources would be handled then, and what would
> cache_flush_permitted() return then?

Or more generally the relationship between that and has_arch_io_resources().

> IMO the benefit of the approach presented here is that it aims to know
> whether a domain needs cache control to be set at creation time, and
> not altered during it's runtime.

I agree that having this not vary over a domain's lifetime makes things easier
for us. At the same time it may negatively affect performance of domains where
hardware devices are added / removed on the fly.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 07:25:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 07:25:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986379.1371937 (Exim 4.92)
	(envelope-from )
	id 1uFpRr-00045H-2R; Fri, 16 May 2025 07:25:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986379.1371937; Fri, 16 May 2025 07:25:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFpRq-00045A-Vz; Fri, 16 May 2025 07:25:38 +0000
Received: by outflank-mailman (input) for mailman id 986379;
 Fri, 16 May 2025 07:25:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFpRp-000453-LV
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 07:25:37 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f5dc8b88-3226-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 09:25:36 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5f5bef591d6so3591481a12.1
 for ; Fri, 16 May 2025 00:25: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
 4fb4d7f45d1cf-6005a6e6366sm961876a12.44.2025.05.16.00.25.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 00: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" 
X-Inumbo-ID: f5dc8b88-3226-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747380336; x=1747985136; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fKB6X3ffOlNz/9yfTbBf2Mvx10O/bznxOXd1Iqxid8I=;
        b=bHocymCYEzS02oDvKwSoCzZVPuAV7W7+Iip46sDkFMDhUeGCuG2QKS8CSCdlUwq1pB
         eMGRArZ/GSKvWlR4wJGrZlYWHmoTkxJ9Jn6BLFgB7zFCOOcosap+oBmfpNmsTVgAsbvf
         ySlv7vcdDXcED25SVPQ4C5Dcvf4iZSTi8Rc77qCZwO/GJczCE5RufmgvvDNp2SWCx25p
         SCn66xXIPsfzAhAwJFZrKl9NajPtGw/t/pGm33yo4mbcH3LyWPbQFUv6lF41J/g2XDDn
         x9cL1Vu54Vl6+geJAYsKEC0qx1Ei7F91owYzDNJGEZHae7RIYIkoLozIZjIg2CH4E3ub
         A7fA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747380336; x=1747985136;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fKB6X3ffOlNz/9yfTbBf2Mvx10O/bznxOXd1Iqxid8I=;
        b=iZf2j5Ls4/Lo8s6PJsh4R4afeP0j7uAgdP3P90bHSTBpi4IA8EIqZyeKBGSBU/Mr7r
         63ghUhRsMsv172Sc90ceHsoAjL0gqFDGBZ/Cxa5lJqrKOhhxII7C+tFEtewRHjSLRUrA
         gDusiKAq4fQZr+rq8pcF/+V/ejaAC98B575xnLBsBmajdGe5NkcwahfaguGHZAnbxOdq
         OF+w31T1gNxNBCSEXpdMpLulkcMe3uaTXYp4QjR2RINoobHyIR30EMw0xYGuGpylACmR
         xENNPko7OSwPh05rGAbLCF1K+lZsSLI8/VngUsJCcIvUJcSShq8ooPJI0VMz7fLHNFyP
         kaWA==
X-Gm-Message-State: AOJu0Yz4S5Ju55g+HbCMAPssJz7brCE0kOssEBMYztcSCMy/ZmlnxHX4
	USO1SgvdqbQaVKGHh7kwEA8HGdjJKziZojBSBFJtC8kZJJ/uBny4rogHj5g03O4YDg==
X-Gm-Gg: ASbGnct/8dm5h9u9UUIKfG90sRG2+ZupTMYo4189jLcvSLtZZli0TuIffdI3GxKfp90
	iD/QIiSCSF15xKvyCrr3g+HAcegaVSOjcKgP5AZHf2Otjwt+gFcZrs5WZt4n4+W9ka4iEO5+l0v
	xI1AfEmBgse0WSauNyNYtKj/YZkZkeCpgWWab6VdmZQ0xj0p/ayrXY1HetqphILj+bQEI1UUZsm
	q4niEyvvYkLhrJXxJ4gMyvsRoTE6Vn5PchzWC0cCD+38U5xwRYsSNwpF/SBk0A68FUdN4GP0REn
	msB7PqCbwYKkP58dDF/iBOcLFBOVru1rSsKPnUNiK+QMXcWQS3qYe3l75z4P8ukdOi+9S7xJ3U9
	LS/bZUEYhWCWBgUflne9tnK07RR67XEQek+RF
X-Google-Smtp-Source: AGHT+IFkSe1aDHqFjg0/M0fAna3fjoWHfOJMLIY3DM8xmJxPiPJWTQM0nn0fnvQCP/mmI0+viJExhA==
X-Received: by 2002:a05:6402:268b:b0:5ff:8cba:cffb with SMTP id 4fb4d7f45d1cf-6009010f421mr1985328a12.25.1747380335915;
        Fri, 16 May 2025 00:25:35 -0700 (PDT)
Message-ID: 
Date: Fri, 16 May 2025 09:25:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 9/9] xen/x86: track dirty pCPU caches for a given vCPU
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-10-roger.pau@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

On 15.05.2025 12:52, Roger Pau Monné wrote:
> On Mon, May 12, 2025 at 05:38:07PM +0200, Jan Beulich wrote:
>> On 06.05.2025 14:55, Roger Pau Monné wrote:
>>> On Tue, May 06, 2025 at 12:16:00PM +0100, Andrew Cooper wrote:
>>>> On 06/05/2025 9:31 am, Roger Pau Monne wrote:
>>>>> When a guest is allowed access to cache control operations such tracking
>>>>> prevents having to issue a system-wide cache flush, and rather just flush
>>>>> the pCPUs where the vCPU has been scheduled since the last flush.
>>>>>
>>>>> Note that domain-wide flushes accumulate the dirty caches from all the
>>>>> vCPUs, but clearing the vCPU masks will require pausing all vCPUs, which
>>>>> seems overkill.  Instead leave the vCPU dirty masks as-is, worse case it
>>>>> will result in redundant flushes in further calls.
>>>>>
>>>>> Signed-off-by: Roger Pau Monné 
>>>>
>>>> I'm afraid this doesn't work.
>>>>
>>>> Unlike TLBs, dirty cacheline can move sideways, e.g. by foreign or grant
>>>> mapping, but also naturally because of how cache coherency works.
>>>
>>> Does such sideway moving also imply that local WB{NO,}INVD on native
>>> could be equally bogus?
>>>
>>> According to the SDM, cache lines can indeed move between processor
>>> caches, but the memory controller must always snoop such moves and
>>> flush the data to memory:
>>>
>>> "Here, the processor with the valid data may pass the data to the
>>> other processors without actually writing it to system memory;
>>> however, it is the responsibility of the memory controller to snoop
>>> this operation and update memory."
>>>
>>> So a cache line moving sideways will always be propagated to memory as
>>> part of the move, and hence the data in the previous pCPU cache will
>>> always hit memory.
>>
>> But that's only one of the two aspects of a flush. The other is to ensure
>> respective data isn't in any (covered) cache anymore. IOW dirty-ness (as
>> the title has it) isn't a criteria, unless of course you mean "dirty" in
>> a sense different from what it means in the cache coherency model.
> 
> Given the direct map, and the fact that the CPU can speculatively load
> entries in the cache, I'm not sure there's much Xen can effectively do
> ATM to ensure a certain cache line it's not in any cache anymore.
> 
> It would possibly get better if/when the direct map is removed, but
> even then Xen (or dom0) might map guest memory for emulation or IO
> purposes.  Then Xen/dom0 would need to issue a wbinvd after unmapping
> the memory, to ensure the cache is clean in case a vCPU from a domain
> is scheduled there.
> 
> IMO being realistic it is very unlikely for Xen to be able to ensure
> that after a guest wbinvd there are no guest owned cache lines in any
> CPU cache, even if such wbinvd is propagated to all host CPUs.

Well, see Andrew's reply on one of the two "restrict guest-induced WBINVD"
of mine. What you say is effectively supporting the statement I make in
the descriptions there ("We allow its use for writeback purposes only
anyway, ..."). Which Andrew says is wrong for at least future use cases,
possibly even today's. IOW I think we first need to find some common
grounds on the underlying goals / principles.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 07:28:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 07:28:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986386.1371946 (Exim 4.92)
	(envelope-from )
	id 1uFpUp-0004eQ-Fg; Fri, 16 May 2025 07:28:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986386.1371946; Fri, 16 May 2025 07:28: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 1uFpUp-0004eJ-Cn; Fri, 16 May 2025 07:28:43 +0000
Received: by outflank-mailman (input) for mailman id 986386;
 Fri, 16 May 2025 07:28:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFpUo-0004eB-K6
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 07:28:42 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5c9c5995-3227-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 09:28:28 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ace333d5f7bso308488266b.3
 for ; Fri, 16 May 2025 00:28: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
 a640c23a62f3a-ad52d06cdccsm107153266b.49.2025.05.16.00.28.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 00: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" 
X-Inumbo-ID: 5c9c5995-3227-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747380508; x=1747985308; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jB7fVrQoyA+r4vLcvPaB1ddQ0Xr11hBWRr6evsrcrD8=;
        b=PC696R470nUP6+xSCo/tY4XNDgQVgyLHORGV49kFgn+ZJvIm8e1hkiKIwNFXv7mRQ4
         J98qc4GxgBA5UKjTF6Km4QwvvQ3NHjnydvSzNYW/Po0OkVQVXK2l32rX9vDD7tKx3yzH
         8ESLB6+K9K5M+I/ZMn1pTp93a2mSG/zhp6TWf+xHnU+bIS8aVLqkLHOiWJJ8Sk0hjEBi
         hkY1AqmQyk+aXjK5ZNXV+kcKc0IgbQM8mUPDZxIrGh5jsmPL+wLGM5sSesE5sjRkEyOR
         CqynScL/hrXmUXhVNweL1DQMJdC3l/RSH1kYwqJfhzIuGacruaNkr9ETC6LpL3D6plx1
         /Jvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747380508; x=1747985308;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jB7fVrQoyA+r4vLcvPaB1ddQ0Xr11hBWRr6evsrcrD8=;
        b=SHhTF4UKYh91ArxRIuc1sOaKWP9bDnpAR3GF9pTXqfP4TbdIqeexjhBbp5ONhT4g5K
         +XMxlFdLwpElEIm1/juapujIL4u0Dxga5vDgmpWPM/bARDCjyQo+g+qPqg8H09bXnUjT
         FDPMo45TIxArvbpRnm3Tv6k67JodxqeKjEnmQWJ8dtflqpYVEWOs3yBC0Z5jLVFaSOig
         SiV7HBzefVq6D3ZkGHAmrH1DQRXk/VV18PCJfYTKIPKeJ7uQjpyRG+WXu8MYp/6dM7la
         FPOYalG+4fSg+K2jp16fEKrciaa0pG2pgYCIAD7p5mC8avPM7jE6uzBitk3pJkhBTrPk
         zBAg==
X-Forwarded-Encrypted: i=1; AJvYcCXpcCrR8i+RuyOqqjve+kEM/TUWqH8iuBR8wanrzDMOU385uCAK14KsyU4UmKtw5W72fUJ4dJO9IhE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzEzV9iZhXlrTsXnKb2pfx2HkixQSreyL8BBch2l1THHLWgbMnF
	Y2rRwyiurrakAy/64v6LBPfwJ+ESzGdhvwHp5onDkAS1SdX7MsYuEV4neQdK2TecyQ==
X-Gm-Gg: ASbGncv+fFWzkwx4srowIwcrpTkE+MODsCu7ew114cBRW5c4iIv3DdzXfRz+OzMs/4W
	zBsKVP+LY7IJtXDGDvGx10WsZUKMQx6tz+ukW1SPM5Zd9dHoc8rJXF0mxVvvSx2H5li43FYXY2w
	vDWbxcq9pgotejtqWXV+qbwkXQCUb2oUA9aZg1xAmuIBuFcChw5vwgbDt+blhbsllLFou3ZR4tC
	jQQOdZA/PqnHUPoDwkKsz/QxWXRSokiaa0lvUghxOFeJN8kg8V+ETiGTB5jgEMZc3FQBCz8HlC6
	FRcd4oMVt53pNDuks0AfuMCbDospoup6rQqwjpG+9CM69T6KD63RcNnnbrlFWu+cY+ww6gwqLcm
	cYn6VEdyYCH2BBQRwTlRkMsIqLoSF/Eby+S8sLlI8VF16FFQ=
X-Google-Smtp-Source: AGHT+IHcwCuMWyWR04moZN2Lxw2polE70sMCCy0v5MRtbBSxCpwFv6WzGnLiHhwnaXHXn/xPxUVRGg==
X-Received: by 2002:a17:907:94ce:b0:ad4:f517:ca3 with SMTP id a640c23a62f3a-ad536bde67bmr135842266b.20.1747380508183;
        Fri, 16 May 2025 00:28:28 -0700 (PDT)
Message-ID: <6e37d964-5df8-4685-934b-0f8d31048123@suse.com>
Date: Fri, 16 May 2025 09:28:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vpci: fix handling of BAR overlaps with non-hole
 regions
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20250515084123.43289-1-roger.pau@citrix.com>
 <8b0fa959-6d00-4bfb-bef0-b3d1ae7ce7e0@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

On 15.05.2025 12:11, Roger Pau Monné wrote:
> On Thu, May 15, 2025 at 11:24:59AM +0200, Jan Beulich wrote:
>> On 15.05.2025 10:41, Roger Pau Monne wrote:
>>> For once the message printed when a BAR overlaps with a non-hole regions is
>>> not accurate on x86.  While the BAR won't be mapped by the vPCI logic, it
>>> is quite likely overlapping with a reserved region in the memory map, and
>>> already mapped as by default all reserved regions are identity mapped in
>>> the p2m.  Fix the message so it just warns about the overlap, without
>>> mentioning that the BAR won't be mapped, as this has caused confusion in
>>> the past.
>>>
>>> Secondly, when an overlap is detected the BAR 'enabled' field is not set,
>>> hence other vPCI code that depends on it like vPCI MSI-X handling won't
>>> function properly, as it sees the BAR as disabled, even when memory
>>> decoding is enabled for the device and the BAR is likely mapped in the
>>> p2m.  Change the handling of BARs that overlap non-hole regions to instead
>>> remove any overlapped regions from the rangeset, so the resulting ranges to
>>> map just contain the hole regions.  This requires introducing a new
>>> pci_sanitize_bar_memory() that's implemented per-arch and sanitizes the
>>> address range to add to the p2m.
>>>
>>> For x86 pci_sanitize_bar_memory() removes any regions present in the host
>>> memory map, for ARM this is currently left as a dummy handler to not change
>>> existing behavior.
>>>
>>> Ultimately the above changes should fix the vPCI MSI-X handlers not working
>>> correctly when the BAR that contains the MSI-X table overlaps with a
>>> non-hole region, as then the 'enabled' BAR bit won't be set and the MSI-X
>>> traps won't handle accesses as expected.
>>
>> While all of this reads plausible, I may need to look at this again later,
>> to hopefully grok the connections and implications.
> 
> Thanks, it's indeed not trivial to follow.  I've attempted to write
> this as best as I could.
> 
> I think the fix is far easier to understand than the description of
> the issue and the connection with vPCI MSI-X handling.

Right - the code change itself looks technically fine to me.

>>> --- a/xen/arch/x86/include/asm/pci.h
>>> +++ b/xen/arch/x86/include/asm/pci.h
>>> @@ -2,6 +2,7 @@
>>>  #define __X86_PCI_H__
>>>  
>>>  #include 
>>> +#include 
>>
>> Please don't, ...
>>
>>> @@ -57,14 +58,7 @@ static always_inline bool is_pci_passthrough_enabled(void)
>>>  
>>>  void arch_pci_init_pdev(struct pci_dev *pdev);
>>>  
>>> -static inline bool pci_check_bar(const struct pci_dev *pdev,
>>> -                                 mfn_t start, mfn_t end)
>>> -{
>>> -    /*
>>> -     * Check if BAR is not overlapping with any memory region defined
>>> -     * in the memory map.
>>> -     */
>>> -    return is_memory_hole(start, end);
>>> -}
>>> +bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
>>> +int pci_sanitize_bar_memory(struct rangeset *r);
>>
>> ... all you need is a struct forward decl here.
> 
> Hm, but any user that makes use of pci_sanitize_bar_memory() will need
> to include rangeset.h anyway, hence it seemed better to just include
> the header rather that pollute the current one by adding forward
> declarations.

Yet any user of the header not calling this function won't need the full
definition of the struct, nor (perhaps) any other of the contents of
xen/rangeset.h.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 07:43:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 07:43:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986396.1371958 (Exim 4.92)
	(envelope-from )
	id 1uFpjR-0007bN-Oz; Fri, 16 May 2025 07:43:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986396.1371958; Fri, 16 May 2025 07:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFpjR-0007bG-KK; Fri, 16 May 2025 07:43:49 +0000
Received: by outflank-mailman (input) for mailman id 986396;
 Fri, 16 May 2025 07:43:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFpjQ-0007bA-4G
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 07:43:48 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7f936475-3229-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 09:43:46 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad4ffb005d8so313380766b.1
 for ; Fri, 16 May 2025 00:43:46 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d047ce3sm109933266b.21.2025.05.16.00.43.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 00: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" 
X-Inumbo-ID: 7f936475-3229-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747381426; x=1747986226; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=nKiRQVOiepaLYQVLtxO6y++Y57bVO8/3pPjrMeojVmo=;
        b=l4fGWy00aze374BSMlI0LmHdJWEXcl/y2G8sjRAzV9k5tF89e3XxiBD8aY6AWrYvro
         5gTIGbiE3UnzLEvSky9z1FFkIiV7SO2SpncVsQjuWELOTkzp0QurBuqEWE02aqBldm6Q
         hrolh1D+TFYwnfAp5T/FhMInjhl216aG4ks6s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747381426; x=1747986226;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=nKiRQVOiepaLYQVLtxO6y++Y57bVO8/3pPjrMeojVmo=;
        b=QA2qaxeJWgMJm/wTLzMaucdCDVBZs8v6nchQ97wp0AWFRlJuHUNRP8I6vZ+DZxHUtN
         LYKxFCJZ99GrUmM2oTaUka20Ho4X9GcxDcRTqa8vCRKa9Oyg9LomDgAQTJKXLW9WQ4cr
         k2fDyWei//2DCIwE0PkjKh9leCvE7VrPSMgLr35APF0CIT6qDrhOxE4eZXBdPdZY4Pnz
         4emVyeGVCzkJRPdf6yHaLF3YDeXL2PLiv11SnOLVqhm+4OXbDLXup7uvlUXrxH0hnME9
         SzlAm/L/hqjTRONYj6z2+9bHitTLgUIshsbA4PYX74SE+9INXAJeFcnT8d+PaEe6mkSz
         cL5A==
X-Gm-Message-State: AOJu0Yx5+sKUa2AaPe3gq0e06Tu+kIqtUIk5Pcc++XZrmLVmFGBaTvdG
	PcWMufJuiHbOn0LBuu6dC6zgFnKjapM59Xzl3Hl6GJSIF2mKd9C61CFqwXJomH6/HLk=
X-Gm-Gg: ASbGncuyN93Q9zstoUsYqtKgLpvikVeQAaSZ9riz/q224YgG0eF/mVYwN9Q3DQiSKJL
	hxVuo1gGCL1EU9YGIi7ka6zg7rGsIAPLq9XysCFaPYHw6eZO3kiNXD6uHJXMXX0YDdMCHNWKsEp
	0PCKXMLZG4PtQdRErwCBqi+NqEkAjXUcPxMzf7JTjzhCHXUF9/h56lgSLLu9Im3JggUKrzfJHpH
	0jl0dotdzuAbyHIwPM3Zgc5f9MngZmbzrBCIfAnvBCRcecmfWyVlDQro8pqk9efsA45x+recO4W
	wAs/Mc+RrNxqIEZo6NXtwpBaa5jyksTXnrhEEOjM1y6PylWLVoi/Zb22VKGfOGRCiI2HBcLsHlv
	ZUZ3GQlin8Ah2JX44nsE=
X-Google-Smtp-Source: AGHT+IGRZqVoHjqEq9YP2czMe1XofMygBJHtliztJN2Ff/urvb11NPaY7BwWWT38tBYNg3brXN8+gw==
X-Received: by 2002:a17:907:1b08:b0:ad2:43b6:dd75 with SMTP id a640c23a62f3a-ad52d441ffemr238026566b.10.1747381425844;
        Fri, 16 May 2025 00:43:45 -0700 (PDT)
Date: Fri, 16 May 2025 09:43:44 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "xen-devel@lists.xenproject.org" ,
	Andrew Cooper , Wei Liu 
Subject: Re: [PATCH] x86/HVM: restrict use of pinned cache attributes as well
 as associated flushing
Message-ID: 
References: <42d40da1-bc38-82fb-154a-e1fc876b0c24@suse.com>
 
 <2032431f-fa8b-47ec-8879-29baadd266bd@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2032431f-fa8b-47ec-8879-29baadd266bd@suse.com>

On Fri, May 16, 2025 at 08:54:52AM +0200, Jan Beulich wrote:
> On 15.05.2025 12:04, Roger Pau Monné wrote:
> > On Wed, Mar 22, 2023 at 07:50:09AM +0100, Jan Beulich wrote:
> >> We don't permit use of uncachable memory types elsewhere unless a domain
> >> meets certain criteria. Enforce this also during registration of pinned
> >> cache attribute ranges.
> >>
> >> Furthermore restrict cache flushing to just uncachable range registration.
> >> While there, also
> >> - take CPU self-snoop as well as IOMMU snoop into account (albeit the
> >>   latter still is a global property rather than a per-domain one),
> >> - avoid flushes when the domain isn't running yet (which ought to be the
> >>   common case).
> >>
> >> Reported-by: Andrew Cooper 
> >> Signed-off-by: Jan Beulich 
> >> ---
> >> At the expense of yet larger a diff it would be possible to get away
> >> without any "goto", by moving the whole "new entry" handling into the
> >> switch(). Personally I'd prefer that, but the larger diff may be
> >> unwelcome.
> >>
> >> I have to admit that I can't spot what part of epte_get_entry_emt() the
> >> comment refers to that is being deleted. The function does use
> >> hvm_get_mem_pinned_cacheattr(), yes, but there's nothing there that talks
> >> about cache flushes (and their avoiding) in any way.
> >>
> >> Is it really sensible to add/remove ranges once the guest is already
> >> running? (If it is, limiting the scope of the flush would be nice, but
> >> would require knowing dirtyness for the domain wrt the caches, which
> >> currently we don't track.)
> >>
> >> This is kind of amending XSA-428.
> >>
> >> --- a/xen/arch/x86/hvm/mtrr.c
> >> +++ b/xen/arch/x86/hvm/mtrr.c
> >> @@ -589,6 +589,7 @@ int hvm_set_mem_pinned_cacheattr(struct
> >>  {
> >>      struct hvm_mem_pinned_cacheattr_range *range, *newr;
> >>      unsigned int nr = 0;
> >> +    bool flush = false;
> >>      int rc = 1;
> >>  
> >>      if ( !is_hvm_domain(d) )
> >> @@ -612,31 +613,35 @@ int hvm_set_mem_pinned_cacheattr(struct
> >>  
> >>                  type = range->type;
> >>                  call_rcu(&range->rcu, free_pinned_cacheattr_entry);
> >> -                p2m_memory_type_changed(d);
> >>                  switch ( type )
> >>                  {
> >> -                case X86_MT_UCM:
> >> +                case X86_MT_WB:
> >> +                case X86_MT_WP:
> >> +                case X86_MT_WT:
> >>                      /*
> >> -                     * For EPT we can also avoid the flush in this case;
> >> -                     * see epte_get_entry_emt().
> >> +                     * Flush since we don't know what the cachability is going
> >> +                     * to be.
> >>                       */
> >> -                    if ( hap_enabled(d) && cpu_has_vmx )
> >> -                case X86_MT_UC:
> >> -                        break;
> >> -                    /* fall through */
> >> -                default:
> >> -                    flush_all(FLUSH_CACHE);
> >> +                    if ( is_iommu_enabled(d) || cache_flush_permitted(d) )
> >> +                        flush = true;
> >>                      break;
> >>                  }
> >> -                return 0;
> >> +                rc = 0;
> >> +                goto finish;
> >>              }
> >>          domain_unlock(d);
> >>          return -ENOENT;
> >>  
> >>      case X86_MT_UCM:
> >>      case X86_MT_UC:
> >> -    case X86_MT_WB:
> >>      case X86_MT_WC:
> >> +        /* Flush since we don't know what the cachability was. */
> >> +        if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
> >> +            return -EPERM;
> >> +        flush = true;
> >> +        break;
> >> +
> >> +    case X86_MT_WB:
> >>      case X86_MT_WP:
> >>      case X86_MT_WT:
> >>          break;
> >> @@ -689,8 +694,12 @@ int hvm_set_mem_pinned_cacheattr(struct
> >>  
> >>      xfree(newr);
> >>  
> >> + finish:
> >>      p2m_memory_type_changed(d);
> >> -    if ( type != X86_MT_WB )
> >> +
> >> +    if ( flush && d->creation_finished &&
> >> +         (!boot_cpu_has(X86_FEATURE_XEN_SELFSNOOP) ||
> >> +          (is_iommu_enabled(d) && !iommu_snoop)) )
> >>          flush_all(FLUSH_CACHE);
> > 
> > I think it would be better if we could add those checks to
> > memory_type_changed() rather than open-coding them here, and just call
> > memory_type_changed() then, which would also avoid the goto AFAICT.
> 
> Hmm, with this last remark, what does "those checks" cover then?

I have a patches I was going to send today (done some overnight
testing) that do:

    if ( cache_flush_permitted(d) &&
         d->vcpu && d->vcpu[0] && p2m_memory_type_changed(d) &&
         /*
          * Do the p2m type-change, but skip the cache flush if the domain is
          * not yet running.  The check for creation_finished must strictly be
          * done after the call to p2m_memory_type_changed().
          */
         d->creation_finished &&
         /*
          * The cache flush should be done if either: CPU doesn't have
          * self-snoop in which case there could be aliases left in the cache,
          * or IOMMUs cannot force all DMA device accesses to be snooped.
          */
         (!boot_cpu_has(X86_FEATURE_XEN_SELFSNOOP) ||
          (is_iommu_enabled(d) && !iommu_snoop)) )
    {
        flush_all(FLUSH_CACHE);
    }

As to attempt to limit the cache flushing done in
memory_type_changed().

> I first
> read it as meaning the conditions in just this if(), but the "goto" is
> needed for a different reason.

Maybe I'm missing something, but couldn't
hvm_set_mem_pinned_cacheattr() just call memory_type_changed() (with
the proposed checks above added) if and return then, instead of doing
a goto?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 16 07:48:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 07:48:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986415.1371967 (Exim 4.92)
	(envelope-from )
	id 1uFpna-0008M5-9W; Fri, 16 May 2025 07:48:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986415.1371967; Fri, 16 May 2025 07: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 1uFpna-0008Ly-6m; Fri, 16 May 2025 07:48:06 +0000
Received: by outflank-mailman (input) for mailman id 986415;
 Fri, 16 May 2025 07:48:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFpnY-0008Ls-Sh
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 07:48:04 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 18dd4fdd-322a-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 09:48:04 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ad53cd163d9so37800766b.0
 for ; Fri, 16 May 2025 00:48:04 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d04e80asm110397166b.2.2025.05.16.00.48.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 00: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" 
X-Inumbo-ID: 18dd4fdd-322a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747381683; x=1747986483; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=2E/hoT4fE8Bh31dCCp6BY8ERhJFrdzHrljWu6xm8+JE=;
        b=kQ4zAExJFolFhHm/kzVRuoAHWW/R2hXN5zTHRHMvF0YtMqSTqGg1cwXTRGJhstMuiS
         OUFHll/JR8wAhBXO9NxLZn/OxeLzNx/KpD4VsuytR8IiMKN5ezUyY6iLy4I1AQ8YPo0b
         1opNQ5LYxInEOYhBN9gtBXGUsMZFfDJS01318=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747381683; x=1747986483;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2E/hoT4fE8Bh31dCCp6BY8ERhJFrdzHrljWu6xm8+JE=;
        b=h52igw8X3m7CespTfxIBCys4WcVyneai3qh61FiUudtBAYN5fctfUZHyWGMJ2OWzZS
         xC42wl/OlBiBksYP52/u+NUPesXNH3eidMzfbu9zlPx5CsJCGnvJKTI33G6xjWPdKoyc
         OHXVrVOFCjShJwEr7hkU3HMPqskdbgCKSJYO+8xn+UaM0PistFfqXdO9bgVliozL3CJf
         u5FGkD16j+mD5RHaAfxqlneciLcOBRrZS5BmEKjtwArhx4NYg7030uI88/MRRhYMToQa
         iwN6bvl45hGv6qDtQPCy1SBPx01ElsQkdoeF9W1vPslzEg0dttVwWyZc3lfv3rykCXFS
         Knkg==
X-Forwarded-Encrypted: i=1; AJvYcCUME52m26yXaYRonUwtkL3EaiaJMBQP6oDU3L17v/8f3J722RXrBGpGxEV94C/2rpQX4ufx3yE06dc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwalPUja9Hm0TB7a/u8BlXdAE7y3mYHumCKeQjeONY9y7g2VkcQ
	nygw0Y6qjTtBNCAgsmm0FWXVo2xnf6PJQTfSh4ZKQ57V0//Oli+NuEYXgaUyKnQMmDr7+sCp3RU
	8RIuR
X-Gm-Gg: ASbGncupEvgTAzITt+v+J6T0gfiLvx8nU8q97Mf5BDUFG/EwnFuufTDeRRaxe+CgAx1
	67XdBWP+baJMB23KvNoEo9qZBn9jkFzmCmG0NyRqKTDJoPDTjQ5d6gcX13a0SqeX/RwaZ/3ckNg
	FwO7vwW+YbBq9toQyJyNeItR6Cugh0E2ygA62fw7Hl9lH/BlFVDzxzDKP3pVN2lipcL41XBUOfF
	TMMw5Cd0oOS/tXaozoY9xyuO9M0q6V1rmzbNzkkigVLfM/Wn8vR3y/xPS87mnFBD4DSHev/KlxX
	Kl2AIAQ3VeNjhn/kjZ23DWBU2ut3Ja0poY/i5KTyO4zgWGAyzvVDctNQMqy+W5phNSbMlSzDBLu
	32tDkAFMFqwRB/sco1kWmgo1Qlw5E5w==
X-Google-Smtp-Source: AGHT+IFHjXsXhnwdXisjGrKAKUbROPL9FgH5FxIejhsE4kscm3lGoUIIsJSkmSZpp850K0D1drop4Q==
X-Received: by 2002:a17:907:7f88:b0:ad2:3bfc:232 with SMTP id a640c23a62f3a-ad52d509f93mr224065866b.32.1747381683075;
        Fri, 16 May 2025 00:48:03 -0700 (PDT)
Date: Fri, 16 May 2025 09:48:01 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 5/9] x86/mtrr: use memory_type_changed() in
 hvm_set_mem_pinned_cacheattr()
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-6-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Fri, May 16, 2025 at 08:58:39AM +0200, Jan Beulich wrote:
> On 06.05.2025 10:31, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/mtrr.c
> > +++ b/xen/arch/x86/hvm/mtrr.c
> > @@ -605,22 +605,8 @@ int hvm_set_mem_pinned_cacheattr(struct domain *d, uint64_t gfn_start,
> >  
> >                  type = range->type;
> >                  call_rcu(&range->rcu, free_pinned_cacheattr_entry);
> > -                p2m_memory_type_changed(d);
> > -                switch ( type )
> > -                {
> > -                case X86_MT_UCM:
> > -                    /*
> > -                     * For EPT we can also avoid the flush in this case;
> > -                     * see epte_get_entry_emt().
> > -                     */
> > -                    if ( hap_enabled(d) && cpu_has_vmx )
> > -                case X86_MT_UC:
> > -                        break;
> > -                    /* fall through */
> > -                default:
> > -                    flush_all(FLUSH_CACHE);
> > -                    break;
> > -                }
> > +                memory_type_changed(d);
> > +
> >                  return 0;
> >              }
> 
> Hmm, so your consideration to avoid the "goto" in my patch was perhaps this
> part of your change, where you expect the "return 0" could then stay here.
> Maybe. However, you removing the switch() means we'd then also flush in
> cases where currently (or with my change) we avoid doing so.

Oh, yes, just replied to your previous email with this suggestion.

I don't have a strong opinion, but I don't think the fine grained
flush avoidance is really required.  What's more, if we want to call
memory_type_changed() we must do so for any changes, as the call to
p2m_memory_type_changed() must be done unconditionally regardless of
whether the specific MTRR type change could allow us to avoid the
flush.

Overall, I have the impression hvm_set_mem_pinned_cacheattr() should
only be used while building a domain, and hence the flush can likely
be skipped unconditionally, regardless of the type changes.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 16 07:55:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 07:55:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986423.1371976 (Exim 4.92)
	(envelope-from )
	id 1uFpv6-0001fh-17; Fri, 16 May 2025 07:55:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986423.1371976; Fri, 16 May 2025 07: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 1uFpv5-0001fa-Uf; Fri, 16 May 2025 07:55:51 +0000
Received: by outflank-mailman (input) for mailman id 986423;
 Fri, 16 May 2025 07:55:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFpv4-0001fT-31
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 07:55:50 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2d971b78-322b-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 09:55:48 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad23db02350so341340666b.1
 for ; Fri, 16 May 2025 00:55: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
 a640c23a62f3a-ad52d496576sm110783866b.133.2025.05.16.00.55.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 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" 
X-Inumbo-ID: 2d971b78-322b-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747382147; x=1747986947; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=F9YQR22x67Cw2L+wlNceLkVyk0xOaNpkeKO1tCeDrVM=;
        b=IWOAHLUyoa35tvCUZsaOKvPUBQcrF1ZTdt0uy6RxgU8xrGH5LzV6KyWVG4quH9UOuL
         8GGSs3VG7oE2oqQm8T/lI9gTARbyjKLxz1dS88X769zkU+uCkRTfOjqo+XQOBX/H/+8Q
         U5cffN+OHUoffkzVDFl0gJ4HlKowM0wVaxDmMUBrQvqisTC4YgWvMSeAEeiHLTT+/ui0
         E3olgcxDQfflmPg9GglQilyn4P9PQWCeoYkjcqRlp9RJxt76Uq2TyBWbP1zVTQmyT2kj
         QtO6KdU8nTiwXVOTP9a3W4D1BUzwCxsQonimCw6DE9N/DRvKaIitF3p+qOsWyCcBqxfs
         aDzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747382147; x=1747986947;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=F9YQR22x67Cw2L+wlNceLkVyk0xOaNpkeKO1tCeDrVM=;
        b=RYEIpG9ibHPs5E50YjIjjh1vsICTff9HGJy6tW4XLLSQPGCWEH2jLoTR7vPFYaECP3
         qdPPgasq08aaEITZ9BYzz9dHrUkOzvh1gsUpNIRKqdnZcKpoNR26CnsE3E4JeD1czlxZ
         ZVSLRYczD4BkLD/bNTZMxAL5E2Tcr2oh3fEo1rQC2lZbyFQlZjtXl/WpO53Wwj8eIA2j
         FDGMZ1Jh3Y+MIKLg7Z5dVFASynSeMAMWMysaQhhu+Q/CNlF1FLam489L/dT/Qc1zFnEw
         PFgFNQvz/xhvxAddTZK76OrIalQ67vKunGbkenBMr8ZzFdBrFevA9/ESpIYOz6x+bkLK
         QWTw==
X-Gm-Message-State: AOJu0YyAZhScOvHKn9g8PW+hjUnPIpNlE7AUMbcB4p/2zN7pmZrwBKV4
	T0ELMQDhixw+WM2pM8q5fionsvn43NOorBvHIuGbzM65J23fZHdnF3FVBHJf/sFH6Q==
X-Gm-Gg: ASbGncshvFOGbBS4RIzlEZpkc7nEWwBFgT37BDIxfZjSIsC5Wnm4C6FxDy2eF1ktUvy
	tEhxU5AhDsdH65pijdetY9OJnG40K9qiMO9HnKMk8XPWTpd1Sr11fAQYpsn9Q3qinsFtZSmJYhN
	2zto3cOhTeR/vYKpuUKcH9WdnOFrqDbnFLiBmgZvyZtD9QqYjqSzwKaen2HN9DAAEdH0/l51VWw
	/wyq832wC6DiUV9b71G4x7aC28JOozRFvCvUUoy53PxNbgwsXHWwLnqU1sWNPIGGKrFs+Rx4YWp
	9U/hf3bjLGOLqp9o4jcRglDvlu+sCiM1UhjXc5hG3IlStni8bUExRQiJ7c+UWnLdS/k8dcgTtJT
	iSTpxvlTzs7jcl4PgWaq5Z+6uq6Qp60j5Svdz
X-Google-Smtp-Source: AGHT+IHBTo/p6jqWgGecC9rt3UmM8FNl92Xrol6gmevWOj4sbyLGU2ojNCuKyGHESdSXlYQbXzDITA==
X-Received: by 2002:a17:907:60d6:b0:ad5:211e:8cff with SMTP id a640c23a62f3a-ad52d5ba7b7mr224176366b.37.1747382147308;
        Fri, 16 May 2025 00:55:47 -0700 (PDT)
Message-ID: <22427127-af31-4f67-8988-b64d7d75e03a@suse.com>
Date: Fri, 16 May 2025 09:55:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/HVM: restrict use of pinned cache attributes as well
 as associated flushing
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Wei Liu 
References: <42d40da1-bc38-82fb-154a-e1fc876b0c24@suse.com>
 
 <2032431f-fa8b-47ec-8879-29baadd266bd@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

On 16.05.2025 09:43, Roger Pau Monné wrote:
> On Fri, May 16, 2025 at 08:54:52AM +0200, Jan Beulich wrote:
>> On 15.05.2025 12:04, Roger Pau Monné wrote:
>>> On Wed, Mar 22, 2023 at 07:50:09AM +0100, Jan Beulich wrote:
>>>> We don't permit use of uncachable memory types elsewhere unless a domain
>>>> meets certain criteria. Enforce this also during registration of pinned
>>>> cache attribute ranges.
>>>>
>>>> Furthermore restrict cache flushing to just uncachable range registration.
>>>> While there, also
>>>> - take CPU self-snoop as well as IOMMU snoop into account (albeit the
>>>>   latter still is a global property rather than a per-domain one),
>>>> - avoid flushes when the domain isn't running yet (which ought to be the
>>>>   common case).
>>>>
>>>> Reported-by: Andrew Cooper 
>>>> Signed-off-by: Jan Beulich 
>>>> ---
>>>> At the expense of yet larger a diff it would be possible to get away
>>>> without any "goto", by moving the whole "new entry" handling into the
>>>> switch(). Personally I'd prefer that, but the larger diff may be
>>>> unwelcome.
>>>>
>>>> I have to admit that I can't spot what part of epte_get_entry_emt() the
>>>> comment refers to that is being deleted. The function does use
>>>> hvm_get_mem_pinned_cacheattr(), yes, but there's nothing there that talks
>>>> about cache flushes (and their avoiding) in any way.
>>>>
>>>> Is it really sensible to add/remove ranges once the guest is already
>>>> running? (If it is, limiting the scope of the flush would be nice, but
>>>> would require knowing dirtyness for the domain wrt the caches, which
>>>> currently we don't track.)
>>>>
>>>> This is kind of amending XSA-428.
>>>>
>>>> --- a/xen/arch/x86/hvm/mtrr.c
>>>> +++ b/xen/arch/x86/hvm/mtrr.c
>>>> @@ -589,6 +589,7 @@ int hvm_set_mem_pinned_cacheattr(struct
>>>>  {
>>>>      struct hvm_mem_pinned_cacheattr_range *range, *newr;
>>>>      unsigned int nr = 0;
>>>> +    bool flush = false;
>>>>      int rc = 1;
>>>>  
>>>>      if ( !is_hvm_domain(d) )
>>>> @@ -612,31 +613,35 @@ int hvm_set_mem_pinned_cacheattr(struct
>>>>  
>>>>                  type = range->type;
>>>>                  call_rcu(&range->rcu, free_pinned_cacheattr_entry);
>>>> -                p2m_memory_type_changed(d);
>>>>                  switch ( type )
>>>>                  {
>>>> -                case X86_MT_UCM:
>>>> +                case X86_MT_WB:
>>>> +                case X86_MT_WP:
>>>> +                case X86_MT_WT:
>>>>                      /*
>>>> -                     * For EPT we can also avoid the flush in this case;
>>>> -                     * see epte_get_entry_emt().
>>>> +                     * Flush since we don't know what the cachability is going
>>>> +                     * to be.
>>>>                       */
>>>> -                    if ( hap_enabled(d) && cpu_has_vmx )
>>>> -                case X86_MT_UC:
>>>> -                        break;
>>>> -                    /* fall through */
>>>> -                default:
>>>> -                    flush_all(FLUSH_CACHE);
>>>> +                    if ( is_iommu_enabled(d) || cache_flush_permitted(d) )
>>>> +                        flush = true;
>>>>                      break;
>>>>                  }
>>>> -                return 0;
>>>> +                rc = 0;
>>>> +                goto finish;
>>>>              }
>>>>          domain_unlock(d);
>>>>          return -ENOENT;
>>>>  
>>>>      case X86_MT_UCM:
>>>>      case X86_MT_UC:
>>>> -    case X86_MT_WB:
>>>>      case X86_MT_WC:
>>>> +        /* Flush since we don't know what the cachability was. */
>>>> +        if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
>>>> +            return -EPERM;
>>>> +        flush = true;
>>>> +        break;
>>>> +
>>>> +    case X86_MT_WB:
>>>>      case X86_MT_WP:
>>>>      case X86_MT_WT:
>>>>          break;
>>>> @@ -689,8 +694,12 @@ int hvm_set_mem_pinned_cacheattr(struct
>>>>  
>>>>      xfree(newr);
>>>>  
>>>> + finish:
>>>>      p2m_memory_type_changed(d);
>>>> -    if ( type != X86_MT_WB )
>>>> +
>>>> +    if ( flush && d->creation_finished &&
>>>> +         (!boot_cpu_has(X86_FEATURE_XEN_SELFSNOOP) ||
>>>> +          (is_iommu_enabled(d) && !iommu_snoop)) )
>>>>          flush_all(FLUSH_CACHE);
>>>
>>> I think it would be better if we could add those checks to
>>> memory_type_changed() rather than open-coding them here, and just call
>>> memory_type_changed() then, which would also avoid the goto AFAICT.
>>
>> Hmm, with this last remark, what does "those checks" cover then?
> 
> I have a patches I was going to send today (done some overnight
> testing) that do:
> 
>     if ( cache_flush_permitted(d) &&
>          d->vcpu && d->vcpu[0] && p2m_memory_type_changed(d) &&
>          /*
>           * Do the p2m type-change, but skip the cache flush if the domain is
>           * not yet running.  The check for creation_finished must strictly be
>           * done after the call to p2m_memory_type_changed().
>           */
>          d->creation_finished &&
>          /*
>           * The cache flush should be done if either: CPU doesn't have
>           * self-snoop in which case there could be aliases left in the cache,
>           * or IOMMUs cannot force all DMA device accesses to be snooped.
>           */
>          (!boot_cpu_has(X86_FEATURE_XEN_SELFSNOOP) ||
>           (is_iommu_enabled(d) && !iommu_snoop)) )
>     {
>         flush_all(FLUSH_CACHE);
>     }
> 
> As to attempt to limit the cache flushing done in
> memory_type_changed().
> 
>> I first
>> read it as meaning the conditions in just this if(), but the "goto" is
>> needed for a different reason.
> 
> Maybe I'm missing something, but couldn't
> hvm_set_mem_pinned_cacheattr() just call memory_type_changed() (with
> the proposed checks above added) if and return then, instead of doing
> a goto?

As per later replies to your patch - yes, looks like that's possible.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 07:57:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 07:57:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986430.1371987 (Exim 4.92)
	(envelope-from )
	id 1uFpwh-0002D4-BN; Fri, 16 May 2025 07:57:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986430.1371987; Fri, 16 May 2025 07: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 1uFpwh-0002Cx-7z; Fri, 16 May 2025 07:57:31 +0000
Received: by outflank-mailman (input) for mailman id 986430;
 Fri, 16 May 2025 07:57:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFpwf-0002Cr-HU
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 07:57:29 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 69aa3b4c-322b-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 09:57:28 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-60179d8e65fso506488a12.0
 for ; Fri, 16 May 2025 00:57:28 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 4fb4d7f45d1cf-6004d4f1f9esm990156a12.8.2025.05.16.00.57.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 00:57:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 69aa3b4c-322b-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747382248; x=1747987048; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=BCdBsP8Tf8Vr+C2q+t0weisYFPxZF1r4GVOhoMizHrM=;
        b=l9b0gLdxUKNh80KUfH+xAUhNLSfhp/CB04qOfeINU5UEcNDguexLP/B6+wcBcY+UFv
         AVE+wxkqkz41NTzoSfiUhOzsG2oamHC5ucQxZTXPJ6t6+yLmscgEpaHbN1GcdfuWimwA
         lCBJC9+UzBVNUuUqDnX/ZZclF0JZlUrT3PjNE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747382248; x=1747987048;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=BCdBsP8Tf8Vr+C2q+t0weisYFPxZF1r4GVOhoMizHrM=;
        b=K3agDvC0553KhNxo6hLXNwBP/D3MKn5zruqsQYNnE0UjyHxcJaYkIwdslYGQn78xNA
         FArWp46yHe+auff4HIRuX7V+a9LQ183uulsAeIMo88epLdt8V7FBlwTt9eKMHvUHm0yU
         qn4xa+x78zHqT/IQkTfrIVvvNeRgSLbCNmUr05nOmRP/v0/mQiXpkQvyKaWvNIP851rl
         5h9NdXicgsdINE5Szwugkjy13IRdR85Jw00D4JXsWAMGerRilmrkI8sOsDZmnLqNHMq3
         qdJ6q9ewKyLgGUTjsVh4RkXB1DtqVwbsbotNJVa4KldCjJ+7mgBycKqNQ19ovWhjvr16
         rl7g==
X-Forwarded-Encrypted: i=1; AJvYcCXUekUEnIoAh6g+r/XGD4xHolOIf9BfGgI/lWy4hUMXiwmijZQQuxAj7f4VflLwJcMU6ka83ipUf+c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzh3+wriRgqtyRvJSmb7SAGrBTBjcQHotIxIPzoa5XsEwAg5Glo
	06TD0uixZFmoYGKY7K+oTdQ66qJBZGwauNx05z4P7Q4tgYfyqKJHJp5/nKx2eWrydCcNaaZHymE
	TU0SB
X-Gm-Gg: ASbGncsPwdKyfF8Z5KZi/vrXoxCHgS9hJLbRuAolYyHai5PfU+u/Tjpbm7FvXjPWr6W
	VZwoRj4RLynQblPMXD2nvqqnOFzwWo4xuEssDNhIo541Lmq0BA622AO1BOhfM70cyDZ4uN8A39B
	8LRWiJPxrtp/59rX6xcuSE0OSGQk8lTGNVjzWMxP+cHdaOSMhyLoM7e+/U6Gk8t7ZckqO6PcCNF
	9+Nck17Kxy6Od/JZQWfu0+xDSefDUtNIZC8qJqYMKY5VRvRhgJH/bRtxrkYkzrFCKMKTmIqiOcS
	hzEyO42ydeOltnPUn0O3F3gytLB0qSx7TqaHZ2APHMNb4WFcqFz3Yb5uMEefb+yiScVL03czNAN
	DX3llP+dLNMCZYiGS11IUOWEL15ctXg==
X-Google-Smtp-Source: AGHT+IFuFsMzFf/tPT0svIuVcdrfd6wo6pqaYbtMGDxBEmhgZCjmb0mI7Io7wO1h88xNeVyQQ9y70g==
X-Received: by 2002:a05:6402:50cb:b0:600:5a9e:2b52 with SMTP id 4fb4d7f45d1cf-6008a7a40camr1794132a12.8.1747382248107;
        Fri, 16 May 2025 00:57:28 -0700 (PDT)
Date: Fri, 16 May 2025 09:57:26 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 5/9] x86/mtrr: use memory_type_changed() in
 hvm_set_mem_pinned_cacheattr()
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-6-roger.pau@citrix.com>
 <853ffc16-f14b-44fa-9e71-4fae8377fa95@suse.com>
 
 <91058f6f-0b87-4958-aa09-749df4de3a9f@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <91058f6f-0b87-4958-aa09-749df4de3a9f@suse.com>

On Fri, May 16, 2025 at 09:00:42AM +0200, Jan Beulich wrote:
> On 15.05.2025 12:22, Roger Pau Monné wrote:
> > On Mon, May 12, 2025 at 05:04:56PM +0200, Jan Beulich wrote:
> >> On 06.05.2025 10:31, Roger Pau Monne wrote:
> >>> The current logic partially open-codes memory_type_changed(), but doesn't
> >>> check whether the type change or the cache flush is actually needed.
> >>> Instead switch to using memory_type_changed(), at possibly a higher expense
> >>> cost of not exclusively issuing cache flushes when limiting cacheability.
> >>>
> >>> However using memory_type_changed() has the benefit of limiting
> >>> recalculations and cache flushes to strictly only when it's meaningful due
> >>> to the guest configuration, like having devices or IO regions assigned.
> >>>
> >>> Signed-off-by: Roger Pau Monné 
> >>
> >> Hmm, I'm not convinced this is a win. This operation isn't normally used on
> >> a running guest, aiui.
> >>
> >> What's more, this heavily conflicts with a patch posted (again) over 2 years
> >> ago [1]. Unless there's something severely wrong with that (and unless your
> >> patch would make that old one unnecessary), I'm again of the opinion that
> >> that one should go in first. It is becoming increasingly noticeable that it's
> >> unhelpful if posted patches aren't being looked at.
> > 
> > I'm happy for your change to go in first, but I think that
> > memory_type_changed() should be adjusted to contain the extra checks
> > that you add in your patch, and then hvm_set_mem_pinned_cacheattr()
> > should be switched to use memory_type_changed() rather than
> > open-coding it.
> 
> Maybe, but see my other reply to your patch.
> 
> >  For once it would miss the adjustment done to
> > memory_type_changed() to only flush the cache when there's a
> > meaningful change to the p2m (iow: p2m_memory_type_changed() is not a
> > no-op).
> 
> That could also be mirrored here, if there were (remaining) reasons to avoid
> use of memory_type_changed() for this function.

Indeed, but it's just more open-coding of memory_type_changed() in the
context of hvm_set_mem_pinned_cacheattr().  IMO I don't know exactly
the usage of this function, it seems like it should be mostly used at
domain build time, or maybe when doing hotplug of a device, so not
very often.

Given how complicated cache management is, I would prefer if the logic
is limited to few places (like memory_type_changed()), instead of
having open-coded implementations of the same logic in multiple
places.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 16 08:02:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:02:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986442.1371996 (Exim 4.92)
	(envelope-from )
	id 1uFq1T-0004Mx-0w; Fri, 16 May 2025 08:02:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986442.1371996; Fri, 16 May 2025 08:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFq1S-0004Mq-UU; Fri, 16 May 2025 08:02:26 +0000
Received: by outflank-mailman (input) for mailman id 986442;
 Fri, 16 May 2025 08:02:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFq1R-0004Mk-IJ
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:02:25 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 19e390c4-322c-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 10:02:24 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5fbcd9088a7so2234349a12.0
 for ; Fri, 16 May 2025 01:02: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
 4fb4d7f45d1cf-6004d502bc1sm986469a12.30.2025.05.16.01.02.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 01:02: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" 
X-Inumbo-ID: 19e390c4-322c-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747382544; x=1747987344; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Dv1fBlliwj5nxKFnT8jOp4JNgKgqoglMRaikG1ibvJU=;
        b=FT/JbjqIWZ3+jaMVp6hV1kLUy5882ltlsDPgoJOlh/2BSCYRGCM+t0oszc53osX8gu
         XmUylSNysHSupITWe9Zry8jGS1JL51EMfFLbMExW6aGrGoef1DvbHHWGK3pChkVNGYO3
         JfrfZ6QEg3eMMcLST1fF3G+OVuGQxSWpL2gjDio5htA+aCXfUqIRofDGhfFAtrt1unLO
         /TTIA+i7lEwKxxM1Z/X6FCFgEeq9XfDnh/tq2MqB04TVxlrgv5ksGpnHnHW9fbbm6Lbp
         eF1WtO8foaYr2YPbS1RIO37lzH6RViWsJ9w03gPM5u8fmcZB4kuVlK+kMnNqO300gnp/
         KAsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747382544; x=1747987344;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Dv1fBlliwj5nxKFnT8jOp4JNgKgqoglMRaikG1ibvJU=;
        b=nfINPKV4T9tNbtFLI4bsY076ePTU6I4J7HuEzBdkUC4a64ufVm50ffTYHXNk0LhzQm
         SA9R+H76XCip1977Mt4320r2HJ92/koHZcvlzzRXNJs+3Z8l7oKslKncSkcT6E6Q+x0/
         Gg7hAuzY+bUwCsqf3j8KVb55j3X9tIs0LSjnJgBfeOe2FNjHh3loSA0whqNi/Pb2qq/1
         FiTng789oEGQoMo1JU/UKBZhAO7ARrJXPccRxIKlddxVniObIh1XtWe/nQGPIhRBGZ1g
         knLHYhPkUelrZ/PpR62Dsdxol4Ngk1ucBNyyonwR37q2mHFvvCE2jwKmBVyZ+7DAqJpP
         6vQQ==
X-Forwarded-Encrypted: i=1; AJvYcCVPqMI6obufd7PR9G9fAq+FXioLccv4qr8aNGaVxNMTnVXF4fAFy+iXaShEdsaHX+Z1rE5hwhSZSwo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwruvLEZ/Jx+L9VefFQtWvLO6LWXsHq3GqFPKUoI55vfeORxaif
	7YSTG4/sAN+s1oSnvv6EqK8yZpL6SlUgmUcSBylFxpUIXmDUDClLOYy8w6YapQSLao9T5QmXDm4
	Adw8=
X-Gm-Gg: ASbGncuBGjtSU0O/17bBovD4u8P2ltgyMu1phMFukF40spPMFY4Ti0lbUghb4z9Foin
	NT5+B/Iu+5f4f3UjG/CdfCbQIJWiS4Pydx3OFM+MM5Pd8/j5HNo74QSzsgneZZSrDuTmvwij1UY
	Yz4bp8F/bBn1YvEZeNGmhGm36yXlVykcT3PqUIYw7zZoFONzvpuyDfc1IV4SNLzXQKnyqlLc8ic
	98TBCkaOGXN6pdPAhC9ZOYGnqdZLwkXIurMRjZ9W46Hbd2TwUZr5a48Ua6Qc3aRRc11K7B6ugZO
	bDmS7I5P9LFmjwn4yCxs4nXjw4nMn67HDNz1rW1DlKZN+pa7Of4HJVLND/eEiTqPz/mScUjtr0t
	n1zJVQnOJJlX3tcTFy0jgjAlAlFXZelTjMW/M
X-Google-Smtp-Source: AGHT+IGqE4ZatBbnWWL5rhY5OrrjQIP4PlN854TkWaAeYJyXCfMfX00b3B48F80qphEDDjhg/+yZVg==
X-Received: by 2002:a17:907:3fa0:b0:ad4:f5f1:28cf with SMTP id a640c23a62f3a-ad50f82067fmr572137866b.25.1747382543774;
        Fri, 16 May 2025 01:02:23 -0700 (PDT)
Message-ID: 
Date: Fri, 16 May 2025 10:02:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/9] x86/mtrr: use memory_type_changed() in
 hvm_set_mem_pinned_cacheattr()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-6-roger.pau@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

On 16.05.2025 09:48, Roger Pau Monné wrote:
> Overall, I have the impression hvm_set_mem_pinned_cacheattr() should
> only be used while building a domain, and hence the flush can likely
> be skipped unconditionally, regardless of the type changes.

See my patch submission, which had this remark:

"Is it really sensible to add/remove ranges once the guest is already
 running? (If it is, limiting the scope of the flush would be nice, but
 would require knowing dirtyness for the domain wrt the caches, which
 currently we don't track.)"

As apparently we both agree, why don't we reject requests post-creation
then, and drop the flush? The one thing I'm uncertain about is whether
the DM would actually have carried out the operation strictly ahead of
the domain being first un-paused.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 08:03:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:03:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986452.1372007 (Exim 4.92)
	(envelope-from )
	id 1uFq21-0004u3-BK; Fri, 16 May 2025 08:03:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986452.1372007; Fri, 16 May 2025 08: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 1uFq21-0004tw-8N; Fri, 16 May 2025 08:03:01 +0000
Received: by outflank-mailman (input) for mailman id 986452;
 Fri, 16 May 2025 08:02:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFq1z-0004kZ-Tw
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:02:59 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2e2d3cb2-322c-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 10:02:58 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5fcc96b6a64so3523241a12.0
 for ; Fri, 16 May 2025 01:02:58 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d080539sm113823866b.66.2025.05.16.01.02.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 01:02: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" 
X-Inumbo-ID: 2e2d3cb2-322c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747382578; x=1747987378; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=VZmLfJIrHVh6aiW+njytaG9i5QdYCwy1E8PQKiz0nDM=;
        b=FeLkTcvYV+NHtmzY904FqHbwMXDjlOjRqtKuDSZguyO9Mj3BuQz/hFpmdZbGhgIdVj
         yJdEtgJ/QFEU5X5LwG7On3TobXSY6ScOMcW1nDR3KlPFTImk8vLZfpRAxrNI5j2jqXuw
         kWbcLYiG+etE+cq8tR4BClGfyY/xxZpQWmzvI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747382578; x=1747987378;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=VZmLfJIrHVh6aiW+njytaG9i5QdYCwy1E8PQKiz0nDM=;
        b=tWg3dK2pMO/H4ViGC+Y6fY9Ci/ByGM7d+Wc7ZkLZlnhN4e3EJndlY94xv1zIExFvmn
         TQr5KLoBmyHnyZIxtNtJOmWVwnMnvUbFrMTInwg2OGUTv2yIqX3swCoNvvdhS9SrcJkl
         xT4j8rNEtpenphW2VhXeEASMMptWYBjwUivSs1rJt3+GTStTuPrsTK8oNqCBubYs3Esc
         bit3qqeYVXWEwjPHTFb5crDPRvut/z7bwYoLZoVS0weXEJx9hvsj7Eacm4y79ghO0e+e
         Xc4Lb+1DaSo5ifI99X67TJhOo6yarPc0E6mRLEWm9kN/ifDOZ7a/8TKhWN3JbG5PyhvF
         nnMQ==
X-Forwarded-Encrypted: i=1; AJvYcCWuQrcunxsaUK8ANWuC4tirQnlTY67UgqqETSsMkxvi7890Mj7SB5dHGqUWYmnooUb4VE/7GNnfWlw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxOvcUaYTsZ1V7CzEdgUJ+x4SObjwVbbzw4atIGQYwI4AjHSvXO
	YZeCxn9lWVyxdzamPgCmUq37V9fZJoGA9OyhNVdqujolqOhkhLe60uFhyLqDsJlT9kc=
X-Gm-Gg: ASbGnctd87hb2gwcF08sI2CKM1bI46vefelq3UbXB0TBUd+igLbzvatGM1x4IP5ofzO
	TmLRipEHoPyrNlGkSigU4eQ1Wss5ssbssX4Ja2onaMlB+yKgHzQQbbjJuePxDKJt7vU7CA0jBnq
	Fr4rVwI4LZve73g0azkEdJxdsCN5rg5Lmfrt7IVGinRhEYYypKPP1w4AKgSBI6OqN2j0k2o27NX
	5culqwF0eqWyw+jmBD0mBbbtIxJifpmjBgS0NsGEmLE48UtHhp3ZIlW8gKpBXnOUvrYWiQ7Vi1i
	jvjnpznBgfL3CddpWKu0pG8joBXd7SxoqjvxwEH+SJ6BbDPihr5Ip1fcQBQBuQU4E3c/pPL8CEl
	gFHl7VRzPRsKbgeIComejWsMNbXIFFA==
X-Google-Smtp-Source: AGHT+IEH5H/0YHS5tfd01keWH6IiwtBO1+bO+w7LN9/yRhvEMjos/6L0jbbV2r49AHi/xJ6McXxOpw==
X-Received: by 2002:a17:907:9628:b0:ad5:10e6:437b with SMTP id a640c23a62f3a-ad52d5d46e6mr277903566b.48.1747382577738;
        Fri, 16 May 2025 01:02:57 -0700 (PDT)
Date: Fri, 16 May 2025 10:02:56 +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 7/9] xen/x86: rename cache_flush_permitted() to
 has_arch_io_resources()
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-8-roger.pau@citrix.com>
 
 
 <205a65d3-92bd-4281-8605-758ca03fcac5@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <205a65d3-92bd-4281-8605-758ca03fcac5@suse.com>

On Fri, May 16, 2025 at 09:07:43AM +0200, Jan Beulich wrote:
> On 15.05.2025 12:28, Roger Pau Monné wrote:
> > On Mon, May 12, 2025 at 05:16:02PM +0200, Jan Beulich wrote:
> >> On 06.05.2025 10:31, Roger Pau Monne wrote:
> >>> To better describe the underlying implementation.  Define
> >>> cache_flush_permitted() as an alias of has_arch_io_resources(), so that
> >>> current users of cache_flush_permitted() are not effectively modified.
> >>>
> >>> With the introduction of the new handler, change some of the call sites of
> >>> cache_flush_permitted() to instead use has_arch_io_resources() as such
> >>> callers are not after whether cache flush is enabled, but rather whether
> >>> the domain has any IO resources assigned.
> >>>
> >>> Take the opportunity to adjust l1_disallow_mask() to use the newly
> >>> introduced has_arch_io_resources() macro.
> >>
> >> While I'm happy with everything else here, to me it's at least on the
> >> edge whether cache_flush_permitted() wouldn't be the better predicate
> >> to use there, for this being about ...
> >>
> >>> --- a/xen/arch/x86/mm.c
> >>> +++ b/xen/arch/x86/mm.c
> >>> @@ -172,8 +172,7 @@ static DEFINE_SPINLOCK(subpage_ro_lock);
> >>>  
> >>>  #define l1_disallow_mask(d)                                     \
> >>>      (((d) != dom_io) &&                                         \
> >>> -     (rangeset_is_empty((d)->iomem_caps) &&                     \
> >>> -      rangeset_is_empty((d)->arch.ioport_caps) &&               \
> >>> +     (!has_arch_io_resources(d) &&                              \
> >>>        !has_arch_pdevs(d) &&                                     \
> >>>        is_pv_domain(d)) ?                                        \
> >>>       L1_DISALLOW_MASK : (L1_DISALLOW_MASK & ~PAGE_CACHE_ATTRS))
> >>
> >> ... cachability, which goes hand in hand with the ability to also
> >> flush cache contents.
> > 
> > Hm, I was on the edge here, in fact I've previously coded this using
> > cache_flush_permitted(), just to the change back to
> > has_arch_io_resources().  If you think cache_flush_permitted() is
> > better I'm fine with that.
> 
> I think that would be better here, yet as you say - it's not entirely
> clear cut either way.

I've reverted this chunk of the change and left the code as-is for the
time being.

> >> Tangentially - is it plausible for has_arch_io_resources() to return
> >> false when has_arch_pdevs() returns true? Perhaps there are exotic
> >> PCI devices (but non-bridges) which work with no BARs at all ...
> > 
> > I guess it's technically possible, albeit very unlikely?  How would
> > the OS interact with such device then, exclusively with PCI config
> > space accesses?
> 
> Yes, that's what I'd expect for such devices. Looking around, there
> are numerous such devices (leaving aside bridges). Just that it looks
> implausible to me that one would want to pass those through to a guest.

Well, we also need to consider dom0 here (either PV or PVH), which
will get those devices passed through.  I assume those are mostly
system devices, and hence there's usually no interaction of the OS
with them.

I'm thinking that our definition of cache_flush_permitted() is not
fully accurate then, we would need to also account for any PCI devices
being assigned to the guest, even if those have no IO resources?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 16 08:05:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:05:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986460.1372017 (Exim 4.92)
	(envelope-from )
	id 1uFq4k-0005fl-NT; Fri, 16 May 2025 08:05:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986460.1372017; Fri, 16 May 2025 08:05: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 1uFq4k-0005fe-Kd; Fri, 16 May 2025 08:05:50 +0000
Received: by outflank-mailman (input) for mailman id 986460;
 Fri, 16 May 2025 08:05:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFq4j-0005fT-7T
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:05:49 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 938e23a9-322c-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 10:05:48 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad53cd163d9so40325066b.0
 for ; Fri, 16 May 2025 01:05:48 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d047cb1sm113826066b.30.2025.05.16.01.05.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 01:05: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" 
X-Inumbo-ID: 938e23a9-322c-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747382748; x=1747987548; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=fyqCvKZE3CbLWKoj2rLeV7NbmPUxeHwiR2HeylYQs4s=;
        b=IWsz91vJaUTQYldIsPEmOfmJcEGC2BPaxq2QtlFEJW7ar8XUC3hxbKtTRlTpbtO4OJ
         lsSo1mPkeOr72Fng7S/kGuKKOFva8n8/QZiRn9foBQNwAtFpYaQz8Nx2qCuKQeJO50OQ
         eOoiM/26aS+ombvkgtiP53odOmyq62Zkj1qdA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747382748; x=1747987548;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=fyqCvKZE3CbLWKoj2rLeV7NbmPUxeHwiR2HeylYQs4s=;
        b=jcsuuGVzAKjilm9tYWl/OWYtS9WWzWrFnqjCXqeXh3tFzhzW/03uBOOnTqyU/dxyng
         D1tT37LWI4z6KJQinwiwvuSzH7krCiIBHU5rxKANpm0m3JnuWIgj8Kv3OCjHwTGgqKG1
         YpBcxBmtbmGuuGbkiKs8Fty9p11xFqMrXDNk6VbAY2b+/t0KJHFLOYb9n2H+ovjvUMim
         f7sxeVZKhwHPTZKsjJAAUAvrJ0D/sVbPIzggOzmNRPZddK6KrKSUOjm8I8PE/p/Cg4OM
         rSxixl9QjsqbSM2xOCyg34quNe6Ypsm0PxeF1mG03xf3JIcEmlRiiPH5y5QN/BeQBQKK
         PMCg==
X-Forwarded-Encrypted: i=1; AJvYcCUK+dzR4YIVpsMw9ZfI25qPzo5KX03bmPyzXPYVcFdAEhKSZ0W26pFhjfb1LpWv8KJ+AcH2YujQmsE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyZbKhjLTe62kWY//X8TVnM9J17xgTm48rkeF2uhMWMztr4nl3d
	Q5/I1p/goFVx2JE8B9QL1fm8TY/SNjHSd4IBinpugwVcoX93JOIGqaMVNMzU98gwWHg=
X-Gm-Gg: ASbGncsz+iyHYqa3FegX+oNWtzqL6X6/6hZsC+7KAQSmLU3EFt3j1YsWC8OFpDQXgZ4
	r4PBSiiqBwD/2NYdRDVCtGkJC/peqWg/bXxgkeijnhcG+Ivlf35k6WaM70H/12L/9nWetCqSLEZ
	hvttGsttYnt5jml5rauYrJX3iicg85bACWBi71S0k5+p6rp/SSO+MrpLJphtSbmjlw2wsOEqD1c
	gHhKjGEguzLLhg/GqektutGQeNhirKE2BGP7YNJOMto8lR/YC7dInPnD5e/EEMJ4fCyMVobw41d
	BypIG0wP+MnMGKn5AimstFC7yHPQhrBPtvtGy+Q0rKReWXCObmTIe7xXdf9UNdTkD292+rDaisb
	VqEa90HL9Stz1x7VGLLA=
X-Google-Smtp-Source: AGHT+IGI1myFVDeswzo1K9UZwYacmSTw5zDXGexAqYFNYhIt5q7rITezhP2SUGELuh+HiH9aj4Q6rQ==
X-Received: by 2002:a17:907:9411:b0:ad1:cd1a:ec8c with SMTP id a640c23a62f3a-ad52d5757e8mr265912566b.44.1747382747983;
        Fri, 16 May 2025 01:05:47 -0700 (PDT)
Date: Fri, 16 May 2025 10:05:46 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	Juergen Gross ,
	Christian Lindig ,
	David Scott ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 8/9] xen: introduce flag when a domain requires cache
 control
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-9-roger.pau@citrix.com>
 
 
 <8f7beebc-643b-4308-b8ff-c0b812eb8d02@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8f7beebc-643b-4308-b8ff-c0b812eb8d02@suse.com>

On Fri, May 16, 2025 at 09:16:10AM +0200, Jan Beulich wrote:
> On 15.05.2025 12:44, Roger Pau Monné wrote:
> > On Mon, May 12, 2025 at 05:24:01PM +0200, Jan Beulich wrote:
> >> On 06.05.2025 10:31, Roger Pau Monne wrote:
> >>> Such flag is added to the domain create hypercall, and a matching option is
> >>> added to xl and libxl to set the flag: `cache_control`.  When the flag is
> >>> set, the domain is allowed the usage of cache control operations.  If the
> >>> flag is not explicitly set, libxl will set it if the domain has any `iomem`
> >>> or `ioports` ranges assigned.
> >>>
> >>> Modify cache_flush_permitted() helper so that it's return value is no
> >>> longer based on the IO resources assigned to the domain, but rather whether
> >>> the domain has been explicitly allowed control over the cache, or if it has
> >>> IOMMU support and there's a single IOMMU in the system that doesn't allow
> >>> forcing snooping behind the guest back.  As a result of this, the return of
> >>> cache_flush_permitted() is constant for the lifetime of a domain, based on
> >>> the domain creation flags and the capabilities of the IOMMU if enabled
> >>> for the domain.
> >>
> >> This then further emphasizes the remark made for patch 7.
> > 
> > Hm, I think you are referring to the remark about how PCI device
> > without IO resources would be handled then, and what would
> > cache_flush_permitted() return then?
> 
> Or more generally the relationship between that and has_arch_io_resources().
> 
> > IMO the benefit of the approach presented here is that it aims to know
> > whether a domain needs cache control to be set at creation time, and
> > not altered during it's runtime.
> 
> I agree that having this not vary over a domain's lifetime makes things easier
> for us. At the same time it may negatively affect performance of domains where
> hardware devices are added / removed on the fly.

I'm planing to leave this change for a further iteration of the
series.  Initially I just want to attempt to limit flushing when the
domain has IOMMU support enabled, and the host globally supports
snooping on all IOMMUs, as that's likely less controversial and would
unblock a customer reported issue.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 16 08:06:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:06:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986469.1372028 (Exim 4.92)
	(envelope-from )
	id 1uFq5G-0006Av-0W; Fri, 16 May 2025 08:06:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986469.1372028; Fri, 16 May 2025 08: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 1uFq5F-0006Ao-SK; Fri, 16 May 2025 08:06:21 +0000
Received: by outflank-mailman (input) for mailman id 986469;
 Fri, 16 May 2025 08:06:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFq5E-0005fT-Cy
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:06:20 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a6260fb5-322c-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 10:06:19 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5fc7edf00b2so2838892a12.2
 for ; Fri, 16 May 2025 01:06: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
 a640c23a62f3a-ad52d4ca2bfsm111403666b.157.2025.05.16.01.06.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 01: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" 
X-Inumbo-ID: a6260fb5-322c-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747382779; x=1747987579; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=P71CORrXcAjS2HNkE4UYt784LxAsBT3j+MQ+sMVtq7k=;
        b=JjfDr/RugsQnpmnghtGDgrtiUVn+ejH42I3dENvBx+fDawyuWd2fs1LE+o/LWgmlJt
         jGjgWv4BnC7lC48fpnvdRlB+MnuO+ud55r1BN5XiuCLNlb56kMSTEtiRH+Wo73grptur
         EJxJaaLJV1mGYqNifgHk1/LsDomWwdHv3+ZYcD1O8OfoAmUIEW5zDct11/F2fceAX7Ut
         rfTzRJNwfcc/b8iCKOobfdJOxe13I3xgqTT049f9KHKBwN/xlCYWlFATzQeFqW+g1zq1
         eUzeLlQ1AVm4NBdx6QxkYcQjP7KLyIn78SScdfYx2zvckz4YG1PoAaIrAyOBpUFzq2zk
         qPBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747382779; x=1747987579;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=P71CORrXcAjS2HNkE4UYt784LxAsBT3j+MQ+sMVtq7k=;
        b=PMdhPlC+CwdrzJLk2owOCV+bRsZcPg+TmCIoUnMKKWrR+DXWKc7RNuunBwqTcZlYFE
         +DxsSpNDGTHh+hHSjgCHwAYBQ2IzUbfxxFXX1jxJaUno5QchH7DIosYyAlKqZDFvdRka
         YoXWaqilQ3Jk4e8X2U4cKg1Ec0CwowRiXd9/7eEJx0rrB7pGd1Kqp0uE1dqqEDtFPfwH
         mxrIBz9qKTMkuJMQUifjWuuGDjWjJk6sjPWidEN5SgI+Hqg3OJXPUwNCU//3gk6VYSk5
         79Qat5tIvuaaUN1VGmUlUvnjoWD8CkTIEJZxZC6/GsDXeIO0vc0q/djqoHGvHnGmZaKZ
         kxCA==
X-Forwarded-Encrypted: i=1; AJvYcCVRbo5kPyxhAeBguxiWUMNBdTeEiszK9HCU5KjEc/nUalFEcOuS5rhxW7hfxxWDUilPQ6hX5DERAEs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyHbOi/nIdVkLcykYlHSM2At+pVPEg3YHslcSjdqXyrVKIsZEw8
	kpXQV4SOjMW3RQwHaWOuJP2BBEBmsrneBOSx/V7Jdkh94d0+uEYBm19Ic1Ti3Tb7mw==
X-Gm-Gg: ASbGncvGkDIFXyInMlJu/lr5Lt3pOEY1Jd8bqyL6ka2C8uPRslEKfFmobB1qRB66Ljt
	ZABHdhtZtGRucdlFOzn4a4uiwaf7Q8Eco5uwSE151y6B32m82OSJ/mpWmPuCReWxs9AnraFlGrz
	xYK7hrqZaqGIhDl10fcqXutuj/qSIlC5SDLCijKdiTGFM0chtHfN8OOSfjBSAsLmMgF/oMMP0SN
	lIn3HYhkETRIkjB29AF30oqPaDsEeX8IR7RU3D5BNb++RcFRiobCZq5ZzyobNrJl9JkV6QxY/EW
	2a1sHG4HfjTqwbPR1iuoLzZ1FR4VdixpJKK+H6zamO8U6n/41bEcBvc+FWMD7E5wibdLRnm6Oct
	/f3Vc2Uve0k+0T1HTwFxT00In0QE4AMQQSVRX
X-Google-Smtp-Source: AGHT+IE4nJKVbwTX9mc8nGAG4QsDlcYiH1QGeBgDscboTFPujPxU+fcgpGDCpu8nIWhDIuiO8aRNbw==
X-Received: by 2002:a17:907:3d4e:b0:ad5:e0f:7850 with SMTP id a640c23a62f3a-ad536bde688mr119178766b.23.1747382779182;
        Fri, 16 May 2025 01:06:19 -0700 (PDT)
Message-ID: <13e936b0-55b6-49d2-9e61-289ee334e51b@suse.com>
Date: Fri, 16 May 2025 10:06:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH for-4.20] x86/emul: Fix emulation of RDSEED with older
 toolchains
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Nicola Vetrini ,
 "consulting @ bugseng . com" ,
 Xen-devel 
References: <20250515195058.3702872-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: <20250515195058.3702872-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.05.2025 21:50, Andrew Cooper wrote:
> This is reported as a MISRA R16.3 (missing break) violation, but turns out to
> be substantially more complicated than expected.
> 
> In commit a8fe4ec5320a ("x86emul: support RDRAND/RDSEED"), the switch()
> statement had a default case going to cannot_emulate, with both the case 6 and
> case 7 labels being fully within #ifdef HAVE_GAS_RD{RAND,SEED}.
> 
> Therefore, when the toolchain didn't understand the RDRAND/RDSEED
> instructions, attempts to emulate them suffered #UD.  (This is arguably a
> problem as there's no interlock to prevent RDRAND/RDSEED being advertied to
> the guest, but as instructions with only register encodings, they can only end
> up being emulated with VM Introspection is in use.)
> 
> In commit 58f1bba44033 ("x86emul: support RDPID"), case 7 was taken outside of
> HAVE_GAS_RDSEED, meaning that emulating an RDSEED instruction no longer hit
> the default case when the toolchain was too old.
> 
> Instead, it would fall out of the switch statment and be completed normally,
> behaving as a NOP to the guest.
> 
> Retrofit a "return X86EMUL_UNIMPLEMENTED" in the case that the toolchain
> doesn't know the RDRAND instruction, matching how RDRAND work.
> 
> Note that this has been fixed differently in Xen 4.21.  Commit
> 05bf9f1f0f52 ("x86/emulate: Remove HAVE_AS_RDRAND and HAVE_AS_RDSEED") has
> removed the problematic condition due to the toolchain baseline upgrade.
> 
> Fixes: 58f1bba44033 ("x86emul: support RDPID")
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Fri May 16 08:08:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:08:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986475.1372036 (Exim 4.92)
	(envelope-from )
	id 1uFq7V-0006i2-AR; Fri, 16 May 2025 08:08:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986475.1372036; Fri, 16 May 2025 08: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 1uFq7V-0006hv-7X; Fri, 16 May 2025 08:08:41 +0000
Received: by outflank-mailman (input) for mailman id 986475;
 Fri, 16 May 2025 08:08:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFq7T-0006hd-3X
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:08:39 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f819cb3a-322c-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 10:08:37 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5feb22e7d84so3526643a12.3
 for ; Fri, 16 May 2025 01:08: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
 4fb4d7f45d1cf-6005ac33a88sm992816a12.51.2025.05.16.01.08.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 01:08: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" 
X-Inumbo-ID: f819cb3a-322c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747382917; x=1747987717; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=NJsIoKxiTjIz4FhDz01fgfOhfoDdugxfkkq8ViNnKhg=;
        b=TQ9CWq8xz6RPiG+FXf81/8TPGsi7dPrUKPNssKasRMccuWXjM2LshMPh0MRzXA359K
         zR1cHXRaJ+a9eHf6bCnvtrdlVQHbjm33O+FeMERCcLMkGWWXnKGnHGRTqqvf2SLaP4xE
         F973v9fQ18PSldp58s4g8IdRw4Rg7n/xCsda51Fp2TGV/rc3ouqeUE/sIxAr+zryOflg
         HNqRxJy5nLbBR/CNzc23nD3tGRoc2eBB3SmFtSxMrn96zFZ5bvOeQF29ZPmi/puICe+h
         ym1tkM24cFtiCnhtGcnzVjUf5BsL9bUz6ZRT99LRj3D2QK0CRy1DLBgoyK65Qa4M5W7W
         FGDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747382917; x=1747987717;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NJsIoKxiTjIz4FhDz01fgfOhfoDdugxfkkq8ViNnKhg=;
        b=KwrHhSHLVRXDOOPizi0LcZfSdsfyaFAIiVrkZFDT/Fl7EIlDVMkuviHSIAnmmAGwEV
         taNS+rVu2EU9j1nCjM4pMe41fvx6qMWjzj5RSbgH97zH7BPLgCMMV0lzekeTXaflF9QB
         qmnu/bjOMieYlh3BNpV9PALBramnmO2gYJO2ZJsFJ/RdSt40/VDZgnyZRAf635co188w
         qVoGKHkLz0xnrbu8ZTFzoCIxtVorv2DUaNshdgAsBrUIBXQKNqszSPQEoOg4Tpy+nmaa
         knuHU6y8Ipnynzqqzlbaf9kevLe6xB8AbC1k7vtKVNUUSgXBQqHGF2BIr5lpkNuX0v3m
         BmWQ==
X-Forwarded-Encrypted: i=1; AJvYcCXlrqoqwXUy44or7FfUHi/dM3CGKuBAvyYEXkbuuAOHcS3mbvcTFO0UVwXz+oWWJqHwzSa9DbY2RBA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6Qu8XH1uGdyxqSipdN+SesUSe9iM2VP3uGeWRsdLU9FV5Ax7V
	Rwam9g6ClkeWIQNEZ84Zc1sH+nrxmV6trOhIc7utTsaxruXje3c8MPlvtkHyBg6NJA==
X-Gm-Gg: ASbGncuGzrKqu4Dajr3BWjkMMqGIclOO5nVTBn5OUCwwRTSZLJR/5XtqCIS8+5hf66/
	rmGjvRwrc8j5ULOLQdrUuLA3gGOLhbmJThT5ZRHjSD8U0p/MjJ9gTy8rOiofFAWTkrjlZrQYvTW
	J59y2dttud5IkJBdPrfMwHru0iDJH6hND4bpZ3mk9tFfAa2+XNO2jd9Cv60DFJppOR2yQo0fVbI
	CLvGmSpEOvS92clvRH2WqW1yGhR5WVU/wL2By5LuuEeUEheZl6aQc7kACw33QRtYJf40/ufQ/Po
	Vf2T3iKYVM/eTeWq+6BII8r+AOWmWybaPGXyekwRaPj1LRiqWPy3LWR9MMXdo1P0xQCOEWwWJrh
	xfoa5j2XGgfbZFtFNQTQ3SZglYAnLaEzhNQs9
X-Google-Smtp-Source: AGHT+IG5p3D//ONcxCWjkT7EvOWt3wlC8dHuoCQSn/fyEuL6zs/LISp1yoWmjuZqSGaxMXBJN7TSMQ==
X-Received: by 2002:a05:6402:42d4:b0:5ff:f524:90e0 with SMTP id 4fb4d7f45d1cf-6008a5a10c5mr1953482a12.11.1747382916628;
        Fri, 16 May 2025 01:08:36 -0700 (PDT)
Message-ID: <9db4a2ce-ba06-42a1-b6e6-7d0c2b59c0c3@suse.com>
Date: Fri, 16 May 2025 10:08:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 7/9] xen/x86: rename cache_flush_permitted() to
 has_arch_io_resources()
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: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-8-roger.pau@citrix.com>
 
 
 <205a65d3-92bd-4281-8605-758ca03fcac5@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

On 16.05.2025 10:02, Roger Pau Monné wrote:
> On Fri, May 16, 2025 at 09:07:43AM +0200, Jan Beulich wrote:
>> On 15.05.2025 12:28, Roger Pau Monné wrote:
>>> On Mon, May 12, 2025 at 05:16:02PM +0200, Jan Beulich wrote:
>>>> On 06.05.2025 10:31, Roger Pau Monne wrote:
>>>>> To better describe the underlying implementation.  Define
>>>>> cache_flush_permitted() as an alias of has_arch_io_resources(), so that
>>>>> current users of cache_flush_permitted() are not effectively modified.
>>>>>
>>>>> With the introduction of the new handler, change some of the call sites of
>>>>> cache_flush_permitted() to instead use has_arch_io_resources() as such
>>>>> callers are not after whether cache flush is enabled, but rather whether
>>>>> the domain has any IO resources assigned.
>>>>>
>>>>> Take the opportunity to adjust l1_disallow_mask() to use the newly
>>>>> introduced has_arch_io_resources() macro.
>>>>
>>>> While I'm happy with everything else here, to me it's at least on the
>>>> edge whether cache_flush_permitted() wouldn't be the better predicate
>>>> to use there, for this being about ...
>>>>
>>>>> --- a/xen/arch/x86/mm.c
>>>>> +++ b/xen/arch/x86/mm.c
>>>>> @@ -172,8 +172,7 @@ static DEFINE_SPINLOCK(subpage_ro_lock);
>>>>>  
>>>>>  #define l1_disallow_mask(d)                                     \
>>>>>      (((d) != dom_io) &&                                         \
>>>>> -     (rangeset_is_empty((d)->iomem_caps) &&                     \
>>>>> -      rangeset_is_empty((d)->arch.ioport_caps) &&               \
>>>>> +     (!has_arch_io_resources(d) &&                              \
>>>>>        !has_arch_pdevs(d) &&                                     \
>>>>>        is_pv_domain(d)) ?                                        \
>>>>>       L1_DISALLOW_MASK : (L1_DISALLOW_MASK & ~PAGE_CACHE_ATTRS))
>>>>
>>>> ... cachability, which goes hand in hand with the ability to also
>>>> flush cache contents.
>>>
>>> Hm, I was on the edge here, in fact I've previously coded this using
>>> cache_flush_permitted(), just to the change back to
>>> has_arch_io_resources().  If you think cache_flush_permitted() is
>>> better I'm fine with that.
>>
>> I think that would be better here, yet as you say - it's not entirely
>> clear cut either way.
> 
> I've reverted this chunk of the change and left the code as-is for the
> time being.

Didn't we agree to use cache_flush_permitted() here instead?

>>>> Tangentially - is it plausible for has_arch_io_resources() to return
>>>> false when has_arch_pdevs() returns true? Perhaps there are exotic
>>>> PCI devices (but non-bridges) which work with no BARs at all ...
>>>
>>> I guess it's technically possible, albeit very unlikely?  How would
>>> the OS interact with such device then, exclusively with PCI config
>>> space accesses?
>>
>> Yes, that's what I'd expect for such devices. Looking around, there
>> are numerous such devices (leaving aside bridges). Just that it looks
>> implausible to me that one would want to pass those through to a guest.
> 
> Well, we also need to consider dom0 here (either PV or PVH), which
> will get those devices passed through.  I assume those are mostly
> system devices, and hence there's usually no interaction of the OS
> with them.
> 
> I'm thinking that our definition of cache_flush_permitted() is not
> fully accurate then, we would need to also account for any PCI devices
> being assigned to the guest, even if those have no IO resources?

I think so, yes.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 08:16:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:16:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986500.1372048 (Exim 4.92)
	(envelope-from )
	id 1uFqEZ-0000KP-6E; Fri, 16 May 2025 08:15:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986500.1372048; Fri, 16 May 2025 08: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 1uFqEZ-0000KI-2P; Fri, 16 May 2025 08:15:59 +0000
Received: by outflank-mailman (input) for mailman id 986500;
 Fri, 16 May 2025 08:15:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFqEY-0000Jw-Fw
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:15:58 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fc318451-322d-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 10:15:53 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ac3eb3fdd2eso374272966b.0
 for ; Fri, 16 May 2025 01:15: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
 a640c23a62f3a-ad52d04f263sm113732766b.1.2025.05.16.01.15.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 01:15: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" 
X-Inumbo-ID: fc318451-322d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747383353; x=1747988153; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=C8F+td71t3yd1OWLfCxdWe/H6jUO8aS9/ZSr2fwhpHo=;
        b=O7iGAsHUBmyqDc9dDNb+hku4bXcS3IhSWhZAZxDHS6wOcdrBCzEldZEUjWXJV4n6b3
         HDDEyPgxybRMJgK7tL19xkM1TLcp7iNKHfFZ1EDeyLWoY12cU+DaJRL60bnwIMS1z1g6
         OfBKIBEYh+5FwU8QsHAxpuxjk/5iikvH9Py65JtAk4Yud+4Ap3KltQrJLaH1q58JBoCF
         jdczgwg4/BKWDrEgPb/Pm1uzu4mtr3Dvix9tBp+wtibiXn59d79P/4GXoQjJj4nd9plz
         V4w+vZgscGenkwsDKwEmebIVO4Qd10/bdQ4SFdegG4XiRZMpKNSdV9VMcXRHpdPl0m58
         oPUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747383353; x=1747988153;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=C8F+td71t3yd1OWLfCxdWe/H6jUO8aS9/ZSr2fwhpHo=;
        b=LyRQ+huXn3x/H28CZprIsm+kSlUvy4BrO+C5Kr+aasG47zdaJT5Jxd0UTW4sWRlX3d
         k0rd9A9loKqBk4KcqnMz6pbxGGepLZEczd9GFunIVKLxOgb+lW4s9k9P8+Op5P2uEZ5p
         100wEAnru8CY5yty5XTj4Y/kR1TjszJEMvBUBOh9bjhSmOW3rIsWBnB+DInUOT5c7i9o
         Cu1G0w9lFbmuK4OslPGOyjEsAGfnxAAHENQgY7KDBunzPqkRCf4HVlFCfCnvhIYn73EL
         kYbPmLrM5IHxbWm3fY7votZnlc5OpJGk1wVwnooZie7QxnCO/dOH9nDRBDDXDAhSq1OB
         2Lbw==
X-Forwarded-Encrypted: i=1; AJvYcCV9Eqovj0mxF41lHUdkyLJiUeGcTxJaW0RBKZUON6ctWREO2lv2yb61DyezybAu7JcXZjpAI0qLWEg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzu1dcICnGJzxGjIh0eHD21/ZPS02wv5DCgBRwJT75qdMe+Xqgm
	fYAZDZ91+dJoFrZAQfSunQ/ny+62XAOtBjrde79EAtHBAwOhJ7GSU5SueAzf+u571Q==
X-Gm-Gg: ASbGncuG8+/9MRirAsUlvKZLeWjh188LZtsmKE0qMzTKbRgXjD405Ha0+psyco/WBaD
	SLxkWBetMLvfekQKj/DYTRMHsc8m1GNpXTFoi2R25Gr+exOe0+vUx4E65p1kzieirPaNzXEVKkE
	i0XVCNrO0mER52WDCmCr/b7zMmgZr1bTTNtSiRtKIPB0wA1j7Sis3v03e7bNgXkJgTA0YIcspEX
	8oB20LzSGoamAKhnurRf3yp9CeiYoMuh1GTeMMZ6erR/lhtUY+B6FqnWFmy8IvzCdMuLUprwHI8
	iY12846hGqFl/Li5T71wfkfMGjiIWk2eRa2cRugb7FbD0S23+oMr/c7jVBOUQXw+Z69D5JRFUNk
	JbQKdofuzON2ImD68STJ0L3F7YtIqAiimN7uRgMwTVqogXWU=
X-Google-Smtp-Source: AGHT+IFk9r8RnRlXuzO4YQDRihSRbXjXxSdds7B2ivWngvK2xi/d7tyDOgigo+6EZou1mlIkvx16dg==
X-Received: by 2002:a17:907:94d2:b0:ad2:4d23:eddd with SMTP id a640c23a62f3a-ad52d5dec95mr209035066b.59.1747383352997;
        Fri, 16 May 2025 01:15:52 -0700 (PDT)
Message-ID: <01498be0-979a-4b89-a70b-050ddb5ad1b3@suse.com>
Date: Fri, 16 May 2025 10:15:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] xen: Introduce asm inline and use it for BUG_FRAME
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , Julien Grall ,
 Volodymyr Babchuk ,
 Bertrand Marquis ,
 Michal Orzel ,
 Xen-devel 
References: <20250515195549.3703017-1-andrew.cooper3@citrix.com>
 <20250515195549.3703017-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: <20250515195549.3703017-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.05.2025 21:55, Andrew Cooper wrote:
> Compilers estimate the size of an asm() block for inlining purposes.
> 
> Constructs with embedded metadata (BUG_FRAME, ALTERNATIVE, EXTABLE, etc)
> appear large, depsite often only being a handful of instructions.  asm
> inline() overrides the estimation to identify the block as being small.
> 
> This has a substantial impact on inlining decisions, expected to be for the
> better given that the compiler has a more accurate picture to work with.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Fri May 16 08:18:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:18:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986516.1372058 (Exim 4.92)
	(envelope-from )
	id 1uFqH9-0000tF-J3; Fri, 16 May 2025 08:18:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986516.1372058; Fri, 16 May 2025 08: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 1uFqH9-0000t8-Ec; Fri, 16 May 2025 08:18:39 +0000
Received: by outflank-mailman (input) for mailman id 986516;
 Fri, 16 May 2025 08:18:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFqH8-0000t2-0S
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:18:38 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5da24937-322e-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 10:18:37 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-6000f2f217dso2543185a12.1
 for ; Fri, 16 May 2025 01:18: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
 a640c23a62f3a-ad52d4e8afdsm113574666b.176.2025.05.16.01.18.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 01:18: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" 
X-Inumbo-ID: 5da24937-322e-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747383516; x=1747988316; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=RLdynXKe20zcP5Gfv3cqwl+P6cxNHLI/U7xpxxCsYfw=;
        b=ONKSQlYbcSgsAEF84Cx8pNS/rPco0opUknq+rfxCFDLtCACqv6f1qlGFR/6QapHrJK
         GWC3mThilmCH8f22Yl4WIE7uMqf3diRLj6YmGA3caGUwVMKUqzKc5dM1t8nBUHmSHh6s
         lT4rX7nMvhq4QWsOp2bF35GS4xOmaCzevhIwZ3RxaOOTu9rvnmN+WWELyBBdwg0JKYj1
         hynr9y/5Rk8GsUs2i6T0bGzdZ1aalOpK3EGK8xcP+ez5ffTF+MwQISLARNU7eu1xO06o
         MpKs7nQ2EYR7TJX/AE7/y6fqVJKiF2027H3eIlQsoeJ87bNU88cB1lMJWOT07yoWH/se
         Yexg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747383516; x=1747988316;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=RLdynXKe20zcP5Gfv3cqwl+P6cxNHLI/U7xpxxCsYfw=;
        b=HmWaYfAUebdKlcFdwLMZL9Vuuzpy0hrVLrbOlenEDFVgdpucxgtVIilWwQp/tLMQLv
         JA9RJzqWo2+aV6ufLFmCGtvXpDeo8F1eaTQNx5yltN8gy/IyyVbpTvH8MJr2sEJWrbVI
         u+KRCDpXrlXyfsITsQiaQu05x+VTOHpU6tu6Kw7TFTZs3uXxmKwhvdczg5g3grw3WxFy
         NJZeIHMTPNaCI5BOdrsLVcolGJ+6doAT9g6L6UEFhFZbiyINhKufYRgWecXUIq2lLC6y
         aGSVE1F8B0pO9hIvpV+Pc1nb2QdZFkfkGqCRu3ETkHj/AS77T2YqTxje7JRxeQ8MlsFS
         h8nw==
X-Forwarded-Encrypted: i=1; AJvYcCWGXtxwjvveM2cUwa5AfO0h1L/4ZMDi+yC3SrT9P6SM2RifOQv6P7RgKCKUdmqW+o9BWOU134UPP4g=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxg53AyYgJK72QW6SGsOTSucNewfvxC/A7qHHaRezwkj+tqdBTa
	JKLCp7Bt7wkqNaYd5Dl4PRYXab5Dke18b/gpL6ALtO23cISxQGn5t4XPEOi1krtuGw==
X-Gm-Gg: ASbGncvM+wxDNF3vbUMMV+eVXMS8qmBQb7xILNJ2watAeU4OszJlx1eFC9EmybenexR
	WSPntZpR3atlDps+mJoaLxJT1sLl5xFJQEa3xJYSPsZAZdIXFO77ySGo7Hh8dsSH0FoGqeYRbvv
	BOJ8vemYTWkD34vo795CS5o7YVF8S+P+XANbmPoRFNosFXOingD9KCaHaTI2t+Q3c6pD9SfQk//
	lyuzbIIcKUaB40XJOp3OGRZWW71UotUGqJlM3pV6H8SoOG+BcGD5qpbbSTk2ilVjlcmB+SYjuEo
	+H43zxniv1GqqCffqgpCyGJMXevmvL8B6meqMSisOaRGELlZeKGsPK6BYibl0XoAuHrvjowRwjv
	LVLlPmZwzgAMrgEZ22WdNqFbSN03rxu5YItjZ
X-Google-Smtp-Source: AGHT+IGSFg1Txe+2hLHN5G30As69oenAqX1emXbCBFcP1Ib4t05rSF2vnOn20jUuUISOHGGhkb6n4A==
X-Received: by 2002:a17:907:9308:b0:ad5:2b74:da86 with SMTP id a640c23a62f3a-ad52d608aadmr230142566b.55.1747383516543;
        Fri, 16 May 2025 01:18:36 -0700 (PDT)
Message-ID: <70508277-6841-4cea-aecc-614834d8fe62@suse.com>
Date: Fri, 16 May 2025 10:18:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/3] x86: Use asm_inline for ALTERNATIVE() and EXTABLE
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , Julien Grall ,
 Volodymyr Babchuk ,
 Bertrand Marquis ,
 Michal Orzel ,
 Xen-devel 
References: <20250515195549.3703017-1-andrew.cooper3@citrix.com>
 <20250515195549.3703017-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: <20250515195549.3703017-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.05.2025 21:55, Andrew Cooper wrote:
> ... when there really are only a few instructions in line.
> 
> In some cases, reformat to reduce left-hand margine space.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Fri May 16 08:24:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:24:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986523.1372067 (Exim 4.92)
	(envelope-from )
	id 1uFqMf-0002lW-4A; Fri, 16 May 2025 08:24:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986523.1372067; Fri, 16 May 2025 08: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 1uFqMf-0002lP-16; Fri, 16 May 2025 08:24:21 +0000
Received: by outflank-mailman (input) for mailman id 986523;
 Fri, 16 May 2025 08:24:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFqMd-0002lH-Ma
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:24:19 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 28a1e68b-322f-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 10:24:17 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a0b9af89f2so1148204f8f.3
 for ; Fri, 16 May 2025 01:24:17 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca8d130sm2065996f8f.95.2025.05.16.01.24.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 01:24: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" 
X-Inumbo-ID: 28a1e68b-322f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747383857; x=1747988657; darn=lists.xenproject.org;
        h=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;
        bh=yyDVuf0qkfkehxoWw8Xm+qymKJHEo8e6iJFeTQOCrSY=;
        b=gLhV0YbeyD/R+X1T3VYQQ2GQSotiA9FYaCy2lRvJsbDHgR3KW0AGyu9e85+jbAJKuE
         EMwFsVtu8l1CO7Y6uJ40iID8Xh9/WfU0QbU9wg3kQrN/VR15pRyNw3iARTNNce5CpCfN
         Fr175fwTB/7FAIVqJ4oZE/G7aTehnav++9biTb5MFJyUlTypy5iaY2cO2ulg/Bv/rZ74
         4SZS2o5BObY60dyyDjyScpMJTG72d3hHkhcAG1nstDRaopqruWeCl2X3/z2XSZ9KmNgF
         JXoM28MSpXpdhht151p2c31weGk7vbFMk7K9GvdKMWzK+adUx4LiwKli7wmDZ6D6E+WK
         yQgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747383857; x=1747988657;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=yyDVuf0qkfkehxoWw8Xm+qymKJHEo8e6iJFeTQOCrSY=;
        b=jpexkVNA/Kto+6GH8o/tmy15S63GrvVKGxZHJP57s4KHtnjTENG5tZq9ELXhFtn/oc
         om0rEt5yQcTbJOx07XFyFbn7L0cyrTFk05EBUf6qt/RMTMzwsJT2Vxv60ZEn6h8YW53w
         pOH4eWEvjg+33Usk9XKO8+Dp/FcPUUzrbAkOGNaXF71yHe5P2Dj474aS0oi+ikUcCqWf
         cH37U2bqAd3lZ4/9yc7mh10pilsZA3o62Htc7R3fijrmTP3BJfdavMBtJBK5br+RuwFJ
         8e1FJdhahXdJZbHp0c2vmOThZaF27/f9U3F3qZ8KNz0ruGm9Uuxvv3/tFtckEj4Rll2A
         rlKg==
X-Forwarded-Encrypted: i=1; AJvYcCVS1ZKdT6d0SDCb7/0fr7zgYkBUB9wG2IhOuflI43XFyKoTnEJQ+TEJWUsbyWxF5lJm6ctDwKvzTiQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOJv2H7phf7wv1evHBq65IAgBRCOJfPyBWnljpJaOeuNYi0G+X
	pWhkB5AQ05er18FmANUP48myOfXwJ49y8munaJey04ESWGeqdGAfB3dJ
X-Gm-Gg: ASbGncsQHOIN4viFaoGH56Sx/r2xIejqh0Q0ni33RDCv0zt5C8LJnliuZrgmUf97xwx
	5fYUsQJNGl8aMOEIdmJMeG22MDQuZcmaUaPSCDkVfAImsqmCSLyCAKfuMfHF0re2qgPB3SYYRx2
	XmToDl9lwCndhzK+JPSVlwmd4u2BoqS8ERuMb3k/RzkfeKbA0Ii+j2CP4WK0gqHk0aA8pu+a1mU
	RNd5S2/EKFp44BLfnQmp90J5ynntRl3J2QXnU8R2mpkvf8S53bBntEQAquEhcmN4LMxWg6TitZC
	nSVxlUSVaSmn0dFpfCeHdKvAXCWHKSDmE5UC7kSy1FvlC0GI9tOnR2DXs7COmPdn8B1HcMlq9zG
	9ldn0karwZ24MOvoGRpi/uf5I
X-Google-Smtp-Source: AGHT+IEM5s8CB2USe78YYsmQSIZTz0iVYGxQ1MEOJab11Ei+HKVGSuCqX+YISwwAyHvx/jqdmKts0g==
X-Received: by 2002:a05:6000:290d:b0:3a3:5bf8:3709 with SMTP id ffacd0b85a97d-3a3600dc277mr1300021f8f.56.1747383856788;
        Fri, 16 May 2025 01:24:16 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------q3Tho88j40DcoSNjc6IBRjhx"
Message-ID: <23156520-4252-4db3-b0f7-5bcd000bc677@gmail.com>
Date: Fri, 16 May 2025 10:24:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/16] xen/riscv: introduce smp_prepare_boot_cpu()
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <704550ffbb34c94bfe85be928b2fcc0105552e82.1746530883.git.oleksii.kurochko@gmail.com>
 <3e849625-582a-4e5e-b2c2-b3eb16aae857@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <3e849625-582a-4e5e-b2c2-b3eb16aae857@suse.com>

This is a multi-part message in MIME format.
--------------q3Tho88j40DcoSNjc6IBRjhx
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/13/25 5:48 PM, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> @@ -72,6 +72,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>>   
>>       remove_identity_mapping();
>>   
>> +    smp_prepare_boot_cpu();
>> +
>>       set_processor_id(0);
>>   
>>       set_cpuid_to_hartid(0, bootcpu_id);
> Is this a good placement? I'd think that smp_prepare_boot_cpu() ought to be
> permitted to rely on set_processor_id() already having run, for example (even
> if right now there's no such dependency). Alternatively the set_processor_id()
> call may want to move into the new function?

Agree, logically it would be better to set processor id before smp_prepare_boot_cpu().

I'll move set_processor_id(0) inside smp_prepare_boot_cpu().

Thanks.

~ Oleksii

--------------q3Tho88j40DcoSNjc6IBRjhx
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/13/25 5:48 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    @@ -72,6 +72,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     remove_identity_mapping();
 
+    smp_prepare_boot_cpu();
+
     set_processor_id(0);
 
     set_cpuid_to_hartid(0, bootcpu_id);

    
      
    
      
    Is this a good placement? I'd think that smp_prepare_boot_cpu() ought to be
permitted to rely on set_processor_id() already having run, for example (even
if right now there's no such dependency). Alternatively the set_processor_id()
call may want to move into the new function?
    
    
    
    
    Agree, logically it would be better to set processor id before smp_prepare_boot_cpu().

I'll move set_processor_id(0) inside smp_prepare_boot_cpu().

Thanks.

~ Oleksii
    
  


--------------q3Tho88j40DcoSNjc6IBRjhx--


From xen-devel-bounces@lists.xenproject.org Fri May 16 08:28:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:28:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986531.1372076 (Exim 4.92)
	(envelope-from )
	id 1uFqQ6-0003K4-Hb; Fri, 16 May 2025 08:27:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986531.1372076; Fri, 16 May 2025 08:27: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 1uFqQ6-0003Jx-F2; Fri, 16 May 2025 08:27:54 +0000
Received: by outflank-mailman (input) for mailman id 986531;
 Fri, 16 May 2025 08:27:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFqQ4-0003Jo-Vp
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:27:53 +0000
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com
 [2607:f8b0:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a4eab432-322f-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 10:27:47 +0200 (CEST)
Received: by mail-pl1-x633.google.com with SMTP id
 d9443c01a7336-22e70a9c6bdso26140475ad.3
 for ; Fri, 16 May 2025 01:27:47 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-231d4b04a52sm9698075ad.91.2025.05.16.01.27.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 01:27: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" 
X-Inumbo-ID: a4eab432-322f-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747384065; x=1747988865; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=No2J97VVo34lpGPj1OLahXjfVgF6G6x9vrV27z9sLa8=;
        b=OejU0vJTztMLn3Tm4qFS2CofNH87gDL9+mHz11wqV6pUFYkMeWS+fnbFTUtqzDxypA
         QwSP8AvhWBsb3Im4k0P6ClFAxvXnRJ1i0wqvjJsUplgQhDpu91XBCulPK86nuva8Pa+Z
         A7bcakSmNAnpEzTQlwfCzrPO2aqygAMoCDsww=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747384065; x=1747988865;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=No2J97VVo34lpGPj1OLahXjfVgF6G6x9vrV27z9sLa8=;
        b=E/kFqXdEcyww9+8O+zOJjYYJzinXTDQsq08wb6Kme78XQUUBWykTHqH7EAlBl5axDu
         W3zmTmE91LF98HnrRaPmlljCX2Hd0zf1nxZNEAaO8EcNUggPHARpRvz8NfKsTjZLkfMW
         +BaEeFYJdj4blFzJcWcm2/6tTLnJE7wRzcv9LaMjR2rQhCYq5u/zxMgXbxif9ZtZ9x93
         lm5Yjd3yzmzvIOOuDsygXu8lcAa6lr8SLuITslLiKm3bHpGozD31KCm/s67U3h+ThOnD
         shbnCJJmoJxcHX0YT1GjpWyTee7xQPCuKfZl3Lcgfe0iLSOSRPkxCYgJGHdlVjYtT7Fv
         zD/A==
X-Forwarded-Encrypted: i=1; AJvYcCVMCft55HfooEo3xdHJecQ8HerU5pc3m8y2xXCH+kp0KZ6D1A2MHu0HzEidMzCs0mV5nLft4X9+TMk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyOxAQOLv+T/ev4ekpcFghWIvRAT6KeVaOEkyEruhVDvCo7+sFm
	VtfRqedzQq1BwMoKz7j3ITiElRa94b6C1bVHXDvGP4eMlT7nWbObarVyhf3SksW46W4=
X-Gm-Gg: ASbGncuMpcrDvrQ8vBuQKGmZUYqxoRhJ+hGxQltEkYT33HQcVzqUZXHc6zzD1GnK8uW
	wqVMuRJkRZyw/dbJCfqqwCPEqKWjhE9P1z8xYf6AyRqbHOpxzG4jqCr1YzUqSUNXF2GoOrc/Sit
	PV1daaesJ3YFdFxTvRUkH90BKrXPJA7rtIz1NovSWFJB7vneMGwW3yVp4GpnDvHbfSAah3MHvI0
	rGe8pxNqn+B8a4dTZWiJsQl3K6XR/OrYEa/JV0rjBd6z1eRwjNsnW+PfLaJahjeIrgBt1MVEEI8
	QN5AxA/FkVUZsr0t1xIGwZTSUrp4zwm+5St1ExC6tndCuRrtoXl/ZwoCRgX8SxYTAgHdlRJx4wn
	KpMiHsWye87qel3wy6CA=
X-Google-Smtp-Source: AGHT+IF9k9eYvlatFMJyw5kjCvOKBEZ3ZMiV/65/eNBcn23g/m3iQVS3b+FmJgMr8E9KzOazTtuYoA==
X-Received: by 2002:a17:903:94e:b0:224:910:23f0 with SMTP id d9443c01a7336-231d45bcdffmr32424475ad.49.1747384065191;
        Fri, 16 May 2025 01:27:45 -0700 (PDT)
Date: Fri, 16 May 2025 10:27:39 +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 7/9] xen/x86: rename cache_flush_permitted() to
 has_arch_io_resources()
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-8-roger.pau@citrix.com>
 
 
 <205a65d3-92bd-4281-8605-758ca03fcac5@suse.com>
 
 <9db4a2ce-ba06-42a1-b6e6-7d0c2b59c0c3@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9db4a2ce-ba06-42a1-b6e6-7d0c2b59c0c3@suse.com>

On Fri, May 16, 2025 at 10:08:35AM +0200, Jan Beulich wrote:
> On 16.05.2025 10:02, Roger Pau Monné wrote:
> > On Fri, May 16, 2025 at 09:07:43AM +0200, Jan Beulich wrote:
> >> On 15.05.2025 12:28, Roger Pau Monné wrote:
> >>> On Mon, May 12, 2025 at 05:16:02PM +0200, Jan Beulich wrote:
> >>>> On 06.05.2025 10:31, Roger Pau Monne wrote:
> >>>>> To better describe the underlying implementation.  Define
> >>>>> cache_flush_permitted() as an alias of has_arch_io_resources(), so that
> >>>>> current users of cache_flush_permitted() are not effectively modified.
> >>>>>
> >>>>> With the introduction of the new handler, change some of the call sites of
> >>>>> cache_flush_permitted() to instead use has_arch_io_resources() as such
> >>>>> callers are not after whether cache flush is enabled, but rather whether
> >>>>> the domain has any IO resources assigned.
> >>>>>
> >>>>> Take the opportunity to adjust l1_disallow_mask() to use the newly
> >>>>> introduced has_arch_io_resources() macro.
> >>>>
> >>>> While I'm happy with everything else here, to me it's at least on the
> >>>> edge whether cache_flush_permitted() wouldn't be the better predicate
> >>>> to use there, for this being about ...
> >>>>
> >>>>> --- a/xen/arch/x86/mm.c
> >>>>> +++ b/xen/arch/x86/mm.c
> >>>>> @@ -172,8 +172,7 @@ static DEFINE_SPINLOCK(subpage_ro_lock);
> >>>>>  
> >>>>>  #define l1_disallow_mask(d)                                     \
> >>>>>      (((d) != dom_io) &&                                         \
> >>>>> -     (rangeset_is_empty((d)->iomem_caps) &&                     \
> >>>>> -      rangeset_is_empty((d)->arch.ioport_caps) &&               \
> >>>>> +     (!has_arch_io_resources(d) &&                              \
> >>>>>        !has_arch_pdevs(d) &&                                     \
> >>>>>        is_pv_domain(d)) ?                                        \
> >>>>>       L1_DISALLOW_MASK : (L1_DISALLOW_MASK & ~PAGE_CACHE_ATTRS))
> >>>>
> >>>> ... cachability, which goes hand in hand with the ability to also
> >>>> flush cache contents.
> >>>
> >>> Hm, I was on the edge here, in fact I've previously coded this using
> >>> cache_flush_permitted(), just to the change back to
> >>> has_arch_io_resources().  If you think cache_flush_permitted() is
> >>> better I'm fine with that.
> >>
> >> I think that would be better here, yet as you say - it's not entirely
> >> clear cut either way.
> > 
> > I've reverted this chunk of the change and left the code as-is for the
> > time being.
> 
> Didn't we agree to use cache_flush_permitted() here instead?

I think it would be a bit weird, if we want this to be a
non-functional change we would need to keep the has_arch_pdevs()
condition because cache_flush_permitted() doesn't take that into
account.  Or we need to adjust cache_flush_permitted() to also take
has_arch_pdevs() into consideration.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 16 08:32:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:32:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986538.1372087 (Exim 4.92)
	(envelope-from )
	id 1uFqUI-0005EO-1j; Fri, 16 May 2025 08:32:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986538.1372087; Fri, 16 May 2025 08:32: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 1uFqUH-0005EH-Ur; Fri, 16 May 2025 08:32:13 +0000
Received: by outflank-mailman (input) for mailman id 986538;
 Fri, 16 May 2025 08:32:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFqUG-0005EB-4c
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:32:12 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 42f8a941-3230-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 10:32:11 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5f62d3ed994so3438674a12.2
 for ; Fri, 16 May 2025 01:32:11 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 4fb4d7f45d1cf-6005a6dfd50sm1024554a12.34.2025.05.16.01.32.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 01:32: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" 
X-Inumbo-ID: 42f8a941-3230-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747384330; x=1747989130; 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;
        bh=4dlsHrKY+Gx86Elbji/GCycF9KX+wzlaT3AAVeSqxvY=;
        b=hkIl8deSdqy3+b4Ozp+JK0AsorZklDNSDrv2D9jdBRvUtlbdbFlcJs2yOIlQla/aeD
         55ZxNq4Ebw5pP6HXTBPQy0oSfgPO3p9iZnAfrTBQjWXbVFy/59qJDbxGgfzkpt7z3DSw
         HSlBTY9KfiFU8kU9Wxl4Yuo9Wuf4EY8HHjra4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747384330; x=1747989130;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=4dlsHrKY+Gx86Elbji/GCycF9KX+wzlaT3AAVeSqxvY=;
        b=S7mOr6Cm+JQHeufPunZDUWlG2NsFcGlu+BfLYeW3hZP4pgP+Fei4Ge/9Czz+ktVnot
         pslYQQurr+QH2rSMAw1WBeoe9jq+lEdseCK2sjEbCyfFdveNRwZ+nT6a8JAMqn4dYbzk
         KjpaMkCAn4e7v+dmQzfFFW9r0hHaZ3ck6yXxE0cNcg2Q3wH4lU5ODq35os8wB3jtusrX
         TOOvNX3WhxGc3223/aoOo/Y9/UISPWsQMN/FJuajI42LdSHCvpN9fokzBhBet6O6/pjy
         0zPFzGxBlyavEuE4ANUbtE7MfaFL9n4PLgmELnSf2Yo7KjuEzW0Nh5YUKUVZmTWC9UYz
         vrXA==
X-Gm-Message-State: AOJu0YxJM/ADbtxhnzQv63aibWMJNvAM8SATSwQy9R25o/yzHv10c9vo
	qmU84uVBTEQCgxY88EjIeUVxtHmYWRolAvDoMe/qciuiAo8TbadnZT4yiE0kA59gfiQNRBXarDO
	q66Gc
X-Gm-Gg: ASbGncsccNHAw0GnVOdwj9VXypXReSPFDkWQ2NfeYCg5nBmy2w3IlJTMX5ZUUO+XnuJ
	aMt/ihksNh1ylbtU146LFTysFvov97wqPIBTHY6HM/WNh8QaPiLQDgTtKNUuM/ih8bMtWZarN9b
	O+PyEWZyNY/agZOS6yzoirgX/nuT+kllHDvP0ipPJ/B75bX5ZJwhdLuMwB+Dy60rnGNZQmYteiz
	pEGPnH0hM6YkVhiSFr1JbGawWkvp4/9wirwvNQnumqlgsD2ZACEbKEsXg8oVp8seRl6kxes4NiV
	6DKLTd8egWKB5jPFeHnrJ/nLONYbUZZRJl+yCT3Hp34MaD4flnqbWei8WEm1kn7qFa1fPvZK1N+
	u6Fca3u6NWuf4aW6fAIU=
X-Google-Smtp-Source: AGHT+IEs2tOTsSb8P7FFYMod8nw81xrhdtjBdt6FXKUjoWsYH6e5lSjTc9AZn37lBvXOBfJi3ZSk3A==
X-Received: by 2002:a05:6402:40d3:b0:5fe:e999:e553 with SMTP id 4fb4d7f45d1cf-600900f4c4bmr1951513a12.23.1747384329916;
        Fri, 16 May 2025 01:32:09 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Jan Beulich ,
	Andrew Cooper ,
	Stefano Stabellini ,
	Victor M Lira 
Subject: [PATCH v2] x86/vpci: fix handling of BAR overlaps with non-hole regions
Date: Fri, 16 May 2025 10:31:59 +0200
Message-ID: <20250516083159.61945-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

For once the message printed when a BAR overlaps with a non-hole regions is
not accurate on x86.  While the BAR won't be mapped by the vPCI logic, it
is quite likely overlapping with a reserved region in the memory map, and
already mapped as by default all reserved regions are identity mapped in
the p2m.  Fix the message so it just warns about the overlap, without
mentioning that the BAR won't be mapped, as this has caused confusion in
the past.

Secondly, when an overlap is detected the BAR 'enabled' field is not set,
hence other vPCI code that depends on it like vPCI MSI-X handling won't
function properly, as it sees the BAR as disabled, even when memory
decoding is enabled for the device and the BAR is likely mapped in the
p2m.  Change the handling of BARs that overlap non-hole regions to instead
remove any overlapped regions from the rangeset, so the resulting ranges to
map just contain the hole regions.  This requires introducing a new
pci_sanitize_bar_memory() that's implemented per-arch and sanitizes the
address range to add to the p2m.

For x86 pci_sanitize_bar_memory() removes any regions present in the host
memory map, for ARM this is currently left as a dummy handler to not change
existing behavior.

Ultimately the above changes should fix the vPCI MSI-X handlers not working
correctly when the BAR that contains the MSI-X table overlaps with a
non-hole region, as then the 'enabled' BAR bit won't be set and the MSI-X
traps won't handle accesses as expected.

Reported-by: Stefano Stabellini 
Fixes: 53d9133638c3 ('pci: do not disable memory decoding for devices')
Signed-off-by: Roger Pau Monné 
Tested-by: Victor M Lira 
---
Changes since v1:
 - Use a forward declaration for struct rangeset instead of including the
   header.
---
 xen/arch/arm/include/asm/pci.h |  3 ++
 xen/arch/x86/include/asm/pci.h | 13 +++------
 xen/arch/x86/pci.c             | 50 ++++++++++++++++++++++++++++++++++
 xen/drivers/vpci/header.c      |  9 ++++++
 4 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
index 7f77226c9bbf..1605ec660d0b 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -128,6 +128,9 @@ int pci_host_bridge_mappings(struct domain *d);
 
 bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
 
+static inline int pci_sanitize_bar_memory(struct rangeset *r)
+{ return 0; }
+
 #else   /*!CONFIG_HAS_PCI*/
 
 struct pci_dev;
diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h
index fd5480d67d43..bed99437cc3b 100644
--- a/xen/arch/x86/include/asm/pci.h
+++ b/xen/arch/x86/include/asm/pci.h
@@ -57,14 +57,9 @@ static always_inline bool is_pci_passthrough_enabled(void)
 
 void arch_pci_init_pdev(struct pci_dev *pdev);
 
-static inline bool pci_check_bar(const struct pci_dev *pdev,
-                                 mfn_t start, mfn_t end)
-{
-    /*
-     * Check if BAR is not overlapping with any memory region defined
-     * in the memory map.
-     */
-    return is_memory_hole(start, end);
-}
+bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
+
+struct rangeset;
+int pci_sanitize_bar_memory(struct rangeset *r);
 
 #endif /* __X86_PCI_H__ */
diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
index 97b792e578f1..afaf9fe1c053 100644
--- a/xen/arch/x86/pci.c
+++ b/xen/arch/x86/pci.c
@@ -98,3 +98,53 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
 
     return rc;
 }
+
+bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
+{
+    /*
+     * Check if BAR is not overlapping with any memory region defined
+     * in the memory map.
+     */
+    if ( !is_memory_hole(start, end) )
+        gdprintk(XENLOG_WARNING,
+                 "%pp: BAR at [%"PRI_mfn", %"PRI_mfn"] not in memory map hole\n",
+                 &pdev->sbdf, mfn_x(start), mfn_x(end));
+
+    /*
+     * Unconditionally return true, pci_sanitize_bar_memory() will remove any
+     * non-hole regions.
+     */
+    return true;
+}
+
+/* Remove overlaps with any ranges defined in the host memory map. */
+int pci_sanitize_bar_memory(struct rangeset *r)
+{
+    unsigned int i;
+
+    for ( i = 0; i < e820.nr_map; i++ )
+    {
+        const struct e820entry *entry = &e820.map[i];
+        int rc;
+
+        if ( !entry->size )
+            continue;
+
+        rc = rangeset_remove_range(r, PFN_DOWN(entry->addr),
+                                   PFN_UP(entry->addr + entry->size - 1));
+        if ( rc )
+            return rc;
+    }
+
+    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/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index ef6c965c081c..1f48f2aac64e 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -394,6 +394,15 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
                 return rc;
             }
         }
+
+        rc = pci_sanitize_bar_memory(bar->mem);
+        if ( rc )
+        {
+            gprintk(XENLOG_WARNING,
+                    "%pp: failed to sanitize BAR#%u memory: %d\n",
+                    &pdev->sbdf, i, rc);
+            return rc;
+        }
     }
 
     /* Remove any MSIX regions if present. */
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 08:36:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:36:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986561.1372096 (Exim 4.92)
	(envelope-from )
	id 1uFqYO-0005sI-Jp; Fri, 16 May 2025 08:36:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986561.1372096; Fri, 16 May 2025 08:36: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 1uFqYO-0005sB-H8; Fri, 16 May 2025 08:36:28 +0000
Received: by outflank-mailman (input) for mailman id 986561;
 Fri, 16 May 2025 08:36:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFqYN-0005s5-Up
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:36:27 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d8490051-3230-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 10:36:21 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-6000f2f217dso2576214a12.1
 for ; Fri, 16 May 2025 01:36: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
 a640c23a62f3a-ad52d047754sm116547466b.7.2025.05.16.01.36.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 01:36: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" 
X-Inumbo-ID: d8490051-3230-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747384581; x=1747989381; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8bwWom9M2XFqFg597hu7e+15n3vsPX9sMRocMuN2nII=;
        b=XR/o4XZ/NuTG2gEE5Bx1/rZLvWmhZh+VUacyfo7Ws0YKZyMHXYGX6ThmRMF0yMHDtb
         A2l0H8jtFCCQOU/pK88cIQwSqF315PbiaNsNz4fM4IhIsYfug3pH5FXhOGYTvCTWZlZl
         BsDBV8OWYGiD6PJBDF3pkOkRySq7Pj7Cf8N/uiQOP6IUaoAfrXWgwCSmEwpAoYbU41aR
         O24G/IHWvqrTku2aPb4HfJyd82QwKoWoj31DWE033QzcruyBXMZ0d76jqSfgUU6zvLDT
         a92Mh8jVigSuq0BE/jqMli/kLWDCG1BLfdLf12ayxBFE7MW7j1MpvuyxriibBTTnys8x
         XTTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747384581; x=1747989381;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8bwWom9M2XFqFg597hu7e+15n3vsPX9sMRocMuN2nII=;
        b=NDdRQ6utcVKCd6hNhuOP8DyEoeYHhZKcyA7VOIjCEPwjeIGrR0IA+5Ot2WCuoyKidQ
         OEl/ImOR/npqiBU6H5+e3XYLPW0bKdjzv2NhWcxnIOzW10G+xuYGTNi3/LSAv/1ptkWm
         yeOr5lQSRpNu22O0ulLvagQj5TJ9lQXLsJtUWYWd5uKhVvmazyU5r/ID0NgfJ9VyBQH8
         KoEfzl2Emxed8GgrkO3+OL6CnR+6iRdQVh7XxzXXVGaut3n3VovuQQG2HeGbcagspAiP
         /MffcnJmB6HKyQt+FxDI4Zi2J0Clwjbl/MDP5jqKwrDUimpwVkx9o6cv8ZS7PT03tCmm
         AKjQ==
X-Forwarded-Encrypted: i=1; AJvYcCXq81ko459ecLR5cJjObXAidWtAKhQDjMRGnSPRPim6ltF3IwkBA72uSScT3Ef6FbPO6fvsoTB6I9E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzT5au96myM/J90r5lKdXilm9Q4iuKNpVcm3WDvD+WUzdmxrHuk
	b48kFljCop+zNe/kwFF/+R+ZdN5nu9lNXdg35Nd5YQSw/evhh+15W1/zFIc60e04Ow==
X-Gm-Gg: ASbGnctIgL89lFne5t/CAlsEyFWMQHYWlsiZZDbFQJiJBO/7jRsgKftBlePFAbSOZIJ
	4iA63U7x0QtUM7c/5JFxt+hFAiiTATQEiaIX+4z/ZIbPSKj9LL1hc5R4kyPDWgjeo/MEJr3CPqv
	jiD/oiZSV+nxK2LvAnkHQoIlYOZxbNIrYk4vMzFfIqAOJ6tFtLkUxOuS0mTavPZBNiCRjB7OXNT
	jT5LMbR8oOVJXVDO2Too1IJU0H1b+i9rDPTjd74DIEu6vpBysALJ9IIs8tqlbN6aNw9RLDG2F8d
	i9OOfr7Q3Ojnr7K6hihX3QOOnC556zcRq0L4opgJxMELz6pLXRC2b4JVjqvTnsSpX2bBOGgxDZG
	S0IwbkoA2z8jXOYm6gmbRfRcZ9sDO23MfvAJK
X-Google-Smtp-Source: AGHT+IFT9Iq1MqE4br+yUZDPG5DEbEZ49uyuAoA/itNPLQ6Kkr65dJHtT7Gyq48dpzqqNZcXCCSLyw==
X-Received: by 2002:a17:906:c7c6:b0:ad5:3746:591d with SMTP id a640c23a62f3a-ad537465c09mr95207166b.52.1747384581312;
        Fri, 16 May 2025 01:36:21 -0700 (PDT)
Message-ID: <00594224-7a33-4c5f-812e-7160bfecb5c4@suse.com>
Date: Fri, 16 May 2025 10:36:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 7/9] xen/x86: rename cache_flush_permitted() to
 has_arch_io_resources()
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: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-8-roger.pau@citrix.com>
 
 
 <205a65d3-92bd-4281-8605-758ca03fcac5@suse.com>
 
 <9db4a2ce-ba06-42a1-b6e6-7d0c2b59c0c3@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

On 16.05.2025 10:27, Roger Pau Monné wrote:
> On Fri, May 16, 2025 at 10:08:35AM +0200, Jan Beulich wrote:
>> On 16.05.2025 10:02, Roger Pau Monné wrote:
>>> On Fri, May 16, 2025 at 09:07:43AM +0200, Jan Beulich wrote:
>>>> On 15.05.2025 12:28, Roger Pau Monné wrote:
>>>>> On Mon, May 12, 2025 at 05:16:02PM +0200, Jan Beulich wrote:
>>>>>> On 06.05.2025 10:31, Roger Pau Monne wrote:
>>>>>>> To better describe the underlying implementation.  Define
>>>>>>> cache_flush_permitted() as an alias of has_arch_io_resources(), so that
>>>>>>> current users of cache_flush_permitted() are not effectively modified.
>>>>>>>
>>>>>>> With the introduction of the new handler, change some of the call sites of
>>>>>>> cache_flush_permitted() to instead use has_arch_io_resources() as such
>>>>>>> callers are not after whether cache flush is enabled, but rather whether
>>>>>>> the domain has any IO resources assigned.
>>>>>>>
>>>>>>> Take the opportunity to adjust l1_disallow_mask() to use the newly
>>>>>>> introduced has_arch_io_resources() macro.
>>>>>>
>>>>>> While I'm happy with everything else here, to me it's at least on the
>>>>>> edge whether cache_flush_permitted() wouldn't be the better predicate
>>>>>> to use there, for this being about ...
>>>>>>
>>>>>>> --- a/xen/arch/x86/mm.c
>>>>>>> +++ b/xen/arch/x86/mm.c
>>>>>>> @@ -172,8 +172,7 @@ static DEFINE_SPINLOCK(subpage_ro_lock);
>>>>>>>  
>>>>>>>  #define l1_disallow_mask(d)                                     \
>>>>>>>      (((d) != dom_io) &&                                         \
>>>>>>> -     (rangeset_is_empty((d)->iomem_caps) &&                     \
>>>>>>> -      rangeset_is_empty((d)->arch.ioport_caps) &&               \
>>>>>>> +     (!has_arch_io_resources(d) &&                              \
>>>>>>>        !has_arch_pdevs(d) &&                                     \
>>>>>>>        is_pv_domain(d)) ?                                        \
>>>>>>>       L1_DISALLOW_MASK : (L1_DISALLOW_MASK & ~PAGE_CACHE_ATTRS))
>>>>>>
>>>>>> ... cachability, which goes hand in hand with the ability to also
>>>>>> flush cache contents.
>>>>>
>>>>> Hm, I was on the edge here, in fact I've previously coded this using
>>>>> cache_flush_permitted(), just to the change back to
>>>>> has_arch_io_resources().  If you think cache_flush_permitted() is
>>>>> better I'm fine with that.
>>>>
>>>> I think that would be better here, yet as you say - it's not entirely
>>>> clear cut either way.
>>>
>>> I've reverted this chunk of the change and left the code as-is for the
>>> time being.
>>
>> Didn't we agree to use cache_flush_permitted() here instead?
> 
> I think it would be a bit weird, if we want this to be a
> non-functional change we would need to keep the has_arch_pdevs()
> condition because cache_flush_permitted() doesn't take that into
> account.  Or we need to adjust cache_flush_permitted() to also take
> has_arch_pdevs() into consideration.

Which is what you suggested elsewhere, or did I misunderstand that?

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 08:43:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:43:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986569.1372107 (Exim 4.92)
	(envelope-from )
	id 1uFqfM-0007Wk-A2; Fri, 16 May 2025 08:43:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986569.1372107; Fri, 16 May 2025 08:43: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 1uFqfM-0007Wd-6i; Fri, 16 May 2025 08:43:40 +0000
Received: by outflank-mailman (input) for mailman id 986569;
 Fri, 16 May 2025 08:43:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFqfL-0007WX-0e
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:43:39 +0000
Received: from mail187-4.suw11.mandrillapp.com
 (mail187-4.suw11.mandrillapp.com [198.2.187.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id db09081f-3231-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 10:43:36 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-4.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4ZzLFz1JcTzlfh3C
 for ; Fri, 16 May 2025 08:43:35 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 4368014b365942719809a18e32120b24; Fri, 16 May 2025 08:43:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: db09081f-3231-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747385015; x=1747655015;
	bh=QIsCxqSevCNnS3VEX4nPvkof78q3xUbwM+lArj0clCg=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=DbaqxbdOp4WQnqm+vdCQuiidyyoNJs/S8+nQpeev6gMpELNK9OuepV1DXYa9VzjJr
	 cmFJvR3xd1o5Bdpj2DNp8r8c4pGZP+g+yLYtNyRywWPjSlmX07Qp1oykWJxxsY1rsi
	 R/gv+mgQKxDdRo+jKO6nredQsNk2ksM3ds7ITnt/s4dYICLlTJe+4X9IDqqBdrVJuZ
	 qk++wn4bWwrt3vClirXBCBx0QhmcIaDxr70K3KRArFVJHccOV/nxM6ZiwlJMv6ABVh
	 PdLqBwrg/+w7/q/AM5ip/e8mIXD2g3R2zW3669ccLSZPVupjmbMt9uFu+/TN4nSvYf
	 fvh/ffb4Ts41w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747385015; x=1747645515; i=teddy.astie@vates.tech;
	bh=QIsCxqSevCNnS3VEX4nPvkof78q3xUbwM+lArj0clCg=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=ffT3F85yufVnk8rYRjBni+gLOH7Zi7Phs7IraH1o/6t8P2q7jONS8JMpAa3V8XfUL
	 ShrNqZhp/zYiSPQhwmxpD5a2poY1XZKmpuYrkdrdM7gNAKqKuATOvrJ7YJYQfs5flT
	 U0CeSDZp3uEbWIOsFAmr+5eMH+EXrXuTnBG8eTnlz8VL+bdqjbftTnfXIXNE8HVERz
	 nUZlHbfdwdRz8my5O9bizgIeUkakvWFEwEf9TQotulRcAJacVfD8sum70oj60E2kGU
	 LSWRUxrFoL2O4rr/rfVhwMTXy7PldXgc1AqAGtxQ3iy5zWl0TtZ6NKKeKHuNLoZkch
	 hlvAOqzjPJP0w==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v6=201/2]=20xen/domain:=20unify=20domain=20ID=20allocation?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747385013610
Message-Id: <3c9f60b3-cedb-4689-a3b4-15ebddcf9f67@vates.tech>
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
References: <20250516020434.1145337-1-dmukhin@ford.com> <20250516020434.1145337-2-dmukhin@ford.com>
In-Reply-To: <20250516020434.1145337-2-dmukhin@ford.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.4368014b365942719809a18e32120b24?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 08:43:35 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

Le 16/05/2025 =C3=A0 04:06, dmkhn@proton.me a =C3=A9crit=C2=A0:
> From: Denis Mukhin 
> 
> Currently, hypervisor code has two different non-system domain ID allocat=
ion
> implementations:
> 
>    (a) Sequential IDs allocation in dom0less Arm code based on max_init_d=
omid;
> 
>    (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
>        max_init_domid (both Arm and x86).
> 
> It makes sense to have a common helper code for such task across architec=
tures
> (Arm and x86) and between dom0less / toolstack domU allocation.
> 
> Wrap the domain ID allocation as an arch-independent function domid_alloc=
() in
> common/domain.c based on rangeset.
> 
> Allocation algorithm:
> - If an explicit domain ID is provided, verify its availability and
>    use it if ID is not used;
> - Otherwise, perform an exhaustive search starting from the end of the us=
ed
>    domain ID range. domid_alloc() guarantees that two subsequent calls wi=
ll
>    result in different IDs allocation.
> 
> Initialize the domain IDs rangeset from the new domid_init() which is cal=
led
> from arch setup code.
> 
> Also, remove is_free_domid() helper as it is not needed now.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v5:
> - rebased
> ---
>   xen/arch/arm/domain_build.c             | 17 ++++--
>   xen/arch/arm/setup.c                    |  2 +
>   xen/arch/x86/setup.c                    | 13 +++--
>   xen/common/device-tree/dom0less-build.c | 10 ++--
>   xen/common/domain.c                     | 70 +++++++++++++++++++++++++
>   xen/common/domctl.c                     | 41 ++-------------
>   xen/include/xen/domain.h                |  4 ++
>   7 files changed, 107 insertions(+), 50 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index b189a7cfae..e9d563c269 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2010,6 +2010,7 @@ void __init create_dom0(void)
>           .grant_opts =3D XEN_DOMCTL_GRANT_version(opt_gnttab_max_version=
),
>       };
>       unsigned int flags =3D CDF_privileged | CDF_hardware;
> +    domid_t domid;
>       int rc;
>   
>       /* The vGIC for DOM0 is exactly emulating the hardware GIC */
> @@ -2034,19 +2035,25 @@ void __init create_dom0(void)
>       if ( !llc_coloring_enabled )
>           flags |=3D CDF_directmap;
>   
> -    dom0 =3D domain_create(0, &dom0_cfg, flags);
> +    domid =3D domid_alloc(0);
> +    if ( domid =3D=3D DOMID_INVALID )
> +        panic("Error allocating domain ID 0\n");
> +
> +    dom0 =3D domain_create(domid, &dom0_cfg, flags);
>       if ( IS_ERR(dom0) )
> -        panic("Error creating domain 0 (rc =3D %ld)\n", PTR_ERR(dom0));
> +        panic("Error creating domain %d (rc =3D %ld)\n", domid, PTR_ERR(=
dom0));
>   
>       if ( llc_coloring_enabled && (rc =3D dom0_set_llc_colors(dom0)) )
> -        panic("Error initializing LLC coloring for domain 0 (rc =3D %d)\=
n", rc);
> +        panic("Error initializing LLC coloring for domain %pd (rc =3D %d=
)\n",
> +              dom0, rc);
>   
>       if ( alloc_dom0_vcpu0(dom0) =3D=3D NULL )
> -        panic("Error creating domain 0 vcpu0\n");
> +        panic("Error creating domain %pdv0\n", dom0);
>   
>       rc =3D construct_dom0(dom0);
>       if ( rc )
> -        panic("Could not set up DOM0 guest OS (rc =3D %d)\n", rc);
> +        panic("Could not set up guest OS for domain %pd (rc =3D %d)\n",
> +              dom0, rc);
>   
>       set_xs_domain(dom0);
>   }
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 10b46d0684..c3959e8d8e 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -418,6 +418,8 @@ void asmlinkage __init start_xen(unsigned long fdt_pa=
ddr)
>   
>       timer_init();
>   
> +    domid_init();
> +
>       init_idle_domain();
>   
>       rcu_init();
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 2518954124..02f665f520 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1030,8 +1030,11 @@ static struct domain *__init create_dom0(struct bo=
ot_info *bi)
>       if ( iommu_enabled )
>           dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu;
>   
> -    /* Create initial domain.  Not d0 for pvshim. */
> -    bd->domid =3D get_initial_domain_id();
> +    /* Allocate initial domain ID. Not d0 for pvshim. */
> +    bd->domid =3D domid_alloc(get_initial_domain_id());
> +    if ( bd->domid =3D=3D DOMID_INVALID )
> +        panic("Error allocating domain ID %d\n", get_initial_domain_id()=
);
> +
>       d =3D domain_create(bd->domid, &dom0_cfg,
>                         pv_shim ? 0 : CDF_privileged | CDF_hardware);
>       if ( IS_ERR(d) )
> @@ -1063,7 +1066,7 @@ static struct domain *__init create_dom0(struct boo=
t_info *bi)
>   
>           if ( (strlen(acpi_param) =3D=3D 0) && acpi_disabled )
>           {
> -            printk("ACPI is disabled, notifying Domain 0 (acpi=3Doff)\n"=
);
> +            printk("ACPI is disabled, notifying domain %pd (acpi=3Doff)\=
n", d);
>               safe_strcpy(acpi_param, "off");
>           }
>   
> @@ -1078,7 +1081,7 @@ static struct domain *__init create_dom0(struct boo=
t_info *bi)
>   
>       bd->d =3D d;
>       if ( construct_dom0(bd) !=3D 0 )
> -        panic("Could not construct domain 0\n");
> +        panic("Could not construct domain %pd\n", d);
>   
>       bd->cmdline =3D NULL;
>       xfree(cmdline);
> @@ -1915,6 +1918,8 @@ void asmlinkage __init noreturn __start_xen(void)
>       mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",
>                                     RANGESETF_prettyprint_hex);
>   
> +    domid_init();
> +
>       xsm_multiboot_init(bi);
>   
>       /*
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-=
tree/dom0less-build.c
> index 2c56f13771..9236dbae11 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -850,15 +850,13 @@ void __init create_domUs(void)
>           struct xen_domctl_createdomain d_cfg =3D {0};
>           unsigned int flags =3D 0U;
>           bool has_dtb =3D false;
> +        domid_t domid;
>           uint32_t val;
>           int rc;
>   
>           if ( !dt_device_is_compatible(node, "xen,domain") )
>               continue;
>   
> -        if ( (max_init_domid + 1) >=3D DOMID_FIRST_RESERVED )
> -            panic("No more domain IDs available\n");
> -
>           d_cfg.max_evtchn_port =3D 1023;
>           d_cfg.max_grant_frames =3D -1;
>           d_cfg.max_maptrack_frames =3D -1;
> @@ -981,7 +979,11 @@ void __init create_domUs(void)
>            * very important to use the pre-increment operator to call
>            * domain_create() with a domid > 0. (domid =3D=3D 0 is reserve=
d for Dom0)
>            */
> -        d =3D domain_create(++max_init_domid, &d_cfg, flags);
> +        domid =3D domid_alloc(++max_init_domid);
> +        if ( domid =3D=3D DOMID_INVALID )
> +            panic("Error allocating ID for domain %s\n", dt_node_name(no=
de));
> +
> +        d =3D domain_create(domid, &d_cfg, flags);
>           if ( IS_ERR(d) )
>               panic("Error creating domain %s (rc =3D %ld)\n",
>                     dt_node_name(node), PTR_ERR(d));
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index abf1969e60..0ba3cdc47d 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -66,6 +66,74 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
>   static struct domain *domain_hash[DOMAIN_HASH_SIZE];
>   struct domain *domain_list;
>   
> +/* Non-system domain ID allocator. */
> +static DEFINE_SPINLOCK(domid_lock);
> +static struct rangeset *domid_rangeset;
> +static unsigned int domid_last;
> +
> +void __init domid_init(void)
> +{
> +    domid_rangeset =3D rangeset_new(NULL, "domid", RANGESETF_prettyprint=
_hex);
> +    if ( !domid_rangeset )
> +        panic("cannot allocate domain ID rangeset\n");
> +
> +    rangeset_limit(domid_rangeset, DOMID_FIRST_RESERVED);
> +}
> +
> +/*
> + * Allocate new non-system domain ID based on the hint.
> + *
> + * If hint is outside of valid [0..DOMID_FIRST_RESERVED - 1] range of ID=
s,
> + * perform an exhaustive search starting from the end of the used domain=
 ID
> + * range.
> + */
> +domid_t domid_alloc(domid_t domid)
> +{
> +    spin_lock(&domid_lock);
> +
> +    if ( domid < DOMID_FIRST_RESERVED )
> +    {
> +        if ( rangeset_contains_singleton(domid_rangeset, domid) )
> +            domid =3D DOMID_INVALID;
> +    }
> +    else
> +    {
> +        for ( domid =3D domid_last + 1; domid !=3D domid_last; domid++ )
> +        {
> +            if ( domid =3D=3D DOMID_FIRST_RESERVED )
> +                domid =3D 0;
> +
> +            if ( !rangeset_contains_singleton(domid_rangeset, domid) )
> +                break;
> +        }
> +
> +        if ( domid =3D=3D domid_last )
> +            domid =3D DOMID_INVALID;
> +    }
> +
> +    if ( domid !=3D DOMID_INVALID )
> +    {
> +        ASSERT(!rangeset_add_singleton(domid_rangeset, domid));
> +
> +        if ( domid !=3D domid_last )
> +            domid_last =3D domid;
> +    }
> +
> +    spin_unlock(&domid_lock);
> +
> +    return domid;
> +}

It's mostly a matter of implementation choice, but I am not really fan 
of relying on rangesets, which to me are meant for address ranges or 
something similar but at least large.

I would rather rely on a bitmap using find_first_zero_bit+set_bit which 
avoids doing a per-domid test, and may be simpler overall. The bitmap 
size for 0x3FF0 domains is almost 4KB, which looks acceptable.

I don't know what other thinks.

> +
> +void domid_free(domid_t domid)
> +{
> +    spin_lock(&domid_lock);
> +
> +    if ( rangeset_contains_singleton(domid_rangeset, domid) )
> +        ASSERT(!rangeset_remove_singleton(domid_rangeset, domid));
> +
> +    spin_unlock(&domid_lock);
> +}
> +
>   /*
>    * Insert a domain into the domlist/hash.  This allows the domain to be=
 looked
>    * up by domid, and therefore to be the subject of hypercalls/etc.
> @@ -1449,6 +1517,8 @@ void domain_destroy(struct domain *d)
>   
>       TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id);
>   
> +    domid_free(d->domain_id);
> +
>       /* Remove from the domlist/hash. */
>       domlist_remove(d);
>   
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index bfe2e1f9f0..2e02139660 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -49,20 +49,6 @@ static int xenctl_bitmap_to_nodemask(nodemask_t *nodem=
ask,
>                                      MAX_NUMNODES);
>   }
>   
> -static inline int is_free_domid(domid_t dom)
> -{
> -    struct domain *d;
> -
> -    if ( dom >=3D DOMID_FIRST_RESERVED )
> -        return 0;
> -
> -    if ( (d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL )
> -        return 1;
> -
> -    rcu_unlock_domain(d);
> -    return 0;
> -}
> -
>   void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *i=
nfo)
>   {
>       struct vcpu *v;
> @@ -421,34 +407,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)=
 u_domctl)
>   
>       case XEN_DOMCTL_createdomain:
>       {
> -        domid_t        dom;
> -        static domid_t rover =3D 0;
> +        domid_t domid =3D domid_alloc(op->domain);
>   
> -        dom =3D op->domain;
> -        if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) )
> +        if ( domid =3D=3D DOMID_INVALID )
>           {
>               ret =3D -EEXIST;
> -            if ( !is_free_domid(dom) )
> -                break;
> -        }
> -        else
> -        {
> -            for ( dom =3D rover + 1; dom !=3D rover; dom++ )
> -            {
> -                if ( dom =3D=3D DOMID_FIRST_RESERVED )
> -                    dom =3D 1;
> -                if ( is_free_domid(dom) )
> -                    break;
> -            }
> -
> -            ret =3D -ENOMEM;
> -            if ( dom =3D=3D rover )
> -                break;
> -
> -            rover =3D dom;
> +            break;
>           }
>   
> -        d =3D domain_create(dom, &op->u.createdomain, false);
> +        d =3D domain_create(domid, &op->u.createdomain, false);
>           if ( IS_ERR(d) )
>           {
>               ret =3D PTR_ERR(d);

In case the domain creation failure, we need to free the domid, 
otherwise, it would not be used anymore as considered used by the domid 
allocator.

> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> index e10baf2615..039bb7eeaf 100644
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -38,6 +38,10 @@ void arch_get_domain_info(const struct domain *d,
>   
>   domid_t get_initial_domain_id(void);
>   
> +void domid_init(void);
> +void domid_free(domid_t domid);
> +domid_t domid_alloc(domid_t domid);
> +
>   /* CDF_* constant. Internal flags for domain creation. */
>   /* Is this a privileged domain? */
>   #define CDF_privileged           (1U << 0)

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Fri May 16 08:46:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:46:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986581.1372117 (Exim 4.92)
	(envelope-from )
	id 1uFqhg-0008Mm-Lo; Fri, 16 May 2025 08:46:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986581.1372117; Fri, 16 May 2025 08:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFqhg-0008Mf-IS; Fri, 16 May 2025 08:46:04 +0000
Received: by outflank-mailman (input) for mailman id 986581;
 Fri, 16 May 2025 08:46:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFqhf-0008MZ-Fw
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:46:03 +0000
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com
 [2607:f8b0:4864:20::429])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2f641f79-3232-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 10:45:58 +0200 (CEST)
Received: by mail-pf1-x429.google.com with SMTP id
 d2e1a72fcca58-74019695377so1512491b3a.3
 for ; Fri, 16 May 2025 01:45:58 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-742a982b7f3sm1058048b3a.87.2025.05.16.01.45.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 01:45: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" 
X-Inumbo-ID: 2f641f79-3232-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747385157; x=1747989957; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=GfzlJ/qnT8QfHcjMeisE3sUR4E0aVwvxuRWnbDCyJ7E=;
        b=N6m7peRS3KQV9Oe4FdIBiz2oXUc4e+4MAJx5USl+99N7XQpTrCUL2gu884qhRO/1UC
         MShbTkpyhy0TP7Zejiz5TUTHSdLVvTbQhL9VUIrl/ztqpyV7ikk2knzNS9JjCdwvzTI6
         3KSA8olU4CuBP207LUR9o3XeYyNbeFe5ue89E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747385157; x=1747989957;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=GfzlJ/qnT8QfHcjMeisE3sUR4E0aVwvxuRWnbDCyJ7E=;
        b=qn2+1n/8OUwfT4alzOrjkGNMcTbIKUKxn+/Li2mt2t67snFm10cEgE2M+yHEXmVjep
         592MeDJ0ge9oljRIj1OyzVIU9Ed1Jj0UjIIUrRL3/hrxTtbh9gG528XaJTXx2zLBevRC
         b8vd/iaoAecYRxffOnP8lNM7s0cwvyUNjhr1ADw//8naCZa13DUBz8kiuG5xPxa7d/Ee
         A/dWc04HYvgOOBAe0RHi2VLHxBsbAtrYMJLyh4s9+WicKKBajmJVpxD7+5aI9e111/QG
         DBLtTZ5wXIHVrsb/G6FgGeXH/Q85etB4uQuedsvPFjzPj08VkrOUzbMkJw/wd3Tv8sdN
         0WEw==
X-Forwarded-Encrypted: i=1; AJvYcCWEpCZg8Td2LMUx1/oOCgzdKo3U1Ovoq2a5TX9HaJbRL/7BnxLa0wT2bdZ0q1OgVdLaEO5dZUOL8Jk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxIu+2Fb7Irr0sxGyWs+bjKUL/qrQ9c8s/aoZ64kCT07XP83z9Z
	0knIiR9hMFJkHXWG5ZFcZ/yUjV2HIcEpmBAcjnJNH6GBUX/s8k0hhvEO2Oo9HjO8SrQ=
X-Gm-Gg: ASbGncv7YtEBqepXu/AeoUaKko7IWRlcgQUTmrxxLtFxbNWPz8AwR1jhaTgLrbQiXDM
	cIkXuZew1nXBwFGJe4Si1F0y0FXh8z/iAbtXpc64pAWfNKEmbD5a1J9lu9EwjtFCf4yqBOFXJqD
	Kk0OT1SESi6lfSKauZ3noJWxp6mUbOxllr2oCjaiVHxXidpDGEQP0y+wcjgjAxmO2OQJjwdfIyR
	iHT2txL8N/a7GqR3hdUEHRpItNKK8L8IpekqNJv7dVU370rFSSwnk1roiFqCFXysPOPquwa/Id6
	a40NdLwdJXOachmb6hBVBOk+Ic+stLuruF47PDNr+dNmBQsNeP1uFvQ/ZC9KCLVnFOXkhAk7URV
	l2J8TpJNvIvF/0fgog8w=
X-Google-Smtp-Source: AGHT+IGmIYZZ/tfy+QfATAVNbxNkGtGNh6ykiLCvCMmOk7TpKYh/WhOGYWWpNPUwx/thVvfW421h2w==
X-Received: by 2002:a05:6a00:18a7:b0:742:a0cf:7753 with SMTP id d2e1a72fcca58-742a97769efmr3707070b3a.3.1747385156582;
        Fri, 16 May 2025 01:45:56 -0700 (PDT)
Date: Fri, 16 May 2025 10:45:51 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 5/9] x86/mtrr: use memory_type_changed() in
 hvm_set_mem_pinned_cacheattr()
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-6-roger.pau@citrix.com>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Fri, May 16, 2025 at 10:02:22AM +0200, Jan Beulich wrote:
> On 16.05.2025 09:48, Roger Pau Monné wrote:
> > Overall, I have the impression hvm_set_mem_pinned_cacheattr() should
> > only be used while building a domain, and hence the flush can likely
> > be skipped unconditionally, regardless of the type changes.
> 
> See my patch submission, which had this remark:
> 
> "Is it really sensible to add/remove ranges once the guest is already
>  running? (If it is, limiting the scope of the flush would be nice, but
>  would require knowing dirtyness for the domain wrt the caches, which
>  currently we don't track.)"

Well, I had an extra patch to attempt to do track vCPU dirtyness wrt
to the caches.

> 
> As apparently we both agree, why don't we reject requests post-creation
> then, and drop the flush? The one thing I'm uncertain about is whether
> the DM would actually have carried out the operation strictly ahead of
> the domain being first un-paused.

I've looked at QEMU, and I cannot convince myself the operation
couldn't be used against live domains, it's part of a memory listener
hook.

What is also concerning is that this seems to be completely ignored
when using AMD NPT, I can only find references to
hvm_get_mem_pinned_cacheattr() in EPT and shadow code.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 16 08:56:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 08:56:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986597.1372127 (Exim 4.92)
	(envelope-from )
	id 1uFqrC-0001zO-My; Fri, 16 May 2025 08:55:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986597.1372127; Fri, 16 May 2025 08:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFqrC-0001zH-Jp; Fri, 16 May 2025 08:55:54 +0000
Received: by outflank-mailman (input) for mailman id 986597;
 Fri, 16 May 2025 08:55:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFqrB-0001zB-Ca
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 08:55:53 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 916ef7bb-3233-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 10:55:51 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ad238c68b35so340912266b.1
 for ; Fri, 16 May 2025 01:55:51 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad534ad59dasm89071566b.31.2025.05.16.01.55.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 01:55: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" 
X-Inumbo-ID: 916ef7bb-3233-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747385751; x=1747990551; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=sH/cErjnCXGpiOVt3Z/e5C0zRWf/h5mzBgpYkmJg8Lg=;
        b=t4Weu5XlmkALMbX0pOWkM5s/8XpDr1+CzQ/sCjZPRsmta/HCacY5Zco7/Io2TVhkyy
         bEjPXyKLFK+1dkaZpoDvGPiEGu5wwkpBivQReYD9wHMOO1AebAmBZakLUM/ejRxcoZGK
         62p8UR5PNHx/44UDDhwTKG1dn7jevj0EEDClQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747385751; x=1747990551;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=sH/cErjnCXGpiOVt3Z/e5C0zRWf/h5mzBgpYkmJg8Lg=;
        b=sRPqKnIm61pr4TYlbcqm4XNZh7dHoThcJmwGWnjksMMsoqwYNEAFDsUrzUTrjdnQfY
         tEr7McvlYev60kgdW3mEkWoZyPH10lHGtG0rKFMEmrQVxCojKxLaS6+uBr+n1V0kSnZa
         C3B6TYawDcV0ieGGXbrh9vQ0r1O1fp9TplP6wksV79qLtcMaqlFBSiWwzau5aSzmb67f
         3i5IWv3OnihTwydX7XlgV7sApF/wii4TPlrkyY2XrNNL/qyD/2bSxODem6mEhoJKvAgl
         E9uRHXBpvRBpvxM5FOcsDGsmtZ8EfmdHMM4FNhK5QARWihcWvLCIlsQHARJwpeyC76vW
         xPyQ==
X-Forwarded-Encrypted: i=1; AJvYcCVDThAtHbfIFKIXwkFzUWD6mAyc6/6fnTKs/6/xkVuwivXM2lTvZOXfCYiBKwcGUZ94QWo1RbUPHzo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzdPT3lxMi4duG9zqxj4Hf9BQnnI2SAR41vIOoPmj/TJ5h4y0Zy
	WNf0obynfbeJIjXeNrBDU9iEQsGEcsj3uc+IQ5hI+s1NKk6J/smyukRfc20zWkgMh1c=
X-Gm-Gg: ASbGncvzhvpS+q7YLWjf6y6XDXrIa6E4TBQsEj6ZMDZzzv4jionCUvGLzxDmhOM6LML
	lwfZ+lDrviEnbl4VBwRczXRIbXCgKwfu6DPFq401W5Bo3Xq38PrIXaSIPMDJRo3f5FYA0P1zrzJ
	FEXcSbV4EZ/sYg1qjqXfK7xOQsP4+y0HKQc2kVwSYmdew4qLyJv3Oh+5fTWnqxBDjyPgyu1kUMt
	KTIv/bMdVXJVYYYSqjOgt3eexqPPIXQUmVXRbGr7b+RfOTioLtGEzYAlRSV9oxp4/KJlSJpBfjx
	adgicnyefoTLCDZA+GEpmLE/egsURwODw1OsJnT9ycbnvZov0SouCyVBJnyb18PNshhtrwfiylK
	nltVshJLdZ3/5qbsd+hk=
X-Google-Smtp-Source: AGHT+IFeNVr2GLqZgdFAH1bpWubhjEFWLNqpHSo7Ehv+G3Vm8kYQ9YIyC0wJkVdJ4CU9q9hnfMkHjQ==
X-Received: by 2002:a17:907:1c2a:b0:ad2:40f4:c251 with SMTP id a640c23a62f3a-ad536bdff0bmr137083466b.35.1747385750716;
        Fri, 16 May 2025 01:55:50 -0700 (PDT)
Date: Fri, 16 May 2025 10:55:49 +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 7/9] xen/x86: rename cache_flush_permitted() to
 has_arch_io_resources()
Message-ID: 
References: <20250506083148.34963-1-roger.pau@citrix.com>
 <20250506083148.34963-8-roger.pau@citrix.com>
 
 
 <205a65d3-92bd-4281-8605-758ca03fcac5@suse.com>
 
 <9db4a2ce-ba06-42a1-b6e6-7d0c2b59c0c3@suse.com>
 
 <00594224-7a33-4c5f-812e-7160bfecb5c4@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <00594224-7a33-4c5f-812e-7160bfecb5c4@suse.com>

On Fri, May 16, 2025 at 10:36:19AM +0200, Jan Beulich wrote:
> On 16.05.2025 10:27, Roger Pau Monné wrote:
> > On Fri, May 16, 2025 at 10:08:35AM +0200, Jan Beulich wrote:
> >> On 16.05.2025 10:02, Roger Pau Monné wrote:
> >>> On Fri, May 16, 2025 at 09:07:43AM +0200, Jan Beulich wrote:
> >>>> On 15.05.2025 12:28, Roger Pau Monné wrote:
> >>>>> On Mon, May 12, 2025 at 05:16:02PM +0200, Jan Beulich wrote:
> >>>>>> On 06.05.2025 10:31, Roger Pau Monne wrote:
> >>>>>>> To better describe the underlying implementation.  Define
> >>>>>>> cache_flush_permitted() as an alias of has_arch_io_resources(), so that
> >>>>>>> current users of cache_flush_permitted() are not effectively modified.
> >>>>>>>
> >>>>>>> With the introduction of the new handler, change some of the call sites of
> >>>>>>> cache_flush_permitted() to instead use has_arch_io_resources() as such
> >>>>>>> callers are not after whether cache flush is enabled, but rather whether
> >>>>>>> the domain has any IO resources assigned.
> >>>>>>>
> >>>>>>> Take the opportunity to adjust l1_disallow_mask() to use the newly
> >>>>>>> introduced has_arch_io_resources() macro.
> >>>>>>
> >>>>>> While I'm happy with everything else here, to me it's at least on the
> >>>>>> edge whether cache_flush_permitted() wouldn't be the better predicate
> >>>>>> to use there, for this being about ...
> >>>>>>
> >>>>>>> --- a/xen/arch/x86/mm.c
> >>>>>>> +++ b/xen/arch/x86/mm.c
> >>>>>>> @@ -172,8 +172,7 @@ static DEFINE_SPINLOCK(subpage_ro_lock);
> >>>>>>>  
> >>>>>>>  #define l1_disallow_mask(d)                                     \
> >>>>>>>      (((d) != dom_io) &&                                         \
> >>>>>>> -     (rangeset_is_empty((d)->iomem_caps) &&                     \
> >>>>>>> -      rangeset_is_empty((d)->arch.ioport_caps) &&               \
> >>>>>>> +     (!has_arch_io_resources(d) &&                              \
> >>>>>>>        !has_arch_pdevs(d) &&                                     \
> >>>>>>>        is_pv_domain(d)) ?                                        \
> >>>>>>>       L1_DISALLOW_MASK : (L1_DISALLOW_MASK & ~PAGE_CACHE_ATTRS))
> >>>>>>
> >>>>>> ... cachability, which goes hand in hand with the ability to also
> >>>>>> flush cache contents.
> >>>>>
> >>>>> Hm, I was on the edge here, in fact I've previously coded this using
> >>>>> cache_flush_permitted(), just to the change back to
> >>>>> has_arch_io_resources().  If you think cache_flush_permitted() is
> >>>>> better I'm fine with that.
> >>>>
> >>>> I think that would be better here, yet as you say - it's not entirely
> >>>> clear cut either way.
> >>>
> >>> I've reverted this chunk of the change and left the code as-is for the
> >>> time being.
> >>
> >> Didn't we agree to use cache_flush_permitted() here instead?
> > 
> > I think it would be a bit weird, if we want this to be a
> > non-functional change we would need to keep the has_arch_pdevs()
> > condition because cache_flush_permitted() doesn't take that into
> > account.  Or we need to adjust cache_flush_permitted() to also take
> > has_arch_pdevs() into consideration.
> 
> Which is what you suggested elsewhere, or did I misunderstand that?

Yes, I missed that you agreed to that then, sorry.  To many messages
on the thread I'm afraid.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 16 09:31:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:31:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986616.1372136 (Exim 4.92)
	(envelope-from )
	id 1uFrPt-0007hg-9t; Fri, 16 May 2025 09:31:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986616.1372136; Fri, 16 May 2025 09:31: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 1uFrPt-0007hZ-6z; Fri, 16 May 2025 09:31:45 +0000
Received: by outflank-mailman (input) for mailman id 986616;
 Fri, 16 May 2025 09:31:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrPr-0007hQ-Vn
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:31:44 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 90e034ba-3238-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 11:31:38 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzMKP0Rm0zMQxXYB
 for ; Fri, 16 May 2025 09:31:37 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 e905edda31bd41638873149f1747232e; Fri, 16 May 2025 09:31: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" 
X-Inumbo-ID: 90e034ba-3238-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747387897; x=1747657897;
	bh=f70Avydbv7fxeXt+EdaNyvnxvCPINflZRbLz61xdssw=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=FRv/5/OF+HVskBSUlGtONazTlE1SgrS8pXDk5rVIYNXuctnvk1YMT9gbrTAE9yTHA
	 M7wmHX/IGRDPVLWuRGM+abmInGCZEvKwPVmdjUIn30PjbHtbYtdwegu3KuAgVC33Bd
	 g5zwOXWjn/J1G6LiJuqRzYu4+hl6F1HcfUH/XWqlDRAb4cMdLuLs25yNap+e6cdI6T
	 HlryXHfZ97pJ7L3cl3kANtTfC/e0iQS8/+O7006UBA5vW+E8Sm6BYqyaNYkLKtDAKE
	 2ekcVEmDGWy/44gUpDEYozBzF7A701sbZ+w8tYlaK8SiHzLeKO9WGrH5dvKb1hVoik
	 HYA+tYVDXnKHg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747387897; x=1747648397; i=teddy.astie@vates.tech;
	bh=f70Avydbv7fxeXt+EdaNyvnxvCPINflZRbLz61xdssw=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=yF4qbLCvoj7Ciung1VcGXxR3J8MIQ5HpfnTriJv5fdlrNaCxQQW66RsQUSI0yAJSv
	 R8lc6sc92lKOCzqOwWszsinTA1QKFWcuCtEVpxcmMFuKGCbTAAyKINKaX4+sTK6fac
	 EFBXupdh5TXoPjWeb7NoC5cAPaBeIcWA1YEeOjrzo1TMv5EaWm7fdbsVSyID4Rb39C
	 by+OmNLImfq5EHJwp6sBn6KQIxWHgZPLb+YUNbt8kM65bDkgGWVCc7ctCHxcK7sxg+
	 YU3tL60p0w3sdHpkkYRHkaITN/iiwIsG3fx/yhnqpR3EcTT59PID9Q0xAplNshnXmo
	 erYsnBALWiQew==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2001/16]=20x86/msr:=20Introduce=20SYSCFG=5FMEM=5FENCRYPT=20MSR.?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747387896147
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Andrei Semenov" 
Message-Id: <72dca4861d81ca418e244526babd48d511b9baa3.1747312394.git.teddy.astie@vates.tech>
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.e905edda31bd41638873149f1747232e?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 09:31:36 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

From: Andrei Semenov 

SYSCFG_MEM_ENCRYPT is the AMD SME MSR used to enable SME and AMD SEV.

Signed-off-by: Andrei Semenov 
---
 xen/arch/x86/include/asm/msr-index.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 22d9e76e55..7620c4cd2e 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -221,6 +221,7 @@
 #define  SYSCFG_MTRR_VAR_DRAM_EN            (_AC(1, ULL) << 20)
 #define  SYSCFG_MTRR_TOM2_EN                (_AC(1, ULL) << 21)
 #define  SYSCFG_TOM2_FORCE_WB               (_AC(1, ULL) << 22)
+#define  SYSCFG_MEM_ENCRYPT                 (_AC(1, ULL) << 23)
 
 #define MSR_K8_IORR_BASE0                   _AC(0xc0010016, U)
 #define MSR_K8_IORR_MASK0                   _AC(0xc0010017, U)
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:31:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:31:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986622.1372197 (Exim 4.92)
	(envelope-from )
	id 1uFrPz-0000cc-0n; Fri, 16 May 2025 09:31:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986622.1372197; Fri, 16 May 2025 09:31: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 1uFrPy-0000cD-RQ; Fri, 16 May 2025 09:31:50 +0000
Received: by outflank-mailman (input) for mailman id 986622;
 Fri, 16 May 2025 09:31:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrPx-0007iv-Cq
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:31:49 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 968e0369-3238-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 11:31:47 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzMKQ4KDyzMQxf5q
 for ; Fri, 16 May 2025 09:31:38 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 ae12c7e11c6b46ecaa70ec2e79b33b58; Fri, 16 May 2025 09:31: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" 
X-Inumbo-ID: 968e0369-3238-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747387898; x=1747657898;
	bh=Oox53sOqqEj7n70xDwRKrmCV5uYcvtps8LZ1Ru6v/p8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=KvBJB/Xd7dfLSXDq+onoyyhu9vlIpJ01RPlAMHpUkNrDLHO0da6s8DXedToNtqJpF
	 edTWaKLH+gEtesih0q6wA4Y92cj6pRlwHphspzufgc0CZtU7n6YowIA3Kze6WQepZO
	 7AwOgQyu9pToah/qoWyKNhkEiS3JinE5ArVDRrxqIBM+aPoBUyVRJeSUA7uCx3MdGG
	 WjdkoKAV1UQWXlfOZIEqOTOj0iGWQoAhPxyGptKsQchptwtC2G5dNkvqlWkl5kJJ85
	 A4E7X7/g+qQI61ogN1W44V/glYLNnOSQOba/4ukF3bI6nlEPd+TxtLWsuKSf9IdY6v
	 y4XeMtPuyD66Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747387898; x=1747648398; i=teddy.astie@vates.tech;
	bh=Oox53sOqqEj7n70xDwRKrmCV5uYcvtps8LZ1Ru6v/p8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=FsyVngK12yS6ADyP2czz7V2rFvDLbGfkTScNlU2qUivy+qC53e6LuVfsuCc/dtZ4X
	 D7sEw3lopvGxzjJWG6fVB5TZIfffKD/luCA2Sqn1i6GDLghUD5g7fZay+ACIt9hsvN
	 rnE/wVw2i0nHKpfdV/qLSjDR+dGUy60Mh17yJ00hXDQf/5wj0RSG7SqVtD3cgzDF/r
	 ioOvGv9ckejUdM2KKYL/fphQysef1kK+jzqR5sud5R3tAkORdLAq4yDzJrV8jV9YWb
	 F589qN9X3Wy+K8s6WonyYInbQ1rvRnrbAPRgBy07d2xWnRVTFQTGoBc2OHljRIFcsg
	 1Jn+cWMX6w2Vg==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2005/16]=20docs/x86:=20Document=20HVM=20Physical=20Addresss=20ABI?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747387897417
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" 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.ae12c7e11c6b46ecaa70ec2e79b33b58?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 09:31:38 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed-off-by: Teddy Astie 
---
 docs/guest-guide/x86/hypercall-abi.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/docs/guest-guide/x86/hypercall-abi.rst b/docs/guest-guide/x86/hypercall-abi.rst
index e52ed453bc..710a02895b 100644
--- a/docs/guest-guide/x86/hypercall-abi.rst
+++ b/docs/guest-guide/x86/hypercall-abi.rst
@@ -35,6 +35,10 @@ The registers used for hypercalls depends on the operating mode of the guest.
 HVM guest depends on whether the vCPU is operating in a 64bit segment or not
 [#mode]_.
 
+If `XEN_HVM_CPUID_PHYS_ADDR_ABI` is supported, HVM guests can use a alternative
+ABI where physical addresses are used for hypercall parameters instead of
+linear addresses. This ABI can be used by tagging the hypercall index with
+0x40000000.
 
 Parameters
 ----------
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:31:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:31:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986620.1372173 (Exim 4.92)
	(envelope-from )
	id 1uFrPx-0008Q5-Av; Fri, 16 May 2025 09:31:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986620.1372173; Fri, 16 May 2025 09: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 1uFrPx-0008PM-2r; Fri, 16 May 2025 09:31:49 +0000
Received: by outflank-mailman (input) for mailman id 986620;
 Fri, 16 May 2025 09:31:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrPv-0007hQ-Mh
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:31:47 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 90ddb0af-3238-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 11:31:38 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzMKP2Pb4zMQxXXp
 for ; Fri, 16 May 2025 09:31:37 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 6d19bda8ab244784b25a29105d05f65e; Fri, 16 May 2025 09:31:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 90ddb0af-3238-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747387897; x=1747657897;
	bh=jXXMZ6aCdgxXcOitCrfcMbnlGzl+JcdnY3VXx2NEZtQ=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=h+Mn3fe1suntMusfqgLt5OVToh5kcWCcimqvTrDj5Oy9H2JofIAagSTj7Z189/5ZW
	 wQL++o/6qZoK6FvLsQr9uH65kbYGo1HQeBy4g/wojQv232UKCE3hd/Ab5aBsmY8aG0
	 xP1RDkGIUKTuhI2IPTFoHDU/j1zZP7fjWH1Ulzqo28n5FTHAhwLu9UJ/ZIz/0cSrIN
	 S0nUQX0DVqpDYXSU6aTBXMx1ETHP11ogHnW1hXMlWpfwtQ7SHcDKcTwIuruLjZxU01
	 fFJ0Tz/Ol5kNJOb81cdq0iZpS5k4JTtLcax2AmZ+LWvZQUawNiOTQYMZTSXZRk5hdM
	 tLT2dADnzIeIA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747387897; x=1747648397; i=teddy.astie@vates.tech;
	bh=jXXMZ6aCdgxXcOitCrfcMbnlGzl+JcdnY3VXx2NEZtQ=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=o/MdznanHXxKUj4xIqbLT9ORX56PcQWjEYRv2UFjsvnC3kaIHIL9Ity1jl9JnWgNG
	 Dmfy/QBfjEiPpbReUALZRKLh4mHK+jZlkcgsncWlK5CRx9duClnYvq55ec+eAzCZbO
	 9lN6oVlGgKCUCI+nklB/CJpGBkT+rLkrYmffvRv0zLIy31qzgUbQqw49pYTeQ0vQWo
	 2447IqTLZJxMSFXQjs+WABM0OkA33SVXxSOAU1XvrnCTp96viaw9dTzAQLzRaqN3X0
	 yXpLhv69qG8nHZl9ivXsIpwW2D0X7WkSOT7eRY6LgErXEoKIfS96xAwGLS3L9Gp6b8
	 zq42E328o53tw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2000/16]=20Confidential=20computing=20and=20AMD=20SEV=20support?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747387895675
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" , "Tim Deegan" , "Juergen Gross" , "Christian Lindig" , "David Scott" 
Message-Id: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.6d19bda8ab244784b25a29105d05f65e?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 09:31:37 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hello,

This series introduce support for confidential computing along with a
AMD SEV implementation. It also bundles some of the functional
requirements (ASID scheme, ABI, ...) which could be separated if needed.

(I bundled everything in this serie to have a complete coherent serie)

This work receives funding by the Hyper Open X consortium (France 2030).

# Concepts

A confidential guest is a bit special as :
 - its memory is by default encrypted or not directly accessible by the
   hypervisor, thus other domains/dom0 as well; it must be explicitely
   shared by the guest itself
 - so its page-tables are also not accessible

# Implementation

Confidential computing is exposed in a uniform way regardless of actual
implementation (SEV, TDX, RME, ...) through the coco_op hypercall (mostly
for use by the Dom0 toolstack). This interface provides a way to query
informations on the coco platform (support status, features (un)safety,
...), and prepare initial guest memory.
Only HVM domains have support for confidential computing.
(in the future, we may want to have attestation support)

In order to create a confidential computing domain, the process is follow : 
 - create a HVM/PVH domain with XEN_DOMCTL_CDF_coco
 - populate initial memory as usual
 - apply coco_prepare_initial_mem on all initial pages
   (under SEV, this will encrypt memory)

Under xl, it is exposed through the `coco` parameter ("coco = 1").

Xen hypercalls usually use virtual addresses as parameter, which causes issues
when issuing them from a confidential guest (where its memory is usually not
available to the hypervisor e.g encryted). This problem is solved by introducing
a new experimental hypercall ABI ("Physical Address ABI") which don't use virtual
addresses anymore, of course it needs explicit guest support.

## SEV Implementation

Currently, only plain SEV (no ES) is implemented. I would prefer to use SEV-ES
as plain SEV has several flaws like having non-trivial emulation paths and the
hypervisor can break the guest encryption by manipulating its registers (unlike
SEV-ES where the hypervisor has a very controlled view on guest registers).

# Series organization

The first part introduce some non-coco/SEV specific bits.

The second part introduce a physical address ABI, that is required to
make proper hypercalls under a confidential computing guest. That's
something that we should discuss more, but for now, it allows some
minimal guest hypercall support in confidential computing guest.

A patch introduce a ASID management rework (based on Vaishali's work)
required to make SEV work, as in this case the ASID is tied to the guest
encryption key. Which also includes a rework on TLB flushing logic.

Then a general confidential computing infrastructure (not SEV-specific)
along with the AMD SEV implementation.

And some extra patches to workaround some limitations (DF_FLUSH support
and temporary debug tools).

You can find Linux branches with early SEV support (more or less working)
https://github.com/xcp-ng/linux/tree/xen-sev-6.6/
https://github.com/xcp-ng/linux/tree/xen-sev-6.14/

Teddy Astie (16):
  x86/msr: Introduce SYSCFG_MEM_ENCRYPT MSR.
  x86/svm: Move svm_domain structure to svm.h
  x86/hvm: Add support for physical address ABI
  x86/public: Expose physaddr_abi through Xen HVM CPUID leaf
  docs/x86: Document HVM Physical Addresss ABI
  vmx: Introduce vcpu single context VPID invalidation
  x86/hvm: Introduce Xen-wide ASID allocator
  x86/crypto: Introduce AMD PSP driver for SEV
  common: Introduce confidential computing infrastructure
  xl/coco: Introduce confidential computing support
  x86/svm: Introduce NPCTRL VMCB bits
  x86/cpufeature: Introduce SME and SEV-related CPU features
  x86/coco: Introduce AMD-SEV support
  sev/emulate: Handle some non-emulable HVM paths
  HACK: coco: Leak ASID for coco guests
  HACK: Add sev_console hypercall

 docs/guest-guide/x86/hypercall-abi.rst      |   4 +
 tools/include/libxl.h                       |   5 +
 tools/include/xenctrl.h                     |   4 +
 tools/include/xenguest.h                    |   1 +
 tools/libs/ctrl/xc_domain.c                 |  36 +
 tools/libs/guest/Makefile.common            |   2 +
 tools/libs/guest/xg_dom_boot.c              |  33 +
 tools/libs/guest/xg_dom_coco.c              |  35 +
 tools/libs/guest/xg_dom_coco.h              |  39 +
 tools/libs/guest/xg_dom_x86.c               |   1 +
 tools/libs/light/libxl_cpuid.c              |   1 +
 tools/libs/light/libxl_create.c             |   4 +
 tools/libs/light/libxl_dom.c                |   1 +
 tools/libs/light/libxl_types.idl            |   1 +
 tools/libs/util/libxlu_disk_l.c             |  13 +-
 tools/libs/util/libxlu_disk_l.h             |   7 +-
 tools/misc/xen-cpuid.c                      |   1 +
 tools/ocaml/libs/xc/xenctrl.ml              |   1 +
 tools/ocaml/libs/xc/xenctrl.mli             |   1 +
 tools/xl/xl_parse.c                         |   2 +
 xen/arch/x86/Makefile                       |   1 +
 xen/arch/x86/coco/Makefile                  |   1 +
 xen/arch/x86/coco/sev.c                     | 262 ++++++
 xen/arch/x86/cpu/amd.c                      |  10 +
 xen/arch/x86/cpu/common.c                   |   2 +
 xen/arch/x86/cpuid.c                        |   7 +
 xen/arch/x86/domain.c                       |   4 +
 xen/arch/x86/flushtlb.c                     |   7 +-
 xen/arch/x86/hvm/Kconfig                    |  10 +
 xen/arch/x86/hvm/asid.c                     | 170 ++--
 xen/arch/x86/hvm/emulate.c                  | 139 +++-
 xen/arch/x86/hvm/hvm.c                      |  55 +-
 xen/arch/x86/hvm/hypercall.c                |  17 +-
 xen/arch/x86/hvm/nestedhvm.c                |   7 +-
 xen/arch/x86/hvm/svm/asid.c                 |  77 +-
 xen/arch/x86/hvm/svm/nestedsvm.c            |   2 +-
 xen/arch/x86/hvm/svm/svm.c                  |  43 +-
 xen/arch/x86/hvm/svm/svm.h                  |   4 -
 xen/arch/x86/hvm/svm/vmcb.c                 |  17 +-
 xen/arch/x86/hvm/vmx/vmcs.c                 |   6 +-
 xen/arch/x86/hvm/vmx/vmx.c                  |  68 +-
 xen/arch/x86/hvm/vmx/vvmx.c                 |   5 +-
 xen/arch/x86/include/asm/coco.h             |   8 +
 xen/arch/x86/include/asm/cpufeature.h       |   4 +
 xen/arch/x86/include/asm/hvm/asid.h         |  26 +-
 xen/arch/x86/include/asm/hvm/domain.h       |   2 +
 xen/arch/x86/include/asm/hvm/hvm.h          |  15 +-
 xen/arch/x86/include/asm/hvm/svm/sev.h      |  14 +
 xen/arch/x86/include/asm/hvm/svm/svm.h      |  32 +
 xen/arch/x86/include/asm/hvm/svm/vmcb.h     |  22 +-
 xen/arch/x86/include/asm/hvm/vcpu.h         |  10 +-
 xen/arch/x86/include/asm/hvm/vmx/vmx.h      |  19 +-
 xen/arch/x86/include/asm/msr-index.h        |   1 +
 xen/arch/x86/include/asm/psp-sev.h          | 655 +++++++++++++++
 xen/arch/x86/mm/hap/hap.c                   |   7 +-
 xen/arch/x86/mm/p2m.c                       |   7 +-
 xen/arch/x86/mm/paging.c                    |   2 +-
 xen/arch/x86/mm/shadow/hvm.c                |   1 +
 xen/arch/x86/mm/shadow/multi.c              |   1 +
 xen/common/Kconfig                          |   5 +
 xen/common/Makefile                         |   1 +
 xen/common/coco.c                           | 140 ++++
 xen/common/domain.c                         |  41 +-
 xen/drivers/Kconfig                         |   2 +
 xen/drivers/Makefile                        |   1 +
 xen/drivers/crypto/Kconfig                  |  10 +
 xen/drivers/crypto/Makefile                 |   1 +
 xen/drivers/crypto/asp.c                    | 830 ++++++++++++++++++++
 xen/include/hypercall-defs.c                |   4 +
 xen/include/public/arch-x86/cpufeatureset.h |   5 +
 xen/include/public/arch-x86/cpuid.h         |   2 +
 xen/include/public/domctl.h                 |   5 +-
 xen/include/public/hvm/coco.h               |  65 ++
 xen/include/public/xen.h                    |   2 +
 xen/include/xen/coco.h                      |  88 +++
 xen/include/xen/lib/x86/cpu-policy.h        |   9 +-
 xen/include/xen/sched.h                     |  14 +
 77 files changed, 2859 insertions(+), 298 deletions(-)
 create mode 100644 tools/libs/guest/xg_dom_coco.c
 create mode 100644 tools/libs/guest/xg_dom_coco.h
 create mode 100644 xen/arch/x86/coco/Makefile
 create mode 100644 xen/arch/x86/coco/sev.c
 create mode 100644 xen/arch/x86/include/asm/coco.h
 create mode 100644 xen/arch/x86/include/asm/hvm/svm/sev.h
 create mode 100644 xen/arch/x86/include/asm/psp-sev.h
 create mode 100644 xen/common/coco.c
 create mode 100644 xen/drivers/crypto/Kconfig
 create mode 100644 xen/drivers/crypto/Makefile
 create mode 100644 xen/drivers/crypto/asp.c
 create mode 100644 xen/include/public/hvm/coco.h
 create mode 100644 xen/include/xen/coco.h

-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:31:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:31:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986621.1372181 (Exim 4.92)
	(envelope-from )
	id 1uFrPx-00008Q-Rd; Fri, 16 May 2025 09:31:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986621.1372181; Fri, 16 May 2025 09: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 1uFrPx-00007Y-JH; Fri, 16 May 2025 09:31:49 +0000
Received: by outflank-mailman (input) for mailman id 986621;
 Fri, 16 May 2025 09:31:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrPw-0007iv-Ca
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:31:48 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 962df48f-3238-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 11:31:46 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzMKQ4409zMQxdhF
 for ; Fri, 16 May 2025 09:31:38 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 f0ae509aaf1c4bf3846e2e2ff59eca25; Fri, 16 May 2025 09:31: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" 
X-Inumbo-ID: 962df48f-3238-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747387898; x=1747657898;
	bh=iMtHB+smiJdOQ9laMMAKQ5QBEFSycIXeep/kGpJ45n8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=uoRmOpPM/u6zliOBEwflrIMPb6kr6kvAPf6jiQBWy6u4KRRuEWFnUqK3wy4JL+HuR
	 WMbr3/iBZDaJ6sApqvWfI3T+GcFWB5DRWsiv19IzRHmpBqFiF+V+PlF+cfEMSvShZa
	 Ty1CfuIK2W1ePpdNVVbXEp+a5qmzUxZmNFUerRvQPI71NjHcDZL49rbou8l7k16w3I
	 N/faXzuTwSE6JgEqGWLphz0hLry6sAg6nOQJm8onJIX60wJJg/2jELwBif4j0mjZ0f
	 C6GPd7siFqMI+CArNR2IegMp6bmyWvAem6V5mcbXg4kIqecoKI1WzoNQ3ePPwTMUsH
	 C6hSBrAWW0+Ig==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747387898; x=1747648398; i=teddy.astie@vates.tech;
	bh=iMtHB+smiJdOQ9laMMAKQ5QBEFSycIXeep/kGpJ45n8=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=BE8kb2VeB4bxMGNM7bH0/vjoAH5LhtRH1WJuogcWVAjSVVMgaKl8AuWi2JAs/2rkw
	 Rtoy7yDvPbLwduHgfecCp3UsLHrV0P2bXbN1bJ/DSyf255UHEGzwtLaoAfSzExrRIV
	 fyYSZoUN5y28egsMZwOKAGtcc84qw7IK8FhA47mJHARefJUEc9HX+DA5tIReYkPD0M
	 TQIoTad1XhRpzDU/Z4YrJQv4vNVItlDGkACeAfUiZysctBJbMDto8taGO3E5YUUzlB
	 KCYw8Lqr+JxL/Mye7xXfl8sAykMpVmEWQQrYwmcVBa99Lt7ERkLQe1q0HNTVzKD2PS
	 Wb6K9oZLpwK1g==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2006/16]=20vmx:=20Introduce=20vcpu=20single=20context=20VPID=20invalidation?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747387897605
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Message-Id: <85727bf1e1df2feeba2af34aa3c7c951982121d6.1747312394.git.teddy.astie@vates.tech>
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.f0ae509aaf1c4bf3846e2e2ff59eca25?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 09:31:38 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Introduce vpid_sync_vcpu_context to do a single-context invalidation
on the vpid attached to the vcpu as a alternative to per-gva and all-context
invlidations.

Signed-off-by: Teddy Astie 
---
This will be used on Intel platforms for the ASID management rework.
---
 xen/arch/x86/include/asm/hvm/vmx/vmx.h | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index d85b52b9d5..a55a31b42d 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -451,6 +451,27 @@ static inline void ept_sync_all(void)
 
 void ept_sync_domain(struct p2m_domain *p2m);
 
+static inline void vpid_sync_vcpu_context(struct vcpu *v)
+{
+    int type = INVVPID_SINGLE_CONTEXT;
+
+    /*
+     * If single context invalidation is not supported, we escalate to
+     * use all context invalidation.
+     */
+    if ( likely(cpu_has_vmx_vpid_invvpid_single_context) )
+        goto execute_invvpid;
+
+    /*
+     * If single context invalidation is not supported, we escalate to
+     * use all context invalidation.
+     */
+    type = INVVPID_ALL_CONTEXT;
+
+execute_invvpid:
+    __invvpid(type, v->arch.hvm.n1asid.asid, (u64)gva);
+}
+
 static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva)
 {
     int type = INVVPID_INDIVIDUAL_ADDR;
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:31:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:31:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986617.1372147 (Exim 4.92)
	(envelope-from )
	id 1uFrPu-0007vL-Il; Fri, 16 May 2025 09:31:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986617.1372147; Fri, 16 May 2025 09:31: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 1uFrPu-0007vD-Du; Fri, 16 May 2025 09:31:46 +0000
Received: by outflank-mailman (input) for mailman id 986617;
 Fri, 16 May 2025 09:31:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrPt-0007iv-MZ
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:31:45 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 94541256-3238-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 11:31:44 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzMKP3MYszMQxXQJ
 for ; Fri, 16 May 2025 09:31:37 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 ff315deb4bd344d39271417cf5ae7a76; Fri, 16 May 2025 09:31:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 94541256-3238-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747387897; x=1747657897;
	bh=Bm3fwAmp4WAbuBybmOkVHtGEJRz6Fv9FQEpbNnQjujk=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=1Gc0hXi6YayeadhiAlCyKeJLWh2XbM+glWXIDDxBW9wVcyWvL7PzQBZzvVO1XZwpd
	 FL23g+zTG72IuyzKi8Woo8O1nKuCvU/569B2ne9CJaoKd75adM2kAMXckw0OMaHpo9
	 cdePv1QaI5fgDYBnnj/KS+iy6C9S2vBROGvDxb2KCNKSJUVk8FwgOE94GzYxy8k9x+
	 MVFFVtycWnh3vxtbDMZp0G7v9OIYPV0L7BPr9poymPmlcLMizOlV4pd5Y2SMxEFVnJ
	 nT49qfa4s7LgtWqp4WVPM8n1IYePT5SP4egvikS0J7omD7vp8rIO9DFuaZ4wo8EDrT
	 gSH+7y+Gl9+ow==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747387897; x=1747648397; i=teddy.astie@vates.tech;
	bh=Bm3fwAmp4WAbuBybmOkVHtGEJRz6Fv9FQEpbNnQjujk=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=RAw6lC0xk7AIzin+hubuQg5zDWFx+wP+WCFQi4xWdPN9wQVQgm3Pi5aSY789FCQTz
	 /G32elnJqJapnDKel/6uItODiq6PRgRv2QIHnubIHrNzTprARNqoSnAfrX04goK7ZZ
	 cQIwOULtIFKg3W16iyu4eAcpulgde5EPTCNaRyZN4MnptBl/e2mXUnAQGkDX0D3ddK
	 LogKQYkqX3Y5Am9LANp8l8OZEy7DsOWix+x7S5+pRzZdEjfymglXhD5zThAWpfbp1O
	 JlX1E024o8OV8Bx+HVoO88Eh+Fd5X9Hr+1LlsDSECAntyLf6hUxoERFM7ftxjCJRNZ
	 5sUfV0+wO7VRQ==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2002/16]=20x86/svm:=20Move=20svm=5Fdomain=20structure=20to=20svm.h?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747387896340
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.ff315deb4bd344d39271417cf5ae7a76?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 09:31:37 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

struct svm_domain was in vmcb.h which is meant for VMCB specific
operations and values, move it to svm.h where it belongs.

Signed-off-by: Teddy Astie 
---
 xen/arch/x86/include/asm/hvm/domain.h   |  1 +
 xen/arch/x86/include/asm/hvm/svm/svm.h  | 11 +++++++++++
 xen/arch/x86/include/asm/hvm/svm/vmcb.h | 11 -----------
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/asm/hvm/domain.h
index 333501d5f2..2608bcfad2 100644
--- a/xen/arch/x86/include/asm/hvm/domain.h
+++ b/xen/arch/x86/include/asm/hvm/domain.h
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_MEM_SHARING
 struct mem_sharing_domain
diff --git a/xen/arch/x86/include/asm/hvm/svm/svm.h b/xen/arch/x86/include/asm/hvm/svm/svm.h
index 4eeeb25da9..32f6e48e30 100644
--- a/xen/arch/x86/include/asm/hvm/svm/svm.h
+++ b/xen/arch/x86/include/asm/hvm/svm/svm.h
@@ -21,6 +21,17 @@ bool svm_load_segs(unsigned int ldt_ents, unsigned long ldt_base,
                    unsigned long fs_base, unsigned long gs_base,
                    unsigned long gs_shadow);
 
+struct svm_domain {
+    /* OSVW MSRs */
+    union {
+        uint64_t raw[2];
+        struct {
+            uint64_t length;
+            uint64_t status;
+        };
+    } osvw;
+};
+
 extern u32 svm_feature_flags;
 
 #define SVM_FEATURE_NPT            0 /* Nested page table support */
diff --git a/xen/arch/x86/include/asm/hvm/svm/vmcb.h b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
index 28f715e376..3d871b6135 100644
--- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h
+++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
@@ -548,17 +548,6 @@ struct vmcb_struct {
     u64 res18[291];
 };
 
-struct svm_domain {
-    /* OSVW MSRs */
-    union {
-        uint64_t raw[2];
-        struct {
-            uint64_t length;
-            uint64_t status;
-        };
-    } osvw;
-};
-
 /*
  * VMRUN doesn't switch fs/gs/tr/ldtr and SHADOWGS/SYSCALL/SYSENTER state.
  * Therefore, guest state is in the hardware registers when servicing a
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:31:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:31:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986618.1372156 (Exim 4.92)
	(envelope-from )
	id 1uFrPv-000896-Nd; Fri, 16 May 2025 09:31:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986618.1372156; Fri, 16 May 2025 09:31:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFrPv-00088z-Kg; Fri, 16 May 2025 09:31:47 +0000
Received: by outflank-mailman (input) for mailman id 986618;
 Fri, 16 May 2025 09:31:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrPu-0007iv-C5
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:31:46 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 955402fb-3238-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 11:31:45 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzMKQ0MMFzMQxdjF
 for ; Fri, 16 May 2025 09:31:38 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 765e177ef22b48fc8d7dcece54076855; Fri, 16 May 2025 09:31:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 955402fb-3238-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747387898; x=1747657898;
	bh=yEIj4vYbaqS4Y1WKd4I6vOFuJvvhA1ynFIt3vpuTIg0=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=uypxcY/kQP2Oej6nzc4EhhNRyNzUNO31XCilUP9I2f3Vew0ZJe1lPDrIIJMjfn4sv
	 WfLw4mypDQ1KMK6CJ8jgWXFD5sr67Ww3ZaaCfyCG15fMvZL9UJvvoMmz+TBHJfv5D9
	 kO+X/1HkZCkXQ5RnNqJAxyBpLge9iZUpoVgkGh6DooOSg23TpLRXBLDoURXYhsKNXO
	 DjzCP42l2zYin81l75ofZFG7h0zGUbh8fS3e9ThjVr2OaUEAEQiLHHYLfCDSDsicQ9
	 Iom79SpSXl128fdLuSlPBZkI52RWLzho2zgImsSfjT2mouHORo2H6GUGgJqWPrZsFt
	 1akqZMw5mYYvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747387898; x=1747648398; i=teddy.astie@vates.tech;
	bh=yEIj4vYbaqS4Y1WKd4I6vOFuJvvhA1ynFIt3vpuTIg0=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=vH7sVi9DcWiyQXD5rAK1LnKqQKB53q+nzchgrgzTpZpR+GEUhR0tSg8Kggko6MSGU
	 ayuqNYQ6WoZv3AVek9oVBu8L8Ch11AUY0MRXW5ZQKLm5tyVLVObZd1V/UyOux3DL8W
	 C+310DuIIKQ1xnOnPwtzD32lFmV//zXm8B1Si7RmTSqBeqGS7WzbUVWOq1WH1YYWLW
	 gJox0eyqhDfJd8dLJRl/lW0R5gKG+C4sngKrvQ5lslAln+p2WIeLeyYXC0v9gWMXft
	 7HRNP5vAi/4S+dRcgBTS461bUZpjmBz/SF7M4YnV8RiVefYlcDLyk40AujHO3dZQMF
	 Tl+zqdua+2uSQ==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2004/16]=20x86/public:=20Expose=20physaddr=5Fabi=20through=20Xen=20HVM=20CPUID=20leaf?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747387897112
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.765e177ef22b48fc8d7dcece54076855?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 09:31:37 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed-off-by: Teddy Astie 
---
 xen/arch/x86/cpuid.c                | 2 ++
 xen/include/public/arch-x86/cpuid.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 8dc68945f7..e2d94619c2 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -153,6 +153,8 @@ static void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,
          */
         res->a |= XEN_HVM_CPUID_UPCALL_VECTOR;
 
+        /* Indicate that guest can the physical addresses hypercall ABI. */
+        res->a |= XEN_HVM_CPUID_PHYS_ADDR_ABI;
         break;
 
     case 5: /* PV-specific parameters */
diff --git a/xen/include/public/arch-x86/cpuid.h b/xen/include/public/arch-x86/cpuid.h
index 3bb0dd249f..5405bf6fbd 100644
--- a/xen/include/public/arch-x86/cpuid.h
+++ b/xen/include/public/arch-x86/cpuid.h
@@ -106,6 +106,8 @@
  * bound to event channels.
  */
 #define XEN_HVM_CPUID_UPCALL_VECTOR    (1u << 6)
+/* Hypercalls can use physical addresses instead of linear ones. */
+#define XEN_HVM_CPUID_PHYS_ADDR_ABI    (1u << 7)
 
 /*
  * Leaf 6 (0x40000x05)
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:31:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:31:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986619.1372166 (Exim 4.92)
	(envelope-from )
	id 1uFrPw-0008Nh-V9; Fri, 16 May 2025 09:31:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986619.1372166; Fri, 16 May 2025 09:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFrPw-0008NW-S7; Fri, 16 May 2025 09:31:48 +0000
Received: by outflank-mailman (input) for mailman id 986619;
 Fri, 16 May 2025 09:31:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrPv-0007iv-CN
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:31:47 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 95c81fea-3238-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 11:31:46 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzMKQ0z9JzMQxf5l
 for ; Fri, 16 May 2025 09:31:38 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 dc3866fe00dd4d1cb15f5f7e0a1d2dc4; Fri, 16 May 2025 09:31: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" 
X-Inumbo-ID: 95c81fea-3238-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747387898; x=1747657898;
	bh=Pu9DXVzNtDp7vBm0SeMKn1Apw+Y0YN30HfO50Yk2htE=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=J/nNHdh2qp9sPkOvbrRg/IHWwj+kWKEeaS/iuBP18i/Otyn3yWK/Wbn5U+0OfImI3
	 D1xifpocdfuK61avf3HicCWyAb3t+up1exCbiRwggw+tflsPlGdfWzs3W2dZgryhqs
	 TZjNZzKAxHCFXlssL3caV03s62eDOJxDuhUODK2ZDrTADnN88jd42OVPL6vAS7hYdZ
	 uFXru8ytUsE++ExD1v7XuVwXOyUodgZRn5tNxmG06Z/KY3t5CcMcEP0S8OQnAgldLj
	 hXsah7ld8jgmP4kHcZ71S4moVKJc6JtLW1DTGkklU2MLDsJc33ULlBg90ai9a1z0jj
	 c/DMlMzOh3xjg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747387898; x=1747648398; i=teddy.astie@vates.tech;
	bh=Pu9DXVzNtDp7vBm0SeMKn1Apw+Y0YN30HfO50Yk2htE=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=E6oc20jCZY9it3AXgPjsovD8HM6gjOfKj+LgN4h+JhBSLEN+erYSegBU1Nmb9R842
	 0gR1VS2S9+7OQxU+egl3eCurI6Jfia4HT4bb8VP4IXxZOpxEIB7QAH68Uj69W7irSe
	 RsRhGk1FVyrEaOxhnjDAz31oIFaikUNuTosPR13tEFGmL5B8TRg60vKksOlBYcmALy
	 8z1nAVMGo9AZlsSbh5ThzsBDtdtj3YttlLdWDCkcc8Nrq0Idw1a3oi8w0kLraMgpE5
	 DmpYfInB+KPOth0mr7lYol6atWm7P3NEcExvx7bTb1HbrZgLA5fambEtPVC31RBw7I
	 O96eR55C3FsEQ==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2003/16]=20x86/hvm:=20Add=20support=20for=20physical=20address=20ABI?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747387896927
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.dc3866fe00dd4d1cb15f5f7e0a1d2dc4?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 09:31:38 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Guest can tag their hypercalls with 0x40000000 in order to use this
alternative ABI that uses physical addresses instead of linear ones.

Signed-off-by: Teddy Astie 
---
This one is based on the "HVMv2 ABI" RFC, but reworked in a way that is more
compatible with existing guest (guest need to opt-in abi for a specific
hypercall).

Andrew has some plans regarding making a better HVM ABI for that, but it is
a first start for this RFC.
---
 xen/arch/x86/hvm/hvm.c       | 17 ++++++++++++++---
 xen/arch/x86/hvm/hypercall.c | 17 +++++++++++++----
 xen/include/xen/sched.h      |  2 ++
 3 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4cb2e13046..0e7c453b24 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3497,7 +3497,11 @@ unsigned int copy_to_user_hvm(void *to, const void *from, unsigned int len)
         return 0;
     }
 
-    rc = hvm_copy_to_guest_linear((unsigned long)to, from, len, 0, NULL);
+    if ( evaluate_nospec(current->hcall_physaddr) )
+        rc = hvm_copy_to_guest_phys((unsigned long)to, from, len, current);
+    else
+        rc = hvm_copy_to_guest_linear((unsigned long)to, from, len, 0, NULL);
+
     return rc ? len : 0; /* fake a copy_to_user() return code */
 }
 
@@ -3511,7 +3515,10 @@ unsigned int clear_user_hvm(void *to, unsigned int len)
         return 0;
     }
 
-    rc = hvm_copy_to_guest_linear((unsigned long)to, NULL, len, 0, NULL);
+    if ( evaluate_nospec(current->hcall_physaddr) )
+        rc = hvm_copy_to_guest_phys((unsigned long)to, NULL, len, current);
+    else
+        rc = hvm_copy_to_guest_linear((unsigned long)to, NULL, len, 0, NULL);
 
     return rc ? len : 0; /* fake a clear_user() return code */
 }
@@ -3526,7 +3533,11 @@ unsigned int copy_from_user_hvm(void *to, const void *from, unsigned int len)
         return 0;
     }
 
-    rc = hvm_copy_from_guest_linear(to, (unsigned long)from, len, 0, NULL);
+    if ( evaluate_nospec(current->hcall_physaddr) )
+        rc = hvm_copy_from_guest_phys(to, (unsigned long)from, len);
+    else
+        rc = hvm_copy_from_guest_linear(to, (unsigned long)from, len, 0, NULL);
+
     return rc ? len : 0; /* fake a copy_from_user() return code */
 }
 
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 6f8dfdff4a..b891089cda 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -160,8 +160,13 @@ int hvm_hypercall(struct cpu_user_regs *regs)
         HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%lu(%lx, %lx, %lx, %lx, %lx)",
                     eax, regs->rdi, regs->rsi, regs->rdx, regs->r10, regs->r8);
 
-        call_handlers_hvm64(eax, regs->rax, regs->rdi, regs->rsi, regs->rdx,
-                            regs->r10, regs->r8);
+        if ( eax & 0x40000000U )
+            curr->hcall_physaddr = true;
+
+        call_handlers_hvm64(eax & ~0x40000000U, regs->rax, regs->rdi, regs->rsi,
+                            regs->rdx, regs->r10, regs->r8);
+
+        curr->hcall_physaddr = false;
 
         if ( !curr->hcall_preempted && regs->rax != -ENOSYS )
             clobber_regs(regs, eax, hvm, 64);
@@ -172,9 +177,13 @@ int hvm_hypercall(struct cpu_user_regs *regs)
                     regs->ebx, regs->ecx, regs->edx, regs->esi, regs->edi);
 
         curr->hcall_compat = true;
-        call_handlers_hvm32(eax, regs->eax, regs->ebx, regs->ecx, regs->edx,
-                            regs->esi, regs->edi);
+        if ( eax & 0x40000000U )
+            curr->hcall_physaddr = true;
+
+        call_handlers_hvm32(eax & ~0x40000000U, regs->eax, regs->ebx, regs->ecx,
+                            regs->edx, regs->esi, regs->edi);
         curr->hcall_compat = false;
+        curr->hcall_physaddr = false;
 
         if ( !curr->hcall_preempted && regs->eax != -ENOSYS )
             clobber_regs(regs, eax, hvm, 32);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 559d201e0c..4ce9253284 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -240,6 +240,8 @@ struct vcpu
     bool             hcall_compat;
     /* Physical runstate area registered via compat ABI? */
     bool             runstate_guest_area_compat;
+    /* A hypercall is using the physical address ABI? */
+    bool             hcall_physaddr;
 #endif
 
 #ifdef CONFIG_IOREQ_SERVER
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:35:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:35:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986660.1372208 (Exim 4.92)
	(envelope-from )
	id 1uFrTQ-0002sN-Gc; Fri, 16 May 2025 09:35:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986660.1372208; Fri, 16 May 2025 09: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 1uFrTQ-0002sG-C5; Fri, 16 May 2025 09:35:24 +0000
Received: by outflank-mailman (input) for mailman id 986660;
 Fri, 16 May 2025 09:35:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFrTP-0002s5-9a
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:35:23 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 168a1173-3239-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 11:35:22 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ad510c259b9so331869866b.1
 for ; Fri, 16 May 2025 02:35: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
 a640c23a62f3a-ad52d4383d6sm124518166b.102.2025.05.16.02.35.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 02:35: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" 
X-Inumbo-ID: 168a1173-3239-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747388122; x=1747992922; darn=lists.xenproject.org;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=GuUUtwLi5p78xydLz57ppP9dNcYDitOJlBtWKRI9umg=;
        b=gLl8mcwDPNgSAxeSQLCuQOKooUtNvwrkv5Noi3V/OD8+cPux1fYZmCp19XeTBUBz5v
         /sDqkli3SLorBfmBSfLqOioMfe41cbpmEWYJuVS9g3n+lEjaNrl4igZhmwkPL/Pqekh+
         TFarT+fv0jVcWYYlDSe4BM2jtCDwC3LiRgGwr7HPQ+nflq5YSGEm/GJS74VEEs2vVmVV
         wwH2Yi6PEFhBVXml1eCfZkkTu29YOMJM+jI1ZU3NnGDfLTa00nb0EJmuWdcYO5muG4Vw
         XIy76G5RZ5OvGfu+I1eDXCxNFnU/91/Mxo3SX4t10N1PLTCwzGLE5AZb6Ks2PAprSrih
         2rww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747388122; x=1747992922;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=GuUUtwLi5p78xydLz57ppP9dNcYDitOJlBtWKRI9umg=;
        b=n/JGo3uMTSQKjpO5GXSKpDMurYQ7SkvmaKTfNjTqLQrE4jMeQm3fdTJJuO8dslUFYq
         pu7OcGa0QdzSJlc6qn85kNcJ1CF27JSrWH2s8OsULTyKvFEFqayD6E1D3ESUmC6UvJFn
         3xii9SLKTciOIOxWj9nCF3gVaKlMa5mEvYJbnCh5dBqg+yAJ0DuXs5Rtwpfj5IkvzUp8
         gaxWVy4DIEbOvOd9o72G4dO7k7TimqmBRbDDdOjs91vedse59JUissc3jlIO233uV/Hn
         RQrs7w6yeTgxJJiSaU87WgegEzZ0YoS34RFrsXom7t2xTefQR99k2y56e1ulnDdv5iU7
         0dSw==
X-Gm-Message-State: AOJu0Yxj4R1ca07EQ05v8/rBrPdacWJidsGYsI/Fh4nyFkXrYqSucuUP
	b5r+8Q/g9xt29GGr0gq+IwDH7A1dv1eZOpcISo+8Mao8ytrQ5iB2DNIPW1VIPMXSYg==
X-Gm-Gg: ASbGnctKqh0vfyn2/nwoz7FTYIZlrvLFNEyxg5KorHh2bxYzLGZ+I+kIyghR5SZtK1A
	1ds+KIdHsCzFPOMQQQBqr6BPwpRWUERM7iajmN0s7idbdEvvI3pV6YbmPi31Fk54o23xs6hdG8F
	IMe+voavS1BxmadDccyfEm3YII6sjZy6LL5UnP8NWeH5KA9YdqRvTCEnoizELLirO7l8Mtc81jx
	3e6hMmXnPCk1ykY1XRKKOjOgCLUhhREqkkvvlSv/ppJ2Strt3syhDj/fAKryj5rb06W7taocfAe
	xUBUjZKmmar+igN39aPAiuEVU++WfQy4lkVz9yY1SGCt6Sk6vdU8z+hC0gcd2AVCEgb9dnPd+Zk
	7bAZNF+2/Shyjw7xfoIQ+NfpDD9jMvJnTsGhSwqCkEZkRcWE=
X-Google-Smtp-Source: AGHT+IE4kohGyvQKsrWfdwryU5Plp+Rqb8fPtvj4Cv8/GQjHwOL8icnsKTwCPYZnNn/wb1a7a8+ZOw==
X-Received: by 2002:a17:907:7205:b0:ad2:409f:fe6f with SMTP id a640c23a62f3a-ad52d5d2fa4mr337706066b.44.1747388121581;
        Fri, 16 May 2025 02:35:21 -0700 (PDT)
Message-ID: <04d6f03a-ff40-48c0-a88b-753f3f8bda0e@suse.com>
Date: Fri, 16 May 2025 11:35:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: Xen 4.18.5 released
To: xen-announce@lists.xenproject.org
Cc: "xen-devel@lists.xenproject.org" 
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

All,

we're pleased to announce the release of another bug fixing Xen version.

Xen 4.18.5 is available from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.18
(tag RELEASE-4.18.5) or from the XenProject download page
https://xenproject.org/resources/downloads/, or from
https://downloads.xenproject.org/release/xen/4.18.5/.

We recommend all users of the 4.18 stable series to update to this (now
firmly) final full-support point release. The branch is moving into security-
only maintenance mode now.

Regards, Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 09:35:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:35:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986669.1372216 (Exim 4.92)
	(envelope-from )
	id 1uFrTs-0003Pn-Tl; Fri, 16 May 2025 09:35:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986669.1372216; Fri, 16 May 2025 09:35: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 1uFrTs-0003Pg-RA; Fri, 16 May 2025 09:35:52 +0000
Received: by outflank-mailman (input) for mailman id 986669;
 Fri, 16 May 2025 09:35:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrTs-0002s5-4d
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:35:52 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 280bf59b-3239-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 11:35:51 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-43d2d952eb1so14505065e9.1
 for ; Fri, 16 May 2025 02:35:51 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442f39ef400sm95489535e9.33.2025.05.16.02.35.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 02:35: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" 
X-Inumbo-ID: 280bf59b-3239-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747388151; x=1747992951; darn=lists.xenproject.org;
        h=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;
        bh=jKvQM2YaUYz6E5m9TlyGKYjSE2MYS//1zmKQO6qAEI8=;
        b=DT4sudK9uokygriXcVM3xJy+ZMHVMUG5iAt/xR71EEHo9JZ9n7pPrtOi1donJhnH95
         0c8fjjhCrk1xjvQfrpU1uZgGniYYIyLHWzSJTda2XGCDVgpG7cK2NkEIPr6pxjMSyKjR
         Rp5WpAhka2x802gzGf+ewigGwRi8NRwfg43h+FB9OHLN4KM+P1Bt9TPtD3BUAwfTO8/m
         k74bb9ppoL71ZuKlDYOUoDNeuR+//tJvBSZRnEUV3ll2V6Rqj56oEfi8BQJOSTH1GKbA
         kIzuI0SO2WyWVXrUcl2mD/nCXKK/fzv/VbpzqCCoV/YPnaEO2Tr78w/rkwd9N7dTQ/pJ
         5wKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747388151; x=1747992951;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=jKvQM2YaUYz6E5m9TlyGKYjSE2MYS//1zmKQO6qAEI8=;
        b=AeQkGqDtU61m3VjxQ4JIiQNNXE9cD/Pf5urHCeYm1OnXzkI22+SnZ9/njlAKPTc/HI
         JUHwekSZmASKZ5dNAmynzrqP4VvwWcsuXOCauC1u9s0xo64W/Um20Gi7615yfDGtJ0XU
         rR2Q+o4xlpkBFD8zsZOxi/dIMKBVbsdvzdr454gPfCDw662mxjejDVigFg+N+ZKYr0BC
         RytnaxaUQtOra2MI1gG0KOlqY/D0C0MXBcMCbwDaAXIzG7zeeyiT0dA8fIZqr+q9ygbU
         h+NC6Vgh6LbWQYdGU6X4rTgEug9b9Qb1mtqhGcUW80OlX1t7bKDf/9Wc42YyvrGP2XdJ
         R1jg==
X-Forwarded-Encrypted: i=1; AJvYcCUnJDubD9I2S5j8d7itoi8yllCr7uOLILhn/SJ96pnib8UgF0gig5XGa+LGJyToAaBMlYh6dH/IbBw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyLMV/JqzS2FqMt47Hlp14mXHc/7lFKstk/JH7UTPbZyiTOgUzR
	dW44MqyGHIRHZxta5xar2GxWhoka+b7JQA9m7Q1WOnlUm41iUZXr43FY
X-Gm-Gg: ASbGncuTyCezRERMIz200QUwvZKseQoiRG1q5lamc8W3RLo9pGfgho3BesgE30F6bU7
	4OGnG5sQJqX/vQNbJwtYOugezPne6dwmtXFYTCSxCPn0Gn8TbC21vOsN2VbjIBgFsnKKvrMVm+Q
	efCqpdpN69XDmjbRrPgShzwweCIRVVFu0RQPuD3q4iSZmxpLuIf3B3DbJo+IaZgK0zV1sJ2+laD
	TLGYCA/CGd7VUjMKu60dKp+wHArVz0bmPY8jZufABwj9sq6ifhJn5mmQVnez8P+lVpGkenwquzc
	lX+hJzut98bPdBDEPIZm5pfeTK0vE4RAPzZjRWLfXMFGVfTHDI/Ltrk7gTXa72/WeiXm0IlOZcj
	GX2iLTKH9zrofFAPelPRgfNpA
X-Google-Smtp-Source: AGHT+IFQm66DxQAc6kuHaxp+aEXDs6AZPcF4YfRP1IUgCdSq7nVCJ/esUEaIt6+3itYNW+tUonjVLg==
X-Received: by 2002:a05:600c:4447:b0:43d:172:50b1 with SMTP id 5b1f17b1804b1-442fd675932mr26752155e9.29.1747388150736;
        Fri, 16 May 2025 02:35:50 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------96dXM9TeOU0YIUMASWjQW94d"
Message-ID: <8d6efc98-079a-44ac-9cf0-1c5441eaa46a@gmail.com>
Date: Fri, 16 May 2025 11:35:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/16] xen/riscv: introduce support of Svpbmt extension
To: Jan Beulich 
Cc: Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , xen-devel@lists.xenproject.org
References: 
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------96dXM9TeOU0YIUMASWjQW94d
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/13/25 6:00 PM, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> Svpbmt extension is necessary for chaning the memory type for a page contains
>> a combination of attributes that indicate the cacheability, idempotency,
>> and ordering properties for access to that page.
> The title suggest use of the extension is optional.
>
>> --- a/xen/arch/riscv/Kconfig
>> +++ b/xen/arch/riscv/Kconfig
>> @@ -10,11 +10,25 @@ config RISCV
>>   config RISCV_64
>>   	def_bool y
>>   	select 64BIT
>> +	select HAS_SVPBMT
> Such redundant ...
>
>>   config ARCH_DEFCONFIG
>>   	string
>>   	default "arch/riscv/configs/tiny64_defconfig"
>>   
>> +config HAS_SVPBMT
>> +	bool
>> +	depends on RISCV_64
> ... dependencies are frowned upon, afaik. And it's pretty certainly not
> needed here.
>
>> +	help
>> +	  This config enables usage of Svpbmt ISA-extension ( Supervisor-mode:
>> +	  page-based memory types).
>> +
>> +	  The memory type for a page contains a combination of attributes
>> +	  that indicate the cacheability, idempotency, and ordering
>> +	  properties for access to that page.
>> +
>> +	  The Svpbmt extension is only available on 64-bit cpus.
> I don't mind the help text, but for a prompt-less option it's of little
> use (beyond what a comment could also achieve).

I'll drop "depends on RISCV_64" for HAS_SVOBMT and leave only 'select HAS_SVPBMT'
and move the help text to commit messaage.

>
>> --- a/xen/arch/riscv/include/asm/page.h
>> +++ b/xen/arch/riscv/include/asm/page.h
>> @@ -46,6 +46,8 @@
>>   #define PAGE_HYPERVISOR_RX          (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE)
>>   
>>   #define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
>> +#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PMBT_IO)
>> +#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PMBT_NOCACHE)
> Hmm, odd - NOCACHE doesn't really mean "no cache" then? I think this
> would require a comment then.

According to the table (Svpbmt Memory Type definitions) in the comment below these
definitions both of them (PTE_PMBT_IO and PTE_PMBT_NOCACHE) are non-cachable.

I wasn't sure what and for what should be used so I did in sync with Arm which
defines "#define PAGE_HYPERVISOR_NOCACHE (_PAGE_DEVICE|MT_DEVICE_nGnRE)" where
MT_DEVICE_nGnRE is equivalent of PTE_PMBT_IO.

I can add the comment above definition of PAGE_HYPERVISOR_NOCACHE:
/* Non-cacheable, non-idempotent, strongly-ordered I/O memory */.

Something similar then I can add for PAGE_HYPERVISOR_WC:
/* Non-cacheable, idempotent, weakly-ordered Main Memory */

>
>> @@ -56,8 +58,21 @@
>>   #define PTE_SMALL       BIT(10, UL)
>>   #define PTE_POPULATE    BIT(11, UL)
>>   
>> +/*
>> + * [62:61] Svpbmt Memory Type definitions:
>> + *
>> + *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
>> + *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
>> + *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
>> + *  11 - Rsvd   Reserved for future standard use
>> + */
>> +#define PTE_PMBT_NOCACHE    BIT(61, UL)
>> +#define PTE_PMBT_IO         BIT(62, UL)
> Unlike PTE_SMALL and PTE_POPULATE these are arch-defined; I think they
> want to move up to where the other arch-defined bits are, thus also
> maping them appear before their first use.

Sure, I'll move them up.

Thanks.

~ Oleksii

--------------96dXM9TeOU0YIUMASWjQW94d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/13/25 6:00 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    Svpbmt extension is necessary for chaning the memory type for a page contains
a combination of attributes that indicate the cacheability, idempotency,
and ordering properties for access to that page.

    
      
    
      
    The title suggest use of the extension is optional.


    
      
    
        
    --- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -10,11 +10,25 @@ config RISCV
 config RISCV_64
 	def_bool y
 	select 64BIT
+	select HAS_SVPBMT

    
      
    
      
    Such redundant ...


    
      
    
        
     config ARCH_DEFCONFIG
 	string
 	default "arch/riscv/configs/tiny64_defconfig"
 
+config HAS_SVPBMT
+	bool
+	depends on RISCV_64

    
      
    
      
    ... dependencies are frowned upon, afaik. And it's pretty certainly not
needed here.


    
      
    
        
    +	help
+	  This config enables usage of Svpbmt ISA-extension ( Supervisor-mode:
+	  page-based memory types).
+
+	  The memory type for a page contains a combination of attributes
+	  that indicate the cacheability, idempotency, and ordering
+	  properties for access to that page.
+
+	  The Svpbmt extension is only available on 64-bit cpus.

    
      
    
      
    I don't mind the help text, but for a prompt-less option it's of little
use (beyond what a comment could also achieve).
    
    
    
    
    I'll drop "depends on RISCV_64" for HAS_SVOBMT and leave only 'select HAS_SVPBMT'
and move the help text to commit messaage.


    
    
    
      
    

    
      
    
        
    --- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -46,6 +46,8 @@
 #define PAGE_HYPERVISOR_RX          (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE)
 
 #define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
+#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PMBT_IO)
+#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PMBT_NOCACHE)

    
      
    
      
    Hmm, odd - NOCACHE doesn't really mean "no cache" then? I think this
would require a comment then.
    
    
    
    
    According to the table (Svpbmt Memory Type definitions) in the comment below these
definitions both of them (PTE_PMBT_IO and PTE_PMBT_NOCACHE) are non-cachable.

I wasn't sure what and for what should be used so I did in sync with Arm which
defines "#define PAGE_HYPERVISOR_NOCACHE (_PAGE_DEVICE|MT_DEVICE_nGnRE)" where
MT_DEVICE_nGnRE is equivalent of PTE_PMBT_IO.

I can add the comment above definition of PAGE_HYPERVISOR_NOCACHE:
/* Non-cacheable, non-idempotent, strongly-ordered I/O memory */.

Something similar then I can add for PAGE_HYPERVISOR_WC:
/* Non-cacheable, idempotent, weakly-ordered Main Memory */


    
    
    
      
    

    
      
    
        
    @@ -56,8 +58,21 @@
 #define PTE_SMALL       BIT(10, UL)
 #define PTE_POPULATE    BIT(11, UL)
 
+/*
+ * [62:61] Svpbmt Memory Type definitions:
+ *
+ *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
+ *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
+ *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
+ *  11 - Rsvd   Reserved for future standard use
+ */
+#define PTE_PMBT_NOCACHE    BIT(61, UL)
+#define PTE_PMBT_IO         BIT(62, UL)

    
      
    
      
    Unlike PTE_SMALL and PTE_POPULATE these are arch-defined; I think they
want to move up to where the other arch-defined bits are, thus also
maping them appear before their first use.
    
    
    
    
    Sure, I'll move them up.

Thanks.

~ Oleksii

    
  


--------------96dXM9TeOU0YIUMASWjQW94d--


From xen-devel-bounces@lists.xenproject.org Fri May 16 09:45:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:45:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986699.1372227 (Exim 4.92)
	(envelope-from )
	id 1uFrdU-0005a2-Qk; Fri, 16 May 2025 09:45:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986699.1372227; Fri, 16 May 2025 09:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFrdU-0005Zv-N0; Fri, 16 May 2025 09:45:48 +0000
Received: by outflank-mailman (input) for mailman id 986699;
 Fri, 16 May 2025 09:45:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrdT-0005Zo-CD
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:45:47 +0000
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com
 [2607:f8b0:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 89884c1e-323a-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 11:45:45 +0200 (CEST)
Received: by mail-pf1-x430.google.com with SMTP id
 d2e1a72fcca58-7376dd56f8fso2284499b3a.2
 for ; Fri, 16 May 2025 02:45:45 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 41be03b00d2f7-b26eb0a76f8sm1172704a12.68.2025.05.16.02.45.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 02:45: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" 
X-Inumbo-ID: 89884c1e-323a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747388743; x=1747993543; 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;
        bh=eCUHMmwmA5X7WnPUkmR4QV/PMvOkkG7ln2HsbBM+65c=;
        b=t46r1x6SwV0LKtK2EuYeCmQ5PGVUJFGIQqPA1OF+io7yV5s7Jii4SJyMAcprB7CMnZ
         RHJh4nz4/jfw2yTZ4DlJThUNEUoEul3jNs9l9mUWND+hytJ4ZI2vV2rvCKIDLdHIK+/k
         uTxoKa8JRWjDnTrjKjVNRlfL1Jwqk6d/AZVPQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747388743; x=1747993543;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=eCUHMmwmA5X7WnPUkmR4QV/PMvOkkG7ln2HsbBM+65c=;
        b=EWFs69BdJSrqMjWBb4Jxyw3tfCPT7VBXFPD7Cc/x6dIlifKHXnOE09KXNWkyeVFai8
         AtXb35yh0PLRZ+/JNP0wER1bBYw+cYn9rJ60CaiGX+4q+jVgwG2ZLc/RMT/2Rxh2k3UD
         Qy7WabUz2XcjU//XDfRnjhThcqWvcTRiG/iNbZuRCwazLw29l22/ILKUsabG/fkqFTP2
         OcooLfU6rrhA1k1qOybt6D/aNP0zUiuP5AaGrLW5wx8QO67J1Jx1sKz72pzlv0fVuMPn
         0IuFe3R74lxO22m697hVITh7WLLfFSQ5Eqjk0AE7XAEIDYqDDwMoY0eZ7y+0X/4DzOMA
         6uUQ==
X-Gm-Message-State: AOJu0YwixKwKzNZZXQZVfwB/8aIqdJNx4e3weE87fyxso/nBSSze7hW8
	TJlIUCU+Usa35w0c0yycFQu9QwOXy7JEEgn1RkgJ0F9V/Vp9hUPBGMarwvBAwB5MdzBjh8m8jMr
	1ZQs6
X-Gm-Gg: ASbGncsuDZHJhxdzsPIqiK6NzhehIaut8L+jwZalMHdU3rfwIvvFCzy6t4/uAP0iGHF
	yA5zV/BqeIbu+UQJwJJ1g1GHNPFT1CnH6smzqknjwEblpv6w0hQWt7Xqio2wBaxi8rEvsHSyn6F
	EIo968lvh/MUQj0YG/F86b7OOYXWcreBwOEcoaF2XKsEqGEFKDORXyPYQYA4XVNUl1aFIyPtwtg
	Q0qULBh/lc4soZVCNr2GVPXpQtiq0fU4Vwb3bohqL4K7fqgdsMXLa4MK1QMsEb2YxiY3KbLUWJS
	TzupbMmUoLkc1Ryw8F3rUyrZHAOy2EXz8YQnaGwgCMTXNTIwy3b9n1IWYz2QM5ILuZmZRoQI4Y2
	E+gi92phIOdD/YUXgN3BLc4vNnVpzWw==
X-Google-Smtp-Source: AGHT+IHrBx9T26PL0AbxlClWp/1+5AnlX6x5P8hGzjzGg2ylctM83/ZNN97cYXSyVnm6GXucA1pcCw==
X-Received: by 2002:a05:6a20:a115:b0:1f8:d245:616d with SMTP id adf61e73a8af0-21621902a80mr3991418637.21.1747388742893;
        Fri, 16 May 2025 02:45:42 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Oleksii Kurochko ,
	Community Manager ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 0/6] xen: cache control improvements
Date: Fri, 16 May 2025 11:45:29 +0200
Message-ID: <20250516094535.63472-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

Following series contain some fixes for cache control operations, the
main focus is to reduce the load on big systems when cache control
operations are executed.

Patches 1-4 are bugfixes, while patches 5 and 6 are improvements
to the current code.

Thanks, Roger.

Roger Pau Monne (6):
  x86/pv: fix emulation of wb{,no}invd to flush all pCPU caches
  x86/gnttab: do not implement GNTTABOP_cache_flush
  xen/x86: rename cache_flush_permitted() to has_arch_io_resources()
  xen/x86: account for assigned PCI devices in cache_flush_permitted()
  x86/hvm: limit memory type cache flush to running domains
  x86/hvm: reduce the need to flush caches in memory_type_changed()

 CHANGELOG.md                        |  3 +++
 xen/arch/x86/hvm/mtrr.c             | 17 +++++++++++++++--
 xen/arch/x86/include/asm/flushtlb.h | 19 -------------------
 xen/arch/x86/include/asm/iocap.h    |  5 ++++-
 xen/arch/x86/mm.c                   |  4 +---
 xen/arch/x86/mm/p2m-pod.c           |  4 ++--
 xen/arch/x86/pv/emul-priv-op.c      |  6 +++---
 xen/common/Kconfig                  |  5 +++++
 xen/common/grant_table.c            |  6 ++++++
 xen/common/memory.c                 |  2 +-
 xen/include/asm-generic/iocap.h     |  4 +++-
 11 files changed, 43 insertions(+), 32 deletions(-)

-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:45:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:45:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986700.1372237 (Exim 4.92)
	(envelope-from )
	id 1uFrde-0005qa-1a; Fri, 16 May 2025 09:45:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986700.1372237; Fri, 16 May 2025 09:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFrdd-0005qT-U6; Fri, 16 May 2025 09:45:57 +0000
Received: by outflank-mailman (input) for mailman id 986700;
 Fri, 16 May 2025 09:45:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrdd-0005Zo-45
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:45:57 +0000
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com
 [2607:f8b0:4864:20::42b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8fa32de5-323a-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 11:45:55 +0200 (CEST)
Received: by mail-pf1-x42b.google.com with SMTP id
 d2e1a72fcca58-74251cb4a05so2664544b3a.3
 for ; Fri, 16 May 2025 02:45:55 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-742a982b862sm1189293b3a.105.2025.05.16.02.45.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 02:45: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" 
X-Inumbo-ID: 8fa32de5-323a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747388753; x=1747993553; 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;
        bh=93X5Yg3wMInb8uao5HlZu8C6yt5D96Z1mKvVI2CvQcU=;
        b=gtwsatLZzEg8lpQUGrOaTkHwKhSimQz6RbM0TAD6/PnlyiuZ2j8rfy5/60rjFuOCYk
         ZjsJNG3mICKddzrQ5g4W2PSZzJLt704J0Gan3T9VTZJ4FwXck+9GkMfd/FI7LlDGu8Th
         0ENsrfj2gkUNyv28tv5F80m4Cs3TX64AwCP8w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747388753; x=1747993553;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=93X5Yg3wMInb8uao5HlZu8C6yt5D96Z1mKvVI2CvQcU=;
        b=eDPSbFiiwkFlYYsPeDHdsqavj1C+6YdpGR8J/pjxwBHYKjgIMtBAUrReoMG347hX2L
         Z50Q//7tjOnqThioByR1OpndiZKyp1S7m+iMEuirAvfzHMxPIfHo13eeYA4JJS9WJL9L
         UJ4qFejKyaa9diYoK6wOWlfLQSkRrwUukAdG6VygG+81qZFHKh/sMjsldTkY/RRSj67c
         5QQ8W148xM54Cbc6ViUoVrmVBpGwuH/5wpQBGdvbqHG0bfSvnDRl31tSMxhgKGVcgw2/
         /t8gB+fGjciq8+xGOIreaNzqFD/ca+iAJGhY56xOD+znRqllYLNiy/eMOdihO2VwNvpZ
         8XjA==
X-Gm-Message-State: AOJu0YwhbvBPr691DFSi6m9SrkwKPVxEz7yEBd2TmBeQmqWNKlgiOO5q
	HQ8TXs780ri1BVjQ0JDV5NcMiD1GplhIGBBCJZBPxs/WG3SwkoRsa7E75yNwIgJG/7DGatJfLdH
	FPkVW
X-Gm-Gg: ASbGncvzRsWbdDtNX3dqK6gzQdwH7nQDnokkFcpuQLdDqJ6XjzVtuysr7Y80srZgoQV
	uSDo8yN8cHw9amFsKndzjaBRFfQb7vijt8uquWX9B6nRrGCP2j8d60dL6PQYYkJxbbjgFmksY56
	LVY8YPNMeFASiqbxZDYvXR1IPRBXGct9+v78/cQEaqQpPa3IvnX6ebpa62SxLWo8CLxmcxzruKM
	dqWSDxeKtRClTQHiRdUZo/UMIOaPsSEaVNO2CxD+mhMcdqnzZWHbqKQ0M6YnAR9qTPVPQT20+g/
	WF171VGaGIc2VBpIWfOMbUx3+mHuBpIXq1y6MnySk7Gm09AEjjYxfIiPp8XAX+gPQDoWlYoIGRK
	iqMJngKTew0u9mG19xvU=
X-Google-Smtp-Source: AGHT+IGmn3MvOmV8mmHycD0BBlPLXNGiENIKJLel6O1rrj6kzeKAaYj95YHcYfV7Su6LkSP1oyOhrA==
X-Received: by 2002:a05:6a20:4329:b0:215:d217:2194 with SMTP id adf61e73a8af0-216219ed0cemr4716758637.34.1747388753189;
        Fri, 16 May 2025 02:45:53 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v2 1/6] x86/pv: fix emulation of wb{,no}invd to flush all pCPU caches
Date: Fri, 16 May 2025 11:45:30 +0200
Message-ID: <20250516094535.63472-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250516094535.63472-1-roger.pau@citrix.com>
References: <20250516094535.63472-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current emulation of wb{,no}invd is bogus for PV guests: it will only
flush the current pCPU cache, without taking into account pCPUs where the
vCPU had run previously.  Resort to flushing the cache on all host pCPUs to
make it correct.

Fixes: 799fed0a7cc5 ("Priv-op emulation in Xen, for RDMSR/WRMSR/WBINVD")
Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Use the recently introduced FLUSH_CACHE_WRITEBACK.
---
 xen/arch/x86/pv/emul-priv-op.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 295d847ea24c..20a90703c83c 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -1198,13 +1198,13 @@ static int cf_check cache_op(
     if ( !cache_flush_permitted(current->domain) )
         /*
          * Non-physdev domain attempted WBINVD; ignore for now since
-         * newer linux uses this in some start-of-day timing loops.
+         * Linux uses this in some start-of-day code.
          */
         ;
     else if ( op == x86emul_wbnoinvd /* && cpu_has_wbnoinvd */ )
-        wbnoinvd();
+        flush_all(FLUSH_CACHE_WRITEBACK);
     else
-        wbinvd();
+        flush_all(FLUSH_CACHE);
 
     return X86EMUL_OKAY;
 }
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:46:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:46:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986703.1372247 (Exim 4.92)
	(envelope-from )
	id 1uFrdp-0006Ec-80; Fri, 16 May 2025 09:46:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986703.1372247; Fri, 16 May 2025 09:46: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 1uFrdp-0006EO-4r; Fri, 16 May 2025 09:46:09 +0000
Received: by outflank-mailman (input) for mailman id 986703;
 Fri, 16 May 2025 09:46:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrdo-0005Zo-AE
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:46:08 +0000
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com
 [2607:f8b0:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 96213000-323a-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 11:46:06 +0200 (CEST)
Received: by mail-pf1-x436.google.com with SMTP id
 d2e1a72fcca58-7410c18bb00so2717139b3a.3
 for ; Fri, 16 May 2025 02:46:06 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-742a9709293sm1141408b3a.37.2025.05.16.02.45.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 02:45: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" 
X-Inumbo-ID: 96213000-323a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747388764; x=1747993564; 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;
        bh=iOJBhBPo4a9LrsqKDMKYH/ap103lQmBfKYXtkZwpVQM=;
        b=lF1H26g0NjmL8Xsk7CwvKILANCnq9cPSX0/Htkat8BpfZvBq7MkNSgF/fCMNpulVcm
         F3032Yv9py+r9hlKMUYB5pejICtMvYPDokM9BzU+yPNekJpfk2m7mtGkhH7KdjpA08YO
         5Yxo2o67NPmFp9PJ0/7V8mSPZZAjRIUefOfjE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747388764; x=1747993564;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=iOJBhBPo4a9LrsqKDMKYH/ap103lQmBfKYXtkZwpVQM=;
        b=eRIMrtSit8vnAVBSPBPdis6HZaYf9LuVTU7tgukK9BQ7l0QNwxeupoAFkWe+wIvWVq
         2MSBIq9lfvGebcN4WQJd5lNEGSujrdFV6caoJNpvIDbicM4R1Q3IwSTmKdICW9czIEAh
         wLagqfVJIEZCkf2xUZ6q+Vw50BSQyPMWAYVpRAID7Euvue6/O+TYHlvpRodKwgRAruRZ
         /02ug+72u8xmu3Detym9MQFP0JQUiovKgjasg2GF2ui6yB2qUihNeo7qXp7KNbi47zUC
         /mUwoljSY558NM/M1BfaRCFXOje6pv27L64Uj/hU5I8Qp5J3p7gSp921j8nFcqc4dWfn
         hDdA==
X-Gm-Message-State: AOJu0Yx39W7RM93LrGOXJcV1AqDKKqkEJbRsfd5iefqfvnIrIazUqWET
	BqdbpFtsiAZ808ZQs5TZV5tGSCnFRU5w3nNik5JPKUxeXgpHdpS59WDofx5xN+HtAhjyv1ycp7c
	vOW7/
X-Gm-Gg: ASbGncs3+O2oIpadSLCzqMI3j7/VYmhCGblTXsOTT9mPTid6msXVAy8I8fOJ7Sw4ZUc
	GkEkPJrtNmaINg3t96HAYpDx/kJltvAiTLq7pLhjU2ng/ZDRojBonjrudR5b7p7x2w9SVykitRL
	WLPe2Iv6f/yk4pYj+UhYl5Mc6HNmoLKohvLREZLE83sclZhWXnzcla17ATcFng17+bIfp1JtDEl
	z8ONs9tI/gl3+xBk/QgpltXkQp8KEQRU32jmESZtjUaAW6h8it9wOIi91Z/c7ZjHDdKllF8r2Sn
	jzkQIh2JxPXCXR7IxmssYfuyjjJL1QN36T3FWShyXOQ+20+zdXnLzVKXUpgbkX0P7TWwUxGKfLG
	9AYA952LVKOlZ5oiHLH8=
X-Google-Smtp-Source: AGHT+IHHiGctnGUQIkWjGc9bS9CAz9UCC2o2b/09UUWBjbv+6+SIV7qCKFJl17nbgqyZ0iDG0A/WWw==
X-Received: by 2002:a05:6a00:9168:b0:736:3d7c:236c with SMTP id d2e1a72fcca58-742acce71d9mr2490679b3a.14.1747388758729;
        Fri, 16 May 2025 02:45:58 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 2/6] x86/gnttab: do not implement GNTTABOP_cache_flush
Date: Fri, 16 May 2025 11:45:31 +0200
Message-ID: <20250516094535.63472-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250516094535.63472-1-roger.pau@citrix.com>
References: <20250516094535.63472-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current underlying implementation of GNTTABOP_cache_flush on x86 won't
work as expected.  The provided {clean,invalidate}_dcache_va_range()
helpers only do a local pCPU cache flush, so the cache of previous pCPUs
where the vCPU might have run are not flushed.

However instead of attempting to fix this, make the GNTTABOP_cache_flush
operation only available to ARM.  There are no known users on x86, the
implementation is broken, and other architectures don't have grant-table
support yet.

With that operation not implemented on x86, the related
{clean,invalidate}_dcache_va_range() helpers can also be removed.

Fixes: f62dc81c2df7 ("x86: introduce more cache maintenance operations")
Fixes: 18e8d22fe750 ("introduce GNTTABOP_cache_flush")
Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Introduce Kconfig option.
 - Introduce CHANGELOG entry.
---
 CHANGELOG.md                        |  3 +++
 xen/arch/x86/include/asm/flushtlb.h | 19 -------------------
 xen/common/Kconfig                  |  5 +++++
 xen/common/grant_table.c            |  6 ++++++
 4 files changed, 14 insertions(+), 19 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1ea06524db20..21d7be0aa389 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -24,6 +24,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
     - Ability to enable stack protector
 
 ### Removed
+ - On x86:
+   - GNTTABOP_cache_flush: it's unused on x86 and the implementation is
+     broken.
 
 ## [4.20.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.20.0) - 2025-03-05
 
diff --git a/xen/arch/x86/include/asm/flushtlb.h b/xen/arch/x86/include/asm/flushtlb.h
index 209ea1e62fae..cd625f911436 100644
--- a/xen/arch/x86/include/asm/flushtlb.h
+++ b/xen/arch/x86/include/asm/flushtlb.h
@@ -184,25 +184,6 @@ void flush_area_mask(const cpumask_t *mask, const void *va,
 }
 
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache) {}
-static inline int invalidate_dcache_va_range(const void *p,
-                                             unsigned long size)
-{ return -EOPNOTSUPP; }
-static inline int clean_and_invalidate_dcache_va_range(const void *p,
-                                                       unsigned long size)
-{
-    unsigned int order = get_order_from_bytes(size);
-    /* sub-page granularity support needs to be added if necessary */
-    flush_area_local(p, FLUSH_CACHE|FLUSH_ORDER(order));
-    return 0;
-}
-static inline int clean_dcache_va_range(const void *p, unsigned long size)
-{
-    unsigned int order = get_order_from_bytes(size);
-
-    /* sub-page granularity support needs to be added if necessary */
-    flush_area_local(p, FLUSH_CACHE_WRITEBACK | FLUSH_ORDER(order));
-    return 0;
-}
 
 unsigned int guest_flush_tlb_flags(const struct domain *d);
 void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask);
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6d43be2e6e8a..563b036474c0 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -35,6 +35,11 @@ config GRANT_TABLE
 
 	  If unsure, say Y.
 
+config HAS_GRANT_CACHE_FLUSH
+	bool
+	depends on GRANT_TABLE
+	default ARM
+
 config EVTCHN_FIFO
 	bool "Event Channel Fifo support" if EXPERT
 	default y
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index e75ff98aff1c..cf131c43a1f1 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -940,6 +940,7 @@ static void reduce_status_for_pin(struct domain *rd,
         gnttab_clear_flags(rd, clear_flags, status);
 }
 
+#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
 static struct active_grant_entry *grant_map_exists(const struct domain *ld,
                                                    struct grant_table *rgt,
                                                    mfn_t mfn,
@@ -975,6 +976,7 @@ static struct active_grant_entry *grant_map_exists(const struct domain *ld,
 
     return ERR_PTR(-EINVAL);
 }
+#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
 
 union maptrack_node {
     struct {
@@ -3520,6 +3522,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) uop,
     return 0;
 }
 
+#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
 static int _cache_flush(const gnttab_cache_flush_t *cflush, grant_ref_t *cur_ref)
 {
     struct domain *d, *owner;
@@ -3631,6 +3634,7 @@ gnttab_cache_flush(XEN_GUEST_HANDLE_PARAM(gnttab_cache_flush_t) uop,
 
     return 0;
 }
+#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
 
 long do_grant_table_op(
     unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
@@ -3773,6 +3777,7 @@ long do_grant_table_op(
         break;
     }
 
+#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
     case GNTTABOP_cache_flush:
     {
         XEN_GUEST_HANDLE_PARAM(gnttab_cache_flush_t) cflush =
@@ -3789,6 +3794,7 @@ long do_grant_table_op(
         }
         break;
     }
+#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
 
     default:
         rc = -ENOSYS;
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:46:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:46:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986706.1372258 (Exim 4.92)
	(envelope-from )
	id 1uFrdt-0006cm-KZ; Fri, 16 May 2025 09:46:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986706.1372258; Fri, 16 May 2025 09:46: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 1uFrdt-0006cf-Fn; Fri, 16 May 2025 09:46:13 +0000
Received: by outflank-mailman (input) for mailman id 986706;
 Fri, 16 May 2025 09:46:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFrdr-0006aW-Mp
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:46:11 +0000
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com
 [2607:f8b0:4864:20::42f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 98b81a2d-323a-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 11:46:11 +0200 (CEST)
Received: by mail-pf1-x42f.google.com with SMTP id
 d2e1a72fcca58-7426159273fso2000551b3a.3
 for ; Fri, 16 May 2025 02:46:10 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-742a98a31desm1183320b3a.171.2025.05.16.02.46.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 02:46: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" 
X-Inumbo-ID: 98b81a2d-323a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747388769; x=1747993569; 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;
        bh=aI/Od08PB2sXeLZpJWvF+CUi72sZFREksWnrg/Tt/Yw=;
        b=SUo5erHQObkLTo+hpLRTMX4Hqo6SsoUETx+RPBZOvMtC9mllB/CQFJyhPEUgmjmhRW
         nftSHEX0SebsNWdTP4aEDmWa28OHpFKDI2iRMpcgNxrXYSSr+e6Z+Ls8/xKicQaU6A6q
         HZxLIcMW7r0zclmtBe8Ne5DY1OwMYlrQPoTb0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747388769; x=1747993569;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=aI/Od08PB2sXeLZpJWvF+CUi72sZFREksWnrg/Tt/Yw=;
        b=wuYj+HRzqgU2TQZ+3sEc1tIEhYNOsbW7oFceyhY7WjWsz30UIu1jxJ3Vv+OPmLRZ3+
         v/C1Q8sQPsJoIkRoWI0MV8SMLVOD4EC13QbmEbZKx4THxXGGrE2IqVGFcRb3EJcVbtee
         D2OQbXF0R2ouSvmAuXXv0+lBbWhImarFF4/iw2ahy6jo18wJDfpLbMh5364w7pUexflZ
         MTiltARnHKw4OYl2fSWxrtwbEF+M852WR3AD0FmQNu9l5T1Iw78R/6JCI9Wx+eneqMO/
         Qqqgdh7nLVIpskflA4gbV+7823p6+rATOLcL9Ptzj0nsDItP1dby+42nuoSowxGmx+eC
         xF7A==
X-Gm-Message-State: AOJu0Yz70lrraUODqzZqvT07zevbx0XxtIWGzzyx411vDGRv+UoPPLHT
	1wijqzKsDfKh450mgbUJQX51q3yszLOkUPUfjdrga18vT7jxJ1aNmEhyY0+ES2lhKcnEPnNkgXh
	4NFQT
X-Gm-Gg: ASbGncusxt4PXsx5ttS62Ly3ivccM0+pbf7FOx2ggH6sC3J3PWkHQ0lGbckqpWS6k+q
	TMYyQpOcNmMEvcXTo0mu+U2uPg2l0f78Ps61jLxcaAQMjFeLzAP7AorlHH3SPUga96MQuqEB8bF
	iC1VfloYvcW5CctCWbBAGU6TL+05mOoVUu5ABHsuNJrq6MmkBNES9I9kgMnge7YmCPAVRIcw/h/
	Po36T9z7u19gkfo7ZK6BBEhu58xqym0BAc8jxhfmngbMpeF0Xy4srI3WcbV7Rbf7jxwzb2NId3e
	gsihlxdkyaDmvxHdeke9/5HhINH6E+zf7sSZtWuT8AqnTolY+jEINoN58JphKzmgPm1iRwzv0KP
	HbcQhZl7YeLVRcLpmv+M=
X-Google-Smtp-Source: AGHT+IE2Dm7Fvn6dqSKkjswk2/qDy0PNEC3SAmtxqH3bJ4rd7I+/nQAqb7QFMMdyi4SORj2LvRBL/A==
X-Received: by 2002:a05:6a00:4c87:b0:730:9502:d564 with SMTP id d2e1a72fcca58-742acce2c1cmr2762355b3a.14.1747388768897;
        Fri, 16 May 2025 02:46:08 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v2 3/6] xen/x86: rename cache_flush_permitted() to has_arch_io_resources()
Date: Fri, 16 May 2025 11:45:32 +0200
Message-ID: <20250516094535.63472-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250516094535.63472-1-roger.pau@citrix.com>
References: <20250516094535.63472-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

To better describe the underlying implementation.  Define
cache_flush_permitted() as an alias of has_arch_io_resources(), so that
current users of cache_flush_permitted() are not effectively modified.

With the introduction of the new handler, change some of the call sites of
cache_flush_permitted() to instead use has_arch_io_resources() as such
callers are not after whether cache flush is enabled, but rather whether
the domain has any IO resources assigned.

No functional change intended.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Drop adjustment to l1_disallow_mask().
---
 xen/arch/x86/include/asm/iocap.h | 4 +++-
 xen/arch/x86/mm/p2m-pod.c        | 4 ++--
 xen/common/memory.c              | 2 +-
 xen/include/asm-generic/iocap.h  | 4 +++-
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/include/asm/iocap.h b/xen/arch/x86/include/asm/iocap.h
index 53d87ae8a334..61d026dbf5f6 100644
--- a/xen/arch/x86/include/asm/iocap.h
+++ b/xen/arch/x86/include/asm/iocap.h
@@ -15,10 +15,12 @@
 #define ioports_access_permitted(d, s, e)               \
     rangeset_contains_range((d)->arch.ioport_caps, s, e)
 
-#define cache_flush_permitted(d)                        \
+#define has_arch_io_resources(d)                        \
     (!rangeset_is_empty((d)->iomem_caps) ||             \
      !rangeset_is_empty((d)->arch.ioport_caps))
 
+#define cache_flush_permitted has_arch_io_resources
+
 static inline int ioports_permit_access(struct domain *d, unsigned long s,
                                         unsigned long e)
 {
diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index df2a1cc0749b..05633fe2ac88 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -338,7 +338,7 @@ p2m_pod_set_mem_target(struct domain *d, unsigned long target)
 
     ASSERT( pod_target >= p2m->pod.count );
 
-    if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
+    if ( has_arch_pdevs(d) || has_arch_io_resources(d) )
         ret = -ENOTEMPTY;
     else
         ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
@@ -1395,7 +1395,7 @@ guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
     if ( !paging_mode_translate(d) )
         return -EINVAL;
 
-    if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
+    if ( has_arch_pdevs(d) || has_arch_io_resources(d) )
         return -ENOTEMPTY;
 
     do {
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8ca4e1a8425b..46620ed8253d 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -86,7 +86,7 @@ static unsigned int max_order(const struct domain *d)
     unsigned int order = domu_max_order;
 
 #ifdef CONFIG_HAS_PASSTHROUGH
-    if ( cache_flush_permitted(d) && order < ptdom_max_order )
+    if ( has_arch_io_resources(d) && order < ptdom_max_order )
         order = ptdom_max_order;
 #endif
 
diff --git a/xen/include/asm-generic/iocap.h b/xen/include/asm-generic/iocap.h
index dd7cb45488f7..664bbc8971fe 100644
--- a/xen/include/asm-generic/iocap.h
+++ b/xen/include/asm-generic/iocap.h
@@ -2,9 +2,11 @@
 #ifndef __ASM_GENERIC_IOCAP_H__
 #define __ASM_GENERIC_IOCAP_H__
 
-#define cache_flush_permitted(d)                        \
+#define has_arch_io_resources(d)                        \
     (!rangeset_is_empty((d)->iomem_caps))
 
+#define cache_flush_permitted has_arch_io_resources
+
 #endif /* __ASM_GENERIC_IOCAP_H__ */
 
 /*
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:46:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:46:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986714.1372267 (Exim 4.92)
	(envelope-from )
	id 1uFre1-00076O-R9; Fri, 16 May 2025 09:46:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986714.1372267; Fri, 16 May 2025 09: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 1uFre1-00076D-Nn; Fri, 16 May 2025 09:46:21 +0000
Received: by outflank-mailman (input) for mailman id 986714;
 Fri, 16 May 2025 09:46:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFre1-0006aW-AP
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:46:21 +0000
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com
 [2607:f8b0:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9eb214d6-323a-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 11:46:21 +0200 (CEST)
Received: by mail-pl1-x636.google.com with SMTP id
 d9443c01a7336-231e21d3b63so5106755ad.3
 for ; Fri, 16 May 2025 02:46:20 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-231d4ebb0d4sm10661265ad.195.2025.05.16.02.46.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 02:46: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" 
X-Inumbo-ID: 9eb214d6-323a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747388779; x=1747993579; 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;
        bh=Hm8AIe/qcud/Th5sHM9Y/G8pv43gmto+PqgQas9D3iE=;
        b=naxO0iRcwb4AjjP5dhSD+p8e+X8Ul2xakaFQNDhWt/CB6ng7YiJZRv57WuJPrg6epx
         uOu/6r8OAxwWSG+W3q7hWm+6/VK36e6ddCb6sXctFVcDgeFmq9EPFs2kqMTBwkvKPlPM
         S2GfpGGxbadp49yDkefqvSZ7lSbjL51JkIQGw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747388779; x=1747993579;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Hm8AIe/qcud/Th5sHM9Y/G8pv43gmto+PqgQas9D3iE=;
        b=UVubzubCq77KJXMVcLXEk6gRRCoRQRhWGEPBO9SBI3ctabzSvOns1tHmCuDT9qSnUs
         9mA61kRBakttRXnbQ+d0xzis8i56PlWKXSane1y0285N4cpflLvLfSrDJlqX4nIAC+7M
         ZUk1rfc7xwWfH6PfBJEfNd6DE4tIiv3KRBvZRBfvVUw0z0y1mtlsOsnFFowT2MvyrQIF
         +LSy9wuiPHkTu7kF57Tsz4ROrxv6J3zOBfCuVQnFGVPu6Zf+8xu/3h2L6kpakiFk5wuV
         whNXAY4bPC5aBsk7JnAW+01iT5qJw2Z92+wHid8hZdzJtmTtb3sgKNVwjxRxJdMuCzy1
         kfeA==
X-Gm-Message-State: AOJu0YyLT9gTAU7jvz1BIFvxwVl9OINRQhJIihExMdmoKXHvyiUrazIG
	dXHbf5ngsIhO8VRisbpJiCq/gOSvVQ+1vyVzu4O8mCPfPguCZD9ldTgxkdgqJk37/9iPIp0HACp
	irngD
X-Gm-Gg: ASbGncsON3+i5avrefOrOv3pm8YApWHWZawB1PBPke/hoXf76BFDVmkEGgleyifFWlO
	V1DZm6Hx423KmEhtI2uIbHoZKD27UhH17Am3cyn9kKK/ZdP3DsdItCHVesM8N0yJIxY/FiYWvi1
	QTeqY9OFndIzrfJqeLonU5B4Va/sVAFKRuT3FU77htJHEtdAShEkowOY+ANjSO2lRxYEw30cYsC
	DsWdB071dI0xnKeGJ7vGWGPyVHQ+EX0GwS0MVCJP+QmKi/dt4g7A3DU7GnuKiBtZee5pWpiXgoK
	StX7cuDMBMw48xobTT8lOf5yyZx877LPj5fz98HNd/06O31hlLrsGcA/vYJcGwAcjmwJckRWeiw
	+X2sxOuEXJTym4pleSVr7vWj/ZMdJBg==
X-Google-Smtp-Source: AGHT+IGA+qWfUyBWb2AxiIES1kDVVnjbALZ1vz8DqSY4VtBKeBEI8NkldomOj1H62clyuTKWds7bDg==
X-Received: by 2002:a17:902:d2cf:b0:22d:b305:e082 with SMTP id d9443c01a7336-231de3bb2d0mr23158125ad.47.1747388774593;
        Fri, 16 May 2025 02:46:14 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v2 4/6] xen/x86: account for assigned PCI devices in cache_flush_permitted()
Date: Fri, 16 May 2025 11:45:33 +0200
Message-ID: <20250516094535.63472-5-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250516094535.63472-1-roger.pau@citrix.com>
References: <20250516094535.63472-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

While unlikely, it's possible for PCI devices to not have any IO resources
assigned, yet in such case the owner domain might still need to issue cache
control operations in case the device performs DMA requests.

Adjust cache_flush_permitted() to account for has_arch_pdevs().

While there also switch l1_disallow_mask() to use cache_flush_permitted().
This should be a non-functional change after the adjustment done to
cache_flush_permitted().

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - New in this version.
---
 xen/arch/x86/include/asm/iocap.h | 3 ++-
 xen/arch/x86/mm.c                | 4 +---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/include/asm/iocap.h b/xen/arch/x86/include/asm/iocap.h
index 61d026dbf5f6..f948b7186e95 100644
--- a/xen/arch/x86/include/asm/iocap.h
+++ b/xen/arch/x86/include/asm/iocap.h
@@ -19,7 +19,8 @@
     (!rangeset_is_empty((d)->iomem_caps) ||             \
      !rangeset_is_empty((d)->arch.ioport_caps))
 
-#define cache_flush_permitted has_arch_io_resources
+#define cache_flush_permitted(d) \
+    (has_arch_io_resources(d) || has_arch_pdevs(d))
 
 static inline int ioports_permit_access(struct domain *d, unsigned long s,
                                         unsigned long e)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a1703db762e3..657623336c0e 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -172,9 +172,7 @@ static DEFINE_SPINLOCK(subpage_ro_lock);
 
 #define l1_disallow_mask(d)                                     \
     (((d) != dom_io) &&                                         \
-     (rangeset_is_empty((d)->iomem_caps) &&                     \
-      rangeset_is_empty((d)->arch.ioport_caps) &&               \
-      !has_arch_pdevs(d) &&                                     \
+     (!cache_flush_permitted(d) &&                              \
       is_pv_domain(d)) ?                                        \
      L1_DISALLOW_MASK : (L1_DISALLOW_MASK & ~PAGE_CACHE_ATTRS))
 
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:46:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:46:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986726.1372276 (Exim 4.92)
	(envelope-from )
	id 1uFreP-0007wm-2k; Fri, 16 May 2025 09:46:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986726.1372276; Fri, 16 May 2025 09: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 1uFreO-0007wf-Vh; Fri, 16 May 2025 09:46:44 +0000
Received: by outflank-mailman (input) for mailman id 986726;
 Fri, 16 May 2025 09:46:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFreN-0006aW-OK
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:46:43 +0000
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com
 [2607:f8b0:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ac17ecaa-323a-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 11:46:43 +0200 (CEST)
Received: by mail-pl1-x62c.google.com with SMTP id
 d9443c01a7336-231e21d3b63so5110425ad.3
 for ; Fri, 16 May 2025 02:46:43 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-231d4ed4815sm10598225ad.232.2025.05.16.02.46.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 02:46: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" 
X-Inumbo-ID: ac17ecaa-323a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747388800; x=1747993600; 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;
        bh=6U99Ry1WVYMmbFKuOmzFIjAmeVmHGjlnI3oGFyiiOks=;
        b=Jccy2V2VzBv1vFN+xqIbUtFmFuGGi6QSkj1Ct3TSAOuGo3njdbmkSIyoDsasYLV1N3
         h0kOg5Iu7SSmy2KetErMZgW7FwTdGljMnWI1N33AmrDz9VXb9XJH4Iqo04jO+zDf7gOD
         IB8O5Y9PaMFS7m9o686wHyWML/VVEDDTUxn5A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747388800; x=1747993600;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=6U99Ry1WVYMmbFKuOmzFIjAmeVmHGjlnI3oGFyiiOks=;
        b=ZItx3t3Kzx5gAIXnK4PrxUUmrU2v/fNIh2lII4+Vgumxy5DPJT5L75yf/tNNgt2IGf
         1p+Qr2ehgrrbWOZDq5yOYcnRjDVkTlZ2HC50onJqmanVH+hTPIps2TMAs6A8UR0OZHE6
         fYJop7WlITEPDHcFgKV46seWkWg3jnb2SNk+Y+WJ2JD+usM706KxvI5HGeJPw2JrdOjd
         PvqxSVOI2LdhVLoLWSdrWxfGi61jKWvDlCqHv2VZ52feJXijuFjqowMq7vY9W8ZXEx08
         F33rkTRgbuvkDGzGEDTbbRWf2D2cQklpdl4g4bxc/5QKX8L9rbiW/NSnd/jQful6JbSX
         /4Nw==
X-Gm-Message-State: AOJu0Yz943JxEjVVkztGgKqL0s8LmdWnQkG39fd3Rm5XfiMBpKAahsjF
	pJxEgYPnW24bZRML2Tg3dCmNcuJBBzL1cPeEML28LMmJerY0ZXF7FdoBqoZni9JVDjaOcxNVYoj
	gugDj
X-Gm-Gg: ASbGncsTAuhO+K5nE96RTnHv7b/if8pjv63DGv257HpLXwAMo8O5wBmHaDKJ3t2GcVU
	6NDzo+6E/hpFd87hoG8dLnj9os52nRcXHdMLbDGZoWZrCwjxAG2P1DMUNrH3pEfCNmm94OyswM0
	5juwhLIXfgPr1l155LVJit7bIwW8cfe9GM+321LQUiU1Bxt6Lb68W7DWHM/dMc8jArpwAUTEPvO
	J8MynmW6KY9hNdpNN/GJvRaVkMNY/O4uZOJoUcPcIul+ojGzXnaXAG7rREzRslWYbqVsgLhBoWR
	4bG4l0Bb4pDsy2sWLDw0m6pIqIHnhg/XHps4ZujdyfRTVzLGoF4wi3aV6xUs/5zbWgETqx/EwD2
	A5D1+/iChvOIEcB09sgI=
X-Google-Smtp-Source: AGHT+IF3R+hS8MIAWD2a/8/cnz9/vji5b/bFgFiq/QwRydJc1PMVSUyRNAB6inv8G1M3Iz3XhHpqLg==
X-Received: by 2002:a17:902:d486:b0:224:1609:a74a with SMTP id d9443c01a7336-231de3ae59amr26808835ad.34.1747388800407;
        Fri, 16 May 2025 02:46:40 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v2 5/6] x86/hvm: limit memory type cache flush to running domains
Date: Fri, 16 May 2025 11:45:34 +0200
Message-ID: <20250516094535.63472-6-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250516094535.63472-1-roger.pau@citrix.com>
References: <20250516094535.63472-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Avoid the cache flush if the domain is not yet running.  There shouldn't be
any cached data resulting from domain accesses that need flushing, as the
domain hasn't run yet.

No change in domain observable behavior intended.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - New in this version.
---
 xen/arch/x86/hvm/mtrr.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 402a1d926337..8e1e15af8d73 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -783,7 +783,13 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr, NULL, hvm_load_mtrr_msr, 1,
 void memory_type_changed(struct domain *d)
 {
     if ( (is_iommu_enabled(d) || cache_flush_permitted(d)) &&
-         d->vcpu && d->vcpu[0] && p2m_memory_type_changed(d) )
+         d->vcpu && d->vcpu[0] && p2m_memory_type_changed(d) &&
+         /*
+          * Do the p2m type-change, but skip the cache flush if the domain is
+          * not yet running.  The check for creation_finished must strictly be
+          * done after the call to p2m_memory_type_changed().
+          */
+         d->creation_finished )
     {
         flush_all(FLUSH_CACHE);
     }
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 09:48:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:48:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986733.1372286 (Exim 4.92)
	(envelope-from )
	id 1uFrgS-0000Bs-Cr; Fri, 16 May 2025 09:48:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986733.1372286; Fri, 16 May 2025 09: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 1uFrgS-0000Bl-AL; Fri, 16 May 2025 09:48:52 +0000
Received: by outflank-mailman (input) for mailman id 986733;
 Fri, 16 May 2025 09:48:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFrgR-0000BY-Gp
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:48:51 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f8662931-323a-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 11:48:50 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad510c259b9so333827166b.1
 for ; Fri, 16 May 2025 02:48: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
 a640c23a62f3a-ad52d498544sm128200666b.143.2025.05.16.02.48.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 02:48: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" 
X-Inumbo-ID: f8662931-323a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747388930; x=1747993730; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=RIF5zmO/6Lv+zyNKBNr/m5cj94Xq3FU9LAsp43XNSlI=;
        b=KxUWru7VVMD/u5ShddgMlgPNXLUf91sDlUUf0u/bl+Ygdjkhd8vWMrmX2NogIf7fqu
         KkTbJqa8VNv3NSQVMJb25tMulxxUcORa1gpOmwbP6iTd8og5Z0KtN80dxXiqoLjQRAGD
         tDm7TDhwhUQDMZqVJ+NZ97twQwhYVG8PrVuCJDOdNg0ab7AtU2zE1lbfWQ2a/+wE8ctH
         zfBOMgmGMWkLirdPxgWtracbb4nb6JOG1GGmsuFSChgVk/8ZxEIQl10ZEy/NifeZw43N
         amiIm+SV/Et/bSm7/6Ct9NsJHdZwposf/J0GvJzl4ZwezmcKid6lRD9zDKwcD0Oqi+aC
         J7gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747388930; x=1747993730;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=RIF5zmO/6Lv+zyNKBNr/m5cj94Xq3FU9LAsp43XNSlI=;
        b=m3IxQh4B2W+jXqT6R1SjO65ZxmMlnJrREdCIqLWZTfrWbLX8jnCsEmDg3J+Ni1Q/gG
         tzTMrpnZNpzZfkMdeuZyafMsAx23GYpskT0uLEi2mzlXsTUKzecFEgufs1fwMAlugOPX
         lI9f/DCWXXcu+fNH8odZAJBYuApVcgvnAVzDBhpH2shV4N4N6vgMQA8NO4Y9V0QVscVh
         Bxq2WTlJjoyXedFUm3GD0+ET7u/f3JigtzL8jPvpOFpl++a55+3Cog3DFqy3u1q+H1/N
         QfjSQ4g+1tatJsb33IoO5Ls5Rxha/CRUDLj6YkRvcEqwdr0skzcM/ui4J9+27KJCi3WZ
         lOxA==
X-Forwarded-Encrypted: i=1; AJvYcCVqd+ZwbBw5YF7kOlih+sgOHq9JJaS7Y7sYVisH9q96bM/w//DmjGsEUn5dwBFAR3qB6fFcf/Sv/qY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YztXQg0/y9ySm04a2qeNp1pk73p/w+zY6WldQoUgytbFLrocu+E
	s6RY3cLKAAe9T4o8mEkFkVTyaA2oHhZ1vv9OQiBjPPiKGWip7h2rVy4Ey7/w2SBqMA==
X-Gm-Gg: ASbGncskE4zA2e01gYaGV2yiAwUfAh1Q5610bqjhG/3imkXflc+fRmyGr4SaK0bm6jN
	/Q1/pVY+tnlrslZ6iRB8KootAEjY/NURWbrJrE0m8dfYO7mTpS6Cpnk35rB9UYp1yibE65/P08q
	NZqj9GHRwHnDXX5COqhlQpNW+WKzl8b4JZc1vEUgHUx1SSekcID/ZwgFqyssJXq5UKgAzg1QdMS
	pydTIAoFEpY1v1TPpZ5kvG6ZfHohZQZi1phhcKy77SEwdohW6iGnesvd55VRb0oZpXzOe873tCR
	uYT6hd1ywHHxi/lMjCJKFoyOBoMeNnldCMrwjQqwP1QtABnGyU8K8btI3GLt6dVQrYL5CLGPHh2
	HfcApI8noWxHzrkqPUMa23VbgLiHQEoFWrr25
X-Google-Smtp-Source: AGHT+IES3eLQZohr7RxXZdbCm4IWzcs8c3/ANyi26ELE69C62z0NjD1AMTkHvBI/JxpL8HlpYVv+vw==
X-Received: by 2002:a17:907:a08a:b0:ad4:f91d:bfc2 with SMTP id a640c23a62f3a-ad52d43826emr259203766b.11.1747388929989;
        Fri, 16 May 2025 02:48:49 -0700 (PDT)
Message-ID: 
Date: Fri, 16 May 2025 11:48:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/6] x86/gnttab: do not implement GNTTABOP_cache_flush
To: Roger Pau Monne 
Cc: Oleksii Kurochko ,
 Community Manager ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-3-roger.pau@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: <20250516094535.63472-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 11:45, Roger Pau Monne wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -35,6 +35,11 @@ config GRANT_TABLE
>  
>  	  If unsure, say Y.
>  
> +config HAS_GRANT_CACHE_FLUSH
> +	bool
> +	depends on GRANT_TABLE
> +	default ARM

To keep arch stuff out of common file as much as possible, I think this instead
wants to be a "select ..." from ARM. Then:
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 09:51:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 09:51:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986757.1372298 (Exim 4.92)
	(envelope-from )
	id 1uFrjD-0001pE-QO; Fri, 16 May 2025 09:51:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986757.1372298; Fri, 16 May 2025 09: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 1uFrjD-0001p7-MQ; Fri, 16 May 2025 09:51:43 +0000
Received: by outflank-mailman (input) for mailman id 986757;
 Fri, 16 May 2025 09:51:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFreT-0005Zo-D4
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 09:46:49 +0000
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com
 [2607:f8b0:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aebc1dac-323a-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 11:46:47 +0200 (CEST)
Received: by mail-pl1-x629.google.com with SMTP id
 d9443c01a7336-22e6344326dso20365185ad.1
 for ; Fri, 16 May 2025 02:46:47 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-231d4eedb3csm10689175ad.259.2025.05.16.02.46.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 02:46: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" 
X-Inumbo-ID: aebc1dac-323a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747388806; x=1747993606; 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;
        bh=DvMZEBj9rqnpNlTgFCVn6ltQWL+ib5z0Tm+s9auszek=;
        b=GqkMALaUpYq+lBqDdqr01/btxozo4Tk4eUzM+cvPxnXHCWpxyw1RLU2lGkZNx3U0hJ
         8SVRgU7kfIPwA3qJW6SeO8TYMEzeQRVXZdJ4TyE6qEadstizVV7kUvyWwfJhmreiyIM7
         M8PnLm2aqoIpvANrwoeLBjC8GtYuXmNpsbJKo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747388806; x=1747993606;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=DvMZEBj9rqnpNlTgFCVn6ltQWL+ib5z0Tm+s9auszek=;
        b=KSGAoDKDjYMFN2LO7oIN8ZwPK6kbRiiZxcdomuLxJ8FOGKROFk/+F+rVBjzQ0YR5tK
         +qb13Gw1Tbbzq/RJFqHM0kRriFOxLBYIDdM+TMoUJOHxdB8aorN+ZGg+HqaonDv+5zEb
         6tqW9pUlHR09U8qkGUQKkTc2LY7ypfJp9C13H50vAsaOTfVn7xKEV9uftXmoJ4K6edQL
         kzc3uTKLRtW9s6W8fz6yQtBIYdoW6CwgNaj3qQk4PTwEIAV3dKTl9KuJ0e8PcKsBU5aI
         up9Zm+vdGd+EHd9DUuA+FXu6WsOexcLHT/quyJoxLoIEsflwFAVHeW9iWcDJhKZOPlbp
         pn+w==
X-Gm-Message-State: AOJu0YwUH0Ju5jdx7+RSd63/281A0ELvA6YEVtbYiR6aRhiGnoL0Zn//
	1DMoH2+TQHVZor3ERQjF3OmWfuVkVO6xad6sETt2ZdLLm9rWmCyISmS27RImmU8Msi8kOARgJOV
	nkwvf
X-Gm-Gg: ASbGncuvC0evqGjvhgAn3HbfgHqO2OD/13dens/SR3q2xlrLO51fu8HWoPDvGepTm6j
	vmVlqufJa674cSjc/dZ6kkwh2E7zBAd/XchWMrPHoJLrS80wTFHaXLJRz79EhrWqddYlCYVnAPN
	OgUvcLQsVCVXcw2x06JXLEOa7phlgQTrtosGYYoDoYTKuU0A0M09lHQf3yMsbOm0G75RrhHMqMl
	/sBMAbFGiUvOl/CoZHbAzWWJfeWUhFdFW7IslBKV7K9y+Qan6W1u2lhPWI3BpLGy35jI/OW0jV+
	WjIHwxtfQlZjXyhSgNPyHt7DHTkSy9fP/vN6hqlsAkp4BxeNTVimx2p3iHihmugrZSn8+nizkNS
	vsjJzEi9UfU9eUkvo470=
X-Google-Smtp-Source: AGHT+IEFrl2Rf1t+jyArCkyEkmT+bpC87gkIhjrCFFH5Zjqv0iaG8NmbviWDO/c1x6zWCrj80ybppA==
X-Received: by 2002:a17:902:c948:b0:220:e9f5:4b7c with SMTP id d9443c01a7336-231d44dc053mr29901695ad.17.1747388805836;
        Fri, 16 May 2025 02:46:45 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v2 6/6] x86/hvm: reduce the need to flush caches in memory_type_changed()
Date: Fri, 16 May 2025 11:45:35 +0200
Message-ID: <20250516094535.63472-7-roger.pau@citrix.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: <20250516094535.63472-1-roger.pau@citrix.com>
References: <20250516094535.63472-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current cache flushing done in memory_type_changed() is too wide, and
this doesn't scale on boxes with high number of CPUs.  Attempt to limit
cache flushes as a result of p2m type changes, and only do them if:

 * The CPU doesn't support (or has broken) self-snoop capability, otherwise
   there would be leftover aliases in the cache.  For guest initiated
   memory changes (like changes to MTRRs) the guest should already do a
   cache flush.
 * The IOMMU cannot force all DMA accesses to be snooping ones.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - New in this version.
---
Not sure whether this attempt to reduce cache flushing should get some
mention in the CHANGELOG.
---
 xen/arch/x86/hvm/mtrr.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 8e1e15af8d73..9a6f6865a05e 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -782,14 +782,21 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr, NULL, hvm_load_mtrr_msr, 1,
 
 void memory_type_changed(struct domain *d)
 {
-    if ( (is_iommu_enabled(d) || cache_flush_permitted(d)) &&
+    if ( cache_flush_permitted(d) &&
          d->vcpu && d->vcpu[0] && p2m_memory_type_changed(d) &&
          /*
           * Do the p2m type-change, but skip the cache flush if the domain is
           * not yet running.  The check for creation_finished must strictly be
           * done after the call to p2m_memory_type_changed().
           */
-         d->creation_finished )
+         d->creation_finished &&
+         /*
+          * The cache flush should be done if either: CPU doesn't have
+          * self-snoop in which case there could be aliases left in the cache,
+          * or IOMMUs cannot force all DMA device accesses to be snooped.
+          */
+         (!boot_cpu_has(X86_FEATURE_XEN_SELFSNOOP) ||
+          (is_iommu_enabled(d) && !iommu_snoop)) )
     {
         flush_all(FLUSH_CACHE);
     }
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 10:22:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:22:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986806.1372319 (Exim 4.92)
	(envelope-from )
	id 1uFsDD-0000QH-EZ; Fri, 16 May 2025 10:22:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986806.1372319; Fri, 16 May 2025 10: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 1uFsDD-0000QA-Be; Fri, 16 May 2025 10:22:43 +0000
Received: by outflank-mailman (input) for mailman id 986806;
 Fri, 16 May 2025 10:22:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsDB-0000Q4-Mg
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:22:42 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b16934bb-323f-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 12:22:39 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzNSG0vkDzMQxhqx
 for ; Fri, 16 May 2025 10:22:38 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 11ea96c549834e75beb56434593a40e2; Fri, 16 May 2025 10:22:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b16934bb-323f-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747390958; x=1747660958;
	bh=+whoNgFeV0mthcIxVXin+w5q5c78yv2JPXRHflVP3O4=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=DtptuGg/aRRLX8dpxHuFNwc2dtpevXwmsG0oyIWh5sAW61l9B2m5gXC7EHnOhLzem
	 dU7JtdCKc9DMfyLVBqoLI0ltzCltSeYO8xcs7X6l/kLkPKlBM4/cv3n1QaAygbkW0K
	 Un0+WaOatUUEdUs3a1B1xG4kdmgym3gaDqIGASBuYNfMvidQMvB7p9gVIhb1sxjpSg
	 vDvpvSr9xN+pbgwXUn9so8qj1h5k7dA8zWJcD2NJzaCcZjtFyprfoP7qThEuvi/Z10
	 Exnm2bwx3wQsY4z2HY3j1TAQ1hAxuVQca/9Dz7XZ3SU6aLyP56PA6z/Kgffl3Xl7Uj
	 XdfsCtJkOFIZQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747390958; x=1747651458; i=teddy.astie@vates.tech;
	bh=+whoNgFeV0mthcIxVXin+w5q5c78yv2JPXRHflVP3O4=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=Jh6vaneGII+HSnbkaqjnrJ43Xw1nVj3ko0F2rlFGvqoZjDAJ5Xmz9tHZYsBiOd2mI
	 z5D0QiMQg0ED0lP6UpY9hfZkn0JpDQfLOkroujDlnUQOv6zvKN23Eso/Uo8O4I9ybG
	 u0pw6xELoLYHaLByUFd7TagsoOGEYgAO/TwmZbZib8hNmg9STjv3IImTBhEwszVDAU
	 XiniWL0ym90y7fxHcw8UWxrAqhvpE5XUmJqo7yqU+tgqvc+n4DAKIcFZYyoIGEBQ5S
	 rATQsN9HikN+zRycK1wAtfBp2Y0twDAxwtvwmfwyCakY0Z/qtvmvnHE2N3hbfwiMVD
	 u2o/dUQsVGg4A==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2007/16]=20x86/hvm:=20Introduce=20Xen-wide=20ASID=20allocator?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747390956490
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" , "Tim Deegan" , "Vaishali Thakkar" 
Message-Id: <9cdb3e67abd01390bcc4cd103ca539d6bf7adbc0.1747312394.git.teddy.astie@vates.tech>
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.11ea96c549834e75beb56434593a40e2?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 10:22:38 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

From: Vaishali Thakkar 

Currently ASID generation and management is done per-PCPU. This
scheme is incompatible with SEV technologies as SEV VMs need to
have a fixed ASID associated with all vcpus of the VM throughout
it's lifetime.

This commit introduces a Xen-wide allocator which initializes
the asids at the start of xen and allows to have a fixed asids
throughout the lifecycle of all domains. Having a fixed asid
for non-SEV domains also presents us with the opportunity to
further take use of AMD instructions like TLBSYNC and INVLPGB
for broadcasting the TLB invalidations.

Introduce vcpu->needs_tlb_flush attribute to schedule a guest TLB
flush for the next VMRUN/VMENTER. This will be later be done using
either TLB_CONTROL field (AMD) or INVEPT (Intel). This flush method
is used in place of the current ASID swapping logic.

Signed-off-by: Teddy Astie 
Signed-off-by: Vaishali Thakkar 
---
TODO:
- Intel: Don't assign the VPID at each VMENTER, though we need
  to rethink how we manage VMCS with nested virtualization / altp2m
  for changing this behavior.
- AMD: Consider hot-plug of CPU with ERRATA_170. (is it possible ?)
- Consider cases where we don't have enough ASIDs (e.g Xen as nested guest)
- Nested virtualization ASID management

This patch currently breaks shadow paging, yet I haven't managed to diagnose
exactly what is happening.

Original changelog :
Changes since v3:
 - Simplified asid bitmap management
   It is only called once per domain, so it doesn't need to have
   a complicated logic.
 - Drop hvm_asid_data structure which doesn't serve a purpose anymore.
 - Introduce and use vcpu->needs_tlb_flush to indicate that a guest TLB
   flush is needed before waking the vcpu. It is used to set
   TLB_CONTROL (AMD) field properly or make a appropriate invept (Intel).
 - Only assign ASID once (see TODO for Intel side)
 - Check the ERRATA_170 for each CPU present.
 - add asid_alloc_range() for allocating within a specific
   range (e.g SEV ASID ranges)

Changes since v2:
 - Moved hvm_asid_domain_create to hvm_domain_initialise
 - Added __ro_after_init for bitmaps
 - Make hvm_asid_init  unsigned int __init
 - Remove functions hvm_asid_flush_domain_asid and hvm_asid_flush_vcpu
 - Mark ASID 0 permenantly
 - Remove the irrelevant tracking of generation
 - Add hvm_domain_asid_destroy to avoid layering violation
 - Remove unnecessary fixups touching the same code
 - Add a logic to move asids from reclaim_bitmap->asid_bitmap
 - Misc styling fixes - remove unncessary trailing spaces/printks

Changes since v1:
 - Introudce hvm_asid_bitmap as discussed at Xen-summit
 - Introduce hvm_reclaim_bitmap for reusing ASIDs
 - Assign the asid to the domain at the domain creation via
   hvm_asid_domain_create
 - Corrected the use of CPUID in the svm_asid_init function
 - Adjusted the code in nested virtualization related files
   to use new scheme. As discussed at the Xen-summit, this
   is not tested.
 - Addressed Jan's comments about using uniform style for
   accessing domains via v->domain
 - Allow to flush at the vcpu level in HAP code
 - Documented the sketch of implementation for the new scheme
 - Remove min_asid as for this patch, we are not demonstarting
   it's usecase
 - Arrange includes in multiple files as per Jan's feedback
---
 xen/arch/x86/flushtlb.c                |   7 +-
 xen/arch/x86/hvm/asid.c                | 170 +++++++++++--------------
 xen/arch/x86/hvm/emulate.c             |   2 +-
 xen/arch/x86/hvm/hvm.c                 |  14 +-
 xen/arch/x86/hvm/nestedhvm.c           |   7 +-
 xen/arch/x86/hvm/svm/asid.c            |  77 +++++++----
 xen/arch/x86/hvm/svm/nestedsvm.c       |   2 +-
 xen/arch/x86/hvm/svm/svm.c             |  37 +++---
 xen/arch/x86/hvm/svm/svm.h             |   4 -
 xen/arch/x86/hvm/vmx/vmcs.c            |   6 +-
 xen/arch/x86/hvm/vmx/vmx.c             |  68 +++++-----
 xen/arch/x86/hvm/vmx/vvmx.c            |   5 +-
 xen/arch/x86/include/asm/hvm/asid.h    |  26 ++--
 xen/arch/x86/include/asm/hvm/domain.h  |   1 +
 xen/arch/x86/include/asm/hvm/hvm.h     |  15 +--
 xen/arch/x86/include/asm/hvm/svm/svm.h |   5 +
 xen/arch/x86/include/asm/hvm/vcpu.h    |  10 +-
 xen/arch/x86/include/asm/hvm/vmx/vmx.h |   8 +-
 xen/arch/x86/mm/hap/hap.c              |   7 +-
 xen/arch/x86/mm/p2m.c                  |   7 +-
 xen/arch/x86/mm/paging.c               |   2 +-
 xen/arch/x86/mm/shadow/hvm.c           |   1 +
 xen/arch/x86/mm/shadow/multi.c         |   1 +
 xen/include/xen/sched.h                |   2 +
 24 files changed, 238 insertions(+), 246 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 1e0011d5b1..9cae828b34 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -124,7 +125,6 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
 
     if ( tlb_clk_enabled )
         t = pre_flush();
-    hvm_flush_guest_tlbs();
 
     old_cr4 = read_cr4();
     ASSERT(!(old_cr4 & X86_CR4_PCIDE) || !(old_cr4 & X86_CR4_PGE));
@@ -229,8 +229,9 @@ unsigned int flush_area_local(const void *va, unsigned int flags)
             do_tlb_flush();
     }
 
-    if ( flags & FLUSH_HVM_ASID_CORE )
-        hvm_flush_guest_tlbs();
+    //if ( flags & FLUSH_HVM_ASID_CORE )
+    //    // Needed ?
+    //    hvm_flush_tlb(NULL);
 
     if ( flags & FLUSH_CACHE )
     {
diff --git a/xen/arch/x86/hvm/asid.c b/xen/arch/x86/hvm/asid.c
index 8d27b7dba1..91f8e44210 100644
--- a/xen/arch/x86/hvm/asid.c
+++ b/xen/arch/x86/hvm/asid.c
@@ -8,133 +8,107 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
+
 #include 
+#include 
 
 /* Xen command-line option to enable ASIDs */
 static bool __read_mostly opt_asid_enabled = true;
 boolean_param("asid", opt_asid_enabled);
 
+bool __read_mostly asid_enabled = false;
+static unsigned long __ro_after_init *asid_bitmap;
+static unsigned long __ro_after_init asid_count;
+static DEFINE_SPINLOCK(asid_lock);
+
 /*
- * ASIDs partition the physical TLB.  In the current implementation ASIDs are
- * introduced to reduce the number of TLB flushes.  Each time the guest's
- * virtual address space changes (e.g. due to an INVLPG, MOV-TO-{CR3, CR4}
- * operation), instead of flushing the TLB, a new ASID is assigned.  This
- * reduces the number of TLB flushes to at most 1/#ASIDs.  The biggest
- * advantage is that hot parts of the hypervisor's code and data retain in
- * the TLB.
- *
  * Sketch of the Implementation:
- *
- * ASIDs are a CPU-local resource.  As preemption of ASIDs is not possible,
- * ASIDs are assigned in a round-robin scheme.  To minimize the overhead of
- * ASID invalidation, at the time of a TLB flush,  ASIDs are tagged with a
- * 64-bit generation.  Only on a generation overflow the code needs to
- * invalidate all ASID information stored at the VCPUs with are run on the
- * specific physical processor.  This overflow appears after about 2^80
- * host processor cycles, so we do not optimize this case, but simply disable
- * ASID useage to retain correctness.
+ * ASIDs are assigned uniquely per domain and doesn't change during
+ * the lifecycle of the domain. Once vcpus are initialized and are up,
+ * we assign the same ASID to all vcpus of that domain at the first VMRUN.
+ * In order to process a TLB flush on a vcpu, we set needs_tlb_flush
+ * to schedule a TLB flush for the next VMRUN (e.g using tlb control field
+ * of VMCB).
  */
 
-/* Per-CPU ASID management. */
-struct hvm_asid_data {
-   uint64_t core_asid_generation;
-   uint32_t next_asid;
-   uint32_t max_asid;
-   bool disabled;
-};
-
-static DEFINE_PER_CPU(struct hvm_asid_data, hvm_asid_data);
-
-void hvm_asid_init(int nasids)
+int __init hvm_asid_init(unsigned long nasids)
 {
-    static int8_t g_disabled = -1;
-    struct hvm_asid_data *data = &this_cpu(hvm_asid_data);
+    ASSERT(nasids);
 
-    data->max_asid = nasids - 1;
-    data->disabled = !opt_asid_enabled || (nasids <= 1);
-
-    if ( g_disabled != data->disabled )
-    {
-        printk("HVM: ASIDs %sabled.\n", data->disabled ? "dis" : "en");
-        if ( g_disabled < 0 )
-            g_disabled = data->disabled;
-    }
+    asid_count = nasids;
+    asid_enabled = opt_asid_enabled || (nasids <= 1);
 
-    /* Zero indicates 'invalid generation', so we start the count at one. */
-    data->core_asid_generation = 1;
+    asid_bitmap = xvzalloc_array(unsigned long, BITS_TO_LONGS(asid_count));
+    if ( !asid_bitmap )
+        return -ENOMEM;
 
-    /* Zero indicates 'ASIDs disabled', so we start the count at one. */
-    data->next_asid = 1;
-}
+    printk("HVM: ASIDs %sabled (count=%lu)\n", asid_enabled ? "en" : "dis", asid_count);
 
-void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid)
-{
-    write_atomic(&asid->generation, 0);
-}
+    /* ASID 0 is reserved, mark it as permanently used */
+    set_bit(0, asid_bitmap);
 
-void hvm_asid_flush_vcpu(struct vcpu *v)
-{
-    hvm_asid_flush_vcpu_asid(&v->arch.hvm.n1asid);
-    hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid);
+    return 0;
 }
 
-void hvm_asid_flush_core(void)
+int hvm_asid_alloc(struct hvm_asid *asid)
 {
-    struct hvm_asid_data *data = &this_cpu(hvm_asid_data);
+    unsigned long new_asid;
+    
+    if ( !asid_enabled )
+    {
+        asid->asid = 1;
+        return 0;
+    }
 
-    if ( data->disabled )
-        return;
+    spin_lock(&asid_lock);
+    new_asid = find_first_zero_bit(asid_bitmap, asid_count);
+    if ( new_asid > asid_count )
+        return -ENOSPC;
 
-    if ( likely(++data->core_asid_generation != 0) )
-        return;
+    set_bit(new_asid, asid_bitmap);
 
-    /*
-     * ASID generations are 64 bit.  Overflow of generations never happens.
-     * For safety, we simply disable ASIDs, so correctness is established; it
-     * only runs a bit slower.
-     */
-    printk("HVM: ASID generation overrun. Disabling ASIDs.\n");
-    data->disabled = 1;
+    asid->asid = new_asid;
+    spin_unlock(&asid_lock);
+    return 0;
 }
 
-bool hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid)
+int hvm_asid_alloc_range(struct hvm_asid *asid, unsigned long min, unsigned long max)
 {
-    struct hvm_asid_data *data = &this_cpu(hvm_asid_data);
-
-    /* On erratum #170 systems we must flush the TLB. 
-     * Generation overruns are taken here, too. */
-    if ( data->disabled )
-        goto disabled;
-
-    /* Test if VCPU has valid ASID. */
-    if ( read_atomic(&asid->generation) == data->core_asid_generation )
-        return 0;
+    unsigned long new_asid;
+    
+    if ( WARN_ON(min >= asid_count) )
+        return -EINVAL;
+    
+    if ( !asid_enabled )
+        return -EOPNOTSUPP;
+
+    spin_lock(&asid_lock);
+    new_asid = find_next_zero_bit(asid_bitmap, asid_count, min);
+    if ( new_asid > max || new_asid > asid_count )
+        return -ENOSPC;
+
+    set_bit(new_asid, asid_bitmap);
+
+    asid->asid = new_asid;
+    spin_unlock(&asid_lock);
+    return 0;
+}
 
-    /* If there are no free ASIDs, need to go to a new generation */
-    if ( unlikely(data->next_asid > data->max_asid) )
-    {
-        hvm_asid_flush_core();
-        data->next_asid = 1;
-        if ( data->disabled )
-            goto disabled;
-    }
+void hvm_asid_free(struct hvm_asid *asid)
+{
+    ASSERT( asid->asid );
 
-    /* Now guaranteed to be a free ASID. */
-    asid->asid = data->next_asid++;
-    write_atomic(&asid->generation, data->core_asid_generation);
+    if ( !asid_enabled )
+        return;
 
-    /*
-     * When we assign ASID 1, flush all TLB entries as we are starting a new
-     * generation, and all old ASID allocations are now stale. 
-     */
-    return (asid->asid == 1);
+    ASSERT( asid->asid < asid_count );
 
- disabled:
-    asid->asid = 0;
-    return 0;
+    spin_lock(&asid_lock);
+    WARN_ON(!test_bit(asid->asid, asid_bitmap));
+    clear_bit(asid->asid, asid_bitmap);
+    spin_unlock(&asid_lock);
 }
 
 /*
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 91f004d233..6ed8e03475 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2666,7 +2666,7 @@ static int cf_check hvmemul_tlb_op(
     case x86emul_invpcid:
         if ( x86emul_invpcid_type(aux) != X86_INVPCID_INDIV_ADDR )
         {
-            hvm_asid_flush_vcpu(current);
+            current->needs_tlb_flush = true;
             break;
         }
         aux = x86emul_invpcid_pcid(aux);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0e7c453b24..625ae2098b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -702,6 +702,10 @@ int hvm_domain_initialise(struct domain *d,
     if ( rc )
         goto fail2;
 
+    rc = hvm_asid_alloc(&d->arch.hvm.asid);
+    if ( rc )
+        goto fail2;
+
     rc = alternative_call(hvm_funcs.domain_initialise, d);
     if ( rc != 0 )
         goto fail2;
@@ -782,8 +786,9 @@ void hvm_domain_destroy(struct domain *d)
         list_del(&ioport->list);
         xfree(ioport);
     }
-
+    hvm_asid_free(&d->arch.hvm.asid);
     destroy_vpci_mmcfg(d);
+
 }
 
 static int cf_check hvm_save_tsc_adjust(struct vcpu *v, hvm_domain_context_t *h)
@@ -1603,7 +1608,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
     int rc;
     struct domain *d = v->domain;
 
-    hvm_asid_flush_vcpu(v);
+    v->needs_tlb_flush = true;
 
     spin_lock_init(&v->arch.hvm.tm_lock);
     INIT_LIST_HEAD(&v->arch.hvm.tm_list);
@@ -4145,6 +4150,11 @@ static void hvm_s3_resume(struct domain *d)
     }
 }
 
+int hvm_flush_tlb(const unsigned long *vcpu_bitmap)
+{
+    return current->domain->arch.paging.flush_tlb(vcpu_bitmap);
+}
+
 static int hvmop_flush_tlb_all(void)
 {
     if ( !is_hvm_domain(current->domain) )
diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
index bddd77d810..61e866b771 100644
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -12,6 +12,7 @@
 #include 
 #include   /* for local_event_delivery_(en|dis)able */
 #include  /* for paging_mode_hap() */
+#include 
 
 static unsigned long *shadow_io_bitmap[3];
 
@@ -36,13 +37,11 @@ nestedhvm_vcpu_reset(struct vcpu *v)
     hvm_unmap_guest_frame(nv->nv_vvmcx, 1);
     nv->nv_vvmcx = NULL;
     nv->nv_vvmcxaddr = INVALID_PADDR;
-    nv->nv_flushp2m = 0;
+    nv->nv_flushp2m = true;
     nv->nv_p2m = NULL;
     nv->stale_np2m = false;
     nv->np2m_generation = 0;
 
-    hvm_asid_flush_vcpu_asid(&nv->nv_n2asid);
-
     alternative_vcall(hvm_funcs.nhvm_vcpu_reset, v);
 
     /* vcpu is in host mode */
@@ -86,7 +85,7 @@ static void cf_check nestedhvm_flushtlb_ipi(void *info)
      * This is cheaper than flush_tlb_local() and has
      * the same desired effect.
      */
-    hvm_asid_flush_core();
+    WARN_ON(hvm_flush_tlb(NULL));
     vcpu_nestedhvm(v).nv_p2m = NULL;
     vcpu_nestedhvm(v).stale_np2m = true;
 }
diff --git a/xen/arch/x86/hvm/svm/asid.c b/xen/arch/x86/hvm/svm/asid.c
index 7977a8e86b..1b6def4a4c 100644
--- a/xen/arch/x86/hvm/svm/asid.c
+++ b/xen/arch/x86/hvm/svm/asid.c
@@ -1,56 +1,77 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 /*
- * asid.c: handling ASIDs in SVM.
+ * asid.c: handling ASIDs/VPIDs.
  * Copyright (c) 2007, Advanced Micro Devices, Inc.
  */
 
+#include 
+
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "svm.h"
 
-void svm_asid_init(const struct cpuinfo_x86 *c)
+void __init svm_asid_init(void)
 {
-    int nasids = 0;
+    unsigned int cpu;
+    int nasids = cpuid_ebx(0x8000000aU);
+
+    if ( !nasids )
+        nasids = 1;
 
-    /* Check for erratum #170, and leave ASIDs disabled if it's present. */
-    if ( !cpu_has_amd_erratum(c, AMD_ERRATUM_170) )
-        nasids = cpuid_ebx(0x8000000aU);
+    for_each_present_cpu(cpu)
+    {
+        /* Check for erratum #170, and leave ASIDs disabled if it's present. */
+        if ( cpu_has_amd_erratum(&cpu_data[cpu], AMD_ERRATUM_170) )
+        {
+            printk(XENLOG_WARNING "Disabling ASID due to errata 170 on CPU%u\n", cpu);
+            nasids = 1;
+        }
+    }
 
-    hvm_asid_init(nasids);
+    BUG_ON(hvm_asid_init(nasids));
 }
 
 /*
- * Called directly before VMRUN.  Checks if the VCPU needs a new ASID,
- * assigns it, and if required, issues required TLB flushes.
+ * Called directly at the first VMRUN/VMENTER of a vcpu to assign the ASID/VPID.
  */
-void svm_asid_handle_vmrun(void)
+void svm_vcpu_assign_asid(struct vcpu *v)
 {
-    struct vcpu *curr = current;
-    struct vmcb_struct *vmcb = curr->arch.hvm.svm.vmcb;
-    struct hvm_vcpu_asid *p_asid =
-        nestedhvm_vcpu_in_guestmode(curr)
-        ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid;
-    bool need_flush = hvm_asid_handle_vmenter(p_asid);
-
-    /* ASID 0 indicates that ASIDs are disabled. */
-    if ( p_asid->asid == 0 )
-    {
-        vmcb_set_asid(vmcb, true);
-        vmcb->tlb_control =
-            cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID : TLB_CTRL_FLUSH_ALL;
-        return;
-    }
+    struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
+    struct hvm_asid *p_asid = &v->domain->arch.hvm.asid;
+
+    ASSERT(p_asid->asid);
 
-    if ( vmcb_get_asid(vmcb) != p_asid->asid )
-        vmcb_set_asid(vmcb, p_asid->asid);
+    /* In case ASIDs are disabled, as ASID = 0 is reserved, guest can use 1 instead. */
+    vmcb_set_asid(vmcb, asid_enabled ? p_asid->asid : 1);
+}
+
+/* Call to make a TLB flush at the next VMRUN. */
+void svm_vcpu_set_tlb_control(struct vcpu *v)
+{
+    struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
+    
+    /*
+     * If the vcpu is already running, the tlb control flag may not be
+     * processed and will be cleared at the next VMEXIT, which will undo
+     * what we are trying to do.
+     */
+    WARN_ON(v != current && v->is_running);
 
     vmcb->tlb_control =
-        !need_flush ? TLB_CTRL_NO_FLUSH :
         cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID : TLB_CTRL_FLUSH_ALL;
 }
 
+void svm_vcpu_clear_tlb_control(struct vcpu *v)
+{
+    struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
+
+    vmcb->tlb_control = TLB_CTRL_NO_FLUSH;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index dc2b6a4253..6e5dc2624f 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -5,6 +5,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -699,7 +700,6 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs,
     if ( svm->ns_asid != vmcb_get_asid(ns_vmcb))
     {
         nv->nv_flushp2m = 1;
-        hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid);
         svm->ns_asid = vmcb_get_asid(ns_vmcb);
     }
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index e33a38c1e4..cc19d80fe1 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -183,14 +184,17 @@ static void cf_check svm_update_guest_cr(
         if ( !nestedhvm_enabled(v->domain) )
         {
             if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) )
-                hvm_asid_flush_vcpu(v);
+                v->needs_tlb_flush = true;
         }
         else if ( nestedhvm_vmswitch_in_progress(v) )
             ; /* CR3 switches during VMRUN/VMEXIT do not flush the TLB. */
         else if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) )
-            hvm_asid_flush_vcpu_asid(
-                nestedhvm_vcpu_in_guestmode(v)
-                ? &vcpu_nestedhvm(v).nv_n2asid : &v->arch.hvm.n1asid);
+        {
+            if (nestedhvm_vcpu_in_guestmode(v))
+                vcpu_nestedhvm(v).nv_flushp2m = true;
+            else
+                v->needs_tlb_flush = true;
+        }
         break;
     case 4:
         value = HVM_CR4_HOST_MASK;
@@ -991,8 +995,7 @@ static void noreturn cf_check svm_do_resume(void)
         v->arch.hvm.svm.launch_core = smp_processor_id();
         hvm_migrate_timers(v);
         hvm_migrate_pirqs(v);
-        /* Migrating to another ASID domain.  Request a new ASID. */
-        hvm_asid_flush_vcpu(v);
+        v->needs_tlb_flush = true;
     }
 
     if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) )
@@ -1019,13 +1022,14 @@ void asmlinkage svm_vmenter_helper(void)
 
     ASSERT(hvmemul_cache_disabled(curr));
 
-    svm_asid_handle_vmrun();
-
     TRACE_TIME(TRC_HVM_VMENTRY |
                (nestedhvm_vcpu_in_guestmode(curr) ? TRC_HVM_NESTEDFLAG : 0));
 
     svm_sync_vmcb(curr, vmcb_needs_vmsave);
 
+    if ( test_and_clear_bool(curr->needs_tlb_flush) )
+        svm_vcpu_set_tlb_control(curr);
+
     vmcb->rax = regs->rax;
     vmcb->rip = regs->rip;
     vmcb->rsp = regs->rsp;
@@ -1146,6 +1150,8 @@ static int cf_check svm_vcpu_initialise(struct vcpu *v)
         return rc;
     }
 
+    svm_vcpu_assign_asid(v);
+
     return 0;
 }
 
@@ -1572,9 +1578,6 @@ static int _svm_cpu_up(bool bsp)
     /* check for erratum 383 */
     svm_init_erratum_383(c);
 
-    /* Initialize core's ASID handling. */
-    svm_asid_init(c);
-
     /* Initialize OSVW bits to be used by guests */
     svm_host_osvw_init();
 
@@ -2338,7 +2341,7 @@ static void svm_invlpga_intercept(
 {
     svm_invlpga(linear,
                 (asid == 0)
-                ? v->arch.hvm.n1asid.asid
+                ? v->domain->arch.hvm.asid.asid
                 : vcpu_nestedhvm(v).nv_n2asid.asid);
 }
 
@@ -2360,8 +2363,8 @@ static bool cf_check is_invlpg(
 
 static void cf_check svm_invlpg(struct vcpu *v, unsigned long linear)
 {
-    /* Safe fallback. Take a new ASID. */
-    hvm_asid_flush_vcpu(v);
+    /* Schedule a tlb flush on the VCPU. */
+    v->needs_tlb_flush = true;
 }
 
 static bool cf_check svm_get_pending_event(
@@ -2528,6 +2531,8 @@ const struct hvm_function_table * __init start_svm(void)
     svm_function_table.caps.hap_superpage_2mb = true;
     svm_function_table.caps.hap_superpage_1gb = cpu_has_page1gb;
 
+    svm_asid_init();
+
     return &svm_function_table;
 }
 
@@ -2584,6 +2589,8 @@ void asmlinkage svm_vmexit_handler(void)
                    (vlapic_get_reg(vlapic, APIC_TASKPRI) & 0x0F));
     }
 
+    svm_vcpu_clear_tlb_control(v);
+
     exit_reason = vmcb->exitcode;
 
     if ( hvm_long_mode_active(v) )
@@ -2659,7 +2666,7 @@ void asmlinkage svm_vmexit_handler(void)
         }
     }
 
-    if ( unlikely(exit_reason == VMEXIT_INVALID) )
+    if ( unlikely(exit_reason == VMEXIT_INVALID || exit_reason == (uint32_t)VMEXIT_INVALID) )
     {
         gdprintk(XENLOG_ERR, "invalid VMCB state:\n");
         svm_vmcb_dump(__func__, vmcb);
diff --git a/xen/arch/x86/hvm/svm/svm.h b/xen/arch/x86/hvm/svm/svm.h
index f5b0312d2d..92145c6d7b 100644
--- a/xen/arch/x86/hvm/svm/svm.h
+++ b/xen/arch/x86/hvm/svm/svm.h
@@ -12,12 +12,8 @@
 #include 
 
 struct cpu_user_regs;
-struct cpuinfo_x86;
 struct vcpu;
 
-void svm_asid_init(const struct cpuinfo_x86 *c);
-void svm_asid_handle_vmrun(void);
-
 unsigned long *svm_msrbit(unsigned long *msr_bitmap, uint32_t msr);
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len);
 
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index a44475ae15..b8a28e2cf8 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -759,8 +760,6 @@ static int _vmx_cpu_up(bool bsp)
 
     this_cpu(vmxon) = 1;
 
-    hvm_asid_init(cpu_has_vmx_vpid ? (1u << VMCS_VPID_WIDTH) : 0);
-
     if ( cpu_has_vmx_ept )
         ept_sync_all();
 
@@ -1941,7 +1940,7 @@ void cf_check vmx_do_resume(void)
          */
         v->arch.hvm.vmx.hostenv_migrated = 1;
 
-        hvm_asid_flush_vcpu(v);
+        v->needs_tlb_flush = true;
     }
 
     debug_state = v->domain->debugger_attached
@@ -2154,7 +2153,6 @@ void vmcs_dump_vcpu(struct vcpu *v)
          (SECONDARY_EXEC_ENABLE_VPID | SECONDARY_EXEC_ENABLE_VM_FUNCTIONS) )
         printk("Virtual processor ID = 0x%04x VMfunc controls = %016lx\n",
                vmr16(VIRTUAL_PROCESSOR_ID), vmr(VM_FUNCTION_CONTROL));
-
     vmx_vmcs_exit(v);
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 827db6bdd8..8859ec4b38 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -824,6 +825,18 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v)
         vmx_update_secondary_exec_control(v);
     }
 
+    if ( asid_enabled )
+    {
+        v->arch.hvm.vmx.secondary_exec_control |= SECONDARY_EXEC_ENABLE_VPID;
+        vmx_update_secondary_exec_control(v);
+    }
+    else
+    {
+        v->arch.hvm.vmx.secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_VPID;
+        vmx_update_secondary_exec_control(v);
+    }
+
+
     /*
      * We can safely pass MSR_SPEC_CTRL through to the guest, even if STIBP
      * isn't enumerated in hardware, as SPEC_CTRL_STIBP is ignored.
@@ -1477,7 +1490,7 @@ static void cf_check vmx_handle_cd(struct vcpu *v, unsigned long value)
             vmx_set_msr_intercept(v, MSR_IA32_CR_PAT, VMX_MSR_RW);
 
             wbinvd();               /* flush possibly polluted cache */
-            hvm_asid_flush_vcpu(v); /* invalidate memory type cached in TLB */
+            v->needs_tlb_flush = true; /* invalidate memory type cached in TLB */
             v->arch.hvm.cache_mode = NO_FILL_CACHE_MODE;
         }
         else
@@ -1486,7 +1499,7 @@ static void cf_check vmx_handle_cd(struct vcpu *v, unsigned long value)
             vmx_set_guest_pat(v, *pat);
             if ( !is_iommu_enabled(v->domain) || iommu_snoop )
                 vmx_clear_msr_intercept(v, MSR_IA32_CR_PAT, VMX_MSR_RW);
-            hvm_asid_flush_vcpu(v); /* no need to flush cache */
+            v->needs_tlb_flush = true;
         }
     }
 }
@@ -1847,7 +1860,7 @@ static void cf_check vmx_update_guest_cr(
         __vmwrite(GUEST_CR3, v->arch.hvm.hw_cr[3]);
 
         if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) )
-            hvm_asid_flush_vcpu(v);
+            v->needs_tlb_flush = true;
         break;
 
     default:
@@ -3128,6 +3141,8 @@ const struct hvm_function_table * __init start_vmx(void)
     lbr_tsx_fixup_check();
     ler_to_fixup_check();
 
+    BUG_ON(hvm_asid_init(cpu_has_vmx_vpid ? (1u << VMCS_VPID_WIDTH) : 1));
+
     return &vmx_function_table;
 }
 
@@ -4901,9 +4916,7 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs)
 {
     struct vcpu *curr = current;
     struct domain *currd = curr->domain;
-    u32 new_asid, old_asid;
-    struct hvm_vcpu_asid *p_asid;
-    bool need_flush;
+    struct hvm_asid *p_asid;
 
     ASSERT(hvmemul_cache_disabled(curr));
 
@@ -4914,38 +4927,14 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs)
     if ( curr->domain->arch.hvm.pi_ops.vcpu_block )
         vmx_pi_do_resume(curr);
 
-    if ( !cpu_has_vmx_vpid )
+    if ( !asid_enabled )
         goto out;
     if ( nestedhvm_vcpu_in_guestmode(curr) )
         p_asid = &vcpu_nestedhvm(curr).nv_n2asid;
     else
-        p_asid = &curr->arch.hvm.n1asid;
-
-    old_asid = p_asid->asid;
-    need_flush = hvm_asid_handle_vmenter(p_asid);
-    new_asid = p_asid->asid;
-
-    if ( unlikely(new_asid != old_asid) )
-    {
-        __vmwrite(VIRTUAL_PROCESSOR_ID, new_asid);
-        if ( !old_asid && new_asid )
-        {
-            /* VPID was disabled: now enabled. */
-            curr->arch.hvm.vmx.secondary_exec_control |=
-                SECONDARY_EXEC_ENABLE_VPID;
-            vmx_update_secondary_exec_control(curr);
-        }
-        else if ( old_asid && !new_asid )
-        {
-            /* VPID was enabled: now disabled. */
-            curr->arch.hvm.vmx.secondary_exec_control &=
-                ~SECONDARY_EXEC_ENABLE_VPID;
-            vmx_update_secondary_exec_control(curr);
-        }
-    }
+        p_asid = &currd->arch.hvm.asid;
 
-    if ( unlikely(need_flush) )
-        vpid_sync_all();
+    __vmwrite(VIRTUAL_PROCESSOR_ID, p_asid->asid);
 
     if ( paging_mode_hap(curr->domain) )
     {
@@ -4954,12 +4943,18 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs)
         unsigned int inv = 0; /* None => Single => All */
         struct ept_data *single = NULL; /* Single eptp, iff inv == 1 */
 
+        if ( test_and_clear_bool(curr->needs_tlb_flush)  )
+        {
+            inv = 1;
+            single = ept;
+        }
+
         if ( cpumask_test_cpu(cpu, ept->invalidate) )
         {
             cpumask_clear_cpu(cpu, ept->invalidate);
 
             /* Automatically invalidate all contexts if nested. */
-            inv += 1 + nestedhvm_enabled(currd);
+            inv = 1 + nestedhvm_enabled(currd);
             single = ept;
         }
 
@@ -4986,6 +4981,11 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs)
             __invept(inv == 1 ? INVEPT_SINGLE_CONTEXT : INVEPT_ALL_CONTEXT,
                      inv == 1 ? single->eptp          : 0);
     }
+    else /* Shadow paging */
+    {
+        if ( test_and_clear_bool(curr->needs_tlb_flush) )
+            vpid_sync_vcpu_context(curr);
+    }
 
  out:
     if ( unlikely(curr->arch.hvm.vmx.lbr_flags & LBR_FIXUP_MASK) )
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index ceb5e5a322..fa84ee4e8f 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1254,7 +1255,7 @@ static void virtual_vmentry(struct cpu_user_regs *regs)
 
         if ( nvmx->guest_vpid != new_vpid )
         {
-            hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid);
+            v->needs_tlb_flush = true;
             nvmx->guest_vpid = new_vpid;
         }
     }
@@ -2055,7 +2056,7 @@ static int nvmx_handle_invvpid(struct cpu_user_regs *regs)
     case INVVPID_INDIVIDUAL_ADDR:
     case INVVPID_SINGLE_CONTEXT:
     case INVVPID_ALL_CONTEXT:
-        hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(current).nv_n2asid);
+        hvm_flush_tlb(NULL);
         break;
     default:
         vmfail(regs, VMX_INSN_INVEPT_INVVPID_INVALID_OP);
diff --git a/xen/arch/x86/include/asm/hvm/asid.h b/xen/arch/x86/include/asm/hvm/asid.h
index 17c58353d1..13ea357f70 100644
--- a/xen/arch/x86/include/asm/hvm/asid.h
+++ b/xen/arch/x86/include/asm/hvm/asid.h
@@ -8,25 +8,21 @@
 #ifndef __ASM_X86_HVM_ASID_H__
 #define __ASM_X86_HVM_ASID_H__
 
+#include 
+#include 
 
-struct vcpu;
-struct hvm_vcpu_asid;
+struct hvm_asid {
+  uint32_t asid;
+};
 
-/* Initialise ASID management for the current physical CPU. */
-void hvm_asid_init(int nasids);
+extern bool asid_enabled;
 
-/* Invalidate a particular ASID allocation: forces re-allocation. */
-void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid);
+/* Initialise ASID management distributed across all CPUs. */
+int hvm_asid_init(unsigned long nasids);
 
-/* Invalidate all ASID allocations for specified VCPU: forces re-allocation. */
-void hvm_asid_flush_vcpu(struct vcpu *v);
-
-/* Flush all ASIDs on this processor core. */
-void hvm_asid_flush_core(void);
-
-/* Called before entry to guest context. Checks ASID allocation, returns a
- * boolean indicating whether all ASIDs must be flushed. */
-bool hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid);
+int hvm_asid_alloc(struct hvm_asid *asid);
+int hvm_asid_alloc_range(struct hvm_asid *asid, unsigned long min, unsigned long max);
+void hvm_asid_free(struct hvm_asid *asid);
 
 #endif /* __ASM_X86_HVM_ASID_H__ */
 
diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/asm/hvm/domain.h
index 2608bcfad2..5fb37d342b 100644
--- a/xen/arch/x86/include/asm/hvm/domain.h
+++ b/xen/arch/x86/include/asm/hvm/domain.h
@@ -141,6 +141,7 @@ struct hvm_domain {
     } write_map;
 
     struct hvm_pi_ops pi_ops;
+    struct hvm_asid asid;
 
     union {
         struct vmx_domain vmx;
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
index bf8bc2e100..7af111cb39 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -268,6 +268,8 @@ int hvm_domain_initialise(struct domain *d,
 void hvm_domain_relinquish_resources(struct domain *d);
 void hvm_domain_destroy(struct domain *d);
 
+int hvm_flush_tlb(const unsigned long *vcpu_bitmap);
+
 int hvm_vcpu_initialise(struct vcpu *v);
 void hvm_vcpu_destroy(struct vcpu *v);
 void hvm_vcpu_down(struct vcpu *v);
@@ -483,17 +485,6 @@ static inline void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset,
     alternative_vcall(hvm_funcs.set_tsc_offset, v, offset, at_tsc);
 }
 
-/*
- * Called to ensure than all guest-specific mappings in a tagged TLB are 
- * flushed; does *not* flush Xen's TLB entries, and on processors without a 
- * tagged TLB it will be a noop.
- */
-static inline void hvm_flush_guest_tlbs(void)
-{
-    if ( hvm_enabled )
-        hvm_asid_flush_core();
-}
-
 static inline unsigned int
 hvm_get_cpl(struct vcpu *v)
 {
@@ -881,8 +872,6 @@ static inline int hvm_cpu_up(void)
 
 static inline void hvm_cpu_down(void) {}
 
-static inline void hvm_flush_guest_tlbs(void) {}
-
 static inline void hvm_invlpg(const struct vcpu *v, unsigned long linear)
 {
     ASSERT_UNREACHABLE();
diff --git a/xen/arch/x86/include/asm/hvm/svm/svm.h b/xen/arch/x86/include/asm/hvm/svm/svm.h
index 32f6e48e30..1254e5f3ee 100644
--- a/xen/arch/x86/include/asm/hvm/svm/svm.h
+++ b/xen/arch/x86/include/asm/hvm/svm/svm.h
@@ -9,6 +9,11 @@
 #ifndef __ASM_X86_HVM_SVM_H__
 #define __ASM_X86_HVM_SVM_H__
 
+void svm_asid_init(void);
+void svm_vcpu_assign_asid(struct vcpu *v);
+void svm_vcpu_set_tlb_control(struct vcpu *v);
+void svm_vcpu_clear_tlb_control(struct vcpu *v);
+
 /*
  * PV context switch helpers.  Prefetching the VMCB area itself has been shown
  * to be useful for performance.
diff --git a/xen/arch/x86/include/asm/hvm/vcpu.h b/xen/arch/x86/include/asm/hvm/vcpu.h
index 196fed6d5d..960bea6734 100644
--- a/xen/arch/x86/include/asm/hvm/vcpu.h
+++ b/xen/arch/x86/include/asm/hvm/vcpu.h
@@ -9,6 +9,7 @@
 #define __ASM_X86_HVM_VCPU_H__
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -17,11 +18,6 @@
 #include 
 #include 
 
-struct hvm_vcpu_asid {
-    uint64_t generation;
-    uint32_t asid;
-};
-
 struct hvm_vcpu_io {
     /*
      * HVM emulation:
@@ -79,7 +75,7 @@ struct nestedvcpu {
     bool stale_np2m; /* True when p2m_base in VMCx02 is no longer valid */
     uint64_t np2m_generation;
 
-    struct hvm_vcpu_asid nv_n2asid;
+    struct hvm_asid nv_n2asid;
 
     bool nv_vmentry_pending;
     bool nv_vmexit_pending;
@@ -141,8 +137,6 @@ struct hvm_vcpu {
     /* (MFN) hypervisor page table */
     pagetable_t         monitor_table;
 
-    struct hvm_vcpu_asid n1asid;
-
     u64                 msr_tsc_adjust;
 
     union {
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index a55a31b42d..cae3613a61 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -462,14 +462,10 @@ static inline void vpid_sync_vcpu_context(struct vcpu *v)
     if ( likely(cpu_has_vmx_vpid_invvpid_single_context) )
         goto execute_invvpid;
 
-    /*
-     * If single context invalidation is not supported, we escalate to
-     * use all context invalidation.
-     */
     type = INVVPID_ALL_CONTEXT;
 
 execute_invvpid:
-    __invvpid(type, v->arch.hvm.n1asid.asid, (u64)gva);
+    __invvpid(type, v->domain->arch.hvm.asid.asid, 0);
 }
 
 static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva)
@@ -493,7 +489,7 @@ static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva)
         type = INVVPID_ALL_CONTEXT;
 
 execute_invvpid:
-    __invvpid(type, v->arch.hvm.n1asid.asid, (u64)gva);
+    __invvpid(type, v->domain->arch.hvm.asid.asid, (u64)gva);
 }
 
 static inline void vpid_sync_all(void)
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index ec5043a8aa..cf7ca1702a 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -739,7 +740,7 @@ static bool cf_check flush_tlb(const unsigned long *vcpu_bitmap)
         if ( !flush_vcpu(v, vcpu_bitmap) )
             continue;
 
-        hvm_asid_flush_vcpu(v);
+        v->needs_tlb_flush = true;
 
         cpu = read_atomic(&v->dirty_cpu);
         if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) && v->is_running )
@@ -748,9 +749,7 @@ static bool cf_check flush_tlb(const unsigned long *vcpu_bitmap)
 
     /*
      * Trigger a vmexit on all pCPUs with dirty vCPU state in order to force an
-     * ASID/VPID change and hence accomplish a guest TLB flush. Note that vCPUs
-     * not currently running will already be flushed when scheduled because of
-     * the ASID tickle done in the loop above.
+     * ASID/VPID flush and hence accomplish a guest TLB flush.
      */
     on_selected_cpus(mask, NULL, NULL, 0);
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 3a39b5d124..04b41cee12 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1405,7 +1406,7 @@ p2m_flush(struct vcpu *v, struct p2m_domain *p2m)
     ASSERT(v->domain == p2m->domain);
     vcpu_nestedhvm(v).nv_p2m = NULL;
     p2m_flush_table(p2m);
-    hvm_asid_flush_vcpu(v);
+    v->needs_tlb_flush = true;
 }
 
 void
@@ -1464,7 +1465,7 @@ static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m)
 
 static void nvcpu_flush(struct vcpu *v)
 {
-    hvm_asid_flush_vcpu(v);
+    v->needs_tlb_flush = true;
     vcpu_nestedhvm(v).stale_np2m = true;
 }
 
@@ -1584,7 +1585,7 @@ void np2m_schedule(int dir)
             if ( !np2m_valid )
             {
                 /* This vCPU's np2m was flushed while it was not runnable */
-                hvm_asid_flush_core();
+                curr->needs_tlb_flush = true; /* TODO: Is it ok ? */
                 vcpu_nestedhvm(curr).nv_p2m = NULL;
             }
             else
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index c77f4c1dac..26b6ce9e9b 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -964,7 +964,7 @@ void paging_update_nestedmode(struct vcpu *v)
     else
         /* TODO: shadow-on-shadow */
         v->arch.paging.nestedmode = NULL;
-    hvm_asid_flush_vcpu(v);
+    v->needs_tlb_flush = true;
 }
 
 int __init paging_set_allocation(struct domain *d, unsigned int pages,
diff --git a/xen/arch/x86/mm/shadow/hvm.c b/xen/arch/x86/mm/shadow/hvm.c
index 114957a3e1..f98591f976 100644
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -737,6 +737,7 @@ bool cf_check shadow_flush_tlb(const unsigned long *vcpu_bitmap)
             continue;
 
         paging_update_cr3(v, false);
+        v->needs_tlb_flush = true;
 
         cpu = read_atomic(&v->dirty_cpu);
         if ( is_vcpu_dirty_cpu(cpu) )
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 7be9c180ec..0e2865286e 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3144,6 +3144,7 @@ sh_update_linear_entries(struct vcpu *v)
      * without this change, it would fetch the wrong value due to a stale TLB.
      */
     sh_flush_local(d);
+    v->needs_tlb_flush = true;
 }
 
 static pagetable_t cf_check sh_update_cr3(struct vcpu *v, bool noflush)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 4ce9253284..f2f5a98534 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -228,6 +228,8 @@ struct vcpu
     bool             defer_shutdown;
     /* VCPU is paused following shutdown request (d->is_shutting_down)? */
     bool             paused_for_shutdown;
+    /* VCPU needs its TLB flushed before waking. */
+    bool             needs_tlb_flush;
     /* VCPU need affinity restored */
     uint8_t          affinity_broken;
 #define VCPU_AFFINITY_OVERRIDE    0x01
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 10:23:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:23:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986808.1372329 (Exim 4.92)
	(envelope-from )
	id 1uFsDW-0000lF-Py; Fri, 16 May 2025 10:23:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986808.1372329; Fri, 16 May 2025 10: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 1uFsDW-0000l6-MG; Fri, 16 May 2025 10:23:02 +0000
Received: by outflank-mailman (input) for mailman id 986808;
 Fri, 16 May 2025 10:23:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsDV-0000kS-CD
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:23:01 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bcbf4d37-323f-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:22:58 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzNSd5Df4zMQxhRj
 for ; Fri, 16 May 2025 10:22:57 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 ca09d91c625d4298b8887bc6fbe1b5db; Fri, 16 May 2025 10:22: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" 
X-Inumbo-ID: bcbf4d37-323f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747390977; x=1747660977;
	bh=RsBZjCl+lvc8p7k8336ELrjqMIlkVDeJAPRHMTKknmM=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=hzUTaRi/+MoTTZ1KvIvZlVXOaGSRbmCxJkdU+BG6p8T/aWY/fNm3gJ78U7JnvD8zO
	 /qrUgq7Lmv/t1+pnuWyR5zxnSB3Mf5puePF3tQtdXqN17VXBng2z1etSMBwEAWA4A8
	 jWXjatfmO2N6PSo+YCXnHBAPcNejPd/b+SY78j6+ZG9LR65WLMO63jeAkED9maFdM1
	 PpyINZqWj2+TNL2wfJUe4jujoAAbEUcQRiLMWHFqrxn73MVdtK4oZTuz6SC/b9c9qD
	 rOsQexF053Fe6SKFfnj9F1O40PdRNVY5BuV0pQGg/VEHRb71xznZmVUmqIA43Pwx/M
	 lrW6/VCY6K6uw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747390977; x=1747651477; i=teddy.astie@vates.tech;
	bh=RsBZjCl+lvc8p7k8336ELrjqMIlkVDeJAPRHMTKknmM=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=VZGziPl1zxNWXRmuzr9ZEELghjqBni/cLFE4/zbJrJETqdDwrZuT0ZidbljKoDWhX
	 y95J9zdFhvKtDO+hYK7APvO5ewViXL5UdOPvbNsWY/KqNFeJPZ/c+MxJs3lrsWmAD0
	 gPlfMQZgQ4XbzM1FiSTx+akEoCchDv2uM8u2+hialOcZgNioCrzttdtQm2fORCaGSi
	 jlVYjOgPnl2+afm7SeJw7tt0GFYSZC5cY3hHCj9WRMeJxpGMBbq6CmqAVbcZ/BRbsz
	 5CtBSNCY6pojxQlnxmsZCzFgzWqvBwoH1FuutZ3pNlPl8tqHb+WSltx/pEeq59LpH3
	 v8/Q7ERZNBXRw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2008/16]=20x86/crypto:=20Introduce=20AMD=20PSP=20driver=20for=20SEV?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747390975438
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" , "Andrei Semenov" 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.ca09d91c625d4298b8887bc6fbe1b5db?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 10:22:57 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

From: Andrei Semenov 

Introduce a basic PSP driver with focus on SEV commands.

Signed-off-by: Andrei Semenov 
Signed-off-by: Teddy Astie 
---
 xen/arch/x86/include/asm/psp-sev.h | 655 +++++++++++++++++++++++
 xen/drivers/Kconfig                |   2 +
 xen/drivers/Makefile               |   1 +
 xen/drivers/crypto/Kconfig         |  10 +
 xen/drivers/crypto/Makefile        |   1 +
 xen/drivers/crypto/asp.c           | 830 +++++++++++++++++++++++++++++
 6 files changed, 1499 insertions(+)
 create mode 100644 xen/arch/x86/include/asm/psp-sev.h
 create mode 100644 xen/drivers/crypto/Kconfig
 create mode 100644 xen/drivers/crypto/Makefile
 create mode 100644 xen/drivers/crypto/asp.c

diff --git a/xen/arch/x86/include/asm/psp-sev.h b/xen/arch/x86/include/asm/psp-sev.h
new file mode 100644
index 0000000000..5bbe1ed2c0
--- /dev/null
+++ b/xen/arch/x86/include/asm/psp-sev.h
@@ -0,0 +1,655 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * AMD Secure Encrypted Virtualization (SEV) driver interface
+ *
+ * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Brijesh Singh 
+ *
+ * SEV API spec is available at https://developer.amd.com/sev
+ */
+
+#ifndef __PSP_SEV_H__
+#define __PSP_SEV_H__
+
+#include 
+
+/**
+ * SEV platform and guest management commands
+ */
+enum sev_cmd {
+    /* platform commands */
+    SEV_CMD_INIT      = 0x001,
+    SEV_CMD_SHUTDOWN    = 0x002,
+    SEV_CMD_FACTORY_RESET    = 0x003,
+    SEV_CMD_PLATFORM_STATUS    = 0x004,
+    SEV_CMD_PEK_GEN      = 0x005,
+    SEV_CMD_PEK_CSR      = 0x006,
+    SEV_CMD_PEK_CERT_IMPORT    = 0x007,
+    SEV_CMD_PDH_CERT_EXPORT    = 0x008,
+    SEV_CMD_PDH_GEN      = 0x009,
+    SEV_CMD_DF_FLUSH    = 0x00A,
+    SEV_CMD_DOWNLOAD_FIRMWARE  = 0x00B,
+    SEV_CMD_GET_ID      = 0x00C,
+    SEV_CMD_INIT_EX                 = 0x00D,
+
+    /* Guest commands */
+    SEV_CMD_DECOMMISSION    = 0x020,
+    SEV_CMD_ACTIVATE    = 0x021,
+    SEV_CMD_DEACTIVATE    = 0x022,
+    SEV_CMD_GUEST_STATUS    = 0x023,
+
+    /* Guest launch commands */
+    SEV_CMD_LAUNCH_START    = 0x030,
+    SEV_CMD_LAUNCH_UPDATE_DATA  = 0x031,
+    SEV_CMD_LAUNCH_UPDATE_VMSA  = 0x032,
+    SEV_CMD_LAUNCH_MEASURE    = 0x033,
+    SEV_CMD_LAUNCH_UPDATE_SECRET  = 0x034,
+    SEV_CMD_LAUNCH_FINISH    = 0x035,
+    SEV_CMD_ATTESTATION_REPORT  = 0x036,
+
+    /* Guest migration commands (outgoing) */
+    SEV_CMD_SEND_START    = 0x040,
+    SEV_CMD_SEND_UPDATE_DATA  = 0x041,
+    SEV_CMD_SEND_UPDATE_VMSA  = 0x042,
+    SEV_CMD_SEND_FINISH    = 0x043,
+    SEV_CMD_SEND_CANCEL    = 0x044,
+
+    /* Guest migration commands (incoming) */
+    SEV_CMD_RECEIVE_START    = 0x050,
+    SEV_CMD_RECEIVE_UPDATE_DATA  = 0x051,
+    SEV_CMD_RECEIVE_UPDATE_VMSA  = 0x052,
+    SEV_CMD_RECEIVE_FINISH    = 0x053,
+
+    /* Guest debug commands */
+    SEV_CMD_DBG_DECRYPT    = 0x060,
+    SEV_CMD_DBG_ENCRYPT    = 0x061,
+
+    SEV_CMD_MAX,
+};
+
+/**
+ * struct sev_data_init - INIT command parameters
+ *
+ * @flags: processing flags
+ * @tmr_address: system physical address used for SEV-ES
+ * @tmr_len: len of tmr_address
+ */
+struct sev_data_init {
+    uint32_t flags;       /* In */
+    uint32_t reserved;    /* In */
+    uint64_t tmr_address; /* In */
+    uint32_t tmr_len;     /* In */
+} __packed;
+
+/**
+ * struct sev_data_init_ex - INIT_EX command parameters
+ *
+ * @length: len of the command buffer read by the PSP
+ * @flags: processing flags
+ * @tmr_address: system physical address used for SEV-ES
+ * @tmr_len: len of tmr_address
+ * @nv_address: system physical address used for PSP NV storage
+ * @nv_len: len of nv_address
+ */
+struct sev_data_init_ex {
+    uint32_t length;      /* In */
+    uint32_t flags;       /* In */
+    uint64_t tmr_address; /* In */
+    uint32_t tmr_len;     /* In */
+    uint32_t reserved;    /* In */
+    uint64_t nv_address;  /* In/Out */
+    uint32_t nv_len;      /* In */
+} __packed;
+
+#define SEV_INIT_FLAGS_SEV_ES  0x01
+
+/**
+ * struct sev_data_pek_csr - PEK_CSR command parameters
+ *
+ * @address: PEK certificate chain
+ * @len: len of certificate
+ */
+struct sev_data_pek_csr {
+    uint64_t address; /* In */
+    uint32_t len;     /* In/Out */
+} __packed;
+
+/**
+ * struct sev_data_cert_import - PEK_CERT_IMPORT command parameters
+ *
+ * @pek_address: PEK certificate chain
+ * @pek_len: len of PEK certificate
+ * @oca_address: OCA certificate chain
+ * @oca_len: len of OCA certificate
+ */
+struct sev_data_pek_cert_import {
+    uint64_t pek_cert_address; /* In */
+    uint32_t pek_cert_len;     /* In */
+    uint32_t reserved;         /* In */
+    uint64_t oca_cert_address; /* In */
+    uint32_t oca_cert_len;     /* In */
+} __packed;
+
+/**
+ * struct sev_data_download_firmware - DOWNLOAD_FIRMWARE command parameters
+ *
+ * @address: physical address of firmware image
+ * @len: len of the firmware image
+ */
+struct sev_data_download_firmware {
+    uint64_t address; /* In */
+    uint32_t len;     /* In */
+} __packed;
+
+/**
+ * struct sev_data_get_id - GET_ID command parameters
+ *
+ * @address: physical address of region to place unique CPU ID(s)
+ * @len: len of the region
+ */
+struct sev_data_get_id {
+    uint64_t address; /* In */
+    uint32_t len;     /* In/Out */
+} __packed;
+/**
+ * struct sev_data_pdh_cert_export - PDH_CERT_EXPORT command parameters
+ *
+ * @pdh_address: PDH certificate address
+ * @pdh_len: len of PDH certificate
+ * @cert_chain_address: PDH certificate chain
+ * @cert_chain_len: len of PDH certificate chain
+ */
+struct sev_data_pdh_cert_export {
+    uint64_t pdh_cert_address;   /* In */
+    uint32_t pdh_cert_len;       /* In/Out */
+    uint32_t reserved;           /* In */
+    uint64_t cert_chain_address; /* In */
+    uint32_t cert_chain_len;     /* In/Out */
+} __packed;
+
+/**
+ * struct sev_data_decommission - DECOMMISSION command parameters
+ *
+ * @handle: handle of the VM to decommission
+ */
+struct sev_data_decommission {
+    uint32_t handle; /* In */
+} __packed;
+
+/**
+ * struct sev_data_activate - ACTIVATE command parameters
+ *
+ * @handle: handle of the VM to activate
+ * @asid: asid assigned to the VM
+ */
+struct sev_data_activate {
+    uint32_t handle; /* In */
+    uint32_t asid;   /* In */
+} __packed;
+
+/**
+ * struct sev_data_deactivate - DEACTIVATE command parameters
+ *
+ * @handle: handle of the VM to deactivate
+ */
+struct sev_data_deactivate {
+    uint32_t handle; /* In */
+} __packed;
+
+/**
+ * struct sev_data_guest_status - SEV GUEST_STATUS command parameters
+ *
+ * @handle: handle of the VM to retrieve status
+ * @policy: policy information for the VM
+ * @asid: current ASID of the VM
+ * @state: current state of the VM
+ */
+struct sev_data_guest_status {
+    uint32_t handle; /* In */
+    uint32_t policy; /* Out */
+    uint32_t asid;   /* Out */
+    uint8_t state;   /* Out */
+} __packed;
+
+/**
+ * struct sev_data_launch_start - LAUNCH_START command parameters
+ *
+ * @handle: handle assigned to the VM
+ * @policy: guest launch policy
+ * @dh_cert_address: physical address of DH certificate blob
+ * @dh_cert_len: len of DH certificate blob
+ * @session_address: physical address of session parameters
+ * @session_len: len of session parameters
+ */
+struct sev_data_launch_start {
+    uint32_t handle;          /* In/Out */
+    uint32_t policy;          /* In */
+    uint64_t dh_cert_address; /* In */
+    uint32_t dh_cert_len;     /* In */
+    uint32_t reserved;        /* In */
+    uint64_t session_address; /* In */
+    uint32_t session_len;     /* In */
+} __packed;
+
+/**
+ * struct sev_data_launch_update_data - LAUNCH_UPDATE_DATA command parameter
+ *
+ * @handle: handle of the VM to update
+ * @len: len of memory to be encrypted
+ * @address: physical address of memory region to encrypt
+ */
+struct sev_data_launch_update_data {
+    uint32_t handle;   /* In */
+    uint32_t reserved;
+    uint64_t address;  /* In */
+    uint32_t len;      /* In */
+} __packed;
+
+/**
+ * struct sev_data_launch_update_vmsa - LAUNCH_UPDATE_VMSA command
+ *
+ * @handle: handle of the VM
+ * @address: physical address of memory region to encrypt
+ * @len: len of memory region to encrypt
+ */
+struct sev_data_launch_update_vmsa {
+    uint32_t handle;   /* In */
+    uint32_t reserved;
+    uint64_t address;  /* In */
+    uint32_t len;      /* In */
+} __packed;
+
+/**
+ * struct sev_data_launch_measure - LAUNCH_MEASURE command parameters
+ *
+ * @handle: handle of the VM to process
+ * @address: physical address containing the measurement blob
+ * @len: len of measurement blob
+ */
+struct sev_data_launch_measure {
+    uint32_t handle;   /* In */
+    uint32_t reserved;
+    uint64_t address;  /* In */
+    uint32_t len;      /* In/Out */
+} __packed;
+
+/**
+ * struct sev_data_launch_secret - LAUNCH_SECRET command parameters
+ *
+ * @handle: handle of the VM to process
+ * @hdr_address: physical address containing the packet header
+ * @hdr_len: len of packet header
+ * @guest_address: system physical address of guest memory region
+ * @guest_len: len of guest_paddr
+ * @trans_address: physical address of transport memory buffer
+ * @trans_len: len of transport memory buffer
+ */
+struct sev_data_launch_secret {
+    uint32_t handle;         /* In */
+    uint32_t reserved1;
+    uint64_t hdr_address;    /* In */
+    uint32_t hdr_len;        /* In */
+    uint32_t reserved2;
+    uint64_t guest_address; /* In */
+    uint32_t guest_len;     /* In */
+    uint32_t reserved3;
+    uint64_t trans_address; /* In */
+    uint32_t trans_len;     /* In */
+} __packed;
+
+/**
+ * struct sev_data_launch_finish - LAUNCH_FINISH command parameters
+ *
+ * @handle: handle of the VM to process
+ */
+struct sev_data_launch_finish {
+    uint32_t handle; /* In */
+} __packed;
+
+/**
+ * struct sev_data_send_start - SEND_START command parameters
+ *
+ * @handle: handle of the VM to process
+ * @policy: policy information for the VM
+ * @pdh_cert_address: physical address containing PDH certificate
+ * @pdh_cert_len: len of PDH certificate
+ * @plat_certs_address: physical address containing platform certificate
+ * @plat_certs_len: len of platform certificate
+ * @amd_certs_address: physical address containing AMD certificate
+ * @amd_certs_len: len of AMD certificate
+ * @session_address: physical address containing Session data
+ * @session_len: len of session data
+ */
+struct sev_data_send_start {
+    uint32_t handle;           /* In */
+    uint32_t policy;           /* Out */
+    uint64_t pdh_cert_address; /* In */
+    uint32_t pdh_cert_len;     /* In */
+    uint32_t reserved1;
+    uint64_t plat_certs_address; /* In */
+    uint32_t plat_certs_len;     /* In */
+    uint32_t reserved2;
+    uint64_t amd_certs_address;  /* In */
+    uint32_t amd_certs_len;     /* In */
+    uint32_t reserved3;
+    uint64_t session_address; /* In */
+    uint32_t session_len;     /* In/Out */
+} __packed;
+
+/**
+ * struct sev_data_send_update - SEND_UPDATE_DATA command
+ *
+ * @handle: handle of the VM to process
+ * @hdr_address: physical address containing packet header
+ * @hdr_len: len of packet header
+ * @guest_address: physical address of guest memory region to send
+ * @guest_len: len of guest memory region to send
+ * @trans_address: physical address of host memory region
+ * @trans_len: len of host memory region
+ */
+struct sev_data_send_update_data {
+    uint32_t handle;        /* In */
+    uint32_t reserved1;
+    uint64_t hdr_address;   /* In */
+    uint32_t hdr_len;       /* In/Out */
+    uint32_t reserved2;
+    uint64_t guest_address; /* In */
+    uint32_t guest_len;     /* In */
+    uint32_t reserved3;
+    uint64_t trans_address; /* In */
+    uint32_t trans_len;     /* In */
+} __packed;
+
+/**
+ * struct sev_data_send_update - SEND_UPDATE_VMSA command
+ *
+ * @handle: handle of the VM to process
+ * @hdr_address: physical address containing packet header
+ * @hdr_len: len of packet header
+ * @guest_address: physical address of guest memory region to send
+ * @guest_len: len of guest memory region to send
+ * @trans_address: physical address of host memory region
+ * @trans_len: len of host memory region
+ */
+struct sev_data_send_update_vmsa {
+    uint32_t handle;      /* In */
+    uint64_t hdr_address; /* In */
+    uint32_t hdr_len;     /* In/Out */
+    uint32_t reserved2;
+    uint64_t guest_address; /* In */
+    uint32_t guest_len;     /* In */
+    uint32_t reserved3;
+    uint64_t trans_address; /* In */
+    uint32_t trans_len;     /* In */
+} __packed;
+
+/**
+ * struct sev_data_send_finish - SEND_FINISH command parameters
+ *
+ * @handle: handle of the VM to process
+ */
+struct sev_data_send_finish {
+    uint32_t handle; /* In */
+} __packed;
+
+/**
+ * struct sev_data_send_cancel - SEND_CANCEL command parameters
+ *
+ * @handle: handle of the VM to process
+ */
+struct sev_data_send_cancel {
+    uint32_t handle; /* In */
+} __packed;
+
+/**
+ * struct sev_data_receive_start - RECEIVE_START command parameters
+ *
+ * @handle: handle of the VM to perform receive operation
+ * @pdh_cert_address: system physical address containing PDH certificate blob
+ * @pdh_cert_len: len of PDH certificate blob
+ * @session_address: system physical address containing session blob
+ * @session_len: len of session blob
+ */
+struct sev_data_receive_start {
+    uint32_t handle;           /* In/Out */
+    uint32_t policy;           /* In */
+    uint64_t pdh_cert_address; /* In */
+    uint32_t pdh_cert_len;     /* In */
+    uint32_t reserved1;
+    uint64_t session_address; /* In */
+    uint32_t session_len;     /* In */
+} __packed;
+
+/**
+ * struct sev_data_receive_update_data - RECEIVE_UPDATE_DATA command parameters
+ *
+ * @handle: handle of the VM to update
+ * @hdr_address: physical address containing packet header blob
+ * @hdr_len: len of packet header
+ * @guest_address: system physical address of guest memory region
+ * @guest_len: len of guest memory region
+ * @trans_address: system physical address of transport buffer
+ * @trans_len: len of transport buffer
+ */
+struct sev_data_receive_update_data {
+    uint32_t handle;        /* In */
+    uint32_t reserved1;
+    uint64_t hdr_address;   /* In */
+    uint32_t hdr_len;       /* In */
+    uint32_t reserved2;
+    uint64_t guest_address; /* In */
+    uint32_t guest_len;     /* In */
+    uint32_t reserved3;
+    uint64_t trans_address; /* In */
+    uint32_t trans_len;     /* In */
+} __packed;
+
+/**
+ * struct sev_data_receive_update_vmsa - RECEIVE_UPDATE_VMSA command parameters
+ *
+ * @handle: handle of the VM to update
+ * @hdr_address: physical address containing packet header blob
+ * @hdr_len: len of packet header
+ * @guest_address: system physical address of guest memory region
+ * @guest_len: len of guest memory region
+ * @trans_address: system physical address of transport buffer
+ * @trans_len: len of transport buffer
+ */
+struct sev_data_receive_update_vmsa {
+    uint32_t handle;        /* In */
+    uint32_t reserved1;
+    uint64_t hdr_address;   /* In */
+    uint32_t hdr_len;       /* In */
+    uint32_t reserved2;
+    uint64_t guest_address; /* In */
+    uint32_t guest_len;     /* In */
+    uint32_t reserved3;
+    uint64_t trans_address; /* In */
+    uint32_t trans_len;     /* In */
+} __packed;
+
+/**
+ * struct sev_data_receive_finish - RECEIVE_FINISH command parameters
+ *
+ * @handle: handle of the VM to finish
+ */
+struct sev_data_receive_finish {
+    uint32_t handle; /* In */
+} __packed;
+
+/**
+ * struct sev_data_dbg - DBG_ENCRYPT/DBG_DECRYPT command parameters
+ *
+ * @handle: handle of the VM to perform debug operation
+ * @src_addr: source address of data to operate on
+ * @dst_addr: destination address of data to operate on
+ * @len: len of data to operate on
+ */
+struct sev_data_dbg {
+    uint32_t handle;   /* In */
+    uint32_t reserved;
+    uint64_t src_addr; /* In */
+    uint64_t dst_addr; /* In */
+    uint32_t len;      /* In */
+} __packed;
+
+/**
+ * struct sev_data_attestation_report - SEV_ATTESTATION_REPORT command parameters
+ *
+ * @handle: handle of the VM
+ * @mnonce: a random nonce that will be included in the report.
+ * @address: physical address where the report will be copied.
+ * @len: length of the physical buffer.
+ */
+struct sev_data_attestation_report {
+    uint32_t handle;    /* In */
+    uint32_t reserved;
+    uint64_t address;   /* In */
+    uint8_t mnonce[16]; /* In */
+    uint32_t len;       /* In/Out */
+} __packed;
+
+
+/**
+ * SEV platform commands
+ */
+enum {
+    SEV_FACTORY_RESET = 0,
+    SEV_PLATFORM_STATUS,
+    SEV_PEK_GEN,
+    SEV_PEK_CSR,
+    SEV_PDH_GEN,
+    SEV_PDH_CERT_EXPORT,
+    SEV_PEK_CERT_IMPORT,
+    SEV_GET_ID,  /* This command is deprecated, use SEV_GET_ID2 */
+    SEV_GET_ID2,
+
+    SEV_MAX,
+};
+
+/**
+ * SEV Firmware status code
+ */
+typedef enum {
+    /*
+    * This error code is not in the SEV spec. Its purpose is to convey that
+    * there was an error that prevented the SEV firmware from being called.
+    * The SEV API error codes are 16 bits, so the -1 value will not overlap
+    * with possible values from the specification.
+    */
+    SEV_RET_NO_FW_CALL = -1,
+    SEV_RET_SUCCESS = 0,
+    SEV_RET_INVALID_PLATFORM_STATE,
+    SEV_RET_INVALID_GUEST_STATE,
+    SEV_RET_INAVLID_CONFIG,
+    SEV_RET_INVALID_LEN,
+    SEV_RET_ALREADY_OWNED,
+    SEV_RET_INVALID_CERTIFICATE,
+    SEV_RET_POLICY_FAILURE,
+    SEV_RET_INACTIVE,
+    SEV_RET_INVALID_ADDRESS,
+    SEV_RET_BAD_SIGNATURE,
+    SEV_RET_BAD_MEASUREMENT,
+    SEV_RET_ASID_OWNED,
+    SEV_RET_INVALID_ASID,
+    SEV_RET_WBINVD_REQUIRED,
+    SEV_RET_DFFLUSH_REQUIRED,
+    SEV_RET_INVALID_GUEST,
+    SEV_RET_INVALID_COMMAND,
+    SEV_RET_ACTIVE,
+    SEV_RET_HWSEV_RET_PLATFORM,
+    SEV_RET_HWSEV_RET_UNSAFE,
+    SEV_RET_UNSUPPORTED,
+    SEV_RET_INVALID_PARAM,
+    SEV_RET_RESOURCE_LIMIT,
+    SEV_RET_SECURE_DATA_INVALID,
+    SEV_RET_MAX,
+} sev_ret_code;
+
+/**
+ * struct sev_user_data_status - PLATFORM_STATUS command parameters
+ *
+ * @major: major API version
+ * @minor: minor API version
+ * @state: platform state
+ * @flags: platform config flags
+ * @build: firmware build id for API version
+ * @guest_count: number of active guests
+ */
+struct sev_user_data_status {
+    uint8_t api_major;   /* Out */
+    uint8_t api_minor;   /* Out */
+    uint8_t state;       /* Out */
+    uint8_t flags;       /* Out */
+    uint8_t build;       /* Out */
+    uint8_t guest_count; /* Out */
+} __packed;
+
+#define SEV_STATUS_FLAGS_CONFIG_ES  0x0100
+
+/**
+ * struct sev_user_data_pek_csr - PEK_CSR command parameters
+ *
+ * @address: PEK certificate chain
+ * @length: length of certificate
+ */
+struct sev_user_data_pek_csr {
+    uint8_t address; /* In */
+    uint8_t length;  /* In/Out */
+} __packed;
+
+/**
+ * struct sev_user_data_cert_import - PEK_CERT_IMPORT command parameters
+ *
+ * @pek_address: PEK certificate chain
+ * @pek_len: length of PEK certificate
+ * @oca_address: OCA certificate chain
+ * @oca_len: length of OCA certificate
+ */
+struct sev_user_data_pek_cert_import {
+    uint8_t pek_cert_address; /* In */
+    uint8_t pek_cert_len;     /* In */
+    uint8_t oca_cert_address; /* In */
+    uint8_t oca_cert_len;     /* In */
+} __packed;
+
+/**
+ * struct sev_user_data_pdh_cert_export - PDH_CERT_EXPORT command parameters
+ *
+ * @pdh_address: PDH certificate address
+ * @pdh_len: length of PDH certificate
+ * @cert_chain_address: PDH certificate chain
+ * @cert_chain_len: length of PDH certificate chain
+ */
+struct sev_user_data_pdh_cert_export {
+    uint8_t pdh_cert_address;   /* In */
+    uint8_t pdh_cert_len;       /* In/Out */
+    uint8_t cert_chain_address; /* In */
+    uint8_t cert_chain_len;     /* In/Out */
+} __packed;
+
+/**
+ * struct sev_user_data_get_id - GET_ID command parameters (deprecated)
+ *
+ * @socket1: Buffer to pass unique ID of first socket
+ * @socket2: Buffer to pass unique ID of second socket
+ */
+struct sev_user_data_get_id {
+    uint8_t socket1[64]; /* Out */
+    uint8_t socket2[64]; /* Out */
+} __packed;
+
+/**
+ * struct sev_user_data_get_id2 - GET_ID command parameters
+ * @address: Buffer to store unique ID
+ * @length: length of the unique ID
+ */
+struct sev_user_data_get_id2 {
+    uint8_t address; /* In */
+    uint8_t length;  /* In/Out */
+} __packed;
+
+extern int sev_do_cmd(int cmd, void *data, int *psp_ret, bool poll);
+
+#endif  /* __PSP_SEV_H__ */
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index 20050e9bb8..bed7d5a3e2 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -12,6 +12,8 @@ source "drivers/pci/Kconfig"
 
 source "drivers/video/Kconfig"
 
+source "drivers/crypto/Kconfig"
+
 config HAS_VPCI
 	bool
 
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 2a1ae8ad13..f24f788fde 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_HAS_VPCI) += vpci/
 obj-$(CONFIG_HAS_PASSTHROUGH) += passthrough/
 obj-$(CONFIG_ACPI) += acpi/
 obj-$(CONFIG_VIDEO) += video/
+obj-y += crypto/
diff --git a/xen/drivers/crypto/Kconfig b/xen/drivers/crypto/Kconfig
new file mode 100644
index 0000000000..ca3d3f5f1b
--- /dev/null
+++ b/xen/drivers/crypto/Kconfig
@@ -0,0 +1,10 @@
+config AMD_SP
+        bool "AMD Secure Processor (UNSUPPORTED)" if UNSUPPORTED
+        depends on X86
+        default n
+        help
+          Enables AMD Secure Processor.
+
+          If your platform includes AMD Secure Processor devices and you are
+          intended to use AMD Secure Encrypted Virtualization Technology, say Y.
+          If in doubt, say N.
diff --git a/xen/drivers/crypto/Makefile b/xen/drivers/crypto/Makefile
new file mode 100644
index 0000000000..ff283c2cb5
--- /dev/null
+++ b/xen/drivers/crypto/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_AMD_SP) += asp.o
diff --git a/xen/drivers/crypto/asp.c b/xen/drivers/crypto/asp.c
new file mode 100644
index 0000000000..834e5d3b9b
--- /dev/null
+++ b/xen/drivers/crypto/asp.c
@@ -0,0 +1,830 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+TODO:
+-  GLOBAL:
+     - add command line params for tunables
+ - INTERRUPT MODE:
+    - CET shadow stack: adapt #CP handler???
+    - Serialization: must be done by the client? adapt spinlock?
+ */
+
+#define PSP_CAPABILITY_SEV                      (1 << 0)
+#define PSP_CAPABILITY_TEE                      (1 << 1)
+#define PSP_CAPABILITY_PSP_SECURITY_REPORTING   (1 << 7)
+#define PSP_CAPABILITY_PSP_SECURITY_OFFSET      8
+
+#define PSP_INTSTS_CMD_COMPLETE       (1 << 1)
+
+#define SEV_CMDRESP_CMD_MASK          0x7ff0000
+#define SEV_CMDRESP_CMD_SHIFT         16
+#define SEV_CMDRESP_CMD(cmd)          ((cmd) << SEV_CMDRESP_CMD_SHIFT)
+#define SEV_CMDRESP_STS_MASK          0xffff
+#define SEV_CMDRESP_STS(x)            ((x) & SEV_CMDRESP_STS_MASK)
+#define SEV_CMDRESP_RESP              (1 << 31)
+#define SEV_CMDRESP_IOC               (1 << 0)
+
+#define ASP_CMD_BUFF_SIZE    0x1000
+#define SEV_FW_BLOB_MAX_SIZE 0x4000
+
+/*
+ * SEV platform state
+ */
+enum sev_state {
+        SEV_STATE_UNINIT                = 0x0,
+        SEV_STATE_INIT                  = 0x1,
+        SEV_STATE_WORKING               = 0x2,
+        SEV_STATE_MAX
+};
+
+struct sev_vdata {
+    const unsigned int cmdresp_reg;
+    const unsigned int cmdbuff_addr_lo_reg;
+    const unsigned int cmdbuff_addr_hi_reg;
+};
+
+struct psp_vdata {
+    const unsigned short   base_offset;
+    const struct sev_vdata *sev;
+    const unsigned int feature_reg;
+    const unsigned int inten_reg;
+    const unsigned int intsts_reg;
+    const char* name;
+};
+
+static struct sev_vdata sevv1 = {
+    .cmdresp_reg         = 0x10580,     /* C2PMSG_32 */
+    .cmdbuff_addr_lo_reg = 0x105e0,     /* C2PMSG_56 */
+    .cmdbuff_addr_hi_reg = 0x105e4,     /* C2PMSG_57 */
+};
+
+static struct sev_vdata sevv2 = {
+    .cmdresp_reg         = 0x10980,     /* C2PMSG_32 */
+    .cmdbuff_addr_lo_reg = 0x109e0,     /* C2PMSG_56 */
+    .cmdbuff_addr_hi_reg = 0x109e4,     /* C2PMSG_57 */
+};
+
+static struct psp_vdata pspv1 = {
+    .base_offset = PCI_BASE_ADDRESS_2,
+    .sev         = &sevv1,
+    .feature_reg = 0x105fc,     /* C2PMSG_63 */
+    .inten_reg   = 0x10610,     /* P2CMSG_INTEN */
+    .intsts_reg  = 0x10614,     /* P2CMSG_INTSTS */
+    .name = "pspv1",
+};
+
+static struct psp_vdata pspv2 = {
+    .base_offset = PCI_BASE_ADDRESS_2,
+    .sev         = &sevv2,
+    .feature_reg = 0x109fc,     /* C2PMSG_63 */
+    .inten_reg   = 0x10690,     /* P2CMSG_INTEN */
+    .intsts_reg  = 0x10694,     /* P2CMSG_INTSTS */
+    .name = "pspv2",
+};
+
+static struct psp_vdata pspv4 = {
+    .base_offset = PCI_BASE_ADDRESS_2,
+    .sev         = &sevv2,
+    .feature_reg = 0x109fc,     /* C2PMSG_63 */
+    .inten_reg   = 0x10690,     /* P2CMSG_INTEN */
+    .intsts_reg  = 0x10694,     /* P2CMSG_INTSTS */
+    .name = "pspv4",
+};
+
+static struct psp_vdata pspv6 = {
+    .base_offset =  PCI_BASE_ADDRESS_2,
+    .sev         = &sevv2,
+    .feature_reg = 0x109fc,     /* C2PMSG_63 */
+    .inten_reg   = 0x10510,     /* P2CMSG_INTEN */
+    .intsts_reg  = 0x10514,     /* P2CMSG_INTSTS */
+    .name = "pspv6",
+};
+
+struct amd_sp_dev
+{
+    struct list_head list;
+    struct pci_dev   *pdev;
+    struct  psp_vdata *vdata;
+    void    *io_base;
+    paddr_t io_pbase;
+    size_t  io_size;
+    int     irq;
+    int     state;
+    void* cmd_buff;
+    uint32_t cbuff_pa_low;
+    uint32_t cbuff_pa_high;
+    unsigned int capability;
+    uint8_t api_major;
+    uint8_t api_minor;
+    uint8_t build;
+    int     intr_rcvd;
+    int     cmd_timeout;
+    struct timer cmd_timer;
+    struct waitqueue_head cmd_in_progress;
+};
+
+LIST_HEAD(amd_sp_units);
+#define for_each_sp_unit(sp) \
+    list_for_each_entry(sp, &amd_sp_units, list)
+
+static spinlock_t _sp_cmd_lock = SPIN_LOCK_UNLOCKED;
+
+static struct amd_sp_dev *amd_sp_master;
+
+static void do_sp_irq(void *data);
+static DECLARE_SOFTIRQ_TASKLET(sp_irq_tasklet, do_sp_irq, NULL);
+
+static bool force_sync = false;
+static unsigned int asp_timeout_val = 30000;
+static unsigned long long asp_sync_delay = 100ULL;
+static int asp_sync_tries = 10;
+
+static void sp_cmd_lock(void)
+{
+    spin_lock(&_sp_cmd_lock);
+}
+
+static void sp_cmd_unlock(void)
+{
+    spin_unlock(&_sp_cmd_lock);
+}
+
+static int sev_cmd_buffer_len(int cmd)
+{
+    switch (cmd) {
+        case SEV_CMD_INIT:                     
+            return sizeof(struct sev_data_init);
+        case SEV_CMD_INIT_EX:
+            return sizeof(struct sev_data_init_ex);
+        case SEV_CMD_PLATFORM_STATUS:
+            return sizeof(struct sev_user_data_status);
+        case SEV_CMD_PEK_CSR:
+            return sizeof(struct sev_data_pek_csr);
+        case SEV_CMD_PEK_CERT_IMPORT:
+            return sizeof(struct sev_data_pek_cert_import);
+        case SEV_CMD_PDH_CERT_EXPORT:
+            return sizeof(struct sev_data_pdh_cert_export);
+        case SEV_CMD_LAUNCH_START:
+            return sizeof(struct sev_data_launch_start);
+        case SEV_CMD_LAUNCH_UPDATE_DATA:
+            return sizeof(struct sev_data_launch_update_data);
+        case SEV_CMD_LAUNCH_UPDATE_VMSA:
+            return sizeof(struct sev_data_launch_update_vmsa);
+        case SEV_CMD_LAUNCH_FINISH:
+            return sizeof(struct sev_data_launch_finish);
+        case SEV_CMD_LAUNCH_MEASURE:
+            return sizeof(struct sev_data_launch_measure);
+        case SEV_CMD_ACTIVATE:
+            return sizeof(struct sev_data_activate);
+        case SEV_CMD_DEACTIVATE:
+            return sizeof(struct sev_data_deactivate);
+        case SEV_CMD_DECOMMISSION:
+            return sizeof(struct sev_data_decommission);
+        case SEV_CMD_GUEST_STATUS:
+            return sizeof(struct sev_data_guest_status);
+        case SEV_CMD_DBG_DECRYPT:
+            return sizeof(struct sev_data_dbg);
+        case SEV_CMD_DBG_ENCRYPT:
+            return sizeof(struct sev_data_dbg);
+        case SEV_CMD_SEND_START:
+            return sizeof(struct sev_data_send_start);
+        case SEV_CMD_SEND_UPDATE_DATA:
+            return sizeof(struct sev_data_send_update_data);
+        case SEV_CMD_SEND_UPDATE_VMSA:
+            return sizeof(struct sev_data_send_update_vmsa);
+        case SEV_CMD_SEND_FINISH:
+            return sizeof(struct sev_data_send_finish);
+        case SEV_CMD_RECEIVE_START:
+            return sizeof(struct sev_data_receive_start);
+        case SEV_CMD_RECEIVE_FINISH:
+            return sizeof(struct sev_data_receive_finish);
+        case SEV_CMD_RECEIVE_UPDATE_DATA:
+            return sizeof(struct sev_data_receive_update_data);
+        case SEV_CMD_RECEIVE_UPDATE_VMSA:
+            return sizeof(struct sev_data_receive_update_vmsa);
+        case SEV_CMD_LAUNCH_UPDATE_SECRET:
+            return sizeof(struct sev_data_launch_secret);
+        case SEV_CMD_DOWNLOAD_FIRMWARE:
+            return sizeof(struct sev_data_download_firmware);
+        case SEV_CMD_GET_ID:
+            return sizeof(struct sev_data_get_id);
+        case SEV_CMD_ATTESTATION_REPORT:
+            return sizeof(struct sev_data_attestation_report);
+        case SEV_CMD_SEND_CANCEL:
+            return sizeof(struct sev_data_send_cancel);
+        default:
+            return 0;
+    }
+}
+
+static void invalidate_cache(void *unused)
+{
+    wbinvd();
+}
+
+int _sev_do_cmd(struct amd_sp_dev *sp, int cmd, void *data, int *psp_ret)
+{
+    unsigned int cbuff_pa_low, cbuff_pa_high, cmd_val;
+    int buf_len, cmdresp, rc;
+
+    buf_len = sev_cmd_buffer_len(cmd);
+
+    if ( data )
+        memcpy(sp->cmd_buff, data, buf_len);
+
+    cbuff_pa_low  = data ? sp->cbuff_pa_low : 0;
+    cbuff_pa_high = data ? sp->cbuff_pa_high : 0;
+
+    writel(cbuff_pa_low, sp->io_base + sp->vdata->sev->cmdbuff_addr_lo_reg);
+    writel(cbuff_pa_high, sp->io_base + sp->vdata->sev->cmdbuff_addr_hi_reg);
+
+    cmd_val = SEV_CMDRESP_CMD(cmd) | SEV_CMDRESP_IOC;
+
+    sp->cmd_timeout = 0;
+    sp->intr_rcvd = 0;
+
+    writel(cmd_val, sp->io_base + sp->vdata->sev->cmdresp_reg);
+
+    set_timer(&sp->cmd_timer, NOW() + MILLISECS(asp_timeout_val));
+
+    /* FIXME: If the timer triggers here the device will be set offline */
+
+    wait_event(sp->cmd_in_progress, sp->cmd_timeout || sp->intr_rcvd);
+
+    stop_timer(&sp->cmd_timer);
+
+    if ( sp->intr_rcvd )
+    {
+        cmdresp = readl(sp->io_base + sp->vdata->sev->cmdresp_reg);
+
+        ASSERT(cmdresp & SEV_CMDRESP_RESP);
+
+        rc = SEV_CMDRESP_STS(cmdresp) ? -EFAULT : 0;
+
+        if ( rc && psp_ret )
+            *psp_ret = SEV_CMDRESP_STS(cmdresp);
+
+        if ( data && (!rc) )
+            memcpy(data, sp->cmd_buff, buf_len);
+    }
+    else
+    {
+        ASSERT(sp->cmd_timeout);
+
+        sp->state = SEV_STATE_UNINIT;
+
+        writel(0, sp->io_base + sp->vdata->inten_reg);
+
+        rc = -EIO;
+    }
+    return rc;
+}
+
+static int _sev_do_cmd_sync(struct amd_sp_dev *sp, int cmd, void *data, int *psp_ret)
+{
+    unsigned int cbuff_pa_low, cbuff_pa_high, cmd_val;
+    int buf_len, cmdresp, rc, i;
+
+    buf_len = sev_cmd_buffer_len(cmd);
+
+    if ( data )
+        memcpy(sp->cmd_buff, data, buf_len);
+
+    cbuff_pa_low  = data ? sp->cbuff_pa_low : 0;
+    cbuff_pa_high = data ? sp->cbuff_pa_high : 0;
+
+    writel(cbuff_pa_low, sp->io_base + sp->vdata->sev->cmdbuff_addr_lo_reg);
+    writel(cbuff_pa_high, sp->io_base + sp->vdata->sev->cmdbuff_addr_hi_reg);
+
+    cmd_val = SEV_CMDRESP_CMD(cmd);
+
+    writel(cmd_val, sp->io_base + sp->vdata->sev->cmdresp_reg);
+
+    for (rc = -EIO, i = asp_sync_tries; i; i-- )
+    {
+        mdelay(asp_sync_delay);
+
+        cmdresp = readl(sp->io_base + sp->vdata->sev->cmdresp_reg);
+        if ( cmdresp & SEV_CMDRESP_RESP )
+        {
+            rc = 0;
+            break;
+        }
+    }
+
+    if ( !rc && SEV_CMDRESP_STS(cmdresp) )
+	rc = -EFAULT;
+
+    if ( rc &&  psp_ret )
+        *psp_ret = SEV_CMDRESP_STS(cmdresp);
+
+    if ( data && (!rc) )
+        memcpy(data, sp->cmd_buff, buf_len);
+
+    return rc;
+}
+
+int sev_do_cmd(int cmd, void *data, int *psp_ret, bool poll)
+{
+    struct amd_sp_dev *sp  = amd_sp_master;
+    int buf_len, rc;
+
+    if ( !sp )
+        return -ENODEV;
+
+    if ( sp->state < SEV_STATE_INIT )
+        return -ENODEV;
+
+    if ( cmd >= SEV_CMD_MAX )
+        return -EINVAL;
+
+    buf_len = sev_cmd_buffer_len(cmd);
+
+    if ( !data != !buf_len )
+        return -EINVAL;
+
+    if ( force_sync || poll )
+    {
+        sp_cmd_lock();
+        rc = _sev_do_cmd_sync(sp, cmd, data, psp_ret);
+        sp_cmd_unlock();
+    }
+    else
+    {
+        rc = _sev_do_cmd(sp, cmd, data, psp_ret);
+    }
+
+    return rc;
+}
+
+static void do_sp_cmd_timer(void *data)
+{
+    struct amd_sp_dev *sp = (struct amd_sp_dev*)data;
+
+    sp->cmd_timeout = 1;
+    wake_up_nr(&sp->cmd_in_progress, 1);
+}
+
+static void do_sp_irq(void *data)
+{
+    struct amd_sp_dev *sp;
+
+    for_each_sp_unit(sp)
+    {
+        uint32_t cmdresp = readl(sp->io_base + sp->vdata->sev->cmdresp_reg);
+        if ( cmdresp & SEV_CMDRESP_RESP )
+        {
+            sp->intr_rcvd = 1;
+            wake_up_nr(&sp->cmd_in_progress, 1);
+        }
+    }
+}
+
+static void sp_interrupt_handler(int irq, void *dev_id)
+{
+    struct amd_sp_dev *sp = (struct amd_sp_dev*)dev_id;
+    uint32_t status;
+
+    status = readl(sp->io_base + sp->vdata->intsts_reg);
+    writel(status, sp->io_base + sp->vdata->intsts_reg);
+
+    if ( status & PSP_INTSTS_CMD_COMPLETE )
+	    tasklet_schedule(&sp_irq_tasklet);
+}
+
+static int __init sp_get_capability(struct amd_sp_dev *sp)
+{
+    uint32_t val = readl(sp->io_base + sp->vdata->feature_reg);
+
+    if ( (val == 0xffffffff) || (!(val & PSP_CAPABILITY_SEV)) )
+        return -ENODEV;
+
+    sp->capability = val;
+
+    return 0;
+}
+
+static int __init sp_get_state(struct amd_sp_dev *sp, int *state, int *err)
+{
+    struct sev_user_data_status status;
+    int rc;
+
+    rc = _sev_do_cmd_sync(sp, SEV_CMD_PLATFORM_STATUS, &status, err);
+    if ( rc )
+        return rc;
+
+    *state = status.state;
+
+    return 0;
+}
+
+static int __init sp_get_api_version(struct amd_sp_dev *sp)
+{
+    struct sev_user_data_status status;
+    int err, rc;
+
+    rc = _sev_do_cmd_sync(sp, SEV_CMD_PLATFORM_STATUS, &status, &err);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: can't get API version (%d 0x%x)\n",
+                &sp->pdev->sbdf, rc, err);
+        return rc;
+    }
+
+    sp->api_major = status.api_major;
+    sp->api_minor = status.api_minor;
+    sp->state     = status.state;
+
+    return 0;
+}
+
+static int __init sp_update_firmware(struct amd_sp_dev *sp)
+{
+    /*
+     * FIXME: nothing to do for now
+     */
+    return 0;
+}
+
+static int __init sp_alloc_special_regions(struct amd_sp_dev *sp)
+{
+    /*
+     * FIXME: allocate TMP memory area for SEV-ES
+     */
+    return 0;
+}
+
+static int __init sp_do_init(struct amd_sp_dev *sp)
+{
+    struct sev_data_init data;
+    int err, rc;
+
+    if ( sp->state == SEV_STATE_INIT )
+        return 0;
+
+    memset(&data, 0, sizeof(data));
+
+    rc = _sev_do_cmd_sync(sp, SEV_CMD_INIT, &data, &err);
+    if ( rc )
+        dprintk(XENLOG_ERR, "asp-%pp: can't init device: (%d 0x%x)\n", &sp->pdev->sbdf, rc, err);
+
+    return 0;
+}
+
+static int __init sp_df_flush(struct amd_sp_dev *sp)
+{
+    int rc, err;
+
+    rc = _sev_do_cmd_sync(sp, SEV_CMD_DF_FLUSH, NULL, &err);
+    if ( rc )
+        dprintk(XENLOG_ERR, "asp-%pp: can't flush device: (%d 0x%x)\n", &sp->pdev->sbdf, rc, err);
+
+    return 0;
+}
+
+static int __init sp_dev_init(struct amd_sp_dev *sp)
+{
+    int err, rc;
+
+    rc = sp_get_capability(sp);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: capability is broken %d\n",
+		&sp->pdev->sbdf, rc);
+        return rc;
+    }
+
+    rc = sp_get_api_version(sp);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: can't get API version %d\n",
+		&sp->pdev->sbdf, rc);
+        return rc;
+    }
+
+    rc = sp_update_firmware(sp);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: can't update firmware %d\n",
+		&sp->pdev->sbdf, rc);
+        return rc;
+    }
+
+    rc = sp_alloc_special_regions(sp);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: can't alloc special regions %d\n",
+		&sp->pdev->sbdf, rc);
+        return rc;
+    }
+
+    rc = sp_do_init(sp);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: can't init device %d\n", &sp->pdev->sbdf,
+		rc);
+        return rc;
+    }
+
+    on_each_cpu(invalidate_cache, NULL, 1);
+
+    rc = sp_df_flush(sp);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: can't flush %d\n", &sp->pdev->sbdf, rc);
+        return rc;
+    }
+
+    rc = sp_get_state(sp, &sp->state, &err);
+    if ( rc )
+        dprintk(XENLOG_ERR, "asp-%pp: can't get sate %d\n", &sp->pdev->sbdf,rc);
+
+
+    if ( sp->state != SEV_STATE_INIT )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: device is not inited 0x%x\n",
+		&sp->pdev->sbdf, sp->state);
+        return rc;
+    }
+
+    printk(XENLOG_INFO "inited asp-%pp device\n", &sp->pdev->sbdf);
+    return 0;
+}
+
+static int __init sp_init_irq(struct amd_sp_dev *sp)
+{
+    int irq, rc;
+    struct msi_info minfo;
+    struct msi_desc *mdesc;
+
+    /* Disable and clear interrupts until ready */
+    writel(0, sp->io_base + sp->vdata->inten_reg);
+    writel(-1, sp->io_base + sp->vdata->intsts_reg);
+
+    irq = create_irq(0, false);
+    if ( !irq )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: can't create interrupt\n", &sp->pdev->sbdf);
+        return -EBUSY;
+    }
+
+    minfo.sbdf = sp->pdev->sbdf;
+    minfo.irq  = irq;
+    minfo.entry_nr = 1;
+    if ( pci_find_cap_offset(sp->pdev->sbdf, PCI_CAP_ID_MSI) )
+        minfo.table_base = 0;
+    else
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: only MSI is handled\n", &sp->pdev->sbdf);
+        return -EINVAL;
+    }
+
+    mdesc = NULL;
+
+    pcidevs_lock();
+
+    rc = pci_enable_msi(sp->pdev, &minfo, &mdesc);
+    if ( !rc )
+    {
+        struct irq_desc *idesc = irq_to_desc(irq);
+        unsigned long flags;
+
+        spin_lock_irqsave(&idesc->lock, flags);
+        rc = setup_msi_irq(idesc, mdesc);
+        spin_unlock_irqrestore(&idesc->lock, flags);
+
+        if ( rc )
+        {
+            pci_disable_msi(mdesc);
+            dprintk(XENLOG_ERR, "asp-%pp: can't setup msi %d\n", &sp->pdev->sbdf, rc);
+        }
+    }
+
+    pcidevs_unlock();
+
+    if ( rc )
+    {
+        if ( mdesc )
+            msi_free_irq(mdesc);
+        else
+            destroy_irq(irq);
+        return rc;
+
+    }
+
+    rc = request_irq(irq, 0, sp_interrupt_handler, "amd_sp", sp);
+
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: can't request interrupt %d\n", &sp->pdev->sbdf, rc);
+        return rc;
+    }
+
+    sp->irq = irq;
+
+        /* Enable interrupts */
+    writel(-1, sp->io_base + sp->vdata->inten_reg);
+
+    return 0;
+}
+
+static int __init sp_map_iomem(struct amd_sp_dev *sp)
+{
+    uint32_t base_low;
+    uint32_t base_high;
+    uint16_t cmd;
+    size_t   size;
+    bool     high_space;
+
+    base_low = pci_conf_read32(sp->pdev->sbdf, sp->vdata->base_offset);
+
+    if ( (base_low & PCI_BASE_ADDRESS_SPACE) != PCI_BASE_ADDRESS_SPACE_MEMORY )
+        return -EINVAL;
+
+    if ( (base_low & PCI_BASE_ADDRESS_MEM_TYPE_MASK) == PCI_BASE_ADDRESS_MEM_TYPE_64 )
+    {
+        base_high = pci_conf_read32(sp->pdev->sbdf, sp->vdata->base_offset + 4);
+        high_space = true;
+    } else {
+        base_high = 0;
+        high_space = false;
+    }
+
+    sp->io_pbase = ((paddr_t)base_high << 32) | (base_low & PCI_BASE_ADDRESS_MEM_MASK);
+    ASSERT(sp->io_pbase);
+
+    pci_conf_write32(sp->pdev->sbdf, sp->vdata->base_offset, 0xFFFFFFFF);
+
+    if ( high_space ) {
+        pci_conf_write32(sp->pdev->sbdf, sp->vdata->base_offset + 4, 0xFFFFFFFF);
+        size = (size_t)pci_conf_read32(sp->pdev->sbdf, sp->vdata->base_offset + 4) << 32;
+    } else
+        size = ~0xffffffffUL;
+
+    size |= pci_conf_read32(sp->pdev->sbdf, sp->vdata->base_offset);
+    sp->io_size = ~(size & PCI_BASE_ADDRESS_MEM_MASK) + 1;
+
+    pci_conf_write32(sp->pdev->sbdf, sp->vdata->base_offset, base_low);
+
+    if ( high_space )
+          pci_conf_write32(sp->pdev->sbdf, sp->vdata->base_offset + 4, base_high);
+
+    cmd = pci_conf_read16(sp->pdev->sbdf, PCI_COMMAND);
+    pci_conf_write16(sp->pdev->sbdf, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
+
+    sp->io_base = ioremap(sp->io_pbase, sp->io_size);
+    if ( !sp->io_base )
+        return -EFAULT;
+
+    if ( pci_ro_device(0, sp->pdev->bus, sp->pdev->devfn) )
+    {
+	dprintk(XENLOG_ERR, "asp-%pp: can't hide PCI device\n",&sp->pdev->sbdf);
+	return -EFAULT;
+    }
+
+    return 0;
+}
+
+static int  __init sp_dev_create(struct pci_dev *pdev, struct psp_vdata *vdata)
+{
+    struct amd_sp_dev *sp;
+    int rc;
+
+    printk(XENLOG_INFO "asp: discovered asp-%pp device\n", &pdev->sbdf);
+
+    sp = xzalloc(struct amd_sp_dev);
+    if ( !sp )
+        return -ENOMEM;
+
+    sp->pdev = pdev;
+    sp->vdata = vdata;
+    sp->state = SEV_STATE_UNINIT;
+
+    init_timer(&sp->cmd_timer, do_sp_cmd_timer, (void*)sp, 0);
+
+    init_waitqueue_head(&sp->cmd_in_progress);
+
+    rc = sp_map_iomem(sp);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: can't map iomem %d\n", &sp->pdev->sbdf, rc);
+        return rc;
+    }
+
+    rc = sp_init_irq(sp);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: can't init irq %d\n", &sp->pdev->sbdf, rc);
+        return rc;
+    }
+
+    sp->cmd_buff = alloc_xenheap_pages(get_order_from_bytes(ASP_CMD_BUFF_SIZE), 0);
+    if ( !sp->cmd_buff )
+    {
+        dprintk(XENLOG_ERR, "asp-%pp: can't allocate cmd buffer\n", &sp->pdev->sbdf);
+        return -ENOMEM;
+    }
+
+    sp->cbuff_pa_low = (uint32_t)(__pa(sp->cmd_buff));
+    sp->cbuff_pa_high = (uint32_t)(__pa(sp->cmd_buff) >> 32);
+
+    list_add(&sp->list, &amd_sp_units);
+
+    amd_sp_master = sp;
+
+    return 0;
+}
+
+static void sp_dev_destroy(struct amd_sp_dev* sp)
+{
+    if( sp->io_base )
+        writel(0, sp->io_base + sp->vdata->inten_reg);
+
+    if ( sp->cmd_buff )
+        free_xenheap_pages(sp->cmd_buff, get_order_from_bytes(ASP_CMD_BUFF_SIZE));
+
+    xfree(sp);
+}
+
+static void sp_devs_destroy(void)
+{
+    struct amd_sp_dev *sp, *next;
+
+    list_for_each_entry_safe ( sp, next, &amd_sp_units, list)
+    {
+        list_del(&sp->list);
+        sp_dev_destroy(sp);
+    }
+}
+
+static int __init amd_sp_probe(void)
+{
+    int bus = 0, devfn = 0, rc;
+    struct  amd_sp_dev *sp;
+
+     if ( boot_cpu_has(X86_FEATURE_XEN_SHSTK) )
+     {
+        force_sync = true;
+        printk(XENLOG_INFO "asp: CET-SS detected - sync mode forced\n");
+     }
+
+    for ( bus = 0; bus < 256; ++bus )
+        for ( devfn = 0; devfn < 256; ++devfn )
+        {
+            struct pci_dev *pdev;
+            pcidevs_lock();
+            pdev = pci_get_pdev(NULL, PCI_SBDF(0, bus, devfn));
+            pcidevs_unlock();
+
+            if ( !pdev || pci_conf_read16(pdev->sbdf, PCI_VENDOR_ID) !=
+                 PCI_VENDOR_ID_AMD )
+                continue;
+
+            switch ( pci_conf_read16(pdev->sbdf, PCI_DEVICE_ID) )
+            {
+                case 0x1456:
+                    rc = sp_dev_create(pdev, &pspv1);
+                    break;
+                case 0x1486:
+                    rc = sp_dev_create(pdev, &pspv2);
+                    break;
+                case 0x14CA:
+                    rc = sp_dev_create(pdev, &pspv4);
+                    break;
+                case 0x156E:
+                    rc = sp_dev_create(pdev, &pspv6);
+                    break;
+                default:
+                    rc = 0;
+                    break;
+            }
+            if ( rc )
+                goto err;
+        }
+
+    for_each_sp_unit(sp)
+    {
+        rc = sp_dev_init(sp);
+        if ( rc )
+            goto err;
+    }
+
+    return 0;
+
+  err:
+    sp_devs_destroy();
+    return rc;
+}
+
+__initcall(amd_sp_probe);
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 10:23:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:23:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986812.1372338 (Exim 4.92)
	(envelope-from )
	id 1uFsDl-0001Au-6b; Fri, 16 May 2025 10:23:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986812.1372338; Fri, 16 May 2025 10:23: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 1uFsDl-0001Al-3p; Fri, 16 May 2025 10:23:17 +0000
Received: by outflank-mailman (input) for mailman id 986812;
 Fri, 16 May 2025 10:23:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsDj-0000kS-HI
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:23:15 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c5a53bcc-323f-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:23:13 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzNSw4kMszMQxhr2
 for ; Fri, 16 May 2025 10:23:12 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 e4369dd05760456da708e1454a2b2ce5; Fri, 16 May 2025 10: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" 
X-Inumbo-ID: c5a53bcc-323f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747390992; x=1747660992;
	bh=DandEhzp+qPKdWdpmRXBmMLVVVlG3pQoydJsD7Um6to=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=gtSQHzLaiFJmwd3fY/To9E6iJGVRkCHSG2ZuIkc0Op0kIZhCpmBL1FMtQ0RRzjGhT
	 +6UUlVSrIFt5X2KIvYJem9ub7n2DZlDuhjo4ql6GA8xRHMxof553+GlCluS5QT7h6A
	 uAyUug7ybmUkDsBm4N1YIY3ZNrGE0IxOoS+Dspjb5SdtRdHl1jQ0Fk2pg62/aCaMHV
	 BivaPSdUJ6LJKsmlFCCTv7nDmTBgyal8pQH9rcNerdOtaWGfrCdHVTJFa3u8MTMG8F
	 TwAu6wjYelUgpxgK6P4Jcxi6HNfdf960BJs9j2BwbFAPElaw/wxJGLc8QNR7DJeV+1
	 EU8LCBYPLwD9g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747390992; x=1747651492; i=teddy.astie@vates.tech;
	bh=DandEhzp+qPKdWdpmRXBmMLVVVlG3pQoydJsD7Um6to=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=OSzdryaztxGhQKUhl1b2SIM1J900Y41ZP6cTY31ujCh2PSc90ruH92ZAcYhmNwt6X
	 EFVQ6BHBq5pbchzf9BnN+isz7mIJ42WC15MGY9kXG6NWfmuxH+MF3xGVdw06ymVzHw
	 y1v4eSXDrTcKCWT8vjy8jzA1hUTXqMf8hgQoE3Z1/q9rYQM9MRlhAc8oZzimHQS3bh
	 /AeEAI4AxO8Ak83uE4vArIO6rY3QG15uXtW8Qgd2sB8pCjgP3Eym8Jj/1vVUzw/Vq2
	 sZoxH+KvWXD2uepKLDQMrdoNmafKPB9CtcCl1QCzPEaNp1wEXN0ZOpwNWNbYbqTE5J
	 +YDYgmVJNPwlw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2009/16]=20common:=20Introduce=20confidential=20computing=20infrastructure?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747390991298
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" 
Message-Id: <2bff74440483be3c59156257a60d632727a18582.1747312394.git.teddy.astie@vates.tech>
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.e4369dd05760456da708e1454a2b2ce5?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 10:23:12 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Introduce a subsystem that is used for future confidential computing
platforms. This subsystem manages and provides hooks for domain management
and exposes various informations for toolstack (COCO platform, supported
features, ...).

Add a domain creation flag to build a confidential computing guest.

Signed-off-by: Teddy Astie 
---
 xen/arch/x86/domain.c         |   4 +
 xen/arch/x86/hvm/hvm.c        |  10 ++-
 xen/common/Kconfig            |   5 ++
 xen/common/Makefile           |   1 +
 xen/common/coco.c             | 134 ++++++++++++++++++++++++++++++++++
 xen/common/domain.c           |  41 ++++++++++-
 xen/include/hypercall-defs.c  |   2 +
 xen/include/public/domctl.h   |   5 +-
 xen/include/public/hvm/coco.h |  65 +++++++++++++++++
 xen/include/public/xen.h      |   1 +
 xen/include/xen/coco.h        |  88 ++++++++++++++++++++++
 xen/include/xen/sched.h       |  10 +++
 12 files changed, 363 insertions(+), 3 deletions(-)
 create mode 100644 xen/common/coco.c
 create mode 100644 xen/include/public/hvm/coco.h
 create mode 100644 xen/include/xen/coco.h

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index f197dad4c0..a5783154ad 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -12,6 +12,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -948,6 +949,9 @@ void arch_domain_destroy(struct domain *d)
     free_xenheap_page(d->shared_info);
     cleanup_domain_irq_mapping(d);
 
+    if ( is_coco_domain(d) )
+        coco_domain_destroy(d);
+
     psr_domain_free(d);
 }
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 625ae2098b..e1bcf8e086 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -702,7 +703,11 @@ int hvm_domain_initialise(struct domain *d,
     if ( rc )
         goto fail2;
 
-    rc = hvm_asid_alloc(&d->arch.hvm.asid);
+    if ( is_coco_domain(d) && d->coco_ops && d->coco_ops->asid_alloc )
+        rc = d->coco_ops->asid_alloc(d, &d->arch.hvm.asid);
+    else
+        rc = hvm_asid_alloc(&d->arch.hvm.asid);
+
     if ( rc )
         goto fail2;
 
@@ -710,6 +715,9 @@ int hvm_domain_initialise(struct domain *d,
     if ( rc != 0 )
         goto fail2;
 
+    if ( is_coco_domain(d) )
+        coco_domain_initialise(d);
+
     return 0;
 
  fail2:
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6d43be2e6e..1ddb73e707 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -576,4 +576,9 @@ config BUDDY_ALLOCATOR_SIZE
 	  Amount of memory reserved for the buddy allocator to serve Xen heap,
 	  working alongside the colored one.
 
+config COCO
+	bool "Enable COnfidential COmputing support for guests" if EXPERT
+	default n
+	help
+	  Allows to run guests in private encrypted memory space.
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..4409510fc0 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_COCO) += coco.o
 obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
 obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
diff --git a/xen/common/coco.c b/xen/common/coco.c
new file mode 100644
index 0000000000..d9bd17628d
--- /dev/null
+++ b/xen/common/coco.c
@@ -0,0 +1,134 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * General confidential computing functions.
+ */
+ 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+static __ro_after_init struct coco_ops *coco_ops;
+__read_mostly struct coco_platform_status platform_status;
+
+void __init coco_register_ops(struct coco_ops *ops)
+{
+    coco_ops = ops;
+}
+
+int __init coco_init(void)
+{
+    int rc = 0;
+
+    if ( coco_ops )
+        printk("coco: Using '%s'\n", coco_ops->name);
+    else
+    {
+        printk("coco: No platform found\n");
+        return 0;
+    }
+
+    if ( coco_ops->init )
+    {
+        rc = coco_ops->init();
+        
+        if ( rc )
+        {
+            printk("coco: Unable to initialize coco platform (%d)", rc);
+            goto err;
+        }
+    }
+
+    rc = coco_ops->get_platform_status(&platform_status);
+    if ( rc )
+    {
+        printk("coco: Unable to get platform status\n");
+        goto err;
+    }
+
+    return 0;
+
+err:
+    /* Disable confidential computing if initialization failed. */
+    coco_ops = NULL;
+    return rc;
+}
+
+void coco_set_domain_ops(struct domain *d)
+{
+    ASSERT(is_coco_domain(d));
+
+    d->coco_ops = coco_ops->get_domain_ops(d);
+}
+
+int coco_prepare_initial_memory(struct domain *d, gfn_t gfn, size_t page_count)
+{
+    /* TODO: Check prepare_initial_memory constraints (no dangling mapping). */
+
+    if ( d->coco_ops->prepare_initial_mem )
+        return d->coco_ops->prepare_initial_mem(d, gfn, page_count);
+    
+    return 0;
+}
+
+long coco_op_prepare_initial_mem(struct coco_prepare_initial_mem arg)
+{
+    long rc = 0;
+    struct domain *d = get_domain_by_id(arg.domid);
+
+    if ( !d )
+        return -ENOENT;
+    
+    if ( !is_coco_domain(d) )
+    {
+        rc = -EOPNOTSUPP;
+        goto out;
+    }
+
+    rc = coco_prepare_initial_memory(d, arg.gfn, arg.count);
+
+out:
+    put_domain(d);
+    return rc;
+}
+
+long do_coco_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+    if ( !is_hardware_domain(current->domain) )
+        return -EPERM;
+
+    switch (cmd)
+    {
+        case XEN_COCO_platform_status:
+        {
+            if ( copy_to_guest(arg, &platform_status, 1) )
+                return -EFAULT;
+
+            return 0;
+        }
+        
+        case XEN_COCO_prepare_initial_mem:
+        {
+            struct coco_prepare_initial_mem prepare_initial_mem;
+
+            if ( copy_from_guest(&prepare_initial_mem, arg, 1) )
+                return -EFAULT;
+
+            return coco_op_prepare_initial_mem(prepare_initial_mem);
+        }
+
+        default:
+            return -ENOSYS;
+    }
+}
+
+__initcall(coco_init);
\ No newline at end of file
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..c29d6efd29 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -4,6 +4,7 @@
  * Generic domain-handling functions.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -716,17 +717,51 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
     bool hap = config->flags & XEN_DOMCTL_CDF_hap;
     bool iommu = config->flags & XEN_DOMCTL_CDF_iommu;
     bool vpmu = config->flags & XEN_DOMCTL_CDF_vpmu;
+    bool coco = config->flags & XEN_DOMCTL_CDF_coco;
 
     if ( config->flags &
          ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
            XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
            XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu |
-           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) )
+           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu | XEN_DOMCTL_CDF_coco) )
     {
         dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
         return -EINVAL;
     }
 
+    if ( coco )
+    {
+        if ( !IS_ENABLED(CONFIG_COCO) )
+        {
+            dprintk(XENLOG_INFO, "COCO support is compiled out\n");
+            return -EINVAL;
+        }
+
+        if ( !coco_is_supported() )
+        {
+            dprintk(XENLOG_INFO, "COCO is not available\n");
+            return -EINVAL;
+        }
+    
+        if ( !hvm )
+        {
+            dprintk(XENLOG_INFO, "COCO requested for non-HVM guest\n");
+            return -EINVAL;
+        }
+
+        if ( !hap )
+        {
+            dprintk(XENLOG_INFO, "COCO cannot work without HAP\n");
+            return -EINVAL;
+        }
+
+        if ( config->flags & XEN_DOMCTL_CDF_nested_virt )
+        {
+            dprintk(XENLOG_INFO, "Nested virtualization isn't supported with COCO\n");
+            return -EINVAL;
+        }
+    }
+
     if ( config->grant_opts & ~XEN_DOMCTL_GRANT_version_mask )
     {
         dprintk(XENLOG_INFO, "Unknown grant options %#x\n", config->grant_opts);
@@ -836,6 +871,9 @@ struct domain *domain_create(domid_t domid,
     /* Holding CDF_* internal flags. */
     d->cdf = flags;
 
+    if ( is_coco_domain(d) )
+        coco_set_domain_ops(d);
+
     TRACE_TIME(TRC_DOM0_DOM_ADD, d->domain_id);
 
     lock_profile_register_struct(LOCKPROF_TYPE_PERDOM, d, domid);
@@ -1617,6 +1655,7 @@ int domain_unpause_by_systemcontroller(struct domain *d)
     {
         d->creation_finished = true;
         arch_domain_creation_finished(d);
+        coco_domain_creation_finished(d); /* TODO: or before arch_* ? */
     }
 
     domain_unpause(d);
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 7720a29ade..6c01a9e395 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -209,6 +209,7 @@ hypfs_op(unsigned int cmd, const char *arg1, unsigned long arg2, void *arg3, uns
 #ifdef CONFIG_X86
 xenpmu_op(unsigned int op, xen_pmu_params_t *arg)
 #endif
+coco_op(unsigned int cmd, void *arg)
 
 #ifdef CONFIG_PV
 caller: pv64
@@ -295,5 +296,6 @@ mca                                do       do       -        -        -
 #ifndef CONFIG_PV_SHIM_EXCLUSIVE
 paging_domctl_cont                 do       do       do       do       -
 #endif
+coco_op                            do       do       do       do       do
 
 #endif /* !CPPCHECK */
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5b2063eed9..f4f69556b6 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -67,8 +67,11 @@ struct xen_domctl_createdomain {
 /* Should we expose the vPMU to the guest? */
 #define XEN_DOMCTL_CDF_vpmu           (1U << 7)
 
+#define _XEN_DOMCTL_CDF_coco         8
+#define XEN_DOMCTL_CDF_coco          (1U << _XEN_DOMCTL_CDF_coco)
+
 /* Max XEN_DOMCTL_CDF_* constant.  Used for ABI checking. */
-#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_vpmu
+#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_coco
 
     uint32_t flags;
 
diff --git a/xen/include/public/hvm/coco.h b/xen/include/public/hvm/coco.h
new file mode 100644
index 0000000000..2e23d91e12
--- /dev/null
+++ b/xen/include/public/hvm/coco.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: MIT */
+#ifndef __XEN_PUBLIC_HVM_COCO_H__
+#define __XEN_PUBLIC_HVM_COCO_H__
+
+#include "../xen.h"
+
+#define XEN_COCO_platform_status 0
+
+/**
+ * XEN_COCO_platform_status: Get the status of confidential computing platform.
+ *
+ * Query informations regarding the current confidential computing platform.
+ *
+ * Confidential computing is supposed working as long as COCO_STATUS_FLAG_SUPPORTED bit
+ * is set, and additionally security-supported only if COCO_STATUS_FLAG_UNSAFE bit
+ * is cleared.
+ *
+ * If COCO_PLATFORM_FLAG_UNSAFE is set but COCO_PLATFORM_FLAG_SUPPORTED is not,
+ * then confidential computing is explicitly present but intentionally disabled
+ * or forbidden by policy.
+ */
+struct coco_platform_status {
+#define COCO_PLATFORM_none        0 /* None */
+#define COCO_PLATFORM_amd_sev     1 /* AMD Secure Encrypted Virtualization */
+#define COCO_PLATFORM_intel_tdx   2 /* Intel Trust Domain Extensions */
+#define COCO_PLATFORM_arm_rme     3 /* ARM Realm Management Extension */
+    uint32_t platform; /* OUT */
+
+#define COCO_PLATFORM_FLAG_sev_es  (1 << 0) /* AMD SEV Encrypted State */
+#define COCO_PLATFORM_FLAG_sev_snp (1 << 1) /* AMD SEV Secure Nested Paging */
+#define COCO_PLATFORM_FLAG_sev_tio (1 << 2) /* AMD SEV Trusted I/O */
+    uint32_t platform_flags; /* OUT */
+
+#define COCO_STATUS_FLAG_supported (1 << 0) /* Confidential computing is supported and usable */
+#define COCO_STATUS_FLAG_unsafe    (1 << 1) /* Confidential computing is unsafe (e.g debug mode) */
+    uint32_t flags;    /* OUT */
+    uint32_t features; /* OUT */
+
+    uint32_t version_major; /* OUT */
+    uint32_t version_minor; /* OUT */
+};
+typedef struct coco_platform_status coco_platform_status_t;
+DEFINE_XEN_GUEST_HANDLE(coco_platform_status_t);
+
+#define XEN_COCO_prepare_initial_mem 1
+
+/**
+ * XEN_COCO_prepare_initial_mem: Prepare early memory pages of a guest
+ * 
+ * During guest construction, the confidential computing platform may require memory
+ * to be prepared (e.g., encrypted) before the guest is started.
+ * 
+ * After preparation, any further access to these pages is invalid, as they may be
+ * encrypted, sealed, or tracked by the platform.
+ */
+struct coco_prepare_initial_mem {
+    domid_t domid;      /* IN */
+    uint16_t _rsvd[3];  /* ZERO */
+    uint64_t gfn;       /* IN */
+    uint64_t count;     /* IN */
+};
+typedef struct coco_prepare_initial_mem coco_prepare_initial_mem_t;
+DEFINE_XEN_GUEST_HANDLE(coco_prepare_initial_mem_t);
+
+#endif /* __XEN_PUBLIC_HVM_COCO_H__ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 82b9c05a76..e656d6f617 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -118,6 +118,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_xenpmu_op            40
 #define __HYPERVISOR_dm_op                41
 #define __HYPERVISOR_hypfs_op             42
+#define __HYPERVISOR_coco_op              43
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/coco.h b/xen/include/xen/coco.h
new file mode 100644
index 0000000000..2ae43995ec
--- /dev/null
+++ b/xen/include/xen/coco.h
@@ -0,0 +1,88 @@
+#ifndef _XEN_COCO_H
+#define _XEN_COCO_H
+
+#include 
+
+#include 
+#include 
+
+#include 
+
+extern __read_mostly struct coco_platform_status platform_status;
+
+struct coco_domain_ops {
+    int (*prepare_initial_mem)(struct domain *d, gfn_t gfn, size_t page_count);
+    /* domain_creation_finished, ... */    
+
+    /* HVM domain hooks */
+    int (*domain_initialise)(struct domain *d);
+    int (*domain_creation_finished)(struct domain *d);
+    void (*domain_destroy)(struct domain *d);
+
+#ifdef CONFIG_X86
+    /* COCO-specific ASID allocation logic */
+    int (*asid_alloc)(struct domain *d, struct hvm_asid *asid);
+#endif
+};
+
+struct coco_ops {
+    const char *name;
+    
+    int (*init)(void);
+    int (*get_platform_status)(coco_platform_status_t *status);
+    struct coco_domain_ops *(*get_domain_ops)(struct domain *d);
+};
+
+void __init coco_register_ops(struct coco_ops *ops);
+int __init coco_init(void);
+void coco_set_domain_ops(struct domain *d);
+
+#ifdef CONFIG_COCO
+static inline bool coco_is_supported(void)
+{
+    return evaluate_nospec(platform_status.flags & COCO_STATUS_FLAG_supported);
+}
+
+static inline int coco_domain_initialise(struct domain *d)
+{
+    if ( d->coco_ops && d->coco_ops->domain_initialise )
+        return d->coco_ops->domain_initialise(d);
+
+    return 0;
+}
+
+static inline int coco_domain_creation_finished(struct domain *d)
+{
+    if ( d->coco_ops && d->coco_ops->domain_creation_finished )
+        return d->coco_ops->domain_creation_finished(d);
+
+    return 0;
+}
+
+static inline void coco_domain_destroy(struct domain *d)
+{
+    if ( d->coco_ops && d->coco_ops->domain_destroy )
+        d->coco_ops->domain_destroy(d);
+}
+#else
+static inline bool coco_is_supported(void)
+{
+    return false;
+}
+
+static inline int coco_domain_initialise(struct domain *d)
+{
+    return 0;
+}
+
+static inline int coco_domain_creation_finished(struct domain *d)
+{
+    return 0;
+}
+
+static inline void coco_domain_destroy(struct domain *d)
+{
+}
+#endif
+
+#endif /* _XEN_COCO_H */
\ No newline at end of file
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index f2f5a98534..c57bedc30a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -630,6 +630,10 @@ struct domain
     struct argo_domain *argo;
 #endif
 
+#ifdef CONFIG_COCO
+    struct coco_domain_ops *coco_ops;
+#endif
+
     /*
      * Continuation information for domain_teardown().  All fields entirely
      * private.
@@ -1198,6 +1202,12 @@ static always_inline bool is_hvm_vcpu(const struct vcpu *v)
     return is_hvm_domain(v->domain);
 }
 
+static always_inline bool is_coco_domain(const struct domain *d)
+{
+    return IS_ENABLED(CONFIG_COCO) &&
+        evaluate_nospec(d->options & XEN_DOMCTL_CDF_coco);
+}
+
 static always_inline bool hap_enabled(const struct domain *d)
 {
     /* sanitise_domain_config() rejects HAP && !HVM */
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 10:30:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:30:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986837.1372349 (Exim 4.92)
	(envelope-from )
	id 1uFsKs-000353-TS; Fri, 16 May 2025 10:30:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986837.1372349; Fri, 16 May 2025 10: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 1uFsKs-00034w-Ql; Fri, 16 May 2025 10:30:38 +0000
Received: by outflank-mailman (input) for mailman id 986837;
 Fri, 16 May 2025 10:30:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsKr-00034q-Ht
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:30:37 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c88a9ebb-3240-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:30:27 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a0af41faa5so1060028f8f.2
 for ; Fri, 16 May 2025 03:30:27 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca4d0fasm2461191f8f.8.2025.05.16.03.30.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 03:30: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" 
X-Inumbo-ID: c88a9ebb-3240-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747391427; x=1747996227; darn=lists.xenproject.org;
        h=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;
        bh=jGFAzIqle5bFXnLYqA97v+UXHOVGWk8Y1pP980RKSzI=;
        b=YGf/mEfZX5KIXifqJtcUgj9w0rH4aM1JVdT99u0MPYstzylckbG2SdB9Stn1kVwgho
         rX+sPRIQTKgs3FvaqnOKR443qzolr0+2ZrCaGPi+U7478wAQC74FBvWr2lRL4mOmcKRs
         vMrQhTdAqCZjGf+GLk9VazdCOAUx/CKOWgrS9CmvA08MP8nFZff/ZHEWDxu7GG2WcyU1
         WHV4jBkvHk71UyYPBvavFQ1OmmNqsgH9Fsm8QiQ4PfX5KFmM0GW9flyDE5ko7lqzoxT/
         yzonOMBRAz5sxyM6Il6R86l/Lgpc9kyee0mPMyVgZGwCsjSMcxltUTwujXbaSr9s+ldg
         WF9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747391427; x=1747996227;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=jGFAzIqle5bFXnLYqA97v+UXHOVGWk8Y1pP980RKSzI=;
        b=KudjAxVbsj+7ra85c6vaxTxghWYAgMMX/4DPZghKT8wwnqslklrFt+FJp/A5jHrdO7
         kfyhFuK7gNTmTJHBYzhr06f2rcThTpT3bnk0KBzpf95YajtsW0jiy2HSVtPyYOoh4L73
         tAzWPJ+YlHYEzF3YL1DRh149HT0ZMi5fWrJOqh9mOOxh8vz5gp7YEwwj1Aa3T3orojP9
         lPCeqBcj6xqCOaZNDp1hLggLO2j40RUNTVVbLAHMlX9rvjN84ILMk6BAjJFzLb07bFHR
         nQnNBg6O462T3VcpuO528HT7PMjq6w8zWQaBWvJ8Jy9pWYvQlf8pdZ5cznUpQ5bNXRmW
         VtHw==
X-Forwarded-Encrypted: i=1; AJvYcCW0rYEUF8k9oWr1iYZ37lbDCzA495vYRYolVobVLsMWmQZTBhuZulCUrDIxnZxquRWDkY3RZHKmq0s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyVV+V6ImkJPb9W/36KF4oxoq6xB5lgV1MynGmVVPwwJxAWULpQ
	gYK4L+grruirPqDc8Z1R2lAjSgnVueKS3gjT7169NZiIMYqC/mV3qse7
X-Gm-Gg: ASbGncuq+LuIKQnW3/J0aKIOybjc1jz2MwHNGOUbpKO1qkN0cmN16so7nLyYNbDjQx0
	L1DfwGZOXoWXQvQoxvls2va7yoD0Pswm1QeuVqjIyhCDC5jdg9SCo8V/9BRlj4VWfTT8NoCl6T2
	JQxt2Mo2h2W6yslzPIIZsjy58monnAAT/J86b+8uNrl2eNOFtvDE3g0A2v2KqQiNl0TRmYdQIDi
	6xjCt68Cn+OB2DZRpn7cTORhMB46HhkS+tm4gC81+pIKVjyrhVh0rRmqIngkoI3VNozk2CqF9Ix
	xF0ILfcSWhEF6B3vZm7jrPXG7GTk9QzqpSWEYVHtXUkd6A/7Keanwb7XB6b9RESgqe155WAIbU9
	Qe8yZWj6MQ6NnELJCh66IPWoH
X-Google-Smtp-Source: AGHT+IHTl4/QVNzyZEu/4YGFgfak5x2zXUD0cAzGm9ePLh/U0buHDQdhryLy0/sOIX0wQ70FeM1UEQ==
X-Received: by 2002:a05:6000:2af:b0:3a1:f5cf:9553 with SMTP id ffacd0b85a97d-3a35fe6628amr1700349f8f.6.1747391426445;
        Fri, 16 May 2025 03:30:26 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------DoFTsLVLewXu9u8IxN10XzQx"
Message-ID: 
Date: Fri, 16 May 2025 12:30:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/16] xen/riscv: add ioremap_*() variants using
 ioremap_attr()
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <0258c1ac04a73b7d3f9f849507539a329b2998e3.1746530883.git.oleksii.kurochko@gmail.com>
 <0fbe380e-2011-4238-9847-a007c754af6f@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <0fbe380e-2011-4238-9847-a007c754af6f@suse.com>

This is a multi-part message in MIME format.
--------------DoFTsLVLewXu9u8IxN10XzQx
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/14/25 4:32 PM, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> @@ -583,3 +584,36 @@ void *__init arch_vmap_virt_end(void)
>>   {
>>       return (void *)(VMAP_VIRT_START + VMAP_VIRT_SIZE);
>>   }
>> +
>> +static void *ioremap_attr(paddr_t start, size_t len, pte_attr_t attributes)
>> +{
>> +    mfn_t mfn = _mfn(PFN_DOWN(start));
>> +    unsigned int offs = start & (PAGE_SIZE - 1);
>> +    unsigned int nr = PFN_UP(offs + len);
>> +    void *ptr = __vmap(&mfn, nr, 1, 1, attributes, VMAP_DEFAULT);
>> +
>> +    if ( ptr == NULL )
>> +        return NULL;
>> +
>> +    return ptr + offs;
>> +}
>> +
>> +void __iomem *ioremap_nocache(paddr_t start, size_t len)
>> +{
>> +    return ioremap_attr(start, len, PAGE_HYPERVISOR_NOCACHE);
>> +}
> Why do you need both this and ...
>
>> +void __iomem *ioremap_cache(paddr_t start, size_t len)
>> +{
>> +    return ioremap_attr(start, len, PAGE_HYPERVISOR);
>> +}
>> +
>> +void __iomem *ioremap_wc(paddr_t start, size_t len)
>> +{
>> +    return ioremap_attr(start, len, PAGE_HYPERVISOR_WC);
>> +}
>> +
>> +void *ioremap(paddr_t pa, size_t len)
>> +{
>> +    return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
>> +}
> ... this? And why's the 1st parameter named differently for this last
> one? Can't they all be in sync in this regard?

Originally, I thought|ioremap_nocache()| was needed because it is used in
common code. However, I now realize that the calls to|ioremap_nocache()|
in|xen/drivers/char| are also ARM-specific. I assume all the
UART drivers currently using|ioremap_nocache|() are intended for ARM.

I'll drop|ioremap_nocache()| for RISC-V, and I think it makes sense to
create a separate patch to clean this up for ARM as well.

~ Oleksii

--------------DoFTsLVLewXu9u8IxN10XzQx
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/14/25 4:32 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    @@ -583,3 +584,36 @@ void *__init arch_vmap_virt_end(void)
 {
     return (void *)(VMAP_VIRT_START + VMAP_VIRT_SIZE);
 }
+
+static void *ioremap_attr(paddr_t start, size_t len, pte_attr_t attributes)
+{
+    mfn_t mfn = _mfn(PFN_DOWN(start));
+    unsigned int offs = start & (PAGE_SIZE - 1);
+    unsigned int nr = PFN_UP(offs + len);
+    void *ptr = __vmap(&mfn, nr, 1, 1, attributes, VMAP_DEFAULT);
+
+    if ( ptr == NULL )
+        return NULL;
+
+    return ptr + offs;
+}
+
+void __iomem *ioremap_nocache(paddr_t start, size_t len)
+{
+    return ioremap_attr(start, len, PAGE_HYPERVISOR_NOCACHE);
+}

    
      
    
      
    Why do you need both this and ...


    
      
    
        
    +void __iomem *ioremap_cache(paddr_t start, size_t len)
+{
+    return ioremap_attr(start, len, PAGE_HYPERVISOR);
+}
+
+void __iomem *ioremap_wc(paddr_t start, size_t len)
+{
+    return ioremap_attr(start, len, PAGE_HYPERVISOR_WC);
+}
+
+void *ioremap(paddr_t pa, size_t len)
+{
+    return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
+}

    
      
    
      
    ... this? And why's the 1st parameter named differently for this last
one? Can't they all be in sync in this regard?
    
    
    
    
    Originally, I thought ioremap_nocache() was needed because it is used in
common code. However, I now realize that the calls to ioremap_nocache()
in xen/drivers/char are also ARM-specific. I assume all the
UART drivers currently using ioremap_nocache() are intended for ARM.
    
    
    I'll drop ioremap_nocache() for RISC-V, and I think it makes sense to
create a separate patch to clean this up for ARM as well.

~ Oleksii
    
  


--------------DoFTsLVLewXu9u8IxN10XzQx--


From xen-devel-bounces@lists.xenproject.org Fri May 16 10:31:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:31:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986846.1372359 (Exim 4.92)
	(envelope-from )
	id 1uFsLR-0003nz-84; Fri, 16 May 2025 10:31:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986846.1372359; Fri, 16 May 2025 10:31:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFsLR-0003ns-52; Fri, 16 May 2025 10:31:13 +0000
Received: by outflank-mailman (input) for mailman id 986846;
 Fri, 16 May 2025 10:31:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsER-0000kS-Md
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:23:59 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e002a537-323f-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:23:57 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzNTm6PzCzMQxhrj
 for ; Fri, 16 May 2025 10:23:56 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 a32b69adad444adc87b2b2c102ecc179; Fri, 16 May 2025 10:23: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" 
X-Inumbo-ID: e002a537-323f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747391036; x=1747661036;
	bh=GO5Dri+xVh1Y4JynkAC/L1FcSze9E66ZA2NqARyadRc=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=CTsn8QblBtzpLm3VnaNNXup9lAPub+fkhhWKiAhhTfvNWKRnXm2TQzfStGqLP1rSU
	 YwepmnGjvEe9hSf9gVjxCnMeODo5XCv0i6hXtZiYK2gjmtWqpYE+sHNjBkebOI0+kC
	 RejD5hpi2d4QqZ+Iv3POZfuLj7KYHQBx3EI4XP0N2+Q/aqRsyisjygaAfkX+VeXFH1
	 zPa7DBvlcnfIzI31UO6K8LkPsxb6EeLDkXxkJf+TjH1AG0Fq0MCGOw1OpTHrDqIjr+
	 jUHKxnTVxT4zIJDolYrlTv/QXYoYtdzVMEnqWoRDNPoCIy2XyoIrMdf25V1U8An48p
	 aqbChmRJttnWw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747391036; x=1747651536; i=teddy.astie@vates.tech;
	bh=GO5Dri+xVh1Y4JynkAC/L1FcSze9E66ZA2NqARyadRc=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=KmfPe3kbcFhlEze4gm87u0qrqVZ/Q7Jzz6D8zsaXa1rhkaRrsckO0GxfoL8crxXsm
	 MLlr8lGVAEumN3uvJldnU4AVj9GfYBO+Wil4oyatq/Pach06Qm0nbxurs9F8KwSrlL
	 RJ20DXPUEhByd6WqvQBlcx5w45cXs6hxdxHPn27xzs+h5S0ktcReCH8JcHp9vJxRpr
	 nS8WA01vwGk38RyR6eiGjJIFthakTz9nI0Als0NXasbvhlk+L3pW4pHTMy0RT8HQGB
	 TRQmlMQEiGMbuYQIjPLvuY1IHfVOjfGCZJ53gDqwxItka4wNvQfuHURXdYqmphtJfQ
	 V1gxZpKawphOw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2010/16]=20xl/coco:=20Introduce=20confidential=20computing=20support?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747391035719
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Anthony PERARD" , "Juergen Gross" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Christian Lindig" , "David Scott" , "Vaishali Thakkar" 
Message-Id: <85b52eb462e171b420d6c8e7c748af763504e9f2.1747312394.git.teddy.astie@vates.tech>
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.a32b69adad444adc87b2b2c102ecc179?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 10:23:56 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

From: Vaishali Thakkar 

Signed-off-by: Vaishali Thakkar 
Signed-off-by: Teddy Astie 
---
 tools/include/libxl.h            |  5 ++++
 tools/include/xenctrl.h          |  4 ++++
 tools/include/xenguest.h         |  1 +
 tools/libs/ctrl/xc_domain.c      | 36 +++++++++++++++++++++++++++++
 tools/libs/guest/Makefile.common |  2 ++
 tools/libs/guest/xg_dom_boot.c   | 33 +++++++++++++++++++++++++++
 tools/libs/guest/xg_dom_coco.c   | 35 ++++++++++++++++++++++++++++
 tools/libs/guest/xg_dom_coco.h   | 39 ++++++++++++++++++++++++++++++++
 tools/libs/guest/xg_dom_x86.c    |  1 +
 tools/libs/light/libxl_cpuid.c   |  1 +
 tools/libs/light/libxl_create.c  |  4 ++++
 tools/libs/light/libxl_dom.c     |  1 +
 tools/libs/light/libxl_types.idl |  1 +
 tools/libs/util/libxlu_disk_l.c  | 13 ++++-------
 tools/libs/util/libxlu_disk_l.h  |  7 ++----
 tools/misc/xen-cpuid.c           |  1 +
 tools/ocaml/libs/xc/xenctrl.ml   |  1 +
 tools/ocaml/libs/xc/xenctrl.mli  |  1 +
 tools/xl/xl_parse.c              |  2 ++
 19 files changed, 175 insertions(+), 13 deletions(-)
 create mode 100644 tools/libs/guest/xg_dom_coco.c
 create mode 100644 tools/libs/guest/xg_dom_coco.h

diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index b7ad7735ca..e75179b604 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -178,6 +178,11 @@
  */
 #define LIBXL_HAVE_BUILDINFO_EVENT_CHANNELS 1
 
+/*
+ * The libxl_domain_build_info has the coco field.
+*/
+#define LIBXL_HAVE_BUILDINFO_COCO 1
+
 /*
  * libxl_domain_build_info has the u.hvm.ms_vm_genid field.
  */
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 4955981231..aae228da44 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xentoollog.h"
 #include "xen-barrier.h"
@@ -1682,6 +1683,9 @@ int xc_hvm_param_get(xc_interface *handle, uint32_t dom, uint32_t param, uint64_
 int xc_set_hvm_param(xc_interface *handle, uint32_t dom, int param, unsigned long value);
 int xc_get_hvm_param(xc_interface *handle, uint32_t dom, int param, unsigned long *value);
 
+int xc_coco_platform_status(xc_interface *handle, coco_platform_status_t *status);
+int xc_coco_prepare_initial_mem(xc_interface *handle, coco_prepare_initial_mem_t *cmd);
+
 /* HVM guest pass-through */
 int xc_assign_device(xc_interface *xch,
                      uint32_t domid,
diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h
index e01f494b77..9d36fa5665 100644
--- a/tools/include/xenguest.h
+++ b/tools/include/xenguest.h
@@ -219,6 +219,7 @@ struct xc_dom_image {
     xen_paddr_t lowmem_end;
     xen_paddr_t highmem_end;
     xen_pfn_t vga_hole_size;
+    bool coco; /* 1 if this is a confidential computing guest, 0 otherwise */
 
     /* If unset disables the setup of the IOREQ pages. */
     bool device_model;
diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
index 2ddc3f4f42..66b6c146f4 100644
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -20,8 +20,10 @@
  */
 
 #include "xc_private.h"
+#include "xenctrl.h"
 #include 
 #include 
+#include 
 
 int xc_domain_create(xc_interface *xch, uint32_t *pdomid,
                      struct xen_domctl_createdomain *config)
@@ -1496,6 +1498,40 @@ int xc_get_hvm_param(xc_interface *handle, uint32_t dom, int param, unsigned lon
     return 0;
 }
 
+int xc_coco_platform_status(xc_interface *handle, coco_platform_status_t *status)
+{
+    DECLARE_HYPERCALL_BUFFER(coco_platform_status_t, arg);
+    int rc;
+
+    arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
+    if ( arg == NULL )
+        return -1;
+    memcpy(arg, status, sizeof(coco_platform_status_t));
+
+    rc = xencall2(handle->xcall, __HYPERVISOR_coco_op, XEN_COCO_platform_status,
+                  HYPERCALL_BUFFER_AS_ARG(arg));
+
+    xc_hypercall_buffer_free(handle, arg);
+    return rc;
+}
+
+int xc_coco_prepare_initial_mem(xc_interface *handle, coco_prepare_initial_mem_t *cmd)
+{
+    DECLARE_HYPERCALL_BUFFER(coco_prepare_initial_mem_t, arg);
+    int rc;
+
+    arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
+    if ( arg == NULL )
+        return -1;
+    memcpy(arg, cmd, sizeof(coco_prepare_initial_mem_t));
+
+    rc = xencall2(handle->xcall, __HYPERVISOR_coco_op, XEN_COCO_prepare_initial_mem,
+                  HYPERCALL_BUFFER_AS_ARG(arg));
+
+    xc_hypercall_buffer_free(handle, arg);
+    return rc;
+}
+
 int xc_domain_setdebugging(xc_interface *xch,
                            uint32_t domid,
                            unsigned int enable)
diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.common
index a026a2f662..64ede46a05 100644
--- a/tools/libs/guest/Makefile.common
+++ b/tools/libs/guest/Makefile.common
@@ -41,6 +41,8 @@ endif
 # new domain builder
 OBJS-y                 += xg_dom_core.o
 OBJS-y                 += xg_dom_boot.o
+# TODO: add something like CONFIG_COCO ?
+OBJS-y                 += xg_dom_coco.o
 OBJS-y                 += xg_dom_elfloader.o
 OBJS-$(CONFIG_X86)     += xg_dom_bzimageloader.o
 OBJS-$(CONFIG_X86)     += xg_dom_decompress_lz4.o
diff --git a/tools/libs/guest/xg_dom_boot.c b/tools/libs/guest/xg_dom_boot.c
index 5c7e12221d..6566784161 100644
--- a/tools/libs/guest/xg_dom_boot.c
+++ b/tools/libs/guest/xg_dom_boot.c
@@ -32,9 +32,13 @@
 
 #include "xg_private.h"
 #include "xg_core.h"
+#include "xg_dom_coco.h"
 #include 
 #include 
 
+#define round_pgup(_p)    (((_p)+(PAGE_SIZE_X86-1))&PAGE_MASK_X86)
+#define round_pgdown(_p)  ((_p)&PAGE_MASK_X86)
+
 /* ------------------------------------------------------------------------ */
 
 static int setup_hypercall_page(struct xc_dom_image *dom)
@@ -201,6 +205,35 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     if ( (rc = dom->arch_hooks->bootlate(dom)) != 0 )
         return rc;
 
+    // Encrypt domain pages
+    if ( dom->coco )
+    {
+        struct xc_dom_seg initrd_seg = {
+            .pfn = dom->initrd_start >> XC_DOM_PAGE_SHIFT(dom),
+            .pages = dom->initrd_len >> XC_DOM_PAGE_SHIFT(dom)
+        };
+
+        if ( (rc = xg_dom_coco_encrypt_seg(dom->xch, dom, dom->kernel_seg, "kernel") != 0) )
+            return rc;
+        if ( initrd_seg.pages && (rc = xg_dom_coco_encrypt_seg(dom->xch, dom, initrd_seg, "ramdisk") != 0) )
+            return rc;
+        if ( (rc = xg_dom_coco_encrypt_seg(dom->xch, dom, dom->start_info_seg, "start_info") != 0) )
+            return rc;
+        
+        for ( int i = 0; i < MAX_ACPI_MODULES; i++ )
+        {
+            struct xc_dom_seg seg;
+            seg.pfn = dom->acpi_modules[i].guest_addr_out >> XC_DOM_PAGE_SHIFT(dom);
+            seg.pages = round_pgup(dom->acpi_modules[i].length) >> XC_DOM_PAGE_SHIFT(dom);
+
+            if ( !seg.pfn || !seg.pages )
+                continue;
+
+            if ( (rc = xg_dom_coco_encrypt_seg(dom->xch, dom, seg, "acpi module")) != 0 )
+                return rc;
+        }
+    }
+
     /* let the vm run */
     if ( (rc = dom->arch_hooks->vcpu(dom)) != 0 )
         return rc;
diff --git a/tools/libs/guest/xg_dom_coco.c b/tools/libs/guest/xg_dom_coco.c
new file mode 100644
index 0000000000..f47b59fa49
--- /dev/null
+++ b/tools/libs/guest/xg_dom_coco.c
@@ -0,0 +1,35 @@
+/*
+ * Confidential computing support.
+ * Copyright (c) 2024 Teddy Astie 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ */
+
+#include "xg_private.h"
+#include "xenctrl.h"
+#include "xg_dom_coco.h"
+
+int xg_dom_coco_encrypt_seg(xc_interface *xch, struct xc_dom_image *dom,
+                            struct xc_dom_seg seg, const char *name)
+{
+    coco_prepare_initial_mem_t cmd;
+    DPRINTF("coco: Encrypting pfn:[%"PRI_xen_pfn"-%"PRI_xen_pfn"] (%s)\n",
+            seg.pfn, seg.pfn + seg.pages, name);
+    
+    cmd.domid = dom->guest_domid;
+    cmd.gfn = seg.pfn;
+    cmd.count = seg.pages;
+    
+    return xc_coco_prepare_initial_mem(xch, &cmd);
+}
\ No newline at end of file
diff --git a/tools/libs/guest/xg_dom_coco.h b/tools/libs/guest/xg_dom_coco.h
new file mode 100644
index 0000000000..eac0fa66e3
--- /dev/null
+++ b/tools/libs/guest/xg_dom_coco.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2006 Isaku Yamahata 
+ *                    VA Linux Systems Japan K.K.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ *
+ */
+
+#ifndef XC_DOM_COCO_H
+#define XC_DOM_COCO_H
+
+#include "xg_private.h"
+#include "xenctrl.h"
+
+int xg_dom_coco_encrypt_seg(xc_interface *xch, struct xc_dom_image *dom,
+                            struct xc_dom_seg seg, const char *name);
+
+#endif /* XC_DOM_COCO_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libs/guest/xg_dom_x86.c b/tools/libs/guest/xg_dom_x86.c
index cba01384ae..93407bf192 100644
--- a/tools/libs/guest/xg_dom_x86.c
+++ b/tools/libs/guest/xg_dom_x86.c
@@ -103,6 +103,7 @@ struct xc_dom_image_x86 {
 #define MAPPING_MAX 2
     struct xc_dom_x86_mapping maps[MAPPING_MAX];
     const struct xc_dom_params *params;
+    bool coco;
 
     /* PV: Pointer to the in-guest P2M. */
     void *p2m_guest;
diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index 063fe86eb7..9891c42a5b 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -342,6 +342,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *policy, const char* str)
         CPUID_ENTRY(0x00000007,  1, CPUID_REG_EDX),
         MSR_ENTRY(0x10a, CPUID_REG_EAX),
         MSR_ENTRY(0x10a, CPUID_REG_EDX),
+        CPUID_ENTRY(0x8000001f, NA, CPUID_REG_EAX),
 #undef MSR_ENTRY
 #undef CPUID_ENTRY
     };
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index e03599ea99..185f7946f4 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -93,6 +93,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 
     libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
     libxl_defbool_setdefault(&b_info->vpmu, false);
+    libxl_defbool_setdefault(&b_info->coco, false);
 
     if (libxl_defbool_val(b_info->device_model_stubdomain) &&
         !b_info->device_model_ssidref)
@@ -667,6 +668,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
         if (libxl_defbool_val(b_info->vpmu))
             create.flags |= XEN_DOMCTL_CDF_vpmu;
 
+        if (libxl_defbool_val(b_info->coco))
+            create.flags |= XEN_DOMCTL_CDF_coco;
+
         assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
         LOG(DETAIL, "passthrough: %s",
             libxl_passthrough_to_string(info->passthrough));
diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
index 94fef37401..778dac2286 100644
--- a/tools/libs/light/libxl_dom.c
+++ b/tools/libs/light/libxl_dom.c
@@ -1081,6 +1081,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
     }
 
     dom->container_type = XC_DOM_HVM_CONTAINER;
+    dom->coco = libxl_defbool_val(info->coco);
 
     /* The params from the configuration file are in Mb, which are then
      * multiplied by 1 Kb. This was then divided off when calling
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 9bb2969931..bb27e27148 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -637,6 +637,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("nested_hvm",       libxl_defbool),
     ("apic",             libxl_defbool),
     ("dm_restrict",      libxl_defbool),
+    ("coco",             libxl_defbool),
     ("tee",              libxl_tee_type),
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
diff --git a/tools/libs/util/libxlu_disk_l.c b/tools/libs/util/libxlu_disk_l.c
index 0c180fff52..4924162a51 100644
--- a/tools/libs/util/libxlu_disk_l.c
+++ b/tools/libs/util/libxlu_disk_l.c
@@ -1,10 +1,7 @@
 #line 1 "libxlu_disk_l.c"
-#line 31 "libxlu_disk_l.l"
 #define _GNU_SOURCE
 
-
-
-#line 7 "libxlu_disk_l.c"
+#line 4 "libxlu_disk_l.c"
 
 #define  YY_INT_ALIGNED short int
 
@@ -1257,9 +1254,9 @@ static int vdev_and_devtype(DiskParseContext *dpc, char *str) {
 #undef DPC /* needs to be defined differently the actual lexer */
 #define DPC ((DiskParseContext*)yyextra)
 
-#line 1260 "libxlu_disk_l.c"
+#line 1257 "libxlu_disk_l.c"
 
-#line 1262 "libxlu_disk_l.c"
+#line 1259 "libxlu_disk_l.c"
 
 #define INITIAL 0
 #define LEXERR 1
@@ -1541,7 +1538,7 @@ YY_DECL
 #line 188 "libxlu_disk_l.l"
  /*----- the scanner rules which do the parsing -----*/
 
-#line 1544 "libxlu_disk_l.c"
+#line 1541 "libxlu_disk_l.c"
 
 	while ( /*CONSTCOND*/1 )		/* loops until end-of-file is reached */
 		{
@@ -1920,7 +1917,7 @@ YY_RULE_SETUP
 #line 306 "libxlu_disk_l.l"
 YY_FATAL_ERROR( "flex scanner jammed" );
 	YY_BREAK
-#line 1923 "libxlu_disk_l.c"
+#line 1920 "libxlu_disk_l.c"
 			case YY_STATE_EOF(INITIAL):
 			case YY_STATE_EOF(LEXERR):
 				yyterminate();
diff --git a/tools/libs/util/libxlu_disk_l.h b/tools/libs/util/libxlu_disk_l.h
index c868422568..027fd96c49 100644
--- a/tools/libs/util/libxlu_disk_l.h
+++ b/tools/libs/util/libxlu_disk_l.h
@@ -3,12 +3,9 @@
 #define xlu__disk_yyIN_HEADER 1
 
 #line 5 "libxlu_disk_l.h"
-#line 31 "libxlu_disk_l.l"
 #define _GNU_SOURCE
 
-
-
-#line 11 "libxlu_disk_l.h"
+#line 8 "libxlu_disk_l.h"
 
 #define  YY_INT_ALIGNED short int
 
@@ -699,6 +696,6 @@ extern int yylex (yyscan_t yyscanner);
 
 #line 306 "libxlu_disk_l.l"
 
-#line 702 "libxlu_disk_l.h"
+#line 699 "libxlu_disk_l.h"
 #undef xlu__disk_yyIN_HEADER
 #endif /* xlu__disk_yyHEADER_H */
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 4c4593528d..10a2e603e9 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -37,6 +37,7 @@ static const struct {
     { "CPUID 0x00000007:1.edx",     "7d1" },
     { "MSR_ARCH_CAPS.lo",         "m10Al" },
     { "MSR_ARCH_CAPS.hi",         "m10Ah" },
+    { "CPUID 0x8000001f.eax",      "e1fa" },
 };
 
 #define COL_ALIGN "24"
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 2690f9a923..256adf0054 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -70,6 +70,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_COCO
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index febbe1f6ae..9ca55af05a 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -63,6 +63,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_COCO
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 089a88935a..0ddec0815b 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2993,6 +2993,8 @@ skip_usbdev:
 
     xlu_cfg_get_defbool(config, "vpmu", &b_info->vpmu, 0);
 
+    xlu_cfg_get_defbool(config, "coco", &b_info->coco, 0);
+
     xlu_cfg_destroy(config);
 }
 
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 10:31:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:31:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986848.1372369 (Exim 4.92)
	(envelope-from )
	id 1uFsLZ-00047l-Gl; Fri, 16 May 2025 10:31:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986848.1372369; Fri, 16 May 2025 10: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 1uFsLZ-00047c-Cp; Fri, 16 May 2025 10:31:21 +0000
Received: by outflank-mailman (input) for mailman id 986848;
 Fri, 16 May 2025 10:31:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsF8-0000kS-Qw
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:24:42 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f9c17d21-323f-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:24:41 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzNVc0flkzMQxhSc
 for ; Fri, 16 May 2025 10:24:40 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 55be2ee1b05f4c71bac5a8b138fad311; Fri, 16 May 2025 10:24: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" 
X-Inumbo-ID: f9c17d21-323f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747391080; x=1747661080;
	bh=rmMyFtnQQP/M6lJv+2OTm80wHgu+FGdxuTTYePbwvvo=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=QDuEbMATQOKPddW1ufK70fdBeatEr0CakgVN7waNQI9kJ5j9ABbZza4T5O79Iidkw
	 5smVTwk0yrES1Pp7VugS3hE3t4Q2T0mE/BEQEzl1YYP0yBOEM1Popc5ATH0JEwsJIt
	 nN0KMpD+Hgwa+LRSoPi5l/yYzr1wCsQpyrWO/RXFmdfDxu6oCa1I3TZnpvQYQ35GvM
	 n8zIzXB7FQR+Tg9CBQirMsi3HU5bryIxr9wuW4gYI0ve2p+QvdHD1IKdjT90huxwzX
	 VOI2DRvu7VPo4buRFZyEIzCQJwYf8BgKMrgjP8ycops/wi4NaQ77QmmRHofZCCek77
	 dUhjU7tS5t8kA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747391080; x=1747651580; i=teddy.astie@vates.tech;
	bh=rmMyFtnQQP/M6lJv+2OTm80wHgu+FGdxuTTYePbwvvo=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=qKljt4eXIzjKpiRbjn9rvxgK70F9BWLWXx/pVT86itAsZglLmpx42itb1q2iv2PE5
	 ID0i3ku/Txr/p0FvkN6v2y0SxzTIM5k3ZBq/+/TLDsnHsWlFvkEkmjZNUT3QQ986q/
	 v+GGRkIQkP1c87qnssQdjLd9DM9mCnUK4sWWrBKPJ2MTuMYCOt/bCuJhEerG6w8Voc
	 X9t7nNcN0aig8I6jM4u6H4uT2RMaTuj5KuYmF0SIYzYcGPRY5NFuSulJgIa81h4Poy
	 eVzquOE6MsIlx4R7HyELmIQxpeG3wwzywRqftt+mUyAG6TphpxJiUTRZzPJ9T31qJg
	 GpFBwkLhJRLjg==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2014/16]=20sev/emulate:=20Handle=20some=20non-emulable=20HVM=20paths?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747391079133
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Andrei Semenov" 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.55be2ee1b05f4c71bac5a8b138fad311?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 10:24:40 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

From: Andrei Semenov 

Some code paths are not emulable under SEV or needs special handling.

Signed-off-by: Andrei Semenov 
Signed-off-by: Teddy Astie 
---
 xen/arch/x86/hvm/emulate.c | 137 ++++++++++++++++++++++++++++++++-----
 xen/arch/x86/hvm/hvm.c     |  13 ++++
 2 files changed, 133 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 6ed8e03475..7ac3be2d59 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -689,6 +690,9 @@ static void *hvmemul_map_linear_addr(
         goto unhandleable;
     }
 
+    if ( is_sev_domain(curr->domain) && (nr_frames > 1) )
+        goto unhandleable;
+
     for ( i = 0; i < nr_frames; i++ )
     {
         enum hvm_translation_result res;
@@ -703,8 +707,16 @@ static void *hvmemul_map_linear_addr(
         /* Error checking.  Confirm that the current slot is clean. */
         ASSERT(mfn_x(*mfn) == 0);
 
-        res = hvm_translate_get_page(curr, addr, true, pfec,
+        if ( is_sev_domain(curr->domain) )
+        {
+            struct hvm_vcpu_io *hvio = &curr->arch.hvm.hvm_io;
+            unsigned long gpa = pfn_to_paddr(hvio->mmio_gpfn) | (addr & ~PAGE_MASK);
+            res = hvm_translate_get_page(curr, gpa, false, pfec,
                                      &pfinfo, &page, &gfn, &p2mt);
+        }
+        else
+            res = hvm_translate_get_page(curr, addr, true, pfec,
+                                         &pfinfo, &page, &gfn, &p2mt);
 
         switch ( res )
         {
@@ -1173,6 +1185,7 @@ static int hvmemul_linear_mmio_access(
                                                            dir, buffer_offset);
     paddr_t gpa;
     unsigned long one_rep = 1;
+    unsigned int chunk;
     int rc;
 
     if ( cache == NULL )
@@ -1183,21 +1196,50 @@ static int hvmemul_linear_mmio_access(
         ASSERT_UNREACHABLE();
         return X86EMUL_UNHANDLEABLE;
     }
+    
+    chunk = min_t(unsigned int, size, PAGE_SIZE - offset);
 
     if ( known_gpfn )
         gpa = pfn_to_paddr(hvio->mmio_gpfn) | offset;
     else
     {
-        rc = hvmemul_linear_to_phys(gla, &gpa, size, &one_rep, pfec,
+        if ( is_sev_domain(current->domain) )
+            gpa = pfn_to_paddr(hvio->mmio_gpfn) | offset;
+        else
+        {
+            rc = hvmemul_linear_to_phys(gla, &gpa, chunk, &one_rep, pfec,
+                                        hvmemul_ctxt);
+            if ( rc != X86EMUL_OKAY )
+                return rc;
+        }
+
+        latch_linear_to_phys(hvio, gla, gpa, dir == IOREQ_WRITE);
+    }
+
+    for ( ;; )
+    {
+        rc = hvmemul_phys_mmio_access(cache, gpa, chunk, dir, buffer, buffer_offset);
+        if ( rc != X86EMUL_OKAY )
+            break;
+
+        gla += chunk;
+        buffer_offset += chunk;
+        size -= chunk;
+
+        if ( size == 0 )
+            break;
+
+        if ( is_sev_domain(current->domain) )
+            return X86EMUL_UNHANDLEABLE;
+
+        chunk = min_t(unsigned int, size, PAGE_SIZE);
+        rc = hvmemul_linear_to_phys(gla, &gpa, chunk, &one_rep, pfec,
                                     hvmemul_ctxt);
         if ( rc != X86EMUL_OKAY )
             return rc;
-
-        latch_linear_to_phys(hvio, gla, gpa, dir == IOREQ_WRITE);
     }
 
-    return hvmemul_phys_mmio_access(cache, gpa, size, dir, buffer,
-                                    buffer_offset);
+    return rc;
 }
 
 static inline int hvmemul_linear_mmio_read(
@@ -1254,6 +1296,9 @@ static int linear_read(unsigned long addr, unsigned int bytes, void *p_data,
     {
         unsigned int part1 = PAGE_SIZE - offset;
 
+        if ( is_sev_domain(current->domain) )
+            return X86EMUL_UNHANDLEABLE;
+
         /* Split the access at the page boundary. */
         rc = linear_read(addr, part1, p_data, pfec, hvmemul_ctxt);
         if ( rc != X86EMUL_OKAY )
@@ -1278,11 +1323,25 @@ static int linear_read(unsigned long addr, unsigned int bytes, void *p_data,
      * upon replay) the RAM access for anything that's ahead of or past MMIO,
      * i.e. in RAM.
      */
-    cache = hvmemul_find_mmio_cache(hvio, start, IOREQ_READ, ~0);
-    if ( !cache ||
-         addr + bytes <= start + cache->skip ||
-         addr >= start + cache->size )
-        rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, &pfinfo);
+     cache = hvmemul_find_mmio_cache(hvio, start, IOREQ_READ, ~0);
+     if ( !cache ||
+          addr + bytes <= start + cache->skip ||
+          addr >= start + cache->size )
+     {
+        if ( is_sev_domain(current->domain) )
+        {
+            if ( hvio->mmio_gpfn )
+            {
+                paddr_t gpa;
+                gpa = pfn_to_paddr(hvio->mmio_gpfn) | (addr & ~PAGE_MASK);
+                rc = hvm_copy_from_guest_phys(p_data, gpa, bytes);
+            }
+            else
+                return X86EMUL_UNHANDLEABLE;
+        }
+        else
+            rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, &pfinfo);
+    }
 
     switch ( rc )
     {
@@ -1325,6 +1384,9 @@ static int linear_write(unsigned long addr, unsigned int bytes, void *p_data,
     {
         unsigned int part1 = PAGE_SIZE - offset;
 
+        if ( is_sev_domain(current->domain) )
+            return X86EMUL_UNHANDLEABLE;
+
         /* Split the access at the page boundary. */
         rc = linear_write(addr, part1, p_data, pfec, hvmemul_ctxt);
         if ( rc != X86EMUL_OKAY )
@@ -1340,9 +1402,23 @@ static int linear_write(unsigned long addr, unsigned int bytes, void *p_data,
     /* See commentary in linear_read(). */
     cache = hvmemul_find_mmio_cache(hvio, start, IOREQ_WRITE, ~0);
     if ( !cache ||
-         addr + bytes <= start + cache->skip ||
-         addr >= start + cache->size )
-        rc = hvm_copy_to_guest_linear(addr, p_data, bytes, pfec, &pfinfo);
+        addr + bytes <= start + cache->skip ||
+        addr >= start + cache->size )
+    {
+        if ( is_sev_domain(current->domain) )
+        {
+            if ( hvio->mmio_gpfn )
+            {
+                paddr_t gpa;
+                gpa = pfn_to_paddr(hvio->mmio_gpfn) | (addr & ~PAGE_MASK);
+                rc = hvm_copy_to_guest_phys(gpa, p_data, bytes, current);
+            }
+            else
+                return X86EMUL_UNHANDLEABLE;
+        }
+        else
+            rc = hvm_copy_to_guest_linear(addr, p_data, bytes, pfec, &pfinfo);
+    }
 
     switch ( rc )
     {
@@ -1430,7 +1506,12 @@ int cf_check hvmemul_insn_fetch(
     if ( !bytes ||
          unlikely((insn_off + bytes) > hvmemul_ctxt->insn_buf_bytes) )
     {
-        int rc = __hvmemul_read(x86_seg_cs, offset, p_data, bytes,
+        int rc;
+
+        if ( is_sev_domain(current->domain) )
+            return X86EMUL_UNHANDLEABLE;
+
+        rc = __hvmemul_read(x86_seg_cs, offset, p_data, bytes,
                                 hvm_access_insn_fetch, hvmemul_ctxt);
 
         if ( rc == X86EMUL_OKAY && bytes )
@@ -1485,6 +1566,7 @@ static int cf_check hvmemul_write(
     if ( !known_gla(addr, bytes, pfec) )
     {
         mapping = hvmemul_map_linear_addr(addr, bytes, pfec, hvmemul_ctxt);
+
         if ( IS_ERR(mapping) )
              return ~PTR_ERR(mapping);
     }
@@ -1719,6 +1801,9 @@ static int cf_check hvmemul_cmpxchg(
     int rc;
     void *mapping = NULL;
 
+    if ( is_sev_domain(current->domain) )
+        return X86EMUL_UNHANDLEABLE;
+
     rc = hvmemul_virtual_to_linear(
         seg, offset, bytes, NULL, hvm_access_write, hvmemul_ctxt, &addr);
     if ( rc != X86EMUL_OKAY )
@@ -1821,6 +1906,9 @@ static int cf_check hvmemul_rep_ins(
     p2m_type_t p2mt;
     int rc;
 
+    if ( is_sev_domain(current->domain) )
+        return X86EMUL_UNHANDLEABLE;
+
     rc = hvmemul_virtual_to_linear(
         dst_seg, dst_offset, bytes_per_rep, reps, hvm_access_write,
         hvmemul_ctxt, &addr);
@@ -1899,6 +1987,9 @@ static int cf_check hvmemul_rep_outs(
     p2m_type_t p2mt;
     int rc;
 
+    if ( is_sev_domain(current->domain) )
+        return X86EMUL_UNHANDLEABLE;
+
     if ( unlikely(hvmemul_ctxt->set_context) )
         return hvmemul_rep_outs_set_context(dst_port, bytes_per_rep, reps);
 
@@ -1944,6 +2035,9 @@ static int cf_check hvmemul_rep_movs(
     int rc, df = !!(ctxt->regs->eflags & X86_EFLAGS_DF);
     char *buf;
 
+    if ( is_sev_domain(current->domain) )
+        return X86EMUL_UNHANDLEABLE;
+
     rc = hvmemul_virtual_to_linear(
         src_seg, src_offset, bytes_per_rep, reps, hvm_access_read,
         hvmemul_ctxt, &saddr);
@@ -2109,9 +2203,13 @@ static int cf_check hvmemul_rep_stos(
     paddr_t gpa;
     p2m_type_t p2mt;
     bool df = ctxt->regs->eflags & X86_EFLAGS_DF;
-    int rc = hvmemul_virtual_to_linear(seg, offset, bytes_per_rep, reps,
-                                       hvm_access_write, hvmemul_ctxt, &addr);
+    int rc;
+
+    if ( is_sev_domain(current->domain) )
+        return X86EMUL_UNHANDLEABLE;
 
+    rc = hvmemul_virtual_to_linear(seg, offset, bytes_per_rep, reps,
+                                   hvm_access_write, hvmemul_ctxt, &addr);
     if ( rc != X86EMUL_OKAY )
         return rc;
 
@@ -2770,6 +2868,7 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt *hvmemul_ctxt,
     struct vcpu *curr = current;
     uint32_t new_intr_shadow;
     struct hvm_vcpu_io *hvio = &curr->arch.hvm.hvm_io;
+
     int rc;
 
     /*
@@ -2983,6 +3082,9 @@ void hvm_emulate_init_per_insn(
         unsigned int pfec = PFEC_page_present | PFEC_insn_fetch;
         unsigned long addr;
 
+        if ( is_sev_domain(current->domain) )
+            goto out;
+
         if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 )
             pfec |= PFEC_user_mode;
 
@@ -3000,6 +3102,7 @@ void hvm_emulate_init_per_insn(
             sizeof(hvmemul_ctxt->insn_buf) : 0;
     }
 
+out:
     hvmemul_ctxt->is_mem_access = false;
 }
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e1bcf8e086..d3060329fb 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -56,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3477,6 +3478,9 @@ enum hvm_translation_result hvm_copy_to_guest_linear(
     unsigned long addr, const void *buf, unsigned int size, uint32_t pfec,
     pagefault_info_t *pfinfo)
 {
+    if ( is_sev_domain(current->domain) )
+        return HVMTRANS_unhandleable;
+
     return __hvm_copy((void *)buf /* HVMCOPY_to_guest doesn't modify */,
                       addr, size, current, HVMCOPY_to_guest | HVMCOPY_linear,
                       PFEC_page_present | PFEC_write_access | pfec, pfinfo);
@@ -3486,6 +3490,9 @@ enum hvm_translation_result hvm_copy_from_guest_linear(
     void *buf, unsigned long addr, unsigned int size, uint32_t pfec,
     pagefault_info_t *pfinfo)
 {
+    if ( is_sev_domain(current->domain) )
+        return HVMTRANS_unhandleable;
+
     return __hvm_copy(buf, addr, size, current,
                       HVMCOPY_from_guest | HVMCOPY_linear,
                       PFEC_page_present | pfec, pfinfo);
@@ -3495,6 +3502,9 @@ enum hvm_translation_result hvm_copy_from_vcpu_linear(
     void *buf, unsigned long addr, unsigned int size, struct vcpu *v,
     unsigned int pfec)
 {
+    if ( is_sev_domain(v->domain) )
+        return HVMTRANS_unhandleable;
+
     return __hvm_copy(buf, addr, size, v,
                       HVMCOPY_from_guest | HVMCOPY_linear,
                       PFEC_page_present | pfec, NULL);
@@ -3522,6 +3532,9 @@ unsigned int clear_user_hvm(void *to, unsigned int len)
 {
     int rc;
 
+    if ( is_sev_domain(current->domain) )
+        return HVMTRANS_unhandleable;
+
     if ( current->hcall_compat && is_compat_arg_xlat_range(to, len) )
     {
         memset(to, 0x00, len);
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 10:31:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:31:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986855.1372379 (Exim 4.92)
	(envelope-from )
	id 1uFsLl-0004ds-Qp; Fri, 16 May 2025 10:31:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986855.1372379; Fri, 16 May 2025 10: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 1uFsLl-0004dl-Nu; Fri, 16 May 2025 10:31:33 +0000
Received: by outflank-mailman (input) for mailman id 986855;
 Fri, 16 May 2025 10:31:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsEn-0000kS-Km
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:24:21 +0000
Received: from mail187-4.suw11.mandrillapp.com
 (mail187-4.suw11.mandrillapp.com [198.2.187.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed3994a5-323f-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:24:20 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-4.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4ZzNVC0TpJzlfknC
 for ; Fri, 16 May 2025 10:24:19 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 ceb244a8b2c1464eb7eaedbb43d943a4; Fri, 16 May 2025 10:24: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" 
X-Inumbo-ID: ed3994a5-323f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747391059; x=1747661059;
	bh=Jt1BJnr3uTOtuUOvC1fwjWoIL41pGCxe5NFXv3n0GUU=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=1+HQ7axaBIXi8erEPvRPonY+S8ynrwwzD5Pe3cP5DwDNcSh3FDRhdBBPwfR435tRA
	 /KH4MG+7U3yJSSvScdIdSW6e134ZHWfcdZwj0oRtO88++yyxT/H7EjFBqF5QYE8iOx
	 pFlHCxt1t9EsVqgOd94RPGm5f7h5pNbuvPqWBIdpzazeqXmzcvbdoUXty4+Zh8oq2A
	 4tWfCFWC8EegM5J4D0JoSIi/UzOR49Y3K7wrdme28nOZIXIhq+Vc29gLPW+8FkqQVL
	 VzS2C2g8ltQmI8+PeivBtsTeb0CA/DUoU2acL4rReL8B5LPhGM6qclvhjCje8F9ja/
	 IRqzc/CMtWyaA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747391059; x=1747651559; i=teddy.astie@vates.tech;
	bh=Jt1BJnr3uTOtuUOvC1fwjWoIL41pGCxe5NFXv3n0GUU=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=N3IGwhZSwgPVxnNZgSUgdDkm9UccNoYIDxv7PhP7FNpIqtHRPEWlVp7rN0MMZp+zv
	 ze7Vo9RY1Im7PELfLIrrYxG6Q+QXB23G83AO3nAk7rb2zk7zqBsDSP0Cf0jfAXMlYj
	 nW7bEwzE1fzFrqxtuOGpCSNuNHWlBJaQZjZbVxNTMOuLtHKPUI4OMlVB+cRsOhaszr
	 LLeQiT22CgaZRm7auXU/zU1/EoW0fgyB8m6wx4BvJNY8WkrV2NFreZJZV4WGMRERXQ
	 pHSzEucj0b5J9zO/gXC9LfK8fFt3S6PPFLN+R46L9J1/BdN6Ah+tO2TvhUUadY11cy
	 I73u6PFAk4LQA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2012/16]=20x86/cpufeature:=20Introduce=20SME=20and=20SEV-related=20CPU=20features?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747391057994
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.ceb244a8b2c1464eb7eaedbb43d943a4?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 10:24:19 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed-off-by: Teddy Astie 
---
 xen/arch/x86/cpu/common.c                   | 2 ++
 xen/arch/x86/include/asm/cpufeature.h       | 4 ++++
 xen/include/public/arch-x86/cpufeatureset.h | 5 +++++
 xen/include/xen/lib/x86/cpu-policy.h        | 9 ++++++++-
 4 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index e8d4ca3203..a610b0f513 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -481,6 +481,8 @@ static void generic_identify(struct cpuinfo_x86 *c)
 		c->x86_capability[FEATURESET_e8b] = cpuid_ebx(0x80000008);
 	if (c->extended_cpuid_level >= 0x80000021)
 		c->x86_capability[FEATURESET_e21a] = cpuid_eax(0x80000021);
+	if (c->extended_cpuid_level >= 0x8000001f)
+		c->x86_capability[FEATURESET_e1fa] = cpuid_eax(0x8000001f);
 
 	/* Intel-defined flags: level 0x00000007 */
 	if (c->cpuid_level >= 7) {
diff --git a/xen/arch/x86/include/asm/cpufeature.h b/xen/arch/x86/include/asm/cpufeature.h
index 397a04af41..bded70231c 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -233,6 +233,10 @@ static inline bool boot_cpu_has(unsigned int feat)
 
 #define cpu_has_msr_tsc_aux     (cpu_has_rdtscp || cpu_has_rdpid)
 
+#define cpu_has_sme             boot_cpu_has(X86_FEATURE_SME)
+#define cpu_has_sev             boot_cpu_has(X86_FEATURE_SEV)
+#define cpu_has_sev_es          boot_cpu_has(X86_FEATURE_SEV_ES)
+
 /* Bugs. */
 #define cpu_bug_fpu_ptrs        boot_cpu_has(X86_BUG_FPU_PTRS)
 #define cpu_bug_null_seg        boot_cpu_has(X86_BUG_NULL_SEG)
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index a6d4a0cba7..2a67bcc6a4 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -394,6 +394,11 @@ XEN_CPUFEATURE(MON_UMON_MITG,      16*32+30) /*   MCU_OPT_CTRL.MON_UMON_MITG */
 /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.edx, word 17 (express in terms of word 16) */
 XEN_CPUFEATURE(ITS_NO,             16*32+62) /*!A No Indirect Target Selection */
 
+/* AMD-defined CPU features, CPUID level 0x8000001f.eax, word 18 */
+XEN_CPUFEATURE(SME,                18*32+ 0) /*   Secure Memory Encryption */
+XEN_CPUFEATURE(SEV,                18*32+ 1) /*   Secure Encrypted Virtualization */
+XEN_CPUFEATURE(SEV_ES,             18*32+ 3) /*   SEV Encrypted State */
+
 #endif /* XEN_CPUFEATURE */
 
 /* Clean up from a default include.  Close the enum (for C). */
diff --git a/xen/include/xen/lib/x86/cpu-policy.h b/xen/include/xen/lib/x86/cpu-policy.h
index f43e1a3b21..a5b22b34d8 100644
--- a/xen/include/xen/lib/x86/cpu-policy.h
+++ b/xen/include/xen/lib/x86/cpu-policy.h
@@ -22,6 +22,7 @@
 #define FEATURESET_7d1       15 /* 0x00000007:1.edx    */
 #define FEATURESET_m10Al     16 /* 0x0000010a.eax      */
 #define FEATURESET_m10Ah     17 /* 0x0000010a.edx      */
+#define FEATURESET_e1fa      18 /* 0x8000001f.eax      */
 
 struct cpuid_leaf
 {
@@ -317,7 +318,13 @@ struct cpu_policy
             uint64_t :64, :64; /* Leaf 0x8000001c. */
             uint64_t :64, :64; /* Leaf 0x8000001d - Cache properties. */
             uint64_t :64, :64; /* Leaf 0x8000001e - Extd APIC/Core/Node IDs. */
-            uint64_t :64, :64; /* Leaf 0x8000001f - AMD Secure Encryption. */
+            /* Leaf 0x8000001f - AMD Secure Memory Encryption. */
+            union {
+                uint32_t e1fa;
+                struct { DECL_BITFIELD(e1fa); };
+            };
+            uint32_t c_bit_pos:6, physaddr_red:6, num_vmpl:4, :16;
+            uint32_t max_sev_guests:32, min_no_es_asid;
             uint64_t :64, :64; /* Leaf 0x80000020 - Platform QoS. */
 
             /* Leaf 0x80000021 - Extended Feature 2 */
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 10:31:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:31:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986856.1372389 (Exim 4.92)
	(envelope-from )
	id 1uFsLo-0004wy-1e; Fri, 16 May 2025 10:31:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986856.1372389; Fri, 16 May 2025 10:31: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 1uFsLn-0004wq-UX; Fri, 16 May 2025 10:31:35 +0000
Received: by outflank-mailman (input) for mailman id 986856;
 Fri, 16 May 2025 10:31:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsFI-0000kS-NX
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:24:52 +0000
Received: from mail187-4.suw11.mandrillapp.com
 (mail187-4.suw11.mandrillapp.com [198.2.187.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ffd42512-323f-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:24:51 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-4.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4ZzNVp20C8zlfcMZ
 for ; Fri, 16 May 2025 10:24:50 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 26fc1f1497074d24a6572d1c605778cd; Fri, 16 May 2025 10:24: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" 
X-Inumbo-ID: ffd42512-323f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747391090; x=1747661090;
	bh=lPXqp2js7vt00YaTBMUsWA+9FdXRi2GQpFRihsFOl30=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=s+sHoJ0eyQzfCTB2nT0EItF49M6MwcQqXVhGklNcZ8O5YHLcHlJbVMTiXV/68RB2F
	 T/O2y1MtmHFlf7DgOq2qMMbnat6Q381r53wsF1dE3l4qHrzL3g29htS8KC4GsEaUZC
	 +6ss4KnPoicPic3B8KmevO9CPxn40f/itRtMfBEM5KSKmEAkk3NKKva6+3RLzGpoHx
	 mjlISCXb8a+4F+sXBdD3EUKI0c9IM3zO/h4OeXTLtnfNzfn/OMeRwB3qwhyCZGeeD/
	 G1OlDWfn2ReZcflLk/MVXfiIhDjwT4+TbJsBb5vE62ZEXQeEu+DdOalTGvPrqzfyiC
	 zyLE0Ev1MQHuQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747391090; x=1747651590; i=teddy.astie@vates.tech;
	bh=lPXqp2js7vt00YaTBMUsWA+9FdXRi2GQpFRihsFOl30=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=l+1h2LX+iOCvWdCT8w/r0sAX+gA8ejuFRSzeHDK3B97fbdHgxMwrOReEagGjB9dqm
	 QnwlbgiTkxDZxKyQ6PxApNR/pyWD2Bzapa8Qw/sfhzii/5BCmj/hOdcpGAeVeyUdjn
	 uzpqUq13p4WV0SQ0rc/GxCi2sMR2NX5RGMww20d1VYaqj/k93jBsiXL1lEj5vipFlj
	 xKML5LximY8+d/ncP8JNsGhYbnflYmaJZReTG7oOkVbJwLOQg/xxK4LkhPTxqxPJr2
	 X5/+aFU3pSCB+BTDCLesgqwflgY4ZuJCrw9HylOJg+ysL6NAy3NOfA8AHxxDG6e/B+
	 jq1N1NdTIIcTQ==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2015/16]=20HACK:=20coco:=20Leak=20ASID=20for=20coco=20guests?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747391089320
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.26fc1f1497074d24a6572d1c605778cd?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 10:24:50 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

In order to reuse a ASID in a SEV guest, we need to perform a
WBINVD on all pCPUs that ran the guest, then a DF_FLUSH on the PSP.

Just leak the ASID for now.

Signed-off-by: Teddy Astie 
---
 xen/arch/x86/hvm/hvm.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d3060329fb..ced58ccf4b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -795,7 +795,10 @@ void hvm_domain_destroy(struct domain *d)
         list_del(&ioport->list);
         xfree(ioport);
     }
-    hvm_asid_free(&d->arch.hvm.asid);
+    if ( !is_coco_domain(d) )
+        hvm_asid_free(&d->arch.hvm.asid);
+    else
+        printk("coco: Leaking ASID %x: TODO (DF_FLUSH handling)\n", d->arch.hvm.asid.asid);
     destroy_vpci_mmcfg(d);
 
 }
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 10:31:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:31:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986871.1372400 (Exim 4.92)
	(envelope-from )
	id 1uFsLz-0005bu-Aa; Fri, 16 May 2025 10:31:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986871.1372400; Fri, 16 May 2025 10:31:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFsLz-0005bl-65; Fri, 16 May 2025 10:31:47 +0000
Received: by outflank-mailman (input) for mailman id 986871;
 Fri, 16 May 2025 10:31:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsEb-0000kS-NA
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:24:09 +0000
Received: from mail187-4.suw11.mandrillapp.com
 (mail187-4.suw11.mandrillapp.com [198.2.187.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e61d7bd4-323f-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:24:08 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-4.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4ZzNTy61lZzlfcNB
 for ; Fri, 16 May 2025 10:24:06 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 fb66e4ff4694405bb0c5bd8ca9aafaf8; Fri, 16 May 2025 10:24:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e61d7bd4-323f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747391046; x=1747661046;
	bh=dLlEWnEcFnUkrXQUBAwvC2R74dRSbryvP/QYt6wEGyA=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=u6Ro8WmoVEI0JcMvbTJkiCWQSGdMOJBA8OyBM0/x4OHAYd79KxB6YmP5LjRK2Ngoa
	 RZ6LIX+LcPkUO6vfLfOdlqN/g4d0vNMt7z0YWeFsUboW+t3rPoHiLG8cl6y183zDm3
	 BOvvMzqT9emIuYDGdh5hicDzeL3qQI/iNPff2VuTRmFxfGfB7uYiP5tsbAWRUP33q/
	 EcanY2vjr+dPFSiEKqlT65eeGaCCFACzddjKm/lRq8EIwY2Tm3J01M65nGsU1V/lnv
	 PyBtqyWUy5cnmUeu4IOHVguSUMljQ+ebqg1Gj6ON91nV6luJ2p0zj26Ri6ay9jiTyk
	 yHAg2RJ2YM+AQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747391046; x=1747651546; i=teddy.astie@vates.tech;
	bh=dLlEWnEcFnUkrXQUBAwvC2R74dRSbryvP/QYt6wEGyA=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=XFcBT+CVLxyD3IZf0ElbSrbidtiRAc30nWLKdndrVtOgFn7Fq00cpEWvR1LgwapmY
	 LKSwV4x11s8/TKDoK4Mb3ICUIXDRGCKRI2HlD0hdYVsDpMDFXAbHhiNQKFwAhidz2c
	 tiNqTzbBfaNDVOwA9FyJ/BUVRt06WUj+zbRxrxltwygr6PEzJNlemf8/iwI2LsSu+8
	 Cgml+DZ6h2V+YiLIKXjqmz6oufdslIxWwQwmi57ZVoLqmJl6fJ5KHNJlOos+zBqb0M
	 ofzgck2d/h4j7KXM6cWbI0k7tsGMu4g5vchDCP3y2sfHlWLMYtydJn+Zy+OP2ypte8
	 TNMD+QZvLV0cw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2011/16]=20x86/svm:=20Introduce=20NPCTRL=20VMCB=20bits?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747391045888
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Andrei Semenov" 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.fb66e4ff4694405bb0c5bd8ca9aafaf8?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 10:24:06 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Those bits are used to enable SEV-related features in VMCB.

Signed-off-by: Andrei Semenov 
Signed-off-by: Teddy Astie 
---
 xen/arch/x86/include/asm/hvm/svm/vmcb.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/arch/x86/include/asm/hvm/svm/vmcb.h b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
index 3d871b6135..fd166498f2 100644
--- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h
+++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
@@ -143,6 +143,17 @@ enum DRInterceptBits
     DR_INTERCEPT_DR15_WRITE = 1u << 31,
 };
 
+/* Miscellanious controls in _np_ctrl*/
+enum NpCtrlBits
+{
+    NPCTRL_NP_ENABLE    = 1 << 0,
+    NPCTRL_SEV_ENABLE   = 1 << 1,
+    NPCTRL_SEVES_ENABLE = 1 << 2,
+    NPCTRL_GMET_ENABLE  = 1 << 3,
+    NPCTRL_NPSSS_ENABL  = 1 << 4,
+    NPCTRL_VTE_ENABLE   = 1 << 5,
+};
+
 enum VMEXIT_EXITCODE
 {
     /* control register read exitcodes */
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 10:32:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:32:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986877.1372409 (Exim 4.92)
	(envelope-from )
	id 1uFsMc-0006Z5-K6; Fri, 16 May 2025 10:32:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986877.1372409; Fri, 16 May 2025 10:32: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 1uFsMc-0006YA-GY; Fri, 16 May 2025 10:32:26 +0000
Received: by outflank-mailman (input) for mailman id 986877;
 Fri, 16 May 2025 10:32:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsEz-0000kS-6p
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:24:33 +0000
Received: from mail187-4.suw11.mandrillapp.com
 (mail187-4.suw11.mandrillapp.com [198.2.187.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f40480ea-323f-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:24:31 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-4.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4ZzNVQ3Hf8zlff4H
 for ; Fri, 16 May 2025 10:24:30 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 63c856eaabcc465290ad4b5fa1439d25; Fri, 16 May 2025 10:24: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" 
X-Inumbo-ID: f40480ea-323f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747391070; x=1747661070;
	bh=lO1eWJXehJrWu+Ma1mFaorTOrllIBJiV30YAtkWYzO4=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=ZoW1a4JDDudBZTiatl4lj4LA/6RPEvoUgWr8CxUyxau7862zRdHQXrN1A6WHnsed9
	 n6Y+EhqNMTGmrlhft7tououRA1/fh3eyhmk2fWniSGUkG49F/2xx4fZFTXOjOhAVaI
	 MsE3DxVV0QMPhK2Nmb4gbIA6xnLaGLrQV5wKXj1DNG3Q/hGF7EVLGeO5+mhbUFeaTI
	 ylcKyg+vouPA+AMxMDyfJiHA/uGc4Ts21sC1SaPpv6XeHvYRF6gwh9uqBWCNrE/hT6
	 RSQWDOTTMGDzqlCSG/Lo7zEXIhqA4j+GYLpSaQIiMQ9Y7AHGdf+hEv5OtaoEOd1KWY
	 8LP8HKE7Wd9Pg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747391070; x=1747651570; i=teddy.astie@vates.tech;
	bh=lO1eWJXehJrWu+Ma1mFaorTOrllIBJiV30YAtkWYzO4=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=GpjepVawJ1WbcosrlqMdqjwmmotYz8QZaE9vyGpm9yi7wRxoRKeiTywBfb5BPc7eo
	 tciAA2H0KON5Wssbm4rzYlNDMbxx2H7yNrQVZE/sbKpx4LHCgGEptWtWByq32N8WwD
	 SXP1N3puRGAuIuqPSNPHJ/qMOiV89DI9WwW3VEHoGcD117ubHwXbMgN+NjpagEPuEn
	 e/c3R+WbrWTSrZ76K/xmOFRxD3eqk/6JR2GmRB2Svjsiyo+tP0Zft9+L6h/F+cN2at
	 6egWnDrm86p1VFZUcDPedQEzQVSZz/xVy2bPMVrMYHkAM9ySnaezp4gkzz2M/T/0Wg
	 EgJZNLUkFTMvg==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2013/16]=20x86/coco:=20Introduce=20AMD-SEV=20support?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747391069679
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Andrei Semenov" 
Message-Id: <0326909f629fd5b2dee9f17d9a566a79953bdd85.1747312394.git.teddy.astie@vates.tech>
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.63c856eaabcc465290ad4b5fa1439d25?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 10:24:30 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

From: Andrei Semenov 

AMD-SEV is AMD implementation for confidential computing.

This patch introduces SEV initialization and HVM enablement logic.

Signed-off-by: Andrei Semenov 
Signed-off-by: Teddy Astie 
---
Some possible improvement would be to slightly change the ASID allocation
logic under SEV : 

With SEV support and usable :
 - non-SEV guest : Use ASID > NumSevGuests if possible
 - SEV guest : Use ASID in SEV range

Such as we don't waste SEV-supported ASIDs.

This currently lacks DF_FLUSH support, so SEV-enabled destroyed cannot
reuse their ASIDs. This is currently workaround with "coco: Leak ASID for coco guests".
---
 xen/arch/x86/Makefile                  |   1 +
 xen/arch/x86/coco/Makefile             |   1 +
 xen/arch/x86/coco/sev.c                | 262 +++++++++++++++++++++++++
 xen/arch/x86/cpu/amd.c                 |  10 +
 xen/arch/x86/cpuid.c                   |   5 +
 xen/arch/x86/hvm/Kconfig               |  10 +
 xen/arch/x86/hvm/svm/svm.c             |   6 +
 xen/arch/x86/hvm/svm/vmcb.c            |  17 +-
 xen/arch/x86/include/asm/coco.h        |   8 +
 xen/arch/x86/include/asm/hvm/svm/sev.h |  14 ++
 xen/arch/x86/include/asm/hvm/svm/svm.h |  16 ++
 11 files changed, 344 insertions(+), 6 deletions(-)
 create mode 100644 xen/arch/x86/coco/Makefile
 create mode 100644 xen/arch/x86/coco/sev.c
 create mode 100644 xen/arch/x86/include/asm/coco.h
 create mode 100644 xen/arch/x86/include/asm/hvm/svm/sev.h

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index bedb97cbee..220bff5e0a 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -1,5 +1,6 @@
 obj-y += acpi/
 obj-y += boot/
+obj-$(CONFIG_COCO) += coco/
 obj-y += cpu/
 obj-y += efi/
 obj-y += genapic/
diff --git a/xen/arch/x86/coco/Makefile b/xen/arch/x86/coco/Makefile
new file mode 100644
index 0000000000..59ab1c075f
--- /dev/null
+++ b/xen/arch/x86/coco/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_COCO_AMD_SEV) += sev.o
\ No newline at end of file
diff --git a/xen/arch/x86/coco/sev.c b/xen/arch/x86/coco/sev.c
new file mode 100644
index 0000000000..366ce42baa
--- /dev/null
+++ b/xen/arch/x86/coco/sev.c
@@ -0,0 +1,262 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * coco/sev.c: AMD SEV support
+ * Copyright (c) Vates SAS
+ */
+
+#include 
+#include 
+#include 
+#include 
+ 
+#include 
+
+#include 
+#include 
+#include 
+
+static int sev_domain_initialise(struct domain *d)
+{
+    struct sev_data_launch_start sd_ls;
+    struct sev_data_activate sd_a;
+    int psp_ret;
+    long rc = 0;
+
+    sd_ls.handle = 0;          /* generate new one */
+    sd_ls.policy = 0;          /* NOKS policy */
+    sd_ls.dh_cert_address = 0; /* do not DH stuff */
+
+    rc = sev_do_cmd(SEV_CMD_LAUNCH_START, (void *)(&sd_ls), &psp_ret, true);
+    if ( rc )
+    {
+        printk(XENLOG_ERR "asp: failed to LAUNCH_START domain(%d): psp_ret %d\n",
+                d->domain_id, psp_ret);
+        return rc;
+    }
+
+    sd_a.handle = sd_ls.handle;
+    sd_a.asid = d->arch.hvm.asid.asid;
+
+    rc = sev_do_cmd(SEV_CMD_ACTIVATE, (void *)(&sd_a), &psp_ret, true);
+    if ( rc )
+    {
+        printk(XENLOG_ERR "asp: failed to ACTIVATE domain(%d): psp_ret %d\n",
+                d->domain_id, psp_ret);
+        return rc;
+    }
+
+    d->arch.hvm.svm.sev.asp_handle = sd_ls.handle;
+    d->arch.hvm.svm.sev.asp_policy = 0;
+
+    return 0;
+}
+
+static int sev_domain_prepare_initial_mem(struct domain *d, gfn_t gfn, size_t count)
+{
+    struct page_info *page;
+    int rc, psp_ret;
+    struct sev_data_launch_update_data sd_lud;
+
+    mfn_t mfn, mfn_base = INVALID_MFN;
+    size_t segment_size = 0;
+
+    do {
+        page = get_page_from_gfn(d, gfn_x(gfn), NULL, P2M_ALLOC);
+        if ( unlikely(!page) )
+            return rc;
+
+        mfn = page_to_mfn(page);
+        put_page(page);
+
+        if ( !mfn_valid(mfn_base) )
+            mfn_base = mfn;
+        else
+        {
+            // Check for a break.
+            if (mfn_x(mfn_base) + segment_size != mfn_x(mfn) || segment_size == 512)
+            {
+                // Make launch update data.
+                printk(XENLOG_DEBUG
+                       "asp: LAUNCH_UPDATE_DATA d%d: base=%"PRI_xen_pfn", size=%zx\n",
+                       d->domain_id, mfn_x(mfn_base), segment_size);
+                
+                sd_lud.reserved = 0;
+                sd_lud.handle = d->arch.hvm.svm.sev.asp_handle;
+                sd_lud.address = mfn_x(mfn_base) << PAGE_SHIFT;
+                sd_lud.len = segment_size * PAGE_SIZE;
+                rc = sev_do_cmd(SEV_CMD_LAUNCH_UPDATE_DATA, (void *)(&sd_lud),
+                                &psp_ret, true);
+                if (rc)
+                {
+                    printk(XENLOG_ERR
+                           "asp: failed to LAUNCH_UPDATE_DATA dom(%d): err %d\n",
+                           d->domain_id, psp_ret);
+                    return rc;
+                }
+
+                mfn_base = mfn_x(mfn);
+                segment_size = 0;
+            }
+        }  
+
+        gfn = gfn_add(gfn, 1);
+        segment_size++;
+        count--;
+    } while ( count );
+
+    // Last launch update data.
+    if ( segment_size )
+    {
+        sd_lud.reserved = 0;
+        sd_lud.handle = d->arch.hvm.svm.sev.asp_handle;
+        sd_lud.address = mfn_x(mfn_base) << PAGE_SHIFT;
+        sd_lud.len = segment_size * PAGE_SIZE;
+        rc = sev_do_cmd(SEV_CMD_LAUNCH_UPDATE_DATA, (void *)(&sd_lud),
+                        &psp_ret, true);
+
+        if ( rc )
+            printk(XENLOG_ERR "asp: failed to LAUNCH_UPDATE_DATA dom(%d): err %d\n",
+                   d->domain_id, psp_ret);
+    }
+
+    return rc;
+}
+
+static int sev_domain_creation_finished(struct domain *d)
+{
+    struct sev_data_launch_measure sd_lm;
+    struct sev_data_launch_finish sd_lf;
+    int psp_ret;
+    long rc = 0;
+
+    sd_lm.handle = d->arch.hvm.svm.sev.asp_handle;
+    sd_lm.address = virt_to_maddr(d->arch.hvm.svm.sev.measure);
+    sd_lm.len = sizeof(d->arch.hvm.svm.sev.measure);
+    sd_lm.reserved = 0;
+
+    rc = sev_do_cmd(SEV_CMD_LAUNCH_MEASURE, (void *)(&sd_lm), &psp_ret, true);
+    if ( rc )
+    {
+        printk(XENLOG_ERR "asp: failed to LAUNCH_MEASURE for d%hu: psp_ret %hu, rc %ld\n",
+               d->domain_id, psp_ret, rc);
+        
+        if (psp_ret == SEV_RET_INVALID_LEN)
+            printk(XENLOG_ERR "asp: Expected %"PRIu32" bytes\n", sd_lm.len);
+        return rc;
+    }
+
+    sd_lf.handle = d->arch.hvm.svm.sev.asp_handle;
+
+    rc = sev_do_cmd(SEV_CMD_LAUNCH_FINISH, (void *)(&sd_lf), &psp_ret, true);
+    if ( rc )
+    {
+        printk(XENLOG_ERR "asp: failed to LAUNCH_FINISH for d%hu: psp_ret %d, rc %ld\n",
+                d->domain_id, psp_ret, rc);
+        return rc;
+    }
+
+    d->arch.hvm.svm.sev.measure_len = sd_lm.len;
+    return 0;
+}
+
+static void sev_domain_destroy(struct domain *d)
+{
+    struct sev_data_deactivate sd_da;
+    struct sev_data_decommission sd_de;
+    int psp_ret;
+    long rc = 0;
+
+    sd_da.handle = d->arch.hvm.svm.sev.asp_handle;
+
+    rc = sev_do_cmd(SEV_CMD_DEACTIVATE, (void *)(&sd_da), &psp_ret, true);
+    if (rc)
+    {
+        printk(XENLOG_ERR "asp: failed to DEACTIVATE for d%hu: psp_ret %d\n",
+               d->domain_id, psp_ret);
+        return;
+    }
+
+    sd_de.handle = d->arch.hvm.svm.sev.asp_handle;
+
+    rc = sev_do_cmd(SEV_CMD_DECOMMISSION, (void *)(&sd_de), &psp_ret, true);
+    if (rc)
+    {
+        printk(XENLOG_ERR "asp: failed to DECOMMISSION for d%hu: psp_ret %d\n",
+               d->domain_id, psp_ret);
+        return;
+    }
+
+    d->arch.hvm.svm.sev.asp_handle = 0;
+}
+
+static int sev_asid_alloc(struct domain *d, struct hvm_asid *asid)
+{
+    /* TODO: SEV-ES/SNP */
+    unsigned long asid_min = raw_cpu_policy.extd.min_no_es_asid;
+    unsigned long asid_max = raw_cpu_policy.extd.max_sev_guests;
+
+    return hvm_asid_alloc_range(asid, asid_min, asid_max);
+}
+
+static struct coco_domain_ops sev_domain_ops = {
+    .prepare_initial_mem = sev_domain_prepare_initial_mem,
+    .domain_initialise = sev_domain_initialise,
+    .domain_creation_finished = sev_domain_creation_finished,
+    .domain_destroy = sev_domain_destroy,
+    .asid_alloc = sev_asid_alloc,
+};
+
+static int sev_init(void)
+{
+    unsigned long syscfg;
+
+    if ( WARN_ON(!cpu_has_sev) )
+        return -ENOSYS;
+
+    ASSERT(raw_cpu_policy.extd.c_bit_pos > 0);
+    ASSERT(raw_cpu_policy.extd.max_sev_guests > 0);
+
+    printk(XENLOG_INFO "sev: C-bit is %"PRIu32"\n", raw_cpu_policy.extd.c_bit_pos);
+    printk(XENLOG_INFO "sev: Supports up to %"PRIu32" guests\n",
+            raw_cpu_policy.extd.max_sev_guests);
+
+    /* Enable AMD SME */	
+    rdmsrl(MSR_K8_SYSCFG, syscfg);
+
+    if ( !(syscfg & SYSCFG_MEM_ENCRYPT) )
+    {
+        syscfg |= SYSCFG_MEM_ENCRYPT;
+        wrmsrl(MSR_K8_SYSCFG, syscfg);
+
+        printk(XENLOG_INFO "sev: Enabled AMD SME\n");
+    }
+
+    return 0;
+}
+
+static int sev_get_platform_status(struct coco_platform_status *status)
+{
+    status->platform = COCO_PLATFORM_amd_sev;
+
+    // if ( cpu_has_sev_es )
+    //   status->platform_flags |= COCO_PLATFORM_FLAG_sev_es;
+
+    status->flags = COCO_STATUS_FLAG_supported;
+
+    return 0;
+}
+
+static struct coco_domain_ops *sev_get_domain_ops(struct domain *d)
+{
+    // TODO: SEV-ES and SEV-SNP support
+    return &sev_domain_ops;
+}
+
+struct coco_ops sev_coco_ops = {
+    .name = "SEV",
+    .init = sev_init,
+    .get_platform_status = sev_get_platform_status,
+    .get_domain_ops = sev_get_domain_ops,
+};
+
+
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 37d67dd15c..28b5a0420d 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -1,4 +1,5 @@
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +20,10 @@
 
 #include "cpu.h"
 
+#ifdef CONFIG_COCO
+#include 
+#endif
+
 /*
  * Pre-canned values for overriding the CPUID features 
  * and extended features masks.
@@ -1333,6 +1338,11 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
 	check_syscfg_dram_mod_en();
 
 	amd_log_freq(c);
+
+#ifdef CONFIG_COCO_AMD_SEV
+	if ( cpu_has_sev )
+		coco_register_ops(&sev_coco_ops);
+#endif
 }
 
 const struct cpu_dev __initconst_cf_clobber amd_cpu_dev = {
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index e2d94619c2..e1d6db4ad8 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define EMPTY_LEAF ((struct cpuid_leaf){})
@@ -250,6 +251,10 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
             return;
 
         *res = array_access_nospec(p->extd.raw, leaf & 0xffff);
+        
+        /* For a SEV guest, passthrough the host SEV leaf. */
+        if ( is_sev_domain(d) && leaf == 0x8000001fU )
+            *res = raw_cpu_policy.extd.raw[0x1f];
         break;
 
     default:
diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
index 2def0f98e2..a9332ab8ce 100644
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -25,6 +25,16 @@ config AMD_SVM
 	  If your system includes a processor with AMD-V support, say Y.
 	  If in doubt, say Y.
 
+config COCO_AMD_SEV
+	bool "AMD SEV (UNSUPPORTED)" if AMD && AMD_SVM && COCO && UNSUPPORTED
+	default y
+	select AMD_SP
+	help
+		Enables support for AMD Secure Encrypted Virtualization technology.
+		This option is needed if you want to run confidential guests on a
+		AMD platform that supports it.
+		If in doubt, say N.
+
 config INTEL_VMX
 	bool "Intel VT-x" if INTEL && EXPERT
 	default y
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index cc19d80fe1..63889bf803 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1865,6 +1866,11 @@ static int cf_check svm_msr_read_intercept(
         break;
 
     case MSR_K8_SYSCFG:
+        if ( is_sev_domain(d) )
+        {
+            *msr_content = SYSCFG_MEM_ENCRYPT;
+            break;
+        }
     case MSR_K8_TOP_MEM1:
     case MSR_K8_TOP_MEM2:
     case MSR_K8_VM_CR:
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 4e1f61dbe0..5157afe733 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -192,15 +193,19 @@ int svm_create_vmcb(struct vcpu *v)
     svm->vmcb = nv->nv_n1vmcx;
     rc = construct_vmcb(v);
     if ( rc != 0 )
-    {
-        free_vmcb(nv->nv_n1vmcx);
-        nv->nv_n1vmcx = NULL;
-        svm->vmcb = NULL;
-        return rc;
-    }
+        goto err;
+
+    if ( is_sev_domain(v->domain) )
+        vmcb_set_np_ctrl(svm->vmcb, vmcb_get_np_ctrl(svm->vmcb) | NPCTRL_SEV_ENABLE);
 
     svm->vmcb_pa = nv->nv_n1vmcx_pa = virt_to_maddr(svm->vmcb);
     return 0;
+
+err:
+    free_vmcb(nv->nv_n1vmcx);
+    nv->nv_n1vmcx = NULL;
+    svm->vmcb = NULL;
+    return rc;
 }
 
 void svm_destroy_vmcb(struct vcpu *v)
diff --git a/xen/arch/x86/include/asm/coco.h b/xen/arch/x86/include/asm/coco.h
new file mode 100644
index 0000000000..874ef56327
--- /dev/null
+++ b/xen/arch/x86/include/asm/coco.h
@@ -0,0 +1,8 @@
+#ifndef __ARCH_X86_COCO_H
+#define __ARCH_X86_COCO_H
+
+#include 
+
+extern struct coco_ops sev_coco_ops;
+
+#endif /* __ARCH_X86_CACHE_H */
\ No newline at end of file
diff --git a/xen/arch/x86/include/asm/hvm/svm/sev.h b/xen/arch/x86/include/asm/hvm/svm/sev.h
new file mode 100644
index 0000000000..b7b5ab5591
--- /dev/null
+++ b/xen/arch/x86/include/asm/hvm/svm/sev.h
@@ -0,0 +1,14 @@
+#ifndef __XEN_HVM_SEV_H__
+#define __XEN_HVM_SEV_H__
+
+#include 
+#include 
+
+#include 
+
+static always_inline bool is_sev_domain(const struct domain *d)
+{
+  return cpu_has_sev && evaluate_nospec(d->options & XEN_DOMCTL_CDF_coco);
+}
+
+#endif /* __XEN_HVM_SEV_H__ */
diff --git a/xen/arch/x86/include/asm/hvm/svm/svm.h b/xen/arch/x86/include/asm/hvm/svm/svm.h
index 1254e5f3ee..efd54511aa 100644
--- a/xen/arch/x86/include/asm/hvm/svm/svm.h
+++ b/xen/arch/x86/include/asm/hvm/svm/svm.h
@@ -9,6 +9,8 @@
 #ifndef __ASM_X86_HVM_SVM_H__
 #define __ASM_X86_HVM_SVM_H__
 
+#include 
+
 void svm_asid_init(void);
 void svm_vcpu_assign_asid(struct vcpu *v);
 void svm_vcpu_set_tlb_control(struct vcpu *v);
@@ -26,6 +28,16 @@ bool svm_load_segs(unsigned int ldt_ents, unsigned long ldt_base,
                    unsigned long fs_base, unsigned long gs_base,
                    unsigned long gs_shadow);
 
+struct sev_state {
+  uint32_t asp_handle;
+  uint32_t asp_policy;
+  uint8_t  measure[96];
+  uint32_t measure_len; /* 96 bytes */
+  uint8_t  state;
+
+  unsigned long flags;
+};
+                
 struct svm_domain {
     /* OSVW MSRs */
     union {
@@ -35,6 +47,10 @@ struct svm_domain {
             uint64_t status;
         };
     } osvw;
+
+    #ifdef CONFIG_COCO_AMD_SEV
+    struct sev_state sev;
+    #endif
 };
 
 extern u32 svm_feature_flags;
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 10:32:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:32:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986884.1372418 (Exim 4.92)
	(envelope-from )
	id 1uFsN2-0007AW-Vu; Fri, 16 May 2025 10:32:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986884.1372418; Fri, 16 May 2025 10:32: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 1uFsN2-0007AP-TE; Fri, 16 May 2025 10:32:52 +0000
Received: by outflank-mailman (input) for mailman id 986884;
 Fri, 16 May 2025 10:32:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsFS-0000kS-7H
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:25:02 +0000
Received: from mail187-4.suw11.mandrillapp.com
 (mail187-4.suw11.mandrillapp.com [198.2.187.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0562caa4-3240-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:25:00 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-4.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4ZzNVz4HQJzlkq4C
 for ; Fri, 16 May 2025 10:24:59 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 7f39565cc8474cdab9afc80d3eba8c0e; Fri, 16 May 2025 10:24: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" 
X-Inumbo-ID: 0562caa4-3240-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747391099; x=1747661099;
	bh=09td6MHuWEdAtrsXq56Leo+iJWk3EtNEWxuIkhfA2QY=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=a2gbiYcDd7G4EV3R5dxVsuqVVKQkuHXSZ49ZrcQCKwpH+qX/qpCklXy/nF5zhmYDD
	 hhiShkEoS8n5h7/Gu46AcEd3w0qx5jzrjZA/tzc9NqYGBzXekD3T0+P2feDSoqCRZ9
	 71LZ2prWtjXd88k5UBe/qm0jrtC/9ybHTqZkQVn6e/8RYSXOtHBTIXYhj8PnvRAi8j
	 yb05w6xYqgKIzo2ASJ2pKRQcfyXVLV1G7FbCfWmDA7WMxG45mfvkuK3mlmPV1iqdoJ
	 mYMg9moILLsRk0G73K4WXZesxLzlgYibF1IDQRnoNn2wmfFk6WTuvCmr0oC2HdR+YM
	 WcU0gsRV1YBhw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747391099; x=1747651599; i=teddy.astie@vates.tech;
	bh=09td6MHuWEdAtrsXq56Leo+iJWk3EtNEWxuIkhfA2QY=;
	h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=ChFOJqpTBxrMueYRacemat+PhOtQRul24i2hKMOu+K6adyvVryfz1rexR0B7HCG8l
	 vloHswhqGTnRPsIelIFWY24288wh2izec/m9cro0zButbUNKTHp4lRRkUHi84Ja5V1
	 rCWqKsl1K1iWLOuZrv7rgdETeSijzFJ5G5qIhptnTui/53vIQ9hYw/QcV48qXgfkVz
	 tQHuNkzoly0ZXMIWoCBL5ybb0rrabfGDgl0T33yxIsac1ZouTwdK+BAcxyNTf/ORbS
	 5Aan1fymqhrtyc0MoC6NmkG5O3/Zh0QsUAtqU3Re64uoGCmyAqKK8nq7izgg2hLaq3
	 Xcp6feiEQMHBw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH=2016/16]=20HACK:=20Add=20sev=5Fconsole=20hypercall?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747391098333
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" 
Message-Id: 
In-Reply-To: 
References: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.7f39565cc8474cdab9afc80d3eba8c0e?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 10:24:59 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Introduce a basic console hypercall for debugging needs under SEV
when PV console is not usable at this point. This is later on used
by the earlyprintk of the experimental SEV Linux branch.

Signed-off-by: Teddy Astie 
---
 xen/common/coco.c            | 6 ++++++
 xen/include/hypercall-defs.c | 2 ++
 xen/include/public/xen.h     | 1 +
 3 files changed, 9 insertions(+)

diff --git a/xen/common/coco.c b/xen/common/coco.c
index d9bd17628d..23c0da6281 100644
--- a/xen/common/coco.c
+++ b/xen/common/coco.c
@@ -131,4 +131,10 @@ long do_coco_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     }
 }
 
+long do_sev_console_op(unsigned long c)
+{
+    printk("%c", (unsigned char)c);
+    return 0;
+}
+
 __initcall(coco_init);
\ No newline at end of file
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 6c01a9e395..19f40f0b38 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -210,6 +210,7 @@ hypfs_op(unsigned int cmd, const char *arg1, unsigned long arg2, void *arg3, uns
 xenpmu_op(unsigned int op, xen_pmu_params_t *arg)
 #endif
 coco_op(unsigned int cmd, void *arg)
+sev_console_op(unsigned long c)
 
 #ifdef CONFIG_PV
 caller: pv64
@@ -297,5 +298,6 @@ mca                                do       do       -        -        -
 paging_domctl_cont                 do       do       do       do       -
 #endif
 coco_op                            do       do       do       do       do
+sev_console_op                     do       do       do       do       -
 
 #endif /* !CPPCHECK */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index e656d6f617..04fc891353 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -119,6 +119,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_dm_op                41
 #define __HYPERVISOR_hypfs_op             42
 #define __HYPERVISOR_coco_op              43
+#define __HYPERVISOR_sev_console_op       45
 
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 10:35:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:35:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986904.1372429 (Exim 4.92)
	(envelope-from )
	id 1uFsPl-0007uz-EA; Fri, 16 May 2025 10:35:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986904.1372429; Fri, 16 May 2025 10:35: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 1uFsPl-0007us-AM; Fri, 16 May 2025 10:35:41 +0000
Received: by outflank-mailman (input) for mailman id 986904;
 Fri, 16 May 2025 10:35:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsPj-0007um-2x
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:35:39 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20631.outbound.protection.outlook.com
 [2a01:111:f403:2413::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 80453b3d-3241-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:35:36 +0200 (CEST)
Received: from IA1PR12MB8467.namprd12.prod.outlook.com (2603:10b6:208:448::9)
 by IA1PR12MB6017.namprd12.prod.outlook.com (2603:10b6:208:3d7::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.20; Fri, 16 May
 2025 10:35:30 +0000
Received: from IA1PR12MB8467.namprd12.prod.outlook.com
 ([fe80::1633:cc45:8177:a91e]) by IA1PR12MB8467.namprd12.prod.outlook.com
 ([fe80::1633:cc45:8177:a91e%4]) with mapi id 15.20.8722.031; Fri, 16 May 2025
 10:35: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" 
X-Inumbo-ID: 80453b3d-3241-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=aPjMg96UZQTaWDKEFNOmR9ZH9xruJOkOwvlFTRtFlNnxjWSRBbRtI6F+SjsG1Eki7ilnx8veGyUYXvCcym+4Mg4UkBR84fjAG6JjtIwDOEMxWBt4qQQQbLWs5yLjdvdxdJMjZp15h+Gpi002MqnQ9dTjO8Zv/XsFoFqvxlnrGTPjVy+ckFYCZS1L1rKSblyOfx0oOvESu9q9Gv+oTp1iBDZqFvpNZMwaij0I2tTjv4UXocq/fhXLPipQIQqwhc7u48U8TtRJf+f6F8GSMFC59DteCQfiUoVpu9n70ydgej+YsO9qnW0j9ghRBJf5S0q13tF5atJJ/TzLSzP9ZQq10A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uO1PhjOK2fmhLrtpYBtEjeTUyUHJHvaSqwq4YTHfA+U=;
 b=VtWpNhnz92IyI7Sts8lTPXoZ8zeepwew6lkILTZRaFd9OCheN8HLY+NbB48N71YxY4TD6TFU1My9+dhKruz3M4DhOFbsfIWLzD4OprrW9rOZUKzEH1K6LPtrh/4zAjXedn7mL0rg29Y3p3Uk1XkTgsU5fUN+N+z6GFHEFTTf7v0XFP+2pDjVeheVVhzzvjawMDm20gLnT5pNwPMuquq2zs2YokNsB8TkeF9yb5nCaa5yNYDX3dnK4zLLXQU7bWu5JOpWeAMvoxDj92uGPhvdaNed/jABtyQuj7ulzOCuLAfKx/j6ViOF8BQrm7Lu0xm5VxeHrkNuPUJeZO3P2U4Gnw==
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=uO1PhjOK2fmhLrtpYBtEjeTUyUHJHvaSqwq4YTHfA+U=;
 b=ftRS/104J88Wx1sgqNHjhDJMGdjhhzjysaBGJxVakJe3OoiiiZwQEMhj/5RbL325hMMdKFdNLHc0dxu7hkygwli8Dino+ubqJEmm1LuRphrSrPL/siRCMJF6JnmuSFIRWF91gR01iiMYZgmRKqeSMAvTeVATx52ZyKR+XRhhEuE=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Anthony PERARD , "Orzel,
 Michal" , Julien Grall , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 03/15] xen/x86: introduce new sub-hypercall to
 propagate CPPC data
Thread-Topic: [PATCH v4 03/15] xen/x86: introduce new sub-hypercall to
 propagate CPPC data
Thread-Index: AQHbrRCmWPNHyarMuUaK4nZ2TXIaALO5UliAgBvrnhA=
Date: Fri, 16 May 2025 10:35:30 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-4-Penny.Zheng@amd.com>
 <2e1de23f-cc79-4d37-8667-0afd07736db3@suse.com>
In-Reply-To: <2e1de23f-cc79-4d37-8667-0afd07736db3@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=8c18a3d8-a11c-496e-a897-9e0563ae00ed;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-16T10:35:21Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR12MB8467:EE_|IA1PR12MB6017:EE_
x-ms-office365-filtering-correlation-id: c2914a39-5b64-4a9f-5bfb-08dd9465617a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?L3ZwVDlzME9QUzE1ZCtuRDVaL3h3SXNVSGhjVTdXUzE3UXQxR0xlQWN3SnBn?=
 =?utf-8?B?TGZGL28vT1BHeFIzYWZBT0hCTnRsb3lmaWhGTTFGWVpEdDJnWE9ZamdCTjlw?=
 =?utf-8?B?TC8vL1BFUkpNYkZJTklzaTFxSjVaVG9waXBHNXJRUC9pYTVpczZwczZwRXdH?=
 =?utf-8?B?cUNGL09MZ2RWYWRBV0M2dGFLZW56dlFlQWZ1UjFmVDFmajM5em52ZlE4dnJ2?=
 =?utf-8?B?am1NTVNXRExha3RBRlV1UjBkTERjT2ZvWGFXMHNqUzJzdzlyL0VUdWpYODRs?=
 =?utf-8?B?c2lBaDdmY3M5VHB5eTlGcDExdVRyZmRIQ1VydFNhNWE5dGlMelU3QXpDNzh0?=
 =?utf-8?B?d2F5MEN5cnlJUlcwdHV2TWM1MFQ4L3k1NG1IRGRtSDBWUGpXaGJPeUVHUnJz?=
 =?utf-8?B?ZFRpdFNIc0FnUzhmWEQ4S29HcUJaNk9pakh2RW9yZXR5MWVoQ20rc3diWm5I?=
 =?utf-8?B?RlBOWWxydDd5YTdHRjQwVHFMNHQ0ZUJQREFrVXJGdS9vc1Y0cVQvU25xQnBD?=
 =?utf-8?B?d0JDU29VYVFyRExpeUpKamw4QTJ5NXZnVWE0MXhUbDFDUWxUbXFsc0FoTHFI?=
 =?utf-8?B?MVMrWEN1Z1Y3TWhFTlIrVko3dkx5K2o1N2w3UEtLNlR1eWpvUWV2ZjA3cllv?=
 =?utf-8?B?eFNjSG5SOW9ZZHRxNkZFK0JyRVp2QTJ0c01LUWVpVUp1SmVpdWVycjZnanV1?=
 =?utf-8?B?aXlUTFYzR1J0eEpxY0dwY3NYaWxiWW9qSm56T2c4YnRHZG1aQUlkUVhVUHRt?=
 =?utf-8?B?NWtTMDdHWVV6Kzc4WUNadFFiU2VUeUpmbjQ5YTZnQk9aZ04vWDhDUDl3cklh?=
 =?utf-8?B?MWVCdDFkbHRRTUdLZVdvdHVBSzVZOHVnWDVhbEZ5WXNBTFdBM3RpQXFma1Rs?=
 =?utf-8?B?a01jaXBYNUVaQ0FaOXBSNEhmQzdpUlhJU3lQRitpVTFXcnBSTCtGdGs2YVBV?=
 =?utf-8?B?RjQvb0tZNktFWGIxYU5pSW5pRnZZKzJnQ1dGeVcvTjc0MzJ1alBBTm1BNGVi?=
 =?utf-8?B?elRkTjAyMjY0TWFVdngvNklKSXlFWGFMNjRYYzNqVjFHek1TTjVoUVpnbnBR?=
 =?utf-8?B?UGJWdFRGQy9mQ0xTaDlISjNrOEQzdEJvcVBueVBwMm0vRUhVSnBYdE9ydXJR?=
 =?utf-8?B?czdPSGZMWG8wbE02Ylc0SHk2cERsUmdrY2V3eGtuSjgyVDh0bWY1cG1wL2Nl?=
 =?utf-8?B?ZVJHNXlKM3psM3JmYXdhSVFlL04zbHVqaGp4azduVTVWcXo4MmViOFdoaXp3?=
 =?utf-8?B?RVN1U2xUV0hVSHNYMDVXeE8zTDk3cTBjZEZ2Z1hIQ1ZiZnAwQUkzSEJ4bVFN?=
 =?utf-8?B?cS9JT01FMEFOSVUxdkFBSnd4OWFzWk9hOFJadGxYelQ0bUZtL3VpY25oN0JE?=
 =?utf-8?B?dFN4ZWZpZElZS3BZdTNMTyt3dkFtVE1kRTRUdmgzcTBCVFlCTVMydmJ4dVBx?=
 =?utf-8?B?WGJkR0pvUzlaN3F5cVd0MnpYU1BIUFBGSHlVT2drdUI5bUxYSjhmWWlxWTNF?=
 =?utf-8?B?M0dhaE54MExXSFpmeWJ1L0ZCMk05UFpmK0Vxd2NmSzVHWDF1M0NUZFRFb2Iv?=
 =?utf-8?B?bGFobm95K1BKOUpzSUx0N1ByWmZlcU1sSzZpcXBPUDUzdWY1OThkRnhra0NW?=
 =?utf-8?B?ZUJLZ1lyWnNFcFFKemFyemZLMHFHWHppd0thRC9IM05lMU1DelVKditydG9v?=
 =?utf-8?B?L05hN1RBbkdZNkwvS0ZqUnJBOFQzUzlJT00yeDhtTWgxdzdjKzJYTUxmYlkr?=
 =?utf-8?B?MjBaVml2VGFsU2l6d3JnZ3FOSHVkdm5WU3phVXRrV1krMGhXZWFhOVZ0b1Z5?=
 =?utf-8?B?WjlQRE14anFDak11WStoZ1BONHo5cXZXQXhFS2JuQncxT0oxcDhXWTJyZzNV?=
 =?utf-8?B?b0c2SFFIYytNa0t2bzdwdGg4QXRGK1B0NUFleGtiZ0Z6bGZNcU4rNmEyUjk5?=
 =?utf-8?B?RENYSTZJckVocTBNMHB3ZW5VeC9YdmhnbHZGNUd4ZExZNzB3SVFwbXBuYWVQ?=
 =?utf-8?Q?HT882ikASJRUVCFj4T0mzxJNvGg+ik=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR12MB8467.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?aWg5SXFQSkwrOHJRMkl2aHhCaVlGNEx3eENuZVEwYWlCOHJZZGIwTExibUth?=
 =?utf-8?B?K1ZiZG9rblcxVHl1R3RDVHVEdGhmUVZkeHBuZFZqOG5yeGQyRXdZamVsc2pW?=
 =?utf-8?B?M3lBTWh3OHZQa2RBRFhvZ0xaQmFxb21qTUNaQTVOd3Z5Vmc3ek5DOW0wcXZO?=
 =?utf-8?B?cWxmVVVtN2piZ0xmM1c1Y2VWSUI5bXlCTERHZjRveEsvcXpZS0dCSk93MkR0?=
 =?utf-8?B?T3BEY3VScEFZVERlNGtFeEFTQlFxWFF2V1R4TjRvSkJYSnRWZEpIWmdRVW13?=
 =?utf-8?B?UDJiQlZMUDRjamIyV1dzMWppMEJzVWZySDZMY2lrME5wdkV5dHVUdlRBT0tQ?=
 =?utf-8?B?ZkRZbHpQeitGcW44bURpV0MyOVA2MHZQYVlPZG5qZ1ZSdXFxR3JjeUZ2WUMx?=
 =?utf-8?B?S2ExZE9MZlJpL3M2aDNSVlRFU05vTFFiVXhtdVNCT2tON1V3dGVpZW84ZnI0?=
 =?utf-8?B?VVc0bHdMbVBrT0trZlFCZENQN3ZXeWlZbURUeVFOYmF0bkVtcXdGSnNtTjBP?=
 =?utf-8?B?SlhkNEVjbzZSQmZuclcwQVNxNzg4cUNzSTBCd3BUWWp4YzZ5cWo4K01Hd0oz?=
 =?utf-8?B?U0M3TGNsSi9oZEdxSmpXeC9mYlc3ZlZIY2h0U0N0WFJQRkpoNXBDcE55K3Ni?=
 =?utf-8?B?dCtLa21FRWVHQmY2TEpzNjFTRFpLZzNLUVJCWnNaZC81U3pVV1dTeG1Od2Jt?=
 =?utf-8?B?S3lzQ2M3djcyQitRUm5SOUtvcU10dklYdnRnbzNsdlNKSUtMZGtXQ3hVdE5j?=
 =?utf-8?B?U0xsZGJXZnZSV3l1Ym12V0hSQkNtUFdQOGFmVFBvWnVlU2h3MUhXcEpyWHRE?=
 =?utf-8?B?c0MwQ1Y3TTVEVFlRVVRCQy9jTHQvMU5kQW14aXhtTmlheWhtVjREWlFrcHda?=
 =?utf-8?B?eGRYZm8xM2hGR2ptTFN3c1I3K2N6ZU13cFZvMzlZTWFuYVRLTk9MMDhqeXVr?=
 =?utf-8?B?dFdoYzYrOE5Ib3AwbVUwWlhESkhMZC9OSzBNQnh1dVF5aVRGRUVqbXhmamNh?=
 =?utf-8?B?NHRGQzdwVzgyNVNwV3lxQ1dnQnZEL2l2Z2N1cTQveDgvTUx5TEZieHJsUnFL?=
 =?utf-8?B?cjJpRXM2UWd3SmRzTGxYOU5ldFM3d3RHbGgyQVlYdDUzeGQrdDZpN2IzY3Jz?=
 =?utf-8?B?d1BmeDRzYy9rWWlVeUJPYW0rMzBqdVI0QUQzNDVtWWFRYjJ3Yk0xMStGY2hr?=
 =?utf-8?B?YVVmamJ3NUpINStVMUkxUU1mbTkyUjVZRnQwM0VUTUpBNEtITTFFWWN4S3FD?=
 =?utf-8?B?YlN3cExENFBGYUJIOTd1VXduaWo2K09COTZ4ZFZFeTB3aGxOd1JkWWJVb2kr?=
 =?utf-8?B?dmZ4KzRrcDNEVTczTzhTcHhYeEFla2tRVkt0SEU0bDNsUmxVVTBlV0tBSXps?=
 =?utf-8?B?cWRMTWIycjJEaFpNVGtYUWZNOFZRa2ViTTVhVSt0SGlBVDgzYTJ0c0xBM05m?=
 =?utf-8?B?VXpmam85NE9ReWZHeWJEU2pQbDAvcFlDUHZ4MDNTY3ovcDhCSjdjZ1lKUUxR?=
 =?utf-8?B?Mm9NM0FUWXZQZUhhcjIybVJUUlF2RlN0Sk84UEx0OENPZFV5VGN1ZTJyN3NW?=
 =?utf-8?B?d01vbzZjMVptdFYwREY5Y0hjQlNnNEFJTnZOVWpUSUFkZHRybDAya210NVJ0?=
 =?utf-8?B?dk1jNHpsc2tFZW5KdVduWHpUL0JpbHVZUTRIbXk2K0xKRXA2bWpOcjJvbkRw?=
 =?utf-8?B?ZURENXp2VWh3QnEzM2FYbUpXQlJRVVhuck93L3dnS0tTM2hOMmZDcWdtVUhK?=
 =?utf-8?B?WTFaYmN3Zldqay83cGlDcmVGZTBpcnJobkdxYVFZVE1SY2w0NXhrV2VPdDZ1?=
 =?utf-8?B?b1VlY0d4YmQzUTBIaE1MTDA3ZnJLKzNtQ0RjcHZ0WjdsNkJyT00xUkY5SDYz?=
 =?utf-8?B?YitLcWwvVTFnTlEyaXVYRVBpRFVMYkt5akNleGFMWXltd0dBb1dOaDlkSFBM?=
 =?utf-8?B?dlVFb0N6TXAzMlJ4T2o0cVJqUGlFZ1AxOXdVU2Y2N0duRXNPNEtlMDNUTGFu?=
 =?utf-8?B?SXNjQmZXNktUS2g4b2RCbzRKbXp1VDZCWE4zR205NFB1a3pzQ0ltTy9MaDBi?=
 =?utf-8?B?T2ZoNnNXWEtQTTFjKzAvajBUSWhyWjR4b0MyeGxaYkZpbzlvMGd2MFI1aHpj?=
 =?utf-8?Q?Ig1A=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB8467.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c2914a39-5b64-4a9f-5bfb-08dd9465617a
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2025 10:35:30.4063
 (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: xziX0exVmyu1ezsGutz7ZoXNlApZ3U28zURId5mP8YQ6alyKloSPTE8/dcuPDGtLZEjcy4BxfS5Alf1Rz8Rl3g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6017

W1B1YmxpY10NCg0KSGkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBK
YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgMjgs
IDIwMjUgMTE6NTcgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4N
Cj4gQ2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8
YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBj
aXRyaXguY29tPjsNCj4gQW50aG9ueSBQRVJBUkQgPGFudGhvbnkucGVyYXJkQHZhdGVzLnRlY2g+
OyBPcnplbCwgTWljaGFsDQo+IDxNaWNoYWwuT3J6ZWxAYW1kLmNvbT47IEp1bGllbiBHcmFsbCA8
anVsaWVuQHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHNzdGFiZWxsaW5pQGtlcm5l
bC5vcmc+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQ
QVRDSCB2NCAwMy8xNV0geGVuL3g4NjogaW50cm9kdWNlIG5ldyBzdWItaHlwZXJjYWxsIHRvIHBy
b3BhZ2F0ZQ0KPiBDUFBDIGRhdGENCj4NCj4gT24gMTQuMDQuMjAyNSAwOTo0MCwgUGVubnkgWmhl
bmcgd3JvdGU6DQo+ID4gQEAgLTQ1OSw2ICs0NjQsMjYgQEAgc3RydWN0IHhlbl9wcm9jZXNzb3Jf
cGVyZm9ybWFuY2UgeyAgdHlwZWRlZg0KPiA+IHN0cnVjdCB4ZW5fcHJvY2Vzc29yX3BlcmZvcm1h
bmNlIHhlbl9wcm9jZXNzb3JfcGVyZm9ybWFuY2VfdDsNCj4gPiBERUZJTkVfWEVOX0dVRVNUX0hB
TkRMRSh4ZW5fcHJvY2Vzc29yX3BlcmZvcm1hbmNlX3QpOw0KPiA+DQo+ID4gK3N0cnVjdCB4ZW5f
cHJvY2Vzc29yX2NwcGMgew0KPiA+ICsgICAgdWludDhfdCBmbGFnczsgLyogZmxhZyBmb3IgQ1BQ
QyBzdWIgaW5mbyB0eXBlICovDQo+ID4gKyAgICAvKg0KPiA+ICsgICAgICogU3Vic2V0IF9DUEMg
ZmllbGRzIHVzZWZ1bCBmb3IgQ1BQQy1jb21wYXRpYmxlIGNwdWZyZXENCj4gPiArICAgICAqIGRy
aXZlcidzIGluaXRpYWxpemF0aW9uDQo+ID4gKyAgICAgKi8NCj4gPiArICAgIHN0cnVjdCB7DQo+
ID4gKyAgICAgICAgdWludDMyX3QgaGlnaGVzdF9wZXJmOw0KPiA+ICsgICAgICAgIHVpbnQzMl90
IG5vbWluYWxfcGVyZjsNCj4gPiArICAgICAgICB1aW50MzJfdCBsb3dlc3Rfbm9ubGluZWFyX3Bl
cmY7DQo+ID4gKyAgICAgICAgdWludDMyX3QgbG93ZXN0X3BlcmY7DQo+ID4gKyAgICAgICAgdWlu
dDMyX3QgbG93ZXN0X21oejsNCj4gPiArICAgICAgICB1aW50MzJfdCBub21pbmFsX21oejsNCj4g
PiArICAgIH0gY3BjOw0KPiA+ICsgICAgc3RydWN0IHhlbl9wc2RfcGFja2FnZSBkb21haW5faW5m
bzsgLyogX1BTRCAqLw0KPg0KPiBUaGlzIGJlaW5nIGEgbWVtYmVyIG9mIHRoZSBuZXcgdHlwZSwg
Li4uDQo+DQo+ID4gLS0tIGEveGVuL2luY2x1ZGUveGxhdC5sc3QNCj4gPiArKysgYi94ZW4vaW5j
bHVkZS94bGF0LmxzdA0KPiA+IEBAIC0xNjgsNiArMTY4LDcgQEANCj4gPiAgISAgcHJvY2Vzc29y
X3BlcmZvcm1hbmNlICAgICAgICAgICBwbGF0Zm9ybS5oDQo+ID4gICEgIHByb2Nlc3Nvcl9wb3dl
ciAgICAgICAgICAgICAgICAgcGxhdGZvcm0uaA0KPiA+ICA/ICBwcm9jZXNzb3JfcHggICAgICAg
ICAgICAgICAgICAgIHBsYXRmb3JtLmgNCj4gPiArPyAgcHJvY2Vzc29yX2NwcGMgICAgICAgICAg
ICAgICAgICBwbGF0Zm9ybS5oDQo+DQo+IC4uLiBob3cgY2FuIGl0IGJlID8gaGVyZSB3aGVuIGl0
J3MgLi4uDQo+DQo+ID4gICEgIHBzZF9wYWNrYWdlICAgICAgICAgICAgICAgICAgICAgcGxhdGZv
cm0uaA0KPg0KPiAuLi4gISBoZXJlPyBBbmQgd2l0aCBpdCBiZWluZyA/LCB5b3UncmUgbGFja2lu
ZyBhIHBsYWNlIHdoZXJlIHlvdSBpbnZva2UgdGhlIHJlc3VsdGluZw0KPiBjaGVja2luZyBtYWNy
byAod2hpY2ggSSBhc3N1bWUgd291bGQgY2F1c2UgYSBidWlsZCBmYWlsdXJlKS4NCj4NCg0KVW5k
ZXJzdG9vZCwgSSBzZWUgaXQgYXV0b21hdGljYWxseSBnZW5lcmF0ZXMgQ0hFQ0tfcHNkX3BhY2th
Z2UuIEkgc2hhbGwgY2hhbmdlIHBzZF9wYWNrYWdlIHdpdGggPyB0b28NCkluIG9yZGVyIHRvIGF2
b2lkIGNhdXNpbmcgYnVpbGQgZmFpbHVyZSwgSSBhZGQgInR5cGVkZWYgc3RydWN0IHhlbl9wc2Rf
cGFja2FnZSB4ZW5fcHNkX3BhY2thZ2VfdDsiDQpJJ20gbm90IGZhbWlsaWFyIHdpdGggdGhlIGNv
bXBhdCBmcmFtZXdvcmssIGlmIGl0IGlzbid0IHRoZSByaWdodCB3YXkgdG8gZml4LCBwbHogbGV0
IG1lIGtub3cNCg0KPiBBbHNvIHdoZW4gbGF5aW5nIG91dCBzdHJ1Y3QgeGVuX3Byb2Nlc3Nvcl9j
cHBjLCBwbGVhc2UgYXZvaWQgdW5uZWNlc3NhcnkgZ2Fwcw0KPiBvciB0YWlsIHBhZGRpbmcgLSBp
dCBsb29rcyBsaWtlICJzaGFyZWRfdHlwZSIgd291bGQgYmV0dGVyIG1vdmUgdXAuIEkgdGhpbmsg
aXQgd291bGQNCj4gYWxzbyBiZSBhIGdvb2QgaWRlYSB0byBtYWtlIHBhZGRpbmcgZmllbGRzIGV4
cGxpY2l0LCBhbmQgY2hlY2sgdGhlbSB0byBiZSB6ZXJvLiBUaGlzDQo+IHdheSB0aGV5IGNhbiBi
ZSBhc3NpZ25lZCBtZWFuaW5nIGxhdGVyIChpZiBuZWVkDQo+IGJlKSB3aXRob3V0IGJyZWFraW5n
IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5Lg0KPg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Fri May 16 10:38:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:38:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986923.1372438 (Exim 4.92)
	(envelope-from )
	id 1uFsSI-0008U8-PW; Fri, 16 May 2025 10:38:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986923.1372438; Fri, 16 May 2025 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 1uFsSI-0008U1-Mb; Fri, 16 May 2025 10:38:18 +0000
Received: by outflank-mailman (input) for mailman id 986923;
 Fri, 16 May 2025 10:38:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFsSH-0008Tv-Ja
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:38:17 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d9140c02-3241-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 12:38:04 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ad2452e877aso296716666b.3
 for ; Fri, 16 May 2025 03:38: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
 a640c23a62f3a-ad52d04e821sm136950066b.17.2025.05.16.03.38.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 03:38: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" 
X-Inumbo-ID: d9140c02-3241-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747391884; x=1747996684; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=hQ7Hd87HNDW0MzwrSZRli/A0eaSCQqXZn4YO+frEP3A=;
        b=Kn6cJh6PKhWR6HoMCn0L1BLpbXeq+lMkeS0t8E44ZOtyEttivr/B6IzbhNlLZ3oUs4
         glDtVUTUDgN1UMJxfF+DDZ4h523kyiiO7vv0Kyc4C/Q83P5XvJQlCbEoF4Fb4kI9BbVH
         P7nIJa05bdWH8UhBznGAI8wCWTfIErvMfG8R/bzbGjcsbri6yc3E7TdOOhBxvdlNPW2W
         dUkyZiphw7Bl9Mv6R/HIEa0/Bp68+E2Zu0nZrnQqv/mj/TLNRlANTD5UCzlbDYC5Pwdh
         sq8+6gaW3iQsRJ1xRNQDWunyo9YhEh/dsS+6Gxufs+ZOPtewi0nrZSG+szh8reXEnB2s
         nKbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747391884; x=1747996684;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=hQ7Hd87HNDW0MzwrSZRli/A0eaSCQqXZn4YO+frEP3A=;
        b=f4ZpMO0BTCauatTonZfdWngRyHd9RogrRZ4KDRqJP+ya6MkXbxvHUdT3vzsyM4M6m0
         6sIMm6I/geOjseFpGw6aMdpacbCogxyDn9nUj2bcgLie6bp13O8vP0MQzpR2LU7J4txQ
         JwTZRk5FKZ2pPSOCTw9bR8zv63eDTNAFBWEqjhOp7zR2hMsAQ+3XVU8vtZcrl+agpAqv
         zCBeOPl9h/3ohCqOBVOCS+L9rJXe1Nz8pF1/p9BcWXGgOi00NRMGIEcF7JudDbcIvNXO
         fzSf0n8r0G0RApRUVEPOhmq8LNK+fuGGIAMTQWO/43P6UQXh4vVCHdk6mFztC27+Lnxx
         +szg==
X-Forwarded-Encrypted: i=1; AJvYcCUpZM9hwcnGAm3bvAUraOVI2CvF4ccTcuh1O0xYN6wGiwncEKQooYh+HaqIwLP3L90i7a0/vyyjKYM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwSb4f51GROf+qEmI0ObHcSH9nw2SOgO5AYU/pH8yNrsIkCQ5XR
	BCSf8oayR9JzvIfO00U2NIsIUwJD0oXNo/AeDSgYs5J4iJvmf3sHcVxcFgAWfxizCg==
X-Gm-Gg: ASbGnctILBCbNJI6TlIsonLcDa/gpIZfUCEPZUO1zAvtkOjgKShXxy+8O+qMxoHy81W
	aBZjckx+O4JyuT5MV0/+5f2fvaJQkKfT6WLilW5qrV6oAVBRbQ8KATMBJ081XwulEfPzpva31xu
	F9vCcORPxgweEQcaWIKLMmrfuAJ4Ti/lyIlcrTR88CabHvNBaAQMan2Ar5WbQdzFEKEnS266AJ7
	4lpX1wQq3CbaSZ0UQdgBlzDx5QIal2Nk5w1j03SUM9C65pHnPsE8ZUViMyZXbi0QJVYeb0leP/U
	joFFJS0/KuCeuFJFVEMuqdZ3szj4CKLfeXRdHkBU09Kfc77VlTDonM3NVGEHGjBksx3oGVt0A1K
	UNNSSEo2bZW8eI172onjYXfYKtd8d/USxfMK9
X-Google-Smtp-Source: AGHT+IGzb1egvPvnA8XI0Kya/EZBWWSS3lu0jifzdeGaP3m17xxysht+ccq3tnrzQ8JVxzALorBhkg==
X-Received: by 2002:a17:907:2d1f:b0:ad2:40ee:5e29 with SMTP id a640c23a62f3a-ad536b56f88mr174089566b.10.1747391883980;
        Fri, 16 May 2025 03:38:03 -0700 (PDT)
Message-ID: <885b6722-5a68-419e-9d63-bf5977194c96@suse.com>
Date: Fri, 16 May 2025 12:38:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/6] x86/gnttab: do not implement GNTTABOP_cache_flush
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Oleksii Kurochko ,
 Community Manager ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-3-roger.pau@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

On 16.05.2025 12:31, Roger Pau Monné wrote:
> On Fri, May 16, 2025 at 11:48:48AM +0200, Jan Beulich wrote:
>> On 16.05.2025 11:45, Roger Pau Monne wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -35,6 +35,11 @@ config GRANT_TABLE
>>>  
>>>  	  If unsure, say Y.
>>>  
>>> +config HAS_GRANT_CACHE_FLUSH
>>> +	bool
>>> +	depends on GRANT_TABLE
>>> +	default ARM
>>
>> To keep arch stuff out of common file as much as possible, I think this instead
>> wants to be a "select ..." from ARM. Then:
>> Reviewed-by: Jan Beulich 
> 
> My first attempt was to do it as you suggest, but then if the users
> disables GRANT_TABLE you get the following warning:
> 
> WARNING: unmet direct dependencies detected for HAS_GRANT_CACHE_FLUSH
>   Depends on [n]: GRANT_TABLE [=n]
>   Selected by [y]:
>   - ARM [=y]
> configuration written to .config

Right, it needs to be

	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE

(and the "depends on" on the new HAS_* can also go away; HAS_* imo shouldn't
normally have any dependencies).

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 10:41:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:41:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986934.1372450 (Exim 4.92)
	(envelope-from )
	id 1uFsVl-0001q4-8N; Fri, 16 May 2025 10:41:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986934.1372450; Fri, 16 May 2025 10:41: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 1uFsVl-0001px-4O; Fri, 16 May 2025 10:41:53 +0000
Received: by outflank-mailman (input) for mailman id 986934;
 Fri, 16 May 2025 10:41:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFsVk-0001pr-IE
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:41:52 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 60551822-3242-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 12:41:51 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-600dbfe7b37so1232477a12.2
 for ; Fri, 16 May 2025 03:41: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
 a640c23a62f3a-ad52d2779efsm136249566b.77.2025.05.16.03.41.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 03:41: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" 
X-Inumbo-ID: 60551822-3242-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747392111; x=1747996911; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=SbAH3afseT0IFEIiUqd5KdjnhZsxM22cO8YrFfFbM0o=;
        b=ECt/wjzCtAVW2LUrNblc7duJ0nbD2xxNp1DfMxGDUeALEX5VItMntxhhISE56W0BCh
         RWgaYH+71zbed4L+2KvbpUC8+MuCULzalRMhw5lUbSvINgG7EuKTL+wx6AuA9+PV/a5D
         6Pz0/xs9L4aX+BXjTi0Mu1HF1l8wBAhp32VGDxiAzdYsbSmOIVmsfmaxyMjbk+49B3VV
         +NB2ybMunqSgxCFhFUjeM75sJcTXUO0v9VsT7BCCGsrSSw+jOIKMVHhMuQGH9VQcU6Sx
         e7nQMRu/oCANwSGi0V+jWSOaEfmHsfr13bYjZAdk756Izth1z1kBWBACL/pU6Y1mbkeo
         YqDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747392111; x=1747996911;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SbAH3afseT0IFEIiUqd5KdjnhZsxM22cO8YrFfFbM0o=;
        b=OumqwxozNEQbWnSAnRtrf/JlTVWAAFIfpiPRLW3tS69VDjSYuvETjhjHmntD0UvmA/
         m2CtVFEiOifmQgBPFwoxBZ/AY5ZbkEnYzCngzAmEljRjNgKmG7GbzZTXsOu/aQnVO4Jq
         NNU6pUP0DoTy0r5vKJPpfTjC+2ZSAt6iy2veKxWAZmF/oV5xsppAchxU4THCfH2DFo69
         yHMWuDQxa8P9SN35iEkMLA5lZOBo0PCY/wEUoJ0Kxeteid35smzA2r/xYFWD2NY6E/19
         ICVkrY+C0t47eM+qXfPxqDEZVNXwVYTZwunQPxP/ECdt0gYkmrvyX0GAMibkqKKHIqeK
         Qmpg==
X-Forwarded-Encrypted: i=1; AJvYcCUgBFhJc2pk77ODQHI/sslBbX76wgN6INpA+uFuXMXF6ZDCB3IsYn9ay/bikFevXPSBuaOjiA312jg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzGuaBJ2Vrn4w0qPPTaYCf/Nq9qjJA8rzXuL8kGFHZPCJFPEiDc
	utBfgvlrxummQfMTxJbxwQOPXXvFnGuwQCqwuDK1B2TYCZ9PWdqWqJPCQVVqwxFn1A==
X-Gm-Gg: ASbGncv7VLBTYotTBTkcTizY3Zduy0UwEclmJpQI784XNCFePuBnAaNzutKXF4xguiS
	2ygtpKnEkh0TZPIfse+mKvn5HpPhkkK5zOTo7KxCyQ3RKQR4QMLWfp6KaKoR2jFluq4DfPMfBsP
	gJPNVS62DpBUh8phgwmd7p2MsNq6WjZ/kTFEmaPudUO7zVlYnzuJn7a+ZmLY2xJ8v5hkLCI08PV
	1qX5+39rCyD9ef/NkjVyj2oc1sfQTvT4OamM5To/Ws4EqAaXJjtPBRFZ5+/TOpWmtphLvVtayeB
	QtefNUTP5zrCdi0GUlmWi0yJv6HHs1e5LX9LBtje6NLduIEH1axS2GLGHq56NPgiuj7kDw1sJfE
	YAjRv/YCoLTuWGoTnpOp+kmg3f26rLM7j+U1Y
X-Google-Smtp-Source: AGHT+IH6332YGZqxLMj0Loh9plsmr2aqO4CvcfVfZA1bmA/ntNN1fVgIvXfT5ZGqdRUuv1Iqb5oDaQ==
X-Received: by 2002:a17:906:c105:b0:ad2:2d84:ab80 with SMTP id a640c23a62f3a-ad52d65f554mr280206866b.58.1747392110962;
        Fri, 16 May 2025 03:41:50 -0700 (PDT)
Message-ID: <5d928ec5-b423-46d7-a8df-7be37b38b6d8@suse.com>
Date: Fri, 16 May 2025 12:41:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/15] xen/x86: introduce new sub-hypercall to
 propagate CPPC data
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-4-Penny.Zheng@amd.com>
 <2e1de23f-cc79-4d37-8667-0afd07736db3@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 12:35, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Monday, April 28, 2025 11:57 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> @@ -459,6 +464,26 @@ struct xen_processor_performance {  typedef
>>> struct xen_processor_performance xen_processor_performance_t;
>>> DEFINE_XEN_GUEST_HANDLE(xen_processor_performance_t);
>>>
>>> +struct xen_processor_cppc {
>>> +    uint8_t flags; /* flag for CPPC sub info type */
>>> +    /*
>>> +     * Subset _CPC fields useful for CPPC-compatible cpufreq
>>> +     * driver's initialization
>>> +     */
>>> +    struct {
>>> +        uint32_t highest_perf;
>>> +        uint32_t nominal_perf;
>>> +        uint32_t lowest_nonlinear_perf;
>>> +        uint32_t lowest_perf;
>>> +        uint32_t lowest_mhz;
>>> +        uint32_t nominal_mhz;
>>> +    } cpc;
>>> +    struct xen_psd_package domain_info; /* _PSD */
>>
>> This being a member of the new type, ...
>>
>>> --- a/xen/include/xlat.lst
>>> +++ b/xen/include/xlat.lst
>>> @@ -168,6 +168,7 @@
>>>  !  processor_performance           platform.h
>>>  !  processor_power                 platform.h
>>>  ?  processor_px                    platform.h
>>> +?  processor_cppc                  platform.h
>>
>> ... how can it be ? here when it's ...
>>
>>>  !  psd_package                     platform.h
>>
>> ... ! here? And with it being ?, you're lacking a place where you invoke the resulting
>> checking macro (which I assume would cause a build failure).

I guess this wasn't clear enough then: Aiui you cannot "check" these, because the
native and compat ones are going to be different. You'll need to use ! here, and
then use the respective XLAT_* macro(s). IOW ...

> Understood, I see it automatically generates CHECK_psd_package. I shall change psd_package with ? too
> In order to avoid causing build failure, I add "typedef struct xen_psd_package xen_psd_package_t;"
> I'm not familiar with the compat framework, if it isn't the right way to fix, plz let me know

... I expect this isn't the correct way of dealing with it.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 10:42:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:42:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986947.1372458 (Exim 4.92)
	(envelope-from )
	id 1uFsWl-0002eI-Is; Fri, 16 May 2025 10:42:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986947.1372458; Fri, 16 May 2025 10:42: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 1uFsWl-0002eB-GG; Fri, 16 May 2025 10:42:55 +0000
Received: by outflank-mailman (input) for mailman id 986947;
 Fri, 16 May 2025 10:42:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsMI-00034q-TM
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:32:06 +0000
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com
 [2607:f8b0:4864:20::433])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 02635dd6-3241-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:32:05 +0200 (CEST)
Received: by mail-pf1-x433.google.com with SMTP id
 d2e1a72fcca58-74267c68c11so1863991b3a.0
 for ; Fri, 16 May 2025 03:32:05 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-231d4adbfc0sm11446755ad.71.2025.05.16.03.32.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 03:32: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" 
X-Inumbo-ID: 02635dd6-3241-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747391523; x=1747996323; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=j0XKJISHS4dzAt7Jr7nklY20nUhhhSE6Y+hlXuQuwr0=;
        b=Qitva1uZKekuWHP4VV3PFxYZbY4EHTJvP4oUnlJ0YzczmAk6jwjox9S10SlNpcBqU4
         +8W4yVVHVKco7Gsn2h1BnpuDJjrGbFGPMVd3R82GaU7i/h3yu020sHM9ghW3I7TYK4C4
         O5KyMEYqxtaNXbsjJih4KUnsiXoVE79NF7QbQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747391523; x=1747996323;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=j0XKJISHS4dzAt7Jr7nklY20nUhhhSE6Y+hlXuQuwr0=;
        b=CpPNqGEDVtDNNXmfjttloFYvKa7FwUEoo8wcawl2EeDjvPeKdEjRFfsJ8ABqtZQqqD
         fkpr3JopeOUavOkCp3sFFivyk+9dYDtABOZNXrXl/NwQqU9c3vjw+bTGrOYsr2mzsxfd
         RSXI9Y8s67NAHgBgn4OR3DFyM4oiMtmwdfxbOaKV16LZurWf+iBH5s/5WUN5P204m4VT
         tV8qA694WcZ4/YxaA1jyX6ZBWfcsRDD99ISSWNwspIWgcRG0l+t493ZlmNHWg7wxmS7F
         gs5FtGPFPtSO2jGdkxvtrc7lqf2B+U81/rIC2NGacuSS3S9abTYLG2OLE36KxdKbiRYU
         dGSQ==
X-Forwarded-Encrypted: i=1; AJvYcCUPw260vVk/TsnkP5e7+WAUP6oEHeCwAkpSAR3fPVmyqO+UpGIKnMpw/Ky03EKuNbNxYygXT44MIpk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx4PRwEYu1lOmWc3TEu3k4NDq19/Obde7+Yw22xPiQvZEdFk+UV
	Wuk0snNe/g9JQF4IeGgDmWihtaDuxk4H+IJFg6RMAz3cfOrasUVJbPysP/uabCG5QCM=
X-Gm-Gg: ASbGncv1o4MDSNAP28H4qtJilNLonYSKr0KoCF0ICZVebv1Kgr4AxZDK4QBHdVcvFjs
	ajsYYR+jOzKh1BALrhSvSpR9WWrry3DKBSjV2s6U8hWG1cO+4U1FPYZk1ebLFmms0cekaYwi6+I
	hsVfG1LRl5up2eaCdJeFuEbgBA0tbe2ZbJvXJXTRjOZM/5EDjVuocYZpPnwId+/7fXkBJcR4ZpB
	x1SBgo80jisaz0Qo4FmUlbdSRVvi5IPfam+/AVmTsXZe3NNTzqi/Dav3PMDmfwtADriy816FKXD
	N4TYFxRttMb5I9v1PqrnZSrTVP9b7UcCOfzxnbJ/tPvkeVsLijgtQh8pVznt98rrK5BtF0Quwon
	SMimI68p815SClTgh/tg=
X-Google-Smtp-Source: AGHT+IGlNaLtx3XnHMNfgYitvZAlLM+sz/IioPtcGAwH7g8dwijbXXbdGIWss5GC48RmrclnhESTzg==
X-Received: by 2002:a17:903:1aec:b0:22d:e57a:27a2 with SMTP id d9443c01a7336-231de36bb6bmr25947565ad.23.1747391523582;
        Fri, 16 May 2025 03:32:03 -0700 (PDT)
Date: Fri, 16 May 2025 12:31:58 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/6] x86/gnttab: do not implement GNTTABOP_cache_flush
Message-ID: 
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-3-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Fri, May 16, 2025 at 11:48:48AM +0200, Jan Beulich wrote:
> On 16.05.2025 11:45, Roger Pau Monne wrote:
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -35,6 +35,11 @@ config GRANT_TABLE
> >  
> >  	  If unsure, say Y.
> >  
> > +config HAS_GRANT_CACHE_FLUSH
> > +	bool
> > +	depends on GRANT_TABLE
> > +	default ARM
> 
> To keep arch stuff out of common file as much as possible, I think this instead
> wants to be a "select ..." from ARM. Then:
> Reviewed-by: Jan Beulich 

My first attempt was to do it as you suggest, but then if the users
disables GRANT_TABLE you get the following warning:

WARNING: unmet direct dependencies detected for HAS_GRANT_CACHE_FLUSH
  Depends on [n]: GRANT_TABLE [=n]
  Selected by [y]:
  - ARM [=y]
configuration written to .config

And you end up with the following on .config:

# CONFIG_GRANT_TABLE is not set
CONFIG_HAS_GRANT_CACHE_FLUSH=y

That's why I've done it the way presented in this patch.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 16 10:45:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:45:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986959.1372469 (Exim 4.92)
	(envelope-from )
	id 1uFsZV-0003TQ-Vs; Fri, 16 May 2025 10:45:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986959.1372469; Fri, 16 May 2025 10: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 1uFsZV-0003TJ-Sx; Fri, 16 May 2025 10:45:45 +0000
Received: by outflank-mailman (input) for mailman id 986959;
 Fri, 16 May 2025 10:45:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsZU-0003TD-LB
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:45:44 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eacd50d9-3242-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 12:45:43 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-442fda876a6so6397835e9.0
 for ; Fri, 16 May 2025 03:45:43 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca4d0fasm2502282f8f.8.2025.05.16.03.45.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 03:45: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" 
X-Inumbo-ID: eacd50d9-3242-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747392343; x=1747997143; darn=lists.xenproject.org;
        h=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;
        bh=1TP5nhJJjHei6NVmalzJb6nTagBEkZYP1AtXWbPfby8=;
        b=e3tN0ehlPBYWm+EqyeAQC7Hr7l6wHqpqoATQNIzawcDrcoyKHEL8DPZfvqlWrzAJu+
         LhW0E7rFyz9P97yDHGno3ic1wQoknaxxxCCWP57Q9vBkuFjxLCIp+d1b6+7+M0xw6ZEy
         MHv4DNNg2vqfM+SXnbe5ZFMQW410sxy85OucJEB/HtlvzH9YbgUoBzOR2N3BFJK1RJ51
         WjAoRHh9HyVKScfwWgJITgL1I2igqHj1CkAlPoTjHKWOJxRXJtblg/7Zs5T8eoyB9S4r
         QrJ7Ou0JxC7t8xTXNHfDuRiTx7K0KCNIUB2BDjd6dgYqrO8NnQ9HqgtEeCOUAyCdSqoY
         ULew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747392343; x=1747997143;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=1TP5nhJJjHei6NVmalzJb6nTagBEkZYP1AtXWbPfby8=;
        b=wQGYsJqlxjRkEwcw1w1dut3botOv9iJ9UC9D3Wx/ek/4LiZgGGRdAMY6IDqmW21NLU
         GoVjaiJPfVzn2k1PD4xb2cpBxlDaZwf/XHOIzu4+VPbI+nTdQ8Fb3GsSi41cRA3jsPfg
         k5HL8VjNuT9X0/bPjo2QYVes1iFQJ7Se02bqDY6bMH36mj4PXqv/l3zR8ZMzFeFCT/QJ
         /ICYdStC8bWZbsJSAI/9tuobVO88o00/VMN/tkt9Y3tvHonu2J3WP4jobw3Btrmcbl34
         kdDWyQ3rkrmTd501KK7yzBwMIDFxmSS3gKovEN2gDPOJo6cFfi8x1bNTz8sTpXMGmrrW
         1D5g==
X-Forwarded-Encrypted: i=1; AJvYcCXuM7uVFRqKG9KX8a7weiUMzow3QNLTEgSKsaYmAE8z60nvvc2W/0/3nbQXsvzAuIaU5Ln1uS8+5GM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywd/KPh9hTJdy9QddfX+Jwt1TuT4POEXpKOqOKDSPjKZfW/o6s9
	KheHFQQVaKeLrtkQyhOf4v5fiFjDcv4sesYl6KNwiHKTKIpWMMVnVmcm
X-Gm-Gg: ASbGnct+AOVKex7kZGsDpV/I0DNsuH03jJ0At/1UogDAXb05hhDapycCGPl/Ms0Bwxh
	9mNaNX55aKNWSIjpY3VfL4oPcID/+l17Z68X/LodL9YeSh1b25V1ZppdWAg1mBjD0eziIdkCwYt
	Vm34sQfWfLRnRSZHlsHTvS04q7n9FEW/bdXLBDfBs4kVudYeZGf7gTTRe6OMbAjP8yAIxs/2FB/
	s2vs/hTwOhQZPuWkFb82qsUDATHWVOCeyvC0mZjNEnMORUvUL4gPL1JDHW0hKNMhv29zEUxEtkj
	hyHcPjFOZOhdFf3H6EGyAKv3/TeiU5Ijs/Y1fYOlNed4PcYHn/6ozUGWV8zc/XPzTh7EH2zL+3g
	jWqxPMRiz/gI140D7BHYLnvvXXoUBKHA+l8E=
X-Google-Smtp-Source: AGHT+IGpcTOC0GmG+LS/gnzIAUHavS7tIlwJyMjOVzJaoZcD2v+RST+ay2tgggbl+SomlSvfG5Xc/A==
X-Received: by 2002:a05:600c:45c3:b0:43e:a7c9:8d2b with SMTP id 5b1f17b1804b1-442fd664965mr29379235e9.24.1747392342861;
        Fri, 16 May 2025 03:45:42 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------tai8GTuIga5emhXukXCx0OXW"
Message-ID: <31d8bc62-6682-423c-b2c9-6ec9ea6b5234@gmail.com>
Date: Fri, 16 May 2025 12:45:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/16] xen/asm-generic: introduce asm-generic/irq-dt.h
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: 
 <35c68e57e5348c6610e030890802e967f6be4230.1746530883.git.oleksii.kurochko@gmail.com>
 <74c6872a-7221-4656-8655-16b53f9b2bd7@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <74c6872a-7221-4656-8655-16b53f9b2bd7@suse.com>

This is a multi-part message in MIME format.
--------------tai8GTuIga5emhXukXCx0OXW
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/14/25 4:36 PM, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> Introduce defintions of IRQ_TYPE_* which correspond to the Xen internal
>> representation of the IRQ types and make them the same asthe existing
>> device tree defintions for convenience.
>>
>> These defines are going to be re-used, at least, by RISC-V architecture.
>>
>> Signed-off-by: Oleksii Kurochko
> Acked-by: Jan Beulich

Thanks!

>
> Assuming an Arm ack would arrive, this looks like it's independent of the
> earlier patches, and hence could go in right away?

Yes, it is independent.

~ Oleksii

--------------tai8GTuIga5emhXukXCx0OXW
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/14/25 4:36 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    Introduce defintions of IRQ_TYPE_* which correspond to the Xen internal
representation of the IRQ types and make them the same asthe existing
device tree defintions for convenience.

These defines are going to be re-used, at least, by RISC-V architecture.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

    
      
    
      
    Acked-by: Jan Beulich <jbeulich@suse.com>
    
    
    
    
    Thanks!
    
    
    
      
    
Assuming an Arm ack would arrive, this looks like it's independent of the
earlier patches, and hence could go in right away?
    
    
    
    
    Yes, it is independent.

~ Oleksii
    
  


--------------tai8GTuIga5emhXukXCx0OXW--


From xen-devel-bounces@lists.xenproject.org Fri May 16 10:53:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 10:53:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986983.1372480 (Exim 4.92)
	(envelope-from )
	id 1uFsgW-00052v-NZ; Fri, 16 May 2025 10:53:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986983.1372480; Fri, 16 May 2025 10:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFsgW-00052o-J0; Fri, 16 May 2025 10:53:00 +0000
Received: by outflank-mailman (input) for mailman id 986983;
 Fri, 16 May 2025 10:52:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFsgV-00052i-AH
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 10:52:59 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed33d398-3243-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 12:52:57 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a36463b9cbso891f8f.2
 for ; Fri, 16 May 2025 03:52:57 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca5a79asm2427307f8f.25.2025.05.16.03.52.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 03:52: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" 
X-Inumbo-ID: ed33d398-3243-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747392777; x=1747997577; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=weo89IvxzIJ17K6wDX/z8/tGq3bym/lJJsmhQ7vaQS8=;
        b=EgAvey1w5N14U2VlkBXBhet2p2kzMmWNkiqsY62OPGiJzoqQ0WqbRAeZDCgJo+19p7
         xjMQw/RCexNI3WooXe3r9Ogm7dfiVmFlNJ1X+9ULChXgTTqIQLUcXFG2aTj/h82uPTkc
         q5IOKSMwJ45XrWDumyQXyeP56+NaGuOzr8yWpLe06NRvDjPL11HxpEfqxuZlCXWltzOt
         ObqLcDn3Wr6QGMHAbaPduTxqCOm5XoQXwVAa0iTeLKCgHsTRwPnca1RGpWbj2gswcByu
         HmiEDxyZSiWbwxBiLQmAnUCLLB+umFjqJCq6+Clav0toHr9QRxy/4/32z9Ku3zTBGkhQ
         x+eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747392777; x=1747997577;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=weo89IvxzIJ17K6wDX/z8/tGq3bym/lJJsmhQ7vaQS8=;
        b=EnN0dYPtrgPS+XYGdd0yKhFW0nPPRpLzu+3XaVBQC51Cfdzp7SPFK+PBlbGrPyqsYX
         NT8/n3cWnBxkxS0DZZEolGnMpU2kFHGZ4bxaFI7IHyRTlAsCmsLBb5OHGYds+wBXiDFA
         LWdZLR1QTjuYvV7JocBHy7r2nTSs9hB8HDsx/KHVgfC03uJB7P0Pw+rGYCxUSF9Y5GHY
         igYygqKdhFWQUyOJtRRblhDVNEbMW5sPC+3orzXbeo5irvU/8hUW+VgpaQa3Bo1dpjRT
         4QaJW2+ii2AwJ9/KqtVJZZRYqp1CpqEbidjZPIyJNXvlx4ZIfnVVpn78A+2ymzGNfcG8
         vnUg==
X-Forwarded-Encrypted: i=1; AJvYcCVWaYpQtH/EmFSzEihGc1os3hKgK/9MZEQUf/gxkvhFOKfEozH9w8NXIsy8vNFbSj0VrDb7PPiS9aw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxm1aaFInBcwyY0JNh9ZDgWAB7ZF9utbxo0OdFxnkZtBRUG0wpe
	/MvUGeHWGLP1htsYswYw8VplfwtP9V0BHoHjeGZFw7GSEBT9MstOJCZOaXnxVM64+ts=
X-Gm-Gg: ASbGncuwV28yxF+NEMpYuXoK4aawaib7NuOf6WE4cYBlCvefyz1Xo9wdHKXObTpdpUC
	rhS53GJA78Enro7tTMPwgQoHYure4rdYNchqPLl0/DBnCL+PraXpZu3mWxfGupEn4fMyyK4frsq
	fNrQy8jJqfNoabtoYBnqTT2YU8um/IW606LzFcYfWNlVaBSvGbeRifi5/9MN1byHVwR0bDjNqA5
	MwbF/Fiefrn8cOjCZY59BrSsJHzGsSLFenCWkNWsKjUrY0FxL2PCUbUnRUyjnD7MMX4vlgmvMgV
	kmbLiy3Tu4mR7jQG0ryLtKFEs+coDcxRRI3CeO5v1CT/oOPJ7g4dqhbBz34SrC9bKR2qasLn8cl
	cvC7rn4S8lSnjNoL2zWA7tmjzzPRX91gbAk0Ypc0+SKHnaG6nqTWcqM4Nd66IF+0dcrG3jf5Ejt
	6O0NN7NPSDCSs=
X-Google-Smtp-Source: AGHT+IF98JhISrZ0lgkdRvAyGosXiCU/LronDUQKmMW124UUxdtcxgQgTTjVB2kb+wqi9BU2ujvXkw==
X-Received: by 2002:a05:6000:2dc6:b0:3a2:1d3:defb with SMTP id ffacd0b85a97d-3a35c840cf0mr2780740f8f.36.1747392776650;
        Fri, 16 May 2025 03:52:56 -0700 (PDT)
Message-ID: <7dc4c08e-b80c-4ee9-a5d7-716ba3a9cfc0@suse.com>
Date: Fri, 16 May 2025 12:52:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 00/16] Confidential computing and AMD SEV support
To: Teddy Astie , xen-devel@lists.xenproject.org
Cc: Jan Beulich , Andrew Cooper
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , Tim Deegan ,
 Christian Lindig , David Scott 
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="------------VAIB1AK8d0r0OuwNb3yhx0P8"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------VAIB1AK8d0r0OuwNb3yhx0P8
Content-Type: multipart/mixed; boundary="------------5J8HISwiSrOYDbYMpCdK8ezu";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Teddy Astie , xen-devel@lists.xenproject.org
Cc: Jan Beulich , Andrew Cooper
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , Tim Deegan ,
 Christian Lindig , David Scott 
Message-ID: <7dc4c08e-b80c-4ee9-a5d7-716ba3a9cfc0@suse.com>
Subject: Re: [RFC PATCH 00/16] Confidential computing and AMD SEV support
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=

--------------5J8HISwiSrOYDbYMpCdK8ezu
Content-Type: multipart/mixed; boundary="------------k1pjn5j8J81P1i6gIRVn20B7"

--------------k1pjn5j8J81P1i6gIRVn20B7
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTYuMDUuMjUgMTE6MzEsIFRlZGR5IEFzdGllIHdyb3RlOg0KPiBIZWxsbywNCj4gDQo+
IFRoaXMgc2VyaWVzIGludHJvZHVjZSBzdXBwb3J0IGZvciBjb25maWRlbnRpYWwgY29tcHV0
aW5nIGFsb25nIHdpdGggYQ0KPiBBTUQgU0VWIGltcGxlbWVudGF0aW9uLiBJdCBhbHNvIGJ1
bmRsZXMgc29tZSBvZiB0aGUgZnVuY3Rpb25hbA0KPiByZXF1aXJlbWVudHMgKEFTSUQgc2No
ZW1lLCBBQkksIC4uLikgd2hpY2ggY291bGQgYmUgc2VwYXJhdGVkIGlmIG5lZWRlZC4NCj4g
DQo+IChJIGJ1bmRsZWQgZXZlcnl0aGluZyBpbiB0aGlzIHNlcmllIHRvIGhhdmUgYSBjb21w
bGV0ZSBjb2hlcmVudCBzZXJpZSkNCj4gDQo+IFRoaXMgd29yayByZWNlaXZlcyBmdW5kaW5n
IGJ5IHRoZSBIeXBlciBPcGVuIFggY29uc29ydGl1bSAoRnJhbmNlIDIwMzApLg0KPiANCj4g
IyBDb25jZXB0cw0KPiANCj4gQSBjb25maWRlbnRpYWwgZ3Vlc3QgaXMgYSBiaXQgc3BlY2lh
bCBhcyA6DQo+ICAgLSBpdHMgbWVtb3J5IGlzIGJ5IGRlZmF1bHQgZW5jcnlwdGVkIG9yIG5v
dCBkaXJlY3RseSBhY2Nlc3NpYmxlIGJ5IHRoZQ0KPiAgICAgaHlwZXJ2aXNvciwgdGh1cyBv
dGhlciBkb21haW5zL2RvbTAgYXMgd2VsbDsgaXQgbXVzdCBiZSBleHBsaWNpdGVseQ0KPiAg
ICAgc2hhcmVkIGJ5IHRoZSBndWVzdCBpdHNlbGYNCj4gICAtIHNvIGl0cyBwYWdlLXRhYmxl
cyBhcmUgYWxzbyBub3QgYWNjZXNzaWJsZQ0KPiANCj4gIyBJbXBsZW1lbnRhdGlvbg0KPiAN
Cj4gQ29uZmlkZW50aWFsIGNvbXB1dGluZyBpcyBleHBvc2VkIGluIGEgdW5pZm9ybSB3YXkg
cmVnYXJkbGVzcyBvZiBhY3R1YWwNCj4gaW1wbGVtZW50YXRpb24gKFNFViwgVERYLCBSTUUs
IC4uLikgdGhyb3VnaCB0aGUgY29jb19vcCBoeXBlcmNhbGwgKG1vc3RseQ0KPiBmb3IgdXNl
IGJ5IHRoZSBEb20wIHRvb2xzdGFjaykuIFRoaXMgaW50ZXJmYWNlIHByb3ZpZGVzIGEgd2F5
IHRvIHF1ZXJ5DQo+IGluZm9ybWF0aW9ucyBvbiB0aGUgY29jbyBwbGF0Zm9ybSAoc3VwcG9y
dCBzdGF0dXMsIGZlYXR1cmVzICh1bilzYWZldHksDQo+IC4uLiksIGFuZCBwcmVwYXJlIGlu
aXRpYWwgZ3Vlc3QgbWVtb3J5Lg0KPiBPbmx5IEhWTSBkb21haW5zIGhhdmUgc3VwcG9ydCBm
b3IgY29uZmlkZW50aWFsIGNvbXB1dGluZy4NCj4gKGluIHRoZSBmdXR1cmUsIHdlIG1heSB3
YW50IHRvIGhhdmUgYXR0ZXN0YXRpb24gc3VwcG9ydCkNCj4gDQo+IEluIG9yZGVyIHRvIGNy
ZWF0ZSBhIGNvbmZpZGVudGlhbCBjb21wdXRpbmcgZG9tYWluLCB0aGUgcHJvY2VzcyBpcyBm
b2xsb3cgOg0KPiAgIC0gY3JlYXRlIGEgSFZNL1BWSCBkb21haW4gd2l0aCBYRU5fRE9NQ1RM
X0NERl9jb2NvDQo+ICAgLSBwb3B1bGF0ZSBpbml0aWFsIG1lbW9yeSBhcyB1c3VhbA0KPiAg
IC0gYXBwbHkgY29jb19wcmVwYXJlX2luaXRpYWxfbWVtIG9uIGFsbCBpbml0aWFsIHBhZ2Vz
DQo+ICAgICAodW5kZXIgU0VWLCB0aGlzIHdpbGwgZW5jcnlwdCBtZW1vcnkpDQo+IA0KPiBV
bmRlciB4bCwgaXQgaXMgZXhwb3NlZCB0aHJvdWdoIHRoZSBgY29jb2AgcGFyYW1ldGVyICgi
Y29jbyA9IDEiKS4NCg0KV291bGRuJ3QgaXQgbWFrZSBzZW5zZSB0byBhbGxvdyBzcGVjaWZ5
aW5nIHRoZSBraW5kIG9mIGRvbWFpbg0KKFNFViwgU0VWLUVTLCBTRVYtU05QLCBURFgpIGxp
a2UgS1ZNIGRvZXM/DQoNCkl0IG1pZ2h0IG5vdCBiZSBuZWVkZWQgcmlnaHQgbm93LCBidXQg
aW4gZnV0dXJlIHRoaXMgY291bGQgYmUgbmVlZGVkDQooZS5nLiB3aGVuIGFsbG93aW5nIG1p
Z3JhdGlvbiBiZXR3ZWVuIGhvc3RzIHdpdGggZGlmZmVyZW50IFNFVg0KZmVhdHVyZXMpLg0K
DQpJIGRvbid0IHRoaW5rIHRoaXMgaXMgaW1wb3J0YW50IGR1cmluZyBSRkMgcGhhc2UsIGJ1
dCB0aGUgZmluYWwNCmNvbmZpZ3VyYXRpb24gYW5kIGh5cGVydmlzb3IgaW50ZXJmYWNlcyBv
ZiB0aGlzIHNlcmllcyBzaG91bGQgYWxsb3cNCnRoYXQuDQoNCg0KSnVlcmdlbg0K
--------------k1pjn5j8J81P1i6gIRVn20B7
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-----

--------------k1pjn5j8J81P1i6gIRVn20B7--

--------------5J8HISwiSrOYDbYMpCdK8ezu--

--------------VAIB1AK8d0r0OuwNb3yhx0P8
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/Ey8FAmgnGQcFAwAAAAAACgkQsN6d1ii/Ey+M
5Af/dAYwFPVWmnvEB120xcz3t1l8LsgMQcX+WFrK8uZFYvTFRXbsP7ZkLWQ89H3QsWGVIZ9XLBsM
U7kNsqX+R2OfAus0YfGX80f8UEgJvDPjZ7YJe9q4GZ1zb5vcuyXve70jMBkWLCT6V1lRPYFVgKDz
eXdpglVNBjhp5jVuL0Ea/55c47cERTwPaYSNXgmy/Xs92SlXLw+Is+ylSxO+yz2ZQ5JWkCvttJXV
6/bltCmV/uMrvI3ETz5uaDCwgD2xv8st+I6W0b4YUVAhtBuFsDT704xZCGd+/678vuowv384lzuo
aI9QA8iZMNPZSwpLPVU6jQV+Gv7T5OXrTCqx3rkqOw==
=BXLL
-----END PGP SIGNATURE-----

--------------VAIB1AK8d0r0OuwNb3yhx0P8--


From xen-devel-bounces@lists.xenproject.org Fri May 16 11:04:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 11:04:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.986996.1372490 (Exim 4.92)
	(envelope-from )
	id 1uFsrj-00085x-Pi; Fri, 16 May 2025 11:04:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 986996.1372490; Fri, 16 May 2025 11:04: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 1uFsrj-00085q-LJ; Fri, 16 May 2025 11:04:35 +0000
Received: by outflank-mailman (input) for mailman id 986996;
 Fri, 16 May 2025 11:04:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFsri-00085k-Uy
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 11:04:34 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 89254892-3245-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 13:04:28 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ad53cd163d9so66180166b.0
 for ; Fri, 16 May 2025 04:04:28 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d06cdefsm142158766b.52.2025.05.16.04.04.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 04:04: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" 
X-Inumbo-ID: 89254892-3245-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747393468; x=1747998268; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=MNRZulMHw+ZS3p7JqXl4SF+qDLtSvnv/s/9bSEhPxz0=;
        b=diEmTo2sd+oOEB0f3U048zVl+zLI40JF3G1X77K0G9VoLFnwYj6qssalsp3LstmEfZ
         b4UT+i8vA7OgUx0uyReAi/rIjH3uLSPxry1EZHmeQcnppUPyKZV8O7xEl/wDikyMGAns
         KnOhoPuQkIgXuWNQ4yPioyeSNXk9TU2aEpIQ0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747393468; x=1747998268;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=MNRZulMHw+ZS3p7JqXl4SF+qDLtSvnv/s/9bSEhPxz0=;
        b=kcBpZBPXBIBY1VGC293BO1i/HC2Qx6FF685wq2bN5CDBtCU9Y5jKoLBnm3ycXVugI7
         qPZ3ApZ3i94OXhS0CH9kg48jpVjeaotYTru3iK2grzpnE7K2/faRF60X4ck5dFGAwMQo
         GgKJxdyia7wmAqSqY6flgHv/EV2Dsh78tavvewbc3ho+5uzY8r32yyjhUy/Z7nM8lK6G
         MolC6q/m/Rupbx5yO9bJxoYEKa5cXPe1BRW5pdx1oZqhJ32Q8zCm1Ac+0fPIWiCxLZFx
         wXAfkOVM1EkLqGyZVGoz1u6I9dWvRCQeIYXFwryqGm3G/e1VQIkuw/YGaVHJKPjajUtK
         oUBA==
X-Forwarded-Encrypted: i=1; AJvYcCXD//ToVhTIa+Rrpt7TU1dWwBaYgcyRz4iueH9DRW1aOLfQbOpYi8eQK4ckRFFoRcaKWQCuZHsl7xg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyzoWbhH8LmU8hGfPII22ZJQszi4nRCIdErhDKqlilqC9v+qbES
	EOjecZooMvrCTmnqwXkvQYu3aD0OuqrfYTNbN4QCA2ymwsoZULNYFi8b3+zawqjrbiM=
X-Gm-Gg: ASbGncsR9EzLGC+yHlmcfD2r8qTdPnddMBZSy7z7OE0qzaJ4E9Dqc07RQFqFbOstqvJ
	tsOGK7TFZtS8rzgFOrHlp4iZ+BzjLfm522mCMvLmm7weUpRZtKixYCbbc1klKBOhL/sp+YpPbrL
	iT3Az5Zy3qk0F7fdC5nqVZ8EHLqoatTsQAhVFaJyswTvtgOkWHVCLNUsti8kAFpHjs81FpJMNZY
	qP1++SWHv+paxRdsZm1YbyqGNlG0ZStZvpWV3904oL4QpFPxq+wBwoZC5QOAr6dCTQU3FRKozim
	Zn53+jcfoNPDk6hFzfJOn2DvhjS5lVhfjAcxgE8FzTE14uttoweR7dMyduNNzmXKBbhrfTZsFlP
	Us0o3YV5i2AJZiE6e8wXkCBaGbPrzHA==
X-Google-Smtp-Source: AGHT+IF3zfeeudS4VRxzsXXWtTCDlb2/KgrrRwIclIdqLTgryYP46WqxI48CLpr/rGSOSVynee96vQ==
X-Received: by 2002:a17:907:d02:b0:ad1:81c5:5ec9 with SMTP id a640c23a62f3a-ad52d42bcb3mr334540166b.4.1747393467804;
        Fri, 16 May 2025 04:04:27 -0700 (PDT)
Date: Fri, 16 May 2025 13:04:26 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/6] x86/gnttab: do not implement GNTTABOP_cache_flush
Message-ID: 
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-3-roger.pau@citrix.com>
 
 
 <885b6722-5a68-419e-9d63-bf5977194c96@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <885b6722-5a68-419e-9d63-bf5977194c96@suse.com>

On Fri, May 16, 2025 at 12:38:02PM +0200, Jan Beulich wrote:
> On 16.05.2025 12:31, Roger Pau Monné wrote:
> > On Fri, May 16, 2025 at 11:48:48AM +0200, Jan Beulich wrote:
> >> On 16.05.2025 11:45, Roger Pau Monne wrote:
> >>> --- a/xen/common/Kconfig
> >>> +++ b/xen/common/Kconfig
> >>> @@ -35,6 +35,11 @@ config GRANT_TABLE
> >>>  
> >>>  	  If unsure, say Y.
> >>>  
> >>> +config HAS_GRANT_CACHE_FLUSH
> >>> +	bool
> >>> +	depends on GRANT_TABLE
> >>> +	default ARM
> >>
> >> To keep arch stuff out of common file as much as possible, I think this instead
> >> wants to be a "select ..." from ARM. Then:
> >> Reviewed-by: Jan Beulich 
> > 
> > My first attempt was to do it as you suggest, but then if the users
> > disables GRANT_TABLE you get the following warning:
> > 
> > WARNING: unmet direct dependencies detected for HAS_GRANT_CACHE_FLUSH
> >   Depends on [n]: GRANT_TABLE [=n]
> >   Selected by [y]:
> >   - ARM [=y]
> > configuration written to .config
> 
> Right, it needs to be
> 
> 	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
> 
> (and the "depends on" on the new HAS_* can also go away; HAS_* imo shouldn't
> normally have any dependencies).

Hm, OK, I didn't like it this way because then we force all users of
HAS_GRANT_CACHE_FLUSH to make it depend on GRANT_TABLE, while putting
the dependency in HAS_GRANT_CACHE_FLUSH avoids that.

Anyway, have adjusted according to your suggestion.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 16 11:53:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 11:53:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987026.1372499 (Exim 4.92)
	(envelope-from )
	id 1uFtck-0006sH-Ui; Fri, 16 May 2025 11:53:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987026.1372499; Fri, 16 May 2025 11:53: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 1uFtck-0006sA-RF; Fri, 16 May 2025 11:53:10 +0000
Received: by outflank-mailman (input) for mailman id 987026;
 Fri, 16 May 2025 11:53:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFtcj-0006s4-BS
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 11:53:09 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 558b2d6d-324c-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 13:53:08 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a1b8e8b2b2so1326348f8f.2
 for ; Fri, 16 May 2025 04:53:08 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca8d005sm2654649f8f.90.2025.05.16.04.53.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 04: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" 
X-Inumbo-ID: 558b2d6d-324c-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747396388; x=1748001188; darn=lists.xenproject.org;
        h=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;
        bh=I5SoKpPrapY6NKVQi0J3X/iaqhKoVWLrPmIwUGsSZGs=;
        b=AruJZm+WW9QTg7YchmvSPrbx84S7QkFHnNdeSm0lbp8EK+gfxrJoOQT0hXzASc40MZ
         xr6B+TZdd7Bj/JG2u9/CUmsYQi1JKF/NvsxXzJ6lnbh+v+BbMCYl1Kr5MdtCqrZYeHuS
         YbWpJHpu2ecERT1yR2p15O5z6T1JkFL7v4D/Z20LwQEn0hXmXjHGcZpQYEJNLYIiZmLJ
         IvmFaBIbgnqVXv1UslirqGgmDw11fKS2J60amQ92Ti1FtL/5/2yOntobhkVGzgWRAilR
         VXQl+3XbegrlBLuow+RPYyj4/zcYso2LIOY9SIVvZM7i/PwwTlgjkh4xiV4PtWmRReaS
         o4RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747396388; x=1748001188;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=I5SoKpPrapY6NKVQi0J3X/iaqhKoVWLrPmIwUGsSZGs=;
        b=O0ojw18WwTOgsYJ9Amb4PnNMHC6UHeZ0LC3r36ssXYiZk/bedLYRIa5ntR3L05fjdK
         ogIfKSBPXOMiB/HepjEDZsheWqtCnLBVQ8pu6KXqpe985JL016u8rVFja+etSwQkEes4
         iLlfe8yR48ozaPXyIzeSiyrlhw2HhheG2cs8mDqBqhR1uo6iLExD2qkj6BeenuHcYLHT
         8ExsTsRGmbS2SEnZ6RWzpAWqy8jW3n72MG4mua5Krugx5ny2oux6pz95rHbP1P+EHZ+M
         nZ07Zpf21tueKnGHW0Mqw5EoNhpckLNwVqmcv3w/1/EbJ7t7rOuHzZeKZMfT+JMC3zeg
         29Jw==
X-Forwarded-Encrypted: i=1; AJvYcCUW83RnSEHRI150zesGtm8aOZ53pKkmzvwsjl8nsz+qOlY0Vxax6SAygB2Cspyy2iCk6YMmcq0DHzc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyaFG0zOWZ6cmzvZm/+pvc17n09TBj7LR0FZwKYeeMWkMhYrEMH
	csoHQL45azxp5o3aXy6Kn2iMQ6ztBXeTn6daev32/hoj+ALcILRftBf/
X-Gm-Gg: ASbGncvsPUZYwxXOhWlrQGXO4vJZ+6Z2BNmFvqxI/ewRVEOoxCQyZfqedTKdE57tI6D
	kskjGbwAVFtKuGdFztujcC4bgOwCrla1dGoYeOr2wf8ZN2YT0YSEpeNOkqBuFX+MaVem39zojx1
	/7flphqZUnseYPTFSXA33/ivUjvlh4hOoOrYdN+3vRGwGB4ZWsoYy5duT3ys5W49IZAI+AjEW/P
	cX5giHh98wvLU3rJ2QnMkHwyTk5OTB/lAj+hWK/ju0JAuJ7+/SMkkDrZCgGWp4tW1DGHU0sNsJ7
	ydipfRcVXMfjsMPUAUiTGn/iN4XFVTOb7kk3xiHFA7qifVFvq5t1r0pmZzk3c6CXKO+8GgXwsiK
	RrdCIDHgs5s2hFSx2BCcFoU4n
X-Google-Smtp-Source: AGHT+IHbT/UZao4x04QuIZBoXvEGkBoVMQ8DWIk+sOWqPwKVu0QvAxBiqpE1ERCppieDnJ5WopXUnA==
X-Received: by 2002:a05:6000:2a4:b0:3a0:b5ec:f05f with SMTP id ffacd0b85a97d-3a35c84bd9emr3208624f8f.39.1747396387514;
        Fri, 16 May 2025 04:53:07 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------7L4IutCdbFvTeN76XvOdN4H7"
Message-ID: <43bc3c71-fa21-4373-b136-31f2f6bd29ab@gmail.com>
Date: Fri, 16 May 2025 13:53:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 06/16] xen/riscv: introduce init_IRQ()
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <2a57200785c710a5203a116bf9a933b4ea12d112.1746530883.git.oleksii.kurochko@gmail.com>
 <86738265-1137-45f0-ae9e-0db7f0451c08@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <86738265-1137-45f0-ae9e-0db7f0451c08@suse.com>

This is a multi-part message in MIME format.
--------------7L4IutCdbFvTeN76XvOdN4H7
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/14/25 4:49 PM, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/include/asm/irq.h
>> +++ b/xen/arch/riscv/include/asm/irq.h
>> @@ -3,6 +3,11 @@
>>   #define ASM__RISCV__IRQ_H
>>   
>>   #include 
>> +#include 
>> +
>> +#include 
>> +
>> +#define NR_IRQS 1024
> Is this arbitrary or arch-induced? Imo it wants saying in a brief comment either
> way. Then again maybe it's entirely obvious for a RISC-V person ...

1024 it is number of interrupt sources for PLIC and APLIC. I will add the comment above:
/*
  * According to the AIA spec:
  *   The maximum number of interrupt sources an APLIC may support is 1023.
  *
  * The same is true for PLIC.
  *
  * Interrupt Source 0 is reserved and shall never generate an interrupt.
  */
#define NR_CPUS 1024

Probably, it makes sense to change it to 1023 as interrupt 0 isn't really used.

>
>> --- /dev/null
>> +++ b/xen/arch/riscv/irq.c
>> @@ -0,0 +1,45 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +
>> +/*
>> + * RISC-V Trap handlers
>> + *
>> + * Copyright (c) 2024 Vates
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static irq_desc_t irq_desc[NR_IRQS];
>> +
>> +int arch_init_one_irq_desc(struct irq_desc *desc)
>> +{
>> +    desc->arch.type = IRQ_TYPE_INVALID;
>> +
>> +    return 0;
>> +}
>> +
>> +static int __init init_irq_data(void)
>> +{
>> +    unsigned int irq;
>> +
>> +    for ( irq = 0; irq < NR_IRQS; irq++ )
>> +    {
>> +        struct irq_desc *desc = irq_to_desc(irq);
>> +        int rc = init_one_irq_desc(desc);
>> +
>> +        if ( rc )
>> +            return rc;
>> +
>> +        desc->irq = irq;
>> +        desc->action  = NULL;
> Nit: You copied a stray blank from Arm code. Actually I wonder why it isn't
> init_one_irq_desc() that clears this field.

I can come up with the patch which does desc->action = NULL in init_one_irq_desc().
But considering that irq_desc[] is zero-initialized then perhaps there is no any
sense for desc->action = NULL, at all.

> It also feels like ->irq would
> better be set ahead of calling that function, like x86 has it.

But what is the difference with an order of writing a value to ->irq? It isn't
really used in init_one_irq_desc(). Or could ->irq be used in arch_init_one_irq_desc()
for something?

~ Oleksii

--------------7L4IutCdbFvTeN76XvOdN4H7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/14/25 4:49 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    --- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -3,6 +3,11 @@
 #define ASM__RISCV__IRQ_H
 
 #include <xen/bug.h>
+#include <xen/device_tree.h>
+
+#include <asm/irq-dt.h>
+
+#define NR_IRQS 1024

    
      
    
      
    Is this arbitrary or arch-induced? Imo it wants saying in a brief comment either
way. Then again maybe it's entirely obvious for a RISC-V person ...
    
    
    
    
    1024 it is number of interrupt sources for PLIC and APLIC. I will add the comment above:
/*
 * According to the AIA spec:
 *   The maximum number of interrupt sources an APLIC may support is 1023.
 *
 * The same is true for PLIC.
 *
 * Interrupt Source 0 is reserved and shall never generate an interrupt.
 */
#define NR_CPUS 1024

Probably, it makes sense to change it to 1023 as interrupt 0 isn't really used.


    
    
    
      
    

    
      
    
        
    --- /dev/null
+++ b/xen/arch/riscv/irq.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+/*
+ * RISC-V Trap handlers
+ *
+ * Copyright (c) 2024 Vates
+ */
+
+#include <xen/bug.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+
+static irq_desc_t irq_desc[NR_IRQS];
+
+int arch_init_one_irq_desc(struct irq_desc *desc)
+{
+    desc->arch.type = IRQ_TYPE_INVALID;
+
+    return 0;
+}
+
+static int __init init_irq_data(void)
+{
+    unsigned int irq;
+
+    for ( irq = 0; irq < NR_IRQS; irq++ )
+    {
+        struct irq_desc *desc = irq_to_desc(irq);
+        int rc = init_one_irq_desc(desc);
+
+        if ( rc )
+            return rc;
+
+        desc->irq = irq;
+        desc->action  = NULL;

    
      
    
      
    Nit: You copied a stray blank from Arm code. Actually I wonder why it isn't
init_one_irq_desc() that clears this field. 
    
    
    
    
    I can come up with the patch which does desc->action = NULL in init_one_irq_desc().
But considering that irq_desc[] is zero-initialized then perhaps there is no any
sense for desc->action = NULL, at all.

    
    
    
      
    It also feels like ->irq would
better be set ahead of calling that function, like x86 has it.
    
    
    
    
    But what is the difference with an order of writing a value to ->irq? It isn't
really used in init_one_irq_desc(). Or could ->irq be used in arch_init_one_irq_desc()
for something?

~ Oleksii

    
  


--------------7L4IutCdbFvTeN76XvOdN4H7--


From xen-devel-bounces@lists.xenproject.org Fri May 16 11:59:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 11:59:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987034.1372509 (Exim 4.92)
	(envelope-from )
	id 1uFtim-0007Sw-HG; Fri, 16 May 2025 11:59:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987034.1372509; Fri, 16 May 2025 11:59: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 1uFtim-0007Sp-EU; Fri, 16 May 2025 11:59:24 +0000
Received: by outflank-mailman (input) for mailman id 987034;
 Fri, 16 May 2025 11:59:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFtik-0007Sj-T6
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 11:59:22 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 33b729b2-324d-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 13:59:21 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-6011407431cso1065518a12.3
 for ; Fri, 16 May 2025 04:59: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
 a640c23a62f3a-ad52d04b059sm152298366b.10.2025.05.16.04.59.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 04:59: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" 
X-Inumbo-ID: 33b729b2-324d-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747396760; x=1748001560; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pIFyXStJjbN7FXjwQkDmXRREFRbxUm51JKeGx6OS8MY=;
        b=YQS4VtVpq09Z+UOQbYz45s8cFfy13uTbzJCGG5SLAsmB06T+maulA7Q0/6ZMzgsJjj
         Z8+QGoE4aZarpJ+nths6x7XGvmGVFheiTWRRRJXAGn/jheRP0x7QoepRJ8TCtXsOREnk
         34rXbdn4on77Q4zA+rq2G+F2ComUJrG8AoMPx1ewyvX9+z5h/kMNFynx/uxi5Whwhlvp
         X1tJHmtJJoh3AD0vR3dR1IAwVjwi9Dqy5rxXPCXtaQ0d7eawI481XzeZRQFUitfKbo8O
         yl32ikQXELj0cYyo3AiQZ//FcVyNVAM4ZEKFjV2waRa+Hx7QZe4knJtMcFrgjVkVbOBF
         o3sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747396760; x=1748001560;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pIFyXStJjbN7FXjwQkDmXRREFRbxUm51JKeGx6OS8MY=;
        b=IorPpyMokX9GhSrVVuBDVipmrBJMvzRf4Y04+vl8PW/wQbSI/8keCsmP7mE9YSxUph
         +bHdBkznzbYVDjZlwyNr8Jgy0i+T2u8whvrP9VxFfJB1/MFBD8LsSYyNNxYvrLnMVxHC
         nt9ljXARtDT0EoK91RdfZ66qPqUXoTqxbFDai/gJIJ2vxY8rR3XSDg8ee5XM0pjeVPRa
         1kmSniHi7bJHYbu20MuMXqok+B4Hg08VPMXWlfnEqGkXOIMRt71ZnmI2h4sXLSP05PF2
         6/P8hLHSrNYuBDNVFcHqpM0F4PYjlqMufVNBZTOMMsgc8z7CbAXbJ7sZXuail0MuPj38
         ihtA==
X-Forwarded-Encrypted: i=1; AJvYcCXG4HE+QBIjQsVZlcnEKrvBjW6vr2TbUd1yUgZbMqwa1pXKa7c3IRyw8Ty6QlubP50DhMjm/tNFZEg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy/BIQR8Wfhn7BhYOwYOYbvGBLewTtqvgkX1z/XTRkZAXM1+F8+
	60JcuJJ3+sMqM7wVCCbNvzSDp6DG+HqgU5VLDvCiOvSMwQhmrJJWJdmOX8mSbA2lxA==
X-Gm-Gg: ASbGncvQj6N7LIz3rw2Pd6NtIkC8Vvp15VOhUXB5OV4GY7X2Pdyrlpc0s2ARtv9Dnk2
	0WAn+S/fYKU9XNSyAFJIJ/z7GXsFiam1/kbEXqUIXib0ucqOX9XLw5TFSUl8nojJSFKcFRIfRor
	wYKaBjyxC/tgCORZOWaI/p8na21pfsL7y64/KhNcvSr50SmxQfv8F2PPNCTXXF5n9imuVoE2egT
	uYFhLkkrdZz/YecYbgOvLkoOpGcwOD6XS/NnBY05xwpbd3lfgfa0lVhiLaq+E/ZwttyMSaGjzYu
	c931hDt47iGSI9YOaGUlmzJO8MYy/3FRbyuk2k+W6CzeHH0FIq+JBU8XzRLLpJi4VrcNxyq+SdG
	8Q0OpT+9t1ElxUbooc5LHTNuf1qy8hEWL8K9p
X-Google-Smtp-Source: AGHT+IHxuMt3G7kJYQW+yHzmx9MUPNIFieDJHKHkP2QiOjkBHCGRFCPzZemp6BKM8SaYV+ZjACrK3A==
X-Received: by 2002:a17:906:c14d:b0:ad2:3efc:dd7a with SMTP id a640c23a62f3a-ad536b57a13mr191001166b.4.1747396760490;
        Fri, 16 May 2025 04:59:20 -0700 (PDT)
Message-ID: <0e978f13-bc06-4d21-99b3-0e903c2bfedf@suse.com>
Date: Fri, 16 May 2025 13:59:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 06/16] xen/riscv: introduce init_IRQ()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <2a57200785c710a5203a116bf9a933b4ea12d112.1746530883.git.oleksii.kurochko@gmail.com>
 <86738265-1137-45f0-ae9e-0db7f0451c08@suse.com>
 <43bc3c71-fa21-4373-b136-31f2f6bd29ab@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: <43bc3c71-fa21-4373-b136-31f2f6bd29ab@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 13:53, Oleksii Kurochko wrote:
> On 5/14/25 4:49 PM, Jan Beulich wrote:
>> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/include/asm/irq.h
>>> +++ b/xen/arch/riscv/include/asm/irq.h
>>> @@ -3,6 +3,11 @@
>>>   #define ASM__RISCV__IRQ_H
>>>   
>>>   #include 
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +#define NR_IRQS 1024
>> Is this arbitrary or arch-induced? Imo it wants saying in a brief comment either
>> way. Then again maybe it's entirely obvious for a RISC-V person ...
> 
> 1024 it is number of interrupt sources for PLIC and APLIC. I will add the comment above:
> /*
>   * According to the AIA spec:
>   *   The maximum number of interrupt sources an APLIC may support is 1023.
>   *
>   * The same is true for PLIC.
>   *
>   * Interrupt Source 0 is reserved and shall never generate an interrupt.
>   */
> #define NR_CPUS 1024

s/CPU/IRQ I suppose.

> Probably, it makes sense to change it to 1023 as interrupt 0 isn't really used.

I'd recommend against that. It would likely make things more difficult when
range-checking IRQ numbers.

>>> --- /dev/null
>>> +++ b/xen/arch/riscv/irq.c
>>> @@ -0,0 +1,45 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>>> +
>>> +/*
>>> + * RISC-V Trap handlers
>>> + *
>>> + * Copyright (c) 2024 Vates
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +static irq_desc_t irq_desc[NR_IRQS];
>>> +
>>> +int arch_init_one_irq_desc(struct irq_desc *desc)
>>> +{
>>> +    desc->arch.type = IRQ_TYPE_INVALID;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int __init init_irq_data(void)
>>> +{
>>> +    unsigned int irq;
>>> +
>>> +    for ( irq = 0; irq < NR_IRQS; irq++ )
>>> +    {
>>> +        struct irq_desc *desc = irq_to_desc(irq);
>>> +        int rc = init_one_irq_desc(desc);
>>> +
>>> +        if ( rc )
>>> +            return rc;
>>> +
>>> +        desc->irq = irq;
>>> +        desc->action  = NULL;
>> Nit: You copied a stray blank from Arm code. Actually I wonder why it isn't
>> init_one_irq_desc() that clears this field.
> 
> I can come up with the patch which does desc->action = NULL in init_one_irq_desc().
> But considering that irq_desc[] is zero-initialized then perhaps there is no any
> sense for desc->action = NULL, at all.

Oh, yes, indeed.

>> It also feels like ->irq would
>> better be set ahead of calling that function, like x86 has it.
> 
> But what is the difference with an order of writing a value to ->irq? It isn't
> really used in init_one_irq_desc().

That's the present state of things, yes. There or ...

> Or could ->irq be used in arch_init_one_irq_desc()
> for something?

... there it could be used e.g. for a log message. Maybe even just a transient
debugging one. And there's no (proper) way to re-establish the IRQ number from
the desc pointer, at least not in arch-independent code.

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 12:29:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 12:29:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987062.1372519 (Exim 4.92)
	(envelope-from )
	id 1uFuBl-0003Se-UF; Fri, 16 May 2025 12:29:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987062.1372519; Fri, 16 May 2025 12:29: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 1uFuBl-0003SX-R7; Fri, 16 May 2025 12:29:21 +0000
Received: by outflank-mailman (input) for mailman id 987062;
 Fri, 16 May 2025 12:29:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFuBk-0003SR-GX
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 12:29:20 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 63aafdb7-3251-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 14:29:19 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-442ed8a275fso23346945e9.2
 for ; Fri, 16 May 2025 05:29:19 -0700 (PDT)
Received: from andrew-laptop.. ([46.149.103.12])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca4dfffsm2759532f8f.9.2025.05.16.05.29.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 05:29: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" 
X-Inumbo-ID: 63aafdb7-3251-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747398559; x=1748003359; 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;
        bh=oM9b8wT66TmQJfExo6/g2uvlE85/1tsMkkMPcvkrzTY=;
        b=U4Afe3FOk88cNcxGlRuqhximVwGOabMdtgAVJhkvV7dSvabuXHDD1A6kGgYHljlCkN
         GpGI1a87R3NBtlljs4C6kJkzXA7vmr0+IYxVNl+BC8XW7mTCtzmoBlNVTFC1JCtgnRyu
         KYd08U6VDcge2FMG2WLXOhrxn6X1Us3so3u8A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747398559; x=1748003359;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=oM9b8wT66TmQJfExo6/g2uvlE85/1tsMkkMPcvkrzTY=;
        b=FOlyx74KqZRBA61IrZS/Q0xEKmLpp4G76+te/5FavyiLuTZ6fgfIzl1UkiOLReYUAy
         jAoMQxDyumUOp0d7oWKnn0qX+cjDwtq66YUvTspEkVod3zcRhs9XnDrYFlszcU2pldFw
         x3ZVfnHEPFNLIIk6bdMEJU96kWdWocjgLqrD9B+BL7XnFQ+5dhO4V4ObZz4yG1dU4WUu
         kOy1ugoZf8duO1d8WtK+zzCu4slQouGV26zlG6Gbwj/xgvfJpYY70SmeugpI4+SPkRGK
         lWnaTQGPDHBYoqZ1NVRZAlCxoaU7NdMw5T+Kh6PWiuOu6NQsP8OrVdULX0tEK+xA5jLF
         LKBw==
X-Gm-Message-State: AOJu0YzyG4RT0pFyk9K1/KZNftV8vPNR5W6OiXCFkJgX1gIVP1H+x82O
	F0GqjMTi7Vmmdh3q4ggwHMy5K4W/PnMlwzlUNTic0l7rEkJ4Uhob8b4ti+QgETTNvWiF8Ki5Z2g
	iE3mq
X-Gm-Gg: ASbGnctt+Ez8R1OiL+qemx4qzG3M7ddXIIg1XRHkOSoTmKEfM+lZkijtgBKHdkwhOHM
	mVaQzCXtA8wtQ4/zA/4gFXYtRTwHF4k1yW2IvDeCyuNk3Dvml3CDSoo2sNopuiq4zAVRga956iL
	2YLRQJeUbXH6cPyTDYPudYuPn1/RS/QOtzWLa6Alt41kT8vt2Q3aJKQxadwjj40klS6VeFNRP3I
	fn79KsD3FXM+l75hqLPWe2jNHQ2/YRwC/jj/OKdT/3wbWtwKrNHIOIH/Xlsgc3StViAcTHErFXh
	jMdffctPb2130kOz22AafbBqhIv96faqJoe8pisT0WtljYP1HEMFdrzIqo7OoOg=
X-Google-Smtp-Source: AGHT+IFjbSA2rplbjLSxfKLQw8bGe/n2OmFf84NRYG9MLYnDr2qk+85wmcN8QJQvL1lc8hm9o6em8g==
X-Received: by 2002:a05:600c:a413:b0:43d:98e7:38dc with SMTP id 5b1f17b1804b1-442fe3fd7eemr24602705e9.5.1747398558793;
        Fri, 16 May 2025 05:29:18 -0700 (PDT)
From: Andrew Cooper 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Denis Mukhin 
Subject: [PATCH] x86/vmx: Annotate the VMCS field widths
Date: Fri, 16 May 2025 13:29:16 +0100
Message-Id: <20250516122916.27070-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This helps identify the appropriate type to use.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Denis Mukhin 
---
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
index cde4fe011bcd..ff5dd66b0ad9 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -436,6 +436,7 @@ extern struct vmx_caps vmx_caps;
 /* VMCS field encodings. */
 #define VMCS_HIGH(x) ((x) | 1)
 enum vmcs_field {
+    /* 16-bit fields. */
     VIRTUAL_PROCESSOR_ID            = 0x00000000,
     POSTED_INTR_NOTIFICATION_VECTOR = 0x00000002,
     EPTP_INDEX                      = 0x00000004,
@@ -457,6 +458,8 @@ enum vmcs_field {
     HOST_FS_SELECTOR                = 0x00000c08,
     HOST_GS_SELECTOR                = 0x00000c0a,
     HOST_TR_SELECTOR                = 0x00000c0c,
+
+    /* 64-bit fields. */
     IO_BITMAP_A                     = 0x00002000,
     IO_BITMAP_B                     = 0x00002002,
     MSR_BITMAP                      = 0x00002004,
@@ -493,6 +496,8 @@ enum vmcs_field {
     HOST_PAT                        = 0x00002c00,
     HOST_EFER                       = 0x00002c02,
     HOST_PERF_GLOBAL_CTRL           = 0x00002c04,
+
+    /* 32-bit fields. */
     PIN_BASED_VM_EXEC_CONTROL       = 0x00004000,
     CPU_BASED_VM_EXEC_CONTROL       = 0x00004002,
     EXCEPTION_BITMAP                = 0x00004004,
@@ -546,6 +551,8 @@ enum vmcs_field {
     GUEST_SYSENTER_CS               = 0x0000482a,
     GUEST_PREEMPTION_TIMER          = 0x0000482e,
     HOST_SYSENTER_CS                = 0x00004c00,
+
+    /* Natural-width fields. */
     CR0_GUEST_HOST_MASK             = 0x00006000,
     CR4_GUEST_HOST_MASK             = 0x00006002,
     CR0_READ_SHADOW                 = 0x00006004,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 12:36:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 12:36:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987070.1372529 (Exim 4.92)
	(envelope-from )
	id 1uFuIb-00059w-Jm; Fri, 16 May 2025 12:36:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987070.1372529; Fri, 16 May 2025 12: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 1uFuIb-00059p-Gr; Fri, 16 May 2025 12:36:25 +0000
Received: by outflank-mailman (input) for mailman id 987070;
 Fri, 16 May 2025 12:36:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFuIa-00059j-DO
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 12:36:24 +0000
Received: from mail133-28.atl131.mandrillapp.com
 (mail133-28.atl131.mandrillapp.com [198.2.133.28])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5f4a174a-3252-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 14:36:22 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-28.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4ZzRQX4g2fzMQxfTF
 for ; Fri, 16 May 2025 12:36:20 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 77e1a3f21d024d78aeac06f20608c89b; Fri, 16 May 2025 12:36: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" 
X-Inumbo-ID: 5f4a174a-3252-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747398980; x=1747668980;
	bh=kkmPraR7ltUZhtF3rGsI2qjde3oV9KdOXdjtmRkLjkM=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=Adko5i2HL7TP/6rchYROO+Nz+S443nmL3I3BRoTeO5GhHgmp5LGzanDavqfttlveb
	 U6U+w/U5UmmenM1bVDuEzYkFJiieYFE9gdUvSMSIBHU+/QTmJqeTSKd1X3fxlRo4F2
	 TNCOWRrup9D9YKxnBwDY+RZec94+evNtcnK+jGfQbqVcMo/OvaGrlFtqe5tSx+u9r0
	 HU+TyxuU025mHTfdxatga/WQS+ZS6f5zm5Oei8xzH/qSVqa6v2HtkzQ1+JWEc5T+Ro
	 J/hKDF8D73iFT3ZoUEyuPHEl/ybRUYFW9YEXF6PH1/XELaL189yeMThl/ySqygbpkC
	 R2r0uNcQM4WeA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747398980; x=1747659480; i=teddy.astie@vates.tech;
	bh=kkmPraR7ltUZhtF3rGsI2qjde3oV9KdOXdjtmRkLjkM=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=ogmoQrjd+/8A6VRmfej22xjL63wRcF5rMYS4nYSJOtJFJAeGfEZwwVE4Kt8ju5qJz
	 keYE2ErpvpQzJdSFfOWoS2X5bKZhEmlq3HliAfXtl2/D7Ete14Xv1jsdlJisl54pg3
	 0OtRTGxWrtl9ZNgiju0B70+bw+faLYiHBxcCMqZ/pdTKazydYcL7vHLvx/tWUqWFfF
	 UIXrCraSJEz2vy6x0CQK6BewBTcemG5oA8alhxXHPKglR+frJdcFCtQw3qseb918/d
	 fhTGDOdIZabZKKchRuXc5wwi08vPxOjzZXe2023uQyT6P9H+KjYsREysydg/M1kmBF
	 jbxZJnOMhiZKA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[RFC=20PATCH=2000/16]=20Confidential=20computing=20and=20AMD=20SEV=20support?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747398978777
Message-Id: <9fa006e3-f47a-42a2-afa9-a10c1aa07172@vates.tech>
To: "=?utf-8?Q?J=C3=BCrgen=20Gro=C3=9F?=" , xen-devel@lists.xenproject.org
Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" , "Tim Deegan" , "Christian Lindig" , "David Scott" 
References:  <7dc4c08e-b80c-4ee9-a5d7-716ba3a9cfc0@suse.com>
In-Reply-To: <7dc4c08e-b80c-4ee9-a5d7-716ba3a9cfc0@suse.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.77e1a3f21d024d78aeac06f20608c89b?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 12:36:20 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 16/05/2025 =C3=A0 12:54, J=C3=BCrgen Gro=C3=9F a =C3=A9crit=C2=A0:
> On 16.05.25 11:31, Teddy Astie wrote:
>>
>> In order to create a confidential computing domain, the process is 
>> follow :
>> =C2=A0 - create a HVM/PVH domain with XEN_DOMCTL_CDF_coco
>> =C2=A0 - populate initial memory as usual
>> =C2=A0 - apply coco_prepare_initial_mem on all initial pages
>> =C2=A0=C2=A0=C2=A0 (under SEV, this will encrypt memory)
>>
>> Under xl, it is exposed through the `coco` parameter ("coco =3D 1").
> 
> Wouldn't it make sense to allow specifying the kind of domain
> (SEV, SEV-ES, SEV-SNP, TDX) like KVM does?
> 

Yes, I was thinking of exposing it through in a optional arch-specific 
parameter for specifying some SEV-specific parameters (enable SNP, ...).

And by default rely on what the platform provides with a "best default" 
configuration.
(AFAICT it's not possible to have both SEV (AMD-specific) and TDX 
(Intel-specific), or at least not yet)

> It might not be needed right now, but in future this could be needed
> (e.g. when allowing migration between hosts with different SEV
> features).
> 
> I don't think this is important during RFC phase, but the final
> configuration and hypervisor interfaces of this series should allow
> that.
> 
> 
> Juergen

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Fri May 16 12:42:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 12:42:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987088.1372539 (Exim 4.92)
	(envelope-from )
	id 1uFuOW-0006tS-6U; Fri, 16 May 2025 12:42:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987088.1372539; Fri, 16 May 2025 12: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 1uFuOW-0006tL-3s; Fri, 16 May 2025 12:42:32 +0000
Received: by outflank-mailman (input) for mailman id 987088;
 Fri, 16 May 2025 12:42:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFuOV-0006tF-C1
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 12:42:31 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3a7ed84e-3253-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 14:42:29 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43edb40f357so15659005e9.0
 for ; Fri, 16 May 2025 05:42:29 -0700 (PDT)
Received: from [10.81.43.161] ([46.149.103.10])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-443000ee99csm18110755e9.31.2025.05.16.05.42.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 05:42: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" 
X-Inumbo-ID: 3a7ed84e-3253-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747399349; x=1748004149; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=VxNrDdHwZDB4e7gQ0bftbwiTKA/WIFIRNRrPLF2lTbc=;
        b=l9WrJ4u2ecxkb50Om083budSsq+cvFWOKWOUIZTQtjUpSPwUY3zNlEwchTBQvwhlLz
         VnZX+G+P9CzZb7e/ZiYeircp3CXVErd3lIswE0xWxx1liHFC2pinsqqvfiHC1Y9Egq0w
         cOtwfM4IPFZG2IvkMGKNQMRdcN3YW4K1cMjmY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747399349; x=1748004149;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=VxNrDdHwZDB4e7gQ0bftbwiTKA/WIFIRNRrPLF2lTbc=;
        b=G3juXVJOoPc6Yub4IDQVRs481DwfGV+xsOm/LUlVm83PL6TEqlK95bItCYp/yz+1Ym
         sjraBPLam5u3s/y4cpBwPlb39lH3cGUAAY8+X6sCzMyV6vIBIUry4+Axp23XctgvsL4R
         kdu0TfMiuBKhXsf5rCmMUMqGFAsZKMw4UyW+sJ0Ev2w4YEKc6Tq3msorX5PuCzrY0dPQ
         cAub9uO+zwVB/HVi7TFyECdwFTkunhXOMuFIsRRi7PFDgsRdfXq/z324MfN+Mdx6aEW/
         OjLd29a9psEB5Ci2ui63FCEkOEJWqEI2JjuES/UeEyl+Xzk6ICKNGBWZRuUwTgnzUeWv
         eRaA==
X-Forwarded-Encrypted: i=1; AJvYcCVAon2965E75MGb74N4fg2FI1wnroo/ACGUL9oSv8Gug/8Y6C5b7hWYfD8sbbayx7K/N26C8/lZU6c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGGLHfJhdpplbwCcYu+5LATa1RAjUha6peKnq4Vhx7e1HOBSmG
	B0Ow/9vT1DH8KCgFYQgNlLF0iIiKhTIt3BsH+V86nwMmSgBb6J5Ww2EbfAwEFhx3YMc=
X-Gm-Gg: ASbGncsLvrRhVwHDU5pkCUz5snwwV9ONUOVkHZIrJLmtW05axjIIvP/ZhW4rK3AlT2D
	lz+D3BSoe3BFvbaHP/rGATB8Y/602apXOLBaAHe5D0hRM/oVdhiaFJao3JOP5S5Q8SOPi8ZQ/VS
	2t7lLCx0CcZN7mT2HErv/fGA5tDfI0IxsPl2rt1cAcnD1qnv3tXN5FIi/pm4WqRkcr2B5HEtIVx
	EH//pJqMvbcIQY1OEObD30JrdLBqYNJgYWvr0X0JbE5hh7a/5n4e2ZtWH7gUnDiUYf8TgLhrPTm
	xYFxQ6iz8Hg+aYVQUi8vvLgwtRH5X/q3ICVEtMDCnam1jW+17C1LP0GOkL3T5UQ0/I/8JsUo
X-Google-Smtp-Source: AGHT+IEeql+bDq0LLvixVb3OHq5FszKypJA8cDZcQQFqGxFLiA5On1Lpbfb6Maqshg6ub0P0I5BpkA==
X-Received: by 2002:a05:600c:5305:b0:43c:fceb:91a with SMTP id 5b1f17b1804b1-442fd62733amr32335915e9.11.1747399348912;
        Fri, 16 May 2025 05:42:28 -0700 (PDT)
Message-ID: <7c0a689e-c116-49e2-9caa-f5679f8960eb@citrix.com>
Date: Fri, 16 May 2025 13:42:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/2] x86/vmx: replace __vmread() with vmread()
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, roger.pau@citrix.com, nicola.vetrini@bugseng.com,
 consulting@bugseng.com, dmukhin@ford.com
References: <20250513052809.3947164-1-dmukhin@ford.com>
 <20250513052809.3947164-2-dmukhin@ford.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: <20250513052809.3947164-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 13/05/2025 6:28 am, dmkhn@proton.me wrote:
> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
> index 91b407e6bc..b622ae1e60 100644
> --- a/xen/arch/x86/hvm/vmx/intr.c
> +++ b/xen/arch/x86/hvm/vmx/intr.c
> @@ -65,7 +65,7 @@ static void vmx_enable_intr_window(struct vcpu *v, struct hvm_intack intack)
>      {
>          unsigned long intr;
>  
> -        __vmread(VM_ENTRY_INTR_INFO, &intr);
> +        intr = vmread(VM_ENTRY_INTR_INFO);
>          TRACE(TRC_HVM_INTR_WINDOW, intack.vector, intack.source,
>                (intr & INTR_INFO_VALID_MASK) ? intr & 0xff : -1);
>      }

As Jan said in v4, lots of these should now change away from being
unsigned long.

For example, this delta alone:

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 203ca83c16e7..c540ea5bd850 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -4154,9 +4154,8 @@ static void undo_nmis_unblocked_by_iret(void)
 
 void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
 {
-    unsigned long exit_qualification, exit_reason, idtv_info, intr_info
= 0;
-    unsigned long cs_ar_bytes = 0;
-    unsigned int vector = 0;
+    unsigned long exit_qualification;
+    unsigned int exit_reason, idtv_info, intr_info = 0, cs_ar_bytes =
0, vector = 0;
     struct vcpu *v = current;
     struct domain *currd = v->domain;
 
@@ -4830,7 +4829,7 @@ void asmlinkage vmx_vmexit_handler(struct
cpu_user_regs *regs)
     /* fall through */
     default:
     exit_and_crash:
-        gprintk(XENLOG_ERR, "Unexpected vmexit: reason %lu\n",
exit_reason);
+        gprintk(XENLOG_ERR, "Unexpected vmexit: reason %u\n", exit_reason);
 
         if ( vmx_get_cpl() )
             hvm_inject_hw_exception(X86_EXC_UD,

results in:

    add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-331 (-331)
    Function                                     old     new   delta
    vmx_vmexit_handler.cold                      929     839     -90
    vmx_vmexit_handler                          5490    5249    -241

worth of saving in the fastpath.  (Yes, I chose this example carefully
because it's surely the largest win to be had.)

I've just sent out a minor docs patch annotating the sizes of the fields.

This patch wants splitting into at least 3:

 * One for the 64bit and natural fields which are a straight transform
and no type-change away from unsigned long.
 * One for the 16bit fields (there are few enough that this can easily
be a single patch).
 * One or more for the 32bit fields, doing a type change to unsigned int
too.  (Might get quite large.  Hard to judge whether it wants to be one
or more without seeing it.)

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 16 12:45:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 12:45:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987095.1372549 (Exim 4.92)
	(envelope-from )
	id 1uFuR4-0007Ph-J0; Fri, 16 May 2025 12:45:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987095.1372549; Fri, 16 May 2025 12:45: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 1uFuR4-0007Pa-GJ; Fri, 16 May 2025 12:45:10 +0000
Received: by outflank-mailman (input) for mailman id 987095;
 Fri, 16 May 2025 12:45:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFuR2-0007PS-W6
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 12:45:08 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 99294e2a-3253-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 14:45:08 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43ede096d73so14547545e9.2
 for ; Fri, 16 May 2025 05:45:08 -0700 (PDT)
Received: from [10.81.43.161] ([46.149.103.13])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442fd50eda6sm31916875e9.13.2025.05.16.05.45.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 05:45: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" 
X-Inumbo-ID: 99294e2a-3253-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747399508; x=1748004308; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=hR6tfFpNGkgK83dfReZQaURSgcWQZAdu0yzou0TQTMg=;
        b=avF6TvpigOb8xVyzSRQayifZ5nLzkI8kDHtUBw8AqpyepTTa4/4kZ39arplgBQky9Q
         firB1J1VXDNZhV+D3IQmqxGNPc+XmqqKCdg96luH93wLsNOLAejDb0x1NP9lwvcwOYLi
         Ec51OlgNvxLqZ7Xd1r6HSb0/a+L+un3fo4mGs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747399508; x=1748004308;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=hR6tfFpNGkgK83dfReZQaURSgcWQZAdu0yzou0TQTMg=;
        b=G8R/wiCnC3L/5g7+154h5uoIM7rFM1JZQSKpbUwLpVmsgNRsQ+0Mjgey229VUB53j+
         H6nuGu+yUqN6x1Ktn48hsMDeHif2tk9FFumXdrXz75d7PSbalp4oWdf9xJCAhomYjMZA
         quz9EldXl2Ln5PnOBze/wzeHAY/1/2GGRyaMAo8t8Akv7MRBi0K85gaekor+8mwXzm1S
         r3ng6RhEOu2nz5JvAUH50Mj33zFKgpMfPv8uXkdhOxUIRd2XzSB1ePpHuVKHTvPU6cqs
         ttu0JIiVu/H9kqMTHf4x9sjeT/sna9zm7I5h1bsLYZpVF6PdvPTZmkfpl8sWjZrsCuBx
         yVlA==
X-Forwarded-Encrypted: i=1; AJvYcCVc9QrED8914Be7qmXQtRrKP+84jS61tzdWj3AptTvcLFJf3v8dnosfTk8C0AzgqmBWMiZBD5w1LpE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx4MAe64+OjLLvzMhJRWHGR45t66CV0xoKhInLqV3iSUAHFmHFJ
	EZfP2cNR0Q6+3GbK6MgNk6a5w+CmD1o550HUuIr6FRWyahYTakHlv9SERV5Pbi83Q9I=
X-Gm-Gg: ASbGncvieDVVAeJ+s4iRswfhtTBMny3cP+Uc7uxZvcldoLDRyVbSAPqtzUeEjUwlqF1
	5tRpwTT+b0BhdyrSvKFNlluEsiIbm4BvjhExZKNFq9ULFgMOaqVU6k+mo4X+36N3yu1wZFo3z79
	vDVi0Z3nlcRv5t9dABZelcj3p498NC+GStjFDoVKiGo0YJIHqbXrjqokd+Xp1zFbAR0ySvBSnq4
	81FBHqmn/Esrxv9tnETGYtAG64B7JB4YZ8uaTyGe4REdzj2fooT8zcgBHl24oMa66FKhS9olprO
	6GG5++5cqyaFOyxQkHOGmwPofsAx+15+KyMi5Qb9o7SP5nmTywqv9UlSqrBD1g==
X-Google-Smtp-Source: AGHT+IFH01s4vmp7V81rk2SUEj7hvywGZ4N7cJWaOuMfqJFjZIq5h3y+wkH5koR+O4eaUGVOkFh3ZQ==
X-Received: by 2002:a05:600c:b88:b0:434:fa55:eb56 with SMTP id 5b1f17b1804b1-442fd60b4abmr29398215e9.7.1747399507710;
        Fri, 16 May 2025 05:45:07 -0700 (PDT)
Message-ID: <85f778d1-7fb5-47da-9153-35333e486d24@citrix.com>
Date: Fri, 16 May 2025 13:45:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PING MISRA] Re: [PATCH v5 2/2] x86/vmx: remove __vmread()
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, roger.pau@citrix.com, nicola.vetrini@bugseng.com,
 consulting@bugseng.com, dmukhin@ford.com,
 Stefano Stabellini 
References: <20250513052809.3947164-1-dmukhin@ford.com>
 <20250513052809.3947164-3-dmukhin@ford.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: <20250513052809.3947164-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

This is adjusting some MISRA configuration.  I'm reasonably sure the
change is fine as we're simply removing the referenced helper, but can
we get a second opinion from anyone who knows what
function-macro-properties.json is supposed to be doing?

Thanks,

~Andrew

On 13/05/2025 6:28 am, dmkhn@proton.me wrote:
> From: Denis Mukhin 
>
> Remove __vmread() and adjust ECLAIR configuration to account for the change.
>
> Signed-off-by: Denis Mukhin 
> ---
>  docs/misra/function-macro-properties.json | 9 ---------
>  xen/arch/x86/include/asm/hvm/vmx/vmx.h    | 5 -----
>  2 files changed, 14 deletions(-)
>
> diff --git a/docs/misra/function-macro-properties.json b/docs/misra/function-macro-properties.json
> index 74058297b5..59ba63626e 100644
> --- a/docs/misra/function-macro-properties.json
> +++ b/docs/misra/function-macro-properties.json
> @@ -152,15 +152,6 @@
>              "taken": ""
>           }
>        },
> -      {
> -         "type": "function",
> -         "value": "^__vmread.*$",
> -         "properties":{
> -            "pointee_write": "2=always",
> -            "pointee_read": "2=never",
> -            "taken": ""
> -         }
> -      },
>        {
>           "type": "function",
>           "value": "^hvm_pci_decode_addr.*$",
> diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
> index d85b52b9d5..299e2eff6b 100644
> --- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
> +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
> @@ -336,11 +336,6 @@ static always_inline unsigned long vmread(unsigned long field)
>      return value;
>  }
>  
> -static always_inline void __vmread(unsigned long field, unsigned long *value)
> -{
> -    *value = vmread(field);
> -}
> -
>  static always_inline void __vmwrite(unsigned long field, unsigned long value)
>  {
>      asm goto ( "vmwrite %[value], %[field]\n\t"



From xen-devel-bounces@lists.xenproject.org Fri May 16 12:52:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 12:52:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987114.1372559 (Exim 4.92)
	(envelope-from )
	id 1uFuY3-0000vM-Ap; Fri, 16 May 2025 12:52:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987114.1372559; Fri, 16 May 2025 12:52: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 1uFuY3-0000vF-7y; Fri, 16 May 2025 12:52:23 +0000
Received: by outflank-mailman (input) for mailman id 987114;
 Fri, 16 May 2025 12:52:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFuY2-0000v9-1Y
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 12:52:22 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9b0aac8a-3254-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 14:52:21 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad5297704aaso234883966b.2
 for ; Fri, 16 May 2025 05:52: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
 a640c23a62f3a-ad52d498909sm155436266b.126.2025.05.16.05.52.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 05:52: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" 
X-Inumbo-ID: 9b0aac8a-3254-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747399940; x=1748004740; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=wNjdHtoCcHajYpCSwI5NBOR2R4plRxMcHd7OE8dP9Vk=;
        b=TRqpQyqDRV7Omt8UCfizaNQStB0CQflfMV4A3SkmNiAzNMgG3fBYsFphmgl4GKa3Or
         CJm3Uk4iIClCLF3nO3wKRhq6hglUlkXYIrUwQe6MlsotxTpggAfu0uVNBvwtZG8IhmBa
         haqg6rHaA5cfgttDEV8dHp8/9QAwi1dRYJlhbK/dk1TtlGkHbwpnn5aFyMERWeO2FCyR
         CKuODOhMsTqz8dYpt2Z05PXRpDusscMKe5hbjeyfpgG6zDWrKZ1iWeUUzS8Z70UWLOBE
         XCem9OGjBuZ7Ygwmu4p5nsLkhQYv1naOk1kQEHggchEJiBHAOGAr6tkkaVCXCGXK26JA
         yaRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747399940; x=1748004740;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=wNjdHtoCcHajYpCSwI5NBOR2R4plRxMcHd7OE8dP9Vk=;
        b=Y5sgqmX6hjSZSQpEgAAFnNPzlDdELkUFCqljhKtXtibmhyQs3ygWYxV4dGI+BxAzjO
         B0LE5hR/wO/xB8bPkkqntd9uRsgTW8kMr1W9zlbUPu4jmEiyOdD7WkicIWl7NhFyMHN+
         GiCSYIdo5I9QB+cJvJ6Wsywj7Icl+ZdQNid77Q+Gqn72yy8ekPaomscGaxGTE02Fl85S
         SH5wvC51mT0dMQTBC9TOwREkYh1lZgcbLdJFuyQ28BX/7+3Fhh4xnqLSx+BTAPWOjV7U
         37Gg9pi/7Mw6n60pxjOZopLxogykSIViBPDkf8mRIlkWe2MpPh2mhz46Lc5g1rSTFHwd
         9iVg==
X-Forwarded-Encrypted: i=1; AJvYcCVirmE+INVaGwD3l6HN7g6PkbKsw5PgmP9I5rYEJJ2ZeKn3j2bMGQIGwPOp9XJdMRh59OD+PyAPriw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwApW5A3rjZVHgjg/oiaYekxDpLNGn1bq/vpZ0GQX4KIzb8LaQP
	2gXr7pqdJpKZ7VWF2lENZqG1tQ3GoXqEIwFkSGICnHIJpg119/KEeerxtmpJh7iABQ==
X-Gm-Gg: ASbGncvQVBmXmWmkNu3AJf6ByS3oJ44ZHLQCuHJV6rwIhMDVHLw3YAIJoghq/NbAxnM
	4E7fPVwNKvdafDeRyu0iRWi/NyxsJWpB8Hoe94VKSikOBbN1pCRfPm7XHZLDH6oXJOu2spPO1b1
	uQpoLZA6judKrEOv2193nh1xE7BFtGMhhbR6J2f/5xkEnYJ5QLsycrmKOgwSkM1oUuKiNB9N/Xt
	gLYwFcAh34VdKJOi92IIn5wu4ul4LLDjIJRU5kfPHmxN47B0wihLHgOrZ8RiPCejCZwFkwWxQYG
	Lyy6gccP7ahwsZgtaQHRr0AYW3xzA2U9yu4ibgSGGW5R9ZhLO6ktHo+g/sZ/U9Qki573OatDnzW
	3d45TBOs3/u3VpopM+xVr2WyfRVpCmPxn7tMM
X-Google-Smtp-Source: AGHT+IG9RhBAWIYCpM4x0Bu0AHn/Zwj8vJMXMnCF7WusnXbmRXto/YmSvsFENCf7E4xtLxB1uOYSPA==
X-Received: by 2002:a17:907:1c0a:b0:ad2:e683:a776 with SMTP id a640c23a62f3a-ad52d45c10emr326456966b.1.1747399940404;
        Fri, 16 May 2025 05:52:20 -0700 (PDT)
Message-ID: <62b0e1b4-4dc5-4ba5-9589-5488b04b3da6@suse.com>
Date: Fri, 16 May 2025 14:52:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/vmx: Annotate the VMCS field widths
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Denis Mukhin , xen-devel@lists.xenproject.org
References: <20250516122916.27070-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: <20250516122916.27070-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 14:29, Andrew Cooper wrote:
> This helps identify the appropriate type to use.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Fri May 16 12:53:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 12:53:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987118.1372568 (Exim 4.92)
	(envelope-from )
	id 1uFuYl-0001LP-IZ; Fri, 16 May 2025 12:53:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987118.1372568; Fri, 16 May 2025 12:53: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 1uFuYl-0001LI-G3; Fri, 16 May 2025 12:53:07 +0000
Received: by outflank-mailman (input) for mailman id 987118;
 Fri, 16 May 2025 12:53:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFuYj-0001DF-Un
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 12:53:06 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b4a7befa-3254-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 14:53:04 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 5450D4EE0739;
 Fri, 16 May 2025 14:53: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" 
X-Inumbo-ID: b4a7befa-3254-11f0-9ffb-bf95429c2676
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=1747399983;
	b=pVVj/R/SsydW29TmR+Ty4FdZd3Dr8D5J87Z3I2dCZdwlnK2B+LkfktWrAEnkohyorVyP
	 Xtsy0YevNxj1pWU2NEHgvnhx4ff1z2bE9tSXgBD5wtelf1zt50S9DrqhkbPPEzpqv+TAl
	 7jdCha9qQnxXhiU6K4egKPdqvdTgKIPDmCMiJRjg7cyPA7nV6dNwoe9C4zE1VdkiEDmgP
	 k4Pa6W1tOsC2X9jeEZGlDvcDYw61/dnC/LuH0l6XnGezOr+kgPu5+bjtUbCBXn1PAi4qj
	 12PuJSAWpnG8vjeREtsvOtewA9h5+SzYJj8pvBmYfRLTWp02m95PQHWoaTafVin80rTch
	 YB71xe8mO8r8qK130V7mX2wRcfHeTU0FYM1dWQ4UQGP1zenQqi2eakIm6y3nmlACQfNQJ
	 eoASky968pxvrgb+4mUe/MMKbEg20r9w/vTAIzOV9neeqgECRTzsiZga7X2gXB9fPOFNp
	 Hb9tSW/gmfCBQmAz9eSGqtjfUcR60duv99U76h7NdJjJ/QgFTdcGEItQsU+3ITpKfyYo0
	 ke6Phq7AK24csuspal1eQbaJ2V0+ZM6wR6eZHkyFwSIL9Uo9RJxYsUutacxkRXE1WzQGv
	 0Ev1sB9qmbP98d/NcnEt1a4tZ/0rh857g679IoCRk55AbXOC/QQugXRWwRd1HvI=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1747399983;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=FleCSofpFpSueE1Xkc0dKlgxuyo7SvDJ1/JJXedVDA8=;
	b=po0sPP6rI6PXScujQoqUHYfZenOpu3oR+1DKg0gYGERljSC797dEI9QfOxrtAOGjZC48
	 oJtF+BhT2HSozxOWB/02303UqH3C3qRJWSrxOA8d0Qnzxa0ezm9BuaGJArGU8XuxYZEw/
	 UtrpukM9c6sAAsUGX3UJO3Ch3O2McBi5/1o6V3QE9ByXIN2qMlfa95GHuDsQxUsu2dpjd
	 B7sX1o5DQ+P9bvvfFUCBMOsjFybP3y6M5vf+s/AkP3JVQA8WgwaWqOFJ+rO5OQre2rQi2
	 j1IkMu686Yg1baP4keBDxVKtwuVNR6uzDJRR/bsD0iiaEbgvoDgoZ/MHu8vrMwtD6xhv3
	 VyylkV5oxv1/I8IHWAiPPe3PtIHqPDNAtKw2fltrW6XDo3qeH3R6hltrDdCt9Hvqq2A05
	 vefVx16T8aajPDyxXhAgXaTChwpY/WVeZFfoQX5U780p7U19KToNhuKV68xJqq9ffaXn3
	 2HAfqY8ZtTUpKknABkZemo2u7bb0pnPxNxcmcjgREijV329xIAxgqHjX3EVDkRbJG8BeC
	 GDXUPn6QX3rJV28qI+/1Eik+Wk1q1eYlcPGwbygrLGdrS0R0SlBEzrRuGbD58ZtOpEvXC
	 b9dX5kEN2tmKs8LkOehtMEb+rqv2SvwoLb8qzg3D//V0dPEPvJr9DOzSoiiHZSc=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1747399983; bh=BdrcMtXgTeckk01WS9gOq+O998+fCeZVeoz+dPfdJv4=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=a2h/d1NqwOD5l3x0W1PGTE3IpQEb5HZrkbZUi+pMzFQgJy7HQIZ2qpO7I1jzSwAAm
	 SRDY54YoWbK1MTvUzhXTAzNrIGa2VDY3+V4z2gPf1AP8WIFyoSMozf8CZbuj1ehU2a
	 sm+VNNjRZnKuBZQlIO8Ipw3pPKGPjgF30YRgw56ynGEXzEmCX/UuXyKmMgIGvCohsW
	 Sp+pMwKVkzFQhe0TgHaFIQ15EinD3uohOVosF8tiTgyMfqDCTpv9Gr6arImGBpHYU0
	 FvQf/PmmcmOytPAtUZ9vxsv+B7gcc2qbwY8ti3dxvAsDZKyNY/FSBkvcXx0wOP9FZ9
	 LPC2NcWDrZnCQ==
MIME-Version: 1.0
Date: Fri, 16 May 2025 14:53:03 +0200
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: dmkhn@proton.me, xen-devel@lists.xenproject.org, jbeulich@suse.com,
 roger.pau@citrix.com, consulting@bugseng.com, dmukhin@ford.com, Stefano
 Stabellini 
Subject: Re: [PING MISRA] Re: [PATCH v5 2/2] x86/vmx: remove __vmread()
In-Reply-To: <85f778d1-7fb5-47da-9153-35333e486d24@citrix.com>
References: <20250513052809.3947164-1-dmukhin@ford.com>
 <20250513052809.3947164-3-dmukhin@ford.com>
 <85f778d1-7fb5-47da-9153-35333e486d24@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

On 2025-05-16 14:45, Andrew Cooper wrote:
> Hello,
> 
> This is adjusting some MISRA configuration.  I'm reasonably sure the
> change is fine as we're simply removing the referenced helper, but can
> we get a second opinion from anyone who knows what
> function-macro-properties.json is supposed to be doing?
> 
> Thanks,
> 
> ~Andrew
> 

Hi Andrew,

sorry, it slipped under other emails. The change is ok.

> On 13/05/2025 6:28 am, dmkhn@proton.me wrote:
>> From: Denis Mukhin 
>> 
>> Remove __vmread() and adjust ECLAIR configuration to account for the 
>> change.
>> 
>> Signed-off-by: Denis Mukhin 

Reviewed-by: Nicola Vetrini 

>> ---
>>  docs/misra/function-macro-properties.json | 9 ---------
>>  xen/arch/x86/include/asm/hvm/vmx/vmx.h    | 5 -----
>>  2 files changed, 14 deletions(-)
>> 
>> diff --git a/docs/misra/function-macro-properties.json 
>> b/docs/misra/function-macro-properties.json
>> index 74058297b5..59ba63626e 100644
>> --- a/docs/misra/function-macro-properties.json
>> +++ b/docs/misra/function-macro-properties.json
>> @@ -152,15 +152,6 @@
>>              "taken": ""
>>           }
>>        },
>> -      {
>> -         "type": "function",
>> -         "value": "^__vmread.*$",
>> -         "properties":{
>> -            "pointee_write": "2=always",
>> -            "pointee_read": "2=never",
>> -            "taken": ""
>> -         }
>> -      },
>>        {
>>           "type": "function",
>>           "value": "^hvm_pci_decode_addr.*$",
>> diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h 
>> b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
>> index d85b52b9d5..299e2eff6b 100644
>> --- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
>> +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
>> @@ -336,11 +336,6 @@ static always_inline unsigned long 
>> vmread(unsigned long field)
>>      return value;
>>  }
>> 
>> -static always_inline void __vmread(unsigned long field, unsigned long 
>> *value)
>> -{
>> -    *value = vmread(field);
>> -}
>> -
>>  static always_inline void __vmwrite(unsigned long field, unsigned 
>> long value)
>>  {
>>      asm goto ( "vmwrite %[value], %[field]\n\t"

-- 
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 May 16 12:54:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 12:54:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987126.1372579 (Exim 4.92)
	(envelope-from )
	id 1uFua4-0001w3-T3; Fri, 16 May 2025 12:54:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987126.1372579; Fri, 16 May 2025 12:54: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 1uFua4-0001vw-PB; Fri, 16 May 2025 12:54:28 +0000
Received: by outflank-mailman (input) for mailman id 987126;
 Fri, 16 May 2025 12:54:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFua4-0001vm-2i
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 12:54:28 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5bc3a1d-3254-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 14:54:26 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-442f9043f56so9784955e9.0
 for ; Fri, 16 May 2025 05:54:26 -0700 (PDT)
Received: from [10.81.43.161] ([46.149.103.12])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a362997dc8sm1378620f8f.46.2025.05.16.05.54.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 05:54: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" 
X-Inumbo-ID: e5bc3a1d-3254-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747400066; x=1748004866; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6Zg4QjNR1jM2damzt0JCGQ6PBfuBtHfM09WrAArsmYU=;
        b=wJZf0wcCuqXsjLidfBOEGLegwJYpULPm0/hfIOAOPumTyVTX0qnAJzn1bkEleDxcwP
         8amkmNKaZtB7hJf9iIG4g6AACxgtDvYABe8SHRtIVSeO/5G1uleAo4hzETj9av5+p8MR
         aO/PeNMKIzfs/Gf1eVYBesD1kZVfL2jMmeIck=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747400066; x=1748004866;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6Zg4QjNR1jM2damzt0JCGQ6PBfuBtHfM09WrAArsmYU=;
        b=rQ617TZTJt1aFlEaBcvgK0f6Glw+LWNApMgPEAN1gdPFpP1HMSxH6ovovmqoaEnmAe
         WriU3smiFu9F497UJwIPEZ3czrq84DZQ/GFo3ZbMz/U1nzIQbXdz0mfmE6Bg5BSpECvk
         8Xxy3HZaSz9zjO0dOxvIVBVqqyxar5poS31FOCwd0LaQk3G2NWdVy+0grk5xg4pO16tr
         m8ea+UoIP0N821rCAAmKLNLIPXecMRu6M/Gi9sffoinLqhjptTvj3aWb6jz4NoVg5DlM
         CFVoXu6PW+KgRlRfFkcTgoSooMEQPckNsKNYl1yvB9KusTwrIAqHrPG/daaKXXx2/4iR
         UWAA==
X-Forwarded-Encrypted: i=1; AJvYcCWP+Yqjl0LTuMW7YodGBGR57OMUEeCLM8ZIIpl0LczDjdIxneDyssXx3DCMUavS5JTVHVw/Hvoaqik=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwPzo7310Y5qy1tCOVy1GPj+EjgQObS24EHz7RSYTY6WnDow7Py
	XlxDkSQ4F+b1STN3kpD9y5A8HOGxy5B4575aym9Fk+lvCeWDvWtYm807GrBuQAPKZpE=
X-Gm-Gg: ASbGncumdDVpZTAfz2QsZGWi5HXzrWW5VXxCvxZFMy+HGwVDzsvgkOpRn/uGzWsS5WN
	OgC5XRfgnDYim8awkKP3oBrLHeY7x6oKPiC+tNxsX1mQRxwobt7eatkRpB2DII9byocurCq6JJL
	5GtVuOcfXgs0/J4If7q/6vpo2F7k94MNbWcIJXie56qMVNMBLy6J0EsdsnnYOahUpseO/wavyv7
	Jt+Mh/bYq9j505ubhDAHVpXVCt7h+g3UrD5/KtS0e2DEt3UDlz2bQ6FebfHv2U09wRZU6byzEES
	BtlHTiIrY4ueMUOjK2KF8+DR0F7Y7JiayOqfdW34N4mpgmTUwS7u+dQJVQq52A==
X-Google-Smtp-Source: AGHT+IGpxLRO0nTd8ow0k5fTXCqi402xJNGUf8EG6A7fil986Cfu4yZ9miWMZIINdRfzHp453+/0cg==
X-Received: by 2002:a05:600c:524c:b0:43d:97ea:2f4 with SMTP id 5b1f17b1804b1-442fd62732fmr36725495e9.12.1747400065706;
        Fri, 16 May 2025 05:54:25 -0700 (PDT)
Message-ID: 
Date: Fri, 16 May 2025 13:54:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PING MISRA] Re: [PATCH v5 2/2] x86/vmx: remove __vmread()
To: Nicola Vetrini 
Cc: dmkhn@proton.me, xen-devel@lists.xenproject.org, jbeulich@suse.com,
 roger.pau@citrix.com, consulting@bugseng.com, dmukhin@ford.com,
 Stefano Stabellini 
References: <20250513052809.3947164-1-dmukhin@ford.com>
 <20250513052809.3947164-3-dmukhin@ford.com>
 <85f778d1-7fb5-47da-9153-35333e486d24@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

On 16/05/2025 1:53 pm, Nicola Vetrini wrote:
> On 2025-05-16 14:45, Andrew Cooper wrote:
>> Hello,
>>
>> This is adjusting some MISRA configuration.  I'm reasonably sure the
>> change is fine as we're simply removing the referenced helper, but can
>> we get a second opinion from anyone who knows what
>> function-macro-properties.json is supposed to be doing?
>>
>> Thanks,
>>
>> ~Andrew
>>
>
> Hi Andrew,
>
> sorry, it slipped under other emails. The change is ok.

No worries.  These things happen.

>
>> On 13/05/2025 6:28 am, dmkhn@proton.me wrote:
>>> From: Denis Mukhin 
>>>
>>> Remove __vmread() and adjust ECLAIR configuration to account for the
>>> change.
>>>
>>> Signed-off-by: Denis Mukhin 
>
> Reviewed-by: Nicola Vetrini 

Thankyou.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 16 13:19:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 13:19:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987137.1372589 (Exim 4.92)
	(envelope-from )
	id 1uFuyI-0005Wr-OS; Fri, 16 May 2025 13:19:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987137.1372589; Fri, 16 May 2025 13:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFuyI-0005Wk-Ks; Fri, 16 May 2025 13:19:30 +0000
Received: by outflank-mailman (input) for mailman id 987137;
 Fri, 16 May 2025 13:19:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFuyI-0005We-03
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 13:19:30 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 64783a4a-3258-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 15:19:28 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id C9C15A4E7B5;
 Fri, 16 May 2025 13:19:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A561C4CEE4;
 Fri, 16 May 2025 13:19: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" 
X-Inumbo-ID: 64783a4a-3258-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747401566;
	bh=oaUy859dTcPr4O32A6D5WWt1R4OnjuyJMMmb5wlJIm8=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=iDb+IMC//aX/x5nhjvb58hALgb2f9WnP8dQdFi/IebqgY5NZyymEASPMa46QOmkWZ
	 UwZIAvwWdTMFwlWSD1mbNEG3NbjSq/QjvKT13dtrEo1aUk2O8tRxHucWSK5dk6kThQ
	 bipJC1UdM2t4QT3UqsmsOb3VzB/qCF3/JW9p5hVp3y4kRdiSUIZikQrfMyi1Xhvf4J
	 d20/f+L6D11ww1wFQ0jhbLfou8JcteHWU5X5taApXcwEULk8fY38p2DN7OE5RJUhmU
	 suyOC+HV2K0rQH8RccDoV8gFbBjEj6AK8VkT4BudkAqXTIsT8s3XdSfw+bo563odYv
	 SVS86C9BWl1ow==
Date: Fri, 16 May 2025 15:19:20 +0200
From: Ingo Molnar 
To: Xin Li 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
	rafael@kernel.org, lenb@kernel.org
Subject: Re: [PATCH v1 2/3] x86/xen/msr: Fix uninitialized symbol 'err'
Message-ID: 
References: <20250512084552.1586883-1-xin@zytor.com>
 <20250512084552.1586883-3-xin@zytor.com>
 
 <30affad5-4f26-4e22-9d64-b8ece1199773@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <30affad5-4f26-4e22-9d64-b8ece1199773@zytor.com>


* Xin Li  wrote:

> On 5/15/2025 8:29 AM, Ingo Molnar wrote:
> > 
> > * Xin Li (Intel)  wrote:
> > 
> > > xen_read_msr_safe() currently passes an uninitialized argument err to
> > > xen_do_read_msr().  But as xen_do_read_msr() may not set the argument,
> > > xen_read_msr_safe() could return err with an unpredictable value.
> > > 
> > > To ensure correctness, initialize err to 0 (representing success)
> > > in xen_read_msr_safe().
> > > 
> > > Because xen_read_msr_safe() is essentially a wrapper of xen_do_read_msr(),
> > > the latter should be responsible for initializing the value of *err to 0.
> > > Thus initialize *err to 0 in xen_do_read_msr().
> > > 
> > > Fixes: 502ad6e5a619 ("x86/msr: Change the function type of native_read_msr_safe()")
> > > Reported-by: Dan Carpenter 
> > > Closes: https://lore.kernel.org/xen-devel/aBxNI_Q0-MhtBSZG@stanley.mountain/
> > > Signed-off-by: Xin Li (Intel) 
> > > ---
> > >   arch/x86/xen/enlighten_pv.c | 5 ++++-
> > >   1 file changed, 4 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> > > index 3be38350f044..01f1d441347e 100644
> > > --- a/arch/x86/xen/enlighten_pv.c
> > > +++ b/arch/x86/xen/enlighten_pv.c
> > > @@ -1091,6 +1091,9 @@ static u64 xen_do_read_msr(u32 msr, int *err)
> > >   {
> > >   	u64 val = 0;	/* Avoid uninitialized value for safe variant. */
> > > +	if (err)
> > > +		*err = 0;
> > > +
> > >   	if (pmu_msr_chk_emulated(msr, &val, true))
> > >   		return val;
> > > @@ -1162,7 +1165,7 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err)
> > >   static int xen_read_msr_safe(u32 msr, u64 *val)
> > >   {
> > > -	int err;
> > > +	int err = 0;
> > >   	*val = xen_do_read_msr(msr, &err);
> > >   	return err;
> > 
> > So why not initialize 'err' with 0 in both callers, xen_read_msr_safe()
> > and xen_read_msr(), and avoid all the initialization trouble in
> > xen_do_read_msr()?
> 
> Yeah, I should make the change in xen_read_msr() too.
> 
> However xen_do_read_msr() should be implemented in a defensive way to
> set *err properly as it's part of its return value.  Actually it was so,
> but one of my previous cleanup patch removed it because err is no longer
> passed to pmu_msr_chk_emulated().

Maybe. It's up to Juergen though.

Thanks,

	Ingo


From xen-devel-bounces@lists.xenproject.org Fri May 16 13:33:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 13:33:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987176.1372598 (Exim 4.92)
	(envelope-from )
	id 1uFvBs-0000DK-Sn; Fri, 16 May 2025 13:33:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987176.1372598; Fri, 16 May 2025 13:33: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 1uFvBs-0000DD-Pv; Fri, 16 May 2025 13:33:32 +0000
Received: by outflank-mailman (input) for mailman id 987176;
 Fri, 16 May 2025 13:33:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFvBr-0000D2-6K
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 13:33:31 +0000
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com
 [2a00:1450:4864:20::42a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ab047b2-325a-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 15:33:30 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a361b8a66cso384097f8f.2
 for ; Fri, 16 May 2025 06:33:30 -0700 (PDT)
Received: from andrew-laptop.. ([46.149.103.13])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca88990sm2919757f8f.68.2025.05.16.06.33.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 06:33: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" 
X-Inumbo-ID: 5ab047b2-325a-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747402409; x=1748007209; 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;
        bh=+563COaD5Tzxy42DVJiIP27O5Q90TLkJxpGFzPREXj4=;
        b=Bg0glXHKqiNNJ/6YKjniaGyx6j2IuPpd6YOTS9q5ImcffaTvCl9wScAvh+sU80u8b7
         O8kHMgzTZnbvXYw4/CPuDdF2xFlLZy/6v18GQcVohSRRcL/YA9pN4KWe9S9URiHiWa8A
         p62+SLQmRmint5E671YZVLWtBRsf3XANthPmw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747402409; x=1748007209;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=+563COaD5Tzxy42DVJiIP27O5Q90TLkJxpGFzPREXj4=;
        b=gbproIwZMWrx3+MmprzzEDxw4hPNboKojzJuj9Rf8l/0giDbDo+sAtmtWzn5u1lkNA
         mxOeUMi25Mqc9QM1YDUkdgjK5L+vWHg0jMdCxPH6SxHIpFOG5T3wBU/pqHTNT8kSET5v
         Pcuh4DhX+lMnAJEzpJbOWwi/goZeaRKIGAyIFrNUxgXGdKGKDyMePE11H38kzVMDJiyp
         Dy2Cum6mjgLIdsT1XNgCYwmXvWsnEwhHaClAmQ/B2A0RZ4PBF0Yj0/0p05sfPR7K6QG+
         WSBv8mgntoDlEOzIhdLx1WLm2+KRNVeVOEAcpFT2j4qRsLiqydADr9nZ0si9vFDwBr5g
         PQQA==
X-Gm-Message-State: AOJu0YwkLBjYREcnzwndRNRPH809o3XHkbm8YpKFPIxGdDMtl+I8awgr
	I5MSOuqgvYhfoQYuMfWEaJPb+kntdNEF1iZBgc86jxlVkeZzmEIuhHXErFgnEQNTf3JdF0UlZ2R
	Ldlek
X-Gm-Gg: ASbGncsMySx/kJvgOGiffgfpSP0qM0Ip7BnK6bONQktriHnrQbuTKbPNvV4RsnF6RGn
	rqZ6zErhXkcZ/yaKgmHTGfvsO/mYgYUu7HWW6GGh1CT9m6Gb3DUCfBoD6t3j/jYu1z4+BC6mbvl
	WOvRwEiZNTZHcCWeHAzrQUjvPv3HPSnERNjELe/F1Gli0BM/SmHbe92/Js58rs9DEJm/MeZt4GU
	0/PTKxHQWWI+N5D/ce/7rkAHqorKC8fvDi809CmrcaE11IH4qpMnD5OeSexmmfZqda23u/1CIGJ
	6X5ll+LXYkfczNvRgxSugiK/1CwtIcJ1qM3Bol1A9MjEer2lO/11Fomzt/c3lbU=
X-Google-Smtp-Source: AGHT+IGBZcA/D0toS/bzcF2SEeqek/9hmi29cajL7lU/dxawRyQdg/bLnBswuTorEq6YmiJwR4jRmQ==
X-Received: by 2002:a5d:64ee:0:b0:3a0:8495:cb75 with SMTP id ffacd0b85a97d-3a35c834f85mr3921790f8f.9.1747402409082;
        Fri, 16 May 2025 06:33:29 -0700 (PDT)
From: Andrew Cooper 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/stubs: Consolidate the stubs infrastructure in asm/stubs.h
Date: Fri, 16 May 2025 14:33:26 +0100
Message-Id: <20250516133326.49587-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Very few files need the stubs.  Move the infrastructure out of
processor.h and config.h into a new stubs.h, and adjust the includes
accordingly.

Make the per-cpu struct stubs be read mostly; they're unmodified
during the uptime of the CPU, and move them into smpboot.c seeing as
that's where they're allocated and freed.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

This is from one of my several failed attempts to deal with the stubs
more nicely in XSA-469.  Still, getting the infrastructure out of
processor.h is a good cleanup.

The FRED series is probably going to result in getting rid of
x86_64/traps.c, given that most of the content gets dropped.
---
 xen/arch/x86/alternative.c           |  1 +
 xen/arch/x86/extable.c               |  8 +++---
 xen/arch/x86/hvm/vmx/vmx.c           |  1 +
 xen/arch/x86/include/asm/config.h    |  5 ----
 xen/arch/x86/include/asm/processor.h | 11 ---------
 xen/arch/x86/include/asm/stubs.h     | 37 ++++++++++++++++++++++++++++
 xen/arch/x86/pv/emul-priv-op.c       |  1 +
 xen/arch/x86/setup.c                 |  1 +
 xen/arch/x86/smpboot.c               |  3 +++
 xen/arch/x86/x86_64/traps.c          |  3 +--
 xen/arch/x86/x86_emulate/private.h   |  2 ++
 11 files changed, 52 insertions(+), 21 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/stubs.h

diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index ecc56964bd9c..d4fe56b3dae8 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 1572efa69a00..8b78c75d3374 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -1,16 +1,18 @@
 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
 
+#include 
+#include 
+
 #define EX_FIELD(ptr, field) ((unsigned long)&(ptr)->field + (ptr)->field)
 
 static inline unsigned long ex_addr(const struct exception_table_entry *x)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 827db6bdd807..c2262c584822 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -48,6 +48,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static bool __initdata opt_force_ept;
diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h
index f0123a7de983..3553bf89dc97 100644
--- a/xen/arch/x86/include/asm/config.h
+++ b/xen/arch/x86/include/asm/config.h
@@ -49,11 +49,6 @@
 /* Primary shadow stack is slot 5 of 8, immediately under the primary stack. */
 #define PRIMARY_SHSTK_SLOT 5
 
-/* Total size of syscall and emulation stubs. */
-#define STUB_BUF_SHIFT (L1_CACHE_SHIFT > 7 ? L1_CACHE_SHIFT : 7)
-#define STUB_BUF_SIZE  (1 << STUB_BUF_SHIFT)
-#define STUBS_PER_PAGE (PAGE_SIZE / STUB_BUF_SIZE)
-
 /* Return value for zero-size _xmalloc(), distinguished from NULL. */
 #define ZERO_BLOCK_PTR ((void *)0xBAD0BAD0BAD0BAD0UL)
 
diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index eacd425c5350..1820e04a32f9 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -424,17 +424,6 @@ static inline void enable_nmis(void)
 
 void nocall sysenter_entry(void);
 
-struct stubs {
-    union {
-        void(*func)(void);
-        unsigned long addr;
-    };
-    unsigned long mfn;
-};
-
-DECLARE_PER_CPU(struct stubs, stubs);
-unsigned long alloc_stub_page(unsigned int cpu, unsigned long *mfn);
-
 static inline uint8_t get_cpu_family(uint32_t raw, uint8_t *model,
                                      uint8_t *stepping)
 {
diff --git a/xen/arch/x86/include/asm/stubs.h b/xen/arch/x86/include/asm/stubs.h
new file mode 100644
index 000000000000..a520928e9a50
--- /dev/null
+++ b/xen/arch/x86/include/asm/stubs.h
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef X86_ASM_STUBS_H
+#define X86_ASM_STUBS_H
+
+/*
+ * Xen has several per-cpu executable stubs which are written dynamically.
+ * These are:
+ *
+ * - The SYSCALL entry stubs, LSTAR and CSTAR.  These are written on boot, and
+ *   are responsible for moving back onto Xen's stack.
+ *
+ * - The emulation stub.  This is used to replay an instruction or sequence
+ *   which trapped for emulation.
+ *
+ * The stubs have an executable alias in l2_xenmap[] (i.e. within 1G of the
+ * rest of .text), and are written via map_domain_page().
+ */
+
+#include 
+
+/* Total size of syscall and emulation stubs. */
+#define STUB_BUF_SHIFT (L1_CACHE_SHIFT > 7 ? L1_CACHE_SHIFT : 7)
+#define STUB_BUF_SIZE  (1 << STUB_BUF_SHIFT)
+#define STUBS_PER_PAGE (PAGE_SIZE / STUB_BUF_SIZE)
+
+struct stubs {
+    union {
+        void (*func)(void);
+        unsigned long addr;
+    };
+    unsigned long mfn;
+};
+
+DECLARE_PER_CPU(struct stubs, stubs);
+unsigned long alloc_stub_page(unsigned int cpu, unsigned long *mfn);
+
+#endif /* X86_ASM_STUBS_H */
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 295d847ea24c..4da3f379ef3e 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 25189541244d..1f5cb67bd0ee 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 0189d6c332a4..41fe67d43c94 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -57,6 +58,8 @@ static cpumask_t scratch_cpu0mask;
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, send_ipi_cpumask);
 static cpumask_t send_ipi_cpu0mask;
 
+DEFINE_PER_CPU_READ_MOSTLY(struct stubs, stubs);
+
 cpumask_t cpu_online_map __read_mostly;
 EXPORT_SYMBOL(cpu_online_map);
 
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index ac0fafd72d31..b10bd0becafb 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -330,8 +331,6 @@ static unsigned int write_stub_trampoline(
     return ROUNDUP(p - stub, 16);
 }
 
-DEFINE_PER_CPU(struct stubs, stubs);
-
 void nocall lstar_enter(void);
 void nocall cstar_enter(void);
 
diff --git a/xen/arch/x86/x86_emulate/private.h b/xen/arch/x86/x86_emulate/private.h
index 30be59547032..c4138afe1db5 100644
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -10,8 +10,10 @@
 
 # include 
 # include 
+
 # include 
 # include 
+# include 
 # include 
 # include 
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 13:41:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 13:41:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987191.1372609 (Exim 4.92)
	(envelope-from )
	id 1uFvJq-000207-QN; Fri, 16 May 2025 13:41:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987191.1372609; Fri, 16 May 2025 13:41: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 1uFvJq-000200-N8; Fri, 16 May 2025 13:41:46 +0000
Received: by outflank-mailman (input) for mailman id 987191;
 Fri, 16 May 2025 13:41:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFvJp-0001zu-Cj
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 13:41:45 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 80ba7fb6-325b-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 15:41:43 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ad23db02350so397456066b.1
 for ; Fri, 16 May 2025 06:41: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
 a640c23a62f3a-ad52d4383d6sm162906866b.102.2025.05.16.06.41.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 06:41: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" 
X-Inumbo-ID: 80ba7fb6-325b-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747402903; x=1748007703; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UnyRK+x/RwRHJkGLjqyRDTT8t9f+YF4lAou/GdChwkk=;
        b=E/4yEfNVpEy7oyZaOF9guHERhPGJWgElizkz8658C30LeNeR2Zu2nRuO3dfappJV+L
         VrmvZFSvvdrfT5KChUvKifFvVnQEYse3hAgX60XJBryiZA5MA199PVOHgLii8K/Ub1pJ
         NKViCrhXIVyFsINY/MmYrSnk7kGb39YbUqLqE2LlKnYMJm2pRog/xg6YPW1nKlnOO/I0
         y4oO8cuqZaP49FVb72jEP6vTBUpPIXppwxf2TZR2gnMNmLKO+KVDm5lwD8sTD3d7yI+f
         9TpR63PEfiokBOpx/PWKf2g3bTUrIVLooHyCViWCkIEYke4Hd6PuCv8NkAqKeXe1Psk+
         OEPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747402903; x=1748007703;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UnyRK+x/RwRHJkGLjqyRDTT8t9f+YF4lAou/GdChwkk=;
        b=LD20Vd3AyQFI/fkqO4jv/KItGei2nv4FA0Q76fseN0HymuWuKUfLmqLfIQ6Fktda+u
         g6AQZjE7pvmncnq3JDnjtiTCUPrCPY+O3kJefxphGs9knIz9gtOKB4ZUjbrVCmvNZxtg
         j1g3Y/SFeQ/fTvd/snnt40x9kV7UZtxrgWjlKQ3YpD9coHjPRl3/+Iv34GHrLbQw0l1s
         eZLnquKSBUvv9fLGISKU+9OGFmvnIndCQ5Wrd6Kfra9CEQRk8meU7fsiLB/eRauOUfnL
         8YO4iZO3rHaw26VopMvo9XHjnIJmv9mbbfOUnEF3yrdV77kVv9pKKdnA9464bmIVRYwW
         HQ3A==
X-Forwarded-Encrypted: i=1; AJvYcCXT+gSSb8OdlhOJwcYGFORG39HlYCu3536NlqH55tnlmN77e3kcdP4Zo04VJ1T618oq/SAQzP3RbY0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YywLTv33v6C3GmPOqhKghOcuBthzVXmQ/ZEBGaCx3os3D1nx9RE
	LVibdVLUsdjtefwNAumXvGfN8BKFeuVMR5+Sqr+0di238FY/Ky4bklvooNBDouBvBw==
X-Gm-Gg: ASbGncsmv4x2BtVpMWwRh4JxKW/w8z3f2wpkzZuaEr16hSWw9af0Xx1eLyOb9NTndFx
	5hA6sN4za3WI67tihA6NzfuIh6ZgeXZ4m9n3BaEKe13Z4+iRYOl2nSdBzW0Io+1lzuqg3z/ut50
	+Fe0H22KD+sQ7DPHWY9rzQILxnF5o4IWOQvq64BVXkFMDkI7rzzO/a8fXU171TIZXlOjDnlmQSO
	OPsu7v8JQrvC7CjoVYtWll9mFQmOkE3xgEvCxf14E50q5VdqGRa6iezxfKks1nwQVq3J3kOmlIb
	HP7Id2qtVI/4j6Y86XHWz1pjEtnW/LNTgvoS9ywNZTAYncZqPutMXlpNBRvX40mZAIMJHE8BEYP
	o3mPfool3BGnGScUTdBwBLzyUiPYCsWObeDIN
X-Google-Smtp-Source: AGHT+IEXt2YdpqC5ftOjRKkCsumatiQ9yXVtJB/QhphRcRCMt7BXgcTPCN8hqWN5YzhqFe+Mjv1u0g==
X-Received: by 2002:a17:906:f29a:b0:ad5:3139:f41c with SMTP id a640c23a62f3a-ad5313a00b7mr244820666b.53.1747402902708;
        Fri, 16 May 2025 06:41:42 -0700 (PDT)
Message-ID: <4a1a8582-7503-49ca-8d34-bce3e101734a@suse.com>
Date: Fri, 16 May 2025 15:41:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/stubs: Consolidate the stubs infrastructure in
 asm/stubs.h
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250516133326.49587-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: <20250516133326.49587-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 15:33, Andrew Cooper wrote:
> Very few files need the stubs.  Move the infrastructure out of
> processor.h and config.h into a new stubs.h, and adjust the includes
> accordingly.
> 
> Make the per-cpu struct stubs be read mostly; they're unmodified
> during the uptime of the CPU, and move them into smpboot.c seeing as
> that's where they're allocated and freed.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 
with one possible suggestion:

> --- /dev/null
> +++ b/xen/arch/x86/include/asm/stubs.h
> @@ -0,0 +1,37 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef X86_ASM_STUBS_H
> +#define X86_ASM_STUBS_H
> +
> +/*
> + * Xen has several per-cpu executable stubs which are written dynamically.

This puts it pretty well. Yet in principle there may be further, perhaps
entirely different stubs in the future. Hence stubs.h feels a little
generic. What about exec-stubs.h?

Jan


From xen-devel-bounces@lists.xenproject.org Fri May 16 13:42:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 13:42:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987196.1372620 (Exim 4.92)
	(envelope-from )
	id 1uFvL1-0002UZ-3g; Fri, 16 May 2025 13:42:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987196.1372620; Fri, 16 May 2025 13:42: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 1uFvL0-0002US-W1; Fri, 16 May 2025 13:42:58 +0000
Received: by outflank-mailman (input) for mailman id 987196;
 Fri, 16 May 2025 13:42:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFvL0-0002UM-1S
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 13:42:58 +0000
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com
 [2a00:1450:4864:20::443])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ac924069-325b-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 15:42:56 +0200 (CEST)
Received: by mail-wr1-x443.google.com with SMTP id
 ffacd0b85a97d-3a0bd7f4cd5so1975905f8f.0
 for ; Fri, 16 May 2025 06:42:56 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442f8ab839esm68011645e9.17.2025.05.16.06.42.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 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" 
X-Inumbo-ID: ac924069-325b-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747402976; x=1748007776; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=yo12YD/EeNnxhz289hdmLpNy6oxcFoxCiS3jEAs1NK0=;
        b=IT0TMyaVSdwhzi/JRRwCQzL6MdQQh7HL3PBC3DF8n9GfFUaPl+apqeCCcQrq1f3FLg
         yHewglhblojt7xfb9ZD9tsfwzAFctMZ//RRdRRSIBCz1LSjCGGoVCeqRKZRYtYt5Jlrk
         ZAd0LpyvZYimoZNqeBHheGfWxTOWyEefk+twfElxFdXDEqhqimDjKGsrmDQFo1icfjas
         EXa9fKBZUSRcN5t9akXosfcCjyBp6C81HHyW5du6hVsU5HHD0BmjRCRKkaXn8MFdTcv2
         Y/RXXBFme5c48UlWkMGOxNmkJUSkNIXICCOFS6R4rsyaCYLNljnwJMkywH9vzQam2DUM
         zwUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747402976; x=1748007776;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=yo12YD/EeNnxhz289hdmLpNy6oxcFoxCiS3jEAs1NK0=;
        b=YDbVvOWLTqasiW9PpH8VfQsHXbikGg9QGtedrNWJew+vT3SoeJw8RW6TXE83ZRTXRz
         v5ytA63MoH8bS+paIKnRiq5VOnYMCOLte1NnCuSFxKQmhpNIduDT3rDooG+2867gwv0h
         +aFAWQdyx6YgGOLZl8+aEwATJF0MkeCGyaPFmmcDiMIvcw6W2063zgsMHc177R7DS3pa
         qtRQhIt7WZplayaqRCglSVGcUuY0nwx2nA7AbVXA0SfcvtMVijW6i1DkfrKF1DKvvViP
         62/4lXO4v1oI6AuKTxuyv9sRFAqlYjpokZ/gjLgbD0b3FRlz4bIUqb4H9W7ZyLPBTENK
         b3Lw==
X-Forwarded-Encrypted: i=1; AJvYcCVdA9t0FP41MM1519mH/6TH9h75jzOTAyhYmffJVOEW2mTAfH5q2+4RSB170qle9NVkMDf5qYhIN/A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwM2kvqECk4z67yjqUVXOlbcflzi2WpU+RKXt4h66jNiTQJ6BbK
	P8DsFfsakruQMEMV0Cyk9rL7GtxjTrHuPVDvW5qhUhkpsYqiIgBw2/9wdU6VIsYOCis=
X-Gm-Gg: ASbGncsak2k1WDJuW9/qY4VKAdwa86WWwCcFAGuZDcDkOyKuxsFQ3Zn54qEg6lgHATw
	ikBRJs/znti4U1WPk/ck7/bSqO4Y3PE4A1FD6RClPMe2gL1jFDTlBRhX2F22TRBFu1hd7tDHiS/
	nHhFf6AWUmkcmijUZ8XS0kHEgY74SxkGDeSt/QeQN26+jGMWwwDxcaS9pPcu0pEx0A/f/ff2SQa
	VjhQ0JMs24QGZnlkWzyqFLQQNBu87ikM20Q7TwPxQtmu/iRSg5OnvGkwPXRXoU3s0ztJE9+zxRg
	lMyTyoJivaQW5RKZujhlYiJxHblNZ/82+KCEiuJk/hSxe4JxtVCYd78M7JR3upfUynQxDaG2Qeg
	QKlAgV2beI33GgIMxwEj1cd3jVQnuYOSRqVidTQ5mdf9xmhjm/Rryh8p8XTFJPWeWGItxzVAF6u
	Yt
X-Google-Smtp-Source: AGHT+IGMcbLo75Lu+7Igu/BA62qo1z5kNbNummd8n2M2O9qqMvMW86VfecgeGjv0GPu5gqB62yvszg==
X-Received: by 2002:a5d:5f54:0:b0:3a3:64b9:2b87 with SMTP id ffacd0b85a97d-3a364b92c18mr151340f8f.8.1747402976122;
        Fri, 16 May 2025 06:42:56 -0700 (PDT)
Message-ID: 
Date: Fri, 16 May 2025 15:42:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] x86/xen/msr: Fix uninitialized symbol 'err'
To: Xin Li , Ingo Molnar 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
 dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
 peterz@infradead.org, boris.ostrovsky@oracle.com, rafael@kernel.org,
 lenb@kernel.org
References: <20250512084552.1586883-1-xin@zytor.com>
 <20250512084552.1586883-3-xin@zytor.com> 
 <30affad5-4f26-4e22-9d64-b8ece1199773@zytor.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: <30affad5-4f26-4e22-9d64-b8ece1199773@zytor.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------PgiYR0j8o8tgjsYaNHIycWKK"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------PgiYR0j8o8tgjsYaNHIycWKK
Content-Type: multipart/mixed; boundary="------------77fm8ZAPfoKwkw5C0Tyy8C7B";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Xin Li , Ingo Molnar 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
 dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
 peterz@infradead.org, boris.ostrovsky@oracle.com, rafael@kernel.org,
 lenb@kernel.org
Message-ID: 
Subject: Re: [PATCH v1 2/3] x86/xen/msr: Fix uninitialized symbol 'err'
References: <20250512084552.1586883-1-xin@zytor.com>
 <20250512084552.1586883-3-xin@zytor.com> 
 <30affad5-4f26-4e22-9d64-b8ece1199773@zytor.com>
In-Reply-To: <30affad5-4f26-4e22-9d64-b8ece1199773@zytor.com>

--------------77fm8ZAPfoKwkw5C0Tyy8C7B
Content-Type: multipart/mixed; boundary="------------DXvRsuOKe4mFw5cdW3f0xAAU"

--------------DXvRsuOKe4mFw5cdW3f0xAAU
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTUuMDUuMjUgMjA6MTEsIFhpbiBMaSB3cm90ZToNCj4gT24gNS8xNS8yMDI1IDg6Mjkg
QU0sIEluZ28gTW9sbmFyIHdyb3RlOg0KPj4NCj4+ICogWGluIExpIChJbnRlbCkgPHhpbkB6
eXRvci5jb20+IHdyb3RlOg0KPj4NCj4+PiB4ZW5fcmVhZF9tc3Jfc2FmZSgpIGN1cnJlbnRs
eSBwYXNzZXMgYW4gdW5pbml0aWFsaXplZCBhcmd1bWVudCBlcnIgdG8NCj4+PiB4ZW5fZG9f
cmVhZF9tc3IoKS7CoCBCdXQgYXMgeGVuX2RvX3JlYWRfbXNyKCkgbWF5IG5vdCBzZXQgdGhl
IGFyZ3VtZW50LA0KPj4+IHhlbl9yZWFkX21zcl9zYWZlKCkgY291bGQgcmV0dXJuIGVyciB3
aXRoIGFuIHVucHJlZGljdGFibGUgdmFsdWUuDQo+Pj4NCj4+PiBUbyBlbnN1cmUgY29ycmVj
dG5lc3MsIGluaXRpYWxpemUgZXJyIHRvIDAgKHJlcHJlc2VudGluZyBzdWNjZXNzKQ0KPj4+
IGluIHhlbl9yZWFkX21zcl9zYWZlKCkuDQo+Pj4NCj4+PiBCZWNhdXNlIHhlbl9yZWFkX21z
cl9zYWZlKCkgaXMgZXNzZW50aWFsbHkgYSB3cmFwcGVyIG9mIHhlbl9kb19yZWFkX21zcigp
LA0KPj4+IHRoZSBsYXR0ZXIgc2hvdWxkIGJlIHJlc3BvbnNpYmxlIGZvciBpbml0aWFsaXpp
bmcgdGhlIHZhbHVlIG9mICplcnIgdG8gMC4NCj4+PiBUaHVzIGluaXRpYWxpemUgKmVyciB0
byAwIGluIHhlbl9kb19yZWFkX21zcigpLg0KPj4+DQo+Pj4gRml4ZXM6IDUwMmFkNmU1YTYx
OSAoIng4Ni9tc3I6IENoYW5nZSB0aGUgZnVuY3Rpb24gdHlwZSBvZiANCj4+PiBuYXRpdmVf
cmVhZF9tc3Jfc2FmZSgpIikNCj4+PiBSZXBvcnRlZC1ieTogRGFuIENhcnBlbnRlciA8ZGFu
LmNhcnBlbnRlckBsaW5hcm8ub3JnPg0KPj4+IENsb3NlczogaHR0cHM6Ly9sb3JlLmtlcm5l
bC5vcmcveGVuLWRldmVsL2FCeE5JX1EwLU1odEJTWkdAc3RhbmxleS5tb3VudGFpbi8NCj4+
PiBTaWduZWQtb2ZmLWJ5OiBYaW4gTGkgKEludGVsKSA8eGluQHp5dG9yLmNvbT4NCj4+PiAt
LS0NCj4+PiDCoCBhcmNoL3g4Ni94ZW4vZW5saWdodGVuX3B2LmMgfCA1ICsrKystDQo+Pj4g
wqAgMSBmaWxlIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPj4+
DQo+Pj4gZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW5fcHYuYyBiL2FyY2gv
eDg2L3hlbi9lbmxpZ2h0ZW5fcHYuYw0KPj4+IGluZGV4IDNiZTM4MzUwZjA0NC4uMDFmMWQ0
NDEzNDdlIDEwMDY0NA0KPj4+IC0tLSBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW5fcHYuYw0K
Pj4+ICsrKyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW5fcHYuYw0KPj4+IEBAIC0xMDkxLDYg
KzEwOTEsOSBAQCBzdGF0aWMgdTY0IHhlbl9kb19yZWFkX21zcih1MzIgbXNyLCBpbnQgKmVy
cikNCj4+PiDCoCB7DQo+Pj4gwqDCoMKgwqDCoCB1NjQgdmFsID0gMDvCoMKgwqAgLyogQXZv
aWQgdW5pbml0aWFsaXplZCB2YWx1ZSBmb3Igc2FmZSB2YXJpYW50LiAqLw0KPj4+ICvCoMKg
wqAgaWYgKGVycikNCj4+PiArwqDCoMKgwqDCoMKgwqAgKmVyciA9IDA7DQo+Pj4gKw0KPj4+
IMKgwqDCoMKgwqAgaWYgKHBtdV9tc3JfY2hrX2VtdWxhdGVkKG1zciwgJnZhbCwgdHJ1ZSkp
DQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiB2YWw7DQo+Pj4gQEAgLTExNjIsNyAr
MTE2NSw3IEBAIHN0YXRpYyB2b2lkIHhlbl9kb193cml0ZV9tc3IodTMyIG1zciwgdTY0IHZh
bCwgaW50ICplcnIpDQo+Pj4gwqAgc3RhdGljIGludCB4ZW5fcmVhZF9tc3Jfc2FmZSh1MzIg
bXNyLCB1NjQgKnZhbCkNCj4+PiDCoCB7DQo+Pj4gLcKgwqDCoCBpbnQgZXJyOw0KPj4+ICvC
oMKgwqAgaW50IGVyciA9IDA7DQo+Pj4gwqDCoMKgwqDCoCAqdmFsID0geGVuX2RvX3JlYWRf
bXNyKG1zciwgJmVycik7DQo+Pj4gwqDCoMKgwqDCoCByZXR1cm4gZXJyOw0KPj4NCj4+IFNv
IHdoeSBub3QgaW5pdGlhbGl6ZSAnZXJyJyB3aXRoIDAgaW4gYm90aCBjYWxsZXJzLCB4ZW5f
cmVhZF9tc3Jfc2FmZSgpDQo+PiBhbmQgeGVuX3JlYWRfbXNyKCksIGFuZCBhdm9pZCBhbGwg
dGhlIGluaXRpYWxpemF0aW9uIHRyb3VibGUgaW4NCj4+IHhlbl9kb19yZWFkX21zcigpPw0K
PiANCj4gWWVhaCwgSSBzaG91bGQgbWFrZSB0aGUgY2hhbmdlIGluIHhlbl9yZWFkX21zcigp
IHRvby4NCj4gDQo+IEhvd2V2ZXIgeGVuX2RvX3JlYWRfbXNyKCkgc2hvdWxkIGJlIGltcGxl
bWVudGVkIGluIGEgZGVmZW5zaXZlIHdheSB0bw0KPiBzZXQgKmVyciBwcm9wZXJseSBhcyBp
dCdzIHBhcnQgb2YgaXRzIHJldHVybiB2YWx1ZS7CoCBBY3R1YWxseSBpdCB3YXMgc28sDQo+
IGJ1dCBvbmUgb2YgbXkgcHJldmlvdXMgY2xlYW51cCBwYXRjaCByZW1vdmVkIGl0IGJlY2F1
c2UgZXJyIGlzIG5vIGxvbmdlcg0KPiBwYXNzZWQgdG8gcG11X21zcl9jaGtfZW11bGF0ZWQo
KS4NCg0KeGVuX2RvX3JlYWRfbXNyKCkgaXMgdXNhYmxlIG9ubHkgaW4gZW5saWdodGVuX3B2
LmMgYXMgaXQgaXMgc3RhdGljLg0KDQpTbyBJJ2QgcHJlZmVyIHRvIGRyb3Agc2V0dGluZyBl
cnIgdG8gMCBpbiB4ZW5fZG9fcmVhZF9tc3IoKSBpbml0aWFsbHkNCmFuZCB0byBzZXQgZXJy
IHRvIDAgaW4gYWxsIGNhbGxlcnMuDQoNCg0KSnVlcmdlbg0K
--------------DXvRsuOKe4mFw5cdW3f0xAAU
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-----

--------------DXvRsuOKe4mFw5cdW3f0xAAU--

--------------77fm8ZAPfoKwkw5C0Tyy8C7B--

--------------PgiYR0j8o8tgjsYaNHIycWKK
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/Ey8FAmgnQN4FAwAAAAAACgkQsN6d1ii/Ey9l
lwf/Xk2T6T50jLesExpAbNXip6060sAMN1Mc1BYrkiVurjsNyS+Uwh6P0jqLiZHfkb2TSD+F0IyF
lfwz1sEUjaNAWM9qY0PiyIhTzdWWPRxWD5Ffl5hCuIHM/OvPo99OhATvJE9gAIWTX7SFc6XUvzLg
zh4WEAOg1mJmlnzOoM/u1/2ZUb7NvdX+IDlUZXxM+Ixv1pbuIFXTi8FQY5reGXKs15D/g1GgRZyV
IBqZeZwosjxNSFC+LVI0WoQ4npyKWGnHitExTb8uBKPimQ+oleF8gmhx7r7q2BsZtuAawZVwjISK
AKQRIdHkbZdv+ROvrq3Aq/lssd0ULRktdKLt6rzaAw==
=zWaj
-----END PGP SIGNATURE-----

--------------PgiYR0j8o8tgjsYaNHIycWKK--


From xen-devel-bounces@lists.xenproject.org Fri May 16 13:50:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 13:50:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987207.1372628 (Exim 4.92)
	(envelope-from )
	id 1uFvRq-0003Lt-Oe; Fri, 16 May 2025 13:50:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987207.1372628; Fri, 16 May 2025 13: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 1uFvRq-0003Kw-M0; Fri, 16 May 2025 13:50:02 +0000
Received: by outflank-mailman (input) for mailman id 987207;
 Fri, 16 May 2025 13:50:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFvRq-00038z-0J
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 13:50:02 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a70d0ba2-325c-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 15:49:57 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43edb40f357so16218255e9.0
 for ; Fri, 16 May 2025 06:49:57 -0700 (PDT)
Received: from [10.81.43.161] ([46.149.103.11])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442fd59708esm33712385e9.37.2025.05.16.06.49.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 06: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" 
X-Inumbo-ID: a70d0ba2-325c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747403396; x=1748008196; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+MX+fzdjUs9D4/4/T9ARROXh13vPdVxGuccJn5w560E=;
        b=Z5qtA+TxhO/ynYgUNtsYTarMPNXvfLb0TlVlRL5CkdUpAb7icanr5P31fGOKtOZ5n+
         9WhuSXIx8ZGL4dcByIKIEBZSKlC8Zhi1g3eKQxLdMcbUou58VqguYOpLoa+LHMFL82AI
         4uwe8amDvGunEya8kUtO3KampULwqnEh4kkW0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747403396; x=1748008196;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+MX+fzdjUs9D4/4/T9ARROXh13vPdVxGuccJn5w560E=;
        b=f30Eqn3vb5bM3kRS1vu82DPqZlWD1h/s9hQ1lTlCtYtsdesqaGKK1GHjipJDlypQOw
         hoy0zl18XSWRdvEMwUazR0ZvD3vaLwFKmD/SS7nMbyKuN03MAy7F/j+2qJn/GFP9yyNX
         ysHzshKPwFTVFjppQwe7RReCa0pYiVAcwaIWXO//eYt6qKntQiF6gP8X/n1JKQiRda05
         eqRcK0YuG0+kyh1/VhBQQCAqsRXB8rC0sv1nYi36q1TOW8HUkbU+mUllHcSlqIr6jzWl
         8YCJ0K/ROx8XGs3MQ6g6Q/lRZsAJu3/WNgb7tCjyoQgwzBcz9gUMo60VA4bJzlNdTqoQ
         Q9KQ==
X-Forwarded-Encrypted: i=1; AJvYcCUMV6seBXD6YIrd8cqDYYFW8vOnz+yD5/rMMhqzXmY4UH144BvZgR6f6yDP1BzWKot6s2OzPqlzoKQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxzwW2oUxuEayrTXhJJJnrRKa7XSCkWpoy4tLrA4K0oCkLsCj9H
	vJ5a7pVFZ7P29kh3c0oDeSIEufD0458tTI+YEmvnCrlQFr6vwsSuLzqbplEvCsQ0vnV15PsfQyE
	mrrav
X-Gm-Gg: ASbGncs2vET1ryBiWdF1tnxbSIYagtERC1IafA1OM+FykvfsBNkZWV6Z7yuespKc4Ez
	uRdqaP8pF0FlgYNnboZMCarBsr0v5VWcCoXt1uI0twkrrymZQN1FQ1GZg1bz5uH/Kc+Ysx2WKbA
	d6dcuRdgUnjLnKSGMywv5ScBJrmECL1mKbreUmVyNSkzR2aTm3D4Ae2wpYjuc7u6tZiFFH3vzRg
	rnlOS5xjchyzcsZF0F5gFEk+PDqKB0Ova+mM8IHQXgYiSUo4NMnLmBbwMxvu1tK2HdGSC0e13CG
	/PT9wmB4yOpyMS/gbQjnFEvYA7sXpDlCKMMaxYSdHtX84A1fwH2v3ZbNdXPl8w==
X-Google-Smtp-Source: AGHT+IG6HnffnaRlG9GJ0XVVSuHFndYGEOJL5hD82sgcTvrsyzn5v0YWU9F1hbk2mCo1lt/wET5yQw==
X-Received: by 2002:a05:600c:1c03:b0:442:c98e:79ab with SMTP id 5b1f17b1804b1-442fd626edcmr32932385e9.9.1747403396381;
        Fri, 16 May 2025 06:49:56 -0700 (PDT)
Message-ID: <87a0546d-d2e4-4042-b34a-e35e2605123b@citrix.com>
Date: Fri, 16 May 2025 14:49:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/stubs: Consolidate the stubs infrastructure in
 asm/stubs.h
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250516133326.49587-1-andrew.cooper3@citrix.com>
 <4a1a8582-7503-49ca-8d34-bce3e101734a@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: <4a1a8582-7503-49ca-8d34-bce3e101734a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16/05/2025 2:41 pm, Jan Beulich wrote:
> On 16.05.2025 15:33, Andrew Cooper wrote:
>> Very few files need the stubs.  Move the infrastructure out of
>> processor.h and config.h into a new stubs.h, and adjust the includes
>> accordingly.
>>
>> Make the per-cpu struct stubs be read mostly; they're unmodified
>> during the uptime of the CPU, and move them into smpboot.c seeing as
>> that's where they're allocated and freed.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper 
> Acked-by: Jan Beulich 

Thanks.

> with one possible suggestion:
>
>> --- /dev/null
>> +++ b/xen/arch/x86/include/asm/stubs.h
>> @@ -0,0 +1,37 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef X86_ASM_STUBS_H
>> +#define X86_ASM_STUBS_H
>> +
>> +/*
>> + * Xen has several per-cpu executable stubs which are written dynamically.
> This puts it pretty well. Yet in principle there may be further, perhaps
> entirely different stubs in the future. Hence stubs.h feels a little
> generic. What about exec-stubs.h?

stubs is quite generic; in fact, that was my feedback for struct stubs.

There is something to be said for the header file to be the same as the
struct you want from it.

What did you have in mind for "different stubs"?  The only thing that
makes these special (i.e. not regular per-cpu data) is that we need an
executable mapping of them.  So, while I think it's reasonably likely
that we'll gain other uses (although, we're losing LSTAR/CSTAR when FRED
is enabled), I'm less certain what non-executable stubs would look like.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 16 13:50:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 13:50:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987211.1372639 (Exim 4.92)
	(envelope-from )
	id 1uFvSI-0004U7-46; Fri, 16 May 2025 13:50:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987211.1372639; Fri, 16 May 2025 13:50: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 1uFvSI-0004U0-1R; Fri, 16 May 2025 13:50:30 +0000
Received: by outflank-mailman (input) for mailman id 987211;
 Fri, 16 May 2025 13:50:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFvSG-00038z-E2
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 13:50:28 +0000
Received: from mail187-4.suw11.mandrillapp.com
 (mail187-4.suw11.mandrillapp.com [198.2.187.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b84f5bb7-325c-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 15:50:26 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-4.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4ZzT411FvrzlfcPK
 for ; Fri, 16 May 2025 13:50:25 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 34bc3b81b0104c4881c63d7a997c5f59; Fri, 16 May 2025 13:50: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" 
X-Inumbo-ID: b84f5bb7-325c-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747403425; x=1747673425;
	bh=Pb2Nd/Hl+Fu+r4N2HLILmZb2CYCIP0DxQZNBb842Blg=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=sQbVtfkdJPS/wZNJGnvj39DQP0TjnFsJlZh5l+zhjNRoY6zVkTd9vJvCYUtZ3Shag
	 qYGG2fT8+s001qA+ibglYMQqR57MxXlGP1S7u0owGn+f6QEWje1QrLXxlFoioRkAWr
	 m/GgWu+LKjvSJSsjuWEx/z3AbDHIaruMCZ2G1ng+9fJUUrG00Lf1vuYGDuUTBofPCf
	 0U5vOHp6aRYsnAZzdH47/zn5tiJXnA3REfWGSanVLLw1EgjakxeuokIySS31Uo3dMR
	 f8YaQAbGchhmdvfvQUZgNnG1oUeFlO+gopqc6w4NyhnuuRK0I7EWbS1nfVtgtz3xZS
	 fqFV0Qzwp/1FQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747403425; x=1747663925; i=teddy.astie@vates.tech;
	bh=Pb2Nd/Hl+Fu+r4N2HLILmZb2CYCIP0DxQZNBb842Blg=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=F+VbRV+fHqM4e8/X5pOt5MzqiyqyVqSTVwiVTFROhsiIHmxLb2jT7/rFm7yZs3OTR
	 wo/j1/nwSr+WxraFpmwzmOJaVSR/l2Y2c65HXwDFEq1k0cL5Xb6rx5sBt00AkCf/2n
	 /aipzOTyuN5J2L0XEq7ayYROeKpzgtjGO2MNk8x+cYCRGcCiE4xrkno2zeRwC3ZTqg
	 KpMbuyZLKjmDgsCCcZw+VB9+1/kCnAns5NuVfsXmjdqoos7XKgNmkIgg712dKOiogN
	 AKmt6D1kQ9MD+/Z3O9btVVikizKq3X5QNwyHpYG9zBLsN2HLcEU/WabMZZLSLjCPjT
	 i7NgKbMdp6ipw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[RFC=20PATCH]=20xen:=20Introduce=20extra=20IRQ=20count=20domain=20creation=20parameter?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747403424440
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" 
Message-Id: <9a746a8b2e9ee68a398795ecb5dcb53697aeece4.1747403245.git.teddy.astie@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.34bc3b81b0104c4881c63d7a997c5f59?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250516:md
Date: Fri, 16 May 2025 13:50:25 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

When doing PCI Passthrough with high-IRQ devices (e.g NVMe drives),
the default limit may be unefficient as not all domains requires
more IRQs.

Introduce a new parameter to allow the toolstack to tune the IRQ
count if more is required.

Signed-off-by: Teddy Astie 
---
0 extra_irqs is meaningful, though I am not sure how to expose this
special case.

This of course wants libxl support next.
---
 xen/common/domain.c         | 8 +++++---
 xen/include/public/domctl.h | 3 +++
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..5c628962fc 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -912,10 +912,12 @@ struct domain *domain_create(domid_t domid,
 
 #ifdef CONFIG_HAS_PIRQ
     if ( !is_hardware_domain(d) )
-        d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
+        d->nr_pirqs = nr_static_irqs + config->extra_irqs ?: extra_domU_irqs;
     else
-        d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs
-                                       : arch_hwdom_irqs(d);
+    {
+        unsigned int extra_irqs = config->extra_irqs ?: extra_hwdom_irqs;
+        d->nr_pirqs = extra_irqs ? nr_static_irqs + extra_irqs : arch_hwdom_irqs(d);
+    }
     d->nr_pirqs = min(d->nr_pirqs, nr_irqs);
 
     radix_tree_init(&d->pirq_tree);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5b2063eed9..e4bb366c78 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -121,6 +121,9 @@ struct xen_domctl_createdomain {
     /* CPU pool to use; specify 0 or a specific existing pool */
     uint32_t cpupool_id;
 
+    /* Additional IRQ for this guest. 0 to use Xen default value. */
+    uint32_t extra_irqs;
+
     struct xen_arch_domainconfig arch;
 };
 
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 16 14:04:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 14:04:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987239.1372649 (Exim 4.92)
	(envelope-from )
	id 1uFvfV-000703-7B; Fri, 16 May 2025 14:04:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987239.1372649; Fri, 16 May 2025 14:04:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uFvfV-0006zw-4R; Fri, 16 May 2025 14:04:09 +0000
Received: by outflank-mailman (input) for mailman id 987239;
 Fri, 16 May 2025 14:04:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFvfT-0006zn-EU
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 14:04:07 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a1222eda-325e-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 16:04:06 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a36463b9cbso133175f8f.2
 for ; Fri, 16 May 2025 07:04:06 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442f482f1d6sm100456375e9.14.2025.05.16.07.04.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 07:04: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" 
X-Inumbo-ID: a1222eda-325e-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747404245; x=1748009045; darn=lists.xenproject.org;
        h=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;
        bh=/edY+Zskoh0wrOH6vmFE+9XhkCbiUGh0UQtxuebu1lo=;
        b=cXCivGgBnOxboVq0nT8lUUE2S6bKblMHfTit2UwUATO+4f8XraY44Wz3hTqUe8tI1/
         H/PXb9THauW9coSy1ljbTGra8/ipx4UPtpPlJhBW4hKi0VquficgOUTq2J9gDIlikCVg
         3wjXBD6ezyGBJRXqzjLLpitsvvG6+R+0sNGWW5Gpi69f76cPG3vNsz5nU0qUfDdZSVcw
         PPkPa3KXdt1mXddzDwXUa4/P941UDFPAjbANnul/uF+rYTuQe+mKpYv2yhMA8fwMW2PV
         s2z0PsIpGwy+29c1Zy7l3mK60viGr3B/+0gBU+zzNluVJMDwrZ+kUgk7xTIy8iPqljgM
         +toA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747404245; x=1748009045;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=/edY+Zskoh0wrOH6vmFE+9XhkCbiUGh0UQtxuebu1lo=;
        b=WPR3mJHW39pavL3kP+1l94EirxMjLLGaHnCUrtVJR3UGLxkcHH7iR8WfKLwB/sfppp
         OfjpuTdKY94El23lqtLgCsbp2NMTmOwLrClPn92isA5nPpUGqOQwE7J4GOs8xoRvELur
         qDttRyKgykRDNWtyxUq1+X3Zl2Aw3RsdFdKiGOg9On520r12vrP1uDAqgT2QyOCiYONy
         LYe4QAuuSm89O6fWeNYiW4JV2PRTjxTGx2HyG80Uq5+GxAu50myZFd4BTH1aUKWqUt5x
         RUkWxLOwl3J9/0MRZ/HqoNS97LeOjCaAMEbIIsSWbvSmkT0H4ch2+DGSCiAeIBT0nWg/
         1ktg==
X-Forwarded-Encrypted: i=1; AJvYcCXRfreujrRVE+AY+50eijITsQUQtJHeveL0FxNR0d2p7eWOtm6bYukfgRVSgf7oB2tZBC9j8EpLu5k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzFk2DoHJuAqwTLetZmjHXqlqNF7QmLUbdyX5rp4sAD/xpYbdX8
	L4Gju2vYoOk4IemJG0YfuAxNSzY4hTR9pwNdCvgdq8n2L2GLLQvtDGUK
X-Gm-Gg: ASbGncttzv/v52p8UVkBy6P1UmSQfbgrmDCabEQ6mO9YNFVZyODvheNLJac/BJI5AWt
	in5q+Etc+MRxlyBM57VRJw55cb0857HB3s2U67KGW3nTR+Znsih3kJRqWGd3NUmwxTs+u58uU+2
	/JS87ChIMdZPpc0JHSocXFzRvXwoftQcnhfW5+yjHxCsICKR/CWrxTU9xge8r2JyhiwHWmENeqv
	9HoqlqF55j7xFoG3oasQBkKfGQfludr9ZBy125jywuHvQMPOXzs61j8huHrDQWfIBf4EFC4gGD4
	SVIztBjeC9Uxt8Edas8ZyN8zDKiCC8/pjXozm800DV7kPGjcvnegrfvU4CfW67NYQub9HaKOKNS
	obrvRWTUeV1mmuTV97SCsLlpZ
X-Google-Smtp-Source: AGHT+IGF2wSQmYpEBCL/akwVepdZjGoqTRKqOSNhvf4mx6gUMtkVlD2C4NLQy3ui62kqlWC5nwUmQw==
X-Received: by 2002:a5d:5849:0:b0:3a1:f654:b84e with SMTP id ffacd0b85a97d-3a35c845c23mr3619414f8f.55.1747404245089;
        Fri, 16 May 2025 07:04:05 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------now59vvmZaF6uxg1wijNK0zA"
Message-ID: 
Date: Fri, 16 May 2025 16:04:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/16] xen/riscv: introduce platform_get_irq()
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------now59vvmZaF6uxg1wijNK0zA
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/15/25 9:33 AM, Jan Beulich wrote:
>> +int platform_get_irq(const struct dt_device_node *device, int index)
>> +{
>> +    struct dt_irq dt_irq;
>> +    int ret;
>> +
>> +    if ( (ret = dt_device_get_irq(device, index, &dt_irq)) != 0 )
>> +        return ret;
>> +
>> +    if ( (ret = irq_set_type(dt_irq.irq, dt_irq.type)) != 0 )
>> +        return ret;
>> +
>> +    return dt_irq.irq;
> What guarantees the value to be at most INT_MAX (i.e. no silent conversion to
> a negative value, signaling an error to the caller)? Actually, looking at
> irq_set_type(), what guarantees irq_to_desc() there to not overrun irq_desc[]?
> There are no bounds checks in aplic_irq_xlate().

I'm afraid that both aren't guaranteed. I think to have the following in platform_get_irq()
should be enough:
     BUILD_BUG_ON(NR_IRQS > INT_MAX);

     if ( dt_irq.irq >= NR_IRQS )
         panic("irq%d is bigger then NR_IRQS(%d)\n", dt_irq.irq, NR_IRQS);

Probably, the first could be dropped as I'm not sure that anyone will use such big
number for NR_IRQS.

~ Oleksii


--------------now59vvmZaF6uxg1wijNK0zA
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 9:33 AM, Jan Beulich wrote:
    
    
    
    
    
      
    +int platform_get_irq(const struct dt_device_node *device, int index)
+{
+    struct dt_irq dt_irq;
+    int ret;
+
+    if ( (ret = dt_device_get_irq(device, index, &dt_irq)) != 0 )
+        return ret;
+
+    if ( (ret = irq_set_type(dt_irq.irq, dt_irq.type)) != 0 )
+        return ret;
+
+    return dt_irq.irq;

    What guarantees the value to be at most INT_MAX (i.e. no silent conversion to
a negative value, signaling an error to the caller)? Actually, looking at
irq_set_type(), what guarantees irq_to_desc() there to not overrun irq_desc[]?
There are no bounds checks in aplic_irq_xlate().
    
    
    
    
    I'm afraid that both aren't guaranteed. I think to have the following in platform_get_irq()
should be enough:
    BUILD_BUG_ON(NR_IRQS > INT_MAX);

    if ( dt_irq.irq >= NR_IRQS )
        panic("irq%d is bigger then NR_IRQS(%d)\n", dt_irq.irq, NR_IRQS);

Probably, the first could be dropped as I'm not sure that anyone will use such big
number for NR_IRQS.

~ Oleksii



    
  


--------------now59vvmZaF6uxg1wijNK0zA--


From xen-devel-bounces@lists.xenproject.org Fri May 16 14:20:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 14:20:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987247.1372658 (Exim 4.92)
	(envelope-from )
	id 1uFvvT-0001NZ-Gz; Fri, 16 May 2025 14:20:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987247.1372658; Fri, 16 May 2025 14:20: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 1uFvvT-0001NS-Dv; Fri, 16 May 2025 14:20:39 +0000
Received: by outflank-mailman (input) for mailman id 987247;
 Fri, 16 May 2025 14:20:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFvvS-0001NM-A5
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 14:20:38 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id efcca057-3260-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 16:20:37 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a363d15c64so230155f8f.3
 for ; Fri, 16 May 2025 07:20:37 -0700 (PDT)
Received: from andrew-laptop.. ([46.149.103.10])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca5a04csm2938274f8f.23.2025.05.16.07.20.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 16 May 2025 07:20: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" 
X-Inumbo-ID: efcca057-3260-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747405236; x=1748010036; 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;
        bh=9AXw0RKJ1u/9DoUFHhT/Kra6yYROZo8iN46o0ZEu/z0=;
        b=bhApMIk//9gppn2sSJ+2deHOlErLq0htF/d0gv4MoUKVPvljs1owYjCxNKgLG0WraI
         dstraxpYqtb772u/9Gg1gxvTZ1DUe1BU0l3vw/+OHe0ZvF9vUU8DdCAtMQYbucyMMmTK
         sBfsZicLGu9UtVmiiVmx52z7AvgVpr/rcCEiw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747405236; x=1748010036;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=9AXw0RKJ1u/9DoUFHhT/Kra6yYROZo8iN46o0ZEu/z0=;
        b=gwidjAXf0XK0/QZUIaUZWTrwNMl07o/2we0uNPn1G9BPRXidC8lLBFb+YUjXY9e1gm
         FQKCUCybV6V006nr/Wyn/IUhoPlcIrVwY2hXETTSfK5+7x5FnaraPE1tK//qj+KpSikb
         +otLux1b0XzU8P/7Jj4tVscQF5oK+UvQ52lU/AgR2F/oBD5Cg7nFg8HmmSYg2N2+4tQD
         NF14/mONfrXwTCszuHzcppoqV7jVZu3L4DvcS+sBwNuj9y+qyETbo9hgxvCAiDL96H8r
         Ke9JASJEwZsedqSn4YzmVW8b/qfPasyE2ntFlqGrOgyDel598XSDL7qBEO4cPgsDwY/B
         82lw==
X-Gm-Message-State: AOJu0Ywl4urC4pZe3UVddw5KVz7rb1rE7fYru7WZjsvj+tNnSqzVO52c
	8cKszq9E6FYr9hjt/xQvJfrTBSvkn3YDMAvT+bdAHK+LDSkbIpUECpkUK7r8V8JNRP/MIu+5O3k
	ZHJhs
X-Gm-Gg: ASbGncux1uKsUZevY/Q56L082HHJffxP+h+qZOgPqXUfDM4X/EHeiOXXjwu7kjSEGm6
	qvXTkZkcrR6vxAcXSN6j1ecshE63xPspG9Ejkw2ewl3n38V8c4NKihWyhtzm7Wbbhip++fX659N
	Ekpag/8jOvFWDqXY+zUGhcbFErRNrwt8GruzW77iocQYXORJZ++BURp8QE546cVEbrs0a9MKdIc
	h0wbtyOntof6U8ZbhybolUfwQH79EjfGKWx6/V8An+0MuOAL1ejhSisPdSkXwdc9hrcCoxghRaR
	l3EpL5YbBZLjoU+6jrCnknl6z1ZxqIPF9XzSKADfvIh1lzlyLiwLfOj5SpgF1IE=
X-Google-Smtp-Source: AGHT+IEmf57B7rUn7ctquoKcCyMZQ/BuWf6Oj0WZzw1I62ESaI/EP7aa9S4jfbnOZudKM/G7E7mZgw==
X-Received: by 2002:a05:6000:2ce:b0:3a0:8c45:d30e with SMTP id ffacd0b85a97d-3a35c82ec75mr4033116f8f.35.1747405236320;
        Fri, 16 May 2025 07:20:36 -0700 (PDT)
From: Andrew Cooper 
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] CODING_STYLE: Updated header guard recommendations
Date: Fri, 16 May 2025 15:20:31 +0100
Message-Id: <20250516142031.58693-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Despite the best intentions at the time, the current recommendation
lead to very long identifiers, bordering on the max limit we've chosen
for certification.

One observation is that we do have static analysis which will
highlight if duplicate guards are created accidentally.

Therefore, relax the recommendations and in particular remove the
specific tie to the directory structure.  This has the other advantage
of being more similar to other projects.

This will hopefully mean there's less churn getting the tree in shape,
and a random contributor is more likely to pick an appropriate guard
given no specific knowledge of Xen.

As always, it's something reviewers and maintainers should be aware
of, and to advise on.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
---
 CODING_STYLE | 49 ++++++++++++++++++-------------------------------
 1 file changed, 18 insertions(+), 31 deletions(-)

diff --git a/CODING_STYLE b/CODING_STYLE
index e3b1da604802..5644f1697fc7 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -157,43 +157,30 @@ Header inclusion guards
 -----------------------
 
 Unless otherwise specified, all header files should include proper
-guards to prevent multiple inclusions. The following naming conventions
-apply:
-
-- Guard names are derived from directory path underneath xen/ and the
-  actual file name.  Path components are separated by double
-  underscores.  Alphabetic characters are converted to upper case.  Non-
-  alphanumeric characters are replaced by single underscores.
-- Certain directory components are omitted, to keep identifier length
-  bounded:
-  - the top level include/,
-  - architecture-specific private files' arch/,
-  - any architecture's arch//include/asm/ collapses to
-    ASM____.
+guards to prevent multiple inclusions.  Guards need to be unique, and
+this property is checked by static analysis.
 
-For example:
+Guards should be chosen based on the logical area, with enough
+disambiguation when the same filename exits in multiple locations in
+the source tree.  Commonly there should be a XEN or  prefix.
+The guard should be spelt in ALL CAPITALS, ending with _H.
 
-- Xen headers: XEN___H
-  - include/xen/something.h -> XEN__SOMETHING_H
+For example:
 
-- asm-generic headers: ASM_GENERIC___H
-  - include/asm-generic/something.h -> ASM_GENERIC__SOMETHING_H
+- Xen headers: XEN__H
+  - include/xen/something.h -> XEN_SOMETHING_H
 
-- arch-specific headers: ASM_______H
-  - arch/x86/include/asm/something.h -> ASM__X86__SOMETHING_H
+- arch-specific headers: __H
+  - arch/x86/include/asm/something.h -> X86_SOMETHING_H
+  - arch/x86/include/asm/hvm/something.h -> X86_HVM_SOMETHING_H
+  - arch/x86/include/asm/pv/something.h -> X86_PV_SOMETHING_H
 
-- Private headers: ___H
-  - arch/arm/arm64/lib/something.h -> ARM__ARM64__LIB__SOMETHING_H
-  - arch/x86/lib/something.h -> X86__LIB__SOMETHING_H
-  - common/something.h -> COMMON__SOMETHING_H
+- Private headers: _PRIVATE_H
+  - common/something/private.h -> _PRIVATE_H
+  - drivers/foo/something.h -> _H
 
-Note that this requires some discipline on the naming of future new
-sub-directories: There shouldn't be any other asm/ one anywhere, for
-example.  Nor should any new ports be named the same as top-level
-(within xen/) directories.  Which may in turn require some care if any
-new top-level directories were to be added.  Rule of thumb: Whenever
-adding a new subdirectory, check the rules to prevent any potential
-collisions.
+A good choice of guard is one that wont become stale if the
+driver/subsystem/etc is shuffled around the source tree.
 
 Emacs local variables
 ---------------------
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 16:03:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 16:03:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987310.1372669 (Exim 4.92)
	(envelope-from )
	id 1uFxWU-0005so-JS; Fri, 16 May 2025 16:02:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987310.1372669; Fri, 16 May 2025 16:02: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 1uFxWU-0005sh-Gr; Fri, 16 May 2025 16:02:58 +0000
Received: by outflank-mailman (input) for mailman id 987310;
 Fri, 16 May 2025 16:02:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uFxWT-0005sb-6m
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 16:02:57 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3abaa500-326f-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 18:02:55 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad53cd163d9so115465166b.0
 for ; Fri, 16 May 2025 09:02:55 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d06eab7sm179338866b.58.2025.05.16.09.02.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 09:02: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" 
X-Inumbo-ID: 3abaa500-326f-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747411375; x=1748016175; darn=lists.xenproject.org;
        h=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;
        bh=uUienFC1r/f0w7zuWvbx5XKWZ6H0hs1mvolVLxJVeAQ=;
        b=NPQhqou31oN2FBLVi+S+oYmgn/CArgxKOzPpqV4Agmevu0lIlez2jvArfhcmHb/PzJ
         Zzvjf1SdqeVNVQjoaKNvFSYx4nqWKWgMbjCRAGhKYg9evyk9LmB/O5yg8pI2C3BaCmWF
         25AGsQkBsVP1WLxjcmapjRXT64Y981LYG75B25qYJlRMpnxIP8E0I1cosjAC2hQNHED+
         gNwkgwWjWCubpGobTd4vH/UvzXdWtpqGnSkH9UvYDyUvNuA+nKf1yOBtN5+dqg2VBzDr
         AwzVD3AiUYTRu+mT3tPMdNwQiHBNrrYRcDg7O7fFvWb75nUzH/pRtHy6woxIR1jOGv5T
         GQBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747411375; x=1748016175;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=uUienFC1r/f0w7zuWvbx5XKWZ6H0hs1mvolVLxJVeAQ=;
        b=ByzmwgUStP0GTcOQFu3BMFx48ajcv/yNGvRsiChduPLofbqTvyXFdp75dBdxrvmzyM
         t3Na11Wsp6q4VOcAGCBFpRsFAV7pOOKSieOWo/g8lXTCLJVTPLY9A/cKgV8d+uSdEp1P
         QtDLLxl0R9/WnhW5g69F1WqDLpvSm+uGR6a9E5plmxq19AdKOwmnQs4TfKK0HEDBSLtY
         9F0vhNix+ohdVdepsmJ+WWWzG56gc98iSMLJqyOiulJDryatwDYaDLFP2CSqbcOvl0cv
         GIw9mIDNgNs+OQ829/qGw0X7SFE4mP2abi/4VdVwlOjOvCSZuK0qq9qLInfQdWGUZyDj
         6K5g==
X-Forwarded-Encrypted: i=1; AJvYcCXQ4ljvbnYAjj5hOEbzooBY3Dl8zTuIk/NWoyzifDTFMSWbbE3I2GCnW9JLL3v35fAuHno31x6zjys=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzQKQKnMyk/b6uzYC7NuPp46kOQXVW8KWj/nOLpW0GM7QoT51rv
	QIPDW2uBZ0Nuz56zPPFzwl9bh4K2LncA+e+CCHXuKRmeVh2B7keFN4R9
X-Gm-Gg: ASbGnctWQrc+fMETX9bDq/xtgksvss5A3iLCKp5iAWqAj17i3/aDvlYupftIpGuiUpR
	n4g1GwN55Xnl0lGnbz0+EeluRBgOo0o35jYc0j6GzXoN77NMHrebsZxjltETpcWnvwtzdDfv+Aa
	sAn/U/cxl84nTkMb5swR93H1HXO7Q5TpMTpNcT5xh8Nc12Pgx7Xy6fov1y1LmlPv+51GVK45yu9
	r6JzBNsvfBs827Ti2SYhHG/wV4jDPfK5OkL3Qr33KZtV455bdBEjGzwL8ujyB4jZ2E1j+QCCdb5
	RGprxpZJ+tErkhCAM3D/zgrrwLYUsoNSfgqUSOdplJgAYcyYLBPCPZkVTjctEOMk5REty8Rf8q9
	58ksPoQq/DNyI5h82DU2iba1p
X-Google-Smtp-Source: AGHT+IE31Ett3nQY3Zb7F7GgMnYvREyt0TDVjv8zPe1VFs8CW5BVxlhA8uoru0RhM2HlgjvSSU2fFQ==
X-Received: by 2002:a17:907:7f20:b0:ad2:1f65:8569 with SMTP id a640c23a62f3a-ad52d4cac82mr385029766b.28.1747411374346;
        Fri, 16 May 2025 09:02:54 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------s5zO9QC0mthSFHmFvQACGQQ9"
Message-ID: <125e918d-7c0f-43dd-8ab9-c0e0bcbf640e@gmail.com>
Date: Fri, 16 May 2025 18:02:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/16] xen/riscv: dt_processor_cpuid() implementation
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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,
 Bertrand Marquis 
References: 
 <4e4b3a018e8dacbe85cc080d9209e2ba3cdf4330.1746530883.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------s5zO9QC0mthSFHmFvQACGQQ9
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/15/25 9:56 AM, Jan Beulich wrote:
> (adding Bertrand as the one further DT maintainer, for a respective question
> below)
>
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> Implements dt_processor_hartid()
> There's no such function (anymore).
>
>> to get the hart ID of the given
>> device tree node and do some checks if CPU is available and given device
>> tree node has proper riscv,isa property.
>>
>> As a helper function dt_get_cpuid() is introduced to deal specifically
>> with reg propery of a CPU device node.
>>
>> Signed-off-by: Oleksii Kurochko
>> ---
>> Changes in V2:
>>   - s/of_get_cpu_hwid()/dt_get_cpu_id().
>>   - Update prototype of dt_get_cpu_hwid(), use pointer-to-const for cpun arg.
>>   - Add empty line before last return in dt_get_cpu_hwid().
>>   - s/riscv_of_processor_hartid/dt_processor_cpuid().
>>   - Use pointer-to_const for node argument of dt_processor_cpuid().
>>   - Use for hart_id unsigned long type as according to the spec for RV128
>>     mhartid register will be 128 bit long.
>>   - Update commit message and subject.
>>   - use 'CPU' instead of 'HART'.
> Was this is good move? What is returned ...
>
>> --- a/xen/arch/riscv/include/asm/smp.h
>> +++ b/xen/arch/riscv/include/asm/smp.h
>> @@ -26,6 +26,9 @@ static inline void set_cpuid_to_hartid(unsigned long cpuid,
>>   
>>   void setup_tp(unsigned int cpuid);
>>   
>> +struct dt_device_node;
>> +int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid);
> ... here isn't a number in Xen's CPU numbering space. From earlier discussions I'm
> not sure it's a hart ID either, so it may need further clarification (and I'd
> expect RISC-V to have suitable terminology to tell apart the different entities).

 From device tree point of view (https://www.kernel.org/doc/Documentation/devicetree/bindings/riscv/cpus.txt)
it is just hart which is defined as a hardware execution context, which contains all the state mandated by
the RISC-V ISA: a PC and some registers.
And also based on this for DT binding:
   For example, my Intel laptop is
   described as having one socket with two cores, each of which has two hyper
   threads.  Therefore this system has four harts.
They are using just harts and in DT it will look like 4 node with a number in reg property which they
call hart. So from DT point of view hartid is pretty fine to use.

 From specification point of view (https://riscv.github.io/riscv-isa-manual/snapshot/unprivileged/#_risc_v_hardware_platform_terminology):
   A RISC-V hardware platform can contain one or more RISC-V-compatible processing cores together
   with other non-RISC-V-compatible cores, fixed-function accelerators, various physical memory
   structures, I/O devices, and an interconnect structure to allow the components to communicate.

   A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-
   compatible core might support multiple RISC-V-compatible hardware threads, or harts, through
   multithreading.
and (https://riscv.github.io/riscv-isa-manual/snapshot/unprivileged/#_risc_v_software_execution_environments_and_harts):
   From the perspective of software running in a given execution environment, a hart is a resource that
   autonomously fetches and executes RISC-V instructions within that execution environment. In this
   respect, a hart behaves like a hardware thread resource even if time-multiplexed onto real hardware by
   the execution environment. Some EEIs support the creation and destruction of additional harts, for
   example, via environment calls to fork new harts.

DT's CPU node should be refer to core plus hardware thread (or threads in case of multithreading)
in reg property to be close to the spec(?) but basically in DT they IMO just describe what in the sepc
is called an independent instruction fetch unit.

I still think that it is fine just to use hart_id. If to be close more to a spec the unit_id(?)
but it is more confusing IMO with what is use in RISC-V's DT binding.

>
>> @@ -10,3 +13,66 @@ void __init smp_prepare_boot_cpu(void)
>>       cpumask_set_cpu(0, &cpu_possible_map);
>>       cpumask_set_cpu(0, &cpu_online_map);
>>   }
>> +
>> +/**
>> + * dt_get_cpuid - Get the cpuid from a CPU device node
>> + *
>> + * @cpun: CPU number(logical index) for which device node is required
>> + *
>> + * Return: The cpuid for the CPU node or ~0ULL if not found.
>> + */
>> +static unsigned long dt_get_cpuid(const struct dt_device_node *cpun)
>> +{
>> +    const __be32 *cell;
>> +    int ac;
> This is bogus (should be unsigned int afaict), but dictated by ...
>
>> +    uint32_t len;
>> +
>> +    ac = dt_n_addr_cells(cpun);
> ... the return value here and ...
>
>> +    cell = dt_get_property(cpun, "reg", &len);
>> +    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
>> +        return ~0ULL;
> (Nit: This doesn't match the return type of the function; same for
> the function comment. Also, what if sizeof(*cell) * ac < len?)
>
>> +    return dt_read_number(cell, ac);
> ... the function parameter type here.

I think that we can declare ac as unsigned int even dt_n_addr_cells
return int as basically it returns be32_to_cpu(*ip) which return unsigned
int and it isn't expected to be a big value so overflow of INT_MAX shouldn't
happen and it won't affect a size argument of dt_read_number().

> In fact, that function is raising
> another question: If the "size" argument is outside of [0, 2], the value
> returned is silently truncated.

Usually address-cells is 1 or 2, so it isn't expected to be higher (but DT tells
that the value is u32 so it could be higher then 2). And I think it could be also
explained by bitness of an architecture.
I think I see address-cells equal to 3 for something connected to PCI, but
probably another one functions should be used to read.

>
> More generally - are there any plans to make DT code signed-ness-correct?
>
>> +/*
>> + * Returns the cpuid of the given device tree node, or -ENODEV if the node
>> + * isn't an enabled and valid RISC-V hart node.
>> + */
>> +int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
>> +{
>> +    const char *isa;
>> +
>> +    if ( !dt_device_is_compatible(node, "riscv") )
>> +    {
>> +        printk("Found incompatible CPU\n");
>> +        return -ENODEV;
>> +    }
>> +
>> +    *cpuid = dt_get_cpuid(node);
>> +    if ( *cpuid == ~0UL )
>> +    {
>> +        printk("Found CPU without CPU ID\n");
>> +        return -ENODEV;
>> +    }
>> +
>> +    if ( !dt_device_is_available(node))
>> +    {
>> +        printk("CPU with cpuid=%lu is not available\n", *cpuid);
>> +        return -ENODEV;
>> +    }
>> +
>> +    if ( dt_property_read_string(node, "riscv,isa", &isa) )
>> +    {
>> +        printk("CPU with cpuid=%lu has no \"riscv,isa\" property\n", *cpuid);
>> +        return -ENODEV;
>> +    }
>> +
>> +    if ( isa[0] != 'r' || isa[1] != 'v' )
>> +    {
>> +        printk("CPU with cpuid=%lu has an invalid ISA of \"%s\"\n", *cpuid, isa);
>> +        return -ENODEV;
>> +    }
>> +
>> +    return 0;
>> +}
> I view it as unhelpful that all errors result in -ENODEV. Yes, there are log
> messages for all of the cases, but surely there are errno values better
> representing the individual failure reasons?

I will update that to:

@@ -46,6 +46,7 @@ static unsigned long dt_get_cpuid(const struct dt_device_node *cpun)
  int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
  {
      const char *isa;
+    int ret;
  
      if ( !dt_device_is_compatible(node, "riscv") )
      {
@@ -57,7 +58,7 @@ int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
      if ( *cpuid == ~0UL )
      {
          printk("Found CPU without CPU ID\n");
-        return -ENODEV;
+        return -EINVAL;
      }
  
      if ( !dt_device_is_available(node))
@@ -66,16 +67,16 @@ int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
          return -ENODEV;
      }
  
-    if ( dt_property_read_string(node, "riscv,isa", &isa) )
+    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
      {
          printk("CPU with cpuid=%lu has no \"riscv,isa\" property\n", *cpuid);
-        return -ENODEV;
+        return ret;
      }
  
      if ( isa[0] != 'r' || isa[1] != 'v' )
      {
          printk("CPU with cpuid=%lu has an invalid ISA of \"%s\"\n", *cpuid, isa);
-        return -ENODEV;
+        return -EINVAL;
      }
  
      return 0;

I think it's better now.

Thanks.

~ Oleksii

--------------s5zO9QC0mthSFHmFvQACGQQ9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 9:56 AM, Jan Beulich wrote:
    
    
    
    
    
      
    (adding Bertrand as the one further DT maintainer, for a respective question
below)

On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    Implements dt_processor_hartid()

    
      
    
      
    There's no such function (anymore).


    
      
    
        
    to get the hart ID of the given
device tree node and do some checks if CPU is available and given device
tree node has proper riscv,isa property.

As a helper function dt_get_cpuid() is introduced to deal specifically
with reg propery of a CPU device node.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in V2:
 - s/of_get_cpu_hwid()/dt_get_cpu_id().
 - Update prototype of dt_get_cpu_hwid(), use pointer-to-const for cpun arg.
 - Add empty line before last return in dt_get_cpu_hwid().
 - s/riscv_of_processor_hartid/dt_processor_cpuid().
 - Use pointer-to_const for node argument of dt_processor_cpuid().
 - Use for hart_id unsigned long type as according to the spec for RV128
   mhartid register will be 128 bit long.
 - Update commit message and subject.
 - use 'CPU' instead of 'HART'.

    
      
    
      
    Was this is good move? What is returned ...


    
      
    
        
    --- a/xen/arch/riscv/include/asm/smp.h
+++ b/xen/arch/riscv/include/asm/smp.h
@@ -26,6 +26,9 @@ static inline void set_cpuid_to_hartid(unsigned long cpuid,
 
 void setup_tp(unsigned int cpuid);
 
+struct dt_device_node;
+int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid);

    
      
    
      
    ... here isn't a number in Xen's CPU numbering space. From earlier discussions I'm
not sure it's a hart ID either, so it may need further clarification (and I'd
expect RISC-V to have suitable terminology to tell apart the different entities).
    
    
    
    
    From device tree point of view (https://www.kernel.org/doc/Documentation/devicetree/bindings/riscv/cpus.txt)
it is just hart which is defined as a hardware execution context, which contains all the state mandated by
the RISC-V ISA: a PC and some registers.
And also based on this for DT binding:
  For example, my Intel laptop is
  described as having one socket with two cores, each of which has two hyper
  threads.  Therefore this system has four harts.
They are using just harts and in DT it will look like 4 node with a number in reg property which they
call hart. So from DT point of view hartid is pretty fine to use.

>From specification point of view (https://riscv.github.io/riscv-isa-manual/snapshot/unprivileged/#_risc_v_hardware_platform_terminology):
  A RISC-V hardware platform can contain one or more RISC-V-compatible processing cores together
  with other non-RISC-V-compatible cores, fixed-function accelerators, various physical memory
  structures, I/O devices, and an interconnect structure to allow the components to communicate.

  A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-
  compatible core might support multiple RISC-V-compatible hardware threads, or harts, through
  multithreading.
and (https://riscv.github.io/riscv-isa-manual/snapshot/unprivileged/#_risc_v_software_execution_environments_and_harts):
  From the perspective of software running in a given execution environment, a hart is a resource that
  autonomously fetches and executes RISC-V instructions within that execution environment. In this
  respect, a hart behaves like a hardware thread resource even if time-multiplexed onto real hardware by
  the execution environment. Some EEIs support the creation and destruction of additional harts, for
  example, via environment calls to fork new harts.
    
    
    DT's CPU node should be refer to core plus hardware thread (or threads in case of multithreading)
in reg property to be close to the spec(?) but basically in DT they IMO just describe what in the sepc
is called an independent instruction fetch unit.

I still think that it is fine just to use hart_id. If to be close more to a spec the unit_id(?)
but it is more confusing IMO with what is use in RISC-V's DT binding.


    
    
    
      
    

    
      
    
        
    @@ -10,3 +13,66 @@ void __init smp_prepare_boot_cpu(void)
     cpumask_set_cpu(0, &cpu_possible_map);
     cpumask_set_cpu(0, &cpu_online_map);
 }
+
+/**
+ * dt_get_cpuid - Get the cpuid from a CPU device node
+ *
+ * @cpun: CPU number(logical index) for which device node is required
+ *
+ * Return: The cpuid for the CPU node or ~0ULL if not found.
+ */
+static unsigned long dt_get_cpuid(const struct dt_device_node *cpun)
+{
+    const __be32 *cell;
+    int ac;

    
      
    
      
    This is bogus (should be unsigned int afaict), but dictated by ...


    
      
    
        
    +    uint32_t len;
+
+    ac = dt_n_addr_cells(cpun);

    
      
    
      
    ... the return value here and ...


    
      
    
        
    +    cell = dt_get_property(cpun, "reg", &len);
+    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
+        return ~0ULL;

    
      
    
      
    (Nit: This doesn't match the return type of the function; same for
the function comment. Also, what if sizeof(*cell) * ac < len?)


    
      
    
        
    +    return dt_read_number(cell, ac);

    
      
    
      
    ... the function parameter type here. 
    
    
    
    
    I think that we can declare ac as unsigned int even dt_n_addr_cells
return int as basically it returns be32_to_cpu(*ip) which return unsigned
int and it isn't expected to be a big value so overflow of INT_MAX shouldn't
happen and it won't affect a size argument of dt_read_number().
    
    
    
      
    In fact, that function is raising
another question: If the "size" argument is outside of [0, 2], the value
returned is silently truncated.
    
    
    
    
    Usually address-cells is 1 or 2, so it isn't expected to be higher (but DT tells
that the value is u32 so it could be higher then 2). And I think it could be also
explained by bitness of an architecture.
I think I see address-cells equal to 3 for something connected to PCI, but
probably another one functions should be used to read.


    
    
    
      
    
More generally - are there any plans to make DT code signed-ness-correct?


    
      
    
        
    +/*
+ * Returns the cpuid of the given device tree node, or -ENODEV if the node
+ * isn't an enabled and valid RISC-V hart node.
+ */
+int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
+{
+    const char *isa;
+
+    if ( !dt_device_is_compatible(node, "riscv") )
+    {
+        printk("Found incompatible CPU\n");
+        return -ENODEV;
+    }
+
+    *cpuid = dt_get_cpuid(node);
+    if ( *cpuid == ~0UL )
+    {
+        printk("Found CPU without CPU ID\n");
+        return -ENODEV;
+    }
+
+    if ( !dt_device_is_available(node))
+    {
+        printk("CPU with cpuid=%lu is not available\n", *cpuid);
+        return -ENODEV;
+    }
+
+    if ( dt_property_read_string(node, "riscv,isa", &isa) )
+    {
+        printk("CPU with cpuid=%lu has no \"riscv,isa\" property\n", *cpuid);
+        return -ENODEV;
+    }
+
+    if ( isa[0] != 'r' || isa[1] != 'v' )
+    {
+        printk("CPU with cpuid=%lu has an invalid ISA of \"%s\"\n", *cpuid, isa);
+        return -ENODEV;
+    }
+
+    return 0;
+}

    
      
    
      
    I view it as unhelpful that all errors result in -ENODEV. Yes, there are log
messages for all of the cases, but surely there are errno values better
representing the individual failure reasons?
    
    
    
    
    I will update that to:

@@ -46,6 +46,7 @@ static unsigned long dt_get_cpuid(const struct dt_device_node *cpun)
 int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
 {
     const char *isa;
+    int ret;
 
     if ( !dt_device_is_compatible(node, "riscv") )
     {
@@ -57,7 +58,7 @@ int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
     if ( *cpuid == ~0UL )
     {
         printk("Found CPU without CPU ID\n");
-        return -ENODEV;
+        return -EINVAL;
     }
 
     if ( !dt_device_is_available(node))
@@ -66,16 +67,16 @@ int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
         return -ENODEV;
     }
 
-    if ( dt_property_read_string(node, "riscv,isa", &isa) )
+    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
     {
         printk("CPU with cpuid=%lu has no \"riscv,isa\" property\n", *cpuid);
-        return -ENODEV;
+        return ret;
     }
 
     if ( isa[0] != 'r' || isa[1] != 'v' )
     {
         printk("CPU with cpuid=%lu has an invalid ISA of \"%s\"\n", *cpuid, isa);
-        return -ENODEV;
+        return -EINVAL;
     }
 
     return 0;

I think it's better now.

Thanks.

~ Oleksii
    
  


--------------s5zO9QC0mthSFHmFvQACGQQ9--


From xen-devel-bounces@lists.xenproject.org Fri May 16 17:41:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 17:41:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987399.1372679 (Exim 4.92)
	(envelope-from )
	id 1uFz3z-0000cg-Jm; Fri, 16 May 2025 17:41:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987399.1372679; Fri, 16 May 2025 17:41: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 1uFz3z-0000cZ-GB; Fri, 16 May 2025 17:41:39 +0000
Received: by outflank-mailman (input) for mailman id 987399;
 Fri, 16 May 2025 17:41:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFz3x-0000cT-5r
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 17:41:38 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 026045ef-327d-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 19:41: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" 
X-Inumbo-ID: 026045ef-327d-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747417293; x=1747676493;
	bh=njgExrnbYLtvK1OaAzeaTD4ltQW3C5C3WVRRW05RHWE=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=TXshXSz4q1NobHNtxASVeOM+Ny7FUDFKq8uh0lp4OjioD3zt0RVp8ealCvVy7Tlxu
	 VBXeS4n4l4U7OCiK1F7jBqSWh+3TMsBC4Meci08SdqBwA9EoauL6dTOJf9xve6uyGd
	 sMfi7F/wdaYYGX8lepRUPrOfzzjRs+7KqiM/5GFQ3l52G7R/87gq11pwk19gmC1mUn
	 7zT3gJ4UGyYVM8gfSNnTMcQLtUIZb3lhcy8WluewJCI7iSccfbnYzMy+yRLO0izpQb
	 kvATY2AYMTX5Kg9rCdAipX1V4fIdnQ2/K5Ornxnhd8D11Tb/vIav+Pk7MTzf/3z9JI
	 /kC7VL7tMsb/w==
Date: Fri, 16 May 2025 17:41:26 +0000
To: Andrew Cooper 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, jbeulich@suse.com, roger.pau@citrix.com, nicola.vetrini@bugseng.com, consulting@bugseng.com, dmukhin@ford.com
Subject: Re: [PATCH v5 1/2] x86/vmx: replace __vmread() with vmread()
Message-ID: 
In-Reply-To: <7c0a689e-c116-49e2-9caa-f5679f8960eb@citrix.com>
References: <20250513052809.3947164-1-dmukhin@ford.com> <20250513052809.3947164-2-dmukhin@ford.com> <7c0a689e-c116-49e2-9caa-f5679f8960eb@citrix.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 36b4c2573d8b712348fca386ce19a70ff1a9f8a9
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, May 16, 2025 at 01:42:23PM +0100, Andrew Cooper wrote:
> On 13/05/2025 6:28 am, dmkhn@proton.me wrote:
> > diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
> > index 91b407e6bc..b622ae1e60 100644
> > --- a/xen/arch/x86/hvm/vmx/intr.c
> > +++ b/xen/arch/x86/hvm/vmx/intr.c
> > @@ -65,7 +65,7 @@ static void vmx_enable_intr_window(struct vcpu *v, st=
ruct hvm_intack intack)
> >      {
> >          unsigned long intr;
> >
> > -        __vmread(VM_ENTRY_INTR_INFO, &intr);
> > +        intr =3D vmread(VM_ENTRY_INTR_INFO);
> >          TRACE(TRC_HVM_INTR_WINDOW, intack.vector, intack.source,
> >                (intr & INTR_INFO_VALID_MASK) ? intr & 0xff : -1);
> >      }
>=20
> As Jan said in v4, lots of these should now change away from being
> unsigned long.

Sorry, I interpreted v4 feedback as "first, do straight reuse of vmread()
everywhere, then send follow on smaller patches cleaning up the code around
vmread()s".

>=20
> For example, this delta alone:
>=20
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 203ca83c16e7..c540ea5bd850 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -4154,9 +4154,8 @@ static void undo_nmis_unblocked_by_iret(void)
> =C2=A0
> =C2=A0void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
> =C2=A0{
> -=C2=A0=C2=A0=C2=A0 unsigned long exit_qualification, exit_reason, idtv_i=
nfo, intr_info
> =3D 0;
> -=C2=A0=C2=A0=C2=A0 unsigned long cs_ar_bytes =3D 0;
> -=C2=A0=C2=A0=C2=A0 unsigned int vector =3D 0;
> +=C2=A0=C2=A0=C2=A0 unsigned long exit_qualification;
> +=C2=A0=C2=A0=C2=A0 unsigned int exit_reason, idtv_info, intr_info =3D 0,=
 cs_ar_bytes =3D
> 0, vector =3D 0;
> =C2=A0=C2=A0=C2=A0=C2=A0 struct vcpu *v =3D current;
> =C2=A0=C2=A0=C2=A0=C2=A0 struct domain *currd =3D v->domain;
> =C2=A0
> @@ -4830,7 +4829,7 @@ void asmlinkage vmx_vmexit_handler(struct
> cpu_user_regs *regs)
> =C2=A0=C2=A0=C2=A0=C2=A0 /* fall through */
> =C2=A0=C2=A0=C2=A0=C2=A0 default:
> =C2=A0=C2=A0=C2=A0=C2=A0 exit_and_crash:
> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gprintk(XENLOG_ERR, "Unexpect=
ed vmexit: reason %lu\n",
> exit_reason);
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gprintk(XENLOG_ERR, "Unexpect=
ed vmexit: reason %u\n", exit_reason);
> =C2=A0
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if ( vmx_get_cpl() )
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 hvm_inject_hw_exception(X86_EXC_UD,
>=20
> results in:
>=20
> =C2=A0=C2=A0=C2=A0 add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-331 (-331=
)
> =C2=A0=C2=A0=C2=A0 Function=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=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 old=C2=A0=C2=A0=C2=A0=C2=A0 new=C2=A0=C2=
=A0 delta
> =C2=A0=C2=A0=C2=A0 vmx_vmexit_handler.cold=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 929=C2=A0=C2=A0=C2=A0=C2=A0 839=C2=A0=C2=A0=
=C2=A0=C2=A0 -90
> =C2=A0=C2=A0=C2=A0 vmx_vmexit_handler=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=C2=A0=C2=A0=C2=A0=C2=A0 5490=C2=A0=C2=A0=C2=A0 5249=
=C2=A0=C2=A0=C2=A0 -241
>=20
> worth of saving in the fastpath.=C2=A0 (Yes, I chose this example careful=
ly
> because it's surely the largest win to be had.)
>=20
> I've just sent out a minor docs patch annotating the sizes of the fields.
>=20
> This patch wants splitting into at least 3:
>=20
> =C2=A0* One for the 64bit and natural fields which are a straight transfo=
rm
> and no type-change away from unsigned long.
> =C2=A0* One for the 16bit fields (there are few enough that this can easi=
ly
> be a single patch).
> =C2=A0* One or more for the 32bit fields, doing a type change to unsigned=
 int
> too.=C2=A0 (Might get quite large.=C2=A0 Hard to judge whether it wants t=
o be one
> or more without seeing it.)

Thanks for the feedback!

>=20
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Fri May 16 18:07:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 18:07:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987417.1372689 (Exim 4.92)
	(envelope-from )
	id 1uFzSh-0003SX-Ee; Fri, 16 May 2025 18:07:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987417.1372689; Fri, 16 May 2025 18: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 1uFzSh-0003SQ-Br; Fri, 16 May 2025 18:07:11 +0000
Received: by outflank-mailman (input) for mailman id 987417;
 Fri, 16 May 2025 18:07:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFzSf-0003SK-Db
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 18:07:10 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91c6c285-3280-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 20:07: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" 
X-Inumbo-ID: 91c6c285-3280-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747418821; x=1747678021;
	bh=P6nu4SsxXiP2P+YxNX+aZdhXlSA+W3wSb6kfH+jAAIk=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=jCZmIBChTQurmXZOQU++Dpd2cQ9NGLVxDOCcQxmpr0+WiITOEiR/hSYEZyX+lCrZg
	 RnTAe6OPPp5wqoTtCbyvYMB4UPIZUNoEKxLX668AoUQxMVufQUtOssXTw1C222PbDX
	 ni7KeK9k5lSUknw90VfqL5zZXXPHu7CGpsX8JSaws70shWWtU0JQINwHBL+jHsSTek
	 9ldW7HXFKne6DfjQAZcOf4WqO3IdK/mFShEJ6+8hWIvCPAKHP9onWRHNucC4cRZQr1
	 EnI7w2pu6zFxUJqmW6p5jYeasMqjn71b9jMpOBkiycaHSQajZYYH49R7jGDOw4bx6E
	 XQboQRYvrRkIQ==
Date: Fri, 16 May 2025 18:06:56 +0000
To: Teddy Astie 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v6 1/2] xen/domain: unify domain ID allocation
Message-ID: 
In-Reply-To: <3c9f60b3-cedb-4689-a3b4-15ebddcf9f67@vates.tech>
References: <20250516020434.1145337-1-dmukhin@ford.com> <20250516020434.1145337-2-dmukhin@ford.com> <3c9f60b3-cedb-4689-a3b4-15ebddcf9f67@vates.tech>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 550e272c748fe01b69429eddf7b387fcaccd2847
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, May 16, 2025 at 08:43:35AM +0000, Teddy Astie wrote:
> Hello,
>=20
> Le 16/05/2025 =C3=A0 04:06, dmkhn@proton.me a =C3=A9crit=C2=A0:
> > From: Denis Mukhin 
> >
> > Currently, hypervisor code has two different non-system domain ID alloc=
ation
> > implementations:
> >
> >    (a) Sequential IDs allocation in dom0less Arm code based on max_init=
_domid;
> >
> >    (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not u=
se
> >        max_init_domid (both Arm and x86).
> >
> > It makes sense to have a common helper code for such task across archit=
ectures
> > (Arm and x86) and between dom0less / toolstack domU allocation.
> >
> > Wrap the domain ID allocation as an arch-independent function domid_all=
oc() in
> > common/domain.c based on rangeset.
> >
> > Allocation algorithm:
> > - If an explicit domain ID is provided, verify its availability and
> >    use it if ID is not used;
> > - Otherwise, perform an exhaustive search starting from the end of the =
used
> >    domain ID range. domid_alloc() guarantees that two subsequent calls =
will
> >    result in different IDs allocation.
> >
> > Initialize the domain IDs rangeset from the new domid_init() which is c=
alled
> > from arch setup code.
> >
> > Also, remove is_free_domid() helper as it is not needed now.
> >
> > No functional change intended.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v5:
> > - rebased
> > ---
> >   xen/arch/arm/domain_build.c             | 17 ++++--
> >   xen/arch/arm/setup.c                    |  2 +
> >   xen/arch/x86/setup.c                    | 13 +++--
> >   xen/common/device-tree/dom0less-build.c | 10 ++--
> >   xen/common/domain.c                     | 70 ++++++++++++++++++++++++=
+
> >   xen/common/domctl.c                     | 41 ++-------------
> >   xen/include/xen/domain.h                |  4 ++
> >   7 files changed, 107 insertions(+), 50 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index b189a7cfae..e9d563c269 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2010,6 +2010,7 @@ void __init create_dom0(void)
> >           .grant_opts =3D XEN_DOMCTL_GRANT_version(opt_gnttab_max_versi=
on),
> >       };
> >       unsigned int flags =3D CDF_privileged | CDF_hardware;
> > +    domid_t domid;
> >       int rc;
> >
> >       /* The vGIC for DOM0 is exactly emulating the hardware GIC */
> > @@ -2034,19 +2035,25 @@ void __init create_dom0(void)
> >       if ( !llc_coloring_enabled )
> >           flags |=3D CDF_directmap;
> >
> > -    dom0 =3D domain_create(0, &dom0_cfg, flags);
> > +    domid =3D domid_alloc(0);
> > +    if ( domid =3D=3D DOMID_INVALID )
> > +        panic("Error allocating domain ID 0\n");
> > +
> > +    dom0 =3D domain_create(domid, &dom0_cfg, flags);
> >       if ( IS_ERR(dom0) )
> > -        panic("Error creating domain 0 (rc =3D %ld)\n", PTR_ERR(dom0))=
;
> > +        panic("Error creating domain %d (rc =3D %ld)\n", domid, PTR_ER=
R(dom0));
> >
> >       if ( llc_coloring_enabled && (rc =3D dom0_set_llc_colors(dom0)) )
> > -        panic("Error initializing LLC coloring for domain 0 (rc =3D %d=
)\n", rc);
> > +        panic("Error initializing LLC coloring for domain %pd (rc =3D =
%d)\n",
> > +              dom0, rc);
> >
> >       if ( alloc_dom0_vcpu0(dom0) =3D=3D NULL )
> > -        panic("Error creating domain 0 vcpu0\n");
> > +        panic("Error creating domain %pdv0\n", dom0);
> >
> >       rc =3D construct_dom0(dom0);
> >       if ( rc )
> > -        panic("Could not set up DOM0 guest OS (rc =3D %d)\n", rc);
> > +        panic("Could not set up guest OS for domain %pd (rc =3D %d)\n"=
,
> > +              dom0, rc);
> >
> >       set_xs_domain(dom0);
> >   }
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 10b46d0684..c3959e8d8e 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -418,6 +418,8 @@ void asmlinkage __init start_xen(unsigned long fdt_=
paddr)
> >
> >       timer_init();
> >
> > +    domid_init();
> > +
> >       init_idle_domain();
> >
> >       rcu_init();
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 2518954124..02f665f520 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -1030,8 +1030,11 @@ static struct domain *__init create_dom0(struct =
boot_info *bi)
> >       if ( iommu_enabled )
> >           dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu;
> >
> > -    /* Create initial domain.  Not d0 for pvshim. */
> > -    bd->domid =3D get_initial_domain_id();
> > +    /* Allocate initial domain ID. Not d0 for pvshim. */
> > +    bd->domid =3D domid_alloc(get_initial_domain_id());
> > +    if ( bd->domid =3D=3D DOMID_INVALID )
> > +        panic("Error allocating domain ID %d\n", get_initial_domain_id=
());
> > +
> >       d =3D domain_create(bd->domid, &dom0_cfg,
> >                         pv_shim ? 0 : CDF_privileged | CDF_hardware);
> >       if ( IS_ERR(d) )
> > @@ -1063,7 +1066,7 @@ static struct domain *__init create_dom0(struct b=
oot_info *bi)
> >
> >           if ( (strlen(acpi_param) =3D=3D 0) && acpi_disabled )
> >           {
> > -            printk("ACPI is disabled, notifying Domain 0 (acpi=3Doff)\=
n");
> > +            printk("ACPI is disabled, notifying domain %pd (acpi=3Doff=
)\n", d);
> >               safe_strcpy(acpi_param, "off");
> >           }
> >
> > @@ -1078,7 +1081,7 @@ static struct domain *__init create_dom0(struct b=
oot_info *bi)
> >
> >       bd->d =3D d;
> >       if ( construct_dom0(bd) !=3D 0 )
> > -        panic("Could not construct domain 0\n");
> > +        panic("Could not construct domain %pd\n", d);
> >
> >       bd->cmdline =3D NULL;
> >       xfree(cmdline);
> > @@ -1915,6 +1918,8 @@ void asmlinkage __init noreturn __start_xen(void)
> >       mmio_ro_ranges =3D rangeset_new(NULL, "r/o mmio ranges",
> >                                     RANGESETF_prettyprint_hex);
> >
> > +    domid_init();
> > +
> >       xsm_multiboot_init(bi);
> >
> >       /*
> > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/devic=
e-tree/dom0less-build.c
> > index 2c56f13771..9236dbae11 100644
> > --- a/xen/common/device-tree/dom0less-build.c
> > +++ b/xen/common/device-tree/dom0less-build.c
> > @@ -850,15 +850,13 @@ void __init create_domUs(void)
> >           struct xen_domctl_createdomain d_cfg =3D {0};
> >           unsigned int flags =3D 0U;
> >           bool has_dtb =3D false;
> > +        domid_t domid;
> >           uint32_t val;
> >           int rc;
> >
> >           if ( !dt_device_is_compatible(node, "xen,domain") )
> >               continue;
> >
> > -        if ( (max_init_domid + 1) >=3D DOMID_FIRST_RESERVED )
> > -            panic("No more domain IDs available\n");
> > -
> >           d_cfg.max_evtchn_port =3D 1023;
> >           d_cfg.max_grant_frames =3D -1;
> >           d_cfg.max_maptrack_frames =3D -1;
> > @@ -981,7 +979,11 @@ void __init create_domUs(void)
> >            * very important to use the pre-increment operator to call
> >            * domain_create() with a domid > 0. (domid =3D=3D 0 is reser=
ved for Dom0)
> >            */
> > -        d =3D domain_create(++max_init_domid, &d_cfg, flags);
> > +        domid =3D domid_alloc(++max_init_domid);
> > +        if ( domid =3D=3D DOMID_INVALID )
> > +            panic("Error allocating ID for domain %s\n", dt_node_name(=
node));
> > +
> > +        d =3D domain_create(domid, &d_cfg, flags);
> >           if ( IS_ERR(d) )
> >               panic("Error creating domain %s (rc =3D %ld)\n",
> >                     dt_node_name(node), PTR_ERR(d));
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index abf1969e60..0ba3cdc47d 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -66,6 +66,74 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
> >   static struct domain *domain_hash[DOMAIN_HASH_SIZE];
> >   struct domain *domain_list;
> >
> > +/* Non-system domain ID allocator. */
> > +static DEFINE_SPINLOCK(domid_lock);
> > +static struct rangeset *domid_rangeset;
> > +static unsigned int domid_last;
> > +
> > +void __init domid_init(void)
> > +{
> > +    domid_rangeset =3D rangeset_new(NULL, "domid", RANGESETF_prettypri=
nt_hex);
> > +    if ( !domid_rangeset )
> > +        panic("cannot allocate domain ID rangeset\n");
> > +
> > +    rangeset_limit(domid_rangeset, DOMID_FIRST_RESERVED);
> > +}
> > +
> > +/*
> > + * Allocate new non-system domain ID based on the hint.
> > + *
> > + * If hint is outside of valid [0..DOMID_FIRST_RESERVED - 1] range of =
IDs,
> > + * perform an exhaustive search starting from the end of the used doma=
in ID
> > + * range.
> > + */
> > +domid_t domid_alloc(domid_t domid)
> > +{
> > +    spin_lock(&domid_lock);
> > +
> > +    if ( domid < DOMID_FIRST_RESERVED )
> > +    {
> > +        if ( rangeset_contains_singleton(domid_rangeset, domid) )
> > +            domid =3D DOMID_INVALID;
> > +    }
> > +    else
> > +    {
> > +        for ( domid =3D domid_last + 1; domid !=3D domid_last; domid++=
 )
> > +        {
> > +            if ( domid =3D=3D DOMID_FIRST_RESERVED )
> > +                domid =3D 0;
> > +
> > +            if ( !rangeset_contains_singleton(domid_rangeset, domid) )
> > +                break;
> > +        }
> > +
> > +        if ( domid =3D=3D domid_last )
> > +            domid =3D DOMID_INVALID;
> > +    }
> > +
> > +    if ( domid !=3D DOMID_INVALID )
> > +    {
> > +        ASSERT(!rangeset_add_singleton(domid_rangeset, domid));
> > +
> > +        if ( domid !=3D domid_last )
> > +            domid_last =3D domid;
> > +    }
> > +
> > +    spin_unlock(&domid_lock);
> > +
> > +    return domid;
> > +}
>=20
> It's mostly a matter of implementation choice, but I am not really fan
> of relying on rangesets, which to me are meant for address ranges or
> something similar but at least large.
>=20
> I would rather rely on a bitmap using find_first_zero_bit+set_bit which
> avoids doing a per-domid test, and may be simpler overall. The bitmap
> size for 0x3FF0 domains is almost 4KB, which looks acceptable.
>=20
> I don't know what other thinks.

Thanks for taking a look!

TBH, I was initially considering using a bitmap. But then I chose use range=
sets
because statically defined bitmap will increase the binary size, which may =
be
indesirable; and for dynamic allocation, rangeset has all convenience APIs
implemented...

>=20
> > +
> > +void domid_free(domid_t domid)
> > +{
> > +    spin_lock(&domid_lock);
> > +
> > +    if ( rangeset_contains_singleton(domid_rangeset, domid) )
> > +        ASSERT(!rangeset_remove_singleton(domid_rangeset, domid));
> > +
> > +    spin_unlock(&domid_lock);
> > +}
> > +
> >   /*
> >    * Insert a domain into the domlist/hash.  This allows the domain to =
be looked
> >    * up by domid, and therefore to be the subject of hypercalls/etc.
> > @@ -1449,6 +1517,8 @@ void domain_destroy(struct domain *d)
> >
> >       TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id);
> >
> > +    domid_free(d->domain_id);
> > +
> >       /* Remove from the domlist/hash. */
> >       domlist_remove(d);
> >
> > diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> > index bfe2e1f9f0..2e02139660 100644
> > --- a/xen/common/domctl.c
> > +++ b/xen/common/domctl.c
> > @@ -49,20 +49,6 @@ static int xenctl_bitmap_to_nodemask(nodemask_t *nod=
emask,
> >                                      MAX_NUMNODES);
> >   }
> >
> > -static inline int is_free_domid(domid_t dom)
> > -{
> > -    struct domain *d;
> > -
> > -    if ( dom >=3D DOMID_FIRST_RESERVED )
> > -        return 0;
> > -
> > -    if ( (d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL )
> > -        return 1;
> > -
> > -    rcu_unlock_domain(d);
> > -    return 0;
> > -}
> > -
> >   void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo =
*info)
> >   {
> >       struct vcpu *v;
> > @@ -421,34 +407,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_=
t) u_domctl)
> >
> >       case XEN_DOMCTL_createdomain:
> >       {
> > -        domid_t        dom;
> > -        static domid_t rover =3D 0;
> > +        domid_t domid =3D domid_alloc(op->domain);
> >
> > -        dom =3D op->domain;
> > -        if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) )
> > +        if ( domid =3D=3D DOMID_INVALID )
> >           {
> >               ret =3D -EEXIST;
> > -            if ( !is_free_domid(dom) )
> > -                break;
> > -        }
> > -        else
> > -        {
> > -            for ( dom =3D rover + 1; dom !=3D rover; dom++ )
> > -            {
> > -                if ( dom =3D=3D DOMID_FIRST_RESERVED )
> > -                    dom =3D 1;
> > -                if ( is_free_domid(dom) )
> > -                    break;
> > -            }
> > -
> > -            ret =3D -ENOMEM;
> > -            if ( dom =3D=3D rover )
> > -                break;
> > -
> > -            rover =3D dom;
> > +            break;
> >           }
> >
> > -        d =3D domain_create(dom, &op->u.createdomain, false);
> > +        d =3D domain_create(domid, &op->u.createdomain, false);
> >           if ( IS_ERR(d) )
> >           {
> >               ret =3D PTR_ERR(d);
>=20
> In case the domain creation failure, we need to free the domid,
> otherwise, it would not be used anymore as considered used by the domid
> allocator.

Thanks!

>=20
> > diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> > index e10baf2615..039bb7eeaf 100644
> > --- a/xen/include/xen/domain.h
> > +++ b/xen/include/xen/domain.h
> > @@ -38,6 +38,10 @@ void arch_get_domain_info(const struct domain *d,
> >
> >   domid_t get_initial_domain_id(void);
> >
> > +void domid_init(void);
> > +void domid_free(domid_t domid);
> > +domid_t domid_alloc(domid_t domid);
> > +
> >   /* CDF_* constant. Internal flags for domain creation. */
> >   /* Is this a privileged domain? */
> >   #define CDF_privileged           (1U << 0)
>=20
> Teddy
>=20
>=20
> Teddy Astie | Vates XCP-ng Developer
>=20
> XCP-ng & Xen Orchestra - Vates solutions
>=20
> web: https://vates.tech
>=20
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Fri May 16 18:08:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 18:08:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987423.1372699 (Exim 4.92)
	(envelope-from )
	id 1uFzTV-0003w4-Ly; Fri, 16 May 2025 18:08:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987423.1372699; Fri, 16 May 2025 18:08: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 1uFzTV-0003vx-JJ; Fri, 16 May 2025 18:08:01 +0000
Received: by outflank-mailman (input) for mailman id 987423;
 Fri, 16 May 2025 18:08:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uFzTU-0003SK-L8
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 18:08:00 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b37bf395-3280-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 20:08:00 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b37bf395-3280-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=xtkqtuzgync4nmq5fi56dj5yt4.protonmail; t=1747418878; x=1747678078;
	bh=U32vardb3bMfLhRe8zBlWvOhEEaCLcFWN5zRoe903xM=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=QErf5hgrOl4cTMZjNlZJg7BDueuIFnkbSsl7DWpM6dwaxEr0GJoJvNpugN8G4vDyT
	 THnb8MmmG5Kl/cKqCNZtQw+9khKYDqENiBrhEeA9t3pN7PA2M6jDOqh4HR2rMg3kKZ
	 UebvrT+neaJG5cX33O2NTTTfaahrxDIfQqGZ9T1JadiJ8duTKluVN2OUr7VL33DyO3
	 3H1S1+iqmvAsWvd9ibQAY4B+BnCM75Hb2aC1JThv/hwfGPG3nRT8uRgrqrXWvk1sRn
	 G4LiUEaNbUZEXHSANpfvKG1ivlYtClKWlTkBsKNbw2zbrp77CtH5HdaVCbFdleqDjG
	 eaFZfLL+oGCFA==
Date: Fri, 16 May 2025 18:07:52 +0000
To: Nicola Vetrini 
From: dmkhn@proton.me
Cc: Andrew Cooper , xen-devel@lists.xenproject.org, jbeulich@suse.com, roger.pau@citrix.com, consulting@bugseng.com, dmukhin@ford.com, Stefano Stabellini 
Subject: Re: [PING MISRA] Re: [PATCH v5 2/2] x86/vmx: remove __vmread()
Message-ID: 
In-Reply-To: 
References: <20250513052809.3947164-1-dmukhin@ford.com> <20250513052809.3947164-3-dmukhin@ford.com> <85f778d1-7fb5-47da-9153-35333e486d24@citrix.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 3aa588e9e93238631c5af83161289d4aa1f8b523
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, May 16, 2025 at 02:53:03PM +0200, Nicola Vetrini wrote:
> On 2025-05-16 14:45, Andrew Cooper wrote:
> > Hello,
> >
> > This is adjusting some MISRA configuration.=C2=A0 I'm reasonably sure t=
he
> > change is fine as we're simply removing the referenced helper, but can
> > we get a second opinion from anyone who knows what
> > function-macro-properties.json is supposed to be doing?
> >
> > Thanks,
> >
> > ~Andrew
> >
>=20
> Hi Andrew,
>=20
> sorry, it slipped under other emails. The change is ok.
>=20
> > On 13/05/2025 6:28 am, dmkhn@proton.me wrote:
> >> From: Denis Mukhin 
> >>
> >> Remove __vmread() and adjust ECLAIR configuration to account for the
> >> change.
> >>
> >> Signed-off-by: Denis Mukhin 
>=20
> Reviewed-by: Nicola Vetrini 

Thank you

>=20
> >> ---
> >>  docs/misra/function-macro-properties.json | 9 ---------
> >>  xen/arch/x86/include/asm/hvm/vmx/vmx.h    | 5 -----
> >>  2 files changed, 14 deletions(-)
> >>
> >> diff --git a/docs/misra/function-macro-properties.json
> >> b/docs/misra/function-macro-properties.json
> >> index 74058297b5..59ba63626e 100644
> >> --- a/docs/misra/function-macro-properties.json
> >> +++ b/docs/misra/function-macro-properties.json
> >> @@ -152,15 +152,6 @@
> >>              "taken": ""
> >>           }
> >>        },
> >> -      {
> >> -         "type": "function",
> >> -         "value": "^__vmread.*$",
> >> -         "properties":{
> >> -            "pointee_write": "2=3Dalways",
> >> -            "pointee_read": "2=3Dnever",
> >> -            "taken": ""
> >> -         }
> >> -      },
> >>        {
> >>           "type": "function",
> >>           "value": "^hvm_pci_decode_addr.*$",
> >> diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
> >> b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
> >> index d85b52b9d5..299e2eff6b 100644
> >> --- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
> >> +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
> >> @@ -336,11 +336,6 @@ static always_inline unsigned long
> >> vmread(unsigned long field)
> >>      return value;
> >>  }
> >>
> >> -static always_inline void __vmread(unsigned long field, unsigned long
> >> *value)
> >> -{
> >> -    *value =3D vmread(field);
> >> -}
> >> -
> >>  static always_inline void __vmwrite(unsigned long field, unsigned
> >> long value)
> >>  {
> >>      asm goto ( "vmwrite %[value], %[field]\n\t"
>=20
> --
> 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 May 16 19:51:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 19:51:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987485.1372708 (Exim 4.92)
	(envelope-from )
	id 1uG156-00082D-77; Fri, 16 May 2025 19:50:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987485.1372708; Fri, 16 May 2025 19: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 1uG156-000826-46; Fri, 16 May 2025 19:50:56 +0000
Received: by outflank-mailman (input) for mailman id 987485;
 Fri, 16 May 2025 19:50:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uG153-000820-DY
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 19:50:54 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 112595f2-328f-11f0-9eb6-5ba50f476ded;
 Fri, 16 May 2025 21:50: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" 
X-Inumbo-ID: 112595f2-328f-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747425048; x=1747684248;
	bh=2CptSXvpa0L4X2bSBq3RP0goG7pZpxKrY0u0Dt/qDBE=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=NjexxW0YKMF8ybrPS992PFs2yBZy0FynVtF7bOMPROTrbDxfgSoX4eqKu+I+f51aK
	 ZjPTLtnsUuGh3I1b+uUz9tnarRwPUeodsctnuPEPQNRTwtDigRIlCdUAptF72njP0j
	 E8DNeLhkRYsQRvGAlW6Ye2IjauGxivugML8pr/yJBO68pCgzgGUD2alIsYSUY55O60
	 +yWJjeRijdqaUyCpjNZ4wtd7xe5Ez0JFgVscIxdhSX7iAO4nP5mGUv0Ge0d+Uve1jD
	 O3zuztMaQPsrgBrH5uTHMbqE/DEOGKl+lpGPU9Jo1Emq5bi6rmX2SR7tJXEysvn311
	 +FU+3vvNm42jA==
Date: Fri, 16 May 2025 19:50:40 +0000
To: Oleksii Kurochko 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini 
Subject: Re: [PATCH v1] xen/riscv: add initialization support for virtual SBI UART (vSBI UART)
Message-ID: 
In-Reply-To: <1f380b7061496f999d4d60a60b58f494dae886e1.1747064551.git.oleksii.kurochko@gmail.com>
References: <1f380b7061496f999d4d60a60b58f494dae886e1.1747064551.git.oleksii.kurochko@gmail.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 44db3bb0ebae9a042f0187035b54721fe1a76e47
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Oleksii,

On Mon, May 12, 2025 at 05:55:21PM +0200, Oleksii Kurochko wrote:
> This is the first step toward supporting a vSBI UART.
>=20
> The implementation checks for the presence of the "vsbi_uart" property
> in the device tree. If present, the vSBI UART is initialized by:
> - Allocating a structure that holds Xen console rings and character
>   buffers.
> - Initializing the vSBI UART spinlock.
>=20
> This commit introduces the following:
> - domain_vsbi_uart_init() and domain_vsbi_uart_deinit() functions.
> - A new arch_kernel_info structure with a vsbi_uart member.
> - A vsbi_uart structure to hold information related to the vSBI
>   driver, including:
>   - Whether the vSBI UART backend is in the domain or in Xen.
>   - If the backend is in Xen: details such as ring buffer, ring page,
>     Xen console ring indexes, and character buffers.
>   - A spinlock for synchronization.
>=20
> Also, introduce init_vuart() which is going to be called by dom0less
> generic code during guest domain construction.
>=20
> Signed-off-by: Oleksii Kurochko 

JFYI, I started to move all virtual UARTs under drivers/vuart directory
and introducing a framework for hooking vUARTs into console driver.

pl011 emulator cleanup
  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/3c635962a349af=
ed75f47cd2559a4160ffa41106

original 'vuart' for hwdom cleanup
  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/405c86cbd6d55f=
5737dc9ccf9b8a8f370767e3f0

move pl011 to drivers/vuart
  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/4b5cdff118a279=
5278dfcc2c1b60423b46e85f27

move 'vuart' for hwdom cleanup to drivers/vuart
  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/d76c17b8056c1d=
500afd854a513403fc3774da51

which is followed by vUART driver framework introduction (not posted):
  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/ebc7e83650e5e3=
f68e5d734e5c475c6bcde626fa

These patches ^^ are not posted, since I do already have enough patches on
the mailing list which are in progress.

I did this work along w/ NS16550 emulator on x86.

IMO, it is worth delivering those patches first and then integrate SBI UART=
.

> ---
> This patch is independent from other RISC-V connected patch series, but i=
t could
> be a merge conflict with some patches of other patch series.
> ---
>  xen/arch/riscv/Makefile                |  2 +
>  xen/arch/riscv/dom0less-build.c        | 30 +++++++++++++
>  xen/arch/riscv/include/asm/domain.h    |  4 ++
>  xen/arch/riscv/include/asm/kernel.h    | 21 +++++++++
>  xen/arch/riscv/include/asm/vsbi-uart.h | 58 ++++++++++++++++++++++++
>  xen/arch/riscv/vsbi-uart.c             | 62 ++++++++++++++++++++++++++
>  6 files changed, 177 insertions(+)
>  create mode 100644 xen/arch/riscv/dom0less-build.c
>  create mode 100644 xen/arch/riscv/include/asm/kernel.h
>  create mode 100644 xen/arch/riscv/include/asm/vsbi-uart.h
>  create mode 100644 xen/arch/riscv/vsbi-uart.c
>=20
> diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
> index d882c57528..89a1897228 100644
> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -1,5 +1,6 @@
>  obj-y +=3D aplic.o
>  obj-y +=3D cpufeature.o
> +obj-y +=3D dom0less-build.o
>  obj-$(CONFIG_EARLY_PRINTK) +=3D early_printk.o
>  obj-y +=3D entry.o
>  obj-y +=3D intc.o
> @@ -14,6 +15,7 @@ obj-y +=3D stubs.o
>  obj-y +=3D time.o
>  obj-y +=3D traps.o
>  obj-y +=3D vm_event.o
> +obj-y +=3D vsbi-uart.o
>=20
>  $(TARGET): $(TARGET)-syms
>  =09$(OBJCOPY) -O binary -S $< $@
> diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-bu=
ild.c
> new file mode 100644
> index 0000000000..afce2f606d
> --- /dev/null
> +++ b/xen/arch/riscv/dom0less-build.c
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
> +                      const struct dt_device_node *node)
> +{
> +    int rc =3D -EINVAL;
> +
> +    kinfo->arch.vsbi_uart =3D dt_property_read_bool(node, "vsbi_uart");
> +
> +    if ( kinfo->arch.vsbi_uart )
> +    {
> +        rc =3D domain_vsbi_uart_init(d, NULL);
> +        if ( rc < 0 )
> +            return rc;
> +    }
> +
> +    if ( rc )
> +        panic("%s: what a domain should use as an UART?\n", __func__);
> +
> +    return rc;
> +}
> diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include=
/asm/domain.h
> index c3d965a559..c312827d18 100644
> --- a/xen/arch/riscv/include/asm/domain.h
> +++ b/xen/arch/riscv/include/asm/domain.h
> @@ -5,6 +5,8 @@
>  #include 
>  #include 
>=20
> +#include 
> +
>  struct hvm_domain
>  {
>      uint64_t              params[HVM_NR_PARAMS];
> @@ -18,6 +20,8 @@ struct arch_vcpu {
>=20
>  struct arch_domain {
>      struct hvm_domain hvm;
> +
> +    struct vsbi_uart vsbi_uart;
>  };
>=20
>  #include 
> diff --git a/xen/arch/riscv/include/asm/kernel.h b/xen/arch/riscv/include=
/asm/kernel.h
> new file mode 100644
> index 0000000000..15c13da158
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/kernel.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef ASM__RISCV__KERNEL_H
> +#define ASM__RISCV__KERNEL_H
> +
> +struct arch_kernel_info
> +{
> +    /* Enable vsbi_uart emulation */
> +    bool vsbi_uart;
> +};
> +
> +#endif /* #ifdef ASM__RISCV__KERNEL_H */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/riscv/include/asm/vsbi-uart.h b/xen/arch/riscv/incl=
ude/asm/vsbi-uart.h
> new file mode 100644
> index 0000000000..144e3191ff
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/vsbi-uart.h
> @@ -0,0 +1,58 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef ASM__RISCV__VSBI_UART_H
> +#define ASM__RISCV__VSBI_UART_H
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +struct domain;
> +struct page_info;
> +
> +#define VSBI_UART_FIFO_SIZE 32
> +#define VSBI_UART_OUT_BUF_SIZE 128
> +
> +struct vsbi_uart_xen_backend {
> +    char in[VSBI_UART_FIFO_SIZE];
> +    char out[VSBI_UART_OUT_BUF_SIZE];
> +    XENCONS_RING_IDX in_cons, in_prod;
> +    XENCONS_RING_IDX out_prod;
> +};
> +
> +struct vsbi_uart {
> +    bool backend_in_domain;
> +    union {
> +        struct {
> +            void *ring_buf;
> +            struct page_info *ring_page;
> +        } dom;
> +        struct vsbi_uart_xen_backend *xen;
> +    } backend;
> +
> +    spinlock_t lock;
> +};
> +
> +/*
> + * TODO: we don't support an option that backend is in a domain.
> + *       At the moment, backend is ib Xen.
> + *       This structure should be implemented in the case if backend
> + *       is in a domain.
> + */
> +struct vsbi_uart_init_info {
> +};
> +
> +int domain_vsbi_uart_init(struct domain *d , struct vsbi_uart_init_info =
*info);
> +void domain_vsbi_uart_deinit(struct domain *d);
> +
> +#endif /* ASM__RISCV__VSBI_UART_H */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/riscv/vsbi-uart.c b/xen/arch/riscv/vsbi-uart.c
> new file mode 100644
> index 0000000000..5fe617ae30
> --- /dev/null
> +++ b/xen/arch/riscv/vsbi-uart.c
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +int domain_vsbi_uart_init(struct domain *d, struct vsbi_uart_init_info *=
info)
> +{
> +    int rc;
> +    struct vsbi_uart *vsbi_uart =3D &d->arch.vsbi_uart;
> +
> +    if ( vsbi_uart->backend.dom.ring_buf )
> +    {
> +        printk("%s: ring_buf !=3D 0\n", __func__);
> +        return -EINVAL;
> +    }
> +
> +    /*
> +     * info is NULL when the backend is in Xen.
> +     * info is !=3D NULL when the backend is in a domain.
> +     */
> +    if ( info !=3D NULL )
> +    {
> +        printk("%s: vsbi_uart backend in a domain isn't supported\n", __=
func__);
> +        rc =3D -EOPNOTSUPP;
> +        goto out;
> +    }
> +    else
> +    {
> +        vsbi_uart->backend_in_domain =3D false;
> +
> +        vsbi_uart->backend.xen =3D xzalloc(struct vsbi_uart_xen_backend)=
;
> +        if ( vsbi_uart->backend.xen =3D=3D NULL )
> +        {
> +            rc =3D -ENOMEM;
> +            goto out;
> +        }
> +    }
> +
> +    spin_lock_init(&vsbi_uart->lock);
> +
> +    return 0;
> +
> +out:
> +    domain_vsbi_uart_deinit(d);
> +
> +    return rc;
> +}
> +
> +void domain_vsbi_uart_deinit(struct domain *d)
> +{
> +    struct vsbi_uart *vsbi_uart =3D &d->arch.vsbi_uart;
> +
> +    if ( vsbi_uart->backend_in_domain )
> +        printk("%s: backed in a domain isn't supported\n", __func__);
> +    else
> +        XFREE(vsbi_uart->backend.xen);
> +}
> --
> 2.49.0
>=20
>=20

Thanks,
Denis



From xen-devel-bounces@lists.xenproject.org Fri May 16 20:35:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 20:35:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987517.1372719 (Exim 4.92)
	(envelope-from )
	id 1uG1mO-0004mO-IM; Fri, 16 May 2025 20:35:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987517.1372719; Fri, 16 May 2025 20:35: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 1uG1mO-0004mH-ER; Fri, 16 May 2025 20:35:40 +0000
Received: by outflank-mailman (input) for mailman id 987517;
 Fri, 16 May 2025 20:35:39 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uG1mN-0004mB-3e
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 20:35:39 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uG1mM-00Cck7-1e;
 Fri, 16 May 2025 20:35:38 +0000
Received: from [2a02:8012:3a1:0:68b3:5dd7:abfd:37e0]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uG1mL-002aHf-1w;
 Fri, 16 May 2025 20:35:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=wia0T3l6wurn0pR+m2+jo1AHUTO8duc9QYz8LHR5xNM=; b=FPIJbqf9lf8Ryb1cyoiYIlF3C8
	WdbDmqoRFhatnpOqBCTTgslZXnJVgyT1vU9gqQVMCSdQpbd0P5+ub3vD9pSGBfy3f7cPlaoR1XIjZ
	5oY3HGdUXlVUp8LtnEk3EkGu6ujCT1LhjFrp4MjxuagIfxpeFv+OtWif9TGSDxyN9YUc=;
Message-ID: <2e5afdf1-3913-4b6f-86ea-21b3ccd0833c@xen.org>
Date: Fri, 16 May 2025 21:35:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/2] xen/domain: unify domain ID allocation
Content-Language: en-GB
To: dmkhn@proton.me, Teddy Astie 
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, jbeulich@suse.com, michal.orzel@amd.com,
 roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
References: <20250516020434.1145337-1-dmukhin@ford.com>
 <20250516020434.1145337-2-dmukhin@ford.com>
 <3c9f60b3-cedb-4689-a3b4-15ebddcf9f67@vates.tech> 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Denis and Teddy,

I haven't looked at the rest of the series. Just answering
to the discussion between both of you.

On 16/05/2025 19:06, dmkhn@proton.me wrote:
> On Fri, May 16, 2025 at 08:43:35AM +0000, Teddy Astie wrote:
>>> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
>>> index 2c56f13771..9236dbae11 100644
>>> --- a/xen/common/device-tree/dom0less-build.c
>>> +++ b/xen/common/device-tree/dom0less-build.c
>>> @@ -850,15 +850,13 @@ void __init create_domUs(void)
>>>            struct xen_domctl_createdomain d_cfg = {0};
>>>            unsigned int flags = 0U;
>>>            bool has_dtb = false;
>>> +        domid_t domid;
>>>            uint32_t val;
>>>            int rc;
>>>
>>>            if ( !dt_device_is_compatible(node, "xen,domain") )
>>>                continue;
>>>
>>> -        if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
>>> -            panic("No more domain IDs available\n");
>>> -
>>>            d_cfg.max_evtchn_port = 1023;
>>>            d_cfg.max_grant_frames = -1;
>>>            d_cfg.max_maptrack_frames = -1;
>>> @@ -981,7 +979,11 @@ void __init create_domUs(void)
>>>             * very important to use the pre-increment operator to call
>>>             * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
>>>             */
>>> -        d = domain_create(++max_init_domid, &d_cfg, flags);
>>> +        domid = domid_alloc(++max_init_domid);
>>> +        if ( domid == DOMID_INVALID )
>>> +            panic("Error allocating ID for domain %s\n", dt_node_name(node));
>>> +
>>> +        d = domain_create(domid, &d_cfg, flags);
>>>            if ( IS_ERR(d) )
>>>                panic("Error creating domain %s (rc = %ld)\n",
>>>                      dt_node_name(node), PTR_ERR(d));
>>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>>> index abf1969e60..0ba3cdc47d 100644
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -66,6 +66,74 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
>>>    static struct domain *domain_hash[DOMAIN_HASH_SIZE];
>>>    struct domain *domain_list;
>>>
>>> +/* Non-system domain ID allocator. */
>>> +static DEFINE_SPINLOCK(domid_lock);
>>> +static struct rangeset *domid_rangeset;
>>> +static unsigned int domid_last;
>>> +
>>> +void __init domid_init(void)
>>> +{
>>> +    domid_rangeset = rangeset_new(NULL, "domid", RANGESETF_prettyprint_hex);
>>> +    if ( !domid_rangeset )
>>> +        panic("cannot allocate domain ID rangeset\n");
>>> +
>>> +    rangeset_limit(domid_rangeset, DOMID_FIRST_RESERVED);
>>> +}
>>> +
>>> +/*
>>> + * Allocate new non-system domain ID based on the hint.
>>> + *
>>> + * If hint is outside of valid [0..DOMID_FIRST_RESERVED - 1] range of IDs,
>>> + * perform an exhaustive search starting from the end of the used domain ID
>>> + * range.
>>> + */
>>> +domid_t domid_alloc(domid_t domid)
>>> +{
>>> +    spin_lock(&domid_lock);
>>> +
>>> +    if ( domid < DOMID_FIRST_RESERVED )
>>> +    {
>>> +        if ( rangeset_contains_singleton(domid_rangeset, domid) )
>>> +            domid = DOMID_INVALID;
>>> +    }
>>> +    else
>>> +    {
>>> +        for ( domid = domid_last + 1; domid != domid_last; domid++ )
>>> +        {
>>> +            if ( domid == DOMID_FIRST_RESERVED )
>>> +                domid = 0;
>>> +
>>> +            if ( !rangeset_contains_singleton(domid_rangeset, domid) )
>>> +                break;
>>> +        }
>>> +
>>> +        if ( domid == domid_last )
>>> +            domid = DOMID_INVALID;
>>> +    }
>>> +
>>> +    if ( domid != DOMID_INVALID )
>>> +    {
>>> +        ASSERT(!rangeset_add_singleton(domid_rangeset, domid));
>>> +
>>> +        if ( domid != domid_last )
>>> +            domid_last = domid;
>>> +    }
>>> +
>>> +    spin_unlock(&domid_lock);
>>> +
>>> +    return domid;
>>> +}
>>
>> It's mostly a matter of implementation choice, but I am not really fan
>> of relying on rangesets, which to me are meant for address ranges or
>> something similar but at least large.
>>
>> I would rather rely on a bitmap using find_first_zero_bit+set_bit which
>> avoids doing a per-domid test, and may be simpler overall. The bitmap
>> size for 0x3FF0 domains is almost 4KB, which looks acceptable.

I guess you meant 0x7FF0?

>>
>> I don't know what other thinks.
> 
> Thanks for taking a look!
> 
> TBH, I was initially considering using a bitmap. But then I chose use rangesets
> because statically defined bitmap will increase the binary size, which may be
> indesirable; and for dynamic allocation, rangeset has all convenience APIs
> implemented...

The bitmap helpers have been optimized for fast lookup and insertion. 
They could also potentially be used lockless.

On the other hand, the rangeset is a linear search from start. So for 
instance, AFAIU, "rangeset_contains_singleton()" will start looking up 
from the first range until it found the highest range lower or 
containing the singleton. It also contains an internal read-write lock. 
So we are taking two locks now.

This means the loop:

 > for ( domid = domid_last + 1; domid != domid_last; domid++ )
 >    [...]
 >    if ( !rangeset_contains_singleton(...) )

is going to be fairly ineffient. I haven't check whether we can do 
better with the rangeset.

Also, the overhead of a range is actually quite high if the domain IDs 
are not contiguous (for Arm 64-bit, it is 16-byte per range and 72-byte 
for the the rangeset structure).

Lastly, as you pointed out this is requiring dynamic allocation. Which 
means domid_alloc() could now fail because Xen is out of memory. This 
feels a little be odd to have domid_alloc() returning -ENOMEM.

BTW, I noticed in your code you are using:

ASSERT(!rangeset_add_singleton(...))

In production build, ASSERTs() behaves like a NOP:

#define ASSERT(p) do { if ( 0 && (p) ) {} } while (0)

So rangeset_add_singleton() would not be called at all. This is also not 
the right way to handle failure that can happen at runtime. Instead, the 
error should be propagated.

Overall, I think a bitmap is more suitable to keep track of the domids 
allocated.

To make clear, I think increase the binary by 4KB is fine in this case. 
If someone is really concern of the increase, they would most likely not 
try to run 4KB domains, so we could potentially introduce 
CONFIG_MAX_DOMAIN to reduce the bitmap size and the number of domains 
(it is not a ask for this series).

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri May 16 21:14:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 21:14:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987543.1372733 (Exim 4.92)
	(envelope-from )
	id 1uG2Np-0001V8-Cp; Fri, 16 May 2025 21:14:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987543.1372733; Fri, 16 May 2025 21: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 1uG2Np-0001V1-AD; Fri, 16 May 2025 21:14:21 +0000
Received: by outflank-mailman (input) for mailman id 987543;
 Fri, 16 May 2025 21:14:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uG2Nm-0001Uv-QP
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 21:14:19 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b892d80d-329a-11f0-9ffb-bf95429c2676;
 Fri, 16 May 2025 23:14:16 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b892d80d-329a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747430053; x=1747689253;
	bh=ILiVZTEkfcZao/WTFBJRIR+pWAqLu86c0kGxkMkuxS0=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=hF0vtq3y4OxYs3No8LLJQ6xwWdvXATzNd+Nk/Sq0/umCbVlrXdPnnM+2WZPunu+SS
	 i9aqO0rBzCHVDTbF+A8us417Vu3G8bmr2W0OKd8W/1Egj5Gxqc0bCR+U+CJxwJQe6T
	 MvjgmXHgwPr2oFQq7a7FzKyXQavUxMgpCt1TS4+tfOzQLtHQl6VA9b/YTWkJye2nMm
	 E+hJ02n9qqWdPF27rr6UHUr3et+Mtpgf/52AFTVulvcxwU5hNNhy3diIsKQc1KQmOF
	 e5Plv+S8zblsgRuGtMgJferrx9+KFMHyDkcvoYgp/u8sRqkElaCxQ8oINl0CPqNhcC
	 k73/Y297GWr8Q==
Date: Fri, 16 May 2025 21:14:10 +0000
To: Julien Grall 
From: dmkhn@proton.me
Cc: Teddy Astie , xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v6 1/2] xen/domain: unify domain ID allocation
Message-ID: 
In-Reply-To: <2e5afdf1-3913-4b6f-86ea-21b3ccd0833c@xen.org>
References: <20250516020434.1145337-1-dmukhin@ford.com> <20250516020434.1145337-2-dmukhin@ford.com> <3c9f60b3-cedb-4689-a3b4-15ebddcf9f67@vates.tech>  <2e5afdf1-3913-4b6f-86ea-21b3ccd0833c@xen.org>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: c8f9c67d200afb1dd42d8e7230606b6607f2a054
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, May 16, 2025 at 09:35:35PM +0100, Julien Grall wrote:
> Hi Denis and Teddy,
>=20
> I haven't looked at the rest of the series. Just answering
> to the discussion between both of you.
>=20
> On 16/05/2025 19:06, dmkhn@proton.me wrote:
> > On Fri, May 16, 2025 at 08:43:35AM +0000, Teddy Astie wrote:
> >>> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/dev=
ice-tree/dom0less-build.c
> >>> index 2c56f13771..9236dbae11 100644
> >>> --- a/xen/common/device-tree/dom0less-build.c
> >>> +++ b/xen/common/device-tree/dom0less-build.c
> >>> @@ -850,15 +850,13 @@ void __init create_domUs(void)
> >>>            struct xen_domctl_createdomain d_cfg =3D {0};
> >>>            unsigned int flags =3D 0U;
> >>>            bool has_dtb =3D false;
> >>> +        domid_t domid;
> >>>            uint32_t val;
> >>>            int rc;
> >>>
> >>>            if ( !dt_device_is_compatible(node, "xen,domain") )
> >>>                continue;
> >>>
> >>> -        if ( (max_init_domid + 1) >=3D DOMID_FIRST_RESERVED )
> >>> -            panic("No more domain IDs available\n");
> >>> -
> >>>            d_cfg.max_evtchn_port =3D 1023;
> >>>            d_cfg.max_grant_frames =3D -1;
> >>>            d_cfg.max_maptrack_frames =3D -1;
> >>> @@ -981,7 +979,11 @@ void __init create_domUs(void)
> >>>             * very important to use the pre-increment operator to cal=
l
> >>>             * domain_create() with a domid > 0. (domid =3D=3D 0 is re=
served for Dom0)
> >>>             */
> >>> -        d =3D domain_create(++max_init_domid, &d_cfg, flags);
> >>> +        domid =3D domid_alloc(++max_init_domid);
> >>> +        if ( domid =3D=3D DOMID_INVALID )
> >>> +            panic("Error allocating ID for domain %s\n", dt_node_nam=
e(node));
> >>> +
> >>> +        d =3D domain_create(domid, &d_cfg, flags);
> >>>            if ( IS_ERR(d) )
> >>>                panic("Error creating domain %s (rc =3D %ld)\n",
> >>>                      dt_node_name(node), PTR_ERR(d));
> >>> diff --git a/xen/common/domain.c b/xen/common/domain.c
> >>> index abf1969e60..0ba3cdc47d 100644
> >>> --- a/xen/common/domain.c
> >>> +++ b/xen/common/domain.c
> >>> @@ -66,6 +66,74 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
> >>>    static struct domain *domain_hash[DOMAIN_HASH_SIZE];
> >>>    struct domain *domain_list;
> >>>
> >>> +/* Non-system domain ID allocator. */
> >>> +static DEFINE_SPINLOCK(domid_lock);
> >>> +static struct rangeset *domid_rangeset;
> >>> +static unsigned int domid_last;
> >>> +
> >>> +void __init domid_init(void)
> >>> +{
> >>> +    domid_rangeset =3D rangeset_new(NULL, "domid", RANGESETF_prettyp=
rint_hex);
> >>> +    if ( !domid_rangeset )
> >>> +        panic("cannot allocate domain ID rangeset\n");
> >>> +
> >>> +    rangeset_limit(domid_rangeset, DOMID_FIRST_RESERVED);
> >>> +}
> >>> +
> >>> +/*
> >>> + * Allocate new non-system domain ID based on the hint.
> >>> + *
> >>> + * If hint is outside of valid [0..DOMID_FIRST_RESERVED - 1] range o=
f IDs,
> >>> + * perform an exhaustive search starting from the end of the used do=
main ID
> >>> + * range.
> >>> + */
> >>> +domid_t domid_alloc(domid_t domid)
> >>> +{
> >>> +    spin_lock(&domid_lock);
> >>> +
> >>> +    if ( domid < DOMID_FIRST_RESERVED )
> >>> +    {
> >>> +        if ( rangeset_contains_singleton(domid_rangeset, domid) )
> >>> +            domid =3D DOMID_INVALID;
> >>> +    }
> >>> +    else
> >>> +    {
> >>> +        for ( domid =3D domid_last + 1; domid !=3D domid_last; domid=
++ )
> >>> +        {
> >>> +            if ( domid =3D=3D DOMID_FIRST_RESERVED )
> >>> +                domid =3D 0;
> >>> +
> >>> +            if ( !rangeset_contains_singleton(domid_rangeset, domid)=
 )
> >>> +                break;
> >>> +        }
> >>> +
> >>> +        if ( domid =3D=3D domid_last )
> >>> +            domid =3D DOMID_INVALID;
> >>> +    }
> >>> +
> >>> +    if ( domid !=3D DOMID_INVALID )
> >>> +    {
> >>> +        ASSERT(!rangeset_add_singleton(domid_rangeset, domid));
> >>> +
> >>> +        if ( domid !=3D domid_last )
> >>> +            domid_last =3D domid;
> >>> +    }
> >>> +
> >>> +    spin_unlock(&domid_lock);
> >>> +
> >>> +    return domid;
> >>> +}
> >>
> >> It's mostly a matter of implementation choice, but I am not really fan
> >> of relying on rangesets, which to me are meant for address ranges or
> >> something similar but at least large.
> >>
> >> I would rather rely on a bitmap using find_first_zero_bit+set_bit whic=
h
> >> avoids doing a per-domid test, and may be simpler overall. The bitmap
> >> size for 0x3FF0 domains is almost 4KB, which looks acceptable.
>=20
> I guess you meant 0x7FF0?
>=20
> >>
> >> I don't know what other thinks.
> >
> > Thanks for taking a look!
> >
> > TBH, I was initially considering using a bitmap. But then I chose use r=
angesets
> > because statically defined bitmap will increase the binary size, which =
may be
> > indesirable; and for dynamic allocation, rangeset has all convenience A=
PIs
> > implemented...
>=20
> The bitmap helpers have been optimized for fast lookup and insertion.
> They could also potentially be used lockless.
>=20
> On the other hand, the rangeset is a linear search from start. So for
> instance, AFAIU, "rangeset_contains_singleton()" will start looking up
> from the first range until it found the highest range lower or
> containing the singleton. It also contains an internal read-write lock.
> So we are taking two locks now.
>=20
> This means the loop:
>=20
>  > for ( domid =3D domid_last + 1; domid !=3D domid_last; domid++ )
>  >    [...]
>  >    if ( !rangeset_contains_singleton(...) )
>=20
> is going to be fairly ineffient. I haven't check whether we can do
> better with the rangeset.
>=20
> Also, the overhead of a range is actually quite high if the domain IDs
> are not contiguous (for Arm 64-bit, it is 16-byte per range and 72-byte
> for the the rangeset structure).
>=20
> Lastly, as you pointed out this is requiring dynamic allocation. Which
> means domid_alloc() could now fail because Xen is out of memory. This
> feels a little be odd to have domid_alloc() returning -ENOMEM.
>=20
> BTW, I noticed in your code you are using:
>=20
> ASSERT(!rangeset_add_singleton(...))
>=20
> In production build, ASSERTs() behaves like a NOP:
>=20
> #define ASSERT(p) do { if ( 0 && (p) ) {} } while (0)
>=20
> So rangeset_add_singleton() would not be called at all. This is also not
> the right way to handle failure that can happen at runtime. Instead, the
> error should be propagated.
>=20
> Overall, I think a bitmap is more suitable to keep track of the domids
> allocated.
>=20
> To make clear, I think increase the binary by 4KB is fine in this case.
> If someone is really concern of the increase, they would most likely not
> try to run 4KB domains, so we could potentially introduce
> CONFIG_MAX_DOMAIN to reduce the bitmap size and the number of domains
> (it is not a ask for this series).

Thanks for taking a look!

I will drop ASSERT()s and switch to bitmaps.

>=20
> Cheers,
>=20
> --
> Julien Grall
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Fri May 16 22:37:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 22:37:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987609.1372799 (Exim 4.92)
	(envelope-from )
	id 1uG3gG-0003BK-J6; Fri, 16 May 2025 22:37:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987609.1372799; Fri, 16 May 2025 22:37: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 1uG3gG-0003BC-FX; Fri, 16 May 2025 22:37:28 +0000
Received: by outflank-mailman (input) for mailman id 987609;
 Fri, 16 May 2025 22:37:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG3gF-0003B6-Ed
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 22:37:27 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 56e45793-32a6-11f0-9eb6-5ba50f476ded;
 Sat, 17 May 2025 00:37:26 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id CE0BCA4E207;
 Fri, 16 May 2025 22:37:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E0F5C4CEE4;
 Fri, 16 May 2025 22:37: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" 
X-Inumbo-ID: 56e45793-32a6-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747435044;
	bh=zbv27sExf0fG9TZJkq1zDxcVhW4CrOgBYmYj+U8BPkc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=da+GnuO7IhBBnSxgmv7s6ZeL/XI0zjcGycNd/6Gb5nBudsGnWh0Onc4iwfI03ui6w
	 5CXRx86bI4sS4BE2CsQunbWN7GedVpZJ7hLOzFGB+Mb2PQfgEP7xYs1XkR1ABut8tY
	 YH60aHXM0b6DsCZIQxrry9XFrAiZbc8keCZ4x1HXjCg3q6OpiBXO1nFcIylmRp6+20
	 lqlt5v04YVaAIM9A0wZ6STY+oXoEH1w15ho6G5i6INdFZJ0Tjwh6qHhs/rv2i2V/Ag
	 YKUSZPhZZr5vCkD8U2YVd14N7B33iySY+28mod64usTmo38z+c2VYTRKVa+P2IErcR
	 6J0dtR23y6PkQ==
Date: Fri, 16 May 2025 15:37:21 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: 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 
Subject: Re: [PATCH] CODING_STYLE: Updated header guard recommendations
In-Reply-To: <20250516142031.58693-1-andrew.cooper3@citrix.com>
Message-ID: 
References: <20250516142031.58693-1-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-313421745-1747435043=:145034"

  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-313421745-1747435043=:145034
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Fri, 16 May 2025, Andrew Cooper wrote:
> Despite the best intentions at the time, the current recommendation
> lead to very long identifiers, bordering on the max limit we've chosen
> for certification.
> 
> One observation is that we do have static analysis which will
> highlight if duplicate guards are created accidentally.
> 
> Therefore, relax the recommendations and in particular remove the
> specific tie to the directory structure.  This has the other advantage
> of being more similar to other projects.
> 
> This will hopefully mean there's less churn getting the tree in shape,
> and a random contributor is more likely to pick an appropriate guard
> given no specific knowledge of Xen.
> 
> As always, it's something reviewers and maintainers should be aware
> of, and to advise on.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Stefano Stabellini 


> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monné 
> CC: Stefano Stabellini 
> ---
>  CODING_STYLE | 49 ++++++++++++++++++-------------------------------
>  1 file changed, 18 insertions(+), 31 deletions(-)
> 
> diff --git a/CODING_STYLE b/CODING_STYLE
> index e3b1da604802..5644f1697fc7 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -157,43 +157,30 @@ Header inclusion guards
>  -----------------------
>  
>  Unless otherwise specified, all header files should include proper
> -guards to prevent multiple inclusions. The following naming conventions
> -apply:
> -
> -- Guard names are derived from directory path underneath xen/ and the
> -  actual file name.  Path components are separated by double
> -  underscores.  Alphabetic characters are converted to upper case.  Non-
> -  alphanumeric characters are replaced by single underscores.
> -- Certain directory components are omitted, to keep identifier length
> -  bounded:
> -  - the top level include/,
> -  - architecture-specific private files' arch/,
> -  - any architecture's arch//include/asm/ collapses to
> -    ASM____.
> +guards to prevent multiple inclusions.  Guards need to be unique, and
> +this property is checked by static analysis.
>  
> -For example:
> +Guards should be chosen based on the logical area, with enough
> +disambiguation when the same filename exits in multiple locations in
> +the source tree.  Commonly there should be a XEN or  prefix.
> +The guard should be spelt in ALL CAPITALS, ending with _H.
>  
> -- Xen headers: XEN___H
> -  - include/xen/something.h -> XEN__SOMETHING_H
> +For example:
>  
> -- asm-generic headers: ASM_GENERIC___H
> -  - include/asm-generic/something.h -> ASM_GENERIC__SOMETHING_H
> +- Xen headers: XEN__H
> +  - include/xen/something.h -> XEN_SOMETHING_H
>  
> -- arch-specific headers: ASM_______H
> -  - arch/x86/include/asm/something.h -> ASM__X86__SOMETHING_H
> +- arch-specific headers: __H
> +  - arch/x86/include/asm/something.h -> X86_SOMETHING_H
> +  - arch/x86/include/asm/hvm/something.h -> X86_HVM_SOMETHING_H
> +  - arch/x86/include/asm/pv/something.h -> X86_PV_SOMETHING_H
>  
> -- Private headers: ___H
> -  - arch/arm/arm64/lib/something.h -> ARM__ARM64__LIB__SOMETHING_H
> -  - arch/x86/lib/something.h -> X86__LIB__SOMETHING_H
> -  - common/something.h -> COMMON__SOMETHING_H
> +- Private headers: _PRIVATE_H
> +  - common/something/private.h -> _PRIVATE_H
> +  - drivers/foo/something.h -> _H
>  
> -Note that this requires some discipline on the naming of future new
> -sub-directories: There shouldn't be any other asm/ one anywhere, for
> -example.  Nor should any new ports be named the same as top-level
> -(within xen/) directories.  Which may in turn require some care if any
> -new top-level directories were to be added.  Rule of thumb: Whenever
> -adding a new subdirectory, check the rules to prevent any potential
> -collisions.
> +A good choice of guard is one that wont become stale if the
> +driver/subsystem/etc is shuffled around the source tree.
>  
>  Emacs local variables
>  ---------------------
> -- 
> 2.34.1
> 
--8323329-313421745-1747435043=:145034--


From xen-devel-bounces@lists.xenproject.org Fri May 16 22:40:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 22:40:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987618.1372808 (Exim 4.92)
	(envelope-from )
	id 1uG3io-0004ZR-Vt; Fri, 16 May 2025 22:40:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987618.1372808; Fri, 16 May 2025 22: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 1uG3io-0004ZK-T3; Fri, 16 May 2025 22:40:06 +0000
Received: by outflank-mailman (input) for mailman id 987618;
 Fri, 16 May 2025 22:40:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG3in-0004Oq-PH
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 22:40:05 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b380dd27-32a6-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 00:40:01 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id B715B49F77;
 Fri, 16 May 2025 22:39:59 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5667CC4CEE4;
 Fri, 16 May 2025 22:39: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" 
X-Inumbo-ID: b380dd27-32a6-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747435199;
	bh=hxKldC/IX0UM/Tbsk9wZtZvxsrn9kaAS4bw+7UafQf0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=bmVN9nwsreVnL/ILLgfsJA4ztBq08uIVjob+Pie+cR5aupMXqV7eKxXgFyoJeZTCq
	 BydBqH8dwIjZJXA65AvnoiWJR/bhk6y80ufoCrFtM0Xy1zZGOWQdPRG2QWsv+d9zRG
	 Ds/p5t/f/N6HfengEnXc+bhdyEfmSshZ+0Ugm6Dqk58PxICdWimRtGLAZoUqyCxnsg
	 OxpgULWRodA7Mvxh5LjphLauQTd1oTcqc7LUYycw3gbniwYCKVVAnRgj65a0ThlJki
	 3Mn9yh3akEWD3MskKVQtMN3LE2gfAM2On2IT+SYMDWNfAWgvERixGRGdnWxs5UpHUv
	 594MlM1kbyFlg==
Date: Fri, 16 May 2025 15:39:56 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , Julien Grall , 
    Volodymyr Babchuk , 
    Bertrand Marquis , 
    Michal Orzel , 
    Xen-devel 
Subject: Re: [PATCH 1/3] xen: Introduce asm inline and use it for BUG_FRAME
In-Reply-To: <01498be0-979a-4b89-a70b-050ddb5ad1b3@suse.com>
Message-ID: 
References: <20250515195549.3703017-1-andrew.cooper3@citrix.com> <20250515195549.3703017-2-andrew.cooper3@citrix.com> <01498be0-979a-4b89-a70b-050ddb5ad1b3@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 16 May 2025, Jan Beulich wrote:
> On 15.05.2025 21:55, Andrew Cooper wrote:
> > Compilers estimate the size of an asm() block for inlining purposes.
> > 
> > Constructs with embedded metadata (BUG_FRAME, ALTERNATIVE, EXTABLE, etc)
> > appear large, depsite often only being a handful of instructions.  asm
> > inline() overrides the estimation to identify the block as being small.
> > 
> > This has a substantial impact on inlining decisions, expected to be for the
> > better given that the compiler has a more accurate picture to work with.
> > 
> > No functional change.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Jan Beulich 

arm:

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Fri May 16 22:42:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 22:42:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987629.1372819 (Exim 4.92)
	(envelope-from )
	id 1uG3l2-0005L0-FW; Fri, 16 May 2025 22:42:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987629.1372819; Fri, 16 May 2025 22:42: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 1uG3l2-0005Kt-C9; Fri, 16 May 2025 22:42:24 +0000
Received: by outflank-mailman (input) for mailman id 987629;
 Fri, 16 May 2025 22:42:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG3l1-0005Kg-5Z
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 22:42:23 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 06b9bcc4-32a7-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 00:42:21 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id CDEFAA4E33C;
 Fri, 16 May 2025 22:42:19 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4575C4CEE4;
 Fri, 16 May 2025 22:42: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" 
X-Inumbo-ID: 06b9bcc4-32a7-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747435339;
	bh=h7TRh5YOYc20cuCVC3Z5C2pogxaTq61yqaFVXN+JmXY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=py+Pf7skE+dai9C4Ti55mzFOVsOod3pgD937X5GMEvdqwel/dFffxfiF82QOQqLzV
	 3vXVLdzvJZXgUDHqhLK1frPQLZrJORiMAsPT/C7mrFUMVqLwx2peTjPDTR/FXs+S7H
	 m39nwfOSPD6GCudmul/QhBDT1aFQ41M2r5O5SOmB494DpwHaJlWBURekeNAWyeyGY2
	 NVTL4jWk4P2xw8soq8i0lDPPGZLswH+3DPJ2eNmLxAKTAYUr+FiP/ERc2Cqu35nyvC
	 d8ypd3KvzAdqGsPFcxwu7c5N/a5qe06Yiy10sTTeCp+LkoOlk+s7RgJ9H0LEPYHiIA
	 bNpxiJBsNtOnw==
Date: Fri, 16 May 2025 15:42:14 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Xen-devel , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , Julien Grall , 
    Volodymyr Babchuk , 
    Bertrand Marquis , 
    Michal Orzel 
Subject: Re: [PATCH 3/3] ARM: Use asm_inline for ALTERNATIVE()
In-Reply-To: <20250515195549.3703017-4-andrew.cooper3@citrix.com>
Message-ID: 
References: <20250515195549.3703017-1-andrew.cooper3@citrix.com> <20250515195549.3703017-4-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-254656756-1747435338=:145034"

  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-254656756-1747435338=:145034
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 15 May 2025, Andrew Cooper wrote:
> ... when there really are only a few instructions in line.
> 
> In some cases, reformat to reduce left-hand margine space.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Stefano Stabellini 


> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Volodymyr Babchuk 
> CC: Bertrand Marquis 
> CC: Michal Orzel 
> 
> v2:
>  * New, split out of previous single patch
> ---
>  xen/arch/arm/include/asm/alternative.h    |  4 +--
>  xen/arch/arm/include/asm/arm64/flushtlb.h |  4 +--
>  xen/arch/arm/include/asm/arm64/io.h       | 43 ++++++++++++++---------
>  xen/arch/arm/include/asm/cpuerrata.h      |  8 ++---
>  xen/arch/arm/include/asm/cpufeature.h     |  8 ++---
>  xen/arch/arm/include/asm/page.h           | 12 ++++---
>  xen/arch/arm/include/asm/processor.h      |  7 ++--
>  xen/arch/arm/include/asm/sysregs.h        | 10 +++---
>  xen/arch/arm/mmu/p2m.c                    |  3 +-
>  9 files changed, 58 insertions(+), 41 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/alternative.h b/xen/arch/arm/include/asm/alternative.h
> index 22477d9497a3..1563f03a0f5a 100644
> --- a/xen/arch/arm/include/asm/alternative.h
> +++ b/xen/arch/arm/include/asm/alternative.h
> @@ -209,9 +209,9 @@ alternative_endif
>  #endif  /*  __ASSEMBLY__  */
>  
>  /*
> - * Usage: asm(ALTERNATIVE(oldinstr, newinstr, feature));
> + * Usage: asm_inline (ALTERNATIVE(oldinstr, newinstr, feature));
>   *
> - * Usage: asm(ALTERNATIVE(oldinstr, newinstr, feature, CONFIG_FOO));
> + * Usage: asm_inline (ALTERNATIVE(oldinstr, newinstr, feature, CONFIG_FOO));
>   * N.B. If CONFIG_FOO is specified, but not selected, the whole block
>   *      will be omitted, including oldinstr.
>   */
> diff --git a/xen/arch/arm/include/asm/arm64/flushtlb.h b/xen/arch/arm/include/asm/arm64/flushtlb.h
> index 45642201d147..3b99c11b50d1 100644
> --- a/xen/arch/arm/include/asm/arm64/flushtlb.h
> +++ b/xen/arch/arm/include/asm/arm64/flushtlb.h
> @@ -31,7 +31,7 @@
>  #define TLB_HELPER(name, tlbop, sh)              \
>  static inline void name(void)                    \
>  {                                                \
> -    asm volatile(                                \
> +    asm_inline volatile (                        \
>          "dsb  "  # sh  "st;"                     \
>          "tlbi "  # tlbop  ";"                    \
>          ALTERNATIVE(                             \
> @@ -55,7 +55,7 @@ static inline void name(void)                    \
>  #define TLB_HELPER_VA(name, tlbop)               \
>  static inline void name(vaddr_t va)              \
>  {                                                \
> -    asm volatile(                                \
> +    asm_inline volatile (                        \
>          "tlbi "  # tlbop  ", %0;"                \
>          ALTERNATIVE(                             \
>              "nop; nop;",                         \
> diff --git a/xen/arch/arm/include/asm/arm64/io.h b/xen/arch/arm/include/asm/arm64/io.h
> index 7d5959877759..ac90b729c44d 100644
> --- a/xen/arch/arm/include/asm/arm64/io.h
> +++ b/xen/arch/arm/include/asm/arm64/io.h
> @@ -51,40 +51,51 @@ static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
>  static inline u8 __raw_readb(const volatile void __iomem *addr)
>  {
>          u8 val;
> -        asm volatile(ALTERNATIVE("ldrb %w0, [%1]",
> -                                 "ldarb %w0, [%1]",
> -                                 ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
> -                     : "=r" (val) : "r" (addr));
> +
> +        asm_inline volatile (
> +            ALTERNATIVE("ldrb %w0, [%1]",
> +                        "ldarb %w0, [%1]",
> +                        ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
> +            : "=r" (val) : "r" (addr) );
> +
>          return val;
>  }
>  
>  static inline u16 __raw_readw(const volatile void __iomem *addr)
>  {
>          u16 val;
> -        asm volatile(ALTERNATIVE("ldrh %w0, [%1]",
> -                                 "ldarh %w0, [%1]",
> -                                 ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
> -                     : "=r" (val) : "r" (addr));
> +        asm_inline volatile (
> +            ALTERNATIVE("ldrh %w0, [%1]",
> +                        "ldarh %w0, [%1]",
> +                        ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
> +            : "=r" (val) : "r" (addr) );
> +
>          return val;
>  }
>  
>  static inline u32 __raw_readl(const volatile void __iomem *addr)
>  {
>          u32 val;
> -        asm volatile(ALTERNATIVE("ldr %w0, [%1]",
> -                                 "ldar %w0, [%1]",
> -                                 ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
> -                     : "=r" (val) : "r" (addr));
> +
> +        asm_inline volatile (
> +            ALTERNATIVE("ldr %w0, [%1]",
> +                        "ldar %w0, [%1]",
> +                        ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
> +            : "=r" (val) : "r" (addr) );
> +
>          return val;
>  }
>  
>  static inline u64 __raw_readq(const volatile void __iomem *addr)
>  {
>          u64 val;
> -        asm volatile(ALTERNATIVE("ldr %0, [%1]",
> -                                 "ldar %0, [%1]",
> -                                 ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
> -                     : "=r" (val) : "r" (addr));
> +
> +        asm_inline volatile (
> +            ALTERNATIVE("ldr %0, [%1]",
> +                        "ldar %0, [%1]",
> +                        ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
> +            : "=r" (val) : "r" (addr) );
> +
>          return val;
>  }
>  
> diff --git a/xen/arch/arm/include/asm/cpuerrata.h b/xen/arch/arm/include/asm/cpuerrata.h
> index 8d7e7b9375bd..1799a16d7e7f 100644
> --- a/xen/arch/arm/include/asm/cpuerrata.h
> +++ b/xen/arch/arm/include/asm/cpuerrata.h
> @@ -16,10 +16,10 @@ static inline bool check_workaround_##erratum(void)             \
>      {                                                           \
>          register_t ret;                                         \
>                                                                  \
> -        asm volatile (ALTERNATIVE("mov %0, #0",                 \
> -                                  "mov %0, #1",                 \
> -                                  feature)                      \
> -                      : "=r" (ret));                            \
> +        asm_inline volatile (                                   \
> +            ALTERNATIVE("mov %0, #0",                           \
> +                        "mov %0, #1", feature)                  \
> +            : "=r" (ret) );                                     \
>                                                                  \
>          return unlikely(ret);                                   \
>      }                                                           \
> diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
> index 50297e53d90e..b6df18801166 100644
> --- a/xen/arch/arm/include/asm/cpufeature.h
> +++ b/xen/arch/arm/include/asm/cpufeature.h
> @@ -102,10 +102,10 @@ static inline bool cpus_have_cap(unsigned int num)
>  #define cpus_have_const_cap(num) ({                 \
>          register_t __ret;                           \
>                                                      \
> -        asm volatile (ALTERNATIVE("mov %0, #0",     \
> -                                  "mov %0, #1",     \
> -                                  num)              \
> -                      : "=r" (__ret));              \
> +        asm_inline volatile (                       \
> +            ALTERNATIVE("mov %0, #0",               \
> +                        "mov %0, #1", num)          \
> +            : "=r" (__ret) );                       \
>                                                      \
>          unlikely(__ret);                            \
>          })
> diff --git a/xen/arch/arm/include/asm/page.h b/xen/arch/arm/include/asm/page.h
> index 69f817d1e68a..27bc96b9f401 100644
> --- a/xen/arch/arm/include/asm/page.h
> +++ b/xen/arch/arm/include/asm/page.h
> @@ -176,7 +176,8 @@ static inline int invalidate_dcache_va_range(const void *p, unsigned long size)
>      {
>          size -= dcache_line_bytes - ((uintptr_t)p & cacheline_mask);
>          p = (void *)((uintptr_t)p & ~cacheline_mask);
> -        asm volatile (__clean_and_invalidate_dcache_one(0) : : "r" (p));
> +        asm_inline volatile (
> +            __clean_and_invalidate_dcache_one(0) :: "r" (p) );
>          p += dcache_line_bytes;
>      }
>  
> @@ -185,7 +186,8 @@ static inline int invalidate_dcache_va_range(const void *p, unsigned long size)
>          asm volatile (__invalidate_dcache_one(0) : : "r" (p + idx));
>  
>      if ( size > 0 )
> -        asm volatile (__clean_and_invalidate_dcache_one(0) : : "r" (p + idx));
> +        asm_inline volatile (
> +            __clean_and_invalidate_dcache_one(0) :: "r" (p + idx) );
>  
>      dsb(sy);           /* So we know the flushes happen before continuing */
>  
> @@ -209,7 +211,7 @@ static inline int clean_dcache_va_range(const void *p, unsigned long size)
>      p = (void *)((uintptr_t)p & ~cacheline_mask);
>      for ( ; size >= dcache_line_bytes;
>              idx += dcache_line_bytes, size -= dcache_line_bytes )
> -        asm volatile (__clean_dcache_one(0) : : "r" (p + idx));
> +        asm_inline volatile ( __clean_dcache_one(0) : : "r" (p + idx) );
>      dsb(sy);           /* So we know the flushes happen before continuing */
>      /* ARM callers assume that dcache_* functions cannot fail. */
>      return 0;
> @@ -247,7 +249,7 @@ static inline int clean_and_invalidate_dcache_va_range
>      if ( sizeof(x) > MIN_CACHELINE_BYTES || sizeof(x) > alignof(x) )    \
>          clean_dcache_va_range(_p, sizeof(x));                           \
>      else                                                                \
> -        asm volatile (                                                  \
> +        asm_inline volatile (                                           \
>              "dsb sy;"   /* Finish all earlier writes */                 \
>              __clean_dcache_one(0)                                       \
>              "dsb sy;"   /* Finish flush before continuing */            \
> @@ -259,7 +261,7 @@ static inline int clean_and_invalidate_dcache_va_range
>      if ( sizeof(x) > MIN_CACHELINE_BYTES || sizeof(x) > alignof(x) )    \
>          clean_and_invalidate_dcache_va_range(_p, sizeof(x));            \
>      else                                                                \
> -        asm volatile (                                                  \
> +        asm_inline volatile (                                           \
>              "dsb sy;"   /* Finish all earlier writes */                 \
>              __clean_and_invalidate_dcache_one(0)                        \
>              "dsb sy;"   /* Finish flush before continuing */            \
> diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
> index 60b587db697f..9cbc4f911061 100644
> --- a/xen/arch/arm/include/asm/processor.h
> +++ b/xen/arch/arm/include/asm/processor.h
> @@ -607,9 +607,10 @@ register_t get_default_cptr_flags(void);
>  #define SYNCHRONIZE_SERROR(feat)                                  \
>      do {                                                          \
>          ASSERT(local_abort_is_enabled());                         \
> -        asm volatile(ALTERNATIVE("dsb sy; isb",                   \
> -                                 "nop; nop", feat)                \
> -                                 : : : "memory");                 \
> +        asm_inline volatile (                                     \
> +            ALTERNATIVE("dsb sy; isb",                            \
> +                        "nop; nop", feat)                         \
> +            ::: "memory" );                                       \
>      } while (0)
>  
>  /*
> diff --git a/xen/arch/arm/include/asm/sysregs.h b/xen/arch/arm/include/asm/sysregs.h
> index 61e30c9e517c..5c2d362be3d8 100644
> --- a/xen/arch/arm/include/asm/sysregs.h
> +++ b/xen/arch/arm/include/asm/sysregs.h
> @@ -22,11 +22,13 @@ static inline register_t read_sysreg_par(void)
>       * DMB SY before and after accessing it, as part of the workaround for the
>       * errata 1508412.
>       */
> -    asm volatile(ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412,
> -                 CONFIG_ARM64_ERRATUM_1508412));
> +    asm_inline volatile (
> +        ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412,
> +                    CONFIG_ARM64_ERRATUM_1508412) );
>      par_el1 = READ_SYSREG64(PAR_EL1);
> -    asm volatile(ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412,
> -                 CONFIG_ARM64_ERRATUM_1508412));
> +    asm_inline volatile (
> +        ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412,
> +                    CONFIG_ARM64_ERRATUM_1508412) );
>  
>      return par_el1;
>  }
> diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
> index 7642dbc7c55b..d96078f547d5 100644
> --- a/xen/arch/arm/mmu/p2m.c
> +++ b/xen/arch/arm/mmu/p2m.c
> @@ -228,7 +228,8 @@ void p2m_restore_state(struct vcpu *n)
>       * registers associated to EL1/EL0 translations regime have been
>       * synchronized.
>       */
> -    asm volatile(ALTERNATIVE("nop", "isb", ARM64_WORKAROUND_AT_SPECULATE));
> +    asm_inline volatile (
> +        ALTERNATIVE("nop", "isb", ARM64_WORKAROUND_AT_SPECULATE) );
>      WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
>  
>      last_vcpu_ran = &p2m->last_vcpu_ran[smp_processor_id()];
> -- 
> 2.39.5
> 
--8323329-254656756-1747435338=:145034--


From xen-devel-bounces@lists.xenproject.org Fri May 16 22:50:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 22:50:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987644.1372853 (Exim 4.92)
	(envelope-from )
	id 1uG3t9-0007AX-F5; Fri, 16 May 2025 22:50:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987644.1372853; Fri, 16 May 2025 22:50:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uG3t9-0007AQ-CN; Fri, 16 May 2025 22:50:47 +0000
Received: by outflank-mailman (input) for mailman id 987644;
 Fri, 16 May 2025 22:50:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG3t8-000794-Ky
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 22:50:46 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 310a87d4-32a8-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 00:50:41 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 5D5FBA4E387;
 Fri, 16 May 2025 22:50:40 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC5BEC4CEE4;
 Fri, 16 May 2025 22: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" 
X-Inumbo-ID: 310a87d4-32a8-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747435840;
	bh=EaMlxl3QaT07s2kYdSaYMftFi15jETPhARP9rMmRsaY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=oQtK1pgdcXdYAXK/zKI1pzq6zR/CBqfBayQKMLvwLFR7OQ7YPWjUsblTmNlI8O5j+
	 ohBpIhSU6AcWCiI0tJStnTVXmwweJg1fa9X4PB3HedgHGQNdxHdx6LyvJTN1/zwmIJ
	 Hzi2flRJrzEWcGc22OqF2qgaEf0qL7uds9c2xN9jYstMRgtwqPMYDGGmQf65D86PJx
	 pwT39JMTsAI3p15YnUKjnFMWaZv27cPZ50Diy0Dp+ksSKHFaJDUnk8iEb5yIN3WwhE
	 QrG7A48R1WiSa8FePorSVsHErFm61jEG9XlJGb0Wce3Jbb1DxRgMRVWydN/U8sfUAT
	 UT7U2uqoLLRMw==
Date: Fri, 16 May 2025 15:50:36 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmkhn@proton.me
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com
Subject: Re: [PATCH v4 1/3] xen/console: cleanup conring management
In-Reply-To: <20250516013508.1144162-2-dmukhin@ford.com>
Message-ID: 
References: <20250516013508.1144162-1-dmukhin@ford.com> <20250516013508.1144162-2-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 16 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Move conring tasklet code close to conring definitions in the console driver
> and rename conring tasklet variables by adding conring_ prefix for better
> readability.
> 
> No functional change.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


> ---
> Changes since v3:
> - dropped 3rd argument from conring_puts()
> ---
>  xen/drivers/char/console.c | 28 ++++++++++++++--------------
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index c3150fbdb7..b4757844e6 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -325,6 +325,16 @@ static void cf_check do_dec_thresh(unsigned char key, bool unused)
>   * ********************************************************
>   */
>  
> +static void cf_check conring_notify(void *unused)
> +{
> +    send_global_virq(VIRQ_CON_RING);
> +}
> +
> +static DECLARE_SOFTIRQ_TASKLET(conring_tasklet, conring_notify, NULL);
> +
> +/* NB: Do not send conring VIRQs during panic. */
> +static bool conring_no_notify;
> +
>  static void conring_puts(const char *str, size_t len)
>  {
>      ASSERT(rspin_is_locked(&console_lock));
> @@ -594,13 +604,6 @@ static void cf_check serial_rx(char c)
>      __serial_rx(c);
>  }
>  
> -static void cf_check notify_dom0_con_ring(void *unused)
> -{
> -    send_global_virq(VIRQ_CON_RING);
> -}
> -static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
> -                               notify_dom0_con_ring, NULL);
> -
>  #ifdef CONFIG_X86
>  static inline void xen_console_write_debug_port(const char *buf, size_t len)
>  {
> @@ -650,7 +653,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>              if ( opt_console_to_ring )
>              {
>                  conring_puts(kbuf, kcount);
> -                tasklet_schedule(¬ify_dom0_con_ring_tasklet);
> +                tasklet_schedule(&conring_tasklet);
>              }
>  
>              nrspin_unlock_irq(&console_lock);
> @@ -753,8 +756,6 @@ long do_console_io(
>   * *****************************************************
>   */
>  
> -static bool console_locks_busted;
> -
>  static void __putstr(const char *str)
>  {
>      size_t len = strlen(str);
> @@ -775,9 +776,8 @@ static void __putstr(const char *str)
>  #endif
>  
>      conring_puts(str, len);
> -
> -    if ( !console_locks_busted )
> -        tasklet_schedule(¬ify_dom0_con_ring_tasklet);
> +    if ( !conring_no_notify )
> +        tasklet_schedule(&conring_tasklet);
>  }
>  
>  static int printk_prefix_check(char *p, char **pp)
> @@ -1171,7 +1171,7 @@ void console_force_unlock(void)
>      spin_debug_disable();
>      rspin_lock_init(&console_lock);
>      serial_force_unlock(sercon_handle);
> -    console_locks_busted = 1;
> +    conring_no_notify = true;
>      console_start_sync();
>  }
>  
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri May 16 22:50:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 22:50:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987645.1372863 (Exim 4.92)
	(envelope-from )
	id 1uG3tD-0007Oy-Mt; Fri, 16 May 2025 22:50:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987645.1372863; Fri, 16 May 2025 22:50:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uG3tD-0007Or-JF; Fri, 16 May 2025 22:50:51 +0000
Received: by outflank-mailman (input) for mailman id 987645;
 Fri, 16 May 2025 22:50:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG3tC-0007OD-3e
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 22:50:50 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 35b1028f-32a8-11f0-9eb6-5ba50f476ded;
 Sat, 17 May 2025 00:50:48 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-442f5b3c710so19554495e9.1
 for ; Fri, 16 May 2025 15:50:48 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442f33690f0sm119572855e9.1.2025.05.16.15.50.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 15:50: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" 
X-Inumbo-ID: 35b1028f-32a8-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747435848; x=1748040648; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=LSOyo5iWZVzBT+iqi2WHlb33LaJUvkDHoNdDgAEM24c=;
        b=AgJn6hMMlZKlhbNKpuHzMDZ9QUNvGKEewHxvZP7IYyOsmQ0HUr1yrRo0ruHAdDZ10S
         /T7KFkl0aAdPdjguX4WTpdaESoPR0Juxuk9oXO4P4A7l+Hdyp8rtJitjTpEPK29aameG
         EKdrJw1kzj9zQ3iVD9oqFM3iJ4Js0uGGJfkFY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747435848; x=1748040648;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LSOyo5iWZVzBT+iqi2WHlb33LaJUvkDHoNdDgAEM24c=;
        b=L8H9RqYQzYSfY+1bi9sGVST6wFuWc6fcj+NRy61EJt6q3MG7LtuFA5G6aUILrJR/2f
         lidYX0kWOBxcfq8abyfTnrrlsU/zkuA0AgVSVwM/DKDAYONio+AbBQsVlmhKptVCinwD
         0xj4CMaMoYBcyBfHRCUuKHMMhmRAO596UZcMvca8NwIBUIgn1p4s+mZ0UVYax/QtZoaq
         d6zjsVcwITmdgWc7uiMLH85aa1n2zWtkaQJDjqB6BLiF7oKyHWoeL4yQtLR+qg2sVPgV
         /2mrqYSirRwFHvbJZJb0wYCLyrElMIJ8JE1Xm7YHzgRq4cUIEZNJ84qoXL5IS/HOywUi
         7WsQ==
X-Gm-Message-State: AOJu0Yyh8cjMO5C+vcvxsyVv1GENxydPu/Rui9uByO+2u8Op17ylvnmw
	CcwIgk5cgR/wLyMTK+lGKCvONEBKb53ZkZ661R5ZYwxAigIj2Y/kx04pckIHBlcTiBJxvGxwhFB
	HJqaD
X-Gm-Gg: ASbGncsdlVQyCg4Qp1ZuB1oMt3eG94c2dYi2S6HZFxY+SDfmlyhfoN4PEEmcZDNcB4F
	LFOOxM9zDzg+mIeJsD+ypl5f1wvlO1sDbzNQUjreWJ4181lUN4aZe0mj2nxswKXxnIB00k+pbmG
	FAr6q87maH/R5FIwUI84IuR8NaKFF6p50IJ4fy93a58jKAy6hnZXf18zvZ1KdlWJuHvjt5BA43t
	IMSVpSa4rtr80sh2bF+/E0AZH7cGnjndskiIJwAgd+bvxHcxSdYxNIcn3Uh4/9Vki2CE7FWI0GG
	8hCji7lJXFiwWaXiuJFX9/MID05nVbYvmQK3hDuyPMtdJ9BjOprUcxRydJwQyscmy2vF+9cznEA
	ys5r1hSLCab/cRd9P
X-Google-Smtp-Source: AGHT+IERSOLKISk//LWo9nDxiA9Y0C2ZMvIzZmtB+xIqvyUmN28GQe8MxU0o8/PmWx0COmTW5aRQEw==
X-Received: by 2002:a05:600c:34d4:b0:442:e0e0:250 with SMTP id 5b1f17b1804b1-442fd67200emr53108385e9.29.1747435847747;
        Fri, 16 May 2025 15:50:47 -0700 (PDT)
Message-ID: <54b07cf2-1a7a-429b-820e-945d82d9830b@citrix.com>
Date: Fri, 16 May 2025 23:50:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] x86/vlapic: Fix handling of writes to APIC_ESR
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <20250303185352.86499-1-andrew.cooper3@citrix.com>
 <20250303185352.86499-2-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: <20250303185352.86499-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03/03/2025 6:53 pm, Andrew Cooper wrote:
> Xen currently presents APIC_ESR to guests as a simple read/write register.

This turns out not to be true.

I'm trying to finish off the XSA-462 XTF PoC, and my detection for this
case wasn't working.

It turns out that there was no write path for APIC_ESR ever wired up
(i.e. I got my analysis wrong about how vlapic_reg_write() behaved with
no APIC_ESR case).

Errors could only ever accumulate, and could never be cleared.

The behaviour following this patch is correct, but the commit message
describing the prior behaviour is not.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 16 23:00:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:00:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987669.1372872 (Exim 4.92)
	(envelope-from )
	id 1uG42j-00011l-MR; Fri, 16 May 2025 23:00:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987669.1372872; Fri, 16 May 2025 23:00: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 1uG42j-00011e-Jo; Fri, 16 May 2025 23:00:41 +0000
Received: by outflank-mailman (input) for mailman id 987669;
 Fri, 16 May 2025 23:00:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG42h-0000zu-KF
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:00:39 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 94b46d0e-32a9-11f0-9eb6-5ba50f476ded;
 Sat, 17 May 2025 01:00:38 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 1C138A4E493;
 Fri, 16 May 2025 23:00:37 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66F14C4CEE4;
 Fri, 16 May 2025 23:00: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" 
X-Inumbo-ID: 94b46d0e-32a9-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747436436;
	bh=sm+D6mlO34imKeVXRJyE8Im9/JUApQb6eEdbreYNC8E=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=OyiBNednOXRkNbT22I/DyQ4ZU+9YhsFKh/AgbWzkBnSNUe5dv3Ac8q/icWeucqf26
	 uW4duekP7LxeWoHt2gwhKT1DR19NPi7uYmaPoJDsis3DGg3dNVWcQXoLMVvjWluHF8
	 i2Adk5bLetHJP7glNUFxKFS6la60YJu+uLybogJdL0Vgg4L2BkrzodG4SZtIQBGqUU
	 OQg3+1oMZI/fuFCFpcIHvxb6G0qnTyivBST6nlNoLvWK7VWQxEBht5epmNpF1H8eMp
	 5Mt6jNfmImCd4HpBxGT8V0AjRz1tS6mSYbUree0nLE22WsNAQ1WRkbjEgc5PFLMird
	 Wp/7JGu5DR2Qw==
Date: Fri, 16 May 2025 16:00:33 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmkhn@proton.me
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com
Subject: Re: [PATCH v3 2/3] xen/console: introduce console_puts()
In-Reply-To: <20250504181423.2302345-3-dmukhin@ford.com>
Message-ID: 
References: <20250504181423.2302345-1-dmukhin@ford.com> <20250504181423.2302345-3-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Sun, 4 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> guest_console_write() duplicates the code from __putstr(), eliminate code
> duplication.
> 
> Introduce console_puts() for writing a buffer to console devices.
> 
> Also, introduce internal console flags to control which console devices
> should be used.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


> ---
> Changes since v2:
> - added CONSOLE_RING_VIRQ flag
> - dropped locking changes
> ---
>  xen/drivers/char/console.c | 123 ++++++++++++++++++++++++-------------
>  1 file changed, 79 insertions(+), 44 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 20504060cb..b788427aa5 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -41,6 +41,28 @@
>  #include 
>  #endif
>  
> +/* Internal console flags. */
> +enum {
> +    CONSOLE_SERIAL          = BIT(0, U),    /* Use serial device. */
> +    CONSOLE_PV              = BIT(1, U),    /* Use PV console. */
> +    CONSOLE_VIDEO           = BIT(2, U),    /* Use video device. */
> +    CONSOLE_DEBUG           = BIT(3, U),    /* Use debug device. */
> +    CONSOLE_RING            = BIT(4, U),    /* Use console ring. */
> +    CONSOLE_RING_VIRQ       = BIT(5, U),    /* Use console ring VIRQ. */
> +
> +    /* Default console flags. */
> +    CONSOLE_DEFAULT         = CONSOLE_SERIAL |
> +                              CONSOLE_PV |
> +                              CONSOLE_VIDEO |
> +                              CONSOLE_RING_VIRQ |
> +                              CONSOLE_DEBUG,
> +
> +    /* Use all known console devices. */
> +    CONSOLE_ALL             = CONSOLE_DEFAULT | CONSOLE_RING,
> +};
> +
> +static void console_puts(const char *str, size_t len, unsigned int flags);
> +
>  /* console: comma-separated list of console outputs. */
>  static char __initdata opt_console[30] = OPT_CONSOLE_STR;
>  string_param("console", opt_console);
> @@ -431,9 +453,6 @@ void console_serial_puts(const char *s, size_t nr)
>          serial_steal_fn(s, nr);
>      else
>          serial_puts(sercon_handle, s, nr);
> -
> -    /* Copy all serial output into PV console */
> -    pv_console_puts(s, nr);
>  }
>  
>  static void cf_check dump_console_ring_key(unsigned char key)
> @@ -467,8 +486,7 @@ static void cf_check dump_console_ring_key(unsigned char key)
>          c += len;
>      }
>  
> -    console_serial_puts(buf, sofar);
> -    video_puts(buf, sofar);
> +    console_puts(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
>  
>      free_xenheap_pages(buf, order);
>  }
> @@ -617,11 +635,66 @@ static inline void xen_console_write_debug_port(const char *buf, size_t len)
>  }
>  #endif
>  
> +static inline void console_debug_puts(const char *str, size_t len)
> +{
> +#ifdef CONFIG_X86
> +    if ( opt_console_xen )
> +    {
> +        if ( xen_guest )
> +            xen_hypercall_console_write(str, len);
> +        else
> +            xen_console_write_debug_port(str, len);
> +    }
> +#endif
> +}
> +
> +/*
> + * Write buffer to all enabled console devices.
> + *
> + * That will handle all possible scenarios working w/ console
> + * - physical console (serial console, VGA console (x86 only));
> + * - PV console;
> + * - debug console (x86 only): debug I/O port or __HYPERVISOR_console_io
> + *   hypercall;
> + * - console ring.
> + */
> +static void console_puts(const char *str, size_t len, unsigned int flags)
> +{
> +    if ( flags & CONSOLE_SERIAL )
> +        console_serial_puts(str, len);
> +
> +    if ( flags & CONSOLE_PV )
> +        pv_console_puts(str, len);
> +
> +    if ( flags & CONSOLE_VIDEO )
> +        video_puts(str, len);
> +
> +    if ( flags & CONSOLE_DEBUG )
> +        console_debug_puts(str, len);
> +
> +    if ( flags & CONSOLE_RING )
> +        conring_puts(str, len, !!(flags & CONSOLE_RING_VIRQ) );
> +}
> +
> +static inline void __putstr(const char *str)
> +{
> +    unsigned int flags = CONSOLE_ALL;
> +
> +    ASSERT(rspin_is_locked(&console_lock));
> +
> +    if ( conring_no_notify )
> +        flags &= ~CONSOLE_RING_VIRQ;
> +
> +    console_puts(str, strlen(str), flags);
> +}
> +
>  static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>                                  unsigned int count)
>  {
>      char kbuf[128];
>      unsigned int kcount = 0;
> +    unsigned int flags = opt_console_to_ring
> +                         ? CONSOLE_ALL : CONSOLE_DEFAULT;
>      struct domain *cd = current->domain;
>  
>      while ( count > 0 )
> @@ -639,23 +712,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>          {
>              /* Use direct console output as it could be interactive */
>              nrspin_lock_irq(&console_lock);
> -
> -            console_serial_puts(kbuf, kcount);
> -            video_puts(kbuf, kcount);
> -
> -#ifdef CONFIG_X86
> -            if ( opt_console_xen )
> -            {
> -                if ( xen_guest )
> -                    xen_hypercall_console_write(kbuf, kcount);
> -                else
> -                    xen_console_write_debug_port(kbuf, kcount);
> -            }
> -#endif
> -
> -            if ( opt_console_to_ring )
> -                conring_puts(kbuf, kcount, true);
> -
> +            console_puts(kbuf, kcount, flags);
>              nrspin_unlock_irq(&console_lock);
>          }
>          else
> @@ -756,28 +813,6 @@ long do_console_io(
>   * *****************************************************
>   */
>  
> -static void __putstr(const char *str)
> -{
> -    size_t len = strlen(str);
> -
> -    ASSERT(rspin_is_locked(&console_lock));
> -
> -    console_serial_puts(str, len);
> -    video_puts(str, len);
> -
> -#ifdef CONFIG_X86
> -    if ( opt_console_xen )
> -    {
> -        if ( xen_guest )
> -            xen_hypercall_console_write(str, len);
> -        else
> -            xen_console_write_debug_port(str, len);
> -    }
> -#endif
> -
> -    conring_puts(str, len, !conring_no_notify);
> -}
> -
>  static int printk_prefix_check(char *p, char **pp)
>  {
>      int loglvl = -1;
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri May 16 23:02:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:02:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987679.1372883 (Exim 4.92)
	(envelope-from )
	id 1uG44Q-0001j9-1o; Fri, 16 May 2025 23:02:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987679.1372883; Fri, 16 May 2025 23:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uG44P-0001j2-UA; Fri, 16 May 2025 23:02:25 +0000
Received: by outflank-mailman (input) for mailman id 987679;
 Fri, 16 May 2025 23:02:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG44P-0001iw-J2
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:02:25 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cd54d401-32a9-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 01:02:13 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 444665C568C;
 Fri, 16 May 2025 22:59:54 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC5CCC4CEE4;
 Fri, 16 May 2025 23:02: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" 
X-Inumbo-ID: cd54d401-32a9-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747436531;
	bh=tDBjQu8+8IotWypS/H+w6jFfC9gZHy43+yrhmUAxQ08=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=hQNf0vcy0Dmpsd1/wBhb1MGEPZUX3DH8sI3pBNBpXd+cEdqae7GlRL/iWNqh10+lM
	 GJYh/jr1Jm0N5ehkGsyPfaccJplV5Juz4IuREh5c67d9ukD4hcquczFvvkkmORPWcr
	 hCueOOm2Yg8R2dwq8InQdWjujYBByLsWjhpFK5GYzh8mB21c4Rb0MNVo6bOJlQhBMq
	 qxtEAr6DiJDPBj6hXAMLn3e+zHxMMRG7jBBNRP/NSY7JANSF94mj3/Hwjzp0AsUcjA
	 XwsIhywUDOMsdT7emWg0p404tIt00+C3OXuStliREOtGuOb9LjxKI9oNuD8nciJ5HF
	 fHPmaSpDwIqCw==
Date: Fri, 16 May 2025 16:02:07 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stefano Stabellini 
cc: dmkhn@proton.me, xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com
Subject: Re: [PATCH v3 2/3] xen/console: introduce console_puts()
In-Reply-To: 
Message-ID: 
References: <20250504181423.2302345-1-dmukhin@ford.com> <20250504181423.2302345-3-dmukhin@ford.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 16 May 2025, Stefano Stabellini wrote:
> On Sun, 4 May 2025, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> > 
> > guest_console_write() duplicates the code from __putstr(), eliminate code
> > duplication.
> > 
> > Introduce console_puts() for writing a buffer to console devices.
> > 
> > Also, introduce internal console flags to control which console devices
> > should be used.
> > 
> > No functional change intended.
> > 
> > Signed-off-by: Denis Mukhin 
> 
> Reviewed-by: Stefano Stabellini 

Sorry I replied to the wrong version, I meant to ack v4.


From xen-devel-bounces@lists.xenproject.org Fri May 16 23:02:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:02:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987683.1372894 (Exim 4.92)
	(envelope-from )
	id 1uG44o-0002An-A0; Fri, 16 May 2025 23:02:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987683.1372894; Fri, 16 May 2025 23: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 1uG44o-0002Ae-5G; Fri, 16 May 2025 23:02:50 +0000
Received: by outflank-mailman (input) for mailman id 987683;
 Fri, 16 May 2025 23:02:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG44n-0001yQ-GG
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:02:49 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e2a51b98-32a9-11f0-9eb6-5ba50f476ded;
 Sat, 17 May 2025 01:02:48 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id ECC6DA4E3A0;
 Fri, 16 May 2025 23:02:47 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28325C4CEE4;
 Fri, 16 May 2025 23:02: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" 
X-Inumbo-ID: e2a51b98-32a9-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747436567;
	bh=0q5vKVy/f59Np49UUn8XheEyTrFnrZAHgxEm7gLkGW8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=L7re55XFsrq+PO4oM5dklPQPXeuiDfc7iSk0K3FVbFchaOn5IhvBWfxWIE8QTKUy7
	 72Y42B1YoK7SHuASwDrZw+QExXnaiv2rGIbp0z1evQKkgOf4OodLSOHz9/2otyshME
	 pQBqYrO8uhWqXNTRCNWrAROhA2ODJiICYvOGBseq1qwUG9Vpog92tdPaG6QbGXh1uj
	 eDOTVJryXToZPCesnaIZwIMtPsbuPTIKgTpR4kQVuxTQ+TCM54cC6ni2V6SRrwbaUX
	 fhsI5ZU016P7kxJydbVcOZBvznrasSYfMh7GyS7XDUe4X461MefDGgUsmVyvJPnD1v
	 qA5xWAVhFzNow==
Date: Fri, 16 May 2025 16:02:44 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmkhn@proton.me
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com
Subject: Re: [PATCH v4 2/3] xen/console: introduce console_send()
In-Reply-To: <20250516013508.1144162-3-dmukhin@ford.com>
Message-ID: 
References: <20250516013508.1144162-1-dmukhin@ford.com> <20250516013508.1144162-3-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 16 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> guest_console_write() duplicates the code from __putstr(), eliminate code
> duplication.
> 
> Introduce console_send() for sending a message on console devices.
> 
> Also, introduce internal console flags to control which console devices
> should be used.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


> ---
> Changes since v3:
> - renamed console_puts() to console_send()
> ---
>  xen/drivers/char/console.c | 131 +++++++++++++++++++++++--------------
>  1 file changed, 82 insertions(+), 49 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index b4757844e6..3420e9630a 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -41,6 +41,28 @@
>  #include 
>  #endif
>  
> +/* Internal console flags. */
> +enum {
> +    CONSOLE_SERIAL          = BIT(0, U),    /* Use serial device. */
> +    CONSOLE_PV              = BIT(1, U),    /* Use PV console. */
> +    CONSOLE_VIDEO           = BIT(2, U),    /* Use video device. */
> +    CONSOLE_DEBUG           = BIT(3, U),    /* Use debug device. */
> +    CONSOLE_RING            = BIT(4, U),    /* Use console ring. */
> +    CONSOLE_RING_VIRQ       = BIT(5, U),    /* Use console ring VIRQ. */
> +
> +    /* Default console flags. */
> +    CONSOLE_DEFAULT         = CONSOLE_SERIAL |
> +                              CONSOLE_PV |
> +                              CONSOLE_VIDEO |
> +                              CONSOLE_RING_VIRQ |
> +                              CONSOLE_DEBUG,
> +
> +    /* Use all known console devices. */
> +    CONSOLE_ALL             = CONSOLE_DEFAULT | CONSOLE_RING,
> +};
> +
> +static void console_send(const char *str, size_t len, unsigned int flags);
> +
>  /* console: comma-separated list of console outputs. */
>  static char __initdata opt_console[30] = OPT_CONSOLE_STR;
>  string_param("console", opt_console);
> @@ -428,9 +450,6 @@ void console_serial_puts(const char *s, size_t nr)
>          serial_steal_fn(s, nr);
>      else
>          serial_puts(sercon_handle, s, nr);
> -
> -    /* Copy all serial output into PV console */
> -    pv_console_puts(s, nr);
>  }
>  
>  static void cf_check dump_console_ring_key(unsigned char key)
> @@ -464,8 +483,7 @@ static void cf_check dump_console_ring_key(unsigned char key)
>          c += len;
>      }
>  
> -    console_serial_puts(buf, sofar);
> -    video_puts(buf, sofar);
> +    console_send(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
>  
>      free_xenheap_pages(buf, order);
>  }
> @@ -614,11 +632,69 @@ static inline void xen_console_write_debug_port(const char *buf, size_t len)
>  }
>  #endif
>  
> +static inline void console_debug_puts(const char *str, size_t len)
> +{
> +#ifdef CONFIG_X86
> +    if ( opt_console_xen )
> +    {
> +        if ( xen_guest )
> +            xen_hypercall_console_write(str, len);
> +        else
> +            xen_console_write_debug_port(str, len);
> +    }
> +#endif
> +}
> +
> +/*
> + * Send a message on console device(s).
> + *
> + * That will handle all possible scenarios working w/ console
> + * - physical console (serial console, VGA console (x86 only));
> + * - PV console;
> + * - debug console (x86 only): debug I/O port or __HYPERVISOR_console_io
> + *   hypercall;
> + * - console ring.
> + */
> +static void console_send(const char *str, size_t len, unsigned int flags)
> +{
> +    if ( flags & CONSOLE_SERIAL )
> +        console_serial_puts(str, len);
> +
> +    if ( flags & CONSOLE_PV )
> +        pv_console_puts(str, len);
> +
> +    if ( flags & CONSOLE_VIDEO )
> +        video_puts(str, len);
> +
> +    if ( flags & CONSOLE_DEBUG )
> +        console_debug_puts(str, len);
> +
> +    if ( flags & CONSOLE_RING )
> +        conring_puts(str, len);
> +
> +    if ( flags & CONSOLE_RING_VIRQ )
> +        tasklet_schedule(&conring_tasklet);
> +}
> +
> +static inline void __putstr(const char *str)
> +{
> +    unsigned int flags = CONSOLE_ALL;
> +
> +    ASSERT(rspin_is_locked(&console_lock));
> +
> +    if ( conring_no_notify )
> +        flags &= ~CONSOLE_RING_VIRQ;
> +
> +    console_send(str, strlen(str), flags);
> +}
> +
>  static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>                                  unsigned int count)
>  {
>      char kbuf[128];
>      unsigned int kcount = 0;
> +    unsigned int flags = opt_console_to_ring
> +                         ? CONSOLE_ALL : CONSOLE_DEFAULT;
>      struct domain *cd = current->domain;
>  
>      while ( count > 0 )
> @@ -636,26 +712,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>          {
>              /* Use direct console output as it could be interactive */
>              nrspin_lock_irq(&console_lock);
> -
> -            console_serial_puts(kbuf, kcount);
> -            video_puts(kbuf, kcount);
> -
> -#ifdef CONFIG_X86
> -            if ( opt_console_xen )
> -            {
> -                if ( xen_guest )
> -                    xen_hypercall_console_write(kbuf, kcount);
> -                else
> -                    xen_console_write_debug_port(kbuf, kcount);
> -            }
> -#endif
> -
> -            if ( opt_console_to_ring )
> -            {
> -                conring_puts(kbuf, kcount);
> -                tasklet_schedule(&conring_tasklet);
> -            }
> -
> +            console_send(kbuf, kcount, flags);
>              nrspin_unlock_irq(&console_lock);
>          }
>          else
> @@ -756,30 +813,6 @@ long do_console_io(
>   * *****************************************************
>   */
>  
> -static void __putstr(const char *str)
> -{
> -    size_t len = strlen(str);
> -
> -    ASSERT(rspin_is_locked(&console_lock));
> -
> -    console_serial_puts(str, len);
> -    video_puts(str, len);
> -
> -#ifdef CONFIG_X86
> -    if ( opt_console_xen )
> -    {
> -        if ( xen_guest )
> -            xen_hypercall_console_write(str, len);
> -        else
> -            xen_console_write_debug_port(str, len);
> -    }
> -#endif
> -
> -    conring_puts(str, len);
> -    if ( !conring_no_notify )
> -        tasklet_schedule(&conring_tasklet);
> -}
> -
>  static int printk_prefix_check(char *p, char **pp)
>  {
>      int loglvl = -1;
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri May 16 23:21:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:21:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987709.1372919 (Exim 4.92)
	(envelope-from )
	id 1uG4Mq-0005aZ-UT; Fri, 16 May 2025 23:21:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987709.1372919; Fri, 16 May 2025 23: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 1uG4Mq-0005aS-Ql; Fri, 16 May 2025 23:21:28 +0000
Received: by outflank-mailman (input) for mailman id 987709;
 Fri, 16 May 2025 23:21:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4Mp-0005aL-3Y
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:21:27 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2417::600])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7bda57db-32ac-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 01:21:24 +0200 (CEST)
Received: from CH2PR10CA0029.namprd10.prod.outlook.com (2603:10b6:610:4c::39)
 by CYYPR12MB9015.namprd12.prod.outlook.com (2603:10b6:930:c8::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.32; Fri, 16 May
 2025 23:21:20 +0000
Received: from CH1PEPF0000A348.namprd04.prod.outlook.com
 (2603:10b6:610:4c:cafe::71) by CH2PR10CA0029.outlook.office365.com
 (2603:10b6:610:4c::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.16 via Frontend Transport; Fri,
 16 May 2025 23:21:20 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000A348.mail.protection.outlook.com (10.167.244.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8746.27 via Frontend Transport; Fri, 16 May 2025 23:21:19 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 18:21:19 -0500
Received: from ubuntu-20.04.2-arm64.shared (10.180.168.240) by
 SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39 via Frontend Transport; Fri, 16 May 2025 18:21: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" 
X-Inumbo-ID: 7bda57db-32ac-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=axNM8jPWFowmv5DoR89xAkdDQYfU9k6vgFQ1kL6kyUDYPvqxsiJSDoEKmTaLdPysGI1m229rifQXUMeI7cJH6s+YuzLAsZm9SAzxy0aUjTiU5D9SECiV+FBtBXu2mig3scTqMgQ17xBfvHgrH2HGsyPrCHIbDNFYk4Yj6Sypuan5zoUmATeK17oTAROLS0YWB45qabB2GSJkCMXUd7+C5tiTtRchi+PedEKvLLFjaymw17u5rlj30SsVwpl7CeAgfq6K6uU5ndrUNQhwWiLk/j2yCF0bFOKRfjbimcItq7LdmMjoXa8buvJryVar+zhCvjDxmRUwNoHlSPiMO3qcTA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Rw4/nff0CJxYiSOlOBcxXpmB+5/RpVGAfVJzqxDSIug=;
 b=MFEdArR/IHFjyXt+lbGpyukyu84CmDuUWSOnxNgrfP/qJ5hgWRS/7hUhMXmG8nC01tZgIr7tBMEyZ9EsTdeyyiFVLe4mGOgQGz3FZ2featAXFdStZTHnBp76vb1fM2Il89E4ZFptfWgRUXMbSXYvIMDLAZ5u7Rxl2SRkWoWLED1JNRbjxtRKQES69EXxaxf9b1krpf4Y8c49xzFlRk+pD3f+TKx9ZBMIqR4jHEfGjdW+kMBjE6ABDs0U9rYwQFy58SHFS5p4Qyaf9hnP1+V82YpSeAuoQPQpVbUpCBbOdDgZtGFkprdwH1jiCyxJ3nsgQq2fg/JVAzOCe1EY3DBaDw==
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=Rw4/nff0CJxYiSOlOBcxXpmB+5/RpVGAfVJzqxDSIug=;
 b=uDksWBD6W+312hGPGA8Quq0y2rvbhMn8hCgH4G4wdjy/UTTPJjQPRM+djwchjWLTs/UzpWQuLEzJOD5ZOSuU8wWaU9gJlpfYJBsm/WAQxy9ujvldWw8NcssNSz3T2ePbZ/q3TCWWsBlFvqzHJ0Po0HtWjMxtsJ8k7/JNwnHnGVw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Date: Fri, 16 May 2025 16:21:12 -0700
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: 
CC: , , ,
	, , ,
	
Subject: [PATCH 0/6] MISRA D4.10: fix header guards 
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Received-SPF: None (SATLEXMB03.amd.com: stefano.stabellini@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A348:EE_|CYYPR12MB9015:EE_
X-MS-Office365-Filtering-Correlation-Id: 0b41fdbc-6c45-4cc5-9cb9-08dd94d05d50
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?eC4BKzz8rVVpWy+oJpO6kxGNlOQ0lk2JouL7YSIDlw3tg3Sxrkg5ioTxXyxZ?=
 =?us-ascii?Q?2HH4orzqiz+5DQQSXjU4uDAVf+8j2eBh4ljKPxiSZMgdrsC/JMP8YW31sOo2?=
 =?us-ascii?Q?T1upnHxKvbktktiZSsJyQB1Rch1zpcBQGJWjaylEMnUp0gQnCtBPdHhCf7/P?=
 =?us-ascii?Q?dDWwIVeM9opo5R5ddYb5BXOntezNp/lf/uu2KmHnhys2pMDMT+wavw115y9j?=
 =?us-ascii?Q?bIj1Sf+nKecKW8BLxUZNdKlBhE5d+tdc+5QeF09e1lDMNT8K5xbc35bQn5IR?=
 =?us-ascii?Q?eMEykMJs2iksGLkMNP7enU5eXp0GhbX/bSyYarhOWIoVqhlFREdsmEw1ztbD?=
 =?us-ascii?Q?LgJ/QHPOP6GP1hLDXCjgP/EziiB7lS2jrBvWHuG1vGiknTYL1g6D3yVqaKhq?=
 =?us-ascii?Q?NBqnq2KPhzRqacSVIZpxZEdlZwrGByXcCYf4jFtkKGS/haVYC0KYVFWocS5j?=
 =?us-ascii?Q?eWYPAHdC8t60+q56UF5DlfWGox41Wx+P5IeU5NwfFKo/4mBCZzNAjd/up7Co?=
 =?us-ascii?Q?tmAWHZgC/bPEzdxmhvcJZdGx0qnz9YaYPYVVW+wzoijHRxzdYrzYAo/tY0rU?=
 =?us-ascii?Q?yZ+jBqpCoDs1DOFCy/+E4FWHDyZuA/z3nqB9MnBz5+e8kyCzTHxetFYLMZO5?=
 =?us-ascii?Q?G5EbLKBCcvimdiadXwoKAv7erbC8awKjOzHe+9q90qAyOHGJeLKNVl+UnTAG?=
 =?us-ascii?Q?QtGrG+GGCGqoD6q5+7oA+fzbnR9UiC3VskwnB7ApgVLaXDZpxua34qfWj2DK?=
 =?us-ascii?Q?rkKqcefmWSIdb5vDoNUQh01dCAvX7Yc6k+Vs/FjF+1YSy0NFL1xZuCSKT/r8?=
 =?us-ascii?Q?I/qzcugZZgxifsVrN8vuBsKyyApJmrBkxlXk+IyNTxj4kZWZnWTf9zK07Oms?=
 =?us-ascii?Q?fONlDkCBWUf83Z09b+9bQFAB5u34KdeY/qDIr2eh9WtvdaP8YfiAqVP6u2vA?=
 =?us-ascii?Q?Lcwkid+r944137nHKcm9QD16ommuZQLuF7qBLpamq6Vzk3Ml79wK6QGEGN+e?=
 =?us-ascii?Q?9AFfILx/K4mhMDQLJFWjo63ZpHtdmYJ7FNenU7jW+HxXv5XMsqK3CkzMdeJX?=
 =?us-ascii?Q?hXXU7+wg5HD6J17BO1PEQrvSrJjashrvX0Q8FI+V7hLjdH39nxe4XvZaSxoU?=
 =?us-ascii?Q?t1EsRFmooPqRne15sBLjARPg3suET4uvLRRDvqbdEtjgWRmafaobiByXOpQ5?=
 =?us-ascii?Q?yeCifr+jZvR5jwmZKWdrEEHAsmt3eLgp03LKZAfqOnOd9BzChP+k4EvilLuq?=
 =?us-ascii?Q?ydMg5Uo5kwy6xtoMJKiZTCJLNt/vgIvvIdWqducRhtcjYw9sWdBl2C+v7bQv?=
 =?us-ascii?Q?rrZ0UjiI39IMVedRmrVcUbxoOUvpm6RtW8uvVjpH7VKF/KyXUeNiROJy6F6w?=
 =?us-ascii?Q?arXC/hazUKCtQlxhhmhGffbX/0xjMbQrmVFExq3ysaMHZsWLnZef2hwOK4hR?=
 =?us-ascii?Q?K8ZQUM3wYuxaPke2PJoB6syN6rDb1KgwFgHAHv2csyjjsd/ThK391usMpDVl?=
 =?us-ascii?Q?gTLrMSxL0etoRszXlPZMbcNj+haMyzH19zyG?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2025 23:21:19.5590
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b41fdbc-6c45-4cc5-9cb9-08dd94d05d50
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A348.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB9015

MISRA C Directive 4.10 states that "Precautions shall be taken in order
to prevent the contents of a header file being included more than
once".

Fix few remaining header guards, and update ECLAIR configuration

Federico Serafini (6):
  xen/arm: add inclusion guards
  xen/x86: add inclusion guards
  xen: add inclusion guards
  xen: refactor include guards
  x86/asm: refactor inclusion guards
  automation/eclair: update configuration of D4.10

 automation/eclair_analysis/ECLAIR/deviations.ecl | 14 +++++++++++---
 automation/eclair_analysis/ECLAIR/tagging.ecl    |  1 +
 docs/misra/deviations.rst                        | 15 +++++++++++++++
 xen/arch/arm/efi/efi-boot.h                      |  6 ++++++
 xen/arch/arm/include/asm/efibind.h               |  5 +++++
 xen/arch/x86/Makefile                            |  8 ++++----
 xen/arch/x86/cpu/cpu.h                           |  6 ++++++
 xen/arch/x86/efi/efi-boot.h                      |  6 ++++++
 xen/arch/x86/efi/runtime.h                       |  5 +++++
 xen/arch/x86/include/asm/compat.h                |  5 +++++
 xen/arch/x86/include/asm/efibind.h               |  5 +++++
 xen/arch/x86/x86_64/mmconfig.h                   |  5 +++++
 xen/arch/x86/x86_emulate/private.h               |  5 +++++
 xen/common/decompress.h                          |  5 +++++
 xen/common/efi/efi.h                             |  5 +++++
 xen/common/event_channel.h                       |  5 +++++
 xen/include/xen/err.h                            | 10 +++++++---
 xen/include/xen/pci_ids.h                        |  5 +++++
 xen/include/xen/softirq.h                        | 10 +++++++---
 19 files changed, 113 insertions(+), 13 deletions(-)

-- 
2.25.1


From xen-devel-bounces@lists.xenproject.org Fri May 16 23:21:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:21:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987713.1372929 (Exim 4.92)
	(envelope-from )
	id 1uG4NE-0005zn-7O; Fri, 16 May 2025 23:21:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987713.1372929; Fri, 16 May 2025 23: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 1uG4NE-0005zg-4O; Fri, 16 May 2025 23:21:52 +0000
Received: by outflank-mailman (input) for mailman id 987713;
 Fri, 16 May 2025 23:21:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4NC-0005s2-9O
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:21:50 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20600.outbound.protection.outlook.com
 [2a01:111:f403:2418::600])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8af95b2c-32ac-11f0-9eb6-5ba50f476ded;
 Sat, 17 May 2025 01:21:49 +0200 (CEST)
Received: from CH0PR03CA0267.namprd03.prod.outlook.com (2603:10b6:610:e5::32)
 by IA0PPF4D923B935.namprd12.prod.outlook.com
 (2603:10b6:20f:fc04::bcd) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.33; Fri, 16 May
 2025 23:21:45 +0000
Received: from CH1PEPF0000A34A.namprd04.prod.outlook.com
 (2603:10b6:610:e5:cafe::a2) by CH0PR03CA0267.outlook.office365.com
 (2603:10b6:610:e5::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.20 via Frontend Transport; Fri,
 16 May 2025 23:21:45 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000A34A.mail.protection.outlook.com (10.167.244.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8746.27 via Frontend Transport; Fri, 16 May 2025 23:21:45 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 18:21:44 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 18:21:44 -0500
Received: from smtp.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 16 May 2025 18:21: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" 
X-Inumbo-ID: 8af95b2c-32ac-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=miEQldNgMP2AiDsoajvZVOqjGMmV3UmyXf7RS86ZdeAQl89dQJvde7nuQlG/hrFs7O+mSgw2xZqoH2GCBdNxksZ7JAEJOdyL+5yvHZUf3F1A2CXthXcf7ZMJIQ2FCV5Xxt6Kwk+/tQTJKvlqNsb8t4x34VfiE2nwIhl3R0diDT90POQFyP6ueTXwlozkLYkv4s0/Iza65Vutg3vF7ANtdaPN8E47ZqlY3qW5rO2APkKOIlUeaj/9I7XT1TAdPOiHVdh/wG6xCIygSlYBz6nPIpj2yD9KsLYujCVqsEpdT5xSjJy8YQlzCWviLQImzo4gKWbB7R3cMYXSbt8p5dFYtQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uvsiHvmuEqOockd22z8vSZlAwyTxhLLN35xLes32HHk=;
 b=tp3TjxnJDa5NFFMpjApO5BICRidk54UBKfm/JSMzrJu5vtKlNjpW5swyLJo9Hii/kwPfAnMZ+YyckOvwREi7cxuMKvT1Ynk525VKUWEvTNWkeYpe120JSG3NveuxHVU1KdMTA2iSeRJ01pq2g1kDB2HpF0h2JC8upnwn16+5bLnucqOGD1LTHhnFl90uyqm9EU4eE5bu2nDMMPnCpTyG++6OAtf8O3KlrDdccQpyWQvCL2ijlU1YpV7upDr3utkbwyEtwaFjP+LOdgFEzxwfkz8zUhf7rR7ivJ59ee7aoGQv5KY+343anabbndFJ9RsTkptX2SSgcSQ4ZCUTKlWAoQ==
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=uvsiHvmuEqOockd22z8vSZlAwyTxhLLN35xLes32HHk=;
 b=mkQSTbJJh4SEWHJL4FG/Lqryi7CxDUN3ey0jCzmDXT7NBC7Ok4H7blEyS6lPf/uBAfbKORUnx9wMjmZon+KS5rBsjKeKDEGAYg1olXgeUtSAUJmrzJY0JIfvqoz/F8TQWZ9m8EPgf0wmnudwxxMTCXlYf8PMbKAks5ZTDUxleQ4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stefano Stabellini 
To: 
CC: , , ,
	, , ,
	, Federico Serafini
	, Stefano Stabellini
	
Subject: [PATCH 1/6] xen/arm: add inclusion guards
Date: Fri, 16 May 2025 16:21:25 -0700
Message-ID: <20250516232130.835779-1-stefano.stabellini@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: stefano.stabellini@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A34A:EE_|IA0PPF4D923B935:EE_
X-MS-Office365-Filtering-Correlation-Id: e201a081-0fcc-4e32-854d-08dd94d06c99
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?njfK6ToZIhyebKh+NzrMt0rs4rDwpbIMo3V+6Z7VsiESbOlsje71yRdOgiac?=
 =?us-ascii?Q?VB8cQF0XNCmp4tMTdNvs1JXylnc4+k+Nkvx7MuXLmOBk7zWzuCitV+bPcExk?=
 =?us-ascii?Q?27O5LO03487TpzL1R4Qm1Ix5FtHsLciO315VOhCtV+LAQqoTJqwXwu5so7wF?=
 =?us-ascii?Q?Fdjbk4wT5vvQ0Al+D19rrqUhLU/fp/lkIiS0XHed04Hob+22VGT69mapgxCw?=
 =?us-ascii?Q?BSb7UCfbQWHvbP7s0iK95kOECZzY5nkMXu2h+zDEkk1k8g5zrnN1tTR82YbU?=
 =?us-ascii?Q?4e6d6HiqNeVb0R2hLjr8Rgv4RBkBoglx6N2eh813Fadt+f4ArlRqAStFXy42?=
 =?us-ascii?Q?xas4Cf5LI0E8qdhg6MWf5ZuW1kV/PsY46VrCx1yV65MQQmcGmVGwtMotmAiG?=
 =?us-ascii?Q?TUFbvx6ccTc9V8izogs/UL0XHzi2q9F+dK90mDo6MEihxy/CV2ZGos8NY5QV?=
 =?us-ascii?Q?A2SQ6Uo4zj5JNcnPMPvwTuT9lrnlDBRWZgV90iHU5mQgIKrdrVQdY4C0i1Ew?=
 =?us-ascii?Q?wyFTEZY+Osgm6gr/lEMDivQnK6PVir3/+DjUGJ53ejyzquldShoZscBbJlmI?=
 =?us-ascii?Q?u2ZKnBNCsJ6vtPp2jXEVo99jn4T9BgAQH6m63Hb6ODRvhscq+I0cAZL8Gydl?=
 =?us-ascii?Q?hA2Mah8rsR37WfOQsrEHmmJAz/wDNu6uym4OJxIJQsSyB1CLGXlYEctUyTDE?=
 =?us-ascii?Q?P11A7BQ9OcTU31Z42KOaWnxK2hhE0/SoiSv11mnQUMbFt93OI3rN5WBwT1tI?=
 =?us-ascii?Q?OGetJ0RBh6E6a6DxZthsmOQ/Bi82JQ0fAK6tzc4UEDtnn4/6uZHx2Kp1uvbD?=
 =?us-ascii?Q?ocuGB7AlYq38izC7PxvhgIdHNGXb+gFbXPnCsE/RUeM4pLdef2TwWbM82PPH?=
 =?us-ascii?Q?fhxJRAULddX+/bsnKdMRSFc+N7n8caDgH06ivW4xrmNMKbya/PUBedQcSY97?=
 =?us-ascii?Q?f1PNmQAiE0oCqP4wXu2dPgzT7zrzekSPXP1Mg9iaShK6Cjkn5/jNTCBflTNA?=
 =?us-ascii?Q?CU8Kwr/Duhf0Rda+QgUjjk+HFyqBzMmKKS0Fo/SDEH3zSoIjcZzTDVKTo1By?=
 =?us-ascii?Q?SPM9Z9vy9zYrKtlsWYoCknlz1Y20HyPimpK4+pU4l1uADUtxabCByJiPorYx?=
 =?us-ascii?Q?2mimQQNMvMdTt0QDww9fTz6zBYsWdwbHI14KW5g0eyNR3TUlbddpi/p6fACU?=
 =?us-ascii?Q?+zGxiufLGC0z80C+V+kFLXLbM6z5727j+00kbH5yIfstbf21+ufZfSoJ72Ft?=
 =?us-ascii?Q?G/Zcz1M6ThXRmVHoqF9LUxihj+fOGTAa9iNrxdlLrJxHeoqnHlk8uYjNBqbS?=
 =?us-ascii?Q?ZonT3jG23beArVYVJP3M3J4tcydF47XOfwShP4QYMX3GsoC/owPWX18q+VKm?=
 =?us-ascii?Q?Q5rKb1LsVA8jK/Ht40ze4/9+O9hNrUpsUclwhZgjAM1sT83qAmsn2yIPozEX?=
 =?us-ascii?Q?RB0gIB1Jled/vi+sNXwHZpXU3TMeqhxLX+3ROPJVkE/Cf95kIxRhIpugayza?=
 =?us-ascii?Q?Ay4PcqL1TRZrVDuTtKyVjJKN5Mce+jAS5UUZ?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2025 23:21:45.1635
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e201a081-0fcc-4e32-854d-08dd94d06c99
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A34A.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF4D923B935

From: Federico Serafini 

MISRA C Directive 4.10 states that:
"Precautions shall be taken in order to prevent the contents of a
header file being included more than once".

Add inclusion guards where missing to address violations of the
guideline.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/efi/efi-boot.h        | 6 ++++++
 xen/arch/arm/include/asm/efibind.h | 5 +++++
 2 files changed, 11 insertions(+)

diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index dcad46ca72..d2a09ad3a1 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -3,6 +3,10 @@
  * is intended to be included by common/efi/boot.c _only_, and
  * therefore can define arch specific global variables.
  */
+
+#ifndef ARM_EFI_BOOT_H
+#define ARM_EFI_BOOT_H
+
 #include 
 #include 
 #include 
@@ -1003,6 +1007,8 @@ static void __init efi_arch_flush_dcache_area(const void *vaddr, UINTN size)
     __flush_dcache_area(vaddr, size);
 }
 
+#endif /* ARM_EFI_BOOT_H */
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/include/asm/efibind.h b/xen/arch/arm/include/asm/efibind.h
index 09dca7a8c9..92b8bad0bb 100644
--- a/xen/arch/arm/include/asm/efibind.h
+++ b/xen/arch/arm/include/asm/efibind.h
@@ -1,2 +1,7 @@
+#ifndef ARM_EFIBIND_H
+#define ARM_EFIBIND_H
+
 #include 
 #include 
+
+#endif /* ARM_EFIBIND_H */
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 23:21:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:21:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987715.1372939 (Exim 4.92)
	(envelope-from )
	id 1uG4NH-0006HP-Dv; Fri, 16 May 2025 23:21:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987715.1372939; Fri, 16 May 2025 23: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 1uG4NH-0006HI-AW; Fri, 16 May 2025 23:21:55 +0000
Received: by outflank-mailman (input) for mailman id 987715;
 Fri, 16 May 2025 23:21:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4NF-0005s2-9h
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:21:53 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20624.outbound.protection.outlook.com
 [2a01:111:f403:2413::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8bf9804a-32ac-11f0-9eb6-5ba50f476ded;
 Sat, 17 May 2025 01:21:52 +0200 (CEST)
Received: from CH0PR03CA0247.namprd03.prod.outlook.com (2603:10b6:610:e5::12)
 by MW4PR12MB5666.namprd12.prod.outlook.com (2603:10b6:303:188::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.30; Fri, 16 May
 2025 23:21:47 +0000
Received: from CH1PEPF0000A34A.namprd04.prod.outlook.com
 (2603:10b6:610:e5:cafe::b5) by CH0PR03CA0247.outlook.office365.com
 (2603:10b6:610:e5::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.29 via Frontend Transport; Fri,
 16 May 2025 23:21:46 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000A34A.mail.protection.outlook.com (10.167.244.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8746.27 via Frontend Transport; Fri, 16 May 2025 23:21:46 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 18:21:45 -0500
Received: from smtp.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 16 May 2025 18:21: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" 
X-Inumbo-ID: 8bf9804a-32ac-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IPwM/EYi1QPTSXZ4KDn1/9i4Pd0LexesI1nf4/nfOpVDRFBO42NlwapMPWOBejXnRKeiAommHBjyTpWriTBS8XS9YrdI2zxOfbFjE5dCvQXSYNfbreMjepgrJH0FIOjzUCjAkAIWXgcELgvp2EmN4UNODJIx90wELNU891+O+jVoqfU8t7HMkxF4aFDLMnc2+hm+nXzJg7ltejO9CDmysW/RCTyJHWQ9SdYlasyyhr4mzSEKTXTUlSQKUFHUh9RJ94pSjSxNToV8bzzwWlDTI96zCMvEMC+tHKgmG3LsycqWmwI2QGwLmU84a/mMwY9nsW/LTbejQDrcp62G5T+ABw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hOfLncgDV8d5Q1wUOwc7gzU+soF9bg8LoZ3vX+hETX0=;
 b=rtTlNKFby8cQfn8irbtFwtWEE3cUoZCmL+Dsspe8nSfaHKjQythtmrRfeVfeDaWuezwy8VcSYwqM7z+FR5d9dxnLShZ//wUM5Q1Pk3w0DMPsJlKXH4pYP2Wv/hIzTJSuyUaD8rqqu6UKQOJtl9U9T4TVR9ILy1d5DUmIKWvj0F5nZyZ1vAmAWVZbkrBZw4AHwr7IYolY4xvGKqH5iOphz4HbF/ERXb3GKB/86/OmBuZEP4f4sksw/bi0516W0168ZIwRqd7h6o2xHuNiDKo85Vz0pfbhF4RTeolep1dLTu/104uKOpfkRpcHmYdzWuNumxM898YPDI4+mjxAyCg61Q==
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=hOfLncgDV8d5Q1wUOwc7gzU+soF9bg8LoZ3vX+hETX0=;
 b=ZpUlH5p+W4QUzagKIse9gtO74NPBy0s5Xz39VuQwF5tC02YrTvRESUXqGpmqZDZcR9An7meGqqsidOH94DeJzP24iqeH8xetGWL+U6Yw+R6KAevdx8yvFSKpsBT4PF9ZNu4SKmnX0nVrBmbL3vBQuIOBl8FGTH328RGMm0fCeZ8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stefano Stabellini 
To: 
CC: , , ,
	, , ,
	, Federico Serafini
	, Stefano Stabellini
	
Subject: [PATCH 2/6] xen/x86: add inclusion guards
Date: Fri, 16 May 2025 16:21:26 -0700
Message-ID: <20250516232130.835779-2-stefano.stabellini@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: stefano.stabellini@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A34A:EE_|MW4PR12MB5666:EE_
X-MS-Office365-Filtering-Correlation-Id: 3e30d180-9f2c-4510-09c2-08dd94d06d32
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?RDTLGWSWeHuWgJql4JL54szsUnjnlPXtULl5K3JPtwFlBtxS9nSUdVD2jkgF?=
 =?us-ascii?Q?lafQ4/Sv/KGUsOGbweuaHTJ/jjzFn5VX57K3RjKmBwdfIgoJnHsOhS/etYgd?=
 =?us-ascii?Q?bRDL8EUeH2aL13MZ+lfue1G8P071ma6+Q9nO6rOlZLd4iiN2X4suNbocRSvX?=
 =?us-ascii?Q?zD6HggIZ3DWeCmrH+FEKVzwnHhUivjg6n8yKTTnxRmEIv2HKtd2dbK4l+pCC?=
 =?us-ascii?Q?aOd7ltM0BPDwbA0bWqv3QENvgLOOlDG0WpgBJ9rzw5f15YJUU+s/HLVH9P9w?=
 =?us-ascii?Q?SyUqHYsfqEFNx8DqTV1s2G2z5xHeY7V58QNT3zJZ0tZfashNCkxMPT1hpA85?=
 =?us-ascii?Q?FCZv0JGeRZcdFX7c387I4n8f8kvHRXT/9LZO/zRzdmnDxfFHw1kUZskQHnO8?=
 =?us-ascii?Q?5EwfXi6U4AMdg0fb+hMnvAxSJTlYCt+qdTQJVZ0zPwU4PWODOJNAKy9SEhm+?=
 =?us-ascii?Q?OmlDIR+FH3dISEv1+4PnD0STruozZlk2Tt4mtwE0+F+rp5gl/VqbkOLml1zZ?=
 =?us-ascii?Q?EnPRaBLHQyvHbtMRoTREh4xEAqH7sFYO4+OkuuMPfil55Xi6EqFeSJwfYNS2?=
 =?us-ascii?Q?qxvUbp1cZoMaHsJW7Dq5UgqIbh4ErUQTGi9zJJF7jSmmrZZ9KAGKfD+Vh9YX?=
 =?us-ascii?Q?H3i2HRsnoXK6bGwYsTCMNQVBR5yVQ06jNWWzPO+dDnZBgIhWrux4SYoetCAt?=
 =?us-ascii?Q?pwUxIVyvzHkKmjsj0T1PH0+5fW7zv/IqNScY0FxI4zM5mPRCaiOCGEFrbzoD?=
 =?us-ascii?Q?K1Xh2KNTabN/Gs/jBQdWDHpem0ABUYu3bZ/J+/oD0hYwGzCXbsJUp6Wfj7bm?=
 =?us-ascii?Q?+cX4aJyB3zetIfs1nMFxhRwGDUYDegzYi0UT0YEBfrzPHQ9JVjakzBTkB/LO?=
 =?us-ascii?Q?gVKqzxUJTY7ZniZdOdjNO67vKKrFPahFmjFrzYZIOmyBd1Yacfwl7yl/SciL?=
 =?us-ascii?Q?9H/LaDJGuRUbvw+0UZxtI15rKz226Ps7agCAIFjtZd4tkp8ozQ5iZdwQU1L7?=
 =?us-ascii?Q?2J5uCenKKnVg7tkhvFgnqUTnuAyI1uNcda8H3E10Rx/bkjigGS1GGh3xG38S?=
 =?us-ascii?Q?uUIFJCN3eDlhPf04oEtcNkh08CFZj0QrlCK2MT4yq/di9AsdR13HrtsCj8gm?=
 =?us-ascii?Q?/LBpIm68AkwFMrdW4yPrkNkAbtdb1Ln6YFKo5ZJmELbigdhX1GsLSBOicHKs?=
 =?us-ascii?Q?u4kYW4z2Y8y3rRqnAQw/2PSamCX4kjTNEqz/U90aG3kGtjC0rReYsypQZ/wO?=
 =?us-ascii?Q?94TfGUifTNBCgZmiSzwU5G3evZqEqgvCzANel195tA8QJQEL1WwcUHBW1Vax?=
 =?us-ascii?Q?CVCSVdXfB2VDN3lviDQ21b3p/LLgvNeLcx75SgEtyY5nd4vok8NjI5N6iF9/?=
 =?us-ascii?Q?Zhv8sfplxzM1HqDimluWhPaQ+D91sXYmP2pOhW2Xw19hx1kAy0nD6gToO9Sn?=
 =?us-ascii?Q?nZx8ybXheUuQwoySngdmQuEAWn+0TkPV27feu6aKOAOfwdfp+g6LIM+GlzTJ?=
 =?us-ascii?Q?C8yfXQ93jAv8sVG892YX4ZavQT93jpzfkNxO?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2025 23:21:46.1229
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e30d180-9f2c-4510-09c2-08dd94d06d32
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A34A.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB5666

From: Federico Serafini 

MISRA C Directive 4.10 states that:
"Precautions shall be taken in order to prevent the contents of a
header file being included more than once".

Add inclusion guards where missing to address violations of the
guideline.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
 xen/arch/x86/cpu/cpu.h             | 6 ++++++
 xen/arch/x86/efi/efi-boot.h        | 6 ++++++
 xen/arch/x86/efi/runtime.h         | 5 +++++
 xen/arch/x86/include/asm/compat.h  | 5 +++++
 xen/arch/x86/include/asm/efibind.h | 5 +++++
 xen/arch/x86/x86_64/mmconfig.h     | 5 +++++
 xen/arch/x86/x86_emulate/private.h | 5 +++++
 7 files changed, 37 insertions(+)

diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h
index 8be65e975a..cbb434f3a2 100644
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -1,4 +1,8 @@
 /* attempt to consolidate cpu attributes */
+
+#ifndef X86_CPU_H
+#define X86_CPU_H
+
 struct cpu_dev {
 	void		(*c_early_init)(struct cpuinfo_x86 *c);
 	void		(*c_init)(struct cpuinfo_x86 * c);
@@ -26,3 +30,5 @@ void amd_init_spectral_chicken(void);
 void detect_zen2_null_seg_behaviour(void);
 
 void intel_unlock_cpuid_leaves(struct cpuinfo_x86 *c);
+
+#endif /* X86_CPU_H */
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 1d8902a9a7..0ecf4ca53f 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -3,6 +3,10 @@
  * is intended to be included by common/efi/boot.c _only_, and
  * therefore can define arch specific global variables.
  */
+
+#ifndef X86_EFI_EFI_BOOT_H
+#define X86_EFI_EFI_BOOT_H
+
 #include 
 
 #include 
@@ -908,6 +912,8 @@ void __init efi_multiboot2(EFI_HANDLE ImageHandle,
     efi_exit_boot(ImageHandle, SystemTable);
 }
 
+#endif /* X86_EFI_EFI_BOOT_H */
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/efi/runtime.h b/xen/arch/x86/efi/runtime.h
index 77866c5f21..88ab5651e9 100644
--- a/xen/arch/x86/efi/runtime.h
+++ b/xen/arch/x86/efi/runtime.h
@@ -1,3 +1,6 @@
+#ifndef X86_EFI_RUNTIME_H
+#define X86_EFI_RUNTIME_H
+
 #include 
 #include 
 #include 
@@ -17,3 +20,5 @@ void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t l4e)
     }
 }
 #endif
+
+#endif /* X86_EFI_RUNTIME_H */
diff --git a/xen/arch/x86/include/asm/compat.h b/xen/arch/x86/include/asm/compat.h
index 818cad87db..30ed8f2fd0 100644
--- a/xen/arch/x86/include/asm/compat.h
+++ b/xen/arch/x86/include/asm/compat.h
@@ -2,6 +2,9 @@
  * compat.h
  */
 
+#ifndef X86_COMPAT_H
+#define X86_COMPAT_H
+
 #ifdef CONFIG_COMPAT
 
 #define COMPAT_BITS_PER_LONG 32
@@ -18,3 +21,5 @@ int switch_compat(struct domain *);
 #include 
 static inline int switch_compat(struct domain *d) { return -EOPNOTSUPP; }
 #endif
+
+#endif /* X86_COMPAT_H */
diff --git a/xen/arch/x86/include/asm/efibind.h b/xen/arch/x86/include/asm/efibind.h
index bce02f3707..ab46341281 100644
--- a/xen/arch/x86/include/asm/efibind.h
+++ b/xen/arch/x86/include/asm/efibind.h
@@ -1,2 +1,7 @@
+#ifndef X86_EFIBIND_H
+#define X86_EFIBIND_H
+
 #include 
 #include 
+
+#endif /* X86_EFIBIND_H */
diff --git a/xen/arch/x86/x86_64/mmconfig.h b/xen/arch/x86/x86_64/mmconfig.h
index 3da4b21e9b..722bf67975 100644
--- a/xen/arch/x86/x86_64/mmconfig.h
+++ b/xen/arch/x86/x86_64/mmconfig.h
@@ -5,6 +5,9 @@
  * Author: Allen Kay  - adapted from linux
  */
 
+#ifndef X86_64_MMCONFIG_H
+#define X86_64_MMCONFIG_H
+
 #define PCI_DEVICE_ID_INTEL_E7520_MCH    0x3590
 #define PCI_DEVICE_ID_INTEL_82945G_HB    0x2770
 
@@ -72,3 +75,5 @@ int pci_mmcfg_reserved(uint64_t address, unsigned int segment,
 int pci_mmcfg_arch_init(void);
 int pci_mmcfg_arch_enable(unsigned int idx);
 void pci_mmcfg_arch_disable(unsigned int idx);
+
+#endif /* X86_64_MMCONFIG_H */
diff --git a/xen/arch/x86/x86_emulate/private.h b/xen/arch/x86/x86_emulate/private.h
index 30be595470..467bce3c84 100644
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -6,6 +6,9 @@
  * Copyright (c) 2005-2007 XenSource Inc.
  */
 
+#ifndef X86_EMULATE_PRIVATE_H
+#define X86_EMULATE_PRIVATE_H
+
 #ifdef __XEN__
 
 # include 
@@ -843,3 +846,5 @@ static inline int read_ulong(enum x86_segment seg,
     *val = 0;
     return ops->read(seg, offset, val, bytes, ctxt);
 }
+
+#endif /* X86_EMULATE_PRIVATE_H */
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 23:21:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:21:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987716.1372949 (Exim 4.92)
	(envelope-from )
	id 1uG4NI-0006WI-Kh; Fri, 16 May 2025 23:21:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987716.1372949; Fri, 16 May 2025 23:21: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 1uG4NI-0006W9-Hn; Fri, 16 May 2025 23:21:56 +0000
Received: by outflank-mailman (input) for mailman id 987716;
 Fri, 16 May 2025 23:21:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4NH-0005s2-Lo
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:21:55 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2415::60f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8d5ad323-32ac-11f0-9eb6-5ba50f476ded;
 Sat, 17 May 2025 01:21:54 +0200 (CEST)
Received: from CH0PR03CA0257.namprd03.prod.outlook.com (2603:10b6:610:e5::22)
 by BL4PR12MB9722.namprd12.prod.outlook.com (2603:10b6:208:4ed::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Fri, 16 May
 2025 23:21:49 +0000
Received: from CH1PEPF0000A34A.namprd04.prod.outlook.com
 (2603:10b6:610:e5:cafe::2a) by CH0PR03CA0257.outlook.office365.com
 (2603:10b6:610:e5::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.20 via Frontend Transport; Fri,
 16 May 2025 23:21:49 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000A34A.mail.protection.outlook.com (10.167.244.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8746.27 via Frontend Transport; Fri, 16 May 2025 23:21:49 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 18:21:49 -0500
Received: from smtp.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 16 May 2025 18:21: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" 
X-Inumbo-ID: 8d5ad323-32ac-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XKtZ8aW/IiRwTyZ/uaqz2fxpVZEXpFPF5KuSGIaAZdfsXEncC1DtyFeIXx5yR8quLC7bkso5t7y7XBWgbSRCoDiy+WJ/tCF+Rdl/B+bMhXOIJIiwoHUfGV2OzabSlcnzPXvu5GoDix8P7g42I+/jmy8+v0gBbt3utouL4t1h69cJBV6OFJhi+fe0xztZmplWWWNERth+1NPWdLst1uTO3WQsR+vCseKSpQmXavrDvgcv5RwTPGXcBxVVUqLBowusFm7r09go//2LZ0GBoWj8q7wyiI8w+ZJlwf9fVyCmIL4+bJOMycrtaqP1oiEnBveTPxBmf2sbrlhvawwrFGTkkw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ibzV0RVz7ZzeEdOUX3J5YjlDrdqnL5X0dajYZtxmsP0=;
 b=qsqNsvK3UoFdwVwAtG07+1Glnd7poxQsU5eybvEc8WpwOUAOqfqek7xk+BYfkaW8PPf7Q3Ia/YDPUg6Ll5okXGbdqWDDmDNOJic0mFXsVe4yrUg3CY7XAJaRkOuy86n3UO7A1tkqcxnG1tYs9B/ygfNdzebVGrDejFFUhRLRyS+q1UwEmuYX0zTbnG7YK08WuorFuoCOBsGze7l+S4m3JR8gJIV6kd9VVZzNM1vTRWnXeyO0YbZWvdCzSZW8vT0S0gaJhWB/T4YmDaE9ELyQ1Qc+aM2WgVfCUFVb24sFdQGypLRJMJ5k4yvSx8DIKjiQ9DErETwkuDtyFfYh15vozA==
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=ibzV0RVz7ZzeEdOUX3J5YjlDrdqnL5X0dajYZtxmsP0=;
 b=h0cpAAOTRiq9qzJStQIhz1QLaNjH/MxpR7mxAGcabPwUGnn36mhqTW45CCB35AgxsuT5uXT8xcCg50dGQ0Ezri6ZEpB1svl0AYOBOmR2z8y/hKcyRgEtCAH/qOgKac5kxzQn6zJK2Myj8ISn9g+1Bq/KKUlOhoEcG3Qe90Cvppc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stefano Stabellini 
To: 
CC: , , ,
	, , ,
	, Federico Serafini
	, Stefano Stabellini
	
Subject: [PATCH 6/6] automation/eclair: update configuration of D4.10
Date: Fri, 16 May 2025 16:21:30 -0700
Message-ID: <20250516232130.835779-6-stefano.stabellini@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: stefano.stabellini@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A34A:EE_|BL4PR12MB9722:EE_
X-MS-Office365-Filtering-Correlation-Id: 2d0098eb-b6ae-4ef0-8585-08dd94d06f4c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?mLAxsJ2cxqSOq0wJUPAnz2mOBw1ZTjLDZx4BVp8M3ugPp2B7IBqi7ZATimzP?=
 =?us-ascii?Q?z328Tsk2tt/wFHVVGR5VAUkvplRqtY3YHZiJi/e6+mJi/aZAHroMC+DKNENz?=
 =?us-ascii?Q?vhD7wszYwhgnu1tIc4Xp1fX/2MXyPBcZi+KejgzNGlE423RFjYeiwUf75iEC?=
 =?us-ascii?Q?pYluNh6TEXZiT7c0oaVFBYRGlRoQw6pU38H/1h3yld8r5sDuYEN2fUwZ3uhX?=
 =?us-ascii?Q?PAdn0cOlw2wQOYdFomWH8urhyreiK75XT8rP7jGiAW3kZ9yknGAxJiULWr5m?=
 =?us-ascii?Q?fmfGzqURHiFB13uWShagI5nX01+YgdzHeK3zxPQVty+zTB41h00TTs3KncGi?=
 =?us-ascii?Q?h460QB6B9zWYQDRE2cMhU6QdhWVC+T8lP7CVwywUJmBkYRqHGLetSeA0BM31?=
 =?us-ascii?Q?DZXNkWtlah5L3ExQgBIOnsyxD3N+/S/uboS8EVCkTHYjzJmtDmn85jbYR7xZ?=
 =?us-ascii?Q?XVhWdlzCh/Q/Bc5l8WHZvdcM5R6H5XQKpKYC89qByDb71tiM0+ADXmcC+EDa?=
 =?us-ascii?Q?edpqZ4MpEWUmlaE+jrUNhku2zJAvFyjEcfOwtLJWJP+Jd3p1zd4jG7DXdOzS?=
 =?us-ascii?Q?2LF1DYtVgChYyg/gh5yFROhwRtHCq4e+Gxrm7Z+gia9ee/gWKNlHrVUeTB+O?=
 =?us-ascii?Q?Xpnq1zCj9eQu+m6dmseLr1TQ0aWFDRgV6fi4aIP1v5ygl4aFvt0JZnEVH0mU?=
 =?us-ascii?Q?Q2HjvBh7QmEMtaF3EhNkvZdPmRu1nXmYwQ7ZyA2/9DgQvZchx0ynZ4bqFVNF?=
 =?us-ascii?Q?xOnw9Y6a+BmMk2D897ScWx/3VOXzRQANTyU2z7Cslw0T0B+pO3zQOTU1ZkpQ?=
 =?us-ascii?Q?0wBUfXATk3if3y76XTjKf7/IphRksHb9aJ4Lyi3ECoF8g0YsKSHypxe9S9BY?=
 =?us-ascii?Q?n1cmlQZVYxFE7ptfwOXB3pk4g1VD2lf5lDWjkNE65+ZaxkWCi3+NeP0TIj+Y?=
 =?us-ascii?Q?HuF17uWVbhiNWCvv5f+Rz8nd91/RY+rX6LfnCzSUgAsMRpNkgXwRS/EVDEpJ?=
 =?us-ascii?Q?g3IBqH8fU3IU8mhSRz2foxQ7H/rLquLTjtcZY5vXDswGXzRPAoMvHljRPnOJ?=
 =?us-ascii?Q?/LSEi5Icx8eVOYrYS3gFDfImbTqIkxQOdLfmGnLmghMGrvX8VZ8jrTXzXBys?=
 =?us-ascii?Q?MLTq3t5uisaXCf3qmcj8UpZUkI/iXpAXW4U9MwxqpHKUNXlx5LlgrFtwOiGr?=
 =?us-ascii?Q?R8J1Nv97jYfAvflyeJ/1EBU24k6eJ35NPovV8Ilxxd77wnGhftvCZchvQn+i?=
 =?us-ascii?Q?Xv2dqXlUBaEoPxuCo/xGwllvOy59l7kNgZdudqSvP69EvNvsUx8qtn9xMsuJ?=
 =?us-ascii?Q?eC1JOaRDSeXtH/FtDReomDkmTMXn8iAmbxXSiwK7D1+hrdZkJ49WCHbDgDbW?=
 =?us-ascii?Q?AmkqAtfnlkGF22d3oC6RHSpYysLBZYggwfjPTYMC+DuSUGf/UEMx5Qwl2nFI?=
 =?us-ascii?Q?/2lZdlGMhBlrJQgyJoFIEqBxsPucJ4Mw/r9ZQLJRo6zm9404/YRhBivvcbps?=
 =?us-ascii?Q?9BNYXQPCKR/j+viAp4OkoZaSC60qjHFf5VFV?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2025 23:21:49.7292
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d0098eb-b6ae-4ef0-8585-08dd94d06f4c
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A34A.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR12MB9722

From: Federico Serafini 

MISRA C Directive 4.10 states that "Precautions shall be taken in order
to prevent the contents of a header file being included more than
once".

Update ECLAIR configuration to:
- extend existing deviation to other comments explicitly saying a file
  is intended for multiple inclusion;
- extend existing deviation to other autogenerated files;
- tag the guidelines as clean.

Update deviations.rst accordingly.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 14 +++++++++++---
 automation/eclair_analysis/ECLAIR/tagging.ecl    |  1 +
 docs/misra/deviations.rst                        | 15 +++++++++++++++
 3 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 9c67358d46..3fb6d9f971 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -72,11 +72,19 @@ they are not instances of commented-out code."
 -config=MC3A2.D4.3,reports+={deliberate, "any_area(any_loc(file(arm64_bitops))&&context(name(int_clear_mask16)))"}
 -doc_end
 
--doc_begin="Files that are intended to be included more than once do not need to
-conform to the directive."
+-doc_begin="Files that are intended to be included more than once (and have
+a comment that says this explicitly) do not need to conform to the directive."
 -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is intended to be included multiple times\\. \\*/$, begin-4))"}
+-config=MC3A2.D4.10,reports+={safe, "first_area(text(^.*Explicitly intended for multiple inclusion.*$, begin-3))"}
+-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-2))"}
 -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3))"}
--config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/generated/autoconf.h$)))"}
+-doc_end
+
+-doc_begin="Autogenerated files that do not need to conform to the directive."
+-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/generated/autoconf\\.h$)))"}
+-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/xen/compile\\.h$)))"}
+-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/compat/xlat\\.h$)))"}
+-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/arch/(arm||x86)/include/generated/asm/.*$)))"}
 -doc_end
 
 -doc_begin="Including multiple times a .c file is safe because every function or data item
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index 5bc35db1fd..7e3095423b 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -23,6 +23,7 @@
 "MC3A2.D1.1||
 MC3A2.D2.1||
 MC3A2.D4.1||
+MC3A2.D4.10||
 MC3A2.D4.11||
 MC3A2.D4.14||
 MC3A2.R1.1||
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index fe0b1e10a2..87ed81c918 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -30,6 +30,21 @@ Deviations related to MISRA C:2012 Directives:
        not to add an additional encapsulation layer.
      - Tagged as `deliberate` for ECLAIR.
 
+   * - D4.10
+     - Files that are intended to be included more than once (and have
+       a comment that says this explicitly) do not need to conform to the
+       directive.
+     - Tagged as `safe` for ECLAIR.
+
+   * - D4.10
+     - There are autogenerated files that do not need to comply to the
+       directive.
+     - Tagged as `safe` for ECLAIR. Such files are:
+        - xen/include/generated/autoconf.h
+        - xen/include/compat/xlat.h
+        - xen/include/xen/compile.h
+        - xen/arch/{arm,x86}/include/generated/asm/\*
+
    * - D4.10
      - Including multiple times a .c file is safe because every function or data item
        it defines would in (the common case) be already defined.
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 23:21:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:21:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987717.1372955 (Exim 4.92)
	(envelope-from )
	id 1uG4NJ-0006Ze-1B; Fri, 16 May 2025 23:21:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987717.1372955; Fri, 16 May 2025 23:21: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 1uG4NI-0006YG-Ob; Fri, 16 May 2025 23:21:56 +0000
Received: by outflank-mailman (input) for mailman id 987717;
 Fri, 16 May 2025 23:21:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4NI-0005aL-0D
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:21:56 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20619.outbound.protection.outlook.com
 [2a01:111:f403:2408::619])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8dc1552c-32ac-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 01:21:54 +0200 (CEST)
Received: from SJ0PR03CA0075.namprd03.prod.outlook.com (2603:10b6:a03:331::20)
 by DS0PR12MB6654.namprd12.prod.outlook.com (2603:10b6:8:d1::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Fri, 16 May
 2025 23:21:48 +0000
Received: from SJ5PEPF000001CD.namprd05.prod.outlook.com
 (2603:10b6:a03:331:cafe::b) by SJ0PR03CA0075.outlook.office365.com
 (2603:10b6:a03:331::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.20 via Frontend Transport; Fri,
 16 May 2025 23:21:47 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001CD.mail.protection.outlook.com (10.167.242.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8746.27 via Frontend Transport; Fri, 16 May 2025 23:21:47 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 18:21:46 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 18:21:46 -0500
Received: from smtp.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 16 May 2025 18:21: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" 
X-Inumbo-ID: 8dc1552c-32ac-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Wq4wcSE0OxPwoI2lFKQrNTDQYDpqmWZTagP/dr3IOUNvjU3j32Iacp37b4NSxsYWCiToRXFOdg8HtL7W7keiooDkgZjfu0Q0GOVnynUi5yI4ygUAwphFemadloFfZDcsxkIaM8ScEmeUSxUVt/OF2TOLgeIdDO/j/lbKvdbDXamZDoswjRPYlwcncs7YHKD8dexgCp4BYt9oARMT9vrJ7WKycP+AkFaCY/QNH/TD3H4uRk2k/exNY3Mk+4xKzzDzzE+ZajiNPAoi7JjHSx/E+mAlX+euTDEmLXDmquYQ27MziX/k8yT5lKFTd06bytvGr1CwIhSXsRs0uxopjxBQVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=buer/yquglfA9IXFa3Y4Vl4yg61qaCIVyNVRWFZFS5E=;
 b=Ixk79s/37rKQo9wiVbAVF5KtE2ABszJ/E++5p7aY9wcJd813ooSAL+KXolHfZK7YWRB+FNoGIw6I/f8wsDOM/GrjuoEwPIMIyCMv9J8U7SZQYNycDKF43W5jP1s4R1MIKib5QEK/w2Yr5rgQ5V3QqE9jXd8y3wib+NFQ0WuaGNYb0A/RO4Z3pbGEZMEBNsE8ugn8zKLLUR0HhJjDWNmhCBXeXOwzv2DnMPzmOFJn82OzYj95zEzyiJIphLxfZA7zZmF+yEVZYXEQm4a/Pi77BLdKKni/ocM+0NuKmeMD/6/Qzk1XEgpzPl5OOUWPQVYABf9ffNe+YpPJdoX0HmX1vw==
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=buer/yquglfA9IXFa3Y4Vl4yg61qaCIVyNVRWFZFS5E=;
 b=sYBcgXrucDa43WOpz8FWPEot2bOd00i7FCBvq/EQNskGuBEg57xtGpACTtHzey35ydkUK0I1jee5ora8Har2GjwD9cmMNqKLjjdiK9DDtRz7zd9BiKdlqeuoLIjpFGKzdEvrOl3OYiaEpT6b9RaDFvx5wWRB6h+8grEGaeB07EA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stefano Stabellini 
To: 
CC: , , ,
	, , ,
	, Federico Serafini
	, Stefano Stabellini
	
Subject: [PATCH 3/6] xen: add inclusion guards
Date: Fri, 16 May 2025 16:21:27 -0700
Message-ID: <20250516232130.835779-3-stefano.stabellini@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: stefano.stabellini@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CD:EE_|DS0PR12MB6654:EE_
X-MS-Office365-Filtering-Correlation-Id: 46ed49a2-ccad-4abd-5811-08dd94d06dff
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?XlEgjc6uz3VWMkmskh5kysM/uMntRkrrJGOifqG5D0Wr8Fdh4Dbe+Pa9Zsw8?=
 =?us-ascii?Q?36m+yRld9oiUc9D40OfiUNmaAqYY62ZslrNezNXMVU4nRlyHRsilzvR2PCYb?=
 =?us-ascii?Q?bc5560hF6m/Uq//9O9x1eLP1L7+VdXp7KpIcJ7GCT78G23gLsPcqzjpYNGhp?=
 =?us-ascii?Q?Hi1NAidHwV11F+Ncq3bl8LQtm2HLvU2+xJjbbiJn7VdUFGaqez/EpWtvLU4N?=
 =?us-ascii?Q?IzY/Xfr9veUd9LdrirjULj8FgCFSbR740+6rTvabY2jJyjbCzcbiSjySy/th?=
 =?us-ascii?Q?rsQ4dH2cmT7Bx0Daq08SBuPG2fGMiXking21qPkBc/g+EeP75KwtVgIRZKH8?=
 =?us-ascii?Q?Pd3vp+DgE51ahIA3Ckix4kV12Gxj7ZgyW7rZHHgzIQHp21N1QK/wE+dbDRqx?=
 =?us-ascii?Q?OmBj4Y3iyqGwmvB+/rQY/dVY1zTvl5oOFwL/050GfrRnnScrzSYLoeTSo+8d?=
 =?us-ascii?Q?ftqtnWnqRee1krBpZ81ph6FezKa/husyO879fyLIiIf8O9hRglGYxPxLVS1j?=
 =?us-ascii?Q?Wj5odFkw6sltAft8LkXylcx2DePAh0Qj5pytTxSJ7/CQ2a6KkuyJ7VybCJ80?=
 =?us-ascii?Q?ScBVqXDhV0uAEx0cO5KH0Nz8qv5ESE7dtfWJYLF6bDG16YBgkMdzFXdeeyxD?=
 =?us-ascii?Q?nmXUZCui+eVgqdphLRwR9H4NVZeuP5tfspKR5fdDAgmYOAKjAhZP0qxSTBG+?=
 =?us-ascii?Q?zvuQInTc0eSDzW3Qzgv+xipR77L1MupwpvE/dQ6nau03L77aC/IOOuoLXVip?=
 =?us-ascii?Q?o7J1w6A671sXYgxVlAWYHZp8CONefB/d8mgTbYnvo2mUOunLann1p4vJaYmi?=
 =?us-ascii?Q?L9vcRU5Ai+DyiLjCBAUccBatJrpS2po7e0mJasY/wWGDgMD4BD/rYq/gFVYk?=
 =?us-ascii?Q?WXe6hBcM/FnX4SKrnIiprJ4mmFrs5rsinBFAV3uODmc8ryD8sIZhLTe8RdH7?=
 =?us-ascii?Q?rG1nU/SlfOjSLjcpjI0NpEfVPiH3xhHhJ3UQcPIx8rlmUbjFBNsBARx8Kx3Z?=
 =?us-ascii?Q?ztnTe7DP6iXZ8/OT/D25gZQNUfKQ1L3t86ncbDqnLt4+rWs2jAOTxubzYjKN?=
 =?us-ascii?Q?TCdB/8HpbRT3BmYe3qSmrG7VwUpSMFpnblb6tn5shmEkEE5PIo8cnXwE6fsa?=
 =?us-ascii?Q?S1hcvjSxjpmTT6Kve21LS6ew87wP4JhraaC5pYzqu/UrebXhoiV2JlQelEG2?=
 =?us-ascii?Q?l3oFsQf+k5cZ7px01fcBX6UeAFvKFGY6kHFj9MsKj9yHzrwZhu8EWQJ6Q631?=
 =?us-ascii?Q?RhEqTJeOuD+c9KuS7XrlreM19o2vw5Njtz5RLphlbFJgZGzOzS6edWU1I4je?=
 =?us-ascii?Q?aQG1YPB4uLvgmDCeFulX9fUNrwEkPMZbU6It3uH5pmdTJrRza3I9qBLppnww?=
 =?us-ascii?Q?CaauvErRafnShpfjn74lANAiWQqBm+p6e+qy6rHdqu2KknzahDtEZSi/4cHp?=
 =?us-ascii?Q?Vcf2IHmKU81vGzHzGgqW4WaS2mixZlQQgr4Mn2Bdjgajf90fgU+ZbN+g0L/j?=
 =?us-ascii?Q?c6rUAbiUm4lpqHsA6ENKCvBbAMQDYU627W8c?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2025 23:21:47.4762
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 46ed49a2-ccad-4abd-5811-08dd94d06dff
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001CD.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6654

From: Federico Serafini 

MISRA C Directive 4.10 states that:
"Precautions shall be taken in order to prevent the contents of a
header file being included more than once".

Add inclusion guards where missing to address violations of the
guideline.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
 xen/common/decompress.h    | 5 +++++
 xen/common/efi/efi.h       | 5 +++++
 xen/common/event_channel.h | 5 +++++
 xen/include/xen/pci_ids.h  | 5 +++++
 4 files changed, 20 insertions(+)

diff --git a/xen/common/decompress.h b/xen/common/decompress.h
index 4683eb6c7e..034c833665 100644
--- a/xen/common/decompress.h
+++ b/xen/common/decompress.h
@@ -1,3 +1,6 @@
+#ifndef DECOMPRESS_H
+#define DECOMPRESS_H
+
 #ifdef __XEN__
 
 #include 
@@ -22,3 +25,5 @@
 #define large_free free
 
 #endif
+
+#endif /* DECOMPRESS_H */
diff --git a/xen/common/efi/efi.h b/xen/common/efi/efi.h
index c02fbb7b69..b02aa2775d 100644
--- a/xen/common/efi/efi.h
+++ b/xen/common/efi/efi.h
@@ -1,3 +1,6 @@
+#ifndef EFI_EFI_H
+#define EFI_EFI_H
+
 #include 
 #include 
 #include 
@@ -51,3 +54,5 @@ 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);
+
+#endif /* EFI_EFI_H */
diff --git a/xen/common/event_channel.h b/xen/common/event_channel.h
index a778ae775b..dc94a43cc2 100644
--- a/xen/common/event_channel.h
+++ b/xen/common/event_channel.h
@@ -1,5 +1,8 @@
 /* Event channel handling private header. */
 
+#ifndef EVENT_CHANNEL_H
+#define EVENT_CHANNEL_H
+
 #include 
 
 static inline unsigned int max_evtchns(const struct domain *d)
@@ -67,6 +70,8 @@ static inline void evtchn_fifo_destroy(struct domain *d)
 }
 #endif /* CONFIG_EVTCHN_FIFO */
 
+#endif /* EVENT_CHANNEL_H */
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/pci_ids.h b/xen/include/xen/pci_ids.h
index e798477a7e..5884a20b8f 100644
--- a/xen/include/xen/pci_ids.h
+++ b/xen/include/xen/pci_ids.h
@@ -1,3 +1,6 @@
+#ifndef XEN_PCI_IDS_H
+#define XEN_PCI_IDS_H
+
 #define PCI_VENDOR_ID_AMD                0x1022
 
 #define PCI_VENDOR_ID_NVIDIA             0x10de
@@ -11,3 +14,5 @@
 #define PCI_VENDOR_ID_BROADCOM           0x14e4
 
 #define PCI_VENDOR_ID_INTEL              0x8086
+
+#endif /* XEN_PCI_IDS_H */
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 23:21:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:21:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987718.1372970 (Exim 4.92)
	(envelope-from )
	id 1uG4NK-00070w-Em; Fri, 16 May 2025 23:21:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987718.1372970; Fri, 16 May 2025 23:21:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uG4NK-00070D-8g; Fri, 16 May 2025 23:21:58 +0000
Received: by outflank-mailman (input) for mailman id 987718;
 Fri, 16 May 2025 23:21:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4NI-0005s2-M2
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:21:56 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2061d.outbound.protection.outlook.com
 [2a01:111:f403:2412::61d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8e5915ea-32ac-11f0-9eb6-5ba50f476ded;
 Sat, 17 May 2025 01:21:55 +0200 (CEST)
Received: from CH0PR03CA0427.namprd03.prod.outlook.com (2603:10b6:610:10e::30)
 by PH7PR12MB9253.namprd12.prod.outlook.com (2603:10b6:510:30d::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.24; Fri, 16 May
 2025 23:21:48 +0000
Received: from CH1PEPF0000A34B.namprd04.prod.outlook.com
 (2603:10b6:610:10e:cafe::51) 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.20.8722.25 via Frontend Transport; Fri,
 16 May 2025 23:21:48 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000A34B.mail.protection.outlook.com (10.167.244.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8746.27 via Frontend Transport; Fri, 16 May 2025 23:21:48 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 18:21:47 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 18:21:47 -0500
Received: from smtp.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 16 May 2025 18:21: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" 
X-Inumbo-ID: 8e5915ea-32ac-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=N48k9fDCm8AVH1vOEgCH4zBs4bk7c80SjG3qyO47bAB54rcAosn7JTDslQ63+0Y1QrM84c99Cl2J9L45RgglPn++X0cCMcHf1qywv69WshZ0Rc0BVM4buCw0Un7HhOmrOVB7eZmb7nJpI/lOm2JlMO3TjXpbtT+s8y34MM0G7zKkCGdNlsXc7TT0s3RXMZzxYIlxETGuGDA/7UIpu1/A9BF+LvN0HMe6bW1vSP5B2AxIOs0t9MN8njLEdMakrILAHQ6QCAei6pR6uZvLplveiQ+JRLVpuWc6d68gyZJE9hREcE7V8QDCDVmVnRBFcjLDqShIMhC3bu9Odc0qd+Es+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=57V9Nd7Q2z6fh1EUxxPXh8g4JtB/sK8KIr3H3tt5FC0=;
 b=RgqtonA+hPeHS2wHXU0H0nn9XIGhKwvRhnKo8r4QfRVbgHkaSGZzSr/ZLZoPDBpCnDWw2+96ZyjqlDIC0WysihaJVAeI5FOvNtTjgHmnrur+0U/HKWQRQXjxDtRt6h4xz2JglEU9nVJP1bgxWU5rHATOqfUxeior5zjkU9byWX6mqUhDCCbdqzkj7kjtOUS0Ye2ARxaCLgI+0HF0fBd8ga7RQIVeLPiLFyDasqsM/vKF7hXjLYcnzPPel2IXU3FuCtKzyAgUOeoMcvh5ow08fKCEZioVq7FNfrtM7RUdQWy/GxxPJKKBo4norIABPTE3nhB5UuRwufQ36JMAnadovg==
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=57V9Nd7Q2z6fh1EUxxPXh8g4JtB/sK8KIr3H3tt5FC0=;
 b=3pjvcGzeemkOKnkD40JJuwZ3Z40UJ5INMqPZTSPCgwfuL6Egc5OumHnzoUELueenoZvNVhlA5ZsrKZhh3skcvZP5GsToMJ5RSIO3H2DuW7xJDxgHatHs3TKa4eYjnGk7vQRdianV0XdY79Z5KX/fgJil9TSiHNU4yOvwG5N7neo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stefano Stabellini 
To: 
CC: , , ,
	, , ,
	, Federico Serafini
	, Stefano Stabellini
	
Subject: [PATCH 4/6] xen: refactor include guards
Date: Fri, 16 May 2025 16:21:28 -0700
Message-ID: <20250516232130.835779-4-stefano.stabellini@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: stefano.stabellini@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000A34B:EE_|PH7PR12MB9253:EE_
X-MS-Office365-Filtering-Correlation-Id: 2c29a5e5-071d-463c-c03b-08dd94d06e48
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?GQspYlvZQDBymHqomv21D0KcsBZtzoy/cYmN4qXNJJ17E4GV4MRNkeIy2Ppa?=
 =?us-ascii?Q?ZCAPTO1ppVLgK2M//Jtomfm1srPqt+Y0pkIPIdOejEOxVvfpvNekUw8Ahz5E?=
 =?us-ascii?Q?Odv4LwymtYlLP+gqSFXTtyLJ2Bg+O6Th9xfwuOZyHKILD0++i73msKpZvEHs?=
 =?us-ascii?Q?dF6U/j2q99+NURY5ZR3dpT0vq1/h3gNWS4Rac+5tqW7h+OSZW27cTM6yfBjb?=
 =?us-ascii?Q?+aJAKca0VQlX2QWVYMxIVAq5mqjeUFWGOwXU8/upwNmke32mqzgLZ/KTXXeo?=
 =?us-ascii?Q?NCxcJoO1fHItPdPofjaAwIO9IES8M5LnnOLvqjSlC+ddSrhMPkVoQxpLCGqT?=
 =?us-ascii?Q?nrfoM6eOXxnz7pIVTuRKc2G9U63Pg37lQCX2ZZ/WngSEdWgKndZoCowNRlDD?=
 =?us-ascii?Q?lui321tLATdokVkIfEAE6NMc/1dk8tq1lJGgbFVHQVEE3cyYwrnYzTFXmjJW?=
 =?us-ascii?Q?jwR/FpaeJsSlI36n1uB6xP2nOPj8fPSIbtCWSA/hbLKeDPMtL5BX/orj02Rd?=
 =?us-ascii?Q?WJMqrTSdxm0Kc3eVHoS/ypjH9+sS+/dG4icTqRHDJTRfveYIJOYBHOov3733?=
 =?us-ascii?Q?t98dhI3sK1AUQ6jvMCZKBtkK/IlPtjyZTXk/9mysYj557WHaCTpWk47TRXBU?=
 =?us-ascii?Q?LJmqY/eIjqK+sQm9hjY7ijuFrHHV5bkv12M8H4apsmSuIMtlrv9vkMfpkN4B?=
 =?us-ascii?Q?xJ4rtGulmBhiHofMIx4wkF/DNqTQwBR3DGCbRnqSROLlqIFi29Nc6LgF26OV?=
 =?us-ascii?Q?mv+DUohg6Y/Un+qIwfBqCiGt1WSTPSQVNqrA0kQSOkpyxRq1xNPhpSj22e96?=
 =?us-ascii?Q?lAjaa82hwRiUE+7LcPhzlF+puHk0a3xdjZojD0UU6Gm14q4/7XeaM9NpkLz9?=
 =?us-ascii?Q?QRAagRwb2/p4zx1Z3Sipm+FBze6CD7ziCm80Sp8KkFIOBz6SmBLK4Eon7bLp?=
 =?us-ascii?Q?fAbEvTImiaLkcSm6r1w1Htfa5GrVXBRyy7/W6OoQQZbZegaqlk1UPNVspdoB?=
 =?us-ascii?Q?S2vGEACW3tR4syFjKTqwVxj2Aia+f2ntjbz7MJXNsozU7I9y2BIV+mnx7VtV?=
 =?us-ascii?Q?WIP2aFBD/105un/ZIa/tTPyRH+PADhenX6kZs9GmQKcnmb+52AGWw3I0V57v?=
 =?us-ascii?Q?yvWNR6J/DIFolDg/duMwpXEr3Zr195iwHDRQg0XHD98MzWDEZ2+ZGCOy26aN?=
 =?us-ascii?Q?9PAML6S0xo2JhHwBrtit6zJlpLIc0fzf22jwIL/qPh5dA5TGazzsOFIHjM4L?=
 =?us-ascii?Q?Dy0F27AcTazRBMgTrgOa8MdbS8p7BPsRMncBMzCYMjyrMX8cs9jG+wHsGfvy?=
 =?us-ascii?Q?/6vLdizIQv2wjQXQ0PyQigSeO+XI0jYKraFd9XwfwMfpZuSeA3L3adr+YDtv?=
 =?us-ascii?Q?Q3D2xCWLwWeP/85hPUeDlI+rBXt6gwHU7tft/UBFaKYDm9RsZUBLNnqVqDqX?=
 =?us-ascii?Q?uIGUy3rSuyLAXVwHUHIw7kVyZo49IiYUZDm7eunYsthjQ71YuBEmPzCnrKne?=
 =?us-ascii?Q?QiZuxeVpM5/RbWaD+mkZrEQjBtn7QrF7VLQ0?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2025 23:21:48.0301
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2c29a5e5-071d-463c-c03b-08dd94d06e48
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000A34B.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9253

From: Federico Serafini 

Refactor inclusion guards:
1) use a syntax that is more likely to be recognized by static
   analyzers;
2) follow the CODING_STYLE.

No functional change.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
 xen/include/xen/err.h     | 10 +++++++---
 xen/include/xen/softirq.h | 10 +++++++---
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/xen/include/xen/err.h b/xen/include/xen/err.h
index cbdd1bf7f8..5bdf8b215c 100644
--- a/xen/include/xen/err.h
+++ b/xen/include/xen/err.h
@@ -1,5 +1,7 @@
-#if !defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__)
-#define __XEN_ERR_H__
+#if !defined(XEN_ERR_H)
+#define XEN_ERR_H
+
+#if !defined(__ASSEMBLY__)
 
 #include 
 #include 
@@ -41,4 +43,6 @@ static inline int __must_check PTR_RET(const void *ptr)
 	return IS_ERR(ptr) ? PTR_ERR(ptr) : 0;
 }
 
-#endif /* __XEN_ERR_H__ */
+#endif /* __ASSEMBLY__ */
+
+#endif /* XEN_ERR_H */
diff --git a/xen/include/xen/softirq.h b/xen/include/xen/softirq.h
index 33d6f2ecd2..5593c7b0a9 100644
--- a/xen/include/xen/softirq.h
+++ b/xen/include/xen/softirq.h
@@ -1,5 +1,7 @@
-#if !defined(__XEN_SOFTIRQ_H__) && !defined(__ASSEMBLY__)
-#define __XEN_SOFTIRQ_H__
+#if !defined(XEN_SOFTIRQ_H)
+#define XEN_SOFTIRQ_H
+
+#if !defined(__ASSEMBLY__)
 
 /* Low-latency softirqs come first in the following list. */
 enum {
@@ -40,4 +42,6 @@ void cpu_raise_softirq_batch_finish(void);
  */
 void process_pending_softirqs(void);
 
-#endif /* __XEN_SOFTIRQ_H__ */
+#endif /* __ASSEMBLY__ */
+
+#endif /* XEN_SOFTIRQ_H */
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 23:21:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:21:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987719.1372978 (Exim 4.92)
	(envelope-from )
	id 1uG4NL-0007IJ-LH; Fri, 16 May 2025 23:21:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987719.1372978; Fri, 16 May 2025 23: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 1uG4NL-0007Hb-I1; Fri, 16 May 2025 23:21:59 +0000
Received: by outflank-mailman (input) for mailman id 987719;
 Fri, 16 May 2025 23:21:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4NJ-0005s2-MK
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:21:57 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20603.outbound.protection.outlook.com
 [2a01:111:f403:2413::603])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8dfec691-32ac-11f0-9eb6-5ba50f476ded;
 Sat, 17 May 2025 01:21:55 +0200 (CEST)
Received: from MW4PR03CA0179.namprd03.prod.outlook.com (2603:10b6:303:8d::34)
 by LV3PR12MB9093.namprd12.prod.outlook.com (2603:10b6:408:19d::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Fri, 16 May
 2025 23:21:51 +0000
Received: from SJ5PEPF000001CF.namprd05.prod.outlook.com
 (2603:10b6:303:8d:cafe::33) by MW4PR03CA0179.outlook.office365.com
 (2603:10b6:303:8d::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.20 via Frontend Transport; Fri,
 16 May 2025 23:21:50 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001CF.mail.protection.outlook.com (10.167.242.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8746.27 via Frontend Transport; Fri, 16 May 2025 23:21:49 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 18:21:48 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 18:21:48 -0500
Received: from smtp.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 16 May 2025 18:21: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" 
X-Inumbo-ID: 8dfec691-32ac-11f0-9eb6-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eVQKfLMh5iuSxX7mG4fUMwovR6UhXUUhvjuA8rXPOmL4BHVE2j7NGiXKK6zqz5nuJmcK2v0xHDwVwsHSxgS54ibdgxTTSv30o5TyEuW92IDFdJxxUocdSFWVizlOUKeNU/kRdQbgtBz2MHb+DNbLRBi0PZa/NWW5kgiSHol4EQ4ZDJAH3JxELhKdzIbTHARINwmYONhHcFC0Frkxjxdfl14xZgfeAbijEUUy24AyhLzu/MC/eUTe8y6IfCHbehyc2LaEW9Tc5sFA+PvgTqKJKSE9ZopWhCtC8TTnrj0jHgFw08orGjSP3jujDOKoTXeuBPFfIEv06OxWFGtEEia0Lg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DK+KHWKqgLBHIw14tu9e6rDx3z6/no2a/sVRmU5bVsQ=;
 b=MWB/cqI9w8folzAL5D1YgY1GgMxC+u4FcHVyczq6bxtdDH2gr5xZqTKEn8hju4nQyKx5ziEX19Y5/b33Wt2Qg7EnuY51zghpOTRwzTaLh9bZBsDvnE7VUKeS4kG0cvDOOaZ3kTTj7E3Wb+zYpNagrPMkQg72n2rZZCtpfbmrDfNxNjTda/SIxDit01jMrB+ygbzg0r1eHW93ojSaZxN7PdClbW80MSpVTQ9m/71H/1ziuAhPy3oyKPVW3YWZep28ajC2snN7Z4DUiEJwt5N8QYLr1e7fQz4+MhnvjouyJ476skxj6QgSg1XjA1NsfzWEwV2FM9rJaM59nXIfCzu6Ng==
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=DK+KHWKqgLBHIw14tu9e6rDx3z6/no2a/sVRmU5bVsQ=;
 b=a4jSFM/Yhfi7AaMtv7DlXmM7QRTwDjPGunXVWYjNUMwtNjiReP6IN1oGclEO0F7qN3pwXl6EDgy7EbbO8n5juxfwOctCUK0W9rCQ4P1+zce3e18coF+LBIBFyPPO2JHKZi9Yt/a7OYS7WQbgFPTmkckvxaMMLNyyVQkACtciTIo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stefano Stabellini 
To: 
CC: , , ,
	, , ,
	, Federico Serafini
	, Stefano Stabellini
	
Subject: [PATCH 5/6] x86/asm: refactor inclusion guards
Date: Fri, 16 May 2025 16:21:29 -0700
Message-ID: <20250516232130.835779-5-stefano.stabellini@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: stefano.stabellini@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CF:EE_|LV3PR12MB9093:EE_
X-MS-Office365-Filtering-Correlation-Id: 50c262b4-0e9b-4bb1-6e45-08dd94d06f19
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?XqYaRiVgtYC3IH4lCswyyD1yTDk9EXcntlAD4v8+DAz2RE7YbQYiwQzVOnyh?=
 =?us-ascii?Q?RkRFJrosUh7bvZmjHEOmyMyydRqi8WXensNxyHvyZQxYnMyJc/fYqZbCJMHN?=
 =?us-ascii?Q?Taey6QE53Zh4XAcEL10qgCooazax81u9P2BQD5ylji6OfGf2+4Qau4CgvsCh?=
 =?us-ascii?Q?UWKN9mg8PFYcIIsfZBqmqjDElCYDS8dXuUDslvadBiqVJxFU0pvdEGyuPG1S?=
 =?us-ascii?Q?lsQxxXgfKy0jEYnNOohVOfKN4vrgfc7k+KorI5zD58tuLx8T+OxaqfNDyn54?=
 =?us-ascii?Q?JDjUd7bufHHeZ3XdMovcGR4qpfaChUqpfmO6yTrJsygQzbR4POzJvSqvCU1h?=
 =?us-ascii?Q?YHzlArQH83vTQtjUDzwfU3d6RNeODsViKjBwPzUW5mO29jWr03KDFfzWKuio?=
 =?us-ascii?Q?4BZ6dCcupbdXnHUDEg1559z8bDjOelbSp9zBKJBrzdccnugDPwC2vRDpjIjK?=
 =?us-ascii?Q?/vFupmeL5IKy29wOoojShIq4lzNPFWoGx164rhExSOhM1Bar09CYT+uwkd6C?=
 =?us-ascii?Q?fH2VVe6rJJGuBwfDhMh1EZxies61QWcfT1wec67sEPDC+P4h/bFuAG/PyXfn?=
 =?us-ascii?Q?BlKCQS+nn4Mv9zFW5Y0eVbieFHN5HWOvjGZMUKTay0+YpY9KikTMWGtje4k4?=
 =?us-ascii?Q?DFoNxUX4HTYVJAbBBc4xvULmVyYsd3DiK86QbERhjayibf5+i4ysHNE95fx7?=
 =?us-ascii?Q?HRGgHZos00OEnfw70HzqMgjMtIwJtM9oleUtBCrSP1YuQinBa3vC4tr6rnsg?=
 =?us-ascii?Q?HESXcCufbZlH/pqrx0XzUidPYlTtmKthI261nhgJsiuIeewssWbB/S7etYbT?=
 =?us-ascii?Q?lDI9RJxWvh3xMUJ56iZTirh8SLce3IYFMbvmS6ZL0uwUIDeqNmkW3TNLUa0U?=
 =?us-ascii?Q?lkHuQrckg4zEAGhgolS/M+3HcQIcvgA2J30dJODP5fa5v1+K+i8qJzVQGjoT?=
 =?us-ascii?Q?WBNLrn4BE71vQSwMao/+5Nn66HnRXxeTYqVT4gx3reVd+Kx3P6APf0YC7UCg?=
 =?us-ascii?Q?qRWeu3WrorUU9FCKRz6yD8cGjc10/S3m3YDmcTiEYbrqX6tDIOUYyX7s+gyo?=
 =?us-ascii?Q?+LjRVS7KBYwoDKIuqmFYlGoqy9eCBWGyFiVwQz2UcUMLCAvSemE3LMP6QHFn?=
 =?us-ascii?Q?iOs5oqYxCPO0ZUAmn3CeFhnT+hapF5jF8akTPHD6ute6lz8fBsJZ64i/qyDd?=
 =?us-ascii?Q?Id2VNJrorVkl5NG3hC9i5NKeZKe458JFwORoASuKsBot5JZ84HLi0e9JmP+i?=
 =?us-ascii?Q?inNquz6osiErf5YBDrbHsqmIQOPSkD4OgyQm8PilkHK1EuAto0Bii3pU4y2R?=
 =?us-ascii?Q?ayjo0dr0mPynGlyOaHWkqAxDFcmSuOadkryegxLcqkpbzrrog8Vu2oaJwa3x?=
 =?us-ascii?Q?OHUij3NgI0cLt9G1duB/xnjICSXO1ggD6USYVLYAKEnfUVbCtwao80hFY4nJ?=
 =?us-ascii?Q?69qvqb5T+8xfvmSTEimm2K9qwe2HnRF+ofi0+i9HUNqdLSlg5QJypjEPj2ui?=
 =?us-ascii?Q?F4uqxt3s3DngOFeWeV/LdgMwE40OcmzRvqcE?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2025 23:21:49.3256
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 50c262b4-0e9b-4bb1-6e45-08dd94d06f19
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001CF.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9093

From: Federico Serafini 

MISRA C Directive 4.10 states that "Precautions shall be taken in order
to prevent the contents of a header file being included more than
once".

Refactor inclusion guards to address a violation of Directive 4.10
and follow CODING_STYLE.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
 xen/arch/x86/Makefile | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index bedb97cbee..ce724a9daa 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -261,17 +261,17 @@ $(objtree)/arch/x86/include/asm/asm-macros.h: $(obj)/asm-macros.i $(src)/Makefil
 	$(call filechk,asm-macros.h)
 
 define filechk_asm-macros.h
+    echo '#ifndef X86_MACROS_H'; \
+    echo '#define X86_MACROS_H'; \
     echo '#if 0'; \
     echo '.if 0'; \
     echo '#endif'; \
-    echo '#ifndef __ASM_MACROS_H__'; \
-    echo '#define __ASM_MACROS_H__'; \
     echo 'asm ( ".include \"$@\"" );'; \
-    echo '#endif /* __ASM_MACROS_H__ */'; \
     echo '#if 0'; \
     echo '.endif'; \
     cat $<; \
-    echo '#endif'
+    echo '#endif'; \
+    echo '#endif /* X86_MACROS_H */'
 endef
 
 $(obj)/efi.lds: AFLAGS-y += -DEFI
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri May 16 23:23:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:23:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987746.1372988 (Exim 4.92)
	(envelope-from )
	id 1uG4Ov-0000lm-7A; Fri, 16 May 2025 23:23:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987746.1372988; Fri, 16 May 2025 23:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uG4Ov-0000lf-4K; Fri, 16 May 2025 23:23:37 +0000
Received: by outflank-mailman (input) for mailman id 987746;
 Fri, 16 May 2025 23:23:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4Ou-0000lN-7w
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:23:36 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c9a9e27b-32ac-11f0-9eb6-5ba50f476ded;
 Sat, 17 May 2025 01:23:35 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a0ebf39427so2453305f8f.3
 for ; Fri, 16 May 2025 16:23:35 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca8896dsm4253699f8f.73.2025.05.16.16.23.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 16:23: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" 
X-Inumbo-ID: c9a9e27b-32ac-11f0-9eb6-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747437814; x=1748042614; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Gs+W4avg9rzloGEWyeULyfi7kt4lquxj3Poh2XAH+qU=;
        b=ndcSkwlza+BkLjPzraksXR5TPxzRI65r7djdQrRGN5gvzjN+uSPFztxp26YEfoG/e1
         oCtS/EfIxP+0VzqxnOYm12IjP/C29U4EIBkaMAnigI5Atf6c1leYsx8yJ2mUREZs2YLT
         sEDRjZzWw1bH2W9nVVaChQwU9o83QdxnjZNOw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747437814; x=1748042614;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Gs+W4avg9rzloGEWyeULyfi7kt4lquxj3Poh2XAH+qU=;
        b=ZLYui1FtlsjlqoFJc44Sqzh9YwmpUGnQZ8jtXgel+2gbtwGfX5Y5qUcCUi78QyPlqC
         YbjeLL/0W0A8yqQnbXvmwXSIPdxzIt6gPBr0eekyDBPDeOS1xJjsZz00ZDyb4kP0tcN4
         zGA74Be78muwKQveu8N+Uy5FRnt2bo0QlQd34QySdXdQDOuEEw/e9XWq13Zcan552bjH
         kykixuJbL40icPLv6umE+CT2SnsVoZTJ77XjxpzmCRSsQLPj26RjcH/zkLgHFM5ULMIG
         nwXptblCUgIaOCkOEHON8GGC6aewWUzbGvaA8om4uLne/HaOgBjb+d1fO7J+HohpLaDN
         zwEw==
X-Forwarded-Encrypted: i=1; AJvYcCXLQzg9ozPqCVRx05j67Y9aX9JIeENeIhAaTM/OowKuLTqhe0lDCpLPuZ0ivMUVWKmvTKvgRQQ5K8E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YygEEa/hP0MzWZ9M6IQENreidJFFy562tcTPIxRN4Cb14SA0xcY
	68cSv741JkPwqhxg20qrKY7oW0qeGoP6xRb+ADwJn1432QSJzdMKbkzXBBHHIm+FQZU=
X-Gm-Gg: ASbGncv+aQmqFogeL/3hqfZxWV0QFZoYJ6Au8/ZKJq10LFFxR3tYKn0hcPE41DCtyC/
	M5N9TSnljcm9tQH8QpDEDa3/+n7ALS/wZDbr95rgGiB0+etVnU0xDMVtV1vURiiF1eeFmrZ9W06
	ZfEdIaL1YA0WYMowoFBG7Jm/N+PeFflxVc409RF1g3wsxm4IJ2v1nmlDUHgvTfrQno95vP/LoFz
	o79biM9cE4Wtzj9AyslbzXmilwTicMrZH7HhsIOrKKB8N3jHHmkFSwIdda7p9U0xEyeXI76Vtu0
	bbW3eKAZiiGCc+K573xUfePXxlFzCgh0iKrswksj98rxki+cJUll2UPOncstMRb81BJmsiuQKP5
	lgA/JNq1ctzDn8iCY
X-Google-Smtp-Source: AGHT+IF+mUzai3UTwDS9H8t3sz7tnZUqHgkDTGKruOuuwscFaaCgX5DJ64pd1BttB+aDf/1jYScAnA==
X-Received: by 2002:a05:6000:1884:b0:3a3:4bac:1421 with SMTP id ffacd0b85a97d-3a35c825ac2mr5770558f8f.22.1747437814319;
        Fri, 16 May 2025 16:23:34 -0700 (PDT)
Message-ID: 
Date: Sat, 17 May 2025 00:23:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] xen/arm: add inclusion guards
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org,
 roger.pau@citrix.com, sstabellini@kernel.org, bertrand.marquis@arm.com,
 Federico Serafini 
References: 
 <20250516232130.835779-1-stefano.stabellini@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: <20250516232130.835779-1-stefano.stabellini@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17/05/2025 12:21 am, Stefano Stabellini wrote:
> From: Federico Serafini 
>
> MISRA C Directive 4.10 states that:
> "Precautions shall be taken in order to prevent the contents of a
> header file being included more than once".
>
> Add inclusion guards where missing to address violations of the
> guideline.
>
> Signed-off-by: Federico Serafini 
> Signed-off-by: Stefano Stabellini 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Fri May 16 23:24:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:24:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987752.1372999 (Exim 4.92)
	(envelope-from )
	id 1uG4Py-0001Mh-Fu; Fri, 16 May 2025 23:24:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987752.1372999; Fri, 16 May 2025 23:24: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 1uG4Py-0001Ma-DE; Fri, 16 May 2025 23:24:42 +0000
Received: by outflank-mailman (input) for mailman id 987752;
 Fri, 16 May 2025 23:24:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4Px-0001MQ-Bk
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:24:41 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f026171b-32ac-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 01:24:39 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a365a68057so177296f8f.0
 for ; Fri, 16 May 2025 16:24:39 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442fd4a0a5dsm51194205e9.0.2025.05.16.16.24.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 16: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" 
X-Inumbo-ID: f026171b-32ac-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747437879; x=1748042679; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Gs+W4avg9rzloGEWyeULyfi7kt4lquxj3Poh2XAH+qU=;
        b=QaavKXG9ko/EiKGKMA7nbzL8Mh0kBo8ocDpcPRF0+DRJYT5xdN6xxD8Etn/MzvA6fT
         I1yvpR38ojeX2vzdjTsYOXzPEALmO3dLhGP+IkgLPBnh48EM633UQsNBjp+uXJZnC50k
         N6KFCRC7j1A5HBp/WIDDlOW5njzk1pydAja7s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747437879; x=1748042679;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Gs+W4avg9rzloGEWyeULyfi7kt4lquxj3Poh2XAH+qU=;
        b=XU0byimvqx1t2UBO3ToKbfvrT5WUhD4YJiVBuOtXoY+NvB+jiLo0aACETvPwpJEhhm
         NTXs/RjFHR1bmO9QjP86uKwVGFY+OrVeknhtRjgrZ86jQfrA2SVddavmlS9UCGuD6KPN
         AzEwERBVx/HqRhrQs1eSIltC/WTHzePCf4JS+uSA+Pj1FBdrxcCUDe44Ek4QKgxM8U+t
         iijS9jlazAHijTp1r9HiQ+rxVg9l7g0CShPLk170ygxFLw+06L8sC0rbgJxQmJc38MNM
         4caSZ/YhnnjTpciP0nefRx9xfFa6lN4xVxqDULiu3/q5ZN3mDO+s4KuJjz/Bx0bm8QE7
         gdcg==
X-Forwarded-Encrypted: i=1; AJvYcCVM/1GrrGraoswQ8Zu7bIwwKxzX8uNlemzH2LTYqBp9mYJ1CGKdEtVbn+j4I1yoQ5nVMP9H9+EN2+E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxg5rWxpuvzhoWThRL8nQyDTuuzPZqrB2SrZFaIIOEwVWlqS5V/
	Fqupa96SmOHO3w1/IG8qfHlWCWzOiCmCd8QFE0aXyq66NJrQDA3mw11FtX5J5/nePvfbTQ6SZLh
	tnXyj
X-Gm-Gg: ASbGnctSJIEq3I0pG3SflsWnSw43T+d94Acr9CBde4jVe4nETr9sV5e6PqXGwtCfGzu
	seaE3dxVhHvbjW8HI8eYSX3chmhv6R0sesXCdW64YcydkOXN6j0r0nY/3uGum8TIUea2FgUClun
	hoVTMIycI/sHY5g933nsWTFMXgA5rLMRMDQhQWb+UipgBk1yP4KIOOUZrcMZVEP0f16qdLYXcwc
	59QHzW2AbnDDKHx/kfWnyqtSCjPhYIVEq1j3F4buuutW9xJd781NhzO2d6yFXnphKigAGf/FQcg
	ymG7g9tnfw8QAYplt/DXWbG69RP946yqjlEY+DOgBkv7kcr17atw0cydx9KdQsRtNx4s8YRtWKy
	QeolDjreq6p1Y3RdV
X-Google-Smtp-Source: AGHT+IHMpL1ahXu98M5O7fxr4CAAuFIc0z60PHexSuTY7dm+p6Tah4XL6MufrOYhCYXVg3RvQtPUUQ==
X-Received: by 2002:a05:6000:2913:b0:3a3:655e:d472 with SMTP id ffacd0b85a97d-3a3655ed55cmr798519f8f.47.1747437878909;
        Fri, 16 May 2025 16:24:38 -0700 (PDT)
Message-ID: <9c00c3b0-bbf2-42e9-84e7-8d61ac44f4e1@citrix.com>
Date: Sat, 17 May 2025 00:24:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/6] xen/x86: add inclusion guards
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org,
 roger.pau@citrix.com, sstabellini@kernel.org, bertrand.marquis@arm.com,
 Federico Serafini 
References: 
 <20250516232130.835779-2-stefano.stabellini@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: <20250516232130.835779-2-stefano.stabellini@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17/05/2025 12:21 am, Stefano Stabellini wrote:
> From: Federico Serafini 
>
> MISRA C Directive 4.10 states that:
> "Precautions shall be taken in order to prevent the contents of a
> header file being included more than once".
>
> Add inclusion guards where missing to address violations of the
> guideline.
>
> Signed-off-by: Federico Serafini 
> Signed-off-by: Stefano Stabellini 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Fri May 16 23:27:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:27:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987767.1373009 (Exim 4.92)
	(envelope-from )
	id 1uG4SX-0001wV-R1; Fri, 16 May 2025 23:27:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987767.1373009; Fri, 16 May 2025 23: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 1uG4SX-0001wN-O0; Fri, 16 May 2025 23:27:21 +0000
Received: by outflank-mailman (input) for mailman id 987767;
 Fri, 16 May 2025 23:27:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4SW-0001wF-5h
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:27:20 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4ececa03-32ad-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 01:27:18 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-43cf06eabdaso24029455e9.2
 for ; Fri, 16 May 2025 16:27:18 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca4d31fsm4245267f8f.6.2025.05.16.16.27.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 16: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" 
X-Inumbo-ID: 4ececa03-32ad-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747438038; x=1748042838; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=EbB1TmCF6/lzHlUUOQ2yuQHZP4GsZ+gKkf/sN6XE2jw=;
        b=RbfRZf9D7dUya9A3aRBbocUjWjitZXW4pOuTtBAZkI5If6H1iR2a2CqI7HZUvvvMPw
         T61JNi+HhiTDpT2d/p1a3lFnlZbFyRtxVaDbQn4FWvgINqGUStx8/O2rf5RApt+uOgbs
         Luwq2j+833255G5iAdtqOaft6KPcNQL5ZvyGE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747438038; x=1748042838;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EbB1TmCF6/lzHlUUOQ2yuQHZP4GsZ+gKkf/sN6XE2jw=;
        b=j8xT1ui/1zFZhi2uvybFNzNgLZ+XYxfz2LqX/p4n9daZPStGFhUzkM8RvczsP3qzfy
         WoF3AqfIVmv6tqu6heqzk5XqswbgUiNEeKzBwsF9bmtkblIS/PyVycJy9C/KtdrTLsES
         yFQAR1bYl8VTKyJg8hHeGSmhYuZTNtKeSaWQVdETdsVXfeb3LGgRcbb1dTh4pH1LD6JG
         8YXrzbwMPmIIHu4aLkbuU9ngY2rRIOmpiBPSki7tSMRgQvnqmoLMKUQkz3vaHu+Dxjc7
         mR3zitm7aE5RItMfWfHED0BSPI++5SPVRbyIvkTjTDITucjFHTTSnB3HXsDXQzoALfAL
         5/CA==
X-Forwarded-Encrypted: i=1; AJvYcCVjXlj5RrqHl1FGDexT06bBp2WFi7kf+Hol1/ixezER9l1aDQMNMX7zVkKQ5x5TKYGCZIMHpg7SipE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwyhJFeXVX2JxVND0hOq0t9tPDZbDG5ouUkvCpI1hhaLGNdKew2
	X/oevT1WWyVi5xTGg24sxkE1CvNEA90w8nzGU7+SM6OL1Q9u0/BflGQyntmGTMK2NI8=
X-Gm-Gg: ASbGncvV7xN9gHpTpOPFLGLTtXP4li2w3Jn71YtuBR2SzT+Rt4AJyoYi4UXXRcBqMm0
	vzfkboB0ClsiQgnRjh1i5yMmxAC9pmQHnxosBjaUhaEO3qDk/inu/UqTzob5ch2aOWT0M5eELV4
	ObgHQ9V6CWoTVWeODlq3qQZuOeboSJ8kNT0G1O/pr5zVbHSCo0cU6Eh0f9GBjhC9QhPPPDsmc39
	bO5vPop/BPP8DhWFDBG3yppTNgxKg8pJBmiIGas28BNO8+vpNa2EGdKQEuzWJQIZG7zdvCtX+pl
	yk33Jhb8FzQuupCyfc/OVsPYWzIBVvM7ofc9q51fqW78D+J0WSf0+DKx9XCWmLaTvttgqZXrp33
	f7QpMTaDONsg9f42TKYPnE11K+oI=
X-Google-Smtp-Source: AGHT+IGxgXvOgAXFE0w3M07n8Fa+RkNV8CoVW0Qkg7uVrr+wR56kjFasq5/tA7Cwd+32/oOxBWdwKA==
X-Received: by 2002:a05:600c:3e10:b0:43d:3df:42d8 with SMTP id 5b1f17b1804b1-442fefd780fmr42374125e9.6.1747438037751;
        Fri, 16 May 2025 16:27:17 -0700 (PDT)
Message-ID: <9b94e43e-3357-41c2-b982-26ed7ffb2fa5@citrix.com>
Date: Sat, 17 May 2025 00:27:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/6] xen: add inclusion guards
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org,
 roger.pau@citrix.com, sstabellini@kernel.org, bertrand.marquis@arm.com,
 Federico Serafini 
References: 
 <20250516232130.835779-3-stefano.stabellini@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: <20250516232130.835779-3-stefano.stabellini@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17/05/2025 12:21 am, Stefano Stabellini wrote:
> From: Federico Serafini 
>
> MISRA C Directive 4.10 states that:
> "Precautions shall be taken in order to prevent the contents of a
> header file being included more than once".
>
> Add inclusion guards where missing to address violations of the
> guideline.
>
> Signed-off-by: Federico Serafini 
> Signed-off-by: Stefano Stabellini 

Reviewed-by: Andrew Cooper 

> diff --git a/xen/common/decompress.h b/xen/common/decompress.h
> index 4683eb6c7e..034c833665 100644
> --- a/xen/common/decompress.h
> +++ b/xen/common/decompress.h
> @@ -1,3 +1,6 @@
> +#ifndef DECOMPRESS_H
> +#define DECOMPRESS_H
> +
>  #ifdef __XEN__
>  
>  #include 
> @@ -22,3 +25,5 @@
>  #define large_free free
>  
>  #endif
> +
> +#endif /* DECOMPRESS_H */

This is borderline too generic, but a COMMON_ prefix doesn't make it any
better.  Oh well...

~Andrew

P.S. the decompressor infrastructure is several stacked disasters and
needs redoing from scratch.


From xen-devel-bounces@lists.xenproject.org Fri May 16 23:30:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:30:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987774.1373019 (Exim 4.92)
	(envelope-from )
	id 1uG4V8-0002au-8N; Fri, 16 May 2025 23:30:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987774.1373019; Fri, 16 May 2025 23:30:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uG4V8-0002aQ-4p; Fri, 16 May 2025 23:30:02 +0000
Received: by outflank-mailman (input) for mailman id 987774;
 Fri, 16 May 2025 23:30:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4V6-0002Si-QL
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:30:00 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id acb9b335-32ad-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 01:29:55 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a363ccac20so611992f8f.2
 for ; Fri, 16 May 2025 16:29:55 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca62c70sm4382829f8f.54.2025.05.16.16.29.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 16:29: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" 
X-Inumbo-ID: acb9b335-32ad-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747438195; x=1748042995; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=HKK9RX4hR0A5SUlwzKQTLFqzQ1hDvrAFwLmvW3QQULc=;
        b=vt3avghyseVEtYw4p4hLlUcSgOPbQ/pPTxcTmzJkSxl8BcqHI6PvzBELKtVSBSFVSb
         iGe23Ea56ZGxj/faJSzAKwjN4dNiRv/zB8s64soj3vtdBg16wPafG0TH2V9gRgQXpLbZ
         QGigG14DaTmUkUYkezaugBqtvEvszrCd/85mI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747438195; x=1748042995;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HKK9RX4hR0A5SUlwzKQTLFqzQ1hDvrAFwLmvW3QQULc=;
        b=eWRnzZcvDmzeHDEGkYMLeEq6T5hvzQTvp+tg7NWygfUjztgZS+COpBrADg0i+jXNxI
         70tCwSAVhMjEgrHsBYqxpCulJAEmyR24O7kHEhZb379kTLJ8w0x5jsQ27cdtgLtWeETD
         RFuLxL9v6dEx6zW+SKmCGUPpCzsF8H/xrk1qDihQhS1Qm7SDZ2nl6FTDKyRNe9HmUEED
         Ec8sjo0Jtf2A29cXNk7SB4U9vxrkgvRrjyQh3/oUSI4zcGkUiUCfWUeHlQPOsZ+IX/Xq
         clfPZO232zLjVMqRXy86ApxOiVezClqloTPF6ldCfk2ugYFRSWRadOobjal5y2F3++w7
         D3Ug==
X-Forwarded-Encrypted: i=1; AJvYcCX1GQ3hX7OLSftuJJSxcmNpCRpVPLvfhleOCPqWFxorKSdNhojatK5Vh7Kj0JQb4mL6eiBZjWu6SjQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyuLv3jG7SP8V/vJbooyY4AXJ5K0utns2IBKbYkVis6Cz0NsT8K
	uNrllXILKIr3qOSl8g2mJG+y0cM4WyGo29u1j2g4M0ewynJlbpmTdl2Cd8/2l+gmLv4=
X-Gm-Gg: ASbGncutNEU4ORaEEct0JDYwXQd3D7lbQrEA3LLJM5M+3ru43TIfpqQ4ReX5HIVLZzS
	2KFk22j9l0JkoUtm1c9xkXvJ0e/+ns4que3PpKEHyzwTW0Z/3QbPzJvJS6dl1kED+qihwyetjHI
	4JzDpMh2oxnXFuPX/ETFkKxrVCbiGwkwkPbkw2CPzDGMBcx3XhrAVlMH3hI/baFcSqP8cWEQInc
	fdv4DTnJTMOR/Fam8z8b06zvs0QmibNkSIOeP9oCwdfYCv8D1MDA7mrlW55TDcslcAqD0NWPM0I
	wZevZYuQ8d5MxQiBU/i7QNB2RX2I2af/BPkd0pDeLt2n0GRkv3ygwUJBOvizl9F+y4r0BMFe3RQ
	xjV08XQn5ZmnIK2d4
X-Google-Smtp-Source: AGHT+IGrcLeQ/94xxk+A3dFEzG1GERItZMl+P1wUOYX4bUU3PFpVR8ume06p+yRRSWEWeXRfd2H/Cg==
X-Received: by 2002:a5d:64eb:0:b0:39c:12ce:6a0 with SMTP id ffacd0b85a97d-3a35c826787mr5432307f8f.21.1747438195307;
        Fri, 16 May 2025 16:29:55 -0700 (PDT)
Message-ID: 
Date: Sat, 17 May 2025 00:29:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/6] xen: refactor include guards
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org,
 roger.pau@citrix.com, sstabellini@kernel.org, bertrand.marquis@arm.com,
 Federico Serafini 
References: 
 <20250516232130.835779-4-stefano.stabellini@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: <20250516232130.835779-4-stefano.stabellini@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17/05/2025 12:21 am, Stefano Stabellini wrote:
> diff --git a/xen/include/xen/err.h b/xen/include/xen/err.h
> index cbdd1bf7f8..5bdf8b215c 100644
> --- a/xen/include/xen/err.h
> +++ b/xen/include/xen/err.h
> @@ -1,5 +1,7 @@
> -#if !defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__)
> -#define __XEN_ERR_H__
> +#if !defined(XEN_ERR_H)
> +#define XEN_ERR_H

I know this is just rearranging the existing like, but both the
defined()'s should turn into the more normal #ifndef's now they're split.

Same for softirq.h

> +
> +#if !defined(__ASSEMBLY__)
>  
>  #include 
>  #include 
> @@ -41,4 +43,6 @@ static inline int __must_check PTR_RET(const void *ptr)
>  	return IS_ERR(ptr) ? PTR_ERR(ptr) : 0;
>  }
>  
> -#endif /* __XEN_ERR_H__ */
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* XEN_ERR_H */

I realise this is personal preference, but for the end of a header like
this where each is annotated properly, I don't see much value having the
extra blank line.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 16 23:57:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 16 May 2025 23:57:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987833.1373028 (Exim 4.92)
	(envelope-from )
	id 1uG4vg-0007xq-BR; Fri, 16 May 2025 23:57:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987833.1373028; Fri, 16 May 2025 23:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uG4vg-0007xj-8p; Fri, 16 May 2025 23:57:28 +0000
Received: by outflank-mailman (input) for mailman id 987833;
 Fri, 16 May 2025 23:57:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG4vf-0007xc-2q
 for xen-devel@lists.xenproject.org; Fri, 16 May 2025 23:57:27 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 83752410-32b1-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 01:57:24 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-43cfe63c592so26818005e9.2
 for ; Fri, 16 May 2025 16:57:24 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442f33691fdsm128034525e9.5.2025.05.16.16.57.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 16:57: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" 
X-Inumbo-ID: 83752410-32b1-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747439844; x=1748044644; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CPVqfVtdG0aOQXYN7JFT5fl0p6ZdZ28JyC5/O6ufdzc=;
        b=SsAY9zw4vxT/Fe1u1t9FuB/LYYnqlSFXXowAdq5PPCIOrBAR2puGP0WiKII6hOu52t
         8VwQBrzEdVoVSitlfFmdNA+CGFWI6hs5quMhU2BUmrJi2tboKhHHKoWy1bVyzNaAEpQT
         OailsxKTsHecte4JhqT1zgeo5mEuK2UGIhyms=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747439844; x=1748044644;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CPVqfVtdG0aOQXYN7JFT5fl0p6ZdZ28JyC5/O6ufdzc=;
        b=sVsFyMqXfCwX5BSHVMIR8evK9ehCA8On7uwNyBloXjAFkoyiOm7qVK7yPXuetAGCAF
         CEC4eXd1EL72TamvTRZtDklLnEN3VLLzw/xUsnT+yM8QdqjWFfmwrN6cSgq+aaQj7HOq
         XekY4lQtYDpk05M5O+J5hYSYjOLg6EOuEI53mdE1QZomCps8b/cN32DmRCwqSrKQge0r
         1FSQfK+rbaLGAMcNn8Qeo34Th8iJM66z1GZFKyA6Eq2bEwEqS1TleAoljnQgIrVVJxwI
         f4d9vTP58t0ys6C6j6jMCrjuxDkBceFev3yfG8veD97GrDkwfRkZBEmCaHArNS0civoe
         jyLw==
X-Forwarded-Encrypted: i=1; AJvYcCUOJWKyToCrk4VD7VjZvUCauUwuwWj1Lxchi9vHp3+NPX43b6UjArD2jPeAC6rU3KKrZZLPAzP1qHs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwFpQY1Vzf9/oEPaCuJ8o7yxxquyvC/iapow16lLataAf06P+Ri
	Z32A9yEjaW2l1SclhuXW0zL2jRcR7xNMEjGFBdgnFDBlKPPjQHGcHchym6LpWiLmD0w=
X-Gm-Gg: ASbGncsqB22LAPKzv2+Wr9Q3cCJpLwu7g64qiu30VNvbKWcTs3gFZSN+xMq+y6ijaqT
	RTMTV05/vvArGuV3idUc7MKdc2BubxwxrPLijVUAU7zKp8bWGZq0JGpkCBb59rW4CYOZWbhO5gb
	QRs9BBMPa50cUT691dUctSiJQgPtZAuq6/mq+PnGyBzQ4vlEoqSMbloV/vP/Ta+1vtzT0ccQb7a
	buerR64y4lGExYXHIAwdPH1VfTAKF80XFzt90tYVL9NNuNkSQdRHF76l53HswrDLm+xCjPIeqtt
	QNOV65rmamZCgMmHPvxsZkqb3110sgW3XiHzB3pKJFPBw4RJxe1yNhoXwuw+o+wK1budyIA2p8k
	7RO/MGBCAWornhb5g
X-Google-Smtp-Source: AGHT+IGw2UDdXk2QwwLiFMjNVigLC6hhLpudBczv1ENwk9+Zux3USypaba0sDsVSZqwhLSyGzSCaVQ==
X-Received: by 2002:a05:600c:8285:b0:440:6a1a:d89f with SMTP id 5b1f17b1804b1-442fd60a587mr56834945e9.4.1747439844000;
        Fri, 16 May 2025 16:57:24 -0700 (PDT)
Message-ID: <5c2aa885-8877-4708-90cc-d65a76b729b3@citrix.com>
Date: Sat, 17 May 2025 00:57:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/6] automation/eclair: update configuration of D4.10
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org,
 roger.pau@citrix.com, sstabellini@kernel.org, bertrand.marquis@arm.com,
 Federico Serafini 
References: 
 <20250516232130.835779-6-stefano.stabellini@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: <20250516232130.835779-6-stefano.stabellini@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17/05/2025 12:21 am, Stefano Stabellini wrote:
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 9c67358d46..3fb6d9f971 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -72,11 +72,19 @@ they are not instances of commented-out code."
>  -config=MC3A2.D4.3,reports+={deliberate, "any_area(any_loc(file(arm64_bitops))&&context(name(int_clear_mask16)))"}
>  -doc_end
>  
> --doc_begin="Files that are intended to be included more than once do not need to
> -conform to the directive."
> +-doc_begin="Files that are intended to be included more than once (and have
> +a comment that says this explicitly) do not need to conform to the directive."
>  -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is intended to be included multiple times\\. \\*/$, begin-4))"}
> +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^.*Explicitly intended for multiple inclusion.*$, begin-3))"}

xen.git/xen$ git grep "Explicitly intended for multiple"
arch/x86/include/asm/cpufeatures.h:2: * Explicitly intended for multiple
inclusion.

I'd suggest altering that one file, rather than adding an special
exclusion pattern.

> +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-2))"}
>  -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3))"}

These seem to only differ by the begin-$N.  Why doesn't the regex work
in both cases?

> --config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/generated/autoconf.h$)))"}
> +-doc_end
> +
> +-doc_begin="Autogenerated files that do not need to conform to the directive."
> +-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/generated/autoconf\\.h$)))"}
> +-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/xen/compile\\.h$)))"}

I see your exception, and raise you some sed.

diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
index 3151d1e7d1bf..9206341ba692 100644
--- a/xen/include/xen/compile.h.in
+++ b/xen/include/xen/compile.h.in
@@ -1,3 +1,6 @@
+#ifndef XEN_COMPILE_H
+#define XEN_COMPILE_H
+
 #define XEN_COMPILE_DATE       "@@date@@"
 #define XEN_COMPILE_TIME       "@@time@@"
 #define XEN_COMPILE_BY         "@@whoami@@"
diff --git a/xen/tools/process-banner.sed b/xen/tools/process-banner.sed
index 56c76558bcd9..4cf3f9a1163a 100755
--- a/xen/tools/process-banner.sed
+++ b/xen/tools/process-banner.sed
@@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
 
 # Trailing \ on all but the final line.
 $!s_$_ \\_
+
+# Append closing header guard
+$a\
+\
+#endif /* XEN_COMPILE_H */

and now compile.h looks like a normal header.

~Andrew


From xen-devel-bounces@lists.xenproject.org Sat May 17 00:10:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 00:10:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987848.1373073 (Exim 4.92)
	(envelope-from )
	id 1uG58E-0003SA-4f; Sat, 17 May 2025 00:10:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987848.1373073; Sat, 17 May 2025 00:10: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 1uG58E-0003S3-10; Sat, 17 May 2025 00:10:26 +0000
Received: by outflank-mailman (input) for mailman id 987848;
 Sat, 17 May 2025 00:10:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG58D-0003De-3Y
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 00:10:25 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20604.outbound.protection.outlook.com
 [2a01:111:f403:2415::604])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 52a380a4-32b3-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 02:10:22 +0200 (CEST)
Received: from DS7PR05CA0102.namprd05.prod.outlook.com (2603:10b6:8:56::22) by
 CY8PR12MB8244.namprd12.prod.outlook.com (2603:10b6:930:72::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8722.32; Sat, 17 May 2025 00:10:18 +0000
Received: from DS2PEPF00003447.namprd04.prod.outlook.com
 (2603:10b6:8:56:cafe::95) by DS7PR05CA0102.outlook.office365.com
 (2603:10b6:8:56::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.11 via Frontend Transport; Sat,
 17 May 2025 00:10:18 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS2PEPF00003447.mail.protection.outlook.com (10.167.17.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8746.27 via Frontend Transport; Sat, 17 May 2025 00:10:18 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 19:10:17 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 16 May
 2025 19:10:17 -0500
Received: from smtp.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 16 May 2025 19:10:16 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 52a380a4-32b3-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=buAAEHRU1YORHJJuiu/nB4rf5mkgP0keKqv38GgoNQsE2oWhm4J5vveH+vRnEAchf1ZDFK+fqpGGKW0EvdxUDsQEqRWrDWqcQfzCA9AQup2we/6ck3FaL7PgBSvFThM1RJqcLVQ8OZLCdOvDjEe0kafoY2QVget28omJlYvgvukciiw6hCDYnfuq+IPfPy2Y20bQTM2Q60bq2jJeJN8jVCApZuE3vucfrWTzg+LD5EroGDCtXnXuKLRAmpu4zYEpiyoGaeDBOnnKhao8FHgrMWYYOYF8aryC6bjxK4Rezx+NXngXRf6hiMSRDJWqtZFHVdskWQiKF6GcOb2E6+xq2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=aGrahaZmw62enb+JyxIjlzeO4SXgBzF+7p04fVlxdwA=;
 b=KlyRAbyLSQnsxwUYv+u7+H7+6NUr1qu2vFTAPvy9PllkVHtF6rGZZORJCsmb7kmU8qJ8j382ji+DsR8DqzwflP63CmJVRaARnfrRq2AbEzAMOjTfIrEhnCF5iCllsbcagQ3T/7c8UokVZWBcWmC1j1RWxh9qXQ8qvLdNFhSa6vao8oGFd55mlKCbcU04dCklPji8nmfdczXQKO4oQ+gwDVbWNZQlSOb5MEnBLg+YUZtzAmh3+PAS3V84BeaQ7OAZvBt8ErQvGK6SOzv75v9oRNXal6eppjFQKtSRVq7pOZ24Q425PleSnCj9v6gM2R2V60u7vOiT8i5y3CYQT8USOA==
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=aGrahaZmw62enb+JyxIjlzeO4SXgBzF+7p04fVlxdwA=;
 b=2uZsGtBJUM17nk8d1ba45vWTUAl5L3c8UJ/E7smaSDcGmLGBm9dX8UNQEdAsV7qgqKCdwSiUQqYGqNtK+vhOCTHWUZ4CmPvooSq1Z7bFlpvUlNnWA3feePsJzEZIi8xVy8Z2ORcRLq1TOJh8OyzI6f73TDyVdmhbzlTRLFowxB4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stefano Stabellini 
To: 
CC: , , ,
	, , ,
	, Federico Serafini
	, Stefano Stabellini
	
Subject: [PATCH v2 4/6] xen: refactor include guards
Date: Fri, 16 May 2025 17:10:05 -0700
Message-ID: <20250517001005.860657-1-stefano.stabellini@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: stefano.stabellini@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF00003447:EE_|CY8PR12MB8244:EE_
X-MS-Office365-Filtering-Correlation-Id: 98d4bb7a-f8a6-46cb-e5da-08dd94d734fc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?YWf0aa9CPog5gLA89IvjPJX7RHBEL1sMqX70AsoqIE3N2ZonIWF0EdWAElvt?=
 =?us-ascii?Q?vALyOXAUFiQ/5NGbfMqsblqiSmwnnXvBG/Htp3B0oo8nY2qgjBx9EaGkmrI0?=
 =?us-ascii?Q?RAVHXHvFKAPTkhttXv6toLkL18aU+uQ6flPEnIJBv8HyWKB0gYA5qWuzJLMj?=
 =?us-ascii?Q?/35v9Ot8E6uXKgKu2RFOgs80uxrnxuhZ5K+5VctgXx/FD+eNSix5cQEuB/dQ?=
 =?us-ascii?Q?TAD3Brzzkjl5eDM2gOtfKdl6twuSs8ipYJjFwN25LMQ2Y//EEgPRFlaJ4phE?=
 =?us-ascii?Q?YryAvbhvyIGjgdLxG33B8v4+S5u021cJ5RqnJP0EYsCUYjW29Z/OgzuyKxwy?=
 =?us-ascii?Q?/bCPXDltESSLtI2slaJrvJfIF5R5BrXWjW54aUU/B5dlY7xaMwfL8R5a9WUM?=
 =?us-ascii?Q?Wg34t2jxtemR//XGqHUQUHqle00Cul5kEuOfW2wzmcjLFMYupyNRr4AMbLhp?=
 =?us-ascii?Q?xEJltmZROB1W6drMgcRZkQAWfih7LgglnnQ5SRVPD97jDhxsgheZI5Jtzy5L?=
 =?us-ascii?Q?34ULtK2hq5IMkBjXyk9OVpXxKcH7VVF0NCBKF8xSAMGHh0B8JQjy5ESIDe7H?=
 =?us-ascii?Q?xMv1Z44fc5nTTU1awLBtQQm8cBm1q1FVV2XBR2qVqCrG12InCM+L0klar5yp?=
 =?us-ascii?Q?ca38LhWDwtwogmhjXTYJxeFj6bXkwtBojWJiE4EkyMxtl3lyzYcPjfotIseA?=
 =?us-ascii?Q?5KlhHnnuNhd7i20uLTOMVoNJPYgy7IJE1SEBf7G9XxedU3Kk48MyVou79g/g?=
 =?us-ascii?Q?7dauU4+k8wcGF3MnSmUMqmeln1a3shacvOcEqDze5qffxkjJU/9L3RazEJ91?=
 =?us-ascii?Q?PFiNbmZNZjQrMku0xwR4aMTZLd2ZfPB1fD9QyqIuFNVa1fbWjYMdxQ1+RzjT?=
 =?us-ascii?Q?2jo5oUatVWBwLIeobNI8mk5459XcFuQVRme+PJVRl505velWb3CNgJUdb3HA?=
 =?us-ascii?Q?lAxiO3R0GD+12bhvIHiSeFU+CKoq9YlAG+90Z6nKBLdFOMBgpDT9loza3IAU?=
 =?us-ascii?Q?bTaV4+eiVCMretLBlRfkXY/1XHB1BupAk/QmCwrdatUIFBlieX4ePSJl9+WT?=
 =?us-ascii?Q?JO0nsevgPckQnOLCNzX6qFXlRCJifl24Zohz9wxFJy2VyMpHW9Iv3mAl5uVp?=
 =?us-ascii?Q?aQAckWRIG0UmMrxee7EFCMVzzgiXW6GJ3/wRRHL872f3HIGXVZfiiswVy3bT?=
 =?us-ascii?Q?0hY3rJ6hxaZ0CIs9sW+vvLBjnZX/T3ukHJZsIaKJ37PN6MtFIKqKAIOpBCeQ?=
 =?us-ascii?Q?IPH/HA9cY9ajWSS+6EaIXwovgZW96QH2v82CzWnp/+K7CC9F8zz7JwYOFarj?=
 =?us-ascii?Q?YGuynrHCbprNSoy/CqpIqD7SmxYxZ/GmgqRyI3KRkeTNLEPIuBXZmYg5Pjvo?=
 =?us-ascii?Q?DPRuNmypqo8B1GXWP3a+4sApO7hXqB2jHgUELadgg2deG/MuOVPyNTHtjtAR?=
 =?us-ascii?Q?ykMM9a31tNvEhhiDeRmR/6CeNnRoZYJn7m2NdclG35fGIGiw1cn8ditUZi9b?=
 =?us-ascii?Q?NE6aU1xvSY2ylyRQ0yv9o55PVFInQRY9A9ey?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2025 00:10:18.3466
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 98d4bb7a-f8a6-46cb-e5da-08dd94d734fc
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF00003447.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8244

From: Federico Serafini 

Refactor inclusion guards:
1) use a syntax that is more likely to be recognized by static
   analyzers;
2) follow the CODING_STYLE.

No functional change.

Signed-off-by: Federico Serafini 
Signed-off-by: Stefano Stabellini 
---
Changes in v2:
- use normal #ifndef
---
 xen/include/xen/err.h     | 10 +++++++---
 xen/include/xen/softirq.h | 10 +++++++---
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/xen/include/xen/err.h b/xen/include/xen/err.h
index cbdd1bf7f8..a5971e290c 100644
--- a/xen/include/xen/err.h
+++ b/xen/include/xen/err.h
@@ -1,5 +1,7 @@
-#if !defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__)
-#define __XEN_ERR_H__
+#ifndef XEN_ERR_H
+#define XEN_ERR_H
+
+#ifndef __ASSEMBLY__
 
 #include 
 #include 
@@ -41,4 +43,6 @@ static inline int __must_check PTR_RET(const void *ptr)
 	return IS_ERR(ptr) ? PTR_ERR(ptr) : 0;
 }
 
-#endif /* __XEN_ERR_H__ */
+#endif /* __ASSEMBLY__ */
+
+#endif /* XEN_ERR_H */
diff --git a/xen/include/xen/softirq.h b/xen/include/xen/softirq.h
index 33d6f2ecd2..e9f79ec0ce 100644
--- a/xen/include/xen/softirq.h
+++ b/xen/include/xen/softirq.h
@@ -1,5 +1,7 @@
-#if !defined(__XEN_SOFTIRQ_H__) && !defined(__ASSEMBLY__)
-#define __XEN_SOFTIRQ_H__
+#ifndef XEN_SOFTIRQ_H
+#define XEN_SOFTIRQ_H
+
+#ifndef __ASSEMBLY__
 
 /* Low-latency softirqs come first in the following list. */
 enum {
@@ -40,4 +42,6 @@ void cpu_raise_softirq_batch_finish(void);
  */
 void process_pending_softirqs(void);
 
-#endif /* __XEN_SOFTIRQ_H__ */
+#endif /* __ASSEMBLY__ */
+
+#endif /* XEN_SOFTIRQ_H */
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Sat May 17 00:10:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 00:10:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987847.1373062 (Exim 4.92)
	(envelope-from )
	id 1uG589-0003Dr-Sb; Sat, 17 May 2025 00:10:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987847.1373062; Sat, 17 May 2025 00:10:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uG589-0003Dk-Pz; Sat, 17 May 2025 00:10:21 +0000
Received: by outflank-mailman (input) for mailman id 987847;
 Sat, 17 May 2025 00:10:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG588-0003De-Us
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 00:10:20 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4f2bbe7c-32b3-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 02:10:15 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a1c85e77d7so1756403f8f.0
 for ; Fri, 16 May 2025 17:10:15 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35fa8c6d6sm3860845f8f.26.2025.05.16.17.10.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 17:10:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4f2bbe7c-32b3-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747440615; x=1748045415; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dF9mAOutupKeQnbfu1RUXC8+QVcyXFml3qN+hoAJMlk=;
        b=jZ4H1vGN+tB+cH4gtQQjJrO0nyfvvglJfdPV5miHUY5t4Hm9RR7ZunGQWR49Cdid3x
         apID8nlc8DlrNKuJOCX1sktj/NI9H1Ceegu1M8Q4MnlWKZP9xyOPM3+ydJ2M+/dgybEc
         6zrMqdR/gXZxYcEein9dgsAou9ovs88retu9k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747440615; x=1748045415;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=dF9mAOutupKeQnbfu1RUXC8+QVcyXFml3qN+hoAJMlk=;
        b=b5QnQHTTTkKZlXj/ZO/s6D2eRnFKrIs/oR94Ha4H4012vWHJiZhaLIYuJt44g3q3I4
         ZdJBfRMT7hI4jNiVzi1IOeOm017/ZCH3U9x67NKy+5KUcV16G+KN5Hq92u6qt/iA85TH
         12hpmrTKpYshXpiwsWUwAyXKtfuWaDdPtJ20Wwqxa/t/kiZLeWTpUOhuE0j3fyOzVPhQ
         c7bhUReuQzl1rVTSowCqq83kDC25H8qbBAJMcflWOgF13qggw5XC43p+ktUBLOHZqiFi
         vU8TZmhnw5ArqRK7u6LYKqiqtWtonywv98iHeDW58DfCokuYv2zPPTxltazhR/05vKuj
         wKsw==
X-Forwarded-Encrypted: i=1; AJvYcCU9ugAMo3mYmH7VmNrr7llffIS/At3xINWCJ0LrIz3je02+426ZGLjv80Aad28Y3ayseT5amWq8iY8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzun8fLNq8PMIMqpQegHKR5FMMiBL3V8fyvavoMgzYNrFoQayO1
	QI5sMa8oFKP/9DrjfKaWsasrROBe19meu4kcR2dIF2Bm2X7xcX4Ra05VbMlyd48Cjo0JrCS8aje
	AXIrH
X-Gm-Gg: ASbGnctsd259OJ1xGIb4ad2luKEGnZAQphgj+604d/hhihXaEiAILg/ahJ6B+V14TT8
	/MsJOHwNVPxOyt7hkIX8O91yxLo0THy69hetPQZFMjUuWo+6DBriOCG5gB1VPx+xY6V4Fdgv3C1
	tXa/MtQQjs1B72oWJSsjGmxWCPNyj6+5PBR94CfftJNGMCzyJ+JxQqGpOgTkeF2M5ri77Kkq2Y+
	f8i2ZUXjaidKFUk6QstTr/lx1y7sBO04j6ie13dWCDoBAQuMnAsensHPikufZ06MOR/9g7APeL1
	v++P397vqqVZJ0vFfpA9LjM/faEzA6FSxiDTcnQEZAJVH44rwiXYfR0iaVw8WPBqtdDlDu+bN4o
	NTtG9Ut9G823F+u6d
X-Google-Smtp-Source: AGHT+IGeHhjvJ4j029YTIgPEFJIg07gACuNbyTOh48+y0X4gW3lbp/3GwqZmu+WF39utzjcGkwDXhA==
X-Received: by 2002:a05:6000:3109:b0:3a3:4b8a:9a57 with SMTP id ffacd0b85a97d-3a35fe662b4mr4481271f8f.10.1747440615289;
        Fri, 16 May 2025 17:10:15 -0700 (PDT)
Message-ID: 
Date: Sat, 17 May 2025 01:10:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/6] x86/asm: refactor inclusion guards
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org,
 roger.pau@citrix.com, sstabellini@kernel.org, bertrand.marquis@arm.com,
 Federico Serafini 
References: 
 <20250516232130.835779-5-stefano.stabellini@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: <20250516232130.835779-5-stefano.stabellini@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17/05/2025 12:21 am, Stefano Stabellini wrote:
> From: Federico Serafini 
>
> MISRA C Directive 4.10 states that "Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once".
>
> Refactor inclusion guards to address a violation of Directive 4.10
> and follow CODING_STYLE.
>
> Signed-off-by: Federico Serafini 
> Signed-off-by: Stefano Stabellini 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Sat May 17 00:13:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 00:13:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.987866.1373098 (Exim 4.92)
	(envelope-from )
	id 1uG5B5-0004nI-NP; Sat, 17 May 2025 00:13:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 987866.1373098; Sat, 17 May 2025 00: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 1uG5B5-0004nB-Kt; Sat, 17 May 2025 00:13:23 +0000
Received: by outflank-mailman (input) for mailman id 987866;
 Sat, 17 May 2025 00:13:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uG5B3-0004n4-Uk
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 00:13:21 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bcfa20be-32b3-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 02:13:20 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a1c85e77d7so1756989f8f.0
 for ; Fri, 16 May 2025 17:13:20 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca5a84csm4436355f8f.31.2025.05.16.17.13.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 16 May 2025 17:13: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" 
X-Inumbo-ID: bcfa20be-32b3-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747440799; x=1748045599; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=qv+jkjlo6UD/rwczhf5/ZHkOayfPbwj7hg0EpuHNAzA=;
        b=CCmYuakkT1lpjXSALkFYLtZ+HiPGviTpj1vh1l1+V3Ohsx448Txmy+2UHbTada4Kqq
         YUVYww0VTeczO0vyVBpF1MiuR0x6UEG7wXCiqbWc8BdoOeQ7F17Fb12zk4rvB7pc2HUS
         daqqpyv5EeoAZPG2wrOlgt3CAFx0x7w08mjIg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747440799; x=1748045599;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qv+jkjlo6UD/rwczhf5/ZHkOayfPbwj7hg0EpuHNAzA=;
        b=w6VZnWxX+ZH7dfguNQuMpytaY0mOpdjZAQfm9igQSX9dHng8x9bUrtrtYCz70ntTMX
         OgLqL7VhwT0dUnxCxWHckbeWiwxNp+Rc+MLXQG1+C6d7p7gjnal5Qes+3GPAZOy8zl+F
         WE5qJSzcYum5/RDzVP6+gziRV1P597xiifTolx6nhAF1CrP6+iueBSM6pxip1m8u3qN+
         LbN8CLKSG35QyVfW0uL951/aKRq15baLPn1OpDS68qU8Nzoqogf3o0IIIppNFK/kJ+74
         xItTSmIyyhalhq7HCC/5ar5JvlMtjt/FdFYkSVzVdml7/T5RFU6mGUxlUCL6w+TJvGaV
         8Ctg==
X-Forwarded-Encrypted: i=1; AJvYcCVME9wjW0CgOCnHLQNFUt6nODGYaUFr/tUcPOtsVc6zWtwzPa+PiQTjK4CBP1gNv5WXhsL0eQvkha0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxBkIIo3ElpjEK9/MuhYxkPWE4V5Tf6DUrmT2o4AuOmfnF/4uFt
	+AYfBkmTw5rxrlrQlsfwqI8a2P7AxvJT2C6iFW/kAZz92aWhvRiQbbODvFeQHL76ngc=
X-Gm-Gg: ASbGnctchNnVinMZeFgjA9UI3/L59A5zAQJvH/xP90maAdc3LOmNyjN1NyVEVn/moBY
	qn1Npj5Ip3rW+VOKDbVyMbPe6teF/tYZ0L+2G/0Q1fMvwUh4HZqqsCSkQxmjMMEM9vzLf4xSDc8
	meRuOQ/qZ/4+gVSnwUgsobV0yFOE4YsmmzLNqfItP+sFp3pLbUqsTo4X6ZUKOZUG9bW+YSo+l+Q
	jGy15m2W7giXfiqiip5iGJnL9cHpk57vjFkvwpT6w4IBKkWUotJhul49AOacOPUhmDU1Iv97RFw
	qmu0Xx8RnzbyFyBTJyQ9xwyXc+aD27Boeqnq76UiGKrtwrXhQRJHgcGsUod5C9gZNxfzUmNZDLb
	1k+KQHRZpwXktWqTR
X-Google-Smtp-Source: AGHT+IHVv2KRAkGNad7cFQrd/ryIf6BvqE2XXZ+OAyl0DVfcaLWNiCETa4kBw9vGleKYvR1jolUIkA==
X-Received: by 2002:a05:6000:430d:b0:3a1:fed3:7108 with SMTP id ffacd0b85a97d-3a3600da40fmr4291621f8f.40.1747440799577;
        Fri, 16 May 2025 17:13:19 -0700 (PDT)
Message-ID: 
Date: Sat, 17 May 2025 01:13:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/6] xen: refactor include guards
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org,
 roger.pau@citrix.com, sstabellini@kernel.org, bertrand.marquis@arm.com,
 Federico Serafini 
References: 
 <20250517001005.860657-1-stefano.stabellini@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: <20250517001005.860657-1-stefano.stabellini@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17/05/2025 1:10 am, Stefano Stabellini wrote:
> From: Federico Serafini 
>
> Refactor inclusion guards:
> 1) use a syntax that is more likely to be recognized by static
>    analyzers;
> 2) follow the CODING_STYLE.
>
> No functional change.
>
> Signed-off-by: Federico Serafini 
> Signed-off-by: Stefano Stabellini 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Sat May 17 04:43:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 04:43:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988004.1373148 (Exim 4.92)
	(envelope-from )
	id 1uG9OP-0002Mm-0g; Sat, 17 May 2025 04:43:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988004.1373148; Sat, 17 May 2025 04: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 1uG9OO-0002Mf-Tz; Sat, 17 May 2025 04:43:24 +0000
Received: by outflank-mailman (input) for mailman id 988004;
 Sat, 17 May 2025 04:43:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uG9ON-0002MZ-1x
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 04:43:23 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7272a4aa-32d9-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 06:43:17 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54H4ggxL509076
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Fri, 16 May 2025 21:42:44 -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" 
X-Inumbo-ID: 7272a4aa-32d9-11f0-9ffb-bf95429c2676
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54H4ggxL509076
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747456965;
	bh=ev5wOQfgz6bQFC1LEpzjYx5uyZaaYgjmzOQTSOQC6w8=;
	h=Date:Subject:From:To:Cc:References:In-Reply-To:From;
	b=I9l7lrd9KpAOVvMoL8timZ4/9ZwbcewJp0cSTFePoDsLLFy4C/db/ARW/U+xSnNSh
	 FHnm3VPe4fh+weL2KMTe5ssJGY7SIq3GjsBWsJU90wOV5V311/T2Hrnn3+ULXBt6bE
	 wAtmfqdH5vll+dgbLvAeOmYpMZiLutzmTsQo7z/HWvc85+NNHeFnwXM6h2LQXqride
	 eq6Ah0TXEfl5PAYGEdy3+jECn6RAJjk2XvhLhWZ3eVrEEX/dctqNJO/Bet7dEnCS8Q
	 dzougJiqoghoU2XqffUwlFCGa88HvdIZ5GPhLgGIZGVe3/pLicB2bGgg4npA1mGyEl
	 i0py6AVeH+DYQ==
Message-ID: 
Date: Fri, 16 May 2025 21:42:42 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/3] x86/msr: Convert a native_wrmsr() use to
 native_wrmsrq()
From: Xin Li 
To: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
        rafael@kernel.org, lenb@kernel.org
References: <20250512084552.1586883-1-xin@zytor.com>
 <20250512084552.1586883-4-xin@zytor.com> 
 <68dba45c-a677-4f6d-b7ec-e896aef3d27b@zytor.com>
Content-Language: en-US
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: <68dba45c-a677-4f6d-b7ec-e896aef3d27b@zytor.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5/15/2025 10:54 AM, Xin Li wrote:
> On 5/15/2025 8:27 AM, Ingo Molnar wrote:
>>
>> * Xin Li (Intel)  wrote:
>>
>>> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
>>> conversions when a u64 MSR value is splitted into two u32.
>>>
>>
>> BTW., at this point we should probably just replace
>> sev_es_wr_ghcb_msr() calls with direct calls to:
>>
>>     native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);
>>
>> as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().
>>
> 
> I thought about it, however it looks to me that current code prefers not
> to spread MSR_AMD64_SEV_ES_GHCB in 17 callsites.  And anyway it's a 
> __always_inline function.
> 
> But as you have asked, I will make the change unless someone objects.

Hi Ingo,

I took a further look and found that we can't simply replace
sev_es_wr_ghcb_msr() with native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...).

There are two sev_es_wr_ghcb_msr() definitions.  One is defined in
arch/x86/boot/compressed/sev.h and it references boot_wrmsr() defined in
arch/x86/boot/msr.h to do MSR write.

The other one is defined in arch/x86/include/asm/sev-internal.h, which
uses native_wrmsrq() from arch/x86/include/asm/msr.h to write MSR.

Because:
1) arch/x86/boot/startup/sev-shared.c is included in both
         arch/x86/boot/compressed/sev.c
    and
         arch/x86/boot/startup/sev-startup.c

2) arch/x86/boot/startup/sev-shared.c has several references to
    sev_es_wr_ghcb_msr(),

sev_es_wr_ghcb_msr() is converted to boot_wrmsr() when included in
arch/x86/boot/compressed/sev.c or native_wrmsrq() when included in
arch/x86/boot/startup/sev-startup.c.

It would change the compressed code to use native_wrmsrq() if we remove
sev_es_wr_ghcb_msr() from arch/x86/include/asm/sev-internal.h and use 
native_wrmsrq() directly in the startup code.

We probably should get rid of boot_wrmsr() and use native_wrmsrq() in
the compressed code because they are indeed the same thing.  But as we
are so close to the v6.16 merge window, I don't think it's a good idea
to make the change right now.

So maybe I should just drop this patch and we can do the job after the 
coming merge window.

But if you think it's not a bad idea to replace native_wrmsr() with
native_wrmsrq() right now, I can keep this original patch.

Thanks!
     Xin







From xen-devel-bounces@lists.xenproject.org Sat May 17 07:13:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 07:13:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988067.1373158 (Exim 4.92)
	(envelope-from )
	id 1uGBj9-0002tW-7u; Sat, 17 May 2025 07:12:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988067.1373158; Sat, 17 May 2025 07:12: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 1uGBj9-0002tP-55; Sat, 17 May 2025 07:12:59 +0000
Received: by outflank-mailman (input) for mailman id 988067;
 Sat, 17 May 2025 07:12:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGBj7-0002tJ-OM
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 07:12:57 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 59b0f556-32ee-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 09:12:54 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 0017A5C1042;
 Sat, 17 May 2025 07:10:35 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C20BEC4CEE3;
 Sat, 17 May 2025 07:12: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" 
X-Inumbo-ID: 59b0f556-32ee-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747465972;
	bh=Kfh7EworHewU7d8WTF/gnxLsAf6Ep1ThneG8fXa6LWs=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=sIST7hY2mns6caxm2l+fYdD6IU7MQuJBJkZEwNhVsa5Nn71ygw3JR2TRGxkVcSTSt
	 j2HV07l10mW9NJHYPka+W8SchEy/SmWalEIWVdkC6j4qIYR8mbtT1ewXIuKN5IV7Fz
	 XMyxO3b+fkcytYiPpTfD5PxJnLdtoYGMlZjS1nAtOVBODvtEPqwwiqn53yj5ndxFaL
	 aFOpFWQ77LCrXZIp5MtL8dAwasyMKvR0goYWhQ7JevULSEUm7m9RbPq+pUxzv8GQg0
	 73Qm4cNKm82Zz+AvqFoeGNm5CbCQrkQl1iLgEgnwr2P0JQmRXGqgWIrfX8OJBjt6/J
	 7KrceZdHuPsAg==
Date: Sat, 17 May 2025 09:12:47 +0200
From: Ingo Molnar 
To: Xin Li 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
	rafael@kernel.org, lenb@kernel.org
Subject: Re: [PATCH v1 3/3] x86/msr: Convert a native_wrmsr() use to
 native_wrmsrq()
Message-ID: 
References: <20250512084552.1586883-1-xin@zytor.com>
 <20250512084552.1586883-4-xin@zytor.com>
 
 <68dba45c-a677-4f6d-b7ec-e896aef3d27b@zytor.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 


* Xin Li  wrote:

> On 5/15/2025 10:54 AM, Xin Li wrote:
> > On 5/15/2025 8:27 AM, Ingo Molnar wrote:
> > > 
> > > * Xin Li (Intel)  wrote:
> > > 
> > > > Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
> > > > conversions when a u64 MSR value is splitted into two u32.
> > > > 
> > > 
> > > BTW., at this point we should probably just replace
> > > sev_es_wr_ghcb_msr() calls with direct calls to:
> > > 
> > > native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);
> > > 
> > > as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().
> > > 
> > 
> > I thought about it, however it looks to me that current code prefers not
> > to spread MSR_AMD64_SEV_ES_GHCB in 17 callsites. And anyway it's a
> > __always_inline function.
> > 
> > But as you have asked, I will make the change unless someone objects.
> 
> Hi Ingo,
> 
> I took a further look and found that we can't simply replace
> sev_es_wr_ghcb_msr() with native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...).
> 
> There are two sev_es_wr_ghcb_msr() definitions.  One is defined in
> arch/x86/boot/compressed/sev.h and it references boot_wrmsr() defined in
> arch/x86/boot/msr.h to do MSR write.

Ah, indeed, it's also a startup code wrapper, which wrmsrq() doesn't 
have at the moment. Fair enough.

Thanks,

	Ingo


From xen-devel-bounces@lists.xenproject.org Sat May 17 07:27:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 07:27:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988075.1373168 (Exim 4.92)
	(envelope-from )
	id 1uGBwz-0004aK-Bf; Sat, 17 May 2025 07:27:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988075.1373168; Sat, 17 May 2025 07:27: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 1uGBwz-0004aD-8B; Sat, 17 May 2025 07:27:17 +0000
Received: by outflank-mailman (input) for mailman id 988075;
 Sat, 17 May 2025 07:27:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGBwy-0004a7-0y
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 07:27:16 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 59399558-32f0-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 09:27:13 +0200 (CEST)
Received: from smtpclient.apple ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54H7QhLm591490
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Sat, 17 May 2025 00:26:45 -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" 
X-Inumbo-ID: 59399558-32f0-11f0-9ffb-bf95429c2676
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54H7QhLm591490
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747466805;
	bh=CZtkP3WrpMIGbhySH/khDRYEg3tCdemTLMORia2zrho=;
	h=From:Subject:Date:References:Cc:In-Reply-To:To:From;
	b=JfigqQZ5Lh/TeQEqqyQKd8QM/ozskiXWWzhEwAaEP/NSDAXzGTuveYCYLruvOh24f
	 Rx6isU+2S9BV3OGP1yK3L2fuZj8zKu0SI6I+SJrNAW4ow77BAKijsLpIBQfeaq7Tgo
	 JebNnI7RC7C0XefauAe3O64YSAbfJmCq8Zvw+ZekHJDAsaFoFJhNnKX89u+GKXJ5xy
	 HTDU4z0X5rSsRI/k1lX6GojOxbeWx3oFn/1nwGYgKkIh5EPikQePMIsnv0vT75sMwn
	 RbykR0FK5XFvenmDV6tfJnOVKc5dzk3SrKNq3P4mImuX8O75ABonq4k35ChRoQGXTJ
	 x5kuQ40RpC+rA==
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Xin Li 
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v1 3/3] x86/msr: Convert a native_wrmsr() use to native_wrmsrq()
Date: Sat, 17 May 2025 00:26:32 -0700
Message-Id: 
References: 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
        rafael@kernel.org, lenb@kernel.org
In-Reply-To: 
To: Molnar Ingo 
X-Mailer: iPhone Mail (22F76)


>>> On 5/15/2025 10:54 AM, Xin Li wrote:
>>> On 5/15/2025 8:27 AM, Ingo Molnar wrote:
>>>> 
>>>> * Xin Li (Intel)  wrote:
>>>> 
>>>>> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
>>>>> conversions when a u64 MSR value is splitted into two u32.
>>>>> 
>>>> 
>>>> BTW., at this point we should probably just replace
>>>> sev_es_wr_ghcb_msr() calls with direct calls to:
>>>> 
>>>>     native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);
>>>> 
>>>> as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().
>>>> 
>>> 
>>> I thought about it, however it looks to me that current code prefers not
>>> to spread MSR_AMD64_SEV_ES_GHCB in 17 callsites.  And anyway it's a
>>> __always_inline function.
>>> 
>>> But as you have asked, I will make the change unless someone objects.
>> 
>> Hi Ingo,
>> 
>> I took a further look and found that we can't simply replace
>> sev_es_wr_ghcb_msr() with native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...).
>> 
>> There are two sev_es_wr_ghcb_msr() definitions.  One is defined in
>> arch/x86/boot/compressed/sev.h and it references boot_wrmsr() defined in
>> arch/x86/boot/msr.h to do MSR write.
> 
> Ah, indeed, it's also a startup code wrapper, which wrmsrq() doesn't
> have at the moment. Fair enough.

So you want me to drop this patch then?

Thanks!
    Xin


From xen-devel-bounces@lists.xenproject.org Sat May 17 13:21:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 13:21:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988251.1373179 (Exim 4.92)
	(envelope-from )
	id 1uGHTV-0003As-CY; Sat, 17 May 2025 13:21:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988251.1373179; Sat, 17 May 2025 13:21: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 1uGHTV-0003Ak-6x; Sat, 17 May 2025 13:21:13 +0000
Received: by outflank-mailman (input) for mailman id 988251;
 Sat, 17 May 2025 13:21:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGHTU-0003Ac-HD
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 13:21:12 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cb5e5d4c-3321-11f0-9eb7-5ba50f476ded;
 Sat, 17 May 2025 15:21:09 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id EEE786116F;
 Sat, 17 May 2025 13:21:07 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8448AC4CEE3;
 Sat, 17 May 2025 13:21: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" 
X-Inumbo-ID: cb5e5d4c-3321-11f0-9eb7-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747488067;
	bh=sPP8XL7tHXh/bsZIzimqagY+xJVixQzy2ZkOpaT6d08=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=m3kX9IFD3icXogFTLh29FQJgZReIlia2+XrTPBHaiHQWcNHeoYu+rzqDCHPZT5Kx9
	 JuDKi0OdRi9fPMVlRnibMl25ZT+ATpWI2LPAbIxiWdcfH1G1mtOaunDWfbb4Dqxh4F
	 W+nDEAwbfsXvdhray4cosHnqyHWgB8+7DetXkWALXdG8YkSdBLJzqCzB7yHbe8yphw
	 MURfgfhqLyuUW8kpTqgrz4wXYQBSGXe2+pkdnXaeT5auhc6If7QqKCAI5wT9Rh+hPy
	 w+kiiyQmIBlFr93WiLuS4Skd0EK09JEqYRUuaUjkSJFw9ygNhgoEbMk4KSizz4ilyo
	 GmmpO83wkiwgQ==
Date: Sat, 17 May 2025 15:21:02 +0200
From: Ingo Molnar 
To: Xin Li 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
	rafael@kernel.org, lenb@kernel.org
Subject: Re: [PATCH v1 3/3] x86/msr: Convert a native_wrmsr() use to
 native_wrmsrq()
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 


* Xin Li  wrote:

> 
> >>> On 5/15/2025 10:54 AM, Xin Li wrote:
> >>> On 5/15/2025 8:27 AM, Ingo Molnar wrote:
> >>>> 
> >>>> * Xin Li (Intel)  wrote:
> >>>> 
> >>>>> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
> >>>>> conversions when a u64 MSR value is splitted into two u32.
> >>>>> 
> >>>> 
> >>>> BTW., at this point we should probably just replace
> >>>> sev_es_wr_ghcb_msr() calls with direct calls to:
> >>>> 
> >>>>     native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...);
> >>>> 
> >>>> as sev_es_wr_ghcb_msr() is now basically an open-coded native_wrmsrq().
> >>>> 
> >>> 
> >>> I thought about it, however it looks to me that current code prefers not
> >>> to spread MSR_AMD64_SEV_ES_GHCB in 17 callsites.  And anyway it's a
> >>> __always_inline function.
> >>> 
> >>> But as you have asked, I will make the change unless someone objects.
> >> 
> >> Hi Ingo,
> >> 
> >> I took a further look and found that we can't simply replace
> >> sev_es_wr_ghcb_msr() with native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, ...).
> >> 
> >> There are two sev_es_wr_ghcb_msr() definitions.  One is defined in
> >> arch/x86/boot/compressed/sev.h and it references boot_wrmsr() defined in
> >> arch/x86/boot/msr.h to do MSR write.
> > 
> > Ah, indeed, it's also a startup code wrapper, which wrmsrq() doesn't
> > have at the moment. Fair enough.
> 
> So you want me to drop this patch then?

No, patch #3 is fine as-is in its -v1 form, I was wrong.

Thanks,

	Ingo


From xen-devel-bounces@lists.xenproject.org Sat May 17 16:24:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 16:24:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988346.1373188 (Exim 4.92)
	(envelope-from )
	id 1uGKKE-0007Fk-Mj; Sat, 17 May 2025 16:23:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988346.1373188; Sat, 17 May 2025 16: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 1uGKKE-0007Fd-JX; Sat, 17 May 2025 16:23:50 +0000
Received: by outflank-mailman (input) for mailman id 988346;
 Sat, 17 May 2025 16:23:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGKKC-0007FX-Bk
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 16:23:48 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4db11186-333b-11f0-9eb8-5ba50f476ded;
 Sat, 17 May 2025 18:23:46 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54HGNEBu917019
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Sat, 17 May 2025 09:23:15 -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" 
X-Inumbo-ID: 4db11186-333b-11f0-9eb8-5ba50f476ded
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54HGNEBu917019
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747498996;
	bh=maOuVxjg5o1o3ZGZ5VTl3WY0MMdEeWcAek4IAaxp2Tc=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=JmhzoS6ELcdbp9uSIzDOg8w2fMwp3grFVOk6J/F1MTs2tTo6AeD6I2ci7Vqb9Cw+r
	 RWtA5sW9Xgj8fDLRFSVyqE3FQb4gIV6e6j21PeHZfx/Z2nIkmN8vSMOxKamYKxtpFg
	 DgDJbWqT3tLRjHUQTNQkGKZhcujD2j0GB2RKF18ft9cKxg2Ov9d1tg7AI5T8NGz1mM
	 HHbQtySfIgbPkFiqWkflCI50y0dtLptX75e77lME9Z3+Xw9Hot6hMqF2DXtJ/LN9ML
	 1TKFVv3+JrNZLKx+1inrWt6BMWMlOwox35mY5mXit+uKZozEG9hxAG7dYb9KLpBCNh
	 Ptgae8SZzlnYQ==
Message-ID: <57f29caa-c952-4ea5-9e63-d19696512235@zytor.com>
Date: Sat, 17 May 2025 09:23:14 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/3] x86/xen/msr: Fix uninitialized symbol 'err'
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
        Ingo Molnar 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, boris.ostrovsky@oracle.com, rafael@kernel.org,
        lenb@kernel.org
References: <20250512084552.1586883-1-xin@zytor.com>
 <20250512084552.1586883-3-xin@zytor.com> 
 <30affad5-4f26-4e22-9d64-b8ece1199773@zytor.com>
 
Content-Language: en-US
From: Xin Li 
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5/16/2025 6:42 AM, Jürgen Groß wrote:
> On 15.05.25 20:11, Xin Li wrote:
>> On 5/15/2025 8:29 AM, Ingo Molnar wrote:
>>>
>>> * Xin Li (Intel)  wrote:
>>>
>>>> xen_read_msr_safe() currently passes an uninitialized argument err to
>>>> xen_do_read_msr().  But as xen_do_read_msr() may not set the argument,
>>>> xen_read_msr_safe() could return err with an unpredictable value.
>>>>
>>>> To ensure correctness, initialize err to 0 (representing success)
>>>> in xen_read_msr_safe().
>>>>
>>>> Because xen_read_msr_safe() is essentially a wrapper of 
>>>> xen_do_read_msr(),
>>>> the latter should be responsible for initializing the value of *err 
>>>> to 0.
>>>> Thus initialize *err to 0 in xen_do_read_msr().
>>>>
>>>> Fixes: 502ad6e5a619 ("x86/msr: Change the function type of 
>>>> native_read_msr_safe()")
>>>> Reported-by: Dan Carpenter 
>>>> Closes: https://lore.kernel.org/xen-devel/aBxNI_Q0- 
>>>> MhtBSZG@stanley.mountain/
>>>> Signed-off-by: Xin Li (Intel) 
>>>> ---
>>>>   arch/x86/xen/enlighten_pv.c | 5 ++++-
>>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
>>>> index 3be38350f044..01f1d441347e 100644
>>>> --- a/arch/x86/xen/enlighten_pv.c
>>>> +++ b/arch/x86/xen/enlighten_pv.c
>>>> @@ -1091,6 +1091,9 @@ static u64 xen_do_read_msr(u32 msr, int *err)
>>>>   {
>>>>       u64 val = 0;    /* Avoid uninitialized value for safe variant. */
>>>> +    if (err)
>>>> +        *err = 0;
>>>> +
>>>>       if (pmu_msr_chk_emulated(msr, &val, true))
>>>>           return val;
>>>> @@ -1162,7 +1165,7 @@ static void xen_do_write_msr(u32 msr, u64 val, 
>>>> int *err)
>>>>   static int xen_read_msr_safe(u32 msr, u64 *val)
>>>>   {
>>>> -    int err;
>>>> +    int err = 0;
>>>>       *val = xen_do_read_msr(msr, &err);
>>>>       return err;
>>>
>>> So why not initialize 'err' with 0 in both callers, xen_read_msr_safe()
>>> and xen_read_msr(), and avoid all the initialization trouble in
>>> xen_do_read_msr()?
>>
>> Yeah, I should make the change in xen_read_msr() too.
>>
>> However xen_do_read_msr() should be implemented in a defensive way to
>> set *err properly as it's part of its return value.  Actually it was so,
>> but one of my previous cleanup patch removed it because err is no longer
>> passed to pmu_msr_chk_emulated().
> 
> xen_do_read_msr() is usable only in enlighten_pv.c as it is static.
> 
> So I'd prefer to drop setting err to 0 in xen_do_read_msr() initially
> and to set err to 0 in all callers.

Okay, I will send v1A to address this comment then.

Thanks!
     Xin

> Juergen



From xen-devel-bounces@lists.xenproject.org Sat May 17 16:26:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 16:26:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988351.1373199 (Exim 4.92)
	(envelope-from )
	id 1uGKMQ-0007kv-1l; Sat, 17 May 2025 16:26:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988351.1373199; Sat, 17 May 2025 16: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 1uGKMP-0007ko-UK; Sat, 17 May 2025 16:26:05 +0000
Received: by outflank-mailman (input) for mailman id 988351;
 Sat, 17 May 2025 16:26:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGKMO-0007ki-GF
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 16:26:04 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9d37e57b-333b-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 18:25:59 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54HGPZUT919995
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Sat, 17 May 2025 09:25:35 -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" 
X-Inumbo-ID: 9d37e57b-333b-11f0-9ffb-bf95429c2676
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54HGPZUT919995
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747499136;
	bh=KTZCp14x76qGytemiSFztrFrvUMZ1IcfhMjR0iRXjV8=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=FJUtD0Ls+vvCc2jgfB0jHxL64yjLhHC4F9dNTGHOBfk/fKgFT+i/VXv9q2ok6I/Og
	 PY+TKlBtRXzigEDX/Xd4OexBlXuyej/WbCmIms8OXtkbW9moKtXSCjOj+kadwNzhzD
	 ITMSiRbDEgYyDu5BbIy0Zn0UAiUqTIZB+CAZPt5CZ+zVUJ0ICnh0pyBXVZfwc1aEAN
	 1kgaNDyKNpRUq+N2bc+Wb6C779YZhlYgantTBaAEJFPwVJuwxiuS/PR3uLiBCO5guI
	 mrNDtdcB8XOjowc2ZbtgFEwZ23rmLzFg/ncmcHjlZqLFHnD2kMTanw7pHFzpzad5YE
	 0AkM8qA+XXRNg==
Message-ID: 
Date: Sat, 17 May 2025 09:25:34 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/3] x86/msr: Convert a native_wrmsr() use to
 native_wrmsrq()
To: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
        rafael@kernel.org, lenb@kernel.org
References: 
  
Content-Language: en-US
From: Xin Li 
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 5/17/2025 6:21 AM, Ingo Molnar wrote:
>>> Ah, indeed, it's also a startup code wrapper, which wrmsrq() doesn't
>>> have at the moment. Fair enough.
>> So you want me to drop this patch then?
> No, patch #3 is fine as-is in its -v1 form

Thanks for confirming.

I'll just update patch #2 as version v1A then.

     Xin


From xen-devel-bounces@lists.xenproject.org Sat May 17 16:57:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 16:57:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988372.1373209 (Exim 4.92)
	(envelope-from )
	id 1uGKr5-0003LX-Ej; Sat, 17 May 2025 16:57:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988372.1373209; Sat, 17 May 2025 16:57:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGKr5-0003LQ-A7; Sat, 17 May 2025 16:57:47 +0000
Received: by outflank-mailman (input) for mailman id 988372;
 Sat, 17 May 2025 16:57:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGKr4-0003LK-Jc
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 16:57:46 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0cafa859-3340-11f0-9eb8-5ba50f476ded;
 Sat, 17 May 2025 18:57:44 +0200 (CEST)
Received: from terminus.zytor.com (terminus.zytor.com
 [IPv6:2607:7c80:54:3:0:0:0:136]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54HGvDhh935399
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Sat, 17 May 2025 09:57:18 -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" 
X-Inumbo-ID: 0cafa859-3340-11f0-9eb8-5ba50f476ded
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54HGvDhh935399
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747501039;
	bh=mKRkOm6YCP44COro/tUSTMPHIOXwpBJTdxPBtiGGv34=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=OYWedsLYqMQmUpWqc2lx996Ra0psIm3b5PKqU86NwNH25aNWyIThMqo2+aNRuDOug
	 B1CY58kCLHBpWGBl0T1HxmhtWReeJMNs8rsPm9o1GG8t67JuTKpzymKrmieoahJOdS
	 TOqO3IMnQj/CrXNe879Sjb1ZilZ2/j9XWTakmjs3koC7vrgSeL/nPPgUkb6zuBW+E2
	 bSVwKohXIIesXQ58FjFp9XJnUD25RKDb3oAyZD2kHGEN27x07cSde3P9HrdTNVUlKv
	 gLCdquuKYcnBd0aCK3drY1Cst2OvRwLvdn/z9ZSeVsC564kEFulFyZbIaENPQ9nP+A
	 k0KUjSx4wKMfA==
From: "Xin Li (Intel)" 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org
Cc: tglx@linutronix.de, mingo@kernel.org, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
        dan.carpenter@linaro.org, rafael@kernel.org, lenb@kernel.org
Subject: [PATCH v1A 2/3] x86/xen/msr: Fix uninitialized symbol 'err'
Date: Sat, 17 May 2025 09:57:12 -0700
Message-ID: <20250517165713.935384-1-xin@zytor.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

xen_read_msr_safe() currently passes an uninitialized argument err to
xen_do_read_msr().  But as xen_do_read_msr() may not set the argument,
xen_read_msr_safe() could return err with an unpredictable value.

To ensure correctness, initialize err to 0 (representing success)
in xen_read_msr_safe().

Do the same in xen_read_msr(), even err is not used after being passed
to xen_do_read_msr().

Fixes: d815da84fdd0 ("x86/msr: Change the function type of native_read_msr_safe()"
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/xen-devel/aBxNI_Q0-MhtBSZG@stanley.mountain/
Signed-off-by: Xin Li (Intel) 
---

Change in v1A:
*) Drop setting err to 0 in xen_do_read_msr() initially and set err to
   0 in all callers (Jürgen Groß).
---
 arch/x86/xen/enlighten_pv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 7f9ded1bc707..26bbaf4b7330 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1162,7 +1162,7 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err)
 
 static int xen_read_msr_safe(u32 msr, u64 *val)
 {
-	int err;
+	int err = 0;
 
 	*val = xen_do_read_msr(msr, &err);
 	return err;
@@ -1179,7 +1179,7 @@ static int xen_write_msr_safe(u32 msr, u64 val)
 
 static u64 xen_read_msr(u32 msr)
 {
-	int err;
+	int err = 0;
 
 	return xen_do_read_msr(msr, xen_msr_safe ? &err : NULL);
 }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Sat May 17 18:18:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 18:18:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988432.1373219 (Exim 4.92)
	(envelope-from )
	id 1uGM6r-0004Gg-Uy; Sat, 17 May 2025 18:18:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988432.1373219; Sat, 17 May 2025 18:18:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGM6r-0004GZ-SJ; Sat, 17 May 2025 18:18:09 +0000
Received: by outflank-mailman (input) for mailman id 988432;
 Sat, 17 May 2025 18:18:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGM6p-0004GT-J2
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 18:18:08 +0000
Received: from 4.mo581.mail-out.ovh.net (4.mo581.mail-out.ovh.net
 [178.32.122.254]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 44d2cb35-334b-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 20:18:02 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.109.139.3])
 by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4b0ByK4sLJz1Ndv
 for ; Sat, 17 May 2025 18:18:01 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-5gtgt (unknown [10.110.113.153])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 4F4111FD3F;
 Sat, 17 May 2025 18:18:00 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.100])
 by ghost-submission-5b5ff79f4f-5gtgt with ESMTPSA
 id 2pBnBNjSKGjmQAkAAGl5dQ
 (envelope-from ); Sat, 17 May 2025 18:18: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" 
X-Inumbo-ID: 44d2cb35-334b-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-100R003bb8f4099-de98-4f44-9343-efc1adac344c,
                    E5B6778283FB85F5FEF284FAF1BF1665328034AA) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Sat, 17 May 2025 21:17:51 +0300
From: Sergii Dmytruk 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v2 09/22] xen/lib: add implementation of SHA-1
Message-ID: 
References: 
 <7fcab16c3efbc0eb28e0f8ec0d9c9d3188881ad4.1747155790.git.sergii.dmytruk@3mdeb.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Ovh-Tracer-Id: 15193174821536576668
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -110
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdefudeifeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnegfrhhlucfvnfffucdlqddutddmnecujfgurhepfffhvfevuffkfhggtggugfgjsehtkeertddttddunecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepgeeiveevteeguddtheegtedtffelteehjedugfelhfegudffkedtgfevkeettefgnecuffhomhgrihhnpehnihhsthdrghhovhenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekgedrvddvuddpfeejrdehledrudegvddruddttdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkedumgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=TYGktWuYeB1G2viZC9Qm3dwDd88Cb4PEVL+Pp5yMTtk=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747505881; v=1;
 b=mFK1Yjj/Tpfy8w12pe23R9N+OtoABxu+ZxXnFFE9R1Mwlb4gkEgw6DipzLpzRdfb0dSjdMoX
 lJ0RiYv5wa3aKcjgSByikLwG0yg6NQ+m6n5mQEwUfzkkbAyFVl9lxxVeea4A72cx+3XPV6h/Ppi
 CMHvgOzLh52sJkJ2zbG1x8nLU+u0llCnMebfbyqk0XgL0BF4cCzrrPKBIc9ZixDWAVfpc0L9NK/
 Z9h8GAg+aep+GfEkscyT4DvZuFRvPnZKICx48AO9bbmgrCN0EE3yWHWeMSIemvDgwP82tNbvCa+
 MTKs97wRpI35W4rGPjIZkMJz5SVmz8MNiaUhYD6v4bLHw==

On Wed, May 14, 2025 at 05:58:59PM +0100, Andrew Cooper wrote:
> Please crib from sha2.h as much as you can. Use xen/types.h, drop the
> double underscore in the guard, and provide a link to the spec.

Until yesterday CODING_STYLE instructed to have 2 underscores, so I
thought sha2.h is outdated.  I'll switch to , although it's
overkill there and only grows header dependency tree (it also brings
extra symbols thus hiding missing includes elsewhere).

> I think it's https://csrc.nist.gov/pubs/fips/180-1/final

Looks like https://csrc.nist.gov/pubs/fips/180-4/upd1/final is the
latest for all SHA algorithms.

> > +struct sha1_state {
> > +    uint32_t state[SHA1_DIGEST_SIZE / 4];
> > +    uint64_t count;
> > +    uint8_t buffer[SHA1_BLOCK_SIZE];
> > +};
>
> As it's uint64_t, the count field needs to be first to avoid padding.

Will swap them.

> > +/* This "rolls" over the 512-bit array */
> > +static void set_w(uint32_t w[SHA1_WORKSPACE_WORDS], size_t i, uint32_t val)
> > +{
> > +#ifdef CONFIG_X86
> > +    *(volatile uint32_t *)&w[i & SHA1_WORKSPACE_MASK] = val;
> > +#else
> > +    w[i & SHA1_WORKSPACE_MASK] = val;
> > +# ifdef CONFIG_ARM
> > +    barrier();
> > +# endif
> > +#endif
>
> This is horrible. I think the problems discussed are created by having
> the loops in sha1_transform() broken in a wrong (read, unhelpful) way.
> The 5-way shuffle of the chaining variables probably is beyond the
> compilers' ability to unroll given the multiples of 4 currently used.
>
> See the implementation in SKL where I spent a while optimising the code
> generation. Admittedly that was optimising for size rather than speed,
> but the end result look to be good for both.

I tried just doing regular writes and didn't notice any massive
changes in the disassembly with GCC 14.2.0, in fact the function got
shorter by 41 bytes and its stack frame size decreased by 8 bytes.  That
comment was probably addressing misbehaviour of some older version.

> > +    /* Round 1 - iterations 0-16 take their input from 'data' */
> > +    for ( ; i < 16; ++i ) {
>
> Xen style has this { on the next line.

Will fix.

> > +static void sha1_update(struct sha1_state *sctx, const uint8_t *msg, size_t len)
> > +{
> > +    unsigned int partial = sctx->count % SHA1_BLOCK_SIZE;
> > +
> > +    sctx->count += len;
> > +
> > +    if ( (partial + len) >= SHA1_BLOCK_SIZE )
> > +    {
> > +        if ( partial )
> > +        {
> > +            int rem = SHA1_BLOCK_SIZE - partial;
>
> Unsigned int please.

Will do.

> > +static void sha1_final(struct sha1_state *sctx, void *out)
>
> Please make this uint8_t digest[SHA1_DIGEST_SIZE] straight away. This
> was an oversight of mine in sha2-256.c which was fixed when exposing the
> function (c/s aea52ce607fe).

OK.  I skipped that intentionally because it really only adds an
explicit cast in the body which is not much different from casting to
`void *` and back.

Regards


From xen-devel-bounces@lists.xenproject.org Sat May 17 18:51:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 17 May 2025 18:51:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988452.1373228 (Exim 4.92)
	(envelope-from )
	id 1uGMdJ-0000jX-EZ; Sat, 17 May 2025 18:51:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988452.1373228; Sat, 17 May 2025 18: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 1uGMdJ-0000jQ-Bv; Sat, 17 May 2025 18:51:41 +0000
Received: by outflank-mailman (input) for mailman id 988452;
 Sat, 17 May 2025 18:51:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGMdH-0000jJ-VV
 for xen-devel@lists.xenproject.org; Sat, 17 May 2025 18:51:40 +0000
Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com
 [2a00:1450:4864:20::643])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f6027304-334f-11f0-9ffb-bf95429c2676;
 Sat, 17 May 2025 20:51:37 +0200 (CEST)
Received: by mail-ej1-x643.google.com with SMTP id
 a640c23a62f3a-ad51ba0af48so479022266b.0
 for ; Sat, 17 May 2025 11:51:37 -0700 (PDT)
Received: from ?IPV6:2003:e5:872a:8800:5c7b:1ac1:4fa0:423b?
 (p200300e5872a88005c7b1ac14fa0423b.dip0.t-ipconnect.de.
 [2003:e5:872a:8800:5c7b:1ac1:4fa0:423b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d498747sm329295866b.137.2025.05.17.11.51.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 17 May 2025 11:51: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" 
X-Inumbo-ID: f6027304-334f-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747507897; x=1748112697; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=esvr8R6WEoSrZXgQlzfaTrT/BDn5P1ZhexoSJKjzt7M=;
        b=JM8ILaJj7x0uz/2Y/JJoS91/Ii3GgdedOrNpMJeZNnUqnHNLIuSXKT0IplvOm4GZnc
         ayZa2HmMTCXAh5nczsRtbuD6sWjDdzcXb8eHicEBGpt7CCxYrPz9/EmWRCY5N9VMf/57
         OxA9it7vZFBdd7+XTCuDE+dImSp5lMT2cNmdNU/FMOvmk+sPW9MH2qpZMJuyr5uAAguE
         bjfyL79dlzgicswN7IzWTGyRlXRlP79KX1tsvzBhuVUlDcEIdy5sb5IXwJ1jf7gqd57t
         hnVZIKkX8XtB6E9PXHNtfqLGnBLNU60zdTuSSbbcucLMXk/Am7hE+VJChVtqedwNZO48
         KVuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747507897; x=1748112697;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=esvr8R6WEoSrZXgQlzfaTrT/BDn5P1ZhexoSJKjzt7M=;
        b=C9Y/c6Whk+9oXGgvXH0e/sfO8s461RZojZZFKoI4j0XaoDx9mad+slRT0+cFnfRY6D
         IgX4EN0TfYqQaVLKqzqiYMBFFnjD6yLBYI+T6+zrp4Sby1+EjXocpCOpcBZQ513RCVk3
         4b4gPcFNtgPl/MnfO2WCw7QmIANJoCij8T8q5FhnbPbIVIAleID/L4mT8hbRmZV3QW+1
         4nfkrLwneYz5vMCn42kmOz7Q7j3gLQgn4t+7Bgj6WvJj3ocZiGCwjH7FR8QsKq5uo0qU
         WTLd2RnvdOHjV6xmrJAj8JxSuUesd7TkTxdR0S/pkbIOWdNmMgZzWZm0idwnNPQ8K3Va
         vX0w==
X-Forwarded-Encrypted: i=1; AJvYcCWXI76VCOyzeLOFZGf79BPcSBp7r+razKgi5QXboPuE2VIDxKex+WonUYM1f1jgk/r4hhzZWDrLpHs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YynwgTiGaB9Vk5FiRpHPkx2zUm0wSE65C8vtt+yB1thhu3TbGXl
	0TaAQZtjUYcio9U9tF0XYZYiah2sXmI/dzmZhrRwicXtU51aAOiS/BAzGe8f9Lz69Wo=
X-Gm-Gg: ASbGncuxjsoi0sEyq/7ewmzNckjphK5+Wb4+uqu2LqIMCOPBtBSU+X5JYwCkoSvsZ8H
	wtsHPvNk7IHvr5XDgfsQmHE2Xm/jb/aljwKYbQZMIkS5WsZ++ghqAvaD8R4pBWdPt5oWkh3v2ed
	9JK9mPrIPQMRTHab1g+qcXYz4tn0pQbh6tDZpNXoA/+yVi4QYREDohGYQ+NkXpUPEpIGTDQWLMS
	uWiNd/nqnlHtxe2s59j8ro/PAcSPazs/KzJHmdmt6zDTirynzPGnvnldEzB68gUY/w4obM0MGs7
	BnDUmIDgaRsTDJ/jM6M9K+TUYa8uKEkusVSaJZyoca4xTTLTn+rO8UGWyD28er4OftAgCZb4wBL
	bnvAtir/D9QZpw9nB5jU8pM3/5ZuY1tbQas66Ywuf86Iu8CHoFPtiIGMob+ysV9XmmnoAjzDWdO
	iY93AG/1dVIf0=
X-Google-Smtp-Source: AGHT+IFEF2Q0UxOZnJlm+Ccp+4eTz4P200IBb4VqMusjriDU43pbgoKygbxgSW1mEWMO0YQml7o1iw==
X-Received: by 2002:a17:907:7e9c:b0:ad5:11a2:f95e with SMTP id a640c23a62f3a-ad52f1a09b1mr739087266b.5.1747507896600;
        Sat, 17 May 2025 11:51:36 -0700 (PDT)
Message-ID: <5f76fa30-53cf-4cdd-9201-5fd525573858@suse.com>
Date: Sat, 17 May 2025 20:51:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1A 2/3] x86/xen/msr: Fix uninitialized symbol 'err'
To: "Xin Li (Intel)" , linux-kernel@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org
Cc: tglx@linutronix.de, mingo@kernel.org, bp@alien8.de,
 dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
 peterz@infradead.org, boris.ostrovsky@oracle.com, dan.carpenter@linaro.org,
 rafael@kernel.org, lenb@kernel.org
References: 
 <20250517165713.935384-1-xin@zytor.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: <20250517165713.935384-1-xin@zytor.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------wYlEYju0WXW3nEzZsQVz5sqK"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------wYlEYju0WXW3nEzZsQVz5sqK
Content-Type: multipart/mixed; boundary="------------npkniPAj3lZU17c0YJiIJgOs";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: "Xin Li (Intel)" , linux-kernel@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org
Cc: tglx@linutronix.de, mingo@kernel.org, bp@alien8.de,
 dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
 peterz@infradead.org, boris.ostrovsky@oracle.com, dan.carpenter@linaro.org,
 rafael@kernel.org, lenb@kernel.org
Message-ID: <5f76fa30-53cf-4cdd-9201-5fd525573858@suse.com>
Subject: Re: [PATCH v1A 2/3] x86/xen/msr: Fix uninitialized symbol 'err'
References: 
 <20250517165713.935384-1-xin@zytor.com>
In-Reply-To: <20250517165713.935384-1-xin@zytor.com>

--------------npkniPAj3lZU17c0YJiIJgOs
Content-Type: multipart/mixed; boundary="------------llwv3cxcMOeLkriHHzdPWzyR"

--------------llwv3cxcMOeLkriHHzdPWzyR
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTcuMDUuMjUgMTg6NTcsIFhpbiBMaSAoSW50ZWwpIHdyb3RlOg0KPiB4ZW5fcmVhZF9t
c3Jfc2FmZSgpIGN1cnJlbnRseSBwYXNzZXMgYW4gdW5pbml0aWFsaXplZCBhcmd1bWVudCBl
cnIgdG8NCj4geGVuX2RvX3JlYWRfbXNyKCkuICBCdXQgYXMgeGVuX2RvX3JlYWRfbXNyKCkg
bWF5IG5vdCBzZXQgdGhlIGFyZ3VtZW50LA0KPiB4ZW5fcmVhZF9tc3Jfc2FmZSgpIGNvdWxk
IHJldHVybiBlcnIgd2l0aCBhbiB1bnByZWRpY3RhYmxlIHZhbHVlLg0KPiANCj4gVG8gZW5z
dXJlIGNvcnJlY3RuZXNzLCBpbml0aWFsaXplIGVyciB0byAwIChyZXByZXNlbnRpbmcgc3Vj
Y2VzcykNCj4gaW4geGVuX3JlYWRfbXNyX3NhZmUoKS4NCj4gDQo+IERvIHRoZSBzYW1lIGlu
IHhlbl9yZWFkX21zcigpLCBldmVuIGVyciBpcyBub3QgdXNlZCBhZnRlciBiZWluZyBwYXNz
ZWQNCj4gdG8geGVuX2RvX3JlYWRfbXNyKCkuDQo+IA0KPiBGaXhlczogZDgxNWRhODRmZGQw
ICgieDg2L21zcjogQ2hhbmdlIHRoZSBmdW5jdGlvbiB0eXBlIG9mIG5hdGl2ZV9yZWFkX21z
cl9zYWZlKCkiDQo+IFJlcG9ydGVkLWJ5OiBEYW4gQ2FycGVudGVyIDxkYW4uY2FycGVudGVy
QGxpbmFyby5vcmc+DQo+IENsb3NlczogaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRl
dmVsL2FCeE5JX1EwLU1odEJTWkdAc3RhbmxleS5tb3VudGFpbi8NCj4gU2lnbmVkLW9mZi1i
eTogWGluIExpIChJbnRlbCkgPHhpbkB6eXRvci5jb20+DQoNClJldmlld2VkLWJ5OiBKdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K
--------------llwv3cxcMOeLkriHHzdPWzyR
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-----

--------------llwv3cxcMOeLkriHHzdPWzyR--

--------------npkniPAj3lZU17c0YJiIJgOs--

--------------wYlEYju0WXW3nEzZsQVz5sqK
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/Ey8FAmgo2rYFAwAAAAAACgkQsN6d1ii/Ey/y
1gf+OIrTmR24006WFmEsHRhFAD+Rxh+DPGsuFdt+zPIvZT46MPLR0SQ9a4Xugs+lkkjnEnwBQ4Gp
sCkPjxXliS8bO+w203UixwqIvyYXSTVMhdl0kvgEBcDobMfbPQExTR0iGja6kQyiy/Oyhz1/MmWe
sKSteetLIxXWLruF/qFh0yxi8QLgDs8vkNY5eTA9Vzx0iGItISRn3u5v/qpmW1Cz9+sSEeihfULy
t6Q9miXwajrovQR3tn4+NBKOaF4oRnM74lrohRFAJRHj46vmMRqkO8n1WkLV5c6KsjSyh4102Mh3
J0gYZzleGWsaA7/Q2Xb8VT4ECuTX+pTYeMtzNV74hA==
=t71+
-----END PGP SIGNATURE-----

--------------wYlEYju0WXW3nEzZsQVz5sqK--


From xen-devel-bounces@lists.xenproject.org Sun May 18 08:22:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 08:22:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988845.1373239 (Exim 4.92)
	(envelope-from )
	id 1uGZHH-0005yZ-Jh; Sun, 18 May 2025 08:21:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988845.1373239; Sun, 18 May 2025 08: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 1uGZHH-0005yS-GN; Sun, 18 May 2025 08:21:47 +0000
Received: by outflank-mailman (input) for mailman id 988845;
 Sun, 18 May 2025 08:21:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGZHG-0005yM-Po
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 08:21:46 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 223a630e-33c1-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 10:21:44 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a3673e12c4so469151f8f.2
 for ; Sun, 18 May 2025 01:21:44 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-24.ptr.icomera.net.
 [185.104.138.24]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca88990sm8815311f8f.68.2025.05.18.01.21.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 01:21: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" 
X-Inumbo-ID: 223a630e-33c1-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747556504; x=1748161304; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=f5Q2VhUrKh64of+oRNqXiqXSIUuzb+feTKvi2o4J1Ig=;
        b=McUYVn3HbKPGtLXBAYFuk5AQ657xFxeWwhHKAjykgqtnemH9GulhNdks1NN0FHGSp/
         3zTuY2GCOSom1tzQDnkhNUIr+/pXQDp3NU6OuDv0atJjVz9kMUbEkM13W+KLO225uksl
         IGxbbJxloe/cNtIFsPCazPq4dqhjVknMbqsYr8h04fpFV+4sYxCfbCie4YwySl+PiG4M
         lyUgjn0nuZWuW3kG/BHKTodneFd0Xpgxd5osscBrrN7TU1IF8/1qusv327WHncEki/R3
         MZoBVbsZk8ubuwI+VkN4C0PejXkq9kum/8wuacvFQG7yDCyiEbL3NmOrRDg2uuTRM/sZ
         ZndQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747556504; x=1748161304;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=f5Q2VhUrKh64of+oRNqXiqXSIUuzb+feTKvi2o4J1Ig=;
        b=s4bTnnOaBht8q+lw0kWatNu9Absl2BCA2y+/T5JfSxO3CcecZP21FaP4yvOeeH87e2
         EJibtS1IsLxE5Sd0P/sKbCypHz3lqneZgfAVFiPmyKx4CEutdQfXfE12JNRM2bFIMxrS
         YQLQC9VWtB1gl9tVoK1O5Df1OGvDFUd1vvJGSXkd9u7j7Wx+Sbj+vWPQn9KZZhNQcRcl
         zCMVwU40aHdph/a8nikXEveC+z1jzT7xRRG/Hxi0gZz/TC93JL2T+MPy2RXa+PxrCCLS
         yb9tXwrY+bB1Qtb3RxTaHamfp/wTbVNQtrw2uvdRKWzJ/Z18n3k/9ngmkR8Aj7T+wMDy
         8rlw==
X-Forwarded-Encrypted: i=1; AJvYcCWiP3k4xJO975f4hYc5O6+0HUGcH0+BEm+TrZcSrZnaboxSMgY9su7Rt0xJbFJRVohJbnJGP/QuVuM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzyj0wNiJ1ujokScoahCoqDGrrf1p0aAhilXsqQ95kOzRX4Mjqs
	qmihx9983x6sMZ76bBIwSH4WL3J8uqCDX67RjDCuFt1mvYPS4cIdH47SFuw96uxfPQ==
X-Gm-Gg: ASbGncsBCqD+llMglZyyufvhIrFCWiomkvA/xekViurAUqo9G2TE0OmyVCajGGHvUNc
	l++MLokNGR56oxVxrWguTzaUxFTFHvMQnczZ3f+VT6UHvWJAln9pOmZPKsgAQXvcPCFOwK0cN+s
	kh7i21sQ2FV4d/APwI4ZVHiMNByGp9rW4b8hboGT4R867h1tBIHOkATAQVv/krXYWIwKDtmGYkE
	aUY5BG0YCFz7GR1rwj78xiN1AGl827WA4DshP8m91JosTra7clwmA1NBNfDoKFro2EMMrpV2Wnb
	QlJorPX/mS1Nc7vVUwxHsSfrvXNfS717gg/bSNSN34zNcEHcsWQxIBehDGZe8nARVw4MQMDPELK
	e7HFzpLEUFg+Ag7T7aShlpHd6jB0AKFn5PuE=
X-Google-Smtp-Source: AGHT+IG4uWMv7xbl8vCbrEEEh9U66iwFwzMuX34cGCaIHJl6GsVfWHFHmS+R0ucJmYszPxeIRjGFGw==
X-Received: by 2002:a5d:64ee:0:b0:3a0:b72a:b36 with SMTP id ffacd0b85a97d-3a35c84bd82mr8129808f8f.36.1747556504018;
        Sun, 18 May 2025 01:21:44 -0700 (PDT)
Message-ID: 
Date: Sun, 18 May 2025 10:21:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/stubs: Consolidate the stubs infrastructure in
 asm/stubs.h
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250516133326.49587-1-andrew.cooper3@citrix.com>
 <4a1a8582-7503-49ca-8d34-bce3e101734a@suse.com>
 <87a0546d-d2e4-4042-b34a-e35e2605123b@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <87a0546d-d2e4-4042-b34a-e35e2605123b@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16.05.2025 15:49, Andrew Cooper wrote:
> On 16/05/2025 2:41 pm, Jan Beulich wrote:
>> On 16.05.2025 15:33, Andrew Cooper wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/include/asm/stubs.h
>>> @@ -0,0 +1,37 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef X86_ASM_STUBS_H
>>> +#define X86_ASM_STUBS_H
>>> +
>>> +/*
>>> + * Xen has several per-cpu executable stubs which are written dynamically.
>> This puts it pretty well. Yet in principle there may be further, perhaps
>> entirely different stubs in the future. Hence stubs.h feels a little
>> generic. What about exec-stubs.h?
> 
> stubs is quite generic; in fact, that was my feedback for struct stubs.
> 
> There is something to be said for the header file to be the same as the
> struct you want from it.
> 
> What did you have in mind for "different stubs"?  The only thing that
> makes these special (i.e. not regular per-cpu data) is that we need an
> executable mapping of them.  So, while I think it's reasonably likely
> that we'll gain other uses (although, we're losing LSTAR/CSTAR when FRED
> is enabled), I'm less certain what non-executable stubs would look like.

A while after having written my reply, I started wondering myself. Likely
we wouldn't normally call anything non-executable a "stub", so please
disregard my suggestion.

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 08:23:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 08:23:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988850.1373249 (Exim 4.92)
	(envelope-from )
	id 1uGZJ0-0006Sp-Ug; Sun, 18 May 2025 08:23:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988850.1373249; Sun, 18 May 2025 08:23: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 1uGZJ0-0006Si-Rk; Sun, 18 May 2025 08:23:34 +0000
Received: by outflank-mailman (input) for mailman id 988850;
 Sun, 18 May 2025 08:23:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGZJ0-0006Sa-7X
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 08:23:34 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 627c8202-33c1-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 10:23:32 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a361b8a664so1949347f8f.3
 for ; Sun, 18 May 2025 01:23:32 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-24.ptr.icomera.net.
 [185.104.138.24]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442fd583f71sm95197565e9.27.2025.05.18.01.23.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 01:23: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" 
X-Inumbo-ID: 627c8202-33c1-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747556612; x=1748161412; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=49j93buoqoZ+Qpg3aRYmy1EreytZ446wBKdsnMPO7xM=;
        b=R+2BUwujsfIrpD2HrvuHO5ndLTq/FCqGHgxV6BF0BtWxyXStLIr5HTx05ZPLYAWjIx
         QisMVXlkrz00jB/uqdFc8pYICjF1b/1l8LzF57N5Ur562UzpJcWD00B/HwF2utXDpjx9
         9BWFoUTM6iCvOsvnalPpiNck6SPSTE8k1ZQO6fjEeFp8V58VMDOGOyN2xqwB0cqI9QGx
         aUMyETHFMaOeMtmjSpeJ8OQr8L3vYTmDuA3aFRgFX6Jkb2zvwB1OSi3ODlRAbg3j9KMu
         zfJcmhU0Yumn+kxPiDxj9A8xQHrWoskLbftqETY3IxJObSY21w3NSy0GsW6pk/WYu5lX
         CK8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747556612; x=1748161412;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=49j93buoqoZ+Qpg3aRYmy1EreytZ446wBKdsnMPO7xM=;
        b=BysDCo1x2VOCmclFNbwYCbsyztenL+PUfemCWPpjPJV/GdUw5INF/rCipbbsITraDk
         68fizlj1SRRTBeXiK+2jHo1pC3u0CPO8wXTRQvXk6ZnpYXtqnscZ+2aSCqWFm/PrgLQi
         qHrgNQYtTMKnuz4hbY46nn8FvwxBQpMSKzBbpXdRqdiO4M/4lhoJ4fpIaU2dhQkezd6n
         gwQK3T3LTJjiRqfCtjrtyKJgTcFZmsxQq4Esq5M2BAq0GPUXpvdDaPkYoNJioJ9hmbX9
         P2sgOgFLkyTvemDHXpEVCQajWA/3dAwl85eWZA+u1KmFwuozbl17ZUbqJmg15v8nw9sc
         /tGA==
X-Forwarded-Encrypted: i=1; AJvYcCV5Qj1jCc0B0bjpVvo1mueIY89XKyJUT22+oYjx+XJP6pifmQOdEC58cQ2nhLP4B3zArgZsb4WCJrE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxbe4vlRLOxadp2QHLybyYeP469FXRsqoPH9eUcsMbOG28ndJKl
	+oFpTuUGVM1lYl38AUzws1ozdNbfe+KOWLqVrp6GIwiWcream5hy3YDaKlGUh+v/fw==
X-Gm-Gg: ASbGncuBoTtq5M+m0g67IQbac0KBhTPwvH7JwneTT3SYMLqK7KPyL3W6THzi/gwtE3u
	nO/iVS59pgDAmitVM+Xf+Hd+ZpurB9+G7DJPsooswkzMn7/TNv7sudgHjyLVxgch6lcDCb0QTw8
	6iC8TUkntAhAem5vRjbqijP0GK8BMYQKkDHZzIfJpXaJHfqch2PusWYXFfNamo1pdNlysaZ0i2J
	nprkvHrSWALIpqCFGTbEZD6IXKdQ6pjbiF6dy+6idSMBULhrptwz84rsi1sQZkxRzPJKGDyuzp8
	Euz06OvPMpX4wVM48hngWhREGMJyCpTDeBso+wv8P8RbjOXwtbhmOuaQMWI9Vki5ZBVuK8tUhB0
	5K4uDs10npEmmp6joV2dVZH6b
X-Google-Smtp-Source: AGHT+IH1lN2al6JTw5QQsQ9qpNP6cxNTDsWTacqoyv01lc/4DCqB4SHp9Th/paa5zzUapLHOMA1Qdw==
X-Received: by 2002:a5d:4ec8:0:b0:3a3:62fa:fb85 with SMTP id ffacd0b85a97d-3a362fafcb2mr5203658f8f.28.1747556611850;
        Sun, 18 May 2025 01:23:31 -0700 (PDT)
Message-ID: 
Date: Sun, 18 May 2025 10:23:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/16] xen/riscv: introduce platform_get_irq()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 16:04, Oleksii Kurochko wrote:
> 
> On 5/15/25 9:33 AM, Jan Beulich wrote:
>>> +int platform_get_irq(const struct dt_device_node *device, int index)
>>> +{
>>> +    struct dt_irq dt_irq;
>>> +    int ret;
>>> +
>>> +    if ( (ret = dt_device_get_irq(device, index, &dt_irq)) != 0 )
>>> +        return ret;
>>> +
>>> +    if ( (ret = irq_set_type(dt_irq.irq, dt_irq.type)) != 0 )
>>> +        return ret;
>>> +
>>> +    return dt_irq.irq;
>> What guarantees the value to be at most INT_MAX (i.e. no silent conversion to
>> a negative value, signaling an error to the caller)? Actually, looking at
>> irq_set_type(), what guarantees irq_to_desc() there to not overrun irq_desc[]?
>> There are no bounds checks in aplic_irq_xlate().
> 
> I'm afraid that both aren't guaranteed. I think to have the following in platform_get_irq()
> should be enough:
>      BUILD_BUG_ON(NR_IRQS > INT_MAX);
> 
>      if ( dt_irq.irq >= NR_IRQS )
>          panic("irq%d is bigger then NR_IRQS(%d)\n", dt_irq.irq, NR_IRQS);
> 
> Probably, the first could be dropped as I'm not sure that anyone will use such big
> number for NR_IRQS.

I'd say better keep it, even if largely for doc purposes.

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 08:30:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 08:30:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988859.1373259 (Exim 4.92)
	(envelope-from )
	id 1uGZPd-0007zz-Jn; Sun, 18 May 2025 08:30:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988859.1373259; Sun, 18 May 2025 08: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 1uGZPd-0007zs-GL; Sun, 18 May 2025 08:30:25 +0000
Received: by outflank-mailman (input) for mailman id 988859;
 Sun, 18 May 2025 08:30:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGZPb-0007zm-VN
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 08:30:23 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 567c57a9-33c2-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 10:30:22 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a361b8a664so1952386f8f.3
 for ; Sun, 18 May 2025 01:30:21 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-24.ptr.icomera.net.
 [185.104.138.24]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442fd59702asm95871195e9.39.2025.05.18.01.30.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 01:30: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" 
X-Inumbo-ID: 567c57a9-33c2-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747557021; x=1748161821; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=vh4rP+360fa3Iqy37r1ALzCeWzwynlR+9jflAyXt+Tw=;
        b=GJr7lQDxJJWRfIWvaY1SZmtbhi+eBWEppvmFax+iyUD0EYwCfOgF83MoPPQwtnql52
         K3xtuqL1N75k/01o+fgagFVgQOxrxbjVHZg2y2GMaM+v2rWAgM9h3vy2LwbKJlYdC2PB
         al7Gbjx1y4iQ7h6q2ZfQqzFMh3fZgCFip7Cb2PyZO5OxR3k8zUpx63DX1/f8zuzD1gYi
         D8zhi0WcY/phDs013N/bvca9VYACatWnuSG/kCE4rN1nWw8wJZ6yZYUQ98KJtuLWPohu
         Hqpdf9YE6xNWdLg5w506oPdfPYuzUKsgPREUYvZUEoySLj6eirVb+DGkwLr7S+wFXph4
         ljMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747557021; x=1748161821;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=vh4rP+360fa3Iqy37r1ALzCeWzwynlR+9jflAyXt+Tw=;
        b=rFDc3OkYKg27pkYujKKp1PDfR6J4uAIbvqx97Tp4UeTgvUZzo+b9iDuWkezLD8ViUK
         GCT7wpQGLkjZUddIfOXmdQ0RKViREe3ffKuDHmnXobVAMky+/Srp4XiU8omH2n2OmpRQ
         8fXpypyR7cvrqS50J9+VJVBzyv4QugBc2mOq2P8262UKdSTbtqH8phCTLWlviHdhQJu3
         MHisRj0c+jDZ6TAu0tKF20W6CkmdvSm7garfixf6FnBrAKX70brnsrPtOTDh+95/4mP5
         QAvtIAss7ukMCi5kb89oHK/Hb0b//a4gx5GHqh53mblamcPfJc7q9xYPXmxsjrAdhh84
         mXwQ==
X-Forwarded-Encrypted: i=1; AJvYcCX3vjGcDoP6XzjIJLo7hKsGAgJdgOhDOQBZsijfVymgkZrgjefMBW3Uzqn96PuXga3S2EMKe99pNUc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YybM0C5e2YxX7Etbulp/3VLAj7SHa7dXMT9BE70pHm9sUbD8Mmx
	ekpgCIJqkXSmbBUEKnotZdl9JippUNskjOTtTWxQ+3TNyN1I70oOt95QCze4ZwHIkQ==
X-Gm-Gg: ASbGnctIq0WjbBxTUJ1zgHztKP2pcW2J5OciRRWODffVtVqN8CjpTnqac4K6kIz6Eb7
	gzem08XQ7nedeKkiF7aMTPXZZOhWt3U6f/WyqBGj751UFq+bAfORqq6NYleqMasze/JlpI/Vggr
	v10XV48TesVNYrywOnb3mEfEFzr3qSTVY5N/3hnGZU6th7dmvAVP8VteaCrZYvId6sfF/VV2wth
	e11nPidQXDW3WAnhqL5xkxKMCK8cg71ox1toxvnLMMk//kdok9zyq66o/KrczNM8fM5JTDUwtXd
	OhD5PNm/tc1x+lDZD0LFbY5QHDKtYx6L20YLE/7ytI0Q+kq4wGlLqM7Kl+U0UXCBjbBZKTkiYJt
	iApJFAp9qBppyXoQ5H1O/KKjj9/Gz1f24eik=
X-Google-Smtp-Source: AGHT+IHlcTN6AcT9ZeJRemXsHX5v5B3q0zlxC2LOR97S31OVh+WCBakJ8hYaW8qc0ucPnkS1zPayeQ==
X-Received: by 2002:a05:6000:2012:b0:3a0:7b07:157 with SMTP id ffacd0b85a97d-3a35c808b0fmr8098089f8f.9.1747557021093;
        Sun, 18 May 2025 01:30:21 -0700 (PDT)
Message-ID: <8fab4920-c03b-4eed-8bf0-474cdb094e4d@suse.com>
Date: Sun, 18 May 2025 10:30:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/16] xen/riscv: dt_processor_cpuid() implementation
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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,
 Bertrand Marquis 
References: 
 <4e4b3a018e8dacbe85cc080d9209e2ba3cdf4330.1746530883.git.oleksii.kurochko@gmail.com>
 
 <125e918d-7c0f-43dd-8ab9-c0e0bcbf640e@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <125e918d-7c0f-43dd-8ab9-c0e0bcbf640e@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 18:02, Oleksii Kurochko wrote:
> 
> On 5/15/25 9:56 AM, Jan Beulich wrote:
>> (adding Bertrand as the one further DT maintainer, for a respective question
>> below)
>>
>> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>>> Implements dt_processor_hartid()
>> There's no such function (anymore).
>>
>>> to get the hart ID of the given
>>> device tree node and do some checks if CPU is available and given device
>>> tree node has proper riscv,isa property.
>>>
>>> As a helper function dt_get_cpuid() is introduced to deal specifically
>>> with reg propery of a CPU device node.
>>>
>>> Signed-off-by: Oleksii Kurochko
>>> ---
>>> Changes in V2:
>>>   - s/of_get_cpu_hwid()/dt_get_cpu_id().
>>>   - Update prototype of dt_get_cpu_hwid(), use pointer-to-const for cpun arg.
>>>   - Add empty line before last return in dt_get_cpu_hwid().
>>>   - s/riscv_of_processor_hartid/dt_processor_cpuid().
>>>   - Use pointer-to_const for node argument of dt_processor_cpuid().
>>>   - Use for hart_id unsigned long type as according to the spec for RV128
>>>     mhartid register will be 128 bit long.
>>>   - Update commit message and subject.
>>>   - use 'CPU' instead of 'HART'.
>> Was this is good move? What is returned ...
>>
>>> --- a/xen/arch/riscv/include/asm/smp.h
>>> +++ b/xen/arch/riscv/include/asm/smp.h
>>> @@ -26,6 +26,9 @@ static inline void set_cpuid_to_hartid(unsigned long cpuid,
>>>   
>>>   void setup_tp(unsigned int cpuid);
>>>   
>>> +struct dt_device_node;
>>> +int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid);
>> ... here isn't a number in Xen's CPU numbering space. From earlier discussions I'm
>> not sure it's a hart ID either, so it may need further clarification (and I'd
>> expect RISC-V to have suitable terminology to tell apart the different entities).
> 
>  From device tree point of view (https://www.kernel.org/doc/Documentation/devicetree/bindings/riscv/cpus.txt)
> it is just hart which is defined as a hardware execution context, which contains all the state mandated by
> the RISC-V ISA: a PC and some registers.
> And also based on this for DT binding:
>    For example, my Intel laptop is
>    described as having one socket with two cores, each of which has two hyper
>    threads.  Therefore this system has four harts.
> They are using just harts and in DT it will look like 4 node with a number in reg property which they
> call hart. So from DT point of view hartid is pretty fine to use.
> 
>  From specification point of view (https://riscv.github.io/riscv-isa-manual/snapshot/unprivileged/#_risc_v_hardware_platform_terminology):
>    A RISC-V hardware platform can contain one or more RISC-V-compatible processing cores together
>    with other non-RISC-V-compatible cores, fixed-function accelerators, various physical memory
>    structures, I/O devices, and an interconnect structure to allow the components to communicate.
> 
>    A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-
>    compatible core might support multiple RISC-V-compatible hardware threads, or harts, through
>    multithreading.
> and (https://riscv.github.io/riscv-isa-manual/snapshot/unprivileged/#_risc_v_software_execution_environments_and_harts):
>    From the perspective of software running in a given execution environment, a hart is a resource that
>    autonomously fetches and executes RISC-V instructions within that execution environment. In this
>    respect, a hart behaves like a hardware thread resource even if time-multiplexed onto real hardware by
>    the execution environment. Some EEIs support the creation and destruction of additional harts, for
>    example, via environment calls to fork new harts.
> 
> DT's CPU node should be refer to core plus hardware thread (or threads in case of multithreading)
> in reg property to be close to the spec(?) but basically in DT they IMO just describe what in the sepc
> is called an independent instruction fetch unit.
> 
> I still think that it is fine just to use hart_id. If to be close more to a spec the unit_id(?)
> but it is more confusing IMO with what is use in RISC-V's DT binding.

Based on what you quoted above I think "hart ID" is indeed appropriate here.

>>> +/*
>>> + * Returns the cpuid of the given device tree node, or -ENODEV if the node
>>> + * isn't an enabled and valid RISC-V hart node.
>>> + */
>>> +int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
>>> +{
>>> +    const char *isa;
>>> +
>>> +    if ( !dt_device_is_compatible(node, "riscv") )
>>> +    {
>>> +        printk("Found incompatible CPU\n");
>>> +        return -ENODEV;
>>> +    }
>>> +
>>> +    *cpuid = dt_get_cpuid(node);
>>> +    if ( *cpuid == ~0UL )
>>> +    {
>>> +        printk("Found CPU without CPU ID\n");
>>> +        return -ENODEV;
>>> +    }
>>> +
>>> +    if ( !dt_device_is_available(node))
>>> +    {
>>> +        printk("CPU with cpuid=%lu is not available\n", *cpuid);
>>> +        return -ENODEV;
>>> +    }
>>> +
>>> +    if ( dt_property_read_string(node, "riscv,isa", &isa) )
>>> +    {
>>> +        printk("CPU with cpuid=%lu has no \"riscv,isa\" property\n", *cpuid);
>>> +        return -ENODEV;
>>> +    }
>>> +
>>> +    if ( isa[0] != 'r' || isa[1] != 'v' )
>>> +    {
>>> +        printk("CPU with cpuid=%lu has an invalid ISA of \"%s\"\n", *cpuid, isa);
>>> +        return -ENODEV;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>> I view it as unhelpful that all errors result in -ENODEV. Yes, there are log
>> messages for all of the cases, but surely there are errno values better
>> representing the individual failure reasons?
> 
> I will update that to:
> 
> @@ -46,6 +46,7 @@ static unsigned long dt_get_cpuid(const struct dt_device_node *cpun)
>   int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
>   {
>       const char *isa;
> +    int ret;
>   
>       if ( !dt_device_is_compatible(node, "riscv") )
>       {
> @@ -57,7 +58,7 @@ int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
>       if ( *cpuid == ~0UL )
>       {
>           printk("Found CPU without CPU ID\n");
> -        return -ENODEV;
> +        return -EINVAL;

EINVAL is the most commonly used error code; I'd therefore recommend to
avoid its use unless it is indeed properly describing the situation
(invalid argument, i.e. invalid value _passed in_). Here ENODATA might
be a suitable replacement, for example.

Jan

>       }
>   
>       if ( !dt_device_is_available(node))
> @@ -66,16 +67,16 @@ int dt_processor_cpuid(const struct dt_device_node *node, unsigned long *cpuid)
>           return -ENODEV;
>       }
>   
> -    if ( dt_property_read_string(node, "riscv,isa", &isa) )
> +    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
>       {
>           printk("CPU with cpuid=%lu has no \"riscv,isa\" property\n", *cpuid);
> -        return -ENODEV;
> +        return ret;
>       }
>   
>       if ( isa[0] != 'r' || isa[1] != 'v' )
>       {
>           printk("CPU with cpuid=%lu has an invalid ISA of \"%s\"\n", *cpuid, isa);
> -        return -ENODEV;
> +        return -EINVAL;
>       }
>   
>       return 0;
> 
> I think it's better now.
> 
> Thanks.
> 
> ~ Oleksii
> 



From xen-devel-bounces@lists.xenproject.org Sun May 18 08:34:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 08:34:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988867.1373269 (Exim 4.92)
	(envelope-from )
	id 1uGZTK-0000C1-1r; Sun, 18 May 2025 08:34:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988867.1373269; Sun, 18 May 2025 08:34:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGZTJ-0000Bu-VF; Sun, 18 May 2025 08:34:13 +0000
Received: by outflank-mailman (input) for mailman id 988867;
 Sun, 18 May 2025 08:34:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGZTJ-0000Bm-0R
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 08:34:13 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df1be496-33c2-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 10:34:10 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ace94273f0dso589807966b.3
 for ; Sun, 18 May 2025 01:34:10 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-24.ptr.icomera.net.
 [185.104.138.24]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d437763sm407674966b.121.2025.05.18.01.34.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 01:34:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: df1be496-33c2-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747557250; x=1748162050; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=3WmLQ68jYJsxKS7twVfeUcQ1E0bg8HqQ2/0I3qrqIpA=;
        b=DYWo8grPTMnIxplWViceClI7QLYi3EX/eUo99CS6GAuqkURvBD81tH4TaSnAEMmxoQ
         IaeAJV4WvF1BUl1r1FNZRbPc1OKvEd0lAlyn0YSeRXLJ4I/EVQ4ze0jYA6VfobBN/7qp
         jqvF56ukuqMdNXCprRPG3n3GwAnwB7FBtg/nHJyeCeJH2Qs/nEybPWesH4eG9R899yFy
         KAz9+nnfLJlLN+1kyXmGUwk4yHxbWDgOovAhMrlldPyp8HSpecQsFP/XvCDQQa62VVn4
         Hbtq1Yi+jhDNfe6Y4/krLeJ6wq1fko+u55twH9gSlU5OfdmjgOSTQ3QksGQCha+uqD2x
         bzqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747557250; x=1748162050;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3WmLQ68jYJsxKS7twVfeUcQ1E0bg8HqQ2/0I3qrqIpA=;
        b=PEIp4h4fJeimK/m3PEBSOhAMDn587hpm4ih6/Ld6+U3NYnJOes4bA+EOYSWmZ1L4fC
         W9UrHYM45TAaAH0TnjE6YaOs1AUcRXz+VqH3jrooYvQcGjKT+oX2CXH79xBUnrpO+zpc
         qHlzs15cQqms3bd1XR7P0Nn55xefmjcAGhsVbndaLcY693EzKCVDyJ3O6OdVPoaSsshZ
         JAKAfi9246G4uzCj00eBJDsUkxU3dUy7ovvNqGvDb0sKX6opjCpIoTzMyVltJTNMQ1aQ
         im3Ct5KdeaUnV/EWGARCvPLOKpfTIWUpEcVjLqe3ePDFuf9V+aseZk6fDbN1uN7iEITs
         lLrw==
X-Gm-Message-State: AOJu0YxTzyiKyzq9NCAU9cmb7Y/wAUfPhqyPoitLUdg+YgmUf5rjdSn3
	pYmNgaDEYUDULuX/JwCtGAKD2jdYjk9J2RRvwBrojPOvQz7kTT37sgu5SqLUxVYzkQ==
X-Gm-Gg: ASbGnctOQwPbc1sx/JPUCMYpe5vF17ZkBFKyO1Q9tbO/wzBqNxKBjSKJw22snGHJgMs
	kutNipmd7H6+i1zJaYxiYXfMqAvpAm6xSIBq/Bp+nG1OhkSfi/QJckoyA3DUcfc7wNsRlp64Xx/
	IR2nc06IDLY6UCc9mjH2EUArbzctm98QE4CHRgtU5ScpGvAELU8n3NO/TmDCSp7Ra84CNM6NuFT
	4Eh0xerdvDW1Y2IyB/kIbfn6yGeY5WWUldGJsI+DzzRKhRmbCZo0v+U5eNNVAviSluRqErMdTHa
	u4GFmmWNCUQ/4rHxreK20JNrmCTvOe2hjcGStFXUD6dMaWqmOcVde/nuv8hcnkdLvVMjM/3YYRP
	jhZ7+F9MpICku8K0R0Bu5SgpB
X-Google-Smtp-Source: AGHT+IG8smgzLPQse3YG8qsW+/1ehpL5ng9CIo4OzJliXTGQ6vgoK+4xPAiR1sftyrUT486YbhcRYQ==
X-Received: by 2002:a17:907:72c9:b0:ad5:2137:cc9e with SMTP id a640c23a62f3a-ad52d438319mr944396366b.3.1747557250314;
        Sun, 18 May 2025 01:34:10 -0700 (PDT)
Message-ID: <1e5f21df-2108-47f1-a59c-7869c6edc447@suse.com>
Date: Sun, 18 May 2025 10:34:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/22] xen/lib: add implementation of SHA-1
To: Sergii Dmytruk 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD
 , Michal Orzel ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 trenchboot-devel@googlegroups.com, Andrew Cooper 
References: 
 <7fcab16c3efbc0eb28e0f8ec0d9c9d3188881ad4.1747155790.git.sergii.dmytruk@3mdeb.com>
  
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17.05.2025 20:17, Sergii Dmytruk wrote:
> On Wed, May 14, 2025 at 05:58:59PM +0100, Andrew Cooper wrote:
>> Please crib from sha2.h as much as you can.  Use xen/types.h, drop the
>> double underscore in the guard, and provide a link to the spec.
> 
> Until yesterday CODING_STYLE instructed to have 2 underscores, so I
> thought sha2.h is outdated.  I'll switch to , although it's
> overkill there and only grows header dependency tree (it also brings
> extra symbols thus hiding missing includes elsewhere).

If xen/stdint.h is sifficient here, I'm pretty sure Andrew would be okay
with its use instead of xen/types.h.

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 08:45:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 08:45:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988878.1373278 (Exim 4.92)
	(envelope-from )
	id 1uGZdn-0001xK-1o; Sun, 18 May 2025 08:45:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988878.1373278; Sun, 18 May 2025 08:45: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 1uGZdm-0001xD-VS; Sun, 18 May 2025 08:45:02 +0000
Received: by outflank-mailman (input) for mailman id 988878;
 Sun, 18 May 2025 08:45:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGZdl-0001x7-54
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 08:45:01 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 61449d28-33c4-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 10:44:58 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-441d437cfaaso19487225e9.1
 for ; Sun, 18 May 2025 01:44:58 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-24.ptr.icomera.net.
 [185.104.138.24]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442fd583ff7sm95535765e9.26.2025.05.18.01.44.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 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" 
X-Inumbo-ID: 61449d28-33c4-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747557898; x=1748162698; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:from:cc:content-language
         :references:to:subject:user-agent:mime-version:date:message-id:from
         :to:cc:subject:date:message-id:reply-to;
        bh=ysdWcVqdU/MwsXp+Sn6q1xiJ8GFq4JRmzFA0ZEf3A64=;
        b=Uh347AyNhZnWbscCAXokYoOPipWifJlctRHH2y1WWTdj07sRIEsx/4gKkFcTJA/2d/
         PMMzjeQIpZVqnh8bRqgOMW5J2nGfOqHQPH9+ebbqRzZJfn+DbSzmYJlTe/G+MU9DcMuw
         SvOWo4bJLMTjXKC/rLNmlh/D1FzR3Kqu7yiEFp0dhnuzw8Az715De+hYapoGXPv0KMf1
         n1f00EBsMD3KyjVO5c+zjAIixiFsRPoBCN5n/D6EfX0ufUUz4jOVTDwaXeZOb0G/uWcf
         C54ouYkvAx4TpIXazmOpaT8K2eKMowb4TAekVpbNoun+nY9Lb9rkjuV34VHOJJWlwiOq
         BBSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747557898; x=1748162698;
        h=content-transfer-encoding:in-reply-to:from:cc:content-language
         :references:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ysdWcVqdU/MwsXp+Sn6q1xiJ8GFq4JRmzFA0ZEf3A64=;
        b=MsOA4sXASNnXrTKuE1G42aXFy8WaVWX7+Zyk6+Z+Foi2B5FZM8QKg1UGJgC3BKq1Xa
         8NSBs35iaeFFYWNH+sK+rBUiPya36LN8e4O4R/bhVmKF47e6AcTpEfc3A7V3cNu7z0JQ
         ZyHjuW+3XEXpstWXVZzeMp/A2tFLG31fm871U50aGsbCOIUDYR5XffUITrQPAwV/6lHR
         8KAsRfjglHzpEis3MJnYQJY8xXMUzydP0/mo5YmjzQl4pWyReu7qg3B8HwCc5P0Euzh+
         wUhkL/dHoHIWS4Dlzq55vO26R8ZDK8396pxshBHP10e910vYmiJbQMInYf4rpcr1NYCj
         uKCw==
X-Gm-Message-State: AOJu0YwlgSMo1yQiewbJyp5S6ShJeDNcI70CAMQmFjQLyQeUpJ9s5MFp
	UI6vi+MGGAozEmBHS9LhDIKpAiZAxIiDKsgd0qgvyxq3ShPIaCkpmRmXVqJ/E/fpr+C85/F5esV
	gkbI=
X-Gm-Gg: ASbGncsQolfKApD+Llh2wtmyW37ItRpljOvIzAX4w+XWk8orjxDrNNWR6JU95PckHCd
	fM2MnV6bbMq7dakYegcEOMR1jKHiOOnOIYP4yHPl40FO4MnUdFXqEAfyxYP1e2a7d2HR2HSZ2B8
	I8mh1N5rcicpdaHm2/ggLYSCyAquzKTMoWvZDFT+zE9qMV5Aukt49HF4LhanFdUwRS5cWxZK7Fu
	dxnyV2HB6j4Ecl77CmeNbFGaljzKUapCOrp0xB4Zi0sgyWWaa7tsIgo2X3V55kUkO+BQEtJdxM8
	8RIqUsZW67w/n+AQPskmYhXIll5/kbs0i09KlIseHwB0RmGw8JaM4Gz/W0sw1i4qQOLKvk3RX/L
	IECCHZuG5sqBa7NV9qHZ7zZz+txSOoJklufM=
X-Google-Smtp-Source: AGHT+IEWtKg8qhT/8CzkQFugoTol3c1h29T2a1cdBUs6BzxFlmMJrTW3d5mYzuRvcm4HZkojzhNV+w==
X-Received: by 2002:a05:600c:3e84:b0:442:e9eb:1b48 with SMTP id 5b1f17b1804b1-442ff029b73mr76754875e9.24.1747557898196;
        Sun, 18 May 2025 01:44:58 -0700 (PDT)
Message-ID: <76c6eb2f-4e00-4bff-866d-fa7172e274b4@suse.com>
Date: Sun, 18 May 2025 10:44:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen: Introduce extra IRQ count domain creation
 parameter
To: Teddy Astie 
References: <9a746a8b2e9ee68a398795ecb5dcb53697aeece4.1747403245.git.teddy.astie@vates.tech>
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich 
In-Reply-To: <9a746a8b2e9ee68a398795ecb5dcb53697aeece4.1747403245.git.teddy.astie@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 15:50, Teddy Astie wrote:
> When doing PCI Passthrough with high-IRQ devices (e.g NVMe drives),
> the default limit may be unefficient as not all domains requires
> more IRQs.
> 
> Introduce a new parameter to allow the toolstack to tune the IRQ
> count if more is required.
> 
> Signed-off-by: Teddy Astie 

Sure, why not (suitably fleshed out, as e.g. you say ...

> ---
> 0 extra_irqs is meaningful, though I am not sure how to expose this
> special case.
> 
> This of course wants libxl support next.

... here).

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -912,10 +912,12 @@ struct domain *domain_create(domid_t domid,
>  
>  #ifdef CONFIG_HAS_PIRQ
>      if ( !is_hardware_domain(d) )
> -        d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
> +        d->nr_pirqs = nr_static_irqs + config->extra_irqs ?: extra_domU_irqs;

I think you're missing parentheses here around the ?: expression.

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 08:52:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 08:52:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988885.1373288 (Exim 4.92)
	(envelope-from )
	id 1uGZkz-0003hd-PZ; Sun, 18 May 2025 08:52:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988885.1373288; Sun, 18 May 2025 08: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 1uGZkz-0003hW-Ml; Sun, 18 May 2025 08:52:29 +0000
Received: by outflank-mailman (input) for mailman id 988885;
 Sun, 18 May 2025 08:52:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGZkz-0003hP-9O
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 08:52:29 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6caa409a-33c5-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 10:52:27 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-441d1ed82dbso34014495e9.0
 for ; Sun, 18 May 2025 01:52:27 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-24.ptr.icomera.net.
 [185.104.138.24]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca5a03fsm8654536f8f.22.2025.05.18.01.52.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 01: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" 
X-Inumbo-ID: 6caa409a-33c5-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747558347; x=1748163147; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=7hQPszjAy/1n+/eu+fcw3zTmBHelRbdxongLDQosijs=;
        b=TnvugMPIPkAPKlDDk6Jj0lPnKfzyhUaWVdTW+2t9r/LqZ+8tn7C/lgNuyvre1O9x6T
         bqNFYQ5UrBQnPj4xMJk7QvroeD44nTcL/dvraXm+8V3iKniuR3xuONuZMWZY09bjtBPI
         aL7siWeHdGpKD8tDGcTK3RJWiqFtekHGe+Sp+zUL3ZcV5fVZZal13jNit8+Gq3GSEWv0
         iiJSbuCK+3fZhuOGoqcaUporsjIUvB8KYFAHqSpVgxM9vkP7C1aWErM2+nHECs3Ypxdg
         lVLyRtesNy/6NaCuPRH2KA1ZUNJ0xN+YyAgdQ2PPR39gIR/lASseix2RpXBDfkL1i4k1
         WDRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747558347; x=1748163147;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7hQPszjAy/1n+/eu+fcw3zTmBHelRbdxongLDQosijs=;
        b=WKyj511ex1dQ7YtzmLW+k6PNewFeHfXna3DvktBfrIYiOmm+E0+0y2gFppOWvRWdKo
         FAI2BQaBeuHpDMWvNwS62CiNdBzZv0mjUU2sel7RGzxY2y9DnoQ5ARX+Z3ym6jXTr0wR
         LDj6wkTNVuPZdWz2e2hNZjTq7WCzGAC6HrgrqveFHgdDvjRfmAmzo54+lbaRQhH/mMj3
         8UKijPGix+mGhR8yJFWmTfKlvryYk7qchVhjoQKb8FsvDfh/R7e1cFm53U4AWorb7Qor
         aGTShTIysZmXdnwLjD3Fe5sloCP3HSJOgS5DOzhrbvDz1vYshnHTtqyFx42F18JCU7KX
         k6aw==
X-Forwarded-Encrypted: i=1; AJvYcCVqoDeVDCFaIVqh/p/1Ydhbxb0YiKGpM+JyBqyxuWQphFoKQt88Cq4J/9zgaNxKHWwD7wqW/XxI/wQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywr8ASGDxdaZ+FVm8T1oUzUJkrk8MM8tkrwfKptwAA4L3B+FY0M
	wGg0GQQtwmu0y0vQihgcO7/IIq7mFGunE2uE5NMISatcfD5lCE9kxppYC4ZG2DSbSg==
X-Gm-Gg: ASbGnct6AGcmaasMGZtGlX3ZhrQloj0b0Us6VEIZN3oOFnwHDWDFYoCfd11+Lj20lw+
	G5YZasRv8Tllh3E5+/hRIoTYOd6WV7n6JzZ4qrSAZj6zpRYFdCiYY/Wxywbn5xdWRhCo3Xu1Imt
	prwr9oUqNd3numN0KoekAiZfsaWPSs69rUnLdrxwYR+egGjo0psF8SIJTSSQsFW0dnTo22aofLn
	5sJR3iYPxyl/hErbERw5cIWaaf3clo7BypZKGS6U72Bx7yfT+hqHqPSmCC8tGXyZkzEQ24fayG1
	Fxx/9oqbUuYmfSdgktZXxTsCKGpfOCAfA6yRlMzb0r0reCiXA1BMILIHV9c1P/d+S2s2g9x1yH/
	UrF2KNTgEjYD70QYv6Q7IepFBIst6teHpA70=
X-Google-Smtp-Source: AGHT+IGJHM3j1OoqHds2WTop51IEzxWY5/3TYMvbvkv/05LPVVv5adxHDtQ8ALQp90zdkJzj1VAibw==
X-Received: by 2002:a05:6000:2289:b0:3a3:6a2b:ab25 with SMTP id ffacd0b85a97d-3a36a2bac49mr2005435f8f.45.1747558346848;
        Sun, 18 May 2025 01:52:26 -0700 (PDT)
Message-ID: <98c10f03-c5f9-4e89-9aed-596b5cc3f8fd@suse.com>
Date: Sun, 18 May 2025 10:52:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/2] xen/domain: unify domain ID allocation
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250516020434.1145337-1-dmukhin@ford.com>
 <20250516020434.1145337-2-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250516020434.1145337-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 04:04, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Currently, hypervisor code has two different non-system domain ID allocation
> implementations:
> 
>   (a) Sequential IDs allocation in dom0less Arm code based on max_init_domid;
> 
>   (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
>       max_init_domid (both Arm and x86).
> 
> It makes sense to have a common helper code for such task across architectures
> (Arm and x86) and between dom0less / toolstack domU allocation.
> 
> Wrap the domain ID allocation as an arch-independent function domid_alloc() in
> common/domain.c based on rangeset.
> 
> Allocation algorithm:
> - If an explicit domain ID is provided, verify its availability and
>   use it if ID is not used;
> - Otherwise, perform an exhaustive search starting from the end of the used
>   domain ID range. domid_alloc() guarantees that two subsequent calls will
>   result in different IDs allocation.
While you properly retain original logic now, the above is not an accurate
description thereof, imo. To search "from the end" usually is understood as
a backwards search. Whereas what you mean is that the search starts off where
the last one finished, wrapping around when hitting the end of the valid
range.

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 08:57:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 08:57:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988892.1373300 (Exim 4.92)
	(envelope-from )
	id 1uGZqC-0004JK-CI; Sun, 18 May 2025 08:57:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988892.1373300; Sun, 18 May 2025 08: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 1uGZqC-0004JD-8X; Sun, 18 May 2025 08:57:52 +0000
Received: by outflank-mailman (input) for mailman id 988892;
 Sun, 18 May 2025 08:57:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGZqB-0004J7-Mw
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 08:57:51 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2be8bbd4-33c6-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 10:57:48 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad560321ed9so52046066b.1
 for ; Sun, 18 May 2025 01:57:48 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-24.ptr.icomera.net.
 [185.104.138.24]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d498747sm416150366b.137.2025.05.18.01.57.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 01: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" 
X-Inumbo-ID: 2be8bbd4-33c6-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747558668; x=1748163468; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Kz7f1C2I6AGys/C5VOBEZ9aH2iob1WrVwTpTuQEnu1g=;
        b=HIp5ceYxpIC2YqyAplrxTYgElEmyepZIFO0+JmTJKF5JySMq87uf/r2Inyk9L+GYFK
         BJ/Me/biYf4q8Agm8QGZscddrWsjmWdTy2uwpKyL80VtgxNKoQ32kPaOWFBIwGGODghh
         r41ftTi994MGW9/e8zloQxSTq3cQCVehKsNstao3SPF6oGgKyfQAVfadaWlhRlqDU1o2
         rzaQm11vsadte5vvUfaSj33jiLRLvOqNG5Twd2icx0gXeWGNnwgrjbZ1x6dvj5PEwutS
         0IaZk+43ICeOE6ExOpF8wu7yj6/Ac57DEouZzek5M5VL3sHe+dFJcxbxgdwghKTD8Po2
         sqmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747558668; x=1748163468;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Kz7f1C2I6AGys/C5VOBEZ9aH2iob1WrVwTpTuQEnu1g=;
        b=FQlHK06XT/7JCnw+C9SlHnsxkjnD3MBntUyYY3CkMOnESeNLmhfH9JRuCnr+dR7inK
         PsIPwdWSVI3aotjIDupoE34eIeLGFKo72AJKpnfdPUREEGWso4bhfC5qcLT0Pxzu19me
         3a8aIz7778ZH3UrcV0Y5mcBewRUWWoTg0OOdezSIf4xqlg/ouotfme+j0WaRX9w69TZt
         Tr8e8e4LMhTIWhnVAeOhhd+AHXh/AHZj9CVnHws8hCoYMPEvzoEiXuIrGruzAVcxgjQG
         pgxRbSxifmrdTlH53hvO7V6M8QuZg5NHGrOlwkpIoDzHe8vPQNdksX3M0iWTkCjeP4BC
         d6Sg==
X-Forwarded-Encrypted: i=1; AJvYcCWfmwyjdItiGNRtTcG3f0PlDegbLclC33dKBuxBZBBj72/KQImY+UJZcBE3m4FOF0gnEM5mcgwc4P4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx7zRcFaW2pVD2ZbR7dingYUgqTDEr/9Xm29QsxzBvPrZ/cqDld
	oexap4DPhjwe8c4uC05tM++ea3G3g4YBVmX8B+VnCKzj2RcJdMpWkJjUV8q8HykvgQ==
X-Gm-Gg: ASbGncvCU+QW14197jp1J1LWGbBOv7gxfrs5PE7NpWePOqUcNMDwpSdAWCgJjd2wEIc
	CkPtV3wgUpSITTe9mndsy4hBNqwfTvubT3ewj/06cmy8jermJKHCtbyuDWuvhTqYC7hUVVThbdE
	8AOXci204ntpWnq2X4MI4bQYJq+6LGS2v+HOsTPyY9RoEyFaJNYEH7s4wqGYhpuTnakkhTKnIe6
	qaGDgKgJvyhrV1u0WdH3IhiznWbtb7vq9zSjej6MvDxI0lVpz+FVvAnXc5AhWJZ+A231AijgzVb
	6sGkIaMWln3xNxOqfy6IY4K2mCVrXWd1Ge3InLaLM6O4XVjxswcIypq7CUIsWMV1X4kTzZuecHb
	3lCKKDQ5vI844r1H3Onf2Sqc8
X-Google-Smtp-Source: AGHT+IGis5/2Fy94dOE0bzoO//MlEp19t3QCpX/GEXA4BCqLUSkXOxToXkttCKwPpnwaQFPvqfx+IQ==
X-Received: by 2002:a17:906:c113:b0:ad5:6174:f944 with SMTP id a640c23a62f3a-ad56174fb0amr185603466b.50.1747558667720;
        Sun, 18 May 2025 01:57:47 -0700 (PDT)
Message-ID: 
Date: Sun, 18 May 2025 10:57:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/2] xen/domain: adjust domain ID allocation for Arm
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250516020434.1145337-1-dmukhin@ford.com>
 <20250516020434.1145337-3-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250516020434.1145337-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 04:04, dmkhn@proton.me wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -85,7 +85,7 @@ void __init domid_init(void)
>   *
>   * If hint is outside of valid [0..DOMID_FIRST_RESERVED - 1] range of IDs,
>   * perform an exhaustive search starting from the end of the used domain ID
> - * range.
> + * range, excluding get_initial_domain_id() ID.
>   */
>  domid_t domid_alloc(domid_t domid)
>  {
> @@ -103,6 +103,9 @@ domid_t domid_alloc(domid_t domid)
>              if ( domid == DOMID_FIRST_RESERVED )
>                  domid = 0;
>  
> +            if ( domid == get_initial_domain_id() )
> +                continue;
> +
>              if ( !rangeset_contains_singleton(domid_rangeset, domid) )
>                  break;
>          }

Isn't there a (perhaps even pre-existing) issue here with a DomU potentially
getting ID 0 assigned when get_initial_domain_id() returns non-zero?

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 11:24:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 11:24:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988963.1373309 (Exim 4.92)
	(envelope-from )
	id 1uGc7f-0005KD-4d; Sun, 18 May 2025 11:24:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988963.1373309; Sun, 18 May 2025 11:24: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 1uGc7f-0005K6-1R; Sun, 18 May 2025 11:24:03 +0000
Received: by outflank-mailman (input) for mailman id 988963;
 Sun, 18 May 2025 11:24:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGc7e-0005K0-9j
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 11:24:02 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 98533ea8-33da-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 13:24:00 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43cfba466b2so37770425e9.3
 for ; Sun, 18 May 2025 04:24:00 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca888fcsm9346273f8f.78.2025.05.18.04.23.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 04:23: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" 
X-Inumbo-ID: 98533ea8-33da-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747567439; x=1748172239; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=ISVlo5CkaHqObbg8m9QzQeot5/VqVMTOtl6H4zBVWbU=;
        b=IobFZHXu+ucW4ipourL6xfZHL/ce6UT7EGNfrKFIsrO+cp6ZqevWPgvHxv1jVPMhr+
         VA+Tx3jw/f1VodWiuxLW6Bs1KAlpJcepGeOQlhYxOIyKOq0pOk1woYm/DjpLubupb/qK
         vGgY5biWO9il7bTapPUpHY5OaBk3RrB0xZyO9rsOh5leZliWJU7HFJ5Rl5DWEYv7xEwM
         H1Zexnfwfvs/ZxAZ4S3zw4B4i75ItHAQIXtQqrlIikJRyIo4JwzloP64M0GfMPFm2rZc
         9QVeO/QiN0EftmNvdC5zPCsWx+61BdYm0MXuLBzkadLZUnbwocr/f6WNHrrwrFwpDwVb
         54nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747567439; x=1748172239;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ISVlo5CkaHqObbg8m9QzQeot5/VqVMTOtl6H4zBVWbU=;
        b=WncrR/Coxsbe3tN9tdtYxWeHvvU6uolCL316FrIl0YH9cXhnzuq9dVawhDZXrjjOeT
         qL8t3oftkDLuNPnJXB0gxpFYcw9+KHrHQCkZaRAop5YSjx4jOwH+DJppJd54hzlidwg+
         Cz40wlJPlp980TkCyk4gWWTiG9LkUmaRU+zwjNHZRO2WAiW5gaRt/KzWpoNVx8v+CtB/
         og3Hz6cco4pleRs9LV87ak74dgec67o+dCFXG5Vblaw+1EUa1fDoWtZrnxrxshsBsvza
         RgDtdrHsuNqSZP5BmmAf21z8h+qziAWBhi/GtI2RS92qc9Rm+IZMzws+dStP5Esm5Ehz
         L75Q==
X-Forwarded-Encrypted: i=1; AJvYcCVlr8r1+CNVVaq7kyWgzHYQq0GMlQUuHz/Pp7481U1HMPO5EzM9OhbW3OjHBacw93m8PNPupWwf7m4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyLqZMTtwkzDNZ1G/M54T3DuSJ+rfzA/2xd74Z/048HhBOArMqc
	9ZFgMOSfs0JaHeUUfN7JoZUeWy7tovkM5MZsG0v8QwXIbzF62PDVB4pvuZY5yKMhSmIft0hlpYR
	gz3M=
X-Gm-Gg: ASbGncvVcJNbixA/KVq1kwYo7G2gp1y+A0ckBUhbreItGW95i/9/mV2v4IZEByuaCzB
	g5B6EYTnbyPUBjHGYL0A6B2783u+lMtxjLDXYy/Yjzhd1rh4if2EHfaBIkqaa9iBtzdDL6zjfZO
	moEeHAd+zUy7HfnZqSUqO/LaRPBjs5cBjjZ6aSQnaZGKOcWUxgPKE7ol7/CYATKKEK23JTib6dH
	u/ffP3V+bWEeN7sElKwcdA9SOS62Myu0sejpWSHkkWf5Sof1ImqdK4qPs8hZjfViY3/hN3uNPhT
	J3NlNpW3WyAIuoV0Kn43LtMzovzRwoOH86z9TvkgmPHxL9QS6AAV7Vadosw2G2PrHBmByxtJD9C
	tE+DdQSIEK3adwzytN7MyPb0rrwa++9gSMog=
X-Google-Smtp-Source: AGHT+IEtrY2tkm+X6QdVhUSyPmEce2mFk4GFUIf6+8n2tI0nvDwmhtpEccYq/1Vy9fZnrsLDcgKEew==
X-Received: by 2002:a05:6000:4284:b0:3a1:fd60:887 with SMTP id ffacd0b85a97d-3a35ffd2bbbmr6966880f8f.45.1747567439481;
        Sun, 18 May 2025 04:23:59 -0700 (PDT)
Message-ID: <30797d9b-8ba4-4ffb-8b85-251ff585afc2@suse.com>
Date: Sun, 18 May 2025 13:23:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/6] x86/pv: fix emulation of wb{,no}invd to flush all
 pCPU caches
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-2-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250516094535.63472-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16.05.2025 11:45, Roger Pau Monne wrote:
> The current emulation of wb{,no}invd is bogus for PV guests: it will only
> flush the current pCPU cache, without taking into account pCPUs where the
> vCPU had run previously.  Resort to flushing the cache on all host pCPUs to
> make it correct.
> 
> Fixes: 799fed0a7cc5 ("Priv-op emulation in Xen, for RDMSR/WRMSR/WBINVD")
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Sun May 18 11:25:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 11:25:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988969.1373318 (Exim 4.92)
	(envelope-from )
	id 1uGc8b-0005n1-CM; Sun, 18 May 2025 11:25:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988969.1373318; Sun, 18 May 2025 11:25:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGc8b-0005mu-9t; Sun, 18 May 2025 11:25:01 +0000
Received: by outflank-mailman (input) for mailman id 988969;
 Sun, 18 May 2025 11:25:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGc8Z-0005mf-Nb
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 11:25:00 +0000
Received: from mx1.somlen.de (typhoon.somlen.de [89.238.64.140])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b9915a83-33da-11f0-9eb8-5ba50f476ded;
 Sun, 18 May 2025 13:24:57 +0200 (CEST)
Received: by mx1.somlen.de with ESMTPSA id 2F2C55030C4;
 Sun, 18 May 2025 13:24: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" 
X-Inumbo-ID: b9915a83-33da-11f0-9eb8-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1747567495;
	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=gTwALlSlBrfcKIjyGIAuCx9O/M4hyllBp+pmzkxrghA=;
	b=NLboTpCL9YuPxkMVYXSQHmc1aokiwhG/MyQLYLHz5mdUXkUlPSptIOZ9W4TIM6/lstJEPz
	XnSFE4dLD3zvHdin7d7SspGaB6qQ5t11TkKPTNz3yXfwx5Tu8Ipa7riNJr7xPA1zMfCiK8
	XGfgO75k7Mw/sV9KpFje2mSqh8Gow21WqSf7k20QUuhe7RNUbeJaVqj1Ze51y7fe6xUuRw
	h8nxCw3LVBEShrUO8X+rKfVLgVpqCj0d4jfgiQdgzgCRJeesYkqWVp0BGE8vYL06iEVoxV
	sJevA8SyUH8sb9j98f3wuDJpkSTQRW1EKdUVinyRAAsGFfSSHiwj83lk6MsulA==
From: Maximilian Engelhardt 
To: xen-devel@lists.xenproject.org, Jan Beulich 
Cc: Ngamia Djabiri Julie ,
 pkg-xen-devel@alioth-lists.debian.net
Subject: Re: Request for patch to fix boot loop issue in Xen 4.17.6
Date: Sun, 18 May 2025 13:24:44 +0200
Message-ID: <2911767.Y6S9NjorxK@localhost>
In-Reply-To: 
References:
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1803761.X513TT2pbd";
 micalg="pgp-sha512"; protocol="application/pgp-signature"

--nextPart1803761.X513TT2pbd
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"; protected-headers="v1"
From: Maximilian Engelhardt 
To: xen-devel@lists.xenproject.org, Jan Beulich 
Subject: Re: Request for patch to fix boot loop issue in Xen 4.17.6
Date: Sun, 18 May 2025 13:24:44 +0200
Message-ID: <2911767.Y6S9NjorxK@localhost>
In-Reply-To: 
MIME-Version: 1.0

On Montag, 12. Mai 2025 10:54:50 CEST Jan Beulich wrote:
> On 03.05.2025 16:02, Ngamia Djabiri Julie wrote:
> > Dear Xen developers,
> > 
> > I would like to ask if the following fix can also be included in Xen
> > 4.17.6 (and eventually in the Xen versions after 4.17.6 that don't have
> > the fix) :
> > 
> > https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=dd05d265b8abda4cc
> > 7206b29cd71b77fb46658bf
> > 
> > This bug causes a boot loop in nested virtualization environments (for
> > instance nested environments that use VMware Workstation), making Xen
> > unable to start. It was introduced in version 4.17.3 and the fix has
> > already be included in 4.19(.2) and 4.20(.0) and woud be planned to be
> > included in Xen 4.18.6 in the coming weeks.
> > 
> > Even though Xen 4.17 is in security-only support, this is an issue that
> > blocks testing and usage for users and projects such as Alpine Linux.
> I fear I don't view this severe enough an issue to break the security-only
> status of that branch. People concerned ought to simply update to a branch
> where the bug was fixed. Or the distro could include a backport.

The Debian Xen team now got a request to include this fix in Xen 4.17 in 
Debian stable:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105222

We understand that Xen 4.17 is in upstream security-only support and thus this 
patch will not land there.

Debian can take the patch if it's confirmed by upstream Xen to be fine for Xen 
4.17 and low risk. We had problems in the past with incomplete backports of 
patches that turned out to cause regressions, so we try to avoid backporting 
patches without upstream Xen confirmation.

Maxi
--nextPart1803761.X513TT2pbd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEQ8gZ7vwsPje0uPkIgepkfSQr0hUFAmgpw3wACgkQgepkfSQr
0hUpDw/9GSBGt6WWiZIN2cHXYuJn/xxbWVkjUW+MlsoJYNi3xYiZCN/bS61oNTsk
/+ma4eINfbskUyP7oBO9B0mvtkjss1eqpipVDFefTyZXlEuLUkD/U5uR0tnvzuNe
sFWMcfpD90rcOHjiRNFiY/wTOIvc/774CXnxYHLdYaqZjbQB9LsZydDZlnW9XCrz
v4MJtq5W8JeCT2PsKkOsn6fNX/VANsCJ9O3DjVYC44r8uQiT5m9BL6iSS3eBXEMD
f4MzrxUES0r4sL5x146knTDto+APbCddIOy/HC0ZNQlyvZliSRX8U6b2oQNEWuis
56aSkfp0Gs6rA87R44mnJNoUG0zyy88GU1XqIqI/zsgw4K+O6xnrW8QT2cXBxE3O
azvplujT4oPmiDmtYixvIZrr3p0cS5ARnMgNBbAG4jSHoLFRg9kzKeQLhQ82bpnr
gGcRlS2gLNeXzEo4yZM3hPe3bAGgEt0KEhhFsXgvgzd6EU61yOW2ks0LxWinKtOE
bDABV+dXECdXcWxrVM7aSbUnGCTzrz7wIKWFNMWZHwq4scAa7mO34sM0z+s8Ei6k
PwkqkPs+jqh7zsOzgEPz4YOVeNFMmY6ZtOyEoXN2gNvgG3vm7H/cYwazzXxdxdsR
79wVliVrzpWRX1SwpKPz7e9sUcEzgEJEFf00dfa1P9GcMAU8wj8=
=QgOQ
-----END PGP SIGNATURE-----

--nextPart1803761.X513TT2pbd--





From xen-devel-bounces@lists.xenproject.org Sun May 18 11:30:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 11:30:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988984.1373329 (Exim 4.92)
	(envelope-from )
	id 1uGcE9-0007NI-W6; Sun, 18 May 2025 11:30:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988984.1373329; Sun, 18 May 2025 11: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 1uGcE9-0007NB-TB; Sun, 18 May 2025 11:30:45 +0000
Received: by outflank-mailman (input) for mailman id 988984;
 Sun, 18 May 2025 11:30:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGcE8-0007N2-Ia
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 11:30:44 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 888e7552-33db-11f0-9eb8-5ba50f476ded;
 Sun, 18 May 2025 13:30:43 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad2216ef31cso600628966b.1
 for ; Sun, 18 May 2025 04:30:43 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d278257sm432995566b.82.2025.05.18.04.30.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 04:30: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" 
X-Inumbo-ID: 888e7552-33db-11f0-9eb8-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747567842; x=1748172642; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=fT5qFUdstaJsfU0VbsAMfpbT7j0sIORq0zcqhKf+2xc=;
        b=VKrYfExHvxnrStU2segaLEvPf5LbIeL6JjBgGzJ5NxtaAMv1Y+8AAqTm0tF7/XhJpi
         Fo2f0D25vACcXqH1/3G5ClXvfj4cq7IBOv/6qiT87I51NQE8dyxbOlukF7wFA08/by5F
         Gv7JTQB5ifgCpxn1P1NA0IrlmQH706gpGGYaIQSiJymZZb8MavbHFNGreTz++Q9WbD6f
         UJoZocgnMk2BPWunnMR8xY7lrbsFCLVJejC75mwj8GgOTaXWqaVeUJXvBYu6CDAtNZEI
         z2O1bHbcrWBQlA7oGFCSO8imIe8IcMQDBt6hbGgX42B0uWNTLSG2roaXJOPn+htNpBXK
         xWYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747567842; x=1748172642;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=fT5qFUdstaJsfU0VbsAMfpbT7j0sIORq0zcqhKf+2xc=;
        b=REZqB16DjJZDI2m300IhIsOT8DY5uIIJZWylYNcRD0DDGV2psluONv3DtYS0GntdW3
         5G3NSyjmVdzzkvHl2z13zgqAc/tvQxDkpGOJ9nK9GNXhDOKbA/XCmzBDxuxsqHUppR3k
         W7PrLz/rszKEvPQpgmCgqw/zjaY3hQ/pu06h/9j0fqBHKuCE76/aVLeNfwgviMCLE+1o
         kjolzmbwFmb3hRVF8p19t+jmgycHWRy+YeuIUZKTZQ6ChMSazJ3t+oUiXMFO9Ut1TGi6
         PVfaMVmxXDszgv+35tP8UUGa1IVeXJdPKXOECQo8dQo/APxip/IZMBy+5Ylhj1XCUgiT
         n9iA==
X-Forwarded-Encrypted: i=1; AJvYcCU8aWJ/YpkZumeFAZ2qr+43BR9RCwSz56xzn4DcsnX5/R+Qiz08vk06Qqqo1hZo3aISGXMAnpPuVCw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwFPrMiuARiTEo1jmDZ2HJcXfHi9AJvlpfIkiFgBUMxlS3/L9pv
	M2GuFA4G0xRQBhlfDWXaEKkNkvAiEd9K/+6X/EDpknOHHg1hQ2Eeb+iathct8faajw==
X-Gm-Gg: ASbGnctCTbg+PFG82wqaLqtX9lqXqdT9wrev7DgWoPul3Yys3zred1FnuzyuplXthgv
	dqKN8jHXQBRCCQL9ULsyQGvyi+E2s41tZ/4voS+4HHP6vHCwDHnYk4jwCBd/oW+c6DgvZCX84Oa
	IiY9dL9zlPQAAWTZ/5O8t69OXFuSw85lu0KsKUH1bgePT1JYVRfd/MALU6zPoLPu/8CKQvuDka0
	IhNeoD/zdCVGViQxR+79wceO3UJ4G12/XtSFqsxy6g0m6d/U0NnzZm00RmGiESdA2w5/bEItmJv
	6YcJD6h2429jm72w4x5WMcwGT3mWINQINg70DDAWcXQvsGnxwfNJ+BydYGvpKHzt9lI/gUSWdC/
	NTWWYKIMgjbu2N3CeaCcS+cAl
X-Google-Smtp-Source: AGHT+IERauixBHvi4TculVjOfou45Ib1nbCipmzvzJd9op95368vhRnLGBsUEdgQdrZeatupDmQcMQ==
X-Received: by 2002:a17:906:580c:b0:ad5:4440:23 with SMTP id a640c23a62f3a-ad5444022c4mr461592666b.50.1747567842603;
        Sun, 18 May 2025 04:30:42 -0700 (PDT)
Message-ID: <03b9a6d4-26af-4da4-91a1-69d50ad0bc15@suse.com>
Date: Sun, 18 May 2025 13:29:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/6] xen/x86: rename cache_flush_permitted() to
 has_arch_io_resources()
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-4-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250516094535.63472-4-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16.05.2025 11:45, Roger Pau Monne wrote:
> To better describe the underlying implementation.  Define
> cache_flush_permitted() as an alias of has_arch_io_resources(), so that
> current users of cache_flush_permitted() are not effectively modified.
> 
> With the introduction of the new handler, change some of the call sites of
> cache_flush_permitted() to instead use has_arch_io_resources() as such
> callers are not after whether cache flush is enabled, but rather whether
> the domain has any IO resources assigned.
> 
> No functional change intended.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Changes since v1:
>  - Drop adjustment to l1_disallow_mask().

Moving the change to the next patch instead, as I see. For both
patches:
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 11:32:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 11:32:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988994.1373340 (Exim 4.92)
	(envelope-from )
	id 1uGcFb-00080j-GS; Sun, 18 May 2025 11:32:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988994.1373340; Sun, 18 May 2025 11:32: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 1uGcFb-00080c-Bu; Sun, 18 May 2025 11:32:15 +0000
Received: by outflank-mailman (input) for mailman id 988994;
 Sun, 18 May 2025 11:32:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGcFa-00080S-4h
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 11:32:14 +0000
Received: from 20.mo550.mail-out.ovh.net (20.mo550.mail-out.ovh.net
 [188.165.45.168]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bbc2369b-33db-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 13:32:09 +0200 (CEST)
Received: from director1.ghost.mail-out.ovh.net (unknown [10.109.176.14])
 by mo550.mail-out.ovh.net (Postfix) with ESMTP id 4b0dvX5QlNz1V68
 for ; Sun, 18 May 2025 11:32:08 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-wr8zr (unknown [10.110.188.199])
 by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 900C21FDB2;
 Sun, 18 May 2025 11:32:07 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.113])
 by ghost-submission-5b5ff79f4f-wr8zr with ESMTPSA
 id UpEeGTfFKWiFMAUAM6NgiA
 (envelope-from ); Sun, 18 May 2025 11:32: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" 
X-Inumbo-ID: bbc2369b-33db-11f0-9ffb-bf95429c2676
Authentication-Results:garm.ovh; auth=pass (GARM-113S007347eb199-d7a0-4959-83eb-6c62728e0a82,
                    6FCDE7FC3973969C7D59E240015AF9737BA2D6B5) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Sun, 18 May 2025 14:32:04 +0300
From: Sergii Dmytruk 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	trenchboot-devel@googlegroups.com,
	Andrew Cooper 
Subject: Re: [PATCH v2 09/22] xen/lib: add implementation of SHA-1
Message-ID: 
References: 
 <7fcab16c3efbc0eb28e0f8ec0d9c9d3188881ad4.1747155790.git.sergii.dmytruk@3mdeb.com>
 
 
 <1e5f21df-2108-47f1-a59c-7869c6edc447@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1e5f21df-2108-47f1-a59c-7869c6edc447@suse.com>
X-Ovh-Tracer-Id: 14211108627590460561
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdefudekgedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggugfgjsehtkeertddttddunecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepueeiudeuveffkeetveelgeehhffgheehgfegjeekleffgeelffetjeefieetleeknecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheehtdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=A3QBxkKpVCVjgwuef/9wAIZTtHsvjnR1T9c1lYRISTI=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747567928; v=1;
 b=cgZGxeFjxUY5PPbRa4TfP61GFw3RDfeu7l5drnUWaql8XauzkCPQEZx607CjAW3rLfK9Y5Cb
 b0ODfbM/ae7RtAApKZhLC/NHlES7eTQgWHwRgeeAxEMdHfj87grecNiYTSygqHx3UkJCdPxn2zp
 qPnV0Wq7Hcyq7CVNYVPRtr9h8Rm8n1ZPyMzcj4Z8Nb4SnTyWYODzARleW1FZburvky3B8/uHS26
 UL/0FsTFA++k78yp4ww3gsbr6q4YlMIcCarF9jACqR9/UQ8C0ueYQl6bVXtptKDbidloVhtNaZC
 kSEMrQ+6P/4peP4i2mvOHkM2riyXcqLA/Jp2tk8hp1tqQ==

On Sun, May 18, 2025 at 10:34:07AM +0200, Jan Beulich wrote:
> On 17.05.2025 20:17, Sergii Dmytruk wrote:
> > On Wed, May 14, 2025 at 05:58:59PM +0100, Andrew Cooper wrote:
> >> Please crib from sha2.h as much as you can. Use xen/types.h, drop the
> >> double underscore in the guard, and provide a link to the spec.
> >
> > Until yesterday CODING_STYLE instructed to have 2 underscores, so I
> > thought sha2.h is outdated.  I'll switch to , although it's
> > overkill there and only grows header dependency tree (it also brings
> > extra symbols thus hiding missing includes elsewhere).
>
> If xen/stdint.h is sifficient here, I'm pretty sure Andrew would be okay
> with its use instead of xen/types.h.
>
> Jan

Oh, there is size_t, so  is actually appropriate.

Thanks


From xen-devel-bounces@lists.xenproject.org Sun May 18 11:32:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 11:32:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.988999.1373349 (Exim 4.92)
	(envelope-from )
	id 1uGcG2-0008Sj-Mq; Sun, 18 May 2025 11:32:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 988999.1373349; Sun, 18 May 2025 11:32: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 1uGcG2-0008Sc-KC; Sun, 18 May 2025 11:32:42 +0000
Received: by outflank-mailman (input) for mailman id 988999;
 Sun, 18 May 2025 11:32:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGcG2-0008Hz-04
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 11:32:42 +0000
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com
 [2a00:1450:4864:20::42a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce877166-33db-11f0-9eb8-5ba50f476ded;
 Sun, 18 May 2025 13:32:40 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a108684f90so2377181f8f.1
 for ; Sun, 18 May 2025 04:32:40 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca88a34sm9064017f8f.70.2025.05.18.04.32.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 04:32: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" 
X-Inumbo-ID: ce877166-33db-11f0-9eb8-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747567960; x=1748172760; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=DUw1+po8yRZDZl8O5oIFcz+dPtTqviLAjE8T18Oia/Y=;
        b=JdAFxvak9gCv1hqbD2T9psEk8aMbL+3z9ylBFG5vQmyYK1auvsB9Sj5jZ0KkdBxMP7
         tDMqFBwnTwSZt+XcWBdmJlZ1tBUOMVxkUveuBglnIF2tNRqsDbpJCcCs9qyxGQQfgPlv
         YHEdfnvtf59VMBIoP0RJJdgqmrpxm3UnIVFkY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747567960; x=1748172760;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=DUw1+po8yRZDZl8O5oIFcz+dPtTqviLAjE8T18Oia/Y=;
        b=KFF0dT+Rk160bMJI2uMyJmbXMN6swfU8m8fbqhqP6pNwXhTPv3/mzzV2+rDoFp8Wvq
         ABAQ5TMke8fhXrb7iAQA1atNC2FojqycqQWCfrszRD3zrQFVlkXVCkpAmDj19+3nWfF+
         PzB2FY3l+bYm7pLLnKSslkPlL7EfZ+8ixJjoiSwncKp8KRdxTO5pYWta95o8Ft/As47J
         S6/+mHs/plC5+GwDUtTgNN6B/99n4aqbZJv0SeLOYWeC8pdkGOX8BOEoIomEpXokJpcN
         5PSVXS48HJBZGzmq6Sytg5GLWizfblR+mEwyTzi0kJIoPX0ql1semEs30a3y2ox6/QTt
         39Ag==
X-Forwarded-Encrypted: i=1; AJvYcCXkiJA+zuiWoD4yIoxuTYsEcVDyp7TOujqY9khxlMhR0B2oBaYrTYq3Bjs3C047wWtHr+NqjVJa4y8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzkkyJIcMSFVGPiitxZ9/C0cnWfyYMRpQ+IuNHuiVeMtPMJGLj3
	OT6fiWDReL6CYdHp4AWTxWv4dghU+2XRKZTFggyysiCNTvJzWPqjLJPN/n09S8HXo6Q=
X-Gm-Gg: ASbGncu01F1QUOhAj62VzkBpL5mGuGYsBTcGYF9++pOVezA9SZA3FpjLFTykxls0IC+
	43VZuOtWUKjYPIEF+lJfYBfMPPz+VCJMEtWjJSIAbrLL96jZVE3lRwKSg0j1dQBg2lPfYbnZzWJ
	O2MY3Y20CIwfLsR7lu90NB/1yqG9PRhssmrorMDFzmcDZT3KGAGwp7aqIGeh8UD7i+0Lffzs7hy
	FWfNfcpGA0afnpgux3mU/fs1FyzHhqtiC003VwKwTBaKjl+1k90ENk3oR8YBZRLAdzmOeIlaoAD
	/VdyjIZiNGLLIEPbD9Q74bUnWVYEmggOh5OcJEf5e83K2WnPxIhgk9k8V6bO+Jy0CUtrWfb2Seb
	dWftDJAWYnp2uqd5Y
X-Google-Smtp-Source: AGHT+IEfbnJCpKXqrGSjr8rdMcaYTKRfTCePkPmrTfMwrk+57WfWXVk7N4tlqHcD8MJQSUgD7nqb4Q==
X-Received: by 2002:a05:6000:240a:b0:3a3:67e6:d27c with SMTP id ffacd0b85a97d-3a367e6d3d6mr3911060f8f.38.1747567959986;
        Sun, 18 May 2025 04:32:39 -0700 (PDT)
Message-ID: 
Date: Sun, 18 May 2025 12:32:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Request for patch to fix boot loop issue in Xen 4.17.6
To: Maximilian Engelhardt ,
 xen-devel@lists.xenproject.org, Jan Beulich 
Cc: Ngamia Djabiri Julie ,
 pkg-xen-devel@alioth-lists.debian.net
References: 
 
 <2911767.Y6S9NjorxK@localhost>
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: <2911767.Y6S9NjorxK@localhost>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18/05/2025 12:24 pm, Maximilian Engelhardt wrote:
> On Montag, 12. Mai 2025 10:54:50 CEST Jan Beulich wrote:
>> On 03.05.2025 16:02, Ngamia Djabiri Julie wrote:
>>> Dear Xen developers,
>>>
>>> I would like to ask if the following fix can also be included in Xen
>>> 4.17.6 (and eventually in the Xen versions after 4.17.6 that don't have
>>> the fix) :
>>>
>>> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=dd05d265b8abda4cc
>>> 7206b29cd71b77fb46658bf
>>>
>>> This bug causes a boot loop in nested virtualization environments (for
>>> instance nested environments that use VMware Workstation), making Xen
>>> unable to start. It was introduced in version 4.17.3 and the fix has
>>> already be included in 4.19(.2) and 4.20(.0) and woud be planned to be
>>> included in Xen 4.18.6 in the coming weeks.
>>>
>>> Even though Xen 4.17 is in security-only support, this is an issue that
>>> blocks testing and usage for users and projects such as Alpine Linux.
>> I fear I don't view this severe enough an issue to break the security-only
>> status of that branch. People concerned ought to simply update to a branch
>> where the bug was fixed. Or the distro could include a backport.
> The Debian Xen team now got a request to include this fix in Xen 4.17 in 
> Debian stable:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105222
>
> We understand that Xen 4.17 is in upstream security-only support and thus this 
> patch will not land there.
>
> Debian can take the patch if it's confirmed by upstream Xen to be fine for Xen 
> 4.17 and low risk. We had problems in the past with incomplete backports of 
> patches that turned out to cause regressions, so we try to avoid backporting 
> patches without upstream Xen confirmation.

Yes, it is safe.

https://github.com/xenserver/xen.pg/blob/XS-8.4/patches/backport-dd05d265b8ab.patch
is the backport I did for XenServer's Xen 4.17.  I don't recall there
being any conflicts or problems.

~Andrew


From xen-devel-bounces@lists.xenproject.org Sun May 18 11:38:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 11:38:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989018.1373359 (Exim 4.92)
	(envelope-from )
	id 1uGcLJ-0000gG-A9; Sun, 18 May 2025 11:38:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989018.1373359; Sun, 18 May 2025 11: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 1uGcLJ-0000g9-6y; Sun, 18 May 2025 11:38:09 +0000
Received: by outflank-mailman (input) for mailman id 989018;
 Sun, 18 May 2025 11:38:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGcLI-0000er-Il
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 11:38:08 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91b52ed2-33dc-11f0-9eb8-5ba50f476ded;
 Sun, 18 May 2025 13:38:08 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a367ec7840so584369f8f.2
 for ; Sun, 18 May 2025 04:38:08 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442fee0d216sm96895835e9.26.2025.05.18.04.38.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 04: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" 
X-Inumbo-ID: 91b52ed2-33dc-11f0-9eb8-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747568287; x=1748173087; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=SnQRWMmIf3B5ilXU5R1PFjc1RhI5ZUdJRKxRApkykH8=;
        b=esAEoiIInoZ2ESYi5yEpV2RKd1pizfMDXu+ppArbdIYqnKK+Lh2JlCoTgCNPa/pm21
         zSr+Icp/R4PJAL3yjEYfQSk7hyw6z+lisWcxZ477r79D9RTaTi0dkAQb4AWdrJWwCi+D
         PdBCwADMe2xkUDLL1Qc7+RIQNadrvSopovY0kFZkaoD875l40EzHeCApKY5Jmpqz9avS
         Fh56DtsHA917gc/6nZ/rIVSZho2+PDvitfoAFw1wddXIj5cts4IldSV1dcRatRh/PAfb
         tiy/p+j9xcTxQKFd2KE7SWw8UK52gJfFRCMR7CHZdPrdn73rdxIZsLiDGEBdAJR83ebS
         6sNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747568287; x=1748173087;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=SnQRWMmIf3B5ilXU5R1PFjc1RhI5ZUdJRKxRApkykH8=;
        b=OlX0drSiRcBii19ExKl8w7exMKKDs08w2OdBfK0mTH+tMIbqAKZR5VAarbv/CGLkMB
         qxP/rnkW4QwEEiATgB+bs13q19ETeU7Tjf/XZk/TagFWv/W3YEioP15mNOQHIiyM36k0
         up6c4sHkngRCvi8zLdTbnjNx6PQ3loNxFEvduDqWApMzCh0gVfh24Y0ltMpT4Fbe5wiz
         SNaJ9yvgnzVLNRMGV5Q/vYHSL7oLaaV9AW1NdszQiO8iPSe/b/Fvbylmc7Sg3Hlw5Kdb
         ZvRoXTxgtk9R+cQ6rsLW5AbfjgPlsfkVetAO4wObJ96/knj6exnVLGF/cLgQA0WLEVNj
         2jDg==
X-Forwarded-Encrypted: i=1; AJvYcCVQEShiT4rztdiNLbWGpOr9DI/Cw/9Aqyj1qfzMnm7sq7LLEaujrjSJcBLQtD2cqvtVfxYxWwMvpqE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxgF59Cd7LjTutaAHM6klrIjCY4kQ9n0THajxc1x6b5uWBJ9gll
	GSn19kaDz7PaJ97URB+HTcDu6n5btelT7+vQfTNSd5Jy8kZ0EPxip6/wuxb8//qnJw==
X-Gm-Gg: ASbGncuISz2dRW/np7pslGs2VGh7rnQyJYdCvAT1dpkDC7mnpeNIB6E+DZ+89GTSs25
	G+ZK9hzj+4vl12b2+kvteFcgERIZtO05OJtxfqpjIH2gOPFL8aJ/5Dt9iicSX7J65GaL6YM2XAL
	8TtgefQH5MQiKA4LlYqe2Ceg6azyjbf35BwAxo4rzDYKXKhWftdcdHv6ny5MiQRoCxnwU5QiwdI
	Hv9Fef7KtbcwVH+70U++CxKFa7OQ3dllyUTO0XzUXjelRpAV9Srw4Mn+R06hb0NCkh3IgnzWYEP
	B3GvrlQttOapgC1e+6qqJe4Vag+6mAKlX7VDEOTwmMez9A0j8UiRWRftkKyN/DLPbpzZCAaxIXY
	8IdY/7yPkShxLAsk9MX3IbHOJ
X-Google-Smtp-Source: AGHT+IHoFuETHi1SOfs6lDE985+jOAh1brNzeadiaTFP50x7DFPBJ0PE38tzKjE+tdOlYfnVIRUJog==
X-Received: by 2002:a05:6000:420f:b0:3a3:6991:dcbb with SMTP id ffacd0b85a97d-3a36991e1bamr2856439f8f.12.1747568287436;
        Sun, 18 May 2025 04:38:07 -0700 (PDT)
Message-ID: <8bf8072f-c379-416a-9d7d-912db7084e67@suse.com>
Date: Sun, 18 May 2025 13:38:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/6] x86/hvm: limit memory type cache flush to running
 domains
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-6-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250516094535.63472-6-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16.05.2025 11:45, Roger Pau Monne wrote:
> Avoid the cache flush if the domain is not yet running.  There shouldn't be
> any cached data resulting from domain accesses that need flushing, as the
> domain hasn't run yet.

This again plays into what we started discussing already: There may still be
data in caches due to Xen or toolsstack behavior. Imo to compensate we'd need
to do one flush right before unleashing the domain. Yet of course this makes
sense only when we make sure to not have (cachable) mapping in Xen for any of
the affected ranges. Hence, with that not presently being the case, ...

> No change in domain observable behavior intended.

... I agree here, thus ...

> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 

The situation may want discussing a bit more in the description, though,
which would make me feel less uneasy about that R-b.

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 11:45:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 11:45:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989025.1373369 (Exim 4.92)
	(envelope-from )
	id 1uGcRr-0002RJ-U2; Sun, 18 May 2025 11:44:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989025.1373369; Sun, 18 May 2025 11: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 1uGcRr-0002RC-R6; Sun, 18 May 2025 11:44:55 +0000
Received: by outflank-mailman (input) for mailman id 989025;
 Sun, 18 May 2025 11:44:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGcRq-0002R6-Kf
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 11:44:54 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 82e6f05e-33dd-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 13:44:52 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-440685d6afcso37461495e9.0
 for ; Sun, 18 May 2025 04:44:52 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a369140048sm4395130f8f.57.2025.05.18.04.44.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 04:44: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" 
X-Inumbo-ID: 82e6f05e-33dd-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747568692; x=1748173492; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=pUVGFaRpGvlS/Wi86yKY81ZWPOYmg2FwKplMhYbHfmA=;
        b=Kr78/edJFkMDUbgKhP7eFCkhAY9qk7GwvC63pbFvpWW1+/GhUT7k0x0kxXEv7jHZjQ
         04jms1bUzGCEda6pHUxQhaqf2lV4NMVzD3sdeWqfb9HdS8CksDHWV5nRaSnpnDxuuHxa
         5EuxWUGM9HM2Z/60JVB2ITzWrgg5GAuMvIF+0AUFCu0l7lpgfuUDaVBMYy1dtWCJqBG0
         YpjYj1Z8ZZHBIR5a+erSdiXYBOJT/rMh69y+rbLU3x+XOkPvu10Povg6rrlMBs74wffB
         STo5ARblNuwnY4AcNmr80RWlp6MLAqDjD2bd4zRq2ay26GulzPr+fV30/snzalmQyc9V
         VCuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747568692; x=1748173492;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=pUVGFaRpGvlS/Wi86yKY81ZWPOYmg2FwKplMhYbHfmA=;
        b=JJknLvxUucIsKpv7yZ8l9BNJ1A4obKV5kSihBRHABDHgZ4F0cHLUAqzoNO+Lmo+C2N
         NMhnKS2e9JcVHaKqBvTtmXV6mavESkXTmcDzQsIh6BmYEFHiO4ErPA5E+Mmv3kN50Kat
         ranVceZQWmp06CfV4ew41lVRNH6uAHZU0BuCOG0QPWWetQGoYL3xc2G1JTnvLWQtqyC9
         oK3UcjubhklgmGCvKIDhyq1ldsLldI0UWjKlYFmevZR0+td5tHtxahs2Tj8roBFEW0/j
         r5c8bF4C/cftgfdFdosxEOIPupJeO1Cdm67wuPrHaL5cPQ4Xi+Es8kGu0eNaxih3pn82
         RUXw==
X-Forwarded-Encrypted: i=1; AJvYcCUxb6Y6HlXuLPt0vVKuoG3UELj/IxooerRFg3+CDE3oEgGKbrzzWNHTR/d8nIoETp6EFe5HUNhSBRs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwDv4QE59iW4ln8XwUVRYUwytXMcNDTD2ZqnOE0XODa9V/ibYp7
	p9EDW/lXu+Ov66zNTWpU6tNccdR3zwFjAcedzQI+pkSF9NB2VN5+V0kV928IL+fE9Q==
X-Gm-Gg: ASbGnctAK36xzJ50eXTYT/slddv7xumO/BsPzKqZ0lP7K3MlORE1+krJuF0xxwstHMK
	vQXnv2pmJbcKavyh+JiTJyOdvoHoFSHVFLtBevYQYZn+dOwMFAWfbAiQt9x8O/6cHMAXkaVHKt5
	4SVLQGX4Wq8kzF1FeZe8Mu8W2BNL4deIZo0ry8I3PUNaiN18BXVK29QJlr7k/YhBLJg6UMwCjGZ
	nhv+xVRNd/N+Cg3i6g3oyhediAsTK/T/FqK4PLzOXwrz6N+mVw0hYIzZZb2Ox5pSGOaA8E9rzp9
	tKpoUHJieNeKrRouunhFsAwgANCZcohOrKDTln9bgoRWUz0KCRPvnUzsBhsyediq050+GlZ/Ni1
	HPDH1mJkD8z/oXs/7lVj3xAbA
X-Google-Smtp-Source: AGHT+IF1LWny7MFyhW03YpKrhd0rkHi7jURU3la5NzeYa0Xspyd5K41CZH1Ws+OoVPa3Hw6JUE3p4A==
X-Received: by 2002:a5d:64e3:0:b0:3a3:6cf9:9b63 with SMTP id ffacd0b85a97d-3a36cf99d95mr1046773f8f.31.1747568692042;
        Sun, 18 May 2025 04:44:52 -0700 (PDT)
Message-ID: 
Date: Sun, 18 May 2025 13:44:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 6/6] x86/hvm: reduce the need to flush caches in
 memory_type_changed()
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-7-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250516094535.63472-7-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16.05.2025 11:45, Roger Pau Monne wrote:
> The current cache flushing done in memory_type_changed() is too wide, and
> this doesn't scale on boxes with high number of CPUs.  Attempt to limit
> cache flushes as a result of p2m type changes, and only do them if:
> 
>  * The CPU doesn't support (or has broken) self-snoop capability, otherwise
>    there would be leftover aliases in the cache.  For guest initiated
>    memory changes (like changes to MTRRs) the guest should already do a
>    cache flush.
>  * The IOMMU cannot force all DMA accesses to be snooping ones.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 

> Not sure whether this attempt to reduce cache flushing should get some
> mention in the CHANGELOG.

Err on the side of adding an entry there?

> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -782,14 +782,21 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr, NULL, hvm_load_mtrr_msr, 1,
>  
>  void memory_type_changed(struct domain *d)
>  {
> -    if ( (is_iommu_enabled(d) || cache_flush_permitted(d)) &&
> +    if ( cache_flush_permitted(d) &&
>           d->vcpu && d->vcpu[0] && p2m_memory_type_changed(d) &&
>           /*
>            * Do the p2m type-change, but skip the cache flush if the domain is
>            * not yet running.  The check for creation_finished must strictly be
>            * done after the call to p2m_memory_type_changed().
>            */
> -         d->creation_finished )
> +         d->creation_finished &&
> +         /*
> +          * The cache flush should be done if either: CPU doesn't have
> +          * self-snoop in which case there could be aliases left in the cache,
> +          * or IOMMUs cannot force all DMA device accesses to be snooped.

I think this could do with "some" added ahead of IOMMUs (maybe parenthesized),
to clarify the route to take here if and when we change the global to a finer
grained property.

Jan

> +          */
> +         (!boot_cpu_has(X86_FEATURE_XEN_SELFSNOOP) ||
> +          (is_iommu_enabled(d) && !iommu_snoop)) )
>      {
>          flush_all(FLUSH_CACHE);
>      }



From xen-devel-bounces@lists.xenproject.org Sun May 18 11:58:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 11:58:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989033.1373379 (Exim 4.92)
	(envelope-from )
	id 1uGcel-0004GO-Vv; Sun, 18 May 2025 11:58:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989033.1373379; Sun, 18 May 2025 11:58:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGcel-0004GH-TA; Sun, 18 May 2025 11:58:15 +0000
Received: by outflank-mailman (input) for mailman id 989033;
 Sun, 18 May 2025 11:58:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGcek-0004G9-AM
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 11:58:14 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5fb31810-33df-11f0-9eb8-5ba50f476ded;
 Sun, 18 May 2025 13:58:12 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a0b9af89f2so2345121f8f.3
 for ; Sun, 18 May 2025 04:58:12 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442f39e851bsm180391485e9.28.2025.05.18.04.58.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 04: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" 
X-Inumbo-ID: 5fb31810-33df-11f0-9eb8-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747569492; x=1748174292; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=EfFDD0Ep71bUkaHEZI4plG/Hq+OZ0RUEHTBA7USNnFk=;
        b=QvtzH3WLR9KpRytOPiHf+mjgzUwO1qaXKcrFSUninJ2XB8qF2WWMf4hjg2J8RyVopQ
         xWlvtFfmcNU6Yfn9IBpuhHCMUCotN2kDSPnPPsx2bsuMWOswwiv1l/1FEGc8jQ5dJYTg
         KuQkpJqBpMq5SIgEx9WBtC/7O3gmd/uNXTT7cOmPwfT+plKFS4ITlLYjP7y6ewSbIXhM
         LxtAzamL99z5BUNhknHC5/+Bt+aHGyagFghUH6TkzXBkby6uOjGlDRJlQTQyVwxwOBRX
         b0QFhnM18jUVWdmKLG2iZ7+V5mHuVQyY0qILqSRHnhy76xSTAyYg29ZYioDObDYRd7Cj
         /92g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747569492; x=1748174292;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EfFDD0Ep71bUkaHEZI4plG/Hq+OZ0RUEHTBA7USNnFk=;
        b=Iu/8Jimz18CR9cRKhhbHh6V75sucj3FtcSiHJ1kdcwe36quWHl9ByiBAEdVQt/R7JA
         9UyAf/AEQgVZ6QvO89u41S2k0XVVfln6A8PGygm3E57rFedZfc9Ozk/NBWzH1WIDBOk6
         2meLGvgAla3iEXBUEqsVP2M+HanBcqZanM7Tb8KNJyDvf8pG/upGfB6K/IG81ga4a1Mm
         XKBbSeV+P7HOu9fgEsPsZMriizI9/1pntyKZtsswdOLXKT+///6t3Q6l1Xd8rE88LPbB
         do/SyaQli05ADbaEwq4wAYgFLH6ezVML77fiAYd7hGgk1TKd0WXWN/VU55e68RHFirB1
         7J+A==
X-Forwarded-Encrypted: i=1; AJvYcCWl+n7RlFnurcAwiZwRYQjgGBC5JB9ceY9PWqQJUBVA+qvzDdxONgA9GyY8KDGugPHOHtNJ2/pyOGY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxXlBmN1Igf1hM5RmiENBnZIkFPrzoWDKkx3SUggDRCDpMZARAp
	w4gUarIgrv218QO6mNXhK1ikQzBNK0LFsbsjuKqAMa+5YrpC40yAf/YOEJpJCsafJQ==
X-Gm-Gg: ASbGnctZGrA0l0bHOYmVRVPsqD44AubY4WFXCiRr0EjUBPPwB0gv+O6CQr6Xf3ft3YO
	u6IIKUZwOLCOli0FRbWFTebaSULwCDl95FNiEisH1uKpuT+Lm0ugJNbYyZgs+6guZTaoxpM9qnm
	coBGQJEfFlhW2AV/x5Va0c0xpYNNZO2ECCfsNV7K6dApZr2H8Fbw2pKloRDlRtyCl6keDDnNwRh
	83ptqEeBS+9VY+Yr9s3Qr55yWaV+DT+5aQkTclGK36crDpvbk/HOMX8Yt/tDQkt2ZByMFpuRGoo
	3XtK5mH5d32P6OvnGP/WXc7iAzdZbLWWopPPkMwkGeGGsJJiD77fhagBVJyo65bwxISN6HqUebd
	a0QEFYo22QstlEiPiuKbfPiSSvlDMKmZJE3Y=
X-Google-Smtp-Source: AGHT+IHZrks0jbhlGLi+2hT+pf60RGgtpIVUiYgmhpz8o5NSdYrp9tMnLXEvdupH6VrPdqMvfnb85Q==
X-Received: by 2002:a05:6000:2ae:b0:3a1:fd74:4248 with SMTP id ffacd0b85a97d-3a35fe5c64fmr5330916f8f.5.1747569492104;
        Sun, 18 May 2025 04:58:12 -0700 (PDT)
Message-ID: <523bbab2-01fc-4ed5-910a-09e8f25a8296@suse.com>
Date: Sun, 18 May 2025 13:58:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/5] livepatch: Embed public key in Xen
To: Ross Lagerwall 
Cc: Kevin Lampis ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250515093822.659916-1-ross.lagerwall@citrix.com>
 <20250515093822.659916-3-ross.lagerwall@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250515093822.659916-3-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.05.2025 11:38, Ross Lagerwall wrote:
> --- a/xen/crypto/Makefile
> +++ b/xen/crypto/Makefile
> @@ -1,2 +1,15 @@
>  obj-y += rijndael.o
>  obj-y += vmac.o
> +
> +obj-$(CONFIG_PAYLOAD_VERIFY) += builtin_payload_key.o

For new files please prefer dashes over underscores in their names.

> +ifeq ($(CONFIG_PAYLOAD_VERIFY),y)

This isn't needed, is it?

> +key_path := $(objtree)/$(patsubst "%",%,$(CONFIG_PAYLOAD_VERIFY_KEY))

Since they can be used there, dashes imo also want preferring for new
make variables (unless they need exporting to the shell).

> @@ -143,6 +144,11 @@ struct payload;
>  int revert_payload(struct payload *data);
>  void revert_payload_tail(struct payload *data);
>  
> +#ifdef CONFIG_PAYLOAD_VERIFY
> +/* The public key data contained with Xen used to verify payload signatures. */
> +extern const uint8_t __initconst xen_livepatch_key_data[];

Nit: Section placement annotations are generally meaningless on declarations,
and hence want omitting from there.

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 12:08:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 12:08:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989052.1373390 (Exim 4.92)
	(envelope-from )
	id 1uGcp1-00066w-0z; Sun, 18 May 2025 12:08:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989052.1373390; Sun, 18 May 2025 12:08: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 1uGcp0-00066p-TT; Sun, 18 May 2025 12:08:50 +0000
Received: by outflank-mailman (input) for mailman id 989052;
 Sun, 18 May 2025 12:08:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGcp0-00066j-Bk
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 12:08:50 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id db06cd9e-33e0-11f0-9eb8-5ba50f476ded;
 Sun, 18 May 2025 14:08:49 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43cfebc343dso25066035e9.2
 for ; Sun, 18 May 2025 05:08:49 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca4d230sm9097583f8f.4.2025.05.18.05.08.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 05:08:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: db06cd9e-33e0-11f0-9eb8-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747570128; x=1748174928; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=ZJaxceEbx1hG9jeZHaW0n8Na17V6UW7vFwACzQTFrTg=;
        b=CbwMpxoN9wrglJm9VJzuArRfm13i/mYrTy+zWtEqG/HLFv6iB9CeUcph43OqZniiMF
         /sgl4czi/2a91Cn5OQ0qAY96OcKR4Ci4Yqd+mEPG31KrWg0oVZMov/yTZ/LdhemsOjPB
         RiFuMNaul8R0Zi3stGN7tjpV/I12r4c25huDUiAskpZbTR10scS9vCOhyL/Ws6G+jzwd
         2twCqnI2Rs3Lek3C1Sx0vgNg5PPkMNin+HFSHpfn7DzzrYNneoPeUTuUh8p1sY8GtzmK
         oQYbL/wTnL2V5czTWuCAn+Z9eLi3wMLW250VKts2/yBHLKc4aQwh1FfsfsLuxHJlt8DG
         i1/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747570128; x=1748174928;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ZJaxceEbx1hG9jeZHaW0n8Na17V6UW7vFwACzQTFrTg=;
        b=N4mB7ilLBqv5gtOdCiKCjRkJEy1S3Fe0lOyHU3VhGyfAYal/PAyQ+0LhhvmdmSHINr
         DEPkkTwFtf2PLgNLgtQYyIgCsftJSXlVC1ml9GbuwGt8WjxhkjPy8GNWWCri/SyHjyHR
         pOfO3liZuDAe1/TwLrH56cC9ZRx9qQVskvikR2rOlSWFWKyZhW7vKGpq9pQb806tizdK
         tUFdyXdZNBZXWwH7dZnlVUPbp46f1Rth3DmwTYDZKTMEqFxuEqlcPPAHhuttKXjsJETQ
         8O7w6qgpBVHOsPEnjQtv/hkxZPcYoQyNelHleO/NWWAZzbXqagAo9iu68v5x/PgtR6dR
         F++Q==
X-Forwarded-Encrypted: i=1; AJvYcCWCd703dqI3ajUF3EGTMJEz5aKxkDOg+uPZ9H3ot9B9AI9tWKWGCojv5MrpRH2htA/19MRuvuAyRbM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwuJIXKGjApw1TSN8VYJcKbHJ9QhIk1pyXd2SRuA7dMXZ7L9HTu
	Xjkv5zftqjlYlZtUYpH6fOO43rnTrvkZi4fCPOxvXN8chFWdzumkFXTtumnWslNlsA==
X-Gm-Gg: ASbGncs7WSJUp/NumaT8XQ0MGtt91ZpRxfolR5n2LX/VV2dcRqVP3yxEM/1f/DIL4bF
	Sq/MlQeFYlW9Xhhsx7hgiKweMTGDx9aaIUeNBb4hmfGRkCyeP8kSFlXjnHb3HvEXr2n0CZkWfYJ
	oA/wRx71MrISf26kBYj1CjLpNNtjtCtyAwuvkA9pjWhmnQLmKo1YjpBRbJ9/y9B5/pTSH1ofkJo
	VNHth7Ryqiuuw5ZY39XAyCBxcM6WHMto9CWfEhvpVs7MlkPMIKCtGCQlPUFBGrqS2DUtONNbp1g
	RdyV6/uvrl4uqjyqOAPab4dPGtyw+MF7jYO5gOzQOsCx1Nu6OkrSX2qiYax/0Ld9k0vZIZBk3nt
	ldB6z35WbvqBS6YFuf8vjNJ9G
X-Google-Smtp-Source: AGHT+IGrB7lPiaiivVX0lak8ubJVhQ4AZCWd17ta6Z+tXkyLcjqYe1hOeMbQNxSn4kvEmCRvS/uZtQ==
X-Received: by 2002:a05:6000:40d9:b0:3a3:4b8a:9a36 with SMTP id ffacd0b85a97d-3a35c808b92mr8665482f8f.11.1747570128462;
        Sun, 18 May 2025 05:08:48 -0700 (PDT)
Message-ID: 
Date: Sun, 18 May 2025 14:08:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/5] crypto: Add RSA support
To: Ross Lagerwall 
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: <20250515093822.659916-1-ross.lagerwall@citrix.com>
 <20250515093822.659916-4-ross.lagerwall@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250515093822.659916-4-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.05.2025 11:38, Ross Lagerwall wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
>  obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
>  obj-$(CONFIG_VM_EVENT) += mem_access.o
>  obj-y += memory.o
> +obj-$(CONFIG_PAYLOAD_VERIFY) += mpi.o

This being odd and non-scalable, I now think the file would better move to
lib/. It _is_ library code, after all. Then it can be included in lib-y
(thus always being built, i.e. reducing the risk of accidental build
breakages), but will be included in the final image only when needed.

> --- /dev/null
> +++ b/xen/include/xen/mpi.h
> @@ -0,0 +1,68 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/* mpi.h  -  Multi Precision Integers
> + *        Copyright (C) 1994, 1996, 1998, 1999,
> + *                    2000, 2001 Free Software Foundation, Inc.
> + *
> + * This file is part of GNUPG.
> + *
> + * GNUPG is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * GNUPG is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
> + *
> + * Note: This code is heavily based on the GNU MP Library.
> + *         Actually it's the same code with only minor changes in the
> + *         way the data is stored; this is to support the abstraction
> + *         of an optional secure memory allocation which may be used
> + *         to avoid revealing of sensitive data due to paging etc.
> + *         The GNU MP Library itself is published under the LGPL;
> + *         however I decided to publish this code under the plain GPL.
> + */
> +
> +#ifndef XEN__MPI_H
> +#define XEN__MPI_H

With the recent change to header guard naming, the double underscore here
(and in rsa.h) wants to shrink back to a single one.

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 12:17:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 12:17:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989065.1373398 (Exim 4.92)
	(envelope-from )
	id 1uGcxT-0007rA-Qp; Sun, 18 May 2025 12:17:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989065.1373398; Sun, 18 May 2025 12:17: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 1uGcxT-0007r3-NW; Sun, 18 May 2025 12:17:35 +0000
Received: by outflank-mailman (input) for mailman id 989065;
 Sun, 18 May 2025 12:17:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGcxS-0007qx-TG
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 12:17:34 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 134ade6c-33e2-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 14:17:32 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-601d66f8cafso645080a12.3
 for ; Sun, 18 May 2025 05:17:32 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005a6e6884sm4431540a12.46.2025.05.18.05.17.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 05:17: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" 
X-Inumbo-ID: 134ade6c-33e2-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747570652; x=1748175452; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=YhM4ll+Pf7AZWlafB4PyBxXbX9rlK3MfptihHp7sVMA=;
        b=cCPHVcePLX9A2HFdfILyRULNFUg0mUKtsmzmYQeJRS5gfOohOE+vYMzeDgnUIdLBwj
         wDV3a/ouyvh6LOz/flcbztlOD3FkAqWM9A9Qfl/gqqVHOE2xxv3Z/2RnfgWT7kQtAU7K
         i1FMKyPIaOhE6L5H5glJD56XhiAHv09iJNy7JBNrvsFGO177A0e13GjZ7xjVbNrQ9Ol7
         5+w07X5UoMCkuaYpuV7LXiVGuAx3ETS4bbJUXNMqG+HrxeM6HJ6eI6Jv9fRsmGkJNm0S
         2OQmt+ntJTtRc7lyF+VQbYExocWVHIx0zyMVPMfpxz78ECtBu2Gyq47fEFlG069hpXTZ
         6Hng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747570652; x=1748175452;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YhM4ll+Pf7AZWlafB4PyBxXbX9rlK3MfptihHp7sVMA=;
        b=Gjpy7KF01TDp5q50C74CPTctzqwgvWrUJWTZluoYC2dPiHvBQxp2amJh3+U1yv1fRy
         1w6e7EcWerX1DZmz1OiO3IqJsuhY6rLz0aYOV9KLDSSrxEuJiuS3y7C8OHDEXpiafOIz
         p361mHfl5wRxRJoFg2LVlHjplALsxs8s3gCZyRSa5j+HXigXwJunM16NsMrP7RKwM9Rc
         CHp6qwWBIAMynr+rkhn507wsLFzZzlPAGsh2NMyaqbMsnFYKzLNCbDwQAcvUxo300mV0
         wDGjZFwUD9i+o90Dr7sBOOUZnCP+kMLrux+L2yUScyeEkEQYKsDoNJ0NF1zgeO4VoBNh
         MKmw==
X-Forwarded-Encrypted: i=1; AJvYcCWf3SP2m8tX3fjwC+IJE6/UYMxPxBP3XonR7vAGbt7x4tZuCbMSR3NP3IoKHkea5fi8hGekDhJGtO8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxY59zv+VFu8kwzsL9QSi9AdITo0lpGJ3yelcSsuCJ+FYxe1P/W
	QgfMiqDAm2dPyJbZZxqEh0X2I+b4V20msSBxgM5THeSNAk4+fH1icSaZOOjQVld8aw==
X-Gm-Gg: ASbGncueA+Hlw6L48JTNAD5mV4ZpzJGUM+vPhjCuFyflVfL6ZnKd3xrGMqr6Y1Kax1q
	QcCBVO/zvoAVR9S/Z5Km//Z1sMCXM3I40kxuM+Xl5qdDDAZ+BDN2AgKinlbN5ZtdulGn/YNLFFb
	R5+CJ1TTbqMGtu+ZtaPsKW737hv5g/Zv4YoczMvpcUAohelpc2opnCOQQ4oQlkHqM1g1kZoBGYK
	oxpyAyzaoQ6+8B/I1/jbF34TJ60SmClKFwCerLMQPC89357nffbnjW5NaEv/YVJm8AL3sW5+HCD
	JC3ZF1UQHyVQsBELlB7XlGR65Q0/+ADwA7onLPVGUgdT2OW3CDL6ryzxPNCOIMOhpH5byPoFmCe
	cpBPUFz/2NnjxFgUAN9OITCNh
X-Google-Smtp-Source: AGHT+IEcUcYHG7dzzvuINpaUvk5JXz8kItDV7ikg9RCI4yBuWLtYlKuyEFtdOKrMmdrtB+buIl48uQ==
X-Received: by 2002:a05:6402:5cd:b0:5f6:4a5b:9305 with SMTP id 4fb4d7f45d1cf-60119cd4192mr7388978a12.33.1747570652370;
        Sun, 18 May 2025 05:17:32 -0700 (PDT)
Message-ID: <2c5fbc92-c81f-452c-8a5a-3f1eaf53dfdb@suse.com>
Date: Sun, 18 May 2025 14:17:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/5] livepatch: Load built-in key during boot
To: Ross Lagerwall 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250515093822.659916-1-ross.lagerwall@citrix.com>
 <20250515093822.659916-5-ross.lagerwall@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250515093822.659916-5-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.05.2025 11:38, Ross Lagerwall wrote:
> @@ -73,6 +75,10 @@ static struct livepatch_work livepatch_work;
>  static DEFINE_PER_CPU(bool, work_to_do);
>  static DEFINE_PER_CPU(struct tasklet, livepatch_tasklet);
>  
> +#ifdef CONFIG_PAYLOAD_VERIFY
> +static struct rsa_public_key builtin_payload_key;

__read_mostly or even __ro_after_init?

> @@ -2287,6 +2293,31 @@ static void cf_check livepatch_printall(unsigned char key)
>      spin_unlock(&payload_lock);
>  }
>  
> +static int __init load_builtin_payload_key(void)
> +{
> +#ifdef CONFIG_PAYLOAD_VERIFY
> +    const uint8_t *ptr;
> +    uint32_t len;
> +
> +    rsa_public_key_init(&builtin_payload_key);
> +
> +    ptr = xen_livepatch_key_data;
> +
> +    memcpy(&len, ptr, sizeof(len));

Doesn't this (and the similar one further down) need to be an endian-
ness conversion? In fact, seeing how the data is being built, it's
not really clear to me what endian-ness the field would be written
in, when build host and target host endianness differ.

> +    ptr += sizeof(len);
> +    builtin_payload_key.n = mpi_read_raw_data(ptr, len);

Whether there are endianness concerns here I also don't know.

> @@ -2305,6 +2336,11 @@ static struct notifier_block cpu_nfb = {
>  static int __init cf_check livepatch_init(void)
>  {
>      unsigned int cpu;
> +    int err;
> +
> +    err = load_builtin_payload_key();
> +    if (err)

Nit (style): Missing blanks.

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 12:22:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 12:22:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989073.1373409 (Exim 4.92)
	(envelope-from )
	id 1uGd20-0001Bd-BL; Sun, 18 May 2025 12:22:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989073.1373409; Sun, 18 May 2025 12:22: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 1uGd20-0001BW-8X; Sun, 18 May 2025 12:22:16 +0000
Received: by outflank-mailman (input) for mailman id 989073;
 Sun, 18 May 2025 12:22:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGd1y-0001BQ-FI
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 12:22:14 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b9e5de3c-33e2-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 14:22:12 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5fbee929e56so6473325a12.0
 for ; Sun, 18 May 2025 05:22:12 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4383f8sm437517866b.113.2025.05.18.05.22.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 05:22: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" 
X-Inumbo-ID: b9e5de3c-33e2-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747570932; x=1748175732; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=tGw/VGJW36MK0FIdcvrioGeqrP9M9zDZ4ZMi00iHbzU=;
        b=Pc9ZuTVFaVMuQiyIGxEu5sbGljnuw6Vc9hK8jpGr1F/NEbUVvMghqhiSf8nPo4+gZk
         BkQsu4+urco1QdbTKtV72n5NQKDw8LYy/Lhwm+BH3940b+7B5yAuobKwPxelj0hh+wna
         sYiGbu2XVrnvTVo9uBh9Lc9Nap2ed+RLwv4Yv0Am8H6BCr4mvqcsfcSKaix+BtoCyv08
         z16/XFQDRqZf27qAdhaL9/P7EFV13WsVJTethbqPkqlt7zlA/3IXCK7ElEwN9Vw/86aM
         PkgEEPUjP634qPLAM3zycvWlm2ovavjQiKP2yKCWXJR0P07HjZBo3BQaN5cv1fNNaXEK
         9Aww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747570932; x=1748175732;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=tGw/VGJW36MK0FIdcvrioGeqrP9M9zDZ4ZMi00iHbzU=;
        b=f1+QS9op/C6PFc74/HbW1wz2Fp28WHdrvzPbvR69gcH1VoDBS3vtLVVB+C/Cm1PuL9
         Bh/IsPlHuUbEG6svbeHzOurKHxl8zLvL2f4gzmuEJ3MXLpkOlM5EQM1QfsqNEYs/4m6j
         xjxNPVSgjPnrBp3fXjsRcRieXHZla5D0MuLso9z2lwOCA5qz5POsQCW5GnI29q3MDJkB
         gEaLzk+u7WPm8Dzn0eDUtJQZeT4qcv89PBAWbOVEJukpFzd97+6EOtM9vuh/K31NfuZ6
         K/JEq3dnbgtWD16aS7rBCiPwtnGezWMAvFBR+cLIorFz4eGDePVKI005HpNBpAUSOclR
         M82w==
X-Forwarded-Encrypted: i=1; AJvYcCWwVTq3BWYPrKIyNPR3XeCJta3qa7xgvBQPDs1AVrnuFO++VPCiFhufPzoyJSZNplkdGVfdYU6ym5k=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+1a12SFgYwlcQnhalz3Fke2t7ICiYZdLxMtWnHA9O9CzkhEST
	6VwFf4K9nobLmhU2fPKSvBgTVk4fg/2tAn2BZNeEoqPKySagmE2o7Va1c1Vyb9Ty8g==
X-Gm-Gg: ASbGnctqRXMCX/9nUbjx8kzf42TyYB2m2CR2Oi30mksEHYtEb7iOXeDyU44O5MJOOK0
	q0FNa0mL2T7T/uFkZ4C+UshRD6KklB6xKtiCVEmmKl2XavBtypw8/SSLzy13aWUlAQ4VD3wYIpD
	WBpDRrgs5gH8Wy99UvOk3YiMze1VQI+0zI5OHL1dzooc7XvZ36NkWrbHxvHGAUUi9O2datzwl5P
	vxJdThcQe78ZF7gL6ITsaKiPiLEldDTv0VZ/JeNxnR8hRCPQhXTtw1gPfveGYmCdM4VHGG1aM+M
	+HXkO/Q/5tBM4w4YcTWafNJhQoK3R9raa98fQ742JK9v+jyGYq8COAIO9p+tHfEEbTo9iblFmgs
	Ve1gCCvcofIJMHYvKMt6Ov3R+
X-Google-Smtp-Source: AGHT+IFo3JqDCEsob3zzI8Ku7HrchXncLl/NgpoXrLwULONmnkkao8LUjk99E6VtWUM41t0/A8kdIQ==
X-Received: by 2002:a17:907:7b97:b0:ad2:39a9:f1b8 with SMTP id a640c23a62f3a-ad536f3867fmr869897966b.57.1747570931804;
        Sun, 18 May 2025 05:22:11 -0700 (PDT)
Message-ID: <9e9882d3-fae7-48ca-bb8d-071ffe2f4a21@suse.com>
Date: Sun, 18 May 2025 14:22:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/5] livepatch: Verify livepatch signatures
To: Ross Lagerwall 
Cc: Jennifer Herbert ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20250515093822.659916-1-ross.lagerwall@citrix.com>
 <20250515093822.659916-6-ross.lagerwall@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250515093822.659916-6-ross.lagerwall@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.05.2025 11:38, Ross Lagerwall wrote:
> @@ -79,6 +80,9 @@ static DEFINE_PER_CPU(struct tasklet, livepatch_tasklet);
>  static struct rsa_public_key builtin_payload_key;
>  #endif
>  
> +static int check_signature(const struct livepatch_elf *elf, void *raw,
> +                           size_t size);

I think it would be nice if this forward decl was avoided. Which looks to
be feasible if you moved the definition further up.

> @@ -1202,6 +1208,109 @@ static int load_payload_data(struct payload *payload, void *raw, size_t len)
>      return rc;
>  }
>  
> +#ifdef CONFIG_PAYLOAD_VERIFY
> +#define MAX_SIG_NOTE_SIZE 1024
> +
> +static int check_rsa_sha256_signature(void *data, size_t datalen,
> +                                      void *sig, uint32_t siglen)
> +{
> +    struct sha2_256_state hash;
> +    MPI s;
> +    int rc;
> +
> +    s = mpi_read_raw_data(sig, siglen);
> +    if ( !s )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH "Failed to mpi_read_raw_data\n");
> +        return -ENOMEM;
> +    }
> +
> +    sha2_256_init(&hash);
> +    sha2_256_update(&hash, data, datalen);
> +
> +    rc = rsa_sha256_verify(&builtin_payload_key, &hash, s);
> +    if ( rc )
> +        printk(XENLOG_ERR LIVEPATCH "rsa_sha256_verify failed: %d\n", rc);
> +
> +    mpi_free(s);
> +
> +    return rc;
> +}
> +
> +static int check_signature(const struct livepatch_elf *elf, void *raw,
> +                           size_t size)
> +{
> +    static const char notename[] = "Xen";
> +    void *sig;
> +    livepatch_elf_note note;
> +    int rc;
> +
> +    rc = livepatch_elf_note_by_names(elf, ELF_XEN_SIGNATURE, notename, -1,
> +                                     ¬e);
> +    if ( rc )
> +    {
> +        dprintk(XENLOG_DEBUG, LIVEPATCH "%s: Signature not present\n",
> +                elf->name);
> +        return rc;
> +    }
> +
> +    /* We expect only one signature, find a second is an error! */
> +    rc = livepatch_elf_next_note_by_name(notename, -1, ¬e);
> +    if ( rc != -ENOENT )
> +    {
> +        if ( rc )
> +        {
> +            printk(XENLOG_ERR LIVEPATCH
> +                   "Error while checking for notes! err = %d\n", rc);
> +            return rc;
> +        }
> +        else
> +        {
> +            printk(XENLOG_ERR LIVEPATCH
> +                   "Error, found second signature note! There can be only one!\n");
> +            return -EINVAL;
> +        }
> +    }
> +
> +    if ( SIGNATURE_VERSION(note.type) != LIVEPATCH_SIGNATURE_VERSION ||
> +         SIGNATURE_ALGORITHM(note.type) != SIGNATURE_ALGORITHM_RSA ||
> +         SIGNATURE_HASH(note.type) != SIGNATURE_HASH_SHA256 )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH
> +               "Unsupported signature type: v:%u, a:%u, h:%u\n",
> +               SIGNATURE_VERSION(note.type), SIGNATURE_ALGORITHM(note.type),
> +               SIGNATURE_HASH(note.type));
> +        return -EINVAL;
> +    }
> +
> +    if ( note.size == 0 || note.size >= MAX_SIG_NOTE_SIZE )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH "Invalid signature note size: %u\n",
> +               note.size);
> +        return -EINVAL;
> +    }
> +
> +    sig = xmalloc_bytes(note.size);
> +    if ( !sig )
> +        return -ENOMEM;
> +
> +    memcpy(sig, note.data, note.size);
> +
> +    /* Remove signature from data, as can't be verified with it. */
> +    memset((void *)note.data, 0, note.size);
> +    rc = check_rsa_sha256_signature(raw, size, sig, note.size);
> +
> +    xfree(sig);
> +    return rc;
> +}
> +#else
> +static int check_signature(const struct livepatch_elf *elf, void *raw,
> +                           size_t size)

As indicated before, I also think it would be nice if this redundant
function header was eliminated, but changing the #if / #else / #endif
placement.

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 14:20:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 14:20:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989218.1373451 (Exim 4.92)
	(envelope-from )
	id 1uGesV-0000m1-7D; Sun, 18 May 2025 14:20:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989218.1373451; Sun, 18 May 2025 14:20: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 1uGesV-0000lu-3e; Sun, 18 May 2025 14:20:35 +0000
Received: by outflank-mailman (input) for mailman id 989218;
 Sun, 18 May 2025 14:20:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGesU-0000lY-02
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 14:20:34 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41092cc8-33f3-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 16:20:31 +0200 (CEST)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a0be50048eso3533617f8f.0
 for ; Sun, 18 May 2025 07:20:31 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a364d2636bsm6675954f8f.99.2025.05.18.07.20.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 07:20:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 41092cc8-33f3-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747578030; x=1748182830; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=9y0PvmsQQfI9ODkztL3z9LNslCFi7d1NvdlKP1VGv+4=;
        b=gfPI7dyoDSYTTe/7WifZ/vMNhVfAs4XvYEIePOhWCOSiK3LvwOILwNFbfUYrp0orq8
         Q+IGXUfOHFtO2xmHTpt/AYnvT9NcP8awo9AHISnu9b9szEn+9UMFyfmxTaJi01VmrnUX
         RJu0UhbXY7ixjytvxc991W0G+HtA7XlpAks606V1ndIpqQqvR3deIs++7cul3htehmnJ
         vsOn2Uj8RIX4HuLbFa0rAOrhjDiaqQhsizfgtKChe0QcEBWajGwYzvhom1yKlvYNLRFI
         yTb/Y/FNS1aeHvWyxecxkg29TlquakieuuZDDDTxK38di+XiPgnvRF17sDvSRldncikD
         S8dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747578030; x=1748182830;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=9y0PvmsQQfI9ODkztL3z9LNslCFi7d1NvdlKP1VGv+4=;
        b=uJU6OhmkiXc6xeMwl6zgRp8ATHWGEl67GOeIAU6Qk16/3Vkw80r16RKLLjnOWB8ZwO
         F8+1pmbRZst008u9JK/heaozxepfoklVqRUf6Y9KMjIxZ0bVFpUbnZ/o6L4brmBh8Wnw
         hRtynC+JME5MD9tfgOpyXarCJKVYNDrZjJ2oOu2Ve1SPlphhsrUpzVGaJjN+VsGo4s9d
         SGsBGrIOyidBF0KS97hvVnEyDYhPAIUa/+cNhLEzsdHeoC6esknrTW3o/VFUm6gn/r4H
         GQcW4HfyxuIFHaTSvIU+kvXeHpFtnUOepcMZjTgKfbecHnaNweWYIK/TahvqsuMsIIJa
         mu0w==
X-Forwarded-Encrypted: i=1; AJvYcCVHMulDrRiw29YAVAGHz/SfJ4TAHgVrSD3qer3HRpP4xyCeHbtCwwIAKWFq6RXq7D80TZVS4Sv2ARc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzmvdqCTEaygT1ySWFK9YAbEA0WtiKgZAeQArvDK5aLELsKQjls
	nv62B6Eg8EmeMWQaPPBT9Rqq3l//a9FHyrYcx/wFT9RxkWozpxhegUlpvoxbOBxIYw==
X-Gm-Gg: ASbGncvNDT54Gp3Ev9GZClzk4vq0ASXcI3LOMErBtljSsSK8vzFJFNl0gwUAb20S8vS
	4z5V7MVJ/FRBiCZD7w/9V7lUvx8vGDiys+yatbcwPeXNc/Xzdx7JEk+HNlGgHEu8hpnmoU68SRk
	tJrOl9ML3KQydCM2+aHxv0fcWpwv6HgNwR/2wHz7YsyLOW+bdYttePv9MPKHG22rDY9VTD2We+P
	bredVkZNxHo8DxfQarh4NFQ0ORSgFnzliTF8rzhY0uTRp/vw/WrnjsbOlOE41+4H11iipWMU8cZ
	agbJpv4bn9VVuu4KSkMgx3B+Qol5e4aoaZEIoMB3YePB1wn79eFuWzjZ3NHlMATtyxr5SnhbIH1
	aZsR9Y8/ops6UDQDNb5e+7JEj
X-Google-Smtp-Source: AGHT+IHGBM64HPLuwhmnThyP7McwWyEV4mT7yOvDKudA72LJ2gHv42Z4qfx3XetDtXtqHIepVHa2kw==
X-Received: by 2002:a05:6000:2485:b0:3a3:621a:d3c4 with SMTP id ffacd0b85a97d-3a3621ad510mr6580495f8f.15.1747578030595;
        Sun, 18 May 2025 07:20:30 -0700 (PDT)
Message-ID: 
Date: Sun, 18 May 2025 16:20:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
To: Jiqian Chen , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
Cc: Huang Rui , xen-devel@lists.xenproject.org
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-4-Jiqian.Chen@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250509090542.2199676-4-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 11:05, Jiqian Chen wrote:
> @@ -827,6 +827,34 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>                                                   PCI_STATUS_RSVDZ_MASK);
>  }
>  
> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
> +{
> +    unsigned int pos = PCI_CFG_SPACE_SIZE, ttl = 480;

The ttl value exists (in the function you took it from) to make sure
the loop below eventually ends. That is, to be able to kind of
gracefully deal with loops in the linked list. Such loops, however,
would ...

> +    if ( !is_hardware_domain(pdev->domain) )
> +        /* Extended capabilities read as zero, write ignore for guest */
> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
> +                                 pos, 4, (void *)0);
> +
> +    while ( pos >= PCI_CFG_SPACE_SIZE && ttl-- )
> +    {
> +        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
> +        int rc;
> +
> +        if ( !header )
> +            return 0;
> +
> +        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
> +                               pos, 4, (void *)(uintptr_t)header);

... mean we may invoke this twice for the same capability. Such
a secondary invocation would fail with -EEXIST, causing device init
to fail altogether. Which is kind of against our aim of exposing
(in a controlled manner) as much of the PCI hardware as possible.

Imo we ought to be using a bitmap to detect the situation earlier
and hence to be able to avoid redundant register addition. Thoughts?

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 14:34:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 14:34:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989225.1373460 (Exim 4.92)
	(envelope-from )
	id 1uGf5i-0002UV-4u; Sun, 18 May 2025 14:34:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989225.1373460; Sun, 18 May 2025 14:34:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGf5i-0002UO-25; Sun, 18 May 2025 14:34:14 +0000
Received: by outflank-mailman (input) for mailman id 989225;
 Sun, 18 May 2025 14:34:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGf5g-0002UG-QW
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 14:34:12 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 28cd1358-33f5-11f0-9eb8-5ba50f476ded;
 Sun, 18 May 2025 16:34:09 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a361b8a66cso1208816f8f.2
 for ; Sun, 18 May 2025 07:34:09 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca888afsm9683908f8f.64.2025.05.18.07.34.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 07: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" 
X-Inumbo-ID: 28cd1358-33f5-11f0-9eb8-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747578849; x=1748183649; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=YCdUb2w5Rpp8XYVS99BXt7Tk1WRjOdMZ1zjppMB850g=;
        b=SFRFyP0nEHOOBQ3NhNYO2UZEfRqDQYLxd6bvwalGUlLOIzP8nZLqFkNrUri1ZbGVaH
         /tgfwiR4MDbXnC3tdAUE6s47ksjVymfwWZSv5V8riAYgrCTO4ssQ+4LijobVyutNF3fj
         7es+38LKcpaYiXypER73tRW4nmVmM4UR8+yfh1a8dY+jvA9tFTra8Sh+NX0CtZHbeOP9
         iGXhi5GuO2BgO9gBvK+7wzEu9ipWnCUfBjmZznJO8GqikEc1b0jegxVAVe7tggCra79a
         7/OUEv36ZKbDO0QBHZbmFegunEc5TyPNtIHhtYRYuezqmtWphwlu5L9O3Rhbp4qywwOl
         cXEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747578849; x=1748183649;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YCdUb2w5Rpp8XYVS99BXt7Tk1WRjOdMZ1zjppMB850g=;
        b=K6q+U6qOCq8AhA46hMvbXlRxt8YfQFPRt0AY2BX93ikQEVEzDveY8/1WDn9o0v4+uW
         kM8tE+c7BJ3ZZLW3/UDh7+i868i4s6d9VT0nizxWBeerdBV5eq/dKliuJjarl1/9jsjv
         9ZRYyFSumUEcxAke0DBFypj+UnQNMGLcd0pDY+3w+SqrG/6znvDTdomW0OJXsjC6QoAQ
         BH1dmKrHROn2IYaJKp/leVULp8rE2uJqZ++XeyMNi+ro9Er9Te2hHjXKHl6PYLszeBPz
         hr/30H7HKkFhqwenSft+NEPHrrO1eywgQ7AIFW+jzxbnO6ppOg/22y4oy+Ki0qbts87I
         uUqQ==
X-Forwarded-Encrypted: i=1; AJvYcCXvEz5J/f/+47mfE8queTkUxkPPBVPtQdNAaG6K7DozDJh7eSq1F3ckheGa75HE+cKGrnu+QdLzsFY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyKKX3qWXy+x50i1VQRGSIrbU6/Ih4gNZYrbeEfHdeYU+tNylsh
	zHHB2NGwigSMXyFytrFKHvepRFGguSKgCNNktvuOW+nMAgdaYbzkNTzV40rKvwTz7Q==
X-Gm-Gg: ASbGncuRxmR+gzkr2GDqrsGWRSyTw8/EJ3UaQLLiVUawpTxBe9kJbqjYVh2rff8vxl/
	KgnojZIVBaO6uY4Ua50LDHHfwwqPE1QLdRD8L8qnF8YVNmuv2ga3N7VIiyucyha13vZzzANQWbK
	dXNUWkXrrl6KieUCMMeFpaDsmA6KEP74bZmnsZhprC/8uvJ/R0PLgGV5NOxj2sK+0Q6slxK8TvG
	yJsmvYb9FLWD2Q5UsVd2/Je/6bFcoOYBOYtWECVxnSGW+hoq6JvLm8YLZoKcRphxR2I1sDdttxx
	Mp/OYlQMuen2L+g89NRasaqwg6UwEG5jc7kszNOwN5Q/Vy15v83SpTl2HUpqvnMYWhtg45e9uUJ
	0jpBlTY5UwaaxAdAZX4LbHqbZ
X-Google-Smtp-Source: AGHT+IFEIFmXoVPwxjgdMLTiUK6YaxXDGlfNpGIPcX5MLULK3ghOKEQYDDUyz1Cs7hzQ4lsJN8Cu+g==
X-Received: by 2002:a05:6000:2203:b0:3a1:fc5c:f8f9 with SMTP id ffacd0b85a97d-3a35c83a219mr9183769f8f.16.1747578848898;
        Sun, 18 May 2025 07:34:08 -0700 (PDT)
Message-ID: <0a6f40a9-a0ea-4652-8692-acfcf873463a@suse.com>
Date: Sun, 18 May 2025 16:34:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 04/10] vpci: Refactor REGISTER_VPCI_INIT
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-5-Jiqian.Chen@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250509090542.2199676-5-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 11:05, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -270,7 +270,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
>  
>      return 0;
>  }
> -REGISTER_VPCI_INIT(init_msi, VPCI_PRIORITY_LOW);
> +REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSI, init_msi, NULL);

To keep identifier length bounded, how about REGISTER_VPCI_CAP() here
and ...

> --- a/xen/drivers/vpci/rebar.c
> +++ b/xen/drivers/vpci/rebar.c
> @@ -118,7 +118,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
>  
>      return 0;
>  }
> -REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
> +REGISTER_VPCI_EXTENDED_CAP(PCI_EXT_CAP_ID_REBAR, init_rebar, NULL);

... and REGISTER_VPCI_EXTCAP() here?

> @@ -83,6 +83,35 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
>  
>  #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>  
> +static int vpci_init_capabilities(struct pci_dev *pdev)
> +{
> +    for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
> +    {
> +        const vpci_capability_t *capability = __start_vpci_array[i];
> +        const unsigned int cap = capability->id;
> +        const bool is_ext = capability->is_ext;
> +        unsigned int pos;
> +        int rc;
> +
> +        if ( !is_hardware_domain(pdev->domain) && is_ext )
> +            continue;

Fold this into ...

> +        if ( !is_ext )
> +            pos = pci_find_cap_offset(pdev->sbdf, cap);
> +        else
> +            pos = pci_find_ext_capability(pdev->sbdf, cap);

... this by adding a middle "else if()"?

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 14:44:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 14:44:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989238.1373471 (Exim 4.92)
	(envelope-from )
	id 1uGfFj-0004Dh-6q; Sun, 18 May 2025 14:44:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989238.1373471; Sun, 18 May 2025 14: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 1uGfFj-0004Da-35; Sun, 18 May 2025 14:44:35 +0000
Received: by outflank-mailman (input) for mailman id 989238;
 Sun, 18 May 2025 14:44:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGfFh-0004DE-Ts
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 14:44:33 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9ba69a39-33f6-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 16:44:31 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-601ab204085so1524534a12.1
 for ; Sun, 18 May 2025 07:44:31 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502742sm4411497a12.28.2025.05.18.07.44.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 07:44: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" 
X-Inumbo-ID: 9ba69a39-33f6-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747579471; x=1748184271; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=jmx9eHqBzJfkMWv/xrYB1jNarUNibcAJ2ihHyuYo4tM=;
        b=GCQ8+M1uRFF7U0900UmwOJCFnxbQ9L28F7IAZTk7AD+/VNcM5s4PRflJbjjmQI0qdQ
         4b9dO4yzRWvq8ZuDBONEdmE4KQgl1+yX/SpMCWLnacI50f0gvLhCDUU7rRf5cdRrA5xF
         k1b6GbZA29ylyJw3+beuxAMq8tWdtl4u+PoV9xq1FN5MXoWUfzBXLosbt+lWDKROYyVd
         8XElFh0dpzbakAu+C0JDEV7KqyvUSYF8/yhnHCCzpkrGf3ba/LjeS0e8xtWRVuccLEsp
         kwN7R9zXtLVbkuf7sMy8pH6W9a1IPq/lgagXZ1751kBTL99cgaj57YfTJfSyhYHtbXBi
         2aTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747579471; x=1748184271;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jmx9eHqBzJfkMWv/xrYB1jNarUNibcAJ2ihHyuYo4tM=;
        b=dCfuAw16ee150wOKUP12Pjne2onHsAdZj7QzwKUV/XOjK+UsU3PHfJVwRt+5v2Ss0B
         XPKnZNnTHxrLiYNXGHwFWyE7MNEjShU809O1Yp2AhO6A3MX14rXCn7o99k43NNYFxRf2
         MoI7zuykaQb7lKwsT7yRtGnZqKp1Y0BSnYfP+9Um+v2+JfEpscMzcqxMzQkcx8ZW79t1
         L1tZodYcYkbYPPKJW0v7zz0Cfq8BusE+n18lEGdSHQDcD8bdWWUYhsxXk0Z5tPVVOJIA
         t4TC47q13S38QUnH1NDsiZL8K4CbqiKqHTIHkTNoZ95kx4NvPMtOdtKRIpJr4d6HYOLJ
         iesA==
X-Forwarded-Encrypted: i=1; AJvYcCV4lDggA8epcRjLg7Y4yide6V2bjBdbWUQg8G8KAExyqX8cxy1H6XwdQfR6FIpKn0hYuIEpkVJ0z2E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzdnbWVy0mkMHeetBk2j+7pRyvWq4PxK4RmA+XZnv/aDJouZbjv
	vchZN0qESCpFHt06jjdj1qWUa0hrhpzagipIc/SsEZhMiKnQo0NIvrCv34mEnZu+/g==
X-Gm-Gg: ASbGncsosPvEXQMZADWflTgBoqH4u+6G4dR+NbTr4Xd+XR0dCVdPOQe+iKXCIfz0LbL
	8Y1ZCLReEMc/GIG2AjNR+Y6/CvkUQ+BwZ2KnlY9qWnQ9VC851otzaWHI2vQ71tIXojhLas1BP1V
	SNq0jEJ2qSm5wAyl9JEedHjRx5PRm+YTCfJ97jIXj5qQd9JVM6GRAq/0LR5qRrQVjMzVo44OHeF
	Jtrt+OuPlPQWOpUGXOxULt2jl+h3MNB0cikdXoAxLEiE2qiXuHH4waBe8X/C1OuJs/UoU0UXmwX
	RTtS9xuzOMkUnGn09QPEDlfPUwbx8/1KsZSlutUHZ2cHrhlrRLNTvysdW87pAvAZTo2NS7odTnw
	AJ88EVpmxOFNQ/AQRyWbnLdWX
X-Google-Smtp-Source: AGHT+IGXMVzgPMKBTtXsKyiA4dulSIokIKe9XzJ1/BtnTVTJoaL8s/cksIt+mEGoxzt/ywfHv8u6pA==
X-Received: by 2002:a17:907:9690:b0:ad5:5086:c2c7 with SMTP id a640c23a62f3a-ad55086cfa6mr490564666b.15.1747579471083;
        Sun, 18 May 2025 07:44:31 -0700 (PDT)
Message-ID: <76d58a17-90aa-46eb-bbe8-c6d9400c489f@suse.com>
Date: Sun, 18 May 2025 16:44:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 05/10] vpci: Hide legacy capability when it fails to
 initialize
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-6-Jiqian.Chen@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250509090542.2199676-6-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 11:05, Jiqian Chen wrote:
> @@ -83,6 +99,100 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
>  
>  #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>  
> +static struct vpci_register *vpci_get_register(struct vpci *vpci,
> +                                               unsigned int offset,
> +                                               unsigned int size)
> +{
> +    const struct vpci_register r = { .offset = offset, .size = size };
> +    struct vpci_register *rm;
> +
> +    ASSERT(spin_is_locked(&vpci->lock));
> +    list_for_each_entry ( rm, &vpci->handlers, node )
> +    {
> +        int cmp = vpci_register_cmp(&r, rm);
> +
> +        if ( !cmp && rm->offset == offset && rm->size == size )

What's the point of using vpci_register_cmp() when you need to do
the "exact match" check here anyway?

> +static int vpci_capability_mask(struct pci_dev *pdev, unsigned int cap)

What's the word "mask" indicating here? The function doesn't return any
mask afaics. Do you perhaps mean "hide"?

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 14:47:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 14:47:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989249.1373482 (Exim 4.92)
	(envelope-from )
	id 1uGfIg-0004mQ-Jt; Sun, 18 May 2025 14:47:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989249.1373482; Sun, 18 May 2025 14: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 1uGfIg-0004mJ-Fv; Sun, 18 May 2025 14:47:38 +0000
Received: by outflank-mailman (input) for mailman id 989249;
 Sun, 18 May 2025 14:47:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGfIe-0004mD-FU
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 14:47:36 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 088ea8cc-33f7-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 16:47:34 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-601afe51106so1075005a12.1
 for ; Sun, 18 May 2025 07:47:34 -0700 (PDT)
Received: from [172.18.118.114] (ip-185-104-138-68.ptr.icomera.net.
 [185.104.138.68]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d501b60sm4495446a12.18.2025.05.18.07.47.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 07:47: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" 
X-Inumbo-ID: 088ea8cc-33f7-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747579654; x=1748184454; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=oa00Bkswp8uBCOnXui7xpUjTb/mRh0fE2T9ZTK73Yz8=;
        b=RrJ59aEi1QNg52cYLYAdZ8m8BSFluJk0HL/bn8y7kUWwyQyMOyCjAs9ZGIkTx7q7vt
         zyUeYcKnKVsZeD0rn+IV2f/J8x73w3F7UpxeF0uKNIXsNQKpom83EoylJlg9B9wnlWb9
         WshzxVcd44aY5/dvoqLgXuoaWeAVpbiPDFzI71nUtoh/B4GGZYX5jqijJJrgVLUptox6
         gyX2ikTWq9P0vLv2NLQEFP5id5y2fKssjg/Wg4oRCPWmMQsxhpaDfgRMNwzT6dfJLU8X
         Z1BSSOB+d5OWNTuUxj4dOg4DPGljSsI+Nz0ryQWUxW9qajmPhdMJ0XVwEF8rfbrU6rU7
         5Sfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747579654; x=1748184454;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=oa00Bkswp8uBCOnXui7xpUjTb/mRh0fE2T9ZTK73Yz8=;
        b=tB8jClmXi4ApY7KxW/yteQj2oMyNhUa1n6YwajJQi2YCGTopaenup2q2NdSEmRU9KZ
         fBdy0Zav+umXbW0aXcnNZiCfLT5ZNPFwl2ZHZ/IqMOW0Rx35hUVBbc8EBExBIhubFkuP
         1mDpzperpST/LoxDVPXk60d6mtXEOQBeoof/ADJ8adEb0zveceGSJZuFyDKeXDfeEREd
         08j8rTqjBpjqFxZGI2ma7HMvTJd3MX1igjvw32zqLyXj9kg0wW6ApiDfdTk00/Jse1wm
         /ivHLSeQduq5XHxSVCFfpmIlrIPKbEN2Sam/RemhyGbH2S49kKdFLwHkLymHkRiGRbyf
         LtVQ==
X-Forwarded-Encrypted: i=1; AJvYcCVUrydwVnqugZFpNaRjVVV/CBmqjswurdAgxXkX44yloEJq45sW4j2ROa+BMFWL4nLu33QCW17uISg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx3EYrhspkUca69AaLEMHh5EHIik6l1TLhctgssaGJ5IReGpT4h
	eYro/XaxMNI3wlwJKnMH+VKY4zwv45Ayua16ha97h01YEeF673EkjnSKwrl+cWLBHw==
X-Gm-Gg: ASbGncvfmw64e65wlQWO9ZHTSjrCNv7vZGKDxkIQHzVCILMaZA/p62oYWuu2KSZSMov
	2v/KyKzI1cof0K9fSHAxoA3OPSqE+BCKEydXgzHwbQy+/PaHGj0L6DamlFRtfx60BQzmeqptd4A
	rN518j5XCdYDGQEuQZcPaIkiLwCYjMihGKbF5gIH50yPKddU/hGT6uqD0EIjHVKd9Y7pl/x8u4D
	g2cRn0qZPNLkFafPogAu97nZeTqcBDUvB5Qh7fA+RqyvH0y6X/1JUPhAJEXRs/n8vOGMzA5r213
	0b5BhjPX051Nm5gWThKLhZxHow5NLX+GW0C1PbetcH+X19X1Vj3iYcMshMnigPgcHpMfRZIxOQF
	AvBLBTb2mHULr4joAYOWyIZNp
X-Google-Smtp-Source: AGHT+IHpV3kVk2AZoWgkkzjL2lRZIKallXk1oBDfn6vKNbQk2vFcD7uG/9iYdT44cx6XEmNcULyxaw==
X-Received: by 2002:a05:6402:27d1:b0:5fc:3e6e:f048 with SMTP id 4fb4d7f45d1cf-6007e829240mr7776214a12.0.1747579653818;
        Sun, 18 May 2025 07:47:33 -0700 (PDT)
Message-ID: <48c71b8b-2b59-41aa-ad02-b237d53f1d6d@suse.com>
Date: Sun, 18 May 2025 16:47:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 06/10] vpci: Hide extended capability when it fails to
 initialize
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-7-Jiqian.Chen@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250509090542.2199676-7-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 11:05, Jiqian Chen wrote:
> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -448,7 +448,10 @@
>  /* Extended Capabilities (PCI-X 2.0 and Express) */
>  #define PCI_EXT_CAP_ID(header)		((header) & 0x0000ffff)
>  #define PCI_EXT_CAP_VER(header)		(((header) >> 16) & 0xf)
> -#define PCI_EXT_CAP_NEXT(header)	(((header) >> 20) & 0xffc)
> +#define PCI_EXT_CAP_NEXT_MASK		0xFFF00000U
> +/* Bottom two bits of next capability position are reserved. */
> +#define PCI_EXT_CAP_NEXT(header) \
> +    (MASK_EXTR(header, PCI_EXT_CAP_NEXT_MASK) & 0xFFCU)

Please can the hex digits all be / remain to be lower case, with just
the U suffixes be upper case?

Jan


From xen-devel-bounces@lists.xenproject.org Sun May 18 15:37:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 15:37:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989270.1373490 (Exim 4.92)
	(envelope-from )
	id 1uGg4s-0002eN-TO; Sun, 18 May 2025 15:37:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989270.1373490; Sun, 18 May 2025 15:37:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGg4s-0002eG-Qo; Sun, 18 May 2025 15:37:26 +0000
Received: by outflank-mailman (input) for mailman id 989270;
 Sun, 18 May 2025 15:37:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGg4q-0002eA-A1
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 15:37:24 +0000
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de
 [81.169.146.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fc9a4c98-33fd-11f0-9ffb-bf95429c2676;
 Sun, 18 May 2025 17:37:21 +0200 (CEST)
Received: from dmzmail.linux.bogus by smtp.strato.de (RZmta 51.3.0 DYNA|AUTH)
 with ESMTPSA id 6293ac14IFbJTns
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
 (Client did not present a certificate)
 for ;
 Sun, 18 May 2025 17:37:19 +0200 (CEST)
Received: from [192.168.5.100] (p508196e9.dip0.t-ipconnect.de [80.129.150.233])
 (authenticated bits=0)
 by dmzmail.linux.bogus (8.17.1.9/8.17.1.9/Debian-2+deb12u2) with ESMTPSA id
 54IFbHq4241291
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT);
 Sun, 18 May 2025 17:37:17 +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" 
X-Inumbo-ID: fc9a4c98-33fd-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; t=1747582639; cv=none;
    d=strato.com; s=strato-dkim-0002;
    b=qW8INH6a9Fy/q9DFE7qadpbd0EgG62cfRDeoO77c8FNUCYF0/OJ5FK3NtSUHTBChvQ
    BPFfK+9KE+2YvPXCSfG+Z+MBWck4Gu8AK9Tm5QH78bMF1HZJaBqSabjYQSFkzdm4/y/e
    NX0tho1AzgGsXApLRbx6uiDH87FSwTFiB2SKoy33sLFjwXiwU2Ll9P9NhKPeTeJKX/jg
    kmvF4XY26E8cS990ouvdcpRH3YNJMFgo8cgN194QXd7ikBsYm112ra9govg8vwtFEAYn
    kg27WllKFnG17udyMek20hwT5dsUDi26+rcUUXfaLve9MR+0M5/R3CBQEpOUlcqn+xBW
    lFFQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1747582639;
    s=strato-dkim-0002; d=strato.com;
    h=In-Reply-To:From:Cc:References:To:Subject:Reply-To:Date:Message-ID:
    Cc:Date:From:Subject:Sender;
    bh=TxBzSHtsc9lclNxdJck3wIIncXDkvgK/dr0Fa6blPnI=;
    b=VCBjLAmK2OTbhNfR1VWLdJqQ9VzDG/GJIIYD6yWtKEo3tV8Nqw3x/7RC2WRaH3p2Pu
    WnT1UkmLihiu7amxBIv1SSgOcDezN10LWs1MChEU2rPLLmQ+3LLIJMpl6HnirXYZJlnC
    t+9/TqHLK1bmwpaltJC4KDbag/G9ZM5yXsitFc7ECqb2zbI8DU593iUVJNoPMXxy7EIm
    dxv2pOuaALFJZV1/HYWzHcOISEklFCu1hzEQafUxWE1Tx0itxIqj8iEINZj6TZA8EZJj
    uwAAbf/6C0c+oZXMO/u98rQdb6PYbxhIcfKdwosS2F6iZku7v974nL9Iv3CoQai1rSxk
    ljow==
ARC-Authentication-Results: i=1; strato.com;
    arc=none;
    dkim=none
X-RZG-CLASS-ID: mo00
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1747582639;
    s=strato-dkim-0002; d=a-greve.de;
    h=In-Reply-To:From:Cc:References:To:Subject:Reply-To:Date:Message-ID:
    Cc:Date:From:Subject:Sender;
    bh=TxBzSHtsc9lclNxdJck3wIIncXDkvgK/dr0Fa6blPnI=;
    b=i825Os2rWRWe0HYuMVgkpDuXQqWS58WE+5cGj4RHBYMoukKb4Qu89nzClcRW75sd8E
    iHPBe8uGBVI61J4gKJBzkNf9CK/+gpIE62BWgm5r0fYAbqzAcgOfM7IOx7kdQB3D++gG
    VRpfjiMO59ZwsfIlEQXvR9EuCV+YPiGTLiA2IHovT8mYIJ4jDow2xqRAK+o46WvngoVM
    1SIOD6nf3MullIuPMSTpHRRvIB7F1MueCRpG01nnkBZvB+NUpeblQrQ7e/jgQjrKE39Z
    qaBjVNDRh5kjH4LDrEHZvznDsKcjdbjpu8za+OxGFfHKN+4HFjpe+rVdTQftJmgpd+Tc
    lzxA==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1747582639;
    s=strato-dkim-0003; d=a-greve.de;
    h=In-Reply-To:From:Cc:References:To:Subject:Reply-To:Date:Message-ID:
    Cc:Date:From:Subject:Sender;
    bh=TxBzSHtsc9lclNxdJck3wIIncXDkvgK/dr0Fa6blPnI=;
    b=t1Vw6PDOnyvkUckjI3fzSjuANyckig6Kh9GZvQav/lMp2HSHqg0CinLnEOGgd+Iw9w
    UW4gb4Gxb1HfhvuJozBA==
X-RZG-AUTH: ":I3kQck+hdfi/FoX876SYvGxtQu+BXCDuSQ9UENFBFhpuMtcK2yjIjEY8XWHyeFlVfYF7"
Content-Type: multipart/alternative;
 boundary="------------lmiZ0fl3KS8jPP4VeNF5ri02"
Message-ID: <93625976-e8af-4c39-90fb-45c926d420fd@a-greve.de>
Date: Sun, 18 May 2025 17:37:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Reply-To: andreas.greve@a-greve.de
Subject: Re: BUG kernel 6.12.19 defautl_swiotlb_limit() returns wrong value
 for CONFIG_SWIOTLB_DYNAMIC=y effects atm only under XEN dom0
To: xen-devel@lists.xenproject.org
References: 
Content-Language: en-US
Cc: andreas.greve@a-greve.de
From: Andreas Greve 
In-Reply-To: 
Content-Transfer-Encoding: 8bit

This is a multi-part message in MIME format.
--------------lmiZ0fl3KS8jPP4VeNF5ri02
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello to all,

here is my BUG-Fix tested against kernel 6.12.19 and 6.12.28.

Signed-off-by: Andreas Greveandreas.greve@a-greve.de

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index abcf3fa63a56..742e6cbbe852 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -1654,7 +1654,16 @@ phys_addr_t default_swiotlb_base(void)
  phys_addr_t default_swiotlb_limit(void)
  {
  #ifdef CONFIG_SWIOTLB_DYNAMIC
-       return io_tlb_default_mem.phys_limit;
+       struct io_tlb_mem *mem = &io_tlb_default_mem;
+       phys_addr_t retval = mem->defpool.end;
+       struct io_tlb_pool *pool;
+       rcu_read_lock();
+       list_for_each_entry_rcu(pool, &mem->pools, node) {
+               if (pool->end > retval)
+                       retval = pool->end;
+       }
+       rcu_read_unlock();
+       return retval - 1;
  #else
         return io_tlb_default_mem.defpool.end - 1;
  #endif


--------------lmiZ0fl3KS8jPP4VeNF5ri02
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    
    Hello to all,
    
    
    here is my BUG-Fix tested against kernel 6.12.19 and 6.12.28.
    
    
    Signed-off-by: Andreas Greve andreas.greve@a-greve.de
    
    
    
    
    diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
    
      index abcf3fa63a56..742e6cbbe852 100644
    
      --- a/kernel/dma/swiotlb.c
    
      +++ b/kernel/dma/swiotlb.c
    
      @@ -1654,7 +1654,16 @@ phys_addr_t default_swiotlb_base(void)
    
       phys_addr_t default_swiotlb_limit(void)
    
       {
    
       #ifdef CONFIG_SWIOTLB_DYNAMIC
    
      -       return io_tlb_default_mem.phys_limit;
    
      +       struct io_tlb_mem *mem = &io_tlb_default_mem;
    
      +       phys_addr_t retval = mem->defpool.end;
    
      +       struct io_tlb_pool *pool;
    
      +       rcu_read_lock();
    
      +       list_for_each_entry_rcu(pool, &mem->pools, node) {
    
      +               if (pool->end > retval)
    
      +                       retval = pool->end;
    
      +       }
    
      +       rcu_read_unlock();
    
      +       return retval - 1;
    
       #else
    
              return io_tlb_default_mem.defpool.end - 1;
    
       #endif
    
    
    
    
    
  


--------------lmiZ0fl3KS8jPP4VeNF5ri02--


From xen-devel-bounces@lists.xenproject.org Sun May 18 18:36:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 18:36:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989333.1373500 (Exim 4.92)
	(envelope-from )
	id 1uGirk-0006Oo-NB; Sun, 18 May 2025 18:36:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989333.1373500; Sun, 18 May 2025 18:36: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 1uGirk-0006Oh-K9; Sun, 18 May 2025 18:36:04 +0000
Received: by outflank-mailman (input) for mailman id 989333;
 Sun, 18 May 2025 18:36:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGiri-0006OZ-SX
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 18:36:03 +0000
Received: from 5.mo576.mail-out.ovh.net (5.mo576.mail-out.ovh.net
 [46.105.43.105]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f1cf5dc8-3416-11f0-9eb8-5ba50f476ded;
 Sun, 18 May 2025 20:36:00 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.108.17.39])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4b0qJb4fyPz1lH4
 for ; Sun, 18 May 2025 18:35:59 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-srqkw (unknown [10.110.101.117])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 22F3D1FE24;
 Sun, 18 May 2025 18:35:57 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.109])
 by ghost-submission-5b5ff79f4f-srqkw with ESMTPSA
 id 7Bl6LY0oKmif/gQAmIYX7A
 (envelope-from ); Sun, 18 May 2025 18:35: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" 
X-Inumbo-ID: f1cf5dc8-3416-11f0-9eb8-5ba50f476ded
Authentication-Results:garm.ovh; auth=pass (GARM-109S0030239ee15-be38-48a1-8cc5-2fa894bc7de3,
                    6FCDE7FC3973969C7D59E240015AF9737BA2D6B5) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Sun, 18 May 2025 21:35:49 +0300
From: Sergii Dmytruk 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Lukasz Hawrylko ,
	Mateusz =?iso-8859-1?Q?M=F3wka?= ,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
Message-ID: 
References: 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Ovh-Tracer-Id: 2922554685630624924
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdefudelvdegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggugfgjsehtkeertddttddunecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepveevhfdvfedtffeiveeigffhffetvdeltdeftddukefgvdeuvdelkeffteeifeetnecuffhomhgrihhnpehinhhtvghlrdgtohhmnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrddutdelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheejiegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=hsdlVVehTPs587A8VqR0oCQI/MsgTIjwmYBXjl5EAfU=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747593359; v=1;
 b=PBE6ZI+aNDcvAsU/K2jwmm7gBozROZxDjXbCjCYY13/2Cz6/LuiQynzBbkkzV5akAGgR0GXn
 ciYw3nPOOjXu5DAu4sX1dhzLR8RKrUcGlUSaUptYiSu0eU6OtxmgLOjhbLHhV3x6b3el32EGBAb
 netdrZ8IgA5jF4Cyf+yz0OH/7JniKmYGGghMEEEBnXckeXTumhVfk3AqhhnuEjColKJnX+L2ARL
 4+17KRtd/PYa9QS0IHx35ey6LP8/83KVeEiqce6I+N32TxeBb4R/D+vd2DsiEfpnpAYvhapY1G6
 mb/a+Vyc4pJZe4qOvKMo2tYdmJMKVlhWh2/rRKRDekhJA==

On Wed, May 14, 2025 at 03:55:51PM +0100, Andrew Cooper wrote:
> Please have at least a one-liner introduction to what TXT is. Is there
> a stable URL for the TXT spec? (I can't spot an obvious one, googling
> around)

In addition to a short definition I'll add:
 * https://www.intel.com/content/www/us/en/support/articles/000025873/processors.html
 * unversioned link to Software Development Guide
 * link to that unofficial archive (marked as such) mentioned by Krystian

> > +#ifndef ASM__X86__INTEL_TXT_H
> > +#define ASM__X86__INTEL_TXT_H
>
> I realise this is what the documentation currently says, but we're just
> in the process of finalising some changes. Please make this
> X86_INTEL_TXT_H.

Will fix.

> Commit message needs to note that you're swapping NR_TXT_CONFIG_PAGES
> for NR_TXT_CONFIG_SIZE, hence the change in logic in
> tboot_protect_mem_regions().

Will clarify that.

> > +#ifndef __ASSEMBLY__
> > +
> > +/* Need to differentiate between pre- and post paging enabled. */
> > +#ifdef __EARLY_SLAUNCH__
> > +#include 
> > +#define _txt(x) _p(x)
> > +#else
> > +#include 
> > +#include    // __va()
> > +#define _txt(x) __va(x)
> > +#endif
>
> I have to admit that I'm rather suspicious of this, but I'm going to
> have to wait to see later patches before making a suggestion. (I highly
> suspect we'll want a fixmap entry).

Leaving it as is for now.

> > +/*
> > + * Always use private space as some of registers are either read-only or not
> > + * present in public space.
> > + */
> > +static inline uint64_t read_txt_reg(int reg_no)
>
> unsigned int reg

OK, for both read and write functions.

> I'd be tempted to name it simply txt_read(). I don't think the extra
> "_reg" is a helpful suffix, and it makes the APIs consistent with
> txt_reset(). But I expect others may have opinions here.

Will be renamed to txt_read() and txt_write(), seems sensible to me.

> > +static inline void write_txt_reg(int reg_no, uint64_t val)
> > +{
> > +    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
> > +    *reg = val;
> > +    /* This serves as TXT register barrier */
> > +    (void)read_txt_reg(TXTCR_ESTS);
>
> What is this barrier for?
>
> It's not for anything in the CPU side of things, because UC accesses are
> strictly ordered.
>
> I presume it's for LPC bus ordering then, but making every write be a
> write/read pair seems very expensive.

The barrier will be moved to txt_reset() as suggested by Krystian in his
reply.

> > +static inline void txt_reset(uint32_t error)
> > +{
> > +    write_txt_reg(TXTCR_ERRORCODE, error);
> > +    write_txt_reg(TXTCR_CMD_NO_SECRETS, 1);
> > +    write_txt_reg(TXTCR_CMD_UNLOCK_MEM_CONFIG, 1);
> > +    write_txt_reg(TXTCR_CMD_RESET, 1);
> > +    while (1);
>
> for ( ;; )
>  cpu_relax();
>
> please.
>
> Will the write to CMD_RESET try to initiate a platform reset, or will we
> just hang here forever?

Will mark the function as `noreturn` and use `unreachable()` instead.

The write sends a platform into a warm reboot which retains the error
code for later examination.

> > +/*
> > + * Functions to extract data from the Intel TXT Heap Memory. The layout
> > + * of the heap is as follows:
>
> This is quite horrible, but I presume this is as specified by TXT?
>
> To confirm, it's a tightly packed data structure where each of the 4
> blobs is variable size? Are there any alignment requirements on the
> table sizes? I suspect not, given the __packed attributes.

Will improve the comment to state this explicitly, including that no
particular alignment is assumed and why (as in Krystian's reply).

> > diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
> > index d5db60d335..8a573d8c79 100644
> > --- a/xen/arch/x86/tboot.c
> > +++ b/xen/arch/x86/tboot.c
> > @@ -15,6 +15,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
>
> I'll send a prep patch to fix tboot.c, but we're trying to keep includes
> sorted (for sanity of backports).
>
> ~Andrew

I've seen commits sorting includes and trying to do the same, but files
which don't have includes sorted yet often don't have any good place for
a new entry and I refrain from sorting them at the same time as I add a
new line.

Regards


From xen-devel-bounces@lists.xenproject.org Sun May 18 23:32:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 18 May 2025 23:32:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989412.1373511 (Exim 4.92)
	(envelope-from )
	id 1uGnUD-0005Zc-Gt; Sun, 18 May 2025 23:32:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989412.1373511; Sun, 18 May 2025 23:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGnUD-0005ZV-EE; Sun, 18 May 2025 23:32:05 +0000
Received: by outflank-mailman (input) for mailman id 989412;
 Sun, 18 May 2025 23:32:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGnUC-0005ZP-Aw
 for xen-devel@lists.xenproject.org; Sun, 18 May 2025 23:32:04 +0000
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com
 [2607:f8b0:4864:20::731])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c842819-3440-11f0-9ffb-bf95429c2676;
 Mon, 19 May 2025 01:32:02 +0200 (CEST)
Received: by mail-qk1-x731.google.com with SMTP id
 af79cd13be357-7c546334bdeso337756285a.2
 for ; Sun, 18 May 2025 16:32:02 -0700 (PDT)
Received: from smtpclient.apple (216-131-77-234.ord.as62651.net.
 [216.131.77.234]) by smtp.gmail.com with ESMTPSA id
 af79cd13be357-7cd468b844bsm487918085a.87.2025.05.18.16.31.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 16:32:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4c842819-3440-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747611121; x=1748215921; darn=lists.xenproject.org;
        h=to:in-reply-to:cc:references:message-id:date:subject:mime-version
         :from:content-transfer-encoding:from:to:cc:subject:date:message-id
         :reply-to;
        bh=hVouPoVCWIgL3YKIWZAl2pIL0gHViCv3WFsDhQh73eo=;
        b=kaau6G1C0/5kFLLocD8m8ktRbRt2euvIQKHFGetETDl4JaeBKyZPZWXFxx+6EaS9Hs
         fOVIxf57D+cDzmCSURs5XijVaNQcvnWMdTp23v8z8bqpKEUZSUDfM5dQnxhmL1+Csjc5
         u4MTChRHuFTyrqCIiilpuJAjMKaZqbop8cxxpu6KZouQJWi92OC0fboku4Za5K+d9rbh
         VrNeFcAZhbmZvgW44GSlZ4PchzjQr3Mcx3Eek0+CU9pt+M/P5tYxY+KX6NvvrKc541i2
         SO0kwBmh2GaAKdx9cULJkJEwbgYYOpB38ylj4C1+l0K4GUB6AHqnIr8b0qiAGR9p/XXT
         /CxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747611121; x=1748215921;
        h=to:in-reply-to:cc:references:message-id:date:subject:mime-version
         :from:content-transfer-encoding:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=hVouPoVCWIgL3YKIWZAl2pIL0gHViCv3WFsDhQh73eo=;
        b=xTI6eg4DmEOEzMn6+Bp0AENnH7UVY0ZR5sbTaJOHb3W70f5zhxXxOJ89/UVe1VAOxy
         KEgHDxvLgba6Lu4svGKQhfbjL5CTiZx3vFQUDPFGVWqBNsvIrUO2iP6ek927iW275wuz
         QiaZp2lTen0k6i9DlH+e9LH+9RlxpTwQC0tElJUR9Ik9PfKx0fag9T/MbmIiEhDXotoT
         i9U9RZICO6ccewOI9cDCZE0PS6S1vNhKPbqo6DLtTTn90v0wWUx2zGt9npCRDoFDY+lF
         i51BLKEReh1OtTdSKUiyvoGaHMcXJ8VVhMyRzsPFZ237s9/vmNFiceml0KNndIADjz5r
         sTLQ==
X-Forwarded-Encrypted: i=1; AJvYcCXmoLlYgV0zChxX+NCXCWXP5sKVOJpShur9CznD0bIvTXcJ9QqCHzqgXLHdCUMdKM7wZ1LpKb3kzlU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzxB4oGf9Dd316+ssmYgxFJkdDkuf7pesDU48RXYhcrZqXMOx2N
	VOS15ZepEMPga4qnN4RrepqT6XeBV3olCniOV0OG4eoiz3j9oE+pdE9j
X-Gm-Gg: ASbGnctwh3l+w4Kd8B+Gb6GvKQemTPthXNJrEMyW5rl/EWodajJzEaOd6JIkdZZZ9Bd
	M4EzNw3N6oAATkjg3GNTPJcD8Pwymyub/2IQMecmFJP2ne89EyJKk00whwYKoE0Fal6LB/OLeVb
	jvJ0xCXAf3MIUcWAd6YAvelpTUzla8jykQXO//80eBKXGaaz/Y9FPxTnZ9WoUUl/RskO5VBL5Nu
	qmkuGckQRkb1etwILAUbt9/QlonQVGNLNdslVmqQEk9wfBXvgPvmCWmrtjXtD9szTRu2EZeczRH
	jeULVqziyv+T1QsKg3vPP+tedhZmuIFm+XgwQN/79RNNXXn0X+QMSL621/JIvbwWRciKTzPY4RH
	ok3DJ+QCKG1OftutxhUiykZ23nEdWS/Yp
X-Google-Smtp-Source: AGHT+IEN1+/whpIzxDGTifxx7HEV0Q4r+xbA6FlW2T5q6F11x1tdGppjMi9iLHBf+OspG/yIDKJE1Q==
X-Received: by 2002:a05:620a:454d:b0:7ce:bd76:e36e with SMTP id af79cd13be357-7cebd76e3c6mr280472385a.46.1747611120746;
        Sun, 18 May 2025 16:32:00 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Rich Persaud 
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and accessors for TXT registers and heap
Date: Sun, 18 May 2025 19:31:49 -0400
Message-Id: <29FDCB46-CA92-4A30-B96C-3851414902EF@gmail.com>
References: 
Cc: Andrew Cooper ,
 xen-devel@lists.xenproject.org,
 "Daniel P. Smith" ,
 Ross Philipson ,
 Jan Beulich ,
 =?utf-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Lukasz Hawrylko ,
 =?utf-8?Q?Mateusz_M=C3=B3wka?= ,
 trenchboot-devel@googlegroups.com
In-Reply-To: 
To: Sergii Dmytruk 
X-Mailer: iPad Mail (22F76)

On May 18, 2025, at 2:36=E2=80=AFPM, Sergii Dmytruk  wrote:
>=20
> =EF=BB=BFOn Wed, May 14, 2025 at 03:55:51PM +0100, Andrew Cooper wrote:
>> Please have at least a one-liner introduction to what TXT is.  Is there
>> a stable URL for the TXT spec?  (I can't spot an obvious one, googling
>> around)
>=20
> In addition to a short definition I'll add:
> * https://www.intel.com/content/www/us/en/support/articles/000025873/proce=
ssors.html
> * unversioned link to Software Development Guide
> * link to that unofficial archive (marked as such) mentioned by Krystian

If there's no stable URL for the TXT spec, can we mirror the relevant doc(s)=
 somewhere in the Xen docs tree? A trusted archive of the spec for trusted e=
xecution.

Rich=


From xen-devel-bounces@lists.xenproject.org Mon May 19 06:28:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 06:28:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989511.1373521 (Exim 4.92)
	(envelope-from )
	id 1uGtyn-0000o5-Cl; Mon, 19 May 2025 06:28:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989511.1373521; Mon, 19 May 2025 06:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGtyn-0000nn-7d; Mon, 19 May 2025 06:28:05 +0000
Received: by outflank-mailman (input) for mailman id 989511;
 Mon, 19 May 2025 06:28:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGtyl-0000nh-OT
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 06:28:04 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20626.outbound.protection.outlook.com
 [2a01:111:f403:2412::626])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 68bffa61-347a-11f0-9ffb-bf95429c2676;
 Mon, 19 May 2025 08:28:01 +0200 (CEST)
Received: from IA1PR12MB8467.namprd12.prod.outlook.com (2603:10b6:208:448::9)
 by PH7PR12MB7890.namprd12.prod.outlook.com (2603:10b6:510:268::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Mon, 19 May
 2025 06:27:56 +0000
Received: from IA1PR12MB8467.namprd12.prod.outlook.com
 ([fe80::1633:cc45:8177:a91e]) by IA1PR12MB8467.namprd12.prod.outlook.com
 ([fe80::1633:cc45:8177:a91e%4]) with mapi id 15.20.8746.030; Mon, 19 May 2025
 06:27: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" 
X-Inumbo-ID: 68bffa61-347a-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FQIoc1egJfxCPWG4Zm1DyTQXH/HAR3vtLiDa/7YjqqU0i7X7J05y1at1E0elq8I0xuT4zle4fwvV51DlHayM59QsqEuo/HONfKJCw+bkIOAbgIRQop0++34Tu+hlSmB68h5wkzut4PuT3nJnmhMdD3Qc1Dnu/1k2mEaZt1ago7EQVn38UhljndrQ6dfHVo7j/4xP29vr/wEIETJsn/bp7Vb257iPa/68+aqheriq5XdyL4aaAt7XKp7IjhKdUT7UIR/zpnJfEYRie79nWZJCW1GawWzycxKc/Ex0Qfq7O83SAeEkHhsCrh8IC480oDOy2Ty6p7W5AYvkaKRX1TPVLA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=L2vFWmbdkCaRYOG5Yj8A/inODvdpDHCOkqaXqlWLch4=;
 b=k9J5joK6MPb/ouqw6fAi1euix9MKMV8YxaI91fsarN1kZXMX+lhhU2kVKOpSI4+jiQH71mzx4yModJ88h4xXk/bVYdQ7Q/fJVhnTCAw0dhddjkz9lNjxUnpVIFPdu5BMJYYiWriXIRrKVtEyU9lxRVCBK/5Y6MR4RgKxXVub3ASSIrWCdCcPi+HNmSa87WdJ+V6XDrJ5xazHx48VJe4yK8XdWRPKR7RtBLZZaFoWBoj3mZWAiw4Hvdr3lNWgotRFZFR7KBDgb0kkJumvyAvGNRX1RkgpXxHTXN1y/icDc1wk5qU+CblSC20SKRC1mgF5S00Sqz6JlHHEqju168ZbpQ==
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=L2vFWmbdkCaRYOG5Yj8A/inODvdpDHCOkqaXqlWLch4=;
 b=y8BcIuDR0E++4twNOox39SJYqQO03+AUEUd3/EbeXPHiWvriDqOzYfI60RtofZ/Z3pphC27Ioaz/f4KuRYwQkqMQw51vGKJ2S1TAa/+CN9hBXz+gUyFLcH0jWDWToAp6c16DQWdNoQd4sDFW5cKHdE2jF3tPdloYiuntwdSiKDo=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
Thread-Topic: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
Thread-Index: AQHbrRCkbAdH8T2kS0OlR5huTdSxQbO6ixQAgAATnQCADAI+0IAIsjAAgApgROA=
Date: Mon, 19 May 2025 06:27:55 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-5-Penny.Zheng@amd.com>
 <2f3702f3-a46b-4161-a890-7aad9bbbcac4@suse.com>
 <889d2b2b-db42-43d2-9da0-dcd130d64d9c@suse.com>
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=af991c1e-815e-41cd-84f6-d90af1f56690;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-19T06:25:13Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR12MB8467:EE_|PH7PR12MB7890:EE_
x-ms-office365-filtering-correlation-id: 90fde0a9-30dc-4049-095b-08dd969e4b33
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?cUxUVU5OaE1KNDlJajJCOUg5UnJvTG9lMlhMOUgxS2VwL05SSFNEeTd1cHZP?=
 =?utf-8?B?V1lYRGlBSkQwODdhOFBJLzYzMTZpa2k4a2lzS2lxenpUY0d1YThURDRLUkMv?=
 =?utf-8?B?TWRNSFd1czdwdXFPSGMyenlVcDQ4ZG1UY3d6Z2lYblRHeUExWC9WaHoybmJw?=
 =?utf-8?B?MXNtcE84eDIydStVZEpxT0QxdFJ6WDhDQ3dwYndFanlGWXBWSVM2M3pyL3Np?=
 =?utf-8?B?dGtXMThHcEl6NlViZGRjVWtmS2l2MDVqa3pIOFJmditEVmdHYStJV1ZwS2VW?=
 =?utf-8?B?Y0xaWmdqa1loWmZBOXlGbFRkMEtDbm1iVnprVERpc2JqaUE0WGcwc3JsMDho?=
 =?utf-8?B?cTFaZEFrMmJGQmN4d2p6OVIrRm1leWU3aXJ4K2duZGtPRFZhZWdZNGdRYjF0?=
 =?utf-8?B?bU5mcFBIMHJ0MWdEanNyMUVFRVFKdjJnRStrMm12eUpkd3QvZ1FtNVJEZktJ?=
 =?utf-8?B?anNqNHNYaGlrcUtVY0lJenZZOUhiMlVjODhEaWtTMXNQOHM1WGk2T1E1anhl?=
 =?utf-8?B?QVVHWXNMZmhJak9HVDBDZURwQ0hHVWh0WDQzekVhZ0pPd3RZeXZZZWx3RXhZ?=
 =?utf-8?B?bzBKSjQ4MXhtUzNDakVJZ0R3dXN0T3lQSExHalBOOGZQSGZjZWlKSXgvNWxt?=
 =?utf-8?B?ZytaNVltRkJhbmMrY3h1ZWoybGJOMFNVWHoxYkgxOHJqanJlTmpuUzI4a1hv?=
 =?utf-8?B?cWJEVnp4NVh6UFkyWjVQdkx2VjU4Ym1vTkJLOHRqNURhWG1PanpzSTBBZkNz?=
 =?utf-8?B?eklNNlBYb0g0QjdkNW80VHRYMWxxcXFDU0FJa3EwT3FpTlRnSE02eGtndyts?=
 =?utf-8?B?b3RHdnNYdCtNZFEza3FHUldla0FJc3dXNWNNL1lwMnMrVUdTMWtTR0crdHdW?=
 =?utf-8?B?bmhMbTd5eVY2RkcvSnhiYkZEbjdOK1ZlWlpORFFXdFB5TXBvSU1uL0FoMDZl?=
 =?utf-8?B?U0RxK0lndkpkYzBFa3Nqa1dMMEp6dGVNa2NjN3lpeHZRN1Z5UlNaanNGWmxW?=
 =?utf-8?B?RzNTOTJNUWdxaE5XZ1RRK2I1SUFxS1pNQ0NiaS9tUjlrNHhtTHRuNzRIUGQw?=
 =?utf-8?B?Y01xY1lUS1owN3RXd2ZDKzNUZ2V0akhzSVZKZlpzUnNzbnZrMWx0cm1iZmZN?=
 =?utf-8?B?NStBb1A0bmhnaVRWT2tCNmFSZ2w1dTd3VFd6d1Fwa0RnM0hpa0NsNDdVS0pr?=
 =?utf-8?B?UGNIeWdxOEhvelArbzRMYmVMWjI1cENrT0ZLMXdFVEpaQkFlL1lPRk54WWxx?=
 =?utf-8?B?ekVNTUVjZ0JMckF4RUxaWW1IcDIwbG1BRkcxbzFyRzVSbHZycTJNZU0vbXZ2?=
 =?utf-8?B?bG9semY5cGluUHVWRjdBSXVFdmRaL1lMM2NpbXJ1eUNPYm1uOE5QMUUyZ0ho?=
 =?utf-8?B?NUJzeUdZMUcxbnljSHpkRE9kMHF1SjdhQUJ6ck5Ib3lhVFpQYlRpRWQ3UlVP?=
 =?utf-8?B?MzFTZjFLRVE2dmJvNkxFZjU5aENSaHZxNWVjcmtFTGZaVFZkMzRKMmdEdTFR?=
 =?utf-8?B?K01pTHhtdVE5SzVQVXZMV2dtNlZCejdvS2d3aEkwd09TWGFsZU8xc2IxR1I1?=
 =?utf-8?B?aGFGSFovdWNiN0grR29Db1kya2prV3FYbkhwd3E3bU56SHp3U3pIc0hJV0Jj?=
 =?utf-8?B?YkYwRUN6MVFsMGFKUnp1Z2hLVkZBZWM1NFVvbis3UjZoVjJxczJPaHE2SkxV?=
 =?utf-8?B?bFJOajdxR2lsMWhDYUVwVzlPVmp2TWk1K1hDTUxrdzlYU0h5bTZVWTBzNytN?=
 =?utf-8?B?ejl0NWdJTWtVdkk0NlZZcVJGMmdsNTAzYmk0L0FlUFpqNXlvSUx3VlNvalV4?=
 =?utf-8?B?WkRhYWlia0x3clEzajhKSTE3Q2pUVVZOT285ZXBzb3EwTkk2T01PcVZoSGp2?=
 =?utf-8?B?d0tnclcvTzlkdUw5b2FNSHJDdGNRYjhYczlVNlZKZkJtSCt1eTR5a1BrQUpF?=
 =?utf-8?B?YTNDVGUzNFpOMW9HVFJJY0tnWDhDRVlONGNlQldxNDlueXNiS3FtbDNUQktk?=
 =?utf-8?Q?CFWgf6VKOUpcTT0Csi69/nob3Rp7oA=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR12MB8467.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?OVh5ZUFrZ0lwNGNkM3RiYXg0UEpScUpGZHVCQm9HejlXaEdRMXBEdmh4S2Zi?=
 =?utf-8?B?MTRPVGRsQTdDQVR0NkhqOWVwSWpTM3RHLzdxWk9CeTUxQ2FWODZva3FDOFFI?=
 =?utf-8?B?RXJKZzUxOU0vcTc3aFdJejVnT21VSnpPcXZKVC93V1VnUGNnMjhiTEtpUklF?=
 =?utf-8?B?QVNFcFVFdVE1UHpjUzdCeENLT0JVb3BHcEFUNUZiTldtLzZ3amk5U0lEeHpZ?=
 =?utf-8?B?OGNjbVhBSFU5ZGNiSXdtaVgxclEva2lMTW52Ukd2NW5kTlBDd1RzTUtiS2Fu?=
 =?utf-8?B?UHRZUHErVGN2UmlyeTR5UVg3OTBwWDlTK0cwZHpIZnZPbkQ1TFlJNFBLUisy?=
 =?utf-8?B?V2JzOStiZ0EyNmt5Wk5Ocjd2MFdkMUVxRnVmc25xU0Z1MjNNbVRTT09xTS9y?=
 =?utf-8?B?YkpWZGRTMTgvWVlnaHkveXRoSjhvTFVNU2VDWHdyU3lUU3dFaFZsOGZGTFBj?=
 =?utf-8?B?QkdqMzdycHhFNERIOVg1L3FScWFmRW10ZEFpNG5yNmZ5SzV1c3FBM0g0NXJU?=
 =?utf-8?B?K1Z5eDRZOWV5aHd5NWNBZVdNZ1hJTHZKSjYxSUIxZFFLOGlXZEoxZW5UMjJ0?=
 =?utf-8?B?SzBYakZCOU81YmtMQ2hKZ21reVBWT1BBa2JBdTdMYktDQkZZOGdMSkdud2xP?=
 =?utf-8?B?VVp5UHRXejlBbWxBZzZKajFGb0ErT1hIYldacmtIOXY0UkZjRmVrdi8yY3ZQ?=
 =?utf-8?B?dHpZemNTRlVoUHpSOGQ3VEErUmNCV3AzK0NjaDJNMHNFNWFsM3BHZzRhdGN3?=
 =?utf-8?B?ZWp3MCtrMlRIbHBBS1hESU9qUkNlSzc0OVpteWF0cnZFWHQ1UW9EVmJ2MWtS?=
 =?utf-8?B?Qml5TGFXbTVHSGp1RllwNUZxaFRwQS9WSndhTjc4UUFXY2p4VjNZUmRNV0ln?=
 =?utf-8?B?RjNtNngyUGhVa0NyWEUwNGZUK1hpbHFDbnpPeEhTWDk2cUxoWTZzcHlUSmg0?=
 =?utf-8?B?bUhyU0x5M1dHRlllRW16RVdwYzJER1JJLzc4aHdpUWt2VXFFNHRNcTZ2ZWh2?=
 =?utf-8?B?LytqaWhEY3RmWGZHdmo5TUJmN1Ryemp1TmVMU2Z6THpFV2RLdDl5ZXRFWjhx?=
 =?utf-8?B?L0dzc0tJOGpQOHh1eWJOdFdZdUd1Q1pQTFBJVUFrcXEyT2R1SzRwSjVWK1FS?=
 =?utf-8?B?MUErUkZWY1A0L1VGWEVqNUt2R2ZPVDhxdm1IbjA5cXdFSGZrNnhRMldqNERn?=
 =?utf-8?B?TkRmMllzWXJva1hScUlUM0sxMUVheStSbXppUE4rS3ZYK0RBbHZ4V2hPTW9S?=
 =?utf-8?B?OGo2dkRvV2NuaGkwM1A3ZjFsakpNTk02L09EdnRxZEFqZWtldzZESHdOeW80?=
 =?utf-8?B?Y0ZBeHJsWG4rcDJpZUN1dXBVTlJ1ckx1TTNOOTZWZlBhTmlCUElXQ3lua1Fk?=
 =?utf-8?B?aTNJVjhjU1gvWWZScVBoVXgwZHFqaGxkbEFZdFFmU1g4N2N5M0lPTnY2VUVE?=
 =?utf-8?B?ZDR5WmFPUkNqVUhOZWZhR0tOK3lGTzhoVzViUEptUElaUzhSTHZMQkkxOHBs?=
 =?utf-8?B?TVdvNHBUajU5Rno2cXo5T2tUUUhLSWg0YldOb3Nlc05QV3ZNS0RFZ2VpTDFu?=
 =?utf-8?B?bk1jZ0dNaDRYSjQrRDYvaUI5WGtQV0RhQlowcnhzc0E1dmRvSDVzbVNVVFJm?=
 =?utf-8?B?MWdZclVKb1BqTlpGQUR0K2piMlhqQVFMNDY1bjdvNnpSYW56YlBwMnVvS2tq?=
 =?utf-8?B?Y1dHUEZaRFkyVW9MSE1EQ3VBYjNCdU5GcmUrWCtWL25maXFYbTNNOEpVWVJY?=
 =?utf-8?B?NUhXOVFmTWZDeW5ZbzQzOEwwZElaOWw5T1lzMGtCRzBtZXJHUlZNa1RJWGd4?=
 =?utf-8?B?MnJLMUM2STVDcHF4YkdiYzNmR0tidisrcjFsTS8yVjNhNlhlTW8vM1ZtZE05?=
 =?utf-8?B?bkdmQklqVHQrcVpuSDIyZ0l5V3F3MmoycVp5NVpTaG5RL2FNbTRoZEs4bC94?=
 =?utf-8?B?S1B3RWJkMklFR2JSLytJR3pNaXBrRjMwQ29oN0wxWmJMV2V3SjlrVTBpU00x?=
 =?utf-8?B?NjlrMlM3V1k0aHl4TC8raFMvZy9UVGxUYnV0blpyK1VJcm9KOXNNUUw5RnVv?=
 =?utf-8?B?Uk9ZNXAzaW1FMFdqeS9rVERsQ2ZqSGVzSFJ1WnhjL21CU3dPd2k5cXFabW44?=
 =?utf-8?Q?EcCA=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB8467.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 90fde0a9-30dc-4049-095b-08dd969e4b33
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 06:27:56.6960
 (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: lRQ1xj1vdyBCZkMNVci1+pig//t9zlvUeE/oXb8fTTjgA36CJSCZ845MwsbWkEK1ZEFIV3Qp9XR90v6KKIgOvA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7890

W1B1YmxpY10NCg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBNb25kYXksIE1heSAxMiwg
MjAyNSAxMTo1OCBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0K
PiBDYzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyB4ZW4tZGV2ZWxAbGlzdHMueGVu
cHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NCAwNC8xNV0geGVuL2NwdWZyZXE6
IHJlZmFjdG9yIGNtZGxpbmUgImNwdWZyZXE9eHh4Ig0KPg0KPiBPbiAwNy4wNS4yMDI1IDA1OjE4
LCBQZW5ueSwgWmhlbmcgd3JvdGU6DQo+ID4gW1B1YmxpY10NCj4gPg0KPiA+IEhpLA0KPiA+DQo+
ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEphbiBCZXVsaWNoIDxq
YmV1bGljaEBzdXNlLmNvbT4NCj4gPj4gU2VudDogVHVlc2RheSwgQXByaWwgMjksIDIwMjUgNzo0
NyBQTQ0KPiA+PiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiA+PiBD
YzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJv
amVjdC5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NCAwNC8xNV0geGVuL2NwdWZyZXE6
IHJlZmFjdG9yIGNtZGxpbmUgImNwdWZyZXE9eHh4Ig0KPiA+Pg0KPiA+PiBPbiAyOS4wNC4yMDI1
IDEyOjM2LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gPj4+IE9uIDE0LjA0LjIwMjUgMDk6NDAsIFBl
bm55IFpoZW5nIHdyb3RlOg0KPiA+Pj4+IC0tLSBhL3hlbi9kcml2ZXJzL2NwdWZyZXEvY3B1ZnJl
cS5jDQo+ID4+Pj4gKysrIGIveGVuL2RyaXZlcnMvY3B1ZnJlcS9jcHVmcmVxLmMNCj4gPj4+PiBA
QCAtNzEsNiArNzEsNDkgQEAgdW5zaWduZWQgaW50IF9faW5pdGRhdGEgY3B1ZnJlcV94ZW5fY250
ID0gMTsNCj4gPj4+Pg0KPiA+Pj4+ICBzdGF0aWMgaW50IF9faW5pdCBjcHVmcmVxX2NtZGxpbmVf
cGFyc2UoY29uc3QgY2hhciAqcywgY29uc3QgY2hhcg0KPiA+Pj4+ICplKTsNCj4gPj4+Pg0KPiA+
Pj4+ICtzdGF0aWMgYm9vbCBfX2luaXQgY3B1ZnJlcV9vcHRzX2NvbnRhaW4oZW51bSBjcHVmcmVx
X3hlbl9vcHQNCj4gPj4+PiArb3B0aW9uKSB7DQo+ID4+Pj4gKyAgICB1bnNpZ25lZCBpbnQgY291
bnQgPSBjcHVmcmVxX3hlbl9jbnQ7DQo+ID4+Pj4gKw0KPiA+Pj4+ICsgICAgd2hpbGUgKCBjb3Vu
dCApDQo+ID4+Pj4gKyAgICB7DQo+ID4+Pj4gKyAgICAgICAgaWYgKCBjcHVmcmVxX3hlbl9vcHRz
Wy0tY291bnRdID09IG9wdGlvbiApDQo+ID4+Pj4gKyAgICAgICAgICAgIHJldHVybiB0cnVlOw0K
PiA+Pj4+ICsgICAgfQ0KPiA+Pj4+ICsNCj4gPj4+PiArICAgIHJldHVybiBmYWxzZTsNCj4gPj4+
PiArfQ0KPiA+Pj4+ICsNCj4gPj4+PiArc3RhdGljIGludCBfX2luaXQgaGFuZGxlX2NwdWZyZXFf
Y21kbGluZShlbnVtIGNwdWZyZXFfeGVuX29wdA0KPiA+Pj4+ICtvcHRpb24pIHsNCj4gPj4+PiAr
ICAgIGludCByZXQgPSAwOw0KPiA+Pj4+ICsNCj4gPj4+PiArICAgIGlmICggY3B1ZnJlcV9vcHRz
X2NvbnRhaW4ob3B0aW9uKSApDQo+ID4+Pj4gKyAgICB7DQo+ID4+Pj4gKyAgICAgICAgY29uc3Qg
Y2hhciAqY3B1ZnJlcV9vcHRzX3N0cltdID0geyAiQ1BVRlJFUV94ZW4iLA0KPiA+Pj4+ICsgIkNQ
VUZSRVFfaHdwIiB9Ow0KPiA+Pj4NCj4gPj4+ICAgICAgICAgY29uc3QgY2hhciAqY29uc3QgX19p
bml0Y29uc3RyZWwgY3B1ZnJlcV9vcHRzX3N0cltdID0gew0KPiA+Pj4gIkNQVUZSRVFfeGVuIiwg
IkNQVUZSRVFfaHdwIiB9Ow0KPiA+Pj4NCj4gPj4+IChsaW5lIHdyYXBwZWQgc3VpdGFibHksIG9m
IGNvdXJzZSkgT3IgbWF5YmUgZXZlbiBiZXR0ZXINCj4gPj4+DQo+ID4+PiAgICAgICAgIGNvbnN0
IGNoYXIgX19pbml0Y29uc3QgY3B1ZnJlcV9vcHRzX3N0cltdWzEyXSA9IHsNCj4gPj4+ICJDUFVG
UkVRX3hlbiIsICJDUFVGUkVRX2h3cCIgfTsNCj4gPj4+DQo+ID4+PiBmb3IgdGhlIHN0cmluZyBs
aXRlcmFscyB0byBhbHNvIGVuZCB1cCBpbiAuaW5pdC5yb2RhdGEuDQo+ID4+DQo+ID4+IEFjdHVh
bGx5LCBpdCBkaWRuJ3QgZXZlbiBvY2N1ciB0byBtZSB0aGF0IHRoZXJlIG1pZ2h0IGJlIGEgInN0
YXRpYyIgbWlzc2luZyBoZXJlLA0KPiB0b28uDQo+ID4NCj4gPiBTb3JyeSwgSSBtYXkgbmVlZCBt
b3JlIGV4cGxhbmF0aW9uLCB3aGF0IGlzIHRoZSAic3RhdGljIiBtaXNzaW5nIHlvdSBhcmUgcmVm
ZXJyaW5nPw0KPg0KPiBJbiB5b3VyIGNvZGUgY3B1ZnJlcV9vcHRzX3N0cltdIGlzIGFuIGF1dG9t
YXRpYyB2YXJpYWJsZSwgd2hpY2ggdGhlIGNvbXBpbGVyIG5lZWRzDQo+IHRvIGVtaXQgY29kZSBm
b3IgaW4gb3JkZXIgdG8gaW5zdGFudGlhdGUgaXQgb24gdGhlIHN0YWNrLiBUaGlzIGNhbiBiZSBh
dm9pZGVkIGlmIHlvdQ0KPiBtYWtlIHRoZSBhcnJheSBhIHN0YXRpYyB2YXJpYWJsZSwgYXMgdGhl
biBhbGwgY29uc3RydWN0aW9uIG9jY3VycyBhdCBidWlsZCB0aW1lLg0KPg0KPiA+PiBQbHVzIEkn
bSBtaXNzaW5nIGFueSBhcnJhbmdlbWVudCBmb3IgdGhlIGFycmF5IHNsb3RzIHRvIHJlbWFpbiBp
bg0KPiA+PiBzeW5jIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgZW51bWVyYXRvcnMuIFdpdGggdGhh
dCAuLi4NCj4gPj4NCj4gPg0KPiA+IFRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIGluc3RydWN0aW9u
cywgbGVhcm5lZCBhbmQgSSdsbCBjaGFuZ2UgaXQgdG8NCj4gPiAgICAgICAgIGNvbnN0IGNoYXIg
X19pbml0Y29uc3QgY3B1ZnJlcV9vcHRzX3N0cltdWzRdID0geyAieGVuIiwgImh3cCINCj4gPiB9
OyBBbmQgZm9yIGluIHN5bmMgd2l0aCB0aGUgY29ycmVzcG9uZGluZyBlbnVtZXJhdG9ycywgbWF5
YmUgd2Ugc2hhbGwgYWRkDQo+IGNvbW1lbnQgaGVyZSwNCj4gPiAgICAgICAgIC8qIFRoZSBvcmRl
ciBvZiBjcHVmcmVxIHN0cmluZyBsaXRlcmFsIG11c3QgYmUgaW4gc3luYyB3aXRoDQo+ID4gdGhl
IG9yZGVyIGluICJlbnVtIGNwdWZyZXFfeGVuX29wdCIgKi8NCj4NCj4gSW5zdGVhZCBvZiBhIGNv
bW1lbnQgSSBoYXMgcmF0aGVyIGhvcGluZyBmb3Igc29tZSB1c2Ugb2YgZGVkaWNhdGVkIGFycmF5
IHNsb3QNCj4gaW5pdGlhbGl6ZXJzLg0KDQpVbmRlcnN0b29kLiBJJ2xsIHVzZSAiQ1BVRlJFUV94
eHgiIGFzIGFycmF5IHNsb3QgaW5kZXguDQogICAgICAgIHN0YXRpYyBjb25zdCBjaGFyIF9faW5p
dGNvbnN0IGNwdWZyZXFfb3B0c19zdHJbXVs1XSA9IHsNCiAgICAgICAgICAgICAgICBbQ1BVRlJF
UV9ub25lXSA9ICJub25lIiwNCiAgICAgICAgICAgICAgICBbQ1BVRlJFUV94ZW5dID0gInhlbiIs
DQogICAgICAgICAgICAgICAgW0NQVUZSRVFfaHdwXSA9ICJod3AiLA0KICAgICAgICB9Ow0KDQo+
DQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Mon May 19 06:30:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 06:30:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989517.1373530 (Exim 4.92)
	(envelope-from )
	id 1uGu15-0002F1-Mu; Mon, 19 May 2025 06:30:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989517.1373530; Mon, 19 May 2025 06:30: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 1uGu15-0002Eu-Jn; Mon, 19 May 2025 06:30:27 +0000
Received: by outflank-mailman (input) for mailman id 989517;
 Mon, 19 May 2025 06:30:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGu13-0002Eo-Q8
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 06:30:25 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bef46651-347a-11f0-9eb8-5ba50f476ded;
 Mon, 19 May 2025 08:30:24 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-601d10de7e1so1408938a12.1
 for ; Sun, 18 May 2025 23:30:24 -0700 (PDT)
Received: from [192.168.61.201] (server.hotelpassage.eu. [88.146.207.194])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4ea8aesm543602866b.179.2025.05.18.23.30.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 23:30: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" 
X-Inumbo-ID: bef46651-347a-11f0-9eb8-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747636224; x=1748241024; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=TeQJ6IFBKtNjAc0HEkaLLlZ44u2eux9Uo/jLFOFCqeY=;
        b=CV/K6LrauN9wga2KzJxqvbECX2IudBqQl4Dr3qN0gR3yYYLLTh4dIMkVSDt7DPcAhQ
         n6o1twF2aSgEcoRbd6O/p+nFTtM9BDJbHZVjysSDBMZGfUpMi8LgfVw6GLR0JHwgoiBM
         +SXPWrQCt/HWFAnkyoX1tRAh1lD0RszvcTPEbM8LcZdYmSCVZKDbl++23M1STWFIRoDJ
         EVESPM172cQGqxbdiSVyvYeLaJStCQyu21QcUixS0T6zZlYuSWkqT0NnwZdJnrBzP8Of
         61oUSXD5/MarvZDI6SzD1S3yjjf2al0e6bQvLXS0F8IlW6zjvsubwYnRE3gxCkri+9d7
         5YtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747636224; x=1748241024;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=TeQJ6IFBKtNjAc0HEkaLLlZ44u2eux9Uo/jLFOFCqeY=;
        b=eJa8FCyt1Ns+MdFh+WeFL68tu687lrtUhG2l16pSaEhTrHA/CAnJ1oV0aUAWgESW0y
         rrOmD3Q8L0K9lydBChRz6qeWHX0DADMAMw/v2liiq0hdiHKnWTtzaqyXgxrQzUu92vgO
         O1lkVHOFvUx2AfwwBcRm89uTVj6fJqa99Pc+N8onw5ryvarC7R+McXJFfyCEsoKIVlGk
         rexhMgyreoFXFYQdWQv0eH94Bshkzs0JUgfSJGvlj9kxv1aNoNqwY/KuZANnV4TL6R7d
         HitajVwUX2m52RlIvLkg4ACDSKAP0UIJpeeMH0xJPwca4dUw+/TU7XIMwchA727lZkOA
         rbcA==
X-Forwarded-Encrypted: i=1; AJvYcCWKzkX2EfAaLVINbB/XHzWMUTaFoPW+fC7j9QpFjEgxCc1N5OutK6z6kldDvpAWkkepAle6wsZfNFw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxN1fgp5l1fMj3QicAFNqhma7kbLBn85MKWuVy6mhZxutfC18sF
	lnBIx5VbH77q9MrLfYON2dJ+dML6VHtFSknQOF/egE51xKAGDu08gbT3fa+a759oajjOHilSTnD
	kR3JEqA==
X-Gm-Gg: ASbGncsFfyRnhaTtKyuWYS1zugZsrop5G6xm2gQ0UFw6bHdMXiGinl4XUb1vTNiUT+0
	SlD186OQj/7IlnYP2oo968EbPRreUCqyu7wrv6IUwJG2mJFqYxcPhb2BQOpRbAWFHkWtD3A6bHb
	fB/hXcH/Ym6cB6++jDk3FN8rTKspOzqT/ihoefAjWGwrnFXGvDjoE9Pp2U+0y1XkftlbuAlpsjr
	ne9pzAwUeuaiUAEsOLRETf2HGoFELFphsPO2pG/s1FUJn0Ugi/OE8k0PSbXAQopp0O4xir1Dbhv
	4jWXd0Am3r4SI/v7WUIOa4ywKm/KpQbISd75MzEKdt181wsIWXTfBt1TPzLpHe2A2niyduqC+Pn
	LpWLXyybKKw==
X-Google-Smtp-Source: AGHT+IH1aCS0MUgER9AE6jGST8Lpa+A0pq9OsFfrLHAIQV8PKbxUQeoPXMPW0NKyfMdq0HRtLkOjrg==
X-Received: by 2002:a17:907:3e16:b0:ad4:f512:733 with SMTP id a640c23a62f3a-ad536dce6e4mr1085821366b.45.1747636223742;
        Sun, 18 May 2025 23:30:23 -0700 (PDT)
Message-ID: <7129d506-b03a-4f89-8128-84b8befe8799@suse.com>
Date: Mon, 19 May 2025 08:30:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 07/10] vpci: Refactor vpci_remove_register to remove
 matched registers
To: Jiqian Chen , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
Cc: Huang Rui , Anthony PERARD
 , xen-devel@lists.xenproject.org
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-8-Jiqian.Chen@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250509090542.2199676-8-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 11:05, Jiqian Chen wrote:
> vpci_remove_register() only supports removing a register in a time,
> but the follow-on changes need to remove all registers within a range.
> So, refactor it to support removing all matched registers in a calling
> time.

Generally I'm a little wary of changing behavior for existing callers,
but I guess Roger already did signal he's okay taking that route?

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 06:32:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 06:32:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989524.1373540 (Exim 4.92)
	(envelope-from )
	id 1uGu2f-0002oe-0t; Mon, 19 May 2025 06:32:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989524.1373540; Mon, 19 May 2025 06: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 1uGu2e-0002oX-UV; Mon, 19 May 2025 06:32:04 +0000
Received: by outflank-mailman (input) for mailman id 989524;
 Mon, 19 May 2025 06:32:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGu2d-0002oN-00
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 06:32:03 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f891f4ce-347a-11f0-9ffb-bf95429c2676;
 Mon, 19 May 2025 08:32:01 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-600210e4219so5677217a12.0
 for ; Sun, 18 May 2025 23:32:01 -0700 (PDT)
Received: from [192.168.61.201] (server.hotelpassage.eu. [88.146.207.194])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d501fe9sm5336419a12.20.2025.05.18.23.32.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 23:32:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f891f4ce-347a-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747636320; x=1748241120; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=inVQoYGkJNXV0yd0t5SUJvuNQY5MUANJ2cdud0HaO3Q=;
        b=YmkU2hH1qohznGQCqWSz4Bn+CCn1FohlO5/5UXeBr7Yeq2LGbpKDvA7gRdvJH7AgEV
         U+hl8Z0lsIpGWhrDzWqGfWRK04zChT8JduHC+k07GijQyJ6K4HCSLwDI/FUPSeb/DfSt
         qRadq7QHQaSM8CNQDIRV+6sg1n0qW1PwaXvq7c3ySb8i2B9oAwFskSBdrdvAawE4BDSq
         +nMFTWX8d9sTFky6r1naVybOp9TKGFSlqW6mn9Sa/0zcD0rcrKBumPHTrfMiE4A+hzs2
         0G6P9OwKUHxJhjMAo34m5m8e3EdM+1zFyn7qjKVZt6I/Fx4ibkrAZUTKPZUkfpZ/kLLk
         j6ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747636320; x=1748241120;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=inVQoYGkJNXV0yd0t5SUJvuNQY5MUANJ2cdud0HaO3Q=;
        b=sUWk4RbZ6QYPr6T/Xj88JzstiqJxnTTw/HTB99TWoaJbE3o+MRw8DrX/70v4wjny4Q
         NxoxA+JoxFzc7Qil0p1YAdGTqIV8vtX1jGBqnLXQqJJmEN0Xeo+DjUJIE5NcZPBGPnXK
         ZpDUEj9kApqJCg9C/TJ/1jP2cJzDA3iXYsZwlnuxpWfix1oaQv7oEfXUPMHcqG/3d8l0
         KP15BaRRUz9e/8+ZJMG5W6p91ALKuRgwtLn6LsC0UHuXR3ZkxQKaGHE0/tUO7yVsG3vC
         G05HP4qBFXW+LwutVD6jpEdTBPN4xmPGnuD8kl2AhmfZFfEZZgrv4/tsNZYoGHGK8ekv
         COkw==
X-Forwarded-Encrypted: i=1; AJvYcCUPDlCS7D3va9/WX7gwDJAHrX6VSSYcdpSg5diKmu/fFI9uHuAdPIDdWFWmhEdcmvvYCMsayTtldSQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzmZ8JV4jQWT9mZAVPS5HuDsKpTUfyLywa7nyGp09o8m5u8QmT8
	PnIjXela52AQ0Wvpgy6B1Lq/t4l/lFNUgcaHQ7PxnWTsSBXBWL2BKsGzaTYZaupc4Q==
X-Gm-Gg: ASbGncvfhwDZjadduRvNHqw662/nf3V5V5dYyXYBkgBOGXqrIq8YwZiJEvMIZNKhg+x
	r4D/uJF1VE1wvpHKrK29kKbO0G0epHF3DXkvH8DBM/WXF9im8e9YEna7o+u/2x/Uia18N5I5IAm
	A2tcVW0iKSQOey7cird5/7Aj5TxCLw86Av4UOYjzlqba2q4g7PrK05rpfd5tTeo8IJpB4V5Gm0N
	YV4ZZk01tGp3yTb9a3XAPy81LvdNLboKBkhRGhmQM42eWCsYhIxiifI2zo6WoLAVl4X/oBBqkL5
	3Gr/cg6lGMZZ/L0ep30xSGIabaSsKUTRe3i/qa80co7d9+u1Y51KT3eaXrgQ+TQgu8R9+d+jVl3
	/yMRDXLnh/w==
X-Google-Smtp-Source: AGHT+IGIlufVtEocN181MOEcmuAqbe4U/fqcmQ8xU28iVfemqt0YKq6Crv7bnL2xCBpFHvN9xcA/xA==
X-Received: by 2002:a05:6402:3085:b0:600:a694:7a23 with SMTP id 4fb4d7f45d1cf-600a6947cecmr7439718a12.0.1747636320546;
        Sun, 18 May 2025 23:32:00 -0700 (PDT)
Message-ID: 
Date: Mon, 19 May 2025 08:31:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufreq=xxx"
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-5-Penny.Zheng@amd.com>
 <2f3702f3-a46b-4161-a890-7aad9bbbcac4@suse.com>
 <889d2b2b-db42-43d2-9da0-dcd130d64d9c@suse.com>
 
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 08:27, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Monday, May 12, 2025 11:58 PM
>> On 07.05.2025 05:18, Penny, Zheng wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich 
>>>> Sent: Tuesday, April 29, 2025 7:47 PM
>>>> On 29.04.2025 12:36, Jan Beulich wrote:
>>>>> On 14.04.2025 09:40, Penny Zheng wrote:
>>>>>> --- a/xen/drivers/cpufreq/cpufreq.c
>>>>>> +++ b/xen/drivers/cpufreq/cpufreq.c
>>>>>> @@ -71,6 +71,49 @@ unsigned int __initdata cpufreq_xen_cnt = 1;
>>>>>>
>>>>>>  static int __init cpufreq_cmdline_parse(const char *s, const char
>>>>>> *e);
>>>>>>
>>>>>> +static bool __init cpufreq_opts_contain(enum cpufreq_xen_opt
>>>>>> +option) {
>>>>>> +    unsigned int count = cpufreq_xen_cnt;
>>>>>> +
>>>>>> +    while ( count )
>>>>>> +    {
>>>>>> +        if ( cpufreq_xen_opts[--count] == option )
>>>>>> +            return true;
>>>>>> +    }
>>>>>> +
>>>>>> +    return false;
>>>>>> +}
>>>>>> +
>>>>>> +static int __init handle_cpufreq_cmdline(enum cpufreq_xen_opt
>>>>>> +option) {
>>>>>> +    int ret = 0;
>>>>>> +
>>>>>> +    if ( cpufreq_opts_contain(option) )
>>>>>> +    {
>>>>>> +        const char *cpufreq_opts_str[] = { "CPUFREQ_xen",
>>>>>> + "CPUFREQ_hwp" };
>>>>>
>>>>>         const char *const __initconstrel cpufreq_opts_str[] = {
>>>>> "CPUFREQ_xen", "CPUFREQ_hwp" };
>>>>>
>>>>> (line wrapped suitably, of course) Or maybe even better
>>>>>
>>>>>         const char __initconst cpufreq_opts_str[][12] = {
>>>>> "CPUFREQ_xen", "CPUFREQ_hwp" };
>>>>>
>>>>> for the string literals to also end up in .init.rodata.
>>>>
>>>> Actually, it didn't even occur to me that there might be a "static" missing here,
>> too.
>>>
>>> Sorry, I may need more explanation, what is the "static" missing you are referring?
>>
>> In your code cpufreq_opts_str[] is an automatic variable, which the compiler needs
>> to emit code for in order to instantiate it on the stack. This can be avoided if you
>> make the array a static variable, as then all construction occurs at build time.
>>
>>>> Plus I'm missing any arrangement for the array slots to remain in
>>>> sync with the corresponding enumerators. With that ...
>>>>
>>>
>>> Thanks for the detailed instructions, learned and I'll change it to
>>>         const char __initconst cpufreq_opts_str[][4] = { "xen", "hwp"
>>> }; And for in sync with the corresponding enumerators, maybe we shall add
>> comment here,
>>>         /* The order of cpufreq string literal must be in sync with
>>> the order in "enum cpufreq_xen_opt" */
>>
>> Instead of a comment I has rather hoping for some use of dedicated array slot
>> initializers.
> 
> Understood. I'll use "CPUFREQ_xxx" as array slot index.
>         static const char __initconst cpufreq_opts_str[][5] = {
>                 [CPUFREQ_none] = "none",
>                 [CPUFREQ_xen] = "xen",
>                 [CPUFREQ_hwp] = "hwp",
>         };

Provided the "none" entry doesn't cause any anomalies, this way.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 06:43:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 06:43:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989534.1373551 (Exim 4.92)
	(envelope-from )
	id 1uGuDq-0004ZX-Vr; Mon, 19 May 2025 06:43:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989534.1373551; Mon, 19 May 2025 06: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 1uGuDq-0004ZQ-St; Mon, 19 May 2025 06:43:38 +0000
Received: by outflank-mailman (input) for mailman id 989534;
 Mon, 19 May 2025 06:43:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGuDp-0004ZK-6k
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 06:43:37 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2060d.outbound.protection.outlook.com
 [2a01:111:f403:200a::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 95639ede-347c-11f0-9eb8-5ba50f476ded;
 Mon, 19 May 2025 08:43:35 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SJ2PR12MB8977.namprd12.prod.outlook.com (2603:10b6:a03:539::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Mon, 19 May
 2025 06:43:30 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Mon, 19 May 2025
 06: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" 
X-Inumbo-ID: 95639ede-347c-11f0-9eb8-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lEmNWwFHeMJwvXyLQEAod8lXSAUDjOZuv6QtxHrM+njh/R2X34MOs1dHusMgoeSSoHASMrFCq1WyDos+Xw2OKXKWk4GKWLRZ8nGNtPo/W/uQbKWl5XLB2clMcYgUNDbjGVg3tYWHJsay1Id25/EAXCe10qvpHvu5hbet0eBv4vs9vL0fAS6MsHS0I5ewAWH61hybeBLwjou0aVUAX+FswjfK8refcABfjba2/jjB4lTIkQg4Muc9lY6LUToOLhrAeADWpBUn0id4xYbqA69kzL5CwQ/zzjvYso9uaq3JP7NLdm7S/xyR4S+2Njktx/PGnY3pc5V2VlscIMs4qzh3Mg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=r7PXkzJlOXDrW03fgMrk4mkgExt/e8dH/DsFJf7bY1E=;
 b=BLL4xpEcqxCu1JjqL8SLQzIGm4RkiZDzk/sjH5u7bOPoyhD903pp//Sdh3+2q3aWy92c/cqf/m5DT5B5Y6XQ6hKpbb4fz0KLwDQIObLfsLUpYQvDBhWrYEcuLe49GsIVZKkYdlk8hDy7UQ/CJP085IvGuUYxsBw65vZ3mZlJVI3OO2dB81BtCg00Xo5TG1i/jcyIdQcqyq5gfP1CN2zcZPoYstwX0lQi47cLnEX3cOZKivrCa1Uy9xCxS7P0cqXHiGmJmd/1fqoy0HpKJ+6Sz3h1oWcx01n+rb7xfAy7XFaaoYUly8llSKweGY8zTcw9LoAHeWeo7r0hR8UrFiaJjw==
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=r7PXkzJlOXDrW03fgMrk4mkgExt/e8dH/DsFJf7bY1E=;
 b=gzTZ1XFuyS+cL7OiV/3GGNGnQCGzyDG2Z30mFInnZAKmKgBAbs57p3I2hJiDFabZZFAJ0C0VOxfA3WyBkhLyOMqwNuthgZ7wI2K1F/snsdyX13O7z43p0KIQnBYZ3Hr27pqGoMzgh5jkMjwoc+bBDtNkHqmdhfXP6d7R6zaqJhU=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= ,
	"xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
Thread-Topic: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
Thread-Index: AQHbwMGevTfR886wakahq6ntIeNmMrPYfnSAgAGVuQA=
Date: Mon, 19 May 2025 06:43:30 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-4-Jiqian.Chen@amd.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SJ2PR12MB8977:EE_
x-ms-office365-filtering-correlation-id: 69ac9a9e-70d6-4db1-2cff-08dd96a077df
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?d0JLblRkLzJLeldiQm51MDE0QWRndEZ1RjF5SXRaRjJBWUI3eCtVYnJDV1FQ?=
 =?utf-8?B?QUozQ0ExaUpMYy9YeFl5UDBneVkzaTQ4L0QyMjZhSm1iR2FVQTJnd2xIeWM2?=
 =?utf-8?B?S2JIRmFMQVY4MmpqZGNUelVnM2Y3bVJnNkZ6MjF0d1VpS3diTTNJVlQ1aUhX?=
 =?utf-8?B?U0tCYXd5LzVTN0NIRmNjMVZMZHJ0NTl6Y3QzMTZJbTJZd0xDd3BlSXU1YytJ?=
 =?utf-8?B?TEZRbGg2SkhHVUE5MDY2clJKRXU2OHNEUDJiTHhlYVJaSEZTaHFnTUlDWk1M?=
 =?utf-8?B?VXJSckZnYXl3NGhtVmE3U08zQzF1RnpIeG1IVUp0UkszMWNzS0F0NkhKa1BZ?=
 =?utf-8?B?b1B2MGNNa2tLR2cyM3Vaak9tZDNFc0V4RHZtZGNaN1kyRmczYVVhRGx2cmFr?=
 =?utf-8?B?aXpqSFo3eE9qV21CWnQxQkxiYXVhOFYwbXpnUm1ZVDJzRDhhSTIxQXNJMEpF?=
 =?utf-8?B?N1krUGJpaGFZVHdPMkJqR3ZxMi9FaDh2TStsdDlucVFTNzlYZHRhNng5aDlj?=
 =?utf-8?B?VDd2ejRUT3BlT1VVcFFyQzZ5L1JoWXJSZTB6U2Fpd0grNnFycWFEclB4UWk1?=
 =?utf-8?B?UXU2MkdDN0szRVRlUlExelJGRmRnQWp1eXVTM3FReVFEdTBiT2lmenpRaTZw?=
 =?utf-8?B?YVRlcHk1MnBxY25PTVVKcm5aNVd0R0U0aGZKaUFid0hwRUNESE1VWUVYYzA1?=
 =?utf-8?B?VDVTT2Y1LzIzT2NCaUkwOVR3c1ZWTEdQQWd6KzlCaDNQZFNnVjZHcU55Uzhu?=
 =?utf-8?B?N2ZZdXdXbitFODNDWFB0bDAxcDR6RFhYakdtR1luR2ZQaS92RmpOVzB0N2pF?=
 =?utf-8?B?OFZYcC9oOGR6aG9PWjhEdFJDSWdvYUdCZm8xaURnQ0VRdXU3Nlh2V081WVlq?=
 =?utf-8?B?OXZYUDcxK1VjVnBxY01FWHNIcjZJUGRNU3FnaHQzTmxCKzF4NC9veE1Samda?=
 =?utf-8?B?UmswNHJHRWZTK0dLQzNsSGhhamx4cDhHSFQ4OWlmQ1hQL2NuVDk3cWxMU0RO?=
 =?utf-8?B?bHIzRmE3dVdVVUJYUzcwODFpYisySDcrZk1qMCtCS1l6MGFUMXJGSXp6dWxL?=
 =?utf-8?B?dkpsL0UzRWxYaktCdnVBOEZOQlhLUkt6S0J1d25NVmRaWVlxVFFVUjhISDFu?=
 =?utf-8?B?M1NUODRRbUdhM0hybThJM1pvelFSdkpoWjI5MFNOQzJXb2ZWbzdkTzdNWUo2?=
 =?utf-8?B?QWpFOUxDcTh6dEExbjlvTVpEZXI0Rmp5T0txOFhZeUt4dDZsRWx4YndCUm0w?=
 =?utf-8?B?YVlCdnRJOHpURkRxL3JEWXFPN0t6d2p1SWZVbndpTHhOQlo5NzAwZE5yeGRX?=
 =?utf-8?B?UzY1K0cxUzh6d0ZGQmhPWWtObjNvaFk4N1VnU2FobVNxODVIdXd1ZDIzRjhI?=
 =?utf-8?B?azgzSVBuZ3oyM0d0RTVPWTdDMEJSWEF1N0VRVmhJclBMQ0ZtUjVsdVBYY09L?=
 =?utf-8?B?L3FmQ2I3TWhFclBRanQ2VytqVS9KSUtNNm1GMGxaU000dWhjU2FmRVREUzdo?=
 =?utf-8?B?QkZ1dFhaQ2NtR2pNSTY2ajZ2MFRsR3VDSTIwR2MwdmlkN3lickxMaXlGVzNT?=
 =?utf-8?B?bENjVHc1d0d6eGJDc2FhVjJGTnJQV0tzSDh6dzRiVzkzMkxUVm45NzIzYnZi?=
 =?utf-8?B?L1M1Z21CaEM3RVZXQlpJOUdxOWdFdG5acFVjSFp4ci9qbjhzb0V3M0hob0Jj?=
 =?utf-8?B?enArN1lyNlg4U3RVTkhORlVKV0s5TnhxR1paWmNtSDFlUEVicFdtQkZPOXBm?=
 =?utf-8?B?MitTY0ZwNFJHZ3RyQThwOW4xN1UzRzBCdTVaankwYUkxQ2wxUTF3WEF6K0Nu?=
 =?utf-8?B?OUd2NmFndVZSd1BOK2N0dms4SEJtK2JSM1MwWnlBVDYrNGcydHhvNW0wTEl2?=
 =?utf-8?B?cU00Q1NPRDcvSTFFMGp4T1hHZ2M5NEFzV1ZyL2tDSENPNDlOQjI1UzNSaU4y?=
 =?utf-8?B?M0dOZnVMZkRKeFBlbHVLZUh4djl5dGlITVpaT2IrOVNIaSt4S2tzRGJYdEJZ?=
 =?utf-8?Q?G7lw/eQNlraSxypABj3neeRlHAtFgE=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?ZkRyVUtqaWZwNHdGampFZmFkYzVKRDVJQlpqVlBodEIrZGtCYzRHak1HcTlG?=
 =?utf-8?B?VXpiQk9NVGpRVElXWHk3QTRMaDJxR0dyeFBONDIydUVYTW15ZGtQSlMrYWJw?=
 =?utf-8?B?cEhGY1hiaXVkN0dTbDF5alp5T2owZ01sT2NzZU1xWGRUQTdndEdrYVQ1bUE0?=
 =?utf-8?B?STQvNFB3ZGNmYUIwakNCcUF2cTcreUdKb0ZMWW5BWWd0NVdkMXJlbE1xNmx3?=
 =?utf-8?B?aVpFdnRVZ01MZ3VYVUdJVGF6R2xUQmZkdUxmNzdqVEFoNkVPVGVHNU9jY3Iy?=
 =?utf-8?B?cjU4MFpURGFDdFM0TFdJUlA3cFJ4TWtlTXozblc2WDRHUW8vbXVHbW9DNkhw?=
 =?utf-8?B?UG8zaWJUTStENEpqcGpNMlJaei84SWNKMkpwaFNGVjVzUngrT1JGVzBLTzdq?=
 =?utf-8?B?SXNWZmFxMU9tQzYyTXlXeEZxRUFKL1NjWk9SS2tmcGxTeDBId1lFMTZVWUwy?=
 =?utf-8?B?QkVuRC9hdGtHbGVsTzMraHdjZU9uc1hMTVN2MTdvRlFCTzgraDhTeG9udi9h?=
 =?utf-8?B?OG1oYUJPaGU4cmdwVmlzUjM2VUxTTlZPYUk0NUhKVGovWFNmTUNDZ0djUG1I?=
 =?utf-8?B?dXlabnBwRlpGUEE0dzBKd2pmNXdHZFo4T3AzNTNsTEYxZ2VENEloa3BIczJJ?=
 =?utf-8?B?bEFaRDBQcEV3VzA5TnpzcVFWdnpuY3V5MFlSVjk3TmZpamIvZXdIUzYrV2tF?=
 =?utf-8?B?OTRsL2pFczE2OFFad0NleUdkRk1XY21oNEg0SGdFdDhEMXBTK3lFNllvWHcz?=
 =?utf-8?B?M2UvZVJzS3JJZVVpSXpoWWFXR3dTVDhJK2Vyd1FMcUtqQWlWaHpCUEZjWG5t?=
 =?utf-8?B?bVhZWjRoUHhWd0grQmd0c3NYTXZOallTUXEvU3RZSjlubkh0dlBBRFRxcWtN?=
 =?utf-8?B?R2l6UTBQakpvSzhTMy9ieVF0TXVNQVVaL01KZENlUVNXOTBraU1SbW1TSFI5?=
 =?utf-8?B?ZER2Z3g1T0Z5c29QenlmbEpqTFdRRUwxZ29ZQ3c1Rk0yRFVtLzRNN0dreEI0?=
 =?utf-8?B?Y0VnQThXa1BzRGdOTkw2eEJMb2JVZnBiUzVDUExXelplU2l2cW5kQ0dLVmZ6?=
 =?utf-8?B?cUZzOHYyRFplSlNqVkhvdUsybjA2cUtCOVRXSG81dUs0Z1FGZW1rbFRCclJJ?=
 =?utf-8?B?WHhpR0FSMW9IaWErZ2Zid0puOVR0YW1OaXBEQ1phQk52ekhxaWgxdmNINFBD?=
 =?utf-8?B?OWhKcHk2SW9LMnRMdm10MU13eVBYY3FRNGRzenl3SlZ3M0pHejQ3SmJScWlN?=
 =?utf-8?B?Skh5UmtvQS9JdlhRM0lFenprNzZuUHg4UGVMZlV3Z0FTaE5pc2xndXIrblpT?=
 =?utf-8?B?d2pnLzZtdFJScGZuZlA4c245dzVzUlZHdFNsVU9xb3VMNVdMdlpqZklMTW1p?=
 =?utf-8?B?L2FyQm5CL0dWeTdOeGpaNDU3OXBkWlFTOVhjdDVaZU0wb2ZxNnB3S21MbzVM?=
 =?utf-8?B?TG9WeDhyT1VSMDZsY081T0Y2VHhsbmptU2RpVW1HUUNrWkdxaWVramJtVWtv?=
 =?utf-8?B?MUJoYkVhVjBaQ2djR3pTQXRubDhoV2JDL2V2WkxCczNCVmNJVHQ5ZDNpRVVF?=
 =?utf-8?B?MUdFN1ZFNzRvNVhwNU95SjdQb3VicUU5SWg5aWRBSEJrOE4vcktpWEdYRVQ3?=
 =?utf-8?B?L0hqYVdPbVRyaWd2YmV6eHpFUUlBVFRuSVA0NXFzcXVtWjBNdzFlYno1QlM2?=
 =?utf-8?B?c1N1b1NISjk4YitUWW0xNHhoSGI3OTJ4dUxnOXBwS1RZWHFvMnE0c25FcDJj?=
 =?utf-8?B?MTlyNFNxQ0xSQ2w0WjM3RTZQaGZuOERVNFVVQWV1Vi9kRVRXamhiZW9HUUFp?=
 =?utf-8?B?SFRjUkQ2NWVNTzM1U3UzNDBMQ1B2dGRrMzkwYVZQaVppbFBlTnpCSStrSURB?=
 =?utf-8?B?NklLWVR6MUM1S2lZcnRXMkN2aVNsQU12d2c0d3A4UFhiUzlnWkpBYmtQL0xX?=
 =?utf-8?B?VUhLS1FkQ2piZW1senpPQXdMWVdablJmMlp1VzJ0b1p5bm1DUXEyWmZ6b2Zw?=
 =?utf-8?B?TXBienh1Smg1THRuMHN0YTB2YTJkUHozVUlHdE1JbGJQY25nOXNyUlZiV3JX?=
 =?utf-8?B?NnZDWlRJQ3ZCWHRsNzdyK0NvbnFUSm1teG00TDNMNWltdGpQSkFYY2tYVDM5?=
 =?utf-8?Q?+lRU=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 69ac9a9e-70d6-4db1-2cff-08dd96a077df
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 06:43:30.6451
 (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: eJooO3xux8skForNKY5rgIp3m+xNyIi6GmrIWm1R5XF1kboGv/TTlZUJR8bV9GSiHyDBfezp5sZIgZWVUOxDQA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8977

T24gMjAyNS81LzE4IDIyOjIwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMDkuMDUuMjAyNSAx
MTowNSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiBAQCAtODI3LDYgKzgyNywzNCBAQCBzdGF0aWMg
aW50IHZwY2lfaW5pdF9jYXBhYmlsaXR5X2xpc3Qoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBDSV9TVEFU
VVNfUlNWRFpfTUFTSyk7DQo+PiAgfQ0KPj4gIA0KPj4gK3N0YXRpYyBpbnQgdnBjaV9pbml0X2V4
dF9jYXBhYmlsaXR5X2xpc3Qoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiArew0KPj4gKyAgICB1
bnNpZ25lZCBpbnQgcG9zID0gUENJX0NGR19TUEFDRV9TSVpFLCB0dGwgPSA0ODA7DQo+IA0KPiBU
aGUgdHRsIHZhbHVlIGV4aXN0cyAoaW4gdGhlIGZ1bmN0aW9uIHlvdSB0b29rIGl0IGZyb20pIHRv
IG1ha2Ugc3VyZQ0KPiB0aGUgbG9vcCBiZWxvdyBldmVudHVhbGx5IGVuZHMuIFRoYXQgaXMsIHRv
IGJlIGFibGUgdG8ga2luZCBvZg0KPiBncmFjZWZ1bGx5IGRlYWwgd2l0aCBsb29wcyBpbiB0aGUg
bGlua2VkIGxpc3QuIFN1Y2ggbG9vcHMsIGhvd2V2ZXIsDQo+IHdvdWxkIC4uLg0KPiANCj4+ICsg
ICAgaWYgKCAhaXNfaGFyZHdhcmVfZG9tYWluKHBkZXYtPmRvbWFpbikgKQ0KPj4gKyAgICAgICAg
LyogRXh0ZW5kZWQgY2FwYWJpbGl0aWVzIHJlYWQgYXMgemVybywgd3JpdGUgaWdub3JlIGZvciBn
dWVzdCAqLw0KPj4gKyAgICAgICAgcmV0dXJuIHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ks
IHZwY2lfcmVhZF92YWwsIE5VTEwsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgcG9zLCA0LCAodm9pZCAqKTApOw0KPj4gKw0KPj4gKyAgICB3aGlsZSAoIHBvcyA+PSBQQ0lf
Q0ZHX1NQQUNFX1NJWkUgJiYgdHRsLS0gKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICB1aW50MzJf
dCBoZWFkZXIgPSBwY2lfY29uZl9yZWFkMzIocGRldi0+c2JkZiwgcG9zKTsNCj4+ICsgICAgICAg
IGludCByYzsNCj4+ICsNCj4+ICsgICAgICAgIGlmICggIWhlYWRlciApDQo+PiArICAgICAgICAg
ICAgcmV0dXJuIDA7DQo+PiArDQo+PiArICAgICAgICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHBk
ZXYtPnZwY2ksIHZwY2lfcmVhZF92YWwsIHZwY2lfaHdfd3JpdGUzMiwNCj4+ICsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgcG9zLCA0LCAodm9pZCAqKSh1aW50cHRyX3QpaGVhZGVyKTsN
Cj4gDQo+IC4uLiBtZWFuIHdlIG1heSBpbnZva2UgdGhpcyB0d2ljZSBmb3IgdGhlIHNhbWUgY2Fw
YWJpbGl0eS4gU3VjaA0KPiBhIHNlY29uZGFyeSBpbnZvY2F0aW9uIHdvdWxkIGZhaWwgd2l0aCAt
RUVYSVNULCBjYXVzaW5nIGRldmljZSBpbml0DQo+IHRvIGZhaWwgYWx0b2dldGhlci4gV2hpY2gg
aXMga2luZCBvZiBhZ2FpbnN0IG91ciBhaW0gb2YgZXhwb3NpbmcNCj4gKGluIGEgY29udHJvbGxl
ZCBtYW5uZXIpIGFzIG11Y2ggb2YgdGhlIFBDSSBoYXJkd2FyZSBhcyBwb3NzaWJsZS4NCk1heSBJ
IGtub3cgd2hhdCBzaXR1YXRpb24gdGhhdCBjYW4gbWFrZSB0aGlzIHR3aWNlIGZvciBvbmUgY2Fw
YWJpbGl0eSB3aGVuIGluaXRpYWxpemF0aW9uPw0KRG9lcyBoYXJkd2FyZSBjYXBhYmlsaXR5IGxp
c3QgaGF2ZSBhIGN5Y2xlPw0KDQo+IA0KPiBJbW8gd2Ugb3VnaHQgdG8gYmUgdXNpbmcgYSBiaXRt
YXAgdG8gZGV0ZWN0IHRoZSBzaXR1YXRpb24gZWFybGllcg0KPiBhbmQgaGVuY2UgdG8gYmUgYWJs
ZSB0byBhdm9pZCByZWR1bmRhbnQgcmVnaXN0ZXIgYWRkaXRpb24uIFRob3VnaHRzPw0KQ2FuIHdl
IGp1c3QgbGV0IGl0IGdvIGZvcndhcmQgYW5kIGNvbnRpbnVlIHRvIGFkZCByZWdpc3RlciBmb3Ig
bmV4dCBjYXBhYmlsaXR5IHdoZW4gcmMgPT0gLUVYSVNULCBpbnN0ZWFkIG9mIHJldHVybmluZyBl
cnJvciA/DQoNCj4gDQo+IEphbg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Mon May 19 06:54:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 06:54:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989546.1373561 (Exim 4.92)
	(envelope-from )
	id 1uGuOX-0006Mj-1E; Mon, 19 May 2025 06:54:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989546.1373561; Mon, 19 May 2025 06:54:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGuOW-0006Mc-UR; Mon, 19 May 2025 06:54:40 +0000
Received: by outflank-mailman (input) for mailman id 989546;
 Mon, 19 May 2025 06:54:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGuOW-0006MW-A9
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 06:54:40 +0000
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [2a00:1450:4864:20::432])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2175e4f1-347e-11f0-9ffb-bf95429c2676;
 Mon, 19 May 2025 08:54:38 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a375888297so100988f8f.1
 for ; Sun, 18 May 2025 23:54:38 -0700 (PDT)
Received: from [192.168.61.201] (server.hotelpassage.eu. [88.146.207.194])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a365bc0b5esm7928041f8f.9.2025.05.18.23.54.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 23:54:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2175e4f1-347e-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747637677; x=1748242477; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=pr/iOLFC9VrC0CSrvGh5HRaU41gZYri8cVgn+uBHz/E=;
        b=JPog3QbCxOovxaAe+S2jHjmGHD96351FEbsC5xCwa17kwgY5PscURc2P8aaZNBFt0s
         9HvjMkewhVXepJ+XhF8hmiS4z/8hxWHe7MIKJ72AwUQ0NStmp+BtVq0ldMPlFThtdBIQ
         POzMlgZosnGxn8QUwuU9ekITRKJg4be03yiIWoD61uOBpuSBHuAVXpq9ob0CTZ5187gs
         0nrjv6HMMtBNwMi+5gzG1l2GOmNvI+QC/Zy123GdG9jkABDlVgF6QoTvsp/gvyRqhL/D
         E7uTiGzXJ79pt9cyjnhXYXLSP7CIuZk2UD495di1CPhMwaW7SDZoody0WUNq7/0LWUaE
         yJdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747637677; x=1748242477;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=pr/iOLFC9VrC0CSrvGh5HRaU41gZYri8cVgn+uBHz/E=;
        b=UPMMx/zAH8Nq8d3bHSt97tMMPYOfpQzLQKp18WN0mCg0KFyd0cKO+pcaBmA3eAyJID
         BRiUCW/Qd0NKDMve8u/l3QofwnU+QDNKqoj7wfqiK6y+xfBnbSLob3NE5fdmWfCIrsBy
         6U13NKB4uAFzXWdxtXmZK6VwY3djRLA6g3ag71au9s4AGrauOPhLOaN7o5zk9LswWbUO
         1cMZvmufMcMSgSJvLF3wbq1+Yzs3USLSluKuGXp+MGlnhf5WEQaNN2tprgZRRb9zWgvs
         20/V82Pdc7jI0RURMCQ9Q2t2GlxUzfpGJGYu5uA0/zF5VozLIQt1RFG5F4lhHItpsK/n
         Kgbg==
X-Forwarded-Encrypted: i=1; AJvYcCVBxzzPGX/ClPp/DgebExTxn/1eTRbbU4WUMoHTpot0ambQK56UICqR3Olbor7IW1GmaJj6AP5xKnc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzyxAwUJbdXvp6KdOoIx1kwHRpsh8MCVP5jGXn5+z1XGARpjh15
	BwVRmANdrfMTKuj4Ti2aArxyEj7drTEDkp9DXxKNvAro2/03lf4ZJCnY09BGxEi2QA==
X-Gm-Gg: ASbGncs/QONFxzTOxPQw0qUE+L8paMC7BuMdtiRly0diokGhbwFSneJNt4HxcHTiFZU
	8u54YOgi3u5GkRru4pB9bYbXt+lX5gWjXCrJNf8bOggJz+ooJWPo3rXvSTdyVeIL+ouWjuUCujJ
	qUXsqB17S0NqSssdIu00R7aYPoObgOrRmAsnV1JJVhB4hQkn6AvWtiOSx1BLHajhYu7kYER/jjg
	90++9qS+ano8Lb0fJOwgvN8biQdunPNdv9r5L3xzhFl95FdKyxTLddzzVKIQ/5CtPF7kpCtrjV2
	3nqs99F129aNIV6KhPth+Q1hRvk9WQsAJoZ6W8XZAytspAM5z3WBW96UyqysNan9QNOxxbebMPq
	tOB0fZAsUUw==
X-Google-Smtp-Source: AGHT+IH2YRVb8UqkUzFnfg7RZAW1DJuyyPc4TGKbWXhxn0wFbbMTEolC1973kmTtkGu4/kDUHXqayA==
X-Received: by 2002:a05:6000:2507:b0:3a3:6a8d:99c4 with SMTP id ffacd0b85a97d-3a36a8d9a33mr3825445f8f.27.1747637677600;
        Sun, 18 May 2025 23:54:37 -0700 (PDT)
Message-ID: 
Date: Mon, 19 May 2025 08:54:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 08/10] vpci/rebar: Remove registers when init_rebar()
 fails
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-9-Jiqian.Chen@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250509090542.2199676-9-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 11:05, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/rebar.c
> +++ b/xen/drivers/vpci/rebar.c
> @@ -49,6 +49,26 @@ static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
>      bar->guest_addr = bar->addr;
>  }
>  
> +static void cleanup_rebar(struct pci_dev *pdev)

Just to remind you that any hook functions need to be cf_check.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 06:56:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 06:56:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989552.1373570 (Exim 4.92)
	(envelope-from )
	id 1uGuPu-0006rK-9h; Mon, 19 May 2025 06:56:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989552.1373570; Mon, 19 May 2025 06:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGuPu-0006rD-6h; Mon, 19 May 2025 06:56:06 +0000
Received: by outflank-mailman (input) for mailman id 989552;
 Mon, 19 May 2025 06:56:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uGuPt-0006r7-9Z
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 06:56:05 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5448ba20-347e-11f0-9ffb-bf95429c2676;
 Mon, 19 May 2025 08:56:03 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43ede096d73so27664965e9.2
 for ; Sun, 18 May 2025 23:56:03 -0700 (PDT)
Received: from [192.168.61.201] (server.hotelpassage.eu. [88.146.207.194])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442fa3e2ce5sm147368205e9.13.2025.05.18.23.56.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 18 May 2025 23:56: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" 
X-Inumbo-ID: 5448ba20-347e-11f0-9ffb-bf95429c2676
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747637763; x=1748242563; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=X0/GKlPUvMupEP+ImHEQUJ1iTl4muMylQqwc7FvNiE0=;
        b=SawvEYuTanQARkZHTpBWdj8rn1gkvtYTIy8vOBK0lGuyyjmqeCAgpfupAHRO/ahqeR
         Q5sYDiW2CW361MqGXwSywjKefbWkKl/6GycwPkhVWvngGhPUIP8oLkw+Mkai0PiiQGjW
         MAfM1iQn1p1PcZMy/C1e+DhCZjIzmT7qEfUGvABjFajJb7wPfJQBuPW0ZYo5csVB6G2o
         1i8e0zqbfnFoKc5n8YhBTn+75yoI9Z4cyTuAchHPC61KuByXWBmbkq4i1HaFBivX1qzm
         5rOfgHjB0FubNDECYT0iQhAIZ47bYN5nz1ZFW5PjQ0PZxrzl/o1G6EbWNXRUW+4dAW/6
         omQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747637763; x=1748242563;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=X0/GKlPUvMupEP+ImHEQUJ1iTl4muMylQqwc7FvNiE0=;
        b=vg0Sb89Qq89RbMbI84qFdBOcr0XSrolfqn8YhXr/fycu8QtXruBAfpEE1kvGpAi/O3
         1uGcxdBi5+802UmBdlGlKZ7BUVMbc6heNHYH7yIMLa1My+mzJYQekPVwvvhVwvSg5tml
         5i+hmiOGXiJX2RlAU50o/wqiwhhVA2j46NmOiTbn51q4D9kEUm6lQ2YKql6DOCnvv1gM
         i8jS4UO8+2VN0iuOL2UZQ0ImiSHti11wDk3b28mvAZUmduJQ/ByaHdNL10jUvKgfcUDz
         O1niHIrln3+2bQlwuz7vvMrYziPLuC+nOUn1CYjb5+Ie5p+AGxcgz+N/gKOBo6/ifnDo
         SaTQ==
X-Forwarded-Encrypted: i=1; AJvYcCVPCN/HnuXz+KizVmMO7w7XM+vSmYXaHnl780V34SEBuaz0CLa8yY16PWMtwFtiSehmFG4Y89/nIkQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyww6mnGq+SMAul1f5pk7MOjLf9li2tfUA9b5xMPP/HHRxmAxui
	PeoPvSgd2XOEhHAL1SRq47VYaUguwqHVQMFvAZo8wXYzQ/ZHVfywoPF69VgeeFsIIg==
X-Gm-Gg: ASbGnctu5O2gWFxPGyjnNUiZq5O8xf1tSCCqIs/YKHD8o71cJs00SE8EgNpIlINkmPa
	z/d5o0+jt0GKRE770Eoijk+aIdoHslj6YA4TCcjMx3z4Cl+D5CkfJrgQizoi9re7Sq/zohSnsRA
	hxZx9wqFyxsP7nzy84lPdknB1ll4fy/6k6vVHewJ14Y6tAxBFRgYPV8x8VQahUn+e0eEZPferbo
	nNyBF72JPU9dzy7eiUB5l1u+98BadNolGgOwrFrhkBsnK2l2ay1sB6TpI7L8DdNTgwcGcbgeDS4
	KDrRAsOPsNQU33mHQHOqL3fgmkgXtnP3CCky6cRMa144auEjco6vbPk9+Xp6/OHwvYOOWQguoMs
	eSYUgrQOxWIUHMpVbwK3u
X-Google-Smtp-Source: AGHT+IH7v/Sxv1+T2Zg7DXIuADO4w8Glt3dyNf6FH7kbDHDkSg+Znm5kKu7jYQhu+KD9XFq2gjhpSw==
X-Received: by 2002:a05:600c:a378:b0:43c:f70a:2af0 with SMTP id 5b1f17b1804b1-442fd64dfb3mr138504055e9.16.1747637762880;
        Sun, 18 May 2025 23:56:02 -0700 (PDT)
Message-ID: 
Date: Mon, 19 May 2025 08:56:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-4-Jiqian.Chen@amd.com>
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 08:43, Chen, Jiqian wrote:
> On 2025/5/18 22:20, Jan Beulich wrote:
>> On 09.05.2025 11:05, Jiqian Chen wrote:
>>> @@ -827,6 +827,34 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>>>                                                   PCI_STATUS_RSVDZ_MASK);
>>>  }
>>>  
>>> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
>>> +{
>>> +    unsigned int pos = PCI_CFG_SPACE_SIZE, ttl = 480;
>>
>> The ttl value exists (in the function you took it from) to make sure
>> the loop below eventually ends. That is, to be able to kind of
>> gracefully deal with loops in the linked list. Such loops, however,
>> would ...
>>
>>> +    if ( !is_hardware_domain(pdev->domain) )
>>> +        /* Extended capabilities read as zero, write ignore for guest */
>>> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
>>> +                                 pos, 4, (void *)0);
>>> +
>>> +    while ( pos >= PCI_CFG_SPACE_SIZE && ttl-- )
>>> +    {
>>> +        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
>>> +        int rc;
>>> +
>>> +        if ( !header )
>>> +            return 0;
>>> +
>>> +        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
>>> +                               pos, 4, (void *)(uintptr_t)header);
>>
>> ... mean we may invoke this twice for the same capability. Such
>> a secondary invocation would fail with -EEXIST, causing device init
>> to fail altogether. Which is kind of against our aim of exposing
>> (in a controlled manner) as much of the PCI hardware as possible.
> May I know what situation that can make this twice for one capability when initialization?
> Does hardware capability list have a cycle?

Any of this is to work around flawed hardware, I suppose.

>> Imo we ought to be using a bitmap to detect the situation earlier
>> and hence to be able to avoid redundant register addition. Thoughts?
> Can we just let it go forward and continue to add register for next capability when rc == -EXIST, instead of returning error ?

Possible, but feels wrong.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 06:56:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 06:56:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989563.1373581 (Exim 4.92)
	(envelope-from )
	id 1uGuQd-0007Ml-IS; Mon, 19 May 2025 06:56:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989563.1373581; Mon, 19 May 2025 06: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 1uGuQd-0007Me-Ev; Mon, 19 May 2025 06:56:51 +0000
Received: by outflank-mailman (input) for mailman id 989563;
 Mon, 19 May 2025 06:56:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGuQb-0007MW-OB
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 06:56:49 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2416::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6e1e6400-347e-11f0-9eb8-5ba50f476ded;
 Mon, 19 May 2025 08:56:48 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DM4PR12MB8521.namprd12.prod.outlook.com (2603:10b6:8:17e::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.29; Mon, 19 May
 2025 06:56:43 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Mon, 19 May 2025
 06:56: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" 
X-Inumbo-ID: 6e1e6400-347e-11f0-9eb8-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Z94nIBkFTZXUlyosrVAFp2DqYSPmijXAbTfmObcTkg8YAAccwGW1EKJcdfiGc8/BmF1OumqEpSP+n5x5oR7hxOg/06BMorWlXn8935P2UeuP3b5b2DGWtNo2xAUNmxXrsarFFCnXSs/S8av3uS12XWgorsWTsmcDZw3QbvCeUh8zEmrQCRpfBRq69/jacLTR+kI4H+KoRBi3bP9Rc1H1Af5jchzJQMIdG9Vmz7MSOAqAsRCebpWrSBMV27pA5jnuAey1vcSKAKx8+65Shz9g2wqsFq8vUwJkNol9V7CAfRzPGkAHNog4zx2gqkJH8oibmw0V0Lzi0F1QaF+p+zrfww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=i9G62P8oHYyiUEUDnOfD0dm4XEvzJ84cb5JldgKZuIQ=;
 b=rjk74wjzRocWZcZcWJjvq3fzj5BVu0hsTkcTNQK29d1jcwAqbf39AJpFHgFPHu1tU1zE/qG7a4fvP/ouNJaWz5OtIYoG0NcFdeTJqqsEcs0z0sPHKnwikw5eSnhxDplM0vCf+cNBf4O3N+WlvrLgVUfEegFyCzLhWWZDrIU0W/P0FzCvuEvTmcJv2us7Hg5J99zVoCg8dMzA25kxe5DPwKN8MqzX04rH922rfbBL+sjmbOKSZYIgDPfZQk4Bk7SmZmDVo0SoBTwl4qoQtRYjIFntcU8YnHTlxHp8LJ5CLSx8yhZ1doY27l7b00j9iAcluLc0lWtDPI8JqegBeeSfMQ==
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=i9G62P8oHYyiUEUDnOfD0dm4XEvzJ84cb5JldgKZuIQ=;
 b=259ipl2PlCd1ja6fl2znJ3/Lb/xzHvZzO1aWDZsvHtJDxlpY/6JeLL2r2hO2OeXbaVRbGfc4Y0iRDaxBqsB38vdgOuwTNlvYHLkFBzlum1JIx+UwvLLZd+qEdOk0M5Ykh5oib9cVSZpYrb64/ig8eqDw3PiEkzsfNazKAtRF4nI=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v4 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Topic: [PATCH v4 04/10] vpci: Refactor REGISTER_VPCI_INIT
Thread-Index: AQHbwMGgw07cR2qhKk29BPmLZ9E3lrPYgkkAgAGWNAA=
Date: Mon, 19 May 2025 06:56:43 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-5-Jiqian.Chen@amd.com>
 <0a6f40a9-a0ea-4652-8692-acfcf873463a@suse.com>
In-Reply-To: <0a6f40a9-a0ea-4652-8692-acfcf873463a@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|DM4PR12MB8521:EE_
x-ms-office365-filtering-correlation-id: c4bd096b-f74f-488a-fd3a-08dd96a2506b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?K2l4YzVVS1ZDVkV5VElKanRtOGZuODNZL2hYQS9LbEtkZVlFa2FDaERsYS8r?=
 =?utf-8?B?SlROV2dJVjhZWU5kS3ZDV3B2a2J0YU1Sby9zR1RHUzRXak50M0lXMy9TOFBT?=
 =?utf-8?B?eTNWclVGVktBN3M0d2Z2cjRDNTZlWVNqNTFHUFgrelY3LzFGVHVPR25BR1JB?=
 =?utf-8?B?a005ckRJVThIVTlMN3dtVTlrVXczY0tPcGNQK0l5YXNKREo1U3JDL295OFlo?=
 =?utf-8?B?dEhobUJ0K0RvMk4zRlNFb2pqeTlwcnJ0TzloSm9ZRnhLNzNucmcvU2ZZcWFG?=
 =?utf-8?B?TjU3UkFac3VSdmlabHJ5UTR6NmZPR3FiaHRuYTdXdFBmNmtXNWg1NVc2am5s?=
 =?utf-8?B?VHFUZnY5NUxjKzFFM1g1MjVxSjVTVXUrQWpockNoZkpzbjA1QXprU3NtUTFC?=
 =?utf-8?B?ZkpFd0YvdXV4cnZPMXIrSHJydGRJd3F2aitnR3BnaXlIS3hucDlqSkVpVERM?=
 =?utf-8?B?M0pRZC9hRjVKOTJVeEJhN0RIbkM2RnpybWJPZDN2dGszdnZaMU9CVzdsUUFP?=
 =?utf-8?B?K3doUnprN09heGhBSFRVSUZKeXh0Z3p2ZDhybGhFTisrcWNCQWg1MGJWbEo5?=
 =?utf-8?B?WTM0bWdZTkpVQ29QM2pCWEhpUmNlT0NkZno2OUhTRXRLMHhjSFgxWkpOcVMw?=
 =?utf-8?B?QXIvT0l6M2duOHJKOGlOQnBvVDJ5SU82bGJZY2FqS2FIUXdrSGo2dUh0dXRq?=
 =?utf-8?B?ZkV2NmREcG9Ma1ByaXRaM0NSOGo5bVFyR2lpdWdDMnhXdTFoenJITk4zRnl2?=
 =?utf-8?B?TGtaSDJiRWRmN0xBRnpQL3ZrTy80Ryt1RUlGS21QRUpzR3hrcnhjdXdCRmtP?=
 =?utf-8?B?VTZScklFVWJ4WEFYWEhQZjBKRzUxUnFHYW8vS2NzZ3ZoUHhzajVvVmQ5dHVI?=
 =?utf-8?B?V2lhRVRMQWFnc2NpV2FiTU9JTENTd0lkMUlnY0ZVTUtGN0VXOVJPeUIwSkxw?=
 =?utf-8?B?QkdET0xPb3NsSVZHWjcrSXFHZGFtZWpva2JwOXdkTlJqbko3c090Q0hQM2JZ?=
 =?utf-8?B?S1JibFRjNWFlZmp3STZGWkZsT0g2ampUbjRzUzE5VVNQYTBQSFdydmozWkxF?=
 =?utf-8?B?M2tNTVFXaXZ0RzhPdldyTXlROUxFVTJ6VDI4M1ZZMnhhZkdEY0VKRk1yZ3FI?=
 =?utf-8?B?MWlERDVzS2pFNjkwUjNid2VLeG9oSkE3MDkvNmRqT2J5WW50ZVQrZWpndXlU?=
 =?utf-8?B?dVY4MnR0VkF5MzBUemF3ekdaTStQTmtNRmo0RmxoZkZvWXJUc1VvVEd6SmdK?=
 =?utf-8?B?KzVRdGFzWkZPd3NiYVRyNS8zNzhYTDA2Q0RBODdVWUtCcHUyWC9CbnhSUFk2?=
 =?utf-8?B?N1Nha2ZZYkJwbVg2RzRWdVJDUUphSXk0Unh2QWJlbHBmYXNvYWJkUHFrUHZR?=
 =?utf-8?B?bDFUd2VKaGdRbjZVSGFTZ3ROZ1lTQTlYUGtoUWNqdFg4SUZyUmF3cVJmM2Fi?=
 =?utf-8?B?S2p2S2pUTnUrdXdmTVNZKzAxZzRoNHl3TVNQMzVRY2o5Nk1vR2E4ZzJUVHNI?=
 =?utf-8?B?VU9UQU1jYjVhb2V5a1lydWFiTXNEZTdiM2VkTFJFeklqMHVLNHRYc254YlN2?=
 =?utf-8?B?SVFveG5yTVg3VGp1ays5TE1QTUxsSnIyblYvZkpjUVEzOE1QUVdUdDNLYnRP?=
 =?utf-8?B?Y2NkQXQyTktqeFEycGdFUlpBYlZsam5sMGo5dkRrVEE5MnA3aVp6RVUwUTN4?=
 =?utf-8?B?WlQ5MngwaTlET2J2MHV1eHFiWW5QYk9XWUZzRXV0WTQvaWtqNkF0Uk1GZXpF?=
 =?utf-8?B?VDlDQUhqODhuY3lqRFJZUFBsc0F2clREVDJVMWhnUkR2LzRJN3RyTUZ5OTRS?=
 =?utf-8?B?TUhobG9uMkVDWkl3WExLcVRXamhLWlNWVDNWRkdEanREOVIxVTd1Q2J5TGhl?=
 =?utf-8?B?TmUxL0NGRm94NzREb2RuU2tKNGxQSWRSczRKZTVlVDIwUk5iRUxtdDJDM0ht?=
 =?utf-8?B?SjVXcEhiY0l2V1pFb3JyOUZKZWdKVUxaWkxXa3Rud2l3cENyUHdXby9zeDVN?=
 =?utf-8?B?SWZVRVUrSHJBPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SHV2UzFCeFI5MDE5QXlqOThlWVZUUXp2T05KQ3ZML2d6N2tDV0lUMW5TTHNS?=
 =?utf-8?B?d0lIY2hobS9lc0txZ2hKeHdlSTdXRkNCbHlpOXBSV29JV3NNR2RqVG5SS09p?=
 =?utf-8?B?eVVxK2tPaTlvTHlyeXFSTDJXeE4xeTdUZTRRaXBOWlVndGNTb2IrS0ZORlQ5?=
 =?utf-8?B?Z2svaEg5T1U4b2ltYm1VYU1JTDB6VUkvdXAyc3czOWNyd1poN3VBYjJEcGJz?=
 =?utf-8?B?N1QrR0R2UUwzNnU4L0Myb09kbWxaNFJleEhEd01hOFZySGJVa0dTQWlVOUx2?=
 =?utf-8?B?NHg3VTh0YjRxS3U0azA4SmdzNFU0eGVtZTMzMnMwNEdIcFhXQzN0NTVSWnpX?=
 =?utf-8?B?OGFJbFhsOG1Dc0QyNU8rS1VHM3ZXTlFlN1V4K3dGUjhUdnZqTzB0b1ZNNG81?=
 =?utf-8?B?SENjRzM5NEE0ZVRrSnJjQnpUMWMzT2k0ZVNtbVJwd3EzMHFPc1V0VFludXZi?=
 =?utf-8?B?eGNtVW1jM3FiRWZudGRkRGNMRVcwL1BkMnRIdW56bWUyOGRFdk1SWDFwUGtW?=
 =?utf-8?B?NGVWanlaZTJJektydDk4Smo5VC9NVEE2SjNzVzVRTUhXNFhoQU5qSy9UT3JL?=
 =?utf-8?B?eDl4ZzBkTFRmTFJsemZYR3hVeFV1Z0V2ekNCVktMYldmVGFoUFJsYTJTMzhv?=
 =?utf-8?B?SGYveE0za0dya0syZVNWL3ZISHFmUjdqbVUvY1RqWExVUGNsYTJwV0VobnE3?=
 =?utf-8?B?VUwvcXpIZnhxaUx3KzhaUExONVpYcjZRcjRPUG9KUTFOMmp5d3hoMzN4WWZJ?=
 =?utf-8?B?SGM4NGtHUjE0ZjQ3YVhwczF2V09NcStnaEdNSU93SkNSbHVDZUNiTEViMmU1?=
 =?utf-8?B?SC8vbWFBSkVRUUNHUUlnZkNaUFEya1U1VXN1T1FCUGViYTFkaERMeUJPQ0FZ?=
 =?utf-8?B?OGVRdngwWnUvbVNuTDRHUFkwdUpjNU4xUGtmaDl4dDY4NlQ0c280V1l5ZjBW?=
 =?utf-8?B?RWkyM0U3dnkyVnpEemZnUDJtS04rWGN1S25OY2piWHhEYWY0SlF3ektrNlE2?=
 =?utf-8?B?Z011RkN0ZEErZG5ESnNZUHR1c1ZkZGdaTWhwOFlycnphb0dHK0RiVElaMXox?=
 =?utf-8?B?RGdzaHlEa09admp6RnpyR0FvdDZET01iekN1SFFzQXd1TGlyazB1MlZwaGg5?=
 =?utf-8?B?NDkyN3dUNjFwTGpGVkdOYXNrY0FQVUVNQkhobG1UeDF6VGRyL3RYTXFKMmtu?=
 =?utf-8?B?M002c2F5SzQwSzhjWjNXamRkNjUyTmIyaE15eGF6Z3pabmQxZ0NlVHhGeVR6?=
 =?utf-8?B?YVFoU2ZRbDVwVzFhT3hpNk9JbUdObzBnOGNCUWJad0FrcXhaR2NDUXJtcVB3?=
 =?utf-8?B?VmRNU0s2RXFLVGRSQnZBWmprOEVQZVdMejZFOFd5dmZXWkRoTTdYK2RwbFRO?=
 =?utf-8?B?ZnFOUjVEMUFLZ2x5aHhiSFhIWFZnWmNnZERlYktqbllSY1NTaGVSS3RpOU5H?=
 =?utf-8?B?QUVIZzl0bmo5M1VqS2NLSko5VDNQa1BQZ3YwNXM1K2FReGQ4aUdjSjlvTzJt?=
 =?utf-8?B?L1EyV2VkbkNVTktFY1p2WmhHZmt6Ri9yZkNUK21HZWJ0WkpHeXlUTWRRN2hM?=
 =?utf-8?B?RGRsWEp2ZkVSSmVMRWdXYTd1NDVseS9VOW05Tm9XU1FuVG4rT1R2eXBwL0dW?=
 =?utf-8?B?TTJoV1AzdVdvRXlqdkFXR3h1d2FEZThTemNJeUFMdDM1SDFuQU4vWmJOc293?=
 =?utf-8?B?YnNHVTZyYnpyWER5RnJYRE9ueDZRY3IzT3dFRXdieU9MaDRWZ2ZLTXhYb0VZ?=
 =?utf-8?B?dlBPTGI3aTRKdnY4RURvZ3BhMWRxQ2pENStLQVlmeS81andrV3ZPd0g0OWR5?=
 =?utf-8?B?RXpHMEpiM09Mc2JVYXdDek9WL3NtRWtwRmpYVTN6cU1mOHJRSDN0WG9BdlVL?=
 =?utf-8?B?VFZUb0F6bWZDMTkvTUZPOTdGbjdudjFWUWIzVUZibllnMkx0K2Rqdk5IM2FQ?=
 =?utf-8?B?RS9naU1kbW4vVFc5VlNDZzNZTEtvRFI3OUhSK0pkU1g0SkcrS3lXbDBJT0Ix?=
 =?utf-8?B?bDFWeVZCVDNMVTV1cTNpbVRHYVR0K1BDWGpsMURnWngyd0QwL3NxQWVaVnpR?=
 =?utf-8?B?bXJWa3JWUVI3NG1xcmx0cGdQS2tNbG53T1RrWUd6NkQ2b1huMmd3T2FtVTFX?=
 =?utf-8?Q?v350=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <393478FC4D19D147859D3E78B4B02BAC@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c4bd096b-f74f-488a-fd3a-08dd96a2506b
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 06:56:43.4453
 (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: ld2Mi7KlIJFYnAKbkYpV3rVXe3qsl8OI7CGAFh7pd5wG8r9OKpEJm2jl7cM1zj8NSRMm1gOewskUqHPPp53t/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB8521

T24gMjAyNS81LzE4IDIyOjM0LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMDkuMDUuMjAyNSAx
MTowNSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL21zaS5j
DQo+PiArKysgYi94ZW4vZHJpdmVycy92cGNpL21zaS5jDQo+PiBAQCAtMjcwLDcgKzI3MCw3IEBA
IHN0YXRpYyBpbnQgY2ZfY2hlY2sgaW5pdF9tc2koc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiAg
DQo+PiAgICAgIHJldHVybiAwOw0KPj4gIH0NCj4+IC1SRUdJU1RFUl9WUENJX0lOSVQoaW5pdF9t
c2ksIFZQQ0lfUFJJT1JJVFlfTE9XKTsNCj4+ICtSRUdJU1RFUl9WUENJX0xFR0FDWV9DQVAoUENJ
X0NBUF9JRF9NU0ksIGluaXRfbXNpLCBOVUxMKTsNCj4gDQo+IFRvIGtlZXAgaWRlbnRpZmllciBs
ZW5ndGggYm91bmRlZCwgaG93IGFib3V0IFJFR0lTVEVSX1ZQQ0lfQ0FQKCkgaGVyZQ0KPiBhbmQg
Li4uDQo+IA0KPj4gLS0tIGEveGVuL2RyaXZlcnMvdnBjaS9yZWJhci5jDQo+PiArKysgYi94ZW4v
ZHJpdmVycy92cGNpL3JlYmFyLmMNCj4+IEBAIC0xMTgsNyArMTE4LDcgQEAgc3RhdGljIGludCBj
Zl9jaGVjayBpbml0X3JlYmFyKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4gIA0KPj4gICAgICBy
ZXR1cm4gMDsNCj4+ICB9DQo+PiAtUkVHSVNURVJfVlBDSV9JTklUKGluaXRfcmViYXIsIFZQQ0lf
UFJJT1JJVFlfTE9XKTsNCj4+ICtSRUdJU1RFUl9WUENJX0VYVEVOREVEX0NBUChQQ0lfRVhUX0NB
UF9JRF9SRUJBUiwgaW5pdF9yZWJhciwgTlVMTCk7DQo+IA0KPiAuLi4gYW5kIFJFR0lTVEVSX1ZQ
Q0lfRVhUQ0FQKCkgaGVyZT8NCg0KSWYgc28sIEkgbmVlZCB0byBjaGFuZ2UgdGhlIG5hbWUgb2Yg
UkVHSVNURVJfVlBDSV9DQVAgdG8gYmUgX1JFR0lTVEVSX1ZQQ0lfQ0FQID8NCg0KI2RlZmluZSBS
RUdJU1RFUl9WUENJX0NBUChjYXAsIGZpbml0LCBmY2xlYW4sIGV4dCkgXA0KICBzdGF0aWMgdnBj
aV9jYXBhYmlsaXR5X3QgZmluaXQjI190ID0geyBcDQogICAgICAgIC5pZCA9IChjYXApLCBcDQog
ICAgICAgIC5pbml0ID0gKGZpbml0KSwgXA0KICAgICAgICAuY2xlYW51cCA9IChmY2xlYW4pLCBc
DQogICAgICAgIC5pc19leHQgPSAoZXh0KSwgXA0KICB9OyBcDQogIHN0YXRpYyB2cGNpX2NhcGFi
aWxpdHlfdCAqY29uc3QgZmluaXQjI19lbnRyeSAgXA0KICAgICAgICAgICAgICAgX191c2VkX3Nl
Y3Rpb24oIi5kYXRhLnZwY2kiKSA9ICZmaW5pdCMjX3QNCg0KPiANCj4+IEBAIC04Myw2ICs4Mywz
NSBAQCBzdGF0aWMgaW50IGFzc2lnbl92aXJ0dWFsX3NiZGYoc3RydWN0IHBjaV9kZXYgKnBkZXYp
DQo+PiAgDQo+PiAgI2VuZGlmIC8qIENPTkZJR19IQVNfVlBDSV9HVUVTVF9TVVBQT1JUICovDQo+
PiAgDQo+PiArc3RhdGljIGludCB2cGNpX2luaXRfY2FwYWJpbGl0aWVzKHN0cnVjdCBwY2lfZGV2
ICpwZGV2KQ0KPj4gK3sNCj4+ICsgICAgZm9yICggdW5zaWduZWQgaW50IGkgPSAwOyBpIDwgTlVN
X1ZQQ0lfSU5JVDsgaSsrICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgY29uc3QgdnBjaV9jYXBh
YmlsaXR5X3QgKmNhcGFiaWxpdHkgPSBfX3N0YXJ0X3ZwY2lfYXJyYXlbaV07DQo+PiArICAgICAg
ICBjb25zdCB1bnNpZ25lZCBpbnQgY2FwID0gY2FwYWJpbGl0eS0+aWQ7DQo+PiArICAgICAgICBj
b25zdCBib29sIGlzX2V4dCA9IGNhcGFiaWxpdHktPmlzX2V4dDsNCj4+ICsgICAgICAgIHVuc2ln
bmVkIGludCBwb3M7DQo+PiArICAgICAgICBpbnQgcmM7DQo+PiArDQo+PiArICAgICAgICBpZiAo
ICFpc19oYXJkd2FyZV9kb21haW4ocGRldi0+ZG9tYWluKSAmJiBpc19leHQgKQ0KPj4gKyAgICAg
ICAgICAgIGNvbnRpbnVlOw0KPiANCj4gRm9sZCB0aGlzIGludG8gLi4uDQo+IA0KPj4gKyAgICAg
ICAgaWYgKCAhaXNfZXh0ICkNCj4+ICsgICAgICAgICAgICBwb3MgPSBwY2lfZmluZF9jYXBfb2Zm
c2V0KHBkZXYtPnNiZGYsIGNhcCk7DQo+PiArICAgICAgICBlbHNlDQo+PiArICAgICAgICAgICAg
cG9zID0gcGNpX2ZpbmRfZXh0X2NhcGFiaWxpdHkocGRldi0+c2JkZiwgY2FwKTsNCj4gDQo+IC4u
LiB0aGlzIGJ5IGFkZGluZyBhIG1pZGRsZSAiZWxzZSBpZigpIj8NCkl0IHNlZW1zIGJldHRlciwg
d2lsbCBkby4NClRoYW5rcy4NCg0KPiANCj4gSmFuDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlx
aWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Mon May 19 07:13:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 07:13:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989579.1373591 (Exim 4.92)
	(envelope-from )
	id 1uGuge-0002AQ-ST; Mon, 19 May 2025 07:13:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989579.1373591; Mon, 19 May 2025 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 1uGuge-0002AJ-PY; Mon, 19 May 2025 07:13:24 +0000
Received: by outflank-mailman (input) for mailman id 989579;
 Mon, 19 May 2025 07:13:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGugd-0002AD-E3
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 07:13:23 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20606.outbound.protection.outlook.com
 [2a01:111:f403:2414::606])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id be09f3ae-3480-11f0-9ffb-bf95429c2676;
 Mon, 19 May 2025 09:13:20 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by IA1PR12MB6164.namprd12.prod.outlook.com (2603:10b6:208:3e8::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Mon, 19 May
 2025 07:13:16 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Mon, 19 May 2025
 07:13:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: be09f3ae-3480-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LUjpw2Oz/wxf3guZoQDwG+6MmaHcGrEH37PhLHthydoQReQfHJrEY0Te8aUtQxSqoeaDkdom2ZoYqjil4vCd4HU5G43BiSDDsOqnE+6yV5yQo6fKhNKbIxlCw+l6ajA6ZbMMVoxrlWm7D+mydxtxjmLlKRhXmgxHDup51GlG0Tzm2G14EqkJeNNNg5N5WJCB3iqIxuxGlJPIC9OBDUDE7/UPm0bolrlcPRMSu1vXiwWrO22eQ8ibe4kfFysyJleVJldlkSyyVpNwx7HHW1KprTCP1xPC7TK2vSzwW2y3L9S7iqs3aVFvudsk9Hnb3Zxd5+1qjxnYWqzZKZ5pqWrXOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=J4nvKe0CBxA/dVyOu2C+FTjWdBAchTSRm6oY9xhuMwE=;
 b=ONx2lD+23cY8u9q110xSDtsU+0RMOhA0e0EbxjqUUVfZpmxeCnvypqv8a1O1uIYGzbb5NTd5kmmybNE6a2NiWI4RzTkDLQLs64uid5wYqE44ne1o8Wi5BjTaEeIlROLZfgKnpsKUevtxxE62bLc3f6TZD4tgaDRmyzF7p47oLJmy78I/k4ALG6O8RzGcnQH5lRMWC/+WiRlQq/KZCEI5l7okmTQCs6yEEXFTj+92QVedSRmUWMS4RoS9OTo+GBUKXCCLuMxQItzoNrgI4MUck4i66JCBFF1Sp4f1/pkxOcqlz7O6dBLyHlfjYGsUnNt10HERtuYrhUkz8bYU1d59gQ==
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=J4nvKe0CBxA/dVyOu2C+FTjWdBAchTSRm6oY9xhuMwE=;
 b=qfOeDRpOV9zSPVmyQNU+ezTN2K32qP878hqYD2OGLjhzS3RTv5NsCO0BKrhNK2YzpCDkSyaq9hcZn2D5vxjTtAB+GEJAObq4Yg2vG+zwutjgFLQh/gP2a2KmB4qeJ31KKIFBWA+Gnkz9NNY5xaAIs2jUsOJeT6eo1ptX9qoajB0=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= ,
	"xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
Thread-Topic: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
Thread-Index: AQHbwMGevTfR886wakahq6ntIeNmMrPYfnSAgAGVuQD//4B5gIAAiU8A
Date: Mon, 19 May 2025 07:13:16 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-4-Jiqian.Chen@amd.com>
 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|IA1PR12MB6164:EE_
x-ms-office365-filtering-correlation-id: 9bf50ef0-326d-4fba-7ae1-08dd96a4a046
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?aS9yUzF0bU9tajhJS3pPcGNEVXRpN3FrM2drbUIzWUd1NktLZjBUK29CdWtp?=
 =?utf-8?B?MFkvT2E1RUxza2oxSFV2VDE0emVrUHRBazlOKytCSFlYOHVBVVQxajErUEJn?=
 =?utf-8?B?aW13cnU0MmY5L2F0SmE0V0hldHdYOUtYdWc0QWFZVTFNNm1qSzN0VHBnaGlD?=
 =?utf-8?B?MzJ3WWdiS2RZSG9tYzdJbytDM2xuYmtiMHVaUWtSOUdTaFg2QUc4ZEsya1ZB?=
 =?utf-8?B?ZDdIbkFaTkMvckNoSXFJOVhjNEJCQmdVSGFJdFhqNGMzcTdyOTdiUWNOclgy?=
 =?utf-8?B?M3FvTUpUb29QaC9PUWJFdGhFb1hncEJFb29QRXRxbTBya1pycEd3T3pjWFBY?=
 =?utf-8?B?N05KR0tMVnE4dHF2dXRYTnJKcjU4VnV1S0RWS1FNZ01nbFhGZEJ0ZUl1RXFn?=
 =?utf-8?B?UmZxWTVCb1dmOVNXQ2JQV2VzNTVjbUtldHY2THM0amVDM0dycm1QU0NTMEhk?=
 =?utf-8?B?d0VoTmFhM0JBd3drRFBBTjlXYzRwTXNyczZYNFQyTktpbGs4K2NnN0xDZzdw?=
 =?utf-8?B?WnRLR1VLN2N2Slp2S3o0Ym9iekZhUTdmNkxwMXFKQm45TUplcWRjNDh6VWVh?=
 =?utf-8?B?KzZQSHYra2hVNnd2S2dzUStHL2dwMGlITHdVWWo0RVdHWG44MWtmeWlIUmp4?=
 =?utf-8?B?cUV5ZXJsb2RJdjF3L1BzTHNMRlpsYWh3QUdrYVl5VjhZWXBpYmRwTUFqY1hM?=
 =?utf-8?B?WUFJbkZ5aFN3U0NvcTBwMy9STGlYZmwzc2pMMm9YZFVjSHg5QmZYRXdSaDcx?=
 =?utf-8?B?U3FVWFd2enU3c2pEK1ZkZDRYQlhxVGFibTNZK3Q4QkxzYXhvRGNUb04vNTVM?=
 =?utf-8?B?TWVoL3NYdVE0RHNkQUtCZEJtL0NNQUc2dnEwQlZ2ZGRLeWZNNVVGYzZwejBa?=
 =?utf-8?B?Sk9PS2NtQnNSbnJJR1lPd1hGL0M3REVLWCtSL25QSVhhL0tEb1FoTWcwbXlR?=
 =?utf-8?B?Y2k3RnNiUzl3WFh5d3FDejRvc0Y2d25RZHpIcEMzUktNclViTlNWWk1ZTlhq?=
 =?utf-8?B?MTZVc0w4MTdkNWxGM2FkZjZVWlg4Zkg1dG1PcXlTTE0wd21OUXMwOVBNT3lE?=
 =?utf-8?B?UitxS2dlYUZpNkJQcGZnalBGVjhDTXFjcTVjeVVyVVNZU3ZubjNkYjNFVUxH?=
 =?utf-8?B?M3dTK3V2ZFpYTHBZWU5kSmtTeTJFVjFWWVBVeXBWRnJpSkJ5amQ5bm9SdWNo?=
 =?utf-8?B?akFTQitUWnYxSFNUa0I0ZlE5eTVMQUczdW5HS08rWjVoVktFS3RyTnFubjF3?=
 =?utf-8?B?SjNRZ1RiMU8yb00zR1Z5MXhZQU5MKzhTdDIvb1IvRXIydmt1TjUwVlBmUlFj?=
 =?utf-8?B?WGIvY3F6NHVwSUxsclM1Wm9tZldjUmV2b0VUYlJKdGs5NFhwWHMxWFJweUta?=
 =?utf-8?B?R0loRW1oaVE3eFRNbC9NTkl6VHJvcW9KczJZSEtCMSt3U25oczhVS0J2bVJx?=
 =?utf-8?B?K3RESEYwSWlsSGVoUzJORWE1S2Vlc1BVN2RFdGJvbXFQZFFSS01USUhwMEtv?=
 =?utf-8?B?MVhzRlRkNDFzWGt6b0h0Y1lLVzJiQk5FNHBtemRwNXV4RElwTEpqUDVXbmpD?=
 =?utf-8?B?VHRBdGtuSFhVSFJYejZOOG0vbG1yVHljLythbTgvRjczaVVNOEV0L2J2RDd5?=
 =?utf-8?B?VmV1aHg3UVNQSEtzaXJGZ2p2cForUmxxWlM1Kyt3SEc0MFAzdmk2N08wNHU4?=
 =?utf-8?B?Mm9NbDZaQW5pajRiRExoNURsV2VtMGVvOXhwNW5SOHdhMjNJdTBmL1BKb25L?=
 =?utf-8?B?MzdzNmlvL2tqRkx0RGJQYUdVbEdXTEcyeHlONzR3cCtDVEVURjVvSGx1OGhw?=
 =?utf-8?B?MjNSZ3VPbXlwaFVhYkkxdnRIRXovQ3JkcENJZHFLemYyWjBKaDcyUHZSbTNH?=
 =?utf-8?B?NWd3K0svdUJ0L0dTK1ZmM29BbjEwcUlGQkNZMjVaN3BpMGhZVlAvcEVRdC9u?=
 =?utf-8?B?ei9tVCtsekhzSlNEcEpMa2FQdisrc3dtREx3dkw5VEwxSkoyendOZHdacnJ4?=
 =?utf-8?Q?ujfE+ymbU6jvmo4WQEH3/t5NgWtVmA=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?YnZCSFRxWDRScldTY0JtWStGcVFsK0RLQzNjM1U3UTJmY1RnZks5TUp6dXpL?=
 =?utf-8?B?eHBQQUhGbE5YN1BlQnNHZkFjdTFWZFZEWlRWSWdmc2JuQjIxOTdJc1puc3l1?=
 =?utf-8?B?RFUycnd3OUt0YzhMYlJGRDZ2a0Jlb1ViekVzWmlDTkR1cURmVkRFWFlFOTRy?=
 =?utf-8?B?REU2cHhnWHJuRFBZMTd6WDhYeWRJais4R3JPMWNTMlhTTUY5TVhSb0xYOU0x?=
 =?utf-8?B?bmNpZmtQVEJiZ216ZEU4c0JDc2NiYkUxTEhGa1ZCeWFRVXVMa2tsVVZhdU5G?=
 =?utf-8?B?amZFQkwrK2dIdXpINDhUWlFacHM4QzlPU0dMT0JLVmNSeWN0bXBCYzk3Y1VO?=
 =?utf-8?B?OTZuT3lGT2daV2loYXRibER1VUV4c0hNcnlnRXk3ZFpHUnp6ZGQ3YkJKT2Rs?=
 =?utf-8?B?UVhVQXRhQ01jZkdSWW9MYlh4Uy9mbTRVUmowa3k5Q29sQVdLSmMvcDZmbEEz?=
 =?utf-8?B?RUNSUlNYOWlkR1F6WXpmVFJkWk1xWWNNQmRXV3VYRFlMVERNdnBPQ0FJa0Mz?=
 =?utf-8?B?QUk2SGdvc0dYb0loSzE0M1owN3o4TlBJaEZoUVFNNGo2U2x4VmhRdXRWaFFy?=
 =?utf-8?B?cUZsOEpVYnA3NVhOSjN2T0xWeWo0bEtsNW1Jcm00QksxeFE2L0NKY1I5SjBq?=
 =?utf-8?B?cE13bmc5NTN0bDRUWGVheG02cnJxeisyUUlKcUFreWZZOFNYWW1wMFpWZXpD?=
 =?utf-8?B?c09UQXVQNEZRN1QxOUQ1bTZORmVpencrTmZsejN0YW5QcjR5aGZKYTNzSDQv?=
 =?utf-8?B?V2xIYVZ0bXVlem14N0wrb0NLMlhGcXMzSjhIVml0d2ZWR1NMdnlER0wxcGxy?=
 =?utf-8?B?MUdObHA3MHFVVkMzZnYwazVNZENRRmlKcWVlVWl1V0E1YlpHOWxtc2NwM0tM?=
 =?utf-8?B?aWM3TEpkL05zRG5qZmkzSlM1L1VKaWdGVlhQZCs0Zm1vWTJMNmFiVzVsVjJC?=
 =?utf-8?B?emQzUUtKRHlqbEkydCs4MzBEQmo2cUVvdlZrdFMwV00vaDhWTnU5SGtaUlBr?=
 =?utf-8?B?SDcrKytkdVk4dHA3NTVBTE83R3dXK2VjdUNuL0c1QUQzczIzVlRYZWs3UVhL?=
 =?utf-8?B?NHI2V3lnWmg2S2tjRUxHWVRoOXJOblE3ekFpNG1FeHFNVmYyd241bmVHeXVn?=
 =?utf-8?B?ZjNNT2ZqZVNYMFpQQ09EMnBpUklJQ2k5YzE5UFJrYkJFTTNESXdGRHNZUFl4?=
 =?utf-8?B?UjZhR3B6TXdTa0pWcVJuUUZnTktNR05YdkFYR1NHa3FJV05KVWdDd3N5Q1NQ?=
 =?utf-8?B?S3U4QVowQUZ5cCtkVGg3aW1maGoreXVIK2ZFNEs2d0NXdVJnVG1yZ1JMRk9k?=
 =?utf-8?B?WWo2MU4xSTBnM2FJbVo1bzhOWTB2Nk0wYnFPMjNHRVAvaXF4S1kvT2dSSXg0?=
 =?utf-8?B?SUxYRVRhTG5vblFoSGhHcGxGY2w1eVhFZTZXcWt0dnpOMTNHVGpVcHdHV1VR?=
 =?utf-8?B?U05OTXlSbWNwSFl2MW1KSjdITll5emVCd0xLK3BNck1zQlEzcmZOZGwvWmFX?=
 =?utf-8?B?YVdVSGxETWZuWDJxUDNlNFpMeFkvOWtlbzhPeTNiZlZ6aGVFUUZsRjVJbkVM?=
 =?utf-8?B?U1UvdExUaTcva1ZvU2VsSUczV0N0MFF6QjhZTVJlZ3VIQ3JSd0lTZ2x1bHlp?=
 =?utf-8?B?MHY3MDBEN3EzeUxIY3FIQzdhVEZ1dTBvbzlzc1ZSYkR4RFI3bWpab3VRdTRP?=
 =?utf-8?B?bGJOUmpibjZpNExOR3MzK1p6WkpTeWM2L0xpTVVUMnNMTkRxamtCczgxRTdX?=
 =?utf-8?B?dWQ4dm9ZTUFrR0hidTF5QytVSjlYdDBwVzhRSmJ0UVp4Um5TTUtSdEJrZFQz?=
 =?utf-8?B?U3NONFNvZU9qWFFTWVBRb0xDMTJvTWxhclc5L3pRTmRKSEhwMWNMQzlORU42?=
 =?utf-8?B?MW85L0hEN2VSRzRMWVRsQXhyM2E2cTUxa2N2OGVVcGpVMm91eHRYQnBvU3Y5?=
 =?utf-8?B?WmNiK1A0eUpoRkMzRk8zZDE3UjNFZms1SjhoT3FYMzg4QkF4SkkreVVnMUZt?=
 =?utf-8?B?OGdvaSthOFZMV1diQWg5dUgyL1dUcWw1MTRpU2lkUThhcmMxQ1ROeEVwM0xI?=
 =?utf-8?B?d1BPVUFPSTVhdlEvZVljNnNjNXM5d1Z5SEg0T0k0MlVMYUhsUURBbHFvNkxM?=
 =?utf-8?Q?yhYE=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bf50ef0-326d-4fba-7ae1-08dd96a4a046
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 07:13:16.3853
 (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: FgXkHknNSlTt99DesTyzjEqQeREkzBhRQ9+g4MOzNibGogCK+NZrS+OrNdRkwHCYzn2IV5i8LWyJAz65BF/ReA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6164

T24gMjAyNS81LzE5IDE0OjU2LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTkuMDUuMjAyNSAw
ODo0MywgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4gT24gMjAyNS81LzE4IDIyOjIwLCBKYW4gQmV1
bGljaCB3cm90ZToNCj4+PiBPbiAwOS4wNS4yMDI1IDExOjA1LCBKaXFpYW4gQ2hlbiB3cm90ZToN
Cj4+Pj4gQEAgLTgyNyw2ICs4MjcsMzQgQEAgc3RhdGljIGludCB2cGNpX2luaXRfY2FwYWJpbGl0
eV9saXN0KHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBDSV9TVEFUVVNfUlNWRFpfTUFTSyk7DQo+Pj4+
ICB9DQo+Pj4+ICANCj4+Pj4gK3N0YXRpYyBpbnQgdnBjaV9pbml0X2V4dF9jYXBhYmlsaXR5X2xp
c3Qoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+Pj4+ICt7DQo+Pj4+ICsgICAgdW5zaWduZWQgaW50
IHBvcyA9IFBDSV9DRkdfU1BBQ0VfU0laRSwgdHRsID0gNDgwOw0KPj4+DQo+Pj4gVGhlIHR0bCB2
YWx1ZSBleGlzdHMgKGluIHRoZSBmdW5jdGlvbiB5b3UgdG9vayBpdCBmcm9tKSB0byBtYWtlIHN1
cmUNCj4+PiB0aGUgbG9vcCBiZWxvdyBldmVudHVhbGx5IGVuZHMuIFRoYXQgaXMsIHRvIGJlIGFi
bGUgdG8ga2luZCBvZg0KPj4+IGdyYWNlZnVsbHkgZGVhbCB3aXRoIGxvb3BzIGluIHRoZSBsaW5r
ZWQgbGlzdC4gU3VjaCBsb29wcywgaG93ZXZlciwNCj4+PiB3b3VsZCAuLi4NCj4+Pg0KPj4+PiAr
ICAgIGlmICggIWlzX2hhcmR3YXJlX2RvbWFpbihwZGV2LT5kb21haW4pICkNCj4+Pj4gKyAgICAg
ICAgLyogRXh0ZW5kZWQgY2FwYWJpbGl0aWVzIHJlYWQgYXMgemVybywgd3JpdGUgaWdub3JlIGZv
ciBndWVzdCAqLw0KPj4+PiArICAgICAgICByZXR1cm4gdnBjaV9hZGRfcmVnaXN0ZXIocGRldi0+
dnBjaSwgdnBjaV9yZWFkX3ZhbCwgTlVMTCwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHBvcywgNCwgKHZvaWQgKikwKTsNCj4+Pj4gKw0KPj4+PiArICAgIHdoaWxlICgg
cG9zID49IFBDSV9DRkdfU1BBQ0VfU0laRSAmJiB0dGwtLSApDQo+Pj4+ICsgICAgew0KPj4+PiAr
ICAgICAgICB1aW50MzJfdCBoZWFkZXIgPSBwY2lfY29uZl9yZWFkMzIocGRldi0+c2JkZiwgcG9z
KTsNCj4+Pj4gKyAgICAgICAgaW50IHJjOw0KPj4+PiArDQo+Pj4+ICsgICAgICAgIGlmICggIWhl
YWRlciApDQo+Pj4+ICsgICAgICAgICAgICByZXR1cm4gMDsNCj4+Pj4gKw0KPj4+PiArICAgICAg
ICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfcmVhZF92YWwsIHZwY2lf
aHdfd3JpdGUzMiwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwb3MsIDQs
ICh2b2lkICopKHVpbnRwdHJfdCloZWFkZXIpOw0KPj4+DQo+Pj4gLi4uIG1lYW4gd2UgbWF5IGlu
dm9rZSB0aGlzIHR3aWNlIGZvciB0aGUgc2FtZSBjYXBhYmlsaXR5LiBTdWNoDQo+Pj4gYSBzZWNv
bmRhcnkgaW52b2NhdGlvbiB3b3VsZCBmYWlsIHdpdGggLUVFWElTVCwgY2F1c2luZyBkZXZpY2Ug
aW5pdA0KPj4+IHRvIGZhaWwgYWx0b2dldGhlci4gV2hpY2ggaXMga2luZCBvZiBhZ2FpbnN0IG91
ciBhaW0gb2YgZXhwb3NpbmcNCj4+PiAoaW4gYSBjb250cm9sbGVkIG1hbm5lcikgYXMgbXVjaCBv
ZiB0aGUgUENJIGhhcmR3YXJlIGFzIHBvc3NpYmxlLg0KPj4gTWF5IEkga25vdyB3aGF0IHNpdHVh
dGlvbiB0aGF0IGNhbiBtYWtlIHRoaXMgdHdpY2UgZm9yIG9uZSBjYXBhYmlsaXR5IHdoZW4gaW5p
dGlhbGl6YXRpb24/DQo+PiBEb2VzIGhhcmR3YXJlIGNhcGFiaWxpdHkgbGlzdCBoYXZlIGEgY3lj
bGU/DQo+IA0KPiBBbnkgb2YgdGhpcyBpcyB0byB3b3JrIGFyb3VuZCBmbGF3ZWQgaGFyZHdhcmUs
IEkgc3VwcG9zZS4NCj4gDQo+Pj4gSW1vIHdlIG91Z2h0IHRvIGJlIHVzaW5nIGEgYml0bWFwIHRv
IGRldGVjdCB0aGUgc2l0dWF0aW9uIGVhcmxpZXINCj4+PiBhbmQgaGVuY2UgdG8gYmUgYWJsZSB0
byBhdm9pZCByZWR1bmRhbnQgcmVnaXN0ZXIgYWRkaXRpb24uIFRob3VnaHRzPw0KPj4gQ2FuIHdl
IGp1c3QgbGV0IGl0IGdvIGZvcndhcmQgYW5kIGNvbnRpbnVlIHRvIGFkZCByZWdpc3RlciBmb3Ig
bmV4dCBjYXBhYmlsaXR5IHdoZW4gcmMgPT0gLUVYSVNULCBpbnN0ZWFkIG9mIHJldHVybmluZyBl
cnJvciA/DQo+IA0KPiBQb3NzaWJsZSwgYnV0IGZlZWxzIHdyb25nLg0KSG93IGFib3V0IHdoZW4g
RVhJU1QsIHNldHRpbmcgdGhlIG5leHQgYml0cyBvZiBwcmV2aW91cyBleHRlbmRlZCBjYXBhYmls
aXR5IHRvIGJlIHplcm8gYW5kIHJldHVybiAwPyBUaGVuIHdlIGJyZWFrIHRoZSBjeWNsZS4NCg0K
PiANCj4gSmFuDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Mon May 19 07:36:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 07:36:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989591.1373601 (Exim 4.92)
	(envelope-from )
	id 1uGv2S-0005Rg-IL; Mon, 19 May 2025 07:35:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989591.1373601; Mon, 19 May 2025 07:35:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGv2S-0005RZ-FQ; Mon, 19 May 2025 07:35:56 +0000
Received: by outflank-mailman (input) for mailman id 989591;
 Mon, 19 May 2025 07:35:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGv2Q-0005RT-L4
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 07:35:54 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2406::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e4b18542-3483-11f0-9eb8-5ba50f476ded;
 Mon, 19 May 2025 09:35:53 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA3PR12MB8439.namprd12.prod.outlook.com (2603:10b6:806:2f7::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.19; Mon, 19 May
 2025 07:35:49 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Mon, 19 May 2025
 07:35: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" 
X-Inumbo-ID: e4b18542-3483-11f0-9eb8-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iKKDpWkDYGpVmxiZtwJ84borSo1CRHSoQbTQtNcNA5FFXyhEjmXJRJ4apqtxf1OTIjyl+TNdGjq1fczu4dkQL4v3JE87TV/m7A5vAjHFeqayAv/KDB7MB+NkPf0HgbLurvTD8QSYePSGPmjdAfesDgjDfx2QOK5teMTOq+7vJni4tk16snPoS+OKw2yvUMnP0uA7M77w4ViBvWycn0itpjdTNdW6QYZkQVkrv3l64ZzkPJBiD0/nRzQTmDDm1DMp84LUn6aWkWhatX/iyOJXacRUQiqTFHX+PM6hCHAIp+tPrSzKIvgXodu5TTAdCwHtz30xm9x1cxMKuRScUCiMXA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=491AY4HAQJHrgbjN3sGzes+iq/mHC0r/x4iefrn0KUo=;
 b=vO+SORLzqb6qq9+15SCibgqlqJqiBnuIo3OwltQdDTBmFAkQRAXwg6gaj5vTEWGDIAyItJzwyilki7ewIlCPhFAFHcx60EzRjs1kuDygVHnqSWAMZc1Wd40vUAUKW1chrJ4KAH7tTA2gNV/MpLfUdU2TPSPJ8HjFfcKjBQXplOemB7zr9Jbalb4OlWhZjCeNjsZFpc4izXaBmNtIRHbnayFl76NDd/64us6AhkADKU7dR7eHMFyGozXJ0E2RF3LWoOiSCesnPdQHS8T4+NBML0CkyIPO0v0Zdqfv7+qk1/Y15Gu8qKYRbxBZBOO2bt3z8rV4GdDJxI+EL6W5dAtCFA==
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=491AY4HAQJHrgbjN3sGzes+iq/mHC0r/x4iefrn0KUo=;
 b=yhK9GjdpNCTRJ+hcVN7CLLsANJQvqcDNX+2MpCCS7qSIoE2uod0QkUiDgoUlOoYgcUThyDjnbGdJ5fbBMfaPsZEZYAe87xGXgtRe5r9gqGoDVKXPfqKedJveEm5jEllxw8KMuz898I9+BVIxSCq2L42PHdKMD5PEMWfpAV5yZwM=
From: "Chen, Jiqian" 
To: Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v4 05/10] vpci: Hide legacy capability when it fails to
 initialize
Thread-Topic: [PATCH v4 05/10] vpci: Hide legacy capability when it fails to
 initialize
Thread-Index: AQHbwMGgfMHCGxGzEUKJiTb14nIoDbPYhTMAgAGdm4A=
Date: Mon, 19 May 2025 07:35:49 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-6-Jiqian.Chen@amd.com>
 <76d58a17-90aa-46eb-bbe8-c6d9400c489f@suse.com>
In-Reply-To: <76d58a17-90aa-46eb-bbe8-c6d9400c489f@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SA3PR12MB8439:EE_
x-ms-office365-filtering-correlation-id: eaec111b-597a-4f68-2ebe-08dd96a7c69b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?ZG5hY2lWV0lpd0RsdjI0SzZJQWZDTkMzUW5ZaG8wS0pDdVN6UGJRTThyNVpW?=
 =?utf-8?B?Y3orMGl1SHpiUklNNjJ4S1FjQlBRNkcrdGNDZmtXNk5tc2F1VmtiaU5FK0FL?=
 =?utf-8?B?RENnVzFjUnRCM3IzZnNhb25NSWhmc0RseXpwTFhDbFdCRFpxc1cvRm5wdUo5?=
 =?utf-8?B?bkNDVFZJaG9wNFdndU5nN0pOdUxlTUZMMlFUTGtkTlB5VXdkRmFVL3pSQTlB?=
 =?utf-8?B?d29XUVl2M2czdlNVUUNtUWpXM1F2anM2MFdsMGhra2crUFZYN1lGMStLbVRC?=
 =?utf-8?B?am0zRmcrYzFVVFc5aFhQV2krU1o3UXlTenZNdGN6SVZNWkZDc1pKaWk2Z0I2?=
 =?utf-8?B?MytOWnR4UmYvUGJWd0pTa1pmTjFIU0NQajZOWnJ5RXJ1SDRqWXl5RmQwWWRz?=
 =?utf-8?B?N0ZsdUh0bG4zOTRyVXJ3SC9BSGN2V2huc1lMbVdkSjcvRWp3R1RXR3FzNTJE?=
 =?utf-8?B?TlI3V1Q3aDVnV1JhYWZrQUhNVFpzcFdMZlBCN0lBNUZQUEQ5VWkvL0hZOUdP?=
 =?utf-8?B?eWROai8vSzhMMUwybkdkL0tuK2d3SFpINlpxQUpURWs3WDJyTmlmVUFkYWQ5?=
 =?utf-8?B?VzNOWmhvZlpBZ0JjdXc1eklncEdSVDdtUGZBeGRaK3dDRURjb0pFb2JBREVX?=
 =?utf-8?B?by8zZkJUdGF2SW4zK3haQ0prZmsvUU5yYTlXV2VMOE1JZzFHY0tFTnF2Nklj?=
 =?utf-8?B?M2RCVFMwdUJKbzBIZ1dPMDBxZWpMWGJuRlM1TFQ3MHJZZmhramtiYkl1ZzhK?=
 =?utf-8?B?SitSNWFQUFIwM21oTDFCbndUZGZob2FNYnZMSExFSWYrdkM1YTk3cDBVYnpO?=
 =?utf-8?B?RDE4UVVrS0hmT0VvbGlCTVVoeW9TRTJqc1IwS2haT3crWUFIY2pJZ3hwSWFE?=
 =?utf-8?B?ZTRkWlplK2Q1R0lNUjY3VVFXNHpMZlZSMitlN0VCcDk1UzM5VDA5YlF3cUp2?=
 =?utf-8?B?Q21IWk83LzhFTFRGN1ovaVdRVHFQdVlMeGlIM2NRLy9EdzlzVzVpVGx6RUVK?=
 =?utf-8?B?VjBKa3FiOWxqWHZiRGNtMURrQkk1K1N2Mk1pTXNncGNUWnp0SUxJQ1I0SEI2?=
 =?utf-8?B?eitmZjhyUXhKRE5DcUFaY1ZpODNRNVdJK2hoQjFlK3VEanA3OXRpTXdDOU85?=
 =?utf-8?B?eUxHQ3FiRjNvNGwwVW0xSlU5a3Z0OUJod3Rqd2NnTHVvcWlYZkVyczFMTXNG?=
 =?utf-8?B?OFV0dzJqTlBqYjQxUjJIWlRwUzZHbXhSbzFiUEZDMk9tdTUzNlZEVzBvby9T?=
 =?utf-8?B?dW9NK3VNRnZlMHgwTU92SjhKZ000YlFYeVdGVDB5N3BIMEJqT2l1MWpzaG5F?=
 =?utf-8?B?VUtoT2U4QnlrZGRRUWxsVFBtaHJnOVkwRzVOaGs3WXViWmJjZXZyMUk0bm00?=
 =?utf-8?B?UUovQzIvdSszdll3M2lmakxqai8zdnpqMDZkeitCMFprTzI2L1NKTDNsVkY0?=
 =?utf-8?B?R1NuQXJLSHhmK3Z4Q0tGZ0ZUZ2VKRlZjVmVlazE5SGk2b2ZNckZPYmh2aitG?=
 =?utf-8?B?aDVMWVRrYnhmbGVBK0tSbU5jSkpHWnNmUGVPY21qdlZ4REZwUW5yeFMyUEF3?=
 =?utf-8?B?UjdiSUNzMlU0c1JWaUlVWnVoZkU2MlhhWmw3dGNSN3NQamYrbzF3Q0IzZjJ4?=
 =?utf-8?B?bUw0aTJqWnJjaHVYa25pK1hPb3FpRXdsOEJIcEYzWEFYOWNsWEkwOERTYmNM?=
 =?utf-8?B?SHlrN1ZHcjkzT0JUNExlK1M1SVVraTZ1ZVYvcndzSHN4YnlCanZ4UnM4VUl4?=
 =?utf-8?B?YWkwd01ZS1ZReWd5Yk5UYTNYbFIrM1Y2QVRHb2ZJUUV1MDhmSEszQW9mOTdo?=
 =?utf-8?B?ZWJScXdzMmc2Ri9hZHJwSUFXb2Myd2hvNTdQSjduSDZqQUovUVJEYXhoY2dT?=
 =?utf-8?B?eHJhSGtYS01wNHk4Z2JVQXZEei8yaGFLOHBkWWk5NHpDK1ljakNRcU9JRndr?=
 =?utf-8?B?SDNOTVY0Tm9hb1BsUkhoNVpwVENvQ2gybmNtUjlYYWhFbDdtZzFBYkdPMHdU?=
 =?utf-8?Q?KukHmGx2/kkXsVtWBS2C1BtiHP/Dsw=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VjRHWmpTR3VTOWl5SzlEWkFyWHk1SHh1WG5sY094VUJXa3ZsblVGRUoyRDFw?=
 =?utf-8?B?Q0ZTMkZSZU5Zb1BiazBmUk03alBCUWV6aFpXdm1uZk8xeVNxMkJET0Q5Z29I?=
 =?utf-8?B?bXQvbXQ1ZTFuZkRtbUp6b0srRWFFNUQvUEtZYVNhK3E3ZHUrRHVvMTk4Zkxn?=
 =?utf-8?B?MTNpeGNsREplU0piYkhqZkNLLzFVTFU0bEhXSjc2Mlc2d0J6QXUwRkJ6SGo2?=
 =?utf-8?B?N0ZvMUNhZWNnQVR4TXNVVVpwMkZPM1ppQTFDcXBZTDk3NHpHWFo1WUtkaVpN?=
 =?utf-8?B?ZGh2UHZJbzdQRzdYaXJUWW12WTV3cGZITVZsRzNwUXZSRXV1Z1dKVm82VWhv?=
 =?utf-8?B?ZTZEVDhDZU1BK0Q4Q2w0RVF2NnJrU25SUW1Vd2N5eERGQzV6TlNBRWVscUhp?=
 =?utf-8?B?bzZFdkoxU1BIQVNvTVlEMUhyOUl4Nk56OEVxSk1iWE1xa3RiODFmMXlFNmU4?=
 =?utf-8?B?SVhqakF4Sy9OcVZSd0tUNDNpUzRuN09YSXFRMVAzbmt4d1RDd1FqZGRNaHN4?=
 =?utf-8?B?enAwa2RzL3R5bEdBd1ZQczVmR0VwcEcvQjZtdzkwTTJOTFF5ZHBrQlFGRE9B?=
 =?utf-8?B?cHV0UXNDc2ZuUkVUNmhqMWlhcENmNDFHMk5FV1N5dzRvZ2Z2UkZtUGpGNTI3?=
 =?utf-8?B?OUlyVXJWZFpaOGlUbkZlTHRJd2JOdWtyaUREODFWV1l5NExiSEloaE9salNH?=
 =?utf-8?B?K0RRRWdONndCMlBwb3Y0QU1HTERvVzliNmJzaXJ1aEhvaktJSFdNRStKQUFH?=
 =?utf-8?B?aDlRdGNMQ1EzS2ZPZGVZZWtZVU5WMkQzdTQ2d0RaVUE1VEI3c2t4VEhNUWVi?=
 =?utf-8?B?M05rai9YNm1wN0tuUGNleXJMUWN0Q2t4YmlnVFlMazl5dGkxbm9ZSUhQSEFv?=
 =?utf-8?B?QXZvaHQxODgrbnhHZnNkSXZVUGVNM2pwRlR4dHlMMm95VW5Eb09YbDhmK2J0?=
 =?utf-8?B?UHBtdzhDUWZaU0cxNmpEMlNpNVJXRkhtR3RVV0JmMEUyLzVSRUhKS0VHUFVw?=
 =?utf-8?B?RXIxVVdhbUZ3MGppbVVwOHUyelJkRFkvalAyc2lYeVI5WktjSm10L0tjOE4y?=
 =?utf-8?B?dG9ZcllWNTdzZERIazhiMEtIN2oxODdKUzMrK2kyMDFFRHptZHYzclJUVGI0?=
 =?utf-8?B?ZVhtWDFNU243U1kxOTJRQWFvS0JNUnpHMngreld1SDlRMm1FRlVoMzVYOE02?=
 =?utf-8?B?MUpYYUZVU0o4eFhkR3ljYnVneEFTbngvU0V4MFZ6dFdnZ0diZW9GTk1HMHI3?=
 =?utf-8?B?anp0T1p4UlNkY0FJR3VKRHk0dUk1SVhlU0tPL0ErL0FXNDZDcUhDQ3BmUGpC?=
 =?utf-8?B?L2JUbUpXNGdvcGlVcVJ1bXFMR3NBMEdFc2czV2wvZlljdldHWWg0elNzbUhI?=
 =?utf-8?B?elFMZ1Zid3ZSUGR1RDcyQml2WFFtZDVqTmVxRFNFcGpaeHRLbmVUWkdRdzkw?=
 =?utf-8?B?TUlGaW9CVXFMWVpIUEhmVWtDa2VaZzBhdXBaQ2Z2WTVpUlc4WGdFbHVmOG8y?=
 =?utf-8?B?dm5qM3premVtYXF2QmFSd2pzMGcvYTRaVXRTUTlSUGh6Y3ZwR0NuSDRWSWgv?=
 =?utf-8?B?dENqNGo1QUxNSmtJNDdaUEY1SzJJS0M4ekZiU2pkZURRRG00UlM5Y3Qzb2RQ?=
 =?utf-8?B?aHoyN3JZN3hGVXJRVXNZbTF4bE55T0NXMXVrclBENnorY3VWTHRGanV0NmVw?=
 =?utf-8?B?M0V3eU5nSGRNUCtMeUxiMzltN0tQNzJrL3BmUkxMaTFueHdjTmZYMUxpVC9Q?=
 =?utf-8?B?L0c4R1UxMXFtWHZaNmVMS2owVmFZcW0vZm0xblZzdHRGMnB0UTc0UVNyOURn?=
 =?utf-8?B?N0xpQ0NETG5IUUwzYXJXSGtLVk01OEhKRlN4dGdveXFqQ3V0bFIvZllIdjVO?=
 =?utf-8?B?b1kraTlWU3ZXaWUvNHl5bldESHlCT1YrSG9ibXdad21oYjlzaGpVMnNPSkMy?=
 =?utf-8?B?ZnhnZzB6Y2UzUjdXdW1rNkJCVm4zZUpUdUdnK0JGWXAybTZ2Mmtmcm5RdzdJ?=
 =?utf-8?B?YTJjcHdDY2JzY2NrUU1mUDc2bjYzWFBqQXE5Z0trM1hOeU9OaDRaYkJQK2lq?=
 =?utf-8?B?bWVxRzJHUGZjTHJwaWFaVVczeVJBQVVLY0M2VnZCLy83TFcxL3pUWFZORG9y?=
 =?utf-8?Q?gurA=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <828D5CEAAEA4464D81B6F30FED741B29@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eaec111b-597a-4f68-2ebe-08dd96a7c69b
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 07:35:49.1631
 (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: 6sDX4DLKLUfMBew6qLDAd9CTlMkZyhV/XHu33rqfBdGyjw34vwqqB/1KNB6I6yJozePXIIgxphk0bOr5jWk59w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB8439

T24gMjAyNS81LzE4IDIyOjQ0LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMDkuMDUuMjAyNSAx
MTowNSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiBAQCAtODMsNiArOTksMTAwIEBAIHN0YXRpYyBp
bnQgYXNzaWduX3ZpcnR1YWxfc2JkZihzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+ICANCj4+ICAj
ZW5kaWYgLyogQ09ORklHX0hBU19WUENJX0dVRVNUX1NVUFBPUlQgKi8NCj4+ICANCj4+ICtzdGF0
aWMgc3RydWN0IHZwY2lfcmVnaXN0ZXIgKnZwY2lfZ2V0X3JlZ2lzdGVyKHN0cnVjdCB2cGNpICp2
cGNpLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
dW5zaWduZWQgaW50IG9mZnNldCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCBzaXplKQ0KPj4gK3sNCj4+ICsgICAgY29uc3Qg
c3RydWN0IHZwY2lfcmVnaXN0ZXIgciA9IHsgLm9mZnNldCA9IG9mZnNldCwgLnNpemUgPSBzaXpl
IH07DQo+PiArICAgIHN0cnVjdCB2cGNpX3JlZ2lzdGVyICpybTsNCj4+ICsNCj4+ICsgICAgQVNT
RVJUKHNwaW5faXNfbG9ja2VkKCZ2cGNpLT5sb2NrKSk7DQo+PiArICAgIGxpc3RfZm9yX2VhY2hf
ZW50cnkgKCBybSwgJnZwY2ktPmhhbmRsZXJzLCBub2RlICkNCj4+ICsgICAgew0KPj4gKyAgICAg
ICAgaW50IGNtcCA9IHZwY2lfcmVnaXN0ZXJfY21wKCZyLCBybSk7DQo+PiArDQo+PiArICAgICAg
ICBpZiAoICFjbXAgJiYgcm0tPm9mZnNldCA9PSBvZmZzZXQgJiYgcm0tPnNpemUgPT0gc2l6ZSAp
DQo+IA0KPiBXaGF0J3MgdGhlIHBvaW50IG9mIHVzaW5nIHZwY2lfcmVnaXN0ZXJfY21wKCkgd2hl
biB5b3UgbmVlZCB0byBkbw0KPiB0aGUgImV4YWN0IG1hdGNoIiBjaGVjayBoZXJlIGFueXdheT8N
Ck9oLCB5b3UgYXJlIHJpZ2h0Lg0KV2lsbCByZW1vdmUgIiFjbXAiIGhlcmUgaW4gbmV4dCB2ZXJz
aW9uLg0KDQo+IA0KPj4gK3N0YXRpYyBpbnQgdnBjaV9jYXBhYmlsaXR5X21hc2soc3RydWN0IHBj
aV9kZXYgKnBkZXYsIHVuc2lnbmVkIGludCBjYXApDQo+IA0KPiBXaGF0J3MgdGhlIHdvcmQgIm1h
c2siIGluZGljYXRpbmcgaGVyZT8gVGhlIGZ1bmN0aW9uIGRvZXNuJ3QgcmV0dXJuIGFueQ0KPiBt
YXNrIGFmYWljcy4gRG8geW91IHBlcmhhcHMgbWVhbiAiaGlkZSI/DQpZZXMsIGhpZGUuDQpUaGlz
IGlzIGEgcXVlc3Rpb24gb2YgbmFtaW5nIHByZWZlcmVuY2UuDQpJIHJlbWVtYmVyIFJvZ2VyIHN1
Z2dlc3RlZCB0aGlzIG5hbWUsIGJ1dCBtYXliZSBJIHJlbWVtYmVyIHdyb25nLg0KRm9yIGRvdWJs
ZSBjb25maXJtYXRpb24sIGhpIFJvZ2VyLCBhcmUgeW91IGZpbmUgdGhhdCBJIGNoYW5nZSB0aGlz
IG5hbWUgZnJvbSBtYXNrIHRvIGhpZGU/DQoNCj4gDQo+IEphbg0KDQotLSANCkJlc3QgcmVnYXJk
cywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Mon May 19 07:41:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 07:41:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989598.1373611 (Exim 4.92)
	(envelope-from )
	id 1uGv7d-0006xa-4W; Mon, 19 May 2025 07:41:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989598.1373611; Mon, 19 May 2025 07:41: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 1uGv7d-0006xT-1a; Mon, 19 May 2025 07:41:17 +0000
Received: by outflank-mailman (input) for mailman id 989598;
 Mon, 19 May 2025 07:41:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGv7c-0006xN-MC
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 07:41:16 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2009::61a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a3ab2848-3484-11f0-9ffb-bf95429c2676;
 Mon, 19 May 2025 09:41:14 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by LV8PR12MB9620.namprd12.prod.outlook.com (2603:10b6:408:2a1::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Mon, 19 May
 2025 07:41:10 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Mon, 19 May 2025
 07: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" 
X-Inumbo-ID: a3ab2848-3484-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lgCuqzLzfI71uVBvBe/C3c8g3mRI3Gmdhck+yiPl6OcF+5XKstzepNxzHWIMgr2V+bQl/Hu7HKZpP/V9acNhGNl/GHdlirEfaibaZNm5ZyXnERX9PE62/Z/fQQV2FUaI0AWhWfH3LVXvCL9oL3IKy8fHGVnkOCQxOePATgm2/Z+itDJEG3PcH9TFbVKnbGIaVRMp/9me7Tcoznl6gq79PkXkL0F7Nbz04UXDkWfSNe2Sj+sIfxqSBq+ADq7N3VD81VcCkLWVZDkQX20NH9I//z8Uw0UyZ367rdpeVqiuYK+Lou7gDuHTQIl2WYGSB0SNOPoGO24jpeUhfI7U6WeJ/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=9YvWkgvAQk4fOVetIis6HCc0GmeSw9LWJX9vxqlPUcA=;
 b=Xn6tP6xFlvXoCViYtUjUtqdu5x8A5iij+O76nfGwiRZRg5UJ691PtiMEePcJ2MbwrlaFhmoW8al+PSEVIG6N4U483cHhfXFYMVOgMRbjIhhAoKvhLyBGUhabhbiU6gIn0LG3dxViPfk/1yv4EUSZaAP3Rp87bC5QCQA7iZ/kAsLy5GFE495pHQQrLgWqhERWBZuXxMisasDcGeQZKN2jJjq9P7e36EleYIYWtfHq2JW38Fm24AN2syVDUpx9FlTIdzqLGMYGl+wZtRa2xbUvjcAC+Ewi3SLsQVa9jNMITPfhTIpXNslwl8ahFc6ZUL0gy270CANR6UCiPnqY4msGyw==
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=9YvWkgvAQk4fOVetIis6HCc0GmeSw9LWJX9vxqlPUcA=;
 b=vwtbgmQVH63UoCq3EfSoD2usddYTIs/89PXkbDfcZrbxvoM7oIzhhdzBEnt1qjnopBRYE9lEGZhHDyN3Jm5xXB50m0D6ZB9Rd2z95she0exfyBPOt0bpoCwdh0Ogd1pII/jPFqR5+at5Mqomi0FP3rA+ZoNLMuJSqdOiRb2BFjw=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Huang, Ray" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	, "Chen, Jiqian" 
Subject: Re: [PATCH v4 06/10] vpci: Hide extended capability when it fails to
 initialize
Thread-Topic: [PATCH v4 06/10] vpci: Hide extended capability when it fails to
 initialize
Thread-Index: AQHbwMGh3aKmZdUzDUy0XNAaOb3iFbPYhg4AgAGguoA=
Date: Mon, 19 May 2025 07:41:10 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-7-Jiqian.Chen@amd.com>
 <48c71b8b-2b59-41aa-ad02-b237d53f1d6d@suse.com>
In-Reply-To: <48c71b8b-2b59-41aa-ad02-b237d53f1d6d@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|LV8PR12MB9620:EE_
x-ms-office365-filtering-correlation-id: da5ded58-e33e-4ad4-3874-08dd96a8862c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?SkowODhiaThSZGduemFCdTJBcWwwQ0xwMnY2WVdTMitweHVQRGJ4OHdIdmhr?=
 =?utf-8?B?OUxpS2hHSGk3OFh0QVRYa1Y1OVB0MEM1MnlGemljbC9JYTQ4YTdNdk0vWkd2?=
 =?utf-8?B?VkpKd3hOSll2OW02YjNXUFdtSVFlTm9lcU5na0h1ajViVS9YTEZBNHByMnVs?=
 =?utf-8?B?UzBSdjVkZU1Od0d4RnZ4MnNvdFVSTEZTTm13dHZoMlo0THlyQzdhSjNnSjhJ?=
 =?utf-8?B?MmVabCtCTzV6Y2l5ZkxBaVhxMTJndEwvY2xYN2kwN0JYa0xVWmR4OTdLWXNQ?=
 =?utf-8?B?aW84ejh6VHVzZnBjTzFqSncvREQrMExvQXZTWnJBQ1c2UVpPVjdGZ0VMa0s3?=
 =?utf-8?B?R2RhSTJHUlZtMDZxUE9SNVdJWXFNT1dCWjVKUTFQQXE4VVpmTVJ1d0V2K29I?=
 =?utf-8?B?OFg1MjBCK3VXQjV2UkQwVUdLaDVLY0FzUGoxdVRCZmV3Mk9ueGVxaVpzR3pN?=
 =?utf-8?B?N2xuOEdWOXV2VHFxQ2hjL1RxR01mVVBtYk5BVG1PbjcrbHVlaUJjOWx0WVow?=
 =?utf-8?B?WVNSbVpLVE1CUEZsbE93SlU0UUJ2U0liUVI5NGI1amhGNW14cGswMTlFYzIx?=
 =?utf-8?B?RmpnY2g3Qldoc21QUEdXTllzMmVlNWt6R1hCckd0ajRaeXVuUjdsNWs3S3Qw?=
 =?utf-8?B?VXh0eStndnhwZkJDYk1Qbk5DZXBDNjdsbVdPbWdwWkQrVGNSVkUyYjNZM1R1?=
 =?utf-8?B?ZWRNTmdKM1BlcHZxMDFUY1VQUXQ1TXp4ZWxleW5KVmE0bjZqa3J1dFRXMzNp?=
 =?utf-8?B?U3hJL2VFeXFRL0doeXBoanpuMmpYL0Q2TDEzQzlZRlBsOEJYbTk5M1VUbENF?=
 =?utf-8?B?YVdyb0xvaE4rQW5zUEZveW1DcGEzWkpwcDJQWnlNWkg4MHlEMXVPOFdDRGlU?=
 =?utf-8?B?K1RrbnZCZ0xqSmQzWllmaHhKSndGT1pVZEJKbk5UdjhmTFNwSS9zQ0x0aERI?=
 =?utf-8?B?RDF2QUl1QnUzQ0hnOGVlVmh0UnVjM2JDeklWNXg5dWEzVDJ5bk50NHNTNkp5?=
 =?utf-8?B?ZGYwclVTSnM3VTdSejMzdlRBemxoenRyZ3BNdVBIVnVHUUdWdTJVMzJMeSty?=
 =?utf-8?B?ZXNUTGY3UThHK3dWWmI3dVFUQkNXblhDMngzUmRkTHg5MXNNUi9KZ3FQUU02?=
 =?utf-8?B?MUhqUkFmcFhNWEFndDF6eWxFMXhlQnk1Qk9TWGlGU2FsTTBJZE1leGJGYk1U?=
 =?utf-8?B?ZjZEK2hBUmF4MFQxdS9URWVQVzFsVytUVWhVUGo2b3Z2TGtBYzZlOVdhNnJv?=
 =?utf-8?B?NTRKQld4NEVqeE5BZzVEc0dJQ3dSOTFXaHNGb1UxbmhudWQ2Zm9ZNXd2cTND?=
 =?utf-8?B?RHF4ekhkdTJnQ3BCcXMzYXpFSVJqS0V5cmZkUEhTYUdjZWlJeDdoSWlCMXJq?=
 =?utf-8?B?Umh6alFnV082YU9zakxMcGtjV1NEQmxibFdsWG5aelBTOUVKMkFyNmJMaW9r?=
 =?utf-8?B?ckVTTXpxMjR5b0JRRlNlWVF3VG45SEthYzl0d05MYmQ4WUxNbWt3ZUdaeUZK?=
 =?utf-8?B?NzdYblNTVnpBcFlYeC90SVk1OHFhWVZSaGtkUjNGaUZKeHpocmxjM25CSUI5?=
 =?utf-8?B?UThmNlBKdCtSVENtTzIvb0J2MmhQNFQwSnoyUUJHWE1pbnRDWWVzNXNNbEtK?=
 =?utf-8?B?ZVNLMjRMUjRVaTErcEZrQkJGdnlWRDllQThEdDlFNjZMbjJEZm5EdHhWL0tk?=
 =?utf-8?B?eDQwUHdFMHhXMThucWVjQlRaZVZ5cGgxbDE4aVFURXdKRCtkeXJIc2JSUUJO?=
 =?utf-8?B?Z0ZTSDdDRkxiYkx5UWlGV2xjbEJ6VWFTV0tublFpejNEYkQ3RGR3SWNwcTQ5?=
 =?utf-8?B?c3MvTzRVMTRWbkRSNTBsbHQzUm1iT3dSSWV6L20rYXVMUU54QmQ3UzkzbFk3?=
 =?utf-8?B?dUZvTDdVcDlTd3IwV0pyL2pYWXFEQ3VmTzZseEJad3VTdVdYWnp0VWw0K3VL?=
 =?utf-8?B?NFdjQkFhc1ZyeGtHbmJtWXZEelN5UDRwZlFpVTMvVnk4Nmt6eTltMmhlQi9i?=
 =?utf-8?Q?kP+Nn91SwzwB1txTSNH+tX3cwmY01M=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TEYxb1lxV1JLQkRLL1pwdk9PcTVlMFRwSVFONjlLaDM1SXNxK2U4N3AySVNo?=
 =?utf-8?B?bXZEWUQ0bzkzOXZIRkd4T3hBZGxmQStieXFidHN1M2dMZ1k4VkJ4MnRyR2th?=
 =?utf-8?B?QUh6dUV2WUZCbnltWXFNRXdWNkhXeTlvZGtHaCtLRk92OEFhdnVYVHpNWUtO?=
 =?utf-8?B?YldHTVo2bXZSaGVmeHBHZ1VJZFg3blBDT2kxcWVxejNCdFVLTEFuSGV1YlVO?=
 =?utf-8?B?cHpxb3hDb3I2SGprRW1Ub2V5dGJkSndDQ2VaSGYzUGF2RENTaG43ZnRmWkc3?=
 =?utf-8?B?K2JrQ2s4Rk0wNzNTZ2l4SnVYbCs3OXlrVlg5c3VVOTlGQ1UwTXRjMHd5MWVD?=
 =?utf-8?B?Wm5Hb0prd1R1bHlRSWptbVA2VlJFMVJQTElUbDhCM3hLQ1AxTDc4KzV1M09Q?=
 =?utf-8?B?QTBraGpzNU1TTDQrZW9HRHk4Uk5vTW5odnlsT3ZBSVdMRVdhMW40cy9kTjdS?=
 =?utf-8?B?QjJ2OGF2dGtxOXN6amV2QVpGVEJDRjYyaDZwZTJKQkU1YjBDWkhZYVp4Q0ls?=
 =?utf-8?B?SzAyVFRlckR6M292UzVFSkNlVEhsQWdoaXREdGlpdlo3ZkZnRjlDaUVNb1ZO?=
 =?utf-8?B?NVNYS0tGY0VoOHplQUVMeW9yMkdRcUxwOVN4NkR4Z0owNWVXUGNNMlNKY29o?=
 =?utf-8?B?d2k3L1NTUk9HWFVwclIyWUVkb2tBY2EvbS9ENlBNZmR3RlByUHp5bUtnaTNq?=
 =?utf-8?B?eEZzTGJreHBIQ3BkYTR1V2F4bi9ZUm1NeFJCSzhrYVpUUklyMVNWMkxhWnJp?=
 =?utf-8?B?Q2NmWndEbkdjMzdGY2grQjRKbDQ0eS9Iekp4ZXNXM1pUQ3JYc3N6Zk94MHo3?=
 =?utf-8?B?a2Z1VVhHTm9ybHBueG5WOTRaTFBCSjRRVk1MVU01dEJQL0hjeGZyakorL3px?=
 =?utf-8?B?UFVPZlBaMkU0NWtaTlJBWGRreTBiQlJweC9NTW8zVkFkc0FOa1VoNk9RWkNN?=
 =?utf-8?B?ZGZCUEdMeHkrbGJ3cXJRRHlHYU5BenlHYUVHdzZSNUQ0TzdhZjNLTnNOK2d3?=
 =?utf-8?B?UUI3M1NqSDVWckhZKzVwN1VVNWM1WnZWTkk5WUQ2eitUUzllNlJ3YWZadUxl?=
 =?utf-8?B?TGtuTURNdk9GUDcwVVl6Ti9PYUI1NWhjS0FsZ0t2NEs5SitJcWhRRW1MNHB4?=
 =?utf-8?B?eWQxSkJnWWdYaWNNelBydlBvNzB3bmNDMmJmbGpDeDlnZkw4QjFXWVFxc3N2?=
 =?utf-8?B?OEYvU204VWQxVGl1MDk5b0x2ZmxTblJDNlF6WVBDNkJWRGlCVmNTRlBCNFZp?=
 =?utf-8?B?SEppeWVJOElyZUJmVGw3YVloaUx6WHQzdXhpanBuUXF2N293Zllnakw4Nkgz?=
 =?utf-8?B?Uk1aOXZUeHBxZXViNEg4TjVyMVN0T1hpT3l1OEpRT0FGVWNORGpXL0F1ekdw?=
 =?utf-8?B?RzJFY1V3TWZMeEJJeTF6Y2xYTXlVV2Z6aDVrZ2hhYzFKNmFjcnJMQ1VlMlRP?=
 =?utf-8?B?eExvK1l3eHhXeVYvaFVHdlFRekJKODRzMndRVXZlaGhSeUNhZ3NKaXAxWHRE?=
 =?utf-8?B?Ty9sUWNFdDZadDVyY1A1SVBsbGdwMWNSckp6bEhoT0M2MmxrNXhrakVEMUZU?=
 =?utf-8?B?amk5cnVaMXpYZ0FDeHlua0FCS1lrcDQwVnVYV2k0K0xHdld5OWNpaDdrNmZy?=
 =?utf-8?B?cTc3Zy9QcUFmUnZFQlgzbVRBWUZjQkJiSWlWTHZoWnMxZXlvYVJLY1hGUUVC?=
 =?utf-8?B?YjdDbXBIcTRwTVpBV096L25IenVlUXhrdG1udzl5QTN2MnFaSWM0dFI1U2NE?=
 =?utf-8?B?R3BlVmptazRvM1BXdUtkZ0d1dm92ZUpReE9UalduSzZPNzM2YWUwZmZHYWht?=
 =?utf-8?B?SjRVU2xISXNPdnZtNldPaWNHaExTN3ZvTitwZjdkenZ1b0tFam53T1YxUlAy?=
 =?utf-8?B?aE4vaWxidnRmaHMxMWtkcStUeWpFNzFrOC9uUmphRkE1RW5rSFRFVnlKM2JC?=
 =?utf-8?B?NTRZR2NSNW5oczByRFpwMUhDTFlycG1wdHpadis5bkhuLzRXSmJ5K0U3M0RW?=
 =?utf-8?B?ZWpkMWhiY3lxbmE5ajZYOTZJOHp2VDFRL2tzaDJiWG81YS9tMUFJaXk1dG0z?=
 =?utf-8?B?VmI3ZkNkUGtoVlg3RWZjd2psaXZsTmgxVzJjY2VDOFpxcGtWZEwxcGFqTlZh?=
 =?utf-8?Q?Gya0=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: da5ded58-e33e-4ad4-3874-08dd96a8862c
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 07:41:10.6091
 (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: O0STwxfOI3u++61iQSFQEom/LI6uedFObNTZEbjZuw/orEnhdJEdqaooN/qUmobogcr9gIvQh8BQXdyBigpMnA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9620

T24gMjAyNS81LzE4IDIyOjQ3LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMDkuMDUuMjAyNSAx
MTowNSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiAtLS0gYS94ZW4vaW5jbHVkZS94ZW4vcGNpX3Jl
Z3MuaA0KPj4gKysrIGIveGVuL2luY2x1ZGUveGVuL3BjaV9yZWdzLmgNCj4+IEBAIC00NDgsNyAr
NDQ4LDEwIEBADQo+PiAgLyogRXh0ZW5kZWQgQ2FwYWJpbGl0aWVzIChQQ0ktWCAyLjAgYW5kIEV4
cHJlc3MpICovDQo+PiAgI2RlZmluZSBQQ0lfRVhUX0NBUF9JRChoZWFkZXIpCQkoKGhlYWRlcikg
JiAweDAwMDBmZmZmKQ0KPj4gICNkZWZpbmUgUENJX0VYVF9DQVBfVkVSKGhlYWRlcikJCSgoKGhl
YWRlcikgPj4gMTYpICYgMHhmKQ0KPj4gLSNkZWZpbmUgUENJX0VYVF9DQVBfTkVYVChoZWFkZXIp
CSgoKGhlYWRlcikgPj4gMjApICYgMHhmZmMpDQo+PiArI2RlZmluZSBQQ0lfRVhUX0NBUF9ORVhU
X01BU0sJCTB4RkZGMDAwMDBVDQo+PiArLyogQm90dG9tIHR3byBiaXRzIG9mIG5leHQgY2FwYWJp
bGl0eSBwb3NpdGlvbiBhcmUgcmVzZXJ2ZWQuICovDQo+PiArI2RlZmluZSBQQ0lfRVhUX0NBUF9O
RVhUKGhlYWRlcikgXA0KPj4gKyAgICAoTUFTS19FWFRSKGhlYWRlciwgUENJX0VYVF9DQVBfTkVY
VF9NQVNLKSAmIDB4RkZDVSkNCj4gDQo+IFBsZWFzZSBjYW4gdGhlIGhleCBkaWdpdHMgYWxsIGJl
IC8gcmVtYWluIHRvIGJlIGxvd2VyIGNhc2UsIHdpdGgganVzdA0KPiB0aGUgVSBzdWZmaXhlcyBi
ZSB1cHBlciBjYXNlPw0KSW5jbHVkaW5nICIweEZGRjAwMDAwVSIgb3IganVzdCAiMHhGRkNVIiA/
DQoNCj4gDQo+IEphbg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Mon May 19 07:44:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 07:44:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989604.1373620 (Exim 4.92)
	(envelope-from )
	id 1uGvAp-0007d6-Hx; Mon, 19 May 2025 07:44:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989604.1373620; Mon, 19 May 2025 07: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 1uGvAp-0007cz-FE; Mon, 19 May 2025 07:44:35 +0000
Received: by outflank-mailman (input) for mailman id 989604;
 Mon, 19 May 2025 07:44:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGvAo-0007cs-KB
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 07:44:34 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20622.outbound.protection.outlook.com
 [2a01:111:f403:2415::622])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1980e327-3485-11f0-9ffb-bf95429c2676;
 Mon, 19 May 2025 09:44:32 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DM3PR12MB9286.namprd12.prod.outlook.com (2603:10b6:8:1ae::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Mon, 19 May
 2025 07:44:28 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Mon, 19 May 2025
 07:44: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" 
X-Inumbo-ID: 1980e327-3485-11f0-9ffb-bf95429c2676
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WXY6/nrTwXdwCs3Vg8N/aQp9ZKAZkxXWcEYgitPFqsb595+1FdiCy3CA7rUL2tqSf2WkVkBctfKoEgnRvl+jGmy0pMv36E7wIh/MmjFlEgb8mJ9PKDZWIxQdLbw8qOEpSVJMpSgWffTYjKinZHXDHYkOmTw9icwGhH21CZmqk4Uy+ZD3RaNOszF67HPZ3PVuPyw5eZ2ss9P0lKJrQaD5N07+QG5DSHGQVna7JX2mK9qAZ75UfJJszJTUDVBiZb76TVSKvIK6IUT4LUwF2zmNiob+edaz29aPCRdOD4fceunbDIoQ2di0rE+OZ3dDLKi3Em4ndzu9Xv/WcBvlxNTnPw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JxaQ6PtlbYk8raRyt3q373mOAZKq4W/vMpTGipk7u8c=;
 b=V2Y2UiLaaywemwHvQj8y/RcujjvGFRlcR0F7N7B9+xhjdjnhU5MJq0by/dfotEyCbs0UiIyScycmuytECFllUv1n+1pY1w45wJmmKd9L4ZE6EWA1zPTT3QB0KkcXTV367ogn2o/jaXHpmoEuyDIoeMw1QNcA83dej6Kd6wORhdujUvo395DiQqi2HZ9YyDp+LgHs3UF8s7Xe8cgE7IoMeuHVFFjrGJOJa5Eb6apyADcnlQriK3ozdmEdiZEg3Yw/H5D0eFQS9ZqcpQzv2srQvYmUkBQSG6Q/ISuSb3QlqmEeiEZ1155QvNEitAl2/wc/1KMQ4gRcVv+CNYDjBxMhBw==
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=JxaQ6PtlbYk8raRyt3q373mOAZKq4W/vMpTGipk7u8c=;
 b=5RChZjfcJm9j4WCHxc066csZrFidXzpe86rqWjm/DCo8BXgs6xq+zMnpuR6Sbl/YD9FH/Yv7fksrKCMfrwxLS6ZGbS+3aVVpppe45dhmPYIeSUcniZR0RSc4Yhth3eAyAjLF3tzJ3jLNlDvcFzU0qnfhivAeP9egi4G10t/DcbI=
From: "Chen, Jiqian" 
To: Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	
CC: "xen-devel@lists.xenproject.org" , Anthony
 PERARD , "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v4 07/10] vpci: Refactor vpci_remove_register to remove
 matched registers
Thread-Topic: [PATCH v4 07/10] vpci: Refactor vpci_remove_register to remove
 matched registers
Thread-Index: AQHbwMGiFe8O5wuIW0u6gzvdFdA3jrPZjXsAgACaRgA=
Date: Mon, 19 May 2025 07:44:28 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-8-Jiqian.Chen@amd.com>
 <7129d506-b03a-4f89-8128-84b8befe8799@suse.com>
In-Reply-To: <7129d506-b03a-4f89-8128-84b8befe8799@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|DM3PR12MB9286:EE_
x-ms-office365-filtering-correlation-id: 37593698-957c-4bf2-fd47-08dd96a8fc2e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?U3VHTkptQ1lMZ0IzNnBsUXlYYmdVUkM1QjdPUzM2ZzlmWXpNRWZsWFBvZkJU?=
 =?utf-8?B?VmFxdktHU0dodUtzcHNrSERFNDZvaHhTYmNMdW5jSE9kaU1Wem5oZUtCaERN?=
 =?utf-8?B?RUdIMzF3bnd5YzMwVjBjSTlZTFBVa2NybmkzOEZ0RXFPVDdoOWZVUkRBYysw?=
 =?utf-8?B?WTdsYmYrWFRBcUIzYWVKMDNNeVpoV3M0dzYvcmZFSHBuMGVPMlFTVlZtVFM3?=
 =?utf-8?B?UGFjUXM3TS9ZOHoyNzZGN05pQWc3VXRYRWJmaGxjM1VlbTdoUmVLcCtMek1Z?=
 =?utf-8?B?ay9GL0NNOVJ4QXlEbTZRWlRubUpoMHJaRXQ3WlM5MXY1V0RtWlJDek1YRHQy?=
 =?utf-8?B?VkdjbzVKbkRVY3VTeFhBMjF0SXJPMVUyR3F6YllxTkVscmtjQ05WMEVMdnFo?=
 =?utf-8?B?djJCdnRvR0EzaGY1QVJUWGpvR3hCVDNMa0Rvd2VLakhSZ1JKcERsU25FVGVk?=
 =?utf-8?B?VlNWUEFnSkVGcFVKbFBtbjVVZ1ZOM3A3RzU4ZmMzL3pZL0xtcHkrbHdCR1Bw?=
 =?utf-8?B?RStnZHl1WG5kTDBVWkJ5OFRHYzZQTUtiTmtRTHFCNlp0QmU5QjFvck9qbE1o?=
 =?utf-8?B?WEhFRUZmQkxTQjN2UU84cmttUDlZd29Tc0ZTeHFsaElTZjF5QVEwMHo2SHdi?=
 =?utf-8?B?dno0Mmp3cUR2eDlFd0hLRkFka2FISzVJT2NWWTgzZGdlaGJneGZRNWJ1THRL?=
 =?utf-8?B?SmYyN1YzU1dHekxyRlpYY3FKdGtHWm9QQ0RQRjU3amp5a05MS0pGWm9EWHhU?=
 =?utf-8?B?Z0xiQVI5U2JDdTloVFBLNUJ6OGlOalBDLzJHTmJST2xzMVZlNElGci9HelZ0?=
 =?utf-8?B?Y1Z4YjZRTFgvb0ZKaXQvbDF3MmFjOGtZTWhZRC80M2Y5UTlJTjdNcHhpVUpI?=
 =?utf-8?B?ZlZjdFNrRUhQRm1MNW9ISm1WSWtIOGVTQUhNN0VySnNJWFQxVkM2Qnd3M0Vy?=
 =?utf-8?B?d29WN1RWeDJRcHc0OWVyRHJRdlM2OS9yNXJPUi9ZbENKNUpxdVc2eStkb2Ja?=
 =?utf-8?B?MHRhMGRwQ0kwUFd5d1BvSFJMTDA1QlBmWlFSdEhkNmpacndPa0xvaTc5Y0dH?=
 =?utf-8?B?Y05kMUNZeEJSMkRkdDZzWkNBdFRQbGd0L1VVejN0R0tDeXhPL0pjZVFUYXB2?=
 =?utf-8?B?UXhLZ1c5eVRGS0xZN0RobStrN0hIVEJZcFFiZGl4MjQxc2IrdzJLa3BERnBW?=
 =?utf-8?B?OUlkTWRMQkZxR1hOeUxXekhDVVdPbXpwbnhkWG82dGJ5UDdaZVlMN3EwU2dX?=
 =?utf-8?B?a3NnaktldVBhdEU4NG0rKzhSSzlIVDdGMUVxT2N6bWI4NVJuQk5BbTRLVE96?=
 =?utf-8?B?UXV5TVpvVDZaSnNiT1FWTlk1cjVKdldEUzF5djFOV0hPU1JxK2JLd2d6dnVG?=
 =?utf-8?B?OHdLa2NnMmZFSzRtZ1Y4YUZGSi9aZittWCtscnRYRE1lQkhXV2x1SWxuQU5u?=
 =?utf-8?B?enNVd0VmREIvQjZmZVNkaFEwajI4SEtTcFMvQnYySnpSYVNudGNQWW5SVEVL?=
 =?utf-8?B?SmtUK09HclNFTFRMRkZxY3RuOWhGWHROUnU5WWdQRjZNWmlFUUxsVlVvVFht?=
 =?utf-8?B?TUhPaW9tclZPSU40am8xa3Q2bkgzaGtPVXZOWnQwTHdLUm5ETTYzRGtBWk91?=
 =?utf-8?B?SUp2bUlGTGw4V0E1Ykg0cCt3TVdRSlh5Y2dnL2J2UHpFWHJDUkk5Y1Z4Nk5O?=
 =?utf-8?B?bk9YQ0JYcTdMeFFmbDdYb3VzWUI1RUZxZ2pmQmFHMkRGV05aNUh5elRNTmdh?=
 =?utf-8?B?eEF3amRkdEU4VEh6K2pPcEZUQm9JZUtaalVObGx1VnMzNjl0VGpXaFlkaGVu?=
 =?utf-8?B?WXgxbWhScFVpQXQrQmtUZ1RyL1MyT3ZaK1d4emNGVUQ3bmwzWFIvMU50SFVn?=
 =?utf-8?B?NWlpTUNzMUpLRkdmWElXamxqK0hONHArMTh4dEkwLzJsYnljRGJXcHJsVVU0?=
 =?utf-8?B?NFFIWWxCbWExLzVrT2h4Yzg3b0F4Y1NZZTRoZ0loMHlVVWVTZDAvK1doU2gv?=
 =?utf-8?Q?TXE5sjE5E8jmyLsEAJN1RiEdL2bjs8=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?cEREL3VydkhiTFY4bytBVmp2TnVmS0pnVllYZ3BkNlIvbnNOZ29BekNXUDVy?=
 =?utf-8?B?TU9KVlkxbGdUVitUaEk5Z2VvTnFwWDVvMzlnT2hRVW9tc2RIZ0VteWt0dmU2?=
 =?utf-8?B?T0x0SU53MVlyNW9uaGs5ckJKcHFrNnhnVUNkTi9PMFRNRExBd0Z0ZkNJQzJp?=
 =?utf-8?B?eW5lUEJSenJ0dkcxOUVueERrWW15NW5ZOVg5WUxFa1pKY2dYc3M2cE5nNCtI?=
 =?utf-8?B?cG1abWR2aXYvY0VmdDViV3h5R3haVGd6WjhIdXczK1RXSEI2OE0vVThDbDBV?=
 =?utf-8?B?YnlsckcwT21CVkl5eEJpbVp3MkNRSW9BVERaTnpnNmlGRVA1SVlIWU9rbmxI?=
 =?utf-8?B?UktsUmM5blJ1b2VWblVuVGFIKzFzbjlpaXVOQTdIV2pLcG9Jam95enBwY0pB?=
 =?utf-8?B?R29paUZzaHZVa3pzVEJ6TUl2Ukc2bmJhb3E2ZnkwaXZISHFKMzA4azFpQWxF?=
 =?utf-8?B?MTcrME80Y3RTLy9qclo4RE9kNE9rbUZCbDI5OEczQXBWa203dzl5Vk9Kb29M?=
 =?utf-8?B?ODNuWkpXVUYxZXM0RlZ0MDNrZnJYaHF4NHQ1OStST2R2UlM3NzlGTmJtSGJs?=
 =?utf-8?B?bkplQ29XZVJvN3ZDYi82cGJ1SDhaTVdpRGhMbERTV1lOZW0rTU9PY0k5akxr?=
 =?utf-8?B?NCt1UXJicWl1K2xETUNUUUVBQ1N2M1gyOUFSQjRIUHpTZm9YL0tQRG9jQ2tp?=
 =?utf-8?B?K2l3YmRCbWNPL1RJTmdOSnhpWWRBRlRCZ01mYU1Ncm5BUlRGUDRPYTBCdHpX?=
 =?utf-8?B?K1FjajUxdGNjU2gvbmZqeCtHdVV1VWp4Uy9OWHdoTU56K1N3MGpma08wdmhq?=
 =?utf-8?B?Mmh5MGJDbk12OHdLMmQrcmwvbFhaU1JTaFRmTUcrVHpXMlF3YStBT0ZwWTBW?=
 =?utf-8?B?RlEwM29Ccm5nckdxd1dCVnBpZkJKZXk1bkhNMlBXNlBtNTY5S3RXaC8vWmky?=
 =?utf-8?B?NHM5MjZSR0ZLQmNiZ2Z1STdlUE1KSlBPSHIrY29EYm5YQ1JIaEdCajY1bGpl?=
 =?utf-8?B?Rys2TmJKRWFJdElkS3Z0MXVKT1N0N0hITjFEc2g1RnNtdzNTU05NRENiVDVV?=
 =?utf-8?B?TjkzeFFmdVJXWlpXSG5zS2hNNzI2UEZ2WFNaODhMMlNnSEZqdWlwT2N4S1J0?=
 =?utf-8?B?YXQ2RDVBM3g0VmoyOTc4M2srOVM4VHJGVlYwNlJBN3JUTEdJc2pUZlJ3WUV2?=
 =?utf-8?B?WCtpRVRvMjJXc0NXNFlGM2dZeVZFZDU4b01JUHVhNjgzTkhob2RrdlpYNlRi?=
 =?utf-8?B?UzhmTHlBNEVTbGJ4STlLOEEvaDhvVnY3ZWFTTDdKQkg3YnFkUy9WUmJYdzlr?=
 =?utf-8?B?Z1Z4U1QwZWVLc2RwU1Awdk9TQnNER3RsWExhY011b015VnlKMGtGc01JU25I?=
 =?utf-8?B?TjFyeDZHZElzRTVaR0k1amlLaVVJZWY2b0VaWlZOSHpISEFJUGlFQTNTbnM2?=
 =?utf-8?B?czFUT2J5eEpUS1M1QjRCcDBCYXV6bTdoZm15MjRUZTRxQU03eDE2L3Y4UmdD?=
 =?utf-8?B?MW50c3dqZ3NlTXNvNGx0YVM5L08xZk8yTitpT0ZSMWVMV21YdHJHN3lveGxY?=
 =?utf-8?B?UjlubEM4cnU1azFMeWxtMk9rTFBDSlYwSWg1a1dWQ0JJU2ozSnp5bGpLVlJY?=
 =?utf-8?B?S2V0bkJYSmhzNVVadzYwWGIzbmEzdC8yUUxZR0wxbVJCTm5tMGswRHJza0ZF?=
 =?utf-8?B?dXhLTEk2RUVPK0hJZDg0eHh6bGt2azhqTGRlTG1rYm1KaHFNelY5ZUlSY0o5?=
 =?utf-8?B?V1MwZkwxRkRSWHNEZGk5MWhCTi9JbzV6bDNKZkNudk1IVUY4ME5XUlE4eGlX?=
 =?utf-8?B?bGx2czhrdE0wRnYwWmVXT1I1VkFtbVJucVFnSU9qTGRRRU5NL2gyR2ZyRnhp?=
 =?utf-8?B?THlWS2YxVHpiYS91ZmdZVGpPSUhzNkgzVnh4Yk40aGJGc3VOeGNWMmhRa3Bj?=
 =?utf-8?B?MnlpN2RVR1JqemV3OTkwNEU4dUNyT0xEN2NDK1hQWWlCMTlJd0J2WVZXOFZH?=
 =?utf-8?B?MXFvUlh0a3Q3RFFoVHQ4UVV1Q0dZRlJwMm14SWZpRGpHaitrK0hqb21NZW1l?=
 =?utf-8?B?V1FUNFJxVWxlWFFtUXdkY1pLQnVHTWNpU2hReGR3d29VTTRHTHJjc1ltMk5G?=
 =?utf-8?Q?zwL0=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <775EDD7F0B117E4E8A345384CEA96933@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 37593698-957c-4bf2-fd47-08dd96a8fc2e
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 07:44:28.5729
 (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: x6TmfM9/gRsg5i7zPms4Ve/JkWb7gCo9WpwTs8pO3rVWAFdp9+Qt80rV+xiqEN/+DR6uxSgL0oyYGBRxyrdrNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR12MB9286

T24gMjAyNS81LzE5IDE0OjMwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMDkuMDUuMjAyNSAx
MTowNSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiB2cGNpX3JlbW92ZV9yZWdpc3RlcigpIG9ubHkg
c3VwcG9ydHMgcmVtb3ZpbmcgYSByZWdpc3RlciBpbiBhIHRpbWUsDQo+PiBidXQgdGhlIGZvbGxv
dy1vbiBjaGFuZ2VzIG5lZWQgdG8gcmVtb3ZlIGFsbCByZWdpc3RlcnMgd2l0aGluIGEgcmFuZ2Uu
DQo+PiBTbywgcmVmYWN0b3IgaXQgdG8gc3VwcG9ydCByZW1vdmluZyBhbGwgbWF0Y2hlZCByZWdp
c3RlcnMgaW4gYSBjYWxsaW5nDQo+PiB0aW1lLg0KPiANCj4gR2VuZXJhbGx5IEknbSBhIGxpdHRs
ZSB3YXJ5IG9mIGNoYW5naW5nIGJlaGF2aW9yIGZvciBleGlzdGluZyBjYWxsZXJzLA0KPiBidXQg
SSBndWVzcyBSb2dlciBhbHJlYWR5IGRpZCBzaWduYWwgaGUncyBva2F5IHRha2luZyB0aGF0IHJv
dXRlPw0KWWVzLCB0aGlzIGlzIHN1Z2dlc3RlZCBieSBSb2dlci4NCnZwY2lfcmVtb3ZlX3JlZ2lz
dGVyKCkgaXMganVzdCB1c2VkIGZvciB0ZXN0IHdpdGhvdXQgbXkgc2VyaWVzLg0KDQo+IA0KPiBK
YW4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Mon May 19 07:45:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 07:45:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989614.1373631 (Exim 4.92)
	(envelope-from )
	id 1uGvBg-0008BM-Us; Mon, 19 May 2025 07:45:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989614.1373631; Mon, 19 May 2025 07:45: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 1uGvBg-0008BF-Rh; Mon, 19 May 2025 07:45:28 +0000
Received: by outflank-mailman (input) for mailman id 989614;
 Mon, 19 May 2025 07:45:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGvBf-000854-Pq
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 07:45:27 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3ad0779d-3485-11f0-9eb8-5ba50f476ded;
 Mon, 19 May 2025 09:45:27 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-acb5ec407b1so685297766b.1
 for ; Mon, 19 May 2025 00:45:27 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4908cesm553063666b.132.2025.05.19.00.45.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 00:45: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" 
X-Inumbo-ID: 3ad0779d-3485-11f0-9eb8-5ba50f476ded
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747640726; x=1748245526; darn=lists.xenproject.org;
        h=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;
        bh=wcSg5UPLHL6rIvTqybciMnu5FShDp9d0RmBAadVtesI=;
        b=lSwedTRe3f8TH4MtzseUDnS7HRneWuGXJ3NHeO4uyVdIf6ZEsQFT2Zl1biGgek5d1u
         nmHOGR57Sve7wBhLe/rV5L1NsV67fBxEBHnuclcZqO+sIY/gYpN8X2LwzHwHMBkXVQ4E
         c4wjdNwfPSEmE+eEJc8KvB0xB1dcGPD0kQuM3iRdJZMKbw7to3lofJX6cRbgnNFRK416
         5Ede6lFh1QQWpNar3APwJ5z3g8cEW/mOmFq40OVFywzUII7pNRjow102OMV5/MX0QjOy
         oQ9sqEsJ0lUH35JiZtgpq5+/tZ4idjH50XNKBK4ei3JSv1pCh9W5OKWoycok7v9EiAFE
         ed6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747640726; x=1748245526;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=wcSg5UPLHL6rIvTqybciMnu5FShDp9d0RmBAadVtesI=;
        b=kYYMGXROFCX5XWgAG5EfqtJUnx0GdxNYcgUUwfEugawQyzs0yuNyFOMlO2LL+BHkPp
         YzYRwvjhTa5hWGyI/w0txFjiQT3d9EDzNkPvJSHPT58ePcH3cvbESZM0pra7yBuSLdJF
         cEo6EhZeL5DuVHb1xRtEV8lHPQrVQ4iGTlTaZWXDm3W4cTLlo2Kk/N5+Pxeq77uX2zju
         udzoby2UZQz8PGOTj44j2iAkOA+Yqn8WzD1rtReib6v/v+c5Xs9KdKi3XWzGaRXthHsV
         iMUMa13kUvp3AHforA6QwpgIF9ilvdC/ym+LYqKO6b5rHnBzaYJrD0eFJDcOisjCzsHp
         Eoqg==
X-Forwarded-Encrypted: i=1; AJvYcCVvb4lTyg5/L37UJJCgId7Q3qc3US2E6DSRm5purb27MJ20uZx1VH9jcKTh3xd0//E3N/t86M3T4Dw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwsqK4XehQ9JqkyaImCQS4O10jzT/fF1mM1VfBhVgWKIxFkWDU2
	vE7y7IKfdoWUJmdzLEsYz19hJ+Bae/dOun0gnk3Xk+4/aOOJxxKUyi0z
X-Gm-Gg: ASbGncuqjYNOI885A6+6TP4N980CV3zi6mrWDqYggjg5aKRNGtrAetSfJmUCDtZ1xHn
	v0QRM9cgqU1iu5++PA20R6iSXDgmc3ada1I9CmnycSKDzZk4q4nxorpqysMxvS6IABBI4RTk5pX
	awJYj0AU+dhY/bAeDM68yFi8R2bq9Azbx2nTugtXZ2waWQ3KXQ2GPf5gVQpiVSg4mlGjAdZDKZw
	8b/ESMPp0BMrlBNS8dTT+MnFfKhDFCqlKPzFPAd5WhOIlqV4WiXIru98cPg/MKXXjd8FrDgqv6k
	rC2jext8JTeqjNkNdeusYrGVIO2ZYncgnC4AN8DMW+NxPIhjNhkk9jVY3Rfv70Zy+u172dRF/tk
	Fuzn6Kzxas6lf9TbS3tP92qTbwpImz5WOHNQ=
X-Google-Smtp-Source: AGHT+IF38RlBYEyodhMYrUxfWDfdwW5VS+O0f8W/LQZyFu4sHcf5zmn61x7byJOIaF8ntAsGvS7Olw==
X-Received: by 2002:a17:906:230a:b0:ad4:f6d2:431b with SMTP id a640c23a62f3a-ad536dce6cfmr767896066b.44.1747640725751;
        Mon, 19 May 2025 00:45:25 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------aUJxhS7Ncp1fkvfo4wFfMZoN"
Message-ID: <145c4507-4810-42c7-b34d-76d256619037@gmail.com>
Date: Mon, 19 May 2025 09:45:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/6] x86/gnttab: do not implement GNTTABOP_cache_flush
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Community Manager ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , Stefano Stabellini 
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-3-roger.pau@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20250516094535.63472-3-roger.pau@citrix.com>

This is a multi-part message in MIME format.
--------------aUJxhS7Ncp1fkvfo4wFfMZoN
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/16/25 11:45 AM, Roger Pau Monne wrote:
> The current underlying implementation of GNTTABOP_cache_flush on x86 won't
> work as expected.  The provided {clean,invalidate}_dcache_va_range()
> helpers only do a local pCPU cache flush, so the cache of previous pCPUs
> where the vCPU might have run are not flushed.
>
> However instead of attempting to fix this, make the GNTTABOP_cache_flush
> operation only available to ARM.  There are no known users on x86, the
> implementation is broken, and other architectures don't have grant-table
> support yet.
>
> With that operation not implemented on x86, the related
> {clean,invalidate}_dcache_va_range() helpers can also be removed.
>
> Fixes: f62dc81c2df7 ("x86: introduce more cache maintenance operations")
> Fixes: 18e8d22fe750 ("introduce GNTTABOP_cache_flush")
> Signed-off-by: Roger Pau Monné
> ---
> Changes since v1:
>   - Introduce Kconfig option.
>   - Introduce CHANGELOG entry.
> ---
>   CHANGELOG.md                        |  3 +++
>   xen/arch/x86/include/asm/flushtlb.h | 19 -------------------
>   xen/common/Kconfig                  |  5 +++++
>   xen/common/grant_table.c            |  6 ++++++
>   4 files changed, 14 insertions(+), 19 deletions(-)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 1ea06524db20..21d7be0aa389 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -24,6 +24,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>       - Ability to enable stack protector
>   
>   ### Removed
> + - On x86:
> +   - GNTTABOP_cache_flush: it's unused on x86 and the implementation is
> +     broken.
>   

LGTM: Reviewed-By: Oleksii Kurochko

Thanks.

~ Oleksii

>   ## [4.20.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.20.0) - 2025-03-05
>   
> diff --git a/xen/arch/x86/include/asm/flushtlb.h b/xen/arch/x86/include/asm/flushtlb.h
> index 209ea1e62fae..cd625f911436 100644
> --- a/xen/arch/x86/include/asm/flushtlb.h
> +++ b/xen/arch/x86/include/asm/flushtlb.h
> @@ -184,25 +184,6 @@ void flush_area_mask(const cpumask_t *mask, const void *va,
>   }
>   
>   static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache) {}
> -static inline int invalidate_dcache_va_range(const void *p,
> -                                             unsigned long size)
> -{ return -EOPNOTSUPP; }
> -static inline int clean_and_invalidate_dcache_va_range(const void *p,
> -                                                       unsigned long size)
> -{
> -    unsigned int order = get_order_from_bytes(size);
> -    /* sub-page granularity support needs to be added if necessary */
> -    flush_area_local(p, FLUSH_CACHE|FLUSH_ORDER(order));
> -    return 0;
> -}
> -static inline int clean_dcache_va_range(const void *p, unsigned long size)
> -{
> -    unsigned int order = get_order_from_bytes(size);
> -
> -    /* sub-page granularity support needs to be added if necessary */
> -    flush_area_local(p, FLUSH_CACHE_WRITEBACK | FLUSH_ORDER(order));
> -    return 0;
> -}
>   
>   unsigned int guest_flush_tlb_flags(const struct domain *d);
>   void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask);
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 6d43be2e6e8a..563b036474c0 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -35,6 +35,11 @@ config GRANT_TABLE
>   
>   	  If unsure, say Y.
>   
> +config HAS_GRANT_CACHE_FLUSH
> +	bool
> +	depends on GRANT_TABLE
> +	default ARM
> +
>   config EVTCHN_FIFO
>   	bool "Event Channel Fifo support" if EXPERT
>   	default y
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index e75ff98aff1c..cf131c43a1f1 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -940,6 +940,7 @@ static void reduce_status_for_pin(struct domain *rd,
>           gnttab_clear_flags(rd, clear_flags, status);
>   }
>   
> +#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
>   static struct active_grant_entry *grant_map_exists(const struct domain *ld,
>                                                      struct grant_table *rgt,
>                                                      mfn_t mfn,
> @@ -975,6 +976,7 @@ static struct active_grant_entry *grant_map_exists(const struct domain *ld,
>   
>       return ERR_PTR(-EINVAL);
>   }
> +#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
>   
>   union maptrack_node {
>       struct {
> @@ -3520,6 +3522,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) uop,
>       return 0;
>   }
>   
> +#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
>   static int _cache_flush(const gnttab_cache_flush_t *cflush, grant_ref_t *cur_ref)
>   {
>       struct domain *d, *owner;
> @@ -3631,6 +3634,7 @@ gnttab_cache_flush(XEN_GUEST_HANDLE_PARAM(gnttab_cache_flush_t) uop,
>   
>       return 0;
>   }
> +#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
>   
>   long do_grant_table_op(
>       unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
> @@ -3773,6 +3777,7 @@ long do_grant_table_op(
>           break;
>       }
>   
> +#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
>       case GNTTABOP_cache_flush:
>       {
>           XEN_GUEST_HANDLE_PARAM(gnttab_cache_flush_t) cflush =
> @@ -3789,6 +3794,7 @@ long do_grant_table_op(
>           }
>           break;
>       }
> +#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
>   
>       default:
>           rc = -ENOSYS;
--------------aUJxhS7Ncp1fkvfo4wFfMZoN
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    

    
    
    
    
    On 5/16/25 11:45 AM, Roger Pau Monne
      wrote:
    
    
    
    
    
      
    The current underlying implementation of GNTTABOP_cache_flush on x86 won't
work as expected.  The provided {clean,invalidate}_dcache_va_range()
helpers only do a local pCPU cache flush, so the cache of previous pCPUs
where the vCPU might have run are not flushed.

However instead of attempting to fix this, make the GNTTABOP_cache_flush
operation only available to ARM.  There are no known users on x86, the
implementation is broken, and other architectures don't have grant-table
support yet.

With that operation not implemented on x86, the related
{clean,invalidate}_dcache_va_range() helpers can also be removed.

Fixes: f62dc81c2df7 ("x86: introduce more cache maintenance operations")
Fixes: 18e8d22fe750 ("introduce GNTTABOP_cache_flush")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - Introduce Kconfig option.
 - Introduce CHANGELOG entry.
---
 CHANGELOG.md                        |  3 +++
 xen/arch/x86/include/asm/flushtlb.h | 19 -------------------
 xen/common/Kconfig                  |  5 +++++
 xen/common/grant_table.c            |  6 ++++++
 4 files changed, 14 insertions(+), 19 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1ea06524db20..21d7be0aa389 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -24,6 +24,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
     - Ability to enable stack protector
 
 ### Removed
+ - On x86:
+   - GNTTABOP_cache_flush: it's unused on x86 and the implementation is
+     broken.
 
    
    
    
    
    LGTM: Reviewed-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii


    
    
    
      
     ## [4.20.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.20.0) - 2025-03-05
 
diff --git a/xen/arch/x86/include/asm/flushtlb.h b/xen/arch/x86/include/asm/flushtlb.h
index 209ea1e62fae..cd625f911436 100644
--- a/xen/arch/x86/include/asm/flushtlb.h
+++ b/xen/arch/x86/include/asm/flushtlb.h
@@ -184,25 +184,6 @@ void flush_area_mask(const cpumask_t *mask, const void *va,
 }
 
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache) {}
-static inline int invalidate_dcache_va_range(const void *p,
-                                             unsigned long size)
-{ return -EOPNOTSUPP; }
-static inline int clean_and_invalidate_dcache_va_range(const void *p,
-                                                       unsigned long size)
-{
-    unsigned int order = get_order_from_bytes(size);
-    /* sub-page granularity support needs to be added if necessary */
-    flush_area_local(p, FLUSH_CACHE|FLUSH_ORDER(order));
-    return 0;
-}
-static inline int clean_dcache_va_range(const void *p, unsigned long size)
-{
-    unsigned int order = get_order_from_bytes(size);
-
-    /* sub-page granularity support needs to be added if necessary */
-    flush_area_local(p, FLUSH_CACHE_WRITEBACK | FLUSH_ORDER(order));
-    return 0;
-}
 
 unsigned int guest_flush_tlb_flags(const struct domain *d);
 void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask);
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6d43be2e6e8a..563b036474c0 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -35,6 +35,11 @@ config GRANT_TABLE
 
 	  If unsure, say Y.
 
+config HAS_GRANT_CACHE_FLUSH
+	bool
+	depends on GRANT_TABLE
+	default ARM
+
 config EVTCHN_FIFO
 	bool "Event Channel Fifo support" if EXPERT
 	default y
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index e75ff98aff1c..cf131c43a1f1 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -940,6 +940,7 @@ static void reduce_status_for_pin(struct domain *rd,
         gnttab_clear_flags(rd, clear_flags, status);
 }
 
+#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
 static struct active_grant_entry *grant_map_exists(const struct domain *ld,
                                                    struct grant_table *rgt,
                                                    mfn_t mfn,
@@ -975,6 +976,7 @@ static struct active_grant_entry *grant_map_exists(const struct domain *ld,
 
     return ERR_PTR(-EINVAL);
 }
+#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
 
 union maptrack_node {
     struct {
@@ -3520,6 +3522,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) uop,
     return 0;
 }
 
+#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
 static int _cache_flush(const gnttab_cache_flush_t *cflush, grant_ref_t *cur_ref)
 {
     struct domain *d, *owner;
@@ -3631,6 +3634,7 @@ gnttab_cache_flush(XEN_GUEST_HANDLE_PARAM(gnttab_cache_flush_t) uop,
 
     return 0;
 }
+#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
 
 long do_grant_table_op(
     unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
@@ -3773,6 +3777,7 @@ long do_grant_table_op(
         break;
     }
 
+#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
     case GNTTABOP_cache_flush:
     {
         XEN_GUEST_HANDLE_PARAM(gnttab_cache_flush_t) cflush =
@@ -3789,6 +3794,7 @@ long do_grant_table_op(
         }
         break;
     }
+#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
 
     default:
         rc = -ENOSYS;

    
    
    
  


--------------aUJxhS7Ncp1fkvfo4wFfMZoN--


From xen-devel-bounces@lists.xenproject.org Mon May 19 07:49:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 07:49:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989624.1373640 (Exim 4.92)
	(envelope-from )
	id 1uGvFU-0000Kd-Do; Mon, 19 May 2025 07:49:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989624.1373640; Mon, 19 May 2025 07:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGvFU-0000KW-BE; Mon, 19 May 2025 07:49:24 +0000
Received: by outflank-mailman (input) for mailman id 989624;
 Mon, 19 May 2025 07:49:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGvFS-0000KQ-OQ
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 07:49:22 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20611.outbound.protection.outlook.com
 [2a01:111:f403:2009::611])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c5cde4dd-3485-11f0-9eb8-5ba50f476ded;
 Mon, 19 May 2025 09:49:21 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DM3PR12MB9286.namprd12.prod.outlook.com (2603:10b6:8:1ae::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Mon, 19 May
 2025 07:49:17 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Mon, 19 May 2025
 07:49: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" 
X-Inumbo-ID: c5cde4dd-3485-11f0-9eb8-5ba50f476ded
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NX/uxJl2EMtyqnP6EqyFSDs0MSiP3zUCz5wJG4zpR5MOvJRw/w/N+7fCFL0UIFgoqZdzus31mSvfVa/9o/Jg+U9D8sNzUsHtL2TWbVSyh0ORvf4XSB25J6Lz4JZGoeNvNqDSRkfgmI+zh+H7uNROAEaAYe3KHHEeXYVnIPiHd/nB2t7/QvkTOa1UYvxr6WLNBvnvrh6kCjpsm8JHlMSqGE/9qiDg5R6NTs/h6vWvaCNTo7KSehuGqOj+1VCo/BkHuiSFPLgHiqIChEldGAsp1Jy2oEdrMloyKzj68Z+OJtAGq6JqagUe1ezWZO+69E4tZSpXBwDR3wplUlEXBHQKjQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YRuy3wektnG2j1QDmSmqn7HZ7BnVThQbQrgg1+poX4Y=;
 b=b/soKVF7X+fMntZ+NAkrxL8ODcjVrFaJAQBpXZl/kNOPMfDqOo79JuO/9k5zGaPI9HkQbGn9+fpCqbCUY/YLEClqFFPEWecGfH8Q8tLyyguPUxwwkpwUSA2oKTmKVFZrm5V6SH4swlIGzxsZu4ESTAy3Jzwiuny9byBmoAZTeB/U1Du+N2x0ktsJfNMNIYK2Uks7QZ12UdhwZE6vajSH0iOe5/sYpmxRGsPGVDYGlEMAmDaY3YkvufSOetsXDZVkxUjCcVtcGQmitxJiXea0zTPBmQ4UY1MH+G7TVZWLG3VXHSKVJHZxCWYi1coByNKhWW0p7a+20OtylLJYoyA79g==
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=YRuy3wektnG2j1QDmSmqn7HZ7BnVThQbQrgg1+poX4Y=;
 b=NdvE8+hd41twlJsq8c6kcrWc5iXGMC0J9ZyVOcOdy66/0YwRdGw/rdtqZKMJBD8Qe+YeOqLiJ8vuoxxLwT+SRH1EEZcIDXlin8yyKttbrW65xa/WDsvZq4P71J99iS9dTZc8xS1ZrOfsF2HVWMZzNlhboOjb0PHSsH2i0ucH7xk=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "xen-devel@lists.xenproject.org" ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "Huang, Ray"
	, "Chen, Jiqian" 
Subject: Re: [PATCH v4 08/10] vpci/rebar: Remove registers when init_rebar()
 fails
Thread-Topic: [PATCH v4 08/10] vpci/rebar: Remove registers when init_rebar()
 fails
Thread-Index: AQHbwMGht1D1H8X23kq6XrWFn0smo7PZlEAAgACVAwA=
Date: Mon, 19 May 2025 07:49:17 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-9-Jiqian.Chen@amd.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|DM3PR12MB9286:EE_
x-ms-office365-filtering-correlation-id: 97e6749d-1191-4a3e-1148-08dd96a9a86a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?NUVnZHB5T2tnbXFvNkNFVzRYYTJrK0hPZ0wyUlo4bXFhVkRsWHZSQnRaVUN1?=
 =?utf-8?B?cFpSV2lPanBOOE9PUXZSSVpSMlJYTlBYTUUwYVVuSG1WcGVDM1M0eVlCRXZw?=
 =?utf-8?B?dGxVY1JCa0h3UWV0V05sLzZRbTgzcVRUQnpRK3RRcXdSTC94b21CK2ZPR2NI?=
 =?utf-8?B?bjBKVi96azNmQjJ4c2N4cE45cGpFRktqRWI1ZmJmUVBoSkk0UGpHNFFVTmY4?=
 =?utf-8?B?OGxLeGNxUE1Cb2NvN3RMMmRaVGN1ZDlxY3Nmc05ZQTJTVmUyNFNBY2RHY3NJ?=
 =?utf-8?B?Mlc2K05FTXBNdGZoWDNxSDdRcVNaaEhHa1JObmQ5SzYzTFoxQzZBT2dGUUtz?=
 =?utf-8?B?dzd2R3BVeHFWeWQyR0Y0aU1jV0ZHMmVWdkg3YWphNm80MWM5dk1RUStqSHZs?=
 =?utf-8?B?Q3Y4ZVIyNklMR0NZVXhqZ0kwMStUZ1VMVTZBSFg2R2Y4aXNoMCtuRnpQZ245?=
 =?utf-8?B?SFQ5VW1XTG9XcnJnM0JXdkJTRnBvR2twbDlNbSs0Mm1aZXVXSi8zRXZFdHBT?=
 =?utf-8?B?OWRIRUxBeklHN1NVYTF6UU5tMnMwMEZ6Rnc0YUZ0c0h3OUNYeTFQL3NYN3BF?=
 =?utf-8?B?NXNUL3NwOGp5TGZKeWdDN1lQZGdIU3ppTEtHdHVjcHFJbXJiVWhzOHVJWEk0?=
 =?utf-8?B?VXg1ZmhCSzdpdWlZT2prT1ozRGRwZmZtM3pHQzJra3hIV0RDeDkxdFZXOWVn?=
 =?utf-8?B?ejZhL0gzYjlER1loNDhJUkJPK2tyU3Y1QzQ5OSsxa2JwdSsvYWNPdDhTczAw?=
 =?utf-8?B?a2lTQ3gyQTBBalZKdnBUbkZHS0JpbmxXNWFmRHlMUW8xMWFoL2V5aHd4NTNp?=
 =?utf-8?B?Z3d5VzRVZ0ZWUmo2cVhlVW1nYWFJNjVRWEMwOFlmNC9ReG16VnRKNWx6WWcr?=
 =?utf-8?B?NElLcG9ROWVLVHVFeU9ra0hTVStzMHdGU09tOVoyL1BJa0hHanlTZW9xQVVN?=
 =?utf-8?B?S1gwQW1CWFkrOWF3MW80SUdQckdzUm1lSnhVeWxjNTh5RmVJS25KSDlRQlpE?=
 =?utf-8?B?OFcrN0pqc1I0T2ZIYS8rbFhrUXpONC9uOG1ScHdXN0dXUGVXd0UxVm1CVnRV?=
 =?utf-8?B?aVJYR2JiMS9tbnVlVmhwdUZWbmZJWkxoOXQvSXdLNkd4cjJqamExd0pDRG5C?=
 =?utf-8?B?S0htVUplYVlGQStsb0E1SzFpMlZ0dnV1M29Xb2pteDAwTHk0TnBlZE5PaG1P?=
 =?utf-8?B?eDVGZUJJWTQ1NlBpWTY4RjUvekN3WlVsTXdwdllyaUxrV2JjWjh0UGljS2pm?=
 =?utf-8?B?ZmJsZXQ4VEljKzZHQnZBeXVOTUVzajRySVczRTc5Y2pManZiLzdxVDNwbFpt?=
 =?utf-8?B?NmRDb2JpK3NmYlhKQmE1N3ZrUnQxRXUwV05XanlkL2RqK0JXcndLYVRxSFlq?=
 =?utf-8?B?eUZGSG5WaFNkZXZCUm5aaXRFWXNpaXlqVHpyaTZVc1AxMXJCc2ZHdzA4ekpH?=
 =?utf-8?B?NnRpUVVObnV2MWhaTE1mcnE4a0d6RjVnNDZHc2pQbHplQklvYy92WmpUbkgy?=
 =?utf-8?B?d0RmYVNOckxnMzltSGl5OTVmZXQ4a3gyYU12ZFZ5NEFpMjMyREh6TDlaQ1ov?=
 =?utf-8?B?M2tLU2NoVDhmaUFLWHlrSDhMK3R5T2g4T3Mvbk4wNGhubkUyTHhDMlV4NUdv?=
 =?utf-8?B?eFFDa2ttV3ZWZ0xEV2plTGtDQ2tucjRvSVJSMFdZMHR5VTFBd1laNlFWR1Fh?=
 =?utf-8?B?Vm1SdUppenBWRWdDcWNFTmcvSXFENDc3QlIxbDlHcjd0UGtDQXBWdG9pKy8r?=
 =?utf-8?B?ajZXME5wdjF1RzJOR0t6SHhsSlJ2dStUK3M2UmFXT0JUcm5hR3d5SUI1bDRu?=
 =?utf-8?B?VWlJZ2l4STZBMDFjbXc0a2pPaDhwdzB5OVhodGpFMlU0MThQNDFOSWpZRS9j?=
 =?utf-8?B?NjdtTW05cUNxMTNPRGI1R0FMTGdDT3RSWU9wclhOZ3pwRlY4WEVBSEhVWUVS?=
 =?utf-8?B?YVNUMXRraFZxTGxmbGE4NjZOVzRjOXFiU0VBb1pRbW5SUUNMZ3Y1U0lNekoz?=
 =?utf-8?Q?/8tNU/mK5rtx7X9FhhqKM3F3RceW9I=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?c2xZQzVJU0lMVmMyZ3lOWndUQXhBZjVZTnRjbmdkTFBidnIyVzBRWUJDZ2x2?=
 =?utf-8?B?NkJFM3J2Um9nZml5bHFvYUpPeHMrSGhQNk93Q091bmFNTXhDTW5Gbm9DYTRM?=
 =?utf-8?B?L3F0dzFKa2Z6bFpQU1V4ODVGdjZRREtLbkVVYk1SL2UwRXBvaTNySjlZT29j?=
 =?utf-8?B?OVpIbkEzQWQyQmpMMUNKQ2xnNzhLSzNINSsvSm1QTENtQ0g1YXA1M2E5VmVS?=
 =?utf-8?B?VlFwbE9GV0cvRmpEZUNUc2kwd3U2UHBqZWppaUFPeXF0b2gzTFJpYUlKVXhV?=
 =?utf-8?B?U2FkUkZmemFmWTZNR250Yk9xSExzU1VpbEZLOUJqK3lVSGh2L0s0Y3lNRHho?=
 =?utf-8?B?VEc2MFd4VGtiUk5yUHhlenByQVNUcExRZmNuK21DeHhlUzZNbDBYQXRUQjlW?=
 =?utf-8?B?ZDNyd3FUWGZuRENSanZOZE9VNS96MVVMZ2FpUUpCZjNkcDBESDNoZ1BJMHNr?=
 =?utf-8?B?b2JXOWpqVExUeHl4Q1NrZnJyOGR2UmpURVlXYzArNnBwUzFHOXZxcXdvQlZ6?=
 =?utf-8?B?L2xSYlJxUlhnVUhUS2xMbXpwV2pQK1FxZGxxd0l3SEJtOW45RlN2SVhRckpB?=
 =?utf-8?B?UERRZTl3U1JBbGRybklPeVpTYkVDRUVqV08vdkhLN0l6MG5NSVdwWmZCQmFN?=
 =?utf-8?B?NERyUmNEMktXekJGaWRwalZUTXM4dlFTQ0pYYnhGUFppcnFUKzdkODR6QUhH?=
 =?utf-8?B?Vk0rWGY3VzdSb2NlYy8wekM3b2I1MitYcGQ5RG5YMlM2WFFyVmZPM3Z5VUZW?=
 =?utf-8?B?SVhES2dNc0VpM3crZ3ZZb2VPSHQ4VElNYkZGOHp3L0Nrend2aG4vNFFjNml6?=
 =?utf-8?B?aGFXemcwcll4Y1FjQ3RPUlovUkRtT2lmYzRMUStMblR4elhZL3VkRjA1UGhV?=
 =?utf-8?B?a3ZtRVQzYjVkcC84SDhZS3V5V2pnaVUxNkFPUHVlWUlSUmwyaTBTb0VqdGJk?=
 =?utf-8?B?QUE4ZzNBbHM3Vk9GWlcvVkdLNVlma25sM2k5T1NEYVpuSkNGQzNEMGxyT0Zk?=
 =?utf-8?B?eEx6UEsyUkdzYkg2clE3QVpxODdlMHRPK3BwVys3Ukl1L2Z3ejU3QnVTa051?=
 =?utf-8?B?UzRCTnhSSjVRWnNvdEg3ZktKR0Q4ZHU3dXk3REk3Smg4a1VoenFYSUIyVlRs?=
 =?utf-8?B?K0o1aktoWFNnbXB2cXptWE9FdS9OWFhiUE9pcjl6RXhtbEFCSkZZcHRQL1VM?=
 =?utf-8?B?NzIrOXBYZmNtNUIrb01nWE5BSDFDempFekQ3eENQRVFjdURxcDlzazRmQ1JF?=
 =?utf-8?B?djdiUGVKNG1scXlXTG9XQnBxQ3ZwRGVrbVhVSXlkK2k4QTVEcE0vVjJRU3hB?=
 =?utf-8?B?bElzcG9mYmIzSndXZXpPTm9iV2tnWEZDOTEwZzR4U1NsYk96RFF1enNFcVBk?=
 =?utf-8?B?eisvRlVvMXdOQWhacHg3Tys2TDVOcHFvak8rSWtrR3JFMWJBNGNPL2M2T3FU?=
 =?utf-8?B?TVdPenMvL241ZUl1Y3c2UEJJUmIyYkYwV1ZkQlFpVEQyVXBzdG5vVGFPQlVY?=
 =?utf-8?B?elRSaWZOWHF1VHNCZVdqdC9zaDg1NGY5T2tuVnhIajY0L0V4N2FXWVFtTzBH?=
 =?utf-8?B?L3JvSENHc0FZMG5NVWdYbEJoTENHam9SU0tMNlo4OHRFbU9yUDFuakx6S1Fp?=
 =?utf-8?B?K2JMdndtc2dIY3hLdk9CbHVYLzQycGdOVFdxeFJHWG1nMko3RXBuQThraVIw?=
 =?utf-8?B?dVhPNUw0QTBRMGZmOUFpdi80ZnBZS1d0SUEyc1ZnRExHWnV3Nk1vRy91dFpk?=
 =?utf-8?B?QmtWMFlBT245WEVBZVdxWXhNQlRVWnNUeFZOZ2ovbGJrenFBNTNPeGZhZTZ4?=
 =?utf-8?B?dUtRemNneXV4d2NMVWRNRlA1TjloM0MwcGxZZjJXbHhpdVpqK1hZUVBFVFVz?=
 =?utf-8?B?cGM4SUV3clI0dkVxYUd4THltTlRxbFBhaHJJWGhGL2FqeDFEZzlHSERKRThT?=
 =?utf-8?B?dnIvZWRIRWtMNm0xUWVGenlEa3J5Wk1NUy9JQ2JZUEYxU0hMWHBYWkxPZDdk?=
 =?utf-8?B?RGJQQTVzYlVaOGplTXVnMFJKRk9ydjJ1U0NWbGFKWXJlNllqbGFrczhNNmhB?=
 =?utf-8?B?Q1E1OGkwcm5Wb2pHNHdWN3BuUUYxdjFGMDNES1dhKytmQWRnOGo2SC9OOUdQ?=
 =?utf-8?Q?jExw=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 97e6749d-1191-4a3e-1148-08dd96a9a86a
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 07:49:17.5253
 (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: aYzxK+OxG8wUwxFaeXSfSwLT9cOvqR3MMG66UiNdwFBzhU5K7pG+GU4ASuTiJqM7v9jWwwy5ar196kFA7NT8Xw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR12MB9286

T24gMjAyNS81LzE5IDE0OjU0LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMDkuMDUuMjAyNSAx
MTowNSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL3JlYmFy
LmMNCj4+ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvcmViYXIuYw0KPj4gQEAgLTQ5LDYgKzQ5LDI2
IEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIHJlYmFyX2N0cmxfd3JpdGUoY29uc3Qgc3RydWN0IHBj
aV9kZXYgKnBkZXYsDQo+PiAgICAgIGJhci0+Z3Vlc3RfYWRkciA9IGJhci0+YWRkcjsNCj4+ICB9
DQo+PiAgDQo+PiArc3RhdGljIHZvaWQgY2xlYW51cF9yZWJhcihzdHJ1Y3QgcGNpX2RldiAqcGRl
dikNCj4gDQo+IEp1c3QgdG8gcmVtaW5kIHlvdSB0aGF0IGFueSBob29rIGZ1bmN0aW9ucyBuZWVk
IHRvIGJlIGNmX2NoZWNrLg0KVGhhbmsgeW91IGZvciByZW1pbmRpbmcgbWUuIFRoaXMgaXMgbXkg
Zmlyc3QgdGltZSB0byBrbm93IHRoaXMuDQpJIHdpbGwgYWRkIGNmX2NoZWNrIGZvciBhbGwgY2xl
YW51cF94IGluIG15IHNlcmllcy4NCg0KPiANCj4gSmFuDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0K
SmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Mon May 19 08:37:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 08:37:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989648.1373651 (Exim 4.92)
	(envelope-from )
	id 1uGvzP-0007V1-Ux; Mon, 19 May 2025 08:36:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989648.1373651; Mon, 19 May 2025 08:36: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 1uGvzP-0007Uu-RF; Mon, 19 May 2025 08:36:51 +0000
Received: by outflank-mailman (input) for mailman id 989648;
 Mon, 19 May 2025 08:36:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGvzO-0007Uo-Ig
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 08:36:50 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20626.outbound.protection.outlook.com
 [2a01:111:f403:2009::626])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 66984309-348c-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 10:36:48 +0200 (CEST)
Received: from IA1PR12MB8467.namprd12.prod.outlook.com (2603:10b6:208:448::9)
 by LV3PR12MB9215.namprd12.prod.outlook.com (2603:10b6:408:1a0::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Mon, 19 May
 2025 08:36:44 +0000
Received: from IA1PR12MB8467.namprd12.prod.outlook.com
 ([fe80::1633:cc45:8177:a91e]) by IA1PR12MB8467.namprd12.prod.outlook.com
 ([fe80::1633:cc45:8177:a91e%4]) with mapi id 15.20.8746.030; Mon, 19 May 2025
 08:36: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" 
X-Inumbo-ID: 66984309-348c-11f0-a2fa-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jb6/6mtDTq7sXiL32odoLb3YYJUiPoN4E8kUAHtB2YMU8sO91T8CddulkDZvy5ciLou6nL1y/u/rbVj2LaDpBOrci+ataYYV0bzrpMWArmrc3v3nsfH8avimVyJIUCitwNqOx9rfjuXjY3mGNUzBljXVDUbzC/CgGjBP+KsamWYSYksLw9nHiIvh0MZbzUTHFg/bLqmxIY0QZYzea86P26A5P7zFTlT4oqFoa+qOlz07PXwG1Khdgen96FTavnrsENDxM0/pVe9aJThybXw8WfELj/Lxjna4f7S6ESnqopfgi37uIKMa+DHKD9toJ+mkemNPLRggD7oxO8ld4qcD9w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Gns/AnUio66ezaanr2QOzkBfgwoCi6WD1aIav/++4Yk=;
 b=xB7vjTwPsBL/2qeD6bDiv3qavh2iVP+BI1gwgxTgk6P8AoGcnm3D/hnrPMhr+cpQswS9Z5rTYibLf/h0IV46XmelgiAk+TTQR+GU630selYi6k4K4XK5h/hwLI5DBZuWB4zstPkHECUjn0OlLP48bn9zpk09FOr5/lp0QlLIJ4mvAie+3v6FAVTm9tENGSI+Wvw1NFC6Q78NT8FeHZWtSVdmYCgZsZf49ex4Zeq3EBBvJzuoWHHDvaXq7PePC61zpyjBAYFYhX/aFu8Gr6gGP1vq5hY7U68RDKKWrMbp+0/5JoYNUOFrRyoPGeIf0a/ZycPSvxelIKa184izxzKJZQ==
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=Gns/AnUio66ezaanr2QOzkBfgwoCi6WD1aIav/++4Yk=;
 b=lmnT/i/rPLXV2QVwsuD9DQ6MrWb4Wxxjjb22R+0ldRoDVQJVKLKL/wsdttxPk7oIbcpNAEjx5Oe4C0qNnDB3/mPJUsdQUoQrK6/KWvN62Bwo9ZAyh3FxJb/NuE12saWBzPdSW+rwbmcr/CA6XTttjqUNYuvzhFbRpXIDIhsUvDQ=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Topic: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Index: AQHbrRCmtZ7pr/knH02upOrsNIOYE7O6sNeAgB8mXDA=
Date: Mon, 19 May 2025 08:36:44 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-6-Penny.Zheng@amd.com>
 <57a3b2c0-d57d-46e3-b248-0e243f715423@suse.com>
In-Reply-To: <57a3b2c0-d57d-46e3-b248-0e243f715423@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=7c77b369-f1ed-460f-8fce-0b55394e74f5;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-19T08:36:37Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR12MB8467:EE_|LV3PR12MB9215:EE_
x-ms-office365-filtering-correlation-id: 02a42c10-da96-40ae-5dac-08dd96b0493a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?a2lQczFMUG9QdzVvUkJRaTluRnFsb09hQnRBNEcyMlpqYmVIeEVQVEdrYVFj?=
 =?utf-8?B?aVMrSUpiMm5vTGJMR3BYNGFzZ3lWSndxZ0FKOWthbUg2YXZ2NjJYVWQyVTQ2?=
 =?utf-8?B?UUpxeTVyZHBpbHVsb29KN2hRVkkwTUNMMlU1R3JrN0JhbWhpb3NySUMzOTlY?=
 =?utf-8?B?LzJIZ05LdVhqc1hjN0puZXJBNTJFWXNmclBrQmNjcUo4RktXclhJaG9kcDRz?=
 =?utf-8?B?ZXNzOUtUKzlrY2xRbVY1QlhPeTd4b1kyV3c0VEJFVU9LbmxIcDJEcnAzMUJI?=
 =?utf-8?B?am9ncDJDaGxVVWR5bGN1a0F4elFabkNUaDk4QU9TbUpNRFkzbkdMSHJ2ZWpt?=
 =?utf-8?B?bHFyL1VBak1nMUNkYjZGL0ZjTnh0Q1I5RW5pd3pqZWxFcUhEN0N0V3hTcUVj?=
 =?utf-8?B?amNpOUVWSUhmTkVrVS9xWkx5aFlOcUpjYlE1Z3F3eWNaQ2ZlT1c4QlhmZ0Iv?=
 =?utf-8?B?R1BHQzBqNzIvUXluRnQrZk9nNlJhRTVxRTZXUmw2YlN6NjNBZEt4dCtOeXBh?=
 =?utf-8?B?djArbWlxNXNmTFlVcXUvcnhNeGRPMXZvUEY1S1p5c1hGQjdTWVpMZmE5UGlm?=
 =?utf-8?B?U0tUZGs0Z3Q5dFAxUlVSZEx3RGYwTFZLRGpRZklERGFIVmlqYU14Q2xxYzhn?=
 =?utf-8?B?ZUl1bEdVTlBZa1RORU1mSmNDMHNHTkhBYUpHVHRnRGg3c2RnNXdvQUM1cm56?=
 =?utf-8?B?d1V5c1pwWWpudk1RM3l0YUlGVFRxRHV0ZjRlUWdsdWQ2dzl5V1NUdjRvZFFV?=
 =?utf-8?B?K2Fjay9rYndIUisweWNNaVl3WjZWZmxXY0pmak55MGNhTjVwdWNwa0dTc0hj?=
 =?utf-8?B?Uk1zeUtGV3dCZTA3UGQyN3AzN3JNTkxaVWdRWXJwSE1GSzRLZmRaRTB1Y09W?=
 =?utf-8?B?MmZ4bjQ3Z3ZLZ0Y4bStiM3R5VkQ5UVJndWxibVlYSFdIZ2luRVhWRFBja0t2?=
 =?utf-8?B?Nng0SEl4WGJLM2JiaStZU1F3RTUyU3QrNkFBZlZvQ0k5VVFiMUpyT1J3WDVy?=
 =?utf-8?B?c1pUTm5uVWt4ekFYaWNXUk96NTFnYUcrRng1M3dRNFNHR0dVU2ZqUXlJWUpM?=
 =?utf-8?B?SFlCVnM1ZjJOVmYxSzcyWHdRREpZblkvU2RLRUdXRkNtbW85dkFwdXpnMFFV?=
 =?utf-8?B?WGtxQmtWc2tXRzlNTldmSi95VnpTQ3FYenRPUWNqS3N2WjFjek5aZlhiTVcy?=
 =?utf-8?B?Z0lCeWNsTTd3NGNNNXFDTTFDTkgzMlRQQTRiTE1TMWs4V1pKbDJhdzNHRTBv?=
 =?utf-8?B?b3krMG84S2cxQUlmbVQ0T0ROejJyK1FXT2c4TDdtS0ZXbE91SmllYmdoOHdM?=
 =?utf-8?B?aWFpeUxxcEFZa3NlTjZWc2s3RFVNcVp2R0d6Z2pUcDBzN2N5N3dIbkY1UDc3?=
 =?utf-8?B?b0VhZUlRSXpwMWdJb2p3MDlrQmsweDlCTks4Q1lUa2pNZUVHWXN4aFNuWUdX?=
 =?utf-8?B?VjRyRk1yRWt1QVBSTDlEMDNxS2d4bnlHa2pBOGlibGdLYWcyMklZUG5uVFEr?=
 =?utf-8?B?dnpYWVlGZmJ4NDhUVSsrQVR5S245MlFXZnJNV25MRWJreTMxL2doZ0w0dDBs?=
 =?utf-8?B?VzJwS3BxZXllNUEwSHN6ZnAwanh3VXZrMUpYWEE5UStFekJTd2VRQjhOSGFs?=
 =?utf-8?B?RW5xNWhEQ0cyTGo1RFFHZmZqb3BqSUs5SzBjeHNURTlOZmpJRWZEYWZ0Q1Vy?=
 =?utf-8?B?a1h1Z0UzamdqS0xkTHRxaUd6ME11OEtHZnFWSWhKam9MdGRKclVjUjNZekhT?=
 =?utf-8?B?NWt1dFJMdjFUM0NwTDJEZmFtMHQzUHRMWlNxeXNORVdMVkdmZ3lHangwdFRO?=
 =?utf-8?B?OExvRWUwOGtYMWZBb0VnVVp6a3dKNlBuK1BpdlUrR2oxbzVoNE0xMVhTMVpX?=
 =?utf-8?B?S1hCUTlEZ1QxVjAvYW5rQ3BlakhTOG4yKzFEM09wU3I0bHF5YUk3VlBuRHhH?=
 =?utf-8?B?NlVycWdoem05WDhnOFM4MHU0Qk9DdTdoQU16K3M5L1QyZzVqWVlqNnVBOUtS?=
 =?utf-8?Q?p+43uJcu0jCqse00UUSvaTQBW/AM1Q=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR12MB8467.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WUFKWHZZY1BmZ005VUpPZHpydG01SGhCQ0RWb202M3ZEM2RWNDVSdE5CY3FM?=
 =?utf-8?B?UTRJaHhFVzdrQkpPY3dPSm5Eb3pWOUFkRnhBcTFsdlpoZEhscWFUYnYwNy9P?=
 =?utf-8?B?V0Zibk1LRVRLRXhiMVZ2MXU1RXZEVWU2aUl0L3ZsKzR5NU1WaWpPbmJRYW8y?=
 =?utf-8?B?R1h4MklxREVMbVp1amE4a0svVW9mWjBXblNWclZHM2pNSmliM0JoY1cwWW5L?=
 =?utf-8?B?MGhnRmpleHF0M21SMzJaR3YrL1F4TjBsdUhnTEEzKzFrMUk0UCtFbllGSkYv?=
 =?utf-8?B?QXFwSFI0UDdkczZhdjhuNXlBc09PQWRYN1BMbGRRWUNZeEQxanJUTzRFQlRz?=
 =?utf-8?B?RkM3MlIyNCsvNkM1UGoxOW93TGRoMXVFNXVWNy9Ba1hMaGYzNG56NlZ0eGNS?=
 =?utf-8?B?eThMOE1lQWE4MS9CMHRzTnpOdjlUajVzUmp1THJaNC83Wk1PbXhTeWlPSHdJ?=
 =?utf-8?B?T1NxNXAydUhKM2RzNzNkRnVLekF5NXQ0WTM5OGFnd3I1VWNoZlcrT0k3V3Zs?=
 =?utf-8?B?eVBMTnEra2g1RHN2TTVsWVgybllXcUVaR3BCWmRsYzVXK1BRd0ZiTUZ2WUVh?=
 =?utf-8?B?WS9UVUZQR3gzeGlIM0hodkJuQUR0dHl3cHNRWHBuL25DbzNKRGNXZ29IQkZS?=
 =?utf-8?B?RUtiM0ticTM3bndrL29KTWhKdmNmaDZra0tGakRHK3hQY3JhclFvWDlXd2JG?=
 =?utf-8?B?MWNteUErckxMaUVBRWJCVG96ckVnaHB2UVlwNzh5V1hUQ0R0aEpnZEY0dEln?=
 =?utf-8?B?SnBZdFpWQnRKNDE4YUFOaDdUbSt4LzZscU8vQWlBZ2QxOU1Ba3pRY3ZIdWxU?=
 =?utf-8?B?MmNoQ2hVVExycmpTVnpLaENKVVN5VnpLa3pnUmpTenZ1TjFjQ2swcUErOWtB?=
 =?utf-8?B?NmhnMlU2Q0V2eTFrTU5PRGNjTzdFQ2t6TjNnQnRiWU9TMW1HWGlrc3MyMkpl?=
 =?utf-8?B?N0ljMVZqMHNhK1JCU0xtd2NVZ3lOZzZyRXhER1UrQU95bkdyeFhwWkVJcDZo?=
 =?utf-8?B?a3NueUVGSjBobjFsRnNhSS9RRDltb0dJUFpxeFlHZFBGR01YZk5vK2k1QVhU?=
 =?utf-8?B?WnBpY0pWa3dTTTU2SnNmbFdnSmxnQzR4dGNmNmo3MUtKYkcxQUk2c3pRdGlj?=
 =?utf-8?B?ZzAweEhnaGh3T1NBYVFkZS9wZE9vMk45dXcwZ3Y1eE45TGFwYjhiMjRFNjJu?=
 =?utf-8?B?NkxKNUtkM3RQMC80eUxKZmZXVVoyOUpoUzF3MFY2WXcxOUNiR0FzRWVpNFBL?=
 =?utf-8?B?TzhkQXdWSGxOVXFZRGpGbDRzdjV6cjZLSDVYcjl3RUpyUjV4SWFmM2dxcTlH?=
 =?utf-8?B?MTJTcjBHb25UbzRUV3ZybGdiR2pIeGpDRTIxRE1sVHJCSjlWUEtycVg4TkM1?=
 =?utf-8?B?eEFEZDhTb2x5cVFPZkZuRnlpU3hTZHhLRFA2UW40SGhsdVM3MlI2NkF3SE9K?=
 =?utf-8?B?MmpOWmtJMDlaVVp1bit0NVpEVmVTRWs5V1BoTjExQUVEdmsyQnlBNW9Pa3Ay?=
 =?utf-8?B?TWFuSkhGYk83eEpYQm5FZmU1K3RaL3hMSVVlZ29URW9hTCtxYThIYzRTMGt4?=
 =?utf-8?B?Wkt4RjVFaFlYN2dxd1FVYlkwOFJxdkswU1Vyd1F0UFZ3dXc0OHExUTB1R0ZC?=
 =?utf-8?B?TGhzbCs0RkJHejBmY1ZaV0RCNkFwV3NhREJlV0ZZVzdvV091MUFDUGtBVnZU?=
 =?utf-8?B?NjlhMDZzRkdCWnNVSWRHakN4K1RBYk16N29vSkl3S1RZSjRYOW5VUlBVczBH?=
 =?utf-8?B?TDBQbTJhNlNBR1ZOanlzQkhlVzMvdUl2MDUydG85Q014SW5kQ3drWnZYN3Bm?=
 =?utf-8?B?aHVLUkdsN2hjTWZOYWhjeUNJNlVNcXNDdWxRRnQvaUF4V21NdmNaQndnNGVR?=
 =?utf-8?B?V216dGtJbmd3dUY0Yit2eXkzUkVtSTRmZ05xVXdqYk9qeldORFdUejJZR2Rh?=
 =?utf-8?B?N3NDa01EWW15WThEMVlrZEpQREhGNHFTYURkbWp3WE0yNzNmOVFFNHViSHJ1?=
 =?utf-8?B?UGdvT0xYa1U4Zlh4MHRWQzFVcElwNCtBbDU3bUo0U1ovZVRLdmUzbERXM0c2?=
 =?utf-8?B?bVdGWUNNMkcvbHU1MHZGVHY2S3ZyUEprdXkwK2loMGZBZE9OZTZMSDMvbWpT?=
 =?utf-8?Q?JjxU=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB8467.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 02a42c10-da96-40ae-5dac-08dd96b0493a
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 08:36:44.3056
 (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: K0+ZY2AWabzo28E3H9JCZCehqMU5IdNIf64M4PH/aDN/8MV+2BTfjw7GVd1l/+zt+PH0vur5wDN33u3kZPheqQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9215

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI5LCAyMDI1
IDg6NTIgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6
IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT47IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEB2YXRl
cy50ZWNoPjsNCj4gT3J6ZWwsIE1pY2hhbCA8TWljaGFsLk9yemVsQGFtZC5jb20+OyBKdWxpZW4g
R3JhbGwgPGp1bGllbkB4ZW4ub3JnPjsgUm9nZXIgUGF1DQo+IE1vbm7DqSA8cm9nZXIucGF1QGNp
dHJpeC5jb20+OyBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyB4
ZW4tDQo+IGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0gg
djQgMDUvMTVdIHhlbi94ODY6IGludHJvZHVjZSAiY3B1ZnJlcT1hbWQtY3BwYyIgeGVuDQo+IGNt
ZGxpbmUNCj4NCj4gT24gMTQuMDQuMjAyNSAwOTo0MCwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4g
LS0tIGEveGVuL2luY2x1ZGUvYWNwaS9jcHVmcmVxL3Byb2Nlc3Nvcl9wZXJmLmgNCj4gPiArKysg
Yi94ZW4vaW5jbHVkZS9hY3BpL2NwdWZyZXEvcHJvY2Vzc29yX3BlcmYuaA0KPiA+IEBAIC01LDYg
KzUsOSBAQA0KPiA+ICAjaW5jbHVkZSA8cHVibGljL3N5c2N0bC5oPg0KPiA+ICAjaW5jbHVkZSA8
eGVuL2FjcGkuaD4NCj4gPg0KPiA+ICsvKiBhYmlsaXR5IGJpdHMgKi8NCj4gPiArI2RlZmluZSBY
RU5fUFJPQ0VTU09SX1BNX0NQUEMgICA4DQo+DQo+IFRoaXMgbmVlZHMgY29ycmVsYXRpbmcgKGF0
IGxlYXN0IHZpYSBjb21tZW50YXJ5LCBiZXR0ZXIgYnkgYnVpbGQtdGltZSBjaGVja2luZykgd2l0
aA0KPiB0aGUgb3RoZXIgWEVOX1BST0NFU1NPUl9QTV8qIHZhbHVlcy4gT3RoZXJ3aXNlIHNvbWVv
bmUgYWRkaW5nIGEgbmV3DQo+ICNkZWZpbmUgaW4gdGhlIHB1YmxpYyBoZWFkZXIgbWF5IG5vdCAo
ZWFzaWx5KSBub3RpY2UgYSBwb3NzaWJsZSBjb25mbGljdC4gV2l0aCB0aGF0IGluDQo+IG1pbmQg
SSBhbHNvIHF1ZXN0aW9uIHdoZXRoZXIgOCBpcyBhY3R1YWxseSBhIGdvb2QgY2hvaWNlOiBUaGF0
J3MgdGhlIG9idmlvdXMgbmV4dA0KPiB2YWx1ZSB0byB1c2UgaW4gdGhlIHB1YmxpYyBpbnRlcmZh
Y2UuIFNJRl9QTV9NQVNLIGlzIDggYml0cyB3aWRlLCBzbyBhIHNlbnNpYmxlDQo+IHZhbHVlIHRv
IHVzZSBoZXJlIHdvdWxkIGJ5IGUuZy4gMHgxMDAuDQo+DQoNCkkndmUgYWRkZWQgYSBwdWJsaWMg
ZmxhZyBhbmNob3IgIlhFTl9QUk9DRVNTT1JfUE1fUFVCTElDX0VORCIgaW4gcHVibGljIGhlYWRl
cjoNCiAgICAgICAgICNkZWZpbmUgWEVOX1BST0NFU1NPUl9QTV9QVUJMSUNfRU5EICAgIFhFTl9Q
Uk9DRVNTT1JfUE1fVFgNCmFuZCB3aWxsIGRvIHRoZSBmb2xsb3dpbmcgYnVpbGQtdGltZSBjaGVj
a2luZzoNCiAgICAgICAgQlVJTERfQlVHX09OKFhFTl9QUk9DRVNTT1JfUE1fQ1BQQyA8PSBYRU5f
UFJPQ0VTU09SX1BNX1BVQkxJQ19FTkQpOw0KDQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Mon May 19 09:12:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 09:12:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989672.1373661 (Exim 4.92)
	(envelope-from )
	id 1uGwY9-0004Kx-N3; Mon, 19 May 2025 09:12:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989672.1373661; Mon, 19 May 2025 09:12: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 1uGwY9-0004Kp-Jh; Mon, 19 May 2025 09:12:45 +0000
Received: by outflank-mailman (input) for mailman id 989672;
 Mon, 19 May 2025 09:12:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uGwY8-0004Kj-MR
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 09:12:44 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uGwY8-001ImW-13;
 Mon, 19 May 2025 09:12:44 +0000
Received: from lfbn-gre-1-199-136.w90-112.abo.wanadoo.fr ([90.112.161.136]
 helo=l14) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uGwY7-00BHSP-1y;
 Mon, 19 May 2025 09:12: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=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=0RpSwdwlttZAZtwRSP93EAUeOBCCE7rT6WBzeAwkMFw=; b=SkjbSJlv+ZdJbP0Y1YIFbzgs+U
	1cdkcNNw6hIYRjm81QWbuzSJK1Hc9hOy+7BH8S6KRVGrDoRewNLsX0R1liEjRc1e2+1XwzU1d9Rcx
	V56XuIlcaL6INug1LlgK+KD803ZD08sCs+GEc2O68RkbfC1H1zLA/gf14dUNLGSWPcw8=;
Date: Mon, 19 May 2025 11:12:41 +0200
From: Anthony PERARD 
To: Juergen Gross 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini 
Subject: Re: [PATCH v3 1/4] docs: remove qemu-traditional support from
 documentation
Message-ID: 
References: <20250429110636.30518-1-jgross@suse.com>
 <20250429110636.30518-2-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250429110636.30518-2-jgross@suse.com>

On Tue, Apr 29, 2025 at 01:06:31PM +0200, Juergen Gross wrote:
> In preparation to no longer support qemu-traditional (including
> qemu-stubdom), remove it from documentation.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 19 09:16:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 09:16:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989679.1373671 (Exim 4.92)
	(envelope-from )
	id 1uGwba-0004ta-3u; Mon, 19 May 2025 09:16:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989679.1373671; Mon, 19 May 2025 09:16: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 1uGwba-0004tT-0v; Mon, 19 May 2025 09:16:18 +0000
Received: by outflank-mailman (input) for mailman id 989679;
 Mon, 19 May 2025 09:16:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGwbY-0004tN-Ta
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 09:16:17 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e9859a97-3491-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 11:16:14 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad52d9be53cso454396466b.2
 for ; Mon, 19 May 2025 02:16:14 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d071c36sm567178966b.64.2025.05.19.02.16.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 02:16: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" 
X-Inumbo-ID: e9859a97-3491-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747646174; x=1748250974; darn=lists.xenproject.org;
        h=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;
        bh=20mE0g/uZDF4lu6y+z9YNWj+qRxx9iPCZda5fVdY4pY=;
        b=cqublEH7gSJe4p4OYGoZQV54FKshyEa5FlAZ3TXUhpEh3cEMUlpQdS1gnEW6nfdbYD
         eWsUCl73qIpqHTKZI+mwCJ/gLux+mjjlLFaBJT+GQZigMX/qp7aUKZD6qtIKG19Gan4E
         DMMa0sm8v81WYy0YF8LCquBxsAP9cc34EFj2c9lVQTjB9HkA+cd0SVb+avYkbIqTBC7P
         EMKlSHFXBJakuGYRbFY99x6wqv97Y7A9B7fTxNeWM3LQz+ue1cl6pA59GH7ew4lJt8eq
         MsShubdJsoxxr50lJJLcz8QEblyy+T4rQ+H2rDcSQtsvIGmE1FoBEBxsYfZzdVmVQX+S
         JHsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747646174; x=1748250974;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=20mE0g/uZDF4lu6y+z9YNWj+qRxx9iPCZda5fVdY4pY=;
        b=h4goUyp5Vl/oU8dvxul8/77VDTJgs2SZp7tQhivg9zyNDKsqnWyJyyS0s3zEFP9n7i
         9IOljNtCze+NMFQ5s9uZ1dLgLGPf8ef3vJqzbhgtjdtbyXnCUc4RagYTywGh/3RO2txr
         OeOU5MLXS+rU6P3/Kx85XS0N+sQtLwZQqsWUPMYs3Muw5ywMpVJ0CWb91qbablsrpVAS
         EOQ7Jfc403LU0jnWjHEOQXaBZ6g+e3MwjCInCjEJ/+A13i7KXlHoWEPx/D9M5OqWkbtO
         LGmFBe/mvLLCoGd5paHEa+9Wrcc7S2Pdp1eS1zadOCOLSXCvnwloAemNhPto9pYwKeGZ
         3kOA==
X-Forwarded-Encrypted: i=1; AJvYcCXq9szXWkt1Pny5rCPgm5UqoCs32ZLqKFA+snANeYh2p0MAepfV8mjF2y1qgjqxRxcq8x6MUTSuFco=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzM6Uqq0dR7agyOlNpFk3cOQ/+u6ArxxD8HHysOOKxFyO6Un9ik
	deNIcGRrbagARDfRIDNgMk8BPOHuZcgyTGtohwNPEYsrVRSvlA8o0FJH
X-Gm-Gg: ASbGncvNQHJV0Q3oiPTQwwKPW5rg2aD9Aa2P/34mrcieU50E9xA/u8m8wx5ahFBV4MS
	WHv2rKdndsEbSyXyI599+L90DlIOvPYpJckXjqPzPf2BNLVW39zM5GxaNlgwPK613v6SYck2Kpx
	fMX8qK1GzKNfkj1tpfcoaLVrPnOjqTnxMjUy8NLA7F7RyKeDVrV/Zk225Fs8plsrpWWOmv4rcJ/
	jTcK/6LDEkJ7m1ke75MR7D9qqIh8ahwWVNinEV1ZG8bk2m/unbQtXYgxQbieLWVbdgTvIT9tuls
	U4JVSBSEiOUkGF1Bx7DhXBL+Vfm+xWaoOE7ckhF99h7i48hJsAKEZbZx2FHo1PxwHAbJNjnt4R5
	0jPXcs3z2fKqI5duYw3RBN5a4
X-Google-Smtp-Source: AGHT+IGkFNsI5fPDtlRu1rHiPkYVTbl5vWbWaz7pqvGdEWa18AwG1ShRJcLo1pO+W4Y/zpWimczWhA==
X-Received: by 2002:a17:907:8dc3:b0:ac7:d7f3:86c6 with SMTP id a640c23a62f3a-ad52d467cccmr889322766b.9.1747646173305;
        Mon, 19 May 2025 02:16:13 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------zaSulQ0JkwlEazr1WB8980pE"
Message-ID: <9c202b56-ad59-481b-924a-addefcea84cd@gmail.com>
Date: Mon, 19 May 2025 11:16:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/16] xen/riscv: introduce register_intc_ops() and
 intc_hw_ops.
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <7cd7d3780bb6db45b92c971ff8bcf2634570431f.1746530883.git.oleksii.kurochko@gmail.com>
 <2436be2e-28d4-4e48-a391-84b21651b339@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <2436be2e-28d4-4e48-a391-84b21651b339@suse.com>

This is a multi-part message in MIME format.
--------------zaSulQ0JkwlEazr1WB8980pE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/15/25 10:06 AM, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/include/asm/intc.h
>> +++ b/xen/arch/riscv/include/asm/intc.h
>> @@ -8,6 +8,8 @@
>>   #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
>>   #define ASM__RISCV__INTERRUPT_CONTOLLER_H
>>   
>> +#include 
> If you need this include anyway, why ...
>
>> @@ -17,6 +19,26 @@ struct intc_info {
>>       const struct dt_device_node *node;
>>   };
>>   
>> +struct irq_desc;
> ... this "forward" decl for something that's then already fully defined?
> I can't, however, spot why xen/irq.h would be needed for anything ...

forward decl for irq_desc could be really dropped.

Inclusion of xen/irq.h was added because of hw_irq_controller which is defined as:
   typedef const struct hw_interrupt_type hw_irq_controller;

And I'm not sure how to do forward declaration properly in this case. Just use
an explicit definition of hw_irq_controller for host_irq_type member of struct
intc_hw_operations seems as not the best one option:
   struct hw_interrupt_type;
  
   struct intc_hw_operations {
       ...
       // const hw_irq_controller *host_irq_type;
       const struct hw_interrupt_type *host_irq_type;

It seems like the best one option is to do the following:
   typedef const struct hw_interrupt_type hw_irq_controller; in asm/intc.h.
I will follow it then.

>> --- a/xen/arch/riscv/intc.c
>> +++ b/xen/arch/riscv/intc.c
>> @@ -5,6 +5,15 @@
>>   #include 
>>   #include 
>>   
>> +#include 
>> +
>> +static struct __ro_after_init intc_hw_operations *intc_hw_ops;
> Nit: Attributes between type and identifier please. Also shouldn't both
> this and ...
>
>> +void __init register_intc_ops(struct intc_hw_operations *ops)
> ... the parameter here be pointer-to-const?

Then|intc_hw_ops| should also be marked as|const| (with the removal of|__ro_after_init|),
otherwise a compilation error will occur (something like/"assignment discards 'const' qualifier"/).

Additionally,|__ro_after_init| should be replaced with|const| for|aplic_ops| in future
patches.

Let me know which approach you prefer. I prefer using|const|, as
|intc_hw_operations| and|aplic_ops| are not expected to change after initialization.

~ Oleksii

--------------zaSulQ0JkwlEazr1WB8980pE
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 10:06 AM, Jan Beulich wrote:
    
    
    
    
    
      
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    --- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -8,6 +8,8 @@
 #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
 #define ASM__RISCV__INTERRUPT_CONTOLLER_H
 
+#include <xen/irq.h>

    
      
    
      
    If you need this include anyway, why ...


    
      
    
        
    @@ -17,6 +19,26 @@ struct intc_info {
     const struct dt_device_node *node;
 };
 
+struct irq_desc;

    
      
    
      
    ... this "forward" decl for something that's then already fully defined?
I can't, however, spot why xen/irq.h would be needed for anything ...
    
    
    
    
    forward decl for irq_desc could be really dropped.

Inclusion of xen/irq.h was added because of hw_irq_controller which is defined as:
  typedef const struct hw_interrupt_type hw_irq_controller;

And I'm not sure how to do forward declaration properly in this case. Just use
an explicit definition of hw_irq_controller for host_irq_type member of struct
intc_hw_operations seems as not the best one option:
  struct hw_interrupt_type;
 
  struct intc_hw_operations {
      ...
      // const hw_irq_controller *host_irq_type;
      const struct hw_interrupt_type *host_irq_type;

It seems like the best one option is to do the following:
  typedef const struct hw_interrupt_type hw_irq_controller; in asm/intc.h.
I will follow it then.


    
    
    
      
    
        
    --- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -5,6 +5,15 @@
 #include <xen/init.h>
 #include <xen/lib.h>
 
+#include <asm/intc.h>
+
+static struct __ro_after_init intc_hw_operations *intc_hw_ops;

    
      
    
      
    Nit: Attributes between type and identifier please. Also shouldn't both
this and ...


    
      
    
        
    +void __init register_intc_ops(struct intc_hw_operations *ops)

    
      
    
      
    ... the parameter here be pointer-to-const?
    
    
    
    
    Then intc_hw_ops should also be marked as const (with the removal of __ro_after_init),
otherwise a compilation error will occur (something like "assignment discards 'const'
qualifier").
    
    
    Additionally, __ro_after_init should be replaced with const for aplic_ops in future
patches.
    
    
    Let me know which approach you prefer. I prefer using const, as
intc_hw_operations and aplic_ops are not expected to change after initialization.
    
    
    ~ Oleksii
    
  


--------------zaSulQ0JkwlEazr1WB8980pE--


From xen-devel-bounces@lists.xenproject.org Mon May 19 10:05:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 10:05:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989690.1373681 (Exim 4.92)
	(envelope-from )
	id 1uGxMY-0002fR-JN; Mon, 19 May 2025 10:04:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989690.1373681; Mon, 19 May 2025 10:04: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 1uGxMY-0002fK-Gm; Mon, 19 May 2025 10:04:50 +0000
Received: by outflank-mailman (input) for mailman id 989690;
 Mon, 19 May 2025 10:04:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGxMX-0002fA-54
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 10:04:49 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b233e8e7-3498-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 12:04:48 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5efe8d9ebdfso7627425a12.3
 for ; Mon, 19 May 2025 03:04:47 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d04e80asm566224266b.2.2025.05.19.03.04.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 19 May 2025 03:04: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" 
X-Inumbo-ID: b233e8e7-3498-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747649087; x=1748253887; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=+XVrJLDO6fe7QBZLwBaJKM6pWz7Wb0RBYQjDq2kYoJo=;
        b=PlQgj+OFqV0bTEMZyIRpH4bOHL3ivdYWRJ680Xsccw+QyLQWxwUVNMjddT/aZPKZ6H
         pzZxOrw90fnZYUobH/3ru0XQJNzYefYIMSakzZOxfJIKF5D3utCfhvVsr/V4ajXpua8Q
         w/LOKRyaKJORqIfRudy5My4IiPZUwFbIuILZ8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747649087; x=1748253887;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+XVrJLDO6fe7QBZLwBaJKM6pWz7Wb0RBYQjDq2kYoJo=;
        b=niBDc9OZP0a4wuM/wzSS6QEOotnuryqM0odzpAkM/LcNmiIjFQc7qceGYdILvRlMHB
         GNk8hZMOZzIwMJc5AMgfpCgrR3GgeHX/W3ejC5+k4P2KZFUB6AJAWwrXpOZ7hG5Y6b6/
         rVNcQPkTv/8wI1jYfiqPt0atmzbzMol0GQH8nai1/essjMQT8EBaDgTUMdbpy2VC9XKG
         7q1S6uF7ZCndueAnBaFKHPY2BliXheu4liTv6Xro3aWqsQTy6Z/tO1RcQOlN3pYoU4vL
         ppBrhDjf3OSYiRIgSaJWP/49MHiDYijMYAPi+P21IQEt+2/a6c6zzWVWKGXDh0hYFgsg
         qV/g==
X-Forwarded-Encrypted: i=1; AJvYcCX4UuoehXYD9t8motZmk4AGa+3tyvTSvtPOua1WzwbkpZSZuIz96vthFkND1BE6rtPvtPqRhMzM3ok=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw+8TUmz68lBZgdr8ao8JNN+UuCtaPVE6bj2ZzVof1neeN6sgH8
	buRAdrrR5JIPs8PUAAfdjvYdHR9249polWKDvHQ2Rf/sWBD/xq1Exurwn0ZyMj+yxUw=
X-Gm-Gg: ASbGncsN4zwjBgIlYGpNVbSCqPfFF1U213FpR8Hbo4ZyS6xOcEY62buOXPJXiQoQuKl
	pYflwg1ck7AczJFGvRO4e6Ut5MoOj/VjG9w8xopLW62r+bmWexOZQt5U7Ozn/0JH6liGSeXwyOC
	TuAFcW9jq5niqvrJtFHk2Qru8iffTjAMMmBB0D8Ue6LK4y0lsVmSmFFhwz2Hl59csqBkhVMbWRt
	SyXUNMTqJ+OJbQxWY71VWLL5A6c5AoQSXz93Fm6iTs7x2ORO5VqykgSbfntaAX1oHdpcA/xW+/q
	wetic6mOgsCHP23qcE+uzUp5iYHESL2C4v2Wwk5YPZBrUULEjaGCzLfqHwNymmJ9BhTPl3m9NsH
	nEpKj77x3eu99Qz9FHKUv81ce
X-Google-Smtp-Source: AGHT+IF7g9AcS43I+lRf56dOymaxZmOUZUT1ZYtiNmqHTNzkv8M2x8lF0Utu11yLsxEDG7+7v0F/iw==
X-Received: by 2002:a17:907:7205:b0:ad5:1bfd:30d2 with SMTP id a640c23a62f3a-ad536ffb552mr1292687166b.55.1747649087236;
        Mon, 19 May 2025 03:04:47 -0700 (PDT)
Date: Mon, 19 May 2025 12:04:45 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: Jan Beulich ,
	"xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v4 05/10] vpci: Hide legacy capability when it fails to
 initialize
Message-ID: 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-6-Jiqian.Chen@amd.com>
 <76d58a17-90aa-46eb-bbe8-c6d9400c489f@suse.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Mon, May 19, 2025 at 07:35:49AM +0000, Chen, Jiqian wrote:
> On 2025/5/18 22:44, Jan Beulich wrote:
> > On 09.05.2025 11:05, Jiqian Chen wrote:
> >> +static int vpci_capability_mask(struct pci_dev *pdev, unsigned int cap)
> > 
> > What's the word "mask" indicating here? The function doesn't return any
> > mask afaics. Do you perhaps mean "hide"?
> Yes, hide.
> This is a question of naming preference.
> I remember Roger suggested this name, but maybe I remember wrong.
> For double confirmation, hi Roger, are you fine that I change this name from mask to hide?

Sure, it's fine to use hide, and it's possibly more inline with how
we use hide in other functions (like pci_hide_device()).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 19 10:24:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 10:24:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989708.1373692 (Exim 4.92)
	(envelope-from )
	id 1uGxfh-0005Sb-6Q; Mon, 19 May 2025 10:24:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989708.1373692; Mon, 19 May 2025 10: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 1uGxfh-0005SU-27; Mon, 19 May 2025 10:24:37 +0000
Received: by outflank-mailman (input) for mailman id 989708;
 Mon, 19 May 2025 10:24:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGxff-0005SL-Rd
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 10:24:35 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 74e20881-349b-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 12:24:33 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ad1d1f57a01so735847466b.2
 for ; Mon, 19 May 2025 03:24:33 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d06ddd6sm579216066b.55.2025.05.19.03.24.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 19 May 2025 03: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" 
X-Inumbo-ID: 74e20881-349b-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747650273; x=1748255073; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=VptiwLq5a77QUBh0b0JtoOt6zHEP7K0QIuTapcJ9CjI=;
        b=fVyAi/dc1wPGjh23ZwBQ1DAobAkCMZW0GFxujGuIoEhXaRrbttft78RgTqBR4IljW9
         uUse9oisYI0Q14j8j7SrtvACZb+5PyOJHDwppo8C1rWQvO9oeAiWq/4VlqmvwyMwy9oz
         masx8iOj60fnqrVABFOsWl5dKdcl/v0XgT6Z4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747650273; x=1748255073;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=VptiwLq5a77QUBh0b0JtoOt6zHEP7K0QIuTapcJ9CjI=;
        b=H+hHzE3KJcCbMxT5ksKHRBpVe6jwJntTcm5wxOE5sLEZQceRuxArEq5Y90cwoy8EcZ
         zuHtG8SqZ0iojoSsqHapluM5ptNIA7dFzdXHmuk4gY3ZJkvW7fx4gB9K61pwH2f3wnib
         yDSNEZQvGWBEkO3v2irEgb6oZbXeUrdoYRC1myYcsDv/thmDGFppjLFE5+MRx/ZBqAEV
         2YZZQEqM1rsNRvzzt47XY7fhy5eEQWWcwuN+2tcCUj7QiNk0SBhapHuiuXY4gPxPLg5y
         H3UsGm1huhZKs05oZn6kb807pFMbAHa5p542p3e/00RnhRjr/b40dCEBhnISkOFntyDY
         +CvA==
X-Forwarded-Encrypted: i=1; AJvYcCU+vyEW6vSbnDzgfo+SaP9qz4XfLbPepg0G4/pwF9d9s6E+v5KcZyqmFSCW1z98SiBzzby49P4Vrv0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzFX1jHT5cASh9uye/rZf2CVrY7gm9F2OildxgPLnFWcz3OzEqW
	Nzym1HtexLBwHxJDfsM2lgIMxjn9JB+HkFtDNVrsw+icrMRhrp6hybXi4nZg9D3gmcA=
X-Gm-Gg: ASbGncvnTt7ucuCXGTUi+Z4MYSqIw+wpas0Z7QOTfhAKMnX/cNVvmyOknUU3cAX7tDc
	fplpuKE9YVpFh++0z001NBiQVvZLvKcvVJbUL3YdvtlBjv5u8fc9ncI3vfqYfW7EANUY6YXzmj1
	b2CEOHxfd3T+7POAWJStdNM0HBwlJL9emRGfmM9k7FvcWysW94gEMBT1Tglwmce9biNc91KTPIy
	DKluKjT7Hgo5PZqrrQmrq6IVjApmi2tliM5R0YeQwch47tzcuiihL3vXERdC3Id/tV2H/ycYQV8
	i5gEmV3g7+FnydTmfMWqpPbWe4ia5o/x/J+rNhj+fovN53ljF8SxIN+ECuXLaBFd8kEw0Aj1MrR
	Djy63QXW9v89cmC9u/c0HyWEo
X-Google-Smtp-Source: AGHT+IEptagXe+3x19JRS9gplTFEtWlhEnetNu2P4kvPInP+6HBcYkXHTlonNfk2qRzbk9VfAarejg==
X-Received: by 2002:a17:907:7254:b0:ad5:7234:e4a9 with SMTP id a640c23a62f3a-ad57234e7e0mr274325966b.28.1747650272918;
        Mon, 19 May 2025 03:24:32 -0700 (PDT)
Date: Mon, 19 May 2025 12:24:31 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Jiqian Chen , Huang Rui ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 07/10] vpci: Refactor vpci_remove_register to remove
 matched registers
Message-ID: 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-8-Jiqian.Chen@amd.com>
 <7129d506-b03a-4f89-8128-84b8befe8799@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <7129d506-b03a-4f89-8128-84b8befe8799@suse.com>

On Mon, May 19, 2025 at 08:30:22AM +0200, Jan Beulich wrote:
> On 09.05.2025 11:05, Jiqian Chen wrote:
> > vpci_remove_register() only supports removing a register in a time,
> > but the follow-on changes need to remove all registers within a range.
> > So, refactor it to support removing all matched registers in a calling
> > time.
> 
> Generally I'm a little wary of changing behavior for existing callers,
> but I guess Roger already did signal he's okay taking that route?

The only users of that function currently are in tools/tests/vpci/,
so changing is not a problem IMO.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 19 10:58:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 10:58:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989720.1373701 (Exim 4.92)
	(envelope-from )
	id 1uGyCp-0000t4-IQ; Mon, 19 May 2025 10:58:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989720.1373701; Mon, 19 May 2025 10:58: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 1uGyCp-0000sx-F8; Mon, 19 May 2025 10:58:51 +0000
Received: by outflank-mailman (input) for mailman id 989720;
 Mon, 19 May 2025 10:58:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGyCp-0000sr-0x
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 10:58:51 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3de2c507-34a0-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 12:58:48 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ad56e993ae9so169466666b.3
 for ; Mon, 19 May 2025 03:58:48 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d06ad94sm573403066b.38.2025.05.19.03.58.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 19 May 2025 03:58: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" 
X-Inumbo-ID: 3de2c507-34a0-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747652328; x=1748257128; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Aus8QzFM/GlRkV4zkxFxtT1REF5/OEDyA0BmHNUNl+I=;
        b=Dd/cvKrnhWuTzM5jSuSifjTZ/hCkBBV9SxIb6T27eixIVlbHEBhyc/raUfyuEBMiLl
         o5y/g+9oL4QTyWKBu5a/kWxDnXAQl7Lmn5OsANs9vbznLvKrGKk0MY5ISj2pwdxbAE2b
         PmuhP9adJyKK1PZsotYFYE/Bf66yFLxlotZvY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747652328; x=1748257128;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Aus8QzFM/GlRkV4zkxFxtT1REF5/OEDyA0BmHNUNl+I=;
        b=Yo/9tzZKS8UDJ3bVZm4LACaoJHNxk5CasJGPPDHm83KsIw+6fJsioQLS47qJGsf6YQ
         eFBaetrpz9dKewiMABwmLE04WT3hQAVHv0l3GJx3YciiT9ES5nkhYrZWPu7RNJn1TUAm
         cXJDyFWWxeBI6tkSi1sTepDDbl/2XWRD+zutpn7Qxj3mQ9G29TQKXgHnYVzX9YX5bhdk
         pFu/FVVmtR6bVAi18YMmG3JE4It0uubTd8SQ9Y8qq1lIfsJGZCUBgg+02JtyVjTrmg+x
         cX4lynv1V1eAx5i/mvH+0u3utY/BBEKY4QxcLBo44u7YE8ksLqIeaxod5StWsXGPXU8I
         ss7w==
X-Forwarded-Encrypted: i=1; AJvYcCXo9Xvwb9uWyZUaxvG58A1zFtXfUK2lMEm8QsCPtYSuZ88J7bP93CPeeQT/m8t/sg99kCPsoTKfenE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywu+1eThMgIsxeWFWtgIm4Wb738t3j4GsGkROG6BTaCDZwYzIpB
	79/O9nAQDDUYyoZEWThR/WbTojUkrZ3C4bc9KY2R8sVG88ZeyJtfuHGNRCAKibTw5ww=
X-Gm-Gg: ASbGncubRgAkUuLA4ptdauUCZKOkTMwK2qAISjcFH8zru+TZ0XlX1OoXSvR1dlngoEQ
	h7H26xI6yyWxVqGuGCrisDpJwdV3siE1cEifhbgHp2+Bo8V4H1WV/dYswXVakeUFBAGUHkF3hRY
	rWkTyUs4Sb0doBFRindZQRSDuHCh0AO+0G/elcGXsZJjxIlm8mnXjlawVB30e4l/y2OEqSIuwVg
	+Z3NFLgSPsYFmgnYe/Ek8eUBxPdffXmVdaDTy8bc2oJZrR/UHMWCtb5tnRFYLe5nm34tpOCklb3
	ot2/QKHEwba89rfoPhuLJ7slHzGRp7CDj6ENNgwsirqk4Ns50A5kiUL0L0465Fgt7QBqFhBJ0yd
	gStQOcpbwZHVM3ZMmU2HYmfE5Ugm9h0n7FV4=
X-Google-Smtp-Source: AGHT+IHr9pJwSczcYze+lMInsgg4UNiZ2dxMKjeV0iHqgkSSIYbp/GWgx91563eG6RU1OeglEmV0Tg==
X-Received: by 2002:a17:907:94d2:b0:ad4:d135:cf68 with SMTP id a640c23a62f3a-ad536f9d8c3mr998103766b.59.1747652328135;
        Mon, 19 May 2025 03:58:48 -0700 (PDT)
Date: Mon, 19 May 2025 12:58:46 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 5/6] x86/hvm: limit memory type cache flush to running
 domains
Message-ID: 
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-6-roger.pau@citrix.com>
 <8bf8072f-c379-416a-9d7d-912db7084e67@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8bf8072f-c379-416a-9d7d-912db7084e67@suse.com>

On Sun, May 18, 2025 at 01:38:02PM +0200, Jan Beulich wrote:
> On 16.05.2025 11:45, Roger Pau Monne wrote:
> > Avoid the cache flush if the domain is not yet running.  There shouldn't be
> > any cached data resulting from domain accesses that need flushing, as the
> > domain hasn't run yet.
> 
> This again plays into what we started discussing already: There may still be
> data in caches due to Xen or toolsstack behavior. Imo to compensate we'd need
> to do one flush right before unleashing the domain. Yet of course this makes
> sense only when we make sure to not have (cachable) mapping in Xen for any of
> the affected ranges. Hence, with that not presently being the case, ...
> 
> > No change in domain observable behavior intended.
> 
> ... I agree here, thus ...
> 
> > Signed-off-by: Roger Pau Monné 
> 
> Reviewed-by: Jan Beulich 
> 
> The situation may want discussing a bit more in the description, though,
> which would make me feel less uneasy about that R-b.

I've added:

"There can be data in the caches as a result of Xen and/or toolstack
behavior.  Ideally we would do a cache flush strictly before starting the
domain, however doing so only makes sense once we can guarantee there are
no leftover mappings of the affected ranges with cacheable attributes,
otherwise the CPU can speculatively populate the cache with data from those
ranges."

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 19 11:08:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 11:08:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989741.1373711 (Exim 4.92)
	(envelope-from )
	id 1uGyMB-0002aW-HH; Mon, 19 May 2025 11:08:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989741.1373711; Mon, 19 May 2025 11:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uGyMB-0002aP-EM; Mon, 19 May 2025 11:08:31 +0000
Received: by outflank-mailman (input) for mailman id 989741;
 Mon, 19 May 2025 11:08:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uGyMA-0002aJ-0r
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 11:08:30 +0000
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com
 [2607:f8b0:4864:20::42d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 96b04a30-34a1-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 13:08:28 +0200 (CEST)
Received: by mail-pf1-x42d.google.com with SMTP id
 d2e1a72fcca58-742c73f82dfso852081b3a.2
 for ; Mon, 19 May 2025 04:08:27 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-742a9829cb7sm5922534b3a.111.2025.05.19.04.08.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 19 May 2025 04: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" 
X-Inumbo-ID: 96b04a30-34a1-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747652906; x=1748257706; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=TRgDNN/WJGaTzMAptFGW4O+KglzQsrfQyHkZcI4kRoA=;
        b=WPtPQfJjMtBi6X0WuZHw36nepavAWHJE+a9ECR4CCvxkv879FkYXrx45HKHldxVfPa
         8toPVWHj8qnoGiZ/TYKhADSqPDVhEAGKDrfGozeQU3fyUie03yIlWEEaTbo8Zgq3PtdM
         F8B+6PCYBlUOXSXFuOIqEJyBihBmP9Wh6KBks=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747652906; x=1748257706;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=TRgDNN/WJGaTzMAptFGW4O+KglzQsrfQyHkZcI4kRoA=;
        b=jAKzrLI2UFfkVTBlfSnK8YIYRJQIkXNpczx/AluljEOqkhn+qzTwHe4Hin3GvvuIPr
         xoGX65CynxySkloCohtoiuGMXvrHn3Nz+0CAt+P+ZAAEd6bpiDZgCZPyWfYsup0qPdgq
         cImPe4PzcNwgSI7KPmAex/rsqnZrMtlklO7BjiHFOwBd4/cdWklXCC2rvEsDTeFQBk4s
         9Ope/7hyfemEa+W1n8LBlA5A7Rr7ym66vxwmXPnvvprGllV5+gHJ27qAfRCSFN1MiM9S
         B4+USNwFMeeLlHEvU6WmF5Ssd3nLd+Kuz/qqQe3nBI8TwD3PpHaZBN1hYQOOIKiOuQEp
         ebOg==
X-Forwarded-Encrypted: i=1; AJvYcCVuP2rw/bDZsN8fP191HydL0ATXXKVKcDLhCrLUoUPDnsfRYJMTaU8Ban7SuUMk8kSdvRV3hKlWLd4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwxaIvZ6PiFHyxU/LbjTzUfy+80J6qpAQwJ2QWJHml6U6lOxFCd
	aNOIUVuSvASA8J+ZLOh9WZkp+Ai3YMq5rERwV9v1EFGf1KWKImrgf6Yos+TsBgUA0iQ=
X-Gm-Gg: ASbGncvtspy38YxuXmAHEO2tJ4Qev4guLm63NH6/vM1i8rhAUeha3pG/ue5Hoce2MxX
	7iTjiRfTVNbT94Z8ZJ8E26GBo9m2TrGF4E3fnvWK1cVdc/WYmwBvyw+UgxpthQh/7/eTnFNQvyV
	XuOP8X8w9kK8XuBodw5EcJbhW1wISK26vkH9SwvDkwHEZTNJiKDjXogm+7WvlcEmVdCtrxJ0LHm
	ZcCTwWsrY2Hn5JO4SBW6VjCzJwS89jc6w923WbE7JS6fzeb5gIXkFC3r81tiR4o4W9LWanAt+k+
	NAFGxVU6SUbINxZyy7M080AXATTrVr2s91+124cTTxbG8JgidVBYjLeq9qXLXKzKxGDsrvRjDYH
	RzlQYRi0mcg2dV7XkMGYwgZvp
X-Google-Smtp-Source: AGHT+IEoJUNV0yC8LPugppleKXiEO7uQ1XCyjz35X3ubPPbDFDbkerei1o8wC0T1lF7hQoLwKqO53A==
X-Received: by 2002:a05:6a00:ad1:b0:736:ab49:d56 with SMTP id d2e1a72fcca58-742a9776965mr17227248b3a.1.1747652906301;
        Mon, 19 May 2025 04:08:26 -0700 (PDT)
Date: Mon, 19 May 2025 13:08:20 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich ,
	Oleksii Kurochko 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 6/6] x86/hvm: reduce the need to flush caches in
 memory_type_changed()
Message-ID: 
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-7-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Sun, May 18, 2025 at 01:44:49PM +0200, Jan Beulich wrote:
> On 16.05.2025 11:45, Roger Pau Monne wrote:
> > The current cache flushing done in memory_type_changed() is too wide, and
> > this doesn't scale on boxes with high number of CPUs.  Attempt to limit
> > cache flushes as a result of p2m type changes, and only do them if:
> > 
> >  * The CPU doesn't support (or has broken) self-snoop capability, otherwise
> >    there would be leftover aliases in the cache.  For guest initiated
> >    memory changes (like changes to MTRRs) the guest should already do a
> >    cache flush.
> >  * The IOMMU cannot force all DMA accesses to be snooping ones.
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> Reviewed-by: Jan Beulich 

Thanks.

> > Not sure whether this attempt to reduce cache flushing should get some
> > mention in the CHANGELOG.
> 
> Err on the side of adding an entry there?

Oleksii would you be fine with me adding:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1ea06524db20..fa971cd9e6ee 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -11,6 +11,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
    - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
  - Linux based device model stubdomains are now fully supported.
+ - On x86:
+   - Restrict the cache flushing done in memory_type_changed() to improve
+     performance.

 ### Added
  - On x86:

Asking whether you provide a RB/Acked-by here so that I don't need to
resend just for the CHANGELOG addition.

> > --- a/xen/arch/x86/hvm/mtrr.c
> > +++ b/xen/arch/x86/hvm/mtrr.c
> > @@ -782,14 +782,21 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr, NULL, hvm_load_mtrr_msr, 1,
> >  
> >  void memory_type_changed(struct domain *d)
> >  {
> > -    if ( (is_iommu_enabled(d) || cache_flush_permitted(d)) &&
> > +    if ( cache_flush_permitted(d) &&
> >           d->vcpu && d->vcpu[0] && p2m_memory_type_changed(d) &&
> >           /*
> >            * Do the p2m type-change, but skip the cache flush if the domain is
> >            * not yet running.  The check for creation_finished must strictly be
> >            * done after the call to p2m_memory_type_changed().
> >            */
> > -         d->creation_finished )
> > +         d->creation_finished &&
> > +         /*
> > +          * The cache flush should be done if either: CPU doesn't have
> > +          * self-snoop in which case there could be aliases left in the cache,
> > +          * or IOMMUs cannot force all DMA device accesses to be snooped.
> 
> I think this could do with "some" added ahead of IOMMUs (maybe parenthesized),
> to clarify the route to take here if and when we change the global to a finer
> grained property.

Done, thanks.


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:07:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:07:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989771.1373720 (Exim 4.92)
	(envelope-from )
	id 1uH0D9-0007r6-Al; Mon, 19 May 2025 13:07:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989771.1373720; Mon, 19 May 2025 13:07: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 1uH0D9-0007qz-7p; Mon, 19 May 2025 13:07:19 +0000
Received: by outflank-mailman (input) for mailman id 989771;
 Mon, 19 May 2025 13:07:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH0D7-0007qt-Jp
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:07:17 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2ffbe78e-34b2-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 15:07:16 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-6011407431cso4581971a12.3
 for ; Mon, 19 May 2025 06:07:16 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ae39549sm5719093a12.71.2025.05.19.06.07.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 06:07: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" 
X-Inumbo-ID: 2ffbe78e-34b2-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747660036; x=1748264836; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=caSmSC0vq01GdhGqSOu2/BTM+otwOs2jmU+X7gsR1t8=;
        b=aagjm8IMAggi6HKTRi/Z+JvSE6JE56MxxeO9PgczIBeTER7Dw46fKMDUUT9l/PZwZ5
         E/zrbnZNg+xFFdAqWj7TC1iMQiPoH+4ys/jbVRI3p8becclUPdyVHtD+m4cO5S473Tv8
         OTYS2CVPalAYQbViwuDj2bUg6GQfRfC7NS6gdbIaQ79AwqtjrVdfbdPX5RkJQzlvN5v1
         KSb9YMwY0bLTdxAHL1CVP1FAVO0yPo5OAmHz2ebZIR1nDnHdCYE5Aa64yEvZVIuKZ6/0
         oVxyCU02xAmFBdzWtQh70Jy/mtckG2vFkY0/JGUnIxZyIeqvbtj9CNJMsKPbsf7wM+YY
         XK8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747660036; x=1748264836;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=caSmSC0vq01GdhGqSOu2/BTM+otwOs2jmU+X7gsR1t8=;
        b=durCuAAG5HJzupRjG5DI9waVs5nry0G8CDN++7QqGaKjgC4LiNLOlb3chex7czXGSY
         wDievlStkjIThFjYxgsYIS/9lqjMTM4eWWhBZOnKA6xQU4G3txAiaVnYf5mKXrh5NVMx
         8WKOVw05IlEZqbRslOLcfLftiP1t7wSXk6upf0mkEXOltkQXLGDblDJYbAyblP1aofye
         HmfrfCsL9vIcworXArITFbguavNc08Vhd1e5dhMKjxT9v65dACwAT/nF3A/5h4gjdnU9
         CxU5zC4pkb69aeCsipH5LVAMG7Lxcp6rMwt73iSDSgpRLaTLZKPhp4cyOjorQAlDmk1z
         ua4A==
X-Forwarded-Encrypted: i=1; AJvYcCU0PfVpIifX23jAXok8Ren5IcDGx7OT9Z/JT/15BE6/0rdUMgayzXN2dGDcVxsPsQu+/aNz4eiD7Eg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyI4NOnb7/FgNNqx32R7rwffHwTXzsFCK7yKr2QhDS0eeNTMAX+
	1FKwW7XI59LVd0nHJXNSvSSGMo0XWu9nREQkPNBRlAMYfRi/BG/my4MJYo/eDkAV6Q==
X-Gm-Gg: ASbGncsAphY0IPJEhxJvfjiCV/98ye1+p+lqLYY0xHnMeJDgPgKrsVnECy6IHXrqmhx
	3gm4U2pQ5vvcXz5Zap+eId4osdG8rmwtxG31u6DuxDQUu+/k08HDVdTRtVvEdLoZuy8/7g4QOBp
	iYt7CGywRK7RESAMJ10aQW78785Wp0zlzFbUj1wGD8Ecf/k7WKZA+QLewx1/M019ylRJpiJxwx5
	sL4ULKIKrTcSmtpR7fgDSsHwjICEwWD4Y+egqp/XSQJOMt/KfjoSFwweq49HVJ7BmT2+3Ewe4MZ
	PEph+sAX4hcWjBLzShl/FV2OEdBWkMji2aSdJhlzZBcoofIKYy3j8LFN9y5GYSNO34GYX3y9
X-Google-Smtp-Source: AGHT+IE9veAHiVEh9xD0E3zlqfCkraRawDf44MdYyhdmNw8MLVboMomansjQFhEegqSAlg1gPCU3UA==
X-Received: by 2002:a05:6402:27d1:b0:5fc:a51a:9c03 with SMTP id 4fb4d7f45d1cf-6010aa8c85bmr10793649a12.0.1747660035643;
        Mon, 19 May 2025 06:07:15 -0700 (PDT)
Message-ID: <19014158-499b-4ce1-ac2e-fa4eda69151a@suse.com>
Date: Mon, 19 May 2025 15:07:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 04/10] vpci: Refactor REGISTER_VPCI_INIT
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-5-Jiqian.Chen@amd.com>
 <0a6f40a9-a0ea-4652-8692-acfcf873463a@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 08:56, Chen, Jiqian wrote:
> On 2025/5/18 22:34, Jan Beulich wrote:
>> On 09.05.2025 11:05, Jiqian Chen wrote:
>>> --- a/xen/drivers/vpci/msi.c
>>> +++ b/xen/drivers/vpci/msi.c
>>> @@ -270,7 +270,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
>>>  
>>>      return 0;
>>>  }
>>> -REGISTER_VPCI_INIT(init_msi, VPCI_PRIORITY_LOW);
>>> +REGISTER_VPCI_LEGACY_CAP(PCI_CAP_ID_MSI, init_msi, NULL);
>>
>> To keep identifier length bounded, how about REGISTER_VPCI_CAP() here
>> and ...
>>
>>> --- a/xen/drivers/vpci/rebar.c
>>> +++ b/xen/drivers/vpci/rebar.c
>>> @@ -118,7 +118,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
>>>  
>>>      return 0;
>>>  }
>>> -REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
>>> +REGISTER_VPCI_EXTENDED_CAP(PCI_EXT_CAP_ID_REBAR, init_rebar, NULL);
>>
>> ... and REGISTER_VPCI_EXTCAP() here?
> 
> If so, I need to change the name of REGISTER_VPCI_CAP to be _REGISTER_VPCI_CAP ?
> 
> #define REGISTER_VPCI_CAP(cap, finit, fclean, ext) \
>   static vpci_capability_t finit##_t = { \
>         .id = (cap), \
>         .init = (finit), \
>         .cleanup = (fclean), \
>         .is_ext = (ext), \
>   }; \
>   static vpci_capability_t *const finit##_entry  \
>                __used_section(".data.vpci") = &finit##_t

That's a reserved name then. Since it's used only twice (to produce the
other two macros), REGISTER_PCI_CAPABILITY() maybe? Or one of
REGISTER_PCI__CAP() / REGISTER_PCI_CAP_()?

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:10:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:10:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989780.1373731 (Exim 4.92)
	(envelope-from )
	id 1uH0G5-0000qp-NB; Mon, 19 May 2025 13:10:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989780.1373731; Mon, 19 May 2025 13:10:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH0G5-0000qf-Kf; Mon, 19 May 2025 13:10:21 +0000
Received: by outflank-mailman (input) for mailman id 989780;
 Mon, 19 May 2025 13:10:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH0G4-0000qS-82
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:10:20 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9d2e1fc3-34b2-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 15:10:19 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ad572ba1347so121997266b.1
 for ; Mon, 19 May 2025 06:10:19 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d04b04esm594557066b.15.2025.05.19.06.10.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 06:10: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" 
X-Inumbo-ID: 9d2e1fc3-34b2-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747660219; x=1748265019; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Ayqhd5jrPNv5RaTlTv6beSfG1Rz34BfzHh4Hy5uDJoQ=;
        b=BY1IInk1Itfn9L42e1DSy+Ghf4xn/1VyFOVva4Xz57xdoReE6lE8G1mmLP5iP8JQrl
         pKKUeXKQchndVHAoxVW9RwEF4kfXZrhMDGZjLTIWOdRuj6MERHLmV2Y6+pF+2DaDRH7m
         X0H01R0XsE3uEbPQTTrk2Xb1Kk95eB4W2YLeNzbqtmntuItmdhDriwzZkK0Ib/4Cvt3O
         ytX3mFgwJsP6KaQHjaKcptBvVTg3SFjt27UNSF8Z4SOiaHdeSSxLJQcpYe4TqTaqUVbR
         zbmvKV2ibhk24asWeh/FVGmTgfAJmKm8sU+A9KqsO8chV/e8UtL58p5bRUWyO27pDugG
         8D7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747660219; x=1748265019;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Ayqhd5jrPNv5RaTlTv6beSfG1Rz34BfzHh4Hy5uDJoQ=;
        b=hNONtaLsgAE72L9JSRMz2KmzfrqT1YryZDQ7dWSJbbIrsgd086h3zHmQFdfMDiQKsK
         HUBehoMaw7EO04Zjpj4hj6DNbc961Xpg2oj3tiMxqb0FHbvTT4HzZ/jM1qpPg+gV3bD3
         LLL6d1mBVXJd1W1Ut1wuJxJ5hstJZgqkPdr2bo4FVOb/COVp1flf/2WuOK5gU6itEQkG
         tRswgblsSlydsfK+m7fbZJVccxCCgjUTM5GtTz7qvS8TAGGaegMK82suLDJG4RPkH3Rf
         eNdgN1/9bdR3BWzs30a9Cj8NqjZJteNV0b72wHQWmqum9ItYNeztCqQl8ejL1YJAnAGy
         JRng==
X-Forwarded-Encrypted: i=1; AJvYcCW/HEQgICS+9NvdLHcylWjqHinDjNNCRJZ5NW6OYKpug7qPXuVolr9rQ4ZSOG8tYd21JuGJ0+Ec6lI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzgAZo4S7o97Ob9ays39j+4NQ27nZZXLyemLByWtkUEIM1PSYCm
	SO3qNR/x5q5+sYgiwvPCY7kG5HfksxBprTeqLdrWdt+m7OcU1qeAbuCBUwCa9VeKGw==
X-Gm-Gg: ASbGncuW+QoMGd/5O+oOSePklK3PpOa63AdIbN/q/5VgWK4ZFHvIkfTrPvQ9wynbBH0
	gL+Gzux7+pfwN1fS5ef7HXAmxQ7yodwiHzGtUYvBEjtmNxXs2LbOE/5N5BsJIJUnhpFWOVTsR8x
	Y8pxBYKRffVnykrOCX49PGeBH60xNc18i2/HKQKPUj00IKsWYeQYxGYImo2IcNw2M9XUGn325vy
	owrlQ02tBP6geUwmlC/w+zWRcLC5hOxbK6aP/jK408ih9cxwY9cziikU7EWxp/vpa8Yfub15aJO
	HUC4K8sH/tO1IRxj1W2Iwi9yTuOjoHdSXF6raVnX4eihnSlimQQ/ryi1QhyE4A==
X-Google-Smtp-Source: AGHT+IF0DDEuj/HXFM9+FtsbTn6+JQ0ivqtmxeEOSkE8rykqCrPwSXZX4rofrkzZaNLSHUfpNSTO1Q==
X-Received: by 2002:a17:907:7f13:b0:ace:8003:6a6 with SMTP id a640c23a62f3a-ad52d441ff2mr1206454066b.6.1747660219003;
        Mon, 19 May 2025 06:10:19 -0700 (PDT)
Message-ID: <20d48f86-d7fe-47c8-89ab-61d816e1d6e9@suse.com>
Date: Mon, 19 May 2025 15:10:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-4-Jiqian.Chen@amd.com>
 
 
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 09:13, Chen, Jiqian wrote:
> On 2025/5/19 14:56, Jan Beulich wrote:
>> On 19.05.2025 08:43, Chen, Jiqian wrote:
>>> On 2025/5/18 22:20, Jan Beulich wrote:
>>>> On 09.05.2025 11:05, Jiqian Chen wrote:
>>>>> @@ -827,6 +827,34 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>>>>>                                                   PCI_STATUS_RSVDZ_MASK);
>>>>>  }
>>>>>  
>>>>> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
>>>>> +{
>>>>> +    unsigned int pos = PCI_CFG_SPACE_SIZE, ttl = 480;
>>>>
>>>> The ttl value exists (in the function you took it from) to make sure
>>>> the loop below eventually ends. That is, to be able to kind of
>>>> gracefully deal with loops in the linked list. Such loops, however,
>>>> would ...
>>>>
>>>>> +    if ( !is_hardware_domain(pdev->domain) )
>>>>> +        /* Extended capabilities read as zero, write ignore for guest */
>>>>> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
>>>>> +                                 pos, 4, (void *)0);
>>>>> +
>>>>> +    while ( pos >= PCI_CFG_SPACE_SIZE && ttl-- )
>>>>> +    {
>>>>> +        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
>>>>> +        int rc;
>>>>> +
>>>>> +        if ( !header )
>>>>> +            return 0;
>>>>> +
>>>>> +        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
>>>>> +                               pos, 4, (void *)(uintptr_t)header);
>>>>
>>>> ... mean we may invoke this twice for the same capability. Such
>>>> a secondary invocation would fail with -EEXIST, causing device init
>>>> to fail altogether. Which is kind of against our aim of exposing
>>>> (in a controlled manner) as much of the PCI hardware as possible.
>>> May I know what situation that can make this twice for one capability when initialization?
>>> Does hardware capability list have a cycle?
>>
>> Any of this is to work around flawed hardware, I suppose.
>>
>>>> Imo we ought to be using a bitmap to detect the situation earlier
>>>> and hence to be able to avoid redundant register addition. Thoughts?
>>> Can we just let it go forward and continue to add register for next capability when rc == -EXIST, instead of returning error ?
>>
>> Possible, but feels wrong.
> How about when EXIST, setting the next bits of previous extended capability to be zero and return 0? Then we break the cycle.

Hmm. Again an option, yet again I'm not certain. But that's perhaps just
me, and Roger may be fine with it. IOW we might as well start out this way,
and adjust if (ever) an issue with a real device is found.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:12:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:12:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989790.1373740 (Exim 4.92)
	(envelope-from )
	id 1uH0Ht-0001Sl-0p; Mon, 19 May 2025 13:12:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989790.1373740; Mon, 19 May 2025 13:12: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 1uH0Hs-0001Se-Ub; Mon, 19 May 2025 13:12:12 +0000
Received: by outflank-mailman (input) for mailman id 989790;
 Mon, 19 May 2025 13:12:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH0Hs-0001SY-Jj
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:12:12 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e011080c-34b2-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 15:12:11 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-6020053cbd5so355032a12.3
 for ; Mon, 19 May 2025 06:12:11 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac33d7asm5727855a12.52.2025.05.19.06.12.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 06:12:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e011080c-34b2-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747660331; x=1748265131; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=4Xwedm6Ci7gw/Y1DGzI1B2QHKHiuHQ2T900iL3ZIxhk=;
        b=MJbO1U37d05ziBs8G4sVdApwaynEYEXjMwtCJOs4sFFKwzMTdeDjSJ7uf9nnr4ML+Q
         tvEJ1j/caNIZytbgoWGawOg1hcE/ScukFghRfB/O1kaTTHUls1AUO0yzklRJ9/z9ybrT
         nqGmWHFDDB/6CPihfFbPqaV9L7130Mr+NFtKj3LAl6iIvd8dDsCJqRQVYSKLXHLMxBGj
         53eMXmrGuGgzx8DAFANP7vZFsWdqnOcs4jyEf9uG8Oyp0i62NH3uR9fPhUHp9ZTXUXM4
         PbjBXofGNsi9pNKKPO+MI6IgdjsNKKqf0WUwuiDeN6ykeIc2QNze4keb1vtjWXXD2Bqw
         CS8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747660331; x=1748265131;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=4Xwedm6Ci7gw/Y1DGzI1B2QHKHiuHQ2T900iL3ZIxhk=;
        b=AIXOqfSR+z2KegJ1kwMrN6vRu3dIbXE2EWAnJEIshIlwbTSkgygnB9aj+b0bBRY2Zn
         oO4ZBZu7e8RvaCENbcyMcwExCYOaTrkgF5G6lWIwBzAW35qxWPRPQnaiG5SHKXhqWL2q
         KxGhTMzROqCR9ZdcgnbdSIHzOHSMZFIyiYF1eKO5exjGWgqhZs2VVE86Al8Fx4+ledky
         bojhl5e0Vle8N2Nj/kIe3ZanewHEXlKtJ20crZ6InkTmYJalYW+qiyzGFOnmkR4URRN/
         5+rBMcnp/ut8PAe2Fhqb2PQkCKulzOruZOe2A7+Yuq5nC/ezDsj9b/2N3GDvPKqBOcoE
         WQCg==
X-Forwarded-Encrypted: i=1; AJvYcCWh5Q0981hsj9y5lU0TUbQ7QBHK8ujE6IJvzXpBhcNESsMsdaYNHeqp35QwIKk4K0LCLVIPkRjYkR4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywvuy8OV/A9tFK+2mQLU63H8dfB+UH7aYpSV+Bq1zCOlBc9Ek6U
	qDM8YHCOoYRxC8oNKmrhemdlzosP2pjAUk/lt4Ls66Z7ErXOBk64DheWx4VxI5dqZA==
X-Gm-Gg: ASbGncvElbW7o9Yt9goUdcUX4evhuDdvtAtuul4bS825Bz0Iz+AptoWP4Eg1hQ9aZH8
	UaOcl7PPP7kGm69hVg+dXaw2cD9ExVcR2cVhIMIsK83O8yGuEJYzNcBMkrvPGDD42/8N7CdHEAh
	f4NK8/PteKNWe4tg8m9zwsyiXi5Rj1mubWB+m0fDTF2PbfDUIjNbH5ybfOETr+RWZMNg4EyDD67
	iuUZAfgvIEqUGqvLsPa/c/pml1KjGy54WasNa580B2WZJ3UkNdN4O7WBKi0cvGpHtkfyvaeiWRG
	/r+gl8yg9pZPZChztFpDdwtL0Vc0NdrOXAlGkDb0TavsjtVOTNeBoB7CBj3bCA==
X-Google-Smtp-Source: AGHT+IG9V3kbGylfNierMJujsYwFRYqDIP892HWrZCzl+nyJctU+ZQeWm9SGfEEjmJOXjVPZXqkaCg==
X-Received: by 2002:a05:6402:26cd:b0:601:d9f4:eac6 with SMTP id 4fb4d7f45d1cf-601d9f4eef5mr4524785a12.21.1747660331151;
        Mon, 19 May 2025 06:12:11 -0700 (PDT)
Message-ID: <981cf287-f096-4dd8-b98f-3b59de4a76c7@suse.com>
Date: Mon, 19 May 2025 15:12:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 06/10] vpci: Hide extended capability when it fails to
 initialize
To: "Chen, Jiqian" 
Cc: "Huang, Ray" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 ,
 "xen-devel@lists.xenproject.org" 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-7-Jiqian.Chen@amd.com>
 <48c71b8b-2b59-41aa-ad02-b237d53f1d6d@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 09:41, Chen, Jiqian wrote:
> On 2025/5/18 22:47, Jan Beulich wrote:
>> On 09.05.2025 11:05, Jiqian Chen wrote:
>>> --- a/xen/include/xen/pci_regs.h
>>> +++ b/xen/include/xen/pci_regs.h
>>> @@ -448,7 +448,10 @@
>>>  /* Extended Capabilities (PCI-X 2.0 and Express) */
>>>  #define PCI_EXT_CAP_ID(header)		((header) & 0x0000ffff)
>>>  #define PCI_EXT_CAP_VER(header)		(((header) >> 16) & 0xf)
>>> -#define PCI_EXT_CAP_NEXT(header)	(((header) >> 20) & 0xffc)
>>> +#define PCI_EXT_CAP_NEXT_MASK		0xFFF00000U
>>> +/* Bottom two bits of next capability position are reserved. */
>>> +#define PCI_EXT_CAP_NEXT(header) \
>>> +    (MASK_EXTR(header, PCI_EXT_CAP_NEXT_MASK) & 0xFFCU)
>>
>> Please can the hex digits all be / remain to be lower case, with just
>> the U suffixes be upper case?
> Including "0xFFF00000U" or just "0xFFCU" ?

Both. See also patch context here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:16:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:16:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989800.1373750 (Exim 4.92)
	(envelope-from )
	id 1uH0MI-000237-H0; Mon, 19 May 2025 13:16:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989800.1373750; Mon, 19 May 2025 13: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 1uH0MI-000230-EM; Mon, 19 May 2025 13:16:46 +0000
Received: by outflank-mailman (input) for mailman id 989800;
 Mon, 19 May 2025 13:16:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH0MH-00022p-51
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:16:45 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8266f2e6-34b3-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 15:16:44 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-6020053cbd5so365932a12.3
 for ; Mon, 19 May 2025 06:16:44 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005a6e746csm5914744a12.47.2025.05.19.06.16.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 06: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" 
X-Inumbo-ID: 8266f2e6-34b3-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747660603; x=1748265403; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=WD8V0FqycuvaqmNySlstSxhbQi/5XV6hGxtYY5KusOE=;
        b=fdnV8OeV/BDpPhH3wk/1ukGTV/GY9G+odZGQwDA9uQm2VQwsSG+AwGRi7Nr4a/EOnK
         JXPH+ewNh8spmV52riONWZQhaD85IaRDZ59U5HSBM0IMWPtwhjfF2x2h9Y8fUxkPuM6Q
         KwURdwUN5isa9Pevt+qnVebt8FDIQC1JnIkIjic3Kb9OjqXl7Ebug+ZH8F1R1qIBmHZp
         AFbuxQ+j8ahd/c0f9Q1bRemNJ40XbLLInWKOlTwrFKguRTMLhB65c+c4WtKkIIZICXDT
         PTMUQyEq0BVPcPiEJJdngx7qSVR98rFZc9BVyHi9CsEbVLRL4OK0LNynfh2i22tvHCPO
         kQNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747660603; x=1748265403;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=WD8V0FqycuvaqmNySlstSxhbQi/5XV6hGxtYY5KusOE=;
        b=C8PFvGBe5i5eNUavARGDBrhuHBwtzpBMXH6rkQ7H2/nvljgLCoH5v+7NvYZ5ybVaEO
         FUhSe3NvIm3wA5xiZWSg2KZUvZeFEIM/wNWigQJrHXo1LYgRlBauH6sdtDmUsCM2CDOq
         O3LmjHL81qyoL9l/T6oatIk1pF7mrLpr2pBZm2Z4nzpGD5yXsEQXT1OJQ338DtxW7AK7
         bGOf1MnLu4M0wK469fA6l6zj/i6GltAFWLSnjE3N/moKU2yT+OldKhGxsQOup1ou4mL6
         3QJd0aytNm2hzRpMExUwKGkflc7o+o9/vhKG0Zx7foCb66JaBaP8bP0+Rt+dDzwFjzr1
         pV7g==
X-Forwarded-Encrypted: i=1; AJvYcCXf95x7olLU18kiMnHun1P9x1oa9omEg6Z7MJdnglijDml8vdUrEum/6XOAMAdtuHt3aDEbsPCd7F8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwUD9V0FGlLdb8SaRKrHUBaAuSY5ntPCFZE47i5eKV6flvsrqy+
	9dqvLA7tjgfVhF3+lDKr4FFuVrv8YxHdQrCVe+NcuVc7r5fFmHh5xp6ZPoZuV3uOGw==
X-Gm-Gg: ASbGncsSvXjV0bjCIHurS0ywyCnecYpwBE9F7c4TpYSCwMySl/rwWDhu6EVH3O/Naat
	nY/cj7eg9hWqa1u/w1+TsezlQYAQB/ccA4y/GpB1zK6ARQsrLvvvpJ41LKus3652QhpB3YNfbwM
	zLrDokqDVM6jcZJDSix185jOKtf4bU7vcLPOdfcT9ytK4IcRUBTD/PsAHUaykFmGqsZCuEh/yri
	76yVSzPIKVlLrz9UGcFhxAtw+YMhAGWk5oRnAqNBrYCH81TcuEFPPBH912M0seLL00B4D15xhMU
	La/y5uUkTJ4GprNUmqhwW+I8hHqzdd0DlPEoR0MmnSZm7LEdL1YqoLAxXsk6YTs7DPMeVaG7
X-Google-Smtp-Source: AGHT+IHgXCOMh5m04LxzlKxcWSn8SZr41xZhUdqsVxheOpW75MnMHhY6kihnRo2GLQd3bZj01dFwUw==
X-Received: by 2002:a05:6402:50c9:b0:601:a681:4d5c with SMTP id 4fb4d7f45d1cf-601a6814f05mr6213982a12.32.1747660603609;
        Mon, 19 May 2025 06:16:43 -0700 (PDT)
Message-ID: <0c167d88-798c-46df-a912-60c4252a8e26@suse.com>
Date: Mon, 19 May 2025 15:16:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/16] xen/riscv: introduce register_intc_ops() and
 intc_hw_ops.
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <7cd7d3780bb6db45b92c971ff8bcf2634570431f.1746530883.git.oleksii.kurochko@gmail.com>
 <2436be2e-28d4-4e48-a391-84b21651b339@suse.com>
 <9c202b56-ad59-481b-924a-addefcea84cd@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <9c202b56-ad59-481b-924a-addefcea84cd@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 11:16, Oleksii Kurochko wrote:
> 
> On 5/15/25 10:06 AM, Jan Beulich wrote:
>> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/include/asm/intc.h
>>> +++ b/xen/arch/riscv/include/asm/intc.h
>>> @@ -8,6 +8,8 @@
>>>   #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
>>>   #define ASM__RISCV__INTERRUPT_CONTOLLER_H
>>>   
>>> +#include 
>> If you need this include anyway, why ...
>>
>>> @@ -17,6 +19,26 @@ struct intc_info {
>>>       const struct dt_device_node *node;
>>>   };
>>>   
>>> +struct irq_desc;
>> ... this "forward" decl for something that's then already fully defined?
>> I can't, however, spot why xen/irq.h would be needed for anything ...
> 
> forward decl for irq_desc could be really dropped.
> 
> Inclusion of xen/irq.h was added because of hw_irq_controller which is defined as:
>    typedef const struct hw_interrupt_type hw_irq_controller;
> 
> And I'm not sure how to do forward declaration properly in this case. Just use
> an explicit definition of hw_irq_controller for host_irq_type member of struct
> intc_hw_operations seems as not the best one option:
>    struct hw_interrupt_type;

This isn't needed for the use below.

>    struct intc_hw_operations {
>        ...
>        // const hw_irq_controller *host_irq_type;
>        const struct hw_interrupt_type *host_irq_type;

It might be that something like this is already done elsewhere in the tree,
so not really an issue imo if a 2nd instance appeared.

> It seems like the best one option is to do the following:
>    typedef const struct hw_interrupt_type hw_irq_controller; in asm/intc.h.
> I will follow it then.

Misra may dislike this.

>>> --- a/xen/arch/riscv/intc.c
>>> +++ b/xen/arch/riscv/intc.c
>>> @@ -5,6 +5,15 @@
>>>   #include 
>>>   #include 
>>>   
>>> +#include 
>>> +
>>> +static struct __ro_after_init intc_hw_operations *intc_hw_ops;
>> Nit: Attributes between type and identifier please. Also shouldn't both
>> this and ...
>>
>>> +void __init register_intc_ops(struct intc_hw_operations *ops)
>> ... the parameter here be pointer-to-const?
> 
> Then|intc_hw_ops| should also be marked as|const| (with the removal of|__ro_after_init|),

Why remove the attribute?

> otherwise a compilation error will occur (something like/"assignment discards 'const' qualifier"/).
> 
> Additionally,|__ro_after_init| should be replaced with|const| for|aplic_ops| in future
> patches.

Same question here then.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:19:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:19:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989808.1373760 (Exim 4.92)
	(envelope-from )
	id 1uH0Oh-0002a0-Sn; Mon, 19 May 2025 13:19:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989808.1373760; Mon, 19 May 2025 13: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 1uH0Oh-0002Zt-Pr; Mon, 19 May 2025 13:19:15 +0000
Received: by outflank-mailman (input) for mailman id 989808;
 Mon, 19 May 2025 13:19:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH0Og-0002Zn-U2
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:19:14 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dbc06327-34b3-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 15:19:14 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ad563b69908so194561166b.3
 for ; Mon, 19 May 2025 06:19:14 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d04af35sm592297066b.32.2025.05.19.06.19.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 06:19: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" 
X-Inumbo-ID: dbc06327-34b3-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747660753; x=1748265553; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=7VcApOWdiLIxQVkLmWx6pEU+M+qAz3pD4fzMs27qcn8=;
        b=E1FQl2IkM3GhdiGjF3E74oKFZeJ3wUG2sSLxCgedrCP2vnOofqcRU6QA3Cm0n15l4C
         aDk0gK+TIfDRwXDy2svLuzN3/kdJv9RlUQPMd9VSSjnRecq4RCmme7Cz48xZKBn4A9Hs
         mWhvcE5sp9Tt+9I0tezxHuafOIHh+YwwF8aXmcSZKHSTLKxwiUuxNH01TTVkMAhCKFIE
         tLD2gnZQFbL8Gm9reKWiPtZoXSGSigTwAXaqA2GKeWv3MoG4vH9Hf2Ro3yamf7gAPCGy
         4E+Op0lYwvtbEX9UJ7bSfqGViZLeiSL331NgZaFqRducz7rVDBXnatvCx7NLEwe9E7sz
         xsiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747660753; x=1748265553;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7VcApOWdiLIxQVkLmWx6pEU+M+qAz3pD4fzMs27qcn8=;
        b=qa59LjlOHVaCoHm+4wa6Yhz3rpzXXyb7Mh8c8d8kmW1y4l7bx1BdRBqkP/BVD19vpb
         2xo1tGQj36kt8jjSAyS6s7XrsGbbWiIse8pVpX7wuYpHIic+evV6IcLDgzVn1LOpnkWB
         xtglEdTfXTs+CL/z3+cKoRaKhKt0aRwKa5KcKuSAXJPWl8q+e/RnNcoRXM70kbMCpCA+
         rLrTG/2Q9gGUHQTMeSLHBxkg1VVflG4aOktc645CjyS7g3Lq0sMwadZzOqVh6ZmEsatO
         tTktPcITPbUabPSMyHdaFUlUMjIfSN80njVrik0R3wMx4BmwpoRc1XXYbNBPpoyc2P6X
         UIFA==
X-Forwarded-Encrypted: i=1; AJvYcCX0B8TL32hKGO25JAcaOLcT4SovO+D7l5eZXn54M+yhnYrirqZO1YUG7mWPRZ9ZGSJAE7pkPVYNx2s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwG+Sv/Xk5vXYoVefxRoVqcbKNtefCYINZx4pTT9cJjNz6denu+
	h5CwCBDdwfWgqelXxqRNiJ9TzmZj/V4f9QeNiYxrFBoxo34zzLSC9QdDDYCV1LBNVQ==
X-Gm-Gg: ASbGncsxeTGNxKdXAKzoZwHFkZlRWtLEKumS0fx/w9+PYQYiQxJUspRWRzuSJTTKxqC
	E82SvJ8+l/dhwBuooERIq/Jc6OOSR/Fq1rJCJfqD04uCfkWKLdmmcKUhgDlpr+uHO69zcN4v0Fh
	0igC693pBy7xK83X2JotciwXuFkHvfdi5gUCLXJRjuXA0wvV2wbXO4fkQGt1lOp0eOyAH5n8bHG
	C9Gh5NNFliZRK5bLznoRfBA9ZlYxGAEED198de71dCAev8dmGYc/8fEH17pAIK3jkHHUiL85AYn
	ChkEJimrzZzyIFUedIL325JFEV9LfcWtohB6LbIX84giU9mNOlhZuWJENg0jYA==
X-Google-Smtp-Source: AGHT+IFHUULXT9f5NSn1u39Zbnhwb2Rok/uZ509CdN0U6e7DlyCAeOvE7ujcI5+EBi3HUar6tBDfLg==
X-Received: by 2002:a17:907:3fa2:b0:ad2:3577:38fb with SMTP id a640c23a62f3a-ad536bbf0fbmr1034080766b.30.1747660753465;
        Mon, 19 May 2025 06:19:13 -0700 (PDT)
Message-ID: <0f673a09-840c-4319-bec8-62fd920a6b84@suse.com>
Date: Mon, 19 May 2025 15:19:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-6-Penny.Zheng@amd.com>
 <57a3b2c0-d57d-46e3-b248-0e243f715423@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19.05.2025 10:36, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Tuesday, April 29, 2025 8:52 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Anthony PERARD ;
>> Orzel, Michal ; Julien Grall ; Roger Pau
>> Monné ; Stefano Stabellini ; xen-
>> devel@lists.xenproject.org
>> Subject: Re: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
>> cmdline
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> --- a/xen/include/acpi/cpufreq/processor_perf.h
>>> +++ b/xen/include/acpi/cpufreq/processor_perf.h
>>> @@ -5,6 +5,9 @@
>>>  #include 
>>>  #include 
>>>
>>> +/* ability bits */
>>> +#define XEN_PROCESSOR_PM_CPPC   8
>>
>> This needs correlating (at least via commentary, better by build-time checking) with
>> the other XEN_PROCESSOR_PM_* values. Otherwise someone adding a new
>> #define in the public header may not (easily) notice a possible conflict. With that in
>> mind I also question whether 8 is actually a good choice: That's the obvious next
>> value to use in the public interface. SIF_PM_MASK is 8 bits wide, so a sensible
>> value to use here would by e.g. 0x100.
>>
> 
> I've added a public flag anchor "XEN_PROCESSOR_PM_PUBLIC_END" in public header:
>          #define XEN_PROCESSOR_PM_PUBLIC_END    XEN_PROCESSOR_PM_TX
> and will do the following build-time checking:
>         BUILD_BUG_ON(XEN_PROCESSOR_PM_CPPC <= XEN_PROCESSOR_PM_PUBLIC_END);

I don't really see why anything would need to be added to the public
header (and we really should strive to avoid unnecessary additions).

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:22:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:22:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989819.1373770 (Exim 4.92)
	(envelope-from )
	id 1uH0RM-0004L2-CV; Mon, 19 May 2025 13:22:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989819.1373770; Mon, 19 May 2025 13:22: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 1uH0RM-0004Kv-9Z; Mon, 19 May 2025 13:22:00 +0000
Received: by outflank-mailman (input) for mailman id 989819;
 Mon, 19 May 2025 13:21:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH0RL-0004Kp-8g
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:21:59 +0000
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com
 [2607:f8b0:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3c61edd1-34b4-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 15:21:56 +0200 (CEST)
Received: by mail-pf1-x42f.google.com with SMTP id
 d2e1a72fcca58-7399a2dc13fso5615316b3a.2
 for ; Mon, 19 May 2025 06:21:56 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 41be03b00d2f7-b26eaf6e6a5sm6185140a12.17.2025.05.19.06.21.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 19 May 2025 06: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" 
X-Inumbo-ID: 3c61edd1-34b4-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747660915; x=1748265715; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=Sy1pJC7nbP1ymJfqNb61gZHd0v9aVsfr1yp1yHFOYIo=;
        b=IVXNjCuaJl5A4HOln2DGVrhX1Mc8Y3iFcrHk+uUnp/LUiKLLZYRzNzYiyefdAj7gYX
         i7+kA6u+PuH8LiencbZ57PwK/uJxRpI/PQUvaDt4HKunsCANQ6MC7pYxfCXw9wNizwOc
         VKZK5Xu6YqrPJ9eb0utD+0B7sJxHaUM6RJYlM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747660915; x=1748265715;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Sy1pJC7nbP1ymJfqNb61gZHd0v9aVsfr1yp1yHFOYIo=;
        b=bu7PQdV+4ksviEZI7zks3id3XNFhBjOeNczGtBSjlXdKxr5mtrwA24WInlvsQHNES/
         NNmlxGg7LsVCISBLesqhq9xKdtwc8YQOdiwPKIsqvOHKvoT2a8lrtCLIwAZW1w4+1Ofb
         BzeGXhy/2CtiBabCMMAT04xg4Nab+jkTV84T7y8VAuBc/fXnJHOWPp7Po4682RIXjJkY
         3IeYAemJa1sgaetwF70g4O10HlKAH2JOGfUlMgIh+AIyk0Sp+y4EVgqNViNa+18Vlqz0
         YdiSlCrqQ5N8Z65ra8EPbwUULuWN5guAfA0+hDEMW0OEACnIryVARSwQ1J+1tZJvo+F2
         0MCg==
X-Forwarded-Encrypted: i=1; AJvYcCVOZrz2K3ziKGhyzVc44kNJC/TvptN2H+B+lRXqM6dyxhLrUSI630N9twjR7xWeV4F9zlze/deV6zM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyPsnpYaRAUAK8Kj/haZDWikdBA8c9UWVtTtRnHQTj20ckzXhA/
	AoBkMUXr99CIv7f9YoXm1Uw2Mv337cFqvPQv9pklPoYtniWkm5K1AgK0FLTUZSasPic=
X-Gm-Gg: ASbGncv+FEw7WEIfDPVV+mOAXyJdLWr9t29prHFi8/D3i0qikgjQ0nl5amA49cYuVpM
	p34LYYlfpbgra2tF6srdv8Z4I7cSBWOGNxD/MlEQmVCf5gNsA0JniE0Ws2l0oyZs5W0u/GsEeRu
	MSHD98c4wkoIZtYo2Ra4rTdgyr3hDM4ExcoP+JpnrD7tKtJ4uuVFAUBk+TtGLK3iDOXqQdSCuzO
	W5S2vUGedMiJ4+XXTuG9CMMmUWQ3N3x+Ez9mGBozkEy2NlShp0E3kiuHWJ58oInwkFQKxZRNk2d
	iHY5jtHvwTFd64rv+N60499cYN01MrWFgabaGNwERR/I/0ZdQEv4xWvcx60CUiDDyiOIZalbCzw
	QTB2vNsKoQwZIC0GTU3NqI/coGERFF3kbIOY=
X-Google-Smtp-Source: AGHT+IFRcFqUEmDbjhXB/nEScqqHFeANS3C8hjm3Bc9/htyd3VMNuG8wsrgsLzU/PI/36peBjVgi1g==
X-Received: by 2002:a05:6a20:9c9b:b0:1fd:f8eb:d232 with SMTP id adf61e73a8af0-2170cc90d47mr19195985637.24.1747660915251;
        Mon, 19 May 2025 06:21:55 -0700 (PDT)
Date: Mon, 19 May 2025 15:21:49 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "Chen, Jiqian" ,
	"xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
Message-ID: 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-4-Jiqian.Chen@amd.com>
 
 
 
 
 <20d48f86-d7fe-47c8-89ab-61d816e1d6e9@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20d48f86-d7fe-47c8-89ab-61d816e1d6e9@suse.com>

On Mon, May 19, 2025 at 03:10:17PM +0200, Jan Beulich wrote:
> On 19.05.2025 09:13, Chen, Jiqian wrote:
> > On 2025/5/19 14:56, Jan Beulich wrote:
> >> On 19.05.2025 08:43, Chen, Jiqian wrote:
> >>> On 2025/5/18 22:20, Jan Beulich wrote:
> >>>> On 09.05.2025 11:05, Jiqian Chen wrote:
> >>>>> @@ -827,6 +827,34 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
> >>>>>                                                   PCI_STATUS_RSVDZ_MASK);
> >>>>>  }
> >>>>>  
> >>>>> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
> >>>>> +{
> >>>>> +    unsigned int pos = PCI_CFG_SPACE_SIZE, ttl = 480;
> >>>>
> >>>> The ttl value exists (in the function you took it from) to make sure
> >>>> the loop below eventually ends. That is, to be able to kind of
> >>>> gracefully deal with loops in the linked list. Such loops, however,
> >>>> would ...
> >>>>
> >>>>> +    if ( !is_hardware_domain(pdev->domain) )
> >>>>> +        /* Extended capabilities read as zero, write ignore for guest */
> >>>>> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
> >>>>> +                                 pos, 4, (void *)0);
> >>>>> +
> >>>>> +    while ( pos >= PCI_CFG_SPACE_SIZE && ttl-- )
> >>>>> +    {
> >>>>> +        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
> >>>>> +        int rc;
> >>>>> +
> >>>>> +        if ( !header )
> >>>>> +            return 0;
> >>>>> +
> >>>>> +        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
> >>>>> +                               pos, 4, (void *)(uintptr_t)header);
> >>>>
> >>>> ... mean we may invoke this twice for the same capability. Such
> >>>> a secondary invocation would fail with -EEXIST, causing device init
> >>>> to fail altogether. Which is kind of against our aim of exposing
> >>>> (in a controlled manner) as much of the PCI hardware as possible.
> >>> May I know what situation that can make this twice for one capability when initialization?
> >>> Does hardware capability list have a cycle?
> >>
> >> Any of this is to work around flawed hardware, I suppose.
> >>
> >>>> Imo we ought to be using a bitmap to detect the situation earlier
> >>>> and hence to be able to avoid redundant register addition. Thoughts?
> >>> Can we just let it go forward and continue to add register for next capability when rc == -EXIST, instead of returning error ?
> >>
> >> Possible, but feels wrong.
> > How about when EXIST, setting the next bits of previous extended capability to be zero and return 0? Then we break the cycle.
> 
> Hmm. Again an option, yet again I'm not certain. But that's perhaps just
> me, and Roger may be fine with it. IOW we might as well start out this way,
> and adjust if (ever) an issue with a real device is found.

Returning -EEXIST might be fine, but at that point there's no further
capability to process.  There's a loop in the linked capability list,
and we should just exit.  There needs to be a warning in this case,
and since this is for the hardware domain only it shouldn't be fatal.

If it was for domUs we would possibly need to discuss whether
assigning the device should fail if a capability linked list loop is
found.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:22:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:22:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989826.1373781 (Exim 4.92)
	(envelope-from )
	id 1uH0Rw-0004nb-Kd; Mon, 19 May 2025 13:22:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989826.1373781; Mon, 19 May 2025 13: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 1uH0Rw-0004nU-Hh; Mon, 19 May 2025 13:22:36 +0000
Received: by outflank-mailman (input) for mailman id 989826;
 Mon, 19 May 2025 13:22:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH0Ru-0004f1-Qy
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:22:34 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 531a9687-34b4-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 15:22:34 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5fbcd9088a7so207092a12.0
 for ; Mon, 19 May 2025 06:22:34 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ae48253sm5785790a12.81.2025.05.19.06.22.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 06:22:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 531a9687-34b4-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747660954; x=1748265754; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=uIDeus1vsoHTicE2Z2VgYl/dNp0Zsle+G/4lsoYeIBI=;
        b=MbkrjCQ1B68iG9DACpwwU0WDP4Og4L14Lzjbt27vX9UjtregzeW4mMtn1GGjaJGmPK
         YfLW9ZzjuqRy48kv1INQV6lokNFiV8SnONtbpv33ZMcSznu0CRWOXD9mn1VzUrTTpoXQ
         fdOcukKoGGFff3780vnA0rtYMAOWZTi32WaBzN0bGJDTOVLYUS1R9+blSR3jDm76s3X/
         IOm3CcMasjN8fKHf+8Qd4rIb7zp8MqrFo4+3nYQbUzhA3z8IaKK5NoyaKzCU+/QGqEkH
         2xSgqpFJVL/oA4eE8g40E2BvzuwRA+/vNdvAv1SlFV77Pitsxmb79186MGChNRYyuaKQ
         ydIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747660954; x=1748265754;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=uIDeus1vsoHTicE2Z2VgYl/dNp0Zsle+G/4lsoYeIBI=;
        b=opb3UJbe+G3GIQxmDv4gfDJRuXlxQN2XIddwsTlPT+tpir803WuqegZ0wZB4dWPiu1
         UhDioE1RagYkMj7RnC7UMHrfVYdVued9OjOP4OefbQOUb7Z8RjhlJnD8qdBaPshgdk1a
         QTX0tD2IZH8sj59GGxCqEBDI4LaDMoBFgpVEpPCk2aT2rPzIneLMi5T1+L1b0jY1nS8V
         vmfY1jJGGte284yrDiqgTYVdj6X9Sjk7h/gVwiGeODO+tGZ0s0KFgsnQPFArn/SdK1pG
         7zw8pxjIwQ7Au9XEuDE46T71NdEC+4m2InihsJIsgrfYitah+vQlkzqV8yXUcGuHs4C0
         1+IQ==
X-Forwarded-Encrypted: i=1; AJvYcCVZVnKpl/47SNnnE3AcP29LNwh44faljwXAQF5JYOMiQF++3V31wu6JHqc2ApU8oIewsLw73dB2pzI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxGvb5zdBASm+WMV6yRMG/wwI9CIPpBtdZkIMyKwZgUG5kTYGJ9
	N1d2lPGYKc/iBvvJ9qecFzhRTwdR3hueBorf/l7cR6q2sw04RzqerejcsUcpdkgegQ==
X-Gm-Gg: ASbGnctN8twHHvDwehZZOM1dAfD+NcMNtTty3+rMZ9UT89MAkeQPGiE2HztQteku8YI
	eqqf9uW550DyJlSKHavP5LgKExilNVpwm5s5Uc+XMsWl1DamnCtcv0bKj0A+vUwXlqHLyOI/F3X
	8EGePvHqNRoS7PkfDMmu894m/NlfGqrSUZXdE8kPyOcs86j26/L4XsQMIYJgwwxjeYbCfzWVPCw
	oDxgaBuzYvgs5W/44PiHev2b2FFjAO1yWXO1SjBPnrk5HrHq3PCcYhciHCoK4vUweWQFfejOs3z
	9MtnNScEowYi1EKHlz/eBs3dj58zPuqLIzM8mBKYtKQ0f97bEJVry/QmW2SdgQ==
X-Google-Smtp-Source: AGHT+IEWKi5lcrHZBb3KA1Ko4dCN4pOgwspWblnpZm8z7DEtrpo5pjWvI6ZnL8p32TEc5h6/iPOOPA==
X-Received: by 2002:a05:6402:1057:b0:600:29cc:e061 with SMTP id 4fb4d7f45d1cf-60029cce38fmr9011601a12.13.1747660953728;
        Mon, 19 May 2025 06:22:33 -0700 (PDT)
Message-ID: <558c7ec2-77ea-42e6-8568-af8b74e19c88@suse.com>
Date: Mon, 19 May 2025 15:22:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 6/6] x86/hvm: reduce the need to flush caches in
 memory_type_changed()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Oleksii Kurochko 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-7-roger.pau@citrix.com>
  
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19.05.2025 13:08, Roger Pau Monné wrote:
> On Sun, May 18, 2025 at 01:44:49PM +0200, Jan Beulich wrote:
>> On 16.05.2025 11:45, Roger Pau Monne wrote:
>>> Not sure whether this attempt to reduce cache flushing should get some
>>> mention in the CHANGELOG.
>>
>> Err on the side of adding an entry there?
> 
> Oleksii would you be fine with me adding:
> 
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 1ea06524db20..fa971cd9e6ee 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -11,6 +11,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>     - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
>     - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
>   - Linux based device model stubdomains are now fully supported.
> + - On x86:
> +   - Restrict the cache flushing done in memory_type_changed() to improve
> +     performance.

Maybe better to mention function names here, saying "after a memory type change
by a guest" instead?

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:30:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:30:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989834.1373791 (Exim 4.92)
	(envelope-from )
	id 1uH0ZG-0006Ml-9l; Mon, 19 May 2025 13:30:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989834.1373791; Mon, 19 May 2025 13:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH0ZG-0006Me-6W; Mon, 19 May 2025 13:30:10 +0000
Received: by outflank-mailman (input) for mailman id 989834;
 Mon, 19 May 2025 13:30:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uH0ZE-0006MY-PY
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:30:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uH0ZE-001NcL-18;
 Mon, 19 May 2025 13:30:08 +0000
Received: from lfbn-gre-1-199-136.w90-112.abo.wanadoo.fr ([90.112.161.136]
 helo=l14) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uH0ZD-00En8v-2j;
 Mon, 19 May 2025 13:30: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=bIyNiXYHNldGruXG6lNwvZe6rL2DuiNpOvIcWcfxW0E=; b=wRmitf9AwzYlYV1W7JgeVr4X5i
	zilV+Pm1uMb/dQ1+q0tqFd73Mzh/KC7bi/1P0WGiW1ZCIvzleTOz2fBCixbM3cz2UFkifAfBq3Gtp
	6/uZ1l5MBgTwnnLlUY0fvo4Um5TIakdYHI9EdUwpatOfsGuuUfOcTLMGzhU7gkHteheI=;
Date: Mon, 19 May 2025 15:30:05 +0200
From: Anthony PERARD 
To: Juergen Gross 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Anthony PERARD ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Subject: Re: [PATCH v3 2/4] tools: remove support for running a guest with
 qemu-traditional
Message-ID: 
References: <20250429110636.30518-1-jgross@suse.com>
 <20250429110636.30518-3-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250429110636.30518-3-jgross@suse.com>

On Tue, Apr 29, 2025 at 01:06:32PM +0200, Juergen Gross wrote:
> diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
> index 34f6753f61..227b5ceafb 100644
> --- a/tools/libacpi/mk_dsdt.c
> +++ b/tools/libacpi/mk_dsdt.c
> @@ -105,7 +81,7 @@ int main(int argc, char **argv)
>  {
>      unsigned int cpu, max_cpus;
>  #if defined(CONFIG_X86)
> -    dm_version dm_version = QEMU_XEN_TRADITIONAL;
> +    dm_version dm_version = QEMU_INVALID;
>      unsigned int slot, dev, intx, link;
>  
>      max_cpus = HVM_MAX_VCPUS;
> @@ -160,6 +134,11 @@ int main(int argc, char **argv)
>          }
>      }
>  
> +    if (dm_version == QEMU_INVALID) {

`dm_version` is only available if CONFIG_X86 is defined, so that doesn't
build on Arm.

> +        fprintf(stderr, "--dm_version is a mandatory parameter.\n");
> +        return -1;
> +    }
> +
>      /**** DSDT DefinitionBlock start ****/
>      /* (we append to existing DSDT definition block) */
>      indent_level++;
> diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
> index 4627564c0d..645119b65a 100644
> --- a/tools/libs/light/libxl_dm.c
> +++ b/tools/libs/light/libxl_dm.c
> @@ -2463,16 +2189,15 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
>                          "%s",
>                          libxl_bios_type_to_string(guest_config->b_info.u.hvm.bios));
>      }
> -    /* Disable relocating memory to make the MMIO hole larger
> -     * unless we're running qemu-traditional and vNUMA is not
> -     * configured. */
> +
> +    /*
> +     * Disable relocating memory, having a lager MMIO hole isn't

I think you wanted to write "larger" and not "lager".

> +     * implemented with qemu-xen.
> +     */
>      libxl__xs_printf(gc, XBT_NULL,
>                       libxl__sprintf(gc, "%s/hvmloader/allow-memory-relocate",
>                                      libxl__xs_get_dompath(gc, guest_domid)),
> -                     "%d",
> -                     guest_config->b_info.device_model_version
> -                        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
> -                     !libxl__vnuma_configured(&guest_config->b_info));
> +                     "0");
>      ret = xc_domain_set_target(ctx->xch, dm_domid, guest_domid);
>      if (ret<0) {
>          LOGED(ERROR, guest_domid, "setting target domain %d -> %d",
> @@ -3196,26 +2917,19 @@ static void device_model_launch(libxl__egc *egc,
>          libxl__xs_printf(gc, XBT_NULL,
>                           GCSPRINTF("%s/hvmloader/bios", path),
>                           "%s", libxl_bios_type_to_string(b_info->u.hvm.bios));
> -        /* Disable relocating memory to make the MMIO hole larger
> -         * unless we're running qemu-traditional and vNUMA is not
> -         * configured. */
> +        /*
> +         * Disable relocating memory, having a lager MMIO hole isn't

Here too, I think you wanted to write "larger" and not "lager".

> +         * implemented with qemu-xen.
> +         */
>          libxl__xs_printf(gc, XBT_NULL,
>                           GCSPRINTF("%s/hvmloader/allow-memory-relocate", path),
> -                         "%d",
> -                         b_info->device_model_version==LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
> -                         !libxl__vnuma_configured(b_info));
> +                         "0");
>          free(path);
>      }

And with those fixed: Reviewed-by: Anthony PERARD 
I guess I can fixed those on commit if that's fine by you?

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:35:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:35:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989842.1373801 (Exim 4.92)
	(envelope-from )
	id 1uH0dv-0007Bn-QP; Mon, 19 May 2025 13:34:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989842.1373801; Mon, 19 May 2025 13:34: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 1uH0dv-0007Bg-NR; Mon, 19 May 2025 13:34:59 +0000
Received: by outflank-mailman (input) for mailman id 989842;
 Mon, 19 May 2025 13:34:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH0du-0007Ba-9s
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:34:58 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0d4c8519-34b6-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 15:34:56 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5fff52493e0so5122070a12.3
 for ; Mon, 19 May 2025 06:34:56 -0700 (PDT)
Received: from [192.168.62.38] (server.hotelpassage.eu. [88.146.207.194])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d4f2f06sm5763735a12.9.2025.05.19.06.34.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 06:34: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" 
X-Inumbo-ID: 0d4c8519-34b6-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747661695; x=1748266495; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:from:to:cc:subject
         :date:message-id:reply-to;
        bh=G0o0PAMbFl5pa7ainzNmhCd/hGWpG0FUAue9Qou/Yw8=;
        b=Kv4By+aAjP2+LUpl7NYLK1qoAucMFUYeHpU2BAU/GmALzDgVcyJGhjdyq+Jz7HfsJC
         5/CkvEhlZXYlum4B3lSeKQCRHZbdWHSdSfj3KAZR3o/RC5He3cPmxm7Ll4CJTG2euZNO
         kRq1C4jFwdaOsVPpSSEYXXKSRr4J3qRGvRFvZpa7g+e8exKSR9vW9/D64linV/gmNB0D
         1Ap1HMjKQEGb65qcLV2Q7TbPdgIGNdFI9xPMr7rhtq7u3bwDklojaWbUQW08LmL098lu
         WeQS+TlQSR3Gsx0ozNBpB92dFBONFcogswzbb+nJRVAOITcQJqPrcfE2U4PH3BQTCQHf
         JKLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747661695; x=1748266495;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=G0o0PAMbFl5pa7ainzNmhCd/hGWpG0FUAue9Qou/Yw8=;
        b=Q2R5ws9drSXeOHjLvcwtpKgQkvKDTMY5jMyKB4PIi2NVK/U9MNvhg0cSoMI0HM/or6
         ilvPUbIuombgd3cQYPKhXWy/R6ip0GjUqqFieDB/dguw42V7aw8kLlrqCuS7y1XKCCBd
         PWkfg34HqDP26cOJ2k1xnVF0KxE5iKJycB335V0LIsESU4ovaNHzaJfccTLT8u+MMBwf
         xhVqcKWF2zcmo7t+/dbu1qkexy3iMYsd69C8P3BZtuSK4g8ob6NaMr2YxssXoA1x2kNT
         j1tw7nNEWMPnQyAJUyvHeG31cb5rcW6LklRbusJJBAadBEa/tGzGnq9lkZ7MIDh3Jrzx
         JZ2A==
X-Gm-Message-State: AOJu0YyvoYLWPG9lPK1rGcb2vX8wLuAx3VS2i3ZcN340d8Dk4I3Zqo1T
	zXeM7aTfPe+s/kg1YoD2BEDSTjXZTH3q9lpJGglWUwNAuATbOIPwWEvnDzP+sBjUTQ0=
X-Gm-Gg: ASbGnctTfPwpwU2BxUfA6LWedIIDyDOITrK2ymctAkfCrsMDagsgexSSChTwzwkyv0J
	qQGhsPJhp8XEBlipw4n+kXDYOK+A9FVY50CwQ/lwwjDI+6zaevzHSWC5XdYzXlPi8LuQYhkAXgs
	YjBPez1gXFbj7AvDxJ5UL2/1f4PA1Rc6JU0oyMYEuW/X9b1y4dvK4boD9aNbEn1XNqOcGCTlVJD
	pGKg/Ttf/nTvPHVdQA/rQKBqLkeR0LHLuEQlSbGRZUZwnkI2Dlc2VHWQuW97w1pWPxuDeDohj9T
	YqUtnsz4ydgwlqcHVvAL89ymV4FnFO8m3QAPaqXUkfzq4g9deO/lJxfMewQONhz+rxlc38s5
X-Google-Smtp-Source: AGHT+IFlAqqVSi1s6mfWQh91o06qt/MPrzA/bJo2O7vvdNKtSjE5Un2SPH1l3uN7tb2q+l0J2r8tvw==
X-Received: by 2002:a05:6402:26cf:b0:601:8481:3268 with SMTP id 4fb4d7f45d1cf-60184813473mr9452638a12.25.1747661695454;
        Mon, 19 May 2025 06:34:55 -0700 (PDT)
Message-ID: 
Date: Mon, 19 May 2025 15:34:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/4] tools: remove support for running a guest with
 qemu-traditional
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
References: <20250429110636.30518-1-jgross@suse.com>
 <20250429110636.30518-3-jgross@suse.com> 
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------rmeP7maN8jl5VkgcndEh9nCs"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------rmeP7maN8jl5VkgcndEh9nCs
Content-Type: multipart/mixed; boundary="------------FmB8240Jkw8cF0nssYYO7hzp";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Message-ID: 
Subject: Re: [PATCH v3 2/4] tools: remove support for running a guest with
 qemu-traditional
References: <20250429110636.30518-1-jgross@suse.com>
 <20250429110636.30518-3-jgross@suse.com> 
In-Reply-To: 
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------FmB8240Jkw8cF0nssYYO7hzp
Content-Type: multipart/mixed; boundary="------------S5glhQFy8lNat0AgtftWkJJm"

--------------S5glhQFy8lNat0AgtftWkJJm
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTkuMDUuMjUgMTU6MzAsIEFudGhvbnkgUEVSQVJEIHdyb3RlOg0KPiBPbiBUdWUsIEFw
ciAyOSwgMjAyNSBhdCAwMTowNjozMlBNICswMjAwLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0K
Pj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYmFjcGkvbWtfZHNkdC5jIGIvdG9vbHMvbGliYWNw
aS9ta19kc2R0LmMNCj4+IGluZGV4IDM0ZjY3NTNmNjEuLjIyN2I1Y2VhZmIgMTAwNjQ0DQo+
PiAtLS0gYS90b29scy9saWJhY3BpL21rX2RzZHQuYw0KPj4gKysrIGIvdG9vbHMvbGliYWNw
aS9ta19kc2R0LmMNCj4+IEBAIC0xMDUsNyArODEsNyBAQCBpbnQgbWFpbihpbnQgYXJnYywg
Y2hhciAqKmFyZ3YpDQo+PiAgIHsNCj4+ICAgICAgIHVuc2lnbmVkIGludCBjcHUsIG1heF9j
cHVzOw0KPj4gICAjaWYgZGVmaW5lZChDT05GSUdfWDg2KQ0KPj4gLSAgICBkbV92ZXJzaW9u
IGRtX3ZlcnNpb24gPSBRRU1VX1hFTl9UUkFESVRJT05BTDsNCj4+ICsgICAgZG1fdmVyc2lv
biBkbV92ZXJzaW9uID0gUUVNVV9JTlZBTElEOw0KPj4gICAgICAgdW5zaWduZWQgaW50IHNs
b3QsIGRldiwgaW50eCwgbGluazsNCj4+ICAgDQo+PiAgICAgICBtYXhfY3B1cyA9IEhWTV9N
QVhfVkNQVVM7DQo+PiBAQCAtMTYwLDYgKzEzNCwxMSBAQCBpbnQgbWFpbihpbnQgYXJnYywg
Y2hhciAqKmFyZ3YpDQo+PiAgICAgICAgICAgfQ0KPj4gICAgICAgfQ0KPj4gICANCj4+ICsg
ICAgaWYgKGRtX3ZlcnNpb24gPT0gUUVNVV9JTlZBTElEKSB7DQo+IA0KPiBgZG1fdmVyc2lv
bmAgaXMgb25seSBhdmFpbGFibGUgaWYgQ09ORklHX1g4NiBpcyBkZWZpbmVkLCBzbyB0aGF0
IGRvZXNuJ3QNCj4gYnVpbGQgb24gQXJtLg0KPiANCj4+ICsgICAgICAgIGZwcmludGYoc3Rk
ZXJyLCAiLS1kbV92ZXJzaW9uIGlzIGEgbWFuZGF0b3J5IHBhcmFtZXRlci5cbiIpOw0KPj4g
KyAgICAgICAgcmV0dXJuIC0xOw0KPj4gKyAgICB9DQo+PiArDQo+PiAgICAgICAvKioqKiBE
U0RUIERlZmluaXRpb25CbG9jayBzdGFydCAqKioqLw0KPj4gICAgICAgLyogKHdlIGFwcGVu
ZCB0byBleGlzdGluZyBEU0RUIGRlZmluaXRpb24gYmxvY2spICovDQo+PiAgICAgICBpbmRl
bnRfbGV2ZWwrKzsNCj4+IGRpZmYgLS1naXQgYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX2Rt
LmMgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX2RtLmMNCj4+IGluZGV4IDQ2Mjc1NjRjMGQu
LjY0NTExOWI2NWEgMTAwNjQ0DQo+PiAtLS0gYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX2Rt
LmMNCj4+ICsrKyBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfZG0uYw0KPj4gQEAgLTI0NjMs
MTYgKzIxODksMTUgQEAgdm9pZCBsaWJ4bF9fc3Bhd25fc3R1Yl9kbShsaWJ4bF9fZWdjICpl
Z2MsIGxpYnhsX19zdHViX2RtX3NwYXduX3N0YXRlICpzZHNzKQ0KPj4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAiJXMiLA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4
bF9iaW9zX3R5cGVfdG9fc3RyaW5nKGd1ZXN0X2NvbmZpZy0+Yl9pbmZvLnUuaHZtLmJpb3Mp
KTsNCj4+ICAgICAgIH0NCj4+IC0gICAgLyogRGlzYWJsZSByZWxvY2F0aW5nIG1lbW9yeSB0
byBtYWtlIHRoZSBNTUlPIGhvbGUgbGFyZ2VyDQo+PiAtICAgICAqIHVubGVzcyB3ZSdyZSBy
dW5uaW5nIHFlbXUtdHJhZGl0aW9uYWwgYW5kIHZOVU1BIGlzIG5vdA0KPj4gLSAgICAgKiBj
b25maWd1cmVkLiAqLw0KPj4gKw0KPj4gKyAgICAvKg0KPj4gKyAgICAgKiBEaXNhYmxlIHJl
bG9jYXRpbmcgbWVtb3J5LCBoYXZpbmcgYSBsYWdlciBNTUlPIGhvbGUgaXNuJ3QNCj4gDQo+
IEkgdGhpbmsgeW91IHdhbnRlZCB0byB3cml0ZSAibGFyZ2VyIiBhbmQgbm90ICJsYWdlciIu
DQo+IA0KPj4gKyAgICAgKiBpbXBsZW1lbnRlZCB3aXRoIHFlbXUteGVuLg0KPj4gKyAgICAg
Ki8NCj4+ICAgICAgIGxpYnhsX194c19wcmludGYoZ2MsIFhCVF9OVUxMLA0KPj4gICAgICAg
ICAgICAgICAgICAgICAgICBsaWJ4bF9fc3ByaW50ZihnYywgIiVzL2h2bWxvYWRlci9hbGxv
dy1tZW1vcnktcmVsb2NhdGUiLA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBsaWJ4bF9feHNfZ2V0X2RvbXBhdGgoZ2MsIGd1ZXN0X2RvbWlkKSksDQo+PiAt
ICAgICAgICAgICAgICAgICAgICAgIiVkIiwNCj4+IC0gICAgICAgICAgICAgICAgICAgICBn
dWVzdF9jb25maWctPmJfaW5mby5kZXZpY2VfbW9kZWxfdmVyc2lvbg0KPj4gLSAgICAgICAg
ICAgICAgICAgICAgICAgID09IExJQlhMX0RFVklDRV9NT0RFTF9WRVJTSU9OX1FFTVVfWEVO
X1RSQURJVElPTkFMICYmDQo+PiAtICAgICAgICAgICAgICAgICAgICAgIWxpYnhsX192bnVt
YV9jb25maWd1cmVkKCZndWVzdF9jb25maWctPmJfaW5mbykpOw0KPj4gKyAgICAgICAgICAg
ICAgICAgICAgICIwIik7DQo+PiAgICAgICByZXQgPSB4Y19kb21haW5fc2V0X3RhcmdldChj
dHgtPnhjaCwgZG1fZG9taWQsIGd1ZXN0X2RvbWlkKTsNCj4+ICAgICAgIGlmIChyZXQ8MCkg
ew0KPj4gICAgICAgICAgIExPR0VEKEVSUk9SLCBndWVzdF9kb21pZCwgInNldHRpbmcgdGFy
Z2V0IGRvbWFpbiAlZCAtPiAlZCIsDQo+PiBAQCAtMzE5NiwyNiArMjkxNywxOSBAQCBzdGF0
aWMgdm9pZCBkZXZpY2VfbW9kZWxfbGF1bmNoKGxpYnhsX19lZ2MgKmVnYywNCj4+ICAgICAg
ICAgICBsaWJ4bF9feHNfcHJpbnRmKGdjLCBYQlRfTlVMTCwNCj4+ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIEdDU1BSSU5URigiJXMvaHZtbG9hZGVyL2Jpb3MiLCBwYXRoKSwNCj4+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICIlcyIsIGxpYnhsX2Jpb3NfdHlwZV90b19z
dHJpbmcoYl9pbmZvLT51Lmh2bS5iaW9zKSk7DQo+PiAtICAgICAgICAvKiBEaXNhYmxlIHJl
bG9jYXRpbmcgbWVtb3J5IHRvIG1ha2UgdGhlIE1NSU8gaG9sZSBsYXJnZXINCj4+IC0gICAg
ICAgICAqIHVubGVzcyB3ZSdyZSBydW5uaW5nIHFlbXUtdHJhZGl0aW9uYWwgYW5kIHZOVU1B
IGlzIG5vdA0KPj4gLSAgICAgICAgICogY29uZmlndXJlZC4gKi8NCj4+ICsgICAgICAgIC8q
DQo+PiArICAgICAgICAgKiBEaXNhYmxlIHJlbG9jYXRpbmcgbWVtb3J5LCBoYXZpbmcgYSBs
YWdlciBNTUlPIGhvbGUgaXNuJ3QNCj4gDQo+IEhlcmUgdG9vLCBJIHRoaW5rIHlvdSB3YW50
ZWQgdG8gd3JpdGUgImxhcmdlciIgYW5kIG5vdCAibGFnZXIiLg0KPiANCj4+ICsgICAgICAg
ICAqIGltcGxlbWVudGVkIHdpdGggcWVtdS14ZW4uDQo+PiArICAgICAgICAgKi8NCj4+ICAg
ICAgICAgICBsaWJ4bF9feHNfcHJpbnRmKGdjLCBYQlRfTlVMTCwNCj4+ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIEdDU1BSSU5URigiJXMvaHZtbG9hZGVyL2FsbG93LW1lbW9yeS1y
ZWxvY2F0ZSIsIHBhdGgpLA0KPj4gLSAgICAgICAgICAgICAgICAgICAgICAgICAiJWQiLA0K
Pj4gLSAgICAgICAgICAgICAgICAgICAgICAgICBiX2luZm8tPmRldmljZV9tb2RlbF92ZXJz
aW9uPT1MSUJYTF9ERVZJQ0VfTU9ERUxfVkVSU0lPTl9RRU1VX1hFTl9UUkFESVRJT05BTCAm
Jg0KPj4gLSAgICAgICAgICAgICAgICAgICAgICAgICAhbGlieGxfX3ZudW1hX2NvbmZpZ3Vy
ZWQoYl9pbmZvKSk7DQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICIwIik7DQo+PiAg
ICAgICAgICAgZnJlZShwYXRoKTsNCj4+ICAgICAgIH0NCj4gDQo+IEFuZCB3aXRoIHRob3Nl
IGZpeGVkOiBSZXZpZXdlZC1ieTogQW50aG9ueSBQRVJBUkQgPGFudGhvbnkucGVyYXJkQHZh
dGVzLnRlY2g+DQo+IEkgZ3Vlc3MgSSBjYW4gZml4ZWQgdGhvc2Ugb24gY29tbWl0IGlmIHRo
YXQncyBmaW5lIGJ5IHlvdT8NCg0KT2YgY291cnNlIGl0IGlzLg0KDQpUaGFua3MsDQoNCg0K
SnVlcmdlbg0K
--------------S5glhQFy8lNat0AgtftWkJJm
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-----

--------------S5glhQFy8lNat0AgtftWkJJm--

--------------FmB8240Jkw8cF0nssYYO7hzp--

--------------rmeP7maN8jl5VkgcndEh9nCs
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/Ey8FAmgrM34FAwAAAAAACgkQsN6d1ii/Ey/2
4AgAil9CKdI/z4oOVicp6G44BkLCsXhWeVm1h2z/iL1hGVaQ5OKDrwJCYIrk86qJBsPBW1/+tQoQ
fqYqDHs0wS3N0ixyi/FBQoMTWFRUPpPYdGs5mlM6uDp56H/qw1/YJ2h30hCZWD9ZXLohYiPCrKeG
bfDchT3Zv+zowG92I+0dqgM6Ullrmo3Kn2qRaqT4hN4WcpsYLvL9HnJVHNS2OygcY5LE+HejYNO1
mVt8iNWB+hk5vQdpG2s4jMuTrmiUUwpjjYKj7+zBCrZWgpL0O5yikvWjHDZuiPCCcTuTmfAwJGLi
8LNM0sVvq/+q8j2uWF9XZ0p6sM+0SjfQ4U7BV/BgXw==
=LJ0C
-----END PGP SIGNATURE-----

--------------rmeP7maN8jl5VkgcndEh9nCs--


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:43:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:43:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989854.1373810 (Exim 4.92)
	(envelope-from )
	id 1uH0mR-0000dd-Nh; Mon, 19 May 2025 13:43:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989854.1373810; Mon, 19 May 2025 13:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH0mR-0000dW-L1; Mon, 19 May 2025 13:43:47 +0000
Received: by outflank-mailman (input) for mailman id 989854;
 Mon, 19 May 2025 13:43:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH0mP-0000dQ-Cj
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:43:46 +0000
Received: from 5.mo584.mail-out.ovh.net (5.mo584.mail-out.ovh.net
 [188.165.44.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 47de116a-34b7-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 15:43:44 +0200 (CEST)
Received: from director8.ghost.mail-out.ovh.net (unknown [10.109.148.103])
 by mo584.mail-out.ovh.net (Postfix) with ESMTP id 4b1Jmv2wv5z1WFX
 for ; Mon, 19 May 2025 13:43:43 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-jlhst (unknown [10.110.96.141])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 28D541FE78;
 Mon, 19 May 2025 13:43:41 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.107])
 by ghost-submission-5b5ff79f4f-jlhst with ESMTPSA
 id HNuoAI01K2gX0wAA+5S5jQ
 (envelope-from ); Mon, 19 May 2025 13: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" 
X-Inumbo-ID: 47de116a-34b7-11f0-a2fa-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-107S00143373b8b-0648-41e1-bff3-41c18edd9b75,
                    FE7BE141BF42593818D4E9FBE246C5489A14F897) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Mon, 19 May 2025 16:43:37 +0300
From: Sergii Dmytruk 
To: Rich Persaud 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org,
	"Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Lukasz Hawrylko ,
	Mateusz =?iso-8859-1?Q?M=F3wka?= ,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
Message-ID: 
References: 
 <29FDCB46-CA92-4A30-B96C-3851414902EF@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <29FDCB46-CA92-4A30-B96C-3851414902EF@gmail.com>
X-Ovh-Tracer-Id: 3859303408682120348
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdefvdduheefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpedtgfeuudevuefgtdejffelgfefvddtgfeffeeuhfefvdefvdfftdfhtedviefhkeenucffohhmrghinhepihhnthgvlhdrtghomhenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekgedrvddvuddpfeejrdehledrudegvddruddtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkeegmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=TYHtPGPtfed8FBcL1Nga6Um7NXyWctjrCYFBVDWqkQw=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1747662223; v=1;
 b=N0708t/jKX5YspetJPdyWon3mS0wJEM/XWDrWUyw1VEQLy9s6F6BStdG5BLBDcC+JycPjFzP
 Qzj1oFx/nldbS87Zhu7vjWsNQ3GU+bBV3KCMjPg1a1LpWuW08KM9/Gwv5oSsFtUJNhhx4euos+g
 954BBLPse78L076EOLLapsW0Ei5D9ZIe0vaEKmucZ1Gkea/kNwOh+LR1QaNVORq8LlfaTIsLJ93
 Dn6BsAa4KbTNyXW4QcgS7WWXtLBfI7XZoqdtx7MR1vog2zmI/R3tFT4nZAR8Ok1Qkk4fpiAcBps
 KjQFjAbLFms4zC+jnqP0MOcsTj03IK5jPsEUdIfTv2t2g==

On Sun, May 18, 2025 at 07:31:49PM -0400, Rich Persaud wrote:
> If there's no stable URL for the TXT spec, can we mirror the relevant
> doc(s) somewhere in the Xen docs tree? A trusted archive of the spec
> for trusted execution.
>
> Rich

By "unversioned link to Software Development Guide" I meant
https://www.intel.com/content/www/us/en/content-details/315168/
which always provides the latest version.

Regards


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:52:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:52:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989861.1373820 (Exim 4.92)
	(envelope-from )
	id 1uH0uw-0002PT-Fc; Mon, 19 May 2025 13:52:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989861.1373820; Mon, 19 May 2025 13:52:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH0uw-0002PM-D3; Mon, 19 May 2025 13:52:34 +0000
Received: by outflank-mailman (input) for mailman id 989861;
 Mon, 19 May 2025 13:52:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH0uu-0002PG-T5
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:52:32 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 81edd9b2-34b8-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 15:52:30 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43cfe574976so30478955e9.1
 for ; Mon, 19 May 2025 06:52:30 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442f3368fbasm210852615e9.2.2025.05.19.06.52.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 19 May 2025 06:52: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" 
X-Inumbo-ID: 81edd9b2-34b8-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747662750; x=1748267550; 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;
        bh=Dzfe1YMWT6hqd8weaS8C4B1kY+AHXFbeCn3sBPzhl24=;
        b=rdjHa4p3fiJSB4z8PTiv9fIbn5Y2DsWhx6h4OnzaHlJ2T2k77cbmPYRIC/1fZjPwjz
         sqykPa85ztQrrtRL7R0Ii0KU6FI5kCngdF4ZgTk06IThDypiegdIBs3PD0RcwHgqWYtC
         AJ6s75NI/8TBmpX5L8k7zyjMQS3+DUTTIf+fo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747662750; x=1748267550;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Dzfe1YMWT6hqd8weaS8C4B1kY+AHXFbeCn3sBPzhl24=;
        b=bKNTeFKQzwDw/kJW6HJnyomdyEOJgrXxH2VAtgx0I7YVmqxi731P5anDnjbrg4SUue
         OttKKvlyFM1RDwZsfEDyEXhSfdAhQKKW55rnrn7z5tRxKQrS4FCJzwo+1sn4Yqw7fHX8
         x+GXWbm+QIikl6yn6hY21tCduhWPp9nc4W1FehDRF3BFvPZ5DPUuQKHeGPgMsWPd1Q7x
         8c0XHRsfelTNZb8ZkeZZNRpsAjt+vqFN5figNhjq6kDoI864EvuC8MN+4COHZ5Lro36h
         oHqwwdOPTdMbHc8Yjyz/AzWUPTvLrI+tma7rqSY3XUbANRMgB0/aIUmQ08dzmoEzbF+I
         Myxg==
X-Gm-Message-State: AOJu0YxIVds1NE5Ns/foMKJ13OWjYh61+NXbSR4N78jnHQy7ZD1R/bka
	OS2exWFMyA50TQQPW+Y8BvQ6fZP9y6EgPrfIz6coJQ1eVGdsfUz8MlFbamSlOTh2OOqhdxvTelZ
	9QnWh
X-Gm-Gg: ASbGncupxZDG/+087DX0bHDflhkUrKHXoG+Izv+y4mQGjX586siFppPopzUoql7ukcZ
	3hV6vGM7+58sztpEmDprnyhsAw0ViQfDFVjkSOcqNgIMl7dU47k5/fu+qvW8ZETZPNAu4bzlcin
	KUDQLw3cmkEJC63yoxv1EMexx279MCu6XuMbOwRlpfk2sikHjzzPzBgR2NEkRWxtiWL+gmy2l0W
	C+AO+pzB64FS2c7BN0oaStsKKnY5JpT8HiR5d0P5ETBsiEAm/LaHXX+q79yvECLyYRKQ7C0b8pN
	N8KUB1VoYRt1TXtKNHyDDXy0ghQWcEyfJizOKiMKXlDINwoTANfx4SuGs1J/iWT59y1Wz2X040Q
	PdRzM/cUX/BK8Pb9vml+eie28
X-Google-Smtp-Source: AGHT+IFqofJNsQtla3niG2JXRd5+LaEevX72HkVxExEwNGO26miJsJlNGtosIf7EEBl1DjxiDwNHyQ==
X-Received: by 2002:a05:600c:3e0a:b0:43c:e478:889 with SMTP id 5b1f17b1804b1-442fd5a2c09mr149640615e9.0.1747662750024;
        Mon, 19 May 2025 06:52:30 -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: Give compile.h header guards
Date: Mon, 19 May 2025 14:52:27 +0100
Message-Id: <20250519135227.27386-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

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/compile.h.in | 3 +++
 xen/tools/process-banner.sed | 5 +++++
 2 files changed, 8 insertions(+)

diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
index 3151d1e7d1bf..9206341ba692 100644
--- a/xen/include/xen/compile.h.in
+++ b/xen/include/xen/compile.h.in
@@ -1,3 +1,6 @@
+#ifndef XEN_COMPILE_H
+#define XEN_COMPILE_H
+
 #define XEN_COMPILE_DATE	"@@date@@"
 #define XEN_COMPILE_TIME	"@@time@@"
 #define XEN_COMPILE_BY		"@@whoami@@"
diff --git a/xen/tools/process-banner.sed b/xen/tools/process-banner.sed
index 56c76558bcd9..4cf3f9a1163a 100755
--- a/xen/tools/process-banner.sed
+++ b/xen/tools/process-banner.sed
@@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
 
 # Trailing \ on all but the final line.
 $!s_$_ \\_
+
+# Append closing header guard
+$a\
+\
+#endif /* XEN_COMPILE_H */

base-commit: 6fc02ebdd053856221f37ba5306232ac1575332d
prerequisite-patch-id: 7bc1c498ba2c9c4a4939a56a0006f820f47f2a66
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 19 13:55:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:55:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989868.1373832 (Exim 4.92)
	(envelope-from )
	id 1uH0xO-0002wC-TK; Mon, 19 May 2025 13:55:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989868.1373832; Mon, 19 May 2025 13: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 1uH0xO-0002w5-OP; Mon, 19 May 2025 13:55:06 +0000
Received: by outflank-mailman (input) for mailman id 989868;
 Mon, 19 May 2025 13:55:05 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uH0xN-0002vz-3T
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:55:05 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uH0xL-001O5D-36;
 Mon, 19 May 2025 13:55:03 +0000
Received: from lfbn-gre-1-199-136.w90-112.abo.wanadoo.fr ([90.112.161.136]
 helo=l14) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uH0xL-00FCsN-15;
 Mon, 19 May 2025 13:55: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=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=YXlEcEhzXUTW5ZgKvke4UWEYUlomDtLto/jSxmmNKYs=; b=p2GspbfAniWqoomm0zCqUVFOws
	cdaWRxJvdC1gPJ2zjxuspWQ3wlTK/2HXUXxc/f3ztn92yxI7I1uTMOprAntmt8t4Id7ExJ1NRf+1A
	4tl9igQd9luhN+ROMTodoS5jWX19UakO8rAgvMFaOclIVb/+EKf6+PEtLf4q+a5J9C9Y=;
Date: Mon, 19 May 2025 15:55:00 +0200
From: Anthony PERARD 
To: Juergen Gross 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	Oleksii Kurochko ,
	Community Manager ,
	Samuel Thibault 
Subject: Re: [PATCH v3 3/4] tools: remove qemu-traditional
Message-ID: 
References: <20250429110636.30518-1-jgross@suse.com>
 <20250429110636.30518-4-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250429110636.30518-4-jgross@suse.com>

On Tue, Apr 29, 2025 at 01:06:33PM +0200, Juergen Gross wrote:
> Remove qemu traditional from the tree.
> 
> Signed-off-by: Juergen Gross 
> Acked-by: Oleksii Kurochko  # CHANGELOG.md

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 19 13:56:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 13:56:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989875.1373841 (Exim 4.92)
	(envelope-from )
	id 1uH0ys-0003T0-4W; Mon, 19 May 2025 13:56:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989875.1373841; Mon, 19 May 2025 13:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH0ys-0003St-1g; Mon, 19 May 2025 13:56:38 +0000
Received: by outflank-mailman (input) for mailman id 989875;
 Mon, 19 May 2025 13:56:36 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uH0yq-0003Si-L6
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 13:56:36 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uH0yq-001O6b-1o;
 Mon, 19 May 2025 13:56:36 +0000
Received: from lfbn-gre-1-199-136.w90-112.abo.wanadoo.fr ([90.112.161.136]
 helo=l14) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uH0yq-00FEOP-03;
 Mon, 19 May 2025 13:56: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=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=6MS10jZqPYauidjKWX6F3N1C3atb24uqr7IIOmdt+1A=; b=zUdPuczIhKnT1JYM9aUVkoSMF8
	7Qp0K72yu2ZQodqvUZUvQXUfq3h2yw6hsMzGpHGmCEN+/ZUZWp661Zy4cGvzxTtEW9RVdGqhGlJDa
	Xvy/doCvkXefWGX073Xy+04RlF/f2zJiMY+koI0yvAMWL3HkkCsNVDYAjT4ntPdB3jHY=;
Date: Mon, 19 May 2025 15:56:33 +0200
From: Anthony PERARD 
To: Juergen Gross 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini 
Subject: Re: [PATCH v3 4/4] build: don't require full tools build for
 building stubdoms
Message-ID: 
References: <20250429110636.30518-1-jgross@suse.com>
 <20250429110636.30518-5-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250429110636.30518-5-jgross@suse.com>

On Tue, Apr 29, 2025 at 01:06:34PM +0200, Juergen Gross wrote:
> With the drop of qemu-traditional "make stubdom" no longer requires
> "make tools" to have finished.
> 
> It is enough to add "install-tools-public-headers" as a prereq of
> "install-stubdom".
> 
> Signed-off-by: Juergen Gross 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 19 14:07:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 14:07:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989883.1373851 (Exim 4.92)
	(envelope-from )
	id 1uH19S-0005IV-VR; Mon, 19 May 2025 14:07:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989883.1373851; Mon, 19 May 2025 14: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 1uH19S-0005IO-Sz; Mon, 19 May 2025 14:07:34 +0000
Received: by outflank-mailman (input) for mailman id 989883;
 Mon, 19 May 2025 14:07:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH19Q-0005IG-US
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 14:07:32 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9a5b2c89-34ba-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 16:07:30 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-43cfe63c592so48460085e9.2
 for ; Mon, 19 May 2025 07:07:30 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-442eb85a8f8sm126141505e9.0.2025.05.19.07.07.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 19 May 2025 07:07:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9a5b2c89-34ba-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747663650; x=1748268450; 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;
        bh=1k8nMQZQL4hONO9wT7+tWYlTJqUYvOSaiCyAXnp+mP4=;
        b=VTzGcrZ0C/9FXPwaeyip1e539taQ3zjf2senycsSjCp+53LlFJBGeNCl9m4bOjkxhB
         G6ZMPam99tLV59aKhFJj7EksnROqOO76PV6PIxajp3MKeKTj03uqZz54GqlvYh/yGsq0
         63Wgx768KYumWdLhO+4kScCI46Mm6dC5u3kWw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747663650; x=1748268450;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=1k8nMQZQL4hONO9wT7+tWYlTJqUYvOSaiCyAXnp+mP4=;
        b=gW79F89aJPXuXxQqUMZfG87L2oWUWVHtSXHiV5hnaGyYUUo/Swl/StuQHIycIU9q1v
         WGREogRpeM0Hacs+F6qcr5QLW2f0tvwO1Dkpa1f4z+GmJEai6zU10HE7AxtIxKpFHD54
         SoLuE3dm3Cd80qC84YkYBzWwYT+FcAogMCLmReYMiaZxeIeKStS4aAQtsweu3Tksg4Iz
         qm6SOiHwNiro+ebqaLCN8BkNQskzfx/p6VRsKgGZop7+GmhTE2cdszcxNzOpKV1zCVbc
         PKf4I3x8OOkWxHdnZ6U9ahHRwJtJ5dryUwGVR/lnBEzfnEtRX/Zko9P+zcjGbFXWtuHk
         LYwQ==
X-Gm-Message-State: AOJu0Yzpd37ZfRzWQ1dnO0KSWWih+PKFGl3eJHYslYmF9/19IgTXaIKh
	EiPjdOXd9nLrPnWAzV3lOB51ECT8Xo4CJjy+OSjk64/stL+bNeTDgVaaC2yneVt/lcNg3EavSlz
	cJxmt
X-Gm-Gg: ASbGncvhsX5mDPpjFtnxWIEtN+oIXZLsn0W9FTiRNIY98RktOwJcWtXtMgI9wdGhTsp
	zeg9ilXtcWmZ5sIwbiW1bszPN0inONsm81wqfp5YJS1J4oyQ9n/eneJdbx9pTsPsVUtRraJ9ZER
	bgx05QQC6l90KWqMmaSs5hpLiRnnWuNm1mGubGxENK6tgQLD7LOz1Ci8Qdh3tulcOgQCEcW3x++
	Lh1uNBG9Ct19F+SjLgVSnOzs8OclkAGV8XcHRLwp7qWs5bqRaYCWdla9XGaO7BDlwAf0qZ6f8G/
	ang1fQubhJkt5oONN3JOOfZR1OIWYtj2HChyGca4oroRJW3AfocvBW3Zul2cJ4DrwMcIoqrgIVl
	yQeAcX+lDS3vvy70j3P8ruO8FFGNw01FM1Ag=
X-Google-Smtp-Source: AGHT+IE6H6jQNmXrQFWxLpEsUCmXS+pAtcqY/yGfuXQWf5nBBPugmTP7rd2+zakIC9/f59Em/vSLJg==
X-Received: by 2002:a05:600c:3114:b0:439:6118:c188 with SMTP id 5b1f17b1804b1-442fd63c6f6mr113232705e9.19.1747663649916;
        Mon, 19 May 2025 07:07:29 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Stefano Stabellini ,
	"consulting @ bugseng . com" ,
	Nicola Vetrini 
Subject: [PATCH] CI/eclair: Remove ARM64 custom clean rules
Date: Mon, 19 May 2025 15:07:27 +0100
Message-Id: <20250519140727.28562-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Rules 5.3, 11.2 and 16.6 are already listed in clean_guidelines_common and
apply to all architectures.  There's no need for arm64 to give them a second
time.

Signed-off-by: Andrew Cooper 
---
CC: Stefano Stabellini 
CC: consulting@bugseng.com 
CC: Nicola Vetrini 

I've left the x86/arm split as-before so it's easier for those not familiar
with Eclair syntax to add per-arch configuruation.
---
 automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index 7e3095423b79..b95f07feb099 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -122,7 +122,7 @@ if(string_equal(target,"x86_64"),
 )
 
 if(string_equal(target,"arm64"),
-    service_selector({"additional_clean_guidelines","MC3A2.R5.3||MC3.R11.2||MC3A2.R16.6"})
+    service_selector({"additional_clean_guidelines","none()"})
 )
 
 -reports+={clean:added,"service(clean_guidelines_common||additional_clean_guidelines)"}

base-commit: 6fc02ebdd053856221f37ba5306232ac1575332d
prerequisite-patch-id: 7bc1c498ba2c9c4a4939a56a0006f820f47f2a66
prerequisite-patch-id: 8fcd84101ab012ed0aa427c30eca564c5ac10726
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 19 14:13:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 14:13:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989891.1373861 (Exim 4.92)
	(envelope-from )
	id 1uH1FM-00072U-Jj; Mon, 19 May 2025 14:13:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989891.1373861; Mon, 19 May 2025 14:13: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 1uH1FM-00072N-H4; Mon, 19 May 2025 14:13:40 +0000
Received: by outflank-mailman (input) for mailman id 989891;
 Mon, 19 May 2025 14:13:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH1FK-00072H-UH
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 14:13:39 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 738951c9-34bb-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 16:13:35 +0200 (CEST)
Received: from [192.168.1.16] (host-87-1-204-51.retail.telecomitalia.it
 [87.1.204.51]) (Authenticated sender: federico)
 by support.bugseng.com (Postfix) with ESMTPSA id 3DC594EE7C49;
 Mon, 19 May 2025 16:13: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" 
X-Inumbo-ID: 738951c9-34bb-11f0-b892-0df219b8e170
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=87.1.204.51
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1747664014;
	b=oQRwq/laYdRlV7m6fy1M+i8t0scIXiSc6TlkEbsBOS9s89iQdO9sfTMhFgIOdHEa2JnO
	 UXFRqVRAn4YfTWkKVXYeh/wLiEeZPqUmulgjoLULcRS9k40OdlFCTtqvblsG8cHRsJO+K
	 hfq8jsgryEx8fLYZ9iQQ/sO0k/2HIE83B4slJFkO9ajynV/RNgp2DUP7Ymv5mj+OwBUtT
	 g20MbYJuQEj+VHTh7H7cWK9P/HHxrcMO5+GUMSMPKhFHOlJ4bQ1MZ3D35b7Edj7NIklQG
	 6YK1M3CEP+sruZJQ6mFIFVnAXebpWcWzBHKpOn/soc1ZTXKPasJOKmZ+xx8tGvGTj5iJ5
	 t3e272f1z1pFCUvXsI4h6+NDKgc/m72MVm0N9waKtBdrdYAfq4WSbs6gCivYNi1PdFlpk
	 vn7W8VaW2ju3wUMkdCjDi5sVtZWX1p86PAinX/bPdSXymrTdvyCgi7/0WIIURb/ZM6i0u
	 rX4KdUHXUr93i0NoWdIsSKdYrB/EC8IyzFmh+WvEXWnTsUdUoqtWKmbe+cA4Li88rTNOx
	 EvHQhSu9DyGGMmKq0MuGabnQhFaN9ry10GrP6VjephZmE2o2GAva0775l/uYQSFIa9eKu
	 Nk9b5dAMhRigRXLK1aY7QV7xhs9utrEhz6mVIasUWIG78MZQ0idYvMJAKy5Snzk=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1747664014;
	h=DKIM-Signature:Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:
	 References:Content-Language:From:Organization:In-Reply-To:
	 Content-Type:Content-Transfer-Encoding;
	bh=6GxuCxcKplKFny5zoZVzpfir6eib2sdPYIN9j+99JMg=;
	b=duxnpCOUjHoTmWFJ2czUvLOF1nUxFcm0Bwwg0GpWXYLsOKXOEa9rFNh9SZP0QBzr7UiL
	 qXWsjPr5L4B64IBD6tOft6oMoRuRSlSYAzHh7x/rf+7f3OkFMUdhiTVIRrOByQAkN7OxX
	 2cp6QUUjGlzFC+ppQqxGL01C2mdjAxvRe9cab1wfLGdYquOGiJJ3Q+ufG+OXTA/I0bKAW
	 b4SMW1Op6cwEvzNQN0DO+Do56PIZWIRXS8SbRxW19almQK8pgZvGnCvbZ4IjYE8xA3TEB
	 txYzwzdu1qlYow+wkJuf/3GjqciQ40GtDf+AvZhRnrmY2UCTA3LL7Rpi+/2mbbEVoXYnY
	 nZ+HEE48YPQMHhtCtYKC6YzSgmpW9yoyteTkckanporXkhiZbLeTCknDbh5HaN4TeeITJ
	 BECXaUeTyxuq5iNlK1zcFyfG7/YkFgdmWYrTkgLlZ9OPo/Dav2UlwkhKVBVhvo14YSbFI
	 GY9kt7adQQcMm6p2MCrBR4euD0mxZnS0HzJVBe4znVEe+y0tAZ/q4pGD2n9jzyxkG8LPA
	 bipqwWCbzhbPexabsBsR6WIxhmB+yeZDar12OiYYNEK/jjl5ohBeaOVNOne1GGYLWmqTt
	 KLeStcndXYSmIZZ0VejFBpYuv3Qh7wjNk3nY3o5PKe6B7c+uw1h+nrNZWkJ66R0=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=87.1.204.51
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1747664014; bh=+vRqquC7f5Vtsb58CFFeIBEBIcyFoTsEu1U6Uxa/VWI=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=ynF6CUJe9Yt/pDn85ayEyI99jNM2kqVWgdKm5SqOF3RGOcBzokJAgN1lauHjW/pM7
	 0AMOjKplTiaLrfFDDuMzYroFW0SiIvnyGcKeLKPpWmnENYzV+UuLVrmL0JpAjJf70N
	 jvYgHfM49cTTyB0rSaATX7X5Yt8s3MM4vZEbbAjpKzo+2sFu/PAhMjO65yoZsSEz85
	 du6elgsZUM0+5BECxIUdQi9D62lip8RZBTRNRoPAEodjb9JZfhDEjYQwcoFBVm1JBu
	 ddKcFVwtSfC0pDFOJzuIbq2vMwI8KCLsonH56mHRWxC9uyCwUW7Mp1KA+APQb04vF3
	 RtadadF8M3aYQ==
Message-ID: 
Date: Mon, 19 May 2025 16:13:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/6] automation/eclair: update configuration of D4.10
To: Andrew Cooper ,
 Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org,
 roger.pau@citrix.com, sstabellini@kernel.org, bertrand.marquis@arm.com
References: 
 <20250516232130.835779-6-stefano.stabellini@amd.com>
 <5c2aa885-8877-4708-90cc-d65a76b729b3@citrix.com>
Content-Language: en-US, it
From: Federico Serafini 
Organization: BUGSENG
In-Reply-To: <5c2aa885-8877-4708-90cc-d65a76b729b3@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 17/05/25 01:57, Andrew Cooper wrote:
> 
>> +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-2))"}
>>   -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3))"}
> 
> These seem to only differ by the begin-$N.  Why doesn't the regex work
> in both cases?

"begin-N" expresses the position of a single line, not a range.
For example, begin-2 means "two lines before the first reported area"
and deviates:

https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/hardware/xen/ECLAIR_normal/staging/X86_64/10063944407/PROJECT.ecd;/sources/xen/include/xen/hypercall-defs.h.html#R174_1{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":false,"selector":{"enabled":true,"negated":false,"kind":2,"children":[]}}}

If you prefer, I think we can use ranges and merge the two
configurations.

-- 
Federico Serafini, MSc
Software Engineer, BUGSENG (https://bugseng.com)
LinkedIn: https://linkedin.com/in/federico-serafini



From xen-devel-bounces@lists.xenproject.org Mon May 19 14:33:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 14:33:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989900.1373870 (Exim 4.92)
	(envelope-from )
	id 1uH1Yn-0001kz-5c; Mon, 19 May 2025 14:33:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989900.1373870; Mon, 19 May 2025 14:33: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 1uH1Yn-0001ks-2i; Mon, 19 May 2025 14:33:45 +0000
Received: by outflank-mailman (input) for mailman id 989900;
 Mon, 19 May 2025 14:33:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH1Ym-0001km-4c
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 14:33:44 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4391faf1-34be-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 16:33:43 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43cf06eabdaso43595065e9.2
 for ; Mon, 19 May 2025 07:33:43 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442fd516a51sm141473145e9.24.2025.05.19.07.33.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 19 May 2025 07:33: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" 
X-Inumbo-ID: 4391faf1-34be-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747665222; x=1748270022; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=ox7Dbgv61pwuI8/vrKMBMI3PAamFjqTf5QkFXQ6JKvo=;
        b=ve/fuCl/oBnEY0HQPlOr1I5h96PI8elD2JqvToBUFaSPKG5aWkDeC0qcDYRIleY+I2
         R5x/Zt6DFbT+20RLn9UXPcJfbBJulOntUu3uAk249Faj26+sORGGh/23LVFp+NJkLfoE
         Yge9ex70bq4rr2ds183feId4Pwj4lBAM7Zfhg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747665222; x=1748270022;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ox7Dbgv61pwuI8/vrKMBMI3PAamFjqTf5QkFXQ6JKvo=;
        b=KZvhcpMqfBmwUxdXk30r5UZc32z/ogN0hXJW7DfiK4FQxsGhsze5NuanLVYbzzmwxD
         ph0O+oMmfrc0eP7flu37X2ZmrYVmkr6R2w4qow7+P/l0a/G/dsykzitneo7M6dFiFxY1
         hru1KpGkyx8XLma9JZ+6SK0rVjiY9V3piZblCHY1Ilz+KuL0cN3iXqQ7rJ6M+rcf3iNU
         PVd4BD0aZi5xRyjhDAQ+R0n6I6z4+YwZIcZxOYVp+0ckoxYNjXR7fFLjiwSsndhoJgNb
         MNbHBXgicZ+gfmb6rOg1og6uLXGB39OkQxzeHlsm047NZnPXpy2SAtECusN+v2PfQsJN
         VM+g==
X-Forwarded-Encrypted: i=1; AJvYcCV9fjz+w87sMKlWBnLgpWxAr+pNtJ+5QJjeXxxzBfWe5r8qjQkpe6v2Ipb4ab0ojjz0LCh7VnCfLSo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwaHc3CgqeYawNaRcLoVypCS3qXQsLKD8nlqZzXuuHroBcqOkaF
	mChwEKTDA1wpM4tgH8jazBF7Nk5cqwOIQamfiSzxA2HzaeXArHtPpHwDvLRV/SRzu0E=
X-Gm-Gg: ASbGncsKNHfeSd3rcOPt3fC7eFGdPR325USJSfdmXSi0wRR7xORFqqO+2Yo+AGeDvHM
	XOGJujZQqTJMc6JzUbtfUXd8h8ff5gJ7wGiOEH3YhkWyifXmnI+zfCYi2NrwfDNgHcGfNjSAXya
	GgMyZNMVNE3afNhzKC9TJF7cMi2bKtoCbP+f0xkJbIal+EHLMegbHx0jJ+4SMFTiKcZ/fI+cbxL
	EppYG/dP+GxG39j4RIhSeFD83+fUyWvv0YRa/LSyRMhqmsflIKgxds3fS2ctah9uwuGisaKMtnR
	G0TR8gTRJ63CYDtk/agtI3MwJNbflWDtGQpoV5jwJeOwQDIiTyAFZbNufFao5DPN1R1ipouPkiK
	ON1IS31PfjRO67kEjiPnwareqNrqCqQ==
X-Google-Smtp-Source: AGHT+IGpuQxXCUxcmduBa1eJXKGRQpQB10vVFjKfOzMj9Klq1vO4FbSRRH9KvYRVuThpimM3zVq60A==
X-Received: by 2002:a05:600c:c059:20b0:43c:fb95:c752 with SMTP id 5b1f17b1804b1-442ffc60edemr69596105e9.3.1747665222613;
        Mon, 19 May 2025 07:33:42 -0700 (PDT)
Date: Mon, 19 May 2025 16:33:41 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Oleksii Kurochko ,
	Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 6/6] x86/hvm: reduce the need to flush caches in
 memory_type_changed()
Message-ID: 
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-7-roger.pau@citrix.com>
 
 
 <558c7ec2-77ea-42e6-8568-af8b74e19c88@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <558c7ec2-77ea-42e6-8568-af8b74e19c88@suse.com>

On Mon, May 19, 2025 at 03:22:32PM +0200, Jan Beulich wrote:
> On 19.05.2025 13:08, Roger Pau Monné wrote:
> > On Sun, May 18, 2025 at 01:44:49PM +0200, Jan Beulich wrote:
> >> On 16.05.2025 11:45, Roger Pau Monne wrote:
> >>> Not sure whether this attempt to reduce cache flushing should get some
> >>> mention in the CHANGELOG.
> >>
> >> Err on the side of adding an entry there?
> > 
> > Oleksii would you be fine with me adding:
> > 
> > diff --git a/CHANGELOG.md b/CHANGELOG.md
> > index 1ea06524db20..fa971cd9e6ee 100644
> > --- a/CHANGELOG.md
> > +++ b/CHANGELOG.md
> > @@ -11,6 +11,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
> >     - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
> >     - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
> >   - Linux based device model stubdomains are now fully supported.
> > + - On x86:
> > +   - Restrict the cache flushing done in memory_type_changed() to improve
> > +     performance.
> 
> Maybe better to mention function names here, saying "after a memory type change
> by a guest" instead?

It's not just "after a memory type change by a guest", since
memory_type_changed() is also used for toolstack operations like
io{mem,ports}_{permit,deny}_access(), that strictly speaking are not
memory type changes, neither are done by the guest itself.  I could
reword to:

   - Restrict the cache flushing done as a result of guest physical
     memory map manipulations and memory type changes.

Does that sound better?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon May 19 15:15:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:15:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989925.1373881 (Exim 4.92)
	(envelope-from )
	id 1uH2Cn-0007LG-AL; Mon, 19 May 2025 15:15:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989925.1373881; Mon, 19 May 2025 15: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 1uH2Cn-0007L9-7e; Mon, 19 May 2025 15:15:05 +0000
Received: by outflank-mailman (input) for mailman id 989925;
 Mon, 19 May 2025 15:15:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2Cl-0007L3-5v
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:15:03 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 08801f11-34c4-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 17:15:01 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 787C14EE7C57;
 Mon, 19 May 2025 17:15:00 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 08801f11-34c4-11f0-a2fa-13f23c93f187
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=1747667700;
	b=r7OdQw9WvJj46nDDCjFbjrjiDTxKJ7EBON5dm2ClweIrNUiml7nhDuRYtiMSV/69ZGir
	 RAD+kbIfSekcIPlt8wBJhIQFo7+5KMH6Pzi0ciJxUJz5LQ8yCJjaultYHJtoBpTL/WKQY
	 t073dSLjc/0p3KJIXp/H5zwKBTAwQRpsi5zvcGd4eLM2yGczhVCnjr0zSKbHg7uniLzRF
	 4tWcob4wkvHl02I3c8e0Q3lcTvIgSz40wvq3jjbFQHLO6eQGJqX7kSISlRes2aoLC5XTs
	 MkXetmLio3ifJJI5Ai5hWLRUPMLWf6GMQ9ejdIQ7BB5ABazmNKzdC0AyJtBvDRwj1smQO
	 TWoutxAU7Uorc5MveheRNvXmtLCQAMUU/IN858MrkMyhzw1edEyYtZsYkyKl2D44a54jM
	 GWUEiD/qD+/uGlQIqC3GAas2UahxT4VB0CS/Gm0a0KXQV5XzXCBMk+D+dpS5pUtmZjXXO
	 tUkDuEWiuLPmBtfYs6PAMLz8pFNFThUpYq0EyqTjQr/Jx2pGhLouhWlts4A2va/uTpwvr
	 8de8pM5yV50BI2Qrw2MPCXPKJihJV2ptZztC+1rLXvb/H9B+99YOvoGcwhfTG3cjRF5sv
	 Rc0PIDATUHkZst2kY3jSM0xEPw9tKqZBvX5zfwkq3ntGG1cEWNVZX91I6jYqKWQ=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1747667700;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=qVzn3AOUy75+D8+1BCusQ2C+wmjsH38vyex5rXrAK4w=;
	b=SQ5MzuXl4h7Syrayu0zWZVOmRKMRhKaZ0zgmxLTx3XrOmFnCYv99KHd1HpPaF8KlT/ei
	 FvHCZx3A/isCrBSA7Z24FBt67tjrNqO+RjMCg94n/zAvmH1vPBn004dAiMpmyDsWd1ItI
	 w0PUTg3ZxBBupFHcSByykHxT9nCdzm4UYPzT7KfjnaXc0hptYv/KUUVkbuCPNJNoquh6q
	 BljqNlNfbiBJqAbrxC+i7A5xc1CgC9u6V6GyJlzD6w3Tzk1o+Fweo8PFnjDIBPArOAfH0
	 0z9+MbqPnYPsxhyaNpPZBhXGUeF5YOwTyBWQfsQDyz1BUqx7Tg55+vIgfHlYI1zuHIpFW
	 66bcUYgcD+ndScyQLgBRThUEkuYZYowxHLMqMMohIy66Lkybl3PEwhJsX6GP5m+x+s3wz
	 epLUCmZXGcN7oGOLah+iN5FjHdE50n0ApfPTdBWJL2JCi8nqWCn71tlq3mzQriwonCmcO
	 7zqYVTrLlbONc00JiorEcg1q6t3kSu7udt/IOw0J7qMfhqbisUhD9Uc6ozxgHz3kQKLX1
	 xL9GCGKa0ev3CFbdGhUZ1UQrXjjwJ3vzhXxyxdlxfK7bXs/xgZFr1jExjviQkKO51VWoS
	 dQsIJZfLbxhq75uTfpEEZpYSLLt8gz8uHeNEle5DWR8Xc1tZLOTVJsT0T94poMk=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1747667700; bh=feJXjqyqU3ntfNDa8kJF+mxgPRRU6ZYDyK/9cg/8egc=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=Ap7nZUJgoVVpzsAN/LtnbsOsozOzWxNP9aHAbs8p7V30a8kwT46xOVnAqCukAvS1l
	 LWyUT1Cg8Qm04LF2UkNnfabgZf+2zQvc3pObcEeoASKdM3G12z54EzzAg6fbuLVi4H
	 6rnFdl5X0YSUo+9vzGG/4Kr7cI3ScMFLZeHQqM5vNndIi4goY6hXPdYoGhoHu8Mqen
	 uOpfk88QjJwgK+Ka8Jjuqx37WcQLZRMr5qMp3f6BFHh7k8pfjGq2+GWG5B+6YlHn3e
	 pjfkQcFyzpWzLnyIGz7qg+jNiRD4abuz557ZZeSA3gTiAy3HPy597HV6Z+/UmiwPXq
	 83e4f5ml+n2HA==
MIME-Version: 1.0
Date: Mon, 19 May 2025 17:15:00 +0200
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: Xen-devel , Stefano Stabellini
 , "consulting @ bugseng . com"
 
Subject: Re: [PATCH] CI/eclair: Remove ARM64 custom clean rules
In-Reply-To: <20250519140727.28562-1-andrew.cooper3@citrix.com>
References: <20250519140727.28562-1-andrew.cooper3@citrix.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

On 2025-05-19 16:07, Andrew Cooper wrote:
> Rules 5.3, 11.2 and 16.6 are already listed in clean_guidelines_common 
> and
> apply to all architectures.  There's no need for arm64 to give them a 
> second
> time.
> 

Thanks.

> Signed-off-by: Andrew Cooper 
Reviewed-by: Nicola Vetrini 

> ---
> CC: Stefano Stabellini 
> CC: consulting@bugseng.com 
> CC: Nicola Vetrini 
> 
> I've left the x86/arm split as-before so it's easier for those not 
> familiar
> with Eclair syntax to add per-arch configuruation.
> ---
>  automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl 
> b/automation/eclair_analysis/ECLAIR/tagging.ecl
> index 7e3095423b79..b95f07feb099 100644
> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> @@ -122,7 +122,7 @@ if(string_equal(target,"x86_64"),
>  )
> 
>  if(string_equal(target,"arm64"),
> -    
> service_selector({"additional_clean_guidelines","MC3A2.R5.3||MC3.R11.2||MC3A2.R16.6"})
> +    service_selector({"additional_clean_guidelines","none()"})
>  )
> 
>  
> -reports+={clean:added,"service(clean_guidelines_common||additional_clean_guidelines)"}
> 
> base-commit: 6fc02ebdd053856221f37ba5306232ac1575332d
> prerequisite-patch-id: 7bc1c498ba2c9c4a4939a56a0006f820f47f2a66
> prerequisite-patch-id: 8fcd84101ab012ed0aa427c30eca564c5ac10726

-- 
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 May 19 15:19:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:19:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989938.1373890 (Exim 4.92)
	(envelope-from )
	id 1uH2HM-0007v8-Qr; Mon, 19 May 2025 15:19:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989938.1373890; Mon, 19 May 2025 15: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 1uH2HM-0007v1-O9; Mon, 19 May 2025 15:19:48 +0000
Received: by outflank-mailman (input) for mailman id 989938;
 Mon, 19 May 2025 15:19:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2HL-0007uv-HW
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:19:47 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b29a3709-34c4-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 17:19:46 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-601dd3dfc1fso2771257a12.0
 for ; Mon, 19 May 2025 08:19:46 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d442069sm608739066b.103.2025.05.19.08.19.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 08: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" 
X-Inumbo-ID: b29a3709-34c4-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747667986; x=1748272786; darn=lists.xenproject.org;
        h=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;
        bh=rLgTU49aYgp8P+Wn53PNt/s9IHXzrJNpPoF6CGKGhEc=;
        b=HmR1+DFwCTspOq2Uz0b8z+tpqjlUy3pQANRQCiddufNDk6FcvXKP5qVIuEv4OUbSqF
         YBKhP6xu8jJjbq6GDj5lCeBMArT5Ts/PTY9u1fl7iiXjLiuy+XJS4EyN65IEm7GrlboD
         Q6AXxDHXSxIMINcYEPhHayOt0r3fmyGP0ZjuwTGRT+b0Gkfg9HZMj/fA7ktSwWHW2jYi
         0Arh5THDS7EB5APvyuJuhoLsolmCUjPz3JXA6/zc1v0054DG1Lbxir7xE2P0hL6cTJyH
         /AAPw0sErPD8DTQv0FdDXcCZvyQtpg/wjnYMSP6fmt+50Z1zVuqM06hIZjO/fUl6D9G5
         ywXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747667986; x=1748272786;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=rLgTU49aYgp8P+Wn53PNt/s9IHXzrJNpPoF6CGKGhEc=;
        b=jWoVHxTH0X6GfsZ7917hjecs9QlUrLW8Jm7M43pQTRuETGqOzIWTdPPSJyCcLekFlj
         OTg8kfkqQe54iCp9gb2qMPmk7LDxfybiZdNHetcn6MNCq7GP18d+n6TN5yjaRlharbng
         FGxJ2Wmcz2/q5yvCS1G7uRgQklu/g4Uer3QNaesugq1Z4JBoSiA9dat/+RIGSnOvy2kf
         lUPnBMrKfRLtB8JNPKLhzht/1q0I15qIZDIETatJfwFu4WLbiaHhCmXxUIFkJEVrXukb
         Vr8Cbke+zR93PctV985gNyLgLS8JG/ESrk0MEC7VDsd2z+BYJOslHncaBMRi2RIlrzRp
         Iasw==
X-Forwarded-Encrypted: i=1; AJvYcCVPXgtUHfD7OKrb2f6o3H4Z4IEWQCGfuSRYo2ccgho/4G800Q6AbpPwMFQ1qDVQwovApjMPA1tZUks=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzHw8CKQcWWaXIgDfULGbUwPaUXikMNFv3aOsnshUMO/dmXtbyI
	AeEhnt2JkD81hzwuX6fI/oOeWNk00oMtbk3uqTYEM0ZZiepK/XVdPooD
X-Gm-Gg: ASbGncuJjBJPfqYPpGjbBf+eAGgwikHjNjojh2GYIqELt1J/kPggXexL9kk04qi1qBT
	jxsA4jR1abY9H+ozNF8GkbVL6UyQUzX+NMDqF3R6r1hKCL+b1TDSnm3JTUO9/IuxmpUawAWG2/9
	Ow1v/XOEjO66ZFPECFRIPMvmY4kf17AX5pe4ccdRn8LhX1DbzpsuEI7BtBbJ9kx7dKPaGy5cjNm
	czNz+fEf//yxNq5skhrvfLxTa/+QWBAH5LRYY1vuizjsErgv2pGnQOcPuPyVSLGEG8CGBAfp3ee
	pM0OvdSbW0kyXSCi1Tl3SiljZgPWaDJ8+jNSJvTMOnMAacc5vbMM9xYfQd5buAF+B6lDgpcuVXc
	SGjctfcWqIiHQpJTl+Muy/MAv
X-Google-Smtp-Source: AGHT+IF1BWtRByF/LHKaQm16HWz6BYUwA6GT2uc6ij5tDgs8ZWJjGY6vFnLoa2AS7u/i0OJOW53H+A==
X-Received: by 2002:a17:906:8f8a:b0:ad2:500c:16ce with SMTP id a640c23a62f3a-ad536c23cffmr956568366b.33.1747667985342;
        Mon, 19 May 2025 08:19:45 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------0070URhvs2zgDilLMLQSPefP"
Message-ID: <52c0be11-7c8e-4e12-9005-3a7ca7f12c43@gmail.com>
Date: Mon, 19 May 2025 17:19:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/16] xen/riscv: imsic_init() implementation
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
 <0d9a9a9e-3454-465f-ac1d-cd65ba4a5792@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <0d9a9a9e-3454-465f-ac1d-cd65ba4a5792@suse.com>

This is a multi-part message in MIME format.
--------------0070URhvs2zgDilLMLQSPefP
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/15/25 10:42 AM, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> imsic_init() is introduced to parse device tree node, which has the following
>> bindings [2], and based on the parsed information update IMSIC configuration
>> which is stored in imsic_cfg.
>>
>> The following helpers are introduces for imsic_init() usage:
>>    - imsic_parse_node() parses IMSIC node from DTS
>>    - imsic_get_parent_cpuid() returns the hart ( CPU ) ID of the given device
>>      tree node.
>>
>> This patch is based on the code from [1].
>>
>> Since Microchip originally developed imsic.{c,h}, an internal discussion with
>> them led to the decision to use the MIT license.
>>
>> [1]https://gitlab.com/xen-project/people/olkur/xen/-/commit/0b1a94f2bc3bb1a81cd26bb75f0bf578f84cb4d4
>> [2]https://elixir.bootlin.com/linux/v6.12/source/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
>>
>> Co-developed-by: Romain Caritey
>> Signed-off-by: Oleksii Kurochko
>> ---
>> Changes in V2:
>>   - Drop years in copyrights.
> Did you, really?

Oops, missed to drop it in asm/imsic.h. Thanks.

>> +    if ( rc )
>> +        return rc;
>> +
>> +    nr_mmios = imsic_cfg.nr_mmios;
>> +
>> +    /* Allocate MMIO resource array */
>> +    imsic_cfg.mmios = xzalloc_array(struct imsic_mmios, nr_mmios);
>> +    if ( !imsic_cfg.mmios )
>> +        return -ENOMEM;
>> +
>> +    imsic_cfg.msi = xzalloc_array(struct imsic_msi, nr_parent_irqs);
>> +    if ( !imsic_cfg.msi )
>> +        return -ENOMEM;
> Leaking the earlier successful allocation?
>
>> +    /* Check MMIO register sets */
>> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
>> +    {
>> +        imsic_cfg.mmios[i].cpus = xzalloc_array(unsigned long,
>> +                                                BITS_TO_LONGS(nr_parent_irqs));
>> +        if ( !imsic_cfg.mmios[i].cpus )
>> +            return -ENOMEM;
> Leaking all earlier successful allocations?

In this cases should be:
     {
         rc = -ENOMEM;
         goto imsic_init_err;

>> +        if ( base_addr != imsic_cfg.base_addr )
>> +        {
>> +            rc = -EINVAL;
>> +            printk(XENLOG_ERR "%s: address mismatch for regset %d\n",
>> +                   node->name, i);
>> +            goto imsic_init_err;
>> +        }
>> +    }
>> +
>> +    /* Configure handlers for target CPUs */
>> +    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
>> +    {
>> +        rc = imsic_get_parent_cpuid(node, i, &cpuid);
> Coming back to a comment I gave on the respective earlier patch: What you get back
> here is a DT value, aiui. There's no translation to Xen CPU numbering space, as
> would be required for e.g. ...
>
>> +        if ( rc )
>> +        {
>> +            printk(XENLOG_WARNING "%s: cpu ID for parent irq%d not found\n",
>> +                   node->name, i);
>> +            continue;
>> +        }
>> +
>> +        if ( cpuid >= num_possible_cpus() )
> ... this. Are you using DT numbering without any translation, no matter that it
> (I suppose) could be very sparse?

Agree, it should translation of cpuid to Xen CPU numbering space as cpuid could be
sparsed according to the RISC-V spec, which guarantees only that cpuid 0 will be present,
all other could be any number.

I thought about to update that with:
    xen_cpuid = hartid_to_cpuid(hartid);

    if ( xen_cpuid >= num_possible_cpus() )
    {
         printk(XENLOG_WARNING "%s: unsupported cpu ID=%lu for parent irq%u\n",
                node->name, hartid, i);
         continue;
    }
       ...

   /* defined in asm/smp.h */
   static inline unsigned long hartid_to_cpuid(unsigned long hartid)
   {
     for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
     {
         if ( hartid == cpuid_to_hartid(cpuid) )
             return cpuid;
     }

     return NR_CPUS;
   }
   
(the proper name of variable 'cpuid' I think we will agree in the discussion of one of the
earlier patches.)

But then it will be an issue that if hart_id (from DT) hasn't been assigned to Xen's cpuid,
then IMSIC's msi[] and mmio[] won't be configured properly.
Probably this is not an issue and this assignment of cpuid to hartid could be done before
imsic_init() in case of CONFIG_SMP=y.

>> +            continue;
>> +        }
>> +
>> +        /* Find MMIO location of MSI page */
>> +        index = nr_mmios;
>> +        reloff = i * BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ;
>> +        for ( unsigned int j = 0; nr_mmios; j++ )
> DYM "j < nr_mmios"?

Yes, the condition should be corrected. Interesting why I am not faced an issue with such
condition, nr_mmios shouldn't be zero (I'll double check) and Linux kernel has the same
condition:
   https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-riscv-imsic-state.c#L907C31-L908C1
It seems like LK wants to have a fix too.

>> +        {
>> +            if ( reloff < imsic_cfg.mmios[j].size )
>> +            {
>> +                index = j;
>> +                break;
>> +            }
>> +
>> +            /*
>> +             * MMIO region size may not be aligned to
>> +             * BIT(global->guest_index_bits) * IMSIC_MMIO_PAGE_SZ
>> +             * if holes are present.
>> +             */
>> +            reloff -= ROUNDUP(imsic_cfg.mmios[j].size,
>> +                BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ);
>> +        }
>> +
>> +        if ( index >= nr_mmios )
> Why is it that you need both "index" and "j"?

There is no need. I will drop 'j'.

>> +                   node->name, imsic_cfg.msi[cpuid].base_addr + reloff);
>> +            imsic_cfg.msi[cpuid].offset = 0;
>> +            imsic_cfg.msi[cpuid].base_addr = 0;
>> +            continue;
>> +        }
>> +
>> +        bitmap_set(imsic_cfg.mmios[index].cpus, cpuid, 1);
> Depending on clarification on the number space used, this may want to be
> cpumask_set_cpu() instead. Else I think this is simply __set_bit().

Considering that cpuid is taken from DT and the value in device tree is what we are
using as hartid and hartid could be according any number from 0 to sizeof(unsigned long)
then we can't use cpuid for msi[] as overflow could happen, it seems like we should use
an id from Xen space. (so basically xen_cpuid which I mentioned above)

>
>> +        imsic_cfg.msi[cpuid].base_addr = imsic_cfg.mmios[index].base_addr;
>> +        imsic_cfg.msi[cpuid].offset = reloff;
> How come it's cpuid that's used as array index here? Shouldn't this be i,
> seeing that the array allocation is using nr_parent_irqs?

Agree, something wrong is here. As I mentioned above, I think, Xen cpu space should be used here.

>> +    XFREE(imsic_cfg.msi);
>> +
>> +    return rc;
>> +}
>> --- /dev/null
>> +++ b/xen/arch/riscv/include/asm/imsic.h
>> @@ -0,0 +1,65 @@
>> +/* SPDX-License-Identifier: MIT */
>> +
>> +/*
>> + * xen/arch/riscv/imsic.h
>> + *
>> + * RISC-V Incoming MSI Controller support
>> + *
>> + * (c) 2023 Microchip Technology Inc.
>> + */
>> +
>> +#ifndef ASM__RISCV__IMSIC_H
>> +#define ASM__RISCV__IMSIC_H
>> +
>> +#include 
>> +
>> +#define IMSIC_MMIO_PAGE_SHIFT   12
>> +#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
>> +
>> +#define IMSIC_MIN_ID            63
> This isn't the "minimum ID", but the "minimum permissible number of IDs" as per
> its first use in imsic_parse_node(). Further uses there consider it a mask,
> which makes me wonder whether the imsic_cfg.nr_ids field name is actually
> correct: Isn't this the maximum valid ID rather than their count/number?

imsic_cfg.nr_ids it is a value of interrupt identities supported by IMSIC interrupt file according to
DT binding:
   riscv,num-ids:
     $ref: /schemas/types.yaml#/definitions/uint32
     minimum: 63
     maximum: 2047
     description:
       Number of interrupt identities supported by IMSIC interrupt file.

 From some point of view it could be called as maximum valid ID specifically for a platform, but the number
of ids looks better to me.

Thanks.

~ Oleksii

--------------0070URhvs2zgDilLMLQSPefP
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 10:42 AM, Jan Beulich wrote:
    
    
    
    
    
      
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    imsic_init() is introduced to parse device tree node, which has the following
bindings [2], and based on the parsed information update IMSIC configuration
which is stored in imsic_cfg.

The following helpers are introduces for imsic_init() usage:
  - imsic_parse_node() parses IMSIC node from DTS
  - imsic_get_parent_cpuid() returns the hart ( CPU ) ID of the given device
    tree node.

This patch is based on the code from [1].

Since Microchip originally developed imsic.{c,h}, an internal discussion with
them led to the decision to use the MIT license.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/0b1a94f2bc3bb1a81cd26bb75f0bf578f84cb4d4
[2] https://elixir.bootlin.com/linux/v6.12/source/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml

Co-developed-by: Romain Caritey <Romain.Caritey@microchip.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in V2:
 - Drop years in copyrights.

    
      
    
      
    Did you, really?
    
    
    
    
    Oops, missed to drop it in asm/imsic.h. Thanks.


    
    
    
      
    
        
    +    if ( rc )
+        return rc;
+
+    nr_mmios = imsic_cfg.nr_mmios;
+
+    /* Allocate MMIO resource array */
+    imsic_cfg.mmios = xzalloc_array(struct imsic_mmios, nr_mmios);
+    if ( !imsic_cfg.mmios )
+        return -ENOMEM;
+
+    imsic_cfg.msi = xzalloc_array(struct imsic_msi, nr_parent_irqs);
+    if ( !imsic_cfg.msi )
+        return -ENOMEM;

    
      
    
      
    Leaking the earlier successful allocation?


    
      
    
        
    +    /* Check MMIO register sets */
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+    {
+        imsic_cfg.mmios[i].cpus = xzalloc_array(unsigned long,
+                                                BITS_TO_LONGS(nr_parent_irqs));
+        if ( !imsic_cfg.mmios[i].cpus )
+            return -ENOMEM;

    
      
    
      
    Leaking all earlier successful allocations?
    
    
    
    
    In this cases should be:
    {
        rc = -ENOMEM;
        goto imsic_init_err;
    
    
    
      
    
        
    +        if ( base_addr != imsic_cfg.base_addr )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: address mismatch for regset %d\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+    }
+
+    /* Configure handlers for target CPUs */
+    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
+    {
+        rc = imsic_get_parent_cpuid(node, i, &cpuid);

    
      
    
      
    Coming back to a comment I gave on the respective earlier patch: What you get back
here is a DT value, aiui. There's no translation to Xen CPU numbering space, as
would be required for e.g. ...


    
      
    
        
    +        if ( rc )
+        {
+            printk(XENLOG_WARNING "%s: cpu ID for parent irq%d not found\n",
+                   node->name, i);
+            continue;
+        }
+
+        if ( cpuid >= num_possible_cpus() )

    
      
    
      
    ... this. Are you using DT numbering without any translation, no matter that it
(I suppose) could be very sparse?
    
    
    
    
    Agree, it should translation of cpuid to Xen CPU numbering space as cpuid could be
sparsed according to the RISC-V spec, which guarantees only that cpuid 0 will be present,
all other could be any number.

I thought about to update that with:
   xen_cpuid = hartid_to_cpuid(hartid);

   if ( xen_cpuid >= num_possible_cpus() )
   {
        printk(XENLOG_WARNING "%s: unsupported cpu ID=%lu for parent irq%u\n",
               node->name, hartid, i);
        continue;
   }
      ...

  /* defined in asm/smp.h */
  static inline unsigned long hartid_to_cpuid(unsigned long hartid)
  {
    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
    {
        if ( hartid == cpuid_to_hartid(cpuid) )
            return cpuid;
    }

    return NR_CPUS;
  }
  
(the proper name of variable 'cpuid' I think we will agree in the discussion of one of the
earlier patches.)

But then it will be an issue that if hart_id (from DT) hasn't been assigned to Xen's cpuid,
then IMSIC's msi[] and mmio[] won't be configured properly.
Probably this is not an issue and this assignment of cpuid to hartid could be done before
imsic_init() in case of CONFIG_SMP=y.

    
    
    
      
    
        
    +            continue;
+        }
+
+        /* Find MMIO location of MSI page */
+        index = nr_mmios;
+        reloff = i * BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ;
+        for ( unsigned int j = 0; nr_mmios; j++ )

    
      
    
      
    DYM "j < nr_mmios"?
    
    
    
    
    Yes, the condition should be corrected. Interesting why I am not faced an issue with such
condition, nr_mmios shouldn't be zero (I'll double check) and Linux kernel has the same
condition:
  https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-riscv-imsic-state.c#L907C31-L908C1
It seems like LK wants to have a fix too.


    
    
    
      
    
        
    +        {
+            if ( reloff < imsic_cfg.mmios[j].size )
+            {
+                index = j;
+                break;
+            }
+
+            /*
+             * MMIO region size may not be aligned to
+             * BIT(global->guest_index_bits) * IMSIC_MMIO_PAGE_SZ
+             * if holes are present.
+             */
+            reloff -= ROUNDUP(imsic_cfg.mmios[j].size,
+                BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ);
+        }
+
+        if ( index >= nr_mmios )

    
      
    
      
    Why is it that you need both "index" and "j"?
    
    
    
    
    There is no need. I will drop 'j'.


    
    
    
      
    
        
    +                   node->name, imsic_cfg.msi[cpuid].base_addr + reloff);
+            imsic_cfg.msi[cpuid].offset = 0;
+            imsic_cfg.msi[cpuid].base_addr = 0;
+            continue;
+        }
+
+        bitmap_set(imsic_cfg.mmios[index].cpus, cpuid, 1);

    
      
    
      
    Depending on clarification on the number space used, this may want to be
cpumask_set_cpu() instead. Else I think this is simply __set_bit().
    
    
    
    
    Considering that cpuid is taken from DT and the value in device tree is what we are
using as hartid and hartid could be according any number from 0 to sizeof(unsigned long)
then we can't use cpuid for msi[] as overflow could happen, it seems like we should use
an id from Xen space. (so basically xen_cpuid which I mentioned above)


    
    
    
      
    

    
      
    
        
    +        imsic_cfg.msi[cpuid].base_addr = imsic_cfg.mmios[index].base_addr;
+        imsic_cfg.msi[cpuid].offset = reloff;

    
      
    
      
    How come it's cpuid that's used as array index here? Shouldn't this be i,
seeing that the array allocation is using nr_parent_irqs?
    
    
    
    
    Agree, something wrong is here. As I mentioned above, I think, Xen cpu space should be used here.


    
    
    
      
    
        
    +    XFREE(imsic_cfg.msi);
+
+    return rc;
+}
--- /dev/null
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/imsic.h
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) 2023 Microchip Technology Inc.
+ */
+
+#ifndef ASM__RISCV__IMSIC_H
+#define ASM__RISCV__IMSIC_H
+
+#include <xen/types.h>
+
+#define IMSIC_MMIO_PAGE_SHIFT   12
+#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
+
+#define IMSIC_MIN_ID            63

    
      
    
      
    This isn't the "minimum ID", but the "minimum permissible number of IDs" as per
its first use in imsic_parse_node(). Further uses there consider it a mask,
which makes me wonder whether the imsic_cfg.nr_ids field name is actually
correct: Isn't this the maximum valid ID rather than their count/number?
    
    
    
    
    imsic_cfg.nr_ids it is a value of interrupt identities supported by IMSIC interrupt file according to
DT binding:
  riscv,num-ids:
    $ref: /schemas/types.yaml#/definitions/uint32
    minimum: 63
    maximum: 2047
    description:
      Number of interrupt identities supported by IMSIC interrupt file.

>From some point of view it could be called as maximum valid ID specifically for a platform, but the number
of ids looks better to me.

Thanks.

~ Oleksii

    
  


--------------0070URhvs2zgDilLMLQSPefP--


From xen-devel-bounces@lists.xenproject.org Mon May 19 15:26:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:26:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989950.1373901 (Exim 4.92)
	(envelope-from )
	id 1uH2Ni-0001EQ-Fu; Mon, 19 May 2025 15:26:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989950.1373901; Mon, 19 May 2025 15: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 1uH2Ni-0001EJ-D6; Mon, 19 May 2025 15:26:22 +0000
Received: by outflank-mailman (input) for mailman id 989950;
 Mon, 19 May 2025 15:26:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2Nh-0001ED-Uw
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:26:21 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9dc0930e-34c5-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 17:26:21 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ad563b69908so219975466b.3
 for ; Mon, 19 May 2025 08:26:21 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d496550sm601327766b.134.2025.05.19.08.26.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 08:26: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" 
X-Inumbo-ID: 9dc0930e-34c5-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747668380; x=1748273180; darn=lists.xenproject.org;
        h=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;
        bh=yRl/PkMU6oguqxB83j7gje4eBUCYPjl7jM58/1LnIHc=;
        b=W1kYqDY3Jn8GKrMkAqSgwrTe3jJwamTxb9sR7AcKgHeiJXNkDlrjz46iIsHHzyrbS4
         3UnJ9B89BBLHdHI50RyVWVeBXZU5niIpskG4mEOrEgkYEC1mj2YnYL7m9aVHzpUZcS+H
         VBeJOchyfgL4G03HcUaooz7WERMOYBSt+ZMXGnmS2cHN4VL7xphSEEY9BnJ2pCzujW6j
         UzwPT6/1Si/0dNbxWkPvRRs3obKsEVCdRp7fDbvR/tHcjHnIIyKua3eSv+ZKcaZkG9ma
         2lagl/AKTIj+gzudJJ3iF+2M6Lm2fYXfRotN7gyE9qQMRdvFJWhipP3+nHdIuLH5FnBM
         cGYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747668380; x=1748273180;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=yRl/PkMU6oguqxB83j7gje4eBUCYPjl7jM58/1LnIHc=;
        b=onPaV4M1gdz1GtoQfzE+S5A/82/CjFCdDvnBYsEmz4o7+kHC/TMqcp9og9pK+/ZOjy
         dViCKu4+pIEDwp9JZcDMiGXQqf6jvR4C5EB2ErO+uUsLA+Th7EDjPuSHFvo8dVC+qxqu
         O2uSh5CSppw9BxSyMo0JEcZf9tCuWdXbrL4V7sKoSu3vwtf4hLVpBCElO6tV0eE+xN5o
         +JXzJFcKTpqO9UuCPD8W4xqtbUxt6xmt+mKJ+WZdA14ysTmT5pYJh4WE6Xbw1uBjq1Tn
         PsW/q/OQK45xG/pibHHSGSIkBH1mzJbpOPeKMC/sJQaVuqF0PY2cuWwOVJxYaba0bUkU
         8nhg==
X-Forwarded-Encrypted: i=1; AJvYcCXIROveDcKs9xYde7k6dD5nGJ9TymgPd0ulpDX9jF0YKtdKiQSjif0IEREOt8oKzBB0GAm+FZXQutg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyZX9lwTZuITgi25dgGeJSHPqA/x9nee2ahvLgdMoCBAsiqpvJ+
	4hwPWh1Ao5BxfPMso0Ua1f8s97MYu6hrB/IhkRPMosWlZY/sxrhU82SU
X-Gm-Gg: ASbGnctoORnofaYBG8K6Si3y868ijsQ8Q1xO2MdjfCtfmY9fFxtYvhvA0ITWWKo3iCT
	JtaYePP4/zkdhAI972uhOvAwmcDAACGgsiASQ+c/4fHrSXOghzwRR2ox5YQGdZBTYlBMpm1Fgdc
	0fx+6r3GlyBDTHnD9tNhPcPeTLIVWbBC0OvdHkjMqC5bQdaZZdkc4LvxZHOxg3wleaErBkmbJ6u
	YT1Kkej0wOvbiywDGPNcogML331+V5JJOD0DAkpXpQCER66h+/6nGFc9TjR6x6p2C2xH3p7kFoP
	AYrOKGYWojvjXN+SllEfURq6RsD/P74aye7l0anxwRRt9BDHTw5tiWjv1rO4MtJptXWlQys7iVq
	46GqYUPQbHHa4rJc2KPD75gLG
X-Google-Smtp-Source: AGHT+IGx3SLRWBY8MEz7CVvAS1gTDVF/2sgUzHOdR6lIKA7RRyVxwvcmy1UxA14RwrUsvH4kTfLPVg==
X-Received: by 2002:a17:906:2418:b0:ad5:480e:c0a4 with SMTP id a640c23a62f3a-ad5480ec7a5mr676614666b.8.1747668380169;
        Mon, 19 May 2025 08:26:20 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------P0N0FGKoqVbxlPleYZXhfR2f"
Message-ID: <4b948489-6fb9-4554-9a4c-4fa75de7345d@gmail.com>
Date: Mon, 19 May 2025 17:26:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/16] xen/riscv: imsic_init() implementation
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
 <0d9a9a9e-3454-465f-ac1d-cd65ba4a5792@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <0d9a9a9e-3454-465f-ac1d-cd65ba4a5792@suse.com>

This is a multi-part message in MIME format.
--------------P0N0FGKoqVbxlPleYZXhfR2f
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/15/25 10:42 AM, Jan Beulich wrote:
>> +                   node->name, imsic_cfg.msi[cpuid].base_addr + reloff);
>> +            imsic_cfg.msi[cpuid].offset = 0;
>> +            imsic_cfg.msi[cpuid].base_addr = 0;
>> +            continue;
>> +        }
>> +
>> +        bitmap_set(imsic_cfg.mmios[index].cpus, cpuid, 1);
> Depending on clarification on the number space used, this may want to be
> cpumask_set_cpu() instead. Else I think this is simply __set_bit().

cpumask_set_cpu() requires cpumask_t which uses static definition but we are
using dynamic allocation.
So it seems like bitmap_set() is the  best one option or reworking to static
allocation will require.
Am I missing something?

~ Oleksii


--------------P0N0FGKoqVbxlPleYZXhfR2f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 10:42 AM, Jan Beulich wrote:
    
    
    
    
    
      
    +                   node->name, imsic_cfg.msi[cpuid].base_addr + reloff);
+            imsic_cfg.msi[cpuid].offset = 0;
+            imsic_cfg.msi[cpuid].base_addr = 0;
+            continue;
+        }
+
+        bitmap_set(imsic_cfg.mmios[index].cpus, cpuid, 1);

    Depending on clarification on the number space used, this may want to be
cpumask_set_cpu() instead. Else I think this is simply __set_bit().

    
    
    
    
    cpumask_set_cpu() requires cpumask_t which uses static definition but we are
using dynamic allocation.
So it seems like bitmap_set() is the  best one option or reworking to static
allocation will require.
Am I missing something?

~ Oleksii

    

    
  


--------------P0N0FGKoqVbxlPleYZXhfR2f--


From xen-devel-bounces@lists.xenproject.org Mon May 19 15:51:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:51:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989961.1373931 (Exim 4.92)
	(envelope-from )
	id 1uH2le-0005YJ-02; Mon, 19 May 2025 15:51:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989961.1373931; Mon, 19 May 2025 15:51: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 1uH2ld-0005YC-SQ; Mon, 19 May 2025 15:51:05 +0000
Received: by outflank-mailman (input) for mailman id 989961;
 Mon, 19 May 2025 15:51:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2lc-00055d-3s
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:51:04 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20625.outbound.protection.outlook.com
 [2a01:111:f403:260e::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 10ec3efc-34c9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 17:51:02 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB9023.eurprd03.prod.outlook.com (2603:10a6:20b:5b7::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.29; Mon, 19 May
 2025 15:50:55 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8722.031; Mon, 19 May 2025
 15:50: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" 
X-Inumbo-ID: 10ec3efc-34c9-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IVhH1F94F8WcCg02MnqypWYfjYA5Rs8TFx2DewgksMl9LrKTx4wRYIzVlOOKEx5NDGy28yVyhPuv2UsFl0larQMcMSqEYH+MLCeig5vkHiMjBVpcIMNTIp5NFay3lckXyBS0l8wqnpajB9Y0onabwggn1K00P0VQxpmtvnN8VYm9NLcYxYKA9gDBFzO5+OgpV1n5EPVpYP1FDoEbwzo4pKNngpHdhqVLh8F91YF4rTSwWAG6bp17BMDyJA00ybslqE574Om2OO5Jqqivf6BDEZk3o7/RUVLOKjWCD/uj+R8stWdlvRRsdAjD02A0MBy+dkUJiz6Yba2oLx1ak4iyWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PUkju2omIIym+Lx1lnHzTO4HLWdLui4dm1V50RKOGHc=;
 b=hvyOHLx3EAkfyatxnudy9BRmSBcKEiLxARmME1VQnSS6z5Oe/6KJUTN+LpdN0Lf3ne9aZMVVPdt/aZCHtfur1blC+r4fLJ3c2ZUfruiAGG6ftNVVnSiHoabEHTqHjaN0joYtMaRoLWAGDuZRQyOv7NaIqYguUUiZAQqecJqDklA/dUIT7Rr1ufdRs1mwTki+60b6r6DCHcBl949vQP3/PzSbHSbkK7OnUnC4MaI+ILk2hdbxZWc8DBeDYGncTB+8pOUhO+i7WrsI+HupSXr8RFbi2QPMiDk0v94kHe8PN3/rpI411Mp2GC4l/0bSLUtmqjZkvzTGvBRzgwRi6AzEPw==
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=PUkju2omIIym+Lx1lnHzTO4HLWdLui4dm1V50RKOGHc=;
 b=J0T976dK/8SbmsKIpaUbSDjbDr0ntAQ90q8gT3s0mTLSDSirzAphzVSKgiMdU5VZwtam6ohnPC8CC6NWnEsbmv8bOSjw1AM4brAAcBGV++i/cr4rgDkdv3J9qHIv5zu/0MHKoP1KN/T+lEzeeT582iZ/W6eiJWOrRWxmdCoLQUikb+VEbE09IQWuouTTlscTchAfbHWiemqWSYXypwfO8DBl0JOX/Fyi1gJag9sf/9JjVfdrxY1zx7qYIUNYMOTM/WTyrUtwVjs58gSqQ2h//ltujMYjKlPTuaBPvxuRuUN3fscrHz6XN8ezG3rNEpqYkfk+rLJ1fpszhJH0D2eLjg==
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: [RFC PATCH v4 0/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent
 support
Thread-Topic: [RFC PATCH v4 0/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent support
Thread-Index: AQHbyNXOhvC4eZK2DUaLACAnive8zg==
Date: Mon, 19 May 2025 15:50:55 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB9023:EE_
x-ms-office365-filtering-correlation-id: 5f778934-43a9-4e45-2455-08dd96ecf10d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?+766BHqIYySAICMsv+t+4FfJvkGjASdhDImmwJqRNlR6tp26UwpxWmbWww?=
 =?iso-8859-1?Q?uMmMnlXxrp3cXdZcyFqbgDgrZ/NThrwZ8QZvjDZUkIzAd0PhAcbBSN3XzW?=
 =?iso-8859-1?Q?CBlPB/gDR8zXHltgwPkiL0C03L44M7hhyYMOSIFiIaFAzF0sst4L7O2H86?=
 =?iso-8859-1?Q?dIAUUnD6gg/F0zMIxTwvEirQ3z+cV6hzVBaM3iX/YsniWCVPEUzXGYVnnw?=
 =?iso-8859-1?Q?FY4H636IBHYOZsuvOBkH1u+zLiCYnqquvMfSVVX7XCjd24JONlNSr+AJ8x?=
 =?iso-8859-1?Q?kvs3tDTB1y5yiLd9wlKAYRZeoBwnOVO8LZhLJbjrzzCdXESf1+amZRf3Ne?=
 =?iso-8859-1?Q?KECYBunB9gBfATj5tIMiGIukLircgbpPdSLmaqKIBtw8aeeEd6LQT3JsJD?=
 =?iso-8859-1?Q?UGy3spzizVPNfg0OrM433w66FS+oq41mRUBWw6ORxWTtszBCXFrSxYnXRj?=
 =?iso-8859-1?Q?IgYBLm4+jUo26vxhzDP40dzNTk1ejvXg+Ra8NQy1rNik82WeXiYapAcFDc?=
 =?iso-8859-1?Q?Pk/9KHSaCjpcVAl78A/aNvXvISXvhOdt2UX9uRkCMllKGSClOBLM0ihAvH?=
 =?iso-8859-1?Q?egZ59Zw8Wp25on605YIz59IlUfGnoDnW/TsfzlCSzat1l1I9V//pUbpFvd?=
 =?iso-8859-1?Q?RxGzrvV0AidsesdSSzlkoCdg+5JgwYMbb17XtWiYVY3RMoTeOb30DfZFiD?=
 =?iso-8859-1?Q?saCDtpQIU4HLiaUNDmJBKl2HIp1Wwh3kaeiNcRCyeDRhuZiKjs5CZrfqyT?=
 =?iso-8859-1?Q?L4gEAHPH9ZdMeTdN1MtmiueMaxIpjeCoVd58AkmtUgvogotyYMBFZhkz/f?=
 =?iso-8859-1?Q?Ya8sPgcZLqCFbcOYiH3MiVB5/QT37ixVghKlm4Kc0tPy87XPFnR3KCO+gP?=
 =?iso-8859-1?Q?+8lZ3aMeGMcYa50Lsl0Fr8vZ7XL70+bl++IDBMDoNT+Zd0FFrViKHIPp7Z?=
 =?iso-8859-1?Q?xxjZ2aBVJ+2o6gQxTcGhbsnE5KwXXGV/rbHVu1Ox1CJEjh2Mx3U61obiOK?=
 =?iso-8859-1?Q?OxvQ4+sDypiUkjymG+1IXwtTtOIBfn5xUqSKbLe/29GA3z/0Wcc44FRSDL?=
 =?iso-8859-1?Q?4X4jiyjshR435FXH+g0P34HuFsnHbStxCaL0QctWLdW7LCmmol2qO4BFXn?=
 =?iso-8859-1?Q?0p5i2d/DUHljeG8yIAv4ejnyqY9jt8uMPn2XQ0xyt8mi/bAPWZc2qiDATT?=
 =?iso-8859-1?Q?mAtyjVTjr3eO98IEO4tMU81O2YR/WlL7YfSWlNk90rKNa3omJCeBermEQO?=
 =?iso-8859-1?Q?xjp1H+GXmmVpAxb4Y6dK2PgQCfU/YpOwzHkH+NWXrfpGm2z97U16qxu45o?=
 =?iso-8859-1?Q?/oFsv2vR8uJuvbYTlOyAPmPIFf6CTmnSVl3C1AQIo8DI9abv0N7nObWL7r?=
 =?iso-8859-1?Q?IC75FMiNGTn5ruq/Dajtmfe7AC6QeIIz2evPmwQkulhfTJM2UOkqYNCC0K?=
 =?iso-8859-1?Q?tEH2h25zXqYyQJim4sfyGPSJ/YGWZSAIecKnnBXkSUZaOoVxl8q7gFoXDR?=
 =?iso-8859-1?Q?M+OHHo8rd0JC7p87LIQlcE?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Z0sIDU2JxkSTuAvmA6Oe4DQpMhQtopuWGaJ04hMgAMidW9MCUZmuqyGWdk?=
 =?iso-8859-1?Q?VnODutzvfu+FoNuYeGMzx0O4TGn4Q1KuNENo740RFOcJGZWLj+s+MiYj82?=
 =?iso-8859-1?Q?bdYlE2rbgHwMSgRCpjW11j8RDGlko/FbRkEQKAnxTAE4GFlQA9XvYqfIQ4?=
 =?iso-8859-1?Q?K/VYY5yoY8ZHSyRp/fvAFjMHxDJ6IT3Pc2i/13Eivy7tzBi4WLbNvo4TsY?=
 =?iso-8859-1?Q?6DqUFPS+bpAZQTPWFNGyWHaSn4ny3R4bOuTOOYNUUoO4XOE62zEWtqoO53?=
 =?iso-8859-1?Q?t3XWee2pWfnklXxw0NOHGOcRdmCTVMNKYEXYH6giVDkKaF7nkiV14ZWbnE?=
 =?iso-8859-1?Q?0BlTXZBiwxQBH5A+evvI/j6J6vvSSIBpzrXvUvySJdZf266eBG9+r0wN+f?=
 =?iso-8859-1?Q?nekHaFjjocnllQUT7Q3IcOrTw+2rKJdSHgpF4ptggYGgo32+onwQqcKyoe?=
 =?iso-8859-1?Q?7x02lDqaL48bFZbEPeqfaMMUgc6dhV/QOQ7nqLD8ufeR+husxMaFi2xkX8?=
 =?iso-8859-1?Q?CYdH6/7yBVWYmPRDCjoFvfWYHkL2YM3zgYzVLRG0uy5/LrwsnJ2r23ETu9?=
 =?iso-8859-1?Q?fHx5xdM7HDQpQiXiVhJ7P69xAHwwRSYtHzM7T6Ecop6JnvjAb3/WlnSDy/?=
 =?iso-8859-1?Q?xofsnzBjzo01uSdgSJTjYAMTHYX+u33zA9QP9g7CndpXJh9TGRw82xQUW3?=
 =?iso-8859-1?Q?TpOrc0oSVbKJjvaWtJRxzNixrCTjkmsCZOEOZSkMb5mz61rELDpM8CHUDs?=
 =?iso-8859-1?Q?xQATi2SSiFJK9f7+rof/2VZveVseqpycMRsGuPD7NPH0F0AkUSz3eKyJYh?=
 =?iso-8859-1?Q?AFDGhWXO/V1wJ9yYpFgBJCKe9L2fBGdy1i0nYmyTHeDGoukxfHVVK4Ksj7?=
 =?iso-8859-1?Q?a0c3p8WHrkAjoCxkFVQlvW0Ztmbv46mWFdYGNpelhLQPq+nmJpxKs+SZfA?=
 =?iso-8859-1?Q?wLn467+ii2GiYD/jz5hvYdrH6m2YA3Y4/zoJKHGeqalGdVoT4id7N4lxDp?=
 =?iso-8859-1?Q?5mobM9NcO/UXTGxvW8UcEYcSib9+/HKi4IK9T+6r13rDix7rm/2z+xrovv?=
 =?iso-8859-1?Q?oDjdJAD/oZUJj+1aNd4tAWu2UoUc4a1s2/IpEOzWmUZPNx4r1QAsygWqzQ?=
 =?iso-8859-1?Q?6aGAblXHGW+37oqu+d3vUJZfIWWyCqlkwkLsHZTw6X6B1e/ek7ofGeSEUy?=
 =?iso-8859-1?Q?CIQzh6otHHhUF1esjgOny+K6QemyQ3CVk3sMFgSUwW1AQ7G2Ms0c3X3xLX?=
 =?iso-8859-1?Q?/8h04w4idusCu+U+APaS9ilWfex/qAACzNo4/Ee9cmqkHL+XqIkcaVX/4v?=
 =?iso-8859-1?Q?Hq3ZWC9Kp66JudNzglAzw7hZ3BD3P7tkxqxvy/UfKgdadbjTEatNPjQxE7?=
 =?iso-8859-1?Q?KO34CXID3fW7VY7J0II+RTAHAJJau/aOaehbwwf7brnGKBZ5ysuiey75kE?=
 =?iso-8859-1?Q?ZZSpDxN/nsKRsmkvDhn/dHiNqDOoaN755O4t90B0EMAOpRkx+BWkzw21Nv?=
 =?iso-8859-1?Q?87V6g00uhTHRgPvaUaHf3wKnew8ZDsrIK3Lgdc4q6HtrYVFesYestl7Gb0?=
 =?iso-8859-1?Q?Y6WfMYaKcqo589gOySND1RwYrCf3Tz9j7UflL2lAZ78m9EfyXixffshitS?=
 =?iso-8859-1?Q?UJA3yVFgkYd7vInXlxsKe8QE7BzQn1gGY+C6BWIOTrZNWkR38/27a77A?=
 =?iso-8859-1?Q?=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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5f778934-43a9-4e45-2455-08dd96ecf10d
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 15:50:55.6950
 (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: V0v5AhyOnMC56M9C2ps7S6n2l72R3QBH185HpyUGvrxPXw5WXNeuit5/xljiL3/04WN85KRlurJZhpWaMxBusp4te0oX3o6jFYBV4xnFlBE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9023

Inroducing V4 RFC patch series  on top of the Xen version 4.20-rc2
which includes implementation of the SCI SCMI SMC multi-agent support.

Patch 1 "xen/arm: add generic SCI subsystem"
- rebased and refactored
- introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probin=
g
instead of custom,
  linker sections based implementation.
- added SCI API for Dom0 DT handling, instead of manipulating with ARM arch
dom0 code directly.
- RFC changes in XEN_DOMCTL_assign_device OP processing

Patch 2 "xen/arm: scmi-smc: update to be used under sci subsystem"
- update driver introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add =
SCMI
over SMC calls
handling layer") be used under sci subsystem.
- no functional changes in general

Patch 3 "xen/arm: scmi-smc: passthrough SCMI SMC to guest domain
This is new change which allows passthrough SCMI SMC, single agent interfac=
e to
guest domain
cover use case "thin Dom0 with guest domain, which serves as Driver domain"=
.
See patch commit message for full description.

Patch 4 - docs: arm: add docs for SCMI over SMC calls forwarding
driver
- add documentation section for Simple Arm SCMI over SMC/HVC calls
forwarding driver.

Patch 5 - xen/domctl: extend XEN_DOMCTL_assign_device to handle not
only iommu
- add chainged handling of assigned DT devices to support
access-controller functionality through SCI framework.
Change was done in two parts:
 - update iommu_do_dt_domctl() to check for dt_device_is_protected()
 and not fail if DT device is not protected by IOMMU
 -add chained call to sci_do_domctl() to do_domctl()

Patch 6 - xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver
- added "xen,scmi-secondary-agents" property in "chosen" to inform SCI SCMI
multi-agent driver
  about available agents and their configuration. It defines  to
 map.
  This option is Xen specific as Xen is the only one entry in the system wh=
ich
need to know
  about SCMI multi-agent support and configuration.
- each guest using SCMI should be configured with SCMI agent_id, so SCMI
  FW can implement Agent-specific permission policy.
  -- dom0: dom0_scmi_agent_id=3D in Xen command line option
  -- toolstack: arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D"
  -- dom0less: "xen,sci_type", "xen,sci_agent_id" properties in
"xen,domain" nodes.
- factored out SCMI generic definitions (re-usable)
- factored out SCMI shmem code (re-usable)
- the SCMI passthrough configuration for guest domains is similar to any ot=
her
HW passthrough cfg.

Patch 7 - docs: arm: add SCI SCMI SMC multi-agent driver docs
- add SCI SCMI SMC multi-agent driver documentation.

Patch 8 - docs: arm: proposal to add separate SCMI node for Xen agent
- proposal to add separate SCMI DT node for Xen management agent under
chosen of xen-config node, lile Hyperlaunch "xen,config".

This proposal introduces a new approach to the Xen multi-domain
configuration, where all Xen-specific configuration has been moved
under the "/chosen" node. This requires less Dom0 device tree
manipulation and isolates Xen configuration from domain configuration.

This approach provides the following device tree (DT) parameters:

- "xen,scmi-secondary-agents": A Xen-specific parameter under the
  "/chosen" node, which describes the SCMI agent configuration for
  the domains.
- the SCMI configuration for Xen (privileged agent) and the shared
  memory configuration for all agents are provided under the "/chosen"
  node and are used strictly by Xen for its initial configuration.
- the scmi_shm and SCMI configuration for Dom0 are placed in the
  "/firmware/scmi" node so that they can be moved to Dom0 without
  any changes.

This configuration allows the use of Xen-specific nodes to provide
information strictly needed by Xen while using the default SCMI
configuration for Dom0 and other domains. As a result, no additional
bindings need to be introduced to the device tree.
This simplifies the Xen SCMI multi-agent configuration and utilizes
generic device tree bindings for the domains.

Code can be found at:
https://github.com/oleksiimoisieiev/xen/tree/scmi_upstrv4

[1] RFC v2:
http://patchwork.kernel.org/project/xen-devel/cover/cover.1644341635.git.ol=
eksii_moisieiev@epam.com/
[2] RFC v3:
https://patchwork.kernel.org/project/xen-devel/patch/20250311111618.1850927=
-1-grygorii_strashko@epam.com
SCMI spec:
https://developer.arm.com/documentation/den0056/e/?lang=3Den

SCMI bindings:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree=
/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree=
/Documentation/devicetree/bindings/access-controllers/access-controllers.ya=
ml

Reference EL3 FW:
RPI5: https://github.com/xen-troops/arm-trusted-firmware/commits/rpi5_dev/
Renesas v4h:
https://github.com/GrygiriiS/arm-trusted-firmware/commits/rcar_gen4_v2.7_v4=
x-scmi_upd/

base-commit: dbe60f244c (Update Xen to 4.21, 2025-02-21)

Changes in v4:
- fix SPDX-License
- rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE
- move XEN_DOMCTL_assign_device code in separate patch
- Add documentation for SCI SCMI drivers
- xl.cfg doc
- fix comments from Stefano Stabellini
- fix toolstack code as sugested by Anthony PERARD
  - use MATCH_OPTION()
  - move arm_sci struct and cfg params in "arch_arm"
- add SCMI passthrough for dom0less case
- toolstack comments from Anthony PERARD
- added dom0less support
- added doc for "xen,scmi-secondary-agents"

Grygorii Strashko (6):
  xen/arm: scmi-smc: update to be used under sci subsystem
  xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent
  docs: arm: add docs for SCMI over SMC calls forwarding driver
  xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu
  docs: arm: add SCI SCMI SMC multi-agent driver docs
  docs: arm: proposal to add separate SCMI node for Xen agent

Oleksii Moisieiev (2):
  xen/arm: add generic SCI subsystem
  xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver

 MAINTAINERS                                   |   6 +
 .../arm/firmware/arm-scmi-proposal.rst        | 224 +++++
 .../arm/firmware/arm-scmi.rst                 | 442 +++++++++
 docs/hypervisor-guide/arm/index.rst           |   9 +
 docs/hypervisor-guide/index.rst               |   1 +
 docs/man/xl.cfg.5.pod.in                      |  47 +
 docs/misc/arm/device-tree/booting.txt         |  75 ++
 docs/misc/xen-command-line.pandoc             |  18 +
 tools/include/libxl.h                         |   5 +
 tools/libs/light/libxl_arm.c                  |  18 +
 tools/libs/light/libxl_types.idl              |  12 +
 tools/xl/xl_parse.c                           |  48 +
 xen/arch/arm/device.c                         |   5 +
 xen/arch/arm/dom0less-build.c                 |  49 +
 xen/arch/arm/domain.c                         |  12 +-
 xen/arch/arm/domain_build.c                   |  11 +-
 xen/arch/arm/firmware/Kconfig                 |  36 +-
 xen/arch/arm/firmware/Makefile                |   2 +
 xen/arch/arm/firmware/sci.c                   | 191 ++++
 xen/arch/arm/firmware/scmi-proto.h            | 164 ++++
 xen/arch/arm/firmware/scmi-shmem.c            | 173 ++++
 xen/arch/arm/firmware/scmi-shmem.h            |  45 +
 xen/arch/arm/firmware/scmi-smc-multiagent.c   | 860 ++++++++++++++++++
 xen/arch/arm/firmware/scmi-smc.c              | 191 +++-
 xen/arch/arm/include/asm/domain.h             |   5 +
 xen/arch/arm/include/asm/firmware/sci.h       | 214 +++++
 xen/arch/arm/include/asm/firmware/scmi-smc.h  |  41 -
 xen/arch/arm/vsmc.c                           |   4 +-
 xen/common/domctl.c                           |  19 +
 xen/drivers/passthrough/device_tree.c         |   6 +
 xen/include/asm-generic/device.h              |   1 +
 xen/include/public/arch-arm.h                 |   8 +
 32 files changed, 2856 insertions(+), 86 deletions(-)
 create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rs=
t
 create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi.rst
 create mode 100644 docs/hypervisor-guide/arm/index.rst
 create mode 100644 xen/arch/arm/firmware/sci.c
 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
 create mode 100644 xen/arch/arm/include/asm/firmware/sci.h
 delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon May 19 15:51:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:51:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989963.1373943 (Exim 4.92)
	(envelope-from )
	id 1uH2le-0005iV-P7; Mon, 19 May 2025 15:51:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989963.1373943; Mon, 19 May 2025 15:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH2le-0005h9-Gq; Mon, 19 May 2025 15:51:06 +0000
Received: by outflank-mailman (input) for mailman id 989963;
 Mon, 19 May 2025 15:51:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2ld-00055d-Ok
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:51:05 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20625.outbound.protection.outlook.com
 [2a01:111:f403:260e::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 11ca88c7-34c9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 17:51:04 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB9023.eurprd03.prod.outlook.com (2603:10a6:20b:5b7::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.29; Mon, 19 May
 2025 15:50:57 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8722.031; Mon, 19 May 2025
 15:50: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" 
X-Inumbo-ID: 11ca88c7-34c9-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XGg/9olLSQyFXp3WI5g+gqj1MIB07JU+yLK3Ts6j2cLNgHgEuiuW20D48yapSVv1MSFPqpPOA9ClHWtTCzniTKI5ZQw/AgqQozUqAiJkHgSmoAM9gIy3V3IO0fnqUXOUJkBa7lYNbIDrWfoVdWb8rE1dJap5cwCNtx5vZrw857b39AjEoWQR1WpVJ18qvcc/mFI9zaV9lMB0s6CPF2AORz6hZz2VzypjQuNC5VGjiWSrfSryzqAdilR/4qyjK4PXhyRYR360gIz0miuJ23j1REACtZOv3ZlR5cTmXSYsUeFbIVxPVt3D0Z7UAH4RnEs4hbHjpzgAh2Rt+VKfuhAVew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Pz/ZMdrRc7mCeJ8Rd8uhD1laT/igu+PIiYNbzkSXnXw=;
 b=awZAs3EoEJ12YoBTjpzM/OQX5ydkFI3y2OXtaW3q3dULc/T6LU+FaA8cV3pCGahU2sac65TZiuf2JYAUN4baNLWXnGnoGL3snLTkGCBmrPH++IDwyV1OMiTXQNlAAlOIFM7HFUw8GVOf1nh8QDlj4s7a6mj6hz1eXS69No8+W5a1GU5sQRfIOP9aYmpGl4ygG9Y6fdPZ+o2rFGKsRaZHwezNKGY+1aR3FzD9fP0D7PdpFPYEbOugX8WQ3tyrfEtmPyIAoUFuIyoVvneISHhFfsfediy5b8Zop15re/ytHVLU9tsuEkGMcd/LGfBXgAGKP346odYcnI252bWzK9xWUg==
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=Pz/ZMdrRc7mCeJ8Rd8uhD1laT/igu+PIiYNbzkSXnXw=;
 b=tFyoNb38GDdxQWh9E0i6XSWddce2ipDDfWHSFNbOt8/8nq6iE5F0qVITv5LBuLqCDJtzJouVTPmN6hKW0cL3BEOxEFc08nkF4dWI70pZlGEJAy+ZHwzmA0TN/QALXWzQl5LKKjYE8s5Lwl6v//fuq5kvRZN+LqMc4Q+UKh4rSqQa2UOO/8lye8fbc+IV3kBb7nIbe6q/XLWI/lIsIfDs8B01+WdNVMmX/PyqPy7CBo6bkpmSoXm3reIYKchopiPchv8oUczK/L7ZWF07MYCh9fiD0/cU3DLdUklQSFQWdev2uM4X0Gw31misgoGpzikri6ri0p/VhSLrz9WwdEOr1g==
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: [RFC PATCH v4 4/8] docs: arm: add docs for SCMI over SMC calls
 forwarding driver
Thread-Topic: [RFC PATCH v4 4/8] docs: arm: add docs for SCMI over SMC calls
 forwarding driver
Thread-Index: AQHbyNXP0pQacOnhI0GW40rDQn7cHA==
Date: Mon, 19 May 2025 15:50:57 +0000
Message-ID:
 <66d4472e46d94e4b64027986f004b98f610c4f1e.1747669845.git.oleksii_moisieiev@epam.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB9023:EE_
x-ms-office365-filtering-correlation-id: 33e991e4-a9a5-4dc6-930f-08dd96ecf219
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?z2dnIVCiRsGu9p73VfXaMrx2qE9yzZOPkZ5CMVe1S2cvzAXDLGA6IeHSk6?=
 =?iso-8859-1?Q?WpGsuCQPHKXNWF/KuqNmliXjrc2r8XC7mOD6r5Y3mzVLvzWSkCOwgk5LMo?=
 =?iso-8859-1?Q?McnVpcGBvJoiOw2fEGBzU3GaZoQEHPbjb+XZB8IxFQiXRimR9Q1O1oJFZu?=
 =?iso-8859-1?Q?b99/P6wdpYiEjzGInbTI9ASlGMaZnOuwIeOR0ZFRClMGC9RCg0qdd/9k9n?=
 =?iso-8859-1?Q?EhNuDKh5kjZ+Vd0Xmy4quIJnWnq+tgsxuMqzhmk6pXne7tyHskDjwCHndp?=
 =?iso-8859-1?Q?jd3Zqszo2cuw9CCMb5BjmEW2wTcQfTx9pllPLF82vuR6uqwXOysx8Lskfi?=
 =?iso-8859-1?Q?olveXbWkAsL8mAEHZsbLMXIaMNcdscpS/GbCnoAPwakXjTT/teVSLw1AkJ?=
 =?iso-8859-1?Q?nSt/CTDkNaJ9JIUKcqT8WCYyuUu2DURcpVOpR+1fDzIB35hGOWQjhi0AT1?=
 =?iso-8859-1?Q?yL7YT2JnDk3DCX1FbFGkHsVWR04gGkbCFlpEyVzbVOLz621ScKBrwggoJr?=
 =?iso-8859-1?Q?4hGTbfSOHNurBOnE/IxMqD7C88Bs1x05qhZOAa9e2ehNdUU+AJvON/8Cb3?=
 =?iso-8859-1?Q?AcU5Vr+1zddkYCuMpMuUOpTqO8ECF1D+L73cuUu5Avf3g/HEWLP5nW/HEt?=
 =?iso-8859-1?Q?08ZK3bifhgnh2znumhOA7C+GKfjXvumHvUc9sa0tVgOr8x1k7dvbi7S38t?=
 =?iso-8859-1?Q?37M2KM5ie29iz8OiODjsk7RKfYMQgd3TD/KXfyN1r/nioEs+AXxN+xUXxu?=
 =?iso-8859-1?Q?J9Co67luaBv/YDlJVfL292H2yvcIDIDXtWxlSQ0PxyF3lwCqRu2doRkPSs?=
 =?iso-8859-1?Q?QTp+Vyxf3X+4w4Fk+KRw4ruxCbin1XUd8VM7pIsRg86CpFPN9b7lWpIDAN?=
 =?iso-8859-1?Q?/0T7QBpuBSe2DFi3GSLWdlenLf+CwYa+MfMRUjhKD5Vh8Ptw85vp9TRtel?=
 =?iso-8859-1?Q?a8u3HEVlkVmC4OP+R3YfVoE7PZ9tRsqzPxRyNSMKBSzKqKW9mSaK1n1Pxh?=
 =?iso-8859-1?Q?kaRZ9X96AZ8l/WtT2c3yzbYirJM8ayU7+XT3fraOASImswZQzTk+N4cBij?=
 =?iso-8859-1?Q?aU8aurIWBHBnx6BO9fdU07slTGTM9HAjXURGZy6VoICZ4MTINDXpN3rB+N?=
 =?iso-8859-1?Q?/CldQEx6blYDGlmooon7DUkAO1fPRPKNKCtgIpr/lZLgGa42RBAa0LFCZ0?=
 =?iso-8859-1?Q?gY3FrzlXAuMSr4PJik/g37rzeVyKEYJx/T24XlqMHOAIbef+tmk/IxYrXT?=
 =?iso-8859-1?Q?qfjqheQYFSyhwOSrzysnLeNvxnTbdSJGkHWIAh3+nd92ArpJ6T0lPYPPRk?=
 =?iso-8859-1?Q?uXbny86U1HbsBY5ibxiHPzBGp+TalwABiiAdmbpGJl/Q1ktIYTt9yvo8T1?=
 =?iso-8859-1?Q?Ys9DlrKjzVe1Vwvb/P79zYA+gFNWiStgEkdfHvKEY6zqmVoaUwqqgXSApj?=
 =?iso-8859-1?Q?92GIixOAhty/AFLLQhXu8C9IHu06n/HVZ7fwMfU0al7Kn3xRhJCRd+07Jp?=
 =?iso-8859-1?Q?c=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?xZ128+rPSw8K2EvKIw5a8uaYM9e4GdKOYll0AJ87uVsGaPZ/cDxp4BeABC?=
 =?iso-8859-1?Q?EWkiXojaIhQBXjal1j3InLMjB8mflmqhrAJB79W0HcdRriXHKiJf3LzVup?=
 =?iso-8859-1?Q?ktDXZ6v9EqnLLqGmGcT76wb+f2zGLNGC+sC2nbt909geNoCtvlKEbd9W/L?=
 =?iso-8859-1?Q?NdSzDBAfMVrGrLGqLMxUZ/2Jgz0XdfBzIVmXk2lQyCmPGeCDr9svQNrRWw?=
 =?iso-8859-1?Q?XR7Gu9lxLHyaIC2+SztnvG6YHAqyW+yRWRVxCgvA2eT9Fv3Ki6PjJzwXDR?=
 =?iso-8859-1?Q?RhGPGuZWUtW7Rh1nGsn+OD0i9SnmhyDPuL24a4LH0XcXq0Lesb0SOqlD8U?=
 =?iso-8859-1?Q?Cti3Q76bA7n4LT/dlCi6eGD2+6rPOjU/Ez6Gepek6EdR4cX9BlI2tsxiuw?=
 =?iso-8859-1?Q?7kkQSQS3U1TEAa+iYd2KeRJx5vSo3pDSpGR9r6xBYUt5Gm3EyvQ9K2l4qF?=
 =?iso-8859-1?Q?TcNdsFowMYV6Moov+jUHW1i2r6K4lHVvrEUH6ohxuWp4Y+n+e5VH+x54kJ?=
 =?iso-8859-1?Q?r+zXEnhY45fkqPR5WP8ouBdLCX7D1LN8PN1moDTVEjiH/LnOwwBy2aeRUI?=
 =?iso-8859-1?Q?+csWC2l5ng7SK4TIWOEp9djwndN7ech3e5Qqhth/Gl81q+t3mxlvd2yBZg?=
 =?iso-8859-1?Q?beBKFEw9/zH/wePvfo3uankCnkBVSzdnzafbcicFCzmVmgjjJR1DIfxUlS?=
 =?iso-8859-1?Q?+Kdt4q16g30IDRPUviiCy8kmhPd4XLX6+BvHJ5o3TM39h0RBP9NtLvxteu?=
 =?iso-8859-1?Q?8OqqKywuMda68+TAu25RV/l4kOxPGzNinpz8eQ7QFDjXI29S3B9RREkbOK?=
 =?iso-8859-1?Q?7XlXstgUAz+r2bvMU+a8YFIw3/Hbziehw/JLYV9Gl7xEu04hlsdzG8aT5l?=
 =?iso-8859-1?Q?d8Ifs1hfe7Q2SZQBhTKnVGfzr5l+BkJkb2KhWbWeocooBbgfeuBSbYJGRN?=
 =?iso-8859-1?Q?Mx1yD6DX4z6fuiKm3a5KJ6p4Jjz+MVm+RKuio+rrna8A7HKFG4RsYNoWxb?=
 =?iso-8859-1?Q?OombYBZxcREvtl6D7pCUY6/FeiOSdImotHBFom1W0YosKMnV8hyxJhyVad?=
 =?iso-8859-1?Q?GzYTCD8/Jv9F7t2Z5POx5ykheuvO6yFkjfIeks2J+IkIBOMKWMAasDgIiH?=
 =?iso-8859-1?Q?pk/EBMXm5ETjj+FNVLGorJcziOME8VJdd/uDMYeohksQQcvbptRtad/9lv?=
 =?iso-8859-1?Q?TCzwVWrAoqFMtOmjxDfZWHyDlu6linrmU9rtC5OP4HGiQXoqPb7VL8/A/o?=
 =?iso-8859-1?Q?r6/ZxMddqtiqxDLWtqUFYAAMAjcX75kR+m4eH3rlawtJc5jFzCFtU/abPZ?=
 =?iso-8859-1?Q?18oiJv0xQar0SjZK3e+99wPpZUVgtNS5dZlpmRZe8/aKvNRe9wMRtPX/l2?=
 =?iso-8859-1?Q?Qd4hhBcThZGFbGtatdea4wGhbdyNuoJ8yELEHKv3WZOaVU5j5IXdMatMHf?=
 =?iso-8859-1?Q?M6lMyQKLZOvOAjqz2pJZMhnp2iwzl8R0flc/3EofSpGYwjD2jDvZLeDuyT?=
 =?iso-8859-1?Q?y0VlfKSmEXBiWb2Twkurr1BDjvhBrcSpp/LXeHXxKXKJhFNZXTApCaeZHo?=
 =?iso-8859-1?Q?SCgyio3fvw1hp9y+zcPp5+gp7QIGCNK4sef8SlfkV2yHh6iizrgG708mfk?=
 =?iso-8859-1?Q?sixfYtq/iKuxi9gY9DO27S8mAcjA7woVwp8qtTfd2x45rTb49Aovyrjg?=
 =?iso-8859-1?Q?=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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 33e991e4-a9a5-4dc6-930f-08dd96ecf219
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 15:50:57.0715
 (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: AR9ArqN9KAA43NJygCAs3IXpDgiZpyigFnGBsRgaX0dWWnz9pdY+3YRyFO5P9jJHwmaMdv7Frw+WNXP3AUH5azjxCT3uOXH/yetLS1b1MV8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9023

From: Grygorii Strashko 

Add documentation section for Simple Arm SCMI over SMC/HVC calls forwarding
driver (EL3).

Signed-off-by: Grygorii Strashko 
Signed-off-by: Oleksii Moisieiev 
---



 .../arm/firmware/arm-scmi.rst                 | 177 ++++++++++++++++++
 docs/hypervisor-guide/arm/index.rst           |   9 +
 docs/hypervisor-guide/index.rst               |   1 +
 3 files changed, 187 insertions(+)
 create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi.rst
 create mode 100644 docs/hypervisor-guide/arm/index.rst

diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervi=
sor-guide/arm/firmware/arm-scmi.rst
new file mode 100644
index 0000000000..bf6a458a6a
--- /dev/null
+++ b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst
@@ -0,0 +1,177 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+ARM System Control and Management Interface (SCMI)
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
+
+The System Control and Management Interface (SCMI) [1], which is a set of =
operating
+system-independent software interfaces that are used in system management.=
 SCMI currently
+provides interfaces for:
+
+- Discovery and self-description of the interfaces it supports
+- Power domain management
+- Clock management
+- Reset domain management
+- Voltage domain management
+- Sensor management
+- Performance management
+- Power capping and monitoring
+- Pin control protocol.
+
+The SCMI compliant firmware could run:
+
+- as part of EL3 secure world software (like Trusted Firmware-A) with
+  ARM SMC/HVC shared-memory transport;
+- on dedicated System Control Processor (SCP) with HW mailbox shared-memor=
y transport
+
+The major purpose of enabling SCMI support in Xen is to enable guest domai=
ns access to the SCMI
+interfaces for performing management actions on passed-through devices (su=
ch as clocks/resets etc)
+without accessing directly to the System control HW (like clock controller=
s) which in most cases
+can't shared/split between domains. Or, at minimum, allow SCMI access for =
dom0/hwdom (or guest
+domain serving as Driver domain).
+
+The below sections describe SCMI support options available for Xen.
+
+[1] `Arm SCMI `_
+
+Simple SCMI over SMC/HVC calls forwarding driver (EL3)
+------------------------------------------------------
+
+The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is pret=
ty generic case for
+the default vendors SDK and new platforms with SCMI support. Such EL3 SCMI=
 firmware supports only
+single SCMI OSPM transport (agent) with Shared memory based transport and =
SMC/HVC calls as doorbell.
+
+The SCMI over SMC/HVC calls forwarding driver solves major problem for thi=
s case by allowing
+SMC/HVC calls to be forwarded form guest to the EL3 SCMI firmware.
+
+By default, the SCMI over SMC/HVC calls forwarding is enabled for Dom0/hwd=
om.
+
+::
+
+    +--------------------------+
+    |                          |
+    | EL3 SCMI FW (TF-A)       |
+    ++-------+--^--------------+
+     |shmem  |  | smc-id
+     +----^--+  |
+          |     |
+     +----|-+---+---+----------+
+     |    | |  FWD  |      Xen |
+     |    | +---^---+          |
+     +----|-----|--------------+
+          |     | smc-id
+     +----v-----+--+ +---------+
+     |             | |         |
+     | Dom0/hwdom  | | DomU    |
+     |             | |         |
+     |             | |         |
+     +-------------+ +---------+
+
+
+The SCMI messages are passed directly through SCMI shared-memory (zero-cop=
y) and driver only
+forwards SMC/HVC calls.
+
+Compiling
+^^^^^^^^^
+
+To build with the SCMI over SMC/HVC calls forwarding enabled support, enab=
le Kconfig option
+
+::
+
+    CONFIG_SCMI_SMC
+
+The ``CONFIG_SCMI_SMC`` is enabled by default.
+
+Pass-through SCMI SMC to domain which serves as Driver domain
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This section describes how to configure the SCMI over SMC/HVC calls forwar=
ding driver to handle use
+case "thin Dom0 with guest domain, which serves as Driver domain". In this=
 case HW need to be
+enabled in Driver domain and dom0 is performing only control functions (wi=
thout accessing FW) and so,
+the SCMI need to be enabled in Driver domain.
+
+::
+
+     +--------------------------+
+     |EL3 SCMI FW (TF-A)        |
+     |                          |
+     +-------------^--+-------+-+
+             smc-id|  |shmem0 |
+                   |  +----^--+
+    +-------------++------+|----+
+    |Xen          |  FWD  ||    |
+    |             +--^----+|    |
+    +----------------|-----|----+
+              smc-id |     |
+    +-----------+ +--+-----v-----+
+    |           | |              |
+    | Dom0      | |    Driver    |
+    | Control   | |    domain    |
+    |           | |              |
+    +-----------+ +--------------+
+
+The SCMI can be enabled for one and only one guest domain.
+
+First. configure Dom0 to enable SCMI pass-through using Xen Command Line
+**"dom0_scmi_smc_passthrough"** option. This will disable SCMI for Dom0/hw=
dom and SCMI nodes will
+be removed from Dom0/hwdom device tree.
+
+**Configure SCMI pass-through for guest domain with toolstack**
+
+* In domain's xl.cfg file add **"arm_sci"** option as below
+
+::
+
+    arm_sci =3D "type=3Dscmi_smc"
+
+* In domain's xl.cfg file enable access to the "arm,scmi-shmem"
+
+::
+
+    iomem =3D [
+        "47ff0,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:
+
+.. 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";
+                    shmem =3D <&scmi_shm_0>;
+                    ...
+                }
+        }
+    }
+
+In general, the configuration is similar to any other HW pass-through, exc=
ept explicitly
+enabling SCMI with "arm_sci" xl.cfg option.
+
+**Configure SCMI pass-through for predefined domain (dom0less)**
+
+* add "xen,sci_type" property for required DomU ("xen,domain") node
+
+::
+
+       xen,sci_type=3D"scmi_smc"
+
+* add scmi nodes to the Driver domain partial device tree the same way as =
above and enable access
+  to the "arm,scmi-shmem" according to  dom0less documentation. For exampl=
e:
+
+.. code::
+
+      scmi_shm_0: sram@22001000 {
+            compatible =3D "arm,scmi-shmem";
+            reg =3D <0x00 0x22001000 0x00 0x1000>;
+    ->        xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>;
+    ->        xen,force-assign-without-iommu;
+      };
diff --git a/docs/hypervisor-guide/arm/index.rst b/docs/hypervisor-guide/ar=
m/index.rst
new file mode 100644
index 0000000000..7aae4a0a03
--- /dev/null
+++ b/docs/hypervisor-guide/arm/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+ARM
+=3D=3D=3D
+
+.. toctree::
+   :maxdepth: 2
+
+   firmware/arm-scmi
diff --git a/docs/hypervisor-guide/index.rst b/docs/hypervisor-guide/index.=
rst
index e4393b0697..520fe01554 100644
--- a/docs/hypervisor-guide/index.rst
+++ b/docs/hypervisor-guide/index.rst
@@ -9,3 +9,4 @@ Hypervisor documentation
    code-coverage
=20
    x86/index
+   arm/index
\ No newline at end of file
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon May 19 15:51:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:51:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989960.1373921 (Exim 4.92)
	(envelope-from )
	id 1uH2lb-0005Jb-N4; Mon, 19 May 2025 15:51:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989960.1373921; Mon, 19 May 2025 15: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 1uH2lb-0005JR-Jq; Mon, 19 May 2025 15:51:03 +0000
Received: by outflank-mailman (input) for mailman id 989960;
 Mon, 19 May 2025 15:51:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2la-00055d-Lh
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:51:02 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20625.outbound.protection.outlook.com
 [2a01:111:f403:260e::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1008bc5b-34c9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 17:51:01 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB9023.eurprd03.prod.outlook.com (2603:10a6:20b:5b7::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.29; Mon, 19 May
 2025 15:50:57 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8722.031; Mon, 19 May 2025
 15:50: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" 
X-Inumbo-ID: 1008bc5b-34c9-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nyLDAoIahHy3xrUhup8FivNBw6/vv1fgnmocpFcmatiuFnFFTbfOZk5//Ynf/ejappjOktwVhcv5V5c1GHKK0Dw/lKgsuJgCCcFvA8mygygUskMih0TlL1OAYCHTYMvqWzcsuNmm20YLfoA1EMJKMcdilJCctv1923ugi3lhLG9hLrSupuKLzranfGR310+LY1Mr618ueF4JPjrFuUz86daqncC5o55mjI/9wesi3hwPDymLPgO3ivR5xIGgi0xF5KSx9oC5qSU4L6Rc6ChMnXMBjgm1/zq3kK/1LAJtzH0QJ6PZniOx5UO15gKyvOSVdGr8WXjOUl3xM7auWfwKBw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Fk5Gs0tS92nr5rjRn//mXLL1DtK3sxSAdDHVHneMlgQ=;
 b=PYEWSQpruE9CrzMnBu/nkOUGv3dg4+7+WGDyAjVnJbsIMNA2VFz55Z04eHvkSj04VC74cRtrzAn+TXRFcC556LnQlEKZKZg8RoKWlUGede6j15hiczJZUOH2gRhsHCyZjMmR4oVB8A+Ksd2u4QUk7SVic8p7FOcJo19jp42hXm8QWiyteLMpLTywdyzpdQPbnu808a0uM4hpf332tkoWaNoLFOVO+nheQtdWABzIRD22mMtfQj+L96ig+DqmWJJKfWr7Ea0XkoRiLrMbZAQqJYgSVR802byUeLJEcnFOpflLmSqRh0HhzeUQQnYI0EcxuZ/5cxxdCoCcEsjA+kajEA==
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=Fk5Gs0tS92nr5rjRn//mXLL1DtK3sxSAdDHVHneMlgQ=;
 b=CyzM5+tHsZu/GgQPVatc68oxjaAVk4gash6tLbEuR8+Vg0I0+5Db5u2MQV2DqmZer9QVXhFKxLF0jZT2pNGM/sxxY7u34OuRmgaJbJCEt85hRibOhwFqc0jtCkEfv1o6qVDl4tVw0nLfdH8aiSECtbU+nhLOmd639b/szx8RLOZXQAFadr5nqfe66Ryvt+PaUKMuWr00Jgi+THtoiQIYX3JnDzDH8nq61ZxOTLC1MWAHiQxuCOUKE1UgUfPX4K1jLWddl/Y7MKxfRnSVioj1zTI2d8ZVGK+S2tmXDmwY4VWCFhG4QqRapqtNSSf4QjN7OEpCeIIaMik9U2HE7gQVbg==
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: [RFC PATCH v4 2/8] xen/arm: scmi-smc: update to be used under sci
 subsystem
Thread-Topic: [RFC PATCH v4 2/8] xen/arm: scmi-smc: update to be used under
 sci subsystem
Thread-Index: AQHbyNXPRF0tCFj/sEGmRLZ+kuwLjw==
Date: Mon, 19 May 2025 15:50:56 +0000
Message-ID:
 <21bdecf961b60fb0094b1f722444a45228aef878.1747669845.git.oleksii_moisieiev@epam.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB9023:EE_
x-ms-office365-filtering-correlation-id: 2d345ae3-acfd-44a4-d9f7-08dd96ecf1cb
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?ZZEf7nhsvJc4orGtNmwSE3GYCpExG7xmMdr/9yp0koxdtuO4QMahIH4/o+?=
 =?iso-8859-1?Q?LnyPJA8ZChNu1FbOQ5WqdM4X1JsXqIWFoEDzA5vfCUhiBheP1ume79o6me?=
 =?iso-8859-1?Q?QCst1GXZxCXG4bhP7Kbr8CvcVFJE+p61RvnKXZjDt/gO45qfa9JlJ+pHC6?=
 =?iso-8859-1?Q?txMBr2s3iBI73qJTMN1gpKw8kt8es5FEKCNVjgKp/0wzAwbTH6T8TnAs8U?=
 =?iso-8859-1?Q?TGGSCcNi9jq8D9SIOFR14A1kdqNTe2kaRS9h1GypkUhN+gEUvC8YUwqqdE?=
 =?iso-8859-1?Q?e5XdEJWX9NofgcQAV0aSk8/Z713yOZPJp/OtpKN4ALJy55Ithqa2Re2/tF?=
 =?iso-8859-1?Q?tJXVfy1GpvYfqYNnFU6pK7icMJ0/7i9M7HQK37qvqTo5gtfdXTryLcU3xs?=
 =?iso-8859-1?Q?0ORi/wvBwOaejRknAZ6kCJOYEbW6KlSUmHOLZmi71mW6oKBusZxqPjPBYT?=
 =?iso-8859-1?Q?ertn3/1CYTK+3HfvSffQATOjtc2PHzC0z8dEx63qBwzjjDDKRqDyZn3Msy?=
 =?iso-8859-1?Q?8vWnySqiBmp5bcLfWRMH+As0tj+/kpgmCPcuALM3pbvNpHVXfzHnaeishQ?=
 =?iso-8859-1?Q?mMrj+KvFsdggCEQx/WFM/4l8M6ylI7GhJwCq+3yCNb8wJSRBp1m00WP/mN?=
 =?iso-8859-1?Q?7WT+HZUMsfhQACNJC1is/nMZcfQvvebAJ5m9VUG3c5phHjNEd63Tt3R1yT?=
 =?iso-8859-1?Q?uuu6UxpkZz9h9tVcShaLogwpVAyXgj9pZI6TB4fpfSOyoYKgiBUvEaW24F?=
 =?iso-8859-1?Q?om3PwezHe68oHLmtBwzDvI3GQqJSaJfnDi+3QUAOKq5vqld4vXEtMyIpLv?=
 =?iso-8859-1?Q?1WUfNcbawfUVzWdLrOk0FKdhrMeSPeBDMJeml94mTVZPEtX8KO5yrhEAxY?=
 =?iso-8859-1?Q?tcVbUzeCaHlrF0xD8liNZ3ZdK+u/NEQb95lufCMyR0tAr3o6Kdk0R85YuY?=
 =?iso-8859-1?Q?NjYfSoo6U4yYCkp9dWyOaEigxf9wC9vujpy4cQ2jao2+ue1FVfYRqCAdtn?=
 =?iso-8859-1?Q?1sevP33tkea1/mCWjJpDAZLg1h9IAImrk0KjppAGgqy+vqLUpUrMzkW/VT?=
 =?iso-8859-1?Q?cVdxfW2huqaw/AFBGbwL95w8K9WOUvGxsKIS6rUG+6X4Pd6+MJy4RoF2xy?=
 =?iso-8859-1?Q?sp6AJI5lCfC/N25UTIfFAPwUurMtag5esDrwHQv7NpnQXid6jA3RtA58Vb?=
 =?iso-8859-1?Q?6v+Af+Ub7UmAKwhe7su1JgdgCJ3IT+bfZxOWbWOuVr2kHyKG+F4kMSrOft?=
 =?iso-8859-1?Q?NlB46ohAu6RuoomgfGnsp3qEN7cujBBQZ/WVk+uLuenUm4LKvvBG0CVuWj?=
 =?iso-8859-1?Q?ZsEPpRoMI5jI7U9mSwpz9tDZDOeRnHGGDPcEARUP+o9QdU/7t7JHOYgX0n?=
 =?iso-8859-1?Q?qI78jSPftiM6RD5A2lPeadU0j1Uol9GzrKru+LoK3KFvi42zV3ruFviafj?=
 =?iso-8859-1?Q?W3xCIb3hENc2EdX1v6YlMfTJ88pMDmoG8QNxxp4TsV0Cl5phdQEoZAF6c/?=
 =?iso-8859-1?Q?mIdMAPcrwS73XIXb1CNGr4pbtCACTJPNeNgDPuOPFdYJH1v22jE03rT/a0?=
 =?iso-8859-1?Q?d4GmQPc=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?uXO2gwt9+dnb2bkxFIQOYIBXsg09mwXvFfegzKOnWJFSNp4XXDrT8cycD0?=
 =?iso-8859-1?Q?PJ5vGbF4/7XYLXWkBp4wUt01rJpHCLE1QQwy9z9yFbvh3bo984DAylIXIG?=
 =?iso-8859-1?Q?W9sYR4IjPlN+yZ0eGJDz0A6BIpP4M0Gz8+h3dq5gpyeOjSPYGOlhSJvxC1?=
 =?iso-8859-1?Q?BFEmZZ05YGPPGghLbRu5pgRQsIZD+ooUhQxK17HQ2xDPRTQR1c7L8eCiJ0?=
 =?iso-8859-1?Q?XSmq5AYp3ENRQXNq3O1D2bCDEuaYW786jvwj1+tnGO9xQchNg7PFz3LAgj?=
 =?iso-8859-1?Q?YAW664LSKi2//ax2hL983XbU2REI7fpYr9mrsDv/v7v/WXrG4WQeCx0oy6?=
 =?iso-8859-1?Q?J4qGfjeYl9LUQbw+vm63WtFRa3xsW5RRuqEaDzVyg+n2drgaw05JD/Al02?=
 =?iso-8859-1?Q?JHElecsPcDmyDGZ0Q33WzdVoHfG1m2t/JpfG5ocavEseSWd9xs0NxNk/Um?=
 =?iso-8859-1?Q?G4gucwdITr3QjNFgZHnuRHokRurz1VtrOYQak5PZ8wUvuVz2dz2nDK3jWw?=
 =?iso-8859-1?Q?5/0TEul9/N+SjE0wwRAA3VI2MlH+oPYBN3+F5Ip9JdArXBQnRY9PhxI1NA?=
 =?iso-8859-1?Q?dvx+H534ZWjCHopY7tFcGtVT3bYd+Dl5Fn68fhEpe9/TQ6CsXHOcEOZe34?=
 =?iso-8859-1?Q?ypeh0U4KrrwUG/WzmUHSN5Ys51LvRanI0/Skn9ycvZrz5f9eeLtUoMvymS?=
 =?iso-8859-1?Q?9wQIBrWTBW7jJNj52u6vRjUR6AX0PYAmPTPPBZnUOeEga+mzgRaPxKiqR3?=
 =?iso-8859-1?Q?Swsf2EQgTj5yc7L7wZxDL0DRQ4OIQV9KgD449Afqa8IfmjraXSUWlUvkQN?=
 =?iso-8859-1?Q?mWB9OXgBXkPG7c0amOtCoOqAEFb6jAdD69ZK6zIeEG02l/QrunKAtupuGL?=
 =?iso-8859-1?Q?bEXjpDQp7dXUFSwGKe1pVz8TM4QHGwW8Qn7oLOeROdkTsdLRWULSun9pdT?=
 =?iso-8859-1?Q?l9Stp+TC8Pk96X30gUQC8NdLCmnQT+JkNQ/BFtfXUW1o2c+7p7qNCGSJP2?=
 =?iso-8859-1?Q?Kc1CSIKP9dfZmVpTg2LmMH2DidbrutTyR1ZNZnMzLq9g+zjs0GMvZj4SbS?=
 =?iso-8859-1?Q?i6u7U4snM0Pn8LaJE15GpXSk9PePLRc0G749IB2iqfSq3ZaZ0IWPzDh87P?=
 =?iso-8859-1?Q?EFn6UFqXOkeBmCPLAwhqdifhxEZXXqt1hvtK2isHOlY52BzK5pg/jdKjRC?=
 =?iso-8859-1?Q?YTog8BIJkcNrPNymIRLqQIVFkfYPKzc05HDMKZsUmz3uajrxy6eLbrqulY?=
 =?iso-8859-1?Q?fidSZy6PzbCEzoKkVG1jurPKroKRWXv2/c2KzIhn5lw/+FdnH1DX6I19QJ?=
 =?iso-8859-1?Q?bPI0OY7ipzR/TVeMYIbm3v6b3Bpz2qsYQHdksCePfndH7VmfjI4GZ3xK/h?=
 =?iso-8859-1?Q?iMZpZSIfLoGFp0QRhHGzw8DqErQuIBOjHCvb1+MnjPbCSdg3EyV+R/S1IR?=
 =?iso-8859-1?Q?PM1AvtRPQbj4wlYnHhZYjrQayBkcPeCtiHtxxfdzADb8oHN3OYtqMyEpGZ?=
 =?iso-8859-1?Q?xydB7M4A1hbncEitruE+oox+jL1hFtEq1vDopVcVsZiHhidz7486yApPCh?=
 =?iso-8859-1?Q?3SHhHemJWNPtAVViyURduq/67bs1o/4WDMLXoZLGqlXEJlh/jYz9fVsT9F?=
 =?iso-8859-1?Q?MA4lzOLLpS9QDnDvMQU+d67lAphj1XgCbAe0Rf4m3F24tcfh57uYKaOA?=
 =?iso-8859-1?Q?=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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d345ae3-acfd-44a4-d9f7-08dd96ecf1cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 15:50:56.4809
 (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: ZFLy79QpGYhsxpLOEcw4g1j9kKyl+veX1ge3CfyuiNnX7+NJiz68EiOuDvR72pK7DKmW1d9KdAz3yjW/d29T78EpRmcKDI4nN1mzgTqp3Uc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9023

From: Grygorii Strashko 

The introduced SCI (System Control Interface) subsystem provides unified
interface to integrate in Xen SCI drivers which adds support for ARM
firmware (EL3, SCP) based software interfaces (like SCMI) that are used in
system management. The SCI subsystem allows to add drivers for different FW
interfaces or have different drivers for the same FW interface (for example=
,
SCMI with different transports).

This patch updates SCMI over SMC calls handling layer, introduced by
commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls handling
layer"), to be SCI driver:
- convert to DT device;
- convert to SCI Xen interface.

There are no functional changes in general, the driver is just adopted
to the SCI interface.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Oleksii Moisieiev 
---



 xen/arch/arm/firmware/Kconfig                | 13 ++-
 xen/arch/arm/firmware/scmi-smc.c             | 93 +++++++++++---------
 xen/arch/arm/include/asm/firmware/scmi-smc.h | 41 ---------
 xen/arch/arm/vsmc.c                          |  5 +-
 xen/include/public/arch-arm.h                |  1 +
 5 files changed, 64 insertions(+), 89 deletions(-)
 delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h

diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
index fc7918c7fc..bbf88fbb9a 100644
--- a/xen/arch/arm/firmware/Kconfig
+++ b/xen/arch/arm/firmware/Kconfig
@@ -8,9 +8,18 @@ config ARM_SCI
=20
 menu "Firmware Drivers"
=20
+choice
+	prompt "ARM SCI driver type"
+	default SCMI_SMC
+	help
+	Choose which ARM SCI driver to enable.
+
+config ARM_SCI_NONE
+	bool "none"
+
 config SCMI_SMC
 	bool "Forward SCMI over SMC calls from hwdom to EL3 firmware"
-	default y
+	select ARM_SCI
 	help
 	  This option enables basic awareness for SCMI calls using SMC as
 	  doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
@@ -18,4 +27,6 @@ config SCMI_SMC
 	  firmware node is used to trap and forward corresponding SCMI SMCs
 	  to firmware running at EL3, for calls coming from the hardware domain.
=20
+endchoice
+
 endmenu
diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-=
smc.c
index 33473c04b1..13d1137592 100644
--- a/xen/arch/arm/firmware/scmi-smc.c
+++ b/xen/arch/arm/firmware/scmi-smc.c
@@ -9,6 +9,7 @@
  * Copyright 2024 NXP
  */
=20
+#include 
 #include 
 #include 
 #include 
@@ -16,12 +17,11 @@
 #include 
 #include 
=20
+#include 
 #include 
-#include 
=20
 #define SCMI_SMC_ID_PROP   "arm,smc-id"
=20
-static bool __ro_after_init scmi_enabled;
 static uint32_t __ro_after_init scmi_smc_id;
=20
 /*
@@ -41,14 +41,11 @@ static bool scmi_is_valid_smc_id(uint32_t fid)
  *
  * Returns true if SMC was handled (regardless of response), false otherwi=
se.
  */
-bool scmi_handle_smc(struct cpu_user_regs *regs)
+static bool scmi_handle_smc(struct cpu_user_regs *regs)
 {
     uint32_t fid =3D (uint32_t)get_user_reg(regs, 0);
     struct arm_smccc_res res;
=20
-    if ( !scmi_enabled )
-        return false;
-
     if ( !scmi_is_valid_smc_id(fid) )
         return false;
=20
@@ -78,49 +75,45 @@ bool scmi_handle_smc(struct cpu_user_regs *regs)
     return true;
 }
=20
-static int __init scmi_check_smccc_ver(void)
+static int scmi_smc_domain_init(struct domain *d,
+                                struct xen_domctl_createdomain *config)
 {
-    if ( smccc_ver < ARM_SMCCC_VERSION_1_1 )
-    {
-        printk(XENLOG_WARNING
-               "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled=
\n");
-        return -ENOSYS;
-    }
+    if ( !is_hardware_domain(d) )
+        return 0;
=20
+    d->arch.sci_enabled =3D true;
+    printk(XENLOG_DEBUG "SCMI: %pd init\n", d);
     return 0;
 }
=20
-static int __init scmi_dt_init_smccc(void)
+static void scmi_smc_domain_destroy(struct domain *d)
 {
-    static const struct dt_device_match scmi_ids[] __initconst =3D
-    {
-        /* We only support "arm,scmi-smc" binding for now */
-        DT_MATCH_COMPATIBLE("arm,scmi-smc"),
-        { /* sentinel */ },
-    };
-    const struct dt_device_node *scmi_node;
-    int ret;
+    if ( !is_hardware_domain(d) )
+        return;
=20
-    /* If no SCMI firmware node found, fail silently as it's not mandatory=
 */
-    scmi_node =3D dt_find_matching_node(NULL, scmi_ids);
-    if ( !scmi_node )
-        return -EOPNOTSUPP;
+    printk(XENLOG_DEBUG "SCMI: %pd destroy\n", d);
+}
=20
-    ret =3D dt_property_read_u32(scmi_node, SCMI_SMC_ID_PROP, &scmi_smc_id=
);
-    if ( !ret )
+static int __init scmi_check_smccc_ver(void)
+{
+    if ( smccc_ver < ARM_SMCCC_VERSION_1_1 )
     {
-        printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT nod=
e\n",
-               SCMI_SMC_ID_PROP, scmi_node->full_name);
-        return -ENOENT;
+        printk(XENLOG_WARNING
+               "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled=
\n");
+        return -ENOSYS;
     }
=20
-    scmi_enabled =3D true;
-
     return 0;
 }
=20
+static const struct sci_mediator_ops scmi_smc_ops =3D {
+    .handle_call =3D scmi_handle_smc,
+    .domain_init =3D scmi_smc_domain_init,
+    .domain_destroy =3D scmi_smc_domain_destroy,
+};
+
 /* Initialize the SCMI layer based on SMCs and Device-tree */
-static int __init scmi_init(void)
+static int __init scmi_dom0_init(struct dt_device_node *dev, const void *d=
ata)
 {
     int ret;
=20
@@ -134,22 +127,36 @@ static int __init scmi_init(void)
     if ( ret )
         return ret;
=20
-    ret =3D scmi_dt_init_smccc();
-    if ( ret =3D=3D -EOPNOTSUPP )
-        return ret;
+    ret =3D dt_property_read_u32(dev, SCMI_SMC_ID_PROP, &scmi_smc_id);
+    if ( !ret )
+    {
+        printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT nod=
e\n",
+               SCMI_SMC_ID_PROP, dt_node_full_name(dev));
+        return -ENOENT;
+    }
+
+    ret =3D sci_register(&scmi_smc_ops);
     if ( ret )
-        goto err;
+    {
+        printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %d)\=
n",
+               ret);
+        return ret;
+    }
=20
     printk(XENLOG_INFO "Using SCMI with SMC ID: 0x%x\n", scmi_smc_id);
=20
     return 0;
-
- err:
-    printk(XENLOG_ERR "SCMI: Initialization failed (ret =3D %d)\n", ret);
-    return ret;
 }
=20
-__initcall(scmi_init);
+static const struct dt_device_match scmi_smc_match[] __initconst =3D {
+    DT_MATCH_COMPATIBLE("arm,scmi-smc"),
+    { /* sentinel */ },
+};
+
+DT_DEVICE_START(scmi_smc, "SCMI SMC DOM0", DEVICE_FIRMWARE)
+    .dt_match =3D scmi_smc_match,
+    .init =3D scmi_dom0_init,
+DT_DEVICE_END
=20
 /*
  * Local variables:
diff --git a/xen/arch/arm/include/asm/firmware/scmi-smc.h b/xen/arch/arm/in=
clude/asm/firmware/scmi-smc.h
deleted file mode 100644
index 6b1a164a40..0000000000
--- a/xen/arch/arm/include/asm/firmware/scmi-smc.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * xen/arch/arm/include/asm/firmware/scmi-smc.h
- *
- * ARM System Control and Management Interface (SCMI) over SMC
- * Generic handling layer
- *
- * Andrei Cherechesu 
- * Copyright 2024 NXP
- */
-
-#ifndef __ASM_SCMI_SMC_H__
-#define __ASM_SCMI_SMC_H__
-
-#include 
-
-struct cpu_user_regs;
-
-#ifdef CONFIG_SCMI_SMC
-
-bool scmi_handle_smc(struct cpu_user_regs *regs);
-
-#else
-
-static inline bool scmi_handle_smc(struct cpu_user_regs *regs)
-{
-    return false;
-}
-
-#endif /* CONFIG_SCMI_SMC */
-
-#endif /* __ASM_SCMI_H__ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 51b3c02973..b33c69a1c2 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
=20
 /* Number of functions currently supported by Hypervisor Service. */
 #define XEN_SMCCC_FUNCTION_COUNT 3
@@ -233,7 +232,7 @@ static bool handle_sip(struct cpu_user_regs *regs)
     if ( platform_smc(regs) )
         return true;
=20
-    return scmi_handle_smc(regs);
+    return sci_handle_call(regs);
 }
=20
 /*
@@ -301,8 +300,6 @@ static bool vsmccc_handle_call(struct cpu_user_regs *re=
gs)
             break;
         case ARM_SMCCC_OWNER_SIP:
             handled =3D handle_sip(regs);
-            if ( !handled )
-                handled =3D sci_handle_call(regs);
             break;
         case ARM_SMCCC_OWNER_TRUSTED_APP ... ARM_SMCCC_OWNER_TRUSTED_APP_E=
ND:
         case ARM_SMCCC_OWNER_TRUSTED_OS ... ARM_SMCCC_OWNER_TRUSTED_OS_END=
:
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 55eed9992c..095b1a23e3 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -328,6 +328,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 #define XEN_DOMCTL_CONFIG_TEE_FFA       2
=20
 #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE      0
+#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC  1
=20
 struct xen_arch_domainconfig {
     /* IN/OUT */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon May 19 15:51:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:51:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989962.1373936 (Exim 4.92)
	(envelope-from )
	id 1uH2le-0005ck-Bb; Mon, 19 May 2025 15:51:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989962.1373936; Mon, 19 May 2025 15:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH2le-0005bx-8D; Mon, 19 May 2025 15:51:06 +0000
Received: by outflank-mailman (input) for mailman id 989962;
 Mon, 19 May 2025 15:51:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2ld-00055d-EW
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:51:05 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on20612.outbound.protection.outlook.com
 [2a01:111:f403:260c::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 11047c03-34c9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 17:51:03 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB9023.eurprd03.prod.outlook.com (2603:10a6:20b:5b7::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.29; Mon, 19 May
 2025 15:50:56 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8722.031; Mon, 19 May 2025
 15:50: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" 
X-Inumbo-ID: 11047c03-34c9-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=i9e9pUtkNdyQQ2vuBZGPSTatUP4QVa4nureL9CDHBZosASAjN25rFgyTfASzPCZgyd/xefeaSvm7u5UQDRwcJF5nBrFTAOZz7ccJf9Efws3e4x2PNghKeSf92e74cFBkN1y+t7ZGQUUcqkgHgFk/7tI6yBQpIlELT8FGEQsUm+XghjehAweZY6ot054Z76MS7Ow/WvEORl/HSXOj/F7QvF66C29G1YKXhH53/VUplr2f9z8vpv8s2AGXNVgsqjOhS/3W7UYaan6RoOG7fZhD/gBhYwlLIrLaPOLJHayyMMMpQTfGE+qh3Foru2xzoURSS45CUemnz7grMNJoByQ7Pg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GuRaKSb2E1086xvD0ZVG5GfhbsL6SY92mOveYINGGu8=;
 b=uyg0PNph68ansj5aYWlV03+TtFjBeudxE+QDDTWqLYcr8OUS8kt27eXHOXUSfpS6BdyfKaV2kSFCgfzmcB01480ptuvkJSX1r9KZLXZcnboNIriBRec5rGAXdT3Vs6u7fdaOD8REY7f3fQQpaziuGYLCpBXg7T2fDlQRmK9s+Cf8bGvD9ad/ywpJFxoQUrCuDSTnijeMEpuEbmSWpypcaLojkbR+RQvCP0wX1PxEU9IKSBsqDS7KA49vzPax7ah82S8KNXS4MMh5UEdYdAbOc6fmbEjf3DnVP3LKZgMbVTRWgKu/vvO31vMIiqxbdalSL4xtsRIOTQgvKR7pRM2tww==
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=GuRaKSb2E1086xvD0ZVG5GfhbsL6SY92mOveYINGGu8=;
 b=Z7SH5iP6W88/OMHeKK2oDQuHY1yd3oX59p1ybCeZVSq/XGlUbyPqlBoRGROa+MaRoflU/slQWDdHI42IlJWSrF3VOQBkftIxlLBsqxiBNzD/K/0hNs9Tww3xKqoA0YoVtD08ySRt+zrfAaslUF9UKuxoPQKP2hQkz5RqeuXeGG0qN5e0eVsDa8SBybue+qmOguM45q8tJuh8HSM5QzA5EDktkryEjy1lo4+BEpTMDyEVv4U2wxKJwkGRW7R8BMyRfshDupxnORUcaW63mmV9j8vrEdoQOGqpVzPba7/+wD0fs0nwCiGqTLxiAPDl0aS4wWi2OAf9PF71N6YFsgcSVw==
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: [RFC PATCH v4 1/8] xen/arm: add generic SCI subsystem
Thread-Topic: [RFC PATCH v4 1/8] xen/arm: add generic SCI subsystem
Thread-Index: AQHbyNXOqELJ9X0XaEyNPLqmNXa/uQ==
Date: Mon, 19 May 2025 15:50:56 +0000
Message-ID:
 <48b70b34c576d8dfcf6156d1997bc3c0f7cbbceb.1747669845.git.oleksii_moisieiev@epam.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB9023:EE_
x-ms-office365-filtering-correlation-id: 38b27eff-4e97-4ad9-f4cb-08dd96ecf1a4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?B4JgUr7hUJy44i0uFVHkp60oUcZIbSu3q8qfVpGGk1aGqcqIv1Cq/Hly6r?=
 =?iso-8859-1?Q?Vn1OInDADFVJR8jEDBMefemod8vVafktj0vv6QOY/9zEVfLonY3eQ+OHbJ?=
 =?iso-8859-1?Q?t4gHx5ShIxxqXMzoXtg9xqfwKu2eFa7+q+h+pkyG1Sggq90J7LxwdMGZ3i?=
 =?iso-8859-1?Q?6Xv1e8blGadjOkeVhFan8YWlWIqOpllazrZg0GnV8QDQ/eEbCZ1ZT9jaoQ?=
 =?iso-8859-1?Q?+BbuLkKEeK5/1auticE3IoZqF+tdguX9oTXhCFcSsdjRN0AFBlCJSQOEEw?=
 =?iso-8859-1?Q?n/CMszWq/HBkYPcM2sSvIg+SQm98n4ujnDMV82854udbNOlTH/bwzEn9f5?=
 =?iso-8859-1?Q?5GDehtuC41qTNbG3MmlvrNDCHpjrNrmscFXGJGsG5hPWOoJEZeWY51DAOZ?=
 =?iso-8859-1?Q?5QcAP16bDOCgjMar2CdTjDft0NjyNfOiDA0JVZkff+znWr+kifiVX0oTYZ?=
 =?iso-8859-1?Q?5CbialbivaLiyYYg3/Lw8PvvbOV9cNZrKj6qcEXefuiJRSh8HzOX729WbR?=
 =?iso-8859-1?Q?ZqSS3szz9+VpF+ua4RKfpYZhBmHHJLPWIKDmEjQ1O91XqhXH75w4BrAvo9?=
 =?iso-8859-1?Q?6GEf448DziHuG2NFkZU0xzqR8yubdSObSvXde8tWhyr7QWFvDS+BcL6Y+2?=
 =?iso-8859-1?Q?UhOTxLWaqGDNj1A+021oMSCq9r1IX5Lki6ONorHUS4lAZlmilWfzG2il9W?=
 =?iso-8859-1?Q?EmU6pbRYsBcSNp53F+iXigQ4gs60b5H/kFMBBJq/mH/GFYEAocxNVSzwh/?=
 =?iso-8859-1?Q?HFf60xgIuIQKWPa0wDxgZNijPmJsKqA3RsovbQkwz+i/LQW/pPyk8oY/KJ?=
 =?iso-8859-1?Q?Dr27utbsGvVO1ux1TnbFf6HAe4/a/1WSAH1qycNMrDwz2ZDKnaEvpk8vHq?=
 =?iso-8859-1?Q?rzo4wsLQZgDCICTk6ZVqf7Y/+GMtG2gFiUbZ6amWXIXtQu8nFEYzWodALl?=
 =?iso-8859-1?Q?7pGGDW/iWF2nJmXptq1eDIuxA2g9Dt/G5Zcb5S2bb/b/HxnmAS2m5racy8?=
 =?iso-8859-1?Q?S/IDhw3+y5zx2tc7wQulDmaut8p5GRHUaCA8KpCHLT+Rqd3o0VXcugDVL+?=
 =?iso-8859-1?Q?vXPrrbONbqR9RVvJRTLOPRsDBDC0OBl2g3/XdCPHtae+F3hC7j+50fVF4W?=
 =?iso-8859-1?Q?iyWzfIi8+hQc8nZxFu5LH6cpYbi/MBWS9M3NGGQkZmoUnJmahZyutLiWTR?=
 =?iso-8859-1?Q?C4igB+XJAte6R/bAcCR/kQwYOkCJkvmbr5qgU6WApQnZhXl1RmDk8RgUGC?=
 =?iso-8859-1?Q?CwUQ5TDJbKS3w+pL8dyJvm2MuKFmzidjCeDXjN1vAG5jy3XMFTu41c/pSs?=
 =?iso-8859-1?Q?t0y3XzT3R6mBmGGoNo/QWrR1rRSQdU/SnpqbRv8UUh9iON88mITnfDViD2?=
 =?iso-8859-1?Q?pwOgrcmoAWnc8gyebYJKM7qamaZVOC/A4loH09mrZbDlDQ0xajMHcMedg/?=
 =?iso-8859-1?Q?dpXnzIp4/Mdse5LnXdTv58/3ifORCm9EWLqUliU/1CSNbbNtfxsemIf6yM?=
 =?iso-8859-1?Q?w+JTaR0Hb7rRPe5iZ+2ZKCXnWC/nciugKE9VrDTI2GXbCBYmeH7366DmwX?=
 =?iso-8859-1?Q?sV/aVEs=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?pXfQZC2pgA2DrlsMeS/Wc18g7eAQRGE9Zk5vDvHxZKUIH5Q3Zzvr/K7Vds?=
 =?iso-8859-1?Q?OlJehgGEMUAJ/L5rZYARYW9jVcVeEDcyzWKNUQHTTS/3gagRW/h4ss8HNT?=
 =?iso-8859-1?Q?DjgM0rrQlSKsPkngcT0gaYJXpn+8rwJ7uX3bldXtOhVeqWKKFySYnqPetK?=
 =?iso-8859-1?Q?P8oBYdhGaGlz8EhNzScgVHwxXmIHcHIYZKlH9ggulR1FJSlYZK7UlNte1P?=
 =?iso-8859-1?Q?ZBvfyA6qcB1c31soqJSWqutJC6H9zyjVl0073Yi5k7SHbjRvthNMgK2kCg?=
 =?iso-8859-1?Q?yvBZ4XjSw8bDUzKgWQKDCi15sdRsMPsaYEe1gYu/P5hCakzGRhhYhlnTSm?=
 =?iso-8859-1?Q?vl6UxdiqKDKkPkoi0GCuGSPtH3dmm1tI7CpCMEVy1NuBZ8+pN5lTSkfYoL?=
 =?iso-8859-1?Q?RpjHE1Z7iBoOrdEi3g9dIS6dX8FUEZJJ8F5zwcCUdVIUpfvSInyv6pH0XZ?=
 =?iso-8859-1?Q?eIHNWP5/4vlpmWWQ0d5ylNAJ8h+DrWh7tf5X4dfVFAC4tJDttWgWs/pDfm?=
 =?iso-8859-1?Q?f/CNzDzoWEduUBVaRaB+eeyQki3roFpypFgABdyFJqecSsZxdzFS2AhHrm?=
 =?iso-8859-1?Q?HeB6wl5cqzzLt7EknkvthecNX1/iVsEKTaNXRflbcxVG/Neo+jyJXMkpjr?=
 =?iso-8859-1?Q?AVaRKMhD0hjK7WNQqYcxf3Yg1bSWQNSVFTaYbA6POU6jK0oXySV/NV3Ous?=
 =?iso-8859-1?Q?lldVkzKIIc9uC2ZpJCQeasZMElwk/osVxID7bhihOy6zYBcXo+vhRiZjeE?=
 =?iso-8859-1?Q?MeRNo46DjgwAVVX+lpr0ZlmSxK2onJwhhTkDlJtUgCaXgKQb3+o7mOLXOE?=
 =?iso-8859-1?Q?U24v+vJ2jCp37WnxyuU5g3xDm58EaVbtu1Tn1N08EXaUQJWM6ltSns+Gk7?=
 =?iso-8859-1?Q?UTRxmOEJ7ZPAB6KnkNtv6ibXiUjAl3/nJQvcy1V6Mf3MZARPd7FQ7I9k0n?=
 =?iso-8859-1?Q?9coocKMwWf50nVo/nG/acm6HhlE7nIuELA3NwWdN3qmL751c+oucyLJgwK?=
 =?iso-8859-1?Q?bVMQ1NP9hShmyaFSw876ZFctXZA/n055qVYXcXYT04sJ+ejgB3xJNFCWkd?=
 =?iso-8859-1?Q?66iDuQfMtSMwsuq5YX5+Ef3zX10LCYESFWIX5YOagJ0Ag6ih1F2oFGH0K8?=
 =?iso-8859-1?Q?wfZTTlUXgiisbTXusCVqhJgA51dOHoMNDhMV1K3lKBqos3lkp7PD1mTcEh?=
 =?iso-8859-1?Q?1J4aHybQL1N2lXbP6TYRpngWyXMfCl4vlQq2pMofW4LmqEhtuEczpt5RjP?=
 =?iso-8859-1?Q?K/PM3bebXxqdnT2SxRhT3C2Juaq94uvqo33Mwe60sTYi31DRNVdCh8E3wR?=
 =?iso-8859-1?Q?c+9ELtbKGAGsKMZBqjRg5dPQYpIFxNnUOdSnjvG24/wi451ngG/Vij9VUf?=
 =?iso-8859-1?Q?6sZc/6njD4V6ocg3KdUhd9tMYXyvhlXs/DxI9xdVXbIH6Zn87B5CljTpG8?=
 =?iso-8859-1?Q?XvY2SYYDlUUzGErrDBTpf9HR+fOio8dELVpNEOEXDKSQb3W/3kuUpADeLo?=
 =?iso-8859-1?Q?pp+26R0eg37IfyqX0GTR5jhNMpGGLbfO6LbrTAALvEpq4WMEb1C0qEz6Ix?=
 =?iso-8859-1?Q?II3yEJ8EgKvBUeutYZgqtrNNcRSC4N1Hd6na6FbiB13+ySJBjFzOakE2TJ?=
 =?iso-8859-1?Q?pCDAljM7qy2hKPsY9N3kRR0iZD2CvArLhw0NnkJ/1pct7KArXPhYXDLw?=
 =?iso-8859-1?Q?=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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 38b27eff-4e97-4ad9-f4cb-08dd96ecf1a4
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 15:50:56.1740
 (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: JR021mEIK9xc+Alyw57gKDXyuu/TMWWbXxFG+JbS9Uyg5DjP0PINFmGfDtQ4hxFMjfWdj5RHe59u5fiL7GriPulCUD5D/W7tM5tsT6KMx+E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9023

This patch adds the basic framework for ARM SCI mediator. SCI is System
Control Interface, which is designed to redirect requests from the Domains
to ARM specific Firmware (for example SCMI). This will allow the devices,
passed-through to the different Domains, to access to the System resources
(such as clocks/resets etc) by sending requests to the firmware.

ARM SCI subsystem allows to implement different SCI drivers to handle
specific ARM firmware interfaces (like ARM SCMI) and mediate requests
between the Domains and the Firmware. Also it allows SCI drivers to perform
proper action during Domain creation/destruction which is vital for
handling use cases like Domain reboot.

This patch introduces new DEVICE_FIRMWARE device subclass for probing SCI
drivers basing on device tree, SCI drivers register itself with
DT_DEVICE_START/END macro. On init - the SCI drivers should register its
SCI ops with sci_register(). Only one SCI driver can be supported.

At run-time, the following SCI API calls are introduced:

- sci_domain_sanitise_config() called from arch_sanitise_domain_config()
- sci_domain_init() called from arch_domain_create()
- sci_relinquish_resources() called from domain_relinquish_resources()
- sci_domain_destroy() called from arch_domain_destroy()
- sci_handle_call() called from vsmccc_handle_call()
- sci_dt_handle_node()
  sci_dt_finalize() called from handle_node() (Dom0 DT)

Signed-off-by: Oleksii Moisieiev 
Signed-off-by: Grygorii Strashko 
---

Changes in v4:
- fix SPDX-License
- rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE
- move XEN_DOMCTL_assign_device code in separate patch
- Add documentation for SCI SCMI drivers

 MAINTAINERS                             |   6 +
 xen/arch/arm/device.c                   |   5 +
 xen/arch/arm/dom0less-build.c           |   7 +
 xen/arch/arm/domain.c                   |  12 +-
 xen/arch/arm/domain_build.c             |   8 +
 xen/arch/arm/firmware/Kconfig           |   8 +
 xen/arch/arm/firmware/Makefile          |   1 +
 xen/arch/arm/firmware/sci.c             | 154 ++++++++++++++++++
 xen/arch/arm/include/asm/domain.h       |   5 +
 xen/arch/arm/include/asm/firmware/sci.h | 200 ++++++++++++++++++++++++
 xen/arch/arm/vsmc.c                     |   3 +
 xen/include/asm-generic/device.h        |   1 +
 xen/include/public/arch-arm.h           |   4 +
 13 files changed, 413 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/firmware/sci.c
 create mode 100644 xen/arch/arm/include/asm/firmware/sci.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c11b82eca9..f5e3c48b96 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -507,6 +507,12 @@ R:	George Dunlap 
 S:	Supported
 F:	xen/common/sched/
=20
+SCI MEDIATORS
+M:	Oleksii Moisieiev 
+S:	Supported
+F:	xen/arch/arm/firmware/sci.c
+F:	xen/arch/arm/include/asm/firmware/sci.h
+
 SEABIOS UPSTREAM
 M:	Wei Liu 
 S:	Supported
diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 5610cddcba..bdab96a408 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -13,6 +13,7 @@
 #include 
 #include 
=20
+#include 
 #include 
=20
 int map_irq_to_domain(struct domain *d, unsigned int irq,
@@ -303,6 +304,10 @@ int handle_device(struct domain *d, struct dt_device_n=
ode *dev, p2m_type_t p2mt,
                 return res;
             }
         }
+
+        res =3D sci_assign_dt_device(d, dev);
+        if ( res )
+            return res;
     }
=20
     res =3D map_device_irqs_to_domain(d, dev, own_device, irq_ranges);
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 49d1f14d65..a09c4c4bd7 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
=20
@@ -321,6 +322,10 @@ static int __init handle_passthrough_prop(struct kerne=
l_info *kinfo,
         return -EINVAL;
     }
=20
+    res =3D sci_assign_dt_device(kinfo->d, node);
+    if ( res )
+        return res;
+
     res =3D map_device_irqs_to_domain(kinfo->d, node, true, NULL);
     if ( res < 0 )
         return res;
@@ -970,6 +975,8 @@ void __init create_domUs(void)
         if ( !llc_coloring_enabled && llc_colors_str )
             panic("'llc-colors' found, but LLC coloring is disabled\n");
=20
+        d_cfg.arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
+
         /*
          * The variable max_init_domid is initialized with zero, so here i=
t's
          * very important to use the pre-increment operator to call
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 3ba959f866..652aeb7a55 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -694,7 +695,7 @@ int arch_sanitise_domain_config(struct xen_domctl_creat=
edomain *config)
         return -EINVAL;
     }
=20
-    return 0;
+    return sci_domain_sanitise_config(config);
 }
=20
 int arch_domain_create(struct domain *d,
@@ -786,6 +787,9 @@ int arch_domain_create(struct domain *d,
     d->arch.sve_vl =3D config->arch.sve_vl;
 #endif
=20
+    if ( (rc =3D sci_domain_init(d, config)) !=3D 0 )
+        goto fail;
+
     return 0;
=20
 fail:
@@ -846,6 +850,7 @@ void arch_domain_destroy(struct domain *d)
     domain_vgic_free(d);
     domain_vuart_free(d);
     free_xenheap_page(d->shared_info);
+    sci_domain_destroy(d);
 #ifdef CONFIG_ACPI
     free_xenheap_pages(d->arch.efi_acpi_table,
                        get_order_from_bytes(d->arch.efi_acpi_len));
@@ -1039,6 +1044,7 @@ enum {
     PROG_p2m_root,
     PROG_p2m,
     PROG_p2m_pool,
+    PROG_sci,
     PROG_done,
 };
=20
@@ -1098,6 +1104,10 @@ int domain_relinquish_resources(struct domain *d)
         ret =3D relinquish_p2m_mapping(d);
         if ( ret )
             return ret;
+    PROGRESS(sci):
+        ret =3D sci_relinquish_resources(d);
+        if ( ret )
+            return ret;
=20
     PROGRESS(p2m_root):
         /*
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 7b47abade1..36d28b52a4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1888,6 +1889,9 @@ static int __init handle_node(struct domain *d, struc=
t kernel_info *kinfo,
         return 0;
     }
=20
+    if ( sci_dt_handle_node(d, node) )
+        return 0;
+
     /*
      * The vGIC does not support routing hardware PPIs to guest. So
      * we need to skip any node using PPIs.
@@ -1988,6 +1992,10 @@ static int __init handle_node(struct domain *d, stru=
ct kernel_info *kinfo,
         if ( res )
             return res;
=20
+        res =3D sci_dt_finalize(d, kinfo->fdt);
+        if ( res )
+            return res;
+
         /*
          * Create a second memory node to store the ranges covering
          * reserved-memory regions.
diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
index 817da745fd..fc7918c7fc 100644
--- a/xen/arch/arm/firmware/Kconfig
+++ b/xen/arch/arm/firmware/Kconfig
@@ -1,3 +1,11 @@
+config ARM_SCI
+	bool
+	depends on ARM
+	help
+	  This option enables generic Arm SCI (System Control Interface) mediator=
s
+	  support. It allows domains to control system resources via one of
+	  Arm SCI mediators drivers implemented in XEN, like SCMI.
+
 menu "Firmware Drivers"
=20
 config SCMI_SMC
diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefil=
e
index a5e4542666..71bdefc24a 100644
--- a/xen/arch/arm/firmware/Makefile
+++ b/xen/arch/arm/firmware/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_ARM_SCI) +=3D sci.o
 obj-$(CONFIG_SCMI_SMC) +=3D scmi-smc.o
diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
new file mode 100644
index 0000000000..e1522e10e2
--- /dev/null
+++ b/xen/arch/arm/firmware/sci.c
@@ -0,0 +1,154 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Generic part of the SCI (System Control Interface) subsystem.
+ *
+ * Oleksii Moisieiev 
+ * Copyright (c) 2025 EPAM Systems
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static const struct sci_mediator_ops __read_mostly *cur_mediator;
+
+int sci_register(const struct sci_mediator_ops *ops)
+{
+    if ( cur_mediator )
+        return -EEXIST;
+
+    if ( !ops->domain_init || !ops->domain_destroy || !ops->handle_call )
+        return -EINVAL;
+
+    cur_mediator =3D ops;
+
+    return 0;
+};
+
+bool sci_handle_call(struct cpu_user_regs *args)
+{
+    if ( unlikely(!cur_mediator) )
+        return false;
+
+    return cur_mediator->handle_call(args);
+}
+
+int sci_domain_init(struct domain *d, struct xen_domctl_createdomain *conf=
ig)
+{
+    if ( !cur_mediator )
+        return 0;
+
+    return cur_mediator->domain_init(d, config);
+}
+
+int sci_domain_sanitise_config(struct xen_domctl_createdomain *config)
+{
+    if ( !cur_mediator )
+        return 0;
+
+    if ( !cur_mediator->domain_sanitise_config )
+        return 0;
+
+    return cur_mediator->domain_sanitise_config(config);
+}
+
+void sci_domain_destroy(struct domain *d)
+{
+    if ( !cur_mediator )
+        return;
+
+    cur_mediator->domain_destroy(d);
+}
+
+int sci_relinquish_resources(struct domain *d)
+{
+    if ( !cur_mediator )
+        return 0;
+
+    if ( !cur_mediator->relinquish_resources )
+        return 0;
+
+    return cur_mediator->relinquish_resources(d);
+}
+
+bool sci_dt_handle_node(struct domain *d, struct dt_device_node *node)
+{
+    if ( !cur_mediator )
+        return 0;
+
+    if ( !cur_mediator->dom0_dt_handle_node )
+        return 0;
+
+    return cur_mediator->dom0_dt_handle_node(d, node);
+}
+
+int sci_dt_finalize(struct domain *d, void *fdt)
+{
+    if ( !cur_mediator )
+        return 0;
+
+    if ( !cur_mediator->dom0_dt_finalize )
+        return 0;
+
+    return cur_mediator->dom0_dt_finalize(d, fdt);
+}
+
+int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
+{
+    struct dt_phandle_args ac_spec;
+    int index =3D 0;
+    int ret;
+
+    if ( !cur_mediator )
+        return 0;
+
+    if ( !cur_mediator->assign_dt_device )
+        return 0;
+
+    while ( !dt_parse_phandle_with_args(dev, "access-controllers",
+                                        "#access-controller-cells", index,
+                                        &ac_spec) )
+    {
+        printk(XENLOG_DEBUG "sci: assign device %s to %pd\n",
+               dt_node_full_name(dev), d);
+
+        ret =3D cur_mediator->assign_dt_device(d, &ac_spec);
+        if ( ret )
+            return ret;
+
+        index++;
+    }
+
+    return 0;
+}
+
+static int __init sci_init(void)
+{
+    struct dt_device_node *np;
+    unsigned int num_sci =3D 0;
+    int rc;
+
+    dt_for_each_device_node(dt_host, np)
+    {
+        rc =3D device_init(np, DEVICE_FIRMWARE, NULL);
+        if ( !rc && num_sci )
+        {
+            printk(XENLOG_ERR
+                   "SCMI: Only one SCI controller is supported. found seco=
nd %s\n",
+                   np->name);
+            return -EOPNOTSUPP;
+        }
+        else if ( !rc )
+            num_sci++;
+        else if ( rc !=3D -EBADF && rc !=3D -ENODEV )
+            return rc;
+    }
+
+    return 0;
+}
+
+__initcall(sci_init);
diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/d=
omain.h
index f1d72c6e48..fa0898b7cf 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -118,6 +118,11 @@ struct arch_domain
 #ifdef CONFIG_TEE
     void *tee;
 #endif
+#ifdef CONFIG_ARM_SCI
+    bool sci_enabled;
+    /* ARM SCI driver's specific data */
+    void *sci_data;
+#endif
=20
 }  __cacheline_aligned;
=20
diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include=
/asm/firmware/sci.h
new file mode 100644
index 0000000000..71fb54852e
--- /dev/null
+++ b/xen/arch/arm/include/asm/firmware/sci.h
@@ -0,0 +1,200 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Generic ARM SCI (System Control Interface) subsystem.
+ *
+ * Oleksii Moisieiev 
+ * Copyright (c) 2025 EPAM Systems
+ */
+
+#ifndef __ASM_ARM_SCI_H
+#define __ASM_ARM_SCI_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_ARM_SCI
+
+struct sci_mediator_ops {
+    /*
+     * Called during domain construction. If it is requested to enable
+     * SCI support, so SCI driver can create own structures for the new do=
main
+     * and inform firmware about new domain (if required).
+     * Mandatory.
+     */
+    int (*domain_init)(struct domain *d,
+                       struct xen_domctl_createdomain *config);
+
+    /*
+     * Called during domain construction. The SCI driver uses
+     * it to sanitize domain SCI configuration parameters.
+     * Optional.
+     */
+    int (*domain_sanitise_config)(struct xen_domctl_createdomain *config);
+
+    /*
+     * Called during domain destruction, releases all resources, that
+     * were allocated for domain.
+     * Mandatory.
+     */
+    void (*domain_destroy)(struct domain *d);
+
+    /*
+     * Called during domain destruction to relinquish resources used
+     * by SCI driver itself and request resources releasing from firmware.
+     * Optional.
+     */
+    int (*relinquish_resources)(struct domain *d);
+
+    /* SMC/HVC Handle callback */
+    bool (*handle_call)(struct cpu_user_regs *regs);
+
+    /*
+     * Dom0 DT nodes handling callback so SCI driver can detect DT nodes i=
t
+     * need to handle and decide if those nodes need to be provided to Dom=
0.
+     * Optional.
+     */
+    bool (*dom0_dt_handle_node)(struct domain *d, struct dt_device_node *n=
ode);
+
+    /*
+     * SCI driver callback called at the end of Dom0 DT generation, so
+     * it can perform steps to modify DT to enable/disable SCI
+     * functionality for Dom0.
+     */
+    int (*dom0_dt_finalize)(struct domain *d, void *fdt);
+
+    /*
+     * SCI driver callback called when DT device is passed through to gues=
t,
+     * so SCI driver can enable device access to the domain if SCI FW prov=
ides
+     * Device specific access control functionality.
+     * Optional.
+     */
+    int (*assign_dt_device)(struct domain *d, struct dt_phandle_args *ac_s=
pec);
+};
+
+
+static inline bool sci_domain_is_enabled(struct domain *d)
+{
+    return d->arch.sci_enabled;
+}
+
+/*
+ * Register SCI subsystem ops.
+ *
+ * Register SCI drivers operation and so enable SCI functionality.
+ * Only one SCI driver is supported.
+ */
+int sci_register(const struct sci_mediator_ops *ops);
+
+/*
+ * Initialize SCI functionality for domain if configured.
+ *
+ * Initialization routine to enable SCI functionality for the domain.
+ * The SCI configuration data and decision about enabling SCI functionalit=
y
+ * for the domain is SCI driver specific.
+ */
+int sci_domain_init(struct domain *d, struct xen_domctl_createdomain *conf=
ig);
+
+/*
+ * Sanitise domain configuration parameters.
+ *
+ */
+int sci_domain_sanitise_config(struct xen_domctl_createdomain *config);
+
+/*
+ * Destroy SCI domain instance.
+ */
+void sci_domain_destroy(struct domain *d);
+
+/*
+ * Free resources assigned to the certain domain.
+ */
+int sci_relinquish_resources(struct domain *d);
+
+/*
+ * SMC/HVC Handle callback.
+ *
+ * SCI driver acts as SMC/HVC server for the registered domains and
+ * does redirection of the domain calls to the SCI firmware,
+ * such as ARM TF-A or similar.
+ */
+bool sci_handle_call(struct cpu_user_regs *regs);
+
+/*
+ * Dom0 DT nodes handling function.
+ *
+ * Allows SCI driver to detect DT nodes it need to handle and decide if
+ * those nodes need to be provided to Dom0.
+ */
+bool sci_dt_handle_node(struct domain *d, struct dt_device_node *node);
+
+/*
+ * Dom0 DT generation finalize.
+ *
+ * Called at the end of Dom0 DT generation, so SCI driver can perform step=
s
+ * to modify DT to enable/disable SCI functionality for Dom0.
+ */
+int sci_dt_finalize(struct domain *d, void *fdt);
+
+/*
+ * Assign DT device to domain.
+ *
+ * Called when DT device is passed through to guest, so SCI driver can ena=
ble
+ * device access to the domain if SCI FW provides "Device specific access
+ * control" functionality.
+ */
+int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev);
+#else
+
+static inline bool sci_domain_is_enabled(struct domain *d)
+{
+    return false;
+}
+
+static inline int sci_domain_init(struct domain *d,
+                                  struct xen_domctl_createdomain *config)
+{
+    return 0;
+}
+
+static inline int
+sci_domain_sanitise_config(struct xen_domctl_createdomain *config)
+{
+    return 0;
+}
+
+static inline void sci_domain_destroy(struct domain *d)
+{}
+
+static inline int sci_relinquish_resources(struct domain *d)
+{
+    return 0;
+}
+
+static inline bool sci_handle_call(struct cpu_user_regs *args)
+{
+    return false;
+}
+
+static inline bool sci_dt_handle_node(struct domain *d,
+                                      struct dt_device_node *node)
+{
+    return false;
+}
+
+static inline int sci_dt_finalize(struct domain *d, void *fdt)
+{
+    return false;
+}
+
+static inline int sci_assign_dt_device(struct domain *d,
+                                       struct dt_device_node *dev)
+{
+    return 0;
+}
+
+#endif /* CONFIG_ARM_SCI */
+
+#endif /* __ASM_ARM_SCI_H */
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 62d8117a12..51b3c02973 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -300,6 +301,8 @@ static bool vsmccc_handle_call(struct cpu_user_regs *re=
gs)
             break;
         case ARM_SMCCC_OWNER_SIP:
             handled =3D handle_sip(regs);
+            if ( !handled )
+                handled =3D sci_handle_call(regs);
             break;
         case ARM_SMCCC_OWNER_TRUSTED_APP ... ARM_SMCCC_OWNER_TRUSTED_APP_E=
ND:
         case ARM_SMCCC_OWNER_TRUSTED_OS ... ARM_SMCCC_OWNER_TRUSTED_OS_END=
:
diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/dev=
ice.h
index 1acd1ba1d8..e96c5558c2 100644
--- a/xen/include/asm-generic/device.h
+++ b/xen/include/asm-generic/device.h
@@ -18,6 +18,7 @@ enum device_class
     DEVICE_IOMMU,
     DEVICE_INTERRUPT_CONTROLLER,
     DEVICE_PCI_HOSTBRIDGE,
+    DEVICE_FIRMWARE,
     /* Use for error */
     DEVICE_UNKNOWN,
 };
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 24840eeaa6..55eed9992c 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -327,6 +327,8 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 #define XEN_DOMCTL_CONFIG_TEE_OPTEE     1
 #define XEN_DOMCTL_CONFIG_TEE_FFA       2
=20
+#define XEN_DOMCTL_CONFIG_ARM_SCI_NONE      0
+
 struct xen_arch_domainconfig {
     /* IN/OUT */
     uint8_t gic_version;
@@ -350,6 +352,8 @@ struct xen_arch_domainconfig {
      *
      */
     uint32_t clock_frequency;
+    /* IN */
+    uint8_t arm_sci_type;
 };
 #endif /* __XEN__ || __XEN_TOOLS__ */
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon May 19 15:51:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:51:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989964.1373961 (Exim 4.92)
	(envelope-from )
	id 1uH2lh-0006Hh-2H; Mon, 19 May 2025 15:51:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989964.1373961; Mon, 19 May 2025 15: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 1uH2lg-0006HI-Uo; Mon, 19 May 2025 15:51:08 +0000
Received: by outflank-mailman (input) for mailman id 989964;
 Mon, 19 May 2025 15:51:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2le-00055d-W8
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:51:07 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on20612.outbound.protection.outlook.com
 [2a01:111:f403:260c::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1298e768-34c9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 17:51:05 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB9023.eurprd03.prod.outlook.com (2603:10a6:20b:5b7::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.29; Mon, 19 May
 2025 15:50:58 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8722.031; Mon, 19 May 2025
 15:50: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" 
X-Inumbo-ID: 1298e768-34c9-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YvojqNmdAdi3vUx1VnPVkxS20qvzhQiT1gPOSfH6JYQ6WPFm5hrV86aa9tgLYADpA9x1rgTxzG3lwoTpMddrnH4UB3NDN3PVBsRCkVsgmDf48XAOOnI4EKa9NERYmHh/j6o3zS0jRvboFsjMgFDUs/kAv+Wqt/NT66yfNZLou3u6mY5XDJX2bic9/5ZBwTuclhiCLBPzq7eOGEohHmXT/NQ4tXf366LFCeBIbA7uzhmyhMjx1Lh/FqOHAvWInIbYOe16LDEMSegIbkPMyObwR1gku44y96AKKGeqwKA8iRyWVaABTDbWo3b901eKX4FYRe8oFzKW0DCK/yvBBfa8xw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ngb/Uc83s7G/8aLrdtXV+MINpMrv6VMh+dzEgsn3NaQ=;
 b=lGQpMZCCs/+E6yag8SOhx3VcQYtLSPyBwhBBAKevjGgfJMmCLfAkWAt3twRlay7ksUzmrSnfPPZJvDKH0iSuZuZtjJqxcyqfTZaeRKf7/ZsqDNQApfI4IoxqqXvQQHBzM2qtafzdUTk5xOU8aioYjuetJmsMVBWYjZHKk6FaeqsC3vJymPNVNtLnlDeV06zBTsxXZ+TFzQxc6r9RHzEB8FzJIn7F63yqlRDKSoCdXMoNyOZrwVKna9nxXQvk2IAdJhBIwuzXqiTHfKPgpCT7olREfKVSqILF1Fe+6Vmu0+emqbALJetFS2brCMtX1glSzSSpubyS/pyhAAqif8Py4g==
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=ngb/Uc83s7G/8aLrdtXV+MINpMrv6VMh+dzEgsn3NaQ=;
 b=Ft705z1BLCkBkrSM8BF8su2/xJL5aQZdsQjzn+qMdzdu2tu++a/edXvc385LnkZ7u2M6JkMzJZHW2PD3Hdo5GiS0HjF0JNWlRZ6X2Sbwd5UblexmnzPQXW4hy4/yEgZXYOe1IKRCk+iQToRRNsZCDUqTGNAKM12fMVSdg3iH4Ze+wq84eGo+8PXobMxs24R0gwM4y/uJ0RSI7D9k1cbnvTN2w9ofFRMvoEzNKPNKLIbHRZYYM8jjOfNFaFVnBjkbwrlbjv/YuIHZ+xccDYI2lLjfhYNyBME6bI/NJFEGgTpbzSmithOZEpsgB47TaWpNFgwyyP4MPt75DkVMR8zHeg==
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: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
Thread-Topic: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
Thread-Index: AQHbyNXPDXt2FT3RV02cltfdm/Dd7g==
Date: Mon, 19 May 2025 15:50:57 +0000
Message-ID:
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB9023:EE_
x-ms-office365-filtering-correlation-id: 4814fdba-2e4e-48bf-f582-08dd96ecf29f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?Fk61h06h5Zkt3QzB2qONmvJMJTHsQ+pMeJ4dlo4/aDhJkFIPsuvoYaD4Vf?=
 =?iso-8859-1?Q?nHV5wgoNXlLNAj9EwjekpRSYGbj5Uda7wS+R0Jpo2bdzBFaMjLrM1oMRvu?=
 =?iso-8859-1?Q?/P4MA/WTJjn0lWZ5ITLdgV7ttBZ6Y9j5FD3gBgirmHCAab+r/1WtDA1TJP?=
 =?iso-8859-1?Q?gpX3U02G5FAfvKfIvuIN7nBvCY6iMzSxCc1DCft4eeickLIC96OfxaBNSg?=
 =?iso-8859-1?Q?h7a74X3J83Ckau/1zS1q0HzX/r3cjAtgbwOOFaqkQE9J+kYc0ls/JHyHma?=
 =?iso-8859-1?Q?tygjuUL5IX7E7qe4AhjrBSuraOOc/ZqtfroXtnpgtcxuMAasbb3eT0zFUD?=
 =?iso-8859-1?Q?X2li12IvMyV90BSIL+S6R7eNqwLACwYEmGMC57933cFx9juU2NRxkopcIL?=
 =?iso-8859-1?Q?mLi9z2PwMBFf4F4xP7lD3bhlOlNYGqi7rT+KC/1uxqRulr4lHCRnZW3ioD?=
 =?iso-8859-1?Q?31P5xjDZpetQe0IK/1WVkrPjjohdtMt5KvyM5y4RHPvm20OzjnA76xcUnU?=
 =?iso-8859-1?Q?JhH1Ch1dG/3QZoCs9cOQYJs16Kru0pnbSongyYFJA4uyRoPqA2oaVnhauQ?=
 =?iso-8859-1?Q?tjbVTsvYp7TmRJ7k90y6Xo/syfDiW5OjirxzKUv2Y8NTO5TNW17f7d49rc?=
 =?iso-8859-1?Q?F4z3aanryNIlLHs1sma+w9CwHEGoKTZcRMkBZAHtaBcdY2JpihymK/K6iR?=
 =?iso-8859-1?Q?AfRWNdvO+e9bzpoWhxiNX3K/E/4kkAMbFCMs14E/l9pX/c5m6qsCWZVWFX?=
 =?iso-8859-1?Q?G+hHJ4sUz66RRlMHdHohkZUeku6iO80u5dn9fKaMOnoatDZU5xxaTje07S?=
 =?iso-8859-1?Q?5YewifXdYNSHoAI+pvRP3PrmxLclqvXpuiaWViCqJu/KYLG5to07rywcYF?=
 =?iso-8859-1?Q?S7/lNSm0BkypMJof4GsXHamZpd2qDcLo0hp9Sdvb4zrplflWqnJsD53fsO?=
 =?iso-8859-1?Q?T9mMz3gtIf+uBdbwJdU5rG/CdB1C/kDPgSZsYValEX8To7wjVnoPvaiss1?=
 =?iso-8859-1?Q?dMnqqXlTJgSMZHEC0gb/1rk2KjWlOe+pyoCQVDQA9mT6TRoH9lUWuYq5B7?=
 =?iso-8859-1?Q?cQiSYlibEntaV54B1VpOVlMQuLxy3O6WJ+ElY4NG3QbkAMkP4xAZickOPS?=
 =?iso-8859-1?Q?nHdjlg94Bfm6CZnIbLZPIp3evEYeKyycPUe8DNYPyy/Qs4nmWKjie2C2tG?=
 =?iso-8859-1?Q?8IQT9uL635PYZbwYWuvemIeE29CDeOu0kU1r9iY/XHTs80usuBOApIUqkW?=
 =?iso-8859-1?Q?3o+ghZgMpKr7onZkHCDFmB7UAW2vx8kwwy0fgvWOIMqsKPEA30C/w758N0?=
 =?iso-8859-1?Q?973FSifM8xSZJ+/Ra2wsapLKbmex6dDOdUDoLrSrj7e60E+vsDBVA2FiG7?=
 =?iso-8859-1?Q?Rgp8m7ZOE8dTPUkVjxz8lIj68FtozbTRbpEZ8IwgPEAp2tvZzF8J1F4lbV?=
 =?iso-8859-1?Q?iWDTZy5IBdz80EMXxfgbjvF6RqCf0c7al6U3i8hyaj0feKM5Mzff3gN0aO?=
 =?iso-8859-1?Q?U8BXrdhUnorl5iqLp9Q0nB5yMQ++SzZfxrNEx/NecLOVEXbGbV+fSOmWcC?=
 =?iso-8859-1?Q?HBen7TQ=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?7qlLpp1diIGUrXgCIuBS2MIsAbGtWBHWNi8sPQzgYfzIcI5zd0oWamKCpD?=
 =?iso-8859-1?Q?hDZg8J4wn1YIEc9QwBIGGKMfWuSxwrBGgZI78oIaOo96RyQtT5zJxKOH56?=
 =?iso-8859-1?Q?BzFGyo+avEsRU3C8KHH3e+enzZSTNgOby8Bq7/28Y1dyttAr4ZID+ZtWSZ?=
 =?iso-8859-1?Q?tFPtnambdnxIl1wXC3H8OhXPCjmyKTJJtV4ELCe4Cm1gppU7vfUACTYy7a?=
 =?iso-8859-1?Q?uQoLxB2cBRms3zdsk77fvlNkSc/1D616Xcksux5aqn2hdPseF1xdgPbzET?=
 =?iso-8859-1?Q?3EqCr/kV+T54BOF++W4qd9jCJEErTuXUCKx/DLa85l0Fcg14vWIwUa6QIC?=
 =?iso-8859-1?Q?mZHSzZWpxmafo0nNHK97wdEeAUi5zW52hPTZdgCaYoVRrrumHgDreTxn/U?=
 =?iso-8859-1?Q?6w1MyP8XzhiV/6vLkwzi6X2Wip7cEBfAgvFurb8fI8vUT49LBbL6VARFJA?=
 =?iso-8859-1?Q?H+dVFsGXy78ISyaMOTtvpxwURAZy6FkvofRp83Ep4/MRw0SN1/lMOf4iMY?=
 =?iso-8859-1?Q?rWA/kKSniox2mFqbq2urnOAB7ZJZKl/wF7K6Nrs/Km6W48pMrLo7ft4Yvl?=
 =?iso-8859-1?Q?NTATJvu5fgT0IbsVzJ6Xb1+ofqwmiLmbEiu3o7/xkXWdHW1tcKy4MTKUm8?=
 =?iso-8859-1?Q?afBFr6ktj2qggEJvGkBMMN+lTTG996v7XKS2KVeBZ4cQ/XimzCg0qxoszo?=
 =?iso-8859-1?Q?4UmwouMTGkGTHYmKt5OyKsP2z6T7BbR/qLmxVvoV97vLwlBlX4MIVBT+cP?=
 =?iso-8859-1?Q?rR1LUUcxW3phLyOaAtJJhaud5YCWYvxHzHVo3R1ysymiwZfQt068pNgZqH?=
 =?iso-8859-1?Q?vpkm6I0To6UIyo8wWIAfXHCBYCBr8/cruTYDhfgAawz7mmFJZShQd4VjUt?=
 =?iso-8859-1?Q?6Ft9RecTfLLF1VgMylykb1yzRhvHrTR9PCdz6VVCFlgQohU5zdkrHPcyYN?=
 =?iso-8859-1?Q?muYPHmmPJjt19kBDyPeMEiz/GeZCQvfarhnjOz8xcFKnjh5HUCO8LRTvzF?=
 =?iso-8859-1?Q?UdroAAAST8NP3KvRa7KvAkbvNqxQ1jA4U3+GrZmu1jyG/gxJz1ojPLEJ4z?=
 =?iso-8859-1?Q?FxcjPOyNAejBN0h2EZRY1SC/T/dRnZH+bogrAbZriSBFKDKMsT/au2vWSv?=
 =?iso-8859-1?Q?KF0tme51thPVVWnB8GnPE+PIRi9nj6SRM/g9ONikTxm96PcWRH4FyCizXF?=
 =?iso-8859-1?Q?DN6FaZ68Mz6WAOc7U8uLln1zObEYnAaZTCvLiSh0Oe3fqvB5fa8P5h6Izn?=
 =?iso-8859-1?Q?i3BJSIYpEIgexbaCj/MRnmRc/V6fHq8/oM8VissgzT1b+VhnT6hd9DoVsm?=
 =?iso-8859-1?Q?mwOwrRRpL2S+xHmaFY625yeBeQuNYPtwskLg5HF49j+2xlQd3XVGgecNbi?=
 =?iso-8859-1?Q?O1+RzLPqUW+IyvN7NHO2Y5TIYItjJNjqaQP2Fdf3QhjH0RKKNwoHvIupDh?=
 =?iso-8859-1?Q?5Oy/qUsu+VKmsa89/ofjtZKcT8MJyJef8rUdvDsbni7U9hcpBjaUJms2h+?=
 =?iso-8859-1?Q?UdnZylzgDzMA4/XsFjN1m2+resSi4QTpg6KpE0IMb2TVirQRwKioexjK1n?=
 =?iso-8859-1?Q?u0Zkfg89L6C5qh8chpvdII9IZULGlsVUbTZzKPtdwjn0yHvktKgVI8FUUT?=
 =?iso-8859-1?Q?jxknycJXzesaD4I/+4ggtzi3E21mULuqdsjzZjlIK38mtaYy1nwQ8NJg?=
 =?iso-8859-1?Q?=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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4814fdba-2e4e-48bf-f582-08dd96ecf29f
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 15:50:57.3512
 (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: CqHYKHE03zuHq3KtnGYLIQQong7yhKITgflql5ORezTsKGv+tEN88sEcFlT2sY4i1UdsrUWo14GO77CLO+KUfou7s7fOXdq3V4zE+u+0Gtk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9023

From: Grygorii Strashko 

Add chained handling of assigned DT devices to support access-controller
functionality through SCI framework, so DT device assign request can be
passed to FW for processing and enabling VM access to requested device
(for example, device power management through FW interface like SCMI).

The SCI access-controller DT device processing is chained after IOMMU
processing and expected to be executed for any DT device regardless of its
protection by IOMMU (or if IOMMU is disabled).

This allows to pass not only IOMMU protected DT device through
xl.cfg:"dtdev" property for processing:

dtdev =3D [
    "/soc/video@e6ef0000", <- IOMMU protected device
    "/soc/i2c@e6508000", <- not IOMMU protected device
]

The change is done in two parts:
1) update iommu_do_dt_domctl() to check for dt_device_is_protected() and
not fail if DT device is not protected by IOMMU
2) add chained call to sci_do_domctl() in do_domctl()

Signed-off-by: Grygorii Strashko 
Signed-off-by: Oleksii Moisieiev 
---



 xen/arch/arm/firmware/sci.c             | 37 +++++++++++++++++++++++++
 xen/arch/arm/include/asm/firmware/sci.h | 14 ++++++++++
 xen/common/domctl.c                     | 19 +++++++++++++
 xen/drivers/passthrough/device_tree.c   |  6 ++++
 4 files changed, 76 insertions(+)

diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
index e1522e10e2..8efd541c4f 100644
--- a/xen/arch/arm/firmware/sci.c
+++ b/xen/arch/arm/firmware/sci.c
@@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct dt_d=
evice_node *dev)
     return 0;
 }
=20
+int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
+                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
+{
+    struct dt_device_node *dev;
+    int ret =3D 0;
+
+    switch ( domctl->cmd )
+    {
+    case XEN_DOMCTL_assign_device:
+        ret =3D -EOPNOTSUPP;
+        if ( domctl->u.assign_device.dev !=3D XEN_DOMCTL_DEV_DT )
+            break;
+
+        if ( !cur_mediator )
+            break;
+
+        if ( !cur_mediator->assign_dt_device )
+            break;
+
+        ret =3D dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
+                                    domctl->u.assign_device.u.dt.size, &de=
v);
+        if ( ret )
+            return ret;
+
+        ret =3D sci_assign_dt_device(d, dev);
+        if ( ret )
+            break;
+
+        break;
+    default:
+        /* do not fail here as call is chained with iommu handling */
+        break;
+    }
+
+    return ret;
+}
+
 static int __init sci_init(void)
 {
     struct dt_device_node *np;
diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include=
/asm/firmware/sci.h
index 71fb54852e..b8d1bc8a62 100644
--- a/xen/arch/arm/include/asm/firmware/sci.h
+++ b/xen/arch/arm/include/asm/firmware/sci.h
@@ -146,6 +146,14 @@ int sci_dt_finalize(struct domain *d, void *fdt);
  * control" functionality.
  */
 int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev);
+
+/*
+ * SCI domctl handler
+ *
+ * Only XEN_DOMCTL_assign_device is handled for now.
+ */
+int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
+                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
 #else
=20
 static inline bool sci_domain_is_enabled(struct domain *d)
@@ -195,6 +203,12 @@ static inline int sci_assign_dt_device(struct domain *=
d,
     return 0;
 }
=20
+static inline int sci_do_domctl(struct xen_domctl *domctl, struct domain *=
d,
+                                XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_dom=
ctl)
+{
+    return 0;
+}
+
 #endif /* CONFIG_ARM_SCI */
=20
 #endif /* __ASM_ARM_SCI_H */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 05abb581a0..a74ee92067 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -851,6 +852,24 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_=
domctl)
     case XEN_DOMCTL_deassign_device:
     case XEN_DOMCTL_get_device_group:
         ret =3D iommu_do_domctl(op, d, u_domctl);
+
+        if ( !ret || ret =3D=3D -EOPNOTSUPP )
+        {
+            int ret1;
+            /*
+             * Add chained handling of assigned DT devices to support
+             * access-controller functionality through SCI framework, so
+             * DT device assign request can be passed to FW for processing=
 and
+             * enabling VM access to requested device.
+             * The access-controller DT device processing is chained after=
 IOMMU
+             * processing and expected to be executed for any DT device
+             * regardless if DT device is protected by IOMMU or not (or IO=
MMU
+             * is disabled).
+             */
+            ret1 =3D sci_do_domctl(op, d, u_domctl);
+            if ( ret1 !=3D -EOPNOTSUPP )
+                ret =3D ret1;
+        }
         break;
=20
     case XEN_DOMCTL_get_paging_mempool_size:
diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthroug=
h/device_tree.c
index 075fb25a37..2624767e51 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -318,6 +318,12 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, stru=
ct domain *d,
             break;
         }
=20
+        if ( !dt_device_is_protected(dev) )
+        {
+            ret =3D 0;
+            break;
+        }
+
         ret =3D iommu_assign_dt_device(d, dev);
=20
         if ( ret )
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon May 19 15:51:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:51:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989959.1373911 (Exim 4.92)
	(envelope-from )
	id 1uH2la-00055q-Bg; Mon, 19 May 2025 15:51:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989959.1373911; Mon, 19 May 2025 15: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 1uH2la-00055j-8h; Mon, 19 May 2025 15:51:02 +0000
Received: by outflank-mailman (input) for mailman id 989959;
 Mon, 19 May 2025 15:51:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2lZ-00055d-KX
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:51:01 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20625.outbound.protection.outlook.com
 [2a01:111:f403:260e::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0ecb8684-34c9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 17:50:59 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB9023.eurprd03.prod.outlook.com (2603:10a6:20b:5b7::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.29; Mon, 19 May
 2025 15:50:57 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8722.031; Mon, 19 May 2025
 15:50: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" 
X-Inumbo-ID: 0ecb8684-34c9-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=RryLzWZbIsJo6b1rJskZ7YYToVMkIPM/j1E1nn5pwHowdDghahrjTFLoikh450/w7uHEJDRWBmBqyrUf7LePsO5hfWEN2Z11ZCWkDjQo7eRGMHdm3z++Ij4lH3E+pWmzLCcR04w14t1+6eUiHg3NnHgZFMZire/BJgN0fMEBrRaxKPFYvC5+1zx6qp7iwePKxIZs36+ug8/wtImaoLNZy03EpthBCucG6Fk7gnG72Q1eRuZoM9HNjrI9ufFhpA+ztwVEn3y8Y4DDfA5nVx9q1C0T1MwsxxhOzUOSvfP9JSwR/0zwgavxbOWCHvLhqBQ92s1WPQ/H4FO8G83kJE79rQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=W8pCd32735DZkbJkk0J7H/LgxlewCXbsG9CT2RHeX0c=;
 b=T6SSteX+rr9vSV/4oWuR8jOFSTjJkom9+vo9la56MXrSyjWjFicQbn6oHdWsI/Ck92JgAk7JG7l7lPnlZnq23RyMxSFVkL7d4rXrZAqMKuoBJVrDM4TGtAaEIxby20DHoc0Rz+ZhCz6BFjqtSUev+1ezRnoOk1xxZhfiExZgMDGasF+PsSCR/q5btD/Lk2ef602DMO/YDkjCthyeF/MaGf3mlpiq8IULtfyCm6c8pmb9Sz0ayAGSLt6omyD5aW57iag+qSrdL0mwjnRx+J0EvTN41BkVB4wgZUtwbt7Eg7OvBDBFuaEPNSDTuWJT1FRVYSjaiQ3+7P1s4h+xMZjgoQ==
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=W8pCd32735DZkbJkk0J7H/LgxlewCXbsG9CT2RHeX0c=;
 b=tdpXAT8qouXfxbKdYTvvOvUFlLGo6tncuN12fNRUrAUho5Di7Bf0xD+7V1Myf4MOlGanUcuGcm5ub/nfk3hxMiFF1Y98qALsYkMOl4cANPg0tCM1w2Wu0xUyWH9VYgEwwMPc3I36NxF24ZTrX7xKsdUmDn/FIEbvIb/MhIJOs3IQlzHSqI5/1lFCbyqlcGhczYbxdjGfGQ1aNeQn7wHHuDfYBrpy+iObOw0lHgD2kiLY+jRnC9Z3RxqMwhThA7m/dxQ6107WQrbU4UDoMZlX4Hlm/yLJpC796dXYXgAIUwYmVvzQFGUs00FH1dDg8bMOj14xCwPJQWcigGP4CU5Feg==
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: [RFC PATCH v4 3/8] xen/arm: scmi-smc: passthrough SCMI SMC to domain,
 single agent
Thread-Topic: [RFC PATCH v4 3/8] xen/arm: scmi-smc: passthrough SCMI SMC to
 domain, single agent
Thread-Index: AQHbyNXP6iFNbvP7Mk2Ziw3Fypk2NQ==
Date: Mon, 19 May 2025 15:50:56 +0000
Message-ID:
 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB9023:EE_
x-ms-office365-filtering-correlation-id: 136e7324-6871-43b5-f1f9-08dd96ecf1e9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?+YB7kXEZb1MlHtVF5MciDrZg8XQpSuEDIt/3hNavNOpPgh4iDDudf5rVey?=
 =?iso-8859-1?Q?K1Heao3egCMeF//OEtsys5C9WxMABilK/KI6I5qCDC+THLcqDyszGoeUsO?=
 =?iso-8859-1?Q?kZij6lPcWcy6o+i8IuDrXxIXEwOETVbKe+/SF2Ex2nyerOAbwVAU2vqIkd?=
 =?iso-8859-1?Q?mG4fga8Qa+ALTS9GVY+J8XKFDFiFR2PQrfIeynr84oDJudy3RURJ47dnEu?=
 =?iso-8859-1?Q?rn+3MDDnHnEwt1rp7nBB6ICs+HWFZ8B0BmnuoPlEm6stWw8hLcTFGTTIXo?=
 =?iso-8859-1?Q?AU+qO4TxNWIZl4RE2M59lOoXvJAKs3+c7a9kUS3F0aqPhqSU4OPb1PYApe?=
 =?iso-8859-1?Q?VgQUnrOmOJDO6ImAr5rCausTEr2q1kFcvjV0/M1c5P4h+g0Z4JuSqow0Vr?=
 =?iso-8859-1?Q?HNwxIBI6YPm/qv3g5s0bVg1tIPe3ZK6H5JgUbvAKhxLJsYDhTdq2C3b7pV?=
 =?iso-8859-1?Q?rwpgbac9+qtD60fSBOV4/cqxSBEGkWW3fRAmdUioKNRMCYGfP9ey2K5Q4z?=
 =?iso-8859-1?Q?aQJBqk6h43dcZsrwFmwfjv6oVREcY4SyJ716KU68jv20O9EmFd1Zwoc73d?=
 =?iso-8859-1?Q?U0ebLh2xRSpzs/rpRToCWVYV12dWdsv83EdTfvRZFjPHyyOeQP/laQUcYC?=
 =?iso-8859-1?Q?M0Ug9hHgLOxFa9p/Q6quWbDzibTtLTO0i4sh99hNAhxWVJ7wTVcsEW1Ete?=
 =?iso-8859-1?Q?WA7l9ayMcahieW91AbFEMPow0959LDWDfaLloIxgo8P1CtrlNfNQLWoMc+?=
 =?iso-8859-1?Q?/QOvq5FdBDw8IyiwsKXw5e6MWH5DZ4tIFWpE3L1rkOF+OX6hU0VCFrZ1tB?=
 =?iso-8859-1?Q?v3xMxi2awr2wxpiqmyxoiISz13YHc6nAP6JxvB/U6WXBDp67fgLV9w1gb3?=
 =?iso-8859-1?Q?37xv33Wr2WThcYgOCjYDpvISFKYeeZXsSbcNwO1KrgvAFGvRaXb9gVLBvC?=
 =?iso-8859-1?Q?WgaC2CWw4W9pYuMInN0dZBMYvvu5ZPUrdrRR1a7QlgQQI3me1Xd/EfFtBb?=
 =?iso-8859-1?Q?Jz8EpKHqIEvPZIpnVij2NsSxcYPpIXw2f7XGg7P13S+WfVkk48ZBvu+Mxj?=
 =?iso-8859-1?Q?ptmJPO+rdVlWzyTp0e301+wuSLfhlGHei+rTxxDIDBcnRvz07LuiKdfgwv?=
 =?iso-8859-1?Q?ufw6HAvapiTrpQYycj9vf18Ynx3btqFF8ynvXKbOkU9AEWSFQG781cShPi?=
 =?iso-8859-1?Q?18F9pVHu00qxMXsjHNUMI9evX7XBKM8vgKbA3nsZgcWyz72xZxJHGND/S1?=
 =?iso-8859-1?Q?/grR18PfKo2TMhqTELEhv6VLm7u7VsbqxEFBRPc0Mq88dD2QtjMoZuq5Jw?=
 =?iso-8859-1?Q?oawbSP1MGbA2Dcaht+NHazqHvXV5l5LM55o77XgvithlH9dWCyT4kDiLkY?=
 =?iso-8859-1?Q?h6i426wzV0H18E6V2+vetFq4/f7r5zJP/SEPVjSaEVC+4sbDJzr09hsIJA?=
 =?iso-8859-1?Q?XwwX8ILfS3ni7t9PW4HnSCjyUQ2oej2Z4EZXCbILWtVE2MikQDkkHc2L4P?=
 =?iso-8859-1?Q?nFgqrA6VF/yIggDM9I78lJz8YEzR3DBC9LBijH87Uyrw//4+TELcxRJTYY?=
 =?iso-8859-1?Q?9gGVVQ4=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?sM6adaUoG6n5t05kQG23I1Y88LloOemG1ktX3x438fcVjygK+eRps/IJ14?=
 =?iso-8859-1?Q?NvU92GifetE8KbEiutm+0BlS9XJ5/iJqORUOl+ZkB+x+U9payRKShPGAwX?=
 =?iso-8859-1?Q?iWHeGetZT6do9UryYZ0T1kEe4lknICATL/AO62y6FgHbWR2/5uA59FTC6D?=
 =?iso-8859-1?Q?IZ3bm96ff53jFMEKaQ7FyN4AQHKc3TbzpNkRi+00mdF7ssCE3h1jpeIAY0?=
 =?iso-8859-1?Q?xmnW3KBbXJFUHU9yQThtIkfDQDdaXheXBhAhDji+5Eavj8LENWZQrbjtvw?=
 =?iso-8859-1?Q?utnGIhPaDT7IGZX/itVx33s7YHJHrXhwItL5n7o27rbBSn9NP2c9IGlV6Y?=
 =?iso-8859-1?Q?ZSf1v4TkZIZxvbPj9645z9dSdcngz/TbjmDbbIVsmMBEdJJiSNd9Jk1XWk?=
 =?iso-8859-1?Q?BCqfHIjOSMs4RLBAiyiCiIMoKS4V28gFUjOJ8zgTGKV4dWI64uqZWBGI3M?=
 =?iso-8859-1?Q?SGqqZkKREHPzYfK4LmlEJ7F6VGzH0c+ma9AGy4hSAZtUXZpARogShlkbFY?=
 =?iso-8859-1?Q?Y0Ca8CxgvU26tQbjKJNLIlR6AK1U8GmcZ1i5qgJD3tTKH76hveJZRHhzMW?=
 =?iso-8859-1?Q?O6RGD1h5Y72XKktWJ3JrP5VKN17yi1Gf1hXtnbDZvNQL0azKJ/6fCE7gaL?=
 =?iso-8859-1?Q?XI69cbD0x3jthjPNRYxEgVgwiKg3HEhNheoubtjrUIVayg0IODdU6pN/dP?=
 =?iso-8859-1?Q?F3QlI4LgdUA0rogNTmEHCnz8kCQpyLnirLR188t3y42EYTbAtqCj7A46jA?=
 =?iso-8859-1?Q?bo8wibTH3GPu9FYMXF/HbVA4coLc+LELyvH6b1FdiAaqCa313/yz7QCBzL?=
 =?iso-8859-1?Q?/Dp2n5mSHVwFssgx0WKPvkEO//yDbPPAjIMu+ZlUZ0bbFdR7F0Q3he3lxW?=
 =?iso-8859-1?Q?8qOa7VG5MQATh+995kR2P3nJLI5fHq5uFrNWafQae1+NcULb935Y67gclq?=
 =?iso-8859-1?Q?phNDbcJIf+Jg3i9x5c58grYFtYfyrkoTkt1w1r/VKXSOI4RurWIBMssLow?=
 =?iso-8859-1?Q?0t2Hu74Ftmhm59Jp3MZTOQ9qGVBf7ccZXqaBKz1W6g/c0Cd1D1AhJY653c?=
 =?iso-8859-1?Q?HZoGWeRP+ss0C13Tebqy9ZkvCMlGJDJMf0YbS9EjJcrJozbh1ylIGctsYs?=
 =?iso-8859-1?Q?JaYQIijj5Jxr56y3qZLK2XypqBv1BqfsCPWZTLsUP+WEHuLQQFbCxobwKg?=
 =?iso-8859-1?Q?n2m+3sFZzm6+036+xZlmKSKu7pZ/zeJ9/LqwtIGPus+4T5t/g+/Va+Qykb?=
 =?iso-8859-1?Q?yXkM9bF2cwcyK3K0vGz6tQWUok64Z9EPtNbt8FCLbpKT2KfDgYsLOuUZff?=
 =?iso-8859-1?Q?iwoWgclv+NWojsyTSVaJt+gy9widWbqEyVox72aKNlYEG16T9jLeFV5mTu?=
 =?iso-8859-1?Q?PBMyLcwNngHAaUy4x3nRVgFX724AnozMy6nxVcCrHluS9gWUIblG/tEDWz?=
 =?iso-8859-1?Q?sCnPWBrRTtHCkvjJ7pngtloUbNuCHy+unAyJA9jJQttzPxO2X4aK8+EOYd?=
 =?iso-8859-1?Q?/06kHMHjwNwBWMGxZh1i6Q4udM30WarAFQQ8gv+YV06PJ0PzgrICjv/9t+?=
 =?iso-8859-1?Q?sJpD3XVGF8Zu6l5TDiqH9/NbuHmd0/pnmT73tet/iVos37mT239rjSrHPF?=
 =?iso-8859-1?Q?XhQVH4CTfhSSkE7qktySglzLiovNd79Wy/mtU/ij6oVAyBphZNvxGvxw?=
 =?iso-8859-1?Q?=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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 136e7324-6871-43b5-f1f9-08dd96ecf1e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 15:50:56.7823
 (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: P1oExcoDz+9OYdvdYTCS4JCjf7kYyT+g152tiYi/7Ny+EcLclzLaBV4ohuV8Zzvino0+Ds39FQ24BsOGq6gbiyTYGXPNIFclEdBpIXZEPHc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9023

From: Grygorii Strashko 

The commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls
handling layer") introduces simple driver which forwards SCMI over SMC
calls from hwdom/dom0 to EL3 firmware (TF-A) with a single SCMI OSPM agent
support. While it is working gracefully for hwdom/dom0 use case it doesn't
cover "thin Dom0 with guest domain, which serves as Driver domain"
use-case. In this case HW need to be enable in Driver domain and dom0 is
performing only control functions.

The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is
pretty generic case for the default vendors SDK and new platforms.

This patch enables passthrough of SCMI SMC single agent interface to the
one guest domain serving as Driver domain.

Configure Dom0 to enable SCMI passthrough:

 - dom0: add dom0_scmi_smc_passthrough to the Xen Command Line

Enabled SCMI passthrough for guest using toolstack in the following way:

 - domD: xl.cfg add "arm_sci" option as below

   arm_sci =3D "type=3Dscmi_smc"

 - domD: xl.cfg enable access to the "arm,scmi-shmem"

iomem =3D [
    "47ff0,1@22001",
]

 - domD: add SCMI nodes to the Driver domain partial device tree as in the
 below example:

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";
                shmem =3D <&scmi_shm_0>;
                ...
            }
    }
}

dom0less case configuration:

- add "xen,sci_type" property for required DomU ("xen,domain") node

   xen,sci_type=3D"scmi_smc"

- add scmi nodes to the Driver domain partial device tree the same way
as above and enable access to the "arm,scmi-shmem" according to
dom0less documentation. For example:

  scmi_shm_0: sram@22001000 {
        compatible =3D "arm,scmi-shmem";
        reg =3D <0x00 0x22001000 0x00 0x1000>;
->        xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>;
->        xen,force-assign-without-iommu;
  };

The SCMI SMC single agent interface can be enabled for one and only one
domain. In general, the configuration is similar to any other HW
passthrough, except explicitly enabling SCMI with "arm_sci" xl.cfg option.

Note that "arm,scmi-smc" and "arm,scmi-shmem" nodes will be removed from
dom0/hwdom DT in case of

Signed-off-by: Grygorii Strashko 
Signed-off-by: Oleksii Moisieiev 
---

Changes in v4:
- xl.cfg doc
- fix comments from Stefano Stabellini
- fix toolstack code as sugested by Anthony PERARD
  - use MATCH_OPTION()
  - move arm_sci struct and cfg params in "arch_arm"
- add SCMI passthrough for dom0less case

 docs/man/xl.cfg.5.pod.in              |  34 ++++++++
 docs/misc/arm/device-tree/booting.txt |  15 ++++
 docs/misc/xen-command-line.pandoc     |   9 +++
 tools/include/libxl.h                 |   5 ++
 tools/libs/light/libxl_arm.c          |  14 ++++
 tools/libs/light/libxl_types.idl      |  10 +++
 tools/xl/xl_parse.c                   |  36 +++++++++
 xen/arch/arm/dom0less-build.c         |  33 +++++++-
 xen/arch/arm/firmware/Kconfig         |   4 +-
 xen/arch/arm/firmware/scmi-smc.c      | 112 +++++++++++++++++++++++++-
 10 files changed, 267 insertions(+), 5 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 8e1422104e..1ccf50b8ea 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3092,6 +3092,40 @@ Otherwise, the value specified by the `nr_spis` para=
meter will be used.
 The number of SPIs should match the highest interrupt ID that will be
 assigned to the domain.
=20
+=3Ditem B
+
+Set ARM_SCI specific options for the guest. ARM SCI is System
+Control Protocol allows domain to manage various functions that are provid=
ed
+by HW platform firmware.
+
+B is a comma separated list of C settings,
+from the following list:
+
+=3Dover 4
+
+=3Ditem B
+
+Specifies an ARM SCI type for the guest.
+
+=3Dover 4
+
+=3Ditem B
+
+Don't allow guest to use ARM SCI if present on the platform. This is the
+default value.
+
+=3Ditem B
+
+Enables ARM SCMI SMC support for the guest by enabling SCMI over SMC calls
+forwarding from domain to the EL3 firmware (like Trusted Firmware-A) with =
a
+single SCMI OSPM agent support.
+Should be used together with B Xen command line
+option.
+
+=3Dback
+
+=3Dback
+
 =3Dback
=20
 =3Dhead3 x86
diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-t=
ree/booting.txt
index 9c881baccc..8943c04173 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -281,6 +281,21 @@ with the following properties:
     passed through. This option is the default if this property is missing
     and the user does not provide the device partial device tree for the d=
omain.
=20
+- xen,sci_type
+
+    A string property specifying an ARM SCI type for the guest.
+
+    - "none"
+    Don't allow guest to use ARM SCI if present on the platform. This is t=
he
+    default value.
+
+    - "scmi_smc"
+    Enables ARM SCMI SMC support for the guest by enabling SCMI over SMC c=
alls
+    forwarding from domain to the EL3 firmware (like Trusted Firmware-A) w=
ith a
+    single SCMI OSPM agent support.
+    Should be used together with dom0_scmi_smc_passthrough Xen command lin=
e
+    option.
+
 Under the "xen,domain" compatible node, one or more sub-nodes are present
 for the DomU kernel and ramdisk.
=20
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line=
.pandoc
index 9bbd00baef..8e50f6b7c7 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1082,6 +1082,15 @@ affinities to prefer but be not limited to the speci=
fied node(s).
=20
 Pin dom0 vcpus to their respective pcpus
=20
+### dom0_scmi_smc_passthrough (ARM)
+> `=3D `
+
+The option is available when `CONFIG_SCMI_SMC` is compiled in, and allows =
to
+enable SCMI SMC single agent interface for any, but only one guest domain,
+which serves as Driver domain. The SCMI will be disabled for Dom0/hwdom an=
d
+SCMI nodes removed from Dom0/hwdom device tree.
+(for example, thin Dom0 with Driver domain use-case).
+
 ### dtuart (ARM)
 > `=3D path [:options]`
=20
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index f8fe4afd7d..5fa43637ab 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -313,6 +313,11 @@
  */
 #define LIBXL_HAVE_BUILDINFO_ARCH_NR_SPIS 1
=20
+/*
+ * libxl_domain_build_info has the arch_arm.sci* fields.
+ */
+#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_SCI 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 28cea1f643..28ba9eb787 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -222,6 +222,20 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl =3D d_config->b_info.arch_arm.sve_vl / 128U;
     }
=20
+    switch (d_config->b_info.arch_arm.arm_sci.type) {
+    case LIBXL_ARM_SCI_TYPE_NONE:
+        config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
+        break;
+    case LIBXL_ARM_SCI_TYPE_SCMI_SMC:
+        config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
+        break;
+    default:
+        LOG(ERROR, "Unknown ARM_SCI type %d",
+            d_config->b_info.arch_arm.arm_sci.type);
+        return ERROR_FAIL;
+    }
+    LOG(DEBUG, " - SCI type=3D%u", config->arch.arm_sci_type);
+
     return 0;
 }
=20
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_type=
s.idl
index 33c9cfc1a2..aa2190ab5b 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -551,6 +551,15 @@ libxl_sve_type =3D Enumeration("sve_type", [
     (2048, "2048")
     ], init_val =3D "LIBXL_SVE_TYPE_DISABLED")
=20
+libxl_arm_sci_type =3D Enumeration("arm_sci_type", [
+    (0, "none"),
+    (1, "scmi_smc")
+    ], init_val =3D "LIBXL_ARM_SCI_TYPE_NONE")
+
+libxl_arm_sci =3D Struct("arm_sci", [
+    ("type", libxl_arm_sci_type),
+    ])
+
 libxl_rdm_reserve =3D Struct("rdm_reserve", [
     ("strategy",    libxl_rdm_reserve_strategy),
     ("policy",      libxl_rdm_reserve_policy),
@@ -725,6 +734,7 @@ libxl_domain_build_info =3D Struct("domain_build_info",=
[
                                ("vuart", libxl_vuart_type),
                                ("sve_vl", libxl_sve_type),
                                ("nr_spis", uint32),
+                               ("arm_sci", libxl_arm_sci),
                               ])),
     ("arch_x86", Struct(None, [("msr_relaxed", libxl_defbool),
                               ])),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 9a3679c023..bd22be9d33 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1284,6 +1284,36 @@ out:
     if (rc) exit(EXIT_FAILURE);
 }
=20
+static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci,
+                                const char *str)
+{
+    int ret =3D 0;
+    char *buf2, *ptr;
+    char *oparg;
+
+    if (NULL =3D=3D (buf2 =3D ptr =3D strdup(str)))
+        return ERROR_NOMEM;
+
+    ptr =3D strtok(buf2, ",");
+    while (ptr !=3D NULL)
+    {
+        if (MATCH_OPTION("type", ptr, oparg)) {
+            ret =3D libxl_arm_sci_type_from_string(oparg, &arm_sci->type);
+            if (ret) {
+                fprintf(stderr, "Unknown ARM_SCI type: %s\n", oparg);
+                ret =3D ERROR_INVAL;
+                goto parse_error;
+            }
+        }
+
+        ptr =3D strtok(NULL, ",");
+    }
+
+parse_error:
+    free(buf2);
+    return ret;
+}
+
 void parse_config_data(const char *config_source,
                        const char *config_data,
                        int config_len,
@@ -2981,6 +3011,12 @@ skip_usbdev:
     if (!xlu_cfg_get_long (config, "nr_spis", &l, 0))
         b_info->arch_arm.nr_spis =3D l;
=20
+    if (!xlu_cfg_get_string(config, "arm_sci", &buf, 1)) {
+        if (parse_arm_sci_config(config, &b_info->arch_arm.arm_sci, buf)) =
{
+            exit(EXIT_FAILURE);
+        }
+    }
+
     parse_vkb_list(config, d_config);
=20
     d_config->virtios =3D NULL;
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a09c4c4bd7..0a00f03a25 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -815,6 +815,36 @@ static int __init construct_domU(struct domain *d,
     return rc;
 }
=20
+int __init domu_dt_sci_parse(struct dt_device_node *node,
+                             struct xen_domctl_createdomain *d_cfg)
+{
+    const char *sci_type =3D NULL;
+    int ret;
+
+    d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
+
+    if ( !IS_ENABLED(CONFIG_ARM_SCI) ||
+         !dt_property_read_bool(node, "xen,sci_type") )
+        return 0;
+
+    ret =3D dt_property_read_string(node, "xen,sci_type", &sci_type);
+    if ( ret )
+        return ret;
+
+    if ( !strcmp(sci_type, "none") )
+        d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
+    else if ( !strcmp(sci_type, "scmi_smc") )
+        d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
+    else
+    {
+        printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n"=
,
+               sci_type, dt_node_name(node));
+        return -EINVAL;
+    }
+
+    return 0;
+}
+
 void __init create_domUs(void)
 {
     struct dt_device_node *node;
@@ -975,7 +1005,8 @@ void __init create_domUs(void)
         if ( !llc_coloring_enabled && llc_colors_str )
             panic("'llc-colors' found, but LLC coloring is disabled\n");
=20
-        d_cfg.arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
+        if ( domu_dt_sci_parse(node, &d_cfg) )
+            panic("Error getting SCI configuration\n");
=20
         /*
          * The variable max_init_domid is initialized with zero, so here i=
t's
diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
index bbf88fbb9a..5c5f0880c4 100644
--- a/xen/arch/arm/firmware/Kconfig
+++ b/xen/arch/arm/firmware/Kconfig
@@ -25,7 +25,9 @@ config SCMI_SMC
 	  doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
 	  compatible only). The value of "arm,smc-id" DT property from SCMI
 	  firmware node is used to trap and forward corresponding SCMI SMCs
-	  to firmware running at EL3, for calls coming from the hardware domain.
+	  to firmware running at EL3, for calls coming from the hardware domain o=
r
+	  driver domain.
+	  Use with EL3 firmware which supports only single SCMI OSPM agent.
=20
 endchoice
=20
diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-=
smc.c
index 13d1137592..7470a21505 100644
--- a/xen/arch/arm/firmware/scmi-smc.c
+++ b/xen/arch/arm/firmware/scmi-smc.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
=20
@@ -22,7 +24,11 @@
=20
 #define SCMI_SMC_ID_PROP   "arm,smc-id"
=20
+static bool __ro_after_init opt_dom0_scmi_smc_passthrough =3D false;
+boolean_param("dom0_scmi_smc_passthrough", opt_dom0_scmi_smc_passthrough);
+
 static uint32_t __ro_after_init scmi_smc_id;
+static struct domain __read_mostly *scmi_dom;
=20
 /*
  * Check if provided SMC Function Identifier matches the one known by the =
SCMI
@@ -50,7 +56,7 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs)
         return false;
=20
     /* Only the hardware domain should use SCMI calls */
-    if ( !is_hardware_domain(current->domain) )
+    if ( scmi_dom !=3D current->domain )
     {
         gdprintk(XENLOG_WARNING, "SCMI: Unprivileged access attempt\n");
         return false;
@@ -75,12 +81,45 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs)
     return true;
 }
=20
+static int
+scmi_smc_domain_sanitise_config(struct xen_domctl_createdomain *config)
+{
+    if ( config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE &&
+         config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC=
 )
+        return -EINVAL;
+
+    return 0;
+}
+
 static int scmi_smc_domain_init(struct domain *d,
                                 struct xen_domctl_createdomain *config)
 {
-    if ( !is_hardware_domain(d) )
+    /*
+     * scmi_passthrough is not enabled:
+     * - proceed only for hw_domain
+     * - fail if guest domain has SCMI enabled.
+     */
+    if ( !opt_dom0_scmi_smc_passthrough && !is_hardware_domain(d) )
+    {
+        if ( config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_SC=
MI_SMC )
+            return -EINVAL;
+        else
+            return 0;
+    }
+    /*
+     * scmi_passthrough is enabled:
+     * - ignore hw_domain
+     * - proceed only for domain with SCMI enabled.
+     */
+    if ( opt_dom0_scmi_smc_passthrough &&
+         (config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE =
||
+          is_hardware_domain(d)) )
         return 0;
=20
+    if ( scmi_dom )
+        return -EEXIST;
+
+    scmi_dom =3D d;
     d->arch.sci_enabled =3D true;
     printk(XENLOG_DEBUG "SCMI: %pd init\n", d);
     return 0;
@@ -88,12 +127,77 @@ static int scmi_smc_domain_init(struct domain *d,
=20
 static void scmi_smc_domain_destroy(struct domain *d)
 {
-    if ( !is_hardware_domain(d) )
+    if ( scmi_dom && scmi_dom !=3D d )
         return;
=20
+    scmi_dom =3D NULL;
+    d->arch.sci_enabled =3D false;
     printk(XENLOG_DEBUG "SCMI: %pd destroy\n", d);
 }
=20
+/*
+ * Handle Dom0 SCMI SMC specific DT nodes
+ *
+ * if dom0_scmi_smc_passthrough=3Dfalse:
+ * - Copy SCMI nodes into Dom0 device tree.
+ * if dom0_scmi_smc_passthrough=3Dtrue:
+ * - skip SCMI nodes from Dom0 DT
+ * - give dom0 control access to SCMI shmem MMIO, so SCMI can be passed
+ *   through to guest.
+ */
+static bool scmi_smc_dt_handle_node(struct domain *d,
+                                    struct dt_device_node *node)
+{
+    static const struct dt_device_match shmem_matches[] __initconst =3D {
+        DT_MATCH_COMPATIBLE("arm,scmi-shmem"),
+        { /* sentinel */ },
+    };
+    static const struct dt_device_match scmi_matches[] __initconst =3D {
+        DT_MATCH_PATH("/firmware/scmi"),
+        { /* sentinel */ },
+    };
+
+    /* 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;
+    }
+
+    /*
+     * skip scmi node for dom0 if scmi not enabled, but give dom0 control
+     * access to SCMI shmem
+     */
+    if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) )
+    {
+        struct dt_device_node *shmem_node;
+        const __be32 *prop;
+        u64 paddr, size;
+        int ret;
+
+        /* give dom0 control access to SCMI shmem */
+        prop =3D dt_get_property(node, "shmem", NULL);
+        if ( !prop )
+            return true;
+
+        shmem_node =3D dt_find_node_by_phandle(be32_to_cpup(prop));
+        if ( !shmem_node )
+            return true;
+
+        ret =3D dt_device_get_address(shmem_node, 0, &paddr, &size);
+        if ( ret )
+            return true;
+
+        ret =3D iomem_permit_access(d, paddr_to_pfn(paddr),
+                                  paddr_to_pfn(paddr + size - 1));
+
+        dt_dprintk("Skip scmi node\n");
+        return true;
+    }
+
+    return false;
+}
+
 static int __init scmi_check_smccc_ver(void)
 {
     if ( smccc_ver < ARM_SMCCC_VERSION_1_1 )
@@ -108,8 +212,10 @@ static int __init scmi_check_smccc_ver(void)
=20
 static const struct sci_mediator_ops scmi_smc_ops =3D {
     .handle_call =3D scmi_handle_smc,
+    .domain_sanitise_config =3D scmi_smc_domain_sanitise_config,
     .domain_init =3D scmi_smc_domain_init,
     .domain_destroy =3D scmi_smc_domain_destroy,
+    .dom0_dt_handle_node =3D scmi_smc_dt_handle_node,
 };
=20
 /* Initialize the SCMI layer based on SMCs and Device-tree */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon May 19 15:51:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:51:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989965.1373965 (Exim 4.92)
	(envelope-from )
	id 1uH2lh-0006K8-F9; Mon, 19 May 2025 15:51:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989965.1373965; Mon, 19 May 2025 15: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 1uH2lh-0006JU-7Z; Mon, 19 May 2025 15:51:09 +0000
Received: by outflank-mailman (input) for mailman id 989965;
 Mon, 19 May 2025 15:51:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2lf-00055d-Pa
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:51:08 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20625.outbound.protection.outlook.com
 [2a01:111:f403:260e::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 12aab7cd-34c9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 17:51:05 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB9023.eurprd03.prod.outlook.com (2603:10a6:20b:5b7::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.29; Mon, 19 May
 2025 15:50:58 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8722.031; Mon, 19 May 2025
 15:50: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" 
X-Inumbo-ID: 12aab7cd-34c9-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=D+LixnOzErXoe9vOhFNbjwBMYj0ImXWY/bX8L8BgaHgtiSRhrI45NROOWupKXcofNYmAZYr4kkzauuzn/L86bq2RoAJdyG+FnJ6YDfJj32X3FIAPTWE5QThAn/d5dUH3XBBXcaKFZQXdKZ4EWCE4uRdeoauHVjls6ky4REwDbNn1nsSYrKO9JoHfKptt0Cjvnksk6vzRwL9MnT8wfmrGtqxN+9sIUHseMDyBYGMILKQQf3sxzoL++RRZOWmdjWZeCMHXS4hVn5sr6CQ++TnaO0QiL1auUIOkFvdGqmgzAWl2p/D++p78SMzfPjzwXH2acV5/U4odZr7WG38fEnLJqg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=T95PAVbCzhHKP7RYhZufYK99SRLDzb3IXsU04ArQbxs=;
 b=YMS+rf692s1SjaRHChDcEJ2D3ygiax1GcfxGziDsD//kTJuWKSqRsj57sHEVhBX4Ktr4HShttnEmdIswr5ukeeBXZ2+QwWdWEPyO88F1rVvUD1ms5wzqtS4F6NZrBtQvf+NaZmVVwpahpI6eItqyz0B18zZ4LjtKtXi5o8f+jmHIoYLkw2KrWDsOIzdbvpIrtuzoLi2m7TH01JOGovwIBkwQxLW9mrAD6EA9plKVLlfu1zWSH7Sm22OyCw3JEi5t6dG7XGdCid3A/VsxSbj0AS5pv1QrwYlqdkzvcdlJAvI2UrGjH14VV40/orPBWO13hL8rUyp0ddwFLfQNHEsNbg==
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=T95PAVbCzhHKP7RYhZufYK99SRLDzb3IXsU04ArQbxs=;
 b=iFLy/SvxwbZr65v5iegU0aRE0KTemVy853sFIpFLRk8xrbuf1L/hFTQKho3utDK73KAcsRc7WqZAc37LOeG3cSLhQ14Ys7T977kORapDsHl+fLNBz/jgozxM4EAAK5CPSaZSGL/vgodoJujClSExP2QMvgprpyfKPzww0uPAVKlRq2B0CUmvB7Qd8KI5LvuhixCxcKBEu/fTfCiCsV0ZhZJMvukjmGzv1sFKS8XoI0LE8V6x6kv+Vh9CsXN0eGHkuVUdLPQ7huXXcMB2cjGzqSXXDsKonksonVf7wImp/EPEPXYZhpi4AR7Gkgq9KEn7BuNeasu//M2H652Xc8ZYuQ==
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: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent
 driver
Thread-Topic: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
Thread-Index: AQHbyNXPHUV4T01ZEEC9Uxm0LaLKHQ==
Date: Mon, 19 May 2025 15:50:57 +0000
Message-ID:
 <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB9023:EE_
x-ms-office365-filtering-correlation-id: f2c928e0-13ca-48f0-5537-08dd96ecf2d0
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?d7lB4ovUmioDg3SccrXN98XKvMbJKTQcG3LC0ncbZIXKkQ6n7NMm1JcoaU?=
 =?iso-8859-1?Q?lwRX10fUCy0UxOWXEg2b/iHMEUYPHUa4I6AYCyhYm4XiGe6l2SMPQNtrGe?=
 =?iso-8859-1?Q?7c26iCKeBoKOn+lmn7ym0cphmljAobn4+Raf85ikUAYQm2OWxd4kXRdsdO?=
 =?iso-8859-1?Q?OWZtRxb2eid+YFjJ92Y/NFPunc7CkKDPSbMwX+PGokSyRvsat2xscwQbuK?=
 =?iso-8859-1?Q?tt/6fz+xc/FFHncF+dGL5SeCgrzNtXy68jv3Oo/Fo0l356dbl4yFPvMCbH?=
 =?iso-8859-1?Q?FcyW5O16R2hr1dWal423xIoRtvcpuAA+FSGUBsg5cMTDkaY8GJXx79FH+n?=
 =?iso-8859-1?Q?iGECuyXaWMVOk41CyjzBsE9GZUyb1rRq18x1W1lfFRHSkaPHZY7albNoDp?=
 =?iso-8859-1?Q?AtGXFp4r+W8maIM89G9WZ0E/s5mN0T5f+Z+ZJ3EQwoGqmVU0X4/4Ygh64F?=
 =?iso-8859-1?Q?Fptlx//ywG+Ud6CIT9uBF15UFjd73+p+7YfzN1775Llb/zrgi6FdYZgGHn?=
 =?iso-8859-1?Q?0/ItzsNraEdisLmONEVoZGs1nchrZbhWV4/YTpQLG1b08Mt/V1ZVI0ryU3?=
 =?iso-8859-1?Q?kmnoYm2dQ1D+UBvIc7RySKCbpc28JZs/0TgyEB2hwLvT19M2DXubAWaLbW?=
 =?iso-8859-1?Q?aooMdTEShn7MWI6GFoP59ntbBgRZVNeLp7Baal3WhgyYL1TtzwyFC3kFas?=
 =?iso-8859-1?Q?MNbXzi/Nf0dbjoB6uO6BOClY7T7HKrNJGZpqqiyvFKdrznftUIY6W0awqy?=
 =?iso-8859-1?Q?tT1fuTzhJePc/47fSaixzcbbf/FqwNGgq+PUU2YNVYvuSAbk3rR6PZpnvG?=
 =?iso-8859-1?Q?CQhQBO8c7aG9u3gIbOgW82z28GEAsVvutiiWG7paWo7NG375zRM0Tw2CLv?=
 =?iso-8859-1?Q?4gb0O3oic6WuYXfFmzM+ZEg76SAIdEKlGCQI1FeL2ZhOX3JVV/gsiv3kmj?=
 =?iso-8859-1?Q?GmQ3kTAMKnfxYvKSpIhHoSseuSffx7oeY8jTpSQNxOfLxeq4kTpEaYeRvz?=
 =?iso-8859-1?Q?M87VikGQ/ilPfExnr14WDvtqoBMsJ+J44xoW9TAqI8/8n2x714GmWjyUlm?=
 =?iso-8859-1?Q?nW59U9NsGUKb+ZCD6IXcj7Uxig1oY3GuS/g/c+B0ODuUxsxwcotcRlziXR?=
 =?iso-8859-1?Q?4aNBcT/SsugI/gyYJVvJLDFGpiRfxwp0+dwKCkCNJf7hUJNXy13aE9YVko?=
 =?iso-8859-1?Q?I0cw/HOZZae31OPwGQYcSvQ6b4iz8gGsHLXi0ZDIhca5lbP/oG47qlYQla?=
 =?iso-8859-1?Q?ZGIqtuT/uIDav3kAZqbARffLd3B1Ub2ZexXDN2QT6fJT5PzboHFPwCaM05?=
 =?iso-8859-1?Q?u0/CAi09CjoIDe0IjkvKH+EHoNLTMW5JFDNU80ebS/MDU26WRAtInc8eNF?=
 =?iso-8859-1?Q?Olh6N/9K0FliBdNQFQ0McLPufH9L/3A4bTS0+oTN7NDv6fUpaRIHaLHrBB?=
 =?iso-8859-1?Q?s1amDPnxtozgXuvPUgFKBkURMtkcs/0ZnPQ8SN+h56jCZQga2bm51oFyO4?=
 =?iso-8859-1?Q?w=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Oip3u8uQMcD9avsLLj3/jjXNDaB9aGmWdmwbM5ExdMatVG/Ni/g99B6/8J?=
 =?iso-8859-1?Q?GvO8miS2U93l/MOtqytjPdCTHduSnSmIoNIf7c/8ExF5U3oCayO2s1hoEl?=
 =?iso-8859-1?Q?dOHAoLoi7RQMaQbV1PQeDfQtqL4VWgzRbQ+sEu7yLKzO/sR94NOVlKYQEj?=
 =?iso-8859-1?Q?ACZpeIROlppe6JJSgLm4NZ1OQF9iJm9sh1AgUl9EDsC1v2RkxmOUJWx6dq?=
 =?iso-8859-1?Q?01MfGfU4TzjY2y1KUdyqYfqfGxNbCLKD1x+QVFpNXNYC4zORDZwrXJv5Fx?=
 =?iso-8859-1?Q?tytDZHKKjX44soE+4oiELzPydNKS1F2ZuCP+ah2Hn160Iq4GK/8mZ4dKbP?=
 =?iso-8859-1?Q?laSnbdpD1Qo2eNef6brQ9OYlkHP+E6sI6acSyKH7pTVAQ87v2L01Cja6HV?=
 =?iso-8859-1?Q?6uQIjzwHg0Tsfr/2xvaJOzveLuA/+KxzNLo8DOjkj9lG7VoGUlvs6uIDYZ?=
 =?iso-8859-1?Q?+vIlgNPRBLu7H4h40SE2xgDujeP2CLSD9vkyMQk//WLQHSWbjz2Hs3jyQf?=
 =?iso-8859-1?Q?reN4f3aF5ygQnmPo3mvSDbmgfH1xDHhSRD/13k2BeyDGLln4pGjcUVbpEh?=
 =?iso-8859-1?Q?e6bPS5k1WeEKL7onvFAqA6+8o5tvZSI72SuYbljFLB95KGlZmHUiu/90mf?=
 =?iso-8859-1?Q?CpIPEVd0OfHKbov1m0Y6leTewgy4ZUUYJP0tnOLVgHsIMOYQESdB1cmIta?=
 =?iso-8859-1?Q?KuDQW52phaVv1ECUovzSi8/1o733kzbtdJDHOKcqqvSZ5BC/E8JjtO3Erq?=
 =?iso-8859-1?Q?pj8zTbqiC6MAq+XwvLsqQK/vOeF0QeJV1gq3+xoEI6qiqznsgLij+x2Vfe?=
 =?iso-8859-1?Q?E9MyFBD8g8HVpAGihMcTCg0VX/kkpWiiJ+8jY3q5AA7TEktoWLl/uw6gRm?=
 =?iso-8859-1?Q?Gf26VOoNixL3XSZ4OcdsCSSnTtwG+xsZpThsHiShLmSAdr/7Ja2xYF3hIR?=
 =?iso-8859-1?Q?bXvFREVafFWgKyTGG0WMQYznKkbiTtsqCQEGsxc4MIMmoiZDhhbKrHdMBp?=
 =?iso-8859-1?Q?259TS9/GKjHLBjlA9RtM6GmiiHtieyglbVV6+HN3GTNUuSdIvL4caZkVyH?=
 =?iso-8859-1?Q?mFkVVVM9jBJ0N0ykkFvHzXwH6XQ4UkteA0XHgtzKXNdFemfiqD6vz5ZWSk?=
 =?iso-8859-1?Q?9kP/zar4Q6juamJqGr4IZZO/EqSZpCUUe1fFNKjwuF5VDkNubDRsc5+TNI?=
 =?iso-8859-1?Q?jokdV9bLapDWMpmVKFkAnSK/dSyyqs/2fR0i++qIA7RmxTfwZptguzIQi7?=
 =?iso-8859-1?Q?QlRFFrdjQ0GwGpDjFrVtfpq7kONm6JNIWwOfjT1f5xidwMLT48rt3bLyQR?=
 =?iso-8859-1?Q?Gk8M1X8tgZU7dFkurhznYr1+hIZTAv+Y5F0n4POx2i+hontAFL+3ZlK4n4?=
 =?iso-8859-1?Q?YZx/2n6OZc1QpRNWBydMi57ptVMG0q2wdUvOhg/ik1MgDZLXFwTDEgXL+Y?=
 =?iso-8859-1?Q?F116R0gf9NGksnSBpUkwrZPds1Z9kWMSx1gDngWYa6ky5rYCrZxn357tRr?=
 =?iso-8859-1?Q?PffLxbhVpLYS+66AKqPmGIrts6bHUuUZB88097J9jj6EuKhmRe/pZJhv0S?=
 =?iso-8859-1?Q?076BjtF6+jtKLnveo9+DRBbJa7RSaaEeAtdMmFsI7TtVjYmomR24bhUwt3?=
 =?iso-8859-1?Q?klBWo9Rf67r4RSBPH+7IIlWv/oNCzJVqfICZRfhi5UmFtFDqTYUtYgNA?=
 =?iso-8859-1?Q?=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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f2c928e0-13ca-48f0-5537-08dd96ecf2d0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 15:50:57.7394
 (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: +ZN2yV/Dgc1AZ5XoiZ4C+AJMCk5coysW6Ydddhf2krFNKd9ig8WTbhPSYF1+F1m6m1BcWfEvWsKOKHyQzK9LCJQAzFxnvc4LxYZzUls+S0o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9023

This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A
(TF-A) which provides SCMI interface with multi-agnet support, as shown
below.

  +-----------------------------------------+
  |                                         |
  | EL3 TF-A SCMI                           |
  +-------+--+-------+--+-------+--+-------++
  |shmem0 |  |shmem1 |  |shmem2 |  |shmemX |
  +-----+-+  +---+---+  +--+----+  +---+---+
smc-id0 |        |         |           |
agent0  |        |         |           |
  +-----v--------+---------+-----------+----+
  |              |         |           |    |
  |              |         |           |    |
  +--------------+---------+-----------+----+
         smc-id1 |  smc-id2|    smc-idX|
         agent1  |  agent2 |    agentX |
                 |         |           |
            +----v---+  +--v-----+  +--v-----+
            |        |  |        |  |        |
            | Dom0   |  | Dom1   |  | DomX   |
            |        |  |        |  |        |
            |        |  |        |  |        |
            +--------+  +--------+  +--------+

The EL3 SCMI multi-agent firmware expected to provide SCMI SMC/HVC shared
memory transport for every Agent in the system.

The SCMI Agent transport channel defined by pair:
 - smc-id: SMC/HVC id used for Doorbell
 - shmem: shared memory for messages transfer, Xen page aligned,
 p2m_mmio_direct_nc.

The follwoing SCMI Agents expected to be defined by SCMI FW to enable SCMI
multi-agent functionality under Xen:
- Xen manegement 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 expected to implement following Base protocol messages:
- BASE_DISCOVER_AGENT
- BASE_RESET_AGENT_CONFIGURATION (optional)
- BASE_SET_DEVICE_PERMISSIONS (optional)

The SCI SCMI SMC multi-agent driver implements following functionality:
- It's initialized based on the Host DT SCMI node (only one SCMI interface
is supported) which describes Xen management agent SCMI interface.

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>; // Xen manegement agent smc-id
        \#address-cells =3D < 1>;
        \#size-cells =3D < 0>;
        \#access-controller - cells =3D < 1>;
        shmem =3D <&scmi_shm_0>; // Xen manegement agent shmem

        protocol@X{
        };
    };
};

- It obtains Xen specific SCMI Agent's configuration from the Host DT,
probes Agents and build SCMI Agents list; The Agents configuration is taken=
 from:

chosen {
  xen,scmi-secondary-agents =3D <
		1 0x82000003 &scmi_shm_1
		2 0x82000004 &scmi_shm_2
		3 0x82000005 &scmi_shm_3
		4 0x82000006 &scmi_shm_4>;
}

/{
	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>;
	};
}
  where first item is "agent_id", second - "arm,smc-id", and third - "arm,s=
cmi-shmem" for
  this agent_id.

  Note that Xen is the only one entry in the system which need to know
  about SCMI multi-agent support.

- 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/HVC 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/HVC 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:
 - pass dom0_scmi_agent_id=3D in Xen command line. if not provide=
d
   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 as=
signed 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 th=
e 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" provid=
er 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 de=
vices should be bound
to the Xen SCMI.

&i2c1 {
	access-controllers =3D <&scmi 0>;
};

The Dom0 and dom0less domains DT devices will be processed automatically th=
rough
sci_assign_dt_device() call, but to assign SCMI devices from toolstack the =
xl.cfg:"dtdev" property
shell be used:

dtdev =3D [
    "/soc/i2c@e6508000",
]

xl.cfg:dtdev will contain all nodes which are under SCMI management (not on=
ly those which are behind IOMMU).

[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: Oleksii Moisieiev 
Signed-off-by: Grygorii Strashko 
---

Changes in v4:
- toolstack comments from Anthony PERARD
- added dom0less support
- added doc for "xen,scmi-secondary-agents"

 docs/man/xl.cfg.5.pod.in                    |  13 +
 docs/misc/arm/device-tree/booting.txt       |  60 ++
 docs/misc/xen-command-line.pandoc           |   9 +
 tools/libs/light/libxl_arm.c                |   4 +
 tools/libs/light/libxl_types.idl            |   4 +-
 tools/xl/xl_parse.c                         |  12 +
 xen/arch/arm/dom0less-build.c               |  11 +
 xen/arch/arm/domain_build.c                 |   3 +-
 xen/arch/arm/firmware/Kconfig               |  11 +
 xen/arch/arm/firmware/Makefile              |   1 +
 xen/arch/arm/firmware/scmi-proto.h          | 164 ++++
 xen/arch/arm/firmware/scmi-shmem.c          | 173 ++++
 xen/arch/arm/firmware/scmi-shmem.h          |  45 +
 xen/arch/arm/firmware/scmi-smc-multiagent.c | 860 ++++++++++++++++++++
 xen/include/public/arch-arm.h               |   3 +
 15 files changed, 1371 insertions(+), 2 deletions(-)
 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/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 1ccf50b8ea..302c46d8bc 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3122,8 +3122,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 a non-zero ARM SCI agent id for the guest. This option is mandat=
ory
+if the SCMI SMC support is enabled for the guest. The agent ids of domains
+existing on a single host must be unique and in the range [1..255].
+
 =3Dback
=20
 =3Dback
diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-t=
ree/booting.txt
index 8943c04173..c8923ab8b2 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -296,6 +296,20 @@ with the following properties:
     Should be used together with dom0_scmi_smc_passthrough Xen command lin=
e
     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 a non-zero ARM SCI 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 [1..=
255].
+
 Under the "xen,domain" compatible node, one or more sub-nodes are present
 for the DomU kernel and ramdisk.
=20
@@ -764,3 +778,49 @@ 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 shell be provided in the Host =
DT
+according to the SCMI compliant EL3 Firmware specification with
+ARM SMC/HVC transport using property "xen,scmi-secondary-agents" under
+the top-level "chosen" node:
+
+- xen,scmi-secondary-agents
+
+    Defines a set of SCMI agents configuration supported by SCMI EL3 FW an=
d
+    available for Xen. Each Agent defined as triple consisting of:
+    SCMI agent_id,
+    SMC/HVC function_id assigned for the agent transport ("arm,smc-id"),
+    phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem"=
).
+
+As an example:
+
+chosen {
+    xen,scmi-secondary-agents =3D <
+        1 0x82000003 &scmi_shm_1
+        2 0x82000004 &scmi_shm_2
+        3 0x82000005 &scmi_shm_3
+        4 0x82000006 &scmi_shm_4>;
+}
+
+/{
+        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_shm_3: sram@47ff4000 {
+                compatible =3D "arm,scmi-shmem";
+                reg =3D <0x0 0x47ff4000 0x0 0x1000>;
+        };
+}
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line=
.pandoc
index 8e50f6b7c7..bc3c64d6ec 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1091,6 +1091,15 @@ which serves as Driver domain. The SCMI will be disa=
bled for Dom0/hwdom and
 SCMI nodes removed from Dom0/hwdom device tree.
 (for example, thin Dom0 with Driver domain use-case).
=20
+### dom0_scmi_agent_id (ARM)
+> `=3D `
+
+The option is available when `CONFIG_SCMI_SMC_MA` is compiled in, and allo=
ws to
+enable SCMI functionality for Dom0 by specifying a non-zero ARM SCMI agent=
 id.
+The SCMI will be disabled for Dom0 if this option is not specified
+(for example, thin Dom0 or dom0less use-cases).
+The agent ids of domains existing on a single host must be unique.
+
 ### dtuart (ARM)
 > `=3D path [:options]`
=20
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 28ba9eb787..7712f53cd4 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -229,6 +229,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);
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_type=
s.idl
index aa2190ab5b..11e31ce786 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -553,11 +553,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 bd22be9d33..81aa3797e3 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1306,6 +1306,18 @@ 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 || val > 255) {
+                fprintf(stderr, "An invalid ARM_SCI agent_id specified (%l=
u). Valid range [1..255]\n",
+                        val);
+                ret =3D ERROR_INVAL;
+                goto parse_error;
+            }
+            arm_sci->agent_id =3D val;
+        }
+
         ptr =3D strtok(NULL, ",");
     }
=20
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 0a00f03a25..43d21eb889 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -835,6 +835,17 @@ int __init domu_dt_sci_parse(struct dt_device_node *no=
de,
         d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
     else if ( !strcmp(sci_type, "scmi_smc") )
         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 ( !dt_property_read_u32(node, "xen,sci_agent_id", &agent_id) ||
+             !agent_id )
+            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 36d28b52a4..0c9274a2b3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -616,7 +616,8 @@ static int __init write_properties(struct domain *d, st=
ruct kernel_info *kinfo,
                  dt_property_name_is_equal(prop, "linux,uefi-mmap-start") =
||
                  dt_property_name_is_equal(prop, "linux,uefi-mmap-size") |=
|
                  dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-siz=
e") ||
-                 dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver=
"))
+                 dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver=
") ||
+                 dt_property_name_is_equal(prop, "xen,scmi-secondary-agent=
s") )
                 continue;
=20
             if ( dt_property_name_is_equal(prop, "xen,dom0-bootargs") )
diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
index 5c5f0880c4..6b051c8ada 100644
--- a/xen/arch/arm/firmware/Kconfig
+++ b/xen/arch/arm/firmware/Kconfig
@@ -29,6 +29,17 @@ 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"
+	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..3f4b9c5d6b
--- /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) 2024 EPAM Systems
+ */
+
+#ifndef XEN_ARCH_ARM_SCI_SCMI_PROTO_H_
+#define XEN_ARCH_ARM_SCI_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 /* XEN_ARCH_ARM_SCI_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..dd613ee0b5
--- /dev/null
+++ b/xen/arch/arm/firmware/scmi-shmem.c
@@ -0,0 +1,173 @@
+/* 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
+ */
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include 
+#include 
+
+#include "scmi-proto.h"
+#include "scmi-shmem.h"
+
+/*
+ * Copy data from IO memory space to "real" memory space.
+ */
+static void __memcpy_fromio(void *to, const volatile void __iomem *from,
+                            size_t count)
+{
+    while ( count && !IS_ALIGNED((unsigned long)from, 4) )
+    {
+        *(u8 *)to =3D readb_relaxed(from);
+        from++;
+        to++;
+        count--;
+    }
+
+    while ( count >=3D 4 )
+    {
+        *(u32 *)to =3D readl_relaxed(from);
+        from +=3D 4;
+        to +=3D 4;
+        count -=3D 4;
+    }
+
+    while ( count )
+    {
+        *(u8 *)to =3D readb_relaxed(from);
+        from++;
+        to++;
+        count--;
+    }
+}
+
+/*
+ * Copy data from "real" memory space to IO memory space.
+ */
+static void __memcpy_toio(volatile void __iomem *to, const void *from,
+                          size_t count)
+{
+    while ( count && !IS_ALIGNED((unsigned long)to, 4) )
+    {
+        writeb_relaxed(*(u8 *)from, to);
+        from++;
+        to++;
+        count--;
+    }
+
+    while ( count >=3D 4 )
+    {
+        writel_relaxed(*(u32 *)from, to);
+        from +=3D 4;
+        to +=3D 4;
+        count -=3D 4;
+    }
+
+    while ( count )
+    {
+        writeb_relaxed(*(u8 *)from, to);
+        from++;
+        to++;
+        count--;
+    }
+}
+
+static inline int
+shmem_channel_is_free(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, int len)
+{
+    int ret;
+
+    if ( (len + sizeof(shmem->msg_header)) > SCMI_SHMEM_MAPPED_SIZE )
+    {
+        printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is invali=
d\n");
+        return -EINVAL;
+    }
+
+    ret =3D shmem_channel_is_free(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, int len)
+{
+    int recv_len;
+    int ret;
+    int pad =3D sizeof(hdr->status);
+
+    if ( len >=3D SCMI_SHMEM_MAPPED_SIZE - sizeof(shmem) )
+    {
+        printk(XENLOG_ERR
+               "scmi: Wrong size of input smc message. Data may be invalid=
\n");
+        return -EINVAL;
+    }
+
+    ret =3D shmem_channel_is_free(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..2f8e23ff76
--- /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 XEN_ARCH_ARM_SCI_SCMI_SHMEM_H_
+#define XEN_ARCH_ARM_SCI_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, int len);
+
+int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shme=
m,
+                       scmi_msg_header_t *hdr, void *data, int len);
+#endif /* XEN_ARCH_ARM_SCI_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..e023bca3a1
--- /dev/null
+++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c
@@ -0,0 +1,860 @@
+/* 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 "scmi-proto.h"
+#include "scmi-shmem.h"
+
+#define SCMI_AGENT_ID_INVALID 0xFF
+
+static uint8_t __initdata opt_dom0_scmi_agent_id =3D SCMI_AGENT_ID_INVALID=
;
+integer_param("dom0_scmi_agent_id", opt_dom0_scmi_agent_id);
+
+#define SCMI_SECONDARY_AGENTS "xen,scmi-secondary-agents"
+
+#define HYP_CHANNEL 0x0
+
+struct scmi_channel {
+    uint32_t agent_id;
+    uint32_t func_id;
+    domid_t domain_id;
+    uint64_t paddr;
+    uint64_t len;
+    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;
+    struct dt_device_node *dt_dev;
+};
+
+static struct scmi_data scmi_data;
+
+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;
+
+    arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0, &resp);
+
+    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 && channel->shmem);
+    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;
+
+    channel =3D get_channel_by_id(agent_id);
+    if ( channel )
+        return ERR_PTR(EEXIST);
+
+    channel =3D xmalloc(struct scmi_channel);
+    if ( !channel )
+        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);
+    return channel;
+}
+
+static void free_channel_list(void)
+{
+    struct scmi_channel *curr, *_curr;
+
+    list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list)
+    {
+        list_del(&curr->list);
+        xfree(curr);
+    }
+}
+
+static int __init
+scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *addr,
+                              u64 *size)
+{
+    struct dt_device_node *shmem_node;
+    const __be32 *prop;
+
+    prop =3D dt_get_property(scmi_node, "shmem", NULL);
+    if ( !prop )
+        return -EINVAL;
+
+    shmem_node =3D dt_find_node_by_phandle(be32_to_cpup(prop));
+    if ( IS_ERR_OR_NULL(shmem_node) )
+    {
+        printk(XENLOG_ERR
+               "scmi: Device tree error, can't parse reserved memory %ld\n=
",
+               PTR_ERR(shmem_node));
+        return PTR_ERR(shmem_node);
+    }
+
+    return dt_device_get_address(shmem_node, 0, addr, size);
+}
+
+/*
+ * Handle Dom0 SCMI specific DT nodes
+ *
+ * Make a decision on copying SCMI specific nodes into Dom0 device tree.
+ * For SCMI multi-agent case:
+ * - shmem nodes will not be copied and generated instead if SCMI
+ *   is enabled for Dom0
+ * - scmi node will be copied if SCMI is enabled for Dom0
+ */
+static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node *n=
ode)
+{
+    static const struct dt_device_match skip_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;
+
+    /* always drop shmem */
+    if ( dt_match_node(skip_matches, node) )
+    {
+        dt_dprintk("  Skip scmi shmem\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;
+}
+
+/*
+ * Finalize Dom0 SCMI specific DT nodes
+ *
+ * if SCMI is enabled for Dom0:
+ * - generate shmem node
+ * - map SCMI shmem MMIO into Dom0
+ */
+static int scmi_dt_finalize(struct domain *d, void *fdt)
+{
+    __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
+    struct scmi_channel *channel;
+    int nodeoffset;
+    __be32 *cells;
+    __be32 val;
+    char buf[64];
+    int res, rc;
+
+    if ( !sci_domain_is_enabled(d) )
+        return 0;
+
+    channel =3D d->arch.sci_data;
+
+    /*
+     * Replace "arm,smc-id" with proper value assigned for Dom0 SCMI chann=
el
+     */
+    nodeoffset =3D fdt_node_offset_by_compatible(fdt, -1, "arm,scmi-smc");
+    if ( nodeoffset < 0 )
+        return -ENODEV;
+
+    cells =3D (__be32 *)&val;
+    dt_set_cell(&cells, 1, channel->func_id);
+    res =3D fdt_setprop_inplace(fdt, nodeoffset, "arm,smc-id", &val, sizeo=
f(val));
+    if ( res )
+        return -EINVAL;
+
+    /*
+     * All SCMI shmem nodes should be removed from Dom0 DT at this point, =
so
+     * the shmem node for Dom0 need to be generated from SCMI channel assi=
gned
+     * to Dom0.
+     * The original SCMI shmem node from platform DT is used by Xen SCMI d=
river
+     * itself as privileged channel (agent_id=3D0) to manage other SCMI
+     * agents (domains).
+     */
+    snprintf(buf, sizeof(buf), "scmi-shmem@%lx", channel->paddr);
+
+    res =3D fdt_begin_node(fdt, buf);
+    if ( res )
+        return res;
+
+    res =3D fdt_property_string(fdt, "compatible", "arm,scmi-shmem");
+    if ( res )
+        return res;
+
+    cells =3D ®[0];
+
+    dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_C=
ELLS,
+                       channel->paddr, SCMI_SHMEM_MAPPED_SIZE);
+
+    res =3D fdt_property(fdt, "reg", reg, sizeof(reg));
+    if ( res )
+        return res;
+
+    res =3D fdt_property_cell(fdt, "phandle", scmi_data.shmem_phandle);
+    if ( res )
+        return res;
+
+    res =3D fdt_end_node(fdt);
+    if ( res )
+        return res;
+
+    /*
+     * Map SCMI shmem into Dom0 here as shmem nodes are excluded from
+     * generic Dom0 DT processing
+     */
+    res =3D iomem_permit_access(d, paddr_to_pfn(channel->paddr),
+                              paddr_to_pfn(channel->paddr +
+                                           SCMI_SHMEM_MAPPED_SIZE - 1));
+    if ( res )
+        return res;
+
+    res =3D map_regions_p2mt(d, gaddr_to_gfn(channel->paddr),
+                           PFN_UP(SCMI_SHMEM_MAPPED_SIZE),
+                           maddr_to_mfn(channel->paddr), p2m_mmio_direct_n=
c);
+    if ( res )
+    {
+        rc =3D iomem_deny_access(d, paddr_to_pfn(channel->paddr),
+                               paddr_to_pfn(channel->paddr +
+                                            SCMI_SHMEM_MAPPED_SIZE - 1));
+        if ( rc )
+            printk(XENLOG_ERR "scmi: Unable to deny iomem access , err =3D=
 %d\n",
+                   rc);
+    }
+
+    return res;
+}
+
+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;
+    int ret;
+
+    channel =3D get_channel_by_id(HYP_CHANNEL);
+    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;
+
+    ret =3D do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0);
+    if ( ret =3D=3D -EOPNOTSUPP )
+        return 0;
+
+    return ret;
+}
+
+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 ( ac_spec->np !=3D scmi_data.dt_dev )
+        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 __init int collect_agents(struct dt_device_node *scmi_node)
+{
+    const struct dt_device_node *chosen_node;
+    const __be32 *prop;
+    uint32_t len, i;
+
+    chosen_node =3D dt_find_node_by_path("/chosen");
+    if ( !chosen_node )
+    {
+        printk(XENLOG_ERR "scmi: chosen node not found\n");
+        return -ENOENT;
+    }
+
+    prop =3D dt_get_property(chosen_node, SCMI_SECONDARY_AGENTS, &len);
+    if ( !prop )
+    {
+        printk(XENLOG_WARNING "scmi: No %s property found\n",
+               SCMI_SECONDARY_AGENTS);
+        return -ENODEV;
+    }
+
+    if ( len % (3 * sizeof(uint32_t)) )
+    {
+        printk(XENLOG_ERR "scmi: Invalid length of %s property: %d\n",
+               SCMI_SECONDARY_AGENTS, len);
+        return -EINVAL;
+    }
+
+    for ( i =3D 0; i < len / (3 * sizeof(uint32_t)); i++ )
+    {
+        uint32_t agent_id =3D be32_to_cpu(*prop++);
+        uint32_t smc_id =3D be32_to_cpu(*prop++);
+        uint32_t shmem_phandle =3D be32_to_cpu(*prop++);
+        struct dt_device_node *node =3D dt_find_node_by_phandle(shmem_phan=
dle);
+        u64 addr, size;
+        int ret;
+
+        if ( !node )
+        {
+            printk(XENLOG_ERR "scmi: Could not find shmem node for agent %=
d\n",
+                   agent_id);
+            return -EINVAL;
+        }
+
+        ret =3D dt_device_get_address(node, 0, &addr, &size);
+        if ( ret )
+        {
+            printk(XENLOG_ERR
+                   "scmi: Could not read shmem address for agent %d: %d",
+                   agent_id, ret);
+            return ret;
+        }
+
+        if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) )
+        {
+            printk(XENLOG_ERR "scmi: shmem memory is not aligned\n");
+            return -EINVAL;
+        }
+
+        ret =3D PTR_RET(smc_create_channel(agent_id, smc_id, addr));
+        if ( ret )
+        {
+            printk(XENLOG_ERR "scmi: Could not create channel for agent %d=
: %d",
+                   agent_id, ret);
+            return ret;
+        }
+
+        printk(XENLOG_DEBUG "scmi: Agent %d SMC %X addr %lx\n", agent_id,
+               smc_id, addr);
+    }
+
+    return 0;
+}
+
+static int scmi_domain_init(struct domain *d,
+                            struct xen_domctl_createdomain *config)
+{
+    struct scmi_channel *channel;
+    int ret;
+
+    if ( !scmi_data.initialized )
+        return 0;
+
+    /*
+     * Special case for Dom0 - the SCMI support is enabled basing on
+     * "dom0_sci_agent_id" Xen command line parameter
+     */
+    if ( is_hardware_domain(d) )
+    {
+        if ( opt_dom0_scmi_agent_id !=3D SCMI_AGENT_ID_INVALID )
+        {
+            config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_S=
MC_MA;
+            config->arch.arm_sci_agent_id =3D opt_dom0_scmi_agent_id;
+        }
+        else
+            config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
+    }
+
+    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 + PAGE_SIZE =
- 1));
+        if ( ret )
+            goto error;
+    }
+
+    d->arch.sci_data =3D channel;
+    d->arch.sci_enabled =3D true;
+
+    return 0;
+
+error:
+    relinquish_scmi_channel(channel);
+    return ret;
+}
+
+int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config)
+{
+    if ( config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE &&
+         config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC=
_MA )
+    {
+        dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n");
+        return -EINVAL;
+    }
+    else if ( config->arch.arm_sci_type =3D=3D
+              XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA &&
+              config->arch.arm_sci_agent_id =3D=3D 0 )
+    {
+        dprintk(XENLOG_INFO,
+                "scmi: A zero ARM SCMI agent_id is not supported\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(HYP_CHANNEL);
+    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 0;
+
+    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 true;
+
+    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;
+    struct arm_smccc_res resp;
+    bool res =3D false;
+
+    if ( !sci_domain_is_enabled(d) )
+        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_1_1_smc(fid,
+                      get_user_reg(regs, 1),
+                      get_user_reg(regs, 2),
+                      get_user_reg(regs, 3),
+                      get_user_reg(regs, 4),
+                      get_user_reg(regs, 5),
+                      get_user_reg(regs, 6),
+                      get_user_reg(regs, 7),
+                      &resp);
+
+    set_user_reg(regs, 0, resp.a0);
+    set_user_reg(regs, 1, resp.a1);
+    set_user_reg(regs, 2, resp.a2);
+    set_user_reg(regs, 3, resp.a3);
+    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,
+    .dom0_dt_finalize =3D scmi_dt_finalize,
+    .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 __init int scmi_probe(struct dt_device_node *scmi_node, const void =
*data)
+{
+    u64 addr, size;
+    int ret, i;
+    struct scmi_channel *channel, *agent_channel;
+    int n_agents;
+    scmi_msg_header_t hdr;
+    struct scmi_msg_base_attributes_p2a rx;
+
+    ASSERT(scmi_node !=3D NULL);
+
+    INIT_LIST_HEAD(&scmi_data.channel_list);
+    spin_lock_init(&scmi_data.channel_list_lock);
+
+    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;
+
+    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;
+    }
+
+    /* save shmem phandle and re-use it fro Dom0 DT shmem node */
+    if ( !dt_property_read_u32(scmi_node, "shmem", &scmi_data.shmem_phandl=
e) )
+    {
+        printk(XENLOG_ERR "scmi: unable to read shmem phandle from DT\n");
+        return -ENOENT;
+    }
+
+    ret =3D scmi_dt_read_hyp_channel_addr(scmi_node, &addr, &size);
+    if ( IS_ERR_VALUE(ret) )
+        return -ENOENT;
+
+    if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) )
+    {
+        printk(XENLOG_ERR "scmi: shmem memory is not aligned\n");
+        return -EINVAL;
+    }
+
+    scmi_data.dt_dev =3D scmi_node;
+
+    channel =3D smc_create_channel(HYP_CHANNEL, scmi_data.func_id, addr);
+    if ( IS_ERR(channel) )
+        goto out;
+
+    ret =3D map_channel_memory(channel);
+    if ( ret )
+        goto out;
+
+    channel->domain_id =3D DOMID_XEN;
+
+    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;
+
+    i =3D 1;
+
+    list_for_each_entry(agent_channel, &scmi_data.channel_list, list)
+    {
+        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 )
+            goto error;
+
+        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), &d=
a_rx,
+                          sizeof(da_rx));
+        if ( agent_channel->domain_id !=3D DOMID_XEN )
+            unmap_channel_memory(agent_channel);
+        if ( ret )
+            goto error;
+
+        printk(XENLOG_DEBUG "id=3D0x%x name=3D%s\n", da_rx.agent_id, da_rx=
.name);
+
+        agent_channel->agent_id =3D da_rx.agent_id;
+
+        if ( i > n_agents )
+            break;
+
+        i++;
+    }
+
+    ret =3D sci_register(&scmi_ops);
+    if ( ret )
+    {
+        printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %d)\=
n",
+               ret);
+        return ret;
+    }
+
+    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 095b1a23e3..30e46de6d7 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
 struct xen_arch_domainconfig {
     /* IN/OUT */
@@ -355,6 +356,8 @@ struct xen_arch_domainconfig {
     uint32_t clock_frequency;
     /* IN */
     uint8_t arm_sci_type;
+    /* IN */
+    uint8_t arm_sci_agent_id;
 };
 #endif /* __XEN__ || __XEN_TOOLS__ */
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Mon May 19 15:51:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:51:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989966.1373973 (Exim 4.92)
	(envelope-from )
	id 1uH2li-0006VM-61; Mon, 19 May 2025 15:51:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989966.1373973; Mon, 19 May 2025 15: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 1uH2lh-0006TK-Vf; Mon, 19 May 2025 15:51:09 +0000
Received: by outflank-mailman (input) for mailman id 989966;
 Mon, 19 May 2025 15:51:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2lg-00055d-Iw
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:51:08 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on20612.outbound.protection.outlook.com
 [2a01:111:f403:260c::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1385b636-34c9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 17:51:07 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB9023.eurprd03.prod.outlook.com (2603:10a6:20b:5b7::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.29; Mon, 19 May
 2025 15:50:59 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8722.031; Mon, 19 May 2025
 15:50: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" 
X-Inumbo-ID: 1385b636-34c9-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=StCd4X8kFsxYQtaujbffGTSrnSTEnadfSHwI4OmQ7ww6FxCGDZTHkMdLmB8K5eypiTUcjJ9qniD3c0TE2Qtt9abdIX/DcGBKqEmVlQ/H02E9KO+veZofJ5bZE241fDDbf+Xhb3Pct7yG+zIFMVjudFtgdBU4Nwrzxle+OyOTde7Gq1YWs6nhdT2d7/thA6YW6LYJ/wKROBPZRRVJwzrZBkcqAqE/dWh/Qmpx3TAuHM3Pqflh7i3mMrQpqd6vK80SYduKu6H4edhUTwFuzVPD3JkW9/TdMIpS8y0IFbe35QwnxRjJCCRgCV4pqnFZ8zRj/g11vpE0kOQaymmmq8uRKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fiZyyBp5vPFXU/i3NtVXScDoBYnysWozlVWCFXbrvnU=;
 b=jvUvPb78x1PItVx+bvFurzUIwZVo3XEo4IBObdpx6cO/8QjvjCbMERmozz4/HwXOAiqlWdcuSTU6Q240XRywnAfBFSiJU9L7+BE5IpwNHGVyXuYsClSJfJ3VA7xfv5icdH2Qt84E8mqz85i0AXfO/KhilgWJiQN1sNmSJel1NzTPKcPyDWgmcYeEAE0o+mwiYhV1RIJ8fRFhjKl1lPRZMBkC4j2+tJan6xfRePtD6wsBi7SNmywztgHyS0rHY2XW/q72EJiGsGHOaRC+hbjNZI/hU+ZYBIq/b67CEK5c7wbUi7QIEwccG0U14zz3Tih7ES+eOK36XWY+aZc/XOTwkg==
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=fiZyyBp5vPFXU/i3NtVXScDoBYnysWozlVWCFXbrvnU=;
 b=axrUxhiRF3zrqy+P2YNW8D8J7duPfECqhjQD5uYhtjFy8wlQAfq8AsjTxEHdYTGcgnSnpHOs4CrGg4eR4oILxtLFg+MZNvAw7IhXidoaswMCHKZjYy0EFDotL7YwxSqohuBNzHtqSOWX33KiSgN1dIA9W9PVhdH1UYLjWhpFysdGCgmaLRNwMUsuhdDvWOGNUcZQ45e5JM5P0bXPOZ21bvnk+o9klvUfTAJstTM2ISWC2GymcIqGrIS31PBsvXRT1stlrZju0EqZTyRG7OE/WmSm1pykXSFCI+GtqIEdNRmDyYdgi/f3Chy19stE5XrpsE+JJneTmPiz4v60lPSoYg==
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: [RFC PATCH v4 7/8] docs: arm: add SCI SCMI SMC multi-agent driver
 docs
Thread-Topic: [RFC PATCH v4 7/8] docs: arm: add SCI SCMI SMC multi-agent
 driver docs
Thread-Index: AQHbyNXP28/MAaIPLEugDxuikDXW5w==
Date: Mon, 19 May 2025 15:50:57 +0000
Message-ID:
 <6778db411b06a1f30d3983d94f3f23fc579b8382.1747669845.git.oleksii_moisieiev@epam.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB9023:EE_
x-ms-office365-filtering-correlation-id: c3e4958e-2404-4873-2ad9-08dd96ecf2f7
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018|13003099007;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?yowmkBXagC67KWTAHUfQduceAFzhvkfvgEkzuxd52zQe3LEib/txx9CMq5?=
 =?iso-8859-1?Q?heggBHKKI91ADDvwbeHuzvQgnX/ms6QUNQcXAi3XSKTYsWdjN86r1FoH00?=
 =?iso-8859-1?Q?j7R1Vnp1rbaOV41JiatcLc4YTLXG9297GzB2H7Y8HsjGiJS6h46ehoxY4L?=
 =?iso-8859-1?Q?ilBld8h5KW8EX9KRuEqhUhSNJZu2TXW4jtlwRhg0tfINP1w8t9qS2bPfN0?=
 =?iso-8859-1?Q?W6T1qr7rIdikY2JG1EilwjEUKtLs6z7hO5IMAl3Mn9lNpAw1kTBp1TVIlK?=
 =?iso-8859-1?Q?PMKet5ltAbDXyJqBTa0eJEZ5T+SIaEaJWWOXtQG1/lAAh/dMttkS4+fBJ2?=
 =?iso-8859-1?Q?dK983PacyKXFVtI8zcQaWlNG3QGWfVRrbkq62DIAOVfOzJ0UrZGHYESKyO?=
 =?iso-8859-1?Q?o898+e2tzbqZetdhs9F8XIq4KRPb3E8Elw2UjgUlp0e+OoINXi+cSW7aBY?=
 =?iso-8859-1?Q?9QBuXVJaxCj4+d2UlhHYk7NojSr6wxGzLXjGSrC7C9cGwRkp2MIGQ8bbM1?=
 =?iso-8859-1?Q?v2Y1nX7+OwTqeqIxudp9Eynh95EJ79SGF/T+bxztK5JKYMlKduLqY5PHUx?=
 =?iso-8859-1?Q?2+N0PUYPka93arQdu2ZcBD6dmboflIWlJETKa3wCdNeNCZ+x0wBZtvNqxG?=
 =?iso-8859-1?Q?D87xQtWEWgXGsDPaX2jG6FJ9HRcBmt/RyctlsbKkaxWOrlAQrnAO1eqBHO?=
 =?iso-8859-1?Q?LIfV3lksMgOHnK9MW/poipRYfuUN8XqGzmYMQGWPPRrUUY9eS4dURJ4eDQ?=
 =?iso-8859-1?Q?mYNohjTB4xk3NkK6QPvRwfmTpWIkgj5nrCDxux0JzpVcSxZYPBw+bEixAO?=
 =?iso-8859-1?Q?HTy8dA24WuPpxwLRXR/7FIdZ8Xpc40kerdIHH/7ZARPPknkag8edvpqeIl?=
 =?iso-8859-1?Q?FqBa4fU1JOCVvR8s4jdI67a0OPMmXNmTlZKwje/DLXQj7O3FNQVHLtlY19?=
 =?iso-8859-1?Q?Cx+DU0iY1FFNLva9U9z4P6apE9RJrxGnAZMPmp3LCskT0v7sbTFa/sAyoF?=
 =?iso-8859-1?Q?K5xKJhqutH4qc902QBeoIw/Qc+PjMfW2xHsDzJXP9+LADrJVhgAV3eX+uR?=
 =?iso-8859-1?Q?Pjvp3Xik5lFJMfaACgwQ6pAQFJ6t7Wj+hDIK9M/X3ggkFUGgGtRUo21CVM?=
 =?iso-8859-1?Q?hrcJEiJM852ujqGRVaE1mCfcG2vFYs5hN2FZkg0QHKDllOqyYc0vEl87MT?=
 =?iso-8859-1?Q?hyxekiBwBurCUMGYC+ymLCTy5YUZm+01fjZyNOITjxZ4x/roCIqTGgCnJG?=
 =?iso-8859-1?Q?xO73l11HltCOaI5ni3PAvCDONhlJXqLi76UCFlunIoB7tGJ5aa+cIbbPf5?=
 =?iso-8859-1?Q?1MaTeRVelTeTRV/7/TzN5mx/JJAtL1IDSYl0TnWdu9GOQ+Nu6EekVtOaTn?=
 =?iso-8859-1?Q?mrJIxkNbxDCGV4SY7agpRZiSFUfh0q59NNhlwxi4Vt5m9OwsrLcLT2T4mU?=
 =?iso-8859-1?Q?1nTgR5lCI9xjjLPo3S89sEBQSuAd3KC7wi4xDAgQEj2HXoEsagGHzM80cx?=
 =?iso-8859-1?Q?4=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018)(13003099007);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?UvP9iTv7vK8tZ6wl8fMtxVUOzrDm9lRuprtENu4msawNAO8VqhifFRsdH7?=
 =?iso-8859-1?Q?HXconBvLEPvbs0cKPxfHQIdDePljuIP//2VYpcMaovlXNBKAIxnvWfGrRy?=
 =?iso-8859-1?Q?/vBv8BO42wvoJVso86gPFFFbEMbKTv1r8oZLTounabAnYKe8zzC98MAM5k?=
 =?iso-8859-1?Q?XpEeCz9XqsQwvU++mT06G5aQ/527Zwz29XaVbu/xJgUV08hrvnMEPc8Jot?=
 =?iso-8859-1?Q?sL/14+c7WbZINCd29W5dLLC9vF2oIjY1++fY/QB9gLDVe0ZM9jIBGUXgRa?=
 =?iso-8859-1?Q?C94lZUBZbYF7kWa0nk8EOjWgiS+8g4c8lInaYNnFFi7gIicnfKViLT0iPG?=
 =?iso-8859-1?Q?BI0qPVg+fy63so52MmxF/o1ggfkYY3DQj4v9dE3Hm0675N86gI1Wmu0Cen?=
 =?iso-8859-1?Q?CNMChrJqASi43b7lbqo6hlS16TDGB+Gj90BxRlG3rjcksmthjyUdAwap5L?=
 =?iso-8859-1?Q?Te30raPpuP6i44zTlBZ7Ri3QzSqOu2Friq8kuN9UkmwKRXBkbYxZP+7NOd?=
 =?iso-8859-1?Q?i137+Bv/fu42LO2EmXQClwQksZNLmTozpETnjFsyWbSz/K4nA6Pn0U2rYA?=
 =?iso-8859-1?Q?faCXKZLz4orp+DEahAP+vVuNx1Ag0h/V9SCWv4wDggGNg0Wk1WmUm4wt+d?=
 =?iso-8859-1?Q?t3q0RXbp39Gd/TCipTptpi/LuDknn05I4CFJHcvFlcY1h1kH0LQRYyxTwd?=
 =?iso-8859-1?Q?FzXgxYnlM3PpCN2+VhYoWdk7hahkZFMoKsrwjX+1OyCC5+rvlJHmAO4bb0?=
 =?iso-8859-1?Q?jBJBlGWLBhnFxgEX9i71kaos68ONI3Agwk0tcJzNYdz+zxfs2/OlJ+Fim+?=
 =?iso-8859-1?Q?V3deAtCI0jaLHUXiBMEssPmqflvRIgC73yM3CT23RiFz1yNkAPHs8UriPL?=
 =?iso-8859-1?Q?mUBYRyewKvhUtIkyPN/5apgRArfLmzx/VuDiuFT1JfiZ3mOsk9nvs0cv+F?=
 =?iso-8859-1?Q?4bW1RM0GuS9AZE1ImPxZywSWdrJS5L5U279l4ylqrfmEeh3MBkVN1pdMtX?=
 =?iso-8859-1?Q?vLEUdEGKYZV9ESlV8Ptj9oeUPVUrM24Nue0sWutnBWC/lf2tqFEL6jwU0J?=
 =?iso-8859-1?Q?IUagWFRsIyMsrg6auFsG2HjWszMUtH9iV19gqiws9Q0c5/w+8GBX+LfPZp?=
 =?iso-8859-1?Q?Zw/6siRlD0hlN8bLWaA02JnaI8Nj9Ag0bVkIyCzmom9H0qe7aPcR9LVBKX?=
 =?iso-8859-1?Q?tfKWfRHoXxZsOSK8CxgtbvHAiL5SbseSA87W3qn0/ywxOWGKy4JpSazbHc?=
 =?iso-8859-1?Q?vlT+CBgy/ZZgH8JijEEMI1hnU5uwoHapFKBFbh714oDU5Usm+81AxHSem3?=
 =?iso-8859-1?Q?1j5D49wPZuoNv6n0zooowHesK6+v1cb3zYg1127Fv/BXIXAR3Y0IubgG1n?=
 =?iso-8859-1?Q?CGcOaa+jigCofky7naeDYw2MCHKBPIUtMC4P77+81upoVG8n9zioay6Vfm?=
 =?iso-8859-1?Q?OktcYmNKMN90neqzgy9/JJvapk4TrQskOE201VfQHBTVYlwXyXTyeSx56Q?=
 =?iso-8859-1?Q?ktcH36SgB1WxMSkCgkOqWZSpGoKeNRbkhUWN7YdFD7Zqzrm7O6YLWc+it8?=
 =?iso-8859-1?Q?41fNA1P0tjMetkwjFMFacUtboCAnrcIWZmpwQ7JQzXQIBvpq2jNaunGqD7?=
 =?iso-8859-1?Q?ee3JFLpGJmSxKQWuyu2mTBmQsfyFZlP280QF/dVIiu07/936yD8D5DHA?=
 =?iso-8859-1?Q?=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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c3e4958e-2404-4873-2ad9-08dd96ecf2f7
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 15:50:57.9840
 (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: pKRg4yWK8CR6vkhNzANJvjOsloh9hdyiX/MotpzML1fjiGG+2LLTyLEWRs3ABglBkzd1SeI4AW3BNXI+EVW+Y3xaWWXqHODz5d6sgfDypvw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9023

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 
---



 .../arm/firmware/arm-scmi.rst                 | 267 +++++++++++++++++-
 1 file changed, 266 insertions(+), 1 deletion(-)

diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervi=
sor-guide/arm/firmware/arm-scmi.rst
index bf6a458a6a..27739015d5 100644
--- a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst
+++ b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst
@@ -31,7 +31,10 @@ domain serving as Driver domain).
=20
 The below sections describe SCMI support options available for Xen.
=20
-[1] `Arm SCMI `_
+| [1] `Arm SCMI `=
_
+| [2] `System Control and Management Interface (SCMI) bindings `_
+| [3] `Generic Domain Access Controllers bindings `_
+
=20
 Simple SCMI over SMC/HVC calls forwarding driver (EL3)
 ------------------------------------------------------
@@ -175,3 +178,265 @@ enabling SCMI with "arm_sci" xl.cfg option.
     ->        xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>;
     ->        xen,force-assign-without-iommu;
       };
+
+SCMI SMC/HVC multi-agent driver (EL3)
+-------------------------------------
+
+The SCMI SMC/HVC multi-agent driver enables support for ARM EL3 Trusted Fi=
rmware-A (TF-A) which
+provides SCMI interface with multi-agnet support, as shown below.
+
+::
+
+      +-----------------------------------------+
+      |                                         |
+      | EL3 TF-A SCMI                           |
+      +-------+--+-------+--+-------+--+-------++
+      |shmem0 |  |shmem1 |  |shmem2 |  |shmemX |
+      +-----+-+  +---+---+  +--+----+  +---+---+
+    smc-id0 |        |         |           |
+    agent0  |        |         |           |
+      +-----v--------+---------+-----------+----+
+      |              |         |           |    |
+      |              |         |           |    |
+      +--------------+---------+-----------+----+
+             smc-id1 |  smc-id2|    smc-idX|
+             agent1  |  agent2 |    agentX |
+                     |         |           |
+                +----v---+  +--v-----+  +--v-----+
+                |        |  |        |  |        |
+                | Dom0   |  | Dom1   |  | DomX   |
+                |        |  |        |  |        |
+                |        |  |        |  |        |
+                +--------+  +--------+  +--------+
+
+The EL3 SCMI multi-agent firmware expected to provide SCMI SMC/HVC shared-=
memory transport
+for every Agent in the system. The SCMI Agent transport channel defined by=
 pair:
+
+- smc-id: SMC/HVC function id used for Doorbell
+- shmem: shared memory for messages transfer, **Xen page aligned** with ma=
pping``p2m_mmio_direct_nc``.
+
+The following SCMI Agents 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 expected to implement following Base protocol messages:
+
+- BASE_DISCOVER_AGENT
+- 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
+^^^^^^^^^
+
+To build with the SCMI SMC/HVC multi-agent driver support, enable Kconfig =
option:
+
+::
+
+    CONFIG_SCMI_SMC_MA
+
+
+Driver functionality
+^^^^^^^^^^^^^^^^^^^^
+
+The SCI SCMI SMC multi-agent driver implements following functionality:
+
+- The driver is initialized based on the Host DT SCMI node (only one SCMI =
interface is supported)
+  which describes Xen management agent SCMI interface.
+
+.. code::
+
+    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>; <--- Xen manegement agent smc-=
id
+            \#address-cells =3D < 1>;
+            \#size-cells =3D < 0>;
+            \#access-controller - cells =3D < 1>;
+            shmem =3D <&scmi_shm_0>; <--- Xen manegement agent shmem
+
+            protocol@X{
+            };
+        };
+    };
+
+- The driver obtains Xen specific SCMI Agent's configuration from the Host=
 DT, probes Agents and
+  builds SCMI Agents list. The Agents configuration is taken from "xen,scm=
i-secondary-agents"
+  property where first item is SCMI "agent_id", second - "arm,smc-id", and
+  third - "arm,scmi-shmem" phandle for this "agent_id":
+
+.. code::
+
+    chosen {
+      xen,scmi-secondary-agents =3D <
+                    1 0x82000003 &scmi_shm_1
+                    2 0x82000004 &scmi_shm_2
+                    3 0x82000005 &scmi_shm_3
+                    4 0x82000006 &scmi_shm_4>;
+    }
+
+    /{
+            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_shm_4: sram@47ff4000 {
+                    compatible =3D "arm,scmi-shmem";
+                    reg =3D <0x0 0x47ff4000 0x0 0x1000>;
+            };
+    }
+
+
+.. 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/HVC
+  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/HVC 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
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The **"dom0_scmi_agent_id=3D"** Xen command line is used to=
 enable SCMI functionality for
+Dom0. if not provided SCMI will be disabled for Dom0 and all SCMI nodes re=
moved from Dom0 DT.
+
+The driver updates Dom0 DT SCMI node "arm,smc-id" property with value and =
fixes up "shmem" property
+according to the assigned for Dom0 SCMI "agent_id".
+
+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>;
+                    shmem =3D <&scmi_shm_0>;
+                    ...
+                }
+        }
+    }
+
+**Device specific access control**
+
+The XEN SCMI SMC/HVC multi-agent driver performs "access-controller" provi=
der 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::
+
+    &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::
+
+      scmi_shm_0: sram@22001000 {
+            compatible =3D "arm,scmi-shmem";
+            reg =3D <0x00 0x22001000 0x00 0x1000>;
+    ->        xen,reg =3D <0x0 0x47ff0000 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:
+
+.. code::
+
+		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.34.1


From xen-devel-bounces@lists.xenproject.org Mon May 19 15:51:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 15:51:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.989967.1373988 (Exim 4.92)
	(envelope-from )
	id 1uH2lj-0006tb-LV; Mon, 19 May 2025 15:51:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 989967.1373988; Mon, 19 May 2025 15:51: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 1uH2lj-0006sj-D4; Mon, 19 May 2025 15:51:11 +0000
Received: by outflank-mailman (input) for mailman id 989967;
 Mon, 19 May 2025 15:51:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH2lh-00055d-Ey
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 15:51:09 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20625.outbound.protection.outlook.com
 [2a01:111:f403:260e::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 13f9ea66-34c9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 17:51:07 +0200 (CEST)
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21)
 by AS8PR03MB9023.eurprd03.prod.outlook.com (2603:10a6:20b:5b7::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.29; Mon, 19 May
 2025 15:50:59 +0000
Received: from PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com
 ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.8722.031; Mon, 19 May 2025
 15: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" 
X-Inumbo-ID: 13f9ea66-34c9-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=B+qpqXHemeHdhUk5bNtkj670k9kwlq9bz8R4ud466fq8HEfo37GRF5c1LdaI9ehawN5vW3bHzWxEwA+WfNU8jhrsm1njo9bG8RKJMT112lWfbNWon9lNnWG06DTsOITCgc7GgdmlonHkX4jCTJFjI0RMIdaw0uQyD+NDeaqN0B6j5k7ZkLA2SvejwnCIJdD6j26AgwqswnYZm2l4ozxLSIJBoXayjdLtqgsJFQSMAPqlmITz9EZ8clPAN8yfuQm3842724XwYz/iGtE+4UGojNDv7uK9D8tlG/RkD9EFgP8i4rIDAjfW6yOCTiX38JtEZy3f8L3OStHAecwuOLglxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Jx3fLHSwk7VgFQnLSwZrpE1wKHHCAxXq7JgHsDxezbE=;
 b=v146IgmU/T1k7BOfqGeff1jZjNgNN0jyr//gG6kV+BK7A7k7iAtwSFO0uRzK9dn2Wp2rXzMUhxBy6BVAYAoeXZKpb5zXk90VXdWNwy9mGpyye3vmLUytEA6sK6bTakMR9IU0Os4nLaFWQ5fPPUQ8kYpqvMb3I9S6ddDo/HsAYZ9Vnmv82hM+vW7GueflZF/U8EeL3Et86pKGfAAxm9go0pmWhJzdIM1va5RytixRwkUZmTc6RG11cohAsAJM1/PXcpG/B6bhpunoYRZCwaPM3ebB+IHRdZkOO+BqB0YriO6wZ3UmG8NKwBIWMbwtSUVHC7GlIiNSD6Lwv9GKqmk6Ng==
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=Jx3fLHSwk7VgFQnLSwZrpE1wKHHCAxXq7JgHsDxezbE=;
 b=si3nX9+xO3BMFrsTFWYVQKGV2jtEn4JzH347aVU45h/dnG3LKk/Qy3n4pSDffYOs+dszNa0nQlGD2zY7x8OobL/c9ZWnBiVDTqtdVizsqGVkyVGJUsair+chl702sRGxCMNa5042NZIu21U1xEo15lUeDk/+P0oNh5N88mQdZHYeiRFLw7tcU0bQSHGt6/7CESiuEWHUSuWo+GjQQyP6y1EfhEBAR8PEKHlEmWTMBXlDSvIMaohppSd8LkXIu5ywNI6P1/p4cNUPHGxuYwaqvpDPqV1eZgHb0Vd/wMONZo5uDTmRLgJLvFC+rOwS+fZGWbuRIiHgERXp2//wbpinhw==
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: [RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node for
 Xen agent
Thread-Topic: [RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node
 for Xen agent
Thread-Index: AQHbyNXQTZOEYVEinUiuxBk1KdhKoA==
Date: Mon, 19 May 2025 15:50:58 +0000
Message-ID:
 <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AS8PR03MB9023:EE_
x-ms-office365-filtering-correlation-id: 14106a3a-8921-49fa-a2b8-08dd96ecf319
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700018|3613699012;
x-microsoft-antispam-message-info:
 =?utf-8?B?bEk4UW45bThteXBjdFBtNStUL1pLb1NKTjBRcGg3U1Y5b1h2RDRKYzVwcVZx?=
 =?utf-8?B?dEZNK2xsMjU3M2U4enRyZDlMcjc1VUlqMkxJTDRNcnRQTC80S2d5a0lrTE5y?=
 =?utf-8?B?dkdtOFJIbGhZY0NBMTN5ZkpaYkRsc3hQdHNKaEd3OE1wcFBkQWFCTEtKZDBX?=
 =?utf-8?B?dkgvaVdsM0xQdUVTMEFHSmtuSUxjRDk4S3A4UHBqUFhabmlQN1AwTFZoN0gw?=
 =?utf-8?B?NGR1UC9oVEVlZ3pibHoxRFFZeWV4VUpOQWV3M1YzbGlDSmZsVXkraTNvcUpk?=
 =?utf-8?B?TkZGZ3dBQnFuTzB0TVhESnkzQzc2ZjdKUEdvOXA5MEx0OW91S3diMzVBOFFt?=
 =?utf-8?B?U0NIOHZaWE1FR2RGL3N1eWVqa2VlY25IK0tidnRSUzJEM3I3dGIvKy9HM2U0?=
 =?utf-8?B?ck9yT1Rxa3h2cE40V3REbjRDcVVKWm13NHBvRnhGcGhwTGE5UVJpM2toL3Uw?=
 =?utf-8?B?QVM2bWFmdkRWMHRDRnRNVC8vVUFiUml6SmpSbjF6blM2MldRUUZQOU8zTlBM?=
 =?utf-8?B?eWRXZFlQc3R2UXk3V3kxV0xJUnE3Q2MydWxVU0F4Qks0a1pwTjhQdGt4RURk?=
 =?utf-8?B?UkU4clVrZlVHVkkwaGxlVzJWT0JQMm1oalJlbnkrQ1RrUVM0OWF5V0tVSXRm?=
 =?utf-8?B?bkR3eitHdXJIR21ya2xMSmw5LzVUUWh5L1hMaTlXNDlxQkRVVXdLa01CZ1lk?=
 =?utf-8?B?QS9HdWk4UW5odno0NHRzZzBCQmtIZ3BaNDQ2WGNYTWpLV05zK3Y3UTNmTEp3?=
 =?utf-8?B?YlM2UnVnQkNlRU9JanJzZmNPODh6SWU3RFo3VTdHRk1MQjNuL2trMmlGaTNm?=
 =?utf-8?B?RnlJREE3ck5MWHNiTGgyQjFpVHh0K0FWMTlZL2t0Rjc4UkJ1YTVIMnAxVUJV?=
 =?utf-8?B?NmtTa1VRb25qbjA2NFFSUkJBM1ZiZWdhM1pQRmZjT0dGL0lzN1ZqenJvSGZI?=
 =?utf-8?B?aXIxQWtscWgwMXozSkdGUnZDcnVVRmhRWnBMNTJsWWhMQnpYMHpxa2pjQkxE?=
 =?utf-8?B?amdkYWNvdm5VQ0d3OXFUWHhGMzBEK1dXRUhFaUJsZE5RcDNrS2NoOUluVmJx?=
 =?utf-8?B?dnVXdXdwNFEzYmdFbkQ0K2hmWjhPdVJ0am96dHNDejhSVjljSERiWTlabEo1?=
 =?utf-8?B?aysvVUZwU3ZpVTBiWGlLbzVobVRpVmNuYkM1M0Y4UnhGZGJGVzNBVXFrWnBU?=
 =?utf-8?B?TmdxZGFCai9aWnFUOEp2OUI4RXZLL0N6eUZJTHJvRS95aEsva2IvV21TTGhY?=
 =?utf-8?B?RFBEUUlvbXlFSENkaUliOUxYS1hMcjA3NE5KYVZCVmpMcHliZTJBemdnbmhh?=
 =?utf-8?B?WTVDVHE1cytlcjVPc3ZyclNiWmdaekpjUHFHcHJZckx6MVlkcXJsZ2xWYllN?=
 =?utf-8?B?UmZuelZ6WTRqcWJkN2JtVGVVRzh0NjA1bnNHSE9kMlBjR1dDUVBYT3V3QzZZ?=
 =?utf-8?B?T0VJS3c1aEFEaks2M0JBTWZHMDY5R0tNZkFhL1NOK2RGUDd1Mm1aMytRT2Jn?=
 =?utf-8?B?U1BaUFg4emlFeEpGM0dBbWZpTDRJSCt6emtMbFM2NVpNV0t6bTl5UURyV1Zk?=
 =?utf-8?B?ci9lMlNOcWNra3pRUXR5M1FGWTRFTTMzREZ4YWthUW1KQkRpVVljU3RXZG40?=
 =?utf-8?B?b0R3ZzRpTXl0dmVrVzVycHliUTdyTEhGK05nZWMwM2hEMlJRZUVzZjZsMzNi?=
 =?utf-8?B?a1FBWi9kQVpFdi9xSlZEYm1XcFFpMkV0TDY3UERyRVpEQ0xkNDFFdE5jY2Qy?=
 =?utf-8?B?NGlNUi9FMWJmbjljUjcxUHpDeVdLSG5HRStrckdxQnkxMkRTdXA1ektxQ1Y4?=
 =?utf-8?B?VDE1QUpjWHQvOHhQTW9IVitVdGk1Z0xzNkFpNXpKWEJ3NGNzNFgyZmp5amt2?=
 =?utf-8?B?MFN5QTBTbTA3RmErWU94TmxnZmlMdHR4N3pRWEJGNGt0bVVYNSt4NmVnV1Ex?=
 =?utf-8?B?TXB3aGM4NnlIZjhzV1M0VEpNOEZQZEl2QmNURUxKNjBvbWZCbTc4Vks1bHQv?=
 =?utf-8?B?dTIzdFNzZ21vdkR4K2FCbDJIMjJib3I0ZS8wVDlWYmw2dkhNSWsyMFVjc3pL?=
 =?utf-8?Q?zecq1z?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7416014)(38070700018)(3613699012);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Qk1yRnl0U2xNRjdDMjFoVzJCdXZDaDl5WHk2U2hhZUJoQmhSbDI1c3hSeFdX?=
 =?utf-8?B?aGttT2JWYWh0eWtPVTl5bnk3ZzhhODN1SHNVVFp3UGJKayt5UTBMaGZGRWMw?=
 =?utf-8?B?S1pvOFUwL0Vnb3ZWc2MrdnFIM0ZJKzd0ZTk4QzNPeXhtRkExVk8yS0tQamhL?=
 =?utf-8?B?MGVxQ2FGeFRrSXByQSttc05uRzhObFB3MEtnQkF5TTYzQzRmSklLWTRrUyt2?=
 =?utf-8?B?U05nNk0zVi93SHZBaE9NdkIwSkoxQnVDZFFwWXcveFM2UmVtbDEwSFRmaHZa?=
 =?utf-8?B?VUlINFgwc3VBb2FUOHYwMFhSQzNILzFGSENSdDlPd216ZzdHQi93TVNobS94?=
 =?utf-8?B?QklPUHBWV3VnVmZCR2V3aGFKcys1SHZIT3N4eitTdCsvVzNReWFVbnBJdmJw?=
 =?utf-8?B?clNIc1YzT0tsODNSd0FESEJaUzl1b2U5S3JPR1dkVHJmSGVpc0RYM05qcnJD?=
 =?utf-8?B?WVFaa08wcjlla2hzdlFydDNpWCtISnRjMXR1RmlNRy92a2JITzFFaUdUejJO?=
 =?utf-8?B?YW9aTzE1ckJhN0NBRHpNNTY5T0ltUkEzSXBCa25SRkZXc2VxbXBXS1E1aWhs?=
 =?utf-8?B?K0NPbFpXRUxWbXVrUFhEWHVtQWNvanY5YVE2b1NOSVcrcmNlQmFYRG1UdzFR?=
 =?utf-8?B?RXNYY2h2cG5wd2NLZWQxSFlVRVorTHNYMEhaTVNhY3JxZExGL1J0Ui95T0V6?=
 =?utf-8?B?T0dMc3Z0NDZJRzdySXc5MHU2NDdSN2hWMUFUZGh5eEEyaVp6UUxNVXlrVjg0?=
 =?utf-8?B?Z2pxcnJZWWEwL1k0Wm1MOTFKeFRKMk84QjBvMHI5WXpLSGoxM1VXdWsxR0hw?=
 =?utf-8?B?Z2VlRnhmMmJwWjZaRTBleG16b0VQdTNiaWw5OFBpc2hGWXZJQVZ4UjV5elpx?=
 =?utf-8?B?bXBYUTRTZUk2a3FaWmZ1S0lVTDZwdHNMZmpUb0M4dytFL3JQeXBtRThmYm0r?=
 =?utf-8?B?aXRMY2xaNXNwYlpWUjNKUWdJM1l4L2ZEYUFYcWFQbG85cXgyRmJPWERPdUFP?=
 =?utf-8?B?bHRVUThGaG9oaGlkWjZyYW41RThwUjlMY2M5Z2kxTVgvbmVPeHRiYlVIV21w?=
 =?utf-8?B?czZFeFpQZlBlcU5ZbEJPWmllaGcvUnRHMWdUalJzZ1JkZHBnQm1vb3BiTDBx?=
 =?utf-8?B?Q296bDYvN0RoVkRkak9ncG9jL3ozZm9KcDF4dnphb0Ftb0pQbjZaL2ljaE5z?=
 =?utf-8?B?OHpxUFhJcWIxd3lzejltVXZIMVl3VXJIWSs2bDN6bytZT1FtWWMvcXFBa0JB?=
 =?utf-8?B?ak0wVEEvZGJxaUU1cEtpV2tVWC9SNnorR09iTHZyRHZiemlWTFRmNFBEYmlJ?=
 =?utf-8?B?SzBaQVpnSGVHSm1NVTZvankzQ2hQdU9wT01FV3FadHlVbUhZTWw0UUZKZUJQ?=
 =?utf-8?B?QVNBYmZVaXZnNXJ0RXlLN01uMXZxeGZQVENLSXV5YUU2TFZaYnBPUkpHY1Vl?=
 =?utf-8?B?TkhUTVFYNmZWcjdLbS9kUFh5RkdDWWVoaEYzVmpQTkZ4Y3QwR0ttNVY5UE00?=
 =?utf-8?B?YWZvVzh0VkZzZTA3UllxZmxQRTRIZFc0bXg0RFAvZlZlYlkwekNWYmV6L3A5?=
 =?utf-8?B?UzlFNUhWdDB1M3dIOGF6M1U0em05dEFSSmRaanJLSlpMSmJtd1dBbUlkVHRo?=
 =?utf-8?B?MnlKNXlVaUxKM1c4dmVRbTQweTJPVDIwNG93SVFvSnE1dXBXNTFJNnFXRFdq?=
 =?utf-8?B?dzkxQU1WMFF5VzNYeWtXYlVsZng5K0tab290YnhrOHd3KytWOWYyMGJQRUxF?=
 =?utf-8?B?RkV3Mm5oQnNJaVpjUUp0QlY5cHVBSHpuMW1NNVJEOEZQalp5akJNK3N5Rnpr?=
 =?utf-8?B?dHdsYUxiUjdhVTBTdE50OFlVT2ZCcTFGZ1FKVFR2WExPMHhCYkxNY0ZJUGVZ?=
 =?utf-8?B?NGoydFFITTlXVlk5c2ZVTzNIb05wODZndFg4Slk3bFFVelhHLzVTU0dJc2Jh?=
 =?utf-8?B?bU1zOXZQVzlBVUdKV3FHN0xUYVdCdW1iaTZHZkhCVGVHVmlBZGJZRVE3Vkxi?=
 =?utf-8?B?SmFMcFdQbTdWbnRkUy84OGJsdWpDOTBvN0RmMkRXN3JBa1VQelFzbnRwNG11?=
 =?utf-8?B?VWxoT1BENFdLM3BpOTMrbk4rT1FrMk9OSy85MjNIanRJVXU0SFVFUG9PN3kw?=
 =?utf-8?B?dk1KU2VES0NoYzM3ZllyK0JmempaYVNWTzVaMEVWWlp5ZE52QWYreHRZbVRi?=
 =?utf-8?B?ZGc9PQ==?=
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: PAVPR03MB8946.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 14106a3a-8921-49fa-a2b8-08dd96ecf319
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2025 15:50:58.4182
 (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: +USJlQBwp9TbfU5wIY/0M+9IagxRXCfnmYfStOR/FAXZvwd4EGgd140ZuYoq7E2eTEhWuoFvq+yYevUQ7aDNcmWuzf7SdyF/PLZLlHjXYJY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9023

RnJvbTogR3J5Z29yaWkgU3RyYXNoa28gPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KDQpQ
cm9wb3NhbCBkZXNjcmlwdGlvbiB0byBhZGQgc2VwYXJhdGUgU0NNSSBEVCBub2RlIGZvciBYZW4g
bWFuYWdlbWVudCBhZ2VudA0KdW5kZXIgImNob3NlbiIgb3IgeGVuLWNvbmZpZyBub2RlLCBsaWtl
IEh5cGVybGF1bmNoICJ4ZW4sY29uZmlnIi4NCg0KVGhpcyBwcm9wb3NhbCBpbnRyb2R1Y2VzIGEg
bmV3IGFwcHJvYWNoIHRvIHRoZSBYZW4gbXVsdGktZG9tYWluDQpjb25maWd1cmF0aW9uLCB3aGVy
ZSBhbGwgWGVuLXNwZWNpZmljIGNvbmZpZ3VyYXRpb24gaGFzIGJlZW4gbW92ZWQNCnVuZGVyIHRo
ZSAiL2Nob3NlbiIgbm9kZS4gVGhpcyByZXF1aXJlcyBsZXNzIERvbTAgZGV2aWNlIHRyZWUNCm1h
bmlwdWxhdGlvbiBhbmQgaXNvbGF0ZXMgWGVuIGNvbmZpZ3VyYXRpb24gZnJvbSBkb21haW4gY29u
ZmlndXJhdGlvbi4NCg0KVGhpcyBhcHByb2FjaCBwcm92aWRlcyB0aGUgZm9sbG93aW5nIGRldmlj
ZSB0cmVlIChEVCkgcGFyYW1ldGVyczoNCg0KLSAieGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyI6
IEEgWGVuLXNwZWNpZmljIHBhcmFtZXRlciB1bmRlciB0aGUNCiIvY2hvc2VuIiBub2RlLCB3aGlj
aCBkZXNjcmliZXMgdGhlIFNDTUkgYWdlbnQgY29uZmlndXJhdGlvbiBmb3INCnRoZSBkb21haW5z
Lg0KLSB0aGUgU0NNSSBjb25maWd1cmF0aW9uIGZvciBYZW4gKHByaXZpbGVnZWQgYWdlbnQpIGFu
ZCB0aGUgc2hhcmVkDQptZW1vcnkgY29uZmlndXJhdGlvbiBmb3IgYWxsIGFnZW50cyBhcmUgcHJv
dmlkZWQgdW5kZXIgdGhlICIvY2hvc2VuIg0Kbm9kZSBhbmQgYXJlIHVzZWQgc3RyaWN0bHkgYnkg
WGVuIGZvciBpdHMgaW5pdGlhbCBjb25maWd1cmF0aW9uLg0KLSB0aGUgc2NtaV9zaG0gYW5kIFND
TUkgY29uZmlndXJhdGlvbiBmb3IgRG9tMCBhcmUgcGxhY2VkIGluIHRoZQ0KIi9maXJtd2FyZS9z
Y21pIiBub2RlIHNvIHRoYXQgdGhleSBjYW4gYmUgbW92ZWQgdG8gRG9tMCB3aXRob3V0DQphbnkg
Y2hhbmdlcy4NCg0KVGhpcyBjb25maWd1cmF0aW9uIGFsbG93cyB0aGUgdXNlIG9mIFhlbi1zcGVj
aWZpYyBub2RlcyB0byBwcm92aWRlDQppbmZvcm1hdGlvbiBzdHJpY3RseSBuZWVkZWQgYnkgWGVu
IHdoaWxlIHVzaW5nIHRoZSBkZWZhdWx0IFNDTUkNCmNvbmZpZ3VyYXRpb24gZm9yIERvbTAgYW5k
IG90aGVyIGRvbWFpbnMuIEFzIGEgcmVzdWx0LCBubyBhZGRpdGlvbmFsDQpiaW5kaW5ncyBuZWVk
IHRvIGJlIGludHJvZHVjZWQgdG8gdGhlIGRldmljZSB0cmVlLg0KDQpTaWduZWQtb2ZmLWJ5OiBH
cnlnb3JpaSBTdHJhc2hrbyA8Z3J5Z29yaWlfc3RyYXNoa29AZXBhbS5jb20+DQpTaWduZWQtb2Zm
LWJ5OiBPbGVrc2lpIE1vaXNpZWlldiA8b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQotLS0N
Cg0KDQoNCiAuLi4vYXJtL2Zpcm13YXJlL2FybS1zY21pLXByb3Bvc2FsLnJzdCAgICAgICAgfCAy
MjQgKysrKysrKysrKysrKysrKysrDQogMSBmaWxlIGNoYW5nZWQsIDIyNCBpbnNlcnRpb25zKCsp
DQogY3JlYXRlIG1vZGUgMTAwNjQ0IGRvY3MvaHlwZXJ2aXNvci1ndWlkZS9hcm0vZmlybXdhcmUv
YXJtLXNjbWktcHJvcG9zYWwucnN0DQoNCmRpZmYgLS1naXQgYS9kb2NzL2h5cGVydmlzb3ItZ3Vp
ZGUvYXJtL2Zpcm13YXJlL2FybS1zY21pLXByb3Bvc2FsLnJzdCBiL2RvY3MvaHlwZXJ2aXNvci1n
dWlkZS9hcm0vZmlybXdhcmUvYXJtLXNjbWktcHJvcG9zYWwucnN0DQpuZXcgZmlsZSBtb2RlIDEw
MDY0NA0KaW5kZXggMDAwMDAwMDAwMC4uZmNjMmVkMmI2NQ0KLS0tIC9kZXYvbnVsbA0KKysrIGIv
ZG9jcy9oeXBlcnZpc29yLWd1aWRlL2FybS9maXJtd2FyZS9hcm0tc2NtaS1wcm9wb3NhbC5yc3QN
CkBAIC0wLDAgKzEsMjI0IEBADQorDQorUHJvcG9zYWwgZm9yIFNDTUkgbXVsdGktYWdlbnQgZHJp
dmVyIGJpbmRpbmdzDQorPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09DQorDQorTm93IHRoZSBYZW4gY29uZmlndXJhdGlvbiBmb3IgU0NNSSBtdWx0aS1hZ2VudCBz
dXBwb3J0IGlzIGRvbmUgaW4gYSBiaXQgY29tcGxpY2F0ZWQgd2F5LCBlc3BlY2lhbGx5DQorZnJv
bSBTQ01JIG11bHRpLWFnZW50IGRyaXZlciBpbml0aWFsaXphdGlvbiBhbmQgRG9tMCBEVCBtYW5p
cHVsYXRpb24gcG9pbnQgb2Ygdmlldy4NCitBbHNvIGl0IGRvZXMgbm90IHRha2UgaW50byBhY2Nv
dW50IGZ1dHVyZSByZXF1aXJlbWVudHMgdG8gc3VwcG9ydCBTQ1AgU0NNSSBGVy4NCisNCitUbyBl
bmFibGUgU0NNSSBtdWx0aS1hZ2VudCB1c2VyIG5lZWQ6DQorDQorKiB0YWtlIGhvc3QgRFQgd2l0
aCBiYXNpYyBTQ01JIGVuYWJsZWQNCisqIGFkZCBTQ01JIHNoYXJlZC1tZW1vcnkgbm9kZXMgZm9y
IGFsbCBhZ2VudHMNCisqIHVwZGF0ZSBTQ01JIG5vZGUgdG8gcG9pbnQgb24gU0NNSSBYZW4gbWFu
YWdlbWVudCBjaGFubmVsIChgYFtzbWMtaWQsIHNobWVtXWBgKQ0KKyogYWRkICJ4ZW4sc2NtaS1z
ZWNvbmRhcnktYWdlbnRzIiBwcm9wZXJ0eSB0byB0aGUgIlxjaG9zZW4iIG5vZGUNCisNCisuLiBj
b2RlOjoNCisNCisgICBjaG9zZW4gew0KKyAgICAgIHhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMg
PSA8DQorICAgICAgICAgICAgICAgICAgICAxIDB4ODIwMDAwMDMgJnNjbWlfc2htXzENCisgICAg
ICAgICAgICAgICAgICAgIDIgMHg4MjAwMDAwNCAmc2NtaV9zaG1fMg0KKyAgICAgICAgICAgICAg
ICAgICAgMyAweDgyMDAwMDA1ICZzY21pX3NobV8zDQorICAgICAgICAgICAgICAgICAgICA0IDB4
ODIwMDAwMDYgJnNjbWlfc2htXzQ+Ow0KKyAgICB9DQorDQorICAgIC97DQorICAgICAgICAgICAg
Ly8gU0NNSSBzaGFyZWQtbWVtb3J5IG5vZGVzIGZvciBhbGwgYWdlbnRzDQorICAgICAgICAgICAg
c2NtaV9zaG1fMCA6IHNyYW1ANDdmZjAwMDAgew0KKyAgICAgICAgICAgICAgICBjb21wYXRpYmxl
ID0gImFybSxzY21pLXNobWVtIjsNCisgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYw
MDAwIDB4MCAweDEwMDA+Ow0KKyAgICAgICAgICAgIH07DQorICAgICAgICAgICAgc2NtaV9zaG1f
MTogc3JhbUA0N2ZmMTAwMCB7DQorICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFy
bSxzY21pLXNobWVtIjsNCisgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMTAw
MCAweDAgMHgxMDAwPjsNCisgICAgICAgICAgICB9Ow0KKyAgICAgICAgICAgIHNjbWlfc2htXzI6
IHNyYW1ANDdmZjIwMDAgew0KKyAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0s
c2NtaS1zaG1lbSI7DQorICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjIwMDAg
MHgwIDB4MTAwMD47DQorICAgICAgICAgICAgfTsNCisgICAgICAgICAgICBzY21pX3NobV8zOiBz
cmFtQDQ3ZmYzMDAwIHsNCisgICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNj
bWktc2htZW0iOw0KKyAgICAgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYzMDAwIDB4
MCAweDEwMDA+Ow0KKyAgICAgICAgICAgIH07DQorICAgICAgICAgICAgc2NtaV9zaG1fNDogc3Jh
bUA0N2ZmNDAwMCB7DQorICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21p
LXNobWVtIjsNCisgICAgICAgICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmNDAwMCAweDAg
MHgxMDAwPjsNCisgICAgICAgICAgICB9Ow0KKw0KKyAgICAgICAgICAgIGZpcm13YXJlIHsNCisg
ICAgICAgICAgICAgICAgc2NtaTogc2NtaSB7DQorICAgICAgICAgICAgICAgICAgICBjb21wYXRp
YmxlID0gImFybSxzY21pLXNtYyI7DQorICAgICAgICAgICAgICAgICAgICBhcm0sIHNtYyAtIGlk
ID0gPDB4ODIwMDAwMDI+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IGNoYW5uZWwgInNtYy1p
ZCINCisgICAgICAgICAgICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0gPCAxPjsNCisgICAgICAg
ICAgICAgICAgICAgICNzaXplLWNlbGxzID0gPCAwPjsNCisgICAgICAgICAgICAgICAgICAgICNh
Y2Nlc3MtY29udHJvbGxlci1jZWxscyA9IDwgMT47DQorICAgICAgICAgICAgICAgICAgICBzaG1l
bSA9IDwmc2NtaV9zaG1fMD47IDwtLS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQgY2hhbm5lbCAic2ht
ZW0iDQorDQorICAgICAgICAgICAgICAgICAgICBwcm90b2NvbEBYew0KKyAgICAgICAgICAgICAg
ICAgICAgfTsNCisgICAgICAgICAgICAgICAgfTsNCisgICAgICAgICAgICB9Ow0KKyAgICB9DQor
DQorSW1wb3J0YW50IHRoaW5nIHRvIG5vdGUgaXMgdGhhdCBhbGwgaW5mb3JtYXRpb24gYWJvdXQg
bXVsdGktY2hhbm5lbCBzdXBwb3J0IGlzIHN0cmljdGx5IFhlbiBzcGVjaWZpYy4NCisNCitEdXJp
bmcgaW5pdGlhbGl6YXRpb24gdGhlIFNDTUkgbXVsdGktYWdlbnQgZHJpdmVyIHVzZXMgSG9zdCBE
VCBTQ01JIG5vZGUgYW5kDQorInhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMiIHByb3BlcnR5IHRv
IGluaXQgaXRzZWxmIGFuZCB0aGVuLCBkdXJpbmcgRG9tMCBjcmVhdGlvbiwgbWFuaXB1bGF0ZXMN
CitEb20wIERUIHRvIHJlbW92ZSBYZW4gc3BlY2lmaWMgU0NNSSBpbmZvIGFuZCB1cGRhdGUgZG9t
MCBTQ01JIG5vZGVzIHdpdGggRG9tMCBTQ01JIGFnZW50IHNwZWNpZmljDQoraW5mb3JtYXRpb24u
DQorDQorVGhlcmUgYXJlIHR3byBuZWdhdGl2ZSBwb2ludHM6DQorDQorMSkgRG91YmxlIERUIG1v
ZGlmaWNhdGlvbiAtIG9uZSBpcyB1c2VyIHRvIHNldCB1cCBTQ01JIFhlbiBzdXBwb3J0IGluIEhv
c3QgRFQsIHNlY29uZCAtDQorICAgRG9tMCBEVCBtYW5pcHVsYXRpb24uDQorMikgSW4gY2FzZSBv
ZiBmdXR1cmUgc3VwcG9ydCBvZiBtYWlsYm94IHNoYXJlZC1tZW1vcnkgdHJhbnNwb3J0IHRoZXJl
IGNvdWxkIGJlIHVwIHRvIDQgbWFpbGJveGVzIGFuZA0KKyAgIHVwIHRvIDIgc2hhcmVkLW1lbW9y
aWVzIHBlciBTQ01JIGFnZW50IGNoYW5uZWwuDQorDQorSGVuY2UgU0NNSSBtdWx0aS1hZ2VudCBz
dXBwb3J0IGlzIFhlbiBzcGVjaWZpYyBrbm93bGVkZ2UgdGhlcmUgaXMgYSBwcm9wb3NhbCB0byBh
ZGQgaXQgYXMgWGVuDQorc3BlY2lmaWMgRFQgZGVmaW5pdGlvbnMgYW5kIHNvIG1pbmltaXplIEhv
c3QgYW5kIERvbTAgRFQgbWFuaXB1bGF0aW9ucy4NCitUaG9zZSBkZWZpbml0aW9ucyBjYW4gYmUg
YWRkZWQgaW4gIi9jaG9zZW4iIG9yLCBpZGVhbGx5LCBpbiAieGVuLGNvbmZpZyIgbm9kZSAobGlr
ZSBpbiBIeXBlcmxhdW5jaCBkZXNpZ24pLg0KKw0KK1RoZSBTQ01JIGJpbmRpbmcgc3RheXMgZ2Vu
ZXJpYywganVzdCB0d28gU0NNSSBub2RlcyBkZWZpbmVkIC0gb25lIGZvciBYZW4gbWFuYWdlbWVu
dCBjaGFubmVsIGFuZA0KK29uZSBmb3IgSG9zdCBEb20wIE9TUE0uDQorDQorRXhhbXBsZSBvZiB1
c2luZyAiY2hvc2VuIiBmb3IgY29uZmlndXJhdGlvbjoNCisNCisuLiBjb2RlOjoNCisNCisgICAg
L3sNCisNCisgICAgICAgIGNob3NlbiB7DQorICAgICAgICAgICAgLi4uDQorDQorICAgICAgICAg
ICAgLy8gWGVuIFNDTUkgbWFuYWdlbWVudCBjaGFubmVsDQorICAgICAgICAgICAgc2NtaV9zaG1f
MCA6IHNyYW1ANDdmZjAwMDAgew0KKyAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxz
Y21pLXNobWVtIjsNCisgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYwMDAwIDB4MCAw
eDEwMDA+Ow0KKyAgICAgICAgICAgIH07DQorICAgICAgICAgICAgc2NtaV94ZW46IHNjbWkgew0K
KyAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNtYyI7DQorICAgICAgICAg
ICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAwMDAwMj47IDwtLS0gWGVuIG1hbmVnZW1lbnQgYWdl
bnQgc21jLWlkDQorICAgICAgICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0gPCAxPjsNCisgICAg
ICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8IDA+Ow0KKyAgICAgICAgICAgICAgICAjYWNjZXNz
LWNvbnRyb2xsZXItY2VsbHMgPSA8IDE+Ow0KKyAgICAgICAgICAgICAgICBzaG1lbSA9IDwmc2Nt
aV9zaG1fMD47IDwtLS0gWGVuIG1hbmVnZW1lbnQgYWdlbnQgc2htZW0NCisgICAgICAgICAgICB9
Ow0KKw0KKyAgICAgICAgICAgIC8vIFNDTUkgbXVsdGktYWdlbnQgY29uZmlndXJhdGlvbg0KKyAg
ICAgICAgICAgIHNjbWlfc2htXzI6IHNyYW1ANDdmZjIwMDAgew0KKyAgICAgICAgICAgICAgICAg
ICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQorICAgICAgICAgICAgICAgICAgICBy
ZWcgPSA8MHgwIDB4NDdmZjIwMDAgMHgwIDB4MTAwMD47DQorICAgICAgICAgICAgfTsNCisgICAg
ICAgICAgICBzY21pX3NobV8zOiBzcmFtQDQ3ZmYzMDAwIHsNCisgICAgICAgICAgICAgICAgICAg
IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KKyAgICAgICAgICAgICAgICAgICAgcmVn
ID0gPDB4MCAweDQ3ZmYzMDAwIDB4MCAweDEwMDA+Ow0KKyAgICAgICAgICAgIH07DQorICAgICAg
ICAgICAgc2NtaV9zaG1fNDogc3JhbUA0N2ZmNDAwMCB7DQorICAgICAgICAgICAgICAgICAgICBj
b21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCisgICAgICAgICAgICAgICAgICAgIHJlZyA9
IDwweDAgMHg0N2ZmNDAwMCAweDAgMHgxMDAwPjsNCisgICAgICAgICAgICB9Ow0KKyAgICAgICAg
ICAgIHhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMgPSA8DQorICAgICAgICAgICAgICAgICAgICAg
ICAgMSAweDgyMDAwMDAzICZzY21pX3NobQ0KKyAgICAgICAgICAgICAgICAgICAgICAgIDIgMHg4
MjAwMDAwNCAmc2NtaV9zaG1fMg0KKyAgICAgICAgICAgICAgICAgICAgICAgIDMgMHg4MjAwMDAw
NSAmc2NtaV9zaG1fMw0KKyAgICAgICAgICAgICAgICAgICAgICAgIDQgMHg4MjAwMDAwNiAmc2Nt
aV9zaG1fND47DQorICAgICAgICB9Ow0KKw0KKyAgICAgICAgLy8gSG9zdCBTQ01JIE9TUE0gY2hh
bm5lbCAtIHByb3ZpZGVkIHRvIHRoZSBEb20wIGFzIGlzIGlmIFNDTUkgZW5hYmxlZCBmb3IgaXQN
CisgICAgICAgIHNjbWlfc2htOiBzcmFtQDQ3ZmYxMDAwIHsNCisgICAgICAgICAgICAgICAgY29t
cGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQorICAgICAgICAgICAgICAgIHJlZyA9IDwweDAg
MHg0N2ZmMTAwMCAweDAgMHgxMDAwPjsNCisgICAgICAgIH07DQorDQorICAgICAgICBmaXJtd2Fy
ZSB7DQorICAgICAgICAgICAgc2NtaTogc2NtaSB7DQorICAgICAgICAgICAgICAgIGNvbXBhdGli
bGUgPSAiYXJtLHNjbWktc21jIjsNCisgICAgICAgICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgy
MDAwMDAzPjsgPC0tLSBIb3N0IE9TUE0gYWdlbnQgc21jLWlkDQorICAgICAgICAgICAgICAgICNh
ZGRyZXNzLWNlbGxzID0gPCAxPjsNCisgICAgICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8IDA+
Ow0KKyAgICAgICAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG0+OyA8LS0tIEhvc3QgT1NQTSBh
Z2VudCBzaG1lbQ0KKw0KKyAgICAgICAgICAgICAgICBwcm90b2NvbEBYew0KKyAgICAgICAgICAg
ICAgICB9Ow0KKyAgICAgICAgICAgIH07DQorICAgICAgICB9Ow0KKyAgICB9DQorDQorDQorSW4g
dGhlIGFib3ZlIGNhc2U6DQorDQorMSkgWGVuIFNDTUkgbXVsdGktYWdlbnQgY2FuIGJlIHByb2Jl
ZCB3aXRoIERUIGNvbmZpZ3VyYXRpb24gZnJvbSAiY2hvc2VuIiAob3Igc3BlY2lhbCAieGVuLGNv
bmZpZyIpDQorICAgbm9kZSBhbmQgYWxsIFhlbiByZWxhdGVkIG5vZGVzIGNhbiBiZSBlYXNpbHkg
ZHJvcHBlZCBmcm9tIERvbTAgRFQuDQorMikgSG9zdCBTQ01JIE9TUE0gY2hhbm5lbCBEVCBub2Rl
cyBjYW4gYmUgY29waWVkIHRvIERvbTAgRFQgd2l0aG91dCBjaGFuZ2VzIGlmIFNDTUkgZW5hYmxl
ZCBmb3IgaXQuDQorMykgRnV0dXJlIHN1cHBvcnQgZm9yIG1haWxib3ggc2hhcmVkLW1lbW9yeSB0
cmFuc3BvcnQgKFNDUCBTQ01JIEZXKSBjYW4gYmUgc2ltcGxpZmllZCBhcyBubyBtb3JlDQorICAg
bWFuaXB1bGF0aW9uIHJlcXVpcmVkIHdpdGggRG9tMCBTQ01JICJhcm0sc21jLWlkIiBhbmQgInNo
bWVtIiBEVCBwcm9wZXJ0aWVzLg0KKw0KKw0KK0V4YW1wbGUgb2YgdXNpbmcgInhlbixjb25maWci
IGZvciBjb25maWd1cmF0aW9uOg0KKw0KKy4uIGNvZGU6Og0KKw0KKyAgICBoeXBlcnZpc29yIHsN
CisgICAgICAgIGNvbXBhdGlibGUgPSDigJxoeXBlcnZpc29yLHhlbuKAnQ0KKw0KKyAgICAgICAg
Ly8gQ29uZmlndXJhdGlvbiBjb250YWluZXINCisgICAgICAgIGNvbmZpZyB7DQorICAgICAgICAg
ICAgY29tcGF0aWJsZSA9ICJ4ZW4sY29uZmlnIjsNCisgICAgICAgICAgICAuLi4NCisNCisgICAg
ICAgICAgICAvLyBYZW4gU0NNSSBtYW5hZ2VtZW50IGNoYW5uZWwNCisgICAgICAgICAgICBzY21p
X3NobV8wIDogc3JhbUA0N2ZmMDAwMCB7DQorICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAi
YXJtLHNjbWktc2htZW0iOw0KKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjAwMDAg
MHgwIDB4MTAwMD47DQorICAgICAgICAgICAgfTsNCisgICAgICAgICAgICBzY21pX3hlbjogc2Nt
aSB7DQorICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc21jIjsNCisgICAg
ICAgICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAwMDAyPjsgPC0tLSBYZW4gbWFuZWdlbWVu
dCBhZ2VudCBzbWMtaWQNCisgICAgICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8IDE+Ow0K
KyAgICAgICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwgMD47DQorICAgICAgICAgICAgICAgICNh
Y2Nlc3MtY29udHJvbGxlci1jZWxscyA9IDwgMT47DQorICAgICAgICAgICAgICAgIHNobWVtID0g
PCZzY21pX3NobV8wPjsgPC0tLSBYZW4gbWFuZWdlbWVudCBhZ2VudCBzaG1lbQ0KKyAgICAgICAg
ICAgIH07DQorDQorICAgICAgICAgICAgLy8gU0NNSSBtdWx0aS1hZ2VudCBjb25maWd1cmF0aW9u
DQorICAgICAgICAgICAgc2NtaV9zaG1fMjogc3JhbUA0N2ZmMjAwMCB7DQorICAgICAgICAgICAg
ICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCisgICAgICAgICAgICAgICAg
ICAgIHJlZyA9IDwweDAgMHg0N2ZmMjAwMCAweDAgMHgxMDAwPjsNCisgICAgICAgICAgICB9Ow0K
KyAgICAgICAgICAgIHNjbWlfc2htXzM6IHNyYW1ANDdmZjMwMDAgew0KKyAgICAgICAgICAgICAg
ICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQorICAgICAgICAgICAgICAgICAg
ICByZWcgPSA8MHgwIDB4NDdmZjMwMDAgMHgwIDB4MTAwMD47DQorICAgICAgICAgICAgfTsNCisg
ICAgICAgICAgICBzY21pX3NobV80OiBzcmFtQDQ3ZmY0MDAwIHsNCisgICAgICAgICAgICAgICAg
ICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KKyAgICAgICAgICAgICAgICAgICAg
cmVnID0gPDB4MCAweDQ3ZmY0MDAwIDB4MCAweDEwMDA+Ow0KKyAgICAgICAgICAgIH07DQorICAg
ICAgICAgICAgeGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyA9IDwNCisgICAgICAgICAgICAgICAg
ICAgICAgICAxIDB4ODIwMDAwMDMgJnNjbWlfc2htDQorICAgICAgICAgICAgICAgICAgICAgICAg
MiAweDgyMDAwMDA0ICZzY21pX3NobV8yDQorICAgICAgICAgICAgICAgICAgICAgICAgMyAweDgy
MDAwMDA1ICZzY21pX3NobV8zDQorICAgICAgICAgICAgICAgICAgICAgICAgNCAweDgyMDAwMDA2
ICZzY21pX3NobV80PjsNCisgICAgICAgIH07DQorICAgIH07DQorDQorICAgIC97DQorICAgICAg
ICAvLyBIb3N0IFNDTUkgT1NQTSBjaGFubmVsIC0gcHJvdmlkZWQgdG8gdGhlIERvbTAgYXMgaXMg
aWYgU0NNSSBlbmFibGVkIGZvciBpdA0KKyAgICAgICAgc2NtaV9zaG06IHNyYW1ANDdmZjEwMDAg
ew0KKyAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCisgICAg
ICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYxMDAwIDB4MCAweDEwMDA+Ow0KKyAgICAgICAg
fTsNCisNCisgICAgICAgIGZpcm13YXJlIHsNCisgICAgICAgICAgICBzY21pOiBzY21pIHsNCisg
ICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0KKyAgICAgICAgICAg
ICAgICBhcm0sc21jLWlkID0gPDB4ODIwMDAwMDM+OyA8LS0tIEhvc3QgT1NQTSBhZ2VudCBzbWMt
aWQNCisgICAgICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8IDE+Ow0KKyAgICAgICAgICAg
ICAgICAjc2l6ZS1jZWxscyA9IDwgMD47DQorICAgICAgICAgICAgICAgIHNobWVtID0gPCZzY21p
X3NobT47IDwtLS0gSG9zdCBPU1BNIGFnZW50IHNobWVtDQorDQorICAgICAgICAgICAgICAgIHBy
b3RvY29sQFh7DQorICAgICAgICAgICAgICAgIH07DQorICAgICAgICAgICAgfTsNCisgICAgICAg
IH07DQorICAgIH0NCi0tIA0KMi4zNC4xDQo=


From xen-devel-bounces@lists.xenproject.org Mon May 19 16:09:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 16:09:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990052.1374001 (Exim 4.92)
	(envelope-from )
	id 1uH33P-0003jh-Bw; Mon, 19 May 2025 16:09:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990052.1374001; Mon, 19 May 2025 16:09:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH33P-0003ja-8g; Mon, 19 May 2025 16:09:27 +0000
Received: by outflank-mailman (input) for mailman id 990052;
 Mon, 19 May 2025 16:09:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH33N-0003jU-My
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 16:09:25 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a0d88536-34cb-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 18:09:23 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad5394be625so551749766b.2
 for ; Mon, 19 May 2025 09:09:23 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d04aed7sm609812166b.9.2025.05.19.09.09.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 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" 
X-Inumbo-ID: a0d88536-34cb-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747670962; x=1748275762; darn=lists.xenproject.org;
        h=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;
        bh=bg5mb81A6bM7YU+0LviaGY6QXJz6XtKaehihYECsyDg=;
        b=KGiRSUimcQCkC1fqEmDUJBnJMPNP37LS15Fl091y2lA5dLCHi/aFNON8Z2YWSslskS
         DgQSgYK4czopDZtozfS6a5SgwIqrUPmSrui6RVNuERuzCA19aS1IPPNUQsIJCNcUqZKY
         bwr5l7YNXBy86AnNFGROeaS4hj+D2JOX8TSp8nThSctNjxIBfvHvuXCdldZp6q/yE4FC
         QlZRiOX17uB5vry/7ftky8cD1iWZt2ztjImFIk2ONVgx9LHzL6vDBaEX42jl6oxlpGT0
         1APUrm+gBT7ckZbT70vPdPaFm9DXvwApoIdTcGiv78t8vkef4BtF902ulPtpbi3L9tZP
         Nf5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747670962; x=1748275762;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=bg5mb81A6bM7YU+0LviaGY6QXJz6XtKaehihYECsyDg=;
        b=qOg+G2oEVsgI1JIGiuLsuEXw/H6k6o9Pi1HpGjl9/5AJtlrs8xYu/0WkSmrLHPxDNR
         cUb3+r56WWu/+6b7oNWSyo1ayn6DqyS0ZyWONgM/6v+y3qo5kWHikLvXqIs0ZhcQlw/8
         1QPyWAkZ/4HlBHL0kziR32JQvwEyJBuTdz518pPZDxpPxkG6njy1+PShXMK4/wZErl+a
         qN0aTlufSZF/e3Qktwe8PR9VrSRCJnIbb48spNCvo/UZlcq7araIoigPbSTiCHChcVO+
         0ne+PtIsbSRTt8wtdy7cLY34Mv2M4LJYCvO1T7P8JM3mhRN2gSTQtGQuUnljtGs249jI
         rN3w==
X-Forwarded-Encrypted: i=1; AJvYcCWKaCcmUvdSbRXgdJcCub5FY02dAR07Yw6GCwsCorP8n5NfOmYWfD6ATlxH+cpxQd8NpN50hUQUMvQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzMiJBwTcPSAZtRe/swsetYehZ5LZBiSjcF8ykr6CoVnRPXzAHL
	03AfwNritY8bpGDdmR66qYI6uB071bTenHI+ffGNKVvcIVJyIq5eaB/3
X-Gm-Gg: ASbGncvS9YEoNdXGhjD0Q4iytaoLKlh9wsJ9hvE+XyWTkd0+2sST8WzY0GfcHEpCTRM
	1j54kuoN76RsvuibtnWbk0wpLKrkbqLbJlDlLKh0NAqRy0yjGbh862icFaSu3SYdlNnGHdJGlpG
	IJx++KnSQY3IHS5jKg5oKMZ6Gvk9Q2XSsQ1qErq5sR8br9w5Dzd59qZDFPPoyIGY85cQ9GHeYGn
	meiRRX2VAP9W0viaQdN4aMHwkhwRn9vRzsji6UFZD0OW1EURuMSJWPPYdaYUbWqvJysp0lIADJt
	X40Jd9HiAOAhIlQoZcsqp+/eUeAVricjbTxXThMcibVgkDYBl/SzPujzsx+SZqE2wf/674n5ho9
	6gneIf+QLUX2li53RF7VtfSL7N9H3c//xviA=
X-Google-Smtp-Source: AGHT+IE7Qcskq+doyDIr6DYTFFajJaloDFJKuWkhhfJBgA0hHkLjZaj/hOuanixi07yq/J/reSlJ2w==
X-Received: by 2002:a17:906:c14d:b0:ad2:26f0:a76 with SMTP id a640c23a62f3a-ad536b7f1d2mr1170595666b.13.1747670961569;
        Mon, 19 May 2025 09:09:21 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------PMQ020XTGqPtvlBYXUp9Qtpu"
Message-ID: 
Date: Mon, 19 May 2025 18:09:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 11/16] xen/riscv: aplic_init() implementation
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <9129b10432dfc7ff8ba451842204342171da7dc1.1746530883.git.oleksii.kurochko@gmail.com>
 <057fc2ce-d4d6-4e14-987d-bef6f909eaff@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <057fc2ce-d4d6-4e14-987d-bef6f909eaff@suse.com>

This is a multi-part message in MIME format.
--------------PMQ020XTGqPtvlBYXUp9Qtpu
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/15/25 11:06 AM, Jan Beulich wrote:
>> --- a/xen/arch/riscv/aplic.c
>> +++ b/xen/arch/riscv/aplic.c
>> @@ -9,19 +9,121 @@
>>    * Copyright (c) 2024-2025 Vates
>>    */
>>   
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>> +#include 
>> +
>> +#include "aplic-priv.h"
> Besides this, are there going to be any other files including this private
> header? If not, why have the header in the first place?

Yes, structure aplic_priv is going to be reused in vaplic.c (which isn't introduce yet):
   https://gitlab.com/xen-project/people/olkur/xen/-/blob/latest/xen/arch/riscv/vaplic.c#L56

>> +    /* Set interrupt type and default priority for all interrupts */
>> +    for ( i = 1; i <= aplic_info.num_irqs; i++ )
>> +    {
>> +        writel(0, &aplic.regs->sourcecfg[i - 1]);
> What guarantees the loop to not run past the array's size?

riscv,aplic binding:
   https://github.com/torvalds/linux/blob/a5806cd506af5a7c19bcd596e4708b5c464bfd21/Documentation/devicetree/bindings/interrupt-controller/riscv%2Caplic.yaml#L57
Should I add an ASSERT() or panic() at the moment where num_irqs are
initialized to double check a binding?

>
>> +        /*
>> +         * 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.
>> +         */
>> +        writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i - 1]);
>> +    }
> Seeing the subtractions of 1 here, why's the loop header not simply
>
>      for ( i = 0; i < aplic_info.num_irqs; i++ )
>
> (i.e. the more conventional form)?

To follow the definition of aplic's binding mentioned about where minimum is 1.
But I think we can use convention form.

>
>> +    writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg);
>> +}
>> +
>> +static int __init cf_check aplic_init(void)
>> +{
>> +    int rc;
>> +    dt_phandle imsic_phandle;
>> +    uint32_t irq_range[num_possible_cpus() * 2];
> Are you going to have enough stack space when num_possible_cpus() is pretty
> large?

When num_possible_cpus() will be pretty large then it will better to allocate irq_range[]
dynamically.

Does it make sense to re-write now?

>> +    const struct dt_device_node *node = aplic_info.node;
>> +
>> +    /* Check for associated imsic node */
>> +    rc = dt_property_read_u32(node, "msi-parent", &imsic_phandle);
>> +    if ( !rc )
>> +        panic("%s: IDC mode not supported\n", node->full_name);
>> +
>> +    imsic_node = dt_find_node_by_phandle(imsic_phandle);
>> +    if ( !imsic_node )
>> +        panic("%s: unable to find IMSIC node\n", node->full_name);
>> +
>> +    rc = dt_property_read_u32_array(imsic_node, "interrupts-extended",
>> +                                    irq_range, ARRAY_SIZE(irq_range));
>> +    if ( rc )
>> +        panic("%s: unable to find interrupt-extended in %s node\n",
>> +              __func__, imsic_node->full_name);
>> +
>> +    if ( irq_range[1] == IRQ_M_EXT )
> How do you know the array has had 2 or ...
>
>> +        /* Machine mode imsic node, ignore this aplic node */
>> +        return 0;
>> +
>> +    for ( unsigned int i = 0; i < ARRAY_SIZE(irq_range); i += 2 )
>> +    {
>> +        if ( irq_range[i + 1] != irq_range[1] )
>> +            panic("%s: mode[%d] != %d\n", __func__, i + 1, irq_range[1]);
>> +    }
> ... or even all of the slots populated? Anything not populated by the DT
> function will still have the stack contents that had been left by earlier
> call chains. (The loop also makes little sense to start from 0.)

Do you mean I asked allocated irq_range[8*2] but DT node has only irq_range[4*2]?
Then it will be really an issue. And out-of-range access will occur in
dt_property_read_variable_u32_array(). I need another way to check then...

>
> I'm also puzzled by there not being any further use of the values later
> in the function.

Yes, because we need this values only to check that DT node's property is
correctly created.

>
>> +    rc = imsic_init(imsic_node);
>> +    if ( rc )
>> +        panic("%s: Failded to initialize IMSIC\n", node->full_name);
>> +
>> +    /* Find out number of interrupt sources */
>> +    rc = dt_property_read_u32(node, "riscv,num-sources", &aplic_info.num_irqs);
>> +    if ( !rc )
> Assigning a bool return value to an int local var, which generally hold
> error codes, is confusing. I don't think you really need to use a local
> variable here.

Considering that I am panicing for all the case where rc is used and rc isn't printed
then we can really just drop rc.

~ Oleksii

--------------PMQ020XTGqPtvlBYXUp9Qtpu
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 11:06 AM, Jan Beulich wrote:
    
    
    
      
    
        
    --- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,19 +9,121 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include <xen/device_tree.h>
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/irq.h>
+#include <xen/mm.h>
 #include <xen/sections.h>
 #include <xen/types.h>
+#include <xen/vmap.h>
+
+#include "aplic-priv.h"

    
      
    
      
    Besides this, are there going to be any other files including this private
header? If not, why have the header in the first place?
    
    
    
    
    Yes, structure aplic_priv is going to be reused in vaplic.c (which isn't introduce yet):
  https://gitlab.com/xen-project/people/olkur/xen/-/blob/latest/xen/arch/riscv/vaplic.c#L56

    
    
    
      
    
        
    +    /* Set interrupt type and default priority for all interrupts */
+    for ( i = 1; i <= aplic_info.num_irqs; i++ )
+    {
+        writel(0, &aplic.regs->sourcecfg[i - 1]);

    
      
    
      
    What guarantees the loop to not run past the array's size?
    
    
    
    
    riscv,aplic binding:
  https://github.com/torvalds/linux/blob/a5806cd506af5a7c19bcd596e4708b5c464bfd21/Documentation/devicetree/bindings/interrupt-controller/riscv%2Caplic.yaml#L57
Should I add an ASSERT() or panic() at the moment where num_irqs are
initialized to double check a binding?


    
    
    
      
    

    
      
    
        
    +        /*
+         * 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.
+         */
+        writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i - 1]);
+    }

    
      
    
      
    Seeing the subtractions of 1 here, why's the loop header not simply

    for ( i = 0; i < aplic_info.num_irqs; i++ )

(i.e. the more conventional form)?
    
    
    
    
    To follow the definition of aplic's binding mentioned about where minimum is 1.
But I think we can use convention form.


    
    
    
      
    

    
      
    
        
    +    writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg);
+}
+
+static int __init cf_check aplic_init(void)
+{
+    int rc;
+    dt_phandle imsic_phandle;
+    uint32_t irq_range[num_possible_cpus() * 2];

    
      
    
      
    Are you going to have enough stack space when num_possible_cpus() is pretty
large?
    
    
    
    
    When num_possible_cpus() will be pretty large then it will better to allocate irq_range[]
dynamically.

Does it make sense to re-write now?


    
    
    
      
    
        
    +    const struct dt_device_node *node = aplic_info.node;
+
+    /* Check for associated imsic node */
+    rc = dt_property_read_u32(node, "msi-parent", &imsic_phandle);
+    if ( !rc )
+        panic("%s: IDC mode not supported\n", node->full_name);
+
+    imsic_node = dt_find_node_by_phandle(imsic_phandle);
+    if ( !imsic_node )
+        panic("%s: unable to find IMSIC node\n", node->full_name);
+
+    rc = dt_property_read_u32_array(imsic_node, "interrupts-extended",
+                                    irq_range, ARRAY_SIZE(irq_range));
+    if ( rc )
+        panic("%s: unable to find interrupt-extended in %s node\n",
+              __func__, imsic_node->full_name);
+
+    if ( irq_range[1] == IRQ_M_EXT )

    
      
    
      
    How do you know the array has had 2 or ...


    
      
    
        
    +        /* Machine mode imsic node, ignore this aplic node */
+        return 0;
+
+    for ( unsigned int i = 0; i < ARRAY_SIZE(irq_range); i += 2 )
+    {
+        if ( irq_range[i + 1] != irq_range[1] )
+            panic("%s: mode[%d] != %d\n", __func__, i + 1, irq_range[1]);
+    }

    
      
    
      
    ... or even all of the slots populated? Anything not populated by the DT
function will still have the stack contents that had been left by earlier
call chains. (The loop also makes little sense to start from 0.)
    
    
    
    
    Do you mean I asked allocated irq_range[8*2] but DT node has only irq_range[4*2]?
Then it will be really an issue. And out-of-range access will occur in
dt_property_read_variable_u32_array(). I need another way to check then...


    
    
    
      
    
I'm also puzzled by there not being any further use of the values later
in the function.
    
    
    
    
    Yes, because we need this values only to check that DT node's property is
correctly created.


    
    
    
      
    

    
      
    
        
    +    rc = imsic_init(imsic_node);
+    if ( rc )
+        panic("%s: Failded to initialize IMSIC\n", node->full_name);
+
+    /* Find out number of interrupt sources */
+    rc = dt_property_read_u32(node, "riscv,num-sources", &aplic_info.num_irqs);
+    if ( !rc )

    
      
    
      
    Assigning a bool return value to an int local var, which generally hold
error codes, is confusing. I don't think you really need to use a local
variable here.
    
    
    
    
    Considering that I am panicing for all the case where rc is used and rc isn't printed
then we can really just drop rc.
    
    
    ~ Oleksii

    
  


--------------PMQ020XTGqPtvlBYXUp9Qtpu--


From xen-devel-bounces@lists.xenproject.org Mon May 19 16:23:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 16:23:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990062.1374011 (Exim 4.92)
	(envelope-from )
	id 1uH3HE-0006vq-GT; Mon, 19 May 2025 16:23:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990062.1374011; Mon, 19 May 2025 16:23: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 1uH3HE-0006vj-Cn; Mon, 19 May 2025 16:23:44 +0000
Received: by outflank-mailman (input) for mailman id 990062;
 Mon, 19 May 2025 16:23:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH3HC-0006vd-LP
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 16:23:42 +0000
Received: from mail187-4.suw11.mandrillapp.com
 (mail187-4.suw11.mandrillapp.com [198.2.187.4])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9ee5cfac-34cd-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 18:23:39 +0200 (CEST)
Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail187-4.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4b1NKQ0qRczlfcHv
 for ; Mon, 19 May 2025 16:23:38 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 5edfc141b19041e8a7ebc0513a127574; Mon, 19 May 2025 16:23: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" 
X-Inumbo-ID: 9ee5cfac-34cd-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747671818; x=1747941818;
	bh=BDjeu0XUR0uU2TT/7xPp2UlOmJZUCLxJErnlwMKjE0M=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=d0ogPap/3IqOWqF3UFByhkRN/uhMfHCvnmBfferGevg2JFPoRodB5INUDA0BQzHdo
	 GxivhxefA6XaeFDYokMT68HRDLcZFTqNMA2I5Z1KqtoY+aY821oPIiFE3J8YSZX4u9
	 sRc7tfLpxWSLZHiYm2vThe+t4VyDiRWf22vMqWPsClsMJGLnjzJIBpJWG4YgQMXE1X
	 6+vu3bWeGSKar6wIAePXgvZFqWUg7kshv+0vGDMhC1RYXOMg0iSA1pNfuU0t2kvnfm
	 +6URokkmWbCixbRvgSQFnnlqxtfITSawHprNOWMM9Y0XP/Q4WXtgDfw9xvWhsx6lpr
	 Ys1vp+w/8LvAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747671818; x=1747932318; i=teddy.astie@vates.tech;
	bh=BDjeu0XUR0uU2TT/7xPp2UlOmJZUCLxJErnlwMKjE0M=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=0UjdA5fWBWBAVSI4BdGG20jzib1JotQD55/HC4ZNy0+j833WUt7FOX6Pxu85b1RXN
	 W+M9OewONbofEcwe6DGFWg++TnUkJhoRbiDOVFbseT6CXgSTkIrNnSyzbkTaK4VccP
	 v6YbYPe7uwWO1CwALfVWU4yfHE4ZKfVXZwWYsqtz5lxPcrqw0qCiJLvHgiENFIH9h+
	 fYiBm/WadpSoIFDvRl0t6oHgeIajl0kpyLXKwzg6aWa7u/tiXC2TsPMybZpc8D5x8L
	 x2LVecVzDQJlsLubMe8Vsg7b0d1AVPMV/eCG13AXxXhn0qhMGtOfuU606/ZIqxbzUf
	 JJQB5h1d6bEQw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v2=2004/16]=20xen/riscv:=20add=20ioremap=5F*()=20variants=20using=20ioremap=5Fattr()?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747671815716
Message-Id: 
To: "Oleksii Kurochko" , xen-devel@lists.xenproject.org
Cc: "Alistair Francis" , "Bob Eshleman" , "Connor Davis" , "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" 
References:  <0258c1ac04a73b7d3f9f849507539a329b2998e3.1746530883.git.oleksii.kurochko@gmail.com>
In-Reply-To: <0258c1ac04a73b7d3f9f849507539a329b2998e3.1746530883.git.oleksii.kurochko@gmail.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.5edfc141b19041e8a7ebc0513a127574?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250519:md
Date: Mon, 19 May 2025 16:23:38 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

Le 06/05/2025 =C3=A0 18:53, Oleksii Kurochko a =C3=A9crit=C2=A0:
> Introduce ioremap_attr() as a shared helper to implement architecture-spe=
cific
> +#include 
>   
>   #include 
>   #include 
> @@ -583,3 +584,36 @@ void *__init arch_vmap_virt_end(void)
>   {
>       return (void *)(VMAP_VIRT_START + VMAP_VIRT_SIZE);
>   }
> +
> +static void *ioremap_attr(paddr_t start, size_t len, pte_attr_t attribut=
es)

you probably want __iomem here

> +{
> +    mfn_t mfn =3D _mfn(PFN_DOWN(start));
> +    unsigned int offs =3D start & (PAGE_SIZE - 1);
> +    unsigned int nr =3D PFN_UP(offs + len);
> +    void *ptr =3D __vmap(&mfn, nr, 1, 1, attributes, VMAP_DEFAULT);
> +
> +    if ( ptr =3D=3D NULL )
> +        return NULL;
> +
> +    return ptr + offs;
> +}
> +
> +void __iomem *ioremap_nocache(paddr_t start, size_t len)
> +{
> +    return ioremap_attr(start, len, PAGE_HYPERVISOR_NOCACHE);
> +}
> +
> +void __iomem *ioremap_cache(paddr_t start, size_t len)
> +{
> +    return ioremap_attr(start, len, PAGE_HYPERVISOR);
> +}
> +
> +void __iomem *ioremap_wc(paddr_t start, size_t len)
> +{
> +    return ioremap_attr(start, len, PAGE_HYPERVISOR_WC);
> +}
> +
> +void *ioremap(paddr_t pa, size_t len)

also here

> +{
> +    return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
> +}

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Mon May 19 17:06:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 17:06:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990076.1374021 (Exim 4.92)
	(envelope-from )
	id 1uH3w3-0003vA-FK; Mon, 19 May 2025 17:05:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990076.1374021; Mon, 19 May 2025 17: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 1uH3w3-0003v3-BX; Mon, 19 May 2025 17:05:55 +0000
Received: by outflank-mailman (input) for mailman id 990076;
 Mon, 19 May 2025 17:05:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH3w2-0003ux-BY
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 17:05:54 +0000
Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 839dcb15-34d3-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 19:05:51 +0200 (CEST)
Received: from [192.168.7.202] ([71.202.166.45]) (authenticated bits=0)
 by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 54JH51I01806864
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
 Mon, 19 May 2025 10:05:02 -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" 
X-Inumbo-ID: 839dcb15-34d3-11f0-b892-0df219b8e170
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 54JH51I01806864
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
	s=2025042001; t=1747674303;
	bh=ts02ww6rWZGYsDbofaKTTtQ1Jg1+MlPMrtXd6RLkuKk=;
	h=Date:Subject:From:To:Cc:References:In-Reply-To:From;
	b=TDYGuEm2xJdqKpSk9HUb6mLJjH8QfE3z/oRA2V/xIDKmePX33e93goxahOmGQ2I3j
	 tYmxL9ORcxAW+J0TECixYkLKG+VvUkIVrFR7yvt59YT3tr5smdcmQgUS0uVOC96Mkn
	 sSYguCgZWvX68kWJfDpbLo49PiSKPGTK5KTXUuFPqjsw2DvpSrIN0U0mJhhDP8pDR3
	 tivIbhQZNZ0T9EUyoseNddg/rbQq/eIVkdiejdUHd5BnnDJ3tTJPUqPT6EH/5Qi9t1
	 GvaCx74S+pp94gbDUxJgdUmfAktr9DJqlgg4T78CgXwPWy65LB1zIctvM/IzjBuafK
	 1u5AG60T+DDfw==
Message-ID: <3486006e-f1ad-4ed2-bdb5-5d39c04c2691@zytor.com>
Date: Mon, 19 May 2025 10:05:01 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/3] x86/msr: Convert a native_wrmsr() use to
 native_wrmsrq()
From: Xin Li 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-acpi@vger.kernel.org
Cc: tglx@linutronix.de, mingo@kernel.org, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        peterz@infradead.org, jgross@suse.com, boris.ostrovsky@oracle.com,
        rafael@kernel.org, lenb@kernel.org
References: <20250512084552.1586883-1-xin@zytor.com>
 <20250512084552.1586883-4-xin@zytor.com>
Content-Language: en-US
Autocrypt: addr=xin@zytor.com; keydata=
 xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
 bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
 raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
 VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
 wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
 NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
 tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
 v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
 sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
 QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
 wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
 oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
 vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
 MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
 g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
 cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
 Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
 m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
 JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
 /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
 OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
 dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
 Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
 PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
 gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
 l75w1xInsg==
In-Reply-To: <20250512084552.1586883-4-xin@zytor.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 5/12/2025 1:45 AM, Xin Li (Intel) wrote:
> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
> conversions when a u64 MSR value is splitted into two u32.
> 
> Signed-off-by: Xin Li (Intel) 
> ---
>   arch/x86/coco/sev/core.c | 7 +------
>   1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
> index ff82151f7718..b3ce6fc8b62d 100644
> --- a/arch/x86/coco/sev/core.c
> +++ b/arch/x86/coco/sev/core.c
> @@ -282,12 +282,7 @@ static inline u64 sev_es_rd_ghcb_msr(void)
>   
>   static __always_inline void sev_es_wr_ghcb_msr(u64 val)
>   {
> -	u32 low, high;
> -
> -	low  = (u32)(val);
> -	high = (u32)(val >> 32);
> -
> -	native_wrmsr(MSR_AMD64_SEV_ES_GHCB, low, high);
> +	native_wrmsrq(MSR_AMD64_SEV_ES_GHCB, val);
>   }
>   
>   static int vc_fetch_insn_kernel(struct es_em_ctxt *ctxt,

Just noticed that this patch doesn't apply to tip/x86/core, I will send
it as a separate one.

Thanks!
     Xin


From xen-devel-bounces@lists.xenproject.org Mon May 19 18:25:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 18:25:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990097.1374030 (Exim 4.92)
	(envelope-from )
	id 1uH5BD-0004uv-Kx; Mon, 19 May 2025 18:25:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990097.1374030; Mon, 19 May 2025 18:25:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH5BD-0004uo-I5; Mon, 19 May 2025 18:25:39 +0000
Received: by outflank-mailman (input) for mailman id 990097;
 Mon, 19 May 2025 18:25:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH5BC-0004ui-NP
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 18:25:38 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a89f2adb-34de-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 20:25:36 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ac3eb3fdd2eso869224166b.0
 for ; Mon, 19 May 2025 11:25:36 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d06eac2sm633858666b.63.2025.05.19.11.25.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 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" 
X-Inumbo-ID: a89f2adb-34de-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747679136; x=1748283936; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=F/rjIQCBKeruqH8Cp+9464FqFbhFXXAV61zk0uTknmU=;
        b=RM2sbBig1x7kcDZYv38h7BazmLOyeWVuF1R4VWTLAntFfuG4Bne+q+y9o9QD2QazdR
         36Iv3cCHv8WuPF83FaL4SWaop1cXCbd60M24nl+0SdcdgcbgPUrW2VA0PHC0aczteiGy
         VhZrJGWCNuH4VGEJ6njWxnOYunJawZYTGGlwHEOJURPWsvfyd1MTSrPfdN9MgiK/dCPc
         aNMuD8UpqSzVu+S/E/SxLx0oA1oxyvS4zkcF83Ll7fQT3ZyD0BWduwtBOdcNDxWmk2He
         K/mtC9J2yxplXPQ6ArOmM2IsIae8xGqs3Y9vhdEDbMF9W1aUj6Bc+SpACoSmWvQO9WFn
         EL+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747679136; x=1748283936;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=F/rjIQCBKeruqH8Cp+9464FqFbhFXXAV61zk0uTknmU=;
        b=AkacFoj5PvhQ5eTy1qUJE839oYKPa0uxFNUhE2KoqIPc+ebQ96UxK1kzGfq2T2ltKC
         TmDtvS1XAua+mzupreMw4OaI6kQv4t555yawNdgjSvSwnk47bQhHyHf3+W7G7QMaYuhD
         pmxXpAlIDqW/7HcmjYNYQaDq1nngBK7f3lKe3iHYAcrYYyOZ0DOIxxa3Kx2jRt40Kk/4
         pM8DiTpCWk5fIt8wQ+wsahxOiDmkzuTOCA0dcBlTqiJLh3egN90/lmePqcBL0EjGXTvh
         jWoUOPl7z4OzhofStizdmF6etwYep35f14302zUmCRLodJDeXBHvnQPSX/tdpJD76psd
         iPlg==
X-Forwarded-Encrypted: i=1; AJvYcCWE0t+DOCEzRDY5wQTI4oxzhW3EG4Wt+dGKMSA7cAYw3W3rqIJ0NjwuL+G6CAhDvfiDlLgXGl+j8GA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw95nH6ghlJs/wQ5KssO/g5cwrFoEbNttNGvbqAh7gdxadnWAuo
	yyjGSx+VOlyeLrPH3CRFhHH6NYUuoqTURlP9LVDZR5rKVZWVUyQ43uA8Grd5+I5Lix2TZ4nL+b2
	qpyk=
X-Gm-Gg: ASbGnct9o9D1j1dW8epICZu4Jx38crviUKQRh6Vu1O6vL/+YBon29qxZfDNJYUpGwbv
	mYcT6jF2bZhCmCuymbdctcSMxUKcRkB83wEgEsXQ1d+lg8dO36IZ5dWoGh+QBWZ3A2PwkxI+byZ
	anYCJj77zhCPe8U/XPIi8oICPTmuqmKk3t96b28M9xmPAAVCMX5dtKad8gOSRRjlP2B70RZzJup
	BLTJwrk48m6KyOQ3ClkRkcGMK0PjnWj9Vpt6Bsm5tvfs1bA1cSWm3xqHhR9c5hGGYHmmQLORulz
	z8ZyrY4np34HGlKHnNklx0UAUGtmUx424enbPXVxuEBIBf0hIBrcgs6ZwjNgMg==
X-Google-Smtp-Source: AGHT+IGPZRIk+IkiMFLLJXxsto8tf6DT7jRLXt6Etl23qEUgCc8GJqAaIYAmvFMc+RcLzOyJHzmQjA==
X-Received: by 2002:a17:906:e4a:b0:ad5:3156:2c0c with SMTP id a640c23a62f3a-ad531563099mr960496166b.26.1747679135951;
        Mon, 19 May 2025 11:25:35 -0700 (PDT)
Message-ID: <0e88db3c-0d68-4f4e-ba7c-e826dc0b9cd4@suse.com>
Date: Mon, 19 May 2025 20:25:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 6/6] x86/hvm: reduce the need to flush caches in
 memory_type_changed()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Oleksii Kurochko ,
 Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-7-roger.pau@citrix.com>
  
 <558c7ec2-77ea-42e6-8568-af8b74e19c88@suse.com> 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19.05.2025 16:33, Roger Pau Monné wrote:
> On Mon, May 19, 2025 at 03:22:32PM +0200, Jan Beulich wrote:
>> On 19.05.2025 13:08, Roger Pau Monné wrote:
>>> On Sun, May 18, 2025 at 01:44:49PM +0200, Jan Beulich wrote:
>>>> On 16.05.2025 11:45, Roger Pau Monne wrote:
>>>>> Not sure whether this attempt to reduce cache flushing should get some
>>>>> mention in the CHANGELOG.
>>>>
>>>> Err on the side of adding an entry there?
>>>
>>> Oleksii would you be fine with me adding:
>>>
>>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>>> index 1ea06524db20..fa971cd9e6ee 100644
>>> --- a/CHANGELOG.md
>>> +++ b/CHANGELOG.md
>>> @@ -11,6 +11,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>>     - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
>>>     - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
>>>   - Linux based device model stubdomains are now fully supported.
>>> + - On x86:
>>> +   - Restrict the cache flushing done in memory_type_changed() to improve
>>> +     performance.
>>
>> Maybe better to mention function names here, saying "after a memory type change
>> by a guest" instead?
> 
> It's not just "after a memory type change by a guest", since
> memory_type_changed() is also used for toolstack operations like
> io{mem,ports}_{permit,deny}_access(), that strictly speaking are not
> memory type changes,

Sure, I'm aware. But I didn't think it would matter that much here. Still ...

> neither are done by the guest itself.  I could
> reword to:
> 
>    - Restrict the cache flushing done as a result of guest physical
>      memory map manipulations and memory type changes.
> 
> Does that sound better?

... yes, let's go with this then.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 18:32:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 18:32:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990109.1374041 (Exim 4.92)
	(envelope-from )
	id 1uH5Hp-0006dD-F5; Mon, 19 May 2025 18:32:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990109.1374041; Mon, 19 May 2025 18:32: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 1uH5Hp-0006d6-Bs; Mon, 19 May 2025 18:32:29 +0000
Received: by outflank-mailman (input) for mailman id 990109;
 Mon, 19 May 2025 18:32:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH5Hn-0006d0-NQ
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 18:32:27 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9d026d3a-34df-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 20:32:26 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-60119cd50b6so5508536a12.0
 for ; Mon, 19 May 2025 11:32:26 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d06dc99sm627028766b.62.2025.05.19.11.32.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 11:32: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" 
X-Inumbo-ID: 9d026d3a-34df-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747679546; x=1748284346; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=R0Ho4HsiCtAq+0A9bdVpMy3spydGkiAulkuYxB2+MOU=;
        b=K1UPeEPq5cLV0KOb5iZhn8kp5QNtszriialp0anVCA1fV2P8356ddk7g7R/qVMeS/L
         gFoNfY+jPF98VHUais3Ph/CIgJkQpyIL6eE97mH3yEXo6r8r/jYe3lptBpwzUxuymqQT
         mvWY1mY8ywro/1ynAQrlPADwB5fIHV9WxiQE0ylLVaQ3JRPcrxXB7bV5mrMTOlSmqvBK
         H0jHbxJW535cnQ9nxLN41iEbpFGu3+oZEDjodHKNd11mktVA1oDAxH9KTg5uWDESPPmD
         b+igKFUFBuovAZ6Goh7stQ/scVZT7w6XBiGVA9dM25G361qHWC21lbULYGjCMDIoV5Cz
         b+RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747679546; x=1748284346;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=R0Ho4HsiCtAq+0A9bdVpMy3spydGkiAulkuYxB2+MOU=;
        b=eAvV9qeQ/issV8HDvFcS9HjGWgr9VkPEeCa7NGQa2VQAOrlKPcxefNH5EEok4RCqgC
         EtUmGWqZPL98wxzgD1PvosAiijTppWFeCnBJ48P+wAYGOP9L2MUo/zmDAfdtsSbBAZeB
         OwgBTYyJwGLmKuqSgc6rPwwEPM3WthaF4Omq1crDmh2C5aEATTDXA99AlgsaVXdIy3Gg
         Z9OpsABA26AONPDCOi9y/58u/cHydWqeC+8R2q/li7Hyc5bqO/ukjVdWDJGYfxhUdoeK
         9h+caCNU/Cv1qNlXw2oLLJ+fMCwElHM0WFmF74BNd+6UeL2JE9IoQkzrhQJoR6Fc46FM
         e1uw==
X-Forwarded-Encrypted: i=1; AJvYcCX0o97dMC7hBjOevnDPw8Q3OhRLqMvGI+6r3Pj5egCWXLoBCM9nlzsf/60QIEpI4968PagdPiMUGDE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyfa2hqQlfZVQ+9v/XDlehA4hSThtlrR9enWOzc4UlXWhMqx2LP
	6A5X3SYEkKAWnEJfE89eNhoc+SEgvL0E9doDqrg46LFdc6XPnak7HI9uDAN0hJuDaA==
X-Gm-Gg: ASbGnctgpuFN+lnIIn3qhcqqCsTXmqVpeiyZ3Hvj9aF3WwHJASWIEtOnfUswVf2X5s4
	sAb0URVO4JmGrz9aQ7Kk67ZbjJUmlvkhXdUKfbQMye2w5pDy+RH1B3qUdT4KsKtbfwxImi+T2nS
	iOTAtb907S7w/wTqS1MFsEpy9/0hopGjQh1EetXto+uzCio+l/HjObcF0M3cHMIZJUWqlLTsu9K
	/7nSWWoXq38wo+oExFLKzPWl89cJ4vFZzs0nw3nLZnJu3Enzr/ED0zM3pTutSCeqCsf63/cwWmc
	RMr0O9EH6BCfkNygtBjH6GVzmzTHj2/MxA+9WIbVUtXw+w8XX3nkdy3ha3AuFg==
X-Google-Smtp-Source: AGHT+IEi54FRDA09xpigR8fBmxy++yrKfXoZAKuNTwFe6yFPlHHDvib0enEtS1Q8w+8FTcAWu4BfDg==
X-Received: by 2002:a17:907:6d06:b0:ad5:7732:675b with SMTP id a640c23a62f3a-ad5773276demr362003766b.40.1747679545947;
        Mon, 19 May 2025 11:32:25 -0700 (PDT)
Message-ID: <81c9f5f5-b5bb-4f3b-9993-dfca54f212c5@suse.com>
Date: Mon, 19 May 2025 20:32:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/16] xen/riscv: imsic_init() implementation
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
 <0d9a9a9e-3454-465f-ac1d-cd65ba4a5792@suse.com>
 <52c0be11-7c8e-4e12-9005-3a7ca7f12c43@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <52c0be11-7c8e-4e12-9005-3a7ca7f12c43@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 17:19, Oleksii Kurochko wrote:
> On 5/15/25 10:42 AM, Jan Beulich wrote:
>> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/imsic.h
>>> @@ -0,0 +1,65 @@
>>> +/* SPDX-License-Identifier: MIT */
>>> +
>>> +/*
>>> + * xen/arch/riscv/imsic.h
>>> + *
>>> + * RISC-V Incoming MSI Controller support
>>> + *
>>> + * (c) 2023 Microchip Technology Inc.
>>> + */
>>> +
>>> +#ifndef ASM__RISCV__IMSIC_H
>>> +#define ASM__RISCV__IMSIC_H
>>> +
>>> +#include 
>>> +
>>> +#define IMSIC_MMIO_PAGE_SHIFT   12
>>> +#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
>>> +
>>> +#define IMSIC_MIN_ID            63
>> This isn't the "minimum ID", but the "minimum permissible number of IDs" as per
>> its first use in imsic_parse_node(). Further uses there consider it a mask,
>> which makes me wonder whether the imsic_cfg.nr_ids field name is actually
>> correct: Isn't this the maximum valid ID rather than their count/number?
> 
> imsic_cfg.nr_ids it is a value of interrupt identities supported by IMSIC interrupt file according to
> DT binding:
>    riscv,num-ids:
>      $ref: /schemas/types.yaml#/definitions/uint32
>      minimum: 63
>      maximum: 2047
>      description:
>        Number of interrupt identities supported by IMSIC interrupt file.

Unless this count accounts for 0 being invalid (and hence isn't counted), I'm
still confused: With the maximum value this would mean 2046 is still valid,
but 2047 isn't anymore. When normally such a boundary would be at an exact
power of 2, i.e. between 2047 and 2048 here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 18:33:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 18:33:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990116.1374052 (Exim 4.92)
	(envelope-from )
	id 1uH5J4-00078G-Q9; Mon, 19 May 2025 18:33:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990116.1374052; Mon, 19 May 2025 18:33: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 1uH5J4-000789-LH; Mon, 19 May 2025 18:33:46 +0000
Received: by outflank-mailman (input) for mailman id 990116;
 Mon, 19 May 2025 18:33:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH5J2-000781-Sc
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 18:33:44 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ca885a25-34df-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 20:33:43 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5efe8d9ebdfso8639176a12.3
 for ; Mon, 19 May 2025 11:33:43 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac35e33sm6094828a12.60.2025.05.19.11.33.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 11:33: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" 
X-Inumbo-ID: ca885a25-34df-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747679622; x=1748284422; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=kZxwnH2sbaztQap8EHDBZ7HxwD0Q+CBtn0Lhd116yDo=;
        b=Ml/UOnk4/wSlxv78pBDMTuamn8gSZjNrZ2DEm3qOFOx8SFLcbxKbgjOmMRN1wGHXDK
         gC/idt0fwX0ScwyI2Dnfb1T8uUmb22Ol/9Pe0aPuI+vRLXD3a518h4gX0maB7LYrbIyh
         dAmm9IjTPWPRonV7RqWyl8KIp2YT2O5xI3wDy1W5awpRNHUJ4hW6hvCqZRU5hKkvWShE
         sEZqrAZkLOLP2UHmWuZ/5iAobawUbA9rwJ15Gzc0qgOUnxVNsv5KC2uOOh6XoL7MB/nQ
         qN7Rkwbgz+uhSn1hQxc8dS2GbxWY/H4A8ny1pOa6UE+4fpZS8KUYoKVXv3ra6Qs+yEqz
         oJYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747679622; x=1748284422;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=kZxwnH2sbaztQap8EHDBZ7HxwD0Q+CBtn0Lhd116yDo=;
        b=KcchPMOe0LVveiXOXea3GD2lNHyA4yb7n2FLTjjEOJkgLMpamSxGOVKEQUpHr7MFWd
         wkDHTp6RZxKljTTKEHxe11XpZ4gbG16150vbcPqNE+eiBIdROzLiz7iQugV5a5VKQQ/J
         eJ05jFHIbsEpWC02TP+c9c1PEZH+ibB/ark/yCkF8RJWvhY80FRm0bsEWp70eHRXWOTJ
         SBoXwSizuKlIEWN57Z19lc83J9low7MY6jj/tXFwDEMQlhbRCaS7QtYA/M0x19XFiTQg
         gNr3icRMu1eydJbrfppHjRWAmjuAbVh0rchIiehrGJ1g2JXO7EgzeWUN1HKV9l54Ya1H
         8lew==
X-Forwarded-Encrypted: i=1; AJvYcCVhlzAc1SwFrwaFONMIzD0YbTC9+yK9tWLUvOOUCPEkAb89yi7THyOHpNlAOOqGgRPGeWeltnqw+cI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzrayLrhJOePdgeiGJM8lqEJtFYOddEs8FGVxiCmJ5P/nlItxi7
	MOhJ4xCczAdew+TUsWlBUF6chJEcsV1/29AzUN3BeJ/d+ChL+ucMhOi0ZtHL95x7TA==
X-Gm-Gg: ASbGncu2tIGhaGfdg7LJBXGgbseUr6nz4xqySg1W8b4eing6Acew8gmSrFoDY7Jjd+0
	BAtn8c/9hRIszGMgrQE2frTWh3+quX1IsKa7Mlqj+EgYDwhX9+wRN43VeA2j6GazM7E9JrQDWl+
	2+QVS8ohX5RzLMOHKAm0WSzhva4llFF3nnc3FfiCkfKAGmmwDKL+AORb7Ffo/4JKLANY38PniGh
	fJOMNxeONR9eMAsbAdhErmhUjFONc0JhOkFPPeJELoIyhG4XixdEpfjhVyMHtChjHlNuITJKs9J
	cVvtlWJ8xShfblqJFhXH4DOnn5JKSlrXJvoi4FOtDCb+ISvCPy3/YG86lYKzaA==
X-Google-Smtp-Source: AGHT+IG89LkTyeaGHkrc8e+4+N16se0aYXB66uAcA7R5H0Qo+l2IZPi951RrrLVcihmsuwThJNuYNQ==
X-Received: by 2002:a05:6402:4410:b0:5f4:c5eb:50c9 with SMTP id 4fb4d7f45d1cf-60119cc8f77mr11797584a12.21.1747679622420;
        Mon, 19 May 2025 11:33:42 -0700 (PDT)
Message-ID: <2966ad6f-179f-47fe-acf1-7fb568cb4fb8@suse.com>
Date: Mon, 19 May 2025 20:33:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/16] xen/riscv: imsic_init() implementation
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
 <0d9a9a9e-3454-465f-ac1d-cd65ba4a5792@suse.com>
 <4b948489-6fb9-4554-9a4c-4fa75de7345d@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <4b948489-6fb9-4554-9a4c-4fa75de7345d@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 17:26, Oleksii Kurochko wrote:
> On 5/15/25 10:42 AM, Jan Beulich wrote:
>>> +                   node->name, imsic_cfg.msi[cpuid].base_addr + reloff);
>>> +            imsic_cfg.msi[cpuid].offset = 0;
>>> +            imsic_cfg.msi[cpuid].base_addr = 0;
>>> +            continue;
>>> +        }
>>> +
>>> +        bitmap_set(imsic_cfg.mmios[index].cpus, cpuid, 1);
>> Depending on clarification on the number space used, this may want to be
>> cpumask_set_cpu() instead. Else I think this is simply __set_bit().
> 
> cpumask_set_cpu() requires cpumask_t which uses static definition but we are
> using dynamic allocation.

But you're aware of cpumask_var_t (and respective allocation functions)?

Jan

> So it seems like bitmap_set() is the  best one option or reworking to static
> allocation will require.
> Am I missing something?
> 
> ~ Oleksii
> 
> 



From xen-devel-bounces@lists.xenproject.org Mon May 19 18:40:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 18:40:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990124.1374062 (Exim 4.92)
	(envelope-from )
	id 1uH5Pj-0000FP-EL; Mon, 19 May 2025 18:40:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990124.1374062; Mon, 19 May 2025 18:40: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 1uH5Pj-0000FI-A1; Mon, 19 May 2025 18:40:39 +0000
Received: by outflank-mailman (input) for mailman id 990124;
 Mon, 19 May 2025 18:40:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH5Pi-0000FC-TE
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 18:40:38 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c13794dd-34e0-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 20:40:36 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ad52d9be53cso552518866b.2
 for ; Mon, 19 May 2025 11:40:36 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4420ccsm613841166b.110.2025.05.19.11.40.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 11:40: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" 
X-Inumbo-ID: c13794dd-34e0-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747680036; x=1748284836; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=3xJLKoGisEzELgLALhj8HI3qbKme4jRSwTX+rgaoSko=;
        b=Mjg4T1ZO/WxHOyJBdaefXvNqLgeTYqOzNB2OSmGaWP5+Z61hnrMxpweqQjfNfI0s2i
         0+euP0kEwsvlNhhyr+qZWqIb7t2CjRT+LCKNEivRffeihrktgs2Bchw8yesIUaaFAn5X
         sQlyzGHKeJ0fmIelWN6RR8pw1qy9WIYwPRFVSQndCx7+K2by/ziNxLq618QJ50z90SHO
         axFQ/utlz7v+QpZRuY30UXx+r3VRwh61Ff9ibnulohL+ahHg8Ocgl45GgdMmOzA2NYOX
         g63qksuEUucR7uM2deyKgqn04bxcY7uPDVzYd+gd+/f+m16qUVCKwPzDArbdq+4NwJYy
         02wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747680036; x=1748284836;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3xJLKoGisEzELgLALhj8HI3qbKme4jRSwTX+rgaoSko=;
        b=mbc4w2IqkiNdDE9mrohQqPtZAsTrBb+cTs9k1bN2i/gRygpqXklFHGKmOQdR2+DBrs
         KPiKSdBIGS/E5Bh88nWyvbK7E9nFOsw9JDHfl7opinQcr9klN7RJ5G476lfTBYzuIpSC
         Jd4kF6hDwLTHy7j8KE+YFmovbc5Ru0mwnXWshwFSKbJ3u26k5CLoW1JVdJ908WPxbLgY
         2HGSnEwCDleOSHKUwC9xOIwEtqsbM7zOVDANqexZyxQidT3WLTmr0FEZOBzndlreV5rs
         Q57hxaTVCwfUINzYb13dUmUX3cDf1L0jFItEBSnIXSmZ7uzo04IVrJ525G0Y6mWKyUxB
         rbGg==
X-Forwarded-Encrypted: i=1; AJvYcCXnMbTOk4vnRHcvWjDYHFBYoI49KKe7GGzbhFdQvqNTzt+Y+qnh6xBGIBYQofs9u+lJo23P9CCu624=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwT/+bXPGtxsM1mimXe05O/B0YUitBG8REDOMRyc/o926G/8y80
	ev9sbID6QLGxEPga+pj1dES8Oba83lw6jOJH4gVbL3o21aGgFPXcSN8fUKFnEgHQsw==
X-Gm-Gg: ASbGncu8/Uyzis/xSTjNHDZ/WZME+N0hUImRKF+TZopznBsMyjXD3/onig8DaWbKcAT
	ZoHqBN3udWWh93gYZ6Ev2WgQyv4PE1CoIipHwXBK1ysCRXrn7qWKNOVsE7QK02MvkUKgiGwRiyd
	3pxAOBlyCzdipkdWBSY6GcWduqpZy2A6Fo2YBQpXiI9HZp9y52R+4r3IywclfH3Ns7loMS9XI9h
	UXvk1pBoeN1xmDlW5DxuWhx+sJC8JF98YxVcxt/EN9mXflrMOtAZpDEh3kp8mWV+uObe/Pkx75g
	+9SZRk5Tgma0pYqQcrulZhFM1hYOAdYkqxiOCsC8GCZxZ0mxHS0g9iLi5Vh27A==
X-Google-Smtp-Source: AGHT+IGaO5fvSDcdAOiqOQbSnPbQ3zTZunvU9ndj4O35x2M3xY7XO7mO1SE9trOWDqbEO3532zdqtg==
X-Received: by 2002:a17:906:c28d:b0:ad5:3648:e2e4 with SMTP id a640c23a62f3a-ad53648eab0mr955935666b.45.1747680036286;
        Mon, 19 May 2025 11:40:36 -0700 (PDT)
Message-ID: <1b012912-c90e-45ad-8411-a4ddc4b2c3dc@suse.com>
Date: Mon, 19 May 2025 20:40:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 11/16] xen/riscv: aplic_init() implementation
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <9129b10432dfc7ff8ba451842204342171da7dc1.1746530883.git.oleksii.kurochko@gmail.com>
 <057fc2ce-d4d6-4e14-987d-bef6f909eaff@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 18:09, Oleksii Kurochko wrote:
> On 5/15/25 11:06 AM, Jan Beulich wrote:
>>> +    /* Set interrupt type and default priority for all interrupts */
>>> +    for ( i = 1; i <= aplic_info.num_irqs; i++ )
>>> +    {
>>> +        writel(0, &aplic.regs->sourcecfg[i - 1]);
>> What guarantees the loop to not run past the array's size?
> 
> riscv,aplic binding:
>    https://github.com/torvalds/linux/blob/a5806cd506af5a7c19bcd596e4708b5c464bfd21/Documentation/devicetree/bindings/interrupt-controller/riscv%2Caplic.yaml#L57
> Should I add an ASSERT() or panic() at the moment where num_irqs are
> initialized to double check a binding?

I may be paranoid, but I don't really trust anything coming from DT. Hence
yes, just like you do in various other situations, perhaps best to panic()
if too large a value is read. Or, if that's feasible, simply cap at the
compiled-in count.

>>> +static int __init cf_check aplic_init(void)
>>> +{
>>> +    int rc;
>>> +    dt_phandle imsic_phandle;
>>> +    uint32_t irq_range[num_possible_cpus() * 2];
>> Are you going to have enough stack space when num_possible_cpus() is pretty
>> large?
> 
> When num_possible_cpus() will be pretty large then it will better to allocate irq_range[]
> dynamically.
> 
> Does it make sense to re-write now?

Well, this kind of runtime-sized stack allocation should go away anyway.
Plus you don't want to leave a trap like this in the code. Whether using
dynamic allocation is the choice to address those concerns you'll need
to judge.

>>> +    const struct dt_device_node *node = aplic_info.node;
>>> +
>>> +    /* Check for associated imsic node */
>>> +    rc = dt_property_read_u32(node, "msi-parent", &imsic_phandle);
>>> +    if ( !rc )
>>> +        panic("%s: IDC mode not supported\n", node->full_name);
>>> +
>>> +    imsic_node = dt_find_node_by_phandle(imsic_phandle);
>>> +    if ( !imsic_node )
>>> +        panic("%s: unable to find IMSIC node\n", node->full_name);
>>> +
>>> +    rc = dt_property_read_u32_array(imsic_node, "interrupts-extended",
>>> +                                    irq_range, ARRAY_SIZE(irq_range));
>>> +    if ( rc )
>>> +        panic("%s: unable to find interrupt-extended in %s node\n",
>>> +              __func__, imsic_node->full_name);
>>> +
>>> +    if ( irq_range[1] == IRQ_M_EXT )
>> How do you know the array has had 2 or ...
>>
>>> +        /* Machine mode imsic node, ignore this aplic node */
>>> +        return 0;
>>> +
>>> +    for ( unsigned int i = 0; i < ARRAY_SIZE(irq_range); i += 2 )
>>> +    {
>>> +        if ( irq_range[i + 1] != irq_range[1] )
>>> +            panic("%s: mode[%d] != %d\n", __func__, i + 1, irq_range[1]);
>>> +    }
>> ... or even all of the slots populated? Anything not populated by the DT
>> function will still have the stack contents that had been left by earlier
>> call chains. (The loop also makes little sense to start from 0.)
> 
> Do you mean I asked allocated irq_range[8*2] but DT node has only irq_range[4*2]?
> Then it will be really an issue. And out-of-range access will occur in
> dt_property_read_variable_u32_array(). I need another way to check then...

I described the opposite situation (not the full array being populated),
but yes - both are a problem.

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 18:55:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 18:55:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990135.1374071 (Exim 4.92)
	(envelope-from )
	id 1uH5db-0002Cx-K9; Mon, 19 May 2025 18:54:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990135.1374071; Mon, 19 May 2025 18: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 1uH5db-0002Cq-GP; Mon, 19 May 2025 18:54:59 +0000
Received: by outflank-mailman (input) for mailman id 990135;
 Mon, 19 May 2025 18:54:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH5da-0002Cj-1o
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 18:54:58 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c18fdbd5-34e2-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 20:54:56 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-601f278369bso2552657a12.1
 for ; Mon, 19 May 2025 11:54:56 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ae39995sm6076089a12.72.2025.05.19.11.54.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 11:54: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" 
X-Inumbo-ID: c18fdbd5-34e2-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747680896; x=1748285696; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=5PK03mMqj/0S146CdDeFCztdaufZ9Ig4GSYXkx7uJko=;
        b=SUgr68ZmQyHaXdEaR+8yUiFOAfnBzJ+1zQzLkQB9X607kC0VCq2Y0TDjfHkvDCPqdX
         saxOB6uJ0RosAATHDiqjLgMAr+P44W1xlJMWkaTr/JkRoUvT7RR8iVIUkn9uGgPa6W1N
         qr8h9Y3J/Kc1ARkFoXDSYaiKeOy11gI3kaGv++KslyEdmvUQsgf+sUW1fUprASPD5a1f
         w4ZEjagQQNsQFw6u9KSRaW7JBY7jcf0lluaEWTewL2RGMbptTphfI2mb6BTQOq7zAT/u
         JJAyXdwJ/YfMDyNbhUOd+Q1f7Dl/OqOabugIgJI8r14AM3Ake6hiktjg8sDXk7l5MY0Z
         IeHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747680896; x=1748285696;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=5PK03mMqj/0S146CdDeFCztdaufZ9Ig4GSYXkx7uJko=;
        b=i0muksvN160qoOxOVwVL/tah0DffBWhIxndah99h+vYEBQoK2/jsilw7O0t71mdQCh
         mf6r8lh6ibnLDnElVY5jli/7VLTEGMBsi0PrzQ7ESvlAQ0/EbTzdp1rELbgvARY5fdi0
         LYtIRVhX+UMSqD8ktZWvuMuNEcte3qyisdZErElEYoImhML1yXpz6uMYEQLZeSAwTBmv
         b+g7PqfFww8gPNgT2PzgrwTfoPfajTVD+7qJT39Dz+jcYApso0bvS6KnstFbnk3r6ufq
         cHXGkSY+LTSKqAO/MFtebQyfftSWTP0LFMqh8/booCHCmClb0x0gp62xmdsI2qmESbP2
         xgOg==
X-Forwarded-Encrypted: i=1; AJvYcCWFnFaxOMVXqu1JQh/ogpZ6KT5fbG7PqFBrXPsJIbQrG25qHFtw79EgCbe6lQE8vQ0u+07ApDtLzoE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywl9Tejd8uiN+Cwb83wNnfBn7tVyae09rAq8PXG8zCN50yrfdlA
	zL4W6S8kJHcubI0q5Sxn+yJ38Zy800F1eydjrtFFRvWznrBHr44Pwb3/On5Fq+wTXQ==
X-Gm-Gg: ASbGncsLt/zGQHbc70KxSsPjN21DUNK/LpNgVNwr2tZmBXl00jJ48UdSgRyFct8IMwj
	LvWglCCF2rYkLEd/bh6cdVU1v147BO8VKBa0Q4AaipLKr3Zj6emmx5W8eN7k9XECmpzO01Bw4Td
	G3I2SDqptlopt4xIZrt6rcfNc9K+AHgzxYGglUyBSpo/uzVhQ8c7VrCV9FZyR43XvMxiLj6WIrz
	nIqGkmLJipeL500hNnR1TGiLtLFgtlfHvTVEbBY+X22Q1CUaDdXT8XSfK4qeDfFYiP6cvDSQeXg
	+DeLppgw8lf5RfyJ3K9wlUsJ5jWX8b/rW72NBg/ZbU9dQZOOLyCD3JREmcKcQQ==
X-Google-Smtp-Source: AGHT+IEOH7PUbOGQklXTnyGpdk04LH6cpNxSVHy3Eo28Zz5LxPUOR3xodbp2FNIkRQ4lyryKbTNXeQ==
X-Received: by 2002:a05:6402:5216:b0:5fc:954e:efb6 with SMTP id 4fb4d7f45d1cf-6008a39230dmr12211691a12.6.1747680895814;
        Mon, 19 May 2025 11:54:55 -0700 (PDT)
Message-ID: <092559d7-ddfd-44f2-9854-779770e24b8a@suse.com>
Date: Mon, 19 May 2025 20:54:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
To: Oleksii Moisieiev ,
 Grygorii Strashko 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Juergen Gross
 , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Volodymyr Babchuk ,
 "xen-devel@lists.xenproject.org" 
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 17:50, Oleksii Moisieiev wrote:
> --- a/xen/arch/arm/firmware/sci.c
> +++ b/xen/arch/arm/firmware/sci.c
> @@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
>      return 0;
>  }
>  
> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> +{
> +    struct dt_device_node *dev;
> +    int ret = 0;
> +
> +    switch ( domctl->cmd )
> +    {
> +    case XEN_DOMCTL_assign_device:
> +        ret = -EOPNOTSUPP;
> +        if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT )
> +            break;
> +
> +        if ( !cur_mediator )
> +            break;
> +
> +        if ( !cur_mediator->assign_dt_device )
> +            break;
> +
> +        ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
> +                                    domctl->u.assign_device.u.dt.size, &dev);
> +        if ( ret )
> +            return ret;
> +
> +        ret = sci_assign_dt_device(d, dev);
> +        if ( ret )
> +            break;

These two lines are pointless when directly followed by ...

> +
> +        break;

... this. Misra calls such "dead code" iirc.

> --- a/xen/arch/arm/include/asm/firmware/sci.h
> +++ b/xen/arch/arm/include/asm/firmware/sci.h
> @@ -146,6 +146,14 @@ int sci_dt_finalize(struct domain *d, void *fdt);
>   * control" functionality.
>   */
>  int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev);
> +
> +/*
> + * SCI domctl handler
> + *
> + * Only XEN_DOMCTL_assign_device is handled for now.
> + */
> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
>  #else
>  
>  static inline bool sci_domain_is_enabled(struct domain *d)
> @@ -195,6 +203,12 @@ static inline int sci_assign_dt_device(struct domain *d,
>      return 0;
>  }
>  
> +static inline int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
> +                                XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> +{
> +    return 0;
> +}
> +
>  #endif /* CONFIG_ARM_SCI */
>  
>  #endif /* __ASM_ARM_SCI_H */

This being an Arm-specific header, how does ...

> @@ -851,6 +852,24 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>      case XEN_DOMCTL_deassign_device:
>      case XEN_DOMCTL_get_device_group:
>          ret = iommu_do_domctl(op, d, u_domctl);
> +
> +        if ( !ret || ret == -EOPNOTSUPP )
> +        {
> +            int ret1;
> +            /*
> +             * Add chained handling of assigned DT devices to support
> +             * access-controller functionality through SCI framework, so
> +             * DT device assign request can be passed to FW for processing and
> +             * enabling VM access to requested device.
> +             * The access-controller DT device processing is chained after IOMMU
> +             * processing and expected to be executed for any DT device
> +             * regardless if DT device is protected by IOMMU or not (or IOMMU
> +             * is disabled).
> +             */
> +            ret1 = sci_do_domctl(op, d, u_domctl);

... this compile on non-Arm? I think I said so before: I don't like this
sitting in common code anyway. Is there really no way to put it in Arm-
specific code?

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 19:11:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:11:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990146.1374081 (Exim 4.92)
	(envelope-from )
	id 1uH5sy-0004yw-TD; Mon, 19 May 2025 19:10:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990146.1374081; Mon, 19 May 2025 19:10: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 1uH5sy-0004yp-Pp; Mon, 19 May 2025 19:10:52 +0000
Received: by outflank-mailman (input) for mailman id 990146;
 Mon, 19 May 2025 19:10:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH5sy-0004yj-0n
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:10:52 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa7eb413-34e4-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 21:10:50 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad53cd163d9so551487266b.0
 for ; Mon, 19 May 2025 12:10:50 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d490789sm628733566b.130.2025.05.19.12.10.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 12:10: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" 
X-Inumbo-ID: fa7eb413-34e4-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747681850; x=1748286650; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=R/wD01PMybT2LQnhKga9JH5u3GQCYLAHtw5OWeAnBH4=;
        b=LQu7lI1aJcLYCg5mgeZ8iYzjRI+WseYirJtIf+ln1cuhxAE+wlrnRePYQZF+cnvp0I
         btNIKl91cQesTAz/Kv5qPWIVGTmgm+x9Oy4NkFkuN+s+0Kvzdwm+eMpWM8tsHYQf89fW
         rd+ShDVhbO5PReuSJQmbELonBaxQUQcB2EfK8dbLpq7Cootj7qPh1hxTizFOF7xZzrNk
         WrMF4zfg6WYZLr+wdlTXkqmleO85BijgSHa6297pF9ueVqA7zqnQxsAOEzJCa9MrdMCu
         y4l1EKhOQr54EmGhjg7NdKTT9gotOBYjslWy0Caeyu9+nkXXQFa1c6kItLjoFjrg6zfU
         oOwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747681850; x=1748286650;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=R/wD01PMybT2LQnhKga9JH5u3GQCYLAHtw5OWeAnBH4=;
        b=N2Tc1AoYjoPjiQowEnvym8oMbveD+VnUTVB5hfwairZ7RuJSk7OPSHYHCpkc77ulnT
         3ooerzKzlHq+i4k6Wwujzuvwmu0lHUXczBAXPVEvCGMIfmNv4DaA0maNP2SozbfpkTeo
         MsOm1y+qkSl9yzYnQN/Y3hS2O1HTZBX1M1Yy0m2l2flh9j3EoJdGezDDMrAnc1HY0xZY
         s2DrE1t5aircN6jqFKC8iBOzfaxc+k3EPwJMufDQr+eIeISc7GNZ48VQqBBpxYQb9/by
         /hp2WHOzkMyvqXC+lVVkGoLLs5iRCd0QpuJzBoi1+SX5UoTSHRCOAXSwENgo8qaMbvih
         O1Yg==
X-Forwarded-Encrypted: i=1; AJvYcCUiUBdnx0sEtIrKLyyswa+HphjFaW11LbhziMTjYTVYdiGYYjSgmVcQHyoVVk1FAokoeQwO8eYAhSU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz3aGom9ZjiaPpPD0sy6MeOfS3frIajFOtJjT6jzv0yuetJkOBm
	9LluIRU17v5f9Nhm7JI4acP/nAStEF0+i3l0jDFjAteWjRgbcZTcQWCdfPbsbpeNrg==
X-Gm-Gg: ASbGncvuPnjpUXiq4yFFCpAvCeXP38EhDlGkwsPGh3F+wJCzDrJlzOd5bPz248RdfRx
	lU7t6s4tlwCuKk0WvONC+tBPZfrPt9SGQGDWurCkM6uPhyA+voihTkl3THc8TaTCMnyROAxmUEv
	e2wLBIIqIRxVhoS63dfUGaM+ltp35Qy8aabnkGD7QlmttWofVg8FAcNVfAXapLHM671Vym+l51h
	qW/TQ6zGkc1C/M7cKFj7zWdnu9X2xDF9l3rarjcYH8+vQJaenp5uJOE1Salha7P9L4xlrbw2C2D
	DGqEscLpo2u+8K7ew85lX0d67pzMeERM1jnGkuPqxMmeiNyOqek2qq6o4TfsVw==
X-Google-Smtp-Source: AGHT+IFPNcA5rBMSQP1zWY2N+HkTWpXl/YTmKwrOvnW7ZGrZkvs1h6LeQwVibg/pOTPxJrFVuYK6xQ==
X-Received: by 2002:a17:907:980d:b0:ad2:4736:9c07 with SMTP id a640c23a62f3a-ad52d42bf01mr1342163066b.2.1747681850436;
        Mon, 19 May 2025 12:10:50 -0700 (PDT)
Message-ID: 
Date: Mon, 19 May 2025 21:10:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Give compile.h header guards
To: Andrew Cooper 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Xen-devel 
References: <20250519135227.27386-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250519135227.27386-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 15:52, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper 

Is this to please Misra in some way?

> --- a/xen/include/xen/compile.h.in
> +++ b/xen/include/xen/compile.h.in
> @@ -1,3 +1,6 @@
> +#ifndef XEN_COMPILE_H
> +#define XEN_COMPILE_H
> +
>  #define XEN_COMPILE_DATE	"@@date@@"
>  #define XEN_COMPILE_TIME	"@@time@@"
>  #define XEN_COMPILE_BY		"@@whoami@@"
> --- a/xen/tools/process-banner.sed
> +++ b/xen/tools/process-banner.sed
> @@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
>  
>  # Trailing \ on all but the final line.
>  $!s_$_ \\_
> +
> +# Append closing header guard
> +$a\
> +\
> +#endif /* XEN_COMPILE_H */

This split of #ifndef and #endif is ugly. Can't we switch to something
more conventional, like

#define XEN_BANNER		"@@banner@@"

with the first sed invocation then replacing this by the result of
a nested sed invocation using process-banner.sed (which of course would
need adjusting some)? (Maybe the double quotes would need omitting here,
for process-banner.sed to uniformly apply them.)

Jan


From xen-devel-bounces@lists.xenproject.org Mon May 19 19:21:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:21:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990163.1374092 (Exim 4.92)
	(envelope-from )
	id 1uH62p-0006rt-Ux; Mon, 19 May 2025 19:21:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990163.1374092; Mon, 19 May 2025 19: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 1uH62p-0006rm-RE; Mon, 19 May 2025 19:21:03 +0000
Received: by outflank-mailman (input) for mailman id 990163;
 Mon, 19 May 2025 19:21:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH62n-0006rg-7y
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:21:01 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 64e61f17-34e6-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 21:20:59 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 387B34EE7C60;
 Mon, 19 May 2025 21:20: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" 
X-Inumbo-ID: 64e61f17-34e6-11f0-a2fa-13f23c93f187
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=1747682458;
	b=heaalXsJ9UfQQr5H/jbcKatMFe6jTX/cHGBLteC4EvW51Eim3b/E0UhExc7BnV94idiQ
	 xYxRiOtEX3c6Pf02P/dQ24W3I/KmxZlGRorIOR5Su0XMVDZJSVEQuvwQyvLNdW2arc9qv
	 WDcwxFP7d+RKK4GhlHRNxR0EQ+4/PgwPJWObAb3hB58IvkX7RtfXp89yPvkXWeYrtL5Qb
	 6mJqRwBkA54YsSb2iwFjQREJJHKE8wnNCyLT4BsXEZsQkjLGNucOF/IAwmqU4hWNPvAn8
	 IhXLk909BJiGFkS9mhDfPty+psDXFaBa1jxDRH0aqd67tPyTllSshfQj5DFg8SlTiPAu5
	 K82+Gh0kNpfvd6I9Pm9yVFRPu93QXGMsabam8BUgjTOkgAjTMK3/PRa3J40b6inZdsGyS
	 dNvJjRNhr6sLrj8+rTZThutTYmrYYHiipCyOastFAf5EYNvaW8dEmM2Ydiecxh11OWWNh
	 2U3A4g4PZggiUorJyGSzwAjWS+b7jT/vfjk6WLsM8/LecEOn0PiqH6K2l2hLILOXTH3Cq
	 utdboPds4kmKLtnsKT2ghl5RGAsxMQN7cePlI5YCPSMi13mDc7C3UncTnwtwtsLxQbeKi
	 KwsRXHY2B205N5f2qZmAyAhEO42O6CYPsw+5TeEAJlduUDe+R13OYvN2rE/1yhE=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1747682458;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=zxRF2dssG7vSmsDLWc8ihjORk55Chb9jxYYjVkZFTYc=;
	b=d40S1y421z+dxdoW7irVCO7pPP2JXCzT8ZwSNJjq9FVjejh5C/pN5+wLaWqxozaahCnf
	 z2AdOUhonZ+BA4c92tWz9OE7ijsnssV4+n3gy2ofpgvPHhSh0VEo6bWc+/sz19bUdF3pc
	 FGQqi0JQqLQ9eBd2Q9fKp9ENQvpqj32qRcJ6MSPe1o0Abqk0BsFG2VdvBJmXy2il0LNtx
	 T7qgAZn5QEh1wqjwRU8nEpu5tpyyZq8z3JdlySXOGx6M13daJ+G1sFbHF7yoYpO74V0UE
	 xiLT9XQu9xbJNvny5r0hFB2Yi0A8zH2/BFeKKYWLT77LXawOEW8J1Raw41xxoTlfa9+FZ
	 uDnqBSJQfBpNnJsxWf+NTCYsFCAFVOYC8MRR/RwUFiY5buHrWnr1fjiU3DunKENooQJsk
	 ASd3tc+OWLmYDknEX+FiwbEcK9ysFlHrLuvdFGG5F4ndPDp+VYyvTZqOVgZpgPV74yh2r
	 YbxrPIMF7hCV4ZxRoEAlrGHlc4ojcINF1bs1Jbid/DMtGvgM1PAryyrBluiFa2DGoxwNr
	 TaEFJ0qKTss2GDBTch05+J7lNBEOAg9YlZr2WBf5Alp4/tFbYJ1vGCs7crMY5d0y4mUzG
	 6+o3+aiL3AaQVXNHo8bmCpXWDLHClD1S7LGi1t7CNK4ZZOgUkF1CGNnDH//E3js=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1747682458; bh=CTFzUztmBHn/M1AXC5FXNL6nWy78MIe54bI+jmcxygo=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=jtwieQFtS3Tpyttp5jgYDRxYydd8gWmL1Qdw8ow1EHmf20kzMeCOCx6CyLCB0cC3A
	 nuYMdV4Mg7Ko8JvnWmDxynWwrC2payr9oIZv7P2M94JYzw/CEQ6hIEPokwj+Fkxugm
	 CItgBfcNv6/jx6tTL4izmUx43adnapXXki+Y4qnD4GT5OoPXlcdr+CucvXPlXbjmDN
	 Wi9+Bt3xMcWkd1Rfx8pg7GjpBhE2bGpKc24Lk3W2iID7I1gaejHsNGi4xwFpaXT4NG
	 HESTUpoZjeeQIt7uYbGr8JoeeLFfUT4xLCT1i262d7tf8+QCF9vXsTLp2msG4VvSM9
	 PiQah4vwQymzg==
MIME-Version: 1.0
Date: Mon, 19 May 2025 21:20:58 +0200
From: Nicola Vetrini 
To: Jan Beulich 
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: Give compile.h header guards
In-Reply-To: 
References: <20250519135227.27386-1-andrew.cooper3@citrix.com>
 
Message-ID: <945af229127e3d6dc578f0ae23059686@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

On 2025-05-19 21:10, Jan Beulich wrote:
> On 19.05.2025 15:52, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper 
> 
> Is this to please Misra in some way?
> 

Directive 4.10: "Precautions shall be taken in order to prevent the 
contents of a header file being included more than once". One approach 
is to special-case this file, but Andrew suggested this approach which 
addresses the issue directly.

>> --- a/xen/include/xen/compile.h.in
>> +++ b/xen/include/xen/compile.h.in
>> @@ -1,3 +1,6 @@
>> +#ifndef XEN_COMPILE_H
>> +#define XEN_COMPILE_H
>> +
>>  #define XEN_COMPILE_DATE	"@@date@@"
>>  #define XEN_COMPILE_TIME	"@@time@@"
>>  #define XEN_COMPILE_BY		"@@whoami@@"
>> --- a/xen/tools/process-banner.sed
>> +++ b/xen/tools/process-banner.sed
>> @@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
>> 
>>  # Trailing \ on all but the final line.
>>  $!s_$_ \\_
>> +
>> +# Append closing header guard
>> +$a\
>> +\
>> +#endif /* XEN_COMPILE_H */
> 
> This split of #ifndef and #endif is ugly. Can't we switch to something
> more conventional, like
> 
> #define XEN_BANNER		"@@banner@@"
> 
> with the first sed invocation then replacing this by the result of
> a nested sed invocation using process-banner.sed (which of course would
> need adjusting some)? (Maybe the double quotes would need omitting 
> here,
> for process-banner.sed to uniformly apply them.)
> 
> 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 Mon May 19 19:23:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:23:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990169.1374101 (Exim 4.92)
	(envelope-from )
	id 1uH65D-0007NW-95; Mon, 19 May 2025 19:23:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990169.1374101; Mon, 19 May 2025 19:23:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH65D-0007NP-5w; Mon, 19 May 2025 19:23:31 +0000
Received: by outflank-mailman (input) for mailman id 990169;
 Mon, 19 May 2025 19:23:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH65B-0007ND-1W
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:23:29 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bc383cfc-34e6-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 21:23: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" 
X-Inumbo-ID: bc383cfc-34e6-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747682604; x=1747941804;
	bh=V7zaVKx0lwtMA+mwrVVONifnlxJ+3PzeD6PCowI19tY=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=RjdXVL9osbT6lcXF3utVxGkdEcPFttz1P/SBgicO+Fa4+bwbckByN46WpJ5tL3fA/
	 CpECjNs7X0DjGaFgl4y5LOr0TGoIt8+KxxbcHjhV7GHn1lbeI9U839awT7xeZvNafG
	 /ch9vrqhxYy5rCncP4zpF/JltlGIFHZRcVeDqhIkGoUevwG9yEoVrnfB9+D4y3lUdc
	 +18SUlhH5rzuhIa4FdTu1HV4luBMsG09sG/aghz72lPny5nfx9FtHdlfjtQb+zJEln
	 klBoPaS3skG/gbbMJHWvk8cj0Jk9YpWZw5ov/kPOFEA8rsPVtC/rRDTBlE/kThYJGT
	 rUf3nHIgQU66w==
Date: Mon, 19 May 2025 19:23:17 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v7 0/3] xen/domain: domain ID allocation
Message-ID: <20250519192306.1364471-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 876f14d5bc9ffab4313313cae61d9dea1005bd0f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The patch series adds new library calls for allocating domain IDs.

Patch 1 introduces new domid_{alloc,free} calls.
Patch 2 adjusts hardware domain ID treatment on Arm.
Patch 3 introduces new CONFIG_MAX_DOMID parameter to limit the number of
domains during run-time.

Link to v6: https://lore.kernel.org/xen-devel/20250516020434.1145337-1-dmuk=
hin@ford.com/
Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1=
825273124

Denis Mukhin (3):
  xen/domain: unify domain ID allocation
  xen/domain: adjust domain ID allocation for Arm
  xen/domain: introduce CONFIG_MAX_DOMID

 xen/arch/arm/domain_build.c             | 17 ++++---
 xen/arch/arm/tee/ffa.c                  |  3 +-
 xen/arch/x86/cpu/mcheck/mce.c           |  2 +-
 xen/arch/x86/cpu/vpmu.c                 |  2 +-
 xen/arch/x86/setup.c                    | 11 +++--
 xen/common/Kconfig                      |  7 +++
 xen/common/device-tree/dom0less-build.c | 17 ++++---
 xen/common/domain.c                     | 59 +++++++++++++++++++++++--
 xen/common/domctl.c                     | 42 +++---------------
 xen/common/sched/core.c                 |  4 +-
 xen/drivers/passthrough/vtd/iommu.c     |  2 +-
 xen/include/public/domctl.h             |  2 +-
 xen/include/xen/domain.h                |  3 ++
 13 files changed, 106 insertions(+), 65 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 19:23:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:23:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990170.1374111 (Exim 4.92)
	(envelope-from )
	id 1uH65J-0007de-EJ; Mon, 19 May 2025 19:23:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990170.1374111; Mon, 19 May 2025 19:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH65J-0007dX-Bf; Mon, 19 May 2025 19:23:37 +0000
Received: by outflank-mailman (input) for mailman id 990170;
 Mon, 19 May 2025 19:23:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH65I-0007ND-GG
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:23:36 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c1bb89ce-34e6-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 21:23: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" 
X-Inumbo-ID: c1bb89ce-34e6-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747682612; x=1747941812;
	bh=rQWgIHLHmbS0TIalS6R8fgsHrwCunvDl9aKdr7mtmX4=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=DsN+YQjTk0OmHjHQpuk65cI+tQ3DTParuSUFcbTqTNdHrPIScEP2lYA/0IqHn/cCI
	 R7xTxrBpbl61BDjHVt3vSOYTqL09vD656bg5Vb5yGLfcx+YvHhLHVDFiZHEwPZcBzr
	 gXLSuv32V3OU4dcYmbq/OPbvy4wgNbTuuQbGD3IG66+Mh1qlG8tMwN8dC6CBISOvpG
	 VmhZRZzx6n9s8GCK1VEHa8IoHJIItQsNRt03RiCEWwz541qtoIXL5V/Hv23h5DDFOJ
	 NmRhEkyYqOmo94szAzNR5Quq0jLtbwtUHF0iNp6QnCbDmYJuOrcjfb9A18xUXPLqoN
	 VtjBsXP/bzdbA==
Date: Mon, 19 May 2025 19:23:27 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v7 1/3] xen/domain: unify domain ID allocation
Message-ID: <20250519192306.1364471-2-dmukhin@ford.com>
In-Reply-To: <20250519192306.1364471-1-dmukhin@ford.com>
References: <20250519192306.1364471-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 56997b8d44c109755c76eb5c07309375e52417ec
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Currently, hypervisor code has two different non-system domain ID allocatio=
n
implementations:

  (a) Sequential IDs allocation in dom0less Arm code based on max_init_domi=
d;

  (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
      max_init_domid (both Arm and x86).

It makes sense to have a common helper code for such task across architectu=
res
(Arm and x86) and between dom0less / toolstack domU allocation.

Wrap the domain ID allocation as an arch-independent function domid_alloc()=
 in
common/domain.c based on the bitmap.

Allocation algorithm:
- If an explicit domain ID is provided, verify its availability and use it =
if
  ID is not used;
- If DOMID_INVALID is provided, perform an exhaustive search within
  [0..CONFIG_MAX_DOMID-1] range, starting from the last used domain ID.
  domid_alloc() guarantees that two subsequent calls will result in differe=
nt
  IDs allocation.

Also, remove is_free_domid() helper as it is not needed now.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- reworked to bitmap
- dropped incorrect uses of ASSERT()
- fixed XEN_DOMCTL_createdomain to call domid_free() in case of unsuccessfu=
l ID
  allocation
---
 xen/arch/arm/domain_build.c             | 17 ++++++---
 xen/arch/x86/setup.c                    | 11 +++---
 xen/common/device-tree/dom0less-build.c | 10 +++---
 xen/common/domain.c                     | 48 +++++++++++++++++++++++++
 xen/common/domctl.c                     | 42 +++-------------------
 xen/include/xen/domain.h                |  3 ++
 6 files changed, 81 insertions(+), 50 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..e9d563c269 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2010,6 +2010,7 @@ void __init create_dom0(void)
         .grant_opts =3D XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
     };
     unsigned int flags =3D CDF_privileged | CDF_hardware;
+    domid_t domid;
     int rc;
=20
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
@@ -2034,19 +2035,25 @@ void __init create_dom0(void)
     if ( !llc_coloring_enabled )
         flags |=3D CDF_directmap;
=20
-    dom0 =3D domain_create(0, &dom0_cfg, flags);
+    domid =3D domid_alloc(0);
+    if ( domid =3D=3D DOMID_INVALID )
+        panic("Error allocating domain ID 0\n");
+
+    dom0 =3D domain_create(domid, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
-        panic("Error creating domain 0 (rc =3D %ld)\n", PTR_ERR(dom0));
+        panic("Error creating domain %d (rc =3D %ld)\n", domid, PTR_ERR(do=
m0));
=20
     if ( llc_coloring_enabled && (rc =3D dom0_set_llc_colors(dom0)) )
-        panic("Error initializing LLC coloring for domain 0 (rc =3D %d)\n"=
, rc);
+        panic("Error initializing LLC coloring for domain %pd (rc =3D %d)\=
n",
+              dom0, rc);
=20
     if ( alloc_dom0_vcpu0(dom0) =3D=3D NULL )
-        panic("Error creating domain 0 vcpu0\n");
+        panic("Error creating domain %pdv0\n", dom0);
=20
     rc =3D construct_dom0(dom0);
     if ( rc )
-        panic("Could not set up DOM0 guest OS (rc =3D %d)\n", rc);
+        panic("Could not set up guest OS for domain %pd (rc =3D %d)\n",
+              dom0, rc);
=20
     set_xs_domain(dom0);
 }
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2518954124..ac1c3e669b 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1030,8 +1030,11 @@ static struct domain *__init create_dom0(struct boot=
_info *bi)
     if ( iommu_enabled )
         dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu;
=20
-    /* Create initial domain.  Not d0 for pvshim. */
-    bd->domid =3D get_initial_domain_id();
+    /* Allocate initial domain ID. Not d0 for pvshim. */
+    bd->domid =3D domid_alloc(get_initial_domain_id());
+    if ( bd->domid =3D=3D DOMID_INVALID )
+        panic("Error allocating domain ID %d\n", get_initial_domain_id());
+
     d =3D domain_create(bd->domid, &dom0_cfg,
                       pv_shim ? 0 : CDF_privileged | CDF_hardware);
     if ( IS_ERR(d) )
@@ -1063,7 +1066,7 @@ static struct domain *__init create_dom0(struct boot_=
info *bi)
=20
         if ( (strlen(acpi_param) =3D=3D 0) && acpi_disabled )
         {
-            printk("ACPI is disabled, notifying Domain 0 (acpi=3Doff)\n");
+            printk("ACPI is disabled, notifying domain %pd (acpi=3Doff)\n"=
, d);
             safe_strcpy(acpi_param, "off");
         }
=20
@@ -1078,7 +1081,7 @@ static struct domain *__init create_dom0(struct boot_=
info *bi)
=20
     bd->d =3D d;
     if ( construct_dom0(bd) !=3D 0 )
-        panic("Could not construct domain 0\n");
+        panic("Could not construct domain %pd\n", d);
=20
     bd->cmdline =3D NULL;
     xfree(cmdline);
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index 2c56f13771..9236dbae11 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -850,15 +850,13 @@ void __init create_domUs(void)
         struct xen_domctl_createdomain d_cfg =3D {0};
         unsigned int flags =3D 0U;
         bool has_dtb =3D false;
+        domid_t domid;
         uint32_t val;
         int rc;
=20
         if ( !dt_device_is_compatible(node, "xen,domain") )
             continue;
=20
-        if ( (max_init_domid + 1) >=3D DOMID_FIRST_RESERVED )
-            panic("No more domain IDs available\n");
-
         d_cfg.max_evtchn_port =3D 1023;
         d_cfg.max_grant_frames =3D -1;
         d_cfg.max_maptrack_frames =3D -1;
@@ -981,7 +979,11 @@ void __init create_domUs(void)
          * very important to use the pre-increment operator to call
          * domain_create() with a domid > 0. (domid =3D=3D 0 is reserved f=
or Dom0)
          */
-        d =3D domain_create(++max_init_domid, &d_cfg, flags);
+        domid =3D domid_alloc(++max_init_domid);
+        if ( domid =3D=3D DOMID_INVALID )
+            panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
+
+        d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
             panic("Error creating domain %s (rc =3D %ld)\n",
                   dt_node_name(node), PTR_ERR(d));
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..37fe811f3f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -66,6 +66,12 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
 static struct domain *domain_hash[DOMAIN_HASH_SIZE];
 struct domain *domain_list;
=20
+/* Non-system domain ID allocator. */
+#define CONFIG_MAX_DOMID DOMID_FIRST_RESERVED
+static DEFINE_SPINLOCK(domid_lock);
+static DECLARE_BITMAP(domid_bitmap, CONFIG_MAX_DOMID);
+static domid_t domid_last;
+
 /*
  * Insert a domain into the domlist/hash.  This allows the domain to be lo=
oked
  * up by domid, and therefore to be the subject of hypercalls/etc.
@@ -1449,6 +1455,8 @@ void domain_destroy(struct domain *d)
=20
     TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id);
=20
+    domid_free(d->domain_id);
+
     /* Remove from the domlist/hash. */
     domlist_remove(d);
=20
@@ -2405,6 +2413,46 @@ domid_t get_initial_domain_id(void)
     return hardware_domid;
 }
=20
+domid_t domid_alloc(domid_t domid)
+{
+    spin_lock(&domid_lock);
+
+    if ( domid < CONFIG_MAX_DOMID )
+    {
+        if ( __test_and_set_bit(domid, domid_bitmap) )
+            domid =3D DOMID_INVALID;
+    }
+    else
+    {
+        domid =3D find_next_zero_bit(domid_bitmap, CONFIG_MAX_DOMID,
+                                   domid_last);
+
+        if ( domid =3D=3D CONFIG_MAX_DOMID )
+            domid =3D find_next_zero_bit(domid_bitmap, CONFIG_MAX_DOMID, 0=
);
+
+        if ( domid =3D=3D CONFIG_MAX_DOMID )
+        {
+            domid =3D DOMID_INVALID;
+        }
+        else
+        {
+            __set_bit(domid, domid_bitmap);
+            domid_last =3D domid;
+        }
+    }
+
+    spin_unlock(&domid_lock);
+
+    return domid;
+}
+
+void domid_free(domid_t domid)
+{
+    spin_lock(&domid_lock);
+    __clear_bit(domid, domid_bitmap);
+    spin_unlock(&domid_lock);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index bfe2e1f9f0..8ef0c147c9 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -49,20 +49,6 @@ static int xenctl_bitmap_to_nodemask(nodemask_t *nodemas=
k,
                                    MAX_NUMNODES);
 }
=20
-static inline int is_free_domid(domid_t dom)
-{
-    struct domain *d;
-
-    if ( dom >=3D DOMID_FIRST_RESERVED )
-        return 0;
-
-    if ( (d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL )
-        return 1;
-
-    rcu_unlock_domain(d);
-    return 0;
-}
-
 void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info=
)
 {
     struct vcpu *v;
@@ -421,36 +407,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u=
_domctl)
=20
     case XEN_DOMCTL_createdomain:
     {
-        domid_t        dom;
-        static domid_t rover =3D 0;
+        domid_t domid =3D domid_alloc(op->domain);
=20
-        dom =3D op->domain;
-        if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) )
+        if ( domid =3D=3D DOMID_INVALID )
         {
             ret =3D -EEXIST;
-            if ( !is_free_domid(dom) )
-                break;
-        }
-        else
-        {
-            for ( dom =3D rover + 1; dom !=3D rover; dom++ )
-            {
-                if ( dom =3D=3D DOMID_FIRST_RESERVED )
-                    dom =3D 1;
-                if ( is_free_domid(dom) )
-                    break;
-            }
-
-            ret =3D -ENOMEM;
-            if ( dom =3D=3D rover )
-                break;
-
-            rover =3D dom;
+            break;
         }
=20
-        d =3D domain_create(dom, &op->u.createdomain, false);
+        d =3D domain_create(domid, &op->u.createdomain, false);
         if ( IS_ERR(d) )
         {
+            domid_free(domid);
             ret =3D PTR_ERR(d);
             d =3D NULL;
             break;
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index e10baf2615..8aab05ae93 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -38,6 +38,9 @@ void arch_get_domain_info(const struct domain *d,
=20
 domid_t get_initial_domain_id(void);
=20
+domid_t domid_alloc(domid_t domid);
+void domid_free(domid_t domid);
+
 /* CDF_* constant. Internal flags for domain creation. */
 /* Is this a privileged domain? */
 #define CDF_privileged           (1U << 0)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 19:23:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:23:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990172.1374121 (Exim 4.92)
	(envelope-from )
	id 1uH65Q-0007zg-Ll; Mon, 19 May 2025 19:23:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990172.1374121; Mon, 19 May 2025 19:23: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 1uH65Q-0007zZ-Iu; Mon, 19 May 2025 19:23:44 +0000
Received: by outflank-mailman (input) for mailman id 990172;
 Mon, 19 May 2025 19:23:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH65Q-0007ND-2d
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:23:44 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c66506dc-34e6-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 21:23: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" 
X-Inumbo-ID: c66506dc-34e6-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747682621; x=1747941821;
	bh=ZfcDPm9ra4WSZMObP3C001/155/M/iDDGdUUTxUS1WA=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=k851jt31c6LgfXQqNFr5lBOiW1vxU34LOL7noHLXbR9Au4W1635i4sO6BFo/cIJK+
	 EE6P6xm6Wso66r2z/Ky44pNNmx7WK5kkNnDYP4j3gEsKy1RJO6iuB7JJeFWNitBNmE
	 r1lkjxrGSvhKtgO38vD8UiUgbnJRuCIBdwcGFOmICGmCzvvY6+6tQ1FY1HevUgNhfw
	 jQWtyKup9izJiZZh/fr38ahigqwrPjeOKPjCfVYsJG/zlSpVZOg/UTs1/94ktDZMu+
	 PHit3MhDkv4KiqSEKjFejyxXwF0wE5B5ioB+oGn87tLYw4PO9qhjpSIZHqYjpcS2hD
	 tyL1Dz4PWi6hQ==
Date: Mon, 19 May 2025 19:23:35 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v7 2/3] xen/domain: adjust domain ID allocation for Arm
Message-ID: <20250519192306.1364471-3-dmukhin@ford.com>
In-Reply-To: <20250519192306.1364471-1-dmukhin@ford.com>
References: <20250519192306.1364471-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 5fe2bf1a84824914e7f9bf48ed2955d99b5d9fb5
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Remove the hardcoded domain ID 0 allocation for hardware domain and replace=
 it
with a call to get_initial_domain_id() (returns the value of hardware_domid=
 on
Arm).

Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_domain_id=
()
ID is skipped during domain ID allocation to cover domU case in dom0less
configuration. That also fixes a potential issue with re-using ID#0 for dom=
Us
when get_initial_domain_id() returns non-zero.

Signed-off-by: Denis Mukhin 
---
Changes since v6:
- reworked to use bitmap
---
 xen/arch/arm/domain_build.c             | 4 ++--
 xen/common/device-tree/dom0less-build.c | 9 +++------
 xen/common/domain.c                     | 6 ++++++
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e9d563c269..0ad80b020a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2035,9 +2035,9 @@ void __init create_dom0(void)
     if ( !llc_coloring_enabled )
         flags |=3D CDF_directmap;
=20
-    domid =3D domid_alloc(0);
+    domid =3D domid_alloc(get_initial_domain_id());
     if ( domid =3D=3D DOMID_INVALID )
-        panic("Error allocating domain ID 0\n");
+        panic("Error allocating domain ID %d\n", get_initial_domain_id());
=20
     dom0 =3D domain_create(domid, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index 9236dbae11..8e38affd0c 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -974,14 +974,11 @@ void __init create_domUs(void)
=20
         arch_create_domUs(node, &d_cfg, flags);
=20
-        /*
-         * The variable max_init_domid is initialized with zero, so here i=
t's
-         * very important to use the pre-increment operator to call
-         * domain_create() with a domid > 0. (domid =3D=3D 0 is reserved f=
or Dom0)
-         */
-        domid =3D domid_alloc(++max_init_domid);
+        domid =3D domid_alloc(DOMID_INVALID);
         if ( domid =3D=3D DOMID_INVALID )
             panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
+        if ( max_init_domid < domid )
+            max_init_domid =3D domid;
=20
         d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 37fe811f3f..0145870a7d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2424,6 +2424,9 @@ domid_t domid_alloc(domid_t domid)
     }
     else
     {
+        domid_t reserved;
+
+        reserved =3D __test_and_set_bit(get_initial_domain_id(), domid_bit=
map);
         domid =3D find_next_zero_bit(domid_bitmap, CONFIG_MAX_DOMID,
                                    domid_last);
=20
@@ -2439,6 +2442,9 @@ domid_t domid_alloc(domid_t domid)
             __set_bit(domid, domid_bitmap);
             domid_last =3D domid;
         }
+
+        if ( !reserved )
+            __clear_bit(reserved, domid_bitmap);
     }
=20
     spin_unlock(&domid_lock);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 19:23:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:23:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990175.1374131 (Exim 4.92)
	(envelope-from )
	id 1uH65Y-0008Qg-T9; Mon, 19 May 2025 19:23:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990175.1374131; Mon, 19 May 2025 19:23: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 1uH65Y-0008QT-QA; Mon, 19 May 2025 19:23:52 +0000
Received: by outflank-mailman (input) for mailman id 990175;
 Mon, 19 May 2025 19:23:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH65X-0008La-G3
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:23:51 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cb68ff48-34e6-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 21:23: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" 
X-Inumbo-ID: cb68ff48-34e6-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747682629; x=1747941829;
	bh=UxJ5IYr6xZT9hXNxC8m3txSu2e/3r4UY8+YJs95ZuDs=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=npUDsX8xhMjaOU7Ckx4P1Di3ZGiBDJ5UEb++1bCewmPtPikfX0J2LnNbfVF6aH49R
	 Im1yJOtI75e7jsmCQjGrQgt8uBwdJcH/LowBRz/yUja8/ZVU7fIvXD0yM+uRclawPe
	 PHWiX8VQiwM1Sfs0VNLBtPTV1hs+fS2T+EOa4Z75ocTu9nbIGvhtVRc+nwmxbwJTym
	 D92KjUKBWgBY2fwYNCpJa0MFv1FexUvE17zujoQAGAgj7PAdCquV65BQVmdofzdjqF
	 Ch2cyrYmpH+rG4CZa7RiTVbpGBuVQVMjegCXzWybpF3vCStP+3AtYqpU1vgRjcWIXZ
	 lLjgPCj3KiJqw==
Date: Mon, 19 May 2025 19:23:44 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v7 3/3] xen/domain: introduce CONFIG_MAX_DOMID
Message-ID: <20250519192306.1364471-4-dmukhin@ford.com>
In-Reply-To: <20250519192306.1364471-1-dmukhin@ford.com>
References: <20250519192306.1364471-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 4ba635a10823f3ef503d79a6a890d0a17054a986
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Embedded deployments of Xen do not need to have support for more than dozen=
 of
domains.

Introduce build-time configuration option to limit the number of domains du=
ring
run-time.

Suggested-by: Julien Grall 
Signed-off-by: Denis Mukhin 
---
Changes since v6:
- new patch
---
 xen/arch/arm/tee/ffa.c              | 3 ++-
 xen/arch/x86/cpu/mcheck/mce.c       | 2 +-
 xen/arch/x86/cpu/vpmu.c             | 2 +-
 xen/common/Kconfig                  | 7 +++++++
 xen/common/domain.c                 | 7 +++----
 xen/common/sched/core.c             | 4 ++--
 xen/drivers/passthrough/vtd/iommu.c | 2 +-
 xen/include/public/domctl.h         | 2 +-
 8 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 3bbdd7168a..faca0acf6a 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -333,8 +333,9 @@ static int ffa_domain_init(struct domain *d)
      */
     BUILD_BUG_ON(DOMID_FIRST_RESERVED >=3D UINT16_MAX);
     BUILD_BUG_ON((DOMID_MASK & BIT(15, U)) !=3D 0);
+    BUILD_BUG_ON(DOMID_FIRST_RESERVED < CONFIG_MAX_DOMID);
=20
-    if ( d->domain_id >=3D DOMID_FIRST_RESERVED )
+    if ( d->domain_id >=3D CONFIG_MAX_DOMID )
         return -ERANGE;
=20
     ctx =3D xzalloc(struct ffa_ctx);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 1c348e557d..ee8ddd33b0 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1493,7 +1493,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc=
)
             d =3D rcu_lock_domain_by_any_id(mc_msrinject->mcinj_domid);
             if ( d =3D=3D NULL )
             {
-                if ( mc_msrinject->mcinj_domid >=3D DOMID_FIRST_RESERVED )
+                if ( mc_msrinject->mcinj_domid >=3D CONFIG_MAX_DOMID )
                     return x86_mcerr("do_mca inject: incompatible flag "
                                      "MC_MSRINJ_F_GPADDR with domain %d",
                                      -EINVAL, domid);
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index c28192ea26..67d423e088 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -174,7 +174,7 @@ void vpmu_do_interrupt(void)
      * in XENPMU_MODE_ALL, for everyone.
      */
     if ( (vpmu_mode & XENPMU_MODE_ALL) ||
-         (sampled->domain->domain_id >=3D DOMID_FIRST_RESERVED) )
+         (sampled->domain->domain_id >=3D CONFIG_MAX_DOMID) )
     {
         sampling =3D choose_hwdom_vcpu();
         if ( !sampling )
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6d43be2e6e..4b487905fa 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -576,4 +576,11 @@ config BUDDY_ALLOCATOR_SIZE
 =09  Amount of memory reserved for the buddy allocator to serve Xen heap,
 =09  working alongside the colored one.
=20
+config MAX_DOMID
+=09int "Maximum number of non-system domains"
+=09range 1 32752
+=09default 32752
+=09help
+=09  Controls the maximum number of non-system domains in the system.
+
 endmenu
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 0145870a7d..cb05156ff5 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -67,7 +67,6 @@ static struct domain *domain_hash[DOMAIN_HASH_SIZE];
 struct domain *domain_list;
=20
 /* Non-system domain ID allocator. */
-#define CONFIG_MAX_DOMID DOMID_FIRST_RESERVED
 static DEFINE_SPINLOCK(domid_lock);
 static DECLARE_BITMAP(domid_bitmap, CONFIG_MAX_DOMID);
 static domid_t domid_last;
@@ -156,7 +155,7 @@ int domain_init_states(void)
     ASSERT(rw_is_write_locked_by_me(¤t->domain->event_lock));
=20
     dom_state_changed =3D xvzalloc_array(unsigned long,
-                                       BITS_TO_LONGS(DOMID_FIRST_RESERVED)=
);
+                                       BITS_TO_LONGS(CONFIG_MAX_DOMID));
     if ( !dom_state_changed )
         return -ENOMEM;
=20
@@ -236,7 +235,7 @@ int get_domain_state(struct xen_domctl_get_domain_state=
 *info, struct domain *d,
     while ( dom_state_changed )
     {
         dom =3D find_first_bit(dom_state_changed, DOMID_MASK + 1);
-        if ( dom >=3D DOMID_FIRST_RESERVED )
+        if ( dom >=3D CONFIG_MAX_DOMID )
             break;
         if ( test_and_clear_bit(dom, dom_state_changed) )
         {
@@ -825,7 +824,7 @@ struct domain *domain_create(domid_t domid,
     /* Sort out our idea of is_hardware_domain(). */
     if ( (flags & CDF_hardware) || domid =3D=3D hardware_domid )
     {
-        if ( hardware_domid < 0 || hardware_domid >=3D DOMID_FIRST_RESERVE=
D )
+        if ( hardware_domid < 0 || hardware_domid >=3D CONFIG_MAX_DOMID )
             panic("The value of hardware_dom must be a valid domain ID\n")=
;
=20
         /* late_hwdom is only allowed for dom0. */
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 9043414290..f1bfb6f6a2 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -867,7 +867,7 @@ int sched_init_domain(struct domain *d, unsigned int po=
olid)
     int ret;
=20
     ASSERT(d->cpupool =3D=3D NULL);
-    ASSERT(d->domain_id < DOMID_FIRST_RESERVED);
+    ASSERT(d->domain_id < CONFIG_MAX_DOMID);
=20
     if ( (ret =3D cpupool_add_domain(d, poolid)) )
         return ret;
@@ -891,7 +891,7 @@ int sched_init_domain(struct domain *d, unsigned int po=
olid)
=20
 void sched_destroy_domain(struct domain *d)
 {
-    ASSERT(d->domain_id < DOMID_FIRST_RESERVED);
+    ASSERT(d->domain_id < CONFIG_MAX_DOMID);
=20
     if ( d->cpupool )
     {
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/=
vtd/iommu.c
index c55f02c97e..5df85ca629 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1509,7 +1509,7 @@ int domain_context_mapping_one(
=20
         prev_did =3D context_domain_id(lctxt);
         domid =3D did_to_domain_id(iommu, prev_did);
-        if ( domid < DOMID_FIRST_RESERVED )
+        if ( domid < CONFIG_MAX_DOMID )
             prev_dom =3D rcu_lock_domain_by_id(domid);
         else if ( pdev ? domid =3D=3D pdev->arch.pseudo_domid : domid > DO=
MID_MASK )
             prev_dom =3D rcu_lock_domain(dom_io);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5b2063eed9..0c14c30c1b 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -36,7 +36,7 @@
=20
 /*
  * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
- * If it is specified as an invalid value (0 or >=3D DOMID_FIRST_RESERVED)=
,
+ * If it is specified as an invalid value (0 or >=3D CONFIG_MAX_DOMID),
  * an id is auto-allocated and returned.
  */
 /* XEN_DOMCTL_createdomain */
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 19:29:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:29:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990205.1374140 (Exim 4.92)
	(envelope-from )
	id 1uH6AU-00019x-Kq; Mon, 19 May 2025 19:28:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990205.1374140; Mon, 19 May 2025 19:28:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH6AU-00019q-IF; Mon, 19 May 2025 19:28:58 +0000
Received: by outflank-mailman (input) for mailman id 990205;
 Mon, 19 May 2025 19:28:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6AS-00019k-S9
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:28:56 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 807b846d-34e7-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 21:28: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" 
X-Inumbo-ID: 807b846d-34e7-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747682933; x=1747942133;
	bh=EVi8Hx1WoiFWzl7lifzSRGlqUUNnXKgH4ezOB7X2b88=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=lacicC7IKMz9v6u7Fc/DCbwQGN6HKxX909OwPQFJePMqkg5fz+7XNrvvE3Mt1c5Gm
	 X2r0biBGD96rMTi5RzlvWgi0tcsvbqVrbfz0kF3POy3IviBBDRUWLC6uoJS9yS4ikM
	 wAZ8gctmSWbi4vPN8K9OpeugA7nvE58MoF9qkpY9o6jqQ6YZBBqKcu135TNwJ0Y67k
	 bpVIdVYvQnOtADXN6dsOt1M2A1TMaux8cAZY9UiknfrXTLyOI6aMTFsYIUHP3VqmMf
	 wMQe4mhSEIYdMDG0C5wBVO8JzrxzKr9WNFEpCKIpYEVbP9WHZFiLGVuPdz1iEIRqnL
	 miVjnwHHfTreA==
Date: Mon, 19 May 2025 19:28:47 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 2/2] xen/domain: adjust domain ID allocation for Arm
Message-ID: 
In-Reply-To: 
References: <20250516020434.1145337-1-dmukhin@ford.com> <20250516020434.1145337-3-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 047387ad87ad0eea3f503587682c6e44b9af21a6
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, May 18, 2025 at 10:57:44AM +0200, Jan Beulich wrote:
> On 16.05.2025 04:04, dmkhn@proton.me wrote:
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -85,7 +85,7 @@ void __init domid_init(void)
> >   *
> >   * If hint is outside of valid [0..DOMID_FIRST_RESERVED - 1] range of =
IDs,
> >   * perform an exhaustive search starting from the end of the used doma=
in ID
> > - * range.
> > + * range, excluding get_initial_domain_id() ID.
> >   */
> >  domid_t domid_alloc(domid_t domid)
> >  {
> > @@ -103,6 +103,9 @@ domid_t domid_alloc(domid_t domid)
> >              if ( domid =3D=3D DOMID_FIRST_RESERVED )
> >                  domid =3D 0;
> >
> > +            if ( domid =3D=3D get_initial_domain_id() )
> > +                continue;
> > +
> >              if ( !rangeset_contains_singleton(domid_rangeset, domid) )
> >                  break;
> >          }
>=20
> Isn't there a (perhaps even pre-existing) issue here with a DomU potentia=
lly
> getting ID 0 assigned when get_initial_domain_id() returns non-zero?

Yes, thanks.

I have updated commit message in v7 to mention that:

  https://lore.kernel.org/xen-devel/20250519192306.1364471-3-dmukhin@ford.c=
om/

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Mon May 19 19:31:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:31:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990210.1374152 (Exim 4.92)
	(envelope-from )
	id 1uH6Cc-0002kq-1N; Mon, 19 May 2025 19:31:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990210.1374152; Mon, 19 May 2025 19:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH6Cb-0002kj-Tj; Mon, 19 May 2025 19:31:09 +0000
Received: by outflank-mailman (input) for mailman id 990210;
 Mon, 19 May 2025 19:31:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6Cb-0002kc-Jb
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:31:09 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cf8abddd-34e7-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 21:31: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" 
X-Inumbo-ID: cf8abddd-34e7-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747683066; x=1747942266;
	bh=5WtLiQhEqyCqxTfrs3BWG+IdQfpdRybAo/Mk4kZdsAc=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=XFVIaqknv5L59a4viFPwggTUz6jPPJc7QTs8tA2Ym2b1k5Y6+CVlBfvn7Y2MPgjDh
	 k0FD95bbWcPcnjvoF/Q2DDuH6wzr1nmZV4DM3ZWRvevt5aY5080xJxyC2inSZ4pStM
	 joRjrvi8rt0c4MBemeMtZ3KlGBQsNGBwNo7lKry2ijxAfiyrfvhzGuhjM8S35Xl9ZV
	 LT5sOyiqEdDnIBl0vb8D9ulB+XNKlhGcbFu0N8RkBYB0Ix4hKeHb6Jl3vRS3SChiM4
	 iId9GwOPvHjJM0T8JSNzwdBufe626v1OpiS0W/PpxnUmhlZ6qR/zlzt26Neb9TaMxq
	 FI1EBWYlSRwbQ==
Date: Mon, 19 May 2025 19:31:02 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 1/2] xen/domain: unify domain ID allocation
Message-ID: 
In-Reply-To: <98c10f03-c5f9-4e89-9aed-596b5cc3f8fd@suse.com>
References: <20250516020434.1145337-1-dmukhin@ford.com> <20250516020434.1145337-2-dmukhin@ford.com> <98c10f03-c5f9-4e89-9aed-596b5cc3f8fd@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: ff79bb8070c29cefbc1de661ba059bb16fec84b9
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, May 18, 2025 at 10:52:24AM +0200, Jan Beulich wrote:
> On 16.05.2025 04:04, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Currently, hypervisor code has two different non-system domain ID alloc=
ation
> > implementations:
> >
> >   (a) Sequential IDs allocation in dom0less Arm code based on max_init_=
domid;
> >
> >   (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not us=
e
> >       max_init_domid (both Arm and x86).
> >
> > It makes sense to have a common helper code for such task across archit=
ectures
> > (Arm and x86) and between dom0less / toolstack domU allocation.
> >
> > Wrap the domain ID allocation as an arch-independent function domid_all=
oc() in
> > common/domain.c based on rangeset.
> >
> > Allocation algorithm:
> > - If an explicit domain ID is provided, verify its availability and
> >   use it if ID is not used;
> > - Otherwise, perform an exhaustive search starting from the end of the =
used
> >   domain ID range. domid_alloc() guarantees that two subsequent calls w=
ill
> >   result in different IDs allocation.
> While you properly retain original logic now, the above is not an accurat=
e
> description thereof, imo. To search "from the end" usually is understood =
as
> a backwards search. Whereas what you mean is that the search starts off w=
here
> the last one finished, wrapping around when hitting the end of the valid
> range.

I have updated the description in v7:
  https://lore.kernel.org/xen-devel/20250519192306.1364471-2-dmukhin@ford.c=
om/

>=20
> Jan
>=20



From xen-devel-bounces@lists.xenproject.org Mon May 19 19:40:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:40:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990217.1374161 (Exim 4.92)
	(envelope-from )
	id 1uH6LU-0004Im-RB; Mon, 19 May 2025 19:40:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990217.1374161; Mon, 19 May 2025 19:40: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 1uH6LU-0004If-Nt; Mon, 19 May 2025 19:40:20 +0000
Received: by outflank-mailman (input) for mailman id 990217;
 Mon, 19 May 2025 19:40:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6LT-0004IZ-BU
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:40:19 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 17d4d88c-34e9-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 21:40: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" 
X-Inumbo-ID: 17d4d88c-34e9-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747683616; x=1747942816;
	bh=6QHXa3icmGRPFD0w15MS/LTXzAqACSE6Jxm0cnbJJuk=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=X2/804Xy236AYGJ2af+wHt8nyjWCwIWi5A0+0BEoDR3clF3530UCo2x5jnuOByADG
	 vOgK/4SCvYQSiAxyDxXAl5fTDv5z0WfPCB76GypXlwImmqOWodp9KfcwC5FKdiQcRv
	 zfkY9PBsJ7fNhaEwKCX2x1bM1TYZfM+Z9nL/XOzbPNxFV0Y+4+KS3JDF7ryQtNo9XD
	 RVd/xEW10M1WDFkO0/qsDO7lPLP50GD72LFvI8GUo3qZ5UKOZQc1zhPe0Xp1GCotbe
	 VuV/Uy2MeFKhuVxBrb6LeP6Yq9bpFOiJ6olO43UCp1L5kxeKMzrfuCoj4OXs2lBomq
	 q8vmGkm4iD6fQ==
Date: Mon, 19 May 2025 19:40:11 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 0/3] xen/console: few cleanups in console driver
Message-ID: <20250519194002.1365454-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 8a3d96259a16250a8a7f2bcba45492d1cbffbb46
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

xen/console: few cleanups in console driver

The patch series introduces a few cleanups aimed at reducing code duplicati=
on
in the console driver and improving readability.

Originally, patches 2 and 3 were part of NS16550 emulator v3 series [1].

Patch 1 performs a cleanup in conring console.

Patch 2 (see [2]) removes code duplication between __putstr() and the rest =
of
the driver. It also introduces private flags to select console devices for
printout which simplifies some code paths.

Patch 3 (see [3]) adds conring_flush() to send contents of conring to all
currently available console devices.

[1] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b3=
1d66c@ford.com/
[2] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-16-c5d36b=
31d66c@ford.com/
[3] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-17-c5d36b=
31d66c@ford.com/
[4] Link to v4: https://lore.kernel.org/xen-devel/20250516013508.1144162-1-=
dmukhin@ford.com/
[5] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1823639304

Denis Mukhin (3):
  xen/console: cleanup conring management
  xen/console: introduce console_send()
  xen/console: introduce conring_flush()

 xen/drivers/char/console.c | 186 +++++++++++++++++++++++--------------
 1 file changed, 116 insertions(+), 70 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 19:40:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:40:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990218.1374171 (Exim 4.92)
	(envelope-from )
	id 1uH6Lf-0004Zv-1Z; Mon, 19 May 2025 19:40:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990218.1374171; Mon, 19 May 2025 19:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uH6Le-0004Zo-Un; Mon, 19 May 2025 19:40:30 +0000
Received: by outflank-mailman (input) for mailman id 990218;
 Mon, 19 May 2025 19:40:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6Ld-0004Yu-9j
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:40:29 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1d525ac1-34e9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 21:40: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" 
X-Inumbo-ID: 1d525ac1-34e9-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=ufywkf3bczcgxnxdujomkfrazu.protonmail; t=1747683626; x=1747942826;
	bh=ExNNPytRMx+TBBWpl9H7gQEHGZzIhvwOBb7pDt+Cih4=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=D9gtujnHEiPenjxpAsyV5MDOwTmxxQPLufxBNWkg/GoSE9M0ol07YcOK4UqTQ06S8
	 aTWhmgUmTHns8QvfldBhSd3H/w1GUOitEFZLvfMpnGrKW6iJ4RLnfXRZ0zIOPcBxTy
	 +scs9ZL0zcHfPgYPHPG7w1bP8qDYl3Za35Z9dopiNfScGrQ+4ysL6nKJF/iI8AYRKY
	 fhzOsskjZcRKA0XIePfKef2Oxvwbk+ZMniz9jz1w0UY0iBACksXOLevdSJxgXy8aEV
	 L3b1MHe1pts8bzS5/vtWVBq7+T8ehnIaxXSpQgZaPYFop/eRyWNDsMN81YIZhKF4ii
	 3rW6hXpPpHkNg==
Date: Mon, 19 May 2025 19:40:20 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 1/3] xen/console: cleanup conring management
Message-ID: <20250519194002.1365454-2-dmukhin@ford.com>
In-Reply-To: <20250519194002.1365454-1-dmukhin@ford.com>
References: <20250519194002.1365454-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 56815f0c1ca0b0fc7f720a24e22918ab5df4d45f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Move conring tasklet code close to conring definitions in the console drive=
r
and rename conring tasklet variables by adding conring_ prefix for better
readability.

No functional change.

Signed-off-by: Denis Mukhin 
Reviewed-by: Stefano Stabellini 
---
Changes since v4:
- added R-b
---
 xen/drivers/char/console.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c3150fbdb7..b4757844e6 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -325,6 +325,16 @@ static void cf_check do_dec_thresh(unsigned char key, =
bool unused)
  * ********************************************************
  */
=20
+static void cf_check conring_notify(void *unused)
+{
+    send_global_virq(VIRQ_CON_RING);
+}
+
+static DECLARE_SOFTIRQ_TASKLET(conring_tasklet, conring_notify, NULL);
+
+/* NB: Do not send conring VIRQs during panic. */
+static bool conring_no_notify;
+
 static void conring_puts(const char *str, size_t len)
 {
     ASSERT(rspin_is_locked(&console_lock));
@@ -594,13 +604,6 @@ static void cf_check serial_rx(char c)
     __serial_rx(c);
 }
=20
-static void cf_check notify_dom0_con_ring(void *unused)
-{
-    send_global_virq(VIRQ_CON_RING);
-}
-static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
-                               notify_dom0_con_ring, NULL);
-
 #ifdef CONFIG_X86
 static inline void xen_console_write_debug_port(const char *buf, size_t le=
n)
 {
@@ -650,7 +653,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(=
char) buffer,
             if ( opt_console_to_ring )
             {
                 conring_puts(kbuf, kcount);
-                tasklet_schedule(¬ify_dom0_con_ring_tasklet);
+                tasklet_schedule(&conring_tasklet);
             }
=20
             nrspin_unlock_irq(&console_lock);
@@ -753,8 +756,6 @@ long do_console_io(
  * *****************************************************
  */
=20
-static bool console_locks_busted;
-
 static void __putstr(const char *str)
 {
     size_t len =3D strlen(str);
@@ -775,9 +776,8 @@ static void __putstr(const char *str)
 #endif
=20
     conring_puts(str, len);
-
-    if ( !console_locks_busted )
-        tasklet_schedule(¬ify_dom0_con_ring_tasklet);
+    if ( !conring_no_notify )
+        tasklet_schedule(&conring_tasklet);
 }
=20
 static int printk_prefix_check(char *p, char **pp)
@@ -1171,7 +1171,7 @@ void console_force_unlock(void)
     spin_debug_disable();
     rspin_lock_init(&console_lock);
     serial_force_unlock(sercon_handle);
-    console_locks_busted =3D 1;
+    conring_no_notify =3D true;
     console_start_sync();
 }
=20
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 19:40:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:40:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990219.1374181 (Exim 4.92)
	(envelope-from )
	id 1uH6Lk-0004tb-7w; Mon, 19 May 2025 19:40:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990219.1374181; Mon, 19 May 2025 19: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 1uH6Lk-0004tU-5G; Mon, 19 May 2025 19:40:36 +0000
Received: by outflank-mailman (input) for mailman id 990219;
 Mon, 19 May 2025 19:40:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6Li-0004IZ-GC
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:40:34 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 21412ce4-34e9-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 21:40: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" 
X-Inumbo-ID: 21412ce4-34e9-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747683633; x=1747942833;
	bh=Jbx/DmBBhad1ynkFBQ4ytgn26HdzCVmyX+znU/mgQIM=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=D4Iag1UUjfvjjjmL/rrkxzt5BMQLW961ZzRYHMaPYS43dVmzW2UzSPpfvPggugiDL
	 GnzsDI8TERZMLA0mRNkMhBMDn/UiPUI21OjYBJcaZy3hBTQIzcbLPWd8sH50nLM0un
	 MRDUqoDHJZEK172YgMr3kAqXp7Lg+/cHyYSSatoECAeYeXb1czO2f/3NTzBazYlEjQ
	 S2836agH2vjOb1ioeV9HN/6CavYmD8a+wmOYIXV2gHMyz6we2Eq5TpZSHdR8LDj3u2
	 S7G3/WUalHEJWmwlMD5/sfdqG8bpCyoUdL7+fbRXGahx5rnDBBqeyyJAouplCXnb8H
	 fzhOWpADCVq/w==
Date: Mon, 19 May 2025 19:40:28 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 2/3] xen/console: introduce console_send()
Message-ID: <20250519194002.1365454-3-dmukhin@ford.com>
In-Reply-To: <20250519194002.1365454-1-dmukhin@ford.com>
References: <20250519194002.1365454-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 6259aa80ae5cb55d00b8a9b3c9137349884dca56
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

guest_console_write() duplicates the code from __putstr(), eliminate code
duplication.

Introduce console_send() for sending a message on console devices.

Also, introduce internal console flags to control which console devices
should be used.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v4:
- fixup for console_send(): do CONSOLE_RING_VIRQ flag processing under
  CONSOLE_RING
---
 xen/drivers/char/console.c | 133 +++++++++++++++++++++++--------------
 1 file changed, 84 insertions(+), 49 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index b4757844e6..0c0cc6677c 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -41,6 +41,28 @@
 #include 
 #endif
=20
+/* Internal console flags. */
+enum {
+    CONSOLE_SERIAL          =3D BIT(0, U),    /* Use serial device. */
+    CONSOLE_PV              =3D BIT(1, U),    /* Use PV console. */
+    CONSOLE_VIDEO           =3D BIT(2, U),    /* Use video device. */
+    CONSOLE_DEBUG           =3D BIT(3, U),    /* Use debug device. */
+    CONSOLE_RING            =3D BIT(4, U),    /* Use console ring. */
+    CONSOLE_RING_VIRQ       =3D BIT(5, U),    /* Use console ring VIRQ. */
+
+    /* Default console flags. */
+    CONSOLE_DEFAULT         =3D CONSOLE_SERIAL |
+                              CONSOLE_PV |
+                              CONSOLE_VIDEO |
+                              CONSOLE_RING_VIRQ |
+                              CONSOLE_DEBUG,
+
+    /* Use all known console devices. */
+    CONSOLE_ALL             =3D CONSOLE_DEFAULT | CONSOLE_RING,
+};
+
+static void console_send(const char *str, size_t len, unsigned int flags);
+
 /* console: comma-separated list of console outputs. */
 static char __initdata opt_console[30] =3D OPT_CONSOLE_STR;
 string_param("console", opt_console);
@@ -428,9 +450,6 @@ void console_serial_puts(const char *s, size_t nr)
         serial_steal_fn(s, nr);
     else
         serial_puts(sercon_handle, s, nr);
-
-    /* Copy all serial output into PV console */
-    pv_console_puts(s, nr);
 }
=20
 static void cf_check dump_console_ring_key(unsigned char key)
@@ -464,8 +483,7 @@ static void cf_check dump_console_ring_key(unsigned cha=
r key)
         c +=3D len;
     }
=20
-    console_serial_puts(buf, sofar);
-    video_puts(buf, sofar);
+    console_send(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
=20
     free_xenheap_pages(buf, order);
 }
@@ -614,11 +632,71 @@ static inline void xen_console_write_debug_port(const=
 char *buf, size_t len)
 }
 #endif
=20
+static inline void console_debug_puts(const char *str, size_t len)
+{
+#ifdef CONFIG_X86
+    if ( opt_console_xen )
+    {
+        if ( xen_guest )
+            xen_hypercall_console_write(str, len);
+        else
+            xen_console_write_debug_port(str, len);
+    }
+#endif
+}
+
+/*
+ * Send a message on console device(s).
+ *
+ * That will handle all possible scenarios working w/ console
+ * - physical console (serial console, VGA console (x86 only));
+ * - PV console;
+ * - debug console (x86 only): debug I/O port or __HYPERVISOR_console_io
+ *   hypercall;
+ * - console ring.
+ */
+static void console_send(const char *str, size_t len, unsigned int flags)
+{
+    if ( flags & CONSOLE_SERIAL )
+        console_serial_puts(str, len);
+
+    if ( flags & CONSOLE_PV )
+        pv_console_puts(str, len);
+
+    if ( flags & CONSOLE_VIDEO )
+        video_puts(str, len);
+
+    if ( flags & CONSOLE_DEBUG )
+        console_debug_puts(str, len);
+
+    if ( flags & CONSOLE_RING )
+    {
+        conring_puts(str, len);
+
+        if ( flags & CONSOLE_RING_VIRQ )
+            tasklet_schedule(&conring_tasklet);
+    }
+}
+
+static inline void __putstr(const char *str)
+{
+    unsigned int flags =3D CONSOLE_ALL;
+
+    ASSERT(rspin_is_locked(&console_lock));
+
+    if ( conring_no_notify )
+        flags &=3D ~CONSOLE_RING_VIRQ;
+
+    console_send(str, strlen(str), flags);
+}
+
 static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
                                 unsigned int count)
 {
     char kbuf[128];
     unsigned int kcount =3D 0;
+    unsigned int flags =3D opt_console_to_ring
+                         ? CONSOLE_ALL : CONSOLE_DEFAULT;
     struct domain *cd =3D current->domain;
=20
     while ( count > 0 )
@@ -636,26 +714,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM=
(char) buffer,
         {
             /* Use direct console output as it could be interactive */
             nrspin_lock_irq(&console_lock);
-
-            console_serial_puts(kbuf, kcount);
-            video_puts(kbuf, kcount);
-
-#ifdef CONFIG_X86
-            if ( opt_console_xen )
-            {
-                if ( xen_guest )
-                    xen_hypercall_console_write(kbuf, kcount);
-                else
-                    xen_console_write_debug_port(kbuf, kcount);
-            }
-#endif
-
-            if ( opt_console_to_ring )
-            {
-                conring_puts(kbuf, kcount);
-                tasklet_schedule(&conring_tasklet);
-            }
-
+            console_send(kbuf, kcount, flags);
             nrspin_unlock_irq(&console_lock);
         }
         else
@@ -756,30 +815,6 @@ long do_console_io(
  * *****************************************************
  */
=20
-static void __putstr(const char *str)
-{
-    size_t len =3D strlen(str);
-
-    ASSERT(rspin_is_locked(&console_lock));
-
-    console_serial_puts(str, len);
-    video_puts(str, len);
-
-#ifdef CONFIG_X86
-    if ( opt_console_xen )
-    {
-        if ( xen_guest )
-            xen_hypercall_console_write(str, len);
-        else
-            xen_console_write_debug_port(str, len);
-    }
-#endif
-
-    conring_puts(str, len);
-    if ( !conring_no_notify )
-        tasklet_schedule(&conring_tasklet);
-}
-
 static int printk_prefix_check(char *p, char **pp)
 {
     int loglvl =3D -1;
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 19:40:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 19:40:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990224.1374192 (Exim 4.92)
	(envelope-from )
	id 1uH6Lr-0005Hp-HO; Mon, 19 May 2025 19:40:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990224.1374192; Mon, 19 May 2025 19:40: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 1uH6Lr-0005Hg-Cl; Mon, 19 May 2025 19:40:43 +0000
Received: by outflank-mailman (input) for mailman id 990224;
 Mon, 19 May 2025 19:40:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6Lq-0004Yu-1h
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 19:40:42 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 252dea66-34e9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 21:40: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" 
X-Inumbo-ID: 252dea66-34e9-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747683640; x=1747942840;
	bh=EAvg6x50bg20eIZqOFil9Se5UOlbAx31iaaUVq/HpdY=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=Ev4PjXE7PyD0grGId7W9taT1FuVEdPiZirMgKVTGVY+8TwkrzDek4+OF59a0ozQV6
	 VTxc8y2ButkY/MOHfoHu7RIYQ3vIsSZ0zUUPqYJGRnxznvMkcvG5/ChwVTEIGyTLvD
	 kZhZSlz6AcuD4amEedJW0xVKFdWyeYj/DcpGuONKHx8eWi1P83OsUwjssi8lS5H3uS
	 YrWVzYjp1W18y9A8mMrqBbD19puBM1XzWUM+orUEVD4+4dhqIINutfOB8zcLm2QjHZ
	 zSEb/sUF5qTtuqKy2vsnvqjISRdAHW2ZyuWUb60NQ2lb9sufdEqj7j57QL6zOjc9aD
	 XgbavepjKTesg==
Date: Mon, 19 May 2025 19:40:34 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 3/3] xen/console: introduce conring_flush()
Message-ID: <20250519194002.1365454-4-dmukhin@ford.com>
In-Reply-To: <20250519194002.1365454-1-dmukhin@ford.com>
References: <20250519194002.1365454-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 90728fbabf71f26f6fddcaa378fb988e2f88143e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Introduce conring_flush() to ensure all messages kept in the internal
console ring are sent to all physical consoles (serial, VGA (x86))
after their initialization is completed.

Rename dump_console_ring_key to conring_dump_keyhandler to match the
notation for conring management symbols.

Resolves: https://gitlab.com/xen-project/xen/-/issues/184
Signed-off-by: Denis Mukhin 
Reviewed-by: Stefano Stabellini 
---
Changes since v4:
- kept R-b
---
 xen/drivers/char/console.c | 31 +++++++++++++++++++++----------
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 0c0cc6677c..c15987f5bb 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -452,23 +452,19 @@ void console_serial_puts(const char *s, size_t nr)
         serial_puts(sercon_handle, s, nr);
 }
=20
-static void cf_check dump_console_ring_key(unsigned char key)
+/*
+ * Flush contents of the conring to the physical console devices.
+ */
+static int conring_flush(void)
 {
     uint32_t idx, len, sofar, c;
     unsigned int order;
     char *buf;
=20
-    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
-
-    /* create a buffer in which we'll copy the ring in the correct
-       order and NUL terminate */
     order =3D get_order_from_bytes(conring_size + 1);
     buf =3D alloc_xenheap_pages(order, 0);
     if ( buf =3D=3D NULL )
-    {
-        printk("unable to allocate memory!\n");
-        return;
-    }
+        return -ENOMEM;
=20
     c =3D conringc;
     sofar =3D 0;
@@ -486,6 +482,18 @@ static void cf_check dump_console_ring_key(unsigned ch=
ar key)
     console_send(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
=20
     free_xenheap_pages(buf, order);
+
+    return 0;
+}
+
+static void cf_check conring_dump_keyhandler(unsigned char key)
+{
+    int rc;
+
+    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
+    rc =3D conring_flush();
+    if ( rc )
+        printk("failed to dump console ring buffer: %d\n", rc);
 }
=20
 /*
@@ -1060,6 +1068,9 @@ void __init console_init_preirq(void)
     serial_set_rx_handler(sercon_handle, serial_rx);
     pv_console_set_rx_handler(serial_rx);
=20
+    /* NB: send conring contents to all enabled physical consoles, if any =
*/
+    conring_flush();
+
     /* HELLO WORLD --- start-of-day banner text. */
     nrspin_lock(&console_lock);
     __putstr(xen_banner());
@@ -1150,7 +1161,7 @@ void __init console_endboot(void)
     if ( opt_conswitch[1] =3D=3D 'x' )
         console_rx =3D max_console_rx;
=20
-    register_keyhandler('w', dump_console_ring_key,
+    register_keyhandler('w', conring_dump_keyhandler,
                         "synchronously dump console ring buffer (dmesg)", =
0);
     register_irq_keyhandler('+', &do_inc_thresh,
                             "increase log level threshold", 0);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 20:12:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 20:12:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990252.1374201 (Exim 4.92)
	(envelope-from )
	id 1uH6qd-0001Vd-Lp; Mon, 19 May 2025 20:12:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990252.1374201; Mon, 19 May 2025 20:12: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 1uH6qd-0001VW-JF; Mon, 19 May 2025 20:12:31 +0000
Received: by outflank-mailman (input) for mailman id 990252;
 Mon, 19 May 2025 20:12:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6qa-0001VO-Q8
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 20:12:29 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 94fec518-34ed-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 22:12: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" 
X-Inumbo-ID: 94fec518-34ed-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747685545; x=1747944745;
	bh=YnK3jLYPaV1fhqO+rkXjLhrCb+WsBMtOZfRJm26nEZM=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=YP+DDJEVyoAVGSP1QRuPscMiebHrsuW1ap2+viODyFkeKIbbTTbVo9voo4QCS/pBT
	 Yd+vDjciyS/wdauFyiRr0G+DYv4HTeIzBS9XkZLagqWtzu4c6JD2+PjInzje1gnErb
	 Dop1VcuBwYTj1jiJdxj1jbcv78BepR5abcxLteVXkZkgSgUCnVTTqL+7kJGrsiJJ86
	 7s9c6y53fLbaAOHgtYeU51kDUxNSsvZX0wcYLXLnMXiVqTPx6Hki+IQJ187VvqVp+J
	 TRwqZk1nLXXSS+2gDz+IXEN5ZzzuYR36Sf8fYQt5p/n6RJ84dJMzykjjnxVOaeOLMR
	 GwqeVEEvwg0PA==
Date: Mon, 19 May 2025 20:12:20 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3 0/5] xen/console: cleanup console input switch logic
Message-ID: <20250519201211.1366244-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: f13a340c786106a4c45b586f208fea8863fccf3f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The patch series originates from the NS16550 UART emulator series [1] (x86)
which requires ability to switch physical console input to a PVH/HVM domain
with an emulated UART.

Currently, on x86, console input can be rotated in round-robin manner only
between dom0, PV shim, and Xen itself. On Arm the input rotation can includ=
e
domUs with vpl011.

The main idea of this series is introducing a per-domain permission flag th=
at
is set during domain initialization and used by the console driver to switc=
h
the input across permitted domains.

Patch 1 performs rename of switch_serial_input() to fit the console driver
notation.

Patch 2 simplifies the existing vUART code by using newly introduced API.

Patch 3 introduces a new domain permission flag to mark ownership of the
console input for the console driver.

Patch 4 cleans up the console input switch logic by removing dependency
on max_init_domid. Depends on patches 1, 3 and [2].

Patch 5 performs rename of console_rx to console_domid to match the usage
of the symbol in the code.

[1] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b3=
1d66c@ford.com/
[2] https://lore.kernel.org/xen-devel/20250519192306.1364471-1-dmukhin@ford=
.com/
[3] Link to v2: https://lore.kernel.org/xen-devel/20250331230508.440198-1-d=
mukhin@ford.com/
[4] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1825448327

Denis Mukhin (5):
  xen/console: rename switch_serial_input() to console_switch_input()
  xen/console: introduce console_get_domid()
  xen/console: introduce console input permission
  xen/console: remove max_init_domid dependency
  xen/console: rename console_rx to console_domid

 xen/arch/arm/include/asm/setup.h        |   2 -
 xen/arch/arm/setup.c                    |   2 -
 xen/arch/arm/vpl011.c                   |   7 +-
 xen/arch/ppc/include/asm/setup.h        |   2 -
 xen/arch/riscv/include/asm/setup.h      |   2 -
 xen/arch/x86/include/asm/setup.h        |   2 -
 xen/arch/x86/pv/shim.c                  |   2 +
 xen/common/device-tree/dom0less-build.c |   2 -
 xen/common/domain.c                     |  31 +++++++
 xen/drivers/char/console.c              | 105 +++++++++++-------------
 xen/include/xen/console.h               |   3 +-
 xen/include/xen/domain.h                |   1 +
 xen/include/xen/sched.h                 |   8 +-
 13 files changed, 94 insertions(+), 75 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 20:12:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 20:12:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990253.1374211 (Exim 4.92)
	(envelope-from )
	id 1uH6qg-0001jQ-T8; Mon, 19 May 2025 20:12:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990253.1374211; Mon, 19 May 2025 20:12: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 1uH6qg-0001jJ-Q7; Mon, 19 May 2025 20:12:34 +0000
Received: by outflank-mailman (input) for mailman id 990253;
 Mon, 19 May 2025 20:12:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6qf-0001j7-QL
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 20:12:33 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 989019db-34ed-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 22:12: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" 
X-Inumbo-ID: 989019db-34ed-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747685550; x=1747944750;
	bh=E9iBDYrfKj31LI0uBbyEOTVIbFv75/GYvzBsSvZRX6M=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=W4aXddIKmLxBxELdx09Z2dBeF7rH0rw2NXlcL9s4ggfuIh8DPqEXlkXltpF4faT78
	 /K6f2Yo08fnd0EfM9tUg20+XdcJnZ6f6gKbQOksDRfQG7khfNDGVnGtXmOUpqnJHrS
	 sxU3/XtGOMn4FjVKV3f4DobqWPZ2wsxrlbjfPtyyoI8Bw1vaagkTvCFdlPIWl7fkAm
	 u0qQ5tHxtJ3ms37MEYeefnLiK4nUKcKHoiJlkjqNpXhTdMyOnRqYL0rWXcyTaBgDJz
	 hG5/lJJQFA2cT9sCgrugsfxQ4odmaURi8a7Apue8uBCdG2fwXkW5rB1axIilXkcJa8
	 nHBYqMAUv4uBw==
Date: Mon, 19 May 2025 20:12:27 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3 1/5] xen/console: rename switch_serial_input() to console_switch_input()
Message-ID: <20250519201211.1366244-2-dmukhin@ford.com>
In-Reply-To: <20250519201211.1366244-1-dmukhin@ford.com>
References: <20250519201211.1366244-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 2c7c174c17b8e55ae7bf60ddc31c94b0ac5dabf3
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Update the function name as per naming notation in the console driver.

No functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v2:
- rebased
- Link to v2: https://lore.kernel.org/xen-devel/20250331230508.440198-5-dmu=
khin@ford.com/
---
 xen/drivers/char/console.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c3150fbdb7..c8dde38376 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -487,7 +487,7 @@ void console_put_domain(struct domain *d)
         rcu_unlock_domain(d);
 }
=20
-static void switch_serial_input(void)
+static void console_switch_input(void)
 {
     unsigned int next_rx =3D console_rx;
=20
@@ -581,7 +581,7 @@ static void cf_check serial_rx(char c)
         /* We eat CTRL- in groups of 3 to switch console inpu=
t. */
         if ( ++switch_code_count =3D=3D 3 )
         {
-            switch_serial_input();
+            console_switch_input();
             switch_code_count =3D 0;
         }
         return;
@@ -1125,7 +1125,7 @@ void __init console_endboot(void)
                             "toggle host/guest log level adjustment", 0);
=20
     /* Serial input is directed to DOM0 by default. */
-    switch_serial_input();
+    console_switch_input();
 }
=20
 int __init console_has(const char *device)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 20:12:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 20:12:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990255.1374221 (Exim 4.92)
	(envelope-from )
	id 1uH6qr-00024e-3e; Mon, 19 May 2025 20:12:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990255.1374221; Mon, 19 May 2025 20:12: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 1uH6qr-00024T-0u; Mon, 19 May 2025 20:12:45 +0000
Received: by outflank-mailman (input) for mailman id 990255;
 Mon, 19 May 2025 20:12:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6qq-0001VO-Ad
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 20:12:44 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9ee05afc-34ed-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 22:12: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" 
X-Inumbo-ID: 9ee05afc-34ed-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=lbcbjcqqnncq3hedkmxwtc5dli.protonmail; t=1747685561; x=1747944761;
	bh=qkF9UnSC7+WkiSRXBNkMlXtFklvN0JpodfP2cIlJzU4=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=KjlElFsag3cIH+39onDpbCXbSMUoYWS2MmVwsRlP7E7sdcYhD+bFYLnzYIwleKKTI
	 HdmEXxgif6uPPFm8XYsMlkiFKoFRzAV/QzBJFh6fKg++435BY1Azc431z6zCeyNPZ7
	 9ufcjz1pWuOu6Mp/PmRqJACCes7I65lxTSfI6yPbt8RIx0Lo4GTtb6+gcNN2agGDsT
	 8pBTbW1CrQSuduJMVuCEo3wzbWHc/gXPYViE2T86Lnm9NqiahkVdQDStf0EzTq6P7m
	 N2F7NG4AsYWdHW1KHx+ROczQic//0eQwVc1UHRXbAMYykiAj2d1Lg3157yNgM1U0et
	 pNXGpmUqrvRcQ==
Date: Mon, 19 May 2025 20:12:34 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3 2/5] xen/console: introduce console_get_domid()
Message-ID: <20250519201211.1366244-3-dmukhin@ford.com>
In-Reply-To: <20250519201211.1366244-1-dmukhin@ford.com>
References: <20250519201211.1366244-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 6703ec991965501074107b8c9a962dece9dbce26
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Add console_get_domid() to the console driver to retrieve the current conso=
le
owner domain ID.

Use the function in vpl011 emulator which leads to simpler code.

Make console_{get,put}_domain() private to the console driver.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v2:
- changed commit subject line
- Link to v2: https://lore.kernel.org/xen-devel/20250331230508.440198-8-dmu=
khin@ford.com/
---
 xen/arch/arm/vpl011.c      |  5 +----
 xen/drivers/char/console.c | 11 +++++++++--
 xen/include/xen/console.h  |  3 +--
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 66047bf33c..0f58b2c900 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -78,12 +78,11 @@ static void vpl011_write_data_xen(struct domain *d, uin=
t8_t data)
     unsigned long flags;
     struct vpl011 *vpl011 =3D &d->arch.vpl011;
     struct vpl011_xen_backend *intf =3D vpl011->backend.xen;
-    struct domain *input =3D console_get_domain();
=20
     VPL011_LOCK(d, flags);
=20
     intf->out[intf->out_prod++] =3D data;
-    if ( d =3D=3D input )
+    if ( d->domain_id =3D=3D console_get_domid() )
     {
         if ( intf->out_prod =3D=3D 1 )
         {
@@ -123,8 +122,6 @@ static void vpl011_write_data_xen(struct domain *d, uin=
t8_t data)
     vpl011_update_interrupt_status(d);
=20
     VPL011_UNLOCK(d, flags);
-
-    console_put_domain(input);
 }
=20
 /*
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c8dde38376..86fd0b427d 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -474,19 +474,26 @@ static unsigned int __read_mostly console_rx =3D 0;
=20
 #define max_console_rx (max_init_domid + 1)
=20
-struct domain *console_get_domain(void)
+static struct domain *console_get_domain(void)
 {
     if ( console_rx =3D=3D 0 )
             return NULL;
     return rcu_lock_domain_by_id(console_rx - 1);
 }
=20
-void console_put_domain(struct domain *d)
+static void console_put_domain(struct domain *d)
 {
     if ( d )
         rcu_unlock_domain(d);
 }
=20
+domid_t console_get_domid(void)
+{
+    if ( console_rx =3D=3D 0 )
+        return DOMID_XEN;
+    return console_rx - 1;
+}
+
 static void console_switch_input(void)
 {
     unsigned int next_rx =3D console_rx;
diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
index 83cbc9fbda..c6f9d84d80 100644
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -32,8 +32,7 @@ void console_end_sync(void);
 void console_start_log_everything(void);
 void console_end_log_everything(void);
=20
-struct domain *console_get_domain(void);
-void console_put_domain(struct domain *d);
+domid_t console_get_domid(void);
=20
 /*
  * Steal output from the console. Returns +ve identifier, else -ve error.
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 20:12:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 20:12:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990257.1374231 (Exim 4.92)
	(envelope-from )
	id 1uH6qv-0002UF-AF; Mon, 19 May 2025 20:12:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990257.1374231; Mon, 19 May 2025 20:12: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 1uH6qv-0002U8-7H; Mon, 19 May 2025 20:12:49 +0000
Received: by outflank-mailman (input) for mailman id 990257;
 Mon, 19 May 2025 20:12:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6qt-0001j7-Qx
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 20:12:47 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a1a2f019-34ed-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 22:12: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" 
X-Inumbo-ID: a1a2f019-34ed-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747685566; x=1747944766;
	bh=s9Xnr4J9o81p53iu9F5mfQfhSRRP2AAzWB/TipdHU3A=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=GxUrsqJP7iTVFfU6KuShVIQs6rT1SJDCEbhhBJC2XshG+JdWGazOPhn4cAAtZGJ9u
	 BNx2r0x2KP5MIhDdOc4RqS8AuK0Ms61Sd+aTw/dYwPo6dawEhVGBJTreqOFwZiE6LQ
	 NHmjaMj1RJfrEw/HQmZMUvI8o7K1zsV77HrbXuJYcdcIETOX6KXhPOZjN/6cXdudF8
	 UyuYZJAaQWVMZ52whWgS99tRsnL6xaDSjDytiFS/Ebv4dtnJNEjC/Ve+GppYSuAH0n
	 GL6Z4cc6HqlhyzwdtCg1DNvw+6n1V4OO8ULeTYSNUwPlVoI+yzTQdQMjxpmVvRcly/
	 ogMyGxpJTv2Ew==
Date: Mon, 19 May 2025 20:12:42 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3 3/5] xen/console: introduce console input permission
Message-ID: <20250519201211.1366244-4-dmukhin@ford.com>
In-Reply-To: <20250519201211.1366244-1-dmukhin@ford.com>
References: <20250519201211.1366244-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 73229b2a4a156b643aacc4fab0873cf0afa39ded
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Add new flag to domain structure for marking permission to intercept
the physical console input by the domain.

Update console input switch logic accordingly.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v2:
- rebased
- Link to v2: https://lore.kernel.org/xen-devel/20250331230508.440198-2-dmu=
khin@ford.com/
---
 xen/arch/arm/vpl011.c      |  2 ++
 xen/arch/x86/pv/shim.c     |  2 ++
 xen/common/domain.c        |  2 ++
 xen/drivers/char/console.c | 18 +++++++++++++++++-
 xen/include/xen/sched.h    |  8 +++++++-
 5 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 0f58b2c900..d0e5504e9e 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -734,6 +734,8 @@ int domain_vpl011_init(struct domain *d, struct vpl011_=
init_info *info)
     register_mmio_handler(d, &vpl011_mmio_handler,
                           vpl011->base_addr, GUEST_PL011_SIZE, NULL);
=20
+    d->console.input_allowed =3D true;
+
     return 0;
=20
 out1:
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index c506cc0bec..bc2a7dd5fa 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -238,6 +238,8 @@ void __init pv_shim_setup_dom(struct domain *d, l4_pgen=
try_t *l4start,
      * guest from depleting the shim memory pool.
      */
     d->max_pages =3D domain_tot_pages(d);
+
+    d->console.input_allowed =3D true;
 }
=20
 static void write_start_info(struct domain *d)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index cb05156ff5..6a6cdd991b 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -836,6 +836,8 @@ struct domain *domain_create(domid_t domid,
         flags |=3D CDF_hardware;
         if ( old_hwdom )
             old_hwdom->cdf &=3D ~CDF_hardware;
+
+        d->console.input_allowed =3D true;
     }
=20
     /* Holding CDF_* internal flags. */
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 86fd0b427d..ccecda6523 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -476,9 +476,21 @@ static unsigned int __read_mostly console_rx =3D 0;
=20
 static struct domain *console_get_domain(void)
 {
+    struct domain *d;
+
     if ( console_rx =3D=3D 0 )
             return NULL;
-    return rcu_lock_domain_by_id(console_rx - 1);
+
+    d =3D rcu_lock_domain_by_id(console_rx - 1);
+    if ( !d )
+        return NULL;
+
+    if ( d->console.input_allowed )
+        return d;
+
+    rcu_unlock_domain(d);
+
+    return NULL;
 }
=20
 static void console_put_domain(struct domain *d)
@@ -522,6 +534,10 @@ static void console_switch_input(void)
         if ( d )
         {
             rcu_unlock_domain(d);
+
+            if ( !d->console.input_allowed )
+                break;
+
             console_rx =3D next_rx;
             printk("*** Serial input to DOM%u", domid);
             break;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 559d201e0c..e91c99a8f3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -512,7 +512,7 @@ struct domain
     bool             auto_node_affinity;
     /* Is this guest fully privileged (aka dom0)? */
     bool             is_privileged;
-    /* Can this guest access the Xen console? */
+    /* XSM: permission to use HYPERCALL_console_io hypercall */
     bool             is_console;
     /* Is this guest being debugged by dom0? */
     bool             debugger_attached;
@@ -651,6 +651,12 @@ struct domain
     unsigned int num_llc_colors;
     const unsigned int *llc_colors;
 #endif
+
+    /* Console settings. */
+    struct {
+        /* Permission to take ownership of the physical console input. */
+        bool input_allowed;
+    } console;
 } __aligned(PAGE_SIZE);
=20
 static inline struct page_list_head *page_to_list(
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 20:12:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 20:12:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990259.1374241 (Exim 4.92)
	(envelope-from )
	id 1uH6qz-0002rl-Hl; Mon, 19 May 2025 20:12:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990259.1374241; Mon, 19 May 2025 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 1uH6qz-0002rd-Ej; Mon, 19 May 2025 20:12:53 +0000
Received: by outflank-mailman (input) for mailman id 990259;
 Mon, 19 May 2025 20:12:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6qy-0001j7-8P
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 20:12:52 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a4149330-34ed-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 22:12: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" 
X-Inumbo-ID: a4149330-34ed-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=fdjbcg6bnra53gjokga2qhgkuq.protonmail; t=1747685570; x=1747944770;
	bh=qN2U2dQLJL1JMOGF37S4KVhD6fSMTiYi58zkKDBG0FE=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=mtVNnA0xWj8ZGXrtJXc/ZqmpBP58/kvlFljZRKgjbIFaK6dmawqP41Hqh5DSPnsPl
	 dqLAGtG8qnopmxqx7SLs6HCP48uDfm5XHUrfVsyBbQjIwQgn4YyOl75TrfloOYBdNG
	 6fyKcjuVkY+GDVHs0QT50m1YR/7JfBHyvl5qBpmm0Rn5Di8W/h9OFRYvhAQvByrDqP
	 6+FT1mslY+ueMAUqI7dGYgseuGjRYJZ9ujMoxeScYgLdiEaf7Gax81P68Ep2iBDDgb
	 yTlJfHTio4XVVdFmXAcRc2dTPvURfwPuCi6FfzcL7EBZiV9UbtzNDmI5G4GwNqo7fI
	 YtEdHgWnDl91w==
Date: Mon, 19 May 2025 20:12:47 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3 4/5] xen/console: remove max_init_domid dependency
Message-ID: <20250519201211.1366244-5-dmukhin@ford.com>
In-Reply-To: <20250519201211.1366244-1-dmukhin@ford.com>
References: <20250519201211.1366244-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 5910fde02699c1e1b7d6683d14e5de31da8b9449
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

The physical console input rotation depends on max_init_domid symbol, which=
 is
managed differently across architectures.

Instead of trying to manage max_init_domid in the arch-common code the cons=
ole
input rotation code can be reworked by removing dependency on max_init_domi=
d
entirely.

To do that, introduce domid_find_with_input_allowed() in arch-independent
location to find the ID of the next possible console owner domain. The IDs
are rotated across non-system domain IDs and DOMID_XEN.

Also, introduce helper console_set_domid() for updating identifier of the
current console input owner (points to Xen or domain).

Use domid_find_with_input_allowed() and console_set_domid() in
console_switch_input().

Remove uses of max_init_domid in the code.

Signed-off-by: Denis Mukhin 
---
Changes since v2:
- reworked to traversing domain list directly
- Link to v2: https://lore.kernel.org/xen-devel/20250331230508.440198-7-dmu=
khin@ford.com/
---
 xen/arch/arm/include/asm/setup.h        |   2 -
 xen/arch/arm/setup.c                    |   2 -
 xen/arch/ppc/include/asm/setup.h        |   2 -
 xen/arch/riscv/include/asm/setup.h      |   2 -
 xen/arch/x86/include/asm/setup.h        |   2 -
 xen/common/device-tree/dom0less-build.c |   2 -
 xen/common/domain.c                     |  29 +++++++
 xen/drivers/char/console.c              | 102 +++++++++---------------
 xen/include/xen/domain.h                |   1 +
 9 files changed, 66 insertions(+), 78 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/se=
tup.h
index 6cf272c160..f107e8eebb 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -25,8 +25,6 @@ struct map_range_data
     struct rangeset *irq_ranges;
 };
=20
-extern domid_t max_init_domid;
-
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
=20
 size_t estimate_efi_size(unsigned int mem_nr_banks);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 10b46d0684..53e2f8b537 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -61,8 +61,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
 bool __read_mostly acpi_disabled;
 #endif
=20
-domid_t __read_mostly max_init_domid;
-
 static __used void init_done(void)
 {
     int rc;
diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/se=
tup.h
index e4f64879b6..956fa6985a 100644
--- a/xen/arch/ppc/include/asm/setup.h
+++ b/xen/arch/ppc/include/asm/setup.h
@@ -1,6 +1,4 @@
 #ifndef __ASM_PPC_SETUP_H__
 #define __ASM_PPC_SETUP_H__
=20
-#define max_init_domid (0)
-
 #endif /* __ASM_PPC_SETUP_H__ */
diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/as=
m/setup.h
index c9d69cdf51..d1fc64b673 100644
--- a/xen/arch/riscv/include/asm/setup.h
+++ b/xen/arch/riscv/include/asm/setup.h
@@ -5,8 +5,6 @@
=20
 #include 
=20
-#define max_init_domid (0)
-
 void setup_mm(void);
=20
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/se=
tup.h
index ac34c69855..b67de8577f 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -69,6 +69,4 @@ extern bool opt_dom0_verbose;
 extern bool opt_dom0_cpuid_faulting;
 extern bool opt_dom0_msr_relaxed;
=20
-#define max_init_domid (0)
-
 #endif
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index 8e38affd0c..4c050b9ded 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -977,8 +977,6 @@ void __init create_domUs(void)
         domid =3D domid_alloc(DOMID_INVALID);
         if ( domid =3D=3D DOMID_INVALID )
             panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
-        if ( max_init_domid < domid )
-            max_init_domid =3D domid;
=20
         d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 6a6cdd991b..90bd42b633 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2460,6 +2460,35 @@ void domid_free(domid_t domid)
     spin_unlock(&domid_lock);
 }
=20
+/*
+ * Find the ID of the next possible console owner domain.
+ *
+ * @return Domain ID: DOMID_XEN or non-system domain IDs within
+ * the range of [0..CONFIG_MAX_DOMID-1].
+ */
+domid_t domid_find_with_input_allowed(domid_t hint)
+{
+    struct domain *d;
+    domid_t domid =3D DOMID_XEN;
+
+    spin_lock(&domlist_update_lock);
+
+    for ( d =3D domid_to_domain(hint);
+          d && likely(get_domain(d)) && (d->domain_id < CONFIG_MAX_DOMID);
+          d =3D d->next_in_list )
+    {
+        if ( d->console.input_allowed )
+        {
+            domid =3D d->domain_id;
+            break;
+        }
+    }
+
+    spin_unlock(&domlist_update_lock);
+
+    return domid;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index ccecda6523..ff20706ac9 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -462,26 +462,17 @@ static void cf_check dump_console_ring_key(unsigned c=
har key)
=20
 /*
  * CTRL- changes input direction, rotating among Xen, Dom0,
- * and the DomUs started from Xen at boot.
+ * and the DomUs.
  */
 #define switch_code (opt_conswitch[0]-'a'+1)
-/*
- * console_rx=3D0 =3D> input to xen
- * console_rx=3D1 =3D> input to dom0 (or the sole shim domain)
- * console_rx=3DN =3D> input to dom(N-1)
- */
-static unsigned int __read_mostly console_rx =3D 0;
=20
-#define max_console_rx (max_init_domid + 1)
+/* Console owner domain identifier. */
+static domid_t __read_mostly console_rx =3D DOMID_XEN;
=20
 static struct domain *console_get_domain(void)
 {
-    struct domain *d;
+    struct domain *d =3D rcu_lock_domain_by_id(console_rx);
=20
-    if ( console_rx =3D=3D 0 )
-            return NULL;
-
-    d =3D rcu_lock_domain_by_id(console_rx - 1);
     if ( !d )
         return NULL;
=20
@@ -499,50 +490,14 @@ static void console_put_domain(struct domain *d)
         rcu_unlock_domain(d);
 }
=20
-domid_t console_get_domid(void)
+static void console_set_domid(domid_t domid)
 {
-    if ( console_rx =3D=3D 0 )
-        return DOMID_XEN;
-    return console_rx - 1;
-}
+    if ( domid =3D=3D DOMID_XEN )
+        printk("*** Serial input to Xen");
+    else
+        printk("*** Serial input to DOM%u", domid);
=20
-static void console_switch_input(void)
-{
-    unsigned int next_rx =3D console_rx;
-
-    /*
-     * Rotate among Xen, dom0 and boot-time created domUs while skipping
-     * switching serial input to non existing domains.
-     */
-    for ( ; ; )
-    {
-        domid_t domid;
-        struct domain *d;
-
-        if ( next_rx++ >=3D max_console_rx )
-        {
-            console_rx =3D 0;
-            printk("*** Serial input to Xen");
-            break;
-        }
-
-        if ( consoled_is_enabled() && next_rx =3D=3D 1 )
-            domid =3D get_initial_domain_id();
-        else
-            domid =3D next_rx - 1;
-        d =3D rcu_lock_domain_by_id(domid);
-        if ( d )
-        {
-            rcu_unlock_domain(d);
-
-            if ( !d->console.input_allowed )
-                break;
-
-            console_rx =3D next_rx;
-            printk("*** Serial input to DOM%u", domid);
-            break;
-        }
-    }
+    console_rx =3D domid;
=20
     if ( switch_code )
         printk(" (type 'CTRL-%c' three times to switch input)",
@@ -550,12 +505,35 @@ static void console_switch_input(void)
     printk("\n");
 }
=20
+domid_t console_get_domid(void)
+{
+    return console_rx;
+}
+
+/*
+ * Switch console focus.
+ * Rotates input focus among Xen and domains with console input permission=
.
+ */
+static void console_switch_input(void)
+{
+    domid_t hint;
+
+    if ( console_rx =3D=3D DOMID_XEN )
+        hint =3D get_initial_domain_id();
+    else
+        hint =3D console_rx + 1;
+
+    hint =3D domid_find_with_input_allowed(hint);
+
+    console_set_domid(hint);
+}
+
 static void __serial_rx(char c)
 {
     struct domain *d;
     int rc =3D 0;
=20
-    if ( console_rx =3D=3D 0 )
+    if ( console_rx =3D=3D DOMID_XEN )
         return handle_keypress(c, false);
=20
     d =3D console_get_domain();
@@ -1130,14 +1108,6 @@ void __init console_endboot(void)
=20
     video_endboot();
=20
-    /*
-     * If user specifies so, we fool the switch routine to redirect input
-     * straight back to Xen. I use this convoluted method so we still prin=
t
-     * a useful 'how to switch' message.
-     */
-    if ( opt_conswitch[1] =3D=3D 'x' )
-        console_rx =3D max_console_rx;
-
     register_keyhandler('w', dump_console_ring_key,
                         "synchronously dump console ring buffer (dmesg)", =
0);
     register_irq_keyhandler('+', &do_inc_thresh,
@@ -1147,8 +1117,8 @@ void __init console_endboot(void)
     register_irq_keyhandler('G', &do_toggle_guest,
                             "toggle host/guest log level adjustment", 0);
=20
-    /* Serial input is directed to DOM0 by default. */
-    console_switch_input();
+    if ( opt_conswitch[1] !=3D 'x' )
+        (void)console_set_domid(get_initial_domain_id());
 }
=20
 int __init console_has(const char *device)
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 8aab05ae93..a88eb34f3f 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -36,6 +36,7 @@ void getdomaininfo(struct domain *d, struct xen_domctl_ge=
tdomaininfo *info);
 void arch_get_domain_info(const struct domain *d,
                           struct xen_domctl_getdomaininfo *info);
=20
+domid_t domid_find_with_input_allowed(domid_t hint);
 domid_t get_initial_domain_id(void);
=20
 domid_t domid_alloc(domid_t domid);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 20:13:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 20:13:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990265.1374251 (Exim 4.92)
	(envelope-from )
	id 1uH6r7-0003Td-0f; Mon, 19 May 2025 20:13:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990265.1374251; Mon, 19 May 2025 20:13: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 1uH6r6-0003TU-Tm; Mon, 19 May 2025 20:13:00 +0000
Received: by outflank-mailman (input) for mailman id 990265;
 Mon, 19 May 2025 20:12:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH6r4-0001j7-WE
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 20:12:59 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a82ad5cf-34ed-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 22:12: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" 
X-Inumbo-ID: a82ad5cf-34ed-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747685575; x=1747944775;
	bh=6sXF1UKe68CpK8zF6xNGeqeo9Hd97I7fR8xMKBTgt9Q=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=AoxtZYN3dQWGUjkd5u2yMRqvDReYphUtqaJlT+41xVoS/ZpGGeQ7zb/9u10Y7b1g0
	 GUjV5h6VLlJ2RRoLpN9+frGQDtM43X1iJcw47C02D4Z+mxCAOu2FTumJl3Gxy9g7Wz
	 b2FcgTwYVby+yNiud9mYdRbi97sbO1e9gBlKQRanRauOKJTOG77r2Ds+xGjiiXyDOw
	 sYfs+2h+XRO9y7AY6I1EQzSo0+Q7stcpP6GGM5IIC1HwtxAwlRg5zQZVZUdgOMEZgi
	 T+L+kXJFbAoBKSM+Ztg/2dGEcrDhKW6h4exmk+96H+/RD+RcXg0ljE21a0F+qPM91o
	 mhl6qfJMc1B3Q==
Date: Mon, 19 May 2025 20:12:51 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3 5/5] xen/console: rename console_rx to console_domid
Message-ID: <20250519201211.1366244-6-dmukhin@ford.com>
In-Reply-To: <20250519201211.1366244-1-dmukhin@ford.com>
References: <20250519201211.1366244-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 34962395dae726ecf123eaf0887728e83acd5270
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Update the symbol name to match the code better.

No functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v2:
- new patch
---
 xen/drivers/char/console.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index ff20706ac9..afcc6a236e 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -467,11 +467,11 @@ static void cf_check dump_console_ring_key(unsigned c=
har key)
 #define switch_code (opt_conswitch[0]-'a'+1)
=20
 /* Console owner domain identifier. */
-static domid_t __read_mostly console_rx =3D DOMID_XEN;
+static domid_t __read_mostly console_domid =3D DOMID_XEN;
=20
 static struct domain *console_get_domain(void)
 {
-    struct domain *d =3D rcu_lock_domain_by_id(console_rx);
+    struct domain *d =3D rcu_lock_domain_by_id(console_domid);
=20
     if ( !d )
         return NULL;
@@ -497,7 +497,7 @@ static void console_set_domid(domid_t domid)
     else
         printk("*** Serial input to DOM%u", domid);
=20
-    console_rx =3D domid;
+    console_domid =3D domid;
=20
     if ( switch_code )
         printk(" (type 'CTRL-%c' three times to switch input)",
@@ -507,7 +507,7 @@ static void console_set_domid(domid_t domid)
=20
 domid_t console_get_domid(void)
 {
-    return console_rx;
+    return console_domid;
 }
=20
 /*
@@ -518,10 +518,10 @@ static void console_switch_input(void)
 {
     domid_t hint;
=20
-    if ( console_rx =3D=3D DOMID_XEN )
+    if ( console_domid =3D=3D DOMID_XEN )
         hint =3D get_initial_domain_id();
     else
-        hint =3D console_rx + 1;
+        hint =3D console_domid + 1;
=20
     hint =3D domid_find_with_input_allowed(hint);
=20
@@ -533,7 +533,7 @@ static void __serial_rx(char c)
     struct domain *d;
     int rc =3D 0;
=20
-    if ( console_rx =3D=3D DOMID_XEN )
+    if ( console_domid =3D=3D DOMID_XEN )
         return handle_keypress(c, false);
=20
     d =3D console_get_domain();
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Mon May 19 20:55:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 20:55:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990301.1374260 (Exim 4.92)
	(envelope-from )
	id 1uH7WE-0000bp-0e; Mon, 19 May 2025 20:55:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990301.1374260; Mon, 19 May 2025 20:55: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 1uH7WD-0000bi-UN; Mon, 19 May 2025 20:55:29 +0000
Received: by outflank-mailman (input) for mailman id 990301;
 Mon, 19 May 2025 20:55:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uH7WC-0000bW-My
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 20:55:28 +0000
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com
 [2607:f8b0:4864:20::f29])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 96c4ba0d-34f3-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 22:55:26 +0200 (CEST)
Received: by mail-qv1-xf29.google.com with SMTP id
 6a1803df08f44-6f8d663fa22so22097626d6.0
 for ; Mon, 19 May 2025 13:55:26 -0700 (PDT)
Received: from smtpclient.apple (216-131-77-234.ord.as62651.net.
 [216.131.77.234]) by smtp.gmail.com with ESMTPSA id
 6a1803df08f44-6f8b08ac386sm61946206d6.39.2025.05.19.13.55.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 13:55: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" 
X-Inumbo-ID: 96c4ba0d-34f3-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747688125; x=1748292925; darn=lists.xenproject.org;
        h=to:in-reply-to:cc:references:message-id:date:subject:mime-version
         :from:content-transfer-encoding:from:to:cc:subject:date:message-id
         :reply-to;
        bh=W8Dsf5NQkRj5qoRJxyN4VTtmUFp809jK0+xUddzDTBQ=;
        b=k+YVSB+9FdjaLT2FMuLVyy072mtpsHi0g1fvjGAmZjnMCOOMuESGaMLNGamu+Z0Nvg
         0pnVDmUehNVB0Qnaem8badfEkj61SUXjNvhMKB3p2tMK5vTCx9nDzuEiT3qrti9tiH5l
         2MzqieZc/8opGIIjmh8ueBRmYCNo73trhTD7GsnRu1WF/ChLPhh17ORZQgfk3wAn0am9
         g/ap3najLLdXjGW02yzyuCItJu3jrSN3iiyI3QafVoe93l0C+rOCE+EC8hGw8PExgmvm
         NpWyfeORpa6rfjtP5bD77x+v7TTac3qxqr25Bqb20XC0ph8t2PVPAvDt2hW1fbCF61hU
         XPjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747688125; x=1748292925;
        h=to:in-reply-to:cc:references:message-id:date:subject:mime-version
         :from:content-transfer-encoding:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=W8Dsf5NQkRj5qoRJxyN4VTtmUFp809jK0+xUddzDTBQ=;
        b=QChy0P9rARs4elBZq3qb1Smn4Ss1TYxHIUavMfMa/jO9ZMuPj5HrDDlpZETX67j7CW
         uYQaTbCHXsrYEvGVtN8w+JuduTsvcLMJeWntqOA9En/IVZVuJAUrKA+V6iMHNSJPy8g+
         hT4Nz8hgFpc2QV6k9nYTYA9YlbxFL0+vdXpFfyZ0GpzWJY01HDtK2aExFpI34Mjh8XH7
         PEgmG2JeaYM3cNc78D3s04WcgdPV/OyQRBXeMCG6Zl+feb0XSyEvA2mTurVy16WKWQz8
         wDtOVRti66ZN6wa207DulYBBK1N831AGf0B4b7W2YgNGxC3iGBTM560iFtEvxAnWRtze
         ShgA==
X-Forwarded-Encrypted: i=1; AJvYcCXqSEmm3ueyMQPMKRlxLCtjTmEKXpPiSILRsuuguDx8QtH7mYtD8qUsXcpb+sWhMfssjNMxguLJLoo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxD4udH7wQNhH0F9M6+TlVFRPoxesFpWUAr6ZVomm+ZZs+zsSYE
	5X+vz3BYXiXb6CU7bfChxbrofPGpev73nlb6xauP2cGtoRHX2mORurcB
X-Gm-Gg: ASbGncsfONEjj5WGZnui2BdrQXDSiU61DxnV23P2l80XC1jEA2DsxB9uTS53ngop4DG
	uXOZWwzkjm6ljVg767giYbXiWq2y4EpejYIPoCbVqruoD5INlc9VCKkJ6Oa+71FUNN0lR8LnKXC
	cH2QBO7sAwwL0nmzLL4ZyntsfTYNExwU4Kg/ZKnLqerg51BaZNct4S2xbBdnjV6Nw9gPwY2irNI
	r1sz9Q7iIUHHuaNHv3RVKunU1MIlBGbG8ktRrMzCVhBRKZmlwZwDNvVX20Y4SojzdIlF0uXJ1l9
	Z6clZ6qWRGffPUhpA+PzJPqegpUzTq5yLUdQcsY3Zy8dTEpY5H94YkZzPZUzoB+7dEYSxPa0buJ
	mkPrb+La28gsPsE256Zz9J325HrI=
X-Google-Smtp-Source: AGHT+IEWRVaJ99D0vmulsyhWMmEkYePOE8RGbpAE0UQ6wGaA+WJKfE3lrWgEqECq4tiaDQVDH3GtRw==
X-Received: by 2002:a05:6214:1c8c:b0:6ed:1681:4846 with SMTP id 6a1803df08f44-6f8b2c95b84mr204349076d6.24.1747688125284;
        Mon, 19 May 2025 13:55:25 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Rich Persaud 
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and accessors for TXT registers and heap
Date: Mon, 19 May 2025 16:55:13 -0400
Message-Id: 
References: 
Cc: Andrew Cooper ,
 xen-devel@lists.xenproject.org,
 "Daniel P. Smith" ,
 Ross Philipson ,
 Jan Beulich ,
 =?utf-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Lukasz Hawrylko ,
 =?utf-8?Q?Mateusz_M=C3=B3wka?= ,
 trenchboot-devel@googlegroups.com
In-Reply-To: 
To: Sergii Dmytruk 
X-Mailer: iPad Mail (22F76)

On May 19, 2025, at 9:43=E2=80=AFAM, Sergii Dmytruk  wrote:
>=20
> =EF=BB=BFOn Sun, May 18, 2025 at 07:31:49PM -0400, Rich Persaud wrote:
>> If there's no stable URL for the TXT spec, can we mirror the relevant
>> doc(s) somewhere in the Xen docs tree? A trusted archive of the spec
>> for trusted execution.
>>=20
>> Rich
>=20
> By "unversioned link to Software Development Guide" I meant
> https://www.intel.com/content/www/us/en/content-details/315168/
> which always provides the latest version.

By "trusted archive of the spec" I meant a server under control of Intel or t=
he Xen community, hosting the specific version(s) of the spec that have been=
 implemented in the Xen tree. =20

Unless Intel reference PDFs are digitally signed by an Intel certificate, we=
 should not be linking to non-Intel mirrors of Intel PDFs, which could be ta=
rgeted by attackers to relay malware onto the workstations of developers of t=
rusted execution software. If Intel reference PDFs are signed, we should inc=
lude instructions for verifying their authenticity, if we are linking to non=
-Intel sources.

Rich=


From xen-devel-bounces@lists.xenproject.org Mon May 19 21:34:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 21:34:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990316.1374270 (Exim 4.92)
	(envelope-from )
	id 1uH87r-0005fx-ND; Mon, 19 May 2025 21:34:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990316.1374270; Mon, 19 May 2025 21: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 1uH87r-0005fq-KR; Mon, 19 May 2025 21:34:23 +0000
Received: by outflank-mailman (input) for mailman id 990316;
 Mon, 19 May 2025 21:34:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH87q-0005fk-Bx
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 21:34:22 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 05c1774f-34f9-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 23:34:20 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 9947AA462CA;
 Mon, 19 May 2025 21:34:19 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F8D4C4CEE4;
 Mon, 19 May 2025 21:34: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" 
X-Inumbo-ID: 05c1774f-34f9-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747690459;
	bh=uNIR9J8IYYLSDr8BnTHVoT33K0GNLeYQ5Ei7ULPdl+4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=stI53RA/WkY9416R1XTyO+DyubcProOGBuVyzwFF9e34TjFojI/hKivJbnMDGTNA5
	 +31nONVUyJ0dzJJeDVRXaQYxYG2lv8al0hicJxBGtPONHPJhTpYigwMfaISPsLyFWZ
	 VsLQd6qqHHxmZ2vVkhM/OpwvMSfFntwtrOrIspdA6Mmc49EDxNkE/zjKivtxlG6gyS
	 SVortkk/HAQdg6nLFx857I46u+p88WsB8L01mcksquW6hnOgcnF9IF+9Hou27kEPZH
	 yNdfjWorgJ09nbsO+wY+tjmrpJaCuLXHaaJIPy4y9VDsexvAe1G+uBtLYgp1NNqKYY
	 aypALreIUMjyg==
Date: Mon, 19 May 2025 14:34:16 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
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: Give compile.h header guards
In-Reply-To: 
Message-ID: 
References: <20250519135227.27386-1-andrew.cooper3@citrix.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 19 May 2025, Jan Beulich wrote:
> On 19.05.2025 15:52, Andrew Cooper wrote:
> > Signed-off-by: Andrew Cooper 
> 
> Is this to please Misra in some way?
> 
> > --- a/xen/include/xen/compile.h.in
> > +++ b/xen/include/xen/compile.h.in
> > @@ -1,3 +1,6 @@
> > +#ifndef XEN_COMPILE_H
> > +#define XEN_COMPILE_H
> > +
> >  #define XEN_COMPILE_DATE	"@@date@@"
> >  #define XEN_COMPILE_TIME	"@@time@@"
> >  #define XEN_COMPILE_BY		"@@whoami@@"
> > --- a/xen/tools/process-banner.sed
> > +++ b/xen/tools/process-banner.sed
> > @@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
> >  
> >  # Trailing \ on all but the final line.
> >  $!s_$_ \\_
> > +
> > +# Append closing header guard
> > +$a\
> > +\
> > +#endif /* XEN_COMPILE_H */
> 
> This split of #ifndef and #endif is ugly. Can't we switch to something
> more conventional, like
> 
> #define XEN_BANNER		"@@banner@@"
> 
> with the first sed invocation then replacing this by the result of
> a nested sed invocation using process-banner.sed (which of course would
> need adjusting some)? (Maybe the double quotes would need omitting here,
> for process-banner.sed to uniformly apply them.)

While I agree with Jan that this is kind of ugly, it is a unique case
and I would prefer an ugly but simple solution than a more complex
solution. This would be different if we were talking about a widespread
pattern, in which case the price for complexity would be worth it.

My 2 cents in this case are in favor of the simplest approach. I would
ack this patch.


From xen-devel-bounces@lists.xenproject.org Mon May 19 21:36:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 21:36:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990322.1374281 (Exim 4.92)
	(envelope-from )
	id 1uH8A0-0006E4-2O; Mon, 19 May 2025 21:36:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990322.1374281; Mon, 19 May 2025 21: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 1uH89z-0006Dx-VW; Mon, 19 May 2025 21:36:35 +0000
Received: by outflank-mailman (input) for mailman id 990322;
 Mon, 19 May 2025 21:36:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH89z-0006Dr-8k
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 21:36:35 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 54aadb7e-34f9-11f0-b892-0df219b8e170;
 Mon, 19 May 2025 23:36:33 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 5AE4E4445D;
 Mon, 19 May 2025 21:36:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC5A1C4CEE9;
 Mon, 19 May 2025 21:36: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" 
X-Inumbo-ID: 54aadb7e-34f9-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747690591;
	bh=UN/v0yGDBaVXFfDMpTCvsIRcPrKNBZzstrYmQVQGyUI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=cB/R01//RgMjOtyF0YdyU4nxK3gDk1iNgd2v+VfTL7hiOezY1xeEnkx/1+1oTjd0S
	 q0ovI/y7tTt1QLTV57mpnQxaX/OtuqwvxkJC+KKFSTadxBwWgpBYNjaAWzgjcPo88v
	 XR7Chb/sx0xdRpyiub34UM1C5YU4ETq85VWpPQAux8F2HlCGCXD5QByGim3Z/NFApe
	 OKiiIE/FUxd5q6IJAgTtE3ZwqW+HhfkicBls/kdmzhsizn7fUrpEQZBmjlmRrqPY4V
	 VuRDQZxfwW5x9DhTvcmrQJ3Gk1N4wCBAYQxE6xlRlVUEXQRhJLahg2PIWWf5Yxp3YH
	 FHNPUpxKd4oCw==
Date: Mon, 19 May 2025 14:36:28 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Federico Serafini 
cc: Andrew Cooper , 
    Stefano Stabellini , 
    xen-devel@lists.xenproject.org, michal.orzel@amd.com, jbeulich@suse.com, 
    julien@xen.org, roger.pau@citrix.com, sstabellini@kernel.org, 
    bertrand.marquis@arm.com
Subject: Re: [PATCH 6/6] automation/eclair: update configuration of D4.10
In-Reply-To: 
Message-ID: 
References:  <20250516232130.835779-6-stefano.stabellini@amd.com> <5c2aa885-8877-4708-90cc-d65a76b729b3@citrix.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-440588898-1747690591=:145034"

  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-440588898-1747690591=:145034
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 19 May 2025, Federico Serafini wrote:
> Hi,
> 
> On 17/05/25 01:57, Andrew Cooper wrote:
> > 
> > > +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated
> > > file, do not edit! \\*/$, begin-2))"}
> > >   -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated
> > > file, do not edit! \\*/$, begin-3))"}
> > 
> > These seem to only differ by the begin-$N.  Why doesn't the regex work
> > in both cases?
> 
> "begin-N" expresses the position of a single line, not a range.
> For example, begin-2 means "two lines before the first reported area"
> and deviates:
> 
> https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/hardware/xen/ECLAIR_normal/staging/X86_64/10063944407/PROJECT.ecd;/sources/xen/include/xen/hypercall-defs.h.html#R174_1{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":false,"selector":{"enabled":true,"negated":false,"kind":2,"children":[]}}}
> 
> If you prefer, I think we can use ranges and merge the two
> configurations.

I think that would be better
--8323329-440588898-1747690591=:145034--


From xen-devel-bounces@lists.xenproject.org Mon May 19 21:40:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 21:40:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990331.1374291 (Exim 4.92)
	(envelope-from )
	id 1uH8Dj-0007hq-Fl; Mon, 19 May 2025 21:40:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990331.1374291; Mon, 19 May 2025 21:40: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 1uH8Dj-0007hj-Cz; Mon, 19 May 2025 21:40:27 +0000
Received: by outflank-mailman (input) for mailman id 990331;
 Mon, 19 May 2025 21:40:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH8Di-0007hb-8N
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 21:40:26 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ded997c4-34f9-11f0-a2fa-13f23c93f187;
 Mon, 19 May 2025 23:40:24 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 7340D629D0;
 Mon, 19 May 2025 21:40:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82EFBC4CEE4;
 Mon, 19 May 2025 21:40:22 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ded997c4-34f9-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747690823;
	bh=nlHjKtCR89CYkiySO7rgbJ+xfOgqBFI53xilbFpS7mE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=YVrd84pk8P1hPk2PL3ijCstwqtfbdH8LccjMwwV/ktxzjpIXc4Kif/atjZe9z5U0/
	 e9fbPU8bHA9pXR7snnHb9UMLfv8LXg4DimSuhY1cjmk2tc8VLT5fi1jLL00D57wDg3
	 RGGfKGE3sTHTMGXPjXSuDMOf/Jcp/Yw3DPsfqCy7ro7MMgXbybzPBG31syYWZfdmnX
	 LpRAr2PaB7qluGDbLYyJu/Oa5esMAR3vppxLIfhH4LaYoKzKqSIPjfmvhaW+qCdQ6J
	 yl5gu1VdS/siY+lix2h1jzYiPLyH83KpQbXOH+9HnVeONDwwhDvItRH3Q05XVTCd3P
	 0pcp0yDT73Oww==
Date: Mon, 19 May 2025 14:40:21 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Nicola Vetrini 
cc: Andrew Cooper , 
    Xen-devel , 
    Stefano Stabellini , 
    "consulting @ bugseng . com" 
Subject: Re: [PATCH] CI/eclair: Remove ARM64 custom clean rules
In-Reply-To: 
Message-ID: 
References: <20250519140727.28562-1-andrew.cooper3@citrix.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 19 May 2025, Nicola Vetrini wrote:
> On 2025-05-19 16:07, Andrew Cooper wrote:
> > Rules 5.3, 11.2 and 16.6 are already listed in clean_guidelines_common and
> > apply to all architectures.  There's no need for arm64 to give them a second
> > time.
> > 
> 
> Thanks.
> 
> > Signed-off-by: Andrew Cooper 
> Reviewed-by: Nicola Vetrini 

Acked-by: Stefano Stabellini 


> > ---
> > CC: Stefano Stabellini 
> > CC: consulting@bugseng.com 
> > CC: Nicola Vetrini 
> > 
> > I've left the x86/arm split as-before so it's easier for those not familiar
> > with Eclair syntax to add per-arch configuruation.
> > ---
> >  automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl
> > b/automation/eclair_analysis/ECLAIR/tagging.ecl
> > index 7e3095423b79..b95f07feb099 100644
> > --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> > +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> > @@ -122,7 +122,7 @@ if(string_equal(target,"x86_64"),
> >  )
> > 
> >  if(string_equal(target,"arm64"),
> > -
> > service_selector({"additional_clean_guidelines","MC3A2.R5.3||MC3.R11.2||MC3A2.R16.6"})
> > +    service_selector({"additional_clean_guidelines","none()"})
> >  )
> > 
> > 
> > -reports+={clean:added,"service(clean_guidelines_common||additional_clean_guidelines)"}
> > 
> > base-commit: 6fc02ebdd053856221f37ba5306232ac1575332d
> > prerequisite-patch-id: 7bc1c498ba2c9c4a4939a56a0006f820f47f2a66
> > prerequisite-patch-id: 8fcd84101ab012ed0aa427c30eca564c5ac10726
> 
> -- 
> 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 May 19 22:26:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 22:26:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990340.1374305 (Exim 4.92)
	(envelope-from )
	id 1uH8vq-0004vh-Ka; Mon, 19 May 2025 22:26:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990340.1374305; Mon, 19 May 2025 22:26: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 1uH8vq-0004va-Hd; Mon, 19 May 2025 22:26:02 +0000
Received: by outflank-mailman (input) for mailman id 990340;
 Mon, 19 May 2025 22:26:01 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uH8vp-0004vU-5V
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 22:26:01 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uH8vo-001YaW-2D;
 Mon, 19 May 2025 22:26:00 +0000
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=[10.95.106.212])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uH8vo-004D9c-0i;
 Mon, 19 May 2025 22:26: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=woruLJD2LWnopL5cJma92FZxj8lRihr/XJ7GhMIFMH8=; b=o8DhymMYr94PviBwNhsRTK8eZ5
	iriyjJauJUG1DS4dEuL8yPSfAfDZ2EU5uPJidB0zw8LO3tp97Sa7R5i87jdrCsta6uoz4xgldJugC
	oy81X1lLsXQMmYL08ZObky8mRZpOUsqGNEQsSpgPqP78iZ6GDnUkAgaixhnFlaPrQozw=;
Message-ID: <806f37b3-118f-4f13-9738-b27de24dff7d@xen.org>
Date: Mon, 19 May 2025 23:25:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] xen/arm: add inclusion guards
Content-Language: en-GB
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, michal.orzel@amd.com, jbeulich@suse.com,
 roger.pau@citrix.com, sstabellini@kernel.org, bertrand.marquis@arm.com,
 Federico Serafini 
References: 
 <20250516232130.835779-1-stefano.stabellini@amd.com>
From: Julien Grall 
In-Reply-To: <20250516232130.835779-1-stefano.stabellini@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Stefano,

On 17/05/2025 00:21, Stefano Stabellini wrote:
> From: Federico Serafini 
> 
> MISRA C Directive 4.10 states that:
> "Precautions shall be taken in order to prevent the contents of a
> header file being included more than once".
> 
> Add inclusion guards where missing to address violations of the
> guideline.
> 
> Signed-off-by: Federico Serafini 
> Signed-off-by: Stefano Stabellini 

With one remark below:

Acked-by: Julien Grall 

> ---
>   xen/arch/arm/efi/efi-boot.h        | 6 ++++++
>   xen/arch/arm/include/asm/efibind.h | 5 +++++
>   2 files changed, 11 insertions(+)
> 
> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> index dcad46ca72..d2a09ad3a1 100644
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h

I always found weird that this file is treated as a header when in fact 
this is just a disguised source file. So in some way...

> @@ -3,6 +3,10 @@
>    * is intended to be included by common/efi/boot.c _only_, and
>    * therefore can define arch specific global variables.
>    */
> +
> +#ifndef ARM_EFI_BOOT_H
> +#define ARM_EFI_BOOT_H

... without the header guard, we could catch two inclusions of 
efi-boot.h. I would consider to use:

#ifdef ARM_EFI_BOOT_H
# error ...
#else
# define ...

#endif ...

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon May 19 22:39:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 22:39:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990349.1374316 (Exim 4.92)
	(envelope-from )
	id 1uH98S-0006gD-PW; Mon, 19 May 2025 22:39:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990349.1374316; Mon, 19 May 2025 22:39: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 1uH98S-0006g6-LZ; Mon, 19 May 2025 22:39:04 +0000
Received: by outflank-mailman (input) for mailman id 990349;
 Mon, 19 May 2025 22:39:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH98Q-0006g0-QH
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 22:39:02 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0e2651be-3502-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 00:39:00 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 83C4242B88;
 Mon, 19 May 2025 22:38:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F55CC4CEE4;
 Mon, 19 May 2025 22:38: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" 
X-Inumbo-ID: 0e2651be-3502-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747694338;
	bh=PxoVaS3+l2Fg2FhGMncJ/REst0egcuwxbD515nMapEU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ukR/dk6XUispoPgJD8n4HpI26rK0EN/jqv3/xzfJyqTn00ulSXRCANsOU2e65YQL+
	 QEyu5UFuvGsB2NfZi5R7kk3dI2zrA6Sf4lFvIwuKkCtocZNtNuZU6nziNDu9bzNVCU
	 0uoKCP6mQYzYZJXvDk5187mIJs3XUpkqEwWfNXSKHzHGC5A42UoCI2AaQTo8z0eRvT
	 p7cFGacfN2fisO+evz2ecFQvPZ8QzECUKf2Jhvubc0QN9bEzGlPcsDrNhMI+x43XqU
	 GMUvd+PCOcNIJV5YYODHXN0Ioyt7xoeFeOecq9gMO85aUlUhI30RWUjfCVupDsc9W7
	 tRwoWxOWL7o3A==
Date: Mon, 19 May 2025 15:38:55 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmkhn@proton.me
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com
Subject: Re: [PATCH v5 2/3] xen/console: introduce console_send()
In-Reply-To: <20250519194002.1365454-3-dmukhin@ford.com>
Message-ID: 
References: <20250519194002.1365454-1-dmukhin@ford.com> <20250519194002.1365454-3-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 19 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> guest_console_write() duplicates the code from __putstr(), eliminate code
> duplication.
> 
> Introduce console_send() for sending a message on console devices.
> 
> Also, introduce internal console flags to control which console devices
> should be used.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Stefano Stabellini 


> ---
> Changes since v4:
> - fixup for console_send(): do CONSOLE_RING_VIRQ flag processing under
>   CONSOLE_RING
> ---
>  xen/drivers/char/console.c | 133 +++++++++++++++++++++++--------------
>  1 file changed, 84 insertions(+), 49 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index b4757844e6..0c0cc6677c 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -41,6 +41,28 @@
>  #include 
>  #endif
>  
> +/* Internal console flags. */
> +enum {
> +    CONSOLE_SERIAL          = BIT(0, U),    /* Use serial device. */
> +    CONSOLE_PV              = BIT(1, U),    /* Use PV console. */
> +    CONSOLE_VIDEO           = BIT(2, U),    /* Use video device. */
> +    CONSOLE_DEBUG           = BIT(3, U),    /* Use debug device. */
> +    CONSOLE_RING            = BIT(4, U),    /* Use console ring. */
> +    CONSOLE_RING_VIRQ       = BIT(5, U),    /* Use console ring VIRQ. */
> +
> +    /* Default console flags. */
> +    CONSOLE_DEFAULT         = CONSOLE_SERIAL |
> +                              CONSOLE_PV |
> +                              CONSOLE_VIDEO |
> +                              CONSOLE_RING_VIRQ |
> +                              CONSOLE_DEBUG,
> +
> +    /* Use all known console devices. */
> +    CONSOLE_ALL             = CONSOLE_DEFAULT | CONSOLE_RING,
> +};
> +
> +static void console_send(const char *str, size_t len, unsigned int flags);
> +
>  /* console: comma-separated list of console outputs. */
>  static char __initdata opt_console[30] = OPT_CONSOLE_STR;
>  string_param("console", opt_console);
> @@ -428,9 +450,6 @@ void console_serial_puts(const char *s, size_t nr)
>          serial_steal_fn(s, nr);
>      else
>          serial_puts(sercon_handle, s, nr);
> -
> -    /* Copy all serial output into PV console */
> -    pv_console_puts(s, nr);
>  }
>  
>  static void cf_check dump_console_ring_key(unsigned char key)
> @@ -464,8 +483,7 @@ static void cf_check dump_console_ring_key(unsigned char key)
>          c += len;
>      }
>  
> -    console_serial_puts(buf, sofar);
> -    video_puts(buf, sofar);
> +    console_send(buf, sofar, CONSOLE_SERIAL | CONSOLE_VIDEO | CONSOLE_PV);
>  
>      free_xenheap_pages(buf, order);
>  }
> @@ -614,11 +632,71 @@ static inline void xen_console_write_debug_port(const char *buf, size_t len)
>  }
>  #endif
>  
> +static inline void console_debug_puts(const char *str, size_t len)
> +{
> +#ifdef CONFIG_X86
> +    if ( opt_console_xen )
> +    {
> +        if ( xen_guest )
> +            xen_hypercall_console_write(str, len);
> +        else
> +            xen_console_write_debug_port(str, len);
> +    }
> +#endif
> +}
> +
> +/*
> + * Send a message on console device(s).
> + *
> + * That will handle all possible scenarios working w/ console
> + * - physical console (serial console, VGA console (x86 only));
> + * - PV console;
> + * - debug console (x86 only): debug I/O port or __HYPERVISOR_console_io
> + *   hypercall;
> + * - console ring.
> + */
> +static void console_send(const char *str, size_t len, unsigned int flags)
> +{
> +    if ( flags & CONSOLE_SERIAL )
> +        console_serial_puts(str, len);
> +
> +    if ( flags & CONSOLE_PV )
> +        pv_console_puts(str, len);
> +
> +    if ( flags & CONSOLE_VIDEO )
> +        video_puts(str, len);
> +
> +    if ( flags & CONSOLE_DEBUG )
> +        console_debug_puts(str, len);
> +
> +    if ( flags & CONSOLE_RING )
> +    {
> +        conring_puts(str, len);
> +
> +        if ( flags & CONSOLE_RING_VIRQ )
> +            tasklet_schedule(&conring_tasklet);
> +    }
> +}
> +
> +static inline void __putstr(const char *str)
> +{
> +    unsigned int flags = CONSOLE_ALL;
> +
> +    ASSERT(rspin_is_locked(&console_lock));
> +
> +    if ( conring_no_notify )
> +        flags &= ~CONSOLE_RING_VIRQ;
> +
> +    console_send(str, strlen(str), flags);
> +}
> +
>  static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>                                  unsigned int count)
>  {
>      char kbuf[128];
>      unsigned int kcount = 0;
> +    unsigned int flags = opt_console_to_ring
> +                         ? CONSOLE_ALL : CONSOLE_DEFAULT;
>      struct domain *cd = current->domain;
>  
>      while ( count > 0 )
> @@ -636,26 +714,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>          {
>              /* Use direct console output as it could be interactive */
>              nrspin_lock_irq(&console_lock);
> -
> -            console_serial_puts(kbuf, kcount);
> -            video_puts(kbuf, kcount);
> -
> -#ifdef CONFIG_X86
> -            if ( opt_console_xen )
> -            {
> -                if ( xen_guest )
> -                    xen_hypercall_console_write(kbuf, kcount);
> -                else
> -                    xen_console_write_debug_port(kbuf, kcount);
> -            }
> -#endif
> -
> -            if ( opt_console_to_ring )
> -            {
> -                conring_puts(kbuf, kcount);
> -                tasklet_schedule(&conring_tasklet);
> -            }
> -
> +            console_send(kbuf, kcount, flags);
>              nrspin_unlock_irq(&console_lock);
>          }
>          else
> @@ -756,30 +815,6 @@ long do_console_io(
>   * *****************************************************
>   */
>  
> -static void __putstr(const char *str)
> -{
> -    size_t len = strlen(str);
> -
> -    ASSERT(rspin_is_locked(&console_lock));
> -
> -    console_serial_puts(str, len);
> -    video_puts(str, len);
> -
> -#ifdef CONFIG_X86
> -    if ( opt_console_xen )
> -    {
> -        if ( xen_guest )
> -            xen_hypercall_console_write(str, len);
> -        else
> -            xen_console_write_debug_port(str, len);
> -    }
> -#endif
> -
> -    conring_puts(str, len);
> -    if ( !conring_no_notify )
> -        tasklet_schedule(&conring_tasklet);
> -}
> -
>  static int printk_prefix_check(char *p, char **pp)
>  {
>      int loglvl = -1;
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Mon May 19 23:29:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 23:29:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990368.1374324 (Exim 4.92)
	(envelope-from )
	id 1uH9uz-0004cv-Au; Mon, 19 May 2025 23:29:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990368.1374324; Mon, 19 May 2025 23: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 1uH9uz-0004co-8J; Mon, 19 May 2025 23:29:13 +0000
Received: by outflank-mailman (input) for mailman id 990368;
 Mon, 19 May 2025 23:29:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uH9uy-0004c9-80
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 23:29:12 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 10b29514-3509-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 01:29:10 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id EE9585C566A;
 Mon, 19 May 2025 23:26:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C35EC4CEE4;
 Mon, 19 May 2025 23:29: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" 
X-Inumbo-ID: 10b29514-3509-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747697348;
	bh=pLdSU8aYNSRM4c6HfUiNt4SomeBz/h9Ae2mnyku9/os=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=XFGVaOhtQYLphp/zN5dRmroygyvG1Bb8rztCX44948LibrHcFUEBsfEDy11BRQa8w
	 NQTp5nZOtqyCTIRKcFuwH6Ytgt4krah23NSC3oFgNdwJyCARCJKUkYwMXFt/wVfVDd
	 MQesvTXArG617zV0dzH2yaUeZIgVnCvrO/Yc03V8jdKOa6CVu5Z62CE6w6wwlCS9m7
	 wdvzZzViLipyLJYb7H0IvONSMNvXHx0aX1S1hJUESe1AR3ekjMmXoVSykSFZ0t2Gjv
	 6BhaB/U7wimz6Zc2QfcgW/XlXmyDSxD5KT1gluqbxglpFCxn3mH+8rOEhApcFgNJV1
	 vw/o8TxGQLcnw==
Date: Mon, 19 May 2025 16:29:05 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
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?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 2/8] xen/arm: scmi-smc: update to be used under
 sci subsystem
In-Reply-To: <21bdecf961b60fb0094b1f722444a45228aef878.1747669845.git.oleksii_moisieiev@epam.com>
Message-ID: 
References:  <21bdecf961b60fb0094b1f722444a45228aef878.1747669845.git.oleksii_moisieiev@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> From: Grygorii Strashko 
> 
> The introduced SCI (System Control Interface) subsystem provides unified
> interface to integrate in Xen SCI drivers which adds support for ARM
> firmware (EL3, SCP) based software interfaces (like SCMI) that are used in
> system management. The SCI subsystem allows to add drivers for different FW
> interfaces or have different drivers for the same FW interface (for example,
> SCMI with different transports).
> 
> This patch updates SCMI over SMC calls handling layer, introduced by
> commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls handling
> layer"), to be SCI driver:
> - convert to DT device;
> - convert to SCI Xen interface.
> 
> There are no functional changes in general, the driver is just adopted
> to the SCI interface.
> 
> Signed-off-by: Grygorii Strashko 
> Signed-off-by: Oleksii Moisieiev 

Reviewed-by: Stefano Stabellini 


> ---
> 
> 
> 
>  xen/arch/arm/firmware/Kconfig                | 13 ++-
>  xen/arch/arm/firmware/scmi-smc.c             | 93 +++++++++++---------
>  xen/arch/arm/include/asm/firmware/scmi-smc.h | 41 ---------
>  xen/arch/arm/vsmc.c                          |  5 +-
>  xen/include/public/arch-arm.h                |  1 +
>  5 files changed, 64 insertions(+), 89 deletions(-)
>  delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h
> 
> diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
> index fc7918c7fc..bbf88fbb9a 100644
> --- a/xen/arch/arm/firmware/Kconfig
> +++ b/xen/arch/arm/firmware/Kconfig
> @@ -8,9 +8,18 @@ config ARM_SCI
>  
>  menu "Firmware Drivers"
>  
> +choice
> +	prompt "ARM SCI driver type"
> +	default SCMI_SMC
> +	help
> +	Choose which ARM SCI driver to enable.
> +
> +config ARM_SCI_NONE
> +	bool "none"
> +
>  config SCMI_SMC
>  	bool "Forward SCMI over SMC calls from hwdom to EL3 firmware"
> -	default y
> +	select ARM_SCI
>  	help
>  	  This option enables basic awareness for SCMI calls using SMC as
>  	  doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
> @@ -18,4 +27,6 @@ config SCMI_SMC
>  	  firmware node is used to trap and forward corresponding SCMI SMCs
>  	  to firmware running at EL3, for calls coming from the hardware domain.
>  
> +endchoice
> +
>  endmenu
> diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
> index 33473c04b1..13d1137592 100644
> --- a/xen/arch/arm/firmware/scmi-smc.c
> +++ b/xen/arch/arm/firmware/scmi-smc.c
> @@ -9,6 +9,7 @@
>   * Copyright 2024 NXP
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -16,12 +17,11 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
> -#include 
>  
>  #define SCMI_SMC_ID_PROP   "arm,smc-id"
>  
> -static bool __ro_after_init scmi_enabled;
>  static uint32_t __ro_after_init scmi_smc_id;
>  
>  /*
> @@ -41,14 +41,11 @@ static bool scmi_is_valid_smc_id(uint32_t fid)
>   *
>   * Returns true if SMC was handled (regardless of response), false otherwise.
>   */
> -bool scmi_handle_smc(struct cpu_user_regs *regs)
> +static bool scmi_handle_smc(struct cpu_user_regs *regs)
>  {
>      uint32_t fid = (uint32_t)get_user_reg(regs, 0);
>      struct arm_smccc_res res;
>  
> -    if ( !scmi_enabled )
> -        return false;
> -
>      if ( !scmi_is_valid_smc_id(fid) )
>          return false;
>  
> @@ -78,49 +75,45 @@ bool scmi_handle_smc(struct cpu_user_regs *regs)
>      return true;
>  }
>  
> -static int __init scmi_check_smccc_ver(void)
> +static int scmi_smc_domain_init(struct domain *d,
> +                                struct xen_domctl_createdomain *config)
>  {
> -    if ( smccc_ver < ARM_SMCCC_VERSION_1_1 )
> -    {
> -        printk(XENLOG_WARNING
> -               "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled\n");
> -        return -ENOSYS;
> -    }
> +    if ( !is_hardware_domain(d) )
> +        return 0;
>  
> +    d->arch.sci_enabled = true;
> +    printk(XENLOG_DEBUG "SCMI: %pd init\n", d);
>      return 0;
>  }
>  
> -static int __init scmi_dt_init_smccc(void)
> +static void scmi_smc_domain_destroy(struct domain *d)
>  {
> -    static const struct dt_device_match scmi_ids[] __initconst =
> -    {
> -        /* We only support "arm,scmi-smc" binding for now */
> -        DT_MATCH_COMPATIBLE("arm,scmi-smc"),
> -        { /* sentinel */ },
> -    };
> -    const struct dt_device_node *scmi_node;
> -    int ret;
> +    if ( !is_hardware_domain(d) )
> +        return;
>  
> -    /* If no SCMI firmware node found, fail silently as it's not mandatory */
> -    scmi_node = dt_find_matching_node(NULL, scmi_ids);
> -    if ( !scmi_node )
> -        return -EOPNOTSUPP;
> +    printk(XENLOG_DEBUG "SCMI: %pd destroy\n", d);
> +}
>  
> -    ret = dt_property_read_u32(scmi_node, SCMI_SMC_ID_PROP, &scmi_smc_id);
> -    if ( !ret )
> +static int __init scmi_check_smccc_ver(void)
> +{
> +    if ( smccc_ver < ARM_SMCCC_VERSION_1_1 )
>      {
> -        printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT node\n",
> -               SCMI_SMC_ID_PROP, scmi_node->full_name);
> -        return -ENOENT;
> +        printk(XENLOG_WARNING
> +               "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled\n");
> +        return -ENOSYS;
>      }
>  
> -    scmi_enabled = true;
> -
>      return 0;
>  }
>  
> +static const struct sci_mediator_ops scmi_smc_ops = {
> +    .handle_call = scmi_handle_smc,
> +    .domain_init = scmi_smc_domain_init,
> +    .domain_destroy = scmi_smc_domain_destroy,
> +};
> +
>  /* Initialize the SCMI layer based on SMCs and Device-tree */
> -static int __init scmi_init(void)
> +static int __init scmi_dom0_init(struct dt_device_node *dev, const void *data)
>  {
>      int ret;
>  
> @@ -134,22 +127,36 @@ static int __init scmi_init(void)
>      if ( ret )
>          return ret;
>  
> -    ret = scmi_dt_init_smccc();
> -    if ( ret == -EOPNOTSUPP )
> -        return ret;
> +    ret = dt_property_read_u32(dev, SCMI_SMC_ID_PROP, &scmi_smc_id);
> +    if ( !ret )
> +    {
> +        printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT node\n",
> +               SCMI_SMC_ID_PROP, dt_node_full_name(dev));
> +        return -ENOENT;
> +    }
> +
> +    ret = sci_register(&scmi_smc_ops);
>      if ( ret )
> -        goto err;
> +    {
> +        printk(XENLOG_ERR "SCMI: mediator already registered (ret = %d)\n",
> +               ret);
> +        return ret;
> +    }
>  
>      printk(XENLOG_INFO "Using SCMI with SMC ID: 0x%x\n", scmi_smc_id);
>  
>      return 0;
> -
> - err:
> -    printk(XENLOG_ERR "SCMI: Initialization failed (ret = %d)\n", ret);
> -    return ret;
>  }
>  
> -__initcall(scmi_init);
> +static const struct dt_device_match scmi_smc_match[] __initconst = {
> +    DT_MATCH_COMPATIBLE("arm,scmi-smc"),
> +    { /* sentinel */ },
> +};
> +
> +DT_DEVICE_START(scmi_smc, "SCMI SMC DOM0", DEVICE_FIRMWARE)
> +    .dt_match = scmi_smc_match,
> +    .init = scmi_dom0_init,
> +DT_DEVICE_END
>  
>  /*
>   * Local variables:
> diff --git a/xen/arch/arm/include/asm/firmware/scmi-smc.h b/xen/arch/arm/include/asm/firmware/scmi-smc.h
> deleted file mode 100644
> index 6b1a164a40..0000000000
> --- a/xen/arch/arm/include/asm/firmware/scmi-smc.h
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -/*
> - * xen/arch/arm/include/asm/firmware/scmi-smc.h
> - *
> - * ARM System Control and Management Interface (SCMI) over SMC
> - * Generic handling layer
> - *
> - * Andrei Cherechesu 
> - * Copyright 2024 NXP
> - */
> -
> -#ifndef __ASM_SCMI_SMC_H__
> -#define __ASM_SCMI_SMC_H__
> -
> -#include 
> -
> -struct cpu_user_regs;
> -
> -#ifdef CONFIG_SCMI_SMC
> -
> -bool scmi_handle_smc(struct cpu_user_regs *regs);
> -
> -#else
> -
> -static inline bool scmi_handle_smc(struct cpu_user_regs *regs)
> -{
> -    return false;
> -}
> -
> -#endif /* CONFIG_SCMI_SMC */
> -
> -#endif /* __ASM_SCMI_H__ */
> -
> -/*
> - * Local variables:
> - * mode: C
> - * c-file-style: "BSD"
> - * c-basic-offset: 4
> - * indent-tabs-mode: nil
> - * End:
> - */
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 51b3c02973..b33c69a1c2 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -21,7 +21,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  /* Number of functions currently supported by Hypervisor Service. */
>  #define XEN_SMCCC_FUNCTION_COUNT 3
> @@ -233,7 +232,7 @@ static bool handle_sip(struct cpu_user_regs *regs)
>      if ( platform_smc(regs) )
>          return true;
>  
> -    return scmi_handle_smc(regs);
> +    return sci_handle_call(regs);
>  }
>  
>  /*
> @@ -301,8 +300,6 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
>              break;
>          case ARM_SMCCC_OWNER_SIP:
>              handled = handle_sip(regs);
> -            if ( !handled )
> -                handled = sci_handle_call(regs);
>              break;
>          case ARM_SMCCC_OWNER_TRUSTED_APP ... ARM_SMCCC_OWNER_TRUSTED_APP_END:
>          case ARM_SMCCC_OWNER_TRUSTED_OS ... ARM_SMCCC_OWNER_TRUSTED_OS_END:
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 55eed9992c..095b1a23e3 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -328,6 +328,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
>  #define XEN_DOMCTL_CONFIG_TEE_FFA       2
>  
>  #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE      0
> +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC  1
>  
>  struct xen_arch_domainconfig {
>      /* IN/OUT */
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Mon May 19 23:46:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 19 May 2025 23:46:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990376.1374335 (Exim 4.92)
	(envelope-from )
	id 1uHABC-0007Ov-L2; Mon, 19 May 2025 23:45:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990376.1374335; Mon, 19 May 2025 23:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHABC-0007Oo-IK; Mon, 19 May 2025 23:45:58 +0000
Received: by outflank-mailman (input) for mailman id 990376;
 Mon, 19 May 2025 23:45:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHABB-0007Oh-A4
 for xen-devel@lists.xenproject.org; Mon, 19 May 2025 23:45:57 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 67312efc-350b-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 01:45:54 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 79A2961120;
 Mon, 19 May 2025 23:45:53 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 797F6C4CEEB;
 Mon, 19 May 2025 23: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" 
X-Inumbo-ID: 67312efc-350b-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747698353;
	bh=yoqX8B6ldnLpDlSDOQ5Vatb8SMeCi4qN5BARC4x5qnw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=cbJADzsuE984dUrExhAahEPWCQ3FcR60ZmreQVCPr/c+cue4HsM5rVl6yrvstFQsI
	 Sp5bXjoirmbOjQJV7v5A0SxIXFwE60BTLvAXDQG+4rbyU/+w4Z4vjabpEq6kAstniA
	 O+genAbFdQaznOA3rr6AobQ1CIPXCrCDlMvU8kbyqOJOoLinwb7StPM0LpMN1VqLUg
	 BmuxhwKD9WVA/VlYZOa930ug4C3bDvYtbS3z52SYkBu+ZNvbw/Gir0AM22aFA9bLHG
	 TEAXkF1qXVFfn4as4nAMtidazz3NJWccjoOdnuAQvqeQrhyt2CjmAhH7Iv0BMP5CdP
	 kh7yGL+EnVv/g==
Date: Mon, 19 May 2025 16:45:50 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
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?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 1/8] xen/arm: add generic SCI subsystem
In-Reply-To: <48b70b34c576d8dfcf6156d1997bc3c0f7cbbceb.1747669845.git.oleksii_moisieiev@epam.com>
Message-ID: 
References:  <48b70b34c576d8dfcf6156d1997bc3c0f7cbbceb.1747669845.git.oleksii_moisieiev@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> This patch adds the basic framework for ARM SCI mediator. SCI is System
> Control Interface, which is designed to redirect requests from the Domains
> to ARM specific Firmware (for example SCMI). This will allow the devices,
> passed-through to the different Domains, to access to the System resources
> (such as clocks/resets etc) by sending requests to the firmware.
> 
> ARM SCI subsystem allows to implement different SCI drivers to handle
> specific ARM firmware interfaces (like ARM SCMI) and mediate requests
> between the Domains and the Firmware. Also it allows SCI drivers to perform
> proper action during Domain creation/destruction which is vital for
> handling use cases like Domain reboot.
> 
> This patch introduces new DEVICE_FIRMWARE device subclass for probing SCI
> drivers basing on device tree, SCI drivers register itself with
> DT_DEVICE_START/END macro. On init - the SCI drivers should register its
> SCI ops with sci_register(). Only one SCI driver can be supported.
> 
> At run-time, the following SCI API calls are introduced:
> 
> - sci_domain_sanitise_config() called from arch_sanitise_domain_config()
> - sci_domain_init() called from arch_domain_create()
> - sci_relinquish_resources() called from domain_relinquish_resources()
> - sci_domain_destroy() called from arch_domain_destroy()
> - sci_handle_call() called from vsmccc_handle_call()
> - sci_dt_handle_node()
>   sci_dt_finalize() called from handle_node() (Dom0 DT)
> 
> Signed-off-by: Oleksii Moisieiev 
> Signed-off-by: Grygorii Strashko 

This patch needs a pretty major rebase. But the looks OK to me.

Reviewed-by: Stefano Stabellini 


> ---
> 
> Changes in v4:
> - fix SPDX-License
> - rename DEVICE_ARM_SCI DT device class to FIRMWARE_DEVICE
> - move XEN_DOMCTL_assign_device code in separate patch
> - Add documentation for SCI SCMI drivers
> 
>  MAINTAINERS                             |   6 +
>  xen/arch/arm/device.c                   |   5 +
>  xen/arch/arm/dom0less-build.c           |   7 +
>  xen/arch/arm/domain.c                   |  12 +-
>  xen/arch/arm/domain_build.c             |   8 +
>  xen/arch/arm/firmware/Kconfig           |   8 +
>  xen/arch/arm/firmware/Makefile          |   1 +
>  xen/arch/arm/firmware/sci.c             | 154 ++++++++++++++++++
>  xen/arch/arm/include/asm/domain.h       |   5 +
>  xen/arch/arm/include/asm/firmware/sci.h | 200 ++++++++++++++++++++++++
>  xen/arch/arm/vsmc.c                     |   3 +
>  xen/include/asm-generic/device.h        |   1 +
>  xen/include/public/arch-arm.h           |   4 +
>  13 files changed, 413 insertions(+), 1 deletion(-)
>  create mode 100644 xen/arch/arm/firmware/sci.c
>  create mode 100644 xen/arch/arm/include/asm/firmware/sci.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c11b82eca9..f5e3c48b96 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -507,6 +507,12 @@ R:	George Dunlap 
>  S:	Supported
>  F:	xen/common/sched/
>  
> +SCI MEDIATORS
> +M:	Oleksii Moisieiev 
> +S:	Supported
> +F:	xen/arch/arm/firmware/sci.c
> +F:	xen/arch/arm/include/asm/firmware/sci.h
> +
>  SEABIOS UPSTREAM
>  M:	Wei Liu 
>  S:	Supported
> diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
> index 5610cddcba..bdab96a408 100644
> --- a/xen/arch/arm/device.c
> +++ b/xen/arch/arm/device.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  
>  int map_irq_to_domain(struct domain *d, unsigned int irq,
> @@ -303,6 +304,10 @@ int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
>                  return res;
>              }
>          }
> +
> +        res = sci_assign_dt_device(d, dev);
> +        if ( res )
> +            return res;
>      }
>  
>      res = map_device_irqs_to_domain(d, dev, own_device, irq_ranges);
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index 49d1f14d65..a09c4c4bd7 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -321,6 +322,10 @@ static int __init handle_passthrough_prop(struct kernel_info *kinfo,
>          return -EINVAL;
>      }
>  
> +    res = sci_assign_dt_device(kinfo->d, node);
> +    if ( res )
> +        return res;
> +
>      res = map_device_irqs_to_domain(kinfo->d, node, true, NULL);
>      if ( res < 0 )
>          return res;
> @@ -970,6 +975,8 @@ void __init create_domUs(void)
>          if ( !llc_coloring_enabled && llc_colors_str )
>              panic("'llc-colors' found, but LLC coloring is disabled\n");
>  
> +        d_cfg.arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
> +
>          /*
>           * The variable max_init_domid is initialized with zero, so here it's
>           * very important to use the pre-increment operator to call
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 3ba959f866..652aeb7a55 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -694,7 +695,7 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>          return -EINVAL;
>      }
>  
> -    return 0;
> +    return sci_domain_sanitise_config(config);
>  }
>  
>  int arch_domain_create(struct domain *d,
> @@ -786,6 +787,9 @@ int arch_domain_create(struct domain *d,
>      d->arch.sve_vl = config->arch.sve_vl;
>  #endif
>  
> +    if ( (rc = sci_domain_init(d, config)) != 0 )
> +        goto fail;
> +
>      return 0;
>  
>  fail:
> @@ -846,6 +850,7 @@ void arch_domain_destroy(struct domain *d)
>      domain_vgic_free(d);
>      domain_vuart_free(d);
>      free_xenheap_page(d->shared_info);
> +    sci_domain_destroy(d);
>  #ifdef CONFIG_ACPI
>      free_xenheap_pages(d->arch.efi_acpi_table,
>                         get_order_from_bytes(d->arch.efi_acpi_len));
> @@ -1039,6 +1044,7 @@ enum {
>      PROG_p2m_root,
>      PROG_p2m,
>      PROG_p2m_pool,
> +    PROG_sci,
>      PROG_done,
>  };
>  
> @@ -1098,6 +1104,10 @@ int domain_relinquish_resources(struct domain *d)
>          ret = relinquish_p2m_mapping(d);
>          if ( ret )
>              return ret;
> +    PROGRESS(sci):
> +        ret = sci_relinquish_resources(d);
> +        if ( ret )
> +            return ret;
>  
>      PROGRESS(p2m_root):
>          /*
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7b47abade1..36d28b52a4 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1888,6 +1889,9 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
>          return 0;
>      }
>  
> +    if ( sci_dt_handle_node(d, node) )
> +        return 0;
> +
>      /*
>       * The vGIC does not support routing hardware PPIs to guest. So
>       * we need to skip any node using PPIs.
> @@ -1988,6 +1992,10 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
>          if ( res )
>              return res;
>  
> +        res = sci_dt_finalize(d, kinfo->fdt);
> +        if ( res )
> +            return res;
> +
>          /*
>           * Create a second memory node to store the ranges covering
>           * reserved-memory regions.
> diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
> index 817da745fd..fc7918c7fc 100644
> --- a/xen/arch/arm/firmware/Kconfig
> +++ b/xen/arch/arm/firmware/Kconfig
> @@ -1,3 +1,11 @@
> +config ARM_SCI
> +	bool
> +	depends on ARM
> +	help
> +	  This option enables generic Arm SCI (System Control Interface) mediators
> +	  support. It allows domains to control system resources via one of
> +	  Arm SCI mediators drivers implemented in XEN, like SCMI.
> +
>  menu "Firmware Drivers"
>  
>  config SCMI_SMC
> diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile
> index a5e4542666..71bdefc24a 100644
> --- a/xen/arch/arm/firmware/Makefile
> +++ b/xen/arch/arm/firmware/Makefile
> @@ -1 +1,2 @@
> +obj-$(CONFIG_ARM_SCI) += sci.o
>  obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
> diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
> new file mode 100644
> index 0000000000..e1522e10e2
> --- /dev/null
> +++ b/xen/arch/arm/firmware/sci.c
> @@ -0,0 +1,154 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Generic part of the SCI (System Control Interface) subsystem.
> + *
> + * Oleksii Moisieiev 
> + * Copyright (c) 2025 EPAM Systems
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +static const struct sci_mediator_ops __read_mostly *cur_mediator;
> +
> +int sci_register(const struct sci_mediator_ops *ops)
> +{
> +    if ( cur_mediator )
> +        return -EEXIST;
> +
> +    if ( !ops->domain_init || !ops->domain_destroy || !ops->handle_call )
> +        return -EINVAL;
> +
> +    cur_mediator = ops;
> +
> +    return 0;
> +};
> +
> +bool sci_handle_call(struct cpu_user_regs *args)
> +{
> +    if ( unlikely(!cur_mediator) )
> +        return false;
> +
> +    return cur_mediator->handle_call(args);
> +}
> +
> +int sci_domain_init(struct domain *d, struct xen_domctl_createdomain *config)
> +{
> +    if ( !cur_mediator )
> +        return 0;
> +
> +    return cur_mediator->domain_init(d, config);
> +}
> +
> +int sci_domain_sanitise_config(struct xen_domctl_createdomain *config)
> +{
> +    if ( !cur_mediator )
> +        return 0;
> +
> +    if ( !cur_mediator->domain_sanitise_config )
> +        return 0;
> +
> +    return cur_mediator->domain_sanitise_config(config);
> +}
> +
> +void sci_domain_destroy(struct domain *d)
> +{
> +    if ( !cur_mediator )
> +        return;
> +
> +    cur_mediator->domain_destroy(d);
> +}
> +
> +int sci_relinquish_resources(struct domain *d)
> +{
> +    if ( !cur_mediator )
> +        return 0;
> +
> +    if ( !cur_mediator->relinquish_resources )
> +        return 0;
> +
> +    return cur_mediator->relinquish_resources(d);
> +}
> +
> +bool sci_dt_handle_node(struct domain *d, struct dt_device_node *node)
> +{
> +    if ( !cur_mediator )
> +        return 0;
> +
> +    if ( !cur_mediator->dom0_dt_handle_node )
> +        return 0;
> +
> +    return cur_mediator->dom0_dt_handle_node(d, node);
> +}
> +
> +int sci_dt_finalize(struct domain *d, void *fdt)
> +{
> +    if ( !cur_mediator )
> +        return 0;
> +
> +    if ( !cur_mediator->dom0_dt_finalize )
> +        return 0;
> +
> +    return cur_mediator->dom0_dt_finalize(d, fdt);
> +}
> +
> +int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
> +{
> +    struct dt_phandle_args ac_spec;
> +    int index = 0;
> +    int ret;
> +
> +    if ( !cur_mediator )
> +        return 0;
> +
> +    if ( !cur_mediator->assign_dt_device )
> +        return 0;
> +
> +    while ( !dt_parse_phandle_with_args(dev, "access-controllers",
> +                                        "#access-controller-cells", index,
> +                                        &ac_spec) )
> +    {
> +        printk(XENLOG_DEBUG "sci: assign device %s to %pd\n",
> +               dt_node_full_name(dev), d);
> +
> +        ret = cur_mediator->assign_dt_device(d, &ac_spec);
> +        if ( ret )
> +            return ret;
> +
> +        index++;
> +    }
> +
> +    return 0;
> +}
> +
> +static int __init sci_init(void)
> +{
> +    struct dt_device_node *np;
> +    unsigned int num_sci = 0;
> +    int rc;
> +
> +    dt_for_each_device_node(dt_host, np)
> +    {
> +        rc = device_init(np, DEVICE_FIRMWARE, NULL);
> +        if ( !rc && num_sci )
> +        {
> +            printk(XENLOG_ERR
> +                   "SCMI: Only one SCI controller is supported. found second %s\n",
> +                   np->name);
> +            return -EOPNOTSUPP;
> +        }
> +        else if ( !rc )
> +            num_sci++;
> +        else if ( rc != -EBADF && rc != -ENODEV )
> +            return rc;
> +    }
> +
> +    return 0;
> +}
> +
> +__initcall(sci_init);
> diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
> index f1d72c6e48..fa0898b7cf 100644
> --- a/xen/arch/arm/include/asm/domain.h
> +++ b/xen/arch/arm/include/asm/domain.h
> @@ -118,6 +118,11 @@ struct arch_domain
>  #ifdef CONFIG_TEE
>      void *tee;
>  #endif
> +#ifdef CONFIG_ARM_SCI
> +    bool sci_enabled;
> +    /* ARM SCI driver's specific data */
> +    void *sci_data;
> +#endif
>  
>  }  __cacheline_aligned;
>  
> diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include/asm/firmware/sci.h
> new file mode 100644
> index 0000000000..71fb54852e
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/firmware/sci.h
> @@ -0,0 +1,200 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Generic ARM SCI (System Control Interface) subsystem.
> + *
> + * Oleksii Moisieiev 
> + * Copyright (c) 2025 EPAM Systems
> + */
> +
> +#ifndef __ASM_ARM_SCI_H
> +#define __ASM_ARM_SCI_H
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#ifdef CONFIG_ARM_SCI
> +
> +struct sci_mediator_ops {
> +    /*
> +     * Called during domain construction. If it is requested to enable
> +     * SCI support, so SCI driver can create own structures for the new domain
> +     * and inform firmware about new domain (if required).
> +     * Mandatory.
> +     */
> +    int (*domain_init)(struct domain *d,
> +                       struct xen_domctl_createdomain *config);
> +
> +    /*
> +     * Called during domain construction. The SCI driver uses
> +     * it to sanitize domain SCI configuration parameters.
> +     * Optional.
> +     */
> +    int (*domain_sanitise_config)(struct xen_domctl_createdomain *config);
> +
> +    /*
> +     * Called during domain destruction, releases all resources, that
> +     * were allocated for domain.
> +     * Mandatory.
> +     */
> +    void (*domain_destroy)(struct domain *d);
> +
> +    /*
> +     * Called during domain destruction to relinquish resources used
> +     * by SCI driver itself and request resources releasing from firmware.
> +     * Optional.
> +     */
> +    int (*relinquish_resources)(struct domain *d);
> +
> +    /* SMC/HVC Handle callback */
> +    bool (*handle_call)(struct cpu_user_regs *regs);
> +
> +    /*
> +     * Dom0 DT nodes handling callback so SCI driver can detect DT nodes it
> +     * need to handle and decide if those nodes need to be provided to Dom0.
> +     * Optional.
> +     */
> +    bool (*dom0_dt_handle_node)(struct domain *d, struct dt_device_node *node);
> +
> +    /*
> +     * SCI driver callback called at the end of Dom0 DT generation, so
> +     * it can perform steps to modify DT to enable/disable SCI
> +     * functionality for Dom0.
> +     */
> +    int (*dom0_dt_finalize)(struct domain *d, void *fdt);
> +
> +    /*
> +     * SCI driver callback called when DT device is passed through to guest,
> +     * so SCI driver can enable device access to the domain if SCI FW provides
> +     * Device specific access control functionality.
> +     * Optional.
> +     */
> +    int (*assign_dt_device)(struct domain *d, struct dt_phandle_args *ac_spec);
> +};
> +
> +
> +static inline bool sci_domain_is_enabled(struct domain *d)
> +{
> +    return d->arch.sci_enabled;
> +}
> +
> +/*
> + * Register SCI subsystem ops.
> + *
> + * Register SCI drivers operation and so enable SCI functionality.
> + * Only one SCI driver is supported.
> + */
> +int sci_register(const struct sci_mediator_ops *ops);
> +
> +/*
> + * Initialize SCI functionality for domain if configured.
> + *
> + * Initialization routine to enable SCI functionality for the domain.
> + * The SCI configuration data and decision about enabling SCI functionality
> + * for the domain is SCI driver specific.
> + */
> +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);
> +
> +/*
> + * Destroy SCI domain instance.
> + */
> +void sci_domain_destroy(struct domain *d);
> +
> +/*
> + * Free resources assigned to the certain domain.
> + */
> +int sci_relinquish_resources(struct domain *d);
> +
> +/*
> + * SMC/HVC Handle callback.
> + *
> + * SCI driver acts as SMC/HVC server for the registered domains and
> + * does redirection of the domain calls to the SCI firmware,
> + * such as ARM TF-A or similar.
> + */
> +bool sci_handle_call(struct cpu_user_regs *regs);
> +
> +/*
> + * Dom0 DT nodes handling function.
> + *
> + * Allows SCI driver to detect DT nodes it need to handle and decide if
> + * those nodes need to be provided to Dom0.
> + */
> +bool sci_dt_handle_node(struct domain *d, struct dt_device_node *node);
> +
> +/*
> + * Dom0 DT generation finalize.
> + *
> + * Called at the end of Dom0 DT generation, so SCI driver can perform steps
> + * to modify DT to enable/disable SCI functionality for Dom0.
> + */
> +int sci_dt_finalize(struct domain *d, void *fdt);
> +
> +/*
> + * Assign DT device to domain.
> + *
> + * Called when DT device is passed through to guest, so SCI driver can enable
> + * device access to the domain if SCI FW provides "Device specific access
> + * control" functionality.
> + */
> +int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev);
> +#else
> +
> +static inline bool sci_domain_is_enabled(struct domain *d)
> +{
> +    return false;
> +}
> +
> +static inline int sci_domain_init(struct domain *d,
> +                                  struct xen_domctl_createdomain *config)
> +{
> +    return 0;
> +}
> +
> +static inline int
> +sci_domain_sanitise_config(struct xen_domctl_createdomain *config)
> +{
> +    return 0;
> +}
> +
> +static inline void sci_domain_destroy(struct domain *d)
> +{}
> +
> +static inline int sci_relinquish_resources(struct domain *d)
> +{
> +    return 0;
> +}
> +
> +static inline bool sci_handle_call(struct cpu_user_regs *args)
> +{
> +    return false;
> +}
> +
> +static inline bool sci_dt_handle_node(struct domain *d,
> +                                      struct dt_device_node *node)
> +{
> +    return false;
> +}
> +
> +static inline int sci_dt_finalize(struct domain *d, void *fdt)
> +{
> +    return false;
> +}
> +
> +static inline int sci_assign_dt_device(struct domain *d,
> +                                       struct dt_device_node *dev)
> +{
> +    return 0;
> +}
> +
> +#endif /* CONFIG_ARM_SCI */
> +
> +#endif /* __ASM_ARM_SCI_H */
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 62d8117a12..51b3c02973 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -300,6 +301,8 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
>              break;
>          case ARM_SMCCC_OWNER_SIP:
>              handled = handle_sip(regs);
> +            if ( !handled )
> +                handled = sci_handle_call(regs);
>              break;
>          case ARM_SMCCC_OWNER_TRUSTED_APP ... ARM_SMCCC_OWNER_TRUSTED_APP_END:
>          case ARM_SMCCC_OWNER_TRUSTED_OS ... ARM_SMCCC_OWNER_TRUSTED_OS_END:
> diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/device.h
> index 1acd1ba1d8..e96c5558c2 100644
> --- a/xen/include/asm-generic/device.h
> +++ b/xen/include/asm-generic/device.h
> @@ -18,6 +18,7 @@ enum device_class
>      DEVICE_IOMMU,
>      DEVICE_INTERRUPT_CONTROLLER,
>      DEVICE_PCI_HOSTBRIDGE,
> +    DEVICE_FIRMWARE,
>      /* Use for error */
>      DEVICE_UNKNOWN,
>  };
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 24840eeaa6..55eed9992c 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -327,6 +327,8 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
>  #define XEN_DOMCTL_CONFIG_TEE_OPTEE     1
>  #define XEN_DOMCTL_CONFIG_TEE_FFA       2
>  
> +#define XEN_DOMCTL_CONFIG_ARM_SCI_NONE      0
> +
>  struct xen_arch_domainconfig {
>      /* IN/OUT */
>      uint8_t gic_version;
> @@ -350,6 +352,8 @@ struct xen_arch_domainconfig {
>       *
>       */
>      uint32_t clock_frequency;
> +    /* IN */
> +    uint8_t arm_sci_type;
>  };
>  #endif /* __XEN__ || __XEN_TOOLS__ */
>  
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Tue May 20 00:18:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 00:18:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990388.1374344 (Exim 4.92)
	(envelope-from )
	id 1uHAgZ-0003jV-En; Tue, 20 May 2025 00:18:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990388.1374344; Tue, 20 May 2025 00:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHAgZ-0003jO-Bc; Tue, 20 May 2025 00:18:23 +0000
Received: by outflank-mailman (input) for mailman id 990388;
 Tue, 20 May 2025 00:18:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHAgY-0003jG-14
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 00:18:22 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ee8d49db-350f-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 02:18:19 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 93496629E1;
 Tue, 20 May 2025 00:18:18 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61736C4CEE4;
 Tue, 20 May 2025 00:18: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" 
X-Inumbo-ID: ee8d49db-350f-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747700298;
	bh=eo49qYkCdGupD0ptDnkWoNVCxDnrHpHvItE8snA9NvU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=mdvAWqb+sy5Xt5cgvl3zUnSqnB2CTRKnB3wKQr2uoKZa3bs9V1pNX9t/YEcJpS14H
	 DixsGlCHqiBqUipcJsLqY3i1UlK/f6tsVvtdCh4jz+WHXMj7wIlcUpLYiYy6LzwZbu
	 b5UfBvp5SrLRx8WoEN5LNyjOIkhJyj166Q+mJhZrHlmYNC/71ZZZutFwuFXMF3tzBG
	 IFsvXfF/KrpY2FI+qcccPFTzSsujJIeyCfSYU5ZnT3hgBRIka73ZjmwrdlkEuSjhQC
	 oKP7JAFSAt7UMwxNY531ZWpRXAY9dwg9J1lWi/iP6ZqhH5OfOsEAm6ZgxdyLLvjehg
	 BtkXbdROqA9fA==
Date: Mon, 19 May 2025 17:18:14 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
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?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 3/8] xen/arm: scmi-smc: passthrough SCMI SMC to
 domain, single agent
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> From: Grygorii Strashko 
> 
> The commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls
> handling layer") introduces simple driver which forwards SCMI over SMC
> calls from hwdom/dom0 to EL3 firmware (TF-A) with a single SCMI OSPM agent
> support. While it is working gracefully for hwdom/dom0 use case it doesn't
> cover "thin Dom0 with guest domain, which serves as Driver domain"
> use-case. In this case HW need to be enable in Driver domain and dom0 is
> performing only control functions.
> 
> The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is
> pretty generic case for the default vendors SDK and new platforms.
> 
> This patch enables passthrough of SCMI SMC single agent interface to the
> one guest domain serving as Driver domain.
> 
> Configure Dom0 to enable SCMI passthrough:
> 
>  - dom0: add dom0_scmi_smc_passthrough to the Xen Command Line
> 
> Enabled SCMI passthrough for guest using toolstack in the following way:
> 
>  - domD: xl.cfg add "arm_sci" option as below
> 
>    arm_sci = "type=scmi_smc"
> 
>  - domD: xl.cfg enable access to the "arm,scmi-shmem"
> 
> iomem = [
>     "47ff0,1@22001",
> ]
> 
>  - domD: add SCMI nodes to the Driver domain partial device tree as in the
>  below example:
> 
> passthrough {
>    scmi_shm_0: sram@22001000 {
>        compatible = "arm,scmi-shmem";
>        reg = <0x0 0x22001000 0x0 0x1000>;
>    };
> 
>    firmware {
>         compatible = "simple-bus";
>             scmi: scmi {
>                 compatible = "arm,scmi-smc";
>                 shmem = <&scmi_shm_0>;
>                 ...
>             }
>     }
> }
> 
> dom0less case configuration:
> 
> - add "xen,sci_type" property for required DomU ("xen,domain") node
> 
>    xen,sci_type="scmi_smc"
> 
> - add scmi nodes to the Driver domain partial device tree the same way
> as above and enable access to the "arm,scmi-shmem" according to
> dom0less documentation. For example:
> 
>   scmi_shm_0: sram@22001000 {
>         compatible = "arm,scmi-shmem";
>         reg = <0x00 0x22001000 0x00 0x1000>;
> ->        xen,reg = <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>;
> ->        xen,force-assign-without-iommu;
>   };
> 
> The SCMI SMC single agent interface can be enabled for one and only one
> domain. In general, the configuration is similar to any other HW
> passthrough, except explicitly enabling SCMI with "arm_sci" xl.cfg option.
> 
> Note that "arm,scmi-smc" and "arm,scmi-shmem" nodes will be removed from
> dom0/hwdom DT in case of
> 
> Signed-off-by: Grygorii Strashko 
> Signed-off-by: Oleksii Moisieiev 
> ---
> 
> Changes in v4:
> - xl.cfg doc
> - fix comments from Stefano Stabellini
> - fix toolstack code as sugested by Anthony PERARD
>   - use MATCH_OPTION()
>   - move arm_sci struct and cfg params in "arch_arm"
> - add SCMI passthrough for dom0less case
> 
>  docs/man/xl.cfg.5.pod.in              |  34 ++++++++
>  docs/misc/arm/device-tree/booting.txt |  15 ++++
>  docs/misc/xen-command-line.pandoc     |   9 +++
>  tools/include/libxl.h                 |   5 ++
>  tools/libs/light/libxl_arm.c          |  14 ++++
>  tools/libs/light/libxl_types.idl      |  10 +++
>  tools/xl/xl_parse.c                   |  36 +++++++++
>  xen/arch/arm/dom0less-build.c         |  33 +++++++-
>  xen/arch/arm/firmware/Kconfig         |   4 +-
>  xen/arch/arm/firmware/scmi-smc.c      | 112 +++++++++++++++++++++++++-
>  10 files changed, 267 insertions(+), 5 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 8e1422104e..1ccf50b8ea 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -3092,6 +3092,40 @@ Otherwise, the value specified by the `nr_spis` parameter will be used.
>  The number of SPIs should match the highest interrupt ID that will be
>  assigned to the domain.
>  
> +=item B
> +
> +Set ARM_SCI specific options for the guest. ARM SCI is System
> +Control Protocol allows domain to manage various functions that are provided
> +by HW platform firmware.
> +
> +B is a comma separated list of C settings,
> +from the following list:
> +
> +=over 4
> +
> +=item B
> +
> +Specifies an ARM SCI type for the guest.
> +
> +=over 4
> +
> +=item B
> +
> +Don't allow guest to use ARM SCI if present on the platform. This is the
> +default value.
> +
> +=item B
> +
> +Enables ARM SCMI SMC support for the guest by enabling SCMI over SMC calls
> +forwarding from domain to the EL3 firmware (like Trusted Firmware-A) with a
> +single SCMI OSPM agent support.
> +Should be used together with B Xen command line
> +option.
> +
> +=back
> +
> +=back
> +
>  =back
>  
>  =head3 x86
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> index 9c881baccc..8943c04173 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -281,6 +281,21 @@ with the following properties:
>      passed through. This option is the default if this property is missing
>      and the user does not provide the device partial device tree for the domain.
>  
> +- xen,sci_type
> +
> +    A string property specifying an ARM SCI type for the guest.
> +
> +    - "none"
> +    Don't allow guest to use ARM SCI if present on the platform. This is the
> +    default value.
> +
> +    - "scmi_smc"
> +    Enables ARM SCMI SMC support for the guest by enabling SCMI over SMC calls
> +    forwarding from domain to the EL3 firmware (like Trusted Firmware-A) with a
> +    single SCMI OSPM agent support.
> +    Should be used together with dom0_scmi_smc_passthrough Xen command line
> +    option.
> +
>  Under the "xen,domain" compatible node, one or more sub-nodes are present
>  for the DomU kernel and ramdisk.
>  
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 9bbd00baef..8e50f6b7c7 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1082,6 +1082,15 @@ affinities to prefer but be not limited to the specified node(s).
>  
>  Pin dom0 vcpus to their respective pcpus
>  
> +### dom0_scmi_smc_passthrough (ARM)

Please rename this option because written like this is really confusing:
it makes me think we are passing through SCMI to Dom0, while actually it
is the opposite.

I would call this option something like "dom0_hide_scmi_smc" because the
only effect is to remove SCMI_SMC from Dom0. Other names might also be
OK, such as "scmi_smc_passthrough".


> +> `= `
> +
> +The option is available when `CONFIG_SCMI_SMC` is compiled in, and allows to
> +enable SCMI SMC single agent interface for any, but only one guest domain,
> +which serves as Driver domain. The SCMI will be disabled for Dom0/hwdom and
> +SCMI nodes removed from Dom0/hwdom device tree.
> +(for example, thin Dom0 with Driver domain use-case).
> +
>  ### dtuart (ARM)
>  > `= path [:options]`
>  
> diff --git a/tools/include/libxl.h b/tools/include/libxl.h
> index f8fe4afd7d..5fa43637ab 100644
> --- a/tools/include/libxl.h
> +++ b/tools/include/libxl.h
> @@ -313,6 +313,11 @@
>   */
>  #define LIBXL_HAVE_BUILDINFO_ARCH_NR_SPIS 1
>  
> +/*
> + * libxl_domain_build_info has the arch_arm.sci* fields.
> + */
> +#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_SCI 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 28cea1f643..28ba9eb787 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -222,6 +222,20 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>          config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
>      }
>  
> +    switch (d_config->b_info.arch_arm.arm_sci.type) {
> +    case LIBXL_ARM_SCI_TYPE_NONE:
> +        config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
> +        break;
> +    case LIBXL_ARM_SCI_TYPE_SCMI_SMC:
> +        config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
> +        break;
> +    default:
> +        LOG(ERROR, "Unknown ARM_SCI type %d",
> +            d_config->b_info.arch_arm.arm_sci.type);
> +        return ERROR_FAIL;
> +    }
> +    LOG(DEBUG, " - SCI type=%u", config->arch.arm_sci_type);
> +
>      return 0;
>  }
>  
> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
> index 33c9cfc1a2..aa2190ab5b 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -551,6 +551,15 @@ libxl_sve_type = Enumeration("sve_type", [
>      (2048, "2048")
>      ], init_val = "LIBXL_SVE_TYPE_DISABLED")
>  
> +libxl_arm_sci_type = Enumeration("arm_sci_type", [
> +    (0, "none"),
> +    (1, "scmi_smc")
> +    ], init_val = "LIBXL_ARM_SCI_TYPE_NONE")
> +
> +libxl_arm_sci = Struct("arm_sci", [
> +    ("type", libxl_arm_sci_type),
> +    ])
> +
>  libxl_rdm_reserve = Struct("rdm_reserve", [
>      ("strategy",    libxl_rdm_reserve_strategy),
>      ("policy",      libxl_rdm_reserve_policy),
> @@ -725,6 +734,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>                                 ("vuart", libxl_vuart_type),
>                                 ("sve_vl", libxl_sve_type),
>                                 ("nr_spis", uint32),
> +                               ("arm_sci", libxl_arm_sci),
>                                ])),
>      ("arch_x86", Struct(None, [("msr_relaxed", libxl_defbool),
>                                ])),
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index 9a3679c023..bd22be9d33 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -1284,6 +1284,36 @@ out:
>      if (rc) exit(EXIT_FAILURE);
>  }
>  
> +static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci,
> +                                const char *str)
> +{
> +    int ret = 0;
> +    char *buf2, *ptr;
> +    char *oparg;
> +
> +    if (NULL == (buf2 = ptr = strdup(str)))
> +        return ERROR_NOMEM;
> +
> +    ptr = strtok(buf2, ",");
> +    while (ptr != NULL)
> +    {
> +        if (MATCH_OPTION("type", ptr, oparg)) {
> +            ret = libxl_arm_sci_type_from_string(oparg, &arm_sci->type);
> +            if (ret) {
> +                fprintf(stderr, "Unknown ARM_SCI type: %s\n", oparg);
> +                ret = ERROR_INVAL;
> +                goto parse_error;
> +            }
> +        }
> +
> +        ptr = strtok(NULL, ",");
> +    }
> +
> +parse_error:
> +    free(buf2);
> +    return ret;
> +}
> +
>  void parse_config_data(const char *config_source,
>                         const char *config_data,
>                         int config_len,
> @@ -2981,6 +3011,12 @@ skip_usbdev:
>      if (!xlu_cfg_get_long (config, "nr_spis", &l, 0))
>          b_info->arch_arm.nr_spis = l;
>  
> +    if (!xlu_cfg_get_string(config, "arm_sci", &buf, 1)) {
> +        if (parse_arm_sci_config(config, &b_info->arch_arm.arm_sci, buf)) {
> +            exit(EXIT_FAILURE);
> +        }
> +    }
> +
>      parse_vkb_list(config, d_config);
>  
>      d_config->virtios = NULL;
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index a09c4c4bd7..0a00f03a25 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -815,6 +815,36 @@ static int __init construct_domU(struct domain *d,
>      return rc;
>  }
>  
> +int __init domu_dt_sci_parse(struct dt_device_node *node,
> +                             struct xen_domctl_createdomain *d_cfg)
> +{
> +    const char *sci_type = NULL;
> +    int ret;
> +
> +    d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
> +
> +    if ( !IS_ENABLED(CONFIG_ARM_SCI) ||
> +         !dt_property_read_bool(node, "xen,sci_type") )
> +        return 0;
> +
> +    ret = dt_property_read_string(node, "xen,sci_type", &sci_type);
> +    if ( ret )
> +        return ret;
> +
> +    if ( !strcmp(sci_type, "none") )
> +        d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
> +    else if ( !strcmp(sci_type, "scmi_smc") )
> +        d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
> +    else
> +    {
> +        printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n",
> +               sci_type, dt_node_name(node));
> +        return -EINVAL;
> +    }
> +
> +    return 0;
> +}
> +
>  void __init create_domUs(void)
>  {
>      struct dt_device_node *node;
> @@ -975,7 +1005,8 @@ void __init create_domUs(void)
>          if ( !llc_coloring_enabled && llc_colors_str )
>              panic("'llc-colors' found, but LLC coloring is disabled\n");
>  
> -        d_cfg.arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
> +        if ( domu_dt_sci_parse(node, &d_cfg) )
> +            panic("Error getting SCI configuration\n");
>  
>          /*
>           * The variable max_init_domid is initialized with zero, so here it's
> diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
> index bbf88fbb9a..5c5f0880c4 100644
> --- a/xen/arch/arm/firmware/Kconfig
> +++ b/xen/arch/arm/firmware/Kconfig
> @@ -25,7 +25,9 @@ config SCMI_SMC
>  	  doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
>  	  compatible only). The value of "arm,smc-id" DT property from SCMI
>  	  firmware node is used to trap and forward corresponding SCMI SMCs
> -	  to firmware running at EL3, for calls coming from the hardware domain.
> +	  to firmware running at EL3, for calls coming from the hardware domain or
> +	  driver domain.
> +	  Use with EL3 firmware which supports only single SCMI OSPM agent.
>  
>  endchoice
>  
> diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
> index 13d1137592..7470a21505 100644
> --- a/xen/arch/arm/firmware/scmi-smc.c
> +++ b/xen/arch/arm/firmware/scmi-smc.c
> @@ -14,6 +14,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  
> @@ -22,7 +24,11 @@
>  
>  #define SCMI_SMC_ID_PROP   "arm,smc-id"
>  
> +static bool __ro_after_init opt_dom0_scmi_smc_passthrough = false;
> +boolean_param("dom0_scmi_smc_passthrough", opt_dom0_scmi_smc_passthrough);
> +
>  static uint32_t __ro_after_init scmi_smc_id;
> +static struct domain __read_mostly *scmi_dom;
>  
>  /*
>   * Check if provided SMC Function Identifier matches the one known by the SCMI
> @@ -50,7 +56,7 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs)
>          return false;
>  
>      /* Only the hardware domain should use SCMI calls */
> -    if ( !is_hardware_domain(current->domain) )
> +    if ( scmi_dom != current->domain )
>      {
>          gdprintk(XENLOG_WARNING, "SCMI: Unprivileged access attempt\n");
>          return false;
> @@ -75,12 +81,45 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs)
>      return true;
>  }
>  
> +static int
> +scmi_smc_domain_sanitise_config(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 )
> +        return -EINVAL;
> +
> +    return 0;
> +}
> +
>  static int scmi_smc_domain_init(struct domain *d,
>                                  struct xen_domctl_createdomain *config)
>  {
> -    if ( !is_hardware_domain(d) )
> +    /*
> +     * scmi_passthrough is not enabled:
> +     * - proceed only for hw_domain
> +     * - fail if guest domain has SCMI enabled.
> +     */
> +    if ( !opt_dom0_scmi_smc_passthrough && !is_hardware_domain(d) )
> +    {
> +        if ( config->arch.arm_sci_type == XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC )
> +            return -EINVAL;
> +        else
> +            return 0;
> +    }
> +    /*
> +     * scmi_passthrough is enabled:
> +     * - ignore hw_domain
> +     * - proceed only for domain with SCMI enabled.
> +     */
> +    if ( opt_dom0_scmi_smc_passthrough &&
> +         (config->arch.arm_sci_type == XEN_DOMCTL_CONFIG_ARM_SCI_NONE ||
> +          is_hardware_domain(d)) )
>          return 0;
>  
> +    if ( scmi_dom )
> +        return -EEXIST;
> +
> +    scmi_dom = d;
>      d->arch.sci_enabled = true;
>      printk(XENLOG_DEBUG "SCMI: %pd init\n", d);
>      return 0;
> @@ -88,12 +127,77 @@ static int scmi_smc_domain_init(struct domain *d,
>  
>  static void scmi_smc_domain_destroy(struct domain *d)
>  {
> -    if ( !is_hardware_domain(d) )
> +    if ( scmi_dom && scmi_dom != d )
>          return;
>  
> +    scmi_dom = NULL;
> +    d->arch.sci_enabled = false;
>      printk(XENLOG_DEBUG "SCMI: %pd destroy\n", d);
>  }
>  
> +/*
> + * Handle Dom0 SCMI SMC specific DT nodes
> + *
> + * if dom0_scmi_smc_passthrough=false:
> + * - Copy SCMI nodes into Dom0 device tree.
> + * if dom0_scmi_smc_passthrough=true:
> + * - skip SCMI nodes from Dom0 DT
> + * - give dom0 control access to SCMI shmem MMIO, so SCMI can be passed
> + *   through to guest.

Is this so that the xl toolstack can be used? Because I don't think it
would be needed in the dom0less case?


> + */
> +static bool scmi_smc_dt_handle_node(struct domain *d,
> +                                    struct dt_device_node *node)
> +{
> +    static const struct dt_device_match shmem_matches[] __initconst = {
> +        DT_MATCH_COMPATIBLE("arm,scmi-shmem"),
> +        { /* sentinel */ },
> +    };
> +    static const struct dt_device_match scmi_matches[] __initconst = {
> +        DT_MATCH_PATH("/firmware/scmi"),
> +        { /* sentinel */ },
> +    };
> +
> +    /* 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;
> +    }
> +
> +    /*
> +     * skip scmi node for dom0 if scmi not enabled, but give dom0 control
> +     * access to SCMI shmem
> +     */
> +    if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) )
> +    {
> +        struct dt_device_node *shmem_node;
> +        const __be32 *prop;
> +        u64 paddr, size;
> +        int ret;
> +
> +        /* give dom0 control access to SCMI shmem */
> +        prop = dt_get_property(node, "shmem", NULL);
> +        if ( !prop )
> +            return true;
> +
> +        shmem_node = dt_find_node_by_phandle(be32_to_cpup(prop));
> +        if ( !shmem_node )
> +            return true;
> +
> +        ret = dt_device_get_address(shmem_node, 0, &paddr, &size);
> +        if ( ret )
> +            return true;
> +
> +        ret = iomem_permit_access(d, paddr_to_pfn(paddr),
> +                                  paddr_to_pfn(paddr + size - 1));
> +
> +        dt_dprintk("Skip scmi node\n");
> +        return true;
> +    }
> +
> +    return false;
> +}
> +
>  static int __init scmi_check_smccc_ver(void)
>  {
>      if ( smccc_ver < ARM_SMCCC_VERSION_1_1 )
> @@ -108,8 +212,10 @@ static int __init scmi_check_smccc_ver(void)
>  
>  static const struct sci_mediator_ops scmi_smc_ops = {
>      .handle_call = scmi_handle_smc,
> +    .domain_sanitise_config = scmi_smc_domain_sanitise_config,
>      .domain_init = scmi_smc_domain_init,
>      .domain_destroy = scmi_smc_domain_destroy,
> +    .dom0_dt_handle_node = scmi_smc_dt_handle_node,
>  };
>  
>  /* Initialize the SCMI layer based on SMCs and Device-tree */
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Tue May 20 05:45:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 05:45:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990416.1374354 (Exim 4.92)
	(envelope-from )
	id 1uHFmd-0006y1-RF; Tue, 20 May 2025 05:44:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990416.1374354; Tue, 20 May 2025 05:44: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 1uHFmd-0006xu-O4; Tue, 20 May 2025 05:44:59 +0000
Received: by outflank-mailman (input) for mailman id 990416;
 Tue, 20 May 2025 05:44:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHFmb-0006xn-Nh
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 05:44:57 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8f3d1832-353d-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 07:44:56 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ad1d1f57a01so896766166b.2
 for ; Mon, 19 May 2025 22:44:56 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d497a0fsm694134866b.140.2025.05.19.22.44.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 22:44: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" 
X-Inumbo-ID: 8f3d1832-353d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747719896; x=1748324696; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Lplm/kvflBzm80700I6ugxByOv4loEqZk1jZby8oAYc=;
        b=HtdlHf2m+GXtXtAic/0nZ7Dd6KsPqrh7N0IL4u2MrBx43l1BaD1wj/Is6y1yN3hHl8
         qmBC8nHkwFZqIrQOALu6Uf+JHfxbvHgBj8DOzzzLFocachChWLLwnxB9g6SLmogBlJQR
         Lh/vqLIRamsMcTMmMEK1BifBSlznyI35fEXNQDfoE8/L32mA45iPjRev7hejoxscfCAN
         74vB93lx94hzGRahSI8+bqXZpAlEB0xOIsUa38hDTGfKLgcu+XsdYpNMixWw7E2Kt0fy
         ySqJWdnvCwvSEEcUUx0J8Ae3zbLSbKJxdBExp6x8lchvsOFUW1xGwK75BOuvq6ZM+bHt
         eT4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747719896; x=1748324696;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Lplm/kvflBzm80700I6ugxByOv4loEqZk1jZby8oAYc=;
        b=weH/rvRJ6820RRDFahd/ZHgYYu31xa7d71jCclGrVRDjVVylRrByD7J+DzfMJg3uq+
         kO0d3fwpr9eQ04FyFLxrd22G3N26RJh2+Ri5DQbTM8/vFuFSTxvmhoKYPOwmQjNWQ8b1
         rQRYliiG44wqa6ASm6IsDvRTGoXpLsYjVFPoFbwh5qOcGsBms3qnbGkCl2MR+Zdw6Y2j
         x+n3EqqJfcZuJ2KywxHXsMTF96s97NXKj/ZUEiMZdVShbEDMLEug/P/RcxSlt+AyrVc2
         GZANQ06vi0oGl0xMpE0kcmmf5lR0nvgm1xg0TBDJtZfGtbxxzBCU6NCB8NTdYKTK81CV
         nzPA==
X-Forwarded-Encrypted: i=1; AJvYcCX5JleMpYfu15GaBaUKGRcA8NCFp9KpdtU57W/wAVBuDjYtSp7fK077Kz+qjAU+A1+m0OdM9PpUc/0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwXCaM+pWwbxNoLZLIjxNr9QPNP18Ahr4tCJFwxBFgNgCaLsafN
	RGXaROyeye88uZ1DL1NcnXfbCH37ENzJ74pYoN71RoIw9KS5dxEyJoLkIJigDDHhzQ==
X-Gm-Gg: ASbGncvEIY59LuweH2AvGj8v/oK1al3ys0i2ySNiF9nlu2bhYqpN0ZmdcWXfllUdK1R
	6gBXHJ5p7Jpnob6VB8bdfFnP7MHDpPS2PbfNUHTKw06OuIvnwtTdIxp3vZynJDj3JYOZ0dI8yYB
	6moyEzAGlu903ntzi7qKNW/Y/Xp7FDYwDW1WcFx73ToSXed69hkIFYsFL0XP69yPoD/AQKS2Eso
	9X+symeeBrTvNntYH2jU+s8ahRwPqHo8LETy2nrkk6iwbFpPaFQlwGjrOkMxxG9p1+Lgos+LlS+
	fnNP/lZQv9tWkJ2OvnmDqo+I5ayiw9vAbYr0JyHmKoEIPtlDck/dBjOo0hCOwQ==
X-Google-Smtp-Source: AGHT+IFDrDn6+xrMicgtTOYGGIWeBTzMYLZv1ytU3zEXjueNgq6u0EHrZQh+U7xBkQXFClA4EL9qmw==
X-Received: by 2002:a17:907:1b1f:b0:ad5:1fe2:d392 with SMTP id a640c23a62f3a-ad52d50f9c1mr1346190166b.29.1747719895810;
        Mon, 19 May 2025 22:44:55 -0700 (PDT)
Message-ID: <4b580922-4aac-44bc-ad14-75a250ac7962@suse.com>
Date: Tue, 20 May 2025 07:44:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: Give compile.h header guards
To: Stefano Stabellini 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250519135227.27386-1-andrew.cooper3@citrix.com>
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 23:34, Stefano Stabellini wrote:
> On Mon, 19 May 2025, Jan Beulich wrote:
>> On 19.05.2025 15:52, Andrew Cooper wrote:
>>> Signed-off-by: Andrew Cooper 
>>
>> Is this to please Misra in some way?
>>
>>> --- a/xen/include/xen/compile.h.in
>>> +++ b/xen/include/xen/compile.h.in
>>> @@ -1,3 +1,6 @@
>>> +#ifndef XEN_COMPILE_H
>>> +#define XEN_COMPILE_H
>>> +
>>>  #define XEN_COMPILE_DATE	"@@date@@"
>>>  #define XEN_COMPILE_TIME	"@@time@@"
>>>  #define XEN_COMPILE_BY		"@@whoami@@"
>>> --- a/xen/tools/process-banner.sed
>>> +++ b/xen/tools/process-banner.sed
>>> @@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
>>>  
>>>  # Trailing \ on all but the final line.
>>>  $!s_$_ \\_
>>> +
>>> +# Append closing header guard
>>> +$a\
>>> +\
>>> +#endif /* XEN_COMPILE_H */
>>
>> This split of #ifndef and #endif is ugly. Can't we switch to something
>> more conventional, like
>>
>> #define XEN_BANNER		"@@banner@@"
>>
>> with the first sed invocation then replacing this by the result of
>> a nested sed invocation using process-banner.sed (which of course would
>> need adjusting some)? (Maybe the double quotes would need omitting here,
>> for process-banner.sed to uniformly apply them.)
> 
> While I agree with Jan that this is kind of ugly, it is a unique case
> and I would prefer an ugly but simple solution than a more complex
> solution. This would be different if we were talking about a widespread
> pattern, in which case the price for complexity would be worth it.
> 
> My 2 cents in this case are in favor of the simplest approach. I would
> ack this patch.

Feel free to do so; my comment was not meant as a plain objection, but more
as a suggestion. The one thing I would ask for is a non-empty description,
though.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 05:53:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 05:53:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990424.1374364 (Exim 4.92)
	(envelope-from )
	id 1uHFvH-00007R-KU; Tue, 20 May 2025 05:53:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990424.1374364; Tue, 20 May 2025 05:53: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 1uHFvH-00007K-HS; Tue, 20 May 2025 05:53:55 +0000
Received: by outflank-mailman (input) for mailman id 990424;
 Tue, 20 May 2025 05:53:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHFvG-00007E-Lq
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 05:53:54 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cf8cc990-353e-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 07:53:53 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-601fb2b7884so2244964a12.2
 for ; Mon, 19 May 2025 22:53:53 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005a6e3ca0sm6866877a12.42.2025.05.19.22.53.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 22:53: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" 
X-Inumbo-ID: cf8cc990-353e-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747720433; x=1748325233; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=PMYEZev2uqmCun+CImMtT9WPp/EgThbcBu50Mxy6KuE=;
        b=XECNfkKQK1mN6Dm87jjgerUubAHSHnAyA9OLX5Tm2C7XE2Gb/a0cly3PE95hNiYiX7
         9UTmi3Em7sG8kILElFozPXwzN8efmaaFttTUl0IsQ6A/4zebAe+CB3pnAwvSX3UVKOXs
         8pExvy09vmqP7kJWYILTrB63xw/p4d6FvWVlRn6sH9CCkzBIlEvagNQdHmtI+WamDdgt
         Iry1Y4gkdWtogip33lYFKUrs6MFGOvuXyEXq9+rxDPo3jr6X1ImkJj/tqFCxfMmuDosP
         PMrM1KVRhE08+Ogpua8A9Dj/z4xb2a4qqigNfalA1VWReG1pzNrGYw8FIoyVR96GqV7o
         BrOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747720433; x=1748325233;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=PMYEZev2uqmCun+CImMtT9WPp/EgThbcBu50Mxy6KuE=;
        b=FK+ZayE5urmShxdQAGLZVdyWJL8yur3Ik0vSApmU1T7mPvzedIljaAwX+APQ9ddQ4e
         VQDwwy49bchhgE5M0AHJ761c4Li8QpmdvQeqdr82kDwzjqaj1J1AskvQvn1z54IxqjIm
         gTfw2FI5bupxxfwVIx0YM+sDn3thTWHDfb5IDe3HjJK1xO8n3GQwF3/Cga+d86NuwUmo
         EC+gAfvbXvbkxRxRkWAdi72k8VSmt85V4vzN61SVYewaZgmJTYKSLfD2GnHbyiHuKblq
         EKVz4+/Ank663Uke2valwmsG3W8zKulYSPnzUgoJxQiojuBuoUS80vI9DytrkH/dXqem
         u1Yg==
X-Forwarded-Encrypted: i=1; AJvYcCVJaEWQQXm70By30/0/Pu76fC+7Dd4ExeM8j08IVA7wE3HDa5Zpza6eSVpsJ7zLu1Aw3dlisSVVZUc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywh2Viz5Ujyz3xRWYe4Gq5PTctQBXjkN4B/gGy1D+/LefuYiePw
	HMX+Agc/t4PRfxOJw2tPiUTWEu3TerjBqthme79o9GYOvza7txS8sD+nrNm+mwik8A==
X-Gm-Gg: ASbGncs5PK9g0DYlKhnocuQWE48BfMVGUq/N50R+a10AjuI3Jt2bdQoIKcajS7kLqS4
	Fzk7cn0OggNX/9kH1I51+5jOxRsu6AMxDux048H4T5Y4SKljJlUnLmWUfCyxuq1Xg788ykw7iez
	IifCapxzmpPPzJrXE5dr+Hh3PWRhDucr0VCpLBJ9f1fkHofJlLroLSxdTJyNdrjhcAF2Kz4qYea
	Uf8x+B1kk1/NHRD90OBEDvB2uYWOOxg/EgzX//6o3MAyebESwFGDQnXcI09QmeFDG0leLdSdDb/
	Q0DbGYEc8I0Hj9jCA7cDpeF0VEpW94glltuvWdEZ9+ZL1JYnvV2zFhIMBfQGnvX2Idm9YSf6
X-Google-Smtp-Source: AGHT+IF100UZdYHREK4A/KGabhrOYo/M6Yc49kVlj/LovL3UryUpWEqcp5Hl5M/hzce+RWm+Mvd7yw==
X-Received: by 2002:a05:6402:1ecc:b0:602:15f:5883 with SMTP id 4fb4d7f45d1cf-602015f5946mr2574730a12.9.1747720433191;
        Mon, 19 May 2025 22:53:53 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 07:53:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 1/3] xen/domain: unify domain ID allocation
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250519192306.1364471-1-dmukhin@ford.com>
 <20250519192306.1364471-2-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250519192306.1364471-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 21:23, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Currently, hypervisor code has two different non-system domain ID allocation
> implementations:
> 
>   (a) Sequential IDs allocation in dom0less Arm code based on max_init_domid;
> 
>   (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
>       max_init_domid (both Arm and x86).
> 
> It makes sense to have a common helper code for such task across architectures
> (Arm and x86) and between dom0less / toolstack domU allocation.
> 
> Wrap the domain ID allocation as an arch-independent function domid_alloc() in
> common/domain.c based on the bitmap.
> 
> Allocation algorithm:
> - If an explicit domain ID is provided, verify its availability and use it if
>   ID is not used;
> - If DOMID_INVALID is provided, perform an exhaustive search within
>   [0..CONFIG_MAX_DOMID-1] range, starting from the last used domain ID.

CONFIG_MAX_DOMID first appears in patch 3 afaics, and hence doesn't want
mentioning here, yet. That patch,for eample, may never make it into the
tree (and thus the description here may be confusing to future readers).

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -66,6 +66,12 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
>  static struct domain *domain_hash[DOMAIN_HASH_SIZE];
>  struct domain *domain_list;
>  
> +/* Non-system domain ID allocator. */
> +#define CONFIG_MAX_DOMID DOMID_FIRST_RESERVED

Oh, wait - you're actually introducing such an identifier. Please don't.
It's bad enough that we still have a few CONFIG_* left which aren't
Kconfig-controlled. We don't want any new ones.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 05:58:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 05:58:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990436.1374375 (Exim 4.92)
	(envelope-from )
	id 1uHFzP-0000l5-85; Tue, 20 May 2025 05:58:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990436.1374375; Tue, 20 May 2025 05:58: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 1uHFzP-0000ky-53; Tue, 20 May 2025 05:58:11 +0000
Received: by outflank-mailman (input) for mailman id 990436;
 Tue, 20 May 2025 05:58:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHFzN-0000ks-Nw
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 05:58:09 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 67934790-353f-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 07:58:08 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad564b7aea9so388635866b.1
 for ; Mon, 19 May 2025 22:58:08 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad53603a369sm641502966b.47.2025.05.19.22.58.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 22:58: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" 
X-Inumbo-ID: 67934790-353f-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747720688; x=1748325488; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=DnZUd73vdE6oubGO0t5uW1E2L4TvTC2C5MtnX8ISUY8=;
        b=dN91jy3CaUzxDdu1FTu43mtskbYEisSn7gf1iZpkV+SyNnUt1ORAOPdV+0Ffk26gN5
         CMHHa31M7bSOyB60AMIXbNJqdp4eNOE7qNMjiJMAPO1j5h4mp8uCwFVLr2rVml+gkmFF
         5mwBPGSl7Uy/swRdu+nqNmV52IXCYcUJ/q9ik4MW0MLe5bGFmwoNOLH5BZ7m/g3aHYU4
         QJnQ3KMZYmVDnLtQHybMM6ABZpW6Illl3Nm8ApxTDEYwhtb9d17/5tmW2k+U5qr4FJfk
         OoVvHrOgEMpoyK30fkDm0R2MhCZyWAOgafeC3qOciFssCLdkeusQMW/5PrwjpSGoQ6bp
         mDyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747720688; x=1748325488;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=DnZUd73vdE6oubGO0t5uW1E2L4TvTC2C5MtnX8ISUY8=;
        b=dF3f7WEydAy3XPBVo7H/Xe2jeIdXEenNvN+0CUle3oQgY2LWpe45Ha+IPSinr5MJk3
         5sN2V1GC4UCWG0zkt5Z5nD6ZcvSAfocaOdjUq0yNvuJBotBuuyhFGw+zKywnpUjnE3HW
         IdPlCf+MYwzzuONoOzhDTawAE8M75CGRlbNCEQr4sovglDSpJzBY21ca08RQvx80K79F
         QMHyEA7Oo8Ao3OyMfo43eZpordJkowvkdeYoSLoR5LHBWNrh6y9Vcor9v7eYiUhwnWI4
         ncFGaKWHM5mF7iBr6DUJckCCwPS6jYY1uSBe11OsGyjZyrTnP9OVi7IS1LYDH4Tdd1v2
         Zrxg==
X-Forwarded-Encrypted: i=1; AJvYcCX4HhGu8+WoP58BGR4csAeDd2OOuG2cP1XDRgAPGyH8lkVHvsydCwFBl5Kqv2kR33mrkCQhYcM/EYY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyS34b1uMwICnihJf1v1tAugR9bDA0cWHgg0ygfnjeAcVqPUIb/
	SphosnDwI30cRvln6x6kxB59rEFyUOSXSoFjHJnLLem0HeqSUtgFamcyeEUq9twfww==
X-Gm-Gg: ASbGnctTkPn6ddP+2alyB7kO7gsWGe28Lw7RhMC4+jxDnmdldM1DeSBS71rpy/uqZm1
	y/DFFGumfh/VJavmBNIrbN5DgjjtuuLZ2q+bLkgLiECwehgipVQiRjz9zHneiqj74LfFd52rlAE
	4SDgOaElHKzRRNQ/X5IMUgya4UuDCnHkNma851SCm927QG+cL6zgHMKJpf50ov3AqtmN6P3uyf3
	HqupWzm6wBo09lvGw4xB4comMypWbRP5NQNZb18dMzF3DCOlNY9GXymbtYAECmgMPA1++WTYnXp
	Pyd8mdkjhkZwaM4JL0Pwoqx7FIFAMTZORW9g4ju3m2c9RbKCzcvw7357rilDvA==
X-Google-Smtp-Source: AGHT+IG8T9dluX0LCk1s16OYBphhaFtaTml++AUHKYtxZCv2QICNleZtqdtGFlxdTAeIXMAX1fyVTw==
X-Received: by 2002:a17:907:1003:b0:ad5:2c8d:6f2d with SMTP id a640c23a62f3a-ad52c8d707bmr1105741066b.28.1747720688242;
        Mon, 19 May 2025 22:58:08 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 07:58:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 2/3] xen/domain: adjust domain ID allocation for Arm
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250519192306.1364471-1-dmukhin@ford.com>
 <20250519192306.1364471-3-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250519192306.1364471-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 21:23, dmkhn@proton.me wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -2424,6 +2424,9 @@ domid_t domid_alloc(domid_t domid)
>      }
>      else
>      {
> +        domid_t reserved;
> +
> +        reserved = __test_and_set_bit(get_initial_domain_id(), domid_bitmap);

This returns a (pseudo-)boolean, and hence the variable's type is wrong,
as is ...

> @@ -2439,6 +2442,9 @@ domid_t domid_alloc(domid_t domid)
>              __set_bit(domid, domid_bitmap);
>              domid_last = domid;
>          }
> +
> +        if ( !reserved )
> +            __clear_bit(reserved, domid_bitmap);

... this.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 06:04:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 06:04:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990443.1374384 (Exim 4.92)
	(envelope-from )
	id 1uHG5L-0002Vm-SA; Tue, 20 May 2025 06:04:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990443.1374384; Tue, 20 May 2025 06: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 1uHG5L-0002VE-Pa; Tue, 20 May 2025 06:04:19 +0000
Received: by outflank-mailman (input) for mailman id 990443;
 Tue, 20 May 2025 06:04:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHG5K-0002V8-Sm
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 06:04:18 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 431095f2-3540-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 08:04:16 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-601dd3dfc1fso4117517a12.0
 for ; Mon, 19 May 2025 23:04:16 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d501f0dsm6765781a12.21.2025.05.19.23.04.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 23:04: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" 
X-Inumbo-ID: 431095f2-3540-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747721056; x=1748325856; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Yd1quX4ntTijSeqrO92BDgk4ZXbs1RbJZnLqqQO/u20=;
        b=ZHU0/HW0NJzwG3wZzFvlORhnTQ8CVoDQjPR7J2kTfdKgc7kyKpsjWEl0OM3RR3tnnv
         YT6qSi+XSw+dcXCnCCf5d1lfIhaXrDZQKGrBH9ayPmkunpDIWBMO5PTSAYdBFgK/v+Rd
         0POtkUOmDkJ2+fkhXJhanbVKyejTlWi19+Y4jm8teHlhAdXy/PVixTSHgGvQXpJ/bW6b
         7M0vbOfTSgpBLjLRedrIzgEp3tgQtswN+smuCgSm1sByUXRsP7/DiDNCsi0iZ8qzQzDm
         7OK6hwkuo8ttq36MT6DhMnB0Ab6kmLZbBsc63RsInCzIrQdhMaR1sjqAMUuttb+jeCg7
         x5xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747721056; x=1748325856;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Yd1quX4ntTijSeqrO92BDgk4ZXbs1RbJZnLqqQO/u20=;
        b=tFXxWALDXVdDm0miqGRt3Q34mHofPE4MLQZ1dXGOYuA0+guyLcp+/jIpOg6LHKl5al
         veRGGvikyUvWSAtzUbiK1h07jmoCi1ZR5cQUj2RGZAEGxB66xR4dBmKHzC+rE2tZMn10
         R48DuY2z5z7O0jRp4f67JyRTV96vGbNQlpmKgTm/EKARaPiIS7ANCblFaEqSbF3Lh0BU
         byVSXoY+nU3bjhfBbYDjE7i6Fw6IK+/U5k2Al0mt2Yg5GVjXwaafZiU3AwAzQ6PgdG20
         /dxfAWFjCHhbZIrxVLoR3i91IrZ3jMZobQZAwqGDKxjrJycM/ky8baTvd4qG8O5jHOJx
         GWtg==
X-Forwarded-Encrypted: i=1; AJvYcCUDKddyRqqxmP3useCRY70jpuK8AuaNl9+rTSAJMWMIPmw9NDxwaP7mdgia6sndgAeBiL5vWi2Hn2E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxGyQKKtNjoyLHhJwbz8Amww92QeuXginLEjx91ZDTfcS0tV3Bd
	uAp4Xjl8j0D6b0fudgYiA7P83iGdW1E9w6CW1xury01yBIs69RT0aRWSyMY1Nk5rGA==
X-Gm-Gg: ASbGnctdWYfwq3TfF53txJjr0vzecXep4busbm8qGRk2TVSoCbq8SByU6QaMx5UyJbe
	iDHlUqHWBlrJNgB6d6ZKweP/53knnBLcFSvra9D1+vvAk2QTyCsIRqL98hIzckdlWmoG0BOyLhA
	fBGzC5X15QAZ7TjvwH/Ui5bi88ut30jSti5zi8CPAs2TuUXko3E+teWISoAMMfQuJOpw0EnbKXN
	sjJPzA9Z9EFx6nsClXYrneuTkbpB7k9iF/PJZBB9H603ia7/M0/2CD+xBYDZHVVAmOWKLLLkdxx
	X4WWp4M1giYS9nBLgIxEOytDyQbu0efX0hFvaLwrvjNGTVGqAYhni4B5fSaEzA==
X-Google-Smtp-Source: AGHT+IFYo3pq3hLIZukCfUvrNCWvExdeW+QEHFvNrMowdjH0UoFbvpXBfc3cLVTSoH5zGPOm+Fj4GQ==
X-Received: by 2002:a05:6402:5189:b0:5fb:f5fc:e038 with SMTP id 4fb4d7f45d1cf-601140b5d05mr13186038a12.19.1747721056311;
        Mon, 19 May 2025 23:04:16 -0700 (PDT)
Message-ID: <0b7fd522-af98-4ab3-ae6b-ed131ef3bf04@suse.com>
Date: Tue, 20 May 2025 08:04:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 3/3] xen/domain: introduce CONFIG_MAX_DOMID
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250519192306.1364471-1-dmukhin@ford.com>
 <20250519192306.1364471-4-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250519192306.1364471-4-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 21:23, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Embedded deployments of Xen do not need to have support for more than dozen of
> domains.
> 
> Introduce build-time configuration option to limit the number of domains during
> run-time.

I fear I don't see the (sufficiently meaningful) gain of this. And I must have ...

> Suggested-by: Julien Grall 

... missed tis earlier suggestion, or else I would have asked the question already
there.

> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -333,8 +333,9 @@ static int ffa_domain_init(struct domain *d)
>       */
>      BUILD_BUG_ON(DOMID_FIRST_RESERVED >= UINT16_MAX);
>      BUILD_BUG_ON((DOMID_MASK & BIT(15, U)) != 0);
> +    BUILD_BUG_ON(DOMID_FIRST_RESERVED < CONFIG_MAX_DOMID);

We want this check, yes, but in common code. It's entirely unrelated to Arm's TEE.

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -576,4 +576,11 @@ config BUDDY_ALLOCATOR_SIZE
>  	  Amount of memory reserved for the buddy allocator to serve Xen heap,
>  	  working alongside the colored one.
>  
> +config MAX_DOMID
> +	int "Maximum number of non-system domains"

Hmm, without clarifying what a system domain is (is hwdom one? is a control
domain one), I fear this may be ambiguous to users.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 06:07:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 06:07:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990451.1374394 (Exim 4.92)
	(envelope-from )
	id 1uHG8p-00035D-9v; Tue, 20 May 2025 06:07:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990451.1374394; Tue, 20 May 2025 06:07: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 1uHG8p-000356-7G; Tue, 20 May 2025 06:07:55 +0000
Received: by outflank-mailman (input) for mailman id 990451;
 Tue, 20 May 2025 06:07:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHG8o-000350-5C
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 06:07:54 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c3cfc58f-3540-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 08:07:52 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-601fb2b7884so2260260a12.2
 for ; Mon, 19 May 2025 23:07:53 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4cac58sm676754566b.168.2025.05.19.23.07.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 23:07: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" 
X-Inumbo-ID: c3cfc58f-3540-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747721272; x=1748326072; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=XycbkiQmhIxEPpBh104BHF4ytnsP39YhNYXlKMRNcMk=;
        b=IKs9rYHByhzMF0+H9Ye/GV3+z3vjCmh/9m2ngQ+4VdkW2cPDT0RT/3GxKTwWgVdgJ+
         OK6DcFgptopGtwYf+2JRB1Aj2kI+S/QDqJcHIyCi1jXJ+12TSseXLuY7eCBSTLHlTV39
         3HxRUOO8P5FRwtM4K9jaMz8ssVHrsDXHLXbnLjqP9jNUq+owpoxFYLWgkv1pKlTomIOB
         h4R3P7mQV4s1+BTpjRUBVf9IMpe5Y0zsu+HmLhVBWpbivgKOioDgPGtS9IJNFY5EhAWQ
         s3F8KuX1o6X61Pxwq+3DKx2LSsXWcTqYHT2f6SizT9st/Ts5ZkgcEp1ozeKb7HI0mual
         PPSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747721272; x=1748326072;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=XycbkiQmhIxEPpBh104BHF4ytnsP39YhNYXlKMRNcMk=;
        b=iLf3BVJ3JJLlhaFrw6WqHdPBcJJOp1rrETaWtvdkFtn8iNXbiWRPqv983HE193k3XH
         Ophoi5WGHOHG6bqJGB8xMiBMBtk+/wtpL/+fSqvrluwJLY9pZ+oNDoppX2ZcIzQlZtJq
         Nxn40RCccrDty3HjCtgqjWv8eVT8SdahVkQh8vDVX6WsgmEHcdt8QLdlnj8I+t6gHAuX
         oJ8nHmGYNGMgMaOOa/KJh4Ju7I13TKBf+TRJBppdFadsJ+ZII2mvdstPnE6QF16ONdYK
         hNboBF7qVfK6WBXkXJyxZyLeLdy/invIh4szQtvqihuqLB2gux4Huw6egkIQslEq9PlA
         FLdA==
X-Forwarded-Encrypted: i=1; AJvYcCW3mRgA12fA/16vMEQMiEmOJhPngp+nc2Kqt/xvT38B7Ri9tTPJwB3M63UTmseu9T7GJzGsgLiDksM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YySxfBFYdhPOUhPckKz1rvWz9DCcS0HK7GFPWfA80kb/Ew6T/OZ
	JK9an59dJTgjCAnO1zNuYrcRQO/hVVql8qoAuCRHRCqk68d2PRE1dJ/1c+STc+NBHA==
X-Gm-Gg: ASbGncvelIYln1TtWZY5A4gOjxW34fQZ9xHjsG3aqVKkVKnEzZ4xYLVUmYHS8/HrtaH
	F8tDEkFbcu7P80ymlHUGHx0aBlLzJHRU56HNtNPDNum0Y6c8DJyIl+sT1279YcVQTwU8V+HOWwl
	HM9nm0a1ySTZtx0h6ux+UfJ++fDAUxCk4uSPUudr53153XXM8VR6Argb1IlnIPiWyWfzEzK2QBe
	Ej32lzo8DqRDPlPGFP+6Y2+x7wqYF5kwvqSeVHkyjN0q3pUEzWfbukekgK89xkAizOp7y/FcXUD
	CuMOxqtKd6MntdkNhnnDYe5G/iClD31fxBw4eDoDKoD0cklKpX82ykTKvveQqQ==
X-Google-Smtp-Source: AGHT+IHrYawBBcaK6pJi6/b/iFegOKbWdIfEgLGAhIwRTrxKjyuYBNBQFCgHfOyvcp/QlgMpSfdE4w==
X-Received: by 2002:a17:906:c303:b0:ad5:fae:6288 with SMTP id a640c23a62f3a-ad536c1a829mr1093829566b.26.1747721272467;
        Mon, 19 May 2025 23:07:52 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 08:07:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/5] xen/console: rename switch_serial_input() to
 console_switch_input()
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250519201211.1366244-1-dmukhin@ford.com>
 <20250519201211.1366244-2-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250519201211.1366244-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 22:12, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Update the function name as per naming notation in the console driver.
> 
> No functional change.
> 
> Signed-off-by: Denis Mukhin 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Tue May 20 06:20:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 06:20:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990458.1374405 (Exim 4.92)
	(envelope-from )
	id 1uHGKs-0005qn-Bc; Tue, 20 May 2025 06:20:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990458.1374405; Tue, 20 May 2025 06:20: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 1uHGKs-0005qg-8V; Tue, 20 May 2025 06:20:22 +0000
Received: by outflank-mailman (input) for mailman id 990458;
 Tue, 20 May 2025 06:20:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHGKq-0005qa-9k
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 06:20:20 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7fea3714-3542-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 08:20:18 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad53cd163d9so602503466b.0
 for ; Mon, 19 May 2025 23:20:18 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4cc5e9sm688760566b.173.2025.05.19.23.20.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 23:20: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" 
X-Inumbo-ID: 7fea3714-3542-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747722017; x=1748326817; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=dPAQPo0D8mdf+B7aRBWjKJ/4rZOLY5oVWJ0SM/csTM4=;
        b=Wl1nT/JjWB6CnXCOsg7yC2OOtHHlzEBqOfTtLA63715Ph24JTkpcaX02/8slSRw9r6
         tYxAI44SFB7p4eo85TIqSt0sILmny/yZ7eVvCGflHC/+2z7JoZHx26dD+isBiOvUsLmr
         TaDltDVG85a5exYtVAaYoIAVYasvi46orYfAjkV1UHaDHkDBehK2O8jb6wMeJxmamA17
         6+vNXL2yR/0LKI6u7gC6DXDQgJLHEaQryqSYmQh0RDG7fwMKCJMvY8fSHAF4ESRkvFLA
         kyhj5Xzp7vHE48UbtURSBPJ+oH7FZafZ/AAABbhgm8l3qiPhqHQFtGgbBwHKJfn5UUxT
         EIrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747722017; x=1748326817;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dPAQPo0D8mdf+B7aRBWjKJ/4rZOLY5oVWJ0SM/csTM4=;
        b=GbepKmuyHSmWjZP35CcxuQMTVrTR3QoNr6KwoD55UGPV4vKLdGoKURdUam1Qxk6SHU
         dr1ES/mE07jGakkH4MtJd5gi25r6vjuxGNorUJklU7JGhcGBWaHv5BVD0tLjLBKx6kAp
         aT5TmRjx2x2tbim9L5gcO1kg5p+vK9u8DjE4YpshlBKt4k2vtweKuCjF60/YnTC2Xqqb
         KbrEDId4mqmmwjR78gL2EgyqaA0UbrQerb+kiA4QhvLhq8atKl9xRhhReh8M8yXvfUYl
         C7UWfR/sAlJ1vXwyEEYvuNzeidGOmEWXuiArO9yTiUVcn7+mlvB9Frps0Sf/HZk42osH
         noDg==
X-Forwarded-Encrypted: i=1; AJvYcCX0sduErzkXx/VC2O1k3VsrHxBnRgvcsuQzC6/dB25igkq5uCZoCQ/KVsrkyNhZd2HFdFFM+1xe8As=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzn7cgmzrMpwBYqziZqGzdjpUL7w+N6AXvmcP6gzE8gQWCkwOpo
	4U9sHdVSBrkUvw5uq6k5Fao6mLWqUYcVrDSruw5wSjEVf88lBVnkRCsQg7Eu8keZxQ==
X-Gm-Gg: ASbGnctXexLtIedH44NEAIecUXRCnQ7JmtnSqLU9cCp6kVYh3M9A0D0tofEAw2ceTVJ
	fvsvZ3a7YFFfJQKsYa8C3/U48PCouP3/AQIUULyN6HVA//mk79eRiJ9ThTgClOVRjWFGhouTwUZ
	5BN9UrJVHkbgyQDR9iFCL0Ue00qQDwVgXAJyebp4u/6fossxfmQxRnHX3frrsOse+5mYcFdRtMH
	U5FJUtsLGnjm0Zxt7BYNHSRSWfvCm7SHSyF/f1PKSbdkeqWRtNqDUYEAqVCULiqUDy0BOPovBlF
	J01gumVxoyNbjvAXTcKYqtJbCa8aJdIK1GSpSwhO5IrEaABFEDiP/Kc2g28Tpg==
X-Google-Smtp-Source: AGHT+IGh3hq4hPQrOoZpu9MT9N7qoDaj2JKB7EUfwRcAvKsSwd7HayPSHpb5R1GgwoI3SI3etzDlZA==
X-Received: by 2002:a17:907:db02:b0:ad5:27b6:7fd1 with SMTP id a640c23a62f3a-ad52d48da04mr1518032566b.17.1747722017425;
        Mon, 19 May 2025 23:20:17 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 08:20:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/5] xen/console: introduce console_get_domid()
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250519201211.1366244-1-dmukhin@ford.com>
 <20250519201211.1366244-3-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250519201211.1366244-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 22:12, dmkhn@proton.me wrote:
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -78,12 +78,11 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
>      unsigned long flags;
>      struct vpl011 *vpl011 = &d->arch.vpl011;
>      struct vpl011_xen_backend *intf = vpl011->backend.xen;
> -    struct domain *input = console_get_domain();
>  
>      VPL011_LOCK(d, flags);
>  
>      intf->out[intf->out_prod++] = data;
> -    if ( d == input )
> +    if ( d->domain_id == console_get_domid() )

How do you know d isn't a domain different from the one that was the
console "owner" prior to being destroyed? Original code guaranteed this
up to ...

> @@ -123,8 +122,6 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
>      vpl011_update_interrupt_status(d);
>  
>      VPL011_UNLOCK(d, flags);
> -
> -    console_put_domain(input);

... here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 06:28:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 06:28:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990465.1374414 (Exim 4.92)
	(envelope-from )
	id 1uHGSq-0006jG-2p; Tue, 20 May 2025 06:28:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990465.1374414; Tue, 20 May 2025 06: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 1uHGSq-0006j9-04; Tue, 20 May 2025 06:28:36 +0000
Received: by outflank-mailman (input) for mailman id 990465;
 Tue, 20 May 2025 06:28:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHGSo-0006j2-Q2
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 06:28:34 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a6f07be1-3543-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 08:28:33 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ad5566ac13cso359108166b.1
 for ; Mon, 19 May 2025 23:28:32 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4ca654sm675914866b.158.2025.05.19.23.28.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 23:28:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a6f07be1-3543-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747722512; x=1748327312; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=ruF28dazTFaSTHvRX7eaxSPU77uh3cIwlnjMA0Ts/qY=;
        b=a5b5cTqrTnMEUGi034OzH3tTPd5p6gx7JAqdgE3dOkl+EKg/SqwNpCJLpe+Us5VjTH
         m7VcFTtKAwwdQzqWWrLhDOSfITllCCnCasrw1cttxDqz+v+hG+DXt4aOGaYGWnH7slQC
         ao/WOnKyeJ1yS17ZI5O7j8uqXTmcZD3Pj2gIKQV1kM9+Rj29Es/VN+htiQFYWaqFvbdm
         1MKASfI1vw4V59pUSUYyh3e5Fuf7rpanRrjqMuHgdB345G/9i155Rw8yuVlsmvkBanIc
         +l0l3Xy4U0v7P6qU4h+byv+uo8eaFEecXkMIPMwiX70ReKOGOIyFwSzY7WRyv1aTxqeD
         arlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747722512; x=1748327312;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ruF28dazTFaSTHvRX7eaxSPU77uh3cIwlnjMA0Ts/qY=;
        b=YIYDLSHBG4zm+LUJvGsVhgq4mcWOXWDkDYFrgrBOA+kRXUaVmZ1puurWYdS2duyclO
         36nrWl/2UuKgMqXkwVCV2OJQIq1PloBJcZS7z95fFKelRHvuQXiH3X84tLDb/+wpz3Q9
         CJublvm41N+Vs5x7UUkCcObfRQK3rtAvslDc/ryOv9uBScULB5T6XJEUOUZydDxgMlep
         QYOp8CIYEBi21fjm/b+uk4S9k6cvfb1Z4Y+2jUiOsfGVPsSbIhC3yd4rovSjc/9NhM/A
         +0ZyAXhNUFFJl7to0etsgKxtvZAB1Dj29k4Tb4Pc87hBPD+jwtoM9OmlzQrCDN5vIhOi
         Rkog==
X-Forwarded-Encrypted: i=1; AJvYcCVn22qJ8ZEgEGzrYeYcvSnZZP235qNiBE8/uyROjsT+reTMI7Iath/nu2QMPKDhUvzUs7bbDxYf/DU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzwknB5fZek6eT1d5WM8SEIGwk3b5eD9v7cCyDP+sZJtI2mPF//
	kOIJPlmgQR0GTmvtVRwBJRTM6p7cy9qfaZwvkadpIfhe7xtGZ6raG21GQ+oy83L4aA==
X-Gm-Gg: ASbGnctblBVa6ZpiQpcrQ1qTJFE2r6KwjItsea+8onDngBTqCZWcqUuWadASBa9BXLC
	225WVPnbOaaVA7pABTdsXsbdwIjZmNjFpS+LSx84qP0xfxoVpQV1tU851f/qbFjuIeCXCyxijOW
	oFmFJaUJiQoJO+F8JqoeccJwCgF/XeFRGEo2DNJYUQ2LXcnqQ7dJFiwDrzOPZj6dL8K3iwfyDwK
	LiMCN331mqrY7l4AP53E/TRHk79y3zT5XLUI/9VzVw7C91325u5OIDobq6IDQm0THWBsYxUUzXK
	6ZRmBvmTEG7tIf0fcIwUQJYNlG+y4WccDFe1eQck0RclXQos9ZRAreW6SiNS4w==
X-Google-Smtp-Source: AGHT+IFMv8bu0m27u2LS9xl92WVoIQiq1lJomkTVzxr/fkT/yA+qAqn9LrlPkQuXJO/lTMmkxi5V9w==
X-Received: by 2002:a17:907:e98a:b0:ad2:4da7:7e2 with SMTP id a640c23a62f3a-ad536f38a4cmr1464187266b.54.1747722512328;
        Mon, 19 May 2025 23:28:32 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 08:28:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 4/5] xen/console: remove max_init_domid dependency
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250519201211.1366244-1-dmukhin@ford.com>
 <20250519201211.1366244-5-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250519201211.1366244-5-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.05.2025 22:12, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> The physical console input rotation depends on max_init_domid symbol, which is
> managed differently across architectures.
> 
> Instead of trying to manage max_init_domid in the arch-common code the console
> input rotation code can be reworked by removing dependency on max_init_domid
> entirely.

... at the expense of doing (worst case) 32k iterations just to find nothing
(else). Iirc it was to avoid this why max_init_domid was introduced.

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -2460,6 +2460,35 @@ void domid_free(domid_t domid)
>      spin_unlock(&domid_lock);
>  }
>  
> +/*
> + * Find the ID of the next possible console owner domain.
> + *
> + * @return Domain ID: DOMID_XEN or non-system domain IDs within
> + * the range of [0..CONFIG_MAX_DOMID-1].
> + */
> +domid_t domid_find_with_input_allowed(domid_t hint)
> +{
> +    struct domain *d;

const?

> +    domid_t domid = DOMID_XEN;
> +
> +    spin_lock(&domlist_update_lock);

Why this heavy lock? Other functions iterating the list just use the RCU
read lock.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 06:40:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 06:40:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990474.1374425 (Exim 4.92)
	(envelope-from )
	id 1uHGeP-00015L-3z; Tue, 20 May 2025 06:40:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990474.1374425; Tue, 20 May 2025 06:40:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHGeP-00015E-09; Tue, 20 May 2025 06:40:33 +0000
Received: by outflank-mailman (input) for mailman id 990474;
 Tue, 20 May 2025 06:40:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHGeN-000158-Q0
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 06:40:31 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 523b46b3-3545-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 08:40:29 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-600210e4219so7740314a12.0
 for ; Mon, 19 May 2025 23:40:29 -0700 (PDT)
Received: from [10.1.250.198] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d04e80asm684191666b.2.2025.05.19.23.40.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 19 May 2025 23:40: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" 
X-Inumbo-ID: 523b46b3-3545-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747723229; x=1748328029; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=EHrIl9SqLhG+x93e+6uTHRwIrOR2ARkYPPXCETZs/8Y=;
        b=SYPdvvQXYnNuAdjUiFMuXxkR499aFB2M3yuCaxc2PRkF8Auqjg/M63NilhavWps9Nt
         wFdE5jDokzWQpxkKOrDSWdh7XjdztRsgONZsAvCwgkLmT52ZBKJi1QXIu/tEp6kGIztI
         AjXNb2gAMxzPwg9oT4QOeJXtyVKE6LfLJoZjs8RK1Q0+IFcEmfUinZJjL732CyLrI76h
         Ik91Ig3ptUcO3cCp8HkM5WZCMvMSrplkar9kskE0y0qPURBMbTDFS2BcZH8BncqWY122
         cw4YsKJUiveXB4ZbSnx3m/C5yNxsJ7tXKE+V+8rwpbCCEvfXslzuOTyeruOxPcpGnnmY
         NRBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747723229; x=1748328029;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EHrIl9SqLhG+x93e+6uTHRwIrOR2ARkYPPXCETZs/8Y=;
        b=tBUir2YtO/gEHt8gCykTlLbGO6yt7jddNqWim/5LTQ17qkPtn9xiGKonQZ0Uz3Z3lB
         EW5c2pC5VXXjveumCNFqq7kj068/v4mZZdWsckln8g8vvu59bjeyUmOQfUsSEhJxS6pN
         JBRIv3h+UJDYdDOSPY1hIBF4YceDnGiNmkthnGOosfnkegg81cSbF06hqYZjXmxMofbY
         et/z1oJw7b0gFSLph4xX1OE5V8iBjxFCtHzAIUJtbC5TvyQjUKflz8G8sr8HOQR14ZXO
         NQ68NJXUGe8caZMUPGsRjjXsA80UMpDUcXdM13FpYm0JuO478LAyEPOHPK6QFuT7HRfq
         x+aw==
X-Forwarded-Encrypted: i=1; AJvYcCXS+2MWySa4GsER3dz070f3gkHSC3mNk8Dg4xIboZ+/ttmX3EvIhtrVVenvv8DtIxRf5e7URaQgZZQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzhXLXk+0iWw0j0TXiqbc+I4YTZ/mCIHjiBNEGEdxCAp1xst5/Z
	D9+GEZ5VJZ2RKUbnWCxKcGXYz/UOSjQZIQ1WgJRohbQtA91u1jA8HCGQ4TrKtslQmw==
X-Gm-Gg: ASbGnctRlOd/XJa+CluWI5vQesQQPi9kp4ln6RLYwc9AOeY+FUvC4UTnxh6JMUTTVm0
	jm6w/ZFidKkQGosZigEkRKFLtq3v2Y7ofc345zwEo2d8TSDbR3jRGukiCgo1F2rqK51M1gtsnZV
	4P1wmZRvALLa58fEFO7l7+2eIe4HGbuovIi6YqwrwPeAevP4XVgP4xw0aWJF+eP2hBE7Eo81iQX
	xSWhiR74RZ7M7OxnDe9rUT/dNV2zcwcMYul3fxBsM0LChzETh5iCwMCDTT6bEp+37BtJb2EXMI4
	WE+ikNJjxp5XyWLx3SXJl5vWHoLR6oX1udOxEsrgZTnfd3CcqiOvEHdLQjigIQ==
X-Google-Smtp-Source: AGHT+IHkndoa/Zy0Fo1vR3SHULvhrEuM+DuAka39CJBDS6RXuZT39cVrzmEJu0sxzprWWoTFtQQWWg==
X-Received: by 2002:a17:906:4ad8:b0:ad5:46a8:1ca4 with SMTP id a640c23a62f3a-ad546a82c11mr981906666b.7.1747723229294;
        Mon, 19 May 2025 23:40:29 -0700 (PDT)
Message-ID: <8d89f644-4ded-4490-ad23-518563d230d2@suse.com>
Date: Tue, 20 May 2025 08:40:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
To: Jiqian Chen 
Cc: Huang Rui , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-10-Jiqian.Chen@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250509090542.2199676-10-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 11:05, Jiqian Chen wrote:
> When init_msi() fails, the previous new changes will hide MSI
> capability, it can't rely on vpci_deassign_device() to remove
> all MSI related resources anymore, those resources must be
> removed in cleanup function of MSI.

That's because vpci_deassign_device() simply isn't called anymore?
Could do with wording along these lines then. But (also applicable
to the previous patch) - doesn't this need to come earlier? And is
it sufficient to simply remove the register intercepts? Don't you
need to put in place ones dropping all writes and making all reads
return either 0 or ~0 (covering in particular Dom0, while for DomU-s
this may already be the case by default behavior)?

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 08:04:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 08:04:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990499.1374435 (Exim 4.92)
	(envelope-from )
	id 1uHHxQ-0003AC-1P; Tue, 20 May 2025 08:04:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990499.1374435; Tue, 20 May 2025 08:04: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 1uHHxP-0003A5-Tz; Tue, 20 May 2025 08:04:15 +0000
Received: by outflank-mailman (input) for mailman id 990499;
 Tue, 20 May 2025 08:04:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHHxO-00039z-LQ
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 08:04:14 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20620.outbound.protection.outlook.com
 [2a01:111:f403:2009::620])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 035fa9c4-3551-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 10:04:12 +0200 (CEST)
Received: from BN0PR04CA0014.namprd04.prod.outlook.com (2603:10b6:408:ee::19)
 by MN6PR12MB8541.namprd12.prod.outlook.com (2603:10b6:208:47a::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.32; Tue, 20 May
 2025 08:04:07 +0000
Received: from BL6PEPF0001AB58.namprd02.prod.outlook.com
 (2603:10b6:408:ee:cafe::10) by BN0PR04CA0014.outlook.office365.com
 (2603:10b6:408:ee::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Tue,
 20 May 2025 08:04:07 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB58.mail.protection.outlook.com (10.167.241.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 20 May 2025 08:04:07 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 20 May
 2025 03:04: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" 
X-Inumbo-ID: 035fa9c4-3551-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TIypA6XZO+C78W9rk/mkCjTKo6zWtGxdy4+YGVqGhj7BtV61E3aW8ui8FAP9fFgzMCyXy5jzAKwDxVE3crvArseuKgy5UXebgLsK3RlbTuIaH9do7TfFql+1cXE65pRDfPVgXP/jZZmOIn8Gu/ErYNRpyMygaLg7c2Wu5KVTOancWzXsMVyiVj2EmoNGEXppndv246qbRhX4zdHVhvcNyn00ut4aizzqdFHj9RFHlD4am1hRsxkTc6WpF0ZTPtu2WLs3CghSr7giZagq5c+MpD5hRF4n9hvugy2IGf5YJgfy/kIid1i6aKlkvAMtuiuv+RFc3LjgwlMaRo/OWPoYIg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YX6goDAVlJoNdyg2xOdb685OsB6OXZAfj6LzRDkuLh4=;
 b=VCJ6BwDHt+ALCEgjKxpx/4XSJ5UijMTO/FWlSJiR2VDRWI8tZUrivPcX517edy25HUIvEFu+A6Ynnf9MkMrHqNQulfyc7odV9khMQNOWm/OY8+ui6lXEk/GebON/ODPypp2j/5KwDM9tGo6mEbkBj85NP3gHqcWoRnusZhPUog4bPad3dEgx+JsiKLlWmRkUPMUdQEsAGDEdm0o0M8ww8IeLqCFeBoH9sM7QixP3X5adLOgE0W2tth7s9WdFP/H1nRZ+yBUh3KgFy8JHVFOCAtKiDKd13LXGHyNMLtgx9+DxYO6ohBYopYU8Mp0zMJPS9x+pseA+iCrwPLTngBGgRg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=YX6goDAVlJoNdyg2xOdb685OsB6OXZAfj6LzRDkuLh4=;
 b=mZcC1Ws9umQ0UInWtDecz89Spb1whu+/W3CicY78jPLuY0LWpKFmIeEoBjcFIbYwD+QlhSVWfJHPdwsUFW7u0fHZM4TfngE4w3EQV3D8ieQ1q46Nwl0QSkUWJmIWnjy7Tj6e2Emi6d23PMei3j8h/AUvp7zLgWhjmtT9AVFfaPQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Date: Tue, 20 May 2025 10:04:05 +0200
From: "Edgar E. Iglesias" 
To: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	"Edgar E. Iglesias" 
CC: 
Subject: xen/arm: Virtio-PCI for dom0less on ARM
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/2.2.14+84 (2efcabc4) (2025-03-23)
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB58:EE_|MN6PR12MB8541:EE_
X-MS-Office365-Filtering-Correlation-Id: 6281d51a-797b-4db1-3967-08dd9774e550
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?aVFUR25Ia0g4NkVFMzdGYXpVVkhNdUpEVzdZVkZmZWhDYjg2dnBHRG0yUVhK?=
 =?utf-8?B?Q1JlSXc0OHN0REJReUVmTTNQQTg1MFl3QzZ4QmpXdkxJc0RSdHBsRmI2YVUw?=
 =?utf-8?B?MFRuejBMZ1dlZUlISktmbXhjSTlYNWluSUdmZGZZbkYxZUxJcCtUdGZuTVoz?=
 =?utf-8?B?c2JaL0xJY3FGMUtIM1E1aDNTSmYySGVoL2RPdUhrOGpzd3NMeTJKZnY5SWJo?=
 =?utf-8?B?czBiT1JRUHNsbVN1UzBodml6RU1Ea2locnFRdGdORjRwL09SVEt6dmJueHZ1?=
 =?utf-8?B?MnJKZHh6MmJmSmR4dTZWdy90SG1tc1JBekVjZlJ2aVg1cEtPM1FiNUhPdjRn?=
 =?utf-8?B?UHZmWFI2bGc2STg4dDlxb3lhTy94cmUvOTdvbmFiZGNHY1NNRXlJTlo4VDdM?=
 =?utf-8?B?cE4zMkRrNHpaZm41bmN5cnIvZW4vUWlxZnJLQ09pRGs2WUM2ZkkwS1M5MGpB?=
 =?utf-8?B?clBiKytFVnpqczFoMUVyRUtnOGZJczhsMlkvNndva3VZRk84STZJS29ia3dy?=
 =?utf-8?B?cUwvQ0JzaDJOTkVDR0ZuempicTMzVlRlNVk1V3ZHc2l6QzNldmxpelIrL0Nr?=
 =?utf-8?B?VkxRWkE2VlJjaHVPc2ZJOWhZSFNqaXlXV013U0l3Q3IreVN4OGhDcG9YbGY4?=
 =?utf-8?B?VDdjSjJoczNxeVRmMVo4TWJ5c3M3enNTd2M4eFM1dXlsRG90NjdVT3F6eDNP?=
 =?utf-8?B?UEwxbVRKWjRFMzZsQkRhdSt3WDhmbHh3enVldzR2RXZQampSalBGUGlFVzJ1?=
 =?utf-8?B?UHJwNk1pR3RaQWFxTml0UVduTHZLcmVMOXpqRzhwbWdRWlBxTkhyZnZkTGM1?=
 =?utf-8?B?dlNtdzdwbnBDYng2VFQ4ckVnajJWVzE1QXg4S0NCZW4rN0lWdEVVZ3A1S2VJ?=
 =?utf-8?B?bmg5K0hOdE1uYm9TODF5Vzk5UkFhSjA3cExBOFJqQ09DYWxjcnluWmJ6S1lz?=
 =?utf-8?B?Q3JDdXdFUUQ1RG1Pak0wZlNYa1lBdTJqMUIxWm9iS083akY5SnlSUlNGQnFU?=
 =?utf-8?B?ZmRQYlhicmNOR2RQc0FLYkk1YllTWEhOenZWQUZuVWZuZ2pNcFZMaDEyYURD?=
 =?utf-8?B?blNCRGFqOXhJM1A4cFRZeWkrcDRRWU1ud2NOZ3RBMjMyWEtuUmpNR0lVQVZY?=
 =?utf-8?B?Ly9neDIvMUhEU0graDR0WkJCdWExamxmeER4SjVSZzNkRDRCcC90RGxobk95?=
 =?utf-8?B?V0NJZFV1bllOd2dkc0lhY2Y1UHNQMjVkRndYU21RcHZCZ3VYT2hEaW5hL0tk?=
 =?utf-8?B?ZTl2Zlo1RDVpUUMyOVNVeGlaTllBUU9PQnRkSHpyU1hZb0gxVzA5ZVdvbDQ1?=
 =?utf-8?B?VTBjSm9lRGVKS2tHYWZ4UWJUamo0OVV2RUMyYmJJejR5MDBTTmsvL3Rnc1Vo?=
 =?utf-8?B?K01ud3V6a2srMjJUcVpKcVdweXlycFg3bkRqcnNKdk9uODRnT05EekxXeU5x?=
 =?utf-8?B?RnozdHFYNE1SZmdUb28zSnZrempYT3VxdkNyaWRWTmNPTjB4dC95eWVzc3NV?=
 =?utf-8?B?NE9GRkhDU1BkTXQ1b3VPS01Uek4rVElnZUFWVHJ0dUpBSGI2RlpPeUMyd3h1?=
 =?utf-8?B?V29BMUluS3VCbFBDRUdkYnRzU3lXMUt2UDFmajJEZDN0ME5Cb2p0VUJ1cHFO?=
 =?utf-8?B?cDB1SFp5U3k1NkJEaXlLWHBTVzFRNCswbng2UklsbmVpUVNkT0VldUJOMDlr?=
 =?utf-8?B?YUdDR0Vkek16cU9zeWt4RXdUZ3UzcGlRMWV1Ymhwdng3OWhMSDRsUGNacTRQ?=
 =?utf-8?B?NUd5TTRFbVJDeDZINnVYK05TYTFGZ2hUeityMmI2Qy8rb0xzck1IcTJQRzVi?=
 =?utf-8?B?VStGb202d2lQRk9jb1ZnaWFqaE5PQjkzczl1bE9zdzlUSjEvbDJOQlo5c2Zo?=
 =?utf-8?B?blp1UitYTTJWM0FEajl6RmNIR3NVMVFLUWxqQzJQa3ZiN0tVeTNwUEtKdkpL?=
 =?utf-8?B?NzZwV0txdEpsTWxoNytxMUozRTJhR1RkbHpMWUxWaS9qaWJKcTI1eDRWUlJv?=
 =?utf-8?B?S05RTHk0a3NKNVRmaUFGSTlFS1Jidno2aEdnQ2hWODdlenpMcEVQcU1TS2gr?=
 =?utf-8?B?WThuQllhRTdLWm1jU3pRc3Nsdjc2ZExmZUNMUT09?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2025 08:04:07.5290
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6281d51a-797b-4db1-3967-08dd9774e550
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF0001AB58.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8541

Hi all,

Following up on the ARM virtio-pci series I posted a while back ago.

There have been some concerns around the delayed and silent apperance of
devices on the ECAM area. The spec is not super clear wether this is OK or
not but I'm providing some references to the PCI specs and to some real cases
where this is used for FPGAs.

There are two options how to implement virtio-pci that we've discussed:
1. VPCI + IOREQ
2. IOREQ only

There are pros and cons with both. For example with #1, has the benefit that
we would only have a single PCIe RC (in Xen) and we could emulate a hotplug
capable expansion port with a standard way to notify when PCI devices plug in.
Approach #2 has the benefit that there is (almost) no additional complexity
or code added to Xen, almost everything lives outside.
IMO, both options have merit and both could co-exist.

For dynamic xl flows, options #2 already works without modifications to Xen.
Users need to pass the correct command-line options to QEMU and a device-tree
fragment with the pci-generic-ecam-host device.

For static dom0less flows, we can do the same as for xl flows but we have the
additional problem of domU's PCI bus enumeration racing with QEMU.
On x86, when domU's access a memory range that has not yet got IOREQ's
connected to it, the accesses succeeds with reads returning 0xFFFFFFFF and
writes ignored. This makes it easy for guests to wait for IOREQ devices to
pop up since guests will find an empty bus and can initiate a rescan later
when QEMU attaches. On ARM, we trap on these accesses.

If we on ARM add support for MMIO background regions with a default read value,
i.e mmio handlers that have lower priority than IOREQs and that are
read-const + writes-ignored, we could support the same flow on ARM.
This may be generally useful for other devices as well (e.g virtio-mmio or
something else). We could also use this to defer PCI enumeration.

So the next versions of this series I was thinking to remove the PCI specifics
and instead add FDT bindings to ARM dom0less enabling setup of user
configurable (by address-range and read-value) background mmio regions.
Xen would then support option #2 without any PCI specifics added.

Thoughts?

Cheers,
Edgar

# References to spec

PCI express base specification:
7.5.1.1.1 Vendor ID Register (Offset 00h)
The Vendor ID register is HwInit and the value in this register identifies the manufacturer of the Function. In keeping with
PCI-SIG procedures, valid vendor identifiers must be allocated by the PCI-SIG to ensure uniqueness. Each vendor must
have at least one Vendor ID. It is recommended that software read the Vendor ID register to determine if a Function is
present, where a value of FFFFh indicates that no Function is present.

PCI Firmware Specification:
3.5 Device State at Firmware/Operating System Handoff
Page 34:
The operating system is required to configure PCI subsystems:
 During hotplug
 For devices that take too long to come out of reset
 PCI-to-PCI bridges that are at levels below what firmware is designed to configure

Page 36:
Note: The operating system does not have to walk all buses during boot. The kernel can
automatically configure devices on request; i.e., an event can cause a scan of I/O on demand.

FPGA's can be programmed at runtime and appear on the ECAM bus silently.
An PCI rescan needs to be triggered for the OS to discover the device:
Intel FPGAs:
https://www.intel.com/content/www/us/en/docs/programmable/683190/1-3-1/how-to-rescan-bus-and-re-enable-aer.html



From xen-devel-bounces@lists.xenproject.org Tue May 20 08:22:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 08:22:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990509.1374444 (Exim 4.92)
	(envelope-from )
	id 1uHIFN-0005o4-Op; Tue, 20 May 2025 08:22:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990509.1374444; Tue, 20 May 2025 08:22: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 1uHIFN-0005nx-Lu; Tue, 20 May 2025 08:22:49 +0000
Received: by outflank-mailman (input) for mailman id 990509;
 Tue, 20 May 2025 08:22:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHIFM-0005nS-2m
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 08:22:48 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20615.outbound.protection.outlook.com
 [2a01:111:f403:2417::615])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 998c0f7d-3553-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 10:22:43 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 PH0PR12MB7983.namprd12.prod.outlook.com (2603:10b6:510:28e::8) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8746.30; Tue, 20 May 2025 08:22:36 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%4]) with mapi id 15.20.8746.030; Tue, 20 May 2025
 08:22: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" 
X-Inumbo-ID: 998c0f7d-3553-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DrSbCukrDVJXUBMc80RytYea3j+3Y3tqQPFew5CucY3Bx/e+QTIYLsgijjbUftsNLyXxMe800dxhEzZW10LztL73Bov+i1SlkaL2DMpm7DpSb/IP+cEDh9PQVNcywPKjZ/cl2FS1fGoEVle6cGKmcZZC801ekFLpZ7KhwsDVOmbYkrUlapJkywcLEd/sy5rar/EB//DdLkqEFM7TaucZtRG0KhB10s1obTsuBg2J55XKQcLb9I/14yKEqhc8p+YytfQefDo9BwlpfXvQ6OcWhqxCskVIm7X1axvF0+iAxDC/XhXQxZmlSGAbHei12uSZGYG0EOL4zGSz10prgXkgDA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SBlPrDocIuVJCMmtzEw8NVz7vOKMYo++HFbwBjqO98s=;
 b=sY9nNsOI+AE17Fi+rq6HyqHFYvst5l16OKwp3ylkpQtTLCXx2zDGQvQp6KhfjjQ6o8OAg93u0zQU4hzEKgpzz+N3SW1SIqTKsHr6Zd5uJ6OngseHZc1djqf0645Le1xqjiQeJ276pXcihrfIEnr0fOJQ5ro4d6CaNDJ7NsBbMnGtVvxwU2UimMk7t8mUlM7hzC8GDpwXN0R0nHVHhE6Rak7+sy53ctshzgrFUvF9827Yav3+oNEib+HNN1NaS8hNp4qNWAjMrvegSA7gE3zpU3amnlkxlEs2x1txrl9OUjGxeBAddmtT8ol0MhqHnVxBUSO2DW1bj9kR2/7d6uZd/Q==
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=SBlPrDocIuVJCMmtzEw8NVz7vOKMYo++HFbwBjqO98s=;
 b=iIANIJgIfxjofBGIjC0B/KjmB5onxgRcN03+FDQv5sSyFyT91P/3OlF9ZS1TNe/7cnUbkNyxWT0MFyhMj9u3wSZC6fIog+ICoNqu8UjtreHJhOdemaVNWZya5g1Xu4rnBWN5l7O8HyehKRtzt5aiEVIzrXZ4kGN0Esi9Rld2Y38=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Anthony PERARD
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 12/15] tools/xenpm: Print CPPC parameters for amd-cppc
 driver
Thread-Topic: [PATCH v4 12/15] tools/xenpm: Print CPPC parameters for amd-cppc
 driver
Thread-Index: AQHbrRCuBHJz/5ZpqUqHhc0gdq6hGrO8VLYAgA1zbxCABpifAIAK/PXg
Date: Tue, 20 May 2025 08:22:36 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-13-Penny.Zheng@amd.com>
 <63b3b016-551c-4201-a3b3-db19b27ea649@suse.com>
 
 <75679a60-7ca0-41da-b542-c5b9d5efdfbe@suse.com>
In-Reply-To: <75679a60-7ca0-41da-b542-c5b9d5efdfbe@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=d4103086-8679-476b-bb5f-44c149482b68;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-20T08:21:12Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|PH0PR12MB7983:EE_
x-ms-office365-filtering-correlation-id: 4c233735-e727-485f-f2b6-08dd97777a5b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?N2JiS2xsMktRRmlkWGRoUHJkdEtBeDdKRThsNHRsakdrVGlBZkJZMGxGUDl2?=
 =?utf-8?B?elhDOC9NTVdWeXdaS09FbW92T0ZQYUpkUWpUUlArYTJWbiswYmd2aEhEZHlz?=
 =?utf-8?B?WTlMVFAwVHlQeXNBY3EvRHJQMjUyWHlwYUsveWMxMGx4UGNVSllXK3E1Vys4?=
 =?utf-8?B?bTRBU2IxdStNODhOaEhyOVc3QWNFYmFzaHdNZVdIcEoxMnRKRnFVYVZhV3NW?=
 =?utf-8?B?TjRzZVpmNXRpeDdoY254Z1pSTmwrUDdRVVg5VE1UdlhFYjBsMDVpc0VpUHFG?=
 =?utf-8?B?aFJZeEZ6dTdkMThheUx2RTYvR1VnMzNhVC9SQ3M3SW1DOVpDSnFhNUpCTDVu?=
 =?utf-8?B?ZG4vSDhxbE42Q3hQS1RzMzV0UXl5TU9MWjZ5NVhybHduOU51T2hVQ3NRTlQv?=
 =?utf-8?B?WWxERmsvSzFXSHhWUHNNaGhJbWJKWnFSRFBHRndRYUhUSzUrSjJFRkF6eGNk?=
 =?utf-8?B?dS9tV1EyTGp0UWlmUnh6R0UvbGQxUWY2WGMrazBOV3Z2YUxVa0dlU2tCTWQx?=
 =?utf-8?B?YlMyTTZ5MHZLRVhuVThVbHNkbEx4eS9xZzN0M3pHL3cwV0MvQ0tBL2RYb1lF?=
 =?utf-8?B?b3VtaVE1RFZ0NEk0L1oxc1pLMTY1TGZxMnJUV2NKQWtYbzZqSGk0elhSb01q?=
 =?utf-8?B?Ykh5MXhyV2xKaFF3TGpZNVV5VktGL3RvUnhPUmNVZU9qdzFnaXpZYU84c29Y?=
 =?utf-8?B?cWxaU0R4S0RpMUhvTzFpV0FpOGYrQm91Y1JWZDZlRzFLSEpBS1o2YUc3bmdj?=
 =?utf-8?B?bTZWWi9jR1hrSk45QWhUN0FkVVNlM3hVdWRQT05xSFNzQkRzY3VacW1OLzFF?=
 =?utf-8?B?L3Y4S3ZlOFBQSUM2OEx1clJYYTdFVFhUSEh5SGhVS0VaNkdZbnNTdHVCSG1B?=
 =?utf-8?B?OGxxVTNQMmY5eGVYUGdOaVNOdFhtWWJQMzVLcVBVeW1vSGprRDRqYkVidGpp?=
 =?utf-8?B?MFJTRTlaL0FSMDNHQlJNMnFVVENIbnIzQ0NTN1JyRHZzMzNRQU1NdG9MckNQ?=
 =?utf-8?B?OUZoMjBDWVdjdU03ck54RlU5aHRBZ21jTmNnNWRYeG0rK0xMTmdnWlBpYmRr?=
 =?utf-8?B?RWFKVFEzajJOdExUcC9rUjM3N29NRit6VzNTbjlzdU42dU9UbkI5bEo0dWdM?=
 =?utf-8?B?QzZmVGR3SGdWWDBOWWo4OHpUK2NOb3VHeHJ6Vys5eGlHT2w2M3o3WTVQTi9u?=
 =?utf-8?B?eDBvSDFqTjRxaUNZcDVIZDlrTGVmcHhOR2xocXF4dUlpK3Q3YVJQZFNqWGo0?=
 =?utf-8?B?SlZlTndoNGhBWXd4QlZxWmlySE5QTVY4MldJc2pVRElLMjcva2RzNVVXSDZJ?=
 =?utf-8?B?d0tzYWM3anduZXhWTm9hT2VWelBXTElDNnh6T2R0c3VwZWNsaUl2VnBycE5B?=
 =?utf-8?B?MU5CZ0I3OGdXbGdFeU1TMytqbGNZR0lqbGUvd1hSbXg0OXlhbnR4SjUwK1dt?=
 =?utf-8?B?OGZCWTMzc2d1RTIxeS9YSGVLeTZwZ3IyV1UzL1U4dG8rdGwzY2ZZV2lTTVJi?=
 =?utf-8?B?YWl5anUvSXVJU1VlUXBrS3ZQSGhKcGtUcGMzanhVK2Y1bzkreThqMFVUYmkz?=
 =?utf-8?B?eEZvT1FnVmo2dm12eFV5VWE5UUJsN0VBMDU5eEVNVGpIRUhKSWxqYnlUS2Zk?=
 =?utf-8?B?T2ZkeUYyQWFLdUdhdU5KcHgvWlJpQW91RlJLMk5IYk0zS1Z3M3UrUi9JTDFi?=
 =?utf-8?B?MStCYStQemxLMnRGTEtFbE0xL2dIdklJVnJHdGxRajRhaTVBcXpJZXhWbVdx?=
 =?utf-8?B?dnhmWE5SNUtaai9JdmR1TDRkRVcza1BaSW04UTYwTko4bS9WRlpjV1M5RTN3?=
 =?utf-8?B?MURWOHQyOWIyUHA3OFRTTkhrRzU3Nlgya0J3cHZzOXUwYWMwUTZVM1R4NlZx?=
 =?utf-8?B?SFVic2FGWXkzT0NlL05JRFVYZXhtcUJjOW4zK2s5YTJYWjBZeThneUNhbE9a?=
 =?utf-8?B?SERiMlB6emh4d3c0SnVsTyt3ek5MeHhVK2RFVXhUQVhld01lajV6dmZBZlQr?=
 =?utf-8?Q?e6Esfwb8znCaBmuDMcUAItj78yEScc=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?dnpGUkhNaVc0NDJabDgrTGt1RTI4YmlJWkJ5SGUyUU5vbGZ0RXc4ZXVKc3ZC?=
 =?utf-8?B?VFB3NjNXTmtTRlZ0d0ZyYUF0T3FSZmRoQUpUTE00NWREZnVtUVdacUc3QUNQ?=
 =?utf-8?B?cGtIWjdpQWcxY0lRTGQwWlZkRzRVaWpFNXc0NWtDenlHWXlsTmYvNlphOG0v?=
 =?utf-8?B?MFFUSGIrZEQzcnpWcFAzM0JYTENLQU9LQ2lxdU9BWStlUmVRR3R0M2gyQTZx?=
 =?utf-8?B?Q1Y0OC9MTmhUc0JqVS8vbWxyaVRaQVBrblVCSkdaVEJZc3FINmNhNHlneDdP?=
 =?utf-8?B?UENXOE4wNndYRFkvMW9va0Y5ZjVKQklZRzFuNVBMWmE3c1NFcTJVeGRYSFNh?=
 =?utf-8?B?c1ZER1lTN2JrVGlVTTQ3UzhPQStUandVNW90QUlYZU1FQTdFNTdzR3p3bGY2?=
 =?utf-8?B?eVliQUExV2VrZEFuMG5ybjZNdVl2ZTc1RDJ4SHg3SW5tTk9aaGhRUTR3YnhR?=
 =?utf-8?B?QU5XcGo0WFlFS1FLUkpjTGFyaW5BKzVhZEV2a3dRSHBucTdHampzVklNSStH?=
 =?utf-8?B?SVQxRHNocW9pQjJIejdQc0k0Y04rTWN6dDFiSW5rckFwNVBpZW8zalhBd1kw?=
 =?utf-8?B?WEhrUXkrOENHd3I3WWNWNzlqRnQvQWJrbjZ1MTFXS0xFUnF0OGJrbWE2ZFFp?=
 =?utf-8?B?cE5KSU41S2pnanJ3YlBaYmEyUWZhUi9icXhpdmxSNDRIeVYzTnpSOXhwdzQw?=
 =?utf-8?B?ZytuOTI1ZnJkVEJGNFd2WVczZS9ONnJCN0hidG00KzFLbUhWbFhaTHRpVk9Y?=
 =?utf-8?B?RWNYZVdac2dVKzQ2Tlh0UHUwUWZZTHE0WDljNTdwRjZpK3pmYUtHbWYvcnJE?=
 =?utf-8?B?VHVRZ3R5Nnh6VC9RMDZwNnVpM3JsWHIyV00vU0twVGtuRDhVSVpoQTVwSkJL?=
 =?utf-8?B?VngxTWx6Smh1ZGJ4ZjByVmkvKzI3TkZ0WUQ3Y0JYK3U3OXMxQzRhQ2ljRWZX?=
 =?utf-8?B?M2pnS3p6V24rMjJST3ZyejM1ZmdGZ3lBWXNDcWlnMFpEaE9NdUE1NFlNWXMw?=
 =?utf-8?B?UGVlMGwxWFdoMEhGZ0pJWVZ0K3VJYkJ0eUlOR1JyY3J3MUhISXEwWitwVWFs?=
 =?utf-8?B?THVhT1RFNis5VFM1d0ZuMG5hL3FldVpPbk00Z0pnNVo1NXA4VVZwNFk5aWlT?=
 =?utf-8?B?WlU0RURPNmUwYlNOT0dOYlJEeXNKVzJueUsyN2NDUU1BR1Z0czlmcVQzMitC?=
 =?utf-8?B?SkdnQkcxcFB4NmxKM050ODZFTSt5Q0U2Q2F5T3Jza0hPcmlIbndXWWxVRmFi?=
 =?utf-8?B?NldPUjI0RndSaUhjSmFYZG5BdE9qUm5ab2FhTEdDd01pMGlrREJ3OEdVQlRB?=
 =?utf-8?B?TFVZK3AvRmVrRkxVWHVKMzJKcmQ3ZmhmakFyL3JHUEpQRTQ5OWhETXZ4RkdB?=
 =?utf-8?B?UmlLT2xzRTJlRTRQY3RsMHVoMmN6akQyc2gzMDg2UnRMRDh2ZDFhNjVBa0Vz?=
 =?utf-8?B?WmVHMGFOSDVzMW41TDBvZGhCWEttMmJSUlVFaVhzSjFXSTRkYnVnaHo3em9C?=
 =?utf-8?B?NjdnU3IzcW85TVlxQzFyUTQ5WnBNanNNNkZxcW0xVEVIT205T2U0ZmNnNUxU?=
 =?utf-8?B?VURvL3lWcm5LUXJyZUpaM2ZBSGtWZmpWTG1zTy9EQmt0VFdkWGdYeWdxVGlR?=
 =?utf-8?B?UVJZU2tUZ2lkOWduQmNua3ErWURYVUJlQzlLT2sxSVV1U0VYdjBPM0FNV2tJ?=
 =?utf-8?B?YVpLaHhIVnhSdW1sOE5zVW9QaktrMjJWR1ZINzFueGVMV2dURWM0S0J0ai8y?=
 =?utf-8?B?TEpzTXNNWGk0dENpNUNwc2xkaWdBRmxFVGFKOU5QN1ZkcE9KVDlpdnYzcjVl?=
 =?utf-8?B?eTBuSGRaQzR4WnZOWVV3cUpoMUxLSmVXelkzVXM0SThWV3dJaTlSM2R5VWFl?=
 =?utf-8?B?dC9DUmR5RExweGlFOHRmVG53UTl3WDJNTVlMSWQ5TzNlbUk1K0ZDQ0pWSnJv?=
 =?utf-8?B?QysxRHFxVnV6c05zKzhMenUvM1BSdEJ4SU1XQXMrQXFaU1hpVmpUWGJXL3Jm?=
 =?utf-8?B?UjVSbVVmNHptcXBSRFQ0dXJLRXVzQkhnaHBCcTZ0c3pkVFBYa0RURC9MNlE1?=
 =?utf-8?B?N01wbWtOQWlPUkFxLzFLSFJMWDcyazdMbEN1MCtwWVcxY1RrZHU4YTgzcFFR?=
 =?utf-8?Q?ExZI=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4c233735-e727-485f-f2b6-08dd97777a5b
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2025 08:22:36.5751
 (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: uSx7ItL9w4PprOysHFSC5xws9Es/RTjd6NJrIGgqHLKZs1FODtArTlLIm3gor9PD57GLJGaCwNpmWsTGuD1eSg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7983

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAxMywgMjAyNSA0
OjAzIFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+IENjOiBI
dWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFudGhvbnkgUEVSQVJEDQo+IDxhbnRob255
LnBlcmFyZEB2YXRlcy50ZWNoPjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggdjQgMTIvMTVdIHRvb2xzL3hlbnBtOiBQcmludCBDUFBDIHBhcmFt
ZXRlcnMgZm9yIGFtZC1jcHBjDQo+IGRyaXZlcg0KPg0KPiBPbiAwOS4wNS4yMDI1IDA4OjM2LCBQ
ZW5ueSwgWmhlbmcgd3JvdGU6DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+
IEZyb206IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gPj4gU2VudDogV2VkbmVz
ZGF5LCBBcHJpbCAzMCwgMjAyNSA5OjU1IFBNDQo+ID4+DQo+ID4+IE9uIDE0LjA0LjIwMjUgMDk6
NDAsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiA+Pj4gSFdQLCBhbWQtY3BwYywgYW1kLWNwcGMtZXBw
IGFyZSBhbGwgdGhlIGltcGxlbWVudGF0aW9uIG9mIEFDUEkgQ1BQQw0KPiA+Pj4gKENvbGxhYm9y
YXRpdmUgUHJvY2Vzc29yIFBlcmZvcm1hY2UgQ29udHJvbCksIHNvIHdlIGludHJvZHVjZQ0KPiA+
Pj4gY3BwY19tb2RlIGZsYWcgdG8gcHJpbnQgQ1BQQy1yZWxhdGVkIHBhcmEuDQo+ID4+Pg0KPiA+
Pj4gQW5kIEhXUCBhbmQgYW1kLWNwcGMtZXBwIGFyZSBib3RoIGdvdmVybm9yLWxlc3MgZHJpdmVy
LCBzbyB3ZQ0KPiA+Pj4gaW50cm9kdWNlIGh3X2F1dG8gZmxhZyB0byBieXBhc3MgZ292ZXJub3It
cmVsYXRlZCBwcmludC4NCj4gPj4NCj4gPj4gQnV0IGluIHRoZSBFUFAgZHJpdmVyIHlvdSB1c2Ug
dGhlIGluZm9ybWF0aW9uIHdoaWNoIGdvdmVybm9yIGlzIGFjdGl2ZS4NCj4gPg0KPiA+IFdlIHdh
bnQgdG8gaGF2ZSBhIG9uZS1vbmUgbWFwcGluZyBiZXR3ZWVuIGdvdmVybm9yIGFuZCBlcHAgdmFs
dWUsIHN1Y2gNCj4gPiBhcywgSWYgdXNlcnMgY2hvb3NlIHBlcmZvcm1hbmNlIGdvdmVybm9yLCBu
byBtYXR0ZXIgdmlhICJ4ZW5wbSIgb3INCj4gPiBjbWRsaW5lLCB1c2VycyB3YW50IG1heGltdW0g
cGVyZm9ybWFuY2UsIFdlIHNldCBlcHAgd2l0aCAwIHRvIG1lZXQgdGhlDQo+IGV4cGVjdGF0aW9u
Lg0KPiA+IEFuZCBpZiB1c2VycyBjaG9vc2UgcG93ZXJzYXZlIGdvdmVybm9yLCB1c2VycyB3YW50
IHRoZSBsZWFzdCBwb3dlcg0KPiA+IGNvbnN1bXB0aW9uLCB0aGVuIHdlIHNoYWxsIHNldCBlcHAg
d2l0aCAyNTUgdG8gbWVldCB0aGUgZXhwZWN0YXRpb24uDQo+DQo+IFRoYXQncyBhbGwgZmluZSwg
YnV0IGNvbXBsZXRlbHkgbWlzc2VzIHRoZSBwb2ludCBvZiBteSBxdWVzdGlvbjogSWYgdGhlIGdv
dmVybm9yIGlzDQo+IHJlbGV2YW50LCB3aHkgd291bGQgeW91IGJ5cGFzcyByZXNwZWN0aXZlIHBy
aW50aW5nPw0KPg0KDQpUaGUgb25seSB1c2VmdWwgaW5mbyBpbiBnb3Zlcm5vciBmb3IgZXBwIG1v
ZGUsIElNTywgaXMgaXRzIG5hbWUuDQpJIGRlZHVjZSB3aGljaCBwZXJmb3JtYW5jZSBwb2xpY3kg
dXNlciB3YW50cyB0byBhcHBseSB0aHJvdWdoIHdoaWNoIGdvdmVybm9yIHRoZXkgY2hvb3NlLg0K
SWYgdXNlciBjaG9vc2VzIHBlcmZvcm1hbmNlIGdvdmVybm9yLCB0aGV5IHdhbnQgbWF4aW11bSBw
ZXJmb3JtYW5jZS4NCklmIHVzZXIgY2hvb3NlcyBwb3dlcnNhdmUgZ292ZXJub3IsIHRoZXkgd2Fu
dCB0aGUgbGVhc3QgcG93ZXIgY29uc3VtcHRpb24NCkkgY291bGQgb25seSBwcm92aWRlIGFwcHJv
cHJpYXRlIGVwcCB2YWx1ZSBpbiBhYm92ZSB0d28gc2NlbmFyaW9zLg0Kb25kZW1hbmQgYW5kIHVz
ZXJzcGFjZSBhcmUgZm9yYmlkZGVuIGNob2ljZXMsIGFuZCBpZiB1c2VycyBzcGVjaWZ5IHN1Y2gg
b3B0aW9ucyBpbiBjbWRsaW5lLA0KSSBzaGFsbCBnaXZlIHdhcm5pbmcgbWVzc2FnZSB0byBzYXkg
IHRoYXQgYW1kLWNwcGMgaW4gYWN0aXZlIG1vZGUgaXMgZ292ZXJub3ItbGVzcywgYW5kIHVzZXJz
IGNvdWxkDQpzZXQgZXBwIHZhbHVlcyBvbiBydW50aW1lIHRvIHNwZWNpZnkgYmlhcyB0b3dhcmRz
IHBlcmZvcm1hbmNlIG9yIGVmZmljaWVuY3kuDQoNCklmIGFib3ZlIGlzIG1lc3N5LCBJIGNvdWxk
IGFsc28gdG90YWxseSBmb3JiaWQgZ292ZXJub3IgdGhpbmcgZm9yIGFjdGl2ZSBtb2RlLi4uIHdk
eXQ/DQoNCg0KPiA+IE9uZGVtYW5kIGlzIGEgdHJpY2t5IHBhcnQsIGhtbW1tLCBJIGRvbid0IGtu
b3cgd2hpY2ggdmFsdWUgaXMgc3VpdGFibGUNCj4gPiBmb3IgaXQsIHRoZSBtZWRpdW0gb25lPyBT
byBJIG5lZ2xlY3QgaXQgaW4gdGhlIGZpcnN0IHBsYWNlDQo+DQo+IE1lZGl1bSBvbmUgbWF5IGJl
IG9rYXktaXNoLCBidXQgaXQncyBub3QgcmVhbGx5IGFuIGFwcHJvcHJpYXRlIGZpdC4gV2UgbWF5
IHdhbnQgdG8NCj4gYXQgbGVhc3QgY29uc2lkZXIgcmVqZWN0aW5nIHRoZSB1c2Ugb2Ygb25kZW1h
bmQgd2l0aCB0aGUgRVBQIGRyaXZlci4NCj4gVGhhdCwgaG93ZXZlciwgaGVhdmlseSBkZXBlbmRz
IG9uIGhvdyBoYXJkd2FyZSB3b3VsZCBiZWhhdmUgd2hlbiB1c2luZyB0aGUNCj4gbWVkaXVtIHZh
bHVlLg0KPg0KPiA+Pj4gLS0tIGEvdG9vbHMvbWlzYy94ZW5wbS5jDQo+ID4+PiArKysgYi90b29s
cy9taXNjL3hlbnBtLmMNCj4gPj4+IEBAIC03OTAsOSArNzkwLDE4IEBAIHN0YXRpYyB1bnNpZ25l
ZCBpbnQNCj4gPj4+IGNhbGN1bGF0ZV9hY3Rpdml0eV93aW5kb3coY29uc3QgeGNfY3BwY19wYXJh
X3QgKmNwcGMsDQo+ID4+PiAgLyogcHJpbnQgb3V0IHBhcmFtZXRlcnMgYWJvdXQgY3B1IGZyZXF1
ZW5jeSAqLyAgc3RhdGljIHZvaWQNCj4gPj4+IHByaW50X2NwdWZyZXFfcGFyYShpbnQgY3B1aWQs
IHN0cnVjdCB4Y19nZXRfY3B1ZnJlcV9wYXJhICpwX2NwdWZyZXEpDQo+ID4+PiB7DQo+ID4+PiAt
ICAgIGJvb2wgaHdwID0gc3RyY21wKHBfY3B1ZnJlcS0+c2NhbGluZ19kcml2ZXIsDQo+IFhFTl9I
V1BfRFJJVkVSX05BTUUpDQo+ID4+ID09IDA7DQo+ID4+PiArICAgIGJvb2wgY3BwY19tb2RlID0g
ZmFsc2UsIGh3X2F1dG8gPSBmYWxzZTsNCj4gPj4+ICAgICAgaW50IGk7DQo+ID4+Pg0KPiA+Pj4g
KyAgICBpZiAoICFzdHJjbXAocF9jcHVmcmVxLT5zY2FsaW5nX2RyaXZlciwgWEVOX0hXUF9EUklW
RVJfTkFNRSkgfHwNCj4gPj4+ICsgICAgICAgICAhc3RyY21wKHBfY3B1ZnJlcS0+c2NhbGluZ19k
cml2ZXIsDQo+IFhFTl9BTURfQ1BQQ19EUklWRVJfTkFNRSkgfHwNCj4gPj4+ICsgICAgICAgICAh
c3RyY21wKHBfY3B1ZnJlcS0+c2NhbGluZ19kcml2ZXIsDQo+ID4+IFhFTl9BTURfQ1BQQ19FUFBf
RFJJVkVSX05BTUUpICkNCj4gPj4+ICsgICAgICAgIGNwcGNfbW9kZSA9IHRydWU7DQo+ID4+PiAr
DQo+ID4+PiArICAgIGlmICggIXN0cmNtcChwX2NwdWZyZXEtPnNjYWxpbmdfZHJpdmVyLCBYRU5f
SFdQX0RSSVZFUl9OQU1FKSB8fA0KPiA+Pj4gKyAgICAgICAgICFzdHJjbXAocF9jcHVmcmVxLT5z
Y2FsaW5nX2RyaXZlciwNCj4gPj4gWEVOX0FNRF9DUFBDX0VQUF9EUklWRVJfTkFNRSkgKQ0KPiA+
Pj4gKyAgICAgICAgaHdfYXV0byA9IHRydWU7DQo+ID4+DQo+ID4+IFBsZWFzZSBhdm9pZCBkb2lu
ZyB0aGUgc2FtZSBzdHJjbXAoKXMgdHdpY2UuIFRoZXJlIGFyZSBzZXZlcmFsIHdheXMNCj4gPj4g
aG93IHRvLCBzbyBJJ20gbm90IGdvaW5nIHRvIG1ha2UgYSBwYXJ0aWN1bGFyIHN1Z2dlc3Rpb24u
DQo+ID4NCj4gPiBNYXliZSB3ZSBzaGFsbCB1c2Ugc3dpdGNoLWNhc2UoKSB0byByZXBsYWNlIHRo
ZSBzYW1lIHN0cmNtcCgpcyBTaW5jZQ0KPiA+IGl0J3Mgbm90IGVhc3kgdG8gc3dpdGNoLWNhc2Uo
KSBzdHJpbmcgdmFsdWUsIEkgaGFkIGEgZHJhZnQgaWRlYSB0bw0KPiA+IGluY2x1ZGUgYW4gbmV3
IGVudHJ5IGluICJzdHJ1Y3QgeGVuX2NwcGNfcGFyYSIsDQo+ID4gU2VlOg0KPiA+IGBgYA0KPiA+
IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9wdWJsaWMvc3lzY3RsLmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvc3lzY3RsLmgNCj4gPiBpbmRleCBmYTQzMWZkOTgzLi5iODcyZjFiNjZhIDEwMDY0NA0K
PiA+IC0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9zeXNjdGwuaA0KPiA+ICsrKyBiL3hlbi9pbmNs
dWRlL3B1YmxpYy9zeXNjdGwuaA0KPiA+IEBAIC0zMDgsNiArMzA4LDEwIEBAIHN0cnVjdCB4ZW5f
b25kZW1hbmQgew0KPiA+DQo+ID4gIHN0cnVjdCB4ZW5fY3BwY19wYXJhIHsNCj4gPiAgICAgIC8q
IE9VVCAqLw0KPiA+ICsjZGVmaW5lIFhFTl9TWVNDVExfQ1BQQ19WRU5ET1JfSFdQICAgICAgMQ0K
PiA+ICsjZGVmaW5lIFhFTl9TWVNDVExfQ1BQQ19WRU5ET1JfQU1EICAgICAgMg0KPiA+ICsjZGVm
aW5lIFhFTl9TWVNDVExfQ1BQQ19WRU5ET1JfQU1EX0VQUCAgMw0KPiA+ICsgICAgdWludDhfdCB2
ZW5kb3I7DQo+ID4gICAgICAvKiBhY3Rpdml0eV93aW5kb3cgc3VwcG9ydGVkIGlmIHNldCAqLyAg
I2RlZmluZQ0KPiA+IFhFTl9TWVNDVExfQ1BQQ19GRUFUX0FDVF9XSU5ET1cgICgxIDw8IDApDQo+
ID4gICAgICB1aW50MzJfdCBmZWF0dXJlczsgLyogYml0IGZsYWdzIGZvciBmZWF0dXJlcyAqLw0K
PiA+DQo+ID4gYGBgDQo+ID4gQSBuZXcgdmVuZG9yIGZpbGVkIGluIHN0cnVjdCB4ZW5fY3BwY19w
YXJhIGNvdWxkIGhlbHAgdXMgZGlmZmVyIHRoZSB1bmRlcmx5aW5nDQo+IGltcGxlbWVudGF0aW9u
Lg0KPiA+IE9yIGFueSBiZXR0ZXIgc3VnZ2VzdGlvbnM/DQo+DQo+IFdlbGwsIGlmIHlvdSBzZXQg
aHdfYXV0byBmaXJzdCwgdGhlbiB5b3UgY2FuIHVzZSB0aGF0IHZhcmlhYmxlIHBsdXMgb25lIG1v
cmUgc3RyY21wKCkNCj4gdG8gc2V0IGNwcGNfbW9kZS4NCj4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Tue May 20 08:28:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 08:28:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990521.1374456 (Exim 4.92)
	(envelope-from )
	id 1uHIKn-0006Rl-II; Tue, 20 May 2025 08:28:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990521.1374456; Tue, 20 May 2025 08: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 1uHIKn-0006Re-E7; Tue, 20 May 2025 08:28:25 +0000
Received: by outflank-mailman (input) for mailman id 990521;
 Tue, 20 May 2025 08:28:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHIKl-0006RY-VE
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 08:28:24 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20630.outbound.protection.outlook.com
 [2a01:111:f403:2415::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 63ced086-3554-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 10:28:21 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 PH0PR12MB7983.namprd12.prod.outlook.com (2603:10b6:510:28e::8) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8746.30; Tue, 20 May 2025 08:28:17 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%4]) with mapi id 15.20.8746.030; Tue, 20 May 2025
 08:28: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" 
X-Inumbo-ID: 63ced086-3554-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DL+43X8fD0UMWRkn29+PMfP0DCavQUyulMB8Rs6qLZJP1b3m7vpTHEQGSeDvW2LCIupEuO+5aJgBxMOZn/dNQXq0e7BmGa/V0n9pDFmUPh1xjc0gsa8Yh0zlfdtr/Y/Htr6ykt4rW0aKHQF+R9J5FHx5j4MSUICk4YzsTLtstGNNMil9tkLgPe76P6tEctesZRjfVU1DeJwGEPZ4bhXEnJF6yFsYy68oTdybSusV18xaGl3w9doSiPQyuWdr2AWf4CmfIZ4Yc4XWUatlZckKY7deWHWTxyOsxBX4k6kZZfFIIY/LgsXdn/ZQt4JLiIRm2g2VPOybAfr3+ry+/mRceQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tSt8KIMbBE9T/BjAVcrNZHKbqoYKvm2QZj7MqZe9Mtc=;
 b=IrWw8Y+S5X9zoW4sm3rbBDZjpD7FisZSBQlH0zSEed+YKF24lvhcwSGrUsMiDzp+V24r0hMLc1Zm1MC2gyCmEdyNvX5TGHCpgkYgj20YNrXm/igqxxY5aExL86ls2FsVu07GINMnn/ULq9znnSA7RtJpYd+LUoFJwNuc0TGjPqTx2TRsOrkXGg0LfDIGyZweLCXStJ4iNgZRw/8h4RhSK+KJS++P3OzsILyH+l84m+40E6V/ZJq4PD1R11aEs9vGGnmYbJsNuqjxCPydaSi6IB/V5w25QAs0rSHnay69Q3twNlQIVx6i6qnYRWn+HlwbwDf4k2hK7uaePEitj0hPjw==
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=tSt8KIMbBE9T/BjAVcrNZHKbqoYKvm2QZj7MqZe9Mtc=;
 b=NLfHu6fmL2rDTUg1diBKexSjGdRF5KUSYys2TG0FyI7xolZvR0NaqSkJIO30IQPSymwKz8RnO0PPCyyb5GvM1Eh8GTVaqS6/sFm7OGN4ZcTPRQ/8/NZqbdu0c93YdFuEM9Ot9N8W9nX2jT/cNRxzgSFtDdmrkqU28ekp8Sf8/XU=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Topic: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Index: AQHbrRCmtZ7pr/knH02upOrsNIOYE7O6sNeAgB8mXDCAAE/jgIABP6gA
Date: Tue, 20 May 2025 08:28:17 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-6-Penny.Zheng@amd.com>
 <57a3b2c0-d57d-46e3-b248-0e243f715423@suse.com>
 
 <0f673a09-840c-4319-bec8-62fd920a6b84@suse.com>
In-Reply-To: <0f673a09-840c-4319-bec8-62fd920a6b84@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=b208c07d-842e-4be4-bd2a-6feae91cb225;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-20T08:28:08Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|PH0PR12MB7983:EE_
x-ms-office365-filtering-correlation-id: a942e9d5-7e14-44d9-55cc-08dd97784555
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?ZUNKeTJxM0t2UUhpZ2ZXR2RXTEJ4bGFRR3ZuMm5IejhXazMzN21lLys3SE9U?=
 =?utf-8?B?Q3ZkQ0cxNFIrVzArSzRzblFpNllXRm1ZQmxtT2xWZ1h4N3F2NUJySkNlNGtF?=
 =?utf-8?B?ZHM5SFdWbUNlc2kwOGdpdVhyZDZBbW9BYWhJRXBrQU1sUE5HSGVUdHg3QmZW?=
 =?utf-8?B?cVJkcnBNNzY2b1p2M3ZhekxxZ3JJTFZ0VEZrdDZEaW1vZTc5ZzVSeW5ncS90?=
 =?utf-8?B?UE9kbHR6djN3SDJDU2d2SnNPV29CTVZORW1yQnFPc3V6bGpaREFQakltSjNB?=
 =?utf-8?B?eUkvODhPWUVPZ1krT2tLbExmRDVKYTB3WWJPbW9kVFdjMnJlT1lCem56L1Nj?=
 =?utf-8?B?TGNoZGQ2QzNQbHcyNnMvZGl0cFZvQVZ1RXJDMWw0SG1JaENnekI4WWxhTEFF?=
 =?utf-8?B?ZG4xL05jbEI1MmNrbTlkcy94elptRFVUMmdrRUVtWklwWE1MNjhzRFM3aUdL?=
 =?utf-8?B?azA3RnJwQ1REZFBMNVNlNlo5ZEE3ZDBtZllqdjBwS1dFR1lpbUY5TEFnaFFq?=
 =?utf-8?B?ZmJnSjdXeEU2K2FDNGxxc0dQSTA4WG5ES1BrWkRYdmx3QzVwY21OVXNXdjJ2?=
 =?utf-8?B?UDRlOUVqT1F1K0lsenUwZXc1WmpaSStDY2RYTGpSaVl0NFhxZzFMdnN4K3Vk?=
 =?utf-8?B?TjZ0clphN3czL3NLMENndEdrOGNtdnh3V29Ga05YWDlYVVNjOGpBdUdwdHpB?=
 =?utf-8?B?ajFrMmxCc2VSbVRLOTNDTkkvQzcyNWtaUzFWNytPRUo5WTdoZFF6ZFBlakdi?=
 =?utf-8?B?QUN1OStzVU9TM0hJVmgzeXl0UWl1TVNNc09IN1ErZ2ZJS0Y4MWNibG0vT2ZH?=
 =?utf-8?B?V1BPUy9rQkpmS3Z3c0Mza2JaOEwxcHRGajJ5emhPbjg3THhZK050RklUTkI2?=
 =?utf-8?B?UWVOMG9GRDB2NzUxUlFLSTg2aUtCbVBtZnhtNEZpbk0wNFRRaFR1YnhVaHJN?=
 =?utf-8?B?Rnp4MW9pZmFBL1d6UE0rUFVMNTFoVFY5QkZiNHJ3Vit1RXhoQXNtbkJ0am5R?=
 =?utf-8?B?aHB3WTdQNDRIcnBHS2JFSlNRS3NnUWtkYlB6cTkvYWYyV1gvMnBoeWpQdHM2?=
 =?utf-8?B?TmQvQkQwMG9BUUlrMTFIWThIeHFwSllianVHSUVQWEhjYjJHaVJteERxbDFD?=
 =?utf-8?B?bG84ZmYvcmNjY2xtUDY0aUx2MjlDNFY3ai93R3IvajR0WUxjRHJndnZyZ3ZB?=
 =?utf-8?B?Q1BtRTZET2EyNkYyZ0dUcjlVaWoyZ0FXYU5Ld3lSamw1L0VtR280TEtQM25B?=
 =?utf-8?B?SXNvak9NRjVVNFJZbXR0SHZsTmlaMHhKcVRneUdBRFN5aWZnVm9nTjFFQzQx?=
 =?utf-8?B?MElRbTJtM29KcStNUGVZV0sxUlI4Y0x1SndtM3k0aUJHYzBWY1BQdXFrR01N?=
 =?utf-8?B?NHdNcmU5WEc3ZkxwMmxtY1IyK1MxZHFUY2kwVzdOT1ltVzZtVDZOTm9BTUU4?=
 =?utf-8?B?WVZnNTcyYnM4ZXFJcURnSzBrb1k2MUtwOUt2Qm5GaTY5TTBYOHFWdVdxbDM4?=
 =?utf-8?B?Z3I2RnZrbDBBVVlPWTNSVTRMNHkrRkZtWFUvZGkremZENXlaSkZUTmVXV09q?=
 =?utf-8?B?a3RlYjRscUd3WFBQV1BwNVNZak1RNkwva0tzL3lPYjFNaDdvd1ZWU1ZpdzF1?=
 =?utf-8?B?aytFOHpmeW1mM1pjQVBYV1djekgyUTBYSFUwMVdHY0phM3FleU9iZEwzeDFB?=
 =?utf-8?B?TUQzTE5iRmxURENhV2Z0Ymw0d2p0Q2lwK1JYejlBME1zOHo2dEZiVU5KTzVU?=
 =?utf-8?B?bmhoQ1dMNHlWaS84WEQzZjNmZ0lCOHNONTNBWnFmMm5SMHM1cWY2WlpZdzFH?=
 =?utf-8?B?SStNa2gvbGQwb3ZHQlhwbXVWUkt5ODZZOWRnTVJmUFJVc2crYTJtZ3BrYi96?=
 =?utf-8?B?c29BV3ArZnpZL1VNTnNWU0VBU3E0Rnl6VXFCbXRudlRmUXcwZVFBRTNWZWV5?=
 =?utf-8?B?THVoSG5zOW5FMG81Y1BlRXBKMXZqcWpRYVVCZUZRUXBBMjBpQVJ5MC94NXhl?=
 =?utf-8?Q?jTjRytjiin+IdFJSluMAJpniqk0lYk=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SVBlTDdqRTNJNjdrSFhJQkRmVnBoYmVOV1Y1L3I3TmhIdUhRdFhSV29sWkto?=
 =?utf-8?B?NzNJcG43K0JFZGdWQUNsQWpJNFhkTGs5QU1JREJTSjRNL2VPMDdhWEw1SVQx?=
 =?utf-8?B?SVE0OGdabElTWm5maGFPVlROTm5QNUFFYldNTDRDL2pMLzdoRzdydGRiaUo2?=
 =?utf-8?B?cjlJTkJ5MlBKYTFmcGM0NmhuSTBwd2xlbXgxWHRIYTZ2M0QrNkprSTBDbzJa?=
 =?utf-8?B?MURyR291K3MrL0pjRHFmUndsYkdkSEFpVnNPOUgrV2YvNWFCclBtSnJFWGdX?=
 =?utf-8?B?dDZVb1pRNjRobzBmQ2NDc2RhY3E5aFBJOGlZL2ZwdW9rUko2OWFSQUhYTjd2?=
 =?utf-8?B?aGl5eURNeU5hN2pXb2NJYjJnRzF0d2NsNU9pUTVlanc3NXU2Y01BOEtGeGpq?=
 =?utf-8?B?N3ZJaXBhUXNMbXlNVWU2cmR1ZUFNVG0yZjhBYXljTG9OZXMvNHVJVEVINUw1?=
 =?utf-8?B?NEZvb200SGhqWk51NEY0bXVHNk1Ta1BMSFlRRENXL2t6cXpRZHF5VUpBcFI3?=
 =?utf-8?B?QjRlT05jRzF6SE50R01ya0VBd1hHVHhSUWhBTm96d3FLVzJaMm5uUnlodll3?=
 =?utf-8?B?dmJIVjlvaTJYK2VDd09iNnJtbU9PNFJHcFVhWkc5OTI2UHZscDBFSG5QQlEr?=
 =?utf-8?B?amllMlU0c3N2TlNxaFI1UHd1NjR6L2s5eU9ZdVlQUjA0NGhjM0lHRzNZa2Uw?=
 =?utf-8?B?ZXdlMmtvbnU3ZmN1OEN5YzRLaUUzSlFvTC8vamcvZkVMTnhLa0R2SEQ2bjJy?=
 =?utf-8?B?V3prMkR3cHBYVDBWcHhoR1VHci9may96RG9MSVNianBVdG5qNDNvTC9zdmRn?=
 =?utf-8?B?ZWlGV2lnWGRWQ1Bqa2hncitWZHl5UFc5L0NYOUFrNFIycVgvNVp5NFB1cWN3?=
 =?utf-8?B?MWtjRjFhTmVxcUZCTkxLcnBTcldLa1BoVCs4RFVFZzdsVHEvWHlKNCs5MVAw?=
 =?utf-8?B?Sy9NUHZhdXRjTjUySWZXQkZ3UWdaWWp6REM0bDcvOENyaHVlRXorTDNYeTQ3?=
 =?utf-8?B?bnlEOGNLU2dKbHNrK2Z2SHlta3UvVjA0L01kZmdMT0dMa3p6cVVxUTBBcnFm?=
 =?utf-8?B?L0k0TnM4NmU2RjUzdFd6UUFaNFROM0JOci9lKzNZajhYbjZrOXpYc3VvWW9V?=
 =?utf-8?B?eDUzV2k2YVJsOFdYWDZxUTlWSE1ENkRRRVNKVEFNOHA1U2FKaXFPNGJ1a1pL?=
 =?utf-8?B?R0RRTnY3a0t1bCtlT1NFTlhKNEgxYkZDQ1FtOTR4NU5tMmp4cEZtMmFNcHBw?=
 =?utf-8?B?M1dPZmVST0Nnd01GOXoxcE9YNERtVVdBMXdxUm5uLzZKOWMwbFBCYTA5dDQ0?=
 =?utf-8?B?c3ZuYlBCWHBPMmpuMVo2Ui9hQlRWWCs5RWx1eWoyMS9aZzFjWFlRRmhQa25B?=
 =?utf-8?B?UldnMHo4WDEweUF1NzZucEgvOGlqZnA4ZGNhZi85T1JBenJVaVk4RWdMb0Ev?=
 =?utf-8?B?ajhDWjJMSzBZbkcvdFlRVVBIRmdIZnJwd1BtRm8xejgwRFBaVlV4SXJiQlpx?=
 =?utf-8?B?czRCWmhuczVSaHY0WElwTWtLTFZ4QS9OakdrOUNGVGs2L1lkN0NHUVgvb2pO?=
 =?utf-8?B?cFc2bmJNUTdSazllRFVpWmpVNGFQbGhqL0lmNWVteHBrQUlORjBBS1NzNkNB?=
 =?utf-8?B?KzdqTWU1eDhENFc3QW81SGd5Z2lDT1A1MjdoOEpWNUx5SGtxa1REUEpDWlFi?=
 =?utf-8?B?bmVEL3lTOGRqWFZ4dllKSndKSVV4ZkpLeEtoUHZJSUNOOVQxc2RTVGp5anN2?=
 =?utf-8?B?eWlJRmluK0MwYlRCWHduWWpxaVZRemEwamxCVS9ZWUY4cks3VmkwUy9PZEFx?=
 =?utf-8?B?blNpYksrSWhkb3hiblp5MVVEdHZxdFdhMEJ2clhrWUtLQ2Z2MzQ2Z0tzcGd3?=
 =?utf-8?B?UmFiQ1F0N2llV2JKOW5OamgrVVluN05wK2JwRjdrdnpGeUZSakZITUpDeTBz?=
 =?utf-8?B?WFdMSXdkT3R6Wlk0TitaRjlrNXNCeGFHWkFMbUNXaFJPQ2FuRGlxbXE1WnBF?=
 =?utf-8?B?bXVzYnZ1bjdyTUZWOWhhZ1hXcUhiOHZibWUrS20ybkhjSVJQVmI4UVBDcURC?=
 =?utf-8?B?MlBSQ25iQ2tUOTN6K2dlNklrR05jVFd4V2hiNmY1YjZXOXQ4QmNSTE9GMzc4?=
 =?utf-8?Q?XkdU=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a942e9d5-7e14-44d9-55cc-08dd97784555
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2025 08:28:17.1483
 (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: THujjlxypwMdp/JoLmW1QeSxw6xcMUngx1coMSKZyvyHknPzxvyQwvsvUz5xEeXLX9eCj20CNFBqsABT7Iw7bg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7983

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IE1vbmRheSwgTWF5IDE5LCAyMDI1IDk6
MTkgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6IEh1
YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5kcmV3LmNv
b3BlcjNAY2l0cml4LmNvbT47IEFudGhvbnkgUEVSQVJEIDxhbnRob255LnBlcmFyZEB2YXRlcy50
ZWNoPjsNCj4gT3J6ZWwsIE1pY2hhbCA8TWljaGFsLk9yemVsQGFtZC5jb20+OyBKdWxpZW4gR3Jh
bGwgPGp1bGllbkB4ZW4ub3JnPjsgUm9nZXIgUGF1DQo+IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJp
eC5jb20+OyBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyB4ZW4t
DQo+IGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjQg
MDUvMTVdIHhlbi94ODY6IGludHJvZHVjZSAiY3B1ZnJlcT1hbWQtY3BwYyIgeGVuDQo+IGNtZGxp
bmUNCj4NCj4gT24gMTkuMDUuMjAyNSAxMDozNiwgUGVubnksIFpoZW5nIHdyb3RlOg0KPiA+IFtQ
dWJsaWNdDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTog
SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiA+PiBTZW50OiBUdWVzZGF5LCBBcHJp
bCAyOSwgMjAyNSA4OjUyIFBNDQo+ID4+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFt
ZC5jb20+DQo+ID4+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBD
b29wZXINCj4gPj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRA0K
PiA+PiA8YW50aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD47IE9yemVsLCBNaWNoYWwgPE1pY2hhbC5P
cnplbEBhbWQuY29tPjsNCj4gPj4gSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2Vy
IFBhdSBNb25uw6kNCj4gPj4gPHJvZ2VyLnBhdUBjaXRyaXguY29tPjsgU3RlZmFubyBTdGFiZWxs
aW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPjsNCj4gPj4geGVuLSBkZXZlbEBsaXN0cy54ZW5w
cm9qZWN0Lm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW1BBVENIIHY0IDA1LzE1XSB4ZW4veDg2OiBp
bnRyb2R1Y2UgImNwdWZyZXE9YW1kLWNwcGMiDQo+ID4+IHhlbiBjbWRsaW5lDQo+ID4+DQo+ID4+
IE9uIDE0LjA0LjIwMjUgMDk6NDAsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiA+Pj4gLS0tIGEveGVu
L2luY2x1ZGUvYWNwaS9jcHVmcmVxL3Byb2Nlc3Nvcl9wZXJmLmgNCj4gPj4+ICsrKyBiL3hlbi9p
bmNsdWRlL2FjcGkvY3B1ZnJlcS9wcm9jZXNzb3JfcGVyZi5oDQo+ID4+PiBAQCAtNSw2ICs1LDkg
QEANCj4gPj4+ICAjaW5jbHVkZSA8cHVibGljL3N5c2N0bC5oPg0KPiA+Pj4gICNpbmNsdWRlIDx4
ZW4vYWNwaS5oPg0KPiA+Pj4NCj4gPj4+ICsvKiBhYmlsaXR5IGJpdHMgKi8NCj4gPj4+ICsjZGVm
aW5lIFhFTl9QUk9DRVNTT1JfUE1fQ1BQQyAgIDgNCj4gPj4NCj4gPj4gVGhpcyBuZWVkcyBjb3Jy
ZWxhdGluZyAoYXQgbGVhc3QgdmlhIGNvbW1lbnRhcnksIGJldHRlciBieSBidWlsZC10aW1lDQo+
ID4+IGNoZWNraW5nKSB3aXRoIHRoZSBvdGhlciBYRU5fUFJPQ0VTU09SX1BNXyogdmFsdWVzLiBP
dGhlcndpc2UNCj4gc29tZW9uZQ0KPiA+PiBhZGRpbmcgYSBuZXcgI2RlZmluZSBpbiB0aGUgcHVi
bGljIGhlYWRlciBtYXkgbm90IChlYXNpbHkpIG5vdGljZSBhDQo+ID4+IHBvc3NpYmxlIGNvbmZs
aWN0LiBXaXRoIHRoYXQgaW4gbWluZCBJIGFsc28gcXVlc3Rpb24gd2hldGhlciA4IGlzDQo+ID4+
IGFjdHVhbGx5IGEgZ29vZCBjaG9pY2U6IFRoYXQncyB0aGUgb2J2aW91cyBuZXh0IHZhbHVlIHRv
IHVzZSBpbiB0aGUNCj4gPj4gcHVibGljIGludGVyZmFjZS4gU0lGX1BNX01BU0sgaXMgOCBiaXRz
IHdpZGUsIHNvIGEgc2Vuc2libGUgdmFsdWUgdG8gdXNlIGhlcmUNCj4gd291bGQgYnkgZS5nLiAw
eDEwMC4NCj4gPj4NCj4gPg0KPiA+IEkndmUgYWRkZWQgYSBwdWJsaWMgZmxhZyBhbmNob3IgIlhF
Tl9QUk9DRVNTT1JfUE1fUFVCTElDX0VORCIgaW4NCj4gcHVibGljIGhlYWRlcjoNCj4gPiAgICAg
ICAgICAjZGVmaW5lIFhFTl9QUk9DRVNTT1JfUE1fUFVCTElDX0VORA0KPiBYRU5fUFJPQ0VTU09S
X1BNX1RYDQo+ID4gYW5kIHdpbGwgZG8gdGhlIGZvbGxvd2luZyBidWlsZC10aW1lIGNoZWNraW5n
Og0KPiA+ICAgICAgICAgQlVJTERfQlVHX09OKFhFTl9QUk9DRVNTT1JfUE1fQ1BQQyA8PQ0KPiA+
IFhFTl9QUk9DRVNTT1JfUE1fUFVCTElDX0VORCk7DQo+DQo+IEkgZG9uJ3QgcmVhbGx5IHNlZSB3
aHkgYW55dGhpbmcgd291bGQgbmVlZCB0byBiZSBhZGRlZCB0byB0aGUgcHVibGljIGhlYWRlciAo
YW5kIHdlDQo+IHJlYWxseSBzaG91bGQgc3RyaXZlIHRvIGF2b2lkIHVubmVjZXNzYXJ5IGFkZGl0
aW9ucykuDQoNCklmIEkgcHV0IHN1Y2ggZGVmaW5pdGlvbg0KIiNkZWZpbmUgWEVOX1BST0NFU1NP
Ul9QTV9QVUJMSUNfRU5EIFhFTl9QUk9DRVNTT1JfUE1fVFgiDQppbiBpbnRlcm5hbCBoZWFkZXIs
IEknbSBhZnJhaWQgaXQgd29uJ3QgYmUgdXBkYXRlZCBpZiBuZXcgb25lcyBhZGRlZCBpbiB0aGUg
cHVibGljIGluIHRoZSBmdXR1cmUuDQpPciBhbnkgb3RoZXIgc3VnZ2VzdGlvbnMgdG8gcHJvdmlk
ZSBidWlsZC10aW1lIGNoZWNraW5nPw0KDQo+DQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Tue May 20 08:42:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 08:42:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990529.1374464 (Exim 4.92)
	(envelope-from )
	id 1uHIYS-0000km-Lx; Tue, 20 May 2025 08:42:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990529.1374464; Tue, 20 May 2025 08: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 1uHIYS-0000kf-J9; Tue, 20 May 2025 08:42:32 +0000
Received: by outflank-mailman (input) for mailman id 990529;
 Tue, 20 May 2025 08:42:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHIYR-0000kZ-Ut
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 08:42:31 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5cf25b03-3556-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 10:42:29 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-601afe51106so3424965a12.1
 for ; Tue, 20 May 2025 01:42:29 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d06b105sm691640666b.41.2025.05.20.01.42.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 01:42: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" 
X-Inumbo-ID: 5cf25b03-3556-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747730549; x=1748335349; darn=lists.xenproject.org;
        h=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;
        bh=1z3Z+oWfL+292B6Xbb1J5dGH/c0AKWQSVrX4RanTt8Y=;
        b=HM9tduUezpM8pqgxlZSBoF4TU/96+fpIzXXKwiblFkZiaaIOjmRQLwGOoZkcCNMm5Y
         h7BNLlH3LXioG6P9cPvYe7lVi+RgXUKx+Xf0WomCpsWVN4vEys0mNBuC7+K7SrpiA2QA
         wQPkGg/OtsJIOv/C3ehonLBmRCOvFsMuRo1B+GReCbhMXVsATfErLmQ74WQNvISL/4k2
         3zNzzTybfqYucbMKBL2ITdhWFn7KtVikO75N3ZXJx7h07ii8xzjAluepndnFw5L9KWOc
         0qLGto7ZbKjyLBycjiWuCS+F/ZBG880zVwaP44TGsxMbCvQTne5svUUY2Wk2cHO3snPl
         +weg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747730549; x=1748335349;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=1z3Z+oWfL+292B6Xbb1J5dGH/c0AKWQSVrX4RanTt8Y=;
        b=VOsjSRV/OHh4EiTFGDcxuASHz8H5MhIKF0CmAXpiuK/6M1Cix34rt9/7WDDUst4O3S
         57wEknvepiDF1PuLZjdZ6Ctjnajxt1WX8UN61gAAq2vbdxgxvfi4SJtNsSqpxsY1zerQ
         uQ6IisZbzOy2M4QhVvTRV7NGPOaHH8/ejt1IDybUbrpyNWBIWrkTHVC5fzAD3KxoSCoY
         /+/ogpdwrpYuXYtmKyvmnckg8mPa7ahdLNZEaurLYl4uf5ctZ2XGRNSRpHIKKgqLOiaM
         9p8cChL83W0IdWvn/72OD56nceSwoLV2CeO6Qpe3bQRvqnQ0cYV0r9rWGYY6lwVpcQA5
         +Wfg==
X-Forwarded-Encrypted: i=1; AJvYcCVD1otbZAoxvVGycrlH367KSqifDOXP6qF90LdFkCBGZUCOyvtyyfG2KbN820sJH2YiyzEMvoSVbt0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzZcvZp0aqMxKYjbTcNXIqOs4kjEFF+aaGL4fg+4YiJfnEWO8m+
	AIf+BHRAz3Eq81nf171TA7SRdIXDsIwyUGSmA8l1yMTc36VA+dIujtGM
X-Gm-Gg: ASbGncsIIYHMdLXajKmvqtwOLJ/pgLahtMQBlV/X9NUS+8AmhyLdPptTC6EdfQpS1Mc
	WM2IvRqLvtEZgmVLSLY400E2VdF93/D3e8CjQGTRzsqtPv+T8qwn6abhNZhJyZIBznlH91eGt4N
	j47vCEgCjLfgi8kv2hoIFnFCxTmXOhCTZxY0RpuiIaX6BJnYKN9hrecBjRdaARUYLdkt/ht3pur
	PxlXZdmxM/hI8MW++XFOAgiB8kiZ4Ggaf8LZxXUbnxdK5OCQuSF/D45ah5winvpiP1MF9/Cy00S
	KO0pYybn4a2dUbODVCKc9DyzDtLkkszQegMcr0WDdr3PhIKJDn1bVcGknU8O2jh72spPyKB4IUK
	60hD3KdXtOkykTIwngXXWOeaN
X-Google-Smtp-Source: AGHT+IHuI6tKG5odimhDrtFpNi38l+C3Vi8h3DwT2sEJhT+pcKWMMTG9Nf0RTVowkIa1b2U9dnOmHQ==
X-Received: by 2002:a17:907:7b9d:b0:ad5:2378:dd77 with SMTP id a640c23a62f3a-ad52d5badd5mr1122248066b.37.1747730548303;
        Tue, 20 May 2025 01:42:28 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------FjoPGa9d0JBMwoyNl0ftk1Yw"
Message-ID: 
Date: Tue, 20 May 2025 10:42:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 12/16] xen/riscv: introduce intc_init() and helpers
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <13ce98ce580b6d1a38dcdcd711a6bcf92f4eb0cd.1746530883.git.oleksii.kurochko@gmail.com>
 <6883f364-fc29-4c43-897d-c24207b64b26@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <6883f364-fc29-4c43-897d-c24207b64b26@suse.com>

This is a multi-part message in MIME format.
--------------FjoPGa9d0JBMwoyNl0ftk1Yw
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/15/25 11:29 AM, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> Introduce intc_init() to initialize the interrupt controller using the
>> registered hardware ops.
>> Also add intc_route_irq_to_xen() to route IRQs to Xen, with support for
>> setting IRQ type and priority via new internal helpers intc_set_irq_type()
>> and intc_set_irq_priority().
>>
>> Call intc_init() to do basic initialization steps for APLIC and IMSIC.
>>
>> Co-developed-by: Romain Caritey
>> Signed-off-by: Oleksii Kurochko
>> ---
>> Changes in V2:
>>   - This patch was part of "xen/riscv: Introduce intc_hw_operations abstraction"
>>     and splitted to have ability to merge patch "xen/riscv: initialize interrupt
>>     controller" to the current patch (where intc_init() call is actually
>>     introduced).
>>   - Add checks of that callbacks aren't set to NULL in intc_set_irq_priority()
>>     and intc_set_irq_type().
>>   - add num_irqs member to struct intc_info as it is used now in
>>     intc_route_irq_to_xen().
>>   - Add ASSERT(spin_is_locked(&desc->lock)) to intc_set_irq_priority() in
>>     the case this function will be called outside intc_route_irq_to_xen().
>> ---
>>   xen/arch/riscv/include/asm/intc.h |  4 +++
>>   xen/arch/riscv/intc.c             | 45 +++++++++++++++++++++++++++++++
>>   xen/arch/riscv/setup.c            |  2 ++
>>   3 files changed, 51 insertions(+)
>>
>> diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
>> index 2d55d74a2e..45a41147a6 100644
>> --- a/xen/arch/riscv/include/asm/intc.h
>> +++ b/xen/arch/riscv/include/asm/intc.h
>> @@ -44,4 +44,8 @@ void intc_preinit(void);
>>   
>>   void register_intc_ops(struct intc_hw_operations *ops);
>>   
>> +void intc_init(void);
>> +
>> +void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
>> +
>>   #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
>> diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
>> index 122e7b32b5..15f358601d 100644
>> --- a/xen/arch/riscv/intc.c
>> +++ b/xen/arch/riscv/intc.c
>> @@ -1,9 +1,12 @@
>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>   
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>> +#include 
>>   
>>   #include 
>>   
>> @@ -21,3 +24,45 @@ void __init intc_preinit(void)
>>       else
>>           panic("ACPI interrupt controller preinit() isn't implemented\n");
>>   }
>> +
>> +void __init intc_init(void)
>> +{
>> +    ASSERT(intc_hw_ops);
> What's the goal of this check (also elsewhere below)? You'll crash anyway ...

Agree, that it could be dropped.

The goal was that it will a little bit easier to find a place where NULL
pointer de-reference  will/could happen.

Then it make sense to drop ASSERT(intc_hw_ops) in intc_set_irq_type() and
intc_set_irq_priority() as intc_init() will be called first and so if it
won't crash, then intc_hw_ops is registered.

>
>> +    if ( intc_hw_ops->init() )
> ... here if the point is still NULL, just like you will if the function
> pointer is unpopulated (and hence NULL).

Here, I think it would be better to rewrite to:
   void __init intc_init(void)
   {
       if ( !intc_hw_ops->init )
           return;

       if ( intc_hw_ops->init() )
           panic("Failed to initialize the interrupt controller drivers\n");
   }
For the case, if an interrupt controller doesn't want to do some initialization.
(but I am not sure if it makes sense, likely an interrupt controller will want
to do some initialization. Then it makes do drop the first if (...)).

>
> Preferably with all of these (but not the other assertions) dropped
> Acked-by: Jan Beulich

Thanks.

~ Oleksii



--------------FjoPGa9d0JBMwoyNl0ftk1Yw
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 11:29 AM, Jan Beulich wrote:
    
    
    
    
    
      
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    Introduce intc_init() to initialize the interrupt controller using the
registered hardware ops.
Also add intc_route_irq_to_xen() to route IRQs to Xen, with support for
setting IRQ type and priority via new internal helpers intc_set_irq_type()
and intc_set_irq_priority().

Call intc_init() to do basic initialization steps for APLIC and IMSIC.

Co-developed-by: Romain Caritey <Romain.Caritey@microchip.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in V2:
 - This patch was part of "xen/riscv: Introduce intc_hw_operations abstraction"
   and splitted to have ability to merge patch "xen/riscv: initialize interrupt
   controller" to the current patch (where intc_init() call is actually
   introduced).
 - Add checks of that callbacks aren't set to NULL in intc_set_irq_priority()
   and intc_set_irq_type().
 - add num_irqs member to struct intc_info as it is used now in
   intc_route_irq_to_xen().
 - Add ASSERT(spin_is_locked(&desc->lock)) to intc_set_irq_priority() in
   the case this function will be called outside intc_route_irq_to_xen().
---
 xen/arch/riscv/include/asm/intc.h |  4 +++
 xen/arch/riscv/intc.c             | 45 +++++++++++++++++++++++++++++++
 xen/arch/riscv/setup.c            |  2 ++
 3 files changed, 51 insertions(+)

diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 2d55d74a2e..45a41147a6 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -44,4 +44,8 @@ void intc_preinit(void);
 
 void register_intc_ops(struct intc_hw_operations *ops);
 
+void intc_init(void);
+
+void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 122e7b32b5..15f358601d 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -1,9 +1,12 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
 #include <xen/acpi.h>
+#include <xen/bug.h>
 #include <xen/device_tree.h>
 #include <xen/init.h>
+#include <xen/irq.h>
 #include <xen/lib.h>
+#include <xen/spinlock.h>
 
 #include <asm/intc.h>
 
@@ -21,3 +24,45 @@ void __init intc_preinit(void)
     else
         panic("ACPI interrupt controller preinit() isn't implemented\n");
 }
+
+void __init intc_init(void)
+{
+    ASSERT(intc_hw_ops);

    
      
    
      
    What's the goal of this check (also elsewhere below)? You'll crash anyway ...
    
    
    
    
    Agree, that it could be dropped.

The goal was that it will a little bit easier to find a place where NULL
pointer de-reference  will/could happen.

Then it make sense to drop ASSERT(intc_hw_ops) in intc_set_irq_type() and
intc_set_irq_priority() as intc_init() will be called first and so if it
won't crash, then intc_hw_ops is registered.
    
    
    
      
    

    
      
    
        
    +    if ( intc_hw_ops->init() )

    
      
    
      
    ... here if the point is still NULL, just like you will if the function
pointer is unpopulated (and hence NULL).
    
    
    
    
    Here, I think it would be better to rewrite to:
  void __init intc_init(void)
  {
      if ( !intc_hw_ops->init )
          return;

      if ( intc_hw_ops->init() )
          panic("Failed to initialize the interrupt controller drivers\n");
  }
For the case, if an interrupt controller doesn't want to do some initialization.
(but I am not sure if it makes sense, likely an interrupt controller will want
to do some initialization. Then it makes do drop the first if (...)).


    
    
    
      
    
Preferably with all of these (but not the other assertions) dropped
Acked-by: Jan Beulich <jbeulich@suse.com>
    
    
    
    
    Thanks.

~ Oleksii

    
    
    


    
  


--------------FjoPGa9d0JBMwoyNl0ftk1Yw--


From xen-devel-bounces@lists.xenproject.org Tue May 20 09:09:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 09:09:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990539.1374474 (Exim 4.92)
	(envelope-from )
	id 1uHIyX-0003m8-EA; Tue, 20 May 2025 09:09:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990539.1374474; Tue, 20 May 2025 09:09: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 1uHIyX-0003m1-BV; Tue, 20 May 2025 09:09:29 +0000
Received: by outflank-mailman (input) for mailman id 990539;
 Tue, 20 May 2025 09:09:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHIyW-0003lv-2z
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 09:09:28 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f38581b-355a-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 11:09:26 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-60119cd50b6so6339637a12.0
 for ; Tue, 20 May 2025 02:09:23 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d06b105sm694472366b.41.2025.05.20.02.09.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 02:09: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" 
X-Inumbo-ID: 1f38581b-355a-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747732163; x=1748336963; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=tVQq2gs+OkPmieyX4cN/JoZaN8OcmE8Kd2im74ZeQoM=;
        b=qKjvrFDzZK5wZpAvJqLwiXWzZbK/gbmGysjTxsWG5zuVt1X3xdHSiqli+xhIdv/95A
         iDfuqjSAOz62eRppOCWTE6ucS9Eobj7AXxXkSo+ybDeLU3qGEmNpB3yYLGTLsZQtW8zL
         1PPC0DeTeAIVNiwiavtM//YaJOzdRdviVN4hM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747732163; x=1748336963;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tVQq2gs+OkPmieyX4cN/JoZaN8OcmE8Kd2im74ZeQoM=;
        b=aDivch5oAhph8cqj7Mq2Y666VQGRjrXxXljSs0qd6ZOI4LxTruTyuyrX+tCUTo11qN
         ohKMWX6R6OSQGjSEocwE3Q06IiMMUSmogQ1gXztS+ogKEq3jqp35n+dvqT3kDAailWTT
         lOnTcDZ0IrN0EF0Kj+tKXEuQ9RYgRjyM2P6RFc/aiLsyVFxasHPlqbiwE1Ti59tyHqV4
         9DY5N1HXb8ZcEz7J0RxJjGIAA8E13t3wHQ0Y3i7h91Bxt/BMxo1qucKzCH89kzd5A/iy
         ta8B/VhMW7tUHin7/Yui3aH5mYgTu1WSruHJwsEAnij+C7V9AkY6lNOz5xxBlOrFri3h
         MGfA==
X-Forwarded-Encrypted: i=1; AJvYcCVB2i5gAPYz4NZZnC7MXwz8m1kPyuuU1uiUaqCajyyuvHlVUYJILQH9qtlVwy80ipjcvl0RzIi7nus=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwOU5sG79z5yHL59joOG+Pi2Xws5/ET2jBANA8mBuA4ZBqwK3m8
	oq3YNusz6dwGsn26wjLDrdcXHilkuA5zDNXydUP1OUqpFQhu2gV0gqSwMh2Phev2d+M=
X-Gm-Gg: ASbGncvh+tQ6OMxGKk4hr/Ag2NoLG7V/KbDjhebAP0iK5LjZpHzNXDRzBd1ZrtCaVnJ
	c2xKyMCTelaBNBoYR6utEE9oT0qBt3pqTTejZ1hPXP8KFYJc/uBuSYAChuoUaZQWVW7k+MizKss
	zgKA5k+Zjt7Tp1wq768BjCXbKY1mrtgFOBLEW8M9gdLDmnN7Rff6jDUdw/9FAKzvLinDKx/xhSw
	fdUimsMs9klLA/QUTwK2sXAfpPngqJ8ar8dLbb9hWu1VBvBVJaUZRCjQIy1DUvinlvB7aYWVjCf
	lWEMvPCct4etLnlYIQLama9GK9R1oXbE+8NKvdI5/MLu2OKgsPw3W5WpEMYyZVGrIaqK1qF6v26
	FH4c9zbqyd2dD9BG5RMM=
X-Google-Smtp-Source: AGHT+IGPNqnv+PLAcCho7TBT2gUtz6XxiATaf8F6wnFefG2ZCku5GvRxxtM3ChRWHWTKBbHjQXSuMA==
X-Received: by 2002:a17:907:7f22:b0:ad5:72d4:85ee with SMTP id a640c23a62f3a-ad572d507b2mr737808366b.53.1747732162966;
        Tue, 20 May 2025 02:09:22 -0700 (PDT)
Date: Tue, 20 May 2025 11:09:21 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Jiqian Chen , Huang Rui ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Message-ID: 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-10-Jiqian.Chen@amd.com>
 <8d89f644-4ded-4490-ad23-518563d230d2@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <8d89f644-4ded-4490-ad23-518563d230d2@suse.com>

On Tue, May 20, 2025 at 08:40:28AM +0200, Jan Beulich wrote:
> On 09.05.2025 11:05, Jiqian Chen wrote:
> > When init_msi() fails, the previous new changes will hide MSI
> > capability, it can't rely on vpci_deassign_device() to remove
> > all MSI related resources anymore, those resources must be
> > removed in cleanup function of MSI.
> 
> That's because vpci_deassign_device() simply isn't called anymore?
> Could do with wording along these lines then. But (also applicable
> to the previous patch) - doesn't this need to come earlier? And is
> it sufficient to simply remove the register intercepts? Don't you
> need to put in place ones dropping all writes and making all reads
> return either 0 or ~0 (covering in particular Dom0, while for DomU-s
> this may already be the case by default behavior)?

For domUs this is already the default behavior.

For dom0 I think it should be enough to hide the capability from the
linked list, but not hide all the capability related
registers.  IMO a well behaved dom0 won't try to access capabilities
disconnected from the linked list, and in general we allow dom0 access
to as much as possible.

For dom0 Xen could drop writes to the MSI(-X) enable bit, thus forcing
MSI(-X) to stay disabled.  I however don't see this as a mandatory
step for the work here.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 20 09:13:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 09:13:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990549.1374484 (Exim 4.92)
	(envelope-from )
	id 1uHJ2V-0005P5-1J; Tue, 20 May 2025 09:13:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990549.1374484; Tue, 20 May 2025 09:13: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 1uHJ2U-0005Oy-V5; Tue, 20 May 2025 09:13:34 +0000
Received: by outflank-mailman (input) for mailman id 990549;
 Tue, 20 May 2025 09:13:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHJ2T-0005Os-LH
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 09:13:33 +0000
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com
 [2607:f8b0:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b29fe18a-355a-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 11:13:31 +0200 (CEST)
Received: by mail-pg1-x52b.google.com with SMTP id
 41be03b00d2f7-b26f7d2c1f1so3568400a12.0
 for ; Tue, 20 May 2025 02:13:31 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 98e67ed59e1d1-30f364fff31sm1199694a91.31.2025.05.20.02.13.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 02:13:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b29fe18a-355a-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747732410; x=1748337210; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=a9PHVzgPS7ZzD2SjFwqVUoXkCFf5jtJJqOuSx3+CF+c=;
        b=bXEG4YsblZ2Vy8Y1aglCLgHAwDCzbZ9NFvzbGhQsLblX6WxPPEluFKdcGyqr+XC7pT
         cAavBooQRrt7jPvRiCBlQ8WvI25YW5+ob4HuSWFQg24JOrkxZJu7qk55MKQ8eCLXRnCI
         Va/HLu6ap5dZTIBzyIXbxm/Uu5REDVKEoaEFE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747732410; x=1748337210;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=a9PHVzgPS7ZzD2SjFwqVUoXkCFf5jtJJqOuSx3+CF+c=;
        b=AK8kwJnTzN2Ukfc1hkYbQUWdn/2vwmExj8c7gmR/JkIoUuVgD4IuuNfBmNeWVevG9r
         uhENVc3VA+5aUeKgYdiDGP8+MgIU2IpUxQ9zknDD+JJLorIcDn11GwhygYbRJC7wIdNd
         eVtwzSW2mUQzsHjlR9pgCmjyef6mH5EeyzFAnawWSV/UJ8HrZZcFa2BRF+UU+Hb4uMP3
         YuOy9cP08nq712H1YZwsENDCfiGg49bbsJuzPST8OKMsP5AieR/yYluS2XgV74Lbrtz2
         RFLp9mGuEUXnzZ/P3i/tzMkid1B8qXc7yDbjozn4S+yfJFdMyf8teGbDgzPO/qMlbRQQ
         FRqA==
X-Gm-Message-State: AOJu0YxbBt5MB62P4UZkFtCgC1RPqJc5kcK5P/R/rH4aE/urQPC87/hm
	28vcIIjTQxKPoyopmAiGxv6C8d8ooLZeLV3lwqZe0b2q5fRvhchUUrW0woOiIN1KNB7mltnR270
	mgTtZ
X-Gm-Gg: ASbGnctvXoPHDa7LZFK1SRpgogeudxZkriXdX8QtXtAzOw4JeYOMDwrYiqucuG4e7fp
	JRFZghIguiID8Gnu40ZisQ7vdgbg1kolyPha3CtLaa1Utvu/mHfsU1ySn3ijvTIqWUKchQQ8bN6
	HgWxcYTKO7uBsLtUT3SUu3xbF0fYO8MB2eivGA1mxIalUUXuJfbIUVEi0w2w+KT7btDWzdS9Sf+
	mctpEnDLBZmvvtLkERJDP28NdApsUasDqG8LWcTBwOCqF/lE7/ayODboZaczF0Q2cuJPyGPyNMK
	ThieSftJyZ0XzuL/fNft4bq2FVoIUbaPL5YuSTkCdohvtrxx8GM4fWCZgZynKuALNHOK6t226Y7
	dC2MMd2BJCChmBsE4QTs=
X-Google-Smtp-Source: AGHT+IFhy5+G0/sqPVxplEwmBPR9sU8sssx2evzygv/28QMSwaMAkoSJfrugGNOt1BOM4EVHcsy0hA==
X-Received: by 2002:a17:90a:e70f:b0:30a:2173:9f0b with SMTP id 98e67ed59e1d1-30e8322596bmr23102343a91.28.1747732410169;
        Tue, 20 May 2025 02:13:30 -0700 (PDT)
Date: Tue, 20 May 2025 11:13:24 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Ngamia Djabiri Julie 
Cc: "xen-devel@lists.xenproject.org" ,
	"jbeulich@suse.com" 
Subject: Re: Request for patch to fix boot loop issue in Xen 4.17.6
Message-ID: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Sat, May 03, 2025 at 02:02:32PM +0000, Ngamia Djabiri Julie wrote:
> Dear Xen developers,
> 
> I would like to ask if the following fix can also be included in Xen 4.17.6 (and eventually in the Xen versions after 4.17.6 that don't have the fix) :

Hello,

4.17.6 is planned for the end of the year (so more than 6 months from
now).  It would be faster if you request the backport to be added to
the Alpine Xen 4.17 package.

Andrew provided a link for the backport to 4.17 that we use in
XenServer, it will most likely apply cleanly to the Alpine package.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 20 09:14:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 09:14:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990555.1374494 (Exim 4.92)
	(envelope-from )
	id 1uHJ3R-0005tx-9Q; Tue, 20 May 2025 09:14:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990555.1374494; Tue, 20 May 2025 09: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 1uHJ3R-0005tq-6p; Tue, 20 May 2025 09:14:33 +0000
Received: by outflank-mailman (input) for mailman id 990555;
 Tue, 20 May 2025 09:14:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHJ3P-0005tk-9B
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 09:14:31 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d54fd376-355a-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 11:14:29 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-601470b6e93so7501423a12.3
 for ; Tue, 20 May 2025 02:14:29 -0700 (PDT)
Received: from [10.10.4.69] (server.hotelpassage.eu. [88.146.207.194])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005a6e637dsm7015811a12.43.2025.05.20.02.14.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 02:14: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" 
X-Inumbo-ID: d54fd376-355a-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747732468; x=1748337268; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=vAh8Wykk7n22DlOu/qE8677hSqyYu+D/iCZyVk1ts/Y=;
        b=G+CbIOmqylIybzUFAHywOpn+fuJb99j70u5KjbbESAf+yl0v34MCp4sB2hHS4JmyY3
         iOIDqo5YVbNavpJyW0R8qtxrOnK10cMkO3xfgMXUL/nMt82I4+Dzi94V0C1dDxyPZREL
         YvNbUCP1i7c9jKYHsz8goUqTGI+NZy/4plBZFnjfq8FGpXzIXqELFlkJon1Tyk/+RcA2
         W0ZOVEpKS+O0TqZWX8rlMzpMeTDxa4ddRKSoEABSt7JmjYNM6/aRp6jI4PB4AlABZPrU
         mscj8FUguHORkHgXaK1BPaelgqbKSJgYsCelAl3UWyb0IaDAfnO/Y2PGHoysNEvTUbX/
         OwTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747732469; x=1748337269;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=vAh8Wykk7n22DlOu/qE8677hSqyYu+D/iCZyVk1ts/Y=;
        b=wbKGqVVh0b3tSZFuplkH0RzaV5Lr6TDoRGFmtbcJUk89HYOIDizJgpj/0lTCNf6BHm
         ZfqAodJ072IxKp8V9blSN92j+36bk1nzdc/krd06xMf7yppzTwcKqGgYYqSgyGjW3TJ9
         DNjWulrCY0Vn3QnJBmRVNT/TkXOn5TQXvmxUrLu5lPblq85GPA800cQjEFmfc5oS32pT
         q+ap5V3Zf2Q2uMWsvu+hEKa6zyYX4CfCgQEHBDvuzeNa480zvZ4R2p5rDtguu8Vke6EB
         noG9yDjGlekJRlr/xRh520zqydno08mehgBeoYbiC+Oxzfa0hAjYadiK6/p7H8H7jBRf
         7Iwg==
X-Forwarded-Encrypted: i=1; AJvYcCWU65UxWhQTsoOg2N6jfbCPkyOwljA0PZhQ8DlrOjX7g6aRSyb5GGmp8JbTtd/rlY0XU9CLW4avxv4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw78VB+8NwghUWDe/B786eifUino6c85mXOD5Oy4sQ970Fefy6g
	AaRz3sL+QwHfZjoaNKwSOP/CiyMPRyNFCDfpW00Csscv31yQIrUAJd/JMvcevzlHlQ==
X-Gm-Gg: ASbGncsvVcElTq9oPEGnrgjFNplO3dPQtNSqQPdcnPQFYwo6IBEYFpf6FZXznElbb2b
	I19B0e84o8cYecn2u2vXrz7lT8S3+d3RBEeQwryFljLPEnkZt1Bz+f9DXyvF4Mm6eGCb2+hbfEP
	pJ80XWjQzo2gp5q1dEGExp+Ct0ZlNAu5NpuCVeBK5MszfXqZhAn+87F6rCf2c26A5AD2ostHNQm
	jtSwbUIIPOX5Q021ChIDfVC5AYotlRfZwdSDRKMrhJIbGjvvZNq7IeCeR2SRga4HIbO2EPu2up5
	3Ihx43qCTFD0E0vqaGQWMIRYsL5tLdfSxWvlY5ppRX2EZFWj0NzxO6GHlCxw2dGkeeoBDLtJRTq
	wbonp
X-Google-Smtp-Source: AGHT+IG/uMbo7VPCfwmbZGaAfym6NOwly06m5p4hLSWdzE0PqkRFwwsJk3ipjKp5dH50wnOnzLEDKg==
X-Received: by 2002:a05:6402:2742:b0:5fc:97e6:ec6a with SMTP id 4fb4d7f45d1cf-60090068697mr14664802a12.13.1747732468591;
        Tue, 20 May 2025 02:14:28 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 11:14:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Jiqian Chen , Huang Rui ,
 xen-devel@lists.xenproject.org
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-10-Jiqian.Chen@amd.com>
 <8d89f644-4ded-4490-ad23-518563d230d2@suse.com> 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.05.2025 11:09, Roger Pau Monné wrote:
> On Tue, May 20, 2025 at 08:40:28AM +0200, Jan Beulich wrote:
>> On 09.05.2025 11:05, Jiqian Chen wrote:
>>> When init_msi() fails, the previous new changes will hide MSI
>>> capability, it can't rely on vpci_deassign_device() to remove
>>> all MSI related resources anymore, those resources must be
>>> removed in cleanup function of MSI.
>>
>> That's because vpci_deassign_device() simply isn't called anymore?
>> Could do with wording along these lines then. But (also applicable
>> to the previous patch) - doesn't this need to come earlier? And is
>> it sufficient to simply remove the register intercepts? Don't you
>> need to put in place ones dropping all writes and making all reads
>> return either 0 or ~0 (covering in particular Dom0, while for DomU-s
>> this may already be the case by default behavior)?
> 
> For domUs this is already the default behavior.
> 
> For dom0 I think it should be enough to hide the capability from the
> linked list, but not hide all the capability related
> registers.  IMO a well behaved dom0 won't try to access capabilities
> disconnected from the linked list,

Just that I've seen drivers knowing where their device has certain
capabilities, thus not bothering to look up the respective
capability.

> and in general we allow dom0 access
> to as much as possible.
> 
> For dom0 Xen could drop writes to the MSI(-X) enable bit, thus forcing
> MSI(-X) to stay disabled.  I however don't see this as a mandatory
> step for the work here.

You're the maintainer, so you have the final say.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 09:15:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 09:15:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990562.1374505 (Exim 4.92)
	(envelope-from )
	id 1uHJ4k-0006Pj-Jk; Tue, 20 May 2025 09:15:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990562.1374505; Tue, 20 May 2025 09:15: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 1uHJ4k-0006Pc-Gq; Tue, 20 May 2025 09:15:54 +0000
Received: by outflank-mailman (input) for mailman id 990562;
 Tue, 20 May 2025 09:15:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHJ4j-0006PU-TB
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 09:15:53 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 073b52a4-355b-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 11:15:52 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-602039559d8so1756295a12.1
 for ; Tue, 20 May 2025 02:15:52 -0700 (PDT)
Received: from [10.10.4.69] (server.hotelpassage.eu. [88.146.207.194])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac33d7asm6855871a12.52.2025.05.20.02.15.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 02:15: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" 
X-Inumbo-ID: 073b52a4-355b-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747732552; x=1748337352; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=mjHeF0aeesIbq3TXLdkw9Qco1LOsm+HoVeaXU8yUpxU=;
        b=LQFNqdEKYUrSlDePK2i+b1RqkQ6E9PfUl/StWwfNyr/A6VdYpQoGZ89A3jjmdoFHL4
         bGcK/qplDwcSpIuB3HAzXImp8xd/tjWq7VhXt6LzhZjttv/IqpcEszrUh8NlYosqxEBo
         yqAuf7AEIcLs0ThSS/qPovcp+a09eYx7AFmUhu2zX0WSDlrGYtnSE1wAH3u1mtRNYZ2y
         GAVjBHmvchhVYb1iwWl9wH60pQG683696GQdtEIX1LTMcPZJ48WIBcQBt0RnQpFZK5VQ
         nI3OW0Ky58PTVkzC3WssqCe5fdcSo2bBx/MTgz4acVuv7LcHODUWvb7gqJufAfZcJAIC
         z3Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747732552; x=1748337352;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=mjHeF0aeesIbq3TXLdkw9Qco1LOsm+HoVeaXU8yUpxU=;
        b=gU4zr8CO9rB5e3Z5sVWRCemOEga35Q+m0H9DVMAQ93EPwA/nJZ93QU7Mhezm7ZeJZi
         vWD3QlDkxy9H+8XRNaEB31V9uiJi2Kq1TBodCHL8F87XZH/xy6/FwelHnMK6rZdUWnXu
         JPvsSkoPaPjbyjZ48fRRjs6E3u8PtHnYC3gfPF878TVaEMs4/NoS1uE8UOAW6tL+kdCs
         UeQL1oqFBQT12+uvaQ5suBqdi31T6jAF0mNuBXmthC0TTSui9P5bUQU3cDfbwAhv3E4H
         TwjfZCka3z0DVpm6lbRj2rOBFkTDjqPaHAOHQi2RsPHSfQTvkygY+Pg5yn33XOeBzxNH
         E4sA==
X-Forwarded-Encrypted: i=1; AJvYcCVLdXMaaEqPAhqQngb7sWUoH3FMJdVR5G/YzVFoklV6sqyWxOM+hXYolatFMaSTrGGvBzJA0gZi7CA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxM2A18fSZGLlyVtJOb2IH1vcv8i/tt7M2444egBpjCDOdB/aow
	IwBKMDlrKHExv2d0Hi6FSXR4gISOKKcTxaaUKVnTcnS+vozYLVEsZjNR6wBowSY2OQ==
X-Gm-Gg: ASbGnctyZqOwpynUTsE5CUJNgFLgfm4LvfjynTuJbUhaMNE477Eo1DKjAghRwi7KGTT
	CguojT10HcAg2ECvUck/LMVI67wKu5jEgqj5TOhCcXUIe2sB3HHrGYcZgGs0hnyloo0N5+XB6mC
	92NA2OzaET+4z9uZL8UTSyZtnf1qMb/rm1PJ8DXJl4+UaLPFgYWwq16eWzVBidoIEPwf3as8ume
	f41EyuPLMQ6f8kEVhUu6XuXyhwqlou0QgicOgkpHg1xoRd3Nx7i2DQ3ty+rDbMj/hHpPgvcymtC
	JbKVyNbSWHGlbriT+nbk58zkUzFlctmPaTyqU+a3qirhAM7hYXtOxVpWXx8PvGIXesmhP//Q01c
	PjYuU1BSFB10zXwk=
X-Google-Smtp-Source: AGHT+IHbFE+DhWnGoq6b48voS5NZMg1MP+EOVA/4296k7JHOBjxfPewQ1ACcdEavuu7+7750RVCZhQ==
X-Received: by 2002:a05:6402:4304:b0:602:1d01:2869 with SMTP id 4fb4d7f45d1cf-6021d012c1cmr383709a12.28.1747732552243;
        Tue, 20 May 2025 02:15:52 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 11:15:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 Anthony PERARD ,
 "Orzel, Michal" , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-6-Penny.Zheng@amd.com>
 <57a3b2c0-d57d-46e3-b248-0e243f715423@suse.com>
 
 <0f673a09-840c-4319-bec8-62fd920a6b84@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.05.2025 10:28, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Monday, May 19, 2025 9:19 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Anthony PERARD ;
>> Orzel, Michal ; Julien Grall ; Roger Pau
>> Monné ; Stefano Stabellini ; xen-
>> devel@lists.xenproject.org
>> Subject: Re: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
>> cmdline
>>
>> On 19.05.2025 10:36, Penny, Zheng wrote:
>>> [Public]
>>>
>>>> -----Original Message-----
>>>> From: Jan Beulich 
>>>> Sent: Tuesday, April 29, 2025 8:52 PM
>>>> To: Penny, Zheng 
>>>> Cc: Huang, Ray ; Andrew Cooper
>>>> ; Anthony PERARD
>>>> ; Orzel, Michal ;
>>>> Julien Grall ; Roger Pau Monné
>>>> ; Stefano Stabellini ;
>>>> xen- devel@lists.xenproject.org
>>>> Subject: Re: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc"
>>>> xen cmdline
>>>>
>>>> On 14.04.2025 09:40, Penny Zheng wrote:
>>>>> --- a/xen/include/acpi/cpufreq/processor_perf.h
>>>>> +++ b/xen/include/acpi/cpufreq/processor_perf.h
>>>>> @@ -5,6 +5,9 @@
>>>>>  #include 
>>>>>  #include 
>>>>>
>>>>> +/* ability bits */
>>>>> +#define XEN_PROCESSOR_PM_CPPC   8
>>>>
>>>> This needs correlating (at least via commentary, better by build-time
>>>> checking) with the other XEN_PROCESSOR_PM_* values. Otherwise
>> someone
>>>> adding a new #define in the public header may not (easily) notice a
>>>> possible conflict. With that in mind I also question whether 8 is
>>>> actually a good choice: That's the obvious next value to use in the
>>>> public interface. SIF_PM_MASK is 8 bits wide, so a sensible value to use here
>> would by e.g. 0x100.
>>>>
>>>
>>> I've added a public flag anchor "XEN_PROCESSOR_PM_PUBLIC_END" in
>> public header:
>>>          #define XEN_PROCESSOR_PM_PUBLIC_END
>> XEN_PROCESSOR_PM_TX
>>> and will do the following build-time checking:
>>>         BUILD_BUG_ON(XEN_PROCESSOR_PM_CPPC <=
>>> XEN_PROCESSOR_PM_PUBLIC_END);
>>
>> I don't really see why anything would need to be added to the public header (and we
>> really should strive to avoid unnecessary additions).
> 
> If I put such definition
> "#define XEN_PROCESSOR_PM_PUBLIC_END XEN_PROCESSOR_PM_TX"
> in internal header, I'm afraid it won't be updated if new ones added in the public in the future.
> Or any other suggestions to provide build-time checking?

Imo it's sufficient to check that the new #define doesn't overlap with
SIF_PM_MASK.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 09:18:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 09:18:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990571.1374515 (Exim 4.92)
	(envelope-from )
	id 1uHJ6q-0006yc-Vg; Tue, 20 May 2025 09:18:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990571.1374515; Tue, 20 May 2025 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 1uHJ6q-0006yV-Rn; Tue, 20 May 2025 09:18:04 +0000
Received: by outflank-mailman (input) for mailman id 990571;
 Tue, 20 May 2025 09:18:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHJ6q-0006yK-3i
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 09:18:04 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 545557ff-355b-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 11:18:02 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad56829fabdso331127066b.1
 for ; Tue, 20 May 2025 02:18:02 -0700 (PDT)
Received: from [10.10.4.69] (server.hotelpassage.eu. [88.146.207.194])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad53603a399sm662064266b.40.2025.05.20.02.18.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 02:18: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" 
X-Inumbo-ID: 545557ff-355b-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747732682; x=1748337482; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=vMexUm1jxCPyNAqeBNWuh8jrILHmwhJLyz/8VAM3tp4=;
        b=RqIo02bgZBTm1OdwGFkZPAKvrG6Oh9F2k7WpzIxWI95iLvBAkJzX2rIdZHQi0Sbvon
         /94eny2pdf51SRIEMk+lihoc1gfdxcVuXFZj3iU1UUBjUKZSZVxX6tWRfCKCFxhWokJ9
         GSKOAB0nEs8F4xIMjLzV/9vGKoU7Jm6uDs/dV91mUsUfFuScnbHNMqqOAyIIQ+lQqkxb
         +vCA99gVjaQ4dBGK/8bm/aMdkrV4yrmmqTkvVbaMjXe5A9USHLkeCQQ7uAq1PUUrBZJf
         y+8aZyK+Q6rRmpqVQ+76zVYfB6W5+HZ7CReucLD+TxMdPlxE0rHqFCd/4YPSAY1Eiv6S
         adDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747732682; x=1748337482;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=vMexUm1jxCPyNAqeBNWuh8jrILHmwhJLyz/8VAM3tp4=;
        b=S0Lb6JXfdAFPtuDOghrm7xkwbfLJQc5qH2cK14TCVCiMwYdrqJZ8Uqrp3lyjEiuvjO
         PgRFDZJIod4F7ZMc+JVRrP08mvTMfeBHeGKWspZr0p1Yam2O8+ncZMwS5zFwm1F5PI7m
         m/VZB/mntm1Bmc6wWyQRESGPCeSLrAddfU+HJRWUiQuPj4jkpimvJrltT8+d8ohcM67r
         yjLJFS7RbXTF3sYL5HLrKufle2QBf06Ib2Yfu9rUop+FYbXC8Yyb9o3xI3RNX1z5lHm+
         eSDAI5+ZRflQxipN4BBXXvIZoHGiM1SkDNQJ3cQdMZQJd5EeP3jPUBzWYkRNPjlG1qgZ
         VEzw==
X-Forwarded-Encrypted: i=1; AJvYcCX5nRk+/dH0+Xo1L2ibneJDhtNnPawQc3nDxfaYHtuu7O49gxfeW2WhLHKmY5cX3PeJMeWPWoP0UII=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzyLQiaC1r23nnalYRYgzIlkFgrR5+rmv8WNdxLXHgevHmCMIvB
	RK7aRpZhhDSNVhvlSWNX0cF8+r+TIye5kI6xjytX2AT4A6KMTUpsC8cEu6yzBD+6/g==
X-Gm-Gg: ASbGnctfygaYCpueC/8EPFuQBtQtlkbuA/O+O2J8S4lJoHwXC9xeY16HjHU7YEckL2X
	wBGIK/Ers+q8AZQp2z4kVc88ZpZgQ3mQcxMNqXJXgBOrzn9/3DWKLghps20vbP6YR6D9GXhgHuP
	XV2UucAeOqvbddvQts+P/2lHueklnZpDox4AiUiEN1s8ce7dAuRcIezQWd1aqAV6k5V22M+MVDy
	pv4cPtvPQ/qlgOvHGIZAeHLr8V0nmws6H6xw5X2/BUGbsNtdkigNr4a5RmmICTWMJVwOpL1+hCI
	mNY/fuEgFHzVKFXvM1plyLN5P+NJ7vzC2tyU2Z/3IgJhlEzCuyfLINhIK9dI/fIPD/v8yXbRkFu
	wTu+6EELj0F2hfUg=
X-Google-Smtp-Source: AGHT+IFuCXuA5lcFlHthrr38+rhqTqlZ0B4YrWHJr6Js8KWRIRmIb2gNhDwrwyNEWxFmyKPeLtf+MA==
X-Received: by 2002:a17:907:8e96:b0:ad2:2fe0:6310 with SMTP id a640c23a62f3a-ad52d60848bmr1470782366b.57.1747732681666;
        Tue, 20 May 2025 02:18:01 -0700 (PDT)
Message-ID: <4a5580aa-2a2a-4b67-9bea-1c53fa5639e4@suse.com>
Date: Tue, 20 May 2025 11:18:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 12/15] tools/xenpm: Print CPPC parameters for amd-cppc
 driver
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Anthony PERARD ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-13-Penny.Zheng@amd.com>
 <63b3b016-551c-4201-a3b3-db19b27ea649@suse.com>
 
 <75679a60-7ca0-41da-b542-c5b9d5efdfbe@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.05.2025 10:22, Penny, Zheng wrote:
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Tuesday, May 13, 2025 4:03 PM
>>
>> On 09.05.2025 08:36, Penny, Zheng wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich 
>>>> Sent: Wednesday, April 30, 2025 9:55 PM
>>>>
>>>> On 14.04.2025 09:40, Penny Zheng wrote:
>>>>> HWP, amd-cppc, amd-cppc-epp are all the implementation of ACPI CPPC
>>>>> (Collaborative Processor Performace Control), so we introduce
>>>>> cppc_mode flag to print CPPC-related para.
>>>>>
>>>>> And HWP and amd-cppc-epp are both governor-less driver, so we
>>>>> introduce hw_auto flag to bypass governor-related print.
>>>>
>>>> But in the EPP driver you use the information which governor is active.
>>>
>>> We want to have a one-one mapping between governor and epp value, such
>>> as, If users choose performance governor, no matter via "xenpm" or
>>> cmdline, users want maximum performance, We set epp with 0 to meet the
>> expectation.
>>> And if users choose powersave governor, users want the least power
>>> consumption, then we shall set epp with 255 to meet the expectation.
>>
>> That's all fine, but completely misses the point of my question: If the governor is
>> relevant, why would you bypass respective printing?
>>
> 
> The only useful info in governor for epp mode, IMO, is its name.
> I deduce which performance policy user wants to apply through which governor they choose.
> If user chooses performance governor, they want maximum performance.
> If user chooses powersave governor, they want the least power consumption
> I could only provide appropriate epp value in above two scenarios.
> ondemand and userspace are forbidden choices, and if users specify such options in cmdline,
> I shall give warning message to say  that amd-cppc in active mode is governor-less, and users could
> set epp values on runtime to specify bias towards performance or efficiency.
> 
> If above is messy, I could also totally forbid governor thing for active mode... wdyt?

Then how would one pick between performance and powersave?

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 09:28:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 09:28:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990580.1374525 (Exim 4.92)
	(envelope-from )
	id 1uHJGj-0000O4-RG; Tue, 20 May 2025 09:28:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990580.1374525; Tue, 20 May 2025 09:28: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 1uHJGj-0000Nx-OX; Tue, 20 May 2025 09:28:17 +0000
Received: by outflank-mailman (input) for mailman id 990580;
 Tue, 20 May 2025 09:28:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHJGi-0000Nr-Vo
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 09:28:16 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c21932cf-355c-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 11:28:16 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-ad1f6aa2f84so1046183466b.0
 for ; Tue, 20 May 2025 02:28:15 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d498544sm711567666b.143.2025.05.20.02.28.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 02:28: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" 
X-Inumbo-ID: c21932cf-355c-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747733295; x=1748338095; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=SYmRLBQK2RYEVwfkMPhUt0J2xhRYGrFwsjIM1ROK/Qk=;
        b=FPYb5Jw06JAIGQl3PQAT6GBEEHSp0LRwWiUl1KdirriA3Bll3DuNV02y61u6JS8jOq
         liAPxdYIC56Clr3EE4Ya1rdIn/CewddfC+/plB3C8xBUNBTQ+RyFkK0RwS+3Fk9bRtN+
         CgqZUcIvod2jitC3pM9RGEwUX6orbDkLMG7No=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747733295; x=1748338095;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SYmRLBQK2RYEVwfkMPhUt0J2xhRYGrFwsjIM1ROK/Qk=;
        b=DikMCgGw4EJB5zsFHYoKZPsqDITBH4TGDLIdSf4tECrxe4lTfVMNLkMo/Eixg1Q4k5
         sxXCj2lE83E6DDNagUtLjql8Ds6ZH9Yr+SNN7ViAoa6Xy6LQeB/DE287LErnD/Cft/jq
         eRu/KBdWmR/qK2iTi+A0yElLTd4v3rOE96lg97nmOJxXiMuAqYbjuf8IN5rlVonflDvo
         hwRSr4NDzYxEDZp+hPHs4mxyZqlfOKkq+6YL3attQIQ4e0Ut+j2lt2rQOBiaNNcF57iY
         OKRMRbUCioGeTVjx7Y0TTV8MRWiJaaIT6Tbx1bST8Sa0fCxaerY1ra/43+qgOgv56XeE
         lMBQ==
X-Gm-Message-State: AOJu0Yx2T3Mioo/NpFkweVCAlo/XYytO0hijk8CCtqkZqSbQ/gr8sfzS
	6jwPl07xZFTCVRoswJPv1DfNGAxU4YPxkeZhAn1x+8+y1lU7gX9mkjvqYb2ceAGjqbEkANyLSyZ
	6GFQr
X-Gm-Gg: ASbGncsZBvFhQZFGNdhAxGLIjFv2IN1ULgAbXKba+DCCY6rkZ8AV84GehWaRnEPEqn/
	1h6Glr5YPzUuJGoRcbkcFQ5CMx991eFVr60iLkpNgSwO1fbe1ummJ1Xqb/pw6aVPiTohpsOYMsl
	WCRqpqxEMFn6rmv28XHZ20kq9EWJwmQMalLv38n278o5gMOj+OBplUhUqDDuPX7dWyJZ5xI4wA4
	tcbBmq3qltnPEJWHbWuIxJ6EsaEe0TJzjMR9bqmWXBFkZP9SAyA1VgHkwq4RLrM3U8IYs7mdZm2
	V4ZfuU8GN27vbzVTuBKQ6VznJscMYFTx8eV1QV6dCY0nh9zeyZgqr6VrmKYyit6rRPCfao/okfY
	0uttydr+nrVg67jd1E0s=
X-Google-Smtp-Source: AGHT+IHRu26nyc2HicfS233TojwPKQ+G0s8hUy2LcVt9H/x1hjwvS3ADWuw6lEBrGrWbB7KfcjZVZA==
X-Received: by 2002:a17:907:8dc3:b0:ad2:2d75:d7fc with SMTP id a640c23a62f3a-ad52f324fc3mr1287925166b.10.1747733295152;
        Tue, 20 May 2025 02:28:15 -0700 (PDT)
Date: Tue, 20 May 2025 11:28:14 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Teddy Astie 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [RFC PATCH] xen: Introduce extra IRQ count domain creation
 parameter
Message-ID: 
References: <9a746a8b2e9ee68a398795ecb5dcb53697aeece4.1747403245.git.teddy.astie@vates.tech>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9a746a8b2e9ee68a398795ecb5dcb53697aeece4.1747403245.git.teddy.astie@vates.tech>

On Fri, May 16, 2025 at 01:50:25PM +0000, Teddy Astie wrote:
> When doing PCI Passthrough with high-IRQ devices (e.g NVMe drives),
> the default limit may be unefficient as not all domains requires
> more IRQs.
> 
> Introduce a new parameter to allow the toolstack to tune the IRQ
> count if more is required.
> 
> Signed-off-by: Teddy Astie 
> ---
> 0 extra_irqs is meaningful, though I am not sure how to expose this
> special case.

You could introduce a new CDF flag to signal the contents of
extra_irqs is valid, or maybe use the top bit of the `extra_irqs`
field to signal the value is set?

> This of course wants libxl support next.

It would be nice if this could come together in a patch series.

> ---
>  xen/common/domain.c         | 8 +++++---
>  xen/include/public/domctl.h | 3 +++
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index abf1969e60..5c628962fc 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -912,10 +912,12 @@ struct domain *domain_create(domid_t domid,
>  
>  #ifdef CONFIG_HAS_PIRQ
>      if ( !is_hardware_domain(d) )
> -        d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
> +        d->nr_pirqs = nr_static_irqs + config->extra_irqs ?: extra_domU_irqs;
>      else
> -        d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs + extra_hwdom_irqs
> -                                       : arch_hwdom_irqs(d);
> +    {
> +        unsigned int extra_irqs = config->extra_irqs ?: extra_hwdom_irqs;

Newline.

> +        d->nr_pirqs = extra_irqs ? nr_static_irqs + extra_irqs : arch_hwdom_irqs(d);

I think the above line is > 80 characters?

> +    }
>      d->nr_pirqs = min(d->nr_pirqs, nr_irqs);
>  
>      radix_tree_init(&d->pirq_tree);
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 5b2063eed9..e4bb366c78 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -121,6 +121,9 @@ struct xen_domctl_createdomain {
>      /* CPU pool to use; specify 0 or a specific existing pool */
>      uint32_t cpupool_id;
>  
> +    /* Additional IRQ for this guest. 0 to use Xen default value. */
> +    uint32_t extra_irqs;

I think you need a domctl version bump, as the last one was done for
4.19.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 20 09:39:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 09:39:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990596.1374535 (Exim 4.92)
	(envelope-from )
	id 1uHJRc-0002EX-Pv; Tue, 20 May 2025 09:39:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990596.1374535; Tue, 20 May 2025 09: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 1uHJRc-0002EQ-MT; Tue, 20 May 2025 09:39:32 +0000
Received: by outflank-mailman (input) for mailman id 990596;
 Tue, 20 May 2025 09:39:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHJRb-0002EA-DP
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 09:39:31 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20605.outbound.protection.outlook.com
 [2a01:111:f403:240a::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5316e509-355e-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 11:39:28 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 SN7PR12MB6910.namprd12.prod.outlook.com (2603:10b6:806:262::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Tue, 20 May
 2025 09:39:24 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%4]) with mapi id 15.20.8746.030; Tue, 20 May 2025
 09:39: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" 
X-Inumbo-ID: 5316e509-355e-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=khpucjU/1tw+VdX57xl6BzsNWGejTFZ4ysonXrwRRgy9SER9nAJ5o2jaO5vJgamzJAXVwo/GypvC/13VjxfjG5uGFt/Lc1kYS2tOYevwOpaxPJZwXN+w1RJ07oHK0HrmtFgPILpH8FDT3UdWkfE3V8gVN0kCbvTeATLoNoI6CUhZOnN9PJdWMY3iS949GozbUYamsLtIitMM8/RzZuApa08D13e8fqvngljXMtsbeDEMGQEvKsOKXIfdqp/WXkOcRG4dHzy11RyqqZ9NQMmJqOZlhId+xx2QlEUC3WJgpDb/urRFckRd/GGHTqCDxWJEydrhspfhKEbchC8bNHdu8w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=W7cIxaU2MzYQ8UAcknvikbu/La2Z5BfuQvvrMNXyH70=;
 b=Gt67cVwfqkVYOZIsmEWKSCcoY2gj5laoJGiWOZU2zuC8OiNqCOsKx16aNynoiGhOdzP93e0i5QkeacqydZJ1m/RDcc47gi40WuCnxUSbGwh6PmnbCOm5CPsCObk8X1P1QxzLPECmq9pcsT/LCK+B1WEZPs4edg6Nt19sTbOLV/xIBXsbze43J5NIaTzJaTj+mh+tknvVrLlbwM558G63U5JZwPWR/ruLTQ5gLl/TF4FrPud7H4KAnyRbUojFS0fazhyl1uiaWPG6gXM/8BxKXCm2Zo8U+ZsS3tGmzeui3OQMnR7WuIBsE5cdgVTwiyo5RetTnihwkAByMLnGyRIllA==
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=W7cIxaU2MzYQ8UAcknvikbu/La2Z5BfuQvvrMNXyH70=;
 b=eJg4dF1D7LyF1TJaSJJFPsPS79MJ6EEjV39XOOjeg8hexxKnew9un9Z9ok5wLhssAXll7hn41BKffrF6MXGnJzhKAAVArlEJbm3TSoBf04/BUiAz7Qpo8idhvW6nVJqzQUuZYIwxh97PosCmjVNg/sy5oX8Zq3KokxVHnJu+LwQ=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Anthony PERARD
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 12/15] tools/xenpm: Print CPPC parameters for amd-cppc
 driver
Thread-Topic: [PATCH v4 12/15] tools/xenpm: Print CPPC parameters for amd-cppc
 driver
Thread-Index:
 AQHbrRCuBHJz/5ZpqUqHhc0gdq6hGrO8VLYAgA1zbxCABpifAIAK/PXggAAYTwCAAAAz8A==
Date: Tue, 20 May 2025 09:39:24 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-13-Penny.Zheng@amd.com>
 <63b3b016-551c-4201-a3b3-db19b27ea649@suse.com>
 
 <75679a60-7ca0-41da-b542-c5b9d5efdfbe@suse.com>
 
 <4a5580aa-2a2a-4b67-9bea-1c53fa5639e4@suse.com>
In-Reply-To: <4a5580aa-2a2a-4b67-9bea-1c53fa5639e4@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=76eb52f0-92d7-4b33-b17a-a123cb5fdf07;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-20T09:34:01Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|SN7PR12MB6910:EE_
x-ms-office365-filtering-correlation-id: 00298ac0-a14f-4af9-3e3c-08dd978234cb
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?czBMN1BDeVdMYkxpTmhZTUVJR0NDdnpVNTYwSGdrU2RYQTU2WVc1Z2dDRW5h?=
 =?utf-8?B?SG9GL3hGR1NQdWZGZEtLeEsrcU5Yb3l5Mk9ZRlp1RmZQdVlaQWh1enMzSzY1?=
 =?utf-8?B?cFBYM0xvaUVuL3VRSVFvQzI2OXhXSjM3TmlHbkFMNmhPQVlEbE9jQVlkNnAx?=
 =?utf-8?B?U2g0aU9WVnRzWENTa04xZWxycXBqYnBncDVnZkdFSUNORndKaGhSbkJYdzNO?=
 =?utf-8?B?Q0JGcWlRNmg1R0lwYUppb1dsNGcwNnVPcWwyZE0xdWRRL0swSTVheERraktp?=
 =?utf-8?B?L1pUeE9lcEpuSU5HdjRxWnplVWdra1M3M2QyaUUwRVprVTgrM28wOFFBRFg4?=
 =?utf-8?B?NVBpL0JVeVRTMG1GbXFRRmNqVURSam1mRkJHM2ZvZlhyQ2FMM3c0RWsySk1z?=
 =?utf-8?B?V3JaMjFzeURVUTBkRWhLYldwVngwc0g4S2ZrbFVJY1ZFSC90S2Zlc0Zvcjh6?=
 =?utf-8?B?MTdaaE5FbDFnNEpSL05sSkhpYi9DWmh2bDI5bnE4cGdDQlA5cFJwWTBaNU1N?=
 =?utf-8?B?MWxRM0MzbHdkR2hZWmMyTWtzSjhrUVdISTRVTXBJT01DeVN2WnZxQVRaWjJp?=
 =?utf-8?B?OVY3U1dPZ1pHV05PVWhLb3Z2V3BVWDZ4Q1VnNmRrUHRsMEY1dkRHSm1zWjRj?=
 =?utf-8?B?YSt5YUxSdGtyZUJHaXlrRXI5S0E3c1hSODFBbXhydE1DZUJVdFdqdzFoMFND?=
 =?utf-8?B?VlFkOFlSMTkveG1nd3IvenhLTTBEYnYzMldQQ3c4NHR1OS9PUmRNSVk0VkF1?=
 =?utf-8?B?Rm4rbWt5bTlaMHAzeHhMaEk2cG8rWVkxSnBRYi9TdVg0bFlSdzQrZ3krcjJG?=
 =?utf-8?B?SGlyMU5zMFcyOGwzZStyeXZPb0V6RDUybVV6WExXZ1NvZElyMmtEcUlSZVBm?=
 =?utf-8?B?bnhCbkV2V1duUnRjaTF4UDcrVWJZeTZOcUhpTW5FeVFXVWkyRTM2WkU0NTNE?=
 =?utf-8?B?eGxtVUhkb2NqdlI4cGE2KzFhRlMrQUpGaHQ4V2tSeDgxWERlQVJQQzV5Y2Zp?=
 =?utf-8?B?b1BLSGhCUHMzNG9pUk0zeTNybHZkOU1zb09ucW54N29LbFdNS1BoamhkMyt6?=
 =?utf-8?B?dkZxZXNVV2U4c2NOK1IyNEt3a0Z0ckE5WXlRZWc1YmhoWW43Ky9HbGxOMmtD?=
 =?utf-8?B?Tm1FdkNyR1ZSSVNicCtXbWhJTE5zcTl5bVRCN1lkSmd0VUltMHdvYWpzSUV6?=
 =?utf-8?B?SGJMWCtwV1dISjZaT1ZNZ2xTVWYvaXlWU0M3VFR2OWhjUyt4aXJqMGI1WU5l?=
 =?utf-8?B?VG5oWmhZOVc2ZnkxU3R6djFpODUrdHlVN2R4Z2xDRkRuYUZSQ3BlZnBaT0hU?=
 =?utf-8?B?M3Fha05lOWhNQlhEUnlBb0dtWEZCclVBNnlVeWVCTVk1cjBIQjNUc04rUHYv?=
 =?utf-8?B?S2d2YUx4N3FoUUJ2MkF2ZjVKZGJyL2t3dXZtb0FWM3ZhMDROMkpGMzNodjBa?=
 =?utf-8?B?a2VJMjNKVmtzbHVCSkpoR0hZeWgrZVZVd1BzR2lidTdqSGg2MlY5clBGUmgz?=
 =?utf-8?B?NFFWUkZoMnRMNHJtSG9OcGFpVGlCTEp6Vm1iRUI5bmt1TWNwUXFaakx1amlw?=
 =?utf-8?B?eGFVaVlXNTBLZ0Fzbmx6WXdqK3ZsVFJ6a2RDVXYzZjJNejZKYkxhdlBMUlRP?=
 =?utf-8?B?NFM2K2NZR0U5MTJmNGxuV3VQcThLb0U3UXQ0VTdsc0FFcTdtamRDelZkTXUw?=
 =?utf-8?B?dlYwcCtKOCtlSnNoN2E0K2t6blRHVnZkK2pKNTFpUVJsbDRFL3Z2UVVIZzZ4?=
 =?utf-8?B?TTllUEQ0N1Fudksyc3FRcDFaYkQ0aEh2SnVnRG1DV2s4NzlSRCtDMStxVzEv?=
 =?utf-8?B?R1VlN2c5a3J2UUFFS1dMT0Rsb3FhMlB6MkxGVGZ6Wjk5SEtXS2NhQWRuc1RB?=
 =?utf-8?B?Zi94Y1NYVzlhNllvNlZKL0JJNUlPZGJrOTJVdUV6ejhiUjlBKzg2aEFDNVl2?=
 =?utf-8?B?NmpHbWx1SDlqV2FkUVdKdjN6YzVxQU96MjJYUEZBR0R6V2ZrZFY0VjBPRDl0?=
 =?utf-8?Q?Nkfpg5i3XgKzvytjLq1itsNaQWIkOE=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?R1lYQWcrK01peXJwUlg0NTk2bHN4SUE0TlFGcC9NQ3IvSWFhOEVMZzhPSWg2?=
 =?utf-8?B?N2dIb3NrUmhkWWMxcmhrN3ZzUDlVbzZ2RzkrRzlCNVRqbzhIcEdEOHBCUFgz?=
 =?utf-8?B?QU94VDY0QzFWZHpNc0Zza0pGVTNLQjdFWEtwVlV4MFg3T29oRGk2RnY1OG52?=
 =?utf-8?B?TGVJeGxxMktFWkluRDlXL0ZuU2t6R3JVUG9rZm9RT2hyUVVUb3hzaUtVRVlF?=
 =?utf-8?B?VExqQWJhUEVEQlBuRG1GeFZIZ2kzekl6TGJsRytsTXR0LzBZKzNZQUFuWVBS?=
 =?utf-8?B?RzdaaHFiZlo1bDJZWHJKYXdZY3h5a3pKWGlqWXJBN2phUVB3R0wyYWc5Mm8y?=
 =?utf-8?B?UStTWm1HRHJqVFVQWmpwbDJCRGdCL1BLUFZBUm13Z1BBNjdKbDlKS3JqN0M2?=
 =?utf-8?B?NlhQZEpVREFHWXhxSmxkNmZ0WmlGektTYk03QjJSdVd4dkFhL2p0TjlCZHVE?=
 =?utf-8?B?MVVLVFRRSFdGVmJCaU9FRlp5SUxhRjNoeFJ6K2dzK0tLUG9UZnZIRkhuZ0xn?=
 =?utf-8?B?NHNQcE5QOTFkNW5QeGJoV3ZpcVh5S2J1VDdkVkR1KzA5UmdrMXJ5QTdDa1Nk?=
 =?utf-8?B?eGZZTFNBTGdLMTZWbzU2eGpETkZFNnNnblhVRFg1UFBSdGExZFBJTHo3TU4x?=
 =?utf-8?B?enp1V2NrL1lJOFdzNGIrTngrUHJvOHdUVHBnU0t2dHh1bFdqdTdnZ01oZ2lP?=
 =?utf-8?B?N2NXdk4xN0JKQUZUbm1tUHVqUHZSUmo1aTNvZHEyVm9rWEo2M0J3azRvM3NS?=
 =?utf-8?B?MnMyNFNtVDdPNWwxajhFSUpVUU1xeUJiSkFNYkRZS3FLZ1JTb0R2ai8rbmox?=
 =?utf-8?B?SFFwSmNzVUo2eG5yRzhQK2ZHTFd3blNLanRTTWFrMlk0YWNJaHlLb1gwemNl?=
 =?utf-8?B?UzFER0M4d0FrMERIUlBGOUpYbnVCbit3eklGMnpJNW8zL1RFcGp2c3QxM2p0?=
 =?utf-8?B?cjlQbGp4eXo2VEQvUmtIUmVkNVN3cjFkNjBoTHYxaXkvai8zcklIdGZsb1pM?=
 =?utf-8?B?eVl0M3h1NlJnNEdNU2p1NkJ6MVo3RmhRbHhGYmpuRStFTlY2SWFuNSt3QTZH?=
 =?utf-8?B?V0Y1TkduSW9qdytUU1hSQ2ZIZXF1R21lQkptQzhTbFJtcmVrMThuTGc4OWdS?=
 =?utf-8?B?Q01ocXlDTkp2S2RnUlJuQnowSU9VUS9qNGduZEJOZjFOZkRDN3RLaXJrRmJC?=
 =?utf-8?B?MnlYUnZ6ZWNsenhQd2hHM21nZ3UzYXZ0MWNwT0IvSEk1WG5uVXNMOGtBZ0dY?=
 =?utf-8?B?OTArZDRVWktQV0liblJJOHVjWENYR3QyQXd6VnBVdEdOQWJqanJKZTc5cXlu?=
 =?utf-8?B?TWJ4Um9Gb0lJZ2FaWWNhNDNneTF2Kzk2QW1XdHo2OFdRS0V5cFd1bzJRRkpW?=
 =?utf-8?B?MjNmRVBHK0NqYm9qcmp2eUVpOUtwZHEyUWhiSWRSREdrRGRtdXRsZ3BBOXpK?=
 =?utf-8?B?d3cySTZMOHZ0RSs5cWVpUlhzUEZXWE5SclNtMW1FTTA2dWQ3TCtTR3hsd3FV?=
 =?utf-8?B?MTd1eVMzVVRhWTF3a1U2amlMTDlMMUhkQ0Nwd3dOeDBrZFRYdUFaTWpTT29j?=
 =?utf-8?B?bFF3RmpOYmhFK0hFa2ZUbngwVVE5eVNjdHFoZmhtN0RaUnhQM3YrcEdqMDdH?=
 =?utf-8?B?Rk0yUGN2WC8xb3NON1JHbTNtWmpKNjMxS1Bpck1PTWdNVnBWaHpoNlYzYVNa?=
 =?utf-8?B?akpkazNkdWorRTdFeWU2RjZFUEhCckpWTStlSnQ2N1dSV0hPYkx6M3ZyR2Nj?=
 =?utf-8?B?MCtqSmlKenE4Z2gyd2xSWWIzN0NwK1E3NG9lVWZCb29SbU0zS2U4bXFHUURu?=
 =?utf-8?B?STY5Mnc0dUdYd3VVVWRRUklPUnJQS3hLcXhEelpsWWlNOFdWUGQvbTVMandU?=
 =?utf-8?B?aFdTNmRDL2ovbU5vSzNySThNZDVNcUwzREwzT000RGVZb3RtTXNUUnhwR0xO?=
 =?utf-8?B?czA2dHFTblNYZ3lMWktvcDhSZUdqV2h2YUtWWUR5UlRlWUxBaHNacTVTV1Zn?=
 =?utf-8?B?MmZqVTBSYktWVVdiWW5YZ3dyWS8vdjBEaGhHVUZUeWVySThqRjUyK3VXbTFs?=
 =?utf-8?B?aWJqNHNUcVFlR01IRmduUnFDWE5tYklSMlg0Nkl6OUpsZTJUS0JURno5K25q?=
 =?utf-8?Q?gVBs=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 00298ac0-a14f-4af9-3e3c-08dd978234cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2025 09:39:24.3289
 (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: Knt4Yh/Br0l0IoKziUIgOUyXaRcnQ0Wx4iLpGsF7//VwZfXtpw40uDmSubdGXEbCPLq3vX+bu4wVlVR/KGMBlw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6910

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAyMCwgMjAyNSA1
OjE4IFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+IENjOiBI
dWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFudGhvbnkgUEVSQVJEDQo+IDxhbnRob255
LnBlcmFyZEB2YXRlcy50ZWNoPjsgeGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggdjQgMTIvMTVdIHRvb2xzL3hlbnBtOiBQcmludCBDUFBDIHBhcmFt
ZXRlcnMgZm9yIGFtZC1jcHBjDQo+IGRyaXZlcg0KPg0KPiBPbiAyMC4wNS4yMDI1IDEwOjIyLCBQ
ZW5ueSwgWmhlbmcgd3JvdGU6DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+
IEZyb206IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gPj4gU2VudDogVHVlc2Rh
eSwgTWF5IDEzLCAyMDI1IDQ6MDMgUE0NCj4gPj4NCj4gPj4gT24gMDkuMDUuMjAyNSAwODozNiwg
UGVubnksIFpoZW5nIHdyb3RlOg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
ID4+Pj4gRnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiA+Pj4+IFNlbnQ6
IFdlZG5lc2RheSwgQXByaWwgMzAsIDIwMjUgOTo1NSBQTQ0KPiA+Pj4+DQo+ID4+Pj4gT24gMTQu
MDQuMjAyNSAwOTo0MCwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4+Pj4+IEhXUCwgYW1kLWNwcGMs
IGFtZC1jcHBjLWVwcCBhcmUgYWxsIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBBQ1BJDQo+ID4+Pj4+
IENQUEMgKENvbGxhYm9yYXRpdmUgUHJvY2Vzc29yIFBlcmZvcm1hY2UgQ29udHJvbCksIHNvIHdl
IGludHJvZHVjZQ0KPiA+Pj4+PiBjcHBjX21vZGUgZmxhZyB0byBwcmludCBDUFBDLXJlbGF0ZWQg
cGFyYS4NCj4gPj4+Pj4NCj4gPj4+Pj4gQW5kIEhXUCBhbmQgYW1kLWNwcGMtZXBwIGFyZSBib3Ro
IGdvdmVybm9yLWxlc3MgZHJpdmVyLCBzbyB3ZQ0KPiA+Pj4+PiBpbnRyb2R1Y2UgaHdfYXV0byBm
bGFnIHRvIGJ5cGFzcyBnb3Zlcm5vci1yZWxhdGVkIHByaW50Lg0KPiA+Pj4+DQo+ID4+Pj4gQnV0
IGluIHRoZSBFUFAgZHJpdmVyIHlvdSB1c2UgdGhlIGluZm9ybWF0aW9uIHdoaWNoIGdvdmVybm9y
IGlzIGFjdGl2ZS4NCj4gPj4+DQo+ID4+PiBXZSB3YW50IHRvIGhhdmUgYSBvbmUtb25lIG1hcHBp
bmcgYmV0d2VlbiBnb3Zlcm5vciBhbmQgZXBwIHZhbHVlLA0KPiA+Pj4gc3VjaCBhcywgSWYgdXNl
cnMgY2hvb3NlIHBlcmZvcm1hbmNlIGdvdmVybm9yLCBubyBtYXR0ZXIgdmlhICJ4ZW5wbSINCj4g
Pj4+IG9yIGNtZGxpbmUsIHVzZXJzIHdhbnQgbWF4aW11bSBwZXJmb3JtYW5jZSwgV2Ugc2V0IGVw
cCB3aXRoIDAgdG8NCj4gPj4+IG1lZXQgdGhlDQo+ID4+IGV4cGVjdGF0aW9uLg0KPiA+Pj4gQW5k
IGlmIHVzZXJzIGNob29zZSBwb3dlcnNhdmUgZ292ZXJub3IsIHVzZXJzIHdhbnQgdGhlIGxlYXN0
IHBvd2VyDQo+ID4+PiBjb25zdW1wdGlvbiwgdGhlbiB3ZSBzaGFsbCBzZXQgZXBwIHdpdGggMjU1
IHRvIG1lZXQgdGhlIGV4cGVjdGF0aW9uLg0KPiA+Pg0KPiA+PiBUaGF0J3MgYWxsIGZpbmUsIGJ1
dCBjb21wbGV0ZWx5IG1pc3NlcyB0aGUgcG9pbnQgb2YgbXkgcXVlc3Rpb246IElmDQo+ID4+IHRo
ZSBnb3Zlcm5vciBpcyByZWxldmFudCwgd2h5IHdvdWxkIHlvdSBieXBhc3MgcmVzcGVjdGl2ZSBw
cmludGluZz8NCj4gPj4NCj4gPg0KPiA+IFRoZSBvbmx5IHVzZWZ1bCBpbmZvIGluIGdvdmVybm9y
IGZvciBlcHAgbW9kZSwgSU1PLCBpcyBpdHMgbmFtZS4NCj4gPiBJIGRlZHVjZSB3aGljaCBwZXJm
b3JtYW5jZSBwb2xpY3kgdXNlciB3YW50cyB0byBhcHBseSB0aHJvdWdoIHdoaWNoIGdvdmVybm9y
DQo+IHRoZXkgY2hvb3NlLg0KPiA+IElmIHVzZXIgY2hvb3NlcyBwZXJmb3JtYW5jZSBnb3Zlcm5v
ciwgdGhleSB3YW50IG1heGltdW0gcGVyZm9ybWFuY2UuDQo+ID4gSWYgdXNlciBjaG9vc2VzIHBv
d2Vyc2F2ZSBnb3Zlcm5vciwgdGhleSB3YW50IHRoZSBsZWFzdCBwb3dlcg0KPiA+IGNvbnN1bXB0
aW9uIEkgY291bGQgb25seSBwcm92aWRlIGFwcHJvcHJpYXRlIGVwcCB2YWx1ZSBpbiBhYm92ZSB0
d28gc2NlbmFyaW9zLg0KPiA+IG9uZGVtYW5kIGFuZCB1c2Vyc3BhY2UgYXJlIGZvcmJpZGRlbiBj
aG9pY2VzLCBhbmQgaWYgdXNlcnMgc3BlY2lmeQ0KPiA+IHN1Y2ggb3B0aW9ucyBpbiBjbWRsaW5l
LCBJIHNoYWxsIGdpdmUgd2FybmluZyBtZXNzYWdlIHRvIHNheSAgdGhhdA0KPiA+IGFtZC1jcHBj
IGluIGFjdGl2ZSBtb2RlIGlzIGdvdmVybm9yLWxlc3MsIGFuZCB1c2VycyBjb3VsZCBzZXQgZXBw
IHZhbHVlcyBvbg0KPiBydW50aW1lIHRvIHNwZWNpZnkgYmlhcyB0b3dhcmRzIHBlcmZvcm1hbmNl
IG9yIGVmZmljaWVuY3kuDQo+ID4NCj4gPiBJZiBhYm92ZSBpcyBtZXNzeSwgSSBjb3VsZCBhbHNv
IHRvdGFsbHkgZm9yYmlkIGdvdmVybm9yIHRoaW5nIGZvciBhY3RpdmUgbW9kZS4uLg0KPiB3ZHl0
Pw0KPg0KPiBUaGVuIGhvdyB3b3VsZCBvbmUgcGljayBiZXR3ZWVuIHBlcmZvcm1hbmNlIGFuZCBw
b3dlcnNhdmU/DQoNCkluIGh3cCwgd2UgZGVmaW5lZA0KIg0KI2RlZmluZSBDUFBDX0VORVJHWV9Q
RVJGX0JBTEFOQ0UgICAgICAgICAweDgwDQoiDQp0byBwcm92aWRlIHRoZSBiYWxhbmNlZCB2YWx1
ZS4gVXNlcnMgY291bGQgcnVuICJ4ZW5wbSBzZXQtY3B1ZnJlcS1jcHBjIGJhbGFuY2UiIHRvIGFj
aGlldmUgb24gcnVudGltZQ0KQW55IG90aGVyIHNwZWNpZmljIGVwcCB2YWx1ZSwgdXNlcnMgc2hh
bGwgcnVuICJ4ZW5wbSBzZXQtY3B1ZnJlcS1jcHBjIGVuZXJneS1wZXJmOk4iIHRvIGFjaGlldmUN
CldlIGRpZG4ndCBwcm92aWRlIGFueSBvcHRpb25zIGluIGNtZGxpbmUsIHNvIEkgdHJpZWQgdG8g
cmUtdXNlIHRoZSBnb3Zlcm5vciB0byBhY2hpZXZlIGEgZmV3LiBobW1tLA0Kbm93IGl0IHNlZW1z
IGl0IGJyaW5ncyBjb25mdXNpb24uLi4uDQoNCj4NCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Tue May 20 09:43:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 09:43:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990603.1374545 (Exim 4.92)
	(envelope-from )
	id 1uHJV8-0003yI-8Y; Tue, 20 May 2025 09:43:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990603.1374545; Tue, 20 May 2025 09:43: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 1uHJV8-0003yB-4d; Tue, 20 May 2025 09:43:10 +0000
Received: by outflank-mailman (input) for mailman id 990603;
 Tue, 20 May 2025 09:43:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHJV7-0003y5-1k
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 09:43:09 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20630.outbound.protection.outlook.com
 [2a01:111:f403:2418::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d470cce7-355e-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 11:43:06 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 SJ2PR12MB7798.namprd12.prod.outlook.com (2603:10b6:a03:4c0::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Tue, 20 May
 2025 09:43:01 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%4]) with mapi id 15.20.8746.030; Tue, 20 May 2025
 09:43: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" 
X-Inumbo-ID: d470cce7-355e-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uVEeh9vl9x3xppP586kl/KPYWagsVZFfKFnq0Kn4Xt4UHnLc9fxWUChzsUz9+XFcjdAi/29LCa40O4MY0QNbiiuYvMjiJbI0mGH4D1ylXpwMRCE/TZZM5Ndmnk1HXb2rzJvr65ooELWnJXzIHcKRaSFHW/WG11bpalXzd3ltfwi9Ab/hMHDjYeFZ5zmFbAhYpPte0TDg356G744VBRIRTXxkitfoCyjr7EWiRU685IO101nG4OjIpYVU4ehJ4WehxkCMSYqQlYGR/3NT9SztN/Fd7zdk4rLBELxKbOkZGsOLCXT9hi09MDcPksgs45NaivJSNIYWe23z1BJi18JIkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=apNLGcGF8Mv2yVbkbH//QKi7efTw3EdFgfhsFYgUfwg=;
 b=tGSStXManuW1/lexo/CHhVqxRKRccShyOadtue8QKPT12IxLiIzpQod9ZWxKXAOfk3qlOJXPiAjtQTqmB6yev13pgJi7gvJZpHMRZ1eJY07z2b8SF6pfD2GmksJMF7P6G1QygM1kIddVcz4iiYCtzARCiem9W0fhwi8FmWHUAn1IXzgvLzh66qnjQ2DJimg6NWyjL/+jxgYECwxQmmMdOux1fsFwuSN3OD1tiFC0nPyJpiuhzcwenUO0s8O03KFTVPSxEAwop+fFmvjc7fcMIpxlWoJhHJ5mm+RDDJ8ifuxFLrFWFaSlz3vXC/dBQbJWAy3iS8a0iF5k0kIEeLLvJg==
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=apNLGcGF8Mv2yVbkbH//QKi7efTw3EdFgfhsFYgUfwg=;
 b=kc9+RKnvRbzPejpA8DKJu2BcbPFOSp9rfIspPtiIgNU21hMlQAWvZ3CMh7kNrFLwo9HMgN5IopAAckvMcKU3M+2i3BWIsTeQFBnL4Hy1fRLJNZ1gGWXwdnOrCpMZFO51VCDejuJ9Ci6oQ5Lv5RWbdLM2JRRe8wXeErbfOzVadcA=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, Anthony PERARD ,
	"Orzel, Michal" , Julien Grall ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Topic: [PATCH v4 05/15] xen/x86: introduce "cpufreq=amd-cppc" xen
 cmdline
Thread-Index:
 AQHbrRCmtZ7pr/knH02upOrsNIOYE7O6sNeAgB8mXDCAAE/jgIABP6gAgAAOsICAAAdcAA==
Date: Tue, 20 May 2025 09:43:01 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-6-Penny.Zheng@amd.com>
 <57a3b2c0-d57d-46e3-b248-0e243f715423@suse.com>
 
 <0f673a09-840c-4319-bec8-62fd920a6b84@suse.com>
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=c6c44406-45d5-4222-9a76-2f5fdeaa9b02;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-20T09:42:42Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|SJ2PR12MB7798:EE_
x-ms-office365-filtering-correlation-id: ffa10cd5-9426-41dc-8aa0-08dd9782b632
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?TW96blpqTXcrZkpCSmJaNU92MXRqejVScUxRRmZJQ0VtYzFzazVEZFVnQU5T?=
 =?utf-8?B?Q2hoNUhNNjJyaVY2dVpicTd2cFU0V0hiVTJRMDNCYmVhc1lGdlBvYi80M1JO?=
 =?utf-8?B?a2Ezc0M4d1djaEZQdFIycUxzWk9ySW52WldiNWh3QnhzWGpEa1ppWEdVaUlM?=
 =?utf-8?B?dkVmeUtIUDRQdzM5NTZSaW95ZGpUZmNlWlBMNFY3U29kSGhNTUhnN1dsSjgv?=
 =?utf-8?B?ZWt3UWdXMENMeUFpdnErZC9qVUdtTmdNK0pnY0xzeFVvbm0wdFpObnZyMEdp?=
 =?utf-8?B?Sk5qblBpVGxOMnRKMmtJMEpPSlV4SFRVSnhrcXJtcVZaQnQybUY3YlFtcGRN?=
 =?utf-8?B?RDNaS1VubU5iWGgxRWRUTUdJU0lCNGJ2bHBDR1YzNHhORjZ0cnpKRWp3VDNK?=
 =?utf-8?B?WlFLVjhtckJJSVdKQ2V5SEFQZ0FiQTRqbXJWekNzUWxNakFIS0x0STZmQm5p?=
 =?utf-8?B?SjlDcGZHYVNvZGtyc1JVRXRqYXg2cEJHK21qbzEwWXFaVVM0U3AxaS9WYWhO?=
 =?utf-8?B?OWw3N0R4M3NTMUxGdyt3T2o5S0FKak5vOFdNVzBlMnNGTGRVZDRVT1N4NFZ3?=
 =?utf-8?B?NTlETkRFd3ZhUXFmOVV2QmZzeXBiaXU3RTdFQnVraG1ENG1XQ1RDUWxIUUhn?=
 =?utf-8?B?RzVkTkszMTNiQVZZeFdZY1ZDRFcvQlIveGdVWEp2Ung5eEFmOURvMkpPaThB?=
 =?utf-8?B?d1hYdDRkQUlGT1o3YjlXMUZ5K1NyUzhwOVo3b0hXa3VKc0ZJMWFnMTgrOHdN?=
 =?utf-8?B?V2ZtbzlnVkdNVTVMdThraTYyTUhSNmM1b2krbzVhMVFobE14L3BGMjRhSjVw?=
 =?utf-8?B?WERocVZNU1pOc0V3MmtYRXBYTmFTMmNkdXR2U1d5YUR5UE9zOW9hY20wRDl0?=
 =?utf-8?B?NENNeW41TXBhemlvVW1PdUNHVXZ4dS96U3JPaC9meTdvM1J6T2VPZThlU0lF?=
 =?utf-8?B?WVhtSi9BeHhiSnRCNEJzODdBcDNaT2dGWXhXQ3pzK1dYR0k1azBTK2FZMjV3?=
 =?utf-8?B?S09yakhUQ2tiQk9SRUljaGVJKzYyTE5PSnVZTGpva3JsK0pWOEtZbUQ1bUZ6?=
 =?utf-8?B?QXRaVlpwYzdjdGU0VUxTQzB1ZG1uV21Ja3dhZ1RIakhXemZYSTJISUpaWXRT?=
 =?utf-8?B?ZWlpbjlzanQwdUJ3WnBJTXJsWUQ5RS84VEgzRFFBR0RJN1R3OG4zeCs5d290?=
 =?utf-8?B?S3kySzlBdHFMSXVJWExuaFZ1T3BiK0ZGcXRFNUxScjlGWUROcU1TbmluTnRi?=
 =?utf-8?B?SHA0b1JKaVJjY3B5eHl0bUx0SnVXU1NBYXlHNFBmKyt6cVJSRm5TZGN4anRq?=
 =?utf-8?B?MStXbmdyQjZxOVFBNmZZUGNKTGlNTXhtWG82c3Y4SVp3MnNSMnNnQ09SanVW?=
 =?utf-8?B?MUZWTHhrYVl1V3NrbGRXRWxQQ291NGd1RjJoRFEzNnRBNFVuOUxnZzY4UUVi?=
 =?utf-8?B?ei9GVTFuVUEzcmtVcW10bHBWV2hTWVpxOWpMMHBQYlZtRjZ3eGQ0dWpVaVYx?=
 =?utf-8?B?QlBuQ2grOUhFYW5oV3ZNTkVZRFZhQUhCT0ZpRWxoMFZBaThsem9MZWVlMFR6?=
 =?utf-8?B?QTlaWUhvdW90UjFYbXdLbDZKQUYrL2JSakZBdGgrSkJ5U29EZVFpMDRUeHRx?=
 =?utf-8?B?L01VOUN4RnVBY0RRZ2lmS1dIeUJ2VUxJWWZNbUJ3S2UyUXc0Smx2Nmh2anZV?=
 =?utf-8?B?cHJrczFJMlZOeHFpWUpxbDZLLy9EYzk0RXVPU0VoSDZSZXhkcmM2KzZLb3BM?=
 =?utf-8?B?OW41Ym5FL3drV2tLUFRzME83WjRXRXhFcGR5SzRnQkpYQzFSeUg2eXBhcDhJ?=
 =?utf-8?B?S3Vtckw0YmR2YW10YjF3cGF2MG1tMWpSU01ZVXA4YlNnSDhZZlIwcTBpMnZV?=
 =?utf-8?B?YkJ2VFZaSWhxZlF4NkdHRGRudWxUZUcrVWhuRVpZTGsyQURqSGlQMWM0NVN6?=
 =?utf-8?B?RUhGbWd5NFYybUg2WFVyWWQ3blpxMXhHSnlUNzgveHJycUMxTFdubXBjUEw4?=
 =?utf-8?Q?0AUrtStDjhOuk9cOLCv53Bhnc9k/b4=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?akFpUUtDaGlMUjhzdGhoL0haa05jYjZHM2NKeTJxa2REUnVML294RkJ6K01q?=
 =?utf-8?B?bEFNSGlNNE1IS011czlNdlpWNjVTbHhDNmNrR2NnNGkyK1RHZmhBZDd0STRl?=
 =?utf-8?B?bFNtTklVYXJEZHdhQWdPaVdjUXlpd3JnUnBJbWxpQnZqTm1BYi9vaW53aGRx?=
 =?utf-8?B?d3VobFUvQm44QlFjWVhOOGk2K2g4Z3BNRVU1RVV0S3lsQ0cxQk51MGFuZmo4?=
 =?utf-8?B?a1NmUVF1ZERaRmxGSFI3cjFhZDNvNmVRaXdlRDVNT2IyUFRieUNWL0s2ZlNp?=
 =?utf-8?B?cEtJOEVBd2haQmdmSlhKWVJ2WWRBWmIyemhOU2NENENSNERQbEJyR0I5dVNO?=
 =?utf-8?B?YXNxSjc5T2ZjWVRhMk9aVGhndlpwcGFVdmhQTkRwY1RnSG5FVnlJVVMzMk5I?=
 =?utf-8?B?YzZQMVJTSzNaNHNuVUdDc2hYMTdicXowTGppd3c5Y0pZek45V3RoZ0ZoWXQz?=
 =?utf-8?B?M0xJZ3JBay9qeEI1MnNZRnBPd2VKYm8zNHZUYk1wc1hCMUlvY29lS0MySXRv?=
 =?utf-8?B?Y0JLS25yWndMTFJEUEgwRmFlZzJ1N0Nqa1AycFlvUnJqejZiK2czNnJWZ0F5?=
 =?utf-8?B?OG40Unp5TlNFUFZpbnM5Ym04TVRiaDdjUWx3Q082TmlRM1ZMOFRSNVpkdytr?=
 =?utf-8?B?Z3RxS1V1SEI5bkk4K2JxMVVLejArR24vM0RUN2FwRU1TTi8xYWRwUGRKV0pY?=
 =?utf-8?B?QThsWTMydTJ1b1hUSHVEVGFZMHdZdUhiQzZPdVVnMzVwUFlqV3pZd0Rmd0hY?=
 =?utf-8?B?cTRQZHBCeUxkZ0pLdmxtTUZ6SFlNZ29CeWNlT3R1UUZRVUVYbmQrMm1oUFVJ?=
 =?utf-8?B?YWNPS0pScThZVlBUKzU0aUxrMS9rd2p0V01makpjZTZ3RmFDMWJDMEFmTjR4?=
 =?utf-8?B?TVJ5TFVUdEFIaDA0cFFvTFhDcGFEOGJGZExNRW0vMGRmTE54R0NYTWN5SjlM?=
 =?utf-8?B?OHo4OWRqL0VYL05Sdk5yVFY3ZTJwTSsyOXBxbHRZZkduSVJUWXNvWXdaRWh1?=
 =?utf-8?B?MDZMYXJleThOVkkxKzAxQzV1UGw4dzdhV2pWQWlvMm9CVTZHd0VKK1M5Ukxx?=
 =?utf-8?B?SzlXS3VONmdSMGRJSDYyZ0VFOEVCa01iN2JsSTZtOTZDSUQ5eW5aZnVXZms2?=
 =?utf-8?B?QlVaZ3FsY1FvZlNzUWxxMzNTM2ZlNWI5bEtpdGloRGE0NmxrdDlPNnRhZjNT?=
 =?utf-8?B?K0dFYkpXSHFER0RNZGIxTDlvc25oT2tqK0tzTUpyQ1p3NnhEK1AwY0hTYmU5?=
 =?utf-8?B?bTFHV0F2R2VKeXNuWXJmaHhFdTBhRlB2V3lxVURVUCtWc1ZmNkJlNnhGNTNx?=
 =?utf-8?B?Nk1JY3dVbnc2ck1QMmVDcS85ZUh3YTUrN3REbjkyVFp6aDlXY0FWNi9xSDhV?=
 =?utf-8?B?TzdLVEtHSjA5OVM3L3ZrWklDSGh4Y0ZLZmUvMnRYbGNidm84YXRnZW9WdGxW?=
 =?utf-8?B?M2ZsZVZmMVpFTXdTL1l0dU9UTm5TZjVGVngxTFBxSzJzSDdOYWx6b2t3Q2FN?=
 =?utf-8?B?eWpJRkhXQ1F6VXJCeHptWEZiV0JrZUUrelpKWm5pMnRBNmVkb2ZOMWh0TGUy?=
 =?utf-8?B?cUlEZndNVjZWN0RVNXlJT0ZQblgzOWtSSmE5T1hLUnlReUxiVEdBZlI5ZDYx?=
 =?utf-8?B?NERuSndmS1MyMmJ3ekpHYVVGck43ek9FYkJESHFQTCtwMmlYd0tJRExoNTZr?=
 =?utf-8?B?K3kzeHpNQUpEelpyRmJpRFdJUEhSYjIyVk5xcTRnTHVBR2YzSU43WkdmcWVY?=
 =?utf-8?B?SUdVV1pwclp5dkN2NTdDWE9lN0txOTRTS1JUc25NcjJzUGpySjNxOFRnMER2?=
 =?utf-8?B?Rjh2L0xRSDZvYml3QmNuYWE5SkJmOUt1YUpqWi9kbi9IbzBvVWF1ZlFDTmUz?=
 =?utf-8?B?S3lpOTQ5NWNTaERvcTlZMWpGLzVGN0VYTVRiQWZybjlwRlNMK0VNMkJVSkZR?=
 =?utf-8?B?SmFNTGRLN1lmdWVpUVZLaW95VjlISWhCN0xkaVoyU1R2TzdwOC9JWWJGVEds?=
 =?utf-8?B?cW5QMDRHTUs2NnFJQTBvNGljZkNVRDRXdGNXdEVKTVZtZXg0QlhVWFRCdDhK?=
 =?utf-8?B?K3QwN1hwUitJMThDdEtOOWR0NVJNOERBRCtZbEpjZENIeDBpWGZYRGRXQVBx?=
 =?utf-8?Q?gJHY=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ffa10cd5-9426-41dc-8aa0-08dd9782b632
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2025 09:43:01.4275
 (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: 1rdXr84kVnqBSByTbiZT6z+hngNGZywfDZqqDHDTgLnn1F4AbAJyeTuEbbDGztoSa52WZicjzpqZ9uEKyTYiqg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7798

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAyMCwgMjAyNSA1
OjE2IFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+DQo+IENjOiBI
dWFuZywgUmF5IDxSYXkuSHVhbmdAYW1kLmNvbT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5j
b29wZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJhcmRAdmF0ZXMu
dGVjaD47DQo+IE9yemVsLCBNaWNoYWwgPE1pY2hhbC5PcnplbEBhbWQuY29tPjsgSnVsaWVuIEdy
YWxsIDxqdWxpZW5AeGVuLm9yZz47IFJvZ2VyIFBhdQ0KPiBNb25uw6kgPHJvZ2VyLnBhdUBjaXRy
aXguY29tPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPjsgeGVu
LQ0KPiBkZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY0
IDA1LzE1XSB4ZW4veDg2OiBpbnRyb2R1Y2UgImNwdWZyZXE9YW1kLWNwcGMiIHhlbg0KPiBjbWRs
aW5lDQo+DQo+IE9uIDIwLjA1LjIwMjUgMTA6MjgsIFBlbm55LCBaaGVuZyB3cm90ZToNCj4gPiBb
UHVibGljXQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206
IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gPj4gU2VudDogTW9uZGF5LCBNYXkg
MTksIDIwMjUgOToxOSBQTQ0KPiA+PiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQu
Y29tPg0KPiA+PiBDYzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbmRyZXcgQ29v
cGVyDQo+ID4+IDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPjsgQW50aG9ueSBQRVJBUkQNCj4g
Pj4gPGFudGhvbnkucGVyYXJkQHZhdGVzLnRlY2g+OyBPcnplbCwgTWljaGFsIDxNaWNoYWwuT3J6
ZWxAYW1kLmNvbT47DQo+ID4+IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+OyBSb2dlciBQ
YXUgTW9ubsOpDQo+ID4+IDxyb2dlci5wYXVAY2l0cml4LmNvbT47IFN0ZWZhbm8gU3RhYmVsbGlu
aSA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz47DQo+ID4+IHhlbi0gZGV2ZWxAbGlzdHMueGVucHJv
amVjdC5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NCAwNS8xNV0geGVuL3g4NjogaW50
cm9kdWNlICJjcHVmcmVxPWFtZC1jcHBjIg0KPiA+PiB4ZW4gY21kbGluZQ0KPiA+Pg0KPiA+PiBP
biAxOS4wNS4yMDI1IDEwOjM2LCBQZW5ueSwgWmhlbmcgd3JvdGU6DQo+ID4+PiBbUHVibGljXQ0K
PiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IEph
biBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gPj4+PiBTZW50OiBUdWVzZGF5LCBBcHJp
bCAyOSwgMjAyNSA4OjUyIFBNDQo+ID4+Pj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdA
YW1kLmNvbT4NCj4gPj4+PiBDYzogSHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbmRy
ZXcgQ29vcGVyDQo+ID4+Pj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBBbnRob255IFBF
UkFSRA0KPiA+Pj4+IDxhbnRob255LnBlcmFyZEB2YXRlcy50ZWNoPjsgT3J6ZWwsIE1pY2hhbCA8
TWljaGFsLk9yemVsQGFtZC5jb20+Ow0KPiA+Pj4+IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5v
cmc+OyBSb2dlciBQYXUgTW9ubsOpDQo+ID4+Pj4gPHJvZ2VyLnBhdUBjaXRyaXguY29tPjsgU3Rl
ZmFubyBTdGFiZWxsaW5pDQo+ID4+Pj4gPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+Ow0KPiA+Pj4+
IHhlbi0gZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTogW1BB
VENIIHY0IDA1LzE1XSB4ZW4veDg2OiBpbnRyb2R1Y2UgImNwdWZyZXE9YW1kLWNwcGMiDQo+ID4+
Pj4geGVuIGNtZGxpbmUNCj4gPj4+Pg0KPiA+Pj4+IE9uIDE0LjA0LjIwMjUgMDk6NDAsIFBlbm55
IFpoZW5nIHdyb3RlOg0KPiA+Pj4+PiAtLS0gYS94ZW4vaW5jbHVkZS9hY3BpL2NwdWZyZXEvcHJv
Y2Vzc29yX3BlcmYuaA0KPiA+Pj4+PiArKysgYi94ZW4vaW5jbHVkZS9hY3BpL2NwdWZyZXEvcHJv
Y2Vzc29yX3BlcmYuaA0KPiA+Pj4+PiBAQCAtNSw2ICs1LDkgQEANCj4gPj4+Pj4gICNpbmNsdWRl
IDxwdWJsaWMvc3lzY3RsLmg+DQo+ID4+Pj4+ICAjaW5jbHVkZSA8eGVuL2FjcGkuaD4NCj4gPj4+
Pj4NCj4gPj4+Pj4gKy8qIGFiaWxpdHkgYml0cyAqLw0KPiA+Pj4+PiArI2RlZmluZSBYRU5fUFJP
Q0VTU09SX1BNX0NQUEMgICA4DQo+ID4+Pj4NCj4gPj4+PiBUaGlzIG5lZWRzIGNvcnJlbGF0aW5n
IChhdCBsZWFzdCB2aWEgY29tbWVudGFyeSwgYmV0dGVyIGJ5DQo+ID4+Pj4gYnVpbGQtdGltZQ0K
PiA+Pj4+IGNoZWNraW5nKSB3aXRoIHRoZSBvdGhlciBYRU5fUFJPQ0VTU09SX1BNXyogdmFsdWVz
LiBPdGhlcndpc2UNCj4gPj4gc29tZW9uZQ0KPiA+Pj4+IGFkZGluZyBhIG5ldyAjZGVmaW5lIGlu
IHRoZSBwdWJsaWMgaGVhZGVyIG1heSBub3QgKGVhc2lseSkgbm90aWNlIGENCj4gPj4+PiBwb3Nz
aWJsZSBjb25mbGljdC4gV2l0aCB0aGF0IGluIG1pbmQgSSBhbHNvIHF1ZXN0aW9uIHdoZXRoZXIg
OCBpcw0KPiA+Pj4+IGFjdHVhbGx5IGEgZ29vZCBjaG9pY2U6IFRoYXQncyB0aGUgb2J2aW91cyBu
ZXh0IHZhbHVlIHRvIHVzZSBpbiB0aGUNCj4gPj4+PiBwdWJsaWMgaW50ZXJmYWNlLiBTSUZfUE1f
TUFTSyBpcyA4IGJpdHMgd2lkZSwgc28gYSBzZW5zaWJsZSB2YWx1ZQ0KPiA+Pj4+IHRvIHVzZSBo
ZXJlDQo+ID4+IHdvdWxkIGJ5IGUuZy4gMHgxMDAuDQo+ID4+Pj4NCj4gPj4+DQo+ID4+PiBJJ3Zl
IGFkZGVkIGEgcHVibGljIGZsYWcgYW5jaG9yICJYRU5fUFJPQ0VTU09SX1BNX1BVQkxJQ19FTkQi
IGluDQo+ID4+IHB1YmxpYyBoZWFkZXI6DQo+ID4+PiAgICAgICAgICAjZGVmaW5lIFhFTl9QUk9D
RVNTT1JfUE1fUFVCTElDX0VORA0KPiA+PiBYRU5fUFJPQ0VTU09SX1BNX1RYDQo+ID4+PiBhbmQg
d2lsbCBkbyB0aGUgZm9sbG93aW5nIGJ1aWxkLXRpbWUgY2hlY2tpbmc6DQo+ID4+PiAgICAgICAg
IEJVSUxEX0JVR19PTihYRU5fUFJPQ0VTU09SX1BNX0NQUEMgPD0NCj4gPj4+IFhFTl9QUk9DRVNT
T1JfUE1fUFVCTElDX0VORCk7DQo+ID4+DQo+ID4+IEkgZG9uJ3QgcmVhbGx5IHNlZSB3aHkgYW55
dGhpbmcgd291bGQgbmVlZCB0byBiZSBhZGRlZCB0byB0aGUgcHVibGljDQo+ID4+IGhlYWRlciAo
YW5kIHdlIHJlYWxseSBzaG91bGQgc3RyaXZlIHRvIGF2b2lkIHVubmVjZXNzYXJ5IGFkZGl0aW9u
cykuDQo+ID4NCj4gPiBJZiBJIHB1dCBzdWNoIGRlZmluaXRpb24NCj4gPiAiI2RlZmluZSBYRU5f
UFJPQ0VTU09SX1BNX1BVQkxJQ19FTkQgWEVOX1BST0NFU1NPUl9QTV9UWCINCj4gPiBpbiBpbnRl
cm5hbCBoZWFkZXIsIEknbSBhZnJhaWQgaXQgd29uJ3QgYmUgdXBkYXRlZCBpZiBuZXcgb25lcyBh
ZGRlZCBpbiB0aGUgcHVibGljIGluDQo+IHRoZSBmdXR1cmUuDQo+ID4gT3IgYW55IG90aGVyIHN1
Z2dlc3Rpb25zIHRvIHByb3ZpZGUgYnVpbGQtdGltZSBjaGVja2luZz8NCj4NCj4gSW1vIGl0J3Mg
c3VmZmljaWVudCB0byBjaGVjayB0aGF0IHRoZSBuZXcgI2RlZmluZSBkb2Vzbid0IG92ZXJsYXAg
d2l0aA0KPiBTSUZfUE1fTUFTSy4NCg0KVW5kZXJzdG9vZCENCg0KPg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Tue May 20 09:43:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 09:43:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990614.1374556 (Exim 4.92)
	(envelope-from )
	id 1uHJVo-0004Vj-Ky; Tue, 20 May 2025 09:43:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990614.1374556; Tue, 20 May 2025 09:43: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 1uHJVo-0004Vc-Gr; Tue, 20 May 2025 09:43:52 +0000
Received: by outflank-mailman (input) for mailman id 990614;
 Tue, 20 May 2025 09:43:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHJVm-0004VU-RM
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 09:43:50 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eed597e5-355e-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 11:43:50 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad5533c468cso416482966b.0
 for ; Tue, 20 May 2025 02:43:49 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 a640c23a62f3a-ad52d438279sm694963366b.112.2025.05.20.02.43.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 02:43:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: eed597e5-355e-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747734229; x=1748339029; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Nut/XAOkRnbpYt8eQOiWPhM34TBKF50Z6wETkr6wZ6I=;
        b=uMt1wSx8R0DejzhaavHyu4u++MEXu6lDeksqXFMzeEmXO528EVJP7qxKEZWddSzf97
         wqO5S79qHe/FTCSb3MKmHfBrB/5HVH6Vy4c0ynsD346OCM2tJYxGpzgU32/sA47CmjGv
         GZqGZx0uokRRQAmxPHgoukrwvEV9VZMN8pm1c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747734229; x=1748339029;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Nut/XAOkRnbpYt8eQOiWPhM34TBKF50Z6wETkr6wZ6I=;
        b=QHIvqDiSwTAGCbz4Vx7oHB1yTy03aZMx2+jB3/3wk15dMQbvPOeSoWs7tDFotLR0sa
         5g45b3naZzJ3y+Ieuar5jlHRDRsChze5F203WmDpUrOxwKkoQir2lvj5D44zTg37rJ0a
         /eigYSP3PeDcVorA3KmHHnIEat5oYHa8SY4lxn1LxIgwajfciUBVVEiWbVclQYOjFSpo
         /NGD9iwVuFfb0QoUvlwCa8++ACToTZ+PynrO7r9wd4IhoppRuckc9zfQy5kdtrUf66J3
         qW1CwVEZiMDZE2hI7HZqwBq/kuiO9wKe/o2Od/Q+a8KAGmKYX10xmr4wwOkqFK5iIvHN
         ya7Q==
X-Forwarded-Encrypted: i=1; AJvYcCXHNxoMiWwI+w4kpgknMWnMQ6GkDeouDkR5ooBOob9WBHO7wDB75yluAsnzLZK021oDf2GZ/i30SpM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzUFCFmuMJLhsfVP39WrfYZMIoxxqjaiKm4pyz8p/DHa/TI3vnf
	ycIpZl71MUs3KdeScq87sJoN0Zocl62TxD7k7/blTR9NflDChnA2aC7LFdDws/9aSMk=
X-Gm-Gg: ASbGncttPZSZ3clxm+4QyfpJ4ovGUD4by6hQKanPsnr6Ig5Tof7ue8P9GZgFXrUpdC0
	CRoVyBWiuLQEatXs0JcVPOYM26Gg0rDpaOsVXw5GKlT/lldrMRFtyWmJFekLW7//F9lGpt4ytUo
	352o9CXbNo3ZQAG4gD8mwQ95JUkTD3PaofTq5hKcf94602dOYIt6/D2FbgHJfidiIHJX8b3ClrE
	wfGR/PYMQl2Zq9Kw9+O7t2rv6sZ14V7mKyF3Hk6pdlKLdDHAXcU82vc6J+ejC5rbXOh/U87wsC7
	pQfypGe1cKFOyZBYMzw/fYpEFnVIS31LHuTaUwUZ51zg4+WeUQOaLGLuuaH/+RBX2usyoOCGyMT
	h1XkJQejVubmEABZGI33z3DDoKEO8rQ==
X-Google-Smtp-Source: AGHT+IG7sTx/TOMxTOjY5WNfUXjd+PWtSvkC72x+8yGuicaTFETKZbnD//YLNzA6zR+lbacm6FoWkw==
X-Received: by 2002:a17:906:c156:b0:ad2:51d8:7931 with SMTP id a640c23a62f3a-ad536bde70emr1274134366b.21.1747734229290;
        Tue, 20 May 2025 02:43:49 -0700 (PDT)
Date: Tue, 20 May 2025 11:43:48 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Jiqian Chen , Huang Rui ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Message-ID: 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-10-Jiqian.Chen@amd.com>
 <8d89f644-4ded-4490-ad23-518563d230d2@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, May 20, 2025 at 11:14:27AM +0200, Jan Beulich wrote:
> On 20.05.2025 11:09, Roger Pau Monné wrote:
> > On Tue, May 20, 2025 at 08:40:28AM +0200, Jan Beulich wrote:
> >> On 09.05.2025 11:05, Jiqian Chen wrote:
> >>> When init_msi() fails, the previous new changes will hide MSI
> >>> capability, it can't rely on vpci_deassign_device() to remove
> >>> all MSI related resources anymore, those resources must be
> >>> removed in cleanup function of MSI.
> >>
> >> That's because vpci_deassign_device() simply isn't called anymore?
> >> Could do with wording along these lines then. But (also applicable
> >> to the previous patch) - doesn't this need to come earlier? And is
> >> it sufficient to simply remove the register intercepts? Don't you
> >> need to put in place ones dropping all writes and making all reads
> >> return either 0 or ~0 (covering in particular Dom0, while for DomU-s
> >> this may already be the case by default behavior)?
> > 
> > For domUs this is already the default behavior.
> > 
> > For dom0 I think it should be enough to hide the capability from the
> > linked list, but not hide all the capability related
> > registers.  IMO a well behaved dom0 won't try to access capabilities
> > disconnected from the linked list,
> 
> Just that I've seen drivers knowing where their device has certain
> capabilities, thus not bothering to look up the respective
> capability.

OK, so let's make the control register read-only in case of failure.

If MSI(-X) is already enabled we should also make the entries
read-only, and while that's not very complicated for MSI, it does get
more convoluted for MSI-X.  I'm fine with just making the control
register read-only for the time being.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 20 10:44:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 10:44:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990627.1374564 (Exim 4.92)
	(envelope-from )
	id 1uHKRw-0004Gs-Sh; Tue, 20 May 2025 10:43:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990627.1374564; Tue, 20 May 2025 10:43:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHKRw-0004Gl-Px; Tue, 20 May 2025 10:43:56 +0000
Received: by outflank-mailman (input) for mailman id 990627;
 Tue, 20 May 2025 10:43:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHKRv-0004Gf-Ps
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 10:43:55 +0000
Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com
 [2001:4860:4864:20::2a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 50b554f7-3567-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 12:43:50 +0200 (CEST)
Received: by mail-oa1-x2a.google.com with SMTP id
 586e51a60fabf-2d4f8c42f49so2234393fac.1
 for ; Tue, 20 May 2025 03:43: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" 
X-Inumbo-ID: 50b554f7-3567-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747737829; x=1748342629; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5uaftpOpgrsIuQy4iUAfyMgweupj/IjoBcEDbSzXkPo=;
        b=b+NyJiaMLJfXOJ9WzTXH3uwNnvL5kVkJfaKiHsazCIyDHdx//LznnKBOLB17aa4yU+
         gcI986bbXx98+qnSb2F70ZCflXKocAdzqAaHhAoUIbTIRvFOaA5fRxZJv0fyOEQPK8nj
         Jy62+91YzcgnlBbidl2CFs6reh0sOb1hJjM6M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747737829; x=1748342629;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=5uaftpOpgrsIuQy4iUAfyMgweupj/IjoBcEDbSzXkPo=;
        b=FEQ+5zhxghZhiupg4PHbyEHEN0iR7Y9t/FS/PMf1zr2xIgOccoJiVnRwUWCWwbIx8H
         LlHtk14YGocoHNUFpAgp2PhCjPampbA1mFkcsYo4OvY8tc2HJoOfWjsaG0VmB3qrew8J
         1ZXHBnfAuHioFbaNQe5C/5ezYvk5BIj6WjSaKqHftEFldgwayHmbHCb5t3WBUhn/IwXA
         cO8B3zd5MEtuXJ0+e03oUIj+P4yyWxQw5M0ftMwD5prL0J84N/hDDqdVIH0R9lpdXYaM
         8fdg5zvm8im/i7xFEQGlWwZQzpw2WT+LkgfdsxdHvfULMhVlCFSbdXIER+dVVX24lG1E
         xr5A==
X-Gm-Message-State: AOJu0Ywqudxb+OFlGsNZjiGCL0YqCyjWY8L/IupZFu6qt++wiNISl0uv
	+bOwpdz2ol+t8zlSdHSR5xw/XfxwkQbU+UxnXn8xdLcHdEwpW6Lk35HFfKatkkylQkF0ulqSMt0
	h+RYSZfcPy2TtqKur7bFwl/xF77fR605wRXufMtv81g==
X-Gm-Gg: ASbGncvlUAgDw6xufCStuVUCXa8Zkpfcbpg8qdWu0b73AVzl8f0DoAaW9+UM/GQFwwp
	W4rsSbP8CY4up6uvi1btPVynWdYdkwLDfdTO//7xrA9HeXRAM8XTyo1loZrXz0rRASuECshjbv6
	kkb7XS0DepiMnbt/TsR3tToWnhF6ucrr6UG3vE0r6EkA==
X-Google-Smtp-Source: AGHT+IEwvPmgfvu29BWKNSBcnNDdzXnc3zNqQ435MZmgeN1kwzg3Isiw7XNtmmjK9lMkI11uPA3btHxq4X6dJFw+HZw=
X-Received: by 2002:a05:6870:ef84:b0:2d4:e101:13f1 with SMTP id
 586e51a60fabf-2e3c2a988d6mr9554270fac.13.1747737829425; Tue, 20 May 2025
 03:43:49 -0700 (PDT)
MIME-Version: 1.0
References: <20250519135227.27386-1-andrew.cooper3@citrix.com>
In-Reply-To: <20250519135227.27386-1-andrew.cooper3@citrix.com>
From: Frediano Ziglio 
Date: Tue, 20 May 2025 11:43:38 +0100
X-Gm-Features: AX0GCFtXgJw3il85Z0HktJWEvteU044WjO75y82oTWFjESGgTNteCBCC34zUN-4
Message-ID: 
Subject: Re: [PATCH] xen: Give compile.h header guards
To: Andrew Cooper 
Cc: Xen-devel , 
	Anthony PERARD , Michal Orzel , 
	Jan Beulich , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 19, 2025 at 2:52=E2=80=AFPM Andrew Cooper  wrote:
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Anthony PERARD 
> CC: Michal Orzel 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Roger Pau Monn=C3=A9 
> CC: Stefano Stabellini 
> ---
>  xen/include/xen/compile.h.in | 3 +++
>  xen/tools/process-banner.sed | 5 +++++
>  2 files changed, 8 insertions(+)
>
> diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
> index 3151d1e7d1bf..9206341ba692 100644
> --- a/xen/include/xen/compile.h.in
> +++ b/xen/include/xen/compile.h.in
> @@ -1,3 +1,6 @@
> +#ifndef XEN_COMPILE_H
> +#define XEN_COMPILE_H
> +

Why not follow CODING_STYLE ?

OT: Maybe while on it, why not add SPDX comments too ?

>  #define XEN_COMPILE_DATE       "@@date@@"
>  #define XEN_COMPILE_TIME       "@@time@@"
>  #define XEN_COMPILE_BY         "@@whoami@@"
> diff --git a/xen/tools/process-banner.sed b/xen/tools/process-banner.sed
> index 56c76558bcd9..4cf3f9a1163a 100755
> --- a/xen/tools/process-banner.sed
> +++ b/xen/tools/process-banner.sed
> @@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
>
>  # Trailing \ on all but the final line.
>  $!s_$_ \\_
> +
> +# Append closing header guard
> +$a\
> +\
> +#endif /* XEN_COMPILE_H */
>
> base-commit: 6fc02ebdd053856221f37ba5306232ac1575332d
> prerequisite-patch-id: 7bc1c498ba2c9c4a4939a56a0006f820f47f2a66
> --
> 2.39.5
>
>
Frediano


From xen-devel-bounces@lists.xenproject.org Tue May 20 10:54:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 10:54:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990639.1374574 (Exim 4.92)
	(envelope-from )
	id 1uHKbm-0005w1-Q1; Tue, 20 May 2025 10:54:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990639.1374574; Tue, 20 May 2025 10: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 1uHKbm-0005vu-NP; Tue, 20 May 2025 10:54:06 +0000
Received: by outflank-mailman (input) for mailman id 990639;
 Tue, 20 May 2025 10:54:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHKbl-0005vo-QE
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 10:54:05 +0000
Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com
 [2607:f8b0:4864:20::c2f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bddd5681-3568-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 12:54:03 +0200 (CEST)
Received: by mail-oo1-xc2f.google.com with SMTP id
 006d021491bc7-601ad30bc0cso4527703eaf.0
 for ; Tue, 20 May 2025 03:54:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: bddd5681-3568-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747738442; x=1748343242; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=xGVwrBMgdBsxlnizpiLyvWOkFnjHtdjObKHW6G+TjR4=;
        b=AYxyVNcaIQxOokA7O7Ve4KBZOAO1pOL0FrYwMCd1NQTNmE8BH837Rx8cCN8/4NMqO7
         aHvo23fn40Ch/erKWIsJWmctdVz4na4hCMX5Xj6avKBydaDFHC7/mqaurKg+1MuDSkWw
         vGTSk6QkoNRyc72fY99kySDGy1r2MZvEy4KFg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747738442; x=1748343242;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=xGVwrBMgdBsxlnizpiLyvWOkFnjHtdjObKHW6G+TjR4=;
        b=diM3KVc702wFC3x+KTkNuApzsLsteS15PfGmAv3AyObudd16B+6yk2osKD45IhOM1K
         Sr2aTWZRf22Enhi6RjqFHSxHPGLud2pjd+qkjvt0tfuQqRbZ0uAFKROw1szrJ1m8x4pA
         OLkAUPR/QxwPXzB/owERz3WmbazqeFbcVpenvxZO0usljonXuimdi2vh32ou0t43PP15
         aatHb2T1RcHbRFqNjfWQGjwzRKF6VqEvRu3ZXer94nIxk+3cu9nA4qPEfV0XQpBbN/+N
         2rIfhxdqDvZ5J0i8GSfWNIQhZwEjMyIjh/ztTsa9j4rl5OhuBgDMsZPVITKVM+Kwi4cF
         nlXw==
X-Gm-Message-State: AOJu0YxDBpRfNzdmoy0apzKk6HrEijtwKL6zAHnqNGNWMf/nO+4OPqkj
	hj8TVaR5dYuQoZZMoglEnTATxymttLF43TJa34u5U5YaLQ7i8dyPyYVRynhD954KEGYEDFGotvo
	/VMzm1kcsBGSqpdrwcqG5bGP7atEOmz8NmXaOTzZMgW5yLMSkKkvoNg==
X-Gm-Gg: ASbGncvB+tocPMlGGXXS5PCHiOrq5CMqGnfF4aMJfwbk8rj1Q+GEcvT2SH2TJulf+8h
	NiC7f5Cz1aJg1YCEEzjBOPFMJfkcq5nLIWNC/7JLUf1k2XoeI9SQ0QEr3rG9jBfym4Wze3Z67GV
	wBmyP3W+kaXJL5aN+eTLK23xGtDoZBo8w=
X-Google-Smtp-Source: AGHT+IFuQOj3S3pNtduZiarIFmLlJlJ1KXTXmEGZzD637yphG81T/AackFlkcxXZEcds3x0fZcdi08ZDHc7Hm+3ZSQI=
X-Received: by 2002:a4a:ec43:0:b0:603:f809:ce19 with SMTP id
 006d021491bc7-609f38b5d20mr8515684eaf.3.1747738442026; Tue, 20 May 2025
 03:54:02 -0700 (PDT)
MIME-Version: 1.0
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
 <20250512144656.314925-2-ross.lagerwall@citrix.com> <204e177c-beba-41a1-93bf-3ae6454875cc@suse.com>
In-Reply-To: <204e177c-beba-41a1-93bf-3ae6454875cc@suse.com>
From: Ross Lagerwall 
Date: Tue, 20 May 2025 11:53:51 +0100
X-Gm-Features: AX0GCFtrwzoYOnZoUGt8Lfv8goLG49nSFPprLdbqQR1YewUINpoSBO_ypMvy_lE
Message-ID: 
Subject: Re: [PATCH v2 1/5] x86/pmstat: Check size of PMSTAT_get_pxstat buffers
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 13, 2025 at 3:27=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 12.05.2025 16:46, Ross Lagerwall wrote:
> > Check that the total number of states passed in and hence the size of
> > buffers is sufficient to avoid writing more than the caller has
> > allocated.
> >
> > The interface is not explicit about whether getpx.total is expected to
> > be set by the caller in this case but since it is always set in
> > libxenctrl it seems reasonable to check it.
>
> Yet if we start checking the value, I think the public header should also
> be made say so (in a comment).
>
> > --- a/xen/drivers/acpi/pmstat.c
> > +++ b/xen/drivers/acpi/pmstat.c
> > @@ -103,8 +103,10 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *o=
p)
> >
> >          cpufreq_residency_update(op->cpuid, pxpt->u.cur);
> >
> > -        ct =3D pmpt->perf.state_count;
> > -        if ( copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct*=
ct) )
> > +        ct =3D min_t(uint32_t, pmpt->perf.state_count, op->u.getpx.tot=
al);
>
> With this, ...
>
> > +        if ( ct <=3D op->u.getpx.total &&
>
> ... this is going to be always true, isn't it? Which constitutes a violat=
ion
> of Misra rule 14.3.
>
> Also it would be nice if the min_t() could become a normal min(), e.g. by
> "promoting" op->u.getpx.total to unsigned int via adding 0U. This way it'=
s
> clear there's no hidden truncation (or else there might be an argument fo=
r
> keeping the check above).
>
> > +             copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct =
* ct) )
> >          {
> >              spin_unlock(cpufreq_statistic_lock);
> >              ret =3D -EFAULT;
>
> Why would you constrain this copy-out but not the one just out of context
> below here? (The question is of course moot if the condition was dropped.=
)
>

Oh, I had intended this condition to be...

    if ( ct =3D=3D op->u.getpx.total &&

... based on your previous comment about the difficulties of partially
copying a 2d array.

> An option may be to document that this array is copied only when the
> buffer is large enough.

I left the other alone since partially copying a 1d array makes sense.

If you would prefer, I can drop the condition and just let the caller
deal with the partially copied 2d array?

Thanks,
Ross


From xen-devel-bounces@lists.xenproject.org Tue May 20 11:24:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 11:24:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990650.1374584 (Exim 4.92)
	(envelope-from )
	id 1uHL59-0001Np-Ut; Tue, 20 May 2025 11:24:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990650.1374584; Tue, 20 May 2025 11:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHL59-0001Ni-SO; Tue, 20 May 2025 11:24:27 +0000
Received: by outflank-mailman (input) for mailman id 990650;
 Tue, 20 May 2025 11:24:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHL58-0001Nc-BY
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 11:24:26 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fb8258eb-356c-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 13:24:24 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-acacb8743a7so910838966b.1
 for ; Tue, 20 May 2025 04:24:24 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d498bdcsm723964166b.145.2025.05.20.04.24.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 04:24: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" 
X-Inumbo-ID: fb8258eb-356c-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747740264; x=1748345064; darn=lists.xenproject.org;
        h=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;
        bh=p5WkFV7gQKE7SnY5xtWN/tVTShcjVe3lU294m5RPPUM=;
        b=HMIeVb8Q4T691UL4af02ZUlOGZdb14z9HVHgPPz85ldViC2VFJxXEx6QvvHaoGn3qg
         uDx2GJo9snR0phHf1aVEdTfjs0p4oKCeGRC2lddAgwKs88bN6NR4zDPDAoGlOCF/NNxR
         tZqgNwiZGCrfVj+zGc41gk7TG5jeUTZ2SMkAB7yay8rVQhdujtP4UNlv3DPz9kIgQqNS
         6G6CC8rE9IlUhQlADSo1M6DxcYn/f54Btp9kSvE0Ntti2v74ruCwyZWybmMEyYxPQKep
         8+OyeVseqnnHhC+fx8/U7xQyhjxefrefqYnc9NEdP3dhvxZwLf1pfPdk7PJQe+WncdhU
         2kaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747740264; x=1748345064;
        h=in-reply-to:content-language:references:cc:to:subject:from
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=p5WkFV7gQKE7SnY5xtWN/tVTShcjVe3lU294m5RPPUM=;
        b=MqPfTxeO7mQsSqWFHlkne/p+galEavcSGftEzAxaKCK4czbFI9nOUnA7+rivuYkSRe
         4XFFQYrkKkvaUg02XIpdkzzuvhBt6XyIOORugd18SB/uLbf77809M3beBpCCaD/wYqnR
         a4WBHFm4nX21A1zmQe4z/UWMmoKUIncaNWMZXZ2Y06UFxgFYiTOjGbYQExzJNFP66I6b
         8toRfGQTg1+Tu9gGmke0GmDnUcEQKrzbb/hDhmMRKuaNvx7GYGje5xS07o+tVSs4ssAc
         9WfUpe9UxBU6Q/dq2gL64pYndsTqr6VAx/GHsRbLz56xIVO/3HnA1fO1F3xURbjFaCGL
         S5Ig==
X-Forwarded-Encrypted: i=1; AJvYcCUi7E79cpsA3qdpn0A9DxoEIu/YBC2UDUQhtG1zJw/o+n+mYZtkOg/Ll98f2y+3Yo2MpUoDaWJA5ZA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxI+J0dCEWvmCCMoUiFb8JC+W/Ufqc2c+lsVW07n72527HqUGBi
	onq1UdCp5eZdd4WcaPqkKr4fw57umEkHjGZZQQ904iPznvM+h3H2EjeB
X-Gm-Gg: ASbGncsUTeOnxMHqbX2VWOoDO98bJNIkE/+BA7Afd4iVGcGgamZ4bkJPm72lJISM8xh
	is36zPkvofLqw8iEiuVEL6+3qz1/DJp6FisWrFLJywZAwFDm4xbO/PAfZGgMrOD9zsDkQvh47kc
	iPKMSVyv6ci+WL2sx3qVbV7B9bldPbJb7BsXuqwz5CbnCx0CNr4kHAGWtcSY4CCpW4oEeOFZLx6
	kXZLqy9sPIZ2xoYRp5oU7D60SaEcY/qD1241TPtO/3R7C6FJTf6E+oF9vanG/R10GcuotCg+i7/
	FFNoK1Xgt+/5DlZdR40k7Rdk2viLQrBiuE2h3mOuW6rJAhgNVEkX/l0UJrgYFWJMXc2a/wQw6Yu
	/LzllSduinsTFsPZW/D0icp30
X-Google-Smtp-Source: AGHT+IGconidpi61EM1K21vFYjyKCvYVd66AyyQbuAXSHBdRAGYZn8jXqxqjgKCLEq4692a+h1q0aA==
X-Received: by 2002:a17:906:c105:b0:ad5:74cd:1813 with SMTP id a640c23a62f3a-ad574cd1daemr571103666b.9.1747740263280;
        Tue, 20 May 2025 04:24:23 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------VxayjQKBwJIkrf4DTCwCgXez"
Message-ID: <14af72c4-56dd-4a50-978c-305de81373cd@gmail.com>
Date: Tue, 20 May 2025 13:24:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko 
Subject: Re: [PATCH v2 13/16] xen/riscv: implementation of aplic and imsic
 operations
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <37d309520a0adb8bb3f4e51a985a2d56b669ba9e.1746530883.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
In-Reply-To: 

This is a multi-part message in MIME format.
--------------VxayjQKBwJIkrf4DTCwCgXez
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/15/25 11:44 AM, Jan Beulich wrote:
>> @@ -159,6 +270,8 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
>>   
>>       dt_irq_xlate = aplic_irq_xlate;
>>   
>> +    spin_lock_init(&aplic.lock);
> Can't you have the struct field have a suitable initializer?

Sure, I will use struct initializer:
   static struct aplic_priv aplic = {
       .lock = SPIN_LOCK_UNLOCKED,
   };

>> +static void imsic_local_eix_update(unsigned long base_id, unsigned long num_id,
>> +                                   bool pend, bool val)
>> +{
>> +    unsigned long id = base_id, last_id = base_id + num_id;
>> +
>> +    while ( id < last_id )
>> +    {
>> +        unsigned long isel, ireg;
>> +        unsigned long start_id = id & (__riscv_xlen - 1);
>> +        unsigned long chunk = __riscv_xlen - start_id;
>> +        unsigned long count = (last_id - id < chunk) ? last_id - id : chunk;
>> +
>> +        isel = id / __riscv_xlen;
>> +        isel *= __riscv_xlen / IMSIC_EIPx_BITS;
>> +        isel += pend ? IMSIC_EIP0 : IMSIC_EIE0;
>> +
>> +        ireg = GENMASK(start_id + count - 1, start_id);
>> +
>> +        id += count;
>> +
>> +        if ( val )
>> +            imsic_csr_set(isel, ireg);
>> +        else
>> +            imsic_csr_clear(isel, ireg);
>> +    }
>> +}
>> +
>> +void imsic_irq_enable(unsigned int irq)
>> +{
>> +    unsigned long flags;
>> +
>> +    spin_lock_irqsave(&imsic_cfg.lock, flags);
>> +    /*
>> +     * There is no irq - 1 here (look at aplic_set_irq_type()) because:
>> +     * From the spec:
>> +     *   When an interrupt file supports distinct interrupt identities,
>> +     *   valid identity numbers are between 1 and inclusive. The identity
>> +     *   numbers within this range are said to be implemented by the interrupt
>> +     *   file; numbers outside this range are not implemented. The number zero
>> +     *   is never a valid interrupt identity.
>> +     *   ...
>> +     *   Bit positions in a valid eiek register that don’t correspond to a
>> +     *   supported interrupt identity (such as bit 0 of eie0) are read-only zeros.
>> +     *
>> +     * So in EIx registers interrupt i corresponds to bit i in comparison wiht
>> +     * APLIC's sourcecfg which starts from 0. (l)
> What's this 'l' in parentheses here to indicate?

I don't really remember, it seems like I want to point to the spec, but
then just make a quote from the spec instead. I'll just drop it.

>> +     */
>> +    imsic_local_eix_update(irq, 1, false, true);
>> +    spin_unlock_irqrestore(&imsic_cfg.lock, flags);
>> +}
>> +
>> +void imsic_irq_disable(unsigned int irq)
>> +{
>> +    unsigned long flags;
>> +
>> +    spin_lock_irqsave(&imsic_cfg.lock, flags);
>> +    imsic_local_eix_update(irq, 1, false, false);
>> +    spin_unlock_irqrestore(&imsic_cfg.lock, flags);
>> +}
> The sole caller of the function has doubly turned off IRQs already; perhaps
> no need to it a 3rd time, unless other callers are to appear? Same for
> imsic_irq_enable() as it looks.

I checked a code in private branches and it seems like these functions are called
only in aplic_irq_{enable,disable}(), so we could do, at least,spin_lock(&imsic_cfg.lock)
+ ASSERT(!local_irq_is_enabled());

~ Oleksii


--------------VxayjQKBwJIkrf4DTCwCgXez
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 11:44 AM, Jan Beulich wrote:
    
    
    
      
    
        
    @@ -159,6 +270,8 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     dt_irq_xlate = aplic_irq_xlate;
 
+    spin_lock_init(&aplic.lock);

    
      
    
      
    Can't you have the struct field have a suitable initializer?
    
    
    
    
    Sure, I will use struct initializer:
  static struct aplic_priv aplic = {
      .lock = SPIN_LOCK_UNLOCKED,
  };


    
    
    
      
    
        
    +static void imsic_local_eix_update(unsigned long base_id, unsigned long num_id,
+                                   bool pend, bool val)
+{
+    unsigned long id = base_id, last_id = base_id + num_id;
+
+    while ( id < last_id )
+    {
+        unsigned long isel, ireg;
+        unsigned long start_id = id & (__riscv_xlen - 1);
+        unsigned long chunk = __riscv_xlen - start_id;
+        unsigned long count = (last_id - id < chunk) ? last_id - id : chunk;
+
+        isel = id / __riscv_xlen;
+        isel *= __riscv_xlen / IMSIC_EIPx_BITS;
+        isel += pend ? IMSIC_EIP0 : IMSIC_EIE0;
+
+        ireg = GENMASK(start_id + count - 1, start_id);
+
+        id += count;
+
+        if ( val )
+            imsic_csr_set(isel, ireg);
+        else
+            imsic_csr_clear(isel, ireg);
+    }
+}
+
+void imsic_irq_enable(unsigned int irq)
+{
+    unsigned long flags;
+
+    spin_lock_irqsave(&imsic_cfg.lock, flags);
+    /*
+     * There is no irq - 1 here (look at aplic_set_irq_type()) because:
+     * From the spec:
+     *   When an interrupt file supports distinct interrupt identities,
+     *   valid identity numbers are between 1 and inclusive. The identity
+     *   numbers within this range are said to be implemented by the interrupt
+     *   file; numbers outside this range are not implemented. The number zero
+     *   is never a valid interrupt identity.
+     *   ...
+     *   Bit positions in a valid eiek register that don’t correspond to a
+     *   supported interrupt identity (such as bit 0 of eie0) are read-only zeros.
+     *
+     * So in EIx registers interrupt i corresponds to bit i in comparison wiht
+     * APLIC's sourcecfg which starts from 0. (l)

    
      
    
      
    What's this 'l' in parentheses here to indicate?
    
    
    
    
    I don't really remember, it seems like I want to point to the spec, but
then just make a quote from the spec instead. I'll just drop it.


    
    
    
      
    
        
    +     */
+    imsic_local_eix_update(irq, 1, false, true);
+    spin_unlock_irqrestore(&imsic_cfg.lock, flags);
+}
+
+void imsic_irq_disable(unsigned int irq)
+{
+    unsigned long flags;
+
+    spin_lock_irqsave(&imsic_cfg.lock, flags);
+    imsic_local_eix_update(irq, 1, false, false);
+    spin_unlock_irqrestore(&imsic_cfg.lock, flags);
+}

    
      
    
      
    The sole caller of the function has doubly turned off IRQs already; perhaps
no need to it a 3rd time, unless other callers are to appear? Same for
imsic_irq_enable() as it looks.
    
    
    
    
    I checked a code in private branches and it seems like these functions are called
only in aplic_irq_{enable,disable}(), so we could do, at least,spin_lock(&imsic_cfg.lock)
+ ASSERT(!local_irq_is_enabled());

~ Oleksii
    
    
    
  


--------------VxayjQKBwJIkrf4DTCwCgXez--


From xen-devel-bounces@lists.xenproject.org Tue May 20 11:37:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 11:37:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990662.1374595 (Exim 4.92)
	(envelope-from )
	id 1uHLI8-00037b-5y; Tue, 20 May 2025 11:37:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990662.1374595; Tue, 20 May 2025 11:37: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 1uHLI8-00037U-2C; Tue, 20 May 2025 11:37:52 +0000
Received: by outflank-mailman (input) for mailman id 990662;
 Tue, 20 May 2025 11:37:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHLI6-00037O-Rc
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 11:37:50 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id db0b0908-356e-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 13:37:48 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ad574992fcaso347671066b.1
 for ; Tue, 20 May 2025 04:37:48 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad534ad59dasm682961566b.31.2025.05.20.04.37.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 04:37:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: db0b0908-356e-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747741068; x=1748345868; darn=lists.xenproject.org;
        h=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;
        bh=cNe/Fdb8PGYy3I9kFDJYzbm8nvTAawrSVm3/nUL5ym0=;
        b=ZqUn6Eo9X5Y86QXVXdMhQM7Uf6nbyNuPNMAwzWegyFS3uQBuOIjqRh8z5w0AgK6syS
         tzNANLrbIS0GzfBxNWUhr1ikch1EnhL/Mhivnaz1nSQqfSraE+0XyDI8lsXg5M2z4B+u
         lfyr3/gpykHMdCDG0ea0XCexaPLa8YjUv+AIhMg+V0QfgWoVQfGs6Uxl5v1w3XoG8/bh
         GIR2zwz1+0niykQ+W9OiEFaqEcM5zpLoRUUjPMMidn1aJ+JH4oY2ekwe788JojTx5W/+
         P4miUVVrvjdSrFFZzN3PgDTMNMtiWr0nxk5MxB+ta657qUXhL9hwTu2pPooFGgE9GcHH
         KbXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747741068; x=1748345868;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=cNe/Fdb8PGYy3I9kFDJYzbm8nvTAawrSVm3/nUL5ym0=;
        b=PzZcZ0yS+ultTtxo21VV8LSR5Hx9AU5hOrCUVg058yooEevWCZ/UMhNmZ2DXgA6I3l
         babV4hg/6wmQ+7vtKg7D+D33P9BVaA6uOmnglT3BZBinXPWC9Z8BFULEKh1Tx32TLzpD
         lastLuaKIYPJhCrGn/5PeMVoq6YQmho2jy3ELBfAGubuPACO83bki3wRvifLwnfyON+X
         37V4L1dCps1OMLSvfjN/bO/PCqkJEzi3ydnqLj+U2UwOl0uA1Py7so7ujktz3/7VZb4g
         uu4SBaAPEXs1X3xdHsmpfonDeNoAE0hctYWc4SDyRROOoidIPaJlpa+PvxKPq5M6paO3
         YqZA==
X-Forwarded-Encrypted: i=1; AJvYcCWt9m6VxBqyMVXI8EQo2ObYU1S76i5kgb5xO+g1KVWzP74gXF8bridYZVHWf8Z3e6qtoG2hvwFUL4A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw3exqydoCbgXA/bUUAFjp4eVfPi9UiRK4zY4QXm9prL/IzQuoH
	GBl6klo9B+LZSOji57qQL2CbtwBLAeLiTSj5p7/trTkl6XrxiZ5SPFYX
X-Gm-Gg: ASbGncsvRqk18wV16guQdXvrpch35lNfO40BrBow1OrR86Al0o0GNRrLrYSydm5abJY
	qDX2SBG5cVirFR/ae4JI/cEazj6cNVGwAzUmXvVN3aAMKuJuKXS5GBdCK+qpoJXdfB+RDbIvoXE
	iZp7OTJvPqt8dqjCYKFq3HqayFlBOP/GIeS7UlkGkuT97/oEC8UO8XRqJ9fvAdU1yJSAMYJYIv6
	k2JG/Ws743g/tdzwQ94wN6hAuoIebikRjhOWRu2jJV0OJkJ0JpOoQkaErVGhXeJntMoRpMuhPse
	SRN9K9M8tCXtLMygI2x2DsETMWPa48zmEriFVwE3HxR+hmd4SOFZ8zWRo31V5nmm9Jip2ezccvH
	nWKtRJIZDyM2FWXzQJ1VKTxVR
X-Google-Smtp-Source: AGHT+IE/St+FkE95V27zPOdtNnbkkPwKcrxcZZ5vJBzCOzCd1drpaI/O5mwSlA26yPvnzMRDLa0jNw==
X-Received: by 2002:a17:906:dc93:b0:ad5:6ca3:c795 with SMTP id a640c23a62f3a-ad56ca3cb15mr695759866b.33.1747741067721;
        Tue, 20 May 2025 04:37:47 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------VDfO9UbkA8u0Q20q29arCSXj"
Message-ID: <57765dd3-502a-4a28-8d15-2983b1f383ff@gmail.com>
Date: Tue, 20 May 2025 13:37:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 14/16] xen/riscv: add external interrupt handling for
 hypervisor mode
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <5688ed044febf734d9c75aa2e6f52affccd3fce9.1746530883.git.oleksii.kurochko@gmail.com>
 <1ca8df48-7e2d-4ad3-b1ad-8b4530fd22be@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <1ca8df48-7e2d-4ad3-b1ad-8b4530fd22be@suse.com>

This is a multi-part message in MIME format.
--------------VDfO9UbkA8u0Q20q29arCSXj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/15/25 11:54 AM, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> +static void cf_check aplic_set_irq_type(struct irq_desc *desc, unsigned int type)
>> +{
>> +    /*
>> +    * Interrupt 0 isn't possible based on the spec:
>> +    *   Each of an APLIC’s interrupt sources has a fixed unique identity number in the range 1 to N,
>> +    *   where N is the total number of sources at the APLIC. The number zero is not a valid interrupt
>> +    *   identity number at an APLIC. The maximum number of interrupt sources an APLIC may support
>> +    *   is 1023.
>> +    *
>> +    * Thereby interrupt 1 will correspond to bit 0 in sourcecfg[] register,
>> +    * interrupt 2 ->sourcecfg[1] and so on.
>> +    *
>> +    * And that is the reason why we need -1.
>> +    */
>> +    unsigned int irq_bit = desc->irq - 1;
>> +
>> +    spin_lock(&aplic.lock);
>> +
>> +    switch(type)
> Nit: style
>
>> +    {
>> +    case IRQ_TYPE_EDGE_RISING:
>> +        writel(APLIC_SOURCECFG_SM_EDGE_RISE, &aplic.regs->sourcecfg[irq_bit]);
>> +        break;
>> +
>> +    case IRQ_TYPE_EDGE_FALLING:
>> +        writel(APLIC_SOURCECFG_SM_EDGE_FALL, &aplic.regs->sourcecfg[irq_bit]);
>> +        break;
>> +
>> +    case IRQ_TYPE_LEVEL_HIGH:
>> +        writel(APLIC_SOURCECFG_SM_LEVEL_HIGH, &aplic.regs->sourcecfg[irq_bit]);
>> +        break;
>> +
>> +    case IRQ_TYPE_LEVEL_LOW:
>> +        writel(APLIC_SOURCECFG_SM_LEVEL_LOW, &aplic.regs->sourcecfg[irq_bit]);
>> +        break;
>> +
>> +    case IRQ_TYPE_NONE:
>> +        fallthrough;
> This is pointless (and hampering readability) when there are no other statements.

Oh, okay, it should be:
   case IRQ_TYPE_NONE:
   case IRQ_TYPE_INVALID:
I thought fallthrough should be used always in such cases.
Anyway, I'll drop it.

>
> With both taken care of:
> Acked-by: Jan Beulich

Thanks.

I am going also to add "ASSERT(spin_is_locked(&desc->lock));" at the start of this
function to be algined with other callbacks which uses spin_{un}lock(&aplic.lock).

~ Oleksii

--------------VDfO9UbkA8u0Q20q29arCSXj
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 11:54 AM, Jan Beulich wrote:
    
    
    
    
    
      
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    +static void cf_check aplic_set_irq_type(struct irq_desc *desc, unsigned int type)
+{
+    /*
+    * Interrupt 0 isn't possible based on the spec:
+    *   Each of an APLIC’s interrupt sources has a fixed unique identity number in the range 1 to N,
+    *   where N is the total number of sources at the APLIC. The number zero is not a valid interrupt
+    *   identity number at an APLIC. The maximum number of interrupt sources an APLIC may support
+    *   is 1023.
+    *
+    * Thereby interrupt 1 will correspond to bit 0 in sourcecfg[] register,
+    * interrupt 2 ->sourcecfg[1] and so on.
+    *
+    * And that is the reason why we need -1.
+    */
+    unsigned int irq_bit = desc->irq - 1;
+
+    spin_lock(&aplic.lock);
+
+    switch(type)

    
      
    
      
    Nit: style


    
      
    
        
    +    {
+    case IRQ_TYPE_EDGE_RISING:
+        writel(APLIC_SOURCECFG_SM_EDGE_RISE, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_EDGE_FALLING:
+        writel(APLIC_SOURCECFG_SM_EDGE_FALL, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_LEVEL_HIGH:
+        writel(APLIC_SOURCECFG_SM_LEVEL_HIGH, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_LEVEL_LOW:
+        writel(APLIC_SOURCECFG_SM_LEVEL_LOW, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_NONE:
+        fallthrough;

    
      
    
      
    This is pointless (and hampering readability) when there are no other statements.
    
    
    
    
    Oh, okay, it should be:
  case IRQ_TYPE_NONE:
  case IRQ_TYPE_INVALID:
I thought fallthrough should be used always in such cases.
Anyway, I'll drop it.


    
    
    
      
    
With both taken care of:
Acked-by: Jan Beulich <jbeulich@suse.com>
    
    
    
    
    Thanks.

I am going also to add "ASSERT(spin_is_locked(&desc->lock));" at the start of this
function to be algined with other callbacks which uses spin_{un}lock(&aplic.lock).
    
    
    ~ Oleksii

    
  


--------------VDfO9UbkA8u0Q20q29arCSXj--


From xen-devel-bounces@lists.xenproject.org Tue May 20 11:54:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 11:54:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990678.1374604 (Exim 4.92)
	(envelope-from )
	id 1uHLXY-0005pt-Df; Tue, 20 May 2025 11:53:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990678.1374604; Tue, 20 May 2025 11:53: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 1uHLXY-0005pm-Ae; Tue, 20 May 2025 11:53:48 +0000
Received: by outflank-mailman (input) for mailman id 990678;
 Tue, 20 May 2025 11:53:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHLXX-0005pg-2s
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 11:53:47 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 145f6bf4-3571-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 13:53:44 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad5394be625so52246666b.2
 for ; Tue, 20 May 2025 04:53:43 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d4f2cd8sm7093085a12.15.2025.05.20.04.53.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 04:53: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" 
X-Inumbo-ID: 145f6bf4-3571-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747742023; x=1748346823; darn=lists.xenproject.org;
        h=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;
        bh=xfZkE131mIxLsC0cdTVCU8aUE78yQal29ryN+ESy2ss=;
        b=TLh0j7qudPeUUe6zfaubnM/GP6wf1PK4gaf3ZmgDlI8U4IohGPoFLHUPS6tI0Y52AS
         K04Bmg2b7cXZZ+NwObdA5x76GYdXNsmQKyGMEEx0S7A9zP5mn3gT8tdOV5G73gCV7hzg
         wWn4jsnL9DV/4SLXHLBekLkifShNU2i4eHcowICZm2PXYyPOqvgUysJWFPprn5t1+7dp
         +bnWKnYEGRZoo+4gdnOAHNrFYwfC+Ixd4pMr1M0DVQiNVlDn3/s5zAtlb2fGQ+naKR7d
         yUOZLHhLK+s/14q4A5UKoLeEr7shSdBcZYaR1WdROV8sGrDFoQ914tNmLoFVrCOTh4A3
         YD6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747742023; x=1748346823;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=xfZkE131mIxLsC0cdTVCU8aUE78yQal29ryN+ESy2ss=;
        b=UihU/mbcrmtd6l9hIGpZNjuzWxWBiIUgmEgZI8rMvF9mGrlBJKbwGk+ia4d5/yUNWI
         zLZkB9/WYRqouGSMpD82RIciYSCmNNH4seLeqGAKtQiUVLisxSezFgB4suh3Dt70HIih
         r+PoJ1xpg1hnLlyym2Bbjxhyo6IlkkJOMZcw+t/ZbIbDuTjrqJpjwGC9S5EXZ/ZFTzNH
         NTc601BpwEgS5URKyn3h+x9YkdYg0ML3kYJ5lX7e0lUeO0cFEHfWSGRfWQQpyXQvQWLt
         4EOPafF2mKTtxFTW0I+feb58+XB3ypc0lu8hymoLOcgwS8xxlzax4OVCmHcoKb2hv3W2
         q3JQ==
X-Forwarded-Encrypted: i=1; AJvYcCUBbmZhohx7eyMcee+8J8OA/oXDVQFc4fvEMrVTcQ21WZeaRYPoDUX72w3RZJc+i7xbgJn5dwC7djc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzwVEwCtUNxPbCJMY+Blb0+SpsleroIsII+WnReCC/E07tudhrH
	7znjoXNoPnaCzSwaOw8iqnFaGku9Tl7PYaahoSs9zRuArKzG+Y8N6oYW
X-Gm-Gg: ASbGncv+pCmhrOB21D139K4dWSYH9dI2dcl/YUkAspmicmz+8F5z1MVgTSJLQNWSO+l
	Hdkp3rSwx5yLyefaFwmgHoPfz9IQy6CsHDKjaXJGDi6FpwsSIaItTqJ+vrGSVpro6m/LIuEdRgK
	Ev+AyT97tMIUIZGKoSy0seuuxP/nbsLMHtp7+Orb54PDprloHj8h4schWJCRMuHUVLXE1FAL2uY
	49E5Tdhl9I25wKFbNN6wKzrGcIkBap8X2QCEw0y9sY7cd1+3GM6o3kGUV3ZCUYOAbkxgxufV89d
	oeOkCh6ZmqBwYcLl+5xB1CTMQ+04oq+42jN8EGsh6A/JW0l24GTFlARJBOTrv+iUjndJnYaX58c
	GE/RxBDArgxyhcPcWgoBKfdVh
X-Google-Smtp-Source: AGHT+IFuwRSG4zKXovxptz9vbfe/65SZs9ADDF35ldbwi+trGwL0DwXS2UOvgfN/6LVqIMLCF9qHjA==
X-Received: by 2002:a17:907:7da8:b0:ad2:4fb7:6cd7 with SMTP id a640c23a62f3a-ad536b5a0e6mr1437237566b.2.1747742022850;
        Tue, 20 May 2025 04:53:42 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------hZtnhytO99qVl3cCHO8z3lAw"
Message-ID: 
Date: Tue, 20 May 2025 13:53:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 15/16] xen/riscv: implement setup_irq()
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <6f17bbf0eb6240d7389d389f0973af6fda5cce29.1746530883.git.oleksii.kurochko@gmail.com>
 <5f8a2840-2080-4b04-8298-0f5e22eaf5c0@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <5f8a2840-2080-4b04-8298-0f5e22eaf5c0@suse.com>

This is a multi-part message in MIME format.
--------------hZtnhytO99qVl3cCHO8z3lAw
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/15/25 11:57 AM, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> @@ -58,6 +59,89 @@ int platform_get_irq(const struct dt_device_node *device, int index)
>>       return dt_irq.irq;
>>   }
>>   
>> +static int _setup_irq(struct irq_desc *desc, unsigned int irqflags,
>> +                      struct irqaction *new)
>> +{
>> +    bool shared = irqflags & IRQF_SHARED;
>> +
>> +    ASSERT(new != NULL);
>> +
>> +    /*
>> +     * Sanity checks:
>> +     *  - if the IRQ is marked as shared
>> +     *  - dev_id is not NULL when IRQF_SHARED is set
>> +     */
>> +    if ( desc->action != NULL && (!(desc->status & IRQF_SHARED) || !shared) )
>> +        return -EINVAL;
>> +    if ( shared && new->dev_id == NULL )
>> +        return -EINVAL;
>> +
>> +    if ( shared )
>> +        desc->status |= IRQF_SHARED;
>> +
>> +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
>> +    new->next = desc->action;
>> +#endif
> Didn't you indicate you'd drop this?

To one of replies I wrote that probably something (eg RISC-V's IOMMU) will want to setup
multiple handler for the same interrupt. But I'm not sure yet. I can drop for now and
return back when it will be really a use case.

~ Oleksii

--------------hZtnhytO99qVl3cCHO8z3lAw
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 11:57 AM, Jan Beulich wrote:
    
    
    
    
    
      
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    @@ -58,6 +59,89 @@ int platform_get_irq(const struct dt_device_node *device, int index)
     return dt_irq.irq;
 }
 
+static int _setup_irq(struct irq_desc *desc, unsigned int irqflags,
+                      struct irqaction *new)
+{
+    bool shared = irqflags & IRQF_SHARED;
+
+    ASSERT(new != NULL);
+
+    /*
+     * Sanity checks:
+     *  - if the IRQ is marked as shared
+     *  - dev_id is not NULL when IRQF_SHARED is set
+     */
+    if ( desc->action != NULL && (!(desc->status & IRQF_SHARED) || !shared) )
+        return -EINVAL;
+    if ( shared && new->dev_id == NULL )
+        return -EINVAL;
+
+    if ( shared )
+        desc->status |= IRQF_SHARED;
+
+#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    new->next = desc->action;
+#endif

    
      
    
      
    Didn't you indicate you'd drop this?
    
    
    
    
    To one of replies I wrote that probably something (eg RISC-V's IOMMU) will want to setup
multiple handler for the same interrupt. But I'm not sure yet. I can drop for now and
return back when it will be really a use case.

~ Oleksii

    
  


--------------hZtnhytO99qVl3cCHO8z3lAw--


From xen-devel-bounces@lists.xenproject.org Tue May 20 11:57:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 11:57:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990685.1374614 (Exim 4.92)
	(envelope-from )
	id 1uHLb6-0006Nn-RK; Tue, 20 May 2025 11:57:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990685.1374614; Tue, 20 May 2025 11:57:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHLb6-0006Ng-Oq; Tue, 20 May 2025 11:57:28 +0000
Received: by outflank-mailman (input) for mailman id 990685;
 Tue, 20 May 2025 11:57:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHLb5-0006Na-FG
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 11:57:27 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9925649e-3571-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 13:57:26 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad1a87d93f7so877411066b.0
 for ; Tue, 20 May 2025 04:57:26 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4cc5dbsm717040066b.169.2025.05.20.04.57.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 04:57: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" 
X-Inumbo-ID: 9925649e-3571-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747742245; x=1748347045; 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;
        bh=3mnj1/ZJr8WXSrPzXVOhf5MKDkqj6JCkA4uZU0rfdXg=;
        b=cAmqkOhM5ZeQcppVqY/jwo8M/rRAgdlNMiivB9j4I/XxLyrSKO9IqoB5RnX9KbSdfu
         eWdXW5vlkjc5Yke/uPNG9hZOk3ZMehe/KOBWhvPpkIlrxe3uR6Q+2pKUte0Yyr28IMNm
         9MUHTnKomdC3ncw59/yp63gJNPlAJ5NS52bMY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747742245; x=1748347045;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=3mnj1/ZJr8WXSrPzXVOhf5MKDkqj6JCkA4uZU0rfdXg=;
        b=r0goDvVW2Pmh4M+UUZGpvmEzVGl/9OP2e6lyfyVr142UEsnaFv2oebjOEzcVAN8mxf
         AzsHMTP/s4sYZwxJufUHSM3ynhXGzj9spvAUGGbiqumD2gPE2YoL7s851nev/JoViwLn
         qsYdwswsoMCcN5Asel2xG6eL8A3emXovA5a9353eOaFgTwbis7JB9+UnM1U1aBMzx4/4
         nvSz1io7T98ygEpG1kjpbm4J1WiHTcSF/3yNfTDeOMSvTSfcc06bRspKOFnQOlUNIYTF
         MqvBswQG1lSKf+KT8IlIhPJ3COe6Z9kRlcAh/C6sitgLSyY1L2XTnRe4AnGoG5D1vZfE
         yZrQ==
X-Gm-Message-State: AOJu0Yy8r+d+yqeocidxoeTAqU1V1ZFua2D2FFwcoxyOtKxbOgRAkEpG
	2obzTNkMycutF7acP+Pn0OT/XTuinwLWmLbIZHx1B9Vpue95Jbw9XK7KsZA+MYeJy7S8ekSCLOS
	GTcmf
X-Gm-Gg: ASbGncsX5J6SLdv6t0nU00gTKh3DBqHUpv1rRGypNeauXpNnavfXOxwjTNbi7dWjjvh
	IKcq5f+8T0OzFJWedN0uf2Tm0nblSa4IPQA5hTabZe1X4SeqaNh/enra1YqGKfOrD1m1Yydm3G5
	QS5SwsfyxaoIcChZKabTlHRxIhLrFjVHsMjqO/M3ByXrVsbgQqr+fYr+L4bgS+BTWk7CCeUCXuN
	6CFJK+DP1/4o1rsOZGg8h/CpJF+xMLIxfkue5hFfDYaxEOxJYTPu62wumcSDSDeayjcmV6jEuC8
	dXw1kSGEy5EQW1FzsCkSxcoOgPW5yefP799LvGikcbAET3tni60t8qPExonLl/qHUUW/
X-Google-Smtp-Source: AGHT+IEFqCy2tk25vh/tS5BUxWQx81bsGoEoC3yPRt9XfaHP29VODL0/hkkrQ9F9zt3lvV7eXRbJRA==
X-Received: by 2002:a17:907:3e16:b0:ad4:f512:733 with SMTP id a640c23a62f3a-ad536dce6e4mr1584479666b.45.1747742245432;
        Tue, 20 May 2025 04:57:25 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Kevin Lampis 
Subject: [PATCH v2 2/3] Add lockdown mode
Date: Tue, 20 May 2025 12:57:16 +0100
Message-ID: <20250520115716.706100-1-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
In-Reply-To: <20250512195628.1728455-3-kevin.lampis@cloud.com>
References: <20250512195628.1728455-3-kevin.lampis@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Ross Lagerwall 

The intention of lockdown mode is to prevent attacks from a rogue dom0
userspace from compromising the system. Lockdown mode can be controlled by a
Kconfig option and a command-line parameter. It is also enabled automatically
when Secure Boot is enabled and it cannot be disabled in that case.

If enabled from the command-line then it is required to be first in the
list otherwise Xen may process some insecure parameters before reaching
the lockdown parameter.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Kevin Lampis 
---
Changes in v2:
- Remove custom command line parsing
- Print warning if lockdown is not first on command line
---
 xen/arch/x86/setup.c       |  1 +
 xen/common/Kconfig         |  8 ++++++
 xen/common/Makefile        |  1 +
 xen/common/kernel.c        |  6 +++++
 xen/common/lockdown.c      | 54 ++++++++++++++++++++++++++++++++++++++
 xen/include/xen/lockdown.h | 11 ++++++++
 6 files changed, 81 insertions(+)
 create mode 100644 xen/common/lockdown.c
 create mode 100644 xen/include/xen/lockdown.h

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2518954124..276957c4ed 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6d43be2e6e..c84073563f 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -576,4 +576,12 @@ config BUDDY_ALLOCATOR_SIZE
 	  Amount of memory reserved for the buddy allocator to serve Xen heap,
 	  working alongside the colored one.
 
+config LOCKDOWN_DEFAULT
+       bool "Enable lockdown mode by default"
+       default n
+       help
+         Lockdown mode prevents attacks from a rogue dom0 userspace from
+         compromising the system. This is automatically enabled when Secure
+         Boot is enabled.
+
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..b00a8a925a 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC) += kimage.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
+obj-y += lockdown.o
 obj-$(CONFIG_VM_EVENT) += mem_access.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 8b63ca55f1..3538f467ad 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -199,6 +199,8 @@ static int parse_params(const char *cmdline, const struct kernel_param *start,
             printk("parameter \"%s\" unknown!\n", key);
             final_rc = -EINVAL;
         }
+
+        lockdown_clear_first_flag();
     }
 
     return final_rc;
@@ -216,6 +218,9 @@ static void __init _cmdline_parse(const char *cmdline)
  */
 void __init cmdline_parse(const char *cmdline)
 {
+    /* Call this early since it affects command-line parsing */
+    lockdown_init(cmdline);
+
     if ( opt_builtin_cmdline[0] )
     {
         printk("Built-in command line: %s\n", opt_builtin_cmdline);
@@ -227,6 +232,7 @@ void __init cmdline_parse(const char *cmdline)
         return;
 
     safe_strcpy(saved_cmdline, cmdline);
+    lockdown_set_first_flag();
     _cmdline_parse(cmdline);
 #endif
 }
diff --git a/xen/common/lockdown.c b/xen/common/lockdown.c
new file mode 100644
index 0000000000..cd3deeb63e
--- /dev/null
+++ b/xen/common/lockdown.c
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include 
+#include 
+#include 
+
+#define FIRST_ARG_FLAG 2
+
+static int __ro_after_init lockdown = IS_ENABLED(CONFIG_LOCKDOWN_DEFAULT);
+
+void __init lockdown_set_first_flag(void)
+{
+    lockdown |= FIRST_ARG_FLAG;
+}
+
+void __init lockdown_clear_first_flag(void)
+{
+    lockdown &= ~FIRST_ARG_FLAG;
+}
+
+static int __init parse_lockdown_opt(const char *s)
+{
+    if ( strncmp("no", s, 2) == 0 )
+        if ( efi_secure_boot )
+            printk("lockdown can't be disabled because Xen booted in Secure Boot mode\n");
+        else
+            lockdown = 0;
+    else
+    {
+        if ( !(lockdown & FIRST_ARG_FLAG) )
+            printk("lockdown was not the first argument, unsafe arguments may have been already processed\n");
+
+        lockdown = 1;
+    }
+
+    return 0;
+}
+custom_secure_param("lockdown", parse_lockdown_opt);
+
+bool is_locked_down(void)
+{
+    return lockdown & ~FIRST_ARG_FLAG;
+}
+
+void __init lockdown_init(const char *cmdline)
+{
+    if ( efi_secure_boot )
+    {
+        printk("Enabling lockdown mode because Secure Boot is enabled\n");
+        lockdown = 1;
+    }
+
+    printk("Lockdown mode is %s\n", is_locked_down() ? "enabled" : "disabled");
+}
diff --git a/xen/include/xen/lockdown.h b/xen/include/xen/lockdown.h
new file mode 100644
index 0000000000..6ae97f9d5f
--- /dev/null
+++ b/xen/include/xen/lockdown.h
@@ -0,0 +1,11 @@
+#ifndef XEN__LOCKDOWN_H
+#define XEN__LOCKDOWN_H
+
+#include 
+
+void lockdown_set_first_flag(void);
+void lockdown_clear_first_flag(void);
+bool is_locked_down(void);
+void lockdown_init(const char *cmdline);
+
+#endif /* XEN__LOCKDOWN_H */
-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Tue May 20 11:57:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 11:57:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990689.1374624 (Exim 4.92)
	(envelope-from )
	id 1uHLbW-0006ni-3G; Tue, 20 May 2025 11:57:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990689.1374624; Tue, 20 May 2025 11:57: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 1uHLbW-0006nb-0i; Tue, 20 May 2025 11:57:54 +0000
Received: by outflank-mailman (input) for mailman id 990689;
 Tue, 20 May 2025 11:57:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHLbU-0006Na-Mt
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 11:57:52 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a86840cf-3571-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 13:57:52 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-6021b8b2c5fso566262a12.2
 for ; Tue, 20 May 2025 04:57:52 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d438c3csm714514766b.88.2025.05.20.04.57.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 04: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" 
X-Inumbo-ID: a86840cf-3571-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747742272; x=1748347072; darn=lists.xenproject.org;
        h=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;
        bh=TcRo7hM/qL07m0qM3hsPwDo4G3dgTyKl9/oWDlAmqBs=;
        b=nhXaJiXJ3Ybe2Id8Nnc/fAEjJ/PLA9ZM3tivcBIqx/dN6pwg0o1xas3ODlUKq54Gg/
         Q6+hxW9hOTey2oLq0HGdCeGwKdEssNUQCRevlqqLHYTBq7vxMsXM/1Mli6pJlqdHR9RF
         +dNGXgWB2/fJt1OQ5/hqTGTzbj0ZLyP7PjKadVjtAppWSo+df4PQqoRLB6Dmrru1S3mI
         E3MDJK7DKF/9ZcsvCk2LTGJ8FfnXngTBH/3NxrEjN+Ky55f2+43K9KscDgb/fridKaYo
         8XauiWRmF4Zbqd0My/AnVVZIs24l4hq+HHbVLafd1qbGL8PluReUyFCMklaudmkio3t4
         /XPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747742272; x=1748347072;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=TcRo7hM/qL07m0qM3hsPwDo4G3dgTyKl9/oWDlAmqBs=;
        b=GeNpgjGPVVXNDS0RzrLyxm0hI9+VnLPt/Ey1osCvX/YO+0fLRuQ5gmi9LZYTeay6qF
         ecPJEM64332ISAqXOxzhTcOnbtA68R9Ghc5sxXfYbZEPv/3FifjwTHMoX6FLNLluVYmk
         GP3cPJhFnHCL0TAfQuteQH/4uY6G6D/NVq6NRXFH0HqanbmgJf14ye97xymuEndr+WhP
         NOQ6H1E+EGYo7d7fsZ1I9j9zWindl8LMUSwSiXb6t3pKj4p8+T8iNvGqVHBZTC7eMmOk
         QFC3WNDSFHjOZ/EUC7WoSQ40dM/4KTSq2pyNiaKynUYtcqiUIeE6RSe10Z8WpGDbqZS6
         q+Ug==
X-Forwarded-Encrypted: i=1; AJvYcCVGfB60G73jTS95BOZXFz2fvhGjxQT7NGs5PDFnWLCiovqXeac9NHRSr7LfjVE4dWg5CRbR8ZvajxQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx2mh9N50bmPgBQcSJA66wk1S6pQlOE1Ztp6MxZHyMvy+OWED52
	sk48i43U7fhwKrflHiicbnbEQ+/nCqA0cwyy3TxyFmjpOV6+a6w7j5Dr
X-Gm-Gg: ASbGncvts7J6WnlMYUacSwr8ekBAMDq7bsuVuMc6p23Wesv1mfO8+wA0euObj4L7xQD
	yOv6X3b/0BoQgupRFBKujVIzgUe9fvOn9SGtkAA7SyNBONuY7cGG2BUL7Fe7MUf7M+bpAXoXvC5
	T+Zont4qRjxqtvQ+kqQtKcLJBeeqysaC18jRPNZlXxAXjGNeCVGLAE5SMDGjJAO8TsVaJA0HbrD
	xSjyGg3P8vc4ZgqayCqAUG9tFub1okqTc5YawlXykKIlJJOJWBoMdp0etjj7phEhWbJh07BFaE4
	QATWkYKFRTn8F6MfBu4eA1IcldnxhC1+PvPvONXiBQ4VHzG0CMIsPFno3Z0HCmJkA8xyQzaWZI3
	E2lNcE4K3usK3OwPBeySbbrJaQ9o6mXR7V54=
X-Google-Smtp-Source: AGHT+IFeoT5qefTQ8xEUUswPvD8G/yrIViZSIjs77zcbXsL83YsJEYW+6Kpenf0SHlIf2VcO1nBNYA==
X-Received: by 2002:a17:907:1b0d:b0:ace:c518:1327 with SMTP id a640c23a62f3a-ad52d496a42mr1448877866b.14.1747742271511;
        Tue, 20 May 2025 04:57:51 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------bOIgjCPENvRSl8K0409gah00"
Message-ID: <24733cab-d34a-4baf-bc04-e99b0f61a283@gmail.com>
Date: Tue, 20 May 2025 13:57:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 16/16] xen/riscv: add basic UART support
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <9fbcd17751fb0b7925d622631acb0030ee110465.1746530883.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------bOIgjCPENvRSl8K0409gah00
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/15/25 11:59 AM, Jan Beulich wrote:
> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/setup.c
>> +++ b/xen/arch/riscv/setup.c
>> @@ -4,12 +4,16 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>>   #include 
>> +#include 
> Why's this needed? I can't spot anything ...

It should be dropped. This rudiment left when I called percpu_init_areas().

>
>> +#include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   
>> @@ -136,8 +140,17 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>>   
>>       intc_preinit();
>>   
>> +    uart_init();
>> +    console_init_preirq();
>> +
>>       intc_init();
>>   
>> +    timer_init();
>> +
>> +    local_irq_enable();
>> +
>> +    console_init_postirq();
>> +
>>       printk("All set up\n");
>>   
>>       machine_halt();
> ... relevant here. With the need clarified or with the #include dropped:
> Acked-by: Jan Beulich

Thanks.

~ Oleksii

--------------bOIgjCPENvRSl8K0409gah00
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 11:59 AM, Jan Beulich wrote:
    
    
    
    
    
      
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
      
    
        
    --- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -4,12 +4,16 @@
 #include <xen/bug.h>
 #include <xen/bootfdt.h>
 #include <xen/compile.h>
+#include <xen/console.h>
 #include <xen/device_tree.h>
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/mm.h>
+#include <xen/percpu.h>

    
      
    
      
    Why's this needed? I can't spot anything ...
    
    
    
    
    It should be dropped. This rudiment left when I called percpu_init_areas().
    
    
    
      
    

    
      
    
        
    +#include <xen/serial.h>
 #include <xen/shutdown.h>
 #include <xen/smp.h>
+#include <xen/timer.h>
 #include <xen/vmap.h>
 #include <xen/xvmalloc.h>
 
@@ -136,8 +140,17 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     intc_preinit();
 
+    uart_init();
+    console_init_preirq();
+
     intc_init();
 
+    timer_init();
+
+    local_irq_enable();
+
+    console_init_postirq();
+
     printk("All set up\n");
 
     machine_halt();

    
      
    
      
    ... relevant here. With the need clarified or with the #include dropped:
Acked-by: Jan Beulich <jbeulich@suse.com>
    
    
    
    
    Thanks.
    
    
    ~ Oleksii
    
  


--------------bOIgjCPENvRSl8K0409gah00--


From xen-devel-bounces@lists.xenproject.org Tue May 20 12:05:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 12:05:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990707.1374636 (Exim 4.92)
	(envelope-from )
	id 1uHLiw-0000Lz-3R; Tue, 20 May 2025 12:05:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990707.1374636; Tue, 20 May 2025 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 1uHLiv-0000Ls-Ua; Tue, 20 May 2025 12:05:33 +0000
Received: by outflank-mailman (input) for mailman id 990707;
 Tue, 20 May 2025 12:05:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHLiu-0000Lm-H7
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 12:05:32 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ba29f718-3572-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 14:05:31 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad572ba1347so263983366b.1
 for ; Tue, 20 May 2025 05:05:31 -0700 (PDT)
Received: from fedora.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d490910sm723322166b.135.2025.05.20.05.05.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 05:05: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" 
X-Inumbo-ID: ba29f718-3572-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747742730; x=1748347530; 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;
        bh=mvrhvDhs6mgmUKLOrnz6N3GSrg7xwOOXlx04huiHAas=;
        b=CQXmGEWhfx9pDx1mmMrpB6CNxkWJcCjgswXzNiStfXNuLPuawbM3+dARF7XwdAEgqC
         LFAi3JpEjie/1IagXVF1IRV/klbh5gjOXN1/RoqcsdizKxhwLbLKIaiZEfLb6t+vvvoL
         JX2MIM1FmN9I578Ttlsl4+/BEx8Z/OnR+Fnn4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747742730; x=1748347530;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=mvrhvDhs6mgmUKLOrnz6N3GSrg7xwOOXlx04huiHAas=;
        b=F58yLFy44/ElxM6Jse4Ve6E5dcvyNjfDMpIwCUmYd20nRuYsKMNRfixBnRsF8+xfTY
         Npn/1IbwuzbzvvzEW/6wm6uTS2fwNh/u6+VX1F0Us5Iq7zE+z5Ex1xE2u72dLNjTATGq
         DmCmZPrEv56BV+YSDnHpOhmYDsR2TUWWdTExlz++Axx75nvZAC8iZL1fxvWD7Gt8ex9M
         4MHHRig6VqCC+8CxQx87PaEvx9M4xDyOUfKgsfxlEeXASJsYr1lXIeju2clylVl0gX1D
         s9Nq+d8UPe9Bo7iitwmwgOFEMGnoiUmALmNL+MmrPXOvLdP2ptWpVce601waby8Nj58J
         lEsA==
X-Gm-Message-State: AOJu0YzOMO35XwhNX2utEDSwO14YAVk+SKvsOprONoA5EgUnqn/Fouip
	Uf1uAtWVrGmYEhTWrZQxR/h3okPEEaXvRJrvFMSo/SSAcOwdTfCgabUZbDxd4gGh0v70VKRLeVe
	KoV41
X-Gm-Gg: ASbGnctcSciVyidUMockTWREBydwMWSH+LWon6dyCQ3le+BtN0p9AY8SOt13zgQDIE8
	4EvlRGyL6dnvBVDCnP0/eVpvFaE6W0alukIZVmgFGeq8gyYuUXvEybJz+xRORgNPXLCz1Qp4Eou
	xFT6UFdx07AK9KtsEEtp/5H+3w7/JJRa+K0ONZ0N47kin+n9AI9kY0Uqp6k70vXVBahPstGMtYY
	av933gisoOimzE+o6SxX1M+LCWofIelw9YlKxMIGSCUKDQOPpObVeRvScQRXw6E6sDw4aVR3+3g
	moBdmCeQ1TIIGPlxT/WYT4m71tCkcbKGHH3Mj10F5RVOJm9c5ZpzgC9Z2an4PZxRvuxp
X-Google-Smtp-Source: AGHT+IGsD0GWhVNDa+/M4b1EaJciJdN5LsF67mIiczkWF3yB0kJGcZQ1I/HYk+mw0G1K3uGAaQlczQ==
X-Received: by 2002:a17:906:b20c:b0:ad5:3a0e:1ccd with SMTP id a640c23a62f3a-ad53a0e248fmr1175264066b.58.1747742730226;
        Tue, 20 May 2025 05:05:30 -0700 (PDT)
From: Kevin Lampis 
To: xen-devel@lists.xenproject.org
Cc: Kevin Lampis ,
	Ross Lagerwall 
Subject: [PATCH v2 3/3] Disallow most command-line options when lockdown mode is enabled
Date: Tue, 20 May 2025 13:05:26 +0100
Message-ID: <20250520120526.706142-1-kevin.lampis@cloud.com>
X-Mailer: git-send-email 2.42.0
In-Reply-To: <20250512195628.1728455-4-kevin.lampis@cloud.com>
References: <20250512195628.1728455-4-kevin.lampis@cloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

A subset of command-line parameters that are specifically safe to use when
lockdown mode is enabled are annotated as such.

These are commonly used parameters which have been audited to ensure they
cannot be used to undermine the integrity of the system when booted in
Secure Boot mode.

Signed-off-by: Kevin Lampis 
Signed-off-by: Ross Lagerwall 
---
Changes in v2:
- Add more information about the safe parameters
- Add lockdown section to the command line doc
---
 docs/misc/xen-command-line.pandoc     | 16 +++++++++
 xen/arch/arm/domain_build.c           |  4 +--
 xen/arch/x86/acpi/cpu_idle.c          |  2 +-
 xen/arch/x86/cpu/amd.c                |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c         |  2 +-
 xen/arch/x86/cpu/microcode/core.c     |  2 +-
 xen/arch/x86/dom0_build.c             |  4 +--
 xen/arch/x86/hvm/hvm.c                |  2 +-
 xen/arch/x86/irq.c                    |  2 +-
 xen/arch/x86/nmi.c                    |  2 +-
 xen/arch/x86/setup.c                  |  2 +-
 xen/arch/x86/traps.c                  |  2 +-
 xen/arch/x86/x86_64/mmconfig-shared.c |  2 +-
 xen/common/domain.c                   |  2 +-
 xen/common/kernel.c                   | 11 +++++-
 xen/common/kexec.c                    |  2 +-
 xen/common/numa.c                     |  2 +-
 xen/common/page_alloc.c               |  2 +-
 xen/common/shutdown.c                 |  2 +-
 xen/drivers/char/console.c            |  2 +-
 xen/drivers/char/ns16550.c            |  4 +--
 xen/drivers/video/vga.c               |  2 +-
 xen/include/xen/param.h               | 49 +++++++++++++++++++++------
 23 files changed, 87 insertions(+), 35 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index b0eadd2c5d..7916875f22 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1798,6 +1798,22 @@ immediately. Specifying `0` will disable all testing of illegal lock nesting.
 
 This option is available for hypervisors built with CONFIG_DEBUG_LOCKS only.
 
+### lockdown
+> `= `
+
+> Default: `false`
+
+The intention of lockdown mode is to prevent attacks from a rogue dom0
+userspace from compromising the system. It is also enabled automatically
+when Secure Boot is enabled and it cannot be disabled in that case.
+
+After lockdown mode is enabled some unsafe command line options will be
+ignored by Xen.
+
+If enabling lockdown mode via the command line then ensure it is positioned as
+the first option in the command line string otherwise Xen may process unsafe
+options before reaching the lockdown parameter.
+
 ### loglvl
 > `= [/]` where level is `none | error | warning | info | debug | all`
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..ef1cba8f0f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -41,7 +41,7 @@
 #include 
 
 static unsigned int __initdata opt_dom0_max_vcpus;
-integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+integer_secure_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 /*
  * If true, the extended regions support is enabled for dom0 and
@@ -61,7 +61,7 @@ static int __init parse_dom0_mem(const char *s)
 
     return *s ? -EINVAL : 0;
 }
-custom_param("dom0_mem", parse_dom0_mem);
+custom_secure_param("dom0_mem", parse_dom0_mem);
 
 int __init parse_arch_dom0_param(const char *s, const char *e)
 {
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 1dbf15b01e..431fd0c997 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -113,7 +113,7 @@ static int __init cf_check parse_cstate(const char *s)
         max_csubstate = simple_strtoul(s + 1, NULL, 0);
     return 0;
 }
-custom_param("max_cstate", parse_cstate);
+custom_secure_param("max_cstate", parse_cstate);
 
 static bool __read_mostly local_apic_timer_c2_ok;
 boolean_param("lapic_timer_c2_ok", local_apic_timer_c2_ok);
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 27ae167808..9aab3d05e1 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -47,7 +47,7 @@ integer_param("cpuid_mask_thermal_ecx", opt_cpuid_mask_thermal_ecx);
 
 /* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */
 int8_t __read_mostly opt_allow_unsafe;
-boolean_param("allow_unsafe", opt_allow_unsafe);
+boolean_secure_param("allow_unsafe", opt_allow_unsafe);
 
 /* Signal whether the ACPI C1E quirk is required. */
 bool __read_mostly amd_acpi_c1e_quirk;
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 1c348e557d..a229af6fd3 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -31,7 +31,7 @@
 #include "vmce.h"
 
 bool __read_mostly opt_mce = true;
-boolean_param("mce", opt_mce);
+boolean_secure_param("mce", opt_mce);
 bool __read_mostly mce_broadcast;
 bool is_mc_panic;
 DEFINE_PER_CPU_READ_MOSTLY(unsigned int, nr_mce_banks);
diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 34a94cd25b..b5b7304ae7 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -160,7 +160,7 @@ static int __init cf_check parse_ucode(const char *s)
 
     return rc;
 }
-custom_param("ucode", parse_ucode);
+custom_secure_param("ucode", parse_ucode);
 
 static struct microcode_ops __ro_after_init ucode_ops;
 
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0b467fd4a4..6d42acb661 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -142,7 +142,7 @@ static int __init cf_check parse_dom0_mem(const char *s)
 
     return s[-1] ? -EINVAL : ret;
 }
-custom_param("dom0_mem", parse_dom0_mem);
+custom_secure_param("dom0_mem", parse_dom0_mem);
 
 static unsigned int __initdata opt_dom0_max_vcpus_min = 1;
 static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX;
@@ -164,7 +164,7 @@ static int __init cf_check parse_dom0_max_vcpus(const char *s)
 
     return *s ? -EINVAL : 0;
 }
-custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
+custom_secure_param("dom0_max_vcpus", parse_dom0_max_vcpus);
 
 static __initdata unsigned int dom0_nr_pxms;
 static __initdata unsigned int dom0_pxms[MAX_NUMNODES] =
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4cb2e13046..97afb274fe 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -87,7 +87,7 @@ unsigned long __section(".bss.page_aligned") __aligned(PAGE_SIZE)
 
 /* Xen command-line option to enable HAP */
 static bool __initdata opt_hap_enabled = true;
-boolean_param("hap", opt_hap_enabled);
+boolean_secure_param("hap", opt_hap_enabled);
 
 #ifndef opt_hvm_fep
 /* Permit use of the Forced Emulation Prefix in HVM guests */
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 556134f85a..44f39f6ece 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -34,7 +34,7 @@
 
 /* opt_noirqbalance: If true, software IRQ balancing/affinity is disabled. */
 bool __read_mostly opt_noirqbalance;
-boolean_param("noirqbalance", opt_noirqbalance);
+boolean_secure_param("noirqbalance", opt_noirqbalance);
 
 unsigned int __read_mostly nr_irqs_gsi = NR_ISA_IRQS;
 unsigned int __read_mostly nr_irqs;
diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 9793fa2316..3735f22e88 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -73,7 +73,7 @@ static int __init cf_check parse_watchdog(const char *s)
 
     return 0;
 }
-custom_param("watchdog", parse_watchdog);
+custom_secure_param("watchdog", parse_watchdog);
 
 /* opt_watchdog_timeout: Number of seconds to wait before panic. */
 static unsigned int opt_watchdog_timeout = 5;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 276957c4ed..1018cdb771 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -70,7 +70,7 @@
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool __initdata opt_nosmp;
-boolean_param("nosmp", opt_nosmp);
+boolean_secure_param("nosmp", opt_nosmp);
 
 /* maxcpus: maximum number of CPUs to activate. */
 static unsigned int __initdata max_cpus;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index c94779b4ad..7b628d9dc8 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -86,7 +86,7 @@ static char __read_mostly opt_nmi[10] = "dom0";
 #else
 static char __read_mostly opt_nmi[10] = "fatal";
 #endif
-string_param("nmi", opt_nmi);
+string_secure_param("nmi", opt_nmi);
 
 DEFINE_PER_CPU(uint64_t, efer);
 static DEFINE_PER_CPU(unsigned long, last_extable_addr);
diff --git a/xen/arch/x86/x86_64/mmconfig-shared.c b/xen/arch/x86/x86_64/mmconfig-shared.c
index f1a3d42c5b..80cdca7d77 100644
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -60,7 +60,7 @@ static int __init cf_check parse_mmcfg(const char *s)
 
     return rc;
 }
-custom_param("mmcfg", parse_mmcfg);
+custom_secure_param("mmcfg", parse_mmcfg);
 
 static const char *__init cf_check pci_mmcfg_e7520(void)
 {
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..c95988c067 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -55,7 +55,7 @@ unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
 
 /* opt_dom0_vcpus_pin: If true, dom0 VCPUs are pinned. */
 bool opt_dom0_vcpus_pin;
-boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
+boolean_secure_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
 
 /* Protect updates/reads (resp.) of domain_list and domain_hash. */
 DEFINE_SPINLOCK(domlist_update_lock);
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 3538f467ad..923ea43cee 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -135,9 +137,16 @@ static int parse_params(const char *cmdline, const struct kernel_param *start,
                 }
                 continue;
             }
+            found = true;
+
+            if ( !param->is_lockdown_safe && is_locked_down() )
+            {
+                printk("Ignoring unsafe cmdline option %s in lockdown mode\n",
+                       param->name);
+                break;
+            }
 
             rctmp = 0;
-            found = true;
             switch ( param->type )
             {
             case OPT_STR:
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 84fe8c3597..790839657d 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -189,7 +189,7 @@ static int __init cf_check parse_crashkernel(const char *str)
 
     return rc;
 }
-custom_param("crashkernel", parse_crashkernel);
+custom_secure_param("crashkernel", parse_crashkernel);
 
 /* Parse command lines in the format:
  *
diff --git a/xen/common/numa.c b/xen/common/numa.c
index ad75955a16..c4981f2ff1 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -687,7 +687,7 @@ static int __init cf_check numa_setup(const char *opt)
 
     return 0;
 }
-custom_param("numa", numa_setup);
+custom_secure_param("numa", numa_setup);
 
 static void cf_check dump_numa(unsigned char key)
 {
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index e57a287133..a07690d8fd 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -235,7 +235,7 @@ static int __init cf_check parse_bootscrub_param(const char *s)
 
     return 0;
 }
-custom_param("bootscrub", parse_bootscrub_param);
+custom_secure_param("bootscrub", parse_bootscrub_param);
 
 /*
  * bootscrub_chunk -> Amount of bytes to scrub lockstep on non-SMT CPUs
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index c47341b977..231de1454a 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -13,7 +13,7 @@
 
 /* opt_noreboot: If true, machine will need manual reset on error. */
 bool __ro_after_init opt_noreboot;
-boolean_param("noreboot", opt_noreboot);
+boolean_secure_param("noreboot", opt_noreboot);
 
 static void noreturn reboot_or_halt(void)
 {
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c3150fbdb7..45a35903fe 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -43,7 +43,7 @@
 
 /* console: comma-separated list of console outputs. */
 static char __initdata opt_console[30] = OPT_CONSOLE_STR;
-string_param("console", opt_console);
+string_secure_param("console", opt_console);
 
 /* conswitch: a character pair controlling console switching. */
 /* Char 1: CTRL+ is used to switch console input between Xen and DOM0 */
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index eaeb0e09d0..fae509cbd8 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1390,8 +1390,8 @@ static void enable_exar_enhanced_bits(const struct ns16550 *uart)
  */
 static char __initdata opt_com1[128] = "";
 static char __initdata opt_com2[128] = "";
-string_param("com1", opt_com1);
-string_param("com2", opt_com2);
+string_secure_param("com1", opt_com1);
+string_secure_param("com2", opt_com2);
 
 enum serial_param_type {
     baud_rate,
diff --git a/xen/drivers/video/vga.c b/xen/drivers/video/vga.c
index b577b24619..abc6e56aa3 100644
--- a/xen/drivers/video/vga.c
+++ b/xen/drivers/video/vga.c
@@ -48,7 +48,7 @@ void (*video_puts)(const char *s, size_t nr) = vga_noop_puts;
  * control of the console to domain 0.
  */
 static char __initdata opt_vga[30] = "";
-string_param("vga", opt_vga);
+string_secure_param("vga", opt_vga);
 
 /* VGA text-mode definitions. */
 static unsigned int columns, lines;
diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h
index 1bdbab34ab..31e7326d88 100644
--- a/xen/include/xen/param.h
+++ b/xen/include/xen/param.h
@@ -25,6 +25,7 @@ struct kernel_param {
         void *var;
         int (*func)(const char *s);
     } par;
+    bool is_lockdown_safe;
 };
 
 /* Maximum length of a single parameter string. */
@@ -44,46 +45,72 @@ extern const struct kernel_param __setup_start[], __setup_end[];
 #define _TEMP_NAME(base, line) __TEMP_NAME(base, line)
 #define TEMP_NAME(base) _TEMP_NAME(base, __LINE__)
 
-#define custom_param(_name, _var) \
+#define custom_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_CUSTOM, \
-          .par.func = (_var) }
-#define boolean_param(_name, _var) \
+          .par.func = (_var), \
+          .is_lockdown_safe = (_sec) }
+#define custom_param(_name, _var) \
+    custom_param_(_name, _var, false)
+#define custom_secure_param(_name, _var) \
+    custom_param_(_name, _var, true)
+#define boolean_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_BOOL, \
           .len = sizeof(_var) + \
                  BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
-          .par.var = &(_var) }
-#define integer_param(_name, _var) \
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define boolean_param(_name, _var) \
+    boolean_param_(_name, _var, false)
+#define boolean_secure_param(_name, _var) \
+    boolean_param_(_name, _var, true)
+#define integer_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_UINT, \
           .len = sizeof(_var), \
-          .par.var = &(_var) }
-#define size_param(_name, _var) \
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define integer_param(_name, _var) \
+    integer_param_(_name, _var, false)
+#define integer_secure_param(_name, _var) \
+    integer_param_(_name, _var, true)
+#define size_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_SIZE, \
           .len = sizeof(_var), \
-          .par.var = &(_var) }
-#define string_param(_name, _var) \
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define size_param(_name, _var) \
+    size_param_(_name, _var, false)
+#define size_secure_param(_name, _var) \
+    size_param_(_name, _var, true)
+#define string_param_(_name, _var, _sec) \
     __setup_str __setup_str_##_var[] = (_name); \
     __kparam __setup_##_var = \
         { .name = __setup_str_##_var, \
           .type = OPT_STR, \
           .len = sizeof(_var), \
-          .par.var = &(_var) }
+          .par.var = &(_var), \
+          .is_lockdown_safe = (_sec) }
+#define string_param(_name, _var) \
+  string_param_(_name, _var, false)
+#define string_secure_param(_name, _var) \
+  string_param_(_name, _var, true)
 #define ignore_param(_name)                 \
     __setup_str TEMP_NAME(__setup_str_ign)[] = (_name);  \
     __kparam TEMP_NAME(__setup_ign) =                    \
         { .name = TEMP_NAME(__setup_str_ign),            \
-          .type = OPT_IGNORE }
+          .type = OPT_IGNORE,                            \
+          .is_lockdown_safe = true }
 
 #ifdef CONFIG_HYPFS
 
-- 
2.42.0



From xen-devel-bounces@lists.xenproject.org Tue May 20 12:44:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 12:44:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990715.1374645 (Exim 4.92)
	(envelope-from )
	id 1uHMJx-00062Y-OW; Tue, 20 May 2025 12:43:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990715.1374645; Tue, 20 May 2025 12:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHMJx-00062R-Lg; Tue, 20 May 2025 12:43:49 +0000
Received: by outflank-mailman (input) for mailman id 990715;
 Tue, 20 May 2025 12:43:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHMJw-00062L-Fe
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 12:43:48 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 126a870d-3578-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 14:43:47 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-601aa0cb92eso3621214a12.0
 for ; Tue, 20 May 2025 05:43:47 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d04e665sm721788966b.5.2025.05.20.05.43.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 05:43:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 126a870d-3578-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747745026; x=1748349826; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=ggUS9oTHJhmybZknx5MZc3EcGArj8C4sRd0GYfEHAew=;
        b=gXuVzHkNaDFKJfaCLsIdtGnoVbkhkUJ6+QMx3dF1VJ8dy3P7l0fqa9ZMKN8Mus+rK8
         LWS8KU4REXG0ZwmDyorRI2BS1oSq/Rsl6y8RGrVG+uv4a017cYKkwr7UUyPYao/THA7E
         9CVGDfk3PnKA3KYiHxcCEpkXsvpsgBjuMmh6eufphZKGYGJev52pRVZ4NzWooNZoNdI+
         rN5AV5BDdF5McMolhEMJU8/3BCOS5IgxjE1PjaPU52iGBTJcP4InR2oXVvmDp3OkA7lF
         dNFbaCMx2nRPvs8D9Nzt04uvbSQ3qoZhqtdcutf0WkJNIXMSIOnd7k3+DpjKS1cvhmJb
         zlYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747745026; x=1748349826;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ggUS9oTHJhmybZknx5MZc3EcGArj8C4sRd0GYfEHAew=;
        b=v2AW024B481O2zh+0rvxWAcOjFQradUxX4hKuq8IaAyA3f1LbHiXtZCe/xClz7/5RR
         TKugsvEaghQkL2HfRLgfub7Ore0oSNkQm/RV5393bc2WWOtjadlLA6sPi1sBpZ9/Mhzq
         6eGF4IHwdBPLNJ9PLV+NlF/NusypxGkoJCeNwXgbsFA8wjNRdDoTFbqvPt7bKG5uP4NF
         fMmd0HsEikcxCSG6K0quKahDKZ3OhPol7xLdZwUR72Hb30sZfHeJCOTh3aIJFrdIG6X6
         d2iIsSGbid25Zi5pjMonTl/1eZeueWPwyWBm4VI6SlvbDb+WO6BTBtep+33IZOnMyP7m
         0ATQ==
X-Gm-Message-State: AOJu0Yzu1Vv0gMhYcqqnXhwABGw7ipEUus1ysEdTZ6PpmWyS8PG/KtQl
	eqDgqeN9STtIPwvCBjwxhkzP0b7sW5pGOQpbnxWkRgew+W10mhGyBwSoOAwzj8tjeA==
X-Gm-Gg: ASbGncu3QZ0ekPNUEFaWHcXwSLil6FxfR3R8dx9eEbErDq2uJVkMaZ3OhiKU5r2KvDR
	10LU/Uw9Mhfc6oYS+MXA1CACJALMDJRT3/Cg1wNUSeW+KIPBznGRVYfJcWjnZ4GLXm2Ax5gDrIM
	bi+H7v+6dWdJBJncHKeWFXzVTnYsRzWQzTwRwGf71veH0+2DPycn+6Zp7I6WIKZUzfHsj5HB1za
	hpXtAtd7gvDXNz4dP2S7hlYRY59rqh0dYYEOAfv2tri13M6GdEWDzCqK0Bqv6gnSQMu4ruae51s
	fRLOWKoi28DOJcbJYq8/gcHHXKfYy2kEWCjy5DGbfnhFVAbbss4fWtxr5d4ABZONrnBv1CDA
X-Google-Smtp-Source: AGHT+IGtBBLq0vPjpBc6bWOjQqc6kftjS7Q902eBnAIwOfRw9ji+FTcokxJzDySKJMIQMttjXf49uA==
X-Received: by 2002:a17:907:db16:b0:ad2:1a64:79c5 with SMTP id a640c23a62f3a-ad536b579e7mr1634160566b.7.1747745026437;
        Tue, 20 May 2025 05:43:46 -0700 (PDT)
Message-ID: <42ce8b15-90eb-4f54-acb3-81bfe2be7e1e@suse.com>
Date: Tue, 20 May 2025 14:43:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/5] x86/pmstat: Check size of PMSTAT_get_pxstat
 buffers
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
 <20250512144656.314925-2-ross.lagerwall@citrix.com>
 <204e177c-beba-41a1-93bf-3ae6454875cc@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.05.2025 12:53, Ross Lagerwall wrote:
> On Tue, May 13, 2025 at 3:27 PM Jan Beulich  wrote:
>>
>> On 12.05.2025 16:46, Ross Lagerwall wrote:
>>> Check that the total number of states passed in and hence the size of
>>> buffers is sufficient to avoid writing more than the caller has
>>> allocated.
>>>
>>> The interface is not explicit about whether getpx.total is expected to
>>> be set by the caller in this case but since it is always set in
>>> libxenctrl it seems reasonable to check it.
>>
>> Yet if we start checking the value, I think the public header should also
>> be made say so (in a comment).
>>
>>> --- a/xen/drivers/acpi/pmstat.c
>>> +++ b/xen/drivers/acpi/pmstat.c
>>> @@ -103,8 +103,10 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
>>>
>>>          cpufreq_residency_update(op->cpuid, pxpt->u.cur);
>>>
>>> -        ct = pmpt->perf.state_count;
>>> -        if ( copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct*ct) )
>>> +        ct = min_t(uint32_t, pmpt->perf.state_count, op->u.getpx.total);
>>
>> With this, ...
>>
>>> +        if ( ct <= op->u.getpx.total &&
>>
>> ... this is going to be always true, isn't it? Which constitutes a violation
>> of Misra rule 14.3.
>>
>> Also it would be nice if the min_t() could become a normal min(), e.g. by
>> "promoting" op->u.getpx.total to unsigned int via adding 0U. This way it's
>> clear there's no hidden truncation (or else there might be an argument for
>> keeping the check above).
>>
>>> +             copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct * ct) )
>>>          {
>>>              spin_unlock(cpufreq_statistic_lock);
>>>              ret = -EFAULT;
>>
>> Why would you constrain this copy-out but not the one just out of context
>> below here? (The question is of course moot if the condition was dropped.)
>>
> 
> Oh, I had intended this condition to be...
> 
>     if ( ct == op->u.getpx.total &&
> 
> ... based on your previous comment about the difficulties of partially
> copying a 2d array.
> 
>> An option may be to document that this array is copied only when the
>> buffer is large enough.
> 
> I left the other alone since partially copying a 1d array makes sense.

Right, if the relation there becomes == it indeed reflects that the 2-D
one is different in this regard from the 1-D one.

> If you would prefer, I can drop the condition and just let the caller
> deal with the partially copied 2d array?

With the adjusted relation I think all is going to be fine as you
(otherwise) had it. There may want to be a brief comment on that extra
condition you add.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 13:37:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 13:37:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990730.1374656 (Exim 4.92)
	(envelope-from )
	id 1uHNA6-0003wy-Gn; Tue, 20 May 2025 13:37:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990730.1374656; Tue, 20 May 2025 13:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHNA6-0003wr-Bz; Tue, 20 May 2025 13:37:42 +0000
Received: by outflank-mailman (input) for mailman id 990730;
 Tue, 20 May 2025 13:37:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHNA4-0003wl-Ki
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 13:37:40 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 97939fb2-357f-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 15:37:37 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-6020ff8d35dso1310784a12.0
 for ; Tue, 20 May 2025 06:37:37 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-602047c4b73sm1360089a12.10.2025.05.20.06.37.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 06:37: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" 
X-Inumbo-ID: 97939fb2-357f-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747748256; x=1748353056; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=7R6D/GxI7OgZG5KDS3ZKKACfjTPFPi0ygsszjLevS3c=;
        b=EEKERmizVW4My/XBX6kFMNCBVldyCZhGwIX0TZHGMmqpiqzKdjqsRGLxD/nWBrOoO0
         2LPxDxkAMsRgsWT75O6y1b8e9HJugqgjoj4XyW9IMK0NezmFASa4iS+8bA+gkkgIIskM
         sO5jUGwCgw3Iu9QUMdu1Gja5t38RjH6A3O7dfY4SuaGfx404o3m0qYkF0gVuOR/PWpjd
         ZP6R89o8mfRcRVgCq66tVKS/Y9RnlYqi69CTqtRdsjMlJL1H3JWlXdsGjwSkhRv0fILo
         y6gGF+UA3ZexUM/mbYMbuodWCUXBNY4SHH3etTvzUX3aPZB1gFQaW6wSwGgOAJkADdrM
         Ri6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747748256; x=1748353056;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7R6D/GxI7OgZG5KDS3ZKKACfjTPFPi0ygsszjLevS3c=;
        b=glvRsHmyB36AQtxPvkWku57pGFnjYGhOnG5vtAtHNjmaEQqtlXYs4kqfZvug8ztAWO
         QpDfFftHvVN5rfSZbWQnfc15QNkK9zrkDTg6FqsoPzmW8nHVfOXxlemYBJ49WTvWnMsq
         1LNRbLVo5lx0FjytmpofYojkapxv4Qhj9gh4AAXGjFL8/hwNUP+w0FP2UQ+GGnTszNg4
         SOEOwI3u28k+Zgzz+O03CYN9Z2C+MFldqJKnDw3yE/5EgTuAlCl3PlbF0v5vJ2S8X5MJ
         mVK7zkNvjyY32+w6G3BZuF6ESgeWFsSK+mYnGAtQ8Sv7YoQ9aj/MclI/jZ5Es/Vvis7e
         c3kQ==
X-Forwarded-Encrypted: i=1; AJvYcCWqgqLrx8wxgVpPIZDuHx4+yABGQcDdvMLRdD6yD+BEfkkiRf34uUg2RI/th8sm7MQLmgxmXjGhdTQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxsqe0DLA84lRGK6Y1h401hCx7co0g0DXPvaLRfDtMqZt0p3e2Z
	KJeUMKXxTyq/sT8PPGV/mp9Qb0Vq2WYeqU8D3WA+XSIFlJ5W0Cou+uvJCjuSjMiNlg==
X-Gm-Gg: ASbGncugrcZOSdz4uYlfRyOd7zN0gbTwVfbbS5H+WNeB6GNfKcZaabVH4gPnw+exiWr
	K3qkgZf9wfihe3HQY6mOXji8MowzFT9YFqG6jqPTrAYlXBzL9r+oEKliHinZZzfRF0QTHL8EBrD
	m8sjQ4d+AoqOIevuM4yFRis4xo9/66ZvjT6ku7gh7UFgzjrHdpGEXrIrqTeOBXLMgaUCJiHLSHn
	PHBYaeoul8AgchnvSV9mXPlg8x3XuEnOt1hnto+AZlzTs/Y/zQ7FgewLBCyyf9S+2/VgVcc6ThE
	Ptgb+N6kGJNq4LfAVnU7pByOwMoMRAbPb90INWUhqQgwA/Rx6BQhBbL2DxW4v4AH2nNNxgaM
X-Google-Smtp-Source: AGHT+IH871cDPbu2SMCyKdMIJJT+HlgRMOKMoiK64oZ6ngNPe2RrN8CeLB4Mie3wNOuW6H0gAGXBFw==
X-Received: by 2002:a05:6402:4401:b0:5f4:8c80:77d with SMTP id 4fb4d7f45d1cf-6008a5a115emr14669156a12.6.1747748256344;
        Tue, 20 May 2025 06:37:36 -0700 (PDT)
Message-ID: <7ef3ca26-05f5-4e86-b7c7-852b6c74a3d0@suse.com>
Date: Tue, 20 May 2025 15:37:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m
 initialization
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 17:57, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/domain.h
> +++ b/xen/arch/riscv/include/asm/domain.h
> @@ -5,6 +5,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  struct hvm_domain
>  {
>      uint64_t              params[HVM_NR_PARAMS];
> @@ -16,8 +18,12 @@ struct arch_vcpu_io {
>  struct arch_vcpu {
>  };
>  
> +

Nit: As before, no double blank lines please.

>  struct arch_domain {
>      struct hvm_domain hvm;
> +
> +    struct p2m_domain p2m;
> +
>  };

Similarly, no blank lines please at the end of a struct/union/enum.

> --- a/xen/arch/riscv/include/asm/mm.h
> +++ b/xen/arch/riscv/include/asm/mm.h
> @@ -149,6 +149,10 @@ extern struct page_info *frametable_virt_start;
>  #define mfn_to_page(mfn)    (frametable_virt_start + mfn_x(mfn))
>  #define page_to_mfn(pg)     _mfn((pg) - frametable_virt_start)
>  
> +/* Convert between machine addresses and page-info structures. */
> +#define maddr_to_page(ma) mfn_to_page(maddr_to_mfn(ma))
> +#define page_to_maddr(pg) (mfn_to_maddr(page_to_mfn(pg)))

Nit: The outermost parentheses aren't really needed here. Or if you really
want them, then please be consistent and also add them for the other macro
you add.

> --- /dev/null
> +++ b/xen/arch/riscv/p2m.c
> @@ -0,0 +1,168 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +/*
> + * Force a synchronous P2M TLB flush.
> + *
> + * Must be called with the p2m lock held.
> + *
> + * TODO: add support of flushing TLB connected to VMID.
> + */
> +static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
> +{
> +    ASSERT(p2m_is_write_locked(p2m));
> +
> +    /*
> +     * TODO: shouldn't be this flush done for each physical CPU?
> +     *       If yes, then SBI call sbi_remote_hfence_gvma() could
> +     *       be used for that.
> +     */
> +#if defined(__riscv_hh) || defined(__riscv_h)

This is a compiler capability check (which would be applicable if you
used a built-in function below).

> +    asm volatile ( "hfence.gvma" ::: "memory" );

Whereas here you use a feature in the assembler, at least for the GNU
toolchain.

> +static void clear_and_clean_page(struct page_info *page)
> +{
> +    void *p = __map_domain_page(page);
> +
> +    clear_page(p);
> +    unmap_domain_page(p);
> +}

What's the "clean" about in the function name? The "clear" is referring
to the clear_page() call afaict. Also aren't you largely open-coding
clear_domain_page() here?

> +static struct page_info *p2m_get_clean_page(struct domain *d)
> +{
> +    struct page_info *page;
> +
> +    /*
> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
> +     * As explained in Section 18.5.1, for the paged virtual-memory schemes
> +     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
> +     * and must be aligned to a 16-KiB boundary.
> +     */
> +    page = alloc_domheap_pages(NULL, 2, 0);

Shouldn't this allocation come from the domain's P2M pool (which is yet
to be introduced)? Also hard-coding 2 here as order effectively builds
in an assumption that PAGE_SIZE will only ever be 4k. I think to wants
properly calculating instead.

> +    if ( page == NULL )
> +        return NULL;
> +
> +    clear_and_clean_page(page);
> +
> +    return page;
> +}

Contrary to the function name you obtained 4 pages here, which is suitable
for ...

> +static struct page_info *p2m_allocate_root(struct domain *d)
> +{
> +    return p2m_get_clean_page(d);
> +}

... this but - I expect - no anywhere else.

> +static unsigned long hgatp_from_page_info(struct page_info *page_info)

Except for the struct name please drop _info; we don#t use such anywhere
else.

> +{
> +    unsigned long ppn;
> +    unsigned long hgatp_mode;
> +
> +    ppn = PFN_DOWN(page_to_maddr(page_info)) & HGATP_PPN;
> +
> +    /* ASID (VMID) not supported yet */
> +
> +#if RV_STAGE1_MODE == SATP_MODE_SV39
> +    hgatp_mode = HGATP_MODE_SV39X4;
> +#elif RV_STAGE1_MODE == SATP_MODE_SV48
> +    hgatp_mode = HGATP_MODE_SV48X4;
> +#else
> +    #error "add HGATP_MODE"

As before, please have the # of pre-processor directives in the first column.

> +#endif
> +
> +    return ppn | (hgatp_mode << HGATP_MODE_SHIFT);

Use MASK_INSR()?

> +}
> +
> +static int p2m_alloc_table(struct domain *d)
> +{
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +
> +    p2m->root = p2m_allocate_root(d);
> +    if ( !p2m->root )
> +        return -ENOMEM;
> +
> +    p2m->hgatp = hgatp_from_page_info(p2m->root);
> +
> +    /*
> +     * Make sure that all TLBs corresponding to the new VMID are flushed
> +     * before using it.
> +     */
> +    p2m_write_lock(p2m);
> +    p2m_force_tlb_flush_sync(p2m);
> +    p2m_write_unlock(p2m);

While Andrew directed you towards a better model in general, it won't be
usable here then, as the guest didn't run on any pCPU(s) yet. Imo you
want to do a single global flush e.g. when VMIDs wrap around. That'll be
fewer global flushes than one per VM creation.

> +int p2m_init(struct domain *d)
> +{
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int rc;
> +
> +    rwlock_init(&p2m->lock);
> +    INIT_PAGE_LIST_HEAD(&p2m->pages);
> +
> +    p2m->max_mapped_gfn = _gfn(0);
> +    p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);

You don't ever read these two fields. Likely better to introduce them when
they're actually needed. Same possibly for further things done in this
function.

> +    p2m->default_access = p2m_access_rwx;
> +
> +    radix_tree_init(&p2m->p2m_type);
> +
> +#ifdef CONFIG_HAS_PASSTHROUGH
> +    /*
> +     * Some IOMMUs don't support coherent PT walk. When the p2m is
> +     * shared with the CPU, Xen has to make sure that the PT changes have
> +     * reached the memory
> +     */
> +    p2m->clean_pte = is_iommu_enabled(d) &&
> +        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
> +#else
> +    p2m->clean_pte = true;

When there's no IOMMU (in use), doesn't this want to be "false"?

> +#endif
> +
> +    /*
> +     * "Trivial" initialisation is now complete.  Set the backpointer so
> +     * p2m_teardown() and friends know to do something.
> +     */
> +    p2m->domain = d;

And where is that p2m_teardown(), to cross-check the comment against?

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 13:47:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 13:47:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990750.1374665 (Exim 4.92)
	(envelope-from )
	id 1uHNJR-0005fD-Ef; Tue, 20 May 2025 13:47:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990750.1374665; Tue, 20 May 2025 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 1uHNJR-0005f6-Bx; Tue, 20 May 2025 13:47:21 +0000
Received: by outflank-mailman (input) for mailman id 990750;
 Tue, 20 May 2025 13:47:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHNJQ-0005f0-6N
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 13:47:20 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f297f1b0-3580-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 15:47:19 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-601fb2b7884so2955341a12.2
 for ; Tue, 20 May 2025 06:47:19 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ae48253sm7238783a12.81.2025.05.20.06.47.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 06:47: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" 
X-Inumbo-ID: f297f1b0-3580-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747748838; x=1748353638; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=ECeqPWjJfUNJ+dzTBt4oHwmwtG3jXAcMU1nC8SCG4YA=;
        b=caKexp7atJBhKzK4hP09saFksxm9d9wRMzp75O7KJfR5VFS4Y6tGkPBKde6OFqtinF
         wxc8gVWCAYkAKTiZYZLU99TgKjIA3LtyuVsN2BSU9Ne40Y/Yn6Ii/ZXLgpYmk6qczO3l
         fMkVQC7pY8jm6YW3dfwq1FZlubxeojnkptZYlEbMwUhXpVkPOsxqfJNNi5xwP9llqcU0
         kSLLnpgpnFf4Eok51vH3e2pRHWknZO4J57a7TioN1xva3gj9OZYGF4u+l7wnBUSSrKQ9
         lPMnKYiRehyaGr8OJR121reFM+hjcoP8tw+VTkFqjUpwtP6Vrrtwc0uHqFd9Spu21z7J
         GHAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747748838; x=1748353638;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ECeqPWjJfUNJ+dzTBt4oHwmwtG3jXAcMU1nC8SCG4YA=;
        b=T+a6yZhw+xQzcxQ3Xrte97r5clNSgF6qQROOaFSLQrJnfIvE8QwZYSWxWBgXDKFbT7
         rkdtzjNwSm1ce3Q3mOSVpGrQYLMUgBvbUbz1lFyX9fNU7JVcELjPqAHzaoxg+qx93Dr8
         14ClmHidiXEkqtTpYJxL5a7eUDYhCly5kgyEkOvWfzyTP7/BWNagpZagKEDTtH633HQG
         L99PR5dM7RCfuc6ueB8DIKp5BzgSQAKiN/eAyRYL2hokoi7WFr2/FiBv3ScNckX6Qf3t
         4ZKLPehwUgcfVaqcaGRfCcdbSLfCJdHTuBvDQrsoF2awEsReHpYnFkWJEJIef7j9UITN
         z6Qg==
X-Forwarded-Encrypted: i=1; AJvYcCVgxT/uk+ms8TUlRV7KyRRKwwoiijyRNI60ZYmWvWA4UW0n0XqqKw0H4yxXwQWBjm4i1OyBWaNOsKM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzT8XoM4d3/YOJ6hg9qtl+Wcc3I97JBuSEnwkQvAsYEPMGb6fI1
	iDLX4ArciAzfIvJvoGd8u70udMQKdnIYnmvAPiqDTaPrSSF5jHARaR6PUOPNN5TByA==
X-Gm-Gg: ASbGncsHjwM228hKiUynjO5/w2PedKyYiQlD+3s9VG5sba46m1C3LnonCyHp+KKzm4v
	a53a2TdZFPGygGzduRStmy+OMuD/GYAlKwzbHXKea4UBQ06qkeuDRUDL4jJHkTP7ngeFK7u95n0
	LOnVaMsvaWEmSChdc6L8youx3En5saCQRpoqIidSz6E4YidnK2esO62zDnktFYe9w3urFXyjRlX
	YLoNAcFdVLl/WDSQ6mnHmwtBUgGbeUWD03WtvV6AzlUnYE2FTCaMkjHHDfwKYiAm/0XynNiy7An
	qsaIeEe8Z1Y2D31Cq4H7Mv0BEgWT92gzv6GRUdNR4T+M9g/nxASxNRJaJm7we47Q3T+GxzFb
X-Google-Smtp-Source: AGHT+IF1tMWE69pR4HDYLFu4ssmj1q/sPGmjeDoCENklLfhSFlMLQK14BCXxkYVlINiWhfgMvCRWLg==
X-Received: by 2002:a05:6402:d0e:b0:5fa:a42f:70ee with SMTP id 4fb4d7f45d1cf-6010aa99504mr13720867a12.0.1747748838501;
        Tue, 20 May 2025 06:47:18 -0700 (PDT)
Message-ID: <34f5806f-d6c7-46cd-8450-fe578df54648@suse.com>
Date: Tue, 20 May 2025 15:47:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m
 initialization
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Andrew Cooper , xen-devel@lists.xenproject.org
References: 
 <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
 <70186bd9-20b6-48a2-9dd0-25cdc30e81f0@citrix.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12.05.2025 11:24, Oleksii Kurochko wrote:
> On 5/9/25 6:14 PM, Andrew Cooper wrote:
>> On 09/05/2025 4:57 pm, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/p2m.c
>>> @@ -0,0 +1,168 @@
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +/*
>>> + * Force a synchronous P2M TLB flush.
>>> + *
>>> + * Must be called with the p2m lock held.
>>> + *
>>> + * TODO: add support of flushing TLB connected to VMID.
>>> + */
>>> +static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
>>> +{
>>> +    ASSERT(p2m_is_write_locked(p2m));
>>> +
>>> +    /*
>>> +     * TODO: shouldn't be this flush done for each physical CPU?
>>> +     *       If yes, then SBI call sbi_remote_hfence_gvma() could
>>> +     *       be used for that.
>>> +     */
>>> +#if defined(__riscv_hh) || defined(__riscv_h)
>>> +    asm volatile ( "hfence.gvma" ::: "memory" );
>>> +#else
>>> +    asm volatile ( ".insn r 0x73, 0x0, 0x31, x0, x0, x0" ::: "memory" );
>>> +#endif
>> TLB flushing needs to happen for each pCPU which potentially has cached
>> a mapping.
>>
>> In other arches, this is tracked by d->dirty_cpumask which is the bitmap
>> of pCPUs where this domain is scheduled.
> 
> I could only find usage of|d->dirty_cpumask| in x86 and common code (grant
> tables) for flushing the TLB. However, it seems that|d->dirty_cpumask| is
> not set anywhere for ARM. Is it sufficient to set a bit in|d->dirty_cpumask|
> in|startup_cpu_idle_loop()|?

No, how would the idle loop be relevant here? The bit needs setting for any
pCPU a vCPU of the domain is running on, i.e. somewhere in context switch
code.

> In addition, it’s also necessary to set and clear bits in|d->dirty_cpumask|
> during|context_switch|, correct? Set it before switching from the previous
> domain, and clear it after switching to the new domain?
> 
> Also, when a bit is set in|d->dirty_cpumask|, the|v->processor| value is also
> stored in|v->dirty_cpu|. Is this needed to track which processor is
> currently being used for the vCPU?
> 
>> CPUs need to flush their TLBs before removing themselves from
>> d->dirty_cpumask, which is typically done during context switch, but it
>> means that to flush the P2M, you only need to IPI a subset of CPUs.
> 
> I can't find where the P2M flush happens for x86/ARM. Could you please point me
> to where it is handled?

Grep for ept_sync_domain, which will give you several involved functions
(for the Intel, i.e. EPT case).

> Also, I found guest_flush_tlb_mask() for x86. I assume that it is x86 specific
> and generally it is enough to have only flush_tlb_mask(), right?

Yes, that's an x86-specific helper which you may or may not want a
counterpart of.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 13:48:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 13:48:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990757.1374674 (Exim 4.92)
	(envelope-from )
	id 1uHNK3-00068S-ML; Tue, 20 May 2025 13:47:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990757.1374674; Tue, 20 May 2025 13:47:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHNK3-00068J-Jg; Tue, 20 May 2025 13:47:59 +0000
Received: by outflank-mailman (input) for mailman id 990757;
 Tue, 20 May 2025 13:47:58 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHNK2-0005f0-99
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 13:47:58 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20618.outbound.protection.outlook.com
 [2a01:111:f403:2613::618])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0837a347-3581-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 15:47:56 +0200 (CEST)
Received: from PR3PR03MB6412.eurprd03.prod.outlook.com (2603:10a6:102:7d::8)
 by DU2PR03MB7895.eurprd03.prod.outlook.com (2603:10a6:10:2d6::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.31; Tue, 20 May
 2025 13:47:53 +0000
Received: from PR3PR03MB6412.eurprd03.prod.outlook.com
 ([fe80::2887:9068:38f6:8340]) by PR3PR03MB6412.eurprd03.prod.outlook.com
 ([fe80::2887:9068:38f6:8340%6]) with mapi id 15.20.8746.030; Tue, 20 May 2025
 13:47: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" 
X-Inumbo-ID: 0837a347-3581-11f0-a2fa-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XyCIZfCnQtoQUegrDrkQZrbhay7mQFr4R8mkaCQhkd6pZlwo7oILRu7cBzh5T1J774XYg6Gcxo3CwypCt+fhjjqbW1VPrdb1iXSk+cTkeAEwxsh3W8PQSxqKK0A4cWayFOMJ+p1IowN6fKLvbJBfCljHO/nno5aYSZMqZM1fvcShLsu44qMrDj5ZJtBJVLbitPbWQEO+mvbKzE08yjbv25Flr1nwkexbzQqqUlNLx/Q62fKUEW9JWRu8He0cZk2/hKf/m/yjlQ/MbvEfcQGNPSrultsf/89il1Vd+YX+jC6AehyJfPt3f8NpXDFzRXQ9qXNnADZkZWA1/gqdOrkSrw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Gv320cKpVHu9ZqS2VbG6u2IhE8QZWqYFIV6gaZm8cCY=;
 b=WuoStJoNIG5GrikCy3wHaErPATK8fSFhlvRuKWs184Y6L5+x76bB8KHlFaz79xRKoUs1VMKIWBNOaDzFm/wK1QrcgjjXCSPf0aGc2laW0TEOVASW/gNNcJUSyUDtc2KAM90pufRJDy9v7EES4ZgrtA6d4iiYOxhQ6nP3tq09I/aV3Me0db3l21pkUoJ/T4DKtq4kkEC25GfPx3l55kEStOkbx+60iegM0Vh/rJVyz2jRx3WYZ+ctYrriTLUdbBU1Nyt8g9FfR89eXpOPixtsAUbvOnqLfxnI7m0oawYwJaejsMqazm+DoKb1Qioas0aRQe926mafGennOr62CS8znw==
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=Gv320cKpVHu9ZqS2VbG6u2IhE8QZWqYFIV6gaZm8cCY=;
 b=JChDb1biAgE/O1SrAJq5rCF3Pd4PZDXhpdcxA67/EeUOHUaBmbJel+pHl9vFLmlhXCd0aERVs7UFMwdB2KSm216xChyXTqlVDsMJZK8DT4Jje78YCRfEGdNCYwZyrxd8eFiYT2OJLyetHtvfl+4O9rm+2Zd5nkebahkwOh6FpJbd2L18l9+3u1zL10Oi9cDyJoXubG1WaCCfYYfX1qHXssTw+AeSxI0obD29iPBDEH61Nr3RZscGPyXBGD9M8JssgGb5EerNs3atgmXLGC1aHQ0G0h1TNquMWR5TXr4T3v3q7O5CmUiA60ZEiOtX8euSwiqWCfnPGV8A7zpXG5QZOw==
From: Oleksandr Tyshchenko 
To: "xen-devel@lists.xenproject.org" 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk 
Subject: [PATCH] arm/vgic-v3: Fix write_ignore_64's check in
 __vgic_v3_rdistr_rd_mmio_write()
Thread-Topic: [PATCH] arm/vgic-v3: Fix write_ignore_64's check in
 __vgic_v3_rdistr_rd_mmio_write()
Thread-Index: AQHbyY3It6QrN0GxI0mChLdwI1GDxA==
Date: Tue, 20 May 2025 13:47:53 +0000
Message-ID: <20250520134751.1460968-1-oleksandr_tyshchenko@epam.com>
Accept-Language: en-US, ru-RU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PR3PR03MB6412:EE_|DU2PR03MB7895:EE_
x-ms-office365-filtering-correlation-id: efcccdf3-6c3e-48fd-a8e5-08dd97a4eb4a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?Jpq4AqTrpyfJHA2TwT+vNHcGyL452IoamyfxotgOBHiM6qIP219K9tAMom?=
 =?iso-8859-1?Q?hD29FQBHs4ncxc9MvNZt+rOLxrsZiESEeyS5QiAR7DHrGooIiU0MVvnDV6?=
 =?iso-8859-1?Q?ggVe00/zGPDpvi+WCyTbo0hPF5WZnXfNUNNpmsMQ0Ay+XJLrkkNernO3kM?=
 =?iso-8859-1?Q?9bPj161uVIV9UzLRHzPTkG4Bv97CGx0XRb75xcj1U3zzzJ3tPAq4gHnV4P?=
 =?iso-8859-1?Q?KLaEG9Cy3YE+SOcBZcqUh2H7vuU47t6wI/SF4tYWNAg2aDpGLPglIeCgI0?=
 =?iso-8859-1?Q?Wxw2zHw2wU4Z7hCb7MxxBR3sV/U8v2VARGdJ8jDGV+T4gKURvY3CcJ72k9?=
 =?iso-8859-1?Q?csWS5es8Eec26v6y5sbBjg15iVdkSTAQ51QzMZ4my2cyZbc+WUlX+8gIgW?=
 =?iso-8859-1?Q?R/tdFdNxhSk775rEXhVZbtZFf0ZOvQEK5+3N6QLtBYLTcb9CPtZ+sJC5VP?=
 =?iso-8859-1?Q?UCh4FQyYLNBVmeF8B66tGz3zmh4hJgI9KlOdlD1d+dw6lHu6QI+V2z8TwG?=
 =?iso-8859-1?Q?oOgGQ2oS7ZVxlQ4JgMaFxjs0fWaSbrIR2Wm2ptXZ4W9STgQD/ih0VEVuIb?=
 =?iso-8859-1?Q?J7Ms5hYg3QEravNCJfkLFiuzMGbveI91RdHyppu/MvH1yrDt8NYpQUgQC9?=
 =?iso-8859-1?Q?EMPWCBAM1ItXr84LPFoRC4a37t1tK8DS+cbIrJQI05v2x5bfOKZxxbWdq8?=
 =?iso-8859-1?Q?B4WGEORqAvIANhE76yGnHTUSDzXJDEQznXgTx135LZGMSA8b0hqrEU0LPR?=
 =?iso-8859-1?Q?PrWt9UPJa9RKHzR1V6VeTmXV3WcGZfyrY1Pk5mK5/fcVhXDtHYCumUTNPB?=
 =?iso-8859-1?Q?0tPKX10IvOaGKQXXia4g9O5kji6icjMpXK6x3wsqVhErIPdLL6M77lXRpU?=
 =?iso-8859-1?Q?RqBy8/T/kfILyZP9B5xEbrtk8Azh0km9qtpb0I1docEoZ18DhKiF01sMKM?=
 =?iso-8859-1?Q?2P4xP0c6PLVWv8BFVvybMVe7ATtdNZK0+n/wtld3etHPDssCnXwOuUl9LT?=
 =?iso-8859-1?Q?qqzARaIBAB4CL9V/17rD/UzDra5NbyAAeRTfAbZ7QCLM5uw2Y+F2/pWrpk?=
 =?iso-8859-1?Q?1DeGI1DusjzsmWA+GV22nWe06dUnsQv6Yzb8/F1c2FCm2QQpkTJdGuyFsu?=
 =?iso-8859-1?Q?eYUpaBFI67IrAXh1fjQYUJ99Ziagf7SMEZfZ9wIsoK6p0zht6Wkn9U9ueA?=
 =?iso-8859-1?Q?3tIgYs2JsBFqVAgjww6E6+EmAMLMS3rvcsWSWafJ4h1cesAhAIw3iCXj12?=
 =?iso-8859-1?Q?R0SHAMHins+EQRduiDEiFtfBhLDQjzMwBWsD5md0ISkBYrdPsNSGGndUUs?=
 =?iso-8859-1?Q?GbE4fOe+c06iH5VumvmwKHJdGflkEDwyfiIX0hOHnpuhdO8cetqRG6YxXm?=
 =?iso-8859-1?Q?7ZWTHpJQjEvn56n3kSa4mOheoBaIxjNE23JSg4cxxtbuIy+Fz8gBFq1BMk?=
 =?iso-8859-1?Q?R76BsxsGQnLoaIPXN+Yof6j/vZqZ5ZHMLvdILmESVml9cemP6gZUFMKpeN?=
 =?iso-8859-1?Q?BXOA93VIn5rWve2PuV7b5j3x2G2J0BsTN6JMjru1FIM7fOxPLr16FCrIG0?=
 =?iso-8859-1?Q?VLyfgtc=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR03MB6412.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?ZMUdmgI4Ry5fcsgadFSwq6EqIKm593S1x6aS7EZEzdsv5Zks6W5VrMmKQc?=
 =?iso-8859-1?Q?j1QfEexUiV+7L4nR9NeuuFGKmom/flGyh/moYFi2414UzTjT2h3cJV0aUq?=
 =?iso-8859-1?Q?KfGLWSrB9IB8DOd6a5sO5UPCiwuAXgw8ZG10RQXsn0g7yyGKdU7aBPttSH?=
 =?iso-8859-1?Q?aNh1yF+Dn9ZGwcDK3LCkeikvv2yIcYhNWXDbNYgiXMM5b3hlF0QLQPj3je?=
 =?iso-8859-1?Q?jW7Uy9KcSyPcVH0b7dS46nkJF3Thmd0H65XnastgLcqXt5ufx4jujFJIuK?=
 =?iso-8859-1?Q?fg+uop0d91Kj9BPI45riZdU9s+gkf2pD6WeYDjuPCrzP4E2VH/1FOoXUhL?=
 =?iso-8859-1?Q?BgWcJN8RlLvAMO2ZBUeVll8Aqjxe+d/QVqzI5lAGJqFrGeVC3+4BYYHA8G?=
 =?iso-8859-1?Q?+REZDSdMdsTRtLJkb66CXCn8mviJiL53V+lVMqthuw3Ox+EwsispguvZB4?=
 =?iso-8859-1?Q?zrHA/CGfsUg8wznFiJcpMz6DL1x0EJQU1iRANf19s+Km2EqtfCeMv+WYr4?=
 =?iso-8859-1?Q?qNePMrHttGopstpZjI2iRSvMtPB1IXy6eFFY/Mz4WadNfkHryBcoSTXeYa?=
 =?iso-8859-1?Q?SDGiJOmTnBhfp7/ZiHdPiku3HaHiC8dffIjoGna5nH0s8MPLzq1wOyBNg4?=
 =?iso-8859-1?Q?pb+J9q65ihFxK89uQR8L8gqKMnT42c6kxXlV1DW4JRifpefa3+8pFKpTbn?=
 =?iso-8859-1?Q?wMZVw6OvClFVmuF7wbNoQ+5UjqKxjNPePY/4lzjnoJQyLdVL5xuHUrdTe3?=
 =?iso-8859-1?Q?UbC4lLYJx/E2tubPiPpk3SXVpggnDQkSaq0npRgJ59n2K+8zrTDR//9wUr?=
 =?iso-8859-1?Q?7fQrLVqrTeYSw6u29z5lqMNligYj2VG3r/30YViaclb+dGlMRJdq+22/0i?=
 =?iso-8859-1?Q?vMgUJvkZbdL0oXNYNhrRjQwsi4MkfHq4kAIlPMqDkrZA7uI4QrdN1CnM8c?=
 =?iso-8859-1?Q?cApzh+IcIOWuYIsFYz04pTpunaVKFYl5hKMIHah7iPne7U1EHnO1N/EknD?=
 =?iso-8859-1?Q?0ccYli5BjT5KkYiXZ3ByCB8skMztlU4CXL4LPjmwhMK3NDOhO5IqMOY23V?=
 =?iso-8859-1?Q?dpIqscWJWSQY4vpOC/Qqb5jPLdR6TzGiJr1G0agP2Ro7iSegra5aKdSQjB?=
 =?iso-8859-1?Q?Rt7Vla4n//LOzInDcY3A2OfVXelyVI/JVMDGs/OmLBfjXLOQA4sqH8oXsP?=
 =?iso-8859-1?Q?hLYPBGSPVrQ6x7uvlf2y5KGdyuvFGeIrj5uVgTH8kS0BW0dhykRb92cNz9?=
 =?iso-8859-1?Q?BpZwmeO0HOohDbpR4+nc91JWF7YiYzui7f+lMEGFacAEZqDLiN9jd2dS9f?=
 =?iso-8859-1?Q?iWhwrrl3raCCgUzwerWbco3rra/N8jnBBhsXpsbtAvRuhYg8fmDE6PttTL?=
 =?iso-8859-1?Q?OntxOkp3kj8gfXDkpR4gNv/idnUIUVkb9dY6tOHEkgVHox33DCo9mkpFX8?=
 =?iso-8859-1?Q?FkrTitlsiKVzxnXwtA+5sVdisMSyT9obZ8m60DLgtWBmxnyEbA25f/36gl?=
 =?iso-8859-1?Q?mydwdGCCll2ExBkrsRT4xpDxptJWWIEQj3lW8E8FVZlKYwRNYAD76TxJYQ?=
 =?iso-8859-1?Q?buWJBu1cGjw6QO9kAdW3jFV0hIlJK8lyZ2ezbHgGL00cRCwVzx1XG6Qf2l?=
 =?iso-8859-1?Q?jsDSGwo23FEsykcUWKDnyoThTNiPx/nJG4dCAwTNeevryRhPXrP52UVTsB?=
 =?iso-8859-1?Q?PP2pTb0aJKGxCBcRkmo=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: PR3PR03MB6412.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: efcccdf3-6c3e-48fd-a8e5-08dd97a4eb4a
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2025 13:47:53.4049
 (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: OE2tdP94gOaewCoM/GnU7mDbK5vGWZstJASJzUm6AcdkyIUgxSoA2lpsSLRo/U5y1CNoUivpOGCYtR8/5VJCyXDF1ZQITBN1M9IuGebR72U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR03MB7895

An attempt to write access the register (i.e. GICR_PROPBASER, GICR_PENDBASE=
R)
which should be ignored (i.e. no virtual ITS present) causes the data about
due to incorrect check at the write_ignore_64 label. The check should be
inverted.

Fixes: c4d6bbdc12e5 ("xen/arm: vgic-v3: Support 32-bit access for 64-bit re=
gisters")
Signed-off-by: Oleksandr Tyshchenko 
---
 xen/arch/arm/vgic-v3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 2eaa48fadb..b366b046a2 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -649,7 +649,7 @@ bad_width:
     return 0;
=20
 write_ignore_64:
-    if ( vgic_reg64_check_access(dabt) ) goto bad_width;
+    if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
     return 1;
=20
 write_ignore_32:
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue May 20 14:04:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:04:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990769.1374685 (Exim 4.92)
	(envelope-from )
	id 1uHNa1-0000eE-UV; Tue, 20 May 2025 14:04:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990769.1374685; Tue, 20 May 2025 14:04: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 1uHNa1-0000e7-QT; Tue, 20 May 2025 14:04:29 +0000
Received: by outflank-mailman (input) for mailman id 990769;
 Tue, 20 May 2025 14:04:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHNa0-0000e1-Je
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:04:28 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 56d9301f-3583-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 16:04:26 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-601ab204085so4829967a12.1
 for ; Tue, 20 May 2025 07:04:26 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d047bd6sm726813666b.29.2025.05.20.07.04.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 07:04: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" 
X-Inumbo-ID: 56d9301f-3583-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747749866; x=1748354666; darn=lists.xenproject.org;
        h=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;
        bh=2jhLnWq6+SD0fIXj0uBlSfxealwulhmHQoFPgTCb9hY=;
        b=M8p3pQEnrOlcEhwmdR5CByNlvraLRIq+b5f6i4lRX6w5wJ5xNRfhrlR5EFvFiV+ylY
         QcFUUwhpanFJEn0Fsj3mjPe74fyh1LlYjPG+wsvJlazX1eH2NiYEZbihJMGfEfVIqf74
         xgCwoCYJBKam8JXWnbFJagfkO3Z9+bD4yN4YnBsUtYuPSeR+hvkP/pLJmT20uBDV8na0
         nFMGo+l67Y1sEgqZJwCcn5MCQgydZAtGt1QGW8rDAa5bi/KaGGuj9F5YKDRPbKuTYWq8
         5eWu53cizKQZWCco8z1W/k6HOPzRZNf4qIenl40UAic0BE8B8jTeu9QkMIiInvjBdzR0
         8qKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747749866; x=1748354666;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=2jhLnWq6+SD0fIXj0uBlSfxealwulhmHQoFPgTCb9hY=;
        b=TuJOoziVqCBi2KtBKFuWFOlHU1Lw6aDQtDIJMAnTYDGdU+a7QXA92RgUaC4IZVkRw0
         2P0qnCbT3zM+Yg+XVZ+X2o9GCXhNZ0CYcJ9fY8v8+fsTYDkav8o20U5lUqWzINxrN3iq
         Cs7UNgmXQPzmTOTd8c09pdDrt29H7YIBnCkCG6bcfXmcWPL5IiFQwdCAo8ueX4f3knhp
         mRhhLGXVNbmki072+G+MbUHbu/AILSQuQGnY/JzmJLU4kTzivxa3r7IkhgYCYrsLORA4
         IuGt7h2TQkOcz0I4qPCRpatvizjsXMRQMtRX+tPHsJuPGxr+H45b08RrJDw/o0E8m+aV
         JTHg==
X-Forwarded-Encrypted: i=1; AJvYcCXhJp7aN2TK+rEXDmDXrOY4DpY5UyF7elbwNRk7GkGc/U6PTpm9gR6kgW/6hH9L3WR46YbgVPpnUGg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzIqOIWAvC2w4Bmppcl0pZ5qmji3w+mBM5GXpJ4TDITkoSBb4OM
	tpHzgICdTVuatENSS6XOzXPxLGlP5WRaWy0/hMH/HOVotXX7zCN/dRoA
X-Gm-Gg: ASbGncviJtBtm8UNwsIBw/9RzIK3fbEKkFWa+Xlu/vjIjdu4c2vKYNb2isE9n/tkqYl
	N/DrLSLZVC02JdgouG6peq6kOQ4oXy+tdL0kkI4baDlPTGVb1xIEu0TYeibJp0aDrfnxi79gqzJ
	InXpQTRQi42TrStMX1+GOIMH0Usk/JxjPulWY0DZEmdsd8sLt0oDkMppPJr3Agdl+Tt7HWOS4Xq
	svlojhkVDaCZQRo0kz1KaADamM33MmUC9KadxQ7tE5EDI3RQVVoFErFxDMLYyZ+Bssl3yO8e2+U
	PdoZ1HhdoV7pOyrpxpOkDPtiTpsvJMVZEHTEkRBdY1LQXH+8Htm4Xp3hq2B3l6e4kKmlxbx06Se
	f6rRd3gBhHCut96IHPjeubUj3
X-Google-Smtp-Source: AGHT+IF0iI0yEvpM4qJkk/C6GlAf8uXZs9WnuaIZt/MM942zAjTbeBQNh9BjXOypAH54k21p0/9wqg==
X-Received: by 2002:a17:907:1c22:b0:ac7:81b0:62c9 with SMTP id a640c23a62f3a-ad52fa5a6bamr1369528866b.20.1747749865353;
        Tue, 20 May 2025 07:04:25 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------89cKEydznd090tHdpRJslNA1"
Message-ID: <35f6a84a-7dbf-410a-9634-a6edec1b2717@gmail.com>
Date: Tue, 20 May 2025 16:04:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/16] xen/riscv: introduce register_intc_ops() and
 intc_hw_ops.
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <7cd7d3780bb6db45b92c971ff8bcf2634570431f.1746530883.git.oleksii.kurochko@gmail.com>
 <2436be2e-28d4-4e48-a391-84b21651b339@suse.com>
 <9c202b56-ad59-481b-924a-addefcea84cd@gmail.com>
 <0c167d88-798c-46df-a912-60c4252a8e26@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <0c167d88-798c-46df-a912-60c4252a8e26@suse.com>

This is a multi-part message in MIME format.
--------------89cKEydznd090tHdpRJslNA1
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/19/25 3:16 PM, Jan Beulich wrote:
> On 19.05.2025 11:16, Oleksii Kurochko wrote:
>> On 5/15/25 10:06 AM, Jan Beulich wrote:
>>> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>>>> --- a/xen/arch/riscv/include/asm/intc.h
>>>> +++ b/xen/arch/riscv/include/asm/intc.h
>>>> @@ -8,6 +8,8 @@
>>>>    #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
>>>>    #define ASM__RISCV__INTERRUPT_CONTOLLER_H
>>>>    
>>>> +#include 
>>> If you need this include anyway, why ...
>>>
>>>> @@ -17,6 +19,26 @@ struct intc_info {
>>>>        const struct dt_device_node *node;
>>>>    };
>>>>    
>>>> +struct irq_desc;
>>> ... this "forward" decl for something that's then already fully defined?
>>> I can't, however, spot why xen/irq.h would be needed for anything ...
>> forward decl for irq_desc could be really dropped.
>>
>> Inclusion of xen/irq.h was added because of hw_irq_controller which is defined as:
>>     typedef const struct hw_interrupt_type hw_irq_controller;
>>
>> And I'm not sure how to do forward declaration properly in this case. Just use
>> an explicit definition of hw_irq_controller for host_irq_type member of struct
>> intc_hw_operations seems as not the best one option:
>>     struct hw_interrupt_type;
> This isn't needed for the use below.

Shouldn't I tell the compiler that definition of hw_interrupt_type struct exist
somewhere else?

>
>>     struct intc_hw_operations {
>>         ...
>>         // const hw_irq_controller *host_irq_type;
>>         const struct hw_interrupt_type *host_irq_type;
> It might be that something like this is already done elsewhere in the tree,
> so not really an issue imo if a 2nd instance appeared.

It is really happing for several places in x86 code.

>
>> It seems like the best one option is to do the following:
>>     typedef const struct hw_interrupt_type hw_irq_controller; in asm/intc.h.
>> I will follow it then.
> Misra may dislike this.

Then this is not an option. I will use then the option above.

>
>>>> --- a/xen/arch/riscv/intc.c
>>>> +++ b/xen/arch/riscv/intc.c
>>>> @@ -5,6 +5,15 @@
>>>>    #include 
>>>>    #include 
>>>>    
>>>> +#include 
>>>> +
>>>> +static struct __ro_after_init intc_hw_operations *intc_hw_ops;
>>> Nit: Attributes between type and identifier please. Also shouldn't both
>>> this and ...
>>>
>>>> +void __init register_intc_ops(struct intc_hw_operations *ops)
>>> ... the parameter here be pointer-to-const?
>> Then|intc_hw_ops| should also be marked as|const| (with the removal of|__ro_after_init|),
> Why remove the attribute?

My understanding is that if it is marked as 'const' then it automatically mean that it is read-only
always before and after init, so '__ro_after_init' is useless.

>
>> otherwise a compilation error will occur (something like/"assignment discards 'const' qualifier"/).
>>
>> Additionally,|__ro_after_init| should be replaced with|const| for|aplic_ops| in future
>> patches.
> Same question here then.

Just wanted to be in sync. If I have intc_hw_ops marked as const, then the thing which will be used
to set intc_hw_ops wants to be also const.

~ Oleksii

--------------89cKEydznd090tHdpRJslNA1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/19/25 3:16 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 19.05.2025 11:16, Oleksii Kurochko wrote:

    
      
    
        
    On 5/15/25 10:06 AM, Jan Beulich wrote:

    
        
    
          
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
          
    
            
    --- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -8,6 +8,8 @@
  #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
  #define ASM__RISCV__INTERRUPT_CONTOLLER_H
  
+#include <xen/irq.h>

    
          
    
          
    If you need this include anyway, why ...


    
          
    
            
    @@ -17,6 +19,26 @@ struct intc_info {
      const struct dt_device_node *node;
  };
  
+struct irq_desc;

    
          
    
          
    ... this "forward" decl for something that's then already fully defined?
I can't, however, spot why xen/irq.h would be needed for anything ...

    
        
    
        
    forward decl for irq_desc could be really dropped.

Inclusion of xen/irq.h was added because of hw_irq_controller which is defined as:
   typedef const struct hw_interrupt_type hw_irq_controller;

And I'm not sure how to do forward declaration properly in this case. Just use
an explicit definition of hw_irq_controller for host_irq_type member of struct
intc_hw_operations seems as not the best one option:
   struct hw_interrupt_type;

    
      
    
      
    This isn't needed for the use below.
    
    
    
    
    Shouldn't I tell the compiler that definition of hw_interrupt_type struct exist
somewhere else?

    
    
    
      
    

    
      
    
        
       struct intc_hw_operations {
       ...
       // const hw_irq_controller *host_irq_type;
       const struct hw_interrupt_type *host_irq_type;

    
      
    
      
    It might be that something like this is already done elsewhere in the tree,
so not really an issue imo if a 2nd instance appeared.
    
    
    
    
    It is really happing for several places in x86 code.

    
    
    
      
    

    
      
    
        
    It seems like the best one option is to do the following:
   typedef const struct hw_interrupt_type hw_irq_controller; in asm/intc.h.
I will follow it then.

    
      
    
      
    Misra may dislike this.
    
    
    
    
    Then this is not an option. I will use then the option above.


    
    
    
      
    

    
      
    
        
    
          
    
            
    --- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -5,6 +5,15 @@
  #include <xen/init.h>
  #include <xen/lib.h>
  
+#include <asm/intc.h>
+
+static struct __ro_after_init intc_hw_operations *intc_hw_ops;

    
          
    
          
    Nit: Attributes between type and identifier please. Also shouldn't both
this and ...


    
          
    
            
    +void __init register_intc_ops(struct intc_hw_operations *ops)

    
          
    
          
    ... the parameter here be pointer-to-const?

    
        
    
        
    Then|intc_hw_ops| should also be marked as|const| (with the removal of|__ro_after_init|),

    
      
    
      
    Why remove the attribute?
    
    
    
    
    My understanding is that if it is marked as 'const' then it automatically mean that it is read-only
always before and after init, so '__ro_after_init' is useless.

    
    
    
      
    

    
      
    
        
    otherwise a compilation error will occur (something like/"assignment discards 'const' qualifier"/).

Additionally,|__ro_after_init| should be replaced with|const| for|aplic_ops| in future
patches.

    
      
    
      
    Same question here then.
    
    
    
    
    Just wanted to be in sync. If I have intc_hw_ops marked as const, then the thing which will be used
to set intc_hw_ops wants to be also const.

~ Oleksii

    
  


--------------89cKEydznd090tHdpRJslNA1--


From xen-devel-bounces@lists.xenproject.org Tue May 20 14:10:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:10:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990781.1374696 (Exim 4.92)
	(envelope-from )
	id 1uHNfu-0002Cx-LC; Tue, 20 May 2025 14:10:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990781.1374696; Tue, 20 May 2025 14:10: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 1uHNfu-0002Cq-HG; Tue, 20 May 2025 14:10:34 +0000
Received: by outflank-mailman (input) for mailman id 990781;
 Tue, 20 May 2025 14:10:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHNfs-0002Ck-CQ
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:10:32 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2fba2fd0-3584-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 16:10:30 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43ede096d73so40809215e9.2
 for ; Tue, 20 May 2025 07:10:30 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca8d005sm16948991f8f.90.2025.05.20.07.10.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 07:10: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" 
X-Inumbo-ID: 2fba2fd0-3584-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747750229; x=1748355029; 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;
        bh=rQvBy5/uvxRnrI67HKlyK8cxfU/5aJIKUfLdplNBqPA=;
        b=M5nalHEsaCbNcZcQQ5JG8XZtfmpnxO1UE/G4P8XXgfE6XsLym4AcS0EIwrLPjDKmQ9
         KU/3+zE18+i6izMokcecK+IOTBU45w21mz7pMWUq4RPnwb4MlnsLmlz14gKJMSAT58SP
         EnhvM3cVEZ01vL3EUXjG1TkTUSjMvI5kEpA0M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747750229; x=1748355029;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=rQvBy5/uvxRnrI67HKlyK8cxfU/5aJIKUfLdplNBqPA=;
        b=NHoBilEzR1PveNtnsPCTFN+T4QUMBBq0TbpGCzevpW9h3IYK2f9po+0LaQ/8X3+IRQ
         Ezl8QuM49GgUsAGXg0Y88Y6O5kfPalypGQ1ShFV83xc09mxE4+aHP6F5zN6i+mEOpYQs
         8cG2SzjA5zn+KuYqAuSPcQX5op33xdOmJeHzRWJ/EcR62gh4lDDQSf0VdPK3bfenP5hJ
         B8VxbfI7RH5k4kHjjFMxQEHNZ+JvsPn9D9p/abQQVmT0uAEIen0Jk2rPHLWx8CCGMkcU
         We6hSNSHYvklLQ8j+/p43HRcTfex0s9V/N+2PHjd2Taw8Ro7bbd0swg9McPhUjEvGBgW
         x2dA==
X-Gm-Message-State: AOJu0YySf6QZ681qwoerzT7U99WdKH2CqhShI6tH2BipZYJEktKkrDcp
	cp9xzkV0A6kI0KYxE0TvELzdwO7xAloMhGdzs/bIQN+cpvYzNVXT8uV4HVxwruiBTqBgyU6/6Od
	Lu7I3
X-Gm-Gg: ASbGnctWg4vRPJWi3lugd5eer7iQ8ib/lfNYA+0QS7A5uyA+tFvw8br85IdosE2LxYg
	dEwrSMihLdD2/7mJec7TVl13hJgavo7M8C4sv4Bw9I4fO+fRWp6OPvhn1IIbqVHa5Bap/ZGPsN7
	oKivE3ehhehJcmUTP+cOvxFiTiugOI2r4SwN7f/QqWHF1h000Jr/w7AjUzBncyglcMGKZBHxFLD
	hjvfQS09cQE/P0VaWZKORtVPfNwoOndwABS2e+db1GCM0uI+vJH6hv++CrqD1HzPVcyIRU3VcT+
	4UTPOkLLIeoHIkPm5JIg0vzWGFXoTnlDVqNelW43taoK1u0dcNJ9zbaEyGljTXcQLWHSchQ+YLi
	gxh2qSbpRbILknUsAT7LiF6or
X-Google-Smtp-Source: AGHT+IGq8h/wkMmzCSSsvy3CLaFNeudXfSfP73P8rNXb/Za0bjyv2crEYFVegIOAKLxicxtMC9xj3g==
X-Received: by 2002:a05:6000:230a:b0:3a0:9dc2:5e0e with SMTP id ffacd0b85a97d-3a35c835093mr17400899f8f.11.1747750229456;
        Tue, 20 May 2025 07:10:29 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Christopher Clark ,
	"Daniel P . Smith" ,
	Denis Mukhin 
Subject: [PATCH] xen/argo: Command line handling improvements
Date: Tue, 20 May 2025 15:10:27 +0100
Message-Id: <20250520141027.120958-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Treat "argo" on the command line as a positive boolean, rather than requiring
the user to pass "argo=1/on/enable/true".

Move both opt_argo* variables into __ro_after_init.  They're set during
command line parsing and never modified thereafter.

Signed-off-by: Andrew Cooper 
---
CC: Christopher Clark 
CC: Daniel P. Smith 
CC: Denis Mukhin 

Found while
---
 xen/common/argo.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/common/argo.c b/xen/common/argo.c
index cbe8911a4364..027b37b18a6c 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -79,8 +79,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_argo_unregister_ring_t);
 DEFINE_COMPAT_HANDLE(compat_argo_iov_t);
 #endif
 
-static bool __read_mostly opt_argo;
-static bool __read_mostly opt_argo_mac_permissive;
+static bool __ro_after_init opt_argo;
+static bool __ro_after_init opt_argo_mac_permissive;
 
 static int __init cf_check parse_argo(const char *s)
 {
@@ -92,7 +92,10 @@ static int __init cf_check parse_argo(const char *s)
         if ( !ss )
             ss = strchr(s, '\0');
 
-        if ( (val = parse_bool(s, ss)) >= 0 )
+        /* Intepret "argo" as a positive boolean. */
+        if ( *s == '\0' )
+            opt_argo = true;
+        else if ( (val = parse_bool(s, ss)) >= 0 )
             opt_argo = val;
         else if ( (val = parse_boolean("mac-permissive", s, ss)) >= 0 )
             opt_argo_mac_permissive = val;

base-commit: 293abb9e0c5e8df96cc5dfe457c62dfcb7542b19
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue May 20 14:18:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:18:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990790.1374705 (Exim 4.92)
	(envelope-from )
	id 1uHNnE-0002zm-AZ; Tue, 20 May 2025 14:18:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990790.1374705; Tue, 20 May 2025 14:18:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHNnE-0002zf-7o; Tue, 20 May 2025 14:18:08 +0000
Received: by outflank-mailman (input) for mailman id 990790;
 Tue, 20 May 2025 14:18:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHNnD-0002zZ-S0
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:18:07 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3f1f7dae-3585-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 16:18:05 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5efe8d9ebdfso10100274a12.3
 for ; Tue, 20 May 2025 07:18:05 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ae3aed4sm7151768a12.75.2025.05.20.07.18.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 07:18:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3f1f7dae-3585-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747750685; x=1748355485; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=SYxShCMmBaRvXeqwnmM4X/3Bq0aOg/BKzo7yFlkyXjw=;
        b=esdDdwJ+s9BzYu5Pxq1WME72/Zc885SY5twj/IUTkuJPgF0WKyw8je2VezCU9eSA0B
         fhdWNB3b2Jssv9xfrMTRiLcmsxkapUrKxW4eCdHPx1337UhKq1FYQIGMK5MOvuYf7M6i
         557smT+U7pw4vQXV9Lw3XAWnJ0C4VigbvC0evuHWkr9PcvcstGDyMa3CjU9wwXsvI296
         qFXRbcBRaVuc2wF6ABKRJoC8FQjSq6U4ImqBn2prupul3Bpo5aYQGUK6yV81MbWfo8QD
         lAKrcGArcpHg2WqoTSe2ln8SQC1OI5pQMKoe5JnFoCIpdcNUtX+s5+dL4fE8Td4w9jOb
         awxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747750685; x=1748355485;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=SYxShCMmBaRvXeqwnmM4X/3Bq0aOg/BKzo7yFlkyXjw=;
        b=fDMgnP84WpIPYTy8k8sa4jUedknDe524iPt9TOkjmeyK5vEKU5qarY8kg4FgVL5WaJ
         aVhem/4nkGKurdGxVkPKaFSI/rC5rR9+7DHNxNUvQ78E00U14vajOdhdrkI5u0Kuoaoa
         aiFvlrIGg1G1sIginATY0RFDyU1Fda5onTaa3eC2P2cAp46c2koMqo4VR5Mq9np2GmKf
         aW01R/s5tDJA/uma92jO/u+mbAdSVAbORsMmdSP1wBKvgFEV7/u/1bovwR5d4M5yELiX
         NmtUOSF5esoNZgzqDSJC6IKBR4gc00X+Qk1uDAcyfVTdw6F179j2ys+RBzHbxBsCuLkY
         ZyUg==
X-Forwarded-Encrypted: i=1; AJvYcCVQxTU+OYk/4Lu/0lo4Ac4PME0mFJeL5UOeooppbl5w2amrV4sJUqW1hJCal5FBIBeA1cJgp9ufJNU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxMviCOX82PMaY3UioPqb766C/jHkafwhV1tplc0TM74q2vvrLY
	62y+hUcVJgif9Y9B5mHtpvF1K2GePzvgbbLgc8DLsygnkdTdaIaMKOtUNGeojmmfBg==
X-Gm-Gg: ASbGncsXe/TSJG4B1K+WPAGAarByaaWkvjttzm3TZbBurgulKl2zIGy9F6903yJTBB4
	dH7zT6exBPiV6CZl4MMf4D2pibjJq5NFSk6t1a9vBtnwEh7ncPQkUYJMW3h+ivvAykI+rMTzPXG
	DICb3LFteePd8KVPS30QfHBEDiEeSRNaqmrdDtrJqx2JIARMmp2E6WTNOhcLML4USoFRovVKjDs
	9Cq17G/qgcjzI9fJAQDy6V2eXhT2ExftpHCjpuwOSuEeURaY2gjUJlv9zNfn6fKYoHHyVzbN1t8
	13TyuZx3if4zA2mvTfKQW21e+Z2YjVDC8/2NXg1M8CUoPM2+5vo+7Y0qD4d8rA==
X-Google-Smtp-Source: AGHT+IEKNvknPL/jZJ3zF9ccByw3phB/gPen/2hOsA1eaQqRpmd7dh4B+2gYSniGd3T/Lu9jWTNkJw==
X-Received: by 2002:a05:6402:2549:b0:600:7c6:eb28 with SMTP id 4fb4d7f45d1cf-6011407df9emr15550480a12.3.1747750684888;
        Tue, 20 May 2025 07:18:04 -0700 (PDT)
Message-ID: <4fc9832c-394c-4fd5-84a2-e898aae41884@suse.com>
Date: Tue, 20 May 2025 16:18:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/16] xen/riscv: introduce register_intc_ops() and
 intc_hw_ops.
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <7cd7d3780bb6db45b92c971ff8bcf2634570431f.1746530883.git.oleksii.kurochko@gmail.com>
 <2436be2e-28d4-4e48-a391-84b21651b339@suse.com>
 <9c202b56-ad59-481b-924a-addefcea84cd@gmail.com>
 <0c167d88-798c-46df-a912-60c4252a8e26@suse.com>
 <35f6a84a-7dbf-410a-9634-a6edec1b2717@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <35f6a84a-7dbf-410a-9634-a6edec1b2717@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.05.2025 16:04, Oleksii Kurochko wrote:
> On 5/19/25 3:16 PM, Jan Beulich wrote:
>> On 19.05.2025 11:16, Oleksii Kurochko wrote:
>>> On 5/15/25 10:06 AM, Jan Beulich wrote:
>>>> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>>>>> --- a/xen/arch/riscv/include/asm/intc.h
>>>>> +++ b/xen/arch/riscv/include/asm/intc.h
>>>>> @@ -8,6 +8,8 @@
>>>>>    #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
>>>>>    #define ASM__RISCV__INTERRUPT_CONTOLLER_H
>>>>>    
>>>>> +#include 
>>>> If you need this include anyway, why ...
>>>>
>>>>> @@ -17,6 +19,26 @@ struct intc_info {
>>>>>        const struct dt_device_node *node;
>>>>>    };
>>>>>    
>>>>> +struct irq_desc;
>>>> ... this "forward" decl for something that's then already fully defined?
>>>> I can't, however, spot why xen/irq.h would be needed for anything ...
>>> forward decl for irq_desc could be really dropped.
>>>
>>> Inclusion of xen/irq.h was added because of hw_irq_controller which is defined as:
>>>     typedef const struct hw_interrupt_type hw_irq_controller;
>>>
>>> And I'm not sure how to do forward declaration properly in this case. Just use
>>> an explicit definition of hw_irq_controller for host_irq_type member of struct
>>> intc_hw_operations seems as not the best one option:
>>>     struct hw_interrupt_type;
>> This isn't needed for the use below.
> 
> Shouldn't I tell the compiler that definition of hw_interrupt_type struct exist
> somewhere else?

The above decl merely introduces the type into (global) scope. The same is
achieved by ...

>>>     struct intc_hw_operations {
>>>         ...
>>>         // const hw_irq_controller *host_irq_type;
>>>         const struct hw_interrupt_type *host_irq_type;

... this. The case where the earlier decl matters is when a type is used
as a function parameter in a prototype. There, if not previously introduced
into global scope, the scope would be limited to that of the function decl
(and hence a type conflict would result when later the same type is
introduced into global scope).

>>>>> --- a/xen/arch/riscv/intc.c
>>>>> +++ b/xen/arch/riscv/intc.c
>>>>> @@ -5,6 +5,15 @@
>>>>>    #include 
>>>>>    #include 
>>>>>    
>>>>> +#include 
>>>>> +
>>>>> +static struct __ro_after_init intc_hw_operations *intc_hw_ops;
>>>> Nit: Attributes between type and identifier please. Also shouldn't both
>>>> this and ...
>>>>
>>>>> +void __init register_intc_ops(struct intc_hw_operations *ops)
>>>> ... the parameter here be pointer-to-const?
>>> Then|intc_hw_ops| should also be marked as|const| (with the removal of|__ro_after_init|),
>> Why remove the attribute?
> 
> My understanding is that if it is marked as 'const' then it automatically mean that it is read-only
> always before and after init, so '__ro_after_init' is useless.

You need to separate properties of the (pointer type) variable, and what
that pointer points to. __ro_after_init applies to the variable, whereas
the const asked for is to apply to the pointed-to type. (This is more
obvious when you place the attribute as requested. Hence why we want that
particular placement.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 14:23:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:23:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990798.1374715 (Exim 4.92)
	(envelope-from )
	id 1uHNsH-0004jd-T5; Tue, 20 May 2025 14:23:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990798.1374715; Tue, 20 May 2025 14: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 1uHNsH-0004jW-PK; Tue, 20 May 2025 14:23:21 +0000
Received: by outflank-mailman (input) for mailman id 990798;
 Tue, 20 May 2025 14:23:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHNsH-0004jQ-9U
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:23:21 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fa06f145-3585-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 16:23:19 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad56cbc7b07so329754066b.0
 for ; Tue, 20 May 2025 07:23:19 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005a6e6371sm7398914a12.40.2025.05.20.07.23.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 07:23: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" 
X-Inumbo-ID: fa06f145-3585-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747750998; x=1748355798; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=s9jXamqxmpepEYCOpcWsD9OoOtGJnaKzn6cFUix2AbI=;
        b=Dx76K8rA9zwhmeIv2sjRWhXxs3aNkf4pbwpKqpvPN+PSvnad6fpAxpbg6AFyIS6zp4
         2CoJfcaTeLE+P86jamphlhoRGFLw/pnSawgklEmtAbDrijJDfjprXsjz5yTqvq1gcK2F
         TU1sxloKvr+TG2rCKKo6JcRHYely8jycvr1V78RN5duZfUzEXAyCDIeu6QHGRhSE/Aif
         7F1gjIwED2rPHPS6plkCSQaqr/pTU7sDKPtdo8/XmqVcKQlyPMy0OxUPyrt4/AH1O5QV
         n6Q6PJx+R1Lf0cPh2OWPOSId1e92VgV0twq4kIOlcvT/sjrFfkO2jNofjKxu7rFdpWhP
         ErCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747750998; x=1748355798;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=s9jXamqxmpepEYCOpcWsD9OoOtGJnaKzn6cFUix2AbI=;
        b=YmYu50LhiKjc59cVeqnPE9BgAXHLDPe0BjjL7MIB5u3x5uWqEJPyL4zwwGhagviKxp
         ckyWtjwJXL/7vUVfhNl+Ym09bNe+kThjT5VDcmfYAhivS8zDxnbAKkTLTTQCQZs2zx0C
         uTamFJ9lIgRz5VCUncSyHNP90qVMKMvCuXPTlZbTv+nZ3Ujy39VMvGllWuh8nwyzHHzc
         9u8Mz1G24Ieucq99Gsc4swD9NFN6dPtKy32o8qLrhV4TCTh11gqBaYZWRBozraaNxuwD
         I6CGicYFTa1HJZU0AvaSYQVkN6ROTKPmXr3aiaoqJNSxASNloAIwWJLIrxmM4X01oPV3
         gviQ==
X-Forwarded-Encrypted: i=1; AJvYcCW1sKMGHCCHCGy+Tf46wBkIr+2vIVkroHRhdI1v/ic3Ou0ku2DBlrknyiZZJJ33W92tWuUIHMrqWm8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzgZilrMFFMy/Z9orh3R5oEmhEmzRMTJLx8XkkJoqtD+6IBaWZY
	JHGIUoWAeQoAWrhYIxKWjSWPWu7X6KHmOOMDATpzKm3u1WS9MLkh49O3vNp3W+KsZQ==
X-Gm-Gg: ASbGnctvMfP7QWBObiul0LIEv1955dFGnIqp4/2eD1KZqv9EE/odQpfxscozNjy8eiN
	w4uqgyoi9zCK56SzY0T8Z5uEk5yVA91kZLLXep8gG7MDU/NXN0FQtnEBNGJuiD9nKEdTbPkiJYH
	mTG67+FVwfsU4kqZ0fIpzN9Q2x1WIz88uCUvIZk/XNtaxNfa8QS3Z2jgWOUUvIc7G7d+ycX+Qpq
	6u+fyOwdMSRrFeMXQvOThg1GgFYuq3nw89uiSDV34zalTWjmwdVeEZ4K6dwcz8v4xqadPJJeaV4
	QXVuheZIO0Etnaxidcjv1msNgAi+ZIbTdlvBHrK5aT5wCsCwRASIwqVZAVowOw==
X-Google-Smtp-Source: AGHT+IGqTQ1I5Wiepc3G2SUpemeJvIKY+jLjtM7GYUWZPjUlPBJCwsU+HVupWR4bHXNIoeZByV7mSQ==
X-Received: by 2002:a17:907:d8b:b0:ad5:719d:3e88 with SMTP id a640c23a62f3a-ad5719d5958mr710813866b.44.1747750998576;
        Tue, 20 May 2025 07:23:18 -0700 (PDT)
Message-ID: <726c5069-2136-403a-910b-de003129b198@suse.com>
Date: Tue, 20 May 2025 16:23:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] Add lockdown mode
To: Kevin Lampis 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
References: <20250512195628.1728455-3-kevin.lampis@cloud.com>
 <20250520115716.706100-1-kevin.lampis@cloud.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250520115716.706100-1-kevin.lampis@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.05.2025 13:57, Kevin Lampis wrote:
> From: Ross Lagerwall 
> 
> The intention of lockdown mode is to prevent attacks from a rogue dom0
> userspace from compromising the system. Lockdown mode can be controlled by a
> Kconfig option and a command-line parameter. It is also enabled automatically
> when Secure Boot is enabled and it cannot be disabled in that case.
> 
> If enabled from the command-line then it is required to be first in the
> list otherwise Xen may process some insecure parameters before reaching
> the lockdown parameter.
> 
> Signed-off-by: Ross Lagerwall 
> Signed-off-by: Kevin Lampis 
> ---
> Changes in v2:
> - Remove custom command line parsing
> - Print warning if lockdown is not first on command line

No comments on the patch itself (yet), just a formal remark: I was puzzled
by having only v2 2/3 and 3/3 in my inbox. Looks like you sent each as
reply on the v1 sub-threads. Very occasionally for a larger series it may
be okay to send just a single update that way. Here, however, please re-
send as a full, standalone v2 series.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 14:23:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:23:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990801.1374724 (Exim 4.92)
	(envelope-from )
	id 1uHNsf-000596-3b; Tue, 20 May 2025 14:23:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990801.1374724; Tue, 20 May 2025 14:23: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 1uHNsf-00058z-15; Tue, 20 May 2025 14:23:45 +0000
Received: by outflank-mailman (input) for mailman id 990801;
 Tue, 20 May 2025 14:23:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHNsd-0004jQ-VD
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:23:43 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 07e7e35a-3586-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 16:23:42 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ad216a5a59cso797238966b.3
 for ; Tue, 20 May 2025 07:23:42 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4cbe90sm733285366b.165.2025.05.20.07.23.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 07:23: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" 
X-Inumbo-ID: 07e7e35a-3586-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747751022; x=1748355822; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=ZdmLR8LVJAce2rpsLLAGcvCK6hz9bQv1dHblOeRnbJA=;
        b=IO8qYyd7NmPinEhYPlaG8qg0w8zkSJtu7H6aqN8hA7jJ9miuIreyrD6ySNAwRm7fbL
         fL6TqIWxOiZ3elbClyPBJnPAXHnbh5714Phuw362/Xv67i1VV50Fyaj4J2xFfaj5sbZP
         9TfDTyaGwx8FQtAfW4zg7PSpNL7PP5lcK8p5dIxH3OjeiMYvjB74yQ0/ugcwiXDVlRGJ
         j7tV7l5iK5y2CoGMRIoszmOUiVC9X+vp/UF9BGujpzvixkWlT4B2AdFL0wdN+z/1MrRE
         vr1O7hRPhwooVzcIN+xE0DNo49ZSFZZQgLgDLGetCEnSrPI/FnzsK7YTZxrJtOZO714i
         kcZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747751022; x=1748355822;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ZdmLR8LVJAce2rpsLLAGcvCK6hz9bQv1dHblOeRnbJA=;
        b=xCfkLr2tttcJSOudwj4Oa3pQzYZnGmyqaI/28E32oajoFKPT4bZ5+aoYXDEIu7qOvK
         z4wcjXlAPPGIRAmqNp8iYUQ6dsw62yjuQo+FgH3yXmiFIaoFm1BKSM4sGIHSd3UoIfot
         BGby+ncx7RWenJKdlAPfOFBXYwNf9zCbpub6Qkn63Jrvl8WA7hNQH3dufEgqCywMAXBV
         jfsItTYjiYN9r4kxTSL9JLbcOA1BDNL6CfANxTlTXF6//f6qkQbUR3AXoy8UajcuhXSI
         VALT8Nf3Ffn8EOaPpuAxkMX0LFDSlbmQLJptukBPvC3Q9uWa3W8346Ed+A8uBOMMm2uR
         04Fw==
X-Forwarded-Encrypted: i=1; AJvYcCVfyiXpSCg85QkCJWPGR9g1uF8+w3Guj9A0UGDfgoWa7lwhReB8gItQXSeMXiVcf2l/ER+HP/pmOCg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzv+oRb977rKxBqnyk8lWh7TP7W8MuNS3EVsk6ehGaz5l5MAVcK
	u8BrlVeItygv8OH2AF+kgtE35oi2Y4txLZeo2jYWKfxGsnJCrVTDxYYVJPhw4Q==
X-Gm-Gg: ASbGncuiDt5YnsebNTdmCnZp3ljSFPgXjTko7LZ6EHz7vtByK2nHOzAd5zTO/ucGoez
	viX24Jc+KmqalkCdFN39AZ75yuNy76qvrB1MPJt2ZcwZWPSH6pFzVrqDyEdKqM+uGRA2zWn55Ja
	Ms7fkQd7eesijFZyuF/OHeWqr58QozasckqeU5D1E7d49RBmnE+98HX7tnJ/OcwSMGNKQwZ/Eks
	j+WaccV6yrDkvI1bloEYVRe70MwVWjz50ds22Gu0xs4eXhKzXZ75RTmxoO1cyxI0VnTqVOhEKDo
	On/52Itd6n3PPmd/RwNxl51LuHty3TGCLeZRuqZZsgHP4zubBwMF18o1LjteTlSDufN4GkJD5RH
	4dvMU9bYC4cwxqAS0GtFIz5Mv
X-Google-Smtp-Source: AGHT+IHnya3Xgt/9gKQvNLReOaOYfiUJF+Fgain9YBbPS8iFLBZQEROpRRaVbXSOYNgXohb3P6Qf7w==
X-Received: by 2002:a17:907:1b09:b0:acb:b900:2bca with SMTP id a640c23a62f3a-ad52d07636amr1515316266b.0.1747751021507;
        Tue, 20 May 2025 07:23:41 -0700 (PDT)
Message-ID: <4357f6bd-d74a-4439-892a-4ad7735af9e0@gmail.com>
Date: Tue, 20 May 2025 16:23:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 6/6] x86/hvm: reduce the need to flush caches in
 memory_type_changed()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper ,
 xen-devel@lists.xenproject.org, Jan Beulich 
References: <20250516094535.63472-1-roger.pau@citrix.com>
 <20250516094535.63472-7-roger.pau@citrix.com>
  
 <558c7ec2-77ea-42e6-8568-af8b74e19c88@suse.com> 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/19/25 4:33 PM, Roger Pau Monné wrote:
> On Mon, May 19, 2025 at 03:22:32PM +0200, Jan Beulich wrote:
>> On 19.05.2025 13:08, Roger Pau Monné wrote:
>>> On Sun, May 18, 2025 at 01:44:49PM +0200, Jan Beulich wrote:
>>>> On 16.05.2025 11:45, Roger Pau Monne wrote:
>>>>> Not sure whether this attempt to reduce cache flushing should get some
>>>>> mention in the CHANGELOG.
>>>> Err on the side of adding an entry there?
>>> Oleksii would you be fine with me adding:
>>>
>>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>>> index 1ea06524db20..fa971cd9e6ee 100644
>>> --- a/CHANGELOG.md
>>> +++ b/CHANGELOG.md
>>> @@ -11,6 +11,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>>      - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
>>>      - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
>>>    - Linux based device model stubdomains are now fully supported.
>>> + - On x86:
>>> +   - Restrict the cache flushing done in memory_type_changed() to improve
>>> +     performance.
>> Maybe better to mention function names here, saying "after a memory type change
>> by a guest" instead?
> It's not just "after a memory type change by a guest", since
> memory_type_changed() is also used for toolstack operations like
> io{mem,ports}_{permit,deny}_access(), that strictly speaking are not
> memory type changes, neither are done by the guest itself.  I could
> reword to:
>
>     - Restrict the cache flushing done as a result of guest physical
>       memory map manipulations and memory type changes.
>
> Does that sound better?

Acked-By: Oleksii Kurochko 

~ Oleksii




From xen-devel-bounces@lists.xenproject.org Tue May 20 14:25:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:25:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990811.1374735 (Exim 4.92)
	(envelope-from )
	id 1uHNts-0005jb-EG; Tue, 20 May 2025 14:25:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990811.1374735; Tue, 20 May 2025 14:25: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 1uHNts-0005jU-BC; Tue, 20 May 2025 14:25:00 +0000
Received: by outflank-mailman (input) for mailman id 990811;
 Tue, 20 May 2025 14:24:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHNtq-0005jK-NT
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:24:58 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 33a72a8c-3586-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 16:24:55 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-601c5cd15ecso3802589a12.2
 for ; Tue, 20 May 2025 07:24:55 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f1fe4fa6sm32635055e9.16.2025.05.20.07.24.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 07:24: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" 
X-Inumbo-ID: 33a72a8c-3586-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747751095; x=1748355895; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=vukP6mAFAfc2z2Hy2jbrX5ANwFrMXoNMWXcrIYeDrBs=;
        b=os9Kx8gRoxbc8RqNs6XI+SEtiv3xdUgb0NnGoDFDqwaMAw+aeuizvjUBJ6JePJ1SB4
         mxPTWmGjWj+RGp29uzWzk5TRRhuqW33l10zzR6+xnGpdKD1rp4rRVZIjZycf0w115Lpb
         o6xa2V/tAh8q04jQYa28rt0jY+JgYsQYhUzxo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747751095; x=1748355895;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=vukP6mAFAfc2z2Hy2jbrX5ANwFrMXoNMWXcrIYeDrBs=;
        b=pW4LYgPun4RiyKc6EAUR5ZDN+2SatphmhACEXvgS2w9rrM9j5BJGYHreaBtc95+fy2
         /eP2gM2zre5pcoOIPBDaNfpR/wIiLNvMw+1kHz1SNNVOemhnpSxfIw3g7+Sh1EWPIOke
         D63ecWo4QjW6l+54EJ1J7CAJ21Ti+qDpu6/4z+FJTg44N8h2E6SlmdWUk5yAgsM16JBo
         LWh24v4qj70ysfTVsJIu3yVxKgEI+aWwK2Yz+uW8Xkj9sLesJEl7KhL8kfDZxxV55JL6
         37UHi6GuVOkeFP/7ONgNfAGKtY56sBYuMCBEMMTiRMN9ghOv0y3x9vJlOt8OsCPftp7V
         aLWA==
X-Forwarded-Encrypted: i=1; AJvYcCVQw6LiQ/mAiD+9wCChDusm8RP2gRpG+8M1AefH2QfnOOR1hvrVvNRQVxmBgVNdRof4zUajYc7QlmQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxjJj+LJAUc+QsRrYKwn2uFywFQ7bfnxCiOGMMopSriGtvPO7Yf
	pfTQrUiFjMh8MUeqa3PTwqFdBMxVlvrExgebJCnlzmtoN+mP7vtw/D7jXdlgU6f2bUeCI9G/t9o
	s4qf9
X-Gm-Gg: ASbGncvrEHzWvM6awv5KPhxKXuou6n7gxRJ1MRxBvb22dZn3wINKPcRfVO8hTIFovy8
	h0fKdgOtLNJzsKNGCSuxm502uKV1nOt9MjbhAr62Sj5ov4/beDFFto0vgg+VUU1ziQeLZDzPoay
	liNHfANSt4o1WLQtmwxK3r9X/cpin+ApNH4ZNL0MMNGbKcHfIVD0lXBg1J0DuUYEX5n6tmfxIFl
	tapw7ZwLEGn3ftCEwYrFiIbY/mfJs5ZIVOWZ/8r1hCBA0svfch6l8ZAXyRUuAXLO0bP8FOF9Ez/
	h6EYx7Y+tsV0z8/DIku/BEddZ8l9inn4KUTAFaq3Pcv8gc0oc/OoAPLV0eGA6cADVqeSw6NZEnT
	aEkWt+skn2e8MIMOm
X-Google-Smtp-Source: AGHT+IGRScKP989oJnjMGzL0TuMyyhiWGMxYCt8WoRzcsa2lYHP+dQ1qnySGYEoqoTaNcbC7GYjX1Q==
X-Received: by 2002:a05:600c:c1b:b0:43c:e481:3353 with SMTP id 5b1f17b1804b1-442feffbb8dmr186256045e9.17.1747751084368;
        Tue, 20 May 2025 07:24:44 -0700 (PDT)
Message-ID: <26756272-790a-4418-b75e-5052f10319d1@citrix.com>
Date: Tue, 20 May 2025 15:24:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm/vgic-v3: Fix write_ignore_64's check in
 __vgic_v3_rdistr_rd_mmio_write()
To: Oleksandr Tyshchenko ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250520134751.1460968-1-oleksandr_tyshchenko@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: <20250520134751.1460968-1-oleksandr_tyshchenko@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20/05/2025 2:47 pm, Oleksandr Tyshchenko wrote:
> An attempt to write access the register (i.e. GICR_PROPBASER, GICR_PENDBASER)
> which should be ignored (i.e. no virtual ITS present) causes the data about

Do you mean "data abort" here?  If not, I can't parse the sentence.

> due to incorrect check at the write_ignore_64 label. The check should be
> inverted.
>
> Fixes: c4d6bbdc12e5 ("xen/arm: vgic-v3: Support 32-bit access for 64-bit registers")
> Signed-off-by: Oleksandr Tyshchenko 
> ---
>  xen/arch/arm/vgic-v3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index 2eaa48fadb..b366b046a2 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -649,7 +649,7 @@ bad_width:
>      return 0;
>  
>  write_ignore_64:
> -    if ( vgic_reg64_check_access(dabt) ) goto bad_width;
> +    if ( !vgic_reg64_check_access(dabt) ) goto bad_width;

As you're modifying anyway, the goto should be on the next line.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 20 14:26:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:26:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990823.1374744 (Exim 4.92)
	(envelope-from )
	id 1uHNv8-0006Lv-PV; Tue, 20 May 2025 14:26:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990823.1374744; Tue, 20 May 2025 14: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 1uHNv8-0006Lo-Mn; Tue, 20 May 2025 14:26:18 +0000
Received: by outflank-mailman (input) for mailman id 990823;
 Tue, 20 May 2025 14:26:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHNv6-0006Li-Qt
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:26:16 +0000
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com
 [2607:f8b0:4864:20::f2b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 627acc60-3586-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 16:26:14 +0200 (CEST)
Received: by mail-qv1-xf2b.google.com with SMTP id
 6a1803df08f44-6f8d8fb211eso17735276d6.3
 for ; Tue, 20 May 2025 07:26:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 627acc60-3586-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747751174; x=1748355974; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=E1JKAUHFWSui+XeHMlb9MsfSB+pHocjJanzL0Be9ELI=;
        b=cIUySEeax604yUGBYAsZ6owPvtqJg2SZKVgT/W+UBYsPUzQcJvlmRIPufRrKDkJUyD
         AmUoBukP/cRnzdoSBZ6BIoBljTuoTYMrWCSMAgH5zIppOkkmIO7dJXcLCsyiw53fJ5d3
         9FgwHawJK5x2B5tRR8Upv6k2UTQGn/GoQ8Wpw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747751174; x=1748355974;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=E1JKAUHFWSui+XeHMlb9MsfSB+pHocjJanzL0Be9ELI=;
        b=EYANbAE27eyCCSq7jcB4zuHdU4cBSw05ZuolBTATMR0isTD9DXk1oh5ceCZF/juq25
         zD8VmQO+bncQXWDAJOO1B87oVtyjHALbkm3XXtVWG45LkPDF4S3sxm1rBxNgh4ASuaOy
         JSW7peq+Wydj6HFKxUuWpLwAdU58VGmddQqj6stqUqM0wZgNBB06zFRKwdl0xnkSjYfz
         wuRs1mlxTTipun+En0rhwRdM116rd7eiuX0sXRqC8Y5TT5JqJ2bozaSc5MLveeL1q53y
         Cbq+sQ2TtWUBiDdfK7ipq48iAxA5hJgbUS1sBkHUahI4jhUqs88btwZvPEsmC7/h8fjV
         PIDw==
X-Forwarded-Encrypted: i=1; AJvYcCU2aWoxrC+jP3uTyY7+HFe6z2MKCgVod+TdepnoN3WSPXHOozQOGEfDtTlKE12/Ftcl8L5FcTIIOuI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAg+Ni2+vpzBeBX+tGVs0+MLYxTJAvVQgfpmnTwa6ypC/SNeol
	m+UY/HtAsGDAJJUkxg3uuPE+rV57ox3eD9Z6H5OhOb7bb//hMSYGgb7UwEBxqw18SjjRKwHDIiH
	Zee8tfgb5ArQ4/bB9Rb7RSUtwd8PRXIoyneMCgVoxjXHi2E/hUqa2mg==
X-Gm-Gg: ASbGnctMlJfFXCqCOtJr77fnNdzX/yiXjxyRFalTzYG2S0fzaCLK1q9ICMMYNWEArRJ
	NYj333JvupHmy3QWuE/otKAYP8nLrWwjrv5n3e1iZ5w2DxQ1E0u10TFC9rwP0A16xpGqKgh0ew1
	rLqXi+hfTwwUw3HVVa+fSqZtvvFmlNQrlOM02PvV/cTg==
X-Google-Smtp-Source: AGHT+IHxdcPHNWoe4q2z8+xv8KZ4aqsSyV2BXEKTkgjfkUkIUX7h6k04VwkTy8y6Eh7hi4imUnE7cthxPYyId5MeuJo=
X-Received: by 2002:a05:6808:608e:b0:3fe:b1fd:527f with SMTP id
 5614622812f47-404d8616f1emr8733829b6e.1.1747751161606; Tue, 20 May 2025
 07:26:01 -0700 (PDT)
MIME-Version: 1.0
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
 <20250512144656.314925-3-ross.lagerwall@citrix.com> <3128bda3-d655-43ae-81a7-df61928a27aa@suse.com>
In-Reply-To: <3128bda3-d655-43ae-81a7-df61928a27aa@suse.com>
From: Ross Lagerwall 
Date: Tue, 20 May 2025 15:25:50 +0100
X-Gm-Features: AX0GCFvg4rTTBAIA7B3ytMnrxKNunW0_T3HZFPlokMbxJtPceQ5t4AHHfkuq4tk
Message-ID: 
Subject: Re: [PATCH v2 2/5] public/sysctl: Clarify usage of pm_{px,cx}_stat
To: Jan Beulich 
Cc: Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 13, 2025 at 3:43=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 12.05.2025 16:46, Ross Lagerwall wrote:
> > --- a/xen/include/public/sysctl.h
> > +++ b/xen/include/public/sysctl.h
> > @@ -215,23 +215,51 @@ typedef struct pm_px_val pm_px_val_t;
> >  DEFINE_XEN_GUEST_HANDLE(pm_px_val_t);
> >
> >  struct pm_px_stat {
> > -    uint8_t total;        /* total Px states */
> > -    uint8_t usable;       /* usable Px states */
> > -    uint8_t last;         /* last Px state */
> > -    uint8_t cur;          /* current Px state */
> > -    XEN_GUEST_HANDLE_64(uint64) trans_pt;   /* Px transition table */
> > +    /*
> > +     * IN: Number of elements in pt, number of rows/columns in trans_p=
t
> > +     *     (PMSTAT_get_pxstat)
> > +     * OUT: total Px states (PMSTAT_get_max_px, PMSTAT_get_pxstat)
> > +     */
> > +    uint8_t total;
>
> The part for this field ought to go in patch 1, as already indicated ther=
e.
>
> > +    uint8_t usable;       /* OUT: usable Px states (PMSTAT_get_pxstat)=
 */
> > +    uint8_t last;         /* OUT: last Px state (PMSTAT_get_pxstat) */
> > +    uint8_t cur;          /* OUT: current Px state (PMSTAT_get_pxstat)=
 */
> > +    /*
> > +     * OUT: Px transition table. This should have total * total elemen=
ts.
> > +     *      This will not be copied if it is smaller than the hypervis=
or's
> > +     *      Px transition table. (PMSTAT_get_pxstat)
> > +     */
> > +    XEN_GUEST_HANDLE_64(uint64) trans_pt;
> > +    /* OUT: This should have total elements (PMSTAT_get_pxstat) */
> >      XEN_GUEST_HANDLE_64(pm_px_val_t) pt;
>
> As also indicated there, the same constraint as for trans_pt applies to t=
his
> output buffer, just that it's having only one dimension.
>
> >  };
> >
> >  struct pm_cx_stat {
> > -    uint32_t nr;    /* entry nr in triggers & residencies, including C=
0 */
> > -    uint32_t last;  /* last Cx state */
> > -    uint64_aligned_t idle_time;                 /* idle time from boot=
 */
> > -    XEN_GUEST_HANDLE_64(uint64) triggers;    /* Cx trigger counts */
> > -    XEN_GUEST_HANDLE_64(uint64) residencies; /* Cx residencies */
> > -    uint32_t nr_pc;                          /* entry nr in pc[] */
> > -    uint32_t nr_cc;                          /* entry nr in cc[] */
> >      /*
> > +     * IN:  Number of elements in triggers, residencies (PMSTAT_get_cx=
stat)
> > +     * OUT: entry nr in triggers & residencies, including C0
> > +     *      (PMSTAT_get_cxstat, PMSTAT_get_max_cx)
> > +     */
> > +    uint32_t nr;
> > +    uint32_t last;  /* OUT: last Cx state (PMSTAT_get_cxstat) */
> > +    /* OUT: idle time from boot (PMSTAT_get_cxstat)*/
> > +    uint64_aligned_t idle_time;
> > +    /* OUT: Cx trigger counts, nr elements (PMSTAT_get_cxstat) */
> > +    XEN_GUEST_HANDLE_64(uint64) triggers;
> > +    /* OUT: Cx residencies, nr elements (PMSTAT_get_cxstat) */
> > +    XEN_GUEST_HANDLE_64(uint64) residencies;
> > +    /*
> > +     * IN: entry nr in pc[] (PMSTAT_get_cxstat)
> > +     * OUT: Index of highest non-zero entry set in pc[] (PMSTAT_get_cx=
stat)
> > +     */
> > +    uint32_t nr_pc;
> > +    /*
> > +     * IN: entry nr in cc[] (PMSTAT_get_cxstat)
> > +     * OUT: Index of highest non-zero entry set in cc[] (PMSTAT_get_cx=
stat)
> > +     */
>
> For both of these, it's not "highest non-zero" but, according to ...
>
> > +    uint32_t nr_cc;
> > +    /*
> > +     * OUT: (PMSTAT_get_cxstat)
> >       * These two arrays may (and generally will) have unused slots; sl=
ots not
> >       * having a corresponding hardware register will not be written by=
 the
> >       * hypervisor. It is therefore up to the caller to put a suitable =
sentinel
>
> ... this comment, "highest written by hypervisor". They're also not "inde=
x of",
> but "one higher than the index of" (i.e. counts, not indexes).
>

Looking at this again, I don't think that matches what Xen does (nor
does my previous attempt). The code in question:

#define PUT_xC(what, n) do { \
        if ( stat->nr_##what >=3D n && \
             copy_to_guest_offset(stat->what, n - 1, &hw_res.what##n, 1) ) =
\
            return -EFAULT; \
        if ( hw_res.what##n ) \
            nr_##what =3D n; \
    } while ( 0 )

Xen will copy all the hardware registers that it knows about (regardless
of whether the hardware actually has them) and will return in nr_pc /
nr_cc the index + 1 of the highest non-zero entry it _would_ have
written if there is sufficient space.

I could describe it simply as "OUT: Required size of cc[]" ?

Thanks,
Ross


From xen-devel-bounces@lists.xenproject.org Tue May 20 14:34:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:34:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990835.1374755 (Exim 4.92)
	(envelope-from )
	id 1uHO2b-0008FW-HU; Tue, 20 May 2025 14:34:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990835.1374755; Tue, 20 May 2025 14:34: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 1uHO2b-0008FP-Dy; Tue, 20 May 2025 14:34:01 +0000
Received: by outflank-mailman (input) for mailman id 990835;
 Tue, 20 May 2025 14:34:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHO2a-0008FJ-H5
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:34:00 +0000
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com
 [2607:f8b0:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7671bd44-3587-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 16:33:58 +0200 (CEST)
Received: by mail-pl1-x633.google.com with SMTP id
 d9443c01a7336-231f6af929eso41442575ad.2
 for ; Tue, 20 May 2025 07:33:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7671bd44-3587-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1747751636; x=1748356436; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QitXDd875rVowBGx5A/RVuvufVa2CmaSg/+/XeeoSqY=;
        b=Fd8CgE9faPNE0tBoNn85Mg+9CBIOTg/321Cu6Q0eXbDw8CY15e0TvR20CqOiBbLM3+
         F1RO0H9PLeYDrA74xtqkMiwzCg7xLiDiN68nX6RoYDdCqT+0dg1lE8khbFQtwg97n+Vq
         3sYIa5m8fIaq4cJwmryYvML+Bixrikns1FaIM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747751636; x=1748356436;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=QitXDd875rVowBGx5A/RVuvufVa2CmaSg/+/XeeoSqY=;
        b=mVhmQMo26MftB4Ljdpfffqjmqfhsd/Ll4bKN2bj8207p/WroqJKDmieqaUt1MN7GBj
         75m9QC99IUzE8tDiBFMBPrSjJUG+//pBf/pqTeb6FFvbJaqPGXV/X0mt58nEFL2JphNP
         GF86C+V8uBKyWSnqCSAALRtCK09O5GB+DrGGJ0Az+ywhwbr9eMkNsuuZUkQO7o7iTeMW
         qQviqrp9pY1f4mMFDKGaTkX+5/cWJW5jSkCY3+0FGFJomfscSayrV8EuvkpHN6t4kbKY
         igaZQozemK2oxW/6MjMiNFxJr5wCc1t6pjIiCbIvU7VGWjKmseUEbAB3FUKDpHsF9coH
         KmVw==
X-Forwarded-Encrypted: i=1; AJvYcCUccP4KUTK4/WdzMfBREvcpSE/CDvVvsjaYW/OT2ZTeRlLq0jQin5VDzjCZzQ7+XmOgyzerUPkYH+4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxpSKOq7G55tKHpt2kTz+o87i6nEsv2MEQDJXwTef21XENeosCp
	MEU6whPGc6ZH2i4/P6oF2JyQb5G3kenjjR+he8jb84scJVX89vH021p3neEyGmEqpjj4bfVgNmj
	A4wEcHD6EtguGa+hRy99sRPNvDqPfGf+GhCqbV6nj3w==
X-Gm-Gg: ASbGncsUHff5pTwjc4LjJr34OYTTHK9TFT3j0evdscg13qxZQG98GdNM9aV64E6EkJB
	nRCsS0NPNtpnUOviLXz/ob2Ek80RNdDcuZvtaJKLxhMf93ocGdkuJyIOmfwB1hxQFb3gD85c5K3
	zxb10c2rI8ERdepNH8O6arwADJz5HknAo=
X-Google-Smtp-Source: AGHT+IEbMpcXEzAi8BIR9pKqFrhOm+e3uQPvwKTv2Z++644DHk8zGCgDQ79qmsgCZi/L+ku7k8CeedhRsaWYc4AHupU=
X-Received: by 2002:a17:902:cf12:b0:224:2717:7993 with SMTP id
 d9443c01a7336-231d454dcaamr245702275ad.45.1747751636582; Tue, 20 May 2025
 07:33:56 -0700 (PDT)
MIME-Version: 1.0
References: <20250512195628.1728455-3-kevin.lampis@cloud.com>
 <20250520115716.706100-1-kevin.lampis@cloud.com> <726c5069-2136-403a-910b-de003129b198@suse.com>
In-Reply-To: <726c5069-2136-403a-910b-de003129b198@suse.com>
From: Kevin Lampis 
Date: Tue, 20 May 2025 15:33:44 +0100
X-Gm-Features: AX0GCFtieeZ1z235CWoJnFAeC_11lkAsW6vr2yfXuOPs4dLfgWQPhzjcl8g3R2Q
Message-ID: 
Subject: Re: [PATCH v2 2/3] Add lockdown mode
To: Jan Beulich 
Cc: Ross Lagerwall , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 20, 2025 at 3:23=E2=80=AFPM Jan Beulich  wro=
te:
>
> No comments on the patch itself (yet), just a formal remark: I was puzzle=
d
> by having only v2 2/3 and 3/3 in my inbox. Looks like you sent each as
> reply on the v1 sub-threads. Very occasionally for a larger series it may
> be okay to send just a single update that way. Here, however, please re-
> send as a full, standalone v2 series.

Sorry I will do that in future.


From xen-devel-bounces@lists.xenproject.org Tue May 20 14:38:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:38:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990842.1374764 (Exim 4.92)
	(envelope-from )
	id 1uHO6z-0000Oa-0W; Tue, 20 May 2025 14:38:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990842.1374764; Tue, 20 May 2025 14:38: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 1uHO6y-0000OT-Tw; Tue, 20 May 2025 14:38:32 +0000
Received: by outflank-mailman (input) for mailman id 990842;
 Tue, 20 May 2025 14:38:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHO6x-0000OI-F6
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:38:31 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 191daccc-3588-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 16:38:30 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad1f6aa2f84so1107833466b.0
 for ; Tue, 20 May 2025 07:38:30 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d49656bsm740208866b.136.2025.05.20.07.38.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 07:38: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" 
X-Inumbo-ID: 191daccc-3588-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747751910; x=1748356710; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=yJWY8FxySyE47zyNsu5PJeWPggpA1cZSYnZCpQKf/rg=;
        b=ZFo9XUfv5E8kWXrRaIUuWb/M9yn7E1x/5LunDJMPSE2YgpNpx8ILQOcgLoMrMa4oxp
         aZtzmNw9/Ll2wxhAgN7lo1k4Lfh3wA+/yQsJvccHc9R3CkhX5q66zslTw9UOGYgYw/hZ
         9cAgNmoE/UKH9PPcoFkW9BZaei7GvpsaID00AcNy+XNELjYah7rytvNOVMkadI4nx1OM
         GJpKj1GuWrQR/lDNz4YkK6WELHBHn0gWZ5y5jsCodpBzG/pi1oesAtiIJn8lvNuw2yCn
         NiXBnNDcnD7JvZwkbm0YrCicNyYpZ+CHG2mQ6JxDt/5S2EYVIjYeM6PYy29XjLzGs/oj
         56Mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747751910; x=1748356710;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=yJWY8FxySyE47zyNsu5PJeWPggpA1cZSYnZCpQKf/rg=;
        b=oML6I2aCMj/aUYED/nO0/HxQa7gcqckXE2gJwzSpRrGoma+e/JKllsIyEUZOXarqPe
         NkBH6UtWhTwPJTvZAgq7aKaFnfBxhuBssBi1HPIV31bzYU529fT51TwJ6kobkHlt6M33
         96i6m2E6WqVChYeISuUo8y7qc2Vbh/CDD38NfJ6mrciEeVR2dFL5+B1cFJT69EuPx/vD
         l19XmeVf3HmUfTe840c2aNIx0StkG322Bjl1nm7QZWUUMtY/E9hW9ShzPWiPvTFnCOS9
         xUNBAxRPyJIp8vZKnEyP/1xxiknD68vqV7Z4zibYJuyIQZtsrCgOCCmmF5DHZKXeaivr
         ZL5Q==
X-Forwarded-Encrypted: i=1; AJvYcCUMvxSl5lBuMMIEvDsjRFRPTlbiHmHqHXr5e1FfM13yft18Y4tTGSXvgQrU6lrvkROyCRp0P+IfkQM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzVSR4mpIO6IhxavJpl1NInQTeiR61bMarzb6tD5Zmh5eyAHIdR
	EDRSU/5mwRbZjylsVfgpp/7k/yjcwlVU8MyQHDvW0PQ02Msdj/tOVhcpVZLl1FaunA==
X-Gm-Gg: ASbGncsrTvj5GKdkAVekYKtvNjco6md9Jo4cv4ZJQF3faJK9i3BsejAXS+EQ145bU0f
	oiKzFOnVj4kIj5PgNqRU0md4BHM8NMtyBfOyRazYCSy28LV/YiENQAJHnt2hMxq81aYao+F8y8E
	T951aoo4pYh8SF71WuGNLHq7qbWFGzKhXCLOCGgb5287L2lQ014xfGhdZk/d96k1fGC5QYFWjn3
	gl7uMUdqPCsL4UUj2LPmFtF9ZGqTNdj3VIQ+C6t/7IHq4qQRxJfbb0+A4ylBMCr2PrZ6I/h5bGX
	6Zs6EhvP1WQytd8blReGkgHOx4dMJHiNuaEADIs/7hOeQx7O24oXKLqAno+arA==
X-Google-Smtp-Source: AGHT+IGgEmcThuhxBeQ+R/qliZyRZ8dcXMqB7aOo7tWMgNq/O2lEPn16Y5z+hqk9MlcGAM2Mrb2Q8w==
X-Received: by 2002:a17:907:2d87:b0:ad5:8593:2817 with SMTP id a640c23a62f3a-ad5859328abmr389211166b.6.1747751909688;
        Tue, 20 May 2025 07:38:29 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 16:38:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/6] xen/riscv: construct the P2M pages pool for guests
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 17:57, Oleksii Kurochko wrote:
> Implement p2m_set_allocation() to construct p2m pages pool for guests
> based on required number of pages.
> 
> This is implemented by:
> - Adding a `struct paging_domain` which contains a freelist, a
>   counter variable and a spinlock to `struct arch_domain` to
>   indicate the free p2m pages and the number of p2m total pages in
>   the p2m pages pool.
> - Adding a helper `p2m_set_allocation` to set the p2m pages pool
>   size. This helper should be called before allocating memory for
>   a guest and is called from domain_p2m_set_allocation(), the latter
>   is a part of common dom0less code.
> 
> Signed-off-by: Oleksii Kurochko 

As already indicated in reply to patch 2, I expect this pool will want
introducing ahead of that.

> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -1,4 +1,12 @@
>  #include 
> +/*
> + * Because of general_preempt_check() from xen/sched.h which uses
> + * local_events_need_delivery() but latter is declared in .
> + * Thereby it is needed to icnlude  here before xen/sched.h.
> + *
> + * Shouldn't be xen/event.h be included in ?
> + */
> +#include 

The question doesn't belong here; such could be put in the post-commit-
message area. And the answer depends on what dependency you found missing.

> @@ -166,3 +176,60 @@ int p2m_init(struct domain *d)
>  
>      return 0;
>  }
> +
> +/*
> + * Set the pool of pages to the required number of pages.
> + * Returns 0 for success, non-zero for failure.
> + * Call with d->arch.paging.lock held.
> + */
> +int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
> +{
> +    struct page_info *pg;
> +
> +    ASSERT(spin_is_locked(&d->arch.paging.lock));
> +
> +    for ( ; ; )
> +    {
> +        if ( d->arch.paging.p2m_total_pages < pages )
> +        {
> +            /* Need to allocate more memory from domheap */
> +            pg = alloc_domheap_page(d, MEMF_no_owner);
> +            if ( pg == NULL )
> +            {
> +                printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
> +                return -ENOMEM;
> +            }
> +            ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
> +                d->arch.paging.p2m_total_pages + 1;

Looks like you copied this from Arm, but this code is bogus: Using
ACCESS_ONCE() just on the lhs is pretty pointless. Once also used on the
rhs the expression can easily become

                ACCESS_ONCE(d->arch.paging.p2m_total_pages) += 1;

or even

                ACCESS_ONCE(d->arch.paging.p2m_total_pages)++;

.

> +            page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
> +        }
> +        else if ( d->arch.paging.p2m_total_pages > pages )
> +        {
> +            /* Need to return memory to domheap */
> +            pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
> +            if( pg )
> +            {
> +                ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
> +                    d->arch.paging.p2m_total_pages - 1;

Same here then, obviously.

> +                free_domheap_page(pg);
> +            }
> +            else
> +            {
> +                printk(XENLOG_ERR
> +                       "Failed to free P2M pages, P2M freelist is empty.\n");
> +                return -ENOMEM;
> +            }
> +        }
> +        else
> +            break;
> +
> +        /* Check to see if we need to yield and try again */
> +        if ( preempted && general_preempt_check() )

While it's this way on both Arm and x86, I wonder how useful it is
to check on every iteration, especially when freeing pages back to the
buddy allocator.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 14:47:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:47:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990850.1374775 (Exim 4.92)
	(envelope-from )
	id 1uHOFr-0002BI-Qy; Tue, 20 May 2025 14:47:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990850.1374775; Tue, 20 May 2025 14:47:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHOFr-0002BB-OH; Tue, 20 May 2025 14:47:43 +0000
Received: by outflank-mailman (input) for mailman id 990850;
 Tue, 20 May 2025 14:47:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHOFq-0002B5-Ai
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:47:42 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 61791ca1-3589-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 16:47:41 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-601dd3dfc1fso5117602a12.0
 for ; Tue, 20 May 2025 07:47:41 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005a6e745fsm7438020a12.48.2025.05.20.07.47.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 07: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" 
X-Inumbo-ID: 61791ca1-3589-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747752460; x=1748357260; darn=lists.xenproject.org;
        h=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;
        bh=mrhiPc8Ka/ZtSTSLuKC5MJ6q3OZ5I/K5zPd8dWqr9gg=;
        b=eX+8q1gitaa0LwU+691FfjtB+cEDrxlKg8in+BZ5bgCBSsg4PR+vnjVImLXPxUyvq0
         dGoR4xoVxLiNmQmRysojZbVzO//41reARRJy3Q6c3k0ZaMXCIMFXY7IwnJXZfYd61Bbj
         0K4vtRV8jwD23cENgiC9pT5Vp7XRCZUfLxlBQulqJOfTFjIMFxButORA7dv7UAMr1kwY
         b1/FEDtXj2sSdwCfYIePXq7PhkQjO9j2l38ocnCWfzh7Jfsd7D91ZXA2tt8rnJYvkcF8
         3t+HlYqLVcBhxe1QxvLtNmAG9YvJ0ApMS/8jgjFhC8ST1HtPLaAjJ/H4W7DrJP57OSVE
         D5sQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747752460; x=1748357260;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=mrhiPc8Ka/ZtSTSLuKC5MJ6q3OZ5I/K5zPd8dWqr9gg=;
        b=A4Y81ptczoO5hlwuEhg2THBj4O0zvvAeGd7RQC6IchDV6KYTSK7cgSdD+5XdRvQXfB
         jlN/tF730LRzWBevg4z4Sikaksdh+xcLmTHJeigC7rLLEs8NMbqj4whB5HmkIUutrzv0
         3TQLfWSFK5wWDNOo0R/LdX/xlvJ74aMvX6b9FOf9rnnSi45mNWZcmzZfiNWMtufx5dfe
         hwWCCc3lpwnT1ENqPCx0WNaHhJZXnYTrAg0W24Kvjge/EV5V4ASs5c3aemuI0b7YMjWe
         3rfA8dU7XuzIRhmVLGItXXdW8qff3YIb7EQnuCkzyfSIq1NR+b+qA+++OY5+c1bb+54G
         YorA==
X-Forwarded-Encrypted: i=1; AJvYcCXN6KMA6QcU0+YMJ/GulbU+vpbIq7rjAkMMyZVAO8mzY+3m3w64roKBJ8cS7njV6Z+sXyG0VYRYy68=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw0s5XvTrrXeDDb1f0vqQlJv1bIkNCl0G8I+jmRQVCpM4CbmXIv
	F5h15RLAFYsQXlIvze8gev5nH3zmRjao8HJ9JI9lOrxmdo+Zrpyfow2J
X-Gm-Gg: ASbGncsWN0oG3AXTteXmzIcLbXdNqEbm54W3P59weIX1+gc9+92EuhGZHV2n4avwpqI
	LdSAAJ+OZvcrUsGkKiHXPkD/ZD8jMJdt7N5722uLtHqVVz0WG73bEpslkYR3hG4ITkusyMQTc6s
	A2RGJsDzwZNwu9YfN0N7h/g+qqp3piPbAAv3xltP0kVnrZ0rWTSIBHdw9DJm+ekWSeCGegWU7Ha
	ozrLBpn+1Gkg7qIYtqrLBDuzlX0G+QGRCwZxNVVBmMpRfmpPH8vS0i66ukSVHsvI0Wq2n4oYO3U
	jxlxzZhWpbxHwCC/Cx5lrmsquY21S9MI5SG0nroTbmzQZO3MZgZGQMXorI18bPqem2JESNcahRQ
	Rxj3ciNFB1aNQeHCPmdM3iknY
X-Google-Smtp-Source: AGHT+IHBCNIQos0MD5pcbzVkGAMgT1mkz0PmAchHufnOE77GzQmmk+VgkZcKHZjK6JZy7d3Ths+pDg==
X-Received: by 2002:a05:6402:51c9:b0:600:1167:7333 with SMTP id 4fb4d7f45d1cf-60114099a62mr13465221a12.10.1747752460179;
        Tue, 20 May 2025 07:47:40 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------qNkDgV45ys52CSppKkGk0Cz6"
Message-ID: <84a12bd8-bf55-4dca-8f9b-38ff6f5547d3@gmail.com>
Date: Tue, 20 May 2025 16:47:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/16] xen/riscv: imsic_init() implementation
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
 <0d9a9a9e-3454-465f-ac1d-cd65ba4a5792@suse.com>
 <52c0be11-7c8e-4e12-9005-3a7ca7f12c43@gmail.com>
 <81c9f5f5-b5bb-4f3b-9993-dfca54f212c5@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <81c9f5f5-b5bb-4f3b-9993-dfca54f212c5@suse.com>

This is a multi-part message in MIME format.
--------------qNkDgV45ys52CSppKkGk0Cz6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/19/25 8:32 PM, Jan Beulich wrote:
> On 19.05.2025 17:19, Oleksii Kurochko wrote:
>> On 5/15/25 10:42 AM, Jan Beulich wrote:
>>> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>>>> --- /dev/null
>>>> +++ b/xen/arch/riscv/include/asm/imsic.h
>>>> @@ -0,0 +1,65 @@
>>>> +/* SPDX-License-Identifier: MIT */
>>>> +
>>>> +/*
>>>> + * xen/arch/riscv/imsic.h
>>>> + *
>>>> + * RISC-V Incoming MSI Controller support
>>>> + *
>>>> + * (c) 2023 Microchip Technology Inc.
>>>> + */
>>>> +
>>>> +#ifndef ASM__RISCV__IMSIC_H
>>>> +#define ASM__RISCV__IMSIC_H
>>>> +
>>>> +#include 
>>>> +
>>>> +#define IMSIC_MMIO_PAGE_SHIFT   12
>>>> +#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
>>>> +
>>>> +#define IMSIC_MIN_ID            63
>>> This isn't the "minimum ID", but the "minimum permissible number of IDs" as per
>>> its first use in imsic_parse_node(). Further uses there consider it a mask,
>>> which makes me wonder whether the imsic_cfg.nr_ids field name is actually
>>> correct: Isn't this the maximum valid ID rather than their count/number?
>> imsic_cfg.nr_ids it is a value of interrupt identities supported by IMSIC interrupt file according to
>> DT binding:
>>     riscv,num-ids:
>>       $ref: /schemas/types.yaml#/definitions/uint32
>>       minimum: 63
>>       maximum: 2047
>>       description:
>>         Number of interrupt identities supported by IMSIC interrupt file.
> Unless this count accounts for 0 being invalid (and hence isn't counted), I'm
> still confused: With the maximum value this would mean 2046 is still valid,
> but 2047 isn't anymore. When normally such a boundary would be at an exact
> power of 2, i.e. between 2047 and 2048 here.

2047 is inclusive according to the AIA spec:
   The number of interrupt identities supported by an interrupt file
   (and hence the number of active bits in each array) is one less than a multiple
   of 64, and may be a minimum of 63 and a maximum of 2047.
   ...
   When an interrupt file supports N distinct interrupt identities,
   valid identity numbers are between 1 and N inclusive.
   The identity numbers within this range are said to be implemented by the interrupt
   file; numbers outside this range are not implemented.
   The number zero is never a valid interrupt identity. Identity 0 is just ignored.

It is still  not a power of two but it was the AIA spec tells us.

Also, this maximum identity number of 2047 is consistent with related fields like
the EIID (External Interrupt Identity) field used in APLICs when forwarding MSIs,
which specifies the MSI data value that becomes the minor identity at the target
hart's interrupt file.
The EIID field is typically an 11-bit field, able to hold values from 0 through
2047.
Since identity 0 is invalid, the entire range of valid identity numbers (1-2047)
fits within the values representable by an 11-bit field.

~ Oleksii

--------------qNkDgV45ys52CSppKkGk0Cz6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/19/25 8:32 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 19.05.2025 17:19, Oleksii Kurochko wrote:

    
      
    
        
    On 5/15/25 10:42 AM, Jan Beulich wrote:

    
        
    
          
    On 06.05.2025 18:51, Oleksii Kurochko wrote:

    
          
    
            
    --- /dev/null
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/imsic.h
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) 2023 Microchip Technology Inc.
+ */
+
+#ifndef ASM__RISCV__IMSIC_H
+#define ASM__RISCV__IMSIC_H
+
+#include <xen/types.h>
+
+#define IMSIC_MMIO_PAGE_SHIFT   12
+#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
+
+#define IMSIC_MIN_ID            63

    
          
    
          
    This isn't the "minimum ID", but the "minimum permissible number of IDs" as per
its first use in imsic_parse_node(). Further uses there consider it a mask,
which makes me wonder whether the imsic_cfg.nr_ids field name is actually
correct: Isn't this the maximum valid ID rather than their count/number?

    
        
    
        
    imsic_cfg.nr_ids it is a value of interrupt identities supported by IMSIC interrupt file according to
DT binding:
   riscv,num-ids:
     $ref: /schemas/types.yaml#/definitions/uint32
     minimum: 63
     maximum: 2047
     description:
       Number of interrupt identities supported by IMSIC interrupt file.

    
      
    
      
    Unless this count accounts for 0 being invalid (and hence isn't counted), I'm
still confused: With the maximum value this would mean 2046 is still valid,
but 2047 isn't anymore. When normally such a boundary would be at an exact
power of 2, i.e. between 2047 and 2048 here.
    
    
    
    
    2047 is inclusive according to the AIA spec:
  The number of interrupt identities supported by an interrupt file
  (and hence the number of active bits in each array) is one less than a multiple
  of 64, and may be a minimum of 63 and a maximum of 2047.
  ...
  When an interrupt file supports N distinct interrupt identities,
  valid identity numbers are between 1 and N inclusive.
  The identity numbers within this range are said to be implemented by the interrupt
  file; numbers outside this range are not implemented.
  The number zero is never a valid interrupt identity. Identity 0 is just ignored.

It is still  not a power of two but it was the AIA spec tells us.

    Also, this maximum identity number of 2047 is consistent with related fields like
the EIID (External Interrupt Identity) field used in APLICs when forwarding MSIs,
which specifies the MSI data value that becomes the minor identity at the target
hart's interrupt file.
The EIID field is typically an 11-bit field, able to hold values from 0 through
2047.
Since identity 0 is invalid, the entire range of valid identity numbers (1-2047)
fits within the values representable by an 11-bit field.

~ Oleksii

    
  


--------------qNkDgV45ys52CSppKkGk0Cz6--


From xen-devel-bounces@lists.xenproject.org Tue May 20 14:50:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:50:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990860.1374785 (Exim 4.92)
	(envelope-from )
	id 1uHOIA-0003bH-C3; Tue, 20 May 2025 14:50:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990860.1374785; Tue, 20 May 2025 14:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHOIA-0003bA-7i; Tue, 20 May 2025 14:50:06 +0000
Received: by outflank-mailman (input) for mailman id 990860;
 Tue, 20 May 2025 14:50:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHOI8-0003K8-Tk
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:50:04 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b5e3c749-3589-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 16:50:02 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-601f1914993so3424553a12.0
 for ; Tue, 20 May 2025 07:50:02 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d4f1ca8sm7305830a12.6.2025.05.20.07.50.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 07:50:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b5e3c749-3589-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747752602; x=1748357402; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=OsD37B8v/4hF2NDy+8qnJjAIlwwXacx2ZFwooaBKCqQ=;
        b=H3Zu5tj3hHmiuXvDUOGdUd5xCra8V3rz+jP/cN0wAMFgiWmOC83pHNaEQfkyiVEYUu
         d7j3wIgwF6YZQqKfqD6kKfVpZ41ZT2Uz1d0Z+Wm0j13Uk5h7mrdCdXlhUC6EHlJrMKu1
         Bq5K4ctaE1EGIY+MIXkR4MmHKuKEXax82E1poOJ9/Txbzl7Jz71OCJDyELJiNLTasMGs
         79yDNwIDcXP6ApMNjYSfEVte5TyNnq6tftvgI9cmrZCylefEJQSIMvC6xjYhQVzvy2/b
         fiMmskSQ3EnORLxAcHu0EcyFQ8zN30AO085ILsOrdePSavTNA0dscjGjoPrAai6Qy6IO
         Qefw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747752602; x=1748357402;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=OsD37B8v/4hF2NDy+8qnJjAIlwwXacx2ZFwooaBKCqQ=;
        b=fft/GMahWatU9Sjl0Ixh35Syoh8g4Ucj9oSJTkp0J8hlr/6wXo0hrgr/HyvhMMW+Yw
         ccK/6/mHDMEqegfSPehRTcVBMHZ86Cr79R3alLYbrGYiQvgIGWvoVVO8uS4nfnGyebtB
         Tlae6kvXHldk+ljp/6kxY7B5vDVvAYTp93X/gQcH3kwFqXP9s+TIkoyEoHbAwvYf5FBI
         Gfb3iuEWk5/dCijrvgCC8wzvevkXcYoRt2RW4HM6T1n/AwGn/+Magk75RXxw0XcACfGM
         29yIu55p6WrOMBrA7PHRpVQGzt1an9nyZd/MslUGe4tGlqpm4TS332SzVOcPdzK6tmVw
         NmJA==
X-Forwarded-Encrypted: i=1; AJvYcCU3fpBQIjTB8CPZXHleA3a/yImcIVG5prUZ4xdGq5WLIazg9taU1UjKlGeXvBMxry62uf0xUomHOag=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwueighO0Xmv5aooRjYLN2UMfwfp55lEAJC0pFNhJqif7AKETGS
	xsxNHTGRpCHyABylMFpCJxVOh2Mff3s3GbkSlCWf1saQMLKxGIKIGkJq9hVNlHvqzw==
X-Gm-Gg: ASbGnctBoy/UoBZVTSAMU1ZUj3K6WCdqfHK6B5NI4hOOYluGbpO/b8EVuBjfoC85CSi
	YG3ROkfd+wdj6jG4Ep3o/V4kzst2rLlS9CoQ5K0eYapCq6TvE5VIQQPVWTOfKcUjVY1sBIWS6yK
	I8sii5y4haAT+h6alrKysjTdwqa0VQgfadBEhAt/4JzN0gJL9NFqxCvrAYZ3AniS4afeuLiCBrX
	yq8swBO8iHhWZS1xKsfzWmnwu5zQY8z3ZcU8WNRM0ZzViThP7RRqYi8YENpD/9AuaPsrF3dKTdh
	Aqnkd+YzrrlqjbPRMYLSc6DJF20Pp4CvMadkaK9MOzDasaXilnfMw7J2wJXxew==
X-Google-Smtp-Source: AGHT+IFg9o5sgnbz2y3cjjCxqkbb7WsYIjXM+F7+lLsSnae6wq4tnMkIvNtlboQdp+2I7DYlh9x7lQ==
X-Received: by 2002:a05:6402:35c5:b0:602:29e0:5e24 with SMTP id 4fb4d7f45d1cf-60229e06128mr264066a12.0.1747752602248;
        Tue, 20 May 2025 07:50:02 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 16:50:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/5] public/sysctl: Clarify usage of pm_{px,cx}_stat
To: Ross Lagerwall 
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: <20250512144656.314925-1-ross.lagerwall@citrix.com>
 <20250512144656.314925-3-ross.lagerwall@citrix.com>
 <3128bda3-d655-43ae-81a7-df61928a27aa@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.05.2025 16:25, Ross Lagerwall wrote:
> On Tue, May 13, 2025 at 3:43 PM Jan Beulich  wrote:
>>
>> On 12.05.2025 16:46, Ross Lagerwall wrote:
>>> --- a/xen/include/public/sysctl.h
>>> +++ b/xen/include/public/sysctl.h
>>> @@ -215,23 +215,51 @@ typedef struct pm_px_val pm_px_val_t;
>>>  DEFINE_XEN_GUEST_HANDLE(pm_px_val_t);
>>>
>>>  struct pm_px_stat {
>>> -    uint8_t total;        /* total Px states */
>>> -    uint8_t usable;       /* usable Px states */
>>> -    uint8_t last;         /* last Px state */
>>> -    uint8_t cur;          /* current Px state */
>>> -    XEN_GUEST_HANDLE_64(uint64) trans_pt;   /* Px transition table */
>>> +    /*
>>> +     * IN: Number of elements in pt, number of rows/columns in trans_pt
>>> +     *     (PMSTAT_get_pxstat)
>>> +     * OUT: total Px states (PMSTAT_get_max_px, PMSTAT_get_pxstat)
>>> +     */
>>> +    uint8_t total;
>>
>> The part for this field ought to go in patch 1, as already indicated there.
>>
>>> +    uint8_t usable;       /* OUT: usable Px states (PMSTAT_get_pxstat) */
>>> +    uint8_t last;         /* OUT: last Px state (PMSTAT_get_pxstat) */
>>> +    uint8_t cur;          /* OUT: current Px state (PMSTAT_get_pxstat) */
>>> +    /*
>>> +     * OUT: Px transition table. This should have total * total elements.
>>> +     *      This will not be copied if it is smaller than the hypervisor's
>>> +     *      Px transition table. (PMSTAT_get_pxstat)
>>> +     */
>>> +    XEN_GUEST_HANDLE_64(uint64) trans_pt;
>>> +    /* OUT: This should have total elements (PMSTAT_get_pxstat) */
>>>      XEN_GUEST_HANDLE_64(pm_px_val_t) pt;
>>
>> As also indicated there, the same constraint as for trans_pt applies to this
>> output buffer, just that it's having only one dimension.
>>
>>>  };
>>>
>>>  struct pm_cx_stat {
>>> -    uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
>>> -    uint32_t last;  /* last Cx state */
>>> -    uint64_aligned_t idle_time;                 /* idle time from boot */
>>> -    XEN_GUEST_HANDLE_64(uint64) triggers;    /* Cx trigger counts */
>>> -    XEN_GUEST_HANDLE_64(uint64) residencies; /* Cx residencies */
>>> -    uint32_t nr_pc;                          /* entry nr in pc[] */
>>> -    uint32_t nr_cc;                          /* entry nr in cc[] */
>>>      /*
>>> +     * IN:  Number of elements in triggers, residencies (PMSTAT_get_cxstat)
>>> +     * OUT: entry nr in triggers & residencies, including C0
>>> +     *      (PMSTAT_get_cxstat, PMSTAT_get_max_cx)
>>> +     */
>>> +    uint32_t nr;
>>> +    uint32_t last;  /* OUT: last Cx state (PMSTAT_get_cxstat) */
>>> +    /* OUT: idle time from boot (PMSTAT_get_cxstat)*/
>>> +    uint64_aligned_t idle_time;
>>> +    /* OUT: Cx trigger counts, nr elements (PMSTAT_get_cxstat) */
>>> +    XEN_GUEST_HANDLE_64(uint64) triggers;
>>> +    /* OUT: Cx residencies, nr elements (PMSTAT_get_cxstat) */
>>> +    XEN_GUEST_HANDLE_64(uint64) residencies;
>>> +    /*
>>> +     * IN: entry nr in pc[] (PMSTAT_get_cxstat)
>>> +     * OUT: Index of highest non-zero entry set in pc[] (PMSTAT_get_cxstat)
>>> +     */
>>> +    uint32_t nr_pc;
>>> +    /*
>>> +     * IN: entry nr in cc[] (PMSTAT_get_cxstat)
>>> +     * OUT: Index of highest non-zero entry set in cc[] (PMSTAT_get_cxstat)
>>> +     */
>>
>> For both of these, it's not "highest non-zero" but, according to ...
>>
>>> +    uint32_t nr_cc;
>>> +    /*
>>> +     * OUT: (PMSTAT_get_cxstat)
>>>       * These two arrays may (and generally will) have unused slots; slots not
>>>       * having a corresponding hardware register will not be written by the
>>>       * hypervisor. It is therefore up to the caller to put a suitable sentinel
>>
>> ... this comment, "highest written by hypervisor". They're also not "index of",
>> but "one higher than the index of" (i.e. counts, not indexes).
>>
> 
> Looking at this again, I don't think that matches what Xen does (nor
> does my previous attempt). The code in question:
> 
> #define PUT_xC(what, n) do { \
>         if ( stat->nr_##what >= n && \
>              copy_to_guest_offset(stat->what, n - 1, &hw_res.what##n, 1) ) \
>             return -EFAULT; \
>         if ( hw_res.what##n ) \
>             nr_##what = n; \
>     } while ( 0 )

Right. I should have inserted "that could be" in my reply.

> Xen will copy all the hardware registers that it knows about (regardless
> of whether the hardware actually has them) and will return in nr_pc /
> nr_cc the index + 1 of the highest non-zero entry it _would_ have
> written if there is sufficient space.

Which is kind of bogus when the last (or more) of those would merely be
zero.

> I could describe it simply as "OUT: Required size of cc[]" ?

Maybe append something like "..., for all known to Xen entries to be
written"? Provided we don't want to change the behavior anyway.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 14:53:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 14:53:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990870.1374795 (Exim 4.92)
	(envelope-from )
	id 1uHOLN-0004Zg-OK; Tue, 20 May 2025 14:53:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990870.1374795; Tue, 20 May 2025 14:53: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 1uHOLN-0004ZZ-L8; Tue, 20 May 2025 14:53:25 +0000
Received: by outflank-mailman (input) for mailman id 990870;
 Tue, 20 May 2025 14:53:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHOLM-0004ZT-7B
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 14:53:24 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2d7a6875-358a-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 16:53:23 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-ad5273c1fd7so930931966b.1
 for ; Tue, 20 May 2025 07:53:23 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005a6e63a0sm7241276a12.39.2025.05.20.07.53.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 07:53: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" 
X-Inumbo-ID: 2d7a6875-358a-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747752803; x=1748357603; darn=lists.xenproject.org;
        h=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;
        bh=SVy/BBRS4i0Veyi5PZGRDxrv2odRHZ3ji+yjuMVCGNs=;
        b=iW+x4f28hg6He5bauqT7AjMErW4ffaZA73VHhKrE32lvh8y8Vfx91KN+2/nh+h0gN/
         ymNEMZK6NtFQ4fVkR/YOTUo3ji4Yp6BJ51DdqnTmn97HBsWQbwXzo0CPLqA8197uABeN
         YJ9WSnJ/rQsPux8iIa982HYhYGrQZ8FvUW6WS7zlKhyXWmPCqjPWhFfUFnRCAvaCibb1
         hk4WXO47OG7w454xmacxfvxXURylg/kUOut7BcRqxMNU+JJL56NEmeL451pvtMYZ6+g0
         L2u/q5xzdp8u4IXfgwfOQSi5sU0GkHcBDR2FEE7aPGFGvG1pW9DI88z0zJisbAFEtYLU
         HWSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747752803; x=1748357603;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=SVy/BBRS4i0Veyi5PZGRDxrv2odRHZ3ji+yjuMVCGNs=;
        b=apl/fn0o2mskXwBPtuEh+N4PJqe7NL/YTnG+FFhZHK/5YfE5zyFzk7FDIR5XmaeSaX
         SXfGt/X6/s9uy6CBB3irla1MtzBmQN0jLP66nN2pIqwBn1qaV5xOjGk9tDIpur3ndsjR
         z6TAB10P3fUqaGxxmYA2k9K7B4YLtxtQsnDTNciG1jMHwNBMf1JjtDFz5IFtM6BMy6W9
         mI0KmRwPemYwufnOP7+kr4WXLv/aFivmGHWt1MFtTstpyoTRz7c9YMJg8uCeAUJVBWmY
         4HrkGdMS8gSa89DgJ6wMoeJ4t2B4Y9ZzCDCyvu7B2gwNsCr+kNjxIeuqC8aAttekHgBq
         f6ZA==
X-Forwarded-Encrypted: i=1; AJvYcCVsNpsfMHYJHBBZ+PkwHGLtiNVLzHkFZANOjS6W6isRx0e22W4jlE5vM5Zyne1QHnmqazMAjF2H5kU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw2jiLlkcDWC7oLbyt1Q2i8iF3jTOFu6KSs3VvU43Dyn/Z4kb2h
	lLBweR9k+aKSQgwzKOqrX1q3Mmbgk+hvwwF/29Ytjkng0801rgKF4o1t
X-Gm-Gg: ASbGnctFRtQq+Pcv0JEyRmtKXKDJNEjDAXhd+cg/lqDwofiK6VGEeunfInX2hpWLiTX
	oVg1+MFnANBaQtbYb7F1pXbePJL8t5K9wSI1cQk6iRwB3tOs8HbIaoP2VJNbn2ItFIhDlM76Bfe
	IGs0j44D+GkSbUTm8OqOY0532Vej+x17Qbvwf3eoirwNh29Rdb+OYa5N2YWlzKlsi3MKWcAo/8w
	AUm0USak66zh1iKyVoef3L77bhQQ8ToW0TvieD2DUEC90YZTD/6K6yTizbt8ikqmm/GSgB7t20o
	awbvH+L0TpXiv5XspdksuXnMC26C4vwR8MRE1HqHoNsInK2/BB/KL439gM2kBn6G5Sv6+BS82sg
	KegIe2d0paii6z2u2S8+dJibf
X-Google-Smtp-Source: AGHT+IH6IfMb6glmYwxgF4hVuemWn7cLDx0SIjtxXKpYDFQsIaece/lmQs2Xgn9gNj8EisP3kWzLTA==
X-Received: by 2002:a17:907:94ce:b0:ad4:f517:ca3 with SMTP id a640c23a62f3a-ad536bde67bmr1563755366b.20.1747752802608;
        Tue, 20 May 2025 07:53:22 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------0tJQ91MJTwezolrEhedV7Ugi"
Message-ID: <9e27c4fd-f62a-417f-ac20-0a6301e30498@gmail.com>
Date: Tue, 20 May 2025 16:53:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/16] xen/riscv: imsic_init() implementation
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
 <0d9a9a9e-3454-465f-ac1d-cd65ba4a5792@suse.com>
 <4b948489-6fb9-4554-9a4c-4fa75de7345d@gmail.com>
 <2966ad6f-179f-47fe-acf1-7fb568cb4fb8@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <2966ad6f-179f-47fe-acf1-7fb568cb4fb8@suse.com>

This is a multi-part message in MIME format.
--------------0tJQ91MJTwezolrEhedV7Ugi
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/19/25 8:33 PM, Jan Beulich wrote:
> On 19.05.2025 17:26, Oleksii Kurochko wrote:
>> On 5/15/25 10:42 AM, Jan Beulich wrote:
>>>> +                   node->name, imsic_cfg.msi[cpuid].base_addr + reloff);
>>>> +            imsic_cfg.msi[cpuid].offset = 0;
>>>> +            imsic_cfg.msi[cpuid].base_addr = 0;
>>>> +            continue;
>>>> +        }
>>>> +
>>>> +        bitmap_set(imsic_cfg.mmios[index].cpus, cpuid, 1);
>>> Depending on clarification on the number space used, this may want to be
>>> cpumask_set_cpu() instead. Else I think this is simply __set_bit().
>> cpumask_set_cpu() requires cpumask_t which uses static definition but we are
>> using dynamic allocation.
> But you're aware of cpumask_var_t (and respective allocation functions)?

Now yes, thanks.

~ Oleksii

--------------0tJQ91MJTwezolrEhedV7Ugi
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/19/25 8:33 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 19.05.2025 17:26, Oleksii Kurochko wrote:

    
      
    
        
    On 5/15/25 10:42 AM, Jan Beulich wrote:

    
        
    
          
    
            
    +                   node->name, imsic_cfg.msi[cpuid].base_addr + reloff);
+            imsic_cfg.msi[cpuid].offset = 0;
+            imsic_cfg.msi[cpuid].base_addr = 0;
+            continue;
+        }
+
+        bitmap_set(imsic_cfg.mmios[index].cpus, cpuid, 1);

    
          
    
          
    Depending on clarification on the number space used, this may want to be
cpumask_set_cpu() instead. Else I think this is simply __set_bit().

    
        
    
        
    cpumask_set_cpu() requires cpumask_t which uses static definition but we are
using dynamic allocation.

    
      
    
      
    But you're aware of cpumask_var_t (and respective allocation functions)?

    
    
    
    
    Now yes, thanks.

~ Oleksii
    
  


--------------0tJQ91MJTwezolrEhedV7Ugi--


From xen-devel-bounces@lists.xenproject.org Tue May 20 15:02:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 15:02:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990882.1374804 (Exim 4.92)
	(envelope-from )
	id 1uHOU4-0006Wf-If; Tue, 20 May 2025 15:02:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990882.1374804; Tue, 20 May 2025 15: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 1uHOU4-0006WY-Fj; Tue, 20 May 2025 15:02:24 +0000
Received: by outflank-mailman (input) for mailman id 990882;
 Tue, 20 May 2025 15:02:23 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uHOU3-0006WR-4T
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 15:02:23 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uHOU2-003Y2k-37;
 Tue, 20 May 2025 15:02:22 +0000
Received: from [2a02:8012:3a1:0:8d74:6848:91ae:ac06]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uHOU2-00FesM-1i;
 Tue, 20 May 2025 15:02:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=iidGXnlNqWRD0tS0NpWxv4PIeId9ZAVA03dv3tORia0=; b=DAm8SVTEkR+wjjVlSKEbaCvslt
	iz0ai2z+Ti8o1Qde9bacHoncH1yy3YN+Ctum7S8hewhVQpTZQJQyjCIq0EUMtC9r6f6vowt2pBDrK
	iUYJYkl1DVkNybVbHiKfisL80Js0A9QmYSj+r7CepZD2mNSM4gkYs9ljRFWhMpK7kwXE=;
Message-ID: 
Date: Tue, 20 May 2025 16:02:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm/vgic-v3: Fix write_ignore_64's check in
 __vgic_v3_rdistr_rd_mmio_write()
Content-Language: en-GB
To: Oleksandr Tyshchenko ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250520134751.1460968-1-oleksandr_tyshchenko@epam.com>
From: Julien Grall 
In-Reply-To: <20250520134751.1460968-1-oleksandr_tyshchenko@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Oleksandr,

On 20/05/2025 14:47, Oleksandr Tyshchenko wrote:
> An attempt to write access the register (i.e. GICR_PROPBASER, GICR_PENDBASER)
> which should be ignored (i.e. no virtual ITS present) causes the data about

I assume, this is a guest data abort, rather than Xen crash?

> due to incorrect check at the write_ignore_64 label. 
> The check should be
> inverted.

OOI, why would a guest try to write to GICR_PROPBASER if the ITS is not 
present? Was it a bug in the OS?

> 
> Fixes: c4d6bbdc12e5 ("xen/arm: vgic-v3: Support 32-bit access for 64-bit registers")
> Signed-off-by: Oleksandr Tyshchenko 

With the commit message clarified and Andrew's comments addressed:

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue May 20 15:04:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 15:04:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990888.1374815 (Exim 4.92)
	(envelope-from )
	id 1uHOWF-00072z-Ua; Tue, 20 May 2025 15:04:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990888.1374815; Tue, 20 May 2025 15:04: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 1uHOWF-00072s-Qt; Tue, 20 May 2025 15:04:39 +0000
Received: by outflank-mailman (input) for mailman id 990888;
 Tue, 20 May 2025 15:04:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHOWE-00072l-DI
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 15:04:38 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bf212281-358b-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 17:04:37 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-601a6e2e93cso2142128a12.1
 for ; Tue, 20 May 2025 08:04:37 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-602047c4b73sm1471192a12.10.2025.05.20.08.04.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 08:04: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" 
X-Inumbo-ID: bf212281-358b-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747753477; x=1748358277; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=8LMKMv3xKdN15SWrKow1gc2tuOhlL0PDj84+Xx06KAI=;
        b=Yihe7tEoAHMk0UrN8drlF99IDVE6h9eQs12vkTmoEbcSC8SPqZ/F3IuE1O48EXfNnc
         F5WWWjtH+hS+NoYCSxL5G9X9zYi1/zQ/OVncg0Sq9eozY9ICLyFjEoGLsW14Xj0y//Tv
         P6sFPHTRgB2yLT+hc85RFXP69nUpeWPQOnI/wTL7Sm05hovCsnHn0AAphfqcbeYiGmBR
         3XzFg8MXG/XdRtG5VdAhfmmbVBj0DdXRmL+ox+CpgVauneWg+kI+afZgE8/0BlU08OYI
         u1q86QeOj2N2K5+ARoRcxh6XE0uPUehT8DS2SYg/j4w/cKTMUr8aZOPCMGn02Y/R1C4r
         Um/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747753477; x=1748358277;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=8LMKMv3xKdN15SWrKow1gc2tuOhlL0PDj84+Xx06KAI=;
        b=kAB/dVY5rTsc+fzS76AVx53oxEsnSvhRuxh/wY7M+u3FwIuFX/rRSc79RhE6Jm9YsH
         +jWlbZxYNL7Sde6mTk14fbYRxHOOJ4kiXCnALhjg4IcFgNo506qArwWaPZsbkToH7rLq
         zKmj6hlWMDCjgVtAZLOycVwHLUVXKRtr/o6q+0mr7mAm5k7NouxDleR+Cx6bOECUY6Es
         U1f5UlfisjtinRizIaHFQvD7dPozHbwfvXpNOOoKhe5nniUWr2LbQkDnuj9Ovpi5Z4/i
         CLHGnxqDnrXWzQ8xN0H+Ho/u9jetZN2Q6IbTE7szEEeOMNXLG9XpKGiWysQuJY68hQtr
         sHOQ==
X-Forwarded-Encrypted: i=1; AJvYcCWyD3hElj7sEQG5X/0vhS39F24X16RS/eIPcJWS8UJa7PRkSnEZNOK9E7eY9h4feG3WABzQ0nLlSD0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yze9KkkE9AuYQuupSwKQU5uyVyKNQCjDmiqg7DmNESCBDtMXK+X
	WTseoq3H4Vo5wBIlOYKqhTzkQzjNVkKR7FLXxie85iTjBiif82dtDTT8NstYlXjNBA==
X-Gm-Gg: ASbGncvBEisgWwlc9piiGcO1gaNHlSAVbzmUimZW5Zej9AO+pHNbv1oSGjhnzJUkuHb
	bXg3fJB8jVGdfaiLNSSb187/C+76z6i5cr5L7+vupJrxpTU/LJFArthSEA+bQEqVthBoouuvKeS
	punSfy53dmpw5QMPEmhQrV59n7g1J7Ks601qo7ounwgG/iNHe2oXAMeRv9mZ6znn5G4NQ0b4jHx
	XRS4dnylKut819wIk/fXFZ1MRM0Y0GUZ+uRjRNkO12ZALW3DhqcBK6Y1QE8D8fEbzm0WhpMYN3x
	4N22oQAUJ+SCtvGLwnkrnpqG3XyLZxKQtyxZ+xWo+y5hvndcN92TAB5+2xyaJp9YZ2D9tuiO
X-Google-Smtp-Source: AGHT+IH5HHdeNouZiTva0NtNnieKP6fgsPy08CIhI4EWsVPejZKcl3qdM+9v6hbfKtvUYuwr0oOT1g==
X-Received: by 2002:a05:6402:274c:b0:601:e499:dc59 with SMTP id 4fb4d7f45d1cf-601e499de23mr7411682a12.1.1747753476392;
        Tue, 20 May 2025 08:04:36 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 17:04:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 4/6] xen/riscv: define pt_t and pt_walk_t structures
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <9f822cfaa058167982c85b3ca3f722881552a75e.1746805907.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <9f822cfaa058167982c85b3ca3f722881552a75e.1746805907.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 17:57, Oleksii Kurochko wrote:
> Refactor pte_t to be a union which hold page table entry plus
> pt_t and pt_walk_t structures to simpilfy p2m functions.

Is this really simplifying things? I really view ...

> Also, introduce some helpers which are using pt_walk_t.

... these helpers as confusing things, by using the wrong part of the
union relative to what their names are. (I'll re-phrase this some at
the bottom.)

With the union it's also unclear to me how to know which part of the
union is the one that's valid to use, when there's no auxiliary info
available.

> --- a/xen/arch/riscv/include/asm/page.h
> +++ b/xen/arch/riscv/include/asm/page.h
> @@ -99,15 +99,67 @@
>  
>  #endif
>  
> -/* Page Table entry */
>  typedef struct {
> +    unsigned long v:1;
> +    unsigned long r:1;
> +    unsigned long w:1;
> +    unsigned long x:1;
> +    unsigned long u:1;
> +    unsigned long g:1;
> +    unsigned long a:1;
> +    unsigned long d:1;
> +    unsigned long rsw:2;
> +#if RV_STAGE1_MODE == SATP_MODE_SV39
> +    unsigned long ppn0:9;
> +    unsigned long ppn1:9;
> +    unsigned long ppn2:26;
> +    unsigned long rsw2:7;
> +    unsigned long pbmt:2;
> +    unsigned long n:1;
> +#elif RV_STAGE1_MODE == SATP_MODE_SV48
> +    unsigned long ppn0:9;
> +    unsigned long ppn1:9;
> +    unsigned long ppn2:9;
> +    unsigned long ppn3:17;
> +    unsigned long rsw2:7;
> +    unsigned long pbmt:2;
> +    unsigned long n:1;
> +#else

Imo you want to settle on whether you want to use bitfields or #define-s
to manipulate page table entries. Using a mix is going to be confusing
(or worse).

> +#error "Add proper bits for SATP_MODE"
> +#endif
> +} pt_t;
> +
> +typedef struct {
> +    unsigned long rsw:10;
> +#if RV_STAGE1_MODE == SATP_MODE_SV39 || RV_STAGE1_MODE == SATP_MODE_SV48
> +    unsigned long ppn: 44;

Nit: Why's there a blank after the colon here when there's none anywhere else?

> +static inline void pte_set_mfn(pte_t *pte, mfn_t mfn)
> +{
> +    pte->walk.ppn = mfn_x(mfn);
> +}
> +
> +static inline mfn_t pte_get_mfn(pte_t pte)
> +{
> +    return _mfn(pte.walk.ppn);
> +}

Following to my remark at the top - if you do it this way, what use are the
ppn fields?

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 15:11:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 15:11:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990897.1374825 (Exim 4.92)
	(envelope-from )
	id 1uHOd2-0000P9-Js; Tue, 20 May 2025 15:11:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990897.1374825; Tue, 20 May 2025 15:11: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 1uHOd2-0000P2-G2; Tue, 20 May 2025 15:11:40 +0000
Received: by outflank-mailman (input) for mailman id 990897;
 Tue, 20 May 2025 15:11:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHOd1-0000Ow-8G
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 15:11:39 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ba1f430e-358c-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 17:11:38 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-601609043cfso6229975a12.0
 for ; Tue, 20 May 2025 08:11:38 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005a6e3ca0sm7505700a12.42.2025.05.20.08.11.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 08:11:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: ba1f430e-358c-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747753898; x=1748358698; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=3nIGCruBoziHP+zwfCA2lqpvfCSAIq19XHEvtDtgFlQ=;
        b=PVMv8d5+SfjVYZ38Z85mflaO0/bdTLrr+XJNJkI6FGOSq0/kGoVYnPpyllXrw3Ava2
         7Ka20rxKMZMSWdF23Q7uNKQAP0w9FjizU9yjAmm9WyDaunTcoetr3IvjtwGqph26wVSl
         7ooT9LNkSPNM1HOnLX03mwtlQITjBMMi5G8dYP6iGDvyO/2g7v8w3KQc4cN7kCI0lsHm
         NdieznX7INTqgtG5c+Sz4WBQoI12wHrWonvaJSi8eljUNVSxbwWblN3425xwwob2KW+h
         K+maHAymRjf167UEXu53ie7ZlbUgIHHWydjCWTB9MA1ui06PHqwasolwRQnH29OBnPlQ
         26vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747753898; x=1748358698;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3nIGCruBoziHP+zwfCA2lqpvfCSAIq19XHEvtDtgFlQ=;
        b=gbY0ru6r8D4VXcA+D3xjY72Bin7Rz2R6muQlDM+sdSU0seiwc/mvDnT4t4MrhGHKMs
         8T79PpWoAJ92+37DC5Lu40CF/+2llRM7QtTFRdW7Fc8NicwsZ1MWgCWhjuqAXGCEhCS2
         igLFbQ6ve1STtdepJ4zx0fDuOc9kJKo4tbQzzGCLE41Inw2iVCT1x0nlAgBYxY2wt9yv
         Yf4QmAI5ZA8d8LNR0Tc6jzGhkp8Qx3pPRYQIJ5e9CRD3SxMAYEe0lHvwkj7RoRRB3G9L
         OSFX4S2ge/uEE1zqjwpIoIoZuv3J+N9BysPOYNpk6IElYOGEo1lPfk2A+GMuMC/dQlLc
         7Iew==
X-Forwarded-Encrypted: i=1; AJvYcCWFoE4BLS/c2H4rlhXn94PKZsoCuOXsoC+8CN2sXAeG9ABJTEFusq8Qqu4rlwFXDAr9eRghLiufCJU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxV0ikyNcG41dvTLDN5atNzQBo+1UFAfJjEoZM4+Q60NFyjazFa
	/uFEUXtmeQSBiM+knIoF3F/qAlKnhkwRW/d95UB7vJ1oh7xsHOZ0ERC/uH/8RNi1Eg==
X-Gm-Gg: ASbGnct0UGrEpHIIfbOCKRhBgl+KwyFeCErqs9aYZMD2M0D4wjLBka77eTVenqW25ln
	cWiXwpnqgBr3isxdr3auSEX35pCfXdAPloDFMlh3zISlWfZkc+tZyzS8cL+eVdd8XF/AVQtJevv
	pq9xra7gNx8nbU4Nl7TS3kccWZEV9hekuE1Q6DNedZcnCq8r680OAncwfPW9u/x7GaR3wuPzxMY
	Xf+bKePZm4htPCvE41GGSYoP/MlPy7UaC8eNsD35gBD1vldP8MJ6bogWRzLaqafxXWTnhYLg0Rg
	kagCtHIeWCFn5BAMXVkMXTGzdGHAV4gQgk2z9e0BadApzLKnCU74gooKExz4TZ7rtwN/Kw+2
X-Google-Smtp-Source: AGHT+IFvMikcGVviHukTluwXy9Ah/1ufJYvIPBbBDzcYouBorlmOvV+lGigpz0yn92VB10uVFSm++g==
X-Received: by 2002:a05:6402:50c9:b0:601:a681:4d5c with SMTP id 4fb4d7f45d1cf-601a6814f05mr9998135a12.32.1747753897648;
        Tue, 20 May 2025 08:11:37 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 17:11:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 5/6] xen/riscv: add new p2m types and helper macros for
 type classification
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <52861198c7c363c4b0caf818345f4ffbec056337.1746805907.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <52861198c7c363c4b0caf818345f4ffbec056337.1746805907.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 17:57, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/p2m.h
> +++ b/xen/arch/riscv/include/asm/p2m.h
> @@ -80,8 +80,36 @@ struct p2m_domain {
>  typedef enum {
>      p2m_invalid = 0,    /* Nothing mapped here */
>      p2m_ram_rw,         /* Normal read/write domain RAM */
> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */

This is pretty special a type, which imo better wouldn't be introduced
without there being proper support for it. (I don't suppose RISC-V
hardware alone can effect this type?)

> +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
> +    p2m_map_foreign_rw, /* Read/write RAM pages from foreign domain */
> +    p2m_map_foreign_ro, /* Read-only RAM pages from foreign domain */

Aiui you took these from Arm. Looking at its sole use, I'm not convinced
it's used correctly. If it is, the same comment as for p2m_ram_ro above
would apply here, too.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 15:16:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 15:16:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990911.1374834 (Exim 4.92)
	(envelope-from )
	id 1uHOhl-00012T-6v; Tue, 20 May 2025 15:16:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990911.1374834; Tue, 20 May 2025 15:16: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 1uHOhl-00012M-43; Tue, 20 May 2025 15:16:33 +0000
Received: by outflank-mailman (input) for mailman id 990911;
 Tue, 20 May 2025 15:16:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHOhj-00012G-2v
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 15:16:31 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 675fb031-358d-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 17:16:29 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ace94273f0dso977033466b.3
 for ; Tue, 20 May 2025 08:16:29 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4466e2sm751054966b.93.2025.05.20.08.16.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 08:16: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" 
X-Inumbo-ID: 675fb031-358d-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747754188; x=1748358988; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=2Jt+WaOF32QEGnOX5C/q6DxL5WTTbmP1R82M8CRIHk8=;
        b=Ilh5EHkuNXEtTQfsOWktnW1/jPIsjGKLtL1PIumu9JnQ27w5sjrvYIhGL0BsOgTwQb
         Cpc16+xwLLL5Zn0AgCIJsL1ApQKeLnx70Abk7sMeiepogH3y3NNUhwONOxZqK4F0vavt
         5TXOkIrcXKavscN37JI55kN+glF14VdFUHhOg8I71eFofGhOLZX7X42mlgW6jfRbE7VS
         KMT2kf8B/+DbFQhhB5s7goWxXv+bhOmNx0UCSO/x5NwrOC/GmPq5hcr7e6WVfxvb0t+6
         clEhUhXZk6HAY+b0tgvnxGC4jfp4V6l+N0leSYNHd6J2r1b0aR5xVjYlur/tc/HuTSoX
         EuKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747754188; x=1748358988;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=2Jt+WaOF32QEGnOX5C/q6DxL5WTTbmP1R82M8CRIHk8=;
        b=GqswUnmO9jEQDhTC2t2PD+nYKA8TtY8wkjAl9gLCkWAEGAhlG8aUcBe7G63RQOlACn
         TWnEH23EdkPQjDaQfZVVZns7WvLcIZNFeYDeZeTWrkdk9NrrhEXxRmvfiaW6AsVl94fB
         j8P/R4PsrIImIyeNhLdauolF5FyzzRZwIFHRGbj6FJllPFYyoI5vjTenFhz305CZU1So
         lkBk2w7E1s9ksTW9kFZHyS3Ue7bwFcHjOaKoKEUyP7ePERw/xdtUGW8Udr59UuAszN8/
         u9JJ8XWI4wSZmkQz7LiU5fJ68Upr+jmpap5lcJ0tCLGMLWHHkQ/CSfFJI7rI5tzQ4hEV
         CINA==
X-Forwarded-Encrypted: i=1; AJvYcCVYHtOPwbnAweKp1aInok2wme/xn7xdhceEYwfw0dEI72nbz7Ei/+XUwmN5txhvD5r3amoqDQsuZK4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzXLMWHVuE0fhV/7kNtHMa7FCWpwed2JfNv8Eptu76QHgIgIJ5f
	eK5YXuprcMtGP5vh021/W1lY25mfvtTgHhdDi8vq0jBGTzAsvm7eUZdP0wfL0DTSbw==
X-Gm-Gg: ASbGncsXE0P1o9H/wIF1dXQiu1gKnw+GoTGWStMoIjSnckzq2Kfw3N6tvo9AujJa+jx
	0M0UnIK8nGONDPPsO4AVoTYQDNqAbgk6nAbd40v/cuBQgvo09W2f53mNFxxV8Xc6CCTmnFPsJCR
	9UVnQ6bY7HkK8IKHtiZvvVLlP5IcgBCEOKBQx6jpwoUMiLmaW2koyfZ7bEuRjdT/HkuuEGa+6nw
	iDEIDYluD/MZqbltadc/rgVB8QExj8VJJcdvlmABeDtyzJoFAGwjQBdM/FJEEo6MMsv7iz08w3k
	BMXkwIDMxOA9mY5Pt14yntYrLphLgr3AGytGk8UiwGzYhYFvgnJBWmU6kYgI1g==
X-Google-Smtp-Source: AGHT+IFTzpq7GkH+rn9eTznDioQ1F3+UPnAL6VC+75nuB2+N2j+FmfinA5Pg6BbJhKEY/DzKJBoIOQ==
X-Received: by 2002:a17:906:c148:b0:ad2:3f1f:7971 with SMTP id a640c23a62f3a-ad52d43839amr1543360566b.8.1747754188463;
        Tue, 20 May 2025 08:16:28 -0700 (PDT)
Message-ID: <701620bf-b76f-4f21-8703-4a6d172eb812@suse.com>
Date: Tue, 20 May 2025 17:16:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 6/6] xen/riscv: implement p2m mapping functionality
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09.05.2025 17:57, Oleksii Kurochko wrote:
> These utilities are needed for building and managing RISC-V guest page
> tables and MMIO mappings by using functions map_regions_p2mt() and
> guest_physmap_add_entry().
> 
> To implement p2m mapping functionality the following is introduced:
> - Define P2M root level/order and entry count.
> - Introdude radix type for p2m types as it isn't enough free bits in pte
>   and the helpers (p2m_type_radix_{get,set}()) to deal with them.
> - Introduce p2m_is_*() helpers() as  pte_is_*() helpers are checking
>   the valid bit set in the PTE but we have to check p2m_type instead
>   (look at the comment above p2m_is_valid() for some details).

May I suggest to name them at least p2me_is_*() then, as they check entries
rather than entire P2Ms? Same perhaps elsewhere.

> - Introduce helper to set p2m's pte permission: p2m_set_permissions().
> - Introduce helper to create p2m entry based on mfn, p2m_type_t and
>   p2m_access_t.
> - Introduce helper to generate table entry with correct attributes:
>   page_to_p2m_table().
> - Introduce p2m page allocation function: p2m_alloc_page().
> - Introduce functions to write/remove p2m's entries: p2m_{write,remove}_pte().
> - Introduce function to allocate p2m table: p2m_create_table().
> - Introduce functions used to free p2m entry.
> - Introduce function for table walking: p2m_next_level().
> - Introduce function to insert an entry in the p2m (p2m_set_entry()).
> - Introduce superpage splitting: p2m_split_superpage()).
> - Introduce page table type defines (PGT_{none,writable_page}, etc).
> 
> Signed-off-by: Oleksii Kurochko 
> ---
>  xen/arch/riscv/include/asm/mm.h   |  32 +-
>  xen/arch/riscv/include/asm/p2m.h  |  17 +-
>  xen/arch/riscv/include/asm/page.h |  11 +
>  xen/arch/riscv/p2m.c              | 780 ++++++++++++++++++++++++++++++
>  4 files changed, 829 insertions(+), 11 deletions(-)

It's imo too many things you do in one go here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 15:17:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 15:17:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990917.1374845 (Exim 4.92)
	(envelope-from )
	id 1uHOiJ-0001UC-Ee; Tue, 20 May 2025 15:17:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990917.1374845; Tue, 20 May 2025 15: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 1uHOiJ-0001U5-Bp; Tue, 20 May 2025 15:17:07 +0000
Received: by outflank-mailman (input) for mailman id 990917;
 Tue, 20 May 2025 15:17:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHOiI-00012G-EA
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 15:17:06 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2614::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7c0a9acf-358d-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 17:17:04 +0200 (CEST)
Received: from PR3PR03MB6412.eurprd03.prod.outlook.com (2603:10a6:102:7d::8)
 by PAXPR03MB7700.eurprd03.prod.outlook.com (2603:10a6:102:206::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Tue, 20 May
 2025 15:17:02 +0000
Received: from PR3PR03MB6412.eurprd03.prod.outlook.com
 ([fe80::2887:9068:38f6:8340]) by PR3PR03MB6412.eurprd03.prod.outlook.com
 ([fe80::2887:9068:38f6:8340%6]) with mapi id 15.20.8746.030; Tue, 20 May 2025
 15:17: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" 
X-Inumbo-ID: 7c0a9acf-358d-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Hspkuzk0zkiF4rLgDCwpp9Di90oHBxD7B0T2wKgAUQRgyHEiA3kado8YCrSwEbgvTOxGjo7Lz3V1lPeXTbhakT1xHLwzCKMYqy9DEZzKzjRt8YW27UkE8X59POwz3odAJv08trERk5KSiFkT3o++/P9oI57l40gWRLdvvCk+zj0NLoGHKa+EhoGSara5estQ7ycuS3gslEsvwZS5Z4s71Dsaym3pUrUdRQieubIyMAOsKWGCysKnfqO8rtqKZETTFioAghbvbhmA71rfiX6RLxEMQoft4tX8nJOhr0qY3G5FCue20FDJQk5z5O5SzjlHgOVF/OYvC0yHxFdnMIGEtA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=l/dAQhVDkTasaRwPrHbblfY4HhPB4oXdRyzNzs1H/Pc=;
 b=EaAAAQp+qZgZDFZ1le21qkzkNfkkDZrEoSKzh6ixQ65F2+nlFSi94YwlIVNophODn11nhdlW3ydjlQJWGUjslDwXCbOxCg8tpiM8WRr4yknbwzLPFk3WY4jd4aTMxkDu0FDKnOECvPkWE1zpEeacUCQR/guq3hsu7LYbUon1HBkfJJd54EOW1gemPTMcwRKlWtT1RquaPu8nu3eXud40hqfx+zGtpzDNWf6BVjsZrjttWWqtsehlxrZOw9gk2C2JPhhWDlGAspuQNliSDVcVScnZKIbMEH2IyTjrrHOvfWpJ90zsdBUhUrNlq4zQCDAWPFRylQXvQK2qvQ7xbh8Rsw==
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=l/dAQhVDkTasaRwPrHbblfY4HhPB4oXdRyzNzs1H/Pc=;
 b=b0+gXlIBvAQ8m7uUllgIwlx7WNP1p/kOKzXhE8ufucvtfDMZhS4jJbTBT0PvTJjUOb+4UEbEf6SnwPBvqhpzVzbmCub88uf/0EdZSm1mBjmu36jhOqEksNqFJwu+c61kxHfyZr2+vLnCjjB5s80jY3DHrjwEGY/ieGLdg5fksPfZHQ9yySGcRPmy9/hsxval7C2rV9yRVcRa3QFrby6/lJ/oUqAhtECv9nGyCfiZsmql46HBCHv/FeyDIaS+46eFge0mMPBfUUaB4wY/mZauzqiePSMxiY3BPfbgH+nzd/W4kFtnlMtKc0umY69tUdfFyv4ekl3FbkjMi9W2LijDtg==
From: Oleksandr Tyshchenko 
To: Andrew Cooper ,
	"xen-devel@lists.xenproject.org" 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk 
Subject: Re: [PATCH] arm/vgic-v3: Fix write_ignore_64's check in
 __vgic_v3_rdistr_rd_mmio_write()
Thread-Topic: [PATCH] arm/vgic-v3: Fix write_ignore_64's check in
 __vgic_v3_rdistr_rd_mmio_write()
Thread-Index: AQHbyY3It6QrN0GxI0mChLdwI1GDxLPbksCAgAAOmIA=
Date: Tue, 20 May 2025 15:17:01 +0000
Message-ID: 
References: <20250520134751.1460968-1-oleksandr_tyshchenko@epam.com>
 <26756272-790a-4418-b75e-5052f10319d1@citrix.com>
In-Reply-To: <26756272-790a-4418-b75e-5052f10319d1@citrix.com>
Accept-Language: en-US, ru-RU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PR3PR03MB6412:EE_|PAXPR03MB7700:EE_
x-ms-office365-filtering-correlation-id: 5c6f0dac-acf5-49dc-2166-08dd97b15f3d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?MC9aMFhJM3d6ZUlkM1A0NmE0RlZoYVJFdFNJQXVZYWxXcGNRdEVQb25MeVBy?=
 =?utf-8?B?clRmSXpKMzl6QnhOS005L1ZxazRGVzFBSHRSNmcwYTFGUHE3VGwwbWMyOFJZ?=
 =?utf-8?B?NWw0RGtpaWhROGtXNjRCUk0vQXNoazhUMjdhSllCc2VZY0JLTDFleG5mN25L?=
 =?utf-8?B?MmVuUDdXT1dORFl1UXFrYTdIeUE0RG80YkNJUDhjVkdTTWJyWTA2SVFOMVF2?=
 =?utf-8?B?RitmN0hIS2YzcFpWRDJ0NTVmQjlXSHFjRkNLbE9sZHdLallrRXNEbXA1V3Bu?=
 =?utf-8?B?MnIyK2dRM2JkazFvVUpkTnduU1VXUWF4SEhWbFk3M2p3REluQ3Ixamp0VDNF?=
 =?utf-8?B?UmF0TUI2ZTQ0MXhmRWQ4REtIOTc1eWN5eVRGSUswdFpPM1htZUkrK0JxdSs3?=
 =?utf-8?B?Wk1kZzB0MkxSRXAxRGswNFJRQ29oYXFTKzRTbFRtaGF4U2JMZWlSTEhoTWp0?=
 =?utf-8?B?VDR3VmlEaCt0VG9KaXhXak5zR3kxL1R6NmNORGRrb1lNa0pCdjhuS0lOWU1v?=
 =?utf-8?B?YTkvOU10cklDM3RUMjkwazQvVU92bFlpN3VXUHY1TXI2b1JLemxRNW9kS1ZL?=
 =?utf-8?B?a1JrM2I0anZ0dkthWlFCZzB5b01ld2U4L25FMHlWVGZySUM4U1h2eWxoeTR1?=
 =?utf-8?B?eVFBRWltQjZWQUR2aTFUZUhlTkNDWG1lb0lzMmhodmx4aHBpNHVuQUpmSEtF?=
 =?utf-8?B?VU84dkNueDZnK01FWjNsTHVXWlJhSzlibTllYUt6Zm01WjR3b1BIT2tPRFBE?=
 =?utf-8?B?ZkEzZ1ZRQWRsQ3VTeWhSZUFzNS94VFBpVEViYkp1SUxYSkJydVBmaTB1TUho?=
 =?utf-8?B?Z2pSckx1OWxMSlg0UVMwTUVRait1MU1MSDR2RFpRWno1NjIrVnF3ZlNTcnhj?=
 =?utf-8?B?blNScHdVaHBpZHNuRTllQTIvUUUzWkV6NzJ2b2JSdFNJMjFPVks1YVVVNUp1?=
 =?utf-8?B?ZU9uWkE3dWJnTEFvMmRNSVdmSFRqZ21oWm5jWElsY1BzNjFNN3dMbkJzMDFP?=
 =?utf-8?B?RjZDby9PbGJ0amh2SXE5SzJ5cWlzWEwwSEpqT21paTdPYXNoeXFveFljeW4w?=
 =?utf-8?B?dWE0ZjkzZkpWdExqaEhQSGtZZVRaL05HTlJacnB2b1RtMTZJRjJab2tNRWdD?=
 =?utf-8?B?U2ZEd09BYWVjUkgvekJKYTF4TWRKcHBFbkJpWkJnL3FOZlFsMGJjM282Vm9C?=
 =?utf-8?B?K3dnRUxRVXArUW9hR291NUdJMmdVdERpUkpQUkxIWjUyY1U2NEc4R1ZEcktD?=
 =?utf-8?B?alBXNFFxNEtGY09kVUdmaGRLcElnYXNRZk03QzQ0Y0x0QjBkQ2grNGFFL1Nn?=
 =?utf-8?B?MW9KSlF5SVQ3V1MydzZ4cld3ZGYxUnRJengwTTh2akZHc29wVFpsNDdLNEJO?=
 =?utf-8?B?V0o0SnA4SmhFcVBxQUNLdldQZm8wUkRuNjloRU94RktUb0V5cVNsWDQ2bmdS?=
 =?utf-8?B?RHNkYTBTTjZUUEZzYmlNczVlcVYrMVRxUWpVUnkvOTZtSkNSNXY3SHRpYlc2?=
 =?utf-8?B?aUx6Zm5QYXF5ZDh6UEdPaGdHQ3ByVGtJVlhoTVhrZWtMQ2JkaHVlcG4wcVR5?=
 =?utf-8?B?MHhsbFNBVjJ1bzNYTmpPUmo4aGVNbHZUREhwN01Ldjd4SG5qRUFESkFZaTFN?=
 =?utf-8?B?N0NZQXFvTlRSRlJacWFjR1luYWpoYXhodEo5S1JMcVAwQnhwTzNmait4QjJo?=
 =?utf-8?B?TC9VK1Fra1RaZUxNTk5pSHRoaFpRRnhXN01VeURhdTg4OHI2dU0rVlhPRHVa?=
 =?utf-8?B?NVRNeXU4eWRkUFlHeEUzeG1ER1BNK2lQY2xueVBjUzlTNUlXRndVbVNqbHlp?=
 =?utf-8?B?d2ZFRXN5a0dCYk9rSGo2MWxFc0Y2REtLY2J3VnI4MTA0L28vQ2NHbmFsSStC?=
 =?utf-8?B?ZnNhWTJ6N1hicXhsNUVaRkFZZGordzQ5bHJId3AyOXVzSWFwQUR4cGQxcTRh?=
 =?utf-8?B?T2dOckprVkhIRnZxWGI4cFdzbWFxQVBEVGVmTjBhOUkvRHRhb3lVdmZ4ekhS?=
 =?utf-8?Q?5+82oQy+xLQbGhj/hLBL90okLkGuoQ=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR03MB6412.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?YjFiQkF4b2gyb1pMTkZCcUxJYzZCZ3E3NzI2YnRKclptQlJlcFUzdjRSOG1R?=
 =?utf-8?B?OE1OVlQxSDdxSVorcXllYXNEeVVFaWdPZ1BndkRrTUxNdExDZ0VDNlBTUEtV?=
 =?utf-8?B?RHJadk11N2szeHBIUEhCaU9QalB2bTYxOWJwL2U2WXNMSnhTZEdXY0ZaTXoy?=
 =?utf-8?B?andPR2xuNkFlcWNDV09KSEVWQjR4R1dZVHdSZXhMRzdiZ054dU1WV0hOZzlW?=
 =?utf-8?B?ZEUyRzRYVDNjOHdKaVhpTmZQTkJucWNXY3pUR2tCZStJNVBWaGFocERrcDF6?=
 =?utf-8?B?Ukp5NFZKVmU3RDZSTHg2MGFNdnoyTkM2SjlvbXYzVThST25jMENud0ZJV1k1?=
 =?utf-8?B?M2czVkVpK0NxblBrZXFhZm9YeHVyU0VDOUJUVjhXamNOZDliV3pNamhhbnYx?=
 =?utf-8?B?bTFubFZ6WWllTHJhMitKSStzNks5WUM2TG00RWQ5WVBoMEgwV1d2aVpSQkZX?=
 =?utf-8?B?VEl3V1FBZCtCeDRVQlhTNHV6M1VpUkNWSVhwWHhrY01MejZoelZPMng0TkRU?=
 =?utf-8?B?UzRMSE41Qlh5YUpzSlJQZmxMTVl6V3YvWnY0d0czWUZ4N1hzZjlUcXVId2tn?=
 =?utf-8?B?R28xdGsySGxzS2VIb2VtdGFuZy9HcWlnVyt3bUtQUEVCZGZaQllGSTdGcmtm?=
 =?utf-8?B?S04rOG9oMldRNFB0MW1DYmxMMkxRZjArRENFQkorUkhzRW5SbGNrdHhqN0NW?=
 =?utf-8?B?R1dSS3Z2T2F3Nm9DNTM2bDhRbFdpenBiRWkwcjZLbE43NUNvUXB6cXl5N0NG?=
 =?utf-8?B?aWRhZ09vVnhIL2Y2dTloMTAwY2VPb1h4TS9qSmRkUE9IVHArYkJzait0czNu?=
 =?utf-8?B?VFEzSi9na2xtdXZKSllCNUQwV0hzS1lLVWVtMVo4T1Qrb21PRUNUamNHNnZh?=
 =?utf-8?B?Q1NKUkpEV1ZPSzZkWEFDR2o3aEJKSm1Pa1A2Q3oxUkJzcEZqc2xFdXVKUzNv?=
 =?utf-8?B?VWhWVTBIMDlEZjBoU0hwLzMzbE5BT0VrVFY3dWtzbkRROG1mTzJkNHBFOFJV?=
 =?utf-8?B?anBSaFNzdjRIRWhiSWVTREIvMkFubGpYUWQyb1dxMHZZZ0ZsQm9FZEVEbmRk?=
 =?utf-8?B?SFJqaFF5TFlNeVlDZmNLaDduZk8xZ2dXK3ZSMnNIZXNNMk5QVVAveHdGSDFi?=
 =?utf-8?B?Y28rTmhucURYc0ZVdmtKWjNhaWl0UlpWRFA1amZlUkJleS95TXdtWk1FdUYy?=
 =?utf-8?B?bWdHOTQybkU4OStMWVlOaWMrWTIwUU0vV1pMOHl3RVFQSk1icjRvTmd1aVNO?=
 =?utf-8?B?eFJCdnRqbEU2dkhHZTRRMWd4Ty9CbGU1dmFocHh6bDc3R0tLUjBvaG5HTURN?=
 =?utf-8?B?ZUVMQXpIMHdQOXQzWVpaeUZCekNzTzVHK0Noc3pGQUdKRCt4dUk0azdScnRq?=
 =?utf-8?B?U0NJVUpsaFFhMEM0ajVWTUUzZFZjU0pHK2p4YVpHQjN2STYxVWlrdU95Nlo2?=
 =?utf-8?B?UEZzNHc5MUJjdzR2MDZRTnNISkt5V3BBOHh4STFiYWNQWFdseEY5OVdvblJ0?=
 =?utf-8?B?TXVsQ1hGQllVQlcvSnNEblpyWkg1QlAwVFNVdDRtbllFazR2YnBZU3V1WUZw?=
 =?utf-8?B?NUwwK2FONXRkdElwMVZVeHBOSlp0MXVhVXdvdjdqcnhkUjR0MytPazc3amM2?=
 =?utf-8?B?MjhwTy94YW1UUk9LUnV5Vk1Ob1dsZW1aUjNrRHRoMGtSMHFnVHk3SjlIRDc5?=
 =?utf-8?B?TE9oeUZVNTBUMFh4NnBza3dFaFVWZDVpWEFiOGh4cjNmS3hKckhPWC9saFlK?=
 =?utf-8?B?OXZxbDVNRTdBc1Q5THBtTGFlN3U1SDAvRDBoRk5JenNSZ2tDZDhZMWpLMjBO?=
 =?utf-8?B?QzJ1OFhRRE4yRSt0R0EwT3EzdFREOG1pdUY3eHpPS0dUSVpzMEhSd2I3WnpP?=
 =?utf-8?B?VlYrb3d3WUJSbXdXaHNKdmVZNkFsT091TXl0WFRvVEN3ckM2bllLdTRPUk1j?=
 =?utf-8?B?c1BhbVhJUElxSzdpV2k5RGp6L2pvS2VDSC85SzNQYUJVYnBudFM5alhvMFJI?=
 =?utf-8?B?Rjh5ZC9aMUYyTlEwZG9rUlJMajduRjRWUm9VOUZOQ0JoR2lHMnJBN2NBcXJs?=
 =?utf-8?B?enQ2KzU2ODlaYjVOSFlxK01ydmRTMll5eFFqczE3L2QvM3JtbWVGdEJBWWxl?=
 =?utf-8?B?ZnV0RHdBZ1l0T2FxdzZSS0dtZUoydEkxMi9ubXVvSlg4bGVtTXBSOGZkRlpk?=
 =?utf-8?Q?BB7Vclsj3QGqM0JIcCJc700=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <234B2BDB731A5F45A47772ADBFBC3FCC@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: PR3PR03MB6412.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c6f0dac-acf5-49dc-2166-08dd97b15f3d
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2025 15:17:01.8859
 (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: YhpaE39n+9ywCS1+zNaowTmDKvX8Hr/4aBUBp03CaauKCoVQLCDTiTOqSQiv4HGz7E2Fp2RkvyPCOGeAL5TgVh0rNuFqIgroe3avMwCdJiA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR03MB7700

DQoNCk9uIDIwLjA1LjI1IDE3OjI0LCBBbmRyZXcgQ29vcGVyIHdyb3RlOg0KDQpIZWxsbyBBbmRy
ZXcNCg0KPiBPbiAyMC8wNS8yMDI1IDI6NDcgcG0sIE9sZWtzYW5kciBUeXNoY2hlbmtvIHdyb3Rl
Og0KPj4gQW4gYXR0ZW1wdCB0byB3cml0ZSBhY2Nlc3MgdGhlIHJlZ2lzdGVyIChpLmUuIEdJQ1Jf
UFJPUEJBU0VSLCBHSUNSX1BFTkRCQVNFUikNCj4+IHdoaWNoIHNob3VsZCBiZSBpZ25vcmVkIChp
LmUuIG5vIHZpcnR1YWwgSVRTIHByZXNlbnQpIGNhdXNlcyB0aGUgZGF0YSBhYm91dA0KPiANCj4g
RG8geW91IG1lYW4gImRhdGEgYWJvcnQiIGhlcmU/DQoNCnllcw0KDQogwqAgSWYgbm90LCBJIGNh
bid0IHBhcnNlIHRoZSBzZW50ZW5jZS4NCj4gDQo+PiBkdWUgdG8gaW5jb3JyZWN0IGNoZWNrIGF0
IHRoZSB3cml0ZV9pZ25vcmVfNjQgbGFiZWwuIFRoZSBjaGVjayBzaG91bGQgYmUNCj4+IGludmVy
dGVkLg0KPj4NCj4+IEZpeGVzOiBjNGQ2YmJkYzEyZTUgKCJ4ZW4vYXJtOiB2Z2ljLXYzOiBTdXBw
b3J0IDMyLWJpdCBhY2Nlc3MgZm9yIDY0LWJpdCByZWdpc3RlcnMiKQ0KPj4gU2lnbmVkLW9mZi1i
eTogT2xla3NhbmRyIFR5c2hjaGVua28gPG9sZWtzYW5kcl90eXNoY2hlbmtvQGVwYW0uY29tPg0K
Pj4gLS0tDQo+PiAgIHhlbi9hcmNoL2FybS92Z2ljLXYzLmMgfCAyICstDQo+PiAgIDEgZmlsZSBj
aGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMSBkZWxldGlvbigtKQ0KPj4NCj4+IGRpZmYgLS1naXQg
YS94ZW4vYXJjaC9hcm0vdmdpYy12My5jIGIveGVuL2FyY2gvYXJtL3ZnaWMtdjMuYw0KPj4gaW5k
ZXggMmVhYTQ4ZmFkYi4uYjM2NmIwNDZhMiAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS92
Z2ljLXYzLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS92Z2ljLXYzLmMNCj4+IEBAIC02NDksNyAr
NjQ5LDcgQEAgYmFkX3dpZHRoOg0KPj4gICAgICAgcmV0dXJuIDA7DQo+PiAgIA0KPj4gICB3cml0
ZV9pZ25vcmVfNjQ6DQo+PiAtICAgIGlmICggdmdpY19yZWc2NF9jaGVja19hY2Nlc3MoZGFidCkg
KSBnb3RvIGJhZF93aWR0aDsNCj4+ICsgICAgaWYgKCAhdmdpY19yZWc2NF9jaGVja19hY2Nlc3Mo
ZGFidCkgKSBnb3RvIGJhZF93aWR0aDsNCj4gDQo+IEFzIHlvdSdyZSBtb2RpZnlpbmcgYW55d2F5
LCB0aGUgZ290byBzaG91bGQgYmUgb24gdGhlIG5leHQgbGluZS4NCg0Kb2ssIHdpbGwgbW92ZQ0K
DQo+IA0KPiB+QW5kcmV3


From xen-devel-bounces@lists.xenproject.org Tue May 20 15:21:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 15:21:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990927.1374855 (Exim 4.92)
	(envelope-from )
	id 1uHOmD-000338-V2; Tue, 20 May 2025 15:21:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990927.1374855; Tue, 20 May 2025 15: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 1uHOmD-000331-Qv; Tue, 20 May 2025 15:21:09 +0000
Received: by outflank-mailman (input) for mailman id 990927;
 Tue, 20 May 2025 15:21:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHOmD-00032t-CE
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 15:21:09 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0d95cd18-358e-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 17:21:07 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad52dfe06ceso458059166b.3
 for ; Tue, 20 May 2025 08:21:07 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4cc7a8sm752504866b.171.2025.05.20.08.21.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 08:21:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0d95cd18-358e-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747754467; x=1748359267; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Kdg//HoaOC+XVQF0Tuk3ZZfVypmDhwbCo/5NABwZuRc=;
        b=WH5b/ZKZyjNumpXhJY/gp7CaLHIJSQOYLCSPEkpvLaGvzTKEmiTRkVVGf6i05wr4Bx
         FPhs95w59/H3X1RIUakHt/YpPi8twJZjJCHX6lqT6WTh7i322IWMZX4oaM8pLBju3QCf
         8EF8X7mrxkOFT+lrMz+c7dDQPSzHz8vr1DV/46RSeY2qtmAULNgeqTNWZUf+Et3KC7Xy
         kAsJLdG8vk7OGgaWr15I6rwVWda6xGaIt2D31rspNEOktB5n/TMlStIeFHiiZ02OZnEh
         kqulvFHKUiS8ovijMW1CA9eCED4xgNzMaiO4uH3flnouy/1fjtbNGiHSselFhxJuWiV/
         jhBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747754467; x=1748359267;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Kdg//HoaOC+XVQF0Tuk3ZZfVypmDhwbCo/5NABwZuRc=;
        b=WGhUAjih9LSH22YtbLXrsaC2IReTp4JMyNioXiNBrSBfvRT3JJI+YGHSGuuY1+dGqU
         4/jl5PDFrqd2c4+rQpBZAuheGQi0IlM2F7I6t0qLPjis96youfutrmAGitbKi3rY7vZa
         yrAemeWAtjRIxgJh+zqfwPoMBnH8DXclpWeBLxOOeQ6D7KafXO8CwVx/HZj39trAkmYM
         J/B/fiYXFJj3gNobhchfzdLSS9y22ZBM7aXuGVtZ4jKyTGZbJQblwnyVB5bRX9dQkSTL
         w668gSLTapPVaQ0Q+gdrVIY/4HUUHdTy/AOiiYyVc2ygmKeWo/PwJAcR9E4BRWwD6+EJ
         wcfQ==
X-Forwarded-Encrypted: i=1; AJvYcCWevxjze3UjzbJ56aIReIL7YsLGeqVDpm0UBTxepG5bzgyOcR4+sQ38oaWiSkUfB89Z/eeIhfOlFsM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxG+Z7CUBuOF7CUC4rlCiBI8hIs7Ej9jOf+RUsiAoCrSuS86y3W
	PumWpoXc0jLev7WShDYRLohARA59Z96k6u4aooHStGEtLr+sP4II1jFF3hpDVkCxOQ==
X-Gm-Gg: ASbGnctNCHqDtApAk4OD2dengHgarC1Egvy/FgF1611jWIF5czc1Pc+IMv/xc5vnPZx
	YsO7LJclFabSxoHxd7grT2Qjf+1n/9rYUzQS7vF3RhFldYLl/yR7w6dhSz05KCBQs8FoC590uj0
	qRdQr7DfAU+7CCbYnpkhxjOjhct3h6QH2hWS+zft34raJ7HIxaoSQDx4vxTk/625mP80VWd9Wa4
	eXWMivOq8TKBGopXDQJoeMIoLGipZlmA3MRXnYM2Z18KOTsRzn4IJqRn299ljxg6K+sEhd01vNZ
	hM3gZPfRj3gFlaeZKl9MeB8TwD8FMbsLcWwfsjwuGqzv0ScII5ed4Ghwkm53EQ==
X-Google-Smtp-Source: AGHT+IHajIpu5O6FJVFyzn/erJ/X8l7jYcg4NYHQIz1YhsTYD3IOgrbm2C5PDlKft6diDJ8wrNbaAA==
X-Received: by 2002:a17:907:7fa1:b0:ad1:e7f0:d8e5 with SMTP id a640c23a62f3a-ad52d4b3b69mr1819789266b.16.1747754467398;
        Tue, 20 May 2025 08:21:07 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 17:21:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/domain: introduce non-x86 hardware emulation
 flags
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250516022855.1146121-1-dmukhin@ford.com>
 <20250516022855.1146121-2-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250516022855.1146121-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 04:29, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Define per-architecture emulation_flags for configuring domain emulation
> features.
> 
> Print d->arch.emulation_flags from 'q' keyhandler for better traceability
> while debugging.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v1:
> - dropped comments
> ---
>  xen/arch/arm/include/asm/domain.h   | 1 +
>  xen/arch/ppc/include/asm/domain.h   | 1 +
>  xen/arch/riscv/include/asm/domain.h | 1 +
>  xen/common/keyhandler.c             | 1 +
>  4 files changed, 4 insertions(+)

If every arch gains identical fields, accessed from common code, why would
those need to live in struct arch_domain?

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 15:22:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 15:22:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990936.1374873 (Exim 4.92)
	(envelope-from )
	id 1uHOnN-0003gY-8w; Tue, 20 May 2025 15:22:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990936.1374873; Tue, 20 May 2025 15:22:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHOnN-0003gR-5r; Tue, 20 May 2025 15:22:21 +0000
Received: by outflank-mailman (input) for mailman id 990936;
 Tue, 20 May 2025 15:22:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHOnM-0003gG-B1
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 15:22:20 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2613::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 377af172-358e-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 17:22:18 +0200 (CEST)
Received: from PR3PR03MB6412.eurprd03.prod.outlook.com (2603:10a6:102:7d::8)
 by DBBPR03MB6843.eurprd03.prod.outlook.com (2603:10a6:10:202::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Tue, 20 May
 2025 15:22:14 +0000
Received: from PR3PR03MB6412.eurprd03.prod.outlook.com
 ([fe80::2887:9068:38f6:8340]) by PR3PR03MB6412.eurprd03.prod.outlook.com
 ([fe80::2887:9068:38f6:8340%6]) with mapi id 15.20.8746.030; Tue, 20 May 2025
 15:22: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" 
X-Inumbo-ID: 377af172-358e-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iBjvGbu/0vmUtunntwx9tn67GFW2jT+88JyiNxyrDhVgQOWbJ+IqVzkLZGfzEwg0IOH9a4Ew3sPx9pucWrsqkjp218Jgbh4VUbAeJakVsgb3YyR58FF3VAVtc5ehpVNKmZBRsOjlRJr7s/DbvXFiEym5pFg9sVKohYZXlObOC/cm1QFl7dNXbxKh1g2dNnbrS3UuSowa1ORNEk9bQjCN+eUZqup9OKQ4PQSHLgim93MjmmBELidHlvvNo9X+G20lHNeGzSPXcndNkw4Xmd7noIV5eqs4JoVUdacEZKYeQlwyJ/sPrhtZlmhxETgzcEHMWBfTsRtzEGIByijZgBDOHQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=X7DJWiPDJy5PhRYCIIt7cSltDC5ZIuEapP0V3N+U8G8=;
 b=y1mKHNXD5wMNiO9FVLGEFdOziI5VrNvOrWREJlPC2tHyUscAK7ixfIhyFPkmRz9fFserxTGCTZEbCz6J1N3tRuiQ/mMFmsixs+saXSZUVK0ZqGay/I8Dlj6Oz9sj66OAhRIRxCnQXKPkd++lHBYH/l9vAmnxQ5kswvt+wbuxBsAD+d8ilqXQxfw5bvU0Eqf/XGji6BnBtHYrkEnsxBZFyFnhQGG4pyJY/cGud1rFVhfb/w2yFcXXkPOQ+0Inz+laSduikycA9l8gxMhH7wbP878njtYqanjV1jESxCkA7FYGDnHnYuCBd9FSqKhM6rtS8c5/E/V9TIwRzwyIuzJdcA==
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=X7DJWiPDJy5PhRYCIIt7cSltDC5ZIuEapP0V3N+U8G8=;
 b=RCFaaEbwco1RRGGRyfSpTt2NGPyXPgXbVDcUcjT2O5LuskV7HgtB8UaaabCYU8FgrcIecoNqnYiYYgr1sr4N/g76Ra/LytjKZRJU8kLP10RWZXC2JWQSONmFrfcxID7kJn0AA2iEStLEDdH8DpN3JykMTeRGAQBlKiUUa07f/fNzm4VWrcGyCW4ieumGkMy9WM3LrBqsciPbMpqLYFyxbH5G7ZZ//kopt4/xCZa0Tt/+Gx0Gxw+neijLEpor1xUPOwTojK9RWW1xZwitEvSXPe7OOovyZ7BCOCIEvruzoGg3PasMj/NBds/vtVaevsh/c2iw2LSXdnnlWZDvmgIZUw==
From: Oleksandr Tyshchenko 
To: Julien Grall , "xen-devel@lists.xenproject.org"
	
CC: Stefano Stabellini , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: Re: [PATCH] arm/vgic-v3: Fix write_ignore_64's check in
 __vgic_v3_rdistr_rd_mmio_write()
Thread-Topic: [PATCH] arm/vgic-v3: Fix write_ignore_64's check in
 __vgic_v3_rdistr_rd_mmio_write()
Thread-Index: AQHbyY3It6QrN0GxI0mChLdwI1GDxLPbnUIAgAAFjoA=
Date: Tue, 20 May 2025 15:22:14 +0000
Message-ID: 
References: <20250520134751.1460968-1-oleksandr_tyshchenko@epam.com>
 
In-Reply-To: 
Accept-Language: en-US, ru-RU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PR3PR03MB6412:EE_|DBBPR03MB6843:EE_
x-ms-office365-filtering-correlation-id: 4b3ed164-1bb5-4a14-60ba-08dd97b2198d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?bVBUdDJ6ZjBBWk9pLzRQaVk3SU5oWllLVDZDZW5JY0IwWVJCWnhxdHZlUG44?=
 =?utf-8?B?dWxkRVF3SEszVmxwcTYyV0NoZVg0ZGZoeEdxVy9HK1I3TElKSHZWd3o0cGh1?=
 =?utf-8?B?YVdRUU9JNlpqV2dyYnJCMkltVzVRU3RBalZOUzREd3JOYUcrRHBweGZaMjBR?=
 =?utf-8?B?Z3hjYmdGWTZoS0Z0N0N0SEFSUGlrb1B4RC9GRmgxeFNBU1dsOWNPelBFZnli?=
 =?utf-8?B?Y1YzNWNmNlhlZnRVOWFka25oK2dMNm9EL1ludEJHcTVCYXZVNzV4eS80eDhI?=
 =?utf-8?B?TXhGdG1RTmNUVE5keE4yZExrSUJyNFRqV1kweEt0VXd5MEIvUmxHMllPQ3hs?=
 =?utf-8?B?eSszdmp0aXVTR3NwZGt3QmFOYXdwQlVqYVRlcmptQ0ZSSjYwYllwb0pNODVp?=
 =?utf-8?B?VmpJVGNONHVHakwyWXR0bnBTRERHSS9NWVpid0tNT2FDRDBMcm1YcUdaSGdY?=
 =?utf-8?B?UU1aVi9hL1dPeDRYU3d3MjJLZ3BEWmtQcVMzckttaFdncWl5c1AvRjY5VUpo?=
 =?utf-8?B?dHF6RmJmek5WVWE3OVVBNlJMd281SklIOE1KVVBpQVoxbCtFQUd2bVNNbUkr?=
 =?utf-8?B?cHdRbzBQdGZrZ3owblRHTEo3WEplR2tJcHVxVmE3RElVQ0NQVU5pMXl0M1Ni?=
 =?utf-8?B?b294V2R5eUNxOXByTlI2NU5MaDFSQjEzVHZkYWxORm4zaE9SR2s0NmN3VU5Q?=
 =?utf-8?B?WU1hem9DNkgwbFFMK1lCSnlHR2U0RkVBeWljYlFORmMyVjdvR2R1eU5ML2xV?=
 =?utf-8?B?Qnd2WS9mZncrYnpJUTg2TitXRFR3R05FN3lRblVqQXZiek01TWJ1VUhrQTVY?=
 =?utf-8?B?dERWTnVlb3l5UEx2YXdkdmVIWjUzS1g4SDZRQVE3MEN4VERTYmozMmM1YlpW?=
 =?utf-8?B?Rmt6alhmMW5ZRTBDSHN5OVpQSmxpcmlVdlUrUkw5bWoyQmNoT3pFbkN5TU5D?=
 =?utf-8?B?UGpwWVNZZDZIT0J4ZG5xbTM2VUtBajRBbE51WWxXa3FnMHpCWmNCNnRYOVJO?=
 =?utf-8?B?TDk5aCtoYnZUNHRMRlR2dGlzSlJTUTZoTUQyUzF1bmFiWlQxMEQxL3lWN25B?=
 =?utf-8?B?WTI2QlNpdkMraytUM1pLeEdPOU10MU5TeE84WXQxUlUxRjFMeUhDbW9vSlR6?=
 =?utf-8?B?T09ISWoyWjRtMTZpejBZRnRlZGJuY0JBSzc4MGR0STdCTm0zdjZoQzBITGNB?=
 =?utf-8?B?S3Bab1lGZ3VkUzhFakxwdkQxaWEyZjBBc2p3cUVUU2FGRWJKd1pabFRuTUdX?=
 =?utf-8?B?cHAvMFJaTENLMXdUOEFmYTBPQjRmV3VNNU9ZeDJ6VXVZUW9tOHVFVTl4M2Vn?=
 =?utf-8?B?NG9WWU9nRTFqM0NHN01haGxSdUpnRUU5NzNpNFpNQVdBVjMzOUF6VkRrV0Fh?=
 =?utf-8?B?a1RrUjN5SVlPMjZ0TTV2Mk5wb1hYMis1QXptL0JPbGFEMWVDL05ncjZnbjV2?=
 =?utf-8?B?SFlSMTZ4TkdZS01iQ0RnY0JONDEyMVdOZUl6ZlBlZjRmbnUyb0FvOW1GWDdI?=
 =?utf-8?B?SlIwWDBwdXFJQnZCR29vRlcvTDl5d1lzcnpFaWdnOHh3SGdpTEdLQlBIYzAx?=
 =?utf-8?B?dlRYdW1TcTZieCtDeDJQeUE0ajlrZlpLRExwTG9zOFBDMDRIdmR6NDR0VDB5?=
 =?utf-8?B?aEJ0MFpHN0Q2bUxHY0w3UUVyVUlIK3E4ZmkweVJIZkNuU2RGQnZvNlppcjFN?=
 =?utf-8?B?Y1kxeVVnbk9IWFhRZDBwNHFTejlra2duUVFFSSthV2s3eXhnQzlyS0ZvazBL?=
 =?utf-8?B?YmRMVTJGTU5EcnJ3VHdYVTRyeUhHQXBYdjB4WFFiUmRoQzFwWk1ST1FhNTBL?=
 =?utf-8?B?VzJJYjRTaDNaOU1vSU9FWUtQYmY3WGdSS1VhTEN6d2ZtMGV6OGdJRTJGSnAv?=
 =?utf-8?B?eUZ0ZHZQdURDN3JXZkxITTB6WmhNZGU4VDNaS0FHQXZZaFZSUTZxeUUvMDFo?=
 =?utf-8?B?K1hheGZrckViazc2Tmo1d0ErNW9Oa2FUR3ZKcERRMU9KTFlVUDdIeW5UZFIw?=
 =?utf-8?Q?/5tZhzLI0GP7zDniTIfeHvpXnyqn0k=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR03MB6412.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?RXBQVDJBeTk5TUU0QncyZE1YOU90dE9ZRlBrSUNKT0hiNHpnczVoZXZ0aXA2?=
 =?utf-8?B?OFBrVGhEZ1hoQ3ZzSSs4NEtaekl2bmF4M0RqS3Jlem1nNUdyY0lMaVJNZ0lm?=
 =?utf-8?B?aW4reE5TMldNNnJ2c2QwSVQwaDE2OFBWTGxvcWtuekltV3J0emdhb1VtZmc5?=
 =?utf-8?B?R3VNcEwwd3lUUzRkQ0hQMVZYVmRjdlQ1M0pTWE42MnJwcGREZmlzUVpOLzJj?=
 =?utf-8?B?QUhPNG92SHBqR0JTckJLVGVuL1dEL20yS0ZxQ1RMOGRaZHY5ZlRrK1FQdENm?=
 =?utf-8?B?R2pEVmtRR2tTL2dUckdQZzEzM1VnNkNLUjBKTHFnNktkV2NmeGZwNXoxREl0?=
 =?utf-8?B?eEhhSlZMRGpiY3V3elY5TDFXV2ZjNkVyQ2tBRUxnc3puWUF5NHRNc3JCUkIr?=
 =?utf-8?B?aGk2UVQrbnVMSzRCRHFrNjFQOHk0cWliSjNhUUJlUE9nREhvWG5ZVlVuVDAr?=
 =?utf-8?B?SWFDUzlkUXZBcnVUNXFnUm1UUmpKaTl1eXRNaU1LQzcxbjJWZCt0VGNtaklS?=
 =?utf-8?B?Nmg1RE53dEg3MDhNbVB6UjF3eG1xTEk3YkJEREcwQk52dUJOamI3UThBKy82?=
 =?utf-8?B?V0dicVlsRytrVk9sdWtDaUg3UXNzY3BFcUpBOVBnekxQUFUxSWRmQ0F6cmZG?=
 =?utf-8?B?cjRkejdlRHFnVlRITXZ3RTlFZkFCUUVmSGpLbTVhNlpvWVgwNjRlWHYreDBN?=
 =?utf-8?B?K0dqbkJvcUI5SmdDd2xLeVN2OVhtRDRRUVRkNHRWZ3pMT053RUFKb1hzLzhG?=
 =?utf-8?B?NThRQjhyaEZhSjlyZ1h2emRvWDQ4UnpuTDEzdTRJdFRBL0NJSmY4NCtHcWlj?=
 =?utf-8?B?bGQ1ZUNDYzlPa2lSWG9Da3lMeDlhQkpvYlNQQUlPR081MVRFbEVYeHBHR0dY?=
 =?utf-8?B?dGxlME82akVuTno0TFZhak9saUtEL2NQUEVQdGlEc0NFV0FEb042TmNkdzE0?=
 =?utf-8?B?VEx6L0NMY0xYN2d5V3dBRmtoUHdjemVVMkhCWm9ONENGSTUxUzJJVDFDNU1Q?=
 =?utf-8?B?Z3p4OWlOVEV3KzF3NGlYeVhtOVBwd2ppUkllRG5kM1hVd2RLeXI1MW81ZG1R?=
 =?utf-8?B?VW5QN1JLOHRzdlh6TFJUL1AzVU56Nko5VzFzSEN5eEFieWl3NFRVYUhYSFdN?=
 =?utf-8?B?cUpvUWFYblhLb1VFcWgwL0JuT253WnJ6VFNvRkZpVURqQVVEK1ZQYzNTSzZn?=
 =?utf-8?B?UjNRNUxra1dCTksrcWVKNHlEL25teU9nSzlTejNLbjZIQ0RVS3FndVZaS29Y?=
 =?utf-8?B?OVdRUHZ2MnZCVGs0VmVmTHp3UURNTmVMTCtKaVdhV0wzS1BDOFBvNUdOd29R?=
 =?utf-8?B?VHJMbjBWVDZSYjExVWhzd0lYM1BZeG5GZVJGbk5PZmljT0cvQzR5Sm1HL3ZM?=
 =?utf-8?B?VTlSajgzTnNLSERmNVF0NnpXdFNLc0Z6NXBGeVpDSDJFS2pNc25kOFo0dStD?=
 =?utf-8?B?dlAwSnVvMmMyUG10VUxmbVpqS2xITW15RFRkR0NablBGSXY1N3g5RTRURWxY?=
 =?utf-8?B?Y2VWcU1GN3VYRWRybEMvMHhLQTg4TTgvV1ZQQmpmVktsdXVsYnJ2QkNkY1ZH?=
 =?utf-8?B?WXFHQ05YNjIwRUVqT0wrbGdmZjRKak9uNzBJeDlYNDZtWlBsaUxYOW96eUlz?=
 =?utf-8?B?UmxDVzF4UTNUTXBJYlNKT3E1NEUwYzdCVjdhdm9HVFFmaVk0eXNWNW44R0kr?=
 =?utf-8?B?L1BOajJ2UU5QOUFQNlN2MjlUS2UxblZkWHdtSWJ1OTZPMjY1WHpLQ0RoV1B2?=
 =?utf-8?B?QmpaSUIyeGt1bWMzY3NEcTg5WlFnNlR3cVYzaHFueDlzakIvSzZvR0RBVTF4?=
 =?utf-8?B?RklJUGdiaWdoTDh0Z0tCc1RuNXdRMGhZSjF6b1o4SURIdEQycEhvZzJsVE5G?=
 =?utf-8?B?VDkxOFJveWJSc0xwNUw0RU1Ua1pzRmNWRG8vcEpXemE4U05qT2s2eHdrc2RH?=
 =?utf-8?B?dW1vQWhXUXVYK21sZ0ZCdXNBVkk2OWlsSlUxQlVsQ1BqOG5wQXFTUWpHaFBk?=
 =?utf-8?B?TkMyb0E1cDRlS01BU2s1czFuVXpHTjlIWXNGYml1V2Nwc2xTa0hQTzVBUVZt?=
 =?utf-8?B?aHBJRWtacHNzNWNQMXZ3K0hHQmhxWUFaTVVuMW40bU9vY2p5dE5wWmo1ZGRU?=
 =?utf-8?B?UXRuaTUybEo2V3VSSzlQRXdxWE9ycGJURWkyMi8rWFpqZFFmN0NIcnhUeTM2?=
 =?utf-8?Q?5Mh0BC1YSE9zH1Wqz3jouEQ=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <2FEC29AAE566E541BC0CFC68E1EF3A73@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: PR3PR03MB6412.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b3ed164-1bb5-4a14-60ba-08dd97b2198d
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2025 15:22:14.4820
 (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: D31/BQsA8aCetpT8nmFzsTDaI5S2AKiIueeeVVv1KAcdUYcQBV8vZWVnfiX+LGBmfzEDlvAZWmr1PfxsPqyOlA+Sd0bK/I2WfchQEBqIRpA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB6843

DQoNCk9uIDIwLjA1LjI1IDE4OjAyLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+IEhpIE9sZWtzYW5k
ciwNCg0KSGVsbG8gSnVsaWVuDQoNCj4gDQo+IE9uIDIwLzA1LzIwMjUgMTQ6NDcsIE9sZWtzYW5k
ciBUeXNoY2hlbmtvIHdyb3RlOg0KPj4gQW4gYXR0ZW1wdCB0byB3cml0ZSBhY2Nlc3MgdGhlIHJl
Z2lzdGVyIChpLmUuIEdJQ1JfUFJPUEJBU0VSLCANCj4+IEdJQ1JfUEVOREJBU0VSKQ0KPj4gd2hp
Y2ggc2hvdWxkIGJlIGlnbm9yZWQgKGkuZS4gbm8gdmlydHVhbCBJVFMgcHJlc2VudCkgY2F1c2Vz
IHRoZSBkYXRhIA0KPj4gYWJvdXQNCj4gDQo+IEkgYXNzdW1lLCB0aGlzIGlzIGEgZ3Vlc3QgZGF0
YSBhYm9ydCwgcmF0aGVyIHRoYW4gWGVuIGNyYXNoPw0KDQp5ZXMNCg0KPiANCj4+IGR1ZSB0byBp
bmNvcnJlY3QgY2hlY2sgYXQgdGhlIHdyaXRlX2lnbm9yZV82NCBsYWJlbC4gVGhlIGNoZWNrIHNo
b3VsZCBiZQ0KPj4gaW52ZXJ0ZWQuDQo+IA0KPiBPT0ksIHdoeSB3b3VsZCBhIGd1ZXN0IHRyeSB0
byB3cml0ZSB0byBHSUNSX1BST1BCQVNFUiBpZiB0aGUgSVRTIGlzIG5vdCANCj4gcHJlc2VudD8g
V2FzIGl0IGEgYnVnIGluIHRoZSBPUz8NCg0Kbm8sIGl0IHdhcyBqdXN0IG1lIGV4cGVyaW1lbnRp
bmcgd2l0aCByZWRpc3RyaWJ1dG9yIHJlZ2lzdGVycy4NCg0KPiANCj4+DQo+PiBGaXhlczogYzRk
NmJiZGMxMmU1ICgieGVuL2FybTogdmdpYy12MzogU3VwcG9ydCAzMi1iaXQgYWNjZXNzIGZvciAN
Cj4+IDY0LWJpdCByZWdpc3RlcnMiKQ0KPj4gU2lnbmVkLW9mZi1ieTogT2xla3NhbmRyIFR5c2hj
aGVua28gPG9sZWtzYW5kcl90eXNoY2hlbmtvQGVwYW0uY29tPg0KPiANCj4gV2l0aCB0aGUgY29t
bWl0IG1lc3NhZ2UgY2xhcmlmaWVkIGFuZCBBbmRyZXcncyBjb21tZW50cyBhZGRyZXNzZWQ6DQo+
IA0KPiBBY2tlZC1ieTogSnVsaWVuIEdyYWxsIDxqZ3JhbGxAYW1hem9uLmNvbT4NCg0KdGhhbmtz
DQoNCj4gDQo+IENoZWVycywNCj4g


From xen-devel-bounces@lists.xenproject.org Tue May 20 15:24:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 15:24:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990950.1374899 (Exim 4.92)
	(envelope-from )
	id 1uHOpa-0004fX-Qy; Tue, 20 May 2025 15:24:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990950.1374899; Tue, 20 May 2025 15:24: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 1uHOpa-0004fQ-NG; Tue, 20 May 2025 15:24:38 +0000
Received: by outflank-mailman (input) for mailman id 990950;
 Tue, 20 May 2025 15:24:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHOpZ-0004fD-Ei
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 15:24:37 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 892060fd-358e-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 17:24:35 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad56cbc7b07so340820166b.0
 for ; Tue, 20 May 2025 08:24:35 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d0717c3sm753641566b.65.2025.05.20.08.24.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 08:24:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 892060fd-358e-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747754675; x=1748359475; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=s9q6aaOAVXpxltmr70zrORYazBV2HTcHNQJLw+kK75U=;
        b=NHDWZYnfoK5KFNpS69oWiePKk+nzzVaECOzBY0MkjIK9fR1xRt5KZNU+DKb7Oa7ryQ
         LUjjiAGHuGLfUx2Axohvv3RI1T+PoGqjLSqFbrdF7iFd2UjLE5iiy/0qfqs/8oJ4QmNp
         jiXhLR1Q8whagxyI2DU4y8Hl4Fh/X4u3OIYDs2sEDL/v9jpUGfZbylkr7GdqicgpSC9R
         HJp8MMyXQqufsjP2zxzV34xC1zl3bbBOeE4q4DgnXXwC2KwTun0db0Pl7KQyZxk3/xjH
         7HrGweh/Ni20fQxXVuvEWRuVqWe7QLE21fkGFt/UTWqiZLx7tu+e19VnCsgkjgMIoaRa
         r0nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747754675; x=1748359475;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=s9q6aaOAVXpxltmr70zrORYazBV2HTcHNQJLw+kK75U=;
        b=KKp4vGd9Aop88usxbsLy+S9jxiBddKtBv61MZlgo+Sv1ykmettW6ltgEn6kMM9ClWM
         wiaFU1hju2BTJBU6CqjdfJM57MgXUhTAvVXvBR9WKOJgPtGqq5UWy9jbA0pXCIBvNcnv
         9X+ZlbXNHycog0wnsM3P332mdO+xjs67I2w3lKhZeqrSQZzhOXZIaGWQ0o/TEuZSs+WI
         1oyurT8PWcKrEG41iJ++GTMoh6coqnE278bw2xOWhtZH0qqAzn12zzGdnh6DK5W3M3Td
         0GU0Glndz9pni2cN/DI9jHvVgxSJfEpLqSf1FIg5QEwuvu+zAa71q/Rq5yL+1hcppTTZ
         h0nw==
X-Forwarded-Encrypted: i=1; AJvYcCXel4e8qBHsFv5LmDWwx1l1sw7sgjTQkv7MKcemvW1WeM11YxjDmvlgQr3uMRblsQk9WLlWxtDCiWU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwtP5V8UYoaqx5x9Zcz5xV45wUkcJBVs9GRFETjh/imBjhj/yA5
	eqd1tp64zUdWiiswaqKq7wCpWYzp1RpOhbhSKGNasAp8wroDJAkMlvf97YzjnL+Ykg==
X-Gm-Gg: ASbGnctMIWib9xjQ+je/irq9q2tNdBmZSIpVkXdEDuFDoEPaL1D9AU3Q348bEG+vq6P
	n01pc8ybsueTbWqXAysUJwyLfrkjGDRpYQe3uvfBF2wnSNp/vLmICiPZW4TfenP9J/eEf8fYzVR
	I65vVFTomXRzm9vYT/2o3On8yBi2rgL8nizTPec7jgb9sFBLRJHQge8FLVdrZ40cRo+zk47FmTE
	dNu0AIw9cVcXL5+Ynx3YfmuZjyDOPNqRu11tOFp58NBoEeMq7RCunnenpem8weL/Vz3zDhD3zFM
	q57iKiaN5PwXlo3Wy+FA3/p2E4dJ84AXEa4+vPoYxR3xqoKwC7WUk9YIYP5EiQ==
X-Google-Smtp-Source: AGHT+IGEZi1+KEIPWmYt6F5HNa3b//jxjEPjhWyxM+ecNqoBJBcnDzk9DiW1gsFi2LezaCtU4Li2ZQ==
X-Received: by 2002:a17:907:97c6:b0:ad4:cc66:1524 with SMTP id a640c23a62f3a-ad52d609746mr1683242466b.54.1747754674529;
        Tue, 20 May 2025 08:24:34 -0700 (PDT)
Message-ID: 
Date: Tue, 20 May 2025 17:24:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/domain: rewrite emulation_flags_ok()
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250516022855.1146121-1-dmukhin@ford.com>
 <20250516022855.1146121-3-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250516022855.1146121-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 04:29, dmkhn@proton.me wrote:
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -494,6 +494,12 @@ struct arch_domain
>                                   X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
>                                   X86_EMU_VPCI)
>  
> +/* User-selectable features. */
> +#define X86_EMU_OPTIONAL        (X86_EMU_USE_PIRQ)
> +
> +#define X86_EMU_BASELINE        (X86_EMU_ALL & ~(X86_EMU_VPCI | \
> +                                                 X86_EMU_OPTIONAL))

That is, VPCI is neither baseline nor optional. Certainly at least strange.

Jan


From xen-devel-bounces@lists.xenproject.org Tue May 20 15:53:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 15:53:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990969.1374909 (Exim 4.92)
	(envelope-from )
	id 1uHPHM-0000Zl-Tb; Tue, 20 May 2025 15:53:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990969.1374909; Tue, 20 May 2025 15:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHPHM-0000Ze-QC; Tue, 20 May 2025 15:53:20 +0000
Received: by outflank-mailman (input) for mailman id 990969;
 Tue, 20 May 2025 15:53:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHPHK-0000ZY-Li
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 15:53:18 +0000
Received: from EUR02-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur02on20615.outbound.protection.outlook.com
 [2a01:111:f403:2607::615])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8aeb7b89-3592-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 17:53:16 +0200 (CEST)
Received: from PR3PR03MB6412.eurprd03.prod.outlook.com (2603:10a6:102:7d::8)
 by DB8PR03MB6155.eurprd03.prod.outlook.com (2603:10a6:10:141::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.31; Tue, 20 May
 2025 15:53:13 +0000
Received: from PR3PR03MB6412.eurprd03.prod.outlook.com
 ([fe80::2887:9068:38f6:8340]) by PR3PR03MB6412.eurprd03.prod.outlook.com
 ([fe80::2887:9068:38f6:8340%6]) with mapi id 15.20.8746.030; Tue, 20 May 2025
 15: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" 
X-Inumbo-ID: 8aeb7b89-3592-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ndq+R88Z0Nd40WYJ9tJBuR6KQcNv84s3dOWikixa2kDFpv/9zypoQT0JVqdAaTo9J3KmH5PnpRK1q2gd9W8S5nVZsClop0MaFcoTEpExAKG/z4EGggrMAsrFJlmR1LFCbTgtfvCqIEN9LPHXzaOJUX0B83IwTMHSkcJ6YTlBLB9ufUdUHhJjGQhILhM42ROp8Xg6rx4NmKWxJJtTvp499g5KwD0M74uxVYS7Y34Y4YuT8B305AKNcsuKhwsnQnONrUUuzQgjsk0juDJ2ZeSNOa2Y05qNc2tCbOnmY+jBTPF0qmjKbtcLhlcauUo1/AI7jRWK0+Nol1AxEt6lbNeEkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=oT2PHo91Kin9htf70Av5ZJswwWgCA59U8JvihiA5XxI=;
 b=zUN7k39atyzVwVdtZUixZwdTqi7ijQuh2YCHo1OKIgL+8dCpE9NUs+cfnVONpyv1R9lkz7nMp/a/6AjdBrMPWxa1RMWZzQEAmsOz51BCndevX/uDxoLDRllsjjrZNwEUZuez1zq/p8uF9D4Tg/bPxLdIPq15PkGo7h+9TPcHRIu/Rwnb2LfJ43jA+4vyq69Yp86llUiyphhiSX+18yUWFI6Bbj6IP2NIYyKGjTYGbrgA5zwW6SHL/63GLUDVicDpJ8jQ2ObyVvjzJ3OtHJczol5dlrpZ4Y/bM1ud9r0NtTZ5XOjLHS0SAX6sx8LRFVj+O2ycqwngivGHPbUeICm58Q==
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=oT2PHo91Kin9htf70Av5ZJswwWgCA59U8JvihiA5XxI=;
 b=YvGjee1Cg5V0iB9iYAZkHKqGNvmSH50h19rM/99jarukLeHEvRs7BST89Y/B464Ytp7fSAlryAaVZH/CsFE2jW7EekWgeh6+DLjhalQl2sYcJlCAmSn7f3lnIjDO4Y7uMXi/R20qfDY6ZvZA8xRz4rkThXWWYvb7PlGTLj6PJkLwTxbGl6t8Us5lA+VkBHwTgyvh/rMId045txHay+mOb8mOcqf9gIDi7HWztY0JGFG3pmaN0PJRAGTfG1yQfKznu1XHCgJGfOt6KN1gdTUS8tdRamu312dFK37CaQbgt4yPvHN9p2k7ZXH3IMVHKx94PvFg/l9z2e0ZfEzK08rO9A==
From: Oleksandr Tyshchenko 
To: "xen-devel@lists.xenproject.org" 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	Julien Grall 
Subject: [PATCH V2] arm/vgic-v3: Fix write_ignore_64's check in
 __vgic_v3_rdistr_rd_mmio_write()
Thread-Topic: [PATCH V2] arm/vgic-v3: Fix write_ignore_64's check in
 __vgic_v3_rdistr_rd_mmio_write()
Thread-Index: AQHbyZ9LliRAEJcwbkSH1It1IBBGkA==
Date: Tue, 20 May 2025 15:53:13 +0000
Message-ID: <20250520155312.1509693-1-oleksandr_tyshchenko@epam.com>
Accept-Language: en-US, ru-RU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PR3PR03MB6412:EE_|DB8PR03MB6155:EE_
x-ms-office365-filtering-correlation-id: ffe4041e-70ec-4c27-5544-08dd97b66da7
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?/PWOQHgdvmAADoadHiKLqjlDTKXdHeaBER2XAwSIa0ohO953iKq6Zg7U72?=
 =?iso-8859-1?Q?lTheUHZE0U0BiLwuzVDh/bhL7BopTQepCOS+9sXZsbpx7lN4BoBpWOhKNQ?=
 =?iso-8859-1?Q?q0ow7jWY2YUjQYmToRgePzZgCheaOKiTRPgrtgVTq51JqM9WS8/wrOLpsl?=
 =?iso-8859-1?Q?gxy8Fb8A1Yl8yyNg5T4c+dllrmswojrg6giXquAvMmTYVF8/k7afdc7O9n?=
 =?iso-8859-1?Q?Htgl2qp/Y3MPkzTFWdirkc3kNpenIk2ffFxM2eMxk0imEIlBilRRyaSPS4?=
 =?iso-8859-1?Q?Cr4ABF8ekWspX/nHdJUfOmDIx9bwXZGJIjD/MbZL0Fovh2X3ZIjsFY8fIi?=
 =?iso-8859-1?Q?n5pDGHCaEjs72j10VQd+Bu0YKqeuT6vNYFnZHTVK69VUAJkhVB/UBsvt0N?=
 =?iso-8859-1?Q?8Vu5LKHt0abYU5mUlLY2KLNW/Dvh+KcQ6+UMy19AonXXt5uiyUiUxNfCNT?=
 =?iso-8859-1?Q?9ksWJvJaBgCFUuI+3ukaOAj/Bo7gNJqaXZKgUAaceMlF6BmezbiUN4laQX?=
 =?iso-8859-1?Q?t95vIsC/8KMgrWZlGDaaDhcEuSEM/tcwwpT7jinx3Y/uPuS3fCaJTt8V6T?=
 =?iso-8859-1?Q?Uy5w7RiRc22tRMSJA1ZGUc9ULf0F86YIGMKudaGVU0dLjxc+Ovm7WFWuCq?=
 =?iso-8859-1?Q?vNlitz4d18OdnvJC6W0Sx7ELiUw9tchIU7zPnJOYV28WQ5MMzqu0WG9HCY?=
 =?iso-8859-1?Q?JuTgk5g9MumiMQQJr9dyadfm1GwYwtEYjLpRzWhqt0y+jCHFU2EgPqETqB?=
 =?iso-8859-1?Q?07qZjSdcdgf+bFqGnIxnWStXheS3B1hv8p6iGrerAgDtMDDFNcqMZbBjmf?=
 =?iso-8859-1?Q?1968yh/nFAhw4/0u4pHXLGo9S5dXneLd7A7SRLiJ/hriYiku9/Kgs8z01e?=
 =?iso-8859-1?Q?eIy0F/MDTEvB3i866QTxKZu+9GCS6J0cPMvMkp2tRs89UJ7nJ/7rHW9iyQ?=
 =?iso-8859-1?Q?G/+/ddoEEy2CMWYGzpM3Kg2FlIUkig/9lADLpJ+ctfZOPd2eMsjTlM79Uq?=
 =?iso-8859-1?Q?Ur/0CJo+kxeJ4MB2/CrSdLIPiax5jdzJCHhHz02U6RvQQaJHs9p7wFkqid?=
 =?iso-8859-1?Q?5TYA0tnJBr2zXM9mxGHt+ggS9EKdThJTUtsuRG6bFmYKjS8pzaQO0YGS/a?=
 =?iso-8859-1?Q?Mscr/WxsphnhWPjydnxgBoExf/Qbr2nltEQ6ZD/3WeWKmeWXa4AY0PPAT/?=
 =?iso-8859-1?Q?ee1nrBK50GkUtRCyE6ERqryXeJFVh/2Q6BUE0Ofnt91xHI/2UK7Bt4dbZ+?=
 =?iso-8859-1?Q?L0uhMsYWH4qwT42zCLY5WtGBvjfRxrf6CfAHzmInApO2Cdo5PsR2giWbnZ?=
 =?iso-8859-1?Q?tt0UNvGR+Z0YQd3eiuv+gBHxBsalM8UeEevG+G7jFvPJc++kQty2/Dcne0?=
 =?iso-8859-1?Q?0dzU1PvoChKB9Ab6BPd9rztAGgYsuxWnjaCsogNX7u6uthCKJoQg9r8GvU?=
 =?iso-8859-1?Q?sm9i0XAfrv+20oIcupUSsERcpRZShSgG8KA62KFp6CuMi6RX4PgXJKaVJd?=
 =?iso-8859-1?Q?TYzoyH0buB8667pxZTTb20x5YtsXzxnT1jRcVYImwvEx5dLMqtc8ehVPNv?=
 =?iso-8859-1?Q?LI72UmM=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR03MB6412.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?6ZUhtg0Xy/44Dao41chZmJfRQAd/RXRnBg1TXZUiv6dIzjo0NzqLRWTe2e?=
 =?iso-8859-1?Q?SlmfjtH6zwm2FXHNrZhEDZSEtRx2exh+S6B/hgjUv8EKPcaJG1bdmFfA+z?=
 =?iso-8859-1?Q?YSDFhcsFj9pEVygoQ2yrAfdVmW4jq70eF9gmnbIlitgk61pA46n0RTO0dD?=
 =?iso-8859-1?Q?ja98pzJIRktakvPhcxVkCysTDsKI/nhYMaKVt+Q4QRTqKeSqUlxiOdDhQU?=
 =?iso-8859-1?Q?4eC2Bs2BHY75mGgJ7GMHf8rS7W6g+ZZEtIyYSg/udY7Z1ptxq6OOG/biCC?=
 =?iso-8859-1?Q?OJY1u3FKc7lWMGNuOOLserbobd97zuL6+v3xlGDYCUHBoM2E5WszHA/BDS?=
 =?iso-8859-1?Q?dzj6C4RNot1lNHFMX6/U9QBgVNDeUzmFiE6Mr5zd3SgL/iKW2z6F6huVmI?=
 =?iso-8859-1?Q?4hqPLF2OJphvmOd4Qc2hntAV28vwfOQEgwwutcI+BsEKRIaOB1LfmEGK8/?=
 =?iso-8859-1?Q?zYbpfJIMjl83CuBoUY3cYWyY7acQIUjeKZJKpu0f0CiqA5+J0ydHDiBQVb?=
 =?iso-8859-1?Q?TudotSSWyV2ra3iYXLFAsQWW1R/iEM7svaOuvGZe9Eya/5IFjONqufsdGJ?=
 =?iso-8859-1?Q?gbctUaGwoZvfqBh+p2AyNsiIqNV4scKiKsMZXPYsVuJ7bt7jreNvHhacZU?=
 =?iso-8859-1?Q?s0lmkmFSbOpiKMeY6JtvE9jy6gbYYCQDiWuxcu0e/RjFNv0FEfqW9Df6IN?=
 =?iso-8859-1?Q?0JWEqpewBPQtmFsxu+ocFZv0/9xV4BHxK3Qu1ohFrpqpuzkoVHOIr1bFpM?=
 =?iso-8859-1?Q?r0DVJJHwPdw8w/Zuw1L62n7f/VWVXNSHYIhlIZ+3kIUyj/eZYzksdWU973?=
 =?iso-8859-1?Q?N7ng8uQYjYg6GsBW8d1D6idm/KyzzxvSSWguXrnlkPfI03CeQTjoukiyVE?=
 =?iso-8859-1?Q?lhiCOMYuknxbv4KGgXrm9q2viNWzGhk/gWYf7ZFpFuUJ13u04dCt1SKs70?=
 =?iso-8859-1?Q?fNwb3zpdrJj/yK2THlV/4RIkhtvDp2FTZA2KrJphNbBKc6neVeaqZLuxSU?=
 =?iso-8859-1?Q?8RY3ftpHohqU4tnpovsd8wqlg/sfH9OPhZdE414mIBE8+2CrTuN0na62Kn?=
 =?iso-8859-1?Q?GGc7GRMoDJnKgJtRj5TpzGJHiCZ0x/USpgQyDlAecPWZ/sUMhtfjtNY3fJ?=
 =?iso-8859-1?Q?/5TNXWBAPmDQCc4N5cI2ydvqy6wXHXjSmdHRBnzfq9odFXheR/7Dfpqqu6?=
 =?iso-8859-1?Q?wG7RQGIqqh2GBj9OM4ebveWFtv7FYYvV6JlOUz9q48hcxASonMo5QhfJKQ?=
 =?iso-8859-1?Q?yVWD6q4+D4QHT0MYXea7BKepljhGusWViscEjZL/y5lM9a53EXu/lI1BRF?=
 =?iso-8859-1?Q?BMF2ghtUHB/1PE4x6PkuFifCL5JTtF2DHgCYojFfRG1AoiUAp+MeMnaypH?=
 =?iso-8859-1?Q?abp4NBI6qj9FDJ3DjXOmB0gC7doK2halk7/aIijP9JXR5q0AWmqLHHcNfi?=
 =?iso-8859-1?Q?8MTKmT5awG6Tra7zhiLzk4TmludKiaAuD7AKjHaPINortLmKXt9o5UjUJk?=
 =?iso-8859-1?Q?lzXrmKk2Ul4YjrkZD3gYILJbZ1JKOs09u0lTKUZPj0JVwvCDo2W+RyQ7Iy?=
 =?iso-8859-1?Q?VvGgV9kSdGECRo71WAioIGcNM2aq7Mn4gXptd6xbHi24nwHfRFGGZ3psct?=
 =?iso-8859-1?Q?qOEwNjmyNpmA7ycgtiyf1XiqA/PYmq83t5fTOUhPOHSokgl3Udr+p8Cs7t?=
 =?iso-8859-1?Q?heUMIBxa8jUZyNDkNV8=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: PR3PR03MB6412.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ffe4041e-70ec-4c27-5544-08dd97b66da7
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2025 15:53:13.5618
 (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: DocyiYCgJXqxLY2NpBWJMXyZdcZPSP8Nh5xa4CEHQig/8fFG2bo2VDiZirqEInorlva9DMJGzytkftn7iBcjxYacszoM/03CBwgeBYzW9I8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6155

An attempt to write access the register (i.e. GICR_PROPBASER, GICR_PENDBASE=
R)
which should be ignored (i.e. no virtual ITS present) causes the guest data=
 abort
due to incorrect check at the write_ignore_64 label. The check should be
inverted.

While at it, move goto to the next line.

Fixes: c4d6bbdc12e5 ("xen/arm: vgic-v3: Support 32-bit access for 64-bit re=
gisters")
Signed-off-by: Oleksandr Tyshchenko 
Acked-by: Julien Grall 
---
  V2:
   - s/data about/guest data abort in the description
   - add A-b
   - move goto to the next line
---
---
 xen/arch/arm/vgic-v3.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 2eaa48fadb..f20249f731 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -649,7 +649,8 @@ bad_width:
     return 0;
=20
 write_ignore_64:
-    if ( vgic_reg64_check_access(dabt) ) goto bad_width;
+    if ( !vgic_reg64_check_access(dabt) )
+        goto bad_width;
     return 1;
=20
 write_ignore_32:
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue May 20 17:37:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 17:37:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.990993.1374939 (Exim 4.92)
	(envelope-from )
	id 1uHQu7-0004lq-6W; Tue, 20 May 2025 17:37:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 990993.1374939; Tue, 20 May 2025 17:37: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 1uHQu7-0004lj-3W; Tue, 20 May 2025 17:37:27 +0000
Received: by outflank-mailman (input) for mailman id 990993;
 Tue, 20 May 2025 17:37:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHQu5-0004lb-Ot
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 17:37:25 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 16133df9-35a1-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 19:37:22 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43ce71582e9so48359585e9.1
 for ; Tue, 20 May 2025 10:37:22 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f78aef8asm40010215e9.29.2025.05.20.10.37.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 10:37: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" 
X-Inumbo-ID: 16133df9-35a1-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747762642; x=1748367442; 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;
        bh=hBMR/tsxhrvvnQPYiNukCqoQmbuc6BX9rVStfHvqwJ8=;
        b=Ll1v4Wq0lhmSEnIfzEdv8HCRdCt4SrKpef8PAuAjyHtZ0t8XCFf6OYqeCIJDcEAubO
         778knz53ac8GiXtkkixrEJ777OetH8EeDNkEh+KA1n2JaxlRPKyWPK1pBZ772NfBD4aS
         A0RDs1ZJaUyrSRRGdDktrV/ZYSxiDbnaXzr+o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747762642; x=1748367442;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=hBMR/tsxhrvvnQPYiNukCqoQmbuc6BX9rVStfHvqwJ8=;
        b=wFPz7VnoH7N7tBwgJJKIlhBaAnn0uKwN2CjfTHWjYxOLlfJn0xpBdbXrgukoxX/5EO
         zUdgYn20WyKFR4AMEUYvziRPyjTBaP0orUHQ+0x+nXJFyffVi1t5zXgwRjNbsf+ryoCb
         dPk3CS5FNIVjifFKf0Z/l1Bhs01FV9iAkpLMukbdakt751+I6P52LfqaRAXVJm7H3YpN
         g69Ssa6TWlREUjcIx1Ts5tzqOTLHaENnQBQJ2PlgFC+oVXhxf9vl57WUjCQ3Vay2JZYc
         t7IcXmF9w5P+S4uSjWLL+pdlQnjaTIkax/HdlLSedMeXxvsoR9wRW9stmOpZzFT6RE5P
         9fLQ==
X-Gm-Message-State: AOJu0YyB1duRvOPz6kkkK4LY23UdUg/zy8WGlvbveYZuNQJcXIoQ1gVd
	+lY4PXCexEAhdAQ5rDlLqogP1DACD8Ab5H6xQMpJ/RmDLEHM2hOrzC8L3PqPt27HX9xdAezxJ76
	nM1wn
X-Gm-Gg: ASbGncvIBO9a7gyvhCGbex6VRQc0zPlreKOj5t7oK4cLXDgLoXyURUEA6Mm4rrtnyaV
	wX5PP27wtzRktSuEOgq09vIhrBq2g/veepOw9R3gb92VUMqxbklstLMRNUflpJVEzMREGZ9vySi
	UHOvPGGN3BDBbprzcrePdW2dqAbkhUJh9iauofKGVICFrzFudPnDull6u83Rnl5KPWF3vVc0wjy
	S2U3N9lpVLvIGUtZBkAqi8ehHNBfnR7Z4V2D8HWoWU0K5Qf16NTHkMeEVdFxvXra1gHYCJnmZDh
	uNJMU+iYSc2TnzRPX4jFYLudAVhso4JuXz4EehZU9Ec8PK9n8J1t/PiD/zT2V/BcR6ox+bLZVk4
	Nshzo87mqF1RH88isUnnqcQfd
X-Google-Smtp-Source: AGHT+IF3fiAufJtRi6ZdpAaC1OEvpFM0b/cRRAKzCqkMExTYlkdF0Hi84yoaXnSkkzKiBBb3Wy9nbQ==
X-Received: by 2002:a05:600c:83c5:b0:439:86fb:7340 with SMTP id 5b1f17b1804b1-442fd67515emr190823355e9.30.1747762641781;
        Tue, 20 May 2025 10:37:21 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH] CI: Rename qubes-x86-64 parameter "" to "dom0pv"
Date: Tue, 20 May 2025 18:37:19 +0100
Message-Id: <20250520173719.139233-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

This really is a legacy of not having parameters to start with.  Give PV dom0
with a PVH domU a real name.

Reformat the table to fix alignment.

Signed-off-by: Andrew Cooper 
---
CC: Marek Marczykowski-Górecki 
---
 automation/gitlab-ci/test.yaml     |  8 ++++----
 automation/scripts/qubes-x86-64.sh | 22 +++++++++++-----------
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index a603d4039aef..842cecf71382 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -257,7 +257,7 @@ xilinx-smoke-dom0-x86_64-gcc-debug-argo:
 adl-smoke-x86-64-gcc-debug:
   extends: .adl-x86-64
   script:
-    - ./automation/scripts/qubes-x86-64.sh 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qubes-x86-64.sh dom0pv 2>&1 | tee ${LOGFILE}
   needs:
     - *x86-64-test-needs
     - alpine-3.18-gcc-debug
@@ -335,7 +335,7 @@ adl-tools-tests-pvh-x86-64-gcc-debug:
 kbl-smoke-x86-64-gcc-debug:
   extends: .kbl-x86-64
   script:
-    - ./automation/scripts/qubes-x86-64.sh 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qubes-x86-64.sh dom0pv 2>&1 | tee ${LOGFILE}
   needs:
     - *x86-64-test-needs
     - alpine-3.18-gcc-debug
@@ -413,7 +413,7 @@ kbl-tools-tests-pvh-x86-64-gcc-debug:
 zen2-smoke-x86-64-gcc-debug:
   extends: .zen2-x86-64
   script:
-    - ./automation/scripts/qubes-x86-64.sh 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qubes-x86-64.sh dom0pv 2>&1 | tee ${LOGFILE}
   needs:
     - *x86-64-test-needs
     - alpine-3.18-gcc-debug
@@ -429,7 +429,7 @@ zen2-suspend-x86-64-gcc-debug:
 zen3p-smoke-x86-64-gcc-debug:
   extends: .zen3p-x86-64
   script:
-    - ./automation/scripts/qubes-x86-64.sh 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qubes-x86-64.sh dom0pv 2>&1 | tee ${LOGFILE}
   needs:
     - *x86-64-test-needs
     - alpine-3.18-gcc-debug
diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index bfdd2ceb99ba..aa47ba6bf5c0 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -2,16 +2,16 @@
 
 set -ex -o pipefail
 
-# One of:
-#  - ""             PV dom0,  PVH domU
-#  - dom0pvh        PVH dom0, PVH domU
-#  - dom0pvh-hvm    PVH dom0, HVM domU
-#  - pci-hvm        PV dom0,  HVM domU + PCI Passthrough
-#  - pci-pv         PV dom0,  PV domU + PCI Passthrough
-#  - pvshim         PV dom0,  PVSHIM domU
-#  - s3             PV dom0,  S3 suspend/resume
-#  - tools-tests-pv PV dom0, run tests from tools/tests/*
-#  - tools-tests-pvh PVH dom0, run tests from tools/tests/*
+# One of:              dom0:   Testing:
+#  - dom0pv              PV      PVH domU
+#  - dom0pvh             PVH     PVH domU
+#  - dom0pvh-hvm         PVH     HVM domU
+#  - pci-hvm             PV      HVM domU + PCI Passthrough
+#  - pci-pv              PV      PV domU + PCI Passthrough
+#  - pvshim              PV      PVSHIM domU
+#  - s3                  PV      S3 suspend/resume
+#  - tools-tests-pv      PV      Run tests from tools/tests/*
+#  - tools-tests-pvh     PVH     Run tests from tools/tests/*
 test_variant=$1
 
 ### defaults
@@ -25,7 +25,7 @@ retrieve_xml=
 
 case "${test_variant}" in
     ### test: smoke test & smoke test PVH & smoke test HVM & smoke test PVSHIM
-    ""|"dom0pvh"|"dom0pvh-hvm"|"pvshim")
+    "dom0pv"|"dom0pvh"|"dom0pvh-hvm"|"pvshim")
         passed="ping test passed"
         domU_check="
 ifconfig eth0 192.168.0.2
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue May 20 18:27:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 18:27:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991010.1374948 (Exim 4.92)
	(envelope-from )
	id 1uHRgi-0002O8-LJ; Tue, 20 May 2025 18:27:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991010.1374948; Tue, 20 May 2025 18: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 1uHRgi-0002O1-IU; Tue, 20 May 2025 18:27:40 +0000
Received: by outflank-mailman (input) for mailman id 991010;
 Tue, 20 May 2025 18:27:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHRgf-0002Nu-Vn
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 18:27:38 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1936cdf0-35a8-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 20:27: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" 
X-Inumbo-ID: 1936cdf0-35a8-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747765653; x=1748024853;
	bh=WC1MszHE5twx3i/Dw9pfsXxHF/3kIN6J1HHv9TON4Ac=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=GV+vGYmoz3F+xx20dXvlyz1rSdESWMIvXsMh2B9VvsHl23FaVeyJMjX0LJTI0XkWP
	 cE0TLt9+OBl7NMVSGjwjwJ1wjqqaleyP8/WyOlkvsZEYydtrLM9o8TQifs0X4eQnMn
	 ON/q0ikN2DHX5IoqRtI1DoGP8r3M0QGSCSQuOeOp9jqcWxQQMxBzvnp6uTZQOmqsZ2
	 7BaFglgjcIzPlEZwdhMpK+SyDFYbP5Of2dnOvKj4ddmRdhEVe3Xprf0s17hX9Bb2uP
	 TLxSfsskjuTnikAuMYMJdb1+LXPtrMnKsFSRsZl6QqQ3bvpfiAGjWwocvppxT0TiJ2
	 HCHrp2uGhD9gQ==
Date: Tue, 20 May 2025 18:27:27 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v7 3/3] xen/domain: introduce CONFIG_MAX_DOMID
Message-ID: 
In-Reply-To: <0b7fd522-af98-4ab3-ae6b-ed131ef3bf04@suse.com>
References: <20250519192306.1364471-1-dmukhin@ford.com> <20250519192306.1364471-4-dmukhin@ford.com> <0b7fd522-af98-4ab3-ae6b-ed131ef3bf04@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: e2f2d23d42a731d2bcf29b5ee0f144584fd6d6dd
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 20, 2025 at 08:04:14AM +0200, Jan Beulich wrote:
> On 19.05.2025 21:23, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Embedded deployments of Xen do not need to have support for more than d=
ozen of
> > domains.
> >
> > Introduce build-time configuration option to limit the number of domain=
s during
> > run-time.
>=20
> I fear I don't see the (sufficiently meaningful) gain of this. And I must=
 have ...
>=20
> > Suggested-by: Julien Grall 
>=20
> ... missed tis earlier suggestion, or else I would have asked the questio=
n already
> there.

The code change is based on the feedback here:

  https://lore.kernel.org/xen-devel/2e5afdf1-3913-4b6f-86ea-21b3ccd0833c@xe=
n.org/

It probably should have been sent as an RFC change.

>=20
> > --- a/xen/arch/arm/tee/ffa.c
> > +++ b/xen/arch/arm/tee/ffa.c
> > @@ -333,8 +333,9 @@ static int ffa_domain_init(struct domain *d)
> >       */
> >      BUILD_BUG_ON(DOMID_FIRST_RESERVED >=3D UINT16_MAX);
> >      BUILD_BUG_ON((DOMID_MASK & BIT(15, U)) !=3D 0);
> > +    BUILD_BUG_ON(DOMID_FIRST_RESERVED < CONFIG_MAX_DOMID);
>=20
> We want this check, yes, but in common code. It's entirely unrelated to A=
rm's TEE.
>=20
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -576,4 +576,11 @@ config BUDDY_ALLOCATOR_SIZE
> >  =09  Amount of memory reserved for the buddy allocator to serve Xen he=
ap,
> >  =09  working alongside the colored one.
> >
> > +config MAX_DOMID
> > +=09int "Maximum number of non-system domains"
>=20
> Hmm, without clarifying what a system domain is (is hwdom one? is a contr=
ol
> domain one), I fear this may be ambiguous to users.
>=20
> Jan
>=20



From xen-devel-bounces@lists.xenproject.org Tue May 20 18:46:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 18:46:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991029.1374962 (Exim 4.92)
	(envelope-from )
	id 1uHRyM-00053H-63; Tue, 20 May 2025 18:45:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991029.1374962; Tue, 20 May 2025 18:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHRyM-00053A-2y; Tue, 20 May 2025 18:45:54 +0000
Received: by outflank-mailman (input) for mailman id 991029;
 Tue, 20 May 2025 18:45:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHRyK-000534-PE
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 18:45:53 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a561ad3a-35aa-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 20:45:49 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747766744617924.572632780241;
 Tue, 20 May 2025 11:45: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" 
X-Inumbo-ID: a561ad3a-35aa-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; t=1747766745; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=KC8KtYzt7icVWvNs6vOE/lsLg13Y3r0yDCG+avUBldA7Ns63v1lQ1VfqOrQK1X69T2qqQmF9e8OiBO4jEtlnCwEgz14Ue56EEf1jxqwY2a86aZ9dsaDN6gXL1l/u9lmM+RdvV1+P/W2buP/JUlEQCqg8zljtU97MlXxk/0sIj6s=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747766745; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=khwdnsxgTYA4crYq+mdovbUPglmY9ltme7rsuRBtajo=; 
	b=KAbyMZaGaRuRYQw42G0xg8gwg/TYf1KBV2gaRh8XKH0VIuu9+GsrvrCkCy+cK6kvPv3mwMi6fxGxzgHpTH+9gZKEae37GQA1NC/+oE2Llk20YuVGHgZay3IJRAbPGANf+BDeuYs6gciMj1fhids4ezp9reYe8ZMpFn2Zb2+sQbw=
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=1747766745;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=khwdnsxgTYA4crYq+mdovbUPglmY9ltme7rsuRBtajo=;
	b=FbeCexl1TPZDpk0V0O2TUXfxEYsKyPnccnNyMBich2ZW63mBwdpPdQKm7Ouf/wQ2
	ml0r5unKouaF8QddaaS6mgizG7QsboEeexyRNX2Ax3V4RyUqL3Ys2zXwJJuOcGhxCtl
	gDD07n8vPvDD4qedvqmeDQPLSx/WyDrIAkd4wp+g=
Message-ID: <2a92e866-543e-404d-be34-d58cf5d51aec@apertussolutions.com>
Date: Tue, 20 May 2025 14:45:42 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/argo: Command line handling improvements
To: Andrew Cooper ,
 Xen-devel 
Cc: Christopher Clark ,
 Denis Mukhin 
References: <20250520141027.120958-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: "Daniel P. Smith" 
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: <20250520141027.120958-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 5/20/25 10:10, Andrew Cooper wrote:
> Treat "argo" on the command line as a positive boolean, rather than requiring
> the user to pass "argo=1/on/enable/true".
> 
> Move both opt_argo* variables into __ro_after_init.  They're set during
> command line parsing and never modified thereafter.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Christopher Clark 
> CC: Daniel P. Smith 
> CC: Denis Mukhin 
> 
> Found while
> ---
>   xen/common/argo.c | 9 ++++++---
>   1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/argo.c b/xen/common/argo.c
> index cbe8911a4364..027b37b18a6c 100644
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -79,8 +79,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_argo_unregister_ring_t);
>   DEFINE_COMPAT_HANDLE(compat_argo_iov_t);
>   #endif
>   
> -static bool __read_mostly opt_argo;
> -static bool __read_mostly opt_argo_mac_permissive;
> +static bool __ro_after_init opt_argo;
> +static bool __ro_after_init opt_argo_mac_permissive;
>   
>   static int __init cf_check parse_argo(const char *s)
>   {
> @@ -92,7 +92,10 @@ static int __init cf_check parse_argo(const char *s)
>           if ( !ss )
>               ss = strchr(s, '\0');
>   
> -        if ( (val = parse_bool(s, ss)) >= 0 )
> +        /* Intepret "argo" as a positive boolean. */
> +        if ( *s == '\0' )
> +            opt_argo = true;
> +        else if ( (val = parse_bool(s, ss)) >= 0 )
>               opt_argo = val;
>           else if ( (val = parse_boolean("mac-permissive", s, ss)) >= 0 )
>               opt_argo_mac_permissive = val;
> 
> base-commit: 293abb9e0c5e8df96cc5dfe457c62dfcb7542b19

While it is logical, this does technically change the behavior of the 
command line flag. Should there be an update to xen-command-line.pandoc 
to clarify that the list is optional?

Other than the doc concern,

Reviewed-by: Daniel P. Smith 



From xen-devel-bounces@lists.xenproject.org Tue May 20 19:47:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 19:47:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991077.1374984 (Exim 4.92)
	(envelope-from )
	id 1uHSvf-00041n-Qb; Tue, 20 May 2025 19:47:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991077.1374984; Tue, 20 May 2025 19: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 1uHSvf-00041g-Ni; Tue, 20 May 2025 19:47:11 +0000
Received: by outflank-mailman (input) for mailman id 991077;
 Tue, 20 May 2025 19:47:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHSve-00041a-Ph
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 19:47:10 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 365e5d74-35b3-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 21:47:08 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id BE3875C5A05;
 Tue, 20 May 2025 19:44:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9DFCBC4CEE9;
 Tue, 20 May 2025 19:47: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" 
X-Inumbo-ID: 365e5d74-35b3-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747770426;
	bh=1DZIIC5dMR306c0R3it4IKiqW5SI0mtSJAhF+S37bFM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=lZiad7QQ+pGU2LCB1cp1weu4LJtHTLVuvYzIX8oXtI7brAvhpbsmRnw/TtaRvV0SG
	 GrYGvah3VLhzM+ySOw1ynMhP6OxNdFc6UR4gb2DOqrkLrg6Le21GhZBLa9ed/OI87G
	 pPvmgyvGIwU6EQyeu79qgBhR0UhkN+qjchf30Ao+UdtM9Gw+xK4+zVCeZrOhBuKn+h
	 PsQFDUqZVE14Zggy4TGYep57ofvfSqKzNCZWLDH8Pgr1jQrLSqqgikw7poPoVma3ED
	 BL2Wn+gXd3sxgn3H2T8bw4U/Lax0gvLs/71C5ON2Lr2VR1ND5Vg6n6sF2Gz0e6/F+a
	 e0SNY/qrNuARg==
Date: Tue, 20 May 2025 12:47:04 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Xen-devel 
Subject: Re: [PATCH] xen: Give compile.h header guards
In-Reply-To: <4b580922-4aac-44bc-ad14-75a250ac7962@suse.com>
Message-ID: 
References: <20250519135227.27386-1-andrew.cooper3@citrix.com>   <4b580922-4aac-44bc-ad14-75a250ac7962@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 20 May 2025, Jan Beulich wrote:
> On 19.05.2025 23:34, Stefano Stabellini wrote:
> > On Mon, 19 May 2025, Jan Beulich wrote:
> >> On 19.05.2025 15:52, Andrew Cooper wrote:
> >>> Signed-off-by: Andrew Cooper 
> >>
> >> Is this to please Misra in some way?
> >>
> >>> --- a/xen/include/xen/compile.h.in
> >>> +++ b/xen/include/xen/compile.h.in
> >>> @@ -1,3 +1,6 @@
> >>> +#ifndef XEN_COMPILE_H
> >>> +#define XEN_COMPILE_H
> >>> +
> >>>  #define XEN_COMPILE_DATE	"@@date@@"
> >>>  #define XEN_COMPILE_TIME	"@@time@@"
> >>>  #define XEN_COMPILE_BY		"@@whoami@@"
> >>> --- a/xen/tools/process-banner.sed
> >>> +++ b/xen/tools/process-banner.sed
> >>> @@ -12,3 +12,8 @@ s_(.*)_"\1\\n"_
> >>>  
> >>>  # Trailing \ on all but the final line.
> >>>  $!s_$_ \\_
> >>> +
> >>> +# Append closing header guard
> >>> +$a\
> >>> +\
> >>> +#endif /* XEN_COMPILE_H */
> >>
> >> This split of #ifndef and #endif is ugly. Can't we switch to something
> >> more conventional, like
> >>
> >> #define XEN_BANNER		"@@banner@@"
> >>
> >> with the first sed invocation then replacing this by the result of
> >> a nested sed invocation using process-banner.sed (which of course would
> >> need adjusting some)? (Maybe the double quotes would need omitting here,
> >> for process-banner.sed to uniformly apply them.)
> > 
> > While I agree with Jan that this is kind of ugly, it is a unique case
> > and I would prefer an ugly but simple solution than a more complex
> > solution. This would be different if we were talking about a widespread
> > pattern, in which case the price for complexity would be worth it.
> > 
> > My 2 cents in this case are in favor of the simplest approach. I would
> > ack this patch.
> 
> Feel free to do so; my comment was not meant as a plain objection, but more
> as a suggestion. The one thing I would ask for is a non-empty description,
> though.

Fair enough. Andrew, please add a better commit message. With that:

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Tue May 20 19:51:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 19:51:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991088.1374994 (Exim 4.92)
	(envelope-from )
	id 1uHT07-0005ct-9y; Tue, 20 May 2025 19:51:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991088.1374994; Tue, 20 May 2025 19:51: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 1uHT07-0005cm-7S; Tue, 20 May 2025 19:51:47 +0000
Received: by outflank-mailman (input) for mailman id 991088;
 Tue, 20 May 2025 19:51:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHT05-0005cg-Tw
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 19:51:45 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id db208a5f-35b3-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 21:51:44 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43cfba466b2so65264455e9.3
 for ; Tue, 20 May 2025 12:51:44 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a361a81fd8sm16125594f8f.81.2025.05.20.12.51.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 12:51: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" 
X-Inumbo-ID: db208a5f-35b3-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747770703; x=1748375503; 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;
        bh=brUjMfaV3P30faob5uS22kyYef5+r4S1qnZtqZ4kPUc=;
        b=lj8aduuJRvB5RuzXacppf+vlLa/Gu3sYKuMgZUh/T8BYL7AENFq0T0CqGpNsh3rkbC
         T1SS9LO+J4eLLdzWBmXuYSXmtLM7aK2NsV7sP22kOpdo/XAyW5nU5DkQa/Xfh3GCA3EF
         2Au8Ib1XhR+opY4/yHKsLwEj5cH3PTVf8RNho=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747770703; x=1748375503;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=brUjMfaV3P30faob5uS22kyYef5+r4S1qnZtqZ4kPUc=;
        b=ruRrUI7EJJZrvNQmv9CrczS5f7YOS/KLaO+EZMZJs7Ti5qkTF57FkyY1kgJdlG0IF7
         yiCaSjzi7J5bhr+ezp4tr/erpqP14IY8NnyM+MQ2IK1CHE9NcMCaNNTYrvsxXG2a95xp
         pGFjzQ6VqUgQSGxYIus/Cx4ZkidZmio3zrXRZ6dnhKY4leVI2wWzZOR0fHFeq6QCc0TB
         ta6vcKqAKQeBPUX2H1FqLstuSQWcCqu81qB4ThhPiIa9K+vwr1e34n+ethy077w+r3UP
         gLpU+87aRJC96iwJIa0Jiev5xne/ikRosgK+vpDgZ2LjgOy+0FavqYxjrh9eP4dGTIzD
         rMIw==
X-Gm-Message-State: AOJu0Yz46F6Qrjm/3L+S+OO707yK8IbqYqYrE+NFpBzgSUZDhKwmQ1nE
	7AQKDHTP5PwwONhCa6D38+jZTYDGkNJ4bohpWO7vb0kH6hsR4awVUWef6SnKHiEU2DjG6ikRjDz
	HKdnK
X-Gm-Gg: ASbGncvLfZG5HV363IsKf8JOxo3Gz2zCbvwgQVaWquQdqKbEykgJUkwdKtynDDEJa6I
	XDQXJk2cli8NBjYlKwUueEiOEP4cBWqMH+IyOpldUX2bXPdP0aeRofd0AZNv529aknEIvismk1t
	D7ZPp5sW5VgVro3+q+BA9nBsmmW0Suuty0HkT2koRR6tO0Rey8tCqYWTN6wqMcjKq/U7D0qtNqb
	CIxQn7LOpetxWgg7zjKbCK+ENRJygp4ImULE3LqeIP368cP9s7D3AHt50VuXG2WlNj0/9JRfU2S
	4vSwK8rBIPQ27OOuj4GmBYusrcpGAqbnahdrMm/aj/orraQ4GR5CCVnq6xIEOdHY6qgp564Kxb6
	iNoremlaTmyvwOzD8kz4ipIIqOJeqwuopTYg=
X-Google-Smtp-Source: AGHT+IHwTmoUPjzxB9R4rC6MR+1xLjbwHeYTOXAdAZWvxNXv96qxjVqefiE/9mSSKB9C+yr/iOPvHw==
X-Received: by 2002:a05:6000:4284:b0:3a1:fd60:887 with SMTP id ffacd0b85a97d-3a35ffd2bbbmr14319014f8f.45.1747770703321;
        Tue, 20 May 2025 12:51:43 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH TEST-ARTEFACTS] (Re)add python3 to alpine rootfs
Date: Tue, 20 May 2025 20:51:41 +0100
Message-Id: <20250520195141.198061-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

XTF uses python, and we're looking to reintroduce XTF testing to Xen.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Stefano Stabellini 
CC: Marek Marczykowski-Górecki 
---
 scripts/alpine-rootfs.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
index c304e2ebfbd9..c999b89dbcd8 100755
--- a/scripts/alpine-rootfs.sh
+++ b/scripts/alpine-rootfs.sh
@@ -22,6 +22,9 @@ PKGS=(
     xz
     yajl
 
+    # Xen Test Framework
+    python3
+
     # QEMU
     glib
     libaio
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue May 20 20:03:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 20:03:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991107.1375004 (Exim 4.92)
	(envelope-from )
	id 1uHTB0-0007Ka-8Z; Tue, 20 May 2025 20:03:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991107.1375004; Tue, 20 May 2025 20: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 1uHTB0-0007KT-5i; Tue, 20 May 2025 20:03:02 +0000
Received: by outflank-mailman (input) for mailman id 991107;
 Tue, 20 May 2025 20:03:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHTAy-0007KJ-H4
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 20:03:00 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6ce2e59c-35b5-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 22:02:59 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 437B14A90C;
 Tue, 20 May 2025 20:02:57 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F670C4CEE9;
 Tue, 20 May 2025 20:02: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" 
X-Inumbo-ID: 6ce2e59c-35b5-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747771377;
	bh=kUJ98PLL4WbosrjwO3iyr66mZbx35KyWFRV12XfJfH0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=pgyIy+1zFYu12dN+VYIYI6LQy9/QI0MYBnVwJlDZExO39F/kQNT6UPOD7GzrDcQ4u
	 PwXMgqldsWgoei+CzIIbob3myLQ/UE15EvLeg1XbJ1jR+BpGRzGQQwmz1jZgTD3jSm
	 PAsWqMVg1Rtqf5gvDEPdoDvvl0xPWQrvnM4iz+fXI1/cA9C6FlK8I/C6fvQjx+xzrw
	 XIWND7ZErhVrO6ECm7ZXt0kFci5TK1FxretM+yX0i9mMQGi5dbIEPiS6xsRia3qsPo
	 23DdKy1Q7iwsgoRiFlXywsxh5D9NBb3LPk0GSdf0VbMdH7+WltsUM9/W08tQQUPYWG
	 6ohhL6AZLp5vg==
Date: Tue, 20 May 2025 13:02:54 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Xen-devel , 
    Anthony PERARD , 
    Stefano Stabellini , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH TEST-ARTEFACTS] (Re)add python3 to alpine rootfs
In-Reply-To: <20250520195141.198061-1-andrew.cooper3@citrix.com>
Message-ID: 
References: <20250520195141.198061-1-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1091536216-1747771377=:2019926"

  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-1091536216-1747771377=:2019926
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Tue, 20 May 2025, Andrew Cooper wrote:
> XTF uses python, and we're looking to reintroduce XTF testing to Xen.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Stefano Stabellini 


> ---
> CC: Anthony PERARD 
> CC: Stefano Stabellini 
> CC: Marek Marczykowski-Górecki 
> ---
>  scripts/alpine-rootfs.sh | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/scripts/alpine-rootfs.sh b/scripts/alpine-rootfs.sh
> index c304e2ebfbd9..c999b89dbcd8 100755
> --- a/scripts/alpine-rootfs.sh
> +++ b/scripts/alpine-rootfs.sh
> @@ -22,6 +22,9 @@ PKGS=(
>      xz
>      yajl
>  
> +    # Xen Test Framework
> +    python3
> +
>      # QEMU
>      glib
>      libaio
> -- 
> 2.39.5
> 
--8323329-1091536216-1747771377=:2019926--


From xen-devel-bounces@lists.xenproject.org Tue May 20 20:19:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 20:19:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991116.1375015 (Exim 4.92)
	(envelope-from )
	id 1uHTQi-0000mX-If; Tue, 20 May 2025 20:19:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991116.1375015; Tue, 20 May 2025 20: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 1uHTQi-0000mQ-Fk; Tue, 20 May 2025 20:19:16 +0000
Received: by outflank-mailman (input) for mailman id 991116;
 Tue, 20 May 2025 20:19:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHTQh-0000mK-5G
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 20:19:16 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b1f45692-35b7-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 22:19: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" 
X-Inumbo-ID: b1f45692-35b7-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747772352; x=1748031552;
	bh=clDefMXEPEmZIzclS1GpKOWlZqrN8tP4S0W+ZRs0nNM=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=fOBIp1YQZYjQdWEFL39AY4lKKHiHr2XxkTt0PWOlc3v/oWmC8iGO5Q1O9OieJk89x
	 eoOsdKLuLWlOJvZ5O1RAolm+5Adx1xAUbhAhPw7xfv68peYcPdGjYqX4ak664j9jGu
	 YMbS8VR+QVq9N6z1tLasipdMaGazyHJqocNXnWTRBiaDuCReE1CCI59AIP9dGYpKp/
	 zcs2aGypLGvnssENxlV+f76yzkY4tvIc+ypPjebdGvPtHb7q7HZF5xz2KDA/guGMSd
	 rJupNOGhxE9zR4XZWPimuh6b+bqkaK3vajHg7YqHEguM+HNJHlkJgQbFKLXNK7ySgz
	 QRFytgtZCpdtw==
Date: Tue, 20 May 2025 20:19:08 +0000
To: Andrew Cooper 
From: dmkhn@proton.me
Cc: Xen-devel , Christopher Clark , "Daniel P . Smith" 
Subject: Re: [PATCH] xen/argo: Command line handling improvements
Message-ID: 
In-Reply-To: <20250520141027.120958-1-andrew.cooper3@citrix.com>
References: <20250520141027.120958-1-andrew.cooper3@citrix.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: d5074852dfa1a42e339fe44b1da18bcb3b21f600
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 20, 2025 at 03:10:27PM +0100, Andrew Cooper wrote:
> Treat "argo" on the command line as a positive boolean, rather than requi=
ring
> the user to pass "argo=3D1/on/enable/true".
>=20
> Move both opt_argo* variables into __ro_after_init.  They're set during
> command line parsing and never modified thereafter.
>=20
> Signed-off-by: Andrew Cooper 

Reviewed-by: Denis Mukhin 

> ---
> CC: Christopher Clark 
> CC: Daniel P. Smith 
> CC: Denis Mukhin 
>=20
> Found while
> ---
>  xen/common/argo.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>=20
> diff --git a/xen/common/argo.c b/xen/common/argo.c
> index cbe8911a4364..027b37b18a6c 100644
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -79,8 +79,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_argo_unregister_ring_t);
>  DEFINE_COMPAT_HANDLE(compat_argo_iov_t);
>  #endif
>=20
> -static bool __read_mostly opt_argo;
> -static bool __read_mostly opt_argo_mac_permissive;
> +static bool __ro_after_init opt_argo;
> +static bool __ro_after_init opt_argo_mac_permissive;
>=20
>  static int __init cf_check parse_argo(const char *s)
>  {
> @@ -92,7 +92,10 @@ static int __init cf_check parse_argo(const char *s)
>          if ( !ss )
>              ss =3D strchr(s, '\0');
>=20
> -        if ( (val =3D parse_bool(s, ss)) >=3D 0 )
> +        /* Intepret "argo" as a positive boolean. */
> +        if ( *s =3D=3D '\0' )
> +            opt_argo =3D true;
> +        else if ( (val =3D parse_bool(s, ss)) >=3D 0 )
>              opt_argo =3D val;
>          else if ( (val =3D parse_boolean("mac-permissive", s, ss)) >=3D =
0 )
>              opt_argo_mac_permissive =3D val;
>=20
> base-commit: 293abb9e0c5e8df96cc5dfe457c62dfcb7542b19
> --
> 2.39.5
>=20



From xen-devel-bounces@lists.xenproject.org Tue May 20 20:47:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 20:47:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991123.1375024 (Exim 4.92)
	(envelope-from )
	id 1uHTrR-0004rB-Kn; Tue, 20 May 2025 20:46:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991123.1375024; Tue, 20 May 2025 20: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 1uHTrR-0004r4-Hb; Tue, 20 May 2025 20:46:53 +0000
Received: by outflank-mailman (input) for mailman id 991123;
 Tue, 20 May 2025 20:46:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHTrP-0004qy-VN
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 20:46:52 +0000
Received: from fhigh-a6-smtp.messagingengine.com
 (fhigh-a6-smtp.messagingengine.com [103.168.172.157])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8ca2a499-35bb-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 22:46:49 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfhigh.phl.internal (Postfix) with ESMTP id B91D31140060;
 Tue, 20 May 2025 16:46:47 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Tue, 20 May 2025 16:46:47 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 20 May 2025 16:46:46 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8ca2a499-35bb-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1747774007;
	 x=1747860407; bh=Wsl69X9Bv89yOHaTQc6LOxJYelF+125GBx7fr7AmOug=; b=
	RG3hJl2DVeYeZl7reIMsIrMmLwefrODfbk6Gm8hge3WBn2w2dtcr0U1f5zi39g6V
	TpYHxwU1g7y5wLILrt67HCRLCGHaW8G0Orha9CgQYe86dR/8gHT/eudmTWpLtTjf
	Z2H5GQGJ5HBY1Ulv5yXmuN8LeGMEoUcIVsKMdVhTOXH4YWDerS6MThY7M3mDtbCr
	NxjmuTAmeZgNIUIqhWzgP0m4KnaRc+Ai2DkfSd97WynqmcxGfMzPrbQ6zW7UuxRZ
	/tbjmYNKOlXpmjhmE0pHLt2xdTz/CL7uJp2uJBqHY7F2Ufcz0dWE6wcKa+ig0Zj8
	M0aiwXhQV58uZUj0Jx09zw==
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=fm3; t=
	1747774007; x=1747860407; bh=Wsl69X9Bv89yOHaTQc6LOxJYelF+125GBx7
	fr7AmOug=; b=CJzDsugYCqcZNkxazNxpI4SZgs5h38oAGcmqpN6eWwFi3FcEsBN
	fLmWPTYeEbNW9QG6gHDy2/YTJoBPHSKr7Q6cCX4mhGV4/LAYAGLpmPyohD6Rtw7R
	ZR2AaNGGWQmaI2XGql8itgbJWUcMRdEa3zI7r9jSSJtiuqeyGzi47IsPmUnzpAZU
	AJOKHNVpa/Rq8wlHBLv81GJ0XVIxvZflOLlPTkkD+fwwLXvK8Nv+ozvpgH6snet1
	U4x8LtEqMIR64uSwjd698zSWhTAaWaAEI8WUAziHaNowOVA/Jj1dyDinLHOCoH+p
	MjbOk6LI1eFxbyl/KJfGzTtbUmPUCrpWypw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdduvdduucdltddurdegfedvrddttd
    dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf
    nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd
    enucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhgg
    tggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskh
    hiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhs
    lhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhje
    fhleduveetteekveettddvgeeuteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfr
    rghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhih
    hnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhht
    pdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprh
    gtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhr
    gh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 20 May 2025 22:46:44 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel 
Subject: Re: [PATCH] CI: Rename qubes-x86-64 parameter "" to "dom0pv"
Message-ID: 
References: <20250520173719.139233-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="HtE9IzP5Iy9WnAye"
Content-Disposition: inline
In-Reply-To: <20250520173719.139233-1-andrew.cooper3@citrix.com>


--HtE9IzP5Iy9WnAye
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 20 May 2025 22:46:44 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel 
Subject: Re: [PATCH] CI: Rename qubes-x86-64 parameter "" to "dom0pv"

On Tue, May 20, 2025 at 06:37:19PM +0100, Andrew Cooper wrote:
> This really is a legacy of not having parameters to start with.  Give PV =
dom0
> with a PVH domU a real name.
>=20
> Reformat the table to fix alignment.
>=20
> Signed-off-by: Andrew Cooper 

Reviewed-by: Marek Marczykowski-G=C3=B3recki 

> ---
> CC: Marek Marczykowski-G=C3=B3recki 
> ---
>  automation/gitlab-ci/test.yaml     |  8 ++++----
>  automation/scripts/qubes-x86-64.sh | 22 +++++++++++-----------
>  2 files changed, 15 insertions(+), 15 deletions(-)
>=20
> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.y=
aml
> index a603d4039aef..842cecf71382 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -257,7 +257,7 @@ xilinx-smoke-dom0-x86_64-gcc-debug-argo:
>  adl-smoke-x86-64-gcc-debug:
>    extends: .adl-x86-64
>    script:
> -    - ./automation/scripts/qubes-x86-64.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qubes-x86-64.sh dom0pv 2>&1 | tee ${LOGFILE}
>    needs:
>      - *x86-64-test-needs
>      - alpine-3.18-gcc-debug
> @@ -335,7 +335,7 @@ adl-tools-tests-pvh-x86-64-gcc-debug:
>  kbl-smoke-x86-64-gcc-debug:
>    extends: .kbl-x86-64
>    script:
> -    - ./automation/scripts/qubes-x86-64.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qubes-x86-64.sh dom0pv 2>&1 | tee ${LOGFILE}
>    needs:
>      - *x86-64-test-needs
>      - alpine-3.18-gcc-debug
> @@ -413,7 +413,7 @@ kbl-tools-tests-pvh-x86-64-gcc-debug:
>  zen2-smoke-x86-64-gcc-debug:
>    extends: .zen2-x86-64
>    script:
> -    - ./automation/scripts/qubes-x86-64.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qubes-x86-64.sh dom0pv 2>&1 | tee ${LOGFILE}
>    needs:
>      - *x86-64-test-needs
>      - alpine-3.18-gcc-debug
> @@ -429,7 +429,7 @@ zen2-suspend-x86-64-gcc-debug:
>  zen3p-smoke-x86-64-gcc-debug:
>    extends: .zen3p-x86-64
>    script:
> -    - ./automation/scripts/qubes-x86-64.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qubes-x86-64.sh dom0pv 2>&1 | tee ${LOGFILE}
>    needs:
>      - *x86-64-test-needs
>      - alpine-3.18-gcc-debug
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qube=
s-x86-64.sh
> index bfdd2ceb99ba..aa47ba6bf5c0 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -2,16 +2,16 @@
> =20
>  set -ex -o pipefail
> =20
> -# One of:
> -#  - ""             PV dom0,  PVH domU
> -#  - dom0pvh        PVH dom0, PVH domU
> -#  - dom0pvh-hvm    PVH dom0, HVM domU
> -#  - pci-hvm        PV dom0,  HVM domU + PCI Passthrough
> -#  - pci-pv         PV dom0,  PV domU + PCI Passthrough
> -#  - pvshim         PV dom0,  PVSHIM domU
> -#  - s3             PV dom0,  S3 suspend/resume
> -#  - tools-tests-pv PV dom0, run tests from tools/tests/*
> -#  - tools-tests-pvh PVH dom0, run tests from tools/tests/*
> +# One of:              dom0:   Testing:
> +#  - dom0pv              PV      PVH domU
> +#  - dom0pvh             PVH     PVH domU
> +#  - dom0pvh-hvm         PVH     HVM domU
> +#  - pci-hvm             PV      HVM domU + PCI Passthrough
> +#  - pci-pv              PV      PV domU + PCI Passthrough
> +#  - pvshim              PV      PVSHIM domU
> +#  - s3                  PV      S3 suspend/resume
> +#  - tools-tests-pv      PV      Run tests from tools/tests/*
> +#  - tools-tests-pvh     PVH     Run tests from tools/tests/*
>  test_variant=3D$1
> =20
>  ### defaults
> @@ -25,7 +25,7 @@ retrieve_xml=3D
> =20
>  case "${test_variant}" in
>      ### test: smoke test & smoke test PVH & smoke test HVM & smoke test =
PVSHIM
> -    ""|"dom0pvh"|"dom0pvh-hvm"|"pvshim")
> +    "dom0pv"|"dom0pvh"|"dom0pvh-hvm"|"pvshim")
>          passed=3D"ping test passed"
>          domU_check=3D"
>  ifconfig eth0 192.168.0.2
> --=20
> 2.39.5
>=20

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--HtE9IzP5Iy9WnAye
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgs6jQACgkQ24/THMrX
1yxURgf7BmI13VWyvKkt2O/j4VFlieQrlzPG0XeG+DaNHrCDK7L3ElBLPhNSP7WK
niM/4AkYKioEQWAs6551n8WESkIXezYvt4pm2C/46tFBEvwJBXTG06W9+qdDSvur
duURHpIednShJCgDvCnE6W2rGNIGSeHedGvXvPcm5H1CKK4XWDLmKbYRN7+r4Yzx
GRTXBo0yUVOfaVNw7KGHASJHJ2ShP5UR+/siG0Xplh+Fj1W+bDV5lVWevV0sr/UQ
qTi7bzSraeP3+xtDw9gvNOxuClp3J0/ZI3Davd8Vx/3lxdjozJz6y11XgCNGkQd+
iOsUw4l8YIxj0kPgTam6NSQM26yp6g==
=V047
-----END PGP SIGNATURE-----

--HtE9IzP5Iy9WnAye--


From xen-devel-bounces@lists.xenproject.org Tue May 20 20:52:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 20:52:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991133.1375055 (Exim 4.92)
	(envelope-from )
	id 1uHTx9-0006ok-Qi; Tue, 20 May 2025 20:52:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991133.1375055; Tue, 20 May 2025 20:52: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 1uHTx9-0006ob-M6; Tue, 20 May 2025 20:52:47 +0000
Received: by outflank-mailman (input) for mailman id 991133;
 Tue, 20 May 2025 20:52:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHTx8-0006MJ-0A
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 20:52:46 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 60aad136-35bc-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 22:52:44 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a36748920cso3388655f8f.2
 for ; Tue, 20 May 2025 13:52:44 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a3674fed67sm13346626f8f.89.2025.05.20.13.52.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 13:52: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" 
X-Inumbo-ID: 60aad136-35bc-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747774363; x=1748379163; 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;
        bh=tYDHu2sNUHYKOZndg0ckJhy2AgiTG60/H+oM7p1zbrI=;
        b=iDqy6fof3cPW6xIW0kMf6D2P7OTQ/TvdyOzjXzeJyg2R5knNy36RW59tWnYZ1vDmGU
         +PnkJcALYnA+eNKFul4/KJyrgfnx/zVmzy4yGYRbeL3Yz3/WIVwFwT+zbou+r8SgamRg
         UtVFs6t5/d6KFfSKEwnQyebaPsfqQ0py6Ehzw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747774363; x=1748379163;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=tYDHu2sNUHYKOZndg0ckJhy2AgiTG60/H+oM7p1zbrI=;
        b=K+Y10e8I4LZCuvuz0ZEta3WUV1hH10lS/hHKfXSva5NrFK6IVRFXgTdfPy/AsPG8VO
         kDK0ouVBztaaKo9AFp5joRLwizz3b8p93dKpUkGWbgC3q+saU7HimCaZ/AcOnb7j474F
         8u13omGPyzHDtkUFXEYjy4Ks92IgWOXYPiomon68h7Pr9V17zthK8wFJd35bdcXuHMOK
         0TcpEUeWLZiOn0Fp3MDbwkKNwpwhvJOc4XlSu2MHQbSf59EGhSxs8wOLtlKB/lSBwl7a
         x8d7khOwPqnkhOhgYfRpZpWUF4Qm1Of9P7D4ywKzuP9cIVFrZni75qvGpprbWS6DRUzZ
         rN+g==
X-Gm-Message-State: AOJu0Yzr0NCGcLneh8/ntzA4lg5m07OJgd6xhNj2YWr82NafE1dc1Ddo
	Z4GdwG6Ej7BxWYTncXkpcixWeR9/raGIRUK1FB6iUsE1mBKInM2oPRNWIM6CTrblvjMXSDRLIPl
	2R47j
X-Gm-Gg: ASbGncvWIYYzGlWJlJ+979HtIIW6fBi4B+TMcxGp6oMnD0VpeA8B8+33+q4uh6tkMOD
	Q1EY9a73kZFGzhYUIATPP6hZuo5DkZyEhOsS0CxIkOXWffNgAspq0hFpgLgfUDy2sZVJ4mxVodB
	Pm0qdJGxj/SnOJt9nwTNPbNg454MFXKajCyO8CxNc3RdiXxQXQFq7jmgjV4WvO4mo5pkkgv2e5H
	adLgCtBdo7RYsK7TQQTg1zp6K6d7pk9BchBdzhV/ke/EY7N2y+vkj444kwm6dr+Kn9D+pSAzusi
	hHeY+VvQ8MtBYab2MY2h1mPtaNcsRfF9tB8jTKwNURtv059Frp3RGGKInhzddPS1xqn2oL2nwhk
	/joIokarLPEqPfBLoThFgljJwAgdOPko0rTQ=
X-Google-Smtp-Source: AGHT+IEm8qC0/Cw499LvGYeu6PTVrv6v4GMfM/V8kSQ0Tgoq7Ny42YSk/kZf0kJtD3FICrHJYPgKkA==
X-Received: by 2002:a05:6000:4284:b0:3a2:244:67a4 with SMTP id ffacd0b85a97d-3a35ffd2acbmr14640201f8f.43.1747774363393;
        Tue, 20 May 2025 13:52:43 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH 2/3] tools/tests: Install tests into $(LIBEXEC)/tests
Date: Tue, 20 May 2025 21:52:38 +0100
Message-Id: <20250520205239.203253-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250520205239.203253-1-andrew.cooper3@citrix.com>
References: <20250520205239.203253-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

$(LIBEXEC_BIN) is a dumping ground of many things.  Separate the "clearly
tests" from everything else so we can clean up how they're run in CI.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Stefano Stabellini 
CC: Marek Marczykowski-Górecki 
---
 tools/tests/cpu-policy/Makefile     | 6 +++---
 tools/tests/paging-mempool/Makefile | 6 +++---
 tools/tests/rangeset/Makefile       | 6 +++---
 tools/tests/resource/Makefile       | 6 +++---
 tools/tests/tsx/Makefile            | 6 +++---
 tools/tests/xenstore/Makefile       | 6 +++---
 6 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/tools/tests/cpu-policy/Makefile b/tools/tests/cpu-policy/Makefile
index 5df9b1ebbd7e..24f87e2eca2a 100644
--- a/tools/tests/cpu-policy/Makefile
+++ b/tools/tests/cpu-policy/Makefile
@@ -29,12 +29,12 @@ distclean: clean
 
 .PHONY: install
 install: all
-	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-	$(if $(TARGETS),$(INSTALL_PROG) $(TARGETS) $(DESTDIR)$(LIBEXEC_BIN))
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests
+	$(if $(TARGETS),$(INSTALL_PROG) $(TARGETS) $(DESTDIR)$(LIBEXEC)/tests)
 
 .PHONY: uninstall
 uninstall:
-	$(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/,$(TARGETS))
+	$(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC)/tests/,$(TARGETS))
 
 CFLAGS += -D__XEN_TOOLS__
 CFLAGS += $(CFLAGS_xeninclude)
diff --git a/tools/tests/paging-mempool/Makefile b/tools/tests/paging-mempool/Makefile
index a081b3baa514..a1e12584ce80 100644
--- a/tools/tests/paging-mempool/Makefile
+++ b/tools/tests/paging-mempool/Makefile
@@ -16,12 +16,12 @@ distclean: clean
 
 .PHONY: install
 install: all
-	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-	$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC_BIN)
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests
+	$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC)/tests
 
 .PHONY: uninstall
 uninstall:
-	$(RM) -- $(DESTDIR)$(LIBEXEC_BIN)/$(TARGET)
+	$(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$(TARGET)
 
 CFLAGS += $(CFLAGS_xeninclude)
 CFLAGS += $(CFLAGS_libxenctrl)
diff --git a/tools/tests/rangeset/Makefile b/tools/tests/rangeset/Makefile
index 3dafcbd0546c..e3bfce471cd3 100644
--- a/tools/tests/rangeset/Makefile
+++ b/tools/tests/rangeset/Makefile
@@ -20,12 +20,12 @@ distclean: clean
 
 .PHONY: install
 install: all
-	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-	$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC_BIN)
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests
+	$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC)/tests
 
 .PHONY: uninstall
 uninstall:
-	$(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/,$(TARGET))
+	$(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC)/tests/,$(TARGET))
 
 list.h: $(XEN_ROOT)/xen/include/xen/list.h
 rangeset.h: $(XEN_ROOT)/xen/include/xen/rangeset.h
diff --git a/tools/tests/resource/Makefile b/tools/tests/resource/Makefile
index a5856bf09590..09d678fffe3e 100644
--- a/tools/tests/resource/Makefile
+++ b/tools/tests/resource/Makefile
@@ -20,12 +20,12 @@ distclean: clean
 
 .PHONY: install
 install: all
-	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-	$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC_BIN)
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests
+	$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC)/tests
 
 .PHONY: uninstall
 uninstall:
-	$(RM) -- $(DESTDIR)$(LIBEXEC_BIN)/$(TARGET)
+	$(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$(TARGET)
 
 CFLAGS += $(CFLAGS_xeninclude)
 CFLAGS += $(CFLAGS_libxenctrl)
diff --git a/tools/tests/tsx/Makefile b/tools/tests/tsx/Makefile
index a4f516b72597..0bb7e7010347 100644
--- a/tools/tests/tsx/Makefile
+++ b/tools/tests/tsx/Makefile
@@ -16,12 +16,12 @@ distclean: clean
 
 .PHONY: install
 install: all
-	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-	$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC_BIN)
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests
+	$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC)/tests
 
 .PHONY: uninstall
 uninstall:
-	$(RM) -- $(DESTDIR)$(LIBEXEC_BIN)/$(TARGET)
+	$(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$(TARGET)
 
 .PHONY: uninstall
 uninstall:
diff --git a/tools/tests/xenstore/Makefile b/tools/tests/xenstore/Makefile
index 202dda0d3c23..2ee4a1327e75 100644
--- a/tools/tests/xenstore/Makefile
+++ b/tools/tests/xenstore/Makefile
@@ -20,12 +20,12 @@ distclean: clean
 
 .PHONY: install
 install: all
-	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-	$(if $(TARGETS),$(INSTALL_PROG) $(TARGETS) $(DESTDIR)$(LIBEXEC_BIN))
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests
+	$(if $(TARGETS),$(INSTALL_PROG) $(TARGETS) $(DESTDIR)$(LIBEXEC)/tests)
 
 .PHONY: uninstall
 uninstall:
-	$(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/,$(TARGETS))
+	$(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC)/tests/,$(TARGETS))
 
 CFLAGS += $(CFLAGS_libxenstore)
 CFLAGS += $(APPEND_CFLAGS)
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue May 20 20:52:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 20:52:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991132.1375045 (Exim 4.92)
	(envelope-from )
	id 1uHTx8-0006aT-J1; Tue, 20 May 2025 20:52:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991132.1375045; Tue, 20 May 2025 20: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 1uHTx8-0006aK-Ex; Tue, 20 May 2025 20:52:46 +0000
Received: by outflank-mailman (input) for mailman id 991132;
 Tue, 20 May 2025 20:52:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHTx6-0006MJ-W7
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 20:52:45 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 606472f9-35bc-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 22:52:43 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-442ec3ce724so49974645e9.0
 for ; Tue, 20 May 2025 13:52:43 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a3674fed67sm13346626f8f.89.2025.05.20.13.52.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 13:52: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" 
X-Inumbo-ID: 606472f9-35bc-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747774363; x=1748379163; 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;
        bh=QF2CENVJm5m7t+V0Pvc5Nc5BgJ21+f+zzmuztZZAqXo=;
        b=lv0SzLuWD82UcZyH7XSMupV8IxvHOxfI+l9OLlHIR81D/jgYQEBRmaACV/vZjx7qkq
         B9iqt5M+j0egK+OchiF0FEbVdn6MJwvjsqxa/vW8iEv9M6ui8V+4ef22dU9eR7yTeehs
         B22Cz2GnYZvX1RJUkZjF3ijiv+f7jcbb8+pRs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747774363; x=1748379163;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=QF2CENVJm5m7t+V0Pvc5Nc5BgJ21+f+zzmuztZZAqXo=;
        b=KEqZyxTAlAK7t5alHhMfVm1PWvcGQ5PgD4X8MEx8sPIaTiRHHj/dzROOmmDPMmTWyX
         kiFBDh3UMDrkosRGLpbg148FAf/EFAsud4N3byjQdRK4HUCdKhXlX4Ouioj5oFAZRd+v
         m063WCBoQUtIpxUGXRtN2+DazpyZUqTw8czwnUKPQ0uedW43BkQuPdapqg5nhyvko8Zx
         appgp0cGMjLSOVr76fq9RBkMKG+8ht6CJJKQgUPYE1Tj5SgNpoi0yYlvqkZSG/hMd70T
         rfRqSVcetmsQbfA0CSSerMvSAp94Ni0QklFDamdVVVUqowikMWwyQVrE1t6Lk10akCQb
         1l0Q==
X-Gm-Message-State: AOJu0YzGufoI0lXEtG9dTJa8G4tjomV5OmB8ZmnQrIIo5vb1+EAHc3LV
	Vl59tkZV/fOzPia0GPYxYxlY2zIHT7NdVlSu4cRHxWFXiBOl5UsTLQJ5jT5BiaJka666j6qZ9UR
	frfQy
X-Gm-Gg: ASbGncs01d8BXNOVjDoN35tzIv1bFjJ1cVjL0m6VtxlRys0gEG5WLhGVjG8DgnUsP29
	4nR03w0INcbbi52l23YwqOntLGppxZ2FlPlw427JbPgt5uGDSZ1Y+Ft0DNU6teFO9V7fLR+qnzX
	QZzuc1IhfwHXms7cs/oFz/dXLcxB1fnYAHp2uwa4oNU8DtjwQKSA6OysoQP/d/Hs/PJJj5oM5VM
	lesGA10brdiUcFHsjnAFeLRa2Bl9y4CzioYW/IRE2x0gnn2TvC2dWnkHFLn9mjrdNJ2dYUFqViV
	ISaA91BFHOVOIyaJy/6hHnbvTDeUTVohpA4lcydXNXGyOhftdUYhIN4XmnpYuwB3VGSejnNVWe0
	xFl4hF1ZX0JpdnpGELvBIBN+Q
X-Google-Smtp-Source: AGHT+IF6XfNakqFYxe0RQsn+F/j9c/CDgReDYbe2WRBYgz2TEaGBtLigippEMa+Dd+EUc5kkkbvFdw==
X-Received: by 2002:a05:6000:4024:b0:3a3:6afd:f2dd with SMTP id ffacd0b85a97d-3a36afdf4demr8835081f8f.50.1747774362730;
        Tue, 20 May 2025 13:52:42 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH 1/3] tools/tests: Drop depriv-fd-checker
Date: Tue, 20 May 2025 21:52:37 +0100
Message-Id: <20250520205239.203253-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250520205239.203253-1-andrew.cooper3@citrix.com>
References: <20250520205239.203253-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Unlike the other tests, this is not standalone.  It requires poking at a live
system, making it unweildly to use.

It hasn't been touched in 7 years, despite changes in libraries and kernel
devices using the deprivilege infrastructure.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Stefano Stabellini 
CC: Marek Marczykowski-Górecki 
---
 .gitignore                             |   1 -
 tools/tests/Makefile                   |   1 -
 tools/tests/depriv/Makefile            |  52 ---
 tools/tests/depriv/depriv-fd-checker.c | 436 -------------------------
 4 files changed, 490 deletions(-)
 delete mode 100644 tools/tests/depriv/Makefile
 delete mode 100644 tools/tests/depriv/depriv-fd-checker.c

diff --git a/.gitignore b/.gitignore
index 53f5df000383..4a4e20680464 100644
--- a/.gitignore
+++ b/.gitignore
@@ -165,7 +165,6 @@ tools/misc/xencov
 tools/pkg-config/*
 tools/qemu-xen-build
 tools/xentrace/xenalyze
-tools/tests/depriv/depriv-fd-checker
 tools/tests/x86_emulator/*.bin
 tools/tests/x86_emulator/*.tmp
 tools/tests/x86_emulator/32/x86_emulate
diff --git a/tools/tests/Makefile b/tools/tests/Makefile
index 3e60ab6b268d..36928676a666 100644
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -9,7 +9,6 @@ ifneq ($(clang),y)
 SUBDIRS-$(CONFIG_X86) += x86_emulator
 endif
 SUBDIRS-y += xenstore
-SUBDIRS-y += depriv
 SUBDIRS-y += rangeset
 SUBDIRS-y += vpci
 SUBDIRS-y += paging-mempool
diff --git a/tools/tests/depriv/Makefile b/tools/tests/depriv/Makefile
deleted file mode 100644
index 5404a12f4780..000000000000
--- a/tools/tests/depriv/Makefile
+++ /dev/null
@@ -1,52 +0,0 @@
-XEN_ROOT=$(CURDIR)/../../..
-include $(XEN_ROOT)/tools/Rules.mk
-
-CFLAGS += $(CFLAGS_xeninclude)
-CFLAGS += $(CFLAGS_libxenctrl)
-CFLAGS += $(CFLAGS_libxencall)
-CFLAGS += $(CFLAGS_libxenevtchn)
-CFLAGS += $(CFLAGS_libxengnttab)
-CFLAGS += $(CFLAGS_libxenforeignmemory)
-CFLAGS += $(CFLAGS_libxendevicemodel)
-CFLAGS += $(CFLAGS_libxentoolcore)
-CFLAGS += $(CFLAGS_libxentoollog)
-
-LDLIBS += $(LDLIBS_xeninclude)
-LDLIBS += $(LDLIBS_libxenctrl)
-LDLIBS += $(LDLIBS_libxencall)
-LDLIBS += $(LDLIBS_libxenevtchn)
-LDLIBS += $(LDLIBS_libxengnttab)
-LDLIBS += $(LDLIBS_libxenforeignmemory)
-LDLIBS += $(LDLIBS_libxendevicemodel)
-LDLIBS += $(LDLIBS_libxentoolcore)
-LDLIBS += $(LDLIBS_libxentoollog)
-
-INSTALL_PRIVBIN-y += depriv-fd-checker
-INSTALL_PRIVBIN := $(INSTALL_PRIVBIN-y)
-TARGETS += $(INSTALL_PRIVBIN)
-
-.PHONY: all
-all: build
-
-.PHONY: build
-build: $(TARGETS)
-
-.PHONY: clean
-clean:
-	$(RM) *.o $(TARGETS) *~ $(DEPS_RM)
-
-.PHONY: distclean
-distclean: clean
-
-depriv-fd-checker: depriv-fd-checker.o
-	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS) $(APPEND_LDFLAGS)
-
-install: all
-	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-	$(INSTALL_PROG) $(INSTALL_PRIVBIN) $(DESTDIR)$(LIBEXEC_BIN)
-
-.PHONY: uninstall
-uninstall:
-	rm -f $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/, $(INSTALL_PRIVBIN))
-
--include $(DEPS_INCLUDE)
diff --git a/tools/tests/depriv/depriv-fd-checker.c b/tools/tests/depriv/depriv-fd-checker.c
deleted file mode 100644
index 98a27a03d543..000000000000
--- a/tools/tests/depriv/depriv-fd-checker.c
+++ /dev/null
@@ -1,436 +0,0 @@
-/*
- * depriv-fd-checker
- *
- * utility to check whether file descriptor(s) are deprivileged
- *
- * usage:
- *  .../depriv-fd-checker CLASS FD X-INFO [CLASS FD X-INFO...]
- *
- * CLASS is one of:
- *    privcmd gntdev evtchn     FD should be appropriate Xen control fd
- *    readonly                  FD is expected to be readonly
- *    appendonly                FD is expected to be append write only
- #    tun                       FD is expected to be an open tun device
- *
- * In each case FD is probably a reference to an open-file stolen
- * from another process, eg by the use of fishdescriptor.
- *
- * X-INFO is simply appended to the discursive reportage.
- *
- * It is an error if depriv-fd-checker cannot open the control
- * facilities itself, or something goes wrong with checking, or an FD
- * is entirely the wrong kind for the specified CLASS.  Otherwise:
- *
- * depriv-fd-checker will perhaps print, for each triplet:
- *   CLASS checking FD INFORMATION... X-INFO
- * and in any case print, for each triplet, exactly one of:
- *   CLASS pass|fail FD INFORMATION... X-INFO
- *   tun maybe FD IFNAME X-INFO
- *
- * "pass" means that the descriptor was restricted as expected.
- * "fail" means that the descriptor was unrestricted.
- * "maybe" means that further information is printed, as detailed above,
- *         and the caller should check that it is as expected
- */
-/*
- * Copyright (C)2018 Citrix Systems R&D
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public License
- * as published by the Free Software Foundation; version 2.1 of the
- * License.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; If not, see
- * .
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-/*
- * Every class needs setup.  setup is called once per class at program
- * startup.
- *
- * Then it can have
- *     open test getfd close
- * In which case the core code will for every fd
- *     open test getfd dup2 test close
- * And test should call blocked or succeeded and then immediately
- * return, or error out
- *
- * Or it can have
- *     check
- * which should call report, or error out
- *
- * Errors: use trouble for simple syscall errors.  Or use err or errx
- * and maybe print fd_desc and test_which, according to the comments
- * in struct classinfo.
- */
-
-static xentoollog_logger *logger;
-
-static int object_fd;
-static const char *classname;
-static const char *fd_desc;
-static const char *test_which;
-
-static const char *test_wh_unrest = "test (unrestricted)";
-static const char *test_wh_rest   = "test (restricted)";
-
-
-static void trouble(const char *what) __attribute__((noreturn));
-static void trouble(const char *what) {
-    fprintf(stderr,
-	    "trouble: %s %s %d (%s) %s: %s\n",
-	    classname, test_which, object_fd, fd_desc, what, strerror(errno));
-    exit(-1);
-}
-
-static void report(const char *pass_or_fail, const char *what,
-		   const char *notes) {
-    printf("%s %s %d %s (%s) %s\n",
-	   classname, pass_or_fail,
-	   object_fd, what, notes, fd_desc);
-    if (ferror(stdout) || fflush(stdout)) err(16,"stdout");
-}
-
-static void succeeded(const char *what) {
-    if (test_which == test_wh_unrest) {
-	/* ok */
-	test_which = 0;
-    } else if (test_which == test_wh_rest) {
-	report("fail",what,"unexpectedly succeeded");
-	test_which = 0;
-    } else {
-	abort();
-    }
-}
-
-static void blocked(const char *what) {
-    if (test_which == test_wh_rest) {
-	/* yay */
-	report("pass", what,"blocked");
-	test_which = 0;
-    } else if (test_which == test_wh_unrest) {
-	err(4,"test blocked on unrestricted fd: %s {%s}",what,test_which);
-    } else {
-	abort();
-    }
-}
-
-/* privcmd */
-
-static xc_interface *xch;
-static void setup_privcmd(void) { }
-static void open_privcmd(void) {
-    xch = xc_interface_open(logger,0,0);
-    if (!xch) trouble("xc_interface_open");
-}
-static void test_privcmd(void) {
-    int r = xc_get_online_cpus(xch);
-    if (r>0)
-	succeeded("xc_get_online_cpus");
-    else if (r==0)
-	errx(-1,"xc_get_online_cpus{%s, %s}=0", test_which, fd_desc);
-    else if (errno==EPERM || errno==EACCES)
-	blocked("xc_get_online_cpus");
-    else
-	trouble("xc_get_online_cpus");
-}
-static int getfd_privcmd(void) {
-    return xencall_fd(xc_interface_xcall_handle(xch));
-}
-static void close_privcmd(void) {
-    xc_interface_close(xch);
-}
-
-/* gntdev */
-
-static xengntshr_handle *xgs;
-static uint32_t gntshr_gref;
-static xengnttab_handle *xgt;
-static void setup_gntdev(void) {
-    void *r;
-    xgs = xengntshr_open(logger,0);
-    if (!xgs) trouble("xengntshr_open");
-    r = xengntshr_share_pages(xgs, 0, 1, &gntshr_gref, 1);
-    if (!r || r==(void*)-1) trouble("xengntshr_share_pages");
-    memset(r, 0x55, XC_PAGE_SIZE);
-}
-static void open_gntdev(void) {
-    xgt = xengnttab_open(logger,0);
-    if (!xgt) trouble("xengnttab_open");
-}
-static void test_gntdev(void) {
-    char mybuf[XC_PAGE_SIZE];
-    memset(mybuf, 0xaa, XC_PAGE_SIZE);
-    xengnttab_grant_copy_segment_t seg;
-    seg.source.foreign.ref = gntshr_gref;
-    seg.source.foreign.offset = 0;
-    seg.source.foreign.domid = 0;
-    seg.dest.virt = mybuf;
-    seg.len = 1;
-    seg.flags = GNTCOPY_source_gref;
-    for (;;) {
-	seg.status = 0;
-	int r = xengnttab_grant_copy(xgt,1,&seg);
-	if (r<0) {
-	    if (errno==EPERM || errno==EACCES || errno==ENOTTY)
-		blocked("xengnttab_grant_copy");
-	    else
-		trouble("xengnttab_grant_copy");
-	} else if (r==0) {
-	    if (seg.status==GNTST_okay)
-		succeeded("xengnttab_grant_copy okay");
-	    else if (seg.status==GNTST_eagain)
-		continue;
-	    else errx(-1,"xengnttab_grant_copy=%d {%s, %s} but .status=%d",
-		      r, test_which, fd_desc,(int)seg.status);
-	} else {
-	    errx(-1,"xengnttab_grant_copy=%d {%s, %s}",
-		 r, test_which, fd_desc);
-	}
-	break;
-    }
-}
-static int getfd_gntdev(void) {
-    return xengnttab_fd(xgt);
-}
-static void close_gntdev(void) {
-    xengnttab_close(xgt);
-}
-
-/* evtchn */
-
-static xenevtchn_handle *xce_recip, *xce;
-static void setup_evtchn(void) {
-    xce_recip = xenevtchn_open(logger, 0);
-    if (!xce_recip) err(-1,"xenevtchn_open (donor)");
-}
-static void open_evtchn(void) {
-    xce = xenevtchn_open(logger, 0);
-    if (!xce) err(-1,"xenevtchn_open");
-}
-static void test_evtchn(void) {
-    xenevtchn_port_or_error_t
-        recip_port=-1, test_unbound_port=-1, test_send_port=-1;
-
-    recip_port = xenevtchn_bind_unbound_port(xce_recip, 0);
-    if (recip_port < 0) trouble("xenevtchn_bind_unbound_port");
-
-    test_unbound_port = xenevtchn_bind_unbound_port(xce, 0);
-    if (test_unbound_port >= 0) {
-        succeeded("xenevtchn_bind_unbound_port");
-        goto out;
-    }
-
-    test_send_port = xenevtchn_bind_interdomain(xce, 0, recip_port);
-    /* bind_interdomain marks the channel pending */
-    struct pollfd pfd;
-    for (;;) {
-        pfd.fd = xenevtchn_fd(xce_recip);
-        pfd.events = POLLIN;
-        pfd.revents = 0;
-        int r = poll(&pfd,1,0);
-        if (r>=0) break;
-        if (errno!=EINTR) err(-1,"poll(xce_recip)");
-    }
-    if (pfd.revents & POLLIN) {
-        xenevtchn_port_or_error_t p3 = xenevtchn_pending(xce_recip);
-        if (p3 < 0) err(-1,"xenevtchn_pending(check)");
-        if (p3 != recip_port)
-            errx(-1,"xenevtchn_pending=%d expected %d",p3,recip_port);
-        xenevtchn_unmask(xce_recip, recip_port);
-    }
-
-    if (test_send_port>=0 && (pfd.revents & POLLIN)) {
-        succeeded("xenevtchn_bind_interdomain/poll");
-        /* we make no attempt to undo what we did to this stolen fd;
-         * the rightful owner will see a spurious event on test_send_port */
-    } else if (test_send_port==-1 && !(pfd.revents & POLLIN) &&
-               (errno==EPERM || errno==EACCES || errno==ENOTTY)) {
-	blocked("xenevtchn_notify");
-    } else {
-        err(-1,"%s %s xenevtchn_bind_interdomain=%d .revents=0x%x",
-             test_which, fd_desc, test_send_port, pfd.revents);
-    }
-
- out:
-    if (recip_port        > 0) xenevtchn_unbind(xce, recip_port);
-    if (test_unbound_port > 0) xenevtchn_unbind(xce, test_unbound_port);
-    if (test_send_port    > 0) xenevtchn_unbind(xce, test_send_port);
-}
-static int getfd_evtchn(void) {
-    return xenevtchn_fd(xce);
-}
-static void close_evtchn(void) {
-    xenevtchn_close(xce);
-}
-
-/* fcntl */
-
-#define CHECK_FCNTL(openmode)				\
-    int r = fcntl(object_fd, F_GETFL);			\
-    if (r < 0) trouble("fcntl F_GETFL");		\
-    int m = r & (O_RDONLY | O_WRONLY | O_RDWR);		\
-							\
-    char mbuf[100 + 30*3];				\
-    snprintf(mbuf,sizeof(mbuf),				\
-	     "F_GETFL=%#o m=%#o " #openmode "=%#o",	\
-	     r,m,(int)openmode);			\
-							\
-    if (m != openmode) {				\
-	report("fail", #openmode, mbuf);		\
-	return;						\
-    }
-
-/* readonly */
-
-static void setup_readonly(void) { }
-static void check_readonly(void) {
-    CHECK_FCNTL(O_RDONLY);
-    report("pass", "fcntl", mbuf);
-}
-
-/* appendonly */
-
-static void setup_appendonly(void) { }
-static void check_appendonly(void) {
-    CHECK_FCNTL(O_WRONLY);
-    if (!(r & O_APPEND)) {
-	report("fail", "O_APPEND", mbuf);
-	return;
-    }
-    report("pass", "fcntl", mbuf);
-}
-
-#if defined(__linux__)
-#include 
-#include 
-#include 
-#include 
-#include 
-#ifndef TUNGETIFF
-#define TUNGETIFF _IOR('T', 210, unsigned int)
-#endif
-
-/* linux tun */
-
-static void setup_tun(void) { }
-static void check_tun(void) {
-    struct ifreq ifr;
-    int r;
-
-    memset(&ifr,0,sizeof(ifr));
-    r = ioctl(object_fd, TUNGETIFF, (void*)&ifr);
-    if (r<0) trouble("TUNGETIFF");
-    printf("tun maybe %d %.*s %s\n", object_fd,
-           (int)IFNAMSIZ, ifr.ifr_ifrn.ifrn_name,
-           fd_desc);
-}
-
-#define PLATFORM_CLASSES \
-    DEFCHECK(tun),
-
-#else /* !defined(__linux__) */
-#define PLATFORM_CLASSES /* empty */
-#endif
-
-/* class table and main program */
-
-#define DEFCLASS(cl) \
-    { #cl, setup_##cl, 0, open_##cl, test_##cl, getfd_##cl, close_##cl }
-#define DEFCHECK(meth) \
-    { #meth, setup_##meth, check_##meth }
-
-static const struct classinfo {
-    const char *name;     /* errors: print fd_desc   test_which */
-    void (*setup)(void);  /*               best not   best not  */
-    void (*check)(void);  /*               must       may       */
-    void (*open)(void);   /*               must       may       */
-    void (*test)(void);   /*               must       must      */
-    int (*getfd)(void);   /*               must       may       */
-    void (*close)(void);  /*               must       may       */
-} classinfos[] = {
-    DEFCLASS(privcmd),
-    DEFCLASS(gntdev),
-    DEFCLASS(evtchn),
-    DEFCHECK(readonly),
-    DEFCHECK(appendonly),
-    PLATFORM_CLASSES
-    { 0 }
-};
-
-int main(int argc, char **argv) {
-    const struct classinfo *cli;
-    int r;
-
-    argv++;
-
-    logger = (xentoollog_logger*)xtl_createlogger_stdiostream
-	(stderr, XTL_NOTICE, XTL_STDIOSTREAM_HIDE_PROGRESS);
-
-    fd_desc = "setup";
-    test_which = "setup";
-    for (cli = classinfos; cli->name; cli++)
-	cli->setup();
-
-    while ((classname = *argv++)) {
-	if (!*argv) errx(8,"need fd after class");
-	object_fd = atoi(*argv++);
-
-	fd_desc = *argv++;
-	if (!fd_desc) errx(8,"need info after fd");
-
-	for (cli = classinfos; cli->name; cli++)
-	    if (!strcmp(cli->name, classname))
-		goto found;
-	report("fail","unknown class","");
-	continue;
-
-    found:
-	if (cli->check) {
-	    report("checking","check","in progress");
-	    test_which = "check";
-	    cli->check();
-	} else {
-	    test_which = "open";
-	    report("checking","dup-hack","in progress");
-                                                  cli->open();
-
-	    test_which = test_wh_unrest;          cli->test();
-	    assert(!test_which);
-
-	    test_which = "getfd"; int intern_fd = cli->getfd();
-	    r = dup2(object_fd, intern_fd);
-	    if (r != intern_fd) err(-1, "dup2");
-
-	    test_which = test_wh_rest;             cli->test();
-	    assert(!test_which);
-
-	    test_which = "close";                  cli->close();
-	}
-    }
-
-    return 0;
-}
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue May 20 20:52:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 20:52:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991131.1375034 (Exim 4.92)
	(envelope-from )
	id 1uHTx7-0006Ma-6X; Tue, 20 May 2025 20:52:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991131.1375034; Tue, 20 May 2025 20:52: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 1uHTx7-0006MP-3d; Tue, 20 May 2025 20:52:45 +0000
Received: by outflank-mailman (input) for mailman id 991131;
 Tue, 20 May 2025 20:52:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHTx6-0006MJ-AM
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 20:52:44 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5fd129eb-35bc-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 22:52:43 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a36efcadb8so2140560f8f.0
 for ; Tue, 20 May 2025 13:52:43 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a3674fed67sm13346626f8f.89.2025.05.20.13.52.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 13:52: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" 
X-Inumbo-ID: 5fd129eb-35bc-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747774362; x=1748379162; 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;
        bh=C/l2BVJeDm+UzPcDvtIlIYkEo9QuHWXfEJ0aG0HjNrM=;
        b=EBjqDlvG7Z95XSX8jLIQBNhXnEfz8VAKSA+EocNr9oJ4CT9QqeU2PgVJFHoKK17+fE
         qUcbFiovy37JdEebs7ywMTxNdDc60mf+vOWMhR0b4Xdz9V2FfPaU/r6xnIs+aH8HMk5g
         y0fjek2VFx2cp2VN8SqK0H4nwbk0yIJ7dzdgo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747774362; x=1748379162;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=C/l2BVJeDm+UzPcDvtIlIYkEo9QuHWXfEJ0aG0HjNrM=;
        b=gWvRHQwtnE1IOtaFMgks5c49WNL0euetHXWEFiK1Jxz8bxyGZVIccbSUhER3w6zWzT
         K0FJ0D8UmtegUaLRJ97v44wEsXwb+ooFWJBiEXPpip/CUkjKguBZQUa2susSQ4IIW9yB
         1/b2DQu+K57zsGAdQt97MALw/Tjg3nmi2oOX63a8Wp4r8oWw4OOnFNLyO1OGD0kkxBau
         D6Or9rrbEDI/GXpV4ntth800vv1IShbUNwoMDMTuBjjvWIIxFTf/L00TI4GZ6LfmPMiL
         JD3iT36ivFWeu+Iwo6NwTPtv4fbH4odDI/5DfpA6zXFtKGFAe/F5q4acUEAP4Z+6AiPw
         LpDA==
X-Gm-Message-State: AOJu0YyeEpn0rf3mixuUMTVfkDld0DFjI5AWezkADtftOx6eJtnaPH4n
	MI0jx6WlSddCXqkJ5F8Y1h4x2niVExjI4MFXmP6C3aSrEDK/2kYVnDemi2VEGnwqrQrWE5W/R9Y
	9jLrR
X-Gm-Gg: ASbGnctaNgHAe65irekCecAlzDNPw8kiKXMYdieKZaTZIxKlIH5DAiBXS9pPJ0RoqDu
	sAL4JqtL+CWj4QwF2zTFIH9pSov/htwOTPpGhbh1x4wlwdRJpGet1mRTRpOHPWVpEEiC37md0nl
	2LpjHpWay1bjHYRnZCK9Br74m4O3uJtE6ILu+22G4vR4Madjp0Yw5P7RrC3FFSqUDtnXJRxl/Zd
	vUWKNlernXshd0LxqZkhil4PlYbEv6yCN2ayNuVTlrg4a9nyuTh7j2shagA8Y0/r1GCwIZAcfEw
	Hx1F6rOvWksIrjyW2WLcXh4oG1iUDY5a++fAF36rGY7EvaKp+06yp162kA9AQ8OVy2uXtmvuYHC
	bU4DTv4POxUPXBcUYZDSp1D1a
X-Google-Smtp-Source: AGHT+IFStY4KEKg8qLifm7M4qeyzKCHLerqxOma2rp7r8/dmuIzEV5YDIoXOEX1u99YgHzsf9RK1cQ==
X-Received: by 2002:a05:6000:184d:b0:3a0:b539:f330 with SMTP id ffacd0b85a97d-3a35c808ba8mr18168534f8f.2.1747774362014;
        Tue, 20 May 2025 13:52:42 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH 0/3] CI: Improvements to *-tools-test-* jobs
Date: Tue, 20 May 2025 21:52:36 +0100
Message-Id: <20250520205239.203253-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

Rearrange tools/tests to be more ameanable to running in CI, and drop the
special casing holding it together.



Andrew Cooper (3):
  tools/tests: Drop depriv-fd-checker
  tools/tests: Install tests into $(LIBEXEC)/tests
  CI: Drop custom handling of tools/tests

 .gitignore                             |   1 -
 automation/scripts/build               |   1 -
 automation/scripts/qubes-x86-64.sh     |   7 +-
 automation/scripts/run-tools-tests     |  43 ++-
 tools/tests/Makefile                   |   1 -
 tools/tests/cpu-policy/Makefile        |   6 +-
 tools/tests/depriv/Makefile            |  52 ---
 tools/tests/depriv/depriv-fd-checker.c | 436 -------------------------
 tools/tests/paging-mempool/Makefile    |   6 +-
 tools/tests/rangeset/Makefile          |   6 +-
 tools/tests/resource/Makefile          |   6 +-
 tools/tests/tsx/Makefile               |   6 +-
 tools/tests/xenstore/Makefile          |   6 +-
 13 files changed, 40 insertions(+), 537 deletions(-)
 delete mode 100644 tools/tests/depriv/Makefile
 delete mode 100644 tools/tests/depriv/depriv-fd-checker.c

-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue May 20 20:52:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 20:52:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991134.1375061 (Exim 4.92)
	(envelope-from )
	id 1uHTxA-0006rY-42; Tue, 20 May 2025 20:52:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991134.1375061; Tue, 20 May 2025 20:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHTx9-0006qk-TD; Tue, 20 May 2025 20:52:47 +0000
Received: by outflank-mailman (input) for mailman id 991134;
 Tue, 20 May 2025 20:52:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHTx9-0006hP-90
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 20:52:47 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 612c3e36-35bc-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 22:52:45 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a36efcadb8so2140590f8f.0
 for ; Tue, 20 May 2025 13:52:45 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a3674fed67sm13346626f8f.89.2025.05.20.13.52.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 13:52: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" 
X-Inumbo-ID: 612c3e36-35bc-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747774364; x=1748379164; 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;
        bh=QfhsUGiiQGKcqNXvuoCj4gQfcfj05NuHnllW0lUrwak=;
        b=sVx8AfwfaAV9Pr26TRafSsqLLvLS0Ugl8OPqPxMjY8eZgk0Sm12jhYhnhOqFN/OPQU
         O1rPC40/dapnd4HKI6JID+MqO8wJHG9Up4rErDPnqN8OgAgAjPIW4PsOafn+6hyltcrA
         xYnf2pyBhBkioDpwieUPMlb++h0u1gJcNF3J4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747774364; x=1748379164;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=QfhsUGiiQGKcqNXvuoCj4gQfcfj05NuHnllW0lUrwak=;
        b=i4+Y9sl6Huir9D19Vl48kGKNv6H0bXmWGP/R5Xaf1/xcq9kjxA9KVzK4T9EZBSqAYf
         vv10kEdytW9GxsuorIznQMVi9vRIVaLOxlQ0IaWpIT1TWmw+1rl0Imhi7kQCnwY2FOZx
         BPD7hP20X/MABkpFGgGvXxp+h89dWccB5GeiADLfvZgHtWmvjOr5vTcleczXe/YKHOo/
         25MzqG+m29e77YHb4bkZ6QIzwxQU3mYAFMya3xAfIlF1E32TVgWl9x2cTBqrKFOVsLru
         w+Z4dTCTbjow2Uh71ro93DAudyLNFKWbXuAMA/F9/by8PgQekgk7BaXEXYFLxCz9AQN/
         /t/Q==
X-Gm-Message-State: AOJu0YyhOyeouSg9T7DMjYBZbDjoK8CTT1QKPrUWQ3UA4f135ztGpmjp
	Vbztu4nrdLs3sTPV6reowg2u0dTqpL4FyAgxUAPRaEB0CfCQKktl/346q7UzGKPEyH/0u8v1pdE
	1b/dt
X-Gm-Gg: ASbGncuqtEVGPRNz58midjjozcB1hK6sf5F/u7/jW9QzGcMYWXc1sx3piPuT5t/1yCv
	oZ3FXSeEEXhTfng21VEfd7o8xrQIbKirQPlo8DqwOgIjpSyaWqWh28UuUD/K5IcjnDmwoGzpQ7N
	BeqD8+z0LfCuwDIJ4eq2U2RqZhQ5ONNBzKyr1MnZFusjObWhTIkqX9PEEkkiheWSIrzpud1E29w
	fpZnlw+dfitvcNzyZyiOc/eLAvvXZBfCzp3mPJ8NuPmhHZvAyItvsX6AsSuuVLTyUgofBVD+WAU
	abYd+txGdCtlQ2bA5iiAjVIo9tZjsKkO5hIZpFHwet7UllPeSrV2Qs217SnGNkjnhH5RbBVhK1x
	I36PxkR4ZlHbE67ZrrA33SiYt
X-Google-Smtp-Source: AGHT+IHZzkHzMWJczmaSAVLmaheYUXHfYvPj47cipkwBJABK0sJZa5J9y+KNAjZkNCfUlFKBK2hxfA==
X-Received: by 2002:a05:6000:1846:b0:38f:4d20:4a17 with SMTP id ffacd0b85a97d-3a35c8218b5mr14937603f8f.13.1747774364176;
        Tue, 20 May 2025 13:52:44 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH 3/3] CI: Drop custom handling of tools/tests
Date: Tue, 20 May 2025 21:52:39 +0100
Message-Id: <20250520205239.203253-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250520205239.203253-1-andrew.cooper3@citrix.com>
References: <20250520205239.203253-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

... and use them from their installed location.

The full recusive copy of tools/tests brings in all build and intermediate
artefacts.  e.g. for test-tsx alone:

  ./tests/tsx
  ./tests/tsx/.test-tsx.o.d
  ./tests/tsx/test-tsx.o
  ./tests/tsx/.gitignore
  ./tests/tsx/test-tsx
  ./tests/tsx/Makefile
  ./tests/tsx/test-tsx.c

duplicating the test binary which is also in ./usr/lib/xen/tests

Rewrite run-tools-tests to run tests from their installed
location (/usr/lib/xen/tests in alpine), which effectively removes the outer
loop over $dir.

No practical change.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Stefano Stabellini 
CC: Marek Marczykowski-Górecki 

This doesn't change any tests that run, although in the XML we get two fewer skips.

Both skips can be fixed by giving vpci and x86_emulator some install targets
---
 automation/scripts/build           |  1 -
 automation/scripts/qubes-x86-64.sh |  7 +++--
 automation/scripts/run-tools-tests | 43 +++++++++++++-----------------
 3 files changed, 22 insertions(+), 29 deletions(-)

diff --git a/automation/scripts/build b/automation/scripts/build
index cdb8cd7c722b..0e7494ff6d87 100755
--- a/automation/scripts/build
+++ b/automation/scripts/build
@@ -109,6 +109,5 @@ else
     # even though dist/ contains everything, while some containers don't even
     # build Xen
     (cd dist/install; find | cpio -o -H newc | gzip) > binaries/xen-tools.cpio.gz
-    cp -r tools/tests binaries/
     collect_xen_artefacts
 fi
diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index aa47ba6bf5c0..577a00238a75 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -136,7 +136,7 @@ done
         passed="test passed"
         domU_check=""
         dom0_check="
-/tests/run-tools-tests /tests /tmp/tests-junit.xml && echo \"${passed}\"
+/root/run-tools-tests /usr/lib/xen/tests /tmp/tests-junit.xml && echo \"${passed}\"
 nc -l -p 8080 < /tmp/tests-junit.xml >/dev/null &
 "
         if [ "${test_variant}" = "tools-tests-pvh" ]; then
@@ -195,9 +195,8 @@ cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
 # test-local configuration
 mkdir -p rootfs
 cd rootfs
-mkdir -p boot etc/local.d
-cp -ar ../binaries/tests .
-cp -a ../automation/scripts/run-tools-tests tests/
+mkdir -p boot etc/local.d root
+cp -a ../automation/scripts/run-tools-tests root/
 
 echo "#!/bin/bash
 
diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
index 770e97c3e943..8d7aa8fa5140 100755
--- a/automation/scripts/run-tools-tests
+++ b/automation/scripts/run-tools-tests
@@ -12,30 +12,25 @@ printf '\n' > "$xml_out"
 printf '\n' >> "$xml_out"
 printf ' \n' >> "$xml_out"
 failed=
-for dir in "$1"/*; do
-    [ -d "$dir" ] || continue
-    echo "Running test in $dir"
-    printf '  \n' "$dir" >> "$xml_out"
-    ret=
-    for f in "$dir"/*; do
-        [ -f "$f" ] || continue
-        [ -x "$f" ] || continue
-        "$f" 2>&1 | tee /tmp/out
-        ret=$?
-        if [ "$ret" -ne 0 ]; then
-            echo "FAILED: $ret"
-            failed+=" $dir"
-            printf '   \n' "$f" "$ret" >> "$xml_out"
-            # TODO: could use xml escaping... but current tests seems to
-            # produce sane output
-            cat /tmp/out >> "$xml_out"
-            printf '   \n' >> "$xml_out"
-        else
-            echo "PASSED"
-        fi
-    done
-    if [ -z "$ret" ]; then
-        printf '   \n' "$dir" >> "$xml_out"
+for f in "$1"/*; do
+    if [ -x "$f" ]; then
+        echo "SKIP: $f not executable"
+        continue
+    fi
+    echo "Running $f"
+    printf '  \n' "$f" >> "$xml_out"
+    "$f" 2>&1 | tee /tmp/out
+    ret=$?
+    if [ "$ret" -ne 0 ]; then
+        echo "FAILED: $f"
+        failed+=" $f"
+        printf '   \n' "$f" "$ret" >> "$xml_out"
+        # TODO: could use xml escaping... but current tests seems to
+        # produce sane output
+        cat /tmp/out >> "$xml_out"
+        printf '   \n' >> "$xml_out"
+    else
+        echo "PASSED"
     fi
     printf '  \n' >> "$xml_out"
 done
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue May 20 21:02:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 21:02:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991171.1375075 (Exim 4.92)
	(envelope-from )
	id 1uHU6E-0001gJ-Vu; Tue, 20 May 2025 21:02:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991171.1375075; Tue, 20 May 2025 21:02: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 1uHU6E-0001gC-St; Tue, 20 May 2025 21:02:10 +0000
Received: by outflank-mailman (input) for mailman id 991171;
 Tue, 20 May 2025 21:02:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHU6D-0001fn-Si
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 21:02:09 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b0b9f1dd-35bd-11f0-b892-0df219b8e170;
 Tue, 20 May 2025 23:02:08 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a35c894313so3811294f8f.2
 for ; Tue, 20 May 2025 14:02:08 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca5a892sm17187164f8f.24.2025.05.20.14.02.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 14:02: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" 
X-Inumbo-ID: b0b9f1dd-35bd-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747774927; x=1748379727; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bKrzXzo8HG+/E0Y6LVc9S8OCNl/Zfeqv+vR2YpFSpzo=;
        b=GiTco9uJTS+CDccGwN9nTS3yM5r+K4eMlQUyjp+gfOgLs7ZL9NHO0DrfP0VcYG8+8h
         vd8xsNC360YYoJQWFjrxPK+rRW418R0kM6x5mMj3EMeyAl8OQ0yTA8b96BSZJ+9PqpFP
         P3BdRFn0frUZ5gxvHanu3n6Sh06qorpqmMULc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747774927; x=1748379727;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bKrzXzo8HG+/E0Y6LVc9S8OCNl/Zfeqv+vR2YpFSpzo=;
        b=Wi0Jy5+aESRmTr/btiBofhA+4In8bKToVCreeBE4siEpBWKiTeKEHTJ4h41Dvyg0uq
         2FtUSVNkFooM2Zey/BI8fSYB4E7A4RLMdVscISeetSHI8aui4t3kVAuuVMffA4guD01k
         NTblDRJlIoBBZ5OGMXAIGQ8OThq3o/SgXm/aMtaeLYmpukIdXG7A8vWVMmCWaaVyQqT+
         V0i+R4qh63l9fYnQHsSGpZePpGZjEpGQRJsJMon9MeQbcLiRE+Iwli8mq47eXHKRY3Kn
         Q5AcLYDTk9JjqbVqR76K8C7Wc9SJ7DlD9hHHNHve7tOzr0a80V/SzWiCUPcgeTbQLXy9
         lihw==
X-Gm-Message-State: AOJu0YywGbatqfzWGuZzqPtKqVc6xFCowkqF3aHgizEhHHOYBxTjibDw
	bmFtVSpBVWgZUexdsnjzAwTrRYwAlDmOIZV/WgABSwlgnv2PHJXJNZI/bAzYOTzP6uHzjlNNwXw
	KTp+Z
X-Gm-Gg: ASbGncvvTYI7hVn6vkxkA9hSYT3sh7iz+AgVkTnH1+eU/zBMsrfhQ8rHUtYEuw4H6fF
	ZL+NoECfC7zPmRLtzQDGp1G/Oepp167ffh28gF48JKMBKMvy7bfAFaGlm8g2kk0iyui8Mal+sWT
	vz9IV2gIHHdT4y1KIgpvjdswpLVrUUJjar1ULM7vk1YofXizZEjMgL9Bs6BFM0mqIkuiiBw6Y1A
	QyhVJ6e0+AGspyhOZ2J99bPssczbfmDdZZHfiBPpF+UElxuF750afgLDPRxOXIIsolMjg+YBM/a
	Ko+ZuGcGnFneko0BkBKtiNaHlKNrkAAMLEnhGgYQFisemObgZwdmgQojq57X/KtD2K+vZk4vhX5
	PkgeJ8qPACtAE32Tg
X-Google-Smtp-Source: AGHT+IFWZoOeDbSv9U8x3wlaEWeVvlD0PEwg+/g5fLbDDIdBmcj4AuaFLFIMx2pD2JcctP2YtpkrNw==
X-Received: by 2002:a5d:5889:0:b0:3a3:7096:a217 with SMTP id ffacd0b85a97d-3a37096a495mr7201569f8f.17.1747774927203;
        Tue, 20 May 2025 14:02:07 -0700 (PDT)
Message-ID: <724b77b5-3b78-436e-bd20-726c34bef03b@citrix.com>
Date: Tue, 20 May 2025 22:02:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools: Add install/uninstall targets to
 tests/x86_emulator
To: Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini 
References: <20240516110710.3446-1-alejandro.vallejo@cloud.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: <20240516110710.3446-1-alejandro.vallejo@cloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16/05/2024 12:07 pm, Alejandro Vallejo wrote:
> Bring test_x86_emulator in line with other tests by adding
> install/uninstall rules.
>
> Signed-off-by: Alejandro Vallejo 
> ---
>  tools/tests/x86_emulator/Makefile | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile
> index 834b2112e7fe..30edf7e0185d 100644
> --- a/tools/tests/x86_emulator/Makefile
> +++ b/tools/tests/x86_emulator/Makefile
> @@ -269,8 +269,15 @@ clean:
>  .PHONY: distclean
>  distclean: clean
>  
> -.PHONY: install uninstall
> -install uninstall:
> +.PHONY: install
> +install: all
> +	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
> +	$(if $(TARGET-y),$(INSTALL_PROG) $(TARGET-y) $(DESTDIR)$(LIBEXEC_BIN))
> +
> +.PHONY: uninstall
> +uninstall:
> +	$(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/,$(TARGET-y))
> +
>  
>  .PHONY: run32 clean32
>  ifeq ($(XEN_COMPILE_ARCH),x86_64)

[starting a clean thread]

x86_emulator is not special enough to behave differently to the rest of
tools/.

Theoretical concerns over cross compiling test_x86_emulator for non-x86
can be fixed by whomever first wants to do this.

The very real problem is that this doesn't run in x86 CI, because and
only because it doesn't have an install target.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 20 21:39:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 21:39:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991183.1375084 (Exim 4.92)
	(envelope-from )
	id 1uHUgP-0005yC-N4; Tue, 20 May 2025 21:39:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991183.1375084; Tue, 20 May 2025 21:39:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHUgP-0005y5-K1; Tue, 20 May 2025 21:39:33 +0000
Received: by outflank-mailman (input) for mailman id 991183;
 Tue, 20 May 2025 21:39:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHUgM-0005xz-Vg
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 21:39:32 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e82e493b-35c2-11f0-a2fa-13f23c93f187;
 Tue, 20 May 2025 23:39: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" 
X-Inumbo-ID: e82e493b-35c2-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747777166; x=1748036366;
	bh=9tmznKEy/lBSTc5WBcDJRk9WJnX1M0ut/Vj9hgMu1wc=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=Ckd5u33CnRsaKJm8QtNZXuv2xOscFGJjIMBNFF7gYc8SGWbRTwL/t7UVua6a0U/pt
	 kVSPdezlwOzfFTts1hvj5U65P2DSZ155bd3+p43ZFGH0zAxNRF9sd5oAhNxRHjRwH1
	 uBJmetpBLS3CghPXo9pIPxmjZdkkf84z31SS9qTNOFK+o12RCjFOInKIlpIBtxuNKn
	 HFfCOscznysfph+vPIxOs6UEogv8Bkxf39f6cw7ggR+GZMqS2pNRR3HQnOjvT9IPPW
	 DfW3gbi70BCn+vkfVmUEyrt/Rt4hUfKmMabESytHXcfUNfhjLQ1HgZKYcVvzbYGBzy
	 OBIIzkI88y7sA==
Date: Tue, 20 May 2025 21:39:20 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/2] xen/domain: introduce non-x86 hardware emulation flags
Message-ID: 
In-Reply-To: 
References: <20250516022855.1146121-1-dmukhin@ford.com> <20250516022855.1146121-2-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 87fceb50b9587fc00eb35a932d3c0b8dd7ae2399
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 20, 2025 at 05:21:06PM +0200, Jan Beulich wrote:
> On 16.05.2025 04:29, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Define per-architecture emulation_flags for configuring domain emulatio=
n
> > features.
> >
> > Print d->arch.emulation_flags from 'q' keyhandler for better traceabili=
ty
> > while debugging.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v1:
> > - dropped comments
> > ---
> >  xen/arch/arm/include/asm/domain.h   | 1 +
> >  xen/arch/ppc/include/asm/domain.h   | 1 +
> >  xen/arch/riscv/include/asm/domain.h | 1 +
> >  xen/common/keyhandler.c             | 1 +
> >  4 files changed, 4 insertions(+)
>=20
> If every arch gains identical fields, accessed from common code, why woul=
d
> those need to live in struct arch_domain?

I did it this way to keep the diff smaller, but I agree such property
makes sense to put in common domain struct. Will update in v3.

Thanks!

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Tue May 20 22:38:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 22:38:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991212.1375095 (Exim 4.92)
	(envelope-from )
	id 1uHVbi-0004nK-Ts; Tue, 20 May 2025 22:38:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991212.1375095; Tue, 20 May 2025 22:38: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 1uHVbi-0004nD-RF; Tue, 20 May 2025 22:38:46 +0000
Received: by outflank-mailman (input) for mailman id 991212;
 Tue, 20 May 2025 22:38:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHVbf-0004n7-Io
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 22:38:44 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2d76d4fa-35cb-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 00:38: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" 
X-Inumbo-ID: 2d76d4fa-35cb-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=3kmeimwcg5anvaqtqopafa2g7m.protonmail; t=1747780719; x=1748039919;
	bh=GU7U0HUUmE7hVz7GtWdDUkNOfae/4u4CfAELipLpg6g=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=BrWI86SSdC8RToSSBbzD6TYfQIsptKaCWjHF90UErC4DPH0oz4ydzshAMt2ZOktkZ
	 k82Rfjowmjnv4IZ2Q9p3//veRaQLzuEDnXH159J92UFJHvz4jtM16vDJ+CrCSeXjPT
	 tDkKGYU0Km/JSvgjzIIS5/rFnDn0TFYZdV6M+bjl0rGqx8h65WhDoX1ntOUDbRQ6E1
	 a8KMIx52WHgd2gaMUhdgCXw/xD3TiS1rSwew+dqrZeKX53ehtQ8tQIIRGhWO0IPOWE
	 /SfdbM4hOQ9vbGExonFbq6NR/4wpkz+FxA8biMsh6A8xY6t+RPgTKV3xD/QDRf/EY9
	 aREEdzdgwDFbA==
Date: Tue, 20 May 2025 22:38:33 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/2] xen/domain: rewrite emulation_flags_ok()
Message-ID: 
In-Reply-To: 
References: <20250516022855.1146121-1-dmukhin@ford.com> <20250516022855.1146121-3-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: a0d1c2ca659a8b1d3d2a721ea0cb77cbfee0524e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 20, 2025 at 05:24:33PM +0200, Jan Beulich wrote:
> On 16.05.2025 04:29, dmkhn@proton.me wrote:
> > --- a/xen/arch/x86/include/asm/domain.h
> > +++ b/xen/arch/x86/include/asm/domain.h
> > @@ -494,6 +494,12 @@ struct arch_domain
> >                                   X86_EMU_PIT | X86_EMU_USE_PIRQ |     =
  \
> >                                   X86_EMU_VPCI)
> >
> > +/* User-selectable features. */
> > +#define X86_EMU_OPTIONAL        (X86_EMU_USE_PIRQ)
> > +
> > +#define X86_EMU_BASELINE        (X86_EMU_ALL & ~(X86_EMU_VPCI | \
> > +                                                 X86_EMU_OPTIONAL))
>=20
> That is, VPCI is neither baseline nor optional. Certainly at least strang=
e.

IMO, X86_EMU_OPTIONAL should include both VPCI and PIRQ.

But that will be a behavior change: AFAIU, VPCI is injected implicitly for =
dom0
case only, "default" xl toolstack currently excludes VPCI for HVM domains.

Do I understand it correctly that "BASELINE" in the symbol name is a concer=
n?

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Tue May 20 22:48:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 22:48:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991219.1375104 (Exim 4.92)
	(envelope-from )
	id 1uHVlM-0006NS-Pb; Tue, 20 May 2025 22:48:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991219.1375104; Tue, 20 May 2025 22: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 1uHVlM-0006NL-Mx; Tue, 20 May 2025 22:48:44 +0000
Received: by outflank-mailman (input) for mailman id 991219;
 Tue, 20 May 2025 22:48:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHVlL-0006NF-Lw
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 22:48:43 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9384d86c-35cc-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 00:48:42 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 768D95C5AF6;
 Tue, 20 May 2025 22:46:23 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59415C4CEE9;
 Tue, 20 May 2025 22:48: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" 
X-Inumbo-ID: 9384d86c-35cc-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747781320;
	bh=yscp7GbN0WQytJ0e6ihAtkd6m542+j8XvrHo/s6CQhA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=r2aEjT304gIuDYtVtnvIPBrOblMSUcQ5p3KTjU1gbX/B45r2PyZdxRIiFuIbGoinr
	 9BX7niaSw5VQ6Zt/XZfNRjZT+sOIEZzcTYYdujr/4dpqBznZmnuZfW+QUhuO7DvZ8+
	 cgzlKVP8d14j0g5HMBScfNKLDHfVnrBlvjk8SyZl0uUWLFFqagpm2uD6nPs+axejzn
	 hxaDC51IWUepoUmD/Sk3PAilGyhahG6752o2+ay/T4rg4falgg/0cAwkr9vjZl2Cpb
	 mVEC1SpNrWdoG77/T49Ru2fZmCyIpuAGiGadcHl7ry6x+USj1EVmdFlLGcON5bUJM7
	 /OXmh0LEjp/2Q==
Date: Tue, 20 May 2025 15:48:38 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Xen-devel , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Anthony PERARD , 
    Michal Orzel , Julien Grall , 
    Stefano Stabellini 
Subject: Re: [PATCH] tools: Add install/uninstall targets to
 tests/x86_emulator
In-Reply-To: <724b77b5-3b78-436e-bd20-726c34bef03b@citrix.com>
Message-ID: 
References: <20240516110710.3446-1-alejandro.vallejo@cloud.com> <724b77b5-3b78-436e-bd20-726c34bef03b@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 20 May 2025, Andrew Cooper wrote:
> On 16/05/2024 12:07 pm, Alejandro Vallejo wrote:
> > Bring test_x86_emulator in line with other tests by adding
> > install/uninstall rules.
> >
> > Signed-off-by: Alejandro Vallejo 
> > ---
> >  tools/tests/x86_emulator/Makefile | 11 +++++++++--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile
> > index 834b2112e7fe..30edf7e0185d 100644
> > --- a/tools/tests/x86_emulator/Makefile
> > +++ b/tools/tests/x86_emulator/Makefile
> > @@ -269,8 +269,15 @@ clean:
> >  .PHONY: distclean
> >  distclean: clean
> >  
> > -.PHONY: install uninstall
> > -install uninstall:
> > +.PHONY: install
> > +install: all
> > +	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
> > +	$(if $(TARGET-y),$(INSTALL_PROG) $(TARGET-y) $(DESTDIR)$(LIBEXEC_BIN))
> > +
> > +.PHONY: uninstall
> > +uninstall:
> > +	$(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/,$(TARGET-y))
> > +
> >  
> >  .PHONY: run32 clean32
> >  ifeq ($(XEN_COMPILE_ARCH),x86_64)
> 
> [starting a clean thread]
> 
> x86_emulator is not special enough to behave differently to the rest of
> tools/.
> 
> Theoretical concerns over cross compiling test_x86_emulator for non-x86
> can be fixed by whomever first wants to do this.
> 
> The very real problem is that this doesn't run in x86 CI, because and
> only because it doesn't have an install target.

This patch has been on the list of a while. I do think that having the
x86 emulator better tested as part of the CI-loop is a priority so I am
in favor of taking the patch as is -- anything to make progress in terms
of running test_x86_emulator as part of the CI-loop.

Acked-by: Stefano Stabellini 

Cheers,

Stefano


From xen-devel-bounces@lists.xenproject.org Tue May 20 23:00:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 23:00:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991227.1375114 (Exim 4.92)
	(envelope-from )
	id 1uHVwd-0000YD-Pf; Tue, 20 May 2025 23:00:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991227.1375114; Tue, 20 May 2025 23: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 1uHVwd-0000Y6-NA; Tue, 20 May 2025 23:00:23 +0000
Received: by outflank-mailman (input) for mailman id 991227;
 Tue, 20 May 2025 23:00:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHVwc-0000Y0-Ck
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 23:00:22 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 328b1fc9-35ce-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 01:00:18 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id E84FD43EAA;
 Tue, 20 May 2025 23:00:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97D70C4CEED;
 Tue, 20 May 2025 23:00: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" 
X-Inumbo-ID: 328b1fc9-35ce-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747782016;
	bh=yf4qWMc/IA2YMVmMvjSwkXQJW55ZJqmF11D4O+oxhIo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=lMFklAyCb+VeDKNcvvtf6T5R5ixorp1nQmPbb2SnAnCaFQA7dcOADT891R+Ie61JS
	 k88+sZpb/xE0+hNMmP3zQZhh7kJqUFKqgnlbB4WcnU87Ydx3AB1Pd2xkF3wu0/xrnf
	 lzAZeazat0b287mjA83QHmxdIy11NvTCgY9tc/arQ/pcV6chzshmPRL2yxlGAkgJzm
	 3IlAqgY70wh3kc+NmVfA6HB0pI7mGUAivTe8ut3o2N/YVQ6Z/L6trwI2Vb7zHCmOY5
	 FrdSp7aDZRxmqmul/4z4TyddxyyZ3ZpbPP2plOso6vJXgDlnpCfXwixiPD7/uRwUtN
	 cbuXBx+FF9LBA==
Date: Tue, 20 May 2025 16:00:14 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmkhn@proton.me
cc: Jan Beulich , andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, 
    roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/2] xen/domain: rewrite emulation_flags_ok()
In-Reply-To: 
Message-ID: 
References: <20250516022855.1146121-1-dmukhin@ford.com> <20250516022855.1146121-3-dmukhin@ford.com>  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 20 May 2025, dmkhn@proton.me wrote:
> On Tue, May 20, 2025 at 05:24:33PM +0200, Jan Beulich wrote:
> > On 16.05.2025 04:29, dmkhn@proton.me wrote:
> > > --- a/xen/arch/x86/include/asm/domain.h
> > > +++ b/xen/arch/x86/include/asm/domain.h
> > > @@ -494,6 +494,12 @@ struct arch_domain
> > >                                   X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
> > >                                   X86_EMU_VPCI)
> > >
> > > +/* User-selectable features. */
> > > +#define X86_EMU_OPTIONAL        (X86_EMU_USE_PIRQ)
> > > +
> > > +#define X86_EMU_BASELINE        (X86_EMU_ALL & ~(X86_EMU_VPCI | \
> > > +                                                 X86_EMU_OPTIONAL))
> > 
> > That is, VPCI is neither baseline nor optional. Certainly at least strange.

I think Denis tried to keep the code more similar to the original. This
way it is easier to review the code change and it seems correct. But at
the same time it is easier to spot inconsistency that were present even
before the patch.


> IMO, X86_EMU_OPTIONAL should include both VPCI and PIRQ.

It looks that way to me too.

However, then we need to be careful as the check would differ from the
original, but maybe that's OK. We want vPCI to be potentially exposed to
DomUs as well.


> But that will be a behavior change: AFAIU, VPCI is injected implicitly for dom0
> case only, "default" xl toolstack currently excludes VPCI for HVM domains.
> 
> Do I understand it correctly that "BASELINE" in the symbol name is a concern?



From xen-devel-bounces@lists.xenproject.org Tue May 20 23:32:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 23:32:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991239.1375126 (Exim 4.92)
	(envelope-from )
	id 1uHWRu-0004TY-8Q; Tue, 20 May 2025 23:32:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991239.1375126; Tue, 20 May 2025 23:32: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 1uHWRu-0004TR-4L; Tue, 20 May 2025 23:32:42 +0000
Received: by outflank-mailman (input) for mailman id 991239;
 Tue, 20 May 2025 23:32:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHWRs-0004TL-R9
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 23:32:40 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b7f3281c-35d2-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 01:32:39 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-442ccf0e1b3so75846115e9.3
 for ; Tue, 20 May 2025 16:32:39 -0700 (PDT)
Received: from localhost.localdomain ([91.85.47.110])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f6b297easm50341795e9.6.2025.05.20.16.32.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 16:32:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b7f3281c-35d2-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747783958; x=1748388758; 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;
        bh=I8V1hl11gRxp9GaliI0XC+7jI+TfFKoJTghQ0PP0k5o=;
        b=blFgHdCcwnVg/AMZI3KpTm5eD5DCudocNl+8Y2cfrrP6OCvYjnfeqVvKDYIyCmZelx
         imzDV70mUVBDaPSEIK3tJNTNiwmeEV5/QijloizJXSgiHde7BnumeuAbtEDmbAAnXb/9
         H+T72pzNCWlSluv+rPnJzpgGUlzvXUIsJZL6rJIdK2AET+KDPWPY55VG+OvPvxiCu7eZ
         Ag7JKNHx2Jb3SiGN0K8BlJ1p7xUl9kbkjwkkIIq1ROAv+CCmQgM2ZYHORa8soIOWhz1C
         L3O95gjBrU5HCHHEXjxnc5fnvqzqiVxbYQW0f+smJrjXLTP8WejecEXGZNth8nu/OBkb
         RvYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747783958; x=1748388758;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=I8V1hl11gRxp9GaliI0XC+7jI+TfFKoJTghQ0PP0k5o=;
        b=pnx4F1GGosO2pQgG2bjtdGBfKXgSjiexZ7Y73/AG3TzaTdQVLYlHN61qX2tVlZZZk9
         MfT7av5sJR8olb03orPEZ+n1OrfEzZ+3DRHxbUcjs25+IU1DTNgfWcqF+ezVksXKgoRF
         ZgsT6yjp+8oaGyRJVwRkVJuaDM7pHgIwuLL/h2dhywVLAoyIOq/qv2yZ22i7jgmD2kxr
         rVnsfgCmiC+J3BfcaRi30mu+dYvYgzK3VeRmG97gfYMTi/dEZtIqAqCMsvsfizxhXqAO
         5J5HigGf5pNGlOrzwwDy9yk8Mra6I+7Q0nehAUe5oFcm6B6q0WYFDv/n/JRYF/hyIj9w
         8W5A==
X-Gm-Message-State: AOJu0Yzkv34hYbKiXKYIR2+r5Qo8AV2ZQ4s6SbkakseAt2Yrl8IXOcJ1
	WWW1V5wBjZkbsvnRf7uWdncxG7NYM+amZrvZXpYrlffutGPdJvv95nj1AYEwzg==
X-Gm-Gg: ASbGncv+sWH2o2bgzI3qFzFlmMPUEjL7kNNUPZt985uP5/DzXUW/4cU8f5ZYfvElzX3
	APONZa3UfY1Sjl1ms+uPSMRggq2nPRjTg8njHGSf/9I3WJH+vuWzAVr2RZpOqp4XPCZ2cBJNN3O
	q6FzVk8bkPsyqd34DupoBUaww9NkWLbZkUOvzVjPED4KKfhk1LOlmOzd5yfUFzkPGY1k88RgZtF
	tmd6gzi6BLZUo406g2HhYQCGS5uxqxOS9g1sIbHrst5s0JNLRNGkftpfbKsWSOM/N2xnqyi+L1C
	L9CmUueW9H6l5yzQf+EUqDiUWm270jfHLiQiDSLlZfaf3iehVGr3vqI9hz8Rppzhw5/a69ktT8U
	=
X-Google-Smtp-Source: AGHT+IHxFziV1JdmTPj33vQndpna0YnSHJI7adhPiuJPEVysxFsM8IEqWA40pZhj7DrjHxlMS9IXVA==
X-Received: by 2002:a05:600c:4686:b0:442:f4a3:9338 with SMTP id 5b1f17b1804b1-442fd664a41mr150737175e9.21.1747783957932;
        Tue, 20 May 2025 16:32:37 -0700 (PDT)
From: Christopher Clark 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Daniel Smith ,
	Rich Persaud ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 1/2] MAINTAINERS: include Argo documentation in the ARGO section
Date: Wed, 21 May 2025 00:32:19 +0100
Message-Id: <20250520233220.868258-1-christopher.w.clark@gmail.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Christopher Clark 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c11b82eca9..e7198363c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -226,6 +226,7 @@ S:	Maintained
 F:	xen/include/public/argo.h
 F:	xen/include/xen/argo.h
 F:	xen/common/argo.c
+F:	docs/designs/argo.pandoc
 
 ARINC653 SCHEDULER
 M:	Nathan Studer 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue May 20 23:32:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 23:32:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991240.1375134 (Exim 4.92)
	(envelope-from )
	id 1uHWRw-0004hW-IF; Tue, 20 May 2025 23:32:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991240.1375134; Tue, 20 May 2025 23:32: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 1uHWRw-0004hP-Fl; Tue, 20 May 2025 23:32:44 +0000
Received: by outflank-mailman (input) for mailman id 991240;
 Tue, 20 May 2025 23:32:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHWRv-0004fT-8p
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 23:32:43 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b917dc22-35d2-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 01:32:41 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-442f5b3c710so49783495e9.1
 for ; Tue, 20 May 2025 16:32:41 -0700 (PDT)
Received: from localhost.localdomain ([91.85.47.110])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f6b297easm50341795e9.6.2025.05.20.16.32.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 20 May 2025 16: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" 
X-Inumbo-ID: b917dc22-35d2-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747783960; x=1748388760; 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;
        bh=aknpjrvPsir/Vt/v4dJDAQUN8C3kR9VROKP2hMJVwTo=;
        b=kl3xmiDoY2qeSjPgXzfieWGy+YWcWVif8kKRKeF+5PQ2ckW6GbGVbqV5wguRNBpu6L
         yf4Tb5DSv+bLcBI6H3MgJUF2p/7u1xy/xAaYEDKHJvEVrUZyvWHxOwjWPVaAF7sn5mJh
         lZgwnAanQkjJZtvcaedDoiv+InYmSnFy/HQWOJT0l6PcGz7odfpBBnVVDEzf1YARhX6l
         gFHfe+Gl+w0eMlVZaXJ5h1wadEGiMwHsupN8Rv59Oyy+IXy/dIvRqdDLhx8ib0NckKu1
         /YYkXmga9cHCV7HkWOt440kHrXHZGC5/Cz61W3/wKNJWMbAkWRhMWLTHu5Yx5Rh53cUm
         BNYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747783960; x=1748388760;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=aknpjrvPsir/Vt/v4dJDAQUN8C3kR9VROKP2hMJVwTo=;
        b=GXfjs2N87KQPDlD5dOxQS2uoWFGeTw+7EWik53aN/GfzpwXEhouPfq3jqLGlFt1e+c
         uwVekPspX8Hrer7gM7d2oncZiIIPOdBAFeLdmIrJv0bDA54CBIUPE0CqVlA2iBJzKWm7
         TxwQKRAroV8vzKz2TABCYYFHUcB5n+uh1/vwisDLDb2KJ5dIYCjvF6z+44tcE4eredBZ
         BRjKC4VeAOMDWsuWGQOHhbMdShIFz3lj2iNnoSaBDsD/atBCoec1reTG1lKHtfMlEwFB
         sqrjyO0WC71AAVYMgcf8eWoYJsl9BC0BX1ZYOFFqZlq5/igh8aR5QhJ9htfpF5CJ0Jf/
         1AzQ==
X-Gm-Message-State: AOJu0YyZm8uH9k0SZwiRQONyGb66f7RIAeD+lQMYDNqj9RLSiCRb3/mv
	ETEAh0kUq2gegF76I8lGu6kZuwS2nH6DIz0y3FcZCLd8yF4AKXpQkuv1lfN/AA==
X-Gm-Gg: ASbGncvg2ZwQsCqEIBW7HGS2bipf0f0tIb92tuvnt50xpnsYzMZexDFMFvlWWmzTZhW
	FKRjMzodPpV9B6/wYGYriboltnzM4CB2zBxVeFpFSJzdnNH0Zq7KsWa0dLg1xiht27yr5fMqHgk
	WDwDMXqu4bKc8TDv/6c0e9TyusRpSvR6U7jfWRta4UNrP5AlbXqCrXD8fRPAYNZ3bkGH3kJ0sgL
	LAULnkzDTcolS7ps2MZVUv2SSlSH9y27UU6yDZytI6nA/ucTYypN8MD7A8f85r58mgH4XKdfipW
	HAwO5sVgK4F2rFIiesOLncsOb27I+v61AZQos592wmWk/Db8KBAL1bZa14mDXxghcxWtfyiy63T
	tQ/JzEVrcrA==
X-Google-Smtp-Source: AGHT+IEMQ4NwdqfF9MurWZhs1a8hiz5P6QQdKVqbcyYKA345zM1sIB/fETk6TVfj13tL21HE6kEKZg==
X-Received: by 2002:a05:600c:4592:b0:43d:45a:8fbb with SMTP id 5b1f17b1804b1-442fd6649d0mr139970645e9.22.1747783959758;
        Tue, 20 May 2025 16:32:39 -0700 (PDT)
From: Christopher Clark 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Daniel Smith ,
	Rich Persaud ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 2/2] MAINTAINERS: add Daniel P. Smith as an Argo maintainer
Date: Wed, 21 May 2025 00:32:20 +0100
Message-Id: <20250520233220.868258-2-christopher.w.clark@gmail.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20250520233220.868258-1-christopher.w.clark@gmail.com>
References: <20250520233220.868258-1-christopher.w.clark@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Daniel is a longstanding contributor to the OpenXT Project where Argo
was developed and is in active use with Xen, and to Argo itself,
involved with the design and development of Argo software.

Signed-off-by: Christopher Clark 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e7198363c5..c2e4f8528f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -222,6 +222,7 @@ F:	tools/libacpi/
 
 ARGO
 M:	Christopher Clark 
+M:	Daniel P. Smith 
 S:	Maintained
 F:	xen/include/public/argo.h
 F:	xen/include/xen/argo.h
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue May 20 23:42:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 23:42:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991258.1375144 (Exim 4.92)
	(envelope-from )
	id 1uHWan-0006li-Ce; Tue, 20 May 2025 23:41:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991258.1375144; Tue, 20 May 2025 23:41: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 1uHWan-0006lb-9a; Tue, 20 May 2025 23:41:53 +0000
Received: by outflank-mailman (input) for mailman id 991258;
 Tue, 20 May 2025 23:41:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHWam-0006lV-6p
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 23:41:52 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ff68b8d8-35d3-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 01:41:49 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id DDDA85C12F1;
 Tue, 20 May 2025 23:39:30 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57320C4CEE9;
 Tue, 20 May 2025 23:41: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" 
X-Inumbo-ID: ff68b8d8-35d3-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747784507;
	bh=MX579Tdf97/V1Pojs7eQnGpeixxWF24nAwDy2zd5RZQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=TX6VcSlL1n/u3CcCppaM+vSd2Rr5niJ7jMXMu0Qhn+a69uCkjoSufseWwQdfmQkVu
	 Xmr7ZS3/ZAN9bFSSYD4sDQSfi2VL1jaIP/J645eZfFVoIyNgWTR52M3i6F52z+511Y
	 XLrpQjcy80ZcllTCMfkgYkwYHlxkMIpugzIHFPGUNt4HGmh8WEogzSY/ynHRNA0Xp5
	 FCqa1nwyL2hcrHc5Bt8fPem1mWsu6+y9NAOja7zbVLU+zPbi2ybnO6jQvWMqail7VB
	 pf7D/+QyONzqG4jD5a0BtPYkD+/wyJ7nErb++9RUC/+weMOJbAxOAtQX3t+Y1nGmzC
	 dG/gziooj5FkA==
Date: Tue, 20 May 2025 16:41:44 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Christopher Clark 
cc: xen-devel@lists.xenproject.org, Andrew Cooper , 
    Daniel Smith , 
    Rich Persaud , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini 
Subject: Re: [PATCH 1/2] MAINTAINERS: include Argo documentation in the ARGO
 section
In-Reply-To: <20250520233220.868258-1-christopher.w.clark@gmail.com>
Message-ID: 
References: <20250520233220.868258-1-christopher.w.clark@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 21 May 2025, Christopher Clark wrote:
> Signed-off-by: Christopher Clark 

Acked-by: Stefano Stabellini 


> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c11b82eca9..e7198363c5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -226,6 +226,7 @@ S:	Maintained
>  F:	xen/include/public/argo.h
>  F:	xen/include/xen/argo.h
>  F:	xen/common/argo.c
> +F:	docs/designs/argo.pandoc
>  
>  ARINC653 SCHEDULER
>  M:	Nathan Studer 
> -- 
> 2.25.1
> 


From xen-devel-bounces@lists.xenproject.org Tue May 20 23:42:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 20 May 2025 23:42:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991260.1375155 (Exim 4.92)
	(envelope-from )
	id 1uHWb1-00073D-K8; Tue, 20 May 2025 23:42:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991260.1375155; Tue, 20 May 2025 23:42: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 1uHWb1-000736-H4; Tue, 20 May 2025 23:42:07 +0000
Received: by outflank-mailman (input) for mailman id 991260;
 Tue, 20 May 2025 23:42:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHWb0-00072U-4u
 for xen-devel@lists.xenproject.org; Tue, 20 May 2025 23:42:06 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 083bba49-35d4-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 01:42:04 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 058A544B12;
 Tue, 20 May 2025 23:42:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9151CC4CEE9;
 Tue, 20 May 2025 23:42: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" 
X-Inumbo-ID: 083bba49-35d4-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747784522;
	bh=j3p5Z582EmuyC1zpsCaf2z0y4GicOnqytv3OkjvCfsc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=PL9GT0Ieqka9+meYoZ103H2rubUr+tqix706VtU4kZHQP7R6w568jZ92Rs0e2RfNr
	 pmfPre1EpgrwA9SdDXpqtNDb8ovFxDgY5gcBhveueavzMWR2Qo8C6TLVlvYXoME1WF
	 pN2w+4JLLMz1tT/SkEJVGfIlGjGmP9BOZKbtYpfPrcJEeSj/RoBQ5oe0/S4zVYmMTl
	 fpDueog1q7vE19DrwvyrZCOwxBLeeZs39mZ05dCsIWcR1ZtKaSouYsNdxOeAf/OGj7
	 8HXj8TSAxx5piVgMNrljlWGdfMHmHDVtrW0gpt108KFaON+n37BnR3x2YnrDEQ1pH7
	 SQ4junNXW9p2g==
Date: Tue, 20 May 2025 16:41:59 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Christopher Clark 
cc: xen-devel@lists.xenproject.org, Andrew Cooper , 
    Daniel Smith , 
    Rich Persaud , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini 
Subject: Re: [PATCH 2/2] MAINTAINERS: add Daniel P. Smith as an Argo
 maintainer
In-Reply-To: <20250520233220.868258-2-christopher.w.clark@gmail.com>
Message-ID: 
References: <20250520233220.868258-1-christopher.w.clark@gmail.com> <20250520233220.868258-2-christopher.w.clark@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 21 May 2025, Christopher Clark wrote:
> Daniel is a longstanding contributor to the OpenXT Project where Argo
> was developed and is in active use with Xen, and to Argo itself,
> involved with the design and development of Argo software.
> 
> Signed-off-by: Christopher Clark 

Acked-by: Stefano Stabellini 


> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e7198363c5..c2e4f8528f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -222,6 +222,7 @@ F:	tools/libacpi/
>  
>  ARGO
>  M:	Christopher Clark 
> +M:	Daniel P. Smith 
>  S:	Maintained
>  F:	xen/include/public/argo.h
>  F:	xen/include/xen/argo.h
> -- 
> 2.25.1
> 


From xen-devel-bounces@lists.xenproject.org Wed May 21 00:00:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 00:00:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991281.1375175 (Exim 4.92)
	(envelope-from )
	id 1uHWt2-0002Ve-Ex; Wed, 21 May 2025 00:00:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991281.1375175; Wed, 21 May 2025 00: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 1uHWt2-0002VX-Br; Wed, 21 May 2025 00:00:44 +0000
Received: by outflank-mailman (input) for mailman id 991281;
 Wed, 21 May 2025 00:00:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHWt1-0002HS-Bp
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 00:00:43 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a2e697ab-35d6-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 02:00: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" 
X-Inumbo-ID: a2e697ab-35d6-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747785641; x=1748044841;
	bh=pvUKgvpXykk6QPUGl6S7aKbOTQ27IdteI+qrKZUIs0A=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=An2iLpdqI15UhAcI0GkxEVPTUsxOoayhPebJIgCaUJqgNGxNUfBN6/rpcWmyKUpuL
	 eHwLLblh4XZ4jXBNavjYH6rneTV4gVsCKmAUZq7JaAealPHfHL/tCA7rPvPjG90XDS
	 LhypG4sCiZhnxa039wX+MphJmBAP/3a8YelI2fqbY/sO9uqbMrcdq9qXxHo1+tidAm
	 UK0AmML5Vj6uNmQxUnMJ4LrcBMjYyfVL0wM71qAFhICdaJGn4UhmkXJcL833V8CORy
	 ISgwaAxsVSA0HhmIBj+O6jbl0BQzapFt19ntZiPbpA7mELbODqdU3JKVy4mMNUh0iR
	 1Gb/R717yzfZQ==
Date: Wed, 21 May 2025 00:00:38 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v8 1/3] xen/domain: unify domain ID allocation
Message-ID: <20250521000024.2944685-2-dmukhin@ford.com>
In-Reply-To: <20250521000024.2944685-1-dmukhin@ford.com>
References: <20250521000024.2944685-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: f7978f4ed4e2dd4147763957d2eb90fa79770726
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Currently, hypervisor code has two different non-system domain ID allocatio=
n
implementations:

  (a) Sequential IDs allocation in dom0less Arm code based on max_init_domi=
d;

  (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
      max_init_domid (both Arm and x86).

It makes sense to have a common helper code for such task across architectu=
res
(Arm and x86) and between dom0less / toolstack domU allocation.

Wrap the domain ID allocation as an arch-independent function domid_alloc()=
 in
common/domain.c based on the bitmap.

Allocation algorithm:
- If an explicit domain ID is provided, verify its availability and use it =
if
  ID is not used;
- If DOMID_INVALID is provided, search the range [0..DOMID_FIRST_RESERVED-1=
],
  starting from the last used ID and wrapping around as needed. It guarante=
es
  that two consecutive calls will never return the same ID.

Also, remove is_free_domid() helper as it is not needed now.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v7:
- Use DOMID_FIRST_RESERVED
---
 xen/arch/arm/domain_build.c             | 17 ++++++---
 xen/arch/x86/setup.c                    | 11 +++---
 xen/common/device-tree/dom0less-build.c | 10 +++---
 xen/common/domain.c                     | 47 +++++++++++++++++++++++++
 xen/common/domctl.c                     | 42 +++-------------------
 xen/include/xen/domain.h                |  3 ++
 6 files changed, 80 insertions(+), 50 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..e9d563c269 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2010,6 +2010,7 @@ void __init create_dom0(void)
         .grant_opts =3D XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
     };
     unsigned int flags =3D CDF_privileged | CDF_hardware;
+    domid_t domid;
     int rc;
=20
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
@@ -2034,19 +2035,25 @@ void __init create_dom0(void)
     if ( !llc_coloring_enabled )
         flags |=3D CDF_directmap;
=20
-    dom0 =3D domain_create(0, &dom0_cfg, flags);
+    domid =3D domid_alloc(0);
+    if ( domid =3D=3D DOMID_INVALID )
+        panic("Error allocating domain ID 0\n");
+
+    dom0 =3D domain_create(domid, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
-        panic("Error creating domain 0 (rc =3D %ld)\n", PTR_ERR(dom0));
+        panic("Error creating domain %d (rc =3D %ld)\n", domid, PTR_ERR(do=
m0));
=20
     if ( llc_coloring_enabled && (rc =3D dom0_set_llc_colors(dom0)) )
-        panic("Error initializing LLC coloring for domain 0 (rc =3D %d)\n"=
, rc);
+        panic("Error initializing LLC coloring for domain %pd (rc =3D %d)\=
n",
+              dom0, rc);
=20
     if ( alloc_dom0_vcpu0(dom0) =3D=3D NULL )
-        panic("Error creating domain 0 vcpu0\n");
+        panic("Error creating domain %pdv0\n", dom0);
=20
     rc =3D construct_dom0(dom0);
     if ( rc )
-        panic("Could not set up DOM0 guest OS (rc =3D %d)\n", rc);
+        panic("Could not set up guest OS for domain %pd (rc =3D %d)\n",
+              dom0, rc);
=20
     set_xs_domain(dom0);
 }
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2518954124..ac1c3e669b 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1030,8 +1030,11 @@ static struct domain *__init create_dom0(struct boot=
_info *bi)
     if ( iommu_enabled )
         dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu;
=20
-    /* Create initial domain.  Not d0 for pvshim. */
-    bd->domid =3D get_initial_domain_id();
+    /* Allocate initial domain ID. Not d0 for pvshim. */
+    bd->domid =3D domid_alloc(get_initial_domain_id());
+    if ( bd->domid =3D=3D DOMID_INVALID )
+        panic("Error allocating domain ID %d\n", get_initial_domain_id());
+
     d =3D domain_create(bd->domid, &dom0_cfg,
                       pv_shim ? 0 : CDF_privileged | CDF_hardware);
     if ( IS_ERR(d) )
@@ -1063,7 +1066,7 @@ static struct domain *__init create_dom0(struct boot_=
info *bi)
=20
         if ( (strlen(acpi_param) =3D=3D 0) && acpi_disabled )
         {
-            printk("ACPI is disabled, notifying Domain 0 (acpi=3Doff)\n");
+            printk("ACPI is disabled, notifying domain %pd (acpi=3Doff)\n"=
, d);
             safe_strcpy(acpi_param, "off");
         }
=20
@@ -1078,7 +1081,7 @@ static struct domain *__init create_dom0(struct boot_=
info *bi)
=20
     bd->d =3D d;
     if ( construct_dom0(bd) !=3D 0 )
-        panic("Could not construct domain 0\n");
+        panic("Could not construct domain %pd\n", d);
=20
     bd->cmdline =3D NULL;
     xfree(cmdline);
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index 2c56f13771..9236dbae11 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -850,15 +850,13 @@ void __init create_domUs(void)
         struct xen_domctl_createdomain d_cfg =3D {0};
         unsigned int flags =3D 0U;
         bool has_dtb =3D false;
+        domid_t domid;
         uint32_t val;
         int rc;
=20
         if ( !dt_device_is_compatible(node, "xen,domain") )
             continue;
=20
-        if ( (max_init_domid + 1) >=3D DOMID_FIRST_RESERVED )
-            panic("No more domain IDs available\n");
-
         d_cfg.max_evtchn_port =3D 1023;
         d_cfg.max_grant_frames =3D -1;
         d_cfg.max_maptrack_frames =3D -1;
@@ -981,7 +979,11 @@ void __init create_domUs(void)
          * very important to use the pre-increment operator to call
          * domain_create() with a domid > 0. (domid =3D=3D 0 is reserved f=
or Dom0)
          */
-        d =3D domain_create(++max_init_domid, &d_cfg, flags);
+        domid =3D domid_alloc(++max_init_domid);
+        if ( domid =3D=3D DOMID_INVALID )
+            panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
+
+        d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
             panic("Error creating domain %s (rc =3D %ld)\n",
                   dt_node_name(node), PTR_ERR(d));
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..9c6932c457 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -66,6 +66,11 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
 static struct domain *domain_hash[DOMAIN_HASH_SIZE];
 struct domain *domain_list;
=20
+/* Non-system domain ID allocator. */
+static DEFINE_SPINLOCK(domid_lock);
+static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
+static domid_t domid_last;
+
 /*
  * Insert a domain into the domlist/hash.  This allows the domain to be lo=
oked
  * up by domid, and therefore to be the subject of hypercalls/etc.
@@ -1449,6 +1454,8 @@ void domain_destroy(struct domain *d)
=20
     TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id);
=20
+    domid_free(d->domain_id);
+
     /* Remove from the domlist/hash. */
     domlist_remove(d);
=20
@@ -2405,6 +2412,46 @@ domid_t get_initial_domain_id(void)
     return hardware_domid;
 }
=20
+domid_t domid_alloc(domid_t domid)
+{
+    spin_lock(&domid_lock);
+
+    if ( domid < DOMID_FIRST_RESERVED )
+    {
+        if ( __test_and_set_bit(domid, domid_bitmap) )
+            domid =3D DOMID_INVALID;
+    }
+    else
+    {
+        domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED,
+                                   domid_last);
+
+        if ( domid =3D=3D DOMID_FIRST_RESERVED )
+            domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVE=
D, 0);
+
+        if ( domid =3D=3D DOMID_FIRST_RESERVED )
+        {
+            domid =3D DOMID_INVALID;
+        }
+        else
+        {
+            __set_bit(domid, domid_bitmap);
+            domid_last =3D domid;
+        }
+    }
+
+    spin_unlock(&domid_lock);
+
+    return domid;
+}
+
+void domid_free(domid_t domid)
+{
+    spin_lock(&domid_lock);
+    __clear_bit(domid, domid_bitmap);
+    spin_unlock(&domid_lock);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index bfe2e1f9f0..8ef0c147c9 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -49,20 +49,6 @@ static int xenctl_bitmap_to_nodemask(nodemask_t *nodemas=
k,
                                    MAX_NUMNODES);
 }
=20
-static inline int is_free_domid(domid_t dom)
-{
-    struct domain *d;
-
-    if ( dom >=3D DOMID_FIRST_RESERVED )
-        return 0;
-
-    if ( (d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL )
-        return 1;
-
-    rcu_unlock_domain(d);
-    return 0;
-}
-
 void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info=
)
 {
     struct vcpu *v;
@@ -421,36 +407,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u=
_domctl)
=20
     case XEN_DOMCTL_createdomain:
     {
-        domid_t        dom;
-        static domid_t rover =3D 0;
+        domid_t domid =3D domid_alloc(op->domain);
=20
-        dom =3D op->domain;
-        if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) )
+        if ( domid =3D=3D DOMID_INVALID )
         {
             ret =3D -EEXIST;
-            if ( !is_free_domid(dom) )
-                break;
-        }
-        else
-        {
-            for ( dom =3D rover + 1; dom !=3D rover; dom++ )
-            {
-                if ( dom =3D=3D DOMID_FIRST_RESERVED )
-                    dom =3D 1;
-                if ( is_free_domid(dom) )
-                    break;
-            }
-
-            ret =3D -ENOMEM;
-            if ( dom =3D=3D rover )
-                break;
-
-            rover =3D dom;
+            break;
         }
=20
-        d =3D domain_create(dom, &op->u.createdomain, false);
+        d =3D domain_create(domid, &op->u.createdomain, false);
         if ( IS_ERR(d) )
         {
+            domid_free(domid);
             ret =3D PTR_ERR(d);
             d =3D NULL;
             break;
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index e10baf2615..8aab05ae93 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -38,6 +38,9 @@ void arch_get_domain_info(const struct domain *d,
=20
 domid_t get_initial_domain_id(void);
=20
+domid_t domid_alloc(domid_t domid);
+void domid_free(domid_t domid);
+
 /* CDF_* constant. Internal flags for domain creation. */
 /* Is this a privileged domain? */
 #define CDF_privileged           (1U << 0)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 21 00:00:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 00:00:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991280.1375164 (Exim 4.92)
	(envelope-from )
	id 1uHWt1-0002I5-8f; Wed, 21 May 2025 00:00:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991280.1375164; Wed, 21 May 2025 00: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 1uHWt1-0002Hy-5S; Wed, 21 May 2025 00:00:43 +0000
Received: by outflank-mailman (input) for mailman id 991280;
 Wed, 21 May 2025 00:00:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHWsy-0002HS-Ih
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 00:00:41 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a0bccc88-35d6-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 02:00: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" 
X-Inumbo-ID: a0bccc88-35d6-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747785637; x=1748044837;
	bh=fP2rWwuRSfClj4KIh4h1Db7VpIHHhE4ET5iPu9j3HIc=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=nRJAcp5WZQ2VsM6CWXNhCuurbogMOLBrB/SZaN9OxrypqjmSha9AKaMCptmg0mx3/
	 u/BOrvZ8bZDh59MIusWArcSO0nxx8FXPNObathN1PMwQ2CP5JwgR1YBopdzjkvR2d2
	 m2ZuyhfCsGClSFq+Dr38/hA4Z2I2UQmCCYpHtPdKPKdwgY0/K2bYHdSarq7fI/CPMb
	 8qRdiCxeXbJhXUTMOa7es5Qq+fuhlhm+byLML0q2uK2PEGJvoTSx0wHyQiFip9x5nB
	 hF1TZXRkjF0eJYC5RB1HozON5u4FPeedR+W6MHEbwcGr8ljtf9ubkuiWjqWueeQT+o
	 Yzr/mYBXnijjw==
Date: Wed, 21 May 2025 00:00:31 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v8 0/3] xen/domain: domain ID allocation
Message-ID: <20250521000024.2944685-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 7678a11abcf520c70427049dc4e1253516dd9069
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The patch series adds new library calls for allocating domain IDs.

Patch 1 introduces new domid_{alloc,free} calls.
Patch 2 adjusts hardware domain ID treatment on Arm.
Patch 3 is an RFC: introduces new CONFIG_MAX_DOMID parameter to limit the
number of user domains during run-time.

Link to v7: https://lore.kernel.org/xen-devel/20250519192306.1364471-1-dmuk=
hin@ford.com/=20
Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1=
828093998=20

Denis Mukhin (3):
  xen/domain: unify domain ID allocation
  xen/domain: adjust domain ID allocation for Arm
  xen/domain: introduce CONFIG_MAX_DOMID

 xen/arch/arm/domain_build.c             | 17 +++++--
 xen/arch/arm/tee/ffa.c                  |  3 +-
 xen/arch/x86/cpu/mcheck/mce.c           |  2 +-
 xen/arch/x86/cpu/vpmu.c                 |  2 +-
 xen/arch/x86/setup.c                    | 11 +++--
 xen/common/Kconfig                      |  7 +++
 xen/common/device-tree/dom0less-build.c | 17 ++++---
 xen/common/domain.c                     | 62 +++++++++++++++++++++++--
 xen/common/domctl.c                     | 42 ++---------------
 xen/common/sched/core.c                 |  4 +-
 xen/drivers/passthrough/vtd/iommu.c     |  2 +-
 xen/include/public/domctl.h             |  2 +-
 xen/include/xen/domain.h                |  3 ++
 13 files changed, 108 insertions(+), 66 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 21 00:00:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 00:00:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991282.1375184 (Exim 4.92)
	(envelope-from )
	id 1uHWt9-0002rH-NZ; Wed, 21 May 2025 00:00:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991282.1375184; Wed, 21 May 2025 00:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHWt9-0002r8-Ju; Wed, 21 May 2025 00:00:51 +0000
Received: by outflank-mailman (input) for mailman id 991282;
 Wed, 21 May 2025 00:00:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHWt8-0002HS-QK
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 00:00:50 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a7819557-35d6-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 02:00: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" 
X-Inumbo-ID: a7819557-35d6-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747785649; x=1748044849;
	bh=gZuziIYnGqs/5mkfDoO7rMHMyTdKJ31HoXIZkb3ogxY=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=SgfyCp/aOipnEISvQfwIG7qCTfnIQVUPThwCW8JbXmXMjTQTQFW9Pk89lMs8Uiktv
	 O6U+Ng/lsODW24bqQf33QTJiX8ICubq7Vc1Z9qelK7JZiWurRvj2jdxMoIuUClZv9V
	 s+PQ6yK+nq9htiYlseyTLVJcNECUGyl7rZefM5n2NFX5AkZfWjj9M0BCJfADcXprXb
	 tGH8GIAA1S/4EMQdEk4G5QMj5kGRl7MEDepUVdOJRi9iOxhFS5VMLZP9JR4kWdxdUn
	 mfEDs7J/0nx64ZUFWiV4VfdVIIUhSD0KPuepdNR1SXDHbWp/zcvLbUFwF7F3tfI4n5
	 w+N9N++quiBzA==
Date: Wed, 21 May 2025 00:00:44 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v8 2/3] xen/domain: adjust domain ID allocation for Arm
Message-ID: <20250521000024.2944685-3-dmukhin@ford.com>
In-Reply-To: <20250521000024.2944685-1-dmukhin@ford.com>
References: <20250521000024.2944685-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 907ae400060ee37746716b45fa33c0fbb991a03f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Remove the hardcoded domain ID 0 allocation for hardware domain and replace=
 it
with a call to get_initial_domain_id() (returns the value of hardware_domid=
 on
Arm).

Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_domain_id=
()
ID is skipped during domain ID allocation to cover domU case in dom0less
configuration. That also fixes a potential issue with re-using ID#0 for dom=
Us
when get_initial_domain_id() returns non-zero.

Signed-off-by: Denis Mukhin 
---
Changes since v7:
- use `bool reserved;` in domid_alloc()
---
 xen/arch/arm/domain_build.c             | 4 ++--
 xen/common/device-tree/dom0less-build.c | 9 +++------
 xen/common/domain.c                     | 6 ++++++
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e9d563c269..0ad80b020a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2035,9 +2035,9 @@ void __init create_dom0(void)
     if ( !llc_coloring_enabled )
         flags |=3D CDF_directmap;
=20
-    domid =3D domid_alloc(0);
+    domid =3D domid_alloc(get_initial_domain_id());
     if ( domid =3D=3D DOMID_INVALID )
-        panic("Error allocating domain ID 0\n");
+        panic("Error allocating domain ID %d\n", get_initial_domain_id());
=20
     dom0 =3D domain_create(domid, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index 9236dbae11..8e38affd0c 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -974,14 +974,11 @@ void __init create_domUs(void)
=20
         arch_create_domUs(node, &d_cfg, flags);
=20
-        /*
-         * The variable max_init_domid is initialized with zero, so here i=
t's
-         * very important to use the pre-increment operator to call
-         * domain_create() with a domid > 0. (domid =3D=3D 0 is reserved f=
or Dom0)
-         */
-        domid =3D domid_alloc(++max_init_domid);
+        domid =3D domid_alloc(DOMID_INVALID);
         if ( domid =3D=3D DOMID_INVALID )
             panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
+        if ( max_init_domid < domid )
+            max_init_domid =3D domid;
=20
         d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 9c6932c457..01a65cb35d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2423,6 +2423,9 @@ domid_t domid_alloc(domid_t domid)
     }
     else
     {
+        bool reserved =3D __test_and_set_bit(get_initial_domain_id(),
+                                           domid_bitmap);
+
         domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED,
                                    domid_last);
=20
@@ -2438,6 +2441,9 @@ domid_t domid_alloc(domid_t domid)
             __set_bit(domid, domid_bitmap);
             domid_last =3D domid;
         }
+
+        if ( !reserved )
+            __clear_bit(reserved, domid_bitmap);
     }
=20
     spin_unlock(&domid_lock);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 21 00:01:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 00:01:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991287.1375195 (Exim 4.92)
	(envelope-from )
	id 1uHWtK-0003RI-2w; Wed, 21 May 2025 00:01:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991287.1375195; Wed, 21 May 2025 00:01: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 1uHWtK-0003RB-06; Wed, 21 May 2025 00:01:02 +0000
Received: by outflank-mailman (input) for mailman id 991287;
 Wed, 21 May 2025 00:01:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHWtI-0003ED-MZ
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 00:01:00 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id acc4adee-35d6-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 02:00: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" 
X-Inumbo-ID: acc4adee-35d6-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747785658; x=1748044858;
	bh=dyWE4g9RjoCjxwzz+tbMoGFTSyVkuUaSnQCT8L45dwk=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=TbSqvMPGyLUnSry1J+SA51tgHl9mOQP1t0Z66lTI0S24Aq08/Ua1vmdjgH2RDku7E
	 sl8IGfAc3N5H79SR4ElyeXcO8O17UnC5cPV7tUlNyh+16f6UaiTGbuTzIkJe1iGiRo
	 jwbxC0HR/jEB+Q1e3DqcfER4N7t0gVFtPXwq72yk0T0VMS/5PVJ0FBneAYeanUo3Pn
	 8iq4J0T3uyvrGZFPwKjpFkNgd6EhB223+U1kNBrSXw7YjNiA5YH2AxDnldgZ5Mk/3V
	 HafsksnYXhKXE/sUiIl9CziZ9CxFYb5/wnNJsJAzwCsSSmRxvpJmMrPCC1fDGnJTFJ
	 3I+BmkfnGzPKg==
Date: Wed, 21 May 2025 00:00:52 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v8 3/3] xen/domain: introduce CONFIG_MAX_DOMID
Message-ID: <20250521000024.2944685-4-dmukhin@ford.com>
In-Reply-To: <20250521000024.2944685-1-dmukhin@ford.com>
References: <20250521000024.2944685-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 4bd2800df5799a7a1e01ada611e97a9ce4808730
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Embedded deployments of Xen do not need to have support for more than dozen=
 of
domains.

Introduce build-time configuration option to limit the number of domains du=
ring
run-time.

Also, move DOMID_FIRST_RESERVED compile-time check from Arm to common code.

Suggested-by: Julien Grall 
Signed-off-by: Denis Mukhin 
---
This is an RFC.

Changes since v7:
- moved DOMID_FIRST_RESERVED compile-time checks to common code
- changed description for MAX_DOMID Kconfig option
---
 xen/arch/arm/tee/ffa.c              |  3 +--
 xen/arch/x86/cpu/mcheck/mce.c       |  2 +-
 xen/arch/x86/cpu/vpmu.c             |  2 +-
 xen/common/Kconfig                  |  7 +++++++
 xen/common/domain.c                 | 21 ++++++++++++---------
 xen/common/sched/core.c             |  4 ++--
 xen/drivers/passthrough/vtd/iommu.c |  2 +-
 xen/include/public/domctl.h         |  2 +-
 8 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 3bbdd7168a..7417ce6bed 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -331,10 +331,9 @@ static int ffa_domain_init(struct domain *d)
      * reserved for the hypervisor and we only support secure endpoints us=
ing
      * FF-A IDs with BIT 15 set to 1 so make sure those are not used by Xe=
n.
      */
-    BUILD_BUG_ON(DOMID_FIRST_RESERVED >=3D UINT16_MAX);
     BUILD_BUG_ON((DOMID_MASK & BIT(15, U)) !=3D 0);
=20
-    if ( d->domain_id >=3D DOMID_FIRST_RESERVED )
+    if ( d->domain_id >=3D CONFIG_MAX_DOMID )
         return -ERANGE;
=20
     ctx =3D xzalloc(struct ffa_ctx);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 1c348e557d..ee8ddd33b0 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1493,7 +1493,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc=
)
             d =3D rcu_lock_domain_by_any_id(mc_msrinject->mcinj_domid);
             if ( d =3D=3D NULL )
             {
-                if ( mc_msrinject->mcinj_domid >=3D DOMID_FIRST_RESERVED )
+                if ( mc_msrinject->mcinj_domid >=3D CONFIG_MAX_DOMID )
                     return x86_mcerr("do_mca inject: incompatible flag "
                                      "MC_MSRINJ_F_GPADDR with domain %d",
                                      -EINVAL, domid);
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index c28192ea26..67d423e088 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -174,7 +174,7 @@ void vpmu_do_interrupt(void)
      * in XENPMU_MODE_ALL, for everyone.
      */
     if ( (vpmu_mode & XENPMU_MODE_ALL) ||
-         (sampled->domain->domain_id >=3D DOMID_FIRST_RESERVED) )
+         (sampled->domain->domain_id >=3D CONFIG_MAX_DOMID) )
     {
         sampling =3D choose_hwdom_vcpu();
         if ( !sampling )
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6d43be2e6e..66b91840f2 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -576,4 +576,11 @@ config BUDDY_ALLOCATOR_SIZE
 =09  Amount of memory reserved for the buddy allocator to serve Xen heap,
 =09  working alongside the colored one.
=20
+config MAX_DOMID
+=09int "Maximum number of user domains"
+=09range 1 32752
+=09default 32752
+=09help
+=09  Specifies the maximum number of domains a user can create.
+
 endmenu
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 01a65cb35d..204b71d096 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -68,7 +68,7 @@ struct domain *domain_list;
=20
 /* Non-system domain ID allocator. */
 static DEFINE_SPINLOCK(domid_lock);
-static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
+static DECLARE_BITMAP(domid_bitmap, CONFIG_MAX_DOMID);
 static domid_t domid_last;
=20
 /*
@@ -155,7 +155,7 @@ int domain_init_states(void)
     ASSERT(rw_is_write_locked_by_me(¤t->domain->event_lock));
=20
     dom_state_changed =3D xvzalloc_array(unsigned long,
-                                       BITS_TO_LONGS(DOMID_FIRST_RESERVED)=
);
+                                       BITS_TO_LONGS(CONFIG_MAX_DOMID));
     if ( !dom_state_changed )
         return -ENOMEM;
=20
@@ -235,7 +235,7 @@ int get_domain_state(struct xen_domctl_get_domain_state=
 *info, struct domain *d,
     while ( dom_state_changed )
     {
         dom =3D find_first_bit(dom_state_changed, DOMID_MASK + 1);
-        if ( dom >=3D DOMID_FIRST_RESERVED )
+        if ( dom >=3D CONFIG_MAX_DOMID )
             break;
         if ( test_and_clear_bit(dom, dom_state_changed) )
         {
@@ -824,7 +824,7 @@ struct domain *domain_create(domid_t domid,
     /* Sort out our idea of is_hardware_domain(). */
     if ( (flags & CDF_hardware) || domid =3D=3D hardware_domid )
     {
-        if ( hardware_domid < 0 || hardware_domid >=3D DOMID_FIRST_RESERVE=
D )
+        if ( hardware_domid < 0 || hardware_domid >=3D CONFIG_MAX_DOMID )
             panic("The value of hardware_dom must be a valid domain ID\n")=
;
=20
         /* late_hwdom is only allowed for dom0. */
@@ -2414,9 +2414,12 @@ domid_t get_initial_domain_id(void)
=20
 domid_t domid_alloc(domid_t domid)
 {
+    BUILD_BUG_ON(DOMID_FIRST_RESERVED >=3D UINT16_MAX);
+    BUILD_BUG_ON(DOMID_FIRST_RESERVED < CONFIG_MAX_DOMID);
+
     spin_lock(&domid_lock);
=20
-    if ( domid < DOMID_FIRST_RESERVED )
+    if ( domid < CONFIG_MAX_DOMID )
     {
         if ( __test_and_set_bit(domid, domid_bitmap) )
             domid =3D DOMID_INVALID;
@@ -2426,13 +2429,13 @@ domid_t domid_alloc(domid_t domid)
         bool reserved =3D __test_and_set_bit(get_initial_domain_id(),
                                            domid_bitmap);
=20
-        domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED,
+        domid =3D find_next_zero_bit(domid_bitmap, CONFIG_MAX_DOMID,
                                    domid_last);
=20
-        if ( domid =3D=3D DOMID_FIRST_RESERVED )
-            domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVE=
D, 0);
+        if ( domid =3D=3D CONFIG_MAX_DOMID )
+            domid =3D find_next_zero_bit(domid_bitmap, CONFIG_MAX_DOMID, 0=
);
=20
-        if ( domid =3D=3D DOMID_FIRST_RESERVED )
+        if ( domid =3D=3D CONFIG_MAX_DOMID )
         {
             domid =3D DOMID_INVALID;
         }
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 9043414290..f1bfb6f6a2 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -867,7 +867,7 @@ int sched_init_domain(struct domain *d, unsigned int po=
olid)
     int ret;
=20
     ASSERT(d->cpupool =3D=3D NULL);
-    ASSERT(d->domain_id < DOMID_FIRST_RESERVED);
+    ASSERT(d->domain_id < CONFIG_MAX_DOMID);
=20
     if ( (ret =3D cpupool_add_domain(d, poolid)) )
         return ret;
@@ -891,7 +891,7 @@ int sched_init_domain(struct domain *d, unsigned int po=
olid)
=20
 void sched_destroy_domain(struct domain *d)
 {
-    ASSERT(d->domain_id < DOMID_FIRST_RESERVED);
+    ASSERT(d->domain_id < CONFIG_MAX_DOMID);
=20
     if ( d->cpupool )
     {
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/=
vtd/iommu.c
index c55f02c97e..5df85ca629 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1509,7 +1509,7 @@ int domain_context_mapping_one(
=20
         prev_did =3D context_domain_id(lctxt);
         domid =3D did_to_domain_id(iommu, prev_did);
-        if ( domid < DOMID_FIRST_RESERVED )
+        if ( domid < CONFIG_MAX_DOMID )
             prev_dom =3D rcu_lock_domain_by_id(domid);
         else if ( pdev ? domid =3D=3D pdev->arch.pseudo_domid : domid > DO=
MID_MASK )
             prev_dom =3D rcu_lock_domain(dom_io);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5b2063eed9..0c14c30c1b 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -36,7 +36,7 @@
=20
 /*
  * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
- * If it is specified as an invalid value (0 or >=3D DOMID_FIRST_RESERVED)=
,
+ * If it is specified as an invalid value (0 or >=3D CONFIG_MAX_DOMID),
  * an id is auto-allocated and returned.
  */
 /* XEN_DOMCTL_createdomain */
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 21 00:10:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 00:10:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991326.1375204 (Exim 4.92)
	(envelope-from )
	id 1uHX2b-0005Wz-TX; Wed, 21 May 2025 00:10:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991326.1375204; Wed, 21 May 2025 00:10: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 1uHX2b-0005Ws-Qy; Wed, 21 May 2025 00:10:37 +0000
Received: by outflank-mailman (input) for mailman id 991326;
 Wed, 21 May 2025 00:10:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHX2a-0005Wm-P1
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 00:10:36 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 03edc5f7-35d8-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 02:10: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" 
X-Inumbo-ID: 03edc5f7-35d8-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747786233; x=1748045433;
	bh=ZdzoAR0r2d1QCrjvC7H8Dzdphpg/hImZBTr3IbkxKRI=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=AZHLFsKxjm1g3dMkvSFD41woWtBfJaIYwa0SlczIgGKbtncJyPhWQZDNddoAP2OnH
	 UaVQXGDm91X35bDJl5b2L0csv7fGE1aJ974P0JR469/5A1+rIK1Hj7ZR1lhnrl/AYW
	 2jnc2xrL9Svd6er7/9VTgp75Bx7/kDOKU8HGXr6bMem6jRSPSebsSn+pfDOT6Jm0Xy
	 jJklzwbLCgQajASiW84Twosui/1o9ZnPHu/a/LdWbyRNXsII+KzpDKucDg4/oFTW+7
	 jk+lve6Dj7zPgHm3mB3NgdWqOxZGvMbIPVjf0SrkORn98m3EV9mH6hHqDYDTvhESIo
	 rKIgyWlbCrlrw==
Date: Wed, 21 May 2025 00:10:28 +0000
To: Andrew Cooper 
From: dmkhn@proton.me
Cc: Xen-devel , Anthony PERARD , Stefano Stabellini , =?utf-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH 0/3] CI: Improvements to *-tools-test-* jobs
Message-ID: 
In-Reply-To: <20250520205239.203253-1-andrew.cooper3@citrix.com>
References: <20250520205239.203253-1-andrew.cooper3@citrix.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: fe9eb75b489afd68bd5fe6eb732e773ef895fe48
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 20, 2025 at 09:52:36PM +0100, Andrew Cooper wrote:
> Rearrange tools/tests to be more ameanable to running in CI, and drop the
> special casing holding it together.
>=20
>=20
>=20
> Andrew Cooper (3):
>   tools/tests: Drop depriv-fd-checker
>   tools/tests: Install tests into $(LIBEXEC)/tests
>   CI: Drop custom handling of tools/tests

The code changes look good to me

Reviewed-by: Denis Mukhin 

for the series.

>=20
>  .gitignore                             |   1 -
>  automation/scripts/build               |   1 -
>  automation/scripts/qubes-x86-64.sh     |   7 +-
>  automation/scripts/run-tools-tests     |  43 ++-
>  tools/tests/Makefile                   |   1 -
>  tools/tests/cpu-policy/Makefile        |   6 +-
>  tools/tests/depriv/Makefile            |  52 ---
>  tools/tests/depriv/depriv-fd-checker.c | 436 -------------------------
>  tools/tests/paging-mempool/Makefile    |   6 +-
>  tools/tests/rangeset/Makefile          |   6 +-
>  tools/tests/resource/Makefile          |   6 +-
>  tools/tests/tsx/Makefile               |   6 +-
>  tools/tests/xenstore/Makefile          |   6 +-
>  13 files changed, 40 insertions(+), 537 deletions(-)
>  delete mode 100644 tools/tests/depriv/Makefile
>  delete mode 100644 tools/tests/depriv/depriv-fd-checker.c
>=20
> --
> 2.39.5
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Wed May 21 00:24:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 00:24:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991332.1375215 (Exim 4.92)
	(envelope-from )
	id 1uHXG8-0007LU-3g; Wed, 21 May 2025 00:24:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991332.1375215; Wed, 21 May 2025 00: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 1uHXG8-0007LN-07; Wed, 21 May 2025 00:24:36 +0000
Received: by outflank-mailman (input) for mailman id 991332;
 Wed, 21 May 2025 00:24:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHXG6-0007LH-K6
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 00:24:34 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f694d387-35d9-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 02:24:32 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 1D1245C3FBB;
 Wed, 21 May 2025 00:22:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51687C4CEE9;
 Wed, 21 May 2025 00:24: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" 
X-Inumbo-ID: f694d387-35d9-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747787069;
	bh=kLnz7QqgPBc9fxMyinRffEDp1TUaXN2QfnkNZQs1r3w=;
	h=Date:From:To:cc:Subject:From;
	b=ckdLLw6FFQLepHt0c+9iO0PYG3Px+Z/NuJKK0XXPGnJcxhRfzabf1E18y5MJoqhDT
	 NVpGiHIZ3HwgUHhY81fneYs50AHtQ09TiZ2jHEkoCgnMH6FOGiXDKsp8WWZF1B/bVG
	 bZloA8IcJSMkGc/CmCBgJWDk6bS493AynVPGyB+dS4kyoxfx1Y3pqmpRyy1MYBEcQ/
	 aujLo3Pa3vs9yGANE/a1uJjDvcFyWCnfIQSzw0TcCUp8/Y0Gfifo+JHkEGZIjdSXlf
	 B5tDTmXZzyI0j3pJsqEvYZ1ouuFK2avKWLnzwc+OzwgQMgEhB81wkCEpM6uD2p3ijL
	 k3wusEKUOUbTA==
Date: Tue, 20 May 2025 17:24:26 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Juergen Gross 
cc: sstabellini@kernel.org, Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Jan Beulich , Jason.Andryuk@amd.com, 
    oleksandr_tyshchenko@epam.com, boris.ostrovsky@oracle.com, 
    Yi.Wang2@amd.com, Xenia.Ragiadakou@amd.com, agarciav@amd.com, 
    julien@xen.org, xen-devel@lists.xenproject.org
Subject: pin_user_pages and foreign mappings error
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

Hi Juergen and all,

We have an issue where QEMU is mapping foreign pages as usual and
passing them to a driver in Linux (amdxdna). The driver in Linux calls
pin_user_pages_fast() on these pages, and it returns -EFAULT. Stack
trace appended below.

This is Dom0 PVH. We disabled CONFIG_XEN_UNPOPULATED_ALLOC and
CONFIG_XEN_BALLOON_MEMORY_HOTPLUG attemping to make things better but it
did not solved the issue. We tried changing pin_user_pages_fast() to
pin_user_pages(), still -EFAULT. check_vma_flags returns -EFAULT because
of the (VM_IO | VM_PFNMAP) check.

We tried removing (VM_IO | VM_PFNMAP) from privcmd_mmap and
xen_xlate_remap_gfn_array based on the idea that the underlying pages
are normal memory once CONFIG_XEN_UNPOPULATED_ALLOC and
CONFIG_XEN_BALLOON_MEMORY_HOTPLUG are disabled.

In this case, vm_normal_page takes the if
(IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) path, none of the checks work,
so it calls print_bad_pte and it breaks.

As another attempt, we tried removing pte_mkspecial from
xlate_mmu.c:remap_pte_fn and remap_pfn_fn, based again on the same idea
that the underlying pages should not be "special". Now it went further
but it broke at unmap_vmas time on a reference counting error. Specifically,
we get "non-zero mapcount" on the callchain from unmap_vmas:

[31789.440433] BUG: Bad page map in process qemu-system-x86  pte:800000018f8a9027 pmd:13c29a067
[31789.440459] page:000000008316c487 refcount:0 mapcount:-1 mapping:0000000000000000 index:0x0 pfn:0x18f8a9
[31789.440461] flags: 0x17ffffc0000214(referenced|dirty|workingset|node=0|zone=2|lastcpupid=0x1fffff)
[31789.440463] page_type: 0xfffffffe()
[31789.440465] raw: 0017ffffc0000214 dead000000000100 dead000000000122 0000000000000000
[31789.440467] raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000
[31789.440468] page dumped because: bad pte
[31789.440469] addr:0000780c1213a000 vm_flags:0c0600fb anon_vma:0000000000000000 mapping:ffff888185672418 index:3a
[31789.440498] file:privcmd fault:privcmd_fault [xen_privcmd] mmap:privcmd_mmap [xen_privcmd] read_folio:0x0

So, it would seem that we need to keep treating foreign mapping pages as
special (pte_mkspecial and also VM_IO | VM_PFNMAP) but if we do that
pin_user_pages() fails.

Do you have any ideas how to get pin_user_pages() to work with foreign
mappings from userspace?

Many thanks for your help!!

Cheers,

Stefano

[ 1645.560295] WARNING: CPU: 5 PID: 3989 at mm/gup.c:229 try_grab_page+0xd7/0x140
[ 1645.560452] CPU: 5 PID: 3989 Comm: qemu-system-x86 Tainted: G    B      OE      6.8.0+ #36
[ 1645.560457] Hardware name: AMD BIRMANPLUS/BirmanPlus-STX, BIOS TXB1001dB 12/09/2024 22:52:15
[ 1645.560459] RIP: 0010:try_grab_page+0xd7/0x140
[ 1645.560463] Code: 00 00 00 be 23 00 00 00 48 c1 e8 36 48 8b 3c c5 a0 3d 04 83 e8 1a 46 fe ff 31 c0 5d 31 d2 31 f6 31 ff 45 31 c0 c3 cc cc cc cc <0f> 0b 41 b8 f4 ff ff ff 44 89 c0 31 d2 31 f6 31 ff 45 31 c0 c3 cc
[ 1645.560467] RSP: 0018:ffffc90004b6b9d0 EFLAGS: 00010286
[ 1645.560470] RAX: ffffea00047559c0 RBX: 0000000000080101 RCX: 0000000000000000
[ 1645.560472] RDX: 00000000ffffffff RSI: 0000000000080101 RDI: ffffea00047559c0
[ 1645.560474] RBP: ffffc90004b6ba20 R08: 0000000000000000 R09: 0000000000000000
[ 1645.560475] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881252fab40
[ 1645.560476] R13: ffff88818c65c998 R14: ffffea00047559c0 R15: 800000011d567027
[ 1645.560481] FS:  00007283a21d3f80(0000) GS:ffff88827e480000(0000) knlGS:0000000000000000
[ 1645.560483] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1645.560485] CR2: 00007283a0cb4060 CR3: 000000011c986000 CR4: 0000000000750ef0
[ 1645.560490] PKRU: 55555554
[ 1645.560492] Call Trace:
[ 1645.560494]  
[ 1645.560499]  ? show_regs+0x72/0x90
[ 1645.560506]  ? try_grab_page+0xd7/0x140
[ 1645.560508]  ? __warn+0x8d/0x160
[ 1645.560512]  ? try_grab_page+0xd7/0x140
[ 1645.560515]  ? report_bug+0x1bb/0x1d0
[ 1645.560520]  ? handle_bug+0x46/0x90
[ 1645.560525]  ? exc_invalid_op+0x19/0x80
[ 1645.560529]  ? asm_exc_invalid_op+0x1b/0x20
[ 1645.560536]  ? try_grab_page+0xd7/0x140
[ 1645.560538]  ? follow_page_pte+0xf1/0x5e0
[ 1645.560541]  follow_page_mask+0x3b5/0x5f0
[ 1645.560544]  ? check_vma_flags+0x1b5/0x290
[ 1645.560547]  __get_user_pages+0x112/0x780
[ 1645.560550]  ? vprintk_emit+0x1ad/0x320
[ 1645.560556]  __gup_longterm_locked+0x231/0xca0
[ 1645.560566]  pin_user_pages+0x78/0xb0
[ 1645.560571]  amdxdna_get_ubuf+0x2c6/0x4d0 [amdxdna]
[ 1645.560667]  amdxdna_gem_create_share_object+0x114/0x170 [amdxdna]
[ 1645.560684]  amdxdna_drm_create_bo_ioctl+0x398/0x5b0 [amdxdna]
[ 1645.560702]  ? __pfx_amdxdna_drm_create_bo_ioctl+0x10/0x10 [amdxdna]
[ 1645.560719]  drm_ioctl_kernel+0xb2/0x110
[ 1645.560727]  drm_ioctl+0x2e2/0x590
[ 1645.560731]  ? __pfx_amdxdna_drm_create_bo_ioctl+0x10/0x10 [amdxdna]
[ 1645.560749]  ? syscall_exit_to_user_mode+0x86/0x260
[ 1645.560753]  ? do_syscall_64+0x93/0x180
[ 1645.560759]  ? __f_unlock_pos+0x12/0x20
[ 1645.560770]  __x64_sys_ioctl+0x9d/0xe0
[ 1645.560775]  do_syscall_64+0x84/0x180
[ 1645.560779]  ? do_syscall_64+0x93/0x180
[ 1645.560784]  ? do_syscall_64+0x93/0x180
[ 1645.560788]  ? irqentry_exit+0x43/0x50
[ 1645.560791]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
[ 1645.560794] RIP: 0033:0x7283a3b1a94f
[ 1645.560798] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
[ 1645.560800] RSP: 002b:00007ffde39d3b50 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 1645.560804] RAX: ffffffffffffffda RBX: 00007ffde39d3c10 RCX: 00007283a3b1a94f
[ 1645.560805] RDX: 00007ffde39d3c10 RSI: 00000000c0206443 RDI: 0000000000000030
[ 1645.560807] RBP: 00000000c0206443 R08: 0000000000000000 R09: 00005e5e79219400
[ 1645.560809] R10: 00007283a35ebb90 R11: 0000000000000246 R12: 00005e5e79559750
[ 1645.560810] R13: 0000000000000030 R14: 00005e5e78ef3f20 R15: 00005e5e78ef4310
[ 1645.560814]  

>


From xen-devel-bounces@lists.xenproject.org Wed May 21 00:34:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 00:34:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991340.1375225 (Exim 4.92)
	(envelope-from )
	id 1uHXPQ-0000a4-Ul; Wed, 21 May 2025 00:34:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991340.1375225; Wed, 21 May 2025 00:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHXPQ-0000Zx-R4; Wed, 21 May 2025 00:34:12 +0000
Received: by outflank-mailman (input) for mailman id 991340;
 Wed, 21 May 2025 00:34:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHXPP-0000ZY-Ig
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 00:34:11 +0000
Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com
 [2607:f8b0:4864:20::112e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4eea61a5-35db-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 02:34:09 +0200 (CEST)
Received: by mail-yw1-x112e.google.com with SMTP id
 00721157ae682-70de8897628so8680077b3.1
 for ; Tue, 20 May 2025 17:34:10 -0700 (PDT)
Received: from [10.138.10.6] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 00721157ae682-70ca82f11d6sm24616697b3.20.2025.05.20.17.34.07
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 17:34: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" 
X-Inumbo-ID: 4eea61a5-35db-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747787648; x=1748392448; darn=lists.xenproject.org;
        h=in-reply-to:subject:autocrypt:from:content-language:references:to
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=OxRnWjTEb1WqVd/79Cr6p/ryPov6LsCp7bZspk3Ut9o=;
        b=VXZpdYKY0y4B0A7RrC1oDsAdwhXpbChHCwoYY33FfAAEEorOsMGi1M6s3VyMndMqst
         c5jt7FIcuAI+aHopKM/SMBZVcuXqAd4cR/SuZp/2G6gn1pPyA61+2rjAln6gcQh0oxaf
         oTRdG1aI8xihMlGQyXiZ8frc3dDFr6AL0oAY3TP+kVEsm7Nn8DNfxBbhK0+1j/qWStnJ
         wLRZBgpDkZzeZpxtrDye2r3MFbsTn34QRw1o1MkkaD3B8rYStqoReLBpqMLtPIJAHnpg
         ylL00vi5tmqeFsxz/UddPTZ3AERAlMyMzwHWgGSHjIRU5oS/KD+luJkrCY/PKLEEReJ0
         Gf6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747787648; x=1748392448;
        h=in-reply-to:subject:autocrypt:from:content-language:references:to
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=OxRnWjTEb1WqVd/79Cr6p/ryPov6LsCp7bZspk3Ut9o=;
        b=SfgzUedEaZLajq2Cen3f4qtUkCQCVQv+5CY+/0VCgnqihrXUK6f7nxJAWMtjlB4q67
         65JgZJe2GY07E8qs4Nka23owU+J3WL0EVIK6+LhahgW/9HvXJY9z26Zcx/H0Pfa30nPE
         mDMaq7c58s+QMT4hOBFPF0mNS2oNjJ2Dp+1cFVIqVtRP4+Wsv3j/hNqkd2dsGWpVTxHL
         G+dLTXikC+z01tkQeIxkEostUO072om206r4PVf4EN51HvgXA+u/GPUTFdpPLGXZa+2a
         YPtE+Oqy7sBgXVPEj4OsD1DfGyzIsurQpDzKh3kLldRNS9jnB+69ShUpaJZDMXqEDL4o
         CaRw==
X-Gm-Message-State: AOJu0Yxl6tPOoNnc5FFtBBO8PGrjcAvOT8Syj+gtwUIDVucze7IUJ5Hx
	mv8UNuZ6TatFnuDOh/QnXxjNkenp7CnAWcB/+fv8H8zRAlAnMa7LD7uqJk93Aw==
X-Gm-Gg: ASbGncvaLbVpuLOB3wAkMYBNR4ZHjHiTwDxOryu2dH5s0AqarKIYb3Mg1NCKO1D68fj
	UzhJa2HteKzCjuSdkG1psj6hkU78ro5skx23vBN9rJmKfVdx63XEutKj56a7iYZ2naroqP0mhQe
	2hBCQ6DmyESSrbukAk7BhFZ0S31rIwz1ls8XC/3oh9zMY2yqc8TX20hqQJANuq0+W3zN0XPAT5v
	SgBqHpSnO/IWmzRLUwMBuaGNdaA1HhN6rMakWPPKzFXVh09r0o03cN+oCsYlfkRoma5iuAKw0I1
	tLg39dCiuYVDyrKIcQw+nwqajY2ck+bKlseWntklPkpvDQw+cgA42IU=
X-Google-Smtp-Source: AGHT+IF/dfOXAITnHpky3dSOLLs65BmhI02wT7QPcle96QhlU/66nxN+nF890DS8Pgq7zuKhfmjI7g==
X-Received: by 2002:a05:690c:60c1:b0:70c:a5c2:ceed with SMTP id 00721157ae682-70cab0bb4afmr223294067b3.25.1747787648416;
        Tue, 20 May 2025 17:34:08 -0700 (PDT)
Message-ID: <5171c83d-aba8-4076-8316-d193f175aa7f@gmail.com>
Date: Tue, 20 May 2025 20:33:54 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: xen-devel@lists.xenproject.org
References: 
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
Subject: Re: pin_user_pages and foreign mappings error
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------HgQXZfGiECgSa0SQW0fKxcss"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------HgQXZfGiECgSa0SQW0fKxcss
Content-Type: multipart/mixed; boundary="------------F1vSJLUwmgZEKzUR8UFPeFMW";
 protected-headers="v1"
From: Demi Marie Obenour 
To: xen-devel@lists.xenproject.org
Message-ID: <5171c83d-aba8-4076-8316-d193f175aa7f@gmail.com>
Subject: Re: pin_user_pages and foreign mappings error
References: 
In-Reply-To: 

--------------F1vSJLUwmgZEKzUR8UFPeFMW
Content-Type: multipart/mixed; boundary="------------c7tKHbO9wNfWU03vGtQJSmXG"

--------------c7tKHbO9wNfWU03vGtQJSmXG
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/20/25 20:24, Stefano Stabellini wrote:
> Hi Juergen and all,
>=20
> We have an issue where QEMU is mapping foreign pages as usual and
> passing them to a driver in Linux (amdxdna). The driver in Linux calls
> pin_user_pages_fast() on these pages, and it returns -EFAULT. Stack
> trace appended below.

Is the QEMU virtual device that does this upstreamed?

> This is Dom0 PVH. We disabled CONFIG_XEN_UNPOPULATED_ALLOC and
> CONFIG_XEN_BALLOON_MEMORY_HOTPLUG attemping to make things better but i=
t
> did not solved the issue. We tried changing pin_user_pages_fast() to
> pin_user_pages(), still -EFAULT. check_vma_flags returns -EFAULT becaus=
e
> of the (VM_IO | VM_PFNMAP) check.
>=20
> We tried removing (VM_IO | VM_PFNMAP) from privcmd_mmap and
> xen_xlate_remap_gfn_array based on the idea that the underlying pages
> are normal memory once CONFIG_XEN_UNPOPULATED_ALLOC and
> CONFIG_XEN_BALLOON_MEMORY_HOTPLUG are disabled.
>=20
> In this case, vm_normal_page takes the if
> (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) path, none of the checks work=
,
> so it calls print_bad_pte and it breaks.
>=20
> As another attempt, we tried removing pte_mkspecial from
> xlate_mmu.c:remap_pte_fn and remap_pfn_fn, based again on the same idea=

> that the underlying pages should not be "special". Now it went further
> but it broke at unmap_vmas time on a reference counting error. Specific=
ally,
> we get "non-zero mapcount" on the callchain from unmap_vmas:
>=20
> [31789.440433] BUG: Bad page map in process qemu-system-x86  pte:800000=
018f8a9027 pmd:13c29a067
> [31789.440459] page:000000008316c487 refcount:0 mapcount:-1 mapping:000=
0000000000000 index:0x0 pfn:0x18f8a9
> [31789.440461] flags: 0x17ffffc0000214(referenced|dirty|workingset|node=
=3D0|zone=3D2|lastcpupid=3D0x1fffff)
> [31789.440463] page_type: 0xfffffffe()
> [31789.440465] raw: 0017ffffc0000214 dead000000000100 dead000000000122 =
0000000000000000
> [31789.440467] raw: 0000000000000000 0000000000000000 00000000fffffffe =
0000000000000000
> [31789.440468] page dumped because: bad pte
> [31789.440469] addr:0000780c1213a000 vm_flags:0c0600fb anon_vma:0000000=
000000000 mapping:ffff888185672418 index:3a
> [31789.440498] file:privcmd fault:privcmd_fault [xen_privcmd] mmap:priv=
cmd_mmap [xen_privcmd] read_folio:0x0
>=20
> So, it would seem that we need to keep treating foreign mapping pages a=
s
> special (pte_mkspecial and also VM_IO | VM_PFNMAP) but if we do that
> pin_user_pages() fails.
>=20
> Do you have any ideas how to get pin_user_pages() to work with foreign
> mappings from userspace?I

Does the privcmd driver try to free the pages while amdxdna is still
using them?  privcmd might be assuming that the pages are freed once
the unmap ioctl is called from userspace and the pages are unmapped
from userspace memory.  That isn't true if the pages are pinned by
another driver.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------c7tKHbO9wNfWU03vGtQJSmXG
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------c7tKHbO9wNfWU03vGtQJSmXG--

--------------F1vSJLUwmgZEKzUR8UFPeFMW--

--------------HgQXZfGiECgSa0SQW0fKxcss
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmgtH3sACgkQszaHOrMp
8lNFXhAAhA3zI9pMBjWoU1ro3c+qoHYT+TAvhGvmoNU+cHuD71Iz8oOVyVk5AZCj
h/VAxX5tgsxDcjk1XmjE6ntKk6I7tXtauDTpmUvOSdj8q8fmuGbNSY2yjDZlkBe2
wxBtgEMAGqNStb9TKb6wgBGlddfEnGGUaHOc4NNq4DAJof3FcYzzsx6b2zCdJ9eI
p1KoqG/Xi9MNyVpzeqF+ZMjYF1FNz9hp6LdRiKRpku532S0kukK9oGWDWGN3oS0u
yK6AVovcPIt9f2H0ROvmf2SHQ+RFQKd6nQSgGHBJTZoh0mZm3E7FTswWYftW6/He
UGzW8yDygooTGfxfoWNryNv4YUXbHd0jFqXM8wqZMHKmZiG78gwn4OUPzhitYrxm
smbmhBapePfTohFbS+DllNUWmCfYSXQHT4Hj9NKjVFpHyp2SHfeeO5EGUZrlgw73
TMxs+bykUclqUZmR+J7HPbd+aoE+SPwf658D+BoLt4Rza9tfJflVkGfLv/1VQcJh
Izo+kgNjMye+X9NfnFmWNoDXnus17wDpvIuH6hMczmhZuPXjJ+S86ju8wPFkY2mA
jZk9SxuP2sJMCRrncKJZ0dTBSLpEZhks+4qyjO4uqtV6WiP+jGLivPs10sCSdNZ/
eyn6sg0+pmdSyX7SGIITrkuTq+oGQwuxOKxgBQ/PXwsNmXj93Yw=
=Ai9H
-----END PGP SIGNATURE-----

--------------HgQXZfGiECgSa0SQW0fKxcss--


From xen-devel-bounces@lists.xenproject.org Wed May 21 01:02:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 01:02:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991352.1375235 (Exim 4.92)
	(envelope-from )
	id 1uHXqP-0003wh-3z; Wed, 21 May 2025 01:02:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991352.1375235; Wed, 21 May 2025 01: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 1uHXqP-0003wa-1J; Wed, 21 May 2025 01:02:05 +0000
Received: by outflank-mailman (input) for mailman id 991352;
 Wed, 21 May 2025 01:02:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHXqO-0003wU-9y
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 01:02:04 +0000
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com
 [2a00:1450:4864:20::129])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 34be3fc8-35df-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 03:02:02 +0200 (CEST)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-550e2b9084dso6990198e87.1
 for ; Tue, 20 May 2025 18:02: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" 
X-Inumbo-ID: 34be3fc8-35df-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747789322; x=1748394122; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Las3xNmpnzPodzQgSlhouDoCKTDiT0A+EO/X0XnBjs0=;
        b=I//Gwx5EwYda2W6F5O08hx9fe+hv55EMFRVxq9bz6lvq9yeSnh30xGXS7HP/NxluSD
         99gsmsmcgIHjB/oi4L7PEH56ath5s4B8Or/eWM+d6sJfv0KMnhRJdtQLrOZXWK5Y8HM5
         Sfly7dSEhC7WFRt+5i3LcANfeWYWRwZ4m3GDX/3NxLfpSnPP0ZWv7hO7tzrAHddq1IDo
         VMWGIjihyvnP+mYaCcyukeRzgT16MhUnOygpcHp3L9V4dxUUoSjI7ptxH+87VftnMsMw
         9wQheK7cdV1wIyFPsGJ1cA9KPKCg2W/uCq7ckzi86FhcsYzoZtrnO7fjrKvqlJRC5vxC
         JDEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747789322; x=1748394122;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Las3xNmpnzPodzQgSlhouDoCKTDiT0A+EO/X0XnBjs0=;
        b=qvxA1LfryyNSG9ZRgXPPGDuUC3w4p84iLQJKSeTxFhF+XqH8a3Dewr/YrhI1bIU1Ai
         EfdsjtGGqebruOJyLYpu3JPc+DoWBsVDuPFGp7sHDRZGearUz7aqTsgpS86nImD8ILOf
         QCyvXw1+BhoA/h7p/+apJMTjht2/VmjI6gy70hf8Qw5vp+cA7rDcg46bW6+Q1dpzCBMo
         4ab9c+fWSlCJHWasQvZ/5DmZIyiBzLNDXV6Nq7vEEUBJRShl2r7jlbvfRV1p6x8XvPeR
         t3NUIFNmZAV0L1DJCJvpXLSv2oH5ijn/vT1TDC3Yowq0jCK3fARdeVoYjzmTdje8RJQR
         XiFg==
X-Gm-Message-State: AOJu0YwwHvCpoRs+bxBNbHPDhRCVIhQZKYkP1QVkPXnk8VGabRlOGXRl
	CDGWug0F3paWn6h0YlzDg90dEXfgwV3ADzJHG4M/itb0UhPJRf2Sa0J3nG76T20nRntGWd0a6we
	8Bs9vrs3MHDgd1DilSGMUa82KVNOLveA=
X-Gm-Gg: ASbGncsGc5E+R2qJL51Iz8rcY01k6ndchtH3QiOfWy2FlVV7s/9k/SaIkvuu+boGBqJ
	Elu79apPfwaJSKSEhAm9htqm+uHQTXQjE1psvNTWxW6uDDMdqG3pB+81Re9Aju54L6uoHppKOlJ
	ukuc9hmRVpRzSTr+/rKQuy3YYW7+GLTYM=
X-Google-Smtp-Source: AGHT+IF3HNLdNZhp9DCb931kzsZfgUHkPUwlmfwiyl3EuxvBL4+b22sPw8GiViKXmXdaQQSq9u5KIxFcpxv4IHRW5rw=
X-Received: by 2002:a05:6512:1342:b0:551:f76c:59ec with SMTP id
 2adb3069b0e04-551f76c5cecmr2117665e87.48.1747789321931; Tue, 20 May 2025
 18:02:01 -0700 (PDT)
MIME-Version: 1.0
References: <20250520141027.120958-1-andrew.cooper3@citrix.com>
In-Reply-To: <20250520141027.120958-1-andrew.cooper3@citrix.com>
From: Christopher Clark 
Date: Wed, 21 May 2025 02:01:50 +0100
X-Gm-Features: AX0GCFstFF_PAcvDgiM9qlK8k0YLU-TzV0F1omJnoZ9PZbsSDnJLveO6nMoIS9Y
Message-ID: 
Subject: Re: [PATCH] xen/argo: Command line handling improvements
To: Andrew Cooper 
Cc: Xen-devel , 
	"Daniel P . Smith" , Denis Mukhin 
Content-Type: multipart/alternative; boundary="000000000000ad12e906359ae906"

--000000000000ad12e906359ae906
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 20, 2025 at 3:10=E2=80=AFPM Andrew Cooper 
wrote:

> Treat "argo" on the command line as a positive boolean, rather than
> requiring
> the user to pass "argo=3D1/on/enable/true".
>
> Move both opt_argo* variables into __ro_after_init.  They're set during
> command line parsing and never modified thereafter.
>

Instead of binding to static values set at boot, would
boolean_runtime_param be acceptable? This allows the system administrator
to adjust the Argo settings if the hypervisor has been compiled with it
enabled and booted with the default settings, and avoid having to reboot
and modify the bootloader configuration.

I agree with Daniel's request for a doc update where affected.

thanks,

Christopher



>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Christopher Clark 
> CC: Daniel P. Smith 
> CC: Denis Mukhin 
>
> Found while
> ---
>  xen/common/argo.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/xen/common/argo.c b/xen/common/argo.c
> index cbe8911a4364..027b37b18a6c 100644
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -79,8 +79,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_argo_unregister_ring_t);
>  DEFINE_COMPAT_HANDLE(compat_argo_iov_t);
>  #endif
>
> -static bool __read_mostly opt_argo;
> -static bool __read_mostly opt_argo_mac_permissive;
> +static bool __ro_after_init opt_argo;
> +static bool __ro_after_init opt_argo_mac_permissive;
>
>  static int __init cf_check parse_argo(const char *s)
>  {
> @@ -92,7 +92,10 @@ static int __init cf_check parse_argo(const char *s)
>          if ( !ss )
>              ss =3D strchr(s, '\0');
>
> -        if ( (val =3D parse_bool(s, ss)) >=3D 0 )
> +        /* Intepret "argo" as a positive boolean. */
> +        if ( *s =3D=3D '\0' )
> +            opt_argo =3D true;
> +        else if ( (val =3D parse_bool(s, ss)) >=3D 0 )
>              opt_argo =3D val;
>          else if ( (val =3D parse_boolean("mac-permissive", s, ss)) >=3D =
0 )
>              opt_argo_mac_permissive =3D val;
>
> base-commit: 293abb9e0c5e8df96cc5dfe457c62dfcb7542b19
> --
> 2.39.5
>
>

--000000000000ad12e906359ae906
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    On Tue, May 20, 2025 at 3:10=E2=80=AFPM A=
ndrew Cooper <andrew.cooper=
3@citrix.com> wrote:
    Treat "argo&q=
uot; on the command line as a positive boolean, rather than requiring
    
the user to pass "argo=3D1/on/enable/true".
    

    
Move both opt_argo* variables into __ro_after_init.=C2=A0 They're set d=
uring
    
command line parsing and never modified thereafter.
    Instead of binding to static values set at boot, would boolean=
_runtime_param be acceptable? This allows the system administrator to adjus=
t the Argo settings if the hypervisor has been compiled with it enabled and=
 booted with the default settings, and avoid having to reboot and modify th=
e bootloader configuration.

    I agree with Daniel=
9;s request for a doc update where affected.

    thank=
s,

    Christopher

    =C2=A0
    

    
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
---
    
CC: Christopher Clark <christopher.w.clark@gmail.com>
    
CC: Daniel P. Smith <dpsmith@apertussolutions.com>
    
CC: Denis Mukhin <d=
mkhn@proton.me>
    

    
Found while
    
---
    
=C2=A0xen/common/argo.c | 9 ++++++---
    
=C2=A01 file changed, 6 insertions(+), 3 deletions(-)
    

    
diff --git a/xen/common/argo.c b/xen/common/argo.c
    
index cbe8911a4364..027b37b18a6c 100644
    
--- a/xen/common/argo.c
    
+++ b/xen/common/argo.c
    
@@ -79,8 +79,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_argo_unregister_ring_t);
    
=C2=A0DEFINE_COMPAT_HANDLE(compat_argo_iov_t);
    
=C2=A0#endif
    

    
-static bool __read_mostly opt_argo;
    
-static bool __read_mostly opt_argo_mac_permissive;
    
+static bool __ro_after_init opt_argo;
    
+static bool __ro_after_init opt_argo_mac_permissive;
    

    
=C2=A0static int __init cf_check parse_argo(const char *s)
    
=C2=A0{
    
@@ -92,7 +92,10 @@ static int __init cf_check parse_argo(const char *s)
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ( !ss )
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ss =3D strchr(s, '\0=
9;);
    

    
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( (val =3D parse_bool(s, ss)) >=3D 0 )
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Intepret "argo" as a positive boo=
lean. */
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( *s =3D=3D '\0' )
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opt_argo =3D true;
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 else if ( (val =3D parse_bool(s, ss)) >=3D =
0 )
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opt_argo =3D val;
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else if ( (val =3D parse_boolean("ma=
c-permissive", s, ss)) >=3D 0 )
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opt_argo_mac_permissive =3D=
 val;
    

    
base-commit: 293abb9e0c5e8df96cc5dfe457c62dfcb7542b19
    
-- 
    
2.39.5
    

    

    

--000000000000ad12e906359ae906--


From xen-devel-bounces@lists.xenproject.org Wed May 21 03:32:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 03:32:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991390.1375262 (Exim 4.92)
	(envelope-from )
	id 1uHaC8-0004yd-PD; Wed, 21 May 2025 03:32:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991390.1375262; Wed, 21 May 2025 03:32: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 1uHaC8-0004yV-KK; Wed, 21 May 2025 03:32:40 +0000
Received: by outflank-mailman (input) for mailman id 991390;
 Wed, 21 May 2025 03:32:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHaC7-0004yP-3r
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 03:32:39 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2418::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3be388bf-35f4-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 05:32:35 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH1PR12MB9573.namprd12.prod.outlook.com (2603:10b6:610:2ae::5) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8746.30; Wed, 21 May 2025 03:32:31 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%4]) with mapi id 15.20.8746.030; Wed, 21 May 2025
 03: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" 
X-Inumbo-ID: 3be388bf-35f4-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PG3LUrsj9iPy+C+UBZAqCKMkctLJgLhgmQZbSYyR+rj/70jhGMKyeG3uASGFvUC+UWXPlXyR7nKFVtpE8Fxsx67S+sgbSjbOV2UHhnoPm3oF6zwZWwtoD1lBm2LZ8JgQRPbnVLcU5VxclyLcRCXsZGepg0WO7rc1aTFUPGxJEwO6m8rDttj3+D+TLC8Cpjyen9aohU23JaLC/zJyT2yaIrgXJHUne10amCkSMuHWCL91b9d8LZI813VzWyhO+aGqieQS8UMXJRBM3HhVNHDJIKI3oWOkkA41IFObhNlVh8JhzahlFjlFRhM7T+pIr9O9ItaPguQKfa8Q9uy5nA+Iwg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=A6lgO1+ItVCy56iWST09fh0O5R8yfiodxM9VPtYNz9s=;
 b=AnmVX0CMrqXjaUb6CJHZOplxlDAHqCN0u/EEwRs/WFsabhZb61S+jyPSrx0t2arCw8HAJ2LfoWcBHF/JpsWkIhCCJy8UkmpwRovjtgexph84wsbfL5wkT9b8+yFEBKleflJk2DT/tPPYG7XUICqZgcZlh9oEYg8vRc1U+ybYhpKgXh8MoiWaKtQ7AuGFe7b7UVw351yXXO7lP2cEkdXOb8qAlo6AM0xvC6dh4KzxMPA9o7nB9v/M1a4XKTxlmB+sOly7QvGJjZMqSibgZI69za+DS6JJGlXX/7bp+YHrMhwerRUbX0BpCS0Jnfuc6R3edNnAT40IMmbE9BoJPc8iTQ==
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=A6lgO1+ItVCy56iWST09fh0O5R8yfiodxM9VPtYNz9s=;
 b=2BlsN4/oamMQkaoAthJWzL0MvNx12IRzwXXUrlXfYECWHNMUzBhxDonKkP6CT+PpEvAlSCtZNydkdH21bBRWM2Ltr6tif6AuM1HKUgAtfegvWmo0+I1jXMohQtjCUmzQjmPRQykzU/3u5zwDOvIAzoZfgnzWi2ti4YStrRmO7Uo=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Anthony PERARD , "Orzel,
 Michal" , Julien Grall , Stefano
 Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v3 01/20] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
Thread-Topic: [PATCH v3 01/20] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
Thread-Index: AQHbspBJQJlxlUqSyEmw7elTsZuHSrO8YLMAgCA1fRA=
Date: Wed, 21 May 2025 03:32:30 +0000
Message-ID:
 
References: <20250421073723.3863060-1-Penny.Zheng@amd.com>
 <20250421073723.3863060-2-Penny.Zheng@amd.com>
 <7e16adfb-21d7-48e1-ab71-b66efa9553df@suse.com>
In-Reply-To: <7e16adfb-21d7-48e1-ab71-b66efa9553df@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=7daf3202-ed3d-47d7-a1a5-686d8ec9b759;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-21T03:32:21Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|CH1PR12MB9573:EE_
x-ms-office365-filtering-correlation-id: 1d9404f3-f2ae-41da-a02b-08dd98181e28
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?WW1DcFA0bUdqWWpGZEZ1YkZES3NHREZoL0RlRUxjU0ZHdFJsbjEyTlVGV3d4?=
 =?utf-8?B?R04zNTV5MzNjWk5yK3FQMDdjbEVmNi9nUmhsbnlIWnljSG5RREVKbkxld2RR?=
 =?utf-8?B?M2h0S2hZY09WWGZYbzJwVFVpUnQydXJOTnpvUkYzOE5PUDF1MTJlTXFVZUZo?=
 =?utf-8?B?U09NdUN1ZzBsMUhrV2FHb3YyTWlnbWs3ckY2UEMxVUdNVWZlVFhZZ3NFM3FO?=
 =?utf-8?B?MWk4RWZBZU1FbXlPSjZzUGxOejl0ZmxkZnNneTJqbzViK2hzWEltTVRVeDZT?=
 =?utf-8?B?ekhCQjN6WGZraEFKZE5FNzZPMWVRRWZCYklBd3FNK3FMN2RZVGVESE5JTXAr?=
 =?utf-8?B?c3RkV2Y4dVIzQ2Y2QXg3VE9IVXlrZGVkdk8vSEJ6cUE0RDhDc1JkV2RnTnJ2?=
 =?utf-8?B?d2R0NjI0SnE4VlZRTk9OVlpJY3c1cUNIV1VoV2U1RjNZWmV2VmFCd0pVcGMz?=
 =?utf-8?B?VGFaU0lKZ1V0bU9VYUY5QzdqNDdXSHRudkFjQlVROGxwUkNVd1gvU0F5enY2?=
 =?utf-8?B?aTk3L1l3WFJZVUxncDA2RDYyaEQzMFU5WHlUZmdncHhBajJCR2t6WDV5dDAv?=
 =?utf-8?B?d1lveTF1ZzV5UzJ4N1poeHBRYktaN1FJejMzWExUalpjeTVpb2krQksybTB5?=
 =?utf-8?B?cmtoL21HeXNLRmVIT0ZaUXl1SGhCbGZ3RU13SjJYNVg2SnZLSTVYRFJFSmt5?=
 =?utf-8?B?Y0laSVhUcERRUnB2eC9CSlNIWUVnVkFlUDNZOTV1NDlqTWhNQ09LYWt3dXBX?=
 =?utf-8?B?RWJQbWwrdDd4TWxyU1lvcXhMYXJ4UldiejBTeFdFK0k3SnVWdHZSLzZDbGVQ?=
 =?utf-8?B?d0pEODQ1b3ZKUGdwN28wMWlkN25rbGF2NTVMOXZ6bVhNeDJ5SUNLOVJ4bmd2?=
 =?utf-8?B?MkMyNG1XdjlSN0xrYUdEOGtoeW5jZnJIN3prTit0OE1WbG9LajA2bERLNkVy?=
 =?utf-8?B?WnVTOW5ONzM5bXdHZmw4YUM5RWF5NExuZVJ2ZDl0Y1BNUUZ2RVFxeXZLUlFy?=
 =?utf-8?B?UWpQQTVSSWhQYVA5V3EzQS9qUTBzMWY3ajlvb2JtQnVWZUxYMTRLdmc5b01Q?=
 =?utf-8?B?VGkvMHlnajNMaHYrWmZXWGp0Zzd3NmJ6QTVEdi9aNFl3K3N0cW1takVDUmdN?=
 =?utf-8?B?bVNJZVlvWmxVKzYzRU8zSzc4dlpGTFJ0N3ZoZkc3OUY4WW16bnp2TkNsV1VL?=
 =?utf-8?B?OGo3V1V2aU5saU5GcHJiMjRNd3BBZ2tYMWY1L1dpSGRXdXVWdmFzdTRkdjZn?=
 =?utf-8?B?aVBCcTUvcEpCMHVkS2Fab2dqbVA2YXFtRysvbG8yRVpUeUVVUE9RTS9RSFBp?=
 =?utf-8?B?N1VaMXBZVkwyM042SWgrSFE3cGR4aTU1T0MrdWVqUEM5YkpwRWRCZ1owT0Fp?=
 =?utf-8?B?SDRxa2tET1JZS1ErSmZObHZ5N3poTEV3dTlaNW1KUUlRenVrRG1KM2p2Y3V0?=
 =?utf-8?B?WGs2amd0NTdhRDAwZGg3U2FadmNQbHJnU1paeTVTbi9KQkc2Mm83cklEd0h2?=
 =?utf-8?B?Z1V5WDczTFZQbVRQYVhrMXEySDRUUlBlbmRwaFUvbUYvYjFQMkJobDlXbzQ1?=
 =?utf-8?B?dVRMTjFzWmFZTDNralB6blNKaXlGQzdhcVNIL011ZlJBV2lqb2FsQkYrelpv?=
 =?utf-8?B?VzZaYmx2RFVISUlPUVpoYWVwUmhvbkVLM1VsN08rMTdNNVpFRTYzanQ5V29H?=
 =?utf-8?B?NTBwVW1oRDI4dHBiOWdOSXpaWWJ1aDVTaGJjTU5VRmVpMTIrRkJ1dnlmNW9r?=
 =?utf-8?B?SEl4UUU5ZC9yNFNhT2pNdWdTOTAydS9wVDdDVzEySnhqUWp1NDAxOHlQT1Uz?=
 =?utf-8?B?aVhMUldPckJBNUlkTE5iS2pzclJkU3pNVGpldVRMUFF0OXhCM1M4NjZnRVBI?=
 =?utf-8?B?SzI3QkhIbnZ3cUFuMHlyZEx4enQwekVnRFltd2J0UDFzYlZncUUrOEdBMEts?=
 =?utf-8?B?K3FKdDJNOHhLUEw1bUVtWUw3dTZRNGJJOHNObHM1MHovQlJka01KNGFRY2ln?=
 =?utf-8?Q?Mjj519O754VC/WyV6kbvVnbZgAvG+E=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VXM4Rkt2K1h2Qko3anJDSWZXa3BKcXlPeDlyT09haGw0WVNIU005Um81dUVW?=
 =?utf-8?B?eGtNY0d6Rm43Q3ZrTi9hSzEvWDlwYUwzOTJtZmNac2ljZnZPZUtORkZPSDdk?=
 =?utf-8?B?Tnk5L2hnVjA3T2tEbVZGQ01sV01tcm1TWXZ4THdoa0ppaFNnN2Zvd0R6a0V1?=
 =?utf-8?B?SHZoeVBGdU5MNHVMc0xSS09pNTFFZHEwOVloTllHZ1NzQmpPZXVIWlhyU1Zh?=
 =?utf-8?B?MW16SW4ra2hWUkJ5OFJLK1p3dzdheUgzUGxCc3UvQ2ZtdEpuYlpOU0wzT1pu?=
 =?utf-8?B?YS9CdFdVTDNrZmEwbFlVQ2M0dm4vMFdsRE1SM3AyeWlqQWV5cFZqbnQvZGxo?=
 =?utf-8?B?Z0g2d3NVbC9Ba3JYWDNWN043VytFY0hxVU9pUFBZRyswMG1FL1FPanY2dDhj?=
 =?utf-8?B?MloyNE4wMWdxLzFSUmQzWjVtVGV1ZEpydjdzbm5jOWF2SEZDeDNLeEhnVzhi?=
 =?utf-8?B?R2pnUjhRUXl2M05tU1NhU2hSSU9rbkQzOFIzMFVBbDVaZ084UlFPakFNeDJ2?=
 =?utf-8?B?Y2ZMUUtXZzBRdEVldmlpK3VYQjNlWjJldDIxM1plRjdKcFJpNFVoMTNYekJr?=
 =?utf-8?B?VWp5OWRqQmdPajRrdU1ZMjVjUnNETDE1V2lsL1ZRMXJMRGlxQ3R3aUdMRDlz?=
 =?utf-8?B?bmtZY3EwSnp2MVZ2RUpzQ2pwaDVTNHlVY1R4bWNzQVlEMjF6clNid3Q3R3Nk?=
 =?utf-8?B?SUJRUC9GQ0cyOWw0YUpLWHZNaFB3TXNkRlRDYjcrQmhINlFDWlFRazJTdEJh?=
 =?utf-8?B?UTVSRUZ5VVBpVjdrZGdxTktpa01jcFY3WFhWc21wMk9EUWZGOUN6dDRPM3U2?=
 =?utf-8?B?UTJTbGc2S2hacjA0dEhTSCtRdllZTEd1bmp4YUFlQVJva2RxOWxsR2tGKzRN?=
 =?utf-8?B?TUxYUE9tUU5SSkt4eG1tVHJ6NnhlRG5TTUZtbitpdVBFa1lmZ3MrenhXTTdo?=
 =?utf-8?B?WjNGZ0lOcng5UXVjTXpzMXJYQ1V6NVJIay9iNFQ1ZDg3ZGp3bjB2R05kY0Ux?=
 =?utf-8?B?NmRBUUpLMzRNZzVYQzcvY1hFRXl0Nm1uaXBlckE4NktibmkycjZaTUpzejJC?=
 =?utf-8?B?enR4TFJ6S3d2RDRsMUorbTVQMldZYzNUZHZPSVRzMmFkNC9vdUxzaGpodVdJ?=
 =?utf-8?B?TTFHVHovRjFSNVpUSStKRnN0bmJZRDZPWEV0UlNKd3RKcS9CNmxRM2dieUhs?=
 =?utf-8?B?MGF4QXdvTnJpakVDUjk5bHhnSHlLdGp5ZGQxcldDRWkreVozWmZicG1zSW5t?=
 =?utf-8?B?UE5LSEx3OG0vUjVlR1FTSzNnQnUvV09SUmhkSzJueGo0YmprdVI0aFFybVVo?=
 =?utf-8?B?eER0aTVFWnpDcjlZenBQREh2WGlWTlJySk5LQXl3V3p2VklBUDQrcFB3ZEtQ?=
 =?utf-8?B?T295UGc2YnZrOThkWmxYN1FMNFdQVjdmS2lVaGQrMmRzc0ZGOUlLRjBsaDdk?=
 =?utf-8?B?L3N6YnY2VDNIbUI2VDdrRlNFa0xBL0FsdzFWaGIvUEdyczBSWHVTUXhiY2JC?=
 =?utf-8?B?c0tpT0IyaVlENTRrREswSHdTNVJXamZ2VEJDMHRDVDRTejRJekdjYVJ1dmRU?=
 =?utf-8?B?SkFRMGZ5K09RdnZKb0Z2b3pna2s4blBDUUxjUU5pYUtJV0lHUU1SanpyZ2pw?=
 =?utf-8?B?QUhrWU1SUW9rNmpjNWdXQUoybVY3OE0vZEtWVnhVUll3MjNGU1MxQ3dWZTIr?=
 =?utf-8?B?N0xyY3hwUUNpU2pWSEtaTGVrWU5ZWUVZZjJHbjcxVnYwZmhQQ1VhYkNnbTZJ?=
 =?utf-8?B?amhab2JneE5ncW9veHpVT1dzamt2T1c0cEJyMjJjVXVhNU9GNm1IcUN5VFR3?=
 =?utf-8?B?QjJlM1pQZDlPbXVXamVGOC9oMzlHZUtEdmltUHpTclV6WXFnNUVRN3NsaUx0?=
 =?utf-8?B?eDI5RHJCZ2FUbklZOE5vWmtRdnEvZ3FNUGM2OHBVUkRmcjkwSktxMmQ1VDN2?=
 =?utf-8?B?UEk3Q1hHVVQ0NTZxU2VXUFkraXFZcW5hWmNYOGhxMk4yWkxHcW55dTJLelMy?=
 =?utf-8?B?UUdlN256dnFlNmk1RmR3R3hIYnQzbjRFSzB3YVdqbDhmaTJOY0VlOFppbWRP?=
 =?utf-8?B?WEtLT0RmTFNtdGw0UHJPQm02VWlDNE53USt2S1lzWXRieUZqeU5Nb3loZUtT?=
 =?utf-8?Q?WUfc=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d9404f3-f2ae-41da-a02b-08dd98181e28
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2025 03:32:30.8815
 (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: pwMq61KmuXXq4IRgZzCX9L4tCHgV+P657hGNLHOZvic8PhcFmIpuSgGl21GhcPFJZDP+lipd9HgU0/nTNNbNeA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9573

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMzAsIDIw
MjUgMTE6MTcgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4g
Q2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5k
cmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRy
aXguY29tPjsNCj4gQW50aG9ueSBQRVJBUkQgPGFudGhvbnkucGVyYXJkQHZhdGVzLnRlY2g+OyBP
cnplbCwgTWljaGFsDQo+IDxNaWNoYWwuT3J6ZWxAYW1kLmNvbT47IEp1bGllbiBHcmFsbCA8anVs
aWVuQHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHNzdGFiZWxsaW5pQGtlcm5lbC5v
cmc+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRD
SCB2MyAwMS8yMF0geGVuL3g4NjogcmVtb3ZlICJkZXBlbmRzDQo+IG9uICFQVl9TSElNX0VYQ0xV
U0lWRSINCj4NCj4gT24gMjEuMDQuMjAyNSAwOTozNywgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4g
UmVtb3ZlIGFsbCAiZGVwZW5kcyBvbiAhUFZfU0hJTV9FWENMVVNJVkUiIChhbHNvIHRoZSBmdW5j
dGlvbmFsbHkNCj4gPiBlcXVpdmFsZW50ICJpZiAhLi4uIikgaW4gS2NvbmZpZyBmaWxlLCBzaW5j
ZSBuZWdhdGl2ZSBkZXBlbmRhbmN5IHdpbGwNCj4gPiBiYWRseSBhZmZlY3QgYWxseWVzY29uZmln
Lg0KPiA+IFRoaXMgY29tbWl0IGlzIGJhc2VkIG9uICJ4ODY6IHByb3ZpZGUgYW4gaW52ZXJ0ZWQg
S2NvbmZpZyBjb250cm9sIGZvcg0KPiA+IHNoaW0tZXhjbHVzaXZlIG1vZGUiWzFdDQo+DQo+IFJl
Y2FsbCBtZSBhc2tpbmcgdG8gYXZvaWQgd29yZGluZyBsaWtlICJUaGlzIGNvbW1pdCIgaW4gY29t
bWl0IG1lc3NhZ2VzPw0KPiBBbHNvIHBlcnNvbmFsbHkgSSBjb25zaWRlciAiaXMgYmFzZWQgb24i
IGFtYmlndW91czogSXQgY291bGQgYWxzbyBtZWFuIHRoZSBvbmUgaGVyZQ0KPiBuZWVkcyB0byBn
byBvbiB0b3Agb2YgdGhhdCBvdGhlciBvbmUuIEl0J3Mgbm90IGVudGlyZWx5IGNsZWFyIHRvIG1l
IHdoYXQga2luZCBvZg0KPiAocmVsZXZhbnQpIGluZm9ybWF0aW9uIHlvdSdyZSB0cnlpbmcgdG8g
Y29udmV5IHdpdGggdGhpcyBzZW50ZW5jZS4gU3VyZWx5IHlvdSBkaWRuJ3QNCj4gcmVhbGx5IG5l
ZWQgdG8gZXZlbiBsb29rIGF0IHRoYXQgcGF0Y2ggb2YgbWluZSB0byBmaW5kIGFsbCB0aGUgIVBW
X1NISU1fRVhDTFVTSVZFOw0KPiB0aGF0J3MgYSBtYXR0ZXIgb2YgYSBzaW1wbHkgZ3JlcC4NCj4N
Cj4gPiAtLS0NCj4gPiAgeGVuL2FyY2gveDg2L0tjb25maWcgICAgICB8IDQgLS0tLQ0KPiA+ICB4
ZW4vYXJjaC94ODYvaHZtL0tjb25maWcgIHwgMSAtDQo+ID4gIHhlbi9kcml2ZXJzL3ZpZGVvL0tj
b25maWcgfCA0ICsrLS0NCj4gPiAgMyBmaWxlcyBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDcg
ZGVsZXRpb25zKC0pDQo+DQo+IFdpdGggdGhlIGNoYW5nZXMgaGVyZSwgd2hhdCBkb2VzIHRoaXMg
bWVhbiBmb3IgdGhlIGluLXRyZWUgc2hpbSBidWlsZCwgb3IgYW55IG90aGVycw0KPiB1c2luZyB4
ZW4vYXJjaC94ODYvY29uZmlncy9wdnNoaW1fZGVmY29uZmlnIGFzIHRoZSBiYXNpcz8gWW91IGFy
ZW4ndCBhbHRlcmluZyB0aGF0DQo+IGZpbGUsIHNvIEkgZXhwZWN0IHRoZSBiaW5hcnkgcHJvZHVj
ZWQgd2lsbCBjaGFuZ2Ugc2lnbmlmaWNhbnRseSAod2hlbiBpdCBzaG91bGRuJ3QsDQo+IHVubGVz
cyBleHBsaWNpdGx5IHN0YXRlZCBvdGhlcndpc2UgaW4gdGhlIGRlc2NyaXB0aW9uLCB3aGljaCBt
YXkgYmUgd2FycmFudGVkIGZvcg0KPiBTSEFET1dfUEFHSU5HKS4NCj4NCg0KWWVzLCBJJ3ZlIG1p
c3NlZCB0aGUgY2hhbmdlcyBpbiBkZWZjb25maWcNCkknbGwgZXhwbGljaXRseSBzdGF0ZSBhYm92
ZSBvcHRpb25zIGluIHhlbi9hcmNoL3g4Ni9jb25maWdzL3B2c2hpbV9kZWZjb25maWcNCg0KRm9y
IFNIQURPV19QQUdJTkcgYW5kIFRCT09ULCBtYXliZSB3ZSBzaGFsbCBhZGQgYmFjayBkZWZhdWx0
IHksIG90aGVyd2lzZSB4ODZfNjRfZGVmY29uZmlnDQp3aWxsIGNoYW5nZS4uLg0KDQo+IEphbg0K


From xen-devel-bounces@lists.xenproject.org Wed May 21 04:47:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 04:47:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991425.1375282 (Exim 4.92)
	(envelope-from )
	id 1uHbLx-0005Qf-Sp; Wed, 21 May 2025 04:46:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991425.1375282; Wed, 21 May 2025 04: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 1uHbLx-0005QY-OE; Wed, 21 May 2025 04:46:53 +0000
Received: by outflank-mailman (input) for mailman id 991425;
 Wed, 21 May 2025 04:46:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHbLw-0005Cf-L8
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 04:46:52 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9c5479cf-35fe-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 06:46:51 +0200 (CEST)
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 24B821F80D;
 Wed, 21 May 2025 04:46:49 +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 E7A9913888;
 Wed, 21 May 2025 04:46:48 +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 mMLcN7haLWiPcwAAD6G6ig
 (envelope-from ); Wed, 21 May 2025 04:46: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" 
X-Inumbo-ID: 9c5479cf-35fe-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1747802809; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=+vioX0lqVonxN27pMsCAjA7/xj/gI/V9EHfXjJsTPB0=;
	b=ocYYdf8oQlopwlTDrjqhqg3yeGr5Ut6/0Av5Bb5q10EgT8hQh/D4vDmtyrbQIvUUOTzZj+
	K9QrA4Wt65zfXGkHT+e262bRoIGtcKHNZMzr3NZzq5VeXCzTnTnxywYAHoBNn01Ctlllyw
	q/FbmHfvlr5/h2zEy1HPWI+m4Myw5pk=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1747802809; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=+vioX0lqVonxN27pMsCAjA7/xj/gI/V9EHfXjJsTPB0=;
	b=ocYYdf8oQlopwlTDrjqhqg3yeGr5Ut6/0Av5Bb5q10EgT8hQh/D4vDmtyrbQIvUUOTzZj+
	K9QrA4Wt65zfXGkHT+e262bRoIGtcKHNZMzr3NZzq5VeXCzTnTnxywYAHoBNn01Ctlllyw
	q/FbmHfvlr5/h2zEy1HPWI+m4Myw5pk=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 1/2] SUPPORT.md: add xenstore stubdom as supported
Date: Wed, 21 May 2025 06:46:33 +0200
Message-ID: <20250521044634.11361-2-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250521044634.11361-1-jgross@suse.com>
References: <20250521044634.11361-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: 0.20
X-Spamd-Result: default: False [0.20 / 50.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[9];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[]

SUPPORT.md is missing a suupport statement for Xenstore stubdom.

As SUSE is using it in production since several years now, it should
be added as "supported". This covers the PV and the PVH variant.

Signed-off-by: Juergen Gross 
---
 SUPPORT.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index e8fd0c251e..7dbb477765 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -272,6 +272,16 @@ or itself will not be regarded a security issue.
     Status: Supported
     Status, Liveupdate: Tech Preview
 
+### C xenstore stubdom PV
+
+    Status: Supported
+    Status, Liveupdate: Not implemented
+
+### C xenstore stubdom PVH
+
+    Status: Supported
+    Status, Liveupdate: Not implemented
+
 ### OCaml xenstored daemon
 
     Status: Supported
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 04:47:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 04:47:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991424.1375270 (Exim 4.92)
	(envelope-from )
	id 1uHbLu-0005Cs-Ka; Wed, 21 May 2025 04:46:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991424.1375270; Wed, 21 May 2025 04:46: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 1uHbLu-0005Cl-Hw; Wed, 21 May 2025 04:46:50 +0000
Received: by outflank-mailman (input) for mailman id 991424;
 Wed, 21 May 2025 04:46:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHbLt-0005Cf-4L
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 04:46:49 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 985c1c57-35fe-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 06:46:44 +0200 (CEST)
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 AFF1A1F80D;
 Wed, 21 May 2025 04:46:43 +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 7FF8D13888;
 Wed, 21 May 2025 04:46:43 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id wbscHrNaLWiFcwAAD6G6ig
 (envelope-from ); Wed, 21 May 2025 04:46:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 985c1c57-35fe-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1747802803; 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=4LD3xUYS24gqoaD7izcrJ/OOVTdERldPlgZ46C6o/Uw=;
	b=EXz1NM9FsC4DftFDJL9USwLAVnGKFehlINXVHTIWVsuYfvaHiC7mPSPg17neAxRzj7EecO
	odrb+Kn10DG0Ksv63nwCT8yfDkBZWQw78Rw7tnOXbibn9d+IMHV5w0RyvjEUg2ADbUbQIb
	OuAlVpGMJ8ewLJWVNeFfgfbJAk8XA+4=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=EXz1NM9F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1747802803; 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=4LD3xUYS24gqoaD7izcrJ/OOVTdERldPlgZ46C6o/Uw=;
	b=EXz1NM9FsC4DftFDJL9USwLAVnGKFehlINXVHTIWVsuYfvaHiC7mPSPg17neAxRzj7EecO
	odrb+Kn10DG0Ksv63nwCT8yfDkBZWQw78Rw7tnOXbibn9d+IMHV5w0RyvjEUg2ADbUbQIb
	OuAlVpGMJ8ewLJWVNeFfgfbJAk8XA+4=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 0/2] SUPPORT.md: update the xenstore support state
Date: Wed, 21 May 2025 06:46:32 +0200
Message-ID: <20250521044634.11361-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-2.99 / 50.00];
	BAYES_HAM(-2.98)[99.90%];
	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)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_SEVEN(0.00)[9];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from,2a07:de40:b281:106:10:150:64:167:received];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:dkim];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -2.99
X-Rspamd-Queue-Id: AFF1A1F80D
X-Spam-Level: 
X-Spam-Flag: NO

Two updates regarding C Xenstore support.

Juergen Gross (2):
  SUPPORT.md: add xenstore stubdom as supported
  SUPPORT.md: mark xenstore live update as supported

 SUPPORT.md | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 04:47:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 04:47:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991426.1375291 (Exim 4.92)
	(envelope-from )
	id 1uHbM6-0005k8-5Q; Wed, 21 May 2025 04:47:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991426.1375291; Wed, 21 May 2025 04:47: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 1uHbM6-0005k1-2k; Wed, 21 May 2025 04:47:02 +0000
Received: by outflank-mailman (input) for mailman id 991426;
 Wed, 21 May 2025 04:47:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHbM4-0005Cf-DK
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 04:47:00 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a1072965-35fe-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 06:46:58 +0200 (CEST)
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 9479621EEA;
 Wed, 21 May 2025 04:46:58 +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 5D59613888;
 Wed, 21 May 2025 04:46:58 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id JUHoFcJaLWiYcwAAD6G6ig
 (envelope-from ); Wed, 21 May 2025 04:46:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1072965-35fe-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1747802818; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=ePxzSoTo04yiio7HLCHj8Zmu3m88S4vMA+VRjoO6hVM=;
	b=kXSlypViqBzFyUdElnWHCFK4Qg8yVWfpu0eUDkunoJYCPiRF74wGLiCLgPsDRttgbPFDH3
	21m3Ak/WVvykNL4knCFPPI/mxB+XeLKjamwbcDJQKenn5+X8u0IYfRhdLG+a2nAGLl6j4J
	NqJJL40YcdKzDAnpzbjbPKOu3SQvpng=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1747802818; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=ePxzSoTo04yiio7HLCHj8Zmu3m88S4vMA+VRjoO6hVM=;
	b=kXSlypViqBzFyUdElnWHCFK4Qg8yVWfpu0eUDkunoJYCPiRF74wGLiCLgPsDRttgbPFDH3
	21m3Ak/WVvykNL4knCFPPI/mxB+XeLKjamwbcDJQKenn5+X8u0IYfRhdLG+a2nAGLl6j4J
	NqJJL40YcdKzDAnpzbjbPKOu3SQvpng=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 2/2] SUPPORT.md: mark xenstore live update as supported
Date: Wed, 21 May 2025 06:46:34 +0200
Message-ID: <20250521044634.11361-3-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250521044634.11361-1-jgross@suse.com>
References: <20250521044634.11361-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: 0.20
X-Spamd-Result: default: False [0.20 / 50.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[9];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[]

Live update of xenstored is available since Xen 4.15 and it is tested
on a regular basis since then.

Switch the live update support from "Tech Preview" to "Supported".

Signed-off-by: Juergen Gross 
---
 SUPPORT.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 7dbb477765..198dfb4229 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -270,7 +270,7 @@ or itself will not be regarded a security issue.
 ### C xenstored daemon
 
     Status: Supported
-    Status, Liveupdate: Tech Preview
+    Status, Liveupdate: Supported
 
 ### C xenstore stubdom PV
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 06:01:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 06:01:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991454.1375301 (Exim 4.92)
	(envelope-from )
	id 1uHcWB-0007kB-Fa; Wed, 21 May 2025 06:01:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991454.1375301; Wed, 21 May 2025 06: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 1uHcWB-0007k4-CP; Wed, 21 May 2025 06:01:31 +0000
Received: by outflank-mailman (input) for mailman id 991454;
 Wed, 21 May 2025 06:01:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHcWA-0007jy-G7
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 06:01:30 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0918a957-3609-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 08:01:28 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-6023cf146d3so388140a12.3
 for ; Tue, 20 May 2025 23:01:28 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac32b53sm8405916a12.64.2025.05.20.23.01.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 23:01: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" 
X-Inumbo-ID: 0918a957-3609-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747807288; x=1748412088; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Te2sl41BRq4UiezfN4tMFVEh0KPl7+0T5eL3YugtMtI=;
        b=Kz8CBAAIa4WBcMg0eraZcZXrW47WAxWHtlFL++9uqJ7/nnqBBp5bv/JZaUh3gATBY5
         y343aFhtxKA7IKhEP2vk7Bbn4pPjMDxvYzymXzwPtB2fkDIFOAfaKx8frBIqrICiTggu
         UVmAmqJaZ6Nbmra9FZRYWUviUdMsYGYtukBo/PXSuxEcD/Ty2Dt3Fr/8RFtXtaE9Bcqp
         y88JNjBwqe5dKAhlMsP3/SZOV2NDhCGNVHbcD/6jHpiqpiLCYfrlDmm77MDDrqZG2J/m
         HR9fV+N3beR1+RzRk6IkPRsodTriJZcGimaw0PSOuulwYnqNdmABoaj6b8K2gDokvKMj
         iD1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747807288; x=1748412088;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Te2sl41BRq4UiezfN4tMFVEh0KPl7+0T5eL3YugtMtI=;
        b=rtLMEGsG6rbSP73tU65+X6xuSRHq5HX0acVNi/0bi/JPI0I+nbWCDkyQcCux/gl4JP
         ApFRpLGZIAzKv/fiWp6w8HbWnDb1+K36f2vK5HbXqSiHHmveqdKc3Wh4aGFqlWYk+nSZ
         fTWvSY/vfm/CTV2UxJOH5Zc9Qvavl3ZGAHeydEmLBddWKkRXkbZaC28J4X+KkLrvQQaz
         Zw5flTif72iARgBrCwu9HNYf4/bsYPHUdo2DUF1b69Ylf4fzbZxl7vdprqvJEExnf0OP
         uzCHTIiNd7yMRaPsWZW7uA9fHqTjwm9oDo+aZnvSfayZAg9JhLJrAtu2D5IeOTMM4uPf
         x/Dg==
X-Forwarded-Encrypted: i=1; AJvYcCWCFwwOsTZeFu27XUlEJY1/JYzLXbvockroC5JpSj+rD5QuIxN38KeatnEhh53HWqA7nLeOtyboEnc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzDavHj2J2kHscBTi+2ODInZuogvnMqPaRVdZHyvqcrQ5F9N7q2
	NjNGio1b+nRRxWDM1BikXKlpAGeiu+42rN3CmiM8vGzRkNrUeDZMCIrtCawNroVrRA==
X-Gm-Gg: ASbGncuMX21TjkBwsb46IDMwMQNPXma//uTCLe1TEvz0u7G0u+/ofOTOeF/1lMqm7qx
	vc0cCR1ab8kMxBZi8VXMnrouJd5U29VCyVxTDtGH7QpwmD0MJyIB+QngUN/BtF40uI16B9lEpk/
	RGIgBlKpTW9fzhJKmIgpJfjwEKHrsbDGguAgbLZBzFXq6PM5R7v6EC3v996Zu5qG6pY1oRZ+ZRh
	tUyxgS9WlY4JsXCtZbpLzLbq1rYn1nwOwkmuMj5AMvEDxg5fu7CsAYPSmkUTkvicnX1i5U9xbzr
	Eh0Mn3c0VXOb0/h48fCK9V5X88iwOEhZMXRx7aV9sw6I8n63Sh7wtQI5fYEmJQ==
X-Google-Smtp-Source: AGHT+IECjA4FzHP6SkF5YsYa4dMsmwyb8lt71O/LEjxP1/fj24w539FHWdIfFSMD1cM1tUnPujD/DA==
X-Received: by 2002:a05:6402:13d2:b0:601:fb61:a0dc with SMTP id 4fb4d7f45d1cf-601fb61a890mr7053941a12.4.1747807287957;
        Tue, 20 May 2025 23:01:27 -0700 (PDT)
Message-ID: <57036af6-3841-4676-968d-c3e318e5daa5@suse.com>
Date: Wed, 21 May 2025 08:01:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/domain: introduce non-x86 hardware emulation
 flags
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250516022855.1146121-1-dmukhin@ford.com>
 <20250516022855.1146121-2-dmukhin@ford.com>
  
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.05.2025 23:39, dmkhn@proton.me wrote:
> On Tue, May 20, 2025 at 05:21:06PM +0200, Jan Beulich wrote:
>> On 16.05.2025 04:29, dmkhn@proton.me wrote:
>>> From: Denis Mukhin 
>>>
>>> Define per-architecture emulation_flags for configuring domain emulation
>>> features.
>>>
>>> Print d->arch.emulation_flags from 'q' keyhandler for better traceability
>>> while debugging.
>>>
>>> Signed-off-by: Denis Mukhin 
>>> ---
>>> Changes since v1:
>>> - dropped comments
>>> ---
>>>  xen/arch/arm/include/asm/domain.h   | 1 +
>>>  xen/arch/ppc/include/asm/domain.h   | 1 +
>>>  xen/arch/riscv/include/asm/domain.h | 1 +
>>>  xen/common/keyhandler.c             | 1 +
>>>  4 files changed, 4 insertions(+)
>>
>> If every arch gains identical fields, accessed from common code, why would
>> those need to live in struct arch_domain?
> 
> I did it this way to keep the diff smaller, but I agree such property
> makes sense to put in common domain struct. Will update in v3.

Provided there's arch maintainer buy-off on generalizing this. There's (at
least) a 3rd option, after all: Have arch-specific and (separate) common
emulation flags.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 06:05:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 06:05:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991465.1375311 (Exim 4.92)
	(envelope-from )
	id 1uHcZa-0008HX-TR; Wed, 21 May 2025 06:05:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991465.1375311; Wed, 21 May 2025 06: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 1uHcZa-0008HQ-Ql; Wed, 21 May 2025 06:05:02 +0000
Received: by outflank-mailman (input) for mailman id 991465;
 Wed, 21 May 2025 06:05:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHcZZ-0008Gm-EP
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 06:05:01 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 872e3d27-3609-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 08:05:00 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-601c5cd15ecso4879809a12.2
 for ; Tue, 20 May 2025 23:05:00 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d06cdccsm843600266b.49.2025.05.20.23.04.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 23:04: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" 
X-Inumbo-ID: 872e3d27-3609-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747807499; x=1748412299; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=9ewkitm98K2wNUZmIq0ZfhmbqJLXphXXgqlFxhxwGMc=;
        b=Y8LaYoWhth7/9Sft/Va6KtLhNwi3ui66jpmvrS6eXF1zAx2Mc2UFFCmPLvG8KCIE6z
         pDaTlk45YgqTZ8q4enn38z5lVXetbebaS/saUWRp0zOTVD7zrKIg9YgAKsmHKrllcvh1
         F/y1aXFGyyBP/9PHPznSJZ6GL7QWA4wNYWKHPhpTj6iYsAp3TrLXewDbrQc15URSFvmb
         XVxcMIExI0QdgnvUmySBv0U0TTjtmQa82Qfgn3MnAMyb71xM7mo84ZY3HAMwop5wvo2N
         GXKyZFM1ifZx0HWvYMpkmBte1KiBltR7OZOtQDUUaO2qz4yW1Bf4Usl1X/woHYs2PCmO
         IVlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747807499; x=1748412299;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=9ewkitm98K2wNUZmIq0ZfhmbqJLXphXXgqlFxhxwGMc=;
        b=mlMc+5dYBjI0TyveUI3j0cZ3rRNkcGn6W/3k7Xb2zokkIWRl5XcoQecTiW92C7/jy0
         zO52dYzTlfisF3Donrs0hz8Os66Rs15jn8akfpCN020F+B91KJOur0tLXVwfWZzbWF9b
         QFXMRTQF2PF8uti0SVfp9zNf/E62yAW5Qk0vi8xwTJygfIm0lVt7NbsmgQmD/P9sJGDd
         uI+DwrE+/it2Rsim+1ainhpr6mBHuvfkz/Np/JcDovuwZqyqcCZ71tXfvy7BpgGkS3c+
         UGrHr0vyofPOMRdBcfqgQFJwzdfBqWbcbfGA4pmbXfB3gQ8pVsF7/Hy56p19vHrIEDEd
         EkfA==
X-Forwarded-Encrypted: i=1; AJvYcCWXgCSo09OfdlxI/SPLWx2dGVohazQnLG7YvbrpDSzvEsvPe2uVG9p0MwO++v9aaaJE39uUHPnyHv4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxlnT+BVG0cOQ2s1UwkGMc6ss/2qoIGwIL8tZUcUSgOGccfgXZZ
	qsMT/0MW1ZVvSK8UJH54RaLy4/bsL94SdQjefJkysYhbva00gGSnAiptCFwNDp4N5Q==
X-Gm-Gg: ASbGncsYTRn3F2PR4caj5arfis2SDgjxom/APi9feVcbalwLbJeJJpK2WNTfbmM4VeL
	kt4h9bs78N31D89D1+Yle60S6EjEwu1lzgFTWGLhJMEH0CL+lwIfAqVyEtdGS/Ro0jpVHUAOYA+
	pckHi1q8H6zHkvV9RWtq4W4Au1Clv87ohjjhR9yYWrUerexnIJ3z30Oi+3HGQtWZuhmziFYwsSw
	jXwoj0GVzMv0EGNF2oAaPthoXOQpTJa9uCn2c1Mc6LTX3vZVo2jUauC9n8VVdSzh0ddYD4KRxxz
	9nzrC4DOLI8SwEdmbp17D/wJ/AcbcmzhLMTvH/6pzlHkBuuCEeqzBAoPOzMQAA==
X-Google-Smtp-Source: AGHT+IERwyLfTkb05uKGZMTfyZODXRLkgUsgHh6Apll9eHLyl7NpTYk8hea9RAt820KGnLN+Uvr7oA==
X-Received: by 2002:a17:906:34d1:b0:ad5:1db5:6ec0 with SMTP id a640c23a62f3a-ad536b7c4c8mr1439908366b.20.1747807499480;
        Tue, 20 May 2025 23:04:59 -0700 (PDT)
Message-ID: 
Date: Wed, 21 May 2025 08:04:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/domain: rewrite emulation_flags_ok()
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250516022855.1146121-1-dmukhin@ford.com>
 <20250516022855.1146121-3-dmukhin@ford.com>
  
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 00:38, dmkhn@proton.me wrote:
> On Tue, May 20, 2025 at 05:24:33PM +0200, Jan Beulich wrote:
>> On 16.05.2025 04:29, dmkhn@proton.me wrote:
>>> --- a/xen/arch/x86/include/asm/domain.h
>>> +++ b/xen/arch/x86/include/asm/domain.h
>>> @@ -494,6 +494,12 @@ struct arch_domain
>>>                                   X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
>>>                                   X86_EMU_VPCI)
>>>
>>> +/* User-selectable features. */
>>> +#define X86_EMU_OPTIONAL        (X86_EMU_USE_PIRQ)
>>> +
>>> +#define X86_EMU_BASELINE        (X86_EMU_ALL & ~(X86_EMU_VPCI | \
>>> +                                                 X86_EMU_OPTIONAL))
>>
>> That is, VPCI is neither baseline nor optional. Certainly at least strange.
> 
> IMO, X86_EMU_OPTIONAL should include both VPCI and PIRQ.
> 
> But that will be a behavior change: AFAIU, VPCI is injected implicitly for dom0
> case only, "default" xl toolstack currently excludes VPCI for HVM domains.
> 
> Do I understand it correctly that "BASELINE" in the symbol name is a concern?

It's not the word by itself. _If_ we want to have such symbols (which I had put
under question before), they need to be named to accurately reflect the purpose.
Imo with the names chosen an implication is that the two are non-overlapping,
while when combined yield the full set of flags.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 06:08:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 06:08:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991475.1375321 (Exim 4.92)
	(envelope-from )
	id 1uHccj-0000PG-C9; Wed, 21 May 2025 06:08:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991475.1375321; Wed, 21 May 2025 06:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHccj-0000P9-7j; Wed, 21 May 2025 06:08:17 +0000
Received: by outflank-mailman (input) for mailman id 991475;
 Wed, 21 May 2025 06:08:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHcci-0000Ok-0s
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 06:08:16 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20625.outbound.protection.outlook.com
 [2a01:111:f403:2416::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fa726e9f-3609-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 08:08:13 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DS0PR12MB9039.namprd12.prod.outlook.com (2603:10b6:8:de::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.33; Wed, 21 May
 2025 06:08:09 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Wed, 21 May 2025
 06:08: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" 
X-Inumbo-ID: fa726e9f-3609-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=j+ZN2O59wp83OaQLsIEVd9Rv1uaibBykjHuj5G8p2wdTEMZPFtshnAiTGdiTcNMQK32JxE6cfC6xUjJ9MHPdL9kTRiVlmg0BvsCCiqwaYf6xHB/f/cRCPvTpCLqW5aaNChm0y0f4XxdgDpomgYCpXMeGl0fzh02JmQUHXevZt+HoKyOM00omhIv3YIjWjHIzoPYDHKQZO4EQyW2z9EbE/l6p2WmrAdwZozUE9a2otQ4JOhkETzVqtfhAOBn0wtcK6OJYCAL3LsQZ8ikyYyW466Z7mte/XrHmsTyyLsd4yTsPK4SuNTXEq1BaUDtn9vdhbcEy5+BEjoFjLScZpMzSiA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6WuRcDIk3zF5y1XhTwOra9wRMAmikeC5dlcFz4anZRU=;
 b=Vwun8jLhS7a441X0NEOb9E1PkD0TrigjUVlUgOoUjWVhU9PZB/R3TDuj6zoh0LnGhGW+LIvc8RQi0QSjeRhlIgFIE78ZzMFUr+dc6zEOvarKeHBav2zyBwOlctsXbX751FBFZv/eFc277M7y5rdZhkPo6EN3s7htV8S2mtRVC7y31V0ufkrZczgCJdFesDr+xjtFuuBIwslMDYON8PkZcXD9IetCv1Dg3BtZ4WV0jjLqbv6UDF9CZZn7LrLPA9E9DR/KfKzs9RbTNug22xp8R8RP/z3DTYyKJKwmyxRgayjGWEyoNIDRH0G1NWgmokrLYLDQXz055VV/9v9vpb156Q==
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=6WuRcDIk3zF5y1XhTwOra9wRMAmikeC5dlcFz4anZRU=;
 b=VC9/cAdAxoNtgqjlQELNsqGjgQk7W0L6EUNVaONHBETZ4tp2MI+pljq/DGTHQj+ms6je1nRAE/YdxZrJFBPxrw+SEIYoXV7j2wO3WjNgvBFVbtrPHdH0niJP8+g9H1cYunCr0NYlIxB4mRuf6eVXVhXxpD4JRZc57S5VIez67F4=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Jan Beulich
	
CC: "Chen, Jiqian" , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" 
Subject: Re: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
Thread-Topic: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
Thread-Index:
 AQHbwMGevTfR886wakahq6ntIeNmMrPYfnSAgAGVuQD//4B5gIAAiU8A///fQoCAAAM5gIADLxQA
Date: Wed, 21 May 2025 06:08:08 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-4-Jiqian.Chen@amd.com>
 
 
 
 
 <20d48f86-d7fe-47c8-89ab-61d816e1d6e9@suse.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|DS0PR12MB9039:EE_
x-ms-office365-filtering-correlation-id: aece10c6-cf8a-4b0e-4e2c-08dd982ddbcf
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?dnQrMXhUR0pHc2tXalBuMlRtMGwxNXphbnpBYTFsM3VIZG9OSkhvZHh0QVl5?=
 =?utf-8?B?cVEwc2tTYU0zR1hncUl2Y3NBSXo1NmVqam9qeHhqakpjamZMNGViQUg5b0FO?=
 =?utf-8?B?VmRmZlJTVUUrVTA5LzNadHIya3BNZlBJQjFkdldXZlk5ZWxKNjErZmV6eld2?=
 =?utf-8?B?SjFUbXoxSmdYMTI1NHdnSTZESUlpanhZRnJhaDlGclhYYzAzR0RxdHhJVXYw?=
 =?utf-8?B?RDBmeDFiR2R2Rjc4N29pbHBnWGJPaHI1TnRlc1Z6UHQ5QnAzaURFemcxWkZN?=
 =?utf-8?B?U1pPYXFUZVJFU1dXT1N0MnpIWVdzZ2MxZ2hIdzRtcG53REQ4WjdOaW1zMTFT?=
 =?utf-8?B?bStJL1Q4V2dURjZ3WkdHeS9VS1RsOFgrajF3MFdYaU5qQ0RBcE9hTGxuRUFQ?=
 =?utf-8?B?cVdFUURoN0hiOFZSN3lnNFEvVGorVU9aOWc5azdyeUJQby9uV1BITGU3c1N3?=
 =?utf-8?B?TDNGSzdJS3d4YkZ0N1p6Z1RScXlRV0NUMDBmQ25VRjRUbVZPWGYzdUxCK3Jy?=
 =?utf-8?B?QWd2QmtUazVRaFpCWHlmTk5iMFg2Y3Qxbk1aQi9uNTNjVmtrM0NtLzhUbHZ4?=
 =?utf-8?B?RlR1U295N09kV0t1TUdCYmlPbDM5TGZSUzhzUWZqcG5ZVlJNZ09TQTJlUWlK?=
 =?utf-8?B?ZllBc3UyemUydVArMndzOHhsd3Jqa0ExTjVCMGErME05R2ZKUllzcE1rUGFU?=
 =?utf-8?B?dnJrTTBYOWFLeklWZ3NrNFpZUkpHbXZrOXBjUUN5dEhpVEE2SWtIWFE2UlA2?=
 =?utf-8?B?akdPc2RYWk5MY1I4Y0hEVUtBRlJObFhEeGVrRWhXdzJ0ejkvY1dST2VPaUdE?=
 =?utf-8?B?aWlQbkpqTGZDbWNrY3ViL2tyTUh3UGdidTBYYytoNXdadEhYLzBIK3VqUjhq?=
 =?utf-8?B?a0hmYXhkMU5SVm5NVUNVWFZSZWR2dlRtNUw4NFU2aS9TdVFXU2I2Ykg4cVQ1?=
 =?utf-8?B?T0plK2tMRDJmeWFSRHBRNlNYS09FdnFTUFdqcHJNRmdvR2JvRjl2VmdxNi9a?=
 =?utf-8?B?dGh6N21pc2lZYWxxQUhuMXVXOG9rSXh6QzUyMzZTUW5ScTNDaXY0Z2k1Z0ZT?=
 =?utf-8?B?ZmRSRW16Y3hrL0E1OHYrY25haUdoL0k3OGlXSGFSZTJLVXZaaUlCaytuRElF?=
 =?utf-8?B?TDJkYWNISHFDL0tLVjBwZWpTZWpWcWJYbGwrK2JqbGFKVXhCTDQyczVGZy9M?=
 =?utf-8?B?d3o1WTFiK00rK1pyaGY4WjBnRGcyL1AzTDhuSXRuRFZEdExNQ01tOG5aV2M3?=
 =?utf-8?B?YU0xOGdiRk9XaUl4b0FHRGpsT0VKTlQvbjBwaEFOMVJNMDFFMVRydktBUXQy?=
 =?utf-8?B?cVJBb2xCdzBaZGxBZy9HRHFadkEvZlBuSmhsQ2xjM2ZiZGljcnpSbWx1M2Zz?=
 =?utf-8?B?SFdMbWR5OWdnMDlJbDV0bityY2Fha2RPcmpCUTJWUVBMeHMvQW1ad0VjL1gv?=
 =?utf-8?B?QTlaeHJ5SUJXZXRNM3B2RC85eEtSSE1abjZWbGU1RkF3K1NudE83V3JPQldv?=
 =?utf-8?B?TjJiVW5qTmw2bUxucmV0L3VkWWdBK1gxVkZVdTZicHg2Qk85bC9WSGJBdTZW?=
 =?utf-8?B?SlB2TGxnckxYM0xnSzZCRDF4SkVUcHh1NjBUTE1rV1pEWVljTkhIWEJhVDRt?=
 =?utf-8?B?TFZQQ3V0SVI5QjBlaTFMM0JrMjRFWmwwbWZSYWZWM1c2dXMyMXJzcmExZThM?=
 =?utf-8?B?WVNVNFpHYTRYRXlmUjhLNHRsUkFCOGpiYlowU29peHBFd3d6ejJtL1YrOUZ3?=
 =?utf-8?B?K0dXUDRYZmcwcnVaL3Z4VWllM0lZK1QxM2hhaDl2anUvNzJwUFRQeDV4czVF?=
 =?utf-8?B?WVVwYi83cmpvNUtsSlFPeEU0WUMxb0hJdDROZkljc3cyZEFlOGlDRXpsanp6?=
 =?utf-8?B?Y2tBaWNCQWZMZmlFa2ZFZ1hQSzh4b2swRStqZHhCYThzcG5qdDVQZlh6YjhO?=
 =?utf-8?B?aGpHV2Faa3BSdmNzNm1XNkcyRyszZVZvTSswTGNDSStUSkNEL3hVUFhpYXph?=
 =?utf-8?B?QlhUSWFoNEFBPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VXNqLzB6VVNFRHdOSW1sTFhKdnZEWURKYVphTm4rZGtCRGpCaDVXZm0yUEVV?=
 =?utf-8?B?bk1zT1dqN0VmcGdPQnBVaGxIREpLQ1oyR1QrZUN0TjBnaDFUQnhFcjYyWXo0?=
 =?utf-8?B?MU1BWXBDRG9KZFVNbk5UdW9tUGhUUk80TWk5d1cwRGlwQlU2bkZQWU1saGNk?=
 =?utf-8?B?MDQxT1YzaHpLNnF3M2RyYWxuQ1ZId3ZQNzVXUkZ3V25qcThsME51d1BnTEVK?=
 =?utf-8?B?cVhRbHAwUW96c2hkYkw4Um5EL2RRODBEZTNsOXM5UjlIWk80Y1NhRVlrb1Jl?=
 =?utf-8?B?cC9NME9sNzZxK1NERUovZ2lNbEpwem9wVndTR0hiU0xLUzczdy90T2hGM1pI?=
 =?utf-8?B?eGF1S05EVDFCelljSXZUb3hHQTJIOFBWVDIyRVJmS0VIejVMSEZFK09JRGdX?=
 =?utf-8?B?VWIyZUZWbDlFdDRCWEJwcUdXMVZXNUNSbWdZR3Z0YjVwcWVxbU5PaElJYmJ6?=
 =?utf-8?B?bTFJQTd0RFV5akhlSXVkbVdSN25RS3dNZEYxV0VONXZ0UmNIQ1FaTkgzdVpp?=
 =?utf-8?B?R2tIajNmK05JOEw5SGZ6ZVRhZTJrOGdaditMMUtJdy9pQ2JYRDFRWkJxaFBP?=
 =?utf-8?B?ZE9NR3dMbDh4RjZSVDVsUXgxdUJNYkZyWXlxWm5zNHNRa2ZlVktIYzNGd3Ax?=
 =?utf-8?B?UVVCZllQVGUrZUFjZnVPa1ltYTVWdDNpc2NYOTh4dlg5L1IxMGpmOWluS0FO?=
 =?utf-8?B?TUFBcmdpUEhCbWQ5Yytjang3NXJneXkvY2tKd2c1VnFDS3h5bFR6MUJNNGts?=
 =?utf-8?B?R0s1VFU5RHdWN1FicEdTOEJpdUVXQXhRRVc1VEpkcHBFQzhXVmRJU3NhQldn?=
 =?utf-8?B?Sy9jaDZpZElEL3c4cHJSY0QvcW9ZV2FBdXhyM0NDY2ZrYXVsbThHcjBFNGtx?=
 =?utf-8?B?RStFNEhoL1hoZjB5aVFMS2Y3Ykx4aExMTUYyTVIvK201V0dLTjBqZnJVZm03?=
 =?utf-8?B?eDdDQ0hKemZmWVJZQ0xpMEhtcWthQkFQUGc3ZGVITnBXM21RaVkzVFJOTXkw?=
 =?utf-8?B?cGh3RGI5WVBjU0xUeUlxS0FiYklkeTd1aU01ZWJ3WnhTSExtN29EVEM4dEVC?=
 =?utf-8?B?RU1BL2tuZHNJeWx1RkQ1d1h4b0V4Qmc4ZUlHdTdEcVRXT2VrVGMxZ29HY2Jo?=
 =?utf-8?B?MURuMWdnY044Nm1XMXQvYXVqd2t0TVh2M0VsZ3hrK04ySFpjZmJnaGpNYktj?=
 =?utf-8?B?V1ViZ0JlM3NXd3ZIaTB2WjRibHRQQ3ZiaFZOeEhNaDR5dGRtR3N3WTNOZy9k?=
 =?utf-8?B?UjNNdEJvN0d1R1MyczJRK243ZUk5dWZDVStDUjMxTjcrWWJySW5kalZHejBM?=
 =?utf-8?B?UVI1ZnQvSUQ0RE9xV2h4YmliazZiZnRBc1lBcGU0MC9OZEJJUnFhWkVBYWpt?=
 =?utf-8?B?eERqZzB4UFNZbEltMzlKQnoxbGdBT01nNGxsc2w0blZ6VFlqaU5paldVTzdD?=
 =?utf-8?B?VW4ySTl6UVFDTUl1bHA3MUlUcDNydGtGRHo5YjdxRWN1U2IrbUVQakxzc2ZR?=
 =?utf-8?B?TGt4RXIwd2JiaktmWlZGdWdvUWtYTjJzekMyVm01TlFuWXllUjdDS2Z1MEN5?=
 =?utf-8?B?MzlsNEhvakNkbGdvN1FxeTBQNmt4OGhiSmlxUnBuYUdrU0FENnFVbWVUd2J5?=
 =?utf-8?B?blp2WDk2eGZ5R0hNRXBCcTlNenJCRTNVcG1qcFpBN3RNUGdGTUova1VRWloz?=
 =?utf-8?B?MTQ4V1Mva2dHUy80Z0o4aFhXSlVRVWttYzFxM2R0SGpFQ1ZNeFFGdVB3RVZ5?=
 =?utf-8?B?c1FCOC9VRnY4S0o2NlVtelFFR0krVlp3TmxWRHhZcGJnMVdwamNSdkxCRlNp?=
 =?utf-8?B?WFpLMUc4clZGeFNpaENROHJ0WXBlSFEvb0FrMGJiVmFNLzk3VXJ4OGhoMGlG?=
 =?utf-8?B?ejY1ak83eFFQTXhNZzMvRUppb0RKRjY2VHZsRnJFYWpzeUVyNE1tazFYN05J?=
 =?utf-8?B?NllNd3hvOUlrVEJQZDRxeUk0MWZmbkYwOTA3NXdheUVzbHNFNGxVUzY3UDEz?=
 =?utf-8?B?ZlBrWGZ3TGQzQU1LbDNTVk1ybVBLK1drdGRYQTNZYmV1Mk9RRC9VSVlQcFVF?=
 =?utf-8?B?alNjczZrUjkzN0xoR0VHeGhieEhXRXR4UGo1SDY4RnRhUklVVmZBY0pEVGNr?=
 =?utf-8?Q?PoUE=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aece10c6-cf8a-4b0e-4e2c-08dd982ddbcf
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2025 06:08:08.4669
 (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: 16s2/vkQnGgyISC/m6NGgYs3BCMnbBeSZ09DuhuTA3SXspYcErRSJlLCfA911NVVc+ZevA1b4jP58Ikxq4OiNQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9039

T24gMjAyNS81LzE5IDIxOjIxLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPiBPbiBNb24sIE1h
eSAxOSwgMjAyNSBhdCAwMzoxMDoxN1BNICswMjAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+IE9u
IDE5LjA1LjIwMjUgMDk6MTMsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+PiBPbiAyMDI1LzUvMTkg
MTQ6NTYsIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+PiBPbiAxOS4wNS4yMDI1IDA4OjQzLCBDaGVu
LCBKaXFpYW4gd3JvdGU6DQo+Pj4+PiBPbiAyMDI1LzUvMTggMjI6MjAsIEphbiBCZXVsaWNoIHdy
b3RlOg0KPj4+Pj4+IE9uIDA5LjA1LjIwMjUgMTE6MDUsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4+
Pj4+PiBAQCAtODI3LDYgKzgyNywzNCBAQCBzdGF0aWMgaW50IHZwY2lfaW5pdF9jYXBhYmlsaXR5
X2xpc3Qoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUENJX1NUQVRVU19SU1ZEWl9NQVNLKTsNCj4+
Pj4+Pj4gIH0NCj4+Pj4+Pj4gIA0KPj4+Pj4+PiArc3RhdGljIGludCB2cGNpX2luaXRfZXh0X2Nh
cGFiaWxpdHlfbGlzdChzdHJ1Y3QgcGNpX2RldiAqcGRldikNCj4+Pj4+Pj4gK3sNCj4+Pj4+Pj4g
KyAgICB1bnNpZ25lZCBpbnQgcG9zID0gUENJX0NGR19TUEFDRV9TSVpFLCB0dGwgPSA0ODA7DQo+
Pj4+Pj4NCj4+Pj4+PiBUaGUgdHRsIHZhbHVlIGV4aXN0cyAoaW4gdGhlIGZ1bmN0aW9uIHlvdSB0
b29rIGl0IGZyb20pIHRvIG1ha2Ugc3VyZQ0KPj4+Pj4+IHRoZSBsb29wIGJlbG93IGV2ZW50dWFs
bHkgZW5kcy4gVGhhdCBpcywgdG8gYmUgYWJsZSB0byBraW5kIG9mDQo+Pj4+Pj4gZ3JhY2VmdWxs
eSBkZWFsIHdpdGggbG9vcHMgaW4gdGhlIGxpbmtlZCBsaXN0LiBTdWNoIGxvb3BzLCBob3dldmVy
LA0KPj4+Pj4+IHdvdWxkIC4uLg0KPj4+Pj4+DQo+Pj4+Pj4+ICsgICAgaWYgKCAhaXNfaGFyZHdh
cmVfZG9tYWluKHBkZXYtPmRvbWFpbikgKQ0KPj4+Pj4+PiArICAgICAgICAvKiBFeHRlbmRlZCBj
YXBhYmlsaXRpZXMgcmVhZCBhcyB6ZXJvLCB3cml0ZSBpZ25vcmUgZm9yIGd1ZXN0ICovDQo+Pj4+
Pj4+ICsgICAgICAgIHJldHVybiB2cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2cGNpX3Jl
YWRfdmFsLCBOVUxMLA0KPj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
cG9zLCA0LCAodm9pZCAqKTApOw0KPj4+Pj4+PiArDQo+Pj4+Pj4+ICsgICAgd2hpbGUgKCBwb3Mg
Pj0gUENJX0NGR19TUEFDRV9TSVpFICYmIHR0bC0tICkNCj4+Pj4+Pj4gKyAgICB7DQo+Pj4+Pj4+
ICsgICAgICAgIHVpbnQzMl90IGhlYWRlciA9IHBjaV9jb25mX3JlYWQzMihwZGV2LT5zYmRmLCBw
b3MpOw0KPj4+Pj4+PiArICAgICAgICBpbnQgcmM7DQo+Pj4+Pj4+ICsNCj4+Pj4+Pj4gKyAgICAg
ICAgaWYgKCAhaGVhZGVyICkNCj4+Pj4+Pj4gKyAgICAgICAgICAgIHJldHVybiAwOw0KPj4+Pj4+
PiArDQo+Pj4+Pj4+ICsgICAgICAgIHJjID0gdnBjaV9hZGRfcmVnaXN0ZXIocGRldi0+dnBjaSwg
dnBjaV9yZWFkX3ZhbCwgdnBjaV9od193cml0ZTMyLA0KPj4+Pj4+PiArICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHBvcywgNCwgKHZvaWQgKikodWludHB0cl90KWhlYWRlcik7DQo+Pj4+
Pj4NCj4+Pj4+PiAuLi4gbWVhbiB3ZSBtYXkgaW52b2tlIHRoaXMgdHdpY2UgZm9yIHRoZSBzYW1l
IGNhcGFiaWxpdHkuIFN1Y2gNCj4+Pj4+PiBhIHNlY29uZGFyeSBpbnZvY2F0aW9uIHdvdWxkIGZh
aWwgd2l0aCAtRUVYSVNULCBjYXVzaW5nIGRldmljZSBpbml0DQo+Pj4+Pj4gdG8gZmFpbCBhbHRv
Z2V0aGVyLiBXaGljaCBpcyBraW5kIG9mIGFnYWluc3Qgb3VyIGFpbSBvZiBleHBvc2luZw0KPj4+
Pj4+IChpbiBhIGNvbnRyb2xsZWQgbWFubmVyKSBhcyBtdWNoIG9mIHRoZSBQQ0kgaGFyZHdhcmUg
YXMgcG9zc2libGUuDQo+Pj4+PiBNYXkgSSBrbm93IHdoYXQgc2l0dWF0aW9uIHRoYXQgY2FuIG1h
a2UgdGhpcyB0d2ljZSBmb3Igb25lIGNhcGFiaWxpdHkgd2hlbiBpbml0aWFsaXphdGlvbj8NCj4+
Pj4+IERvZXMgaGFyZHdhcmUgY2FwYWJpbGl0eSBsaXN0IGhhdmUgYSBjeWNsZT8NCj4+Pj4NCj4+
Pj4gQW55IG9mIHRoaXMgaXMgdG8gd29yayBhcm91bmQgZmxhd2VkIGhhcmR3YXJlLCBJIHN1cHBv
c2UuDQo+Pj4+DQo+Pj4+Pj4gSW1vIHdlIG91Z2h0IHRvIGJlIHVzaW5nIGEgYml0bWFwIHRvIGRl
dGVjdCB0aGUgc2l0dWF0aW9uIGVhcmxpZXINCj4+Pj4+PiBhbmQgaGVuY2UgdG8gYmUgYWJsZSB0
byBhdm9pZCByZWR1bmRhbnQgcmVnaXN0ZXIgYWRkaXRpb24uIFRob3VnaHRzPw0KPj4+Pj4gQ2Fu
IHdlIGp1c3QgbGV0IGl0IGdvIGZvcndhcmQgYW5kIGNvbnRpbnVlIHRvIGFkZCByZWdpc3RlciBm
b3IgbmV4dCBjYXBhYmlsaXR5IHdoZW4gcmMgPT0gLUVYSVNULCBpbnN0ZWFkIG9mIHJldHVybmlu
ZyBlcnJvciA/DQo+Pj4+DQo+Pj4+IFBvc3NpYmxlLCBidXQgZmVlbHMgd3JvbmcuDQo+Pj4gSG93
IGFib3V0IHdoZW4gRVhJU1QsIHNldHRpbmcgdGhlIG5leHQgYml0cyBvZiBwcmV2aW91cyBleHRl
bmRlZCBjYXBhYmlsaXR5IHRvIGJlIHplcm8gYW5kIHJldHVybiAwPyBUaGVuIHdlIGJyZWFrIHRo
ZSBjeWNsZS4NCj4+DQo+PiBIbW0uIEFnYWluIGFuIG9wdGlvbiwgeWV0IGFnYWluIEknbSBub3Qg
Y2VydGFpbi4gQnV0IHRoYXQncyBwZXJoYXBzIGp1c3QNCj4+IG1lLCBhbmQgUm9nZXIgbWF5IGJl
IGZpbmUgd2l0aCBpdC4gSU9XIHdlIG1pZ2h0IGFzIHdlbGwgc3RhcnQgb3V0IHRoaXMgd2F5LA0K
Pj4gYW5kIGFkanVzdCBpZiAoZXZlcikgYW4gaXNzdWUgd2l0aCBhIHJlYWwgZGV2aWNlIGlzIGZv
dW5kLg0KPiANCj4gUmV0dXJuaW5nIC1FRVhJU1QgbWlnaHQgYmUgZmluZSwgYnV0IGF0IHRoYXQg
cG9pbnQgdGhlcmUncyBubyBmdXJ0aGVyDQo+IGNhcGFiaWxpdHkgdG8gcHJvY2Vzcy4gIFRoZXJl
J3MgYSBsb29wIGluIHRoZSBsaW5rZWQgY2FwYWJpbGl0eSBsaXN0LA0KPiBhbmQgd2Ugc2hvdWxk
IGp1c3QgZXhpdC4gIFRoZXJlIG5lZWRzIHRvIGJlIGEgd2FybmluZyBpbiB0aGlzIGNhc2UsDQo+
IGFuZCBzaW5jZSB0aGlzIGlzIGZvciB0aGUgaGFyZHdhcmUgZG9tYWluIG9ubHkgaXQgc2hvdWxk
bid0IGJlIGZhdGFsLg0KPiANCklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIEkgbmVlZCB0byBh
ZGQgYmVsb3cgaW4gbmV4dCB2ZXJzaW9uPw0KDQogICAgICAgICByYyA9IHZwY2lfYWRkX3JlZ2lz
dGVyKHBkZXYtPnZwY2ksIHZwY2lfcmVhZF92YWwsIHZwY2lfaHdfd3JpdGUzMiwNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcG9zLCA0LCAodm9pZCAqKSh1aW50cHRyX3QpaGVhZGVy
KTsNCisNCisgICAgICAgIGlmICggcmMgPT0gLUVFWElTVCApDQorICAgICAgICB7DQorICAgICAg
ICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HDQorICAgICAgICAgICAgICAgICAgICIlcGQgJXBw
OiB0aGVyZSBpcyBhIGxvb3AgaW4gdGhlIGxpbmtlZCBjYXBhYmlsaXR5IGxpc3RcbiIsDQorICAg
ICAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNiZGYpOw0KKyAgICAgICAgICAg
IHJldHVybiAwOw0KKyAgICAgICAgfQ0KKw0KICAgICAgICAgaWYgKCByYyApDQogICAgICAgICAg
ICAgcmV0dXJuIHJjOw0KDQo+IElmIGl0IHdhcyBmb3IgZG9tVXMgd2Ugd291bGQgcG9zc2libHkg
bmVlZCB0byBkaXNjdXNzIHdoZXRoZXINCj4gYXNzaWduaW5nIHRoZSBkZXZpY2Ugc2hvdWxkIGZh
aWwgaWYgYSBjYXBhYmlsaXR5IGxpbmtlZCBsaXN0IGxvb3AgaXMNCj4gZm91bmQuDQo+IA0KPiBU
aGFua3MsIFJvZ2VyLg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Wed May 21 06:25:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 06:25:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991493.1375331 (Exim 4.92)
	(envelope-from )
	id 1uHctB-0003EZ-RW; Wed, 21 May 2025 06:25:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991493.1375331; Wed, 21 May 2025 06:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHctB-0003ES-OJ; Wed, 21 May 2025 06:25:17 +0000
Received: by outflank-mailman (input) for mailman id 991493;
 Wed, 21 May 2025 06:25:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHctA-0003EM-H3
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 06:25:16 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5b6c9ded-360c-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 08:25:15 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-601a9e65228so1573730a12.2
 for ; Tue, 20 May 2025 23:25:15 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004550358asm8625437a12.0.2025.05.20.23.25.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 23:25:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5b6c9ded-360c-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747808714; x=1748413514; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=+G2FemtRri8XxdnSu4MvLGBgUKayZGtMV0PcDdUkTgY=;
        b=BP38GR9wD4aUdidAqBnrMW2vKb6Yd2wVS8gi4JAlB6LXEQEGRohgY1H8y//UGchyoe
         r2Fv/hTrdCQ6+1dKq9uF2/ti75WdJEYfcIZuLLsMMu9E/nqbp5UU7RtiJJU0/nZvjmS7
         qZPDLzxuaWKGRRK6tz0nGjphwEUlQ3sfWqn0JlWU1g9a6y+iK33YMbrZmFWTb8w6VkE2
         wf7or1RhCfsSJcaLk3dOhanh8G5qe8XX5LfIc2gKqpE1MnIZPvLijh+zYfzTfv70046p
         KPv9C1fjKm8xRTdcuXASioa3qbXOc8DkaJbNKkWfqzydeWyUjR2WlDvC5G+03CmbqOmL
         sq2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747808714; x=1748413514;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=+G2FemtRri8XxdnSu4MvLGBgUKayZGtMV0PcDdUkTgY=;
        b=PRttQSdclFxn/DUwJS9jHY4pgXu1/6fVhs1MH2tAtU2jlT7+DgsMJVMI5cSBE2Gf7s
         oMgtZjrdgebiaTFUX9kw4JFfbOqn7GntTn+Hjaz8QKUdAU5ACZGtP/WKo1zxtBww63LW
         ClcxonOfpkyyNVtC8sl4/MwTJ4de1AAUVH2T/36wdLfPJm7fdTIs9JbuG5OETgVSsxXO
         r/2bribGncTJ5tAiAHAqJXfwFgOgyp98eDn71Oo/V3Zx4xU6F9vED4yyuggvqMpLnDv+
         9DFb4urcD5Qt87UF+E1w7YWhy4D1Kyh/M15qyeDOjYv/I3c3qAI6ytqkChGlRbhs5YnZ
         7+kA==
X-Gm-Message-State: AOJu0Ywph2nFYC4Qf/5oouIRHjeNYidEkp5mW/2bIJg5+mvnFOy0iKMk
	tFoCyE4i18eTnt55Ie2vitXkjhTSqR0RsdaMm4RdsGniQhVoidqYuXJt5ENtKzpJ5A==
X-Gm-Gg: ASbGncvjwcRrVufIlPauskmjQXek1n62st7F3F7ppmdkyGx4BjDALctHqG+qsl3cEHd
	/xefR0GnWCZ3QvUN1COGMeqWSDj76RA5hlL+KIWauXP0ZilGUDATD+lUxYqvffDvMCYakhTvysk
	eijChoIdvF8nrhSiWyqhRf88nInwyXtniCX12048p4qeuVYjy0c+bhGaku8BZGAtwqEXzkoIAOG
	xhV+vZ3u1+r8lqfgm7W3TlRu1eOgAORJjcHNTv1zvpfYlGW1hrlIIGGWCn6b8NC5qchCwVO6qDc
	sFYKLOzYXPH5aUON1Ta3qtX/6Gl4s1tXiGHpFEllsWFWXPLkfWORVSANA4+V+w==
X-Google-Smtp-Source: AGHT+IF4Pcb+4NB5OVrO9kHDOJ0ELxNQSVih4GsB+pNvtcCavrEhN7C9FhwFoqy0rjJV1azsy+X0Dw==
X-Received: by 2002:a05:6402:50cb:b0:600:5a9e:2b52 with SMTP id 4fb4d7f45d1cf-6008a7a40camr16581389a12.8.1747808714563;
        Tue, 20 May 2025 23:25:14 -0700 (PDT)
Message-ID: <79ae134b-f364-472f-b9a2-eeb1ff55c6fc@suse.com>
Date: Wed, 21 May 2025 08:25:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
 "Huang, Ray" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-4-Jiqian.Chen@amd.com>
 
 
 
 
 <20d48f86-d7fe-47c8-89ab-61d816e1d6e9@suse.com> 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.05.2025 08:08, Chen, Jiqian wrote:
> On 2025/5/19 21:21, Roger Pau Monné wrote:
>> On Mon, May 19, 2025 at 03:10:17PM +0200, Jan Beulich wrote:
>>> On 19.05.2025 09:13, Chen, Jiqian wrote:
>>>> On 2025/5/19 14:56, Jan Beulich wrote:
>>>>> On 19.05.2025 08:43, Chen, Jiqian wrote:
>>>>>> On 2025/5/18 22:20, Jan Beulich wrote:
>>>>>>> On 09.05.2025 11:05, Jiqian Chen wrote:
>>>>>>>> @@ -827,6 +827,34 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
>>>>>>>>                                                   PCI_STATUS_RSVDZ_MASK);
>>>>>>>>  }
>>>>>>>>  
>>>>>>>> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
>>>>>>>> +{
>>>>>>>> +    unsigned int pos = PCI_CFG_SPACE_SIZE, ttl = 480;
>>>>>>>
>>>>>>> The ttl value exists (in the function you took it from) to make sure
>>>>>>> the loop below eventually ends. That is, to be able to kind of
>>>>>>> gracefully deal with loops in the linked list. Such loops, however,
>>>>>>> would ...
>>>>>>>
>>>>>>>> +    if ( !is_hardware_domain(pdev->domain) )
>>>>>>>> +        /* Extended capabilities read as zero, write ignore for guest */
>>>>>>>> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
>>>>>>>> +                                 pos, 4, (void *)0);
>>>>>>>> +
>>>>>>>> +    while ( pos >= PCI_CFG_SPACE_SIZE && ttl-- )
>>>>>>>> +    {
>>>>>>>> +        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
>>>>>>>> +        int rc;
>>>>>>>> +
>>>>>>>> +        if ( !header )
>>>>>>>> +            return 0;
>>>>>>>> +
>>>>>>>> +        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
>>>>>>>> +                               pos, 4, (void *)(uintptr_t)header);
>>>>>>>
>>>>>>> ... mean we may invoke this twice for the same capability. Such
>>>>>>> a secondary invocation would fail with -EEXIST, causing device init
>>>>>>> to fail altogether. Which is kind of against our aim of exposing
>>>>>>> (in a controlled manner) as much of the PCI hardware as possible.
>>>>>> May I know what situation that can make this twice for one capability when initialization?
>>>>>> Does hardware capability list have a cycle?
>>>>>
>>>>> Any of this is to work around flawed hardware, I suppose.
>>>>>
>>>>>>> Imo we ought to be using a bitmap to detect the situation earlier
>>>>>>> and hence to be able to avoid redundant register addition. Thoughts?
>>>>>> Can we just let it go forward and continue to add register for next capability when rc == -EXIST, instead of returning error ?
>>>>>
>>>>> Possible, but feels wrong.
>>>> How about when EXIST, setting the next bits of previous extended capability to be zero and return 0? Then we break the cycle.
>>>
>>> Hmm. Again an option, yet again I'm not certain. But that's perhaps just
>>> me, and Roger may be fine with it. IOW we might as well start out this way,
>>> and adjust if (ever) an issue with a real device is found.
>>
>> Returning -EEXIST might be fine, but at that point there's no further
>> capability to process.  There's a loop in the linked capability list,
>> and we should just exit.  There needs to be a warning in this case,
>> and since this is for the hardware domain only it shouldn't be fatal.
>>
> If I understand correctly, I need to add below in next version?
> 
>          rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
>                                 pos, 4, (void *)(uintptr_t)header);
> +
> +        if ( rc == -EEXIST )
> +        {
> +            printk(XENLOG_WARNING
> +                   "%pd %pp: there is a loop in the linked capability list\n",

I think we shouldn't say "loop" unless we firmly know that's what the
issue is. Maybe use "overlap" instead? And then also log the offending
register range? (As a nit: "there is" and "linked" are not adding any
value to the log message; to keep them short [without losing
information], please try to avoid such.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 06:44:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 06:44:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991512.1375341 (Exim 4.92)
	(envelope-from )
	id 1uHdBZ-00062u-BE; Wed, 21 May 2025 06:44:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991512.1375341; Wed, 21 May 2025 06:44: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 1uHdBZ-00062n-84; Wed, 21 May 2025 06:44:17 +0000
Received: by outflank-mailman (input) for mailman id 991512;
 Wed, 21 May 2025 06:44:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHdBY-00062O-JL
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 06:44:16 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20629.outbound.protection.outlook.com
 [2a01:111:f403:2414::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 01a5dcb8-360f-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 08:44:14 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SJ1PR12MB6052.namprd12.prod.outlook.com (2603:10b6:a03:489::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Wed, 21 May
 2025 06:44:08 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Wed, 21 May 2025
 06:44: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" 
X-Inumbo-ID: 01a5dcb8-360f-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=R51JgBn77qHVkzoAg60Nk3BIZZWpGG48KiW1OdLgR4wRtV7e41XxkdJL7cOhnrqO0KMycaAuo3WmHS1ug7aHCYeRdc9FhZOd8KRroxXxOsDC0N1mcwHVp83TxTwQbyeyUnSQkrXXvRhvBxh1ipheVKmA9fP4TDICHyPG3/bF5rfm/m3UDkDK/W2demccf5mQc/ykRh9L9XxqwhnNKKjsVjj00k9OO5mu1eXVCBOhQXOG2Oq9i2YIwIfOvii1C4TgUDs3fXmppdJeQZVJq6qE0gpNZUPijUWD3kH2Wao5RuMF3B/1GQSS0W7mBi3MnF7eyBRKIXNs7TAc4dKJhTXFrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GtjVC67YxlCZqbn7KmV2mmInRoQ+z/Gt965b69Z6vZk=;
 b=L2Ul8Lszv5494jSZ2hF+4nZggNT0kn0vZGjjLC17fa6sfnIR474B4aKOXSmN4ZSxWDmmntHmoOxGUGAD/d2PFYGDESNopETYfNQJMZ94bqMvsZYiknvQ1hfxe3m3RgR/v0MUQ3uFy0YnnpSEutHuNcp8/N3N6YdVsYaJ7AJYsnvdwXt65w85qDAXbzDkD3Il1XHaczn9XDK5j/hK2/ftTDurShgKQGvs9WOCFlNRrQx8N1nVgsA1N381oAdgJ+OFVBbuhYXpXd/W/b4enGu75vtxqPnYvg4zN0dGJwLJHnx7rV1liBBW6S+XhnJtvDrY30nQ2YjT1X+uIBl+CUIJ3A==
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=GtjVC67YxlCZqbn7KmV2mmInRoQ+z/Gt965b69Z6vZk=;
 b=P64J+dkOksNCXCujqd5NanhnES9h1lV4LYro9HobpDLPZF3uDceNEoRqWoUX163DAgFlI3sL524/0MLFZu3RCGqzAutY9+vXItd+kLUyfIXbEizOCIEC8AAlz0dUfYZhCCDxTzy8/OgHEj9gmzeDLop8xkVnryhM/+puAh3hMOg=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "xen-devel@lists.xenproject.org" , "Huang,
 Ray" , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, "Chen, Jiqian" 
Subject: Re: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
Thread-Topic: [PATCH v4 03/10] vpci/header: Emulate extended capability list
 for dom0
Thread-Index:
 AQHbwMGevTfR886wakahq6ntIeNmMrPYfnSAgAGVuQD//4B5gIAAiU8A///fQoCAAAM5gIADLxQA//+BMIAAES4rAA==
Date: Wed, 21 May 2025 06:44:08 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-4-Jiqian.Chen@amd.com>
 
 
 
 
 <20d48f86-d7fe-47c8-89ab-61d816e1d6e9@suse.com> 
 
 <79ae134b-f364-472f-b9a2-eeb1ff55c6fc@suse.com>
In-Reply-To: <79ae134b-f364-472f-b9a2-eeb1ff55c6fc@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SJ1PR12MB6052:EE_
x-ms-office365-filtering-correlation-id: dc4b8652-40ec-42d4-4240-08dd9832e353
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?JVk+0dPYHWeSFZtH4Twap4DhxonZgFso5G9Xdd0HXxFBnUHFyPpJWejDjg?=
 =?iso-8859-1?Q?ZglYnA0M8HnvkhUMY+Pj98n4dG0jimz+MglyWidNMuCtbnbYgpYNeEPf7o?=
 =?iso-8859-1?Q?Qill2TJubSTq73S/JUjVVd9Rb9ja83XfBOsjxNHbWae9SmgvvU3aozQPKx?=
 =?iso-8859-1?Q?38bH35zwBYjsEFWHEd5wGpOo4791p3lGUHhEPZiTuqLTscJH8KK7sQbi+H?=
 =?iso-8859-1?Q?goF6eHvgq9hxDQt3w6I0YSOQIhataJ4Wal0IBnqhWGAILf9IXSeVOJmGpz?=
 =?iso-8859-1?Q?KV7CFsBaYJ2OTHbBNwW0sASmi9Sl8hm//vO575spJ9AJe2pWU+thGB6OWB?=
 =?iso-8859-1?Q?MZC6YA0fM1PwyFUddq96qBw+gml3fkL/X7/UhjD1H1q3OgA72YIoDpE4xc?=
 =?iso-8859-1?Q?4MOPPq/xZA0FGke3aDrxZzAAN6zM4o1yfcTGsAcGzXa83Pq6wh2OZaBVEz?=
 =?iso-8859-1?Q?/k9AC/oqIYw2NsYBS44Ocy/Y8Onak5a9q8DhMyqBydRf08go/sA9w7rOQi?=
 =?iso-8859-1?Q?xwpcMG9QAH40GR6T34fc03oNK4QHN2o0KrpJQK8xBCmXu3dOQjIaWWXTYY?=
 =?iso-8859-1?Q?G90+hg4Z6m/mwyhHwVMdJv2MCGwnT+YVbZkvgwGEMMnyowuil8RLqzOIxJ?=
 =?iso-8859-1?Q?de0y6FqknOW1o+tTkU4FPgCW8oNE6Ig08BQDwCDPnd+Umef9N6ChwBjn1N?=
 =?iso-8859-1?Q?fCmlEaxdq+idXbxoxwBRqofGmZUzXGemyH3SsNJTI/E4+FmgdK3aMuwdai?=
 =?iso-8859-1?Q?KyJJgVCnuG96q078GlHXl5KqATfZyNy9B9S4QOB0H/LhS9X/czaHZlaGpd?=
 =?iso-8859-1?Q?rwlJpg31Jc66Es/L3yqt4rLGifjCM5luLaYLFw+lhrknef/H1JsPdl/9Jf?=
 =?iso-8859-1?Q?+7aFY8b+oHvF/yUlhnzP4kiH1f98JRUM9R/GY3TmhLtJyo3GSwW6Ba/u26?=
 =?iso-8859-1?Q?SSKBUxoILKy2VOIgh6AQ6LYvudPD+ef60EvKsVnzJwC9vjA6P2Vp3F3p4b?=
 =?iso-8859-1?Q?AvRZghXciGGD0DheRcGh4xeKcSdvS+N6ukpWq5AZ85uskHYOmFMltKR7zb?=
 =?iso-8859-1?Q?/EDuOQEUhOohiiQ79qUMm6/2kRPjm9FW9o05Mv6Ss7mz654xYUvVM899gN?=
 =?iso-8859-1?Q?6312X6Jfx29rbRF/Ff5flr4N+hLtmQVT4UJs0Q9H/f06h6tA5m7qqxdwJS?=
 =?iso-8859-1?Q?kGs3mBRK1CCww1azwd9dDqZw7DiAbfPt5BSRH1lT9h4GL9ZIe8w7yzE0iY?=
 =?iso-8859-1?Q?+jqTqDz8+ZTKHdXxIhvfN3eyE7H+N0eyFLZJI78/3+Ot5qq+qba20T1Ow9?=
 =?iso-8859-1?Q?bwyIl391lvN/f+gWs9XfyqkD4vBGV2dNR1wSJqEUbaFq5I1O4CF2Ev+O9w?=
 =?iso-8859-1?Q?UFVe2iSHVXxq25Eoui5BRgNrR+DL+LRJYD8qFrsEqdZpn6O6ZBc29QNLkf?=
 =?iso-8859-1?Q?CGIVveuYK79ZF01fCY6RQIuEecayUf7Vc1lf2VROYwGcJsSQOUiAL5xrn/?=
 =?iso-8859-1?Q?S8HjxhQv7UrBR+OZ4dglMgpU0aL98FTUD7dAzWwk3MCA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?HnsNl6BsFWfAlWF4SzPXCuO7jtHCvEciwEzPc+9a64QqTQrXPoqZRq5BzU?=
 =?iso-8859-1?Q?R3NP3Yx68I0MpkcWg4ZhM9D2kRDgY1uuDIXAYAV56FmJl7VqhJpe7h07IB?=
 =?iso-8859-1?Q?CIbzNN2FGgkqEw53mOkUY6FMIcXRKdGnZQxNVvJreionHR2GQ0McepihG6?=
 =?iso-8859-1?Q?/GBnURaO1574RzucatyOlRtRAlaQMLb5ijdyHY1+EpqGHp70OMv7VrahM2?=
 =?iso-8859-1?Q?FbGrnvKql1UXhRXaU4CWm6q7HUOuN4QaTF4pnAzNj4gNTj6ZvRHKdlLuHq?=
 =?iso-8859-1?Q?uKkeajqxLORDGpy7LEZw8c3QXYcKBCwhkNtkQvhbXWvcGi+41/8wY6OizY?=
 =?iso-8859-1?Q?0rJ4NEvzb8N8ejYkQI++pxoOmUpXg8Bhs/GSpD0RvsOGUakr6oTGTXj1AR?=
 =?iso-8859-1?Q?M71y0iSXKQHOBS5b/prgkpqe4ZQtT41bEaokgZodrxnswQyywEc/UKQJmI?=
 =?iso-8859-1?Q?kqLu53BP7X3q5PWRZ/zwOMS539JWsnjgmVXkYSmcISWpOegssKBhXVDxhX?=
 =?iso-8859-1?Q?P6pvD4UP7SdyaFhUs7buHxAwsLCF4GI43FQpX2nGKGXdfSYnZb2MLq7tso?=
 =?iso-8859-1?Q?obPYBP9KBNSa2iXQWGCTb/i1kj0uiHy4zRB+tSsnYTRqwgFToPDsVWiD0/?=
 =?iso-8859-1?Q?TSbbhzbCjhB2d7BTdC98YFXsUtk7Y4joARoi5QminY7E+i+xnpLo5Pgwmx?=
 =?iso-8859-1?Q?/Neta9l19+K2gxMbxpuHRkBMNfdobbIZ7bx6qXfNhUbfwVSd38KnERhwOv?=
 =?iso-8859-1?Q?fIbVl24eH8sFm3DNwro8fTuV0lqnwqaygXa/eiIIDif8BZOsNRvMjHrsb/?=
 =?iso-8859-1?Q?S79fw3CDlBsHZD4P0nBkqnh2azpxBbFyFwKIbbLvxcXqWWZ53ac/q++og5?=
 =?iso-8859-1?Q?b9Si/BNBFYoieaVkvRyHupXLJ4j1qyintt5AmMeQjTOK8Pfa+KnginysJA?=
 =?iso-8859-1?Q?vjw5NQKA8JdH4zh+FoIX9DZxY+4bDeIPYDcEUjfhnLmL4pbNgY4hg/qscY?=
 =?iso-8859-1?Q?HDVcy6JTZ9/nDHL4nNSv6k5CEsrKwjMWlFDeLYfiiXSUACOukqW1ipYYff?=
 =?iso-8859-1?Q?+osB8W9sayyUKl0lyUPmG00APqAp76dnP5Wyy7GVQC4Pw6mn9Enx1TAp4p?=
 =?iso-8859-1?Q?N4V+8YTa1dUm0x8R6zdQSUg1B7woM6UfwwkCUmwrso6dc4YYUoRJbs60w4?=
 =?iso-8859-1?Q?sZOB0xpAM7TJ5XbyBvmZJLZsEjWUW2Imqchp2dNw+8w20VVv/nkhH/5rIg?=
 =?iso-8859-1?Q?x17crS31rEiccKFW4slncGFGzYmq++nmmSLUvi5AOpRNvVA40Q3+s915IU?=
 =?iso-8859-1?Q?GqtS+UHsyg5+Hoj/pJpKKXArsQz7St8O0SGrB8qkujHkD1+Hmmi04AOSxz?=
 =?iso-8859-1?Q?mOcZBZfQ0F1+nQ8AdQbOef7ohXgakQ91CtabM8THA0suPRWf9OEfgrRsZB?=
 =?iso-8859-1?Q?c9QO2aLUD3FMr+U2BCR2Y+5MzzKugkZbsYYEk1eONInfVGsuNFA3r7qBKY?=
 =?iso-8859-1?Q?cgudd0oQhRQKQ52wu49+aaxmJSBGKTvAn0D04lAoVrnBsVhkobJNa+2Xjv?=
 =?iso-8859-1?Q?waT8TVzjj+qqhuTE7KoKLP7NsPJa3rOWfKGKcueF9jOLwvgUCfpQInTuEy?=
 =?iso-8859-1?Q?RQwl5E21V8hb8=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <6ABB37A2EFAFD540A4BD2D2AD3DFF2BC@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc4b8652-40ec-42d4-4240-08dd9832e353
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2025 06:44:08.5523
 (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: PgyfIRNU+UEoy6fVufvcDOriwaP4VmtWP5kfSzD+vTwwUGJ2ZGxIvNXXcy3tyjAZjXX9ZXvez/p5BOSh7qHvJg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6052

On 2025/5/21 14:25, Jan Beulich wrote:
> On 21.05.2025 08:08, Chen, Jiqian wrote:
>> On 2025/5/19 21:21, Roger Pau Monn=E9 wrote:
>>> On Mon, May 19, 2025 at 03:10:17PM +0200, Jan Beulich wrote:
>>>> On 19.05.2025 09:13, Chen, Jiqian wrote:
>>>>> On 2025/5/19 14:56, Jan Beulich wrote:
>>>>>> On 19.05.2025 08:43, Chen, Jiqian wrote:
>>>>>>> On 2025/5/18 22:20, Jan Beulich wrote:
>>>>>>>> On 09.05.2025 11:05, Jiqian Chen wrote:
>>>>>>>>> @@ -827,6 +827,34 @@ static int vpci_init_capability_list(struct =
pci_dev *pdev)
>>>>>>>>>                                                   PCI_STATUS_RSVD=
Z_MASK);
>>>>>>>>>  }
>>>>>>>>> =20
>>>>>>>>> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
>>>>>>>>> +{
>>>>>>>>> +    unsigned int pos =3D PCI_CFG_SPACE_SIZE, ttl =3D 480;
>>>>>>>>
>>>>>>>> The ttl value exists (in the function you took it from) to make su=
re
>>>>>>>> the loop below eventually ends. That is, to be able to kind of
>>>>>>>> gracefully deal with loops in the linked list. Such loops, however=
,
>>>>>>>> would ...
>>>>>>>>
>>>>>>>>> +    if ( !is_hardware_domain(pdev->domain) )
>>>>>>>>> +        /* Extended capabilities read as zero, write ignore for =
guest */
>>>>>>>>> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL=
,
>>>>>>>>> +                                 pos, 4, (void *)0);
>>>>>>>>> +
>>>>>>>>> +    while ( pos >=3D PCI_CFG_SPACE_SIZE && ttl-- )
>>>>>>>>> +    {
>>>>>>>>> +        uint32_t header =3D pci_conf_read32(pdev->sbdf, pos);
>>>>>>>>> +        int rc;
>>>>>>>>> +
>>>>>>>>> +        if ( !header )
>>>>>>>>> +            return 0;
>>>>>>>>> +
>>>>>>>>> +        rc =3D vpci_add_register(pdev->vpci, vpci_read_val, vpci=
_hw_write32,
>>>>>>>>> +                               pos, 4, (void *)(uintptr_t)header=
);
>>>>>>>>
>>>>>>>> ... mean we may invoke this twice for the same capability. Such
>>>>>>>> a secondary invocation would fail with -EEXIST, causing device ini=
t
>>>>>>>> to fail altogether. Which is kind of against our aim of exposing
>>>>>>>> (in a controlled manner) as much of the PCI hardware as possible.
>>>>>>> May I know what situation that can make this twice for one capabili=
ty when initialization?
>>>>>>> Does hardware capability list have a cycle?
>>>>>>
>>>>>> Any of this is to work around flawed hardware, I suppose.
>>>>>>
>>>>>>>> Imo we ought to be using a bitmap to detect the situation earlier
>>>>>>>> and hence to be able to avoid redundant register addition. Thought=
s?
>>>>>>> Can we just let it go forward and continue to add register for next=
 capability when rc =3D=3D -EXIST, instead of returning error ?
>>>>>>
>>>>>> Possible, but feels wrong.
>>>>> How about when EXIST, setting the next bits of previous extended capa=
bility to be zero and return 0? Then we break the cycle.
>>>>
>>>> Hmm. Again an option, yet again I'm not certain. But that's perhaps ju=
st
>>>> me, and Roger may be fine with it. IOW we might as well start out this=
 way,
>>>> and adjust if (ever) an issue with a real device is found.
>>>
>>> Returning -EEXIST might be fine, but at that point there's no further
>>> capability to process.  There's a loop in the linked capability list,
>>> and we should just exit.  There needs to be a warning in this case,
>>> and since this is for the hardware domain only it shouldn't be fatal.
>>>
>> If I understand correctly, I need to add below in next version?
>>
>>          rc =3D vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_wri=
te32,
>>                                 pos, 4, (void *)(uintptr_t)header);
>> +
>> +        if ( rc =3D=3D -EEXIST )
>> +        {
>> +            printk(XENLOG_WARNING
>> +                   "%pd %pp: there is a loop in the linked capability l=
ist\n",
>=20
> I think we shouldn't say "loop" unless we firmly know that's what the
> issue is. Maybe use "overlap" instead? And then also log the offending
> register range? (As a nit: "there is" and "linked" are not adding any
> value to the log message; to keep them short [without losing
> information], please try to avoid such.)
OK, below may be more in line with your opinion.

         rc =3D vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write3=
2,
                                pos, 4, (void *)(uintptr_t)header);
+
+        if ( rc =3D=3D -EEXIST )
+        {
+            printk(XENLOG_WARNING
+                   "%pd %pp: overlap in extended cap list, offset %#x\n",
+                   pdev->domain, &pdev->sbdf, pos);
+            return 0;
+        }
+
         if ( rc )
             return rc;

>=20
> Jan

--=20
Best regards,
Jiqian Chen.


From xen-devel-bounces@lists.xenproject.org Wed May 21 06:47:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 06:47:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991518.1375350 (Exim 4.92)
	(envelope-from )
	id 1uHdEv-0006aD-PP; Wed, 21 May 2025 06:47:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991518.1375350; Wed, 21 May 2025 06:47: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 1uHdEv-0006a6-MY; Wed, 21 May 2025 06:47:45 +0000
Received: by outflank-mailman (input) for mailman id 991518;
 Wed, 21 May 2025 06:47:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHdEu-0006Zw-Fc
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 06:47:44 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7e7b9f03-360f-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 08:47:42 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad5a11c2942so174545866b.3
 for ; Tue, 20 May 2025 23:47:42 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d443a0fsm862394366b.97.2025.05.20.23.47.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 23:47: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" 
X-Inumbo-ID: 7e7b9f03-360f-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747810062; x=1748414862; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=h8oIyxLaLhYf99A7W6NRo575+3iDSO5yqjANehu8DAw=;
        b=cKhULXh7mp63uoKafnxliVFgnG9oFTX+peZzMiA0O0IA5BkYldbRmD921kD+pF2FN1
         7acKy8PK1I13HEPtu5eSebXniphkO78ngQwbpZ4l8OR2VC7+mIOtETMUU/z0YOepZxHf
         QWwg9u9M8bEXr5VE5/5I5uCfbVcI59BDP2pkKsDqcfRL8kgjwprWIp36QaprZ+vAhEaK
         bkhSZrC0hWq1N/fBWUSwR+WiS1VO/L/3L0RB12R45e8nBR7yjpEROIruerm0d0+hFtJw
         0aQH3feBn/U4Z/iPtNWG3lu9lBhQdP+qcGefjiQi0cG/dE2PulbML81NOBHqXvXtAcog
         Nj4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747810062; x=1748414862;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=h8oIyxLaLhYf99A7W6NRo575+3iDSO5yqjANehu8DAw=;
        b=NJCMRXceSPacSh5+wCuppYAE6ct6Q/7CmzmVOf38MHEeKcagEXO9rID6i7l4bZRoLq
         Eav49GN+PLban8rN26lm74J/VadbnQHH+vFqMvuRmQUXFXvgv1NCxleaULNiYy6SKVXL
         azNhVzD5gj3YoiDQ3xG0Lw5MOzYuNEkAlbpNcH5J8cQRTbDbMwtVHDVUxWYgArkPEurP
         K/8VCk2NiIMAehfJVG5WbogyRqsFyJkS1sjLRVbcukus5vWVP7pC4yNoM+kdrsQCeuBY
         TghMtXpWb2R4ZCZsCF1hUwJ9RwBrh903q9oO9Jogf1xfWBgs/XdMyOEuvOPI+nfARhyv
         p88w==
X-Forwarded-Encrypted: i=1; AJvYcCUYIXrBqgjiR1/ZJNEcJfoGtDoPQ/NMJUlvoNZD7qsWNpyHK9ILfUROIb0bhBM+Saaa9hqi0ODsa5I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzbUXxnU16mVbdwp8flwLuxpq9W7cVVtP12ekDo/1dAnHT3BBLh
	spf4NnAYMAumtZbFQjYrtzw/TYNs59Vb/KM9JtuTrSmXZ6RjrTYXbM8CkNQfCe5REg==
X-Gm-Gg: ASbGnctP3hasnsAyMEzqKtIaHrBNN/94BJX9PkzSH2U8q5a6dWXLxCfOCZniGZ+4jex
	tGT0i5KWtbDQw1moc6eA1JIuICxej2nsSdPv+um0K3FCLcxLQuA2+HUt812NWwchSNKo9WI+oLH
	oQza0kBFinz2iCJwUwNw6kG7sFshe1hX3ElXb6wUNzJC8AtM38aUwhirHjGG7Vb0qTyP02TBc2f
	qnPd9sm8MiTGPh6zpBDvmdTqm8KqE7FDZQ6lIoxQi2S2+ylb/pkFJ0tTwshV5Kx9HrZ16/o3ImP
	hOCuRD0C/MwYfni13TEwwYsK498LEatwxfchHuNf5Lr8Shw6e0jGkWbvzb9x9nUbYRMBe0gu
X-Google-Smtp-Source: AGHT+IFstWEh1wuLAoJaB/z3Qwc1Zk14lGFniVKzYgMAlaMFsKSwRQpjWYtVpgf94y/FbOTJfvBo8g==
X-Received: by 2002:a17:907:930b:b0:ad2:2e99:8d9b with SMTP id a640c23a62f3a-ad5370339c4mr1997903066b.58.1747810061846;
        Tue, 20 May 2025 23:47:41 -0700 (PDT)
Message-ID: <11021b35-826c-4e41-ad31-d6966dd0431b@suse.com>
Date: Wed, 21 May 2025 08:47:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/argo: Command line handling improvements
To: "Daniel P. Smith" 
Cc: Christopher Clark ,
 Denis Mukhin , Andrew Cooper ,
 Xen-devel 
References: <20250520141027.120958-1-andrew.cooper3@citrix.com>
 <2a92e866-543e-404d-be34-d58cf5d51aec@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <2a92e866-543e-404d-be34-d58cf5d51aec@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.05.2025 20:45, Daniel P. Smith wrote:
> On 5/20/25 10:10, Andrew Cooper wrote:
>> Treat "argo" on the command line as a positive boolean, rather than requiring
>> the user to pass "argo=1/on/enable/true".
>>
>> Move both opt_argo* variables into __ro_after_init.  They're set during
>> command line parsing and never modified thereafter.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Christopher Clark 
>> CC: Daniel P. Smith 
>> CC: Denis Mukhin 
>>
>> Found while
>> ---
>>   xen/common/argo.c | 9 ++++++---
>>   1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/common/argo.c b/xen/common/argo.c
>> index cbe8911a4364..027b37b18a6c 100644
>> --- a/xen/common/argo.c
>> +++ b/xen/common/argo.c
>> @@ -79,8 +79,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_argo_unregister_ring_t);
>>   DEFINE_COMPAT_HANDLE(compat_argo_iov_t);
>>   #endif
>>   
>> -static bool __read_mostly opt_argo;
>> -static bool __read_mostly opt_argo_mac_permissive;
>> +static bool __ro_after_init opt_argo;
>> +static bool __ro_after_init opt_argo_mac_permissive;
>>   
>>   static int __init cf_check parse_argo(const char *s)
>>   {
>> @@ -92,7 +92,10 @@ static int __init cf_check parse_argo(const char *s)
>>           if ( !ss )
>>               ss = strchr(s, '\0');
>>   
>> -        if ( (val = parse_bool(s, ss)) >= 0 )
>> +        /* Intepret "argo" as a positive boolean. */
>> +        if ( *s == '\0' )
>> +            opt_argo = true;
>> +        else if ( (val = parse_bool(s, ss)) >= 0 )
>>               opt_argo = val;
>>           else if ( (val = parse_boolean("mac-permissive", s, ss)) >= 0 )
>>               opt_argo_mac_permissive = val;
>>
>> base-commit: 293abb9e0c5e8df96cc5dfe457c62dfcb7542b19
> 
> While it is logical, this does technically change the behavior of the 
> command line flag. Should there be an update to xen-command-line.pandoc 
> to clarify that the list is optional?

I'd view it the other way around: If you look at the neighboring doc
entries, we uniformly say

> `= `

when the options can appear all by themselves. This would therefore be
the expected behavior for "argo" alone, too.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 06:51:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 06:51:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991532.1375360 (Exim 4.92)
	(envelope-from )
	id 1uHdIH-0008Hp-Av; Wed, 21 May 2025 06:51:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991532.1375360; Wed, 21 May 2025 06: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 1uHdIH-0008Hi-80; Wed, 21 May 2025 06:51:13 +0000
Received: by outflank-mailman (input) for mailman id 991532;
 Wed, 21 May 2025 06:51:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHdIF-0008HO-Fg
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 06:51:11 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa79f8cd-360f-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 08:51:10 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-601f278369bso5618112a12.1
 for ; Tue, 20 May 2025 23:51:10 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ae3aed4sm8287753a12.75.2025.05.20.23.51.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 20 May 2025 23:51: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" 
X-Inumbo-ID: fa79f8cd-360f-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747810270; x=1748415070; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=YVYXZRLpOWkBJa2fhZ8pLQuu1LIkaD5CXf8JiwDR42U=;
        b=SQliSQsy+qVRmcSlL6jb/zPKRR7qzfZP1be4srf2L476EEcG5gz3JMnwVbnOJqmzVJ
         +92cIjDVch1E9wtJs42jWbas4OOPIxiOR5Udh6NpG7xzvHP3fa2YqYfP5sMDQ/ZaJGm5
         xCMZ+RWUO54xn9MnqLImmxWEBp2jxR8ISrjX0i7ScdoHMlFIqb0s0Eu2vuQED5lpyBg9
         eQ3+jj+UsvwlCkWFSE03baw6XX+U67rdKThny2bngXP1LdA+pZmyUYr+n4/dqYz0BF4f
         OL/bqEhQTyCPBMrkhnf1Nqr8DEsv3bmJypGji7zSt0KaKR9bwvOEMqCFP9CswKd9x3Ov
         j1pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747810270; x=1748415070;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YVYXZRLpOWkBJa2fhZ8pLQuu1LIkaD5CXf8JiwDR42U=;
        b=Op/nGQaLo/rWaetyNaRw2+JTqGsCsg0uwirQ4Q9vFGzm1rj9kTwmNce+snekrkCYj7
         XyLVnGqoel3Trcn5AlYyXYRvp+6OSeZQmi75gdsg+tWhd6jpA3jhCdVi8AOB9LvyubzL
         coaLUZ1LB20UmzfnBOe5mdcjb8lZkXshrsbF87wNwH3J7meVEbHFQGU16mFzJc4v6ySN
         k9Kv87XtAIiXiJ2tlPmYSc0Hk/lKlvqwV8x2F6CXLCd/LNZicRTDXS/3YzzpLGp3FtUi
         2j2hAUgon8/kPCUfP20PEmLF+0JyC1sOQD9HE3BBxGH/JCR0zSiXlKu2RlKd3PPWA++Y
         kmcQ==
X-Forwarded-Encrypted: i=1; AJvYcCXXts0Xw8XkhyQaMis9fE3wYfQhBEmG1pMxL/8OK3z/PgeWDfakLxWE14OT4+rpYSrvRW/ERzYT8UA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YygfCY2C5rjEIDKFqQS1hd+Ry/UUOMYCB11Dw9Q5S9y7wYqnZ1H
	I9Em3mmEi9Lmz2165ie44VVoAQFlwnxW74CQoIzRR0Am8X/wP8Ojx31Vh62tprp4uA==
X-Gm-Gg: ASbGnctYUyMw8i9H7b74u0WGCIKL5GOGjkduZbhk9/fRxfI6u6ONlfRJA6luaWnmIHv
	GThrPAZahrV0zx9Ji9oo4yd9/klPjxSXHWxHY4zzI6OhhtxQq4pqfkG27pWglhgn0gFD2SaZruN
	3KitpKK8fL2AXYbsfHusFzAzAh8ta1LNXkyV1fIRAkEHAIPVIklOXbiKK0zgCsp9/cXOkSuXt58
	TJN9sIznGx1siXsnK8x4XYlAeDU4Mq/guQ/6AdBRi/d0B+1nZilDdzy+B3vYed2gyIc/2clNvmo
	GbhNJJPofXjoM+vcHYSR1rHR+QPd/KTmtLxHVQ9DGof11vthDIvPfaGy5kRjA/Fd3yHBUNId
X-Google-Smtp-Source: AGHT+IG8iGzXj7eHx3TrMkdHB3lT2dCrQug4vhRdJXAexu7mDJlbJ8IgG/XNiwb8ZSc6mPkdaGmeYg==
X-Received: by 2002:a05:6402:34cd:b0:601:89d4:968e with SMTP id 4fb4d7f45d1cf-60189d49a3emr16840576a12.27.1747810269939;
        Tue, 20 May 2025 23:51:09 -0700 (PDT)
Message-ID: 
Date: Wed, 21 May 2025 08:51:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/domain: rewrite emulation_flags_ok()
To: Stefano Stabellini 
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com,
 xen-devel@lists.xenproject.org, dmkhn@proton.me
References: <20250516022855.1146121-1-dmukhin@ford.com>
 <20250516022855.1146121-3-dmukhin@ford.com>
  
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 01:00, Stefano Stabellini wrote:
> On Tue, 20 May 2025, dmkhn@proton.me wrote:
>> On Tue, May 20, 2025 at 05:24:33PM +0200, Jan Beulich wrote:
>>> On 16.05.2025 04:29, dmkhn@proton.me wrote:
>>>> --- a/xen/arch/x86/include/asm/domain.h
>>>> +++ b/xen/arch/x86/include/asm/domain.h
>>>> @@ -494,6 +494,12 @@ struct arch_domain
>>>>                                   X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
>>>>                                   X86_EMU_VPCI)
>>>>
>>>> +/* User-selectable features. */
>>>> +#define X86_EMU_OPTIONAL        (X86_EMU_USE_PIRQ)
>>>> +
>>>> +#define X86_EMU_BASELINE        (X86_EMU_ALL & ~(X86_EMU_VPCI | \
>>>> +                                                 X86_EMU_OPTIONAL))
>>>
>>> That is, VPCI is neither baseline nor optional. Certainly at least strange.
> 
> I think Denis tried to keep the code more similar to the original. This
> way it is easier to review the code change and it seems correct. But at
> the same time it is easier to spot inconsistency that were present even
> before the patch.

Right, and that was in response to me complaining on an earlier version
that the behavior was (silently) changed. Yet doing it like this wasn't
the only way to address my comment there. At the same time (or already
before) I raised the question whether having such constants is helpful /
necessary in the first place. And now that their names don't reflect
their purpose, this question becomes yet more relevant.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 07:00:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 07:00:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991540.1375370 (Exim 4.92)
	(envelope-from )
	id 1uHdRX-0001RI-5G; Wed, 21 May 2025 07:00:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991540.1375370; Wed, 21 May 2025 07:00:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHdRX-0001RB-2e; Wed, 21 May 2025 07:00:47 +0000
Received: by outflank-mailman (input) for mailman id 991540;
 Wed, 21 May 2025 07:00:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHdRV-0001R3-Rc
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 07:00:45 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2415::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4e21b31d-3611-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 09:00:41 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DM4PR12MB6158.namprd12.prod.outlook.com (2603:10b6:8:a9::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.34; Wed, 21 May
 2025 07:00:37 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Wed, 21 May 2025
 07:00:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4e21b31d-3611-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bYfYMuENC0S4qeyVIijcDq99KQWOEMMZmbby+mMFFWzvoV5n1Hb2NLkDvUVZCpE6O9qLc8CTsuN0/3bybnDiJfuum2QwO+NHatJoVc+KizKTEX5gHiA0/CUYrNhfLX+f5j9vi5B7WoHs4a+QPhyPw/zrJPQ550sOUmu4qiAGBrRpc4SMjKOvDNBvghvxOMcsplNvp/eoMnx8fVvIJKtnpxEoBXEie0cqX0DYejPwm68JhGIVFqxaoCrXESxJmXerQIV4XEIjDOFXKWK22yhYtkgd1ForLqWaq/CBx+5xhRFT78dTXk4b1gzRaNOSAZ0G8p5KehSyV64coABxvr2+IQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KR6TXHco41bm2waWPB9DKT3Iq4ZAIK+Gekujl7B24A4=;
 b=J4zsAqe9mg8iZzSkDMeAz3g+ogwuV/YnVe1wvUxCluFH8hy/SyG6+ofPxLzja5z8Cx1txbEHWyz54JBp7XPZjBNGo0r8ZdUscyEU812iaWTzl2YU/efSQCbf88apSCQWMnH24itS75hVdype4o3BhY81OG1s+Yo9MT6LziXev/F/btEFofNIamVx1vdV8pvTV200nW1RGY1/+607szDkhBfOxTjvwkDh15mTR7TK/OusPc064jArXMFmOLGd/NWQCg7xhlNJ6V+AM45gQ07UGyhh5QJONc4Jm6gIqsUa9AZIokgYejURUj6TOKErsKq7fZYnJVkXbtJ2kYpkWVMTjA==
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=KR6TXHco41bm2waWPB9DKT3Iq4ZAIK+Gekujl7B24A4=;
 b=Acm5O5jdc7igiaGfaotE2pEnsWLfxk4bOOIGAmVatD5G5hirZhy+zWo0Cgr0wjKyLfeoKM+o/L3Z+MBL6tngpeuheOWspZ+h+e5vCmb9BObX7GMTFBDRBrQ0HDT9V4EN5agN9OOfLT4s4hbWNL0qvdFaR7B+pYn4HyyT7ug72K0=
From: "Chen, Jiqian" 
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Jan Beulich
	
CC: "Chen, Jiqian" , "Huang, Ray" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Topic: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Index: AQHbwMGh3xGCtPOZ6EmRbIkDtAY42rPbIqIAgAApmYCAAAFtgIAACDMAgAHezgA=
Date: Wed, 21 May 2025 07:00:37 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-10-Jiqian.Chen@amd.com>
 <8d89f644-4ded-4490-ad23-518563d230d2@suse.com> 
  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|DM4PR12MB6158:EE_
x-ms-office365-filtering-correlation-id: a3502a5a-7973-40ea-2985-08dd98353084
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?Z7RVsIgP9YfbcSHOT40iBMVKhfAL2oUkRKEmDY7ZrOTvUNlJhamRgASjIC?=
 =?iso-8859-1?Q?Tde57bj9Re9ExquO/f7ImWV6BTM9wR6GCrh4CikvH/jfLWs3udaNjtkvSA?=
 =?iso-8859-1?Q?ji8m8xs+8M80YJ0BfM27vghS/uX50RnKri+HfKP55oVZVUluAQazmnPY/g?=
 =?iso-8859-1?Q?a7qyGSkqMWNQOeNcfgqDbY+23AwYUsc51YiNNzDcKDCkt5iEj7fazHwYhW?=
 =?iso-8859-1?Q?MvqCZxAh3Llp6YgJ+k22viGoFc2nZBMx9AG/4UA7sS0t4hixxeS3LyeUlA?=
 =?iso-8859-1?Q?Xp0ykaSE7w0rj5fS3cYRta8mdkIe1uTuF+o5I+Ihdc+fWt8M40zDa8rtPu?=
 =?iso-8859-1?Q?5ObtlxuduLE7PHXlYDraCtsNQ1HM0AbbFFX1tCl6KTj40JpoEXARG8sRGG?=
 =?iso-8859-1?Q?P63NjW20OZzymjaRAnIahHHMBRWq3Sax8ykSoieIO6gzQA/4kidM8EI7BO?=
 =?iso-8859-1?Q?IBtkuOtormuzTUrVbQymOuYnzDOTusDoYvvwd89CCz/dkOTz5B7zr5c5/x?=
 =?iso-8859-1?Q?xWZ0z73RT3d5g72xy2SGb+UCBI6Cm6dLq0Bvmoprek3uvQv1niJ+W2lS0F?=
 =?iso-8859-1?Q?xHvtCIcX80KGyieN7ZcPkqj8Dt8YUHoPKNM08cYYANC1uGmnWnv7htj5LU?=
 =?iso-8859-1?Q?FOM6OwtIeZ1UcX22Ip+XFfpTh1LTDVWuKG1fJkgLspVT9THRjhtFCAjAYt?=
 =?iso-8859-1?Q?89jZAlqObKVB4RzuwriWWidDDJOgEEVhHuVOU2OxT/rRDVDlVPls/xUGda?=
 =?iso-8859-1?Q?6Ho0wDIRu/BK//9W+/1yQ51SlwvG5tgF/U5e/k3lp/3Vfe4+kMZefNo+KM?=
 =?iso-8859-1?Q?iQKzKneuMd1wrAAXPwyezpkPNcnan4pnwVh5NSUk+sL+WPTUkluLUB5J/j?=
 =?iso-8859-1?Q?TqRGRKeQqp2qwjOqw1VlxN+0ifPWRtKvqsqraeKT8wRDRCLcJ9EgtgFotl?=
 =?iso-8859-1?Q?820BeAfs9SBZ7mc9wJPRYnZxuoO99aVTrlqa/PV2PnC9E4lwwhyZS2Pf4W?=
 =?iso-8859-1?Q?ZUnsTCzKd1kOL8mRNcSjIYlFSmUGGZaA4tfFs0HiTp2YMXhQjiHsP3ihnM?=
 =?iso-8859-1?Q?kT/dCeGfE0+BPZEdAI7ysuFIDsjKXmmTMaDgeCp05U8z5h2Qc15PU7F/iX?=
 =?iso-8859-1?Q?EGaaiAYZPSHLGFfaAWWWWmphR3nd/OWdknKPeXgy2GuudM3965Bm2lJa/C?=
 =?iso-8859-1?Q?j49nWpvMgt+4ThQSZSgeYUQ1FHutLExz3jnlyXFBgLO2bwpQGt/lXQIwmu?=
 =?iso-8859-1?Q?q4DX5FdDD6vg4Kmuyk+bzqous0+cbZt5mLLEkjAybG6UlhluqAvjNIkVJv?=
 =?iso-8859-1?Q?KuUufDTza2NXjci88JrAzykdhXvovB9pA1krSnAtlUMEqXnnSxP2eNOFpR?=
 =?iso-8859-1?Q?YrWWJDj2XOXE9sybKOplFh8X0t8sftIIb3EGd2fn1D6GOpW5dTAex7f6eG?=
 =?iso-8859-1?Q?nOh/7pNEzd1QGBEZC6lbnL8F1pslMChkETEcEI2kdegUVKBt2WMTueRU02?=
 =?iso-8859-1?Q?mmf4LrP4ORYUJifEPAET+xrbR8h3ASK79vjkLymsHxiM68FZLE/xAWSrR8?=
 =?iso-8859-1?Q?+YsgINo=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Ub9hqoNK81/PL2LLk8RQ27L9AWzWjzcfdaZzkG4XP+dN1e4/g4roKxPofB?=
 =?iso-8859-1?Q?tO4/620QLLMmkHwnEzJOXCProZ7GH1wx/2uuf5SZGcT9tMBNWaL5hWzZXt?=
 =?iso-8859-1?Q?909vDDn6CX/wzBu7R9E2crUIgjhY9Sh5/BSEnqjHGgJX1ggiNobKkuqbHG?=
 =?iso-8859-1?Q?ncPRSFs5T1T4xBYggUDNI9nPIP+iogJ1hK31p6CKP2i2qrQhxafZQfYi01?=
 =?iso-8859-1?Q?6/XDDAUvh3Pcw7fiNczQ7PyicIfmxoQnvoOvSn1nDnMUsYcdSzTpHgEzKt?=
 =?iso-8859-1?Q?1U3pTPuN9V9YhLrd3B6fOh8oOmLyHjYLRAcRtr5BLO/5icNjs1YPcivRP5?=
 =?iso-8859-1?Q?/fLBjjHBn9zUsxmJFi7C5r0TKob+aUQNOzm5N9OoAJ5B8bCgwxlgatiX5T?=
 =?iso-8859-1?Q?eRTx62rR48NnAsaIU2748QuVzZ76TMO1gaBxQR52hT5bF/yHuF2LUnWZH1?=
 =?iso-8859-1?Q?1zMHWREqhwTsv0+uogveC2Oqlxm/KrNT16SoLReOPiRkezHOb6qXdJERzy?=
 =?iso-8859-1?Q?VIIRdgblAvp9Iefd09lXp48BKshKw5loir383aw4/D3JC17HzhV4cUJ/sp?=
 =?iso-8859-1?Q?F80sycL/AAAG8+5V2V6Yrm7mhTOzUxC+RXuztTFkg1e8Eu20Ylkz6f02H+?=
 =?iso-8859-1?Q?4mnT7qsg30iY+4akfd04oZ3KEX+263W1fdil24Z08FjRKMKfdhTKK+ZcBm?=
 =?iso-8859-1?Q?24/vSjsthEIBqoRYItZ9/en2RvMtFx+CbqnkNXdC4LD92PcgrbxrOOpR/3?=
 =?iso-8859-1?Q?o1WQhmNhRc9p/bga2mVgVWM2ke/X0I6dryxQYKeqyps3vfgjAoIyj4JhxC?=
 =?iso-8859-1?Q?M/KK30pOyc6XgqtQcj0js5B1xDuN2Ng0Ja8rt2QSHsybhVKrBHKhthMq4n?=
 =?iso-8859-1?Q?R/9KAgOEiFFRJHCdQ4mnzj96CcLFIdnvXKVC4hw2IvFO3NUDc6xl1dD04q?=
 =?iso-8859-1?Q?jqeyBV4FbiyIP4aJH+SJOFJSn3VnzYBlVRJQnPtgCL/riI/cVZPqFAJTOZ?=
 =?iso-8859-1?Q?5LfN/xmgAt7/DF2qOgEfDTfbkIioeekUaWtv2HBJPVVP0f9ELBxHPggyiK?=
 =?iso-8859-1?Q?kmpfj52nutxQi8MCPeHB3QlhDSPGscp5WsJNd+AmqYGPgzccejRIfKUlVY?=
 =?iso-8859-1?Q?fosTWjbdIeBT6yIgst8cpqhbG9WTBgNbKY3zyEQ6iYvfybw3JGTiG8bqSY?=
 =?iso-8859-1?Q?QsX9uZhoDYiubKqyJJAh4N/MtcENasUjRrN/Xcw3zswLSVDJyhdgAPJBIM?=
 =?iso-8859-1?Q?/GyopT0Yv33iEqpTmEIVy+PpKC9mBq2cBwxd74OSKfHtFHpwe2Otw8AXiD?=
 =?iso-8859-1?Q?uoLNqm8uhS0a7CPo4CIjYB8UAwnQ7fjIXsi3s1IgJ9jJ9cNGjyn6BCbA/X?=
 =?iso-8859-1?Q?fCmovlMq4wVae1boLqGwkqXP+388MwVZjxoFPifJr/s2qN7MyaUZ5Xqbh0?=
 =?iso-8859-1?Q?5FwcqGSg3eddhm6P+uldvr+8xctAbmqALjMd46rJ2ykCilJH5ZBKFZhCHD?=
 =?iso-8859-1?Q?4Lv9bWGS0M476MbGJYMWdbEjoxHiqJyve4mj50z+rJMl0UNIMLC/c8upN7?=
 =?iso-8859-1?Q?XLYhocMxZO1ZQiK3o9kp6x82bA6fP0GQ14AM5Z65NoF0+aAKorqImk+zjZ?=
 =?iso-8859-1?Q?v8Tt6KpPKL9Pg=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a3502a5a-7973-40ea-2985-08dd98353084
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2025 07:00:37.0919
 (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: XAzKS8alfSmSfTo+qFoYLIIJnr8J2gsozjhp4qODC4pdXyL8AQ4xDJNL+3X6U86PpYCT5sjFmWCxZa3ms++clw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6158

On 2025/5/20 17:43, Roger Pau Monn=E9 wrote:
> On Tue, May 20, 2025 at 11:14:27AM +0200, Jan Beulich wrote:
>> On 20.05.2025 11:09, Roger Pau Monn=E9 wrote:
>>> On Tue, May 20, 2025 at 08:40:28AM +0200, Jan Beulich wrote:
>>>> On 09.05.2025 11:05, Jiqian Chen wrote:
>>>>> When init_msi() fails, the previous new changes will hide MSI
>>>>> capability, it can't rely on vpci_deassign_device() to remove
>>>>> all MSI related resources anymore, those resources must be
>>>>> removed in cleanup function of MSI.
>>>>
>>>> That's because vpci_deassign_device() simply isn't called anymore?
>>>> Could do with wording along these lines then. But (also applicable
>>>> to the previous patch) - doesn't this need to come earlier? And is
>>>> it sufficient to simply remove the register intercepts? Don't you
>>>> need to put in place ones dropping all writes and making all reads
>>>> return either 0 or ~0 (covering in particular Dom0, while for DomU-s
>>>> this may already be the case by default behavior)?
>>>
>>> For domUs this is already the default behavior.
>>>
>>> For dom0 I think it should be enough to hide the capability from the
>>> linked list, but not hide all the capability related
>>> registers.  IMO a well behaved dom0 won't try to access capabilities
>>> disconnected from the linked list,
>>
>> Just that I've seen drivers knowing where their device has certain
>> capabilities, thus not bothering to look up the respective
>> capability.
>=20
> OK, so let's make the control register read-only in case of failure.
>=20
> If MSI(-X) is already enabled we should also make the entries
> read-only, and while that's not very complicated for MSI, it does get
> more convoluted for MSI-X.  I'm fine with just making the control
> register read-only for the time being.
If I understand correctly, I need to avoid control register being removed a=
nd set the write hook of control register to be vpci_ignored_write and avoi=
d freeing vpci->msi?

"
     if ( !msi_pos || !vpci->msi )
         return;

+    spin_lock(&vpci->lock);
+    control =3D vpci_get_register(vpci, msi_control_reg(msi_pos), 2);
+    if ( control )
+        control->write =3D vpci_ignored_write;
+    spin_unlock(&vpci->lock);
+
     if ( vpci->msi->masking )
         end =3D msi_pending_bits_reg(msi_pos, vpci->msi->address64);
     else
         end =3D msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;

-    size =3D end - msi_control_reg(msi_pos);
+    start =3D msi_control_reg(msi_pos) + 2;
+    size =3D end - start;

-    vpci_remove_registers(vpci, msi_control_reg(msi_pos), size);
-    XFREE(vpci->msi);
+    vpci_remove_registers(vpci, start, size);
"

>=20
> Thanks, Roger.

--=20
Best regards,
Jiqian Chen.


From xen-devel-bounces@lists.xenproject.org Wed May 21 07:07:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 07:07:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991548.1375381 (Exim 4.92)
	(envelope-from )
	id 1uHdXY-0002Dn-PV; Wed, 21 May 2025 07:07:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991548.1375381; Wed, 21 May 2025 07: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 1uHdXY-0002Dg-Mb; Wed, 21 May 2025 07:07:00 +0000
Received: by outflank-mailman (input) for mailman id 991548;
 Wed, 21 May 2025 07:06:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHdXX-0002Da-72
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 07:06:59 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2eca020f-3612-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 09:06:57 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-6020ff8d35dso2939288a12.0
 for ; Wed, 21 May 2025 00:06:57 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac32a7fsm8345571a12.56.2025.05.21.00.06.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 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" 
X-Inumbo-ID: 2eca020f-3612-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747811217; x=1748416017; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=CxGiJdansaBYx8iz1FSGBIWSTL36s4XGSNjoYs7TQLk=;
        b=PsLtwzmMbUrYKLZXU3TCOKNh3QwDe66OVmcp98vy2M+8cSaf1K6Hwz7ghAyBCH3kjM
         cCoxouzGopJNEB3XHfSdGeraSzwNu6R1y5lS8QCFxcEEbWOuucDp1ApNw34qTyJYYfpe
         P+QTiu0NnPDZJT6PiuAxYFpHkLIh3j50vxxy8FcLUrOAzHFT/gdvkyxMO+A+TOhQBz3o
         fq+J2pC8wqMeAPL86vJ4JfahR9j/TZqrl0F4q2zvnOGUOR8vxuVcsXUIyhnuTMzQMy3V
         9AE6xyC3jzhNLcpPlDh/VXQxi8v4OMOWMN54vVYzHHYFSib3KT0nmEJvSjIpq6XqSexx
         iVLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747811217; x=1748416017;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=CxGiJdansaBYx8iz1FSGBIWSTL36s4XGSNjoYs7TQLk=;
        b=uJFgs+ZGJOUIrXrRKDBfOy9L8xFWbht31xg27G9oWnksYq7EaZssoJ/q189Pq1dua1
         BTZEF/zcjmaBx/CIYFrzXXpInKPSG9F3GD+ozBdoOtfkkd6acDb4Ej7zJV6V4LGYjFV4
         ONNwjIRwA32qjjLYWfbkYiUzgSMynvoRNK3kaFn5NdT0yJGaDcNucDPvPJdO83IiDN5v
         kPUHDR0SF0okRMtcfXnJ034d8ehhzKCXuXL1RUrHSLozzsUlsxHwMRxnfXA/qW475vvO
         6uioHpcHlQjeWtATgxgxM5dECN2AFAwXSz3vjVa2QLFx9+4mpGF81aTEjVTjITy7Qmxa
         t2/A==
X-Forwarded-Encrypted: i=1; AJvYcCUJ76013+EoysUUG5FFJ+Gr3AtuVZ9ox6u69O055PCSRm5DP2CWYkaANxNvfL4Al0IjYUF7pqiUqzY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzcAfTgDY+2ybr5PtjhywjOtDyAG8ehawxf4Pk5q61NWfoSHQqn
	Kw2w8TON7HEImFTfemDZ3njsIsvaPzzbV5OgE1Ra9UXbW9s1chSqTgLz8+YPv/HDsA==
X-Gm-Gg: ASbGncuz9eLYSBJH6+BIVvQPTP+yfChBDe2Ric5Ft9rJDgkAoO/jGd2/KayTvzBE+vQ
	vRepf9h39j3vzwlzxMpE+Tcv/qXPjOjTywCywmWwWixDQdIhaL0ziM/cCENeXmIObf6u/7KhVDq
	jz3u8OaBQf+s1RNvDnQXik1d0I+OPiHMMPIUJpcu1X2/BIhg9/g/H8n6kCFWDOKEZME1AM9ZT6H
	TkLQU6we3Cs4bM2ATKNtPBwMGeioQMnljfAxvBnvhFGndHxnilQFAbeLQlrEAN8wlgv8N/YbFGQ
	UP5J6f7vFbTRup6k8O+352YMNeW+FapctzZS2eMgUspCkhhGBRLf4/FK+6KUYPIvF+9dtHn6
X-Google-Smtp-Source: AGHT+IEzh0IBqxj45Gg3mmkU9VNY2WLCMboGp8hmwoCBeWcDIYQUdFteM4ab2ZlTjWZKYhAYuWa1wA==
X-Received: by 2002:a05:6402:254c:b0:601:a857:52b8 with SMTP id 4fb4d7f45d1cf-601a857586amr12766410a12.6.1747811216633;
        Wed, 21 May 2025 00:06:56 -0700 (PDT)
Message-ID: <847c263c-1fe1-4a68-9962-8d998a3c272d@suse.com>
Date: Wed, 21 May 2025 09:06:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools: Add install/uninstall targets to
 tests/x86_emulator
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD , Michal Orzel
 , Julien Grall ,
 Stefano Stabellini ,
 Xen-devel 
References: <20240516110710.3446-1-alejandro.vallejo@cloud.com>
 <724b77b5-3b78-436e-bd20-726c34bef03b@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <724b77b5-3b78-436e-bd20-726c34bef03b@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.05.2025 23:02, Andrew Cooper wrote:
> On 16/05/2024 12:07 pm, Alejandro Vallejo wrote:
>> Bring test_x86_emulator in line with other tests by adding
>> install/uninstall rules.
>>
>> Signed-off-by: Alejandro Vallejo 
>> ---
>>  tools/tests/x86_emulator/Makefile | 11 +++++++++--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile
>> index 834b2112e7fe..30edf7e0185d 100644
>> --- a/tools/tests/x86_emulator/Makefile
>> +++ b/tools/tests/x86_emulator/Makefile
>> @@ -269,8 +269,15 @@ clean:
>>  .PHONY: distclean
>>  distclean: clean
>>  
>> -.PHONY: install uninstall
>> -install uninstall:
>> +.PHONY: install
>> +install: all
>> +	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
>> +	$(if $(TARGET-y),$(INSTALL_PROG) $(TARGET-y) $(DESTDIR)$(LIBEXEC_BIN))
>> +
>> +.PHONY: uninstall
>> +uninstall:
>> +	$(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/,$(TARGET-y))
>> +
>>  
>>  .PHONY: run32 clean32
>>  ifeq ($(XEN_COMPILE_ARCH),x86_64)
> 
> [starting a clean thread]
> 
> x86_emulator is not special enough to behave differently to the rest of
> tools/.
> 
> Theoretical concerns over cross compiling test_x86_emulator for non-x86
> can be fixed by whomever first wants to do this.
> 
> The very real problem is that this doesn't run in x86 CI, because and
> only because it doesn't have an install target.

Well, I won't insist on any of the adjustments to be made that previously
were discussed, yet I wonder: Elsewhere you complain (at times loudly)
about (building up) technical debt.

Further, without the compiler overridden to be the absolutely newest one
available, coverage of such testing would be limited (especially if some
of my work there would finally, in part after years, be unblocked). Yes,
that's better than nothing, but still ...

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 07:12:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 07:12:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991556.1375391 (Exim 4.92)
	(envelope-from )
	id 1uHdcx-0003yM-Cr; Wed, 21 May 2025 07:12:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991556.1375391; Wed, 21 May 2025 07: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 1uHdcx-0003yF-8y; Wed, 21 May 2025 07:12:35 +0000
Received: by outflank-mailman (input) for mailman id 991556;
 Wed, 21 May 2025 07:12:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHdcw-0003y9-9c
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 07:12:34 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f6c7a32f-3612-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 09:12:33 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad1b94382b8so1156983266b.0
 for ; Wed, 21 May 2025 00:12:33 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4383f8sm849729066b.113.2025.05.21.00.12.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 00:12:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f6c7a32f-3612-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747811552; x=1748416352; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=k3AJnoLl/PZmaCOh+D/CsrVhF9m29JVSHBsr+xfTkLQ=;
        b=QJcptmQSurEq6GV1zsjggoKM1TXgj/Hp/h6u1GRL0lKFAsw9tohlnFKDKbA9VtjuyN
         +SQamVM9eDHwkpsH71w5O+taSk1JW3lrBPGdT4WekePvzv8KwFq2oUxjKktmSMXzOSGJ
         i1eVOe+7uCl9H8Z267ePwbmNJIDLXCaVTcPv2ie2x9881H17xQIEW1eTKq5h/CM2GEab
         SU+ThQBQVpFGqfiBSino6C9PfVo7A+BmJOFP9/1BEWKgtppRAivbE3MgDXGnltAn9wX9
         Z2YCJy1Jmrfr/LQ4CGyq/Tjk+T7t/OXi0KGGb46NXtDPZKcRGZyr2BSNp6FxY1wTcR+6
         IJQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747811552; x=1748416352;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=k3AJnoLl/PZmaCOh+D/CsrVhF9m29JVSHBsr+xfTkLQ=;
        b=wZlW01eQW7ZTMTjxhCUWFkAYNp+1X4nCkG+0C7YFSse6EIQH+GMdkucwWp+WFkzudC
         Rmtxb3hyywB54jwfZlLln6laoD1YfnqTR23ojOkdGuOJihJO55/snZC18ZkAZUCf8E0W
         DUaabnOTGACoG8f0YWUuR2Y/bggzfpv262b2L4LMmCUrQcr81pVEWkisxIVscJF0MFV0
         4A8Jbz2Q2IIhRv+svrl2/pnCZoBLGV5o2Kp4ppRVKA9PvOgkaOui6ks2KoyRRXZ24Hr5
         MWq/j1GHFTaeXVWLDRIwbHJRT0qqHovkQbEwzzgLcbBGado8GG8asjFFo4Q7uSgMJlT+
         Rx/Q==
X-Forwarded-Encrypted: i=1; AJvYcCV+AEsFrn753byblX4ITpSZGhcftasWAaxVnnS0yQRlDOz8wGcDYlAnb0O+CTgug1PcomRz5Z6QSZY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx+Itnsi7/aByQGuSYelg/Wo2wGTXhhPDoajBrAzIH0yIt7J67R
	FjljCvNqOglo2IOfH1FpWffpnB++HRZxIQ0ksPkW6YF30IFhi9DujsybtUEjyAZdXQ==
X-Gm-Gg: ASbGncto4r0KOo9mjy08ilgfhS19tnMIMxLPBtP1cSgDMZlxdOcUWXIU+tiXMuFoBst
	bcBoyaX+15+035L8OzLgbifFsqtJDI89NUlfdr11/PRWQZKuNRCobZ2t9Zw05A56LXA1NwdtHZd
	PK7nO51PFaINX3/dtj3W80qp605iy8LNOaPjIpU3Wo73axnoFZFoiamCAmW6h+HYzgvuWJ9ZOMc
	eHr7YBF8e23bhxvBL73nFPP/beKcDQLpo1lm+IKLPdnysH3s7fgxJegmaCGq6kRDp0DoLyOcLm+
	/BDH0ykGnXfLWxb7J4yjZpHXkXNGIxi8K2Ee2LsuhLXcy+WhHaKZoxCRSSDNCQ==
X-Google-Smtp-Source: AGHT+IGBO0sTv5dXPNewLw1595h3fjHh4UiKlQI5lLMv5LDHTLk0MkGo8hxn1BmUGKDphF/4c6wo0g==
X-Received: by 2002:a17:907:97ca:b0:ace:f2c2:5a4 with SMTP id a640c23a62f3a-ad52d49e2c7mr1787732066b.13.1747811552216;
        Wed, 21 May 2025 00:12:32 -0700 (PDT)
Message-ID: <528bd2ae-d33b-4038-92c1-c9ab1ccf0bb7@suse.com>
Date: Wed, 21 May 2025 09:12:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] MAINTAINERS: include Argo documentation in the ARGO
 section
To: Christopher Clark 
Cc: Andrew Cooper ,
 Daniel Smith , Rich Persaud
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250520233220.868258-1-christopher.w.clark@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250520233220.868258-1-christopher.w.clark@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 01:32, Christopher Clark wrote:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -226,6 +226,7 @@ S:	Maintained
>  F:	xen/include/public/argo.h
>  F:	xen/include/xen/argo.h
>  F:	xen/common/argo.c
> +F:	docs/designs/argo.pandoc

The list of F: isn't alphabetically sorted here, yes, but please let's
at least not make that problem worse.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 07:20:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 07:20:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991567.1375401 (Exim 4.92)
	(envelope-from )
	id 1uHdkO-0005XZ-4Z; Wed, 21 May 2025 07:20:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991567.1375401; Wed, 21 May 2025 07:20: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 1uHdkO-0005XS-1u; Wed, 21 May 2025 07:20:16 +0000
Received: by outflank-mailman (input) for mailman id 991567;
 Wed, 21 May 2025 07:20:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHdkM-0005XM-HA
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 07:20:14 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 09510780-3614-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 09:20:13 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ac2bb7ca40bso1080747166b.3
 for ; Wed, 21 May 2025 00:20:13 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d04772dsm851807966b.3.2025.05.21.00.20.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 00:20: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" 
X-Inumbo-ID: 09510780-3614-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747812013; x=1748416813; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=3jxvm6IcmIUDIP+aplbWZYaDXzlC2kGeTNNoKsfuqaY=;
        b=gnt3gcVwe187vBIetFnMjvfcSfwFrOinJyhnyIfVMHARw2HqIC4yo/7Mgc6oF6NWC0
         tylXmX2byNDRyuVob0QauJHtIdaadBjWvPEOBaYL8cNnCKDGasHZ6GDI63an+5OFGZnD
         nID1/MStif9d834CFA+a+qUXFjLkCZLHsCyX9Xd3Gvegauan8qgVq7NbKtWIiEGtiIm8
         Q6cbz2cFMbPHbLC4Hb9RVDdKjBPj4DPxRTLBknEBs2206GP30g/XZ+l3OyacWagyCGiI
         CqoIzw9UBiqna48SINsgswNCWTYeOy+5GCOJNrsALtEc1EV44acqr0P8hu6fgDvkz7bh
         7rnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747812013; x=1748416813;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3jxvm6IcmIUDIP+aplbWZYaDXzlC2kGeTNNoKsfuqaY=;
        b=LSZr+1uRRbucuzdE1rfCuN0CriGgcEIS3sBmqSfXeZEoWzMkw4GMsagkPtQjvd48tE
         t4IEcIItn0GfvK169cuILHUtp/agoEWktsjLf+MFawJf+Nf8OPvQOLEDzdZGS7x6gais
         Gur4cP4gAuAUKj2FvIFvYWVegAsU6ibpHxsKAiv3VM9mLdLOGTGtg8ERzPgWBoSMQicC
         1P45CzAmIiDsEzv/8uut6SPafkOwihfy3cZ3T5GTBBEqSONNnAQSxgpuTT/M4fcm4bvc
         4b705GbQMOM98VJ3vIVxxye+H3AExhpfGZeTTnaJJ9RYTQW3eC3sl+MR+yaBrp3EcEQb
         cBIg==
X-Forwarded-Encrypted: i=1; AJvYcCXlxgrNu6r3gLLVm/Wf9RkeMa4gmR9W6YgCwkqfhbsRdWiRIeA+ng84YHHkqQlHRq2yHOA1J9TsR6E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyNBpMvHc8crSDRkFNzwTY2WR5lH71bx2100PylaQn+Ssyu3XKc
	c1T35vlQl5p8+A51yxLJ3o6gVWzBBQgnTn5avbsRawcFQCioM+7KQVchT7YmoNHdug==
X-Gm-Gg: ASbGncsSrOxzl/aQkgp8AEcDS1jHH6go4j/7uhGsUGPRLrPfyBOxKVGY60pltcBESrF
	sBWBN2PRaoMFxWZcI17RVVbRar1amquaSasLkYl+2RKvsxZj76IzX03aJhRPm/IX63u3DUlepza
	hcYFGEX3giz22xLVTNHQpLr0htVWisc8erv/27HANVloJUTZM+NHOkHsr2ETr+feeH/2CjB4wdq
	zz9IWY9umYFMrhYYQDwnylxw5FTcXJbmdH9r2nLu47kc3pFuAuK6WO5UC/qQIBvx7q2mLcZ1aN6
	O9wGvW6GbBrQull2eQ3Nqc+bAbw2p4ZSM8XrgauXwGokfzSM+dUIv6/1vHCAEg==
X-Google-Smtp-Source: AGHT+IGhrMMvnm5iCBosWgs/2cS8yrw1x4bluqd9yizzr0PH7R6+pt7UH8V0OpUtO4jHnRuyblN3Yg==
X-Received: by 2002:a17:907:7da9:b0:ad5:a215:7271 with SMTP id a640c23a62f3a-ad5a2157651mr275200366b.17.1747812012834;
        Wed, 21 May 2025 00:20:12 -0700 (PDT)
Message-ID: <150cbc21-9d7b-43d8-9204-417e9d5f5dbe@suse.com>
Date: Wed, 21 May 2025 09:20:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] SUPPORT.md: add xenstore stubdom as supported
To: Juergen Gross 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20250521044634.11361-1-jgross@suse.com>
 <20250521044634.11361-2-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250521044634.11361-2-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 06:46, Juergen Gross wrote:
> SUPPORT.md is missing a suupport statement for Xenstore stubdom.
> 
> As SUSE is using it in production since several years now, it should
> be added as "supported". This covers the PV and the PVH variant.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Wed May 21 07:31:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 07:31:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991579.1375427 (Exim 4.92)
	(envelope-from )
	id 1uHdvQ-0007py-8k; Wed, 21 May 2025 07:31:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991579.1375427; Wed, 21 May 2025 07:31: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 1uHdvQ-0007pr-5a; Wed, 21 May 2025 07:31:40 +0000
Received: by outflank-mailman (input) for mailman id 991579;
 Wed, 21 May 2025 07:31:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHdvO-0007pl-JW
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 07:31:38 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a02f6289-3615-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 09:31:35 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-601fb2b7884so4432403a12.2
 for ; Wed, 21 May 2025 00:31:36 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4382d7sm850841566b.117.2025.05.21.00.31.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 00:31:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a02f6289-3615-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747812696; x=1748417496; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=JmlJMmB9hmskFmXM43qBGD194jQ0zMmOFRlp1/Eji0I=;
        b=SCHk6lUSWA745wkXFYu56u+pee2emPliUa500OyezRoVhHWUDgG672Kpt6rlAM5zTg
         Uw5D0YRQq1xWtvYROSDC6Z6e7mp/mFiXtPpCkpgAxkuWxxb4togjvn0NC8J3a58pNOwl
         lF7rx8CxxqwxTP64ldUU6LELWzyl0ZQ6OG+/ixzMl+8FbnGnRaB4dY3AEvUDSoj91pZz
         GwlTScNTp/HdAqNWrVnHe96VQGG/O5oto+yulhgg3+J+JkRSqvv8RLFm0lfRyysFcafi
         1u7Yr2r69zsqlJfZYOwe5r+70FCKd2tPSJBK0WMDNrLzIqrLOJ7F95xulYqQCYo4wmg6
         uOYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747812696; x=1748417496;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=JmlJMmB9hmskFmXM43qBGD194jQ0zMmOFRlp1/Eji0I=;
        b=FFu8Z6JV9fLfAgm+o4P3QWjjZhHUCjcLezxg2NbCSdBryKeHwvhQaU8jupXzXp3VUU
         ye0nivVYzxZsN7nLCvxQCU2Eiub6yvBb0+LLovs3C9Wj8v4t/l6JFbA3Myo89Z28mpGa
         dWXbbK03Ha/kwwNIJ2Lzs+cMXMpzhlYK7O3ZPgkcSrBThn12e+zgzM4jK6cazoi/sgb6
         IZj3vz14TfBwziY1KcbC3pgh2PjZryoYdHOKBXg05Imtx3SAROp/n2/LlOfcEGqGp/nO
         KGLq6Rv5G3dd5bVLYjuJcKmL674u523dLIPKueOXanMr+W/Y5QM5BViIBB+bkYZG45MQ
         hK+A==
X-Forwarded-Encrypted: i=1; AJvYcCVkwKjzwTZcY2M/8fPJVyb99DZTWoDc+jb7fx04popz0hBFex11MS/rTn3xpfL4dvRysxqtZaP5C4U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwUY7dt80C7skdqIsXuvhN5bdkcCqv0aknrjP/WrkvQNLEzzBkK
	3G9EbuLwuUF/XQ2i5gaSPlOO0o56WHnvdy0sXAaeG5RJ8F0J4T+M+HYZWl5yPTsR+g==
X-Gm-Gg: ASbGnctg9QiuswCTMHUg2SJfoEZXbkJBxym6m2y73yVX/gldEM6rpOUEMd2miSVnTYp
	yotUWusi16jcCQfFLOqiov9Bij6rnU2Zb6jQcLwKgTccBKZGPKuGqCkDiZ9i8087rheSf/q1do5
	Te3S8fw1URh+r8P65u+dZqejmMJFeWHogfjui4M1QmOrGwiuw+2hNZTOVv4OS98YlM+caivaA//
	ndh/DV2F8fdw6FMvn5qCXTRx6ouFKsnkISLlkZEbeKZO/R0FdvabafnrxXcgim9Zv8dLbr3F1aw
	gF6Opoh4G+aTVGRC/wYKstoxBNyqbMTY/Dfj2uNlKtqHAUCUFxWSdMhifkOqUA==
X-Google-Smtp-Source: AGHT+IHRrFX4PcoDI2sl45JkPnjIpvyscpxQRg9K+LOh9SPbPt6UGSK55tPG1qerUK8HUUmQy0pmzw==
X-Received: by 2002:a17:907:944a:b0:ad2:4ed5:ca4b with SMTP id a640c23a62f3a-ad537036e7amr1525198066b.61.1747812695477;
        Wed, 21 May 2025 00:31:35 -0700 (PDT)
Message-ID: <54945bd5-333e-4ffd-8ff1-bb89d22c7ef4@suse.com>
Date: Wed, 21 May 2025 09:31:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 3/3] xen/domain: introduce CONFIG_MAX_DOMID
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250521000024.2944685-1-dmukhin@ford.com>
 <20250521000024.2944685-4-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250521000024.2944685-4-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 02:00, dmkhn@proton.me wrote:
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -331,10 +331,9 @@ static int ffa_domain_init(struct domain *d)
>       * reserved for the hypervisor and we only support secure endpoints using
>       * FF-A IDs with BIT 15 set to 1 so make sure those are not used by Xen.
>       */
> -    BUILD_BUG_ON(DOMID_FIRST_RESERVED >= UINT16_MAX);

Why's this being moved to common code? It certainly may have a purpose here
(which I'm simply unaware of); I don't see what purpose it has in common
code.

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -576,4 +576,11 @@ config BUDDY_ALLOCATOR_SIZE
>  	  Amount of memory reserved for the buddy allocator to serve Xen heap,
>  	  working alongside the colored one.
>  
> +config MAX_DOMID
> +	int "Maximum number of user domains"
> +	range 1 32752
> +	default 32752
> +	help
> +	  Specifies the maximum number of domains a user can create.

My prior comment remains: The description and help needs to be accurate, in
order to not cause any confusion. In a true dom0less environment I'm not
sure the "user" can create any domains (post boot, that is). And when there
is Dom0 (or late hwdom), the number specified already isn't the number of
domains one can create (again, post boot, which is how I understand "user
domains"). If someone picked 1 as the value here, it's unclear to me how
late hwdom or dom0less would work in the first place.

> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -36,7 +36,7 @@
>  
>  /*
>   * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> - * If it is specified as an invalid value (0 or >= DOMID_FIRST_RESERVED),
> + * If it is specified as an invalid value (0 or >= CONFIG_MAX_DOMID),

In the public interface I question the relevance of any implementation
details of the hypervisor.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 08:03:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 08:03:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991589.1375436 (Exim 4.92)
	(envelope-from )
	id 1uHePl-0003yl-Lg; Wed, 21 May 2025 08:03:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991589.1375436; Wed, 21 May 2025 08: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 1uHePl-0003ye-J8; Wed, 21 May 2025 08:03:01 +0000
Received: by outflank-mailman (input) for mailman id 991589;
 Wed, 21 May 2025 08:02:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHePj-0003yY-MZ
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 08:02:59 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ffa348d8-3619-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 10:02:54 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-6021b8b2c5fso2387111a12.2
 for ; Wed, 21 May 2025 01:02:54 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d04b059sm869953666b.10.2025.05.21.01.02.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 01:02: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" 
X-Inumbo-ID: ffa348d8-3619-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747814573; x=1748419373; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=8RKb0K7otHgP7RzDk9UByehX8X7QlZO9RoYs09s8/hk=;
        b=IYil/KNBW1X+PsRTnEbkYFHN34g4HJq/gPs+tHSXoSFrebKUEJnI4hgJfjK3w15KB/
         ZNwx/dr8tcZD3i2JuOGY60CCDipKSKd6PHFumbdJ0rYfZ72jMbf0IdOQnmWyVEuBTEQt
         pnDMyMrkfdf6iUPj1h3szPmFKE9dnO31jkEykOwduPGwKWbgWO1vcVqRxnxKHS/VKbCI
         9h7kIGS/6CzdAtFG23VygJT0ds82zTBcpn1RyAlt/0abIjojG2a2IWGutkYLGYamSj1Y
         UeAkTOSmmM2NX8d2xesz2KWXF+pLp6NEXef1s69RZFqnRegVsa00/mIGKioFH6hSCqkF
         Vw+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747814573; x=1748419373;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=8RKb0K7otHgP7RzDk9UByehX8X7QlZO9RoYs09s8/hk=;
        b=GJl0B2qlFKgD/M97EjNqKmUuqvqEqPXabR4YkruIzt3IqA7058TgMxuBBDFg/U4xNq
         P+3w362QBMCJAlUY+8hyaLye2CEQy3SifaoUr2wpcQJMlzOC9+U4MtmVxe8FpFdj9Jf5
         QXeM7Z4+Ekk8bBY5UcTFLdWy6D1rAgsfXUxsOujH1hBbRAxM9MdXJmOMElrQfI0Ld8aG
         JSkQIWbeAw2isy5U+R4aDCslwb6uQAp3VATFN00QzjOWaKvH8EmvruhD2RCGOT/agqf4
         A6rMfGnPAEV5OhMYgZXdnzPDOe/7ZHpkB/FnjHCDnnaGukf4X8J8Y8Dog6NGNAup0bjG
         g00A==
X-Forwarded-Encrypted: i=1; AJvYcCVSNpjiV4Vf2piVsWvlzT9zXBxJptSdyOnN9YcEOtALzUrg6eGprxdgpNttB/L4CPpZdXO/N0yj20g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwbSsg5n8rR8bVKThZPlXIaUMHw2OoPIP9Lp90sHvUvQIskdafW
	0cH1sxmjO3SZyPg1B95lzEhSFi8ZksMJXc6+xC7CzKWvfagtmOxhQzL5KVIUpq71OA==
X-Gm-Gg: ASbGncvGpJWJzdPwE+Pe4kxNMA22SRZF5AupVvftCrG2VwyLidsqho4TacLA5bOYAv9
	SLLJ5YpFKVhCIL8RjkIw52J+humx2qZiT1VwuKHR8o5jPXStQglBSKMtM79Hi+7VFb6CvuGKxED
	QCCb6Idomd9imlZa3hBze5dDe56P/6LpHvJB1vk+n4JRM+0OO2TtJ98BH8Rk0o012uZ8CB+5or2
	GX47oYgIyHZnEnA+h8/04cH/My0WXAbzExxDqYkX8/8iPLQqzRAtFvb86sS40sZnwLp5UJa1KqS
	EQW19IxdItDvvosQGFBa59Qwsrar5L+MBjUuI+OnJUfk0ZnnGK1tg0QA0bPi3g==
X-Google-Smtp-Source: AGHT+IEND500oVlNJLsvfzvE8jA4wdHt87LyiNW3spphFfaYZ4JjLnPNiwijKC6n/CYM3yRrQftDFg==
X-Received: by 2002:a17:907:980d:b0:ad2:3f1f:7965 with SMTP id a640c23a62f3a-ad52d43838fmr1945414266b.4.1747814573541;
        Wed, 21 May 2025 01:02:53 -0700 (PDT)
Message-ID: <675950c9-f48a-489e-9ca1-816d876fbcbb@suse.com>
Date: Wed, 21 May 2025 10:02:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 1/3] xen/domain: unify domain ID allocation
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250521000024.2944685-1-dmukhin@ford.com>
 <20250521000024.2944685-2-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250521000024.2944685-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 02:00, dmkhn@proton.me wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -66,6 +66,11 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
>  static struct domain *domain_hash[DOMAIN_HASH_SIZE];
>  struct domain *domain_list;
>  
> +/* Non-system domain ID allocator. */
> +static DEFINE_SPINLOCK(domid_lock);
> +static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
> +static domid_t domid_last;

Please move this into the narrowest possible scope. No reason to expose
it to the entire CU.

> @@ -2405,6 +2412,46 @@ domid_t get_initial_domain_id(void)
>      return hardware_domid;
>  }
>  
> +domid_t domid_alloc(domid_t domid)
> +{
> +    spin_lock(&domid_lock);
> +
> +    if ( domid < DOMID_FIRST_RESERVED )
> +    {
> +        if ( __test_and_set_bit(domid, domid_bitmap) )
> +            domid = DOMID_INVALID;
> +    }
> +    else
> +    {
> +        domid = find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED,
> +                                   domid_last);
> +
> +        if ( domid == DOMID_FIRST_RESERVED )
> +            domid = find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED, 0);

Despite what the last sentence of the description says, there is a subtle
behavioral change here: The original code would never return what was
called "rover" there. If the most recently created domain went away, you
would return its ID again here if no other ID is free (which is easier to
run into with patch 3 in place, and MAX_DOMID set to a pretty low value).
(Noticing only later: This could even occur without wrapping, as the last
argument passed is just domid_last, without adding in 1.)

I agree it's debatable whether using the sole available ID instead of
failing wouldn't be better(?) behavior in this specific case, but such
definitely can't go silently.

Furthermore you once again are potentially returning ID 0 here (after
wrapping), when the original code specifically avoided that (irrespective
of there actually being a Dom0, that is; i.e. covering both the dom0less
case and the late-hwdom one).

To be frank, being at v8 I find it problematic that there still are
(unmentioned and potentially unwanted) behavioral changes here. This
kind of supports my earlier raised question of whether we actually want
this sort of a change.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 08:29:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 08:29:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991605.1375447 (Exim 4.92)
	(envelope-from )
	id 1uHepP-0006nO-L4; Wed, 21 May 2025 08:29:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991605.1375447; Wed, 21 May 2025 08:29: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 1uHepP-0006nH-HJ; Wed, 21 May 2025 08:29:31 +0000
Received: by outflank-mailman (input) for mailman id 991605;
 Wed, 21 May 2025 08:29:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHepN-0006nB-HA
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 08:29:29 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b5ca6e19-361d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 10:29:28 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad545e74f60so744631866b.2
 for ; Wed, 21 May 2025 01:29:28 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4cc7a8sm872832366b.171.2025.05.21.01.29.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 01:29:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b5ca6e19-361d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747816168; x=1748420968; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Uw9vCptajLCeHOpMP1Xf2Y0cZdP7pIFtckH6kWEL4bg=;
        b=cFY8ELdNgR2e+ZJdIheM5Yv7m3U8fPnR3WDYPs1ivq0dGpiwb8dXnPvkjc2wdrdIDS
         W2G5FVHGS7hvgnnSFq8WDsDy2C3WUWR1G5dUFFwOTfm1fBdFI+KCzr30THpYjS5zrbvB
         gTb1ubwyeNtzLvROOgCGF25qfN9SXk0PynM4K7PleZFPlHYmafHOZiXrdhxBHfWxYJJz
         YHwMCTg0WlAiEcvFagz7F5dNjfO3V8OyWQJLEROje6V7KM+udnWHOsbRyXtr8cIqc0iH
         /CihrVx7I15y+LdED9jxBpToPyKTKQj8MkhhIdAkK0kcgpmN7CvK4qZOVlwJjCZc6HTT
         emxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747816168; x=1748420968;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Uw9vCptajLCeHOpMP1Xf2Y0cZdP7pIFtckH6kWEL4bg=;
        b=NQDktDLv7yamw0OI3cUSgh2BRBAz9dcMibJzw6jSSmXP1ckBS5X6yNCnqXSxVxzd74
         D4d2Y3tn3FtcOJ/y24zmHiaCTnsbtOawcbO/Te8wM5wkVTmLNVchAmzT5+EpAHyC9E7O
         Z/zTJ/utCbdeWmc/7mw2PTNdODaEag0hBolmFxH08Kg6OTfdG9HHnndUg7nSupj//qE+
         GOTZFYqxqOSNHG8eRCAFGPcx0d6nwPIMdg5HR1gygmubDHTO/ZxhwI5EzNCrRKwgqeWk
         j63+CcXrZt+Gr3SEsGj3zWjhuU5/U0wAvm6fRZXWRAWTuL9KZEyqKjdSc854SCSD1Tiw
         mvng==
X-Forwarded-Encrypted: i=1; AJvYcCX4GOXpoI4JPCSJb+USv+rVgqOT/55ajvKK6wV34+9CpI+Pl1jmeNf3eT/gap29RK6LaSjl4pApWno=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxWdX5tokuy78ovxYu8WL4cDbj9lmrShMDFXQVQjReqprXYAbDw
	cKkeLqzqJ/rDLy5g1xqf+Pf3avBxDeZmkyMT8xVQUA47LY4r4PsbeBMgIeFJd7sptQ==
X-Gm-Gg: ASbGncvo+4knJmHsIiXrJL8eP6uCe4XPVu9zNV/ms3I/VcC0eUFRI3HHl8miDlZ5l6O
	XDbpF8rGBW5AGVu21fd9z5K57WWC/QXygBIb2tOB8qbwKZsA/ihyRlAQfb5tkw/o9sy+hn6N6eR
	Whmxozr0neFJyCtxvts2vxTAzNPd1aLEU0GUfWatu2l+kV6XuyVLBs388OfbKGqzCx2onPoa9AX
	eGWdiy5gRTCs5eg+qPmx4yebgb6f7pgiR/TAqY6Efs32/oF0CrLanss4wsAuKqrcryX1FcRCI4+
	qidk/btw/Wgj8XEQVk7CEwOFg+l9Lr/vJ8Mw+BnVqq+P14We3uNjdmXe4cK18Q==
X-Google-Smtp-Source: AGHT+IEc3+z6LT0G8rfYrS4kGKYLWQvqnYNR3TM89Y0NWuqJ9gZJIvznzeXOgqVuEuOZmw/EhUHffQ==
X-Received: by 2002:a17:907:9805:b0:ac3:3e40:e183 with SMTP id a640c23a62f3a-ad52d42c08emr1938156766b.3.1747816167942;
        Wed, 21 May 2025 01:29:27 -0700 (PDT)
Message-ID: <7bbc1569-672e-42a7-a5b8-4187282fcb18@suse.com>
Date: Wed, 21 May 2025 10:29:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/vpci: fix handling of BAR overlaps with non-hole
 regions
To: Roger Pau Monne 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Stefano Stabellini ,
 Victor M Lira , xen-devel@lists.xenproject.org
References: <20250516083159.61945-1-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250516083159.61945-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.05.2025 10:31, Roger Pau Monne wrote:
> For once the message printed when a BAR overlaps with a non-hole regions is
> not accurate on x86.  While the BAR won't be mapped by the vPCI logic, it
> is quite likely overlapping with a reserved region in the memory map, and
> already mapped as by default all reserved regions are identity mapped in
> the p2m.  Fix the message so it just warns about the overlap, without
> mentioning that the BAR won't be mapped, as this has caused confusion in
> the past.

I was trying to get back to this, but my attempt to use this "fixed
message" as an anchor failed: You don't modify any existing message, and
hence I was unable to determine which other message you refer to here.
None of the ones I looked at appear to fit this description.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 08:52:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 08:52:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991615.1375467 (Exim 4.92)
	(envelope-from )
	id 1uHfBJ-0002MB-Pe; Wed, 21 May 2025 08:52:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991615.1375467; Wed, 21 May 2025 08: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 1uHfBJ-0002M4-LZ; Wed, 21 May 2025 08:52:09 +0000
Received: by outflank-mailman (input) for mailman id 991615;
 Wed, 21 May 2025 08:52:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHfBI-000287-M4
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 08:52:08 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df0028e8-3620-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 10:52:06 +0200 (CEST)
Received: from pps.filterd (m0333521.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54L8SorW026372;
 Wed, 21 May 2025 08:51:57 GMT
Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta01.appoci.oracle.com [130.35.100.223])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46sahbg660-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 21 May 2025 08:51:57 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 54L7sbuL034540; Wed, 21 May 2025 08:51:46 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 46rwepjaqp-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 21 May 2025 08:51:46 +0000
Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 54L8pjuh027328;
 Wed, 21 May 2025 08:51:46 GMT
Received: from ca-dev112.us.oracle.com (ca-dev112.us.oracle.com
 [10.129.136.47])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 46rwepjaq9-1; Wed, 21 May 2025 08:51:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: df0028e8-3620-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=corp-2025-04-25; bh=As9JDv7IWpzCSGWcv7pVzMu79+syJ
	SOzE0AhtTJB65E=; b=I++XWayzFyWrJYK66Tzza35MAfJ2CaKGttV9QI7/oxUtB
	l375Oby7JSFX8L+pFaFh3mgavZH7T4L/fC3lZapPqGUSBuvTiblnNQFSJvD6fx8g
	aCXvEvtCVeUqRY8qlN0H99lfFXD7R2gbQyMfbmS6I4mTwQJOgSp7lmzsw6uVh1IM
	xp49ycZ38GX5vbrQT+RuBfYzaRT1Y3YP5fgwH9MnyQobbSt7rZJ9qigo1mN3W1pt
	kHsgEH2/Ctpxv7xjZZbFvv7HfgS2N0iFiscJlR1LpeKfDjErF6NjVChCWXC5yRj0
	N9ladLl1FeEpFhqdlOIfwUhdtjwq4iB9HPjSLlt+Q==
From: Harshvardhan Jha 
To: jgross@suse.com, sstabellini@kernel.org, boris.ostrovsky@oracle.com
Cc: harshvardhan.j.jha@oracle.com, xen-devel@lists.xenproject.org,
        iommu@lists.linux.dev, stable@vger.kernel.org
Subject: [PATCH 5.15.y v3 0/1] Manual Backport of 099606a7b2d5 to 5.15
Date: Wed, 21 May 2025 01:51:43 -0700
Message-ID: <20250521085144.1578880-1-harshvardhan.j.jha@oracle.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-05-21_02,2025-05-20_03,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 spamscore=0
 suspectscore=0 adultscore=0 malwarescore=0 phishscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
 definitions=main-2505210086
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTIxMDA4NyBTYWx0ZWRfXzIBt0qr/N4Qv vtKmnRNDXYddRLaThAtraoQY5Ts2KnLUq+9lkUMOUS44CD+Qp/QiSGM3q6I+To4yk87t8eX7CnI GaRj7y7bh864o3LN6+1XB8IF4dAzADcrcrtYfvEtO2ln0IgtNpSaD+Pz8VwmismULbC+zQUHmkb
 EEjrSvqLfHLYNr2e4MddNio5O/N/zFwAm/Jd+2Wesq2q9eeQC1AUGykwTs7xOLz5nvDlrSUrl+N nPtJx2Kb3Y+U3U45Wy4V1YOKqGoVRdpoTIiKUqXOxxgH+gCiRqB8O5h7yPhZeUr+Isa5q6kqX3O zmvu/DlXSRqoHEkinOS3KLO9tSX5byTdJowoj5V9lLPh34seiyMOAXGV/0Z4WUe1JNXtzM4Rnsf
 k6gVseQRX90J2GCS+j4ZnqRCT9QkAP0oXo0PJsSVGkDJrZhzqMep+z3ixRPVT2ZgmSEiDTob
X-Authority-Analysis: v=2.4 cv=VY/3PEp9 c=1 sm=1 tr=0 ts=682d942d b=1 cx=c_pps a=zPCbziy225d3KhSqZt3L1A==:117 a=zPCbziy225d3KhSqZt3L1A==:17 a=dt9VzEwgFbYA:10 a=rs8Xjf8ku5-kuHtvfxMA:9 a=zZCYzV9kfG8A:10 cc=ntf awl=host:13206
X-Proofpoint-GUID: dthhuNeQH1ofGErp_6-Hlq4B32MpNnHS
X-Proofpoint-ORIG-GUID: dthhuNeQH1ofGErp_6-Hlq4B32MpNnHS

The patch 099606a7b2d5 didn't cleanly apply to 5.15 due to the
significant difference in codebases.

I've tried to manually bring it back to 5.15 via some minor conflict
resolution but also invoking the newly introduced API using inverted
logic as the conditional statements present in 5.15 are the opposite of
those in 6.1 xen/swiotlib.

v2 of this patch was added and dropped due to some issues in testing.
However, after further verification this version seems to be right as
is.

I kindly request Juergen's ack specifically before this is added to
stable queue as this patch differs quite significantly compared to the
original.

Changes in v2:
Include correct upstream SHA in the commit message

Changes in v3:
Patch remains the same, however further verification and testing was
done.

Harshvardhan Jha (1):
  xen/swiotlb: relax alignment requirements

 drivers/xen/swiotlb-xen.c | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed May 21 08:52:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 08:52:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991614.1375457 (Exim 4.92)
	(envelope-from )
	id 1uHfBI-00028K-DM; Wed, 21 May 2025 08:52:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991614.1375457; Wed, 21 May 2025 08: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 1uHfBI-00028D-AL; Wed, 21 May 2025 08:52:08 +0000
Received: by outflank-mailman (input) for mailman id 991614;
 Wed, 21 May 2025 08:52:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHfBG-000287-SG
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 08:52:06 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dcc2233a-3620-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 10:52:04 +0200 (CEST)
Received: from pps.filterd (m0333521.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54L8Spjg026402;
 Wed, 21 May 2025 08:51:56 GMT
Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta01.appoci.oracle.com [130.35.100.223])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46sahbg66d-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 21 May 2025 08:51:55 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 54L7i855034623; Wed, 21 May 2025 08:51:47 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 46rwepjar3-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 21 May 2025 08:51:47 +0000
Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 54L8pjuj027328;
 Wed, 21 May 2025 08:51:47 GMT
Received: from ca-dev112.us.oracle.com (ca-dev112.us.oracle.com
 [10.129.136.47])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 46rwepjaq9-2; Wed, 21 May 2025 08:51: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" 
X-Inumbo-ID: dcc2233a-3620-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=corp-2025-04-25; bh=YCUn1
	PIbwBCxw1cn97O5FsKta9uLJW/+01K2MDVFP7A=; b=UcT01hPmJJP9Az+0HamHp
	GRVQE4qd9IrqBk027upBdONbhbR3Hp9I1JtA8nyimgJGOBy8vz1kCZrwp80Lc1ML
	bfoC5Yjnfw1rOPKCTDZX34QQDJxIVdEg81Jnldkf8JrXk+MIUram4f6/IzMO01EZ
	GgMYpQTKFXVpqocVmxqC3mWTEQqVALe+SOlefwYzw7Lm4PLJ/pDSPZvweyg7IfXS
	5a7jc2xYvhzhtOpgYZYsen5k800AISAUbBZxzka94hYIKp6Sy5sn6S0WJy0Yhi96
	LgsdrNOf9O+xP8mqk+NfImd72Oet7IAlymasE47wHIlEG82oUBdFbTjdQ9Rrf71C
	A==
From: Harshvardhan Jha 
To: jgross@suse.com, sstabellini@kernel.org, boris.ostrovsky@oracle.com
Cc: harshvardhan.j.jha@oracle.com, xen-devel@lists.xenproject.org,
        iommu@lists.linux.dev, stable@vger.kernel.org
Subject: [PATCH 5.15.y v3 1/1] xen/swiotlb: relax alignment requirements
Date: Wed, 21 May 2025 01:51:44 -0700
Message-ID: <20250521085144.1578880-2-harshvardhan.j.jha@oracle.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20250521085144.1578880-1-harshvardhan.j.jha@oracle.com>
References: <20250521085144.1578880-1-harshvardhan.j.jha@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-05-21_02,2025-05-20_03,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 spamscore=0
 suspectscore=0 adultscore=0 malwarescore=0 phishscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
 definitions=main-2505210086
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTIxMDA4NyBTYWx0ZWRfX8f+U4oe/EQtS R/xiEPxMlpCBYcGuSQb5iApcpwt2bmOsBhLJna3sBQCLd5HDWYDNekKfY1QecnMQlfdNx1guQ6w b/HUBOQfH7SoRiXARMavCgfslIukAR6mpQBKRmmdISRxAjwX6iI7UWFK5QC5E1xDh6hQe9N4xCP
 Eg2fBmmEj79OkO1rnHahTu7bL7m+1rupo5HbijlmQzaxeGePPTFe4Ef/N9bQaXxHBGvKgwrCLRN FpUS51MqTZzh+1sp4UqjSFsHwL9cRzsaXXLNS3pfgY05jzK3q+bPLbHPhyEtoB0Y3gQ8l0iZI5J Ddu3ekRaYU3wNbFgYy77CAe0B5hT33E2I4FHNhGOrJbqyF5TK/qecCK9T9oP9ry31JAw9qQKenb
 vh5j+AJUHZwQMQUP/VcVcHMNcVFjAQR4AQc0ly/5ZTGEy7hitICqG1D1CGIjmDF75kfUMGHi
X-Authority-Analysis: v=2.4 cv=VY/3PEp9 c=1 sm=1 tr=0 ts=682d942b b=1 cx=c_pps a=zPCbziy225d3KhSqZt3L1A==:117 a=zPCbziy225d3KhSqZt3L1A==:17 a=dt9VzEwgFbYA:10 a=iox4zFpeAAAA:8 a=yPCof4ZbAAAA:8 a=E5hRKjw2lWykmI9IJP0A:9 a=WzC6qhA0u3u7Ye7llzcV:22 cc=ntf
 awl=host:13206
X-Proofpoint-GUID: 5_s0WM-cZWPJR4YTdgd_l_rYSXFz68xK
X-Proofpoint-ORIG-GUID: 5_s0WM-cZWPJR4YTdgd_l_rYSXFz68xK

[ Upstream commit 85fcb57c983f423180ba6ec5d0034242da05cc54 ]

When mapping a buffer for DMA via .map_page or .map_sg DMA operations,
there is no need to check the machine frames to be aligned according
to the mapped areas size. All what is needed in these cases is that the
buffer is contiguous at machine level.

So carve out the alignment check from range_straddles_page_boundary()
and move it to a helper called by xen_swiotlb_alloc_coherent() and
xen_swiotlb_free_coherent() directly.

Fixes: 9f40ec84a797 ("xen/swiotlb: add alignment check for dma buffers")

Signed-off-by: Juergen Gross 
Signed-off-by: Harshvardhan Jha 
---
 drivers/xen/swiotlb-xen.c | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 0392841a822fa..65da97be06285 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -75,19 +75,21 @@ static inline phys_addr_t xen_dma_to_phys(struct device *dev,
 	return xen_bus_to_phys(dev, dma_to_phys(dev, dma_addr));
 }
 
+static inline bool range_requires_alignment(phys_addr_t p, size_t size)
+{
+	phys_addr_t algn = 1ULL << (get_order(size) + PAGE_SHIFT);
+	phys_addr_t bus_addr = pfn_to_bfn(XEN_PFN_DOWN(p)) << XEN_PAGE_SHIFT;
+
+	return IS_ALIGNED(p, algn) && !IS_ALIGNED(bus_addr, algn);
+}
+
 static inline int range_straddles_page_boundary(phys_addr_t p, size_t size)
 {
 	unsigned long next_bfn, xen_pfn = XEN_PFN_DOWN(p);
 	unsigned int i, nr_pages = XEN_PFN_UP(xen_offset_in_page(p) + size);
-	phys_addr_t algn = 1ULL << (get_order(size) + PAGE_SHIFT);
 
 	next_bfn = pfn_to_bfn(xen_pfn);
 
-	/* If buffer is physically aligned, ensure DMA alignment. */
-	if (IS_ALIGNED(p, algn) &&
-	    !IS_ALIGNED((phys_addr_t)next_bfn << XEN_PAGE_SHIFT, algn))
-		return 1;
-
 	for (i = 1; i < nr_pages; i++)
 		if (pfn_to_bfn(++xen_pfn) != ++next_bfn)
 			return 1;
@@ -306,7 +308,8 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 	phys = dma_to_phys(hwdev, *dma_handle);
 	dev_addr = xen_phys_to_dma(hwdev, phys);
 	if (((dev_addr + size - 1 <= dma_mask)) &&
-	    !range_straddles_page_boundary(phys, size))
+	    !range_straddles_page_boundary(phys, size) &&
+	    !range_requires_alignment(phys, size))
 		*dma_handle = dev_addr;
 	else {
 		if (xen_create_contiguous_region(phys, order,
@@ -347,6 +350,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
 
 	if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
 		     range_straddles_page_boundary(phys, size)) &&
+	    !range_requires_alignment(phys, size) &&
 	    TestClearPageXenRemapped(page))
 		xen_destroy_contiguous_region(phys, order);
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed May 21 08:54:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 08:54:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991632.1375477 (Exim 4.92)
	(envelope-from )
	id 1uHfDr-0003EH-6I; Wed, 21 May 2025 08:54:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991632.1375477; Wed, 21 May 2025 08:54: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 1uHfDr-0003EA-2M; Wed, 21 May 2025 08:54:47 +0000
Received: by outflank-mailman (input) for mailman id 991632;
 Wed, 21 May 2025 08:54:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHfDp-0003E3-Qu
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 08:54:45 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3dc54cb5-3621-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 10:54:44 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-6020ff8d35dso3137451a12.0
 for ; Wed, 21 May 2025 01:54:44 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005a6e6366sm8677401a12.44.2025.05.21.01.54.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 01:54: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" 
X-Inumbo-ID: 3dc54cb5-3621-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747817684; x=1748422484; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=TTcNcN/mn4vwLSDJHVvJ6D89I9AaCHM3ByCAn3FkYMk=;
        b=TEc8N+sbBVXflUQOqn/+ygxvPNB7SUhqQ1rUfZLI2WW8olWLT3VgrQ7U38h3GAGE4B
         cclEW+Lulsz9jYy2kYRdYLRffXiReBClPcg2yJRwx6bzGeVhZTp49wBVeI6VhbcPxsfF
         pS8luvl/ZRifmK5nKDLKsHbZyU5207CZupCuBrlVGDRRG/TeF6v/NLN8uXVa8MRPq3Fj
         EKh3hNrtTIlli3gc6yaCFpM3sWujJZmfBR3wtDecF7qmGiYiGtjvDFYfUVIgyGzUxjWF
         AW1AmD3CjkwJxP8+uEnncNC6ajjiWn1Tck+eCqsxmZ7+VN8Z1qZKhZ2ms5qjphM0YXB5
         +mXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747817684; x=1748422484;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=TTcNcN/mn4vwLSDJHVvJ6D89I9AaCHM3ByCAn3FkYMk=;
        b=FIvKMNfwVFv91enozg/ieWEa3UU6MAafF8rh9nhnkiSpyEWlp9llDRScOz5TfzA2EX
         6g7bOAMlU2bdttLiLzz5RuJAyjspSitD4z4FijICTRYgNOOVmhhIc+B/GjqjSTN/Tv1t
         f5oSOjKGfHRBmIsIS9R+SXEKgTk1f9LogtmGYK75ZyJMALi67JidjCngWkOikvfKyrfN
         x5ahZY56KmSpN6Jck1TWovIGooDuybuOTaIrSBNvCcBsnMKXVv5bRpq2k3TjY+R3/mSj
         i5lS7w7J79etebU0O5IrtHinm9zZxlJ/x7lq14+M8jlV29IGMdmRcGV3NFVU/MbKNwDX
         hhhA==
X-Forwarded-Encrypted: i=1; AJvYcCXSO8C0oMJpzkYxEzA626QalP2Efe410ROZWzH+crSUpRz39/xOa5XJgy+53MHpxzwiVMn8NYi6g9M=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yydz8fK/hLuWIBdDjwdd/ZbWe4irGs0JFMvzFCAK0fNHdhwwdat
	S/kEsbRmaNuiseyrK2W/X+qWqqbrU44tiua/ub4Klt7hy8LpgpogPmOdvAV11cnBFw==
X-Gm-Gg: ASbGncuZJFR0D1l8WgmA+/l8hELmPFaDdIpXYAzLKHQwUk/M5mU3tG1h21qVlJKvWkH
	ylCBAPu+jyaNYg1BB1I3h5MBtUAQB06ljSh49vPYpCoqT4NMfPQkoBqGmvMnM1pxY5k2zRZazG4
	dLl/H+91xl6sHJ2zjXUa+LeMIsrJocBdNO77oBoeHHvDRUHuL5q+Aa3dO2cpyNfdnVmFviGALmu
	NdBAGqrkmGhVk2GdvFY10GnBSAsq6JAZFgSb2txpGSbOmmS2ED3ParSUVxY6bWZiY4SCjQXTwcC
	eE+UcBQRoDkza+AaUF2wepW39fP/42rmkvi9+MwlRkLjXNUNEoqxFe6luvnNSDdg6rGJgcd9
X-Google-Smtp-Source: AGHT+IFEiyRbsFlJms7UqQ35HbVJNfGRON+KwNo949Pe5+OL5LqoqOuTfsywH8U+f40mCtHvtqvozQ==
X-Received: by 2002:a05:6402:4307:b0:602:a0:1f2c with SMTP id 4fb4d7f45d1cf-60200a02e14mr6226619a12.9.1747817684230;
        Wed, 21 May 2025 01:54:44 -0700 (PDT)
Message-ID: 
Date: Wed, 21 May 2025 10:54:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 02/12] common/hyperlaunch: introduce the domain builder
To: Alejandro Vallejo 
Cc: "Daniel P. Smith" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Jason Andryuk , Denis Mukhin ,
 xen-devel@lists.xenproject.org
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-3-agarciav@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250429123629.20839-3-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 29.04.2025 14:36, Alejandro Vallejo wrote:
> @@ -1284,9 +1285,14 @@ void asmlinkage __init noreturn __start_xen(void)
>                 bi->nr_modules);
>      }
>  
> -    /* Dom0 kernel is always first */
> -    bi->mods[0].type = BOOTMOD_KERNEL;
> -    bi->domains[0].kernel = &bi->mods[0];
> +    if ( builder_init(bi) == FDT_KIND_NONE )

With this, can ...

> +    {
> +        /* Find first unknown boot module to use as dom0 kernel */
> +        i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);

... i ever be anything else than 0? If not, perhaps keeping the call here is
still fine (kind of for doc purposes), but an assertion may then want adding.

> +        bi->mods[i].type = BOOTMOD_KERNEL;
> +        bi->domains[0].kernel = &bi->mods[i];
> +        bi->hyperlaunch_enabled = false;

Is this necessary, when the field is supposed to be starting out clear?

> --- /dev/null
> +++ b/xen/common/domain-builder/Makefile
> @@ -0,0 +1,2 @@
> +obj-y += fdt.init.o
> +obj-y += core.init.o

Any reason for these not both adding to obj-bin-y, like we do elsewhere for
*.init.o?

Also please sort object lists alphabetically.

> --- /dev/null
> +++ b/xen/include/xen/domain-builder.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __XEN_DOMAIN_BUILDER_H__
> +#define __XEN_DOMAIN_BUILDER_H__
> +
> +struct boot_info;
> +
> +/* Return status of builder_init(). Shows which boot mechanism was detected */
> +enum fdt_kind
> +{
> +    /* FDT not found. Skipped builder. */
> +    FDT_KIND_NONE,
> +    /* Found an FDT that wasn't hyperlaunch. */
> +    FDT_KIND_UNKNOWN,
> +};
> +
> +/*
> + * Initialises `bi` if it detects a compatible FDT. Otherwise returns
> + * FDT_KIND_NONE and leaves initialisation up to the caller.
> + */
> +#if IS_ENABLED(CONFIG_DOMAIN_BUILDER)

For the pre-processor it wants to be the simpler #ifdef.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 09:12:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 09:12:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991642.1375487 (Exim 4.92)
	(envelope-from )
	id 1uHfVG-00067f-JV; Wed, 21 May 2025 09:12:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991642.1375487; Wed, 21 May 2025 09:12: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 1uHfVG-00067Y-GX; Wed, 21 May 2025 09:12:46 +0000
Received: by outflank-mailman (input) for mailman id 991642;
 Wed, 21 May 2025 09:12:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHfVF-00067S-8W
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 09:12:45 +0000
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com
 [2607:f8b0:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bfb0d1d9-3623-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 11:12:43 +0200 (CEST)
Received: by mail-pl1-x629.google.com with SMTP id
 d9443c01a7336-2321c38a948so40712435ad.2
 for ; Wed, 21 May 2025 02:12:42 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d9443c01a7336-231d4ebcd45sm88795785ad.210.2025.05.21.02.12.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 02:12: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" 
X-Inumbo-ID: bfb0d1d9-3623-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747818760; x=1748423560; 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;
        bh=oI9EMhWCWBlVnQwaD4envDuYNzNTvcySHJAXA4pshoU=;
        b=pZCgHxL/2IHbbYxyI0EBn2YUqliriksKHCmffPKkZsMTQo/pXFExiUh3Lhste9+e2x
         Gwy/BcCmUNb9Zp5SuSLLoTekXByz8gBx9ktTgVzJmQMnSUkoCTL8BvO0AGdualIKyqsg
         Zs5Q2z9JfrjaNDFKya+wAizYtrm9p5VirUkeQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747818760; x=1748423560;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=oI9EMhWCWBlVnQwaD4envDuYNzNTvcySHJAXA4pshoU=;
        b=OIxg3/RNflax1N0PzuVM9OtrUG3oGjkRNlgxW+4e9HEhIHeti1hfSszsSTvCXsEIrt
         oEIMlsvDox7XikFaZbuimnO0dXylymBEDK0y3QulY42A0I2FepLFJ5Fc2ejVFmIPTacv
         PVsd1SCJvmcHO4J1uBW+1kIGuA64HXRiH2DaBDHq4zvrsOzVVAzq3Td6FFfkgm4AXk0d
         B70aX4YWaojNNaJbQiXVN6sgdcq4D+OlqNmV2xIuliag1uSlIdjxZg6MMb/294W/l/Qp
         11NnlVPSBJssSozibP2Vc0wtU+IHj+meL9G+49/kEMgasGRDGPEjoDdsssBxLcLiEMzH
         Gv0w==
X-Gm-Message-State: AOJu0YxTFpcPEyyfpu6iJwZjxVL2T/bnzMqR60cmg7+23gDKQNWpjrho
	urvOrkrBPQNMTuo4gadxNYIblYhL5TSSinAVVBH0hoHcc/tfu03njug69zPc5O3VYMwR5fhCc6H
	LTTF/
X-Gm-Gg: ASbGncu7aSEH2ZEoPuWO17RFHM8s21GCnaqKFRhOQKZ6AYAXnNoEdJZ1Cgwrr4HCnkf
	N7tmkHjKUf3GQhQc4oWWixuOkQxf4A+vuIb0F9wxTmol9qjFqKSnd/gwtgGB44jahK9ttBGIUGp
	/qBgER+ny1MMvmcc+BZRSworq0hrOgRYqwzvMOek8TDc1EqaB3uVKJZPRbbzaBncHfh6avB+AEO
	R9dRckrteyYkj1ExR9QETPz8nx280NJuER3CgTELY10JFWioEhhHCcO43NeGkpiHa4M1GtJ8aD2
	4aqgKM+WpeCJEJWEhwYksbYZESFm1Yiijz9zDPxsOHt0q6vRG6nOHlW2KXv7nJgcPU2w4gZmT4i
	JIQ5g+YlERu6e/ttrmdzfyqfq
X-Google-Smtp-Source: AGHT+IFar4zPK2S3dsLjfZ5VVzZoXPq/04DB6VQwRlCsFP5RD6xAMTazy8a531rDv+GpitylL4Ojaw==
X-Received: by 2002:a17:902:db07:b0:224:1001:677c with SMTP id d9443c01a7336-231de351468mr258572645ad.9.1747818760432;
        Wed, 21 May 2025 02:12:40 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH v3] x86/gnttab: do not implement GNTTABOP_cache_flush
Date: Wed, 21 May 2025 11:12:25 +0200
Message-ID: <20250521091225.84597-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current underlying implementation of GNTTABOP_cache_flush on x86 won't
work as expected.  The provided {clean,invalidate}_dcache_va_range()
helpers only do a local pCPU cache flush, so the cache of previous pCPUs
where the vCPU might have run are not flushed.

However instead of attempting to fix this, make the GNTTABOP_cache_flush
operation only available to ARM.  There are no known users on x86, the
implementation is broken, and other architectures don't have grant-table
support yet.

With that operation not implemented on x86, the related
{clean,invalidate}_dcache_va_range() helpers can also be removed.

Fixes: f62dc81c2df7 ("x86: introduce more cache maintenance operations")
Fixes: 18e8d22fe750 ("introduce GNTTABOP_cache_flush")
Signed-off-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
Reviewed-By: Oleksii Kurochko
---
Changes since v2:
 - Adjust how HAS_GRANT_CACHE_FLUSH gets selected.
---
 CHANGELOG.md                        |  3 +++
 xen/arch/arm/Kconfig                |  1 +
 xen/arch/x86/include/asm/flushtlb.h | 19 -------------------
 xen/common/Kconfig                  |  3 +++
 xen/common/grant_table.c            |  6 ++++++
 5 files changed, 13 insertions(+), 19 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index faf2271011f1..ec452027f54b 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -28,6 +28,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
     - Ability to enable stack protector
 
 ### Removed
+ - On x86:
+   - GNTTABOP_cache_flush: it's unused on x86 and the implementation is
+     broken.
 
 ## [4.20.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.20.0) - 2025-03-05
 
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 3321d8906863..a5aad97a688e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,6 +17,7 @@ config ARM
 	select HAS_ALTERNATIVE if HAS_VMAP
 	select HAS_DEVICE_TREE
 	select HAS_DOM0LESS
+	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
 	select HAS_STACK_PROTECTOR
 	select HAS_UBSAN
 
diff --git a/xen/arch/x86/include/asm/flushtlb.h b/xen/arch/x86/include/asm/flushtlb.h
index 209ea1e62fae..cd625f911436 100644
--- a/xen/arch/x86/include/asm/flushtlb.h
+++ b/xen/arch/x86/include/asm/flushtlb.h
@@ -184,25 +184,6 @@ void flush_area_mask(const cpumask_t *mask, const void *va,
 }
 
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache) {}
-static inline int invalidate_dcache_va_range(const void *p,
-                                             unsigned long size)
-{ return -EOPNOTSUPP; }
-static inline int clean_and_invalidate_dcache_va_range(const void *p,
-                                                       unsigned long size)
-{
-    unsigned int order = get_order_from_bytes(size);
-    /* sub-page granularity support needs to be added if necessary */
-    flush_area_local(p, FLUSH_CACHE|FLUSH_ORDER(order));
-    return 0;
-}
-static inline int clean_dcache_va_range(const void *p, unsigned long size)
-{
-    unsigned int order = get_order_from_bytes(size);
-
-    /* sub-page granularity support needs to be added if necessary */
-    flush_area_local(p, FLUSH_CACHE_WRITEBACK | FLUSH_ORDER(order));
-    return 0;
-}
 
 unsigned int guest_flush_tlb_flags(const struct domain *d);
 void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask);
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6d43be2e6e8a..3d66d0939738 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -35,6 +35,9 @@ config GRANT_TABLE
 
 	  If unsure, say Y.
 
+config HAS_GRANT_CACHE_FLUSH
+	bool
+
 config EVTCHN_FIFO
 	bool "Event Channel Fifo support" if EXPERT
 	default y
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index e75ff98aff1c..cf131c43a1f1 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -940,6 +940,7 @@ static void reduce_status_for_pin(struct domain *rd,
         gnttab_clear_flags(rd, clear_flags, status);
 }
 
+#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
 static struct active_grant_entry *grant_map_exists(const struct domain *ld,
                                                    struct grant_table *rgt,
                                                    mfn_t mfn,
@@ -975,6 +976,7 @@ static struct active_grant_entry *grant_map_exists(const struct domain *ld,
 
     return ERR_PTR(-EINVAL);
 }
+#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
 
 union maptrack_node {
     struct {
@@ -3520,6 +3522,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) uop,
     return 0;
 }
 
+#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
 static int _cache_flush(const gnttab_cache_flush_t *cflush, grant_ref_t *cur_ref)
 {
     struct domain *d, *owner;
@@ -3631,6 +3634,7 @@ gnttab_cache_flush(XEN_GUEST_HANDLE_PARAM(gnttab_cache_flush_t) uop,
 
     return 0;
 }
+#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
 
 long do_grant_table_op(
     unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
@@ -3773,6 +3777,7 @@ long do_grant_table_op(
         break;
     }
 
+#ifdef CONFIG_HAS_GRANT_CACHE_FLUSH
     case GNTTABOP_cache_flush:
     {
         XEN_GUEST_HANDLE_PARAM(gnttab_cache_flush_t) cflush =
@@ -3789,6 +3794,7 @@ long do_grant_table_op(
         }
         break;
     }
+#endif /* CONFIG_HAS_GRANT_CACHE_FLUSH */
 
     default:
         rc = -ENOSYS;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 09:29:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 09:29:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991651.1375497 (Exim 4.92)
	(envelope-from )
	id 1uHflU-0007uG-VJ; Wed, 21 May 2025 09:29:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991651.1375497; Wed, 21 May 2025 09:29:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHflU-0007u9-S2; Wed, 21 May 2025 09:29:32 +0000
Received: by outflank-mailman (input) for mailman id 991651;
 Wed, 21 May 2025 09:29:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHflT-0007u3-Nv
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 09:29:31 +0000
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
 [2a00:1450:4864:20::134])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 17bb9fce-3626-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 11:29:28 +0200 (CEST)
Received: by mail-lf1-x134.google.com with SMTP id
 2adb3069b0e04-550e2ac6bc9so7161496e87.1
 for ; Wed, 21 May 2025 02:29: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" 
X-Inumbo-ID: 17bb9fce-3626-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747819768; x=1748424568; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=juu3MSergNi56rWxVd5yr7cNodLo8FHyvOwVr8d04mo=;
        b=FEKFz31IKKtnk+WmbARvosok6bMYMht/MwUCQme4WrS7EQrHxg+XuhSHHrObEvBvCo
         IaqWGss31OBRxjAkZr/FmpqWYlWy1e3MmITQP68KoRy8y6jf0UZ7/t2a9sLzDTReSpzB
         3dGBfDQQQuVSbHk2OeeLFmC7kM76hJwpqtRTuZQXM3kDmwEfPULsPEHoRsFCaG+IOC+s
         1QIy31M9ydaHHICwx0MatixAWR1GzLoQjT3WBWzoeVEjJArpR7sANlb/jCAMWqFDXfaQ
         NMhOaZZaBslUajeChAA0wWwmg0GjXgy2PfVLpk2+t8DCDWxDvf762Lj+qNZ4RUWScGp7
         Yb5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747819768; x=1748424568;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=juu3MSergNi56rWxVd5yr7cNodLo8FHyvOwVr8d04mo=;
        b=RKmrCZi6go1LY6eytl+ueodKQDVC38wihqqsbVunl1spkYIfe49oYu88ylTjuwqAE1
         n3p1HeChpixJiBfIHRPyhn/IILeUbF9USdmIngK7KAwY5wDWdCwt3zFyp2YEhikcJ7+3
         eAcxPqXTkOjO6fZa8vrkuBJuaKVmLHkJ41L82zuUDJRwnzLA/IKAmzXn9OFOQpMEPN//
         PuWEqqQ6gHILRzFNi18hgdzeIzL72Kf8Qw2spv0G1YJutK4oIVwjbxq24inUx9pGyB6y
         RmUdjlYl4bHJAjF2bdKugAsnkoRhsB/dOALklPLVZP8vYgvoEOEUJHt+Ud1Je/AuIQls
         zgmA==
X-Forwarded-Encrypted: i=1; AJvYcCWcJ/Yh98B/btpEWFuMKNAFBcuePHXIPpOh+nNRnQtf2TRlGyVh0lW/DXG5yL+6ntB8E+m4t1LLf10=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwziRDke0mKSPM1QV41z+w/kFilXMD5abCYBKlG+xdWsaUrq1cE
	+5mEfhPz+kDoeYquqCph66mIWJBYyGgqI+HpMQUmVMUZEo5i2R4Qg5e2wQXPZnsubkFpjDimDpq
	kVEE7aVCbbbDMkYe57HqiTmVm8PV5njw=
X-Gm-Gg: ASbGncs0gC8+TfDeZWhihNRbf4eINiFR3WoBDdcY96hXXQNiMvZgD3ArDltkC8swgjE
	zX6Dz4SPbVjG6MdxPv5wHXDAwFOOUOw7tVpCQjoqQHB9tTGryx5sG95DggSKeyl+x5eSQ9hoLrG
	vWtTDGMidcgKUfytR871O2UJNrKOmgRC0=
X-Google-Smtp-Source: AGHT+IERJ7pDGRhfYzgkKoZU76MviPfXRS5aqHrqdsVnzErX+rA2vaHjeRegPhsRtaMqlQUrAzIR8fxJCWNJhSL/O+U=
X-Received: by 2002:a05:6512:4389:b0:54f:c33c:a5eb with SMTP id
 2adb3069b0e04-550e7230510mr5521975e87.44.1747819767611; Wed, 21 May 2025
 02:29:27 -0700 (PDT)
MIME-Version: 1.0
References: <20250520233220.868258-1-christopher.w.clark@gmail.com> <528bd2ae-d33b-4038-92c1-c9ab1ccf0bb7@suse.com>
In-Reply-To: <528bd2ae-d33b-4038-92c1-c9ab1ccf0bb7@suse.com>
From: Christopher Clark 
Date: Wed, 21 May 2025 10:29:15 +0100
X-Gm-Features: AX0GCFvLk1oWLloQBLvPjiNOituCHoeEd4Vu3s_Z6jKPKJRB9wvk4z7YqexDjtE
Message-ID: 
Subject: Re: [PATCH 1/2] MAINTAINERS: include Argo documentation in the ARGO section
To: Jan Beulich 
Cc: Andrew Cooper , Daniel Smith , 
	Rich Persaud , Anthony PERARD , 
	Michal Orzel , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , xen-devel@lists.xenproject.org
Content-Type: multipart/alternative; boundary="00000000000061440c0635a200fe"

--00000000000061440c0635a200fe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 21, 2025 at 8:12=E2=80=AFAM Jan Beulich  wro=
te:

> On 21.05.2025 01:32, Christopher Clark wrote:
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -226,6 +226,7 @@ S:        Maintained
> >  F:   xen/include/public/argo.h
> >  F:   xen/include/xen/argo.h
> >  F:   xen/common/argo.c
> > +F:   docs/designs/argo.pandoc
>
> The list of F: isn't alphabetically sorted here, yes, but please let's
> at least not make that problem worse.
>

Apologies, thanks for the review.

Christopher



>
> Jan
>

--00000000000061440c0635a200fe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



    On Wed, May 21, 202=
5 at 8:12=E2=80=AFAM Jan Beulich <j=
beulich@suse.com> wrote:
    On 21.05.2025 01:32, Christopher Clark wrote:
    
> --- a/MAINTAINERS
    
> +++ b/MAINTAINERS
    
> @@ -226,6 +226,7 @@ S:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Maintained
    
>=C2=A0 F:=C2=A0 =C2=A0xen/include/public/argo.h
    
>=C2=A0 F:=C2=A0 =C2=A0xen/include/xen/argo.h
    
>=C2=A0 F:=C2=A0 =C2=A0xen/common/argo.c
    
> +F:=C2=A0 =C2=A0docs/designs/argo.pandoc
    

    
The list of F: isn't alphabetically sorted here, yes, but please let=
9;s
    
at least not make that problem worse.

    A=
pologies, thanks for the review.

    Christopher
    =


    =C2=A0
    

    
Jan
    

    

--00000000000061440c0635a200fe--


From xen-devel-bounces@lists.xenproject.org Wed May 21 10:24:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 10:24:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991670.1375507 (Exim 4.92)
	(envelope-from )
	id 1uHgc9-0006lT-SA; Wed, 21 May 2025 10:23:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991670.1375507; Wed, 21 May 2025 10:23: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 1uHgc9-0006lM-PO; Wed, 21 May 2025 10:23:57 +0000
Received: by outflank-mailman (input) for mailman id 991670;
 Wed, 21 May 2025 10:23:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHgc8-0006lG-Fn
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 10:23:56 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b2c6d047-362d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 12:23:55 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a376da332aso2026902f8f.3
 for ; Wed, 21 May 2025 03:23:55 -0700 (PDT)
Received: from localhost.localdomain ([91.85.47.110])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f38142aasm62329635e9.27.2025.05.21.03.23.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 03:23: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" 
X-Inumbo-ID: b2c6d047-362d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747823034; x=1748427834; 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;
        bh=BaaopXGzVQVS3ui+bxnu+lj+jxPd2TC7KpOv7bUuDVY=;
        b=h4dDYknn30F8kw4++/wL49r2dINwkMIKVbMioWhDLlxdzDrstqdo3sZ6UXCFlUiIPn
         0gseKl3c2r4C8ZC+KkAQFL9Agg0fQoXXGkAetU0qe+ioFLQ6smprchcm4+ulX0JyY9FM
         vW/hCjXYOT1PEKCnNBfO37EAtExMk4luVBT6gy2fS79CfhLu6vCMxik0LTdmo7APCt/Q
         nBifOitJ+YyQyGprJ/IXFZnjtHtcrFpWea4hnNaU6uz6qkulGDYf88nvsXSuIWRiXu+T
         Ge4ZgIc3hI6/wbaXqKo4y75mW2Tq99dqr28CHM+CXckh7ivtj4AszmdqVU65d2dP9E64
         1yFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747823034; x=1748427834;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=BaaopXGzVQVS3ui+bxnu+lj+jxPd2TC7KpOv7bUuDVY=;
        b=IAbIbZlz8+691X6unXHE4SocJewiueYXLNmI3HyA4JHzrsnGgL1GTwqdkaqO9jtd6V
         yB1xNmFP8vhw9Q8fbFGCZFgDrW5OGkYjMAW/mxKDvYgzX/wdNikvyaQPps38HGY+aJwe
         qWCXjOpP+tpmWIB2bs408BNNQ+Mr/K0K/78ujuKJejCFBFIenHrQVlaGgBOAx+ZKgLOF
         KdNDng/vxBE4yRhEKZZ5/QCJxIfYkRbfRRaU5Epqnw/lAdtjcCP1twSEt7XV+5W8Q8K2
         ow517xrEVhFn6cZMf5foPcX+F/IdDUAsqdKnXCLLzHUf6kX+4cJOhqe98VZHl20hr2KX
         +qog==
X-Gm-Message-State: AOJu0Yzo6GgG7LwAjDiRafHALrtPptVaTgQMxt/JjSYsF03E1OIIhVEU
	MLOwMYZYvS7sC+CF/4OY6sBKbVx7XUxe5OdZpCR39gbuPzZH2Q70jaHdtve2Tkaq
X-Gm-Gg: ASbGncvQ+fhp/XrCHI6dN2JmaY+QskYmv/bznLYhpHG7lqbZ+lb4BO21dwMs8Hlfxwd
	bfTMyAQN2sc7ksMgzBV7993fPhGlWWYcoGZBQjgrhkY+TWBjkMRpzE5oIcmjd/XRK2MCI2FoW3e
	Mx9kGHTygy2+blZRgR//DOZ6O/UsLL3PlR7FVA6Gkmgu0lYlKOb7mLQ0nC29tIPifzaOPqjBdWF
	G3k0HqoyBEIPkQiJxoQ/AtzEWAIbjxZUM2ATshuaKs522v5aDEyBB/zmkptqwHY2QQv+z3MoBX3
	aaJiapK1v6ZQs4XwJ3/F1IgSG9Sjxb7d0XB8f5vMwZv40Pe23d9rb37dRVHkanQubPefmPbjZ3g
	=
X-Google-Smtp-Source: AGHT+IGxmvRFi9KDEqAcIldo/Ag0nJf9tNOFdValeBXjknF6xvVgmXmMKi3lufkrQMJG2CSMnt7ndg==
X-Received: by 2002:a05:6000:400f:b0:3a0:b4f1:8bd5 with SMTP id ffacd0b85a97d-3a35fe67aa7mr15728914f8f.18.1747823033960;
        Wed, 21 May 2025 03:23:53 -0700 (PDT)
From: Christopher Clark 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Daniel Smith ,
	Rich Persaud ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2] MAINTAINERS: add a reviewer for Argo
Date: Wed, 21 May 2025 11:23:33 +0100
Message-Id: <20250521102333.870789-1-christopher.w.clark@gmail.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Adding Daniel P. Smith as a reviewer.

Signed-off-by: Christopher Clark 
---
since v1: add to R: role

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c11b82eca9..517143075d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -222,6 +222,7 @@ F:	tools/libacpi/
 
 ARGO
 M:	Christopher Clark 
+R:	Daniel P. Smith 
 S:	Maintained
 F:	xen/include/public/argo.h
 F:	xen/include/xen/argo.h
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Wed May 21 11:24:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 11:24:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991698.1375516 (Exim 4.92)
	(envelope-from )
	id 1uHhY9-0005ci-5j; Wed, 21 May 2025 11:23:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991698.1375516; Wed, 21 May 2025 11:23:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHhY9-0005cb-2v; Wed, 21 May 2025 11:23:53 +0000
Received: by outflank-mailman (input) for mailman id 991698;
 Wed, 21 May 2025 11:23:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHhY8-0005cV-3A
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 11:23:52 +0000
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com
 [2a00:1450:4864:20::42a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 11893d7d-3636-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 13:23:50 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a35919fa8bso2707619f8f.0
 for ; Wed, 21 May 2025 04:23:50 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca4d2d1sm20013991f8f.19.2025.05.21.04.23.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 04:23: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" 
X-Inumbo-ID: 11893d7d-3636-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747826629; x=1748431429; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=u5i2XRUMt8Wc5XyeJDF55b4Gg6QTaNnRZIhf+cL4pUc=;
        b=iYjSoVU7GPyxAJob7QDM2RoAhg2JNpkC00Rz23lKzwH0SVWDG+9dyl5vUFlJKxInbO
         mPwVVrFlh87BYWa1ht2cOJBNbzgW1QaEO4Twqd1pefx/oPr8nQRva7WWoy0QX56FCN9+
         HIyLXGTAPRUyeE+eFDpfePzIlmWmmxQM2xgAk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747826629; x=1748431429;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=u5i2XRUMt8Wc5XyeJDF55b4Gg6QTaNnRZIhf+cL4pUc=;
        b=E4uezjimkX4YAUr9yDxhSoHlINwRvPqnRtdykboAri3qQs/mJk/GDyGtssMy7XH2xP
         6XSEcu+vjaEdc1lJEFM8XbnoL840PWShAQx3oR/miwAdj+ICumijWbu1DUK9ab8D99hB
         bhP7WYjsqgWi5byhfjVuyXj5tdvL3z4nfO3DaTNan+zBAip/+VMsDubi3/UbXLbik1XL
         3iDOOkHMU4VfS/Og7i8YJ4ZC0crPrY7kt/yj8vCTnXjdCx8SwCs7B1rhK1plisdnZnP1
         /sTC4MuE1h7RmO4SnlTvq507/L8Azt2VBQvpxdunN/PxLL/0MOtzOArsOYl+G1bzhFrW
         tUWQ==
X-Forwarded-Encrypted: i=1; AJvYcCWA2bwFyiWgBELsbz5xHZMi4mHVvJGn1zGHk177V9Thay+64RR1sGjGYrKz9XRlRSPTlcpSSYb0ouE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwOIhXIO9OQTsSXB27CopaUE7qmZwO/Uqyz8MZ9mImzZoqR0rIv
	yFWHYmPbqJM0XBHGRpOUa5ygt/GAdrCYiH1oYjF0xWWy3/a7nP7Xm8M6M2B9du1W4smTnIGaUbi
	QRmNu
X-Gm-Gg: ASbGncsuiDiBppEwfKmirAbCrj0FCdC6LOqP7C3V6uItXmhOXBaeWr7M3rwF6o8Epi8
	zWdiYsYgiCgSjGsle9aS6yvnPzZuGycZxJWPnUaahlJc9itHmZt0XHSK1Qw209hbtSIzYYKPgva
	klIK3WhfImVGSlrfgRm4l05zQTHWiTRRU9ImkspB+AvNq8r7Ruajw/M2On+oOumVNZ/LfBlvkAv
	Ynf5XMXJQgN5sW5Za5WCRpSMu2YQYckiz0OwMlvjowrloEaJJBJGBNDPVVQpu6OzM5m57+kdAAd
	eHD9dMIaVg+MR5bN/tk6L5e7PckH6WI9I3KXhzp993EVwfD5rUSJXve3HIhCYc5hMEYFw2TL7B8
	ypE+2sgHqtD0KzenxVnl9hzbl
X-Google-Smtp-Source: AGHT+IGUKR7sqx8CoV9YlU7kqFMHBgORAwfq23kSzJIcSUZ0jlnyPRqoj0J0qxYipwYA8iC0aAGvwQ==
X-Received: by 2002:a05:6000:2405:b0:3a0:7a7c:2648 with SMTP id ffacd0b85a97d-3a35fe95381mr17283752f8f.27.1747826629384;
        Wed, 21 May 2025 04:23:49 -0700 (PDT)
Date: Wed, 21 May 2025 13:23:48 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: Jan Beulich , "Huang, Ray" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Message-ID: 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-10-Jiqian.Chen@amd.com>
 <8d89f644-4ded-4490-ad23-518563d230d2@suse.com>
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 21, 2025 at 07:00:37AM +0000, Chen, Jiqian wrote:
> On 2025/5/20 17:43, Roger Pau Monné wrote:
> > On Tue, May 20, 2025 at 11:14:27AM +0200, Jan Beulich wrote:
> >> On 20.05.2025 11:09, Roger Pau Monné wrote:
> >>> On Tue, May 20, 2025 at 08:40:28AM +0200, Jan Beulich wrote:
> >>>> On 09.05.2025 11:05, Jiqian Chen wrote:
> >>>>> When init_msi() fails, the previous new changes will hide MSI
> >>>>> capability, it can't rely on vpci_deassign_device() to remove
> >>>>> all MSI related resources anymore, those resources must be
> >>>>> removed in cleanup function of MSI.
> >>>>
> >>>> That's because vpci_deassign_device() simply isn't called anymore?
> >>>> Could do with wording along these lines then. But (also applicable
> >>>> to the previous patch) - doesn't this need to come earlier? And is
> >>>> it sufficient to simply remove the register intercepts? Don't you
> >>>> need to put in place ones dropping all writes and making all reads
> >>>> return either 0 or ~0 (covering in particular Dom0, while for DomU-s
> >>>> this may already be the case by default behavior)?
> >>>
> >>> For domUs this is already the default behavior.
> >>>
> >>> For dom0 I think it should be enough to hide the capability from the
> >>> linked list, but not hide all the capability related
> >>> registers.  IMO a well behaved dom0 won't try to access capabilities
> >>> disconnected from the linked list,
> >>
> >> Just that I've seen drivers knowing where their device has certain
> >> capabilities, thus not bothering to look up the respective
> >> capability.
> > 
> > OK, so let's make the control register read-only in case of failure.
> > 
> > If MSI(-X) is already enabled we should also make the entries
> > read-only, and while that's not very complicated for MSI, it does get
> > more convoluted for MSI-X.  I'm fine with just making the control
> > register read-only for the time being.
> If I understand correctly, I need to avoid control register being removed and set the write hook of control register to be vpci_ignored_write and avoid freeing vpci->msi?
> 
> "
>      if ( !msi_pos || !vpci->msi )
>          return;
> 
> +    spin_lock(&vpci->lock);
> +    control = vpci_get_register(vpci, msi_control_reg(msi_pos), 2);
> +    if ( control )
> +        control->write = vpci_ignored_write;
> +    spin_unlock(&vpci->lock);
> +
>      if ( vpci->msi->masking )
>          end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
>      else
>          end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
> 
> -    size = end - msi_control_reg(msi_pos);
> +    start = msi_control_reg(msi_pos) + 2;
> +    size = end - start;
> 
> -    vpci_remove_registers(vpci, msi_control_reg(msi_pos), size);
> -    XFREE(vpci->msi);
> +    vpci_remove_registers(vpci, start, size);

I think you want to first purge all the MSI range, and then add the
control register, also you want to keep the XFREE(), and set the
register as:

vpci_add_register(vpci, vpci_hw_read16, NULL, msi_control_reg(msi_pos),
                  2, NULL);

So that you make it strictly hardware read-only, and not use the data
in vpci->msi.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 21 11:35:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 11:35:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991706.1375526 (Exim 4.92)
	(envelope-from )
	id 1uHhit-0007IC-3w; Wed, 21 May 2025 11:34:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991706.1375526; Wed, 21 May 2025 11:34: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 1uHhit-0007I5-1J; Wed, 21 May 2025 11:34:59 +0000
Received: by outflank-mailman (input) for mailman id 991706;
 Wed, 21 May 2025 11:34:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHhir-0007Hy-Ex
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 11:34:57 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9cddf3f6-3637-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 13:34:53 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-442e9c00bf4so49021555e9.3
 for ; Wed, 21 May 2025 04:34:53 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f3dd94f1sm68659685e9.35.2025.05.21.04.34.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 04:34: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" 
X-Inumbo-ID: 9cddf3f6-3637-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747827293; x=1748432093; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=B8zw2/iRLiGc176aMf+E2U4+GHTz3No35Bxuo2nAC/Q=;
        b=TzoS/ITF5wOtdUe2z/D6ErjzlF6dfYB+Aqd+/0T+LNDtksv3f19ZwYUv7OABIh7TpM
         dNbanHqZeWa8L6ouquYR4sMw/wRDoS7PTwvVDCDxBoM7jXccgB3Ap5xgV7HtS1/3LY9p
         v4dfhdStZkf8QRny9gwDVf2/eYEVjozdYv5r0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747827293; x=1748432093;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=B8zw2/iRLiGc176aMf+E2U4+GHTz3No35Bxuo2nAC/Q=;
        b=A77yuY8TegQmW8YyzZcIk3riwQ3o0fmsssm1513j1L6ICB8GIsDfRArEgmxwqqUN7C
         DnULftolsj6Pps+SRkkQjd795ECAlsEAzWRHt+H8Lc8+vg9EDZShJZ/IjnH2c03O2/aD
         Zekkq/PkEOjHXde5FHHr7Y+ytgoUyLog+TyWW3VXLm9SH0Sg6/jKBqQGFAvpK13W5vBN
         qRuj9+SOiZ5xLUo76t6duCDapXgPKWEBPVnVWpcr5kY7LM5Heaqc5Gzvp2GL2ohk59Tz
         17xFLmPfrY2+3wL88FGTVdNMf1wjlhjynq8V4nGIPfhbbscTwZFormCTwbLC9QSVNFRg
         jHTw==
X-Forwarded-Encrypted: i=1; AJvYcCVhbU6IhXsqRZ1x3/q5tbV3e69x1tTeqQTsk5AgUYhbooq49T+rIl3c8fjYD7YiXFNx94mRwCyYZ/g=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxxs7kr/+kcJd91KO+seucEseSFc59Pr6HlmMzP3Omal6bvsyM3
	yYY20w+XR4JI+DxmlxxtiIeM/EWFAARnx9D4lY6aNO4oaqMRdOGsYs5OsSesLP2UmHE=
X-Gm-Gg: ASbGncvAUnfdfWihdT2zClvmYG67a64Bern+ITXh3Vr9GY1puh+ViYpEHdC2qjh1MD9
	XYARK2n2MX/nj1hroBge51khqCK3MDNWqM9sct0reqWFtx/9m7qT0MeuBxJqbtEJYZZS0X9zWht
	p2dcRezhZB5kCqmZmVncSUzPnmlndb198MeAchhmD5I0ZWpbqOX0KLqUydou7EZ0D8Qdm1dQ3z0
	ZMH06kR/oc31IjrDBarBTVM+NIx/dem5DRNSqcr1y1kQ460ahGxHfh+z1qUb4Ue8ffM1z8Aj1NW
	opSSBo3b/jR8IREO8KYl8/+0786jdzF3CU+QoT6H+QSNTbv2+SUq5LPgewHt/2m83BACXTEuwLs
	IdflaArMNIrK/dLWDsQAXQoZVcqdYRAmc1Vk=
X-Google-Smtp-Source: AGHT+IFuRtcERcTaJWOFlLWs5QjgFwFfLKWawWPEj75ZK05Bbk12hPOobOBIfIS0kvE2Ukg5yVDBtw==
X-Received: by 2002:a05:600c:1c16:b0:43c:fd27:a216 with SMTP id 5b1f17b1804b1-442ff029e12mr157066065e9.23.1747827292683;
        Wed, 21 May 2025 04:34:52 -0700 (PDT)
Date: Wed, 21 May 2025 13:34:51 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Stefano Stabellini ,
	Victor M Lira ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] x86/vpci: fix handling of BAR overlaps with non-hole
 regions
Message-ID: 
References: <20250516083159.61945-1-roger.pau@citrix.com>
 <7bbc1569-672e-42a7-a5b8-4187282fcb18@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <7bbc1569-672e-42a7-a5b8-4187282fcb18@suse.com>

On Wed, May 21, 2025 at 10:29:26AM +0200, Jan Beulich wrote:
> On 16.05.2025 10:31, Roger Pau Monne wrote:
> > For once the message printed when a BAR overlaps with a non-hole regions is
> > not accurate on x86.  While the BAR won't be mapped by the vPCI logic, it
> > is quite likely overlapping with a reserved region in the memory map, and
> > already mapped as by default all reserved regions are identity mapped in
> > the p2m.  Fix the message so it just warns about the overlap, without
> > mentioning that the BAR won't be mapped, as this has caused confusion in
> > the past.
> 
> I was trying to get back to this, but my attempt to use this "fixed
> message" as an anchor failed: You don't modify any existing message, and
> hence I was unable to determine which other message you refer to here.
> None of the ones I looked at appear to fit this description.

OK, it's a bit tricky.  Note how the new implementation of
pci_check_bar() unconditionally returns true, which means the message
in modify_bars() will never be printed on x86.  Instead a slightly
different warning message is printed in the x86 implementation of
pci_check_bar().

That's what the above paragraph attempts to explain.

Maybe I need to adjust the last sentence so it's:

"Avoiding printing the warning message in modify_bars(), and instead
print a more lax message in the x86 implementation of pci_check_bar()
to note the current BAR position overlaps with non-hole region(s)."

Does the above make it a bit clearer?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 21 11:36:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 11:36:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991713.1375536 (Exim 4.92)
	(envelope-from )
	id 1uHhkb-0007pT-EZ; Wed, 21 May 2025 11:36:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991713.1375536; Wed, 21 May 2025 11: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 1uHhkb-0007pM-BK; Wed, 21 May 2025 11:36:45 +0000
Received: by outflank-mailman (input) for mailman id 991713;
 Wed, 21 May 2025 11:36:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHhka-0007pC-RQ
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 11:36:44 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ddf5ec79-3637-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 13:36:42 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-acb5ec407b1so1131672966b.1
 for ; Wed, 21 May 2025 04:36:42 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4420ccsm871359666b.110.2025.05.21.04.36.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 04:36: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" 
X-Inumbo-ID: ddf5ec79-3637-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747827402; x=1748432202; darn=lists.xenproject.org;
        h=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;
        bh=OvtI3wCVPYpw9YxMS7wk/RISza5+TDZdXWaw/AwZ9h0=;
        b=IgszQVMHQhXD6+8fOzdv/+f+1PYePzV0wAuAk3qd8vaYX4gFKupa3jNZVVJ57slqdg
         Y9XtRbH6YQ2JG3FFg9flBy6z4UZY8/tj6rGWb/FW6oHG69tiv/XLKzHb7eAEWj30TlHY
         iydLXeTq8Z7hsvZTYkvzTFkAPDKf30t841BKhduRFtqkpgN64/xPLOZpGLa2kkhMQsLw
         Wuplu1Saf/IlGJLGUf7TGU54Hhb6ZFEIrpQxfJKE/Jinyl7Zso/maFBAC/k+VUQVy1mN
         gViJxbdB93IPczze7TmY+Xo8M612VXl4gc5S9EjPP9jEA/Z3XJnfQ/yVfS1uAFGSKX9W
         DItQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747827402; x=1748432202;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=OvtI3wCVPYpw9YxMS7wk/RISza5+TDZdXWaw/AwZ9h0=;
        b=WYUCnm7Lve3OxM8vs03D9FhdQYNIDYmUp774XDojv0zEZjjUWecEQ8uChNvrrOIJDz
         LOO16Ey5HmUXT0kxI3YJsoUXh9oIoq1TJjEMFBCJ+3pUM5i1xeOEBYOqxbLJWUgs9QCz
         7OomKVMIlCRbBWQd1ra8DWKzASykcE224SvST7+Ztj67qRv+8bSyUqDO3+Dse7OlebFO
         /m/HC6BXh8llUXPmJ040hVyWVf4L9MP/nvuuL57AXszeJKaND9En8BX4wphcDJouvEJ8
         u084pvZ0pEjegZmvIzNoLovuF/+GtQNAN2jHSFLzIzO42VK348ZrLpmCbmkkGzwJJwdu
         f1hA==
X-Gm-Message-State: AOJu0YzI3eImuJTw0WNxQLKG3JvlQTxChqYKmWsSRXqMAN7X4Fc3egSn
	ka7v1kWuhDy1Q6agkxLIXVVVucBxFRbA9LFLcJ2OlfA6xJYru8QSFxY7
X-Gm-Gg: ASbGncuy7kZ8y7NuMyKmwAhLftoeP2ZGReBkF25iRzPgB8h61R81JW2Gg//xfp+YfmD
	0pfeIkLtG7zzq9XZvQyzRMWXy3uz6S71TUpSmbcd0z1BtNTJs6AGvCyUyc06GD3x7JFqmfH9Obo
	C7LFQPljQpsnuaQxKFDv8F7vobD9PTEslavTpQRTSAI/Q+eFFQZcGpefpxkxhvmDxxK89Y8pTIU
	aR5yGqZy5+4owVLXJOcaN7fhP79A0G1Gw2nQcTqBkwO9ip4R2SwHacBKlIWu7oCLkbGjDYKNJop
	l6wD1EtInOJ2qDZsV5S1stiu8osrOhk1FiTeuMDBmHVAfSl0wUpFQC1QAGSuzvn6cO96ecdMlDe
	LQCpAB0SFuDFXjA0yPYUaN1pG
X-Google-Smtp-Source: AGHT+IFlhVAFV1Hr0cQyaNFkJ4DbNc7BwRVXzgmt2V0n16deA8ox39DwdDo7SxCxFgMgn6dZW+voGQ==
X-Received: by 2002:a17:907:3e16:b0:ad4:f512:733 with SMTP id a640c23a62f3a-ad536dce6e4mr1986447766b.45.1747827401526;
        Wed, 21 May 2025 04:36:41 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------fSTWdDHqTBPPhtZzqumk8kgM"
Message-ID: <9591ab10-9e39-4af0-a8e6-d701fa0e114d@gmail.com>
Date: Wed, 21 May 2025 13:36:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen/riscv: add initialization support for virtual SBI
 UART (vSBI UART)
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: <1f380b7061496f999d4d60a60b58f494dae886e1.1747064551.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------fSTWdDHqTBPPhtZzqumk8kgM
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Denis,

On 5/16/25 9:50 PM, dmkhn@proton.me wrote:
> Hi Oleksii,
>
> On Mon, May 12, 2025 at 05:55:21PM +0200, Oleksii Kurochko wrote:
>> This is the first step toward supporting a vSBI UART.
>>
>> The implementation checks for the presence of the "vsbi_uart" property
>> in the device tree. If present, the vSBI UART is initialized by:
>> - Allocating a structure that holds Xen console rings and character
>>    buffers.
>> - Initializing the vSBI UART spinlock.
>>
>> This commit introduces the following:
>> - domain_vsbi_uart_init() and domain_vsbi_uart_deinit() functions.
>> - A new arch_kernel_info structure with a vsbi_uart member.
>> - A vsbi_uart structure to hold information related to the vSBI
>>    driver, including:
>>    - Whether the vSBI UART backend is in the domain or in Xen.
>>    - If the backend is in Xen: details such as ring buffer, ring page,
>>      Xen console ring indexes, and character buffers.
>>    - A spinlock for synchronization.
>>
>> Also, introduce init_vuart() which is going to be called by dom0less
>> generic code during guest domain construction.
>>
>> Signed-off-by: Oleksii Kurochko
> JFYI, I started to move all virtual UARTs under drivers/vuart directory
> and introducing a framework for hooking vUARTs into console driver.
>
> pl011 emulator cleanup
>    https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/3c635962a349afed75f47cd2559a4160ffa41106
>
> original 'vuart' for hwdom cleanup
>    https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/405c86cbd6d55f5737dc9ccf9b8a8f370767e3f0
>
> move pl011 to drivers/vuart
>    https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/4b5cdff118a2795278dfcc2c1b60423b46e85f27
>
> move 'vuart' for hwdom cleanup to drivers/vuart
>    https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/d76c17b8056c1d500afd854a513403fc3774da51
>
> which is followed by vUART driver framework introduction (not posted):
>    https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/ebc7e83650e5e3f68e5d734e5c475c6bcde626fa
>
> These patches ^^ are not posted, since I do already have enough patches on
> the mailing list which are in progress.
>
> I did this work along w/ NS16550 emulator on x86.
>
> IMO, it is worth delivering those patches first and then integrate SBI UART.

Agree, it makes sense. But If it will take a lot of time to upstream/merge then I prefer this patch
go first to not block RISC-V upstreaming.

Anyway, I will look at your changes tomorrow.

Thanks.

~ Oleksii

--------------fSTWdDHqTBPPhtZzqumk8kgM
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    
    Hi Denis,


    
    
    On 5/16/25 9:50 PM, dmkhn@proton.me
      wrote:
    
    
    
    
    
      
    Hi Oleksii,

On Mon, May 12, 2025 at 05:55:21PM +0200, Oleksii Kurochko wrote:

    
      
    
        
    This is the first step toward supporting a vSBI UART.

The implementation checks for the presence of the "vsbi_uart" property
in the device tree. If present, the vSBI UART is initialized by:
- Allocating a structure that holds Xen console rings and character
  buffers.
- Initializing the vSBI UART spinlock.

This commit introduces the following:
- domain_vsbi_uart_init() and domain_vsbi_uart_deinit() functions.
- A new arch_kernel_info structure with a vsbi_uart member.
- A vsbi_uart structure to hold information related to the vSBI
  driver, including:
  - Whether the vSBI UART backend is in the domain or in Xen.
  - If the backend is in Xen: details such as ring buffer, ring page,
    Xen console ring indexes, and character buffers.
  - A spinlock for synchronization.

Also, introduce init_vuart() which is going to be called by dom0less
generic code during guest domain construction.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

    
      
    
      
    JFYI, I started to move all virtual UARTs under drivers/vuart directory
and introducing a framework for hooking vUARTs into console driver.

pl011 emulator cleanup
  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/3c635962a349afed75f47cd2559a4160ffa41106

original 'vuart' for hwdom cleanup
  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/405c86cbd6d55f5737dc9ccf9b8a8f370767e3f0

move pl011 to drivers/vuart
  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/4b5cdff118a2795278dfcc2c1b60423b46e85f27

move 'vuart' for hwdom cleanup to drivers/vuart
  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/d76c17b8056c1d500afd854a513403fc3774da51

which is followed by vUART driver framework introduction (not posted):
  https://gitlab.com/xen-project/people/dmukhin/xen/-/commit/ebc7e83650e5e3f68e5d734e5c475c6bcde626fa

These patches ^^ are not posted, since I do already have enough patches on
the mailing list which are in progress.

I did this work along w/ NS16550 emulator on x86.

IMO, it is worth delivering those patches first and then integrate SBI UART.
    
    
    
    
    Agree, it makes sense. But If it will take a lot of time to upstream/merge then I prefer this patch
go first to not block RISC-V upstreaming.

Anyway, I will look at your changes tomorrow.

Thanks.

~ Oleksii
    
  


--------------fSTWdDHqTBPPhtZzqumk8kgM--


From xen-devel-bounces@lists.xenproject.org Wed May 21 11:40:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 11:40:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991723.1375547 (Exim 4.92)
	(envelope-from )
	id 1uHhob-00012V-TW; Wed, 21 May 2025 11:40:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991723.1375547; Wed, 21 May 2025 11:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHhob-00012O-QM; Wed, 21 May 2025 11:40:53 +0000
Received: by outflank-mailman (input) for mailman id 991723;
 Wed, 21 May 2025 11:40:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHhob-00012I-0q
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 11:40:53 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 721d8d88-3638-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 13:40:51 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-ad5574b59c0so694264466b.2
 for ; Wed, 21 May 2025 04:40:51 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d04af35sm889539466b.32.2025.05.21.04.40.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 04:40: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" 
X-Inumbo-ID: 721d8d88-3638-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747827650; x=1748432450; darn=lists.xenproject.org;
        h=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;
        bh=jpFJCKcCrT4E6iFxkrqzaSnB0yEpCDzQJhLI9suyxwY=;
        b=bJDbMt58qBK8aqycQQKBgjqnX1xkBxhdlV2cSoGjf6Uv2SmP4Cdwgh0m1b4ys999Ga
         ex5ThNjfQJLPZDUtn8bddqKSmDg3I9Z91zQ2d4bB3dgW+OPvydTaDiTUITngRq+V1osY
         AiJvlhd8TfcYVpY4r2N3eRcMjGVretbZtSUNkZbH/6IkyacZfWguRFIsL8mLcJe7eTMe
         E5x2E723H287MCRRYuL5UwoU1abmuwhUxhGUw303HFBYJ1YcJgmGqpVtErwbESoqg6Ko
         b0aKPLZqjCHgW+h0YtPbhjbJVZ/HL8QaMjAzwuDMAgdY9ol9C1qfkbupxs0TMqn8KekR
         SJng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747827650; x=1748432450;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=jpFJCKcCrT4E6iFxkrqzaSnB0yEpCDzQJhLI9suyxwY=;
        b=Lnvy4bMLYnKHVpdBSFTjiQPT/BGHLuyZFASNjpZ92FalL3c2sqp4MqaaNnMZxS1K3v
         zHw6obg4SodoF9vptm5SClWNRN+FYP9af+rJDAzQycIhnchCrQBvi1309LnKPvwG0laX
         b+v87QI3zomb+xCMR71uQPGGrdtIx3x2OulbPuP7H5mmfGI2uBqjara1KGY0HMeDznAb
         5NXhzgUiZWaxFJWBVCUjtaUR3aKsbwMntuzxO/tIYlLq9iTrO8wyXRX8iMFkznBMC/e+
         xaKsncAkWqQHB/11Hgk7q4j0mQp5nenAZp+puE8ezD288xRxzBkXTJDzNcbivoez0a9z
         U79Q==
X-Forwarded-Encrypted: i=1; AJvYcCWQRW/SQQNhg4kzSct5fT2vTdXKkihqa7lCq7qfYKHS7YY8kY+ZceReiaQsmb5jFA2tSlxkUrN9plY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxsJtnqPzdau/IM0usiAtz+Zw7Ha1udVnkRIsXbR68xjhyLZtvQ
	hzgWCwKp3xKQK3Cs+PjfrTpJGDRigNZsgmgpdmFQWZmKhp0VG5d79voW
X-Gm-Gg: ASbGnctiGrRQpYp5j8Sb/QRGG4uh2j2Mnb46zlAyG70r6OChMp9LZneQpYgiCNL6wTr
	uU3j9MNf50PxST+dGwf/170vKQVeGq0+6KVyeV1A+8IiblyvxKU6oAop/A/uo3VVL4oYZOkm+z0
	fCWySbiZIgWGwNRX+jGrePdg9L3HiZ71TJJizFFQ7DyUNiOwfRaiMbep+DkTxztZwvapX+3ZxNU
	qF/sYZd90Nill/JxHppQk1py/PHPSJpicTVsTtX5+2d8Bgqo8av/rb/TevnZO0JRGsHBF5DEXZf
	Mq6gT5yKH/DWc9nKwJOOFfesgKJLEYLrPtGCJJrd25hqAQtLL4RXWcrezof2oJq3KfX4Otm1ZKv
	DGc2lrm1wQcRx7bPetp0K8cmX
X-Google-Smtp-Source: AGHT+IGn7tG7D/2Ld4pT+XMP4CzTONeqOZQGTz8NA1Vs8c9RW5/qikwXoItcSOtvvEt0+O5N/aoH5g==
X-Received: by 2002:a17:906:f1c6:b0:ad5:2e5b:d16b with SMTP id a640c23a62f3a-ad536c1a81emr1625199666b.27.1747827650265;
        Wed, 21 May 2025 04:40:50 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------toL00BL1Do6yBuvY8isHmULQ"
Message-ID: 
Date: Wed, 21 May 2025 13:40:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen/riscv: add initialization support for virtual SBI
 UART (vSBI UART)
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: <1f380b7061496f999d4d60a60b58f494dae886e1.1747064551.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------toL00BL1Do6yBuvY8isHmULQ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/15/25 12:08 PM, Jan Beulich wrote:
> On 12.05.2025 17:55, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/Makefile
>> +++ b/xen/arch/riscv/Makefile
>> @@ -1,5 +1,6 @@
>>   obj-y += aplic.o
>>   obj-y += cpufeature.o
>> +obj-y += dom0less-build.o
> Arm uses
>
> obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
>
> Why the two differences?

Missed that. I have to understand why Arm uses *.init.o, but likely I should do the same for RISC-V.

>
>> --- /dev/null
>> +++ b/xen/arch/riscv/dom0less-build.c
>> @@ -0,0 +1,30 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
>> +                      const struct dt_device_node *node)
>> +{
>> +    int rc = -EINVAL;
>> +
>> +    kinfo->arch.vsbi_uart = dt_property_read_bool(node, "vsbi_uart");
>> +
>> +    if ( kinfo->arch.vsbi_uart )
>> +    {
>> +        rc = domain_vsbi_uart_init(d, NULL);
>> +        if ( rc < 0 )
>> +            return rc;
>> +    }
>> +
>> +    if ( rc )
>> +        panic("%s: what a domain should use as an UART?\n", __func__);
> Is this a reason to panic()? Isn't it possible for domains to be fine
> without any UART?

Good point.
I think that it is possible to leave without UART. At this stage,
of development I need UART for debug, so automatically the panic() was added.
But I agree, it should be dropped.

>> +    domain_vsbi_uart_deinit(d);
>> +
>> +    return rc;
>> +}
>> +
>> +void domain_vsbi_uart_deinit(struct domain *d)
>> +{
>> +    struct vsbi_uart *vsbi_uart = &d->arch.vsbi_uart;
>> +
>> +    if ( vsbi_uart->backend_in_domain )
>> +        printk("%s: backed in a domain isn't supported\n", __func__);
> Is this relevant in a de-init function?

Probably not, it was just added to not forget to update domain_vsbi_uart_deinit().

Thanks.

~ Oleksii

--------------toL00BL1Do6yBuvY8isHmULQ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/15/25 12:08 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 12.05.2025 17:55, Oleksii Kurochko wrote:

    
      
    
        
    --- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,5 +1,6 @@
 obj-y += aplic.o
 obj-y += cpufeature.o
+obj-y += dom0less-build.o

    
      
    
      
    Arm uses

obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o

Why the two differences?
    
    
    
    
    Missed that. I have to understand why Arm uses *.init.o, but likely I should do the same for RISC-V.


    
    
    
      
    

    
      
    
        
    --- /dev/null
+++ b/xen/arch/riscv/dom0less-build.c
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include <xen/bug.h>
+#include <xen/device_tree.h>
+#include <xen/errno.h>
+#include <xen/fdt-kernel.h>
+#include <xen/init.h>
+#include <xen/sched.h>
+
+#include <asm/vsbi-uart.h>
+
+int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
+                      const struct dt_device_node *node)
+{
+    int rc = -EINVAL;
+
+    kinfo->arch.vsbi_uart = dt_property_read_bool(node, "vsbi_uart");
+
+    if ( kinfo->arch.vsbi_uart )
+    {
+        rc = domain_vsbi_uart_init(d, NULL);
+        if ( rc < 0 )
+            return rc;
+    }
+
+    if ( rc )
+        panic("%s: what a domain should use as an UART?\n", __func__);

    
      
    
      
    Is this a reason to panic()? Isn't it possible for domains to be fine
without any UART?
    
    
    
    
    Good point.
I think that it is possible to leave without UART. At this stage,
of development I need UART for debug, so automatically the panic() was added.
But I agree, it should be dropped.


    
    
    
      
    
        
    +    domain_vsbi_uart_deinit(d);
+
+    return rc;
+}
+
+void domain_vsbi_uart_deinit(struct domain *d)
+{
+    struct vsbi_uart *vsbi_uart = &d->arch.vsbi_uart;
+
+    if ( vsbi_uart->backend_in_domain )
+        printk("%s: backed in a domain isn't supported\n", __func__);

    
      
    
      
    Is this relevant in a de-init function?
    
    
    
    
    Probably not, it was just added to not forget to update domain_vsbi_uart_deinit().

Thanks.

~ Oleksii
    
  


--------------toL00BL1Do6yBuvY8isHmULQ--


From xen-devel-bounces@lists.xenproject.org Wed May 21 11:53:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 11:53:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991735.1375557 (Exim 4.92)
	(envelope-from )
	id 1uHi0m-0002ts-1U; Wed, 21 May 2025 11:53:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991735.1375557; Wed, 21 May 2025 11: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 1uHi0l-0002tl-UH; Wed, 21 May 2025 11:53:27 +0000
Received: by outflank-mailman (input) for mailman id 991735;
 Wed, 21 May 2025 11:53:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHi0k-0002tf-Jo
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 11:53:26 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on2060f.outbound.protection.outlook.com
 [2a01:111:f403:260e::60f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 33016286-363a-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 13:53:24 +0200 (CEST)
Received: from AM0PR02CA0214.eurprd02.prod.outlook.com (2603:10a6:20b:28f::21)
 by DB3PR08MB9011.eurprd08.prod.outlook.com (2603:10a6:10:431::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Wed, 21 May
 2025 11:53:21 +0000
Received: from AMS0EPF000001AA.eurprd05.prod.outlook.com
 (2603:10a6:20b:28f:cafe::a1) by AM0PR02CA0214.outlook.office365.com
 (2603:10a6:20b:28f::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.29 via Frontend Transport; Wed,
 21 May 2025 11:53:21 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF000001AA.mail.protection.outlook.com (10.167.16.150) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Wed, 21 May 2025 11:53:20 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS8PR08MB9411.eurprd08.prod.outlook.com (2603:10a6:20b:5aa::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Wed, 21 May
 2025 11:52:48 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%3]) with mapi id 15.20.8699.022; Wed, 21 May 2025
 11:52: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" 
X-Inumbo-ID: 33016286-363a-11f0-a2fa-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=QMZL+6Dq0oSgb/CVa2t740rt+ojhWr7Mxdfh/uEjq7ylmlk9e+IpzsKegeESFIrGuP18/YZhejs2Fa9iQlGx5ytynnaVz3w80AFlaW9EA+/Z9BWOMLRpE8VwDM3EStG9KrGJp5XjmPH3HwVFf1xYlyi6gRUwIeDglXSPAqWL066KDoR0iOtKYQJACXP6BBeD+gl+C52xeK6DJ9jtbRsGjaCElMw2tq9omEyyLfJeF4t+jrdn2IzRa3Cm7azezmVttC8MA4O7gXkUhqFo4MEUeqfYGRXq+5RMu6f6uDed4hBmgKWEKzExVfjlV7/xgxF0NqIs4MOt+lG9NZaOBW0lqQ==
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=kQ2kmbFCMaxI6Hmq2bPgpDH8KVgS9owSxdy9Y1yT+g8=;
 b=soy44w5OwKX6ieUH8n9nt4NTS3Wrj/TAzfL/fStipU4O3kz0Nsgxa/7S5f6EDF7oHUdYL4VkKREiEojEQqe1dRK44ROjgtAXLXp1NeAO03Bdtqmddotha6YAzdG3EzhLzxK3Kyyl65PQSmuhLPJk6vnXINgvmH61MxfLJdFVowRGdM6xGhgswTQY+GDfzvHEh5eZETDLmGB6QqWByksGdesKK6bBrNbjbKW4Jgx51PoYzSSxNghyf+EnKspxUDegDzFapj+mJjQp9IS+RPX/P6UgEEJtOaR0PZgyjENq9k7n7+OvX8tqId9SDilWhrabR3ZcR93g/UDzsBWkhZ4oBA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.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=kQ2kmbFCMaxI6Hmq2bPgpDH8KVgS9owSxdy9Y1yT+g8=;
 b=Zskf+NDQ/jRtMz4XTPdPPK+WN3PA8BvOGje2WIFeW0C/5CIkY5cvjrpptIaKuY8cUFvpbcmll//i4d6vktyyLZViXKPKLc4YfroG9E0uZozN2v0hccKMpVzHr7444Wzn8SysMattyof86LJ0sKJogn7a3vj8UqOYp1v8WTcjBv0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PdEyE101PUZlwwD2MhAaPWL/gmyGAByfdAfcSIxB7QX/P87R7AtMVasc+HhNBGfpU5AKHwMJ3iPPsg2MypKZqS/ETC5pYrET3y7Pnz6zadIZjZj8rzu21VD50CpXO0ALy1VwKS6HN61nJysoDU4p0HhACKRDjInTWwdPi9faYL4yPrZLpDqlZjB0dAY55AiiKKQz+bqIfHWbnlTO+XlAq9JZsmNCR/w1Da8UoVNSPvk8GoqzbcXFf2hW8/Qkh21k2KK+jwlDygrHrTE85Nb9LnC9ZjqhGre3Ji339A3n095iJ0QeieJn5AkrFjLbyZx7zUnycB6ZVrbDDecwEwuRMQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kQ2kmbFCMaxI6Hmq2bPgpDH8KVgS9owSxdy9Y1yT+g8=;
 b=ikXVCyvK6pLGgjnLt8T7SkLO87w8NivY4m8o7Gd4ZqfqvbGQ4jYBeKIo5tXS6rGC2rtjDeTtgRz+2TAH5prkCK/u0Z4aGRHFiiM0pwiFJ2kIUr7QBV9ZUL3z2b5qisDY1FNgcfv4mk38AXYweE+RVOHCHLcuF24BhWbu5p6vNwKjEoWJl+/gW+Dj9iFIF2h/h9x5jUBob8yZ3DFLdJAW2rzoyBJLE/l1JRBUmHmLnp3HNgKb5Ff9RhKm+gGthUYcvnbosppybfFImHH8GzTw+JYsTq8GYdgXyg75aPpvU0Wld2gwebQJJOUpEvN/AdAVGke7vBt2/AAk+n7Wmb1v+Q==
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=kQ2kmbFCMaxI6Hmq2bPgpDH8KVgS9owSxdy9Y1yT+g8=;
 b=Zskf+NDQ/jRtMz4XTPdPPK+WN3PA8BvOGje2WIFeW0C/5CIkY5cvjrpptIaKuY8cUFvpbcmll//i4d6vktyyLZViXKPKLc4YfroG9E0uZozN2v0hccKMpVzHr7444Wzn8SysMattyof86LJ0sKJogn7a3vj8UqOYp1v8WTcjBv0=
From: Bertrand Marquis 
To: "Edgar E. Iglesias" 
CC: Stefano Stabellini , Julien Grall
	, Michal Orzel , Volodymyr Babchuk
	, "Edgar E. Iglesias" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: xen/arm: Virtio-PCI for dom0less on ARM
Thread-Topic: xen/arm: Virtio-PCI for dom0less on ARM
Thread-Index: AQHbyV3Hle+PZAZfxkivw95jajJbObPc+vWA
Date: Wed, 21 May 2025 11:52:47 +0000
Message-ID: <904E8858-E310-4D3E-A1AB-352D43C4EDC5@arm.com>
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|AS8PR08MB9411:EE_|AMS0EPF000001AA:EE_|DB3PR08MB9011:EE_
X-MS-Office365-Filtering-Correlation-Id: 2b1a1cf5-578c-4022-c8e6-08dd985e153f
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?RFRRdVA1b2hUTUZBQUZPYnRMUXljNU5yenUvSGNRRlpqemZXNVpqRVFYaTFJ?=
 =?utf-8?B?NkhEeW4zaysxdzM1ZjM3QllxeitxQnZvbERWb3pzZ3FnNlQ2YnoxUkhjLzY0?=
 =?utf-8?B?dTIwM25PYUxITmxlVjhUNjl2dDkxWWF1dWtpVVdpNDRwb3FPNHhzNVFPZS8z?=
 =?utf-8?B?dk1wb3hZMWMzK1BVOENmc3BaVHNKVzVqMXIwK3ArREtUSlRRajIvVGRKeVNu?=
 =?utf-8?B?NUh4cmNwYzlFUnZLTmFxSkZSVERMREdobnBaWERvcDJremJVaUIyRWsranpa?=
 =?utf-8?B?RldyeTB2TDhPMkFSNlp6ZEtJcjZIcm5SZkRwUU1CVHFHWGo1aVFuYXRVbEpk?=
 =?utf-8?B?MHp6cVBVZkhUYjBLMWY5NThFUDVuVGJBdGtxYm9RcFdTd3hJRVdCdlMxVHJ4?=
 =?utf-8?B?OVFhZGxhbjF6M0ZmQ1JXdzVCSnZLYzZpa1lqcGcvVmwyQ0dYYW1xNk9IRVFX?=
 =?utf-8?B?RDRWTW4wOGtlcDVibHFvZFBoZWtTYjhTTXN0R0xJUEZXejVYcDNvUm5WbjBV?=
 =?utf-8?B?dXpWVFI2YU1IMlJweVc5VytUTklNNzNjRDNYOW9iYTlPekRmTkh1REkxZCtY?=
 =?utf-8?B?aDRlWURGQmg5MnRtMi9HVDlXbXlhdUFhMklzbHlnakNDdERjRGx6Q3duZ0Nn?=
 =?utf-8?B?SCttd2hwVFVlbjVNWXFtMlUwYWR3QW4xUTFHMWhkVkNtcnJ5QTFDMHpWaTBk?=
 =?utf-8?B?VCt1RTBQMXFtOWJtZm1vY25kZUVJLzUwdXNRNmZ4RUhkbXhreFVFZkZMdWJO?=
 =?utf-8?B?QjBKRjFNYmRBRGVRdmN4dGIwYmZVd3R2dEV2dUd6bGZ6VnAyVGlwOXcyREFx?=
 =?utf-8?B?Zm1nNHRoS1E5SXhVcFRZM1kvNmFQaCtmckFMZmZhWWJCWWlSQ2RtOEVKclht?=
 =?utf-8?B?TElpd0RQdS90NnBicTZDdy8xV0lJN3I1OFRDUStzbEg2QjFFZGt6TWlwZW54?=
 =?utf-8?B?a0FrYzM1YWJqMmtuUnlCcURWanoxWHZodDFhbnJpd1NVOFhSWXpkeG5tbXJo?=
 =?utf-8?B?YkpxNFp4bEl2T3Y0Sjk1dVhtcmovVFdWTkFteWhRR0s0RWhKbGpBc05zMDlx?=
 =?utf-8?B?YUdTNFMvVFRqT0czNmgvMG1DdTZSOE94eFM4Mm5YcHM2QS9hZmllUDhLUGQv?=
 =?utf-8?B?SjdLbUpUMmt4NnpaNmtCU1VoMVE1d1I0aDhEckhMRjdPdWJqTkl6OXJBcXZE?=
 =?utf-8?B?dEcwY3ZaZU9zOVVoTjREWnlubW5nMzg4TW1YS2Q4ZWs2cmZYZjQwZ082dFhw?=
 =?utf-8?B?VHdsckVodWNjb0FZdDUxaVMrUlpnZEFMcmp4NFRHU20yY0M3TERFRmd4KzNa?=
 =?utf-8?B?QzE2bE5FMHlLNkJyTVZFUUt2UkZUNzNGL3JoS1lXQ05lR2tHZWxKSFEvRlh6?=
 =?utf-8?B?MjQxQWpFZVA2U1dNMjRPem9Vamg0WUV0OTh5eldzVHBmZTRmTzNxaEk4K2ZQ?=
 =?utf-8?B?aGlrY3lES2lYeHlpN3VYSjR6ZGNwaUdTbzdRODVnL0hnMk1FTm44UjdQRENQ?=
 =?utf-8?B?d3gyeTRNVHlDek1DWjJjU3JzVDUwOVhmK1FaK2VxZHZacld3VFRQeWdRVkUv?=
 =?utf-8?B?Tk9Wb2xkS2Y1aVZHZTFCc1Yrd3c5VmZ6NUR4T3RFY0dTTCs0UHNuN0VkZGdq?=
 =?utf-8?B?ejIrb3pMeXBwc1ZBaEJvTmlpMWN1U0RaTDRITCtBM05xYmFtSmNqZjZ6QnAv?=
 =?utf-8?B?c1BpbHNsYkZWdWhGTUhsei85NHBjMCtzYzU0ZmZjazg5N2M4NE1qbmVFU3lL?=
 =?utf-8?B?aVJqbGZXcCtrc0I4cHJqVWVLV2w4aGxVVHlFWEJ4M01GWHVObTdpV0Rsblps?=
 =?utf-8?B?ZDdKY1p5WTFYWGhOSWxLUVl2dWZsSUYxRTlZUTJ5TTZPc1B3NjJIUUh3TEpY?=
 =?utf-8?B?c0NZTjZROGNHV3FYUjFjd2dTNnRlSE1Zc2V4aTVTaDQzZVI4TzFuNGVJQWpQ?=
 =?utf-8?B?UnFqNXdoQ054TUNrcWl2Smx5cEMzTk0xTklxRGcwdmFhaXMrWmt5YjhYSkZG?=
 =?utf-8?Q?F1Iu4sO6y7JLZ/1diaOHg3cDkcqINY=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9411
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF000001AA.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	2aef9a43-b662-49e1-e8ae-08dd985e01ac
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|35042699022|14060799003|1800799024|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?T3B4RE1MaVNHaVJUcFRRRkdWY291WWh4aWRneUIvSmZuQ0dZc1VKOU95U1ZK?=
 =?utf-8?B?MXlEc3cwampaYnpPWlA2QStQVjNrNTJwcEQzYkVOUjFRRlRLejViSEZJTUdq?=
 =?utf-8?B?dmVUdVZzejZSK0QxU0lPVkFjOGVhMmFldVo5eXA4azZPVTZpdWhnaHVDSkZK?=
 =?utf-8?B?NnVqNllCZmhrY25vcWRyN0tXbjl3NUp0SStaQWg5RzVMODhiYitlTFVWYTJ0?=
 =?utf-8?B?MFRkYWRiRFdWbkxNZjI2RlNWbmhqeUlCYURYRFBaUTRjZCtVcUVEazlDcFZa?=
 =?utf-8?B?MzI0anR2WlMvcjdyOFFWZDcxSTZpWXFOVXBPKzNVdm0raklWS2NOQW1tcFBa?=
 =?utf-8?B?eGk1ZUU0VW9YMFNiVFZPL3BFbkVMdWlZMUtwbmVCSUU4R1dqbWs1N3hTUElU?=
 =?utf-8?B?QU84YXI5SHRuOUxoaFM5S1JRMHA4OHNmQXZ1aVhObFdKZFo0d2w4REI2dkNT?=
 =?utf-8?B?dFJBMnlLc1NCWkNLR2xya2MzaWl0REhnSW9Ra2E1b2xBdGFpYlVndnBjME1p?=
 =?utf-8?B?M2tZdHFqUjNDVHFJYVJYSGJicEI3SGhwVFhHYW5TdjhHRHhYc08vQ0c4VVNu?=
 =?utf-8?B?ckRVYUt3Wk1TNFYway9nVjUvZVZHLzg3WVNrdE9nMW1rK0JyODNWNDBLVlh1?=
 =?utf-8?B?TnA4Y1NxbFNLT3JCT0J1ZjByWHFDMWt4WWF3ZHF2NHdSa3dwbGJ6TU4waWlE?=
 =?utf-8?B?ZEpYNmVKL1lGbC94NW0rYyt0bUN2N1BjckVma2RlVm9yUDZJWWl0N2ExTFBJ?=
 =?utf-8?B?SDlxWHdzV0lVMnBENXNndVlROTlhM0ZqQStIUWQ3ZWJ1QWZVNmZTOFR2R09Y?=
 =?utf-8?B?ZVZMTy9TYU0vUFVmOHdZSWNvbkQ3OUlNZ0hnbDAwKzdkVHQvOFpkck40UWJN?=
 =?utf-8?B?K04rSFJzQU1BMlBOd0FQbHZFSlhIbDNnZVJOQnNjTEVySjFyM080TXdsNlB1?=
 =?utf-8?B?SVdsK1JwVjJaWFVvZU1aRXFWdzVmTzBkOFNVaHE0SUx2bVlWbUZyNEJWNVJk?=
 =?utf-8?B?b2MxN2p3WStrblFKemVwempONlFRNHNHZ0dScE9TT1QxK0tCUGVidzgyWkRG?=
 =?utf-8?B?cDVWdG9JcVJKRHJRd2cwaytHZHlXVnFscnBTWWo5Y0ZVR2phVVNVZCsyRU03?=
 =?utf-8?B?RUNLUmw4R280YVo4bFJZVW93a1dIYzlVMGZVQ3FlWkZTSUtCaDg1a0xoeFNX?=
 =?utf-8?B?TE5ZODlHdFVZbW1saGZYcC8xQUhVblltVklSQmkvbXRRTWJ2NFB2SFlNWjdW?=
 =?utf-8?B?ckF2SXlNNFVuYWV5V0xLTEttSGVYeEtUSzBwbzJxUTZaR0lkVCtmZXZvU2ha?=
 =?utf-8?B?cGxqbThOWk9LMWVXWVR1WmZiaWp6R0JORi8xbUhjR0F1dXNDMDAvMERGVytK?=
 =?utf-8?B?RUtoOFBwelZjRG5YTkVCQ2ZEVFlCbHNwamszeUlpSkQwNkVLcVZpU0J2c0Z5?=
 =?utf-8?B?UURCT1FKMmNpdXV1RFR5SE1Ed0N3cC9xSGdCMDU4Y1RsbDlocXYxK2VFQ3BW?=
 =?utf-8?B?VVZ2cjRoZFNoRk5lMC8waUFJL204TE1LWEZHWU1YUWk1LzBsM1dTc1pLbWVP?=
 =?utf-8?B?U2tmeWR0c2VVWlRvbzRLNWJ0eitqQW13SnBVekZSZDNWYjRTUTRVVUpHcUph?=
 =?utf-8?B?ellTa01OZGVlbXRnUXJ4cHhvN1ZlNVZvRm82eExIRHg1aWNGT2JoWXdDa3hj?=
 =?utf-8?B?QlQ3YjNQUlVNTHJ2ZVdldHJ1SUxwbU84eE92b0xvd0todWhyQ2tETzBjK09h?=
 =?utf-8?B?YmdObEcxVGFCaVNrQU1Ga0k1ZjBaQWpLenJhMlltZ2dQTm1jbzRaNEZzYS83?=
 =?utf-8?B?STRzdStRODhvVnZKWWdNaER2aUg3RVlqUFVOckJmSEJLVXVIdDFVTFdwYkNI?=
 =?utf-8?B?S2IxdUZBSUVqay8vTGZEMXJHM3FVejRublJFOU5WK3E0QmhXVDRkeUVQaWdP?=
 =?utf-8?B?VkdCV1ZrTlRCQUNHbHZhRnUwMjU1VDlJbGdmRGFwRkV5ZDB3cXlPOWk3VUU2?=
 =?utf-8?B?d1d1aUlQanY4L3B1cWJLWGlBVkdwa2NhTTRxNFhKT2NTVFE5NU9DWCt2S2x5?=
 =?utf-8?B?NDFsUTFsaTF4Tjc4ZHRXbGUrL29STHpyd3pBZz09?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(35042699022)(14060799003)(1800799024)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2025 11:53:20.6351
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b1a1cf5-578c-4022-c8e6-08dd985e153f
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:
	AMS0EPF000001AA.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB9011

SGkgRWRnYXIsDQoNCj4gT24gMjAgTWF5IDIwMjUsIGF0IDEwOjA0LCBFZGdhciBFLiBJZ2xlc2lh
cyA8ZWRnYXIuaWdsZXNpYXNAYW1kLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBG
b2xsb3dpbmcgdXAgb24gdGhlIEFSTSB2aXJ0aW8tcGNpIHNlcmllcyBJIHBvc3RlZCBhIHdoaWxl
IGJhY2sgYWdvLg0KPiANCj4gVGhlcmUgaGF2ZSBiZWVuIHNvbWUgY29uY2VybnMgYXJvdW5kIHRo
ZSBkZWxheWVkIGFuZCBzaWxlbnQgYXBwZXJhbmNlIG9mDQo+IGRldmljZXMgb24gdGhlIEVDQU0g
YXJlYS4gVGhlIHNwZWMgaXMgbm90IHN1cGVyIGNsZWFyIHdldGhlciB0aGlzIGlzIE9LIG9yDQo+
IG5vdCBidXQgSSdtIHByb3ZpZGluZyBzb21lIHJlZmVyZW5jZXMgdG8gdGhlIFBDSSBzcGVjcyBh
bmQgdG8gc29tZSByZWFsIGNhc2VzDQo+IHdoZXJlIHRoaXMgaXMgdXNlZCBmb3IgRlBHQXMuDQo+
IA0KPiBUaGVyZSBhcmUgdHdvIG9wdGlvbnMgaG93IHRvIGltcGxlbWVudCB2aXJ0aW8tcGNpIHRo
YXQgd2UndmUgZGlzY3Vzc2VkOg0KPiAxLiBWUENJICsgSU9SRVENCj4gMi4gSU9SRVEgb25seQ0K
PiANCj4gVGhlcmUgYXJlIHByb3MgYW5kIGNvbnMgd2l0aCBib3RoLiBGb3IgZXhhbXBsZSB3aXRo
ICMxLCBoYXMgdGhlIGJlbmVmaXQgdGhhdA0KPiB3ZSB3b3VsZCBvbmx5IGhhdmUgYSBzaW5nbGUg
UENJZSBSQyAoaW4gWGVuKSBhbmQgd2UgY291bGQgZW11bGF0ZSBhIGhvdHBsdWcNCj4gY2FwYWJs
ZSBleHBhbnNpb24gcG9ydCB3aXRoIGEgc3RhbmRhcmQgd2F5IHRvIG5vdGlmeSB3aGVuIFBDSSBk
ZXZpY2VzIHBsdWcgaW4uDQo+IEFwcHJvYWNoICMyIGhhcyB0aGUgYmVuZWZpdCB0aGF0IHRoZXJl
IGlzIChhbG1vc3QpIG5vIGFkZGl0aW9uYWwgY29tcGxleGl0eQ0KPiBvciBjb2RlIGFkZGVkIHRv
IFhlbiwgYWxtb3N0IGV2ZXJ5dGhpbmcgbGl2ZXMgb3V0c2lkZS4NCj4gSU1PLCBib3RoIG9wdGlv
bnMgaGF2ZSBtZXJpdCBhbmQgYm90aCBjb3VsZCBjby1leGlzdC4NCj4gDQo+IEZvciBkeW5hbWlj
IHhsIGZsb3dzLCBvcHRpb25zICMyIGFscmVhZHkgd29ya3Mgd2l0aG91dCBtb2RpZmljYXRpb25z
IHRvIFhlbi4NCj4gVXNlcnMgbmVlZCB0byBwYXNzIHRoZSBjb3JyZWN0IGNvbW1hbmQtbGluZSBv
cHRpb25zIHRvIFFFTVUgYW5kIGEgZGV2aWNlLXRyZWUNCj4gZnJhZ21lbnQgd2l0aCB0aGUgcGNp
LWdlbmVyaWMtZWNhbS1ob3N0IGRldmljZS4NCj4gDQo+IEZvciBzdGF0aWMgZG9tMGxlc3MgZmxv
d3MsIHdlIGNhbiBkbyB0aGUgc2FtZSBhcyBmb3IgeGwgZmxvd3MgYnV0IHdlIGhhdmUgdGhlDQo+
IGFkZGl0aW9uYWwgcHJvYmxlbSBvZiBkb21VJ3MgUENJIGJ1cyBlbnVtZXJhdGlvbiByYWNpbmcg
d2l0aCBRRU1VLg0KPiBPbiB4ODYsIHdoZW4gZG9tVSdzIGFjY2VzcyBhIG1lbW9yeSByYW5nZSB0
aGF0IGhhcyBub3QgeWV0IGdvdCBJT1JFUSdzDQo+IGNvbm5lY3RlZCB0byBpdCwgdGhlIGFjY2Vz
c2VzIHN1Y2NlZWRzIHdpdGggcmVhZHMgcmV0dXJuaW5nIDB4RkZGRkZGRkYgYW5kDQo+IHdyaXRl
cyBpZ25vcmVkLiBUaGlzIG1ha2VzIGl0IGVhc3kgZm9yIGd1ZXN0cyB0byB3YWl0IGZvciBJT1JF
USBkZXZpY2VzIHRvDQo+IHBvcCB1cCBzaW5jZSBndWVzdHMgd2lsbCBmaW5kIGFuIGVtcHR5IGJ1
cyBhbmQgY2FuIGluaXRpYXRlIGEgcmVzY2FuIGxhdGVyDQo+IHdoZW4gUUVNVSBhdHRhY2hlcy4g
T24gQVJNLCB3ZSB0cmFwIG9uIHRoZXNlIGFjY2Vzc2VzLg0KPiANCj4gSWYgd2Ugb24gQVJNIGFk
ZCBzdXBwb3J0IGZvciBNTUlPIGJhY2tncm91bmQgcmVnaW9ucyB3aXRoIGEgZGVmYXVsdCByZWFk
IHZhbHVlLA0KPiBpLmUgbW1pbyBoYW5kbGVycyB0aGF0IGhhdmUgbG93ZXIgcHJpb3JpdHkgdGhh
biBJT1JFUXMgYW5kIHRoYXQgYXJlDQo+IHJlYWQtY29uc3QgKyB3cml0ZXMtaWdub3JlZCwgd2Ug
Y291bGQgc3VwcG9ydCB0aGUgc2FtZSBmbG93IG9uIEFSTS4NCj4gVGhpcyBtYXkgYmUgZ2VuZXJh
bGx5IHVzZWZ1bCBmb3Igb3RoZXIgZGV2aWNlcyBhcyB3ZWxsIChlLmcgdmlydGlvLW1taW8gb3IN
Cj4gc29tZXRoaW5nIGVsc2UpLiBXZSBjb3VsZCBhbHNvIHVzZSB0aGlzIHRvIGRlZmVyIFBDSSBl
bnVtZXJhdGlvbi4NCj4gDQo+IFNvIHRoZSBuZXh0IHZlcnNpb25zIG9mIHRoaXMgc2VyaWVzIEkg
d2FzIHRoaW5raW5nIHRvIHJlbW92ZSB0aGUgUENJIHNwZWNpZmljcw0KPiBhbmQgaW5zdGVhZCBh
ZGQgRkRUIGJpbmRpbmdzIHRvIEFSTSBkb20wbGVzcyBlbmFibGluZyBzZXR1cCBvZiB1c2VyDQo+
IGNvbmZpZ3VyYWJsZSAoYnkgYWRkcmVzcy1yYW5nZSBhbmQgcmVhZC12YWx1ZSkgYmFja2dyb3Vu
ZCBtbWlvIHJlZ2lvbnMuDQo+IFhlbiB3b3VsZCB0aGVuIHN1cHBvcnQgb3B0aW9uICMyIHdpdGhv
dXQgYW55IFBDSSBzcGVjaWZpY3MgYWRkZWQuDQo+IA0KPiBUaG91Z2h0cz8NCg0KV2UgZGlzY3Vz
c2VkIHRoYXQgdG9nZXRoZXIgbGFzdCB3ZWVrIGFuZCBJIHRoaW5rIHRoaXMgaXMgYSBnb29kIGFw
cHJvYWNoIGFzIGl0DQpwcmV2ZW50cyBoYXZpbmcgc29tZSAid29ya2Fyb3VuZCIgY29kZSBmb3Ig
UENJIG5vdCBmb2xsb3dpbmcgdGhlIFZpcnRpbyBzcGVjIGFuZA0KY291bGQgYWxzbyBmdWxmaWwg
c29tZSBvdGhlciB1c2UgY2FzZXMgYnkgZ2l2aW5nIGEgc29sdXRpb24gdG8gZW11bGF0ZSBzb21l
IElPDQpyZWdpc3RlcnMgZm9yIGEgZ3Vlc3Qgd2l0aCBhIGZpeGVkIHZhbHVlLg0KDQpDaGVlcnMN
CkJlcnRyYW5kDQoNCj4gDQo+IENoZWVycywNCj4gRWRnYXINCj4gDQo+ICMgUmVmZXJlbmNlcyB0
byBzcGVjDQo+IA0KPiBQQ0kgZXhwcmVzcyBiYXNlIHNwZWNpZmljYXRpb246DQo+IDcuNS4xLjEu
MSBWZW5kb3IgSUQgUmVnaXN0ZXIgKE9mZnNldCAwMGgpDQo+IFRoZSBWZW5kb3IgSUQgcmVnaXN0
ZXIgaXMgSHdJbml0IGFuZCB0aGUgdmFsdWUgaW4gdGhpcyByZWdpc3RlciBpZGVudGlmaWVzIHRo
ZSBtYW51ZmFjdHVyZXIgb2YgdGhlIEZ1bmN0aW9uLiBJbiBrZWVwaW5nIHdpdGgNCj4gUENJLVNJ
RyBwcm9jZWR1cmVzLCB2YWxpZCB2ZW5kb3IgaWRlbnRpZmllcnMgbXVzdCBiZSBhbGxvY2F0ZWQg
YnkgdGhlIFBDSS1TSUcgdG8gZW5zdXJlIHVuaXF1ZW5lc3MuIEVhY2ggdmVuZG9yIG11c3QNCj4g
aGF2ZSBhdCBsZWFzdCBvbmUgVmVuZG9yIElELiBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHNvZnR3
YXJlIHJlYWQgdGhlIFZlbmRvciBJRCByZWdpc3RlciB0byBkZXRlcm1pbmUgaWYgYSBGdW5jdGlv
biBpcw0KPiBwcmVzZW50LCB3aGVyZSBhIHZhbHVlIG9mIEZGRkZoIGluZGljYXRlcyB0aGF0IG5v
IEZ1bmN0aW9uIGlzIHByZXNlbnQuDQo+IA0KPiBQQ0kgRmlybXdhcmUgU3BlY2lmaWNhdGlvbjoN
Cj4gMy41IERldmljZSBTdGF0ZSBhdCBGaXJtd2FyZS9PcGVyYXRpbmcgU3lzdGVtIEhhbmRvZmYN
Cj4gUGFnZSAzNDoNCj4gVGhlIG9wZXJhdGluZyBzeXN0ZW0gaXMgcmVxdWlyZWQgdG8gY29uZmln
dXJlIFBDSSBzdWJzeXN0ZW1zOg0KPiDvgbEgRHVyaW5nIGhvdHBsdWcNCj4g74GxIEZvciBkZXZp
Y2VzIHRoYXQgdGFrZSB0b28gbG9uZyB0byBjb21lIG91dCBvZiByZXNldA0KPiDvgbEgUENJLXRv
LVBDSSBicmlkZ2VzIHRoYXQgYXJlIGF0IGxldmVscyBiZWxvdyB3aGF0IGZpcm13YXJlIGlzIGRl
c2lnbmVkIHRvIGNvbmZpZ3VyZQ0KPiANCj4gUGFnZSAzNjoNCj4gTm90ZTogVGhlIG9wZXJhdGlu
ZyBzeXN0ZW0gZG9lcyBub3QgaGF2ZSB0byB3YWxrIGFsbCBidXNlcyBkdXJpbmcgYm9vdC4gVGhl
IGtlcm5lbCBjYW4NCj4gYXV0b21hdGljYWxseSBjb25maWd1cmUgZGV2aWNlcyBvbiByZXF1ZXN0
OyBpLmUuLCBhbiBldmVudCBjYW4gY2F1c2UgYSBzY2FuIG9mIEkvTyBvbiBkZW1hbmQuDQo+IA0K
PiBGUEdBJ3MgY2FuIGJlIHByb2dyYW1tZWQgYXQgcnVudGltZSBhbmQgYXBwZWFyIG9uIHRoZSBF
Q0FNIGJ1cyBzaWxlbnRseS4NCj4gQW4gUENJIHJlc2NhbiBuZWVkcyB0byBiZSB0cmlnZ2VyZWQg
Zm9yIHRoZSBPUyB0byBkaXNjb3ZlciB0aGUgZGV2aWNlOg0KPiBJbnRlbCBGUEdBczoNCj4gaHR0
cHM6Ly93d3cuaW50ZWwuY29tL2NvbnRlbnQvd3d3L3VzL2VuL2RvY3MvcHJvZ3JhbW1hYmxlLzY4
MzE5MC8xLTMtMS9ob3ctdG8tcmVzY2FuLWJ1cy1hbmQtcmUtZW5hYmxlLWFlci5odG1sDQo+IA0K
DQo=


From xen-devel-bounces@lists.xenproject.org Wed May 21 12:02:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 12:02:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991748.1375567 (Exim 4.92)
	(envelope-from )
	id 1uHi9q-0004gg-Vd; Wed, 21 May 2025 12:02:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991748.1375567; Wed, 21 May 2025 12: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 1uHi9q-0004gZ-T1; Wed, 21 May 2025 12:02:50 +0000
Received: by outflank-mailman (input) for mailman id 991748;
 Wed, 21 May 2025 12:02:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHi9p-0004gQ-2p
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 12:02:49 +0000
Received: from AM0PR83CU005.outbound.protection.outlook.com
 (mail-westeuropeazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c201::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 81f913ba-363b-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 14:02:46 +0200 (CEST)
Received: from DB3PR06CA0030.eurprd06.prod.outlook.com (2603:10a6:8:1::43) by
 AM9PR08MB5972.eurprd08.prod.outlook.com (2603:10a6:20b:280::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.19; Wed, 21 May
 2025 12:02:44 +0000
Received: from DU6PEPF0000B61E.eurprd02.prod.outlook.com
 (2603:10a6:8:1:cafe::b4) by DB3PR06CA0030.outlook.office365.com
 (2603:10a6:8:1::43) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Wed,
 21 May 2025 12:02:44 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DU6PEPF0000B61E.mail.protection.outlook.com (10.167.8.133) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Wed, 21 May 2025 12:02:43 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS2PR08MB8746.eurprd08.prod.outlook.com (2603:10a6:20b:55e::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Wed, 21 May
 2025 12:02:09 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%3]) with mapi id 15.20.8699.022; Wed, 21 May 2025
 12:02: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" 
X-Inumbo-ID: 81f913ba-363b-11f0-b892-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=Yorev5a9wW0TFMwcld0RsP8P+JK+yrDMyX8uNcmDNPkxYGNflTKft3hNjxfbpQX1IOtVzAN1c3IL21dfF/3+eYYPD+wz8Eb+bgPyINip9WPfsM444jP7gXkIk3BcdAa20DFw1gc7O9p0AxD/6x1Ivu712uL3lOxhKMO6nH03AEy0zJRv1KxSU7qjRV1vSRQ/QWboFHpYt4VOg6GZCLNWoeVj8VUls7sf9nZ4qrZrC11quOINMoNAcb2NP0sSbLnGfwuAkAiE40ugoeU/hBf3Bmyz1ZH2Kd+MvUQgBPjLX5pwl9ctfgBYCTe1K7/GNJXJaaYaeLan1+dKis9Tv7QBGQ==
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=uOEPHl1FhvYGERFHBgtJVoJZVRe0UGt8udpoGR2MPAk=;
 b=tjgz1KtO0RsUpubXKr1HSOmYxTD9bEA/8c9ienXwST/oXuoa09uUfb1phtDuozKuKEfXyQbBtrrNLj0TBoOuxE1g8dmkL3Un2IawNVw4SodNCNKHfouea1QIhie5SrMLimpC+k6Wtq2VBuatSnkU9UBIh+UO2D9ttWBPQI081knl0pRG7ekHfG9n5l/pfUSEuyNKxZCmy/LhalCrnA8+QaTPsJYfp4ppF3vg7AnzALCd7u/5ZdkqKPZoUVmvpTODnY1idOgfo79/2eG4ahXquERNWRy4NnDA9DrlhEx6iCf7NzyAVHVLDYpB3u/ZpAAZPLefMjCc010pg1Eyxq4gsA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.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=uOEPHl1FhvYGERFHBgtJVoJZVRe0UGt8udpoGR2MPAk=;
 b=BTvmyXtVh5sOf8aLgUku4XSQAswMD6Q/1cifWvmZXkVioSoNZ708h0UjLWZjNTrRlWO1S4tdqLiuKsly/Qf4P+jrgSkp/Ae8rDPpvnEloebbP+YZoRcPduVP0BkUyS+OpucDB4c01JkYv0ChMC3BFm4U4GhMbI1DInr3dkjqtpE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bjjWOjvDqJh/Mc+dnV+Yw9bnFKBP6h2bkyitQHjN+ljeUCpwBoYgu10bkbl63y7i7DxVUG7nkqH2lTFQr2NYH8LPO/Gj14q0aru6nXzyf4yDJ8I55XlCHdKe0o6y+UeB4HhEOCBxZt2ohbIqaME6PJ4oi78gs67kI+OdwxftFYn1gjHY4OglmfbYmtIaL9s//JZDX0ACPIRuwftyziXoPhElhwN2ll5rKZb/Zt1eJKsMk3u5lveY6h6cK59JSJ6BoPt6uDkTQExkGyu3Jzwrrjv8mMJr2sZiL2v3O1HhUwEa7U4W/my64xwio7hhn9jBQrRyN1qKNo9jhoLDuL2MnA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uOEPHl1FhvYGERFHBgtJVoJZVRe0UGt8udpoGR2MPAk=;
 b=FjETdrnivfLyzPoTPO77GfmAGgm4YhPl3VImWmr1iZuuxlSQ8LB3YVCKbKgYg3NCIKXz/22kZKiD18ZKbPaGW2ODwJl+CC1QYfPGTECctzZtRB/S6jL9n89lDauROH5QQi4utu347clYUWImT5YjRmwcXtq5LUL0OMbprp1j6MVs/W4S1qSriR7QsElsY4bQ3TiPlSZLTekqSNwpiLo8UIRM6er+FZJ0OdyZZZ0r+kvwF11L7x/S1wgkaMa6HFtutFcqau4/0BbUhHnsWjHMCtXAJfS2JxcwkzOWJy7S+AilH9TuYAAl4r795YvtmCOhwONWTVW6VP2MXt9gFX0dDA==
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=uOEPHl1FhvYGERFHBgtJVoJZVRe0UGt8udpoGR2MPAk=;
 b=BTvmyXtVh5sOf8aLgUku4XSQAswMD6Q/1cifWvmZXkVioSoNZ708h0UjLWZjNTrRlWO1S4tdqLiuKsly/Qf4P+jrgSkp/Ae8rDPpvnEloebbP+YZoRcPduVP0BkUyS+OpucDB4c01JkYv0ChMC3BFm4U4GhMbI1DInr3dkjqtpE=
From: Bertrand Marquis 
To: Ayan Kumar Halder 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Michal Orzel ,
	Artem Mygaiev 
Subject: Re: [PATCH v3 1/2] docs: fusa: Define the requirements for
 XEN_VERSION hypercall.
Thread-Topic: [PATCH v3 1/2] docs: fusa: Define the requirements for
 XEN_VERSION hypercall.
Thread-Index: AQHbwNT/SvCvWvdWh0CT9yLy3QlhobPdDqQA
Date: Wed, 21 May 2025 12:02:09 +0000
Message-ID: <2040B386-299A-4BC5-BC59-7D3F58835A2B@arm.com>
References: <20250509112447.2931909-1-ayan.kumar.halder@amd.com>
In-Reply-To: <20250509112447.2931909-1-ayan.kumar.halder@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|AS2PR08MB8746:EE_|DU6PEPF0000B61E:EE_|AM9PR08MB5972:EE_
X-MS-Office365-Filtering-Correlation-Id: 1ba22844-57e6-4726-40d6-08dd985f648e
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?7ootux0WZKMkYdA0JHKL6/ImrZ0KiMwfpBAq/u7ukReJiMECRqBu9HZ9T38V?=
 =?us-ascii?Q?kqQmv7SVV6QST8eSL8Pxz5CJ3RxyKjRNGRZemIn5/pqNFOaqfELz6r7iZvUV?=
 =?us-ascii?Q?p+UqF1y98hP/ojeGwdD0ZuEyqLhERXGGfIDwtl3G5e9rUPZPDjRSUdj+ApgM?=
 =?us-ascii?Q?iE0cAs9Mug0JkQdHd6LhnDxUgzgQux4Pk9I7VKd9Inxg77xhlemnpC3EvB4T?=
 =?us-ascii?Q?SHHmorKqncfhVblrVjv2JtcDmBqzWV9+pa3KVFOlosVtRAYirSCHQvWGiiT1?=
 =?us-ascii?Q?I9HD+mzb6jTQ0FgaF7JTXAQW9corV75v7/JmE0W+TWS/K01CTjUNg8yWOYte?=
 =?us-ascii?Q?TK61/SSnytwPqXzeg5BvNOEUh0sehq/EjX5B1872dd1mJ4uCi/o6sk0FmKp+?=
 =?us-ascii?Q?YT07PSZD44YtftRyaaUgaffa1tPg7V+/lQeDL/M9bfCx/JUGzOED8Ik1s8c/?=
 =?us-ascii?Q?X2UBBEAdkCd4fB0bdP0t9WHkiOnqsntX+ui+aX+jQoeFYx1S2OvYSFATV196?=
 =?us-ascii?Q?N3pB9O98ZCXORPuHbKxY/2S05c63S36gUDEzWDi0jh7mTATGUCJu7F93qmCu?=
 =?us-ascii?Q?wsT+c7/h8pJHW6IfYJhR7zde8+KHI72VIp771jXzcletWPKkNmZLlOwfgoQx?=
 =?us-ascii?Q?lpXqP/QJf0+9N8SdjakOe1Z/6oM1YWjc/3Z4f6s+M7GF5JPw2xhAUqJbll/l?=
 =?us-ascii?Q?yWsiqkK9KyL+1ywaB6SjMTtWFayMKkQMIXuOJKl5CMk5IzXGQE8qYb0fN7Rl?=
 =?us-ascii?Q?EVPrU6beDJTh5urAaNuSbdv1mqxQt+CadQalDt6goyM1rYQ9YHUKfRKMyl6S?=
 =?us-ascii?Q?ApeV0PNKM1gLmkNjCUjJZbBiINiFzkPGOcfi/dLtulgIyXCKMGt2p/CjOmm2?=
 =?us-ascii?Q?PoW4wSszQkcoHWvAoMhXFRQf2ZGynSzz22oGrjzDQ5y4K5TVM/5WDSQg54vr?=
 =?us-ascii?Q?mgyqjR/KfA4J6NdJ/giSV1C6auWEpnIv3FpRqFtE+jQGcum3vEhGvDMtSCer?=
 =?us-ascii?Q?3Xeo8jl1tbMNiXQlMTpxSRQkerOjL0XlwdsxwKsR+9eD0AQVz1z9TTE1KRI1?=
 =?us-ascii?Q?oyMJPtcfQIpIUPVCO5mcba5YvdHYXG0y7rTjUfT/4zK7lEf9CVBeeUKgOmqV?=
 =?us-ascii?Q?KnNesUfY+H0qL8WvE7mmL/EiPI0pwGj5y7ns/nneIfVerRRw3BME9hN0T+yl?=
 =?us-ascii?Q?PBBo4wVIJ6A+pMfWclKnwpDflV0wU2WCOOo14qKeR2jVK7s5/2htTKmegSxt?=
 =?us-ascii?Q?Q5gMbdezbOCKMKOgM1dgiH0PFO+6YIAgwlZU5DNrLHtjIg1jbIOzYKOiAW+8?=
 =?us-ascii?Q?ntp4+65GFtb2cS9U5R+8/U2m3beptVV7h77vGcsaDiTcclL7SCMutwCr7Zpf?=
 =?us-ascii?Q?fnQRAe5jm/m3eK0M6zbWEqrH3G1RfJ36DMy/DN72PiDB9aM+ie7gquVlXW3/?=
 =?us-ascii?Q?3DaQXQkb9EOjX1CD4oFdeOLFZCIUvoghGp+kCaPlBd+Oxu4wuGh+NgavUQqv?=
 =?us-ascii?Q?19667XbfkzvlFCU=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <69C09579A1433D4FA10EAEFC781653FA@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB8746
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF0000B61E.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	7087ad02-9ede-44d6-42ab-08dd985f5038
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|14060799003|36860700013|376014|35042699022|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?r7ddajqGLD5/ujZprCsu57pKyWz4pGj3JqIKR6BaLecqsbIlht3oNNjvpENP?=
 =?us-ascii?Q?9dZtBWZ0O1N2FsAm41Xckq/pOQl27Cy1aOS+SkucECO/zxmveaXOnF/LmQRH?=
 =?us-ascii?Q?utTqdBXSkiI+3g19to5gs6rv0DwS4hQHon1AnjwiWSUX2E7tsZ7Mhk5F3yrY?=
 =?us-ascii?Q?ZWtTiTs99o8Rat/rThUR+Rz8DV3zEM1Jd3ewv1DJ5/22gd+t6R5Q42GH3sKW?=
 =?us-ascii?Q?gBHa77h1zGj9cWtu6Vp/S631a1nNE87HcIj0fFFTjo5YJiXoddVV//TTLg3L?=
 =?us-ascii?Q?qSyRz23oDBjj7e262C0YJXc6Kk2Xk2JxzUZ5XhBsQ9LiCKLgioUZyw9GCZRU?=
 =?us-ascii?Q?vy36myF9kowwJhYDNwWQ+NyCKwSZc2yGX9zGg28zmMIrqLuOcaWGDDSpPLRY?=
 =?us-ascii?Q?diP77rXvCQHzvreu84b2sDlHz99a3wZOQGA+p6HDE+Dzi+CMIMSLwAMLbVga?=
 =?us-ascii?Q?VrSw/JRBOAihh51x0mT8WEcLkmJkl6BHsor/lcyoBrPh7/Obf4vMyb4MPTlp?=
 =?us-ascii?Q?wu4D388jg1Ya3PUx9Cq4Rmd9lYAwz9bVCg750lEboXSnjQLdeGMDJapZHmV2?=
 =?us-ascii?Q?Ph02Q9vWPFms/W/gPPYH22l9L1AeXHgvS/PCflRddpm9I02u+D6rDrnb7ZVj?=
 =?us-ascii?Q?p1DzQRS1eSatc8bSH0mKaapZKGbk68z4or2qloUgnAyF5t93qCxhdOXi6ejm?=
 =?us-ascii?Q?OlyeHbsDkudue4YYlc/ZzDS4t4h5wXjbtSYH24hOoIIpLYxGiQT4i+FK6xqg?=
 =?us-ascii?Q?zpoN4eopCqXO0e9AHhaUYUlRNr/ylR7UuS4WAE5nSS/0oxdanNe6kZeJxx4g?=
 =?us-ascii?Q?AhwF/XdAf4BBMHFt9I7BFuRiX2YM4gT5/GdnxSQtDg4QXjS5UwBBtB2kU926?=
 =?us-ascii?Q?8PbHr9YCI2T8QwgD40IeaeCGOFoV2cTukbFdrbzdu/6493FAGcBKyt+QkKUJ?=
 =?us-ascii?Q?thnMgrJsA0yEhfsEo6xrTiEizRZMNz95PxaePg5hx+x8tY8cLdCFazUFqwpR?=
 =?us-ascii?Q?rs38qD/w7g+AXiUYouLcru6XErijP4wuuOKpcF/DfdTxxisJ8P5snhGznSI3?=
 =?us-ascii?Q?y5HSzIOYgWfd0P7eel3YCrybAaYNN/bsVhcvc+yjL+/by//fW2O/8mroh6FE?=
 =?us-ascii?Q?fgywOhH01HDA0JdWicDAseLgdutLz/hrUXpmtn4UsX0HwYa5TXfrBqvsM3CF?=
 =?us-ascii?Q?yxpvvFxpbNSp0daCM/LwEZoPoXtQPMzBmnK2GZNzF52ZoBu8Q9dgEE6vzDrx?=
 =?us-ascii?Q?fBy+5XOByU0FSergC/IboPkIBJcfUxNwR8xpSdLWt6wFUk4NihdZoAe4RKF8?=
 =?us-ascii?Q?djwcbj4B1xFcLWicP9RiOt5PiPlzn7piDX2d3lqz5S4xdGUJ8ntTbJbfUcdz?=
 =?us-ascii?Q?ruc68w35m082xVp9q0thnxu0s5UVoJwVxovPjJSxmzwLfWtXh7H1pLoY48x+?=
 =?us-ascii?Q?wpqEplfTnjyguZq4yE9lGg7KAeyN3zZfCN26S426rxlnI4AGbcpbUkvsfZsj?=
 =?us-ascii?Q?CiC4LazrCKqlgOrP2K5wyCnZfCMaNYUhxyQ3?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(14060799003)(36860700013)(376014)(35042699022)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2025 12:02:43.1726
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ba22844-57e6-4726-40d6-08dd985f648e
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:
	DU6PEPF0000B61E.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB5972

Hi Ayan,

> On 9 May 2025, at 13:24, Ayan Kumar Halder  wr=
ote:
>=20
> Define the requirements which are common for all the commands for XEN_VER=
SION
> hypercall.
>=20
> Signed-off-by: Ayan Kumar Halder 
> ---
> Changes from -
>=20
> v1 - 1. Fixed `XenProd~version_hyp_ret_val~1` requirement as Xen does not=
 return
> 0 for success in all the cases.
> 2. Reworded the requirements so as to write them from Xen's perspective (=
not
> domain's perspective).
>=20
> v2 - 1. Specified the register details.
> 2. Specified the type of buffer.=20
>=20
> .../fusa/reqs/design-reqs/arm64/hypercall.rst | 58 +++++++++++++++++++
> docs/fusa/reqs/index.rst                      |  2 +
> docs/fusa/reqs/market-reqs/reqs.rst           | 16 +++++
> .../reqs/product-reqs/version_hypercall.rst   | 43 ++++++++++++++
> 4 files changed, 119 insertions(+)
> create mode 100644 docs/fusa/reqs/design-reqs/arm64/hypercall.rst
> create mode 100644 docs/fusa/reqs/product-reqs/version_hypercall.rst
>=20
> diff --git a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst b/docs/fusa/r=
eqs/design-reqs/arm64/hypercall.rst
> new file mode 100644
> index 0000000000..f00b0b00f9
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
> @@ -0,0 +1,58 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Hypercall
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +Instruction
> +-----------
> +
> +`XenSwdgn~arm64_hyp_instr~1`
> +
> +Description:
> +Xen shall treat domain hypercall exception as hypercall requests.

This really reads weirdly.
Maybe: Xen shall treat domain hvc instruction execution as hypercall reques=
ts.

Then you can add a comment to explain that this is detected through a speci=
fic exception.

Also this is not completely true as hvc is also used in other scenarios:
- PSCI calls
- Firmware calls

So i would put the 0xEA1 value as part of the requirement.

> +
> +Rationale:
> +
> +Comments:
> +Hypercall is one of the communication mechanism between Xen and domains.
> +Domains use hypercalls for various requests to Xen.
> +Domains use 'hvc #0xEA1' instruction to invoke hypercalls.
> +
> +Covers:
> + - `XenProd~version_hyp_first_param~1`
> + - `XenProd~version_hyp_second_param~1`
> +
> +Parameters
> +----------
> +
> +`XenSwdgn~arm64_hyp_param~1`
> +
> +Description:
> +Xen shall use the first five cpu core registers to obtain the arguments =
for
> +domain hypercall requests.

Why not say x0 to x4 registers instead ? You use x16 after anyway

> +
> +Rationale:
> +
> +Comments:
> +Xen shall read the first register for the first argument, second registe=
r for
> +the second argument and so on.
> +
> +Covers:
> + - `XenProd~version_hyp_first_param~1`
> + - `XenProd~version_hyp_second_param~1`
> +
> +Hypercall number
> +----------------
> +
> +`XenSwdgn~arm64_hyp_num~1`
> +
> +Description:
> +Xen shall read x16 to obtain the hypercall number.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_first_param~1`
> + - `XenProd~version_hyp_second_param~1`
> diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
> index 1088a51d52..d8683edce7 100644
> --- a/docs/fusa/reqs/index.rst
> +++ b/docs/fusa/reqs/index.rst
> @@ -10,5 +10,7 @@ Requirements documentation
>    market-reqs/reqs
>    product-reqs/reqs
>    product-reqs/arm64/reqs
> +   product-reqs/version_hypercall
>    design-reqs/arm64/generic-timer
>    design-reqs/arm64/sbsa-uart
> +   design-reqs/arm64/hypercall
> diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-=
reqs/reqs.rst
> index 2d297ecc13..0e29fe5362 100644
> --- a/docs/fusa/reqs/market-reqs/reqs.rst
> +++ b/docs/fusa/reqs/market-reqs/reqs.rst
> @@ -79,3 +79,19 @@ Comments:
>=20
> Needs:
>  - XenProd
> +
> +Version hypercall
> +-----------------
> +
> +`XenMkt~version_hypercall~1`
> +
> +Description:
> +Xen shall provide an interface for the domains to retrieve Xen's version=
, type
> +and compilation information.

I would say hypercall instead of interface here

> +
> +Rationale:
> +
> +Comments:
> +
> +Needs:
> + - XenProd
> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fus=
a/reqs/product-reqs/version_hypercall.rst
> new file mode 100644
> index 0000000000..400d51bbeb
> --- /dev/null
> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> @@ -0,0 +1,43 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Version hypercall
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +
> +First Parameter
> +---------------
> +
> +`XenProd~version_hyp_first_param~1`
> +
> +Description:
> +Xen shall treat the first argument (as an integer) to denote the command=
 number
> +for the hypercall.

I would be more precise and say x0 value.

Also "integer" is unspecified, use a more specific type definition (32/64 b=
it signed/unsigned integer).

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Second Parameter
> +----------------
> +
> +`XenProd~version_hyp_second_param~1`
> +
> +Description:
> +Xen shall treat the second argument as a virtual address (mapped as Norm=
al
> +Inner Write-Back Outer Write-Back Inner-Shareable) to buffer in domain's
> +memory.

You should say "guest virtual address" to be more precise.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> --=20
> 2.25.1
>=20

Cheers
Bertrand



From xen-devel-bounces@lists.xenproject.org Wed May 21 12:10:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 12:10:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991756.1375577 (Exim 4.92)
	(envelope-from )
	id 1uHiHX-0006Co-OQ; Wed, 21 May 2025 12:10:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991756.1375577; Wed, 21 May 2025 12:10: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 1uHiHX-0006Ch-LF; Wed, 21 May 2025 12:10:47 +0000
Received: by outflank-mailman (input) for mailman id 991756;
 Wed, 21 May 2025 12:10:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHiHV-0006Cb-EP
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 12:10:45 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20622.outbound.protection.outlook.com
 [2a01:111:f403:2613::622])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9ee0579d-363c-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 14:10:44 +0200 (CEST)
Received: from AS4P195CA0008.EURP195.PROD.OUTLOOK.COM (2603:10a6:20b:5e2::13)
 by PAVPR08MB9457.eurprd08.prod.outlook.com (2603:10a6:102:319::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Wed, 21 May
 2025 12:10:41 +0000
Received: from AMS0EPF000001AF.eurprd05.prod.outlook.com
 (2603:10a6:20b:5e2:cafe::57) by AS4P195CA0008.outlook.office365.com
 (2603:10a6:20b:5e2::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Wed,
 21 May 2025 12:10:41 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF000001AF.mail.protection.outlook.com (10.167.16.155) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Wed, 21 May 2025 12:10:39 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS8PR08MB9867.eurprd08.prod.outlook.com (2603:10a6:20b:5ab::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Wed, 21 May
 2025 12:10:06 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%3]) with mapi id 15.20.8699.022; Wed, 21 May 2025
 12:10: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" 
X-Inumbo-ID: 9ee0579d-363c-11f0-a2fa-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=Vp59a7G8ekOFvVgkBY1V4SbUTKPhjqdXNGb/Z6LJ3CLGxJPQL4Xyg47/5xOEnvadYyaspzYMWhkyyjoaM14QCDHB52cN8o7LcIx0Q89QsUDdPXsr0ahCyeF7EsUYIi8v2GbZTzodnkWe9DUvltxztQzeiDf5rO2q1kZKGAHlUmTgwzGptN5eMtgiU+A4xC2zRlrVpH15XD88zORUjCtLI6NJ7mMyPDcmKm+0IpdQ7ReAGxOOljzTw9cX1dOjoGlDNr6QAqve/n+m2M550yzZ6VlZ1EhnAYjdemg853BrDCphQA436HgiK80t/5+9D6VoEeCr7p8tSI5Pu3AUIl4J4A==
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=KcSkkmGT7b+3fviiu8CoKuciKMK1pXA3TW8fB0LM+Mk=;
 b=Cyw1lM7VasPTINXgJaWqSPwbGxSabgF3KcQwQuDwYLVIjAJbQzlFu8wicANz72vNAJllzbnh7k+D+F4nB455H8ofT3kwTjUcwjNktzdHSd5YsdtNRMuc4R0YZO4/nVzUDsZhzWzb8h5myRNm8/jfxyFw1MZUPpCrYJHCekb2iWPi4nURS9pYN+PCPTy6aOofj6aJITfCUHUXoWS7qTB205u/OQo0C4/3p61uotwxUsmIqQfZUSF2bS+hFMHcS4nHFjqyHG8L0CzFRcvlC3zoaP0RXUu6HHWcjhE8jAYa0MUf6q263ykC1ku7ZfY4Sbo7cq6XUx0OVc8Vj31DDpFUog==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.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=KcSkkmGT7b+3fviiu8CoKuciKMK1pXA3TW8fB0LM+Mk=;
 b=hRM41e4SH4tbXi3jWc48xw+q/kgrJxpIePKW0wMrg3313lbrAs/4hFBPrxawrCGW/mUfoUCN3lS94635axYtxRCNKjtT5KjBF/Km9ol2TZD67DHMiAO9IR916xf5Qf4NFqmcX+ga6sjKjiiYIZYKEkuHOG+wQ328qBWla9x5dS4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qRm/syPETxHaT3PzZN9GQ2/nN0+7kSplvERyd9NxMpeXakToGz7CiLsFw/NseLVPHuhvMuWMZJxl1iz6cgRAdIkbdu9H+rIJttjC0FO3l8v04leemqxntD2ZebnILtCVzsN4KpsHMJnwrAYK5VK2Yx2vlCEPr2bq4/X2uMymaXLlEtIrJ4ig7CIEmZmTZFXN6rxMW5TrqDWPG6+jtG/ZJd3iEmV0XdHK3B0NiXvggO7lmvkBzMX0AvDWeoNrcoGNeJxLc9Uuv0NlA+GyMBeFxBgm65JuXe9zLXSBFEavXzAbwdNN+kkRDrjLKwGFLy3SnIgXy64ywymlFPZEl0qsaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KcSkkmGT7b+3fviiu8CoKuciKMK1pXA3TW8fB0LM+Mk=;
 b=F1PU7J83vES3q+VIg/1gryK+9z2zCLbXnpZdK9yoczwVQQxGHD+42BxjGiMdne3FVnVYZf1z3dg7NsJW9wnbiYkecjQS7d59421kx1n5FM/+R2vfQskApEGlx1H9y33KV3vHAZgDIg9rg2IRfiywuq56w0/ILiuUMmEOl9mvtseCD/cg1IAg8eY4qYGdGpGxGO4VZrhvdQGVdDDXOLzqrsvS3cwo01phjMfkix8QP/tLMvzKe0fG57+uRRSj40vluJJnQVspSD+kAdcKseCaxlLYXrJS7ZOwQu4Dz2g7pX8Vxa3jGK6oUztLur/KkjM1Uv8kbBTfcQaskEnEW2Qmyw==
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=KcSkkmGT7b+3fviiu8CoKuciKMK1pXA3TW8fB0LM+Mk=;
 b=hRM41e4SH4tbXi3jWc48xw+q/kgrJxpIePKW0wMrg3313lbrAs/4hFBPrxawrCGW/mUfoUCN3lS94635axYtxRCNKjtT5KjBF/Km9ol2TZD67DHMiAO9IR916xf5Qf4NFqmcX+ga6sjKjiiYIZYKEkuHOG+wQ328qBWla9x5dS4=
From: Bertrand Marquis 
To: Ayan Kumar Halder 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Michal Orzel ,
	Artem Mygaiev 
Subject: Re: [PATCH v3 2/2] docs: fusa: Add the requirements for few commands
 of XEN_VERSION
Thread-Topic: [PATCH v3 2/2] docs: fusa: Add the requirements for few commands
 of XEN_VERSION
Thread-Index: AQHbwNT/t0poWSgC+UCvRirhbzGp97PdENyA
Date: Wed, 21 May 2025 12:10:06 +0000
Message-ID: 
References: <20250509112447.2931909-1-ayan.kumar.halder@amd.com>
 <20250509112447.2931909-2-ayan.kumar.halder@amd.com>
In-Reply-To: <20250509112447.2931909-2-ayan.kumar.halder@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|AS8PR08MB9867:EE_|AMS0EPF000001AF:EE_|PAVPR08MB9457:EE_
X-MS-Office365-Filtering-Correlation-Id: bca68ee4-4609-4c98-6ae5-08dd98608038
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|376014|1800799024|366016|38070700018|13003099007;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?4Qf7nOFN5mTJnfGEJmjOhMeyAlXjkU5CxuKUiYjNpINaITBMoXAFMqO8JI/G?=
 =?us-ascii?Q?OwYwONnbyWX0KQTBuYet5MPgMgHgTsfh7l6q7diGQQAvd+1EWNK0mHrwM5kl?=
 =?us-ascii?Q?A3AHVamyb7R5k0am6gux2B1aJuvn1bVxelLsqIka9WU9VDPQmt6gczSHv7kZ?=
 =?us-ascii?Q?jLJxv27wGZLR4PSVOq+h/wOE3N5iKbSL5Duh67XejAXx444Q9Y0KbBnnZWA9?=
 =?us-ascii?Q?ziAnG9Wzoum+HPg3Ydg8rQAFAfUWmCoHjogfeHlP6HxX0GRXKc7Fa22j6K18?=
 =?us-ascii?Q?Bohcx7m8DBqqhZ6F1xI4GGBesJtrlbDDCrHSQA9Esphqv8nIK3oRnUFyT0Rl?=
 =?us-ascii?Q?mPJ5/owqa7MJQGQFHeob4+bD8MNy/X/G13BFa5ygXna2GyTGlMFraoL83cik?=
 =?us-ascii?Q?XSmBrEETZ81jvQpZUih8dy8xF4n/W8OLHu9q1bzdQn3piK8ZC+zMwGMZ/A6u?=
 =?us-ascii?Q?uBQkFAiAXttjIstThAvlhs15exrZ5m6DEX4YVXg0D2sLGTD5RUmICcASwi5k?=
 =?us-ascii?Q?1xpvKkstq02oyQ99iJMVsi50xrmCrhibeTLXU9ebKvF+79RtbWNBM02PhUrd?=
 =?us-ascii?Q?xMc1tSFizpr6LU5v05vAVv9+9DmMmKf0TjEuGc23ocr3w03kn2H+IfncqpkA?=
 =?us-ascii?Q?z7f+TT5lw9E6LPZDlCbHl/q2c441vxZLGsNIEu/m6rDjM7zenbWbQYTq8A9a?=
 =?us-ascii?Q?wPM3kK62sQqXDhVvs9+5k2xH6yfB601sCPXLnH7UpTkRZFQ8W2iDJFNKocFf?=
 =?us-ascii?Q?B74k+NXn+oAwGpGB9vFfm5wUpbhP2LUCLylF5QFrYy9BaEBue/2ZYyYE4+W3?=
 =?us-ascii?Q?JQc0EBjGX2gYBk99tEXl9rPW6taINsCvv02Twa87KrfXSTLlmbWEVrW+7th0?=
 =?us-ascii?Q?8O1q5UvMfQKJOGPBW+f2IXD6FWERLlF7n1E72u1Adjh9VwtPWHkfnsld5lV/?=
 =?us-ascii?Q?2/GVhgAjtLCI4BJ6eYpj/kmhGsftFyjMy4PVwl25261MRngkE8cVstLNRmtp?=
 =?us-ascii?Q?gzHGmsR5mWdMHMmdQe26LROIEmG/E/SoESYuSDNgwcBnLGFTjaRLQ8taAAJ2?=
 =?us-ascii?Q?1Fdy90WqkHKl2DUPc0e5AmdKRsWBv8cx6QR3hirD6aS9/FcvHHDI6es9ttDH?=
 =?us-ascii?Q?YzjNjYgMhu5/s65cmc6Xs6C/6l9KZi3xyRE4KHIwgeupqK2b4chEnbxQmDhu?=
 =?us-ascii?Q?m7xHB8zM2SooBQxYqdRs+x4oFnZc6BHGjTm6eBANBm+JhLt8HPgWUqqwyxXD?=
 =?us-ascii?Q?4V1jbBqYeYUAPY2ppfF4Sa7bxY4apAz3OH4SpjGT4AuDqsBtp6oi4dD1ny8n?=
 =?us-ascii?Q?YFNKsb3UzrhwUTe+qYtd2IaZM0fTFtNSh396SPV2AyIbC6SgPBls5F538bR9?=
 =?us-ascii?Q?5eZ+wR4x78W33t8ZEDrVcdNMBUf3hmwFWh9zOYaSpM3PtLu7zINL8ljp8d10?=
 =?us-ascii?Q?aMzxCdriUxs=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018)(13003099007);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8268D9E54BD8174DA0701A37BD4345B5@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9867
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF000001AF.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	d9fd7c93-1005-4914-f33e-08dd98606c8f
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|14060799003|376014|82310400026|35042699022|7053199007|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?jE3sENhPvSrQGYwjNugYf16QnPiVmQC9rvM1FshUiNGaQcForCKNrxfxyXTL?=
 =?us-ascii?Q?K1Ig/xqE1SoNf3IyabF4joG5jJeS8Xeb1+aMxg+McOeIKq6i4M47phLBKnB+?=
 =?us-ascii?Q?Ylr1Eg4WomhmlB7L0ZR2uMi6+VvSD1ECDZBzkA/1mDe79CQ6yYiYizrF6NNa?=
 =?us-ascii?Q?JYXYjz26sHZPBPGwrjB+LE4jN/LzWq7o5AqGuU3BDYQgkJu9sjgkyyD7p/ue?=
 =?us-ascii?Q?OToQ3B5SkuyTLpA720FuiPNQAkn0AN3runv9/H6EZ+sA+cez65PSsHbnyeHa?=
 =?us-ascii?Q?oXqFVVIEaryTWDadQdXdE2LcvQuBvBv9MWAL/kV/xsa2p3HsoPp+S3EvUqwq?=
 =?us-ascii?Q?1AJyyZ6kjRxgITAXo7Ieh55BCkM8l53NXmtkhf+prz358odHFqivxOIMJUif?=
 =?us-ascii?Q?zo2DoiTRMEQpITBJYMFBffyOV/Fj3oGq3TtuT3zIFPI+MO2e/jqzMi0obYcV?=
 =?us-ascii?Q?flaXr5vW+pyOf0iuAuOVSDbIvrS+FQbAznpIMzHkiwZ0p5qvM+2YZyTHS4Wa?=
 =?us-ascii?Q?FoN1oEXvPpKWQGN/S9FI7CURNnjqG5HQTJ8b1GI59p40nV0TkifnYvrNFNJR?=
 =?us-ascii?Q?g2oYTHkxRbUQDeT87oxg4BEHG8lMgjciqbPyfEO1KgSiRlq7OO+SRVPwWbmj?=
 =?us-ascii?Q?VHWdCtt7jwCn4ca6YWQUkdA8aduIb6fth6bQ1RLVqHbibqm1ZZB2OuVmi1iN?=
 =?us-ascii?Q?fltPdUtoC+npSMqS2wU68hCyl01knE7ktzwi/xO+EqCUp10JxaFKkn4v9bEc?=
 =?us-ascii?Q?0SbmOrt1imjA2AFnXN34GvD+AqAhgdb91nBWUU/ae3e9w3euhlTM3o5gDFj6?=
 =?us-ascii?Q?8449gZPsPxRYnHgEmDrkHcWozcpfe8lZAmrWeUrWRXZ11kbRVWw/vfpuEgDT?=
 =?us-ascii?Q?/+0a6gFV/ymtd1w8tjVMH0whhVlsY0gIEZCquS91om12DPIUfeYoYBi9Oxvi?=
 =?us-ascii?Q?kyfwfdg7Mhu4QT9XbZvbgXx/9/9aS2X7tXQRiFFW8LRy/x7uVCuSBi56VY1F?=
 =?us-ascii?Q?mZ3PzWynLbKrZY/gCji8/YFMi80D7/b1mRRNX7k2Lh3jYEHZyqowaUdscCyH?=
 =?us-ascii?Q?/3sLa1EArDosqYDD5vmj8E1wgtReJ7jKh/97LAKI/nHvBegvfaf8zpwiI1cL?=
 =?us-ascii?Q?fVjsj5pZZkfWP8uOpwHDOnKXaZHmeb1wIhY4k4bSmZLrx1IV6Lbr1dNB0kDE?=
 =?us-ascii?Q?0f62kxyyiGHr/EtxpQg68tRiwj1rJ7RD+TX2NDO2ldsQNChB12/0W7R59WkX?=
 =?us-ascii?Q?ZsqRal2ncnkQMY3t6SzN+koXozpT027YPIV7NNsDFqoH+2MRnAJEA1OzWfB5?=
 =?us-ascii?Q?PhBBGvFwoZf82ZKg/MdWCjWg7cPoPqNROWESPRu4NeIezZR8NGbu5ZnL0hGM?=
 =?us-ascii?Q?FWf5EONSqHuujkgYJt4YaqjSop6jdC5aUMRsI/UYolemOc5qGg4UduGYVN+W?=
 =?us-ascii?Q?yqGbnKiAlelL7JMUcg15RtR+r9wtDhHYt3IO/wSIAUqT6mY+H7fhbA=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(14060799003)(376014)(82310400026)(35042699022)(7053199007)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2025 12:10:39.0975
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bca68ee4-4609-4c98-6ae5-08dd98608038
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:
	AMS0EPF000001AF.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9457

Hi Ayan,

> On 9 May 2025, at 13:24, Ayan Kumar Halder  wr=
ote:
>=20
> Define requirements for specific commands.
>=20
> Signed-off-by: Ayan Kumar Halder 
> ---
> Changes from -
>=20
> v1 - 1. Reworded the requirement so as to avoid mentioining variable name=
s
> or hardcoded strings. Otherwise, one would need to change the requirement
> each time the code changes.
>=20
> v2 - 1. Moved few changes to previous patch.
>=20
> .../fusa/reqs/design-reqs/arm64/hypercall.rst | 15 ++++
> .../design-reqs/arm64/version_hypercall.rst   | 34 ++++++++
> .../reqs/design-reqs/version_hypercall.rst    | 82 ++++++++++++++++++
> docs/fusa/reqs/index.rst                      |  3 +
> docs/fusa/reqs/product-reqs/hypercall.rst     | 20 +++++
> .../reqs/product-reqs/version_hypercall.rst   | 83 +++++++++++++++++++
> 6 files changed, 237 insertions(+)
> create mode 100644 docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> create mode 100644 docs/fusa/reqs/design-reqs/version_hypercall.rst
> create mode 100644 docs/fusa/reqs/product-reqs/hypercall.rst
>=20
> diff --git a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst b/docs/fusa/r=
eqs/design-reqs/arm64/hypercall.rst
> index f00b0b00f9..f58a9d50aa 100644
> --- a/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
> +++ b/docs/fusa/reqs/design-reqs/arm64/hypercall.rst
> @@ -56,3 +56,18 @@ Comments:
> Covers:
>  - `XenProd~version_hyp_first_param~1`
>  - `XenProd~version_hyp_second_param~1`
> +
> +Return value
> +------------
> +
> +`XenSwdgn~arm64_ret_val~1`
> +
> +Description:
> +Xen shall store the return value in first cpu core register.

use x0 instead.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~hyp_err_ret_val~1`
> diff --git a/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst b/doc=
s/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> new file mode 100644
> index 0000000000..3aa12ea2c2
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/arm64/version_hypercall.rst
> @@ -0,0 +1,34 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Capabilities
> +------------
> +
> +`XenSwdgn~arm64_capabilities~1`
> +
> +Description:
> +Xen shall have an internal constant string to denote that the cpu is run=
ning
> +in arm64 mode.

This is untestable if this is purely internal so this cannot be a requireme=
nt
I am not quite sure why you need this, can you explain ?

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_capabilities_cmd~1`
> +
> +Capabilities AArch32
> +--------------------
> +
> +`XenSwdgn~arm64_capabilities_aarch32~1`
> +
> +Description:
> +Xen shall have a internal constant string to denote that the cpu is runn=
ing in
> +arm32 mode.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_capabilities_cmd~1`
> +
> diff --git a/docs/fusa/reqs/design-reqs/version_hypercall.rst b/docs/fusa=
/reqs/design-reqs/version_hypercall.rst
> new file mode 100644
> index 0000000000..aac5896965
> --- /dev/null
> +++ b/docs/fusa/reqs/design-reqs/version_hypercall.rst
> @@ -0,0 +1,82 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Version
> +-------
> +
> +`XenSwdgn~version~1`
> +
> +Description:
> +Xen shall have a internal constant (XEN_VERSION) storing the version num=
ber
> +coming from the Makefile.

I really have doubts about this and the following one.

If this only goal is to say what should be returned in the XEN_VERSION hypc=
all you might
just need something saying it and mention this as a comment because you wil=
l have a very
hard time to test such a requirement.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_version_cmd~1`
> +
> +Subversion
> +----------
> +
> +`XenSwdgn~subversion~1`
> +
> +Description:
> +Xen shall have a internal constant (XEN_SUBVERSION) storing the sub vers=
ion
> +number coming from the Makefile.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_version_cmd~1`
> +
> +Error copying buffer
> +--------------------
> +
> +`XenSwdgn~error_copy_buffer~1`
> +
> +Description:
> +Xen shall return -EFAULT if it is not able to copy data to domain's buff=
er.
> +
> +Rationale:
> +-EFAULT is one of the error code defined in
> +http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dxen/include/publ=
ic/errno.h.
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~hyp_err_ret_val~1`
> +
> +Extraversion
> +------------
> +
> +`XenSwdgn~extraversion~1`
> +
> +Description:
> +Xen shall have a internal constant (XEN_EXTRAVERSION) storing the extrav=
ersion
> +coming from the build environment.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_extraversion_cmd~1`
> +
> +Changeset
> +---------
> +
> +`XenSwdgn~changeset~1`
> +
> +Description:
> +Xen shall have a internal constant string (XEN_CHANGESET) storing the da=
te,
> +time and git hash of the last change made to Xen's codebase.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenProd~version_hyp_changeset_cmd~1`
> diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
> index d8683edce7..de19b0cda2 100644
> --- a/docs/fusa/reqs/index.rst
> +++ b/docs/fusa/reqs/index.rst
> @@ -11,6 +11,9 @@ Requirements documentation
>    product-reqs/reqs
>    product-reqs/arm64/reqs
>    product-reqs/version_hypercall
> +   product-reqs/hypercall
>    design-reqs/arm64/generic-timer
>    design-reqs/arm64/sbsa-uart
>    design-reqs/arm64/hypercall
> +   design-reqs/arm64/version_hypercall
> +   design-reqs/version_hypercall
> diff --git a/docs/fusa/reqs/product-reqs/hypercall.rst b/docs/fusa/reqs/p=
roduct-reqs/hypercall.rst
> new file mode 100644
> index 0000000000..b57b9acde8
> --- /dev/null
> +++ b/docs/fusa/reqs/product-reqs/hypercall.rst
> @@ -0,0 +1,20 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Error Return Value
> +------------------
> +
> +`XenProd~hyp_err_ret_val~1`
> +
> +Description:
> +In case the hypercall fails, Xen shall return one of the error codes def=
ined
> +in http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dxen/include/p=
ublic/errno.h.

s/the/an/ hypercall otherwise it is not quite clear which hypercall you mea=
n.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst b/docs/fus=
a/reqs/product-reqs/version_hypercall.rst
> index 400d51bbeb..2ef1c4f9ca 100644
> --- a/docs/fusa/reqs/product-reqs/version_hypercall.rst
> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> @@ -41,3 +41,86 @@ Covers:
>=20
> Needs:
>  - XenSwdgn
> +
> +Version command
> +---------------
> +
> +`XenProd~version_hyp_version_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 0) for  hypercall (num 17) to retrieve =
Xen's
> +version in the domain's register 0.
> +
> +Rationale:
> +
> +Comments:
> +Xen version is composed of major and minor number.

How Xen version is encoded should be a requirement, you can add this direct=
ly into
the definition of this one in fact i think.

> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Extraversion command
> +--------------------
> +
> +`XenProd~version_hyp_extraversion_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 1) for hypercall (num 17) to copy its
> +extraversion in the domain's buffer.
> +
> +Rationale:
> +
> +Comments:
> +Xen's extra version consists of a string passed with 'XEN_VENDORVERSION'=
 command
> +line parameter while building Xen.
> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Capabilities command
> +--------------------
> +
> +`XenProd~version_hyp_capabilities_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 3) for hypercall (num 17) to copy its
> +capabilities to the domain's buffer.
> +
> +Rationale:
> +
> +Comments:
> +Capabilities related information is represented by char[1024].
> +For Arm64, the capabilities should contain "xen-3.0-aarch64" string.

Isn't it mandatory for xen to return aarch64 for arm64 ?
This could be turned into a requirement (easily testable).

> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Changeset command
> +-----------------
> +
> +`XenProd~version_hyp_changeset_cmd~1`
> +
> +Description:
> +Xen shall provide a command (num 4) for hypercall (num 17) to copy chang=
eset
> +to the domain's buffer.
> +
> +Rationale:
> +
> +Comments:
> +Changeset is string denoting the date, time and git hash of the last cha=
nge
> +made to Xen's codebase.

Does this has a standard format ? if so it should be explained.

> +
> +Covers:
> + - `XenMkt~version_hypercall~1`
> +
> +Needs:
> + - XenSwdgn
> --=20
> 2.25.1
>=20

Cheers
Bertrand




From xen-devel-bounces@lists.xenproject.org Wed May 21 12:21:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 12:21:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991776.1375611 (Exim 4.92)
	(envelope-from )
	id 1uHiS7-0000GD-JD; Wed, 21 May 2025 12:21:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991776.1375611; Wed, 21 May 2025 12:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHiS7-0000FV-F1; Wed, 21 May 2025 12:21:43 +0000
Received: by outflank-mailman (input) for mailman id 991776;
 Wed, 21 May 2025 12:21:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHiS6-0008Qd-1R
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 12:21:42 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2606::60c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 265b73e8-363e-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 14:21:40 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PAWPR03MB9644.eurprd03.prod.outlook.com
 (2603:10a6:102:2e3::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Wed, 21 May
 2025 12:21:33 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8746.030; Wed, 21 May 2025
 12:21: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" 
X-Inumbo-ID: 265b73e8-363e-11f0-a2fa-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YZuVpWrXEKUdgwkBfCWgY8RBkCx7A0PtzKhSSttEmJW5vO0AhXFa4ERO/N9tzighvO+E/qCdvr25Hd44+1pTz2vip+/0UdYYXG+nIzvfgzpau8EUB1jaq2r5hwyT1H2pAUP/eWNpiyO58DhBts3cHL5y4dqJeJ0POvDIeEwpfVLSaZSfmYKw95Xz4L2ztku8qXxCa5S0J064U8XDNHnXmJKmiug0Uy7WSyq3c1z3GT3L+3aNLzLd+T13aYyu5otYmQG+W/jmODLo2zuXK6N8BlsAHxIv2N7t63Pt5mK7EJk0wWsbG4vCGiZ6EHpyhWBzJvyd9024TT/bNnSl97PX2g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cpZsBbj7D3pf+dpvbBxlCm4AJ6L7tIyDoTO9zE1yQnQ=;
 b=PVLcFt2H+Ib+LtrInNRZd415DTvSamtq+aL8U7AVuw3jaQE4qixN8VEB1zBBz6j8dF82d1nOwsPkikUyJdlzLB9oFloOVKvVzUX44Xf2hMtrUs2TajUqrXjpFHjEt0wGFhFTcU+ZotSjFCanZE9tNo8rLmjQX0VErM6zXK2vwc7N0E3gqCPH9W6aaUwELxP+aG7o9uNB7acRtqvpFy3Jc6hztIfKA9VCcPaZiAtHR4GV0/vI8RBDBkuW4LYAS+36DoSqHkekFTXqHtmCc/1doNUSaBJTzxKu7crQwmxtwSJyDd6J2Gknlv88kMwwL/f4u/+SAivs1sgYa0sbkmTJ8w==
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=cpZsBbj7D3pf+dpvbBxlCm4AJ6L7tIyDoTO9zE1yQnQ=;
 b=jzZ+e5qco2zKkdvaIZi++LbD0h+eSc6MH6d0zdeXzxOW3HDcJaSYhbB6PbzZxfpk3rAzpO7ypeTd7OG3cN4kBi11c2Ljac7tcai2CUPMSW6cbar6t0O5dkE/Z6Llw2drDdt+QNIDlD4ixf84LG76cAptFCiAp8eD56/4mNttPEvsaVVJKjVdw7RYLC+CMYfHuEM2V+sVGXYAHXfZ45FeNA+chBBdefyYXqKke/7RENLqFUyJRA/+72g9u5iLM8GP8jjpTluugXqFF2h7ZwLz0y9mtZlMfJvEkV7ZQKRP5qUfCAJjmZ0kRsV15u8xggP1/x093ZFIK8RHlCgOLZHxDg==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , Julien
 Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Stefano Stabellini , Bertrand
 Marquis , Volodymyr Babchuk
	, Mykyta Poturai 
Subject: [PATCH v5 4/4] xen/arm: add support for R-Car Gen4 PCI host
 controller
Thread-Topic: [PATCH v5 4/4] xen/arm: add support for R-Car Gen4 PCI host
 controller
Thread-Index: AQHbykrjmOX6JVLEJUWwTM6YRoyEQQ==
Date: Wed, 21 May 2025 12:21:33 +0000
Message-ID:
 <06f5972dda6a8132be8eab5ad1b8586ff3c5aaf3.1747820844.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: 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_|PAWPR03MB9644:EE_
x-ms-office365-filtering-correlation-id: a96de8b4-4f33-4aa8-ff99-08dd98620627
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?E6AYpxJC4tCe+lEK1eyvKu+Gf3pF4BGUMRNDlwpAwG2+TXTWr7pHlfHOdm?=
 =?iso-8859-1?Q?YdyBNiNTYpknSP34dXrFRM5BBsdFZy6AV01AMWs4kQ9XM9BRav1qOZL+6i?=
 =?iso-8859-1?Q?hjYpShMkSffuhJQ15zYY1Ivq8kRJndszfA9+eSD3mpWmf/3nW6VRcCngst?=
 =?iso-8859-1?Q?qMvaq4zCY2NogL4LLNhQEQr8h3aiAXDnePfxUpSJWGmGYa1vukyd2rFJ3y?=
 =?iso-8859-1?Q?UNsrwhIDRgzR0ysFyFn4EoUYyrRw4gVoU1HXDnxbBp8dvoEZzo1+k8BUbV?=
 =?iso-8859-1?Q?X8hVmwEG5cNFXQDnPZll9iUPT+ddKufP++QtFjNSxbDZ+OGJipE1PtqCe9?=
 =?iso-8859-1?Q?tiM7yszxaW2hIv1FUVx5LNF23eDhdF0TX2Jb50UHd4iiKjpmjwJlk5L685?=
 =?iso-8859-1?Q?kgbKnuz3qbk0izVrqdJVBbPLyDWl8fRPfETMKSuXV5unM2oOE2KHcCM6L7?=
 =?iso-8859-1?Q?apnLgDZbxyqIpLrgJb+yQUKAUD5BbLyNpgwJhXBMmAJkGyKpWVuQrPXUrt?=
 =?iso-8859-1?Q?Aj9C89Avc+hidgiBk4tkhFCF58anrQPq90pWUvUbRRXyNB09xxmU4Cf1cQ?=
 =?iso-8859-1?Q?5VEHf1GQXEwIPMcvtkzfAL3CYP8MC8nh4QQ00I8kMUbvsi04SS57femCkC?=
 =?iso-8859-1?Q?pHpAjPnLLEBRQtivDL8VJyY2SE5W1FV29uRWinql2jAuqzFGfxT4ID37Sm?=
 =?iso-8859-1?Q?eXQzR2TEajM3sAMhbwHZ4J35hrHa+bV1OZzHmMJ1N9V5c6MfsKq4P5oGhu?=
 =?iso-8859-1?Q?R8vTsNWdk8CowiYeY7W2f6EqoEEI63evPMCPykcWvwplAy5I/FiVf/oFm8?=
 =?iso-8859-1?Q?Y3/2yF2jhcN3loHwR6gtlympVEPjOQKxU3hbw/I6uBN59PPWsiRYTC8VMw?=
 =?iso-8859-1?Q?PewymC+j28wBzomza2j971piQzixGH2RJ62C110gXApJgHYrIpw7Tq2pnT?=
 =?iso-8859-1?Q?7aK2WcDVaca9HeNVyPA1wyxHx+NYML0+Q959bQTV3jVAjwd23rqA1519O9?=
 =?iso-8859-1?Q?7FysZlrEnVGoaAz7/ekJ1bC9R9r4fy/Srldpgim1wKYH4wS7VeldtmOwXv?=
 =?iso-8859-1?Q?em7zIBzvM8b8ur+es4PBy3/ascv2z1dP49kpEcSjIu/v6AnzJ8HqD/oY4R?=
 =?iso-8859-1?Q?qoG2U20HxYtuJ39nSd5+j2E2HQA357McsedcPkF5BH3ReyAQ0R4fZ+dNc4?=
 =?iso-8859-1?Q?dDLcx1z5pNVgna33JKDDabam0KazaHHKVcv20M9Hgcv66NI4RoBE7nqYRu?=
 =?iso-8859-1?Q?DoLT/JPURBpSismU0Fe6xBzjj60PC+sS5gaUlnh7ATiYzMTHMEkdrMFDdu?=
 =?iso-8859-1?Q?Hsn9IDqGikXS3UMGvsW8+lx5P16Ce/3N9kTESd6N8vNJObjcHEQQeiNcdN?=
 =?iso-8859-1?Q?u165sqXUP/qdWtfgkZsT/LipyCEeyb7Aoa+G1TY+8lF70nPhLURGYyxv2V?=
 =?iso-8859-1?Q?5+M4Sm2khapeHYFgKjy85xkgpdAXA0V8xVZr8bdFXEEsx6A8Sg7O8qSunT?=
 =?iso-8859-1?Q?k=3D?=
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)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?d7xfOBKpf62MZCQahFItVyrUoNEwwApUuxFGAIk3z9+YXIPds/tdJTkEVz?=
 =?iso-8859-1?Q?9BekWv7g07V7xTZWrdVHTxkdPXk9B+spTv+wt582fuyJby9gMZmXnq141k?=
 =?iso-8859-1?Q?soxjN4B81owE5RmfdH6aFOCQbP2NXU+ZMoTKbzRyagzCyoU3Slwvdb/6LZ?=
 =?iso-8859-1?Q?uspLFtI1ra3gAVsYNahOBQVzs/6Ssxi79zUl9afLg7ewgDtbH1LPRg774/?=
 =?iso-8859-1?Q?pUz5iUf6j2WY4FpvWEerQ1U4zXih7/xCWOJa57jWZ0Vk/zdQwJXeouatuW?=
 =?iso-8859-1?Q?jQ2mahKEDuRtuGm3VdGdALMCWS4+e3G4EVMFqvLgTGo/k6VvtLzv8cR7Eb?=
 =?iso-8859-1?Q?hq2QmTH6CVuEPFTwDj+z3ZuRg1NayVjwzWRX0q8EtEbBPVN9aMs5wA2yB2?=
 =?iso-8859-1?Q?14t0+httyUvj4ZgD02qk387IyDKcadzxd99tVZx/7BLSu/CgtsZ2cZFhbN?=
 =?iso-8859-1?Q?+zWXWye5+/Bmbe5+H5FTqdOeyPVi8GEVnJ1Rq/jSJ44oBOq3hr/oYk5WVP?=
 =?iso-8859-1?Q?XI6uZt0FlXiFiMYcEeaz8ECkq3hLawk7KdMBOatRns5t/8vqpXHmvQOFpH?=
 =?iso-8859-1?Q?pzv6p9w8gSDiD5g6JZcnk3qek9/Q9o2bQB7envL9xjzPpaG727nhJo0NlU?=
 =?iso-8859-1?Q?N1ZtAUgZ+vsn1SpjgGnJpBn3ONsbRWKPXAJWs32Y7PpKN4ZJ9Jix+OWdWb?=
 =?iso-8859-1?Q?3LsSghfkPK7zwL8gtiuEF+iIKa5+wZhZVoMAl+em3ZxVw5mW3uF1RJPVNi?=
 =?iso-8859-1?Q?5m5sbc7i76XuiJhJp6GRn6OSin+YQrgL1jx5TARh0dDiBDudid4pxHwuG6?=
 =?iso-8859-1?Q?hznugayYHs6LBDShCD6pm5y7di47mn46967L/KhPGX5YUopLLCYzVwNvDD?=
 =?iso-8859-1?Q?CXQ0J6XUeulUjTQ2vQxqVcysyvPefiCrM5SnHxpzi8zk4OKPthUqqfEADS?=
 =?iso-8859-1?Q?aLbnNvZ8CzVf/Dy6Wd+wYzhIOkO2e26RgC7/Mk7E8rPMtB2WtBmdbtqpqu?=
 =?iso-8859-1?Q?noN2jIQQLp2uq5Xe5QyzSGY0gX6h/lN1wourgaIDUDAL1HrCzlDCISt6et?=
 =?iso-8859-1?Q?lYmWMsAEIhzdY3jJPXTW9BOJuYP8atvEpQJRwmoHJ1e7aZOzaT1k0dBKNE?=
 =?iso-8859-1?Q?ViT5wzDYvg8Ir6qiEJQJcPR5Vkv1NV6PjckmHZqETGUKBbXYGQAwKr/we0?=
 =?iso-8859-1?Q?pwDLubjUCC7mEN8SY4KncdhNE+OP4tuQBLoaUwd47fiBsUMjuqUX2s7vat?=
 =?iso-8859-1?Q?Cb1Ap+9PMKR7nljFZKajvY1BQ9HMsL9pWbT6WWKihUkSgGLQn4za42n9wQ?=
 =?iso-8859-1?Q?9KJrNtGvK9aVRMSj7Mgv7D0PF7thl3vTC9pn6l/fIMniU9hDZ+WaZ5f2r7?=
 =?iso-8859-1?Q?Fzz0jQS86l+GGkiTFCKM1K+MjlizcsneqUT6XArwf/0waopeji47s3AWXO?=
 =?iso-8859-1?Q?nmoESgZCDObH8609IvpLcsOMqq9oyEWUIaYGKUaKvPwGjFwzeSzv6tAtaI?=
 =?iso-8859-1?Q?e/BqOriz8kuiFVgx1XcVTs7/LAIOHo1z1xXIszo9GSxpqwXhEODUEbKsVf?=
 =?iso-8859-1?Q?VcmFdoOt0H1WfPp0g5D4/lJfdd42oIiXJPabKdWO5M9JvXpzFuKHJ671eZ?=
 =?iso-8859-1?Q?UAjhYADuQjVOeo+HramsLHyjrXu6UFifUK2aIeFfj1J3VKbopEMeuJMw?=
 =?iso-8859-1?Q?=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: a96de8b4-4f33-4aa8-ff99-08dd98620627
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2025 12:21:33.3900
 (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: 9ppQjGIx7d5XmkBytdm3n9SJlDwKqDqUQaChreMD8JIY4Fkpej/3F7Tr8kmbvwBQnd83IQ4OQ5n5SxqjuBuzrA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9644

From: Oleksandr Andrushchenko 

Add support for Renesas R-Car Gen4 PCI host controller, specifically
targeting the S4 and V4H SoCs. The implementation includes configuration
read/write operations for both root and child buses. For accessing the
child bus, iATU is used for address translation.

The host controller needs to be initialized by Dom0 first to be properly
handled by Xen. Xen itself only handles the runtime configuration of
the iATU for accessing different child devices.

iATU programming is done similarly to Linux, where only window 0 is used
for dynamic configuration, and it is reconfigured for every config space
read/write.

Code common to all DesignWare PCI host controllers is located in a
separate file to allow for easy reuse in other DesignWare-based PCI
host controllers.

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykyta Poturai 
---
v4->v5:
* update license identifiers
* improve error checking
* use XENLOG_G_* where needed
* make macro defs more robust and minor style fixes
* add MAINTANERS entry

v3->v4:
* no changes

v2->v3:
* move priv allocation to dw_pcie_host_probe

v1->v2:
* move designware code in a separate file
---
 MAINTAINERS                       |   6 +
 xen/arch/arm/pci/Makefile         |   2 +
 xen/arch/arm/pci/pci-designware.c | 416 ++++++++++++++++++++++++++++++
 xen/arch/arm/pci/pci-designware.h |  90 +++++++
 xen/arch/arm/pci/pci-host-rcar4.c |  94 +++++++
 5 files changed, 608 insertions(+)
 create mode 100644 xen/arch/arm/pci/pci-designware.c
 create mode 100644 xen/arch/arm/pci/pci-designware.h
 create mode 100644 xen/arch/arm/pci/pci-host-rcar4.c

diff --git a/MAINTAINERS b/MAINTAINERS
index c11b82eca9..dc1291e2b0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -476,6 +476,12 @@ M:	Anthony Perard 
 S:	Supported
 T:	git https://xenbits.xenproject.org/git-http/qemu-xen.git
=20
+RCAR PCI
+M:	Mykyta Poturai 
+S:	Supported
+F:	xen/arch/arm/pci/pci-host-rcar4.c
+F:	xen/arch/arm/pci/pci-designware*
+
 REMUS
 S:	Orphan
 F:	docs/README.remus
diff --git a/xen/arch/arm/pci/Makefile b/xen/arch/arm/pci/Makefile
index 1d045ade01..ca6135e282 100644
--- a/xen/arch/arm/pci/Makefile
+++ b/xen/arch/arm/pci/Makefile
@@ -4,3 +4,5 @@ obj-y +=3D pci-host-generic.o
 obj-y +=3D pci-host-common.o
 obj-y +=3D ecam.o
 obj-y +=3D pci-host-zynqmp.o
+obj-y +=3D pci-designware.o
+obj-y +=3D pci-host-rcar4.o
diff --git a/xen/arch/arm/pci/pci-designware.c b/xen/arch/arm/pci/pci-desig=
nware.c
new file mode 100644
index 0000000000..fc8c6724f2
--- /dev/null
+++ b/xen/arch/arm/pci/pci-designware.c
@@ -0,0 +1,416 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ *
+ * Based on Linux drivers/pci/controller/pci-host-common.c
+ * Based on Linux drivers/pci/controller/pci-host-generic.c
+ * Based on Linux drivers/pci/controller/dwc/pcie-designware.c
+ * Based on xen/arch/arm/pci/pci-host-generic.c
+ *
+ */
+
+#include 
+#include 
+
+#include "pci-designware.h"
+/**
+ * upper_32_bits - return bits 32-63 of a number
+ * @n: the number we're accessing
+ *
+ * A basic shift-right of a 64- or 32-bit quantity.  Use this to suppress
+ * the "right shift count >=3D width of type" warning when that quantity i=
s
+ * 32-bits.
+ */
+#define upper_32_bits(n) ((uint32_t)(((n) >> 16) >> 16))
+
+/**
+ * lower_32_bits - return bits 0-31 of a number
+ * @n: the number we're accessing
+ */
+#define lower_32_bits(n) ((uint32_t)((n) & 0xffffffffU))
+
+static int dw_pcie_read(void __iomem *addr, int len, uint32_t *val)
+{
+    if ( !IS_ALIGNED((uintptr_t)addr, len) )
+    {
+        *val =3D 0;
+        return -EFAULT;
+    }
+
+    switch ( len )
+    {
+    case 1:
+        *val =3D readb(addr);
+        break;
+    case 2:
+        *val =3D readw(addr);
+        break;
+    case 4:
+        *val =3D readl(addr);
+        break;
+    default:
+        ASSERT_UNREACHABLE();
+    }
+
+    return 0;
+}
+
+static int dw_pcie_write(void __iomem *addr, int len, uint32_t val)
+{
+    if ( !IS_ALIGNED((uintptr_t)addr, len) )
+        return -EFAULT;
+
+    switch ( len )
+    {
+    case 1:
+        writeb(val, addr);
+        break;
+    case 2:
+        writew(val, addr);
+        break;
+    case 4:
+        writel(val, addr);
+        break;
+    default:
+        ASSERT_UNREACHABLE();
+    }
+
+    return 0;
+}
+
+static uint32_t dw_pcie_read_dbi(struct pci_host_bridge *bridge, uint32_t =
reg,
+                                 size_t size)
+{
+    void __iomem *addr =3D bridge->cfg->win + reg;
+    uint32_t val;
+    int ret;
+
+    ret =3D dw_pcie_read(addr, size, &val);
+    if ( ret )
+        printk(XENLOG_G_ERR "Read DBI address failed\n");
+
+    return val;
+}
+
+static void dw_pcie_write_dbi(struct pci_host_bridge *bridge, uint32_t reg=
,
+                              size_t size, uint32_t val)
+{
+    void __iomem *addr =3D bridge->cfg->win + reg;
+    int ret;
+
+    ret =3D dw_pcie_write(addr, size, val);
+    if ( ret )
+        printk(XENLOG_G_ERR "Write DBI address failed\n");
+}
+
+static uint32_t dw_pcie_readl_dbi(struct pci_host_bridge *bridge, uint32_t=
 reg)
+{
+    return dw_pcie_read_dbi(bridge, reg, sizeof(uint32_t));
+}
+
+static void dw_pcie_writel_dbi(struct pci_host_bridge *pci, uint32_t reg,
+                               uint32_t val)
+{
+    dw_pcie_write_dbi(pci, reg, sizeof(uint32_t), val);
+}
+
+static void dw_pcie_read_iatu_unroll_enabled(struct pci_host_bridge *bridg=
e)
+{
+    struct dw_pcie_priv *priv =3D bridge->priv;
+    uint32_t val;
+
+    val =3D dw_pcie_readl_dbi(bridge, PCIE_ATU_VIEWPORT);
+    if ( val =3D=3D 0xffffffffU )
+        priv->iatu_unroll_enabled =3D true;
+
+    printk(XENLOG_G_DEBUG "%s iATU unroll: %sabled\n",
+           dt_node_full_name(bridge->dt_node),
+           priv->iatu_unroll_enabled ? "en" : "dis");
+}
+
+static uint32_t dw_pcie_readl_atu(struct pci_host_bridge *pci, uint32_t re=
g)
+{
+    struct dw_pcie_priv *priv =3D pci->priv;
+    int ret;
+    uint32_t val;
+
+    ret =3D dw_pcie_read(priv->atu_base + reg, 4, &val);
+    if ( ret )
+        printk(XENLOG_G_ERR "Read ATU address failed\n");
+
+    return val;
+}
+
+static void dw_pcie_writel_atu(struct pci_host_bridge *pci, uint32_t reg,
+                               uint32_t val)
+{
+    struct dw_pcie_priv *priv =3D pci->priv;
+    int ret;
+
+    ret =3D dw_pcie_write(priv->atu_base + reg, 4, val);
+    if ( ret )
+        printk(XENLOG_G_ERR "Write ATU address failed\n");
+}
+
+static uint32_t dw_pcie_readl_ob_unroll(struct pci_host_bridge *pci,
+                                        uint32_t index, uint32_t reg)
+{
+    uint32_t offset =3D PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
+
+    return dw_pcie_readl_atu(pci, offset + reg);
+}
+
+static void dw_pcie_writel_ob_unroll(struct pci_host_bridge *pci,
+                                     uint32_t index, uint32_t reg, uint32_=
t val)
+{
+    uint32_t offset =3D PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
+
+    dw_pcie_writel_atu(pci, offset + reg, val);
+}
+
+static uint32_t dw_pcie_enable_ecrc(uint32_t val)
+{
+    ASSERT_UNREACHABLE();
+    return 0;
+}
+
+static int dw_pcie_prog_outbound_atu_unroll(struct pci_host_bridge *pci,
+                                            uint8_t func_no, int index,
+                                            int type, uint64_t cpu_addr,
+                                            uint64_t pci_addr, uint64_t si=
ze)
+{
+    struct dw_pcie_priv *priv =3D pci->priv;
+    uint32_t retries, val;
+    uint64_t limit_addr =3D cpu_addr + size - 1;
+
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_BASE,
+                             lower_32_bits(cpu_addr));
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_BASE,
+                             upper_32_bits(cpu_addr));
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_LIMIT,
+                             lower_32_bits(limit_addr));
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_LIMIT,
+                             upper_32_bits(limit_addr));
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_TARGET,
+                             lower_32_bits(pci_addr));
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
+                             upper_32_bits(pci_addr));
+    val =3D type | PCIE_ATU_FUNC_NUM(func_no);
+    val =3D upper_32_bits(size - 1) ? val | PCIE_ATU_INCREASE_REGION_SIZE =
: val;
+    if ( priv->version =3D=3D 0x490A )
+        val =3D dw_pcie_enable_ecrc(val);
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1, val);
+    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
+                             PCIE_ATU_ENABLE);
+
+    /*
+     * Make sure ATU enable takes effect before any subsequent config
+     * and I/O accesses.
+     */
+    for ( retries =3D 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++ )
+    {
+        val =3D dw_pcie_readl_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CT=
RL2);
+        if ( val & PCIE_ATU_ENABLE )
+            return 0;
+
+        mdelay(LINK_WAIT_IATU);
+    }
+    printk(XENLOG_G_ERR "Outbound iATU is not being enabled\n");
+
+    return -ENXIO;
+}
+
+static int __dw_pcie_prog_outbound_atu(struct pci_host_bridge *pci,
+                                       uint8_t func_no, int index, int typ=
e,
+                                       uint64_t cpu_addr, uint64_t pci_add=
r,
+                                       uint64_t size)
+{
+    struct dw_pcie_priv *priv =3D pci->priv;
+    uint32_t retries, val;
+
+    if ( priv->iatu_unroll_enabled )
+        return dw_pcie_prog_outbound_atu_unroll(pci, func_no, index, type,
+                                                cpu_addr, pci_addr, size);
+
+    dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT,
+                       PCIE_ATU_REGION_OUTBOUND | index);
+    dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_BASE, lower_32_bits(cpu_addr));
+    dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_BASE, upper_32_bits(cpu_addr));
+    dw_pcie_writel_dbi(pci, PCIE_ATU_LIMIT, lower_32_bits(cpu_addr + size =
- 1));
+    if ( priv->version >=3D 0x460A )
+        dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_LIMIT,
+                           upper_32_bits(cpu_addr + size - 1));
+    dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_TARGET, lower_32_bits(pci_addr)=
);
+    dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET, upper_32_bits(pci_addr)=
);
+    val =3D type | PCIE_ATU_FUNC_NUM(func_no);
+    val =3D ((upper_32_bits(size - 1)) && (priv->version >=3D 0x460A))
+              ? val | PCIE_ATU_INCREASE_REGION_SIZE
+              : val;
+    if ( priv->version =3D=3D 0x490A )
+        val =3D dw_pcie_enable_ecrc(val);
+    dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, val);
+    dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE);
+
+    /*
+     * Make sure ATU enable takes effect before any subsequent config
+     * and I/O accesses.
+     */
+    for ( retries =3D 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++ )
+    {
+        val =3D dw_pcie_readl_dbi(pci, PCIE_ATU_CR2);
+        if ( val & PCIE_ATU_ENABLE )
+            return 0;
+
+        mdelay(LINK_WAIT_IATU);
+    }
+    printk(XENLOG_G_ERR "Outbound iATU is not being enabled\n");
+
+    return -ENXIO;
+}
+
+static int dw_pcie_prog_outbound_atu(struct pci_host_bridge *pci, int inde=
x,
+                                     int type, uint64_t cpu_addr,
+                                     uint64_t pci_addr, uint64_t size)
+{
+    return __dw_pcie_prog_outbound_atu(pci, 0, index, type, cpu_addr, pci_=
addr,
+                                       size);
+}
+
+void dw_pcie_set_version(struct pci_host_bridge *bridge, unsigned int vers=
ion)
+{
+    struct dw_pcie_priv *priv =3D bridge->priv;
+
+    priv->version =3D version;
+}
+
+void __iomem *dw_pcie_child_map_bus(struct pci_host_bridge *bridge,
+                                    pci_sbdf_t sbdf, uint32_t where)
+{
+    uint32_t busdev;
+    int ret;
+
+    busdev =3D PCIE_ATU_BUS(sbdf.bus) | PCIE_ATU_DEV(PCI_SLOT(sbdf.devfn))=
 |
+             PCIE_ATU_FUNC(PCI_FUNC(sbdf.devfn));
+
+    /* FIXME: Parent is the root bus, so use PCIE_ATU_TYPE_CFG0. */
+    ret =3D dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
+                                    PCIE_ATU_TYPE_CFG0,
+                                    bridge->child_cfg->phys_addr, busdev,
+                                    bridge->child_cfg->size);
+    if ( ret )
+        return 0;
+
+    return bridge->child_cfg->win + where;
+}
+
+int dw_pcie_child_config_read(struct pci_host_bridge *bridge, pci_sbdf_t s=
bdf,
+                              uint32_t reg, uint32_t len, uint32_t *value)
+{
+    struct dw_pcie_priv *priv =3D bridge->priv;
+    int ret;
+
+    /*
+     * FIXME: we cannot read iATU settings at the early initialization
+     * (probe) as the host's HW is not yet initialized at that phase.
+     * This read operation is the very first thing Domain-0 will do
+     * during its initialization, so take this opportunity and read
+     * iATU setting now.
+     */
+    if ( unlikely(!priv->iatu_unroll_initilized) )
+    {
+        dw_pcie_read_iatu_unroll_enabled(bridge);
+        priv->iatu_unroll_initilized =3D true;
+    }
+
+    ret =3D pci_generic_config_read(bridge, sbdf, reg, len, value);
+    if ( !ret && (priv->num_viewport <=3D 2) )
+        ret =3D dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
+                                        PCIE_ATU_TYPE_IO,
+                                        bridge->child_cfg->phys_addr, 0,
+                                        bridge->child_cfg->size);
+
+    return ret;
+}
+
+int dw_pcie_child_config_write(struct pci_host_bridge *bridge, pci_sbdf_t =
sbdf,
+                               uint32_t reg, uint32_t len, uint32_t value)
+{
+    struct dw_pcie_priv *priv =3D bridge->priv;
+    int ret;
+
+    ret =3D pci_generic_config_write(bridge, sbdf, reg, len, value);
+    if ( !ret && (priv->num_viewport <=3D 2) )
+        ret =3D dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
+                                        PCIE_ATU_TYPE_IO,
+                                        bridge->child_cfg->phys_addr, 0,
+                                        bridge->child_cfg->size);
+    return ret;
+}
+
+bool __init dw_pcie_child_need_p2m_hwdom_mapping(struct domain *d,
+                                                 struct pci_host_bridge *b=
ridge,
+                                                 uint64_t addr)
+{
+    struct pci_config_window *cfg =3D bridge->child_cfg;
+
+    /*
+     * We do not want ECAM address space to be mapped in Domain-0's p2m,
+     * so we can trap access to it.
+     */
+    return cfg->phys_addr !=3D addr;
+}
+
+struct pci_host_bridge *__init
+dw_pcie_host_probe(struct dt_device_node *dev, const void *data,
+                   const struct pci_ecam_ops *ops,
+                   const struct pci_ecam_ops *child_ops)
+{
+    struct pci_host_bridge *bridge;
+    struct dw_pcie_priv *priv;
+
+    paddr_t atu_phys_addr;
+    paddr_t atu_size;
+    int atu_idx, ret;
+
+    bridge =3D pci_host_common_probe(dev, ops, child_ops);
+    if ( IS_ERR(bridge) )
+        return bridge;
+
+    priv =3D xzalloc(struct dw_pcie_priv);
+    if ( !priv )
+        return ERR_PTR(-ENOMEM);
+
+    bridge->priv =3D priv;
+
+    atu_idx =3D dt_property_match_string(dev, "reg-names", "atu");
+    if ( atu_idx < 0 )
+    {
+        printk(XENLOG_ERR "Cannot find \"atu\" range index in device tree\=
n");
+        return ERR_PTR(atu_idx);
+    }
+    ret =3D dt_device_get_address(dev, atu_idx, &atu_phys_addr, &atu_size)=
;
+    if ( ret )
+    {
+        printk(XENLOG_ERR "Cannot find \"atu\" range in device tree\n");
+        return ERR_PTR(ret);
+    }
+    printk("iATU at [mem 0x%" PRIpaddr "-0x%" PRIpaddr "]\n", atu_phys_add=
r,
+           atu_phys_addr + atu_size - 1);
+    priv->atu_base =3D ioremap_nocache(atu_phys_addr, atu_size);
+    if ( !priv->atu_base )
+    {
+        printk(XENLOG_ERR "iATU ioremap failed\n");
+        return ERR_PTR(ENXIO);
+    }
+
+    if ( !dt_property_read_u32(dev, "num-viewport", &priv->num_viewport) )
+        priv->num_viewport =3D 2;
+
+    /*
+     * FIXME: we cannot read iATU unroll enable now as the host bridge's
+     * HW is not yet initialized by Domain-0: leave it for later.
+     */
+
+    printk(XENLOG_INFO "%s number of view ports: %d\n", dt_node_full_name(=
dev),
+           priv->num_viewport);
+
+    return bridge;
+}
diff --git a/xen/arch/arm/pci/pci-designware.h b/xen/arch/arm/pci/pci-desig=
nware.h
new file mode 100644
index 0000000000..df4a9afe75
--- /dev/null
+++ b/xen/arch/arm/pci/pci-designware.h
@@ -0,0 +1,90 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ *
+ * Based on Linux drivers/pci/controller/pci-host-common.c
+ * Based on Linux drivers/pci/controller/pci-host-generic.c
+ * Based on Linux drivers/pci/controller/dwc/pcie-designware.c
+ * Based on xen/arch/arm/pci/pci-host-generic.c
+ */
+
+#include 
+#include 
+
+#ifndef __PCI_DESIGNWARE_H__
+#define __PCI_DESIGNWARE_H__
+
+
+#define PCIE_ATU_VIEWPORT               0x900
+#define PCIE_ATU_REGION_OUTBOUND        0
+#define PCIE_ATU_CR1                    0x904
+#define PCIE_ATU_INCREASE_REGION_SIZE   BIT(13, UL)
+#define PCIE_ATU_CR2                    0x908
+#define PCIE_ATU_ENABLE                 BIT(31, UL)
+#define PCIE_ATU_LOWER_BASE             0x90C
+#define PCIE_ATU_UPPER_BASE             0x910
+#define PCIE_ATU_LIMIT                  0x914
+#define PCIE_ATU_LOWER_TARGET           0x918
+#define PCIE_ATU_UPPER_TARGET           0x91C
+#define PCIE_ATU_UPPER_LIMIT            0x924
+
+#define PCIE_ATU_REGION_INDEX1  0x1
+#define PCIE_ATU_TYPE_IO        0x2
+#define PCIE_ATU_TYPE_CFG0      0x4
+
+#define FIELD_PREP(_mask, _val) \
+    (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask))
+
+#define PCIE_ATU_BUS(x)         FIELD_PREP(GENMASK(31, 24), (x))
+#define PCIE_ATU_DEV(x)         FIELD_PREP(GENMASK(23, 19), (x))
+#define PCIE_ATU_FUNC(x)        FIELD_PREP(GENMASK(18, 16), (x))
+
+/* Register address builder */
+#define PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(region) \
+    ((region) << 9)
+
+/*
+ * iATU Unroll-specific register definitions
+ * From 4.80 core version the address translation will be made by unroll
+ */
+#define PCIE_ATU_UNR_REGION_CTRL1       0x00
+#define PCIE_ATU_UNR_REGION_CTRL2       0x04
+#define PCIE_ATU_UNR_LOWER_BASE         0x08
+#define PCIE_ATU_UNR_UPPER_BASE         0x0C
+#define PCIE_ATU_UNR_LOWER_LIMIT        0x10
+#define PCIE_ATU_UNR_LOWER_TARGET       0x14
+#define PCIE_ATU_UNR_UPPER_TARGET       0x18
+#define PCIE_ATU_UNR_UPPER_LIMIT        0x20
+
+#define PCIE_ATU_FUNC_NUM(pf)           ((pf) << 20)
+
+/* Parameters for the waiting for iATU enabled routine */
+#define LINK_WAIT_MAX_IATU_RETRIES      5
+#define LINK_WAIT_IATU                  9
+
+struct dw_pcie_priv {
+    uint32_t num_viewport;
+    bool iatu_unroll_initilized;
+    bool iatu_unroll_enabled;
+    void __iomem *atu_base;
+    unsigned int version;
+};
+
+void dw_pcie_set_version(struct pci_host_bridge *bridge, unsigned int vers=
ion);
+
+void __iomem *dw_pcie_child_map_bus(struct pci_host_bridge *bridge,
+                                    pci_sbdf_t sbdf, uint32_t where);
+
+int dw_pcie_child_config_read(struct pci_host_bridge *bridge, pci_sbdf_t s=
bdf,
+                              uint32_t reg, uint32_t len, uint32_t *value)=
;
+
+int dw_pcie_child_config_write(struct pci_host_bridge *bridge, pci_sbdf_t =
sbdf,
+                               uint32_t reg, uint32_t len, uint32_t value)=
;
+
+bool __init dw_pcie_child_need_p2m_hwdom_mapping(struct domain *d,
+                                                 struct pci_host_bridge *b=
ridge,
+                                                 uint64_t addr);
+
+struct pci_host_bridge *__init
+dw_pcie_host_probe(struct dt_device_node *dev, const void *data,
+                   const struct pci_ecam_ops *ops,
+                   const struct pci_ecam_ops *child_ops);
+#endif /* __PCI_DESIGNWARE_H__ */
diff --git a/xen/arch/arm/pci/pci-host-rcar4.c b/xen/arch/arm/pci/pci-host-=
rcar4.c
new file mode 100644
index 0000000000..62d2130a63
--- /dev/null
+++ b/xen/arch/arm/pci/pci-host-rcar4.c
@@ -0,0 +1,94 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ *
+ * Based on Linux drivers/pci/controller/pci-host-common.c
+ * Based on Linux drivers/pci/controller/pci-host-generic.c
+ * Based on xen/arch/arm/pci/pci-host-generic.c
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "pci-designware.h"
+
+#define RCAR4_DWC_VERSION       0x520A
+
+/*
+ * PCI host bridges often have different ways to access the root and child
+ * bus config spaces:
+ *   "dbi"   : the aperture where root port's own configuration registers
+ *             are available.
+ *   "config": child's configuration space
+ *   "atu"   : iATU registers for DWC version 4.80 or later
+ */
+static int __init rcar4_cfg_reg_index(struct dt_device_node *np)
+{
+    return dt_property_match_string(np, "reg-names", "dbi");
+}
+
+static int __init rcar4_child_cfg_reg_index(struct dt_device_node *np)
+{
+    return dt_property_match_string(np, "reg-names", "config");
+}
+
+/* ECAM ops */
+const struct pci_ecam_ops rcar4_pcie_ops =3D {
+    .bus_shift  =3D 20,
+    .cfg_reg_index =3D rcar4_cfg_reg_index,
+    .pci_ops    =3D {
+        .map_bus                =3D pci_ecam_map_bus,
+        .read                   =3D pci_generic_config_read,
+        .write                  =3D pci_generic_config_write,
+        .need_p2m_hwdom_mapping =3D pci_ecam_need_p2m_hwdom_mapping,
+        .init_bus_range         =3D pci_generic_init_bus_range,
+    }
+};
+
+const struct pci_ecam_ops rcar4_pcie_child_ops =3D {
+    .bus_shift  =3D 20,
+    .cfg_reg_index =3D rcar4_child_cfg_reg_index,
+    .pci_ops    =3D {
+        .map_bus                =3D dw_pcie_child_map_bus,
+        .read                   =3D dw_pcie_child_config_read,
+        .write                  =3D dw_pcie_child_config_write,
+        .need_p2m_hwdom_mapping =3D dw_pcie_child_need_p2m_hwdom_mapping,
+        .init_bus_range         =3D pci_generic_init_bus_range_child,
+    }
+};
+
+static const struct dt_device_match __initconstrel rcar4_pcie_dt_match[] =
=3D {
+    { .compatible =3D "renesas,r8a779f0-pcie" },
+    { .compatible =3D "renesas,r8a779g0-pcie" },
+    {},
+};
+
+static int __init pci_host_rcar4_probe(struct dt_device_node *dev,
+                                       const void *data)
+{
+    struct pci_host_bridge *bridge;
+
+    bridge =3D dw_pcie_host_probe(dev, data, &rcar4_pcie_ops,
+                                &rcar4_pcie_child_ops);
+
+    dw_pcie_set_version(bridge, RCAR4_DWC_VERSION);
+
+    return 0;
+}
+
+DT_DEVICE_START(pci_gen, "PCI HOST R-CAR GEN4", DEVICE_PCI_HOSTBRIDGE)
+.dt_match =3D rcar4_pcie_dt_match,
+.init =3D pci_host_rcar4_probe,
+DT_DEVICE_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 21 12:21:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 12:21:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991774.1375597 (Exim 4.92)
	(envelope-from )
	id 1uHiS4-0008PL-VH; Wed, 21 May 2025 12:21:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991774.1375597; Wed, 21 May 2025 12: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 1uHiS4-0008PE-SL; Wed, 21 May 2025 12:21:40 +0000
Received: by outflank-mailman (input) for mailman id 991774;
 Wed, 21 May 2025 12:21:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHiS3-0008BY-7V
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 12:21:39 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2606::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 24805530-363e-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 14:21:37 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PAWPR03MB9644.eurprd03.prod.outlook.com
 (2603:10a6:102:2e3::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Wed, 21 May
 2025 12:21:32 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8746.030; Wed, 21 May 2025
 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" 
X-Inumbo-ID: 24805530-363e-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ahQnGVS3v3W8Zf/DTrXaCj2pIIENBchqPEjo+YUBoh/pg1E+tXIdnHQy7ECgD0dIYzJj+WDx9HCnMW0Fe7O/yuZUwxR4b29hrUK4G/PbIDArojcY6Txkl9gp5drwybAwq+x/lJPGJnjroT/OOb4UlR96CytAdsGdzhfhbiJRpXJk7TK9FcwTLqJOmLvIb9AwFjzzZp0cTtt2r8T5sblXSnDEL5Le1bZyEvwCW6EuDwgZYIGC+sVKYFt/nJc0LcljdXyvbKnkpJoiMVs/pJT/LTMpMEVMCTwHz/aCKBQWrHT3GdQcKrQjoZ/7b6IAB6uGdYOPcDYnfQTsPA+c5KEAGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=AD+lXGFVxLsdJe/Wp7M37E7pZVi1Gm7YGU5N4kr6VvE=;
 b=XVKNRo7tbc2bQN97YUvsl0BfTjmHmvpX8KpkBovwE0duNTD5hQS4V2KhBUBk9D3dwnIjeKdjYkZQK0yRjlOp9+bmXT0jOEkqEUBHeFNvpiy8mpvgOeN819Otfi52wPLEYpCPTdRaXXnHXDdL7fSR5PtVX2L61qhf5NvgByXVV4+rd4QRgLIQPGPzwqRoL2GUyuTJgjXGGvNpbvDpDGUYLTi4sZtRXweFSuBR8+nt2EM3NziUFLHCZexnsgc5XMtWwdFO4xuTTFuvMQ2dR46doMv7gpcl3NXB3K9Z8hjahelsbWygO9O9HLzu6ab6kR5jBtIRS4YBcKK4Res04E3/3Q==
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=AD+lXGFVxLsdJe/Wp7M37E7pZVi1Gm7YGU5N4kr6VvE=;
 b=O6VsuQts7ZMw0K9+auXhDPA/rA+M99xzYXYztugGim42oS3+uhCtMO5tbI7QSaclq0PjGTyMSSWz/TrqRR7ToLnqRby0cmodBEr3F8Yfqca/HWwiJpEvjTtWddBk1icSmwhMzXjBz0tGCmj++4DOPnNuDfN9sdSc6XV3xPhpZmU4UfwSbQHoNet92ZbxbyKIOojT4eTzaVizquGIxlkkfja/QpSpwVzhqnc4QaTxeIc5Db8Zms+egtFJtryIh8rePNuwHvHu/LLaCd4P1y/fo7dZ04KFksdSt8pvYg+xRgAzN3NGvTRZP2XYBDBaWyFGg4WC5XyXBUmxyEJWEQBpxg==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk , Mykyta Poturai
	
Subject: [PATCH v5 1/4] xen/arm: allow PCI host bridge to have private data
Thread-Topic: [PATCH v5 1/4] xen/arm: allow PCI host bridge to have private
 data
Thread-Index: AQHbykrilqxIORNGzEKIDfmnR2QzLw==
Date: Wed, 21 May 2025 12:21: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: 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_|PAWPR03MB9644:EE_
x-ms-office365-filtering-correlation-id: 04e9cafd-fbef-4ba1-89b7-08dd9862056f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?sgG8osn7F3EdxqBFqUYB+tKWXzDn+4VSyftuiJXl5TFFOdYJiu8tQXnKFR?=
 =?iso-8859-1?Q?RO243JSAmtSzltRVsYwKhKuUvzUM0cMQQIUKcdNgOwwUTYuiqF2gs0sfjV?=
 =?iso-8859-1?Q?qot8egCooJ0MqKWZgU1OjUn8Zh7bU3uNnfYf7Sya+ovckN6cyuMkoVk8ei?=
 =?iso-8859-1?Q?++Y6ppd0832tTCRlE+L+mvc9J5Oz4QYvoXf5gVj5LeZjFud/g4NhmJIGdg?=
 =?iso-8859-1?Q?KGYTWW4ioTFDphkwYhCBA2L1Rse5y4eH3IGH5a2VfMNwwF+znSRd4J2ifI?=
 =?iso-8859-1?Q?sVqPgKY+QOMvdRgX8OwJFQB4y4dOtGkl7TsSS3iC8j6fJPhjc5zN1I9scp?=
 =?iso-8859-1?Q?+Ot5g+WOb3Z7vien3GptAH5jcOH+yzZQc+Lj4p+nHAZD8xHkYfGk+Z0jQH?=
 =?iso-8859-1?Q?0XOhUODXF8fdBQIp07uPsoHJ1t01gOnrpTIGI+2MpFcRDQy7MzEv56YxrZ?=
 =?iso-8859-1?Q?vaZm+oPWzx36rurOAJ+VHp3lS6FD4oapd4dRM1V5ClUUTiSnlUodLwUMQw?=
 =?iso-8859-1?Q?e+HNnk4sLhUOsYy7h3h5D8N7ujcahDy/n1CH949J1De0dj+zfyFy0RoyuE?=
 =?iso-8859-1?Q?IvbM67WkuVb+HLFT38fVfsf99aauVVD48H5TOM1TvWc+oKw2bZ4Tre05C9?=
 =?iso-8859-1?Q?aWbNZDxVAXrI2f1lJtzdBL9ky1T86RFzaNkKRd+rER8pa5R54m6O47hAe7?=
 =?iso-8859-1?Q?oODw0FxCkeqfQGbTLburGVMEJp+aGEMxsNhuH61qgALBBGEiFrA3/deXPK?=
 =?iso-8859-1?Q?t04ugWthACelne+Dg5FQWorKIQmJbl048U4RcxF5VFtFAOcb0IAjTKkQbB?=
 =?iso-8859-1?Q?DSucn2cauqI+T8L7OH8g1GxlQzSeUs0v5kl77hNHADeKz1EqJElP4vJtCc?=
 =?iso-8859-1?Q?g9mReM7Aqws7egn61UWMiOLxN98f4t5qAWjbgNmyG8uTZQdDuXBq6Bbrx8?=
 =?iso-8859-1?Q?Te7Jm2Q6t2OLe+DIaKZbrW0IDXru5sd5Uri2zycknu6oIr8+0VXWLNg+mB?=
 =?iso-8859-1?Q?NGLf1Gkc2YTdBjoua42LlLls9SRAioOn/CZSQs3P/xWTBCMAcD7najqWot?=
 =?iso-8859-1?Q?4v+TCwrCa/o8IJxAo3M99cWbqO3aq2bVlKNjRBjkgFUKQXJ4DEkKkuAuzA?=
 =?iso-8859-1?Q?wlZx/sOODOf34eRMeOb2i5xEk7FTnEOKHNwj7RLkNpOWb26DycKBaoB4Fj?=
 =?iso-8859-1?Q?NsCMVMOOSAi+Ll6LPvCuM2bYKTJBeM/6u/qmWGJIOmsvN/iU50lW1TXWUc?=
 =?iso-8859-1?Q?3b8WrQ3w5mGhL/JPFF0QUCQQRj93IAIOmS9qM1hSFPhYfq7vVXYtWgBosn?=
 =?iso-8859-1?Q?+uDJ/HxRFEKudLCCRsYJ6yIhy0jlAd6kgqMAw7R8Eq5SYZ80Vkg9OZKaMM?=
 =?iso-8859-1?Q?CvGzVFFi1M0N6/mTL8uXCBoeOSrB+w3xliuWE5x1BG1w7tY69D1Lyx4ndN?=
 =?iso-8859-1?Q?hECXGki+Vdf/XKgOtdjyS9/req3ltQS7g2fABz/dYmpYBUiuL3Lmw9gZnX?=
 =?iso-8859-1?Q?GxCvZEQhey3/Re+AJxqnsHwCK68AToae0piN/Ot3eWgL3Xj5EJvXr5rVm8?=
 =?iso-8859-1?Q?yuQjTOQ=3D?=
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)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?vNVHzQHInt3RsuCFjzNmiwITfm2OJQQbSPDHcyEdmFrBohqiATrfEZm9zo?=
 =?iso-8859-1?Q?swTX5zmyF91vUp5HqhBL4RguAPHd3krP5bE2OYLbV2KI/pyZBHbVlPGS+M?=
 =?iso-8859-1?Q?sUnkVEZxNAJlvyuOTcy+Xc+/CLVw92R3b9qco3rSpgWw43CqgoOeCyFKuZ?=
 =?iso-8859-1?Q?C4Uh11hkcFyP1NzDl83ni/PXP0XqwUaD3zWkshdD63YF189gwRr+3Uj9Zh?=
 =?iso-8859-1?Q?e4h9LO7pNprIt7nzz0LBjzku6rrZTrc5oxOfT/I23i6RhLKaKidNtG9SbQ?=
 =?iso-8859-1?Q?nJZgRMvPAE4Z2vQOa2ArWOa4R/wbGuFYyBt+DxMEkNSB1lsg7lzzoql0xl?=
 =?iso-8859-1?Q?F8CVmHZi5Lk/reZZ2Y8Kn29845MkRlu0vU3DmJQIluLVjRY5pDMvKMmQIV?=
 =?iso-8859-1?Q?J6aBtD5/sACC7f7Wxr97FhGtGzGbSTydwV5LU6/fkqan+nEHsFwKgt6ead?=
 =?iso-8859-1?Q?zw2Y5JKzCHuQ6IKKzjF84JBs6qx9l3L+dXXbAcu+OeJgJ/L+ycoQPeKOEH?=
 =?iso-8859-1?Q?0hkny556BwywfyMl20mbX2ZoOW0ys93cxZdNsox3BTyz8On31vqbL/tZ9R?=
 =?iso-8859-1?Q?DHm8AvOhR5XYVQYTUyhrOa/K8ul+jItPPCj1Zn+AezDjZjGNox3eCUsm0v?=
 =?iso-8859-1?Q?+8VRS49OthyPOQWsa98sPA5TI4eLh776z1UL8S3izV+slnJXOzXHHU4SoD?=
 =?iso-8859-1?Q?mo69zF2AGeCfs6Am9KSAGPwibWpOgqUhzLtWRgiAlW1mc86k9AkeTwtY/l?=
 =?iso-8859-1?Q?opu4KX7huch1iUoF7fAeicpr3DVdMenFhf/jfMKRvG3PleRaCkZzNNbZar?=
 =?iso-8859-1?Q?ipopvYSGjWuhYsxfuSV/pCksR17HKOrEahnVT2+d5DAXiUBJo/qsjY7e5K?=
 =?iso-8859-1?Q?ZgUNsp75zXAvAfrBHTGbum79tgiFc7nLOBGpltWOJUbej3Hc/Db3FHlggw?=
 =?iso-8859-1?Q?yGbpXYZTK4luwMEOUM6qMWmYYeLVnmNxJu7LD9PzXvp5s7KV/GpBlxBxbZ?=
 =?iso-8859-1?Q?prPO1il2pFKunK7zOv35yHVtlc+woRso4SB6YFVpEjz9ANpR21LHSWN0/k?=
 =?iso-8859-1?Q?vORtpx8qopwlwU/ux21PHLrBJyzw4csEkAiaM19rIxgwyKaZsUSiQfRZ+4?=
 =?iso-8859-1?Q?1jluA9WvmVgPJmlx5GiEwxOppA3OxbRFsJI6UHACYB6G3Kn6cIqOkoFRSq?=
 =?iso-8859-1?Q?OyrFtDuOMDr68Ky7wUN5ukgQeAU6wu5MpJhAoSvl2PljSA+vpLY7chOkSK?=
 =?iso-8859-1?Q?ehB710dkaiK/LlbYx5C7WGj13l+hvitRMuBrZIOB8naUvJE7+21ZOg+kTI?=
 =?iso-8859-1?Q?ifbxpbtISYTTD3fkmrpl/+InFKlUp0B3c7jumUSHgqmzhkNA8lt6lloUk9?=
 =?iso-8859-1?Q?DQ9VVs1w4kQ8RDPBcEfbsQVGYmrOvUHj3zpZmLkTnxYk1exLrSN8kMkdQB?=
 =?iso-8859-1?Q?tqA6+Wp8B8CL4aGRVUhN8epLKHfeSdEKdaryTBzkgDQZrORh0fZ2bO4dTL?=
 =?iso-8859-1?Q?9XMm5rywGpRfRLdkIXPHldmGRGu+Wr8egX0QYx/SnQ7gFg8vuam18JZJZO?=
 =?iso-8859-1?Q?7/Nx8zx6BdTMVZSFjSLJ1n90/SGpKo8JrzO7DKC8orrJ+sbW05L+I+SJmw?=
 =?iso-8859-1?Q?wY0LmAMTzUbC2wStW2xPdwGvUn8Hb5oZ6WgLQ0Mcb4V7TsW+cfLHzrqA?=
 =?iso-8859-1?Q?=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: 04e9cafd-fbef-4ba1-89b7-08dd9862056f
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2025 12:21:32.1336
 (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: g5ofO74kepu3tynzCa9+rME3Ze/Vl6//3i3Sj2Y3vB/TnXhGtBuIFhpvFYvVVAPJg/UpfHT81yoHZENHLoJJ6Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9644

From: Oleksandr Andrushchenko 

Some of the PCI host bridges require private data. Add priv field
to struct pci_host_bridge, so such bridges may populate it with
their private data.

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykyta Poturai 
Reviewed-by: Stefano Stabellini 
---
v4->v5:
* no change

v3->v4:
* Added Stefano's RB

v2->v3:
* removed priv allocation from common code

v1->v2:
* no change
---
 xen/arch/arm/include/asm/pci.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.=
h
index 7f77226c9b..a87672d834 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -66,6 +66,7 @@ struct pci_host_bridge {
     uint16_t segment;                /* Segment number */
     struct pci_config_window* cfg;   /* Pointer to the bridge config windo=
w */
     const struct pci_ops *ops;
+    void *priv;                      /* Private data of the bridge. */
 };
=20
 struct pci_ops {
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 21 12:21:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 12:21:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991775.1375607 (Exim 4.92)
	(envelope-from )
	id 1uHiS7-0000DI-BO; Wed, 21 May 2025 12:21:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991775.1375607; Wed, 21 May 2025 12:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHiS7-0000D6-7q; Wed, 21 May 2025 12:21:43 +0000
Received: by outflank-mailman (input) for mailman id 991775;
 Wed, 21 May 2025 12:21:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHiS5-0008Qd-C4
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 12:21:41 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2606::60c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 25d72b11-363e-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 14:21:40 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PAWPR03MB9644.eurprd03.prod.outlook.com
 (2603:10a6:102:2e3::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Wed, 21 May
 2025 12:21:32 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8746.030; Wed, 21 May 2025
 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" 
X-Inumbo-ID: 25d72b11-363e-11f0-a2fa-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=g7dCmwk5rPd8ks8HhjHFpohMzpf0J+/AmWsYtwsgxPdqvvFwfpB32ZQXRG8a0JRb5T23lATSmFXTW1i72C5IOdZkLrXAWjIA17vbi18hU9houIx6pO2vcwFg+9kKQ+TiOVhjbqvyyEUvvI/PSfi8m6f4GPy0M0x2/5LBHD+QTvpgoKmLagfYCELKU0vw6sBkgPEzeFFygIN2Cc0Uy1IcEVy2SCdKzv23Tq/b9fglj0lKPoZLV1rvSpYP+yBLg0QHbDcLwC1h9Zyb9KcH1Yu4vzr11cta+JUJ3E3IEpiWHBy24nMVwS1RL+hFlYZz8/hu6Q+tFggU+BBRfRpGRbdS0w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XXlEugMu56S+FR75MPQXIrqVs5/GFWgKNx5N1lVYYZg=;
 b=e6Bm010FGCcUjSX2HNIfDNKDTDfMp+AvlYh1uvJ6y/EV/Y1Vt/kaUCn29a/pZw0Iu2mM7+s8bnjaGuEer0RySLUG0fEeGgDEJt1xD+7Xii8Scfr7UdxuOnMXgqvvRuFMAyUboTJFr8sOmYTZw7oWSyY5B/QQEX7+xchp6+R+ygdfxshm9aJ+4SN9LMNP7l0EGCdVY0vyIe5bIM44kNWxhDYAU6JTjmMzj056oanI11IBrEWpNgej5hqQKar+Lrp8pH6wMmNgjP6W2hyoF3wT6Ij0XXmKxNc+aP/9OvrVeaOxYbf3upFfY0bp3AQkfNzBGAFubvTFFhDXrwlGWg79DA==
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=XXlEugMu56S+FR75MPQXIrqVs5/GFWgKNx5N1lVYYZg=;
 b=LEpQQBTLeGuumx4h6uc+JPO3XxfYwDCoL6QNJjpn9rUUMhmqgIVyIGdKVmceIb0OZIwNVmR3udjHEIWMjLd/aJYyuXfXmG1AGPsHXPlKvWO7TBtpor5Ba/09ueidnoG1OmiV7oujDuDU9v2b0is4GRukYATL5qD+28OykQhC0br5OGmrozXxesCOVoZpHt09gkxnpDhKQou1IV7qLG6TapiZgfx7EXgkwVTrFAIJ8ethBauA5REtIXDLR/3wnRl7VygDKrDqdqmBB8zTFA9PBufRpryYr/Wl+jSC92sCqg0Nf/ZPhdZRikNuhCUKLEbWNI2nEPrsAycNgWOZ7dM3cg==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk , Mykyta Poturai
	
Subject: [PATCH v5 2/4] xen/arm: make pci_host_common_probe return the bridge
Thread-Topic: [PATCH v5 2/4] xen/arm: make pci_host_common_probe return the
 bridge
Thread-Index: AQHbykrjILOaYfYMbEqAZUHbg++Fgw==
Date: Wed, 21 May 2025 12:21:32 +0000
Message-ID:
 <2bb8628cd0eaaa2f84749ca7f72d030d20ca4325.1747820844.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: 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_|PAWPR03MB9644:EE_
x-ms-office365-filtering-correlation-id: 6a97cb4b-0c87-498a-7eb0-08dd986205a2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?/WOsPs0DfV9VxtoT4I+t+BGqP32C5rgjr1VbKbC1z3RiPkhEQikfR0xATB?=
 =?iso-8859-1?Q?6IzuRB/KoPqbCSVpd2hlByVRSeWB8QJLQc/bXcnaozdOIs4feEl2sA6Gkp?=
 =?iso-8859-1?Q?oFaolsKE+Kx8B6mqd+p4aWrmPNbA/O2hWBLhoNib849pP40whKKC/oci20?=
 =?iso-8859-1?Q?CQBIrTZnuN2vYiCau7v8Ae92OdG2l0LpwpDiJ3mezfoQ6eN5QdhV90EdHP?=
 =?iso-8859-1?Q?gPXp2id1yoOSN0dw4L6O/XX21tZo62PfkC0BbEh5ggNEzHzsWSQXjVRlzj?=
 =?iso-8859-1?Q?HcFnVYnmvuWndKAoGj3j3ezesoFP69ITfZluzp4hW5JrXVsvMbRlLFZUOJ?=
 =?iso-8859-1?Q?ZYOls813Ta98JRYuCxpTF5BkcWQFW5sZ3g4IMplZpQuWuSg+5//SwPblLw?=
 =?iso-8859-1?Q?6KCdx/kMhmNA7Dc0VmHdesbHsH/L22NYXPjbNa0CArpbyHtBdtjduNb9Z4?=
 =?iso-8859-1?Q?1FVMfBotFa7lkG1Hg5Zpj4TXxErKescZ6vtiVKpgIxkIuUSxmLoSUcNzOX?=
 =?iso-8859-1?Q?tNKZqX0gaZkYreGtQMx9KMuMoU3OTOMEM5zW/35C7Ruebe7zhJ1GYb4Lde?=
 =?iso-8859-1?Q?EFY+L/QO6T9m9r7eBeth+Ie+mjd6I58+l78OdklqTxhbnl/RMo8uT6V+ie?=
 =?iso-8859-1?Q?P/KlTahcb0idlc4ooJZkoCIS/0PfNBME1RSeV0XJFN8FyqCpQEyaAk7TP8?=
 =?iso-8859-1?Q?W3Ps3WuKqEEMta8fYepa/3wfBqabsPVvDScNdmfmpH0GR1+aCTzIFvJZyR?=
 =?iso-8859-1?Q?MN9zZkqJwgBqhfqjYV5OEFEZ92kv1s0PtgUgeV5CV/CB2d7Qestjf8Lt4y?=
 =?iso-8859-1?Q?VHg5YdhJsfEI8j65RlbPAkM4GKAWJEetzR1/NSDac+reRA1VUbLwHr3Pih?=
 =?iso-8859-1?Q?GM4jfbjaK0dQylzqjfP13up864Pjb/p+oNFhsCUd5vvHoNniCnbN5ppsC3?=
 =?iso-8859-1?Q?pekvZNR21Gre4bcibhZA5Z7OrwSaSyQPCFd89vKOVWLqL0WB1IpsJiVsW8?=
 =?iso-8859-1?Q?6PQmcXEbH1FoZ5Pw24R6dJlpVtYEGDNJSrLuKsXltgZAAF+Kr8N84V9HU4?=
 =?iso-8859-1?Q?Fl86JFQcB+IUV4spkxXiMKjw53sM13zeYnqWNjuTWYWHLI5oADpO9hNs64?=
 =?iso-8859-1?Q?O0MKUgsTkYLRSv5v5vdHOS6QH0aw4z2oEHNSvuINO26zytF9khUtXl4C1p?=
 =?iso-8859-1?Q?ASJCqOeI0FAvv8BzTANcl1GqRkguNvTfKfTKSc//Xb1T4JvcFRpdgp5By7?=
 =?iso-8859-1?Q?NcHpoPRpe/tYBBuN22+OvGexSIWjJUFYPPBx+7gjqFIH4V1IFkPhygm6ry?=
 =?iso-8859-1?Q?xJ9KpmtYRcd6bU18l/watT8h7TXcdKlFud0BILE1vMkTcuUnCutCC1ayuz?=
 =?iso-8859-1?Q?6tteFi7TSUl1Awm8woFCnXavoLbVlIUQcPwAszUXEpJDdmnN6asxIgIEUm?=
 =?iso-8859-1?Q?aP+4IoiYtK+Jw0QOGWo3UxTmMIy+NG3z8RvPyFUF3fD6tSJKLgEW7Yle+y?=
 =?iso-8859-1?Q?fpVLlnZr/92q6Z+vNR6HylYuLj7R3O+ZWWLOH9KAdU4+sn3x2ncKYgZYUt?=
 =?iso-8859-1?Q?l5h3Ovo=3D?=
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)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?mTOgo3AuN8oR/f9n1ucgRGYbfU4i0VQNPWuOV5MJ7PsG3NHKuWBXTcZdPb?=
 =?iso-8859-1?Q?h6pWXiqjGxzWqpB5IOl97uFYQfKalO8maL4wdpzKaWvcN6KkvRQBdgCKsH?=
 =?iso-8859-1?Q?UBqOQ+vbQOKbH32ftkEtSsmzJnAFucNvRa9vwwaG/ucbzrYiS4Mo8HKGuX?=
 =?iso-8859-1?Q?7fwOOXvyifo49ODq6oURnKvb3haxSqq2PZgk2va89EqsrKtJqeqHCIATqv?=
 =?iso-8859-1?Q?SkgTyWgyc8qQzjlhDT+nbifb6UorPl+ngALIvxU+RjZForJH3X95i3/XEt?=
 =?iso-8859-1?Q?pIXqcMFkG1//s+WSbR2IUpeVZra7sjfsoB7H9clffmypmPPM7zEOK61QV+?=
 =?iso-8859-1?Q?MoxCxWTUT+pnNcX6HUqmim9FMvuNwgJd7hSYMPTutgfxSXGr3nBMvpxNZa?=
 =?iso-8859-1?Q?SlKsW5/80tCjYcQKDp7Ki2iYz62lkRAJFt9N6VKIpO713LWG8e/TxPWLaI?=
 =?iso-8859-1?Q?YIleurF7xeLZ/sKINuNI2EcnhEdB3pet29iM2B4lddP2/Qb8///jaG/d39?=
 =?iso-8859-1?Q?BXbZ0tZDe6rQeDQfXP+02g68Jwl1LznGEkqwp8RYUVyyqzWxeHjJtujpMY?=
 =?iso-8859-1?Q?wfC6tEus7t53l/bkwSh81Am9kCckGpKF8DvfMyEXeLIZpuB+RlBhfUiz1j?=
 =?iso-8859-1?Q?t6ib42Ncn41K6LDCrEsRgPSuYMggo1EUDP3qBBop/OB/N1eODKChW0cyFQ?=
 =?iso-8859-1?Q?yidoo7xxcq41BrdDNMkMy7azWrQZhklUVMEiFt+PuD+2bhilgNLnWp+6UU?=
 =?iso-8859-1?Q?wgKF0SGiawEpXxLrs4sSdolUW1t1fYtGENQrRq9EcGNf1anB93x2xLM8U8?=
 =?iso-8859-1?Q?UsmRva6TnOmdGp642nEf/SEJyRzsv19+P30uCG2R6R4f4J30CrDYXcgru/?=
 =?iso-8859-1?Q?6E919epOKXlZhBocm/NQzICOo/Ekj5880agP6BjwMQEKJg4nDpih4vmD+j?=
 =?iso-8859-1?Q?gAe229f8RL2ncND/9VbLhhYosKKNuq3Ma5XDr3x6PMyvc1sLSuItbKcgZh?=
 =?iso-8859-1?Q?oY6DWI/ulvcL1n7tYTmvtLxUGNWsh0/WmC9dxQHP5vGOGlE6i8lsRynRUI?=
 =?iso-8859-1?Q?Acj42Th9yFj+pSM7Yl1cR+glD6KxzW6Bf5Q++VuWOuHJ9YK64TZ7KNxJox?=
 =?iso-8859-1?Q?H/HOMQfHLEpS8S5t/yqFf5eN15DD7yxjMiN3uSKQRdmNtceBzA5PFtH1QY?=
 =?iso-8859-1?Q?N7ODzYtEWJxKokvw3R+EiTTT5/RC2CRZcYIAnGbDS+YSCjIBqJ6795ibeq?=
 =?iso-8859-1?Q?vxUXe+Gnp/LauyR2OJSoDe402VDN24pzoGRcq8vZeBJKfVAcynbS7Tz+Ks?=
 =?iso-8859-1?Q?LlW9iLqHKoPDuhDtVTNkxji9AL9CVhbASWDk6nv3ahbUHqMYB5yJltL1nw?=
 =?iso-8859-1?Q?w3VDO/2avg87Avpo5FHL0lsy0MFEaiQPl41OMh3CkoTi+QVI+SNsDVH4nB?=
 =?iso-8859-1?Q?89bQpg2qsMpP36Dx3yE025qymcx8OW5RKWa02uUr+7DkybJf5dLoh1OUQu?=
 =?iso-8859-1?Q?j2LJeS4fsoxydQhLPLEjIIbS6oGBivOr2LiXljhwjAjHADkZFlNAB7pDN7?=
 =?iso-8859-1?Q?kWfVpMR/z5EDPO8P/qcxhZd9YSOtDeltjbNaIsDOh0XB2mW0KVUcxcxMum?=
 =?iso-8859-1?Q?uF1tzY8O2pnWunZ+CABUvTylUsrR9cceZUApooKaFJJN6DKyeHnZ8Vww?=
 =?iso-8859-1?Q?=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: 6a97cb4b-0c87-498a-7eb0-08dd986205a2
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2025 12:21:32.5035
 (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: 1LyT4qVVJzuMNby0PHPsV/p9iVJgNfeaFThr6ktZHWw3ZRt8r/SLrUxwoSkFRwfROw0sSt878o/z8lZ9fcY5Kw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9644

From: Oleksandr Andrushchenko 

Some of the PCI host bridges require additional processing during the
probe phase. For that they need to access struct bridge of the probed
host, so return pointer to the new bridge from pci_host_common_probe.

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykyta Poturai 
Reviewed-by: Stefano Stabellini 

---
v4->v5:
* added Stefano's RB

v3->v4:
* change return 0 to return NULL

v2->v3:
* no change

v1->v2:
* no change
---
 xen/arch/arm/include/asm/pci.h      |  5 +++--
 xen/arch/arm/pci/pci-host-common.c  | 12 ++++++------
 xen/arch/arm/pci/pci-host-generic.c |  2 +-
 xen/arch/arm/pci/pci-host-zynqmp.c  |  2 +-
 4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.=
h
index a87672d834..3d2ca9b5b0 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -18,6 +18,7 @@
 #ifdef CONFIG_HAS_PCI
=20
 #include 
+#include 
=20
 #define pci_to_dev(pcidev) (&(pcidev)->arch.dev)
=20
@@ -95,8 +96,8 @@ struct pci_ecam_ops {
 /* Default ECAM ops */
 extern const struct pci_ecam_ops pci_generic_ecam_ops;
=20
-int pci_host_common_probe(struct dt_device_node *dev,
-                          const struct pci_ecam_ops *ops);
+struct pci_host_bridge *pci_host_common_probe(struct dt_device_node *dev,
+                                              const struct pci_ecam_ops *o=
ps);
 int pci_generic_config_read(struct pci_host_bridge *bridge, pci_sbdf_t sbd=
f,
                             uint32_t reg, uint32_t len, uint32_t *value);
 int pci_generic_config_write(struct pci_host_bridge *bridge, pci_sbdf_t sb=
df,
diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host=
-common.c
index c0faf0f436..53953d4895 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -208,8 +208,8 @@ static int pci_bus_find_domain_nr(struct dt_device_node=
 *dev)
     return domain;
 }
=20
-int pci_host_common_probe(struct dt_device_node *dev,
-                          const struct pci_ecam_ops *ops)
+struct pci_host_bridge *pci_host_common_probe(struct dt_device_node *dev,
+                                              const struct pci_ecam_ops *o=
ps)
 {
     struct pci_host_bridge *bridge;
     struct pci_config_window *cfg;
@@ -217,11 +217,11 @@ int pci_host_common_probe(struct dt_device_node *dev,
     int domain;
=20
     if ( dt_device_for_passthrough(dev) )
-        return 0;
+        return NULL;
=20
     bridge =3D pci_alloc_host_bridge();
     if ( !bridge )
-        return -ENOMEM;
+        return ERR_PTR(-ENOMEM);
=20
     /* Parse and map our Configuration Space windows */
     cfg =3D gen_pci_init(dev, ops);
@@ -244,12 +244,12 @@ int pci_host_common_probe(struct dt_device_node *dev,
     bridge->segment =3D domain;
     pci_add_host_bridge(bridge);
=20
-    return 0;
+    return bridge;
=20
 err_exit:
     xfree(bridge);
=20
-    return err;
+    return ERR_PTR(err);
 }
=20
 /*
diff --git a/xen/arch/arm/pci/pci-host-generic.c b/xen/arch/arm/pci/pci-hos=
t-generic.c
index 46de6e43cc..a6ffbda174 100644
--- a/xen/arch/arm/pci/pci-host-generic.c
+++ b/xen/arch/arm/pci/pci-host-generic.c
@@ -29,7 +29,7 @@ static const struct dt_device_match __initconstrel gen_pc=
i_dt_match[] =3D
 static int __init pci_host_generic_probe(struct dt_device_node *dev,
                                          const void *data)
 {
-    return pci_host_common_probe(dev, &pci_generic_ecam_ops);
+    return PTR_RET(pci_host_common_probe(dev, &pci_generic_ecam_ops));
 }
=20
 DT_DEVICE_START(pci_gen, "PCI HOST GENERIC", DEVICE_PCI_HOSTBRIDGE)
diff --git a/xen/arch/arm/pci/pci-host-zynqmp.c b/xen/arch/arm/pci/pci-host=
-zynqmp.c
index 101edb8593..a38f2e019e 100644
--- a/xen/arch/arm/pci/pci-host-zynqmp.c
+++ b/xen/arch/arm/pci/pci-host-zynqmp.c
@@ -47,7 +47,7 @@ static const struct dt_device_match __initconstrel nwl_pc=
ie_dt_match[] =3D
 static int __init pci_host_generic_probe(struct dt_device_node *dev,
                                          const void *data)
 {
-    return pci_host_common_probe(dev, &nwl_pcie_ops);
+    return PTR_RET(pci_host_common_probe(dev, &nwl_pcie_ops));
 }
=20
 DT_DEVICE_START(pci_gen, "PCI HOST ZYNQMP", DEVICE_PCI_HOSTBRIDGE)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 21 12:21:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 12:21:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991773.1375588 (Exim 4.92)
	(envelope-from )
	id 1uHiS3-0008Bq-Qp; Wed, 21 May 2025 12:21:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991773.1375588; Wed, 21 May 2025 12: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 1uHiS3-0008Bj-Ll; Wed, 21 May 2025 12:21:39 +0000
Received: by outflank-mailman (input) for mailman id 991773;
 Wed, 21 May 2025 12:21:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHiS2-0008BY-8W
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 12:21:38 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2606::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 231c6a80-363e-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 14:21:35 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PAWPR03MB9644.eurprd03.prod.outlook.com
 (2603:10a6:102:2e3::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Wed, 21 May
 2025 12:21:33 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8746.030; Wed, 21 May 2025
 12:21: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" 
X-Inumbo-ID: 231c6a80-363e-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nedgo0dkfIFtSIA9b0orcpodUWzJSyVM39C+bLqjOPVPuKW5wnKVBidKaWGdDqAvQLgd4p88d0BLk5WKZah+VHc7TDJSZGijVC96NK2CNBk+1w5hHRAwuYP3Ze7imFs6+QYE2YpAZ800LSxKCO+Zg86W5ez7eo220bOtGBVByPkrmOx7ign4Z1ir5/SCr7v5eORyBe3LJu2HfSRuIsih53ZXfPr78JEMpY+QE+1PwWNOYWZ3e6oTsPFrdixrTY/QEJh0JBdRWfk0oLP+03AWwyJQtWJUwrnjj/CSZroyfNFaqg7O+Gb98tsLLCDzu3sb3pLmYkTlFLfC7Nc/ZJZ8Rw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ubzs8I4zULoQObgoaMItRYM4B8QCjrpSt1rCRfPQvBA=;
 b=xKqN056jKBkkzVycqE+HM9OFIjst8t2zjysHy6kK2WI+EDlH5t0Gv06K3eR4CwYkY9zi237ewXcgRmO4bQWdpz+JynrT9D5rfPC7FLQo3njdu76+CAnjTtxRUm0/1/fBcVQe4QUEoh9u31sYL3iflW0hUp2DfZp5fWwO395iSgbjo94iceWRPG1B5ODEZ1Y7iwF7vC5+rCJVNlkcWyTeWFwA0iN2xBPlnlciHJZaCxbLLRtOHmGAwWfaOPADPjly2JJttt3Po7SW4PgRG0xmfherrQ0NUaQBui7puB7fTR+r72Y0z9EHJJwi9wCubuBgEAYDEBcIPzTWVWJ7nQ4oKg==
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=Ubzs8I4zULoQObgoaMItRYM4B8QCjrpSt1rCRfPQvBA=;
 b=Zw/KIKHE/14CvbK9XywUplQwRDrN8OET28OsUJ1N4LlC2K+TCw1xyI5SGA1PX4M+364onewPaLpDXdesQHGolcipckZqG6yeXIa+jZbmM6ONHSPU2AqoLUTT4X9u25XQesgsg/sTf5kBUttA2MCVLAeIAHAfpS+IJr720ZEess6axoZDosLd3OaSgNHC2SY7of0iWfGM8AXu1FT+J33BACpY4Bhh6DlSRp5TbEagtgF4JRTtodHk7ayYqZocyZV6OXnOd5PsCcMTfw0rcox0CO4YlR94F0ehupeXGOk0YPX0/AGINsgB+N9PGGHYJ94vIgA6ZquLbS6JTscu/WmjCw==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk , Mykyta Poturai
	
Subject: [PATCH v5 3/4] xen/arm: add support for PCI child bus
Thread-Topic: [PATCH v5 3/4] xen/arm: add support for PCI child bus
Thread-Index: AQHbykrjNC7jm+FgWk6NewzRcK0EQQ==
Date: Wed, 21 May 2025 12:21:32 +0000
Message-ID:
 <5f46d2b3ef03dcc7a54f8346ba9e610002381ba2.1747820844.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: 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_|PAWPR03MB9644:EE_
x-ms-office365-filtering-correlation-id: 782ecb60-d329-466b-f8b9-08dd986205ee
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?osZIaWUyM65BTcUY3Td0nkae2b95jgRfIgxr3UVz0G7v9Dc9G3PbY1M43v?=
 =?iso-8859-1?Q?b0I11SdD3Ta7ayRvcng4Y4JnR3/S8Rg1va/zw7X7ZiW9MVe1v+ZU8x+sUj?=
 =?iso-8859-1?Q?PEuE9J9E/CNUHTpKZSM3TT0u1hCHQupALEqJulj/u47ubXarezEJHJJlh2?=
 =?iso-8859-1?Q?EM9tbaZAabfYVDIgpOvKZMTF2dMThlfNCulG06Kr0VLfqoros34+s6Zj39?=
 =?iso-8859-1?Q?VGv7yTNj1hxAELWqAUhmK8vjCvukUeYp8PDiZVZuTJPb83LG+yW6wIw2Z7?=
 =?iso-8859-1?Q?yEbzUqovdNrS9yNFqyyd112Hee+XpZ7xN9qNNIOZsEMF7JKwWkao5II16h?=
 =?iso-8859-1?Q?kcBEdIKIG3HAdUOiJMvQcNqIsNyCya+mgHyl+SmZHq6cnUJVa1MusCmduQ?=
 =?iso-8859-1?Q?T5MVBsFYcRl/X0EyLMNcyRGCdqQ6gG9QykbC2csNYwTdasajxSSI+dtbDv?=
 =?iso-8859-1?Q?MAH1Sm7Q0bP3QgtRFYoqQDZr/0Vxvm27pDMPc8iHbhWR7w7mZrGaAwNTBD?=
 =?iso-8859-1?Q?5TTsMOkSJ4tjCCAKfSKG2fVX0V1FW4+xKm+YG++9tQJoZxg/3jVtbdFMS4?=
 =?iso-8859-1?Q?vDWlv89tmU8lfPbgUkKokZVc/t0Tz/K04Pt51s5QaqNT/VPRQfiMKINO1p?=
 =?iso-8859-1?Q?tBlTZMgMTG/TTTynPrk9bzsRY1bw9PvGrLrglte87xspvIMJCsGey1H6AC?=
 =?iso-8859-1?Q?PYBUf0E2vNr1gyplY9VLhXOc44Z6eiIcylbhY0AEP1lDg5NPxK0OmWgr12?=
 =?iso-8859-1?Q?Wto/u4hw1etpDtY5hn+uGOOH9Eq+iEZ72VCja+82NSEU4cyN8VEa3i0CWt?=
 =?iso-8859-1?Q?dAmYdfcJ50x2eY/zfCH1rNkIjTYMf9VPI6t9zhl85eUmFoGvIBkWM4fdAl?=
 =?iso-8859-1?Q?wjVMWn3XkVIVHcC+s9SXurxbkmSYimvoP+9jxDnUJhdgxoA5UZX5sC041z?=
 =?iso-8859-1?Q?z+6YUE7KiARWUU1xyCszaqOyCdvMVuQ+KtIk1O+KR3iAN1R2kWE+rJyvRI?=
 =?iso-8859-1?Q?lyN+jT5eRO7rNPpQKsg7MPuY+5RZ6xvcM+TtXhapI8zZMiloTuPTWXy0mV?=
 =?iso-8859-1?Q?7ushIJL0l6cXMGLuQf5CGmqksJYnpmgv3gE++4hs/2DVjEJhyNHuMCiSDe?=
 =?iso-8859-1?Q?dFTnhrc+g+RLCYcaLqVZIkdQqGP4S6oZ/3YrrA08gBGzmXAXWertI+VctR?=
 =?iso-8859-1?Q?q9BCN5YgyxdRmyF/KOHu0VeXvPCdYn0R8MsO6/ezFT8bUMtYvJwae6qcoh?=
 =?iso-8859-1?Q?2wuS3Aygz9+1S0lofg3gFjqqb9eNxLAEDpNjJOi5Q8msoYZMMCIpcL+6je?=
 =?iso-8859-1?Q?QEb9Q1s0GbaL4aLonXI1QE4BA8uA8YBNxzbcXEi0Qp2k3xlWBlTEyjrOrT?=
 =?iso-8859-1?Q?r847SJUOHgD6gqSTBlZ9ah7e7moNbJWexZrTbvaaHFTud+q1J8i2h6G9wd?=
 =?iso-8859-1?Q?wGXujMWbZIJzGUkrF3NBl+ekwmshxHiX/tLI2e3iAuLWm4Fvq82dnmxz7v?=
 =?iso-8859-1?Q?U=3D?=
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)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?UuD+bVgad37WyEHx5DQn7RomGpTU0IgOX9K/FzVRj9Cq9ktymkQ16Y9C8h?=
 =?iso-8859-1?Q?pYsOg2i3Lve4kKr+kHQRZruSw2GfQMARhNG1l3VZq3F+6J4ErwByXe5WUP?=
 =?iso-8859-1?Q?l9Zh3Lx5Q0CaTppsBNKvRQZ/fyD2lDxG7ayQs/9P+0N1XDrm4niXKb9KFj?=
 =?iso-8859-1?Q?/TFZGNdViJQQ42PzyMQHDZORjizMx2sDArxSmFAslsRJmOzIA4H9e4x2Fx?=
 =?iso-8859-1?Q?0Hbc3lp851PIBkYefDOXske0NaMoIXr4s4Ux3ZvRVa483REHKUHBBc30mu?=
 =?iso-8859-1?Q?i5tBiTQ3HXAKVEd5aGq1AUFF1mj6yuN7EMo5uniaZftWSmmB8TTyLlfH0z?=
 =?iso-8859-1?Q?HznSUm62zWQqgVBuG5oGIpTVq0wAKIbdLq4ZTdWqQVLt+KulCulzyHLjGA?=
 =?iso-8859-1?Q?ewJcCMvKSo35LKrF0J9HxP+eNvrPvRNgRRf9McWk8sU8vIRCrr10rejCqe?=
 =?iso-8859-1?Q?9TSm9lWXhqn51IlH9vJNmvtE9FGpRlK/6bId59ooWWZWXVTCgredp3iP8/?=
 =?iso-8859-1?Q?824N45EmwgTtg3KgKGKlllcCKYF+ev2gY8TG/BkxFQh1ra3FMICvgePOby?=
 =?iso-8859-1?Q?P6horl7YlmwrRPX/DH8nNNBIJ3/6R52eb/B4Neq5pYRps+VvCE8CYUR1Zr?=
 =?iso-8859-1?Q?PgSv9EFimhyYKLj6MLzBgonlUYUjrtRSssN4d8Roc/5v116MLe8ZwPg/Nt?=
 =?iso-8859-1?Q?5EQTIs5GJW0jun6LOZgyT09TgtVH2f6VeRoPaNsAYX3OqLQFKooVcpk3et?=
 =?iso-8859-1?Q?c0+qPGeocoqElFLwhD+cQKhS3BysSFMu0RJz1SVexQCaxBhVZOaii17Naw?=
 =?iso-8859-1?Q?+brtF0zqcgINGUIkFSc0d7n3A4vPCvrG+gFIXdK3FHfoVR0+Dfvvt6QlLp?=
 =?iso-8859-1?Q?mI0zgEqNDs/uXO+8Hum+/5ZPaNzSKjsFRnXQR3adA0+y7cTpszNrl5Ms+J?=
 =?iso-8859-1?Q?Ci0yHeW9Jp5W1qGUtY3ZAdljxdn9OuDeIPmSSD5BbjBGXHMgA8MV1vY0nH?=
 =?iso-8859-1?Q?J8aEpDrtyslAMv3I5tCxtKx8dY0PQEbwbFGV8w8QlKsodyEFOIIKJY8mbp?=
 =?iso-8859-1?Q?vS4ypLEuPs74LkPsiLTtJnJr8m/k/e0M2uMCftHde73p6phM3LeMPKOquG?=
 =?iso-8859-1?Q?odqDUwF+TFFrOu7vQH6NmozB+2I2HXDlnFOpMnIwOciWEyfa1b1RLK9E+M?=
 =?iso-8859-1?Q?3YUyMfTs1/3JILDMibwO+FNxfT53mK/xRMGJ/QTMopNFJEwg7MIGG6Lw1x?=
 =?iso-8859-1?Q?X7yqky9AN/2Hg869Gxcmdo/31zX3D/OURKnUltBK6yCC+xko7HSQU2gX48?=
 =?iso-8859-1?Q?vLxarH25T1fPiby+iz+ZQO8YA7cCgJ8JFPGxXjv79ggo1jgpV7svj/rDOR?=
 =?iso-8859-1?Q?mCybSBFCqVPdF7KPfbP+s62CTFULBHkBqwT61BNRbPJoAmkzmHrd6Tt4FK?=
 =?iso-8859-1?Q?Y8RnFSoiWmsxNS/71ijE90/xgMYPPtZF0MRUrpy0ho5I05MnemneJrjOA4?=
 =?iso-8859-1?Q?lMejp0kBdTWMujBhBEo1oId1JVdG3Jr6ZY7OQxk4BCMzhMbPH51omFhNOF?=
 =?iso-8859-1?Q?uI8XspUEEHR7mD3LfB/z5+LutiuvGejZC/Pcgg7Jzn1YZYWe6A2fwOOXH6?=
 =?iso-8859-1?Q?d862FDIZqWppoIwOxxbWGSJ77olEUvKidgUTY+zshIfXE7nIMzrKlCXw?=
 =?iso-8859-1?Q?=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: 782ecb60-d329-466b-f8b9-08dd986205ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2025 12:21:32.9731
 (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: tQ7D4Ajuz+RUnpxngLTTZIqU/i2ItYcdgjibuhNI9ODh+uXtIRigBHg10IN8boPMiU4Qb7StuX8P9iKWb/YQRQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9644

From: Oleksandr Andrushchenko 

PCI host bridges often have different ways to access the root and child
bus configuration spaces. One of the examples is Designware's host bridge
and its multiple clones [1].

Linux kernel implements this by instantiating a child bus when device
drivers provide not only the usual pci_ops to access ECAM space (this is
the case for the generic host bridge), but also means to access the child
bus which has a dedicated configuration space and own implementation for
accessing the bus, e.g. child_ops.

For Xen it is not feasible to fully implement PCI bus infrastructure as
Linux kernel does, but still child bus can be supported.

Add support for the PCI child bus which includes the following changes:
- introduce bus mapping functions depending on SBDF
- assign bus start and end for the child bus and re-configure the same for
  the parent (root) bus
- make pci_find_host_bridge be aware of multiple busses behind the same bri=
dge
- update pci_host_bridge_mappings, so it also doesn't map to guest the memo=
ry
  spaces belonging to the child bus
- make pci_host_common_probe accept one more pci_ops structure for the chil=
d bus
- install MMIO handlers for the child bus for hardware domain
- re-work vpci_mmio_{write|read} with parent and child approach in mind

[1] https://elixir.bootlin.com/linux/v5.15/source/drivers/pci/controller/dw=
c

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykyta Poturai 
---
v4->v5:
* fix formatting
* move init_bus_range inside pci_ops
* fix logic error in pci_host_bridge_mappings again

v3->v4:
* remove changes to pci_ecam_map_bus
* make map_bus inline
* fix logic error in pci_host_bridge_mappings

v2->v3:
* no change

v1->v2:
* fixed compilation issues
---
 xen/arch/arm/include/asm/pci.h      | 20 ++++++-
 xen/arch/arm/pci/ecam.c             |  1 +
 xen/arch/arm/pci/pci-access.c       | 37 ++++++++++--
 xen/arch/arm/pci/pci-host-common.c  | 84 +++++++++++++++++++++-----
 xen/arch/arm/pci/pci-host-generic.c |  2 +-
 xen/arch/arm/pci/pci-host-zynqmp.c  |  3 +-
 xen/arch/arm/vpci.c                 | 91 +++++++++++++++++++++++------
 7 files changed, 194 insertions(+), 44 deletions(-)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.=
h
index 3d2ca9b5b0..1f2b74a2bb 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -67,6 +67,9 @@ struct pci_host_bridge {
     uint16_t segment;                /* Segment number */
     struct pci_config_window* cfg;   /* Pointer to the bridge config windo=
w */
     const struct pci_ops *ops;
+    /* Child bus */
+    struct pci_config_window *child_cfg;
+    const struct pci_ops *child_ops;
     void *priv;                      /* Private data of the bridge. */
 };
=20
@@ -80,6 +83,9 @@ struct pci_ops {
     bool (*need_p2m_hwdom_mapping)(struct domain *d,
                                    struct pci_host_bridge *bridge,
                                    uint64_t addr);
+    void (*init_bus_range)(struct dt_device_node *dev,
+                           struct pci_host_bridge *bridge,
+                           struct pci_config_window *cfg);
 };
=20
 /*
@@ -96,8 +102,10 @@ struct pci_ecam_ops {
 /* Default ECAM ops */
 extern const struct pci_ecam_ops pci_generic_ecam_ops;
=20
-struct pci_host_bridge *pci_host_common_probe(struct dt_device_node *dev,
-                                              const struct pci_ecam_ops *o=
ps);
+struct pci_host_bridge *
+pci_host_common_probe(struct dt_device_node *dev,
+                      const struct pci_ecam_ops *ops,
+                      const struct pci_ecam_ops *child_ops);
 int pci_generic_config_read(struct pci_host_bridge *bridge, pci_sbdf_t sbd=
f,
                             uint32_t reg, uint32_t len, uint32_t *value);
 int pci_generic_config_write(struct pci_host_bridge *bridge, pci_sbdf_t sb=
df,
@@ -130,6 +138,14 @@ int pci_host_bridge_mappings(struct domain *d);
=20
 bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
=20
+void pci_generic_init_bus_range(struct dt_device_node *dev,
+                                struct pci_host_bridge *bridge,
+                                struct pci_config_window *cfg);
+
+void pci_generic_init_bus_range_child(struct dt_device_node *dev,
+                                      struct pci_host_bridge *bridge,
+                                      struct pci_config_window *cfg);
+
 #else   /*!CONFIG_HAS_PCI*/
=20
 struct pci_dev;
diff --git a/xen/arch/arm/pci/ecam.c b/xen/arch/arm/pci/ecam.c
index 3987f96b01..c979af7302 100644
--- a/xen/arch/arm/pci/ecam.c
+++ b/xen/arch/arm/pci/ecam.c
@@ -60,6 +60,7 @@ const struct pci_ecam_ops pci_generic_ecam_ops =3D {
         .read                   =3D pci_generic_config_read,
         .write                  =3D pci_generic_config_write,
         .need_p2m_hwdom_mapping =3D pci_ecam_need_p2m_hwdom_mapping,
+        .init_bus_range         =3D pci_generic_init_bus_range,
     }
 };
=20
diff --git a/xen/arch/arm/pci/pci-access.c b/xen/arch/arm/pci/pci-access.c
index 9f9aac43d7..4a94867501 100644
--- a/xen/arch/arm/pci/pci-access.c
+++ b/xen/arch/arm/pci/pci-access.c
@@ -18,10 +18,31 @@
 #define INVALID_VALUE (~0U)
 #define PCI_ERR_VALUE(len) GENMASK(0, len * 8)
=20
+static const struct pci_ops *get_ops(struct pci_host_bridge *bridge,
+                                     pci_sbdf_t sbdf)
+{
+    if ( bridge->child_ops )
+    {
+        struct pci_config_window *cfg =3D bridge->child_cfg;
+
+        if ( (sbdf.bus >=3D cfg->busn_start) && (sbdf.bus <=3D cfg->busn_e=
nd) )
+            return bridge->child_ops;
+    }
+    return bridge->ops;
+}
+
+static inline void __iomem *map_bus(struct pci_host_bridge *bridge,
+                                    pci_sbdf_t sbdf, uint32_t reg)
+{
+    const struct pci_ops *ops =3D get_ops(bridge, sbdf);
+
+    return ops->map_bus(bridge, sbdf, reg);
+}
+
 int pci_generic_config_read(struct pci_host_bridge *bridge, pci_sbdf_t sbd=
f,
                             uint32_t reg, uint32_t len, uint32_t *value)
 {
-    void __iomem *addr =3D bridge->ops->map_bus(bridge, sbdf, reg);
+    void __iomem *addr =3D map_bus(bridge, sbdf, reg);
=20
     if ( !addr )
     {
@@ -50,7 +71,7 @@ int pci_generic_config_read(struct pci_host_bridge *bridg=
e, pci_sbdf_t sbdf,
 int pci_generic_config_write(struct pci_host_bridge *bridge, pci_sbdf_t sb=
df,
                              uint32_t reg, uint32_t len, uint32_t value)
 {
-    void __iomem *addr =3D bridge->ops->map_bus(bridge, sbdf, reg);
+    void __iomem *addr =3D map_bus(bridge, sbdf, reg);
=20
     if ( !addr )
         return -ENODEV;
@@ -78,14 +99,16 @@ static uint32_t pci_config_read(pci_sbdf_t sbdf, unsign=
ed int reg,
 {
     uint32_t val =3D PCI_ERR_VALUE(len);
     struct pci_host_bridge *bridge =3D pci_find_host_bridge(sbdf.seg, sbdf=
.bus);
+    const struct pci_ops *ops;
=20
     if ( unlikely(!bridge) )
         return val;
=20
-    if ( unlikely(!bridge->ops->read) )
+    ops =3D get_ops(bridge, sbdf);
+    if ( unlikely(!ops->read) )
         return val;
=20
-    bridge->ops->read(bridge, sbdf, reg, len, &val);
+    ops->read(bridge, sbdf, reg, len, &val);
=20
     return val;
 }
@@ -94,14 +117,16 @@ static void pci_config_write(pci_sbdf_t sbdf, unsigned=
 int reg,
                              unsigned int len, uint32_t val)
 {
     struct pci_host_bridge *bridge =3D pci_find_host_bridge(sbdf.seg, sbdf=
.bus);
+    const struct pci_ops *ops;
=20
     if ( unlikely(!bridge) )
         return;
=20
-    if ( unlikely(!bridge->ops->write) )
+    ops =3D get_ops(bridge, sbdf);
+    if ( unlikely(!ops->write) )
         return;
=20
-    bridge->ops->write(bridge, sbdf, reg, len, val);
+    ops->write(bridge, sbdf, reg, len, val);
 }
=20
 /*
diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host=
-common.c
index 53953d4895..487c545f3a 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -57,17 +57,12 @@ static void pci_ecam_free(struct pci_config_window *cfg=
)
     xfree(cfg);
 }
=20
-static struct pci_config_window * __init
-gen_pci_init(struct dt_device_node *dev, const struct pci_ecam_ops *ops)
+void __init pci_generic_init_bus_range(struct dt_device_node *dev,
+                                       struct pci_host_bridge *bridge,
+                                       struct pci_config_window *cfg)
 {
-    int err, cfg_reg_idx;
     u32 bus_range[2];
-    paddr_t addr, size;
-    struct pci_config_window *cfg;
-
-    cfg =3D xzalloc(struct pci_config_window);
-    if ( !cfg )
-        return NULL;
+    int err;
=20
     err =3D dt_property_read_u32_array(dev, "bus-range", bus_range,
                                      ARRAY_SIZE(bus_range));
@@ -82,6 +77,35 @@ gen_pci_init(struct dt_device_node *dev, const struct pc=
i_ecam_ops *ops)
         if ( cfg->busn_end > cfg->busn_start + 0xff )
             cfg->busn_end =3D cfg->busn_start + 0xff;
     }
+}
+
+void __init pci_generic_init_bus_range_child(struct dt_device_node *dev,
+                                             struct pci_host_bridge *bridg=
e,
+                                             struct pci_config_window *cfg=
)
+{
+    cfg->busn_start =3D bridge->cfg->busn_start + 1;
+    cfg->busn_end =3D bridge->cfg->busn_end;
+    bridge->cfg->busn_end =3D bridge->cfg->busn_start;
+
+    printk(XENLOG_INFO "Root bus end updated: [bus %x-%x]\n",
+           bridge->cfg->busn_start, bridge->cfg->busn_end);
+}
+
+static struct pci_config_window *__init
+gen_pci_init(struct dt_device_node *dev, struct pci_host_bridge *bridge,
+             const struct pci_ecam_ops *ops)
+{
+    int err, cfg_reg_idx;
+    paddr_t addr, size;
+    struct pci_config_window *cfg;
+
+    cfg =3D xzalloc(struct pci_config_window);
+    if ( !cfg )
+        return NULL;
+    if ( !ops || !ops->pci_ops.init_bus_range )
+        goto err_exit;
+
+    ops->pci_ops.init_bus_range(dev, bridge, cfg);
=20
     if ( ops->cfg_reg_index )
     {
@@ -208,8 +232,10 @@ static int pci_bus_find_domain_nr(struct dt_device_nod=
e *dev)
     return domain;
 }
=20
-struct pci_host_bridge *pci_host_common_probe(struct dt_device_node *dev,
-                                              const struct pci_ecam_ops *o=
ps)
+struct pci_host_bridge *
+pci_host_common_probe(struct dt_device_node *dev,
+                      const struct pci_ecam_ops *ops,
+                      const struct pci_ecam_ops *child_ops)
 {
     struct pci_host_bridge *bridge;
     struct pci_config_window *cfg;
@@ -224,7 +250,7 @@ struct pci_host_bridge *pci_host_common_probe(struct dt=
_device_node *dev,
         return ERR_PTR(-ENOMEM);
=20
     /* Parse and map our Configuration Space windows */
-    cfg =3D gen_pci_init(dev, ops);
+    cfg =3D gen_pci_init(dev, bridge, ops);
     if ( !cfg )
     {
         err =3D -ENOMEM;
@@ -242,10 +268,28 @@ struct pci_host_bridge *pci_host_common_probe(struct =
dt_device_node *dev,
         BUG();
     }
     bridge->segment =3D domain;
+
+    if ( child_ops )
+    {
+        /* Parse and map child's Configuration Space windows */
+        cfg =3D gen_pci_init(dev, bridge, child_ops);
+        if ( !cfg )
+        {
+            err =3D -ENOMEM;
+            goto err_child;
+        }
+
+        bridge->child_cfg =3D cfg;
+        bridge->child_ops =3D &child_ops->pci_ops;
+    }
+
     pci_add_host_bridge(bridge);
=20
     return bridge;
=20
+err_child:
+    xfree(bridge->cfg);
+
 err_exit:
     xfree(bridge);
=20
@@ -280,9 +324,12 @@ struct pci_host_bridge *pci_find_host_bridge(uint16_t =
segment, uint8_t bus)
     {
         if ( bridge->segment !=3D segment )
             continue;
-        if ( (bus < bridge->cfg->busn_start) || (bus > bridge->cfg->busn_e=
nd) )
-            continue;
-        return bridge;
+        if ( bridge->child_cfg && (bus >=3D bridge->child_cfg->busn_start)=
 &&
+             (bus <=3D bridge->child_cfg->busn_end) )
+            return bridge;
+        if ( (bus >=3D bridge->cfg->busn_start) &&
+             (bus <=3D bridge->cfg->busn_end) )
+            return bridge;
     }
=20
     return NULL;
@@ -348,6 +395,7 @@ int __init pci_host_bridge_mappings(struct domain *d)
     {
         const struct dt_device_node *dev =3D bridge->dt_node;
         unsigned int i;
+        bool need_mapping;
=20
         for ( i =3D 0; i < dt_number_of_address(dev); i++ )
         {
@@ -363,7 +411,11 @@ int __init pci_host_bridge_mappings(struct domain *d)
                 return err;
             }
=20
-            if ( bridge->ops->need_p2m_hwdom_mapping(d, bridge, addr) )
+            need_mapping =3D bridge->ops->need_p2m_hwdom_mapping(d, bridge=
, addr);
+            if ( !need_mapping && bridge->child_ops )
+                need_mapping =3D
+                    bridge->child_ops->need_p2m_hwdom_mapping(d, bridge, a=
ddr);
+            if ( need_mapping )
             {
                 err =3D map_range_to_domain(dev, addr, size, &mr_data);
                 if ( err )
diff --git a/xen/arch/arm/pci/pci-host-generic.c b/xen/arch/arm/pci/pci-hos=
t-generic.c
index a6ffbda174..47cf144831 100644
--- a/xen/arch/arm/pci/pci-host-generic.c
+++ b/xen/arch/arm/pci/pci-host-generic.c
@@ -29,7 +29,7 @@ static const struct dt_device_match __initconstrel gen_pc=
i_dt_match[] =3D
 static int __init pci_host_generic_probe(struct dt_device_node *dev,
                                          const void *data)
 {
-    return PTR_RET(pci_host_common_probe(dev, &pci_generic_ecam_ops));
+    return PTR_RET(pci_host_common_probe(dev, &pci_generic_ecam_ops, NULL)=
);
 }
=20
 DT_DEVICE_START(pci_gen, "PCI HOST GENERIC", DEVICE_PCI_HOSTBRIDGE)
diff --git a/xen/arch/arm/pci/pci-host-zynqmp.c b/xen/arch/arm/pci/pci-host=
-zynqmp.c
index a38f2e019e..2c4afa7a19 100644
--- a/xen/arch/arm/pci/pci-host-zynqmp.c
+++ b/xen/arch/arm/pci/pci-host-zynqmp.c
@@ -35,6 +35,7 @@ const struct pci_ecam_ops nwl_pcie_ops =3D {
         .read                   =3D pci_generic_config_read,
         .write                  =3D pci_generic_config_write,
         .need_p2m_hwdom_mapping =3D pci_ecam_need_p2m_hwdom_mapping,
+        .init_bus_range         =3D pci_generic_init_bus_range,
     }
 };
=20
@@ -47,7 +48,7 @@ static const struct dt_device_match __initconstrel nwl_pc=
ie_dt_match[] =3D
 static int __init pci_host_generic_probe(struct dt_device_node *dev,
                                          const void *data)
 {
-    return PTR_RET(pci_host_common_probe(dev, &nwl_pcie_ops));
+    return PTR_RET(pci_host_common_probe(dev, &nwl_pcie_ops, NULL));
 }
=20
 DT_DEVICE_START(pci_gen, "PCI HOST ZYNQMP", DEVICE_PCI_HOSTBRIDGE)
diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
index 0ce11ffcc5..d41aa383a8 100644
--- a/xen/arch/arm/vpci.c
+++ b/xen/arch/arm/vpci.c
@@ -8,15 +8,17 @@
 #include 
=20
 static pci_sbdf_t vpci_sbdf_from_gpa(const struct pci_host_bridge *bridge,
-                                     paddr_t gpa)
+                                     paddr_t gpa, bool use_root)
 {
     pci_sbdf_t sbdf;
=20
     if ( bridge )
     {
-        sbdf.sbdf =3D VPCI_ECAM_BDF(gpa - bridge->cfg->phys_addr);
+        const struct pci_config_window *cfg =3D use_root ? bridge->cfg
+                                                       : bridge->child_cfg=
;
+        sbdf.sbdf =3D VPCI_ECAM_BDF(gpa - cfg->phys_addr);
         sbdf.seg =3D bridge->segment;
-        sbdf.bus +=3D bridge->cfg->busn_start;
+        sbdf.bus +=3D cfg->busn_start;
     }
     else
         sbdf.sbdf =3D VPCI_ECAM_BDF(gpa - GUEST_VPCI_ECAM_BASE);
@@ -24,18 +26,14 @@ static pci_sbdf_t vpci_sbdf_from_gpa(const struct pci_h=
ost_bridge *bridge,
     return sbdf;
 }
=20
-static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
-                          register_t *r, void *p)
+static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info, register_t *r=
,
+                          pci_sbdf_t sbdf)
 {
-    struct pci_host_bridge *bridge =3D p;
-    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa);
     const unsigned int access_size =3D (1U << info->dabt.size) * 8;
     const register_t invalid =3D GENMASK_ULL(access_size - 1, 0);
     /* data is needed to prevent a pointer cast on 32bit */
     unsigned long data;
=20
-    ASSERT(!bridge =3D=3D !is_hardware_domain(v->domain));
-
     if ( vpci_ecam_read(sbdf, ECAM_REG_OFFSET(info->gpa),
                         1U << info->dabt.size, &data) )
     {
@@ -48,33 +46,86 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t *=
info,
     return 0;
 }
=20
-static int vpci_mmio_write(struct vcpu *v, mmio_info_t *info,
-                           register_t r, void *p)
+static int vpci_mmio_read_root(struct vcpu *v, mmio_info_t *info, register=
_t *r,
+                               void *p)
+{
+    struct pci_host_bridge *bridge =3D p;
+    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa, true);
+
+    ASSERT(!bridge =3D=3D !is_hardware_domain(v->domain));
+
+    return vpci_mmio_read(v, info, r, sbdf);
+}
+
+static int vpci_mmio_read_child(struct vcpu *v, mmio_info_t *info,
+                                register_t *r, void *p)
 {
     struct pci_host_bridge *bridge =3D p;
-    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa);
+    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa, false);
=20
     ASSERT(!bridge =3D=3D !is_hardware_domain(v->domain));
=20
+    return vpci_mmio_read(v, info, r, sbdf);
+}
+
+static int vpci_mmio_write(struct vcpu *v, mmio_info_t *info, register_t r=
,
+                           pci_sbdf_t sbdf)
+{
     return vpci_ecam_write(sbdf, ECAM_REG_OFFSET(info->gpa),
                            1U << info->dabt.size, r);
 }
=20
+static int vpci_mmio_write_root(struct vcpu *v, mmio_info_t *info, registe=
r_t r,
+                                void *p)
+{
+    struct pci_host_bridge *bridge =3D p;
+    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa, true);
+
+    ASSERT(!bridge =3D=3D !is_hardware_domain(v->domain));
+
+    return vpci_mmio_write(v, info, r, sbdf);
+}
+
+static int vpci_mmio_write_child(struct vcpu *v, mmio_info_t *info,
+                                 register_t r, void *p)
+{
+    struct pci_host_bridge *bridge =3D p;
+    pci_sbdf_t sbdf =3D vpci_sbdf_from_gpa(bridge, info->gpa, false);
+
+    ASSERT(!bridge =3D=3D !is_hardware_domain(v->domain));
+
+    return vpci_mmio_write(v, info, r, sbdf);
+}
+
 static const struct mmio_handler_ops vpci_mmio_handler =3D {
-    .read  =3D vpci_mmio_read,
-    .write =3D vpci_mmio_write,
+    .read =3D vpci_mmio_read_root,
+    .write =3D vpci_mmio_write_root,
+};
+
+static const struct mmio_handler_ops vpci_mmio_handler_child =3D {
+    .read =3D vpci_mmio_read_child,
+    .write =3D vpci_mmio_write_child,
 };
=20
 static int vpci_setup_mmio_handler_cb(struct domain *d,
                                       struct pci_host_bridge *bridge)
 {
     struct pci_config_window *cfg =3D bridge->cfg;
+    int count =3D 1;
=20
     register_mmio_handler(d, &vpci_mmio_handler,
                           cfg->phys_addr, cfg->size, bridge);
=20
-    /* We have registered a single MMIO handler. */
-    return 1;
+    if ( bridge->child_ops )
+    {
+        struct pci_config_window *child_cfg =3D bridge->child_cfg;
+
+        register_mmio_handler(d, &vpci_mmio_handler_child, child_cfg->phys=
_addr,
+                              child_cfg->size, bridge);
+        count++;
+    }
+
+    return count;
 }
=20
 int domain_vpci_init(struct domain *d)
@@ -105,8 +156,12 @@ int domain_vpci_init(struct domain *d)
 static int vpci_get_num_handlers_cb(struct domain *d,
                                     struct pci_host_bridge *bridge)
 {
-    /* Each bridge has a single MMIO handler for the configuration space. =
*/
-    return 1;
+    int count =3D 1;
+
+    if ( bridge->child_cfg )
+        count++;
+
+    return count;
 }
=20
 unsigned int domain_vpci_get_num_mmio_handlers(struct domain *d)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 21 12:21:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 12:21:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991777.1375620 (Exim 4.92)
	(envelope-from )
	id 1uHiS8-0000Q4-3K; Wed, 21 May 2025 12:21:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991777.1375620; Wed, 21 May 2025 12:21:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHiS7-0000OK-UL; Wed, 21 May 2025 12:21:43 +0000
Received: by outflank-mailman (input) for mailman id 991777;
 Wed, 21 May 2025 12:21:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHiS7-0008Qd-1n
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 12:21:43 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2606::60c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 26e5ef16-363e-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 14:21:41 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PAWPR03MB9644.eurprd03.prod.outlook.com
 (2603:10a6:102:2e3::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Wed, 21 May
 2025 12:21:31 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8746.030; Wed, 21 May 2025
 12:21: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" 
X-Inumbo-ID: 26e5ef16-363e-11f0-a2fa-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=AFgDtlU/gmiys/eIUJZVxrQPFzTXEq0nBg30JLgczK1pZ+r7yUVMvog2sQK4TZ/+gLBJ3Bb5KBZ6RYktLEX8MQbTLK3c8L26PEZMhhkp9il2QMe+czYJoUlEYy7sixSdY3bTKcJa+6QacNHQcGOfh7t4lu3nZLUvAXjKSHpcHGYM5LzEu9Ac2vRLskPJgJ3vm9aznpAcey0dXemXpHvwYZlbl/WdpSOTT4O5rjneOz3p3OnvjS6qpSIm44Cwq8gDPvgrnbSk0mBiJvc+1/Y6fqgnRRsu6hYWqBO+OzRbFDlwhpWPtA6PnM1tZ1z2NuB/9+YtCo7M7LPS2sJKNtafAw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0yIOmdLyF6w2oLxwUbcDWdA2217xBALXqLqQvHNKfxA=;
 b=UnwCxEj6+PIgt9199n+ABLFtk5H5sjYSGzLSBpLaptTMDXJ48R6Pz1FMAvA7dlioNBnix3BbrWQ6H843hETSPKAfTFuwqM1CtLrGh4UqCR/gO9W6IVqH7VGT2Uhf3CX5COVWTd8ICEMTX+DxXOfgirVH0oy1SpKD+/6UggO0Yk9z3bFPAdc6WzEGyL5zWUH7zgR4Bd12yNLIZrEQUhhzDL71Gz8nIqGw1Bn/VTI4bGfLUQM+jkjhhr53U0vmX0729bXx+REwMY1t0Bj+arFp2yNK7FnIJfXry2QSHsKRJrahNoCyD3KA9tNqNznLqvU5UEvKWNNdPO3PqHyMfHve9A==
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=0yIOmdLyF6w2oLxwUbcDWdA2217xBALXqLqQvHNKfxA=;
 b=CyKzxE45csirnsQIn0tuXSRuoBxohn+c3W8VXZJoU1T+bn1GUUilAsMYtB+dMy1X6MxakrSrwa8wSIc5kcKHFtmA2EVArSp5NQHoWAY/v1AmYoUNMyiV7EXGw9Cq5N6QF7YkJfrASy5T5BGk08VDUyTTOCrf4IUWlrrwX1aw7zTWkJQXsvwEPudShQP4BvFNfhjFZSlG52kuI01tWSRfYLr5/a72Es1OwuQMzluNEocVhZK8cqGMjd6nj5Ei0Cf0L/R4/JDlvcKDyah42WpURnyLEKLVplDQuSg9TXQ3Vygfxn+oUC+R4Ft1fC85LELt/pf/zoNC5RLLhM5dAr/fYw==
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?=
	
Subject: [PATCH v5 0/4] Add support for R-Car Gen4 PCI host controller
Thread-Topic: [PATCH v5 0/4] Add support for R-Car Gen4 PCI host controller
Thread-Index: AQHbykri8+u9hNG+1kmy/z9Y016O8A==
Date: Wed, 21 May 2025 12:21:31 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|PAWPR03MB9644:EE_
x-ms-office365-filtering-correlation-id: f88e3e95-eafd-47f6-9543-08dd98620526
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?7SytwQKlAhubC9RDREMwfric3YReZ3vzQKP0dD/as3B53XE4Cxv3xw8I6T?=
 =?iso-8859-1?Q?VCvBTkPZSyVJYIGNh2nnL+wW4w8e83zUQh4kOe4qilTgDk4Nyz29mjsTeq?=
 =?iso-8859-1?Q?rYjYdpX1nx7UiQtpb9N6XIf/pFCZ4tjo52HVL5HMH2o5GzktiMDF14lQW4?=
 =?iso-8859-1?Q?BTdCwosjUccj+atLaR5td29HdgZo6DeZS01YmS1bgy9kL1zzRzaKYwJtoc?=
 =?iso-8859-1?Q?g7C4eKHAcWlq2VbJxdaQfQ+FC/AIJNuUHSs2PRGLkOQ6Wg+uYwpU5+Nb9w?=
 =?iso-8859-1?Q?Zk28EHtbUVpdsJh0RqVyubqUvWsrp2Jv0M5yemhToNTjIcoEsbn1EZXdZE?=
 =?iso-8859-1?Q?cWU5WbThAShlkw09/A1V6isj6mXkX3SfBRu0f5J1MRkOd5j3i4edgymHMJ?=
 =?iso-8859-1?Q?misuSEoSWK31RyazxxqJUekq2w4xlufbcNXbmi2Nc+brvM5SEVIOieR5ku?=
 =?iso-8859-1?Q?9WfgbtegYbJn9gS+lvwEULJgJJO3ZwkM6pmuejpad0aZaioQOIdvgC2T5G?=
 =?iso-8859-1?Q?KzhEv5n0BZnnleVgS+WIH8gT0ksVR89tUihE133EUjgZEULVWzE/Vx6R/I?=
 =?iso-8859-1?Q?TwVaBed1RL+LsVyIjsSAS12aIORxy6sZpWR+36GYZCZXg4k4AbBfhFfQTm?=
 =?iso-8859-1?Q?s+EHYy+9qccp6VRnUb3BfConRC89qBkiqxGqzu+3XMd2zUBv/mmKSKR5cB?=
 =?iso-8859-1?Q?tXnrcguIZt2elA3pNAqpSz/pXllvWU4ZTLenBuPSWHyEXY1EVC4ynI2vUR?=
 =?iso-8859-1?Q?gZjCJK75KUZqjckB1bT7ls19wVxJs3bZoavz3TTEWgN3ekv8EAuwjFNQP/?=
 =?iso-8859-1?Q?ZlX5ladbz1OdVMucgsPxQI2aM5uovdp313BTMM5erqUI1WxDiodEp2vh4z?=
 =?iso-8859-1?Q?GetziBl4go6CR7daui9jUO5Zxef3ORks/0T87bwBCXo81DcCAoQ1KtAWJb?=
 =?iso-8859-1?Q?g8IXT2GPAMljuPLwQgocbPDOJP856eIVF80X1jyhOmpphB/gnKakOuN+dL?=
 =?iso-8859-1?Q?QcvynFPCw28a2kV6ukaUs9LKb8PzodGshETpnHXIUHWSN/1VoXG6dm8FhH?=
 =?iso-8859-1?Q?TQukrSErI+BLjWMeFsASuqrEH4hbWol/cJ5m9eV60i+u5cOLeonTkGU2mb?=
 =?iso-8859-1?Q?3wIpdsCN+L9iUClbVgPfk3QmtZDwIzezDTqQs1g60NrmAuozVcWlqjA28k?=
 =?iso-8859-1?Q?cMottq8+oBKP38JJlyR2WxO1pShoQSQTK2b3hoouHxAWf7pnwWB9xctTTy?=
 =?iso-8859-1?Q?KITN8KEUh1U+5WGiWB4BWleuX83e3I2uuHS38D7X4Lb6NF5S3vQjkqFbQi?=
 =?iso-8859-1?Q?lS5JG/dXDwrc+9Yo6p5beE4gforhL1UparP973hznAFRdDj1T7TRItotCt?=
 =?iso-8859-1?Q?xL5CQl5op51wa31EKdWVTsMfyWWcWAOAQTIC0CbCzfvRyvaEESEIlKMuiV?=
 =?iso-8859-1?Q?oOb0p7jxr7P4zIj3Odpmc/kOoTSGR/3kFt3wV/+ghfbX/bW5fHMMEjY3EE?=
 =?iso-8859-1?Q?g=3D?=
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)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?yFgKQuXndxXomhoXpc+QYZS4jurmpIuH6MztRvPG40UALmHkWZrKf5CmFW?=
 =?iso-8859-1?Q?Nfy1P3GHvN48OLzAe5k5Kir5pTw7xJuf7qtRxoyjkJcI8PeN4j5I2lxCmd?=
 =?iso-8859-1?Q?zm+nCnGc8w1Oi8M4+OKHluQOoY142Jg5NbGns781gJ1xr5E39MYMw8HUQd?=
 =?iso-8859-1?Q?Py6WRb/erPEdxxxA1MxmJOP/FCPs5oop0NkIveN4h/c/9xgwhAREARXDG2?=
 =?iso-8859-1?Q?y7MuOPD2Sh7vUglQcORBrb1K8My5T/mhIjjMMF8sxjq/bEDELXKtV3MMmk?=
 =?iso-8859-1?Q?xPSVG+7TuAJMzzrEdpLeD8S8ZF7AjmWd2O8DxXuH1cRYx/hJgTLvGRhYJl?=
 =?iso-8859-1?Q?q0J0HMxBhCsQofjaqyLR7d85N2K9LPQQQblQM8BSxnvs7pwqJZTtPRfqWF?=
 =?iso-8859-1?Q?pNr5U13B8vJQPV6LdZCqq/DDBfvMeeOtCcp4UuoTRsIGv7f1FX80+bKk2S?=
 =?iso-8859-1?Q?B5mebVY9JlFT4tN0ulsCkam0lSCw9nFkNhLbHgWc4c6mim3pkH7DxlaSgL?=
 =?iso-8859-1?Q?6N2yZXVKkQGWpS8IF+rF2ctTpbEUIhQf0RMopqbuVT/e2num9Ksi94sNtn?=
 =?iso-8859-1?Q?g7NNq1hHRShVin0Yb/CapiRW9zoiUnwQi7cq/1Rum5VeXNiBs/gdfitQwF?=
 =?iso-8859-1?Q?QjcqpZ7TUXD63GBASxT/JWuyY/Q1AQo/fgAbEhvet06picJaUs10VhZ9Ub?=
 =?iso-8859-1?Q?10A80koLng9hD6k9e+mFL7T4e0YGQJjm864QGJ/3xXClFftZRSDMJwWQfF?=
 =?iso-8859-1?Q?olrB93wZml3LNR2gqF+rRs3RBUGkAWxA20HZVVbIw9yTJyxPN64gWatTc0?=
 =?iso-8859-1?Q?YoPgb5/j/QsQno2dZ9hO2lvV+I0Ve/oQ/fAdK9aZIyHbDHVca7QyKMVc1Q?=
 =?iso-8859-1?Q?FpZVoXWJ8m86GWcy3vYC4y8yW7uJobnSp9+ISd2dhObfEq5TvYegl13zm1?=
 =?iso-8859-1?Q?3kOC2Ela43Ih7fkXMYd/nf2gKvTj0h4BVfgmznxhDF0pGG6vGl16oKCJ3W?=
 =?iso-8859-1?Q?zAta5wFyi1avRHL7eDB3mryzhrPy4GLAt/0UN2KGu5Vm/nPfUDb9t/PopE?=
 =?iso-8859-1?Q?ChB7lSEoFEa9YfUIz/sh83BzrqPVtsXVev+NFJLMM0RsjkcSZ6uacm+jNd?=
 =?iso-8859-1?Q?geFfbiJBkTjNHUJ+mK+B0Lc6YlcA1bwKzdUKYDuag4ehjQUgf6H1LCGqyp?=
 =?iso-8859-1?Q?wbVyzk/lMDcIj6zrt2WJzKyCf82KDFiH5XnAOI+UNFnoMCIQG4kp+rIlHd?=
 =?iso-8859-1?Q?WEKJ5++iZwDhhjeZtwx2mMpC7haFE0wg0FFDSOmmjdcU8JfNsUg5g1/Pgj?=
 =?iso-8859-1?Q?yLktFZ+rE64hbZvDRr1zbpd/YszX7z/qpmeSLx9FJ2k5htCEflxhjZu/OR?=
 =?iso-8859-1?Q?ylIgaYzBtk8ZpmSSuwBLdB9kWRQNI+XyE+acTffdVJllS2/klxkPAnytsZ?=
 =?iso-8859-1?Q?sZfeCS9IIj/mDs9TnJvwgTAvdr3yROGuKEhRBjDOGCwm/KclLoB9ZowmmV?=
 =?iso-8859-1?Q?0eDnRgEVRi9/5PnUTup56WnIYM3HWFK4TpauwHtFmvCsIB6bqJACtxWwjG?=
 =?iso-8859-1?Q?tYc7xSaNN++U+ORq7RdVW8HtW6Wz9Y3fZzJNCUXbfmHVUA65CoI4Dsd915?=
 =?iso-8859-1?Q?MzvHoRqsfToapsffZLRjbdvfpaUpsP/hvipqfbdyw7/9W+6t0lTBTb7Q?=
 =?iso-8859-1?Q?=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: f88e3e95-eafd-47f6-9543-08dd98620526
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2025 12:21:31.6781
 (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: /qEoycf06iLsj7P6UeMTtv2DoZGwdEvhVHQBOBlei2B/aJQMf3NQEaJ+IGKZ6BNgu+76ddMaT3TNOUMxmIJrHg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB9644

This series adds support for R-Car Gen4 PCI host controller.

To fully support the controller, the following changes were made:
- Generic mechanism to support PCI child buses is added.
- Private data for PCI host bridge and means to access it are added.

The series was tested as a part of the pci-passthrough patches[1] and
build-tested standalone with enabled HAS_PCI and HAS_VPCI.
CI pipeline results: [2]

[1]: https://github.com/Deedone/xen/tree/pci_passthrough_wip
[2]: https://gitlab.com/xen-project/people/mpoturai/xen/-/pipelines/1828720=
661

v4->v5:
* see individual patches

v3->v4:
* rebase
* see individual patches

v2->v3:
* dropped patches related to ATU programming delay
* improved formatting

v1->v2:
* see individual patches

Oleksandr Andrushchenko (4):
  xen/arm: allow PCI host bridge to have private data
  xen/arm: make pci_host_common_probe return the bridge
  xen/arm: add support for PCI child bus
  xen/arm: add support for R-Car Gen4 PCI host controller

 MAINTAINERS                         |   6 +
 xen/arch/arm/include/asm/pci.h      |  22 +-
 xen/arch/arm/pci/Makefile           |   2 +
 xen/arch/arm/pci/ecam.c             |   1 +
 xen/arch/arm/pci/pci-access.c       |  37 ++-
 xen/arch/arm/pci/pci-designware.c   | 416 ++++++++++++++++++++++++++++
 xen/arch/arm/pci/pci-designware.h   |  90 ++++++
 xen/arch/arm/pci/pci-host-common.c  |  92 ++++--
 xen/arch/arm/pci/pci-host-generic.c |   2 +-
 xen/arch/arm/pci/pci-host-rcar4.c   |  94 +++++++
 xen/arch/arm/pci/pci-host-zynqmp.c  |   3 +-
 xen/arch/arm/vpci.c                 |  91 ++++--
 12 files changed, 808 insertions(+), 48 deletions(-)
 create mode 100644 xen/arch/arm/pci/pci-designware.c
 create mode 100644 xen/arch/arm/pci/pci-designware.h
 create mode 100644 xen/arch/arm/pci/pci-host-rcar4.c

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 21 12:22:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 12:22:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991804.1375636 (Exim 4.92)
	(envelope-from )
	id 1uHiSh-0002CD-DA; Wed, 21 May 2025 12:22:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991804.1375636; Wed, 21 May 2025 12: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 1uHiSh-0002C4-AR; Wed, 21 May 2025 12:22:19 +0000
Received: by outflank-mailman (input) for mailman id 991804;
 Wed, 21 May 2025 12:22:17 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uHiSf-0002AS-RS
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 12:22:17 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uHiSb-005xgv-25;
 Wed, 21 May 2025 12:22:13 +0000
Received: from [15.248.2.235] (helo=[10.24.67.107])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uHiSb-004sVd-0j;
 Wed, 21 May 2025 12:22: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=Q6gBuWcqa8fMdyDHTqMr15KjwjEp6whhjX4rOKLYeY0=; b=3FjVJM9W1UUZKnCXfslOOzQEn/
	dGWtk8DbylqSCjFJTSu7Drp4gfizlA1v2dMAJ6HmZUSKy4nylnOb+Bg8KJDcvXkojdntMvCMDKHIK
	If4WvqJ3T7jrMzT9s/ojkmOa8/d/LuugDXWHFxnE6qY9kJhgV0J+oOdvJkbpD8vrPA8A=;
Message-ID: 
Date: Wed, 21 May 2025 13:22:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: xen/arm: Virtio-PCI for dom0less on ARM
Content-Language: en-GB
To: "Edgar E. Iglesias" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 "Edgar E. Iglesias" 
Cc: xen-devel@lists.xenproject.org
References: 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Edgar,

Thanks for the write-up.

On 20/05/2025 09:04, Edgar E. Iglesias wrote:
> Hi all,
> 
> Following up on the ARM virtio-pci series I posted a while back ago.
> 
> There have been some concerns around the delayed and silent apperance of
> devices on the ECAM area. The spec is not super clear wether this is OK or
> not but I'm providing some references to the PCI specs and to some real cases
> where this is used for FPGAs.
> 
> There are two options how to implement virtio-pci that we've discussed:
> 1. VPCI + IOREQ
> 2. IOREQ only
> 
> There are pros and cons with both. For example with #1, has the benefit that
> we would only have a single PCIe RC (in Xen) and we could emulate a hotplug
> capable expansion port with a standard way to notify when PCI devices plug in.
> Approach #2 has the benefit that there is (almost) no additional complexity
> or code added to Xen, almost everything lives outside.
> IMO, both options have merit and both could co-exist.
 > > For dynamic xl flows, options #2 already works without 
modifications to Xen.
> Users need to pass the correct command-line options to QEMU and a device-tree
> fragment with the pci-generic-ecam-host device.

IIUC, in approach #2, QEMU will emulate the host controller. In Xen, we 
also support multiple IOREQ servers. For instance IOREQ A may emulate a 
GPU device, whereas IOREQ B could emulate a disk. This is usuful in case 
where one may want a separate domain to handle GPUs.

With the approach #2, it sounds like you will end up to have one host 
controller per IOREQ server. The user will also need to know them in 
advance. Is my understanding correct? If so, then it feels like this is 
defeating the purpose of IOREQ.

This is the first reason why I feel approach #1 is more suitable.

> 
> For static dom0less flows, we can do the same as for xl flows but we have the
> additional problem of domU's PCI bus enumeration racing with QEMU.
> On x86, when domU's access a memory range that has not yet got IOREQ's
> connected to it, the accesses succeeds with reads returning 0xFFFFFFFF and
> writes ignored. This makes it easy for guests to wait for IOREQ devices to
> pop up since guests will find an empty bus and can initiate a rescan later
> when QEMU attaches. On ARM, we trap on these accesses.
> > If we on ARM add support for MMIO background regions with a default 
read value,
> i.e mmio handlers that have lower priority than IOREQs and that are
> read-const + writes-ignored, we could support the same flow on ARM.
> This may be generally useful for other devices as well (e.g virtio-mmio or
> something else). We could also use this to defer PCI enumeration.

Regardless what I wrote above, if we are going down the route of 
returning 0xFFFFFFFF, I would just do it for every IOs rather than the 
one specify in the device-tree. This could still behind a per-domain 
option, but it would at least make simpler to setup the system (AFAIU, 
in your current proposal, we would need to specify the range in multiple 
places).

> 
> So the next versions of this series I was thinking to remove the PCI specifics
> and instead add FDT bindings to ARM dom0less enabling setup of user
> configurable (by address-range and read-value) background mmio regions.
> Xen would then support option #2 without any PCI specifics added.
> 
> Thoughts?
> 
> Cheers,
> Edgar
> 
> # References to spec
> 
> PCI express base specification:
> 7.5.1.1.1 Vendor ID Register (Offset 00h)
> The Vendor ID register is HwInit and the value in this register identifies the manufacturer of the Function. In keeping with
> PCI-SIG procedures, valid vendor identifiers must be allocated by the PCI-SIG to ensure uniqueness. Each vendor must
> have at least one Vendor ID. It is recommended that software read the Vendor ID register to determine if a Function is
> present, where a value of FFFFh indicates that no Function is present.
> 
> PCI Firmware Specification:
> 3.5 Device State at Firmware/Operating System Handoff
> Page 34:
> The operating system is required to configure PCI subsystems:
>  During hotplug
>  For devices that take too long to come out of reset
>  PCI-to-PCI bridges that are at levels below what firmware is designed to configure
> 
> Page 36:
> Note: The operating system does not have to walk all buses during boot. The kernel can
> automatically configure devices on request; i.e., an event can cause a scan of I/O on demand.

I am not sure why you quote this. To me it reads like this is up to the 
OS to decide when to access the PCI bus. As we don't control the OS, 
this doesn't seem a behavior Xen can rely on.

> 
> FPGA's can be programmed at runtime and appear on the ECAM bus silently.
> An PCI rescan needs to be triggered for the OS to discover the device:
> Intel FPGAs:
> https://www.intel.com/content/www/us/en/docs/programmable/683190/1-3-1/how-to-rescan-bus-and-re-enable-aer.html

To clarify, you are saying the ECAM bus may be completely empty (e.g. 
everything is reading as ~0) and some part of the ECAM will return a non 
~0 value when the FPGA run.

That said, the FPGA behavior is IMHO slightly different. I would expect 
for FPGA, one would now when the device is present because they would 
have programmed the FPGA. In our case, we are trying to solve a race 
introduce by Xen (not the user itself). So it feels wrong to ask the 
user to "probe in a loop until it works".

This is the other reason why the approach #1 looks more appealing to me.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 21 13:02:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 13:02:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991853.1375647 (Exim 4.92)
	(envelope-from )
	id 1uHj5k-0000By-Cd; Wed, 21 May 2025 13:02:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991853.1375647; Wed, 21 May 2025 13:02: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 1uHj5k-0000Br-9s; Wed, 21 May 2025 13:02:40 +0000
Received: by outflank-mailman (input) for mailman id 991853;
 Wed, 21 May 2025 13:02:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHj5i-0000A1-89
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 13:02:38 +0000
Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com
 [2607:f8b0:4864:20::c33])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ddbd589c-3643-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 15:02:36 +0200 (CEST)
Received: by mail-oo1-xc33.google.com with SMTP id
 006d021491bc7-606668f8d51so4551214eaf.0
 for ; Wed, 21 May 2025 06:02: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" 
X-Inumbo-ID: ddbd589c-3643-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747832555; x=1748437355; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tbPvxJsYqO9VIz9CrM76HReyKaSvx4EtXbJhhPkxMcU=;
        b=OEaVYWznCyo/6vIjYhPcL+weS98aRJhMrqikHciroO/RNvfJEmWWz/8Vpdc5p3NyQL
         1cXHWeXXrQFSXVyBh2SiEaLOoM6dvdebuggo5YyKH3S/O1U8kQ7WrwytKCHluho/Y3EG
         6Vsv2yZrgZOGUIDVWsCXIiD581Ke90inEXzlpEgqmY6bm2XdWN9nedV57tLZyHIjgaiG
         rVLR4x0NcnsYBNVU1Qvg+Ge2tVKcrpFlf+B4P0LKZLKuwEo2SLlc7S6jqY96ffIq14p9
         NrJSkgvkQXnQbdycH2b//dRhrMfyQm08VHOkj+FFnQpa3ztWvt51/gsIDeCLD4sJeQVQ
         g3dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747832555; x=1748437355;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=tbPvxJsYqO9VIz9CrM76HReyKaSvx4EtXbJhhPkxMcU=;
        b=Vp5glBL833VoCTXz3JQbvj/t9Qeg7a7AY7EW952lfBPI0kAJahHE2YlWWS6qPAXAGZ
         4K6FtylPj7RKh4/npWtJlpRRBvZ/ul9IVGbUDffpaQ4H4sQogEFwTR7L0cIxYFIh3Q3U
         uXbgOCezcrs0L0Pf6lpuhdsuogsEAVFsTIFPm2dD3Rum4nJ6sd0s4/lH/P9hHecwkgyb
         s5KJVkdWhhVFrEeHO/9Tz2RaWcP3StafgGH8bQWs5A9EOec4oDrRvGEspvRkEmvwtPQU
         VGfWQYgIEO2jFTyNKBwfJqjZ5C87zYhNDcbR/hegyyPMqfrVsFekGHKZYfy9ySdLK6Ln
         EThw==
X-Gm-Message-State: AOJu0Yzh/fCmTRXDrymXoOarJSSD+NwwxlNJ9j+IKC3Ff2/BD0K3HtjW
	OPCn0Tp+ZRm2toT57csFhiDLbryH5/z3C+EhHyTBP+t0PGG1rP7nfMmFjZU5L/ZQg+ecPxQDqGn
	4KqZ4uz+/pAdV8sAu7K9/CArkI/182boHgNyHa3XWJg==
X-Gm-Gg: ASbGnct0J5YMIG3D0+IlIPUCnzDlIcDThVjQBZpbVfVPt1e4GfodDstbKE94h0XfoHh
	MmaWYcRKC0a/I5BM9FjbvFB43M93rpyVJCIE84Zb0mltvjX5flWnI2H956t6bOf1OE6zAzDslr9
	d9zy4ilLSnhk/KFtOCi0pmPjsAS548BqsStiQABHa8gokr
X-Google-Smtp-Source: AGHT+IHLS9kVfRJjJ6GhjbHQv1OYPWZb0gmaPIUnt9wwPTczl8jUe8gKaoG+0D8VK9lOjJlprsMte8MZ/guvt8SYl2I=
X-Received: by 2002:a05:6820:12f:b0:609:ef1e:4960 with SMTP id
 006d021491bc7-609ef1e49f9mr10504184eaf.4.1747832553928; Wed, 21 May 2025
 06:02:33 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Jens Wiklander 
Date: Wed, 21 May 2025 15:02:22 +0200
X-Gm-Features: AX0GCFtaWAT9FprTmyhhiOwVYIecuOU2tVz41OK7aVPzNdW-YkjbElwx0SZW6pM
Message-ID: 
Subject: Re: [PATCH v5 1/6] xen/arm: Create tee command line parameter
To: Bertrand Marquis 
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 , Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bertrand,

On Wed, Apr 16, 2025 at 9:40=E2=80=AFAM Bertrand Marquis
 wrote:
>
> Add a new command line parameter "tee=3D" to be used to explicitly select
> what tee mediator is to be used by Xen and fail if it does not exist
> or the probe function for it failed.
>
> Without specifying which tee is to be used, Xen will use the first one
> for which the probe function succeeds which depends on the order of the
> mediator list which depends on the compiler.
> Using the command line argument, it is now possible to explicit request
> a specific TEE mediator and panic on boot if it is not available.
>
> Signed-off-by: Bertrand Marquis 
> ---
> Changes in v5:
> - Typo fix and rewording in command line doc (Julien)
> - fix include order in tee.c (Julien)
> - use a local bool instead of retesting the string each time in tee_init
>   (Julien)
> Changes in v4:
> - None
> Changes in v3:
> - Properly classify tee as arm specific (Jan)
> Changes in v2:
> - Patch introduced to add a command line selection of the TEE
> ---
>  docs/misc/xen-command-line.pandoc  | 14 +++++++++++++
>  xen/arch/arm/include/asm/tee/tee.h |  4 ++++
>  xen/arch/arm/tee/tee.c             | 32 ++++++++++++++++++++++++++++++
>  3 files changed, 50 insertions(+)

Looks good.
Reviewed-by: Jens Wiklander 

Cheers,
Jens

>
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-li=
ne.pandoc
> index 89db6e83be66..472de1911363 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2651,6 +2651,20 @@ Specify the per-cpu trace buffer size in pages.
>
>  Flag to enable TSC deadline as the APIC timer mode.
>
> +### tee (arm)
> +> `=3D `
> +
> +Specify the TEE mediator to be probed and use.
> +
> +The default behaviour is to probe all TEEs supported by Xen and use
> +the first one successfully probed. When this parameter is passed, Xen wi=
ll
> +probe only the TEE mediator passed as argument and boot will fail if thi=
s
> +mediator is not properly probed or if the requested TEE is not supported=
 by
> +Xen.
> +
> +This parameter can be set to `optee` or `ffa` if the corresponding media=
tors
> +are compiled in.
> +
>  ### tevt_mask
>  > `=3D `
>
> diff --git a/xen/arch/arm/include/asm/tee/tee.h b/xen/arch/arm/include/as=
m/tee/tee.h
> index 0169fd746bcd..15d664e28dce 100644
> --- a/xen/arch/arm/include/asm/tee/tee.h
> +++ b/xen/arch/arm/include/asm/tee/tee.h
> @@ -55,6 +55,9 @@ struct tee_mediator_desc {
>      /* Printable name of the TEE. */
>      const char *name;
>
> +    /* Command line name of the TEE (to be used with tee=3D cmdline opti=
on) */
> +    const char *cmdline_name;
> +
>      /* Mediator callbacks as described above. */
>      const struct tee_mediator_ops *ops;
>
> @@ -77,6 +80,7 @@ void tee_free_domain_ctx(struct domain *d);
>  static const struct tee_mediator_desc __tee_desc_##_name __used     \
>  __section(".teemediator.info") =3D {                                  \
>      .name =3D _namestr,                                               \
> +    .cmdline_name =3D #_name,                                         \
>      .ops =3D _ops,                                                    \
>      .tee_type =3D _type                                               \
>  }
> diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c
> index 3f65e45a7892..8501443c8e57 100644
> --- a/xen/arch/arm/tee/tee.c
> +++ b/xen/arch/arm/tee/tee.c
> @@ -18,6 +18,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -25,6 +26,10 @@
>  extern const struct tee_mediator_desc _steemediator[], _eteemediator[];
>  static const struct tee_mediator_desc __read_mostly *cur_mediator;
>
> +/* Select the TEE mediator using a name on command line. */
> +static char __initdata opt_mediator[16] =3D "";
> +string_param("tee", opt_mediator);
> +
>  /*
>   * TODO: Add function to alter Dom0 DTB, so we can properly describe
>   * present TEE.
> @@ -80,15 +85,42 @@ uint16_t tee_get_type(void)
>  static int __init tee_init(void)
>  {
>      const struct tee_mediator_desc *desc;
> +    bool select_mediator =3D strcmp(opt_mediator, "");
> +
> +    if ( select_mediator )
> +        printk(XENLOG_INFO "TEE Mediator %s selected from command line\n=
",
> +               opt_mediator);
>
> +    /*
> +     * When a specific TEE is selected using the 'tee=3D' command line
> +     * argument, we panic if the probe fails or if the requested TEE is =
not
> +     * supported.
> +     */
>      for ( desc =3D _steemediator; desc !=3D _eteemediator; desc++ )
>      {
> +        if ( select_mediator &&
> +             strncmp(opt_mediator, desc->cmdline_name, sizeof(opt_mediat=
or)) )
> +            continue;
> +
>          if ( desc->ops->probe() )
>          {
>              printk(XENLOG_INFO "Using TEE mediator for %s\n", desc->name=
);
>              cur_mediator =3D desc;
>              return 0;
>          }
> +        else if ( select_mediator )
> +        {
> +            panic("TEE mediator %s from command line probe failed\n",
> +                  opt_mediator);
> +            return -EFAULT;
> +        }
> +    }
> +
> +    if ( select_mediator )
> +    {
> +        panic("TEE Mediator %s from command line not supported\n",
> +              opt_mediator);
> +        return -EINVAL;
>      }
>
>      return 0;
> --
> 2.47.1
>


From xen-devel-bounces@lists.xenproject.org Wed May 21 13:12:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 13:12:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991861.1375657 (Exim 4.92)
	(envelope-from )
	id 1uHjFM-0001z1-8F; Wed, 21 May 2025 13:12:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991861.1375657; Wed, 21 May 2025 13: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 1uHjFM-0001yu-5T; Wed, 21 May 2025 13:12:36 +0000
Received: by outflank-mailman (input) for mailman id 991861;
 Wed, 21 May 2025 13:12:35 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uHjFL-0001yo-Mk
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 13:12:35 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uHjFL-005yf1-0D;
 Wed, 21 May 2025 13:12:34 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uHjFK-005USJ-1q;
 Wed, 21 May 2025 13:12: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=IXsdIHjx3NsnQcBO8ZJhdJ31Takj+JFk4b7Uzzyu7fc=; b=VAxRwJ9AGEzcXcaVArplwPTXXo
	PnSKfUlm9FSmuBdTapzCgFHOV+xS3tViEx5l/9Dd/UMpM71OpBDvAM1Cz040WatYek/cfKpPqhQQw
	XGDiOcLuMyfJjktKuZt2b2BLVrj2i6PbsO5/bHO0sfNOnQwx0qCY77YaQ7ZbaCSsDrjU=;
Date: Wed, 21 May 2025 15:12:32 +0200
From: Anthony PERARD 
To: Jason Andryuk 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [PATCH v2] tools/libxl: Only access legacy altp2m on HVM
Message-ID: 
References: <20250513154419.27860-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250513154419.27860-1-jason.andryuk@amd.com>

On Tue, May 13, 2025 at 11:44:19AM -0400, Jason Andryuk wrote:
> Only access the HVM union b_info->u.hvm on HVM guests.  The union
> access is not guarded, so this reads and sets the default even on
> non-HVM guests.  Usually this doesn't matter as PV and PVH unions are
> smaller and zero-initialized, but the zero default will be re-written as
> a -1 boolean.  Generally, it could incorrectly set b_info->altp2m
> through aliased data.
> 
> Fixes: 0291089f6ea8 ("xen: enable altp2m at create domain domctl")
> Signed-off-by: Jason Andryuk 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed May 21 13:31:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 13:31:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991872.1375667 (Exim 4.92)
	(envelope-from )
	id 1uHjXl-0004ww-Rp; Wed, 21 May 2025 13:31:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991872.1375667; Wed, 21 May 2025 13: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 1uHjXl-0004wp-Ov; Wed, 21 May 2025 13:31:37 +0000
Received: by outflank-mailman (input) for mailman id 991872;
 Wed, 21 May 2025 13:31:36 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uHjXk-0004wi-Kb
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 13:31:36 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uHjXk-005z0l-0p;
 Wed, 21 May 2025 13:31:36 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uHjXj-005iVa-1x;
 Wed, 21 May 2025 13:31: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=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=AYgMM8TTWykfG7/hepnajJiNI4TqFpZRrRvK14NRjSQ=; b=7AhSisHwENZhf894PMILYQTZTn
	NA4nPdxCiviBMR22e66GMcM4NwCtxwSY55CiaDIU9tm4qFBrNYxg/xkM8d1kys1j5Xog3N5AjyKl0
	cIV7DePnBSKTZqjEwqS+SbQhOb15mKkNj35lV5l4ucTWRPv/Z7aL6408l4QvtQy5MqPY=;
Date: Wed, 21 May 2025 15:31:33 +0200
From: Anthony PERARD 
To: Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [PATCH] libxl+hvmloader: extend IGD check part 2
Message-ID: 
References: <20250408132333.1524246-2-marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250408132333.1524246-2-marmarek@invisiblethingslab.com>

On Tue, Apr 08, 2025 at 03:23:13PM +0200, Marek Marczykowski-Grecki wrote:
> Consider also "Display controller" an IGD, not only "VGA compatible
> controller" in few more places.
> 
> Fixes: 4191619e0893 ("libxl: extend IGD check")
> Signed-off-by: Marek Marczykowski-Grecki 
> ---
> Do you prefer this to be split into two patches (libxl, hvmloader)?
> 
>  tools/firmware/hvmloader/pci.c | 1 +
>  tools/libs/light/libxl_pci.c   | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index c3c61ca060a6..1ee97a5b4b20 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -173,6 +173,7 @@ void pci_setup(void)
>          switch ( class )
>          {
>          case 0x0300:
> +        case 0x0380:
>              /* If emulated VGA is found, preserve it as primary VGA. */
>              if ( (vendor_id == 0x1234) && (device_id == 0x1111) )
>              {
> diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
> index 1647fd6f4756..db1299832cce 100644
> --- a/tools/libs/light/libxl_pci.c
> +++ b/tools/libs/light/libxl_pci.c
> @@ -2575,7 +2575,8 @@ int libxl__grant_vga_iomem_permission(libxl__gc *gc, const uint32_t domid,
>  
>          if (sysfs_dev_get_class(gc, pci, &pci_device_class))
>              continue;
> -        if (pci_device_class != 0x030000) /* VGA class */
> +        if (pci_device_class != 0x030000 && /* VGA class */
> +                pci_device_class != 0x038000) /* Display class */

According to some not too random document on internet [1][2], the whole
0x03 would be the display class, with 0x0380 been other display
controller. So it might be better to change the new comment to "Other
display controller".

[1] https://pcisig.com/sites/default/files/files/PCI_Code-ID_r_1_12__v9_Jan_2020.pdf
[2] https://wiki.osdev.org/PCI#Class_Codes

Otherwise, change looks fine to me:
Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed May 21 13:36:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 13:36:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991880.1375677 (Exim 4.92)
	(envelope-from )
	id 1uHjcY-0005Z4-CH; Wed, 21 May 2025 13:36:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991880.1375677; Wed, 21 May 2025 13:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHjcY-0005Yx-9Y; Wed, 21 May 2025 13:36:34 +0000
Received: by outflank-mailman (input) for mailman id 991880;
 Wed, 21 May 2025 13:36:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHjcW-0005Yr-Kw
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 13:36:32 +0000
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com
 [2607:f8b0:4864:20::22c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 99ca0e98-3648-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 15:36:30 +0200 (CEST)
Received: by mail-oi1-x22c.google.com with SMTP id
 5614622812f47-3feaedb531dso1853577b6e.3
 for ; Wed, 21 May 2025 06:36:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 99ca0e98-3648-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747834589; x=1748439389; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Wzpy5rpJQ14ukrX7WCf39+UzhN3XFDf/ts3qywsSKLc=;
        b=fcBbVZszip9JCfDC5kypqBdQ+whMphT4h7JuQjkgS2aBWYU1/bQUck9EuFHii4mjKm
         ku5PgTSva3aKJSKwM86o+Cngor5U9ZSs3fuj3+NE4KIagkeHrK1BcBSKI8LpJOrHcFyZ
         E2UY1Rn3Kk2nhknQN6pfFZjaDPMhT6OdG7o5xi6l2EwS4SSz7GMosAapkBYkiQMsMwIE
         FAT91Igr5VEJ2bp/6/WD3KJEOwT0NogxAvhghV2LlhFhw9OYWkEAHEeOrUWtrwSG12pB
         up6DQez61nQl6dxciXbqA9kyVPjJBI9au6hJv7F5EF9cx8MFpF7PGzml7Kv2DL++2No6
         Oa+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747834589; x=1748439389;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Wzpy5rpJQ14ukrX7WCf39+UzhN3XFDf/ts3qywsSKLc=;
        b=PWVvYoZ1KtY19eZiT1ZHcGX8EcF9Ns+poaQzEN2iRPz23LnUnbLL2NCAWoD8k+BJVy
         9n7BfNYqjJ7QQLJawKhAEMlWqYPRvYZA3hzNIboNYs/A3W5UO3s88Iw26DjWOyM1T3Yb
         /kCMlsdtpoKZmePpryy2P6Y6PamBeL/K++MSfuCe+4+WvhSVV3VmankE8deULlFK2Vdg
         Bgh3WddMPd6Obnf/P5pJ1gryNWvbAeE8Irar3paSTXvVjx2lzXeDXgLzHBv7foPQ+jo7
         0LBHWACnr4k1Qg0FLvQg7y2Zb+T4AFyIU83tcc5E78OSfV6nGZbnyCqj4AKZzte/ai50
         w6eQ==
X-Gm-Message-State: AOJu0YyAHQb3El9UOG0SovN4jsT1HiI97NARUpRAOR8dnubQfeEJhj3D
	0Jvit+vBvWgrCr9z+CEi4grKLRaP26SURq5W2jY6+Z3OV14C6QjaSvwGpjAH2sghAchxxnylbOq
	8XTTtXxI21TPUVzM2aTN/afq3+o8gjZcXP0VQzrJTTw==
X-Gm-Gg: ASbGncuW7FAGQrzBZUsE2f7S0IlgGbQHCzr8gRZa+qOWc2YKECi+rV04ZaU8ePySjQ2
	Bhq/h2GZJp4P7zXS62aZtpucBysmiJByNcBSvYG+dB9QILISEucpiSpF6SjT/D/d6Q16ccjAA5J
	48o9fBZxZHDBHhSe0QnU+nqF0D78zkpnHXjcm78fTj80So
X-Google-Smtp-Source: AGHT+IHYDtgciMeF4aPxmrZA+LKFwXMlQf6ZZw6CiTbP2YcVewMX7iAfGNfQNi7iMIWFnclxiZcGjJUBQjAdvWpI2vw=
X-Received: by 2002:a05:6808:6b98:b0:3f9:aeb6:6eac with SMTP id
 5614622812f47-404da7debffmr13984497b6e.30.1747834588704; Wed, 21 May 2025
 06:36:28 -0700 (PDT)
MIME-Version: 1.0
References:  <7784969bf79154363ac3479b9489778d03349c77.1744787720.git.bertrand.marquis@arm.com>
In-Reply-To: <7784969bf79154363ac3479b9489778d03349c77.1744787720.git.bertrand.marquis@arm.com>
From: Jens Wiklander 
Date: Wed, 21 May 2025 15:36:17 +0200
X-Gm-Features: AX0GCFs0uv_AOafNKPy-pucdCIusZvy_IPPlsen-WxYqEnhoCcgKx5oep6J-4-c
Message-ID: 
Subject: Re: [PATCH v5 2/6] xen/arm: ffa: Rework partinfo_get implementation
To: Bertrand Marquis 
Cc: xen-devel@lists.xenproject.org, 
	Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Michal Orzel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bertrand,

On Wed, Apr 16, 2025 at 9:40=E2=80=AFAM Bertrand Marquis
 wrote:
>
> This patch is in preparation for VM to VM support in order to do the
> changes on the SP handling part of partinfo_get before adding support
> for the VM part.
>
> This patches is doing the following changes:
> - split partinfo_get into 3 functions to have the locking handling and
>   proper exit on error handled more clearly
> - add some potential overflow checks to validate the offset and sizes
>   passed by the VM on partinfo call.
> - Introduce a maximum number of SPs (for now set to 64) to prevent
>   holding the CPU for too long in case there would be a lot of
>   partitions in the secure world. The limit currently set is thought to
>   be realistic for most use cases as 64 secure partitions is a very high
>   number compared to current seen usage (more 3 or 4).
> - fix include ordering in ffa_private.h to be in alphabetic order
>
> Signed-off-by: Bertrand Marquis 
> ---
> Changes in v5:
> - patch added
> ---
>  xen/arch/arm/tee/ffa_partinfo.c | 201 +++++++++++++++++++-------------
>  xen/arch/arm/tee/ffa_private.h  |  18 ++-
>  2 files changed, 131 insertions(+), 88 deletions(-)
>
> diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_parti=
nfo.c
> index c0510ceb8338..e524445c6fb8 100644
> --- a/xen/arch/arm/tee/ffa_partinfo.c
> +++ b/xen/arch/arm/tee/ffa_partinfo.c
> @@ -63,9 +63,95 @@ static int32_t ffa_partition_info_get(uint32_t *uuid, =
uint32_t flags,
>      return ret;
>  }
>
> -void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
> +static int32_t ffa_get_sp_count(uint32_t *uuid, uint32_t *sp_count)
> +{
> +    uint32_t src_size;
> +
> +    return ffa_partition_info_get(uuid, FFA_PARTITION_INFO_GET_COUNT_FLA=
G,
> +                                  sp_count, &src_size);
> +}
> +
> +static int32_t ffa_get_sp_partinfo(uint32_t *uuid, uint32_t *sp_count,
> +                                   void *dst_buf, void *end_buf,
> +                                   uint32_t dst_size)
>  {
>      int32_t ret;
> +    uint32_t src_size, real_sp_count;
> +    void *src_buf =3D ffa_rx;
> +    uint32_t count =3D 0;
> +
> +    /* Do we have a RX buffer with the SPMC */
> +    if ( !ffa_rx )
> +        return FFA_RET_DENIED;
> +
> +    /* We need to use the RX buffer to receive the list */
> +    spin_lock(&ffa_rx_buffer_lock);
> +
> +    ret =3D ffa_partition_info_get(uuid, 0, &real_sp_count, &src_size);
> +    if ( ret )
> +        goto out;
> +
> +    /* We now own the RX buffer */
> +
> +    /* Validate the src_size we got */
> +    if ( src_size < sizeof(struct ffa_partition_info_1_0) ||
> +         src_size >=3D FFA_PAGE_SIZE )
> +    {
> +        ret =3D FFA_RET_NOT_SUPPORTED;
> +        goto out_release;
> +    }
> +
> +    /*
> +     * Limit the maximum time we hold the CPU by limiting the number of =
SPs.
> +     * We just ignore the extra ones as this is tested during init in
> +     * ffa_partinfo_init so the only possible reason is SP have been add=
ed
> +     * since boot.
> +     */
> +    if ( real_sp_count > FFA_MAX_NUM_SP )
> +        real_sp_count =3D FFA_MAX_NUM_SP;
> +
> +    /* Make sure the data fits in our buffer */
> +    if ( real_sp_count > (FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE) / src_siz=
e )
> +    {
> +        ret =3D FFA_RET_NOT_SUPPORTED;
> +        goto out_release;
> +    }
> +
> +    for ( uint32_t sp_num =3D 0; sp_num < real_sp_count; sp_num++ )
> +    {
> +        struct ffa_partition_info_1_1 *fpi =3D src_buf;
> +
> +        /* filter out SP not following bit 15 convention if any */
> +        if ( FFA_ID_IS_SECURE(fpi->id) )
> +        {
> +            if ( dst_buf > (end_buf - dst_size) )
> +            {
> +                ret =3D FFA_RET_NO_MEMORY;
> +                goto out_release;
> +            }
> +
> +            memcpy(dst_buf, src_buf, MIN(src_size, dst_size));
> +            if ( dst_size > src_size )
> +                memset(dst_buf + src_size, 0, dst_size - src_size);
> +
> +            dst_buf +=3D dst_size;
> +            count++;
> +        }
> +
> +        src_buf +=3D src_size;
> +    }
> +
> +    *sp_count =3D count;
> +
> +out_release:
> +    ffa_hyp_rx_release();
> +out:
> +    spin_unlock(&ffa_rx_buffer_lock);
> +    return ret;
> +}

Please add an empty line before the next function. With that fixed:
Reviewed-by: Jens Wiklander 

Cheers,
Jens

> +void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
> +{
> +    int32_t ret =3D FFA_RET_OK;
>      struct domain *d =3D current->domain;
>      struct ffa_ctx *ctx =3D d->arch.tee;
>      uint32_t flags =3D get_user_reg(regs, 5);
> @@ -75,8 +161,8 @@ void ffa_handle_partition_info_get(struct cpu_user_reg=
s *regs)
>          get_user_reg(regs, 3),
>          get_user_reg(regs, 4),
>      };
> -    uint32_t src_size, dst_size;
> -    void *dst_buf;
> +    uint32_t dst_size =3D 0;
> +    void *dst_buf, *end_buf;
>      uint32_t ffa_sp_count =3D 0;
>
>      /*
> @@ -89,31 +175,26 @@ void ffa_handle_partition_info_get(struct cpu_user_r=
egs *regs)
>      else
>          dst_size =3D sizeof(struct ffa_partition_info_1_1);
>
> -    /*
> -     * FF-A v1.0 has w5 MBZ while v1.1 allows
> -     * FFA_PARTITION_INFO_GET_COUNT_FLAG to be non-zero.
> -     *
> -     * FFA_PARTITION_INFO_GET_COUNT is only using registers and not the
> -     * rxtx buffer so do the partition_info_get directly.
> -     */
> -    if ( flags =3D=3D FFA_PARTITION_INFO_GET_COUNT_FLAG &&
> -         ctx->guest_vers =3D=3D FFA_VERSION_1_1 )
> +    /* Only count requested */
> +    if ( flags )
>      {
> +        /*
> +         * FF-A v1.0 has w5 MBZ while v1.1 allows
> +         * FFA_PARTITION_INFO_GET_COUNT_FLAG to be non-zero.
> +         */
> +        if ( ctx->guest_vers =3D=3D FFA_VERSION_1_0 ||
> +                flags !=3D FFA_PARTITION_INFO_GET_COUNT_FLAG )
> +        {
> +            ret =3D FFA_RET_INVALID_PARAMETERS;
> +            goto out;
> +        }
> +
>          if ( ffa_fw_supports_fid(FFA_PARTITION_INFO_GET) )
> -            ret =3D ffa_partition_info_get(uuid, flags, &ffa_sp_count,
> -                                        &src_size);
> -        else
> -            ret =3D FFA_RET_OK;
> +            ret =3D ffa_get_sp_count(uuid, &ffa_sp_count);
>
>          goto out;
>      }
>
> -    if ( flags )
> -    {
> -        ret =3D FFA_RET_INVALID_PARAMETERS;
> -        goto out;
> -    }
> -
>      if ( !ffa_fw_supports_fid(FFA_PARTITION_INFO_GET) )
>      {
>          /* Just give an empty partition list to the caller */
> @@ -121,80 +202,33 @@ void ffa_handle_partition_info_get(struct cpu_user_=
regs *regs)
>          goto out;
>      }
>
> +    /* Get the RX buffer to write the list of partitions */
>      ret =3D ffa_rx_acquire(d);
>      if ( ret !=3D FFA_RET_OK )
>          goto out;
>
>      dst_buf =3D ctx->rx;
> +    end_buf =3D ctx->rx + ctx->page_count * FFA_PAGE_SIZE;
>
> -    if ( !ffa_rx )
> -    {
> -        ret =3D FFA_RET_DENIED;
> -        goto out_rx_release;
> -    }
> -
> -    spin_lock(&ffa_rx_buffer_lock);
> -
> -    ret =3D ffa_partition_info_get(uuid, 0, &ffa_sp_count, &src_size);
> -
> -    if ( ret )
> -        goto out_rx_hyp_unlock;
> +    /* An entry should be smaller than a page */
> +    BUILD_BUG_ON(sizeof(struct ffa_partition_info_1_1) > FFA_PAGE_SIZE);
>
>      /*
> -     * ffa_partition_info_get() succeeded so we now own the RX buffer we
> -     * share with the SPMC. We must give it back using ffa_hyp_rx_releas=
e()
> -     * once we've copied the content.
> +     * Check for overflow and that we can at least store one entry.
> +     * page_count cannot be 0 so we have at least one page.
>       */
> -
> -    /* we cannot have a size smaller than 1.0 structure */
> -    if ( src_size < sizeof(struct ffa_partition_info_1_0) )
> -    {
> -        ret =3D FFA_RET_NOT_SUPPORTED;
> -        goto out_rx_hyp_release;
> -    }
> -
> -    if ( ctx->page_count * FFA_PAGE_SIZE < ffa_sp_count * dst_size )
> +    if ( dst_buf >=3D end_buf || dst_buf > (end_buf - dst_size) )
>      {
> -        ret =3D FFA_RET_NO_MEMORY;
> -        goto out_rx_hyp_release;
> +        ret =3D FFA_RET_INVALID_PARAMETERS;
> +        goto out_rx_release;
>      }
>
> -    if ( ffa_sp_count > 0 )
> -    {
> -        uint32_t n, n_limit =3D ffa_sp_count;
> -        void *src_buf =3D ffa_rx;
> -
> -        /* copy the secure partitions info */
> -        for ( n =3D 0; n < n_limit; n++ )
> -        {
> -            struct ffa_partition_info_1_1 *fpi =3D src_buf;
> -
> -            /* filter out SP not following bit 15 convention if any */
> -            if ( FFA_ID_IS_SECURE(fpi->id) )
> -            {
> -                memcpy(dst_buf, src_buf, dst_size);
> -                dst_buf +=3D dst_size;
> -            }
> -            else
> -                ffa_sp_count--;
> +    ret =3D ffa_get_sp_partinfo(uuid, &ffa_sp_count, dst_buf, end_buf,
> +                              dst_size);
>
> -            src_buf +=3D src_size;
> -        }
> -    }
>
> -out_rx_hyp_release:
> -    ffa_hyp_rx_release();
> -out_rx_hyp_unlock:
> -    spin_unlock(&ffa_rx_buffer_lock);
>  out_rx_release:
> -    /*
> -     * The calling VM RX buffer only contains data to be used by the VM =
if the
> -     * call was successful, in which case the VM has to release the buff=
er
> -     * once it has used the data.
> -     * If something went wrong during the call, we have to release the R=
X
> -     * buffer back to the SPMC as the VM will not do it.
> -     */
> -    if ( ret !=3D FFA_RET_OK )
> +    if ( ret )
>          ffa_rx_release(d);
>  out:
>      if ( ret )
> @@ -353,9 +387,10 @@ bool ffa_partinfo_init(void)
>          goto out;
>      }
>
> -    if ( count >=3D UINT16_MAX )
> +    if ( count >=3D FFA_MAX_NUM_SP )
>      {
> -        printk(XENLOG_ERR "ffa: Impossible number of SPs: %u\n", count);
> +        printk(XENLOG_ERR "ffa: More SPs than the maximum supported: %u =
- %u\n",
> +               count, FFA_MAX_NUM_SP);
>          goto out;
>      }
>
> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat=
e.h
> index c4cd65538908..0a9c1082db28 100644
> --- a/xen/arch/arm/tee/ffa_private.h
> +++ b/xen/arch/arm/tee/ffa_private.h
> @@ -6,15 +6,15 @@
>  #ifndef __FFA_PRIVATE_H__
>  #define __FFA_PRIVATE_H__
>
> +#include 
>  #include 
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> -#include 
> +#include 
>
>  /* Error codes */
>  #define FFA_RET_OK                      0
> @@ -108,6 +108,14 @@
>   */
>  #define FFA_CTX_TEARDOWN_DELAY          SECONDS(1)
>
> +/*
> + * The maximum number of Secure partitions we support for partinfo_get.
> + * This prevents holding the CPU during potentially to long time during
> + * a partinfo_get call. Value choosen seems realistic for any configurat=
ion
> + * but can be incremented here if needed.
> + */
> +#define FFA_MAX_NUM_SP                  64
> +
>  /*
>   * We rely on the convention suggested but not mandated by the FF-A
>   * specification that secure world endpoint identifiers have the bit 15
> --
> 2.47.1
>


From xen-devel-bounces@lists.xenproject.org Wed May 21 13:46:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 13:46:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991889.1375686 (Exim 4.92)
	(envelope-from )
	id 1uHjmK-0007GT-7t; Wed, 21 May 2025 13:46:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991889.1375686; Wed, 21 May 2025 13:46: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 1uHjmK-0007GM-5P; Wed, 21 May 2025 13:46:40 +0000
Received: by outflank-mailman (input) for mailman id 991889;
 Wed, 21 May 2025 13:46:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHjmI-0007GG-HX
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 13:46:38 +0000
Received: from smarthost01c.sbp.mail.zen.net.uk
 (smarthost01c.sbp.mail.zen.net.uk [212.23.1.5])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 00d0b36c-364a-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 15:46:32 +0200 (CEST)
Received: from [217.155.64.189] (helo=mail0.xen.dingwall.me.uk)
 by smarthost01c.sbp.mail.zen.net.uk with esmtpsa (TLS1.0) tls
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (Exim 4.95)
 (envelope-from ) id 1uHjm9-001FTY-DV;
 Wed, 21 May 2025 13:46:30 +0000
Received: from localhost (localhost [IPv6:::1])
 by mail0.xen.dingwall.me.uk (Postfix) with ESMTP id B9EEBCB6CD9;
 Wed, 21 May 2025 14:46:30 +0100 (BST)
Received: from mail0.xen.dingwall.me.uk ([IPv6:::1])
 by localhost (mail0.xen.dingwall.me.uk [IPv6:::1]) (amavis, port 10024)
 with ESMTP id RvbEaheKPvE1; Wed, 21 May 2025 14:46:30 +0100 (BST)
Received: from behemoth.dingwall.me.uk (behemoth.dingwall.me.uk
 [IPv6:2a02:8010:698e:302::c0a8:105])
 by dingwall.me.uk (Postfix) with ESMTP id 7C3B1CB6CD6;
 Wed, 21 May 2025 14:46:30 +0100 (BST)
Received: by behemoth.dingwall.me.uk (Postfix, from userid 1000)
 id 324F8F9245F; Wed, 21 May 2025 14:46:29 +0100 (BST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 00d0b36c-364a-11f0-b892-0df219b8e170
X-Virus-Scanned: Debian amavis at dingwall.me.uk
Date: Wed, 21 May 2025 14:46:29 +0100
From: James Dingwall 
To: xen-devel@lists.xenproject.org
Cc: Paul Durrant 
Subject: viridian time_ref_count triggers guest clock drift
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Originating-smarthost01c-IP: [217.155.64.189]
Feedback-ID: 217.155.64.189

Hi,

I've been looking at clock drift problem we've been having in Windows VMs
which seems to come down to whether the time_ref_count enlightenment is
enabled for the guest.  For migration compatibility reasons we had the
list expanded to:

viridian = ['base', 'freq', 'time_ref_count', 'apic_assist', 'crash_ctl']

The drift is no longer observed with:

viridian = ['base', 'freq', 'apic_assist', 'crash_ctl']


The drift is also absent with (enabled stime causes the guest gets stuck in
boot):

viridian = ['all', '!time_ref_count', '!stime']


The drift is observed with:

viridian = 1


The method of testing the drift was to execute the following command in
the guest:

w32tm /stripchart /computer:0.pool.ntp.org /rdtsc

first and last lines of output, default sample period is 2s, total 41 samples:

The current time is 15/05/2025 14:32:25.
RdtscStart, RdtscEnd, FileTime, RoundtripDelay, NtpOffset
391444616392, 391478090002, 133917895450376964, +00.0100979, +10.3926898
...
637570858836, 637609379234, 133917896256928566, +00.0135181, +17.8456872


Curiously the rate of drift is exacerbated by using 'spice = 1' approx
0.1s / s, vs 'spice = 0' approx 0.02s / s.  When 'time_ref_count' is set it
is possible to observe a higher than expected frequency in the guest 'System
Information' (also reported with get-wmiobject Win32_Processor -Property
CurrentClockSpeed) but the registry key HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0
~MHz was set to the expected speed and agreed with `xl debug-key s` output.

Forcing the guest to use the platform clock (presumably using the hpet) also
prevented the clock from drifting.

bcdedit /set useplatformclock yes

Other options relating to "Guest Virtual Time Controls" were tested without
any option resolving the problem.  We could reproduce this with Intel and
AMD processors.

Guest operating system: Windows 2012, Windows 10

Xen version: 4.19.3-pre, 4.18.3, 4.15.4, 4.14.3 (our internal ticket was opened
for the two older releases but they haven't been checked again)

Xen params: console=vga,com2 console_timestamps=datems dom0_max_vcpus=4-8 dom0_mem=min:6144,max:65536m iommu=on,required,intpost,verbose,debug x2apic=off sched=credit2 flask=enforcing gnttab_max_frames=128 xpti=off smt=on cpufreq=xen:performance spec-ctrl=gds-mit=0 com2=115200,8n1
Guest config:

memory = 2048
vcpus = 2
cpu_weight=256
pae = 1
acpi = 1
apic = 1
xen_platform_pci = 1
viridian = ['base', 'freq', 'apic_assist', 'crash_ctl']
vga = 'stdvga'
videoram = 16
soundhw = 'hda'
spice = 1
spicehost = '127.0.0.1'
spiceport = 35999
spicedisable_ticketing = 1
spicevdagent = 1
spice_clipboard_sharing = 0
spice_image_compression = 'auto_glz'
sdl = 0
vnc = 1
vncunused = 0
vnclisten = '0.0.0.0:99'
usb = 0
usbdevice = 'tablet'
keymap = 'en-us'
vif = [
    'vifname=winguest{%domid}.0,script=vif-local,bridge=wan,mac=00:16:3e:01:6e:d8,backend=netdom'
]
name = 'winguest-00'
uuid = '08092537-70b6-4248-bfc4-4f6ecd92c230'
disk = [
    'phy:/dev/zvol/ztank/08092537-70b6-4248-bfc4-4f6ecd92c230/c,hda,w,no-discard',
    'phy:/dev/zvol/ztank/08092537-70b6-4248-bfc4-4f6ecd92c230/d,hdb,w,no-discard'
]
type = 'hvm'
dm_restrict = 1
device_model_chroot = 0
device_model_override = '/usr/lib/xen/bin/qemu-system-i386'
device_model_args = [
  '-object', 'tls-creds-x509,id=tls0,endpoint=client,dir=/etc/certificates/usb,verify-peer=yes,sanity-check=no',
  # SERIAL
  '-chardev', 'socket,id=charredir_serial0,host=127.0.0.1,port=48051,reconnect=2,nodelay=on,keepalive=on,user-timeout=3250',
  '-device', 'isa-serial,chardev=charredir_serial0',
  '-chardev', 'socket,id=charredir_serial1,host=127.0.0.1,port=48052,reconnect=2,nodelay=on,keepalive=on,user-timeout=3250',
  '-device', 'isa-serial,chardev=charredir_serial1',
  '-chardev', 'socket,id=charredir_serial2,host=127.0.0.1,port=48053,reconnect=2,nodelay=on,keepalive=on,user-timeout=3250',
  '-device', 'pci-serial,chardev=charredir_serial2',
  '-trace', 'events=/etc/xen/qemu-trace-options',
]
boot = 'cn'
localtime = 1
on_poweroff = 'destroy'
on_crash = 'preserve'
on_reboot = 'destroy'
seclabel = 'system_u:system_r:migrate_domU_t'


If there's any further information which would be useful please let me know.

Thanks,
James


From xen-devel-bounces@lists.xenproject.org Wed May 21 14:05:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 14:05:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991899.1375697 (Exim 4.92)
	(envelope-from )
	id 1uHk4F-0001h3-Lf; Wed, 21 May 2025 14:05:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991899.1375697; Wed, 21 May 2025 14:05: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 1uHk4F-0001gw-Ij; Wed, 21 May 2025 14:05:11 +0000
Received: by outflank-mailman (input) for mailman id 991899;
 Wed, 21 May 2025 14:05:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHk4E-0001gp-7z
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 14:05:10 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 98fe7b8a-364c-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 16:05:06 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-442f4a3a4d6so44475845e9.0
 for ; Wed, 21 May 2025 07:05:06 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f7ca2dd9sm68753125e9.37.2025.05.21.07.05.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 07:05: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" 
X-Inumbo-ID: 98fe7b8a-364c-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747836305; x=1748441105; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=+66ej0K2+ae/eb+TyFmQBQuJEpdUsCdPkCcZeb5MUno=;
        b=uzPY7SzxvS/6auN/nP+xQrAPFflZcfUC2+nZri0nHGFj4FjspTP0kdEfBt6VjKP5z1
         4oXBVl6mXOrorc3Hv7QOo2Rtgol/t/3HOB3wGBz2RaBsdzhSVNVfYUTTq4aa7pomte75
         oATRilAbwnBmizhy/K5gU6Tuer9GMpj9Dk+rA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747836305; x=1748441105;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+66ej0K2+ae/eb+TyFmQBQuJEpdUsCdPkCcZeb5MUno=;
        b=WqVzJkhqv91e8XvRjkadx843CcD4GNiVlibty90dwsvYXNdWbo5yhaJqdQx6ZJErAx
         nI6oQNsdgGNGU/qYUNuZqKX9URVMBN2vu/4wwjG4Ax/KDvdvLspagCTDz/CCeZmzCYXl
         ZUEvO0f23XosJImt6pUxos7CppOms36KvrTL0ngcbZ2F4kS961onUeN9/lOO69fd0yk+
         Yvyfwl+qivpXxPnYmW0KCbSUwOBFQjsun4AH50uhwOTQz1FaxOhhivigyKXFqLojhNHO
         edlDwsvNAoavj9HaR4nO5D2GPUo1/u4C9FrqwNdNWR6OgBoraD2GApecidcBF0ROs75f
         qvhg==
X-Gm-Message-State: AOJu0YyS/4fjBOvjWZLKjeBKtMxvF+6p4IudNAJm9zcDTKnuaTy/gLFN
	l/yA35p9xKHgH6tVytjj0cudPVmTCDHcqGeeNa6OUAivnuZBHhlBx/tY14vgsTBwK2o=
X-Gm-Gg: ASbGncufjJj5KB2isMQ+MF0tNIKk8bO1SxmPh8xeRcBgsQ71pJrthsXYobw4fqQk9LV
	mMKn3jRv7FagT8NIamaA0w+0rAj/29gYThs1Z0+tyjJ/Quzp40FexpSVDGS+ODy1YaLFcVIamha
	+cTgpwkPEqpIzPIssXS/f3y9Ya8XprJithgrC8SFdOuvyuppvYQ57H/e6orC6VbvyveWwImTvVi
	RNBKIYiPuKDjrCXq4B94LB6SfFn7sw/ZS7Hy5ONTaVri/R2NnIqf9X15THzWMGQ4ObVcyLjzcED
	V0kcBFnzU1IjD02lGn9OJuP24tOfKWb4Og0TQtSZomg3uzI2msl06yWbx2DrxsulOcUCtrRjmnr
	a/rU6jIXChPbaRBCIGkUx7bke
X-Google-Smtp-Source: AGHT+IGUOjBoJzBpZ1MW0VPvNs7SXUG/tUm3xzT4ztIDN7oe8wChxo6jh+7fbSdPAjF9I7LME8Qbew==
X-Received: by 2002:a05:600c:1e09:b0:442:cd12:c68a with SMTP id 5b1f17b1804b1-442fd935c8emr198158225e9.1.1747836305449;
        Wed, 21 May 2025 07:05:05 -0700 (PDT)
Date: Wed, 21 May 2025 16:05:04 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
	michal.orzel@amd.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v2 1/2] xen/domain: introduce non-x86 hardware emulation
 flags
Message-ID: 
References: <20250516022855.1146121-1-dmukhin@ford.com>
 <20250516022855.1146121-2-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250516022855.1146121-2-dmukhin@ford.com>

On Fri, May 16, 2025 at 02:29:09AM +0000, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Define per-architecture emulation_flags for configuring domain emulation
> features.
> 
> Print d->arch.emulation_flags from 'q' keyhandler for better traceability
> while debugging.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v1:
> - dropped comments
> ---
>  xen/arch/arm/include/asm/domain.h   | 1 +
>  xen/arch/ppc/include/asm/domain.h   | 1 +
>  xen/arch/riscv/include/asm/domain.h | 1 +
>  xen/common/keyhandler.c             | 1 +
>  4 files changed, 4 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
> index a3487ca713..70e6e7d49b 100644
> --- a/xen/arch/arm/include/asm/domain.h
> +++ b/xen/arch/arm/include/asm/domain.h
> @@ -121,6 +121,7 @@ struct arch_domain
>      void *tee;
>  #endif
>  
> +    uint32_t emulation_flags;
>  }  __cacheline_aligned;
>  
>  struct arch_vcpu
> diff --git a/xen/arch/ppc/include/asm/domain.h b/xen/arch/ppc/include/asm/domain.h
> index 3a447272c6..001116a0ab 100644
> --- a/xen/arch/ppc/include/asm/domain.h
> +++ b/xen/arch/ppc/include/asm/domain.h
> @@ -21,6 +21,7 @@ struct arch_vcpu {
>  
>  struct arch_domain {
>      struct hvm_domain hvm;
> +    uint32_t emulation_flags;
>  };
>  
>  #include 
> diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
> index c3d965a559..7bc242da55 100644
> --- a/xen/arch/riscv/include/asm/domain.h
> +++ b/xen/arch/riscv/include/asm/domain.h
> @@ -18,6 +18,7 @@ struct arch_vcpu {
>  
>  struct arch_domain {
>      struct hvm_domain hvm;
> +    uint32_t emulation_flags;
>  };
>  
>  #include 
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> index 0bb842ec00..73f5134b68 100644
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -306,6 +306,7 @@ static void cf_check dump_domains(unsigned char key)
>              if ( test_bit(i, &d->watchdog_inuse_map) )
>                  printk("    watchdog %d expires in %d seconds\n",
>                         i, (u32)((d->watchdog_timer[i].expires - NOW()) >> 30));
> +        printk("    emulation_flags %#x\n", d->arch.emulation_flags);
>  
>          arch_dump_domain_info(d);

Hello,

I think it might be easier to print emulation_flags in
arch_dump_domain_info(), ideally it would be helpful if this could be
printed in a user friendly way apart from the raw dump:

printk("    emulation_flags:%s%s... (%#x)\n",
       !d->arch.emulation_flags ? " none" : "",
       has_vlapic(d) ? " lapic" : "", ...
       d->arch.emulation_flags);

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 21 14:16:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 14:16:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991918.1375707 (Exim 4.92)
	(envelope-from )
	id 1uHkEu-0003Px-NG; Wed, 21 May 2025 14:16:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991918.1375707; Wed, 21 May 2025 14: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 1uHkEu-0003Pq-KX; Wed, 21 May 2025 14:16:12 +0000
Received: by outflank-mailman (input) for mailman id 991918;
 Wed, 21 May 2025 14:16:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHkEt-0003Oy-8V
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 14:16:11 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 23cb5e0e-364e-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 16:16:08 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-601ed5e97e9so6178974a12.2
 for ; Wed, 21 May 2025 07:16:08 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ae48253sm8977664a12.81.2025.05.21.07.16.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 07:16: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" 
X-Inumbo-ID: 23cb5e0e-364e-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747836968; x=1748441768; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=edDdcId7Anufnt/IaeMu1mkUCIPLUjT71SdevQXuUzM=;
        b=L0FUD3Pquq0KotG3QHTN4vKC7TG2obcXlELZgvu0cTm7gfsrob531i296QQdDhGDR4
         lXrMMdggbExyzt0F8bkejagdUP+fwoD0T1/POtTBsi2HJot6Q6D5JyaLtIATCyKaBmYE
         V6IfDC0fTw9ZTu1ovKEZtcz8Wbd7ZsOXOFd1SXSPRuJ3tuvwoRudG9I8+qoYVEF2e7+Y
         NblG6H6AKqBHiKPhmPlMKraSJyU+Dqx+QG4Vp4DwhJ8pOg2XUOAhfmWSsq+SQSmbEL5e
         brqFWH3VB1yBzfWjWXkWkn8kHoIyXowCESdtggPNX/JKh7UYp20f7FH5S/xFvd2cCGV0
         dCUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747836968; x=1748441768;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=edDdcId7Anufnt/IaeMu1mkUCIPLUjT71SdevQXuUzM=;
        b=Rn6LC37QgL369r9nQ4lvZtWDTsYgoJGH4S2dVLKVLGSp/PpTWaCfouw56mFUGdnA7a
         o9bIeUMXy07ELNCI/7D/FVPTqvfNzr6PgUg4oB2ui0K9k0/XL5FundzGNZO45p/Rz9FZ
         vIbppKARxTk1jlReQeAIQ6T60rJIHlYwRw2A/kDN+z3pTmtFQg17Lr50J6doJ3AtKD+J
         gyu5SnaNpnJ06gySwC/jlm4Wwriw2/qeuEHzBquxsY/I5Ox1x6yKFCCSKMoOga1eaQhS
         UtcjBf0Rz8agDsA43M+TLqjIZpqjDptDkVG1lAe9iWlRp2grKsp0l+ORRlpFvFnwv/+9
         w26Q==
X-Forwarded-Encrypted: i=1; AJvYcCVJyWoNzD1gfRXvGJOtE4srLQsIBcMUBARS9V5DcSVH2+fsauHC5+Y3j8S25v0jdH1B9Ma9yf/O7fc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyY9MgH1viA9oHf5TxNtU6PpHnKuRDcnIdwFR6/gqVpO99PNnPG
	YzpOX4xRBc8tGg5J9ivUmBfFrCi61SJ5s0X7gWbOyW5GYbzqA3tN8aozLZJ6we3WPw==
X-Gm-Gg: ASbGncuGpuGffq3ba3ofDNz6q2T+vu0sfXJWm3fSFoq/Fj7OyHULy6WAuLRUA8a4Zco
	iAVqFYJpCAysrKkJVIPGSwIyg0vGrnPowR/VDLSBxZuvL+G8MDtbF1+zGxzOJjD5KJCxstea/Rx
	rGhdee2txNGtETOYUTLDfpJEIlec3OeA3LLx8w5cKoQkaswC/+KzJORv/cFrxRyalOg8veef9pa
	lL+EXN/5COvY5EjNIR8qSFrW6rpOcGdJFvI8Anwr/dxUK8iiHWUbcsVsuutF81TaLT43cgcgtCp
	xyYYdHrVuqf5tnOY3uxJR0m+XTjNy4hbURwObdFaPd967nYbSXLS4DDibh2jzA==
X-Google-Smtp-Source: AGHT+IFzgGEaPQ4scpoSSWBBF55xtPN7l0xGZnmf9dIw1iW1duWRYCLturr64iXOcIHI14mLJO/Hpw==
X-Received: by 2002:a05:6402:13d6:b0:601:f3f1:f10e with SMTP id 4fb4d7f45d1cf-601f3f1f375mr9629486a12.5.1747836967822;
        Wed, 21 May 2025 07:16:07 -0700 (PDT)
Message-ID: <537a0452-8299-4164-afce-38a5f7e2ff67@suse.com>
Date: Wed, 21 May 2025 16:16:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xen/riscv: add initialization support for virtual SBI
 UART (vSBI UART)
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: <1f380b7061496f999d4d60a60b58f494dae886e1.1747064551.git.oleksii.kurochko@gmail.com>
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 13:40, Oleksii Kurochko wrote:
> On 5/15/25 12:08 PM, Jan Beulich wrote:
>> On 12.05.2025 17:55, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/Makefile
>>> +++ b/xen/arch/riscv/Makefile
>>> @@ -1,5 +1,6 @@
>>>   obj-y += aplic.o
>>>   obj-y += cpufeature.o
>>> +obj-y += dom0less-build.o
>> Arm uses
>>
>> obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
>>
>> Why the two differences?
> 
> Missed that. I have to understand why Arm uses *.init.o, but likely I should do the same for RISC-V.

There's likely nothing Arm-specific in this. When all functions in a file
are __init and all data is __initdata / __initconst, we prefer to move
the remaining data (string literals being the most prominent example) to
.init.* as well. That's (basically) what the *.o -> *.init.o build step
does.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 14:27:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 14:27:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991934.1375717 (Exim 4.92)
	(envelope-from )
	id 1uHkPH-000575-Kg; Wed, 21 May 2025 14:26:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991934.1375717; Wed, 21 May 2025 14:26: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 1uHkPH-00056y-Hy; Wed, 21 May 2025 14:26:55 +0000
Received: by outflank-mailman (input) for mailman id 991934;
 Wed, 21 May 2025 14:26:54 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uHkPG-00056s-Ef
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 14:26:54 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uHkPF-00607V-24;
 Wed, 21 May 2025 14:26:53 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uHkPF-006Mwn-0J;
 Wed, 21 May 2025 14:26:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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=V3oKYw1ew7RdkmQGNCAz8YhinDgoQIjOlcbY4Fetcc0=; b=TRDdmNrpjbJJh8h59mGFiECHRq
	tqFqhfx73nP3/QZlxQo8jJbMretN/dvpUF6/hASCGUE4QyY3YMcDE4prSfGzA3/hhqEWl1ByHAvZn
	Sz0Bm0l9IGwLxrQ3W9dPp+/WLCNqDeZDNW8atbpMFfYalUdDDbZdDnotPRW/LnV/5TJ0=;
Date: Wed, 21 May 2025 16:26:51 +0200
From: Anthony PERARD 
To: Sookyung Ahn 
Cc: xen-devel@lists.xenproject.org, matthew.l.weber3@boeing.com,
	joshua.c.whitehead@boeing.com, Anderson.Choi@boeing.com,
	brian.j.wood2@boeing.com, haesun.kim@boeing.com
Subject: Re: [RFC PATCH 0/2] Propose an minimal xen-tools
Message-ID: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

Hi,

Thanks for the proposal.

On Wed, May 14, 2025 at 07:12:48AM +0000, Sookyung Ahn wrote:
> I am writing to propose an enhancement to the `xen-tools` for users who require only a minimal subset of its functionality, particularly in safety-critical domains like aerospace.

FYI, there's a project call `xen-tools`, at
https://github.com/xen-tools/xen-tools/, and having it spell like
reminds me of that external project, and not the tools in this repo.

> I believe that the addition of a new build-time option, `ENABLE_MINIMAL_XEN_TOOLS`, will significantly benefit users by allowing them to build only the essential components needed for their specific applications. 
> This approach not only streamlines the toolset but also reduces the potential for unnecessary complexity in safety-critical environments.
> This proposal is based on `dom0less` environment.
> 
> The proposed implementation includes:
> - Introducing the `ENABLE_MINIMAL_XEN_TOOLS` configuration flag.
> - Modifying the build process to selectively include only the necessary components based on the configuration.
> 
> This implementation can be effectively applied to the following use cases. 
> - Minimal APIs for `dom0less` operation. This involves taking existing Xen functions and shrinking them to minimal needed parts. For example, we can use static device tree instead of XenStore. 
> - By retaining `libxencall` and minimum part of `libxencrtl`, the Hypercall interface can be utilized, enabling support for the Xen ARINC653 Multiple Module Schedules service. 
> - Addition of ARINC653 Part1&2 APIs and services (hosted on the domain OS.)
> 
> I would appreciate any feedback or suggestions you may have regarding this enhancement. 
> Additionally, I would like to emphasize the importance of community input in refining this proposal to ensure it meets the needs of all users.

I don't quite like this approach. What is "minimal"? Whatever
definition we can come up with isn't going to fit other's expectation
of a minimal set of tools. Also, the minimum set of tools needed might
be 0, if you only need the hypervisor.

Also, the implementation is quite invasive, with `CONFIG_MINIMAL_TOOLS`
spread through the build system. It also duplicates configurations, with
like "SUBDIRS-y += libs" been written twice in tools/Makefile.

I feel like a better approach would be to have something like:
    ./configure --no-default --enable-flask --enable-hotplug ...

As for the makefiles, instead of having to invent a config option for
every single `SUBDIRS-y` we could have a generic
SUBDIRS-$(subdir-default) where subdir_default is 'y' unless we want to
select a handful of subdirectory.

It might not be necessary to have a config option for everything, you
could deal with some of the stray binary with the tool use to make
package, like RPM where you select which files to packages (as already
suggested), and for other tool just `rm` the few files not needed.

Then, there's `libxenctrl`. For this one, it doesn't feel like a good
idea to make it selectively smaller. Maybe there's a way to extract the
functionality you need into a new lib? We kind of tried in the past to
extract piece of it into lib with a stable interface, like
libdevicemodel, libcall. So it might be a better approach to remove the
need of libxenctrl in your environment.

I hope that help.

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed May 21 14:31:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 14:31:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991942.1375727 (Exim 4.92)
	(envelope-from )
	id 1uHkTq-0006d7-5l; Wed, 21 May 2025 14:31:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991942.1375727; Wed, 21 May 2025 14:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHkTq-0006d0-1x; Wed, 21 May 2025 14:31:38 +0000
Received: by outflank-mailman (input) for mailman id 991942;
 Wed, 21 May 2025 14:31:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHkTo-0006cW-V3
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 14:31:36 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4cd2aa49-3650-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 16:31:36 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ace94273f0dso1185761066b.3
 for ; Wed, 21 May 2025 07:31:36 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d06ddd6sm925802366b.55.2025.05.21.07.31.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 07:31:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4cd2aa49-3650-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747837896; x=1748442696; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Qayd1Jk1yQEMeBqLuKl2cbOb86FMBCDqSXk5OE5RkPM=;
        b=Kmxv1xmHxWuxCATUZhNMXpVBAm+3nSTmLDBxfaGzTjOdp89XQrg0kM7KtAXY8SDSa7
         y9u+BMhCLAGBKTymEj+JLMIIxR/WwZ+tHMICrGMA+FNC1hRkgsbFhPmZUgqMDiro14Xp
         opuMktdVxVDDy4bQxMGI16oVmqlVFFUuCJ6uZ83dSCfevxCnthdzYhP8zVhNyacD3W7q
         nACrMmego/fHzKDHYpvhTEPmEGfshD7oH7yGfjUI/sFM2j4ZeyWSPY532Sx4pLwDy6fp
         bmTVkoh6nVZcWWkJ5GRimVqZvjsL5tF61/1iKypPQ73vILMrT8HExxOHl5lr9dOC97Vh
         E1og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747837896; x=1748442696;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Qayd1Jk1yQEMeBqLuKl2cbOb86FMBCDqSXk5OE5RkPM=;
        b=rO1oOhfarJyKFlcpvDr2/GvRp8pCHYBlRBLgL2K88iobng2uDJbmrEcnl9+oa3QV9J
         zMS19g2xeRfErAg7zi9vcFtQNzfhXlyyoQ+LlTvrH9VptmWRJgtD8Xx3tl3oP40JPI/c
         QthrLqAbFS+4wz9JY9epP5A8d9duAQQkgvVsaFcTmRNq8AMDVJ7HntKpLLcXfWnp9lLX
         fZufCKATTmYWwdVjroiGotPHs14TvzdKzXkBEC4iIfIkqzFkH4reidjzoYpnPWfRfYRO
         X2pXcUy2tHw9MdPtaSGFhQWn4AbXRyXQzoA3EmQHHdxP8LCvlN1QjiNhc/TZOmGZmKA9
         rsgw==
X-Forwarded-Encrypted: i=1; AJvYcCXBcb+w0mfgAhaGL1DVMaN0c+LODzIoXr+UJHbn55wcSUPG5FZ/Lf9GjKoC2e4EW5w6Iv3KguULagU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyikJmzdBzXruu7ZBkxffesnUKM8DfDqjQo9xtsznfJM8V6O7Hd
	pUSwCd7BQHf+oBmstEnIGZ/loICHq+ubQJh53/+CLxRDVFS1y+49VPQNnucKdTyhBw==
X-Gm-Gg: ASbGnctTuMSSvcHem7mlHSmv+lyzkp8NO8dRVNW6qDH/vJtREi6dSHmPAUGkptqrbFE
	atEdYsjjlntOtaa6st4Ey4lHiVP+39yEVdvZmXLPOlXl6WmTZ3edILhQ++vOv6uj9AJcZNUl+aS
	ToIV+pUIxRjHeAoa/9zUbmHYaztXIr28M+jz3/Rq4cL0f9h+fQNy3Td3RUAPZaxg0xG4fkinkp2
	WYm0IRCe1w5wtR89ZCyioSdJiYxWMmQSAU6WpXV0KS9jVym6Ie35VfG+O3mVGd3hpxO0JP7qqU4
	TzDHpGUAmgiGgH5sH5jZox1vI38V4sIQlmQ9D/YGcp2NdBq7P7mR5zUEQQ+2jQ==
X-Google-Smtp-Source: AGHT+IGdw2z4gTLtYAfPbaAbIEw2ojJuFUR5PV0MeMXPocW/z/vj3aSW/gP+hCD6huk3EDxRMQAWPQ==
X-Received: by 2002:a17:907:f496:b0:ad4:d0bf:f4a9 with SMTP id a640c23a62f3a-ad52d4cd771mr1864721266b.21.1747837895602;
        Wed, 21 May 2025 07:31:35 -0700 (PDT)
Message-ID: <4ea08d6d-c2e1-40ad-a31e-554e7bb5cc6c@suse.com>
Date: Wed, 21 May 2025 16:31:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/vpci: fix handling of BAR overlaps with non-hole
 regions
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Stefano Stabellini ,
 Victor M Lira , xen-devel@lists.xenproject.org
References: <20250516083159.61945-1-roger.pau@citrix.com>
 <7bbc1569-672e-42a7-a5b8-4187282fcb18@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.05.2025 13:34, Roger Pau Monné wrote:
> On Wed, May 21, 2025 at 10:29:26AM +0200, Jan Beulich wrote:
>> On 16.05.2025 10:31, Roger Pau Monne wrote:
>>> For once the message printed when a BAR overlaps with a non-hole regions is
>>> not accurate on x86.  While the BAR won't be mapped by the vPCI logic, it
>>> is quite likely overlapping with a reserved region in the memory map, and
>>> already mapped as by default all reserved regions are identity mapped in
>>> the p2m.  Fix the message so it just warns about the overlap, without
>>> mentioning that the BAR won't be mapped, as this has caused confusion in
>>> the past.
>>
>> I was trying to get back to this, but my attempt to use this "fixed
>> message" as an anchor failed: You don't modify any existing message, and
>> hence I was unable to determine which other message you refer to here.
>> None of the ones I looked at appear to fit this description.
> 
> OK, it's a bit tricky.  Note how the new implementation of
> pci_check_bar() unconditionally returns true, which means the message
> in modify_bars() will never be printed on x86.  Instead a slightly
> different warning message is printed in the x86 implementation of
> pci_check_bar().
> 
> That's what the above paragraph attempts to explain.
> 
> Maybe I need to adjust the last sentence so it's:
> 
> "Avoiding printing the warning message in modify_bars(), and instead
> print a more lax message in the x86 implementation of pci_check_bar()
> to note the current BAR position overlaps with non-hole region(s)."
> 
> Does the above make it a bit clearer?

Yes, it definitely does. And with use of that I'm now also feeling reasonably
confident to offer
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 14:36:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 14:36:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991960.1375738 (Exim 4.92)
	(envelope-from )
	id 1uHkXz-0007Ge-Mc; Wed, 21 May 2025 14:35:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991960.1375738; Wed, 21 May 2025 14:35: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 1uHkXz-0007GW-HT; Wed, 21 May 2025 14:35:55 +0000
Received: by outflank-mailman (input) for mailman id 991960;
 Wed, 21 May 2025 14:35:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHkXx-0007GP-Ns
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 14:35:54 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20619.outbound.protection.outlook.com
 [2a01:111:f403:200a::619])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e47c19f4-3650-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 16:35:52 +0200 (CEST)
Received: from MW4PR03CA0215.namprd03.prod.outlook.com (2603:10b6:303:b9::10)
 by CH8PR12MB9743.namprd12.prod.outlook.com (2603:10b6:610:27a::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.29; Wed, 21 May
 2025 14:35:47 +0000
Received: from SJ5PEPF000001E8.namprd05.prod.outlook.com
 (2603:10b6:303:b9:cafe::65) by MW4PR03CA0215.outlook.office365.com
 (2603:10b6:303:b9::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Wed,
 21 May 2025 14:35:46 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001E8.mail.protection.outlook.com (10.167.242.196) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 21 May 2025 14:35:46 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 21 May
 2025 09:35: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" 
X-Inumbo-ID: e47c19f4-3650-11f0-a2fa-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZEnn6FmoKi9B5gdhZrgw7eGnSRtg/m1P0zxbhYZ8t5T+lBB+ITPo3xQdUCttQJvwQOwg1USpiLakJcDS1wFDi+kfJHNTkBisRkZDqkKLBSt++fa36QnqsENbJo0Bq6/FEsMaL4kvR5HHHgxhx3EckILUbmiPSDEmiEhHbb9i0ufCpY/0f3K67Yzn8p6HQznyPDFSb+VqT3myaie9I9sSr3rGn4wG0rtNCikVcEs/vXZN1iTAWs7F4HPJkNqw25nMfRGtJKgYutYoqOIqeiGlCBegea4A1X+14aMzYnIiydy9/ke2oWwRRYEG/dGbufPFszBW7cvQoY8vNlzRSNKwZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LxNF8yPnfKOnRwgsU15acE56A5/eYkWJV+RhnqKWZoQ=;
 b=zE/OJtWwbSlS3c8rDzXTabqoM6G1tz/zrAYeLhrL+uJZPBMxdu/Qgsr0XAQDaCZlNFoHtqa6cMYdfFXzrceERaNhhcJj2DYOuUJBCqdU84bP38MmIJys90qwpjWkb0tGcBJtgCq+kvADjdf87F08IsOKD28oThZpedzNZlhdwsNK0QFQqsAAPV8I/qCAqFZpWr4NyF6U4v2aWvjorPULhksbQ5C8bro0Smr30mq4d4IvEt0ps3ClqRMyQK4+h2tBxIhKoJJ8ME1Ul9D6nJHnP/JHq1LyEIMY0WlLt779Ubpihy9r/+fdYFpAS159AXruk9UeAQGsBQ85l0hsBADzXA==
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=LxNF8yPnfKOnRwgsU15acE56A5/eYkWJV+RhnqKWZoQ=;
 b=fp4vrbtNMzHoN1t661tk0KapRYyAIlYiZZ1OL10bs569SSzjLAOc9IzrePq+BBX34Eqb27QUBT8cuvf2M1FWZiZFF/Uem90dLQlW8mSTB/8YSanK5j8wmJqACcb+DUdbCUNUzT6vX6+4/uiqUQOZUKgPw5J3QIEZR+TQXwyZ6Mw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 21 May 2025 16:35:38 +0200
Message-ID: 
From: Alejandro Vallejo 
To: 
CC: Andrew Cooper , "Daniel P. Smith"
	, Michal Orzel , "Jan
 Beulich" , Jason Andryuk ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini
	, Xenia Ragiadakou 
Subject: Hyperlaunch/dom0less code sharing
X-Mailer: aerc 0.20.1
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001E8:EE_|CH8PR12MB9743:EE_
X-MS-Office365-Filtering-Correlation-Id: 93459236-bb77-4f6a-3a68-08dd9874c61b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?a3d6VVlSa1lXRHpYQXdyUmhtZ21QT25ObTQwT3JZL2xhaVRkSVJXb1pla3FX?=
 =?utf-8?B?MTcvL0NibHFpZ0pCSUNjUDB3b3k2OVlETi8vTE42c1ZWVStEc252ekVPaE44?=
 =?utf-8?B?NkJJV25KQTh6Zm0wYzREd00rNWZvUVM0S3p4eHp2MXk3Y2lLeHdxK2trZ1Uy?=
 =?utf-8?B?TkpyT0lSendaamNLVGp4UkVtR1gyMnhVU0VwZnZ4L2k2VU1HanlXWkxpcWNN?=
 =?utf-8?B?Ym1OdG5EeFhaZkNRZzNmQUhJTXRwWEV1bTFYeUp0R1ZPeFZCWDA0eWphUzN2?=
 =?utf-8?B?bzUzZjh4L3JFWEtWRldQaHkzdDk4RlRmWU1oT3A3T3ZhRGJpSEZvRXpwRDlB?=
 =?utf-8?B?a0pJeloydGtyeXlQWkRDV3VTUXB2M2Q0TzZiVGVOek50aDRqT3RhSzAyN2VT?=
 =?utf-8?B?SFZVMExpRnZUUXVTNy9HOFhKK2phTGE4czBiMDBRREpEMnlCOXdTRmF3aTBz?=
 =?utf-8?B?U0VEaFRIbEZUTXJQM290Y3VlaVEvbHEvbnJzRDdIZDVDa3hPNHg5d1JPMVRo?=
 =?utf-8?B?a2VsOE9lUVlUOWtudk95SW5nSGtWTHJFOFBSd0h4ZkxhYnZRQUhOcUJBQWNW?=
 =?utf-8?B?SlNGMGJ5M1RnWTZMT256WDdHdzVVV1A5S1ZmTXdSVDFOaXA5UmVjTGNZTXRl?=
 =?utf-8?B?U2xreGdpRVk1R1FEekNnODVuQi93akRYV094T2pYR2FsbXhzVThFS084L2t0?=
 =?utf-8?B?SldFSWpoVlpXdUY3YXlJdXpwUEl1M3hBaTNmZTZSQVlzSmpTN2ZocEhIZkEz?=
 =?utf-8?B?aE1vQ3g2UWtkTGFnNFdtbHVKM1ZYMWIyN3lrbUJWaVdNTkxYWmFnRStwQm9v?=
 =?utf-8?B?bm9HSnJ6Z3QwS2dndUFHd3p2TFNsZVQ3SEM4L2s2QitlMFJtN0MrSzBrNzJo?=
 =?utf-8?B?UUFicjVNaDc2cS95cG56UWFzenkxUUM2VnZwN1BJcXZ2RXdZazY1L0FCcDVv?=
 =?utf-8?B?c1BaRU5ZTHBEcW82VHAyUXFud2FkNTlnRWltSFovc2xTbkNHVXZrU1VlSXN1?=
 =?utf-8?B?R3FDd0lKWDNYL2hZU2ZSdHkrZ3JlM3pOZ1YxakFUM3JYZTA4UnRISDRqNFpU?=
 =?utf-8?B?Y3pTZTA3K2pzd2hlZ1VVekR1cERBOTZLZUtXbVMrd0VOVHJaVWZEQ1dlRnlL?=
 =?utf-8?B?bVluckIrZGJBNXZyeDNsZ1lnalBSSDNhQXF6VXVCR0xUU0JRM1pEVHcydmg4?=
 =?utf-8?B?bnVWaFV5ZTlYeEtLcDdMZkFhOFVyb0JLU0pxU3h5SlFWYk90Y1A5b0d2VHhm?=
 =?utf-8?B?MUJNTzZ1TGFQQTJlbC9aNlhXVitkc1R3WHQ4VFU5U3hka09tTEJkMHdjYkVp?=
 =?utf-8?B?UkdHSGFxUk5JU1JuVFlSOTlzdS9MeEJFTE5lWWYwcjlrMTU5UnR5TG5IeFhW?=
 =?utf-8?B?ZHNQNUIzQU9wSjN4MkdRY0h4MmFsaWFFREw2Y0trdDl0MG55bzV3Zm9STkFQ?=
 =?utf-8?B?V0ZDdWZWcGhjRTNISzQyUFV1VXUwOFhoaFNqZlNaYXdJd2V1ZmE4VCtYTFN2?=
 =?utf-8?B?RENJY01oL0M2ejkrVmhScEpsSDRGWkhXUXlYdUdCR2FWaXNTMFdxQmt5cVBo?=
 =?utf-8?B?QjdJUjhBTVZTMjBXUmM2U01uWkZCWVhqbHN6NTg0a09iTU9kV0xFbXV5KzNW?=
 =?utf-8?B?N3NrOEUvNU4zR25RcllrNzNxVEtpaXUwNW11OHZaN0VlYTRUbWlUMDhibHFx?=
 =?utf-8?B?eHYwZ3VTNXJLUmt2NEVqaHlRNjNQc2dneUJ4YU9ib29yL2ZlTHcyVEFPUm56?=
 =?utf-8?B?U3VzVlB1NW5qL2RCaFFKNEZjZU91dExMT2FsRnhzSHdkY285Y0krQXRaOTFJ?=
 =?utf-8?B?TXVQeVFWRWRHUU9UcW16WmF1aWxhUHp4cXNBTFpPQmxoMU5od0xOTFpXaHFn?=
 =?utf-8?B?MG9NaFpMUVZIU1YzVklTbG9kQVRkSUZwdmsvNUZqVThMMmRJVjBMY2Q0UDZW?=
 =?utf-8?B?OHNUYUYwZmE1VHRMUUJDMVFDRXp6MGlrNThsdUdvOEd0S0hMazZ1OVkxSkx1?=
 =?utf-8?B?ZXhERzhhSS9MK0t0OVlLUFNNWEtXUW4xSVZmVVVZQ0d5NkgvYnlMSGw0WHE0?=
 =?utf-8?Q?qT63Sh?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2025 14:35:46.2527
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 93459236-bb77-4f6a-3a68-08dd9874c61b
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001E8.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH8PR12MB9743

Hi,

(There's a TL;DR at the end)

While working on preparing and reworking the hyperlaunch series for
upstreaming it's slowly becoming apparent the degree of duplication with
dom0less.

Oleksii's latest effort to move all that code into common[*] (see
ad03faa942b9("xen/common: dom0less: make some...) makes this even clearer.
There are 1:1 relationships for every key data strucutre, and by deviating
we're overcomplicating the ability to share code.

  [*] https://lore.kernel.org/xen-devel/cover.1746468003.git.oleksii.kuroch=
ko@gmail.com/

    dom0less           Hyperlaunch
    ------------------------------
    kernel_info        boot_domain
    bootmodule         boot_module
    bootmodule_kind   bootmod_type
    membanks                memmap
    bootinfo             boot_info

The difficulty in code sharing is not just unfortunate from a vague sense o=
f
elegance or neatness. Having different code paths parsing the same DT bindi=
ngs
means it's a matter of time before x86 and all other Xen ports have differe=
nt
bindings, which would would only worsen the situation wrt code sharing and =
user
confusion.
=20
I've been trying to get _somewhere_ in using parts of dom0less on x86
and develop a credible PoC that highlights the use of dom0less parsing
code paths. The results are interesting.

While I didn't get to a full integration in the hyperlaunch series as I hop=
ed
due to time constraints I did get far enough to:

  1. Replace boot_module, boot_domain and bootmod_type with their dom0less
     counterparts (pending some cleanup).
  2. Isolate binding parsing code in common/device-tree so it's dettached f=
rom
     the not-so-common dom0less domain building logic in dom0less-build.c
  3. Do early module kind detection from x86 using code in (2).
  4. Do late binding parsing also using code in (2) after unflattening the =
DTB.

And it works well enough under QEMU to populate boot_info to a first
approximation. It's missing hyperlaunch-specific bindings (like "domid"
or "mode"), but that's just a matter of adding them to the already
existing per-arch binding parser ("mode", maybe, would be a candidate
for this) or retrofit them in dom0less ("domid" is a very clear
candidate for this) and integrating in the larger series to be able to
actually boot domains.

The PoC does not go all the way due to time constraints, as I said, but
I think it goes far enough to convince me it's both feasible and
beneficial to go in this direction rather than that of a full
reimplementation on x86, specially seeing how Oleksii already aims to
have full code reuse on riscv.

A brave new world would reuse all data (including bootinfo) and code
(bootfdt.c/bootinfo.c), but I couldn't get that far, and I don't think
I'll be able to in a timely manner. IOW: I compiled-in device-tree.c,
but NOT bootfdt.c or bootinfo.c, or any of the others. I merely
extracted from those files the binding parsing bits of interest.

It'd be nice to use them, but the domain construction logic is just too
different at present. As for the code I tested with,  I need to do some ser=
ious
cleanup before it's ready for sharing, and even moreso for review, but befo=
re I
go through that I'd like to reach consensus on the following points before
investing any more of my time working on the side.

TL;DR:

I think we should aim to share binding code wherever possible, using common
datastructures (kernel_info and bootmodule) as dumping ground for the resul=
ts
of the binding parsing functions. I seek agreement on the following 3 point=
s
for the end goal of DTB multidomain boots on x86 before I start slicing
my hacks into reasonable chunks.

  1. We want common data structures, with arch-specific fields to hold
     information from xen,domain DT nodes
  2. We want to have a single collection of DTB parsers in the code.
  3. We want to operate on the unflattened DTB for the majority of parsing.
    (plus a minimal version on the FDT in order to bootstrap, also common)

(2) and (3) are tightly related. There's many reasons for wanting to use th=
e
unflattened blobs as much as possible. They range from quirks in specific "=
dtc"
versions, to complexities parsing phandles, to corner cases involving dupli=
cate
properties (i.e: due to .dtsi files), etc. Unflattening an FDT brings a
lots of "maybe-ok-after-sanitising" FDTs back into canonically correct DTs.

I'll share the PoC code as soon as as it's in a presentable state.
Hopefully by the end of the week. But I'm sending this ahead of time to
start collecting thoughts right away.

So. Thoughts?

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Wed May 21 14:36:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 14:36:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991969.1375747 (Exim 4.92)
	(envelope-from )
	id 1uHkYV-0007nt-0M; Wed, 21 May 2025 14:36:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991969.1375747; Wed, 21 May 2025 14: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 1uHkYU-0007nm-Sf; Wed, 21 May 2025 14:36:26 +0000
Received: by outflank-mailman (input) for mailman id 991969;
 Wed, 21 May 2025 14:36:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHkYT-0007GP-Ar
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 14:36:25 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f8df4325-3650-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 16:36:25 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43edecbfb46so55696815e9.0
 for ; Wed, 21 May 2025 07:36:24 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f381420fsm70544975e9.32.2025.05.21.07.36.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 07:36: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" 
X-Inumbo-ID: f8df4325-3650-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747838184; x=1748442984; 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;
        bh=1aU84GzIfkbPB3TPQ9rGHiXLRhubXlVpWyNiYxWgMW4=;
        b=IB9flyvqUziOFWQgWP+oO1zQLkhvF4pRc2RsVbJ8GAH/c4A2Vxpgs7urLMIHbRplIL
         kaYvLOk4/C3kxLx9r0TrrJ57/+don8PY00B1BZG2UFUq9vdyNK9eEUthQ0AdEQnvz3fF
         eG8daHD/IPWIFGF4T9hx0ZzWeXfJeTqtEWL34=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747838184; x=1748442984;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=1aU84GzIfkbPB3TPQ9rGHiXLRhubXlVpWyNiYxWgMW4=;
        b=Z5Tdrb+Ap+RQ/rkgvggXk1aGcLYDEXr3o9Xr9bxVKpOTW6vw2eQrcB/2kAu0HdYjQ7
         ae2x18TvQHQ8EcVgHapGxSJyJ3rLWIh3pXGrbCiw3DmvroDgUN5JGEYhh85WUqe5TqZF
         7msAzv58u4hsIx922kgkQvFvSTIm/QCvB2qtYIDq/sM64INr3Uw3ZMKjohqb+4qwwLBA
         5hs82XRJhlqpI0MvVxbZ9a4W2WP8EkLGjHkmM8++0Kc1xCJ2CWSXeQ4CV6n2+eHF/w7L
         W0i+Nkf8XjZ1Eovon25vq4/XUP7SgoQlh6bSzzCkOXIP5OW/CF4KePgG1/BikbvScGnf
         o3fg==
X-Gm-Message-State: AOJu0YwChV/G1SdjsxWEVHWPJIHY2qXBs8XjB1brYynhJ6yBhDZfdtYo
	6uEfzKVSTdnvRYE8+5NXGHFSmtMjWGVKxWCtLUtxtljXgx4wCnjz7qj5HZgZwtJI3mlc/blKnEb
	5gr0M
X-Gm-Gg: ASbGnctpGrT6pjMQ2lObzZpvAGgyUT6A9RiE4whSiYi6ADSQ2kNCtkXxNM6kfANNus+
	eOa1zxjK2IHlvT8C+Qu4VgJtG3cqJzEAbE5iThl1c7PfRAJsXPLqSTTZekcvmLH0b8A9F7M6YOO
	poLPqja/gFF03u9VsrJb5yBPNLKPFjknCum6EWOGYJEmE5oH+VHwtK3d4klaOj3KqYP/lK/VFXN
	z/lcTy1x58T5SO+b2LXslrHurA6bC43BuRvE4kpSVVXiTKaE1cfbi4KE4PkEocg7yrxswvq2R9+
	0+yZGPLtu5JtYWB/1bJTRNCc674cA3Qku+FeiMF9vLhKIkA6I2UlEvh0NhcqHtuuAD5PqVfLMOa
	lWoLFdUL3nzMgW1R9QFIXMQX/
X-Google-Smtp-Source: AGHT+IG4EUJcIrigNhEqNd8W8muA6o5VvT/ltWGgX5+hKTDDaByzkLX7rOV58sHStEpmKmag6ycwmw==
X-Received: by 2002:a05:600c:c05:b0:440:94a2:95b8 with SMTP id 5b1f17b1804b1-442feffc03dmr239976495e9.16.1747838184133;
        Wed, 21 May 2025 07:36:24 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/xstate: Rework xsetbv() to use asm goto()
Date: Wed, 21 May 2025 15:36:22 +0100
Message-Id: <20250521143622.311566-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

Switch to using a mnemonic, and asm_inline as there's EXTABLE metadata.

Update the types, and adjust parameter names.  The name xfeatures is specific
to xcr0, so rename to val to be more generic, even if there isn't another
writeable xcr yet.

No functional change.

Resolves: https://gitlab.com/xen-project/xen/-/work_items/212
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/xstate.c | 29 +++++++++++++++--------------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 3d249518a1b7..e8e218caed36 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -40,21 +40,22 @@ static DEFINE_PER_CPU(uint64_t, xcr0);
 /* Because XCR0 is cached for each CPU, xsetbv() is not exposed. Users should 
  * use set_xcr0() instead.
  */
-static inline bool xsetbv(u32 index, u64 xfeatures)
+static inline bool xsetbv(uint32_t xcr, uint64_t val)
 {
-    u32 hi = xfeatures >> 32;
-    u32 lo = (u32)xfeatures;
-
-    asm volatile ( "1: .byte 0x0f,0x01,0xd1\n"
-                   "3:                     \n"
-                   ".section .fixup,\"ax\" \n"
-                   "2: xor %0,%0           \n"
-                   "   jmp 3b              \n"
-                   ".previous              \n"
-                   _ASM_EXTABLE(1b, 2b)
-                   : "+a" (lo)
-                   : "c" (index), "d" (hi));
-    return lo != 0;
+    uint32_t hi = val >> 32, lo = val;
+
+    asm_inline goto (
+        "1: xsetbv\n\t"
+        _ASM_EXTABLE(1b, %l[fault])
+        :
+        : "a" (lo), "c" (xcr), "d" (hi)
+        :
+        : fault );
+
+    return true;
+
+ fault:
+    return false;
 }
 
 bool set_xcr0(u64 xfeatures)
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed May 21 14:37:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 14:37:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991979.1375756 (Exim 4.92)
	(envelope-from )
	id 1uHkZ6-0008Ka-8Q; Wed, 21 May 2025 14:37:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991979.1375756; Wed, 21 May 2025 14:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHkZ6-0008KT-4i; Wed, 21 May 2025 14:37:04 +0000
Received: by outflank-mailman (input) for mailman id 991979;
 Wed, 21 May 2025 14:37:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHkZ4-0007cs-TQ
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 14:37:02 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0e63b085-3651-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 16:37:01 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-43d0618746bso55999745e9.2
 for ; Wed, 21 May 2025 07:37:01 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f23c07bfsm72631465e9.23.2025.05.21.07.36.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 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" 
X-Inumbo-ID: 0e63b085-3651-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747838220; x=1748443020; 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;
        bh=SsF+xqOcNWx0UuYSVSIv0Shyn2lJXpUwn0fUWXAfkcg=;
        b=fL5iRpRkhkNScWV+N9uVrjXO13FrE1uuVDd7LNHP+rzuj86eUy3HWBcdFaTXgabye9
         bmL8XsTXqJ0XOdaWeBdKFN8DhFX34qN8wYlnMCNMAVjrJl5TJGs9UjM/BTCxyLRM38kO
         uK8iEP407icUmQaW80wuiJGIB7YeTGJHUPe5Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747838220; x=1748443020;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=SsF+xqOcNWx0UuYSVSIv0Shyn2lJXpUwn0fUWXAfkcg=;
        b=SWW3F1ne8IwH74FbGsJ0p6igx86zVuyuiTk4kwUNpPVdb60zTCp/yEtLKz1lrfO8EK
         wDxbRMnU78Q0y11v4ldgsVs2O9F9v2yM85LZPzJKpLIUef55Q48HaCNyFmOsViQgfmlF
         h3J+RhRhRpgXw5f4zJRELIr7OXsmDmS2s0hAK656doo2iIUVpC9nMCCCtM4RldWAtYo5
         HBHHWayCh2n6PkpFOJ/GTHEXuF/qbjZXiu/zkyykyw+1CjCr/ywMBPhStGzmOYzWZoz9
         cxsj+EisQ8r5Z4Q0dxfU90GA7P2Mkhnwbz5AqFAnZcZV5nHxwdTwKaY3INTQ9a00CEdG
         ijag==
X-Gm-Message-State: AOJu0YyASKpUeFA+TUHioMHaLStYWyH22NcF9Ir3r79xEXsb3QCDywz9
	66xMN4b7CiuVPyToeXcFfIKp7tFwrILmuVbaN2qdZ98gq3HGdEPDYTCm2mlvQ+lwHX6+FKBmLH8
	dZztu
X-Gm-Gg: ASbGncu8pIIUz2Z7yXpHDvvT7Sc/OnHT/Y+DpuuJT58zxWcvVMA0et3Qk+D7ANv/Bu2
	WpQ1l12lU80GGr8QlDQ3cJSqBA9zz5tFexEaKaMXfXbs5jK5NyegcRbyypLnux0NUtG6XLnYbZc
	nIDu+Q4m3bHQN7HAifPX3a/hO7yXdyqa6WpcK9VigMZZD5KnEk9Qfu95bhYamUtlFJMW+7a0PpA
	6k04uJRleXoNGdSpgi/GR9FYIOaFOU3v03v0ibhOlLmAJyO62mpZ4VXT9+IB034iwjV3plOIPmc
	fwb2aBdbHm3TTQNyx6l1puSId4afyHHx6fTXA3ESKmsneATZLGNkiIN8+HueoHxruvmH8Aymoau
	GFz7vI3qhBcQlu4YBVomLQFM3
X-Google-Smtp-Source: AGHT+IFWKoCLl+DCDDowO3fNcVlFbsc0m9RWCVSkdVvh/AQWPRUY4b7Zug36saFReF2JnxDg1R9IiA==
X-Received: by 2002:a05:600c:c059:20b0:445:49e:796b with SMTP id 5b1f17b1804b1-445049e81c3mr104866955e9.17.1747838220239;
        Wed, 21 May 2025 07:37:00 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/msr: Rework wrmsr_safe() using asm goto()
Date: Wed, 21 May 2025 15:36:58 +0100
Message-Id: <20250521143658.312514-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

This avoids needing to hold rc in a register across the WRMSR, and in most
cases removes direct testing and branching based on rc, as the fault label can
be rearranged to directly land on the out-of-line block.

No functional change.

Resolves: https://gitlab.com/xen-project/xen/-/work_items/214
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/include/asm/msr.h | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/include/asm/msr.h b/xen/arch/x86/include/asm/msr.h
index 0d3b1d637488..4c4f18b3a54d 100644
--- a/xen/arch/x86/include/asm/msr.h
+++ b/xen/arch/x86/include/asm/msr.h
@@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr, uint32_t lo, uint32_t hi)
 /* wrmsr with exception handling */
 static inline int wrmsr_safe(unsigned int msr, uint64_t val)
 {
-    int rc;
-    uint32_t lo, hi;
-    lo = (uint32_t)val;
-    hi = (uint32_t)(val >> 32);
-
-    __asm__ __volatile__(
-        "1: wrmsr\n2:\n"
-        ".section .fixup,\"ax\"\n"
-        "3: movl %5,%0\n; jmp 2b\n"
-        ".previous\n"
-        _ASM_EXTABLE(1b, 3b)
-        : "=&r" (rc)
-        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
-    return rc;
+    uint32_t lo = val, hi = val >> 32;
+
+    asm_inline goto (
+        "1: wrmsr\n\t"
+        _ASM_EXTABLE(1b, %l[fault])
+        :
+        : "a" (lo), "c" (msr), "d" (hi)
+        :
+        : fault );
+
+    return 0;
+
+ fault:
+    return -EFAULT;
 }
 
 static inline uint64_t msr_fold(const struct cpu_user_regs *regs)
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed May 21 14:42:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 14:42:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.991991.1375766 (Exim 4.92)
	(envelope-from )
	id 1uHke6-0001gZ-PO; Wed, 21 May 2025 14:42:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 991991.1375766; Wed, 21 May 2025 14:42: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 1uHke6-0001gS-Me; Wed, 21 May 2025 14:42:14 +0000
Received: by outflank-mailman (input) for mailman id 991991;
 Wed, 21 May 2025 14:42:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHke5-0001g2-CX
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 14:42:13 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c77eead0-3651-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 16:42:11 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ad53a96baf9so800476566b.3
 for ; Wed, 21 May 2025 07:42:11 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d04b073sm898590966b.27.2025.05.21.07.42.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 07:42: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" 
X-Inumbo-ID: c77eead0-3651-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747838531; x=1748443331; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Fm8dZemQlRt96oetnrEy09QGZuP7WE9DX8CaQgTbvYg=;
        b=WMASRhtirkZqKtdavi6N3/py3VmGXw3h5giUYdfEOYJFHxLlXsR3XUUHPpkX9JYboE
         SdsijY1r7/4VE4tAdqfwZSGTd6ZVya1axAAUebq3/jwUfulupb8c9RJrQZTYqzsNpXgg
         IsKpTin+kcXelPBBz9r02b/tbO6+gBhEr1kkYyoM/JRbOdPqVOUOEbV4tHOsL+xHiR02
         uUK3xmRfGqqUd2Bs/WcGH9HAcvZka5mnAWJhAnlshDV7VjJRwyrEIKJDWSgUP2HljAgp
         Dm8nlMowwB5DifS/Tlc/HKIUbpnEJfObknHwBcQndwyoF5GRyKoEVZk09TJNIx2U2NRz
         WYog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747838531; x=1748443331;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Fm8dZemQlRt96oetnrEy09QGZuP7WE9DX8CaQgTbvYg=;
        b=NdPl28smt0R4PnKuJ5I7shg8vXNUAqeG0YUi9AjZ6ZShNRA94zBAvinpRrNM8ioj2k
         spVSdv23YYORgKkQix0fBEt0uWiP6JKtjrv4+ua2fhUM9UbU+HcRhj6QK3v0YB9p5fXH
         i6NbbUwHOJOH+UHjXx28KnURIXUH5XnR1Y8CH+osV4zME+/QsjRmzntda/EThA20TajE
         Ak/x10qSgSkjt1bwzgozXlTLwcegF8AXAC7TDPpr/PHF62tJIHdaNzB9Mv4cI/Zc78O3
         nKIwFt1cRRGNLKgH44aNa9icZY5MBUUic4dyrqCa9Gx3OIfSpoJJL7fLxA3YOcrcfVE4
         ztIQ==
X-Forwarded-Encrypted: i=1; AJvYcCWBHPvxci1eWAcng59Zbdoq3k2AOJWOp5KeaesE4C2nIyBpeb8tmHm88vIX50YZQLPGKpkfiaPfTlw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzRrAQaXUMr1DX9YvPM2gN90ittYbGnqODClTTFZ/W/bRc2QwVM
	MEtgIYFKoHtY8I2dpFt5S/G4Gy61Mip9dvyUq0eeCpY+k5zeaE3XKHdPl4mNcGFCsQ==
X-Gm-Gg: ASbGncva/K3AcFw4onvlj5igxB6ya2+4faZNNoaC+m1muwpEzKXRkgfpKlXrf2lqrTW
	ZAqi+bP/UqYtxD1zc1RUrNs5uuKVrzdDUTyeBk0WY5P8e39Cjomj63RngkLdin5c1L7rb4kHMxK
	tzBDLqoOYMnIV0ZrKzrQ0Ca6tnpwgu01/71JafM7Fc4AlLvCZmM0KlauLClBzoeretXkBntPOSz
	7fsOXClyXAB41G9syaikNow2z1qDWEoYZ5ctLw45OV9ZT/2g0Nj1mfHArKRUzxMRijCQVBE3yh4
	iFUV0bLMLmBWZlonJiNobRkU22NP5rdJaOgfH0zOBTZbYoeLYMfYUH3bgCOA3u0lg4NN770t
X-Google-Smtp-Source: AGHT+IHPmqnesP22p+YCh5P/RuB9mzR9mwqMKDdeYQ3Weh8TRyY+4IrNpFLqOf8zUtKR+VQtjmJ76g==
X-Received: by 2002:a17:906:f5a0:b0:aca:b72b:4576 with SMTP id a640c23a62f3a-ad52d509d1dmr1846497966b.33.1747838531096;
        Wed, 21 May 2025 07:42:11 -0700 (PDT)
Message-ID: 
Date: Wed, 21 May 2025 16:42:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Hyperlaunch/dom0less code sharing
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 "Daniel P. Smith" ,
 Michal Orzel , Jason Andryuk ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Xenia Ragiadakou , xen-devel@lists.xenproject.org
References: 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 16:35, Alejandro Vallejo wrote:
> I think we should aim to share binding code wherever possible, using common
> datastructures (kernel_info and bootmodule) as dumping ground for the results
> of the binding parsing functions. I seek agreement on the following 3 points
> for the end goal of DTB multidomain boots on x86 before I start slicing
> my hacks into reasonable chunks.
> 
>   1. We want common data structures, with arch-specific fields to hold
>      information from xen,domain DT nodes
>   2. We want to have a single collection of DTB parsers in the code.
>   3. We want to operate on the unflattened DTB for the majority of parsing.
>     (plus a minimal version on the FDT in order to bootstrap, also common)

+1 on all three, with the caveat that I'm far from being an expert on DT.

Jan

> (2) and (3) are tightly related. There's many reasons for wanting to use the
> unflattened blobs as much as possible. They range from quirks in specific "dtc"
> versions, to complexities parsing phandles, to corner cases involving duplicate
> properties (i.e: due to .dtsi files), etc. Unflattening an FDT brings a
> lots of "maybe-ok-after-sanitising" FDTs back into canonically correct DTs.
> 
> I'll share the PoC code as soon as as it's in a presentable state.
> Hopefully by the end of the week. But I'm sending this ahead of time to
> start collecting thoughts right away.
> 
> So. Thoughts?
> 
> Cheers,
> Alejandro



From xen-devel-bounces@lists.xenproject.org Wed May 21 14:46:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 14:46:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992001.1375778 (Exim 4.92)
	(envelope-from )
	id 1uHki4-0002GE-8j; Wed, 21 May 2025 14:46:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992001.1375778; Wed, 21 May 2025 14: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 1uHki4-0002G7-4A; Wed, 21 May 2025 14:46:20 +0000
Received: by outflank-mailman (input) for mailman id 992001;
 Wed, 21 May 2025 14:46:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHki3-0002G1-F9
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 14:46:19 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5aacd138-3652-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 16:46:18 +0200 (CEST)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-ad5533c468cso651274766b.0
 for ; Wed, 21 May 2025 07:46:18 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d047c30sm905384066b.6.2025.05.21.07.46.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 07:46: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" 
X-Inumbo-ID: 5aacd138-3652-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747838778; x=1748443578; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=FVFet3xoWefKKVawYbCCRbLAxEdKpBbFXS6HzUTlXSM=;
        b=HQR1Bk24Vp15P4AkuoEa9z5YH7jHCxB6KtdBYjB0EzZZBAr69uCbqdVU3EXVeNL5Yr
         pNRKepAeomQ1udeLAwv9v0rk4Eo+LDUfcOXShFS1Ki40UIkU0kGvfQVzPaFyE+7bWNPe
         +6nGXK9edYSnElzfXQtcVDMFXF9zpo16haa6FByRHLV0IFU2Ka4h1vFpEgbLZXUBePaZ
         dNZA/YB+4/BwsHXfSciSGnysNHfmNIjJzLBdGsXPmrmRSpw4j/7zIkyasvyq9DqHPdgh
         5EUABO9677uCwYt2jKsZjAR6XcU+7O6Treva8sZ7ridwnn800/PsJJ0jYpKjopp6RWAi
         6o/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747838778; x=1748443578;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=FVFet3xoWefKKVawYbCCRbLAxEdKpBbFXS6HzUTlXSM=;
        b=aThB+AXWpMkIB6f7+z/lB0P6f9v8sOYwOf5bPrZmns6s2MYKr6B/o7TsmnO+P08j9d
         5DWjDAZcMfwetBZp4MwVdqSsm2d6YIeDJyP/Jphx8zCH0vPBVYWBWiUNJKQT9DptjTZN
         t6CKGyV6en0nhh6GtA9/rBbbA7oLMeOq3Oj3p9fT5bqkHxuCkVipfV4508HLtbNDBqgM
         mfUi58vDFFvDFH2Cuml+4mDeZmQ4yFYw5nzkQxKw3X4mvbjrK5qGp9GzYnhoIutzW7pX
         OF+fwCxHVp/2QdOrdSocNGsFb6M08+gTPzU6gS8XmHsD6T+SXRGaycsgaEeisBPhtszP
         8JyA==
X-Forwarded-Encrypted: i=1; AJvYcCXX/jDiyd0SO60vgETMuTWHYnJGdCQEJsnbOWNBhph/5aLpAwL+LmIWGwNLkDG4S2qCvvN6M78GV2g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwdhHUw8OIOIG33x/HcV5qzOalRZ0MwL2jU6zgsMsoWTgf55GuE
	3t5k2RJm3byZYsR4UaCAt+sxYx42v6vxre6jQaEh0OOEy0EyoyzVKxStk5b7Fgm7Vw==
X-Gm-Gg: ASbGncsJKClmjibmbh9mW1lPfXp2ycuCfngmEowv/ypsoTt/VZpwFN1nQRUVqG4/8l2
	Qb39gRtLmvsfUIlrr6Fr6E7VKUOJ/5Y2xSCzd6QJHELBg1ksjGRbUzqPHslpDFhoudTFnzwEisN
	eL8l290koGmvjU3YGbTse1U/MMfsJF9ygBHQSENM/WQWbSOg2KxNg1tmJnHrnNBCAFtBoRZAub3
	QBaMmHI1V4Mryllr87tbAmfi57bH6GLyRcW6vybgpCod1wxXBSGeVKeMRS+M5X1JGGILmHj62BL
	pKREBPYjR7tNieAn7T8X5rGM9uUGBvc5zLSjedV4OLsSBz431p6L6+/GGSdLDg==
X-Google-Smtp-Source: AGHT+IFKhbCYh6veQxMiAAEatLbcddhtrN1lGye6RI2wR8d7Wrj0yVZ4kUQWHaKbhCCHUqemYdOZhQ==
X-Received: by 2002:a17:906:6a19:b0:acb:34b2:851 with SMTP id a640c23a62f3a-ad536f9d598mr1635099866b.44.1747838777940;
        Wed, 21 May 2025 07:46:17 -0700 (PDT)
Message-ID: <3256d638-8f6b-4eab-98ae-d8afb23cc51f@suse.com>
Date: Wed, 21 May 2025 16:46:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/xstate: Rework xsetbv() to use asm goto()
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250521143622.311566-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250521143622.311566-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 16:36, Andrew Cooper wrote:
> Switch to using a mnemonic, and asm_inline as there's EXTABLE metadata.
> 
> Update the types, and adjust parameter names.  The name xfeatures is specific
> to xcr0, so rename to val to be more generic, even if there isn't another
> writeable xcr yet.
> 
> No functional change.
> 
> Resolves: https://gitlab.com/xen-project/xen/-/work_items/212
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Wed May 21 14:48:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 14:48:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992007.1375787 (Exim 4.92)
	(envelope-from )
	id 1uHkjb-0002ll-HI; Wed, 21 May 2025 14:47:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992007.1375787; Wed, 21 May 2025 14: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 1uHkjb-0002le-Dg; Wed, 21 May 2025 14:47:55 +0000
Received: by outflank-mailman (input) for mailman id 992007;
 Wed, 21 May 2025 14:47:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHkjZ-0002lW-Oj
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 14:47:53 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 92c813f9-3652-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 16:47:52 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad1b94382b8so1237531066b.0
 for ; Wed, 21 May 2025 07:47:52 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4ca358sm913936766b.159.2025.05.21.07.47.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 07:47: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" 
X-Inumbo-ID: 92c813f9-3652-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747838872; x=1748443672; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=I11EPxNNEPGD7g2jhrcCT0d4xhyVr3ZAmyjybLrYLBk=;
        b=WSMVuF4fKiPg6HZehKOWSU8TXgtMumOkkEDYYyLLq4nNokAIqAYX4vJDy8m6DVjjFp
         fvqfpdMxVsXqmsxsbVxp2aIGSqhWDTCL//uJZb0M9790cyJFy9dDzyf4Bze0jiy5wgIY
         g5w9jP8aB7CGtbOyqk2JyiF40wIit8Bb3xtsXmLG/ytDIT+9jd0e2+zM9Elr4IVzmZuv
         1kWFwgKTcJZ3mCw9ZHitalb45LQXJvtGSwaNYnudYnRq6BRFfBxo2uqcTFI6imqZZ5Fj
         OFe2FYbbj4Ky667015KRZ379+j260GXDYopSgzLKV/SsAy7wAxA06qa+mDs7ORZZWqKZ
         M5lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747838872; x=1748443672;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=I11EPxNNEPGD7g2jhrcCT0d4xhyVr3ZAmyjybLrYLBk=;
        b=WgngR4odUAUnIzteKOTcqg8ZT2r0V7W+6K8poohWa64pt1jEJwp0fOTb2vgi3+kVzK
         5CGW/BImvkpn5tR6TuUmk7RA0DLFrMDsyXYdLfvj2Z55YT+uIQXhlMO3xKLOtpeEEwDP
         V7jUeC7Dljc2UQ2mH4C96PV4mbba+djCRL46u8VsTCweB9t+ufDcJPh4ZCBYLHcBaE4g
         7z3bDYbkZ2tfF1saTvSwtGmmgOKnrQ0aV87ZwjK1jX6r6MUKYjbbPjAlIpRv8rpmlf7h
         JzCUCMoZBUc6g7L8EzI+uoM7Jcq6o/snyh/vIeF7i+JVfFVpHJkFfiv4nf8a0Btg/Dgv
         02bw==
X-Forwarded-Encrypted: i=1; AJvYcCXZm7u/JhsmwJD4BcP4DmuhV7JithfIrxFKY15To1NvRuh1xZFZVF05+Le+Us17RDf2OOXCPfRk9Oc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwnZzfDQhYS7sBc/iAzRwbWAFGn/d0MVizUyjjTLz4Ll1xfAF1z
	CYP9E/iT65IR93iqEhC6A3Xf8R+jAuxVS+WIHeB11HMokSRNBxa80xv+P0/lI5iqZQ==
X-Gm-Gg: ASbGncvc8pB6YasmwRi+vGTC3k+RqdwHfdvW3yuPegXNvxQ5VT4Z70kq0INbOkLPG8Q
	wMs9hhHTK5YRcVcFEskps2mu/Vr7INDvisL64nbQirRGQRnkMm/cfDDJzXzkkYr5KQo+4QPTKru
	yoLfA+j0OUKD/WCfV261l3GlybPWtFE52BJ8yv2RbtUguyNvULTNeUOwtz0x3rTzp7G+1ZWI5OY
	azGGWb13f6rmBzjgcbSHmavoCAsf4qQ170zzMlyaEMPp7o80LPfkM5g+brMffcaVjLcHfsXrz+O
	Mg4eXfRbODo8zf62TbUcNBV2VywxkBjupxuWo7nJ6Jw2rTiY8l3M0CgPIUth5g==
X-Google-Smtp-Source: AGHT+IGZHZccmCQs0Jn3cIQNzAIMXuwLc0gthHUvMDJhxfOVtkc//+W9fidYfngK2riTbbpr9KKQEw==
X-Received: by 2002:a17:907:9814:b0:acb:b1be:4873 with SMTP id a640c23a62f3a-ad52d45ac94mr1761083866b.2.1747838872053;
        Wed, 21 May 2025 07:47:52 -0700 (PDT)
Message-ID: 
Date: Wed, 21 May 2025 16:47:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/msr: Rework wrmsr_safe() using asm goto()
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: <20250521143658.312514-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250521143658.312514-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 16:36, Andrew Cooper wrote:
> This avoids needing to hold rc in a register across the WRMSR, and in most
> cases removes direct testing and branching based on rc, as the fault label can
> be rearranged to directly land on the out-of-line block.
> 
> No functional change.
> 
> Resolves: https://gitlab.com/xen-project/xen/-/work_items/214
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Wed May 21 14:55:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 14:55:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992015.1375796 (Exim 4.92)
	(envelope-from )
	id 1uHkqX-0004ZU-6l; Wed, 21 May 2025 14:55:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992015.1375796; Wed, 21 May 2025 14:55: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 1uHkqX-0004ZN-3r; Wed, 21 May 2025 14:55:05 +0000
Received: by outflank-mailman (input) for mailman id 992015;
 Wed, 21 May 2025 14:55:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHkqV-0004ZH-Lb
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 14:55:03 +0000
Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com
 [2607:f8b0:4864:20::c30])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9258843a-3653-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 16:55:02 +0200 (CEST)
Received: by mail-oo1-xc30.google.com with SMTP id
 006d021491bc7-604f0d27c24so3655278eaf.2
 for ; Wed, 21 May 2025 07:55:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9258843a-3653-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747839301; x=1748444101; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GLe/VFOV+IGfsar9eaNwR5XIUVZBcoWh0JazlUMDS3g=;
        b=u3r92UEG61gqc+LTRH3K93/uLxnMKOu+M+mOvc3xJyNysmtrhJHPN/iPar4NK5rBsJ
         +DFEPRcq5uAIseFslj8oJwYt4Nnb3JU4VzATB6HhF+0RKH9+RMTv76c3sY+WJqc33HJH
         +W9IHeDkgYQZribZ9pS5NbuYhTXP++yGJCvKnZ6eGKk1YSsEe9SqruTlCvwrX7WzA2B8
         7PXqstX35vTM4kdZ/nZItNmytyDMyu4k3zxOuY4caxp4DD89QiXnNtXj3b1M1Z8anu2a
         714slngfAPl6BE2uEhyYKv32fdyNnGQjft5aSmws7z6ZEm2Vr3dkCfRbtCeSJYwUfiQA
         IsiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747839301; x=1748444101;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GLe/VFOV+IGfsar9eaNwR5XIUVZBcoWh0JazlUMDS3g=;
        b=rc+IxEmFZzHcPmyL54hPcMJVRIvClKETX+1ViBZ6rHruwGOiJRfKxvEfsRTiOUGaPe
         ejUc+hHAQHgIrXu/qSpVUPyRTQQn0SZV0SnQAYabszfhJoUmfbXJQAbrGJPGT3YNSgwM
         3THkVXIY9E8BTmAgaUPB2OiUnMD1u3sEe9mU27uj9PIlSQwvxbjo63n+EefEDn88QFiM
         NqyDI7m3Y/48jHEh/hAon5js7djsuFMbIo7+uC/URk/SnGhW+L3prtwawLK70PzTkWcw
         Pv+N6HIKcMU/WBJ+eivAzuDfyE9W86MKrm80yy5TTEo510CH34+IJeWhEdQSzXjSieYs
         V5sg==
X-Gm-Message-State: AOJu0Yw2D2YeZqiLvVYJgIBeOWrcVNkb0wQjW6PsBu72Qg6uLI4dD6Kv
	H3IcPngctRYK7bDCp61aQjwD4WAofpNZw/isb5xlZGdiwg2caUSZALHAarYrVzobV+Nu66tWpe6
	+ANfXctiPSYxSWUeDjFBPHK+NB6nODuhUAYKXPZ3suw==
X-Gm-Gg: ASbGncuR/8p70wysUD4Vt8vv1R1muiie/QKfgKNslHvMDn68B3jSyL3PEm9rMiCaEMI
	r9O3tTcpu8nhD1eE+MFyBCBu7cX5CPcPmL6LwtbFC4vwfmx9upmTxKK6c7apD6IFtb/G2ZewzoO
	s+L+NeTM5q1eiw7tIOadvyP3TbLDrg2yiacA==
X-Google-Smtp-Source: AGHT+IEo1PpFCKo90cnsuy5cZCEtznjaKaZNU0yrwFfKwUSppTsca4zVUQ/OOnUg0JlHolE9CqWZ95DZMNqQVMdbfNc=
X-Received: by 2002:a4a:ec49:0:b0:607:dd61:9c33 with SMTP id
 006d021491bc7-609f48646b0mr11736797eaf.1.1747839300425; Wed, 21 May 2025
 07:55:00 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Jens Wiklander 
Date: Wed, 21 May 2025 16:54:48 +0200
X-Gm-Features: AX0GCFsmxtGpIi5ZdXIRj2BMuQlwA0VWsivBb-tOdfpmLD04eqyGLTVgTlYi9wQ
Message-ID: 
Subject: Re: [PATCH v5 3/6] xen/arm: ffa: Introduce VM to VM support
To: Bertrand Marquis 
Cc: xen-devel@lists.xenproject.org, 
	Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Michal Orzel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bertrand,

On Wed, Apr 16, 2025 at 9:40=E2=80=AFAM Bertrand Marquis
 wrote:
>
> Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
> between VMs.
> When activated list VMs in the system with FF-A support in part_info_get.
>
> When VM to VM is activated, Xen will be tainted as Insecure and a
> message is displayed to the user during the boot as there is no
> filtering of VMs in FF-A so any VM can communicate or see any other VM
> in the system.
>
> WARNING: There is no filtering for now and all VMs are listed !!
>
> This patch is reorganizing the ffa_ctx structure to make clear which
> lock is protecting what parts.
>
> This patch is introducing a chain list of the ffa_ctx with a FFA Version
> negociated allowing to create the partinfo results for VMs without
> taking a lock on the global domain list in Xen.
>
> Signed-off-by: Bertrand Marquis 
> ---
> Changes in v5:
> - remove invalid comment about 1.1 firmware support
> - rename variables from d and dom to curr_d and dest_d (Julien)
> - add a TODO in the code for potential holding for long of the CPU
>   (Julien)
> - use an atomic global variable to store the number of VMs instead of
>   recomputing the value each time (Julien)
> - add partinfo information in ffa_ctx (id, cpus and 64bit) and create a
>   chain list of ctx. Use this chain list to create the partinfo result
>   without holding a global lock to prevent concurrency issues.
> - Move some changes in a preparation patch modifying partinfo for sps to
>   reduce this patch size and make the review easier
> Changes in v4:
> - properly handle SPMC version 1.0 header size case in partinfo_get
> - switch to local counting variables instead of *pointer +=3D 1 form
> - coding style issue with missing spaces in if ()
> Changes in v3:
> - break partinfo_get in several sub functions to make the implementation
>   easier to understand and lock handling easier
> - rework implementation to check size along the way and prevent previous
>   implementation limits which had to check that the number of VMs or SPs
>   did not change
> - taint Xen as INSECURE when VM to VM is enabled
> Changes in v2:
> - Switch ifdef to IS_ENABLED
> - dom was not switched to d as requested by Jan because there is already
>   a variable d pointing to the current domain and it must not be
>   shadowed.
> ---
>  xen/arch/arm/tee/Kconfig        |  11 ++++
>  xen/arch/arm/tee/ffa.c          |  47 +++++++++++++-
>  xen/arch/arm/tee/ffa_partinfo.c |  95 ++++++++++++++++++++++++---
>  xen/arch/arm/tee/ffa_private.h  | 112 ++++++++++++++++++++++++++------
>  4 files changed, 233 insertions(+), 32 deletions(-)
>
> diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
> index c5b0f88d7522..88a4c4c99154 100644
> --- a/xen/arch/arm/tee/Kconfig
> +++ b/xen/arch/arm/tee/Kconfig
> @@ -28,5 +28,16 @@ config FFA
>
>           [1] https://developer.arm.com/documentation/den0077/latest
>
> +config FFA_VM_TO_VM
> +    bool "Enable FF-A between VMs (UNSUPPORTED)" if UNSUPPORTED
> +    default n
> +    depends on FFA
> +    help
> +      This option enables to use FF-A between VMs.
> +      This is experimental and there is no access control so any
> +      guest can communicate with any other guest.
> +
> +      If unsure, say N.
> +
>  endmenu
>
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 3bbdd7168a6b..c1c4c0957091 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -118,6 +118,13 @@ void *ffa_tx __read_mostly;
>  DEFINE_SPINLOCK(ffa_rx_buffer_lock);
>  DEFINE_SPINLOCK(ffa_tx_buffer_lock);
>
> +struct list_head ffa_ctx_head;
> +/* Lock to protect addition/removal in ffa_ctx_head */
> +DEFINE_SPINLOCK(ffa_ctx_list_lock);
> +
> +#ifdef CONFIG_FFA_VM_TO_VM
> +atomic_t ffa_vm_count;
> +#endif
>
>  /* Used to track domains that could not be torn down immediately. */
>  static struct timer ffa_teardown_timer;
> @@ -160,10 +167,21 @@ static void handle_version(struct cpu_user_regs *re=
gs)
>       */
>      if ( FFA_VERSION_MAJOR(vers) =3D=3D FFA_MY_VERSION_MAJOR )
>      {
> +        uint32_t old_vers =3D ACCESS_ONCE(ctx->guest_vers);
> +
>          if ( FFA_VERSION_MINOR(vers) > FFA_MY_VERSION_MINOR )
> -            ctx->guest_vers =3D FFA_MY_VERSION;
> +            ACCESS_ONCE(ctx->guest_vers) =3D FFA_MY_VERSION;
>          else
> -            ctx->guest_vers =3D vers;
> +            ACCESS_ONCE(ctx->guest_vers) =3D vers;

What is the ACCESS_ONCE() scheme intended for?

> +
> +        if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !old_vers )

If handle_version() is called concurrently on two CPUs, it might be
possible for a context to be added twice.
How about a separate flag to indicate whether a context has been added
to the list?

Cheers,
Jens

> +        {
> +            /* One more VM with FF-A support available */
> +            inc_ffa_vm_count();
> +            spin_lock(&ffa_ctx_list_lock);
> +            list_add_tail(&ctx->ctx_list, &ffa_ctx_head);
> +            spin_unlock(&ffa_ctx_list_lock);
> +        }
>      }
>      ffa_set_regs(regs, FFA_MY_VERSION, 0, 0, 0, 0, 0, 0, 0);
>  }
> @@ -345,6 +363,10 @@ static int ffa_domain_init(struct domain *d)
>      ctx->teardown_d =3D d;
>      INIT_LIST_HEAD(&ctx->shm_list);
>
> +    ctx->ffa_id =3D ffa_get_vm_id(d);
> +    ctx->num_vcpus =3D d->max_vcpus;
> +    ctx->is_64bit =3D is_64bit_domain(d);
> +
>      /*
>       * ffa_domain_teardown() will be called if ffa_domain_init() returns=
 an
>       * error, so no need for cleanup in this function.
> @@ -421,6 +443,14 @@ static int ffa_domain_teardown(struct domain *d)
>      if ( !ctx )
>          return 0;
>
> +    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) && ACCESS_ONCE(ctx->guest_vers)=
 )
> +    {
> +        dec_ffa_vm_count();
> +        spin_lock(&ffa_ctx_list_lock);
> +        list_del(&ctx->ctx_list);
> +        spin_unlock(&ffa_ctx_list_lock);
> +    }
> +
>      ffa_rxtx_domain_destroy(d);
>      ffa_notif_domain_destroy(d);
>
> @@ -464,6 +494,18 @@ static bool ffa_probe(void)
>      printk(XENLOG_INFO "ARM FF-A Mediator version %u.%u\n",
>             FFA_MY_VERSION_MAJOR, FFA_MY_VERSION_MINOR);
>
> +    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> +    {
> +        /*
> +         * When FFA VM to VM is enabled, the current implementation does=
 not
> +         * offer any way to limit which VM can communicate with which VM=
 using
> +         * FF-A.
> +         * Signal this in the xen console and taint the system as insecu=
re.
> +         * TODO: Introduce a solution to limit what a VM can do through =
FFA.
> +         */
> +        printk(XENLOG_ERR "ffa: VM to VM is enabled, system is insecure =
!!\n");
> +        add_taint(TAINT_MACHINE_INSECURE);
> +    }
>      /*
>       * psci_init_smccc() updates this value with what's reported by EL-3
>       * or secure world.
> @@ -538,6 +580,7 @@ static bool ffa_probe(void)
>
>      ffa_notif_init();
>      INIT_LIST_HEAD(&ffa_teardown_head);
> +    INIT_LIST_HEAD(&ffa_ctx_head);
>      init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NULL, 0=
);
>
>      return true;
> diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_parti=
nfo.c
> index e524445c6fb8..66ea1860e97a 100644
> --- a/xen/arch/arm/tee/ffa_partinfo.c
> +++ b/xen/arch/arm/tee/ffa_partinfo.c
> @@ -149,6 +149,68 @@ out:
>      spin_unlock(&ffa_rx_buffer_lock);
>      return ret;
>  }
> +
> +static int32_t ffa_get_vm_partinfo(uint32_t *vm_count, void *dst_buf,
> +                                   void *end_buf, uint32_t dst_size)
> +{
> +    struct ffa_ctx *curr_ctx =3D current->domain->arch.tee;
> +    struct ffa_ctx *dest_ctx, *tmp;
> +    uint32_t count =3D 0;
> +
> +    /*
> +     * There could potentially be a lot of VMs in the system and we coul=
d
> +     * hold the CPU for long here.
> +     * Right now there is no solution in FF-A specification to split
> +     * the work in this case.
> +     * TODO: Check how we could delay the work or have preemption checks=
.
> +     */
> +    list_for_each_entry_safe(dest_ctx, tmp, &ffa_ctx_head, ctx_list)
> +    {
> +        /*
> +         * Do not include an entry for the caller VM as the spec is not
> +         * clearly mandating it and it is not supported by Linux.
> +         */
> +        if ( dest_ctx !=3D curr_ctx )
> +        {
> +            /*
> +             * We do not have UUID info for VMs so use
> +             * the 1.0 structure so that we set UUIDs to
> +             * zero using memset
> +             */
> +            struct ffa_partition_info_1_0 info;
> +
> +            if  ( dst_buf > (end_buf - dst_size) )
> +            {
> +                return FFA_RET_NO_MEMORY;
> +            }
> +
> +            /*
> +             * Context might has been removed since we go it or being re=
moved
> +             * right now so we might return information for a VM not exi=
sting
> +             * anymore. This is acceptable as we return a view of the sy=
stem
> +             * which could change at any time.
> +             */
> +            info.id =3D dest_ctx->ffa_id;
> +            info.execution_context =3D dest_ctx->num_vcpus;
> +            info.partition_properties =3D FFA_PART_VM_PROP;
> +            if ( dest_ctx->is_64bit )
> +                info.partition_properties |=3D FFA_PART_PROP_AARCH64_STA=
TE;
> +
> +            memcpy(dst_buf, &info, MIN(sizeof(info), dst_size));
> +
> +            if ( dst_size > sizeof(info) )
> +                memset(dst_buf + sizeof(info), 0,
> +                       dst_size - sizeof(info));
> +
> +            dst_buf +=3D dst_size;
> +            count++;
> +        }
> +    }
> +    *vm_count =3D count;
> +
> +    return FFA_RET_OK;
> +}
> +
>  void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
>  {
>      int32_t ret =3D FFA_RET_OK;
> @@ -163,7 +225,7 @@ void ffa_handle_partition_info_get(struct cpu_user_re=
gs *regs)
>      };
>      uint32_t dst_size =3D 0;
>      void *dst_buf, *end_buf;
> -    uint32_t ffa_sp_count =3D 0;
> +    uint32_t ffa_vm_count =3D 0, ffa_sp_count =3D 0;
>
>      /*
>       * If the guest is v1.0, he does not get back the entry size so we m=
ust
> @@ -190,15 +252,18 @@ void ffa_handle_partition_info_get(struct cpu_user_=
regs *regs)
>          }
>
>          if ( ffa_fw_supports_fid(FFA_PARTITION_INFO_GET) )
> +        {
>              ret =3D ffa_get_sp_count(uuid, &ffa_sp_count);
> +            if ( ret )
> +                goto out;
> +        }
>
> -        goto out;
> -    }
> +        /*
> +         * Do not count the caller VM as the spec is not clearly mandati=
ng it
> +         * and it is not supported by Linux.
> +         */
> +        ffa_vm_count =3D get_ffa_vm_count() - 1;
>
> -    if ( !ffa_fw_supports_fid(FFA_PARTITION_INFO_GET) )
> -    {
> -        /* Just give an empty partition list to the caller */
> -        ret =3D FFA_RET_OK;
>          goto out;
>      }
>
> @@ -223,9 +288,19 @@ void ffa_handle_partition_info_get(struct cpu_user_r=
egs *regs)
>          goto out_rx_release;
>      }
>
> -    ret =3D ffa_get_sp_partinfo(uuid, &ffa_sp_count, dst_buf, end_buf,
> -                              dst_size);
> +    if ( ffa_fw_supports_fid(FFA_PARTITION_INFO_GET) )
> +    {
> +        ret =3D ffa_get_sp_partinfo(uuid, &ffa_sp_count, dst_buf, end_bu=
f,
> +                                  dst_size);
> +
> +        if ( ret )
> +            goto out_rx_release;
> +
> +        dst_buf +=3D ffa_sp_count * dst_size;
> +    }
>
> +    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> +        ret =3D ffa_get_vm_partinfo(&ffa_vm_count, dst_buf, end_buf, dst=
_size);
>
>  out_rx_release:
>      if ( ret )
> @@ -234,7 +309,7 @@ out:
>      if ( ret )
>          ffa_set_regs_error(regs, ret);
>      else
> -        ffa_set_regs_success(regs, ffa_sp_count, dst_size);
> +        ffa_set_regs_success(regs, ffa_sp_count + ffa_vm_count, dst_size=
);
>  }
>
>  static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat=
e.h
> index 0a9c1082db28..52c1078b06f4 100644
> --- a/xen/arch/arm/tee/ffa_private.h
> +++ b/xen/arch/arm/tee/ffa_private.h
> @@ -195,6 +195,18 @@
>   */
>  #define FFA_PARTITION_INFO_GET_COUNT_FLAG BIT(0, U)
>
> +/*
> + * Partition properties we give for a normal world VM:
> + * - can send direct message but not receive them
> + * - can handle indirect messages
> + * - can receive notifications
> + * 32/64 bit flag is set depending on the VM
> + */
> +#define FFA_PART_VM_PROP    (FFA_PART_PROP_DIRECT_REQ_SEND | \
> +                             FFA_PART_PROP_INDIRECT_MSGS | \
> +                             FFA_PART_PROP_RECV_NOTIF | \
> +                             FFA_PART_PROP_IS_PE_ID)
> +
>  /* Flags used in calls to FFA_NOTIFICATION_GET interface  */
>  #define FFA_NOTIF_FLAG_BITMAP_SP        BIT(0, U)
>  #define FFA_NOTIF_FLAG_BITMAP_VM        BIT(1, U)
> @@ -297,36 +309,66 @@ struct ffa_ctx_notif {
>  };
>
>  struct ffa_ctx {
> -    void *rx;
> -    const void *tx;
> -    struct page_info *rx_pg;
> -    struct page_info *tx_pg;
> -    /* Number of 4kB pages in each of rx/rx_pg and tx/tx_pg */
> -    unsigned int page_count;
> +    /*
> +     * Chain list of all FF-A contexts, to prevent locking access to thi=
s list,
> +     * all "unlocked" data from the structure must be set before adding =
an
> +     * entry in the list and an entry must be removed from the list befo=
re
> +     * freeing a context.
> +     */
> +    struct list_head ctx_list; /* chain list of all FF-A contexts */
> +
> +    /*
> +     * Data access unlocked (mainly for part_info_get in VM to VM).
> +     * Those should be set before the ctx is added in the list.
> +     */
> +    /* FF-A Endpoint ID */
> +    uint16_t ffa_id;
> +    uint16_t num_vcpus;
> +    bool is_64bit;
> +
> +    /*
> +     * Global data accessed atomically or using ACCES_ONCE.
> +     */
>      /* FF-A version used by the guest */
>      uint32_t guest_vers;
> -    bool rx_is_free;
> -    /* Used shared memory objects, struct ffa_shm_mem */
> -    struct list_head shm_list;
> +    struct ffa_ctx_notif notif;
> +
> +    /*
> +     * Global data accessed with lock locked.
> +     */
> +    spinlock_t lock;
> +    /* Number of 4kB pages in each of rx/rx_pg and tx/tx_pg */
> +    unsigned int page_count;
>      /* Number of allocated shared memory object */
>      unsigned int shm_count;
> -    struct ffa_ctx_notif notif;
> +    /* Used shared memory objects, struct ffa_shm_mem */
> +    struct list_head shm_list;
> +
>      /*
> -     * tx_lock is used to serialize access to tx
> -     * rx_lock is used to serialize access to rx_is_free
> -     * lock is used for the rest in this struct
> +     * Rx buffer, accessed with rx_lock locked.
> +     * rx_is_free is used to serialize access.
>       */
> -    spinlock_t tx_lock;
>      spinlock_t rx_lock;
> -    spinlock_t lock;
> -    /* Used if domain can't be torn down immediately */
> +    bool rx_is_free;
> +    void *rx;
> +    struct page_info *rx_pg;
> +
> +    /*
> +     * Tx buffer, access with tx_lock locked.
> +     */
> +    spinlock_t tx_lock;
> +    const void *tx;
> +    struct page_info *tx_pg;
> +
> +
> +    /*
> +     * Domain teardown handling if data shared or used by other domains
> +     * do not allow to teardown the domain immediately.
> +     */
>      struct domain *teardown_d;
>      struct list_head teardown_list;
>      s_time_t teardown_expire;
> -    /*
> -     * Used for ffa_domain_teardown() to keep track of which SPs should =
be
> -     * notified that this guest is being destroyed.
> -     */
> +    /* Keep track of SPs that should be notified of VM destruction */
>      unsigned long *vm_destroy_bitmap;
>  };
>
> @@ -334,8 +376,15 @@ extern void *ffa_rx;
>  extern void *ffa_tx;
>  extern spinlock_t ffa_rx_buffer_lock;
>  extern spinlock_t ffa_tx_buffer_lock;
> +extern spinlock_t ffa_ctx_list_lock;
>  extern DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
>
> +extern struct list_head ffa_ctx_head;
> +
> +#ifdef CONFIG_FFA_VM_TO_VM
> +extern atomic_t ffa_vm_count;
> +#endif
> +
>  bool ffa_shm_domain_destroy(struct domain *d);
>  void ffa_handle_mem_share(struct cpu_user_regs *regs);
>  int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags);
> @@ -368,6 +417,29 @@ int ffa_handle_notification_set(struct cpu_user_regs=
 *regs);
>  void ffa_handle_msg_send_direct_req(struct cpu_user_regs *regs, uint32_t=
 fid);
>  int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs);
>
> +#ifdef CONFIG_FFA_VM_TO_VM
> +static inline uint16_t get_ffa_vm_count(void)
> +{
> +    return atomic_read(&ffa_vm_count);
> +}
> +
> +static inline void inc_ffa_vm_count(void)
> +{
> +    atomic_inc(&ffa_vm_count);
> +}
> +
> +static inline void dec_ffa_vm_count(void)
> +{
> +    ASSERT(atomic_read(&ffa_vm_count) > 0);
> +    atomic_dec(&ffa_vm_count);
> +}
> +#else
> +/* Only count the caller VM */
> +#define get_ffa_vm_count()  ((uint16_t)1UL)
> +#define inc_ffa_vm_count()  do {} while(0)
> +#define dec_ffa_vm_count()  do {} while(0)
> +#endif
> +
>  static inline uint16_t ffa_get_vm_id(const struct domain *d)
>  {
>      /* +1 since 0 is reserved for the hypervisor in FF-A */
> --
> 2.47.1
>


From xen-devel-bounces@lists.xenproject.org Wed May 21 15:01:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 15:01:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992028.1375807 (Exim 4.92)
	(envelope-from )
	id 1uHkwF-0006IH-TK; Wed, 21 May 2025 15:00:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992028.1375807; Wed, 21 May 2025 15: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 1uHkwF-0006IA-Pr; Wed, 21 May 2025 15:00:59 +0000
Received: by outflank-mailman (input) for mailman id 992028;
 Wed, 21 May 2025 15:00:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHkwF-0006I2-B2
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 15:00:59 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6703fe76-3654-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 17:00:58 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-601a6e2e93cso544909a12.1
 for ; Wed, 21 May 2025 08:00:58 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502bc1sm8871019a12.30.2025.05.21.08.00.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 08:00: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" 
X-Inumbo-ID: 6703fe76-3654-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747839657; x=1748444457; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=jhhOmd5Q29gsD/BIB4B6W/kIzNcyrxLA5sa4eK4oIaU=;
        b=ahUEQ5SfiRhMNov8plpbmOpNKWacf8rgYbEtgQciCOcrOUl0Pk3u4MZkI9dJi9FXgs
         cucDaIYqKSCru4d3KeIl3+9hOoAItEbeuFfzXaXIk+IWE9yoNK2Ag6Uszz8rEFUeVEAJ
         7k+SYkEma6sq5EUqceJ2SXb+OeTFfhG/EdY4sZIzHAFztJPJiXHM6MZiWhIO3f/rnzAs
         NB2xR7QI02uah7zTSV3Repr5OOO8zZKxbhBex7QSAnYwRsRI4kYjBmNk4U/vfM4tKaRa
         fvnnK1WVIyZS4kDedUUjcIUF4je2+nLsbd2s+RZv/pxA9LXdBncPfGKG+mQTOY8w83m1
         orKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747839657; x=1748444457;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=jhhOmd5Q29gsD/BIB4B6W/kIzNcyrxLA5sa4eK4oIaU=;
        b=ZSurt6hKydmj1GIs6CZdjVjcdHosqbWeDdrsBPfgWfT1zn2+vo4Y8NSbIzQ4NWWHys
         7O8N7eh8QA3wJD3jWXQxwbz7gRegZx1MDrqro3HFu6afBoEC6CF96aSiznXknNFLa4Mv
         rVK4/ouE8i/SGeTaL33j07NmsT/SiaKm22eB2PCwGgQhNBEKMmJkSFA62VblelyylSFw
         jlvLH91Svqs+Gw7dwukFOvkNjMnoGDXo2Ij2DXOfFt300WRL3TuGQ9OrAtTV1SFcaqpL
         u2lnNpCuSObZr+F2p810YkDUmaO8cdanGUvJpdINorjLunTZfJaJA9yn+1TBVtQR49ST
         W0+g==
X-Forwarded-Encrypted: i=1; AJvYcCX98QIDHJqqLi7aJ+RyMf3O+I9S0EyhfeDLKsg28V9ZDUnK2fjN7RE8mGbccAvVmnRe6R6tLVtm8J0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywvr6Pq8NqhNC+cvp7nyXxNrr4Ciha3z/x/tQ8roiykhPEGUon3
	PYmyByPuisxVLTSslydTf0McbJczOrctEfuWfKF/NVudKq33JyHrFOBr1gzFG9CP+Q==
X-Gm-Gg: ASbGncsWXkgxLCBVcqSp0bORITfJtf8hdlascrD5kJjNBglvRdoJAyoXDv5HOiSpzYe
	Uf+fT/+Eqz3RJ5tAteUCOkI+Vo6VtJS0uT+amlEL4RHCUfRn5AFBdGTo4+WY5GyeAp3rDK7E6Nz
	5wKVoPFxUvb2J57/vatd6EnKlBtV6n6H/MjXL1w6ChdOmEjR+IjUfSpHm3KZ51yRniqbiY5IeQR
	pzmvXLU9Tr3h6Oamtupl4hzR8t/MSTR6kTMhdqjJs6vlPZIRkjhUUuHpg+2/SCVFKPHxD/aMCK8
	rnh+0hUzx8wmuGPHEhTlfPPo+LkPEXxZFulgnbD3XdYxzPT9pD3SwA8a/lDjv91EaoeyVZHY
X-Google-Smtp-Source: AGHT+IF01aUVRDdsW+bmXtWVdgVofUfX+YsmMp35eTAN1O4Gvccy7cqyKlBIzEWd5VPCpA2Y8Z5s7Q==
X-Received: by 2002:a05:6402:4401:b0:5f4:8c80:77d with SMTP id 4fb4d7f45d1cf-6008a5a115emr18605583a12.6.1747839657565;
        Wed, 21 May 2025 08:00:57 -0700 (PDT)
Message-ID: <6f821e28-b182-4d27-b2db-e3be80910c12@suse.com>
Date: Wed, 21 May 2025 17:00:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 03/12] x86/hyperlaunch: initial support for hyperlaunch
 device tree
To: Alejandro Vallejo 
Cc: "Daniel P. Smith" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Jason Andryuk , Denis Mukhin ,
 xen-devel@lists.xenproject.org
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-4-agarciav@amd.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250429123629.20839-4-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 29.04.2025 14:36, Alejandro Vallejo wrote:
> From: "Daniel P. Smith" 
> 
> Add the ability to detect both a formal hyperlaunch device tree or a dom0less
> device tree. If the hyperlaunch device tree is found, then count the number of
> domain entries, reporting an error if more than one is found.
> 
> Signed-off-by: Daniel P. Smith 
> Signed-off-by: Jason Andryuk 
> Signed-off-by: Alejandro Vallejo 
> Reviewed-by: Denis Mukhin 

First: With your code re-use proposal sent earlier today I wonder how
meaningful it is to further review this series. Much of it would change
if that proposal was followed, I expect?

Then: When you say "hyperlaunch or dom0less" - is it entirely benign
which of the two is found, as to further parsing? I ask because I can't
spot anywhere that you would record which of the two (if any) was found.

> --- a/xen/common/domain-builder/fdt.c
> +++ b/xen/common/domain-builder/fdt.c
> @@ -13,6 +13,36 @@
>  
>  #include "fdt.h"
>  
> +static int __init find_hyperlaunch_node(const void *fdt)
> +{
> +    int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
> +
> +    if ( hv_node >= 0 )
> +    {
> +        /* Anything other than zero indicates no match */
> +        if ( fdt_node_check_compatible(fdt, hv_node, "hypervisor,xen") )
> +            return -ENODATA;
> +
> +        return hv_node;
> +    }
> +    else

Please can such unnecessary (and potentially misleading) "else" be omitted?
As ...

> +    {
> +        /* Look for dom0less config */
> +        int node, chosen_node = fdt_path_offset(fdt, "/chosen");

... these will need to move to function scope then, one of the two may want
folding with "hv_node" above.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 15:05:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 15:05:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992036.1375817 (Exim 4.92)
	(envelope-from )
	id 1uHl0p-00074q-EJ; Wed, 21 May 2025 15:05:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992036.1375817; Wed, 21 May 2025 15: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 1uHl0p-00074j-Ap; Wed, 21 May 2025 15:05:43 +0000
Received: by outflank-mailman (input) for mailman id 992036;
 Wed, 21 May 2025 15:05:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHl0n-00074d-TC
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 15:05:41 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0fa91340-3655-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 17:05:41 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ad1d1f57a01so1214204366b.2
 for ; Wed, 21 May 2025 08:05:41 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d06dcafsm932478666b.54.2025.05.21.08.05.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 08: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" 
X-Inumbo-ID: 0fa91340-3655-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747839940; x=1748444740; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=5wuPi4LjeIrSrlnLi0ue8bh6SPLZgSeygRov7Xu7hTM=;
        b=gVsmqXnHH75gOfkmBTIfWcz5l64kMAz2gXcjlpAOsylsRH2oSEAMsNr4JNTa7r5VoY
         kAY1NfxPR/9HkZl+oD2WsydfY4UMu0zSK4FFY7q/Qd8VuPiZ4FI55JDkPWbtHmeONbIx
         oPZ3sMy+5FVQfjTCvWm0gDee7Sx1c43jSSx5Ey5gRAnyq239mk6R8AzI/HdmFXfJoZBt
         aTlUvtYzYWypnTufPNMnIjL930qj//0HSiAHx5qCeztLov8pmAg3KICLKaEcSuTj030F
         8PCtRNR09A0rdr+87yGp+UaRIeJbr4HaxB8HffQJ1DG63wItH0oZWOk+jetwb7I37bUs
         kBPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747839940; x=1748444740;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=5wuPi4LjeIrSrlnLi0ue8bh6SPLZgSeygRov7Xu7hTM=;
        b=JbVnqm8wDcoldhDHK2ueqfoQPnpiAIRrks9cov4bWzeQEYPw3yfKxtcYP3z5iDQ/BM
         vpO0HLolJXxHWhJ3LfB9ZCsSnnWaCfr800vcCbdSSQdOzETyzJDwy/60Q5yol3qgv4s2
         MELmlni8bUumefp4UPwEU5YY/DIP3CjpDqu0o6cqGG/CGTQix4JfAGcjm5RPW86+Yy70
         Vis0ZqBZkeni4YwZuP4eVoGT8JismI7RBQfLbB42EDBqigc+w2SU8XM0566greCZKZ1L
         zFtYVzwxfwu7LcdGlb71q32bp82pYMO7ZLRXoF3QP1jgK2eA62aMjfLV+ehqy221KSZM
         OgiQ==
X-Forwarded-Encrypted: i=1; AJvYcCVmZbWYWQs1nTt2x3ooSjDHPtAflrHUik6kyVXaMZyWiIOcsayESAulxrMKlcYXiZsuLkDAn0LmuGE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzRaA8pxGDhSpD7DyGAmSJ0wQYH93K1Br7wAHajsCC/u2bHD+JC
	LVS4VI4EE452Gf0OZ2MX8/NtUgq639KkJbLKHw/qTac65ATMkjEoIjigIbKn1MAigw==
X-Gm-Gg: ASbGnctVoog7qKCuMY9DtXj7/k+8UVJ72+3bFOSL1hCSLSQPcGX/arySdLLZcc/Mg7F
	jmUBDZvWadN7Zgmam1BEgE4/KBqrlPysjpunBKRLNGdlJqRMVBmTub2pdXKGCfyCkFIzyWVuDvu
	Ufgj0pqT6trlGexNanLF2QVynHWfW51g74K4sovZkW4oUbNMXsYKBd1G11I3feBXoG2n0H9rXUq
	Y0nYaB2IhCLrt+KE5bDVse7fQeprYas/H1b+6AjFcyflchUXZGTO4sSWB2ZuYcm2jorAp2L3Iju
	CtE6qnthfKZchao83sYnqiujwqlVuRcFJ4fHclKduuqjvpznGfVPMHgJ1xVcVw==
X-Google-Smtp-Source: AGHT+IEHG2qmB2LmzH3T0Zgn0rsKH84tg2w3jalJkB8NuWD2TTIccKDZvfqK+R3Ygm+t7XDwnb/JPQ==
X-Received: by 2002:a17:907:728e:b0:ad5:5198:b2ad with SMTP id a640c23a62f3a-ad55198bc52mr1558639866b.48.1747839940014;
        Wed, 21 May 2025 08:05:40 -0700 (PDT)
Message-ID: 
Date: Wed, 21 May 2025 17:05:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
To: Andrew Cooper ,
 Sergii Dmytruk 
Cc: "Daniel P. Smith" ,
 Ross Philipson ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Lukasz Hawrylko , =?UTF-8?Q?Mateusz_M=C3=B3wka?=
 , trenchboot-devel@googlegroups.com,
 xen-devel@lists.xenproject.org
References: 
 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14.05.2025 16:55, Andrew Cooper wrote:
> On 13/05/2025 6:05 pm, Sergii Dmytruk wrote:
>> +/*
>> + * Always use private space as some of registers are either read-only or not
>> + * present in public space.
>> + */
>> +static inline uint64_t read_txt_reg(int reg_no)
> 
> unsigned int reg
> 
> I'd be tempted to name it simply txt_read().  I don't think the extra
> "_reg" is a helpful suffix, and it makes the APIs consistent with
> txt_reset().  But I expect others may have opinions here.

+1

>> +static inline void txt_reset(uint32_t error)
>> +{
>> +    write_txt_reg(TXTCR_ERRORCODE, error);
>> +    write_txt_reg(TXTCR_CMD_NO_SECRETS, 1);
>> +    write_txt_reg(TXTCR_CMD_UNLOCK_MEM_CONFIG, 1);
>> +    write_txt_reg(TXTCR_CMD_RESET, 1);
>> +    while (1);
> 
> for ( ;; )
>     cpu_relax();
> 
> please.

With (style nit) another blank between the semicolons.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 15:07:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 15:07:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992042.1375826 (Exim 4.92)
	(envelope-from )
	id 1uHl2L-0007bd-NS; Wed, 21 May 2025 15:07:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992042.1375826; Wed, 21 May 2025 15: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 1uHl2L-0007bW-Kt; Wed, 21 May 2025 15:07:17 +0000
Received: by outflank-mailman (input) for mailman id 992042;
 Wed, 21 May 2025 15:07:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHl2K-0007bO-J3
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 15:07:16 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 47180149-3655-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 17:07:14 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43cf848528aso62514665e9.2
 for ; Wed, 21 May 2025 08:07:14 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442eb85a8f8sm160210345e9.0.2025.05.21.08.07.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 08:07: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" 
X-Inumbo-ID: 47180149-3655-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747840034; x=1748444834; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=zppJwBYcToytG4EhXhFNvwdzt1AUcH92gNWkwpcV0xM=;
        b=YUhEpUW1XL0eWb7JAOltCfRT0VuCphHPlakijQUkES0Swe2mgOvg9/Nh46Zq1TvUMR
         aocqyl3aHdqPT6qR6Qsj87soQF8IHQ3MCzWbYMa016NncdbZhk05VrQyWAGSq3nrYm1d
         9znXaASvXa8kcBqjH/FHSdMDqZft6sQPfk1IM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747840034; x=1748444834;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=zppJwBYcToytG4EhXhFNvwdzt1AUcH92gNWkwpcV0xM=;
        b=Li4Z/+XXGv+1wSK+JCj58+4zDjZiyQYfjrOpN3vUc/7OMM0eB8VSv5uG6fZMEl8aWe
         KzTG3sNgYCIjaQ4glApJ6z0KPOSfngHWf4li9xCeFxPTo8Ugyi8l+CyVuk6oau6q3KS8
         Jj+j4NLXwTrccpOMYmvMqWdkwURv1AYpslz/DMf8ohnlZaq9DbUlpuOdYWlO30T3+ajH
         sK4oJCi7CgSgpIsKfXwn7XzxhULOLRIYcgaZWhfyTHNSI7T6UfA+JrhFG0cGKdVuOuO3
         dlruZZp+VyZF8qZrW5+C5epa+eWAAmfSIS7qBN0lGbAPBi8lqtKVUwIAS3D2npVyfkp1
         At6w==
X-Gm-Message-State: AOJu0YxTMJ18HH/B0Ryby0N2tSIvveDEe7dvy8p8s9j5bY6ydHtGUu4i
	ELQPvB9Kwt5KURKYocmDLPJP5n4J6eJCWn3WPthmDDJ07B3Hr+sPcJWjJ5absiK6eBg=
X-Gm-Gg: ASbGncvhrDbfzjGxzTMdFug41eUPCxoO1v+gQhHjxUb7TxhIZx3da5U9aN2CcqLnUzV
	dDa8AoC2fMomvgfNy8LCIRSyVz9LN3hlOFs3h9+4dR2gO5BgpOg1UWjJHcxd5WRhzQ0RENJ0N0N
	NvjX1DrZZXp4bDep0R6n/UKZp0CgcHHGVkpwQOrjUHa7qhSBou2HdlqZe4yObgZ0OCHf8qhkiKe
	WfwvBIMz2+vlYYaJ9HNYzMxAVQcBCVTRBwNksVKO5CPIrHpY67aRn6ijAQYl33ASldjvILnINFc
	X5QvKBkQzoP1T6AILXaEvu+tzdzMeZADMDwyDrN4xZLPD25D7diy0j8L8Nm/y4aoMgUpA+IEvPc
	0Lw20sQqjzMB0H+O5pTJpLx5y5GBx8Q==
X-Google-Smtp-Source: AGHT+IHxXERf8wAAgHh075zWFqlNI4Uy3eoq4MmdAux2SPPfRdW10WhcFhkZBMY/m0PEF0FAB/uBSQ==
X-Received: by 2002:a05:600c:1e0f:b0:43c:ec0a:ddfd with SMTP id 5b1f17b1804b1-442fd606a72mr191038855e9.6.1747840033664;
        Wed, 21 May 2025 08:07:13 -0700 (PDT)
Date: Wed, 21 May 2025 17:07:12 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
	michal.orzel@amd.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v2 2/2] xen/domain: rewrite emulation_flags_ok()
Message-ID: 
References: <20250516022855.1146121-1-dmukhin@ford.com>
 <20250516022855.1146121-3-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250516022855.1146121-3-dmukhin@ford.com>

On Fri, May 16, 2025 at 02:29:16AM +0000, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Rewrite emulation_flags_ok() to simplify future modifications.
> 
> Also, introduce X86_EMU_{BASELINE,OPTIONAL} helper macros.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v1:
> - kept use of non-public X86_EMU_XXX flags
> - corrected some comments and macro definitions
> ---
>  xen/arch/x86/domain.c             | 29 +++++++++++------------------
>  xen/arch/x86/include/asm/domain.h |  6 ++++++
>  2 files changed, 17 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index f197dad4c0..c64c2c6fef 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -750,25 +750,18 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
>      BUILD_BUG_ON(X86_EMU_ALL != XEN_X86_EMU_ALL);
>  #endif
>  
> -    if ( is_hvm_domain(d) )
> -    {
> -        if ( is_hardware_domain(d) &&
> -             emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
> -            return false;
> -        if ( !is_hardware_domain(d) &&
> -             /* HVM PIRQ feature is user-selectable. */
> -             (emflags & ~X86_EMU_USE_PIRQ) !=
> -             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
> -             emflags != X86_EMU_LAPIC )
> -            return false;
> -    }
> -    else if ( emflags != 0 && emflags != X86_EMU_PIT )
> -    {
> -        /* PV or classic PVH. */
> -        return false;
> -    }
> +    /* PV */
> +    if ( !is_hvm_domain(d) )
> +        return emflags == 0 || emflags == X86_EMU_PIT;
>  
> -    return true;
> +    /* HVM */
> +    if ( is_hardware_domain(d) )
> +        return emflags == (X86_EMU_LAPIC |
> +                           X86_EMU_IOAPIC |
> +                           X86_EMU_VPCI);
> +
> +    return (emflags & ~X86_EMU_OPTIONAL) == X86_EMU_BASELINE ||
> +            emflags == X86_EMU_LAPIC;
>  }
>  
>  void __init arch_init_idle_domain(struct domain *d)
> diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
> index 8c0dea12a5..3a9a9fd80d 100644
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -494,6 +494,12 @@ struct arch_domain
>                                   X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
>                                   X86_EMU_VPCI)
>  
> +/* User-selectable features. */
> +#define X86_EMU_OPTIONAL        (X86_EMU_USE_PIRQ)
> +
> +#define X86_EMU_BASELINE        (X86_EMU_ALL & ~(X86_EMU_VPCI | \
> +
> X86_EMU_OPTIONAL))

If you go this route I think you need to name those
X86_EMU_HVM_{BASELINE,OPTIONAL}, because they are really meaningful
only for HVM domains.

Regarding vPCI and HVM: we might want to enable it in the future for
domUs, but the fact is that right now it will collide badly with
ioreqs.  So for the time being on x86 it would be best if vPCI is
limited to PVH hardware domain exclusively, otherwise the hypervisor
internals might malfunction.  We shouldn't really allow dom0 to create
this kind of malformed domain as much as possible.

static const struct {
   bool pv, hwdom;
   uint32_t base, optional;
} allowed_conf[] = {
    /* PV */
    { true, false, 0, X86_EMU_PIT },
    /* PVH hardware domain */
    { false, true, X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI, 0 },
    /* PVH domU */
    { false, false, X86_EMU_LAPIC, 0 },
    /* HVM */
    { false, false, X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
      X86_EMU_VPCI | X86_EMU_USE_PIRQ },
};
unsigned int i;

for ( i = 0; i < ARRAY_SIZE(allowed_conf); i++ )
{
    if ( is_pv_domain(d) == allowed_conf[i].pv &&
         /*
	  * A hardware domain can also use !hwdom entries, but not the
	  * other way around
	  */
         (is_hardware_domain(d) || !allowed_conf[i].hwdom) &&
	 (emflags & ~allowed_conf[i].optional) == allowed_conf[i].base )
        return true;
}

printk(XENLOG_INFO "%pd: invalid emulation flags: %#x\n", d, emflags);

return false;

I think the above (not even build tested) is slightly clearer, and
allows for easier expansion going forward?

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 21 15:11:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 15:11:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992053.1375837 (Exim 4.92)
	(envelope-from )
	id 1uHl61-0000eV-6K; Wed, 21 May 2025 15:11:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992053.1375837; Wed, 21 May 2025 15:11: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 1uHl61-0000eO-3j; Wed, 21 May 2025 15:11:05 +0000
Received: by outflank-mailman (input) for mailman id 992053;
 Wed, 21 May 2025 15:11:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHl5z-0000eI-UV
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 15:11:04 +0000
Received: from EUR02-DB5-obe.outbound.protection.outlook.com
 (mail-db5eur02on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2608::61e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ceaf27f6-3655-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 17:11:02 +0200 (CEST)
Received: from AS4P195CA0013.EURP195.PROD.OUTLOOK.COM (2603:10a6:20b:5e2::16)
 by AS8PR08MB6183.eurprd08.prod.outlook.com (2603:10a6:20b:29e::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.19; Wed, 21 May
 2025 15:10:59 +0000
Received: from AM3PEPF0000A795.eurprd04.prod.outlook.com
 (2603:10a6:20b:5e2:cafe::e6) by AS4P195CA0013.outlook.office365.com
 (2603:10a6:20b:5e2::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Wed,
 21 May 2025 15:10:59 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM3PEPF0000A795.mail.protection.outlook.com (10.167.16.100) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Wed, 21 May 2025 15:10:59 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS2PR08MB9942.eurprd08.prod.outlook.com (2603:10a6:20b:545::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.31; Wed, 21 May
 2025 15:10:20 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%3]) with mapi id 15.20.8699.022; Wed, 21 May 2025
 15:10: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" 
X-Inumbo-ID: ceaf27f6-3655-11f0-a2fa-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=l4A0XbDr12NHpvkjisqdUrwL+ini0AKqHfDTLrWjP0f+yeCIAoVwTbfcYU69xpjqtQmCsoT46/2z8JPQ5+c123enjEim/0CjWRaaTUvgDhLL5fLysl7qTof0fc5EESa4A/0CabDw2ON4Xiy6Ix6Y8pVnO8K3oelOmZYhNyJU1qV/iGfc1z0oATssFB4wDPdQw4J0Ijm8yELGtWwi8SfOkEgHeGhbPZ/mqcybtSYoz8YYQ2TghxjyTZT4zQT6xVK5od4jbB6sT0loCt3bGkIk7RvRSQRGOzJSL9h+poOC/cAw5mU2Ph5ERuIin18Rwl6wkBKk8xJ1lzWtLNZd3LOB7g==
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=EITqOaiWriLr/iVAckORdiuzIDy3OOJFzeM3oEPCl28=;
 b=cQjabDpL569vdFTBUJppW17Fz7yNq1ilD+KfFqTOHosIVmDzFgVbpBwsBXEZ4aUD6nCwMpilztAo3hF4FNEwIiLS9lG/pE5YVBTV7g+5npYHmb/EJ6oVZeHhKWwG1ajVgWl5HCboVza4X9K2aul6s35FsR1KZ2z/p0pLDFpN9v5Wnpi9jF6qi37eMPhIcxU3vo3RN6pu6MY02R+TcBSu9yMlSEReAKC8LoBTobRvX2BCVI4O84RRPWI+TNNng83hJHSc6hngHBkLQV60zhjj6Md229FzJRQWGDpY4fAdEsqoA2MiHay0mq2jfuw1qV/Tqx6ghrKAjN5Z8RWnj2TGrw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=linaro.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=EITqOaiWriLr/iVAckORdiuzIDy3OOJFzeM3oEPCl28=;
 b=Ml/W2YknWNaQlyvBI01O4y7LZhiiQGySxc9exKq+PDi+5MPRrIsZPc3d8lhAaFpxgPXr3cT2hO+7KIDrhxeuxUHteQBv744l+tJFMuLrw1Z3kNgdf179HM6gBtVhnVFrfdb6ViPbkhdOGlNgvjyIKOo4rBp/nflc5Q96OSstWeQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Z9ncRARLprZyZdoZOndmFhpyayjtsns6fbkb8cO/Qy93WLC9RIMgPTfyPubduIA2dG0lb5NdR+DS4fmntKVklmduavjVYGF4BtmWXJXADwBLmLym93jEuzB1WdZ87qkTBgE1pXTAHG3/P+Jk/hsmR1q5UJybr2T7pzVB7RCE1Wm/srJFFiviFZC831rsd+BUy9eUSgj2iodlXG5XrA2+TMd5RrsKhAtr338+irv0YWZFn6CS0JQaBEe0bce2UvayIysZgi97mJuRuCA940WAjK7M8RlHz+nUlNrb/Dw7Hat6ov23DhGJ5yXFHx/Z9G4+jAndtyAdCPL18XpEqn4bvg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EITqOaiWriLr/iVAckORdiuzIDy3OOJFzeM3oEPCl28=;
 b=ZrJdGtEtUKSoGkaplhpFBDQqlVOY/JCzk1lWQn8Hazxgd1CpIBTtT5ydhd9oAhRvilSyMSFToFo3gQGMIUL+KyhFQedeXGrIk/p6Jn2gylf+2ZjaFhSAyIaj4hmOCLlGeGDj4eK3VSlgUppP3KngWwKO1lXSFJTsxNn/YbTCMk/6IqGY/BCH6cj5D9ovS1GGxy40ALYGgX5flWVSzIZd88zFaWE2My7evB5eF+ueVBkfDJvzOAC0e1FCvfmSearuvi1dso6OyWkIUSiAVFwuRl2a6/juNQacmcdqtVFxPuXfC18IZkr9UVjBFXkaSIh3iT2C6jcCAU39CFkOvWtmYA==
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=EITqOaiWriLr/iVAckORdiuzIDy3OOJFzeM3oEPCl28=;
 b=Ml/W2YknWNaQlyvBI01O4y7LZhiiQGySxc9exKq+PDi+5MPRrIsZPc3d8lhAaFpxgPXr3cT2hO+7KIDrhxeuxUHteQBv744l+tJFMuLrw1Z3kNgdf179HM6gBtVhnVFrfdb6ViPbkhdOGlNgvjyIKOo4rBp/nflc5Q96OSstWeQ=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: "xen-devel@lists.xenproject.org" ,
	Volodymyr Babchuk , Stefano Stabellini
	, Julien Grall , Michal Orzel
	
Subject: Re: [PATCH v5 3/6] xen/arm: ffa: Introduce VM to VM support
Thread-Topic: [PATCH v5 3/6] xen/arm: ffa: Introduce VM to VM support
Thread-Index: AQHbrqLcUoVcqzY6y0GU3I61EJDkQrPdY1IAgAAESwA=
Date: Wed, 21 May 2025 15:10:20 +0000
Message-ID: 
References: 
 
 
In-Reply-To:
 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|AS2PR08MB9942:EE_|AM3PEPF0000A795:EE_|AS8PR08MB6183:EE_
X-MS-Office365-Filtering-Correlation-Id: c6a6707a-fa20-4231-5869-08dd9879b18d
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?WHNHMXYxSkYwZGljZ2F1aVhNZ1RrcWxxak1KY1ZwU3dPRjJsUCtKRTVEVnFw?=
 =?utf-8?B?K3ZtTzNIVEtUQjJKQWFTL0UzcVhDL2VjMTdOSUI3emh5RFhMVGhiYjk4N3FT?=
 =?utf-8?B?ZHRpMk9Zeml6MkVNcHloMm1WUXJRTUNxSWkwNTdZY0FDRGNVNXM4NHZmNjUx?=
 =?utf-8?B?ekVHNFQrVjVmN3djcE1adjZWRUtMRHpMaWpLeVJJdGRwQkdydUJoOTZsdUI0?=
 =?utf-8?B?MnhxbitXdUdsNDVqZUdmSUtWL0lSbHdaZ1hrcjhBb2dKZzBBb0F6ZWtqdmNy?=
 =?utf-8?B?TkpHS1dqcTBjZGNoMXM2dWZtZkhsYkNLTjlaU1N5VCswSERqYUtTV2hSVnBu?=
 =?utf-8?B?MlRKc1FYdEREWW9YQmZTM1dNbnlRQnV5UzJaR1JHclprNWJRM2FYZVZ0WFdZ?=
 =?utf-8?B?QTB4RG1PekptWllBaGl0UnY1aDVyV2JXbk9yRGp6c2VVU1ZJc1EyK3FHRGRa?=
 =?utf-8?B?c3VweFBtcEh1aG00dFRmOWhPYzFHbzduSzEySk5xMk13bGRUSVFQamErd2VF?=
 =?utf-8?B?V3BJajlhVEZSTnNQU0YrS2FhWTFIS3c4RTBmQmlibmRjNlhiVDFFWXhOWWgr?=
 =?utf-8?B?MkQ0UjFBRVplWDlUY2MyRVVnUXY4b0V6R3hQejhiWVkxS2UxY1dRbVNNUUx6?=
 =?utf-8?B?My9pUXZ5MVp3eEM4dmoxS3RoRkJpdStIUUJwNG5BSjRDc1VTWnliU29CcDBN?=
 =?utf-8?B?T3FhTUZBY1dobnMxTXVSeGRCMXFiNnkvU0lMWGNXZTZ5d1R6SDdMd3ViQ25O?=
 =?utf-8?B?L3QySmhOQW96UDJUM3dZd2FFZkZCUGtDdUl2eE1hd050ZkpUR1YyWnpIT1Ja?=
 =?utf-8?B?cHovUzY4MTNPcjJQaWRqYm56Nmg4SlF4c3ZMcTc1OVdRSWFyOXZSRzFTWkVs?=
 =?utf-8?B?U1Z0OVBCWkxGWWZRU0JvNG56SzI3NTZZVmJNWGhjeFBPTlo2cCsycU16ZXpu?=
 =?utf-8?B?Z1FyMkFxaU90MDJnTUViM3R5U2l4ZDE5THIrUHp3NjhRLy83MkcrR1lRMVFy?=
 =?utf-8?B?UU91cm84SzIxWFJCV3B0YnUxczN0bkY1c2FQQTIzSlc0cFJpeExZdGcxSGZ5?=
 =?utf-8?B?WmQzcFRrZk4wMnZXZ1d4Zk9YaTIxMDkwRllFR29tSVVXbDA4Vk0vZkJ5UFV6?=
 =?utf-8?B?OHlIYnlnUThwK1dSWHd6bU5Jdjg5WC95bkxiRUVCWlFZbGtMZkJGOXgrMzFI?=
 =?utf-8?B?cnhOMTBUeURKeml3dmdZcWZGMWNrNzRCQVF0UlJ1K1p5cUNoY3FCQWs2WmUw?=
 =?utf-8?B?aE9RRGRxRXRuMldBTENtT2owZXZNdXFWQmtKUjBvdWU5RlExb1pMZkxaNHFj?=
 =?utf-8?B?bkk5MC9nT3ZjUlgycnhWdnlRUzFFYTZ5RDIrRGtWRlRKYlNBeWwrWGloMFVO?=
 =?utf-8?B?YWpWbnUrdlV0UXc2M25lZnJ3T21JNDFQeTUraE9aRWpOc2o1TTNVdUZJTWtH?=
 =?utf-8?B?ejhxczNvZUFpa0RPSnRRTDBjNURTWFJVMVVQTTU1TUpvb0xacVlhTjUvTXJ6?=
 =?utf-8?B?V1VWTmZsd2YrNjM1WXl1TGRtSVBUME9yeUN3bzg2TXMzdUtaTzlycGxsTVFo?=
 =?utf-8?B?MVl1TWUxV2NBeGdLczhWNk8vaFJRQnZuTytXWTlGQjZxZ2t0bU5BOU5HNVly?=
 =?utf-8?B?NjZXVGFoZ3pPWnloeWxYcVRleGp6OWtDQi9UVDRGM0JBQm1MNHkwWEUwN2xC?=
 =?utf-8?B?anF1aWtnUEphSVJ5MGlEckpITlhNeGdZaXJkMmUvd3ozN21rQXRmTnVXUDlr?=
 =?utf-8?B?MDRZdWE2WVptOGl4djVrU1locUNnb1BSOU1DQ1BGNXUrMW5VUTdHZ1RQZmUr?=
 =?utf-8?B?L081RFR2Y3FzOFNSQVRKeHpVekp1bm8xeUw4WkdsZVdhOEFvZ2d6a1VXanF0?=
 =?utf-8?B?ckRqUDNkZjBPWEZhRlh0Qms2UzRiS0prVVhiZUtXMjMxdWtnRG9iOWpnZ0RW?=
 =?utf-8?Q?nkQHVEPc1hE=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <4D64D65F7882EC40A441664970E298E8@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9942
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM3PEPF0000A795.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	4d2be6e2-796f-493f-9e99-08dd98799a79
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|14060799003|36860700013|35042699022|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SGl4YktmV25EK2lFRHh6a29zclNhS2hPeE43S1VsRThhck1FVXRzRDNDSDNI?=
 =?utf-8?B?Yk1tT2hLcmhoRkc3NXlydkpkZ2RPenVFZmlNRTFHa1hkeEtHVU1aS055Ymh4?=
 =?utf-8?B?MzJPa285N3V2cjN0UjQ5R2NVT05Ea2VxMVF1OXFUMDN0TCtaMW82NWI1SWRo?=
 =?utf-8?B?Vjl2Q2kzaElXQnAwZGFocFJxZjM5ZnV2T1dvRWEwK1cvbmppSUZtcitxb09a?=
 =?utf-8?B?bXlLdmVQNVlvdmZGb0Rkd1FseURIY2Z5L29nQVdiU2tzeGZpbDZsOFlGLzdX?=
 =?utf-8?B?cE11RjhDOXN6M1NGWlF6SStaMXBGQ0xpRjIxVWphMFlNN2pzWG5Uc3B5OWNH?=
 =?utf-8?B?UDVvODNhRkEyc3drc08xcnRlc3REYW45eGFvVVBRdlE0RkMwNEt6MjB3RDhw?=
 =?utf-8?B?dzVvV2lPYTdkOHNzVjdqcFowSTNiWktyY3JHV0pBcnp3WEh0aE1LWGF5Mmth?=
 =?utf-8?B?U3U5WGh6NzFvbkJtVXlGQkt0WUZ3YXZ6eFVtUlhlaHAxL1JoMHArM2NaL1U1?=
 =?utf-8?B?WEtsUHRFK2xlTUM5T0NIRWRmQzdzemdhT0p4azl0MVF5SG1TMHFOVzJQMFlJ?=
 =?utf-8?B?cUxFM2ZDNUV4V2pvMTJvK0tUc0l2Vk9xOVNnemMvY0p5U0U4QWl2a0ppQWtx?=
 =?utf-8?B?TWZ3bVZhWWVMYUJzT1RNR3JRUTBpcUM2dUF3TWtqc1kwa29CcGFqVHd0Y256?=
 =?utf-8?B?c29DckxiKzVQMU1GajJLbko4UDJBakZrNDFKNzFXc2IyMGRmNEc4VHZzcFdu?=
 =?utf-8?B?UzdIWWxaWm45dDdxQyt4UGZYSkhQUkJaVTN5azR6UVZ2WjdWRHJVVVpSNzQw?=
 =?utf-8?B?Y3lORll3dlBJRUlDNmFFSzVsNjkzZXVZc3JkaVdaZEsydm5KVFFGN1ZSQld3?=
 =?utf-8?B?dUNDRWE4SlNCRFN1aEUvcThEV2Vsd3hRWlVSKzJicjk2OFhrTUt4MXgzUTNN?=
 =?utf-8?B?NytDR0x4QlVlL3ArRnN6MUVEOVh6V1BRRHRiMnRhWllFOXNBcVcvMEdRRys2?=
 =?utf-8?B?RXlNR3IrTGVOazNvTE84TDNLRmRQQ3RMVzFmS2UreWw5YXdtRnR0M2F6TldT?=
 =?utf-8?B?a3VoYnJFRFdNTms1dlI5dXIwVHk2c2M2dHVjaGR5VkhQZkFTYkNiaXpMZkRW?=
 =?utf-8?B?Skh0cmRCdWE5M1V4ektWSVQrNkdxc0FHL0MyZUhoeTYrRXd0RGkyZHllcXZN?=
 =?utf-8?B?QWdmWHBydUpPWm5CVWxBcStRRi9LWXZlUWVSa2dKNTI3aUxGek1DUjNKcUlm?=
 =?utf-8?B?VXc4OWxoRXczSEtIUTdnT0lJbTNZWmdvZFNOQ0VHVHNuZThEUDdIa0Rlb2Rm?=
 =?utf-8?B?WDJtRlVkNHR3amZXckJJTzNOUXhXbXdKSll0Um40bXpieVVjWklqU2ZyTExX?=
 =?utf-8?B?TnNDQ0krRDNKMkoyajNrU3QyOVg2b1NDN0VWWExXQ1hIbytHeGxlUlNLeTM0?=
 =?utf-8?B?V1pEc0IrVGdLcFRqd0pjNzBsaUdsV09hZ1Y2aWtNd2NaRjRZa0NOZ2U5N1hM?=
 =?utf-8?B?N2RqQWpDRmlIR2c0ZCtUUkxadnNFUGUrV1crdDc5NHM3WWJVUGdTS1ZoZURM?=
 =?utf-8?B?dGxlNm5xMkxnSEx5d1Nvb1gzbXFsaW4xa0pGQ29qdEdKL1VXakRodG9hbUYz?=
 =?utf-8?B?QmI5TVNMcUJrUGNZVHFRUnY5R1lESk9Pd2s2c3VDNURFOXZrL2VqNVBtaTBi?=
 =?utf-8?B?TnZWMVh3UWp1aGdwdGdSZ0RvcVRuR0pZUjhEZ240Vnl5SEtweUl3VWVsQ2xp?=
 =?utf-8?B?Q3UvLzZGN0E2dE1VaGptb2o3dDNXbGUxMTVYbEswRlhVdE50b0VZQ3RiUHNm?=
 =?utf-8?B?RTM4ZTNOSWpHcTdHbnI4RTJoUkp4QjNoNWFSWUZjV2tBdVZ3Q1ZpeUh0blY3?=
 =?utf-8?B?VzFNd295c0d6Qk9JUFc0aUNBcFp2NnJMelpjT0dCOSt5ZUNhMGcwM1crb3BI?=
 =?utf-8?B?ZVphOG1lYlpGYk5hMWdBUCs5cGFIQ0NnU1FtdUd5cTN2QnBlZzh5V0d5b1hs?=
 =?utf-8?B?SURvbTJPRTlBPT0=?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(14060799003)(36860700013)(35042699022)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2025 15:10:59.2733
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c6a6707a-fa20-4231-5869-08dd9879b18d
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:
	AM3PEPF0000A795.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6183

SGkgSmVucywNCg0KPiBPbiAyMSBNYXkgMjAyNSwgYXQgMTY6NTQsIEplbnMgV2lrbGFuZGVyIDxq
ZW5zLndpa2xhbmRlckBsaW5hcm8ub3JnPiB3cm90ZToNCj4gDQo+IEhpIEJlcnRyYW5kLA0KPiAN
Cj4gT24gV2VkLCBBcHIgMTYsIDIwMjUgYXQgOTo0MOKAr0FNIEJlcnRyYW5kIE1hcnF1aXMNCj4g
PGJlcnRyYW5kLm1hcnF1aXNAYXJtLmNvbT4gd3JvdGU6DQo+PiANCj4+IENyZWF0ZSBhIENPTkZJ
R19GRkFfVk1fVE9fVk0gcGFyYW1ldGVyIHRvIGFjdGl2YXRlIEZGQSBjb21tdW5pY2F0aW9uDQo+
PiBiZXR3ZWVuIFZNcy4NCj4+IFdoZW4gYWN0aXZhdGVkIGxpc3QgVk1zIGluIHRoZSBzeXN0ZW0g
d2l0aCBGRi1BIHN1cHBvcnQgaW4gcGFydF9pbmZvX2dldC4NCj4+IA0KPj4gV2hlbiBWTSB0byBW
TSBpcyBhY3RpdmF0ZWQsIFhlbiB3aWxsIGJlIHRhaW50ZWQgYXMgSW5zZWN1cmUgYW5kIGENCj4+
IG1lc3NhZ2UgaXMgZGlzcGxheWVkIHRvIHRoZSB1c2VyIGR1cmluZyB0aGUgYm9vdCBhcyB0aGVy
ZSBpcyBubw0KPj4gZmlsdGVyaW5nIG9mIFZNcyBpbiBGRi1BIHNvIGFueSBWTSBjYW4gY29tbXVu
aWNhdGUgb3Igc2VlIGFueSBvdGhlciBWTQ0KPj4gaW4gdGhlIHN5c3RlbS4NCj4+IA0KPj4gV0FS
TklORzogVGhlcmUgaXMgbm8gZmlsdGVyaW5nIGZvciBub3cgYW5kIGFsbCBWTXMgYXJlIGxpc3Rl
ZCAhIQ0KPj4gDQo+PiBUaGlzIHBhdGNoIGlzIHJlb3JnYW5pemluZyB0aGUgZmZhX2N0eCBzdHJ1
Y3R1cmUgdG8gbWFrZSBjbGVhciB3aGljaA0KPj4gbG9jayBpcyBwcm90ZWN0aW5nIHdoYXQgcGFy
dHMuDQo+PiANCj4+IFRoaXMgcGF0Y2ggaXMgaW50cm9kdWNpbmcgYSBjaGFpbiBsaXN0IG9mIHRo
ZSBmZmFfY3R4IHdpdGggYSBGRkEgVmVyc2lvbg0KPj4gbmVnb2NpYXRlZCBhbGxvd2luZyB0byBj
cmVhdGUgdGhlIHBhcnRpbmZvIHJlc3VsdHMgZm9yIFZNcyB3aXRob3V0DQo+PiB0YWtpbmcgYSBs
b2NrIG9uIHRoZSBnbG9iYWwgZG9tYWluIGxpc3QgaW4gWGVuLg0KPj4gDQo+PiBTaWduZWQtb2Zm
LWJ5OiBCZXJ0cmFuZCBNYXJxdWlzIDxiZXJ0cmFuZC5tYXJxdWlzQGFybS5jb20+DQo+PiAtLS0N
Cj4+IENoYW5nZXMgaW4gdjU6DQo+PiAtIHJlbW92ZSBpbnZhbGlkIGNvbW1lbnQgYWJvdXQgMS4x
IGZpcm13YXJlIHN1cHBvcnQNCj4+IC0gcmVuYW1lIHZhcmlhYmxlcyBmcm9tIGQgYW5kIGRvbSB0
byBjdXJyX2QgYW5kIGRlc3RfZCAoSnVsaWVuKQ0KPj4gLSBhZGQgYSBUT0RPIGluIHRoZSBjb2Rl
IGZvciBwb3RlbnRpYWwgaG9sZGluZyBmb3IgbG9uZyBvZiB0aGUgQ1BVDQo+PiAgKEp1bGllbikN
Cj4+IC0gdXNlIGFuIGF0b21pYyBnbG9iYWwgdmFyaWFibGUgdG8gc3RvcmUgdGhlIG51bWJlciBv
ZiBWTXMgaW5zdGVhZCBvZg0KPj4gIHJlY29tcHV0aW5nIHRoZSB2YWx1ZSBlYWNoIHRpbWUgKEp1
bGllbikNCj4+IC0gYWRkIHBhcnRpbmZvIGluZm9ybWF0aW9uIGluIGZmYV9jdHggKGlkLCBjcHVz
IGFuZCA2NGJpdCkgYW5kIGNyZWF0ZSBhDQo+PiAgY2hhaW4gbGlzdCBvZiBjdHguIFVzZSB0aGlz
IGNoYWluIGxpc3QgdG8gY3JlYXRlIHRoZSBwYXJ0aW5mbyByZXN1bHQNCj4+ICB3aXRob3V0IGhv
bGRpbmcgYSBnbG9iYWwgbG9jayB0byBwcmV2ZW50IGNvbmN1cnJlbmN5IGlzc3Vlcy4NCj4+IC0g
TW92ZSBzb21lIGNoYW5nZXMgaW4gYSBwcmVwYXJhdGlvbiBwYXRjaCBtb2RpZnlpbmcgcGFydGlu
Zm8gZm9yIHNwcyB0bw0KPj4gIHJlZHVjZSB0aGlzIHBhdGNoIHNpemUgYW5kIG1ha2UgdGhlIHJl
dmlldyBlYXNpZXINCj4+IENoYW5nZXMgaW4gdjQ6DQo+PiAtIHByb3Blcmx5IGhhbmRsZSBTUE1D
IHZlcnNpb24gMS4wIGhlYWRlciBzaXplIGNhc2UgaW4gcGFydGluZm9fZ2V0DQo+PiAtIHN3aXRj
aCB0byBsb2NhbCBjb3VudGluZyB2YXJpYWJsZXMgaW5zdGVhZCBvZiAqcG9pbnRlciArPSAxIGZv
cm0NCj4+IC0gY29kaW5nIHN0eWxlIGlzc3VlIHdpdGggbWlzc2luZyBzcGFjZXMgaW4gaWYgKCkN
Cj4+IENoYW5nZXMgaW4gdjM6DQo+PiAtIGJyZWFrIHBhcnRpbmZvX2dldCBpbiBzZXZlcmFsIHN1
YiBmdW5jdGlvbnMgdG8gbWFrZSB0aGUgaW1wbGVtZW50YXRpb24NCj4+ICBlYXNpZXIgdG8gdW5k
ZXJzdGFuZCBhbmQgbG9jayBoYW5kbGluZyBlYXNpZXINCj4+IC0gcmV3b3JrIGltcGxlbWVudGF0
aW9uIHRvIGNoZWNrIHNpemUgYWxvbmcgdGhlIHdheSBhbmQgcHJldmVudCBwcmV2aW91cw0KPj4g
IGltcGxlbWVudGF0aW9uIGxpbWl0cyB3aGljaCBoYWQgdG8gY2hlY2sgdGhhdCB0aGUgbnVtYmVy
IG9mIFZNcyBvciBTUHMNCj4+ICBkaWQgbm90IGNoYW5nZQ0KPj4gLSB0YWludCBYZW4gYXMgSU5T
RUNVUkUgd2hlbiBWTSB0byBWTSBpcyBlbmFibGVkDQo+PiBDaGFuZ2VzIGluIHYyOg0KPj4gLSBT
d2l0Y2ggaWZkZWYgdG8gSVNfRU5BQkxFRA0KPj4gLSBkb20gd2FzIG5vdCBzd2l0Y2hlZCB0byBk
IGFzIHJlcXVlc3RlZCBieSBKYW4gYmVjYXVzZSB0aGVyZSBpcyBhbHJlYWR5DQo+PiAgYSB2YXJp
YWJsZSBkIHBvaW50aW5nIHRvIHRoZSBjdXJyZW50IGRvbWFpbiBhbmQgaXQgbXVzdCBub3QgYmUN
Cj4+ICBzaGFkb3dlZC4NCj4+IC0tLQ0KPj4geGVuL2FyY2gvYXJtL3RlZS9LY29uZmlnICAgICAg
ICB8ICAxMSArKysrDQo+PiB4ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jICAgICAgICAgIHwgIDQ3ICsr
KysrKysrKysrKystDQo+PiB4ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wYXJ0aW5mby5jIHwgIDk1ICsr
KysrKysrKysrKysrKysrKysrKysrKy0tLQ0KPj4geGVuL2FyY2gvYXJtL3RlZS9mZmFfcHJpdmF0
ZS5oICB8IDExMiArKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLQ0KPj4gNCBmaWxlcyBj
aGFuZ2VkLCAyMzMgaW5zZXJ0aW9ucygrKSwgMzIgZGVsZXRpb25zKC0pDQo+PiANCj4+IGRpZmYg
LS1naXQgYS94ZW4vYXJjaC9hcm0vdGVlL0tjb25maWcgYi94ZW4vYXJjaC9hcm0vdGVlL0tjb25m
aWcNCj4+IGluZGV4IGM1YjBmODhkNzUyMi4uODhhNGM0Yzk5MTU0IDEwMDY0NA0KPj4gLS0tIGEv
eGVuL2FyY2gvYXJtL3RlZS9LY29uZmlnDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vdGVlL0tjb25m
aWcNCj4+IEBAIC0yOCw1ICsyOCwxNiBAQCBjb25maWcgRkZBDQo+PiANCj4+ICAgICAgICAgIFsx
XSBodHRwczovL2RldmVsb3Blci5hcm0uY29tL2RvY3VtZW50YXRpb24vZGVuMDA3Ny9sYXRlc3QN
Cj4+IA0KPj4gK2NvbmZpZyBGRkFfVk1fVE9fVk0NCj4+ICsgICAgYm9vbCAiRW5hYmxlIEZGLUEg
YmV0d2VlbiBWTXMgKFVOU1VQUE9SVEVEKSIgaWYgVU5TVVBQT1JURUQNCj4+ICsgICAgZGVmYXVs
dCBuDQo+PiArICAgIGRlcGVuZHMgb24gRkZBDQo+PiArICAgIGhlbHANCj4+ICsgICAgICBUaGlz
IG9wdGlvbiBlbmFibGVzIHRvIHVzZSBGRi1BIGJldHdlZW4gVk1zLg0KPj4gKyAgICAgIFRoaXMg
aXMgZXhwZXJpbWVudGFsIGFuZCB0aGVyZSBpcyBubyBhY2Nlc3MgY29udHJvbCBzbyBhbnkNCj4+
ICsgICAgICBndWVzdCBjYW4gY29tbXVuaWNhdGUgd2l0aCBhbnkgb3RoZXIgZ3Vlc3QuDQo+PiAr
DQo+PiArICAgICAgSWYgdW5zdXJlLCBzYXkgTi4NCj4+ICsNCj4+IGVuZG1lbnUNCj4+IA0KPj4g
ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMgYi94ZW4vYXJjaC9hcm0vdGVlL2Zm
YS5jDQo+PiBpbmRleCAzYmJkZDcxNjhhNmIuLmMxYzRjMDk1NzA5MSAxMDA2NDQNCj4+IC0tLSBh
L3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMN
Cj4+IEBAIC0xMTgsNiArMTE4LDEzIEBAIHZvaWQgKmZmYV90eCBfX3JlYWRfbW9zdGx5Ow0KPj4g
REVGSU5FX1NQSU5MT0NLKGZmYV9yeF9idWZmZXJfbG9jayk7DQo+PiBERUZJTkVfU1BJTkxPQ0so
ZmZhX3R4X2J1ZmZlcl9sb2NrKTsNCj4+IA0KPj4gK3N0cnVjdCBsaXN0X2hlYWQgZmZhX2N0eF9o
ZWFkOw0KPj4gKy8qIExvY2sgdG8gcHJvdGVjdCBhZGRpdGlvbi9yZW1vdmFsIGluIGZmYV9jdHhf
aGVhZCAqLw0KPj4gK0RFRklORV9TUElOTE9DSyhmZmFfY3R4X2xpc3RfbG9jayk7DQo+PiArDQo+
PiArI2lmZGVmIENPTkZJR19GRkFfVk1fVE9fVk0NCj4+ICthdG9taWNfdCBmZmFfdm1fY291bnQ7
DQo+PiArI2VuZGlmDQo+PiANCj4+IC8qIFVzZWQgdG8gdHJhY2sgZG9tYWlucyB0aGF0IGNvdWxk
IG5vdCBiZSB0b3JuIGRvd24gaW1tZWRpYXRlbHkuICovDQo+PiBzdGF0aWMgc3RydWN0IHRpbWVy
IGZmYV90ZWFyZG93bl90aW1lcjsNCj4+IEBAIC0xNjAsMTAgKzE2NywyMSBAQCBzdGF0aWMgdm9p
ZCBoYW5kbGVfdmVyc2lvbihzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCj4+ICAgICAgKi8N
Cj4+ICAgICBpZiAoIEZGQV9WRVJTSU9OX01BSk9SKHZlcnMpID09IEZGQV9NWV9WRVJTSU9OX01B
Sk9SICkNCj4+ICAgICB7DQo+PiArICAgICAgICB1aW50MzJfdCBvbGRfdmVycyA9IEFDQ0VTU19P
TkNFKGN0eC0+Z3Vlc3RfdmVycyk7DQo+PiArDQo+PiAgICAgICAgIGlmICggRkZBX1ZFUlNJT05f
TUlOT1IodmVycykgPiBGRkFfTVlfVkVSU0lPTl9NSU5PUiApDQo+PiAtICAgICAgICAgICAgY3R4
LT5ndWVzdF92ZXJzID0gRkZBX01ZX1ZFUlNJT047DQo+PiArICAgICAgICAgICAgQUNDRVNTX09O
Q0UoY3R4LT5ndWVzdF92ZXJzKSA9IEZGQV9NWV9WRVJTSU9OOw0KPj4gICAgICAgICBlbHNlDQo+
PiAtICAgICAgICAgICAgY3R4LT5ndWVzdF92ZXJzID0gdmVyczsNCj4+ICsgICAgICAgICAgICBB
Q0NFU1NfT05DRShjdHgtPmd1ZXN0X3ZlcnMpID0gdmVyczsNCj4gDQo+IFdoYXQgaXMgdGhlIEFD
Q0VTU19PTkNFKCkgc2NoZW1lIGludGVuZGVkIGZvcj8NCj4gDQo+PiArDQo+PiArICAgICAgICBp
ZiAoIElTX0VOQUJMRUQoQ09ORklHX0ZGQV9WTV9UT19WTSkgJiYgIW9sZF92ZXJzICkNCj4gDQo+
IElmIGhhbmRsZV92ZXJzaW9uKCkgaXMgY2FsbGVkIGNvbmN1cnJlbnRseSBvbiB0d28gQ1BVcywg
aXQgbWlnaHQgYmUNCj4gcG9zc2libGUgZm9yIGEgY29udGV4dCB0byBiZSBhZGRlZCB0d2ljZS4N
Cj4gSG93IGFib3V0IGEgc2VwYXJhdGUgZmxhZyB0byBpbmRpY2F0ZSB3aGV0aGVyIGEgY29udGV4
dCBoYXMgYmVlbiBhZGRlZA0KPiB0byB0aGUgbGlzdD8NCg0KSSB3YW50ZWQgdG8gYXZvaWQgaGF2
aW5nIGd1ZXN0X3ZlcnMgYXMgYXRvbWljIG9yIGludHJvZHVjZSBhbiBvdGhlciBsb2NrLg0KQnV0
IGkgdGhpbmsgbm93IHRoYXQgdGhpcyBpcyBraW5kIG9mIGltcG9zc2libGUgdG8gYXZvaWQgYW5k
IHRoaXMgd2F5IHRvIGRvDQppdCBpcyB3cm9uZy4NCg0KSSB3aWxsIHRha2UgdGhlIGNvbnRleHQg
bG9jayB0byBkbyB0aGlzIHByb2Nlc3NpbmcgdG8gYXZvaWQgdGhpcyBjb3JuZXIgY2FzZQ0KYW5k
IHJlbW92ZSB0aGUgQUNDRVNTX09OQ0UgdG8gcHJvdGVjdCBtb2RpZmljYXRpb25zIHRvIGd1ZXN0
X3ZlcnM6DQoNCmRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jIGIveGVuL2FyY2gv
YXJtL3RlZS9mZmEuYw0KaW5kZXggYjg2Yzg4Y2VmYThjLi4zMDZlZGI5Nzg2M2EgMTAwNjQ0DQot
LS0gYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jDQorKysgYi94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5j
DQpAQCAtMTU4LDYgKzE1OCw3IEBAIHN0YXRpYyB2b2lkIGhhbmRsZV92ZXJzaW9uKHN0cnVjdCBj
cHVfdXNlcl9yZWdzICpyZWdzKQ0KICAgICBzdHJ1Y3QgZG9tYWluICpkID0gY3VycmVudC0+ZG9t
YWluOw0KICAgICBzdHJ1Y3QgZmZhX2N0eCAqY3R4ID0gZC0+YXJjaC50ZWU7DQogICAgIHVpbnQz
Ml90IHZlcnMgPSBnZXRfdXNlcl9yZWcocmVncywgMSk7DQorICAgIHVpbnQzMl90IG9sZF92ZXJz
Ow0KDQogICAgIC8qDQogICAgICAqIEd1ZXN0IHdpbGwgdXNlIHRoZSB2ZXJzaW9uIGl0IHJlcXVl
c3RlZCBpZiBpdCBpcyBvdXIgbWFqb3IgYW5kIG1pbm9yDQpAQCAtMTY3LDEyICsxNjgsMTQgQEAg
c3RhdGljIHZvaWQgaGFuZGxlX3ZlcnNpb24oc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQog
ICAgICAqLw0KICAgICBpZiAoIEZGQV9WRVJTSU9OX01BSk9SKHZlcnMpID09IEZGQV9NWV9WRVJT
SU9OX01BSk9SICkNCiAgICAgew0KLSAgICAgICAgdWludDMyX3Qgb2xkX3ZlcnMgPSBBQ0NFU1Nf
T05DRShjdHgtPmd1ZXN0X3ZlcnMpOw0KKyAgICAgICAgc3Bpbl9sb2NrKCZjdHgtPmxvY2spOw0K
KyAgICAgICAgb2xkX3ZlcnMgPSBjdHgtPmd1ZXN0X3ZlcnM7DQoNCiAgICAgICAgIGlmICggRkZB
X1ZFUlNJT05fTUlOT1IodmVycykgPiBGRkFfTVlfVkVSU0lPTl9NSU5PUiApDQotICAgICAgICAg
ICAgQUNDRVNTX09OQ0UoY3R4LT5ndWVzdF92ZXJzKSA9IEZGQV9NWV9WRVJTSU9OOw0KKyAgICAg
ICAgICAgY3R4LT5ndWVzdF92ZXJzID0gRkZBX01ZX1ZFUlNJT047DQogICAgICAgICBlbHNlDQot
ICAgICAgICAgICAgQUNDRVNTX09OQ0UoY3R4LT5ndWVzdF92ZXJzKSA9IHZlcnM7DQorICAgICAg
ICAgICBjdHgtPmd1ZXN0X3ZlcnMgPSB2ZXJzOw0KKyAgICAgICAgc3Bpbl91bmxvY2soJmN0eC0+
bG9jayk7DQoNCiAgICAgICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfRkZBX1ZNX1RPX1ZNKSAm
JiAhb2xkX3ZlcnMgKQ0KICAgICAgICAgew0KDQpXaGF0IGRvIHlvdSB0aGluayA/DQoNCkNoZWVy
cw0KQmVydHJhbmQNCg0K


From xen-devel-bounces@lists.xenproject.org Wed May 21 15:11:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 15:11:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992064.1375847 (Exim 4.92)
	(envelope-from )
	id 1uHl6s-0001Da-JL; Wed, 21 May 2025 15:11:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992064.1375847; Wed, 21 May 2025 15:11: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 1uHl6s-0001DT-GZ; Wed, 21 May 2025 15:11:58 +0000
Received: by outflank-mailman (input) for mailman id 992064;
 Wed, 21 May 2025 15:11:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHl6q-0000eI-SR
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 15:11:56 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ef5d9f1f-3655-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 17:11:56 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43d2d952eb1so55826815e9.1
 for ; Wed, 21 May 2025 08:11:56 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca8cfb8sm19260710f8f.85.2025.05.21.08.11.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 08: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" 
X-Inumbo-ID: ef5d9f1f-3655-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747840316; x=1748445116; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=YXnmpTrr3K1gmCCnuinpatIWCk0RMdlAKsuvR6yAbGg=;
        b=aSt1KmOderHVo0lxpPuKgs9kb5et7Jp+IBsrTC7iNXJoUYO8eZyQKofDf/4ATq52BZ
         GFlwRKjRnq3TtWgq1Z8C/g/V2nnYKdP6f2d/rnldnBpO+Jecpjp3Zi76NGdQhZuv3dl4
         k1OcCRBCStzjVIEMa3SdVoi1PITgVw3uyE7M0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747840316; x=1748445116;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YXnmpTrr3K1gmCCnuinpatIWCk0RMdlAKsuvR6yAbGg=;
        b=dJ/3f17AxAyTj6qQiyi4kANZeMt9vyTcRoD+gGr+LMatZKd20mEQ/1PyARHWbaISMW
         Zd0PGpEP9NGiRzF7CWqcWdBsq4CMP/lPxzKq3cG/PCRRH/AgdMKTdkgIzcspTmSzIuZg
         go6yTtQ4K54tAbuBwGiLb3zNs7V3vdPFgq8UJYhxMoRI39rnnuT+MPRzljNhesjeuybY
         pMVDhkoJVzb2D5KL8HuAJSNKeuA1oN2HRShbAhIMHYGJE72b2w6WVLUeN0eNMmqkPJvk
         BReKPL/Q39GdVA0tYDCtVzCY4O2CbUJyvmHzQCqw++VNpGjd3iZwWJnWj3smcwx05V99
         NjEw==
X-Forwarded-Encrypted: i=1; AJvYcCVJExgJlRmCnjKyr9JLR28h3upIVC7tj+eW4hQHBAQEm38nIh2rU5bmXQxrjfCVr+/C+jPas0Q5alk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxvdC420YA7PL6dqPSEYoyulm9ktKW335TyydFF/MpeBb0RRQCp
	nWTUXHlM/QTzqEOHyp3Jwt2Tx25/F97EU2jEeVq3sebVK+WvjX1wUtMuPcztQD1Cpzo=
X-Gm-Gg: ASbGncuCOxm+OUmCkoOGhgxZUGWZ1H8JTNwpI6+0ykBDhC8wMwFOq2aukGF/XLKGXVZ
	pfwj/CUUMqyOk3TUJ9zdPPYscphul2qTYG0tkNatBh8pEgh5itqB9DL9WPPyZn60/J5OnlP1Cli
	Iod2SKLY2c2Pn8aGr9OMfKTBBgE6XIKF7ZXL/U6lRfIKZgeKRr8C+//GtztUNzAnq+c3H31dhUI
	SYTyzx158Yh4DmTpFBAq8FQSmLYu+weHl8jGcC/EwN/t8egezjcH44WAFicJ/skpEYP/YcOl+6N
	15bsRbQiCHkw8SWWkXXhuETZsBtEHr5liniPy/mPer0ylcRE2athnvBEPfK4uBkPgiax4AGz1fy
	hMRfHqSj3NMb8+ChHR4Y=
X-Google-Smtp-Source: AGHT+IFOO3MVFe63bkQsbYDOCiHerigcjdv7iOVa4TwCOpUysZdyod9DGZPN5b52lcpPpmSL+pQDuA==
X-Received: by 2002:a05:6000:40cf:b0:3a3:581f:9af9 with SMTP id ffacd0b85a97d-3a35c822085mr20833344f8f.7.1747840315831;
        Wed, 21 May 2025 08:11:55 -0700 (PDT)
Date: Wed, 21 May 2025 17:11:54 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Stefano Stabellini ,
	Victor M Lira ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] x86/vpci: fix handling of BAR overlaps with non-hole
 regions
Message-ID: 
References: <20250516083159.61945-1-roger.pau@citrix.com>
 <7bbc1569-672e-42a7-a5b8-4187282fcb18@suse.com>
 
 <4ea08d6d-c2e1-40ad-a31e-554e7bb5cc6c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4ea08d6d-c2e1-40ad-a31e-554e7bb5cc6c@suse.com>

On Wed, May 21, 2025 at 04:31:33PM +0200, Jan Beulich wrote:
> On 21.05.2025 13:34, Roger Pau Monné wrote:
> > On Wed, May 21, 2025 at 10:29:26AM +0200, Jan Beulich wrote:
> >> On 16.05.2025 10:31, Roger Pau Monne wrote:
> >>> For once the message printed when a BAR overlaps with a non-hole regions is
> >>> not accurate on x86.  While the BAR won't be mapped by the vPCI logic, it
> >>> is quite likely overlapping with a reserved region in the memory map, and
> >>> already mapped as by default all reserved regions are identity mapped in
> >>> the p2m.  Fix the message so it just warns about the overlap, without
> >>> mentioning that the BAR won't be mapped, as this has caused confusion in
> >>> the past.
> >>
> >> I was trying to get back to this, but my attempt to use this "fixed
> >> message" as an anchor failed: You don't modify any existing message, and
> >> hence I was unable to determine which other message you refer to here.
> >> None of the ones I looked at appear to fit this description.
> > 
> > OK, it's a bit tricky.  Note how the new implementation of
> > pci_check_bar() unconditionally returns true, which means the message
> > in modify_bars() will never be printed on x86.  Instead a slightly
> > different warning message is printed in the x86 implementation of
> > pci_check_bar().
> > 
> > That's what the above paragraph attempts to explain.
> > 
> > Maybe I need to adjust the last sentence so it's:
> > 
> > "Avoiding printing the warning message in modify_bars(), and instead
> > print a more lax message in the x86 implementation of pci_check_bar()
> > to note the current BAR position overlaps with non-hole region(s)."
> > 
> > Does the above make it a bit clearer?
> 
> Yes, it definitely does. And with use of that I'm now also feeling reasonably
> confident to offer
> Reviewed-by: Jan Beulich 

Thanks, sorry this was a bit dense.

Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 21 15:20:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 15:20:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992074.1375857 (Exim 4.92)
	(envelope-from )
	id 1uHlEf-0002DS-BZ; Wed, 21 May 2025 15:20:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992074.1375857; Wed, 21 May 2025 15: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 1uHlEf-0002Ct-8m; Wed, 21 May 2025 15:20:01 +0000
Received: by outflank-mailman (input) for mailman id 992074;
 Wed, 21 May 2025 15:20:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHlEe-0002Bn-St
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 15:20:00 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0f756ceb-3657-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 17:20:00 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-6020ff8d35dso757894a12.0
 for ; Wed, 21 May 2025 08:19:59 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ae38870sm9134851a12.66.2025.05.21.08.19.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 08: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" 
X-Inumbo-ID: 0f756ceb-3657-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747840799; x=1748445599; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=LBQolO/vz6Qh/YQxilMrAGEepxGKkYcAqOP86dFGug4=;
        b=FWMpNRbEGpjIo7xl3ofG0pZexNnepE1v1BDYxLyTJjLF7aHaXbKMNxdV3/T+vaLhfM
         weum8QZ+7J3ARI4FXaZnSGc73HzyMc9eG/7Td9wvwNOt/qdrkJ6k77ZoxaUn68rTTrBX
         LmaV8AJbejMKOHoX8mvsQqPknKc+CW6ZzXUCMXQ3Upy7/blGPCnjDjBKJ4k5Og6bxo7e
         qYVoWoQRff/b/xTNFWe+FqHZm/KqUR0DoItPKPIH6RNDcmKpaIgHkmCjFyLoEAwgBBSL
         J733DGQF/yCOzITR4WjMNZQFq9K+TBNePEf7NGlxkqRr18FxB4knS9LKYsORxBE48Ohw
         xK7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747840799; x=1748445599;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=LBQolO/vz6Qh/YQxilMrAGEepxGKkYcAqOP86dFGug4=;
        b=mcfWE5BS6wPJ6N7CdbtjQ2cq94RE6LIaw+jV7jIkM7y4No1HFyjd150vC59yyoKFsy
         se0yBwqc9GWH446zO3L2v6KD5sa//2sNUvBaqiaBXL2NVE4nDzFfJwp3WdqEPjYtW/Io
         /z8NUQjhjBYL+7iAKA9m1ZO8JeYm5x/ROxw2wJP4zeTx6CGC4diAQHBaANr0OJ9leVvB
         xyH++1Zy2G4KPHZXA2bm/Lbr6d7aSeb8TwECisaEaEN/wfxhZVC2yVZW7Nq8WLwlX2WY
         f9EXNHNqmxUhp3chsmKqo5AhYNn+1F4yJLcOAIfhNYG9c1WZB4XvM0KVNyVg/Un2IoAa
         mY2g==
X-Forwarded-Encrypted: i=1; AJvYcCXIKI0eQwu3VxU6rTyqKcMyAHo8nVId4PZAEitrjXou/sqI4eU9Kxggav7iAffwTrjdrVRkP40nWng=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzK82fXb8tzOT5CIyQrssNw1gWXKUs1mLTcHfvFXKjpRNwotUck
	ZV9Y108t84sFlTPbyM9PpYPI834zhwf4diLy1g8i93bEwNjArh26Mm9xytmpHtB2Qg==
X-Gm-Gg: ASbGnctk4OjdSD1dvHqMd/ZoHT6QuVKY25X6sfQKvbFHBIdArrS7wH2lCIZHMUatCzZ
	O5yoXK+9DdnBDVP1qNk54PZDXoHsvYnaDggA8r2f0kvtbGYBouQBAhROkEJMaPnqmA+qn2UorOw
	bNuER/eZ0oMIZL1XqEfguG8KfChWtdSeXkDT9d6Z0q67AMFMPMa2avnA1uajmlDtqBguVqswVQQ
	S84TfFvYpoTizkSnN29AAGcTSV7TkmGP/W8jphYTTFwXP9VLPOiNbecVDpMmsv8bQNmFMWT5NCi
	HD78xNUrD1zZ5ig5F3M+DpsWUmBjVf7VknMUETrl/xs9hYU6G3Ltu5FFHpX/7Q==
X-Google-Smtp-Source: AGHT+IFg2Zmlam0zgMojQO1dsABATgDmftOoeSX7aL0z21wS9OtqdrC/SGY9WsCFlo3/4t9EpkCe2g==
X-Received: by 2002:a05:6402:3085:b0:600:a694:7a23 with SMTP id 4fb4d7f45d1cf-600a6947cecmr13850622a12.0.1747840799044;
        Wed, 21 May 2025 08:19:59 -0700 (PDT)
Message-ID: 
Date: Wed, 21 May 2025 17:19:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
To: Sergii Dmytruk 
Cc: "Daniel P. Smith" ,
 Ross Philipson ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Lukasz Hawrylko , =?UTF-8?Q?Mateusz_M=C3=B3wka?=
 , trenchboot-devel@googlegroups.com,
 xen-devel@lists.xenproject.org
References: 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.05.2025 19:05, Sergii Dmytruk wrote:
> From: Krystian Hebel 
> 
> The file contains TXT register spaces base address, registers offsets,
> error codes and inline functions for accessing structures stored on
> TXT heap.
> 
> Signed-off-by: Krystian Hebel 
> Signed-off-by: Sergii Dmytruk 
> ---
>  xen/arch/x86/include/asm/intel-txt.h | 277 +++++++++++++++++++++++++++
>  xen/arch/x86/tboot.c                 |  20 +-
>  2 files changed, 279 insertions(+), 18 deletions(-)
>  create mode 100644 xen/arch/x86/include/asm/intel-txt.h
> 
> diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
> new file mode 100644
> index 0000000000..07be43f557
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/intel-txt.h
> @@ -0,0 +1,277 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#ifndef ASM__X86__INTEL_TXT_H
> +#define ASM__X86__INTEL_TXT_H
> +
> +/*
> + * TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
> + */
> +#define TXT_PUB_CONFIG_REGS_BASE        0xfed30000U
> +#define TXT_PRIV_CONFIG_REGS_BASE       0xfed20000U
> +
> +/*
> + * The same set of registers is exposed twice (with different permissions) and
> + * they are allocated continuously with page alignment.
> + */
> +#define NR_TXT_CONFIG_SIZE \
> +    (TXT_PUB_CONFIG_REGS_BASE - TXT_PRIV_CONFIG_REGS_BASE)

What does the NR_ in the identifier try to express?

> +/*
> + * Secure Launch defined OS/MLE TXT Heap table
> + */
> +struct txt_os_mle_data {
> +    uint32_t version;
> +    uint32_t reserved;
> +    uint64_t slrt;
> +    uint64_t txt_info;
> +    uint32_t ap_wake_block;
> +    uint32_t ap_wake_block_size;
> +    uint8_t mle_scratch[64];
> +} __packed;

This being x86-specific, what's the __packed intended to achieve here?

> +/*
> + * TXT specification defined BIOS data TXT Heap table
> + */
> +struct txt_bios_data {
> +    uint32_t version; /* Currently 5 for TPM 1.2 and 6 for TPM 2.0 */
> +    uint32_t bios_sinit_size;
> +    uint64_t reserved1;
> +    uint64_t reserved2;
> +    uint32_t num_logical_procs;
> +    /* Versions >= 3 && < 5 */
> +    uint32_t sinit_flags;
> +    /* Versions >= 5 with updates in version 6 */
> +    uint32_t mle_flags;
> +    /* Versions >= 4 */
> +    /* Ext Data Elements */
> +} __packed;

It does affect sizeof() here, which I'm unsure is going to matter.

> +/*
> + * TXT specification defined OS/SINIT TXT Heap table
> + */
> +struct txt_os_sinit_data {
> +    uint32_t version;       /* Currently 6 for TPM 1.2 and 7 for TPM 2.0 */
> +    uint32_t flags;         /* Reserved in version 6 */
> +    uint64_t mle_ptab;
> +    uint64_t mle_size;
> +    uint64_t mle_hdr_base;
> +    uint64_t vtd_pmr_lo_base;
> +    uint64_t vtd_pmr_lo_size;
> +    uint64_t vtd_pmr_hi_base;
> +    uint64_t vtd_pmr_hi_size;
> +    uint64_t lcp_po_base;
> +    uint64_t lcp_po_size;
> +    uint32_t capabilities;
> +    /* Version = 5 */
> +    uint64_t efi_rsdt_ptr;  /* RSD*P* in versions >= 6 */
> +    /* Versions >= 6 */
> +    /* Ext Data Elements */
> +} __packed;

It does really affect the layout here, so can't be removed in this case.

> +/*
> + * Functions to extract data from the Intel TXT Heap Memory. The layout
> + * of the heap is as follows:
> + *  +------------------------------------+
> + *  | Size of Bios Data table (uint64_t) |
> + *  +------------------------------------+
> + *  | Bios Data table                    |
> + *  +------------------------------------+
> + *  | Size of OS MLE table (uint64_t)    |
> + *  +------------------------------------+
> + *  | OS MLE table                       |
> + *  +--------------------------------    +
> + *  | Size of OS SINIT table (uint64_t)  |
> + *  +------------------------------------+
> + *  | OS SINIT table                     |
> + *  +------------------------------------+
> + *  | Size of SINIT MLE table (uint64_t) |
> + *  +------------------------------------+
> + *  | SINIT MLE table                    |
> + *  +------------------------------------+
> + *
> + *  NOTE: the table size fields include the 8 byte size field itself.
> + */
> +static inline uint64_t txt_bios_data_size(void *heap)

Here, below, and in general: Please try to have code be const-correct, i.e.
use pointers-to-const wherever applicable.

> +{
> +    return *((uint64_t *)heap) - sizeof(uint64_t);

For readability it generally helps if excess parentheses like the ones here
are omitted.

> +}
> +
> +static inline void *txt_bios_data_start(void *heap)
> +{
> +    return heap + sizeof(uint64_t);
> +}
> +
> +static inline uint64_t txt_os_mle_data_size(void *heap)
> +{
> +    return *((uint64_t *)(txt_bios_data_start(heap) +
> +                          txt_bios_data_size(heap))) -
> +        sizeof(uint64_t);

This line wants indenting a little further, such that the"sizeof" aligns
with the start of the expression. (Same elsewhere below.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 15:31:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 15:31:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992091.1375867 (Exim 4.92)
	(envelope-from )
	id 1uHlPz-0005O1-Bk; Wed, 21 May 2025 15:31:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992091.1375867; Wed, 21 May 2025 15:31: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 1uHlPz-0005Nu-92; Wed, 21 May 2025 15:31:43 +0000
Received: by outflank-mailman (input) for mailman id 992091;
 Wed, 21 May 2025 15:31:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlPy-0005No-6X
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 15:31:42 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aed1fce8-3658-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 17:31:38 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747841490516469.7242626446938;
 Wed, 21 May 2025 08:31: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" 
X-Inumbo-ID: aed1fce8-3658-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; t=1747841491; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=KzOdOSMBCdMezfTPObSsnAeWmoPx1HgeenyuFmbqPRQg96Xs2eGz3OZdRVCPtyiEqjIGPBd8VvQGNuWxR+mxINB9Bx8ueq+GKls8uARaz5nbqCyM2DMZe9Ep30Qy2/8h/uLjrnNTve8xicXECq81XiRKnrWyhuySiKf8C2ntUlg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747841491; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=k9zwI5bASVGJQ3uKxIsfubGuwhDLMhp3SxVDuBTuMHg=; 
	b=FSnmNFSUylVKjs14VpStWvcOGtx7GdwL24YLbLBS702K3gs6/0/XOR5z34bvCFcXBHPjoMF/pIadrg9h6y9Rr03MIQC26bcYrk3rFg2nx2i0R0znf4dLJ6ceKNH6syB9jKeaUH13lzEegdwbJnQfmMYSY5vvZ4L+tXuKA8x5mM0=
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=1747841491;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=k9zwI5bASVGJQ3uKxIsfubGuwhDLMhp3SxVDuBTuMHg=;
	b=hdWMgyhU0Do++cu74BkM7qypjQKxyZ++mEnHjd4o5Xub90jBV1sjAq780w+voDQ8
	wD7h1iKcLDlCl/BqHy6M/c7t6+a13gkal732oTi2f8XvI2bKIhxnHivBV3BJLvEy2PQ
	t8l8OtvwDsJg36AkdPBvAwQknzxVTfoZ0qCK8LS4=
Message-ID: <958f591f-35ac-4a10-93e2-9301ccfc5353@apertussolutions.com>
Date: Wed, 21 May 2025 11:31:28 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Hyperlaunch/dom0less code sharing
Content-Language: en-US
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Jason Andryuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Xenia Ragiadakou 
References: 
From: "Daniel P. Smith" 
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 5/21/25 10:35, Alejandro Vallejo wrote:
> Hi,
> 
> (There's a TL;DR at the end)
> 
> While working on preparing and reworking the hyperlaunch series for
> upstreaming it's slowly becoming apparent the degree of duplication with
> dom0less.

Yes, this was by design so that when we got to the point of convergence 
it would be apparent where the commonalities are and thus be collapsed.

> Oleksii's latest effort to move all that code into common[*] (see
> ad03faa942b9("xen/common: dom0less: make some...) makes this even clearer.
> There are 1:1 relationships for every key data strucutre, and by deviating
> we're overcomplicating the ability to share code.
> 
>    [*] https://lore.kernel.org/xen-devel/cover.1746468003.git.oleksii.kurochko@gmail.com/
> 
>      dom0less           Hyperlaunch
>      ------------------------------
>      kernel_info        boot_domain
>      bootmodule         boot_module
>      bootmodule_kind   bootmod_type
>      membanks                memmap
>      bootinfo             boot_info

If you go back, you will see less of these differences. A lot of the 
variations have been the results of reviewer's request. And that goes to 
the fact that dom0less was developed with Arm mentality in terminology, 
eg. memory banks verse memory map.

> The difficulty in code sharing is not just unfortunate from a vague sense of
> elegance or neatness. Having different code paths parsing the same DT bindings
> means it's a matter of time before x86 and all other Xen ports have different
> bindings, which would would only worsen the situation wrt code sharing and user
> confusion.

Only if we allowed it, but with that said there are subtleties between 
the arch that will require variation. Such as mode, which is primarily 
an x86 specific.

> I've been trying to get _somewhere_ in using parts of dom0less on x86
> and develop a credible PoC that highlights the use of dom0less parsing
> code paths. The results are interesting.
> 
> While I didn't get to a full integration in the hyperlaunch series as I hoped
> due to time constraints I did get far enough to:
> 
>    1. Replace boot_module, boot_domain and bootmod_type with their dom0less
>       counterparts (pending some cleanup).
>    2. Isolate binding parsing code in common/device-tree so it's dettached from
>       the not-so-common dom0less domain building logic in dom0less-build.c
>    3. Do early module kind detection from x86 using code in (2).
>    4. Do late binding parsing also using code in (2) after unflattening the DTB.
> 
> And it works well enough under QEMU to populate boot_info to a first
> approximation. It's missing hyperlaunch-specific bindings (like "domid"
> or "mode"), but that's just a matter of adding them to the already
> existing per-arch binding parser ("mode", maybe, would be a candidate
> for this) or retrofit them in dom0less ("domid" is a very clear
> candidate for this) and integrating in the larger series to be able to
> actually boot domains.
> 
> The PoC does not go all the way due to time constraints, as I said, but
> I think it goes far enough to convince me it's both feasible and
> beneficial to go in this direction rather than that of a full
> reimplementation on x86, specially seeing how Oleksii already aims to
> have full code reuse on riscv.
> 
> A brave new world would reuse all data (including bootinfo) and code
> (bootfdt.c/bootinfo.c), but I couldn't get that far, and I don't think
> I'll be able to in a timely manner. IOW: I compiled-in device-tree.c,
> but NOT bootfdt.c or bootinfo.c, or any of the others. I merely
> extracted from those files the binding parsing bits of interest.
> 
> It'd be nice to use them, but the domain construction logic is just too
> different at present. As for the code I tested with,  I need to do some serious
> cleanup before it's ready for sharing, and even moreso for review, but before I
> go through that I'd like to reach consensus on the following points before
> investing any more of my time working on the side.
> 
> TL;DR:
> 
> I think we should aim to share binding code wherever possible, using common
> datastructures (kernel_info and bootmodule) as dumping ground for the results
> of the binding parsing functions. I seek agreement on the following 3 points
> for the end goal of DTB multidomain boots on x86 before I start slicing
> my hacks into reasonable chunks.
> 
>    1. We want common data structures, with arch-specific fields to hold
>       information from xen,domain DT nodes
>    2. We want to have a single collection of DTB parsers in the code.
>    3. We want to operate on the unflattened DTB for the majority of parsing.
>      (plus a minimal version on the FDT in order to bootstrap, also common)

As for 3, I can repost my original analysis that went to the working 
group on why using this is not the best idea. Doing 3 would require 
doing at least two, if not three passes on the DTB for x86 with zero 
benefit/need since, unlike Arm, we never have to read from it after 
boot. The way the x86 parser is today, we are walking the DTB only once.

What I would suggest for 2 is that, perhaps, it might be an opportune 
time to review the existing DTB parsing code. Providing a common 
interface to parse standard/spec DTB structures regardless if it is 
coming from an FTB or via the FTB index, aka "unflattened" DTB. Doing so 
would enable a complete reuse within the DTB parsers and remove then 
need for 3.


> (2) and (3) are tightly related. There's many reasons for wanting to use the
> unflattened blobs as much as possible. They range from quirks in specific "dtc"
> versions, to complexities parsing phandles, to corner cases involving duplicate
> properties (i.e: due to .dtsi files), etc. Unflattening an FDT brings a
> lots of "maybe-ok-after-sanitising" FDTs back into canonically correct DTs.
> 
> I'll share the PoC code as soon as as it's in a presentable state.
> Hopefully by the end of the week. But I'm sending this ahead of time to
> start collecting thoughts right away.
> 
> So. Thoughts?


v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed May 21 15:39:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 15:39:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992100.1375877 (Exim 4.92)
	(envelope-from )
	id 1uHlXJ-00064o-1J; Wed, 21 May 2025 15:39:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992100.1375877; Wed, 21 May 2025 15:39: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 1uHlXI-00064h-V0; Wed, 21 May 2025 15:39:16 +0000
Received: by outflank-mailman (input) for mailman id 992100;
 Wed, 21 May 2025 15:39:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlXI-00064b-4S
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 15:39:16 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id be5adc25-3659-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 17:39:13 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1747841949196258.15362504154143;
 Wed, 21 May 2025 08:39: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" 
X-Inumbo-ID: be5adc25-3659-11f0-a2fa-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; t=1747841950; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=OZIUfmRvCVnNETPzommRHutb0jMPgejoNWFt8Xy8Tu1ot/pLPcUBagdWXppxlOgzXa4gNzXWh0uCTHkkWISejhIdw8lVp/L8JJcksOiOrPK+2xa58gdcDmetvu60f+40Wg8uNdFbVtd6a8uoF0CDQP1vOH0FwgbL0B4Y29le3Qo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747841950; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=wQvoDCGpLpyz8uDJKqSsfk2KWp4dhhdOk5HLxm6M23U=; 
	b=Bwpey/p6Wkppjcuu1exIyCUE8u1mKYalgzT7+OSCRyJlbUEvpKKRDLFkczBRkz6CDG1AY8XOM+DzOrhuV6qplm8oqGiJtUVfgt+hxSXx2IdU/tGppqU3xvsswAoqgsZ/QHDosxjljlo60Cx0TSlYYWIxJk/U5TjzIQTr9CCaFDA=
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=1747841950;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:References:From:From:To:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=wQvoDCGpLpyz8uDJKqSsfk2KWp4dhhdOk5HLxm6M23U=;
	b=pdcDbB1/DdXPqu3AQl7cd0KZ80j/sj5453BwDvCAynlEPMVmdeZpvKLaemvdA13j
	1onvRzREoluoee6EJCyWXqld3+EUlv7ZDn9fmXKOkIqm72girFc25T/g67lNvnkhmI7
	4G/G6yLD/KxaXTcwycwJ2BRKWIzcNvUq8tKulf0o=
Message-ID: 
Date: Wed, 21 May 2025 11:39:07 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Hyperlaunch Device Tree Discussion
Content-Language: en-US
References: <85d65163-6120-4653-8ed5-e7752ae7ce48@apertussolutions.com>
From: "Daniel P. Smith" 
To: Xen-devel 
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: <85d65163-6120-4653-8ed5-e7752ae7ce48@apertussolutions.com>
X-Forwarded-Message-Id: <85d65163-6120-4653-8ed5-e7752ae7ce48@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

Greetings,

Per my response to Allejandro's message, here is the response sent the 
the DTB working group formed last year to discuss DTB parsing for x86.


Original Message:

I have copied everyone that attended the hyperlaunch working group a few 
weeks back to ensure everyone has a chance to review and comment.

As a start and to provide a common understanding, first is a quick 
overview of Flattened Device Tree and Xen's "Unflattened Device Tree". 
The intent is to assist everyone in having an equal footing when 
considering the impacts that Device Tree parsing brings.

A Flattened Device Tree (FDT) is a nested linear tree structure that 
uses a combination of tags, layout definition, and headers to allow 
navigation through the tree. Because the layout is nested, if given the 
offset for a node in the FDT, it is possible to start at that node and 
jump directly into the tree to access child nodes and properties. 
Provided below is a visual representation of what any parent node, 
including the root node, may look like:

+------------------------------+
| NODE TAG (parent node)       |
+------------------------------+
| Null-term String (node name) |
+------------------------------+
| PROPERTY TAG                 |
+------------------------------+
| struct property {            |
|   u32 len                    |
|   u32 name_offset            |
| }                            |
+------------------------------+
| Property Data                |
+------------------------------+
| NODE TAG (child node)        |
+------------------------------+
| Null-term String (node name) |
+------------------------------+
| PROPERTY TAG                 |
+------------------------------+
| struct property {            |
|   u32 len                    |
|   u32 name_offset            |
| }                            |
+------------------------------+
| Property Data                |
+------------------------------+
| END NODE TAG (child node)    |
+------------------------------+
| END NODE TAG (parent node)   |
+------------------------------+

Before moving forward, let us clarify some terminology to ensure a 
common understanding when discussing a tree.

  - node path: represents a series of hierarchical child nodes starting 
at the root node
  - adjacent node: the logically next node that is at the same level in 
the tree
  - child node: a node that is a one level lower leaf to another node, 
the parent node
  - tree walk: incrementally walking the nodes, to locate a specific 
node or to iterate over the whole tree

The libfdt library provides handlers for finding the offset of a node, 
as well as handlers to jump to a node offset and iterate only on the 
child nodes. While the libfdt is fairly optimized, the reality is that 
to find a node, the library must do a tree walk starting with the first 
node written in the FDT. If a node is not a path match at the current 
depth, it must cross a null terminated string, all the node's property 
entries and all children nodes to reach the next adjacent node. Once a 
path match for the depth is found, then the search may descend into the 
next depth and repeat the process until a match at that level is found.

This brings us to Xen's "Unflattened Device Tree" (UDT), for which I am 
quoting as I find myself thinking of it in another way, which IMHO is a 
more descriptive name, which is that it is an FDT lookup index. It just 
happens that the implementation for the lookup index structure is a tree 
structure. UDT uses a structure to represent a node and one to represent 
a property. The node structure is a traditional tree structure with 
adjacent and child node pointers. The contents of both structures are 
pointers to the respective memory locations within the FDT. As with the 
FDT, in order to locate a node in the index, a tree walk of the index 
must be done. The difference comes when a node is not a path match, to 
reach the adjacent node, it only needs to access the node pointed to by 
the adjacent node pointer of the current node. UDT provides an API for 
walking the node tree, walking the property list for a node, and methods 
for type-interpreted extraction of property values. NB: the 
type-interpreted extraction API is codified around taking a UDT property 
structure, but the interpreted extraction logic isn't UDT specific as it 
is still reading the property value from the FDT.

The benefit UDT brings is when repeated node lookups and/or repeated 
phandle dereferencing are done. For both FDT and UDT, a tree walk must 
be done. The walk will start with a node, either the root node or one 
for which a reference has already been found, walking each adjacent node 
and descending into a node's children when a path match occurs. For 
phandle dereferencing, the benefit is greater due to the fact that when 
indexing the FDT, phandles get dereferenced, thus allowing direct 
reference in the index. For comparison, a phandle dereference using 
libfdt does a walk of the tree to find the node referenced by the phandle.

The UDT, as implemented, is not without cost. The current implementation 
takes two complete walks of the entire FDT using libfdt. The first pass 
is to obtain the amount of memory that is required to allocate enough 
instances of the UDT node and property structures to represent the full 
tree. The second pass is when the FDT nodes and properties are indexed 
into the UDT.

With the expense of using FDT and UDT established, it is important to 
put that expense into context. Consider hyperlaunch on x86 where the 
arch itself has no DT requirements. In all likelihood, an FDT 
constructed for this arch would only contain the nodes necessary for 
hyperlaunch. If hyperlaunch were constructed x86 only, loading the 
configuration could be done in a single full walk of the FDT, even when 
considering phandle usage. The reason this is true for the phandles 
case, is that as nodes known to be a phandle target are encountered, 
their offset into the FDT could be stored with dereferencing resolved 
post walk.

For DT based archs, currently accepted costs are two FDT node lookups 
along with the two full walks to construct the UDT. These first two node 
lookups being the memory allocation table and the Xen command line. As 
noted above, an FDT node lookup requires a walk of the linear tree until 
the node is located. AIUI at this point is that the number of nodes that 
must be crossed is indeterminate. I did not see anything in the device 
tree specification that the FDT must be packed in the same order as the 
string representation. NB: I have not reviewed the DT compiler to see if 
it optimizes for early access nodes to be packed at the beginning of the 
linear tree to reduce the number of nodes that must be crossed.

While the aforementioned strategy for x86 would be optimal for x86, it 
is not necessarily the best for DT based archs. Hyperlaunch started, and 
currently is, focused on the x86 arch, but long term it was always 
understood that its more expansive design would be desirable by all 
archs. Like anything that moves into common, a slightly less efficient 
approach for one platform is accepted for the benefit of a common 
implementation that reduces the amount of code while increasing the 
number of reviewers.

After listening to everyone's concerns, re-reviewing all of Arm's device 
tree logic, and considering everything in totality, the conclusion is 
that there is a core root cause from with which all the concerns raised 
flow. First a summary of the main concerns raised,

  - The issue of memory allocator(s) available at the time when the 
first FDT walk/parsing occurs.
  - Overhead of doing a more than one FDT walk to obtain the hyperlaunch 
configuration when phandles are in use.
  - Supporting FDT would require the introduction of a 
duplicate/competing set of property parsers.

This root cause is due to a design decision difference made for the 
hyperlaunch domain builder versus the dom0less domain builder and Arm's 
approach to device tree parsing. For dom0less, the approach is to walk 
the UDT index tree at the domain construction time, which appears to 
stem from Arm's need and practice of repeatedly accessing device tree 
entries. Whereas x86 has no need for the device tree and took the 
approach to do a single walk to extract its configuration into a code 
usable structure.

With that understanding, it is believed that these two approaches are 
not diametrically opposed and in fact can be blended together to result 
in a generally optimized approach. The approach will be to conduct two 
full walks of the FDT, an early boot pass before memory allocation is 
available and a second pass after a memory allocator is set up. Both 
passes serve to populate the proposed boot info structure, specifically 
the scope of these passes are as follows:

Early FDT Walk: (static values)
  - calculate the space required for the device tree index
  - count the number of domains defined
  - Xen command line
  - XSM policy
  - arch specific static values, via an arch_early_fdt()

Late FDT Walk: (dynamic values)
  - construct device tree index, aka "unflattened device tree"
  - populate boot modules entries (NB: boot modules are expected to be 
static array)
  - store device tree node index for top level index and hyperlaunch node
  - populate boot domain entries, basis will be device tree index node
  - arch specific dynamic values, via an arch_late_fdt()

By taking this approach which is constructed around a set of arch 
neutral structures will enable another goal of the hyperlaunch series, 
which is to move to having a common domain creation/construction logic. 
Currently, there is a significant amount of duplication in each arch's 
branch for boot time construction of domains. It will also allow 
removing arch specific code from the initialization of common 
infrastructure such as XSM.

V/r,
Daniel P. Smith


From xen-devel-bounces@lists.xenproject.org Wed May 21 15:45:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 15:45:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992112.1375887 (Exim 4.92)
	(envelope-from )
	id 1uHld0-00081x-OZ; Wed, 21 May 2025 15:45:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992112.1375887; Wed, 21 May 2025 15:45: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 1uHld0-00081q-LR; Wed, 21 May 2025 15:45:10 +0000
Received: by outflank-mailman (input) for mailman id 992112;
 Wed, 21 May 2025 15:45:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHlcz-00081k-1E
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 15:45:09 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 918b6372-365a-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 17:45:06 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad216a5a59cso980353066b.3
 for ; Wed, 21 May 2025 08:45:06 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d04b08bsm928214566b.13.2025.05.21.08.45.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 08:45: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" 
X-Inumbo-ID: 918b6372-365a-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747842306; x=1748447106; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Fmlu9LIzefqsnSDBpgSUuQP5QuHaG/iY95IyALdJ1bA=;
        b=DC1zWwHnoYwkX7cCJ82J6R43i2P8QgvHqpbl6PYvf3PuzQwpTJmFU+cnvkdygVP7iY
         XLMWrwIsnOMcpOo3Zczldv3m+ceYMqf6rrM17XdexxPqFJ8rvzU/bRA99e4VD6IyUYgi
         vdmlk0UPNO6EQSYVXd91Qnhkn7lGcGGkLe34lLyl58kVhhwmpmEFdxeT5L17xjc/Lq/q
         sbkKbIPArqC1NglwEk8h89GcKjQcFD/u/XhYtq/2fGdFQmuLrpydov38NbFuf5f/KLWY
         XMVk2td7RlJvewCfvSRPb3h8E/GL0XADp+FAggu6bFJ1WKyWptECIu1+KG6QEeb9+Ktt
         RRXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747842306; x=1748447106;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Fmlu9LIzefqsnSDBpgSUuQP5QuHaG/iY95IyALdJ1bA=;
        b=Kfo7K0kjOvhtkYtslsDGNlbqlmADe05WOTwZ/OAQDyyzysuRaYbiFnr0X/50iUqd5+
         V9an1gd50fDdQ0+qeyHq/cca6F0dt3QifGQqc182hZOsW+xR6K7N0WpjwwqJ6d+o2Zmg
         2yc0mlQaUxv1ekfrpWkqLpPupTzJYsh4Krn1DFEVbg31CJLhstIqO+nTbJsw+cjz+7X/
         NMJ/oAnTUArlS03hg2WlhIbzitDWkBlaMLKn3hG9kh9saUX2QlQOGF1vo8J9m4PTtNmM
         afwtdmqvdXmXh6Q1OOLwxxIbcekjskkkX8j+OSZ/7DK0FH9BvgmOGURi7mMsRUgsGPm/
         X1Yw==
X-Forwarded-Encrypted: i=1; AJvYcCVd3tHX+E0N3IIYSIVLuhyG3BqMxAZelsjj4QTtB9Gq0UCuR5Y76XdwwXzKHKUes154VF7JoktGbBw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxrpnsn6W88Wyw/p9DLolrbAv909kykxKs7XdQcHpfgYtjSzfwo
	5d6BAXtr88Y1z7dUrvyF7eyt8CUg2oLk73hd+lcURDERPXVqLGqpzLR7OfrdvRHj/Q==
X-Gm-Gg: ASbGncutRrzZ0CLx9nxPW+Y61omAGJgWmU+qc2nMDXfvIt0IHGiCYqdIVji7N/ObeQM
	I0HZeY3I8gkq+WB1Nn30/rDabCr0rBUMo6wNPA1DfLnNJ7GFMcS19E/Egl1+yPh1oBqb/aMkbTg
	oplQFkA8w5mJ/0MYcD22jnpVqqsgFxaWXb2BfY950WzvKe6ijQW6NLHKVH+q3mTMMUAomebC34Z
	YlMpcQK2KtWegTAhTvOqw7EG7BfGIRH8utGlEC1riXQ66NBhOiJN92cr6owiP9zmmxTpJOMpapO
	XX+2RCPqR0dSz/7LxrqVB5hhKe+dZs+I7NPJiXxvbCLa0zraXKdMpsbjBxfrGg==
X-Google-Smtp-Source: AGHT+IFwY3EBkA9SdvbUJ07ZxcbYFvj6yaI0lJQioAfj14s6spZSvGy1E6QH2A+bdJV8Ez+fqfXDBA==
X-Received: by 2002:a17:906:fb92:b0:ad5:3746:58fd with SMTP id a640c23a62f3a-ad537465b55mr1449347666b.51.1747842305973;
        Wed, 21 May 2025 08:45:05 -0700 (PDT)
Message-ID: <4896ab0b-f45e-43e9-bcee-f5496717eb2a@suse.com>
Date: Wed, 21 May 2025 17:45:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/22] include/xen/slr-table.h: Secure Launch Resource
 Table definitions
To: Sergii Dmytruk 
Cc: "Daniel P. Smith" ,
 Ross Philipson ,
 trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
References: 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.05.2025 19:05, Sergii Dmytruk wrote:
> The file provides constants, structures and several helper functions for
> parsing SLRT.
> 
> Signed-off-by: Ross Philipson 
> Signed-off-by: Sergii Dmytruk 
> ---
>  xen/include/xen/slr-table.h | 268 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 268 insertions(+)
>  create mode 100644 xen/include/xen/slr-table.h
> 
> --- /dev/null
> +++ b/xen/include/xen/slr-table.h
> @@ -0,0 +1,268 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

GPL-2.0-only is, I think, the one to use for new code.

> +/*
> + *  Copyright (c) 2025 Apertus Solutions, LLC
> + *  Copyright (c) 2025 Oracle and/or its affiliates.
> + *  Copyright (c) 2025 3mdeb Sp. z o.o

I'm curious: Considering the (just) 2 S-o-b, where's the 3rd copyright
line coming from?

> + *  Secure Launch Resource Table definitions
> + */
> +
> +#ifndef XEN__SLR_TABLE_H
> +#define XEN__SLR_TABLE_H
> +
> +#include 

Looks like xen/stdint.h would suffice?

> +#define UEFI_SLR_TABLE_GUID \
> +    { 0x877a9b2aU, 0x0385, 0x45d1, { 0xa0, 0x34, 0x9d, 0xac, 0x9c, 0x9e, 0x56, 0x5f } }

I'm not sure this is a good place to put UEFI GUIDs. Considering e.g ...

> +/* SLR table header values */
> +#define SLR_TABLE_MAGIC         0x4452544d
> +#define SLR_TABLE_REVISION      1
> +
> +/* Current revisions for the policy and UEFI config */
> +#define SLR_POLICY_REVISION         1
> +#define SLR_UEFI_CONFIG_REVISION    1

... this, is the whole concept perhaps bound to UEFI? In which casethe
whole header may want to move to the efi/ subdir?

> +/* SLR defined architectures */
> +#define SLR_INTEL_TXT   1
> +#define SLR_AMD_SKINIT  2

These are both x86, yet the header is put in the common include dir?

> +/* SLR defined bootloaders */
> +#define SLR_BOOTLOADER_INVALID  0
> +#define SLR_BOOTLOADER_GRUB     1
> +
> +/* Log formats */
> +#define SLR_DRTM_TPM12_LOG      1
> +#define SLR_DRTM_TPM20_LOG      2
> +
> +/* DRTM Policy Entry Flags */
> +#define SLR_POLICY_FLAG_MEASURED    0x1
> +#define SLR_POLICY_IMPLICIT_SIZE    0x2
> +
> +/* Array Lengths */
> +#define TPM_EVENT_INFO_LENGTH       32
> +#define TXT_VARIABLE_MTRRS_LENGTH   32
> +
> +/* Tags */
> +#define SLR_ENTRY_INVALID       0x0000
> +#define SLR_ENTRY_DL_INFO       0x0001
> +#define SLR_ENTRY_LOG_INFO      0x0002
> +#define SLR_ENTRY_DRTM_POLICY   0x0003
> +#define SLR_ENTRY_INTEL_INFO    0x0004
> +#define SLR_ENTRY_AMD_INFO      0x0005
> +#define SLR_ENTRY_ARM_INFO      0x0006
> +#define SLR_ENTRY_UEFI_INFO     0x0007
> +#define SLR_ENTRY_UEFI_CONFIG   0x0008
> +#define SLR_ENTRY_END           0xffff
> +
> +/* Entity Types */
> +#define SLR_ET_UNSPECIFIED        0x0000
> +#define SLR_ET_SLRT               0x0001
> +#define SLR_ET_BOOT_PARAMS        0x0002
> +#define SLR_ET_SETUP_DATA         0x0003
> +#define SLR_ET_CMDLINE            0x0004
> +#define SLR_ET_UEFI_MEMMAP        0x0005
> +#define SLR_ET_RAMDISK            0x0006
> +#define SLR_ET_MULTIBOOT2_INFO    0x0007
> +#define SLR_ET_MULTIBOOT2_MODULE  0x0008
> +#define SLR_ET_TXT_OS2MLE         0x0010
> +#define SLR_ET_UNUSED             0xffff
> +
> +/*
> + * Primary SLR Table Header
> + */
> +struct slr_table
> +{
> +    uint32_t magic;
> +    uint16_t revision;
> +    uint16_t architecture;
> +    uint32_t size;
> +    uint32_t max_size;
> +    /* entries[] */
> +} __packed;

If x86-specific, the question on the need for some of the __packed arises
again.

> +/*
> + * Common SLRT Table Header
> + */
> +struct slr_entry_hdr
> +{
> +    uint32_t tag;
> +    uint32_t size;
> +} __packed;
> +
> +/*
> + * Boot loader context
> + */
> +struct slr_bl_context
> +{
> +    uint16_t bootloader;
> +    uint16_t reserved[3];
> +    uint64_t context;
> +} __packed;
> +
> +/*
> + * Prototype of a function pointed to by slr_entry_dl_info::dl_handler.
> + */
> +typedef void (*dl_handler_func)(struct slr_bl_context *bl_context);

It being an internal header, ...

> +/*
> + * DRTM Dynamic Launch Configuration
> + */
> +struct slr_entry_dl_info
> +{
> +    struct slr_entry_hdr hdr;
> +    uint64_t dce_size;
> +    uint64_t dce_base;
> +    uint64_t dlme_size;
> +    uint64_t dlme_base;
> +    uint64_t dlme_entry;
> +    struct slr_bl_context bl_context;
> +    uint64_t dl_handler;

... why can't this type be used here then? This would presumably avoid a
typecast later.

> +static inline void *
> +slr_end_of_entries(struct slr_table *table)
> +{
> +    return (uint8_t *)table + table->size;

Considering the function's return type, why not cast to void * (or perhaps
const void *, if the return type also can be such)?

> +}
> +
> +static inline struct slr_entry_hdr *
> +slr_next_entry(struct slr_table *table, struct slr_entry_hdr *curr)
> +{
> +    struct slr_entry_hdr *next = (struct slr_entry_hdr *)
> +                                 ((uint8_t *)curr + curr->size);
> +
> +    if ( (void *)next >= slr_end_of_entries(table) )
> +        return NULL;

Is this sufficient as a check? With it fulfilled, ...

> +    if ( next->tag == SLR_ENTRY_END )

... this member access may still be out of bounds. IOW the question is what
level of checking is really adequate here.

> +        return NULL;
> +
> +    return next;
> +}
> +
> +static inline struct slr_entry_hdr *
> +slr_next_entry_by_tag (struct slr_table *table,
> +                       struct slr_entry_hdr *entry,
> +                       uint16_t tag)
> +{
> +    if ( !entry ) /* Start from the beginning */
> +        entry = (struct slr_entry_hdr *)((uint8_t *)table + sizeof(*table));

Extending from the earlier comment - if the inner cast was to void * here,
the outer one could be dropped altogether.

Jan


From xen-devel-bounces@lists.xenproject.org Wed May 21 15:50:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 15:50:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992120.1375897 (Exim 4.92)
	(envelope-from )
	id 1uHliJ-00017U-Bi; Wed, 21 May 2025 15:50:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992120.1375897; Wed, 21 May 2025 15:50: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 1uHliJ-00017N-8X; Wed, 21 May 2025 15:50:39 +0000
Received: by outflank-mailman (input) for mailman id 992120;
 Wed, 21 May 2025 15:50:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHliI-00015Q-2u
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 15:50:38 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 561bdd70-365b-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 17:50:36 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43d04dc73b7so76987935e9.3
 for ; Wed, 21 May 2025 08:50:36 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f3ce483bsm73019585e9.33.2025.05.21.08.50.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 08:50: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" 
X-Inumbo-ID: 561bdd70-365b-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747842636; x=1748447436; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=yS+eYEND79sXHLH0pfeL2QUeK3wZNWKJtSI1kmxVrxQ=;
        b=aKodymekw4gMipWviUsioYbzorBX8pJAblC1/ydsyZXERMjzBExWkj6PzkvKQfMMF2
         RrlCb7uvFEf1rLSJB9x4/IG0x9FasWVtF6258mCvihOXXcAZTzyxdvCVhyr7Te+LaVfH
         0A5iFJieIkiwlAtqaR8OYekVePfRj1iwrUCRk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747842636; x=1748447436;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yS+eYEND79sXHLH0pfeL2QUeK3wZNWKJtSI1kmxVrxQ=;
        b=TcyXaMiD+AhhMTwPOfqDm5N5DWlnwUrcpZC8FhJ9xivVvIv0ilWNTxRq5CH0Prlv7E
         h3sW/CuBRjma0gi5dcCfu8zLccS/p+aMwluKgbNCdqV/lBQ148J4kyx7h/hhbjaBiruj
         ihzeka7Sp5ob6XxFI2n508z4Us4Nn3yJy87uemizQi0WlMVbn1J2W/Tyy2Uj6gT2cuPB
         Thq9DGT4LUsLIN7+CKmMgGM9UrQtJ9mCVpR+kX+NZ5RYQLzpUsjP3LFcFtpB05t4mpxg
         CgHzwl+7uwdNXvlkfSK4e/OPl5FTHl99jI3hXhRoOMYXPAU+EyfewgUeUPxzcojfMj1Z
         QJcw==
X-Forwarded-Encrypted: i=1; AJvYcCU+uL9NkFD0a6xudp50aNdlDo9cXI8BKwOHSlS/kUvE6WU5ZhhIdc3YXrFD2DczoZavD15O/kJI4lQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw2rNWObbY0IReU7Ose5GMMUaTgb+MY50C13HJqM1QVEA93IZP8
	srG6LwDKFBxz+D6u7rtG9PSm3xbPBC1zJLuSG3sx3+v9RgtOdB8uTXv2S1+Aq9pY/c8=
X-Gm-Gg: ASbGncvMTzjQEJQN6xFixdHq/TVGJYrwlj9RySBsI7Casmg5514zEGpMm6yqhMm3FyV
	897BLTTi3LjfFujP5Aq8JcKZQPtfcaQzc0UfvWlBkmOOJbxiGfKq1hEiT177JR9EOhLa7FJAIf7
	RVtbPWhVbYLPPt0plKkvwFm1DqCW0jszaPR4fCO46+iSyKoq6Bheb/0fSfiaY4kfTbpbxiu/VDG
	hHB13svi+iis2SDpolFMZifMG+IcBHWH8kDD5L5NeLsuRmFEub7SWd3UmABRWrSZvnquZQSVdNP
	U3iSCvDBoZAuPEfSIifEFpzBEnTTaF79aC/Ld5TXbEldJTY98asRu6sl2bIcMsfbqA1vrXOhmpo
	THdKzSxPOvJjLPDPB
X-Google-Smtp-Source: AGHT+IHbtZ7mSQ3tPpaOfil4jJb/yV2RyAMklZLNgTt0HzAPhDBCzr4EL2uLGWv4H5C5gfGlC2nPGA==
X-Received: by 2002:a05:600c:8597:b0:43c:fe15:41cb with SMTP id 5b1f17b1804b1-442fd780527mr223202855e9.15.1747842635822;
        Wed, 21 May 2025 08:50:35 -0700 (PDT)
Message-ID: 
Date: Wed, 21 May 2025 16:50:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/22] include/xen/slr-table.h: Secure Launch Resource
 Table definitions
To: Jan Beulich , Sergii Dmytruk 
Cc: "Daniel P. Smith" ,
 Ross Philipson ,
 trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
References: 
 
 <4896ab0b-f45e-43e9-bcee-f5496717eb2a@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: <4896ab0b-f45e-43e9-bcee-f5496717eb2a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21/05/2025 4:45 pm, Jan Beulich wrote:
> On 13.05.2025 19:05, Sergii Dmytruk wrote:
>> +/* SLR defined architectures */
>> +#define SLR_INTEL_TXT   1
>> +#define SLR_AMD_SKINIT  2
> These are both x86, yet the header is put in the common include dir?

ARM have a DRTM technology in progress, which will be 3 here in due course.

OpenPOWER and RISC-V are also investigating DRTM.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 21 16:02:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:02:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992130.1375906 (Exim 4.92)
	(envelope-from )
	id 1uHltX-00041I-AI; Wed, 21 May 2025 16:02:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992130.1375906; Wed, 21 May 2025 16:02: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 1uHltX-00041B-7p; Wed, 21 May 2025 16:02:15 +0000
Received: by outflank-mailman (input) for mailman id 992130;
 Wed, 21 May 2025 16:02:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uHltW-000415-2G
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:02:14 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uHltV-0062Uo-23;
 Wed, 21 May 2025 16:02:13 +0000
Received: from [15.248.2.235] (helo=[10.24.67.107])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uHltV-007167-0h;
 Wed, 21 May 2025 16:02: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=ofZ0TmNT3UO0L4t2n85+JQXYCvXKSh2/A6Pr2hwNnjw=; b=PghmeuUv6QzJZe1VKeSBeRjxED
	rSqA1muEOe6BCiMXwOp5uQV6ywjrw8bs8sMEnDxNnlot/f/LKE58zx3/KzJIzm1LOgQHWrVkJGh3p
	0hswl2UIwKZPPhKcLPixD3ZhLiGougKl6bUwsOOdZjDy7yo9ukCGsR/nSqMn6ujJJC88=;
Message-ID: <55778d7c-e559-4ae3-a6f6-cb74e6e1d1a8@xen.org>
Date: Wed, 21 May 2025 17:02:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/vpci: fix handling of BAR overlaps with non-hole
 regions
Content-Language: en-GB
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Jan Beulich , Andrew Cooper ,
 Stefano Stabellini ,
 Victor M Lira 
References: <20250516083159.61945-1-roger.pau@citrix.com>
From: Julien Grall 
In-Reply-To: <20250516083159.61945-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Roger,

On 16/05/2025 09:31, Roger Pau Monne wrote:
> For once the message printed when a BAR overlaps with a non-hole regions is
> not accurate on x86.  While the BAR won't be mapped by the vPCI logic, it
> is quite likely overlapping with a reserved region in the memory map, and
> already mapped as by default all reserved regions are identity mapped in
> the p2m.  Fix the message so it just warns about the overlap, without
> mentioning that the BAR won't be mapped, as this has caused confusion in
> the past.
> 
> Secondly, when an overlap is detected the BAR 'enabled' field is not set,
> hence other vPCI code that depends on it like vPCI MSI-X handling won't
> function properly, as it sees the BAR as disabled, even when memory
> decoding is enabled for the device and the BAR is likely mapped in the
> p2m.  Change the handling of BARs that overlap non-hole regions to instead
> remove any overlapped regions from the rangeset, so the resulting ranges to
> map just contain the hole regions.  This requires introducing a new
> pci_sanitize_bar_memory() that's implemented per-arch and sanitizes the
> address range to add to the p2m.
> 
> For x86 pci_sanitize_bar_memory() removes any regions present in the host
> memory map, for ARM this is currently left as a dummy handler to not change
> existing behavior.
> 
> Ultimately the above changes should fix the vPCI MSI-X handlers not working
> correctly when the BAR that contains the MSI-X table overlaps with a
> non-hole region, as then the 'enabled' BAR bit won't be set and the MSI-X
> traps won't handle accesses as expected.
> 
> Reported-by: Stefano Stabellini 
> Fixes: 53d9133638c3 ('pci: do not disable memory decoding for devices')
> Signed-off-by: Roger Pau Monné 
> Tested-by: Victor M Lira 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992137.1375918 (Exim 4.92)
	(envelope-from )
	id 1uHlvG-0004X4-Mh; Wed, 21 May 2025 16:04:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992137.1375918; Wed, 21 May 2025 16:04: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 1uHlvG-0004Wx-Ic; Wed, 21 May 2025 16:04:02 +0000
Received: by outflank-mailman (input) for mailman id 992137;
 Wed, 21 May 2025 16:04:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvF-0004Wm-Vq
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:02 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3518b82e-365d-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 18:04:00 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-60179d8e65fso3005936a12.0
 for ; Wed, 21 May 2025 09:04:00 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.03.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:03:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3518b82e-365d-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843439; x=1748448239; 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;
        bh=esmqiTpleEhtSL1o478nEONFk3pNRpgcw9ytAzP+Zko=;
        b=JPsse5QT0kTB3ii4DTYTy/2AkR7z4TCkTJbaBLaSYsXuacjYgPc0sIqmFSiP8MR2Ox
         n5setVIasEaOjOG+k67yAFewpanVO0qr26JQhiboTEyigex22o0jrxmprsQ/tcaZE/0O
         N+CoF5PGGuQ02LcIrN4ty9EtAgi87IENHCaTTiiEpRJYeVXkfLvRlTt4ar9vl4rnAT0d
         Sa+rzjRP08HxOYw109ju2Vb+fTJclD9gM6N24S0J//anjjqp4nInSsvplMo7W+ubyzKt
         NwhzDda4mnTd9Kac0iVjDmE7dDd9wPUeqPkYxIsAn/wX6A1B8kmYu5Pg/UDrmOsOthRw
         tlSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843439; x=1748448239;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=esmqiTpleEhtSL1o478nEONFk3pNRpgcw9ytAzP+Zko=;
        b=W3qCqVChClMmsLcgVObbw+1l7Eq/e8VO9T2s7IL9Dyhms0qpfDadFI7eORpDcUgQRs
         lyTsivDuftbSbHwv8HvUbKjaOr+VdKWTij/YYTxMKl0F1wWGwyCszzgYgOI80+jT05JI
         xKSMhILRCTBOadFkKG/93gmaI7uoK5MKQWRnb6/vVtBmWC+O4V26GDVQPVs/9f7fzqDd
         xJl8t/PIFxIbauyFWNem2Z2V72l/24jShrqwtUHKGuRUBHUy/TmvctMcHpd/ifinUhoT
         xm42vtAQLxmMOzCVSOlvyWRNeZOt6jPBtVf/QwRSHNnd7csqdUj5O/DO1RCDx6ijL8Rq
         t1cA==
X-Gm-Message-State: AOJu0Yw9SPUeBmWiOiPN8aHspdShglmfCPHxuHonkb6K3/C8+Z41XNpn
	4ib81B8o7+3m0Fbv70RyizxnCmvqK7RMXqDFlVcEM7mvG6g1EH9y5ZudzeFVgQ==
X-Gm-Gg: ASbGncspfTkhzzQsxmzQuU9pFSMKTdIkpmQZqe21CyvzZoLJy5L0QCd8GCsNmYQqv6F
	aQ5AyI6848lzbb7RqCnZ/sGe7+WG1coanFQ9zwiHGxfun/9nmvvxsbDgfVcdLmmzALNYYKQm7kD
	S/UqmfehBHl3mdmWB8mXweoiUqve5pTWAzg7Qs3AuYeeHxOAZ+Niur4CsS95HdzlXohMTPLwco/
	b1xB5umoiXjcEOAOyNHkD0MZp9omhSPrmETPmxqWXEW1fI7jtAq7VFyTBwmTzl60qh6tnYZeaS/
	N+VwH90j1nquhq444Q8BnP16Z4agoCdpxz1KKMxv4jhtdcTJGFZ7tctbeVpWHoqvkE+jWJ3GWzR
	SPuXcWVdwdx5Sol5/yBTDnXvYD7jL
X-Google-Smtp-Source: AGHT+IESSSVPWiASZ+Y9GLyuYwdM3CLR8aCAhv91SouE2vDzW4qcX0H0rZ49E8IrRb0vYJWkqtSWbg==
X-Received: by 2002:a05:6402:51c7:b0:601:9531:68b8 with SMTP id 4fb4d7f45d1cf-60195316a37mr18213015a12.18.1747843438828;
        Wed, 21 May 2025 09:03:58 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Doug Goldstein 
Subject: [PATCH v3 00/14] riscv: introduce basic UART support and interrupts for hypervisor mode
Date: Wed, 21 May 2025 18:03:40 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The patch series introduces basic UART support (in interrupt mode) and support of
interrupts for hypervisor mode.

To implement this the following has been added:
- APLIC and IMISC initialization.
- Introduce of intc_hw_operations abstraction.
- Introduce some APLIC and IMSIC operations.
- Introduce init_IRQ(), platform_get_irq() and setup_irq() functions.
- Update do_trap() handler to handle IRQ_S_EXT.
- Introduce some other functions such as: get_s_time(), smp_clear_cpu_maps(),
  ioremap().
- Enable UART. 

CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1829069921
---
Changes in V2:
 - Merged to staging:
    xen/riscv: initialize bitmap to zero in riscv_fill_hwcap_from_isa_string()
    xen/asm-generic: introduce asm-generic/irq-dt.h
 - All other changes are patch-specific. Please check each patch separately.
---

Oleksii Kurochko (14):
  xen/riscv: introduce smp_prepare_boot_cpu()
  xen/riscv: introduce support of Svpbmt extension and make it mandatory
  xen/riscv: add ioremap_*() variants using ioremap_attr()
  xen/riscv: introduce init_IRQ()
  xen/riscv: introduce platform_get_irq()
  xen/riscv: dt_processor_hartid() implementation
  xen/riscv: introduce register_intc_ops() and intc_hw_ops.
  xen/riscv: imsic_init() implementation
  xen/riscv: aplic_init() implementation
  xen/riscv: introduce intc_init() and helpers
  xen/riscv: implementation of aplic and imsic operations
  xen/riscv: add external interrupt handling for hypervisor mode
  xen/riscv: implement setup_irq()
  xen/riscv: add basic UART support

 automation/scripts/qemu-smoke-riscv64.sh |   1 +
 docs/misc/riscv/booting.txt              |   4 +
 xen/arch/riscv/Kconfig                   |   5 +
 xen/arch/riscv/Makefile                  |   3 +
 xen/arch/riscv/aplic-priv.h              |  38 ++
 xen/arch/riscv/aplic.c                   | 300 ++++++++++++++
 xen/arch/riscv/cpufeature.c              |   2 +
 xen/arch/riscv/imsic.c                   | 474 +++++++++++++++++++++++
 xen/arch/riscv/include/asm/Makefile      |   1 +
 xen/arch/riscv/include/asm/aplic.h       |  73 ++++
 xen/arch/riscv/include/asm/cpufeature.h  |   1 +
 xen/arch/riscv/include/asm/fixmap.h      |   2 +-
 xen/arch/riscv/include/asm/imsic.h       |  84 ++++
 xen/arch/riscv/include/asm/intc.h        |  32 ++
 xen/arch/riscv/include/asm/io.h          |  10 +-
 xen/arch/riscv/include/asm/irq.h         |  24 ++
 xen/arch/riscv/include/asm/mm-types.h    |   8 +
 xen/arch/riscv/include/asm/page.h        |  23 +-
 xen/arch/riscv/include/asm/smp.h         |  17 +
 xen/arch/riscv/intc.c                    |  55 +++
 xen/arch/riscv/irq.c                     | 223 +++++++++++
 xen/arch/riscv/mm.c                      |  30 ++
 xen/arch/riscv/pt.c                      |  20 +-
 xen/arch/riscv/setup.c                   |  21 +-
 xen/arch/riscv/smpboot.c                 |  85 ++++
 xen/arch/riscv/stubs.c                   |  11 -
 xen/arch/riscv/traps.c                   |  19 +
 xen/arch/riscv/xen.lds.S                 |   2 +
 xen/drivers/char/Kconfig                 |   3 +-
 29 files changed, 1537 insertions(+), 34 deletions(-)
 create mode 100644 xen/arch/riscv/aplic-priv.h
 create mode 100644 xen/arch/riscv/imsic.c
 create mode 100644 xen/arch/riscv/include/asm/aplic.h
 create mode 100644 xen/arch/riscv/include/asm/imsic.h
 create mode 100644 xen/arch/riscv/include/asm/mm-types.h
 create mode 100644 xen/arch/riscv/irq.c
 create mode 100644 xen/arch/riscv/smpboot.c

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992138.1375927 (Exim 4.92)
	(envelope-from )
	id 1uHlvI-0004lz-1I; Wed, 21 May 2025 16:04:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992138.1375927; Wed, 21 May 2025 16: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 1uHlvH-0004lr-TY; Wed, 21 May 2025 16:04:03 +0000
Received: by outflank-mailman (input) for mailman id 992138;
 Wed, 21 May 2025 16:04:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvG-0004Wm-TD
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:02 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 35c55240-365d-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 18:04:01 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-60236e3d093so1573669a12.3
 for ; Wed, 21 May 2025 09:04:01 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.03.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:03: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" 
X-Inumbo-ID: 35c55240-365d-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843440; x=1748448240; 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;
        bh=shglBms3cAYrXtkagIZN9N+XVCLYlAM3GBQ8WROjCv4=;
        b=mZrN6r2fPHSISpLslWZngLYwmK0y5nAMxIn26CogtZpnGRs7j3uYJGgVRcSxxOK3Ov
         CafF80a/yiJXYSycNHCSP5BzUp2fdwDmUiAHAh4vmjZH2vfYI33HeI/P+14e8SJ0xpwq
         pCabSaeaNCWFLyCaL0NzGfHaTU4hgXWHfRlhajpTScIhl+VPUiXO89YTKPydlNhKlVwg
         7qykmMSduMtbykvwrgY0aA+kQzN3ugTxugk88923DvidhVUbvGl1IL2aYYxgmvlr0RFg
         7wIlMXCRCjThGGMFvmrL3EIlxy4SNrQA1mjUP5qURoQ4WASgIvpofmeuMVKRHIzIM0CR
         iLcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843440; x=1748448240;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=shglBms3cAYrXtkagIZN9N+XVCLYlAM3GBQ8WROjCv4=;
        b=iZ96X5iZAvqZyQ4ZInX2N0FyuUtFA1n3CsVyn9zK+QimKtQKw5Uo561dJMn+NKiag3
         ccklRQfSAwL6DvOXrkYErKxY9xIfqMp0aWwyXdDCnCmWs0MFOcsfjejk9NTxYAFQTPB0
         WfF+d1qFkNX378lmTAwjq0VnXH/8hZJM9kNK86pnB7zgDoJTVsIqP3xXirVjmLMzIjSm
         qomgFa2pKTQtoynNFKsjZUr/whcWCWjlNa47u9zgwgazfrEck37d+G4j6UssgTaqkyND
         NWIPhkrIhg9H5beRIFTwKbDLLX84iSJoxLp/xwT7nExUm/+bX1ncTRV30YAOT0WNczzF
         US+A==
X-Gm-Message-State: AOJu0YzIpNNXXK12rAH4u+qQy9sqAECnU1sHDUZeLUWOSF8Co4kxqc8I
	wI3xgoM6+94oBxXHqS7ZP4n0nEdXsXqnlRY0WJmHG9USA+59MAo6aGLj8Or3fQ==
X-Gm-Gg: ASbGncvKY39fDuF1JNqOL2U6AptC3KOGktXCXKx+k4+5oUNlqRmuj/vYkvPlG9CZ1s3
	muYKaOuSVGzsD/ZFWU4nqinPWi9HNQNKW7mGyqKRgQgKlZ3LHnZ2UWWCza+Z2PNdUXVUz+2bGlE
	Jwgu4PWx8jEeXQQ7aLrf/7OiIAwDDmAr3XxMJiws9D/40RVMZE2gmzyESeLwh4MWHjk85SQIyMn
	ydmFR02YQqXMNRuSUaCFwCEXvaAjXU/qCy3I1+Yz+HXMZ7NRHIqNKButJYX4P9TEkrTNJEhamBq
	vQ0SfT0INZUFuVslrlh4s+j1l23LljX6IMMCyzV4Xfm0zwUxkDtwzgJ48N2SGJNKyKbfW4MNuA3
	Xy/aYxpXcH6Qfx1Z7Dw==
X-Google-Smtp-Source: AGHT+IGXKA2S9+ecIE6syxuKTBTXlChTOcT8GX4dk5kuzybbiWRvidQud5EUiYkHTkrzJvp6rSGEcw==
X-Received: by 2002:a05:6402:3492:b0:601:ef7e:fb49 with SMTP id 4fb4d7f45d1cf-601ef7efe12mr8735000a12.12.1747843439705;
        Wed, 21 May 2025 09:03:59 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 01/14] xen/riscv: introduce smp_prepare_boot_cpu()
Date: Wed, 21 May 2025 18:03:41 +0200
Message-ID: <33f3e8378631f6b73148402bbb0b6bb3c64bf754.1747843009.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Initialize cpu_{possible, online}_map by using smp_prepare_boot_cpu().

Drop DEFINE_PER_CPU(unsigned int, cpu_id) from stubs.c as this variable isn't
expected to be used in RISC-V at all.

Move declaration of cpu_{possible,online}_map from stubs.c to smpboot.c
as now smpboot.c is now introduced.
Other defintions keep in stubs.c as they are not initialized and not needed, at
the moment.

Drop cpu_present_map as it is enough to have cpu_possible_map. Also, ask
linker to provide symbol for cpu_present_map as common code references it.

Move call of set_processor_id(0) to smp_prepare_boot_cpu().

Signed-off-by: Oleksii Kurochko 
---
Changes in V3:
 - Move call of set_processor_id(0) inside smp_prepare_boot_cpu().
 - Update the commit message.
---
Changes in v2:
 - Add __read_mostly for cpu_online_map.
 - Add __ro_after_init for cpu_possible_map.
 - Drop cpu_present_map and cpumask_copy(&cpu_present_map, &cpu_possible_map);
 - Drop cpumask_clear() for cpu_{possible,online}_map.
 - Ask the linker provide the symbol for cpu_present_map as common code uses
   it.
 - s/smp_clear_cpu_maps/smp_prepare_boot_cpu.
 - Include  in setup.c as smp_prepare_boot_cpu() is declare in that
   header now.
   Also, drop inclusion of asm/smp.h in setup.c asm xen/smp.h has inclusion of
   asm/smp.h.
 - Update the commit message.
---
 xen/arch/riscv/Makefile  |  1 +
 xen/arch/riscv/setup.c   |  4 ++--
 xen/arch/riscv/smpboot.c | 16 ++++++++++++++++
 xen/arch/riscv/stubs.c   |  6 ------
 xen/arch/riscv/xen.lds.S |  2 ++
 5 files changed, 21 insertions(+), 8 deletions(-)
 create mode 100644 xen/arch/riscv/smpboot.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index d882c57528..f42cf3dfa6 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -10,6 +10,7 @@ obj-y += sbi.o
 obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
+obj-y += smpboot.o
 obj-y += stubs.o
 obj-y += time.o
 obj-y += traps.o
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 4e416f6e44..a9c0c61fb6 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -19,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /* Xen stack for bringing up the first CPU. */
@@ -72,7 +72,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     remove_identity_mapping();
 
-    set_processor_id(0);
+    smp_prepare_boot_cpu();
 
     set_cpuid_to_hartid(0, bootcpu_id);
 
diff --git a/xen/arch/riscv/smpboot.c b/xen/arch/riscv/smpboot.c
new file mode 100644
index 0000000000..0f9c2cc54a
--- /dev/null
+++ b/xen/arch/riscv/smpboot.c
@@ -0,0 +1,16 @@
+#include 
+#include 
+#include 
+
+#include 
+
+cpumask_t __read_mostly cpu_online_map;
+cpumask_t __ro_after_init cpu_possible_map;
+
+void __init smp_prepare_boot_cpu(void)
+{
+    set_processor_id(0);
+
+    cpumask_set_cpu(0, &cpu_possible_map);
+    cpumask_set_cpu(0, &cpu_online_map);
+}
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index 83416d3350..fdcf91054e 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -11,12 +11,6 @@
 
 /* smpboot.c */
 
-cpumask_t cpu_online_map;
-cpumask_t cpu_present_map;
-cpumask_t cpu_possible_map;
-
-/* ID of the PCPU we're running on */
-DEFINE_PER_CPU(unsigned int, cpu_id);
 /* XXX these seem awfully x86ish... */
 /* representing HT siblings of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index 818aa43669..8c3c06de01 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -165,6 +165,8 @@ SECTIONS
     ELF_DETAILS_SECTIONS
 }
 
+PROVIDE(cpu_present_map = cpu_possible_map);
+
 ASSERT(IS_ALIGNED(__bss_start,      POINTER_ALIGN), "__bss_start is misaligned")
 ASSERT(IS_ALIGNED(__bss_end,        POINTER_ALIGN), "__bss_end is misaligned")
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992139.1375933 (Exim 4.92)
	(envelope-from )
	id 1uHlvI-0004nr-Cj; Wed, 21 May 2025 16:04:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992139.1375933; Wed, 21 May 2025 16: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 1uHlvI-0004nK-4w; Wed, 21 May 2025 16:04:04 +0000
Received: by outflank-mailman (input) for mailman id 992139;
 Wed, 21 May 2025 16:04:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvG-0004XB-Vf
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:03 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 36443578-365d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:04:02 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-601956fa3beso7489603a12.0
 for ; Wed, 21 May 2025 09:04:02 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.03.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:04: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" 
X-Inumbo-ID: 36443578-365d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843441; x=1748448241; 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;
        bh=Vhh7mLKOS422FBFt4UIWy2zs58dqVadBUh2l97wxS44=;
        b=JHwIyEJ29XJTqw83GuTyLOJbaMX05R8tTSh++dS2c+ScoLs50HZsFbRi0nOIBT/jBB
         9dDpq7V2h4IcQuET7QBQbte1pvIoljRtKe9wApAuWeTccIcrrEjX4/IzQEndcBcsucnA
         WhOt62WIGLV2Hg2YCQeQQ7QlB4KGZYjSj/7kO8oZQNJdySg74+r24VZXzqHkjTmqDwKu
         +8wrAiP8EacctWDo+zrpHM3WEj8TIPzA2pKm3MNxB+ix6+N2sEnNuPfJSiY2gfSaKVQA
         SlH6A3BmPX8KpTpCIWHKVF5x8RlFHa3jvJ8mV9KXMQwDhWY+i6FVgpMDveo/VmxtBBMz
         gtTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843441; x=1748448241;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Vhh7mLKOS422FBFt4UIWy2zs58dqVadBUh2l97wxS44=;
        b=EckL5q5gqnZJyOLGzznq4Vy+ZnU5GhDp8mcJJcqoitV3JKh25rU2m0hnsrFMlnl0Ci
         s2475CXfmssK7+0fun1gYEXz6k7kSMpl5EUHVI3gPyXySl2WJdAW6PDgq7wocq6mw0Jl
         aKB8LNU4rj37feemkZBHsRNV9VJHa5UxFWHZCxKbp6UmE2uIcqHzu2wU2XCGbea/4gaA
         E2DHJGMYYLu0cVIZHh2WUSoSQ92g4yRyu9br9Pvkib9K4KwVwdSuzqlRmvhZhJcisIYU
         zdw/2q2SNNiWWeX7D/geGipgk9yfDh89aqn1xb08/RITGOvFH5og5R59gdCKo9fYXo0j
         4HXg==
X-Gm-Message-State: AOJu0YwsLkzh+Fpnr14bgaH6rm601yf4Eo2p3Uz2/k6ZexSvIDTLeVDr
	gsAGsYEYEGOxtXBq5sjttRi8Ohdb9RThRSAQ2XgMWv3cGkPCWSFz5ceStC8yrg==
X-Gm-Gg: ASbGnctNQmDL3/u4LHNy0LHUUgqm5xdLszhdEiMWAKy1phtowgOpPIbJQsQsoUp9nei
	9v4iGGifF/rsOqrdUQ5RTvNiCeqraM8GKRh4io6Jy6uojHWEjm70JCau8HSuw+sbwujY5c9zWsZ
	JiUpyzaRsmI+KwzywHlGnDmQ9pYqS6Mcf3o1+KDNgimtJMuGX8g7c6GTdUg5sxJULjYS8yHJRQi
	s8pU4UGBzrbqlg6nmjGZTw5uv9TxD4UKvjAl58vKNsJhY+djzlUcmarFLERacmEAEUeNpP/rN5K
	rxjOTPuMw49cxQEufDYG56EDc/OJ94VbZtbe7rq5kLgyT5FKITwuSsAcStFoCZTTXrozwordpNv
	e1Rc/lLYXs1JxD1ukMw==
X-Google-Smtp-Source: AGHT+IFhG7x4HtSEX7BJV/ofoAM1+NoJCsmEJv58pdf+SV/Z03PPdGmhTMEbAKl3/8PMUl63cZdGLA==
X-Received: by 2002:a05:6402:254a:b0:601:9aeb:3d9 with SMTP id 4fb4d7f45d1cf-6019aeb05f4mr15520397a12.20.1747843440712;
        Wed, 21 May 2025 09:04:00 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Doug Goldstein ,
	Stefano Stabellini ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis 
Subject: [PATCH v3 02/14] xen/riscv: introduce support of Svpbmt extension and make it mandatory
Date: Wed, 21 May 2025 18:03:42 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Svpbmt extension is necessary for chaning the memory type for a page contains
a combination of attributes that indicate the cacheability, idempotency,
and ordering properties for access to that page.

As a part of the patch the following is introduced:
- Svpbmt memory type defintions: PTE_PBMT_{NOCACHE,IO}.
- PAGE_HYPERVISOR_{NOCACHE,WC}.
- RISCV_ISA_EXT_svpbmt and add a check in runtime that Svpbmt is
  supported by platform.
- Update riscv/booting.txt with information about Svpbmt.
- Update logic of pt_update_entry() to take into account PBMT bits.

Use 'unsigned long' for pte_attr_t as PMBT bits are 61 and 62 and it doesn't
fit into 'unsigned int'. Also, update function prototypes which uses
'unsigned int' for flags/attibutes.

Enable Svpbmt for testing in QEMU as Svpmbt is now mandatory for
Xen work.

Signed-off-by: Oleksii Kurochko 
---
Changes in v3:
 - Remove dependecy "depends on RISCV_64" for HAS_SVPBMT as it is selected by
   CONFIG_RISCV_64.
 - Move HAS_SVPMBT's help text to commit message as it's not too much sense
   to have it for a prompt-less option.
 - Move definition of PTE_PMBT_{NOCACHE,IO} up closer to arch-specific
   definitions.
 - Update the commit message and subject.
 - Add a comment above PAGE_HYPERVISOR_NOCACHE.
---
Changes in v2:
 - new patch.
---
 automation/scripts/qemu-smoke-riscv64.sh |  1 +
 docs/misc/riscv/booting.txt              |  4 ++++
 xen/arch/riscv/Kconfig                   |  4 ++++
 xen/arch/riscv/cpufeature.c              |  2 ++
 xen/arch/riscv/include/asm/cpufeature.h  |  1 +
 xen/arch/riscv/include/asm/fixmap.h      |  2 +-
 xen/arch/riscv/include/asm/mm-types.h    |  8 ++++++++
 xen/arch/riscv/include/asm/page.h        | 23 ++++++++++++++++++++++-
 xen/arch/riscv/pt.c                      | 20 +++++++++++---------
 9 files changed, 54 insertions(+), 11 deletions(-)
 create mode 100644 xen/arch/riscv/include/asm/mm-types.h

diff --git a/automation/scripts/qemu-smoke-riscv64.sh b/automation/scripts/qemu-smoke-riscv64.sh
index b2e112c942..25f9e4190e 100755
--- a/automation/scripts/qemu-smoke-riscv64.sh
+++ b/automation/scripts/qemu-smoke-riscv64.sh
@@ -7,6 +7,7 @@ rm -f smoke.serial
 
 export TEST_CMD="qemu-system-riscv64 \
     -M virt,aia=aplic-imsic \
+    -cpu rv64,svpbmt=on \
     -smp 1 \
     -nographic \
     -m 2g \
diff --git a/docs/misc/riscv/booting.txt b/docs/misc/riscv/booting.txt
index 3a8474a27d..e100bde575 100644
--- a/docs/misc/riscv/booting.txt
+++ b/docs/misc/riscv/booting.txt
@@ -18,3 +18,7 @@ Xen is run:
 - Zihintpause:
   On a system that doesn't have this extension, cpu_relax() should be
   implemented properly.
+- SVPBMT is mandatory to enable changing the memory attributes of a page.
+  For platforms that do not support SVPBMT, it is necessary to introduce a
+  similar mechanism as described in:
+  https://lore.kernel.org/all/20241102000843.1301099-1-samuel.holland@sifive.com/
diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index d882e0a059..62c5b7ba34 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -10,11 +10,15 @@ config RISCV
 config RISCV_64
 	def_bool y
 	select 64BIT
+	select HAS_SVPBMT
 
 config ARCH_DEFCONFIG
 	string
 	default "arch/riscv/configs/tiny64_defconfig"
 
+config HAS_SVPBMT
+	bool
+
 menu "Architecture Features"
 
 source "arch/Kconfig"
diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
index 3246a03624..b7d5ec6580 100644
--- a/xen/arch/riscv/cpufeature.c
+++ b/xen/arch/riscv/cpufeature.c
@@ -137,6 +137,7 @@ const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
     RISCV_ISA_EXT_DATA(zbs),
     RISCV_ISA_EXT_DATA(smaia),
     RISCV_ISA_EXT_DATA(ssaia),
+    RISCV_ISA_EXT_DATA(svpbmt),
 };
 
 static const struct riscv_isa_ext_data __initconst required_extensions[] = {
@@ -151,6 +152,7 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = {
     RISCV_ISA_EXT_DATA(zifencei),
     RISCV_ISA_EXT_DATA(zihintpause),
     RISCV_ISA_EXT_DATA(zbb),
+    RISCV_ISA_EXT_DATA(svpbmt),
 };
 
 static bool __init is_lowercase_extension_name(const char *str)
diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h
index 1015b6ee44..768b84b769 100644
--- a/xen/arch/riscv/include/asm/cpufeature.h
+++ b/xen/arch/riscv/include/asm/cpufeature.h
@@ -37,6 +37,7 @@ enum riscv_isa_ext_id {
     RISCV_ISA_EXT_zbs,
     RISCV_ISA_EXT_smaia,
     RISCV_ISA_EXT_ssaia,
+    RISCV_ISA_EXT_svpbmt,
     RISCV_ISA_EXT_MAX
 };
 
diff --git a/xen/arch/riscv/include/asm/fixmap.h b/xen/arch/riscv/include/asm/fixmap.h
index e399a15f53..5990c964aa 100644
--- a/xen/arch/riscv/include/asm/fixmap.h
+++ b/xen/arch/riscv/include/asm/fixmap.h
@@ -33,7 +33,7 @@
 extern pte_t xen_fixmap[];
 
 /* Map a page in a fixmap entry */
-void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags);
+void set_fixmap(unsigned int map, mfn_t mfn, pte_attr_t flags);
 /* Remove a mapping from a fixmap entry */
 void clear_fixmap(unsigned int map);
 
diff --git a/xen/arch/riscv/include/asm/mm-types.h b/xen/arch/riscv/include/asm/mm-types.h
new file mode 100644
index 0000000000..fa512064b8
--- /dev/null
+++ b/xen/arch/riscv/include/asm/mm-types.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef ASM_RISCV_MM_TYPES_H
+#define ASM_RISCV_MM_TYPES_H
+
+typedef unsigned long pte_attr_t;
+
+#endif /* ASM_RISCV_MM_TYPES_H */
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index bf8988f657..81b91b63d8 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -37,6 +37,16 @@
 #define PTE_ACCESSED                BIT(6, UL)
 #define PTE_DIRTY                   BIT(7, UL)
 #define PTE_RSW                     (BIT(8, UL) | BIT(9, UL))
+/*
+ * [62:61] Svpbmt Memory Type definitions:
+ *
+ *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
+ *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
+ *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
+ *  11 - Rsvd   Reserved for future standard use
+ */
+#define PTE_PMBT_NOCACHE            BIT(61, UL)
+#define PTE_PMBT_IO                 BIT(62, UL)
 
 #define PTE_LEAF_DEFAULT            (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
 #define PTE_TABLE                   (PTE_VALID)
@@ -46,6 +56,15 @@
 #define PAGE_HYPERVISOR_RX          (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE)
 
 #define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
+/*
+ * PAGE_HYPERVISOR_NOCACHE is used for ioremap().
+ *
+ * Both PTE_PMBT_IO and PTE_PMBT_NOCACHE are non-cacheable, but the difference
+ * is that IO is non-idempotent and strongly ordered, which makes it a good
+ * candidate for mapping IOMEM.
+ */
+#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PMBT_IO)
+#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PMBT_NOCACHE)
 
 /*
  * The PTE format does not contain the following bits within itself;
@@ -58,6 +77,8 @@
 
 #define PTE_ACCESS_MASK (PTE_READABLE | PTE_WRITABLE | PTE_EXECUTABLE)
 
+#define PTE_PBMT_MASK   (PTE_PMBT_NOCACHE | PTE_PMBT_IO)
+
 /* Calculate the offsets into the pagetables for a given VA */
 #define pt_linear_offset(lvl, va)   ((va) >> XEN_PT_LEVEL_SHIFT(lvl))
 
@@ -202,7 +223,7 @@ static inline pte_t read_pte(const pte_t *p)
     return read_atomic(p);
 }
 
-static inline pte_t pte_from_mfn(mfn_t mfn, unsigned int flags)
+static inline pte_t pte_from_mfn(mfn_t mfn, pte_attr_t flags)
 {
     unsigned long pte = (mfn_x(mfn) << PTE_PPN_SHIFT) | flags;
     return (pte_t){ .pte = pte };
diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c
index 918b1b91ab..82c8c73c3e 100644
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -25,7 +25,7 @@ static inline mfn_t get_root_page(void)
  * See the comment about the possible combination of (mfn, flags) in
  * the comment above pt_update().
  */
-static bool pt_check_entry(pte_t entry, mfn_t mfn, unsigned int flags)
+static bool pt_check_entry(pte_t entry, mfn_t mfn, pte_attr_t flags)
 {
     /* Sanity check when modifying an entry. */
     if ( (flags & PTE_VALID) && mfn_eq(mfn, INVALID_MFN) )
@@ -260,7 +260,7 @@ pte_t pt_walk(vaddr_t va, unsigned int *pte_level)
  */
 static int pt_update_entry(mfn_t root, vaddr_t virt,
                            mfn_t mfn, unsigned int *target,
-                           unsigned int flags)
+                           pte_attr_t flags)
 {
     int rc;
     /*
@@ -328,17 +328,19 @@ static int pt_update_entry(mfn_t root, vaddr_t virt,
         pte.pte = 0;
     else
     {
+        const pte_attr_t attrs = PTE_ACCESS_MASK | PTE_PBMT_MASK;
+
         /* We are inserting a mapping => Create new pte. */
         if ( !mfn_eq(mfn, INVALID_MFN) )
             pte = pte_from_mfn(mfn, PTE_VALID);
-        else /* We are updating the permission => Copy the current pte. */
+        else /* We are updating the attributes => Copy the current pte. */
         {
             pte = *ptep;
-            pte.pte &= ~PTE_ACCESS_MASK;
+            pte.pte &= ~attrs;
         }
 
-        /* update permission according to the flags */
-        pte.pte |= (flags & PTE_ACCESS_MASK) | PTE_ACCESSED | PTE_DIRTY;
+        /* Update attributes of PTE according to the flags. */
+        pte.pte |= (flags & attrs) | PTE_ACCESSED | PTE_DIRTY;
     }
 
     write_pte(ptep, pte);
@@ -353,7 +355,7 @@ static int pt_update_entry(mfn_t root, vaddr_t virt,
 
 /* Return the level where mapping should be done */
 static int pt_mapping_level(unsigned long vfn, mfn_t mfn, unsigned long nr,
-                            unsigned int flags)
+                            pte_attr_t flags)
 {
     unsigned int level = 0;
     unsigned long mask;
@@ -407,7 +409,7 @@ static DEFINE_SPINLOCK(pt_lock);
  * inserting will be done.
  */
 static int pt_update(vaddr_t virt, mfn_t mfn,
-                     unsigned long nr_mfns, unsigned int flags)
+                     unsigned long nr_mfns, pte_attr_t flags)
 {
     int rc = 0;
     unsigned long vfn = PFN_DOWN(virt);
@@ -535,7 +537,7 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 }
 
 /* Map a 4k page in a fixmap entry */
-void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags)
+void set_fixmap(unsigned int map, mfn_t mfn, pte_attr_t flags)
 {
     if ( map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL) != 0 )
         BUG();
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992140.1375946 (Exim 4.92)
	(envelope-from )
	id 1uHlvJ-0005DC-HR; Wed, 21 May 2025 16:04:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992140.1375946; Wed, 21 May 2025 16:04: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 1uHlvJ-0005D0-DZ; Wed, 21 May 2025 16:04:05 +0000
Received: by outflank-mailman (input) for mailman id 992140;
 Wed, 21 May 2025 16:04:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvH-0004XB-On
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:03 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 36e88ac4-365d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:04:03 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-601d66f8cafso5698071a12.3
 for ; Wed, 21 May 2025 09:04:03 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:04: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" 
X-Inumbo-ID: 36e88ac4-365d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843442; x=1748448242; 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;
        bh=GTDxJdlWqyBuUYAssfRiBPJ9qN2ELiVYcf2RQUhFW1U=;
        b=cjcrTPPoqTY+uKyaNYt9GvbRuj4cwz0GKWt0P9Fzdjgo2N5ZNbWF2mcdfCdq8WbxbP
         YxnfjKSdFS8HeW1PRX5gqGHNHGPgVfPcHGA2v7pU7tvF/3HQ2rQgLIGUdf0l2/ySUcy3
         kN43AkjuiwsNmPXMSzLnPGEitJIf1WED8k0oAdcwgiqX9RI5FJ7SvqZOf0ZaRzBFGipZ
         u2r3MSiZ+FGfoyHaG0FlXFyVUQyAN8mfl0D4f9EaOzcx10ko0NED3hgRbKYMWRWtMWMu
         JptW6lgXxD77khgnQ6jq/XjlPOHJj0Oq6rAFr34FfaYRl/qKB9+bSLSbOE8xUFLNv87Y
         Lx4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843442; x=1748448242;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GTDxJdlWqyBuUYAssfRiBPJ9qN2ELiVYcf2RQUhFW1U=;
        b=MhVAktMsTYAWJD48VdCDuh7h6KnBkupMEWMl1OLUliq4R2hOJC2NajIbSxLuHG78yj
         5ZfZtv/c7WT8axmyhoPxZ3MaMBeQdZODphC1ydP+awtNg7GweDrFwfpKYSuhPuMBIWTF
         cIGpUVTitlmAv2+nqoqorVHqohdL97D9leOX+Re09j8VAS79TnwOEio1PpP7ioKuR+L8
         CzmDaxDHcplkNXCgsUZU1avW+RLqSW6Uf2thnfyhspFXr+cRVSPvjGWCD+2nRGVH3zAk
         rLlriJAO72ywOqyTyfUgOR4ep2CpvP8j260wKLb3HunZZsoMEgwLoi+tj3NeBZ4V2kJp
         QwVg==
X-Gm-Message-State: AOJu0YxSlZIAuBUALfi5kS+TWpSufOENR9+uFH+pyeMYhAAq+LVffBiz
	0WA7AURUrh01vlW+15Vv7NjiVDFciG/LCqKMI9gTVlwAAyRnja8BfMcNS/rIzA==
X-Gm-Gg: ASbGncvGKKXbq7SGWaWqzAC/zqGkgPGlPI+Ar4fjzdcw1FHlbp8fqHg9NCo3Pb2wCoX
	cTcNxPoZOmq+zrM5YflX8J7Ifr5sWhgGdw8DNXIzWT+pfN2qF1ECUppmNZKJUVV2CnXheouHZun
	5uLRvwP2n5uIYoF1an4HO5z/1uWXfc1d6ixKik+X7Au8v9jfexVyOTX3tlJUcLQK1f7DY1guMX0
	H1DRAjQiU42JiYAHnKH6900og6p4lQCb4Bpi5fT/vD0krpGhruLPauIFQ2GLz8rLUL6mNBqysyI
	Ln2o05QEM0FMjs5+ouiRIF5xpwai6N31Inha0KTcH0oXiwzK8JEAXy8EzfWvCX0lI76vCtdDfDn
	stiaW4njR0jrKFpGk9g==
X-Google-Smtp-Source: AGHT+IHvMVemtY/rVmjCbwswGEM7HqhP6r5qb6LnqJDAtjjjAajYDr3TUYO5Abv8PQ6/cuQUXCR7zg==
X-Received: by 2002:a05:6402:4304:b0:602:1d01:2869 with SMTP id 4fb4d7f45d1cf-6021d012c1cmr5908930a12.28.1747843441958;
        Wed, 21 May 2025 09:04:01 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 03/14] xen/riscv: add ioremap_*() variants using ioremap_attr()
Date: Wed, 21 May 2025 18:03:43 +0200
Message-ID: <2bdbb98adf5246cd1a10e1575b8bf0aa2bdb5f6d.1747843009.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce ioremap_attr() as a shared helper to implement architecture-specific
ioremap variants:
- ioremap_cache()
- ioremap_wc()

These functions use __vmap() internally and apply appropriate memory attributes
for RISC-V.

These functions are implemned not as static inline function or macros as it will
require to include asm/page.h into asm/io.h what will lead to compilation
issue.

Also, remove the unused ioremap_wt() macro from asm/io.h, as write-through
mappings are not expected to be used on RISC-V.

Signed-off-by: Oleksii Kurochko 
---
Changes in v3:
 - Drop ioremap_nocache() as ioremap() duplicates functionality of
   ioremap_nocache().
 - Add __iomem to defintion of ioremap(), ioremap_attr().
 - Rename start to pa for all ioremap*() functions.
 - Update the commit message ioremap_nocache().
---
Changes in v2:
 - Update the commit subject + message.  
 - move out Svpbmt changes to separate patch.
 - Drop #ifdef SVPBMT for ioremap().
 - Redefine ioremap_* in io.h.
 - Introduce ioremap_attr().
---
 xen/arch/riscv/include/asm/io.h | 10 ++--------
 xen/arch/riscv/mm.c             | 30 ++++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/xen/arch/riscv/include/asm/io.h b/xen/arch/riscv/include/asm/io.h
index 8bab4ffa03..9aeafd6b3b 100644
--- a/xen/arch/riscv/include/asm/io.h
+++ b/xen/arch/riscv/include/asm/io.h
@@ -41,14 +41,8 @@
 #include 
 #include 
 
-/*
- * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
- * change the properties of memory regions.  This should be fixed by the
- * upcoming platform spec.
- */
-#define ioremap_nocache(addr, size) ioremap(addr, size)
-#define ioremap_wc(addr, size) ioremap(addr, size)
-#define ioremap_wt(addr, size) ioremap(addr, size)
+void __iomem *ioremap_cache(paddr_t pa, size_t len);
+void __iomem *ioremap_wc(paddr_t pa, size_t len);
 
 /* Generic IO read/write.  These perform native-endian accesses. */
 static inline void __raw_writeb(uint8_t val, volatile void __iomem *addr)
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index d3ece9f132..4047d67c0e 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -583,3 +584,32 @@ void *__init arch_vmap_virt_end(void)
 {
     return (void *)(VMAP_VIRT_START + VMAP_VIRT_SIZE);
 }
+
+static void __iomem *ioremap_attr(paddr_t pa, size_t len,
+                                  pte_attr_t attributes)
+{
+    mfn_t mfn = _mfn(PFN_DOWN(pa));
+    unsigned int offs = pa & (PAGE_SIZE - 1);
+    unsigned int nr = PFN_UP(offs + len);
+    void *ptr = __vmap(&mfn, nr, 1, 1, attributes, VMAP_DEFAULT);
+
+    if ( ptr == NULL )
+        return NULL;
+
+    return ptr + offs;
+}
+
+void __iomem *ioremap_cache(paddr_t pa, size_t len)
+{
+    return ioremap_attr(pa, len, PAGE_HYPERVISOR);
+}
+
+void __iomem *ioremap_wc(paddr_t pa, size_t len)
+{
+    return ioremap_attr(pa, len, PAGE_HYPERVISOR_WC);
+}
+
+void __iomem *ioremap(paddr_t pa, size_t len)
+{
+    return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992141.1375953 (Exim 4.92)
	(envelope-from )
	id 1uHlvK-0005KM-4h; Wed, 21 May 2025 16:04:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992141.1375953; Wed, 21 May 2025 16:04: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 1uHlvJ-0005JY-TX; Wed, 21 May 2025 16:04:05 +0000
Received: by outflank-mailman (input) for mailman id 992141;
 Wed, 21 May 2025 16:04:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvI-0004XB-UM
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:04 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 37b46271-365d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:04:04 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-601d10de7e1so5959327a12.1
 for ; Wed, 21 May 2025 09:04:04 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:04: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" 
X-Inumbo-ID: 37b46271-365d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843443; x=1748448243; 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;
        bh=0/elDcf0J+uEdYg0IcO9C9ITYyw5kGwji+p9HGpFOSE=;
        b=NCxNBcm79HEVCHuevHxMMiV7UoJqRfFEzLFCAM65zywkWPEMy0WzYQ48tdUspAGjlh
         lRpDq7fPNEmPPAB1GLiR7bQjiXDP2N3vbrjovyNjWpIpkLGx6oISQ2Nd0y+klAgTFjHP
         /q6cmLpWbrR+qLNvUU29uCsR5Vt0/lSXyZ1K106pRvqfnZb3R3URIZF2+RuTn/VQ6jqI
         79o3WVUWTkV9a+Y1nOq3zeWOwbtzZfxkVEVt2lAiML1JwSaufJ3fuWtp1O3oa+fYyTXa
         quDBHIw0WsJY+9gSkOP0P6cQsSTTbqSF00bsN+FnJKtBlC1gpVz+pwUOw1P2PFcG/tnj
         fslQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843443; x=1748448243;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=0/elDcf0J+uEdYg0IcO9C9ITYyw5kGwji+p9HGpFOSE=;
        b=bA6e8k0I0cD2st0dUT7ggJDLzw/7WjMZ7S/5BqftAMmUZvTOwUpSOdUmoikARWoF3l
         RDlkCGCxgb62tm/fL5FERJX1nixI89JGb8i/bRgT6gxhEO6jiekuVGwA34PiTqSCPkby
         TmrTAx/BHlMpOj4maQLVjE5mbT4LfxCin5ff++94RT/skj4DwmLb6fbWcCpXTwPslWAp
         OuZKUC0o/Da5vNAC9KtMpk45FoGJvH8F6wlGkZg3/9vc2+LQRbSyormRXNVrm/MIg3de
         HEWs6F/prgdwMuEyqEtupCP6njuKwmk3tdSMtixGxpYOhawM1m2EKT0p488BXn2Y4WOe
         MJ8A==
X-Gm-Message-State: AOJu0YxPjNZtveQ9tNdy6iNjB3Wuopxx/+ExNEgecJBsrZirxjkW1m5N
	Qfa5PBJwkXCYHmuHGZ9J31+Ngl18Few1WY63o1NcaloTHGNeltJ9uD3oi9niDQ==
X-Gm-Gg: ASbGncsoprYmWUm4fqwX2L8tUsbWwHQwQvgHafIFpgoWvyBbWp2ykfL8oWNE8wpo9h0
	KLjlaCo7slsncFXmFQRf36j9+YMpSGu8DighxSFS1UZmom+DT1/fEa2yjOkKHetLZERsGMgIjZD
	+JUXQ3CuGDMlJeV+/NXIT39RW6+VJnbYJJK+wCXwwtxb83LKM202ipvJzl5i7p0mukhtSpOJFnB
	lPrYvvnacLJ6bimyG+SHK2FEgGZlDkN8OS5JvX73aokj5YXO+OdVUWC+WI8m2tU5Wl4B/haY5h7
	pe8JFMsIYAwj6ysi5cABfx+qvQ6TIBceu5GRGs47z9lk9HbHr2EarrfMzlGj9quPFwEuODSoz8i
	lykXSATMOevz8exUnqg==
X-Google-Smtp-Source: AGHT+IEa+JUzcbczAQq8o2/fg/s1PT8cuwXsa9rgrAfOnPixs0ymYOgRRJ6fCt3JnFSA4qtF1tmLyw==
X-Received: by 2002:a05:6402:2786:b0:602:29e0:5e05 with SMTP id 4fb4d7f45d1cf-60229e0615dmr3984646a12.14.1747843442984;
        Wed, 21 May 2025 09:04:02 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 04/14] xen/riscv: introduce init_IRQ()
Date: Wed, 21 May 2025 18:03:44 +0200
Message-ID: <3f86f284ebccff9de877844f33c4588ac5631906.1747843009.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement init_IRQ() to initalize various IRQs.

Currently, this function initializes the irq_desc[] array,
which stores IRQ descriptors containing various information
about each IRQ, such as the type of hardware handling, whether
the IRQ is disabled, etc.
The initialization is basic at this point and includes setting
IRQ_TYPE_INVALID as the IRQ type, assigning the IRQ number ( which
is just a consequent index of irq_desc[] array ) to
desc->irq.

Additionally, the function init_irq_data() is introduced to
initialize the IRQ descriptors for all IRQs in the system.

Reuse defines of IRQ_TYPE_* from asm-generic/irq-dt.h.

Signed-off-by: Oleksii Kurochko 
---
 - Add an explanatory comment about NR_IRQS definitions.
 - Init desc->irq and desc->action before call of init_one_irq_desc().
 - Drop "desc->action = NULL" as irq_desc[] is zero-initialized.
 - Update the commit message: drop mention of NULLing of desc->action.
 - Drop year in Copyright.
---
Changes in v2:
 - Move an introduction of IRQ_TYPE_* defines to the separate patch.
 - Reuse asm-generic/irq-dt.h.
 - Use 'unsigned int' for local irq variable inside init_irq_data().
---
 xen/arch/riscv/Makefile             |  1 +
 xen/arch/riscv/include/asm/Makefile |  1 +
 xen/arch/riscv/include/asm/irq.h    | 15 ++++++++++
 xen/arch/riscv/irq.c                | 45 +++++++++++++++++++++++++++++
 xen/arch/riscv/setup.c              |  3 ++
 xen/arch/riscv/stubs.c              |  5 ----
 6 files changed, 65 insertions(+), 5 deletions(-)
 create mode 100644 xen/arch/riscv/irq.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index f42cf3dfa6..a1c145c506 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -3,6 +3,7 @@ obj-y += cpufeature.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
 obj-y += intc.o
+obj-y += irq.o
 obj-y += mm.o
 obj-y += pt.o
 obj-$(CONFIG_RISCV_64) += riscv64/
diff --git a/xen/arch/riscv/include/asm/Makefile b/xen/arch/riscv/include/asm/Makefile
index c989a7f89b..bfdf186c68 100644
--- a/xen/arch/riscv/include/asm/Makefile
+++ b/xen/arch/riscv/include/asm/Makefile
@@ -5,6 +5,7 @@ generic-y += div64.h
 generic-y += hardirq.h
 generic-y += hypercall.h
 generic-y += iocap.h
+generic-y += irq-dt.h
 generic-y += paging.h
 generic-y += percpu.h
 generic-y += perfc_defn.h
diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 2a48da2651..ea555afd1a 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -3,6 +3,19 @@
 #define ASM__RISCV__IRQ_H
 
 #include 
+#include 
+
+#include 
+
+/*
+ * According to the AIA spec:
+ *   The maximum number of interrupt sources an APLIC may support is 1023.
+ *
+ * The same is true for PLIC.
+ *
+ * Interrupt Source 0 is reserved and shall never generate an interrupt.
+ */
+#define NR_IRQS 1024
 
 /* TODO */
 #define nr_irqs 0U
@@ -25,6 +38,8 @@ static inline void arch_move_irqs(struct vcpu *v)
     BUG_ON("unimplemented");
 }
 
+void init_IRQ(void);
+
 #endif /* ASM__RISCV__IRQ_H */
 
 /*
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
new file mode 100644
index 0000000000..b5ae7a114b
--- /dev/null
+++ b/xen/arch/riscv/irq.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+/*
+ * RISC-V Interrupt support
+ *
+ * Copyright (c) Vates
+ */
+
+#include 
+#include 
+#include 
+
+static irq_desc_t irq_desc[NR_IRQS];
+
+int arch_init_one_irq_desc(struct irq_desc *desc)
+{
+    desc->arch.type = IRQ_TYPE_INVALID;
+
+    return 0;
+}
+
+static int __init init_irq_data(void)
+{
+    unsigned int irq;
+
+    for ( irq = 0; irq < NR_IRQS; irq++ )
+    {
+        struct irq_desc *desc = irq_to_desc(irq);
+        int rc;
+
+        desc->irq = irq;
+
+        rc = init_one_irq_desc(desc);
+        if ( rc )
+            return rc;
+    }
+
+    return 0;
+}
+
+void __init init_IRQ(void)
+{
+    if ( init_irq_data() < 0 )
+        panic("initialization of IRQ data failed\n");
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index a9c0c61fb6..8bcd19218d 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -125,6 +126,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
         panic("Booting using ACPI isn't supported\n");
     }
 
+    init_IRQ();
+
     riscv_fill_hwcap();
 
     preinit_xen_time();
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index fdcf91054e..e396b67cd3 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -107,11 +107,6 @@ void irq_ack_none(struct irq_desc *desc)
     BUG_ON("unimplemented");
 }
 
-int arch_init_one_irq_desc(struct irq_desc *desc)
-{
-    BUG_ON("unimplemented");
-}
-
 void smp_send_state_dump(unsigned int cpu)
 {
     BUG_ON("unimplemented");
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992142.1375965 (Exim 4.92)
	(envelope-from )
	id 1uHlvL-0005gq-Ai; Wed, 21 May 2025 16:04:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992142.1375965; Wed, 21 May 2025 16: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 1uHlvL-0005fo-7A; Wed, 21 May 2025 16:04:07 +0000
Received: by outflank-mailman (input) for mailman id 992142;
 Wed, 21 May 2025 16:04:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvJ-0004XB-LD
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:05 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 38205288-365d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:04:05 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-601956fa3beso7489696a12.0
 for ; Wed, 21 May 2025 09:04:05 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:04: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" 
X-Inumbo-ID: 38205288-365d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843444; x=1748448244; 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;
        bh=MuKFAgwAzdWX+jRW22HkNFtK9R6Dh6rQ/ItEXnnpjQ4=;
        b=WSoFoG0V5iWtBFxt1xF0zUVz9exvvJ7jtpoJ0/Y+ZjxvjQkaC2fNYdcSJvXZiqJY3I
         LOyQ8yzCNGt/AHOHkqNu5csmTy6Jq65ooDMhsxTXn0AJ0m9Hej7nmRfigIcMrjm8nwKJ
         0ACh0u+wReNAU/OESz96NZnRLfRmrYjcA0rnsQijn45xz+Xb5/0XNUks5brZaLMVNvhz
         l83LTYsB8eaoow4vtQ3PbT5C/jmI9IobjMdA0r7TwIAH99a8rcNRR3WVyEGRYOw7a4U6
         WBFp/f1i0zRAJoFhBFvZIjQzyp6a9Q1wNG8cn19BsMaZy6IpggJh6GKH+p71Pahteabr
         oLUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843444; x=1748448244;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=MuKFAgwAzdWX+jRW22HkNFtK9R6Dh6rQ/ItEXnnpjQ4=;
        b=MWPmBpDt2vwVj+qnJ4gp1/r6DTGVU/NRQClQADFn1biMUdq3dU/BlUmcRv+K/wQvg8
         Hi4KJnuEzAsuGVmD3QJlz5UCJtpeFzTuT/Z29sFSAos+9S/WWX6MzrSs8axzcBwEyfBr
         RQRBig1OGXDTUVuQfqEQgK74HNUyJaTJb6oT8gGd8/6XWk3Q+597vbJnaZC5BZI9VIYP
         x1Jty5UkEytvRnESWgp+w58tmAuXQ/LL7YuePj/A4S6VZcyGI2N2BkCjuWGIPA7qVNVp
         Yt+ri+Vg1Xsr+5bmmBLEcDCFY5sfvanAUQO0GLdsp1Iq/fNLlNb52NEaxN5i0+sTGca6
         PueA==
X-Gm-Message-State: AOJu0Yz9zKtvjMZMi6yAjTModplXdQLkRYWwdCe81nSawG4nlHRjWnjC
	st0sAPsAqANp/60PwRX7uhJ/MTEqOOKZa0al9Z/QNlf8ChDyTp0m5cF8SLrsaQ==
X-Gm-Gg: ASbGncvdA3dm1Exi/IBGSjXEuWV0aijcfm1yqb913uRM7fZtqHSiKhv3sVu9Z5V+50A
	CgQp+U8quvidtLJl9e8wXffbB+OBDFc0Aa+yMIIXDaasEN3uBtTVr7BSwuzPCxRRCbqFH0lXqqN
	JyV72ljloV7b2w3ZaNN1jEPgaH3SU9fM5I6caA49p1EGkMSIgyhOe+zTms70KOHXTjzDtHW3ltz
	a0P9s13Yok96Opggg3JpympksLNJhhT/2sW4z++3R4ARJDTfzpHt+YMvSCe0aG3fguKVVQC52se
	i5W7DdI7l5PcKAe4z8P21Rop3myfZe8pBVL+OfpuXl+X0tIv7E7R/u0JleY35InHhRFUftdUEaz
	ejdlxXq40kZ/KqxHaaw==
X-Google-Smtp-Source: AGHT+IHMiUE1RNqkd7CFA0gkM4DTS7mv6rwNoXKENbduXzPAJdFGKEhEHzlWMu7Blf5NHSFiWG9jtg==
X-Received: by 2002:aa7:d28a:0:b0:601:31e6:697f with SMTP id 4fb4d7f45d1cf-60131e66b16mr14765902a12.26.1747843444003;
        Wed, 21 May 2025 09:04:04 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v3 05/14] xen/riscv: introduce platform_get_irq()
Date: Wed, 21 May 2025 18:03:45 +0200
Message-ID: <1729279a0ab39e2a2f09e475c2eb48fefd4aef54.1747843009.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

platform_get_irq() recieves information about device's irq ( type
and irq number ) from device tree node and using this information
update irq descriptor in irq_desc[] array.

Introduce dt_irq_xlate and initialize with aplic_irq_xlate() as
it is used by dt_device_get_irq() which is called by
platform_get_irq().

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V3:
 - Drop parentheses in return inside irq_validate_new_type().
 - Add a check in platform_get_irq() that dt_irq.irq is less
   then NR_IRQS.
   Also, add BUILD_BUG_ON(NR_IRQS > INT_MAX).
---
Changes in V2:
 - Add cf_check for aplic_irq_xlate().
 - Ident label in irq_set_type().
 - Return proper -E... values for platform_get_irq().
---
 xen/arch/riscv/aplic.c           | 20 ++++++++++++++
 xen/arch/riscv/include/asm/irq.h |  3 ++
 xen/arch/riscv/irq.c             | 47 ++++++++++++++++++++++++++++++++
 3 files changed, 70 insertions(+)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index caba8f8993..10ae81f7ac 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -21,6 +22,23 @@ static struct intc_info __ro_after_init aplic_info = {
     .hw_version = INTC_APLIC,
 };
 
+static int cf_check aplic_irq_xlate(const uint32_t *intspec,
+                                    unsigned int intsize,
+                                    unsigned int *out_hwirq,
+                                    unsigned int *out_type)
+{
+    if ( intsize < 2 )
+        return -EINVAL;
+
+    /* Mapping 1:1 */
+    *out_hwirq = intspec[0];
+
+    if ( out_type )
+        *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
+
+    return 0;
+}
+
 static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 {
     if ( aplic_info.node )
@@ -35,6 +53,8 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     aplic_info.node = node;
 
+    dt_irq_xlate = aplic_irq_xlate;
+
     return 0;
 }
 
diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index ea555afd1a..84c3c2904d 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -38,6 +38,9 @@ static inline void arch_move_irqs(struct vcpu *v)
     BUG_ON("unimplemented");
 }
 
+struct dt_device_node;
+int platform_get_irq(const struct dt_device_node *device, int index);
+
 void init_IRQ(void);
 
 #endif /* ASM__RISCV__IRQ_H */
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index b5ae7a114b..669ef3ae9e 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -7,11 +7,58 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 
 static irq_desc_t irq_desc[NR_IRQS];
 
+static bool irq_validate_new_type(unsigned int curr, unsigned int new)
+{
+    return curr == IRQ_TYPE_INVALID || curr == new;
+}
+
+static int irq_set_type(unsigned int irq, unsigned int type)
+{
+    unsigned long flags;
+    struct irq_desc *desc = irq_to_desc(irq);
+    int ret = -EBUSY;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    if ( !irq_validate_new_type(desc->arch.type, type) )
+        goto err;
+
+    desc->arch.type = type;
+
+    ret = 0;
+
+ err:
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    return ret;
+}
+
+int platform_get_irq(const struct dt_device_node *device, int index)
+{
+    struct dt_irq dt_irq;
+    int ret;
+
+    if ( (ret = dt_device_get_irq(device, index, &dt_irq)) != 0 )
+        return ret;
+
+    BUILD_BUG_ON(NR_IRQS > INT_MAX);
+
+    if ( dt_irq.irq >= NR_IRQS )
+        panic("irq%d is bigger then NR_IRQS(%d)\n", dt_irq.irq, NR_IRQS);
+
+    if ( (ret = irq_set_type(dt_irq.irq, dt_irq.type)) != 0 )
+        return ret;
+
+    return dt_irq.irq;
+}
+
 int arch_init_one_irq_desc(struct irq_desc *desc)
 {
     desc->arch.type = IRQ_TYPE_INVALID;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992143.1375977 (Exim 4.92)
	(envelope-from )
	id 1uHlvN-00062S-Lz; Wed, 21 May 2025 16:04:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992143.1375977; Wed, 21 May 2025 16:04:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHlvN-00061w-HL; Wed, 21 May 2025 16:04:09 +0000
Received: by outflank-mailman (input) for mailman id 992143;
 Wed, 21 May 2025 16:04:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvL-0004XB-BE
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:07 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3945bd89-365d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:04:07 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-60119cd50b6so8915099a12.0
 for ; Wed, 21 May 2025 09:04:06 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:04:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3945bd89-365d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843446; x=1748448246; 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;
        bh=pXa7CGMEIFOZ1vN2aNUNz1YqzXIyy5P1kJ1VTA9ahL8=;
        b=Ql/U+Y2gv8TuEyJvD55drooo0n+lpbzEJgvHP1dXnRe7W6f3TE6qa1GYFwtqAKn2j9
         jTqyF7te+xrKt0O1hi60DwUb8H9SCFBSeM+wAH4SRnMMwnPNvcH71MH3ZNh4RjQ8PXzu
         ctNI5hmNHIY/esNB+a9Us1xPhRtI9PUqF1cm6ec3IG6KE2wohykGzw4MM9dL/wD0hh2X
         k6gL0RXfM2Z55lCkjH0yGSFL9oboV10OeCVnVWvP+ac+xfdfWXJ8vmTj3QvbaZgVlzyR
         g/x8J+FK/Y+qfxYQKvIJOvkT1n+8OBtGOd9q8t0zUGIt7SkIRyqXPdB4exPdcWnyNSX1
         8Kbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843446; x=1748448246;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=pXa7CGMEIFOZ1vN2aNUNz1YqzXIyy5P1kJ1VTA9ahL8=;
        b=Wt6VUCXLEvDfRB9YhoE5WyP08+PHF8E4+Zrhpb9AeqMASvEfy2f1vUsOU8ir4q2OwA
         vUaPOeSTze47fEk+zq2v4WsKW8b71HL055aUF5VNA2/IIGTHBuwIjiCVkr/H5O0IvQXv
         2F0sbnIJ1RIlnq5QgRsDsWi9co3wnwIBItStZUrVVu3CKEPNq6+KoyF8xrY3xDajLvH1
         z9phmflz5dz70FzbDxiZbaNg+vRRADQyHHpdAIso8mW83oRHMK2OkeDZkJfQji1221eH
         SzJ+IdBBQE46SRMkPf0GLpatVig2jFNu7ramTZZUWvSbSRmDos3+umkJHCpL2Uz2WFiV
         GWpg==
X-Gm-Message-State: AOJu0YzEaZW8bdPkK9GS7yWrTMaw9ly1vSItyJOO5J3LppIIdOdTC/0H
	5JEnDYCGP6iY67S+/UqLMOOGOlwuOrcR+xzqCClpQwZ5JUIRnBSk1gpiQNKPsQ==
X-Gm-Gg: ASbGnctxi2rLFD2OGlHwg7jigooZ9GAUycl1oz/CvEstCextyW73ncbt7DcKve2YvQQ
	fqol9xnaRljRJeg/iy5A9bCz6PqbqqDetyPwhlKbEJFn3nJs3sXyEnozJEeohOrYlN3NzoPzeHM
	aN1X07IiNV2FJAwjGdGg/AHnFFqfZsn31LuN6a1JxNIizxWQ6oASBtO7TOAK69J1i1mgfscSidS
	UNOzzxQv3ParXcVuZ5xdHahJ/yBugmx+8sL9vKTxpMFYrcCFPyfc7tSuSxqDhpjuvCISt+L9Cfn
	m9yP4CJgfT41BaXikVxXvIub2t8AL0L+SoH03IB5BUsiUJx5nClP5D9UdsafZOwYbxndkvGY/Di
	yxTkl10se+tem/gplBw==
X-Google-Smtp-Source: AGHT+IHS5fYBVXgwvUEWYYYGn4MRpmHoyuk/dgn1+GBR9YqJki3D+U4gCHeomjidZ5cP60SAXnS+tA==
X-Received: by 2002:a05:6402:35c3:b0:601:ff94:4a41 with SMTP id 4fb4d7f45d1cf-601ff944b43mr7172006a12.29.1747843446075;
        Wed, 21 May 2025 09:04:06 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v3 07/14] xen/riscv: introduce register_intc_ops() and intc_hw_ops.
Date: Wed, 21 May 2025 18:03:47 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce the intc_hw_operations structure to encapsulate interrupt
controller-specific data and operations. This structure includes:
- A pointer to interrupt controller information (`intc_info`)
- Callbacks to initialize the controller and set IRQ type/priority
- A reference to an interupt controller descriptor (`host_irq_type`)
- number of interrupt controller irqs.

Add function register_intc_ops() to mentioned above structure.

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V3:
 - Drop inclusion of xen/irq.h in asm/intc.h as forward declaration is enogh
   for types used in asm/intc.h.
 - Drop forward declaration for dt_device_node  and hw_irq_controller.
 - Declare intc_hw_ops as:
     const struct intc_hw_operations * __ro_after_init intc_hw_ops;
---
Changes in V2:
 - Declare host_irq_type member of intc_hw_operations as pointer-to-const.
 - Moved up forward declaration of irq_desc.
 - Use attribute __init for register_intc_ops().
 - Use attribute __ro_after_init for intc_hw_ops variable.
 - Update prototype of register_intc_ops() because of what mention in the
   previous point.
---
 xen/arch/riscv/include/asm/intc.h | 19 +++++++++++++++++++
 xen/arch/riscv/intc.c             |  9 +++++++++
 2 files changed, 28 insertions(+)

diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 52ba196d87..860737f965 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -12,11 +12,30 @@ enum intc_version {
     INTC_APLIC,
 };
 
+struct irq_desc;
+
 struct intc_info {
     enum intc_version hw_version;
     const struct dt_device_node *node;
 };
 
+struct intc_hw_operations {
+    /* Hold intc hw information */
+    const struct intc_info *info;
+    /* Initialize the intc and the boot CPU */
+    int (*init)(void);
+
+    /* hw_irq_controller to enable/disable/eoi host irq */
+    const struct hw_interrupt_type *host_irq_type;
+
+    /* Set IRQ type */
+    void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
+    /* Set IRQ priority */
+    void (*set_irq_priority)(struct irq_desc *desc, unsigned int priority);
+};
+
 void intc_preinit(void);
 
+void register_intc_ops(const struct intc_hw_operations *ops);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 4061a3c457..1ecd651bf3 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -5,6 +5,15 @@
 #include 
 #include 
 
+#include 
+
+static const struct intc_hw_operations *__ro_after_init intc_hw_ops;
+
+void __init register_intc_ops(const struct intc_hw_operations *ops)
+{
+    intc_hw_ops = ops;
+}
+
 void __init intc_preinit(void)
 {
     if ( acpi_disabled )
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992144.1375983 (Exim 4.92)
	(envelope-from )
	id 1uHlvO-00066D-2W; Wed, 21 May 2025 16:04:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992144.1375983; Wed, 21 May 2025 16:04: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 1uHlvN-00064B-QZ; Wed, 21 May 2025 16:04:09 +0000
Received: by outflank-mailman (input) for mailman id 992144;
 Wed, 21 May 2025 16:04:07 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvL-0004Wm-LB
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:07 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 38a72137-365d-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 18:04:06 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-6023cf146d3so1699237a12.3
 for ; Wed, 21 May 2025 09:04:06 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:04: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" 
X-Inumbo-ID: 38a72137-365d-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843445; x=1748448245; 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;
        bh=+Emu0YizvdQs9hLvUx13eJRnhsUQuOpHcWfHxBTfGWM=;
        b=db5PTxCfdZ19nUZSMnwF5G4ApBqDy1KWg/wW1UimOAi+U3daRR2LPW/wPJPcZCJs6R
         PBZXuiqIf1o+G9EFK8EBD+qKCouJBBJxgJskeGn4viIMc44TOhsqqlMBOZSV9VFDRdM6
         APuLdFvugHIMyVkXaLXY2cnf05LZVSnSPVILZV7RUA34Zh6fHmjFvh0mmBJAuaqLGGGm
         jJCgsSLdfvqSf4oNb0jkR0f8oewG6SxM5a/dxqe2pt0OHuvWeNnirk7LbLTlK/4wGVtI
         Nww8+M/XH/iIa6dF40sY55to3zDrq81ekATyfjLIMdHMRVlT0t9Orm5OCEF4tJnU6bGq
         O0sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843445; x=1748448245;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+Emu0YizvdQs9hLvUx13eJRnhsUQuOpHcWfHxBTfGWM=;
        b=NC4GEaLJUMgqTS9NMWli2K+Uh485mQIhmAI4hYMFD5MyYu7FAgDc+a7TUCJIILIGjr
         JU08wDw80KvxvXYV/+qhu3Aa6EqmCcM0OWraT/DIlBfaaux+RKqbRF0sZKil9mkpM/KR
         zRNbc431x3R0HHiHFwi9Mxk0ydz/+TzZjkAgCX/OzDv4fPHlR4wT07oBGpdqLQEZduxa
         09Zx29JYMmUQFXbFtiPWmv5LjLw0oW42yh/Wu6UQ76MKWEImo2ojEPMW5VFJHcmtJQLN
         ZKwfFimNoPh7crXkf8RcottxGlwPPkY2qR6RMQe5t4RdPzU5EKsdDN+umXNCxiEpnxxu
         Pa5A==
X-Gm-Message-State: AOJu0YxCjy5Ljw3lmZ9ftUr4uO9fFxJcQAXq5+m5P8UWfOXVcLdwx6nt
	r1KDInYdND2E7MHoYPF/y9IGkf2IMXzjJrJcpBewWuKCe90zutpxut4csFE9BQ==
X-Gm-Gg: ASbGncuPB1varSPc1xGZ2z9PjnYrvHb+H9C7wlwj7TrmymldAXweP8Lvi+FiUwDiZxJ
	7d0NqLbaQCKc9JzhPOFc4D+7ovKAzNXUtZok8O9W4pSU3TjZA37UXI2WdpSPxIkiiMKDidTOK08
	AsAmIbYBZaeKY+DfOedxeVmqOmAUBL73AV5Solaj2wnb1P1Mv+3Q8NJ/PImlbHkKEIQO1Gvk2+X
	bbf4ir2PztjufsP2W0blRURkYB/43V4ZxsMgE72t8UXTvzlVgw6obKQB+kuCXIrzX19gThHpCeo
	wwKawCm9t2FpITFBqXJ2f7guS46bXpfRDmuDTHyHKpxVWSAwCjW9l/wo65dQARB9/XCsSqgqKD4
	yoH4ndMrM1uUnaX1kbA==
X-Google-Smtp-Source: AGHT+IHHhP/LsIguqgN6zsA0Jjn44n4Zs/ziLAUhK8pM5XA6DUuNDWtu1jFotLN++2Ql7i2mBzKu3A==
X-Received: by 2002:a05:6402:280c:b0:600:1167:7329 with SMTP id 4fb4d7f45d1cf-6008a392452mr18561851a12.5.1747843445031;
        Wed, 21 May 2025 09:04:05 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 06/14] xen/riscv: dt_processor_hartid() implementation
Date: Wed, 21 May 2025 18:03:46 +0200
Message-ID: <5aec324c04c67ba88336244358542f3faa6726b2.1747843009.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implements dt_processor_hartid() to get the hart ID of the given
device tree node and do some checks if CPU is available and given device
tree node has proper riscv,isa property.

As a helper function dt_get_hartid() is introduced to deal specifically
with reg propery of a CPU device node.

Signed-off-by: Oleksii Kurochko 
---
Changes in V3:
 - s/dt_processor_cpuid/dt_processor_hartid.
 - s/dt_get_cpuid/dt_get_hartid.
 - use ~0UL in dt_get_cpuid() and in the comment above it.
 - change type for local variable ac in dt_get_cpuid() to unsigned int.
 - Update the return errors for dt_processor_cpuid().
 - Update the commit message + subject: s/cpuid/hartid.
---
Changes in V2:
 - s/of_get_cpu_hwid()/dt_get_cpu_id().
 - Update prototype of dt_get_cpu_hwid(), use pointer-to-const for cpun arg.
 - Add empty line before last return in dt_get_cpu_hwid().
 - s/riscv_of_processor_hartid/dt_processor_cpuid().
 - Use pointer-to_const for node argument of dt_processor_cpuid().
 - Use for hart_id unsigned long type as according to the spec for RV128
   mhartid register will be 128 bit long.
 - Update commit message and subject.
 - use 'CPU' instead of 'HART'.
 - Drop thread argument of dt_get_cpu_id() (of_get_cpu_hwid) as it is
   expected to be always 0 according to RISC-V's DTS binding.
---
 xen/arch/riscv/include/asm/smp.h |  4 ++
 xen/arch/riscv/smpboot.c         | 69 ++++++++++++++++++++++++++++++++
 2 files changed, 73 insertions(+)

diff --git a/xen/arch/riscv/include/asm/smp.h b/xen/arch/riscv/include/asm/smp.h
index 5e170b57b3..eb58b6576b 100644
--- a/xen/arch/riscv/include/asm/smp.h
+++ b/xen/arch/riscv/include/asm/smp.h
@@ -26,6 +26,10 @@ static inline void set_cpuid_to_hartid(unsigned long cpuid,
 
 void setup_tp(unsigned int cpuid);
 
+struct dt_device_node;
+int dt_processor_hartid(const struct dt_device_node *node,
+                        unsigned long *hartid);
+
 #endif
 
 /*
diff --git a/xen/arch/riscv/smpboot.c b/xen/arch/riscv/smpboot.c
index 0f9c2cc54a..b8d18fc3ea 100644
--- a/xen/arch/riscv/smpboot.c
+++ b/xen/arch/riscv/smpboot.c
@@ -1,5 +1,8 @@
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
 
 #include 
@@ -14,3 +17,69 @@ void __init smp_prepare_boot_cpu(void)
     cpumask_set_cpu(0, &cpu_possible_map);
     cpumask_set_cpu(0, &cpu_online_map);
 }
+
+/**
+ * dt_get_hartid - Get the hartid from a CPU device node
+ *
+ * @cpun: CPU number(logical index) for which device node is required
+ *
+ * Return: The hartid for the CPU node or ~0UL if not found.
+ */
+static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
+{
+    const __be32 *cell;
+    unsigned int ac;
+    uint32_t len;
+
+    ac = dt_n_addr_cells(cpun);
+    cell = dt_get_property(cpun, "reg", &len);
+    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
+        return ~0UL;
+
+    return dt_read_number(cell, ac);
+}
+
+/*
+ * Returns the hartid of the given device tree node, or -ENODEV if the node
+ * isn't an enabled and valid RISC-V hart node.
+ */
+int dt_processor_hartid(const struct dt_device_node *node,
+                        unsigned long *hartid)
+{
+    const char *isa;
+    int ret;
+
+    if ( !dt_device_is_compatible(node, "riscv") )
+    {
+        printk("Found incompatible CPU\n");
+        return -ENODEV;
+    }
+
+    *hartid = dt_get_hartid(node);
+    if ( *hartid == ~0UL )
+    {
+        printk("Found CPU without CPU ID\n");
+        return -ENODATA;
+    }
+
+    if ( !dt_device_is_available(node))
+    {
+        printk("CPU with hartid=%lu is not available\n", *hartid);
+        return -ENODEV;
+    }
+
+    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
+    {
+        printk("CPU with hartid=%lu has no \"riscv,isa\" property\n", *hartid);
+        return ret;
+    }
+
+    if ( isa[0] != 'r' || isa[1] != 'v' )
+    {
+        printk("CPU with hartid=%lu has an invalid ISA of \"%s\"\n", *hartid,
+               isa);
+        return -EINVAL;
+    }
+
+    return 0;
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992145.1375990 (Exim 4.92)
	(envelope-from )
	id 1uHlvO-0006Gq-PT; Wed, 21 May 2025 16:04:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992145.1375990; Wed, 21 May 2025 16:04: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 1uHlvO-0006Dn-DA; Wed, 21 May 2025 16:04:10 +0000
Received: by outflank-mailman (input) for mailman id 992145;
 Wed, 21 May 2025 16:04:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvM-0004XB-SI
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:08 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 39ee49e9-365d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:04:08 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-6020ff8d51dso3589015a12.2
 for ; Wed, 21 May 2025 09:04:08 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:04: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" 
X-Inumbo-ID: 39ee49e9-365d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843447; x=1748448247; 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;
        bh=cc8l2Phl1PBhhKkspy5jt6XpbCX7rExH1ZYHyLm8/NQ=;
        b=N1MLx6RxP7AkqrnrH7lZkpidMIgAreAcihrQ65uxal+X+m/SUwL9rpEkbGTgqdZN0q
         4A3qrtezsdWP4Cdu84o4C0GDubPFtve0H37obqZmSCxwROBwE7wSoBFJ3Nn1GXId7AP3
         9AUaKfV9wqc7G0ZO3UvqS6wmqFRQq9grmA5qgRtL9AxeAnYpxjj2eL9kJ7OYmynAvDxB
         2Ln4zLKOBneOxgIMRmVdniUNIIDY67gUh7SL8L70qu2HX5PvNe9zwWO5GkrhkVgPp6qJ
         xXYfN4zGh3Rlg3uisS2JOo2QQfaydh0nt6BHaoyYfQglEXT0lXGuUkUYocOjbryyE839
         miqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843447; x=1748448247;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=cc8l2Phl1PBhhKkspy5jt6XpbCX7rExH1ZYHyLm8/NQ=;
        b=NrK41HV5yK8C9c9uFFNBkJNwlBe8w/6usEdZ2LRDDhFHJWKTVJj6mm0bHjEedgYbsm
         /HI9WbA/qXfHBDIljbc2/WjbmkB7pqwmKWD0da8KT03J6bF/NCZs7MN6XyZUPZxLo1YD
         RhYI0aVdlCk8M+JnngxXj6ntLndGWZ+zoG9qhfHLh8PdWYkeneWn5AfG9WNG6VASfBCT
         Uj6CiNiADPVX8iGqlkKmHch48GcLey3gt9wNRfIBCrPYQ4ussmkEE2N+HKLgD7iByeSX
         pKmhfRNIijNOBsPDiIJmhwdOKLYd0Mfii5r+QBEOqOvYDUQt++MQvCzV6QlJ5qMMLMSt
         LjzQ==
X-Gm-Message-State: AOJu0YzVHz9bhdD82BHJpTHYny7kJqmafIhKdMTOdxie8eVQ77YUJysH
	C83h5g3aAQQ7D2G6PuhYM9IUipFquktJVa7bJaodn4B+mPEOc3SLmb0GVIy0WA==
X-Gm-Gg: ASbGncsWnwrGj86gAHZnU4v5yjHELh2rGhsjm6uQaya0Eo6A71vLw+8kvyZlSO7ZBGX
	XZWEhn1qkmUJIWDFMkOpla1bEJWuqUCvOw2obaksuhiT2CpnpXgxeNDpgGAmOIYf5aWEX10yOox
	/cWIv49wPfeMOG0RK9LWqX5oWXdEC585pKJeNfN/szBywzm7qq11U00/iaA3gIDxF1rhxMMVYz6
	VVjcY1198CzTSyw7F2BWo+nX4oSJpLbahBypOL8rQhg0uKgXLktyI/ebyO0oDBPUPz+C/8VY/Nd
	5t6Y8U+8vehGDHvjQ0X0ZC+Kr/AFyzYm2mZX9iTh+pdyLMneONW98Rw6vB1lKILpRSULHOnx+30
	lFzLnUwPIEtbqM+ixYw==
X-Google-Smtp-Source: AGHT+IF3zpE/Xa94QmEbfYkiHcCAgo23PQYL1rTzXWKouOVfuI8YHMTDFCnxVaKwgu3PbCbfMspbhw==
X-Received: by 2002:a05:6402:3495:b0:602:4405:776f with SMTP id 4fb4d7f45d1cf-60244057906mr1590265a12.31.1747843447034;
        Wed, 21 May 2025 09:04:07 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
Date: Wed, 21 May 2025 18:03:48 +0200
Message-ID: <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

imsic_init() is introduced to parse device tree node, which has the following
bindings [2], and based on the parsed information update IMSIC configuration
which is stored in imsic_cfg.

The following helpers are introduces for imsic_init() usage:
  - imsic_parse_node() parses IMSIC node from DTS
  - imsic_get_parent_hartid() returns the hart ( CPU ) ID of the given device
    tree node.

This patch is based on the code from [1].

Since Microchip originally developed imsic.{c,h}, an internal discussion with
them led to the decision to use the MIT license.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/0b1a94f2bc3bb1a81cd26bb75f0bf578f84cb4d4
[2] https://elixir.bootlin.com/linux/v6.12/source/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V3:
 - Drop year in imsic.h in copyrights.
 - Correct identation in imsic_parse_node() and imsic_init()
   where for imsic_cfg.base_addr a mask is applied.
 - Use unsigned int istead of uint32_t for local variable nr_parent_irqs,
   index, nr_handlers in imsic_init().
 - Fix a leakage of ealiers successfull allocations in case if imsic_init()
   returns with an error.
 - Excess blank in printk() message: "%s: unable to parse MMIO regset %d\n".
 - Introduce hartid_to_cpuid() and use it in the check:
     if ( hardid_to_cpuid(cpuid) >= num_possible_cpus() )
   in imsic_init().
 - Use "%u" for unsigned int in printk(...).
 - Fix for loop condition: nr_mmios -> "j < nr_mmios".
 - [imsic_init()] Drop usage of j in nested loop. It is enough to have only
   index.
 - Change 0x%lx to %#lx for formatting of an address in printk().
 - [imsic_init()] Rename local variable cpuid to hartid.
 - s/imsic_get_parent_cpuid/imsic_get_parent_hartid, s/cpuid/hartid for an
   imsic_get_parent_hartid()'s argument.
 - Declare cpus member of struct imsic_mmios as cpumask_t.
 - [imsic_init()] Allocate imsic_mmios.cpus by using of alloc_cpumask_var().
 - [imsic_init()] Use cpumask_set_cpu() instead of bitmap_set().
 - [imsic_parse_node()] add check for correctness of "interrupt-extended" property.
 - [imsic_parse_node()] Use dt_node_name() or dt_full_node_name() instead of
   derefence of struct dt_node.
 - [imsic_parse_node()] Add cleanup label and update 'rc = XXX; goto cleanup'
   instead of 'return rc' as now we have to cleanup dynamically allocated irq_range
   array.
 - Add comments above imsic_init() and imsic_parse_node().
 - s/xen/arch/riscv/imsic.h/xen/arch/riscv/include/asm/imsic.h in the comment of
   imsic.h.
---
Changes in V2:
 - Drop years in copyrights.
 - s/riscv_of_processor_hartid/dt_processor_cpuid.
 - s/imsic_get_parent_hartid/imsic_get_parent_hartid.
   Rename argument hartid to cpuid.
   Make node argument const.
   Return res instead of -EINVAL for the failure case of dt_processor_cpuid().
   Drop local variable hart and use cpuid argument instead.
   Drop useless return res;
 - imsic_parse_node() changes:
   - Make node argument const.
   - Check the return value of dt_property_read_u32() directly instead of
     saving it to rc variable.
   - Update tmp usage, use short form "-=".
   - Update a check (imsic_cfg.nr_ids >= IMSIC_MAX_ID) to (imsic_cfg.nr_ids > IMSIC_MAX_ID)
     as IMSIC_MAX_ID is changed to maximum valid value, not just the firsr out-of-range.
   - Use `rc` to return value instead of explicitly use -EINVAL.
   - Use do {} while() to find number of MMIO register sets.
 - Set IMSIC_MAX_ID to 2047 (maximum possible IRQ number).
 - imsic_init() changes:
   - Use unsigned int in for's expression1.
   - s/xfree/XFEE.
   - Allocate msi and cpus array dynamically.
 - Drop forward declaration before declaration of imsic_get_config() in asm/imsic.h
   as it is not used as parameter type.
 - Align declaration of imisic_init with defintion.
 - s/harts/cpus in imisic_mmios.
   Also, change type from bool harts[NR_CPUS] to unsigned long *cpus.
 - Allocate msi member of imsic_config dynamically to save some memory.
 - Code style fixes.
 - Update the commit message.
---
 xen/arch/riscv/Makefile            |   1 +
 xen/arch/riscv/imsic.c             | 354 +++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/imsic.h |  65 ++++++
 xen/arch/riscv/include/asm/smp.h   |  13 ++
 4 files changed, 433 insertions(+)
 create mode 100644 xen/arch/riscv/imsic.c
 create mode 100644 xen/arch/riscv/include/asm/imsic.h

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index a1c145c506..e2b8aa42c8 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -2,6 +2,7 @@ obj-y += aplic.o
 obj-y += cpufeature.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
+obj-y += imsic.o
 obj-y += intc.o
 obj-y += irq.o
 obj-y += mm.o
diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
new file mode 100644
index 0000000000..9f8b492e97
--- /dev/null
+++ b/xen/arch/riscv/imsic.c
@@ -0,0 +1,354 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/imsic.c
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) Microchip Technology Inc.
+ * (c) Vates
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static struct imsic_config imsic_cfg;
+
+/* Callers aren't expected to changed imsic_cfg so return const. */
+const struct imsic_config *imsic_get_config(void)
+{
+    return &imsic_cfg;
+}
+
+static int __init imsic_get_parent_hartid(const struct dt_device_node *node,
+                                          unsigned int index,
+                                          unsigned long *hartid)
+{
+    int res;
+    struct dt_phandle_args args;
+
+    res = dt_parse_phandle_with_args(node, "interrupts-extended",
+                                     "#interrupt-cells", index, &args);
+    if ( !res )
+        res = dt_processor_hartid(args.np->parent, hartid);
+
+    return res;
+}
+
+/*
+ * Parses IMSIC DT node.
+ *
+ * Returns 0 if initialization is successful, a negative value on failure,
+ * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
+ * which should be ignored by the hypervisor.
+ */
+static int imsic_parse_node(const struct dt_device_node *node,
+                            unsigned int *nr_parent_irqs)
+{
+    int rc;
+    unsigned int tmp;
+    paddr_t base_addr;
+    uint32_t *irq_range;
+
+    *nr_parent_irqs = dt_number_of_irq(node);
+    if ( !*nr_parent_irqs )
+        panic("%s: irq_num can be 0. Check %s node\n", __func__,
+              dt_node_full_name(node));
+
+    irq_range = xzalloc_array(uint32_t, *nr_parent_irqs * 2);
+    if ( !irq_range )
+        panic("%s: irq_range[] allocation failed\n", __func__);
+
+    if ( (rc = dt_property_read_u32_array(node, "interrupts-extended",
+                                    irq_range, *nr_parent_irqs * 2)) )
+        panic("%s: unable to find interrupt-extended in %s node: %d\n",
+              __func__, dt_node_full_name(node), rc);
+
+    if ( irq_range[1] == IRQ_M_EXT )
+    {
+        /* Machine mode imsic node, ignore it. */
+        rc = IRQ_M_EXT;
+        goto cleanup;
+    }
+
+    /* Check that interrupts-extended property is well-formed. */
+    for ( unsigned int i = 2; i < (*nr_parent_irqs * 2); i += 2 )
+    {
+        if ( irq_range[i + 1] != irq_range[1] )
+            panic("%s: mode[%d] != %d\n", __func__, i + 1, irq_range[1]);
+    }
+
+    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
+                               &imsic_cfg.guest_index_bits) )
+        imsic_cfg.guest_index_bits = 0;
+    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
+    if ( tmp < imsic_cfg.guest_index_bits )
+    {
+        printk(XENLOG_ERR "%s: guest index bits too big\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    /* Find number of HART index bits */
+    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
+                               &imsic_cfg.hart_index_bits) )
+    {
+        /* Assume default value */
+        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
+        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
+            imsic_cfg.hart_index_bits++;
+    }
+    tmp -= imsic_cfg.guest_index_bits;
+    if ( tmp < imsic_cfg.hart_index_bits )
+    {
+        printk(XENLOG_ERR "%s: HART index bits too big\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    /* Find number of group index bits */
+    if ( !dt_property_read_u32(node, "riscv,group-index-bits",
+                               &imsic_cfg.group_index_bits) )
+        imsic_cfg.group_index_bits = 0;
+    tmp -= imsic_cfg.hart_index_bits;
+    if ( tmp < imsic_cfg.group_index_bits )
+    {
+        printk(XENLOG_ERR "%s: group index bits too big\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    /* Find first bit position of group index */
+    tmp = IMSIC_MMIO_PAGE_SHIFT * 2;
+    if ( !dt_property_read_u32(node, "riscv,group-index-shift",
+                               &imsic_cfg.group_index_shift) )
+        imsic_cfg.group_index_shift = tmp;
+    if ( imsic_cfg.group_index_shift < tmp )
+    {
+        printk(XENLOG_ERR "%s: group index shift too small\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+    tmp = imsic_cfg.group_index_bits + imsic_cfg.group_index_shift - 1;
+    if ( tmp >= BITS_PER_LONG )
+    {
+        printk(XENLOG_ERR "%s: group index shift too big\n",
+               dt_node_name(node));
+        rc = -EINVAL;
+        goto cleanup;
+    }
+
+    /* Find number of interrupt identities */
+    if ( !dt_property_read_u32(node, "riscv,num-ids", &imsic_cfg.nr_ids) )
+    {
+        printk(XENLOG_ERR "%s: number of interrupt identities not found\n",
+               node->name);
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) ||
+         (imsic_cfg.nr_ids > IMSIC_MAX_ID) ||
+         ((imsic_cfg.nr_ids & IMSIC_MIN_ID) != IMSIC_MIN_ID) )
+    {
+        printk(XENLOG_ERR "%s: invalid number of interrupt identities\n",
+               node->name);
+        rc = -EINVAL;
+        goto cleanup;
+    }
+
+    /* Compute base address */
+    imsic_cfg.nr_mmios = 0;
+    rc = dt_device_get_address(node, imsic_cfg.nr_mmios, &base_addr, NULL);
+    if ( rc )
+    {
+        printk(XENLOG_ERR "%s: first MMIO resource not found: %d\n",
+               dt_node_name(node), rc);
+        goto cleanup;
+    }
+
+    imsic_cfg.base_addr = base_addr;
+    imsic_cfg.base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+                                 imsic_cfg.hart_index_bits +
+                                 IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+    imsic_cfg.base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                             imsic_cfg.group_index_shift);
+
+    /* Find number of MMIO register sets */
+    do {
+        imsic_cfg.nr_mmios++;
+    } while ( !dt_device_get_address(node, imsic_cfg.nr_mmios, &base_addr, NULL) );
+
+ cleanup:
+    xfree(irq_range);
+
+    return rc;
+}
+
+/*
+ * Initialize the imsic_cfg structure based on the IMSIC DT node.
+ *
+ * Returns 0 if initialization is successful, a negative value on failure,
+ * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
+ * which should be ignored by the hypervisor.
+ */
+int __init imsic_init(const struct dt_device_node *node)
+{
+    int rc;
+    unsigned long reloff, hartid;
+    unsigned int nr_parent_irqs, index, nr_handlers = 0;
+    paddr_t base_addr;
+    unsigned int nr_mmios;
+
+    /* Parse IMSIC node */
+    rc = imsic_parse_node(node, &nr_parent_irqs);
+    /*
+     * If machine mode imsic node => ignore it.
+     * If rc < 0 => parsing of IMSIC DT node failed.
+     */
+    if ( (rc == IRQ_M_EXT) || rc )
+        return rc;
+
+    nr_mmios = imsic_cfg.nr_mmios;
+
+    /* Allocate MMIO resource array */
+    imsic_cfg.mmios = xzalloc_array(struct imsic_mmios, nr_mmios);
+    if ( !imsic_cfg.mmios )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    imsic_cfg.msi = xzalloc_array(struct imsic_msi, nr_parent_irqs);
+    if ( !imsic_cfg.msi )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    /* Check MMIO register sets */
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+    {
+        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
+        {
+            rc = -ENOMEM;
+            goto imsic_init_err;
+        }
+
+        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
+                                   &imsic_cfg.mmios[i].size);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        base_addr = imsic_cfg.mmios[i].base_addr;
+        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+                           imsic_cfg.hart_index_bits +
+                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                       imsic_cfg.group_index_shift);
+        if ( base_addr != imsic_cfg.base_addr )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+    }
+
+    /* Configure handlers for target CPUs */
+    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
+    {
+        unsigned long xen_cpuid;
+
+        rc = imsic_get_parent_hartid(node, i, &hartid);
+        if ( rc )
+        {
+            printk(XENLOG_WARNING "%s: cpu ID for parent irq%u not found\n",
+                   node->name, i);
+            continue;
+        }
+
+        xen_cpuid = hartid_to_cpuid(hartid);
+
+        if ( xen_cpuid >= num_possible_cpus() )
+        {
+            printk(XENLOG_WARNING "%s: unsupported cpu ID=%lu for parent irq%u\n",
+                   node->name, hartid, i);
+            continue;
+        }
+
+        /* Find MMIO location of MSI page */
+        reloff = i * BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ;
+        for ( index = 0; index < nr_mmios; index++ )
+        {
+            if ( reloff < imsic_cfg.mmios[index].size )
+                break;
+
+            /*
+             * MMIO region size may not be aligned to
+             * BIT(global->guest_index_bits) * IMSIC_MMIO_PAGE_SZ
+             * if holes are present.
+             */
+            reloff -= ROUNDUP(imsic_cfg.mmios[index].size,
+                BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ);
+        }
+
+        if ( index == nr_mmios )
+        {
+            printk(XENLOG_WARNING "%s: MMIO not found for parent irq%u\n",
+                   node->name, i);
+            continue;
+        }
+
+        if ( !IS_ALIGNED(imsic_cfg.msi[xen_cpuid].base_addr + reloff, PAGE_SIZE) )
+        {
+            printk(XENLOG_WARNING "%s: MMIO address %#lx is not aligned on a page\n",
+                   node->name, imsic_cfg.msi[xen_cpuid].base_addr + reloff);
+            imsic_cfg.msi[xen_cpuid].offset = 0;
+            imsic_cfg.msi[xen_cpuid].base_addr = 0;
+            continue;
+        }
+
+        cpumask_set_cpu(xen_cpuid, imsic_cfg.mmios[index].cpus);
+
+        imsic_cfg.msi[xen_cpuid].base_addr = imsic_cfg.mmios[index].base_addr;
+        imsic_cfg.msi[xen_cpuid].offset = reloff;
+
+        nr_handlers++;
+    }
+
+    if ( !nr_handlers )
+    {
+        printk(XENLOG_ERR "%s: No CPU handlers found\n", node->name);
+        rc = -ENODEV;
+        goto imsic_init_err;
+    }
+
+    return 0;
+
+ imsic_init_err:
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+        free_cpumask_var(imsic_cfg.mmios[i].cpus);
+    XFREE(imsic_cfg.mmios);
+    XFREE(imsic_cfg.msi);
+
+    return rc;
+}
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
new file mode 100644
index 0000000000..0d17881884
--- /dev/null
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/include/asm/imsic.h
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) Microchip Technology Inc.
+ */
+
+#ifndef ASM__RISCV__IMSIC_H
+#define ASM__RISCV__IMSIC_H
+
+#include 
+
+#define IMSIC_MMIO_PAGE_SHIFT   12
+#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
+
+#define IMSIC_MIN_ID            63
+#define IMSIC_MAX_ID            2047
+
+struct imsic_msi {
+    paddr_t base_addr;
+    unsigned long offset;
+};
+
+struct imsic_mmios {
+    paddr_t base_addr;
+    unsigned long size;
+    cpumask_var_t cpus;
+};
+
+struct imsic_config {
+    /* Base address */
+    paddr_t base_addr;
+
+    /* Bits representing Guest index, HART index, and Group index */
+    unsigned int guest_index_bits;
+    unsigned int hart_index_bits;
+    unsigned int group_index_bits;
+    unsigned int group_index_shift;
+
+    /* IMSIC phandle */
+    unsigned int phandle;
+
+    /* Number of parent irq */
+    unsigned int nr_parent_irqs;
+
+    /* Number off interrupt identities */
+    unsigned int nr_ids;
+
+    /* MMIOs */
+    unsigned int nr_mmios;
+    struct imsic_mmios *mmios;
+
+    /* MSI */
+    struct imsic_msi *msi;
+};
+
+struct dt_device_node;
+int imsic_init(const struct dt_device_node *node);
+
+const struct imsic_config *imsic_get_config(void);
+
+#endif /* ASM__RISCV__IMSIC_H */
diff --git a/xen/arch/riscv/include/asm/smp.h b/xen/arch/riscv/include/asm/smp.h
index eb58b6576b..33ee5ec06b 100644
--- a/xen/arch/riscv/include/asm/smp.h
+++ b/xen/arch/riscv/include/asm/smp.h
@@ -3,6 +3,7 @@
 #define ASM__RISCV__SMP_H
 
 #include 
+#include 
 #include 
 
 #include 
@@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
     return pcpu_info[cpuid].hart_id;
 }
 
+static inline unsigned long hartid_to_cpuid(unsigned long hartid)
+{
+    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
+    {
+        if ( hartid == cpuid_to_hartid(cpuid) )
+            return cpuid;
+    }
+
+    /* hartid isn't valid for some reason */
+    return NR_CPUS;
+}
+
 static inline void set_cpuid_to_hartid(unsigned long cpuid,
                                        unsigned long hartid)
 {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992146.1376007 (Exim 4.92)
	(envelope-from )
	id 1uHlvQ-0006qZ-UT; Wed, 21 May 2025 16:04:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992146.1376007; Wed, 21 May 2025 16:04: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 1uHlvQ-0006qJ-PE; Wed, 21 May 2025 16:04:12 +0000
Received: by outflank-mailman (input) for mailman id 992146;
 Wed, 21 May 2025 16:04:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvO-0004XB-Gj
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:10 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3b2697ce-365d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:04:10 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-601dfef6a8dso6168312a12.1
 for ; Wed, 21 May 2025 09:04:10 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09: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" 
X-Inumbo-ID: 3b2697ce-365d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843449; x=1748448249; 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;
        bh=4rRipHHgVNlXBwWiXRpUAQ4oqkKb1qQJ/QJeF1BX1DU=;
        b=eC47aDgHT8dCD/Lc0+WaDwtP91gQf8e9PTPF38T4oRqUxJDebUfI5urTdIe0+DMvpR
         /8jGL0DnEYdFc7j9ZpJWkZ6LF9NDRFYopTINOhlBEV5kOJESLHLRJzKLLQjClEagoq3X
         hyq9HnZ012hEMkPFWw/CVE6V/ArUQRUBbX9SOHfDbxhrl5XWwHb0geUJu4mxg+vGpxOo
         LOGN5Y/o9RntMIBwS+POyY23vMfgYQ57lpdumi6jwPioWhlSQwO8ETP1vS7k+tVVXi4L
         dtNRSH3mNqpEvW4WGBdwJVC6vIL94Y+Fuxo6UONjr9jBS4F5khO6GL/WSFMbk0g3u/Md
         OZrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843449; x=1748448249;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4rRipHHgVNlXBwWiXRpUAQ4oqkKb1qQJ/QJeF1BX1DU=;
        b=dxRa77jMdwgQtzaNaLTh6jfqdqCKTVpN6q4tZkNfFs2m/3Db/UL0U9Krz4B4lvRnV7
         mnfpGS2B0Xkym/7OKedtNMyn+dcRuPoyhumKmVxghW1RwN9cfPVFZhcF/pUjxWmshaNW
         xJhsBiSgGquOBGcDfennmlFYEiau1sqyYHu6lxxWBWeoTvHWaPEz9+KKE4/Nj+eYcWEi
         ia5lb4UtmVYD5N4xKMPZIKKW2OetcSCmeTZbStbwgMDdFo+He/flM5fLbmQHzoH76M0+
         pVNlojPO+leJdDMZ8VtcXnES4nfrWMVGo1LE8h0B4R0Tqoq/YkVQR/PHKpzKs7tf+rAr
         aGmQ==
X-Gm-Message-State: AOJu0YwA9PQv32veReJVihIjQ7v+ggGwE7AGEozSfluMHP2w2S3NwoHR
	hHp0MGjvXr0Z+0iNPNNhCw8WIs6oj8nd4LWchyPP4J2u3mVPq9pdbSKoafjOkg==
X-Gm-Gg: ASbGnct4I6QPOdkju2jNSe6IkTVnzPDVQOomx1OUCDxKAQHmrezxSkX86a3nHOYvrrf
	YK4HGWxq4XbqllL1L9YdzhU893+APQ32NSWdgVBvyJmPy6StJveAU36CJ2PvQzLLXGekwySLrPO
	VpH22bznVS0otVkc58rOBlpKnsplkhZoqKHSowmPFCFe79b15xBECU5G1/iUyAvafgh444G8agq
	iVHrH9f3wb1GazfZnNM/ZexPzhMa7m6NWLPgmXTLMjwR/YgH6yGIFkRBt/x1MidvHN7gQFmaxaN
	AQyqjZkNmRzCkRB8JDhNAAOHZOFAJHWjR3DUnltxEOlNlCRX+jxjTtUw4fngtNySilrxLYAUuws
	PXG+ktrZGccJaXf4e+pJ7BYYNeqpp
X-Google-Smtp-Source: AGHT+IHv9NdEfpk3ZS9JniuwJMZErPk5+MAvAllfRVvYFcFyYUz0uYtmV9DDn8BG4d4SsmOTQ7b+fg==
X-Received: by 2002:a05:6402:2793:b0:601:d77f:47d9 with SMTP id 4fb4d7f45d1cf-601d77f4b72mr12256239a12.5.1747843449162;
        Wed, 21 May 2025 09:04:09 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v3 10/14] xen/riscv: introduce intc_init() and helpers
Date: Wed, 21 May 2025 18:03:50 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce intc_init() to initialize the interrupt controller using the
registered hardware ops.
Also add intc_route_irq_to_xen() to route IRQs to Xen, with support for
setting IRQ type and priority via new internal helpers intc_set_irq_type()
and intc_set_irq_priority().

Call intc_init() to do basic initialization steps for APLIC and IMSIC.

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V3:
 - Drop ASSERIT(intc_hw_ops) in intc_init().
 - Drop ASSERT(intc_hw_ops) in intc_set_irq_type() and
   intc_set_irq_priority() as intc_init() will be called first and so if it
   won't crash, then intc_hw_ops is registered.
---
Changes in V2:
 - This patch was part of "xen/riscv: Introduce intc_hw_operations abstraction"
   and splitted to have ability to merge patch "xen/riscv: initialize interrupt controller"
   to the current patch (where intc_init() call is actually introduced).
 - Add checks of that callbacks aren't set to NULL in intc_set_irq_priority()
   and intc_set_irq_type().
 - add num_irqs member to struct intc_info as it is used now in
   intc_route_irq_to_xen().
 - Add ASSERT(spin_is_locked(&desc->lock)) to intc_set_irq_priority() in
   the case this function will be called outside intc_route_irq_to_xen().
---
 xen/arch/riscv/include/asm/intc.h |  4 +++
 xen/arch/riscv/intc.c             | 41 +++++++++++++++++++++++++++++++
 xen/arch/riscv/setup.c            |  2 ++
 3 files changed, 47 insertions(+)

diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index f3bbd281fa..1a88505518 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -41,4 +41,8 @@ void intc_preinit(void);
 
 void register_intc_ops(const struct intc_hw_operations *ops);
 
+void intc_init(void);
+
+void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 1ecd651bf3..f2823267a9 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -1,9 +1,12 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 
@@ -21,3 +24,41 @@ void __init intc_preinit(void)
     else
         panic("ACPI interrupt controller preinit() isn't implemented\n");
 }
+
+void __init intc_init(void)
+{
+    if ( intc_hw_ops->init() )
+        panic("Failed to initialize the interrupt controller drivers\n");
+}
+
+/* desc->irq needs to be disabled before calling this function */
+static void intc_set_irq_type(struct irq_desc *desc, unsigned int type)
+{
+    ASSERT(desc->status & IRQ_DISABLED);
+    ASSERT(spin_is_locked(&desc->lock));
+    ASSERT(type != IRQ_TYPE_INVALID);
+
+    if ( intc_hw_ops->set_irq_type )
+        intc_hw_ops->set_irq_type(desc, type);
+}
+
+static void intc_set_irq_priority(struct irq_desc *desc, unsigned int priority)
+{
+    ASSERT(spin_is_locked(&desc->lock));
+
+    if ( intc_hw_ops->set_irq_priority )
+        intc_hw_ops->set_irq_priority(desc, priority);
+}
+
+void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
+{
+    ASSERT(desc->status & IRQ_DISABLED);
+    ASSERT(spin_is_locked(&desc->lock));
+    /* Can't route interrupts that don't exist */
+    ASSERT(intc_hw_ops && desc->irq < intc_hw_ops->info->num_irqs);
+
+    desc->handler = intc_hw_ops->host_irq_type;
+
+    intc_set_irq_type(desc, desc->arch.type);
+    intc_set_irq_priority(desc, priority);
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 8bcd19218d..0e7398159c 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -134,6 +134,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     intc_preinit();
 
+    intc_init();
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992148.1376012 (Exim 4.92)
	(envelope-from )
	id 1uHlvR-0006uo-H3; Wed, 21 May 2025 16:04:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992148.1376012; Wed, 21 May 2025 16:04: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 1uHlvR-0006tl-5M; Wed, 21 May 2025 16:04:13 +0000
Received: by outflank-mailman (input) for mailman id 992148;
 Wed, 21 May 2025 16:04:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvO-0004Wm-VJ
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:10 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3a8be89b-365d-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 18:04:09 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-601dd3dfc1fso7608387a12.0
 for ; Wed, 21 May 2025 09:04:09 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:04: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" 
X-Inumbo-ID: 3a8be89b-365d-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843448; x=1748448248; 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;
        bh=tKcUbC/dKhBrMOeG2SxpSs0jn1vZOvnDoHWCS0RyMFk=;
        b=bRAzbqywdICG7bHhE/Wha1OgQQN8P1SxHxCHnIBCciTgF+VM5CV0aRYlCKuJ2tO0J5
         /PVnYMuaAKFl1cBgcyCu41klJvdQq5MthGe7FmH0mvRtL7tFlj1MXLl9ExnapDkBOaQ/
         PJUCiKyIcwzxGqOZppsIEmBgmoHXLLoNLi7eTSF9p0stVbJ5PzRs7fl+JRphxfihDU3D
         yMdyg6ZRFQbJxHReLWKgaKOCC/o+6DatkoVTB2D3sI/nyOa0kh0t2+geBD0LgqPcZCeE
         dcmxF6HD1O8tN2JC4yr2Y5QskrpIx7VoiT2Nay2gnmOx54082r9IPsQEuZARpL5rBX7n
         1LNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843448; x=1748448248;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=tKcUbC/dKhBrMOeG2SxpSs0jn1vZOvnDoHWCS0RyMFk=;
        b=Le6Cjm6UpMid5NpARsBN7jyr/ifwS7Q+JRU6HU/s2Xta5//LZaHDIBZFuHcOTOuHEQ
         wevEa4DgA7O0/Icxs4oe5+LE0tvhyubn6m/sOfQK93PiclS+TfXamuoQ7y2pPrBWBNfe
         PxcOhUPiQ0Duuieg0xGF1xqYWU75HJXEuNv/jzSLvXq7uy3T0WSO/OvZ127ikxcjhmcE
         dtbzXHoZcnUdXQGTHKVgzs6K7y7Gk/FaveXJ3aavw1WkTOaECCHD62MUeGNFCrcmmwnv
         0LzRHkeCM6S6BcicxCGD6Fe0hJiX1LOHp2vpoUh77Mf6Zkq5im+xLar48FLhT6Tlo3Wc
         SSDg==
X-Gm-Message-State: AOJu0Yx9hndV1SMunNH8X5HQhmGgaehap0meU1VYltWpDnW8YiNEUFfA
	LQ59ie3VDV3ixWMJnjL2sranjPny+Ov5Ih2LND9RzQdDNQ/EOeZ04f3DnE7XQg==
X-Gm-Gg: ASbGncuwz+Cd3S6NgQqFTVPFYJ9ys3GOMSfrmPdoD+RVNBvLzNqOhaeiWOUSNqJm6TE
	BwVI/vQjub9ZNtXWEx8I2Voem4uIqi4CUbRU9zo5dmvfD9sOAEDwlKgPyaKSDpXNpuZUYIOA4+X
	OxOJjySM14dkFOPsBnmYERTuQqpudev5+X68Zuu+PzZ7fsjQVeLqSW/nYMz2EAhMyTZD+q0WDQP
	BqvVS3+dEfnGgVDbZrSwKOlhAE1UewQFtMP6szsmpYan6f6XoaWjYqu9mX6XQtQDZYqQ6ssQpXW
	ZkGNvl9gDw1Nq3wAul6Pk3qntM4YuWzjTvvGdS9eB5kUFQRgg6RWnvuOGjB62WtpSyaspCmElvf
	3qEX7WspkTTBJncJD7RXj+wesXWIN
X-Google-Smtp-Source: AGHT+IFnhWduam6EWVj1qtA4Elrpl3Pnd4GfLJCKTcqpUoTLlF4c6X0S6IiJ1qtH5S1Du0QBil0EHA==
X-Received: by 2002:a05:6402:354a:b0:602:3cf1:44a6 with SMTP id 4fb4d7f45d1cf-6023cf149b7mr2474889a12.28.1747843448056;
        Wed, 21 May 2025 09:04:08 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v3 09/14] xen/riscv: aplic_init() implementation
Date: Wed, 21 May 2025 18:03:49 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

aplic_init() function does the following few things:
 - checks that IMSIC in device tree node  ( by checking msi-parent property
   in APLIC node ) is present as current one implmenetaion of AIA is
   supported only MSI method.
 - initialize IMSIC based on IMSIC device tree node
 - Read value of APLIC's paddr start/end and size.
 - Map aplic.regs
 - Setup APLIC initial state interrupts (disable all interrupts, set
   interrupt type and default priority, confgifure APLIC domaincfg) by
   calling aplic_init_hw_interrutps().

aplic_init() is based on the code from [1] and [2].

Since Microchip originally developed aplic.c, an internal discussion with
them led to the decision to use the MIT license.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7cfb4bd4748ca268142497ac5c327d2766fb342d
[2] https://gitlab.com/xen-project/people/olkur/xen/-/commit/392a531bfad39bf4656ce8128e004b241b8b3f3e

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V3:
 - Correct the comment on top of aplic-priv.h:
     xen/arch/riscv/aplic.h -> .../aplic-priv.h
 - Add __iomem for regs member of aplic_priv structure.
 - [aplic_init_hw_interrupts] Use ~0U instead of -1U in aplic_init_hw_interrupts()
   to disable all interrupts.
 - [aplic_init_hw_interrupts] Start 'i' (for-cycle variable) from 0, not from 1.
 - [aplic_init()] Declare imsic_node as pointer-to-const.
 - Use decimal for arrays in struct aplic_regs.
 - [aplic_init()] Check that aplic_info.num_irqs are less then 1023.
 - [aplic_init()] Drop out check of IMSIC's node interrupt-extended property
   from aplic_init().
---
Changes in V2:
 - use __ro_after_init for aplic_ops.
 - s/nr_irqs/num_irqs.
 - s/dt_processor_hartid/dt_processor_cpuid.
 - Drop confusing comment in aplic_init_hw_interrupts().
 - Code style fixes.
 - Drop years for Copyright.
 - Revert changes which drop nr_irq define from asm/irq.h,
   it shouldn't be, at least, part of this patch.
 - Drop paddr_enf from struct aplic_regs. It is enough to have pair
   (paddr_start, size).
 - Make  struct aplic_priv of asm/aplic.h private by moving it to
   riscv/aplic-priv.h.
 - Add the comment above the initialization of APLIC's target register.
 - use writel() to access APLIC's registers.
 - use 'unsinged int' for local variable i in aplic_init_hw_interrupts.
 - Add the check that all modes in interrupts-extended property of
   imsic node are equal. And drop rc != EOVERFLOW when interrupts-extended
   property is read.
 - Add cf_check to aplic_init().
 - Fix a cycle of clrie register initialization in aplic_init_hw_interrupts().
   Previous implementation leads to out-of-boundary.
 - Declare member num_irqs in struct intc_info as it is used by APLIC code.
---
 xen/arch/riscv/aplic-priv.h        | 34 +++++++++++
 xen/arch/riscv/aplic.c             | 98 ++++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/aplic.h | 64 +++++++++++++++++++
 xen/arch/riscv/include/asm/intc.h  |  3 +
 4 files changed, 199 insertions(+)
 create mode 100644 xen/arch/riscv/aplic-priv.h
 create mode 100644 xen/arch/riscv/include/asm/aplic.h

diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h
new file mode 100644
index 0000000000..e5f9f5fd90
--- /dev/null
+++ b/xen/arch/riscv/aplic-priv.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/aplic-priv.h
+ *
+ * Private part of aplic.h header.
+ *
+ * RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ * Copyright (c) Vates.
+ */
+
+#ifndef ASM__RISCV_PRIV_APLIC_H
+#define ASM__RISCV_PRIV_APLIC_H
+
+#include 
+
+#include 
+#include 
+
+struct aplic_priv {
+    /* base physical address and size */
+    paddr_t paddr_start;
+    size_t  size;
+
+    /* registers */
+    volatile struct aplic_regs __iomem *regs;
+
+    /* imsic configuration */
+    const struct imsic_config *imsic_cfg;
+};
+
+#endif /* ASM__RISCV_PRIV_APLIC_H */
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 10ae81f7ac..069d157723 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,19 +9,113 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+
+#include "aplic-priv.h"
 
 #include 
+#include 
 #include 
+#include 
+
+#define APLIC_DEFAULT_PRIORITY  1
+
+/* The maximum number of wired interrupt sources supported by APLIC domain. */
+#define APLIC_MAX_NUM_WIRED_IRQ_SOURCES 1023
+
+static struct aplic_priv aplic;
 
 static struct intc_info __ro_after_init aplic_info = {
     .hw_version = INTC_APLIC,
 };
 
+static void __init aplic_init_hw_interrupts(void)
+{
+    unsigned int i;
+
+    /* Disable all interrupts */
+    for ( i = 0; i < ARRAY_SIZE(aplic.regs->clrie); i++)
+        writel(~0U, &aplic.regs->clrie[i]);
+
+    /* Set interrupt type and default priority for all interrupts */
+    for ( i = 0; i < aplic_info.num_irqs; i++ )
+    {
+        writel(0, &aplic.regs->sourcecfg[i]);
+        /*
+         * 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.
+         */
+        writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i]);
+    }
+
+    writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg);
+}
+
+static int __init cf_check aplic_init(void)
+{
+    dt_phandle imsic_phandle;
+    const __be32 *prop;
+    uint64_t size, paddr;
+    const struct dt_device_node *imsic_node;
+    const struct dt_device_node *node = aplic_info.node;
+    int rc;
+
+    /* Check for associated imsic node */
+    if ( !dt_property_read_u32(node, "msi-parent", &imsic_phandle) )
+        panic("%s: IDC mode not supported\n", node->full_name);
+
+    imsic_node = dt_find_node_by_phandle(imsic_phandle);
+    if ( !imsic_node )
+        panic("%s: unable to find IMSIC node\n", node->full_name);
+
+    rc = imsic_init(imsic_node);
+    if ( rc == IRQ_M_EXT )
+        /* Machine mode imsic node, ignore this aplic node */
+        return 0;
+    else if ( rc )
+        panic("%s: Failded to initialize IMSIC\n", node->full_name);
+
+    /* Find out number of interrupt sources */
+    if ( !dt_property_read_u32(node, "riscv,num-sources",
+                               &aplic_info.num_irqs) )
+        panic("%s: failed to get number of interrupt sources\n",
+              node->full_name);
+
+    if ( aplic_info.num_irqs > APLIC_MAX_NUM_WIRED_IRQ_SOURCES )
+        panic("%s: too big number of riscv,num-source: %u\n",
+               __func__, aplic_info.num_irqs);
+
+    prop = dt_get_property(node, "reg", NULL);
+    dt_get_range(&prop, node, &paddr, &size);
+    if ( !paddr )
+        panic("%s: first MMIO resource not found\n", node->full_name);
+
+    aplic.paddr_start = paddr;
+    aplic.size = size;
+
+    aplic.regs = ioremap(paddr, size);
+    if ( !aplic.regs )
+        panic("%s: unable to map\n", node->full_name);
+
+    /* Setup initial state APLIC interrupts */
+    aplic_init_hw_interrupts();
+
+    return 0;
+}
+
+static struct intc_hw_operations __ro_after_init aplic_ops = {
+    .info                = &aplic_info,
+    .init                = aplic_init,
+};
+
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
                                     unsigned int intsize,
                                     unsigned int *out_hwirq,
@@ -53,8 +147,12 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     aplic_info.node = node;
 
+    aplic.imsic_cfg = imsic_get_config();
+
     dt_irq_xlate = aplic_irq_xlate;
 
+    register_intc_ops(&aplic_ops);
+
     return 0;
 }
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
new file mode 100644
index 0000000000..fef5f90a61
--- /dev/null
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/asm/include/aplic.h
+ *
+ * RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ */
+
+#ifndef ASM__RISCV__APLIC_H
+#define ASM__RISCV__APLIC_H
+
+#include 
+
+#include 
+
+#define APLIC_DOMAINCFG_IE      BIT(8, UL)
+#define APLIC_DOMAINCFG_DM      BIT(2, UL)
+
+struct aplic_regs {
+    uint32_t domaincfg;
+    uint32_t sourcecfg[1023];
+    uint8_t _reserved1[3008];
+
+    uint32_t mmsiaddrcfg;
+    uint32_t mmsiaddrcfgh;
+    uint32_t smsiaddrcfg;
+    uint32_t smsiaddrcfgh;
+    uint8_t _reserved2[48];
+
+    uint32_t setip[32];
+    uint8_t _reserved3[92];
+
+    uint32_t setipnum;
+    uint8_t _reserved4[32];
+
+    uint32_t in_clrip[32];
+    uint8_t _reserved5[92];
+
+    uint32_t clripnum;
+    uint8_t _reserved6[32];
+
+    uint32_t setie[32];
+    uint8_t _reserved7[92];
+
+    uint32_t setienum;
+    uint8_t _reserved8[32];
+
+    uint32_t clrie[32];
+    uint8_t _reserved9[92];
+
+    uint32_t clrienum;
+    uint8_t _reserved10[32];
+
+    uint32_t setipnum_le;
+    uint32_t setipnum_be;
+    uint8_t _reserved11[4088];
+
+    uint32_t genmsi;
+    uint32_t target[1023];
+};
+
+#endif /* ASM__RISCV__APLIC_H */
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 860737f965..f3bbd281fa 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -17,6 +17,9 @@ struct irq_desc;
 struct intc_info {
     enum intc_version hw_version;
     const struct dt_device_node *node;
+
+    /* number of irqs */
+    unsigned int num_irqs;
 };
 
 struct intc_hw_operations {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992149.1376019 (Exim 4.92)
	(envelope-from )
	id 1uHlvS-00073j-Bc; Wed, 21 May 2025 16:04:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992149.1376019; Wed, 21 May 2025 16:04: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 1uHlvR-00072R-RO; Wed, 21 May 2025 16:04:13 +0000
Received: by outflank-mailman (input) for mailman id 992149;
 Wed, 21 May 2025 16:04:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvP-0004XB-QR
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:11 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3bc76172-365d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:04:11 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-6021b8b2c5fso3307443a12.2
 for ; Wed, 21 May 2025 09:04:11 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:04: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" 
X-Inumbo-ID: 3bc76172-365d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843450; x=1748448250; 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;
        bh=NQhS3BCzqDqg/tB23NlNGRPRQsd4AUHRLO+Tv6cvfi0=;
        b=WQn63EhU0CmO3pzuTz5HFjGVWoQARQ4/YzRrI1wfng+c8iiZ+jKAvhgow4favUB+Td
         nBrT8cIEqmc6h5oo6zpvCoP+YytFRhx1GFx6bQCYjvXpuFpKAQt83OVBneywuBBZ3h65
         mipQVUGt949HHYpNkTOHueAvyLlXgrWtoY2EuImrdvtaWLpW0cSte2pK9YymYI/OkU1L
         H1zVs+9Z6luqB5pid5oEHHtWjkTNPJ1b1nsIBi74oR4ZIZReVVlSc5O4uCDzFvIS3fZa
         yfvha6dEnu9n+7mNwlMHPYmwEep/NuPl7VKXiIUzrDv/uQth66FTK2RVaB/Xg4N+HCgL
         rtRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843450; x=1748448250;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=NQhS3BCzqDqg/tB23NlNGRPRQsd4AUHRLO+Tv6cvfi0=;
        b=hTTIDti3cEbg/RFeX3aNZzPl1NnSWx/5h/CJ3EvmhGqsHrnPqkO1BzWXSOmS2vrqtc
         ihRLk4GZpcwwyByLIjsBSLq76ntLiK0fChvT4NrfwRsWChuN5PhKH7OReEzicN5y9eoD
         JLnwi5UOeERPGMC+9zWe4g+KCVIKAwCH9g/mx6bIC2EfWcNKO9ZV4TQUItEto1h7S01P
         SieTwjj/yrPy1naJ+5ywLK08EKiBCYwqzuSyCJOIZNgw3Wo7/Lslgufjnd59Cf+/LGS9
         DmDWsUXEFGxN9dPZxKgilvCg/F35NB9LXtULRtXZPzYqAWmJ6B1D9FX/KfZPLAXck7eN
         LeBA==
X-Gm-Message-State: AOJu0YyrqGs5crVMZoB/KkMvcVHOEUU9p6mihK5oypLxIw5FSFzaM99m
	qK/b6N7LkP4LEXPXFT/h0fgWzidKiBNMqXepynYX7rj0xZMiS+bBJS5FQ7k7zA==
X-Gm-Gg: ASbGncuDSpy/L7nuO7/+FUkfv/rfUlAItdbh5ogl1IHZErZfVILBfjcB/GJm+RU4zbR
	42nGIT1riP3+k6zdlIjKKi+5KqrC0jhYPiXgPvNmrFvuDDnSYxp+px2gRG1s1Zk+onpnvpwLwj5
	V8HsrumgezdgakCAgQTMavJ3BVsIal+x6xujLTs8gMIkzsHzTxw0rGdcfGUgARgkj8CKOm6e561
	5Lva6nTLnVlqzp9JZ4lrQONLP99Oq+EJnkfxJwtXblnxbGx82ZESrqzE6HA+GD1qf8NlBvDO0Gd
	2omm7gty7xJrHnJ6uI6u9BPiJdlEGc5Xa/AXz+PWYmpF+bhMWjlBKlI8waN8+5IZoHohrZJa9U1
	PM3mxrRNct1zPjSlf5mUUDSgQkjNh
X-Google-Smtp-Source: AGHT+IH39hYXIb36NxukRyZ0FCD1/8tPv5jNWN5kwqUkL9wUQ22UAZbcM9Ko8f8ZYyCtnPPOxjlYpg==
X-Received: by 2002:a05:6402:90a:b0:5fb:1cbb:9390 with SMTP id 4fb4d7f45d1cf-60090185bbamr17736230a12.33.1747843450125;
        Wed, 21 May 2025 09:04:10 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v3 11/14] xen/riscv: implementation of aplic and imsic operations
Date: Wed, 21 May 2025 18:03:51 +0200
Message-ID: <33f0952f0d05e4fe8fff926df31987e006c6eacf.1747843009.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce interrupt controller descriptor for host APLIC to describe
the low-lovel hardare. It includes implementation of the following functions:
 - aplic_irq_startup()
 - aplic_irq_enable()
 - aplic_irq_disable()
 - aplic_set_irq_affinity()

As APLIC is used in MSI mode it requires to enable/disable interrupts not
only for APLIC but also for IMSIC. Thereby for the purpose of
aplic_irq_{enable,disable}() it is introduced imsic_irq_{enable,disable)().

For the purpose of aplic_set_irq_affinity() aplic_get_cpu_from_mask() is
introduced to get hart id.

Also, introduce additional interrupt controller h/w operations and
host_irq_type for APLIC:
 - aplic_host_irq_type

Patch is based on the code from [1].

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V3:
 - Update the lock above lock member of struct aplic_priv and imsic_config struct.
 - Use spin_{un}lock() in aplic_irq_{enable,disable}() as it is IRQ-safe.
   Also drop local variable 'flags'.
 - Add ASSERT(spin_is_locked(&desc->lock)) to aplic_set_irq_affinity() and
   aplic_set_irq_type().
 - Use an initializer instead of spin_lock_init() for aplic.lock.
 - Drop "(l)" in the comment in imsic_irq_enable() as it doesn't point to
   anything.
 - Use ASSERT(!local_irq_is_enabled()) + spin_lock() in imsic_irq_{enable,disable}().
 - Use an initializer instead of spin_lock_init() for imsic_config.lock.
---
Changes in V2:
 - Move imsic_ids_local_delivery() and connected to it parts to the current
   patch to fix compilation issue. Also, add __init for
   imsic_ids_local_delivery().
 - Move introduction of aplic_set_irq_type() and aplic_set_irq_priority()
   to patch [PATCH v1 12/14] xen/riscv: implement setup_irq() where they
   really started to be used.
 - Update the commit message.
 - Drop is_used variable for imsic_cfg and use (aplic.regs->domaincfg & APLIC_DOMAINCFG_DM) instead.
 - Use writel() to write to APLIC regs.
 - Drop aplic_irq_shutdown() and use aplic_irq_disable explicitly.
 - Drop local variable cpu in aplic_get_cpu_from_mask():
   Use cpu_online_map instead of cpu_possible_map.
   Remame possible_mask to mask.
 - Code style fixes.
 - Move spin_lock(&aplic.lock) down before write to the register in aplic_set_irq_affinity.
 - Make aplic_host_irq_type const.
 - imsic_local_eix_update() updates:
   - move unsigned long isel, ireg; to inner loop.
   - Drop unnecessary parentheses.
   - Optimize inner loop of ireg's setting.
 - Drop aplic_irq_ack() and aplic_host_irq_end() as they do nothing.
 - Rename s/hwirq/irq.
 - Add explanatory comment to imsic_irq_enable() about why there is not -1 for IRQ in
   comparison with APLIC's sourcecfg.
 - Use IMSIC_MMIO_PAGE_SHIFT instead of constant 12 in aplic_set_irq_affinity().
 - s/aplic_host_irq_type/aplic_xen_irq_type
 - Drop set/clear of IRQ_DISABLED bit in aplic_{enable,disable}() as guest will always
   first request an interrupt and then only an interrupt will be enabled.
   (for example, in Arm, the physical interrupts would be enabled when the
   interrupt is initially routed. This could lead to problem because the guest
   will usually boot with interrupt disabled.)
---
 xen/arch/riscv/aplic-priv.h        |   4 +
 xen/arch/riscv/aplic.c             | 113 +++++++++++++++++++++++++-
 xen/arch/riscv/imsic.c             | 122 ++++++++++++++++++++++++++++-
 xen/arch/riscv/include/asm/aplic.h |   2 +
 xen/arch/riscv/include/asm/imsic.h |  18 +++++
 5 files changed, 257 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h
index e5f9f5fd90..cd7db2a9d2 100644
--- a/xen/arch/riscv/aplic-priv.h
+++ b/xen/arch/riscv/aplic-priv.h
@@ -14,6 +14,7 @@
 #ifndef ASM__RISCV_PRIV_APLIC_H
 #define ASM__RISCV_PRIV_APLIC_H
 
+#include 
 #include 
 
 #include 
@@ -27,6 +28,9 @@ struct aplic_priv {
     /* registers */
     volatile struct aplic_regs __iomem *regs;
 
+    /* lock to protect access to APLIC's registers */
+    spinlock_t lock;
+
     /* imsic configuration */
     const struct imsic_config *imsic_cfg;
 };
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 069d157723..f48937ccc6 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -23,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define APLIC_DEFAULT_PRIORITY  1
@@ -30,7 +32,9 @@
 /* The maximum number of wired interrupt sources supported by APLIC domain. */
 #define APLIC_MAX_NUM_WIRED_IRQ_SOURCES 1023
 
-static struct aplic_priv aplic;
+static struct aplic_priv aplic = {
+    .lock = SPIN_LOCK_UNLOCKED,
+};
 
 static struct intc_info __ro_after_init aplic_info = {
     .hw_version = INTC_APLIC,
@@ -111,9 +115,116 @@ static int __init cf_check aplic_init(void)
     return 0;
 }
 
+static void aplic_irq_enable(struct irq_desc *desc)
+{
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    spin_lock(&aplic.lock);
+
+    /* Enable interrupt in IMSIC */
+    imsic_irq_enable(desc->irq);
+
+    /* Enable interrupt in APLIC */
+    writel(desc->irq, &aplic.regs->setienum);
+
+    spin_unlock(&aplic.lock);
+}
+
+static void aplic_irq_disable(struct irq_desc *desc)
+{
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    spin_lock(&aplic.lock);
+
+    /* disable interrupt in APLIC */
+    writel(desc->irq, &aplic.regs->clrienum);
+
+    /* disable interrupt in IMSIC */
+    imsic_irq_disable(desc->irq);
+
+    spin_unlock(&aplic.lock);
+}
+
+static unsigned int aplic_irq_startup(struct irq_desc *desc)
+{
+    aplic_irq_enable(desc);
+
+    return 0;
+}
+
+static unsigned int aplic_get_cpu_from_mask(const cpumask_t *cpumask)
+{
+    cpumask_t mask;
+
+    cpumask_and(&mask, cpumask, &cpu_online_map);
+
+    return cpumask_any(&mask);
+}
+
+static void 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;
+
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(!cpumask_empty(mask));
+
+    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;
+    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) ;
+
+    spin_lock(&aplic.lock);
+
+    writel(value, &aplic.regs->target[desc->irq - 1]);
+
+    spin_unlock(&aplic.lock);
+}
+
+static const hw_irq_controller aplic_xen_irq_type = {
+    .typename     = "aplic",
+    .startup      = aplic_irq_startup,
+    .shutdown     = aplic_irq_disable,
+    .enable       = aplic_irq_enable,
+    .disable      = aplic_irq_disable,
+    .set_affinity = aplic_set_irq_affinity,
+};
+
 static struct intc_hw_operations __ro_after_init aplic_ops = {
     .info                = &aplic_info,
     .init                = aplic_init,
+    .host_irq_type       = &aplic_xen_irq_type,
 };
 
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
index 9f8b492e97..2d139943c5 100644
--- a/xen/arch/riscv/imsic.c
+++ b/xen/arch/riscv/imsic.c
@@ -22,7 +22,124 @@
 
 #include 
 
-static struct imsic_config imsic_cfg;
+static struct imsic_config imsic_cfg = {
+    .lock = SPIN_LOCK_UNLOCKED,
+};
+
+#define IMSIC_DISABLE_EIDELIVERY    0
+#define IMSIC_ENABLE_EIDELIVERY     1
+#define IMSIC_DISABLE_EITHRESHOLD   1
+#define IMSIC_ENABLE_EITHRESHOLD    0
+
+#define imsic_csr_write(c, v)   \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_write(CSR_SIREG, v);    \
+} while (0)
+
+#define imsic_csr_set(c, v)     \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_set(CSR_SIREG, v);      \
+} while (0)
+
+#define imsic_csr_clear(c, v)   \
+do {                            \
+    csr_write(CSR_SISELECT, c); \
+    csr_clear(CSR_SIREG, v);    \
+} while (0)
+
+void __init imsic_ids_local_delivery(bool enable)
+{
+    if ( enable )
+    {
+        imsic_csr_write(IMSIC_EITHRESHOLD, IMSIC_ENABLE_EITHRESHOLD);
+        imsic_csr_write(IMSIC_EIDELIVERY, IMSIC_ENABLE_EIDELIVERY);
+    }
+    else
+    {
+        imsic_csr_write(IMSIC_EITHRESHOLD, IMSIC_DISABLE_EITHRESHOLD);
+        imsic_csr_write(IMSIC_EIDELIVERY, IMSIC_DISABLE_EIDELIVERY);
+    }
+}
+
+static void imsic_local_eix_update(unsigned long base_id, unsigned long num_id,
+                                   bool pend, bool val)
+{
+    unsigned long id = base_id, last_id = base_id + num_id;
+
+    while ( id < last_id )
+    {
+        unsigned long isel, ireg;
+        unsigned long start_id = id & (__riscv_xlen - 1);
+        unsigned long chunk = __riscv_xlen - start_id;
+        unsigned long count = (last_id - id < chunk) ? last_id - id : chunk;
+
+        isel = id / __riscv_xlen;
+        isel *= __riscv_xlen / IMSIC_EIPx_BITS;
+        isel += pend ? IMSIC_EIP0 : IMSIC_EIE0;
+
+        ireg = GENMASK(start_id + count - 1, start_id);
+
+        id += count;
+
+        if ( val )
+            imsic_csr_set(isel, ireg);
+        else
+            imsic_csr_clear(isel, ireg);
+    }
+}
+
+void imsic_irq_enable(unsigned int irq)
+{
+    /*
+    * The only caller of imsic_irq_enable() is aplic_irq_enable(), which
+    * already runs with IRQs disabled. Therefore, there's no need to use
+    * spin_lock_irqsave() in this function.
+    *
+    * This ASSERT is added as a safeguard: if imsic_irq_enable() is ever
+    * called from a context where IRQs are not disabled,
+    * spin_lock_irqsave() should be used instead of spin_lock().
+    */
+    ASSERT(!local_irq_is_enabled());
+
+    spin_lock(&imsic_cfg.lock);
+    /*
+     * There is no irq - 1 here (look at aplic_set_irq_type()) because:
+     * From the spec:
+     *   When an interrupt file supports distinct interrupt identities,
+     *   valid identity numbers are between 1 and inclusive. The identity
+     *   numbers within this range are said to be implemented by the interrupt
+     *   file; numbers outside this range are not implemented. The number zero
+     *   is never a valid interrupt identity.
+     *   ...
+     *   Bit positions in a valid eiek register that don’t correspond to a
+     *   supported interrupt identity (such as bit 0 of eie0) are read-only zeros.
+     *
+     * So in EIx registers interrupt i corresponds to bit i in comparison wiht
+     * APLIC's sourcecfg which starts from 0.
+     */
+    imsic_local_eix_update(irq, 1, false, true);
+    spin_unlock(&imsic_cfg.lock);
+}
+
+void imsic_irq_disable(unsigned int irq)
+{
+   /*
+    * The only caller of imsic_irq_disable() is aplic_irq_enable(), which
+    * already runs with IRQs disabled. Therefore, there's no need to use
+    * spin_lock_irqsave() in this function.
+    *
+    * This ASSERT is added as a safeguard: if imsic_irq_disable() is ever
+    * called from a context where IRQs are not disabled,
+    * spin_lock_irqsave() should be used instead of spin_lock().
+    */
+    ASSERT(!local_irq_is_enabled());
+
+    spin_lock(&imsic_cfg.lock);
+    imsic_local_eix_update(irq, 1, false, false);
+    spin_unlock(&imsic_cfg.lock);
+}
 
 /* Callers aren't expected to changed imsic_cfg so return const. */
 const struct imsic_config *imsic_get_config(void)
@@ -342,6 +459,9 @@ int __init imsic_init(const struct dt_device_node *node)
         goto imsic_init_err;
     }
 
+    /* Enable local interrupt delivery */
+    imsic_ids_local_delivery(true);
+
     return 0;
 
  imsic_init_err:
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index fef5f90a61..a814a36a82 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -18,6 +18,8 @@
 #define APLIC_DOMAINCFG_IE      BIT(8, UL)
 #define APLIC_DOMAINCFG_DM      BIT(2, UL)
 
+#define APLIC_TARGET_HART_IDX_SHIFT 18
+
 struct aplic_regs {
     uint32_t domaincfg;
     uint32_t sourcecfg[1023];
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index 0d17881884..a0eba55f99 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -11,6 +11,7 @@
 #ifndef ASM__RISCV__IMSIC_H
 #define ASM__RISCV__IMSIC_H
 
+#include 
 #include 
 
 #define IMSIC_MMIO_PAGE_SHIFT   12
@@ -19,6 +20,15 @@
 #define IMSIC_MIN_ID            63
 #define IMSIC_MAX_ID            2047
 
+#define IMSIC_EIDELIVERY        0x70
+
+#define IMSIC_EITHRESHOLD       0x72
+
+#define IMSIC_EIP0              0x80
+#define IMSIC_EIPx_BITS         32
+
+#define IMSIC_EIE0              0xC0
+
 struct imsic_msi {
     paddr_t base_addr;
     unsigned long offset;
@@ -55,6 +65,9 @@ struct imsic_config {
 
     /* MSI */
     struct imsic_msi *msi;
+
+    /* Lock to protect access to IMSIC's stuff */
+    spinlock_t lock;
 };
 
 struct dt_device_node;
@@ -62,4 +75,9 @@ int imsic_init(const struct dt_device_node *node);
 
 const struct imsic_config *imsic_get_config(void);
 
+void imsic_irq_enable(unsigned int hwirq);
+void imsic_irq_disable(unsigned int hwirq);
+
+void imsic_ids_local_delivery(bool enable);
+
 #endif /* ASM__RISCV__IMSIC_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992150.1376026 (Exim 4.92)
	(envelope-from )
	id 1uHlvT-0007EK-Ao; Wed, 21 May 2025 16:04:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992150.1376026; Wed, 21 May 2025 16: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 1uHlvS-0007BH-Lb; Wed, 21 May 2025 16:04:14 +0000
Received: by outflank-mailman (input) for mailman id 992150;
 Wed, 21 May 2025 16:04:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvR-0004XB-3Q
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:13 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3c8ee7d1-365d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:04:12 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ad563b69908so601633166b.3
 for ; Wed, 21 May 2025 09:04:12 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:04: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" 
X-Inumbo-ID: 3c8ee7d1-365d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843452; x=1748448252; 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;
        bh=XyAwodaa4cada9dAsxM26iAezZGHbHHwpzUE0m4gKwA=;
        b=Wb/Wm7+gL4n8rHDqTt1kCOb5Z7MQo3tqIZu9mDIg8KYOYusyBFDsCxjBg4dMJGp/x3
         nLTZpacd7X+e0LCXmOJphKc0dXfua87NofBzoHoFPirVbGlfwVMeylnRmRjnTdmm7erO
         lt/oMwryHjgnNhLS1+eCQbuvGLqbpfQCVYI0qnAmfldjPdYE3Aqv8i950UXRdS6nwikK
         aSpWYJ4VUDWGwoncmsilZ/MaDTYMNsrwr3UabPXidVhHrENFj/bEnW/r/v3JU6dHEnGA
         5q0JtrH8GjEZ+zDTfpFGbPQ1IJw09+yiRkptjdnHpT5a2ZEqJWoaDYkjfBB8AQaG8/tZ
         XRHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843452; x=1748448252;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=XyAwodaa4cada9dAsxM26iAezZGHbHHwpzUE0m4gKwA=;
        b=NAYC2Yb/4pnQVi/Lz1gkOw/7pSsLTD7Ho+UcYjWo4XkBKSF+OGbZ2Q9eKCDQYqLLJ3
         VzYNGD3qSXEVzLFAKNgyzEpMrh+AgzDWyr9Ys5wWia3bW9alJ0HbT51WQfinJ5gpVXPX
         ihc40vv8pX2OoWk+APbHcwzOtOyUq1c6eDyT14hLDa6wOizFXw5TW3mpQtvlL1sG2Qbr
         +rQv32rrSI4p1vJGErgRJ0au2YTjS/tnBuwPuAhDvsFz7LcjmZhRLoAhKqkEQedTHlNh
         4n0yRhU1f8z8pEY8GBQOi8IIlnt6lDs0q6db6lhunbC/uTIV3uUd+mOeq7GCcU6JNny4
         JGmw==
X-Gm-Message-State: AOJu0YxikApHMrR0FOd9UogRKNKRxZqrascgEPz1gNaXS1bzu1Xz/Dnb
	MRAneH3scEfO66S8JFgjUjwczsnXWRlJzyYxOoaiUfoaQhICSfFjljsUuB3b/Q==
X-Gm-Gg: ASbGnctyPNXKMlHkRtv6c2j4SayRyh38n1+QOjKiEFgcNNBY80R3L26lH+ooyMAQbUY
	tNPsfTX3PQ+dHByO7mzpMzGEJuiKMU9WQXmNrKjgmVr4B+3rtpj2qOFf9sVLBOy80dKlNG9uypu
	MC18ROOR/OGa9TYEUwplK+2GZOF4B+iwsXH2fLy/JT2iMdq29sF651uexwuaaUsmg/XaEtx+2i9
	TIOzS8xXzeNX9Mt/+xUUOmauXnJ8WLiEM0clriEvlayjgsnjym1RvFFKmNTZ3+wd+lqr0CR1FCM
	FvkdUoAiUYa18t7r0qX4/cmx1ptYSEWjLvVjwUIsSLRnMePY6R8G9NEmwefjymNYvw8G/RtKSZb
	/XJA6H4JWkRcZiQwjNw==
X-Google-Smtp-Source: AGHT+IH4gHHiOcNKmaJyl8xGv7otfroRllepUtnSAz3Afmf5TUkO+KT9AIeJUB3LPsq6yOit4+DnbQ==
X-Received: by 2002:a17:906:c408:b0:ad5:4919:6317 with SMTP id a640c23a62f3a-ad549196826mr1225561966b.49.1747843451176;
        Wed, 21 May 2025 09:04:11 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v3 12/14] xen/riscv: add external interrupt handling for hypervisor mode
Date: Wed, 21 May 2025 18:03:52 +0200
Message-ID: <30b7b5fe1b37b1360b9ba23b6fd0b9c90e0b7651.1747843009.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Implement functions necessarry to have working external interrupts in
hypervisor mode. The following changes are done:
  - Add a common function intc_handle_external_irq() to call APLIC specific
    function to handle an interrupt.
  - Update do_trap() function to handle IRQ_S_EXT case; add the check to catch
    case when cause of trap is an interrupt.
  - Add handle_interrrupt() member to intc_hw_operations structure.
  - Enable local interrupt delivery for IMSIC by calling of
    imsic_ids_local_delivery() in imsic_init(); additionally introduce helper
    imsic_csr_write() to update IMSIC_EITHRESHOLD and IMSIC_EITHRESHOLD.
  - Enable hypervisor external interrupts.
  - Implement aplic_handler_interrupt() and use it to init ->handle_interrupt
    member of intc_hw_operations for APLIC.
  - Add implementation of do_IRQ() to dispatch the interrupt.

The current patch is based on the code from [1].

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V3:
 - Add ASSERT(spin_is_locked(&desc->lock)) to aplic_set_irq_type().
 - Fix code style for switch () in aplic_set_irq_type().
 - Drop fallthrough between "case IRQ_TYPE_NONE: case IRQ_TYPE_INVALID:" as there
   is no other statements in "case IRQ_TYPE_NONE".
 - Add Acked-by: Jan Beulich .
---
Changes in V2:
 - use BIT() macros instead of 1UL << bit_num in aplic.c.
 - Drop passing of a cause to aplic_handle_interrupt() function. And update
   prototype of handle_interrupt() callback.
 - Drop ASSERT() in intc_handle_external_irqs() as it is useless.
 - Code style fixes.
 - Drop cause argument for intc_handle_external_irqs().
 - Update the commit message: drop words that imsic_ids_local_delivery() is
   implemented in this patch, it is only called.
 - Add cf_check for aplic_handle_interrupt(), aplic_set_irq_type().
 - Move forward declarations in asm/intc.h up.
 - Use plain C operator instead if {clear,set}_bit() for desc->status as it
   is always used under spinlock().
 - use writel() for writing to APLIC's sourcecfg in aplic_set_irq_type().
---
 xen/arch/riscv/aplic.c             | 71 ++++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/aplic.h |  7 +++
 xen/arch/riscv/include/asm/imsic.h |  1 +
 xen/arch/riscv/include/asm/intc.h  |  6 +++
 xen/arch/riscv/include/asm/irq.h   |  6 ++-
 xen/arch/riscv/intc.c              |  5 +++
 xen/arch/riscv/irq.c               | 47 ++++++++++++++++++++
 xen/arch/riscv/traps.c             | 19 ++++++++
 8 files changed, 161 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index f48937ccc6..5415471680 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,6 +9,7 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -212,6 +213,71 @@ static void aplic_set_irq_affinity(struct irq_desc *desc, const cpumask_t *mask)
     spin_unlock(&aplic.lock);
 }
 
+static void cf_check aplic_handle_interrupt(struct cpu_user_regs *regs)
+{
+    /* disable to avoid more external interrupts */
+    csr_clear(CSR_SIE, BIT(IRQ_S_EXT, UL));
+
+    /* clear the pending bit */
+    csr_clear(CSR_SIP, BIT(IRQ_S_EXT, UL));
+
+    /* dispatch the interrupt */
+    do_IRQ(regs, csr_swap(CSR_STOPEI, 0) >> TOPI_IID_SHIFT);
+
+    /* enable external interrupts */
+    csr_set(CSR_SIE, BIT(IRQ_S_EXT, UL));
+}
+
+static void cf_check aplic_set_irq_type(struct irq_desc *desc, unsigned int type)
+{
+    /*
+    * Interrupt 0 isn't possible based on the spec:
+    *   Each of an APLIC’s interrupt sources has a fixed unique identity number in the range 1 to N,
+    *   where N is the total number of sources at the APLIC. The number zero is not a valid interrupt
+    *   identity number at an APLIC. The maximum number of interrupt sources an APLIC may support
+    *   is 1023.
+    *
+    * Thereby interrupt 1 will correspond to bit 0 in sourcecfg[] register,
+    * interrupt 2 ->sourcecfg[1] and so on.
+    *
+    * And that is the reason why we need -1.
+    */
+    unsigned int irq_bit = desc->irq - 1;
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+    spin_lock(&aplic.lock);
+
+    switch ( type )
+    {
+    case IRQ_TYPE_EDGE_RISING:
+        writel(APLIC_SOURCECFG_SM_EDGE_RISE, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_EDGE_FALLING:
+        writel(APLIC_SOURCECFG_SM_EDGE_FALL, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_LEVEL_HIGH:
+        writel(APLIC_SOURCECFG_SM_LEVEL_HIGH, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_LEVEL_LOW:
+        writel(APLIC_SOURCECFG_SM_LEVEL_LOW, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    case IRQ_TYPE_NONE:
+    case IRQ_TYPE_INVALID:
+        writel(APLIC_SOURCECFG_SM_INACTIVE, &aplic.regs->sourcecfg[irq_bit]);
+        break;
+
+    default:
+        panic("%s: APLIC doesnt support IRQ type: 0x%x?\n", __func__, type);
+    }
+
+    spin_unlock(&aplic.lock);
+}
+
 static const hw_irq_controller aplic_xen_irq_type = {
     .typename     = "aplic",
     .startup      = aplic_irq_startup,
@@ -225,6 +291,8 @@ static struct intc_hw_operations __ro_after_init aplic_ops = {
     .info                = &aplic_info,
     .init                = aplic_init,
     .host_irq_type       = &aplic_xen_irq_type,
+    .handle_interrupt    = aplic_handle_interrupt,
+    .set_irq_type        = aplic_set_irq_type,
 };
 
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
@@ -264,6 +332,9 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     register_intc_ops(&aplic_ops);
 
+    /* Enable supervisor external interrupt */
+    csr_set(CSR_SIE, BIT(IRQ_S_EXT, UL));
+
     return 0;
 }
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index a814a36a82..ef5b1d3e85 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -18,6 +18,13 @@
 #define APLIC_DOMAINCFG_IE      BIT(8, UL)
 #define APLIC_DOMAINCFG_DM      BIT(2, UL)
 
+#define APLIC_SOURCECFG_SM_INACTIVE     0x0
+#define APLIC_SOURCECFG_SM_DETACH       0x1
+#define APLIC_SOURCECFG_SM_EDGE_RISE    0x4
+#define APLIC_SOURCECFG_SM_EDGE_FALL    0x5
+#define APLIC_SOURCECFG_SM_LEVEL_HIGH   0x6
+#define APLIC_SOURCECFG_SM_LEVEL_LOW    0x7
+
 #define APLIC_TARGET_HART_IDX_SHIFT 18
 
 struct aplic_regs {
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index a0eba55f99..4973016cd8 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -12,6 +12,7 @@
 #define ASM__RISCV__IMSIC_H
 
 #include 
+#include 
 #include 
 
 #define IMSIC_MMIO_PAGE_SHIFT   12
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 1a88505518..b11b26addd 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -12,6 +12,7 @@ enum intc_version {
     INTC_APLIC,
 };
 
+struct cpu_user_regs;
 struct irq_desc;
 
 struct intc_info {
@@ -35,6 +36,9 @@ struct intc_hw_operations {
     void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
     /* Set IRQ priority */
     void (*set_irq_priority)(struct irq_desc *desc, unsigned int priority);
+
+    /* handle external interrupt */
+    void (*handle_interrupt)(struct cpu_user_regs *regs);
 };
 
 void intc_preinit(void);
@@ -45,4 +49,6 @@ void intc_init(void);
 
 void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
 
+void intc_handle_external_irqs(struct cpu_user_regs *regs);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 84c3c2904d..94151eb083 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -33,16 +33,20 @@ struct arch_irq_desc {
     unsigned int type;
 };
 
+struct cpu_user_regs;
+struct dt_device_node;
+
 static inline void arch_move_irqs(struct vcpu *v)
 {
     BUG_ON("unimplemented");
 }
 
-struct dt_device_node;
 int platform_get_irq(const struct dt_device_node *device, int index);
 
 void init_IRQ(void);
 
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq);
+
 #endif /* ASM__RISCV__IRQ_H */
 
 /*
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index f2823267a9..ea317aea5a 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -50,6 +50,11 @@ static void intc_set_irq_priority(struct irq_desc *desc, unsigned int priority)
         intc_hw_ops->set_irq_priority(desc, priority);
 }
 
+void intc_handle_external_irqs(struct cpu_user_regs *regs)
+{
+    intc_hw_ops->handle_interrupt(regs);
+}
+
 void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
 {
     ASSERT(desc->status & IRQ_DISABLED);
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index 669ef3ae9e..466f1b4ba9 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -11,6 +11,10 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
+#include 
 
 static irq_desc_t irq_desc[NR_IRQS];
 
@@ -90,3 +94,46 @@ void __init init_IRQ(void)
     if ( init_irq_data() < 0 )
         panic("initialization of IRQ data failed\n");
 }
+
+/* Dispatch an interrupt */
+void do_IRQ(struct cpu_user_regs *regs, unsigned int irq)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action;
+
+    irq_enter();
+
+    spin_lock(&desc->lock);
+
+    if ( desc->handler->ack )
+        desc->handler->ack(desc);
+
+    if ( desc->status & IRQ_DISABLED )
+        goto out;
+
+    desc->status |= IRQ_INPROGRESS;
+
+    action = desc->action;
+
+    spin_unlock_irq(&desc->lock);
+
+#ifndef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    action->handler(irq, action->dev_id);
+#else
+    do {
+        action->handler(irq, action->dev_id);
+        action = action->next;
+    } while ( action );
+#endif /* CONFIG_IRQ_HAS_MULTIPLE_ACTION */
+
+    spin_lock_irq(&desc->lock);
+
+    desc->status &= ~IRQ_INPROGRESS;
+
+ out:
+    if ( desc->handler->end )
+        desc->handler->end(desc);
+
+    spin_unlock(&desc->lock);
+    irq_exit();
+}
diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c
index ea3638a54f..f061004d83 100644
--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -128,6 +129,24 @@ void do_trap(struct cpu_user_regs *cpu_regs)
         }
         fallthrough;
     default:
+        if ( cause & CAUSE_IRQ_FLAG )
+        {
+            /* Handle interrupt */
+            unsigned long icause = cause & ~CAUSE_IRQ_FLAG;
+
+            switch ( icause )
+            {
+            case IRQ_S_EXT:
+                intc_handle_external_irqs(cpu_regs);
+                break;
+
+            default:
+                break;
+            }
+
+            break;
+        }
+
         do_unexpected_trap(cpu_regs);
         break;
     }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:04:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:04:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992154.1376045 (Exim 4.92)
	(envelope-from )
	id 1uHlvV-0007wS-GZ; Wed, 21 May 2025 16:04:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992154.1376045; Wed, 21 May 2025 16: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 1uHlvV-0007uS-7r; Wed, 21 May 2025 16:04:17 +0000
Received: by outflank-mailman (input) for mailman id 992154;
 Wed, 21 May 2025 16:04:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvT-0004Wm-Qp
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:15 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3d702837-365d-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 18:04:14 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-601fb2b7884so5505590a12.2
 for ; Wed, 21 May 2025 09:04:14 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09: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" 
X-Inumbo-ID: 3d702837-365d-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843453; x=1748448253; 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;
        bh=mnu64s57ZUL2GkbK8NSRVCu3wg1knPSgvCDSoN2TG7w=;
        b=c2ulDGUUJYxEIQfBuZbMGM5qTI6rinRZ49vUQOYujNqN9UQ1Yft+Nt0+Fs7C8wLJL7
         d5ojoStVSqj08RS2QDpumvrBhEOcIcYR0CtC6eXfZJmDCipvk3H/dL+MKNfFyUKw6eOg
         u6Hp3VJtWfuokr7wE3K+yM9boAeGbJKTn+i222HiISw0y5TzFZNoNnd3YPOXEX/DYw77
         U6hSLW2EaVxp3QhwYlEWWaWkXhbD3dBx8w2ySkue1sj+4RKbucn0xL4IUUyhzynYAz6d
         YpRA5C6aVWgsI9ABDviWgIeDQ/CYMyppCFXhP0CyiMgGDbG/OTj8wCQ5/esJo9/4QBiL
         dtpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843453; x=1748448253;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=mnu64s57ZUL2GkbK8NSRVCu3wg1knPSgvCDSoN2TG7w=;
        b=g2AeBNyWrC6sbz+HN6/KUknMrpPnRAiZRRTi5Q9xOqMhtCro6UsayVBrA7B3QQF6Qv
         0AYwLwqpLMD0+2NEEM0h+zHh83PP4uqBMhkjc2eFLJ0+Nby4FO7bLWMMFYjvIWE6xTdh
         6Zs9SKGz/h988SN10kMbR6KRNkeYctvPT5Lyjex93nSVHN9KteRI1VDlaK3VJvEVbNb9
         zl/2TR0/mS3ANXj1p/A+a+wPZAju7Czm04wwtz5WMqZ6E6lDO41SxBYhX974UR/juFDj
         V0sX7vH8u+oskgd+bE1T83MwO+pfzvjn+kuSY25yCosRGNE2kGVteOrtK7kxzt5fimuo
         m/cQ==
X-Gm-Message-State: AOJu0YxwYViVCW6ar9kGKD42ruqfmURTYPNTixGTG23K68oWAk2tXC4n
	0KNWoJMvEaxL5iLaIWsI3JnRBxHmZMHXNuhq13LMa2QhKWHMmVa0Lv7cTJOYpA==
X-Gm-Gg: ASbGncu2H5JxSG76Zi5ZilX/k3K2FhSzm2pl69VIxbh3a05ys7cjBFpxcTlWqDtHyq7
	JrGq00MXb6Aewp3CtsmFAKUz2MP5qoOQPE7HYdEz8iJ+5EBRPDLcurM4tXOuqx9+3ZBn/FUGWzJ
	YmcZNAWB8VYaTsbNILL6EQX6styYOP8Gq6Rn0F8PiXiFjHDGTq1v5KLPtRj4oCCmWa3Cp8NLzGa
	ZKSBZaoZuAPVXseEIhBBxXsnVpopsRBkwm0Uc3KxHT9Ox1CWsUkgX2Q+VMIS4PoQZ40vr17HFf3
	z+9GF/M0Y6q2/eu/EfX8ZYrqdaYnN49hkaQ2U/azvbv9pl0rQYB/ArN32WotsXqNnL22hbCsSky
	s8NCHedJzye93Zxsdjw==
X-Google-Smtp-Source: AGHT+IGunMgZiri1Ev5kZ3w9ZTII3G+8c7DPfjfcl25jVSc2uIWoNuARjTbhoI0T2M9oflC+5lXPDg==
X-Received: by 2002:a17:907:7da2:b0:ad2:2ef3:cc1b with SMTP id a640c23a62f3a-ad536b7bd28mr1899159666b.7.1747843453074;
        Wed, 21 May 2025 09:04:13 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 14/14] xen/riscv: add basic UART support
Date: Wed, 21 May 2025 18:03:54 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Update Kconfig to select GENERIC_UART_INIT for basic UART init ( find a dt node
and call device specific device_init() ).

Drop `default n if RISCV` statement for config HAS_NS16550 as now ns16550 is
ready to be compiled and used by RISC-V. Also, make the config user selectable
for everyone except X86.

Initialize a minimal amount of stuff to have UART and Xen console:
 - Initialize uart by calling uart_init().
 - Initialize Xen console by calling console_init_{pre,post}irq().
 - Initialize timer and its internal lists which are used by
   init_timer() which is called by ns16550_init_postirq(); otherwise
   "Unhandled exception: Store/AMO Page Fault" occurs.
 - Enable local interrupt to recieve an input from UART

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in v3:
 - Drop inclusion of  as nothing in setup.c requires it.
 - Add Acked-by: Jan Beulich .
---
Changes in v2:
 - Drop #include  in setup.c, isn't needed anymore.
 - Drop call of percpu_init_areas() as it was needed when I used polling
   mode for UART,  for this case percpu is used to receive serial port info:
     struct serial_port *port = this_cpu(poll_port);
   So percpu isn't really needed at the current development state.
 - Make HAS_NS16550 user selectable for everyone, except X86.
 - Update the commit message.
---
 xen/arch/riscv/Kconfig   |  1 +
 xen/arch/riscv/setup.c   | 12 ++++++++++++
 xen/drivers/char/Kconfig |  3 +--
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 62c5b7ba34..96bef90751 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -2,6 +2,7 @@ config RISCV
 	def_bool y
 	select FUNCTION_ALIGNMENT_16B
 	select GENERIC_BUG_FRAME
+	select GENERIC_UART_INIT
 	select HAS_DEVICE_TREE
 	select HAS_PMAP
 	select HAS_UBSAN
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 0e7398159c..a17096bf02 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -4,12 +4,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -134,8 +137,17 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     intc_preinit();
 
+    uart_init();
+    console_init_preirq();
+
     intc_init();
 
+    timer_init();
+
+    local_irq_enable();
+
+    console_init_postirq();
+
     printk("All set up\n");
 
     machine_halt();
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index e6e12bb413..8e49a52c73 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -2,8 +2,7 @@ config GENERIC_UART_INIT
 	bool
 
 config HAS_NS16550
-	bool "NS16550 UART driver" if ARM
-	default n if RISCV
+	bool "NS16550 UART driver" if !X86
 	default y
 	help
 	  This selects the 16550-series UART support. For most systems, say Y.
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:10:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:10:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992220.1376066 (Exim 4.92)
	(envelope-from )
	id 1uHm1o-0004q0-FH; Wed, 21 May 2025 16:10:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992220.1376066; Wed, 21 May 2025 16:10:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHm1o-0004pt-Cd; Wed, 21 May 2025 16:10:48 +0000
Received: by outflank-mailman (input) for mailman id 992220;
 Wed, 21 May 2025 16:10:47 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uHm1m-0004kc-Ut
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:10:46 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uHm1l-0062hr-29;
 Wed, 21 May 2025 16:10:45 +0000
Received: from [15.248.2.235] (helo=[10.24.67.107])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uHm1l-0074CM-0W;
 Wed, 21 May 2025 16:10: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=A5vMC1ohmzupjDbGzo04CEdKXoiwWkMzOtbB9xCtnzQ=; b=E0ClzlH9mqYoQ/iT+DNhxnrXtS
	uOC8XFbOcVddLqlu3mn7gx5OHonsrYbLjiZYJm7F6olwTB34DwV4D5+4FW0KVeltkcvVb2yTvM972
	FeY5bz/JkY58PJpCYXnca9GsfxsvTGdzMhr8ZDIsSPrp44QLhNppk9hQIzUC4hLxbEk4=;
Message-ID: <9a9682aa-2888-47f5-a985-52e95bf9f9a7@xen.org>
Date: Wed, 21 May 2025 17:10:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/gnttab: do not implement GNTTABOP_cache_flush
Content-Language: en-GB
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
 Community Manager ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250521091225.84597-1-roger.pau@citrix.com>
From: Julien Grall 
In-Reply-To: <20250521091225.84597-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Roger,

On 21/05/2025 10:12, Roger Pau Monne wrote:
> The current underlying implementation of GNTTABOP_cache_flush on x86 won't
> work as expected.  The provided {clean,invalidate}_dcache_va_range()
> helpers only do a local pCPU cache flush, so the cache of previous pCPUs
> where the vCPU might have run are not flushed.
> 
> However instead of attempting to fix this, make the GNTTABOP_cache_flush
> operation only available to ARM.  There are no known users on x86, the
> implementation is broken, and other architectures don't have grant-table
> support yet.
> 
> With that operation not implemented on x86, the related
> {clean,invalidate}_dcache_va_range() helpers can also be removed.
> 
> Fixes: f62dc81c2df7 ("x86: introduce more cache maintenance operations")
> Fixes: 18e8d22fe750 ("introduce GNTTABOP_cache_flush")
> Signed-off-by: Roger Pau Monné 
> Reviewed-by: Jan Beulich 
> Reviewed-By: Oleksii Kurochko

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:10:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:10:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992217.1376056 (Exim 4.92)
	(envelope-from )
	id 1uHm1m-0004Z7-50; Wed, 21 May 2025 16:10:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992217.1376056; Wed, 21 May 2025 16:10:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHm1m-0004Z0-2S; Wed, 21 May 2025 16:10:46 +0000
Received: by outflank-mailman (input) for mailman id 992217;
 Wed, 21 May 2025 16:10:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHlvU-0004XB-Eg
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:04:16 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3eae0dbe-365d-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:04:16 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-60179d8e65fso3006359a12.0
 for ; Wed, 21 May 2025 09:04:16 -0700 (PDT)
Received: from fedora.. (user-109-243-64-38.play-internet.pl. [109.243.64.38])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d502736sm9152513a12.25.2025.05.21.09.04.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:04: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" 
X-Inumbo-ID: 3eae0dbe-365d-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747843455; x=1748448255; 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;
        bh=JlWbz8bLXM971n4ELjNA8FOn3nNYfb72U/n4kfm36CE=;
        b=Z3yHxa2yZ+JqbV2x2QrfwdUaISVrvbE/uI9zQxqn9w14GEgkGrQJQeX117q/pXQQKW
         mUONbn6sFd/uyOXh1ODngAb0dDK4PUSBLA2KKcc0we8BXF+PjIenf7zG1l79EktMFnRW
         YJWnCnNvMG4d+uFM+BXEBrsBUFM7YEzs6l4jbRUWigzAtUdOmrKHq2o7WAYxDeMQikK6
         AV6UT4OV1dSl3hBwrNOZXPB0qFJH+M58tnnfKX1z91JjM8r/sP1fs5bf9kawYmDDgKh7
         8wu+HdtXjcv6a4psGDyk1XpKnr3XIPW1F8x2gCsWgA2y+0Sz71q/l1ONI5hIQJnLq4v4
         5e3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747843455; x=1748448255;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=JlWbz8bLXM971n4ELjNA8FOn3nNYfb72U/n4kfm36CE=;
        b=se7hQ6MDip/Xqa7HeX7s7wAxxiEJ82NBeKTiLZz4HjPqfSHkpv55RYGleLsyVvHr5o
         EgXzKsQPdSoXukKUJBaJthFRkAgI7qjBJraRoSJeota6SwNPfUbm8CJpaE11A3mEzRY/
         ZrF0CWCzScH9+3Xuo9O4wUAyilTVssS/Qj/8SSK9S9K88PqL5Z0d1g1nOSVomk9/8BpK
         //4GcwtQQu61oCT097qWwWrhOV8PMNJDIjPT5yI/SOMUP4cGil7ysdUbH3PK71CEC2F6
         Y3rIqUSlK9Rz8+3BgrXfMhkYOdEjNMvsKlKeAmDmAVtyonS+39oZDpOThee5BR38mnPL
         iZcQ==
X-Gm-Message-State: AOJu0YxIFH1Z1R6U79UgHU1sMFPNRbbQ4zjXkL93b5cH6rAP1H69VdkV
	PziXGx527errBOiHpO5QaIRCB/P9JcSnABgRmG7XUnYyYWtnq+Tw7zrq9gBRZQ==
X-Gm-Gg: ASbGnctL+WzeqAS5peot+qEdZmNbZqV/LId/xB/DWDy/fm6SfJYR0NdeO7PSjrJt5N3
	4IxjkjDQ87QlnkoYMeuoZlIpppuX32v5t1niVen2P9oxLpUbsjnpcgxVC08UQKaHGX04fChdBFj
	aliVN3njk93WXC/YrN4MTJLGm9ktdgIcBgzO2RUsuJDLjrN7VlsgNQB9FIDcmxWKSSKobJh1av+
	tj6pDU7BaK48UxwYkJgWNzFvKThiMmMcOn6NDX7QWj08nCuBlgZMC1pWSpzwc6zpYYlO3Ri4zlL
	2tpDisvA2/3GhWguQlLIa9vOIldbpF0LHp6OdSYoUwWmfUi3u+w0xFpzZWSg15/E6batO46uGxK
	NBKTkBOPsiCyX7yaWuQ==
X-Google-Smtp-Source: AGHT+IFvXA5o4dcbptWPK9BfnqNxYlHv9zOXStdBdVOGxjEE1H2yKuHdQ4hApBcrS7rYn3vsPx8Svg==
X-Received: by 2002:a05:6402:848:b0:602:4405:7779 with SMTP id 4fb4d7f45d1cf-60244057a3amr1383333a12.20.1747843452136;
        Wed, 21 May 2025 09:04:12 -0700 (PDT)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Romain Caritey 
Subject: [PATCH v3 13/14] xen/riscv: implement setup_irq()
Date: Wed, 21 May 2025 18:03:53 +0200
Message-ID: <5c7105aaf0a249cb86321ff58796658f69ad0f2d.1747843009.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce support for IRQ setup on RISC-V by implementing setup_irq() and
__setup_irq(), adapted and extended from an initial implementation by [1].

__setup_irq() does the following:
  - Sets up an IRQ action.
  - Validates that shared IRQs have non-NULL `dev_id` and are only used when
    existing handlers allow sharing.
  - Uses smp_wmb() to enforce memory ordering after assigning desc->action
    to ensure visibility before enabling the IRQ.
  - Supports multi-action setups via CONFIG_IRQ_HAS_MULTIPLE_ACTION.

setup_irq() does the following:
  - Converts IRQ number to descriptor and acquires its lock.
  - Rejects registration if the IRQ is already assigned to a guest domain,
    printing an error.
  - Delegates the core setup to __setup_irq().
  - On first-time setup, disables the IRQ, routes it to Xen using
    intc_route_irq_to_xen(), sets default CPU affinity (current CPU),
    calls the handler’s startup routine, and finally enables the IRQ.

irq_set_affinity() invokes set_affinity() callback from the IRQ handler
if present.

Defined IRQ_NO_PRIORITY as default priority used when routing IRQs to Xen.

[1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/7390e2365828b83e27ead56b03114a56e3699dd5

Co-developed-by: Romain Caritey 
Signed-off-by: Oleksii Kurochko 
---
Changes in V3:
 - Nothing changed. Only rebase.
---
Changes in V2:
 - Added implenmtation of aplic_set_irq_type() as it is going to be used in
   this commit. And also, update the implementation of it. Make default case
   of switch to do panic().
 - Move all forward declaration up  in asm/irq.h.
 - s/__setup_irq/_setup_irq.
 - Code style fixes.
 - Update commit message.
 - use smp_wmb() instead of smp_mb() in _setup_irq().
 - Drop irq_set_affinity().
 - Use plain C operator instead if {clear,set}_bit() for desc->status as it
   is always used under spinlock().
 - Drop set_bit(_IRQ_DISABLED, &desc->status) in setup_irq() as in the case
   when IRQ is setuped for a first time, desc->status should be already set
   to IRQ_DISABLED in init_one_irq_desc().
----
 xen/arch/riscv/include/asm/irq.h |  2 +
 xen/arch/riscv/irq.c             | 84 ++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+)

diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 94151eb083..f633636dc3 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -17,6 +17,8 @@
  */
 #define NR_IRQS 1024
 
+#define IRQ_NO_PRIORITY 0
+
 /* TODO */
 #define nr_irqs 0U
 #define nr_static_irqs 0
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index 466f1b4ba9..25d3295002 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -63,6 +64,89 @@ int platform_get_irq(const struct dt_device_node *device, int index)
     return dt_irq.irq;
 }
 
+static int _setup_irq(struct irq_desc *desc, unsigned int irqflags,
+                      struct irqaction *new)
+{
+    bool shared = irqflags & IRQF_SHARED;
+
+    ASSERT(new != NULL);
+
+    /*
+     * Sanity checks:
+     *  - if the IRQ is marked as shared
+     *  - dev_id is not NULL when IRQF_SHARED is set
+     */
+    if ( desc->action != NULL && (!(desc->status & IRQF_SHARED) || !shared) )
+        return -EINVAL;
+    if ( shared && new->dev_id == NULL )
+        return -EINVAL;
+
+    if ( shared )
+        desc->status |= IRQF_SHARED;
+
+#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    new->next = desc->action;
+#endif
+
+    desc->action = new;
+    smp_wmb();
+
+    return 0;
+}
+
+int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new)
+{
+    int rc;
+    unsigned long flags;
+    struct irq_desc *desc = irq_to_desc(irq);
+    bool disabled;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    disabled = (desc->action == NULL);
+
+    if ( desc->status & IRQ_GUEST )
+    {
+        spin_unlock_irqrestore(&desc->lock, flags);
+        /*
+         * TODO: would be nice to have functionality to print which domain owns
+         *       an IRQ.
+         */
+        printk(XENLOG_ERR "ERROR: IRQ %u is already in use by a domain\n", irq);
+        return -EBUSY;
+    }
+
+    rc = _setup_irq(desc, irqflags, new);
+    if ( rc )
+        goto err;
+
+    /* First time the IRQ is setup */
+    if ( disabled )
+    {
+        /* Route interrupt to xen */
+        intc_route_irq_to_xen(desc, IRQ_NO_PRIORITY);
+
+        /*
+         * We don't care for now which CPU will receive the
+         * interrupt.
+         *
+         * TODO: Handle case where IRQ is setup on different CPU than
+         *       the targeted CPU and the priority.
+         */
+        desc->handler->set_affinity(desc, cpumask_of(smp_processor_id()));
+
+        desc->handler->startup(desc);
+
+        /* Enable irq */
+        desc->status &= ~IRQ_DISABLED;
+    }
+
+ err:
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    return rc;
+}
+
 int arch_init_one_irq_desc(struct irq_desc *desc)
 {
     desc->arch.type = IRQ_TYPE_INVALID;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:35:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:35:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992313.1376080 (Exim 4.92)
	(envelope-from )
	id 1uHmPN-0002Yd-Ch; Wed, 21 May 2025 16:35:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992313.1376080; Wed, 21 May 2025 16: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 1uHmPN-0002YW-9r; Wed, 21 May 2025 16:35:09 +0000
Received: by outflank-mailman (input) for mailman id 992313;
 Wed, 21 May 2025 16:35:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHmPM-0002YQ-30
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:35:08 +0000
Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com
 [2607:f8b0:4864:20::c2a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8d9e83f1-3661-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:35:07 +0200 (CEST)
Received: by mail-oo1-xc2a.google.com with SMTP id
 006d021491bc7-6060a70ba80so3801701eaf.2
 for ; Wed, 21 May 2025 09: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" 
X-Inumbo-ID: 8d9e83f1-3661-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747845306; x=1748450106; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4x3vNqKHty/ekIZpyczjpfexXrz7j5aLh2Uk1ezdOoU=;
        b=jAMGukLwpzlen9vywNYIaCq5yik0NFkedpwwEsVMMUSeJoiAiQKzGevKGpJjsAmBe+
         hc9cTNYNPNSXVog/jOIVytp8yOX/3ujpoeI6XGW9cg4I3qd1XX5p/vp3ooiE594iJrMn
         5mhleGx+Zhd7pr2bgCnzifLFZCukcj5VXHfPp41Vl+kCCEwp2G2WDD/2FYAHADl1u7NZ
         DgradL5Ot7o7CAbN5FvAdUJAB8tW582PADpIomisD5SbcTZmLQo8KG/qhFepTXOWsWH7
         H/hYFQqtKXgLDs5pJHdC8uxZ7jYRBf0VzBFOA16u+Kk3Elf8zMou22OW37AsklTbUHN+
         f9Aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747845306; x=1748450106;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4x3vNqKHty/ekIZpyczjpfexXrz7j5aLh2Uk1ezdOoU=;
        b=i97nVMRsKDgNXNsXajalOj/f74ys5CM5HyjD0fFxWnemyFgaYvz/3SEcRyqsdX83of
         UroGD9G6Jj6eLwIE1WXLVkEhN4NgGLUe+VaK05AKD91pBdkQX1Oy2HRDwD3VAUFvxqYk
         HqWe7jGrXsd2jmeGGHUYlN5KR400ynVDVml2ewNstJQN78EYOHZ6xI4fIbrWF4dOuCb+
         Oa7Jg4g3X4BNYQCGOf17aolFWTZ26cED8qoxqV5w3Ok2h14S31T/4xu1Eamcv85spkmr
         x3GMX4ty5arHCj5iyNPbKXRkd0xoEA7zOtu608KE63pWCrV8PPOdcOMfGCuWq8T1PxgR
         G6ww==
X-Gm-Message-State: AOJu0YxkYxV6DKhJsem4zgFWJSjX6nsG6648f5Xdx6o7I6GaZ4kj92tF
	EZGy5SgANKkXt4qCDH4xe2G5zhrgStbzBsJPBD8tkS/vTbqkPNidUSfTXovveA3LEGJM/m/24ao
	W9v1ntAnNFiwLWy8T9DPENvMNaVnAlbKKujk1CeBL2g==
X-Gm-Gg: ASbGnct9vtXM5kmtBfXD48J7eddhafvkHdsSxo1XTkO9zp3qvEfj1rdmAllitvElApO
	1dMABCGz5bqGlEdU53HgE+TQD8tl1zl/it0tp4IClbcwvr2xjbVhU9lrYyo75WTuD70a8y0Q4X6
	Nrc8wKQpSqglBBNpZxy6RWOTOj7YrtyU58phFEAv6nASqT
X-Google-Smtp-Source: AGHT+IF8g7EsQbMv7CNc9vwAwzbFvjLl+eRnmbaFdEyZUSPXkJZChdYTRsI9mcyo4PMi0N9wcJ9XDaoVTEYGIfzNFHI=
X-Received: by 2002:a05:6820:1843:b0:603:f973:1b6 with SMTP id
 006d021491bc7-609f37776a6mr13110333eaf.5.1747845305627; Wed, 21 May 2025
 09:35:05 -0700 (PDT)
MIME-Version: 1.0
References: 
 
  
In-Reply-To: 
From: Jens Wiklander 
Date: Wed, 21 May 2025 18:34:53 +0200
X-Gm-Features: AX0GCFsatMYqPOsFoX9YHhkyJ9T_H6KzZwP1CM55gu5cXLeJdczjyTlBOST4-no
Message-ID: 
Subject: Re: [PATCH v5 3/6] xen/arm: ffa: Introduce VM to VM support
To: Bertrand Marquis 
Cc: "xen-devel@lists.xenproject.org" , 
	Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Michal Orzel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, May 21, 2025 at 5:11=E2=80=AFPM Bertrand Marquis
 wrote:
>
> Hi Jens,
>
> > On 21 May 2025, at 16:54, Jens Wiklander  wr=
ote:
> >
> > Hi Bertrand,
> >
> > On Wed, Apr 16, 2025 at 9:40=E2=80=AFAM Bertrand Marquis
> >  wrote:
> >>
> >> Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
> >> between VMs.
> >> When activated list VMs in the system with FF-A support in part_info_g=
et.
> >>
> >> When VM to VM is activated, Xen will be tainted as Insecure and a
> >> message is displayed to the user during the boot as there is no
> >> filtering of VMs in FF-A so any VM can communicate or see any other VM
> >> in the system.
> >>
> >> WARNING: There is no filtering for now and all VMs are listed !!
> >>
> >> This patch is reorganizing the ffa_ctx structure to make clear which
> >> lock is protecting what parts.
> >>
> >> This patch is introducing a chain list of the ffa_ctx with a FFA Versi=
on
> >> negociated allowing to create the partinfo results for VMs without
> >> taking a lock on the global domain list in Xen.
> >>
> >> Signed-off-by: Bertrand Marquis 
> >> ---
> >> Changes in v5:
> >> - remove invalid comment about 1.1 firmware support
> >> - rename variables from d and dom to curr_d and dest_d (Julien)
> >> - add a TODO in the code for potential holding for long of the CPU
> >>  (Julien)
> >> - use an atomic global variable to store the number of VMs instead of
> >>  recomputing the value each time (Julien)
> >> - add partinfo information in ffa_ctx (id, cpus and 64bit) and create =
a
> >>  chain list of ctx. Use this chain list to create the partinfo result
> >>  without holding a global lock to prevent concurrency issues.
> >> - Move some changes in a preparation patch modifying partinfo for sps =
to
> >>  reduce this patch size and make the review easier
> >> Changes in v4:
> >> - properly handle SPMC version 1.0 header size case in partinfo_get
> >> - switch to local counting variables instead of *pointer +=3D 1 form
> >> - coding style issue with missing spaces in if ()
> >> Changes in v3:
> >> - break partinfo_get in several sub functions to make the implementati=
on
> >>  easier to understand and lock handling easier
> >> - rework implementation to check size along the way and prevent previo=
us
> >>  implementation limits which had to check that the number of VMs or SP=
s
> >>  did not change
> >> - taint Xen as INSECURE when VM to VM is enabled
> >> Changes in v2:
> >> - Switch ifdef to IS_ENABLED
> >> - dom was not switched to d as requested by Jan because there is alrea=
dy
> >>  a variable d pointing to the current domain and it must not be
> >>  shadowed.
> >> ---
> >> xen/arch/arm/tee/Kconfig        |  11 ++++
> >> xen/arch/arm/tee/ffa.c          |  47 +++++++++++++-
> >> xen/arch/arm/tee/ffa_partinfo.c |  95 ++++++++++++++++++++++++---
> >> xen/arch/arm/tee/ffa_private.h  | 112 ++++++++++++++++++++++++++------
> >> 4 files changed, 233 insertions(+), 32 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
> >> index c5b0f88d7522..88a4c4c99154 100644
> >> --- a/xen/arch/arm/tee/Kconfig
> >> +++ b/xen/arch/arm/tee/Kconfig
> >> @@ -28,5 +28,16 @@ config FFA
> >>
> >>          [1] https://developer.arm.com/documentation/den0077/latest
> >>
> >> +config FFA_VM_TO_VM
> >> +    bool "Enable FF-A between VMs (UNSUPPORTED)" if UNSUPPORTED
> >> +    default n
> >> +    depends on FFA
> >> +    help
> >> +      This option enables to use FF-A between VMs.
> >> +      This is experimental and there is no access control so any
> >> +      guest can communicate with any other guest.
> >> +
> >> +      If unsure, say N.
> >> +
> >> endmenu
> >>
> >> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> >> index 3bbdd7168a6b..c1c4c0957091 100644
> >> --- a/xen/arch/arm/tee/ffa.c
> >> +++ b/xen/arch/arm/tee/ffa.c
> >> @@ -118,6 +118,13 @@ void *ffa_tx __read_mostly;
> >> DEFINE_SPINLOCK(ffa_rx_buffer_lock);
> >> DEFINE_SPINLOCK(ffa_tx_buffer_lock);
> >>
> >> +struct list_head ffa_ctx_head;
> >> +/* Lock to protect addition/removal in ffa_ctx_head */
> >> +DEFINE_SPINLOCK(ffa_ctx_list_lock);
> >> +
> >> +#ifdef CONFIG_FFA_VM_TO_VM
> >> +atomic_t ffa_vm_count;
> >> +#endif
> >>
> >> /* Used to track domains that could not be torn down immediately. */
> >> static struct timer ffa_teardown_timer;
> >> @@ -160,10 +167,21 @@ static void handle_version(struct cpu_user_regs =
*regs)
> >>      */
> >>     if ( FFA_VERSION_MAJOR(vers) =3D=3D FFA_MY_VERSION_MAJOR )
> >>     {
> >> +        uint32_t old_vers =3D ACCESS_ONCE(ctx->guest_vers);
> >> +
> >>         if ( FFA_VERSION_MINOR(vers) > FFA_MY_VERSION_MINOR )
> >> -            ctx->guest_vers =3D FFA_MY_VERSION;
> >> +            ACCESS_ONCE(ctx->guest_vers) =3D FFA_MY_VERSION;
> >>         else
> >> -            ctx->guest_vers =3D vers;
> >> +            ACCESS_ONCE(ctx->guest_vers) =3D vers;
> >
> > What is the ACCESS_ONCE() scheme intended for?
> >
> >> +
> >> +        if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !old_vers )
> >
> > If handle_version() is called concurrently on two CPUs, it might be
> > possible for a context to be added twice.
> > How about a separate flag to indicate whether a context has been added
> > to the list?
>
> I wanted to avoid having guest_vers as atomic or introduce an other lock.
> But i think now that this is kind of impossible to avoid and this way to =
do
> it is wrong.
>
> I will take the context lock to do this processing to avoid this corner c=
ase
> and remove the ACCESS_ONCE to protect modifications to guest_vers:
>
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index b86c88cefa8c..306edb97863a 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -158,6 +158,7 @@ static void handle_version(struct cpu_user_regs *regs=
)
>      struct domain *d =3D current->domain;
>      struct ffa_ctx *ctx =3D d->arch.tee;
>      uint32_t vers =3D get_user_reg(regs, 1);
> +    uint32_t old_vers;
>
>      /*
>       * Guest will use the version it requested if it is our major and mi=
nor
> @@ -167,12 +168,14 @@ static void handle_version(struct cpu_user_regs *re=
gs)
>       */
>      if ( FFA_VERSION_MAJOR(vers) =3D=3D FFA_MY_VERSION_MAJOR )
>      {
> -        uint32_t old_vers =3D ACCESS_ONCE(ctx->guest_vers);
> +        spin_lock(&ctx->lock);
> +        old_vers =3D ctx->guest_vers;
>
>          if ( FFA_VERSION_MINOR(vers) > FFA_MY_VERSION_MINOR )
> -            ACCESS_ONCE(ctx->guest_vers) =3D FFA_MY_VERSION;
> +           ctx->guest_vers =3D FFA_MY_VERSION;
>          else
> -            ACCESS_ONCE(ctx->guest_vers) =3D vers;
> +           ctx->guest_vers =3D vers;
> +        spin_unlock(&ctx->lock);
>
>          if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !old_vers )
>          {
>
> What do you think ?

That works. It might be worth adding a comment that ctx->guest_vers is
accessed unlocked elsewhere, and why that is OK.

Cheers,
Jens


From xen-devel-bounces@lists.xenproject.org Wed May 21 16:54:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:54:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992340.1376091 (Exim 4.92)
	(envelope-from )
	id 1uHmhh-0006hA-UP; Wed, 21 May 2025 16:54:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992340.1376091; Wed, 21 May 2025 16:54: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 1uHmhh-0006h3-PZ; Wed, 21 May 2025 16:54:05 +0000
Received: by outflank-mailman (input) for mailman id 992340;
 Wed, 21 May 2025 16:54:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHmhg-0006gx-Gu
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:54:04 +0000
Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com
 [2001:4860:4864:20::2a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 312bd0c3-3664-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 18:54:00 +0200 (CEST)
Received: by mail-oa1-x2a.google.com with SMTP id
 586e51a60fabf-2db9e29d3bcso2046117fac.1
 for ; Wed, 21 May 2025 09: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" 
X-Inumbo-ID: 312bd0c3-3664-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747846439; x=1748451239; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jbHs+5nY9sp/4FUlljaXDfUYYdafIe7VtM5PIMYtNvQ=;
        b=O8mcFRYvk6x+o7IYxfGn8zBM2+HTVjxkc/jcn17moQ4JNifeiEv5oqqqkqY/4cvf2e
         v1qRlsXfeU7Vh8CklUy3VWfTpoCHBJpzti/HdB4Vhz08fCG31wn7pUYiZb4LXyB19D0R
         g+vAmidz1elNDbfqx9hu4rhiyldsuP+vPAsWRpt9xh8HUCcNaA3ZPnIXnK6IaQeymdHc
         DUJvjUKO5I8TNyjApcl86uz1kmjcgfDfNNWPLcE1AM5FWExO5YueSNjGVNm84xrGtzUA
         X9ROWncDxNr0P/yTtDWnYNjfUO25ZI6Hul2pc/kml6oz8e9t4q9SaSXKTDwAaprw4jQO
         LmWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747846439; x=1748451239;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jbHs+5nY9sp/4FUlljaXDfUYYdafIe7VtM5PIMYtNvQ=;
        b=IDwaLtYWLGRx+ZZ5NFMQBmuhIMy8b7iireGiQAxc9xGyaL4scMUYZol8uqI11ptLiQ
         L/GnFxzvjR2hIivInurWeUkCefl9qeIYTqzDMx5O5+3GCjSd4er3z74rAgU2eMP3uvJu
         xQBVbnFPoeMIS49MkeSVYHvUgysUTk8vj3LnUNhTLoAY4YWqMzCTu4F7RZgt8HRxKO4b
         CZ66Y27tPnPNrRCs041J8ZBhUIBJUppUyFLzYKgjebuMAYxouC0cTEozuWs6sw5yzlfK
         ozKN/yOQklMzvTauOIzaxeU0kUSHzMQdP5LfPQSEbz4/mN3Jo6Vrj/AHKvmm44dNsXKB
         r2nw==
X-Gm-Message-State: AOJu0YyjbIlPlR8hH+TOuSxxuK/tzC+uQAsEIRpVOtSik+pMSQ/PLSRY
	1UH3/ggVGQvf2rU0Uo/u9+ejfCis2lchcUOPsAh3KMQXskEjVIdERyexVqcpKeTSElW1lsWnCDe
	Y1XkKViXXeDR+7kKRsXvYORPn2SZ5jyYvXtlhQR8OoA==
X-Gm-Gg: ASbGncss15kY8E4jP7httPHDF/h/mbX6n9WQWqm84uk4KOO6xSs5y23aeD2AMv3+IIu
	t/NeCWNkrhjn1rPVQOgMcLKNsW9/6RtM+zptB5CGBMaKlNQtXDM+WWlxFIr6vstMeEajxnhHEQv
	bg1VyIOnobiiWJu/g4PRF1oIz8/I+3RgITrw==
X-Google-Smtp-Source: AGHT+IErp45iVYOCQvuZywNrTvp6HN8/ehvHQ/RjpNov1ey5jCy18yRv6uJsQ/JHlCOWVFFJl6TDJwYzv6UW8BQXBhc=
X-Received: by 2002:a05:6871:50c7:b0:29e:2caf:8cc with SMTP id
 586e51a60fabf-2e3c1fa7334mr12642844fac.37.1747846439193; Wed, 21 May 2025
 09:53:59 -0700 (PDT)
MIME-Version: 1.0
References:  <81ec9ce34c3990b02ec6427d95b6238445333b57.1744787720.git.bertrand.marquis@arm.com>
In-Reply-To: <81ec9ce34c3990b02ec6427d95b6238445333b57.1744787720.git.bertrand.marquis@arm.com>
From: Jens Wiklander 
Date: Wed, 21 May 2025 18:53:47 +0200
X-Gm-Features: AX0GCFttCTN8XoOGEuGwaCDV3kKZDkShiaEsTHPZyt_AzrXO7d5KwmSwGcgKO8s
Message-ID: 
Subject: Re: [PATCH v5 5/6] xen/arm: ffa: Add indirect message between VM
To: Bertrand Marquis 
Cc: xen-devel@lists.xenproject.org, 
	Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Michal Orzel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bertrand,

On Wed, Apr 16, 2025 at 9:40=E2=80=AFAM Bertrand Marquis
 wrote:
>
> Add support for indirect messages between VMs.
> This is only enabled if CONFIG_FFA_VM_TO_VM is selected.
>
> Signed-off-by: Bertrand Marquis 
> ---
> Changes in v5:
> - Prevent potential overflow in send2 handling (Julien)
> - Only use page_count with rx lock acquired
> - Fix an issue where send2 between VMs was not doing the copy from the
>   tx buffer but from a wrong location in the stack. This bug was
>   introduced in v4 when switching to a local copy for the header.
> Changes in v4:
> - Use a local copy of the message header to prevent a TOC/TOU possible
>   issue when using the payload size
> Changes in v3:
> - Move vm to vm indirect message handling in a sub function to simplify
>   lock handling and make implementation easier to read
> Changes in v2:
> - Switch ifdef to IS_ENABLED
> ---
>  xen/arch/arm/tee/ffa_msg.c | 115 ++++++++++++++++++++++++++++++++-----
>  1 file changed, 101 insertions(+), 14 deletions(-)
>
> diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
> index ee594e737fc7..35de260c013a 100644
> --- a/xen/arch/arm/tee/ffa_msg.c
> +++ b/xen/arch/arm/tee/ffa_msg.c
> @@ -88,43 +88,130 @@ out:
>                   resp.a7 & mask);
>  }
>
> +static int32_t ffa_msg_send2_vm(uint16_t dst_id, const void *src_buf,
> +                                struct ffa_part_msg_rxtx *src_msg)
> +{
> +    struct domain *dst_d;
> +    struct ffa_ctx *dst_ctx;
> +    struct ffa_part_msg_rxtx *dst_msg;
> +    int err;
> +    int32_t ret;
> +
> +    if ( dst_id =3D=3D 0 )
> +        /* FF-A ID 0 is the hypervisor, this is not valid */
> +        return FFA_RET_INVALID_PARAMETERS;
> +
> +    /* This is also checking that dest is not src */
> +    err =3D rcu_lock_live_remote_domain_by_id(dst_id - 1, &dst_d);
> +    if ( err )
> +        return FFA_RET_INVALID_PARAMETERS;
> +
> +    if ( dst_d->arch.tee =3D=3D NULL )
> +    {
> +        ret =3D FFA_RET_INVALID_PARAMETERS;
> +        goto out_unlock;
> +    }
> +
> +    dst_ctx =3D dst_d->arch.tee;
> +    if ( !dst_ctx->guest_vers )
> +    {
> +        ret =3D FFA_RET_INVALID_PARAMETERS;
> +        goto out_unlock;
> +    }
> +
> +    /* This also checks that destination has set a Rx buffer */
> +    ret =3D ffa_rx_acquire(dst_d);
> +    if ( ret )
> +        goto out_unlock;
> +
> +    /* we need to have enough space in the destination buffer */
> +    if ( (dst_ctx->page_count * FFA_PAGE_SIZE -
> +          sizeof(struct ffa_part_msg_rxtx)) < src_msg->msg_size )
> +    {
> +        ret =3D FFA_RET_NO_MEMORY;
> +        ffa_rx_release(dst_d);
> +        goto out_unlock;
> +    }
> +
> +    dst_msg =3D dst_ctx->rx;
> +
> +    /* prepare destination header */
> +    dst_msg->flags =3D 0;
> +    dst_msg->reserved =3D 0;
> +    dst_msg->msg_offset =3D sizeof(struct ffa_part_msg_rxtx);
> +    dst_msg->send_recv_id =3D src_msg->send_recv_id;
> +    dst_msg->msg_size =3D src_msg->msg_size;
> +
> +    memcpy(dst_ctx->rx + sizeof(struct ffa_part_msg_rxtx),
> +           src_buf + src_msg->msg_offset, src_msg->msg_size);
> +
> +    /* receiver rx buffer will be released by the receiver*/
> +
> +out_unlock:
> +    rcu_unlock_domain(dst_d);
> +    if ( !ret )
> +        ffa_raise_rx_buffer_full(dst_d);
> +
> +    return ret;
> +}
> +
>  int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs)
>  {
>      struct domain *src_d =3D current->domain;
>      struct ffa_ctx *src_ctx =3D src_d->arch.tee;
> -    const struct ffa_part_msg_rxtx *src_msg;
> +    struct ffa_part_msg_rxtx src_msg;
>      uint16_t dst_id, src_id;
>      int32_t ret;
>
> -    if ( !ffa_fw_supports_fid(FFA_MSG_SEND2) )
> -        return FFA_RET_NOT_SUPPORTED;
> +    BUILD_BUG_ON(sizeof(struct ffa_part_msg_rxtx) >=3D FFA_PAGE_SIZE);
>
>      if ( !spin_trylock(&src_ctx->tx_lock) )
>          return FFA_RET_BUSY;
>
> -    src_msg =3D src_ctx->tx;
> -    src_id =3D src_msg->send_recv_id >> 16;
> -    dst_id =3D src_msg->send_recv_id & GENMASK(15,0);
> +    /* create a copy of the message header */
> +    memcpy(&src_msg, src_ctx->tx, sizeof(src_msg));
>
> -    if ( src_id !=3D ffa_get_vm_id(src_d) || !FFA_ID_IS_SECURE(dst_id) )
> +    src_id =3D src_msg.send_recv_id >> 16;
> +    dst_id =3D src_msg.send_recv_id & GENMASK(15,0);
> +
> +    if ( src_id !=3D ffa_get_vm_id(src_d) )
>      {
>          ret =3D FFA_RET_INVALID_PARAMETERS;
> -        goto out_unlock_tx;
> +        goto out;
>      }
>
>      /* check source message fits in buffer */
> -    if ( src_ctx->page_count * FFA_PAGE_SIZE <
> -         src_msg->msg_offset + src_msg->msg_size ||
> -         src_msg->msg_offset < sizeof(struct ffa_part_msg_rxtx) )
> +    if ( src_msg.msg_offset < sizeof(struct ffa_part_msg_rxtx) ||
> +            src_msg.msg_size =3D=3D 0 ||
> +            src_msg.msg_offset > src_ctx->page_count * FFA_PAGE_SIZE ||
> +            src_msg.msg_size > (src_ctx->page_count * FFA_PAGE_SIZE -
> +                                src_msg.msg_offset) )
>      {
>          ret =3D FFA_RET_INVALID_PARAMETERS;
> -        goto out_unlock_tx;
> +        goto out;
>      }
>
> -    ret =3D ffa_simple_call(FFA_MSG_SEND2,
> +    if ( FFA_ID_IS_SECURE(dst_id) )
> +    {
> +        /* Message for a secure partition */
> +        if ( !ffa_fw_supports_fid(FFA_MSG_SEND2) )
> +        {
> +            ret =3D FFA_RET_NOT_SUPPORTED;
> +            goto out;
> +        }
> +
> +        ret =3D ffa_simple_call(FFA_MSG_SEND2,
>                            ((uint32_t)ffa_get_vm_id(src_d)) << 16, 0, 0, =
0);

Please align with the opening '(' at the row above.

Other than that:
Reviewed-by: Jens Wiklander 

Cheers,
Jens

> +    }
> +    else if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> +    {
> +        /* Message for a VM */
> +        ret =3D ffa_msg_send2_vm(dst_id, src_ctx->tx, &src_msg);
> +    }
> +    else
> +        ret =3D FFA_RET_INVALID_PARAMETERS;
>
> -out_unlock_tx:
> +out:
>      spin_unlock(&src_ctx->tx_lock);
>      return ret;
>  }
> --
> 2.47.1
>


From xen-devel-bounces@lists.xenproject.org Wed May 21 16:56:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:56:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992347.1376100 (Exim 4.92)
	(envelope-from )
	id 1uHmjk-0007Eg-7T; Wed, 21 May 2025 16:56:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992347.1376100; Wed, 21 May 2025 16: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 1uHmjk-0007EZ-4v; Wed, 21 May 2025 16:56:12 +0000
Received: by outflank-mailman (input) for mailman id 992347;
 Wed, 21 May 2025 16:56:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHmjj-0007EC-Eh
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:56:11 +0000
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com
 [2607:f8b0:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7d29f359-3664-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 18:56:08 +0200 (CEST)
Received: by mail-pg1-x531.google.com with SMTP id
 41be03b00d2f7-b26f01c638fso5239767a12.1
 for ; Wed, 21 May 2025 09:56:08 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 98e67ed59e1d1-30f36366219sm3894848a91.6.2025.05.21.09.56.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:56: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" 
X-Inumbo-ID: 7d29f359-3664-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747846566; x=1748451366; 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;
        bh=eliR2nkb7Vuh2naOk8wjTkjUYBIZCqckOsAyoeIiAw8=;
        b=MY7nZ2oNdtu04gMfZBm0BzUKOUrZSh/GPOUMjkRvW3bVOEniUi2eOuATmUOUGCyAzm
         wI/GFrV9qw9UznbXqTX5+DATmcDDQk5QqhXEHZo9eDUlWrFUXJ9qiKAUQy2p1JOc0FiD
         51g5fbY/lhx49rlWOgrMlW5OqdIsIgPTYA9lg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747846566; x=1748451366;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=eliR2nkb7Vuh2naOk8wjTkjUYBIZCqckOsAyoeIiAw8=;
        b=bUNbLmCqg4hrdvT7as23oetC10KHipaYBg8anv244FGzcDHeTmaSTDh19P8hGvV688
         tytGB7c41jVeq7nQWqvKXuLv61V7SpvNMA2cR1iJDlkWQAcUDYCN6MDPSOhDdbp+nwZ6
         2XdxpKraH8YRrGyr0kL3xJusF2oX1ZhD7fMqa2spj70PeVPxzlMyv4igUSbNjco57abu
         mRmg/uev/UvQlhdkablbFUQ5wRpjL1JsWNflnjJMgIkoNY0OO2UTf7xzFMHEJBqEZEbz
         aHa1VRlry3Pgi7b8QPU/ojb1NHOIha4JiYq97OI51/eUhJMmSCqEkYgdhJxxIHIh16FA
         ChyQ==
X-Gm-Message-State: AOJu0YzbFY/hAyF/7G/sa0Rg4kK0BOY2bPRHh+05XcBEeE7TENP9EI0N
	3l3rMgyI4MpC57IOZzOCZKe0QzeAZsdbaYgG6osLgn8JZOEvFRiS/9/p7nf+rpRfPV3+H4OWuWa
	wJME0
X-Gm-Gg: ASbGncvIoh5WxvgbPmmn74QyxdOoTT7sCxvM64c2rvSE0pA+QH2XY/8/Z1yvaJGysV5
	18JcrAv0jl6rQyBLUBz/eQuj1ByLidnoDXajFejhRQYvwrX77OPsLFSIDuTZVD59Us7/eryiZnN
	sD83F4hbXn9EQ5zEs2zcvatrmOyQ9PMoCSR+hW5NHn3mCwPXuPA02NkyimTgS1hjdejs/uLPAjw
	Vi6sxfRSBo6aFv9tYA9aznQIVXgkNIOAfH6QJZFj2sXyx1+kuTZVviZZ86nWnQKCHfdBkdgPcZZ
	vS/eLFt63+uyDEP7NCPQWShbSietLMnjKejp0HHo03PEdq5ODcqqIBIBDIg5grdriNKdlVmgIff
	ssIcNRtgU/AJEo7xkWMQ=
X-Google-Smtp-Source: AGHT+IFnGhvdQp5Ng/qylonF/Sy2e22aJEsWRYp/IMAGZQyEg8GU55IGfE+OVTEm0VSX6MfKlGY2bw==
X-Received: by 2002:a17:90b:2f0d:b0:2fe:6942:3710 with SMTP id 98e67ed59e1d1-30e7d4eea1bmr30531398a91.3.1747846566167;
        Wed, 21 May 2025 09:56:06 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 0/2] x86/boot: provide better diagnostics in AP boot failure
Date: Wed, 21 May 2025 18:55:02 +0200
Message-ID: <20250521165504.89885-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

Both patches attempt to improve AP boot failure diagnosis by improving
the printed failure messages (patch 1) and detecting AP getting stuck
during bringup (patch 2).  They should be non-functional changes for
systems working correctly.

Thanks, Roger.

Roger Pau Monne (2):
  x86/boot: print CPU number in bring up failure
  x86/boot: attempt to print trace and panic on AP bring up stall

 xen/arch/x86/include/asm/processor.h |  1 +
 xen/arch/x86/smpboot.c               | 12 ++++-
 xen/arch/x86/traps.c                 | 66 +++++++++++++++++-----------
 3 files changed, 51 insertions(+), 28 deletions(-)

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:56:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:56:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992348.1376109 (Exim 4.92)
	(envelope-from )
	id 1uHmjo-0007UN-GR; Wed, 21 May 2025 16:56:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992348.1376109; Wed, 21 May 2025 16: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 1uHmjo-0007UE-Dq; Wed, 21 May 2025 16:56:16 +0000
Received: by outflank-mailman (input) for mailman id 992348;
 Wed, 21 May 2025 16:56:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHmjn-0007EC-Bp
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:56:15 +0000
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com
 [2607:f8b0:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 807a5dcb-3664-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 18:56:13 +0200 (CEST)
Received: by mail-pf1-x42e.google.com with SMTP id
 d2e1a72fcca58-74267c68c11so6121353b3a.0
 for ; Wed, 21 May 2025 09:56:13 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 d2e1a72fcca58-742a9876d51sm10145775b3a.141.2025.05.21.09.56.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:56: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" 
X-Inumbo-ID: 807a5dcb-3664-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747846572; x=1748451372; 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;
        bh=7RLYMRivYweydZfPNnM0rOXuUXXKFPj67o1KMs4fjDc=;
        b=W9KPk6YJq8fYhOxFSL1XdErtwnuiuYJoVQwF83DQNcrH8cCzPjTUQ5hNPqCE3XBjGO
         4OLyMab6FiO8WNqH+hqsIykYzDdH+hyI5v9VgFSbCaa/iD63sQPuSf2KPy1O+a+dFipJ
         pfP3KjGn/oeMRVsFVsrwecFc4wy04qmcsz1Ig=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747846572; x=1748451372;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=7RLYMRivYweydZfPNnM0rOXuUXXKFPj67o1KMs4fjDc=;
        b=wbqrH+Jd+bXTJncSko5PFl9rFQ0I5ZcMYpPryQ9dOGuGVYNy8trgGbkKhKCgu3wSr6
         VYlRGML7cCSYGPaEQg2DAEo9bJsvcXWWCEE+YpjmcmVK4T/NKhVSpPskXVU7giQoeTNr
         9EQ/7jCVb8udTJYTXIgPRXojO5zZvSTIS6otjlw1RRcPF394rTnc8b+KyL1T2yVV6obb
         9sEmKzjDVoTS8yQexeoBUq57PGCbqsMkXqxoLY7XVbXgsejbcgQLC8V9tqTGE85A49Qp
         /fBWDb65joiiybI+QOcefqxBChBuiiM8c60bvYnUtmfRjK8QVcLR4xvOGK0fxEpypLu5
         YJRQ==
X-Gm-Message-State: AOJu0YwSPxC9awmSbLCB/3Z08N8YdV/0Dgn/V2cg+IkS8HTrzZSAYk6/
	gRjuWLqfs9jPZYj3qEAD23i299P/w6g6fWgM4nI+SZ3+PkOul8Wz+34T+roFMBkNPFI4JYFow7j
	d0GD3
X-Gm-Gg: ASbGncvUUKiFx7zpcnBDf1GuXrFI6WLK4e3SiDu4NLii0d6W/zCslNZvFISsolbo5xF
	DvirxW+vbwLtveu+c1UM28rroQjdxMGDZgX3fJMYWTw0sMfH0KaFfupj8fMn4cOiV85dSnsb3t8
	GEnUPjQ7bYlwS3tQUYWDphPkisDQgUQFLfIA7oVfXa5SOeuyxlSqndWkNEjPwjCXu3IdH1WuIVV
	DzyENouLmXVmbXZlnc91nc0e7EVhPysWCHmgyasOhJe4YuacwfeDjJTLg1sDWWgdOKWQtcnpfaU
	Chli+reh9YubuXHD4+8N/UNvNz47CadD1cc1WObTNBv9/ntFQkufzl8g2RWfhddCq/AWNTpz7HX
	ULxSf2bS8iBZ768ckyCp63xnItN9jLQ==
X-Google-Smtp-Source: AGHT+IES7Ek8EzshDBdhQSGONc0yvnA3KTmFWE2v1kEF+JfemXRUcsXF1uGp1Mv7bkHt0QAWpR5ZQw==
X-Received: by 2002:a05:6a00:b56:b0:740:a52f:a126 with SMTP id d2e1a72fcca58-742accc52cbmr25285685b3a.9.1747846571808;
        Wed, 21 May 2025 09:56:11 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 1/2] x86/boot: print CPU number in bring up failure
Date: Wed, 21 May 2025 18:55:03 +0200
Message-ID: <20250521165504.89885-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250521165504.89885-1-roger.pau@citrix.com>
References: <20250521165504.89885-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Print the CPU ID that fails to respond to the init sequence, or that didn't
manage to reach the "callin" state.  Expand a bit the printed error
messages.  Otherwise the "Not responding." message is not easy to
understand by users.

Reported-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/smpboot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 0189d6c332a4..48ce996ba414 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -618,10 +618,10 @@ static int do_boot_cpu(int apicid, int cpu)
             smp_mb();
             if ( bootsym(trampoline_cpu_started) == 0xA5 )
                 /* trampoline started but...? */
-                printk("Stuck ??\n");
+                printk("CPU%u: Didn't finish startup sequence\n", cpu);
             else
                 /* trampoline code not run */
-                printk("Not responding.\n");
+                printk("CPU%u: Not responding to startup\n", cpu);
         }
     }
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:56:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:56:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992349.1376120 (Exim 4.92)
	(envelope-from )
	id 1uHmjt-0007n8-Nb; Wed, 21 May 2025 16:56:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992349.1376120; Wed, 21 May 2025 16:56:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHmjt-0007n1-KT; Wed, 21 May 2025 16:56:21 +0000
Received: by outflank-mailman (input) for mailman id 992349;
 Wed, 21 May 2025 16:56:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHmjs-0007kx-87
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:56:20 +0000
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com
 [2607:f8b0:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 83e77f63-3664-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:56:19 +0200 (CEST)
Received: by mail-pf1-x42c.google.com with SMTP id
 d2e1a72fcca58-7425bd5a83aso6999631b3a.0
 for ; Wed, 21 May 2025 09:56:19 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 41be03b00d2f7-b26eb0a0b19sm9850067a12.74.2025.05.21.09.56.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 21 May 2025 09:56: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" 
X-Inumbo-ID: 83e77f63-3664-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747846577; x=1748451377; 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;
        bh=qDIOiRpQ/UWqZgclLlLXABuivH/D3ZP3P/vQMi7O+1g=;
        b=QChupFmSgSzSRnbgEONq6e63zEA3OLWj8XuDXzvz0a6BxL6yDLhAtyc+3Bd3PfyrVs
         bYRguGmAW8qHKz/aHsJjDRjj+PBWGf7/o2VxVny8EYyVn+GWyWmUjm9AO08IGCC+il8+
         5v8RZkRfoUJgEH5zr4QJEXyIprVtFBQ2p0Abc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747846577; x=1748451377;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=qDIOiRpQ/UWqZgclLlLXABuivH/D3ZP3P/vQMi7O+1g=;
        b=lQ6VpvkkSkotGRLJ49JNAp6Amwch7/TGOMR/G7XenmvR/bBt3m0S6PollK5QtKK8W3
         RgMSJ/cN4M4tM/Km5GietSZG4HLuNFlAjriuCG8a+qLkFzz0ObHB4Xiy4GlCanJLm2A9
         65C0J+1KTRf2X2Vda6tYr21iFybIM7v6BGJGZtEFlLixlI2wrymVJcTq12PdDQI+8Fah
         q5cqmsCBlp5NLAui4CK1oiZjrwK1QqBnOhRxkuMHdjAve6AKBHnexwCCMJFIc7V1USSV
         ZKRIhh+FDpyJgQFyZPApjyEKaKR0/ynnoFrzxK/anOiednNqqlHqR9NJWe+ze1f4F1OI
         s5pA==
X-Gm-Message-State: AOJu0YydvYjZEP1GhGw4T4IawiPuc9wGHaErZ31aGwQuAiPodunYL2oz
	mtqb6w/R0/1b9K01yFBw3/VLxVFdlqZEy3iSYG0gukiTdG3EhRPEoEicD0KPuL3RrcbUejRUZNB
	wOxx4
X-Gm-Gg: ASbGncsUCySS+35nH5m3bbwYY3y+MU3VAlcUSaaw8VbRDJPD5XlxJ1vb5OPJUmebIU+
	/2tkJY5TQfzZ7VxK91pUS8ab96hl6a4EFkhZYeMPT+647Tp5RahxqAoIGoALDtqc4HcPx1jBA6m
	w6riJYtc0DF/xPb2d/QkY2xhSKEcWbOtlFTmXbhL+iyoPZwdnor4V1a4+FDoZPZksGPkj1TnIoY
	kWdGBCSv9TG8Q/9naRYNJcECQs5t511UGfWol2OwejSy/Gm0dIDP4Z3ctGYtU3S+4uPfgv/odCe
	8l76SlWmfUPyejcUaiu1GYToie6QW87DPAbGhmuUtQmLNs7/bAu1Nk+bnuDCni1vda9gz2T4gx6
	tTKPfrph8eTnjOxSHUwE=
X-Google-Smtp-Source: AGHT+IGXzgNihnHoIDZ49HYZOtoHdKkHpbangZQmlumpILsL+ggNAnIJfg1eVBtBYPorxJZCtPztZQ==
X-Received: by 2002:a05:6a21:6e4a:b0:1f3:194b:30ae with SMTP id adf61e73a8af0-2162188b7d7mr32339282637.1.1747846577248;
        Wed, 21 May 2025 09:56:17 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 2/2] x86/boot: attempt to print trace and panic on AP bring up stall
Date: Wed, 21 May 2025 18:55:04 +0200
Message-ID: <20250521165504.89885-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250521165504.89885-1-roger.pau@citrix.com>
References: <20250521165504.89885-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With the current AP bring up code Xen can get stuck indefinitely if an AP
freezes during boot after the 'callin' step.  Introduce a 10s timeout while
waiting for APs to finish startup.

On failure of an AP to complete startup send an NMI to trigger the printing
of a stack backtrace on the stuck AP and panic on the BSP.

The sending of the NMI re-uses the code already present in fatal_trap(), by
moving it to a separate function.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/include/asm/processor.h |  1 +
 xen/arch/x86/smpboot.c               |  8 ++++
 xen/arch/x86/traps.c                 | 66 +++++++++++++++++-----------
 3 files changed, 49 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index eacd425c5350..10d8078cc1ca 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -371,6 +371,7 @@ void show_registers(const struct cpu_user_regs *regs);
 #define dump_execution_state() run_in_exception_handler(show_execution_state)
 void show_page_walk(unsigned long addr);
 void noreturn fatal_trap(const struct cpu_user_regs *regs, bool show_remote);
+void show_execution_state_nmi(const cpumask_t *mask, bool show_all);
 
 extern void mtrr_ap_init(void);
 extern void mtrr_bp_init(void);
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 48ce996ba414..77dce3e3e22b 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1370,6 +1370,7 @@ int cpu_add(uint32_t apic_id, uint32_t acpi_id, uint32_t pxm)
 int __cpu_up(unsigned int cpu)
 {
     int apicid, ret;
+    s_time_t start;
 
     if ( (apicid = x86_cpu_to_apicid[cpu]) == BAD_APICID )
         return -ENODEV;
@@ -1388,10 +1389,17 @@ int __cpu_up(unsigned int cpu)
     time_latch_stamps();
 
     set_cpu_state(CPU_STATE_ONLINE);
+    start = NOW();
     while ( !cpu_online(cpu) )
     {
         cpu_relax();
         process_pending_softirqs();
+        if ( NOW() > start + SECONDS(10) )
+        {
+            /* AP is stuck, send NMI and panic. */
+            show_execution_state_nmi(cpumask_of(cpu), true);
+            panic("CPU%u: Stuck while starting up\n", cpu);
+        }
     }
 
     return 0;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index c94779b4ad4f..9b9e3726e2fb 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -714,13 +714,15 @@ static cpumask_t show_state_mask;
 static bool opt_show_all;
 boolean_param("async-show-all", opt_show_all);
 
+static bool force_show_all;
+
 static int cf_check nmi_show_execution_state(
     const struct cpu_user_regs *regs, int cpu)
 {
     if ( !cpumask_test_cpu(cpu, &show_state_mask) )
         return 0;
 
-    if ( opt_show_all )
+    if ( opt_show_all || force_show_all )
         show_execution_state(regs);
     else if ( guest_mode(regs) )
         printk(XENLOG_ERR "CPU%d\t%pv\t%04x:%p in guest\n",
@@ -734,6 +736,40 @@ static int cf_check nmi_show_execution_state(
     return 1;
 }
 
+void show_execution_state_nmi(const cpumask_t *mask, bool show_all)
+{
+    unsigned int msecs, pending;
+
+    force_show_all = show_all;
+
+    watchdog_disable();
+    console_start_sync();
+
+    cpumask_copy(&show_state_mask, mask);
+    set_nmi_callback(nmi_show_execution_state);
+    /* Ensure new callback is set before sending out the NMI. */
+    smp_wmb();
+    send_IPI_mask(mask, APIC_DM_NMI);
+
+    /* Wait at most 10ms for some other CPU to respond. */
+    msecs = 10;
+    pending = cpumask_weight(&show_state_mask);
+    while ( pending && msecs-- )
+    {
+        unsigned int left;
+
+        mdelay(1);
+        left = cpumask_weight(&show_state_mask);
+        if ( left < pending )
+        {
+            pending = left;
+            msecs = 10;
+        }
+    }
+    if ( pending )
+        printk("Non-responding CPUs: {%*pbl}\n", CPUMASK_PR(&show_state_mask));
+}
+
 const char *vector_name(unsigned int vec)
 {
     static const char names[][4] = {
@@ -780,33 +816,11 @@ void fatal_trap(const struct cpu_user_regs *regs, bool show_remote)
 
         if ( show_remote )
         {
-            unsigned int msecs, pending;
+            cpumask_t *scratch = this_cpu(scratch_cpumask);
 
-            cpumask_andnot(&show_state_mask, &cpu_online_map,
+            cpumask_andnot(scratch, &cpu_online_map,
                            cpumask_of(smp_processor_id()));
-            set_nmi_callback(nmi_show_execution_state);
-            /* Ensure new callback is set before sending out the NMI. */
-            smp_wmb();
-            smp_send_nmi_allbutself();
-
-            /* Wait at most 10ms for some other CPU to respond. */
-            msecs = 10;
-            pending = cpumask_weight(&show_state_mask);
-            while ( pending && msecs-- )
-            {
-                unsigned int left;
-
-                mdelay(1);
-                left = cpumask_weight(&show_state_mask);
-                if ( left < pending )
-                {
-                    pending = left;
-                    msecs = 10;
-                }
-            }
-            if ( pending )
-                printk("Non-responding CPUs: {%*pbl}\n",
-                       CPUMASK_PR(&show_state_mask));
+            show_execution_state_nmi(scratch, false);
         }
     }
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Wed May 21 16:58:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 16:58:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992371.1376130 (Exim 4.92)
	(envelope-from )
	id 1uHmmA-0000PI-2V; Wed, 21 May 2025 16:58:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992371.1376130; Wed, 21 May 2025 16:58:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHmm9-0000PA-Vt; Wed, 21 May 2025 16:58:41 +0000
Received: by outflank-mailman (input) for mailman id 992371;
 Wed, 21 May 2025 16:58:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHmm8-0000Oy-2O
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 16:58:40 +0000
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
 [2a00:1450:4864:20::433])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d78cd754-3664-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 18:58:39 +0200 (CEST)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a3673e12c4so2821517f8f.2
 for ; Wed, 21 May 2025 09:58:39 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca5a84csm20355774f8f.31.2025.05.21.09.58.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 09:58: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" 
X-Inumbo-ID: d78cd754-3664-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747846718; x=1748451518; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=UPyVRz9pXq4sGeCwWjKLzIei9u3zxgHoNDinNdva4vY=;
        b=rw7mvv/F3YeVjUdcLHsjbSy4NFtiNxU2dwNdDWyLu4l2INeJmJ1pr+YUzMA96YozYa
         QT6EnqAYYUEj8n4nwfmLPZz1Hety3MfWwICAuwiGWvXr2JYh1uaqNmiXm45lrNTmoSBh
         ZAD98VNFJcQe7BJnRA8ickbDmsyQgPrUtxvc0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747846718; x=1748451518;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UPyVRz9pXq4sGeCwWjKLzIei9u3zxgHoNDinNdva4vY=;
        b=DfLD/1ZT/uVOdTpRVMIFNOic+gYyTnZL81ySSlmZLbzpgOKQ7G+6Yr7n7MdmN/FKml
         IVp8Z+DvVDsp7K1Cc+qeuBi05nYBpp2W4juI5oy7eDwzLLNuvtqTkIm7WS+MjPKKtEvO
         V3mJhz138NDB3ZqU5lhh5TZCcOKEONj4OGMehqRl2PJ2v7ApU2rzePbbvA1pE4lLyLp2
         1qMpY7Vi7dg9KqPgwFTPfiDjedJte/jHXgfSKbRgX4AHRwsYayqaxOtZkyFWc7SCdaYy
         yQcx9sCHsOxBfvRMU9M6GjORCxP/NKoG8DaCP/hx1BeycFB0gkTLRj37fDLKqR1NPmcR
         4c0Q==
X-Forwarded-Encrypted: i=1; AJvYcCXK/yARysreRDAq3A4vuxGdsZnG8tJRlyEKPpgps8aHpS3Zz/Zae/Zrn8of/lFiFRBYBqvSd/OLhjU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzBbifPEN9K4LqFyxqIoi0tYVTITo3perervRRyi9cmwl2eeD4Z
	MYCgZwdcAZgdhvUaP1zx1I1wtjwbhAN7TGSxyiBs3U2d8uR8fWI5IpbngVy2xkOrhZc=
X-Gm-Gg: ASbGncuwcCYaApBfZ4YuJi7biX/P57xZwZXtROwh/5UeL1rvlJFAZkbKePgRXFWDIkP
	VGK58XiszYjgkQoo4eL9WU/tqfOhA2J8Redi6eBgMoJTQVm/tyiZV5zUSTEg9s03GgYYCnkcg4X
	vZwm28KMMlTtalPclajsb2i1wo181+RAsuaOVcu0xQol1TYXpWW3H0Z6mCjA4MA7lmOQCHTdxIY
	JnslRpidof5gQO6cIjfKdky2EEi4ABp+mpx4XZI+WkOUZofsC+tUQKhruD2aHVXHa/cDhdCYYqn
	q2G8s0E+YmZnYGrD858fjYrvl2g2lGt1Fccj31hL+ngS1mfPLpkv3QAuLJZ8FfwOMsWh3AlRuOZ
	6zoary0JbUAJpd1fh
X-Google-Smtp-Source: AGHT+IGrffbGCaVt/A3GOj3E5l3Rd9O4oUQG3nLUQFA0w0In1SB1U8RhmuNVdZKtkIbmmlQu1GbKuA==
X-Received: by 2002:a5d:5f46:0:b0:3a0:7017:61f6 with SMTP id ffacd0b85a97d-3a35c825eefmr21237666f8f.14.1747846718497;
        Wed, 21 May 2025 09:58:38 -0700 (PDT)
Message-ID: 
Date: Wed, 21 May 2025 17:58:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] x86/boot: print CPU number in bring up failure
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich 
References: <20250521165504.89885-1-roger.pau@citrix.com>
 <20250521165504.89885-2-roger.pau@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: <20250521165504.89885-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21/05/2025 5:55 pm, Roger Pau Monne wrote:
> Print the CPU ID that fails to respond to the init sequence, or that didn't
> manage to reach the "callin" state.  Expand a bit the printed error
> messages.  Otherwise the "Not responding." message is not easy to
> understand by users.
>
> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 
> ---
>  xen/arch/x86/smpboot.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 0189d6c332a4..48ce996ba414 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -618,10 +618,10 @@ static int do_boot_cpu(int apicid, int cpu)
>              smp_mb();
>              if ( bootsym(trampoline_cpu_started) == 0xA5 )
>                  /* trampoline started but...? */
> -                printk("Stuck ??\n");
> +                printk("CPU%u: Didn't finish startup sequence\n", cpu);
>              else
>                  /* trampoline code not run */
> -                printk("Not responding.\n");
> +                printk("CPU%u: Not responding to startup\n", cpu);
>          }
>      }
>  

I'd suggest printing the APIC_ID too.  The next step here is always to
cross-reference with the MADT.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 21 17:25:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 17:25:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992383.1376140 (Exim 4.92)
	(envelope-from )
	id 1uHnBU-00064R-1E; Wed, 21 May 2025 17:24:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992383.1376140; Wed, 21 May 2025 17:24: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 1uHnBT-00064K-UE; Wed, 21 May 2025 17:24:51 +0000
Received: by outflank-mailman (input) for mailman id 992383;
 Wed, 21 May 2025 17:24:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHnBS-00064A-H4
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 17:24:50 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20621.outbound.protection.outlook.com
 [2a01:111:f403:200a::621])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7ddc706c-3668-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 19:24:48 +0200 (CEST)
Received: from SJ0PR05CA0063.namprd05.prod.outlook.com (2603:10b6:a03:332::8)
 by PH7PR12MB7820.namprd12.prod.outlook.com (2603:10b6:510:268::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.20; Wed, 21 May
 2025 17:24:40 +0000
Received: from SJ1PEPF000023CE.namprd02.prod.outlook.com
 (2603:10b6:a03:332:cafe::3f) by SJ0PR05CA0063.outlook.office365.com
 (2603:10b6:a03:332::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.13 via Frontend Transport; Wed,
 21 May 2025 17:24:40 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF000023CE.mail.protection.outlook.com (10.167.244.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 21 May 2025 17:24:39 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 21 May
 2025 12:24: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" 
X-Inumbo-ID: 7ddc706c-3668-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=i+wq2OEfR0PhO2beDgDmFO6SJgDKX3khHO5enPO1PG47v0Tee31zO41Lm8fJn3nFWbXIC64OI7bJDTVtjTlJodny6sGUJpSCY0TquUkQanx/c/TTt8B4aLiReCyLcstiJe1RSNZSX72qHyRR9sOvqmpiC1LQKlpvzFf4Z2MRtwFC1UyQO1CVnVSG9UqfclZE10QoTNxlNMstqaOMoSNN6q+cIOykd83a0wTMWvBVq8wSRKSAAv0tHey8yYl9p19FCDngsXK3XCTE67Wi+QENbLyEFwGa9KWm4vLTilxi5Sf6jZ17twrxZniUvVn2tsxHshPF/PMXKC5wHQi/+e1KRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5f3c3t6rUgnHBAAzqlNlPYUG+dEoJIOJHb5GRm7vK8k=;
 b=q6tFpWFklN/kvcRFI5uFpmidlsKTbk57y6ZoJbjcu+4ZmzEBLPAawz22mMSYD9aPbop2GX3S+Ikt675fREz/p9ypXQhz86c7CLnHPtG07u/zgX1Mvh9IZ9HyG/ZuVcYS7XXsvO4+YpmbLUzfbRAx3i1b4QzHbpemn5ztdERL9EhNdvA4U07LHKBK8lIFARZcYkDuGl7jeiTq8LdJgEbLUShUIgm6XztFxjuOlQiYa5DN/iSH2a60ECi3A+Jw/9sEHuRc/Vc4aoUorEwsljlSTz3X8yMNLDr+Po+Fte6/sap6nAKfUnq2MDbDH1xZHIDgo52HNmmNk3gq3Re2gjyYfg==
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=5f3c3t6rUgnHBAAzqlNlPYUG+dEoJIOJHb5GRm7vK8k=;
 b=GCAux34K5CpcB2Ns0Um/R64TUtEI+lUvbYDi1OzSQDBJ0JprOA3cU5C8VXF4dG3BiTMrhl/ZFbgb07YbJPZjBz9hIDewMJh8Xwj+A9cVyzudZv0h5jDYxLVcDqznrujuxpQ3gd5txMHGNdIOWwcdrYy08Ii3NS4IIJEG/7bTcNY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 21 May 2025 19:24:36 +0200
Message-ID: 
From: Alejandro Vallejo 
To: Jan Beulich 
CC: "Daniel P. Smith" , Andrew Cooper
	, =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Anthony PERARD , "Michal
 Orzel" , Julien Grall , "Stefano
 Stabellini" , Jason Andryuk ,
	Denis Mukhin , 
Subject: Re: [PATCH v6 03/12] x86/hyperlaunch: initial support for
 hyperlaunch device tree
X-Mailer: aerc 0.20.1
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-4-agarciav@amd.com>
 <6f821e28-b182-4d27-b2db-e3be80910c12@suse.com>
In-Reply-To: <6f821e28-b182-4d27-b2db-e3be80910c12@suse.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023CE:EE_|PH7PR12MB7820:EE_
X-MS-Office365-Filtering-Correlation-Id: 53fd08aa-9522-4069-50eb-08dd988c5e49
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NWdaeDlhTnRUd0p6TS8vTnU5U1FiUFJDZjJPNkNyeThyVlpZa3JUMHJBQUVm?=
 =?utf-8?B?U0tyVW5CUWFWbzE0SytkZ1owSk1haU5YcmpSZzBiTEJsWmxtQmRGb1g0QWJO?=
 =?utf-8?B?N0lHM0NHMTBXU29waExSbmJFUnc3YXhJSm5pZXE1WmN3cnVNcHhvUVRGTUJt?=
 =?utf-8?B?R2lZK29BUG1nZDNqUVdYVnhQRzFhaEdScmpqMzlJRnYrclgzdEo3c2JrZWRx?=
 =?utf-8?B?NXN5ZTh0M2U4aVNXVlQ1cDMrelJzY243azlaa3M5aWU2WW4yNVVDL0NvZnA3?=
 =?utf-8?B?cEpLYnJQbTRaRGR0NmVMaE9KcFQ1dkhmcE9GeVhMLzRhT3ozNk8vaEVEVitF?=
 =?utf-8?B?WlNJWUhCeC9XbHp0bUhOODZUK2RZL1JmNlNEdDV6ZUtCcDFEYlJkeEd5OUE1?=
 =?utf-8?B?ek1ONTNTK2xONUVpbEZBSDRsODhRRzZoN3g3NjBVVmNFYVY2QVZXc0JaZllY?=
 =?utf-8?B?aDJhVnZSbjRReHpxMmRoN0gyUjFXQXVJN0IvbVVWeUpTSzBGQVplTThwenlP?=
 =?utf-8?B?RG8veEhDQnpjZGIxcHp3dkxCdUREb0kwK0t5YmI3Q0tZb1dJYmJ1Y2Q4K2Fa?=
 =?utf-8?B?YkxEWk5aNm1hb2tmUkxRQjZuM0p2aDdNV3VOeXgyTzh2VmErRVNQNnoxdEd3?=
 =?utf-8?B?NXp3Kys3RDcvbUU0VkJBNndDQk1GVFpvUWdua3F2Nk82SDZHRGVVajR6YnZm?=
 =?utf-8?B?ZUF5YkZrejhBYWxMU1JUV3NmTVdNc0RSbmlIRjgvYWx5djVjNmZlUlFueU5W?=
 =?utf-8?B?QjdvbUtJWHIyNWtwajNrOVFpZmJhNzRtYVpObkZGWFBKYlhncENzRTNudy9q?=
 =?utf-8?B?MTlaM1ptUTNkT1oxZkNocG94cUJNMVNieTNCZm5pVmFneFRGaEJ4Y2M5c0lN?=
 =?utf-8?B?dkxHMzBJN1h5UHpucjJ1Ykx5Q3JVS1pzbGZJRXovUkhsUUVMQTdmUTZGU1RM?=
 =?utf-8?B?aHlwVExsOVhLZG5VYW1pQXE4N1JvUyttSUsxbE02OTJrc1h5blZhb2lXV3pL?=
 =?utf-8?B?Qnl4N2hsekRwcUZJUHlKOGlWdjEza2hmd2ZwQklHWk80aWhjQzZLRFJqcW1Y?=
 =?utf-8?B?K1MxNG4zZmlqeE54c0ZuV2ZYcGRLdjZuTWpLbVRucFVvNjFiQkkyS24zbGEr?=
 =?utf-8?B?dldSUnlaZ2hUOWk2QTFSbzB5OVpMSXhmOFFoZ2M0cXpNQ0hlTEVMbGEwU24x?=
 =?utf-8?B?cWhqNGFQQjR0WE9MSENpQVFnZm02Um1qUzJ4WTVwR1dVMldoenBmUHJDcFYr?=
 =?utf-8?B?djZ0aGR5U3ZGMjB0Y2NxYVphcERSTm8wK1ltSFRtb3M2NkNrS0FrN1MwdHBq?=
 =?utf-8?B?SVM4ek0ra2pPbE44Y0IzZlpnTlY3NVRJVE05eFltUGhadytTZ1M5UG5hTlhn?=
 =?utf-8?B?aTB1NTIyTlhkLzlGM3NHM3pqVy80eElaOW1RSTVCSDg5d3MvUzNGQXNNU3BR?=
 =?utf-8?B?eEtLaFY5L1dtMytIT2Fyc2JQR0szcklPMzR4QWNpbHBMRU0yR0RlUjZidi9r?=
 =?utf-8?B?MVpNdkJaalJxdlFTMXRUb2FvdkFtTHlTcXNmT0RIWCtkcG1mcFc3SitPankw?=
 =?utf-8?B?YWNqUHROTk9kQzFIWGNZMjJldkV1SGFpRVVrVnFiUHpqM1lHYnRQSnZCT3VT?=
 =?utf-8?B?blVOTDU5bDRtczdLN09Ec2VHbFZtb3daQU9Gd0U1L3F0YXVlakxYVis2ZHRa?=
 =?utf-8?B?SFFmZytjNnk3SnlYbzdtNzBsUW9FeFBBQVVKUjNTMGRkRjRYZHVtVHVTZUI2?=
 =?utf-8?B?Nm1hK3VUWGh2cTFNOUxhZjdxUWE3TEJvLy9kWlNOcE5nOVNZM2hUMVY4aGxD?=
 =?utf-8?B?WVpuR0hrODBoRC9mandQeEdrSU9BOGJHdjVzRE8ySDR1QWdKaUZuZU9iaXNk?=
 =?utf-8?B?bTN4WjgvM2xWSTJiSFR3dGxUbGVyTDB5dkh1TGFKdnRwTVJTMlJkTTdJdXVa?=
 =?utf-8?B?ZUlpTG50dUc1dllJb0xXeXlMMURPZDd1dXVrbFNUM3lZSmpDeWhFYXVYb1py?=
 =?utf-8?B?RkcrRkZpbDF6dFRHTnhOTFFXK3pRR1hnMjlNOGU4VTVKa0QvMjBqWG5uRlBa?=
 =?utf-8?Q?parBue?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2025 17:24:39.9919
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 53fd08aa-9522-4069-50eb-08dd988c5e49
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023CE.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7820

On Wed May 21, 2025 at 5:00 PM CEST, Jan Beulich wrote:
> On 29.04.2025 14:36, Alejandro Vallejo wrote:
>> From: "Daniel P. Smith" 
>>=20
>> Add the ability to detect both a formal hyperlaunch device tree or a dom=
0less
>> device tree. If the hyperlaunch device tree is found, then count the num=
ber of
>> domain entries, reporting an error if more than one is found.
>>=20
>> Signed-off-by: Daniel P. Smith 
>> Signed-off-by: Jason Andryuk 
>> Signed-off-by: Alejandro Vallejo 
>> Reviewed-by: Denis Mukhin 
>
> First: With your code re-use proposal sent earlier today I wonder how
> meaningful it is to further review this series. Much of it would change
> if that proposal was followed, I expect?

Should I follow through with that proposal, that would indeed have large
knock-on effects here. Sorry, I took longer than I thought I would
evaluating.

I'll go over your reviews and answer them in case they stay relevant
afterwards. Thanks for that.

>
> Then: When you say "hyperlaunch or dom0less" - is it entirely benign
> which of the two is found, as to further parsing? I ask because I can't
> spot anywhere that you would record which of the two (if any) was found.

Under dom0less everything is /chosen, mixed with other nodes.
Hyperlaunch mandates the initial system configuration to reside in
/chosen/hypervisor, which is meant to be "xen,hypervisor"-compatible.

The function is effectively finding a suitable root for the tree that
contains the initial system config.

>
>> --- a/xen/common/domain-builder/fdt.c
>> +++ b/xen/common/domain-builder/fdt.c
>> @@ -13,6 +13,36 @@
>> =20
>>  #include "fdt.h"
>> =20
>> +static int __init find_hyperlaunch_node(const void *fdt)
>> +{
>> +    int hv_node =3D fdt_path_offset(fdt, "/chosen/hypervisor");
>> +
>> +    if ( hv_node >=3D 0 )
>> +    {
>> +        /* Anything other than zero indicates no match */
>> +        if ( fdt_node_check_compatible(fdt, hv_node, "hypervisor,xen") =
)
>> +            return -ENODATA;
>> +
>> +        return hv_node;
>> +    }
>> +    else
>
> Please can such unnecessary (and potentially misleading) "else" be omitte=
d?

Not sure how it could be misleading, but...

> As ...
>
>> +    {
>> +        /* Look for dom0less config */
>> +        int node, chosen_node =3D fdt_path_offset(fdt, "/chosen");
>
> ... these will need to move to function scope then, one of the two may wa=
nt
> folding with "hv_node" above.

... there is indeed a more compact form the function could take. Noted.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Wed May 21 17:32:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 17:32:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992402.1376150 (Exim 4.92)
	(envelope-from )
	id 1uHnIo-00085f-Qc; Wed, 21 May 2025 17:32:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992402.1376150; Wed, 21 May 2025 17:32: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 1uHnIo-00085Y-O2; Wed, 21 May 2025 17:32:26 +0000
Received: by outflank-mailman (input) for mailman id 992402;
 Wed, 21 May 2025 17:32:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHnIn-000849-E4
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 17:32:25 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8d3e9078-3669-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 19:32:23 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 17478487363520.5364171347913498;
 Wed, 21 May 2025 10: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" 
X-Inumbo-ID: 8d3e9078-3669-11f0-a2fa-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; t=1747848738; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=V2vYzP5s4TQ/bOD9hjVHW2NfdagKjH9iuvDLwHdbu6EnNcsAORmH49ujcqD7wLyyd/wae5LQy25SJiPSxQB4uD2e6SKOlmmfGav/1QLFDaJz+YJtfZigVKFxsq85l5NXyNQbqktCRWIQ+JmV9GZasaJNClAlVEmZmoVfeKfzJ7g=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1747848738; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=2M/ZHcqsRoeogBFbSY4UDqqx2mVwPC35qS2+XjLNMDA=; 
	b=mbZpr1MIEqv1CjaJMO0Rnonzf3C4A+Mu6Q4Ajsp28dk4nmz2x4bQlByYILr9WCPb0ouD0KeFayNq3gTAzKHoE3T4m4053FjxBN6Z5LYGjm9JdNBEuCsbD0lLkRBIyzZqsXdH5o2twZcINBo+a65+kVFkg/rVTmDsvTnqXdsTa9c=
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=1747848738;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:From:From:To:To:Cc:Cc:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=2M/ZHcqsRoeogBFbSY4UDqqx2mVwPC35qS2+XjLNMDA=;
	b=pr7uT+D4udgkcUKMUOuL8uemuea8nx/rmRqjuhOYfQaMIXbKKQyDXI0FnIc0KETs
	V3Cq25mr7T6+l5vO+H/EYMkcxEH27NGaTwJM4Sqe4fEnheRbIapUma9WFBv/9mbFXBJ
	EDAGxoGYn5F+ROTgpa4RQjGbwpqg1XByfTfJsEBY=
Message-ID: <40b3eb93-779f-478a-a8a8-6716693a68fa@apertussolutions.com>
Date: Wed, 21 May 2025 13:32:14 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Hyperlaunch/dom0less code sharing
Content-Language: en-US
From: "Daniel P. Smith" 
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Jason Andryuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Xenia Ragiadakou 
References: 
 <958f591f-35ac-4a10-93e2-9301ccfc5353@apertussolutions.com>
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: <958f591f-35ac-4a10-93e2-9301ccfc5353@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 5/21/25 11:31, Daniel P. Smith wrote:

> As for 3, I can repost my original analysis that went to the working 
> group on why using this is not the best idea. Doing 3 would require 
> doing at least two, if not three passes on the DTB for x86 with zero 
> benefit/need since, unlike Arm, we never have to read from it after 
> boot. The way the x86 parser is today, we are walking the DTB only once.
> 
> What I would suggest for 2 is that, perhaps, it might be an opportune 
> time to review the existing DTB parsing code. Providing a common 
> interface to parse standard/spec DTB structures regardless if it is 
> coming from an FTB or via the FTB index, aka "unflattened" DTB. Doing so 
> would enable a complete reuse within the DTB parsers and remove then 
> need for 3.

Apologies, I did not CC anyone on the posting of the original analysis. 
It is posted to xen-devel as "Hyperlaunch Device Tree Discussion".

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed May 21 18:00:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 18:00:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992409.1376160 (Exim 4.92)
	(envelope-from )
	id 1uHnkC-0003xX-Ux; Wed, 21 May 2025 18:00:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992409.1376160; Wed, 21 May 2025 18: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 1uHnkC-0003xQ-S2; Wed, 21 May 2025 18:00:44 +0000
Received: by outflank-mailman (input) for mailman id 992409;
 Wed, 21 May 2025 18:00:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHnkB-0003xK-Oy
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 18:00:43 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 81b612a8-366d-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 20:00:40 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a37a243388so2069243f8f.1
 for ; Wed, 21 May 2025 11:00:40 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca9417dsm20097364f8f.101.2025.05.21.11.00.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 11:00: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" 
X-Inumbo-ID: 81b612a8-366d-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747850440; x=1748455240; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CdEJW6WCmifQ+lA5KIs4zJTvaJPYfOdXrnMLZdJ9XSU=;
        b=CADO1StQj4g7Had+MDi3SKOKoZyZvN+tv+jjg6kr8YYBctXaIcLN73x0VvJaDyliNT
         Y+o/rfWNuyU41gKErA48+hdwl43mgac2XI9B6e5zA0omjZ6n7pd2xcEX2qH6Xqz6tBfM
         AUcJLF97nAW39NYqkiUBTkLSp/4LLD0g9sQn8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747850440; x=1748455240;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CdEJW6WCmifQ+lA5KIs4zJTvaJPYfOdXrnMLZdJ9XSU=;
        b=ZMQmJ46NRSzoDP2Tv9XXSnDQCUsKuxlnOW5ueovIrJN5PpYpzetzzCvCvQVNfbNv/Q
         ch2itBqfCzKAGBAtxXIg3VZh75XQDQLZfy++zeUIAZ5IBfROQohk1fGVyLekXVxY0l3I
         Ss82F4/de3IXMPVfrF83wdyip0TY4Kv+5ogKgoIR5h5CBIbpr8zS7XklAeGD494bLqgT
         TOebtEQdcmxBNJyuXP05vMxObEq2ajawxtu1gh9mjksgxrgKlysq829xmFy+9Fj/sbK6
         Tuc0bEEXfd7UXwPmUojxeNEC2IoVR6W07awwdoMoRSdWdRLhwaoRq4K50Q4QF4ZrjUif
         927w==
X-Gm-Message-State: AOJu0YygCHdIRiGR0rUjh6dYfcRPf3eDvDo4pj/tc3O0hRbtLZXk/AEM
	PHt/eildIfa2u260bpOyj37MRY/8pH+4nH8bCx11FAYzIoqoSi0vjVQwD3tVds+IequaNLHbQUI
	JYeDU
X-Gm-Gg: ASbGnctrX2jGVdxSqhejY05unFa0Cd4lQMcf7MZ3kDwGDBYaoovISkAKPzq2RnVXAly
	CJiQZZgzMGGJ/LNOT68DNTe+nwv6yBwIvHh7DJyeurKwwF5/dtu1jjPsXURzH16wvnhaam0172W
	utUbOpu6ij+pT3Rb7cJFDT2M5NncjkQqnQ9SVVJ/mb0Bt1AVH15CsDhhanIPjB2MR7CE57Pqb2t
	hOP+b/N5pq/kj4KVcXBJ0tYwkRMBHQWWztOSZvy6YTUXufrjQN6AWLSfxwXXKwaHfUhJoDhFkXK
	KsGO9dgu5Xm2h3lR0rne/oJSsvJvOyxkCrd15KAvTRfEGmApuqkHrKqI2BSCguDiAWqmKaDWYmm
	S9dNxnGR0soGnZ6d0
X-Google-Smtp-Source: AGHT+IFPfur7Je0SL9rNUVPBV/aZkrh4UoIuAtS8mLPh25UPELZULTa2OuYwH4jSR8dU8p8h9Lr07w==
X-Received: by 2002:a05:6000:400f:b0:39f:175b:a68d with SMTP id ffacd0b85a97d-3a35c808b3dmr19777335f8f.11.1747850439694;
        Wed, 21 May 2025 11:00:39 -0700 (PDT)
Message-ID: <8504aab1-c48a-4981-a502-93a2fd18880b@citrix.com>
Date: Wed, 21 May 2025 19:00:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [Eclair false positive] Re: [PATCH] x86/msr: Rework wrmsr_safe()
 using asm goto()
To: Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , "consulting@bugseng.com" ,
 Stefano Stabellini ,
 Nicola Vetrini 
References: <20250521143658.312514-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: <20250521143658.312514-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21/05/2025 3:36 pm, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/include/asm/msr.h b/xen/arch/x86/include/asm/msr.h
> index 0d3b1d637488..4c4f18b3a54d 100644
> --- a/xen/arch/x86/include/asm/msr.h
> +++ b/xen/arch/x86/include/asm/msr.h
> @@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr, uint32_t lo, uint32_t hi)
>  /* wrmsr with exception handling */
>  static inline int wrmsr_safe(unsigned int msr, uint64_t val)
>  {
> -    int rc;
> -    uint32_t lo, hi;
> -    lo = (uint32_t)val;
> -    hi = (uint32_t)(val >> 32);
> -
> -    __asm__ __volatile__(
> -        "1: wrmsr\n2:\n"
> -        ".section .fixup,\"ax\"\n"
> -        "3: movl %5,%0\n; jmp 2b\n"
> -        ".previous\n"
> -        _ASM_EXTABLE(1b, 3b)
> -        : "=&r" (rc)
> -        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
> -    return rc;
> +    uint32_t lo = val, hi = val >> 32;
> +
> +    asm_inline goto (
> +        "1: wrmsr\n\t"
> +        _ASM_EXTABLE(1b, %l[fault])
> +        :
> +        : "a" (lo), "c" (msr), "d" (hi)
> +        :
> +        : fault );
> +
> +    return 0;
> +
> + fault:
> +    return -EFAULT;
>  }

It turns out this is the first piece of Eclair-scanned code using asm goto.

https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10108558677
(The run also contained an equivalent change to xsetbv())

We're getting R1.1 and R2.6 violations.

R1.1 complains about [STD.adrslabl] "label address" not being valid C99.

R2.6 complains about unused labels.

I expect this means that Eclair doesn't know how to interpret asm goto()
yet.  The labels listed are reachable from inside the asm block.

>From a qualification point of view, this allows for some extensive
optimisations dropping emitted code.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 21 18:16:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 18:16:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992417.1376169 (Exim 4.92)
	(envelope-from )
	id 1uHnzN-00062E-6C; Wed, 21 May 2025 18:16:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992417.1376169; Wed, 21 May 2025 18:16: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 1uHnzN-000627-3g; Wed, 21 May 2025 18:16:25 +0000
Received: by outflank-mailman (input) for mailman id 992417;
 Wed, 21 May 2025 18:16:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHnzL-00061i-FS
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 18:16:23 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b2779b36-366f-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 20:16:21 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43cfdc2c8c9so43733265e9.2
 for ; Wed, 21 May 2025 11:16:21 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f7baaf2asm78199995e9.34.2025.05.21.11.16.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 11:16: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" 
X-Inumbo-ID: b2779b36-366f-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747851381; x=1748456181; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GhcJzQKC5gshz1J2+48hyL/oKwr3Dj/y63z851yN1N0=;
        b=YmfcPcVCV96q57nZEwYk10nh3EMwdCy84XUU6LsFG/aF9s1jxxLOSovegAmS+joyJ1
         fOil63YqHXfpsJES1H5Ir+iyVNMQTThHFt5EBT3y5YvCRaemsd6s48CGqOjhXOYvoSVb
         Kti2aUyO/cIvhip2r+fNmD4rOp/0r2neyBgtw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747851381; x=1748456181;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GhcJzQKC5gshz1J2+48hyL/oKwr3Dj/y63z851yN1N0=;
        b=vXNuCisZTfnTlFM463GyGJE9xdEpmj3DbglprnIO1IYv5ye42/dVZWX25XK75i/O27
         g7/BhtjRUMU2Wl+QFRoO8UnicVd/e7mdeystYCr2woKC6ogTDz2aLh1+/pV+U51yFQFb
         ZFQafQi9rKQw/fLt8uHJ6hMm6XqwiSWJaNQ4uQLCQrCL0pemszIZDdAnoTPBIipSCTRW
         lPiNMMLsNx1RnUsSgdyIjitFCA9S805Iiopiub3ozJPxGvVcD+POJia67PuLJb0MGOJu
         v5kX0aSH3g3lbDogAR0nroItLYZ3b/7gVr7NKwlbcOqwzFXdhAiH0izdqZEZuzwWjRvv
         RQlg==
X-Forwarded-Encrypted: i=1; AJvYcCWVlONhC9wOb4aF6JF2//+xjl6GGUoGHtADu15nU2oIf894vE9b0UEQkDyWQUVPK+dDXkkqRQv4lf4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywn/wzDOjErzqr/xXR90sRO2gn+7n52YeAMdByepcj4KChpe9tl
	f0ywL9wNBCi0Yp0IDiqOOe4wBr4uBMAH36ORpj+iDtmqLm/GJzpi07p7/+ok6/t5x3A=
X-Gm-Gg: ASbGncvdVS9WDRl6S1T4Ij9UfZ/NG6mbE0Q3AXWy3JbpqNBsxKd8Sop44IqAQ/FydUY
	UV4ybb7TLoMvldLFyq6Ib8NoyBe3XpneXgc8MRVAxntHxBDk6e7rn9JeY4vNSD6PuouMiVW+iM2
	9KIq8Ap/voUBPTCJRD2tR1Uwok+r5lzSlFW1yFKXENdIgpzTX8PUnftwO+xreI4Bq6hff/uC/Lh
	sztzs2vlQY59K4gk2ZRJyHo9YzsS03GczUo1v4yaPLQc5SDerQHjoiQLlCmXIrYgEGvhw8l1A45
	kSfeAtpVi4fARWOD5xy20B/Q3OijZPweB7pT++zioZZuL+sz5PDmpTwPYTzhje9F/LprleqMLnO
	7SLj12gFGaNlBfgj7
X-Google-Smtp-Source: AGHT+IGSnTJJvprQsF/PO2Qhvr509i65mjqnn9h2fhttHDdFkmg6eaLxuoCLskdG5P8Jo7A5071L7w==
X-Received: by 2002:a05:600c:3e88:b0:43d:94:2d1e with SMTP id 5b1f17b1804b1-442fd627303mr212091845e9.13.1747851380662;
        Wed, 21 May 2025 11:16:20 -0700 (PDT)
Message-ID: 
Date: Wed, 21 May 2025 19:16:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/boot: attempt to print trace and panic on AP
 bring up stall
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich 
References: <20250521165504.89885-1-roger.pau@citrix.com>
 <20250521165504.89885-3-roger.pau@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: <20250521165504.89885-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21/05/2025 5:55 pm, Roger Pau Monne wrote:
> With the current AP bring up code Xen can get stuck indefinitely if an AP

You want a comma between "code, Xen" to make the sentence easier to parse.

> freezes during boot after the 'callin' step.  Introduce a 10s timeout while
> waiting for APs to finish startup.

5s is the timeout used in other parts of AP bringup.  I'd suggest being
consistent here.


> On failure of an AP to complete startup send an NMI to trigger the printing

Again, a comma between "startup, send" would go a long way.

> of a stack backtrace on the stuck AP and panic on the BSP.
>
> The sending of the NMI re-uses the code already present in fatal_trap(), by
> moving it to a separate function.

I'd be tempted to split the patch in two.

>
> Signed-off-by: Roger Pau Monné 
> ---

It may be worth nothing that this came from the ICX143 investigation,
even if it wasn't relevant in the end?

> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 48ce996ba414..77dce3e3e22b 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -1388,10 +1389,17 @@ int __cpu_up(unsigned int cpu)
>      time_latch_stamps();
>  
>      set_cpu_state(CPU_STATE_ONLINE);
> +    start = NOW();
>      while ( !cpu_online(cpu) )
>      {
>          cpu_relax();
>          process_pending_softirqs();
> +        if ( NOW() > start + SECONDS(10) )

(NOW() - start) > SECONDS(10)

It has one fewer boundary conditions, even if it is rather unlikely that
start + 10s will overflow.

> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index c94779b4ad4f..9b9e3726e2fb 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -734,6 +736,40 @@ static int cf_check nmi_show_execution_state(
>      return 1;
>  }
>  
> +void show_execution_state_nmi(const cpumask_t *mask, bool show_all)
> +{
> +    unsigned int msecs, pending;
> +
> +    force_show_all = show_all;
> +
> +    watchdog_disable();
> +    console_start_sync();
> +
> +    cpumask_copy(&show_state_mask, mask);
> +    set_nmi_callback(nmi_show_execution_state);
> +    /* Ensure new callback is set before sending out the NMI. */
> +    smp_wmb();

I know this is only moving code, but this is wrong.  So is the smp_mb()
in the x2apic drivers.

It would only be correct in principle for xAPIC (which is an MMIO
store), except it's UC and is strongly ordered anyway.  Furthermore, the
sequence point for the send_IPI_mask() prevents the compiler from
reordering this unsafely.

The x2APIC drivers need LFENCE;MFENCE on Intel, and just MFENCE on AMD,
and this (critically) is not smp_mb(), which is now just a locked operation.

I bet these aren't the only examples of incorrect barriers WRT IPIs.  I
guess we should fix those separately.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 21 19:21:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 19:21:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992464.1376179 (Exim 4.92)
	(envelope-from )
	id 1uHp0H-0006VV-LH; Wed, 21 May 2025 19:21:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992464.1376179; Wed, 21 May 2025 19:21:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHp0H-0006VO-Im; Wed, 21 May 2025 19:21:25 +0000
Received: by outflank-mailman (input) for mailman id 992464;
 Wed, 21 May 2025 19:21:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHp0F-0006V2-IE
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 19:21:23 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c5e409cd-3678-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 21:21:19 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 5A33D4EE8F37;
 Wed, 21 May 2025 21:21: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" 
X-Inumbo-ID: c5e409cd-3678-11f0-b892-0df219b8e170
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=1747855278;
	b=LUctiTTGH2+3XzTGk9rizEELeyVu/FbqqsAG2V+413ub7cezO1DS8WAfpQpOefHxykfl
	 md8fJhP0+v+APOuo6aAgUBf6MBlYe5QZhhkSqxblgXR2diFmHip/9j1VJMVMcT3KWtsDZ
	 ht6WMv/nHsUDJcRtpaPoyGa3dYOS16Q7NY3Yyv1jUNvLMuSPJZILMyCmWSD57CDdxr6eW
	 WQ/DDZAN2PJqzL1nszxNfnwO9YrxaRxiyUkes/qvg6ee4PbnEYQt4NEWupSNRznx7poFX
	 c+yDS9BoKVOl62iW+oYXnTpBrWNU+oXk/hRDhKjsIlNORBPrBJkIAg8gXJbzWfXmwEbH5
	 c7xqHxLXg56cj0MKmDyBSb7P8Hbj02U4KWHurKV6FZXHlgnTClegvPcHarp8C8xSx0Q9N
	 Cf8i4/zmKloB/nkLMAD4QouGqnSbfyhcJKl2y/GrFvOeg6dIKZLh10rd5C+BcsU2E913c
	 mf1CZ3y7mRo7/143PXMal3CMEYoeeqduXJoDmputG6nMDa1X41qtji/cra/SYREIQjsbT
	 n589xsPYDx0I0VhvDOYBEa6jx31CMPl6mxQqQbXh6PiNbxkidzbTM67izpaDyTTeXuJUt
	 gecOChMTdr5lBX4LQJKNv/CEOTPtxPu0ehejQpLvgOwv0BohLaBmImHtOp/tZAg=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1747855278;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=ZraXWh/iQ3lNhXXC1xKcadFz6sINU0JgNn4VFrkMYL8=;
	b=ZJgQQL20o1vedpFCeFzvk27UBS5LjBtYDfA3kk3WFEsrrFS+6eoGvvou/2S1l8rLsV2T
	 DZQKimTxIXWV6B8evj6EjscXwNKJ+KCvxvHv/bb2CatMcWlzhDSpRpUA4/LVyGxgWXuW3
	 1L7fCh+ffybfQ21ZbS+8ujMOkl39r5WDeNBFx+dVIoyrf5ypiU8R2pI476IkCbLpH5JxC
	 sbTaApjaM1/BU2rXsSXsV/Mvn4oXqDqFRbnyLkB+OVLX5mQA0ahEHFzO5L+4tDOQ+/Day
	 /JE3N0krhDjAoagYRUVCg2IeyVLOQxSkNU4S/N2UMpSqhHHOpBhvXvbI1IMC9wRcXjF6W
	 NmewFTanGj7Oy8me3q6nQUk8s42Sk9PxsCRJVhHpLpnzK6yxxJFHN71MoGEBP1ao5jZ2I
	 WS2NstnBlVTqFdNiy9Fs9XQ9gW5t8s/4eDuyLbL3fFrVOIpy1gDm3b0er4FuZyR5AKGRh
	 uQM637gEg0bdpPXkxc4fk5A/10w16xEmFhatzc7jwiDluffeYDxHHGpEsu4GwyOqo3UMz
	 Tl8hv/Lzk3NhE6BLFTve3TyddrV8pVFDZSnz3DSRfPwg9g9ONuv24+iC3DYPLKyzRKjrm
	 4z1UOzVVLVbrR+HZPjNYpTs1psyBKyJqCpLL8iOaacz2YiomTHY5musfyuKa4IU=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1747855278; bh=6L4iSTlNiFXCb09zXDURe3Zac62HlWYwaIgEpnrWWuM=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=CuBhcUgKqnawtWZgmQdLprk+2Z4J5J1zRPc/8DpFLnIll2gte2X/DlzXLFNrMoVRd
	 UadnR78nnpDhFPSURuqKkDkB6zJWb0wzokZgKo8w93AjUuISbgujA2iIf9tWTNBkc+
	 LGmhboDM98FwCq/8Y2xUQelrKQEOwEMnUY8bkAW8CE2153ZXnz3QCEen3k0SiVL0A0
	 Zp0JnD8NaM4VpNnWa10j418xkLvD/5e0lyb5O6TKXFuu0LTsKp8EEI1Dkuf4cRhvK3
	 PV0UzeDDB+fAw/7fHH6TekAA6d5waidvTBh67yBsw4aq5Ifk8lP6Zlf+a/y492lN06
	 IRJZbhY7mvTJg==
MIME-Version: 1.0
Date: Wed, 21 May 2025 21:21:18 +0200
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , consulting@bugseng.com, Stefano Stabellini
 
Subject: Re: [Eclair false positive] Re: [PATCH] x86/msr: Rework wrmsr_safe()
 using asm goto()
In-Reply-To: <8504aab1-c48a-4981-a502-93a2fd18880b@citrix.com>
References: <20250521143658.312514-1-andrew.cooper3@citrix.com>
 <8504aab1-c48a-4981-a502-93a2fd18880b@citrix.com>
Message-ID: <70f8e278921685e39eec6656a529b31b@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2025-05-21 20:00, Andrew Cooper wrote:
> On 21/05/2025 3:36 pm, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/include/asm/msr.h 
>> b/xen/arch/x86/include/asm/msr.h
>> index 0d3b1d637488..4c4f18b3a54d 100644
>> --- a/xen/arch/x86/include/asm/msr.h
>> +++ b/xen/arch/x86/include/asm/msr.h
>> @@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr, uint32_t 
>> lo, uint32_t hi)
>>  /* wrmsr with exception handling */
>>  static inline int wrmsr_safe(unsigned int msr, uint64_t val)
>>  {
>> -    int rc;
>> -    uint32_t lo, hi;
>> -    lo = (uint32_t)val;
>> -    hi = (uint32_t)(val >> 32);
>> -
>> -    __asm__ __volatile__(
>> -        "1: wrmsr\n2:\n"
>> -        ".section .fixup,\"ax\"\n"
>> -        "3: movl %5,%0\n; jmp 2b\n"
>> -        ".previous\n"
>> -        _ASM_EXTABLE(1b, 3b)
>> -        : "=&r" (rc)
>> -        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
>> -    return rc;
>> +    uint32_t lo = val, hi = val >> 32;
>> +
>> +    asm_inline goto (
>> +        "1: wrmsr\n\t"
>> +        _ASM_EXTABLE(1b, %l[fault])
>> +        :
>> +        : "a" (lo), "c" (msr), "d" (hi)
>> +        :
>> +        : fault );
>> +
>> +    return 0;
>> +
>> + fault:
>> +    return -EFAULT;
>>  }
> 
> It turns out this is the first piece of Eclair-scanned code using asm 
> goto.
> 
> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10108558677
> (The run also contained an equivalent change to xsetbv())
> 
> We're getting R1.1 and R2.6 violations.
> 
> R1.1 complains about [STD.adrslabl] "label address" not being valid 
> C99.
> 
> R2.6 complains about unused labels.
> 
> I expect this means that Eclair doesn't know how to interpret asm 
> goto()
> yet.  The labels listed are reachable from inside the asm block.
> 
> From a qualification point of view, this allows for some extensive
> optimisations dropping emitted code.
> 

Hi Andrew,

R1.1 is easy to fix, I'll send a patch myself. On R2.6 you are probably 
right. I suggest marking the rule not clean to unblock while we 
investigate. It should not be hard to fix this FP.

Thanks,
  Nicola
> ~Andrew

-- 
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 May 21 19:43:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 19:43:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992483.1376190 (Exim 4.92)
	(envelope-from )
	id 1uHpLj-0000wr-EV; Wed, 21 May 2025 19:43:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992483.1376190; Wed, 21 May 2025 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 1uHpLj-0000wk-Bm; Wed, 21 May 2025 19:43:35 +0000
Received: by outflank-mailman (input) for mailman id 992483;
 Wed, 21 May 2025 19:43:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHpLh-0000we-PZ
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 19:43:33 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e08ff1c7-367b-11f0-a2fa-13f23c93f187;
 Wed, 21 May 2025 21:43:32 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-442ed8a275fso89736295e9.2
 for ; Wed, 21 May 2025 12:43:32 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f6b2979fsm85563075e9.1.2025.05.21.12.43.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 12: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" 
X-Inumbo-ID: e08ff1c7-367b-11f0-a2fa-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747856612; x=1748461412; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=8RxifEaxya2qktArADWMfzCJaLLBpxqEtKINBJztMe4=;
        b=mmB3w9N4B1PbBHbR6uLuimRUJ/BJ4bml70n4IBtfMo/liPUqu71liCuRuAV63UHM2n
         EnQvpmhy/gBMghxKVkXHi/WiAEnXRv6yeY21jW0jLGNIR7EJeHyw9Jh5+OFieLbDvr+B
         peQHPh+PT3sjTe7VR3Ssr6lOrNU2I4dMc53lo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747856612; x=1748461412;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8RxifEaxya2qktArADWMfzCJaLLBpxqEtKINBJztMe4=;
        b=EHGVYfG3zBI5pTthDN/AyryLeDvzE6wlOoPMS4lW//ojGr+xUeH6g/ZfwrDQ0DVM90
         HdX4arxRPjiSL0yvr/6yifRp4f+91vuoqCEOeLFxrEYDUGrd8/CFMU5Jg3fl/L0KbRHT
         7gkqy0+OFawzt4Wt3t05b/Gg3YuhWIbqwqc41mhsGl7BY2Z0jvlgUeYmcaPA0A9hKVEC
         yhq2tWFEZ7FF3EvOQkQCYa1WFTJ4DSWeUwwEEYpn9voXehAA9bIK+0AlbQOFSBXwT0HK
         pLERCIJ6W6wpuTc/hBNS856mKVw7b2dSyhb8nHO0yb5HOAV2TnfEKd3WK9JVrNzOWNm6
         k5Pg==
X-Gm-Message-State: AOJu0YweVNmZ5yDsXeMwpRjFFLv+2lpmUS+00x9RzyUAfFTKeI5BzhIk
	pRKFOFS3Rkvt1JLXgpHXa8a7QqvgI+Na+6tI6Etz0JxOlXVkUhmeJuBqFJS527YIxm0=
X-Gm-Gg: ASbGncu4EfkIT0cdjy3Km7pZznuQL3w/JaEwcXps5O1e1PeIvTpcCsBXb9SF1UOF5T0
	NragysAhuTS2unZB36ANZ1HBHG8cV1zEL86gIupGijHmAXYFD9AZv11jmWYfDlc5EW5PXL2Owzc
	JQZ3HgxTB3fPdWtT7nbYTlnykriGYZtO/kUGQ9LYe4xrZmANn4/EAyLhd0npc2/HTbLEqHRVxca
	R8PrlOZsaeGM036xId6aW0sPoMHhnWjDa4rt5vwEsXWhbWGzgpzmEiuSjqOR5SafH1EqEHhWsNb
	Dcqiq8yxFGLsHPUSNCS5kAN5rzfvjmKdMqgmczpNth23b9E/aTqAYqrdx79WoaP7jC/eRBRLilu
	TT6pilQ3AZx+SIZdO
X-Google-Smtp-Source: AGHT+IF0EUrlWiyTkwjfKIp49896zA1YNOeLLFGJ5cfTkwuxYe7EN9mJS4Za2RwCBPkRfvMrkVtDyg==
X-Received: by 2002:a05:600c:4688:b0:43d:2230:300f with SMTP id 5b1f17b1804b1-442fd5a160amr246232555e9.0.1747856611843;
        Wed, 21 May 2025 12:43:31 -0700 (PDT)
Message-ID: <5eda4958-0eb8-4b52-8ae4-297206c29803@citrix.com>
Date: Wed, 21 May 2025 20:43:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [Eclair false positive] Re: [PATCH] x86/msr: Rework wrmsr_safe()
 using asm goto()
To: Nicola Vetrini 
Cc: Xen-devel ,
 Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , consulting@bugseng.com,
 Stefano Stabellini 
References: <20250521143658.312514-1-andrew.cooper3@citrix.com>
 <8504aab1-c48a-4981-a502-93a2fd18880b@citrix.com>
 <70f8e278921685e39eec6656a529b31b@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: <70f8e278921685e39eec6656a529b31b@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21/05/2025 8:21 pm, Nicola Vetrini wrote:
> On 2025-05-21 20:00, Andrew Cooper wrote:
>> On 21/05/2025 3:36 pm, Andrew Cooper wrote:
>>> diff --git a/xen/arch/x86/include/asm/msr.h
>>> b/xen/arch/x86/include/asm/msr.h
>>> index 0d3b1d637488..4c4f18b3a54d 100644
>>> --- a/xen/arch/x86/include/asm/msr.h
>>> +++ b/xen/arch/x86/include/asm/msr.h
>>> @@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr,
>>> uint32_t lo, uint32_t hi)
>>>  /* wrmsr with exception handling */
>>>  static inline int wrmsr_safe(unsigned int msr, uint64_t val)
>>>  {
>>> -    int rc;
>>> -    uint32_t lo, hi;
>>> -    lo = (uint32_t)val;
>>> -    hi = (uint32_t)(val >> 32);
>>> -
>>> -    __asm__ __volatile__(
>>> -        "1: wrmsr\n2:\n"
>>> -        ".section .fixup,\"ax\"\n"
>>> -        "3: movl %5,%0\n; jmp 2b\n"
>>> -        ".previous\n"
>>> -        _ASM_EXTABLE(1b, 3b)
>>> -        : "=&r" (rc)
>>> -        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
>>> -    return rc;
>>> +    uint32_t lo = val, hi = val >> 32;
>>> +
>>> +    asm_inline goto (
>>> +        "1: wrmsr\n\t"
>>> +        _ASM_EXTABLE(1b, %l[fault])
>>> +        :
>>> +        : "a" (lo), "c" (msr), "d" (hi)
>>> +        :
>>> +        : fault );
>>> +
>>> +    return 0;
>>> +
>>> + fault:
>>> +    return -EFAULT;
>>>  }
>>
>> It turns out this is the first piece of Eclair-scanned code using asm
>> goto.
>>
>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10108558677
>> (The run also contained an equivalent change to xsetbv())
>>
>> We're getting R1.1 and R2.6 violations.
>>
>> R1.1 complains about [STD.adrslabl] "label address" not being valid C99.
>>
>> R2.6 complains about unused labels.
>>
>> I expect this means that Eclair doesn't know how to interpret asm goto()
>> yet.  The labels listed are reachable from inside the asm block.
>>
>> From a qualification point of view, this allows for some extensive
>> optimisations dropping emitted code.
>>
>
> Hi Andrew,
>
> R1.1 is easy to fix, I'll send a patch myself. On R2.6 you are
> probably right. I suggest marking the rule not clean to unblock while
> we investigate. It should not be hard to fix this FP.

I've not committed the patch yet, so staging is still green.

But, it occurs to me that this is not the first asm goto() to be scanned
by Eclair.  There's wrmsr_amd_safe() in amd.c (c/s b3d8b3e3f3aa from ~6w
ago) using exactly the same pattern, which has been passing just fine.

Clearly something else is relevant in terms of triggering violations.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 21 19:48:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 19:48:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992491.1376199 (Exim 4.92)
	(envelope-from )
	id 1uHpQm-0001W3-0N; Wed, 21 May 2025 19:48:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992491.1376199; Wed, 21 May 2025 19: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 1uHpQl-0001Vw-Tm; Wed, 21 May 2025 19:48:47 +0000
Received: by outflank-mailman (input) for mailman id 992491;
 Wed, 21 May 2025 19:48:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHpQl-0001Vq-JL
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 19:48:47 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9b045d15-367c-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 21:48:45 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 90E964EE8F3B;
 Wed, 21 May 2025 21:48: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" 
X-Inumbo-ID: 9b045d15-367c-11f0-b892-0df219b8e170
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=1747856924;
	b=lJONIE43XycHjKY1L4OAKMDD7FrzZnEcIHFKjrg5sfYXfqbp2tqlWm2j5zFX9rlL+3Eb
	 tI55SDr8ww7SHTqtzWjBmLgzmM98K3oEnkfyFx4EeKN9rVDoDdu8K8yk8RKo8Hk5NzHdu
	 uqVsGGMAR2DzWG8oJ/il0JrNvbUoKv3Tjh5btW4PMnHJuVvcN8wGS7SjqST5NR8fbWdzY
	 q6BYV2BC0qNdqz01iRIAGh5yFCoG1+nsrLwZNNA6lt/Ib1wTRA04SgQp1SDnp7992q+hh
	 WApBJC8cs8EmGq8/KGv7lN79wq4f5ZpFH3R/4IFnThxg4w0cMs8XGwNBpsKgQIgJVPDdP
	 g8U49FSvIor8VYiVDfvboO5XWZcA4DCqv9DLZLMPgK9u7SVcUGZdpWZ7h6VOuHqN759V0
	 2XcV4G7EagPCoqMiNMUSnBykfHnRyjkSNk8SFnKRcp/u+U8npN9vZkb596jE203AgoXhJ
	 1y085C89rG8fZVeVLWOSnxamNjygSX7lMy7c1hSAOJgyGQ69SfakaM/VZuQkAQ3ycxkYZ
	 1LZUmWfo6sLpgdntNtd5Ek7cjzHSD76TQymc3342SRWV5T2ThJNMBBJmNDqEk8b/R0aL9
	 BV5kz43qMCINQEthwvbUhqCJAyr10ENgHckyr7xGgxjE3ogc/sMb9CFqKSAvvGg=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1747856924;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=LTxE9Yb2r8dLahvXU0v8CIBcEw3dxDbuyQCr6UuSSA0=;
	b=yY4/V8KHay4grV7R/UI53wvHh3OilW4Mc4Naac9F7lyS7LBfnPVvSiXO/PdzU6IIQFK4
	 aw3C0mMK1998S3cgriqGXEowsN7NlzgcmyFe0kA6aL4i55zrEGWffSprBtnABqC0P/E1s
	 YSyhwaLivjgCA8tB2QGnhfl1B3f3oqaRU9ySMmUwoJ3VTUhE25lUHmsgFIrnV5oDBwVTs
	 lpbwCEXZ7SqO4XQ2I1lB9x/aEDCzBbLl0wVdRy3ZolFmGIK5sZNw7d+b2mLT3tMwgHXFM
	 CsVqfhZyHftURuKGyWutJg8Lxu+lfxe5YblW/cTssbRZsRs0OTdPOIpwFDLY8d9oSxTyz
	 GDIdVvu/IPzhWA15ROxU2d6sWQvHcA3wjzPZQRKMrZaFRX2I1wCTY5od3r0W9neykAJXf
	 XjOyC6VT+xsLXWELEU+TqUFPUrJg30MzeAp7GOmNlSwTNn/jNA9WiqVijudynkcVC0A3P
	 9DBhknp6Qv8weYn3tkj3YLr6xQN+DwCEEk5niza2Z3Ex4755ljWcJ+R21E6vpcf0O5E7u
	 yOQllHj5/+8xPixcgxaEt0oGsSdJUtMWU6Zt8skf9v0uHmDrcYpTWYoJe30RmptTWYOYo
	 jBQEPuwQbLOVI6OM/EsSSZhGcNw0GWg/a8SrokseXS9wKwYH6ttV0vv73W76M8E=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1747856924; bh=liPU9YORblEFjB8Li3//3zilGtMryo3pmHS0W7XpouM=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=fkdZjDrSDF6V/8sQWxvh9EurFj1HHxZ2/l5EzgZ/fu4E42tlCTWcfo0NuZH28nHhY
	 za75pZ6MSnOnCszub8mwHSjobLz8by45mzmdBeDdFMDe/oIS5kN5I6LFymQ85dIRx4
	 M8UdMdvXPSI36WOiEYM1ZHagUyBq6AhCX2ooUMPdqa8LoHXbslh1E4AvS1wux4xdHM
	 KUPg8Upnvps/lIacruHWQPHKGSZkd6Z6XS1/0bU2VXbXamYswKvXBZgGT5d5ZNdeL2
	 duVqHp6nbQr5WulBXeKDuZ8XcW+NKG2Aj8/xSJ0KhXtJ3yRm75NCfkhHK74DkiYuZD
	 HMsctUDURvrkw==
MIME-Version: 1.0
Date: Wed, 21 May 2025 21:48:44 +0200
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , consulting@bugseng.com, Stefano Stabellini
 
Subject: Re: [Eclair false positive] Re: [PATCH] x86/msr: Rework wrmsr_safe()
 using asm goto()
In-Reply-To: <5eda4958-0eb8-4b52-8ae4-297206c29803@citrix.com>
References: <20250521143658.312514-1-andrew.cooper3@citrix.com>
 <8504aab1-c48a-4981-a502-93a2fd18880b@citrix.com>
 <70f8e278921685e39eec6656a529b31b@bugseng.com>
 <5eda4958-0eb8-4b52-8ae4-297206c29803@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

On 2025-05-21 21:43, Andrew Cooper wrote:
> On 21/05/2025 8:21 pm, Nicola Vetrini wrote:
>> On 2025-05-21 20:00, Andrew Cooper wrote:
>>> On 21/05/2025 3:36 pm, Andrew Cooper wrote:
>>>> diff --git a/xen/arch/x86/include/asm/msr.h
>>>> b/xen/arch/x86/include/asm/msr.h
>>>> index 0d3b1d637488..4c4f18b3a54d 100644
>>>> --- a/xen/arch/x86/include/asm/msr.h
>>>> +++ b/xen/arch/x86/include/asm/msr.h
>>>> @@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr,
>>>> uint32_t lo, uint32_t hi)
>>>>  /* wrmsr with exception handling */
>>>>  static inline int wrmsr_safe(unsigned int msr, uint64_t val)
>>>>  {
>>>> -    int rc;
>>>> -    uint32_t lo, hi;
>>>> -    lo = (uint32_t)val;
>>>> -    hi = (uint32_t)(val >> 32);
>>>> -
>>>> -    __asm__ __volatile__(
>>>> -        "1: wrmsr\n2:\n"
>>>> -        ".section .fixup,\"ax\"\n"
>>>> -        "3: movl %5,%0\n; jmp 2b\n"
>>>> -        ".previous\n"
>>>> -        _ASM_EXTABLE(1b, 3b)
>>>> -        : "=&r" (rc)
>>>> -        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
>>>> -    return rc;
>>>> +    uint32_t lo = val, hi = val >> 32;
>>>> +
>>>> +    asm_inline goto (
>>>> +        "1: wrmsr\n\t"
>>>> +        _ASM_EXTABLE(1b, %l[fault])
>>>> +        :
>>>> +        : "a" (lo), "c" (msr), "d" (hi)
>>>> +        :
>>>> +        : fault );
>>>> +
>>>> +    return 0;
>>>> +
>>>> + fault:
>>>> +    return -EFAULT;
>>>>  }
>>> 
>>> It turns out this is the first piece of Eclair-scanned code using asm
>>> goto.
>>> 
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10108558677
>>> (The run also contained an equivalent change to xsetbv())
>>> 
>>> We're getting R1.1 and R2.6 violations.
>>> 
>>> R1.1 complains about [STD.adrslabl] "label address" not being valid 
>>> C99.
>>> 
>>> R2.6 complains about unused labels.
>>> 
>>> I expect this means that Eclair doesn't know how to interpret asm 
>>> goto()
>>> yet.  The labels listed are reachable from inside the asm block.
>>> 
>>> From a qualification point of view, this allows for some extensive
>>> optimisations dropping emitted code.
>>> 
>> 
>> Hi Andrew,
>> 
>> R1.1 is easy to fix, I'll send a patch myself. On R2.6 you are
>> probably right. I suggest marking the rule not clean to unblock while
>> we investigate. It should not be hard to fix this FP.
> 
> I've not committed the patch yet, so staging is still green.
> 
> But, it occurs to me that this is not the first asm goto() to be 
> scanned
> by Eclair.  There's wrmsr_amd_safe() in amd.c (c/s b3d8b3e3f3aa from 
> ~6w
> ago) using exactly the same pattern, which has been passing just fine.
> 
> Clearly something else is relevant in terms of triggering violations.
> 
> ~Andrew

I think the reason it's simply that file being out of scope due to being 
imported from Linux (whether that is still true I don't know), which is 
unfortunate. We ought to revise that list 
(docs/misra/exclude-list.json).

-- 
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 May 21 19:50:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 19:50:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992498.1376210 (Exim 4.92)
	(envelope-from )
	id 1uHpSj-00036j-BW; Wed, 21 May 2025 19:50:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992498.1376210; Wed, 21 May 2025 19: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 1uHpSj-00036c-7l; Wed, 21 May 2025 19:50:49 +0000
Received: by outflank-mailman (input) for mailman id 992498;
 Wed, 21 May 2025 19:50:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHpSi-000333-G8
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 19:50:48 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e312bc5f-367c-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 21:50:46 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43cf680d351so49803235e9.0
 for ; Wed, 21 May 2025 12:50:46 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35e49262fsm20075072f8f.44.2025.05.21.12.50.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 12:50:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e312bc5f-367c-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747857046; x=1748461846; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3znSiK4nKxXPx+u0aRYNV82e3clJEJVeMpcirc6h1lM=;
        b=OcK5ssz3oyj4iWEYleQkLTL3q85e0kBSNcVEizfxzSCxsHb3Q6uiY7qWOi2o06S73M
         GjQy9GgwSL6WXGBtqvzXQ17EOkp1yk6icFzZryMOqdQAOLZldlGyB9BZIAFLaS55GmLb
         HnQm2hbOb+GXbkUjFeoIzoxsbZyX38rM4D/FY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747857046; x=1748461846;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3znSiK4nKxXPx+u0aRYNV82e3clJEJVeMpcirc6h1lM=;
        b=LmPrmrL6RWg9zWXzLjSr6Qs/XE4p1JZLlBfA4JmQOcKKh8o9JkAlXIxCwjOtCaxBtH
         6eZg5GN4/z9L9FPMp935fd9VaLxpy9MdMaj6ll9m6G1JFwrmoeklrvyrZIbAeKlZrpZU
         c6W0WJItm1UxxyQgDKIYuDsfUXONTfSBjdW2E4DRJOuMBk4fby/i/TLhQ/WeYpyC5Kub
         cfzX7+mTMno6zOej+FvW4BW93+ihuzPQXqMoMfgPdVyYVvFWlvk7uRSrhxiQYVjWoi3q
         EngH2bx/LnA1c+cObfhUk/2lnVtvKNSxp9HSTHxR5QazSxWTDPeviHwOncZbHIqr1LRK
         uNpw==
X-Gm-Message-State: AOJu0YzdbIJCCKBqfijJFhzuCNpV0TE9knAyTtoiOTPNNwPp7x+IzhBr
	ErXV6GzViTeyS86KHz5KlwtI4kWY2Gc2plHYLlAJLIZ+OgOe2fQ9pHalZwXtk4GpIYs=
X-Gm-Gg: ASbGncvSkzTgnVdcWzqIj4SbEQJ+rNECo3872BRcCJulokhYG3LHWB273ihwOmTdS4g
	HjoFRFjTsqjX9jE/RUJuYpGjjq2yq3qyoBSLK3j73xkqFXmPsglxekUk7v24HEI//Bz9QWttfTQ
	67Rz0tG5XNUIdEorycU9LHzZoCdThWO1fUGIBFmQC54vUU9PCJ+XxjHqLMF5AsRZbuStnu3SBr+
	cjhrNyEaQBUX2YELU/idh3Sr9M6ah1DY4a4lcqbRlv02X2RoYkOJj/CO25OWUChSABK/Zso+Py6
	KlZcbqNYNWxkNM9i7MsuLSEEKM2pWguY77s5l32OzK1JYQe7x8JrZSXck3s0Bfrf8OOGmuu9Dq8
	xYRUKCNiJNW9aGLuo
X-Google-Smtp-Source: AGHT+IEYvoU2fNkVThUQQkh9VAYt/ug4il28egK3k1kdb0Y/S4hTUymDezxx3RZGHpdMOff8XOWtNQ==
X-Received: by 2002:a05:600c:8a5:b0:43c:ed33:a500 with SMTP id 5b1f17b1804b1-442f8b7a2b9mr163101705e9.10.1747857045663;
        Wed, 21 May 2025 12:50:45 -0700 (PDT)
Message-ID: <338413e6-7917-4dfd-bee6-7518125d7824@citrix.com>
Date: Wed, 21 May 2025 20:50:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [Eclair false positive] Re: [PATCH] x86/msr: Rework wrmsr_safe()
 using asm goto()
To: Nicola Vetrini 
Cc: Xen-devel ,
 Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , consulting@bugseng.com,
 Stefano Stabellini 
References: <20250521143658.312514-1-andrew.cooper3@citrix.com>
 <8504aab1-c48a-4981-a502-93a2fd18880b@citrix.com>
 <70f8e278921685e39eec6656a529b31b@bugseng.com>
 <5eda4958-0eb8-4b52-8ae4-297206c29803@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

On 21/05/2025 8:48 pm, Nicola Vetrini wrote:
> On 2025-05-21 21:43, Andrew Cooper wrote:
>> On 21/05/2025 8:21 pm, Nicola Vetrini wrote:
>>> On 2025-05-21 20:00, Andrew Cooper wrote:
>>>> On 21/05/2025 3:36 pm, Andrew Cooper wrote:
>>>>> diff --git a/xen/arch/x86/include/asm/msr.h
>>>>> b/xen/arch/x86/include/asm/msr.h
>>>>> index 0d3b1d637488..4c4f18b3a54d 100644
>>>>> --- a/xen/arch/x86/include/asm/msr.h
>>>>> +++ b/xen/arch/x86/include/asm/msr.h
>>>>> @@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr,
>>>>> uint32_t lo, uint32_t hi)
>>>>>  /* wrmsr with exception handling */
>>>>>  static inline int wrmsr_safe(unsigned int msr, uint64_t val)
>>>>>  {
>>>>> -    int rc;
>>>>> -    uint32_t lo, hi;
>>>>> -    lo = (uint32_t)val;
>>>>> -    hi = (uint32_t)(val >> 32);
>>>>> -
>>>>> -    __asm__ __volatile__(
>>>>> -        "1: wrmsr\n2:\n"
>>>>> -        ".section .fixup,\"ax\"\n"
>>>>> -        "3: movl %5,%0\n; jmp 2b\n"
>>>>> -        ".previous\n"
>>>>> -        _ASM_EXTABLE(1b, 3b)
>>>>> -        : "=&r" (rc)
>>>>> -        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
>>>>> -    return rc;
>>>>> +    uint32_t lo = val, hi = val >> 32;
>>>>> +
>>>>> +    asm_inline goto (
>>>>> +        "1: wrmsr\n\t"
>>>>> +        _ASM_EXTABLE(1b, %l[fault])
>>>>> +        :
>>>>> +        : "a" (lo), "c" (msr), "d" (hi)
>>>>> +        :
>>>>> +        : fault );
>>>>> +
>>>>> +    return 0;
>>>>> +
>>>>> + fault:
>>>>> +    return -EFAULT;
>>>>>  }
>>>>
>>>> It turns out this is the first piece of Eclair-scanned code using asm
>>>> goto.
>>>>
>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10108558677
>>>> (The run also contained an equivalent change to xsetbv())
>>>>
>>>> We're getting R1.1 and R2.6 violations.
>>>>
>>>> R1.1 complains about [STD.adrslabl] "label address" not being valid
>>>> C99.
>>>>
>>>> R2.6 complains about unused labels.
>>>>
>>>> I expect this means that Eclair doesn't know how to interpret asm
>>>> goto()
>>>> yet.  The labels listed are reachable from inside the asm block.
>>>>
>>>> From a qualification point of view, this allows for some extensive
>>>> optimisations dropping emitted code.
>>>>
>>>
>>> Hi Andrew,
>>>
>>> R1.1 is easy to fix, I'll send a patch myself. On R2.6 you are
>>> probably right. I suggest marking the rule not clean to unblock while
>>> we investigate. It should not be hard to fix this FP.
>>
>> I've not committed the patch yet, so staging is still green.
>>
>> But, it occurs to me that this is not the first asm goto() to be scanned
>> by Eclair.  There's wrmsr_amd_safe() in amd.c (c/s b3d8b3e3f3aa from ~6w
>> ago) using exactly the same pattern, which has been passing just fine.
>>
>> Clearly something else is relevant in terms of triggering violations.
>>
>> ~Andrew
>
> I think the reason it's simply that file being out of scope due to
> being imported from Linux (whether that is still true I don't know),
> which is unfortunate. We ought to revise that list
> (docs/misra/exclude-list.json).
>

Oh, that.  Anyone who takes a cursory look at amd.c will find it has
diverged entirely from Linux.

If I were an examiner, I wouldn't accept such a claim for being out of
scope...

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 21 20:41:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 20:41:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992528.1376220 (Exim 4.92)
	(envelope-from )
	id 1uHqFU-0001QP-Vc; Wed, 21 May 2025 20:41:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992528.1376220; Wed, 21 May 2025 20:41:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHqFU-0001QI-Sb; Wed, 21 May 2025 20:41:12 +0000
Received: by outflank-mailman (input) for mailman id 992528;
 Wed, 21 May 2025 20:41:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHqFU-0001QC-2O
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 20:41:12 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e8578b90-3683-11f0-a2fb-13f23c93f187;
 Wed, 21 May 2025 22:41:02 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 6DFCB5C0FDC;
 Wed, 21 May 2025 20:38:43 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1EF16C4CEE4;
 Wed, 21 May 2025 20:40: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" 
X-Inumbo-ID: e8578b90-3683-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747860060;
	bh=IAjsNY+HMoi6wyQBPniks3RY4zBZ99ASV0Kluaug67M=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=tgnYGrLJVpsZI/kS8l50O1drubpcetMOVAPAEo3xsKut9tndCw0/FEdLYdrNzgFwZ
	 A8qAJEy1g22E5WNUwTzwHpFFrOJRvhIbw66RqpVoAE6QENH4U3+29lUnisFv3nJ/+Z
	 9/cB2i8PW8qWW0mlyu4dU/DzxX28oT5k30IiwHdL5+WWnS6AYKRFxw1esR+fnc4ppT
	 TmPn/i0b8xQvXzgdK9HxY3JX9758IJ/6O5Miuk6VuBjAA1ln+sprEerDII9Hy+ZBFK
	 aa8nYyaYINJvgOkAbCHraKUtbqrvW4ME9LsA4uto8RPRjsE/Ul7GZhsYfzJRAIZMLT
	 kYlH9OPRuvDqw==
Date: Wed, 21 May 2025 13:40:58 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Bertrand Marquis 
cc: "Edgar E. Iglesias" , 
    Stefano Stabellini , Julien Grall , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    "Edgar E. Iglesias" , 
    "xen-devel@lists.xenproject.org" 
Subject: Re: xen/arm: Virtio-PCI for dom0less on ARM
In-Reply-To: <904E8858-E310-4D3E-A1AB-352D43C4EDC5@arm.com>
Message-ID: 
References:  <904E8858-E310-4D3E-A1AB-352D43C4EDC5@arm.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 21 May 2025, Bertrand Marquis wrote:
> Hi Edgar,
> 
> > On 20 May 2025, at 10:04, Edgar E. Iglesias  wrote:
> > 
> > Hi all,
> > 
> > Following up on the ARM virtio-pci series I posted a while back ago.
> > 
> > There have been some concerns around the delayed and silent apperance of
> > devices on the ECAM area. The spec is not super clear wether this is OK or
> > not but I'm providing some references to the PCI specs and to some real cases
> > where this is used for FPGAs.
> > 
> > There are two options how to implement virtio-pci that we've discussed:
> > 1. VPCI + IOREQ
> > 2. IOREQ only
> > 
> > There are pros and cons with both. For example with #1, has the benefit that
> > we would only have a single PCIe RC (in Xen) and we could emulate a hotplug
> > capable expansion port with a standard way to notify when PCI devices plug in.
> > Approach #2 has the benefit that there is (almost) no additional complexity
> > or code added to Xen, almost everything lives outside.
> > IMO, both options have merit and both could co-exist.
> > 
> > For dynamic xl flows, options #2 already works without modifications to Xen.
> > Users need to pass the correct command-line options to QEMU and a device-tree
> > fragment with the pci-generic-ecam-host device.
> > 
> > For static dom0less flows, we can do the same as for xl flows but we have the
> > additional problem of domU's PCI bus enumeration racing with QEMU.
> > On x86, when domU's access a memory range that has not yet got IOREQ's
> > connected to it, the accesses succeeds with reads returning 0xFFFFFFFF and
> > writes ignored. This makes it easy for guests to wait for IOREQ devices to
> > pop up since guests will find an empty bus and can initiate a rescan later
> > when QEMU attaches. On ARM, we trap on these accesses.
> > 
> > If we on ARM add support for MMIO background regions with a default read value,
> > i.e mmio handlers that have lower priority than IOREQs and that are
> > read-const + writes-ignored, we could support the same flow on ARM.
> > This may be generally useful for other devices as well (e.g virtio-mmio or
> > something else). We could also use this to defer PCI enumeration.
> > 
> > So the next versions of this series I was thinking to remove the PCI specifics
> > and instead add FDT bindings to ARM dom0less enabling setup of user
> > configurable (by address-range and read-value) background mmio regions.
> > Xen would then support option #2 without any PCI specifics added.
> > 
> > Thoughts?
> 
> We discussed that together last week and I think this is a good approach as it
> prevents having some "workaround" code for PCI not following the Virtio spec and
> could also fulfil some other use cases by giving a solution to emulate some IO
> registers for a guest with a fixed value.

+1


From xen-devel-bounces@lists.xenproject.org Wed May 21 20:43:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 20:43:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992543.1376230 (Exim 4.92)
	(envelope-from )
	id 1uHqHo-000212-E1; Wed, 21 May 2025 20:43:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992543.1376230; Wed, 21 May 2025 20:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHqHo-00020v-BM; Wed, 21 May 2025 20:43:36 +0000
Received: by outflank-mailman (input) for mailman id 992543;
 Wed, 21 May 2025 20:43:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHqHm-00020p-El
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 20:43:34 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 42a9a2be-3684-11f0-a2fb-13f23c93f187;
 Wed, 21 May 2025 22:43:33 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-44a57d08bbfso430285e9.2
 for ; Wed, 21 May 2025 13:43:33 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca4d305sm21184785f8f.16.2025.05.21.13.43.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 13:43:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 42a9a2be-3684-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747860212; x=1748465012; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=tT0MUv82gInkHImLuGT572t1gbQt3bPXepdiyT8e/wY=;
        b=mzviQsPcbx7PuqqvU6LZbLHwrIFicQYzLjMRtuxukOEpN77DSwgQeeG7va1fPKzLAe
         /e/YQzMQ+CDU4g4IFcr9nK8kdamYEKTEI3vWegcemB1n4P/vMfKYgbRh1ApUQzVUiceH
         j2o5W92Mu4LNlv1qowibxN4iHJE1gitWZ+86U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747860212; x=1748465012;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tT0MUv82gInkHImLuGT572t1gbQt3bPXepdiyT8e/wY=;
        b=XC23ttTCX5QAUIhDEQ3tqI/q9UozfwfQ+XQ6ThJTBg5CtBRmYdPcQuKaD3k+WPNrLN
         8HNlfsxGRGxKjqDV4vXUKmuZ1uAZdwPgOLnlieUuYIRYlwke8JTRRwv1qvnCscLOv73k
         Wp5enrlVw9VJOUwxf3OkMI9MbdZl4s5zT/Y7IByKUXuCb4ISwqTLeK+tQIzWpIkNSRRk
         9hwMgFrVjBQN/tfG6Z47SVQESbum5b9PwEZlTBPrEkHD7RRh59KU/FAFAh5uOW89TA6F
         aVP9jl6fBACtabidGXZF1M68+br/E5wKEvPjBmbDqdqd8wlhZDaVWhdDlECoz4FTKvVf
         UdQQ==
X-Gm-Message-State: AOJu0Ywtsrw9HstiwD/6nVrc37LOS7tXhAUFZm28MDKVfwyIw0F7OhDJ
	3DSqGLW3r5TqPLEUceaVIii3SEqrm5K+2A32Dql1nt5y3XcHfis7tCflQqKkBNAjM9U=
X-Gm-Gg: ASbGncvmfzMl0onf2+fGpyeZGwDpNO29YpcFrKpMosIyYseAe2mhq0WuHF8jzzaCRvE
	sw6i6DWEfVn3MH4VaTS6PCknWKv+grJwS5OxEehVzi4FaOmZ1Mb7iG640FMcyM+PIe5IoeuEa53
	XLp288SCsMhAp3dQQ+ZQP90rmXwgN7b62N8pHYPfrbw3IT55uq+2CqWXHFkc3UjudTLjGCmy3He
	l0U9W0HdbBu+CAWUwvnIDkQpriiHkF1d7WN1a8a0geRNHLTd3eJkTi/S9lDFCa3gisICqr1CLof
	gBYqe5YYoO0M4+heR2tfWrIlPA59wjgOwi382VqPY7LFbL2zxEctfq+I4NrK7PDtXIOCB4wxa8l
	LymJkzAvrr+IhY1G+nzpbv+0WQPk=
X-Google-Smtp-Source: AGHT+IHGi36ZZ0sAnw7W9xpybZCrFzYhM6n9TfuCvQZsdfnpU2iOPhUNRUuJK5XGifkAiAWHrZGJvg==
X-Received: by 2002:a5d:638e:0:b0:3a3:64b8:ef20 with SMTP id ffacd0b85a97d-3a364b8ef5fmr13316262f8f.52.1747860212539;
        Wed, 21 May 2025 13:43:32 -0700 (PDT)
Message-ID: <0a2a1ff2-d2fa-4331-acad-0e825421e95e@citrix.com>
Date: Wed, 21 May 2025 21:43:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/argo: Command line handling improvements
To: Christopher Clark 
Cc: Xen-devel ,
 "Daniel P . Smith" ,
 Denis Mukhin 
References: <20250520141027.120958-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

On 21/05/2025 2:01 am, Christopher Clark wrote:
> On Tue, May 20, 2025 at 3:10 PM Andrew Cooper
>  wrote:
>
>     Treat "argo" on the command line as a positive boolean, rather
>     than requiring
>     the user to pass "argo=1/on/enable/true".
>
>     Move both opt_argo* variables into __ro_after_init.  They're set
>     during
>     command line parsing and never modified thereafter.
>
>
> Instead of binding to static values set at boot, would
> boolean_runtime_param be acceptable?

No, for several reasons.

Sure, you could dynamically turn it on, but existing domains can't use
it because argo_init() wasn't called on them.  Now consider what happens
when dynamically turning it off behind the back of a domain which was
using it.

All the existing runtime controls are for properties that are not
visible to guests.  Adding opt_argo to this list would create a lot of
carnage.


(Like almost everything else in Xen), Argo is entirely broken with
respect to enumeration and controls.  And while this isn't your fault
for having copied the status quo, it is still a problem needing fixing.

Argo's availability needs advertising to the toolstack like all other
features, and the toolstack needs to be able to choose the Argo settings
on a per-VM basis.  Like everything else about VMs, the Argo-ness must
be invariant for the lifetime of the domain.

This means changes to sysctls/domctls, which IMO are prerequisites for
Argo to move from Tech Preview to Supported.  In a world where such
controls existed, the argo cmdline option would really only be for
someone trying to disable Argo globally.

This particular patch comes simply from me trying to experiment with
Argo to sort out the XTF test, and deciding that the behaviour was
objectionable enough that I'd improve it.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 21 20:48:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 20:48:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992562.1376240 (Exim 4.92)
	(envelope-from )
	id 1uHqM0-0002bX-Ts; Wed, 21 May 2025 20:47:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992562.1376240; Wed, 21 May 2025 20:47: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 1uHqM0-0002bQ-RG; Wed, 21 May 2025 20:47:56 +0000
Received: by outflank-mailman (input) for mailman id 992562;
 Wed, 21 May 2025 20:47:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHqLz-0002bK-ME
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 20:47:55 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dd307105-3684-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 22:47:53 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 8CEE34A6DB;
 Wed, 21 May 2025 20:47:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D573C4CEF3;
 Wed, 21 May 2025 20:47: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" 
X-Inumbo-ID: dd307105-3684-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747860471;
	bh=eWHmfzJdPRGEGVEM6jJzAcWUYXI2SvdTsfP1FCwsYiA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=KTkpifVhI/5hx9b0OQSKkiWbMmfz+rXFkMJPA3n+gVHt1Jr/c0LOBXtlzXlN/GsK5
	 xwlgO1dCW7Ltvy6L/z5t28AvWA+9vYp2KmDYe3QmRgh6w4sRFOIS8Hy4INJy48cXY8
	 SHexAqOKTdqTrq8mhsSsttzHqpXD5deOCZpzfsZc1SUAxQmHnsDL6IVt1WluFyW95k
	 Up+oT34+aS5vjWelC9sayLBC2kCM1vaADUQkwxeHaMXAc5hQGMOOc3N1Zfm92lpFoU
	 2UaaquAbGYWimSzWAlVeavQjmloJj5tjBfGkzg9H6CHR/ADqa9/OKeuiTxm+XnubTs
	 Gama72S9w3IpA==
Date: Wed, 21 May 2025 13:47:49 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Julien Grall 
cc: "Edgar E. Iglesias" , 
    Stefano Stabellini , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    "Edgar E. Iglesias" , 
    xen-devel@lists.xenproject.org
Subject: Re: xen/arm: Virtio-PCI for dom0less on ARM
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1406415365-1747860472=:147219"

  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-1406415365-1747860472=:147219
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 21 May 2025, Julien Grall wrote:
> > For static dom0less flows, we can do the same as for xl flows but we have
> > the
> > additional problem of domU's PCI bus enumeration racing with QEMU.
> > On x86, when domU's access a memory range that has not yet got IOREQ's
> > connected to it, the accesses succeeds with reads returning 0xFFFFFFFF and
> > writes ignored. This makes it easy for guests to wait for IOREQ devices to
> > pop up since guests will find an empty bus and can initiate a rescan later
> > when QEMU attaches. On ARM, we trap on these accesses.
> > > If we on ARM add support for MMIO background regions with a default 
> read value,
> > i.e mmio handlers that have lower priority than IOREQs and that are
> > read-const + writes-ignored, we could support the same flow on ARM.
> > This may be generally useful for other devices as well (e.g virtio-mmio or
> > something else). We could also use this to defer PCI enumeration.
> 
> Regardless what I wrote above, if we are going down the route of returning
> 0xFFFFFFFF, I would just do it for every IOs rather than the one specify in
> the device-tree. This could still behind a per-domain option, but it would at
> least make simpler to setup the system (AFAIU, in your current proposal, we
> would need to specify the range in multiple places).
 
This seems like a good idea.


> > So the next versions of this series I was thinking to remove the PCI
> > specifics
> > and instead add FDT bindings to ARM dom0less enabling setup of user
> > configurable (by address-range and read-value) background mmio regions.
> > Xen would then support option #2 without any PCI specifics added.
> > 
> > Thoughts?
> > 
> > Cheers,
> > Edgar
> > 
> > # References to spec
> > 
> > PCI express base specification:
> > 7.5.1.1.1 Vendor ID Register (Offset 00h)
> > The Vendor ID register is HwInit and the value in this register identifies
> > the manufacturer of the Function. In keeping with
> > PCI-SIG procedures, valid vendor identifiers must be allocated by the
> > PCI-SIG to ensure uniqueness. Each vendor must
> > have at least one Vendor ID. It is recommended that software read the Vendor
> > ID register to determine if a Function is
> > present, where a value of FFFFh indicates that no Function is present.
> > 
> > PCI Firmware Specification:
> > 3.5 Device State at Firmware/Operating System Handoff
> > Page 34:
> > The operating system is required to configure PCI subsystems:
> >  During hotplug
> >  For devices that take too long to come out of reset
> >  PCI-to-PCI bridges that are at levels below what firmware is designed to
> > configure
> > 
> > Page 36:
> > Note: The operating system does not have to walk all buses during boot. The
> > kernel can
> > automatically configure devices on request; i.e., an event can cause a scan
> > of I/O on demand.
> 
> I am not sure why you quote this. To me it reads like this is up to the OS to
> decide when to access the PCI bus. As we don't control the OS, this doesn't
> seem a behavior Xen can rely on.
> 
> > 
> > FPGA's can be programmed at runtime and appear on the ECAM bus silently.
> > An PCI rescan needs to be triggered for the OS to discover the device:
> > Intel FPGAs:
> > https://www.intel.com/content/www/us/en/docs/programmable/683190/1-3-1/how-to-rescan-bus-and-re-enable-aer.html
> 
> To clarify, you are saying the ECAM bus may be completely empty (e.g.
> everything is reading as ~0) and some part of the ECAM will return a non ~0
> value when the FPGA run.

>From what I found from my searches on the topic, the PCIe spec says when
a device is not present or not initialized, the system typically
receives a value of 0xFFFFFFFF on read. Once a device becomes active and
responds to configuration accesses, subsequent reads will return valid
data. The specifications do not require interrupts or hot-plug events
for device detection; polling the configuration space is a compliant
method.

Which actually points to your suggestion above to do this for every IOs.
--8323329-1406415365-1747860472=:147219--


From xen-devel-bounces@lists.xenproject.org Wed May 21 20:55:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 20:55:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992578.1376250 (Exim 4.92)
	(envelope-from )
	id 1uHqTY-0004LA-L5; Wed, 21 May 2025 20:55:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992578.1376250; Wed, 21 May 2025 20: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 1uHqTY-0004L3-I3; Wed, 21 May 2025 20:55:44 +0000
Received: by outflank-mailman (input) for mailman id 992578;
 Wed, 21 May 2025 20:55:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHqTX-0004Kw-OM
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 20:55:43 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f52f8afc-3685-11f0-a2fb-13f23c93f187;
 Wed, 21 May 2025 22:55:42 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 69ADAA4AC2A;
 Wed, 21 May 2025 20:55:41 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94B08C4CEE4;
 Wed, 21 May 2025 20:55: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" 
X-Inumbo-ID: f52f8afc-3685-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747860941;
	bh=Xnu30nzPoHCTYquH9DLumd1xjLmwbvMzDFpyXfNQjL0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Y7atkHtF5SgcW0OLwPM9wvJ91uMrOB1wXjCfBXe0YaZEmc7+iynexxnA8OPhXNLSu
	 qQvC+n89fXJ/9q9qXBPxcm9P5AeG92OoEEzN3wlro35+pivImwJleiWJThRr7/gSJB
	 mhUckIWL/iLUD4AUzKrmzZAubJzBg6dVWNV0/2KQBMzzF8CyprorpjnxpukrgPhhCM
	 TI2lcvw3pdBsiDXxMpzGzjPISebXP0xawF5OnW2a7o/raHfJMTs8f0zvPh8Lsb1dlY
	 iHOjhG0MftVYj+KohfzVvJmV20fHn+HFQZHyg6sKB9Jvry42xtWXuYseeClK/IKDpp
	 k1TMSgx2xBxbA==
Date: Wed, 21 May 2025 13:55:38 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Christopher Clark 
cc: xen-devel@lists.xenproject.org, Andrew Cooper , 
    Daniel Smith , 
    Rich Persaud , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini 
Subject: Re: [PATCH v2] MAINTAINERS: add a reviewer for Argo
In-Reply-To: <20250521102333.870789-1-christopher.w.clark@gmail.com>
Message-ID: 
References: <20250521102333.870789-1-christopher.w.clark@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 21 May 2025, Christopher Clark wrote:
> Adding Daniel P. Smith as a reviewer.
> 
> Signed-off-by: Christopher Clark 

Acked-by: Stefano Stabellini 


> ---
> since v1: add to R: role
> 
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c11b82eca9..517143075d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -222,6 +222,7 @@ F:	tools/libacpi/
>  
>  ARGO
>  M:	Christopher Clark 
> +R:	Daniel P. Smith 
>  S:	Maintained
>  F:	xen/include/public/argo.h
>  F:	xen/include/xen/argo.h
> -- 
> 2.25.1
> 


From xen-devel-bounces@lists.xenproject.org Wed May 21 21:08:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 21:08:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992586.1376260 (Exim 4.92)
	(envelope-from )
	id 1uHqfS-0006BL-MJ; Wed, 21 May 2025 21:08:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992586.1376260; Wed, 21 May 2025 21: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 1uHqfS-0006BE-J5; Wed, 21 May 2025 21:08:02 +0000
Received: by outflank-mailman (input) for mailman id 992586;
 Wed, 21 May 2025 21:08:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHqfR-0006B8-4o
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 21:08:01 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id abb0cc8f-3687-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 23:07:58 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 2EB55444B1;
 Wed, 21 May 2025 21:07:57 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA9EFC4CEE4;
 Wed, 21 May 2025 21:07: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" 
X-Inumbo-ID: abb0cc8f-3687-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747861677;
	bh=iCJtP202SBbCFbzyF1CsTxdlhtaL+N1jPWwIS62hgGU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=TkI6CxLWFv2v4ZemU/n2AcyjViXipRzOcBbdXIMtSBZBwXKpSjDEHari7nk23qvXO
	 MidJL/3005/zS38agTkC2EavirPCOkdl0F4m075DDQrDcYwGO5ddPRNwS42LFg8J+G
	 rNy7F85kiHJXFRAskMNn1HluUqYd/JtqkD7jeYBZ/8UkQxMAQkAevAnr9ddo94t/iJ
	 c9fITHul2EuWubqHXTqi9qV/pc0cBJMfU+YKitEnoHmWZuucU9Y7kQt7sN3V+kM7tZ
	 Dv0VYZYqs+YTL0d0cVRRoX2gs/1V1jaEJeDfrjepdK9OAjnycxkHU4JcOlJk+Luv9j
	 6D7VPiN4vsbAw==
Date: Wed, 21 May 2025 14:07:54 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Alejandro Vallejo , 
    Andrew Cooper , 
    "Daniel P. Smith" , 
    Michal Orzel , Jason Andryuk , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Xenia Ragiadakou , 
    xen-devel@lists.xenproject.org
Subject: Re: Hyperlaunch/dom0less code sharing
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 21 May 2025, Jan Beulich wrote:
> On 21.05.2025 16:35, Alejandro Vallejo wrote:
> > I think we should aim to share binding code wherever possible, using common
> > datastructures (kernel_info and bootmodule) as dumping ground for the results
> > of the binding parsing functions. I seek agreement on the following 3 points
> > for the end goal of DTB multidomain boots on x86 before I start slicing
> > my hacks into reasonable chunks.
> > 
> >   1. We want common data structures, with arch-specific fields to hold
> >      information from xen,domain DT nodes
> >   2. We want to have a single collection of DTB parsers in the code.
> >   3. We want to operate on the unflattened DTB for the majority of parsing.
> >     (plus a minimal version on the FDT in order to bootstrap, also common)
> 
> +1 on all three, with the caveat that I'm far from being an expert on DT.

+1 from me as well



From xen-devel-bounces@lists.xenproject.org Wed May 21 21:18:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 21:18:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992593.1376270 (Exim 4.92)
	(envelope-from )
	id 1uHqpB-0007v1-Hc; Wed, 21 May 2025 21:18:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992593.1376270; Wed, 21 May 2025 21:18:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHqpB-0007uu-Ez; Wed, 21 May 2025 21:18:05 +0000
Received: by outflank-mailman (input) for mailman id 992593;
 Wed, 21 May 2025 21:18:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHqp9-0007uo-7x
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 21:18:04 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 12f9be76-3689-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 23:18:00 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 12f9be76-3689-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=4yrzmnskpfgtvhlus3yx2ch2xa.protonmail; t=1747862279; x=1748121479;
	bh=U7qB+1IJjVuCW7oZXlL4+b6qlPeT+pYJk0YLTyjZ9z0=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=XEMiqO1xoN8xLoUVyoPNxM6ntWtvaJjqE9LIgqnWDcVxN6u1+IYE2UIQ5IIBiJ4c/
	 JiJ29j9ta/bbrktcvhsD+2QjFDF7h9nQx+OV/7xQa4HfTg2+t98kPr0rzVvyOakE61
	 C7WCmwFYF8gx/uJfQGAflpQ6aTnhV2+FnClOX5p8ZNqxC++9jzgIvRPkHfxTZtafUX
	 nOnAomSblJk9N7yLu9xm0oZ5LvvVYC7mJVNv5N10SiS/vK/UiQbs7zW9OvK6ncfif7
	 EPUglGQnj6o/U+n8CqJlty2Y6tb49pg/p39YxFoCK6gtYvtM808PT+Ly3BQBDN5zvz
	 SZw6ly++opP7A==
Date: Wed, 21 May 2025 21:17:53 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, christopher.w.clark@gmail.com, dpsmith@apertussolutions.com, michal.orzel@amd.com, persaur@gmail.com, dmukhin@ford.com
Subject: [XTF PATCH v2 0/2] xtf: integrate argo test
Message-ID: <20250521211742.2997890-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 583ebcbd4b2e4937a661644facfb7591f58a5820
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The patch series integrates an XTF argo test available at [1].

Patch 1 is the original test.
Patch 2 adds fixups to run the test under QEMU environment in gitlab CI.

[1] https://github.com/dozylynx/meta-argo/blob/master/recipes-extended/xen/=
xtf/0001-Add-Argo-test.patch
[2] Link to v1: https://lore.kernel.org/xen-devel/20250416050443.919751-1-d=
mukhin@ford.com/
[3] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/jobs/10=
110489477

Christopher Clark (1):
  tests/argo: Add argo test suite

Denis Mukhin (1):
  tests/argo: use event channel to get own domain ID

 common/lib.c                |  34 +++-
 docs/all-tests.dox          |   2 +
 include/xen/argo.h          | 259 ++++++++++++++++++++++++++
 include/xen/event_channel.h |  34 ++++
 include/xtf/hypercall.h     |   1 +
 include/xtf/numbers.h       |   5 +
 tests/argo/Makefile         |   9 +
 tests/argo/main.c           | 353 ++++++++++++++++++++++++++++++++++++
 8 files changed, 696 insertions(+), 1 deletion(-)
 create mode 100644 include/xen/argo.h
 create mode 100644 tests/argo/Makefile
 create mode 100644 tests/argo/main.c

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 21 21:18:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 21:18:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992594.1376279 (Exim 4.92)
	(envelope-from )
	id 1uHqpH-00089v-OV; Wed, 21 May 2025 21:18:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992594.1376279; Wed, 21 May 2025 21:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHqpH-00089o-Lq; Wed, 21 May 2025 21:18:11 +0000
Received: by outflank-mailman (input) for mailman id 992594;
 Wed, 21 May 2025 21:18:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHqpG-000898-1A
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 21:18:10 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 17137dc1-3689-11f0-a2fb-13f23c93f187;
 Wed, 21 May 2025 23:18: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" 
X-Inumbo-ID: 17137dc1-3689-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747862286; x=1748121486;
	bh=QuBV8JelOIY3LcKJnn2bVYDh86Bxi1+tDluV88gUXwU=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=ioR0tDvWHRIk1kFV7bMtVnSXAj7Yzlye3zbYe7GyeMj48JWL7UrTKsE9wSzDX1AXE
	 aUAK3NIOeIHNcrBltppPFUfVE/xxlF2OoDfXsgi4iGhnblSyREW/NxfaVr47kCcLrV
	 ht0rLaw6muu2ZQr4Kin7OtyLDcH5tTcuGkBvcsEoQJDg4nq+OD7u9wXC7Z8QK2/wlp
	 Tw9QTYqZNOQzNh9S0hcHAy56TEoTOdiV+0czk69nDVdmy8YaqrnUq7+Rwwlz8zGZwJ
	 Yk+/TtBmqPuAehGJ5hg1sNfkayLCF/EbCL8BVUBXVTkvaC7O/9fMosU3GhjYMtI4MC
	 rbN1D3qD496CQ==
Date: Wed, 21 May 2025 21:18:00 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, christopher.w.clark@gmail.com, dpsmith@apertussolutions.com, michal.orzel@amd.com, persaur@gmail.com, dmukhin@ford.com, Christopher Clark 
Subject: [XTF PATCH v2 1/2] tests/argo: Add argo test suite
Message-ID: <20250521211742.2997890-2-dmukhin@ford.com>
In-Reply-To: <20250521211742.2997890-1-dmukhin@ford.com>
References: <20250521211742.2997890-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 5d1e9a5137bd239ea0938bc7b54331b8911e4f57
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Christopher Clark 

From: Christopher Clark 

Simple test cases for the four Argo operations, register, unregister,
sendv and notify exercised with a single test domain.
Add infrastructure to access Argo: a 5-argument hypercall, number 39.

Signed-off-by: Christopher Clark 
Signed-off-by: Denis Mukhin 
---
Original XTF argo test:
  https://github.com/dozylynx/meta-argo/blob/master/recipes-extended/xen/xt=
f/0001-Add-Argo-test.patch
---
 docs/all-tests.dox      |   2 +
 include/xen/argo.h      | 259 +++++++++++++++++++++++++++++
 include/xtf/hypercall.h |   1 +
 include/xtf/numbers.h   |   5 +
 tests/argo/Makefile     |   9 +
 tests/argo/main.c       | 353 ++++++++++++++++++++++++++++++++++++++++
 6 files changed, 629 insertions(+)
 create mode 100644 include/xen/argo.h
 create mode 100644 tests/argo/Makefile
 create mode 100644 tests/argo/main.c

diff --git a/docs/all-tests.dox b/docs/all-tests.dox
index 566762c..1a7b4b7 100644
--- a/docs/all-tests.dox
+++ b/docs/all-tests.dox
@@ -178,6 +178,8 @@ states.
=20
 @section index-utility Utilities
=20
+@subpage test-argo - Argo functionality test
+
 @subpage test-cpuid - Print CPUID information.
=20
 @subpage test-fep - Test availability of HVM Forced Emulation Prefix.
diff --git a/include/xen/argo.h b/include/xen/argo.h
new file mode 100644
index 0000000..5ae2def
--- /dev/null
+++ b/include/xen/argo.h
@@ -0,0 +1,259 @@
+/*************************************************************************=
*****
+ * Argo : Hypervisor-Mediated data eXchange
+ *
+ * Derived from v4v, the version 2 of v2v.
+ *
+ * Copyright (c) 2010, Citrix Systems
+ * Copyright (c) 2018-2019, BAE Systems
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
+ * of this software and associated documentation files (the "Software"), t=
o
+ * deal in the Software without restriction, including without limitation =
the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, an=
d/or
+ * sell copies of the Software, and to permit persons to whom the Software=
 is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included=
 in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS=
 OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __XEN_PUBLIC_ARGO_H__
+#define __XEN_PUBLIC_ARGO_H__
+
+#define XEN_ARGO_DOMID_ANY       DOMID_INVALID
+
+/* The maximum size of an Argo ring is defined to be: 16MB (0x1000000 byte=
s). */
+#define XEN_ARGO_MAX_RING_SIZE  (0x1000000ULL)
+
+/* Fixed-width type for "argo port" number. Nothing to do with evtchns. */
+typedef uint32_t xen_argo_port_t;
+
+/* gfn type: 64-bit fixed-width on all architectures */
+typedef uint64_t xen_argo_gfn_t;
+
+/*
+ * XEN_ARGO_MAXIOV : maximum number of iovs accepted in a single sendv.
+ * Caution is required if this value is increased: this determines the siz=
e of
+ * an array of xen_argo_iov_t structs on the hypervisor stack, so could ca=
use
+ * stack overflow if the value is too large.
+ * The Linux Argo driver never passes more than two iovs.
+*/
+#define XEN_ARGO_MAXIOV          8U
+
+typedef struct xen_argo_iov
+{
+    unsigned long iov_hnd;
+    uint32_t iov_len;
+    uint32_t pad;
+} xen_argo_iov_t;
+
+typedef struct xen_argo_addr
+{
+    xen_argo_port_t aport;
+    domid_t domain_id;
+    uint16_t pad;
+} xen_argo_addr_t;
+
+typedef struct xen_argo_send_addr
+{
+    struct xen_argo_addr src;
+    struct xen_argo_addr dst;
+} xen_argo_send_addr_t;
+
+typedef struct xen_argo_ring
+{
+    /* Guests should use atomic operations to access rx_ptr */
+    uint32_t rx_ptr;
+    /* Guests should use atomic operations to access tx_ptr */
+    uint32_t tx_ptr;
+    /*
+     * Header space reserved for later use. Align the start of the ring to=
 a
+     * multiple of the message slot size.
+     */
+    uint8_t reserved[56];
+    uint8_t ring[];
+} xen_argo_ring_t;
+
+typedef struct xen_argo_register_ring
+{
+    xen_argo_port_t aport;
+    domid_t partner_id;
+    uint16_t pad;
+    uint32_t len;
+} xen_argo_register_ring_t;
+
+typedef struct xen_argo_unregister_ring
+{
+    xen_argo_port_t aport;
+    domid_t partner_id;
+    uint16_t pad;
+} xen_argo_unregister_ring_t;
+
+/* Messages on the ring are padded to a multiple of this size. */
+#define XEN_ARGO_MSG_SLOT_SIZE 0x10
+
+/*
+ * Notify flags
+ */
+/* Ring exists */
+#define XEN_ARGO_RING_EXISTS            (1U << 0)
+/* Ring is shared, not unicast */
+#define XEN_ARGO_RING_SHARED            (1U << 1)
+/* Ring is empty */
+#define XEN_ARGO_RING_EMPTY             (1U << 2)
+/* Sufficient space to queue space_required bytes might exist */
+#define XEN_ARGO_RING_SUFFICIENT        (1U << 3)
+/* Insufficient ring size for space_required bytes */
+#define XEN_ARGO_RING_EMSGSIZE          (1U << 4)
+/* Too many domains waiting for available space signals for this ring */
+#define XEN_ARGO_RING_EBUSY             (1U << 5)
+
+typedef struct xen_argo_ring_data_ent
+{
+    struct xen_argo_addr ring;
+    uint16_t flags;
+    uint16_t pad;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} xen_argo_ring_data_ent_t;
+
+typedef struct xen_argo_ring_data
+{
+    uint32_t nent;
+    uint32_t pad;
+
+    /*
+     * The Xen headers have:
+     *   struct xen_argo_ring_data_ent data[];
+     * here.  It's useful for the hypervisor side of the interface, but re=
ally
+     * not for the client side.
+     */
+} xen_argo_ring_data_t;
+
+struct xen_argo_ring_message_header
+{
+    uint32_t len;
+    struct xen_argo_addr source;
+    uint32_t message_type;
+    uint8_t data[];
+};
+
+/*
+ * Hypercall operations
+ */
+
+/*
+ * XEN_ARGO_OP_register_ring
+ *
+ * Register a ring using the guest-supplied memory pages.
+ * Also used to reregister an existing ring (eg. after resume from hiberna=
te).
+ *
+ * The first argument struct indicates the port number for the ring to reg=
ister
+ * and the partner domain, if any, that is to be allowed to send to the ri=
ng.
+ * A wildcard (XEN_ARGO_DOMID_ANY) may be supplied instead of a partner do=
mid,
+ * and if the hypervisor has wildcard sender rings enabled, this will allo=
w
+ * any domain (XSM notwithstanding) to send to the ring.
+ *
+ * The second argument is an array of guest frame numbers and the third ar=
gument
+ * indicates the size of the array. This operation only supports 4K-sized =
pages.
+ *
+ * arg1: XEN_GUEST_HANDLE(xen_argo_register_ring_t)
+ * arg2: XEN_GUEST_HANDLE(xen_argo_gfn_t)
+ * arg3: unsigned long npages
+ * arg4: unsigned long flags (32-bit value)
+ */
+#define XEN_ARGO_OP_register_ring     1
+
+/* Register op flags */
+/*
+ * Fail exist:
+ * If set, reject attempts to (re)register an existing established ring.
+ * If clear, reregistration occurs if the ring exists, with the new ring
+ * taking the place of the old, preserving tx_ptr if it remains valid.
+ */
+#define XEN_ARGO_REGISTER_FLAG_FAIL_EXIST  0x1
+
+#ifdef __XEN__
+/* Mask for all defined flags. */
+#define XEN_ARGO_REGISTER_FLAG_MASK XEN_ARGO_REGISTER_FLAG_FAIL_EXIST
+#endif
+
+/*
+ * XEN_ARGO_OP_unregister_ring
+ *
+ * Unregister a previously-registered ring, ending communication.
+ *
+ * arg1: XEN_GUEST_HANDLE(xen_argo_unregister_ring_t)
+ * arg2: NULL
+ * arg3: 0 (ZERO)
+ * arg4: 0 (ZERO)
+ */
+#define XEN_ARGO_OP_unregister_ring     2
+
+/*
+ * XEN_ARGO_OP_sendv
+ *
+ * Send a list of buffers contained in iovs.
+ *
+ * The send address struct specifies the source and destination addresses
+ * for the message being sent, which are used to find the destination ring=
:
+ * Xen first looks for a most-specific match with a registered ring with
+ *  (id.addr =3D=3D dst) and (id.partner =3D=3D sending_domain) ;
+ * if that fails, it then looks for a wildcard match (aka multicast receiv=
er)
+ * where (id.addr =3D=3D dst) and (id.partner =3D=3D DOMID_ANY).
+ *
+ * For each iov entry, send iov_len bytes from iov_base to the destination=
 ring.
+ * If insufficient space exists in the destination ring, it will return -E=
AGAIN
+ * and Xen will notify the caller when sufficient space becomes available.
+ *
+ * The message type is a 32-bit data field available to communicate messag=
e
+ * context data (eg. kernel-to-kernel, rather than application layer).
+ *
+ * arg1: XEN_GUEST_HANDLE(xen_argo_send_addr_t) source and dest addresses
+ * arg2: XEN_GUEST_HANDLE(xen_argo_iov_t) iovs
+ * arg3: unsigned long niov
+ * arg4: unsigned long message type (32-bit value)
+ */
+#define XEN_ARGO_OP_sendv               3
+
+/*
+ * XEN_ARGO_OP_notify
+ *
+ * Asks Xen for information about other rings in the system.
+ *
+ * ent->ring is the xen_argo_addr_t of the ring you want information on.
+ * Uses the same ring matching rules as XEN_ARGO_OP_sendv.
+ *
+ * ent->space_required : if this field is not null then Xen will check
+ * that there is space in the destination ring for this many bytes of payl=
oad.
+ * If the ring is too small for the requested space_required, it will set =
the
+ * XEN_ARGO_RING_EMSGSIZE flag on return.
+ * If sufficient space is available, it will set XEN_ARGO_RING_SUFFICIENT
+ * and CANCEL any pending notification for that ent->ring; otherwise it
+ * will schedule a notification event and the flag will not be set.
+ *
+ * These flags are set by Xen when notify replies:
+ * XEN_ARGO_RING_EXISTS     ring exists
+ * XEN_ARGO_RING_SHARED     ring is registered for wildcard partner
+ * XEN_ARGO_RING_EMPTY      ring is empty
+ * XEN_ARGO_RING_SUFFICIENT sufficient space for space_required is there
+ * XEN_ARGO_RING_EMSGSIZE   space_required is too large for the ring size
+ * XEN_ARGO_RING_EBUSY      too many domains waiting for available space s=
ignals
+ *
+ * arg1: XEN_GUEST_HANDLE(xen_argo_ring_data_t) ring_data (may be NULL)
+ * arg2: NULL
+ * arg3: 0 (ZERO)
+ * arg4: 0 (ZERO)
+ */
+#define XEN_ARGO_OP_notify              4
+
+#endif
diff --git a/include/xtf/hypercall.h b/include/xtf/hypercall.h
index 0d33807..17975ba 100644
--- a/include/xtf/hypercall.h
+++ b/include/xtf/hypercall.h
@@ -33,6 +33,7 @@
 extern uint8_t hypercall_page[PAGE_SIZE];
=20
 /* All Xen ABI for includers convenience .*/
+#include 
 #include 
 #include 
 #include 
diff --git a/include/xtf/numbers.h b/include/xtf/numbers.h
index f5c73b7..b0b2c1b 100644
--- a/include/xtf/numbers.h
+++ b/include/xtf/numbers.h
@@ -52,6 +52,11 @@
  */
 #define _u(v) ((unsigned long)(v))
=20
+/**
+ * Round up a number to the next integer
+ */
+#define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))
+
 #endif /* !__ASSEMBLY__ */
 #endif /* XTF_NUMBERS_H */
=20
diff --git a/tests/argo/Makefile b/tests/argo/Makefile
new file mode 100644
index 0000000..c6b3113
--- /dev/null
+++ b/tests/argo/Makefile
@@ -0,0 +1,9 @@
+include $(ROOT)/build/common.mk
+
+NAME      :=3D argo
+CATEGORY  :=3D in-development
+TEST-ENVS :=3D $(ALL_ENVIRONMENTS)
+
+obj-perenv +=3D main.o
+
+include $(ROOT)/build/gen.mk
diff --git a/tests/argo/main.c b/tests/argo/main.c
new file mode 100644
index 0000000..fa54aed
--- /dev/null
+++ b/tests/argo/main.c
@@ -0,0 +1,353 @@
+/**
+ * @file tests/argo/main.c
+ * @ref test-argo
+ *
+ * @page test-argo argo
+ *
+ * @todo Docs for test-argo
+ *
+ * @see tests/argo/main.c
+ */
+#include 
+
+const char test_title[] =3D "Argo hypercall test";
+
+/*
+ * The current Linux Argo driver has a default ring size of 32 4k pages,
+ * so follow that for the test ring size.
+ */
+static uint8_t ring_buffer[32 * PAGE_SIZE] __page_aligned_bss;
+#define TEST_RING_NPAGES (sizeof(ring_buffer) / PAGE_SIZE)
+
+static int probe_for_argo(domid_t own_domid)
+{
+    /* Attempt an Argo call to register a ring with invalid arguments */
+    xen_argo_register_ring_t reg =3D {
+        .aport      =3D 1,
+        .partner_id =3D own_domid,
+        .len        =3D 1, /* A 1-byte ring is never allowed */
+    };
+    int rc =3D hypercall_argo_op(XEN_ARGO_OP_register_ring, ®, NULL, 0,=
 0);
+
+    switch ( rc )
+    {
+    case -EINVAL: /* This is the response we are looking for */
+        return 0;
+
+        /* All below here are test exit conditions */
+    case -ENOSYS:
+        xtf_skip("Skip: Argo support has not been enabled in this hypervis=
or\n");
+        break;
+    case -EOPNOTSUPP:
+        xtf_skip("Skip: Argo is not enabled at runtime for this hypervisor=
\n");
+        break;
+    case -ENODEV:
+        xtf_skip("Skip: Argo is not enabled for this domain\n");
+        break;
+
+    case -EPERM:
+        xtf_failure("Fail: ring registration by this domain is not permitt=
ed\n");
+        break;
+    case 0:
+        xtf_failure("Fail: an invalid ring register op was not rejected\n"=
);
+        break;
+    default:
+        xtf_failure("Fail: unknown error %d for invalid ring registration\=
n", rc);
+        break;
+    }
+
+    return -1;
+}
+
+/* notify: asks Xen for information about rings */
+static int
+test_notify_for_one_ring(domid_t query_domid, xen_argo_port_t query_port,
+                         bool exists)
+{
+    struct {
+        xen_argo_ring_data_t data;
+        xen_argo_ring_data_ent_t ents[1];
+    } notify =3D {
+        .data =3D {
+            .nent =3D ARRAY_SIZE(notify.ents),
+        },
+        .ents =3D {
+            {
+                .ring =3D {
+                    .domain_id =3D query_domid,
+                    .aport     =3D query_port,
+                },
+            },
+        },
+    };
+    int rc =3D hypercall_argo_op(XEN_ARGO_OP_notify, ¬ify, NULL, 0, 0);
+
+    if ( rc )
+    {
+        xtf_failure("Fail: Unexpected error code %d in notify test\n", rc)=
;
+        return -1;
+    }
+
+    if ( !exists )
+    {
+        /* No currently-defined flags should be set for a non-existent rin=
g */
+        if ( notify.ents[0].flags )
+        {
+            xtf_failure("Fail: Non-existent ring reported as existing\n");
+            return -1;
+        }
+    }
+    else
+    {
+        if ( !(notify.ents[0].flags & XEN_ARGO_RING_EXISTS) )
+        {
+            xtf_failure("Fail: Ring not reported as existing\n");
+            return -1;
+        }
+    }
+
+    return 0;
+}
+
+/* See the Argo Linux device driver for similar use of these macros */
+#define XEN_ARGO_ROUNDUP(x) roundup((x), XEN_ARGO_MSG_SLOT_SIZE)
+#define ARGO_RING_OVERHEAD 80
+#define TEST_RING_SIZE(npages)                                      \
+    (XEN_ARGO_ROUNDUP((((PAGE_SIZE)*npages) - ARGO_RING_OVERHEAD)))
+
+static int
+test_register_ring(domid_t own_domid, xen_argo_port_t aport)
+{
+    unsigned int i;
+    xen_argo_register_ring_t reg =3D {
+        .aport      =3D aport,
+        .partner_id =3D own_domid,
+        .len        =3D TEST_RING_SIZE(TEST_RING_NPAGES),
+    };
+    xen_argo_gfn_t gfns[TEST_RING_NPAGES];
+
+    for ( i =3D 0; i < TEST_RING_NPAGES; i++ )
+        gfns[i] =3D virt_to_gfn(ring_buffer + (i * PAGE_SIZE));
+
+    int rc =3D hypercall_argo_op(XEN_ARGO_OP_register_ring, ®, &gfns,
+                               TEST_RING_NPAGES, XEN_ARGO_REGISTER_FLAG_FA=
IL_EXIST);
+    switch ( rc )
+    {
+    case 0:
+        return 0;
+
+    case -ENODEV:
+        xtf_failure("Fail: Argo is not enabled for this domain\n");
+        break;
+    case -EFAULT:
+        xtf_failure("Fail: Memory fault performing register ring test\n");
+        break;
+    default:
+        xtf_failure("Fail: Unexpected error code %d in register ring test\=
n", rc);
+        break;
+    }
+    return -1;
+}
+
+static int
+test_unregister_ring(domid_t partner_domid, xen_argo_port_t aport,
+                     bool exists)
+{
+    xen_argo_register_ring_t unreg =3D {
+        .aport      =3D aport,
+        .partner_id =3D partner_domid,
+    };
+    int rc =3D hypercall_argo_op(XEN_ARGO_OP_unregister_ring, &unreg, NULL=
, 0, 0);
+
+    switch ( rc )
+    {
+    case 0:
+        if ( exists )
+            return 0;
+        xtf_failure("Fail: unexpected success unregistering non-existent r=
ing\n");
+        return -1;
+
+    case -ENOENT:
+        if ( !exists )
+            return 0;
+        xtf_failure("Fail: unexpected ring not found when unregistering \n=
");
+        return -1;
+
+    default:
+        xtf_failure("Fail: Unexpected error code %d in unregister ring tes=
t\n", rc);
+        break;
+    }
+    return -1;
+}
+
+static int
+test_sendv(domid_t src_domid, xen_argo_port_t src_aport,
+           domid_t dst_domid, xen_argo_port_t dst_aport,
+           const char *msg_text, size_t msg_len, unsigned int msg_type)
+{
+    xen_argo_send_addr_t send_addr =3D {
+        .src =3D {
+            .domain_id =3D src_domid,
+            .aport     =3D src_aport,
+        },
+        .dst =3D {
+            .domain_id =3D dst_domid,
+            .aport     =3D dst_aport,
+        },
+    };
+    xen_argo_iov_t iovs[] =3D {
+        {
+            .iov_hnd =3D _u(msg_text),
+            .iov_len =3D msg_len,
+        },
+    };
+    int rc =3D hypercall_argo_op(XEN_ARGO_OP_sendv, &send_addr,
+                               iovs, ARRAY_SIZE(iovs), msg_type);
+
+    if ( rc < 0 )
+    {
+        xtf_failure("Fail: Unexpected error code %d in sendv test\n", rc);
+        return -1;
+    }
+
+    if ( (size_t)rc !=3D msg_len )
+    {
+        xtf_failure("Fail: Unexpected message size %d written in sendv tes=
t\n", rc);
+        return -1;
+    }
+
+    return 0;
+}
+
+static int
+inspect_ring_after_first_single_sendv(domid_t src_domid,
+                                      xen_argo_port_t src_aport,
+                                      const char *sent_msg,
+                                      unsigned int sent_msg_len,
+                                      unsigned int sent_msg_type)
+{
+    int rc =3D 0;
+    xen_argo_ring_t *ringp =3D (xen_argo_ring_t *)ring_buffer;
+    struct xen_argo_ring_message_header *msg_hdr;
+    unsigned int sent_length;
+
+    if ( ringp->rx_ptr !=3D 0 )
+    {
+        xtf_failure("Fail: receive pointer non-zero after sendv: %u\n",
+                    ringp->rx_ptr);
+        rc =3D -1;
+    }
+
+    if ( ringp->tx_ptr !=3D XEN_ARGO_ROUNDUP(
+             sizeof(struct xen_argo_ring_message_header) + sent_msg_len) )
+    {
+        xtf_failure("Fail: transmit pointer incorrect after sendv: %u\n",
+                    ringp->rx_ptr);
+        rc =3D -1;
+    }
+
+    msg_hdr =3D (struct xen_argo_ring_message_header *)&(ringp->ring);
+
+    if ( msg_hdr->source.domain_id !=3D src_domid )
+    {
+        xtf_failure("Fail: source domain id incorrect: %u, expected %u\n",
+                    msg_hdr->source.domain_id, src_domid);
+        rc =3D -1;
+    }
+
+    if ( msg_hdr->source.aport !=3D src_aport )
+    {
+        xtf_failure("Fail: source domain port incorrect: %u, expected %u\n=
",
+                    msg_hdr->source.domain_id, src_aport);
+        rc =3D -1;
+    }
+
+    if ( msg_hdr->source.pad !=3D 0 )
+    {
+        xtf_failure("Fail: source padding incorrect: %u, expected zero\n",
+                    msg_hdr->source.pad);
+        rc =3D -1;
+    }
+
+    if ( sent_msg_type !=3D msg_hdr->message_type )
+    {
+        xtf_failure("Fail: message type incorrect: %u sent, %u received\n"=
,
+                    sent_msg_type, msg_hdr->message_type);
+        rc =3D -1;
+    }
+
+    sent_length =3D sent_msg_len + sizeof(struct xen_argo_ring_message_hea=
der);
+    if ( sent_length !=3D msg_hdr->len )
+    {
+        xtf_failure("Fail: received message length incorrect: "
+                    "%u sent is %u with header added, %u received\n",
+                    sent_msg_len, sent_length, msg_hdr->len);
+        rc =3D -1;
+    }
+
+    if ( strncmp((const char *)msg_hdr->data, sent_msg, sent_msg_len) )
+    {
+        xtf_failure("Fail: sent message got mangled\n");
+        rc =3D -1;
+    }
+
+    return rc;
+}
+
+static void clear_test_ring(void)
+{
+    memset(ring_buffer, 0, sizeof(ring_buffer));
+}
+
+void test_main(void)
+{
+    int own_domid;
+    xen_argo_port_t test_aport =3D 1;
+    const char simple_text[] =3D "a simple thing to send\n";
+    const unsigned int msg_type =3D 0x12345678;
+
+    own_domid =3D xtf_get_domid();
+    if ( own_domid < 0 )
+        return xtf_error("Error: could not determine domid of the test dom=
ain\n");
+
+    /* First test validates for Argo availability to gate further testing =
*/
+    if ( probe_for_argo(own_domid) )
+        return;
+
+    if ( test_notify_for_one_ring(own_domid, test_aport, false) ||
+         test_unregister_ring(own_domid, test_aport, false) )
+        return;
+
+    clear_test_ring();
+
+    if ( test_register_ring(own_domid, test_aport) ||
+         test_notify_for_one_ring(own_domid, test_aport, true) ||
+         test_unregister_ring(own_domid, test_aport, true) ||
+         test_notify_for_one_ring(own_domid, test_aport, false) ||
+         test_unregister_ring(own_domid, test_aport, false) )
+        return;
+
+    clear_test_ring();
+
+    if ( test_register_ring(own_domid, test_aport) ||
+         test_sendv(own_domid, test_aport, own_domid, test_aport,
+                    simple_text, strlen(simple_text), msg_type) ||
+         inspect_ring_after_first_single_sendv(
+             own_domid, test_aport, simple_text, strlen(simple_text), msg_=
type) ||
+         test_notify_for_one_ring(own_domid, test_aport, true) ||
+         test_unregister_ring(own_domid, test_aport, true) ||
+         test_unregister_ring(own_domid, test_aport, false) )
+        return;
+
+    xtf_success(NULL);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 21 21:18:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 21:18:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992596.1376289 (Exim 4.92)
	(envelope-from )
	id 1uHqpR-0008VE-4k; Wed, 21 May 2025 21:18:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992596.1376289; Wed, 21 May 2025 21:18: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 1uHqpR-0008V3-1h; Wed, 21 May 2025 21:18:21 +0000
Received: by outflank-mailman (input) for mailman id 992596;
 Wed, 21 May 2025 21:18:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHqpQ-000898-62
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 21:18:20 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1e5e67e6-3689-11f0-a2fb-13f23c93f187;
 Wed, 21 May 2025 23:18: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" 
X-Inumbo-ID: 1e5e67e6-3689-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747862299; x=1748121499;
	bh=/UcRWNMCCCUoiYtm7Wrs8tukKW7vOxsjOSokpJV8UrA=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=M3JWmX/vfI44QNSMSA28PYxC3uwhrg8XMn3OXTG5SbJx9VXtw3ly1JAd4pq4GgN11
	 MGO3rCDJjXPsZgsgFxKS1doAXuIEghczcIc+bphZ4jO9Dxe1mO/yZ9snAIAXkzklPE
	 PxfNRHMincYzljL9MHA+a1kqZtWbHfKak5kDubIGmZ7iAwaSTXEg9SaxjW6CjIwgb5
	 ygBRfwTXZtK2Phf/hBlpHm/AHB5tkJuBgVeYEDxh1Uv8feWgq46FDmTrloQznceXNI
	 SbKKrJPiV96DV0s94CGEeq4WeZYkKoR0avxKGMpiWDSSonCLEFYoBBpulkIn+H+NUp
	 dm/XdJ9sYYX/g==
Date: Wed, 21 May 2025 21:18:07 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, christopher.w.clark@gmail.com, dpsmith@apertussolutions.com, michal.orzel@amd.com, persaur@gmail.com, dmukhin@ford.com
Subject: [XTF PATCH v2 2/2] tests/argo: use event channel to get own domain ID
Message-ID: <20250521211742.2997890-3-dmukhin@ford.com>
In-Reply-To: <20250521211742.2997890-1-dmukhin@ford.com>
References: <20250521211742.2997890-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 46d7215b2575f92a98c23629adea5ebfe1e15c92
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

The existing argo test depends on xenstore to retrieve the domain ID.

Also, test does not perform peer-to-peer communication using Argo hypercall=
, it
communicates with itself.

Since xenstore currently runs in dom0, xenstore adds unnecessary dependency=
 on
dom0 for the test in x86 QEMU environment.

Use event channel to identify the domain ID which eliminates dom0 dependenc=
y
for the test.

Signed-off-by: Denis Mukhin 
---
Changes since v1:
- dropped hack of hardcoding test's own domain ID to 0, reworked getting ow=
n
  domain ID by relying on message channel.

Thanks to Michal Orzel and Andrew Cooper for helping with that.
---
 common/lib.c                | 34 +++++++++++++++++++++++++++++++++-
 include/xen/event_channel.h | 34 ++++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/common/lib.c b/common/lib.c
index 58f4965..c37347a 100644
--- a/common/lib.c
+++ b/common/lib.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
=20
 #ifndef isdigit
 /* Avoid pulling in all of ctypes just for this. */
@@ -44,12 +45,43 @@ int xtf_probe_sysctl_interface_version(void)
     return -1;
 }
=20
+static domid_t get_domid_from_evtchn(void)
+{
+    union {
+        struct evtchn_alloc_unbound alloc;
+        struct evtchn_status status;
+        struct evtchn_close close;
+    } op;
+    evtchn_port_t port;
+    int rc;
+
+    op.alloc.dom =3D DOMID_SELF;
+    op.alloc.remote_dom =3D DOMID_SELF;
+    rc =3D hypercall_event_channel_op(EVTCHNOP_alloc_unbound, &op.alloc);
+    if ( rc )
+        return -1;
+
+    port =3D op.alloc.port;
+
+    op.status.dom =3D DOMID_SELF;
+    op.status.port =3D port;
+    rc =3D hypercall_event_channel_op(EVTCHNOP_status, &op.status);
+    if ( !rc )
+        rc =3D op.status.u.unbound.dom;
+
+    op.close.port =3D port;
+    /* NB: no need to check the return code */
+    (void)hypercall_event_channel_op(EVTCHNOP_close, &op.close);
+
+    return rc;
+}
+
 int xtf_get_domid(void)
 {
     int rc =3D xenstore_init();
=20
     if ( rc )
-        return -1;
+        return get_domid_from_evtchn();
=20
     const char *str =3D xenstore_read("domid");
     unsigned int domid =3D 0;
diff --git a/include/xen/event_channel.h b/include/xen/event_channel.h
index bef0f46..7d89ac3 100644
--- a/include/xen/event_channel.h
+++ b/include/xen/event_channel.h
@@ -3,7 +3,9 @@
=20
 #include 
=20
+#define EVTCHNOP_close            3
 #define EVTCHNOP_send             4
+#define EVTCHNOP_status           5
 #define EVTCHNOP_alloc_unbound    6
 #define EVTCHNOP_init_control    11
 #define EVTCHNOP_expand_array    12
@@ -32,6 +34,38 @@ struct evtchn_expand_array {
     uint64_t array_gfn;
 };
=20
+struct evtchn_close {
+    /* IN parameters. */
+    evtchn_port_t port;
+};
+
+#define EVTCHNSTAT_closed       0  /* Channel is not in use.              =
   */
+#define EVTCHNSTAT_unbound      1  /* Channel is waiting interdom connecti=
on.*/
+#define EVTCHNSTAT_interdomain  2  /* Channel is connected to remote domai=
n. */
+#define EVTCHNSTAT_pirq         3  /* Channel is bound to a phys IRQ line.=
   */
+#define EVTCHNSTAT_virq         4  /* Channel is bound to a virtual IRQ li=
ne */
+#define EVTCHNSTAT_ipi          5  /* Channel is bound to a virtual IPI li=
ne */
+
+struct evtchn_status {
+    /* IN parameters */
+    domid_t  dom;
+    evtchn_port_t port;
+    /* OUT parameters */
+    uint32_t status;
+    uint32_t vcpu;                 /* VCPU to which this channel is bound.=
   */
+    union {
+        struct {
+            domid_t dom;
+        } unbound;                 /* EVTCHNSTAT_unbound */
+        struct {
+            domid_t dom;
+            evtchn_port_t port;
+        } interdomain;             /* EVTCHNSTAT_interdomain */
+        uint32_t pirq;             /* EVTCHNSTAT_pirq        */
+        uint32_t virq;             /* EVTCHNSTAT_virq        */
+    } u;
+};
+
 #endif /* XEN_PUBLIC_EVENT_CHANNEL_H */
=20
 /*
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 21 21:37:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 21 May 2025 21:37:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992618.1376300 (Exim 4.92)
	(envelope-from )
	id 1uHr8E-0003cQ-LU; Wed, 21 May 2025 21:37:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992618.1376300; Wed, 21 May 2025 21:37: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 1uHr8E-0003cJ-Iz; Wed, 21 May 2025 21:37:46 +0000
Received: by outflank-mailman (input) for mailman id 992618;
 Wed, 21 May 2025 21:37:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHr8E-0003cD-2Y
 for xen-devel@lists.xenproject.org; Wed, 21 May 2025 21:37:46 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d3138249-368b-11f0-b892-0df219b8e170;
 Wed, 21 May 2025 23:37:42 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43d2d952eb1so58780495e9.1
 for ; Wed, 21 May 2025 14:37:42 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a360b0b766sm20633531f8f.56.2025.05.21.14.37.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 14:37: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" 
X-Inumbo-ID: d3138249-368b-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747863461; x=1748468261; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=GpPVPXCCPXF7BOwGXNat6gwQ/ZskJE75+M8RZ/VSvII=;
        b=gOcxIp09NPkpjYPE0hFLfUvPRQ3iw2+Wo8WWTep8wSAcEEq28LTpnBlHVYa3tXq7kS
         mK+AqFET0EYARIvpJ1WUJEqVsyK32gY/3YCpGXXCI1MEyRdSZwcelyFm6hWmktEDqkLe
         Zz9HEffXqiFcRpqnXgYtbBiOQ4WWK7uctmyvU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747863461; x=1748468261;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GpPVPXCCPXF7BOwGXNat6gwQ/ZskJE75+M8RZ/VSvII=;
        b=YagNrVq+dRtIKqDY5NSlbqHbABuQFg2C6XGh+73Ym+Wgu3bgN/aiz9EP6DNizzG7m1
         WFHN6bx4DsRl0pc/b5eDyKdYjT7dDpWmul34blFDRoofzxYsPpenWiSJo6DfTPxpXjBV
         q8i8MS+BuZuYgsXWkhe79CUGC2i3WMLIbqbSY4QmZVyDOUm+oUmB7VtVEp191xeV7PH2
         +oj24WW9F/vOlID4m56qhbkJFq0NMMVG67OjMsmFJfiW2sr+4Bf9X5C+IKO51GKouB5E
         ACcBvI9WauESsRC1xKrL8QeZ66Ux+VpE1XHpXE1WOv4XwH/s708FrctfXdpIvMQCHm2d
         0oxA==
X-Forwarded-Encrypted: i=1; AJvYcCU+cfGTTOPI3f9ojNfUpVHaeFRIenq1TyPtNx5yxa1xRyciFJuqZTJleWiX4Hl5FKthbtNHij7yCQU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyEw8nASfxNv/ZgGlnDfS2/p8IsOBA/vxxYNv9/kBHgThdVEIKH
	Nj051rGSiSHnqcD8xo7s8Erd1Uqxj0oAVtLBoUzQxarEypKfpAUzgrNyOZd/LSpudrQ=
X-Gm-Gg: ASbGncuPNNrkg9TeYGhNwNNuLxNsSI64PIy397n5Oj7MWN1aWqatf/Sk4eS+YsZ0grl
	FSE2pXzVNUNiMVcLLMOY/jm+F4qlbX/+7MxJgafr6B9JuIIvqC3ZRee8u1JB3EoHhDDrmeHpNy/
	w5iKcwwiKZYOfBBoyq/ZouQQdZVeBkHENyMov9VD4vQIS17RAQvq31RQ1EubhmVLnQB1Emb9PA7
	SUV2o0LsfgT8CYbFWLhxNZitqVhqBroVojgaL3o16e/5jYVPreYlMdp0H0fSE3Br+mSgFtoN08c
	aaK9r/tQGl/c7reUZYTyw/eBKQG+ENiAD9jFYIMvEn9wxBtV3XONYbDtBOhcRqYPNzzBcTM5W+C
	IYt7qr3lGBRnyzo42
X-Google-Smtp-Source: AGHT+IG7j7fTiCb7HixBcTg2DDSPGF0YhzCcauQTNEN39hdXWtacDaJ3x86PMRl9BDGptA2oj/utag==
X-Received: by 2002:a05:600c:1d88:b0:442:ccf9:e6f2 with SMTP id 5b1f17b1804b1-442fd64452bmr269549855e9.16.1747863461365;
        Wed, 21 May 2025 14:37:41 -0700 (PDT)
Message-ID: <850d4bf8-3e98-4aee-9d41-e298be34893a@citrix.com>
Date: Wed, 21 May 2025 22:37:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XTF PATCH v2 2/2] tests/argo: use event channel to get own
 domain ID
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, dpsmith@apertussolutions.com,
 michal.orzel@amd.com, persaur@gmail.com, dmukhin@ford.com
References: <20250521211742.2997890-1-dmukhin@ford.com>
 <20250521211742.2997890-3-dmukhin@ford.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: <20250521211742.2997890-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21/05/2025 10:18 pm, dmkhn@proton.me wrote:
> From: Denis Mukhin 
>
> The existing argo test depends on xenstore to retrieve the domain ID.
>
> Also, test does not perform peer-to-peer communication using Argo hypercall, it
> communicates with itself.
>
> Since xenstore currently runs in dom0, xenstore adds unnecessary dependency on
> dom0 for the test in x86 QEMU environment.
>
> Use event channel to identify the domain ID which eliminates dom0 dependency
> for the test.
>
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v1:
> - dropped hack of hardcoding test's own domain ID to 0, reworked getting own
>   domain ID by relying on message channel.
>
> Thanks to Michal Orzel and Andrew Cooper for helping with that.

Thanks, although this needs integrating into the pending series I've
already got.  Notably, we want to use the CPUID if it's available.

It also needs to be ahead of the argo test to avoid a bisection hazard.

I'll pick this up and sort things out.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu May 22 00:10:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 00:10:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992686.1376310 (Exim 4.92)
	(envelope-from )
	id 1uHtVc-00063a-BE; Thu, 22 May 2025 00:10:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992686.1376310; Thu, 22 May 2025 00: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 1uHtVc-00063C-7j; Thu, 22 May 2025 00:10:04 +0000
Received: by outflank-mailman (input) for mailman id 992686;
 Thu, 22 May 2025 00:10:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHtVZ-0005Te-Cq
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 00:10:02 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 18f2aaea-36a1-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 02:09:58 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 18f2aaea-36a1-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747872596; x=1748131796;
	bh=8SGp7iqkXDG1CAs0VeJxvwQn3LebWCkVpH6lLj3zYmM=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=S39zSfRr0VHR3ES902M1mHiw85KlyXLcTe5iIeXD6DzrOGg00dGKroE575QNkavp2
	 d/hFGT726vAsEyR05h6L37a0ie+DQRSVGFS/bazga00CcJhVEnXLQktisOOGG2JJZ5
	 FOwfhxXjWMzE5f79wDkszGwbc0pypnWk5VvGBXUUtmugMjj8YvsTL8xwTTgH4g6+VU
	 ktAUwYHaMFiBXYCiG9n/TunrMJq2ng1/s4obFdNsVf28Ut3LV2ChcCNM3hCM1JsGgF
	 MXgkxMVXzMB+MPpNVDZTpCx2IOWHJwZbp4Wrp51zVfn9/4dGHc1nXzYBn6481rbOUL
	 j5R7+Y4Cg9rDQ==
Date: Thu, 22 May 2025 00:09:49 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v8 3/3] xen/domain: introduce CONFIG_MAX_DOMID
Message-ID: 
In-Reply-To: <54945bd5-333e-4ffd-8ff1-bb89d22c7ef4@suse.com>
References: <20250521000024.2944685-1-dmukhin@ford.com> <20250521000024.2944685-4-dmukhin@ford.com> <54945bd5-333e-4ffd-8ff1-bb89d22c7ef4@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: def13c5d2fef9ab1ee42ce23559f2b90b90c2703
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 21, 2025 at 09:31:34AM +0200, Jan Beulich wrote:
> On 21.05.2025 02:00, dmkhn@proton.me wrote:
> > --- a/xen/arch/arm/tee/ffa.c
> > +++ b/xen/arch/arm/tee/ffa.c
> > @@ -331,10 +331,9 @@ static int ffa_domain_init(struct domain *d)
> >       * reserved for the hypervisor and we only support secure endpoint=
s using
> >       * FF-A IDs with BIT 15 set to 1 so make sure those are not used b=
y Xen.
> >       */
> > -    BUILD_BUG_ON(DOMID_FIRST_RESERVED >=3D UINT16_MAX);
>=20
> Why's this being moved to common code? It certainly may have a purpose he=
re
> (which I'm simply unaware of); I don't see what purpose it has in common
> code.

My understanding having DOMID_FIRST_RESERVED compile-time checks in one pla=
ce
is good for testability: the check in question also applies to x86.

I will drop that hunk.

>=20
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -576,4 +576,11 @@ config BUDDY_ALLOCATOR_SIZE
> >  =09  Amount of memory reserved for the buddy allocator to serve Xen he=
ap,
> >  =09  working alongside the colored one.
> >
> > +config MAX_DOMID
> > +=09int "Maximum number of user domains"
> > +=09range 1 32752
> > +=09default 32752
> > +=09help
> > +=09  Specifies the maximum number of domains a user can create.
>=20
> My prior comment remains: The description and help needs to be accurate, =
in
> order to not cause any confusion. In a true dom0less environment I'm not
> sure the "user" can create any domains (post boot, that is). And when the=
re
> is Dom0 (or late hwdom), the number specified already isn't the number of
> domains one can create (again, post boot, which is how I understand "user
> domains"). If someone picked 1 as the value here, it's unclear to me how
> late hwdom or dom0less would work in the first place.

Do you think something like the following will be more accurate?

    config MAX_DOMID
       int "Maximum number of domains"
       range 1 32752
       default 32752
       help
         Specifies the maximum number of domains: dom0 or late hwdom,
         predefined domains, post-boot domains, excluding Xen system domain=
s
         (domid >=3D DOMID_FIRST_RESERVED).

>=20
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -36,7 +36,7 @@
> >
> >  /*
> >   * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> > - * If it is specified as an invalid value (0 or >=3D DOMID_FIRST_RESER=
VED),
> > + * If it is specified as an invalid value (0 or >=3D CONFIG_MAX_DOMID)=
,
>=20
> In the public interface I question the relevance of any implementation
> details of the hypervisor.

Ack, will revert.

>=20
> Jan
>=20



From xen-devel-bounces@lists.xenproject.org Thu May 22 00:25:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 00:25:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992693.1376321 (Exim 4.92)
	(envelope-from )
	id 1uHtk1-00089a-IL; Thu, 22 May 2025 00:24:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992693.1376321; Thu, 22 May 2025 00:24: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 1uHtk1-00089T-Dl; Thu, 22 May 2025 00:24:57 +0000
Received: by outflank-mailman (input) for mailman id 992693;
 Thu, 22 May 2025 00:24:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHtk0-00089N-Vl
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 00:24:56 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2ecb0c06-36a3-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 02:24: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" 
X-Inumbo-ID: 2ecb0c06-36a3-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747873492; x=1748132692;
	bh=oRMZKwwLtE0DcPcKZiclDXzlGPmbErHhf3v77GZJy3M=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=Vi+RZARNYyc8RNMTKilB9DXXREtMiUFOTQ3HoJP1iwOtbm3rtsX9Vzy4bEW0iSvMs
	 Dqa7w77VIFZ+/UsX81J7HF28rWblWMvifoD5EWXgWtk9FKOI/RLAw81htEwdEuDqZG
	 RvoUe2tDsDgCar9z99X0uagC8u2RCw8M/MCtD3+9RITXQTrOty03omoFlwlj9zoD6L
	 aJoEklL2+R/1yj+C4WRl0fLq/3WgXP5YXm01x4m5fbMmWggtd5GppT6O5PvcVFn3kS
	 Of7TD+XbMSJBNt1Q7Qa0kuerXF08P91LAMDrC+2QynjFnhSDpz4DKFDGlBR6NrilOr
	 Egg0htz2WbuNg==
Date: Thu, 22 May 2025 00:24:45 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v8 1/3] xen/domain: unify domain ID allocation
Message-ID: 
In-Reply-To: <675950c9-f48a-489e-9ca1-816d876fbcbb@suse.com>
References: <20250521000024.2944685-1-dmukhin@ford.com> <20250521000024.2944685-2-dmukhin@ford.com> <675950c9-f48a-489e-9ca1-816d876fbcbb@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 24fe2a01789c13baef5ffb7815e8a03ff70f2ce0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 21, 2025 at 10:02:52AM +0200, Jan Beulich wrote:
> On 21.05.2025 02:00, dmkhn@proton.me wrote:
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -66,6 +66,11 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
> >  static struct domain *domain_hash[DOMAIN_HASH_SIZE];
> >  struct domain *domain_list;
> >
> > +/* Non-system domain ID allocator. */
> > +static DEFINE_SPINLOCK(domid_lock);
> > +static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
> > +static domid_t domid_last;
>=20
> Please move this into the narrowest possible scope. No reason to expose
> it to the entire CU.

Will do.

>=20
> > @@ -2405,6 +2412,46 @@ domid_t get_initial_domain_id(void)
> >      return hardware_domid;
> >  }
> >
> > +domid_t domid_alloc(domid_t domid)
> > +{
> > +    spin_lock(&domid_lock);
> > +
> > +    if ( domid < DOMID_FIRST_RESERVED )
> > +    {
> > +        if ( __test_and_set_bit(domid, domid_bitmap) )
> > +            domid =3D DOMID_INVALID;
> > +    }
> > +    else
> > +    {
> > +        domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVE=
D,
> > +                                   domid_last);
> > +
> > +        if ( domid =3D=3D DOMID_FIRST_RESERVED )
> > +            domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RES=
ERVED, 0);
>=20
> Despite what the last sentence of the description says, there is a subtle
> behavioral change here: The original code would never return what was
> called "rover" there. If the most recently created domain went away, you
> would return its ID again here if no other ID is free (which is easier to
> run into with patch 3 in place, and MAX_DOMID set to a pretty low value).
> (Noticing only later: This could even occur without wrapping, as the last
> argument passed is just domid_last, without adding in 1.)

Thanks for spotting the problem!

>=20
> I agree it's debatable whether using the sole available ID instead of
> failing wouldn't be better(?) behavior in this specific case, but such
> definitely can't go silently.
>=20
> Furthermore you once again are potentially returning ID 0 here (after
> wrapping), when the original code specifically avoided that (irrespective
> of there actually being a Dom0, that is; i.e. covering both the dom0less
> case and the late-hwdom one).
>=20
> To be frank, being at v8 I find it problematic that there still are
> (unmentioned and potentially unwanted) behavioral changes here. This
> kind of supports my earlier raised question of whether we actually want
> this sort of a change.

I appreciate patience and the feedback for the series!

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Thu May 22 00:25:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 00:25:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992697.1376330 (Exim 4.92)
	(envelope-from )
	id 1uHtko-0000Ba-Pp; Thu, 22 May 2025 00:25:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992697.1376330; Thu, 22 May 2025 00:25: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 1uHtko-0000BT-MC; Thu, 22 May 2025 00:25:46 +0000
Received: by outflank-mailman (input) for mailman id 992697;
 Thu, 22 May 2025 00:25:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHtkn-00009y-8K
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 00:25:45 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4aea82e5-36a3-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 02:25:42 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id B070A44C4E;
 Thu, 22 May 2025 00:25:40 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B928CC4CEE4;
 Thu, 22 May 2025 00:25: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" 
X-Inumbo-ID: 4aea82e5-36a3-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1747873540;
	bh=iHJRHfIUDt6gGcKdt2Sy8LmCQtH7tBgOHKMOKeVYDsc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=DBCtZatiWRca9YFOmpAOgxLcwZpIwXStPZKmWf/9xASOGAM4WmQk0R865A5nv0S48
	 AA6xSQXyv4TulC+ZIF0arZS4Qbt2pCJbbw6lGOVyQp/4G+RY5cYU1kiz3Ye9gE+6V0
	 9g1iEbDCKW6iNAeo/blY5Rx7qztQI8fW+ZvQlwvYJWObi3gGZypD05j9mGPYtSnBg7
	 ys2HWyJqEJ/Qo3XgXblt6v4B3Hocn6DmED/aX/QQBvOLdywSn/a4Dc9/DjWS+uR6qC
	 2CiE+5QGAv2QC863Ge0h9ITFcMRZ8av3jHaHWdfHWQ//u69xCvAVg7YnvJ37xIIAGw
	 tNOHkNooikAuA==
Date: Wed, 21 May 2025 17:25:37 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
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?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device
 to handle not only iommu
In-Reply-To: <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
Message-ID: 
References:  <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> From: Grygorii Strashko 
> 
> Add chained handling of assigned DT devices to support access-controller
> functionality through SCI framework, so DT device assign request can be
> passed to FW for processing and enabling VM access to requested device
> (for example, device power management through FW interface like SCMI).
> 
> The SCI access-controller DT device processing is chained after IOMMU
> processing and expected to be executed for any DT device regardless of its
> protection by IOMMU (or if IOMMU is disabled).
> 
> This allows to pass not only IOMMU protected DT device through
> xl.cfg:"dtdev" property for processing:
> 
> dtdev = [
>     "/soc/video@e6ef0000", <- IOMMU protected device
>     "/soc/i2c@e6508000", <- not IOMMU protected device
> ]
> 
> The change is done in two parts:
> 1) update iommu_do_dt_domctl() to check for dt_device_is_protected() and
> not fail if DT device is not protected by IOMMU
> 2) add chained call to sci_do_domctl() in do_domctl()
> 
> Signed-off-by: Grygorii Strashko 
> Signed-off-by: Oleksii Moisieiev 
> ---
> 
> 
> 
>  xen/arch/arm/firmware/sci.c             | 37 +++++++++++++++++++++++++
>  xen/arch/arm/include/asm/firmware/sci.h | 14 ++++++++++
>  xen/common/domctl.c                     | 19 +++++++++++++
>  xen/drivers/passthrough/device_tree.c   |  6 ++++
>  4 files changed, 76 insertions(+)
> 
> diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
> index e1522e10e2..8efd541c4f 100644
> --- a/xen/arch/arm/firmware/sci.c
> +++ b/xen/arch/arm/firmware/sci.c
> @@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev)
>      return 0;
>  }
>  
> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> +{
> +    struct dt_device_node *dev;
> +    int ret = 0;
> +
> +    switch ( domctl->cmd )
> +    {
> +    case XEN_DOMCTL_assign_device:
> +        ret = -EOPNOTSUPP;

Are you sure -EOPNOTSUPP is the right error code for the 3 checks below?


> +        if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT )
> +            break;

this one

> +        if ( !cur_mediator )
> +            break;

this one

> +        if ( !cur_mediator->assign_dt_device )
> +            break;

and also this one? It seems more like an -EINVAL as the caller used a
wrong parameter?


> +        ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
> +                                    domctl->u.assign_device.u.dt.size, &dev);
> +        if ( ret )
> +            return ret;
> +
> +        ret = sci_assign_dt_device(d, dev);
> +        if ( ret )
> +            break;
> +
> +        break;
> +    default:
> +        /* do not fail here as call is chained with iommu handling */

It looks like this should be an error


> +        break;
> +    }
> +
> +    return ret;
> +}
> +
>  static int __init sci_init(void)
>  {
>      struct dt_device_node *np;
> diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include/asm/firmware/sci.h
> index 71fb54852e..b8d1bc8a62 100644
> --- a/xen/arch/arm/include/asm/firmware/sci.h
> +++ b/xen/arch/arm/include/asm/firmware/sci.h
> @@ -146,6 +146,14 @@ int sci_dt_finalize(struct domain *d, void *fdt);
>   * control" functionality.
>   */
>  int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev);
> +
> +/*
> + * SCI domctl handler
> + *
> + * Only XEN_DOMCTL_assign_device is handled for now.
> + */
> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
>  #else
>  
>  static inline bool sci_domain_is_enabled(struct domain *d)
> @@ -195,6 +203,12 @@ static inline int sci_assign_dt_device(struct domain *d,
>      return 0;
>  }
>  
> +static inline int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
> +                                XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> +{
> +    return 0;
> +}
> +
>  #endif /* CONFIG_ARM_SCI */
>  
>  #endif /* __ASM_ARM_SCI_H */
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 05abb581a0..a74ee92067 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -851,6 +852,24 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>      case XEN_DOMCTL_deassign_device:
>      case XEN_DOMCTL_get_device_group:
>          ret = iommu_do_domctl(op, d, u_domctl);
> +
> +        if ( !ret || ret == -EOPNOTSUPP )

It is better to invert the check:

if ( ret < 0 && ret != -EOPNOTSUPP )
    return ret;


> +        {
> +            int ret1;
> +            /*
> +             * Add chained handling of assigned DT devices to support
> +             * access-controller functionality through SCI framework, so
> +             * DT device assign request can be passed to FW for processing and
> +             * enabling VM access to requested device.
> +             * The access-controller DT device processing is chained after IOMMU
> +             * processing and expected to be executed for any DT device
> +             * regardless if DT device is protected by IOMMU or not (or IOMMU
> +             * is disabled).
> +             */
> +            ret1 = sci_do_domctl(op, d, u_domctl);
> +            if ( ret1 != -EOPNOTSUPP )
> +                ret = ret1;
> +        }
>          break;
>  
>      case XEN_DOMCTL_get_paging_mempool_size:
> diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c
> index 075fb25a37..2624767e51 100644
> --- a/xen/drivers/passthrough/device_tree.c
> +++ b/xen/drivers/passthrough/device_tree.c
> @@ -318,6 +318,12 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
>              break;
>          }
>  
> +        if ( !dt_device_is_protected(dev) )
> +        {
> +            ret = 0;
> +            break;
> +        }

I am concerned about this: previously we would call
iommu_assign_dt_device and the same check at the beginning of
iommu_assign_dt_device would return -EINVAL. Now it is a success.

I am not sure this is appropriate. I wonder if instead we should:

- remove this chunk from the patch
- change the return error for !dt_device_is_protected at the top of
  iommu_assign_dt_device from -EINVAL to -EOPNOTSUPP
- this would fall into the same ret != -EOPNOTSUPP check after
  iommu_do_domctl


>          ret = iommu_assign_dt_device(d, dev);
>  
>          if ( ret )
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Thu May 22 00:26:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 00:26:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992709.1376339 (Exim 4.92)
	(envelope-from )
	id 1uHtlv-0000nb-4k; Thu, 22 May 2025 00:26:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992709.1376339; Thu, 22 May 2025 00:26: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 1uHtlv-0000nU-2C; Thu, 22 May 2025 00:26:55 +0000
Received: by outflank-mailman (input) for mailman id 992709;
 Thu, 22 May 2025 00:26:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHtlt-00009y-KC
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 00:26:53 +0000
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch
 [79.135.106.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7446b271-36a3-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 02:26:50 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7446b271-36a3-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747873609; x=1748132809;
	bh=cDzBWx2PUvd+hyF8v9TP1zwOFBaZmTOPmpHMtGIx5UM=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=nS19H3a0BK+8+rUoQMwXayWJG3CRBabHUg5rzN/UGviPRuf4EW+a/3Bt/PVegFBtA
	 hwnqGfoJyAs2u62IjHnDMyfJtrFNsemVw2U2/dch5fT4I2f5ejSLv9K61uGSlrWSBS
	 egURQaWSBcW75iSy02EBE64T2WP/ryAqbUbjgtPuSPjjxBA5sSuVkabx4Tbvb94I5A
	 mgP+twPBZ/UUntpdRwPwSqTxd7XCrm+EflzpN/E/wZbvvpHxQWheIOcKfUtBM9N+My
	 MXhwDz5nzYqFiEvcoBE0lXq1GFSZDQ5Jd7WZD9od7YZL7Hho3MM58+GIVevdvKaz1h
	 xt1iZYz1MRjTA==
Date: Thu, 22 May 2025 00:26:43 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v2 2/2] xen/domain: rewrite emulation_flags_ok()
Message-ID: 
In-Reply-To: 
References: <20250516022855.1146121-1-dmukhin@ford.com> <20250516022855.1146121-3-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: fcdbfc96e22b2eff129ba87c7f3a38e1322409ed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 21, 2025 at 05:07:12PM +0200, Roger Pau Monn=C3=A9 wrote:
> On Fri, May 16, 2025 at 02:29:16AM +0000, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Rewrite emulation_flags_ok() to simplify future modifications.
> >
> > Also, introduce X86_EMU_{BASELINE,OPTIONAL} helper macros.
> >
> > No functional change intended.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v1:
> > - kept use of non-public X86_EMU_XXX flags
> > - corrected some comments and macro definitions
> > ---
> >  xen/arch/x86/domain.c             | 29 +++++++++++------------------
> >  xen/arch/x86/include/asm/domain.h |  6 ++++++
> >  2 files changed, 17 insertions(+), 18 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index f197dad4c0..c64c2c6fef 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -750,25 +750,18 @@ static bool emulation_flags_ok(const struct domai=
n *d, uint32_t emflags)
> >      BUILD_BUG_ON(X86_EMU_ALL !=3D XEN_X86_EMU_ALL);
> >  #endif
> >
> > -    if ( is_hvm_domain(d) )
> > -    {
> > -        if ( is_hardware_domain(d) &&
> > -             emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAP=
IC) )
> > -            return false;
> > -        if ( !is_hardware_domain(d) &&
> > -             /* HVM PIRQ feature is user-selectable. */
> > -             (emflags & ~X86_EMU_USE_PIRQ) !=3D
> > -             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
> > -             emflags !=3D X86_EMU_LAPIC )
> > -            return false;
> > -    }
> > -    else if ( emflags !=3D 0 && emflags !=3D X86_EMU_PIT )
> > -    {
> > -        /* PV or classic PVH. */
> > -        return false;
> > -    }
> > +    /* PV */
> > +    if ( !is_hvm_domain(d) )
> > +        return emflags =3D=3D 0 || emflags =3D=3D X86_EMU_PIT;
> >
> > -    return true;
> > +    /* HVM */
> > +    if ( is_hardware_domain(d) )
> > +        return emflags =3D=3D (X86_EMU_LAPIC |
> > +                           X86_EMU_IOAPIC |
> > +                           X86_EMU_VPCI);
> > +
> > +    return (emflags & ~X86_EMU_OPTIONAL) =3D=3D X86_EMU_BASELINE ||
> > +            emflags =3D=3D X86_EMU_LAPIC;
> >  }
> >
> >  void __init arch_init_idle_domain(struct domain *d)
> > diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/a=
sm/domain.h
> > index 8c0dea12a5..3a9a9fd80d 100644
> > --- a/xen/arch/x86/include/asm/domain.h
> > +++ b/xen/arch/x86/include/asm/domain.h
> > @@ -494,6 +494,12 @@ struct arch_domain
> >                                   X86_EMU_PIT | X86_EMU_USE_PIRQ |     =
  \
> >                                   X86_EMU_VPCI)
> >
> > +/* User-selectable features. */
> > +#define X86_EMU_OPTIONAL        (X86_EMU_USE_PIRQ)
> > +
> > +#define X86_EMU_BASELINE        (X86_EMU_ALL & ~(X86_EMU_VPCI | \
> > +
> > X86_EMU_OPTIONAL))
>=20
> If you go this route I think you need to name those
> X86_EMU_HVM_{BASELINE,OPTIONAL}, because they are really meaningful
> only for HVM domains.
>=20
> Regarding vPCI and HVM: we might want to enable it in the future for
> domUs, but the fact is that right now it will collide badly with
> ioreqs.  So for the time being on x86 it would be best if vPCI is
> limited to PVH hardware domain exclusively, otherwise the hypervisor
> internals might malfunction.  We shouldn't really allow dom0 to create
> this kind of malformed domain as much as possible.
>=20
> static const struct {
>    bool pv, hwdom;
>    uint32_t base, optional;
> } allowed_conf[] =3D {
>     /* PV */
>     { true, false, 0, X86_EMU_PIT },
>     /* PVH hardware domain */
>     { false, true, X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI, 0 },
>     /* PVH domU */
>     { false, false, X86_EMU_LAPIC, 0 },
>     /* HVM */
>     { false, false, X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
>       X86_EMU_VPCI | X86_EMU_USE_PIRQ },
> };
> unsigned int i;
>=20
> for ( i =3D 0; i < ARRAY_SIZE(allowed_conf); i++ )
> {
>     if ( is_pv_domain(d) =3D=3D allowed_conf[i].pv &&
>          /*
> =09  * A hardware domain can also use !hwdom entries, but not the
> =09  * other way around
> =09  */
>          (is_hardware_domain(d) ||=C2=A0!allowed_conf[i].hwdom) &&
> =09 (emflags & ~allowed_conf[i].optional) =3D=3D allowed_conf[i].base )
>         return true;
> }
>=20
> printk(XENLOG_INFO "%pd: invalid emulation flags: %#x\n", d, emflags);
>=20
> return false;
>=20
> I think the above (not even build tested) is slightly clearer, and
> allows for easier expansion going forward?

I like the idea! Thanks for the suggestion.

I will wait a bit to collect some feedback, if any, before doing coding.

>=20
> Regards, Roger.



From xen-devel-bounces@lists.xenproject.org Thu May 22 00:30:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 00:30:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992727.1376350 (Exim 4.92)
	(envelope-from )
	id 1uHtpk-0002Ny-K8; Thu, 22 May 2025 00:30:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992727.1376350; Thu, 22 May 2025 00: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 1uHtpk-0002Nr-HU; Thu, 22 May 2025 00:30:52 +0000
Received: by outflank-mailman (input) for mailman id 992727;
 Thu, 22 May 2025 00:30:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHtph-0001M8-Ib
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 00:30:50 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0167234b-36a4-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 02:30: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" 
X-Inumbo-ID: 0167234b-36a4-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=neon75zegzeq5j6jvwu6pe27eq.protonmail; t=1747873846; x=1748133046;
	bh=94+daJ7MKlQipotqSqi8+oFp836FlSzSm/WXpHSSQOs=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=MpMdfOs5uSDuvqeYXu4cmIfJrxBMuMLuXuO6wvkn/18ca0Rbt1BRI2fuNQRBlPzgZ
	 x8Uj4gU92OchB68Sc/Sj4rUD/O90+J3/Je34hGEZb0+GY7zboISpdrIJlL0g1P+HLI
	 iV3bK8kewSKrTZCvq7p5JrsT4GusSufiIxRlW9rtPkClv1Z5FSXPxNLMqplbEJCMp6
	 37P66CmQHynTZslgZcgMcza9W8ln8ExiJh13joCLs27BYVk7gdjzXxLKbvdn04S5yv
	 ONPdIx1s5yGTmYnVWWTp4a3WPmKrTxMGR6QDal1NtoPkvCxKYFsHXXsF+mElFdnATG
	 yVe2uN0YB7M/g==
Date: Thu, 22 May 2025 00:30:39 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/5] xen/console: introduce console_get_domid()
Message-ID: 
In-Reply-To: 
References: <20250519201211.1366244-1-dmukhin@ford.com> <20250519201211.1366244-3-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 98508e00a38f1e2b49d380cfedf3a414229817ef
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 20, 2025 at 08:20:16AM +0200, Jan Beulich wrote:
> On 19.05.2025 22:12, dmkhn@proton.me wrote:
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -78,12 +78,11 @@ static void vpl011_write_data_xen(struct domain *d,=
 uint8_t data)
> >      unsigned long flags;
> >      struct vpl011 *vpl011 =3D &d->arch.vpl011;
> >      struct vpl011_xen_backend *intf =3D vpl011->backend.xen;
> > -    struct domain *input =3D console_get_domain();
> >
> >      VPL011_LOCK(d, flags);
> >
> >      intf->out[intf->out_prod++] =3D data;
> > -    if ( d =3D=3D input )
> > +    if ( d->domain_id =3D=3D console_get_domid() )
>=20
> How do you know d isn't a domain different from the one that was the
> console "owner" prior to being destroyed? Original code guaranteed this
> up to ...
>=20
> > @@ -123,8 +122,6 @@ static void vpl011_write_data_xen(struct domain *d,=
 uint8_t data)
> >      vpl011_update_interrupt_status(d);
> >
> >      VPL011_UNLOCK(d, flags);
> > -
> > -    console_put_domain(input);
>=20
> ... here.

Agreed; I will drop the code change in the next iteration.
Thanks.

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Thu May 22 02:21:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 02:21:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992779.1376361 (Exim 4.92)
	(envelope-from )
	id 1uHvYj-0006cb-5a; Thu, 22 May 2025 02:21:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992779.1376361; Thu, 22 May 2025 02:21:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uHvYj-0006cU-1R; Thu, 22 May 2025 02:21:25 +0000
Received: by outflank-mailman (input) for mailman id 992779;
 Thu, 22 May 2025 02:21:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHvYi-0006cO-IK
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 02:21:24 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20618.outbound.protection.outlook.com
 [2a01:111:f403:2009::618])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 73fe6215-36b3-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 04:21:22 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by MW4PR12MB5625.namprd12.prod.outlook.com (2603:10b6:303:168::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Thu, 22 May
 2025 02:21:17 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Thu, 22 May 2025
 02:21:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 73fe6215-36b3-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U/QNpX3sMvsK4g8QCYd8ZbHCmjJsgN3DpclG9Pi6Esn75hJwFVcNdsijWjCq9gSL/WEVm3CgJBU+11+vgeI5hc7fmedvBqAz+oVtDkSYEh4G/lX0YWsNvlvwpXuvJbW4ydFjbMFdxwN7NnEsEJijIbUsWzsOZ8c68GnT2YhODGJNe5DpFwRMOboIS7jiHhX7K7ZkEU0Qo36M5pEklz2KM6Sdly55qbTWGUQLDkz5Du9HzR6B7BXfJ/0hTWrceriL/MubPxAYHMffqP9rWpAlfgFrM0WduHLN73Dfc3porpujShNiNaILAIFYHg46pMg0iuVIsGew61EGqCUouWNDIQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zeeBbq30sU0lK56tr9ljt/2A6EWEOrnovqWmRjarNR0=;
 b=zTmsAxJUCGWNXUi2ZC8OltyDfDbItJR8YrHftauTiySu8M4HoKIewITxOct7Z1oHiZJ2iNd44OIZmH01lt6honukd6Mfgom+5NP8IjSMbILomx1TBblD8SPvJFC10UrEm8x3U5psvyk9XxzCIbkWEnKwreEmbGZY53el9tOrcnchE3nGa3Bpso/wb29xBVXyAZ/w56Ky5Eo+rSF4PEU7XYROcBJnPfhWNmLUCEtS0E69TybD8sAhcGOX4q2OxmCzRLr9UAg+3BF7gAtzvy5amhRwMsEQGTZVmAbXqERh1r6arw2dS6Z4kBULJZCDWoka7Qy+XJsM9gn4RbaoGRHn6g==
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=zeeBbq30sU0lK56tr9ljt/2A6EWEOrnovqWmRjarNR0=;
 b=HbskI4HSAxA+NN0gMTVAtMQF8cK8KfCgZB+X+Wyd8gceYzWj5BB/NhjVoB43/lT/Y2VtGMdHHxIlBe/uv4ui+yaoRcZSDJ0eho3hTb7vlIjd0bZR3+J+xNVtTeugGwRr2Dq+gU2CxaemXIMRPrrvIA4C+C2qO5C/iMuY3GTFuEw=
From: "Chen, Jiqian" 
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= 
CC: Jan Beulich , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Topic: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Index:
 AQHbwMGh3xGCtPOZ6EmRbIkDtAY42rPbIqIAgAApmYCAAAFtgIAACDMAgAHezgD//894AIABfxcA
Date: Thu, 22 May 2025 02:21:16 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-10-Jiqian.Chen@amd.com>
 <8d89f644-4ded-4490-ad23-518563d230d2@suse.com> 
  
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|MW4PR12MB5625:EE_
x-ms-office365-filtering-correlation-id: 54d08e73-3b57-462c-0076-08dd98d7551e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?F0LwPvj1yK5HZeMnBDVMsPIpNa6gS1VefElwlm7kdBvs4+k8eeT7ngg1qD?=
 =?iso-8859-1?Q?YStxlEYn2BkpL9xBJBDOAcbVZEbxwbUZPirUqyPi7D+b8ZUySaZXxOCA37?=
 =?iso-8859-1?Q?RG/rRszrptIhxBPjEVemgiWYNLxdLnkSADuy8MUPrjsTH2vPkK28aWxq7C?=
 =?iso-8859-1?Q?L/QgUF9jZO/c7rEpkr2fT21gSGTTzkjdAygOU2SP3t5MKeCsXRGrwGdW6h?=
 =?iso-8859-1?Q?3Fyq73kMd7Ry1xho/oSq9JDt+FzgzbNPLB1TWhoaK37k7EW/YeP1DsvN0m?=
 =?iso-8859-1?Q?Rh6D16Oxhft6lX+3OBEkl2qpfQEtq6cWsRIWZTdeGk4jY/voz/U3wa8/Yj?=
 =?iso-8859-1?Q?ok4ZokrEzVfQ2NPO3bPsIT5TqZKhIK2SCBg82uD4tRvj1oRB5gmC9u61tJ?=
 =?iso-8859-1?Q?QyZQWk9Kk3fKF/jYKGvw/C/JtvUFgvGata8goN7ab7HrAj1H7DtWXPVYv3?=
 =?iso-8859-1?Q?+QdBM3X73ZoYEwaTS80RGPs+Vr7Fvqife9H60/HCe7pL+wTAJRsQZdLy/V?=
 =?iso-8859-1?Q?GRQaYMfOUpiYnryJZzNq5PmlqJX3o8KIZ8fodozEG/5z5w9sXn2udYuEdN?=
 =?iso-8859-1?Q?WNuBuWhwOzfwbifjvphy7Q8y7Q07Ka2ipVqZDqCtnhayYFoEKeS4Xzf5V0?=
 =?iso-8859-1?Q?EH8eI1KIQFnZmTCdMifnd1xtWj3InvzAS3/oRDxAVqsr5nXOOPcYWbq4Uf?=
 =?iso-8859-1?Q?uCNZvfAUlM06OBXe4W0Wn7rPQnilEwOPMAAS6dsKEHEGnrPnKf8Nv/ovF1?=
 =?iso-8859-1?Q?Eqn+p2UxewHgoBC43IaWZn3VH1IJTtxo9nRBn9aMiB/iMBjiSKwMNOlCH5?=
 =?iso-8859-1?Q?vPUpqTS+h+ZVKgSVh5AnMwN6cxKfPyHn86ZYlkmlNPmXPqQOem9pfEe2Ym?=
 =?iso-8859-1?Q?mPhwIMY81duzyEDtJkMZzfDoJ99DP27G6AuAeisCnChVdCB0baQ4IIsUpj?=
 =?iso-8859-1?Q?6b3Hpn93zxiyUBgiV5YlMtn+IItYw/242A9ZvRyjryPu0wV5t6IdGbt6fG?=
 =?iso-8859-1?Q?ts5Yo3fl41eS7YH4s+O4wzLiMKLvHXrCBMBJfD2cNfD63L6n5w5csNSWhi?=
 =?iso-8859-1?Q?SCwL+IVEayArs4n2XLhedthVzyCamJysd1/fVRYCGXw6emXTrtJP2c3jW6?=
 =?iso-8859-1?Q?D/F3sBHbykTQXVKMDDeOt5jzajbtFn4sYPdcZrfofbdbxmOlmzSE48ikCM?=
 =?iso-8859-1?Q?6WzsjxltvBu3zyX6uDv5Wf07ejtYvbwhBMwjHM+jQWf3TqUkchAqfKdwcU?=
 =?iso-8859-1?Q?TC0sCFSsv0yPTQVKH+TWkWkc/M5HJQAIFFOpQKJKv+YAVizrRrhSPOEFXP?=
 =?iso-8859-1?Q?Z5PTAqQ8Tp/roVqhn3gu4HHge9ROXIwD/xaEv3YEof77jbwYesD+saLYoZ?=
 =?iso-8859-1?Q?p0buSVOWiFDCmu9auibTIbKY3JpaBqf0kWqhnenJ5+3mHG9E/u0KSNI/YR?=
 =?iso-8859-1?Q?DyhqkMB/RMHk/nhYSNLmk/+fLDTFxdRsO0IKSoq2sXKcoI32/oBq1fkvyx?=
 =?iso-8859-1?Q?Fcn1ChZmI9zA3e5iKeH276FpyPgQeP5EMR1JnNCspfPg=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?voTGry8a6N4VG/rvBvREM79czdc09kdq6iC1lDXNNHTyT4PMCOGmZOC5YB?=
 =?iso-8859-1?Q?aLn7G2zXmbKDYsQA0ewJGq8hT0juN2eRi9WgreaD9i7uNZKiQ1/T42Hhvr?=
 =?iso-8859-1?Q?5kCqH1PfyYmqohAPMGDh8f+lBVFY3UXHtbdhikgNxcmo3/8ON2kDUa0Fgi?=
 =?iso-8859-1?Q?ssjXibRa8+hQSAUPL1SIvjTK/E8vB2bfecEGgSl7yJ68K8Z9JQzvj09HtA?=
 =?iso-8859-1?Q?IO+qNVkeo6OhkLdE4ZA4wyMVBq1vQv8vwehfX18hYQjCwflMQV2D0mLMqf?=
 =?iso-8859-1?Q?WeMKv4mwDI5dIXZWYpb2C6qaA+klkUWKQRO4p9ZhEGiJ5mr3Q649vx0Zp2?=
 =?iso-8859-1?Q?6tsXqsJhd7fhLpZ8sxnCdU6FJTbmq1dz7+cOCjXd59yuzyfkS+s2AIZP3P?=
 =?iso-8859-1?Q?QdA7LZewTANsJL8xITVoizRbMxxq6YYsWvmxAukKo3DMHdy58jD9uedWE6?=
 =?iso-8859-1?Q?WOkPRY2a7PtBQmMQzlSxwfP8rABMZU31WBY361+AkUB7WICGMzxDCiec1l?=
 =?iso-8859-1?Q?gu+A5RpglKI3suwjx3ra42BjB6mH7OAA1MDx29fPWfZweiGflk5uPGqMcx?=
 =?iso-8859-1?Q?zXrnpN1boXHjPxHWRj460FPeMOARyQgsOn1y9fD1wz6BGt6xhsAhmRjjjT?=
 =?iso-8859-1?Q?+lE9EuiOJmz531IFcg84SVXU1ktqF5hPtmVb95oE/QCPa9SSmmiVXEoRXc?=
 =?iso-8859-1?Q?JwxhJcknPgVLrXY8MsioHik60ccX8Tn6u1Z8j4xWqoFKTwlqRRIOFoJdnd?=
 =?iso-8859-1?Q?CFA9CHJEVYTop86T7lx8f1wykWSG2YtUCoHWe1wnVJi+gdNt6XejcJC0vh?=
 =?iso-8859-1?Q?3dL/rvzERiLrGfKhFfqmV2TE2m3+fySZYkrLeXGcPxnAJJLDL2wiEcQGGc?=
 =?iso-8859-1?Q?rfS4L7sPBAce4Ey6dr1pP9X/yWALgwu4tSx0mOIpfeGv00tL7cC0sHlxnL?=
 =?iso-8859-1?Q?n8g5ozNOZfaXi5qobqQTtexJEy0pKwpW3B2SPyzY/Nz3OnUEFcAHD6sm2y?=
 =?iso-8859-1?Q?x3msW1/0zFj8co08qqGMUuqTBsQ/sVyZ+8OSqg0BiPiNtiv9QJsZKwcZrm?=
 =?iso-8859-1?Q?hnya1YpPKZAW+3zJ0FuYSHf0cwtyvvNYDHvE3opoQ7TQ3TppM+IcisARVs?=
 =?iso-8859-1?Q?3dl+b1EPXnc8pmFksMDWTFcPeXfkIq9VaItIFsZKGCwwzq27IFH5oONuQy?=
 =?iso-8859-1?Q?VbGZ5QPtxCdN5hk/Wcz9hMayOEG0xMyHHJYbPk95rvZ8F2rr4GBXu3X93O?=
 =?iso-8859-1?Q?vfNVEaSXGUpESFaTYTAVHytGtVnCnuXPUeQPRJa6KTHm9vTCJrbET7Ikyo?=
 =?iso-8859-1?Q?NoKru5apJroZk+VrUXYtGLOLPaDOGy+8pZ91qhivselwizhlVXz8rwZndP?=
 =?iso-8859-1?Q?yuKcAAgSrcaXL0HG79Kejz6LxnVDVvL6k3nOh9hDDWYqLSY8xfxXToYyk8?=
 =?iso-8859-1?Q?m8d7VJi/2RKIPGqatk56KHg9htLpE58xolzC4ee/ttOBgvBGD1765bekRy?=
 =?iso-8859-1?Q?C93tzpKZDXlXfcWhNFhTbHfyGYmM/bcD2Baan1573qXh8T+npSdFwv6/vV?=
 =?iso-8859-1?Q?LEKT9+6Zkeoww499Y8qBfxHEsgtVO210XU5DBXYuMQ8v81JpOtm3kspCc9?=
 =?iso-8859-1?Q?8idiK8JrBXOTU=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <56EBAB19B573B2479C903EFAB35DEBFC@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 54d08e73-3b57-462c-0076-08dd98d7551e
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2025 02:21:16.9874
 (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: sOmQUneC59Ue7+sYhFJoLdfOY0/ox5YO+Ui/BBHEg85II1zDAd3N3p9ZQcE53uIPqF+uFYjkLAdzZXKBO8RYkA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB5625

On 2025/5/21 19:23, Roger Pau Monn=E9 wrote:
> On Wed, May 21, 2025 at 07:00:37AM +0000, Chen, Jiqian wrote:
>> On 2025/5/20 17:43, Roger Pau Monn=E9 wrote:
>>> On Tue, May 20, 2025 at 11:14:27AM +0200, Jan Beulich wrote:
>>>> On 20.05.2025 11:09, Roger Pau Monn=E9 wrote:
>>>>> On Tue, May 20, 2025 at 08:40:28AM +0200, Jan Beulich wrote:
>>>>>> On 09.05.2025 11:05, Jiqian Chen wrote:
>>>>>>> When init_msi() fails, the previous new changes will hide MSI
>>>>>>> capability, it can't rely on vpci_deassign_device() to remove
>>>>>>> all MSI related resources anymore, those resources must be
>>>>>>> removed in cleanup function of MSI.
>>>>>>
>>>>>> That's because vpci_deassign_device() simply isn't called anymore?
>>>>>> Could do with wording along these lines then. But (also applicable
>>>>>> to the previous patch) - doesn't this need to come earlier? And is
>>>>>> it sufficient to simply remove the register intercepts? Don't you
>>>>>> need to put in place ones dropping all writes and making all reads
>>>>>> return either 0 or ~0 (covering in particular Dom0, while for DomU-s
>>>>>> this may already be the case by default behavior)?
>>>>>
>>>>> For domUs this is already the default behavior.
>>>>>
>>>>> For dom0 I think it should be enough to hide the capability from the
>>>>> linked list, but not hide all the capability related
>>>>> registers.  IMO a well behaved dom0 won't try to access capabilities
>>>>> disconnected from the linked list,
>>>>
>>>> Just that I've seen drivers knowing where their device has certain
>>>> capabilities, thus not bothering to look up the respective
>>>> capability.
>>>
>>> OK, so let's make the control register read-only in case of failure.
>>>
>>> If MSI(-X) is already enabled we should also make the entries
>>> read-only, and while that's not very complicated for MSI, it does get
>>> more convoluted for MSI-X.  I'm fine with just making the control
>>> register read-only for the time being.
>> If I understand correctly, I need to avoid control register being remove=
d and set the write hook of control register to be vpci_ignored_write and a=
void freeing vpci->msi?
>>
>> "
>>      if ( !msi_pos || !vpci->msi )
>>          return;
>>
>> +    spin_lock(&vpci->lock);
>> +    control =3D vpci_get_register(vpci, msi_control_reg(msi_pos), 2);
>> +    if ( control )
>> +        control->write =3D vpci_ignored_write;
>> +    spin_unlock(&vpci->lock);
>> +
>>      if ( vpci->msi->masking )
>>          end =3D msi_pending_bits_reg(msi_pos, vpci->msi->address64);
>>      else
>>          end =3D msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
>>
>> -    size =3D end - msi_control_reg(msi_pos);
>> +    start =3D msi_control_reg(msi_pos) + 2;
>> +    size =3D end - start;
>>
>> -    vpci_remove_registers(vpci, msi_control_reg(msi_pos), size);
>> -    XFREE(vpci->msi);
>> +    vpci_remove_registers(vpci, start, size);
>=20
> I think you want to first purge all the MSI range, and then add the
> control register, also you want to keep the XFREE(), and set the
> register as:
Understood.

>=20
> vpci_add_register(vpci, vpci_hw_read16, NULL, msi_control_reg(msi_pos),
>                   2, NULL);
And one more question, how do I process return value of vpci_add_register s=
ince definition of cleanup hook is "void"?
Print a error message if fail?

>=20
> So that you make it strictly hardware read-only, and not use the data
> in vpci->msi.
>=20
> Regards, Roger.

--=20
Best regards,
Jiqian Chen.


From xen-devel-bounces@lists.xenproject.org Thu May 22 06:00:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 06:00:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992890.1376370 (Exim 4.92)
	(envelope-from )
	id 1uHyy5-0006L2-7L; Thu, 22 May 2025 05:59:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992890.1376370; Thu, 22 May 2025 05: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 1uHyy5-0006Kv-4h; Thu, 22 May 2025 05:59:49 +0000
Received: by outflank-mailman (input) for mailman id 992890;
 Thu, 22 May 2025 05:59:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHyy3-0006Kn-SN
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 05:59:48 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2060b.outbound.protection.outlook.com
 [2a01:111:f403:2417::60b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f5192031-36d1-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 07:59:44 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 DS0PR12MB8501.namprd12.prod.outlook.com (2603:10b6:8:15d::6) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8746.31; Thu, 22 May 2025 05:59:41 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%4]) with mapi id 15.20.8746.035; Thu, 22 May 2025
 05:59: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" 
X-Inumbo-ID: f5192031-36d1-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=I167EzEwUjGcxlazB4KH6YRgJ0hBkrCf97T2Tl7nqlblCyxvWhdfWvlo2IqmxynHMCeCHfbOIOQI5cEdd3z4cG5nOTDzA3WrLsmMqizeKAbPrPqvcXwaJJFjUoyUhfV48CE5x1ustTuTF3JU8LRsL0O60k04fkWV6gwQ0R76T9MsR20/PYFGbODDSpMg/LHolOBLPgoL7iS7YH2z/RgRkxrtA7kYPjWvqq9DnFnhWoOmGP9LEZdEOaZBbVpcO1gyez4aLYK5Ok4NMwKexhWZpAMY/60h7SxyCIfEQOoTIINEU0EJR8eKgz/1YKSycgh7kX/PikqPF/5CAf9jzC7Ecw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=URqgedpDIipbImUzPk3jV2mGpeB3OInPHgAlaLmnlrE=;
 b=ZN9oZInW9bqtLXs2ZHshcDHaa/BFms6XinuC20kPCvpyERPNGDm0pdZzguoB+T3Ku1kBfnD/e63aAOuPuU2BxcKWUVoM1wNaHcQCSPOJXLx2R78ey2eEQDTHeDTCwHxZ6qXAlV4iwa9ZvnPwC6ldWVttJ1y6g0sjQxp2g80tbeHVQXFIznDb7LIPAXYlp6lQkw2gl+hKobVKJoxy3+kASLFNziUYl79CV0UUykUOV9jaU4hiPobJb3EgxDHiVW9YjKlg1Hpx8FaCuRNG652AHq99EGczQjoco9OMyW69MfonInsy3/+LEX0sXpP3TbJcT0+kSmHobn6QSP8JXas9qw==
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=URqgedpDIipbImUzPk3jV2mGpeB3OInPHgAlaLmnlrE=;
 b=lx35ycu1FzcAhMNNTdhJ6HLW3Xd3Wg8AwEGI1jCsvMWeZdxTIN4YiKOXS/iHOcZYYlmrgyvo3peqM8HYszI9lfjPspfNk81vTHmW7Sw6v88APjRT59PUCZU/00QlCB9lbq5v2KPwqPSRNI3V/PODnzc8DDPdmKVrJqVbvIxLzb8=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 15/15] xen/xenpm: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
Thread-Topic: [PATCH v4 15/15] xen/xenpm: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
Thread-Index: AQHbrRCy0dvLnopz7kONlcDKiL+9s7O8Z2mAgCH2THA=
Date: Thu, 22 May 2025 05:59:40 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-16-Penny.Zheng@amd.com>
 <239e1256-a47d-44e1-a335-2199b880f5d7@suse.com>
In-Reply-To: <239e1256-a47d-44e1-a335-2199b880f5d7@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ActionId=7d81e07e-7a48-4427-8fad-24b268d87197;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=0;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=true;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open
 Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-05-22T05:59:33Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|DS0PR12MB8501:EE_
x-ms-office365-filtering-correlation-id: cb353a97-429e-422f-6b52-08dd98f5d7d3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?VE1OWVlrOFYxRWNqWXkrYUFqZS9qSmlBQnZZZzRuVVJaU0xTYU54Zkdyc1la?=
 =?utf-8?B?bmYvNnBLSHVwOWNXYjRrZWp5VEpLYS9hQU1JVmVWdXBaQzhTSUlvL3cwaVZM?=
 =?utf-8?B?OGJ4WnoySi9aeGp4Mkx4dmN2WVN0M2tHSjNaMzV6RVlrNkpoRk03QitNdG1X?=
 =?utf-8?B?N2o2eHpQQlZ2SWE2RXZjYjVnQnB4cEVLMHVUK0w1UFMzN3FyeHdrQVJPUmRO?=
 =?utf-8?B?SXJWaFdYaDNnZmRMbmxhZmZPWTNDRklVaU5HSmM1cjN2dERpZFhUMzlWdlpv?=
 =?utf-8?B?VHVjczZBOXhGK0tZWVA5VWZDcGFKZFpualNodDJMTEJ6UUllWlc1UjR1WW5a?=
 =?utf-8?B?ZldhUzBJcnhONmwrUVphWkc5YjBOdXRHQmdGL1NQNlZSOVdVTnY5alJJZ3d4?=
 =?utf-8?B?ZWY4SElmbHU3SDVLbFFZaGViVkNtNGwrNkpubnA5VmM2clM1OFc1LzhQczQz?=
 =?utf-8?B?NnFNajhVU0lkcDU2T2VzdDQ0Z0tiMjJDNEpnUWpmcmRYQTc0NHlpK21vLzBS?=
 =?utf-8?B?L2Q3T0MramRDcm5sZ1JYZnY4VWN0a21SZ2RsN3A0cVI0STZyaDIrVUlNazV6?=
 =?utf-8?B?WDhweENrTXV0cUE2YU14MG9pdHk1VFBVL2pnNjg4aGRiZlNRNmJic09HdXds?=
 =?utf-8?B?bURja3RGMU9sRWMyY1JJMU4wL3ZmQWJNY3RvTDFxMGNLaUtlVk9nTVF4R0N6?=
 =?utf-8?B?NnkvNVJwdjU5czhuY25WQUhsT0d5dTVUZHZ6V0t4a0NaV09YcHZwdDFYUVFM?=
 =?utf-8?B?V2Fnb21HRWMwREpVREZwOWNuR241UWJxZCtWclJFZXVEKytHS2hEV2RudC9B?=
 =?utf-8?B?YkxPVnBzSDhWNnVPUXRIcjBPN3BXYXNLK0VzOHJleVhldXBiZmFONWxhR2ZW?=
 =?utf-8?B?YnpWMVpBSU5FYXVPUVFpOXlZSDkxSThCTWp5TC9xRGhqSG1GVUlsUDBSOHo3?=
 =?utf-8?B?M2U0U2pvSEFYT3M4UFRDY2RNZUNXTjVHTUNVSXQ2a0pJcDFLT0dnc0I2djdj?=
 =?utf-8?B?WUJWUXVZRWJNOVkxd3lEaHZKQ3g5RWIycHYwQ3lucWlIdUM1KzhMRUZhbGJh?=
 =?utf-8?B?V0g4UFhWbFA1a2NkZ0VTaVBYSlhuMjZ1ZVdrQnlJYkh2eTNHU01ZYkQzZlJw?=
 =?utf-8?B?emkxcWlrZytPQy9BaVVRam5hbU1WZmlRSnpsUmFZQ3pjWVBtM3lUaUc4RGUv?=
 =?utf-8?B?MnFvQk01bS9TQ2NOZHhiaURGdzFIZm1USk1NVGlqR3lKelNNdDhncDBCelYy?=
 =?utf-8?B?b2JqVk9oTDZ2YXVTWjByLzRlUEtFeTdjakdYQzF6TGFnOUdoazgvaWtrTEUz?=
 =?utf-8?B?S0hacCszTklIRzh0dmphYm1Kc3RzSmgxWkFiQmJ2enNYQnR5bmlyWjR6ejht?=
 =?utf-8?B?Ry9zK2tRZG5mVTJBdm1oTDNHZzZQNmN3NHB3SW1JazEzdm1vN0VqZWlISEhW?=
 =?utf-8?B?MFg1QlEwUGhsc1p5ZEIxRkE5T2NKVElaRUpFRCtNL2pDVXBUZGR3TlFhbm1F?=
 =?utf-8?B?OW0vTnZza1lOeG1Oczc5dzlRQ29sTVJGVmpyZ2t3TzlFNTZndHcvV3JNVldr?=
 =?utf-8?B?S2dYUGRvRkROd0NhaGNTcjhYMW9QWlFuYVNpREREbDJpcVg5WHBBVWJENXcz?=
 =?utf-8?B?VHAreStPcDhkZ1REVUVRQkR0cWV1RXBIOXRXUWE4aGVrWThoQ1Q4bEdnYmhZ?=
 =?utf-8?B?RmRwMW8xZnJoeG5mZ2kzdXhEbnhveWxkeE1BdWhYdFcyalhwNVdCNzU2YlFC?=
 =?utf-8?B?SVdBNmpIeHVNK0FBZVFSSzh3Z2M3NndnVUFRZEUwbUxRQUtURXpmL2t2YzI2?=
 =?utf-8?B?akJ0MjQvVDVXb09IZHN5MzNMNzJBUXY0S3VkemIyRjFqTlEvSy9vWnNUMlh6?=
 =?utf-8?B?K0NvRTErMkdUVkMyczRTcmFyZmxYd2FBNE5laWs5Sk5vclA3RGNVM08wNERl?=
 =?utf-8?B?N2c5Y25TZWxUZHhvN2RpR1VhQm5JOTRmZlFUaWhCdWlwUk9CdDhJRXI5ckp1?=
 =?utf-8?Q?Eb7DIUhO7xXS7I5avDl8z+8JVf/93o=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VSt4WkVIa1dZUmYycXZvczU5dkRuR0pTTE5ZazQvWUR1SzZoYlpneXZFeWpO?=
 =?utf-8?B?OXdEcFUwVDNDR0owMFVISkpaY09SRjJuVjRyeFFpK3daaUxoOWxrQ1ZRVVIv?=
 =?utf-8?B?VWNlMG1DTXpUaUU1MWdETm9Bb25yMVJUV3gyRVNZa2EwSkduZENheWJOMEpM?=
 =?utf-8?B?b1RyaW5POXVJdHhuZGg3YU9WdUFtamhVWklGdWJxVzFMRi9tcXRtblVrWjN1?=
 =?utf-8?B?V20yb3A5V0xZWkVNTkUvTUlZb3N0ZWRHRTZReG1TQzZLUTR3cUpna1NhWk5p?=
 =?utf-8?B?RGhqUEh0blRvZUdmTlBKcmtzaVl0b0RCOVlsSk5zdXV0VmtBVjJDNS9FVVh6?=
 =?utf-8?B?N2RuR3Q0QWZTcEpuQXZSSEd6S1RvMC9raDlHclMyUXFtQ015NENPcWFHMk9n?=
 =?utf-8?B?WGZxb0pWYWErdzVjdnFUOWRGb2RiS2RPWlJ3OXMrdUNrdEFYMFpHclZDdktt?=
 =?utf-8?B?MTdTd0k2WkI2ZjR3RTZPYXpqWGRwakY0NVB1MXpoNEZwampyazYvSTRsMElm?=
 =?utf-8?B?SmpwUitXNE5lNStSa2FhTXZBeGNpRzlLV2t3RllCZjZ3b2tka2VyUkxDczhU?=
 =?utf-8?B?S3d3ZFAzT29HaDBpRzV0M0tLRU1way9UNjRjVFF5bE1aMkJZLzZNeUl5UEJo?=
 =?utf-8?B?UGhsZ3pEYW5wYWhGV0IvWWE4dXErWDhLaWpVS0s0TnI3VERQQ0U2YnVoUi9Z?=
 =?utf-8?B?V25BejBESDhzZWp4ZkdvMHBQRTZXOXp6enVNSXJxd2JENGM3WmFxYS9GcUEw?=
 =?utf-8?B?Nmo4S2ozcEptcjNTYnptclowdUU2YTRva1NEVVc0V3Y4bGpBUkhQclBSREdm?=
 =?utf-8?B?UktQSHFlSWRUQzFFVlFrdlhCM0pTaEVUTGc2RDN3d1NWc0lkWmVISGFGQ0Ji?=
 =?utf-8?B?bWR1Zi9tTHRJWjNJN1hwNUR3K2o3VU1jN1BkT08rOVIwK2w4SUJrdnNNMlUr?=
 =?utf-8?B?eGVmU3QrOUJ4K1kzVjBORnl6WWNxRjNYOU9sMm1uNS9NcFIrQ21MTlpRT1Nl?=
 =?utf-8?B?bVF0SjRkcnpvSFd1ZWhwRldXb0F3dmJzYm00NFVCenZmZDIyRWRMa01DOEwr?=
 =?utf-8?B?REhxaVJ3NEI3VXcvSXJhU0NaL3c1WmhlYlZEMEw3ZW54UnRYRlZBYUE0STNX?=
 =?utf-8?B?YXcvWGJsT0IrNzNtUnNCc041YU5leExGZVNWV1FSbm5UMzZxaVcwMnNMNXpn?=
 =?utf-8?B?V0ZLNnhESlZWWkFQbFhYTjJiMktJeXJYSzlmVDJTMTErNXNrUTg3RHNtMDdv?=
 =?utf-8?B?Q3M2TmFwM3J6K0FHM2VFTmZ3cGdiMHB0aTNRUXlDb0dRQnlaVHlmZmVUMTBz?=
 =?utf-8?B?ZjZEVjNpTlBEUnBHdlg0OERHQzhycDdRTlhkODZpclljRlgyWklIaDBRdjFp?=
 =?utf-8?B?SFNGM1BEUFU0Q0M1YUdFb3krWTR6b0VMTkJIaVg2UWd0dnBoeUIzdDdVNmFy?=
 =?utf-8?B?VmdzSlNDbEN4bWphMFAwRjV4MlpENjVsZlN6WlhyYnRxSUVRMHRRT011SGNT?=
 =?utf-8?B?VkZXeTA1K25BNk9LT2FDazdqRFlPY3RYcUlIZWlvQ09nSEdTeThjVS8yVFhp?=
 =?utf-8?B?bW03dmZ1SEY4MHdrbmp5OTFpMzAvQ1BMckN3SG9hVnRZVmlWL093eHN0empG?=
 =?utf-8?B?V2FzNlZiZENiWW9BOEIvQkI0Y3NMajR4MmtkbE5nbmk5cGhaeXdZOGpHcitJ?=
 =?utf-8?B?ckxGd3ozNHpIUjVLZWxKdW1Vc29VblFQZnZFN05zTGFlakVhVG96YUFEcFBs?=
 =?utf-8?B?amZWUUcrVnZzMFRCR0E3dVFYSkd4RkF0QkxNNGNmdzhFMkRUZUh3YkJUMEM5?=
 =?utf-8?B?eHh4YkZ4M09kRWd4NW1Ec3lsVUJQd1FsdXdSVldqUzRJWG55V1dlcVJvN0Fm?=
 =?utf-8?B?bGZYZlp1eitHRFJ2N2pweG9VQTJEQjBJNmFrSWhsQW1hdVJEUHZBVkZ5b3Vv?=
 =?utf-8?B?Y3dHWGVwREI2bGRTQ2JibVlpUGNiTkRqU01McVpxRVFHV2tIbmpodDhRbmNW?=
 =?utf-8?B?dUNNcENuOEpaa2NKdVp2c05nOElpOXZlT2doZFMxdUI1TWZiVEpreEpsTmJC?=
 =?utf-8?B?amk1TGxuZkNTREJiMXZyRFpTTjFqeGZRL1ZDNWtaMFdiZ0M2NWF3Z2d2U2gz?=
 =?utf-8?Q?Rac8=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cb353a97-429e-422f-6b52-08dd98f5d7d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2025 05:59:41.1537
 (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: DwodT9Av2mtDzDlj/aGn4alIU2DJhZ685J7hXx8pjlX1BDdR8SB/73XiYexuK8WqGBz0kK6B6ap2GXNVBHIh1A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8501

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMzAsIDIw
MjUgMTE6MDIgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4g
Q2M6IEh1YW5nLCBSYXkgPFJheS5IdWFuZ0BhbWQuY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5k
cmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRy
aXguY29tPjsgeGVuLQ0KPiBkZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBS
ZTogW1BBVENIIHY0IDE1LzE1XSB4ZW4veGVucG06IEFkYXB0IFNFVC9HRVRfQ1BVRlJFUV9DUFBD
DQo+IHhlbl9zeXNjdGxfcG1fb3AgZm9yIGFtZC1jcHBjIGRyaXZlcg0KPg0KPiBPbiAxNC4wNC4y
MDI1IDA5OjQwLCBQZW5ueSBaaGVuZyB3cm90ZToNCj4gPiArICAgIC8qIE9ubHkgYWxsb3cgdmFs
dWVzIGlmIHBhcmFtcyBiaXQgaXMgc2V0LiAqLw0KPiA+ICsgICAgaWYgKCAoIShzZXRfY3BwYy0+
c2V0X3BhcmFtcyAmIFhFTl9TWVNDVExfQ1BQQ19TRVRfREVTSVJFRCkgJiYNCj4gPiArICAgICAg
ICAgIHNldF9jcHBjLT5kZXNpcmVkKSB8fA0KPiA+ICsgICAgICAgICAoIShzZXRfY3BwYy0+c2V0
X3BhcmFtcyAmIFhFTl9TWVNDVExfQ1BQQ19TRVRfTUlOSU1VTSkgJiYNCj4gPiArICAgICAgICAg
IHNldF9jcHBjLT5taW5pbXVtKSB8fA0KPiA+ICsgICAgICAgICAoIShzZXRfY3BwYy0+c2V0X3Bh
cmFtcyAmIFhFTl9TWVNDVExfQ1BQQ19TRVRfTUFYSU1VTSkgJiYNCj4gPiArICAgICAgICAgIHNl
dF9jcHBjLT5tYXhpbXVtKSB8fA0KPiA+ICsgICAgICAgICAoIShzZXRfY3BwYy0+c2V0X3BhcmFt
cyAmDQo+IFhFTl9TWVNDVExfQ1BQQ19TRVRfRU5FUkdZX1BFUkYpICYmDQo+ID4gKyAgICAgICAg
ICBzZXRfY3BwYy0+ZW5lcmd5X3BlcmYpICkNCj4gPiArICAgICAgICByZXR1cm4gLUVJTlZBTDsN
Cj4gPiArDQo+ID4gKyAgICAvKiBBY3Rpdml0eSB3aW5kb3cgbm90IHN1cHBvcnRlZCBpbiBNU1Ig
Ki8NCj4gPiArICAgIGlmICggc2V0X2NwcGMtPnNldF9wYXJhbXMgJiBYRU5fU1lTQ1RMX0NQUENf
U0VUX0FDVF9XSU5ET1cgKQ0KPiA+ICsgICAgICAgIHJldHVybiAtRU9QTk9UU1VQUDsNCj4gPiAr
DQo+ID4gKyAgICAvKiBSZXR1cm4gaWYgdGhlcmUgaXMgbm90aGluZyB0byBkby4gKi8NCj4gPiAr
ICAgIGlmICggc2V0X2NwcGMtPnNldF9wYXJhbXMgPT0gMCApDQo+ID4gKyAgICAgICAgcmV0dXJu
IDA7DQo+ID4gKw0KPiA+ICsgICAgZXBwID0gcGVyX2NwdShlcHBfaW5pdCwgY3B1KTsNCj4gPiAr
ICAgIC8qDQo+ID4gKyAgICAgKiBBcHBseSBwcmVzZXRzOg0KPiA+ICsgICAgICogWEVOX1NZU0NU
TF9DUFBDX1NFVF9ERVNJUkVEIHJlZmxlY3RzIHdoZXRoZXIgZGVzaXJlZCBwZXJmIGlzIHNldCwN
Cj4gd2hpY2gNCj4gPiArICAgICAqIGlzIGFsc28gdGhlIGZsYWcgdG8gZGlzdGlndWlzaCBiZXR3
ZWVuIHBhc3NpdmUgbW9kZSBhbmQgYWN0aXZlIG1vZGUuDQo+ID4gKyAgICAgKiBXaGVuIGl0IGlz
IHNldCwgQ1BQQyBpbiBwYXNzaXZlIG1vZGUsIG9ubHkNCj4gPiArICAgICAqIFhFTl9TWVNDVExf
Q1BQQ19TRVRfUFJFU0VUX05PTkUgY291bGQgYmUgY2hvc2VuLCB3aGVyZQ0KPiBtaW5fcGVyZiA9
DQo+ID4gKyAgICAgKiBsb3dlc3Rfbm9ubGluZWFyX3BlcmYgdG8gZW5zdXJlcyBwZXJmb3JtYW5j
ZSBpbiBQLXN0YXRlIHJhbmdlLg0KPiA+ICsgICAgICogd2hlbiBpdCBpcyBub3Qgc2V0LCBDUFBD
IGluIGFjdGl2ZSBtb2RlLCB0aHJlZSBkaWZmZXJlbnQgcHJvZmlsZQ0KPiA+ICsgICAgICoNCj4g
WEVOX1NZU0NUTF9DUFBDX1NFVF9QUkVTRVRfUE9XRVJTQVZFL1BFUkZPUk1BTkNFL0JBTEFOQw0K
PiBFIGFyZSBwcm92aWRlZCwNCj4gPiArICAgICAqIHdoZXJlIG1pbl9wZXJmID0gbG93ZXN0X3Bl
cmYgaGF2aW5nIFQtc3RhdGUgcmFuZ2Ugb2YgcGVyZm9ybWFuY2UuDQo+ID4gKyAgICAgKi8NCj4N
Cj4gSSBmZWFyIEknbSBzdHJ1Z2dsaW5nIHRvIHBhcnNlIHNvbWUgb2YgdGhpcywgbWFraW5nIGl0
IGRpZmZpY3VsdCB0byBzdWdnZXN0IHBvc3NpYmxlDQo+IGFkanVzdG1lbnRzIChhcyBJIGNhbid0
IGRlcml2ZSB3aGF0IGlzIG1lYW50IHRvIGJlIHNhaWQpLiBQbHVzIHdoZXJlJ3MgdGhlIHRlcm0g
VC0NCj4gc3RhdGUgY29taW5nIGZyb20gYWxsIG9mIHRoZSBzdWRkZW4/DQo+DQoNClBhc3Rpbmcg
ZGVzY3JpcHRpb24gb24gImxvd2VzdF9wZXJmIiBhbmQgIm5vbmxpbmVhcl9sb3dlc3RfcGVyZiI6
DQoiDQpMb3dlc3QgTm9ubGluZWFyIFBlcmZvcm1hbmNlIGlzIHRoZSBsb3dlc3QgcGVyZm9ybWFu
Y2UgbGV2ZWwgYXQgd2hpY2ggbm9ubGluZWFyIHBvd2VyIHNhdmluZ3MgYXJlIGFjaGlldmVkLCBm
b3IgZXhhbXBsZSwgZHVlIHRvIHRoZSBjb21iaW5lZCBlZmZlY3RzIG9mIHZvbHRhZ2UgYW5kIGZy
ZXF1ZW5jeSBzY2FsaW5nLiBBYm92ZSB0aGlzIHRocmVzaG9sZCwgbG93ZXIgcGVyZm9ybWFuY2Ug
bGV2ZWxzIHNob3VsZCBiZSBnZW5lcmFsbHkgbW9yZSBlbmVyZ3kgZWZmaWNpZW50IHRoYW4gaGln
aGVyIHBlcmZvcm1hbmNlIGxldmVscy4gSW4gdHJhZGl0aW9uYWwgdGVybXMsIHRoaXMgcmVwcmVz
ZW50cyB0aGUgUC1zdGF0ZSByYW5nZSBvZiBwZXJmb3JtYW5jZSBsZXZlbHMuDQoNCkxvd2VzdCBQ
ZXJmb3JtYW5jZSBpcyB0aGUgYWJzb2x1dGUgbG93ZXN0IHBlcmZvcm1hbmNlIGxldmVsIG9mIHRo
ZSBwbGF0Zm9ybS4gU2VsZWN0aW5nIGEgcGVyZm9ybWFuY2UgbGV2ZWwgbG93ZXIgdGhhbiB0aGUg
bG93ZXN0IG5vbmxpbmVhciBwZXJmb3JtYW5jZSBsZXZlbCBtYXkgYWN0dWFsbHkgY2F1c2UgYW4g
ZWZmaWNpZW5jeSBwZW5hbHR5LCBidXQgc2hvdWxkIHJlZHVjZSB0aGUgaW5zdGFudGFuZW91cyBw
b3dlciBjb25zdW1wdGlvbiBvZiB0aGUgcHJvY2Vzc29yLiBJbiB0cmFkaXRpb25hbCB0ZXJtcywg
dGhpcyByZXByZXNlbnRzIHRoZSBULXN0YXRlIHJhbmdlIG9mIHBlcmZvcm1hbmNlIGxldmVscy4N
CiINCklNTywgaW4gcGFzc2l2ZSBtb2RlLCB3ZSByZWx5IG9uIFhlbiBnb3Zlcm5vciB0byBkbyBw
ZXJmb3JtYW5jZSB0dW5pbmcuIEFuZCBYZW4gZ292ZXJub3IgaXMgdGhpbmtpbmcgYmFzZWQgb24g
UC1zdGF0ZXMuIFNvIEkgdGFrZSBub24tbGluZWFyIGxvd2VzdCBwZXJmIGFzIG1pbl9wZXJmDQpX
aGlsZSBpbiBhY3RpdmUgbW9kZSwgaGFyZHdhcmUgaXRzZWxmIGlzIGNhbGN1bGF0aW5nIHN1aXRh
YmxlIHBlcmZvcm1hbmNlL2ZyZXF1ZW5jeSBhdXRvbWF0aWNhbGx5IGJhc2VkIG9uIHdvcmtsb2Fk
LCB0aGVybWFsLCB2b2x0YWdlLCBhbmQgZXRjLiBTbyBtYXliZSBzZXR0aW5nIG1pbl9wZXJmIHdp
dGggbG93ZXN0IHBlcmYgaXMgYSBiZXR0ZXIgY2hvaWNlPw0KDQoNCj4gPiArICAgICAgICByZXQg
PSBnZXRfYW1kX2NwcGNfcGFyYShwb2xpY3ktPmNwdSwNCj4gPiArICZvcC0+dS5nZXRfcGFyYS51
LmNwcGNfcGFyYSk7DQo+ID4gKw0KPiA+ICsgICAgaWYgKCBzdHJuY21wKG9wLT51LmdldF9wYXJh
LnNjYWxpbmdfZHJpdmVyLCBYRU5fSFdQX0RSSVZFUl9OQU1FLA0KPiA+ICsgICAgICAgICAgICAg
ICAgIENQVUZSRVFfTkFNRV9MRU4pICYmDQo+ID4gKyAgICAgICAgIHN0cm5jbXAob3AtPnUuZ2V0
X3BhcmEuc2NhbGluZ19kcml2ZXIsDQo+IFhFTl9BTURfQ1BQQ19FUFBfRFJJVkVSX05BTUUsDQo+
ID4gKyAgICAgICAgICAgICAgICAgQ1BVRlJFUV9OQU1FX0xFTikgKQ0KPiA+ICAgICAgew0KPiA+
ICAgICAgICAgIGlmICggIShzY2FsaW5nX2F2YWlsYWJsZV9nb3Zlcm5vcnMgPQ0KPiA+ICAgICAg
ICAgICAgICAgICB4emFsbG9jX2FycmF5KGNoYXIsIGdvdl9udW0gKiBDUFVGUkVRX05BTUVfTEVO
KSkgKQ0KPg0KPiBJc24ndCBpdCB0aGUgbm9uLUVQUCBkcml2ZXIgd2hpY2ggaXMgZ292ZXJub3It
aW5kZXBlbmRlbnQ/DQo+DQoNCkVQUCBkcml2ZXIgaXMgZ292ZXJub3ItaW5kZXBlbmRlbnQsIGlu
ZGljYXRpbmcgYWN0aXZlIG1vZGUuIEhhcmR3YXJlIGl0c2VsZiB3aWxsIGF1dG9tYXRpY2FsbHkg
Y2FsY3VsYXRlIGFuZCBzZXQgZnJlcXVlbmN5LiBVc2VyIG9ubHkgc2hhbGwgc2V0IG1pbl9wZXJm
LCBtYXhfcGVyZiwgYW5kIEVQUCBhdCB0aGUgYmVnaW5uaW5nLg0KRVBQIGlzIGEgcHJlZmVyZW5j
ZSByYXRpbyB2YWx1ZSB0b3dhcmRzIHBlcmZvcm1hbmNlIG92ZXIgcG93ZXJzYXZlLCBvbiB0aGUg
c2NhbGUgb2YgMC0yNTUsIDAgYXMgMTAwJSBwZXJjZW50YWdlIGZhdm9yaW5nIHBlcmZvcm1hbmNl
LCB3aGlsZSAyNTUgYXMgMTAwJSBwZXJjZW50YWdlIGZhdm9yaW5nIHBvd2Vyc2F2ZQ0KTm9uLUVQ
UCBkcml2ZXIgaXMgc3RpbGwgcmVseWluZyBvbiBYZW4gZ292ZXJub3IgdG8gZG8gdGhlIHR1bmlu
Zy4NCg0KPiBKYW4NCg==


From xen-devel-bounces@lists.xenproject.org Thu May 22 06:18:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 06:18:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992909.1376379 (Exim 4.92)
	(envelope-from )
	id 1uHzGK-0000sT-Ph; Thu, 22 May 2025 06:18:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992909.1376379; Thu, 22 May 2025 06:18: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 1uHzGK-0000sM-N6; Thu, 22 May 2025 06:18:40 +0000
Received: by outflank-mailman (input) for mailman id 992909;
 Thu, 22 May 2025 06:18:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHzGJ-0000sG-HW
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 06:18:39 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 98cbd618-36d4-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 08:18:37 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ac3eb3fdd2eso1358829566b.0
 for ; Wed, 21 May 2025 23:18:37 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d496576sm1028632066b.133.2025.05.21.23.18.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 23:18: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" 
X-Inumbo-ID: 98cbd618-36d4-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747894717; x=1748499517; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=rv3uqiJ2sWJIAWxz/PlWHp0yGmTX9oHCdn4+VUD3ukU=;
        b=K2QFAVrF97i4M1efDC+fHubk7D3zGKVwyNuIGfKr3piUenxKwhtioExL1iRu/flBYY
         39Ea/cu2i8+Es2fHKuW1SOtYU/dW3mwlViyM9+R0ZJwKUHsJCJn2LjzCz0It3vXequ8w
         jTWxqsIb5nqldIynh+dtDzI9U9tPzy5AG2jH2V7bwPr3ZqzRtuDyKBRPqwW4mIpI57Lp
         kVH3uY3H5gNCVj/xb35hf8PYKqpWCN+8P0+M9ISu3yWkEJt6g+wRtcN4U4CR8lhiamTr
         4dRjBekDolvgh9+/19rTaw5sulOEzwGXXWXnCinfeE6uQsfyr8ZPsVfsgLYn8dHz0unP
         IxOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747894717; x=1748499517;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=rv3uqiJ2sWJIAWxz/PlWHp0yGmTX9oHCdn4+VUD3ukU=;
        b=CSfcBnCTsXSqCe0lGdg6fOnty/B6HVXJCJd8JnAQrGG49sZCMgBy2ddh8bJr5yWMtE
         zzNedLPUmzlscAKLxXTUqpQRnAj1Jo259qO7ilP8k9JWLxPYqI9BvjJOdOc/z/H6CTwR
         k23tEj/xrBxI9022N2/ND+hzVsXLzAsqCsS2ie4KK7LLRyYozyIggtlISpfcn8V92lL6
         rOo/bRBPJUjCjKUebtL2drFROs2J++QBab9maNxe8PIuNkQRfZUTujoFTnAekmeb4z6M
         z9JbkjY83CSynrnmJZhxapBjFry0hpcR7uEpNKU/vgYzLRfIdFcz4gR7m9NA0Mj2sKIO
         ZwHA==
X-Gm-Message-State: AOJu0Yz3NFcsO0ePl0a1gfwGQArrth54P076/l7DrtmtFxedhQ8OdDxR
	a15xklK2Fwt8zwtYIrxrPEhjBbU1phkFQXsK09KYvYYpEL67rB+YSIJQrzVXBojjPQ==
X-Gm-Gg: ASbGncu13C4ZltHVMxbibzniTtMUEiKaVHvLAXNF4nV5rH7TDzFWtI1ZLIIs5Etg/Le
	i612sph8lRWeZUZ60PyahIs+KxiHApnJMbWSVEFrjThMF1+tU8ETW1RQ5AIlb9pANX582y7MZbZ
	aJ6fsn0xFGZjfeck6i0wszLa9WPQyzQrw/4Kzf226LdSxFuyP5wv1zpptc/2XPGvCujVeYAZmml
	0aVZhb6XGqHlnx+1fuofD3YI35mUHq6REmxiYHCXzFDp7+b6lfYHNCCpF0aCnfAYrZDm9xaa/mx
	+ci0QYe1IzZ2y/FdnkVP0DY14m2kciK6JwogAR2+LNEs0vkKoI2+fvLBZhhepw==
X-Google-Smtp-Source: AGHT+IHVkNN8GODRZ97gLn33E626sY3/r+HgtrVXasa/uFFKNRleUnmfkTJE3OnnV6ldcBBhy1bHHw==
X-Received: by 2002:a17:907:980c:b0:ad5:bf7a:964 with SMTP id a640c23a62f3a-ad5bf7a0dd7mr241058666b.8.1747894716808;
        Wed, 21 May 2025 23:18:36 -0700 (PDT)
Message-ID: <862c0fe6-8204-4c85-92f2-388d44e01af3@suse.com>
Date: Thu, 22 May 2025 08:18:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to
 handle not only iommu
To: Stefano Stabellini ,
 Oleksii Moisieiev 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper ,
 Anthony PERARD ,
 Bertrand Marquis , Juergen Gross
 , Julien Grall ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Volodymyr Babchuk ,
 Grygorii Strashko 
References: 
 <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.05.2025 02:25, Stefano Stabellini wrote:
> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
>> +        ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
>> +                                    domctl->u.assign_device.u.dt.size, &dev);
>> +        if ( ret )
>> +            return ret;
>> +
>> +        ret = sci_assign_dt_device(d, dev);
>> +        if ( ret )
>> +            break;
>> +
>> +        break;
>> +    default:
>> +        /* do not fail here as call is chained with iommu handling */
> 
> It looks like this should be an error

The way the hooking is done at the call site, I think it can't be an error
here. But I previously questioned the way that hooking is done.

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 06:36:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 06:36:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992923.1376390 (Exim 4.92)
	(envelope-from )
	id 1uHzXp-0003og-85; Thu, 22 May 2025 06:36:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992923.1376390; Thu, 22 May 2025 06: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 1uHzXp-0003oZ-4I; Thu, 22 May 2025 06:36:45 +0000
Received: by outflank-mailman (input) for mailman id 992923;
 Thu, 22 May 2025 06:36:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHzXn-0003lz-TR
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 06:36:44 +0000
Received: from PA4PR04CU001.outbound.protection.outlook.com
 (mail-francecentralazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c20a::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f9f0af5-36d7-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 08:36:42 +0200 (CEST)
Received: from AM8P189CA0026.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:218::31)
 by DB4PR08MB8079.eurprd08.prod.outlook.com (2603:10a6:10:385::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 06:36:39 +0000
Received: from AM4PEPF00027A6B.eurprd04.prod.outlook.com
 (2603:10a6:20b:218:cafe::8c) by AM8P189CA0026.outlook.office365.com
 (2603:10a6:20b:218::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.29 via Frontend Transport; Thu,
 22 May 2025 06:36:39 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM4PEPF00027A6B.mail.protection.outlook.com (10.167.16.89) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Thu, 22 May 2025 06:36:37 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DB3PR08MB10336.eurprd08.prod.outlook.com (2603:10a6:10:43b::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 06:36:03 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%3]) with mapi id 15.20.8699.022; Thu, 22 May 2025
 06:36: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" 
X-Inumbo-ID: 1f9f0af5-36d7-11f0-a2fb-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=v1KK+lpcmeZpVjVpR0FBlyCdHKmugnCKa74TVpV52Mjrp4J4trB34AXWba1CF8HNOkiSoDJ+UXhiRTUZ7Nv/tFjOUaXP8K6y7CMPvETfSdGtXrMBbSIaBOkgNavklU1dizbYvQ9e9bnKngZVWDa80/YHAGCe3wMXpxxrZ48txt7ukVtNzTcprZjFfByckoz/VL9dODr+WYoLPPJUKNlAAx8AXQW3R6Q4WRkbIRGg8LrwZ8eoftZk0/YlpSk4zLoLeVMi/gB/oIu2SxiExjZeGEu8cpj7WSpAa5Z1NgKR4sS3E6OCyG5YOd1E6NcHXFqGvpxrdmztJMpmHzs4W8EM3A==
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=stk66sdxH8OrsM/SQCnppO1CCKo0b6N4+adgoZU3HQM=;
 b=Ir/WNjhDxyRy/z8B0/ULiLgsST4+Y8Cd+Lp2puUwWSr8KSfFLK7+3xvwQn2aU/AMPynSG1XW6ERPr6XQeHqSVXPPnpITMO7jcv/QVCBgqqxsFVoKsOdFZF7ShZwBH5xRgSI3KbtTA+h+wQaGBuLT9+anQGfeXkbI4tNNphV4cgSeVkwD9hh+bLAzIcirlv22K8VxnShvrSLiNosmXmM+FM/ZItemMpA4ert9AJsc7hFPkDZ/HU1GHS9Y6YgAA7z/Wm0Eapb0dj4z3RPPVpGy163xPBrmmpqSxprnHpxen8+XxlbGQRKaKIB1e462y7/NOFBOzWTn73WAVOwKq5XQqA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=linaro.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=stk66sdxH8OrsM/SQCnppO1CCKo0b6N4+adgoZU3HQM=;
 b=PTZ2DorsJVyHBOPf4KCcDCI3E+ON3cXKnPADbEPgqOVBWwoMQsoV2tMJCPxEKKplie2fI1l19J5iCg596I4oxq9hrfMxvCDeiXa5vq9S4KsMNOnb+OtG49y+4kGLKLCNinfUkGo+819ETob192ufUWfMPZ2gjQuRDWhDnZKtgvo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GVQuxSDkxp5ZjLwCjbiR7V4BNVVKtVK4pB+qQ6SE9RtTzVT9R8coS5FAaILEPusWHMwgBOmTSBidh3INLXaRnhQ1louZ2wEvie2Osf37pnhiFIhus4EujJBeFb1YApXGkIQuoEoUSTirIw9lBnjPc+IPw3z4eG+XS+YTAfhaA3wxpDbW75x9u76FueQ6z5weT8LaZKmxn2j1ZD5W2Cj3y4CNji9GGyBZvaJcv5A/PhMuAJkXRL11fQ5eL9TrHyx7tud3kH8pM/SiRgr+cop+1Z3EwUXXg10vYH4uBxAiRiEc6UQRkcILtrtTGdPUnrD6w7YLDl1yoZt0MFHg7MCzoQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=stk66sdxH8OrsM/SQCnppO1CCKo0b6N4+adgoZU3HQM=;
 b=khSGsgk6ElOj5SnoZotCh7FX+5xWAEMhzzMrLvcn75ElvF59hGCpXxeobFPZWfdf4S8hFQC55wte2t9Su4NjFwmZtqhW5WDaGBY4yM0W278QC/dHnxnkMrj2yZz5tXYCvyUsMDp/OTQnkgzmNtf7PGj7hh0DMmD+bVFnyAOakPy9TJeEqBWvvjm9xQMUSGwOInaeOx/H6nQyrZqiQTUgh0ZSgwndZiaDsctmAIGRqNDMgThtG3mytz47ujy/8rI3ENVe2I7P0rsWooQUqcpmTyZABB7/hZZIwzVK7ND+MbrNfsDg/WFjxn/aAqT6yT364dxA51QQ9Zqxw9ItKaqUoQ==
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=stk66sdxH8OrsM/SQCnppO1CCKo0b6N4+adgoZU3HQM=;
 b=PTZ2DorsJVyHBOPf4KCcDCI3E+ON3cXKnPADbEPgqOVBWwoMQsoV2tMJCPxEKKplie2fI1l19J5iCg596I4oxq9hrfMxvCDeiXa5vq9S4KsMNOnb+OtG49y+4kGLKLCNinfUkGo+819ETob192ufUWfMPZ2gjQuRDWhDnZKtgvo=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: "xen-devel@lists.xenproject.org" ,
	Volodymyr Babchuk , Stefano Stabellini
	, Julien Grall , Michal Orzel
	
Subject: Re: [PATCH v5 3/6] xen/arm: ffa: Introduce VM to VM support
Thread-Topic: [PATCH v5 3/6] xen/arm: ffa: Introduce VM to VM support
Thread-Index: AQHbrqLcUoVcqzY6y0GU3I61EJDkQrPdY1IAgAAESwCAABesgIAA6vmA
Date: Thu, 22 May 2025 06:36:03 +0000
Message-ID: 
References: 
 
 
 
 
In-Reply-To:
 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DB3PR08MB10336:EE_|AM4PEPF00027A6B:EE_|DB4PR08MB8079:EE_
X-MS-Office365-Filtering-Correlation-Id: 1b339b4e-a14c-4ff9-c7de-08dd98fb00bd
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|10070799003|1800799024|366016|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?V1JieTBONHBSd29NL2E5Q2doN1JxQWs3VW1Ec21sN21sS1MxdWlPbStIWHNk?=
 =?utf-8?B?R2pJcnhxTkFEZGhmcGd0eUM0Nnkrb0tFTTFya1FWUTdNZS9NWjNqNHkwS2dq?=
 =?utf-8?B?UHhNNU95S29YWjFjYzlSYUF4dVQ4d0JtQ1FzaHB3QnFLN1REQnBRRE5qbEFp?=
 =?utf-8?B?eUgwWTFQZGtkbDhCWW84SlBWWlBqeUJXd0ZUUjhPclJpVnRMN1JBTjNkbEJu?=
 =?utf-8?B?c09OTFpFZ3hVcHFET0l6RWtOdE5Pb0Z6YVpwNGdSYTU5N3g3WW5EQkxmaStQ?=
 =?utf-8?B?eGpQUkZ5ZHVCTnVMeEtlMzFJUlhDNk5MTWd4MHpXY3U0YmJmdlRFaHR2RzBX?=
 =?utf-8?B?QVFTTkluWTVXU1g3NG55Skc0RU5kV0RpT1Rqc2ZhcGkwdTVEekx0SzNqdE5z?=
 =?utf-8?B?K0FwcW10WjNYamlSZUJ6SlFLL2Rrd3NTQXU5WlhpME53d0lSV2xqTEU0K1dv?=
 =?utf-8?B?amxRR3VHVEVxNy8rOXRMaTdXUFd4dFN0V3NueFg1alpkNXkyaUJXaHpFUkxY?=
 =?utf-8?B?azA0QVI3bEJUdXFIMnd3NGc0bUkwbHVGenRlTy9jZGpvMW1mdWJuT2U2Z3lu?=
 =?utf-8?B?clU5UURRYmM5b2F6cERCWTQ3ZnE3TkNLME5jajBVOEdaUFlnWTNYR1VNQVpL?=
 =?utf-8?B?dDZ1b211L3JXY0U2MmJrOUluZDdtbzRpbWlxeFpSYVQreUlSS083L0czMmtQ?=
 =?utf-8?B?NnZxYmJlSmhERkhGUHhXd29VWXJaTCtMSjBXdUJaT2dxQ0I4SExDODIvU2Zw?=
 =?utf-8?B?ZFBmWHNLeng5MUEwOVdWSVRaaDNydXJnMUVOT2dQMW5PeVowMi9CUE03VlVs?=
 =?utf-8?B?QXRRd08rOHNtajhiU2Y3cms0N2lkQitadW9DZVdXajJwM2VsZmFRU3Y2RG9i?=
 =?utf-8?B?OVhuNFlBSnRqWXIwUjlGSzBRa0ZNMk9obEgwQ2tVY0JzZW4zRW5EWnhNNHQ0?=
 =?utf-8?B?RFRwY3ZFK2h6VmgyWWJrNnZjOWJhZnRsais4Wmh1UEhLYUEraElLWm1NbzhT?=
 =?utf-8?B?U3BVSWVJMDE0NzQxQks4cklWSVRFOVM3UGhEeXRNT2xiSUZldFBESkdSQlZz?=
 =?utf-8?B?a3BEUkpVNXFnQWNzMWY0cFhlbEg1MzRtVHVobGJINW9qVzR4VDFMS0RyVkZU?=
 =?utf-8?B?WWlrVGUwNUZBcjd4TDZyUlZaS0NEcGE0VUdyZEZ2NzZscjFOOHpTZC82ZDh3?=
 =?utf-8?B?WnI2TXBjaW81NmppZW5weFQ0QlVoRXJ5TS9UOGVUL3dsTGRCcFVvaEtOTnEr?=
 =?utf-8?B?MDBpakNIY25GTGJvR01nSk9VZ1czOUxXNDNQT2hxTG05bXE2U1VTVG1RYU5P?=
 =?utf-8?B?UmIzZjlyWExiMytTRm5aYXl2aVRjeHlDb1YwSkE1QzNtejl6anBlWlE0Z3dN?=
 =?utf-8?B?L3dUcGErMlVMNnhCOXdsdFFaejd0NTlwb0dPeVBlT2ZMU28rVEpmMDlaNm1k?=
 =?utf-8?B?ZzdlYUQ3eG4zcnJES2ZPU054Qk5DN1poQU9mL2xKOEt4VEFnTzF1dmRxZXdu?=
 =?utf-8?B?R25FS2ZJaU1xYUJ5cXAxamlETFpJdVYxdVZuaFVDNjdGS212MlhVMkVMVWd0?=
 =?utf-8?B?OVpNOWRrNFFvcHZieXpESjU4djVFQnUvOUpQak41TDdWV2IvM2h3MUFleXU0?=
 =?utf-8?B?c2o3eVZUVU0zWUpzdVFZbTlOM1VmODRBdy9sZS93bWpqeXRnVmhnUjg3Lzkv?=
 =?utf-8?B?K0xwS3d6OTZqWDVVMnA4eWVWdS8xa2N2VzZKYzdjQTdGV0lQNmVlN1Y0ai90?=
 =?utf-8?B?cDB1L2lseUJ6djRicVRVMXhVS0RIa0ZTNjlVOGREa3dsM0lGOWJWaHdlVVdQ?=
 =?utf-8?B?c2VrdGIyRkRVZUJTYkFUUmRnYm5tNnltRTJwVk5tNnkwdVdwZHdaYTdLK3pV?=
 =?utf-8?B?UTBGT0hVZVZzay9oc2JtVkxXSzNxaCt5SEtMRVpsTnNhcjY4TDYzQ2lURmd5?=
 =?utf-8?Q?yKXmfHxT30A=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <397CEF65CBBB4241A79BBE95512FFE6C@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB10336
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM4PEPF00027A6B.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	2b5fb2cd-0049-4074-915a-08dd98faec87
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|1800799024|36860700013|82310400026|14060799003|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?T0hib0tZNXlBcWxsalQyZS9vUElxYWNQaW8yUFlndlNBS25LeTVNUGh2MENV?=
 =?utf-8?B?SldXRHpFY2w0dHl5Zk5kb2Y5Q0VKUk5JdTFJL1hoMnZ4bTZtZnJ6bXdsdEND?=
 =?utf-8?B?bHdzdXpiUjJ6TFFrd2tGYkRGMjEzVFJzWlM4MjJCR2MvcVFIYTduRFdQYlhW?=
 =?utf-8?B?RkhyN1lNdmZvMFVwMUpFemltTlF2dVNkUWxja1Z2VDNHbVY1dnBQSzhjYzF5?=
 =?utf-8?B?MTRXZlk5ck9VMHo2dWdPWTZjRGUvZnFHTUdyMXVxTVdMVDQ4OE4vNmQyQ1Qw?=
 =?utf-8?B?R0VXRzdPVFBteVkwYnVCeFNGT29CRTZuVE5GV1pFSGZSU1pYUmFNTjBvVWlV?=
 =?utf-8?B?bWV2UGFzUG1veUI0S0xaNXJmVHpMKzc2dEV1djZCRWlMa3o2cS95L01QTEtG?=
 =?utf-8?B?SW5oVUdKQXJ5Skx2bGRhMm9EcFhqMUM3UDU4ay8rMWJSU0ZKZTBmNHd1bzR5?=
 =?utf-8?B?cG13c25IVk8ydlJnM204dFhnNkh0ejR1Z3poNkliQ1MwTW5SWWh3aUxuZ0F3?=
 =?utf-8?B?cWZpMkplckk1VHpCRkNkczRQYXRCRTQ3SXQ1WlVCS0NBNWg1UlpRMXN1WlN2?=
 =?utf-8?B?dzRubHVNd0cxUnFEa25oMElIdlFGVjdvUVpVQUtIWGFKL0oxVDBtZzRlSHFj?=
 =?utf-8?B?bzcrS3Zoc001OGRCMFNZUzZ1M3YvNFA2N3NZMWoybmkwQ2F3UExUdGVYRWVS?=
 =?utf-8?B?aUpia25tem56cE14K3NNUlc2TWJiOUJKNGJaTmc1S21ZckdmL2FmL00xR1Fm?=
 =?utf-8?B?aW1CLzFwMUQ3WmRPQ3ovV1N2VGpQQjRJUlQwdlNnUGdMMUNDUCtmUUhYY0hX?=
 =?utf-8?B?bi96MnRPNVBRTjN5eEE4RmF6VnlwOFBhTzFCeW12N0REbkJQMTZTZFdqSlFu?=
 =?utf-8?B?T0lRUk5KRTdxNGFVQzgrK3ZRTGwrOE8rMFErdlVpN05tb2dqbEI5L2FIdzFT?=
 =?utf-8?B?SU9MeW9lbFZaQkYvMlE5RVFIbjRzamZQNS93WnJqLzg1d09QcWNHZWVEYjIw?=
 =?utf-8?B?K0Yza05iOFpyclVwWnVyWHIvNnJGNTI3TE1FdlIxWldEd2JpNmtnSTh1RFFq?=
 =?utf-8?B?MjBxWllPWnBSdzRCZnNPMUp5WGZkZlU5bFVsNUJzaDlqT2Fhc3JGM1lMTUlp?=
 =?utf-8?B?U1FYakQ4UVNOc21KNGszdWRPNTBjTURYZmp6cmJpVGxvQ3dDcGtVcEZ3WHdx?=
 =?utf-8?B?eWJWc3dpR3E3dkNBTnFiT3VUMkNTSkp3Y3A0bHFRQnI3eXVHMU1xY04xV0xo?=
 =?utf-8?B?YTEveGNMQ1RwQjV6UXdkRW1JdEE3OTNSTXhaMkRyRHFuT0Z5dTVEd2xybnY1?=
 =?utf-8?B?eHhHc1g2WUFuQUc3b0szME9XcTgxUWdBNjNtcjlrbldZTWU4TG5zK2MwN09B?=
 =?utf-8?B?ZzgraFFRNGt2eWFtU21RTkp4RVV3V204cEtPdy9KcmtlWFRjME9aZUNWMi94?=
 =?utf-8?B?b25MQS8rUm5mVnUrRGVDd1I1eDN1TFN6RFF5TkFnbndEeU5SZlcwUGl4TEJx?=
 =?utf-8?B?ZGJDS29WSW03WGt6ZGJZN0tZdFMyTnlYRk5FUlA2WFhxaVVwSlNMV0tWSVRQ?=
 =?utf-8?B?SVgvYnRLU1dRWkQwUmFIamdMbkVnNjkreEJrNVpGWllCRjdCanFudTUyYWJW?=
 =?utf-8?B?cTYrdWQ2bU80eDF2anhPOUpkNENKZGJESjVQb0JxTnVxQjFHM0t0WG1Oc0tT?=
 =?utf-8?B?NTRiYnZtZm01L1VaaEE3c2JyVHNWQ0I5WDNsSU56TmpNaThPd240bFJuZTAx?=
 =?utf-8?B?L1ZXTkhHeWdHbDdMRk1hMi9yaVdocjRXS0o4SDBYL0dobFlwZEpxMUp1ZnYx?=
 =?utf-8?B?WDhSSFlya004c0Nmd0tPampSTTJYZGhtejNqc0xQcWdpcllrSWhzVW1JZjdR?=
 =?utf-8?B?SkcyWUs5NGlXTldoYjEzVUZrVVFocWtzSHFRdWU2OFNXaEFFaURYbHUzNU1W?=
 =?utf-8?B?T2JMRDNJRkRObmt6bm42M0xBOHFYWTNhVVNtL1BnMWc5bmhtaTJCQURJTzFH?=
 =?utf-8?B?cE9jWktpUTR3PT0=?=
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)(1800799024)(36860700013)(82310400026)(14060799003)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 06:36:37.2261
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b339b4e-a14c-4ff9-c7de-08dd98fb00bd
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:
	AM4PEPF00027A6B.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB8079

SGkgSmVucywNCg0KPiBPbiAyMSBNYXkgMjAyNSwgYXQgMTg6MzQsIEplbnMgV2lrbGFuZGVyIDxq
ZW5zLndpa2xhbmRlckBsaW5hcm8ub3JnPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gT24gV2Vk
LCBNYXkgMjEsIDIwMjUgYXQgNToxMeKAr1BNIEJlcnRyYW5kIE1hcnF1aXMNCj4gPEJlcnRyYW5k
Lk1hcnF1aXNAYXJtLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpIEplbnMsDQo+PiANCj4+PiBPbiAy
MSBNYXkgMjAyNSwgYXQgMTY6NTQsIEplbnMgV2lrbGFuZGVyIDxqZW5zLndpa2xhbmRlckBsaW5h
cm8ub3JnPiB3cm90ZToNCj4+PiANCj4+PiBIaSBCZXJ0cmFuZCwNCj4+PiANCj4+PiBPbiBXZWQs
IEFwciAxNiwgMjAyNSBhdCA5OjQw4oCvQU0gQmVydHJhbmQgTWFycXVpcw0KPj4+IDxiZXJ0cmFu
ZC5tYXJxdWlzQGFybS5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4gQ3JlYXRlIGEgQ09ORklHX0ZG
QV9WTV9UT19WTSBwYXJhbWV0ZXIgdG8gYWN0aXZhdGUgRkZBIGNvbW11bmljYXRpb24NCj4+Pj4g
YmV0d2VlbiBWTXMuDQo+Pj4+IFdoZW4gYWN0aXZhdGVkIGxpc3QgVk1zIGluIHRoZSBzeXN0ZW0g
d2l0aCBGRi1BIHN1cHBvcnQgaW4gcGFydF9pbmZvX2dldC4NCj4+Pj4gDQo+Pj4+IFdoZW4gVk0g
dG8gVk0gaXMgYWN0aXZhdGVkLCBYZW4gd2lsbCBiZSB0YWludGVkIGFzIEluc2VjdXJlIGFuZCBh
DQo+Pj4+IG1lc3NhZ2UgaXMgZGlzcGxheWVkIHRvIHRoZSB1c2VyIGR1cmluZyB0aGUgYm9vdCBh
cyB0aGVyZSBpcyBubw0KPj4+PiBmaWx0ZXJpbmcgb2YgVk1zIGluIEZGLUEgc28gYW55IFZNIGNh
biBjb21tdW5pY2F0ZSBvciBzZWUgYW55IG90aGVyIFZNDQo+Pj4+IGluIHRoZSBzeXN0ZW0uDQo+
Pj4+IA0KPj4+PiBXQVJOSU5HOiBUaGVyZSBpcyBubyBmaWx0ZXJpbmcgZm9yIG5vdyBhbmQgYWxs
IFZNcyBhcmUgbGlzdGVkICEhDQo+Pj4+IA0KPj4+PiBUaGlzIHBhdGNoIGlzIHJlb3JnYW5pemlu
ZyB0aGUgZmZhX2N0eCBzdHJ1Y3R1cmUgdG8gbWFrZSBjbGVhciB3aGljaA0KPj4+PiBsb2NrIGlz
IHByb3RlY3Rpbmcgd2hhdCBwYXJ0cy4NCj4+Pj4gDQo+Pj4+IFRoaXMgcGF0Y2ggaXMgaW50cm9k
dWNpbmcgYSBjaGFpbiBsaXN0IG9mIHRoZSBmZmFfY3R4IHdpdGggYSBGRkEgVmVyc2lvbg0KPj4+
PiBuZWdvY2lhdGVkIGFsbG93aW5nIHRvIGNyZWF0ZSB0aGUgcGFydGluZm8gcmVzdWx0cyBmb3Ig
Vk1zIHdpdGhvdXQNCj4+Pj4gdGFraW5nIGEgbG9jayBvbiB0aGUgZ2xvYmFsIGRvbWFpbiBsaXN0
IGluIFhlbi4NCj4+Pj4gDQo+Pj4+IFNpZ25lZC1vZmYtYnk6IEJlcnRyYW5kIE1hcnF1aXMgPGJl
cnRyYW5kLm1hcnF1aXNAYXJtLmNvbT4NCj4+Pj4gLS0tDQo+Pj4+IENoYW5nZXMgaW4gdjU6DQo+
Pj4+IC0gcmVtb3ZlIGludmFsaWQgY29tbWVudCBhYm91dCAxLjEgZmlybXdhcmUgc3VwcG9ydA0K
Pj4+PiAtIHJlbmFtZSB2YXJpYWJsZXMgZnJvbSBkIGFuZCBkb20gdG8gY3Vycl9kIGFuZCBkZXN0
X2QgKEp1bGllbikNCj4+Pj4gLSBhZGQgYSBUT0RPIGluIHRoZSBjb2RlIGZvciBwb3RlbnRpYWwg
aG9sZGluZyBmb3IgbG9uZyBvZiB0aGUgQ1BVDQo+Pj4+IChKdWxpZW4pDQo+Pj4+IC0gdXNlIGFu
IGF0b21pYyBnbG9iYWwgdmFyaWFibGUgdG8gc3RvcmUgdGhlIG51bWJlciBvZiBWTXMgaW5zdGVh
ZCBvZg0KPj4+PiByZWNvbXB1dGluZyB0aGUgdmFsdWUgZWFjaCB0aW1lIChKdWxpZW4pDQo+Pj4+
IC0gYWRkIHBhcnRpbmZvIGluZm9ybWF0aW9uIGluIGZmYV9jdHggKGlkLCBjcHVzIGFuZCA2NGJp
dCkgYW5kIGNyZWF0ZSBhDQo+Pj4+IGNoYWluIGxpc3Qgb2YgY3R4LiBVc2UgdGhpcyBjaGFpbiBs
aXN0IHRvIGNyZWF0ZSB0aGUgcGFydGluZm8gcmVzdWx0DQo+Pj4+IHdpdGhvdXQgaG9sZGluZyBh
IGdsb2JhbCBsb2NrIHRvIHByZXZlbnQgY29uY3VycmVuY3kgaXNzdWVzLg0KPj4+PiAtIE1vdmUg
c29tZSBjaGFuZ2VzIGluIGEgcHJlcGFyYXRpb24gcGF0Y2ggbW9kaWZ5aW5nIHBhcnRpbmZvIGZv
ciBzcHMgdG8NCj4+Pj4gcmVkdWNlIHRoaXMgcGF0Y2ggc2l6ZSBhbmQgbWFrZSB0aGUgcmV2aWV3
IGVhc2llcg0KPj4+PiBDaGFuZ2VzIGluIHY0Og0KPj4+PiAtIHByb3Blcmx5IGhhbmRsZSBTUE1D
IHZlcnNpb24gMS4wIGhlYWRlciBzaXplIGNhc2UgaW4gcGFydGluZm9fZ2V0DQo+Pj4+IC0gc3dp
dGNoIHRvIGxvY2FsIGNvdW50aW5nIHZhcmlhYmxlcyBpbnN0ZWFkIG9mICpwb2ludGVyICs9IDEg
Zm9ybQ0KPj4+PiAtIGNvZGluZyBzdHlsZSBpc3N1ZSB3aXRoIG1pc3Npbmcgc3BhY2VzIGluIGlm
ICgpDQo+Pj4+IENoYW5nZXMgaW4gdjM6DQo+Pj4+IC0gYnJlYWsgcGFydGluZm9fZ2V0IGluIHNl
dmVyYWwgc3ViIGZ1bmN0aW9ucyB0byBtYWtlIHRoZSBpbXBsZW1lbnRhdGlvbg0KPj4+PiBlYXNp
ZXIgdG8gdW5kZXJzdGFuZCBhbmQgbG9jayBoYW5kbGluZyBlYXNpZXINCj4+Pj4gLSByZXdvcmsg
aW1wbGVtZW50YXRpb24gdG8gY2hlY2sgc2l6ZSBhbG9uZyB0aGUgd2F5IGFuZCBwcmV2ZW50IHBy
ZXZpb3VzDQo+Pj4+IGltcGxlbWVudGF0aW9uIGxpbWl0cyB3aGljaCBoYWQgdG8gY2hlY2sgdGhh
dCB0aGUgbnVtYmVyIG9mIFZNcyBvciBTUHMNCj4+Pj4gZGlkIG5vdCBjaGFuZ2UNCj4+Pj4gLSB0
YWludCBYZW4gYXMgSU5TRUNVUkUgd2hlbiBWTSB0byBWTSBpcyBlbmFibGVkDQo+Pj4+IENoYW5n
ZXMgaW4gdjI6DQo+Pj4+IC0gU3dpdGNoIGlmZGVmIHRvIElTX0VOQUJMRUQNCj4+Pj4gLSBkb20g
d2FzIG5vdCBzd2l0Y2hlZCB0byBkIGFzIHJlcXVlc3RlZCBieSBKYW4gYmVjYXVzZSB0aGVyZSBp
cyBhbHJlYWR5DQo+Pj4+IGEgdmFyaWFibGUgZCBwb2ludGluZyB0byB0aGUgY3VycmVudCBkb21h
aW4gYW5kIGl0IG11c3Qgbm90IGJlDQo+Pj4+IHNoYWRvd2VkLg0KPj4+PiAtLS0NCj4+Pj4geGVu
L2FyY2gvYXJtL3RlZS9LY29uZmlnICAgICAgICB8ICAxMSArKysrDQo+Pj4+IHhlbi9hcmNoL2Fy
bS90ZWUvZmZhLmMgICAgICAgICAgfCAgNDcgKysrKysrKysrKysrKy0NCj4+Pj4geGVuL2FyY2gv
YXJtL3RlZS9mZmFfcGFydGluZm8uYyB8ICA5NSArKysrKysrKysrKysrKysrKysrKysrKystLS0N
Cj4+Pj4geGVuL2FyY2gvYXJtL3RlZS9mZmFfcHJpdmF0ZS5oICB8IDExMiArKysrKysrKysrKysr
KysrKysrKysrKysrKy0tLS0tLQ0KPj4+PiA0IGZpbGVzIGNoYW5nZWQsIDIzMyBpbnNlcnRpb25z
KCspLCAzMiBkZWxldGlvbnMoLSkNCj4+Pj4gDQo+Pj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9h
cm0vdGVlL0tjb25maWcgYi94ZW4vYXJjaC9hcm0vdGVlL0tjb25maWcNCj4+Pj4gaW5kZXggYzVi
MGY4OGQ3NTIyLi44OGE0YzRjOTkxNTQgMTAwNjQ0DQo+Pj4+IC0tLSBhL3hlbi9hcmNoL2FybS90
ZWUvS2NvbmZpZw0KPj4+PiArKysgYi94ZW4vYXJjaC9hcm0vdGVlL0tjb25maWcNCj4+Pj4gQEAg
LTI4LDUgKzI4LDE2IEBAIGNvbmZpZyBGRkENCj4+Pj4gDQo+Pj4+ICAgICAgICAgWzFdIGh0dHBz
Oi8vZGV2ZWxvcGVyLmFybS5jb20vZG9jdW1lbnRhdGlvbi9kZW4wMDc3L2xhdGVzdA0KPj4+PiAN
Cj4+Pj4gK2NvbmZpZyBGRkFfVk1fVE9fVk0NCj4+Pj4gKyAgICBib29sICJFbmFibGUgRkYtQSBi
ZXR3ZWVuIFZNcyAoVU5TVVBQT1JURUQpIiBpZiBVTlNVUFBPUlRFRA0KPj4+PiArICAgIGRlZmF1
bHQgbg0KPj4+PiArICAgIGRlcGVuZHMgb24gRkZBDQo+Pj4+ICsgICAgaGVscA0KPj4+PiArICAg
ICAgVGhpcyBvcHRpb24gZW5hYmxlcyB0byB1c2UgRkYtQSBiZXR3ZWVuIFZNcy4NCj4+Pj4gKyAg
ICAgIFRoaXMgaXMgZXhwZXJpbWVudGFsIGFuZCB0aGVyZSBpcyBubyBhY2Nlc3MgY29udHJvbCBz
byBhbnkNCj4+Pj4gKyAgICAgIGd1ZXN0IGNhbiBjb21tdW5pY2F0ZSB3aXRoIGFueSBvdGhlciBn
dWVzdC4NCj4+Pj4gKw0KPj4+PiArICAgICAgSWYgdW5zdXJlLCBzYXkgTi4NCj4+Pj4gKw0KPj4+
PiBlbmRtZW51DQo+Pj4+IA0KPj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3RlZS9mZmEu
YyBiL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+Pj4gaW5kZXggM2JiZGQ3MTY4YTZiLi5jMWM0
YzA5NTcwOTEgMTAwNjQ0DQo+Pj4+IC0tLSBhL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+Pj4g
KysrIGIveGVuL2FyY2gvYXJtL3RlZS9mZmEuYw0KPj4+PiBAQCAtMTE4LDYgKzExOCwxMyBAQCB2
b2lkICpmZmFfdHggX19yZWFkX21vc3RseTsNCj4+Pj4gREVGSU5FX1NQSU5MT0NLKGZmYV9yeF9i
dWZmZXJfbG9jayk7DQo+Pj4+IERFRklORV9TUElOTE9DSyhmZmFfdHhfYnVmZmVyX2xvY2spOw0K
Pj4+PiANCj4+Pj4gK3N0cnVjdCBsaXN0X2hlYWQgZmZhX2N0eF9oZWFkOw0KPj4+PiArLyogTG9j
ayB0byBwcm90ZWN0IGFkZGl0aW9uL3JlbW92YWwgaW4gZmZhX2N0eF9oZWFkICovDQo+Pj4+ICtE
RUZJTkVfU1BJTkxPQ0soZmZhX2N0eF9saXN0X2xvY2spOw0KPj4+PiArDQo+Pj4+ICsjaWZkZWYg
Q09ORklHX0ZGQV9WTV9UT19WTQ0KPj4+PiArYXRvbWljX3QgZmZhX3ZtX2NvdW50Ow0KPj4+PiAr
I2VuZGlmDQo+Pj4+IA0KPj4+PiAvKiBVc2VkIHRvIHRyYWNrIGRvbWFpbnMgdGhhdCBjb3VsZCBu
b3QgYmUgdG9ybiBkb3duIGltbWVkaWF0ZWx5LiAqLw0KPj4+PiBzdGF0aWMgc3RydWN0IHRpbWVy
IGZmYV90ZWFyZG93bl90aW1lcjsNCj4+Pj4gQEAgLTE2MCwxMCArMTY3LDIxIEBAIHN0YXRpYyB2
b2lkIGhhbmRsZV92ZXJzaW9uKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4+PiAgICAg
Ki8NCj4+Pj4gICAgaWYgKCBGRkFfVkVSU0lPTl9NQUpPUih2ZXJzKSA9PSBGRkFfTVlfVkVSU0lP
Tl9NQUpPUiApDQo+Pj4+ICAgIHsNCj4+Pj4gKyAgICAgICAgdWludDMyX3Qgb2xkX3ZlcnMgPSBB
Q0NFU1NfT05DRShjdHgtPmd1ZXN0X3ZlcnMpOw0KPj4+PiArDQo+Pj4+ICAgICAgICBpZiAoIEZG
QV9WRVJTSU9OX01JTk9SKHZlcnMpID4gRkZBX01ZX1ZFUlNJT05fTUlOT1IgKQ0KPj4+PiAtICAg
ICAgICAgICAgY3R4LT5ndWVzdF92ZXJzID0gRkZBX01ZX1ZFUlNJT047DQo+Pj4+ICsgICAgICAg
ICAgICBBQ0NFU1NfT05DRShjdHgtPmd1ZXN0X3ZlcnMpID0gRkZBX01ZX1ZFUlNJT047DQo+Pj4+
ICAgICAgICBlbHNlDQo+Pj4+IC0gICAgICAgICAgICBjdHgtPmd1ZXN0X3ZlcnMgPSB2ZXJzOw0K
Pj4+PiArICAgICAgICAgICAgQUNDRVNTX09OQ0UoY3R4LT5ndWVzdF92ZXJzKSA9IHZlcnM7DQo+
Pj4gDQo+Pj4gV2hhdCBpcyB0aGUgQUNDRVNTX09OQ0UoKSBzY2hlbWUgaW50ZW5kZWQgZm9yPw0K
Pj4+IA0KPj4+PiArDQo+Pj4+ICsgICAgICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfRkZBX1ZN
X1RPX1ZNKSAmJiAhb2xkX3ZlcnMgKQ0KPj4+IA0KPj4+IElmIGhhbmRsZV92ZXJzaW9uKCkgaXMg
Y2FsbGVkIGNvbmN1cnJlbnRseSBvbiB0d28gQ1BVcywgaXQgbWlnaHQgYmUNCj4+PiBwb3NzaWJs
ZSBmb3IgYSBjb250ZXh0IHRvIGJlIGFkZGVkIHR3aWNlLg0KPj4+IEhvdyBhYm91dCBhIHNlcGFy
YXRlIGZsYWcgdG8gaW5kaWNhdGUgd2hldGhlciBhIGNvbnRleHQgaGFzIGJlZW4gYWRkZWQNCj4+
PiB0byB0aGUgbGlzdD8NCj4+IA0KPj4gSSB3YW50ZWQgdG8gYXZvaWQgaGF2aW5nIGd1ZXN0X3Zl
cnMgYXMgYXRvbWljIG9yIGludHJvZHVjZSBhbiBvdGhlciBsb2NrLg0KPj4gQnV0IGkgdGhpbmsg
bm93IHRoYXQgdGhpcyBpcyBraW5kIG9mIGltcG9zc2libGUgdG8gYXZvaWQgYW5kIHRoaXMgd2F5
IHRvIGRvDQo+PiBpdCBpcyB3cm9uZy4NCj4+IA0KPj4gSSB3aWxsIHRha2UgdGhlIGNvbnRleHQg
bG9jayB0byBkbyB0aGlzIHByb2Nlc3NpbmcgdG8gYXZvaWQgdGhpcyBjb3JuZXIgY2FzZQ0KPj4g
YW5kIHJlbW92ZSB0aGUgQUNDRVNTX09OQ0UgdG8gcHJvdGVjdCBtb2RpZmljYXRpb25zIHRvIGd1
ZXN0X3ZlcnM6DQo+PiANCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jIGIv
eGVuL2FyY2gvYXJtL3RlZS9mZmEuYw0KPj4gaW5kZXggYjg2Yzg4Y2VmYThjLi4zMDZlZGI5Nzg2
M2EgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jDQo+PiArKysgYi94ZW4v
YXJjaC9hcm0vdGVlL2ZmYS5jDQo+PiBAQCAtMTU4LDYgKzE1OCw3IEBAIHN0YXRpYyB2b2lkIGhh
bmRsZV92ZXJzaW9uKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gICAgIHN0cnVjdCBk
b21haW4gKmQgPSBjdXJyZW50LT5kb21haW47DQo+PiAgICAgc3RydWN0IGZmYV9jdHggKmN0eCA9
IGQtPmFyY2gudGVlOw0KPj4gICAgIHVpbnQzMl90IHZlcnMgPSBnZXRfdXNlcl9yZWcocmVncywg
MSk7DQo+PiArICAgIHVpbnQzMl90IG9sZF92ZXJzOw0KPj4gDQo+PiAgICAgLyoNCj4+ICAgICAg
KiBHdWVzdCB3aWxsIHVzZSB0aGUgdmVyc2lvbiBpdCByZXF1ZXN0ZWQgaWYgaXQgaXMgb3VyIG1h
am9yIGFuZCBtaW5vcg0KPj4gQEAgLTE2NywxMiArMTY4LDE0IEBAIHN0YXRpYyB2b2lkIGhhbmRs
ZV92ZXJzaW9uKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gICAgICAqLw0KPj4gICAg
IGlmICggRkZBX1ZFUlNJT05fTUFKT1IodmVycykgPT0gRkZBX01ZX1ZFUlNJT05fTUFKT1IgKQ0K
Pj4gICAgIHsNCj4+IC0gICAgICAgIHVpbnQzMl90IG9sZF92ZXJzID0gQUNDRVNTX09OQ0UoY3R4
LT5ndWVzdF92ZXJzKTsNCj4+ICsgICAgICAgIHNwaW5fbG9jaygmY3R4LT5sb2NrKTsNCj4+ICsg
ICAgICAgIG9sZF92ZXJzID0gY3R4LT5ndWVzdF92ZXJzOw0KPj4gDQo+PiAgICAgICAgIGlmICgg
RkZBX1ZFUlNJT05fTUlOT1IodmVycykgPiBGRkFfTVlfVkVSU0lPTl9NSU5PUiApDQo+PiAtICAg
ICAgICAgICAgQUNDRVNTX09OQ0UoY3R4LT5ndWVzdF92ZXJzKSA9IEZGQV9NWV9WRVJTSU9OOw0K
Pj4gKyAgICAgICAgICAgY3R4LT5ndWVzdF92ZXJzID0gRkZBX01ZX1ZFUlNJT047DQo+PiAgICAg
ICAgIGVsc2UNCj4+IC0gICAgICAgICAgICBBQ0NFU1NfT05DRShjdHgtPmd1ZXN0X3ZlcnMpID0g
dmVyczsNCj4+ICsgICAgICAgICAgIGN0eC0+Z3Vlc3RfdmVycyA9IHZlcnM7DQo+PiArICAgICAg
ICBzcGluX3VubG9jaygmY3R4LT5sb2NrKTsNCj4+IA0KPj4gICAgICAgICBpZiAoIElTX0VOQUJM
RUQoQ09ORklHX0ZGQV9WTV9UT19WTSkgJiYgIW9sZF92ZXJzICkNCj4+ICAgICAgICAgew0KPj4g
DQo+PiBXaGF0IGRvIHlvdSB0aGluayA/DQo+IA0KPiBUaGF0IHdvcmtzLiBJdCBtaWdodCBiZSB3
b3J0aCBhZGRpbmcgYSBjb21tZW50IHRoYXQgY3R4LT5ndWVzdF92ZXJzIGlzDQo+IGFjY2Vzc2Vk
IHVubG9ja2VkIGVsc2V3aGVyZSwgYW5kIHdoeSB0aGF0IGlzIE9LLg0KDQpJbiBmYWN0IHRoZXJl
IGlzIGFuIG90aGVyIEFDQ0VTU19PTkNFIG9uIGd1ZXN0X3ZlcnMgdGhhdCBpIHdpbGwgcmVtb3Zl
DQphcyBpdCBpbiB0ZWFyZG93biBhbmQgdGhlcmUgaXMgbm8gbmVlZCBmb3IgaXQuDQoNCkkgd2ls
bCBhZGQgYSBjb21tZW50IGluIHRoZSBmZmFfcHJpdmF0ZS5oIHRvIHN0YXRlIHRoYXQgbW9kaWZp
Y2F0aW9uIGFyZSBwcm90ZWN0ZWQNCmJ5IHRoZSBjb250ZXh0IGxvY2suDQoNClRoaXMgY29kZSB3
aWxsIGJlIHJld29ya2VkIGluIHRoZSBuZXh0IHNlcmllIHdpdGggdjEuMiBzdXBwb3J0IGFzIHRo
ZSBndWlkYW5jZQ0KYmVjYW1lIGNsZWFyZXIgaW4gdGhlIHYxLjIgc3BlYyBhbmQgdGhpcyB3aWxs
IHJlbW92ZSBzb21lIGlzc3Vlcy4NCg0KQ2hlZXJzDQpCZXJ0cmFuZA0KDQoNCj4gDQo+IENoZWVy
cywNCj4gSmVucw0KDQoNCg==


From xen-devel-bounces@lists.xenproject.org Thu May 22 06:41:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 06:41:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992935.1376400 (Exim 4.92)
	(envelope-from )
	id 1uHzcF-0005TU-Sw; Thu, 22 May 2025 06:41:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992935.1376400; Thu, 22 May 2025 06:41: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 1uHzcF-0005TN-OR; Thu, 22 May 2025 06:41:19 +0000
Received: by outflank-mailman (input) for mailman id 992935;
 Thu, 22 May 2025 06:41:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uHzZ9-0003lz-Gv
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 06:38:07 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on2061c.outbound.protection.outlook.com
 [2a01:111:f403:260c::61c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 51d1e9af-36d7-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 08:38:07 +0200 (CEST)
Received: from DUZPR01CA0007.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:3c3::11) by DB3PR08MB9088.eurprd08.prod.outlook.com
 (2603:10a6:10:436::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 06:38:04 +0000
Received: from DU6PEPF0000B61C.eurprd02.prod.outlook.com
 (2603:10a6:10:3c3:cafe::c) by DUZPR01CA0007.outlook.office365.com
 (2603:10a6:10:3c3::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 22 May 2025 06:38:16 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DU6PEPF0000B61C.mail.protection.outlook.com (10.167.8.135) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Thu, 22 May 2025 06:38:03 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DB3PR08MB10336.eurprd08.prod.outlook.com (2603:10a6:10:43b::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 06:37:31 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%3]) with mapi id 15.20.8699.022; Thu, 22 May 2025
 06:37: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" 
X-Inumbo-ID: 51d1e9af-36d7-11f0-a2fb-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=QE3e7I4wfOeBIl0VTMaAuwz40hE6DCkntTL56otMOuNEAYXwttjgZ772bxZqF5T9zy2nAWeMbFqHaXeNk9F1gPQJFdl2X2MQP+Gu2vL905SWFcWEQWKtGtlkU2vwI3LJe+/o+oNf5DK8fRat2Xmn5rKQzIiOrIEkC+PyKLV6kMAdP+MPrtRzxSn+vlUfhEQpNXvtbuX5idSvy1htSRNlAI4W+Iauu5azCT/s8rYOY/5cwsTmTYA56I9ldn2FO4bdLETDOksI04QVqMbKy9tkLEJD7bHNf2IiB/3psiBPeknnYLvUzghGTkIc66KvxZ3azJbV65XuGYFtZL2Jx5xrlQ==
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=yuGhrbvwPujqvDryH/rJ1rbDnCyY1eN/Ff6Wa5GnYlM=;
 b=aDQ0/mVu2UNRoebTjKqHifLodj7h4JKntv2ymJGz/Nga2gPe0E2qm9y/BUHXJyiTMK3yl1J50dEaiOxjNisU/e+9MvSecc5rF5xbxZahSL8gf5SokLz1lZPNgczNP6nQtwFl6MUAK7N9gdm1DkMtOvOa6yXszyEq/5k4NilZPNEi/Bhp18EVI98kjrKxlf0Pu+zMT5NzgIHJeJwQcgDLoun+7h1z7ab5GBF0Uq8zkr7y+TS/ntQcsKAwGkRKV+5U1680YIGenoHug0MAkoEcJO2Qkzi3YVA7TfjjHPf7OI0uzeIaLuJ1eAPeFiMRexT+gtLkHk5ddG32Y9w7tATQ5A==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=linaro.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=yuGhrbvwPujqvDryH/rJ1rbDnCyY1eN/Ff6Wa5GnYlM=;
 b=p3cI8uAJOc5WKyRGvsdqQNm1ZjJWEPb4RasELtvYt16ggy/kv5GQUESMNBBNCfkWIuA/OxyfC58e6aw91TN8h7bfIwrBdnzrByStMz+fYnRhYqvsXUR4J67yl4RPc1iwnF7zwuiBo1XLBuAMiHDnJ/Mora6ekLsj9ZBEPFIV/UA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qWl6JSc6rslhRoiRgz99G0eRW5b5QBZ6MXpSL/QY0ZrtTp9T062SUvfXNJO6btfVT5sVF4xiZHfKPtPLIbvoDdfjIOlgQR4StL8VZeY5yweonq5VM388MYpsjjSEifsUfL492o28xe0IV+fObdI3NEPilj6gB6JN41rh8z2kHV8UHi2gmZq8WY0Gps2BymrxAhUlXqOSVn1W9YQm8wAQGfID1ddcgCKK4LncfackOtns4Sv7F4ABcJTnQtZEufq/1ONtGrKzUYZiGtvHcI5Bj52EzUwSR6QJpPG/ytl06HJ95Z94GYhfFSAOYjdy+j79epF3cAmDrcg/k9sSJJIShQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=yuGhrbvwPujqvDryH/rJ1rbDnCyY1eN/Ff6Wa5GnYlM=;
 b=Auo6kHO2zwTl0qsJqps6AvvqHEGe8oWcoHVWC0YwDe5PxdWJ0w9cSRV25Rh0eGpKuwG66BKmSCSaM2phjI/EqyLNomOIymznPtuc6XI6D6M7q1snB5oyzFan9G3PjF8h7hFz6EUqLRB/YYKJhVXmCBN0O6sNtRfXBjYnjvMuAb1RixfeGh1CKOOM7pcP5Qgi1aDmr0rdSDP+1XiLeCM9C2Sf/Gsw0QxAyeJrPCW4xeRcFDSloRX0pDKk1bKbzbXDAVCBC0t0vzd+ykfWDNmQCK+asczw//eEeKejkLTXTiTuC4AjBW5pmhYaqBqJ3+9Sb1cK2lWrViduci7CXL6cyg==
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=yuGhrbvwPujqvDryH/rJ1rbDnCyY1eN/Ff6Wa5GnYlM=;
 b=p3cI8uAJOc5WKyRGvsdqQNm1ZjJWEPb4RasELtvYt16ggy/kv5GQUESMNBBNCfkWIuA/OxyfC58e6aw91TN8h7bfIwrBdnzrByStMz+fYnRhYqvsXUR4J67yl4RPc1iwnF7zwuiBo1XLBuAMiHDnJ/Mora6ekLsj9ZBEPFIV/UA=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: "xen-devel@lists.xenproject.org" ,
	Volodymyr Babchuk , Stefano Stabellini
	, Julien Grall , Michal Orzel
	
Subject: Re: [PATCH v5 5/6] xen/arm: ffa: Add indirect message between VM
Thread-Topic: [PATCH v5 5/6] xen/arm: ffa: Add indirect message between VM
Thread-Index: AQHbrqLZUo9s1RWIvkuj+N+Xve97jrPdhJCAgADmGoA=
Date: Thu, 22 May 2025 06:37:31 +0000
Message-ID: <1E1317C0-DBF7-4A07-A7BC-BC04B3FF7F03@arm.com>
References: 
 <81ec9ce34c3990b02ec6427d95b6238445333b57.1744787720.git.bertrand.marquis@arm.com>
 
In-Reply-To:
 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DB3PR08MB10336:EE_|DU6PEPF0000B61C:EE_|DB3PR08MB9088:EE_
X-MS-Office365-Filtering-Correlation-Id: 7f561047-9c93-4c25-64b1-08dd98fb3466
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|10070799003|1800799024|366016|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?Q1ZCM0lialZvOGRYcUpubUlubURnYUFCS3NDSGt1TTltZzhlR0gvT2R2U3M5?=
 =?utf-8?B?cWhzQUpqdGRQQTFwQ0JYbXlISk05akhQWHlId1NLdHk4ZkdRSzVVcVhSWEVC?=
 =?utf-8?B?WDlnMnhGYktlZExqTU80TDFKbDdxT3J2ak9rRTVKSGdSUnloY0d1TjlOOXYx?=
 =?utf-8?B?ZTVTQmxPbVBmSm9heitlZUUrQU5IUlFlMmxhYWdzblZuQzBIZjVpSDI5blBy?=
 =?utf-8?B?TUdWNzUvQ3UzcEgxYStnd1lTMFB0NXQ2Qmoyd0RiTGYvdndlTjZpTXZhaklp?=
 =?utf-8?B?OGFscnNNLzAzZVIyb1M1c3kyVUh6UDVaTkFkM0ZRWFZJWi9mN0lqNzdPOFp0?=
 =?utf-8?B?aWE1clpNN2ExdVZTd2hzT2hwSVIxbUVEOERCUkVxNnd1c05Sdk5PelB4dkdG?=
 =?utf-8?B?b1RseFlCQStJWUF2ZjlQVlM0TE1Hb0JFMnd0bXJKQlRQNWNDZGRPVkRkS0Vl?=
 =?utf-8?B?MGtwRTllYlB0N3hYbjZwNkhnQWNydWIxbVc2RVRwNWlwL1Bwb21IMTZmREJw?=
 =?utf-8?B?Y0pnb2VNcnhBaXNYRGhER3VrQlg4aGtKLy9PM0ZvWDJSU2tOWXRnTmhobVIr?=
 =?utf-8?B?d04xWVd3OHNnOGRkUHhYNlVBb0VJbXNBQXJISTNOS21HdWVCNE02S2xQYnNB?=
 =?utf-8?B?MmNyR0gybDNoS0oyT28rN0JaeXlZWTY0TDN2cDBJNTVMY0ZZMG94Q1FsNngw?=
 =?utf-8?B?WUQvUEQwZVpEMDZDRVZPVEdUWGhGdTZrN2RJUXQ2SlFHcFc5RVN3Nmc3QnZw?=
 =?utf-8?B?NC9WZmo4TDVkOTV0WXRSY1I2UGM1dkhCZTlVQVFyc0lleEN4aWZjS3doeFE2?=
 =?utf-8?B?RTh4OExSM00zT2xhZG8yRS9tSVUrTXpoRG4xaHRZZkdBZFNOSnRNUDhiVkdN?=
 =?utf-8?B?VmdyY1pxV2ZXVHFiOFVVMVJkSXJBNTdrSm5kMGR0KzdRcmgyT0M3c24vejZ0?=
 =?utf-8?B?Y3hyWlBtN2Y4YktUdkRBNGZkdCt1RXN4eW56blhMQXpKMWhwZVVyTE1qbVZm?=
 =?utf-8?B?dXpvYW5wMmMwSHBXc2xDeGI5K0dmcEl0dnYweWtYREYvOHB3SzJ1QTV4MHdT?=
 =?utf-8?B?UVZFRlZSbnJDY1hhMjZHbjEwZ1hIdm0vaUZrKzNMT1EzbUpUb2Q2ZWU5a3hq?=
 =?utf-8?B?NlVXUVlVY0RuN2RTTGE4eGF1VVQyd000ZzRiS3ZQR2hTKzNiV2JTb3F0NEhs?=
 =?utf-8?B?YnVQTVVZV1ozTGdiMk1xYXVWUitld2hDODVOcVY2MmVaWUZDMEthY1VKRVcr?=
 =?utf-8?B?c1BNUXQrL3cwRmUxaW1YeTkwd1hVMm5zVC9OWjV6WjQyQ0lXb21wWjRQREg3?=
 =?utf-8?B?V09qS3ZVN2hjRkN5cVdwYlI4UEpWbVJLcnVDRXFlVCtmcjhXTEVXejVFcVZj?=
 =?utf-8?B?YnJES0Fqc3RieWk3Qy9WNUlqTld1bkw5L1k2b0N1eHp6K3VIbGdyc0xlUjVs?=
 =?utf-8?B?TXVmQW5GcUlLQ1dPSUhrcXdCRFMzQzJWOFRweTFBMUVJMVl0Qlp3MVU1M1FP?=
 =?utf-8?B?Z0lNYlFNcHhqWEo2ZDFGaXowdHVDVFc3RFU4MER0dFRxUDl2VnFHczdWNjJi?=
 =?utf-8?B?V2p1TldRVlFtN1FvZXhZRndMQ1pveTVOMUV3ekRVc09rak8xc2p2dlorYmhL?=
 =?utf-8?B?TFJuNUVoTEtPR1JDeE0wVGdjRFZWZFFEdmtYUnBEVUdkTG96Y2RaSkIxSEtL?=
 =?utf-8?B?M1J5Z2xTUjVVNmxsMUE2MHlxRFQydGQ1TG10c2xuMkc0R1pHVVZhWE8zREow?=
 =?utf-8?B?aWRBOE0ram1kQVZyZFZJeEo3eXhkS3NHN0RGOU54WEJZdWZKTFFVb0JMR0s2?=
 =?utf-8?B?OVNTWTRCbGhrWDdWdTRKekt3cTMxNTlqZ2dCbG9wVjQzUWx2cU1rOVRLRElm?=
 =?utf-8?B?L2xSQm1LUnczMitHWFRmdDdKSnJreU9TWGNIcitGVmE2ZWFvbC8xbnJnVkR1?=
 =?utf-8?B?R215WFgvc2NjcS9WckI5NTFnalRBQzVBc3dhUTdlVVErMHk3SmZTb1pSR0pZ?=
 =?utf-8?B?OGdFSFg1TGh3PT0=?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB10336
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF0000B61C.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	689bedc0-ac89-48d8-4235-08dd98fb20fe
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|1800799024|36860700013|82310400026|14060799003|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MDZZYlFYMklIMFR3M3E0VUxyZjFwWmxVV2NTWXRCb3RqRFMxYU5PbXk0Qi9T?=
 =?utf-8?B?QnE1M1NFcjdWeWpycFNsZ0hoY1hQeDBONU40OTJneXIyelpUM3pGaDNCbzlL?=
 =?utf-8?B?bHdNVlBJZGEwNjVLN2theUJvOWRJUVBKSE1HTkFxVTl2Q3FNejh0eDNIckFw?=
 =?utf-8?B?d21rbVY2eUdOR1lSdnppZTJ6MFdTc3VqY2dEQzRqRURKem4rTVBEOHVMSmFz?=
 =?utf-8?B?eVFpWElaRmlTeDdPajljell5THlJcW02OXpiTFZRTmltcktCajd5eHFvcHhK?=
 =?utf-8?B?c3pkUzNCaW8yQVQ2MXlMSE9oZEV5a3NWOGMxUXhrMjVTdkJQTVN4bjJHVjJ0?=
 =?utf-8?B?M3lpRmZsSU95eW9pZDJMMFErblpxNHk4dEVQRUZvVG00ZHRpbkZZWU51OHBP?=
 =?utf-8?B?ejc4dW9ta3cyUTV2NmxyaGI0VnJaOGsvanJMaTIvd1liWG5FaDZ1MUxTSEhG?=
 =?utf-8?B?OUZyQ0ZtU2JaRmxhZW9LVUFlKzZCd3dGVGcwSzVpSlVMK0FnclB2SWorVjBj?=
 =?utf-8?B?SGxFR1A2bzJuSlRxMk9jcXgyeDNMNTJLYkFlZnZHL0lCOW96aUhPQzJiNkNt?=
 =?utf-8?B?UGlsdVZzVGRucHRqdFVseVRmcEZra1RDaGthL2hvUHV5YVV2a0ZwWFY5emJk?=
 =?utf-8?B?bnBveXZoSlBIamhhcWNoVG4wQXVjR1lad3VuY2JERnNaSlA2YlM4emhRTzZa?=
 =?utf-8?B?Uk1tMk9yM0hhL1NsczBtenZUZ1JsVXNnYUhjNUQrNVFzN2tXTHpTZktLb0Zi?=
 =?utf-8?B?STFSdVczNkZEZ2IxSG1VM1dhOTNLdElOQ09KUkFXTkk4bVNwK2FxelNBdnBV?=
 =?utf-8?B?NDh3U1dISHc3VHZFU1ZQYS9TTzUrYkJsM3Uyc1lWYjRBWkljakMzeWRzZmZw?=
 =?utf-8?B?MU9WK1ZLWEFmeUdtOWpqYjYzNWZrL25OWEdFOHdGOFZ3aWIwNEpYZTVsTlp4?=
 =?utf-8?B?VlpIVTJ2cHlOKzAycldSdy93SGtWRnBtemJKaWZLVlJOVFZpakpyRExvVS9q?=
 =?utf-8?B?VFdyWGxWMy9nRk44SHhscndrcFV1a3JnNkVJSTRqRzhFT0ZUZldlQ3JzYWhp?=
 =?utf-8?B?SzhJbERCL0ZvNDBPdDNnTUdCYTA3RWxFR0xib0wxQWxZc0tqd2kyNWtzUjRu?=
 =?utf-8?B?QXhXcGtFOUhlWUVZVi9EZWpaNzh1ck1Xd1JzQ2pnMzZ1VitSODA0VnJsbllM?=
 =?utf-8?B?bFJJM3QyaVN6aXZPOTBoMEhFZCttVVBTWk1MaHpzSnIxa3JrRDVZTldHQWxJ?=
 =?utf-8?B?VUp3SXNObHRmN1VYNXNaR0tSelpaTE5NTDYrUHltTnowVWxneHBSM2JPMnl0?=
 =?utf-8?B?SFVhbkNjYjFURWFIZ2piTFB2WFJFRkxzeFRVVDhHVDR3dWZaRVNrZjloWW5s?=
 =?utf-8?B?cGwxWC9wMU15a3pXeVM4elQ3eHNvRjhLYmZmbnVjL3JtOUh6TGZHK3VqZXJB?=
 =?utf-8?B?Nm02eFU5T3FGcVBQVGJDdGY2ZldjTDcxUzAxbVNyNUx2SEdhOTJzUHFQcUVH?=
 =?utf-8?B?YU9yb1B3ZEdpd0RsYVBKdUF6eGMvUCtXMzcvamVHZzFCVkZOMWV3VzdOY2lt?=
 =?utf-8?B?c0YxS3lVaVI0TVFLSkpnWXZUZVpZcmJ1cVhnOUk2OTJPNFEvY0YrcVBOOS9P?=
 =?utf-8?B?MW1NQU9ua2NiWDhLblZRb0JsZ0R0UW1YckhuVU43bUozSkVKRUlaZzVTVWx0?=
 =?utf-8?B?UU1oVlVQUzhEdzAzR2hrSWl0ME1CazFkekNweTREQ2ErVTdrYmdTTDN5ZDlh?=
 =?utf-8?B?cHRGY0dOam5RbXF3UTBueUZidjh5YklhUUVxRE92djdsd2JrTGlGUmlLTk1x?=
 =?utf-8?B?eEpYcHNvb3RyWHVsejEzSG8xdGNwTzhvUG5KZksrMUw3eVVoZm82NXdtTlpl?=
 =?utf-8?B?ZDh1bFREc0wxV0lxbkV6WG0rT3phS2taZUNnZllmZS9KMEpCRWRGbzhDQjRS?=
 =?utf-8?B?ZU9hZGNTeENGVGQvVGJ4QTRtNE1JNVFaY1B5K0tkYmpvK2EwNmF1dEcxclhY?=
 =?utf-8?B?KzJRT0xmVFI0anNrMnA4ZG13TXNPdkxCVlNTZTFTNzZHYkNNUWszNUsxdDBz?=
 =?utf-8?Q?NOVERG?=
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)(1800799024)(36860700013)(82310400026)(14060799003)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 06:38:03.8719
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f561047-9c93-4c25-64b1-08dd98fb3466
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:
	DU6PEPF0000B61C.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB9088

DQoNCj4gT24gMjEgTWF5IDIwMjUsIGF0IDE4OjUzLCBKZW5zIFdpa2xhbmRlciA8amVucy53aWts
YW5kZXJAbGluYXJvLm9yZz4gd3JvdGU6DQo+IA0KPiBIaSBCZXJ0cmFuZCwNCj4gDQo+IE9uIFdl
ZCwgQXByIDE2LCAyMDI1IGF0IDk6NDDigK9BTSBCZXJ0cmFuZCBNYXJxdWlzDQo+IDxiZXJ0cmFu
ZC5tYXJxdWlzQGFybS5jb20+IHdyb3RlOg0KPj4gDQo+PiBBZGQgc3VwcG9ydCBmb3IgaW5kaXJl
Y3QgbWVzc2FnZXMgYmV0d2VlbiBWTXMuDQo+PiBUaGlzIGlzIG9ubHkgZW5hYmxlZCBpZiBDT05G
SUdfRkZBX1ZNX1RPX1ZNIGlzIHNlbGVjdGVkLg0KPj4gDQo+PiBTaWduZWQtb2ZmLWJ5OiBCZXJ0
cmFuZCBNYXJxdWlzIDxiZXJ0cmFuZC5tYXJxdWlzQGFybS5jb20+DQo+PiAtLS0NCj4+IENoYW5n
ZXMgaW4gdjU6DQo+PiAtIFByZXZlbnQgcG90ZW50aWFsIG92ZXJmbG93IGluIHNlbmQyIGhhbmRs
aW5nIChKdWxpZW4pDQo+PiAtIE9ubHkgdXNlIHBhZ2VfY291bnQgd2l0aCByeCBsb2NrIGFjcXVp
cmVkDQo+PiAtIEZpeCBhbiBpc3N1ZSB3aGVyZSBzZW5kMiBiZXR3ZWVuIFZNcyB3YXMgbm90IGRv
aW5nIHRoZSBjb3B5IGZyb20gdGhlDQo+PiAgdHggYnVmZmVyIGJ1dCBmcm9tIGEgd3JvbmcgbG9j
YXRpb24gaW4gdGhlIHN0YWNrLiBUaGlzIGJ1ZyB3YXMNCj4+ICBpbnRyb2R1Y2VkIGluIHY0IHdo
ZW4gc3dpdGNoaW5nIHRvIGEgbG9jYWwgY29weSBmb3IgdGhlIGhlYWRlci4NCj4+IENoYW5nZXMg
aW4gdjQ6DQo+PiAtIFVzZSBhIGxvY2FsIGNvcHkgb2YgdGhlIG1lc3NhZ2UgaGVhZGVyIHRvIHBy
ZXZlbnQgYSBUT0MvVE9VIHBvc3NpYmxlDQo+PiAgaXNzdWUgd2hlbiB1c2luZyB0aGUgcGF5bG9h
ZCBzaXplDQo+PiBDaGFuZ2VzIGluIHYzOg0KPj4gLSBNb3ZlIHZtIHRvIHZtIGluZGlyZWN0IG1l
c3NhZ2UgaGFuZGxpbmcgaW4gYSBzdWIgZnVuY3Rpb24gdG8gc2ltcGxpZnkNCj4+ICBsb2NrIGhh
bmRsaW5nIGFuZCBtYWtlIGltcGxlbWVudGF0aW9uIGVhc2llciB0byByZWFkDQo+PiBDaGFuZ2Vz
IGluIHYyOg0KPj4gLSBTd2l0Y2ggaWZkZWYgdG8gSVNfRU5BQkxFRA0KPj4gLS0tDQo+PiB4ZW4v
YXJjaC9hcm0vdGVlL2ZmYV9tc2cuYyB8IDExNSArKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKy0tLS0tDQo+PiAxIGZpbGUgY2hhbmdlZCwgMTAxIGluc2VydGlvbnMoKyksIDE0IGRlbGV0
aW9ucygtKQ0KPj4gDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3RlZS9mZmFfbXNnLmMg
Yi94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9tc2cuYw0KPj4gaW5kZXggZWU1OTRlNzM3ZmM3Li4zNWRl
MjYwYzAxM2EgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9tc2cuYw0KPj4g
KysrIGIveGVuL2FyY2gvYXJtL3RlZS9mZmFfbXNnLmMNCj4+IEBAIC04OCw0MyArODgsMTMwIEBA
IG91dDoNCj4+ICAgICAgICAgICAgICAgICAgcmVzcC5hNyAmIG1hc2spOw0KPj4gfQ0KPj4gDQo+
PiArc3RhdGljIGludDMyX3QgZmZhX21zZ19zZW5kMl92bSh1aW50MTZfdCBkc3RfaWQsIGNvbnN0
IHZvaWQgKnNyY19idWYsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1
Y3QgZmZhX3BhcnRfbXNnX3J4dHggKnNyY19tc2cpDQo+PiArew0KPj4gKyAgICBzdHJ1Y3QgZG9t
YWluICpkc3RfZDsNCj4+ICsgICAgc3RydWN0IGZmYV9jdHggKmRzdF9jdHg7DQo+PiArICAgIHN0
cnVjdCBmZmFfcGFydF9tc2dfcnh0eCAqZHN0X21zZzsNCj4+ICsgICAgaW50IGVycjsNCj4+ICsg
ICAgaW50MzJfdCByZXQ7DQo+PiArDQo+PiArICAgIGlmICggZHN0X2lkID09IDAgKQ0KPj4gKyAg
ICAgICAgLyogRkYtQSBJRCAwIGlzIHRoZSBoeXBlcnZpc29yLCB0aGlzIGlzIG5vdCB2YWxpZCAq
Lw0KPj4gKyAgICAgICAgcmV0dXJuIEZGQV9SRVRfSU5WQUxJRF9QQVJBTUVURVJTOw0KPj4gKw0K
Pj4gKyAgICAvKiBUaGlzIGlzIGFsc28gY2hlY2tpbmcgdGhhdCBkZXN0IGlzIG5vdCBzcmMgKi8N
Cj4+ICsgICAgZXJyID0gcmN1X2xvY2tfbGl2ZV9yZW1vdGVfZG9tYWluX2J5X2lkKGRzdF9pZCAt
IDEsICZkc3RfZCk7DQo+PiArICAgIGlmICggZXJyICkNCj4+ICsgICAgICAgIHJldHVybiBGRkFf
UkVUX0lOVkFMSURfUEFSQU1FVEVSUzsNCj4+ICsNCj4+ICsgICAgaWYgKCBkc3RfZC0+YXJjaC50
ZWUgPT0gTlVMTCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHJldCA9IEZGQV9SRVRfSU5WQUxJ
RF9QQVJBTUVURVJTOw0KPj4gKyAgICAgICAgZ290byBvdXRfdW5sb2NrOw0KPj4gKyAgICB9DQo+
PiArDQo+PiArICAgIGRzdF9jdHggPSBkc3RfZC0+YXJjaC50ZWU7DQo+PiArICAgIGlmICggIWRz
dF9jdHgtPmd1ZXN0X3ZlcnMgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICByZXQgPSBGRkFfUkVU
X0lOVkFMSURfUEFSQU1FVEVSUzsNCj4+ICsgICAgICAgIGdvdG8gb3V0X3VubG9jazsNCj4+ICsg
ICAgfQ0KPj4gKw0KPj4gKyAgICAvKiBUaGlzIGFsc28gY2hlY2tzIHRoYXQgZGVzdGluYXRpb24g
aGFzIHNldCBhIFJ4IGJ1ZmZlciAqLw0KPj4gKyAgICByZXQgPSBmZmFfcnhfYWNxdWlyZShkc3Rf
ZCk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIGdvdG8gb3V0X3VubG9jazsNCj4+
ICsNCj4+ICsgICAgLyogd2UgbmVlZCB0byBoYXZlIGVub3VnaCBzcGFjZSBpbiB0aGUgZGVzdGlu
YXRpb24gYnVmZmVyICovDQo+PiArICAgIGlmICggKGRzdF9jdHgtPnBhZ2VfY291bnQgKiBGRkFf
UEFHRV9TSVpFIC0NCj4+ICsgICAgICAgICAgc2l6ZW9mKHN0cnVjdCBmZmFfcGFydF9tc2dfcnh0
eCkpIDwgc3JjX21zZy0+bXNnX3NpemUgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICByZXQgPSBG
RkFfUkVUX05PX01FTU9SWTsNCj4+ICsgICAgICAgIGZmYV9yeF9yZWxlYXNlKGRzdF9kKTsNCj4+
ICsgICAgICAgIGdvdG8gb3V0X3VubG9jazsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBkc3Rf
bXNnID0gZHN0X2N0eC0+cng7DQo+PiArDQo+PiArICAgIC8qIHByZXBhcmUgZGVzdGluYXRpb24g
aGVhZGVyICovDQo+PiArICAgIGRzdF9tc2ctPmZsYWdzID0gMDsNCj4+ICsgICAgZHN0X21zZy0+
cmVzZXJ2ZWQgPSAwOw0KPj4gKyAgICBkc3RfbXNnLT5tc2dfb2Zmc2V0ID0gc2l6ZW9mKHN0cnVj
dCBmZmFfcGFydF9tc2dfcnh0eCk7DQo+PiArICAgIGRzdF9tc2ctPnNlbmRfcmVjdl9pZCA9IHNy
Y19tc2ctPnNlbmRfcmVjdl9pZDsNCj4+ICsgICAgZHN0X21zZy0+bXNnX3NpemUgPSBzcmNfbXNn
LT5tc2dfc2l6ZTsNCj4+ICsNCj4+ICsgICAgbWVtY3B5KGRzdF9jdHgtPnJ4ICsgc2l6ZW9mKHN0
cnVjdCBmZmFfcGFydF9tc2dfcnh0eCksDQo+PiArICAgICAgICAgICBzcmNfYnVmICsgc3JjX21z
Zy0+bXNnX29mZnNldCwgc3JjX21zZy0+bXNnX3NpemUpOw0KPj4gKw0KPj4gKyAgICAvKiByZWNl
aXZlciByeCBidWZmZXIgd2lsbCBiZSByZWxlYXNlZCBieSB0aGUgcmVjZWl2ZXIqLw0KPj4gKw0K
Pj4gK291dF91bmxvY2s6DQo+PiArICAgIHJjdV91bmxvY2tfZG9tYWluKGRzdF9kKTsNCj4+ICsg
ICAgaWYgKCAhcmV0ICkNCj4+ICsgICAgICAgIGZmYV9yYWlzZV9yeF9idWZmZXJfZnVsbChkc3Rf
ZCk7DQo+PiArDQo+PiArICAgIHJldHVybiByZXQ7DQo+PiArfQ0KPj4gKw0KPj4gaW50MzJfdCBm
ZmFfaGFuZGxlX21zZ19zZW5kMihzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCj4+IHsNCj4+
ICAgICBzdHJ1Y3QgZG9tYWluICpzcmNfZCA9IGN1cnJlbnQtPmRvbWFpbjsNCj4+ICAgICBzdHJ1
Y3QgZmZhX2N0eCAqc3JjX2N0eCA9IHNyY19kLT5hcmNoLnRlZTsNCj4+IC0gICAgY29uc3Qgc3Ry
dWN0IGZmYV9wYXJ0X21zZ19yeHR4ICpzcmNfbXNnOw0KPj4gKyAgICBzdHJ1Y3QgZmZhX3BhcnRf
bXNnX3J4dHggc3JjX21zZzsNCj4+ICAgICB1aW50MTZfdCBkc3RfaWQsIHNyY19pZDsNCj4+ICAg
ICBpbnQzMl90IHJldDsNCj4+IA0KPj4gLSAgICBpZiAoICFmZmFfZndfc3VwcG9ydHNfZmlkKEZG
QV9NU0dfU0VORDIpICkNCj4+IC0gICAgICAgIHJldHVybiBGRkFfUkVUX05PVF9TVVBQT1JURUQ7
DQo+PiArICAgIEJVSUxEX0JVR19PTihzaXplb2Yoc3RydWN0IGZmYV9wYXJ0X21zZ19yeHR4KSA+
PSBGRkFfUEFHRV9TSVpFKTsNCj4+IA0KPj4gICAgIGlmICggIXNwaW5fdHJ5bG9jaygmc3JjX2N0
eC0+dHhfbG9jaykgKQ0KPj4gICAgICAgICByZXR1cm4gRkZBX1JFVF9CVVNZOw0KPj4gDQo+PiAt
ICAgIHNyY19tc2cgPSBzcmNfY3R4LT50eDsNCj4+IC0gICAgc3JjX2lkID0gc3JjX21zZy0+c2Vu
ZF9yZWN2X2lkID4+IDE2Ow0KPj4gLSAgICBkc3RfaWQgPSBzcmNfbXNnLT5zZW5kX3JlY3ZfaWQg
JiBHRU5NQVNLKDE1LDApOw0KPj4gKyAgICAvKiBjcmVhdGUgYSBjb3B5IG9mIHRoZSBtZXNzYWdl
IGhlYWRlciAqLw0KPj4gKyAgICBtZW1jcHkoJnNyY19tc2csIHNyY19jdHgtPnR4LCBzaXplb2Yo
c3JjX21zZykpOw0KPj4gDQo+PiAtICAgIGlmICggc3JjX2lkICE9IGZmYV9nZXRfdm1faWQoc3Jj
X2QpIHx8ICFGRkFfSURfSVNfU0VDVVJFKGRzdF9pZCkgKQ0KPj4gKyAgICBzcmNfaWQgPSBzcmNf
bXNnLnNlbmRfcmVjdl9pZCA+PiAxNjsNCj4+ICsgICAgZHN0X2lkID0gc3JjX21zZy5zZW5kX3Jl
Y3ZfaWQgJiBHRU5NQVNLKDE1LDApOw0KPj4gKw0KPj4gKyAgICBpZiAoIHNyY19pZCAhPSBmZmFf
Z2V0X3ZtX2lkKHNyY19kKSApDQo+PiAgICAgew0KPj4gICAgICAgICByZXQgPSBGRkFfUkVUX0lO
VkFMSURfUEFSQU1FVEVSUzsNCj4+IC0gICAgICAgIGdvdG8gb3V0X3VubG9ja190eDsNCj4+ICsg
ICAgICAgIGdvdG8gb3V0Ow0KPj4gICAgIH0NCj4+IA0KPj4gICAgIC8qIGNoZWNrIHNvdXJjZSBt
ZXNzYWdlIGZpdHMgaW4gYnVmZmVyICovDQo+PiAtICAgIGlmICggc3JjX2N0eC0+cGFnZV9jb3Vu
dCAqIEZGQV9QQUdFX1NJWkUgPA0KPj4gLSAgICAgICAgIHNyY19tc2ctPm1zZ19vZmZzZXQgKyBz
cmNfbXNnLT5tc2dfc2l6ZSB8fA0KPj4gLSAgICAgICAgIHNyY19tc2ctPm1zZ19vZmZzZXQgPCBz
aXplb2Yoc3RydWN0IGZmYV9wYXJ0X21zZ19yeHR4KSApDQo+PiArICAgIGlmICggc3JjX21zZy5t
c2dfb2Zmc2V0IDwgc2l6ZW9mKHN0cnVjdCBmZmFfcGFydF9tc2dfcnh0eCkgfHwNCj4+ICsgICAg
ICAgICAgICBzcmNfbXNnLm1zZ19zaXplID09IDAgfHwNCj4+ICsgICAgICAgICAgICBzcmNfbXNn
Lm1zZ19vZmZzZXQgPiBzcmNfY3R4LT5wYWdlX2NvdW50ICogRkZBX1BBR0VfU0laRSB8fA0KPj4g
KyAgICAgICAgICAgIHNyY19tc2cubXNnX3NpemUgPiAoc3JjX2N0eC0+cGFnZV9jb3VudCAqIEZG
QV9QQUdFX1NJWkUgLQ0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3JjX21z
Zy5tc2dfb2Zmc2V0KSApDQo+PiAgICAgew0KPj4gICAgICAgICByZXQgPSBGRkFfUkVUX0lOVkFM
SURfUEFSQU1FVEVSUzsNCj4+IC0gICAgICAgIGdvdG8gb3V0X3VubG9ja190eDsNCj4+ICsgICAg
ICAgIGdvdG8gb3V0Ow0KPj4gICAgIH0NCj4+IA0KPj4gLSAgICByZXQgPSBmZmFfc2ltcGxlX2Nh
bGwoRkZBX01TR19TRU5EMiwNCj4+ICsgICAgaWYgKCBGRkFfSURfSVNfU0VDVVJFKGRzdF9pZCkg
KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICAvKiBNZXNzYWdlIGZvciBhIHNlY3VyZSBwYXJ0aXRp
b24gKi8NCj4+ICsgICAgICAgIGlmICggIWZmYV9md19zdXBwb3J0c19maWQoRkZBX01TR19TRU5E
MikgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIHJldCA9IEZGQV9SRVRfTk9UX1NV
UFBPUlRFRDsNCj4+ICsgICAgICAgICAgICBnb3RvIG91dDsNCj4+ICsgICAgICAgIH0NCj4+ICsN
Cj4+ICsgICAgICAgIHJldCA9IGZmYV9zaW1wbGVfY2FsbChGRkFfTVNHX1NFTkQyLA0KPj4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAoKHVpbnQzMl90KWZmYV9nZXRfdm1faWQoc3JjX2QpKSA8
PCAxNiwgMCwgMCwgMCk7DQo+IA0KPiBQbGVhc2UgYWxpZ24gd2l0aCB0aGUgb3BlbmluZyAnKCcg
YXQgdGhlIHJvdyBhYm92ZS4NCg0KV2lsbCBkby4NCg0KPiANCj4gT3RoZXIgdGhhbiB0aGF0Og0K
PiBSZXZpZXdlZC1ieTogSmVucyBXaWtsYW5kZXIgPGplbnMud2lrbGFuZGVyQGxpbmFyby5vcmc+
DQo+IA0KDQpUaGFua3MNCkJlcnRyYW5kDQoNCj4gQ2hlZXJzLA0KPiBKZW5zDQo+IA0KPj4gKyAg
ICB9DQo+PiArICAgIGVsc2UgaWYgKCBJU19FTkFCTEVEKENPTkZJR19GRkFfVk1fVE9fVk0pICkN
Cj4+ICsgICAgew0KPj4gKyAgICAgICAgLyogTWVzc2FnZSBmb3IgYSBWTSAqLw0KPj4gKyAgICAg
ICAgcmV0ID0gZmZhX21zZ19zZW5kMl92bShkc3RfaWQsIHNyY19jdHgtPnR4LCAmc3JjX21zZyk7
DQo+PiArICAgIH0NCj4+ICsgICAgZWxzZQ0KPj4gKyAgICAgICAgcmV0ID0gRkZBX1JFVF9JTlZB
TElEX1BBUkFNRVRFUlM7DQo+PiANCj4+IC1vdXRfdW5sb2NrX3R4Og0KPj4gK291dDoNCj4+ICAg
ICBzcGluX3VubG9jaygmc3JjX2N0eC0+dHhfbG9jayk7DQo+PiAgICAgcmV0dXJuIHJldDsNCj4+
IH0NCj4+IC0tDQo+PiAyLjQ3LjENCj4+IA0KDQo=


From xen-devel-bounces@lists.xenproject.org Thu May 22 06:51:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 06:51:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992954.1376410 (Exim 4.92)
	(envelope-from )
	id 1uHzlt-0007Pd-O9; Thu, 22 May 2025 06:51:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992954.1376410; Thu, 22 May 2025 06:51: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 1uHzlt-0007PW-Kg; Thu, 22 May 2025 06:51:17 +0000
Received: by outflank-mailman (input) for mailman id 992954;
 Thu, 22 May 2025 06:51:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHzls-0007PQ-KN
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 06:51:16 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 274fd9c4-36d9-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 08:51:14 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-6016d401501so10176009a12.2
 for ; Wed, 21 May 2025 23:51:14 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d501e19sm10401525a12.22.2025.05.21.23.51.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 23:51: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" 
X-Inumbo-ID: 274fd9c4-36d9-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747896674; x=1748501474; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=Bd4mK2u+CfFvys3QXUw7XXnjE55NQfDRpthBE3KeDDE=;
        b=biG6yi5TiSlYFoFeFv5c2pAZ2WkcaHTMDywvbjrN+P7Y+vNz4D8HAhsPt+80y8rduM
         LTcbBLtRCrU4T9Zc0ASThA2bxX62Cd6Cw2CWP0ASjOWxgqRMPwmuwrlJgCctE1ZNmZSr
         o6CDdQ4rI9IyaVy9kBWqgXq+SakI5xy/Aqv6CZW2ZpAkNc4ABz8z3sZpgtXpSqZHnFB6
         27gBp1RKWV6c6oxvHyOoC3O3YdWB39GEOp1Cpcs7PjoZ5xRzoImc5dACk6MrHzZ0wkbo
         8sueviXQbqqFmDKjqzg102mUxVnQTxfoLfXIBUuU+YWHzeohsmQaBM3mEfng3kMXDhQV
         sWSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747896674; x=1748501474;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Bd4mK2u+CfFvys3QXUw7XXnjE55NQfDRpthBE3KeDDE=;
        b=NHBpBkzM11tQMVVy+13hGM7rbPApP327fmfBObmxqQXX+s51guQJjlkkhDjM77st3o
         JnHhYaNyvDrB5OChp2nUWpWpqG5EKNwKYX644zkDqTHdfmkXNOSGa7SnO1ZsXVpV1LIj
         PLO/28ExYFr8cxvCo043FRovCAjpsB4kzIAuhom5Ym6co7vHIc3AQ0avf/BajG27dsNj
         qR7XviTUJKSgPNOyEBdG7LLWqDYaE9ZlDgGdUqV31BFe8LlDpuyEp9P+8F0oUXsQwO9G
         e4zYGMMKMbo9/ttOk+hPj0rJiFo6VcE4E8IxHimtEzXCQbN+bBuOEmA1QlSAAYCKrkIZ
         tvyg==
X-Forwarded-Encrypted: i=1; AJvYcCVuKCHox9WbLO8rq+sZrT7dpGoMZlqwdUaBaa5bKlau1m91guTcftDTPTdvZjJEl6051Qi+aElordM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxaDY468gGg5sf4gEqmsf+RLCmmJ0C9GlV0nWu0VdWwAd/FJ0a0
	V2+VZoUdmqPWF9DS/MieOvpl6hL8GRCtgWabGyNSwXPAu0p2tNVQDxiLiJIoQSKGmA==
X-Gm-Gg: ASbGncsyqMuQ4+Q9p/mmSRBqGf8kIf82UwKA0yjH5KFiwu7TUYrV8qSeItW6i/7n6M/
	n8t9Lc73qq6lb0+qFLLS/xzcsaR6LJRa69gnFoGaA32zKdnG2VzQhcyRhCJRLzYa6Zu7oYvdBt6
	928pm/Egc/PRA7F4BHFi1vPLP6SCMDF9FhFfSkMFnc6glfa9v8AlyHqnpyEVx60tTUZGTfpHmUq
	JSECcJ0PHnsagJTmzaIbOxJmQWqdwI7e3/CScAWT7LvM2XY0nANSASnjY0DVUggtMdWKs3mf1Id
	d8Tlyk/W2PXLqnXn+pi1T5lVP8mbQXoWnyt6XMqQQw5Z00jkcCYb6ESjzt603SSPNx+NXG2A
X-Google-Smtp-Source: AGHT+IHrHFNLJNTvFNdFHpx9TiLdPBXsI3TDI4zyzd1hfPOA/ApNrmXzT8gfyXxPxK8t+wz7HZZx1g==
X-Received: by 2002:a05:6402:50cf:b0:5f7:f55a:e5e1 with SMTP id 4fb4d7f45d1cf-600900e014bmr19760528a12.24.1747896672037;
        Wed, 21 May 2025 23:51:12 -0700 (PDT)
Message-ID: 
Date: Thu, 22 May 2025 08:51:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 15/15] xen/xenpm: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
To: "Penny, Zheng" 
Cc: "Huang, Ray" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-16-Penny.Zheng@amd.com>
 <239e1256-a47d-44e1-a335-2199b880f5d7@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.05.2025 07:59, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich 
>> Sent: Wednesday, April 30, 2025 11:02 PM
>> To: Penny, Zheng 
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Roger Pau Monné ; xen-
>> devel@lists.xenproject.org
>> Subject: Re: [PATCH v4 15/15] xen/xenpm: Adapt SET/GET_CPUFREQ_CPPC
>> xen_sysctl_pm_op for amd-cppc driver
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> +    /* Only allow values if params bit is set. */
>>> +    if ( (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED) &&
>>> +          set_cppc->desired) ||
>>> +         (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM) &&
>>> +          set_cppc->minimum) ||
>>> +         (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM) &&
>>> +          set_cppc->maximum) ||
>>> +         (!(set_cppc->set_params &
>> XEN_SYSCTL_CPPC_SET_ENERGY_PERF) &&
>>> +          set_cppc->energy_perf) )
>>> +        return -EINVAL;
>>> +
>>> +    /* Activity window not supported in MSR */
>>> +    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW )
>>> +        return -EOPNOTSUPP;
>>> +
>>> +    /* Return if there is nothing to do. */
>>> +    if ( set_cppc->set_params == 0 )
>>> +        return 0;
>>> +
>>> +    epp = per_cpu(epp_init, cpu);
>>> +    /*
>>> +     * Apply presets:
>>> +     * XEN_SYSCTL_CPPC_SET_DESIRED reflects whether desired perf is set,
>> which
>>> +     * is also the flag to distiguish between passive mode and active mode.
>>> +     * When it is set, CPPC in passive mode, only
>>> +     * XEN_SYSCTL_CPPC_SET_PRESET_NONE could be chosen, where
>> min_perf =
>>> +     * lowest_nonlinear_perf to ensures performance in P-state range.
>>> +     * when it is not set, CPPC in active mode, three different profile
>>> +     *
>> XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE/PERFORMANCE/BALANC
>> E are provided,
>>> +     * where min_perf = lowest_perf having T-state range of performance.
>>> +     */
>>
>> I fear I'm struggling to parse some of this, making it difficult to suggest possible
>> adjustments (as I can't derive what is meant to be said). Plus where's the term T-
>> state coming from all of the sudden?
>>
> 
> Pasting description on "lowest_perf" and "nonlinear_lowest_perf":
> "
> Lowest Nonlinear Performance is the lowest performance level at which nonlinear power savings are achieved, for example, due to the combined effects of voltage and frequency scaling. Above this threshold, lower performance levels should be generally more energy efficient than higher performance levels. In traditional terms, this represents the P-state range of performance levels.
> 
> Lowest Performance is the absolute lowest performance level of the platform. Selecting a performance level lower than the lowest nonlinear performance level may actually cause an efficiency penalty, but should reduce the instantaneous power consumption of the processor. In traditional terms, this represents the T-state range of performance levels.
> "

And again "T-state". The only T-ish thing I'm aware of is something that
was never implemented in Xen's power management. Hence I fear I continue
to be confused. (And btw, I searched PM vol 2 for the term, and it doesn't
occur there at all.) As a result ...

> IMO, in passive mode, we rely on Xen governor to do performance tuning. And Xen governor is thinking based on P-states. So I take non-linear lowest perf as min_perf
> While in active mode, hardware itself is calculating suitable performance/frequency automatically based on workload, thermal, voltage, and etc. So maybe setting min_perf with lowest perf is a better choice?

...answering this question isn't possible for me (yet).

>>> +        ret = get_amd_cppc_para(policy->cpu,
>>> + &op->u.get_para.u.cppc_para);
>>> +
>>> +    if ( strncmp(op->u.get_para.scaling_driver, XEN_HWP_DRIVER_NAME,
>>> +                 CPUFREQ_NAME_LEN) &&
>>> +         strncmp(op->u.get_para.scaling_driver,
>> XEN_AMD_CPPC_EPP_DRIVER_NAME,
>>> +                 CPUFREQ_NAME_LEN) )
>>>      {
>>>          if ( !(scaling_available_governors =
>>>                 xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) )
>>
>> Isn't it the non-EPP driver which is governor-independent?
>>
> 
> EPP driver is governor-independent, indicating active mode.

I'm confused here as well then: Early in the series, before the EPP driver
is introduced (i.e. as preparation for the non-EPP one) you suppress use
and reporting of the governor. Whereas for the EPP driver while you (also)
don't use the governor as such, you use the choice of governor to determine
the EPP setting. In that sense to me the EPP driver is less governor-
independent than the non-EPP one. That's what I tried to express in my
earlier reply.

Jan

> Hardware itself will automatically calculate and set frequency. User only shall set min_perf, max_perf, and EPP at the beginning.
> EPP is a preference ratio value towards performance over powersave, on the scale of 0-255, 0 as 100% percentage favoring performance, while 255 as 100% percentage favoring powersave
> Non-EPP driver is still relying on Xen governor to do the tuning.
> 
>> Jan



From xen-devel-bounces@lists.xenproject.org Thu May 22 06:55:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 06:55:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992967.1376420 (Exim 4.92)
	(envelope-from )
	id 1uHzqD-00081g-C3; Thu, 22 May 2025 06:55:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992967.1376420; Thu, 22 May 2025 06:55: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 1uHzqD-00081Z-8V; Thu, 22 May 2025 06:55:45 +0000
Received: by outflank-mailman (input) for mailman id 992967;
 Thu, 22 May 2025 06:55:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHzqB-00081T-H4
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 06:55:43 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c6d7c324-36d9-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 08:55:42 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad574992fcaso757010766b.1
 for ; Wed, 21 May 2025 23:55:42 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4d27e8sm1035336566b.174.2025.05.21.23.55.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 21 May 2025 23:55: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" 
X-Inumbo-ID: c6d7c324-36d9-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747896941; x=1748501741; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=osglV1z/xntQZBv5YjuhrlhT7HeQkSny8853lD77kYU=;
        b=C/2PILbq5TU4pyU/7LCx7Cg4lgIgbAKSWPJkFz8Q5BWAEExFG6kas+aN2shUtP9weI
         hlnrD64mI1jpGC/SWEmDbcOJjk9vxbfU+erkH09yZaxjU1HymZnmUtqZFiesWPvb+j8e
         0iMuS3JAbaCXc+GUH9KzwLnqe7Wf+QvFQG9P985eaeZ/k3Y/NIK4+QEVsYE5Vd1lRZAO
         66HPG/XE3fGW/spaV/rJfT8VlfaRE2A9tLhq80tgyaOI/vpIwRYFLdBgXUGRcVBZMOFx
         lbvpP6GOcdv6XohiY5Q+7o9uIv0tz0J36if7xk3TKHGVWiZetrrxae/561/NshpokcdM
         EmwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747896941; x=1748501741;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=osglV1z/xntQZBv5YjuhrlhT7HeQkSny8853lD77kYU=;
        b=pSKoMVHXvWRBMxWebxzuMS/pJbZLkQhuf2B6PG1zGEHD9QkHC7fO2MVvlixefBH5eD
         K3FMvzRWWv5NtmGeWS+dCsLCvx+fW8pJ3U/annP6ovFB46QlsvEaND8NMiYJjqeTfcVo
         FsFJqhM+DsNwlYijYiC3KB3GBThy2/KKveft2sHcuS8FG/LYd6UrlypDMg0eNx0JfpJp
         ulumHSlbPSZHJtFrJ+Ft9YEDZ5MGAGRkh1Ph+kiLiKKSOOMldD5D1Cb48PG5nZ7egwyh
         svnlIIhWtGJAmvFZQ8/iDh5jA4bYfNOTUpsTmBs1OMYU/U3C+Rwv95rqR6m5Uw4z1M/D
         hXxg==
X-Forwarded-Encrypted: i=1; AJvYcCUvLSSMTVXGDcSz1pb8V4kpoDqzvzY0CXqBjN6JqfBH38CCWbqRwu/BwzrmmMtYPpqtYUIy8lcl934=@lists.xenproject.org
X-Gm-Message-State: AOJu0YygbJntrMTQI4nAM1XMrRelZsqNEiG34j73ae41qyzpqE7sPaP1
	4A0fWHtEzz4yBYiUewpvKwh3iMyCYAegzyqn6hP9svMkqaxZHMGZcV3TtCRq6gFuRw==
X-Gm-Gg: ASbGncsO2zCqDQwGa/0JktMEhg0T9qhai58bI8flOCL0kTspjL/wqySsCWVL1pShnB+
	kettO14o/mDI8bAtJxeCn/vUrlPb0E7fFDVSMsqRHDpgk2qO0OTJFopArc+esroyAlLsT+lNQ7T
	XTXzorJxtwhR5y/900UmGoOcnUIRS6aqZlfTiVOerKaWoWwMJorI5I1iHpZzPN2vxcP70MEQfEa
	VPh47W0Xcm4EHQL0l/uqY9o85kAfnTLFkMQTOISRcZL8Y3kP+55+SyBGG8lAGTthY+h20yhegdV
	wCEtFKcQVNXMjj/PNpvIS0zZM69fFsCNVcmhWt5s6o6MpLx5aj5iNQVVjUTj/g==
X-Google-Smtp-Source: AGHT+IGVkUbAlS9lEJ+XZw8jgU+7FnmxHaBQhf1u5qgBeqH/zjmkazBWlG+RIMpBoeh51rPz2hKKmA==
X-Received: by 2002:a17:907:60cd:b0:ad5:a203:b6ba with SMTP id a640c23a62f3a-ad5a203b86dmr678213166b.43.1747896941534;
        Wed, 21 May 2025 23:55:41 -0700 (PDT)
Message-ID: <8ac2d7fc-214b-40dd-a5d2-6e1dc8c0e4ad@suse.com>
Date: Thu, 22 May 2025 08:55:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 03/12] x86/hyperlaunch: initial support for hyperlaunch
 device tree
To: Alejandro Vallejo 
Cc: "Daniel P. Smith" ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini ,
 Jason Andryuk , Denis Mukhin ,
 xen-devel@lists.xenproject.org
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-4-agarciav@amd.com>
 <6f821e28-b182-4d27-b2db-e3be80910c12@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 19:24, Alejandro Vallejo wrote:
> On Wed May 21, 2025 at 5:00 PM CEST, Jan Beulich wrote:
>> On 29.04.2025 14:36, Alejandro Vallejo wrote:
>>> --- a/xen/common/domain-builder/fdt.c
>>> +++ b/xen/common/domain-builder/fdt.c
>>> @@ -13,6 +13,36 @@
>>>  
>>>  #include "fdt.h"
>>>  
>>> +static int __init find_hyperlaunch_node(const void *fdt)
>>> +{
>>> +    int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
>>> +
>>> +    if ( hv_node >= 0 )
>>> +    {
>>> +        /* Anything other than zero indicates no match */
>>> +        if ( fdt_node_check_compatible(fdt, hv_node, "hypervisor,xen") )
>>> +            return -ENODATA;
>>> +
>>> +        return hv_node;
>>> +    }
>>> +    else
>>
>> Please can such unnecessary (and potentially misleading) "else" be omitted?
> 
> Not sure how it could be misleading,

For context, just briefly looking at such a construct may leave one with
the (wrong) impression that both branches of the conditional can fall through
to subsequent code. This may be less of an issue as long as both sides are
reasonably short, but then it is imo better to avoid the pattern altogether.

Jan

> but...
> 
>> As ...
>>
>>> +    {
>>> +        /* Look for dom0less config */
>>> +        int node, chosen_node = fdt_path_offset(fdt, "/chosen");
>>
>> ... these will need to move to function scope then, one of the two may want
>> folding with "hv_node" above.
> 
> ... there is indeed a more compact form the function could take. Noted.
> 
> Cheers,
> Alejandro



From xen-devel-bounces@lists.xenproject.org Thu May 22 07:02:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:02:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992974.1376431 (Exim 4.92)
	(envelope-from )
	id 1uHzwB-0001QT-0Q; Thu, 22 May 2025 07:01:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992974.1376431; Thu, 22 May 2025 07:01: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 1uHzwA-0001QM-Sf; Thu, 22 May 2025 07:01:54 +0000
Received: by outflank-mailman (input) for mailman id 992974;
 Thu, 22 May 2025 07:01:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uHzw9-0001QG-VL
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:01:53 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a3d36789-36da-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 09:01:53 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad5394be625so436954466b.2
 for ; Thu, 22 May 2025 00:01:52 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4466e2sm1041436666b.93.2025.05.22.00.01.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 00:01:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a3d36789-36da-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747897312; x=1748502112; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=5ZnCMNOK19g2beZgIpWstHoa0tVgsbyzm96lOgGrbXI=;
        b=FG6z1BJcvhmblUKq8Q7J/y40/yE2DFl6anp6qnkitloEAK63NwRVq6aylpUeUGLgTM
         g2J9QhyiKZ8dvcxHgfcz9ZTCfBhhVZgGkZw5wuPGRzDdNVNdAYSzc4ICeL2fPfY4xqoZ
         kwwTab/mZGp6Q953234RKDKrFiUxBNMt+YHU1YE/hgSyxmEzf3S4DSwgiLlVgR2gSAA/
         RcnR6fsoWXSEJK6AtQMyUr381HPZG5Tg/fxcI1+Mmn3JMYMMMQauAf+KZxiXvlruVSW5
         nP4e2LXRELPxNdsPAGg4DSER2zKvZXNpVqah2IZ0RIFr+N3/Gg56VH9L2zkwrWk4+EYx
         avbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747897312; x=1748502112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=5ZnCMNOK19g2beZgIpWstHoa0tVgsbyzm96lOgGrbXI=;
        b=NvpAHy+ItVMfeASb9vVtfvuVY1PHWMHmnTgEKKj3GI35iovrp0GhwmStbkVmfHZX3z
         SlSNRSzvqkU0hfIMIqD2mQ3suHjgez2rpZmVko7TQGOdmrAj+OujycIZ5iAqNoqS3P7u
         OadS+urtjaYN0sagQTblmTvw/5eaDJEQBQNUaNz0HDA2R0C0YsvF9fdy6Sy43MoRXykN
         /nG7zz+3nv6ivjFuqmLlBaTIZojHTpcQs7iYN0VtNv1U3OJHEwRLqG6FulVUqi5REwh0
         rI/9Y8j2PMIztVXM7SROEbd8VhJEV97faFlKkxAPZgKyQsVDtmUeOqeefytDVVP31hH0
         f+HA==
X-Forwarded-Encrypted: i=1; AJvYcCWqAJxiDr6nBLaxhfKQQv+4/YU++F77RbxSeIiekWIhqyl5pgJGKYNxOIE7uMhluSCDJv8+Cao2HAA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyH+gnaMRU/Of19XHbxX9/rPDiSTsDJma5d4WZpzRDyX07sUcpX
	HmAn32YJIJv8yE9Q4AfYEDYggV9fBTWnQB9JRoXWaZcq5YrjYzrCc3wcixYolOtVJw==
X-Gm-Gg: ASbGnctTS3MRK8sfrdIdkFqDjfPF5kf2PgtaVYDgrCsfwJHg1FzVtiDNbTc5L8nIFDL
	/t90o1/dg0CmItTidpGldbmY4NkNP7NXkFkr7XNTDNyzn7VsUNh0dvGssmD79f+udRkiX8Kf8fI
	t6R0DMb2Xrolz4GeeAKInQsbFY+/h3b0FFkPrJWTlpBuGMNCaUpt6eUGESaIakl63fbh/vOQbPt
	CsEhp/268+nd8oz0bQZRGDf2yWbou+M5dAZoMv18bQePH5HYd9Gg8/aCCIXTBtVnsv1vmyuneyw
	gavtmAHGV3NKZKJeb1K4ddMq8bpLA0Wh5F5ONVQJ53oaNlisjPXfML6PoRPMog==
X-Google-Smtp-Source: AGHT+IEQ/74AfjRJ6TW0pew9ePplx5Dv9HINyckz/rk26fCEm3x0bI/ZN0/cnbUvYLpVS2SlQsRX5g==
X-Received: by 2002:a17:906:2515:b0:ad5:4822:b7a2 with SMTP id a640c23a62f3a-ad54822c4c7mr1518313166b.45.1747897312313;
        Thu, 22 May 2025 00:01:52 -0700 (PDT)
Message-ID: <3b203f39-756b-4fb3-b0e5-0f790701c23a@suse.com>
Date: Thu, 22 May 2025 09:01:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 3/3] xen/domain: introduce CONFIG_MAX_DOMID
To: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20250521000024.2944685-1-dmukhin@ford.com>
 <20250521000024.2944685-4-dmukhin@ford.com>
 <54945bd5-333e-4ffd-8ff1-bb89d22c7ef4@suse.com> 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.05.2025 02:09, dmkhn@proton.me wrote:
> On Wed, May 21, 2025 at 09:31:34AM +0200, Jan Beulich wrote:
>> On 21.05.2025 02:00, dmkhn@proton.me wrote:
>>> --- a/xen/arch/arm/tee/ffa.c
>>> +++ b/xen/arch/arm/tee/ffa.c
>>> @@ -331,10 +331,9 @@ static int ffa_domain_init(struct domain *d)
>>>       * reserved for the hypervisor and we only support secure endpoints using
>>>       * FF-A IDs with BIT 15 set to 1 so make sure those are not used by Xen.
>>>       */
>>> -    BUILD_BUG_ON(DOMID_FIRST_RESERVED >= UINT16_MAX);
>>
>> Why's this being moved to common code? It certainly may have a purpose here
>> (which I'm simply unaware of); I don't see what purpose it has in common
>> code.
> 
> My understanding having DOMID_FIRST_RESERVED compile-time checks in one place
> is good for testability: the check in question also applies to x86.
> 
> I will drop that hunk.

And also the other one, unless you can explain what exactly you're checking.
The connection between DOMID_FIRST_RESERVED and UINT16_MAX is at best
indirect, through domid_t. Yet if domid_t was widened (possible in principle,
but breaking the ABI) that check would end up wrong without the compiler
noticing (unless DOMID_FIRST_RESERVED was also bumped, which however is an
independent thing).

>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -576,4 +576,11 @@ config BUDDY_ALLOCATOR_SIZE
>>>  	  Amount of memory reserved for the buddy allocator to serve Xen heap,
>>>  	  working alongside the colored one.
>>>
>>> +config MAX_DOMID
>>> +	int "Maximum number of user domains"
>>> +	range 1 32752
>>> +	default 32752
>>> +	help
>>> +	  Specifies the maximum number of domains a user can create.
>>
>> My prior comment remains: The description and help needs to be accurate, in
>> order to not cause any confusion. In a true dom0less environment I'm not
>> sure the "user" can create any domains (post boot, that is). And when there
>> is Dom0 (or late hwdom), the number specified already isn't the number of
>> domains one can create (again, post boot, which is how I understand "user
>> domains"). If someone picked 1 as the value here, it's unclear to me how
>> late hwdom or dom0less would work in the first place.
> 
> Do you think something like the following will be more accurate?
> 
>     config MAX_DOMID
>        int "Maximum number of domains"
>        range 1 32752
>        default 32752
>        help
>          Specifies the maximum number of domains: dom0 or late hwdom,
>          predefined domains, post-boot domains, excluding Xen system domains
>          (domid >= DOMID_FIRST_RESERVED).

Especially the mention of DOMID_FIRST_RESERVED is too much of an implementation
detail here, imo. Beyond that - maybe, but I'm not overly happy this way either.

As an aside - MAX_DOMID and "Maximum number of domains" are conflicting
with one another, too: Do you mean "maximum ID" or "maximum number of"? The two
are different by 1.

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 07:12:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:12:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.992982.1376440 (Exim 4.92)
	(envelope-from )
	id 1uI06P-0003IB-St; Thu, 22 May 2025 07:12:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 992982.1376440; Thu, 22 May 2025 07: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 1uI06P-0003I4-Q4; Thu, 22 May 2025 07:12:29 +0000
Received: by outflank-mailman (input) for mailman id 992982;
 Thu, 22 May 2025 07:12:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI06P-0003Hy-4p
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:12:29 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1e3cac05-36dc-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 09:12:27 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a363ccac20so5027307f8f.2
 for ; Thu, 22 May 2025 00:12:27 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca5beccsm22350199f8f.36.2025.05.22.00.12.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 00:12: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" 
X-Inumbo-ID: 1e3cac05-36dc-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747897947; x=1748502747; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=7oYMkcBPqatPPgNd3FRfOGxTWtsxbjr0KC1Q8451qmQ=;
        b=Of5yEHL3bCknBWZl53vNyrNnpbU/iYlEi43AvwPknCbnVzDmNl/YaKpDM4EAPUenbC
         Dwo3S2BcHhjYY07gbtuNtzj5zi01bFZzLgjQm7g4abBOurPrXXMzjv49O+DJwn/owq9Y
         1bGbyKk0ISRolyXKkjCNiJHpsSI7r754JEBV8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747897947; x=1748502747;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7oYMkcBPqatPPgNd3FRfOGxTWtsxbjr0KC1Q8451qmQ=;
        b=Yvs/IUHDuObJ8oCZtyIaBuWKNdcY5gAkf4QWhM2KNzibpi9WzgmwfeJiCgfaRCowsi
         kaZrT+FL9cPlnzIByrQvSzPx0utDaH5nUtiHnu39NxKD291AAQKODpElF9agOV/LBlRw
         KzA2o6xy8TsuH14DckPY/0FJz6ui4irG+Vg6WCqRS+ATu+PEUPAtCWi/jGGYMCVn9dWP
         5DVaL0kjnDTnB47s/NGX7nFaw4ak2db/13d4OfnN5j7YNjUdtcKuDNojxL3G0QpSKbzV
         ar86/m+YijsQpdIyDTQZg47gjg9ZQ6d6fagz7ECuBvJMhuuZWeCJ7oM5OoQeCscK/6Cm
         4x9A==
X-Forwarded-Encrypted: i=1; AJvYcCUm11kMjyUWQ/7eGv/F3IGUTIjhHJpoJoA9UbtQhyRegz6hDE/9aEXTK3PnraXqnkVnLFBt2IYMwl0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw63BSy5JVNV7vIGfieQS6NUBKIovYYEriKPCmUsjB47Do4Tdrj
	aY6ljXa3Qjbjt3gVmnBv0DKO6vVb3k16lur7Y+oSI/qGccoMAHy26HzUJQJP/1JOncA=
X-Gm-Gg: ASbGnctNIElJpSwEHSl+hfzsRSv8WpIykJdRjGIE20oR95wcGgswpp38Tf8eTB3vP0z
	G5iuW2Yn6ZpuX+KnN+tRDwpPsSU4rwR1eBxtRBM93+SL77w8m5E4uRPHzK83SKD75Aq9ZOqSnTJ
	PSNW1Y4rhdL6tVmJSbJKaxgKdUf1oOhMbpZfkM8jpBeMrwDjHXIoqPaJH0wW5oXtqE+6equcHwC
	P1mjdq54sa4pTdYoEskyGA21Di60WtSXk1WgEG+eLjVq2alkslrf6IdlRZZtJpk7exAKixQKuOE
	/hu/sWVfsK1ZLZjNdUHHbo/i0CWX/hRpyS9s7sORLSQJRCsC3OOfoTL+FAHKnQaBHzKFs/h/dKe
	PaQ2Yp/ZrC8pLcgoIpIc=
X-Google-Smtp-Source: AGHT+IG+yDvMAiBIof1krR9Iosx6MaW73fpo3WlTFIcJvwRwYOG5ZUv8HOk1iA1SGLQGuV5oHKjONA==
X-Received: by 2002:a05:6000:2385:b0:3a3:4ba4:f3cd with SMTP id ffacd0b85a97d-3a35c821e38mr19214329f8f.1.1747897947335;
        Thu, 22 May 2025 00:12:27 -0700 (PDT)
Date: Thu, 22 May 2025 09:12:25 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: Jan Beulich ,
	"xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Message-ID: 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-10-Jiqian.Chen@amd.com>
 <8d89f644-4ded-4490-ad23-518563d230d2@suse.com>
 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, May 22, 2025 at 02:21:16AM +0000, Chen, Jiqian wrote:
> On 2025/5/21 19:23, Roger Pau Monné wrote:
> > On Wed, May 21, 2025 at 07:00:37AM +0000, Chen, Jiqian wrote:
> >> On 2025/5/20 17:43, Roger Pau Monné wrote:
> >>> On Tue, May 20, 2025 at 11:14:27AM +0200, Jan Beulich wrote:
> >>>> On 20.05.2025 11:09, Roger Pau Monné wrote:
> >>>>> On Tue, May 20, 2025 at 08:40:28AM +0200, Jan Beulich wrote:
> >>>>>> On 09.05.2025 11:05, Jiqian Chen wrote:
> >>>>>>> When init_msi() fails, the previous new changes will hide MSI
> >>>>>>> capability, it can't rely on vpci_deassign_device() to remove
> >>>>>>> all MSI related resources anymore, those resources must be
> >>>>>>> removed in cleanup function of MSI.
> >>>>>>
> >>>>>> That's because vpci_deassign_device() simply isn't called anymore?
> >>>>>> Could do with wording along these lines then. But (also applicable
> >>>>>> to the previous patch) - doesn't this need to come earlier? And is
> >>>>>> it sufficient to simply remove the register intercepts? Don't you
> >>>>>> need to put in place ones dropping all writes and making all reads
> >>>>>> return either 0 or ~0 (covering in particular Dom0, while for DomU-s
> >>>>>> this may already be the case by default behavior)?
> >>>>>
> >>>>> For domUs this is already the default behavior.
> >>>>>
> >>>>> For dom0 I think it should be enough to hide the capability from the
> >>>>> linked list, but not hide all the capability related
> >>>>> registers.  IMO a well behaved dom0 won't try to access capabilities
> >>>>> disconnected from the linked list,
> >>>>
> >>>> Just that I've seen drivers knowing where their device has certain
> >>>> capabilities, thus not bothering to look up the respective
> >>>> capability.
> >>>
> >>> OK, so let's make the control register read-only in case of failure.
> >>>
> >>> If MSI(-X) is already enabled we should also make the entries
> >>> read-only, and while that's not very complicated for MSI, it does get
> >>> more convoluted for MSI-X.  I'm fine with just making the control
> >>> register read-only for the time being.
> >> If I understand correctly, I need to avoid control register being removed and set the write hook of control register to be vpci_ignored_write and avoid freeing vpci->msi?
> >>
> >> "
> >>      if ( !msi_pos || !vpci->msi )
> >>          return;
> >>
> >> +    spin_lock(&vpci->lock);
> >> +    control = vpci_get_register(vpci, msi_control_reg(msi_pos), 2);
> >> +    if ( control )
> >> +        control->write = vpci_ignored_write;
> >> +    spin_unlock(&vpci->lock);
> >> +
> >>      if ( vpci->msi->masking )
> >>          end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
> >>      else
> >>          end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
> >>
> >> -    size = end - msi_control_reg(msi_pos);
> >> +    start = msi_control_reg(msi_pos) + 2;
> >> +    size = end - start;
> >>
> >> -    vpci_remove_registers(vpci, msi_control_reg(msi_pos), size);
> >> -    XFREE(vpci->msi);
> >> +    vpci_remove_registers(vpci, start, size);
> > 
> > I think you want to first purge all the MSI range, and then add the
> > control register, also you want to keep the XFREE(), and set the
> > register as:
> Understood.
> 
> > 
> > vpci_add_register(vpci, vpci_hw_read16, NULL, msi_control_reg(msi_pos),
> >                   2, NULL);
> And one more question, how do I process return value of vpci_add_register since definition of cleanup hook is "void"?
> Print a error message if fail?

Well, we should consider the cleanup function returning an error code.
vpci_remove_registers() can also fail, and the error is currently
ignored.  Both cases should result in failing to assign the device to
the domain IMO.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 22 07:19:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:19:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993004.1376450 (Exim 4.92)
	(envelope-from )
	id 1uI0Ci-0003tc-I4; Thu, 22 May 2025 07:19:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993004.1376450; Thu, 22 May 2025 07:19: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 1uI0Ci-0003tT-ER; Thu, 22 May 2025 07:19:00 +0000
Received: by outflank-mailman (input) for mailman id 993004;
 Thu, 22 May 2025 07:18:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI0Ch-0003tN-IP
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:18:59 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 07376f60-36dd-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 09:18:58 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-601a6e2e93cso307849a12.1
 for ; Thu, 22 May 2025 00:18:58 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac336d5sm10164316a12.54.2025.05.22.00.18.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 00:18: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" 
X-Inumbo-ID: 07376f60-36dd-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747898338; x=1748503138; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=ZHg8jAWMsjn/TRzGwfRbrlJdxdRRRX7STo4YvNJ5bz4=;
        b=ScOeXgG5z/K1dG82hs17Hh7dzpDozxk5K5NmFXAm5f9ucoCzfGfDp57bu3lucLkifX
         rljpV0cRUawVZ/mkOurhv/8IIe3zJ2oxcUEMiVHOXMcANwjbFUqPYLMFXreqVW6P6oaY
         w4YIk2NqoiHq5eNMyouG2v0GtLS8fehfRPvtFpezjEm1MoXoX1rZQ2wS3I0TeGA9mL5T
         OFQBza24C7AMbgb0BWpzMvj5PIdpE6bPY3ON7wGgeBZWBP8WXqxrzBvfCyPxnDlIITzK
         lSqyc/+FpDksVzfxI9yxzNr4dI7a6Mv+zEWLD0/Iv2KRcctNe5CPuZ9JAmCJycPdLoiy
         DKsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747898338; x=1748503138;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ZHg8jAWMsjn/TRzGwfRbrlJdxdRRRX7STo4YvNJ5bz4=;
        b=SvedKNMBlpOHP3Lr3448RbW5KHgYTeZvcEgvZN6tBuqjmr77qWdNfYP03xZetV30yT
         wEkLaCFZRXGpbjOUPsb7iU4iqu2tGY4GyKTPtWs7xU9nsSaR+DLDwNLzQ4CLRq5dlYmI
         39/sse/RpT/vLb/0LbcFy9aX2NDbkFFoUZ6lkTT0461w/c23n5weloVZ2QbzaaPsdUPq
         RoDTBo5Gn5w4+glkm4/Sy0hcT4x93rUe01mr5kZckiNS/jO+RuMhlLhaWwwPlYi5wDfQ
         7+L1nzhk28YdqnE4HmPr9bwzRbFkp6ietgfjX6UqxUDzJIoUzPiLPq2iQsIqNP7zG13g
         Nqvg==
X-Forwarded-Encrypted: i=1; AJvYcCWiwq4D73Fz7Q7oxxsk+aeQ106sicvGRqaq68bjymsBIPpd+3vvw8zS++o7ti31Z2hekjB73NuiU0M=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx+38EYd08VUG0XStdvx8iljaGe6XB6HMIj1TZPxbW+3XU9C07w
	Qkx8BEOaLqR2DftpyohYwGHy8ZgH850IRZe0VNNmQuUg0N5SQW4u9g7+rqbXZVMj2Q==
X-Gm-Gg: ASbGncvzeYnN4wVJ7Qrw2z4O8V6HLVoWjV6ZX43hdKTXTzpfVTuMIA1DI5ur+JmFBdu
	2cSwm5vKl66cC2Sx0dqHPtMYPPl7je7xKzzxeZpedfJxhxEcJFfOXhJA3ABpoVbapfayp7M8s4p
	U50FvtHgMw/Z77lsKaVa834Jsrib9M0TOWLEIPlV8/ipWtPt4IIG+l8BxbmTyVXzYVTH13nFMvR
	GO8KCI8bRsN5LiKNhveAcqu1PKI8Jq9T79vpg8l+nNQc2di6s3dsRV1GaCE3a6PnQRo5wFYnCdR
	j/tfEQBOg6bbjeW10zL0+GDUi7808c7nnQvUMFC2GALVTsZLOaf9QLraL7PqoA==
X-Google-Smtp-Source: AGHT+IHbEXoqV52g6auTF/erLKPQy6wOtHwLeKZIVhzZ/zB5lzS28WKiH9+DF8XT84vgGOb0L5H3Jg==
X-Received: by 2002:a50:a446:0:b0:601:470b:6d47 with SMTP id 4fb4d7f45d1cf-601470b6e9emr15326667a12.1.1747898338092;
        Thu, 22 May 2025 00:18:58 -0700 (PDT)
Message-ID: <8a39ec76-f050-488e-bf4c-ba378fae7275@suse.com>
Date: Thu, 22 May 2025 09:18:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/boot: attempt to print trace and panic on AP
 bring up stall
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250521165504.89885-1-roger.pau@citrix.com>
 <20250521165504.89885-3-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250521165504.89885-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 18:55, Roger Pau Monne wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -714,13 +714,15 @@ static cpumask_t show_state_mask;
>  static bool opt_show_all;
>  boolean_param("async-show-all", opt_show_all);
>  
> +static bool force_show_all;
> +
>  static int cf_check nmi_show_execution_state(
>      const struct cpu_user_regs *regs, int cpu)
>  {
>      if ( !cpumask_test_cpu(cpu, &show_state_mask) )
>          return 0;
>  
> -    if ( opt_show_all )
> +    if ( opt_show_all || force_show_all )
>          show_execution_state(regs);
>      else if ( guest_mode(regs) )
>          printk(XENLOG_ERR "CPU%d\t%pv\t%04x:%p in guest\n",
> @@ -734,6 +736,40 @@ static int cf_check nmi_show_execution_state(
>      return 1;
>  }
>  
> +void show_execution_state_nmi(const cpumask_t *mask, bool show_all)
> +{
> +    unsigned int msecs, pending;
> +
> +    force_show_all = show_all;

Both forms of the call can, aiui, in principle race with one another.
I think you want to avoid setting the static to false once it was set
to true.

Furthermore, as long as all calls here with the 2nd argument being
true are followed by panic() or alike, I see no reason why you couldn't
simply re-use opt_show_all, setting that one to true. (Or else there
would then also be some resetting of the new static.)

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 07:22:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:22:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993012.1376460 (Exim 4.92)
	(envelope-from )
	id 1uI0Fz-0005j9-0N; Thu, 22 May 2025 07:22:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993012.1376460; Thu, 22 May 2025 07: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 1uI0Fy-0005j2-Sn; Thu, 22 May 2025 07:22:22 +0000
Received: by outflank-mailman (input) for mailman id 993012;
 Thu, 22 May 2025 07:22:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI0Fx-0005iw-Mh
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:22:21 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7ef27c9c-36dd-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 09:22:19 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-601956fa3beso8519019a12.0
 for ; Thu, 22 May 2025 00:22:19 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac32b53sm10167046a12.64.2025.05.22.00.22.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 00:22: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" 
X-Inumbo-ID: 7ef27c9c-36dd-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747898539; x=1748503339; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=OmW4i0A11ZtP8YRdQQ9hPjUiVy3nQCRBWGZIN2e/oes=;
        b=e3hyD7bDzzVtDR4CTV4wconrb3TEH3AOq6wCkpdIaxWLX5kSE5q3kxeQSNpFg0iyiN
         ADpyShuwdajzINUrNC8sOjWFat2cfhZrIZWon/MkknTKu6yLFXyMh41DigB0S0ECcfxa
         WHCbC+pifTrDAf5Pr2ydvHDHFhqRftBGt9SCP9lslofJu8D5CP29yzXaiCl5DYPurFj9
         w3ddwmJAhyqPTkvtP2y93vqXvb1qafXoHD6b2WX5bNa/+sgCjYEe0WSKurphX0PRYt6d
         hy9mF9wH4rFJDUoHXtmxLpc52hnML6iN7kWrTPhSmjMq6baoVHyI8TktW4eogs5LAA2j
         5cfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747898539; x=1748503339;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=OmW4i0A11ZtP8YRdQQ9hPjUiVy3nQCRBWGZIN2e/oes=;
        b=rF+Jp8AJfMDqPudMQmEqs2xE7LTO0cJ3sHxhqVowQdKW3p4P7sWmcFWGMly/zlk880
         ryIr7Xh+axVGLgCII7qYdJP4M49yRWXZ/LPF4MhXyZTnxxwdjnm16ns7Pu0amFzc6VyF
         IGTQOzJFJw770OPFnwAVMmiNcFWQ2edOlouT7lbwIgjoP2AdO2fmPldKrKpLdNfvFrtv
         fz5pZf+MLFRcQkU5ymkESKzZ0KoK865Dtq0hpK7NekFNMTur1aCNbJKeOsvNrJpCe0aX
         +ufSIRi9P4TvBb2+MF68U9H9oYu6iUiPywv6QhitC4iUbAsKe6NB1+89ih+gRQnpUr2G
         sZ6Q==
X-Forwarded-Encrypted: i=1; AJvYcCWXLtxe3Osg5a98Be7i3xw93IlM0wrrxcA6VVoAdwSv/v+v5Dn0eLGOilhUtFjxa87WVnHPSO/UH5A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzcPknQPHRo3useHGl/zmmPh7LfeZJDu19u0tpaY1l9r5IOYWQJ
	54g9y2RFxmI/8PGbvfWSf6nKhrQ/mIBE2nTyrkdqLKYde/BtVJGkUdqz3tDkPuiviA==
X-Gm-Gg: ASbGncu6dejjTagt7eFp8bmkQ1Yl4XqqbYSLPaYr0WBp0E+s4O76NzoPK68WTV1sIT4
	TRC7cUSQUYOAJyFc79HsXl4X/DIpWlmoNy1uWcsldtYEiPdc3N1kBwbodjPPCPkjt+jBz1DZ7Zb
	h+bjd83FfYCwzhYBgL3JoO0+k7iKEX6YqPQa/cYx0dz7lvuL/uHIStf8ynycmuSO6ywsHQQ6FRh
	GK6I133GX/0q/fJdLbklc/K6jN0Q1Two+H8v+a5H4m/2J423Xbgb/ItVT2ChUhZvscN/H5wgGrV
	P676RcwyyQmB6b8mR9KYCQNUZevBenirLDCakDzSc6BgYgIOrn5NsgA8hgib7A==
X-Google-Smtp-Source: AGHT+IF2eVAltQ6MnaXr3ehgVaziCVlJPjtxpWoHEfcQ37yiilP3dFvzex3H06WXrC0R4R+gmxJ4rg==
X-Received: by 2002:a05:6402:1e8c:b0:602:1b8b:292a with SMTP id 4fb4d7f45d1cf-6021b8b2cb2mr7283262a12.2.1747898538921;
        Thu, 22 May 2025 00:22:18 -0700 (PDT)
Message-ID: <0554d84f-41bc-45a5-9c46-c850e0316d87@suse.com>
Date: Thu, 22 May 2025 09:22:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 01/14] xen/riscv: introduce smp_prepare_boot_cpu()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <33f3e8378631f6b73148402bbb0b6bb3c64bf754.1747843009.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <33f3e8378631f6b73148402bbb0b6bb3c64bf754.1747843009.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> Initialize cpu_{possible, online}_map by using smp_prepare_boot_cpu().
> 
> Drop DEFINE_PER_CPU(unsigned int, cpu_id) from stubs.c as this variable isn't
> expected to be used in RISC-V at all.
> 
> Move declaration of cpu_{possible,online}_map from stubs.c to smpboot.c
> as now smpboot.c is now introduced.
> Other defintions keep in stubs.c as they are not initialized and not needed, at
> the moment.
> 
> Drop cpu_present_map as it is enough to have cpu_possible_map. Also, ask
> linker to provide symbol for cpu_present_map as common code references it.
> 
> Move call of set_processor_id(0) to smp_prepare_boot_cpu().
> 
> Signed-off-by: Oleksii Kurochko 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu May 22 07:26:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:26:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993023.1376470 (Exim 4.92)
	(envelope-from )
	id 1uI0Jd-0006KM-Ha; Thu, 22 May 2025 07:26:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993023.1376470; Thu, 22 May 2025 07:26: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 1uI0Jd-0006KF-Ey; Thu, 22 May 2025 07:26:09 +0000
Received: by outflank-mailman (input) for mailman id 993023;
 Thu, 22 May 2025 07:26:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI0Jc-0006K9-0t
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:26:08 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 05ff9608-36de-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 09:26:06 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-601dbd75b74so6862873a12.1
 for ; Thu, 22 May 2025 00:26:06 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005a6e637dsm10291631a12.43.2025.05.22.00.26.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 00:26: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" 
X-Inumbo-ID: 05ff9608-36de-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747898765; x=1748503565; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=fbZM+QuaQvX+gygVGE/ecAx0nAKkgKv/oaZIxVbXDqQ=;
        b=IOzEvGzPKWSRa/kY7iPxUrPMrdk8c/FaQuxyWTjjUfhAxfDtL0wsrS6IzMqoOC7rMi
         QW15xC5Uk+U/fbVIKDkS8dtVllswdcSiec3jKYoAV1WQOwkwo0qlQjIsZnFWV3MPNkzX
         QsKS2v58FzKtOJnUaxnTOY7r6DpdHgZPvD1dGPiCMjk/0tMewUtFsViVJjWxghyQM8zJ
         VeNpBoQa1dHQ7A3zEu+wgUxT9o3G/imbQKOH8FzSM/T2+N+09XH7m4W96QJEX6kvEsZT
         6ozTnom2KQMvug33CXd5vRzoyllLmVqNV7bgw8tWah9ZeSzKnBsKExYl2v3mkz9jMAJk
         kS3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747898765; x=1748503565;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=fbZM+QuaQvX+gygVGE/ecAx0nAKkgKv/oaZIxVbXDqQ=;
        b=OvJgNdNnx1ZcdPCnZVncaLpao6NPs/EtqNnahp6RKQH3q4QHCRXFn/FV9zSAZ5KPCM
         Y/s0qZNIq99W/vnrxag7gPZwJQmuppmhsX0tQJctK3XVveV9aPYvYP8Lb6zotbiEm1/D
         ApiAek6rZy85CEz5fehs56UHb0tcFSIOJ3aSCq2zRQZR8WJ05il5dTGn0dTTMxtBZG4H
         Q5TVy/Ti+S3m8aPK54NBb00ZtIYtNGr5oztrue6loDSiN64rohyHP26h1xKJQAMy4+hp
         R2Ad6V1LKOtM6k0HGcfetqYc/okDu5Ybn8YY17DJDghqArz/t7lEENbjQ6mmDkf5WfgA
         v4OQ==
X-Forwarded-Encrypted: i=1; AJvYcCVROfKeZ8CuVfmEMRHvUAT59KOcqvwzWcKb4nBA3kmORD7c6keRYTdGFST38fTfUqAf2mA9prVFA28=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxYbAb1XaKTFLAQATKICB21a6giWEGbUDQzFQ58m7t9LhYjmQR+
	92YC7+s19f8FCvYcFwptOLprteV4fPTK7I2ByOrQuiCTcnL6FA8d1B2WRayYEfc/0w==
X-Gm-Gg: ASbGnctAHLLotuRcipUeTeDlOBjX1JYo2Z944+I3QoUKFnqz6x6A7CQWIGQoljX6tnW
	P8FrEb/nmmZhuPSu7QPJigwtPw2Y5+m8nDh7U12sNLcpQWpZ1zNaungbGxbSIJD3sGzCIebE0k2
	+E6m0ofyKB3bAESOfR4bul5wIK5RG4t5RJSMuqMXpsLNeJCQ3FWrJXlZrTJGDLYfVl5oGgt+SU1
	sNnCEv5THu2a/xWR5Y8c51kSBH2P7sTlCm1NXLg4nHVW+zc3FO0TntytMdMaF199lGA5cquxQBt
	kR1cndcvOhI9ggxfqJc9FnSomkpxrSu+lxZpOtTv7RJpkdNtAFkqKqgiNHSyZA==
X-Google-Smtp-Source: AGHT+IFVxBhZuXZ1CI0vYz9ek/esarR3ttsOcco8NqT8KgK2yzY0s88AarG/NKhcgjaNwdLM6gqWnA==
X-Received: by 2002:a05:6402:d74:b0:5fd:c426:9d17 with SMTP id 4fb4d7f45d1cf-60119d2305emr17422949a12.34.1747898765517;
        Thu, 22 May 2025 00:26:05 -0700 (PDT)
Message-ID: <3eaba65b-5b36-433c-afbc-ed17886916a9@suse.com>
Date: Thu, 22 May 2025 09:26:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/14] xen/riscv: introduce support of Svpbmt extension
 and make it mandatory
To: Oleksii Kurochko 
Cc: Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , xen-devel@lists.xenproject.org
References: 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> Svpbmt extension is necessary for chaning the memory type for a page contains
> a combination of attributes that indicate the cacheability, idempotency,
> and ordering properties for access to that page.
> 
> As a part of the patch the following is introduced:
> - Svpbmt memory type defintions: PTE_PBMT_{NOCACHE,IO}.
> - PAGE_HYPERVISOR_{NOCACHE,WC}.
> - RISCV_ISA_EXT_svpbmt and add a check in runtime that Svpbmt is
>   supported by platform.
> - Update riscv/booting.txt with information about Svpbmt.
> - Update logic of pt_update_entry() to take into account PBMT bits.
> 
> Use 'unsigned long' for pte_attr_t as PMBT bits are 61 and 62 and it doesn't
> fit into 'unsigned int'. Also, update function prototypes which uses
> 'unsigned int' for flags/attibutes.
> 
> Enable Svpbmt for testing in QEMU as Svpmbt is now mandatory for
> Xen work.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu May 22 07:26:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:26:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993029.1376479 (Exim 4.92)
	(envelope-from )
	id 1uI0KJ-0006pB-Qk; Thu, 22 May 2025 07:26:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993029.1376479; Thu, 22 May 2025 07:26:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI0KJ-0006p4-NP; Thu, 22 May 2025 07:26:51 +0000
Received: by outflank-mailman (input) for mailman id 993029;
 Thu, 22 May 2025 07:26:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI0KI-0006K9-TY
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:26:50 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1f89349b-36de-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 09:26:49 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-442ed8a275fso96053965e9.2
 for ; Thu, 22 May 2025 00:26:49 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f3dd94f1sm97278215e9.35.2025.05.22.00.26.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 00:26:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1f89349b-36de-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747898808; x=1748503608; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=D4WU5xmLRElTwZZkWu2x+8D04HEL65/GvsCbnJyPA9I=;
        b=HPayl2J42+LHbM06QAb6zrxS6j53zA6vrUC90YYW9cx7mQgvZ7Bczm1LJ5oOGesChT
         pIq6zuFk2F1ELFeknlmou5H5PgOpdj5AcWW4jODObnNo+WgQ9rj63giXWOMHdPt2iZSi
         s+S7ghg9p7Lqy/Z27ucL6hd6py4CEXYlFV97s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747898808; x=1748503608;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=D4WU5xmLRElTwZZkWu2x+8D04HEL65/GvsCbnJyPA9I=;
        b=XuZw3qK9bOCMhZUrh1/sszk5SwHXPALXHz9xfudIyuj36Gsa4NXUosQNp6RZ1eRW/s
         xWW+TMgQAAj6okK57XClWLuFOzGcDE1f+T5rte329D7cTt1ZUchErOTJloXxZwqXGEbg
         Ij76jwN9EyTx7xhoyZtbP8eyoBLWLpbNngtwiPW6OMz1C9TSyKKI9HMOXxgLqlswFP9k
         TGYdglGpdQTCplCVMvW1tlhvsf2mI9EAvxL8Lg6yJpNjSQucfFBYQTzw1t5rnHNfGSgc
         ndrRLJ9XrR03bCmBLJG3hUQ8aojL81IyMIttpyAjD14XsX/7m4iK/uVPTXknhwhe/qzl
         C+8Q==
X-Gm-Message-State: AOJu0YxKMKyL23W1N+4QhnXHZtWgDbLkWK5qHrNvS9Eu+jeVp51zT5cM
	XVt4WGSWiCpwiAhKOLePKjbcWbEIxeJL6c2Wtdo5w9KGcjiOo1rzVjozG4GQflJMjdI=
X-Gm-Gg: ASbGnctbIUJDETaBZdLQFKYiD5nwMLYZVfdBdlNBXyz+Iaa7HW4/dWXS2rdhLx4lb/V
	iUFF1kX9/9Ty2BVzjJh/Kc3uv/MaSF1NByjikJQrLsD9dT29tJQd8JXM7mTBAszyXUdlq3L1zmq
	rIezxWSp1Ep5tPxYyKDjdZYQ5xKlgHjfaSHdFTlt0K114KfKQju16HEWJ/tHG8AuRTD1r3uwdDn
	Su9lMjObctdQDQIlUDRgkBhslKhQQXiOyh+Hzs0KCKX6BcHsj1dNhfEdOb6dBJeTipY9mB+w2ut
	Yqa8EXSgGxSNqMLRn/TPUCPaV5RnXQYIqeLhjKBpUP7EIQtD1hGIIOWuUGHmOoINjz7kKPimqou
	W7ATciSaeKL23ykgMcYk=
X-Google-Smtp-Source: AGHT+IE+xhB7g+vH7dOPfPzmy3WOLqk7UPUEQjk1D3k9DR/CoQD743PK+pOonchCJLMgrwj67zVCZA==
X-Received: by 2002:a05:600c:524c:b0:43d:160:cd9e with SMTP id 5b1f17b1804b1-442fd633ae6mr260882545e9.17.1747898808334;
        Thu, 22 May 2025 00:26:48 -0700 (PDT)
Date: Thu, 22 May 2025 09:26:47 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, Jan Beulich 
Subject: Re: [PATCH 2/2] x86/boot: attempt to print trace and panic on AP
 bring up stall
Message-ID: 
References: <20250521165504.89885-1-roger.pau@citrix.com>
 <20250521165504.89885-3-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, May 21, 2025 at 07:16:18PM +0100, Andrew Cooper wrote:
> On 21/05/2025 5:55 pm, Roger Pau Monne wrote:
> > With the current AP bring up code Xen can get stuck indefinitely if an AP
> 
> You want a comma between "code, Xen" to make the sentence easier to parse.
> 
> > freezes during boot after the 'callin' step.  Introduce a 10s timeout while
> > waiting for APs to finish startup.
> 
> 5s is the timeout used in other parts of AP bringup.  I'd suggest being
> consistent here.
> 
> 
> > On failure of an AP to complete startup send an NMI to trigger the printing
> 
> Again, a comma between "startup, send" would go a long way.
> 
> > of a stack backtrace on the stuck AP and panic on the BSP.
> >
> > The sending of the NMI re-uses the code already present in fatal_trap(), by
> > moving it to a separate function.
> 
> I'd be tempted to split the patch in two.
> 
> >
> > Signed-off-by: Roger Pau Monné 
> > ---
> 
> It may be worth nothing that this came from the ICX143 investigation,
> even if it wasn't relevant in the end?
> 
> > diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> > index 48ce996ba414..77dce3e3e22b 100644
> > --- a/xen/arch/x86/smpboot.c
> > +++ b/xen/arch/x86/smpboot.c
> > @@ -1388,10 +1389,17 @@ int __cpu_up(unsigned int cpu)
> >      time_latch_stamps();
> >  
> >      set_cpu_state(CPU_STATE_ONLINE);
> > +    start = NOW();
> >      while ( !cpu_online(cpu) )
> >      {
> >          cpu_relax();
> >          process_pending_softirqs();
> > +        if ( NOW() > start + SECONDS(10) )
> 
> (NOW() - start) > SECONDS(10)
> 
> It has one fewer boundary conditions, even if it is rather unlikely that
> start + 10s will overflow.
> 
> > diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> > index c94779b4ad4f..9b9e3726e2fb 100644
> > --- a/xen/arch/x86/traps.c
> > +++ b/xen/arch/x86/traps.c
> > @@ -734,6 +736,40 @@ static int cf_check nmi_show_execution_state(
> >      return 1;
> >  }
> >  
> > +void show_execution_state_nmi(const cpumask_t *mask, bool show_all)
> > +{
> > +    unsigned int msecs, pending;
> > +
> > +    force_show_all = show_all;
> > +
> > +    watchdog_disable();
> > +    console_start_sync();
> > +
> > +    cpumask_copy(&show_state_mask, mask);
> > +    set_nmi_callback(nmi_show_execution_state);
> > +    /* Ensure new callback is set before sending out the NMI. */
> > +    smp_wmb();
> 
> I know this is only moving code, but this is wrong.  So is the smp_mb()
> in the x2apic drivers.
> 
> It would only be correct in principle for xAPIC (which is an MMIO
> store), except it's UC and is strongly ordered anyway.  Furthermore, the
> sequence point for the send_IPI_mask() prevents the compiler from
> reordering this unsafely.
> 
> The x2APIC drivers need LFENCE;MFENCE on Intel, and just MFENCE on AMD,
> and this (critically) is not smp_mb(), which is now just a locked operation.
> 
> I bet these aren't the only examples of incorrect barriers WRT IPIs.  I
> guess we should fix those separately.

Thanks, I will remove the smp_wmb() ahead of moving the code, but
other instances in the APIC drivers I will leave for a different
series, I don't want to delay the work here on those fixes.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 22 07:27:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:27:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993035.1376490 (Exim 4.92)
	(envelope-from )
	id 1uI0Kk-0007I9-29; Thu, 22 May 2025 07:27:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993035.1376490; Thu, 22 May 2025 07: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 1uI0Kj-0007I2-VU; Thu, 22 May 2025 07:27:17 +0000
Received: by outflank-mailman (input) for mailman id 993035;
 Thu, 22 May 2025 07:27:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI0Ki-0006K9-OV
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:27:16 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2062a.outbound.protection.outlook.com
 [2a01:111:f403:2418::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2e27113e-36de-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 09:27:14 +0200 (CEST)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by BL4PR12MB9480.namprd12.prod.outlook.com (2603:10b6:208:58d::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.31; Thu, 22 May
 2025 07:27:10 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8746.030; Thu, 22 May 2025
 07:27:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2e27113e-36de-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HmNGVNo2Zr2Y0gZmvVOtSRmTOd7vTjWrABOCTZ5LN4W/MDkZd2cHtw/ZMKrHWQ2QSrl8mxHH8WH8h70jmnfq//1wesO9G8i/fSRRb/37YFhi2IcHlhUiVFWhUwmftQzjEB4CzFMpCjRmltiryf8L0XskQc1LSucj7fGH6uEatJIcJdneni5P2C0EqZvPit2TL2NssO6UdbmYSDXZPO8tlLKDzYMXYrc8xfUA4A5ui0K0H982LTbVKNTRdg9XA3faDNFpPoAqRy4iFVk5fSLarAO9OQVKw9urqzqEQZ6v7KdY+oq7UUP6uvjJEYAd4osPoal0m10y4lqIQNZhhdx9Tw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=00Rmu00Ma0deiKirFzc9Hiv4TzOZ+LhPJQDhrTZMBr0=;
 b=g2SZexQQhGkXxWjvWPYfYrSeZrtC2UZ0NH4wOXRN2GmARwooPEINaNGtTWiXxp286UssUZGrBj4F9xgkd406wz43C0RC6lYUGIZbWeCW5nSu3WJjVnfzHylIs9isa269iMBq8VAA5mwovFhBaO0V5WcsRbSjt7OrSX1U0o8FB2+0mK7Sxtheivo6kPWuHhcKMVjywJbbOdHIiYkQEbtZIKA3Gnv0gh9L7/kBzxj+thDtK1hIHujeGIVSbwrjRafBzWk+uw9XHjYFjPFPZTBYwHhj8WZ2S13aXgh1+G6RuTfs9AkrZnrV4aTPiqDN2rSaAV+cinlTf0mdJS3FbjHRJw==
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=00Rmu00Ma0deiKirFzc9Hiv4TzOZ+LhPJQDhrTZMBr0=;
 b=TWfV5RJBQ1lAhao61bA8cpDPDas0Tnd4jkhssTpx32yZN/B6OTEqQGplkMYDxzfYJNNMnk/QTCTnTuBG49GZssfpMyX6yPaKcWYRuTCPZjXRV8H4aVfFIIj5QDShQbx+sDI4JPXZow78u8sj7EiC5xrle+1DibedBy9PDUHCcuE=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: Jan Beulich , "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Topic: [PATCH v4 09/10] vpci/msi: Free MSI resources when init_msi()
 fails
Thread-Index:
 AQHbwMGh3xGCtPOZ6EmRbIkDtAY42rPbIqIAgAApmYCAAAFtgIAACDMAgAHezgD//894AIABfxcA///NAYCAAIoGgA==
Date: Thu, 22 May 2025 07:27:09 +0000
Message-ID:
 
References: <20250509090542.2199676-1-Jiqian.Chen@amd.com>
 <20250509090542.2199676-10-Jiqian.Chen@amd.com>
 <8d89f644-4ded-4490-ad23-518563d230d2@suse.com> 
  
 
 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8746.028)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|BL4PR12MB9480:EE_
x-ms-office365-filtering-correlation-id: 049f4110-9635-4039-5252-08dd9902105a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?azU2YXNlZ3pZRWkzQStNVFVJUWhSekErQkVORFZDT2ZsL05MUThTblJ6VEt4?=
 =?utf-8?B?VS9sbzlLVVZhTGZNbmV6cDVNUEE2QmVPWlhuTWxIczZCUnU2Ymh0aFFIbW9U?=
 =?utf-8?B?ZGdzUEFla2J4ckxPOUl1QWNSaXRBVlJSTnRxMWQ1U1MyU0FnalQxQ0FOODFB?=
 =?utf-8?B?Q3A0N2tFcm13Mlpsb24zbVhDcytmc1U4d3MxeWgxZmUrbEQrUHJJZWQ2VVZB?=
 =?utf-8?B?c3ZNeWMxclZnZGdMTGI5aUR0dVpTbnBCckJ3OFRvUUh1MUNSSXYzSzZTMTBs?=
 =?utf-8?B?N0VRNzhBZ2t5WVBUNTJZdnJxSm1Teng0d2hveE5oWG53NTYzU242WFNPU09a?=
 =?utf-8?B?NUdtOVcvS0NVb2xKclNNWTBVVGF3RWtUU2RIRFZ1ZlVvSWFJaEFWbkRBZmZJ?=
 =?utf-8?B?STZDL0lpUll3dFBJUDl3dmJ0cklzbVBzSFNRZ0tQaWJVd3JSRHJhdm1Lc0l2?=
 =?utf-8?B?WlFYZ0VkcHpONzdmdlViRGtEMWZPWG1iSTFHQVZDNnFZTUNORjQ4UHlHM0Rh?=
 =?utf-8?B?QjQ0Z2JuaVIxYU9XRjZQWjFubnNKTS9zSXphS1lzbWliMVpjNnNma1h0c3Bl?=
 =?utf-8?B?TWlGTlE3bEhrRGt3TmtCdGhsOFZTUlFFQU8rRFEvNUhjSktwYWZMRjUvRE5h?=
 =?utf-8?B?Nys2RGMrVmtCRENFalJGNmVxTlUwS2dqUERqSUpSa1FmQkhibXBiWHZlMXFE?=
 =?utf-8?B?QW9hcjBvZWJIRytoSDRvc1NJb2ZGaTNoQm1FTWwyWS9aN0s1M3I3QkRWWHgx?=
 =?utf-8?B?K0VoS3IzK3Zpak03Q1dBQWtKRk45RFFVRzNiUnFFdDl6YVFCSTY5blZ5YkZV?=
 =?utf-8?B?RTIxSUdWcVNJSkppT2sxMzhRa3daRkhZV2F4cUg2bERZalQrWlFNN2xDSWdj?=
 =?utf-8?B?K1M0UlRHTHJmTHdLYTl6RVFudXhJalArd29oaDVNK25kbHRPRlBGVjk1V3lB?=
 =?utf-8?B?a3pMRXMwOVFXT1NMVHQvTVQyczNqSlhtMzRrcEI0WTRIa1JZZ2Z2d0ZMNFVU?=
 =?utf-8?B?SlZWeTlhVkJEcnZ0dHRkM0dlUlVWNzR4RnJJbG1JY1dMdllidjdzR05YUVZi?=
 =?utf-8?B?S2xlRFZtUlkwL1F4T1l5cXBxb2hWOThCVWNIb2JPcTdQRCtxMWlIcXRqYzd5?=
 =?utf-8?B?TUhRVjl2elQyeXNlekJlSlNsQ091bG5neDd6SWVjZVVDbmxTZDBqVEpld1Z2?=
 =?utf-8?B?TEtTWmppRnJLRXlIMnpKRVhvbGcyL3cyUHcxcGZhcmNYRWpIcnlCSVJSMFdS?=
 =?utf-8?B?bXNsNG55VUY2dDJMem4zUUt6TTl6MzY3MWxiTCtzbHpEdzQrZWc2OVNGbzRW?=
 =?utf-8?B?VXhsSmhjN0l0T09MZWxhaUlndzVTcTlXcHVsR3RIejdyYUo1Tis2YlQxUWdz?=
 =?utf-8?B?ODlKR2V6VHhoenBHTTNnREtLbU43NHovQnFKMHMwQ0p3UUEzK2lobHVOeHBo?=
 =?utf-8?B?T2RURGEzKzRWNmhkT3V6SWF1em1tRFlKanp0Nk1nSmxGSUN6UXpYVVVmQjVa?=
 =?utf-8?B?bndNNzBFdnpkU054bXdENGRMbFNVY1NweVBNczE2NTN2Zjl1WTh2OFBWUjhy?=
 =?utf-8?B?Zy9XYnIwbFhvNWUreHMzTC9NdlpreFFMdElzNElwL0cxVXpvekEzN01TeTlI?=
 =?utf-8?B?MHQveDd4bWdpN0NVelFMc2Y2Yk5IMUdnNERnaGF1NU9sOWk4empUdjJTVTAy?=
 =?utf-8?B?RGVsZEQ3dHN3djhIVGdPREpKbWUzNVZLZGdaelRoRW1DcElpanRWZnJNS284?=
 =?utf-8?B?c1c5dXJXdVFBQjIxYzFSUE5hWmIrbENrZ2dNS2p0Zk1waGM4bG9oRTczYkxx?=
 =?utf-8?B?U1NoRnRtbHZ3dHhiVmhWUUpreU1CRFZZV2Z6aFhYZUZIVzZHNnNWSzFvM0Iz?=
 =?utf-8?B?bGxvU3hYNTVCcWoyRCtqNU9vNmVpRWJJUWFWM0MrYnZNcGw1SCtMZGxYZ3RC?=
 =?utf-8?B?UytYbHFXRWo2SkJzMlBJbHdzcWtvM0s1ZDhVYWR3YzZlYk9BTlk2N2ZQcjhB?=
 =?utf-8?B?ZDBEeDduK1FBPT0=?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?UEI1RllqcUphSXQ0dithRVQ3V0Z5SFAwdENmeWdWZzljeG94ZXMza0FkeDdj?=
 =?utf-8?B?dXo5SjhWRGwxTjRSamRxMWY0UjBUaE1NUmk1TVZmWUY2RFkzemw3dERjRVdL?=
 =?utf-8?B?WGszc2VDYnQ5bitUVEhoZFNXN01Jd2tKUTFEOHRYN2tNdDB5amFkNnVmRStt?=
 =?utf-8?B?eEplSHQ0NXdyZFE0QTBXU3dIZUdkdVZWanlYdzRvR0VaM25WUVo2WnB0dktR?=
 =?utf-8?B?SWFZY05xQ09rTkd2dFpFODRJMWxSanFnQTE4QWVkb0dacUN5M0p1TGJSUkoy?=
 =?utf-8?B?cUt6ZVlob2tpbTNoTkxrR081SjZpdVZxMksvT3ljWC9GeXhITnpyK3RDNUE5?=
 =?utf-8?B?MzhTalptZzZHdTBVUExmdk41b3JOVTZhTk9jOW5xdXpQQ2pKQ1hMeSs4THhw?=
 =?utf-8?B?TndvZy92aWpVM0o0a2puTitZOWlrTy8ySlpKZmZXSEFON05UaDhPMXE3V0NB?=
 =?utf-8?B?Sm1taVJOTUlvRW40R01kakRDajRLZ3ozYlJoWTBheDFsN1hrdDdSaXdobnlh?=
 =?utf-8?B?SkVqVGQ1M1ljYWhsU1B5OXRwdGo3c0VqRVltcExWRmRpRVF0U2ZlYzhFelpW?=
 =?utf-8?B?WXBuK2xQVEk1aFBPMzZyUyt4MzA2N2ozMldCTVczL0g5cUVNRXVCTUt6ck5U?=
 =?utf-8?B?cUFhSW4zZDM3NHR3dENvS0dXTVMvMG0yYis1VTJLOW5NSWVMV2RXbFlZMXBq?=
 =?utf-8?B?THZMRHljMkNPNWUxZktOL1pNMkk3dGZvUndhSEtBZ0dDQXhNV0svS3hLYkRl?=
 =?utf-8?B?bFNKREk2SVZyYVVQb2IxUGRmQlFSaFBTaW9VRCtBWVBwajFQY2pRY0wxL1dZ?=
 =?utf-8?B?MC96STZJRldPTUczR1dhUmpYTTBmTkl0Skc5YisyWEYvdnZrS29IcTBTTDNL?=
 =?utf-8?B?aWpuQXlFTHFyZjM3R010QVpTdXc4aVFiQTNFZ3d0bEtJOXhuQVZOaFpraERV?=
 =?utf-8?B?Yjd0SzF6RUF0N2JvNi9hNko2Z20vK0NhUG5XU0xIak1XbzlaNkpVdnlUcEQ2?=
 =?utf-8?B?U2twYStOSDJUWWJucDdDRVdvNFAydktMT0dpakZnaDZqbDVnb1VvdGxrQlIy?=
 =?utf-8?B?bHIrK2pudTlpRlRuaHhTQmlLVy9TNlJiWTlKVlVzSi9YVmlnWlBRYzU3a0M4?=
 =?utf-8?B?Ym5kbVJwZlVkNE9EdlVpSnpkODM5M2hITlFVSHpVa3pVbjVZam9nODdWb3BB?=
 =?utf-8?B?RFZsaWg1elp1MnpacGVzbTVTb0MvcGpDa05yeCtGdUg2Z3ZZQjNKWXFjc3N2?=
 =?utf-8?B?STByWVcxbVFTQ2xSNmNOTGJCaU9YaFMyUllaVERTbklIKzJjYSsvN0hpdmdI?=
 =?utf-8?B?ZmNRN20vOTVQRm9LSXJmaWF2b0hWZjZOSzNZNHZiZ1hrMWpkNFU2aUx3ZFJP?=
 =?utf-8?B?NFBGNEY5aEd2aUk0VTdVcTdldDdUWVZPM2xXaXUrRnNMVDdGc2VDRDVZakhH?=
 =?utf-8?B?R21YR1VWVW1JS2ZhUWl6WlFoNDcxYmFUSExHRm5uTU1xNFY1ZFYzakxJTnVk?=
 =?utf-8?B?K1F1ZDZTOXZxaVZZMUhwZTlCNUZyU3dVdFdhWnNnOUwwdHNlZ09PR01hRHdJ?=
 =?utf-8?B?S3p1anVWcUJ2YUttSUREQjBCVDZjZHk5VndpTExQdndlUHhsS0RyR0Y3R1Jx?=
 =?utf-8?B?THlCMWd1N01KSk90Z1QxRm9uOTlFVEJoTm1zekx2V3hENTB4ZnIyMDc0Z1Zi?=
 =?utf-8?B?MGpXV2x2YnU4YjkvWmwyajBRY2Z1M1JWQnMreDFZTkdEcy9sUDIvVlYweHpE?=
 =?utf-8?B?RTBNa0Z4ZWJDbVBCbmZyNzkzNlQrWXoyaDIxOE5WRlg4SWRGdTlaMzVKTHdC?=
 =?utf-8?B?aFc0TFNWQUhXaTB2QXBFY0V3Ykx0TzdyZUNCNnJOa0JnckZ3YUhkWTRCM1Vl?=
 =?utf-8?B?WjF4eGNwME1nbHBObkZZTkUxUlBJdnpGcnAzODhGY2FiTGR0SHNMWEVQcDVP?=
 =?utf-8?B?eWJKd3psa0x2eVFqMlZnYU9uKzBrelBiUkZYbHA1VGlkYng1NC84TkhKQjdW?=
 =?utf-8?B?U1l0KzFwbytyc0kwVnpxNk9EMEJoQzVwZy9zTWY4UGNXRWEwdlBJbGVtUHhz?=
 =?utf-8?B?bzJHZHovaGhSVlhxcEZJK2M0aWVrNjVESlNDMVBmVHZiZUVYMnVoTk1DVW5n?=
 =?utf-8?Q?3WjQ=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3E5E9F8603AD5F4E8E8250355BDE8782@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 049f4110-9635-4039-5252-08dd9902105a
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2025 07:27:09.9749
 (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: 7T1hFk28dL3oTDt5iM3rejCIUjz86f+MLcVxLNT9OwMM3JwY+8gGh7LayPoZOQiHr9d7LNd8PAE3GRa9lt8o/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR12MB9480

T24gMjAyNS81LzIyIDE1OjEyLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPiBPbiBUaHUsIE1h
eSAyMiwgMjAyNSBhdCAwMjoyMToxNkFNICswMDAwLCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+PiBP
biAyMDI1LzUvMjEgMTk6MjMsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+Pj4gT24gV2VkLCBN
YXkgMjEsIDIwMjUgYXQgMDc6MDA6MzdBTSArMDAwMCwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+
PiBPbiAyMDI1LzUvMjAgMTc6NDMsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+Pj4+PiBPbiBU
dWUsIE1heSAyMCwgMjAyNSBhdCAxMToxNDoyN0FNICswMjAwLCBKYW4gQmV1bGljaCB3cm90ZToN
Cj4+Pj4+PiBPbiAyMC4wNS4yMDI1IDExOjA5LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPj4+
Pj4+PiBPbiBUdWUsIE1heSAyMCwgMjAyNSBhdCAwODo0MDoyOEFNICswMjAwLCBKYW4gQmV1bGlj
aCB3cm90ZToNCj4+Pj4+Pj4+IE9uIDA5LjA1LjIwMjUgMTE6MDUsIEppcWlhbiBDaGVuIHdyb3Rl
Og0KPj4+Pj4+Pj4+IFdoZW4gaW5pdF9tc2koKSBmYWlscywgdGhlIHByZXZpb3VzIG5ldyBjaGFu
Z2VzIHdpbGwgaGlkZSBNU0kNCj4+Pj4+Pj4+PiBjYXBhYmlsaXR5LCBpdCBjYW4ndCByZWx5IG9u
IHZwY2lfZGVhc3NpZ25fZGV2aWNlKCkgdG8gcmVtb3ZlDQo+Pj4+Pj4+Pj4gYWxsIE1TSSByZWxh
dGVkIHJlc291cmNlcyBhbnltb3JlLCB0aG9zZSByZXNvdXJjZXMgbXVzdCBiZQ0KPj4+Pj4+Pj4+
IHJlbW92ZWQgaW4gY2xlYW51cCBmdW5jdGlvbiBvZiBNU0kuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g
VGhhdCdzIGJlY2F1c2UgdnBjaV9kZWFzc2lnbl9kZXZpY2UoKSBzaW1wbHkgaXNuJ3QgY2FsbGVk
IGFueW1vcmU/DQo+Pj4+Pj4+PiBDb3VsZCBkbyB3aXRoIHdvcmRpbmcgYWxvbmcgdGhlc2UgbGlu
ZXMgdGhlbi4gQnV0IChhbHNvIGFwcGxpY2FibGUNCj4+Pj4+Pj4+IHRvIHRoZSBwcmV2aW91cyBw
YXRjaCkgLSBkb2Vzbid0IHRoaXMgbmVlZCB0byBjb21lIGVhcmxpZXI/IEFuZCBpcw0KPj4+Pj4+
Pj4gaXQgc3VmZmljaWVudCB0byBzaW1wbHkgcmVtb3ZlIHRoZSByZWdpc3RlciBpbnRlcmNlcHRz
PyBEb24ndCB5b3UNCj4+Pj4+Pj4+IG5lZWQgdG8gcHV0IGluIHBsYWNlIG9uZXMgZHJvcHBpbmcg
YWxsIHdyaXRlcyBhbmQgbWFraW5nIGFsbCByZWFkcw0KPj4+Pj4+Pj4gcmV0dXJuIGVpdGhlciAw
IG9yIH4wIChjb3ZlcmluZyBpbiBwYXJ0aWN1bGFyIERvbTAsIHdoaWxlIGZvciBEb21VLXMNCj4+
Pj4+Pj4+IHRoaXMgbWF5IGFscmVhZHkgYmUgdGhlIGNhc2UgYnkgZGVmYXVsdCBiZWhhdmlvcik/
DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEZvciBkb21VcyB0aGlzIGlzIGFscmVhZHkgdGhlIGRlZmF1bHQg
YmVoYXZpb3IuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEZvciBkb20wIEkgdGhpbmsgaXQgc2hvdWxkIGJl
IGVub3VnaCB0byBoaWRlIHRoZSBjYXBhYmlsaXR5IGZyb20gdGhlDQo+Pj4+Pj4+IGxpbmtlZCBs
aXN0LCBidXQgbm90IGhpZGUgYWxsIHRoZSBjYXBhYmlsaXR5IHJlbGF0ZWQNCj4+Pj4+Pj4gcmVn
aXN0ZXJzLiAgSU1PIGEgd2VsbCBiZWhhdmVkIGRvbTAgd29uJ3QgdHJ5IHRvIGFjY2VzcyBjYXBh
YmlsaXRpZXMNCj4+Pj4+Pj4gZGlzY29ubmVjdGVkIGZyb20gdGhlIGxpbmtlZCBsaXN0LA0KPj4+
Pj4+DQo+Pj4+Pj4gSnVzdCB0aGF0IEkndmUgc2VlbiBkcml2ZXJzIGtub3dpbmcgd2hlcmUgdGhl
aXIgZGV2aWNlIGhhcyBjZXJ0YWluDQo+Pj4+Pj4gY2FwYWJpbGl0aWVzLCB0aHVzIG5vdCBib3Ro
ZXJpbmcgdG8gbG9vayB1cCB0aGUgcmVzcGVjdGl2ZQ0KPj4+Pj4+IGNhcGFiaWxpdHkuDQo+Pj4+
Pg0KPj4+Pj4gT0ssIHNvIGxldCdzIG1ha2UgdGhlIGNvbnRyb2wgcmVnaXN0ZXIgcmVhZC1vbmx5
IGluIGNhc2Ugb2YgZmFpbHVyZS4NCj4+Pj4+DQo+Pj4+PiBJZiBNU0koLVgpIGlzIGFscmVhZHkg
ZW5hYmxlZCB3ZSBzaG91bGQgYWxzbyBtYWtlIHRoZSBlbnRyaWVzDQo+Pj4+PiByZWFkLW9ubHks
IGFuZCB3aGlsZSB0aGF0J3Mgbm90IHZlcnkgY29tcGxpY2F0ZWQgZm9yIE1TSSwgaXQgZG9lcyBn
ZXQNCj4+Pj4+IG1vcmUgY29udm9sdXRlZCBmb3IgTVNJLVguICBJJ20gZmluZSB3aXRoIGp1c3Qg
bWFraW5nIHRoZSBjb250cm9sDQo+Pj4+PiByZWdpc3RlciByZWFkLW9ubHkgZm9yIHRoZSB0aW1l
IGJlaW5nLg0KPj4+PiBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCBJIG5lZWQgdG8gYXZvaWQg
Y29udHJvbCByZWdpc3RlciBiZWluZyByZW1vdmVkIGFuZCBzZXQgdGhlIHdyaXRlIGhvb2sgb2Yg
Y29udHJvbCByZWdpc3RlciB0byBiZSB2cGNpX2lnbm9yZWRfd3JpdGUgYW5kIGF2b2lkIGZyZWVp
bmcgdnBjaS0+bXNpPw0KPj4+Pg0KPj4+PiAiDQo+Pj4+ICAgICAgaWYgKCAhbXNpX3BvcyB8fCAh
dnBjaS0+bXNpICkNCj4+Pj4gICAgICAgICAgcmV0dXJuOw0KPj4+Pg0KPj4+PiArICAgIHNwaW5f
bG9jaygmdnBjaS0+bG9jayk7DQo+Pj4+ICsgICAgY29udHJvbCA9IHZwY2lfZ2V0X3JlZ2lzdGVy
KHZwY2ksIG1zaV9jb250cm9sX3JlZyhtc2lfcG9zKSwgMik7DQo+Pj4+ICsgICAgaWYgKCBjb250
cm9sICkNCj4+Pj4gKyAgICAgICAgY29udHJvbC0+d3JpdGUgPSB2cGNpX2lnbm9yZWRfd3JpdGU7
DQo+Pj4+ICsgICAgc3Bpbl91bmxvY2soJnZwY2ktPmxvY2spOw0KPj4+PiArDQo+Pj4+ICAgICAg
aWYgKCB2cGNpLT5tc2ktPm1hc2tpbmcgKQ0KPj4+PiAgICAgICAgICBlbmQgPSBtc2lfcGVuZGlu
Z19iaXRzX3JlZyhtc2lfcG9zLCB2cGNpLT5tc2ktPmFkZHJlc3M2NCk7DQo+Pj4+ICAgICAgZWxz
ZQ0KPj4+PiAgICAgICAgICBlbmQgPSBtc2lfbWFza19iaXRzX3JlZyhtc2lfcG9zLCB2cGNpLT5t
c2ktPmFkZHJlc3M2NCkgLSAyOw0KPj4+Pg0KPj4+PiAtICAgIHNpemUgPSBlbmQgLSBtc2lfY29u
dHJvbF9yZWcobXNpX3Bvcyk7DQo+Pj4+ICsgICAgc3RhcnQgPSBtc2lfY29udHJvbF9yZWcobXNp
X3BvcykgKyAyOw0KPj4+PiArICAgIHNpemUgPSBlbmQgLSBzdGFydDsNCj4+Pj4NCj4+Pj4gLSAg
ICB2cGNpX3JlbW92ZV9yZWdpc3RlcnModnBjaSwgbXNpX2NvbnRyb2xfcmVnKG1zaV9wb3MpLCBz
aXplKTsNCj4+Pj4gLSAgICBYRlJFRSh2cGNpLT5tc2kpOw0KPj4+PiArICAgIHZwY2lfcmVtb3Zl
X3JlZ2lzdGVycyh2cGNpLCBzdGFydCwgc2l6ZSk7DQo+Pj4NCj4+PiBJIHRoaW5rIHlvdSB3YW50
IHRvIGZpcnN0IHB1cmdlIGFsbCB0aGUgTVNJIHJhbmdlLCBhbmQgdGhlbiBhZGQgdGhlDQo+Pj4g
Y29udHJvbCByZWdpc3RlciwgYWxzbyB5b3Ugd2FudCB0byBrZWVwIHRoZSBYRlJFRSgpLCBhbmQg
c2V0IHRoZQ0KPj4+IHJlZ2lzdGVyIGFzOg0KPj4gVW5kZXJzdG9vZC4NCj4+DQo+Pj4NCj4+PiB2
cGNpX2FkZF9yZWdpc3Rlcih2cGNpLCB2cGNpX2h3X3JlYWQxNiwgTlVMTCwgbXNpX2NvbnRyb2xf
cmVnKG1zaV9wb3MpLA0KPj4+ICAgICAgICAgICAgICAgICAgIDIsIE5VTEwpOw0KPj4gQW5kIG9u
ZSBtb3JlIHF1ZXN0aW9uLCBob3cgZG8gSSBwcm9jZXNzIHJldHVybiB2YWx1ZSBvZiB2cGNpX2Fk
ZF9yZWdpc3RlciBzaW5jZSBkZWZpbml0aW9uIG9mIGNsZWFudXAgaG9vayBpcyAidm9pZCI/DQo+
PiBQcmludCBhIGVycm9yIG1lc3NhZ2UgaWYgZmFpbD8NCj4gDQo+IFdlbGwsIHdlIHNob3VsZCBj
b25zaWRlciB0aGUgY2xlYW51cCBmdW5jdGlvbiByZXR1cm5pbmcgYW4gZXJyb3IgY29kZS4NCj4g
dnBjaV9yZW1vdmVfcmVnaXN0ZXJzKCkgY2FuIGFsc28gZmFpbCwgYW5kIHRoZSBlcnJvciBpcyBj
dXJyZW50bHkNCj4gaWdub3JlZC4gIEJvdGggY2FzZXMgc2hvdWxkIHJlc3VsdCBpbiBmYWlsaW5n
IHRvIGFzc2lnbiB0aGUgZGV2aWNlIHRvDQo+IHRoZSBkb21haW4gSU1PLg0KT0ssIHdpbGwgY2hh
bmdlIGluIG5leHQgdmVyc2lvbi4NClRoYW5rIHlvdSENCg0KPiANCj4gVGhhbmtzLCBSb2dlci4N
Cg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Thu May 22 07:33:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:33:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993051.1376500 (Exim 4.92)
	(envelope-from )
	id 1uI0Qp-00011f-PZ; Thu, 22 May 2025 07:33:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993051.1376500; Thu, 22 May 2025 07:33: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 1uI0Qp-00011Y-MM; Thu, 22 May 2025 07:33:35 +0000
Received: by outflank-mailman (input) for mailman id 993051;
 Thu, 22 May 2025 07:33:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI0Qo-000110-IU
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:33:34 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1058ab99-36df-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 09:33:33 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad51ef2424bso1211576866b.0
 for ; Thu, 22 May 2025 00:33:32 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d438086sm1027096266b.89.2025.05.22.00.33.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 00:33: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" 
X-Inumbo-ID: 1058ab99-36df-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747899212; x=1748504012; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=OY4atMzM5dFc/F+bExUQKfalrJYBS2kiIBGL2qt8cmg=;
        b=dlEqBZ3B8XeIjIE29HSe6GM3APAvBMENK2y4+bvCErWZwC+/Rt1EDPQG2kcCvPY+/M
         7YoJK8yucUphatJfr1DwgDV+bMNcAiL715nWKXeKXCGUsk81swqIucnjzRYEPmtXTH7n
         72RynLnGcEAa4qrMANzyvzoxNgt7Ix5F7tWn0Uvkw2Niw6k3GnVdovBfKr3dc/zkx9T5
         NHscDpv3VhB75PMtZDgdcPVFxAMzo/9XrF8G/mTItg9C2DrmkM1cei647TdCGPB0+D/X
         RJpP9Xx20rHjWSs0KTDBkl/mDfE+KthoaTbpnNDxaa0eOTNjkTUhd01vnYlfbWrjGQF+
         1wDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747899212; x=1748504012;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=OY4atMzM5dFc/F+bExUQKfalrJYBS2kiIBGL2qt8cmg=;
        b=LOOhSBhtNkeETK+6/1cGeSKZQtLgHdYymgo2ZK0i5a+UDSs7k0GGTjvx4nb7X3YO+o
         FxQmhQrlF3oC95mlUdhs38Ur1WQ+q73TouV2iY8UpTkcNvSV5Iy8YYwn5a/Dmheue1nn
         d7LQrAPbSpU0JIlFdsG6U8oM985gvX9fQvY3BB/MBrSno8SpKqkILECmK9BVnxuBr9Tn
         /aQ06bIg7F3222YxtyVpXMW5ARj4nTekhwq4zDEzloybO1XzNGLsT986tQL0LaGbxEhv
         e16YiY7vUnnqdCLCUN/4EyUXknhf3SVuzDKjvYyeAFWVpi3AySKCoKx5TLK7SDmJly1e
         CIbg==
X-Forwarded-Encrypted: i=1; AJvYcCWOFJZAxOk2iBdimUqGqSH6X6yQLVzKvR/AqIWHgPZKgMpbK56K4r4d0bMq7/dO8Fm471bs00VP6xE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxw1/kPDY8hk5bXHVAzsyY9DKpwCgDGb4+uyFGKAsePwPGSlfVu
	rak5LQmAssJhPluh9vq/wdeU8tSa3npwyfJM0ocr6n5jDS2Dg82jJrl/A8nHIAmg6w==
X-Gm-Gg: ASbGncuv13fsuQRZZ6iJjP4dIEPUZ8qgr+vOUM3lSIy5ESdwjQr6cpmpO0GEE/Qd/au
	FPAA+T8UE2XotK9P4ASweJnlX2vI6waNQxv3X6c55G1oR2pmjaVuoq3pQdQt9e3IStvfYJF+ZpJ
	4V6xeRVdRA2zXRUn+7CNn78v2NOwmMkzDCqEmGFS4kYMfn0hVA++0Rw9UofKd8TVxrUE9GE4KC3
	zZku9qLMHQSUK5/fb/IUHNmoVwepgM22+FPQdg1lG9UH6HLeK2FW4sbMZzTBJcoD+FNCT4H67WS
	Z6UYhM/bFPXiZXHzEcgGnsspwrQaKmLQj5wrhV+oN4TDjOwfaxBAPeKIzXwqXA==
X-Google-Smtp-Source: AGHT+IGmsPrjGhR/HfxZjU9TQ/wMC/nNAguNrRjkS9o4fFY18sFR7aI5iEZpTynADOkBp7z9C/RHRg==
X-Received: by 2002:a17:907:980d:b0:ad2:3f1f:7965 with SMTP id a640c23a62f3a-ad52d43838fmr2323033166b.4.1747899212339;
        Thu, 22 May 2025 00:33:32 -0700 (PDT)
Message-ID: 
Date: Thu, 22 May 2025 09:33:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 03/14] xen/riscv: add ioremap_*() variants using
 ioremap_attr()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <2bdbb98adf5246cd1a10e1575b8bf0aa2bdb5f6d.1747843009.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <2bdbb98adf5246cd1a10e1575b8bf0aa2bdb5f6d.1747843009.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> Introduce ioremap_attr() as a shared helper to implement architecture-specific
> ioremap variants:
> - ioremap_cache()
> - ioremap_wc()
> 
> These functions use __vmap() internally and apply appropriate memory attributes
> for RISC-V.
> 
> These functions are implemned not as static inline function or macros as it will
> require to include asm/page.h into asm/io.h what will lead to compilation
> issue.
> 
> Also, remove the unused ioremap_wt() macro from asm/io.h, as write-through
> mappings are not expected to be used on RISC-V.
> 
> Signed-off-by: Oleksii Kurochko 

Reviewed-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu May 22 07:39:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:39:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993065.1376510 (Exim 4.92)
	(envelope-from )
	id 1uI0W6-0001cc-Bd; Thu, 22 May 2025 07:39:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993065.1376510; Thu, 22 May 2025 07:39:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI0W6-0001cV-83; Thu, 22 May 2025 07:39:02 +0000
Received: by outflank-mailman (input) for mailman id 993065;
 Thu, 22 May 2025 07:39:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI0W4-0001cP-UH
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:39:00 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d3481a45-36df-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 09:39:00 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ac2bb7ca40bso1297419866b.3
 for ; Thu, 22 May 2025 00:38:59 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d04aed7sm1037687966b.9.2025.05.22.00.38.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 00:38: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" 
X-Inumbo-ID: d3481a45-36df-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747899539; x=1748504339; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=7YO7CMJfci6zs46H5NMTwaTIOU7pUi3zDYyjePlu7xc=;
        b=UhBAKQM706Je6foONDPANoyBuni+WAKGITbzyb4kHQJ4b9jlu2YGS+T11r52kh0tyQ
         kEHY8ze0U0Bnr9SBPMKQrdGBhWhPgpgSlw+5a4vnPYNfzmPwmfPj85lLW8xhjkWf4WGJ
         o4AEZ99VIUHkGD2+/AuD8Hrijex8DaLJqoUJieZ5Zo5fjfb+gXXx45ZtxLNEI2WjhzNU
         XNFk1aikKnYZSaeje8xotiVmphGZTy112FnThJSp3rXNPJVHqRMIxWHzKsN3roaw4pCH
         i3/L+Ae80HgxVwXS/Xwha0Dob/J9cGmG4MvkfIihtOqnAIJpjHQ2ckmpBGxoHM5i6wwG
         VVaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747899539; x=1748504339;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7YO7CMJfci6zs46H5NMTwaTIOU7pUi3zDYyjePlu7xc=;
        b=MX+y4eCOxMhDgr3oGB3dEpR0c8drbKXsScuo8mbUcHsJAE7p+E3jUrAxuBP3khZ2aA
         OQLo6gqN+0xUoNheiqmHv4vamfhDLLwMsQcQWQA9pCDN2l/3T42xLlxnNWG2EJelLuTu
         eP0N/I3Qf54mVMK7/0UuUSDHBYutHTOY3kE6aQ/bhTfSXo2ly3baWPIzP+uLWpVBjsiS
         qYULmXJLI8cNhk5T4+x7964udGQlY7zl4oMOiBwzREGaOghEqPCbzxrtfSaK+wiIdmXt
         Gn6K2DEcmoG2Vj/Awd64BYSXqOaq13cSCWPPgNjtWSyEwrJY8e5nHMvDBAVUu/90GfSx
         SoZQ==
X-Forwarded-Encrypted: i=1; AJvYcCVjRNBSRibDB+msMXYvuxy2bsfxyeDT9JgnZHUddOkyyg/Rhun886pvcFsBQVR4HPZmaZI1n7JsT4Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzh7f3M+yY74xSEnoPA9IrxVwLLWaJ1mzo75MvIqHF35oLnZgji
	cVGzdWIMBxnjDpIL7ulH4ssBPAiGglcgq3bfbqUgePzgvxW88VV1oPizijgN3DPwYQ==
X-Gm-Gg: ASbGncvNxQt4yz53Y78xRB6xnlchOrXvdPS7YA6KCviElBves182bMihrsNe9HSms1S
	PN18+EPGlr3HEnIAABY4E8OnH+JsZ9fE0zCVFo89EzsRr5/vF8JEpqNA14P8EbtOhCFOXVEw9NY
	cWrmt6n3XqcrAK+IZxyaE1o6CIv/+4dnLiqABLv2lGzGzBMit4y0kFId6l+OAhku1x0YYXnAWbC
	Jpg9kY0h2FIG0U0dDdiHse9Jou3DH1WWMvXKHCz12pQb0RqBjep6YAa0k91R8APot3pTdrzK1KG
	XmACtyoyS2Qvljy44oWBXkhGq+m2wclwFLYdAlTaxiUy3hiLoJQvtLoBaa4o9w==
X-Google-Smtp-Source: AGHT+IEt34VVbAATpDDkGmTk7jsEbds5xedraMlMI/OPBkqS8aNHnu7C/+v9GdsBLRqsJH0m5lvEbg==
X-Received: by 2002:a17:907:728e:b0:ad5:5198:b2ad with SMTP id a640c23a62f3a-ad55198bc52mr1800810766b.48.1747899539430;
        Thu, 22 May 2025 00:38:59 -0700 (PDT)
Message-ID: <9d16d731-c578-480b-a2ec-8761d28aed48@suse.com>
Date: Thu, 22 May 2025 09:38:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 04/14] xen/riscv: introduce init_IRQ()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <3f86f284ebccff9de877844f33c4588ac5631906.1747843009.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <3f86f284ebccff9de877844f33c4588ac5631906.1747843009.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> Implement init_IRQ() to initalize various IRQs.
> 
> Currently, this function initializes the irq_desc[] array,
> which stores IRQ descriptors containing various information
> about each IRQ, such as the type of hardware handling, whether
> the IRQ is disabled, etc.
> The initialization is basic at this point and includes setting
> IRQ_TYPE_INVALID as the IRQ type, assigning the IRQ number ( which
> is just a consequent index of irq_desc[] array ) to
> desc->irq.
> 
> Additionally, the function init_irq_data() is introduced to
> initialize the IRQ descriptors for all IRQs in the system.
> 
> Reuse defines of IRQ_TYPE_* from asm-generic/irq-dt.h.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 

> ---
>  - Add an explanatory comment about NR_IRQS definitions.
>  - Init desc->irq and desc->action before call of init_one_irq_desc().
>  - Drop "desc->action = NULL" as irq_desc[] is zero-initialized.

Just to mention: This is odd to read, as it partially invalidates the
earlier bullet point.

>  - Update the commit message: drop mention of NULLing of desc->action.

Again only for the future: Adjusting the description to match changes
being made is the expected thing (and hence doesn't need mentioning
separately, in the common case at least).

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 07:41:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:41:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993071.1376519 (Exim 4.92)
	(envelope-from )
	id 1uI0YM-0003VJ-M6; Thu, 22 May 2025 07:41:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993071.1376519; Thu, 22 May 2025 07:41: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 1uI0YM-0003VC-JV; Thu, 22 May 2025 07:41:22 +0000
Received: by outflank-mailman (input) for mailman id 993071;
 Thu, 22 May 2025 07:41:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI0YL-0003Ri-1y
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:41:21 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 263cb3e7-36e0-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 09:41:19 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-601dfef6a8dso7364949a12.1
 for ; Thu, 22 May 2025 00:41:19 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad5572f6428sm787415366b.185.2025.05.22.00.41.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 00:41: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" 
X-Inumbo-ID: 263cb3e7-36e0-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747899678; x=1748504478; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=D1GjXYXB99+XfHp9l4xA/pYZT59fXSGf+SsASpoYDTo=;
        b=HCPL45pyvE7lcVGw8AF7GWTpaVGmkPaWu+ohGFGxNaTghH46oSnpme5xlMY3o9mJeT
         e8N3S1kTE4VhjH8AJcrbcOGBypEFO+15RuW18lSLppMWT0blWzj+27/iPrvP3MkgsAwC
         HKVpJ/sIDPf0zaU1Djg11mGmMiVBkcnAuv6Roi7JOkywB3vn4YhF9WUDn179ce/sUcT6
         QTmkwNJSi/9pAiNNYYJ+awHtNu7k6+V6w8kcHRkPpNns9nsqi3ALwg7lCVafvUaSZY9a
         4LquKnWBkTYmzvbMArlwPdfXkptW7Dfam7YLVVTo/iRox2jwcLYsvpbdOv3Pv0L3FXcH
         7Tsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747899678; x=1748504478;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=D1GjXYXB99+XfHp9l4xA/pYZT59fXSGf+SsASpoYDTo=;
        b=szuYhVY9uUT4SNlr1U6Z9yacsYEoYVl3J4e2LJXs0HnB8/n4b+9ZUn2gyFcJuWH3/p
         8rJ+VIfeVy56ximqtAzFUkN3GmkjFpgwG0mcUddX3o/kVoZNmjzz8F8azlXUTkm3/2Kl
         9a7atdgDvrHjTkzIHQN5TJlHihIB/zeRccCW+r/NtvnWarW55r1vEqWPx/4k8gFRQyYt
         8vfAoVahfUMUE+ah6J8E0IuEy5i692lPsyWZlfSD/RUTU0+eZD9oCikSKfWo6NYIpxG0
         4PYRWaltfs73Oy9zhJN1dhg22mGhwMA0b95BjmYyqDibqxUYl5jLSAKzDyha+jeYYs60
         5DXA==
X-Forwarded-Encrypted: i=1; AJvYcCWWY3eQAY69ZNeICOEvxVHxYX5KUDNhg6Q/ed9laQ+Ekkaw76CXauig1SnJj4JkZ5YE9gjoLqnC+5k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzqX4iqnDRaW116UEIUVWU//oNobNmD/oRneEQ5DjZOokBcmCzJ
	z0qwf+vxTiD4wgFRptBPkL2Ri69/OH9HC4OMJ5e/pWSb5ltTDBRCCsc8Z6r7kIhWmg==
X-Gm-Gg: ASbGncsyi+zjgZsOgrgwGeZUDsh4N9U07DG6rR1Mni4j7Oh5sTrcn0KEsQcVkSH8Ymy
	Mknm5pvMdwF9/kjI+9XX5HgRlA2kCXkqJCL8XwRNyWt+zDYnBbsAhoPFuj6xPhUxr1d9H8Zf+Yb
	dqFCA5H5Ln7+vf1CnJPTkODDFTV0U5v2hvEQH6Iw/Erz08+ccieMZSRzZHwmqeEfVX4SucGQnWr
	GCtHuTzlpfmOfkPYmEmeG820O4Qae+qXsogeGfpD9W8mofufnXCnHuKeNnkbGaDP82YI78UWKUl
	cBxI1pvK0JtIC+qHdS3eKlpBUHOX/gcidRvEmeCDieWddSI/D2Ld845psaBz4A==
X-Google-Smtp-Source: AGHT+IHVCAM7O8NretBqnbWBNfVEQEG36Z4iCgxPrIT/mT41LLcYi0go2ee3PLhHRQ6vlNOweHJOXQ==
X-Received: by 2002:a17:907:6eaa:b0:ad2:4b33:ae70 with SMTP id a640c23a62f3a-ad52d55a3d8mr2313642066b.31.1747899678621;
        Thu, 22 May 2025 00:41:18 -0700 (PDT)
Message-ID: <62a084d9-5ee2-48b5-b017-3612c7116f4e@suse.com>
Date: Thu, 22 May 2025 09:41:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 05/14] xen/riscv: introduce platform_get_irq()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <1729279a0ab39e2a2f09e475c2eb48fefd4aef54.1747843009.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <1729279a0ab39e2a2f09e475c2eb48fefd4aef54.1747843009.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> platform_get_irq() recieves information about device's irq ( type
> and irq number ) from device tree node and using this information
> update irq descriptor in irq_desc[] array.
> 
> Introduce dt_irq_xlate and initialize with aplic_irq_xlate() as
> it is used by dt_device_get_irq() which is called by
> platform_get_irq().
> 
> Co-developed-by: Romain Caritey 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu May 22 07:50:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:50:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993082.1376530 (Exim 4.92)
	(envelope-from )
	id 1uI0hK-0005Gp-Gf; Thu, 22 May 2025 07:50:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993082.1376530; Thu, 22 May 2025 07:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI0hK-0005Gi-Dk; Thu, 22 May 2025 07:50:38 +0000
Received: by outflank-mailman (input) for mailman id 993082;
 Thu, 22 May 2025 07:50:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI0hJ-0005GW-6R
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:50:37 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7065e7eb-36e1-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 09:50:33 +0200 (CEST)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-acb5ec407b1so1305776766b.1
 for ; Thu, 22 May 2025 00:50:33 -0700 (PDT)
Received: from [10.1.248.227] ([80.188.125.198])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d498f18sm1030321666b.150.2025.05.22.00.50.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 00:50: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" 
X-Inumbo-ID: 7065e7eb-36e1-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747900232; x=1748505032; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=eUyGdua4W5d8JFvp3f9dAGXjC9yavNqlLQekS0f5fLw=;
        b=fjcvs0MHxPp+JAHtacB0UNJ88WfIc8oUuyyCCldqX9GD/BTfrSrZJ4+YIs3Tc1X9wX
         RqWyO0wAxTvaqM1EwfkkIjXH5aJm6Eu/ZxYtcfd/oe48HXQ/pOY3syFNOn6ZTX0S/lzQ
         00B4e2iIkn/n4wiGE3O6Crv7QifcRoAe20zyzSB2C//z8GD4gJi/tyOalBuJEwUSipj/
         BjZq66ug07JkspRQJuPXQsfbAxdjuSDR07bAfxnbAQ+tBY/i7N3DfJGLKQ3oIkh7SWCy
         qljVcxwA+6a4EGXPV+bQ4qN0wAnrnTE1PJ6iMBiKiUDci2Jbdw19dSuD+GnrA3AW8TQA
         VyAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747900232; x=1748505032;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=eUyGdua4W5d8JFvp3f9dAGXjC9yavNqlLQekS0f5fLw=;
        b=HjrMr6/nyMTQScp+I2yFVgCiwWOjJ7SjYzM1CJkrX66YoL6ZifPbOkHdYdAOuhM+ZO
         0Eci8mSANy0uITCo+Z0EP6pTQLk3nYKpaYCcXjj9kYLTroPswS76Am3j6HudvjLFCdye
         M3t0wtC4/K1sHIIeJszvxNie0naLS1jGYDANmoPUsv1jINdkE5iANPkjJT6NjDgJRCbg
         dkff68f77qmCVVBrdBziUALC9CJ8UgkvFKtrpsmmxnJ/lvXqFs5Dns9/ygwkTdlAla1o
         a2lXww83idNqGEvxOD9WAFs4Wr1njJdPMNTGNrZ6iAQurzQOrKglaHwnU/6yvbV53woG
         X4rQ==
X-Forwarded-Encrypted: i=1; AJvYcCXeWCLoR5SoUH6rr335m7y7nnDcrHUe5a0KTz3HtRgU14L1GRi6voHOxED+WqKxaVWGGx0c2onnypA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwsQKpn3O6HmpTgx9ShGGMNk6/qsqVo6+0ldAYi/UTF5QibGz0j
	IsZKZnlu9SY5F1jINS3VKxSHu9PGGz6oe1J+IDv9aiCHOipHhlHRXu7z/KNnioAUxA==
X-Gm-Gg: ASbGncsL/feYrL66Yx1VDUMfFnY+sPRIVl4qFBsLIH+ueQ9OdoldaKD9+QxMs2y0XXF
	mygK3uH3SN9k/mHRKzpdoAdB7rXO1MAhJxtAqoVIyhveJteWwOkVzviW61RVOFpOpi8FZe87jYf
	reIw2UkQxdYcxf3uSdLqjKG/TjfrntW45ZwckRhDEoPwrDOajKC3dNVfGLauMvQP7odNf/WPjmC
	ycB/zp3vEa1Cogmu80uzW/0O99bk9i5Pcnj4NKlWIPdXh+XWwYS4OjPBX+rVUhCcT2dkwPNtO3f
	GGaBnezMC71lACoEtNqx7eGC4/eq3Q/O5Hg1IBi728uKQyhuIvp0s38CActi5g==
X-Google-Smtp-Source: AGHT+IEoeKkVySC3t2E9exF62m7QFue6AAuVdnqoPW5eTPYk0KGWL+bv3vS+EQNQJ1wAyEmKjd2+qA==
X-Received: by 2002:a17:907:80b:b0:ad2:2fa8:c0a7 with SMTP id a640c23a62f3a-ad536b7c43fmr1981181466b.21.1747900232523;
        Thu, 22 May 2025 00:50:32 -0700 (PDT)
Message-ID: <12e3ad4c-b7cc-4166-940f-b2301349680c@suse.com>
Date: Thu, 22 May 2025 09:50:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 06/14] xen/riscv: dt_processor_hartid() implementation
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <5aec324c04c67ba88336244358542f3faa6726b2.1747843009.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <5aec324c04c67ba88336244358542f3faa6726b2.1747843009.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/smpboot.c
> +++ b/xen/arch/riscv/smpboot.c
> @@ -1,5 +1,8 @@
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
>  #include 

Nit: The latter insertion wants to move one line down. Yet then - isn't
xen/stdint.h sufficient here?

> @@ -14,3 +17,69 @@ void __init smp_prepare_boot_cpu(void)
>      cpumask_set_cpu(0, &cpu_possible_map);
>      cpumask_set_cpu(0, &cpu_online_map);
>  }
> +
> +/**
> + * dt_get_hartid - Get the hartid from a CPU device node
> + *
> + * @cpun: CPU number(logical index) for which device node is required
> + *
> + * Return: The hartid for the CPU node or ~0UL if not found.
> + */
> +static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
> +{
> +    const __be32 *cell;
> +    unsigned int ac;
> +    uint32_t len;
> +
> +    ac = dt_n_addr_cells(cpun);
> +    cell = dt_get_property(cpun, "reg", &len);
> +    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )

Does DT make any guarantees for this multiplication to not overflow?

> +        return ~0UL;
> +
> +    return dt_read_number(cell, ac);
> +}
> +
> +/*
> + * Returns the hartid of the given device tree node, or -ENODEV if the node
> + * isn't an enabled and valid RISC-V hart node.
> + */
> +int dt_processor_hartid(const struct dt_device_node *node,
> +                        unsigned long *hartid)
> +{
> +    const char *isa;
> +    int ret;
> +
> +    if ( !dt_device_is_compatible(node, "riscv") )
> +    {
> +        printk("Found incompatible CPU\n");
> +        return -ENODEV;
> +    }
> +
> +    *hartid = dt_get_hartid(node);
> +    if ( *hartid == ~0UL )
> +    {
> +        printk("Found CPU without CPU ID\n");
> +        return -ENODATA;
> +    }
> +
> +    if ( !dt_device_is_available(node))
> +    {
> +        printk("CPU with hartid=%lu is not available\n", *hartid);

Considering that hart ID assignment is outside of our control, would we
perhaps better (uniformly) log such using %#lx?

> +        return -ENODEV;
> +    }
> +
> +    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
> +    {
> +        printk("CPU with hartid=%lu has no \"riscv,isa\" property\n", *hartid);
> +        return ret;
> +    }
> +
> +    if ( isa[0] != 'r' || isa[1] != 'v' )
> +    {
> +        printk("CPU with hartid=%lu has an invalid ISA of \"%s\"\n", *hartid,
> +               isa);
> +        return -EINVAL;

As before -EINVAL is appropriate when input arguments have wrong values.
Here, however, you found an unexpected value in something the platform
has presented to you. While not entirely appropriate either, maybe
-ENODEV again (if nothing better can be found)?

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 07:54:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:54:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993099.1376545 (Exim 4.92)
	(envelope-from )
	id 1uI0lL-0006OF-8e; Thu, 22 May 2025 07:54:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993099.1376545; Thu, 22 May 2025 07:54: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 1uI0lL-0006Ng-3U; Thu, 22 May 2025 07:54:47 +0000
Received: by outflank-mailman (input) for mailman id 993099;
 Thu, 22 May 2025 07:54:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI0lK-0006JE-31
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:54:46 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 06c72dd9-36e2-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 09:54:45 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-442f5b3c710so63606005e9.1
 for ; Thu, 22 May 2025 00:54:45 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f73d3edcsm97786325e9.20.2025.05.22.00.54.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 00:54: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" 
X-Inumbo-ID: 06c72dd9-36e2-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747900484; x=1748505284; 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;
        bh=tt93X8/M//cm6RVXeEKC2o6v986fsxbCRkDTkmxvdfg=;
        b=keUgetdG2fXqvMvWke7zPH060AGv53DFA7JhK9UEZabeLK3L2zNtcnspkJiC1sluo3
         3oOuBgyWwXjL95okSQHgXDm4Q+voToxVpswgcTxAYBFmvgYdBv3MdW9qt2OG9pfxSEYl
         kTH5IPuV8gMte8U/NSlqH8rRoinJMppe2JQGI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747900484; x=1748505284;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=tt93X8/M//cm6RVXeEKC2o6v986fsxbCRkDTkmxvdfg=;
        b=UUym3EjWpZy6bw5oSJM2/IQFy/L5WI1bUII0rKxK3EjRnOlZNnH+mWL6Xe07WH8KcQ
         Nk7nB7kL/+3B/gfLrLsYL+g5oKcX5Pvdw5fopc3skSWNe35zpdx5snc0CXcu8QZzs+8O
         eOyonDGPnEL3hb2x7JwgYocAuEjrauNpZBaJUoTp+myMXaumVcY+yqiTckfDXilMPNKV
         /EdAnzkefhmndYznEm4pCEekjyDGwzecI+LbRjUdIvFwCrKy6A/8OYr0pWR2Ee/Qv47T
         2Ljp6KXS+bx/4VD52bdO/e5VTOJxTwuudKOubwE7Csgsxg8Jp1rzGMJXjNk13mrRbo6F
         OnVQ==
X-Gm-Message-State: AOJu0Ywxa53+IPd+Akv9Q1T4f3TZ15Gb8TBfcwXPhRMF7QrtTgOgKWn0
	JlcNn/cnsiRglg54xDmirAhkA8Ee67qJkZDmTyphOUJSHcphMOXz/WhycnSTOqNZhy+JzoC1J1m
	4bhrw
X-Gm-Gg: ASbGncu4PevKy/9aaJd6LXGaZrWKL5DIOyCRdEouUoZbnSkibdXuzo/y3UcYotwYc0Q
	t+cDs5RHB4AiEjYo99H8sihdZTJc9OgmLbHWn5rhWHmACyJkRQkwcv6WJ2uDgRn0pr8DZMh005x
	jcour8BseAQ5E5mFv7/VNLHrrxTN8cXPWO4145inBQTOdn8jejpRQUPKgMfyG6GOitxybdgB4D1
	w0eMUDQh+vvHBStmzwMkC7gT6jyQRxtB/o0Q6A2YwREXNBL2v+H6DvGtiqjSuYnmsNVDJSBlOps
	+EoDtg6sL2MdGUUDnJ4RaPA9f5gBAYLawUvmGQgXzGSYV/THcvFTiiQGEPswkQJOndzwmTmuVcE
	fU0TMQnnNBHDFw+tQSvZEuMZkVPDYOA==
X-Google-Smtp-Source: AGHT+IGhNrAr/hRUljY+8j/hvusjJZFNAobH2p1pEtgVC2wSlfpCVao6R/KxtDVBG57mG422/tHzlg==
X-Received: by 2002:a05:600c:5305:b0:441:b19c:96fe with SMTP id 5b1f17b1804b1-442fd622eb4mr288804925e9.10.1747900484472;
        Thu, 22 May 2025 00:54:44 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v2 2/4] x86/traps: remove smp_mb() ahead of IPI dispatch
Date: Thu, 22 May 2025 09:54:38 +0200
Message-ID: <20250522075440.99882-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250522075440.99882-1-roger.pau@citrix.com>
References: <20250522075440.99882-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The IPI dispatch functions should already have the required barriers to
ensure correct memory ordering.

Note other callers of send_IPI_mask() don't use any barriers.

Reported-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - New in this version.
---
 xen/arch/x86/traps.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index c94779b4ad4f..22f20629327d 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -785,8 +785,6 @@ void fatal_trap(const struct cpu_user_regs *regs, bool show_remote)
             cpumask_andnot(&show_state_mask, &cpu_online_map,
                            cpumask_of(smp_processor_id()));
             set_nmi_callback(nmi_show_execution_state);
-            /* Ensure new callback is set before sending out the NMI. */
-            smp_wmb();
             smp_send_nmi_allbutself();
 
             /* Wait at most 10ms for some other CPU to respond. */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 22 07:54:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:54:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993098.1376540 (Exim 4.92)
	(envelope-from )
	id 1uI0lL-0006Ly-06; Thu, 22 May 2025 07:54:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993098.1376540; Thu, 22 May 2025 07:54: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 1uI0lK-0006Lq-T9; Thu, 22 May 2025 07:54:46 +0000
Received: by outflank-mailman (input) for mailman id 993098;
 Thu, 22 May 2025 07:54:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI0lJ-0006LU-LY
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:54:45 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 058481f5-36e2-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 09:54:43 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43cfe574976so55742325e9.1
 for ; Thu, 22 May 2025 00:54:43 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca5a04csm21898743f8f.23.2025.05.22.00.54.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 00:54: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" 
X-Inumbo-ID: 058481f5-36e2-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747900482; x=1748505282; 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;
        bh=/9QsM4NKOwV2R5dlmGWrikes0+MG3PhOjvwu44Y10RU=;
        b=VFb0x1yulla/1WxcIzG9GktthxnJVYoaCp8Ka7hxil42xPXVlcis+BHaGLPhfvMa1C
         jW1sMTzugKTyorYQJ367tt7wU7z0cs/EP6Rc+VF72vIfoZ4WrSlo161OfSxOho421HO9
         IB6rd7QW2hzLPe+aV9Gssc1Ag7KjX83queHLw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747900482; x=1748505282;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=/9QsM4NKOwV2R5dlmGWrikes0+MG3PhOjvwu44Y10RU=;
        b=nOWoFp84OriXYpIYdnkZXxmRhNh7n5vr5TKrWXLjufnKfIatRtjbN5YL60exA97LBr
         1Db/MkXLT9y27A2SrEgMrYEKV+NWihZIdyP4dBlszcJWM0pGD1+03sT6J+i1ELyZNaWr
         0Czd/jiLg1shhJsdybjNvS13Nt/g9+OcdUhq2Auhp6ewR0cmCi2WG//r9616lytKxvQb
         Vk2vSIrA9xeobHeVTTYIKncBTHm5bnwa+YPSqyIGjtZFMqU6HvEuwAT71s5dCneWlH3t
         z/4TTo/xol/YaOojPeJj8+m8BwL1bf7mMLQw8sjHhjaS8m73Xg2/6MyaJpS2j8RhdHPl
         LUZw==
X-Gm-Message-State: AOJu0YyrD9xZIqtcHbVpHxPhieIk9Y2f/vty3LsbsuskzA+A9NlZKLRh
	rvZOZkqKo1jgKuNqenKq+3Q70c+Fvaiy08z7eS5RQX4h6HopsF6PB3RyNLR8iA1vU8Skh1cL8Yv
	i9Sfr
X-Gm-Gg: ASbGncuc20oHkb95q0TW002e2MYJAqvxISbqJE4KIOJDXwm6bqVYYMYLqZeEQb4Z71I
	+/HacVzAAS1WSklAux1ImfQlLUV/++GiH7AvgimUtm7sUKf+ix+/bErRnlj8R3BLa8d2LrAoBAl
	lR3kmtNUOnd+1oLgEs86djnqIymK8j/0b0YtYg1Jr99N3j2rLZCXasQk6pQ9UaHXpatfnc2O6Nr
	PYmMlieZTfTsPuB2pwV+GCnIIEmD7aqugW15Pn9IXao53q3glW7QwuMAblVqD+DBLL4YBRAWBg0
	wIkIiDuxWONG68TnyVXX04M2FcsuQYuHujxIusnfy/TO46/ZhUu9FH09jB5S9lcp7EyypYuouXO
	4GR9h7xb1owjrRLMeDvI=
X-Google-Smtp-Source: AGHT+IFgiLlTLphN51lEGGGXKJNhq/uJDJhi7PgykBfcB9NyDP+TqnYfXQjeTOsEorzfAEyCPC07FA==
X-Received: by 2002:a05:600c:5247:b0:442:f4a3:b5f2 with SMTP id 5b1f17b1804b1-442fd60b4e8mr201922505e9.6.1747900482262;
        Thu, 22 May 2025 00:54:42 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v2 0/4] x86/boot: provide better diagnostics in AP boot failure
Date: Thu, 22 May 2025 09:54:36 +0200
Message-ID: <20250522075440.99882-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

This series attempts to improve AP boot failure diagnosis by improving
the printed failure messages (patch 1) and detecting AP getting stuck
during bringup (patch 4).  Patches 2 and 3 are preparatory changes for
the work done in patch 4.

They should be non-functional changes for systems working correctly.

Thanks, Roger.

Roger Pau Monne (4):
  x86/boot: print CPU and APIC ID in bring up failure
  x86/traps: remove smp_mb() ahead of IPI dispatch
  x86/traps: split code to dump execution state to a separate helper
  x86/boot: attempt to print trace and panic on AP bring up stall

 xen/arch/x86/include/asm/processor.h |  1 +
 xen/arch/x86/smpboot.c               | 14 +++++-
 xen/arch/x86/traps.c                 | 64 +++++++++++++++++-----------
 3 files changed, 51 insertions(+), 28 deletions(-)

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 22 07:54:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:54:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993101.1376560 (Exim 4.92)
	(envelope-from )
	id 1uI0lN-0006p6-JR; Thu, 22 May 2025 07:54:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993101.1376560; Thu, 22 May 2025 07:54:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI0lN-0006ox-GO; Thu, 22 May 2025 07:54:49 +0000
Received: by outflank-mailman (input) for mailman id 993101;
 Thu, 22 May 2025 07:54:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI0lL-0006LU-M8
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:54:47 +0000
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com
 [2a00:1450:4864:20::42a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 061ae988-36e2-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 09:54:44 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a3683d8314so4468953f8f.3
 for ; Thu, 22 May 2025 00:54:44 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca889d9sm22233672f8f.77.2025.05.22.00.54.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 00:54: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" 
X-Inumbo-ID: 061ae988-36e2-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747900483; x=1748505283; 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;
        bh=SNt/a796h8HJ1FyF4HukdZmnJKGKgEPfZABr2Qwwqsc=;
        b=mMkuERbf3ofMtAH2Id4jK/MG79eK0JwlKdSGgqI7XiTu0fbqajjQyNdJOYBmEC/ew5
         5WL5ZyL7q1LacO1SN1ASf+3b2ADEUaroL772sNopGc/ql1+73GYCjcf1BWaQTYVNMpR9
         gq7OL+T1qG3lgay5SzM3V1PQ9qaFOXPTJYolM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747900483; x=1748505283;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=SNt/a796h8HJ1FyF4HukdZmnJKGKgEPfZABr2Qwwqsc=;
        b=cXu2rJvD4u7G+k8/9PN+Apwzvapqi0ZUfQwOKhT5GiXsqxBF1QKJb4CJXROc/v9sGL
         MSRImIRO7umqwMRSFoLkAtuveJTTqg0TdqaPrUj+8H9+5jmZFwszizxvyRjuJHOq/B/u
         MJbNkfSWZQH4B+xOd5jO8ANVPnsJdTvVHPzMMJKVCU6rtLhTAgpHR+f4XCLc01zdRsOQ
         4j80yOkuRjPS6jK5W7HRyGjYHRQGIPKCBbL5LvJbsZOfTmp9FxOAO5gYJZncOL8nYnek
         KHXZOPHtxR6A7t4I0koJfqm8g7sjleZIdZFk0VTQLx0wXtksfcJgB4cVje2IoE+Ab3N6
         81Fw==
X-Gm-Message-State: AOJu0YxgEBxXNpV+NCFOl37I0uXlV0uqdxGh0q7gWbvYfOLKwfkQctQx
	orBaaVhAiGpWnHM2kc3rzKvhmJo36SAV3YWyw5jGl/mZF8yVrEjE+BnYiQOI2If10KZCLitUys/
	QmRQL
X-Gm-Gg: ASbGncvm7q0hwWvI7qdgQ5E3AQXzXgawiWpArDOTpt2ubd3GhJ6m0tlXAoQh6bc0Nha
	QmgVjFx3BvFpUh4n/y4kdMRmrP4alR/lm5ddhWrEI8CQ0qkhJBL4a+sVb+DymyrKN/AHOeHhaJ0
	f/77mYpzFkw+IWXbHEahYjZ56st81yE3cftUVuC7zVhPOYjQdXKaVOGIImuAz7/e2OmBb568l+l
	HJJlXKv5Qxsasz2rGmFOE+9nDs+y9C78V+y+o+M5lA6QmK3JH/wnGy7jisVdXwhxN9gjFcfAEGt
	phGLRxIUTiKye3WxhWELun2CVpT8FzwfyauyTce08/BypzNh/IF3pjuHvJb5EU1Mm17HUeeWZlY
	cz0TOF3g7P7GGK44l0tJGrXy7XAmRAg==
X-Google-Smtp-Source: AGHT+IGw5ZUYXHmwfwWoYLLq3/50OjJvJxw5n7JcSFRYTWRVB29lNAxDM4fup1ovD+xAR/gqZwDlzw==
X-Received: by 2002:a05:6000:c0b:b0:3a3:5c64:c60 with SMTP id ffacd0b85a97d-3a35c84beacmr15062310f8f.59.1747900483409;
        Thu, 22 May 2025 00:54:43 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v2 1/4] x86/boot: print CPU and APIC ID in bring up failure
Date: Thu, 22 May 2025 09:54:37 +0200
Message-ID: <20250522075440.99882-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250522075440.99882-1-roger.pau@citrix.com>
References: <20250522075440.99882-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Print the CPU and APIC ID that fails to respond to the init sequence, or
that didn't manage to reach the "callin" state.  Expand a bit the printed
error messages.  Otherwise the "Not responding." message is not easy to
understand by users.

Reported-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Also print APIC ID.
---
 xen/arch/x86/smpboot.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 0189d6c332a4..dbc2f2f1d411 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -618,10 +618,12 @@ static int do_boot_cpu(int apicid, int cpu)
             smp_mb();
             if ( bootsym(trampoline_cpu_started) == 0xA5 )
                 /* trampoline started but...? */
-                printk("Stuck ??\n");
+                printk("CPU%u/APICID%u: Didn't finish startup sequence\n",
+                       cpu, apicid);
             else
                 /* trampoline code not run */
-                printk("Not responding.\n");
+                printk("CPU%u/APICID%u: Not responding to startup\n",
+                       cpu, apicid);
         }
     }
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 22 07:54:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:54:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993102.1376570 (Exim 4.92)
	(envelope-from )
	id 1uI0lO-00074M-QR; Thu, 22 May 2025 07:54:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993102.1376570; Thu, 22 May 2025 07: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 1uI0lO-00074F-MH; Thu, 22 May 2025 07:54:50 +0000
Received: by outflank-mailman (input) for mailman id 993102;
 Thu, 22 May 2025 07:54:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI0lM-0006LU-MC
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:54:48 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 07614e74-36e2-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 09:54:46 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-442f5b3c710so63606155e9.1
 for ; Thu, 22 May 2025 00:54:46 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f78aeb8csm93578185e9.28.2025.05.22.00.54.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 00:54: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" 
X-Inumbo-ID: 07614e74-36e2-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747900485; x=1748505285; 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;
        bh=AzhHFn9O4oOU3Qn2JobHAp8hOeRtdX5BhB0MX7qBcDI=;
        b=LAQw2uPbrKsK3NSB3RJ3ZUi+NCN01DVBvZsKN0gXgKI/4rVNOMEsog5EUJP78qD2y+
         A8NvO+cCROEguh31ireqZKfmku7nPtqUaK6lt55J8BLsHqW+IM10nP9T/Xw6xjn3vQ8u
         wdq7PwkrOu59u1QAgjLnF28Yz0HrOKBScA3K8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747900485; x=1748505285;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=AzhHFn9O4oOU3Qn2JobHAp8hOeRtdX5BhB0MX7qBcDI=;
        b=K6DKIx/uBfS0iIz/Bb7C58R5bmpxBXk0Ox/6jzP2c+zIROjtl6pBR2FoRk+GeiNErC
         TR7R1xqDD9WamWmUQAfIv+9Or8nWY+ubWIob+ponR5LLgvcUsDU3iDmj84zSgnDHSUI3
         MvgRj5AvFLHKXMF6tdVaqvTchtq53vYVeGGoC2qx4P/JLx6Hfs40ucTB+kEyWM1dasz+
         L3I1aKLVGJNd35Hj0kg9jPU7Sf8DCBQftseHxTlHGQWFi6rtbGxIs1oIUydn4cera03G
         2oDHzoSMtXZQI+cpBNTdVUen2DD3Vlw40in8VaRhiopEUDSp9D+RLm5HNOrFInRRkeJx
         ebYg==
X-Gm-Message-State: AOJu0Yxd4rWDjKGSsG61j9ReIk+vD6q3vJzXZIoWyaJqzMjgHn0exMU1
	KNavkaCeoxQawOcdwKTcW/tSBVVJWpNATdEqyOcGXttRymsnvkMhnHKNd/6hg0w27byHrp241OG
	/Mbwb
X-Gm-Gg: ASbGncui1J14wl/YKRnb4oPDhZpnX1TmQ07FIrrqDnmLzEDFmTEW2IHaBUwbHe6d9bC
	mTtQ320Q/h3IKLPDXkTw50U5RJlc1k99ZeO1LLAR7XU2UiJGmq6irIsCZv/gp/wsI2FbH2By6XU
	LYBGBCyqf/bD+Nuxm2/2YQj6HJpIvnTkCZvc31jGLycUzbZnIn03SvxVdKQ4GYguIOQAYGVtnRU
	lo7l3cIn8tpfdjHcfAXCERrHK2UR3rQR0QSL4jAGJH35rUiFminfTtm2vLkbfPEbXXT+O6cD+hw
	lNP91vgT563HDEh9IESN7T5RkC+agst93FiNIeKI4BH81ifQ0mNyJQDzS7EqCJlsWGjiRknCHq/
	AzMzurNeuv8+q4dkHA6E=
X-Google-Smtp-Source: AGHT+IG61P+oaIK9VJw8B2DaXk4AiHjU8pknx0c2hQqVWKmmd8kHow/r6+OtNqaQNz/VBb1nqJEi6g==
X-Received: by 2002:a05:600c:628c:b0:43d:b32:40aa with SMTP id 5b1f17b1804b1-442fd60a536mr247845445e9.3.1747900485527;
        Thu, 22 May 2025 00:54:45 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v2 3/4] x86/traps: split code to dump execution state to a separate helper
Date: Thu, 22 May 2025 09:54:39 +0200
Message-ID: <20250522075440.99882-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250522075440.99882-1-roger.pau@citrix.com>
References: <20250522075440.99882-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Split the code that triggers remote CPUs to dump stacks into a separate
function.  Also introduce a parameter that can be set by the caller of the
newly introduced function to force CPUs to dump the full stack, rather than
just dumping the current function name.

No functional change intended.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/include/asm/processor.h |  1 +
 xen/arch/x86/traps.c                 | 62 +++++++++++++++++-----------
 2 files changed, 39 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index eacd425c5350..10d8078cc1ca 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -371,6 +371,7 @@ void show_registers(const struct cpu_user_regs *regs);
 #define dump_execution_state() run_in_exception_handler(show_execution_state)
 void show_page_walk(unsigned long addr);
 void noreturn fatal_trap(const struct cpu_user_regs *regs, bool show_remote);
+void show_execution_state_nmi(const cpumask_t *mask, bool show_all);
 
 extern void mtrr_ap_init(void);
 extern void mtrr_bp_init(void);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 22f20629327d..f6646d505644 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -714,13 +714,15 @@ static cpumask_t show_state_mask;
 static bool opt_show_all;
 boolean_param("async-show-all", opt_show_all);
 
+static bool force_show_all;
+
 static int cf_check nmi_show_execution_state(
     const struct cpu_user_regs *regs, int cpu)
 {
     if ( !cpumask_test_cpu(cpu, &show_state_mask) )
         return 0;
 
-    if ( opt_show_all )
+    if ( opt_show_all || force_show_all )
         show_execution_state(regs);
     else if ( guest_mode(regs) )
         printk(XENLOG_ERR "CPU%d\t%pv\t%04x:%p in guest\n",
@@ -734,6 +736,38 @@ static int cf_check nmi_show_execution_state(
     return 1;
 }
 
+void show_execution_state_nmi(const cpumask_t *mask, bool show_all)
+{
+    unsigned int msecs, pending;
+
+    force_show_all = show_all;
+
+    watchdog_disable();
+    console_start_sync();
+
+    cpumask_copy(&show_state_mask, mask);
+    set_nmi_callback(nmi_show_execution_state);
+    send_IPI_mask(mask, APIC_DM_NMI);
+
+    /* Wait at most 10ms for some other CPU to respond. */
+    msecs = 10;
+    pending = cpumask_weight(&show_state_mask);
+    while ( pending && msecs-- )
+    {
+        unsigned int left;
+
+        mdelay(1);
+        left = cpumask_weight(&show_state_mask);
+        if ( left < pending )
+        {
+            pending = left;
+            msecs = 10;
+        }
+    }
+    if ( pending )
+        printk("Non-responding CPUs: {%*pbl}\n", CPUMASK_PR(&show_state_mask));
+}
+
 const char *vector_name(unsigned int vec)
 {
     static const char names[][4] = {
@@ -780,31 +814,11 @@ void fatal_trap(const struct cpu_user_regs *regs, bool show_remote)
 
         if ( show_remote )
         {
-            unsigned int msecs, pending;
+            cpumask_t *scratch = this_cpu(scratch_cpumask);
 
-            cpumask_andnot(&show_state_mask, &cpu_online_map,
+            cpumask_andnot(scratch, &cpu_online_map,
                            cpumask_of(smp_processor_id()));
-            set_nmi_callback(nmi_show_execution_state);
-            smp_send_nmi_allbutself();
-
-            /* Wait at most 10ms for some other CPU to respond. */
-            msecs = 10;
-            pending = cpumask_weight(&show_state_mask);
-            while ( pending && msecs-- )
-            {
-                unsigned int left;
-
-                mdelay(1);
-                left = cpumask_weight(&show_state_mask);
-                if ( left < pending )
-                {
-                    pending = left;
-                    msecs = 10;
-                }
-            }
-            if ( pending )
-                printk("Non-responding CPUs: {%*pbl}\n",
-                       CPUMASK_PR(&show_state_mask));
+            show_execution_state_nmi(scratch, false);
         }
     }
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 22 07:54:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 07:54:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993103.1376575 (Exim 4.92)
	(envelope-from )
	id 1uI0lP-00077E-40; Thu, 22 May 2025 07:54:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993103.1376575; Thu, 22 May 2025 07:54: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 1uI0lO-00076S-UX; Thu, 22 May 2025 07:54:50 +0000
Received: by outflank-mailman (input) for mailman id 993103;
 Thu, 22 May 2025 07:54:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI0lN-0006LU-ME
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 07:54:49 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 083f4952-36e2-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 09:54:47 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a4bdee0bf7so238247f8f.1
 for ; Thu, 22 May 2025 00:54:47 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca5a892sm21774670f8f.24.2025.05.22.00.54.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 00:54: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" 
X-Inumbo-ID: 083f4952-36e2-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747900486; x=1748505286; 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;
        bh=AWtufX/fZJTkl4t/yBYN+P8J2qIQZH/xOV2FrRV6Hek=;
        b=N11JkwK+cstNd/PQ/n+Zpa05GWWNOw4jq37pyZcLxwowvRjKW+4y3a9quDdxXg7JFJ
         XoyqPfx8DUfov51sZYpnhNIANam9Axw2Pg2ROXadrtozeVXIFf0DYpIUv9tTiB6V2x5s
         cTV1jXDF95jUN4w0XXduJIn78MgyN9Oy9K6nM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747900486; x=1748505286;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=AWtufX/fZJTkl4t/yBYN+P8J2qIQZH/xOV2FrRV6Hek=;
        b=B5Xq/1kj2fXHzBUZ6jGGpJ2QVUDmMcpyzQpKfXgotkdcqj5SaHaXSOxrzgvUM8hNSp
         mLkVKJRtlK4zXJzM7AOTknxqFby18mgoOnGkNxFx3d9un1FS5/87AsVBtiyAqLuZVqYW
         Si5OweUkaUwo5yjUTE6If/K+RjwSNjJnZUVC23WxbG2nYGeaqxFrBWFg/Z6qmVN0L5CG
         ijVSYuu1r4S4yGRwYAltZkzjD5yn/lfORAQKCH/3TnQgpk5j8P3NM2/LXUdQZY8Nph/R
         AZX5bBdEOvZobdlVIObbVeAvJGgM5M7ze25tK+0mwZFaOBcmlrDqdx7OM26RLzvBTAvK
         GcEQ==
X-Gm-Message-State: AOJu0YyBQ4/4B5WonlYCDWYVg3oJnX9hDvXdqK0+6K3J6+vPq47C4oyo
	T44zZcjm6PIDw2ObBDfLglntHiopMwA7oqI47Dkh4TXSMxghs9/ZJn4Zy4Psi8QiWMuHu9S4vnS
	Fq3yz
X-Gm-Gg: ASbGncuoIQxRrUMZSwxNOnoXD/5uOwyl0JFJ3GK485SFFA+XH18zN/NXUyKkkR8AV8m
	I1XHUDsCO55SpP2UZoIz8k51l/A5mm2aYFVUsWN161Fn9TdbQnT4b0nm7maf9W3BYUkZQ6MpVX3
	9ho8O8K8abotHmBRdjPBafP3Ozv/KqDXEK1Cgbiqxf6hLjBnEaVBIlVp20cuA/eksukG2CqjfaT
	t57XKha84lWPyQ/q3DAaBJBE59h7u03r8O5jOOw3T8xOC2/LXzasH0uPMjGNvdPEjogmVEM/31b
	4ud5zpvdU2jBIFMCOuOvJ9/HrpzemsoTv22yH6cRXIpj/rWMHcFgi6Mf0YqR7i8Mi+wBocdVISK
	i2ca+uHLs93gmeKxznH13aQcJ7L32QQ==
X-Google-Smtp-Source: AGHT+IEdIbVsdISUuEN4SVsoPfQG2xeQf8EhvNBS7jzQTibsGDg+6/qOpvLZsSWIvjZBCOZv6m8qOg==
X-Received: by 2002:a05:6000:22c7:b0:3a3:6cf9:9b58 with SMTP id ffacd0b85a97d-3a36cf99c63mr12895366f8f.20.1747900486560;
        Thu, 22 May 2025 00:54:46 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v2 4/4] x86/boot: attempt to print trace and panic on AP bring up stall
Date: Thu, 22 May 2025 09:54:40 +0200
Message-ID: <20250522075440.99882-5-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250522075440.99882-1-roger.pau@citrix.com>
References: <20250522075440.99882-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With the current AP bring up code, Xen can get stuck indefinitely if an AP
freezes during boot after the 'callin' step.  Introduce a 5s timeout while
waiting for APs to finish startup.

On failure of an AP to complete startup, send an NMI to trigger the
printing of a stack backtrace on the stuck AP and panic on the BSP.

This patch was done while investigating the issue caused by Intel erratum
ICX143.  It wasn't helpful in that case, but it's still and improvement
when debugging AP bring up related issues.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Use 5s timeout.
 - Print APICID.
 - Split NMI dispatch code movement to a pre-patch.
 - Reorder timeout check condition.
---
 xen/arch/x86/smpboot.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index dbc2f2f1d411..50c5674555e4 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1372,6 +1372,7 @@ int cpu_add(uint32_t apic_id, uint32_t acpi_id, uint32_t pxm)
 int __cpu_up(unsigned int cpu)
 {
     int apicid, ret;
+    s_time_t start;
 
     if ( (apicid = x86_cpu_to_apicid[cpu]) == BAD_APICID )
         return -ENODEV;
@@ -1390,10 +1391,17 @@ int __cpu_up(unsigned int cpu)
     time_latch_stamps();
 
     set_cpu_state(CPU_STATE_ONLINE);
+    start = NOW();
     while ( !cpu_online(cpu) )
     {
         cpu_relax();
         process_pending_softirqs();
+        if ( (NOW() - start) > SECONDS(5) )
+        {
+            /* AP is stuck, send NMI and panic. */
+            show_execution_state_nmi(cpumask_of(cpu), true);
+            panic("CPU%u/APICID%u: Stuck while starting up\n", cpu, apicid);
+        }
     }
 
     return 0;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 22 08:00:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:00:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993133.1376591 (Exim 4.92)
	(envelope-from )
	id 1uI0qw-00024V-T6; Thu, 22 May 2025 08:00:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993133.1376591; Thu, 22 May 2025 08:00: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 1uI0qw-00024O-Ok; Thu, 22 May 2025 08:00:34 +0000
Received: by outflank-mailman (input) for mailman id 993133;
 Thu, 22 May 2025 08:00:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI0qv-00024I-LK
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:00:33 +0000
Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com
 [2607:f8b0:4864:20::a33])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d4879ad9-36e2-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 10:00:31 +0200 (CEST)
Received: by mail-vk1-xa33.google.com with SMTP id
 71dfb90a1353d-52d9a275c27so5002725e0c.0
 for ; Thu, 22 May 2025 01:00: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" 
X-Inumbo-ID: d4879ad9-36e2-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747900830; x=1748505630; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=a0ANtDmhC85QqsrPkwAYqYXWbxfJ8i+/FZVdm/ElQk4=;
        b=PWCaKWgGgyAWgINbcXcbD8WGYzTsd8WPxHNRUiRdqAzfK9wfTVB9qGAuF9hU48Z4Kz
         kf2+LA4O7OQbaeOCYjaGpy51THzZUMlxRpMmaFtERzlRpyTMuOiNmNbxCmOxRm+97uxH
         fLtSgxf0V+wuo6HzTltUt5Kz+JezEP2Y7kkPabRX+VMsTkdmVAUYlRhJMP1fcKTtsham
         iPDoEvhz274zpWgtI8YfBqzolr9uh0mESVBGinu+vzwbkC9NJWhMvNNYvpcTa/JnhGuM
         vuv23lUPTfs1n6N4AGoV+muJ1kSfv+blSgsg598PdxHfP46ZlKGk9Amz9JSNpP98af16
         xVUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747900830; x=1748505630;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=a0ANtDmhC85QqsrPkwAYqYXWbxfJ8i+/FZVdm/ElQk4=;
        b=NXEI/Fr2sxoBfDW8lSDjgWcoAXdaRMohn+xsqUmGHT3Cey7+9qVLdEYgMgivmBrAd9
         FOByDVZ5djd99OAaeGL81mTEFpovQjCkVWQzG0g57s4C+XiF78hmW2bZJHczDLkPG0zy
         LVZjOMIsnhcn5prMxbdHbnqsAo0Twfmz4w81IPEMLsQm+1W3uCs+bTUfT7IYk80Mwqym
         qo/An/1WlhEq44OMlJfEXv20eEh3fv75OwATy1cYK6ys90PQKcQEMEDfz8LVzYj5WgXS
         33SeOp9V8AtLphUYiBCkHjRO02G1A7WSVdDZ5KIQHBofOFsvzZ7wqOwcJFsH8QIb2TcW
         nzcw==
X-Gm-Message-State: AOJu0YxURTb9ctGDHOHKQErrV52LrRSf9F5bJw7xy/NO9jYEvdPtlyMU
	EFY6ECxYtGCzaSnsJ7Uro85ASLrkP5KL/z1z4z+1i71rUC5hTIot65Uo0PQOrU77/xL0ltQmYXE
	P1vgKHV3RMbUCb/8NMBg1iemU1J94Zj/bSEe052lBhCbhMi77jzMqN5s=
X-Gm-Gg: ASbGncvELOffe2xrrg3w/OK7mInPCmk4aZuJWfsbSQGVKvpQqYVfxP3m6vYL6feyQXg
	f8cZxmc6yD8JGbOyJZFxRudS47XKnFUVDFdaPfFwlehscUArr7lk+dLABR0Xe2yozkzqyyzCCKt
	AC5NTHqtM9ZlLxrmkrWmT9Sp/TNjVch9AN1aJ3y8wKqGI3
X-Google-Smtp-Source: AGHT+IGdj6Uo2f+U1JrZ1x5Zi+XcBtkVYej0WVySL9D9CZqytzref130/YnSAmWDWvGX0Z1IGq1RtoCB+l+8+1YeD6U=
X-Received: by 2002:a05:6808:8415:b0:401:e8a2:76f1 with SMTP id
 5614622812f47-404d863ceecmr14728485b6e.8.1747900819786; Thu, 22 May 2025
 01:00:19 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Jens Wiklander 
Date: Thu, 22 May 2025 10:00:07 +0200
X-Gm-Features: AX0GCFtd0FL6s2QGaNY8INBsNUamZM5QZWklI6dV-jcth4u6_T7Jq_zO_G54X6U
Message-ID: 
Subject: Re: [PATCH v5 6/6] xen/arm: ffa: Enable VM to VM without firmware
To: Bertrand Marquis 
Cc: xen-devel@lists.xenproject.org, 
	Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Michal Orzel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bertrand,

On Wed, Apr 16, 2025 at 9:40=E2=80=AFAM Bertrand Marquis
 wrote:
>
> When VM to VM support is activated and there is no suitable FF-A support
> in the firmware, enable FF-A support for VMs to allow using it for VM to
> VM communications.
> If there is OP-TEE running in the secure world and using the non FF-A
> communication system, having CONFIG_FFA_VM_TO_VM could be non functional
> (if optee is probed first) or OP-TEE could be non functional (if FF-A is
> probed first) so it is not recommended to activate the configuration
> option for such systems.
>
> To make buffer full notification work between VMs when there is no
> firmware, rework the notification handling and modify the global flag to
> only be used as check for firmware notification support instead.
>
> Signed-off-by: Bertrand Marquis 
> ---
> Changes in v5:
> - init ctx list when there is no firmware
> - rework init a bit to prevent duplicates
> - Remove Jens R-b due to changes done
> Changes in v4:
> - Fix Optee to OP-TEE in commit message
> - Add Jens R-b
> Changes in v3:
> - fix typos in commit message
> - add spaces around <<
> - move notification id fix back into buffer full patch
> - fix | position in if
> Changes in v2:
> - replace ifdef with IS_ENABLED when possible
> ---
>  xen/arch/arm/tee/ffa.c       |  24 ++++++--
>  xen/arch/arm/tee/ffa_notif.c | 104 ++++++++++++++++-------------------
>  2 files changed, 67 insertions(+), 61 deletions(-)
>
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index c1c4c0957091..b86c88cefa8c 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -342,8 +342,9 @@ static int ffa_domain_init(struct domain *d)
>      struct ffa_ctx *ctx;
>      int ret;
>
> -    if ( !ffa_fw_version )
> +    if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !ffa_fw_version )
>          return -ENODEV;
> +
>      /*
>       * We are using the domain_id + 1 as the FF-A ID for VMs as FF-A ID =
0 is
>       * reserved for the hypervisor and we only support secure endpoints =
using
> @@ -579,11 +580,8 @@ static bool ffa_probe(void)
>          goto err_rxtx_destroy;
>
>      ffa_notif_init();
> -    INIT_LIST_HEAD(&ffa_teardown_head);
> -    INIT_LIST_HEAD(&ffa_ctx_head);
> -    init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NULL, 0=
);
>
> -    return true;
> +    goto exit;
>
>  err_rxtx_destroy:
>      ffa_rxtx_destroy();
> @@ -592,6 +590,22 @@ err_no_fw:
>      bitmap_zero(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
>      printk(XENLOG_WARNING "ARM FF-A No firmware support\n");
>
> +exit:
> +    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) || ffa_fw_version )
> +    {
> +        INIT_LIST_HEAD(&ffa_teardown_head);
> +        INIT_LIST_HEAD(&ffa_ctx_head);
> +        init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NUL=
L, 0);
> +    }
> +
> +    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> +    {
> +        printk(XENLOG_INFO "ARM FF-A only available between VMs\n");

This should only be printed if ffa_fw_version =3D=3D 0

> +        return true;
> +    }
> +    else if ( ffa_fw_version )

The else isn't needed.

Cheers,
Jens

> +        return true;
> +
>      return false;
>  }
>
> diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c
> index f6df2f15bb00..86bef6b3b2ab 100644
> --- a/xen/arch/arm/tee/ffa_notif.c
> +++ b/xen/arch/arm/tee/ffa_notif.c
> @@ -16,7 +16,7 @@
>
>  #include "ffa_private.h"
>
> -static bool __ro_after_init notif_enabled;
> +static bool __ro_after_init fw_notif_enabled;
>  static unsigned int __ro_after_init notif_sri_irq;
>
>  int ffa_handle_notification_bind(struct cpu_user_regs *regs)
> @@ -27,21 +27,17 @@ int ffa_handle_notification_bind(struct cpu_user_regs=
 *regs)
>      uint32_t bitmap_lo =3D get_user_reg(regs, 3);
>      uint32_t bitmap_hi =3D get_user_reg(regs, 4);
>
> -    if ( !notif_enabled )
> -        return FFA_RET_NOT_SUPPORTED;
> -
>      if ( (src_dst & 0xFFFFU) !=3D ffa_get_vm_id(d) )
>          return FFA_RET_INVALID_PARAMETERS;
>
>      if ( flags )    /* Only global notifications are supported */
>          return FFA_RET_DENIED;
>
> -    /*
> -     * We only support notifications from SP so no need to check the sen=
der
> -     * endpoint ID, the SPMC will take care of that for us.
> -     */
> -    return ffa_simple_call(FFA_NOTIFICATION_BIND, src_dst, flags, bitmap=
_lo,
> -                           bitmap_hi);
> +    if ( FFA_ID_IS_SECURE(src_dst >> 16) && fw_notif_enabled )
> +        return ffa_simple_call(FFA_NOTIFICATION_BIND, src_dst, flags,
> +                               bitmap_lo, bitmap_hi);
> +
> +    return FFA_RET_NOT_SUPPORTED;
>  }
>
>  int ffa_handle_notification_unbind(struct cpu_user_regs *regs)
> @@ -51,18 +47,14 @@ int ffa_handle_notification_unbind(struct cpu_user_re=
gs *regs)
>      uint32_t bitmap_lo =3D get_user_reg(regs, 3);
>      uint32_t bitmap_hi =3D get_user_reg(regs, 4);
>
> -    if ( !notif_enabled )
> -        return FFA_RET_NOT_SUPPORTED;
> -
>      if ( (src_dst & 0xFFFFU) !=3D ffa_get_vm_id(d) )
>          return FFA_RET_INVALID_PARAMETERS;
>
> -    /*
> -     * We only support notifications from SP so no need to check the
> -     * destination endpoint ID, the SPMC will take care of that for us.
> -     */
> -    return  ffa_simple_call(FFA_NOTIFICATION_UNBIND, src_dst, 0, bitmap_=
lo,
> -                            bitmap_hi);
> +    if ( FFA_ID_IS_SECURE(src_dst >> 16) && fw_notif_enabled )
> +        return  ffa_simple_call(FFA_NOTIFICATION_UNBIND, src_dst, 0, bit=
map_lo,
> +                                bitmap_hi);
> +
> +    return FFA_RET_NOT_SUPPORTED;
>  }
>
>  void ffa_handle_notification_info_get(struct cpu_user_regs *regs)
> @@ -71,7 +63,7 @@ void ffa_handle_notification_info_get(struct cpu_user_r=
egs *regs)
>      struct ffa_ctx *ctx =3D d->arch.tee;
>      bool notif_pending;
>
> -    if ( !notif_enabled )
> +    if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !fw_notif_enabled )
>      {
>          ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>          return;
> @@ -108,7 +100,7 @@ void ffa_handle_notification_get(struct cpu_user_regs=
 *regs)
>      uint32_t w6 =3D 0;
>      uint32_t w7 =3D 0;
>
> -    if ( !notif_enabled )
> +    if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !fw_notif_enabled )
>      {
>          ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>          return;
> @@ -120,7 +112,8 @@ void ffa_handle_notification_get(struct cpu_user_regs=
 *regs)
>          return;
>      }
>
> -    if ( flags & ( FFA_NOTIF_FLAG_BITMAP_SP | FFA_NOTIF_FLAG_BITMAP_SPM =
) )
> +    if ( fw_notif_enabled && (flags & ( FFA_NOTIF_FLAG_BITMAP_SP |
> +                                        FFA_NOTIF_FLAG_BITMAP_SPM )) )
>      {
>          struct arm_smccc_1_2_regs arg =3D {
>              .a0 =3D FFA_NOTIFICATION_GET,
> @@ -177,15 +170,14 @@ int ffa_handle_notification_set(struct cpu_user_reg=
s *regs)
>      uint32_t bitmap_lo =3D get_user_reg(regs, 3);
>      uint32_t bitmap_hi =3D get_user_reg(regs, 4);
>
> -    if ( !notif_enabled )
> -        return FFA_RET_NOT_SUPPORTED;
> -
>      if ( (src_dst >> 16) !=3D ffa_get_vm_id(d) )
>          return FFA_RET_INVALID_PARAMETERS;
>
> -    /* Let the SPMC check the destination of the notification */
> -    return ffa_simple_call(FFA_NOTIFICATION_SET, src_dst, flags, bitmap_=
lo,
> -                           bitmap_hi);
> +    if ( FFA_ID_IS_SECURE(src_dst >> 16) && fw_notif_enabled )
> +        return ffa_simple_call(FFA_NOTIFICATION_SET, src_dst, flags, bit=
map_lo,
> +                               bitmap_hi);
> +
> +    return FFA_RET_NOT_SUPPORTED;
>  }
>
>  #ifdef CONFIG_FFA_VM_TO_VM
> @@ -371,7 +363,7 @@ void ffa_notif_init_interrupt(void)
>  {
>      int ret;
>
> -    if ( notif_enabled && notif_sri_irq < NR_GIC_SGI )
> +    if ( fw_notif_enabled && notif_sri_irq < NR_GIC_SGI )
>      {
>          /*
>           * An error here is unlikely since the primary CPU has already
> @@ -402,41 +394,41 @@ void ffa_notif_init(void)
>      int ret;
>
>      /* Only enable fw notification if all ABIs we need are supported */
> -    if ( !(ffa_fw_supports_fid(FFA_NOTIFICATION_BITMAP_CREATE) &&
> -           ffa_fw_supports_fid(FFA_NOTIFICATION_BITMAP_DESTROY) &&
> -           ffa_fw_supports_fid(FFA_NOTIFICATION_GET) &&
> -           ffa_fw_supports_fid(FFA_NOTIFICATION_INFO_GET_64)) )
> -        return;
> -
> -    arm_smccc_1_2_smc(&arg, &resp);
> -    if ( resp.a0 !=3D FFA_SUCCESS_32 )
> -        return;
> -
> -    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 request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL);
> -    if ( ret )
> +    if ( ffa_fw_supports_fid(FFA_NOTIFICATION_BITMAP_CREATE) &&
> +         ffa_fw_supports_fid(FFA_NOTIFICATION_BITMAP_DESTROY) &&
> +         ffa_fw_supports_fid(FFA_NOTIFICATION_GET) &&
> +         ffa_fw_supports_fid(FFA_NOTIFICATION_INFO_GET_64) )
>      {
> -        printk(XENLOG_ERR "ffa: request_irq irq %u failed: error %d\n",
> -               irq, ret);
> -        return;
> -    }
> +        arm_smccc_1_2_smc(&arg, &resp);
> +        if ( resp.a0 !=3D FFA_SUCCESS_32 )
> +            return;
>
> -    notif_enabled =3D true;
> +        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 request_irq(irq, 0, notif_irq_handler, "FF-A notif", NUL=
L);
> +        if ( ret )
> +        {
> +            printk(XENLOG_ERR "ffa: request_irq irq %u failed: error %d\=
n",
> +                   irq, ret);
> +            return;
> +        }
> +        fw_notif_enabled =3D true;
> +    }
>  }
>
>  int ffa_notif_domain_init(struct domain *d)
>  {
>      int32_t res;
>
> -    if ( !notif_enabled )
> -        return 0;
> +    if ( fw_notif_enabled )
> +    {
>
> -    res =3D ffa_notification_bitmap_create(ffa_get_vm_id(d), d->max_vcpu=
s);
> -    if ( res )
> -        return -ENOMEM;
> +        res =3D ffa_notification_bitmap_create(ffa_get_vm_id(d), d->max_=
vcpus);
> +        if ( res )
> +            return -ENOMEM;
> +    }
>
>      return 0;
>  }
> @@ -447,6 +439,6 @@ void ffa_notif_domain_destroy(struct domain *d)
>       * Call bitmap_destroy even if bitmap create failed as the SPMC will
>       * return a DENIED error that we will ignore.
>       */
> -    if ( notif_enabled )
> +    if ( fw_notif_enabled )
>          ffa_notification_bitmap_destroy(ffa_get_vm_id(d));
>  }
> --
> 2.47.1
>


From xen-devel-bounces@lists.xenproject.org Thu May 22 08:11:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:11:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993158.1376599 (Exim 4.92)
	(envelope-from )
	id 1uI11T-0004dr-Vc; Thu, 22 May 2025 08:11:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993158.1376599; Thu, 22 May 2025 08:11: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 1uI11T-0004dk-T1; Thu, 22 May 2025 08:11:27 +0000
Received: by outflank-mailman (input) for mailman id 993158;
 Thu, 22 May 2025 08:11:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI11R-0004cJ-4C
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:11:26 +0000
Received: from gw3.antarean.org (gw3.antarean.org [84.247.13.64])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 59eb6b71-36e4-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 10:11:23 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by gw3.antarean.org (Postfix) with ESMTP id 4b31GW5k4HzNlQR
 for ; Thu, 22 May 2025 10:11:47 +0200 (CEST)
Received: from gw3.antarean.org ([127.0.0.1])
 by localhost (gw3.antarean.org [127.0.0.1]) (amavis, port 10024) with ESMTP
 id ovcKAOQtRooR for ;
 Thu, 22 May 2025 10:11:47 +0200 (CEST)
Received: from mailstore1.adm.antarean.org (localhost [127.0.0.1])
 by gw3.antarean.org (Postfix) with ESMTP id 4b31GW527vzNkFp
 for ; Thu, 22 May 2025 10:11:47 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
 by mailstore1.adm.antarean.org (Postfix) with ESMTP id 4b31G321P6z1G
 for ; Thu, 22 May 2025 08:11:23 +0000 (UTC)
Received: from mailstore1.adm.antarean.org ([127.0.0.1])
 by localhost (mailstore1.adm.antarean.org [127.0.0.1]) (amavis, port 10024)
 with ESMTP id rdsdahx-dfrs for ;
 Thu, 22 May 2025 08:11:22 +0000 (UTC)
Received: from f2b978515ea2 (web2.adm.antarean.org [10.55.16.79])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mailstore1.adm.antarean.org (Postfix) with ESMTPSA id 4b31G23YDDz17
 for ; Thu, 22 May 2025 08:11: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" 
X-Inumbo-ID: 59eb6b71-36e4-11f0-a2fb-13f23c93f187
X-Virus-Scanned: amavis at antarean.org
X-Virus-Scanned: amavis at antarean.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=antarean.org;
	s=default; t=1747901482;
	bh=wWHwIbSNvrwUct4+MsbF+SOreN5QqKjn7jqnbTORdbk=;
	h=From:To:Subject:Date;
	b=AauUUEKicYbNWsdTAwJu8xrMSsW6e5/zpecAQ733Pql5Rrewf++ef/XuimwYxqvH6
	 dIeutIrUx8EhRRyhm7jJBRfqPY3mfqGDp5y+xwpo1ixO+FmF9UH5RWh0DwZT6VplML
	 YvAzM36hoJsyv1sMZ+DKEEAKOf55OqpgHb3vQQLU=
User-Agent: EGroupware API 23.1.011
From: Joost Roeleveld 
X-Priority: 3
X-Mailer: EGroupware-Mail
To: xen-devel@lists.xenproject.org
Subject: xen-users mailing list? (Apologies for sending this here)
Message-ID: <20250522081122.EGroupware.g0gOPwanFzfUtefaocj94UN@egw.antarean.nl>
Date: Thu, 22 May 2025 08:11:22 +0000
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0

Hi all,

I am not sure where to send this, but as this list seems to still  
work, I'll try here.
I am not receiving any emails from the xen-users mailing list since  
the 13th and my email I sent yesterday doesn't even show up in the  
archive.
I tried re-subscribing, but according to the mail I received, I am  
still subscribed.

Can someone look into this and/or tell me where to reach out for this? :)

Many thanks,

Joost





From xen-devel-bounces@lists.xenproject.org Thu May 22 08:12:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:12:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993164.1376609 (Exim 4.92)
	(envelope-from )
	id 1uI12c-0005J5-8A; Thu, 22 May 2025 08:12:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993164.1376609; Thu, 22 May 2025 08:12:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI12c-0005Iy-5O; Thu, 22 May 2025 08:12:38 +0000
Received: by outflank-mailman (input) for mailman id 993164;
 Thu, 22 May 2025 08:12:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI12b-0005Io-AM
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:12:37 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20627.outbound.protection.outlook.com
 [2a01:111:f403:2414::627])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8427a83e-36e4-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 10:12:35 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by MN0PR12MB6295.namprd12.prod.outlook.com (2603:10b6:208:3c0::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.20; Thu, 22 May
 2025 08:12:31 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.019; Thu, 22 May 2025
 08:12: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" 
X-Inumbo-ID: 8427a83e-36e4-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=y7A2K7ssKzJvLe/tJfjs5qUvcb/FS3DfRJXPnNLbJyvuwqK3H4ahEo/yOJpx+y5oqw0vaXLNoRSlJxQL8ee00wNYSDcZZG0x7HM4ElGkuVS+dj6w6Cf4upkuEtmU+WUbzj/h0/7cjZKpvGXXdwmirZL21ZQsXyPouQZchVL3HpT7eeyTqlV8pzacaOt/iyk6WPryFDB6cNHE7RdZ1I+UFWqleLtVLGTZ69SGS1TuSzEBfYkrjmxMkQk0hB8eg7KE6aS17vEzVyVuAIM/VdMZA5gZvTedLfcRuRrK39Mxw3G001gPeaiU4JfAKkAOHCZOCb97FxlENkLkwlSA8MB19Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=m5BnwMZWJ5rCtGRJQphXq/CaIfE5mry3HMFkIt1E0K0=;
 b=itnU7YYn2A2QiPTl17H01+0IBBVTkEkf9o3GQY9HNouVpCh6E6NtcKpafZ5jL/AH+DBavs07HpW8kiGfsD0xN4Z50jLoCCmWUaiOBILmIjPcNg/TcJbHHc6/chh5VAARHhi3J8bOGmtk2byZGAXFnVJiczWQpVUXKM1E+rG8tiECtjfmbtiD7SWlT8HGmUPg6o0/gU8/qGjiO02qoYEdvgbHX9OoB+9LF6kaUl5/sF0U+8wSf/oYBcYe4mkqvDzonYVgrX85rkMb9S3v5lt95jU5CVrrfU3kqVf7ZEwUzM/dpn5TEXtWJn4j1Cl70GYiVYImxrZzSeUoSDcBP+FZyA==
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=m5BnwMZWJ5rCtGRJQphXq/CaIfE5mry3HMFkIt1E0K0=;
 b=xOzWKTIKkcVE956ABYU+FX8Jj9qBMAcXK1/YnCRICHJ3i+nB5syzy+AFczjknnjmeCC3XVgFBS6vbl6JV4O/rZ/lLfZnot/xiOD1VlUavW6yZ3GLVBxaA54OdJN9OPtjHh+qqrFXpDTvoy2XO47PmRpvEskA23wlTs6PriFGCRM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Thu, 22 May 2025 10:12:27 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 2/6] arm/mpu: Introduce MPU memory region map structure
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Penny Zheng ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Volodymyr Babchuk , Wei Chen 
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-3-luca.fancellu@arm.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250513084532.4059388-3-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0166.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:99::13) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|MN0PR12MB6295:EE_
X-MS-Office365-Filtering-Correlation-Id: 2b199551-e119-4f44-41ac-08dd9908661c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?akRSZEpXWGl3aHR0NnJwZWs1OGJlajROYXJZYUhNRFBCakk1VXF1MVlEWUwv?=
 =?utf-8?B?SXZxZW9aRU1nWHphVWpRZ2dtMENDbFlUdW5MOEw4bHJxN0pETXBkSHorTGto?=
 =?utf-8?B?THRFajRVelJPV1dCSlo4Vis1VEovQ2hjNHlVemsyaWVWWUVRb2V1M1o3VXd2?=
 =?utf-8?B?QTJyK0xJZ0hiMWhQZ3AxcUt3aWVCb25ocnhaS1BGdWVmT212dTIzeFpYWi84?=
 =?utf-8?B?VG1wWkpFTDE4MFg3VW56RTdnckNmQm5jNFpHbFBvQlFyNXd3cXUxbG5YeExD?=
 =?utf-8?B?dHhndHpJK3VQaFhNK3VsS2NtVk8vM2hxd2cra0NkUGVxMmlDbVlXS1U2MWMr?=
 =?utf-8?B?OWlnWXR5ME1yWWJFZmZjUlNhZ1BhS3BvS216TU51bVI5T2ordTFGQkM0WkxW?=
 =?utf-8?B?YXJSTHg1NlJOWWp6b3ZiMGZ4OUFWakdINjZwRlNuc295MXNVdDdSMms4bk5Z?=
 =?utf-8?B?eTFETFpIMThrTU43T20vaStINzk1cm55aGk3NS9sRW1SS3laZmhrZ1NqeVNU?=
 =?utf-8?B?dGU3MVBZYUxJQ095YURlT0I0Y2lySTBvWTZOZ3J5Z2ZwK0ZlREFoUS9mN29P?=
 =?utf-8?B?a1doQkxrRWY2OVhyTlQxYWlsTEFxNTdGMkprb2JNcm1xVHdCOG16b09pNmhk?=
 =?utf-8?B?V0ora2N5RlRDMitUWXJOU2RUVGhRMFdQQXY2dW9maVhqaW5CZEwyMGdYVWdX?=
 =?utf-8?B?dlh2aEQ5UTZ2UmdRb3l3TTBGMnEwLzUvOTMvQnNoWjNFWDRGL0hXelRuK2dp?=
 =?utf-8?B?YVBOSkdpTEF4ZmFIZGxBdmxHYWJETnRLV3BNYWRncEZBWmZvUGJ1b0lwZDR3?=
 =?utf-8?B?WWJDczJaNnpEclYxMG9ZOFN0aSs2cTZEVmNRYnVmRk1GSGxaZDAwdllZSGxa?=
 =?utf-8?B?Q252QWh1dWFUZU5vL2lsdG1WTlN0ZGRDR0NnbVYyWTc4VU1sN2RDN0hJRVJh?=
 =?utf-8?B?WGk2Q1NxVFk1RFhqQi9sU2drdWRIZzQxd0tTdTVtWDhTbldvdUdoL05xTTQ4?=
 =?utf-8?B?NGtMaVAybHVXbGRDR1V6dFlOcW5jK3NlMWpNbzVzRTdPWEJkVy9wNnJxRmlY?=
 =?utf-8?B?MXlzV0pCM3V6SXlHaGU3VG9rNW03bE5SdlkyWVJYMytsNHJjaFhFd2ZNRWhp?=
 =?utf-8?B?QzMyc2dBaGVpTFR3SWMwQk9SYnVyVEhyajJFamhuWVdYYjZ3Rk5DOUkvNzVH?=
 =?utf-8?B?Um14ZkhPU3g2V2pNY0ZGcjVZOTVFeGxRVlJ3MG4xN29sVGxqQW0zVWtmVmQ2?=
 =?utf-8?B?ZnlaNno2dUJjdjRmQkFBd0U5RXNYaHhOQkR1VElJT05icGZMV3pRbkNmQjJj?=
 =?utf-8?B?bWo2UkhlSVpaeXBqbVdSTHdpQTE2aUNPTVV4VGM3dFhBQUMrNERQSGxxNm42?=
 =?utf-8?B?dDVncGM4K29BbjRId2pxUHZib1hTcEVUUkMyYkNidWFEQU85YmVYNEVnZVJR?=
 =?utf-8?B?ZGhKQlZPUlFrcmw2MEZaNTRwTFYvQjF6eXo4ZVVoNlhzZ3VXSi8xU0hhWlpn?=
 =?utf-8?B?NjExa3RmaHpwSWsrQTlmWmlHTHQ4dWV2aENrMGUvbndIcW1Hc2tBNDdQbVBL?=
 =?utf-8?B?SFUwZjh1aWFVT2wvQVNCc2xhR05hb1JsUHdnTWxMOW5HbDVkcDkwbVMwRGJU?=
 =?utf-8?B?ZjY2aDYya1ozSFFNZjIrNFB5NVZGbWJMRUI3cExtRFpyempOQ0gxRER3MHp1?=
 =?utf-8?B?Zi9XSlU2ampBM1IzT1FVSlRHeHR3UVdYTTNHZXJ5SzRndW42aGMwMzg5NHFr?=
 =?utf-8?B?d0RQNlAzRUY3K3gwUUx6S3NHSzV5OXYwdTFkN0o4Z2IvdDlXc3l4UFVQT3dt?=
 =?utf-8?B?Q2FuMHFXTWJYMlJkMmE5ZTNDQm5ocGdYRzQ0eTVLaUN1dExKY0tPRHBCcCsr?=
 =?utf-8?B?emtoNHlDeFBqelArV0h3TWxhM3NXVDM1bmFzRlpEcXRXalJkSk1WYmxWbjlZ?=
 =?utf-8?Q?+j9SSdNKavQ=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UVQ5Wkl2UVpZNXI5STFMZkxYODNROTZwOXNsWU9LQStkdFRVTkdQdkRobHNX?=
 =?utf-8?B?MXNpWjZ3Y0RkSGZ6ZHdNenR3b09nQmxLcmEwSkh5TkdJYzh4ZUJydzR5ZkhW?=
 =?utf-8?B?Rjc5NnRsajhOWUJBak9rL1dPcE5UY201Nm52ZTVRa2N1NUhXaUxpT1lMaW9X?=
 =?utf-8?B?ck9sMFIrcjdFdHJ4M3JKaXh1cWxxNWxYZm1XRmt1RlEwTXdGYTlOaFgxT1VZ?=
 =?utf-8?B?ODkzZjVyNTh0UDQyOGljY1pJbW5pbDdrcU5hUG5pZzJqOVM4YmJKd0Q4TmJG?=
 =?utf-8?B?MWJ1dXdaUDQ5ZC82RTAyQ1Z3aGd0QXFZZTQ1M0NKNzE1d1FzQWlFTmdyUHlm?=
 =?utf-8?B?cEF1SVk1ZGtudmhFcUpLdVlwT0hpSno1NlhwU3dzbVRtaXE4cDRLSWNCaFpa?=
 =?utf-8?B?TURYMDdLaHhlYzhqSnFBQjgrNGsxeklzMDVJYlVTMEZNMWdDMUZaWVQ1cVMw?=
 =?utf-8?B?UEx5T1NjL1EvQzVrODJtY3dITWtIdkRxUytqbzY0WkpNbjJmcGkwOGRpM2d1?=
 =?utf-8?B?Z3ErZ2w1bFYrS3BqejNPa0ZUbmd1ZnZmVWNBYnVXWDdVM0ZVUC94UXkvVzlQ?=
 =?utf-8?B?YkFLblA4TkwvN05TZ3o0dFpkRUxLWEpxeHNTN2E5Y08xZTh0aFlmN01MQW94?=
 =?utf-8?B?MnZwSjAybE1sbDRTLzBMeS95UnFZeUJLeWd2RjJ1U0ZIRFRRcUw5dHRTWk1k?=
 =?utf-8?B?bXpwMFRhaEpjbmZaOTR3ZnZlWnlzMWwwWDZXdlZSczVVb3hZOWVsNWx1TUpC?=
 =?utf-8?B?OVYzeWZjaExpeWNDMExoVXF5MmplMG93NzVCNGxvS250VEVvdEp3RUdUMkVC?=
 =?utf-8?B?SUlJVUc3QWk1NjlSYTV6MjZ2ejErUjRXR1Vua2tlUFg2aDJkdHZjWkNud1Y1?=
 =?utf-8?B?eEFCL2xoMUdaOW8wSWU1TG53ajE1bys2NnR4WFo3bEs2TmRIbHRmN0VjZnY2?=
 =?utf-8?B?cDFlcWxaK1poWm5VL0Yya0k4THNVSkJQYUQwWnJldG5MaWgzWk1HWUI2WWph?=
 =?utf-8?B?ajR5alRzdmtXekdQTUo0bU9aRTZpT3BsWUQ1VllQNFozekRhckNsZ3c4NG4w?=
 =?utf-8?B?VnZHdmQyQ1ZLSDZCOGxUNWlMTjgzVy9Vc1dSb0M3U1Vqakh6NHBFYWtLUk95?=
 =?utf-8?B?TmhzOEExeVJXSWhzcjdUL3VjQUJtN1RmZzhTdjU3MTNuS1FIMVo4dmtyT2t2?=
 =?utf-8?B?aU0waDdpWW16cGFEY2g1Wnl0WnFpN2JCeWN1MGQxS3g2NUVWNjU5TDVjditV?=
 =?utf-8?B?b3ZCZnRmUm5xTzBYL2dPNllJeWVPOVdKQ1U1ZGkvL3d2SjNhRDVWTWJoUm1K?=
 =?utf-8?B?UEpCcSt5MjVQQ0lsczk2YzZPM2JGSVZYbmRpZzFOYTZkU1FON3U2UFpjek1U?=
 =?utf-8?B?cUhIMkhhNnAzZ2RJWjJCOWxGaWY0VU5abTc4ZEhsL2t6TlpRV1BMWThrRlVu?=
 =?utf-8?B?NzA0YkVWOE5BT0NQNERoUEV1YWlVc2JRWVo2ZXBCeHpQVm5ZbmFKVkpUYm03?=
 =?utf-8?B?L1g5T2J4NlBTT3JjSnFST05MVjFScTFEUitKdStBZzhJU2NCQ1FoRysxdC83?=
 =?utf-8?B?c0Qvdzdpbm1KU1NKa0cwYlhQaVBHdlNmQU81YWhjM1dQclcvcmpPaGZMcmcw?=
 =?utf-8?B?MHNvQjN6NDhmQzUzdlh0eG92RkhobVQrMlE5blFsM3lTdTRSTUUwZ2FIL3RQ?=
 =?utf-8?B?aXBxZDg0QVB0bk5nVE1WcjNoWkd0VzF3SVFKS0xKSWU4WEJuMmhxdDZzU1Jz?=
 =?utf-8?B?TTAvWjdGekRNZ0NONW5NSUs4TFhYQS92M1pJVlZKRmdKZElSRUs0azgvY3VH?=
 =?utf-8?B?OW9oQ0ZiRFBQYWc0bjhBZnUyb1RTdVNnRzlTdjZFdmI0WTlsanFNQ2tPWjlk?=
 =?utf-8?B?U2ZCaFgxbmVUMlFMREF5OTZhOWQycnExSW5rVGUzYzA1bExjaEJ5NXo1YXlN?=
 =?utf-8?B?RmQ5WmRONU9LZHhGVGl4MXMzUEd2KzBLc0U3amROVHdOMnUxY3gzTFl5SGNy?=
 =?utf-8?B?QlFyWnBWU3A1cGdUTVNZMzZRdlNNUjl6RWhkcU8xcTZDVVM4NmdkdS9ic1Ji?=
 =?utf-8?B?NHRhWTdhNU1BazdoK0xBbzhDT29meUZZTXZESitvL1FBU1hKQVB3cmZBdlJ0?=
 =?utf-8?Q?/LoDvGcc4HWyR9IAHRLwUf870?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b199551-e119-4f44-41ac-08dd9908661c
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 08:12:31.3745
 (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: KVJi/tGNSmKbMvlPV/HAKauiZSWLhhaAToyYN4pEa/cvajJJB3a1f30J3c6ne6CB
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6295



On 13/05/2025 10:45, Luca Fancellu wrote:
> From: Penny Zheng 
> 
> Introduce pr_t typedef which is a structure having the prbar
> and prlar members, each being structured as the registers of
> the AArch64 Armv8-R architecture.
> 
> Signed-off-by: Penny Zheng 
> Signed-off-by: Wei Chen 
> Signed-off-by: Luca Fancellu 
> ---
> Changes in v5:
>  - Given some comments on the page.h flags, I had to rework some
>    fields here to better match the flags usage and avoid duplication
> Changes in v4:
>  - Fixed typos, changed name for reserved bitfields, add emacs bits
>    to arm64/mpu.h.
>    Now base and limit are 42 bits as we consider FEAT_LPA disabled,
>    since we support max 1TB of memory.
>    Moved data structure in commit that uses it
> ---
>  xen/arch/arm/include/asm/arm64/mpu.h | 52 ++++++++++++++++++++++++++++
>  xen/arch/arm/include/asm/mpu.h       |  4 +++
>  2 files changed, 56 insertions(+)
>  create mode 100644 xen/arch/arm/include/asm/arm64/mpu.h
> 
> diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h
> new file mode 100644
> index 000000000000..d3c055a2e53b
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/arm64/mpu.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __ARM_ARM64_MPU_H__
> +#define __ARM_ARM64_MPU_H__
Given that Andrew's CODING_STYLE update \wrt headers went it, I think we should
adhere to it in new files. Other than that:

Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Thu May 22 08:17:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:17:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993180.1376620 (Exim 4.92)
	(envelope-from )
	id 1uI17i-0005y6-Rx; Thu, 22 May 2025 08:17:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993180.1376620; Thu, 22 May 2025 08:17: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 1uI17i-0005xz-Ox; Thu, 22 May 2025 08:17:54 +0000
Received: by outflank-mailman (input) for mailman id 993180;
 Thu, 22 May 2025 08:17:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI17g-0005xo-U3
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:17:53 +0000
Received: from MRWPR03CU001.outbound.protection.outlook.com
 (mail-francesouthazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c207::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 40087235-36e5-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 10:17:50 +0200 (CEST)
Received: from DU2PR04CA0031.eurprd04.prod.outlook.com (2603:10a6:10:234::6)
 by AM8PR08MB5809.eurprd08.prod.outlook.com (2603:10a6:20b:1db::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 08:17:47 +0000
Received: from DB1PEPF000509F1.eurprd03.prod.outlook.com
 (2603:10a6:10:234:cafe::9f) by DU2PR04CA0031.outlook.office365.com
 (2603:10a6:10:234::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.29 via Frontend Transport; Thu,
 22 May 2025 08:17:47 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB1PEPF000509F1.mail.protection.outlook.com (10.167.242.75) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Thu, 22 May 2025 08:17:46 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 AS4PR08MB7735.eurprd08.prod.outlook.com (2603:10a6:20b:512::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.31; Thu, 22 May
 2025 08:17:14 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8746.030; Thu, 22 May 2025
 08:17: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" 
X-Inumbo-ID: 40087235-36e5-11f0-b892-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=TGy1pZa1jMlF9uJRmerd3NJVn6bIqSyz1Y/Us747EIcrBnCpJNFFjJgE/H3N6I4mRG62ZFK3vPzrxWdQn65lvo15+M79vZdBY1df+vTN8FkNxNAe5lSDVPwONkYeDKJ983Xi0x1B3rJKrZpWMmw644ch+99eONjds5IQ7LQ60rhKCjbT8Mv6/BJB9TPkWZNdtHcp8mL00yF/zcZm8z9BhLJpUnkYi+sSMCVhX6hrzdITbmM32JzYYQ9R0o5+e7Q3/ONsqVkjLcVcVWyOuyrLjhiyYs3LLcrJ5WMtufNAxLiZlD0S0Xcp9Xv3QE53nHci9/MqAnjLR2ERwcH3sq8i1w==
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=mgIhukxxzm8aMMNZMjmLjgQK4wejOJcOd2ZdQIRhT58=;
 b=pefc1P2SGBvq01o19jqtUPenWRoHvRc2pF3Yw7vNg/F0wNLX0LqwpY1fsa0woYsI28ZAvY4Xo/C1pAS+l7cVBF7NAI66OUIj8ZNQSdMrtroHEoJGbjqgMUR02gDDr3lP/dxzlPL+79KhRdu5D14NN0cB2Tacl13cAlUda7fgBI1GjYKVWZKEOIS+y6uZo3QQdPMRc27A2KMTcup0pOvZL80MrqOvz3JDod9DhoESwCjvCaONqExe7/L7CIrU3QFC9Patk3qAszIHSZC2p4ElsRvKZa1R8HvvxWdTsPxjkA3wZvSkNTiuGxx/IbVnlHh3ZPzeSgZMdGkZzdfEqODLCA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.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=mgIhukxxzm8aMMNZMjmLjgQK4wejOJcOd2ZdQIRhT58=;
 b=eHCw1vw4UlNcyT6tC0QeJ74qjRvtXxhThiAYToVs9gq1otnoRSKpULT3D0Tk9pxv+75GVjAHu4/FZ27ohUVKUZoqLhHyb/5vMmAiCPQr0F2C0cQ42Ltus1GpcWaLJdxt3PkN4j5bh2iFL7vmprO0Uib2I/N6n1caUMDCUpnYp/w=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ed1/JxjdvJaoqNl8qIu9gJnQmcFOaQJSWqJTjo84wqizVzz5E5fWwDQdLvGZbAzmNkiO09J16ZUqjFbzRsIyzYUNnArcY4AIdM5atgS6R8T3yfQw6IE4XAs6FJM+vfGI8cVI+cYCv/ChQdra3+pDaMKP8CmZ8ZRE1LG4Bt+d+kCYMLrbO3rsun+Rdhcw0JNU/YB59z4fK7/2qNUuSOLcVdFDL0yHtmGTMl4+06xiS4WaC1yT1PSRrgvB9ZZZIZQRjk+9okRbVCcdDUyyxvIzDbMGfUs3hM7dTZLvuYt0n5spLkr2MAdY54Z462ek68cpy7ikrTnutw7KScrMKaxocg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mgIhukxxzm8aMMNZMjmLjgQK4wejOJcOd2ZdQIRhT58=;
 b=STae+x6cjwM9AlKsnsox12Bi3vuVzpCFKN0bWTPhYIoEPhOCGvuZLd8Hzl5YpnNqsc+tS3oQSNgpvSnTXpcWDHYSzd+Sq4giZtXIPFubNgotQSeljcyhewcJLGiPm4gz/vFDRZxThF9PP3sQUzMd82mPxOLXN70tRmofap02CGjO3+NHwIRx8Ok2Ob6LUVIWiws4KlK7Gf3ZDuZGeH0J1MBb9zNaX1JUGB0YawIXU0nNO6X1HHs+trssDZGuwG7Xrjz/PC7c/I/nOjpvG+yRSldgRVaQ6APItCEBCAtOjA3kXUBDzxUu7YBSmYL4mCJuL89rkD7kEVH4dvhqdiMCCQ==
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=mgIhukxxzm8aMMNZMjmLjgQK4wejOJcOd2ZdQIRhT58=;
 b=eHCw1vw4UlNcyT6tC0QeJ74qjRvtXxhThiAYToVs9gq1otnoRSKpULT3D0Tk9pxv+75GVjAHu4/FZ27ohUVKUZoqLhHyb/5vMmAiCPQr0F2C0cQ42Ltus1GpcWaLJdxt3PkN4j5bh2iFL7vmprO0Uib2I/N6n1caUMDCUpnYp/w=
From: Luca Fancellu 
To: "Orzel, Michal" 
CC: "xen-devel@lists.xenproject.org" , Penny
 Zheng , Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Volodymyr Babchuk , Wei Chen 
Subject: Re: [PATCH v5 2/6] arm/mpu: Introduce MPU memory region map structure
Thread-Topic: [PATCH v5 2/6] arm/mpu: Introduce MPU memory region map
 structure
Thread-Index: AQHbw+N/shgrvSYtoE6nwpjSqKGwG7PeWruAgAABMYA=
Date: Thu, 22 May 2025 08:17:13 +0000
Message-ID: <1CDB84D9-6D82-45DB-900A-7BE71DF54EEC@arm.com>
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-3-luca.fancellu@arm.com>
 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|AS4PR08MB7735:EE_|DB1PEPF000509F1:EE_|AM8PR08MB5809:EE_
X-MS-Office365-Filtering-Correlation-Id: 1a9d5af6-5135-4ee9-04cb-08dd9909226d
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?cGJVbVlab3VUcFlONGFRaXpySkVTK3lwY3hxaVY4Si92TlVKeGl6UHdEN3kw?=
 =?utf-8?B?ZDlNbGJHTUY3YktBbXUzUWxVWDNmL05LMGhQK3I0MVpQRVMwbVRsTG03NG5C?=
 =?utf-8?B?bnVkYjVCQVNzWTU0ZytreWQwY2s2RFh2Rm0vdTJ2MzhMRit0VGdraWJoRkl6?=
 =?utf-8?B?QlYzMEJzSWZjZTVuMTFXTjQveko3VFVWT0poaTNpUTRocUxabkh3MUFOOVNF?=
 =?utf-8?B?eU04R21MNkZzZkdnMmRsNlpOQzNoL3g1ZlRFMzd2bnhmU3JlWGJwS2tzTmNz?=
 =?utf-8?B?L0M2a3BnbDZxTGJmc2RHdm9EUk96a3UrSEFxYTJ0YXAwM1VLRUFMRndGT1p6?=
 =?utf-8?B?L04xTHFiVjQ2dkxyeWp3MVVSbEt1WjdIOGJkZnY0b2IrTGtXUU9hK0tkVUVw?=
 =?utf-8?B?K21oeklQSW5vdmRXMDV6eFVHZHA4RU91N0d0WE5ZamZDbDVCMmJ6bXNrOW5P?=
 =?utf-8?B?eWlHaHY0QzJNOGlQV3dTclFHUlNQR3M2blhSWFpNR0JSM215ZE41NVU1RG5Z?=
 =?utf-8?B?SHFRTzhHeWk5VmNvTGhmYmgwdFcrblhPdkdhVVBpOGhQanBlZlRRNXRFbEF0?=
 =?utf-8?B?bzMxQkpUNFhVb2tiMzFwcTg3VTFRdmR3eXBNVjUwVE02THpGTHBkaU5qM3hr?=
 =?utf-8?B?TE9wZytoOC9RUlZualp3cTZOSys4ZGYwdU1Ba0xkVVJLK0FkNlBnWkxvR2xu?=
 =?utf-8?B?b1RFYjMxdUgvaHJqNnJyUW5PR05MbFhsclBhaWJDaUY1NFh6WGRrMkMvVXd4?=
 =?utf-8?B?b1ZZN3VocHVicklHU0JGcE5wdi9pb3ZlN1ZTVk5TcW1OaDVONEJDNmorajhD?=
 =?utf-8?B?SDRCZkRNTDBBZmczSlhzU2dNM3E2NFduSDhWQmRJK0p0bzA5Vys5djhteWdy?=
 =?utf-8?B?TE1ZVjRmd2dsZnBaemJOMThoRHFqN1hGbmVyMndlZnZTbmd1YnQxTk04QlRL?=
 =?utf-8?B?WlZMQ2o5ZlNQSG5ETStmQXJsWlh5bVhOYVpJT1Y3TitBVnBITng0R0VrelRx?=
 =?utf-8?B?aWhRMlZzSDZoVUpnQ3lGaDlsSEcwWGhySU1wMldveUFlbFp5Y1BRMlhTQVY2?=
 =?utf-8?B?VG54dC9Fc0FEMGlPbzFWNDk5Ri82UWdrVUoydG9kc2dXOUdvK0NYWlhuUHd3?=
 =?utf-8?B?bVZ3TmNMMnFTNXo2OHF0SlB3RGlSR014Z1hIRjNFNHpWQ2g5K2lqWm1MbWl2?=
 =?utf-8?B?a2FCb3YxOElNdEZlcUlQaG9wWTYrV0UrbUtJWklPeWV6NGlsZ3lCZmp2S2Zw?=
 =?utf-8?B?akpib3FmQ0FJdUdjWlQzRE9DUTN1ZTJ3RlRWeWtoT3BNeWlPemRaK1NmZm9x?=
 =?utf-8?B?Z2ZMOTZLeGUrY0lZd3lzdzVIMk81bllZaHhZeEtHUExXajh2NHVKZm5lVVBr?=
 =?utf-8?B?M3JSYlFzTVd5UXBMaU5BZ3JPUGRQZzl2cUVZSHgwRWl1K0sxd0pZaW45bjN3?=
 =?utf-8?B?QmdoTnVLNEJXdS9vSW1vTzhJSFg3L2d3TXJOd0orQVRHemx5ZjVtQWgyaHhq?=
 =?utf-8?B?N2RWQ25pOEJoUVlhRmxmb2htUXZtc0VNWUwzNjVsR0hvWU0vWFNhd09naHBm?=
 =?utf-8?B?aXZyT2RidXNFZnVobXJZOEVOaEgwMlllOWN3N2hkS1duSTQ0eHJXcTllQkFK?=
 =?utf-8?B?VGhyai8yZ2ZSK2FEOHVQdVRWNGNVTG9hZVVodURKeklQemhlMi9NcUhheVVB?=
 =?utf-8?B?Ymw0TVhySGRteDNHWkJZaHl1ck84bTQydGdMMk92UDd4VGJEMnNhR2h3MGtj?=
 =?utf-8?B?dEZBMk4wNTU3VzdnRzduZFQ4VHpjbysxcUpNQ0ZIZm5GaW1ta3owcWtKbDVC?=
 =?utf-8?B?eUpkWHFGeUo1UXlJRk1mNEo0dTNGMlRnMncyV1BWd0ZkRk5LL3EvTk1kSlZq?=
 =?utf-8?B?RVlaZ3crREFWQ3g4TUMwQUpPS0lKbEdLcVRwS1FSdXB6QkQvTkxZODlyeFpQ?=
 =?utf-8?B?Qmx4WU1iYzNCQ0FsVnF6eU4wcDhSNlA3aWVTY21lQmU3NFo1cHkxSUtqK2Rs?=
 =?utf-8?B?U3hZM2VmME1RPT0=?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <00070121C49EB442BA429E5760BFEB09@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7735
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF000509F1.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	6c146ccd-a9a5-44d2-5d1a-08dd99090e9f
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|82310400026|14060799003|1800799024|36860700013|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dmVOZWFPcDRVK2lySWZ0RWxwUFlwbHRWVEgrbEgyQ3FKWVY0RERkbFBwM2NM?=
 =?utf-8?B?TGQ0dVFpdkZFbTdiSjV3cnFhV2JKWU9SVDVrSGsxaml2aVY1T1dyZ3VSNzMw?=
 =?utf-8?B?ZVphMEdFUGJsNDl1UjkzNVlhNW5UUEFHaWQ2OWhmc2MwcE9iZjh3by93QnR0?=
 =?utf-8?B?REJibk5rNmF5L1ZrVGNmNnpKZ2ZpZlY1Qk9NRElxWUJqQjZkQmV2c0YzT08v?=
 =?utf-8?B?NnhNbzFHRXVzV3hwK1RiYUhNNlNjTHBCSll0OXFhRXFSaXZVTVVjS3JtREZD?=
 =?utf-8?B?OGtDQW9laHIzdHRsdFhaOExyUjVZMlo5aGtjNW5kS0kxOXRuU0kzVHAvUnpC?=
 =?utf-8?B?bUVNMGJ1MHIyckE5d2lkcHRmM3UyMVUxVFNEYlQ3VmdDWFZVTFlHck1zUDJ5?=
 =?utf-8?B?V1VSU1hiUXdKSDR0dGs3WGl6d2FLbGFrNndtcnpUaVg4NmgyNHY0Qm1OK3gr?=
 =?utf-8?B?bmNpZVBGeXk0ZTRMSlBxdENKQkFlckgwaTRFMXJNSEJQMk45TERyTkVvOGJD?=
 =?utf-8?B?VkRwOGtQbmZ4UE5WUWlqM3B4SDJQMW9RZnF2d1FxamNYYWprQ1FGd2tIOG1G?=
 =?utf-8?B?U0wyZ0I4TkM4VlNqNmNNSXBCcDR4aHN2Q1BYZ21QbTlXWGVJWUdJeTBZdm1Z?=
 =?utf-8?B?MG0wbDgraWlHM3ZDZDVoeE55cFNnL2dUa25udnVTOWJpTG0yelgrZlFIUkJv?=
 =?utf-8?B?c2t2NXlkeWJNdGl6OFhrb0ZXamJSNDR3WWh0b282RTFNM3JVVk1XT2VUUEJX?=
 =?utf-8?B?dkNqWWRIK0ZrMi85NGUwSlZBbC9xQnUycWlwU3V1aTVYcXd6VHYvaHFkbTdR?=
 =?utf-8?B?K1lTZVNGN1dJMXFUL21FZE1zVHdtalVJZkFmYnF4dGcyYjd1VDlZdElGNlVn?=
 =?utf-8?B?M24xUkRjK2NxcEtxajhmU0t5aHkzR1lPV3lHdG5CbXZyQWZGRTdLcUwrUElz?=
 =?utf-8?B?UnNDR3hlcUhDYUVUbmlTSG11dnFBdTFpMGpUazc4Q0FMSU5HaTB4cWtRLzdO?=
 =?utf-8?B?d1FZbVFtN0NKYnlueWgvamR1UU1rYXgvRS9xekRndzZoakluTE5hMGdNNG1r?=
 =?utf-8?B?aEgvV3V0bjZSQ3VSdWoralBhZituMXgxcy95aGlySFFGdGRjL1J5NEt6NVVQ?=
 =?utf-8?B?MXhBNXpXVHhkMEZpTHRjUVBDakxFTFVVQWMwZ0JEOWxsNFhnaVI4VlVUdGhS?=
 =?utf-8?B?MlVqSmZsYUhMallHNUVEV3VqRitMNlNJRGlWbHV2R1FqUG9IcFVzVHN1aVly?=
 =?utf-8?B?T0k3MklmbWtQK3JWNVZJMzJ2aEJuL212M2RxS0ZPbXJOTnhMeklKenN4NzFG?=
 =?utf-8?B?cW1FS3d0QWRBL0lYL2tCazRpTjBBTVdOQnNLVk5lZDlsM2U3Z3JGanEyNE83?=
 =?utf-8?B?dmlkTUkzbk01MWZKS0VQbW5LS1hHbVQ2UUZ1TXUrSTM3ZFh3V3ptNWRjeWhK?=
 =?utf-8?B?UDlnN1ozYlZ0N1gyY0ZWb1VMb2s1MytKRnk5WFFtSW54K3l4a0hRdEg3MklY?=
 =?utf-8?B?MmlwQVpzV1lERlp6dFMrS3Y2TmVvYmRCUnBaSCsyL2hkbGdrNUpqMnZjb3BS?=
 =?utf-8?B?ZjNWejVQb1crVU8vVnE5NVFjeFdBLzZtNjNpTW1ZQy9OUFFqL1dITkZ4NDBm?=
 =?utf-8?B?dmh6M0dMMEttL3pJT1pCNkhGZTdTN0s3dklnWXQxWTRwaEtJMVplcTN2N0JY?=
 =?utf-8?B?cmNiZXU5VEozeUNXaE4ycUFOeFRUTEVkY3o0WGQ2dEVPU1Q5MVpDVUtQYUNR?=
 =?utf-8?B?Wno3dGQ5SkdTT0pvcVRuVEhQbFJnWWpKR1NlSTlObFpYQVFTQlI2RlA0T2RE?=
 =?utf-8?B?bkMvd2Z5ZjdxeU9weVpuN0M3RUZVdkRKS0dVN1dVRzc3WEFQNHJlQkdzL3lY?=
 =?utf-8?B?Z1lNN0dEVmQ5MHFrVDNTYTRtR1ZkZWRqTi9oOWdNTk9RNGlUM2xmeCt0Mi85?=
 =?utf-8?B?UVVIUTJsL3hRcExLcDlKamgzOXRjSnRVRC9zT1A2TlNGRFRESGVYL2h5bkVH?=
 =?utf-8?B?RTRWcU9oVnp1TFZOZzJjSGRkTFZZQ1FPTXlEbEw1NUU1ZWdiUVZuRlBEZGtz?=
 =?utf-8?Q?Solagc?=
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)(82310400026)(14060799003)(1800799024)(36860700013)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 08:17:46.6762
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a9d5af6-5135-4ee9-04cb-08dd9909226d
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:
	DB1PEPF000509F1.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5809

SGkgTWljaGFsLA0KDQo+PiANCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9h
c20vYXJtNjQvbXB1LmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vYXJtNjQvbXB1LmgNCj4+
IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+PiBpbmRleCAwMDAwMDAwMDAwMDAuLmQzYzA1NWEyZTUz
Yg0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Fy
bTY0L21wdS5oDQo+PiBAQCAtMCwwICsxLDUyIEBADQo+PiArLyogU1BEWC1MaWNlbnNlLUlkZW50
aWZpZXI6IEdQTC0yLjAtb25seSAqLw0KPj4gKw0KPj4gKyNpZm5kZWYgX19BUk1fQVJNNjRfTVBV
X0hfXw0KPj4gKyNkZWZpbmUgX19BUk1fQVJNNjRfTVBVX0hfXw0KPiBHaXZlbiB0aGF0IEFuZHJl
dydzIENPRElOR19TVFlMRSB1cGRhdGUgXHdydCBoZWFkZXJzIHdlbnQgaXQsIEkgdGhpbmsgd2Ug
c2hvdWxkDQo+IGFkaGVyZSB0byBpdCBpbiBuZXcgZmlsZXMuIE90aGVyIHRoYW4gdGhhdDoNCj4g
DQo+IFJldmlld2VkLWJ5OiBNaWNoYWwgT3J6ZWwgPG1pY2hhbC5vcnplbEBhbWQuY29tPg0KDQpP
aCBJIG1pc3NlZCB0aGF0LCBJ4oCZbGwgdXBkYXRlIHRoZSBoZWFkZXJzIGluIHRoaXMgc2VyaWUN
Cg0KQ2hlZXJzLA0KTHVjYQ0KDQo=


From xen-devel-bounces@lists.xenproject.org Thu May 22 08:18:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:18:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993189.1376630 (Exim 4.92)
	(envelope-from )
	id 1uI18X-0006Vc-8J; Thu, 22 May 2025 08:18:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993189.1376630; Thu, 22 May 2025 08:18: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 1uI18X-0006VV-4S; Thu, 22 May 2025 08:18:45 +0000
Received: by outflank-mailman (input) for mailman id 993189;
 Thu, 22 May 2025 08:18:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI18W-0006VN-6O
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:18:44 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20629.outbound.protection.outlook.com
 [2a01:111:f403:2613::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5efc8f6f-36e5-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 10:18:42 +0200 (CEST)
Received: from DU7PR01CA0041.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:50e::6) by GV1PR08MB10569.eurprd08.prod.outlook.com
 (2603:10a6:150:16e::7) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Thu, 22 May
 2025 08:18:33 +0000
Received: from DB1PEPF000509EB.eurprd03.prod.outlook.com
 (2603:10a6:10:50e:cafe::28) by DU7PR01CA0041.outlook.office365.com
 (2603:10a6:10:50e::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.21 via Frontend Transport; Thu,
 22 May 2025 08:18:50 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB1PEPF000509EB.mail.protection.outlook.com (10.167.242.69) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Thu, 22 May 2025 08:18:31 +0000
Received: from AM8PR08MB6578.eurprd08.prod.outlook.com (2603:10a6:20b:36a::15)
 by DU0PR08MB7857.eurprd08.prod.outlook.com (2603:10a6:10:3b3::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 08:17:57 +0000
Received: from AM8PR08MB6578.eurprd08.prod.outlook.com
 ([fe80::bb1a:3ac6:3110:e2d5]) by AM8PR08MB6578.eurprd08.prod.outlook.com
 ([fe80::bb1a:3ac6:3110:e2d5%4]) with mapi id 15.20.8769.019; Thu, 22 May 2025
 08:17: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" 
X-Inumbo-ID: 5efc8f6f-36e5-11f0-b892-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=XiUQ+wxjWeixToppqnxffnbDdFQadeIZuOpSfCV/SQ+XvS4DoeT5VUOoff7h+afMHhRTZ/t+EujXzA4n7Ha719Ye+U1SXAW1/t2Jd5Ogdzppcg4nK4Fld2biO+LGe5bkkCR+SSIcvF/Qse2HRHzutfzACC1rfjSWgCdWJjkq3hA7+vQj9LQfdntvq4PeKPs6OU9pFsmMTTbzOcFBZ44aODaZwtFqBXz2m+RRygrIafAjGT6M7MayurwBOmvt72koj38JAQtk/5j4SstEM1OWChs4kK+u0Xj3XzkEsttdW8wmiFGz/jBKJXZ8mCP0V7DBq3vVMV1BldeNJbT0OOF1MQ==
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=n1XRav/QsWkRMbyiOydWxzIelX1zYefLFVrxxInw+rE=;
 b=h8GAUzS1PC9ROwmbp3m3s+xFRoDz9gd59hz1487OR/lJQEq998RZPOiySYMB/nSiEqPs+qP1KoDF4VVjz/8ufb2XNKndj/lFdXtP3sPZQL3JWPNnPoeyJTwrTrhI6w1uxlNfHXUs1eIr9OBreyu+wck71T+HG+0+rJI2fM/TkUNpMjkLM8S2yZpgY7xscRjKyE8ge8ohI1VBKaqxFrMBxGh09uHt9aw8vMvoY4oMI6LdMAAIztLhnKeXbPKBQL/t2ND3YvkCG/AICpBSws5up21h2aDgqQY3aE7HBTltSl2Z7mX/Gx/E1uibwvYkQ6jw7kutkHxQAGIJ8b4j8v5DPA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=linaro.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=n1XRav/QsWkRMbyiOydWxzIelX1zYefLFVrxxInw+rE=;
 b=K+A93faXnkc39KKABHva1WvOZqSS9IpEayqCwef1PM7pi9ZE9kINchbG1+pbGz/FV812sW04+zZBNV2M35ewLsjU+MW7Hjlex5yP/GoiM0xTp2Bmhm5gbreVYYWloYAidCy4BszHOGK8zw79BKoIz8L/o5BHoziBT1pHPUYJGlc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eUYIF6EWDqGdnc8VnsRYmEQjmauoyBCCiourvv2tWmlS1nhE5ecp1IYpJh8SAiofF2YNcq0DlAfsBRUUJk4NYsbcssOIRm1QKrwoJjqGsyYyLoyJXxiEPViAUHmLi/GSUziqW4UtAaBeDa729OZMv6MQeHmFzI2hgUQVVGthxUSqYc9qemPQrRYdRBvkT1DqsLEMjhfKyq7RmVySDTZWryWRyxK1uSu4bS/XHw4SjU2/0kDykhDEJNfqPPFNuetRlF8Hssy+c5yV/V1R4V4zu0eYGLuxtiAvaFy6EYm/Q4OuEoG524rvYfGnIAO2zk8qQAp1BdihB86R5rqXgSmPKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=n1XRav/QsWkRMbyiOydWxzIelX1zYefLFVrxxInw+rE=;
 b=fN6H5/WktnXCTdwI0FckpS1/f6ywNhfuoWWFtcXv5oaf9ieYLEcugEAlJYNutBkl/HdE37+YSqB/nuYGzS0ge4RAoxexGu4LeAW7B0Et+4tjAGJD9G/U4x3zsG2rXaS0xDX3nqDU+kCXYj/VB0s906WBsXQatYs6mxS0fGj4F1KaVKrOFq/6Ya0M8eH4V0l0l7FXOjn0Ib7oBVhEel7PKCw47yML1zpDR0C4iqsU+EPg9TEQ1RnkaiWJ+YW4o0l/Nb9CzEp4nRutMlIQRHuTHjLkqLq9yovhN0dLbmpyMj09pvWg66T7pDp5cLYXyiYmOuM6HnQV0CvHzRiUh9GCyw==
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=n1XRav/QsWkRMbyiOydWxzIelX1zYefLFVrxxInw+rE=;
 b=K+A93faXnkc39KKABHva1WvOZqSS9IpEayqCwef1PM7pi9ZE9kINchbG1+pbGz/FV812sW04+zZBNV2M35ewLsjU+MW7Hjlex5yP/GoiM0xTp2Bmhm5gbreVYYWloYAidCy4BszHOGK8zw79BKoIz8L/o5BHoziBT1pHPUYJGlc=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: "xen-devel@lists.xenproject.org" ,
	Volodymyr Babchuk , Stefano Stabellini
	, Julien Grall , Michal Orzel
	
Subject: Re: [PATCH v5 6/6] xen/arm: ffa: Enable VM to VM without firmware
Thread-Topic: [PATCH v5 6/6] xen/arm: ffa: Enable VM to VM without firmware
Thread-Index: AQHbrqLcLBT6scPDY02nTshBGWfMDLPegcqAgAAE8IA=
Date: Thu, 22 May 2025 08:17:57 +0000
Message-ID: 
References: 
 
 
In-Reply-To:
 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	AM8PR08MB6578:EE_|DU0PR08MB7857:EE_|DB1PEPF000509EB:EE_|GV1PR08MB10569:EE_
X-MS-Office365-Filtering-Correlation-Id: 85c7ba05-e160-4bac-ba93-08dd99093d31
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|1800799024|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?dmNNUGpkczR3NWhrNmVLM3pGYjNXZ0h3ZFZCRWlaakV2bytaZGhnV29jdzRh?=
 =?utf-8?B?STZiSk56R3BQcmFKM08xWExDOFVjTG9HMHNzc2tVUGdmd3Y5a002eWEzNTE5?=
 =?utf-8?B?dUdGb0w5UDJZd1V2RXFrOVF3aDVOOG1TcjNYSmlHSUtOaUZBaTZtN3VabVFS?=
 =?utf-8?B?OXhSVWM1ZzhzQ29MVUZjV3NCSWJLa01ad0UyYmFCTllIa2lTUk5lSDQ1NTVN?=
 =?utf-8?B?RmVrLzFobzFJU2JYOGJkZndHSGxIV0h2RjVYR3htanFDdDFPemxWZFZ4OWE3?=
 =?utf-8?B?Tis2N3duaDhPTnUydzhFL3JyUEo1ZUlOa2tNeVFObmJzajJLRityT3NYcDUx?=
 =?utf-8?B?WjAwclhtTHhZbSthWWVxNk1WQXh3Vnl4cjAyYzB3cThRZHdPWllJZWZZL2pj?=
 =?utf-8?B?bDR6MEMrZHpNWVhod05sbXo4Ly8yZ1dMYWZWME1oOTM2Y1ZrcGdNdlU1TGhQ?=
 =?utf-8?B?Y1lxamJpSndUc0doa0RxcHFYenZaUCtjOVRMRDdYczBSTGVma0JjNzVnUWFO?=
 =?utf-8?B?VFZuSjBpMTZaeDUwbWJubVdHUm9DbVZ2ZlJGU0J2K0Q1ZHh5U0FOK3NNTGsy?=
 =?utf-8?B?VXpmWWs4d2NxbSs4cWhSZkkvbVNBNmxnVkgrZjRBV1A0RzVWN040Nm12dHZC?=
 =?utf-8?B?Qy8yb0pRckRvYjFMQW9HS1RMMy9vblJxcXA2UDAwQUJpQmM3T2JqVDI4aWJi?=
 =?utf-8?B?djUzRytaNEg0N2Qwb2VLelhKR1Q3YkF4S29TbFJsei9sVDNaY3A5NWRmMGpj?=
 =?utf-8?B?UXJrQTJWYVVmME1paXZUSU9Jb3lCSUgwUGNGc01PNkZFSnQxRW9XcTFXbzRI?=
 =?utf-8?B?VE5hUHNlamNwbS9ma1V2TEhuSFZ5WkU1WldDUzgrcmg3bXVVN1pZVjNwQ2hM?=
 =?utf-8?B?dFRKRlRvTVkxaXdlUlhuK0t6Wk15MU5ycEZWUzFYZGVWMWxyRUNETVBDVzVT?=
 =?utf-8?B?bHU3MTMxaHVodXBxWVV2KzhIdndQU0V5MDczUUwwaHNVVmRLend6TnVDQWcy?=
 =?utf-8?B?dmJIRGdzUUdmMW5MVkVTM1VONFhxS2dPdEZLUUlkR3pFSjZCUmM3NXBubnlQ?=
 =?utf-8?B?UTFMaFUreU9UejhyN3Vyb3A1d1BPTzFaRXhpSGJrNUtMdFcvSzZzL1RnNXBu?=
 =?utf-8?B?K0dacFNqbmRkbG5NTkM2MmdDUlI3ZDNNTnJ5TEp4WHE4RVc3aVJJOHlTWFRF?=
 =?utf-8?B?Wm1RQzZRaFN1WE92VGJZOFZXaWRXdnp5ajhIZ0pZckROL2hkSHc2Yk9MRGlO?=
 =?utf-8?B?WXlEMTRMSFBwc3FWSDlHVjBROTdKMFljK3ZuTlU2aFZEblhvRUo4UFdJRXJ5?=
 =?utf-8?B?aWhXNE9xYytqZUFoaFhkczVrTDF4UjE1REtjOVR2aVBLam5XaW8xbURXL1Zx?=
 =?utf-8?B?YTRZRnpaempQdWxXWmJMSWx5dmxXbVYyanNHNVJvbjN4b1cxUllRMWFualp6?=
 =?utf-8?B?bGIwTUVYTmF3YWdySE56WUxOZkN4RURmUVl2Z3M3VHErSnZzMlhYYVYyeGhV?=
 =?utf-8?B?aklHNXR3bGZyUUpDbnAwUm85K1hlTzIxVVM2Mm1MWVc1aUVqRmdSQVQ0N1c3?=
 =?utf-8?B?ZzYwdHNER3RBbjZTclJxSUljV1J5WHhjQW9EM2VyOXJuSDVzOW1jTWY2MkY1?=
 =?utf-8?B?TVBIUHltVzJ2d0Y0aWV0b0xvNElkVWVpZ1dxS2JPNjd0YjBYSllsZldZNTZo?=
 =?utf-8?B?Ukx4VmxrOHg0cnpmNWhHNlZYc0FLWTNZVWxValVQaVFkWHpKU0t4UjF6Y0c1?=
 =?utf-8?B?T0YxaktEQzJBZ2xkS1FNaEVQeU1TTFIxa2NqbG1aKy9Pem5nVnI4cC9HbndM?=
 =?utf-8?B?dlk4WnN5T3FJL1BCYXVPaWlISXk3Sk1tZkwwbzE5Vng1a29MQndaREJ6dVJJ?=
 =?utf-8?B?SVdmdEtvZ25PT1NpOWo3TlBBS3ZYcTRHTVc3dWNuNGlva0ZDYVVQblo0eGU4?=
 =?utf-8?B?TmFtM2lmQWJQMUpnaHR0RFc2TmNkb1pRTkJaWnFWRTB4OC9VeS91cVlBRDh0?=
 =?utf-8?Q?hzTmpkGFHP25IrSfv299nIP/5QHt+o=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM8PR08MB6578.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <0D348F84B2427A45A4F75E29A6902C09@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB7857
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF000509EB.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	b45c3bbd-341d-4ad9-f7eb-08dd990928b9
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|14060799003|376014|35042699022|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TXFzT3BiV1VHMGRFanlhcUtGOUZtRHAvTWlBZ1MwTmJPOENpTFArb1pTM1Nm?=
 =?utf-8?B?TmRBL2RCd3l3Y3lNK3FCM2VLSm1Gc1Fxc0RZMG5sMmNZa011NnNaMlUwQmMx?=
 =?utf-8?B?a3YxcWtBSDVXaTh2N2NjVUdLbk1iaEVYL2dmSjJkamJFdnhoUXZNR3JSVi9D?=
 =?utf-8?B?a3prNW1vbFNGU0tNZGZIb3k2MjBRemdSRkxzanVmSFpmZWRRVTdaWXR0bE1T?=
 =?utf-8?B?TzYvemhsTmNrZEl1WWlQaVNLN0tuMmZTSk02OGJkSHhWdUVDTklLZUpHaGNT?=
 =?utf-8?B?OGxyK1NQNjBmNFo2MlI1R01yQnlIT1d5OWZOa1hFWStoNGNYZnc2ekVJZkpG?=
 =?utf-8?B?bVFhbmdVU2tyLzZhd1VHcG1iVEk4RDNpZkt0bnhMeG8wY0wrcHVranNBSXNN?=
 =?utf-8?B?bG00Zjg4d3E0Y0xtRVJ1cER2UFlvbjJFQzBqRmNrU3NLSmo4eWJtd1ZiMytT?=
 =?utf-8?B?d1hPNlBTQ01xOVduUG5VcEJjeUpNTXFhZUZ5c3FyMzFsdUl6MUJhN0xobXZ4?=
 =?utf-8?B?ZUNIVjRYVUZHZHllNDF5LzN4Sjd5Yk5NZ3M1M3U0SUJVbWRoNWZXRlpmRjJi?=
 =?utf-8?B?cVRSLzhGYTdWL0VpNWFaTnM4Wnh5bmJsdmpDdWsxejNNTFdOQ3ltZmNlY2pm?=
 =?utf-8?B?dWVQWldpV3dmelRZRzdJbUk3LzRZem90S3ZZREFPdHNpWkt0T0RmN1BieFNV?=
 =?utf-8?B?anRHODVpRXBYaS9VdzNaUk1wSUpCa2VGMFE2Z2lYRTVhYjVOcXMybHFXcFF5?=
 =?utf-8?B?OFVNcHYyNUhDb2twVmRtc0h2NmYwd1BXcTFYa1hrWVFJTTZSaTRuN3FvTzVW?=
 =?utf-8?B?RDVKTkl1ejF4Y2k4MjRveU1RWjBDUXcrek0wS20rd0ZTdWVkNXhiQnQxRUkr?=
 =?utf-8?B?cTdNTUF6ZmxBUExXSUdhRys3MjQrMklrUk5IeDJhTXp3TWgzRExnKzk2VTFw?=
 =?utf-8?B?ZTYzdXVFNGFGKzQzSnlta0c5SnJaVXBoWG9QazlSM0dHcURlYlRnZ0xZdEVU?=
 =?utf-8?B?SXdTSGI1VEEvY3Q1cWc5c0N4ampRbFJOaFpyUDhDVEV0b3FjSmRuS3JIa0Zx?=
 =?utf-8?B?aXpVSCtvZ0FqNE1LR3VLVnhydDY2bnRpNmZvcUVUa1l4cVc2RzNvc0p0U01z?=
 =?utf-8?B?L0NaU0g2RDlxUFFueHB1a1hBT2xIQmpWODJaeWZtSnFhM1RCTHhqYzZQc0hK?=
 =?utf-8?B?YWd3Mnc2NkpybnNnUkozQkgxLzhuTEdKUzFadVlxQUxYS3FFTHBFMEhqVWRE?=
 =?utf-8?B?dHVvclp2QlJKWlpRc0lYMFkxRWhuY1N5NVYvWTlYOUJNWWZNSlJDbzkwMVc1?=
 =?utf-8?B?VE1BcmxXS3Rtbzd5eDhNMjVjNHdMVUNNbnJ2S29vaGpJck1veXFRclJwNzdy?=
 =?utf-8?B?a1VFSWc4dTVwWWFjcEtjWUxsWmVZL2JFQlFDeWMzN0Q0VFZoNzM1bUI2bXor?=
 =?utf-8?B?TWlpYXZFVjNiTGZSc1FKOVlvQTBzRHVKdy9JckJlUDVhMUtSOC9qanV0bmNN?=
 =?utf-8?B?bUp6WjR3YUN4Mmd5MkIrVVl3a1VqcEtUdE9vcUZrbHBKWjhrc2xFWksyLzRF?=
 =?utf-8?B?SDlRRmxGc3NHUkRRVXBYMStHOFNKdVNwV2dTL3pody82bklOc2J4SVp1TjQ4?=
 =?utf-8?B?V0NGQ2pzNGtXSHZhbWY1L20wQlpVOUsydDlXK1RCbzA0WmR5U1loTFNYR01P?=
 =?utf-8?B?blFuUmRia1BnWlFFbDBxejFveTVYMllkZ2V6d0ZZTWxKeUxTRS9NVE85Y1pV?=
 =?utf-8?B?Zlo4OHRyMzA0MWNUYkxuRXlTVzN2V0NhL2pNcDZ1dEpqS1RqNGhERnpZNktS?=
 =?utf-8?B?aFNLNGEwZ25KZ1FPeW4wOEo1NXBaNVhpNFBRNm9xT3FHejlDaFYyTWh5Q0tB?=
 =?utf-8?B?SHNYWG0yLzMzY1VNRmFMbms1eHNqdkoxbnJIanJvS21idnR0ZEJpNGFyNmxV?=
 =?utf-8?B?cEVHanB2UXpzU0RZSXdZblpuTFQ1SDdoK1gwQ3dEOElndVFEakN0RDhmbllp?=
 =?utf-8?B?VlZoRm9ObE9jRkhXOUpRR2JjQ09Wa3J4bGRkRGtMZGpwK2ZKSkFBYlhQNjFH?=
 =?utf-8?Q?/gE4G/?=
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(14060799003)(376014)(35042699022)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 08:18:31.5800
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 85c7ba05-e160-4bac-ba93-08dd99093d31
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:
	DB1PEPF000509EB.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB10569

SGkgSmVucywNCg0KPiBPbiAyMiBNYXkgMjAyNSwgYXQgMTA6MDAsIEplbnMgV2lrbGFuZGVyIDxq
ZW5zLndpa2xhbmRlckBsaW5hcm8ub3JnPiB3cm90ZToNCj4gDQo+IEhpIEJlcnRyYW5kLA0KPiAN
Cj4gT24gV2VkLCBBcHIgMTYsIDIwMjUgYXQgOTo0MOKAr0FNIEJlcnRyYW5kIE1hcnF1aXMNCj4g
PGJlcnRyYW5kLm1hcnF1aXNAYXJtLmNvbT4gd3JvdGU6DQo+PiANCj4+IFdoZW4gVk0gdG8gVk0g
c3VwcG9ydCBpcyBhY3RpdmF0ZWQgYW5kIHRoZXJlIGlzIG5vIHN1aXRhYmxlIEZGLUEgc3VwcG9y
dA0KPj4gaW4gdGhlIGZpcm13YXJlLCBlbmFibGUgRkYtQSBzdXBwb3J0IGZvciBWTXMgdG8gYWxs
b3cgdXNpbmcgaXQgZm9yIFZNIHRvDQo+PiBWTSBjb21tdW5pY2F0aW9ucy4NCj4+IElmIHRoZXJl
IGlzIE9QLVRFRSBydW5uaW5nIGluIHRoZSBzZWN1cmUgd29ybGQgYW5kIHVzaW5nIHRoZSBub24g
RkYtQQ0KPj4gY29tbXVuaWNhdGlvbiBzeXN0ZW0sIGhhdmluZyBDT05GSUdfRkZBX1ZNX1RPX1ZN
IGNvdWxkIGJlIG5vbiBmdW5jdGlvbmFsDQo+PiAoaWYgb3B0ZWUgaXMgcHJvYmVkIGZpcnN0KSBv
ciBPUC1URUUgY291bGQgYmUgbm9uIGZ1bmN0aW9uYWwgKGlmIEZGLUEgaXMNCj4+IHByb2JlZCBm
aXJzdCkgc28gaXQgaXMgbm90IHJlY29tbWVuZGVkIHRvIGFjdGl2YXRlIHRoZSBjb25maWd1cmF0
aW9uDQo+PiBvcHRpb24gZm9yIHN1Y2ggc3lzdGVtcy4NCj4+IA0KPj4gVG8gbWFrZSBidWZmZXIg
ZnVsbCBub3RpZmljYXRpb24gd29yayBiZXR3ZWVuIFZNcyB3aGVuIHRoZXJlIGlzIG5vDQo+PiBm
aXJtd2FyZSwgcmV3b3JrIHRoZSBub3RpZmljYXRpb24gaGFuZGxpbmcgYW5kIG1vZGlmeSB0aGUg
Z2xvYmFsIGZsYWcgdG8NCj4+IG9ubHkgYmUgdXNlZCBhcyBjaGVjayBmb3IgZmlybXdhcmUgbm90
aWZpY2F0aW9uIHN1cHBvcnQgaW5zdGVhZC4NCj4+IA0KPj4gU2lnbmVkLW9mZi1ieTogQmVydHJh
bmQgTWFycXVpcyA8YmVydHJhbmQubWFycXVpc0Bhcm0uY29tPg0KPj4gLS0tDQo+PiBDaGFuZ2Vz
IGluIHY1Og0KPj4gLSBpbml0IGN0eCBsaXN0IHdoZW4gdGhlcmUgaXMgbm8gZmlybXdhcmUNCj4+
IC0gcmV3b3JrIGluaXQgYSBiaXQgdG8gcHJldmVudCBkdXBsaWNhdGVzDQo+PiAtIFJlbW92ZSBK
ZW5zIFItYiBkdWUgdG8gY2hhbmdlcyBkb25lDQo+PiBDaGFuZ2VzIGluIHY0Og0KPj4gLSBGaXgg
T3B0ZWUgdG8gT1AtVEVFIGluIGNvbW1pdCBtZXNzYWdlDQo+PiAtIEFkZCBKZW5zIFItYg0KPj4g
Q2hhbmdlcyBpbiB2MzoNCj4+IC0gZml4IHR5cG9zIGluIGNvbW1pdCBtZXNzYWdlDQo+PiAtIGFk
ZCBzcGFjZXMgYXJvdW5kIDw8DQo+PiAtIG1vdmUgbm90aWZpY2F0aW9uIGlkIGZpeCBiYWNrIGlu
dG8gYnVmZmVyIGZ1bGwgcGF0Y2gNCj4+IC0gZml4IHwgcG9zaXRpb24gaW4gaWYNCj4+IENoYW5n
ZXMgaW4gdjI6DQo+PiAtIHJlcGxhY2UgaWZkZWYgd2l0aCBJU19FTkFCTEVEIHdoZW4gcG9zc2li
bGUNCj4+IC0tLQ0KPj4geGVuL2FyY2gvYXJtL3RlZS9mZmEuYyAgICAgICB8ICAyNCArKysrKyst
LQ0KPj4geGVuL2FyY2gvYXJtL3RlZS9mZmFfbm90aWYuYyB8IDEwNCArKysrKysrKysrKysrKysr
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gMiBmaWxlcyBjaGFuZ2VkLCA2NyBpbnNlcnRpb25zKCsp
LCA2MSBkZWxldGlvbnMoLSkNCj4+IA0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS90ZWUv
ZmZhLmMgYi94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jDQo+PiBpbmRleCBjMWM0YzA5NTcwOTEuLmI4
NmM4OGNlZmE4YyAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+ICsr
KyBiL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+IEBAIC0zNDIsOCArMzQyLDkgQEAgc3RhdGlj
IGludCBmZmFfZG9tYWluX2luaXQoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICAgICBzdHJ1Y3QgZmZh
X2N0eCAqY3R4Ow0KPj4gICAgIGludCByZXQ7DQo+PiANCj4+IC0gICAgaWYgKCAhZmZhX2Z3X3Zl
cnNpb24gKQ0KPj4gKyAgICBpZiAoICFJU19FTkFCTEVEKENPTkZJR19GRkFfVk1fVE9fVk0pICYm
ICFmZmFfZndfdmVyc2lvbiApDQo+PiAgICAgICAgIHJldHVybiAtRU5PREVWOw0KPj4gKw0KPj4g
ICAgIC8qDQo+PiAgICAgICogV2UgYXJlIHVzaW5nIHRoZSBkb21haW5faWQgKyAxIGFzIHRoZSBG
Ri1BIElEIGZvciBWTXMgYXMgRkYtQSBJRCAwIGlzDQo+PiAgICAgICogcmVzZXJ2ZWQgZm9yIHRo
ZSBoeXBlcnZpc29yIGFuZCB3ZSBvbmx5IHN1cHBvcnQgc2VjdXJlIGVuZHBvaW50cyB1c2luZw0K
Pj4gQEAgLTU3OSwxMSArNTgwLDggQEAgc3RhdGljIGJvb2wgZmZhX3Byb2JlKHZvaWQpDQo+PiAg
ICAgICAgIGdvdG8gZXJyX3J4dHhfZGVzdHJveTsNCj4+IA0KPj4gICAgIGZmYV9ub3RpZl9pbml0
KCk7DQo+PiAtICAgIElOSVRfTElTVF9IRUFEKCZmZmFfdGVhcmRvd25faGVhZCk7DQo+PiAtICAg
IElOSVRfTElTVF9IRUFEKCZmZmFfY3R4X2hlYWQpOw0KPj4gLSAgICBpbml0X3RpbWVyKCZmZmFf
dGVhcmRvd25fdGltZXIsIGZmYV90ZWFyZG93bl90aW1lcl9jYWxsYmFjaywgTlVMTCwgMCk7DQo+
PiANCj4+IC0gICAgcmV0dXJuIHRydWU7DQo+PiArICAgIGdvdG8gZXhpdDsNCj4+IA0KPj4gZXJy
X3J4dHhfZGVzdHJveToNCj4+ICAgICBmZmFfcnh0eF9kZXN0cm95KCk7DQo+PiBAQCAtNTkyLDYg
KzU5MCwyMiBAQCBlcnJfbm9fZnc6DQo+PiAgICAgYml0bWFwX3plcm8oZmZhX2Z3X2FiaV9zdXBw
b3J0ZWQsIEZGQV9BQklfQklUTUFQX1NJWkUpOw0KPj4gICAgIHByaW50ayhYRU5MT0dfV0FSTklO
RyAiQVJNIEZGLUEgTm8gZmlybXdhcmUgc3VwcG9ydFxuIik7DQo+PiANCj4+ICtleGl0Og0KPj4g
KyAgICBpZiAoIElTX0VOQUJMRUQoQ09ORklHX0ZGQV9WTV9UT19WTSkgfHwgZmZhX2Z3X3ZlcnNp
b24gKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBJTklUX0xJU1RfSEVBRCgmZmZhX3RlYXJkb3du
X2hlYWQpOw0KPj4gKyAgICAgICAgSU5JVF9MSVNUX0hFQUQoJmZmYV9jdHhfaGVhZCk7DQo+PiAr
ICAgICAgICBpbml0X3RpbWVyKCZmZmFfdGVhcmRvd25fdGltZXIsIGZmYV90ZWFyZG93bl90aW1l
cl9jYWxsYmFjaywgTlVMTCwgMCk7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgaWYgKCBJU19F
TkFCTEVEKENPTkZJR19GRkFfVk1fVE9fVk0pICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJp
bnRrKFhFTkxPR19JTkZPICJBUk0gRkYtQSBvbmx5IGF2YWlsYWJsZSBiZXR3ZWVuIFZNc1xuIik7
DQo+IA0KPiBUaGlzIHNob3VsZCBvbmx5IGJlIHByaW50ZWQgaWYgZmZhX2Z3X3ZlcnNpb24gPT0g
MA0KDQpSaWdodCBpIHdpbGwgZml4IGJ1dCAuLi4NCg0KPiANCj4+ICsgICAgICAgIHJldHVybiB0
cnVlOw0KPj4gKyAgICB9DQo+PiArICAgIGVsc2UgaWYgKCBmZmFfZndfdmVyc2lvbiApDQo+IA0K
PiBUaGUgZWxzZSBpc24ndCBuZWVkZWQuDQoNCnRoZSBlbHNlIGlzIG5lZWRlZCBzbyB0aGF0IHdl
IHJldHVybiB0cnVlIGFuZCBub3QgZmFsc2UuDQoNCldlIGhhdmUgMyBjYXNlczoNCi0gZmlybXdh
cmUgaXMgdGhlcmU6IHJldHVybiB0cnVlDQotIGZpcm13YXJlIG5vdCB0aGVyZSBidXQgdm0gdG8g
dm0gZW5hYmxlOiByZXR1cm4gdHJ1ZQ0KLSBvdGhlcndpc2U6IHJldHVybiBmYWxzZQ0KDQpJIHdp
bGwgbW9kaWZ5IGl0IGxpa2UgdGhpcyB0byBtYWtlIGl0IGNsZWFyZXI6DQpkaWZmIC0tZ2l0IGEv
eGVuL2FyY2gvYXJtL3RlZS9mZmEuYyBiL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCmluZGV4IDU3
YjY0OGEyMjg0MC4uNzY4YjRlOWVjOTY4IDEwMDY0NA0KLS0tIGEveGVuL2FyY2gvYXJtL3RlZS9m
ZmEuYw0KKysrIGIveGVuL2FyY2gvYXJtL3RlZS9mZmEuYw0KQEAgLTYwMSwxMyArNjAxLDEzIEBA
IGV4aXQ6DQogICAgICAgICBpbml0X3RpbWVyKCZmZmFfdGVhcmRvd25fdGltZXIsIGZmYV90ZWFy
ZG93bl90aW1lcl9jYWxsYmFjaywgTlVMTCwgMCk7DQogICAgIH0NCg0KLSAgICBpZiAoIElTX0VO
QUJMRUQoQ09ORklHX0ZGQV9WTV9UT19WTSkgKQ0KKyAgICBpZiAoIGZmYV9md192ZXJzaW9uICkN
CisgICAgICAgIHJldHVybiB0cnVlOw0KKyAgICBlbHNlIGlmICggSVNfRU5BQkxFRChDT05GSUdf
RkZBX1ZNX1RPX1ZNKSApDQogICAgIHsNCiAgICAgICAgIHByaW50ayhYRU5MT0dfSU5GTyAiQVJN
IEZGLUEgb25seSBhdmFpbGFibGUgYmV0d2VlbiBWTXNcbiIpOw0KICAgICAgICAgcmV0dXJuIHRy
dWU7DQogICAgIH0NCi0gICAgZWxzZSBpZiAoIGZmYV9md192ZXJzaW9uICkNCi0gICAgICAgIHJl
dHVybiB0cnVlOw0KDQogICAgIHJldHVybiBmYWxzZTsNCiB9DQoNClRlbGwgbWUgaWYgeW91IGFn
cmVlLg0KDQpDaGVlcnMNCkJlcnRyYW5kDQoNCg==


From xen-devel-bounces@lists.xenproject.org Thu May 22 08:19:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:19:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993197.1376640 (Exim 4.92)
	(envelope-from )
	id 1uI19G-000709-G4; Thu, 22 May 2025 08:19:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993197.1376640; Thu, 22 May 2025 08: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 1uI19G-000702-DK; Thu, 22 May 2025 08:19:30 +0000
Received: by outflank-mailman (input) for mailman id 993197;
 Thu, 22 May 2025 08:19:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI19F-0006FR-2c
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:19:29 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20608.outbound.protection.outlook.com
 [2a01:111:f403:2406::608])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7a4851a1-36e5-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 10:19:27 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CYYPR12MB8940.namprd12.prod.outlook.com (2603:10b6:930:bd::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.22; Thu, 22 May
 2025 08:19:22 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.019; Thu, 22 May 2025
 08:19: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" 
X-Inumbo-ID: 7a4851a1-36e5-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BisBPan5gIwhPtCeTwo3AVJ6peS+Sva24HtjD7SXhaWpRzSHpVQmLHNtDd/UDgx6m7U5r1VUrCTFL7CQBfAW5/KZcOgTqQ1mp8b1SUcBVTeZCmzwTp5xTewFu0Gt6hQpOosdcWjROKbsdEwE2rJ7LGCtEe+Ijr+llFp72r0XHhSehipuAFM8jI1AIkThI6EJm3NtqVD9szZ+Ts1CjiSbAmoiR8KwNk1k3fctZ6cUmLWNRIa42PvIQq+YBDEK9az6nM/QclGhOzs1qfVoCZpUNjCDN1a5royjIUB3OYsXedTWDseevqnIZYDv2jQP/MfNzNsClVloQnTUaA0kPr06Ag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lLOkqDNf69QhHHgjWOU//VCf3VKO5hIug8BBi2sn3rY=;
 b=xMr2AKm6fu43dh5pylSgKF3NGCaM8xaJGlJ8oLP3jbvgAOlS+LPgMaKIXo/J6hPoR66t02IH0mHn2RlcT2b4HxVqv3MkYBocCIKCqLzNRPKE/KN+Ba7yKmOnlBEVbeLMbzFDc+Bv0gU521kmBvBp1b6JUxCY3THHeC5nyaiA3/rbHk4VaFBY3XDf2j4U6kGZwhmmBCU95x0Xt2/R9PwSkNDYZ9FPuf+ZCx/N1JrsjQie/cOx/+noheBRbGFVU50N0RdtAjeBdK5gMkrPFsrAzIL0/FuPCZEdivlgK/HFsaYaIhVKwisMTq49cLUCYxILfBpYw27CkGGPDL5bEcyDMA==
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=lLOkqDNf69QhHHgjWOU//VCf3VKO5hIug8BBi2sn3rY=;
 b=xEpo75fxSkf9+GJHifrdJu1kCJ2NJPEl+LmM2YxIBGjUgCzhXnkNx9tF8YYpe5uJOd4M72Ux6pbmFIw0djz2jWgsRgllCiiXpdfV0TSvl4hc5mS39/n1yUgqajjje7SH3O38V3RmqHjJLUKXkBC3ceOKIl38dHjohQ8m39fVwDE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <66db0b1b-c62b-4b84-9c01-12b1f93cc86d@amd.com>
Date: Thu, 22 May 2025 10:19:18 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 4/6] arm/mpu: Provide access to the MPU region from the
 C code
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-5-luca.fancellu@arm.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250513084532.4059388-5-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0262.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:e8::6) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CYYPR12MB8940:EE_
X-MS-Office365-Filtering-Correlation-Id: ac6ff4fe-4602-421d-db55-08dd99095b21
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MHpiQ3JzcDBLSE9VZzhaVCtzcG9XUWpjWDByQ0ZLclJkNlFyU1JrbWpWbFBF?=
 =?utf-8?B?SEw3QWpOY1VoaGEwdlBDWGtiUHhwenVtelQ0WVZOSUQvT0RYUk9PSC85bmty?=
 =?utf-8?B?THJUNWV4Y0RTY1NIRWRyWXI5WFJzUm9KN2w0RkxDTVE4Q1FlSW91U0pmcm1L?=
 =?utf-8?B?QTlBTjJFTEJKL1Y3bzEvTmQ3YWY3Z3F3K0hmemYzRUtNZFFTYSsrcHVTbklW?=
 =?utf-8?B?NUhidlF5VnlsVFFzdUJaVFdRcFpEVnl2eTkzWUtwZ0IzN0diN080WEFRbFB0?=
 =?utf-8?B?cUVOQWQ3VThIL09ISE9lWWdhRDIvbC9pQkhmRlplOUJiWjh4YmU2d1FXM3Bq?=
 =?utf-8?B?Y1NOR1dxR1Z1cGQzNVBuTWh3bHBpVWhHWEh5OWhBOUpMSEd6ZGtCNEIrT3Vz?=
 =?utf-8?B?TUhYQVArRGUwOTN2aHlzUlA4a1R3MEpwaVlUSWhUeHFTM0thWFhDUGJHai8x?=
 =?utf-8?B?VVFmc2RZTVFNempCNzZucmoxdGd6dkRCRjBhSUhSVS91d2kxd0JLMTJPMWMr?=
 =?utf-8?B?a0o3ZFk5cVFLQTZLbkhIRU96YVZEWlZTZGs2d2h6TFdRaXl3UWF3MHRvbnlO?=
 =?utf-8?B?T2ZoQUdGTEdBdk9SSEVmK1lLL1Z5ZkpXTjVyemFvUmJ5SUE0bVdCNlArVlht?=
 =?utf-8?B?OFJncUdGUEM5UVROaGpjNGhRMjN0UnNlWm5PbTc1RU9EWEphL3pVSlIwMlQ4?=
 =?utf-8?B?czJJUFlibU5TVkkrVkNCL0FwMUUwUVJrakFiUFFKNXFQSEE0WjZhN2xqSUxy?=
 =?utf-8?B?WkU3MmRLU1pRQlhON1VSRWNCYTJZR0JRYTdHUm9XRzd6N0ttMFcxVXRWSndM?=
 =?utf-8?B?TG4yb1lwb3dSOVRVNDVGTTNRdHRwR2wvd3J2Y0VBREpyNVhLTHBLMDAxZ0Y5?=
 =?utf-8?B?Y1I0b2R4TjRRejJtY1JHbUdiWnJ2YkxZOWs2bkJjRnJENDVoRms2VXA2UXhr?=
 =?utf-8?B?Q1QyeCtJMkIvRklQR21qc0Z4WGRUbE1oaDdHb2ZhaVBrZklFMkhIOUNqaWFY?=
 =?utf-8?B?YmVIcmZiS1pHT2ZwbDZ6bERpbjc4UXFHTll1V21xbEtTZXkwWWt2R01DOHl4?=
 =?utf-8?B?MXBhbUhXdTNTQ01leE8yVUhRWWk5K015RUhQZWxvbG1xN3o1ZmFxa0RINHdq?=
 =?utf-8?B?c1pZcVVJc2FjN3ZSRlE1WVlvQ29IdnRuMmwvVkxDSlZLRjd6OWtUMVAvdW1W?=
 =?utf-8?B?d09JYlJTWlhaengwRkZWekZBUkxKVmNUcmxHQUJBeENUTkxJL1NSU2FmNUNo?=
 =?utf-8?B?ZWIyczdNd3NCNjdrZ203cDZPdW90RVlpdUR1YmdaZk0ybnhWSEhoQkw0K29I?=
 =?utf-8?B?STdDcmpoZ3RTYmhjL1lIOUEwVkdjQi8wdVhPOGtCY0F6eTI5cEk1ZU1hQ2FZ?=
 =?utf-8?B?MGllRHMxcVkvbFRIOXRtdlF5eFVSc2JRM3VYbU1DY3F1bEhTYTI0OVlPNjF5?=
 =?utf-8?B?V1MvTkY2Sm4vVitEZ29ZdXNVZVdTNzQzZFBERStYTWc1cWVRT3Q2RXdIL0E2?=
 =?utf-8?B?QU4yV3ZCY2lpdWtQMUh6UFlvdHlUaXYrd0crS3l3MGRjN2N5RE5UN295anJm?=
 =?utf-8?B?VGUrL0U1VDRUeUNiNnV6a2Q5OFVRQSszdDBqVnBiT2JpL04xc1BOUlJNY0t6?=
 =?utf-8?B?d1lyenMrZ1Z5NGluVkFVVVFIZmhEUncxbWxBdXA5WkhxVVVSWS9hRnZKRVVs?=
 =?utf-8?B?eHdGL3M1TllyS3I2c0RIZ2FHazIwaFp2cktORkd1ZVI0ZWNRdGsrODA3dG5D?=
 =?utf-8?B?dHBKUC9pVSs5enovYjcxTjNHSHVxRXhXRFFMa0lIc3FweGMwd0tUTCtnY3hv?=
 =?utf-8?B?bXNGendWTEx2UFp2aTdrL2JjSXFjV0VSbEg5Z3p3bThPQk16RVhobEtBUnBo?=
 =?utf-8?B?Q21wVlU2ZmtwazlLQ3JEK29WMCtHTklSamVsQm0rQ1daR1BFbUhyYUhXb0ZH?=
 =?utf-8?Q?2ki4rKlWB7E=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?REtzTXJYNVJYVHNkZndBRG1XYzF2UHZiZXVhaHpMQmI0clZMR2NYcFZGWXRi?=
 =?utf-8?B?eDlqVGFDcWNtQ3Mybi9FbEZjVmQ3RHBTUVNqZHU0a09RMVUyVVc2OGk4R0hh?=
 =?utf-8?B?VXdoeHl1RVRBWHlCQVkvTDFEZ2I0QlNiUG1mUExIY0RoMy9Hc1NXVllXeGs0?=
 =?utf-8?B?Ry8weTJwc3daT2tCN0dFa0tKTVk2WGdMZjV5UjhGQ3BYQlFLM1VCcEpxU2tT?=
 =?utf-8?B?aGNGbTF1MDFUelRaSUhKM1FDcVk4aGo2OGF5UDJLOENtSlU0MjlYL3VvQW41?=
 =?utf-8?B?U2NCTjIzOHdwUllxWi9rcFBmRmlaVk8zRUpvTTFkaGRiVHlpaHpvcCtwSVhy?=
 =?utf-8?B?TG1uekR0RGp3V1hPT3Z4OWRGbTUvZlc5YWZzMEMycFlhYkxrQmxuK1dOT3Mz?=
 =?utf-8?B?b1hpRFZOOW12M0hxOHY3RzIrSFBQQ3FIQ2RRN1k1TkUwZlNlWGpsR1laVVg3?=
 =?utf-8?B?bFEwSDFiT3Jubll0eG9qb2psNm90MjRJNFhIRlpsOHJVS2lJY2FEOUpuMHNB?=
 =?utf-8?B?RHlTYzJrWWFXVmRvRTZ3WFlaUjVkblBVNnB0SFhST3J5aFR1RXN4M0g2T0F3?=
 =?utf-8?B?Sk8rYWtCblYwSCtVZC8vbzRkR3JPZWtvY1hJbFRXb1NwSTRWNEJMM1lFb0VQ?=
 =?utf-8?B?dTI5OFYwN05abnY5TytqNlZ0NWI2WnFHRGtLSjYyZ3IzY3VPQUttVVpCbk1o?=
 =?utf-8?B?djdROEpDUHB2dkhTbDlQVVhQN0I5YVB4SGQ5N08yV08zajR2TjZ2WXRvK1d3?=
 =?utf-8?B?bmZnM2RWd0NMUHV1enIwSVRQam5IT1EzelY4KzN4QlBpdFBEVzVzQkZmTzNo?=
 =?utf-8?B?MnJsUVZ0SE51M0dOaVJvMXBGU1BGbmJEcDRzbG9nK29hWU8xM2dLWUxoRUd3?=
 =?utf-8?B?SG52RCtyUjU2MlhvL1V5Wkp4eTJQMy9vR05WbklkbkhEQlh6RU53UlBLTDc2?=
 =?utf-8?B?Z1ZNLytxSWNqZW1uQ2EycllzT1hZVjZUNWZudnU0SHFDUzRMR1czQzduZkI4?=
 =?utf-8?B?Si9NekZqc0RaNzk5THB4cUljUzRhTVQ4QVVoakd1YzdXMFdGdlIzMDVhNnZC?=
 =?utf-8?B?Z2RYS3hRTEl2NzJjN1dCak0wR2ZvcnZSajNDZmxYd05DVmk3TzBja3hmOW5O?=
 =?utf-8?B?QXRaaGc0NFdQb3FheHFjcXZROEdkcElQZUxYb2ZOcGk0Q3FWTDBqcEhSd3FC?=
 =?utf-8?B?Ly9aVXljenlGSnNvQ1RqUHNUK1NSeEFYMnNlaXRLR0dmbUZqaWZZYmk1UlZI?=
 =?utf-8?B?bEI4Nk91RnJVY1U4Y05zRDlEQ3I3T3Z4M215KzBZSzA0T2c4cHZMTDRaZWVj?=
 =?utf-8?B?UkpnRE9KSm9nUlZPVW5WZmNpUURKZXJmLzN0cDJKTHFrYWJackRJbGozNWlh?=
 =?utf-8?B?cW42ZlpsTWdCRXRMbTdHQ1kxT0JlKzVUWHZKVzlJQWUrWU5jdEdlMWhybmt4?=
 =?utf-8?B?c1N6RzNBdWNGTlRCdlQ4d2xjSzJqVTVBSkNWRnk4eGtHZGRmVXNPSjJEOGlx?=
 =?utf-8?B?dEgxN2hOdXp2V0IwRy84dWhKdUIzTStuc3pIZmh2WnZmbHBtNFRvaEd5QW5F?=
 =?utf-8?B?MnltM25JZkZGVzBGcDcrOEFQcEV4dWVSMXo3U3JBYklsWTNOT3N4SEZRVnc4?=
 =?utf-8?B?MFdkNXA5ZExXbWtrQ3hIcy9FWXZ6bjV2NlVLYklMclErNUVRMU1OdmFxbzhu?=
 =?utf-8?B?N21iQzNHNnFGWDQxaGtXWVJSdldHUnJCYU4wOWg4SVRaVFVieDI3K3ZhSGt6?=
 =?utf-8?B?Tkh3S1RYNmw4TllFR1NlMkVLTDJrelcycHFZNWd1NkxaUjR2VGd2b2NHa3hy?=
 =?utf-8?B?c1duTDJSNDhqOExyNG04c0ZnWldwb2V5U3R5Y0NCakRrSEtiUmhWd3VJK3hX?=
 =?utf-8?B?LzJ0OU9yUWo3VUc0ZnRKYUMwcXBmYkJmL0RINk96WHR6bTBPb3VsZ0lrQVVJ?=
 =?utf-8?B?S2NCWHZ5aVZBOHpOTXNKL2NPSDZ4ZFdrckJ4K2VoeUZtWitvYzc1aTRBUHc1?=
 =?utf-8?B?MldqMCtmb0JQbDN5V2dPUUIyWnYxL21ZcnppNFQxUFNsc3VUb3RoNmxPR0lo?=
 =?utf-8?B?R2dQYXIzR0RtYTMrb0t2Yk4rZHlLR3hQRkQxU3hqNy80c1lxZTJ0L2FveDQ0?=
 =?utf-8?Q?S64vq41Z5OMdTdhAhQU75EgvT?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ac6ff4fe-4602-421d-db55-08dd99095b21
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 08:19:22.1136
 (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: o0KM4ON+aumnWuwVi1Bb//tr143PnIaPm8bSt1frEjA9bE0dW//vNYVAQZ6BH1mI
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8940



On 13/05/2025 10:45, Luca Fancellu wrote:
> Implement some utility function in order to access the MPU regions
NIT: s/function/functions

> from the C world.
> 
> Signed-off-by: Luca Fancellu 
> ---
> v5 changes:
>  - move MPU_REGION_RES0 to arm64, fixed typos and code style.
> v4 changes:
>  - moved back PRBAR0_EL2/PRLAR0_EL2 to mm.c and protect
>    them with CONFIG_ARM_64, changed comments, fixed typos and code
>    style
>  - Add PRBAR_EL2_(n) definition, to be overriden by Arm32
>  - protect prepare_selector, read_protection_region,
>    write_protection_region by Arm64 to ensure compilation on both
>    arm32 and arm64, Arm32 will modify that later while introducing
>    the arm32 bits.
> v3 changes:
>  - Moved PRBAR0_EL2/PRLAR0_EL2 to arm64 specific
>  - Modified prepare_selector() to be easily made a NOP
>    for Arm32, which can address up to 32 region without
>    changing selector and it is also its maximum amount
>    of MPU regions.
> ---
> ---
>  xen/arch/arm/include/asm/arm64/mpu.h |   2 +
>  xen/arch/arm/include/asm/mpu/mm.h    |  34 ++++++++
>  xen/arch/arm/mpu/mm.c                | 119 +++++++++++++++++++++++++++
>  3 files changed, 155 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h
> index d3c055a2e53b..0fed6c8e5828 100644
> --- a/xen/arch/arm/include/asm/arm64/mpu.h
> +++ b/xen/arch/arm/include/asm/arm64/mpu.h
> @@ -5,6 +5,8 @@
>  
>  #ifndef __ASSEMBLY__
>  
> +#define MPU_REGION_RES0        (0xFFFFULL << 48)
> +
>  /* Protection Region Base Address Register */
>  typedef union {
>      struct __packed {
> diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
> index 409b4dd53dc6..2ee908801665 100644
> --- a/xen/arch/arm/include/asm/mpu/mm.h
> +++ b/xen/arch/arm/include/asm/mpu/mm.h
> @@ -41,6 +41,40 @@ static inline struct page_info *virt_to_page(const void *v)
>      return mfn_to_page(mfn);
>  }
>  
> +/* Utility function to be used whenever MPU regions are modified */
> +static inline void context_sync_mpu(void)
> +{
> +    /*
> +     * ARM DDI 0600B.a, C1.7.1
> +     * Writes to MPU registers are only guaranteed to be visible following a
> +     * Context synchronization event and DSB operation.
Isn't it misleading to people reading this code that does not match when it
comes to order of operations?

> +     */
> +    dsb(sy);
> +    isb();
> +}
> +
> +/*
> + * The following API requires context_sync_mpu() after being used to modify MPU
> + * regions:
> + *  - write_protection_region
> + */
> +
> +/*
> + * Reads the MPU region with index @sel from the HW.
> + *
> + * @pr_read: mpu protection region returned by read operation.
> + * @sel: which mpu protection region to read
NIT: I mentioned that in the past that I find it a bit too much duplicated
information in the comment. It could very well be:
/* Reads the MPU region (into @pr_read) with index @sel from the HW */

> + */
> +void read_protection_region(pr_t *pr_read, uint8_t sel);
> +
> +/*
> + * Writes the MPU region with index @sel to the HW.
> + *
> + * @pr_write: mpu protection region passed through write operation.
> + * @sel: which mpu protection region to write
> + */
> +void write_protection_region(const pr_t *pr_write, uint8_t sel);
> +
>  #endif /* __ARM_MPU_MM_H__ */
>  
>  /*
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index ee035a54b942..46883cbd4af9 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -8,6 +8,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  struct page_info *frame_table;
>  
> @@ -26,6 +28,35 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
>  /* EL2 Xen MPU memory region mapping table. */
>  pr_t __section(".data.page_aligned") xen_mpumap[MAX_MPU_REGION_NR];
>  
> +#ifdef CONFIG_ARM_64
> +/*
> + * The following are needed for the cases: GENERATE_WRITE_PR_REG_CASE
> + * and GENERATE_READ_PR_REG_CASE with num==0
> + */
> +#define PRBAR0_EL2 PRBAR_EL2
> +#define PRLAR0_EL2 PRLAR_EL2
> +
> +#define PRBAR_EL2_(n)   PRBAR##n##_EL2
> +#define PRLAR_EL2_(n)   PRLAR##n##_EL2
> +
> +#endif
> +
> +#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
> +    case num:                                                               \
> +    {                                                                       \
> +        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
> +        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
> +        break;                                                              \
> +    }
> +
> +#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
> +    case num:                                                   \
> +    {                                                           \
> +        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
> +        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
> +        break;                                                  \
> +    }
> +
>  static void __init __maybe_unused build_assertions(void)
>  {
>      /*
> @@ -36,6 +67,94 @@ static void __init __maybe_unused build_assertions(void)
>      BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
>  }
>  
> +#ifdef CONFIG_ARM_64
> +/*
> + * Armv8-R supports direct access and indirect access to the MPU regions through
> + * registers:
> + *  - indirect access involves changing the MPU region selector, issuing an isb
> + *    barrier and accessing the selected region through specific registers
> + *  - direct access involves accessing specific registers that point to
> + *    specific MPU regions, without changing the selector, avoiding the use of
> + *    a barrier.
> + * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR_ELx (for n=1..15) are
> + * used for the direct access to the regions selected by
> + * PRSELR_EL2.REGION<7:4>:n, so 16 regions can be directly accessed when the
> + * selector is a multiple of 16, giving access to all the supported memory
> + * regions.
> + */
> +static void prepare_selector(uint8_t *sel)
> +{
> +    uint8_t cur_sel = *sel;
> +
> +    /*
> +     * {read,write}_protection_region works using the direct access to the 0..15
> +     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
> +     * only when needed, so when the upper 4 bits of the selector will change.
> +     */
> +    cur_sel &= 0xF0U;
Here you use &=
+NIT: you could do that at the definition (but maybe it's clearer this way in
your opinion)

> +    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
> +    {
> +        WRITE_SYSREG(cur_sel, PRSELR_EL2);
> +        isb();
> +    }
> +    *sel = *sel & 0xFU;
but here you don't.

> +}
> +
> +void read_protection_region(pr_t *pr_read, uint8_t sel)
> +{
> +    prepare_selector(&sel);
> +
> +    switch ( sel )
> +    {
> +        GENERATE_READ_PR_REG_CASE(0, pr_read);
> +        GENERATE_READ_PR_REG_CASE(1, pr_read);
> +        GENERATE_READ_PR_REG_CASE(2, pr_read);
> +        GENERATE_READ_PR_REG_CASE(3, pr_read);
> +        GENERATE_READ_PR_REG_CASE(4, pr_read);
> +        GENERATE_READ_PR_REG_CASE(5, pr_read);
> +        GENERATE_READ_PR_REG_CASE(6, pr_read);
> +        GENERATE_READ_PR_REG_CASE(7, pr_read);
> +        GENERATE_READ_PR_REG_CASE(8, pr_read);
> +        GENERATE_READ_PR_REG_CASE(9, pr_read);
> +        GENERATE_READ_PR_REG_CASE(10, pr_read);
> +        GENERATE_READ_PR_REG_CASE(11, pr_read);
> +        GENERATE_READ_PR_REG_CASE(12, pr_read);
> +        GENERATE_READ_PR_REG_CASE(13, pr_read);
> +        GENERATE_READ_PR_REG_CASE(14, pr_read);
> +        GENERATE_READ_PR_REG_CASE(15, pr_read);
> +    default:
> +        BUG(); /* Can't happen */
I think that MISRA requires adding break even for impossible default cases.

> +    }
> +}
> +
> +void write_protection_region(const pr_t *pr_write, uint8_t sel)
> +{
> +    prepare_selector(&sel);
> +
> +    switch ( sel )
> +    {
> +        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
> +        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
> +    default:
> +        BUG(); /* Can't happen */
> +    }
> +}
> +#endif
Please add /* CONFIG_ARM_64 */

> +
>  void __init setup_mm(void)
>  {
>      BUG_ON("unimplemented");

Other than that:
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Thu May 22 08:31:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:31:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993211.1376650 (Exim 4.92)
	(envelope-from )
	id 1uI1KM-00020S-Mt; Thu, 22 May 2025 08:30:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993211.1376650; Thu, 22 May 2025 08:30: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 1uI1KM-00020L-JC; Thu, 22 May 2025 08:30:58 +0000
Received: by outflank-mailman (input) for mailman id 993211;
 Thu, 22 May 2025 08:30:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI1KL-0001z8-Fi
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:30:57 +0000
Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com
 [2607:f8b0:4864:20::c29])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 14662097-36e7-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 10:30:56 +0200 (CEST)
Received: by mail-oo1-xc29.google.com with SMTP id
 006d021491bc7-6021e3daeabso4097995eaf.3
 for ; Thu, 22 May 2025 01:30:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 14662097-36e7-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747902655; x=1748507455; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kQT+aGoqV4JMu0Aj/XrzebHqrG3rh4Nwn3I2DCSc7bc=;
        b=Tvb3mxtuLBOUOxacr6pBwuJcfVdMtix4W2aUwVwHDDMdFxGcSLKZNneJyFdFnNpQj1
         z2cIbFPWjYdOHTwaE+nU5wt6CVg6eaTc1Q4WySJjh83kG8iU5cDlDfiUd6XpTOPS4fCw
         +oGkrve+e1p+r2dzKmPGyi19ZTFyhOjVnoO+5S8OXZ+LeYe5M3jznAFVb+l3dAlvTfBa
         K8c9OSAum5baaD47F36zrwl0FFYq9quIIGpR0949/tE42g4Lhsw+yzw27hC5gdNATgnL
         kaThITfORlY3McvjiOPT8fu264JmRXABzng2FNDJXuTJC8cPPz+ypwdEJhI0Jj3czSuZ
         y4eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747902655; x=1748507455;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=kQT+aGoqV4JMu0Aj/XrzebHqrG3rh4Nwn3I2DCSc7bc=;
        b=PDvjndZN9llKgXsxca91XECMeTPX/n3NGJ53G2OOLhRRIWV5UUg8UtMBOzYjXqflvt
         eBMUqYwcp1VQSfcgFzgw4WTIoRGBb0WAcSw5kS4OdfJtDOETLx5OuelKFL+gBuQvQpE/
         ADHRbcUTlY3rDfmBn2Hpv1RIX59XIW8aom/9vdslArY8by0IbkqY+LxYVsacrNUm6bt1
         21Roa2MamJDklk/ujrZDMZLdne7qGzLWgghgNPmTKrKCIf5U8MHj1B0KpTDUeTS//clK
         xOAjXXW7q7CmRIUoeHs2gD5f8Ize8AZLRzIB54cwqpZ2OHPphprEHNwxBvWKor3FuFys
         eBgA==
X-Gm-Message-State: AOJu0YwU0+NxdoOL9d1pgOfgXOiuZVOPsXayWXHXOv5ATqIRSdTFKuQX
	kOqfHaWlHFfRP/Jd7dERIXs5hmdacMnOKUJ3or6eLSxkO+rth/mNUGQIiCIQ5DYScSInLoqYxu1
	55Jm15nxI5yRQOhWNMZvtfINloJ3OFMYzJMILSQEE/A==
X-Gm-Gg: ASbGncsvAfRmbBJl90m/1geZjQmoV840J/ds7VPIwOFgoiRQVsH978wAno/EZKz97t0
	iZfUJPo3v5yRsIf2GxiZxdh0i03lWKqY74s/uiJg0uOE1n32zqVBub/Uif8AlotZLEy6f8k9kSY
	XN81CDAXARZXHMhLfObcr33dXJbw+CtTt0Cg==
X-Google-Smtp-Source: AGHT+IE+JfJcr807f7Q6D/jccBPesa+UehwQHAq2MJXIU+j2Cv4gNjLI2dGs2j8zUpcnUl7ZuxUg2623FGtN8R5oY4s=
X-Received: by 2002:a05:6820:4a90:b0:60a:383:dbce with SMTP id
 006d021491bc7-60a0383dd43mr9035249eaf.8.1747902654919; Thu, 22 May 2025
 01:30:54 -0700 (PDT)
MIME-Version: 1.0
References: 
 
  
In-Reply-To: 
From: Jens Wiklander 
Date: Thu, 22 May 2025 10:30:43 +0200
X-Gm-Features: AX0GCFtfV2LAEVAGSPwHXgrNK0HisKb4sWpbAP7F5ZCdoAU-XQA-TQG66VLfszU
Message-ID: 
Subject: Re: [PATCH v5 6/6] xen/arm: ffa: Enable VM to VM without firmware
To: Bertrand Marquis 
Cc: "xen-devel@lists.xenproject.org" , 
	Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Michal Orzel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, May 22, 2025 at 10:18=E2=80=AFAM Bertrand Marquis
 wrote:
>
> Hi Jens,
>
> > On 22 May 2025, at 10:00, Jens Wiklander  wr=
ote:
> >
> > Hi Bertrand,
> >
> > On Wed, Apr 16, 2025 at 9:40=E2=80=AFAM Bertrand Marquis
> >  wrote:
> >>
> >> When VM to VM support is activated and there is no suitable FF-A suppo=
rt
> >> in the firmware, enable FF-A support for VMs to allow using it for VM =
to
> >> VM communications.
> >> If there is OP-TEE running in the secure world and using the non FF-A
> >> communication system, having CONFIG_FFA_VM_TO_VM could be non function=
al
> >> (if optee is probed first) or OP-TEE could be non functional (if FF-A =
is
> >> probed first) so it is not recommended to activate the configuration
> >> option for such systems.
> >>
> >> To make buffer full notification work between VMs when there is no
> >> firmware, rework the notification handling and modify the global flag =
to
> >> only be used as check for firmware notification support instead.
> >>
> >> Signed-off-by: Bertrand Marquis 
> >> ---
> >> Changes in v5:
> >> - init ctx list when there is no firmware
> >> - rework init a bit to prevent duplicates
> >> - Remove Jens R-b due to changes done
> >> Changes in v4:
> >> - Fix Optee to OP-TEE in commit message
> >> - Add Jens R-b
> >> Changes in v3:
> >> - fix typos in commit message
> >> - add spaces around <<
> >> - move notification id fix back into buffer full patch
> >> - fix | position in if
> >> Changes in v2:
> >> - replace ifdef with IS_ENABLED when possible
> >> ---
> >> xen/arch/arm/tee/ffa.c       |  24 ++++++--
> >> xen/arch/arm/tee/ffa_notif.c | 104 ++++++++++++++++-------------------
> >> 2 files changed, 67 insertions(+), 61 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> >> index c1c4c0957091..b86c88cefa8c 100644
> >> --- a/xen/arch/arm/tee/ffa.c
> >> +++ b/xen/arch/arm/tee/ffa.c
> >> @@ -342,8 +342,9 @@ static int ffa_domain_init(struct domain *d)
> >>     struct ffa_ctx *ctx;
> >>     int ret;
> >>
> >> -    if ( !ffa_fw_version )
> >> +    if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !ffa_fw_version )
> >>         return -ENODEV;
> >> +
> >>     /*
> >>      * We are using the domain_id + 1 as the FF-A ID for VMs as FF-A I=
D 0 is
> >>      * reserved for the hypervisor and we only support secure endpoint=
s using
> >> @@ -579,11 +580,8 @@ static bool ffa_probe(void)
> >>         goto err_rxtx_destroy;
> >>
> >>     ffa_notif_init();
> >> -    INIT_LIST_HEAD(&ffa_teardown_head);
> >> -    INIT_LIST_HEAD(&ffa_ctx_head);
> >> -    init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NULL=
, 0);
> >>
> >> -    return true;
> >> +    goto exit;
> >>
> >> err_rxtx_destroy:
> >>     ffa_rxtx_destroy();
> >> @@ -592,6 +590,22 @@ err_no_fw:
> >>     bitmap_zero(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
> >>     printk(XENLOG_WARNING "ARM FF-A No firmware support\n");
> >>
> >> +exit:
> >> +    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) || ffa_fw_version )
> >> +    {
> >> +        INIT_LIST_HEAD(&ffa_teardown_head);
> >> +        INIT_LIST_HEAD(&ffa_ctx_head);
> >> +        init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, =
NULL, 0);
> >> +    }
> >> +
> >> +    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> >> +    {
> >> +        printk(XENLOG_INFO "ARM FF-A only available between VMs\n");
> >
> > This should only be printed if ffa_fw_version =3D=3D 0
>
> Right i will fix but ...
>
> >
> >> +        return true;
> >> +    }
> >> +    else if ( ffa_fw_version )
> >
> > The else isn't needed.
>
> the else is needed so that we return true and not false.

I meant the "else" isn't needed, the "if" is still needed, as you explain.

>
> We have 3 cases:
> - firmware is there: return true
> - firmware not there but vm to vm enable: return true
> - otherwise: return false
>
> I will modify it like this to make it clearer:
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 57b648a22840..768b4e9ec968 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -601,13 +601,13 @@ exit:
>          init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NUL=
L, 0);
>      }
>
> -    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> +    if ( ffa_fw_version )
> +        return true;
> +    else if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
>      {
>          printk(XENLOG_INFO "ARM FF-A only available between VMs\n");
>          return true;
>      }
> -    else if ( ffa_fw_version )
> -        return true;
>
>      return false;
>  }
>
> Tell me if you agree.

Yes, this is an improvement. A return at the end of an if block makes
the eventual following "else" redundant. I suppose there are coding
styles where it's still preferred. I'm not sure if that applies in
Xen, though.

Cheers,
Jens

>
> Cheers
> Bertrand
>


From xen-devel-bounces@lists.xenproject.org Thu May 22 08:49:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:49:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993235.1376660 (Exim 4.92)
	(envelope-from )
	id 1uI1bi-0004Ug-5o; Thu, 22 May 2025 08:48:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993235.1376660; Thu, 22 May 2025 08:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI1bi-0004UZ-1Q; Thu, 22 May 2025 08:48:54 +0000
Received: by outflank-mailman (input) for mailman id 993235;
 Thu, 22 May 2025 08:48:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI1bh-0004UT-1X
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:48:53 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20619.outbound.protection.outlook.com
 [2a01:111:f403:2414::619])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9531915e-36e9-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 10:48:51 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by LV3PR12MB9213.namprd12.prod.outlook.com (2603:10b6:408:1a6::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.31; Thu, 22 May
 2025 08:48:47 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.019; Thu, 22 May 2025
 08:48: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" 
X-Inumbo-ID: 9531915e-36e9-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=d9i4o41MC2Zd5J0JPA3qDgQR7YTDWKHHAUGR75Z6HqTwaVh7nA7EOSCNTmaRrFu/oSNETA9BFk+v4pQ2G08+7cQQ9wH3WkIM56Lb0jXoNKATs9sVJUBTHeDz22ALZTEd7VgSX+eedbTAG5DFDBOuK6v5e3Lt1gcEJqE1OmBcNQqueBIWFN+LipINQTzuWwVHbsv/RmFOdSzTfmxDg99sVBdJp84WY32ajEILd4ogyvIVG9meqe83gzHscQbj2Ji2rPrIzT7JmdTC4UyGDMZ2JyeVjxUTeKbByVj6flw2BWFiu5irOTeOS7gUd0Ogb/Ex1CIb0Ra2Nrnq17WVbBqtWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=p1LBU9Kn1Os0qoiuZLo3U/AMfrFQTFFhLK8MerzpK2A=;
 b=pGiO6aQVBQNoITwjP3vsrd5lBQFMQDkUOEeSt4Xlfoiij9X3WOzF6cYL9dPjAVc9WvxNWgfdlNX9XeFk0QMKSdoYNBppMnuWu+I40jPx/ybq2ka8jMfC8h4NNVWWo8iIvt/ngTdT0gnVTPwLwsVr2b+p5pCNCKoUazvhkEmJ7bxyJ2r6yqRRMEjbOTxQ11vUeWbA5Dfvom2v4TPAugY7fZGIZH4atFi8/3if8kosTRrBeXy3qkiIzrTBUmBKG40oEnG7SosmN8NVf1znjZ3I6ZIG4BbI/Xi9iQD514Bv8Cr5ej3JbNCyNfVXmsk9uUt7QzOSjHVLP62D0cjjGa/ZqA==
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=p1LBU9Kn1Os0qoiuZLo3U/AMfrFQTFFhLK8MerzpK2A=;
 b=bNfMue4Aa0M5PLkjMy/JOu28bq6Gob9+PCOyN2vSXi6wVi90Nh8X/59MRjLdz+cGyiul7J9cEvDSs+dsym5U2ips4OaN8PQfWOrkDLKqeLUVdsM/EvvyPK1lV974SgTy/SL4Ztny0yhepS/kLcdPOQ0Qz0VfyW3Ij8MQxXg/Afs=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Thu, 22 May 2025 10:48:44 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 5/6] arm/mpu: Introduce utility functions for the pr_t
 type
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-6-luca.fancellu@arm.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250513084532.4059388-6-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DU2PR04CA0198.eurprd04.prod.outlook.com
 (2603:10a6:10:28d::23) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|LV3PR12MB9213:EE_
X-MS-Office365-Filtering-Correlation-Id: 513c4cd4-e2ab-483d-53f8-08dd990d776c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SUUvL3hzV3ZpZnMzbGRXM3FRVEdtZ09pa2FZLzV3bnkvZnhncWM0T25mTHBm?=
 =?utf-8?B?V09UeWRkOEZ3SE9Da2hYemZJcE1SaTJ2R05OdUxzYlVjOUtFUlpOTExWb2xN?=
 =?utf-8?B?Vmg3UExGNFJEQjdYWjlKS2JGcW05NlFCYWR3Z1BkenBOMzlaSzRWNjB2dlYx?=
 =?utf-8?B?bkxzeHFtR2hYNkpmWkUzUmdMdmJneDBaQTFLdE44QWhvTmNsR2Uwd0pveThv?=
 =?utf-8?B?RG5ZTVQ5MjJTMGMwSVBRS0MyOUhmNUF6NDJnK21xNEJHYTlNdlJqNVNDL1gz?=
 =?utf-8?B?ankxRHFsOUpqbnQ3cW5vS1QxWC9yc2tMRWwrNGFEQjFORVJIb29lZzI4V0lO?=
 =?utf-8?B?VU9zcmc2YkZiUGxML0ZKcTVkakRhWWJuejZYaDNaV0JOTTBJZWJsanZXM1Fu?=
 =?utf-8?B?QnYzZ2xuckEvNDdmZ2FMNThpVEJTU2FyakVtU1gxdXZ3eGJxZkd3clNaT1h2?=
 =?utf-8?B?NExraTMxTTdkWWN3d3ZPWk5CVzhBb1NnV1hVUWZzaFI2a3duWnJmZGFkWEpD?=
 =?utf-8?B?NENMbHpBU2RWcExSVytwSGZDZHJqbkZKMFNPZkdxdlJ5Y0FzbjlrcTQ5WCtI?=
 =?utf-8?B?bmk5dXNMRHFhd1lwZ0RmZjE4R3h2RVhvN29DazkzMTluRXpWc3Jmb0ZoRTdB?=
 =?utf-8?B?MWxZdDVtNmJDRmI0U0pOOG1tcDNrVzhDQTl2dEtmOVBWVjFXQ2hlTjBCUWIr?=
 =?utf-8?B?SjNUWkpJMndxV3o5dXRydWJtWUlXN3BFczBod2NQblBOYWt2TVUrYnN3YVc1?=
 =?utf-8?B?djQ0N3B6eGI2VkpNVERTQWlSOVVENVZxVWlOVEVWR2EySHhCSzVRL3R0MWFN?=
 =?utf-8?B?bm4vUHVmRlM0UHBDWG5qQnpjWjF5N0E4NFpsQ1FBZHNTN1N5U1ozaVJBSk96?=
 =?utf-8?B?bWJqOTVKcm9LNGpCK0J1RjA0ZlEwVmhaS0oxakF2R3ptditxdnE4bkVXSk0y?=
 =?utf-8?B?Vk5qaXBEUldVYmZ2bHA1MHB3cHRhTHVaV3RzSjlFRTIvSHhEZFczTWgvZklC?=
 =?utf-8?B?UVhqMlZ2dUJZU3FIcFQySEpKOSttbWs3YWdPQlJnYmxXMGlJREpCelV3aFRN?=
 =?utf-8?B?dTM3dkNkSjdka3kyQWVQYWJ0Yjh6c2RXNXBoeXk2a09xcFZvaGlXTzczSEtW?=
 =?utf-8?B?cldPWTdoSjVFRFZlY2krZjJ2am8vRHJIMUJUYytGVVhDS0dzeTF5SUZ2TEhl?=
 =?utf-8?B?alBaVlF0LzB6bkhMeDlqUUttUkRFZVBLRk5oRW9Gem52QWJiY2FjOTlCN2dB?=
 =?utf-8?B?bm8wWnBWOUdaUkFMdnkzTmhlbitwVk9qbzhnazk1aGVSL2wyd3FJWXdXNGlO?=
 =?utf-8?B?a1ZTT1BpL1M2b05uaXhPZUVuM2Ixc1dzS1Q1UmdKNmNHbi8rMUZudUNBTjNE?=
 =?utf-8?B?RDBYaUo5WkFUZjA2TjMyMkZUS3JuY0ZwZlhyVkdOdWtsbzJKaU1JSHcxRkJ2?=
 =?utf-8?B?eDJSY0xJQ1Zhd1pKM2pVRkRSbDJwQzFhVUtZNVA4SUc3OGkwTVB4WHptMzRZ?=
 =?utf-8?B?TUZPei9meVFjV0IwMncvbnY1N1MzR3F2WXNxaVppdFZjREZ6NkRhVmpzbWEv?=
 =?utf-8?B?OVFsMVFBMnFDblBLcXk5QjhHNEh1eUtWSW13YXl3MFp6RTFFRzkyQUg3eE9x?=
 =?utf-8?B?eXVUVU93Y0syWTN1UEIyb0NxVHVwOEFsbUNndFY3S3E1SDVSWGJyZ20ydTUw?=
 =?utf-8?B?MkZRcituU2thTDFycDlKcGtTa3paQXozZ1I4M0tEdnVrK281aFd5bVJDQ0JW?=
 =?utf-8?B?ZVEvWjhpT2R5aTRhNzlnSHc3SEl3Vy9tMnBFaEh1eU5uZGU5Yy81YlJsQ2JN?=
 =?utf-8?B?OFBmcm5aaTUrazdWUzQ0SXZNQUhPQUdhOEkrM1B4eWQ0YmY0clBRd09pb2ZH?=
 =?utf-8?B?NE9ZaVVHU1gwa3g1aStXcWpYWnh6ak85dXpKNGhWS0IvYWhQWWM4QTJCZmJq?=
 =?utf-8?Q?kc9lxg/r+sQ=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?MWIrRjlEK3VvcmZrTEhENVFkK0UzZ083a29aV25CdnZJMEkxeFJyN09TbGlS?=
 =?utf-8?B?aUNlVUF0RTJBVjJ2WDhibGpRNEh0VFhoYUV5VVNQQTlNOW9MMkpCQldjZWk0?=
 =?utf-8?B?WSt1c3YxeHk4ZmxMYkVXQWlLTGJqODJMWDIyb2FxNU1GZFJMTVdJNHBXTS9O?=
 =?utf-8?B?QVl6Z3dyVU9EaUpXNDYremJXTFBPS3B1VzNvVDFJNnAyU0ZlSFpabThxdWVn?=
 =?utf-8?B?NGVYVjdtNitXcFR4SHBOOTVwaGFVMVBpNEZLYWdtL014VndpV3RocjdQY2NS?=
 =?utf-8?B?aGdpNTlEVFBFWmlDQnVUTjVXcGY3MU9GQWcra3VpbTY2ZFpYSm50eEFOQ3I5?=
 =?utf-8?B?Z2tkTjhUbkw2aDdBemRpVUpYOCsrNFJ1K3ZKNVBKR1E3VXUzU0lhNFBBd0Z0?=
 =?utf-8?B?U1NZMUprWTAwVENLYmRBbkdUN1Z0eUJ2Ym1hV01jRlZqSTMrU1F0bkFzWDkr?=
 =?utf-8?B?S1QyYVVkRFhsRm5vMllScXAxa0loVWNXQlQwTDdHREJNVmovdG1DNGdjSHpk?=
 =?utf-8?B?TVZIekpzREN5ZTNJaHZOa0N4dkhHZEo0UG5EdnBtZ3MvNVE1YXB5am1Xa1Q1?=
 =?utf-8?B?OFBSSUh4QTFEckN1eldoMWFpVGViTWx0SUZTWHg0SkV6djhidFQ4aXlGZ2t6?=
 =?utf-8?B?cE4yazYyOVpnUXloeGdqUTE2bmNUVjl3c1JqK3dTV2U3MVo2Z3l2djYwd3pG?=
 =?utf-8?B?U240djAxM0dXMFVmbnFpZjFHNEtnZDNBUmNNY3ZWSHRqOUNNbW90Zitwa1g5?=
 =?utf-8?B?ODZtUlZJQ0ptRjA0U00vWVpVSk82RkdYc0VVUVJ1UVFyMVdsYllyVU53U1BY?=
 =?utf-8?B?dDBFZ3ovQlA3K3hNSTZmMFFEUzN4WmtSQ01oZ28wSzk2QnFzcDVNWmhZU0kr?=
 =?utf-8?B?SitEOHN0VWViSmdmL3hMdGR6eFN0SVdXNUVjc1NCblU0Szc4YXBiZzZMS09N?=
 =?utf-8?B?OSs4MGNwNjFlaGJnYmRoNm01b2xzUTFQa2NLV1FpN2hDRmxJWWtUSnRDK2tl?=
 =?utf-8?B?NWlhWGNkV1VMeUR2NTRPRWY0VzdBYXAvbHhnREJFWjlScEdjWndFS1pEWjZh?=
 =?utf-8?B?THVNTEhnYTlyTFZCbEMrRDdTS0dUQWpFd1lXeTR2dTRnYm9peFAyeGdXQ1Vt?=
 =?utf-8?B?b21NaFVaN1FUVGVycHR3amRLR0RqcjRTR0RtUjIzQlRrVkZ5MzBMdy9jenRO?=
 =?utf-8?B?c2RSb1FPYXU5alM4S0lRRlJyeGlrbDRKTjBWaisvRGxUU21OR0FhbThnaEwy?=
 =?utf-8?B?eE9JQ0tqOUJ1cmpyNWFQaWtwc1VXS3hMV1p4MUVqK3lYV1FsMGNVUElKaXVH?=
 =?utf-8?B?clZCOEx6NmxBeG9EQXorUGlrOFNaY2FWMXFCYWJSN3dwN3EyTXB4QmJmMFhU?=
 =?utf-8?B?dUM5cmVYZEhMRmczLzZNcU5wRnR4ZDU3R3Z2VE5NVVJXZ2N6ejBxWWRzeFl4?=
 =?utf-8?B?Mk1Cd0ZMMjBBU0c4VDBzL00xNWFJTjRpODlNTTdKam1UTzNZYlJPdlFXdDdH?=
 =?utf-8?B?VWV3QXFUYnlHdU1tTVo0OTU0c2p3eFdURDZvVlYySVIzcDFaUCs4T0Z0anJl?=
 =?utf-8?B?ZXJkYmt2U0lQbDhnTitLaStaN0tGeTYwMVNqK0M3TFlTVm1iRUNkT2xFeWdS?=
 =?utf-8?B?b3FyZjBmZWxEMkZReUs5aG94dUIxTGgrTlBkMHVkTzlFOHdUeVc5Q3lYVWYw?=
 =?utf-8?B?R2ZzUEJ4cmh3VmgxMUhLRC84NlFmNkJnQy8zLytXb2lXa1N2UmFKUVFLWnp4?=
 =?utf-8?B?a1NFalM2MktIeW1Tc3QzU1lBM080andQL1JNMXN2dmdYNGFyaS9nd1ZyOFV3?=
 =?utf-8?B?UnNEbUFYc1BXdTlSQzRnSG1sMW1PMTBKMTViVDlSNUpOWjZYeHlVYU9TdXVE?=
 =?utf-8?B?VTFCUXdHdm1KMmdkMzBSemtYUmNBeTVoWEV2ZFVTdnJUYVZDcjdQL25MK25y?=
 =?utf-8?B?eDRHc1VCNThmVk9FdEtiQjE3OUs3NTU4c1NwQUNrYThzSmEzdSt1aWxYV2dQ?=
 =?utf-8?B?ajB2eUlzOVZGamtHeVROcmpjRWZWM3hlK2ozbG9RV2pkZDFRSy9uTHJ0K0Rr?=
 =?utf-8?B?SmZxSHhUa2xYb0RMNk5zQUg4UTE4VUFnQWNTU2M5Zm5xblR3cWdtczVkdUh3?=
 =?utf-8?Q?csB7TJ2JHsAUyPnc7GwrbpKxu?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 513c4cd4-e2ab-483d-53f8-08dd990d776c
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 08:48:47.5689
 (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: bhxoRI07j8wv3SMemEOi13FaRJw4vroKMHXJ62fAVGK63CGwzbAdg4ptl6Izf/ec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9213



On 13/05/2025 10:45, Luca Fancellu wrote:
> Introduce a few utility functions to manipulate and handle the
> pr_t type.
> 
> Signed-off-by: Luca Fancellu 
> ---
> v5 changes:
>  - Don't rely on bitfield and use the mask MPU_REGION_RES0 for
>    pr_set_base and pr_set_limit to make it explicit. Fixed typos
>    in commit message.
> v4 changes:
>  - Modify comment on top of the helpers. Clarify pr_set_limit
>    takes exclusive address.
>    Protected common code with #ifdef Arm64 until Arm32 is ready
>    with pr_t
> ---
>  xen/arch/arm/include/asm/mpu.h | 65 ++++++++++++++++++++++++++++++++++
>  1 file changed, 65 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
> index fb93b8b19d24..b90ae8eab662 100644
> --- a/xen/arch/arm/include/asm/mpu.h
> +++ b/xen/arch/arm/include/asm/mpu.h
> @@ -23,6 +23,71 @@
>  #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
>  #define MAX_MPU_REGION_NR       NUM_MPU_REGIONS_MASK
>  
> +#ifndef __ASSEMBLY__
> +
> +#ifdef CONFIG_ARM_64
> +/*
> + * Set base address of MPU protection region.
> + *
> + * @pr: pointer to the protection region structure.
> + * @base: base address as base of the protection region.
> + */
> +static inline void pr_set_base(pr_t *pr, paddr_t base)
> +{
> +    pr->prbar.reg.base = ((base & ~MPU_REGION_RES0) >> MPU_REGION_SHIFT);
> +}
> +
> +/*
> + * Set limit address of MPU protection region.
> + *
> + * @pr: pointer to the protection region structure.
> + * @limit: exclusive address as limit of the protection region.
> + */
> +static inline void pr_set_limit(pr_t *pr, paddr_t limit)
> +{
> +    pr->prlar.reg.limit = (((limit - 1) & ~MPU_REGION_RES0)
Might be worth adding a comment that PRLAR expects inclusive limit hence (limit -1).

> +                           >> MPU_REGION_SHIFT);
> +}
> +
> +/*
> + * Access to get base address of MPU protection region.
> + * The base address shall be zero extended.
> + *
> + * @pr: pointer to the protection region structure.
> + * @return: Base address configured for the passed protection region.
> + */
> +static inline paddr_t pr_get_base(pr_t *pr)
Why not const?

> +{
> +    return (paddr_t)(pr->prbar.reg.base << MPU_REGION_SHIFT);
> +}
> +
> +/*
> + * Access to get limit address of MPU protection region.
> + * The limit address shall be concatenated with 0x3f.
> + *
> + * @pr: pointer to the protection region structure.
> + * @return: Inclusive limit address configured for the passed protection region.
> + */
> +static inline paddr_t pr_get_limit(pr_t *pr)
Why not const?

> +{
> +    return (paddr_t)((pr->prlar.reg.limit << MPU_REGION_SHIFT)
> +                     | ~MPU_REGION_MASK);
> +}
> +
> +/*
> + * Checks if the protection region is valid (enabled).
NIT: in other helpers you use imperative mood, so this should be "Check if"
> + *
> + * @pr: pointer to the protection region structure.
> + * @return: True if the region is valid (enabled), false otherwise.
> + */
> +static inline bool region_is_valid(pr_t *pr)
Why not const?

> +{
> +    return pr->prlar.reg.en;
> +}
> +#endif
Please add /* CONFIG_ARM_64 */

> +
> +#endif /* __ASSEMBLY__ */
> +
>  #endif /* __ARM_MPU_H__ */
>  
>  /*


~Michal



From xen-devel-bounces@lists.xenproject.org Thu May 22 08:49:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:49:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993240.1376670 (Exim 4.92)
	(envelope-from )
	id 1uI1cA-0004wk-Ce; Thu, 22 May 2025 08:49:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993240.1376670; Thu, 22 May 2025 08:49: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 1uI1cA-0004wd-9j; Thu, 22 May 2025 08:49:22 +0000
Received: by outflank-mailman (input) for mailman id 993240;
 Thu, 22 May 2025 08:49:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI1c8-0004lt-M4
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:49:20 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2412::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a47a1d4c-36e9-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 10:49:17 +0200 (CEST)
Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by
 CH3PR12MB7524.namprd12.prod.outlook.com (2603:10b6:610:146::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 08:49:13 +0000
Received: from DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com
 ([fe80::b04e:2da5:7189:4c4d%4]) with mapi id 15.20.8746.035; Thu, 22 May 2025
 08:49: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" 
X-Inumbo-ID: a47a1d4c-36e9-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FsxrmtjuH3mxa9MGX+Hn7xs8/Tw/ECTFWlWhbLlQ6JutGhy5Dhn2/GtPNQA1jMtvdcs6xmmjI1eYiQ1+SLktqy8LXrOfiSQhsD3c7k0MaLVqxTqLvSXYCZKeS6T8t8GyN/psPeGjkkJ65MoKZkKfT9ULstLFYQxb1Ux/5UaONido8GjHMIm9BnHQY0do0CwMp5bGCP/x9zICJBSE/b9YN+XeK7MaMHXuWTowyfok8Zo1rDiyDolUM2KK4KkyWvkgggW09LufWXMEfbiBvYVoQB92BGsrxaaQE+2Tq+Ytjyyh8xRbIu6fm/2bNrstYBHajczyO6VTFzNHJl9aBxU59Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7HI/ryzjDD7PX5Vkw0rW/VFR1PrGZzFjV+Jd/+ZuXx8=;
 b=TIXfq0rczIttPeA6w3n2VUpY2gn88r9lEeXyU3t+t6osvwF2UbDzQKiv5axtqB0B++ZqPhOo1OeqXjkj+wWhupGXhbzWAaL2Mv38PIlYyCdfXv35lblL5tCQ5LnXjznVr6o3rX3tITybDxjFBr0Yns1n+kUjKYb8DwMM+cBtF/Gi0ci5aj1xok1R4xVVZmg3HhEy6+odAnjhX1rblEZSkuUHK+Qkwcy106VLe/hZQpjLPdmFcDEvA+1+ZdDQjiiowiGsXFSi1yDpVpnYaWHrK5+DbRmwOYhzAI6DbRZidVr2xoFAIkmYfXP/++mp3hC4q7uTahC0qJ7Mbz6VwoQTjA==
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=7HI/ryzjDD7PX5Vkw0rW/VFR1PrGZzFjV+Jd/+ZuXx8=;
 b=Fz6AtQ9uDEuK5U3nM9+G5Wx6HzFZwkFI7EL9p4o/OkeM5yw54uGgW0CFlUmRFTKe9H3EEzRzH5OP/Ip0c9P9SjMyrmuxpIowpjZJg3FtHwpk/MCCh8BiNXCJMS1OXholBc2Wcf5CdYHaSw639fjHB6wEm9hDobpEmYJgZ+NDl18=
From: "Penny, Zheng" 
To: Jan Beulich 
CC: "Huang, Ray" , Andrew Cooper
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: RE: [PATCH v4 15/15] xen/xenpm: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
Thread-Topic: [PATCH v4 15/15] xen/xenpm: Adapt SET/GET_CPUFREQ_CPPC
 xen_sysctl_pm_op for amd-cppc driver
Thread-Index: AQHbrRCy0dvLnopz7kONlcDKiL+9s7O8Z2mAgCH2THCAABP3gIAAGTEg
Date: Thu, 22 May 2025 08:49:13 +0000
Message-ID:
 
References: <20250414074056.3696888-1-Penny.Zheng@amd.com>
 <20250414074056.3696888-16-Penny.Zheng@amd.com>
 <239e1256-a47d-44e1-a335-2199b880f5d7@suse.com>
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_ActionId=cff5bb06-abdb-46e8-b700-262d58e907f8;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_ContentBits=0;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_Enabled=true;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_Method=Privileged;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_Name=Published
 AMD
 Product;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_SetDate=2025-05-22T08:49:05Z;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_0fec2151-cbe0-4586-8a3f-997880a38a28_Tag=10,
 0, 1, 1;
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|CH3PR12MB7524:EE_
x-ms-office365-filtering-correlation-id: c466fcec-f13b-4dcd-4509-08dd990d86fc
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?bHpaKzZ3SVU0U2ZCcURpODMxbmE4NHlGK0lyeHhiWTl0TG5adm1VMktFRDl0?=
 =?utf-8?B?WnJITDduQW5WUmlBUmRETmZ5bk1ySzg2K0E5SHJpQUZRZzBaNyt4S29iVERM?=
 =?utf-8?B?QWNOZ0E4bzNnWlh6aDYwOUsyZzRBU2Q1UTlBVzA1SWdrSitocUZRYmJRdFpx?=
 =?utf-8?B?b0REMUhLaUdsdHpzTWpuVzNCVlFrWHpxUjRvaGFIMUp1NlJ5bUJKbVQyNkYv?=
 =?utf-8?B?d0VrRU9BcGgrOGpnRjVmMXp2TEpIN3JYZmV0bVN3TklKNy8zU0xBdStHU2Fy?=
 =?utf-8?B?SzIzbDZRR2JTNHBFempIUGY0akhWTklEVE1VOGxRUWZFYnV1YmxnaitLNEVQ?=
 =?utf-8?B?Wi9iN3VTZzM4UGErNGFXT1hrRjJ2K1FJbCs3K2lXcjcyT25PKzZNcWFtSVN2?=
 =?utf-8?B?STBzTE4rVW55V0ltdmk1UkxCamZUc3IybWpWcFMrZEgzYTA0dXc4bGh1a3Nw?=
 =?utf-8?B?UGthcVpzOEhYc0UvNGMzN1l0bnFBa0xSUktJK2JFWmt5WG1MNUs2RzFBbE9s?=
 =?utf-8?B?NnBaM3JhT2FXUUlibzBkVWdyK0dic0NJNkJySWNnREFyUVQ2SnNMeFh4WGts?=
 =?utf-8?B?bTV3WmZmUGJyb3BQL2lQRThOY3pXLzBKNWNGR0NJZ3RadHBXaUtPSVFIYUds?=
 =?utf-8?B?empCOEZzZUJkMWljTlF5ZWRaVitTUlkwM0Z2RHRCYVJYQ1NKVzE3Z2lzd3VS?=
 =?utf-8?B?SmYrc2JZR3FxaWQ5cFNjTnZrWC9RdTJoNG5CYWVtNlZlN2NBMlRXUW5GNEdY?=
 =?utf-8?B?UzlaeDg2T2F2TlNoMklhQVEyRGYva3hha1dJUG54RjMxZTc4VjByL1l0RFp1?=
 =?utf-8?B?cVluTWcrWk0yaTJScyt2QTdwWTkzL2ppSDdndzR5Qjl4K3p2MmhtcEdvdkdV?=
 =?utf-8?B?Z29CRHczMXloUmIvR1gvb3UrbVRkRVhFT3E1WUpGWW1ObmRXdFdvTXBkZHZv?=
 =?utf-8?B?RVJUNUExMTk4VXR5UjlOVlRqUThhVGFyWW9Zd2pBZ1ViZXM1K000N2dEMnUv?=
 =?utf-8?B?TERMVUdQS3czYW15WmVRUUh1L2p5M2RTUFMxTDBnZEZqN0txVEZSd09nM3d3?=
 =?utf-8?B?NURma0IwWk1qR3BXM3ZhWEZyMlQ2SVRkRFVnWkRyVThJY3Y1czJPSVBoaEpr?=
 =?utf-8?B?L2pIVzZPMkxxZ2FOOURXSGQxbURqSTJCQzgyYXlycE9DNE4zVWd5TXZHbENH?=
 =?utf-8?B?YzF4QmhZRE9rbW10M1Jlc0ZjclhINjdGYkFlTmVSOVZzKzNPM1ArUTR3bkJm?=
 =?utf-8?B?dmZDS3FkZ29zZElxZ20vZUN5Sm52T3dPenN4ZEJmdDZJOC9nc25rWnRSalBS?=
 =?utf-8?B?U09ERGlIVHdldDF6eThlNkMrM1JhekNsKzRyQnY1SVBDSkZSaWFDN2o1QmtE?=
 =?utf-8?B?cC9aaEFCZzJ4cHhtcUJrN05iMGFxQmxWcElreFJlRUVNRnBoVUNaM2Rwcm9U?=
 =?utf-8?B?NldYYkFvM25YWWxidTNPKzl5NzdodmxVQ0orQURFc2NMbHR1bjZZbXlmSk40?=
 =?utf-8?B?M3AwUGY5V2dMbHZyRHZGRWdHZmNBWSs0djVvcitJRGs1RTNTSHd2bVdSV3Ur?=
 =?utf-8?B?dmMzQ2NlK1RRMytiQkdrdUtBUzdBYVBVZWREaHppamhycCt1V0ZDRjRpMHpX?=
 =?utf-8?B?Wkk3OTkxRFFickVaYUlZRWx0Y1NZZGxsYWpoYVBoQlR6Ty90QTRmaWlFTWtG?=
 =?utf-8?B?MzE1Yi9nTHJJN09mYkNNbVUwQVFxOVNwdHByOEE1WHBwMVdieitBRDhtV1Rs?=
 =?utf-8?B?Wm5ZZ1RyaUFmK280MTFDMVk0SFQwcWZyNFJQclRielR0ekxMdFo2Vm9JY2VG?=
 =?utf-8?B?Y0dmb0hPSGJVVEtWUmFGMmZpbGxMSW5JeUN2bEhHQ2NkeThqWjZDZVpBSmdj?=
 =?utf-8?B?TmV3TUZqeTA4N2FJdWRGWkxPcE54eGFLeE5yT0txeDVNbHdONU1hZVBFMk11?=
 =?utf-8?Q?wYw5yHzlnAA=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?RzJnWWJiQU1FYkpHTzZlRVZaaEc5S1BtVHRLSVdhaEV4SStnK0NLQTNTUFRV?=
 =?utf-8?B?U0JLeUhTK091K2JFU21qWG9aVWc1N2tBMXJRZzNVUUVVRzYwNGtQTlpqbEpE?=
 =?utf-8?B?Y1FDZk5qckFiOG9vOEwvbmFCLzcvMVNyekwzUnFwT3B2SEtIZUhLWVllN3BM?=
 =?utf-8?B?WExWMk4rTEFsWW9Sb3p2ekNCL0o4WERpcXVKWWVNWGVHNHQzVTJnZCtjbWZD?=
 =?utf-8?B?a2dYcTlwSWxOcGw5SHFkbkhBMHhUSFR3bjZqTlFhSktZb01BekVUdmFWdXFL?=
 =?utf-8?B?alIycnVpK3hrRzV2bFh1Wnk5TFlwRm1XZ1pZVERSZVRHQTZFTnBIK3FVUXJL?=
 =?utf-8?B?SkhOeTJ0L0FaMTJ0Q1JGMWM5czcwK2RtY3l5eGN1ODlyZFZwaHBnNHMrZTU5?=
 =?utf-8?B?OUpJQjRlQWc1UzIzSGdoQytoZ09IeFFJWnRiQzhSVjBFdSs5dXByM1dOZGo3?=
 =?utf-8?B?U2xGb3gzQzN1aVpCM3hWOE5ra0RBaVVUMEQzNXhZMW9nZUZFRnJCU0xaNXMr?=
 =?utf-8?B?ODVkR2FSWTNOekxrV3RuajhmT1o3bnJQTDZweDd2a2w4bGFGcmQ5TnU3d3A5?=
 =?utf-8?B?RkN4RDFpT3NRcmZPbmxaSEdkbUgwaWtqWUJvRWxCQk1wQThibHdXczF0WHo2?=
 =?utf-8?B?UmFxZzU4RnNscW85VVZBanJOaHA2dG5saWxvaFRFMGFWR2QvMFBPaW9Dakh1?=
 =?utf-8?B?VHBiQjEvTy92UUVIU3JuNFhMbjJQaVFoblU2Z2U1WDdwT0N3ZmRLZGorYzlQ?=
 =?utf-8?B?dDAzc25GdEhTWVoxb0FuTCsrZDByZ3VERG94Ylc1U3JiZTJOMkVlRGpSdERl?=
 =?utf-8?B?eUdoOFNEeEhaL2lzK2doUCt1ZzRxWGNkYnlreVVFbm45amRCQTJ6L29qak5Z?=
 =?utf-8?B?dDhNa3J1R0dGQ2t1akdkSVFYUGQrRW45OFFURkZqQjRQOEZMOXJVa2JzTlFr?=
 =?utf-8?B?Yjg3SjltYlJPNGFVVlF3VGdiS1VVeCszbUlwckFLbjREbWNNdGkraFQwL2Yv?=
 =?utf-8?B?K05aQ21xT3A5KzJUbDFkMUZLb1lIa2Vpb245dzF3S2h0TW5zckhvVjFPZDZV?=
 =?utf-8?B?bHFPeWVpU0xQZDFGTlJ2Y0lBTnNnWkdMdHd4UklrdTg1eXQvZXRpV05QWlFy?=
 =?utf-8?B?clJIQ3diNmI4NUNiVElZRk1FU3ZJMytKOEZ1MGdOWmJEV2pub04yOTRuellZ?=
 =?utf-8?B?bnhtem13VUN1b1JibVZabWIwSUZ3bWRyVGFEdmdIRlVXeEVmSm5QOExQNUYr?=
 =?utf-8?B?aDhyc3RCM2R0c2pjSVMzVEJEZSs2SjNvQktrTThxT2NYNWd0Nm9Nd2FJZ2x6?=
 =?utf-8?B?VVo3a3RiK2puQ2FQaWJMdFBaZkxJWFpLTmtTYWMrSDQ0Q3lvRjJmZFc1cVow?=
 =?utf-8?B?Z1IreG42NjROdUFQN0Q1OVhhUXhvR3VPV1NKSDBvRVJuYkFEVDRmNHdnTlVS?=
 =?utf-8?B?UThWQkZLYWJoUVlteUhZQ2xPaGp1QklCQVVJbk4rTmZnVVR5K0huRkJNY3Nt?=
 =?utf-8?B?bU9OWGVPYi9lZEgrQXEvYjAzdDVjNzQzRjJJcE9zbnVQVnpoV1B1VUZGMkZE?=
 =?utf-8?B?eTMrL2NHV3ZrNEtIeXVIRmh6NlA0eFRvYmozUEV6YkNSWUpOU1BRb2VSQXNj?=
 =?utf-8?B?Y1c2OG5vYkpNcmZKTVNycUozclBRdXhHWXNBeHo0SzdTMnI2ZEtSUGJUaWtt?=
 =?utf-8?B?WVozdHgwZ3JzeDZ6dWlTMmpiRk50YmhLRytpbkh3TWFyQ3I0UmtXbUhTYlAx?=
 =?utf-8?B?ODltWEhHUmtUcWtmZXhoTkordkFrcUxHTTJteDB0R051R09sUWtvNTlxMFBo?=
 =?utf-8?B?Y2xsM3VwcUYxcTk0YTRJTHZsUWJjNTVSc2Fsd3VxbVRoSUFDbkhuYkpheVN4?=
 =?utf-8?B?ZEVBeGg4Y0RZVU1CaFVIc1lNL3JQRzcxVUlNUXFIOFpDbjZiV1M5NDRWbzV3?=
 =?utf-8?B?TXR1MnVQK3A3bTRFN2FTU0lhZnM4TTM0anhYSUJqbG92ZEVBcGdEYTN1N2xw?=
 =?utf-8?B?ZXFBL1NNY1piNG1NYWszOHVHd3p0eXRQVTFTVkpjK0d4cjlpbFhlRUIxMFNR?=
 =?utf-8?B?MytvM1R6WWlPTUVaZDhWYUh2SkRPblNXYStwekFRM1luTmpkWm5hRUEyemJz?=
 =?utf-8?Q?Ua1A=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c466fcec-f13b-4dcd-4509-08dd990d86fc
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2025 08:49:13.4148
 (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: imHBPg5RsXK/zp+vjxZvRkiQ21dXFeuqGQoMH425riHNOdOP3jIOj+pTHeGYNVPbbmoe6as01C6OsmFfym2eoA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7524

W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1
bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMjIsIDIwMjUg
Mjo1MSBQTQ0KPiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiBDYzog
SHVhbmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbmRyZXcgQ29vcGVyDQo+IDxhbmRyZXcu
Y29vcGVyM0BjaXRyaXguY29tPjsgUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j
b20+OyB4ZW4tDQo+IGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+IFN1YmplY3Q6IFJlOiBb
UEFUQ0ggdjQgMTUvMTVdIHhlbi94ZW5wbTogQWRhcHQgU0VUL0dFVF9DUFVGUkVRX0NQUEMNCj4g
eGVuX3N5c2N0bF9wbV9vcCBmb3IgYW1kLWNwcGMgZHJpdmVyDQo+DQo+IE9uIDIyLjA1LjIwMjUg
MDc6NTksIFBlbm55LCBaaGVuZyB3cm90ZToNCj4gPiBbUHVibGljXQ0KPiA+DQo+ID4+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEphbiBCZXVsaWNoIDxqYmV1bGljaEBz
dXNlLmNvbT4NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAzMCwgMjAyNSAxMTowMiBQTQ0K
PiA+PiBUbzogUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KPiA+PiBDYzogSHVh
bmcsIFJheSA8UmF5Lkh1YW5nQGFtZC5jb20+OyBBbmRyZXcgQ29vcGVyDQo+ID4+IDxhbmRyZXcu
Y29vcGVyM0BjaXRyaXguY29tPjsgUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j
b20+Ow0KPiA+PiB4ZW4tIGRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnDQo+ID4+IFN1YmplY3Q6
IFJlOiBbUEFUQ0ggdjQgMTUvMTVdIHhlbi94ZW5wbTogQWRhcHQNCj4gU0VUL0dFVF9DUFVGUkVR
X0NQUEMNCj4gPj4geGVuX3N5c2N0bF9wbV9vcCBmb3IgYW1kLWNwcGMgZHJpdmVyDQo+ID4+DQo+
ID4+IE9uIDE0LjA0LjIwMjUgMDk6NDAsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiA+Pj4gKyAgICAv
KiBPbmx5IGFsbG93IHZhbHVlcyBpZiBwYXJhbXMgYml0IGlzIHNldC4gKi8NCj4gPj4+ICsgICAg
aWYgKCAoIShzZXRfY3BwYy0+c2V0X3BhcmFtcyAmIFhFTl9TWVNDVExfQ1BQQ19TRVRfREVTSVJF
RCkNCj4gJiYNCj4gPj4+ICsgICAgICAgICAgc2V0X2NwcGMtPmRlc2lyZWQpIHx8DQo+ID4+PiAr
ICAgICAgICAgKCEoc2V0X2NwcGMtPnNldF9wYXJhbXMgJiBYRU5fU1lTQ1RMX0NQUENfU0VUX01J
TklNVU0pDQo+ICYmDQo+ID4+PiArICAgICAgICAgIHNldF9jcHBjLT5taW5pbXVtKSB8fA0KPiA+
Pj4gKyAgICAgICAgICghKHNldF9jcHBjLT5zZXRfcGFyYW1zICYgWEVOX1NZU0NUTF9DUFBDX1NF
VF9NQVhJTVVNKQ0KPiAmJg0KPiA+Pj4gKyAgICAgICAgICBzZXRfY3BwYy0+bWF4aW11bSkgfHwN
Cj4gPj4+ICsgICAgICAgICAoIShzZXRfY3BwYy0+c2V0X3BhcmFtcyAmDQo+ID4+IFhFTl9TWVND
VExfQ1BQQ19TRVRfRU5FUkdZX1BFUkYpICYmDQo+ID4+PiArICAgICAgICAgIHNldF9jcHBjLT5l
bmVyZ3lfcGVyZikgKQ0KPiA+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+ID4+PiArDQo+
ID4+PiArICAgIC8qIEFjdGl2aXR5IHdpbmRvdyBub3Qgc3VwcG9ydGVkIGluIE1TUiAqLw0KPiA+
Pj4gKyAgICBpZiAoIHNldF9jcHBjLT5zZXRfcGFyYW1zICYNCj4gWEVOX1NZU0NUTF9DUFBDX1NF
VF9BQ1RfV0lORE9XICkNCj4gPj4+ICsgICAgICAgIHJldHVybiAtRU9QTk9UU1VQUDsNCj4gPj4+
ICsNCj4gPj4+ICsgICAgLyogUmV0dXJuIGlmIHRoZXJlIGlzIG5vdGhpbmcgdG8gZG8uICovDQo+
ID4+PiArICAgIGlmICggc2V0X2NwcGMtPnNldF9wYXJhbXMgPT0gMCApDQo+ID4+PiArICAgICAg
ICByZXR1cm4gMDsNCj4gPj4+ICsNCj4gPj4+ICsgICAgZXBwID0gcGVyX2NwdShlcHBfaW5pdCwg
Y3B1KTsNCj4gPj4+ICsgICAgLyoNCj4gPj4+ICsgICAgICogQXBwbHkgcHJlc2V0czoNCj4gPj4+
ICsgICAgICogWEVOX1NZU0NUTF9DUFBDX1NFVF9ERVNJUkVEIHJlZmxlY3RzIHdoZXRoZXIgZGVz
aXJlZCBwZXJmIGlzDQo+ID4+PiArIHNldCwNCj4gPj4gd2hpY2gNCj4gPj4+ICsgICAgICogaXMg
YWxzbyB0aGUgZmxhZyB0byBkaXN0aWd1aXNoIGJldHdlZW4gcGFzc2l2ZSBtb2RlIGFuZCBhY3Rp
dmUgbW9kZS4NCj4gPj4+ICsgICAgICogV2hlbiBpdCBpcyBzZXQsIENQUEMgaW4gcGFzc2l2ZSBt
b2RlLCBvbmx5DQo+ID4+PiArICAgICAqIFhFTl9TWVNDVExfQ1BQQ19TRVRfUFJFU0VUX05PTkUg
Y291bGQgYmUgY2hvc2VuLCB3aGVyZQ0KPiA+PiBtaW5fcGVyZiA9DQo+ID4+PiArICAgICAqIGxv
d2VzdF9ub25saW5lYXJfcGVyZiB0byBlbnN1cmVzIHBlcmZvcm1hbmNlIGluIFAtc3RhdGUgcmFu
Z2UuDQo+ID4+PiArICAgICAqIHdoZW4gaXQgaXMgbm90IHNldCwgQ1BQQyBpbiBhY3RpdmUgbW9k
ZSwgdGhyZWUgZGlmZmVyZW50IHByb2ZpbGUNCj4gPj4+ICsgICAgICoNCj4gPj4NCj4gWEVOX1NZ
U0NUTF9DUFBDX1NFVF9QUkVTRVRfUE9XRVJTQVZFL1BFUkZPUk1BTkNFL0JBTEFOQw0KPiA+PiBF
IGFyZSBwcm92aWRlZCwNCj4gPj4+ICsgICAgICogd2hlcmUgbWluX3BlcmYgPSBsb3dlc3RfcGVy
ZiBoYXZpbmcgVC1zdGF0ZSByYW5nZSBvZiBwZXJmb3JtYW5jZS4NCj4gPj4+ICsgICAgICovDQo+
ID4+DQo+ID4+IEkgZmVhciBJJ20gc3RydWdnbGluZyB0byBwYXJzZSBzb21lIG9mIHRoaXMsIG1h
a2luZyBpdCBkaWZmaWN1bHQgdG8NCj4gPj4gc3VnZ2VzdCBwb3NzaWJsZSBhZGp1c3RtZW50cyAo
YXMgSSBjYW4ndCBkZXJpdmUgd2hhdCBpcyBtZWFudCB0byBiZQ0KPiA+PiBzYWlkKS4gUGx1cyB3
aGVyZSdzIHRoZSB0ZXJtIFQtIHN0YXRlIGNvbWluZyBmcm9tIGFsbCBvZiB0aGUgc3VkZGVuPw0K
PiA+Pg0KPiA+DQo+ID4gUGFzdGluZyBkZXNjcmlwdGlvbiBvbiAibG93ZXN0X3BlcmYiIGFuZCAi
bm9ubGluZWFyX2xvd2VzdF9wZXJmIjoNCj4gPiAiDQo+ID4gTG93ZXN0IE5vbmxpbmVhciBQZXJm
b3JtYW5jZSBpcyB0aGUgbG93ZXN0IHBlcmZvcm1hbmNlIGxldmVsIGF0IHdoaWNoIG5vbmxpbmVh
cg0KPiBwb3dlciBzYXZpbmdzIGFyZSBhY2hpZXZlZCwgZm9yIGV4YW1wbGUsIGR1ZSB0byB0aGUg
Y29tYmluZWQgZWZmZWN0cyBvZiB2b2x0YWdlDQo+IGFuZCBmcmVxdWVuY3kgc2NhbGluZy4gQWJv
dmUgdGhpcyB0aHJlc2hvbGQsIGxvd2VyIHBlcmZvcm1hbmNlIGxldmVscyBzaG91bGQgYmUNCj4g
Z2VuZXJhbGx5IG1vcmUgZW5lcmd5IGVmZmljaWVudCB0aGFuIGhpZ2hlciBwZXJmb3JtYW5jZSBs
ZXZlbHMuIEluIHRyYWRpdGlvbmFsIHRlcm1zLA0KPiB0aGlzIHJlcHJlc2VudHMgdGhlIFAtc3Rh
dGUgcmFuZ2Ugb2YgcGVyZm9ybWFuY2UgbGV2ZWxzLg0KPiA+DQo+ID4gTG93ZXN0IFBlcmZvcm1h
bmNlIGlzIHRoZSBhYnNvbHV0ZSBsb3dlc3QgcGVyZm9ybWFuY2UgbGV2ZWwgb2YgdGhlIHBsYXRm
b3JtLg0KPiBTZWxlY3RpbmcgYSBwZXJmb3JtYW5jZSBsZXZlbCBsb3dlciB0aGFuIHRoZSBsb3dl
c3Qgbm9ubGluZWFyIHBlcmZvcm1hbmNlIGxldmVsDQo+IG1heSBhY3R1YWxseSBjYXVzZSBhbiBl
ZmZpY2llbmN5IHBlbmFsdHksIGJ1dCBzaG91bGQgcmVkdWNlIHRoZSBpbnN0YW50YW5lb3VzDQo+
IHBvd2VyIGNvbnN1bXB0aW9uIG9mIHRoZSBwcm9jZXNzb3IuIEluIHRyYWRpdGlvbmFsIHRlcm1z
LCB0aGlzIHJlcHJlc2VudHMgdGhlIFQtc3RhdGUNCj4gcmFuZ2Ugb2YgcGVyZm9ybWFuY2UgbGV2
ZWxzLg0KPiA+ICINCj4NCj4gQW5kIGFnYWluICJULXN0YXRlIi4gVGhlIG9ubHkgVC1pc2ggdGhp
bmcgSSdtIGF3YXJlIG9mIGlzIHNvbWV0aGluZyB0aGF0IHdhcyBuZXZlcg0KPiBpbXBsZW1lbnRl
ZCBpbiBYZW4ncyBwb3dlciBtYW5hZ2VtZW50LiBIZW5jZSBJIGZlYXIgSSBjb250aW51ZSB0byBi
ZSBjb25mdXNlZC4NCj4gKEFuZCBidHcsIEkgc2VhcmNoZWQgUE0gdm9sIDIgZm9yIHRoZSB0ZXJt
LCBhbmQgaXQgZG9lc24ndCBvY2N1ciB0aGVyZSBhdCBhbGwuKSBBcyBhDQo+IHJlc3VsdCAuLi4N
Cj4NCg0KU29ycnksIEkgZGlkbid0IGFkZCB0aGUgcmVmZXJlbmNlOg0KaHR0cHM6Ly91ZWZpLm9y
Zy9zcGVjcy9BQ1BJLzYuNS8wOF9Qcm9jZXNzb3JfQ29uZmlndXJhdGlvbl9hbmRfQ29udHJvbC5o
dG1sP2hpZ2hsaWdodD1jcHBjI2xvd2VzdC1ub25saW5lYXItcGVyZm9ybWFuY2UNCg0KPiA+IElN
TywgaW4gcGFzc2l2ZSBtb2RlLCB3ZSByZWx5IG9uIFhlbiBnb3Zlcm5vciB0byBkbyBwZXJmb3Jt
YW5jZQ0KPiA+IHR1bmluZy4gQW5kIFhlbiBnb3Zlcm5vciBpcyB0aGlua2luZyBiYXNlZCBvbiBQ
LXN0YXRlcy4gU28gSSB0YWtlIG5vbi1saW5lYXINCj4gbG93ZXN0IHBlcmYgYXMgbWluX3BlcmYg
V2hpbGUgaW4gYWN0aXZlIG1vZGUsIGhhcmR3YXJlIGl0c2VsZiBpcyBjYWxjdWxhdGluZyBzdWl0
YWJsZQ0KPiBwZXJmb3JtYW5jZS9mcmVxdWVuY3kgYXV0b21hdGljYWxseSBiYXNlZCBvbiB3b3Jr
bG9hZCwgdGhlcm1hbCwgdm9sdGFnZSwgYW5kIGV0Yy4NCj4gU28gbWF5YmUgc2V0dGluZyBtaW5f
cGVyZiB3aXRoIGxvd2VzdCBwZXJmIGlzIGEgYmV0dGVyIGNob2ljZT8NCj4NCj4gLi4uYW5zd2Vy
aW5nIHRoaXMgcXVlc3Rpb24gaXNuJ3QgcG9zc2libGUgZm9yIG1lICh5ZXQpLg0KPg0KPiA+Pj4g
KyAgICAgICAgcmV0ID0gZ2V0X2FtZF9jcHBjX3BhcmEocG9saWN5LT5jcHUsDQo+ID4+PiArICZv
cC0+dS5nZXRfcGFyYS51LmNwcGNfcGFyYSk7DQo+ID4+PiArDQo+ID4+PiArICAgIGlmICggc3Ry
bmNtcChvcC0+dS5nZXRfcGFyYS5zY2FsaW5nX2RyaXZlciwgWEVOX0hXUF9EUklWRVJfTkFNRSwN
Cj4gPj4+ICsgICAgICAgICAgICAgICAgIENQVUZSRVFfTkFNRV9MRU4pICYmDQo+ID4+PiArICAg
ICAgICAgc3RybmNtcChvcC0+dS5nZXRfcGFyYS5zY2FsaW5nX2RyaXZlciwNCj4gPj4gWEVOX0FN
RF9DUFBDX0VQUF9EUklWRVJfTkFNRSwNCj4gPj4+ICsgICAgICAgICAgICAgICAgIENQVUZSRVFf
TkFNRV9MRU4pICkNCj4gPj4+ICAgICAgew0KPiA+Pj4gICAgICAgICAgaWYgKCAhKHNjYWxpbmdf
YXZhaWxhYmxlX2dvdmVybm9ycyA9DQo+ID4+PiAgICAgICAgICAgICAgICAgeHphbGxvY19hcnJh
eShjaGFyLCBnb3ZfbnVtICogQ1BVRlJFUV9OQU1FX0xFTikpICkNCj4gPj4NCj4gPj4gSXNuJ3Qg
aXQgdGhlIG5vbi1FUFAgZHJpdmVyIHdoaWNoIGlzIGdvdmVybm9yLWluZGVwZW5kZW50Pw0KPiA+
Pg0KPiA+DQo+ID4gRVBQIGRyaXZlciBpcyBnb3Zlcm5vci1pbmRlcGVuZGVudCwgaW5kaWNhdGlu
ZyBhY3RpdmUgbW9kZS4NCj4NCj4gSSdtIGNvbmZ1c2VkIGhlcmUgYXMgd2VsbCB0aGVuOiBFYXJs
eSBpbiB0aGUgc2VyaWVzLCBiZWZvcmUgdGhlIEVQUCBkcml2ZXIgaXMNCj4gaW50cm9kdWNlZCAo
aS5lLiBhcyBwcmVwYXJhdGlvbiBmb3IgdGhlIG5vbi1FUFAgb25lKSB5b3Ugc3VwcHJlc3MgdXNl
IGFuZA0KPiByZXBvcnRpbmcgb2YgdGhlIGdvdmVybm9yLiBXaGVyZWFzIGZvciB0aGUgRVBQIGRy
aXZlciB3aGlsZSB5b3UgKGFsc28pIGRvbid0IHVzZSB0aGUNCg0KQXJlIHlvdSBtZW50aW9uaW5n
IHRoZSBjb21taXQgb2YgIiB4ZW4vY3B1ZnJlcTogb25seSBzZXQgZ292IE5VTEwgd2hlbiBjcHVm
cmVxX2RyaXZlci5zZXRwb2xpY3kgaXMgTlVMTCAiID8NClRoZSBjb21taXQgcHJldmlvdXNseSBp
cyBhZGRlZCBiZWZvcmUgdGhlIGludHJvZHVjdGlvbiBvZiBhbWQtY3BwYyBpbiBhY3RpdmUgbW9k
ZSAoRVBQLW1vZGUpLCBhbmQgaW4gdGhlIGNvbW1pdCBtZXNzYWdlLA0KSXQgc2F5cyAiIGFtZC1j
cHBjIG9uIGFjdGl2ZSBtb2RlIGJ5cGFzc2VzIHRoZSBzY2FsaW5nIGdvdmVybm9yIGxheWVyIC4u
Li4iDQpJTU8sIGNwdWZyZXEgZHJpdmVyIGluIFhlbiBpbmhlcml0ZWQgZnJvbSBMaW51eCwgYW5k
IGluIExpbnV4LCBmb3IgaG9va3MgaW4gY3B1ZnJlcSBkcml2ZXIsIHdlIGRlZmluZWQgLT5zZXRw
b2xpY3koKSBhbmQgLT50YXJnZXQoKSwgdGhlc2UNCnR3byBhcmUgZXhjbHVzaXZlIHRvIGVhY2gg
b3RoZXIuIFdlIGhhdmUgIiAhZHJpdmVyX2RhdGEtPnRhcmdldCA9PSAhZHJpdmVyX2RhdGEtPnNl
dHBvbGljeSAiIGNoZWNraW5nIGluIGNwdWZyZXFfcmVnaXN0ZXJfZHJpdmVyKCkuDQotPnRhcmdl
KCkgaG9vayBpcyBmb3IgY3B1ZnJlcSBkcml2ZXIgbmVlZGluZyBYZW4gZ292ZXJub3IsIGFuZCAt
PnNldHBvbGljeSgpIGlzIGZvciBnb3Zlcm5vci1sZXNzIGNwdWZyZXEgZHJpdmVyLg0KQWx0aG91
Z2ggd2UgYWxyZWFkeSBkZWZpbmVkIHRoZXNlIGhvb2tzLCBFUFAtbW9kZSBpcyB0aGUgZmlyc3Qg
ZHJpdmVyIHdoaWNoIGFjdHVhbGx5IGltcGxlbWVudHMgLT5zZXRwb2xpY3kgaG9vaw0KDQo+IGdv
dmVybm9yIGFzIHN1Y2gsIHlvdSB1c2UgdGhlIGNob2ljZSBvZiBnb3Zlcm5vciB0byBkZXRlcm1p
bmUgdGhlIEVQUCBzZXR0aW5nLiBJbg0KPiB0aGF0IHNlbnNlIHRvIG1lIHRoZSBFUFAgZHJpdmVy
IGlzIGxlc3MgZ292ZXJub3ItIGluZGVwZW5kZW50IHRoYW4gdGhlIG5vbi1FUFANCj4gb25lLiBU
aGF0J3Mgd2hhdCBJIHRyaWVkIHRvIGV4cHJlc3MgaW4gbXkgZWFybGllciByZXBseS4NCj4NCg0K
U29ycnkgZm9yIGJyaW5naW5nIGNvbmZ1c2lvbiBoZXJlLg0KTGlrZSBJIGFkZHJlc3NlZCBpbiBw
cmV2aW91cyBlbWFpbCwgdGhlIHJlYXNvbiB3aHkgSSB0cmllZCB0byBidWlsZCBjb25uZWN0aW9u
IGJldHdlZW4gZ292ZXJub3IgYW5kIEVQUC1tb2RlIGlzICBmb3IgdGhvc2UgdXNlcnMsDQp3aG8g
Y2hvb3NlcyBFUFAtbW9kZSwgYW5kIHRyaWVzIHVzZSBnb3Zlcm5vciB0byBkZWxpdmVyIHRoZWly
IHBlcmZvcm1hbmNlIHBvbGljeSwgc3VjaCBhcyBkZWZpbmluZyBzdWNoIGNwdWZyZXEgY21kbGlu
ZQ0KImNwdWZyZXE9cGVyZm9ybWFuY2UsYW1kLWNwcGMsYWN0aXZlIg0KUXVvdGluZyB3aGF0IEkg
cmVwbGllZCBpbiBhbm90aGVyIHRocmVhZDoNCg0KVGhlIG9ubHkgdXNlZnVsIGluZm8gaW4gZ292
ZXJub3IgZm9yIGVwcCBtb2RlLCBJTU8sIGlzIGl0cyBuYW1lLg0KSSBkZWR1Y2Ugd2hpY2ggcGVy
Zm9ybWFuY2UgcG9saWN5IHVzZXIgd2FudHMgdG8gYXBwbHkgdGhyb3VnaCB3aGljaCBnb3Zlcm5v
ciB0aGV5IGNob29zZS4NCklmIHVzZXIgY2hvb3NlcyBwZXJmb3JtYW5jZSBnb3Zlcm5vciwgdGhl
eSB3YW50IG1heGltdW0gcGVyZm9ybWFuY2UuDQpJZiB1c2VyIGNob29zZXMgcG93ZXJzYXZlIGdv
dmVybm9yLCB0aGV5IHdhbnQgdGhlIGxlYXN0IHBvd2VyIGNvbnN1bXB0aW9uIEkgY291bGQgb25s
eSBwcm92aWRlIGFwcHJvcHJpYXRlIGVwcCB2YWx1ZSBpbiBhYm92ZSB0d28gc2NlbmFyaW9zLg0K
b25kZW1hbmQgYW5kIHVzZXJzcGFjZSBhcmUgZm9yYmlkZGVuIGNob2ljZXMsIGFuZCBpZiB1c2Vy
cyBzcGVjaWZ5IHN1Y2ggb3B0aW9ucyBpbiBjbWRsaW5lLCBJIHNoYWxsIGdpdmUgd2FybmluZyBt
ZXNzYWdlIHRvIHNheSAgdGhhdCBhbWQtY3BwYyBpbiBhY3RpdmUgbW9kZSBpcyBnb3Zlcm5vci1s
ZXNzLCBhbmQgdXNlcnMgY291bGQgc2V0IGVwcCB2YWx1ZXMgb24gcnVudGltZSB0byBzcGVjaWZ5
IGJpYXMgdG93YXJkcyBwZXJmb3JtYW5jZSBvciBlZmZpY2llbmN5Lg0KDQo+IEphbnINCj4NCj4g
PiBIYXJkd2FyZSBpdHNlbGYgd2lsbCBhdXRvbWF0aWNhbGx5IGNhbGN1bGF0ZSBhbmQgc2V0IGZy
ZXF1ZW5jeS4gVXNlciBvbmx5IHNoYWxsIHNldA0KPiBtaW5fcGVyZiwgbWF4X3BlcmYsIGFuZCBF
UFAgYXQgdGhlIGJlZ2lubmluZy4NCj4gPiBFUFAgaXMgYSBwcmVmZXJlbmNlIHJhdGlvIHZhbHVl
IHRvd2FyZHMgcGVyZm9ybWFuY2Ugb3ZlciBwb3dlcnNhdmUsIG9uDQo+ID4gdGhlIHNjYWxlIG9m
IDAtMjU1LCAwIGFzIDEwMCUgcGVyY2VudGFnZSBmYXZvcmluZyBwZXJmb3JtYW5jZSwgd2hpbGUg
MjU1IGFzDQo+IDEwMCUgcGVyY2VudGFnZSBmYXZvcmluZyBwb3dlcnNhdmUgTm9uLUVQUCBkcml2
ZXIgaXMgc3RpbGwgcmVseWluZyBvbiBYZW4NCj4gZ292ZXJub3IgdG8gZG8gdGhlIHR1bmluZy4N
Cj4gPg0KPiA+PiBKYW4NCg0K


From xen-devel-bounces@lists.xenproject.org Thu May 22 08:49:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:49:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993245.1376681 (Exim 4.92)
	(envelope-from )
	id 1uI1cT-0005KW-PZ; Thu, 22 May 2025 08:49:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993245.1376681; Thu, 22 May 2025 08:49: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 1uI1cT-0005KP-LM; Thu, 22 May 2025 08:49:41 +0000
Received: by outflank-mailman (input) for mailman id 993245;
 Thu, 22 May 2025 08:49:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI1cS-0004UT-0c
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:49:40 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b257b596-36e9-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 10:49:39 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-445b11306abso31199355e9.3
 for ; Thu, 22 May 2025 01:49:39 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f38142f1sm96587395e9.31.2025.05.22.01.49.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 01:49: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" 
X-Inumbo-ID: b257b596-36e9-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747903779; x=1748508579; 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;
        bh=c8l19uXgmUMdMBBrIbGU3wYkycmyZxvGhh4gllaGzig=;
        b=FLdMG6G8N6fXZd9bnKmA6m2/Whc4GlCDwf9e09ckoofsdPH6IncimUBuoiRXHqrYFn
         ZQ0MroMGS2eY8L0jwmi3fI/Rtw+lUJYVIqHGsu404W62HhiGE4OrEwnVtJ/CgmxJ+xi4
         zkXA4HTw4dDnvAowf1x+AOJAvHrJNWiNHMpr8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747903779; x=1748508579;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=c8l19uXgmUMdMBBrIbGU3wYkycmyZxvGhh4gllaGzig=;
        b=PvgHe4vHTYmhbCad6G6tZA/R3F9WIHYslbqDl6GXFoqzkAKqKRkpwu/DkHkFr+T4TB
         Tx8dPRtZKC16vBO1YQ2Ust2QuXdWc+Yx6CDsPZp/QUuQf2Yw4jWbovq+oGj0u4cGCUfZ
         o+ltwx5hx5IAe4VU/kIj7yt8K38jx9IHTUL2V20CKBlPpjbLsARq8ezUxWB8uJOKOqkS
         1eUTuEJjO5VYZ+I5cJCraxvfX4MlLG4Z290/PcvzkJ+XyXns1ohHZJt3LCI2VSngJHJs
         IQFEvfgNUlqdJq3y06BGc1LBfX5cfjgtKsXFtB61AhV7X/58Dg75Z6KOFtYiqpriltiT
         RvAg==
X-Gm-Message-State: AOJu0YxI40V4Eo8Woh6pUjfIGN90Pzve7ngT8iUaAHhhcu42WJXtmdfS
	JFFRj79gs+y/zZYrVIMsBEAtNbHmlYm6NBh7tpTx4m3EVHNI1+dOdU5G/Q7wEeJOuCD530gP/OZ
	m+b71
X-Gm-Gg: ASbGncuMyvqZt2PNz5CY86ueyR54P0syQmT9wOilF9m7SHlrcs1gZ8vhGh/EUvqSTFQ
	2OYZ/vUge5mIgkLxnUzXYMAmcYNkm28Qvn+51vUq5Y0Vui5SgKEGf42h7adsD6I+gpEZmgEFKop
	qIZ+XoN4LC90AlNg1Fg7EzMRQ5t6B92imBxiNq3Nf7TLIu29U0Z/Ydo2sOlk095Qf9EgSbwzI6S
	xvN9YQEKO4flWW0mZYfnuKuy4+3zFCfPrdJ+O5THZDC+06i/KyEiAAopR8nbtvHstQCeBxwf/gg
	cV3xosQAmjKaCQU6ySRKov8kAvrS5RCgj3y9EREKLXx3QdrJoq+f6jNXo3XqxeF+YVKwHkAT/gd
	KFSgBjY8hejKMUl5RELoCq/4Snfu5vw==
X-Google-Smtp-Source: AGHT+IHQxmPOG+Q7hPlR1p2LjxFO0FsHwt+099+4SK7UkCbLXnu/l+afNQ84ip27Z8RzbRIjgQf97Q==
X-Received: by 2002:a05:600c:4e87:b0:440:59eb:bfc with SMTP id 5b1f17b1804b1-442ff032a90mr183097795e9.23.1747903778821;
        Thu, 22 May 2025 01:49:38 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 0/2] x86/numa: introduce per-node flush_lock
Date: Thu, 22 May 2025 10:48:13 +0200
Message-ID: <20250522084815.825-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

I've had this patches pending for quite some time, but never sent them.
Kind of RFC because I'm unsure whether the approach is the best, there's
however a need to split the flush_lock, as on hosts with a high number
of CUPs there's there's a non-trivial amount of contention around it.

First patch is a preparatory change to allow using per-NUMA node locks,
second patch introduces a per-node flush_lock.

Thanks, Roger.

Roger Pau Monne (2):
  x86/numa: add per-node lock profile objects
  x86/numa: introduce per-NUMA node flush locks

 tools/misc/xenlockprof.c               |  5 ++
 xen/arch/x86/include/asm/irq-vectors.h |  9 ++-
 xen/arch/x86/include/asm/numa.h        |  3 +
 xen/arch/x86/include/asm/smp.h         |  3 +
 xen/arch/x86/numa.c                    | 95 ++++++++++++++++++++++++++
 xen/arch/x86/smp.c                     | 16 +++--
 xen/arch/x86/smpboot.c                 |  3 +
 xen/common/numa.c                      | 23 +++++++
 xen/common/spinlock.c                  |  1 +
 xen/include/public/sysctl.h            |  3 +-
 xen/include/xen/numa.h                 | 13 ++++
 11 files changed, 168 insertions(+), 6 deletions(-)

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 22 08:49:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:49:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993246.1376690 (Exim 4.92)
	(envelope-from )
	id 1uI1cV-0005au-0f; Thu, 22 May 2025 08:49:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993246.1376690; Thu, 22 May 2025 08:49: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 1uI1cU-0005ac-SO; Thu, 22 May 2025 08:49:42 +0000
Received: by outflank-mailman (input) for mailman id 993246;
 Thu, 22 May 2025 08:49:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI1cT-0004UT-3w
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:49:41 +0000
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com
 [2a00:1450:4864:20::42a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b2eaa07b-36e9-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 10:49:40 +0200 (CEST)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a376da332aso3083459f8f.3
 for ; Thu, 22 May 2025 01:49:40 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a36a83b63bsm16513777f8f.97.2025.05.22.01.49.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 01:49: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" 
X-Inumbo-ID: b2eaa07b-36e9-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747903780; x=1748508580; 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;
        bh=yx4+zgGbRpsEhggPXSuzqYHsD8VxJjLcNb6O+IlJ+kk=;
        b=QZ1/ryVOxfwYLy0E/5QXXMJdFJnw0yixEDZoOZkkGp1SjQcRg8uW77BYcwwPFA+4M/
         GcpQswXz4iDbdujiiz0fO7tKhE4mmxgQ0h4SLrPgR+tBVvu4oCgmrDTz6oWLGmvbjYTM
         uxXqcH7hfLjwnNdddTcmjrjrATU7vG1h/0nU4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747903780; x=1748508580;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=yx4+zgGbRpsEhggPXSuzqYHsD8VxJjLcNb6O+IlJ+kk=;
        b=nVnm1ZohT0MPMTCnbVhMti33stppZUYnm7ARc6qGRotkyYaxEwF6hWAyZpF+Kuaw42
         8Jf16aPMiZVwegaoTkd+VNWc2qlewrMfUK8mnmSeM0FbuUcHGV9s5asl1bcx+pmjna2Z
         mbz9/m+81PQvs933U8O9qBy+cLCWMK1raUV7PO7Ph931/8rcOEubj8BzZ7K/selXM2Fi
         hRgEmKLJenZ+o/t4f/SAyAHGa7LJNsALiaGWzj6FNJcUYqdpY1Xq+GmZTx8xEQii/bhp
         WguwPt8z9LFeEdUitkskiJVGRfI6D4RtcrjmGRBRusQBq31KFNsgo93ZL9oFURV5hWdx
         A7Zg==
X-Gm-Message-State: AOJu0YzIzMpZOsPWIMZBiLMWJafkgyJxadUKCIfHpQOnbvaL5tVV+ZZ9
	IsCkyLke1Ry16ch0FUBP8QHAGnqSIN2Bsdgx8MTB+DwMzaATwBOxRHfy6Ox2ouzrdoXYt5CHbWA
	Q7k3N
X-Gm-Gg: ASbGncuzsxftjVwXegUfmiset74FoEf/cMqg9GuPsh/FViYLWPOqVK+NE7qVWTDhQjk
	YVJnN5r6rCY/8L1IqXIEPuwrEr5qsZt2M3BzaPn752Od8N4CquqlXpHaW69j52xPCNJCC00pAOJ
	DTPMAfD0Q922yrCxA8+5iIDEhyT/pGZwbLDEKMVm+P31LnbV00mMhJmeWxMZUr/lEODd0S4Lsd4
	wFKj6BNoSUwxUs/cd9QaveiHm2ZuSsDJ8aKWrlj/2G956x1bF6m84f/iNuoK1+OoXsEvy5MZGw1
	FkQu3HMVqA0c5NS6iem5HZEolby//AF7S5/qfYlf9/fTukfgZxdVoyDhiaEQ4r7otbmoOzEg3Ln
	1ldDxbOWt/B/xst4bHfY=
X-Google-Smtp-Source: AGHT+IGs65c5GaODEoeBQP2cvvjUWxKsUEUaJ4YXDd8yKvkd/ufGowoFvdMoMKg3sSjPN9c+lCHnYA==
X-Received: by 2002:a5d:64c7:0:b0:3a3:6584:3fa1 with SMTP id ffacd0b85a97d-3a365844ba6mr20445053f8f.44.1747903779803;
        Thu, 22 May 2025 01:49:39 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 1/2] x86/numa: add per-node lock profile objects
Date: Thu, 22 May 2025 10:48:14 +0200
Message-ID: <20250522084815.825-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250522084815.825-1-roger.pau@citrix.com>
References: <20250522084815.825-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Add some basic infrastructure to be able to use lockprofile with per NUMA
node locks.  This patch just introduces the required types, plus the
printing of the data for the newly introduced type.  There's no user of
per NUMA node locks introduced here.

Signed-off-by: Roger Pau Monné 
---
 tools/misc/xenlockprof.c    | 5 +++++
 xen/common/spinlock.c       | 1 +
 xen/include/public/sysctl.h | 3 ++-
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/misc/xenlockprof.c b/tools/misc/xenlockprof.c
index 11f43a35e3c0..3fc91e832ae5 100644
--- a/tools/misc/xenlockprof.c
+++ b/tools/misc/xenlockprof.c
@@ -96,6 +96,11 @@ int main(int argc, char *argv[])
         case LOCKPROF_TYPE_PERDOM:
             sprintf(name, "domain %d lock %s", data[j].idx, data[j].name);
             break;
+
+        case LOCKPROF_TYPE_PERNODE:
+            sprintf(name, "NUMA node %d lock %s", data[j].idx, data[j].name);
+            break;
+
         default:
             sprintf(name, "unknown type(%d) %d lock %s", data[j].type,
                     data[j].idx, data[j].name);
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 38caa10a2ea2..d86e32bd67aa 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -612,6 +612,7 @@ static s_time_t lock_profile_start;
 static struct lock_profile_anc lock_profile_ancs[] = {
     [LOCKPROF_TYPE_GLOBAL] = { .name = "Global" },
     [LOCKPROF_TYPE_PERDOM] = { .name = "Domain" },
+    [LOCKPROF_TYPE_PERNODE] = { .name = "NUMA node" },
 };
 static struct lock_profile_qhead lock_profile_glb_q;
 static spinlock_t lock_profile_lock = SPIN_LOCK_UNLOCKED;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 9eca72865b87..bcf3dd3b1f31 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -582,7 +582,8 @@ struct xen_sysctl_page_offline_op {
 /* Record-type: */
 #define LOCKPROF_TYPE_GLOBAL      0   /* global lock, idx meaningless */
 #define LOCKPROF_TYPE_PERDOM      1   /* per-domain lock, idx is domid */
-#define LOCKPROF_TYPE_N           2   /* number of types */
+#define LOCKPROF_TYPE_PERNODE     2   /* pNUMA per-node lock, idx is node ID */
+#define LOCKPROF_TYPE_N           3   /* number of types */
 struct xen_sysctl_lockprof_data {
     char     name[40];     /* lock name (may include up to 2 %d specifiers) */
     int32_t  type;         /* LOCKPROF_TYPE_??? */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 22 08:49:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 08:49:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993248.1376697 (Exim 4.92)
	(envelope-from )
	id 1uI1cV-0005eM-Cj; Thu, 22 May 2025 08:49:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993248.1376697; Thu, 22 May 2025 08:49: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 1uI1cV-0005dr-4P; Thu, 22 May 2025 08:49:43 +0000
Received: by outflank-mailman (input) for mailman id 993248;
 Thu, 22 May 2025 08:49:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI1cU-0004UT-B9
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 08:49:42 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b3aef5b4-36e9-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 10:49:42 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-441ab63a415so83607895e9.3
 for ; Thu, 22 May 2025 01:49:41 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca888fcsm23433058f8f.78.2025.05.22.01.49.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 01:49: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" 
X-Inumbo-ID: b3aef5b4-36e9-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747903781; x=1748508581; 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;
        bh=wbA2N4Sx+9yCupSjz9rtr7Z+UbsRZXxcS06NGIutUUY=;
        b=udcXFWMtRldhtN2jk1oxOGq30P46YeT3j6Qr9goEsqpLYbZDjfwGVmOmPIjGO2+m8Q
         kTzPv76D0n/yJHTAOc4qhPFdwvYva+0aba/tleekZCXS8UzfUm7DPL/d2rCBs89KDHiR
         0HVnax/SQbTgWeBhdWZNoAqk4cAArHWPBlV6k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747903781; x=1748508581;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=wbA2N4Sx+9yCupSjz9rtr7Z+UbsRZXxcS06NGIutUUY=;
        b=p+A4hLUP77qz3Es2IXD5zXMKDzE56Ewce/upGHRkKVCy+0P6q2xZRmDOi23Xxo4zvX
         j4k5rb93X4H321/Y7zoDsYRgdbn5NXDI9VuOvz57tm343ft+1eIicAcasCk/HwnFe5sz
         618oqiSn95aeD5CBR49YVHNQkjdMPnbvgr+cmF8IApb6ikp2NGGwIHP0JjNozDGd6KxZ
         vsB13/H2BKo+knWF+1jncnmbCxg0hm3xtzIKXXi2zwHkPqMIKwFD/xo+jWG/lkyAt4tU
         24PJv3K8Wl82jLsea3NNE4O2V9N5LwDFfFdct3d3Kdnld/FZ57YLLeGi9r2EQglEDWMt
         BRDA==
X-Gm-Message-State: AOJu0YzhQmFlUs3/EiTcOCU8a6c/jTzUSs1Qg0i+le2C9t57HG91coC0
	s6wd6Y8fACSs6S28FPQLAtUZ4ejeLQmKFJ+0Qc1zkWdyaqGXQ7ATunXezoCqeC8Dor0aAf5lPem
	nPWRU
X-Gm-Gg: ASbGnct5LB47G7V2QxU7B/Q+mULrbrsyHSXwx7petEMzbba1egaMkMyDUEXls72nEJa
	Ulxbl1/uxbXVRB3s44xgdOUGA4AtymJZT0ZTmAHQzki/0C9NaXtXjAsqkRhGUZMP97gs2pJZNtI
	lf6Qi+BEh2SM/kKh4dqVGuzvssoGD3V2XXZ8ZIvaEei6LO2LlgZJcr73QU4FviZzeX5QXZxTcLC
	s4qiD5Am2AAQzcfTUbpChYTaQ+wQROvFcoeFWZzaYa0hqwocR7btPT7JUY7SPGUbxcOGDV/BvLB
	Q6+O1a1S8UQiDaGq+hKbFERsFb8tH8RPATmn6ccGjqnJ4cCY0axyidatJ8ZpRP1f3YV5NR+so37
	yJzIhqHET07X+gmbL7QIQ5Tx/J1YSkg==
X-Google-Smtp-Source: AGHT+IHkRhaunxLXl2soEk1ANBtB65BNTfNZfbNCiHa/VpK9eH15Hdp9wbjWw5ayH1Vdh+dcHL6znQ==
X-Received: by 2002:a05:600c:1d81:b0:43c:fc04:6d35 with SMTP id 5b1f17b1804b1-442fd606b8emr230238295e9.4.1747903780774;
        Thu, 22 May 2025 01:49:40 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH 2/2] x86/numa: introduce per-NUMA node flush locks
Date: Thu, 22 May 2025 10:48:15 +0200
Message-ID: <20250522084815.825-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250522084815.825-1-roger.pau@citrix.com>
References: <20250522084815.825-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Contention around the global flush_lock increases as the amount of physical
CPUs on the host also increases.  Sadly this doesn't scale on big boxes.
However most of the time Xen doesn't require broadcasting flushes to all
CPUs on the system, and hence more fine grained (ie: covering less CPUs)
locks could be used.

A natural boundary to use when splitting the locks are NUMA nodes.  Most
domains will be limited to running on a single node, specifically the one
where the domain memory has been allocated from.  Flushes related to
domains are most likely to be limited to a single NUMA node, and hence
being able to execute per-node flushes allows to reduce the contention
around the global flush_lock, while also allowing to perform concurrent
flushes on different nodes.

This however doesn't come for free.  A new vector must be allocated to be
used for the per-NUMA flushes, and more logic is required in the flush
dispatcher to figure out whether a flush is limited to a single node.

The figures on a 2-node NUMA system are as follows, after having been
running the same XenRT boot storm workload for 90 minutes.

Without the per-NUMA node flush:

Global flush_lock: addr=ffff82d040837340, lockval=d8ded8de, not locked
  lock:21878876(98178042228), block:1603338(6043805110)

So a total block time of ~6s, and average block time of 3.7us.

With the per-node locks:

Global flush_lock: addr=ffff82d040837360, lockval=78e678e6, not locked
  lock:6781028(41032945811), block:583712(2025657239)
NUMA node 1 flush_lock: addr=ffff832fd085b110, lockval=5cd65cd6, not locked
  lock:220374(766500536), block:4091(9933129)
NUMA node 0 flush_lock: addr=ffff8310336a7110, lockval=5c715c71, not locked
  lock:547953(1658170241), block:23856(51266297)

The total block time goes down to ~2s, and the average block time is 3.4us.
The total block time of the per-node locks is much lower compared to the
global flush_lock, 9ms and 51ms respectively.

Note the example here is possibly the system where such split locks don't
make a lot of difference, being a 2 node system, but still there's a
non-trivial difference between the block times.  On a 4 or 9 node system
the figures should likely be even better.

Signed-off-by: Roger Pau Monné 
---
Kind of RFC, had this patch pending for some time on my queue.  Before
working further on this I would like to make sure the approach is OK.
---
 xen/arch/x86/include/asm/irq-vectors.h |  9 ++-
 xen/arch/x86/include/asm/numa.h        |  3 +
 xen/arch/x86/include/asm/smp.h         |  3 +
 xen/arch/x86/numa.c                    | 95 ++++++++++++++++++++++++++
 xen/arch/x86/smp.c                     | 16 +++--
 xen/arch/x86/smpboot.c                 |  3 +
 xen/common/numa.c                      | 23 +++++++
 xen/include/xen/numa.h                 | 13 ++++
 8 files changed, 160 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/include/asm/irq-vectors.h b/xen/arch/x86/include/asm/irq-vectors.h
index f546aedd87de..3b8fee7e22cf 100644
--- a/xen/arch/x86/include/asm/irq-vectors.h
+++ b/xen/arch/x86/include/asm/irq-vectors.h
@@ -9,12 +9,19 @@
 #define CALL_FUNCTION_VECTOR	0xfb
 #define LOCAL_TIMER_VECTOR	0xfa
 #define PMU_APIC_VECTOR 	0xf9
+
+#ifdef CONFIG_NUMA
+# define INVALIDATE_NUMA_VECTOR  0xf8
+# define LAST_HIPRIORITY_VECTOR  0xf7
+#else /* !CONFIG_NUMA */
+# define LAST_HIPRIORITY_VECTOR  0xf8
+#endif /* !CONFIG_NUMA */
+
 /*
  * High-priority dynamically-allocated vectors. For interrupts that
  * must be higher priority than any guest-bound interrupt.
  */
 #define FIRST_HIPRIORITY_VECTOR	0xf1
-#define LAST_HIPRIORITY_VECTOR  0xf8
 /* IRQ0 (timer) is statically allocated but must be high priority. */
 #define IRQ0_VECTOR             0xf0
 
diff --git a/xen/arch/x86/include/asm/numa.h b/xen/arch/x86/include/asm/numa.h
index 7866afa40860..e68c2d9d9bea 100644
--- a/xen/arch/x86/include/asm/numa.h
+++ b/xen/arch/x86/include/asm/numa.h
@@ -25,4 +25,7 @@ void srat_parse_regions(paddr_t addr);
 extern u8 __node_distance(nodeid_t a, nodeid_t b);
 unsigned int arch_get_dma_bitsize(void);
 
+bool flush_numa_node(const cpumask_t *mask, const void *va, unsigned int flags);
+void cf_check invalidate_tbl_numa(void);
+
 #endif
diff --git a/xen/arch/x86/include/asm/smp.h b/xen/arch/x86/include/asm/smp.h
index c8c79601343d..1e6972fd7b39 100644
--- a/xen/arch/x86/include/asm/smp.h
+++ b/xen/arch/x86/include/asm/smp.h
@@ -79,6 +79,9 @@ extern bool unaccounted_cpus;
 
 void *cpu_alloc_stack(unsigned int cpu);
 
+void invalidate_tlb_handler(const void *va, unsigned int flags,
+                            cpumask_t *mask);
+
 #endif /* !__ASSEMBLY__ */
 
 #endif
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index ae3cc7a8d060..0139fe5377ba 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -8,8 +8,11 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
+#include 
 
 #ifndef Dprintk
 #define Dprintk(x...)
@@ -126,3 +129,95 @@ int __init arch_get_ram_range(unsigned int idx, paddr_t *start, paddr_t *end)
 
     return 0;
 }
+
+static struct arch_numa_node {
+    const void *flush_va;
+    unsigned int flush_flags;
+    cpumask_t flush_mask;
+    spinlock_t flush_lock;
+    struct lock_profile_qhead profile_head;
+} *node_info[MAX_NUMNODES];
+
+static int __init cf_check arch_numa_init(void)
+{
+    unsigned int i;
+
+    if ( num_online_nodes() == 1 )
+        return 0;
+
+    for_each_online_node ( i )
+    {
+        struct arch_numa_node *node =
+            alloc_xenheap_pages(get_order_from_bytes(sizeof(*node)),
+                                                     MEMF_node(i));
+
+        if ( node )
+            clear_page(node);
+        else
+            node = xvzalloc(typeof(*node));
+
+        if ( !node )
+        {
+            printk(XENLOG_WARNING
+                   "failed to allocate NUMA info struct for node %u\n", i);
+            return 0;
+        }
+
+        spin_lock_init(&node->flush_lock);
+        lock_profile_register_struct(LOCKPROF_TYPE_PERNODE, node, i);
+        spin_lock_init_prof(node, flush_lock);
+        node_info[i] = node;
+    }
+
+    return 0;
+}
+__initcall(arch_numa_init);
+
+void cf_check invalidate_tbl_numa(void)
+{
+    unsigned int cpu = smp_processor_id();
+    nodeid_t node = cpu_to_node[cpu];
+    struct arch_numa_node *info = node_info[node];
+
+    ASSERT(info);
+
+    invalidate_tlb_handler(info->flush_va, info->flush_flags,
+                           &info->flush_mask);
+}
+
+bool flush_numa_node(const cpumask_t *mask, const void *va, unsigned int flags)
+{
+    nodeid_t node = num_online_nodes() > 1 ? cpumask_to_node(mask)
+                                           : NUMA_NO_NODE;
+    struct arch_numa_node *info;
+
+    if ( node == NUMA_NO_NODE )
+        return false;
+
+    info = node_info[node];
+
+    if ( !info )
+        return false;
+
+    spin_lock(&info->flush_lock);
+    cpumask_and(&info->flush_mask, mask, &cpu_online_map);
+    cpumask_clear_cpu(smp_processor_id(), &info->flush_mask);
+    info->flush_va = va;
+    info->flush_flags = flags;
+    send_IPI_mask(&info->flush_mask, INVALIDATE_NUMA_VECTOR);
+    while ( !cpumask_empty(&info->flush_mask) )
+        cpu_relax();
+    spin_unlock(&info->flush_lock);
+
+    return true;
+}
+
+/*
+ * 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/x86/smp.c b/xen/arch/x86/smp.c
index 516dab5528c1..06acc5843f9a 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -247,16 +247,21 @@ static cpumask_t flush_cpumask;
 static const void *flush_va;
 static unsigned int flush_flags;
 
-void cf_check invalidate_interrupt(void)
+void invalidate_tlb_handler(const void *va, unsigned int flags,
+                            cpumask_t *mask)
 {
-    unsigned int flags = flush_flags;
     ack_APIC_irq();
     perfc_incr(ipis);
     if ( (flags & FLUSH_VCPU_STATE) && __sync_local_execstate() )
         flags &= ~(FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_ROOT_PGTBL);
     if ( flags & ~(FLUSH_VCPU_STATE | FLUSH_ORDER_MASK) )
-        flush_area_local(flush_va, flags);
-    cpumask_clear_cpu(smp_processor_id(), &flush_cpumask);
+        flush_area_local(va, flags);
+    cpumask_clear_cpu(smp_processor_id(), mask);
+}
+
+void cf_check invalidate_interrupt(void)
+{
+    invalidate_tlb_handler(flush_va, flush_flags, &flush_cpumask);
 }
 
 void flush_area_mask(const cpumask_t *mask, const void *va, unsigned int flags)
@@ -281,6 +286,9 @@ void flush_area_mask(const cpumask_t *mask, const void *va, unsigned int flags)
              !hypervisor_flush_tlb(mask, va, flags) )
             return;
 
+        if ( flush_numa_node(mask, va, flags) )
+            return;
+
         spin_lock(&flush_lock);
         cpumask_and(&flush_cpumask, mask, &cpu_online_map);
         cpumask_clear_cpu(cpu, &flush_cpumask);
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 50c5674555e4..eb8600eb008f 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1451,4 +1451,7 @@ void __init smp_intr_init(void)
     set_direct_apic_vector(EVENT_CHECK_VECTOR, event_check_interrupt);
     set_direct_apic_vector(INVALIDATE_TLB_VECTOR, invalidate_interrupt);
     set_direct_apic_vector(CALL_FUNCTION_VECTOR, call_function_interrupt);
+#ifdef CONFIG_NUMA
+    set_direct_apic_vector(INVALIDATE_NUMA_VECTOR, invalidate_tbl_numa);
+#endif
 }
diff --git a/xen/common/numa.c b/xen/common/numa.c
index ad75955a1622..b9bb8628fb6b 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -689,6 +689,29 @@ static int __init cf_check numa_setup(const char *opt)
 }
 custom_param("numa", numa_setup);
 
+/*
+ * Return the NUMA node index if all CPUs in the mask belong to the same node,
+ * otherwise return NUMA_NO_NODE.
+ */
+nodeid_t cpumask_to_node(const cpumask_t *mask)
+{
+    unsigned int cpu;
+    nodeid_t node = NUMA_NO_NODE;
+
+    if ( num_online_nodes() == 1 )
+        return cpu_to_node[0];
+
+    for_each_cpu ( cpu, mask )
+    {
+        if ( node == NUMA_NO_NODE )
+            node = cpu_to_node[cpu];
+        else if ( node != cpu_to_node[cpu] )
+            return NUMA_NO_NODE;
+    }
+
+    return node;
+}
+
 static void cf_check dump_numa(unsigned char key)
 {
     s_time_t now = NOW();
diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h
index f6c1f27ca105..256dfbcf85f8 100644
--- a/xen/include/xen/numa.h
+++ b/xen/include/xen/numa.h
@@ -128,6 +128,8 @@ extern bool numa_update_node_memblks(nodeid_t node, unsigned int arch_nid,
                                      paddr_t start, paddr_t size, bool hotplug);
 extern void numa_set_processor_nodes_parsed(nodeid_t node);
 
+extern nodeid_t cpumask_to_node(const cpumask_t *mask);
+
 #else
 
 /* Fake one node for now. See also node_online_map. */
@@ -148,6 +150,17 @@ static inline nodeid_t mfn_to_nid(mfn_t mfn)
     return 0;
 }
 
+static inline nodeid_t cpumask_to_node(const cpumask_t *mask)
+{
+    return NUMA_NO_NODE;
+}
+
+#ifdef CONFIG_X86
+static inline bool flush_numa_node(const cpumask_t *mask, const void *va,
+                                   unsigned int flags)
+{ return false; }
+#endif /* CONFIG_X86 */
+
 #endif
 
 #define page_to_nid(pg) mfn_to_nid(page_to_mfn(pg))
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 22 09:10:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 09:10:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993317.1376725 (Exim 4.92)
	(envelope-from )
	id 1uI1wk-0003hR-8N; Thu, 22 May 2025 09:10:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993317.1376725; Thu, 22 May 2025 09:10: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 1uI1wk-0003hK-5p; Thu, 22 May 2025 09:10:38 +0000
Received: by outflank-mailman (input) for mailman id 993317;
 Thu, 22 May 2025 09:10:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI1wi-0003hA-FE
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 09:10:36 +0000
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [2a00:1450:4864:20::432])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9eb0db27-36ec-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 11:10:35 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a36748920cso4964199f8f.2
 for ; Thu, 22 May 2025 02:10:35 -0700 (PDT)
Received: from [10.10.6.18] (server.hotelpassage.eu. [88.146.207.194])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca8cfb8sm21556178f8f.85.2025.05.22.02.10.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 02:10: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" 
X-Inumbo-ID: 9eb0db27-36ec-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747905035; x=1748509835; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=7KflOCq7BeS3fgdiD47nTA671QGwjH0OBoU3sAG/QC0=;
        b=Wd31iBMrVbiWHDPD3+lU72PIy/qZJKkSarAIfoWCojnnltI/haTgQtikY4VpuilStU
         jjB7AEEng5d80zINYpDmL1HlUgHYt70A1k5FfHwvbyXGEQ/rlTWjS0n8eGkiaHN5VfVP
         BOeLHtvqaXdxUnC27nhrrkSMc7IJMhOftDnKuqwqVfSHmcBOfS9tN5eCSxJyDlhPAtG+
         UOr/cWLtHOyz9nLoAMo6tFBHbJ4wjJndlM3feLIpEMJg47qbZ/5/nP1ACmz18mRrBrbz
         mDoSB/V4d9B2pKntsP2uc4m+8d6iiT612aQ1MarsTU0QMRd1P2irk+YZU4Mvc1ye1sgD
         TF0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747905035; x=1748509835;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7KflOCq7BeS3fgdiD47nTA671QGwjH0OBoU3sAG/QC0=;
        b=NErKGArL2sBuKr2lhU4f8/ZYh/SkJVkSENivq0FWMhP3hm5E0Iojhpy8hcPhhOV6hZ
         /1hu/Izx2ToNCT+r+Ll+QTHfTm08s/n8hnt+Jh8ZcmwVBAIxPEXTMxrO27b8q8WvBwf0
         h2/Rdr4unRbkFWxUYZQNpdL6LkqV7FjMZOnKPINrpAo4GT07PpcqSDx7bEbxR5FXirq8
         TW1A5pOhwRjbuspKh1gwm/JaVkUkFyBKvpmfhGo+MjGYNsQAtUBDtm9F8wvnbvpAT7+T
         fH9bIHw7biF3ptIzKhe0bs0YXm3ZQ6nDjRdYqF4ThqHqeyQv8CzgZSPF9qQ+rHiCcT5T
         AzVQ==
X-Forwarded-Encrypted: i=1; AJvYcCW/SCVodV9MnaP3wDYw0qJh5RZ8ICaK8EZMOnMRwRrJkYIQn9dzTL9vjyWuhgmQRfTk6agZxPrf1i4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxKRbC95qBn45CbJGsr2JauHFanKjnhZZVOzqOlwbEpoMX04Ia4
	pJOuMX5hVr1FzjXQYUSf1buxpoDbs/OreLe8yDYT7dYbPNhto/t24KaDOhIakaIqAw==
X-Gm-Gg: ASbGncsfmEfiUftV9Lmz26zxEwDqN4XG6aTMUiww28sx5vf8Cqgto6ICnYE4p49J6gS
	0P+wc3moNx2XKtL7Swd2SxmPB3yNAlupPr/ZxfnBpayMYuEgwG92mGaxtTMN07PnoHH8MNwHNr1
	fNvnfCd8Hops76Xek43VFrCIIyP1dgzQnq14lKDnq0xnT9KWHD+6dxEUP6WYMP8m4MiFgaCVyfB
	Y2U+s8nODrtHa04qvEVsgbvshTytrhOyMFZyOZSwaU8QoU022OCXQ0GnoPCFFgxJg6yofjwfLTy
	WSd2mREL6fMMQ7hDAsM0LvLW3qb0bBgihZ8ZkdWoo1kux+Nq6bkFEdbnCIJk4y9le9TXw5XNqlX
	Tmmyh
X-Google-Smtp-Source: AGHT+IGOUuIeVn8Il/mmPQ88Wrp8b+Jl2eOQCaQKmrVjE6EDZTCMBJgQoKK0SdiMVoCxsuBpguKccA==
X-Received: by 2002:a5d:5888:0:b0:3a3:760c:81b7 with SMTP id ffacd0b85a97d-3a3760c82c6mr12807370f8f.57.1747905034672;
        Thu, 22 May 2025 02:10:34 -0700 (PDT)
Message-ID: <0028ad37-95e7-4b6e-87b6-07cadcac64aa@suse.com>
Date: Thu, 22 May 2025 11:10:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] x86/boot: print CPU and APIC ID in bring up
 failure
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250522075440.99882-1-roger.pau@citrix.com>
 <20250522075440.99882-2-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250522075440.99882-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.05.2025 09:54, Roger Pau Monne wrote:
> Print the CPU and APIC ID that fails to respond to the init sequence, or
> that didn't manage to reach the "callin" state.  Expand a bit the printed
> error messages.  Otherwise the "Not responding." message is not easy to
> understand by users.
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 
> ---
> Changes since v1:
>  - Also print APIC ID.
> ---
>  xen/arch/x86/smpboot.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 0189d6c332a4..dbc2f2f1d411 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -618,10 +618,12 @@ static int do_boot_cpu(int apicid, int cpu)
>              smp_mb();
>              if ( bootsym(trampoline_cpu_started) == 0xA5 )
>                  /* trampoline started but...? */
> -                printk("Stuck ??\n");
> +                printk("CPU%u/APICID%u: Didn't finish startup sequence\n",
> +                       cpu, apicid);
>              else
>                  /* trampoline code not run */
> -                printk("Not responding.\n");
> +                printk("CPU%u/APICID%u: Not responding to startup\n",
> +                       cpu, apicid);
>          }
>      }
>  

Elsewhere I think we print AIC IDs in hex; may be better to do so here, too.
That may then want some text re-arrangement though, e.g.

"CPU%u: APICID %#x not responding to startup\n"

Thoughts?

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 09:11:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 09:11:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993329.1376744 (Exim 4.92)
	(envelope-from )
	id 1uI1xP-0004Pi-Me; Thu, 22 May 2025 09:11:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993329.1376744; Thu, 22 May 2025 09:11: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 1uI1xP-0004Pb-Js; Thu, 22 May 2025 09:11:19 +0000
Received: by outflank-mailman (input) for mailman id 993329;
 Thu, 22 May 2025 09:11:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI1xO-0004CG-Ix
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 09:11:18 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2614::60c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b03b066e-36ec-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 11:11:05 +0200 (CEST)
Received: from DUZPR01CA0325.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:4ba::22) by AS2PR08MB9834.eurprd08.prod.outlook.com
 (2603:10a6:20b:605::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.31; Thu, 22 May
 2025 09:11:01 +0000
Received: from DB1PEPF000509F2.eurprd02.prod.outlook.com
 (2603:10a6:10:4ba:cafe::97) by DUZPR01CA0325.outlook.office365.com
 (2603:10a6:10:4ba::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 22 May 2025 09:11:10 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB1PEPF000509F2.mail.protection.outlook.com (10.167.242.148) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Thu, 22 May 2025 09:11:01 +0000
Received: from AM8PR08MB6578.eurprd08.prod.outlook.com (2603:10a6:20b:36a::15)
 by VE1PR08MB5869.eurprd08.prod.outlook.com (2603:10a6:800:1b2::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 09:10:27 +0000
Received: from AM8PR08MB6578.eurprd08.prod.outlook.com
 ([fe80::bb1a:3ac6:3110:e2d5]) by AM8PR08MB6578.eurprd08.prod.outlook.com
 ([fe80::bb1a:3ac6:3110:e2d5%4]) with mapi id 15.20.8769.019; Thu, 22 May 2025
 09:10: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" 
X-Inumbo-ID: b03b066e-36ec-11f0-b892-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=lnybOmv0iSORAa89D8ZGlMf0rg1/zJ4LCzCJHmgi/nggfQ8sXFckNr50XyzH171eQL3TerkORn6bBcoKHyWpOYG9SmAwEiYMwqmK6BH/+nC/RJ4VRfOnLE1sN5SGJfbj+5iLGGIaaWck8qU7bksgz9YUIRYkVZBcpn2B0U+nlnNGgAlDzCnop9+Gdg30uiYi32CeK+sVDSB2JOwsuzYiEwycnzbQQ3ADaStsgdTD10YNVT2ITrnkvvXqmLe/aHYkseZ7qWL4CMePCBB6LLPeuwZk8irRf46IhntNZsp9kAcCfq2g7+sqKjs+Mmj3uXXpvFmwNL5id4TyR3lWFUVGkg==
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=zSfoxgfeE7cmWfSORHsWrTj6F/8772nmNJ9ZZX5IKzg=;
 b=oFJLVuAJlUnwkQHfoI6KXCbZ+ECOEuU6rLcQ/IrqlaCl5qOsvI8T5GyfhwJkmg+bcb4CdpwqnjHJ0GBkpUu9U5BRBg2/0QoLYhefLsq2GZUtZLNwE0szQNuNWd4gVEOuZ8IKN93zXMtyprGiVr0WqbHS5gzglj12pNwqJFcXMzzhlCAItNoe8UzSy4dJJjgtTXjyLHbyI5dqfYwM93uwi/PKtEda46aa3LgVkZgBIzuqAG+X2NfSeH0LTIziLcNZ79Pa+RssJ8poe0ZCw5SehvVlCutnCJuPeAZgaCths+9N6rC2JHUSOoBh4chWnUQJzUkWs7JkBqNHExMeCiksqg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=linaro.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zSfoxgfeE7cmWfSORHsWrTj6F/8772nmNJ9ZZX5IKzg=;
 b=ourQRQlcXkJdKhALsDP3cjYL3UayPE0wvj7rMHqYzYoxmGBi5CfrZ9pJDQLSEj71BVoRstnMrvKl1UeyY4juIB9d0sQuMuA6TR0T6Zc06Xypso9hA7IETmUyzIZsEGTS93ZBBiGZ/A9jU9zfaDt2Q4HENMlKoKLlRl4fs0j0JHs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=L53BpFxrVs05AGuUaRBPei7wx4+7GgFlSvNre/EHgGnWm30Fk134omBLKRLgYVd8352nm3yznrzeg8/X+5QKr46jc81/G/Xs0O8B6r+8rU0IjGQSwgn4FNvJcQkj575QS36UkIhuab/RLi5MidAXr1Ssfpx3JmmUSt7WKUCl27nALq2tl/lMX/P2MIQsv3H41wcrDEJ7MHXvN7pkp2AFqHTYHgc8mkNfWwwTIOrUUum3kX0g9Nb7SQIz/aP0MyfFITiL7fGaW2qoX4+NI91kXAzd//3h1daFvkByEQ9sdIOJcxC4XIxfHdUiv157hpCpzRNK04Ruc1s2XUOMHPfehg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zSfoxgfeE7cmWfSORHsWrTj6F/8772nmNJ9ZZX5IKzg=;
 b=q4ll1xR6P1LHSD6c7Qm28Jr4xrOHdW0TaDzAdr/xoJ2i3dGYmyrY5EI+Y130dtpjusHNqtPGEs8v3aByelGUwQfBt5AHYBceQe1UgqkoR9OuUBZuYaZ3gglxVjUHnGlpi6VtmPsQrawFTqEb0FdWfaUNOjX6GvgHuUj51MKObaaBz/3cBuEJdEKf3yIQf58ndfi5PdYq9Fjgu4Xj0RFK5p0whgIMYpi33Z60+Iak5OIdFdNUNcbWB9vUjjnSgRktCiwcYRwDgtt4gNbC3axOk6jgj/RpLre04f/zvmFyU6hHOagP7+9GywwFbij2QtVgMZXTG+kWChb3H7QcY6bsCw==
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=zSfoxgfeE7cmWfSORHsWrTj6F/8772nmNJ9ZZX5IKzg=;
 b=ourQRQlcXkJdKhALsDP3cjYL3UayPE0wvj7rMHqYzYoxmGBi5CfrZ9pJDQLSEj71BVoRstnMrvKl1UeyY4juIB9d0sQuMuA6TR0T6Zc06Xypso9hA7IETmUyzIZsEGTS93ZBBiGZ/A9jU9zfaDt2Q4HENMlKoKLlRl4fs0j0JHs=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: "xen-devel@lists.xenproject.org" ,
	Volodymyr Babchuk , Stefano Stabellini
	, Julien Grall , Michal Orzel
	
Subject: Re: [PATCH v5 6/6] xen/arm: ffa: Enable VM to VM without firmware
Thread-Topic: [PATCH v5 6/6] xen/arm: ffa: Enable VM to VM without firmware
Thread-Index: AQHbrqLcLBT6scPDY02nTshBGWfMDLPegcqAgAAE8ICAAAOdgIAACw0A
Date: Thu, 22 May 2025 09:10:26 +0000
Message-ID: <54AE155E-5D83-4C45-B21C-7BB264ADB7E9@arm.com>
References: 
 
 
 
 
In-Reply-To:
 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	AM8PR08MB6578:EE_|VE1PR08MB5869:EE_|DB1PEPF000509F2:EE_|AS2PR08MB9834:EE_
X-MS-Office365-Filtering-Correlation-Id: 75a3a0d4-224a-4b29-b3e6-08dd9910927c
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?N01INVdpZmZDWnFQaldYeWdZK1cwOUthYUduQlByb1ZKSzBjTG44N1g5REM2?=
 =?utf-8?B?Kzl5NWNoR1hScnJHeWtRdVI1czdySGFkeTFzQTgwMS92Sk9LS1pyL0VURXdN?=
 =?utf-8?B?QkR2Y2kxbW9TYlJvMW1RTVN5K2Q0cHFHdE9mNnhabnJhZkdqdGtDZjFNU1hK?=
 =?utf-8?B?RmNZS09KTnBLUXhGLzVNaVZQMXpWcjhycTBucHN2R0tJUG5IRWtWd2ovNXho?=
 =?utf-8?B?UEhHTTZZL21MUG1vL1k4bEwxemQ1aFo1YjNIV1IvMnRjQWFYMXpKZ3ExRnMy?=
 =?utf-8?B?Z0NyaXdDc3VNUU54RG5semhiVlNlN2VBRUgrSUxtSUM2SXg3aXRMYU5sRTZJ?=
 =?utf-8?B?TFZCQlltVURKMGMwdnhyc04xNVY1WG93NGVmN0FlYVA1SlBnMUtLaC95bDNJ?=
 =?utf-8?B?Wkhlcmp0MUphcTdJVkM0Zy9KZ0g0WlJvSTlLRExrSjVqbTVNUk1nd091dW9S?=
 =?utf-8?B?anJCaVFuZTR2UnExTE9sUTN2a3dUb0RpYjdZbGN0L2VkbDROeUp6YnpTWWMr?=
 =?utf-8?B?U3FHdlFlQm5JZXkvS01YQyttTEdwSTF2Y045aEJTdC9tUEg2SE1sYkx3SG4x?=
 =?utf-8?B?RnZSYkZuR3c3NFY1QWVLUm1ueVV2cTFLOGFJUmhwZG1tRHJ2YlNtQmFwREpZ?=
 =?utf-8?B?a25SNWl0dEV0ODI5cFVYL3dteEZnWlh2Y3hGSkZJUHp4USs1d0ZsMFVWWDM5?=
 =?utf-8?B?ZmZLZy92SldGZURpb0Q3WVlZdFdRUDlHODhhamRHWnFsbXMxdXkvaHcvYWNY?=
 =?utf-8?B?RDlFZXRhK1UyTkxYclZvTGt4UzFzbFpVNG9OTndaWEFZbjR2T2paQXNieWND?=
 =?utf-8?B?My85Y2ZHU05oN1duTnd1VWQvT2Z0YkR0anRQQVhnbnJteTZ2T0MydlNnT0pF?=
 =?utf-8?B?WkowMTBTMk81ZVE3MEw5UUVPVU4xbitrdG1SdXdiSVk5SHZsM1I1TXFUREJX?=
 =?utf-8?B?ZklOT21wVnFjOVkyNTlNZjRlWTlxUW1ZL1RRYzFpQ1RSeWczOEdtL1NLNVEx?=
 =?utf-8?B?THZBMm1QcFVGZHUrWWo4eG5QSGFaUmpEZUVCYnlmUFlNeVV6cVFUb2JxRkZy?=
 =?utf-8?B?T1FrVHkzYW0vSkF0MFlwZ0piWDJhckllWGJjQ0grL2tuUnlBNzRyR0xZOHV5?=
 =?utf-8?B?WWVUa1NMZklWK2NRQlZzbS9lMUxZQWFucy9Lc1UvTSsya09JMjlidFlMU29u?=
 =?utf-8?B?S3BDNFA0d2JKWlZScXVOKzk4Y1pCVjZYRjJzN2VOYjRvQXpwdFdOdWl3QWk4?=
 =?utf-8?B?YzhqdnhoU0ZOcUQzMlVqOFhidW56RnA3L2NzenJSbU5SOFp5ZVhzbmpoWEpw?=
 =?utf-8?B?djNVd1pJLytXWDRtUDVrbU81c2UvNE4xRHRRdTlsdkhIeVh3U2VHbm0yS0NY?=
 =?utf-8?B?QkxzTFYrOVpvYm0rZFhmOWtmU3JGNlRBQTRZOGVTRHRlaG93THAzdlhGaDE1?=
 =?utf-8?B?MnIzMEpTa3ZqS0FZNHV6UEtVL25QajRPWUEzc0VGblV0V0xhbVhaZ3ZQaTJX?=
 =?utf-8?B?R2x1b043NmhyRXBEN2x6b1NSUVl0OGgzNEQzRk5KR3l2bHNpR1QyMnJqRFVq?=
 =?utf-8?B?SEN3a2xoZjZDSXRObDl2RFRtRWkxMCt3VERRUFNRVlAvTW90NkxDK21ZWXhs?=
 =?utf-8?B?a3FYdVpnNTVzUWxPbENXemlYUXYrdWJUN215dlBETDhzbFNsYkdhcCtCSEI5?=
 =?utf-8?B?a1RWR1hmUFdkZk15ZVRsT2pYdGU3aThQc2NjUjJ6TWYwUHpIZm8vS0RaVEht?=
 =?utf-8?B?VEx1YnZZQTNuVG9WbksvMktOdlhhYjhMWEMreGhQb0JUbmRXazkwT2NCV01K?=
 =?utf-8?B?a3BsNWs3RTVIbDdZR0dRamxhMUFTQ2lSRW9QMDZTWCsyd2Z5ZzJOSGRTMjdN?=
 =?utf-8?B?dS8yM09YcGZwNHQwOUxEVVNJcnducFdnWEtPeS9ScHVjbGxMYUZIWVhlWllE?=
 =?utf-8?B?ajF2eW56SHlzak1WYnJmMHU1Q2owcW9tclZ5allBL1RIaERZVlJ6K3NydnIz?=
 =?utf-8?Q?5vn4iCavvGg60nzaoc0p1O3qW5IDjU=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM8PR08MB6578.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <27A6ABC44324AA48BFD4BFB9A0C2C1AF@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5869
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF000509F2.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	4a7246ea-9d57-4f46-6162-08dd99107e03
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|14060799003|1800799024|376014|82310400026|35042699022|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?S3NJbnd4RW03M2NMZW1CNVF3YXdWT09FL0lkN2c1VE0vVDhrbk9UVktOM3pt?=
 =?utf-8?B?NG5LZjhnREdvMUVNRTVhd3lCbGtQRFdpckdOeEFYbjJoMVZPZC93MWJ1KzQx?=
 =?utf-8?B?WUZjVHhHK2xJa2N3czI2RkxXNEppU1FNR2pFV2NRREp3K051dmgxeHdnUWpG?=
 =?utf-8?B?YURBRFFnL21tUmJwUzRRMU96NjVnbGQ1MTJMdGRkVFBWWFZWOW5rRm1BWVB0?=
 =?utf-8?B?QUpVTVdTN24rYVo4UWljT3JIZlRyK1RNczZ5NndRcllDamtGajBzU05iRUZt?=
 =?utf-8?B?NkRzUzdYRmVBNlMzK0VhQ01uZGNzbS9nbmwyOUNrQ2NHWVJVR0YwOEVrelVS?=
 =?utf-8?B?OE15UDA3blFWeWFmWUhlRXJWbU5BdHZFN2Z4RFkwRit5UnV4bkRZd29NSVFa?=
 =?utf-8?B?d1FzcXpUa1lrTCtROXU2SVlhd2RrVXA2MmlWTlB4ZWJKbXU4bWNrK2Y4R0Y4?=
 =?utf-8?B?dlUxYW96SkJmS1N0eTU0bHJ1VXM2b1IwWjQxeFJ3Q1c0bUpKLzlTdjhzRHVk?=
 =?utf-8?B?ZTFSNjRpR3QyWnU1MWpYTUhVU3ZqSDZRRUVpaWhIczRlS3REZUVVTFlIWjQ5?=
 =?utf-8?B?aFUrMlNVUUkrTHYrVlpIdnFEbHhBSWRnaG5GY0FzSWNRYVA3RXk4MjJmdDZq?=
 =?utf-8?B?YjZlL3lFV01pMWpDUmw2eVRRckxLRWJNK3BXNDRIclU4d2Y3QTlPWFNTazdI?=
 =?utf-8?B?UjNkd0VmSXhlODdJejRWVXFhL093aHRZNkovMmh6NmJjeW9IUjVJQXF0WlY3?=
 =?utf-8?B?MTd6UHZsV21XVkZMTkUway9vK1NveERpUUtWNjVqYUdiRjczQm5QQkxxYTZJ?=
 =?utf-8?B?Vm1qa2ZEYkpla1E1ZWxoODgzcXF3UXRJZC82UnJENGF4MTJsSFR6Mk1UMkEv?=
 =?utf-8?B?OWRqL1V2a251V0E4TGhJYjRTQ29rVjcrcm9hTjFKdXV4U1paOThKTVpWZFJO?=
 =?utf-8?B?NzM5ZnQ1YTVQL2hEWTJJUzdUWUVrOHJkU2N1eVJic3lGeGl2UVBodzlLekF2?=
 =?utf-8?B?RWRiR0dhaVBzVFdYSzlLS29vTzZPV3ZYK3dUN0E2UDMwLzBCMmdoZndQaTht?=
 =?utf-8?B?Nllvemc0MHJTWjQ0a2JSamJXUXVUMkZ5L3BpZEk3SmluZ0IrNmtxYVJyeFlS?=
 =?utf-8?B?QW5EY1g4dUIzUms1UFd1UlYrUmRMZmlPbFZvVkh4UElhL2xTbU42VVFtZGlW?=
 =?utf-8?B?Q2xNSjVFaSs2QzROMUE4WW12LzRiKzVZbktFdVd3Tmt6cFBuVENaTEFONm5Q?=
 =?utf-8?B?S29UTFFielhZWWdlcWJ6THVUcytwSEIvNytXQjJTL0piU2JEd2VGMGhNSDdV?=
 =?utf-8?B?V1o1eW04NjB4aXhyRTRSdFJpbGhPN3dZUVlmUTVENUlUNUdvN1N2V0FDcWdM?=
 =?utf-8?B?V2NuS0VEVXJPUVplUVJPdkR6T1JWS0JoK3lqK3VYd2ZvZzRGTXdjRElPejgx?=
 =?utf-8?B?TFNmR0k5ZDROak50UmNwRTJsRkRqbWI3VStuREx0MHc1RUovbHVzMXRKYXdt?=
 =?utf-8?B?eUxxYzdXTHQ0UDlnZ0hzd2dFUU5ITFQ2aVplVHh0UHFGZTRTVWl6Q2ZHYjJQ?=
 =?utf-8?B?UUlHK2M3YU9oQmR3Mkp4VTRwZjdmUWxqdVVIdG5ndE5DMVUxVm14YTFTTUtF?=
 =?utf-8?B?czJZR2tGUjAvbldqRzh4V05UVTdMUEpscEhiazYwTHdOUXlNRnFvSEo4aTg0?=
 =?utf-8?B?aVlqRWFwL1BnSkdwQW4rUnR0RjhuaUN4MGp3OSt4RFV6b3FMcWoyRFBTZFVi?=
 =?utf-8?B?NWZLZmpobVFoV3Y0VTNCVVhKU2VtZzdYb2ZWUlR3V05lSS9tSWxacXF0MUNC?=
 =?utf-8?B?NG90K2Q2SW9qbzNRWTJvdnNlejNLYWdiTUR2SkVEYTRtZmFncjNoa0dlME1h?=
 =?utf-8?B?SG81MkxhYVU2UEsyS281ek5HVnJiRUFyc2Y2N08wQjhaRUZ6WGZoMGdpMGgw?=
 =?utf-8?B?TjBKbmJhSDRBemNqaUNydFRPMktiR1J2YkQyU25ublM2ZmhvdW1rTXRJaGc4?=
 =?utf-8?B?akppNWs1SEw5bUMvcGVYZXdWL1kyVDZOQXVKQ0lBQUxHUWlGQVBOemNGdWpX?=
 =?utf-8?Q?BquGeg?=
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)(36860700013)(14060799003)(1800799024)(376014)(82310400026)(35042699022)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 09:11:01.1479
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 75a3a0d4-224a-4b29-b3e6-08dd9910927c
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:
	DB1PEPF000509F2.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9834

SGkgSmVucywNCg0KPiBPbiAyMiBNYXkgMjAyNSwgYXQgMTA6MzAsIEplbnMgV2lrbGFuZGVyIDxq
ZW5zLndpa2xhbmRlckBsaW5hcm8ub3JnPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gT24gVGh1
LCBNYXkgMjIsIDIwMjUgYXQgMTA6MTjigK9BTSBCZXJ0cmFuZCBNYXJxdWlzDQo+IDxCZXJ0cmFu
ZC5NYXJxdWlzQGFybS5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBKZW5zLA0KPj4gDQo+Pj4gT24g
MjIgTWF5IDIwMjUsIGF0IDEwOjAwLCBKZW5zIFdpa2xhbmRlciA8amVucy53aWtsYW5kZXJAbGlu
YXJvLm9yZz4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkgQmVydHJhbmQsDQo+Pj4gDQo+Pj4gT24gV2Vk
LCBBcHIgMTYsIDIwMjUgYXQgOTo0MOKAr0FNIEJlcnRyYW5kIE1hcnF1aXMNCj4+PiA8YmVydHJh
bmQubWFycXVpc0Bhcm0uY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IFdoZW4gVk0gdG8gVk0gc3Vw
cG9ydCBpcyBhY3RpdmF0ZWQgYW5kIHRoZXJlIGlzIG5vIHN1aXRhYmxlIEZGLUEgc3VwcG9ydA0K
Pj4+PiBpbiB0aGUgZmlybXdhcmUsIGVuYWJsZSBGRi1BIHN1cHBvcnQgZm9yIFZNcyB0byBhbGxv
dyB1c2luZyBpdCBmb3IgVk0gdG8NCj4+Pj4gVk0gY29tbXVuaWNhdGlvbnMuDQo+Pj4+IElmIHRo
ZXJlIGlzIE9QLVRFRSBydW5uaW5nIGluIHRoZSBzZWN1cmUgd29ybGQgYW5kIHVzaW5nIHRoZSBu
b24gRkYtQQ0KPj4+PiBjb21tdW5pY2F0aW9uIHN5c3RlbSwgaGF2aW5nIENPTkZJR19GRkFfVk1f
VE9fVk0gY291bGQgYmUgbm9uIGZ1bmN0aW9uYWwNCj4+Pj4gKGlmIG9wdGVlIGlzIHByb2JlZCBm
aXJzdCkgb3IgT1AtVEVFIGNvdWxkIGJlIG5vbiBmdW5jdGlvbmFsIChpZiBGRi1BIGlzDQo+Pj4+
IHByb2JlZCBmaXJzdCkgc28gaXQgaXMgbm90IHJlY29tbWVuZGVkIHRvIGFjdGl2YXRlIHRoZSBj
b25maWd1cmF0aW9uDQo+Pj4+IG9wdGlvbiBmb3Igc3VjaCBzeXN0ZW1zLg0KPj4+PiANCj4+Pj4g
VG8gbWFrZSBidWZmZXIgZnVsbCBub3RpZmljYXRpb24gd29yayBiZXR3ZWVuIFZNcyB3aGVuIHRo
ZXJlIGlzIG5vDQo+Pj4+IGZpcm13YXJlLCByZXdvcmsgdGhlIG5vdGlmaWNhdGlvbiBoYW5kbGlu
ZyBhbmQgbW9kaWZ5IHRoZSBnbG9iYWwgZmxhZyB0bw0KPj4+PiBvbmx5IGJlIHVzZWQgYXMgY2hl
Y2sgZm9yIGZpcm13YXJlIG5vdGlmaWNhdGlvbiBzdXBwb3J0IGluc3RlYWQuDQo+Pj4+IA0KPj4+
PiBTaWduZWQtb2ZmLWJ5OiBCZXJ0cmFuZCBNYXJxdWlzIDxiZXJ0cmFuZC5tYXJxdWlzQGFybS5j
b20+DQo+Pj4+IC0tLQ0KPj4+PiBDaGFuZ2VzIGluIHY1Og0KPj4+PiAtIGluaXQgY3R4IGxpc3Qg
d2hlbiB0aGVyZSBpcyBubyBmaXJtd2FyZQ0KPj4+PiAtIHJld29yayBpbml0IGEgYml0IHRvIHBy
ZXZlbnQgZHVwbGljYXRlcw0KPj4+PiAtIFJlbW92ZSBKZW5zIFItYiBkdWUgdG8gY2hhbmdlcyBk
b25lDQo+Pj4+IENoYW5nZXMgaW4gdjQ6DQo+Pj4+IC0gRml4IE9wdGVlIHRvIE9QLVRFRSBpbiBj
b21taXQgbWVzc2FnZQ0KPj4+PiAtIEFkZCBKZW5zIFItYg0KPj4+PiBDaGFuZ2VzIGluIHYzOg0K
Pj4+PiAtIGZpeCB0eXBvcyBpbiBjb21taXQgbWVzc2FnZQ0KPj4+PiAtIGFkZCBzcGFjZXMgYXJv
dW5kIDw8DQo+Pj4+IC0gbW92ZSBub3RpZmljYXRpb24gaWQgZml4IGJhY2sgaW50byBidWZmZXIg
ZnVsbCBwYXRjaA0KPj4+PiAtIGZpeCB8IHBvc2l0aW9uIGluIGlmDQo+Pj4+IENoYW5nZXMgaW4g
djI6DQo+Pj4+IC0gcmVwbGFjZSBpZmRlZiB3aXRoIElTX0VOQUJMRUQgd2hlbiBwb3NzaWJsZQ0K
Pj4+PiAtLS0NCj4+Pj4geGVuL2FyY2gvYXJtL3RlZS9mZmEuYyAgICAgICB8ICAyNCArKysrKyst
LQ0KPj4+PiB4ZW4vYXJjaC9hcm0vdGVlL2ZmYV9ub3RpZi5jIHwgMTA0ICsrKysrKysrKysrKysr
KystLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IDIgZmlsZXMgY2hhbmdlZCwgNjcgaW5zZXJ0aW9u
cygrKSwgNjEgZGVsZXRpb25zKC0pDQo+Pj4+IA0KPj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
YXJtL3RlZS9mZmEuYyBiL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+Pj4gaW5kZXggYzFjNGMw
OTU3MDkxLi5iODZjODhjZWZhOGMgMTAwNjQ0DQo+Pj4+IC0tLSBhL3hlbi9hcmNoL2FybS90ZWUv
ZmZhLmMNCj4+Pj4gKysrIGIveGVuL2FyY2gvYXJtL3RlZS9mZmEuYw0KPj4+PiBAQCAtMzQyLDgg
KzM0Miw5IEBAIHN0YXRpYyBpbnQgZmZhX2RvbWFpbl9pbml0KHN0cnVjdCBkb21haW4gKmQpDQo+
Pj4+ICAgIHN0cnVjdCBmZmFfY3R4ICpjdHg7DQo+Pj4+ICAgIGludCByZXQ7DQo+Pj4+IA0KPj4+
PiAtICAgIGlmICggIWZmYV9md192ZXJzaW9uICkNCj4+Pj4gKyAgICBpZiAoICFJU19FTkFCTEVE
KENPTkZJR19GRkFfVk1fVE9fVk0pICYmICFmZmFfZndfdmVyc2lvbiApDQo+Pj4+ICAgICAgICBy
ZXR1cm4gLUVOT0RFVjsNCj4+Pj4gKw0KPj4+PiAgICAvKg0KPj4+PiAgICAgKiBXZSBhcmUgdXNp
bmcgdGhlIGRvbWFpbl9pZCArIDEgYXMgdGhlIEZGLUEgSUQgZm9yIFZNcyBhcyBGRi1BIElEIDAg
aXMNCj4+Pj4gICAgICogcmVzZXJ2ZWQgZm9yIHRoZSBoeXBlcnZpc29yIGFuZCB3ZSBvbmx5IHN1
cHBvcnQgc2VjdXJlIGVuZHBvaW50cyB1c2luZw0KPj4+PiBAQCAtNTc5LDExICs1ODAsOCBAQCBz
dGF0aWMgYm9vbCBmZmFfcHJvYmUodm9pZCkNCj4+Pj4gICAgICAgIGdvdG8gZXJyX3J4dHhfZGVz
dHJveTsNCj4+Pj4gDQo+Pj4+ICAgIGZmYV9ub3RpZl9pbml0KCk7DQo+Pj4+IC0gICAgSU5JVF9M
SVNUX0hFQUQoJmZmYV90ZWFyZG93bl9oZWFkKTsNCj4+Pj4gLSAgICBJTklUX0xJU1RfSEVBRCgm
ZmZhX2N0eF9oZWFkKTsNCj4+Pj4gLSAgICBpbml0X3RpbWVyKCZmZmFfdGVhcmRvd25fdGltZXIs
IGZmYV90ZWFyZG93bl90aW1lcl9jYWxsYmFjaywgTlVMTCwgMCk7DQo+Pj4+IA0KPj4+PiAtICAg
IHJldHVybiB0cnVlOw0KPj4+PiArICAgIGdvdG8gZXhpdDsNCj4+Pj4gDQo+Pj4+IGVycl9yeHR4
X2Rlc3Ryb3k6DQo+Pj4+ICAgIGZmYV9yeHR4X2Rlc3Ryb3koKTsNCj4+Pj4gQEAgLTU5Miw2ICs1
OTAsMjIgQEAgZXJyX25vX2Z3Og0KPj4+PiAgICBiaXRtYXBfemVybyhmZmFfZndfYWJpX3N1cHBv
cnRlZCwgRkZBX0FCSV9CSVRNQVBfU0laRSk7DQo+Pj4+ICAgIHByaW50ayhYRU5MT0dfV0FSTklO
RyAiQVJNIEZGLUEgTm8gZmlybXdhcmUgc3VwcG9ydFxuIik7DQo+Pj4+IA0KPj4+PiArZXhpdDoN
Cj4+Pj4gKyAgICBpZiAoIElTX0VOQUJMRUQoQ09ORklHX0ZGQV9WTV9UT19WTSkgfHwgZmZhX2Z3
X3ZlcnNpb24gKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgSU5JVF9MSVNUX0hFQUQoJmZm
YV90ZWFyZG93bl9oZWFkKTsNCj4+Pj4gKyAgICAgICAgSU5JVF9MSVNUX0hFQUQoJmZmYV9jdHhf
aGVhZCk7DQo+Pj4+ICsgICAgICAgIGluaXRfdGltZXIoJmZmYV90ZWFyZG93bl90aW1lciwgZmZh
X3RlYXJkb3duX3RpbWVyX2NhbGxiYWNrLCBOVUxMLCAwKTsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsN
Cj4+Pj4gKyAgICBpZiAoIElTX0VOQUJMRUQoQ09ORklHX0ZGQV9WTV9UT19WTSkgKQ0KPj4+PiAr
ICAgIHsNCj4+Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19JTkZPICJBUk0gRkYtQSBvbmx5IGF2
YWlsYWJsZSBiZXR3ZWVuIFZNc1xuIik7DQo+Pj4gDQo+Pj4gVGhpcyBzaG91bGQgb25seSBiZSBw
cmludGVkIGlmIGZmYV9md192ZXJzaW9uID09IDANCj4+IA0KPj4gUmlnaHQgaSB3aWxsIGZpeCBi
dXQgLi4uDQo+PiANCj4+PiANCj4+Pj4gKyAgICAgICAgcmV0dXJuIHRydWU7DQo+Pj4+ICsgICAg
fQ0KPj4+PiArICAgIGVsc2UgaWYgKCBmZmFfZndfdmVyc2lvbiApDQo+Pj4gDQo+Pj4gVGhlIGVs
c2UgaXNuJ3QgbmVlZGVkLg0KPj4gDQo+PiB0aGUgZWxzZSBpcyBuZWVkZWQgc28gdGhhdCB3ZSBy
ZXR1cm4gdHJ1ZSBhbmQgbm90IGZhbHNlLg0KPiANCj4gSSBtZWFudCB0aGUgImVsc2UiIGlzbid0
IG5lZWRlZCwgdGhlICJpZiIgaXMgc3RpbGwgbmVlZGVkLCBhcyB5b3UgZXhwbGFpbi4NCj4gDQo+
PiANCj4+IFdlIGhhdmUgMyBjYXNlczoNCj4+IC0gZmlybXdhcmUgaXMgdGhlcmU6IHJldHVybiB0
cnVlDQo+PiAtIGZpcm13YXJlIG5vdCB0aGVyZSBidXQgdm0gdG8gdm0gZW5hYmxlOiByZXR1cm4g
dHJ1ZQ0KPj4gLSBvdGhlcndpc2U6IHJldHVybiBmYWxzZQ0KPj4gDQo+PiBJIHdpbGwgbW9kaWZ5
IGl0IGxpa2UgdGhpcyB0byBtYWtlIGl0IGNsZWFyZXI6DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gvYXJtL3RlZS9mZmEuYyBiL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+IGluZGV4IDU3YjY0
OGEyMjg0MC4uNzY4YjRlOWVjOTY4IDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL3RlZS9m
ZmEuYw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL3RlZS9mZmEuYw0KPj4gQEAgLTYwMSwxMyArNjAx
LDEzIEBAIGV4aXQ6DQo+PiAgICAgICAgIGluaXRfdGltZXIoJmZmYV90ZWFyZG93bl90aW1lciwg
ZmZhX3RlYXJkb3duX3RpbWVyX2NhbGxiYWNrLCBOVUxMLCAwKTsNCj4+ICAgICB9DQo+PiANCj4+
IC0gICAgaWYgKCBJU19FTkFCTEVEKENPTkZJR19GRkFfVk1fVE9fVk0pICkNCj4+ICsgICAgaWYg
KCBmZmFfZndfdmVyc2lvbiApDQo+PiArICAgICAgICByZXR1cm4gdHJ1ZTsNCj4+ICsgICAgZWxz
ZSBpZiAoIElTX0VOQUJMRUQoQ09ORklHX0ZGQV9WTV9UT19WTSkgKQ0KPj4gICAgIHsNCj4+ICAg
ICAgICAgcHJpbnRrKFhFTkxPR19JTkZPICJBUk0gRkYtQSBvbmx5IGF2YWlsYWJsZSBiZXR3ZWVu
IFZNc1xuIik7DQo+PiAgICAgICAgIHJldHVybiB0cnVlOw0KPj4gICAgIH0NCj4+IC0gICAgZWxz
ZSBpZiAoIGZmYV9md192ZXJzaW9uICkNCj4+IC0gICAgICAgIHJldHVybiB0cnVlOw0KPj4gDQo+
PiAgICAgcmV0dXJuIGZhbHNlOw0KPj4gfQ0KPj4gDQo+PiBUZWxsIG1lIGlmIHlvdSBhZ3JlZS4N
Cj4gDQo+IFllcywgdGhpcyBpcyBhbiBpbXByb3ZlbWVudC4gQSByZXR1cm4gYXQgdGhlIGVuZCBv
ZiBhbiBpZiBibG9jayBtYWtlcw0KPiB0aGUgZXZlbnR1YWwgZm9sbG93aW5nICJlbHNlIiByZWR1
bmRhbnQuIEkgc3VwcG9zZSB0aGVyZSBhcmUgY29kaW5nDQo+IHN0eWxlcyB3aGVyZSBpdCdzIHN0
aWxsIHByZWZlcnJlZC4gSSdtIG5vdCBzdXJlIGlmIHRoYXQgYXBwbGllcyBpbg0KPiBYZW4sIHRo
b3VnaC4NCg0KSSBub3cgZ2V0IHdoYXQgeW91IG1lYW4gYW5kIHlvdSB3b3VsZCBsaWtlIHRoZSBy
ZXR1cm4gZmFsc2UgdG8gYmUgaW4gYSBlbHNlLg0KDQpSZWxvb2tpbmcgYXQgdGhlIGNvZGUsIGkg
YWN0dWFsbHkgZG8gbm90IGxpa2UgdGhlIGZhY3QgdGhhdCB3ZSBkbyBzbyBtdWNoIGluDQpleGl0
IGFuZCBpIHRoaW5rIGkgY2FuIG1vdmUgYSBiaXQgdGhlIGNvZGUgdG8gYmUgY2xlYXJlcjoNCi0g
cHV0IHRoZSBmdyBpbml0IGluIGEgc3ViIGZ1bmN0aW9uDQotIGNyZWF0ZSBhIHZtX3RvX3ZtIGlu
aXQgZnVuY3Rpb24NCi0gaW4gcHJvYmUgY2FsbCBib3RoIGZ1bmN0aW9ucyBhbmQgZG8gdGhlIGNv
bW1vbiBpbml0IHBhcnQgaWYgYXQgbGVhc3Qgb25lIHN1Y2NlZGVkDQoNClNvbWV0aGluZyBsaWtl
IHRoaXM6DQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3RlZS9mZmEuYyBiL3hlbi9hcmNoL2Fy
bS90ZWUvZmZhLmMNCmluZGV4IDU3YjY0OGEyMjg0MC4uNDJkZmM3MWExMmQ3IDEwMDY0NA0KLS0t
IGEveGVuL2FyY2gvYXJtL3RlZS9mZmEuYw0KKysrIGIveGVuL2FyY2gvYXJtL3RlZS9mZmEuYw0K
QEAgLTQ3OCwzOCArNDc4LDEyIEBAIHN0YXRpYyB2b2lkIGZmYV9pbml0X3NlY29uZGFyeSh2b2lk
KQ0KICAgICBmZmFfbm90aWZfaW5pdF9pbnRlcnJ1cHQoKTsNCiB9DQoNCi1zdGF0aWMgYm9vbCBm
ZmFfcHJvYmUodm9pZCkNCitzdGF0aWMgYm9vbCBmZmFfcHJvYmVfZncodm9pZCkNCiB7DQogICAg
IHVpbnQzMl90IHZlcnM7DQogICAgIHVuc2lnbmVkIGludCBtYWpvcl92ZXJzOw0KICAgICB1bnNp
Z25lZCBpbnQgbWlub3JfdmVyczsNCg0KLSAgICAvKg0KLSAgICAgKiBGRi1BIG9mdGVuIHdvcmtz
IGluIHVuaXRzIG9mIDRLIHBhZ2VzIGFuZCBjdXJyZW50bHkgaXQncyBhc3N1bWVkDQotICAgICAq
IHRoYXQgd2UgY2FuIG1hcCBtZW1vcnkgdXNpbmcgdGhhdCBncmFudWxhcml0eS4gU2VlIGFsc28g
dGhlIGNvbW1lbnQNCi0gICAgICogYWJvdmUgdGhlIEZGQV9QQUdFX1NJWkUgZGVmaW5lLg0KLSAg
ICAgKg0KLSAgICAgKiBJdCBpcyBwb3NzaWJsZSB0byBzdXBwb3J0IGEgUEFHRV9TSVpFIGxhcmdl
ciB0aGFuIDRLIGluIFhlbiwgYnV0DQotICAgICAqIHVudGlsIHRoYXQgaXMgZnVsbHkgaGFuZGxl
ZCBpbiB0aGlzIGNvZGUgbWFrZSBzdXJlIHRoYXQgd2Ugb25seSB1c2UNCi0gICAgICogNEsgcGFn
ZSBzaXplcy4NCi0gICAgICovDQotICAgIEJVSUxEX0JVR19PTihQQUdFX1NJWkUgIT0gRkZBX1BB
R0VfU0laRSk7DQotDQotICAgIHByaW50ayhYRU5MT0dfSU5GTyAiQVJNIEZGLUEgTWVkaWF0b3Ig
dmVyc2lvbiAldS4ldVxuIiwNCi0gICAgICAgICAgIEZGQV9NWV9WRVJTSU9OX01BSk9SLCBGRkFf
TVlfVkVSU0lPTl9NSU5PUik7DQotDQotICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfRkZBX1ZN
X1RPX1ZNKSApDQotICAgIHsNCi0gICAgICAgIC8qDQotICAgICAgICAgKiBXaGVuIEZGQSBWTSB0
byBWTSBpcyBlbmFibGVkLCB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdA0KLSAg
ICAgICAgICogb2ZmZXIgYW55IHdheSB0byBsaW1pdCB3aGljaCBWTSBjYW4gY29tbXVuaWNhdGUg
d2l0aCB3aGljaCBWTSB1c2luZw0KLSAgICAgICAgICogRkYtQS4NCi0gICAgICAgICAqIFNpZ25h
bCB0aGlzIGluIHRoZSB4ZW4gY29uc29sZSBhbmQgdGFpbnQgdGhlIHN5c3RlbSBhcyBpbnNlY3Vy
ZS4NCi0gICAgICAgICAqIFRPRE86IEludHJvZHVjZSBhIHNvbHV0aW9uIHRvIGxpbWl0IHdoYXQg
YSBWTSBjYW4gZG8gdGhyb3VnaCBGRkEuDQotICAgICAgICAgKi8NCi0gICAgICAgIHByaW50ayhY
RU5MT0dfRVJSICJmZmE6IFZNIHRvIFZNIGlzIGVuYWJsZWQsIHN5c3RlbSBpcyBpbnNlY3VyZSAh
IVxuIik7DQotICAgICAgICBhZGRfdGFpbnQoVEFJTlRfTUFDSElORV9JTlNFQ1VSRSk7DQotICAg
IH0NCiAgICAgLyoNCiAgICAgICogcHNjaV9pbml0X3NtY2NjKCkgdXBkYXRlcyB0aGlzIHZhbHVl
IHdpdGggd2hhdCdzIHJlcG9ydGVkIGJ5IEVMLTMNCiAgICAgICogb3Igc2VjdXJlIHdvcmxkLg0K
QEAgLTUyOCwxMSArNTAyLDYgQEAgc3RhdGljIGJvb2wgZmZhX3Byb2JlKHZvaWQpDQogICAgICAg
ICBnb3RvIGVycl9ub19mdzsNCiAgICAgfQ0KDQotICAgIC8qIFNvbWUgc2FuaXR5IGNoZWNrIGlu
IGNhc2Ugd2UgdXBkYXRlIHRoZSB2ZXJzaW9uIHdlIHN1cHBvcnQgKi8NCi0gICAgQlVJTERfQlVH
X09OKEZGQV9NSU5fU1BNQ19WRVJTSU9OID4gRkZBX01ZX1ZFUlNJT04pOw0KLSAgICBCVUlMRF9C
VUdfT04oRkZBX1ZFUlNJT05fTUFKT1IoRkZBX01JTl9TUE1DX1ZFUlNJT04pICE9DQotICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGRkFfTVlfVkVSU0lPTl9NQUpPUik7DQotDQog
ICAgIG1ham9yX3ZlcnMgPSBGRkFfVkVSU0lPTl9NQUpPUih2ZXJzKTsNCiAgICAgbWlub3JfdmVy
cyA9IEZGQV9WRVJTSU9OX01JTk9SKHZlcnMpOw0KDQpAQCAtNTg0LDcgKzU1Myw3IEBAIHN0YXRp
YyBib29sIGZmYV9wcm9iZSh2b2lkKQ0KDQogICAgIGZmYV9ub3RpZl9pbml0KCk7DQoNCi0gICAg
Z290byBleGl0Ow0KKyAgICByZXR1cm4gdHJ1ZTsNCg0KIGVycl9yeHR4X2Rlc3Ryb3k6DQogICAg
IGZmYV9yeHR4X2Rlc3Ryb3koKTsNCkBAIC01OTMsMjMgKzU2Miw1OSBAQCBlcnJfbm9fZnc6DQog
ICAgIGJpdG1hcF96ZXJvKGZmYV9md19hYmlfc3VwcG9ydGVkLCBGRkFfQUJJX0JJVE1BUF9TSVpF
KTsNCiAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJBUk0gRkYtQSBObyBmaXJtd2FyZSBzdXBw
b3J0XG4iKTsNCg0KLWV4aXQ6DQotICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfRkZBX1ZNX1RP
X1ZNKSB8fCBmZmFfZndfdmVyc2lvbiApDQotICAgIHsNCi0gICAgICAgIElOSVRfTElTVF9IRUFE
KCZmZmFfdGVhcmRvd25faGVhZCk7DQotICAgICAgICBJTklUX0xJU1RfSEVBRCgmZmZhX2N0eF9o
ZWFkKTsNCi0gICAgICAgIGluaXRfdGltZXIoJmZmYV90ZWFyZG93bl90aW1lciwgZmZhX3RlYXJk
b3duX3RpbWVyX2NhbGxiYWNrLCBOVUxMLCAwKTsNCi0gICAgfQ0KKyAgICByZXR1cm4gZmFsc2U7
DQorfQ0KDQotICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfRkZBX1ZNX1RPX1ZNKSApDQotICAg
IHsNCitzdGF0aWMgYm9vbCBmZmFfcHJvYmVfdm1fdG9fdm0odm9pZCkNCit7DQorICAgIGlmICgg
IUlTX0VOQUJMRUQoQ09ORklHX0ZGQV9WTV9UT19WTSkgKQ0KKyAgICAgICAgcmV0dXJuIGZhbHNl
Ow0KKw0KKyAgICAvKg0KKyAgICAgKiBXaGVuIEZGQSBWTSB0byBWTSBpcyBlbmFibGVkLCB0aGUg
Y3VycmVudCBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdA0KKyAgICAgKiBvZmZlciBhbnkgd2F5IHRv
IGxpbWl0IHdoaWNoIFZNIGNhbiBjb21tdW5pY2F0ZSB3aXRoIHdoaWNoIFZNIHVzaW5nDQorICAg
ICAqIEZGLUEuDQorICAgICAqIFNpZ25hbCB0aGlzIGluIHRoZSB4ZW4gY29uc29sZSBhbmQgdGFp
bnQgdGhlIHN5c3RlbSBhcyBpbnNlY3VyZS4NCisgICAgICogVE9ETzogSW50cm9kdWNlIGEgc29s
dXRpb24gdG8gbGltaXQgd2hhdCBhIFZNIGNhbiBkbyB0aHJvdWdoIEZGQS4NCisgICAgICovDQor
ICAgIHByaW50ayhYRU5MT0dfRVJSICJmZmE6IFZNIHRvIFZNIGlzIGVuYWJsZWQsIHN5c3RlbSBp
cyBpbnNlY3VyZSAhIVxuIik7DQorICAgIGFkZF90YWludChUQUlOVF9NQUNISU5FX0lOU0VDVVJF
KTsNCisNCisgICAgcmV0dXJuIHRydWU7DQorfQ0KKw0KK3N0YXRpYyBib29sIGZmYV9wcm9iZSh2
b2lkKQ0KK3sNCisgICAgLyoNCisgICAgICogRkYtQSBvZnRlbiB3b3JrcyBpbiB1bml0cyBvZiA0
SyBwYWdlcyBhbmQgY3VycmVudGx5IGl0J3MgYXNzdW1lZA0KKyAgICAgKiB0aGF0IHdlIGNhbiBt
YXAgbWVtb3J5IHVzaW5nIHRoYXQgZ3JhbnVsYXJpdHkuIFNlZSBhbHNvIHRoZSBjb21tZW50DQor
ICAgICAqIGFib3ZlIHRoZSBGRkFfUEFHRV9TSVpFIGRlZmluZS4NCisgICAgICoNCisgICAgICog
SXQgaXMgcG9zc2libGUgdG8gc3VwcG9ydCBhIFBBR0VfU0laRSBsYXJnZXIgdGhhbiA0SyBpbiBY
ZW4sIGJ1dA0KKyAgICAgKiB1bnRpbCB0aGF0IGlzIGZ1bGx5IGhhbmRsZWQgaW4gdGhpcyBjb2Rl
IG1ha2Ugc3VyZSB0aGF0IHdlIG9ubHkgdXNlDQorICAgICAqIDRLIHBhZ2Ugc2l6ZXMuDQorICAg
ICAqLw0KKyAgICBCVUlMRF9CVUdfT04oUEFHRV9TSVpFICE9IEZGQV9QQUdFX1NJWkUpOw0KKw0K
KyAgICAvKiBTb21lIHNhbml0eSBjaGVjayBpbiBjYXNlIHdlIHVwZGF0ZSB0aGUgdmVyc2lvbiB3
ZSBzdXBwb3J0ICovDQorICAgIEJVSUxEX0JVR19PTihGRkFfTUlOX1NQTUNfVkVSU0lPTiA+IEZG
QV9NWV9WRVJTSU9OKTsNCisgICAgQlVJTERfQlVHX09OKEZGQV9WRVJTSU9OX01BSk9SKEZGQV9N
SU5fU1BNQ19WRVJTSU9OKSAhPQ0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
RkZBX01ZX1ZFUlNJT05fTUFKT1IpOw0KKw0KKyAgICBwcmludGsoWEVOTE9HX0lORk8gIkFSTSBG
Ri1BIE1lZGlhdG9yIHZlcnNpb24gJXUuJXVcbiIsDQorICAgICAgICAgICBGRkFfTVlfVkVSU0lP
Tl9NQUpPUiwgRkZBX01ZX1ZFUlNJT05fTUlOT1IpOw0KKw0KKyAgICBpZiAoICFmZmFfcHJvYmVf
ZncoKSAmJiAhZmZhX3Byb2JlX3ZtX3RvX3ZtKCkgKQ0KKyAgICAgICAgcmV0dXJuIGZhbHNlOw0K
Kw0KKyAgICBpZiAoICFmZmFfZndfdmVyc2lvbiApDQogICAgICAgICBwcmludGsoWEVOTE9HX0lO
Rk8gIkFSTSBGRi1BIG9ubHkgYXZhaWxhYmxlIGJldHdlZW4gVk1zXG4iKTsNCi0gICAgICAgIHJl
dHVybiB0cnVlOw0KLSAgICB9DQotICAgIGVsc2UgaWYgKCBmZmFfZndfdmVyc2lvbiApDQotICAg
ICAgICByZXR1cm4gdHJ1ZTsNCg0KLSAgICByZXR1cm4gZmFsc2U7DQorICAgIElOSVRfTElTVF9I
RUFEKCZmZmFfdGVhcmRvd25faGVhZCk7DQorICAgIElOSVRfTElTVF9IRUFEKCZmZmFfY3R4X2hl
YWQpOw0KKyAgICBpbml0X3RpbWVyKCZmZmFfdGVhcmRvd25fdGltZXIsIGZmYV90ZWFyZG93bl90
aW1lcl9jYWxsYmFjaywgTlVMTCwgMCk7DQorDQorICAgIHJldHVybiB0cnVlOw0KIH0NCg0KIHN0
YXRpYyBjb25zdCBzdHJ1Y3QgdGVlX21lZGlhdG9yX29wcyBmZmFfb3BzID0NCg0KSSB0aGluayB0
aGlzIG1ha2VzIHRoZSBjb2RlIGNsZWFuZXIgYXMgd2UgYWxzbyBnZXQgdGhlIHByb3BlciBlcnJv
ciBoYW5kbGluZyB3aXRoIGdvdG8NCmluc2lkZSB0aGUgZncgcHJvYmUgaW5zdGVhZCBvZiB0aGUg
cHJldmlvdXMgb25lIHdoaWNoIHdhcyB0cnlpbmcgdG8gaGFuZGxlIGJvdGggY2FzZXMuDQoNCldo
YXQgZG8geW91IHRoaW5rID8NCg0KQ2hlZXJzDQpCZXJ0cmFuZA0KDQoNCg0K


From xen-devel-bounces@lists.xenproject.org Thu May 22 09:11:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 09:11:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993331.1376753 (Exim 4.92)
	(envelope-from )
	id 1uI1xb-0004qN-Te; Thu, 22 May 2025 09:11:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993331.1376753; Thu, 22 May 2025 09:11: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 1uI1xb-0004qG-Qw; Thu, 22 May 2025 09:11:31 +0000
Received: by outflank-mailman (input) for mailman id 993331;
 Thu, 22 May 2025 09:11:30 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI1xa-0004CG-Eh
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 09:11:30 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bd605087-36ec-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 11:11:27 +0200 (CEST)
Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com
 [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-538-bTkOZMoaNP6jvjmYRUQrxQ-1; Thu, 22 May 2025 05:11:24 -0400
Received: by mail-wm1-f69.google.com with SMTP id
 5b1f17b1804b1-43ea256f039so60909935e9.0
 for ; Thu, 22 May 2025 02:11:24 -0700 (PDT)
Received: from ?IPV6:2a0d:3344:247a:1010::f39? ([2a0d:3344:247a:1010::f39])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f6f05581sm97329145e9.13.2025.05.22.02.11.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 02:11: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" 
X-Inumbo-ID: bd605087-36ec-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1747905086;
	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=Efw/xOoBR5JtsAGWTbkGb39F5QrJRSJy0Aiy1rPkylA=;
	b=ISOQZg9Ku2Jm3YWSfGM5qZjGumLJ4SlE/J1M0ERPml0wEXoHSDffyuORHMuNHd3fgsFy3j
	GHcRPRJlB1XQ+MPaOYVCzsVRsCcSHdFtOl7Tk23Twsi3XSQGlvv9p3qheiME65JzJ8Tv8R
	XmbXDGsRw5GhMIiSpMrvDuDrUS61PsU=
X-MC-Unique: bTkOZMoaNP6jvjmYRUQrxQ-1
X-Mimecast-MFC-AGG-ID: bTkOZMoaNP6jvjmYRUQrxQ_1747905084
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747905083; x=1748509883;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Efw/xOoBR5JtsAGWTbkGb39F5QrJRSJy0Aiy1rPkylA=;
        b=rBbPFp35WwcajZHtIF3BmOlaWJkC2Ry2LLMbvsQ/4TBvkPNfdDc5G305h2yAXx7wgC
         8AWM5XAPj6XTQXUOWn60qTIhunAIGUWDfcZeC1konxGSYVXVusjw0k7097SYAQPB9564
         yOy9E0PhyfiRFQDSrg4b+kgGrsep/vGuiVASFbDlyBHqNu5xAFdBeAFhGhncsj1+BxsY
         AajOGAGKx9o/QanA58yp9a0oNqCKXQP857ykgG1Bpt5HGlEiYNUTNZRDzZIBZTTrClxV
         uYqN7Jf/OmyMDGAoGV2DLqkKpbfYVzKKDKF7FKK1fVXBVbJt56r7nXEY3QKYKNykayzV
         E2MA==
X-Forwarded-Encrypted: i=1; AJvYcCW9uYet3Gn5qIdjsHHKbN7jEll+iYPn11xju9kzrqKrNpTsfeDDgp3lsH+6ES6nTK+ctlAA6GCplg4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYZ/xu+xeW0d3WaPXUmNOSG20qvG97Z6kO03LFA0vgMVdYJ3Jr
	0T2C7nUoHTAvjRipZ8yTxH2O3SsxU46T0uZe52HBpywDA9eHhY4hSag25HVKxyo2GUw8AcKmNeY
	nJTwcDSip96Pbz3W4po35VT5Mnn2Trsb+FNYbYx7KfryUgKFOWfHLHRdCIHE3wPRu3Ezx
X-Gm-Gg: ASbGncsxveVJrynAct6Eohacns/H2XDpY0fbiWQ/w110/uxHw4ysbnd0yhBlLfyPMKL
	UmlArYBoPYfue5BjT9bgpNGKJTYseBZLCJfL6jGecvHN+YoHDUqQAhS4F9pxVPcjGhXqCresoN4
	yQzhzo5ZQLLYBHVjjod2kJvaaaFcP1afWOxYeyIovTuBE3Mc+QV5VW8pyGD/p2XlZjxElBMWZgl
	wkTmtF5nJM6daTXEKk786mxTxo4PY1DIl+LQ0W/KbeTv5gbKE/W6SyHq50KJ2mZ0XDFJ7IptYvO
	BcsFwKE05+hLItVt5v4=
X-Received: by 2002:a05:600c:a016:b0:441:d2d8:bd8b with SMTP id 5b1f17b1804b1-442fd622c81mr247895365e9.8.1747905083665;
        Thu, 22 May 2025 02:11:23 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IEciTJ/zcRf4AXElu0pqBhYj5jKqeehae3NT83Gy64LvlkBARBipL5idMvjE3WFf06oe/P65g==
X-Received: by 2002:a05:600c:a016:b0:441:d2d8:bd8b with SMTP id 5b1f17b1804b1-442fd622c81mr247894945e9.8.1747905083275;
        Thu, 22 May 2025 02:11:23 -0700 (PDT)
Message-ID: 
Date: Thu, 22 May 2025 11:11:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 net-next 5/6] socket: Replace most sock_create() calls
 with sock_create_kern().
To: Kuniyuki Iwashima ,
 "David S. Miller" , Eric Dumazet ,
 Jakub Kicinski , Willem de Bruijn 
Cc: Simon Horman , Kuniyuki Iwashima ,
 netdev@vger.kernel.org, Jason Gunthorpe ,
 Leon Romanovsky ,
 "Martin K. Petersen" ,
 linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
 Juergen Gross , Stefano Stabellini
 , xen-devel@lists.xenproject.org,
 Mark Fasheh , Joel Becker ,
 ocfs2-devel@lists.linux.dev
References: <20250517035120.55560-1-kuniyu@amazon.com>
 <20250517035120.55560-6-kuniyu@amazon.com>
From: Paolo Abeni 
In-Reply-To: <20250517035120.55560-6-kuniyu@amazon.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: 8ODJYG7RA8TK3KoqhuIaeFFp0fCdYlzd2VERTZw1aUQ_1747905084
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 5/17/25 5:50 AM, Kuniyuki Iwashima wrote:
> Except for only one user, sctp_do_peeloff(), all sockets created
> by drivers and fs are not tied to userspace processes nor exposed
> via file descriptors.
> 
> Let's use sock_create_kern() for such in-kernel use cases as CIFS
> client and NFS.
> 
> Signed-off-by: Kuniyuki Iwashima 

The change makes sense to me, but it has a semantic change, let's add
more CCs.

Link to the full series:

https://lore.kernel.org/all/20250517035120.55560-1-kuniyu@amazon.com/

/P



From xen-devel-bounces@lists.xenproject.org Thu May 22 09:16:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 09:16:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993348.1376764 (Exim 4.92)
	(envelope-from )
	id 1uI223-0005vG-Hv; Thu, 22 May 2025 09:16:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993348.1376764; Thu, 22 May 2025 09:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI223-0005v9-Eu; Thu, 22 May 2025 09:16:07 +0000
Received: by outflank-mailman (input) for mailman id 993348;
 Thu, 22 May 2025 09:16:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI222-0005v3-3a
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 09:16:06 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6233ce8e-36ed-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 11:16:05 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a36e950e41so2908723f8f.0
 for ; Thu, 22 May 2025 02:16:03 -0700 (PDT)
Received: from [10.10.6.18] (server.hotelpassage.eu. [88.146.207.194])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f73d3edcsm100615565e9.20.2025.05.22.02.16.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 02:16:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6233ce8e-36ed-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747905363; x=1748510163; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=nl4dyR5F2gZP9fPzMMobhVGpr32We3YsDWUuMsZXgV0=;
        b=Qy1ZIQK01+LFUWV23oyFWTnq24W4gJ5qEfJJzZOXv8XV6EZ7mBiNqLsJBkP8DJA6hA
         NqQiRCbY79GHZWE/4IfN0nBbjcG8LWYhhKrKesYt8tbXcr/TNYsSGi1GQ64ePCBBHE3o
         N5WzetrDss5vYdQQwtRCdAVNQhczK0dANsG6Onm5JfUfgBBjG40ong/YKZrhyPmiWXSS
         crK8uWN69v9E8kMyVT8bEqDkJhDaTx3tIOHzHBA3dkVldrV1z8qMUHGmJWilRArEfPpo
         PTMcb4FDFvTtzvtFvjhnRlnOnqVAhCPLHmrEQzT/maHgLeKCCzi9UHw2ZSYnWcpeIDA9
         6NAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747905363; x=1748510163;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=nl4dyR5F2gZP9fPzMMobhVGpr32We3YsDWUuMsZXgV0=;
        b=fBS+ZEJq673y7ILyT9ynSMx9U8DOkr+zEitO0IlaobxGSTkruAlJgx63SW0ZcthHl7
         XZBmJrBsHVWwhsFVrjIxU0/az96shTNgWKEw/N7vebHzFAtGFDOju7CQQ2hYhuOTIIWp
         cOc7bGf7CN8BISAz7h8UFSlrO6Zca2HlmGRGw7Y3ntCw4xu+QLUJ1VJVo8CZgppJ+G+P
         Z9yIhhZ/LintNqmGnGqJ/MCprDZNhi7XEjjDnlZr1nzVbSvjWCk0onQfu32t1lCyMxTX
         269B5sNWhQQI459K5LaWQam+jbNzC+KxJoigcocuLGJItctsaFHyNyd1Xh+W+y8rFD3d
         3MuA==
X-Forwarded-Encrypted: i=1; AJvYcCXfPXw4Z4lsNEEXgsJr8uMobCMRPwSOAFKZ8NCrbQrVDFVKQff32TI5UE/C4fFEP2dPYMm4i5ATMlI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwKZlKNXTMzQN/+R9rriXC0+Qo12uafMWW/tF3HdJqDTjzUoMDB
	iz2JLRktjPx1eoQ7UKBYCWZm9h6nQpL5LJVbQ2FuWBCZFUlgjyesrTEzpgyYuklhCw==
X-Gm-Gg: ASbGncuV3Z2SkeCkvd//QhVzBJGP5XQmZOGLjVCp6RPSUfFoWxPP55/3MujZjmJY8HE
	BiyvW5ZZnpNUGwrbKRlQJ/FV7CyGTwn5liH3gqELS2HNTt90umni45j2ePo3XcvCnHVv7KwAkTl
	6odBHiB+Pgw64LuZ7V1OqNfFuvvFGRiz1IxgUkl15bUSYDr0Jh3Wz8422gNW8+IObORYU5dcbfH
	WM870UN5Ufh4wINIzqZ+ZLcq5dHpM0FnOiSqwhILs2RB7ziyeyYOV14izkmFxf0xBFgIto9QVTv
	wJir+tOR9RMvriUrpKDuqoM1SEVvycyoYQz3Q+xVR0zJruRtqJ9A00CqUq2s8hDmq3RYQpTP2EM
	5PnKc
X-Google-Smtp-Source: AGHT+IFYai6Qe0O07ei4lHtGYQdbqPAMbdseW3bA9QXv7KQCVBQHuGvc8bjZ5e58W69NQfQKJJOSXA==
X-Received: by 2002:a5d:65c2:0:b0:3a3:5c7c:188c with SMTP id ffacd0b85a97d-3a35c856459mr16031199f8f.57.1747905362695;
        Thu, 22 May 2025 02:16:02 -0700 (PDT)
Message-ID: <1cdf2744-5b12-485f-9fe0-40d986dbf2d5@suse.com>
Date: Thu, 22 May 2025 11:16:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/4] x86/traps: remove smp_mb() ahead of IPI dispatch
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250522075440.99882-1-roger.pau@citrix.com>
 <20250522075440.99882-3-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250522075440.99882-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.05.2025 09:54, Roger Pau Monne wrote:
> The IPI dispatch functions should already have the required barriers to
> ensure correct memory ordering.

To be quite honest, "should" isn't sufficient here for my taste. Either
they are there or they aren't. According to my check they are, so ...

> Note other callers of send_IPI_mask() don't use any barriers.
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 
with the word dropped.

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 09:21:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 09:21:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993368.1376773 (Exim 4.92)
	(envelope-from )
	id 1uI26n-0007Wy-2l; Thu, 22 May 2025 09:21:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993368.1376773; Thu, 22 May 2025 09:21:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI26n-0007Wr-07; Thu, 22 May 2025 09:21:01 +0000
Received: by outflank-mailman (input) for mailman id 993368;
 Thu, 22 May 2025 09:20:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI26l-0007Wl-Cj
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 09:20:59 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2418::61b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 112a2d41-36ee-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 11:20:57 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CY8PR12MB8337.namprd12.prod.outlook.com (2603:10b6:930:7d::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.36; Thu, 22 May
 2025 09:20:53 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.019; Thu, 22 May 2025
 09: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" 
X-Inumbo-ID: 112a2d41-36ee-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MZpqB+IEqmNuKsWHSdAbdXT5qf2ZJd0FAzXKrpX1fCrBsBkdkwbY0fGOMuTEsR45DeTIVq55RsyzJAXUaUUbSPYYOYefr23Eit/JcjpIlMp+reJZsa2KVjqVcPvhlI/Xy7cLNSJJRw3aRjftnXHPFuB8gCjdeXjsx4pqikpWIUorn7bewRT/UlSJVevf3mkOfuzxCM164ppCsj1OF+V9qhqSgaYmCfe134BA+m53Q9gOSlcd9w0WbjlkmSyz6VDcFkM5YBOujfldiJLa8E7LVsjhJM9QywynRWSWFFRmdyex1qruRR9FLVflwgj6PdBPeBHOWxCtH302vGZ+t6fkbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=V8XG4OOXNchFg9Equ0G+30Oudv+/TFxJK7M+IMtNX5I=;
 b=bcyxpicYYuiRb5KJsijekUnMntGlgG3J9+I1cdEc6EA1zaniJhkKpEjZ5JcQxKkj6E2dJYcNIyD8x9jKhHQmP72db6Y9mbW2sTsQ2iCeM5VRs8g8O06Xvm7Jky1F1T/9lhGa9z2yiz8XVADSQnREuRMVKL/ZF7oj50bHZ2eFd4+0cVyA5yODcALF1r6jsx9wDzLgDY06rDQQM19aCRP8ouFG5lA9ggOmSxQ5DqBe0SBr/lfvJlgGy6IdzlzQKgAnGW2pgd00ck2iiG0Ax+6Wyo0APe3W0JEFbVk84Ls56tS9LZudRg0tHr4wU0EwMcX4uDa+vSd/EoaH5PavIZuy2Q==
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=V8XG4OOXNchFg9Equ0G+30Oudv+/TFxJK7M+IMtNX5I=;
 b=jflJaMy0Cpm125m8IThqIqnYpQ0LUGyfLlckzPxgWz4UbBQ2+4Xxk9cQqiVYaXEbJBzxN/mLjHMZg0/llK3Dbwrzoxu/KUJwDVgbyw9gji5LYiwiAlz++o81ly9KWV1YvKZDNl4E7Ks+8KmGP3kBjNGA9bU1fballkCcflc2XeM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Thu, 22 May 2025 11:20:50 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 6/6] arm/mpu: Provide a constructor for pr_t type
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-7-luca.fancellu@arm.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250513084532.4059388-7-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR2P281CA0097.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:9c::12) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CY8PR12MB8337:EE_
X-MS-Office365-Filtering-Correlation-Id: cc469aff-0048-4e68-2e10-08dd9911f350
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Q2tXYll2dnFYZlcyK2VKKzJ6UG5hdG9QbnNPNUxYcnNoTnlzMVo3NTllS1lh?=
 =?utf-8?B?RVc1bU1hck5RcU9vY0JFck5Va3JONjZFc2xzNS80NG51NDZ4VXFETW0xMFh2?=
 =?utf-8?B?bThVYk1sczRKaW1WQlVwUWRhdm0wQ0UwdDJxc3l3d2tNekRuU01lbFoxWTVL?=
 =?utf-8?B?NjFMU1hMZThDUG10TE9RYzFRSnZIeHhvNVhJeXV5c3FvNWxUakd0Q1hFNm1T?=
 =?utf-8?B?dGt1d0tYM0c3a2J3aUNuTlYrMURQUzJZVUxaRWVTQSs0aU9uY2xzenJvWkd1?=
 =?utf-8?B?dUpBYXkxNUpXT1ZyMzhKSG1vMENpMjY4NWN3SlVrVnJUVFh2bnpLTEhiY1hC?=
 =?utf-8?B?dnNKUTh2WHZ0YlFybi9NMkJTbkkvSEE0ZnIydVl5SlhtMkdZaHMxTS9NeGFh?=
 =?utf-8?B?cjBaeEVmRlFneEFnTHlpaS95bTlycHJwc0xpcVBWcVZBY1c5SjluTjFXc2sv?=
 =?utf-8?B?UkpoZmxacURMdCtwSXRDTk0xVEg2dmF2MU1sYkdENUdxaDczRVh4dlRaYlVw?=
 =?utf-8?B?bUNOekwzMmowaStBYm92OEV6STdMbm94eGEzNXZyemxEOTcwK1FZZ2JYcWNw?=
 =?utf-8?B?clNXQzg1S3l2NzhxdjZhWDltbmZYcUJVQWRlY0swcUNwRGhBMndKdWxpa3R0?=
 =?utf-8?B?K202NXZ2dEVUUUtyR2FyUHN6VUprYzVIMnZZQ09lWlpNcUVvZElQWmQyTFEz?=
 =?utf-8?B?a1J3K213RXMwWXpVbURsRHc1SFZTUHBxM0JBczRqc0JUcXFLZ250Rm1xVmxN?=
 =?utf-8?B?MW1yOVVCbmRQUW9rSUZYNDAwRTR2eGVEQjNNZGgyekQzeHJobWdiamJDeVFC?=
 =?utf-8?B?Q01NM0hBV3N3Q3lDWk9tS1JTcTVCcWtTeXZ5SUdEbWYzQXNSakgzc2J3QnpP?=
 =?utf-8?B?bFhvRVBmdnY1bjVsVU9nZ08wMnJoMVE1c2dvemNXSzAvb25mVHRnZVZrM0hP?=
 =?utf-8?B?Y1ozdnB4d0d1U3RPbmlnSjM2Ujlwd2hhL3NaR2llbi9SSGZQaG5RR25nRGpM?=
 =?utf-8?B?d0VvLzBwRGRpSHloV1Y5am50bmgzL08zRDhjZ0o0bVJpdjdkVFdyaDErdkg1?=
 =?utf-8?B?NmRoM1lqSVRtUlFyTGpJQllGNENpMEpHYVRxTWxSY0tLTEF1d3hPck5NSEVL?=
 =?utf-8?B?eU1iWXlOYW1OSXUyOS9GUDlZY1NYYVlCajVRamRXTnR3Z3IwOHYwVURJSFVX?=
 =?utf-8?B?eXZ4K2lsclB6azFnV1dYNXZJelVXSzhiYmRHZC9lKzhDdzJwTEdBZXNWVDMr?=
 =?utf-8?B?QloyWGlyLzZjOVlQcko1TUd0bW5sTkNJWEI1Qjkrc2tOcHgraUU1NjhqNGNF?=
 =?utf-8?B?bnluMzhNNUljbVNCS2lrdzQ4MXZMeXh0aUxIMjYvUDgyUTVtUXkzQktVY0RB?=
 =?utf-8?B?WlBpSmxCMGZiWExNSWdCRFFVeEZSUVluUE1ISS9hWlkyTVI5MC8wTm1STTIy?=
 =?utf-8?B?TUsrc0ZNeVp2VVY4VXFHZ0JYV1I0US9aRm5GMHE3dTdnbHpMTkcwbFE0RnBi?=
 =?utf-8?B?WWVOUDhRS291ZXNSeEtrcGxMOWduUjVmRUZha09FU1J2ejhuQkgrSEg3MnV4?=
 =?utf-8?B?Y3A0TE1lT1RmMmxaZ0lhSjVIYlM3RkJaRm42aXJpYzhYTGpPeVkya1ZFeFI3?=
 =?utf-8?B?V1hHdHB6R2psSXRIUWhWejFXNFFGQlA3bzBFdGgwZzd2bHhwU1Z6cVAxMm9i?=
 =?utf-8?B?NGM3TVZoeGVyMFlxVEpJZzc5UGVCN29xSTBsYWJoTndjVVZTQllhSVBUL0VG?=
 =?utf-8?B?NDJlOGcreUx5K0EvM3dpYnNKNzk2TkFicTJIWHpQQmtQMmdiWTA4REdLa0tt?=
 =?utf-8?B?bExZZ2RLdFkwWnhSY2UwOXRMTTVZQzd2TjhhbHVFdGNwc2FiZTRGSHVFajQw?=
 =?utf-8?B?NjZOd24rQW1ZREFMVC81bFpoQXl0T1A2RTlnTWcrSHlacVRiOUhzWFYrbDdY?=
 =?utf-8?Q?afrrkgF9kbk=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UjNKN2I3dkN3Q25jOS96MURHMXdFRGlscGdvL0JETmYwZHBzbzBkL3NlVEo0?=
 =?utf-8?B?eTVMRDNnbkdSNXpPSzFDeXFJOTRuRmozMUdRdGc0cDRObkVWMERpQUVaSTRX?=
 =?utf-8?B?bkdTOVJqWitHa3h6YzFKVCt6ZURPQ0g1eWI0NGFpTUU3T24zTGJLS1lmTjY3?=
 =?utf-8?B?SHEvQTA2Tm9zNFBwaDc0OFB4bkdOVWxoc3kvMHh5NVVPc1ZwRUpJSUJKQity?=
 =?utf-8?B?eEZvVjd0L0NLU1RvWkV3WWNGRERyZGxWMGNRWW9XZHpTN051V0M4c3ptUW5C?=
 =?utf-8?B?LzcwYWRaaDhRSlFKSFRGL0xmV1Blckl0RGRCOEJ4TDB2NExMREdqeWtwNU5Z?=
 =?utf-8?B?NFFkcVV2TCtHTU9rdmZLZHFWaDBiNGE0eWlvUHJxNTEzcTlHU09yMFB0aXFj?=
 =?utf-8?B?d3dQQWIyeklkZE1OZnd6S3ZsamFxdWxqdXFDd29BS2IwOGs3SkV5WFFZU09v?=
 =?utf-8?B?TnpPNE5GeThCaS9UR2RYdlBZSW1uUUU2ZkEyV2RxQmR5TVl3RnovNHdRWFhO?=
 =?utf-8?B?R0Z3WXcxNTdCTDZxcElIem1YcndFMVZ4eDZQNnBiYXlBSkdKdzY5Szg1ZDFD?=
 =?utf-8?B?M1h4U2hQQ200S08xeTZkZHVkV2NpeFhXZC85cmFYRTI4WXB0VnArdUdnNWZ5?=
 =?utf-8?B?aUYzSHNndm9xMDB0REhWdExyNGIzTWd0RFVweG5kVlRXbEE3RjlFNnNQWTh2?=
 =?utf-8?B?bnJzZkRZVEFUVUFkd29mZVpldjFZOURGYWhDM3Z1VXc3RUdUakJBV3ExamIy?=
 =?utf-8?B?WEhHa3JOR3dWR1dCcERLYjBXWVBsZktZYnZRWXBwc2dPMlVwMTZhVTZHcE4v?=
 =?utf-8?B?NzZxRGRkUkdsMDdzcWFPN3VPUHNaSjVzYXpCY1orQjVuWC9VOUxEUkkvV2s5?=
 =?utf-8?B?WDY2QlNyc2JzS0lGM1JNMzVjM1pvcjh6YXF5OU1Ydk9EWEdZMGtHaXFMdmlT?=
 =?utf-8?B?Y3M3dkcxR1dSMUFXN0hGMERpY3Z1N2VHbEM2c0tEdGw1UC9nN0VRZC9nL0JM?=
 =?utf-8?B?ajVPUnExRGQ0RktLYUc5YkgyYlZTL0lYRDRLUnVIVC9VSVBYZmRreGtGS0Zm?=
 =?utf-8?B?U3kwdTNCeU4wQXY4TGd6eFA1NTRqRVJIQWZJUVBxbm9ZbXNWM0xEbmhhaVpq?=
 =?utf-8?B?WE1vdW1XMnVZcmlpSTd0cU9icmxyYkM2S0RoYmZsa2drQS84aEhKdXh3b3BC?=
 =?utf-8?B?R3BISTBCUUhPUGdtY2VuYXJYMmMraXl0MDU4TkQ2bXlab3RkK0VnL1ZCRFFp?=
 =?utf-8?B?YUd0MWlWYTdkWXZtd1dPRjR6cVZ3VW5YU3BYUDQ5QkZvVkMyRDB3cjhlM1lL?=
 =?utf-8?B?ZW1YV2orbXlmR3NnanU4R0FwbnZ5U1gvWTJpdjlxQjdLVi85ZVI5bHRVcWpp?=
 =?utf-8?B?VGNzVWowZVpldFo3TUNWdGU5Zzh4WkVMZnB2Y0dpcmJYTVlpcC9lQ3NLTkl0?=
 =?utf-8?B?aGMwajFuWE01NGtBSEdWQUl0bjRmSjIyUlFXNkVOQzE2aVpSMVM3bktNd0Nm?=
 =?utf-8?B?L1d2NFIrZzZMS0VaM21vdE9BWlpMYUUzbVBlUUZRWTFYZkxKOXNlTmJHcTFX?=
 =?utf-8?B?V2dNZFZGWkxaendhN0k5WVhFb25PcmNzWmFKcEJiNGRWMkFoSFlkVVNIMFAv?=
 =?utf-8?B?UFJXU3d5MzFlclN3R3JYOGhOdEdPd3RzbUIvNlNFdDdZNy9tR2ppdUVEY2or?=
 =?utf-8?B?eDRFNmd5d1BnbkNTeWpjV2xmVDlSU2VRTFp5TjZmamhEczlCK1B0ZnNHQkpH?=
 =?utf-8?B?NW1qZWhMbFJXNjVmUkdWVW9OUnVVb3JlZ3ZsMnU2ZS9QditEZ01YcmRHcnZo?=
 =?utf-8?B?ZzJaS1BiSEM3V3dXWjBsOWNsTHBjOXlIcW1TYTJMcSt5SjI3SmVSYUViT1Zv?=
 =?utf-8?B?RnFXUUZXK1A5Sit3NzQwODl5bHBvUlRKVHA3TklmUnJMYTQ5bUpURDJpS1g1?=
 =?utf-8?B?bkNDaFNuNkdvZEVlM0Zpd3NVeGZnQWQ2N2hMdkFpRFZMU2pLcU50U3lZVHls?=
 =?utf-8?B?eHhHSzdweWEvRzhmcEVFaFFSQTFSa2UzSVJaY2NKUFJzVGcwTC9sOHFmQXNp?=
 =?utf-8?B?SjZaNEVzNnRTUDlxcVNoUC9NUWdidHNMWjZ3VU02em0vY3V0QVViaEFNekJn?=
 =?utf-8?Q?2dDZIIQe6mnrHFrB9TCNgSUcu?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cc469aff-0048-4e68-2e10-08dd9911f350
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 09:20:53.3951
 (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: B7JfIZTuLkQ1W+BB9iKAmLQfthu66heLPCIxA4KCl2RbkKj+UHgwwki4u4x+3bP7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8337



On 13/05/2025 10:45, Luca Fancellu wrote:
> Provide a function that creates a pr_t object from a memory
> range and some attributes.
> 
> Signed-off-by: Luca Fancellu 
> ---
> v5 changes:
>  - removed AP_RW_EL2 used only by pr_of_xenaddr(), fixed
>    comments and typos
>  - Given some comments to the page.h flags and modifications
>    to the prbar_t fields ap, xn, the constructor now takes
>    flags instead of attr_idx, which I believe it's better,
>    deleted PRBAR_EL2_XN_ENABLED since now the PAGE_XN_MASK()
>    is used instead.
>  - renamed to pr_of_addr since it will be used also in p2m
> v4 changes:
>  - update helper comments
>  - rename XN_EL2_ENABLED to PRBAR_EL2_XN_ENABLED
>  - protected pr_of_xenaddr() with #ifdef Arm64 until Arm32
>    can build with it
> ---
>  xen/arch/arm/include/asm/mpu/mm.h | 10 +++++
>  xen/arch/arm/mpu/mm.c             | 66 +++++++++++++++++++++++++++++++
>  2 files changed, 76 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
> index 2ee908801665..f0facee51692 100644
> --- a/xen/arch/arm/include/asm/mpu/mm.h
> +++ b/xen/arch/arm/include/asm/mpu/mm.h
> @@ -75,6 +75,16 @@ void read_protection_region(pr_t *pr_read, uint8_t sel);
>   */
>  void write_protection_region(const pr_t *pr_write, uint8_t sel);
>  
> +/*
> + * Creates a pr_t structure describing a protection region.
> + *
> + * @base: base address as base of the protection region.
> + * @limit: exclusive address as limit of the protection region.
> + * @flags: memory flags for the mapping.
> + * @return: pr_t structure describing a protection region.
> + */
> +pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags);
> +
>  #endif /* __ARM_MPU_MM_H__ */
>  
>  /*
> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
> index 46883cbd4af9..ac83227e607e 100644
> --- a/xen/arch/arm/mpu/mm.c
> +++ b/xen/arch/arm/mpu/mm.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct page_info *frame_table;
> @@ -153,6 +154,71 @@ void write_protection_region(const pr_t *pr_write, uint8_t sel)
>          BUG(); /* Can't happen */
>      }
>  }
> +
> +pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
> +{
> +    unsigned int attr_idx = PAGE_AI_MASK(flags);
> +    prbar_t prbar;
> +    prlar_t prlar;
> +    pr_t region;
> +
> +    /* Build up value for PRBAR_EL2. */
> +    prbar = (prbar_t) {
> +        .reg = {
> +            .ro = PAGE_RO_MASK(flags),
> +            .xn = PAGE_XN_MASK(flags),
Shouldn't you also initialize .xn_0 and .ap_0 or you rely on compound literal
implicit zero initialization of unspecified fields? But then you do initialize
.ns to 0 fror prlar...

> +        }};
> +
> +    switch ( attr_idx )
> +    {
> +    /*
> +     * ARM ARM: Shareable, Inner Shareable, and Outer Shareable Normal memory
> +     * (DDI 0487L.a B2.10.1.1.1 Note section):
> +     *
> +     * Because all data accesses to Non-cacheable locations are data coherent
> +     * to all observers, Non-cacheable locations are always treated as Outer
> +     * Shareable
> +     *
> +     * ARM ARM: Device memory (DDI 0487L.a B2.10.2)
> +     *
> +     * All of these memory types have the following properties:
> +     * [...]
> +     *  - Data accesses to memory locations are coherent for all observers in
> +     *    the system, and correspondingly are treated as being Outer Shareable
> +     */
> +    case MT_NORMAL_NC:
> +        /* Fall through */
> +    case MT_DEVICE_nGnRnE:
> +        /* Fall through */
> +    case MT_DEVICE_nGnRE:
> +        prbar.reg.sh = LPAE_SH_OUTER;
> +        break;
> +    default:
> +        /* Xen mappings are SMP coherent */
> +        prbar.reg.sh = LPAE_SH_INNER;
> +        break;
> +    }
> +
> +    /* Build up value for PRLAR_EL2. */
> +    prlar = (prlar_t) {
> +        .reg = {
> +            .ns = 0,        /* Hyp mode is in secure world */
> +            .ai = attr_idx,
> +            .en = 1,        /* Region enabled */
> +        }};
> +
> +    /* Build up MPU memory region. */
> +    region = (pr_t) {
> +        .prbar = prbar,
> +        .prlar = prlar,
> +    };
> +
> +    /* Set base address and limit address. */
> +    pr_set_base(®ion, base);
> +    pr_set_limit(®ion, limit);
> +
> +    return region;
> +}
>  #endif
>  
>  void __init setup_mm(void)

Other than that:
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Thu May 22 09:57:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 09:57:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993481.1376815 (Exim 4.92)
	(envelope-from )
	id 1uI2fY-0006Ix-Cy; Thu, 22 May 2025 09:56:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993481.1376815; Thu, 22 May 2025 09: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 1uI2fY-0006Iq-9t; Thu, 22 May 2025 09:56:56 +0000
Received: by outflank-mailman (input) for mailman id 993481;
 Thu, 22 May 2025 09:56:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI2fW-0006HE-Mj
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 09:56:54 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20602.outbound.protection.outlook.com
 [2a01:111:f403:2613::602])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 16832e5e-36f3-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 11:56:53 +0200 (CEST)
Received: from AS4PR10CA0029.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:5d8::18)
 by GV1PR08MB11165.eurprd08.prod.outlook.com (2603:10a6:150:1f3::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Thu, 22 May
 2025 09:56:49 +0000
Received: from AMS0EPF0000019D.eurprd05.prod.outlook.com
 (2603:10a6:20b:5d8:cafe::91) by AS4PR10CA0029.outlook.office365.com
 (2603:10a6:20b:5d8::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 22 May 2025 09:56:49 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF0000019D.mail.protection.outlook.com (10.167.16.249) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Thu, 22 May 2025 09:56:47 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 DB4PR08MB9190.eurprd08.prod.outlook.com (2603:10a6:10:3fd::21) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8769.21; Thu, 22 May 2025 09:56:12 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8746.030; Thu, 22 May 2025
 09:56: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" 
X-Inumbo-ID: 16832e5e-36f3-11f0-a2fb-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=It9SQYTVbtPNz4JpCDorbMPX1eF2R5JBoQTQBokjsVOJ0rtiVDXADFkiQinS98oR6WW9kBOS4PfIMonfxqOUvv7D/5XMFCuc2r5lRw7VeKcPkBeRZjMtXzMZCg/35mxstdA5KZ6z+qq6lDX5apYirdnT/WGuJco6/VQa/+EvKWEUN8UACi0CJE0kDGHQO4BaHcz7Qw7BkB6uaMBWkZ6PhzLncF/XSHIlwD0/TFHHjxYYn2HA34OGm2o+yclOmpzc7ZrLFFD7QAgdQXGsoQrwnDD0E4VkggcZY4WCaNGF36lAhP/TD1f1wDrP0cbovUPTYacceGzjW3ur8KBlxh2Ecg==
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=HX0ICNMa/FDROzjfi5n4RwjMAAbwXLqOf710uP5MNXw=;
 b=CWr2mug8LToXeXRkLt3Uoy923ap67BX8xrETFUbSfEkJaan8rSc9FgXOMalAaa5IbadClmUdT7R4yEsD8lxRDL9eNRk9dNgIiQU0LhA5N6IehmqI6AvbUqx7m6MCNaLwjiPhYpMayfOcJX2ar8Os3qmBUEXZhAg8qjGXM+R5W+83y0DaVmhxszYVyhFww4yvw41Oxbg9A92JGscijLFKp094n0XQWS4IbwV0xOHwtmHqYeNZNa4uYEGBvBRDX2DjbEaU/5gVobTJntkxq5WgPN9dkYY1uYIqhX3hGsO5stNVrNmIq6OKxz7nlPk/ICDBn7KLp1RXBYVeXxgxQDjrGg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.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=HX0ICNMa/FDROzjfi5n4RwjMAAbwXLqOf710uP5MNXw=;
 b=Nrk9yTKjJlFiv4pLZuRSMZLyFlNGYfcZ8fBGdHOr7ChlOjLH9n8vKFOcoqptTDs5WIc4hvSmyjSjfe80ToDCpRDHmQznvxGdOIBvF6dW4DaiXRjR8VSivgp/u6Qx/ysJ5yW2pJbqEmx05Vh6MtkHdq4T8SAcqgQYw/kDQeEQJhc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=O6w3ea3NxzeLt8w3tqvtfAtKd9F+J0RgFyiqVOiMaaYDgzMCmWj6YsjSb9KiA8P/nhzwPa53qbb10QwSLzxKLCHq7Cs3KgO/nWMXmji0DU0zeFg3ltTzaqmpvP7yNMk+w/Auq1bOJ86nnJEwODv0ZQruQmZzuZ8AdErxl97lrgTqU6jEClL8WMtXhaXQ/sqgTxyqikOX+KcvdPsN0LSjRfGG4LLrKWzIEEZYwUK6yRfAG/iwGZpU8O+Q5q4BvccwbGmpcmlOf6C3ZvlqER7m0ujXpIa2H7BrSLUMUm1yNQ3OpxX1geHF+tQK2cH5TuwfqKHJFS0G7pMnzvKluIO18Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=HX0ICNMa/FDROzjfi5n4RwjMAAbwXLqOf710uP5MNXw=;
 b=Zae72FQF7/o3pS+Dy33/VGetG+QKwK017/SE+LIEStXf1TcWtTMIAjBNjghdpxYB7+h1DUgTQ4KUeCNU1shXWNLuIE4+ZfIgGubXgETxHCEaJXaeOKSpiA4fz/AHGOVLT6EUFkd0bevsbi4++C2WA3z8s9VNnjTnuw+In+rPAbLxPm+u/6BWxsBA8WeeoL9E8uGhfXlcfRdU9X2wCq2Y/oLxEdkt4yOmmsrrGPR3gTcqXb16JMffrja+u4OnWFZs+sYcrl9PknouQfvuwWepbkcbRWl/SrGuwyQEjqAzzfl549aGwt8BZcHf+qYgaj4erzBn1tpvO/h4HF8T4B7d0w==
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=HX0ICNMa/FDROzjfi5n4RwjMAAbwXLqOf710uP5MNXw=;
 b=Nrk9yTKjJlFiv4pLZuRSMZLyFlNGYfcZ8fBGdHOr7ChlOjLH9n8vKFOcoqptTDs5WIc4hvSmyjSjfe80ToDCpRDHmQznvxGdOIBvF6dW4DaiXRjR8VSivgp/u6Qx/ysJ5yW2pJbqEmx05Vh6MtkHdq4T8SAcqgQYw/kDQeEQJhc=
From: Luca Fancellu 
To: "Orzel, Michal" 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	
Subject: Re: [PATCH v5 5/6] arm/mpu: Introduce utility functions for the pr_t
 type
Thread-Topic: [PATCH v5 5/6] arm/mpu: Introduce utility functions for the pr_t
 type
Thread-Index: AQHbw+N8axomw5+oq0q6+Td9FW5OAbPeZN4AgAAStgA=
Date: Thu, 22 May 2025 09:56:12 +0000
Message-ID: <14A6545F-F7C5-412B-8A3D-9EFD293D69AE@arm.com>
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-6-luca.fancellu@arm.com>
 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|DB4PR08MB9190:EE_|AMS0EPF0000019D:EE_|GV1PR08MB11165:EE_
X-MS-Office365-Filtering-Correlation-Id: 7fcd523d-baa7-45e4-531c-08dd9916f756
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?MlZNSHVRVmR6K1dFYXpTeExyK1RVd09QWUhyc1NnTXBuVmRnd1JxVUIyYTFS?=
 =?utf-8?B?VWl5RVBCaDlUY2sveTY2Vk1PVEpIYkFkR3VyNjg5T29lU0ZEUGdlSXFwYU5m?=
 =?utf-8?B?V3VVbnp3N0pWcG5pbGVWM1I5alIzeEJiYlRkUVhySGJ3QmJ2MkhqVHo3emJF?=
 =?utf-8?B?Z21ydnZ4cHlieTBuay84Yjg5c0dCbmY3ZGZRQkNQWkhDWk92TUdEWVcvS0lD?=
 =?utf-8?B?eWFaQ0dLMy9PaEk5UW5zaVZDTDlZUFRLTThNbTBIcndydnVLM1lodjdtSEtW?=
 =?utf-8?B?RVIweEpPSjlQdE4wZ0RSMHdUbzNlbXI3MWZ3cXJTOEFTcXpxdThjK04wTHAy?=
 =?utf-8?B?d3hURE1HVU1ZVUxoS3JoZGh3eVQ5OWxDSlp4M1MyVU5EOUxWZFR4ckJrTnl4?=
 =?utf-8?B?UW50YlRtenF5SEFxVFFxNXp5Q21RT2poVExuRXdhYnZCeTRwd1dHalpyODVQ?=
 =?utf-8?B?akFsejhXRC9RaS9SWnA3VkN3cytFQ0YvdGVMMm1PQWd0TU5PVmNZY09UK1NR?=
 =?utf-8?B?cUpCdlN3WW5wRWNhZUVla0oramd5WU9jSERRakNzYitNMUw3cGZFeDcra3Zl?=
 =?utf-8?B?UVVMNU5mb1AvZm9sUU5OTVd5YkxxbFVvd01FdjRTaVJneXNkdERpMXEzb05a?=
 =?utf-8?B?aEZxNjlNU0J4NVhVVzV4dnhHM3dZNUhaQkdSRWtja09oVEM0Q0hpdEYzQWlp?=
 =?utf-8?B?WGdxS29IYk5OQncvYld4ZWozczlaMlc4TkhpQVN5Slo0MmRnTnFibjZWUDYz?=
 =?utf-8?B?b09NaUs0KzhjMTFXUEI4anAzaldCMzZKNFI4aHFOOG5VODViWTRhb0FqaVRl?=
 =?utf-8?B?Y0w1VnZYTnk1VExEMGhLMEY2NzFDN2JSQ2tNL25TbTB5L2RaTzFhM2w2Wmc0?=
 =?utf-8?B?NmhOWEV4c1U0bHZKOWVEU01ieFZtM3VkRFdwRFRaZ1QrZUxadUpLdk8zb0xz?=
 =?utf-8?B?S2NuamJtVnJKbDVIV0V3Z2xxWk9iS2U2eG10ZkFnQXpCTVdhU0p2a1RvZFJW?=
 =?utf-8?B?akdKV1RUR1Y0OGNRTkxSUUV6aVpKTjZYSnpzOEVScTRlU1ptOXBIZ3ViWWQx?=
 =?utf-8?B?V3NRazB2VzJQWkNLbEczdi9LdWtuSkVVQ0JGM2ZaVmw5UE9OUi9zYzkzVXNN?=
 =?utf-8?B?cGgzNzliV1RrVmkyZ3loNkhrZGpiSTZQSEhmU09WUTFnT2t1MWlYSWpZcXBr?=
 =?utf-8?B?bE53TWJBRW8xbXJ5MmRoTHl6M0ltZWMzdVJ5ek1nMjJLVzhrRk9hUC9qWDJH?=
 =?utf-8?B?ZGRkUmNFdzkrN1V2dXVRSWdYcVRZVUhhaFdDSS9URDdlS1Riay9xK1lJYW1T?=
 =?utf-8?B?WDdHUkI3b25OWHluYThJbERqV3FRcEk3T3VTUVZ5eGdMNFlpTWp1RkkxNzRs?=
 =?utf-8?B?S0hJbmw3UXVEd2tiMnV3RGRMZnlyM1ZjTDZQc01nU3RQSU5FcTZ1QVVybm5U?=
 =?utf-8?B?bWZSU2VlNmM2THArRThQUElLcmxZRzgybmJuTWxYRm5EZ1ZQSnFPVnFRRkhi?=
 =?utf-8?B?bFU4cFpISm5MVEVuQVhDR2JjZkFJemtBYjg1ZmJtaFhHaVppMzhsR3EvTXdP?=
 =?utf-8?B?V2VmNUxYNEFKL1F3R1hzK0o3aGd6b0QvN2NQelNvangvdDNIZFNXZkdsK1JI?=
 =?utf-8?B?eWF3UWtWSFVZWEFmSm8yMVFVUXV6eU16TlVMVS9MSGc4VXhJS0JQbGxESmxJ?=
 =?utf-8?B?cHRVU0lOVUQrczVKVzg0Szd3MUtTbllCN0xjUWtrQllMaDQ3SHYxV2UwcGZi?=
 =?utf-8?B?MU8vOTNnVHAzQkJLRGx1dDFVbGN5WkZ1ZGJzSC9vUnorRDNOTFNETXJ5MEsr?=
 =?utf-8?B?cXpTV3Q2aVljVnpkeWpnUVZSZ2pDU0dHdVFuZFVkbDU2UVlMWTVKQTcyUGVP?=
 =?utf-8?B?ZzFXN2g1M2Fnd0J6aUo5YXNnUUJKc2p4MEJWZ0pxUnd5OUQxZnZ3WFlhL08z?=
 =?utf-8?B?bDBsMkRVV2srekYvZWNtZ2dlRkxsb3ZlM1pHdVZ5c1l1V1ZBQ3RVeEwvUXYy?=
 =?utf-8?B?b1hYTnRldTZBPT0=?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB9190
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF0000019D.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	f3d418b1-19b5-44d8-2fd9-08dd9916e29b
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|1800799024|36860700013|82310400026|35042699022|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RUcwamcxbGZrclNScWMwTWxiNFhZM1ZnbkhuZVFRSDJPeUNvNjFxYXRIbUxm?=
 =?utf-8?B?bzBha2hPWm1pNUtFbDROK3hsSXd5b3k3MVhRa2ovZUVMaVVBOEcxQmo2cHZQ?=
 =?utf-8?B?c1M4b3phK29BRmJNaXNBeWpzVGo1TVkxOFVHNEttbVM4QmY1U0QxSy9aUmJj?=
 =?utf-8?B?OHZ5K2VRRkJSd1NFSmdneS95UmxsU2cxVGIvb21EL0FzMks1Q1pNb211Y0ly?=
 =?utf-8?B?WWR2RUFVUGFYMVVuTHd1cHBranZlMm14UktaWkNMMEZ5aWNDNFJxUWt5aTZM?=
 =?utf-8?B?R3ZQUy9lWkxHRG9MTHZrM0xkWkI4K1dJV2lRVjBNZXgzOXEyeDJScHJIS2RZ?=
 =?utf-8?B?NTRldi8xZGl5TldPUk1MTUdtTWJkMXVHU0dwQWhsWTlST0JqTjdtYkxaYS96?=
 =?utf-8?B?cno1VFZoeGF1czhRdjRKKzk2ODVxNWZoblJ0bjhaa0dMT3UvV3JMSDl2VzdF?=
 =?utf-8?B?NWlkeE5HdTVlZGhjSnhlTzdTNE5Id3QrUlpjby9KYzlNMGxVYzBCUC9CSHlU?=
 =?utf-8?B?V3hHZWJKNDY2Uld3ZjdWSlJNZ0I1c3pjdkc4SllpcklEamNudFBmSGJoaXJO?=
 =?utf-8?B?bDJqWjNHRGlFdHdJMnJ3cFR6NFNTL1ErUDd0WnB1WVdBMFVpaldLUTQ5UWwr?=
 =?utf-8?B?dzRqT3pjeGN1TktWUG53YnVtNWVRVHN1SmVhZDFWcWJvbjVJcC9XeXNFbUhT?=
 =?utf-8?B?RjJBSjhPSE9reWp1MVo0REF1dXVMaDh2WjZLMVdQUktVN0p4cUxXVHk4YUlO?=
 =?utf-8?B?eGJld2lkalZnQ1JzMWQ3SFlVbFlzbzVteUxNNWJuWDNKdFNFSnY4NVVaMHFm?=
 =?utf-8?B?QS9ZVkxobS9NSjNSNVpVZHJiWnpvK3RHeENvYmxBVjN1UmRiVG0zYXZrL3I5?=
 =?utf-8?B?WFlsWE1rL3JlVjRzQVpiZjd5bmc0UUVIUE1GUmdBZEtVZHNveXZ2NkIwVW93?=
 =?utf-8?B?anhOR29JTnU1VlMwVjkySFk5OUxHb0U1WmpLK0szK1ZYRUxacS96MkVPazIy?=
 =?utf-8?B?V21iOFBiU1J0ZHh6NUVra2ZhNDFUSkFibkxuMitreCt2QXc2ZDk3MTZwQTdM?=
 =?utf-8?B?WnZNZE9kanpSeXYzNDYxRUJzb2pKb0JBUmg2cXlUMVhZTG1OOGNVYlZvN2R3?=
 =?utf-8?B?aUg2ZGcxTE5rbncxallmRGd0SG0ybTQybnkwQWljRURwcVByWDJtVTE1V0p5?=
 =?utf-8?B?WnFtQ0Q5UWNpTFBtZ2dIcDl3R1dGTktDWXBGL3hRVFcxU3hCZjV3Q3ZXQXN6?=
 =?utf-8?B?anJJcjNDUFlWY2FaektTM0ZBYnl5TXU4MmZFZ2RrNU02TXhDZjhhTnYwMUN1?=
 =?utf-8?B?SkNKVkluYVRNemh2VUFMTDBoOG5qbVpqOGpkWS9QTGRmUEc3NTk4NllJOC9z?=
 =?utf-8?B?c0lTWEpZY2hxc2UvaW5EK3R3SnYzcS82cVRFNm94MHcrb09DcjFBbkJicEcr?=
 =?utf-8?B?SlhMQ2JuaVRzRXBvM1VxVFhaQWVQQVEranFRRFFXVkdmd0I3UnJHODBqbDl5?=
 =?utf-8?B?MkZ0WWJqTVNHV0xFZU8xK3QzSkYrTTBuV1Y2bDJEUWd3cDZ4aWJCM2V1WVZq?=
 =?utf-8?B?dnRPdTNZR1YzVjZ4YW16L3FJU0JCVFN3bmd1TXhFbG1GOU1wbTBOUHp3MDl3?=
 =?utf-8?B?YWcyU2JuZnVTa3JIb3hXSVh6bkxUQ0VoL3J5NXU0bkgxWUxHbkU5VjdLbThO?=
 =?utf-8?B?RWNhL0w2T3V1YytjTXdmTnRGWk9ySXBzOGoyZktTRmlrSGMrM1VZbXo0YlQ4?=
 =?utf-8?B?cU44R3JHVDdDdEZPbDAySjQzcXU4dnhESDNzN1E3cUpCQTNrb2pkaWdIY2Mw?=
 =?utf-8?B?b1NUdmpRSzE0RDZpY2dkcW12TDhkeG5YNTlVcFFqZnNqMjNIYjFUZmR5Rnh2?=
 =?utf-8?B?SGxUUXdBRXE4emgyVTRibkhxdWtLcjE1bXhFSEVhTjRLanhTQ1p3R1RIL0gr?=
 =?utf-8?B?L0VFV29xRk1CSmMvUXZscTVLclc2ei9yMS9tQ3JSSWZBRUwxT01lakV3d21H?=
 =?utf-8?B?NjdwR3kwOXFFOXo5QW5xV2JWV21Daks0cTVtZXZFVnh4VWRXWUpoM0ZkN1RY?=
 =?utf-8?Q?eOVLUw?=
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)(14060799003)(1800799024)(36860700013)(82310400026)(35042699022)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 09:56:47.3394
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7fcd523d-baa7-45e4-531c-08dd9916f756
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:
	AMS0EPF0000019D.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB11165

SGkgTWljaGFsLA0KDQo+PiArDQo+PiArLyoNCj4+ICsgKiBTZXQgbGltaXQgYWRkcmVzcyBvZiBN
UFUgcHJvdGVjdGlvbiByZWdpb24uDQo+PiArICoNCj4+ICsgKiBAcHI6IHBvaW50ZXIgdG8gdGhl
IHByb3RlY3Rpb24gcmVnaW9uIHN0cnVjdHVyZS4NCj4+ICsgKiBAbGltaXQ6IGV4Y2x1c2l2ZSBh
ZGRyZXNzIGFzIGxpbWl0IG9mIHRoZSBwcm90ZWN0aW9uIHJlZ2lvbi4NCj4+ICsgKi8NCj4+ICtz
dGF0aWMgaW5saW5lIHZvaWQgcHJfc2V0X2xpbWl0KHByX3QgKnByLCBwYWRkcl90IGxpbWl0KQ0K
Pj4gK3sNCj4+ICsgICAgcHItPnBybGFyLnJlZy5saW1pdCA9ICgoKGxpbWl0IC0gMSkgJiB+TVBV
X1JFR0lPTl9SRVMwKQ0KPiBNaWdodCBiZSB3b3J0aCBhZGRpbmcgYSBjb21tZW50IHRoYXQgUFJM
QVIgZXhwZWN0cyBpbmNsdXNpdmUgbGltaXQgaGVuY2UgKGxpbWl0IC0xKS4NCg0KWW91IG1lYW4g
b24gdG9wIG9mIHRoZSBhc3NpZ25tZW50PyBJ4oCZdmUgcHJvYmFibHkgbWlzdW5kZXJzdG9vZCB5
b3UgY29tbWVudCBpbiB0aGUgcGFzdCB2ZXJzaW9uDQphbmQgdGhvdWdodCB0aGF0IHRoZSBAbGlt
aXQgZGVzY3JpcHRpb24gd2FzIGVub3VnaCwgSeKAmW0gb2sgdG8gYWRkIGFsc28gdGhpcyBjb21t
ZW50Lg0KDQpJ4oCZbGwgZml4IHlvdXIgb3RoZXIgZmluZGluZ3MuDQoNCkNoZWVycywNCkx1Y2EN
Cg0KDQo=


From xen-devel-bounces@lists.xenproject.org Thu May 22 10:01:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 10:01:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993528.1376842 (Exim 4.92)
	(envelope-from )
	id 1uI2kP-0000oN-Ck; Thu, 22 May 2025 10:01:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993528.1376842; Thu, 22 May 2025 10:01: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 1uI2kP-0000oG-9S; Thu, 22 May 2025 10:01:57 +0000
Received: by outflank-mailman (input) for mailman id 993528;
 Thu, 22 May 2025 10:01:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI2kO-0000jJ-Ee
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 10:01:56 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20602.outbound.protection.outlook.com
 [2a01:111:f403:2418::602])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c9cf0111-36f3-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 12:01:55 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DM3PR12MB9350.namprd12.prod.outlook.com (2603:10b6:8:1ae::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Thu, 22 May
 2025 10:01:50 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.019; Thu, 22 May 2025
 10:01: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" 
X-Inumbo-ID: c9cf0111-36f3-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZyYFfofb7RRxU0Neu6+j7sGaHeKOi9bZbBaQvw33NwZ9H0gcAeQ52e0M9JNICLa57r3oS5vMo/ogyLms/LE+85mWqj60OdokNgoWPrEjwWp9R9vG/0TF0d6U9OkLajzmQeJVNZwoosgvWky9xavL1I59rc1s10YZ59q7BOInPHRQVm8SUdNESX8Ir/tfMyTdPrM6yY5meVi4d6hJnScBk+6o7UJv6gIx+ECB+HKs1XrYtwao/96nyYPHz3ZbuH2e4CcviKp9crLXVBITcEQPHF2WesJUscg2KoVyAe6DF12Nj8OwOaQ/Vk5j8nt5DRRjhGU0noOhQuqsdDppWgQt5g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6hyIZAZIXb6CfumXiODnehY590AZP1SGyYkc/rf1q34=;
 b=ihWgoTtGm4V270/P6bFm1sGYZsw4z2K+z7Pmlyzcyiog0mbGI0Al0Eg9qlHwBMarQTMidfJtY4qdpsE29efIO+SKmFp32y+EVvMDDXDLVMvSY68IpP9TZfuOURh1S+k/EG8ai/oJG+XdZracf2ENPk+sKKCTQ2pInpUoK6hZkNh4RfgtvujpE4dquFgk3bXlopWdspBP1x+yUisu+KjbzcNx6YhirchUybFniux0uC6ieRTljuj5GXA3wgBew8Y9Trie9z08XOB0snmZXzfmvD1H/5jwpIFiSMY/wUv3sQSlEs13GzWcG1kX4VLfGOHPvLv1pCZ/dK7B1cfZAXyoOg==
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=6hyIZAZIXb6CfumXiODnehY590AZP1SGyYkc/rf1q34=;
 b=HbByJ8UAZAtoHUksgwBnFjMGRvkbbgdOnCu2aRBq4ZfhkMnnwkmPSrpXywfLbwEiC458ns3rysp4dLG3DTJvvKEAygONyF2YG1l32hOhNEflMwM3SzbdtqTGHNz3t8b/zNEMi81OTO0/tJVLqktCjtGTCbCvgt7lTlcfjWlTeSY=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Thu, 22 May 2025 12:01:46 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 5/6] arm/mpu: Introduce utility functions for the pr_t
 type
To: Luca Fancellu 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-6-luca.fancellu@arm.com>
 
 <14A6545F-F7C5-412B-8A3D-9EFD293D69AE@arm.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <14A6545F-F7C5-412B-8A3D-9EFD293D69AE@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: AS9PR05CA0330.eurprd05.prod.outlook.com
 (2603:10a6:20b:491::10) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DM3PR12MB9350:EE_
X-MS-Office365-Filtering-Correlation-Id: f7838db5-5e84-4937-dba7-08dd9917abb3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VkVhSXk0UTdadHhpQjQ3MDFjeHJnREdKYmxUWmZzRnNybi9RcDFSRWgwQnE1?=
 =?utf-8?B?MEpYMlhzREVQK0djT3ZDcDJqcStiQVBOb1h5SVpkUGdROFRIZlhKUjlIem1p?=
 =?utf-8?B?Um95TGovNTVOeGlwSnBWN2hmN09ndFd0Vm1vdVNudStaaHhrV0xvME5XYWNi?=
 =?utf-8?B?clFOWGRzTEZlNmZrcElNWnVlK3pjRU9BQWJOOVJNeVJhUUhDbnpSRkc4dndR?=
 =?utf-8?B?LzJLZHFiSFZCWWNtSHV2bGE1VkZwTVd3MDVvN1M0SW1tamRWNU9qZEVLNHN5?=
 =?utf-8?B?N1RBRHFVK293U0VYWEpLb0xVVEtWL21nQlg4WUpnY25IemRLUXhWR05KVXc3?=
 =?utf-8?B?c0x0Y1c5ZVdSR0d3Zm5ZUVMzdHJqZnUxeERWYS9aNWNVbmtjNHp5akhEWTlU?=
 =?utf-8?B?YUUva3BFLzNPZGE5OHppZUNITmRqcDYyM2MyU3Q5a3VuZjlic2hrYXRrcWV3?=
 =?utf-8?B?NWtaeGs4Tlp3OFZ3T3NzZ1pnMDV3aDZObWlFSm1MN3RnbEdsRzAwV3FjSmcz?=
 =?utf-8?B?NXZOaDZGQ3hmQ2Viem0zOXo5dVlyUU5qWFpGSFdRK1BxNXZVSW5wS251UHhB?=
 =?utf-8?B?VHpQcUhBOHFvbmpUMjFyN1pKcmNxQXViSXE5L2VuWjdjNmJMNVE4V2NEcHlx?=
 =?utf-8?B?eUZ1dUdDbERLY21UNUtnSFc0YXZ4Tkh2QlNYUEg1Ly9CWHNzWHFPdCtIZjBm?=
 =?utf-8?B?SmJ0UnZHdkRRYS9xWUROcHdheHFnTzQzdjk0RWlIUzQzK0dpV29FRXFHQVEv?=
 =?utf-8?B?K1FFOEpmK1R3WmdBSUVPZ05RbUx5UndxUlREOEo4WHY3TXNPdk1lM2FvMTIz?=
 =?utf-8?B?QUovOUU5VS9jaUlFdnh2bU5wVHNIVDNVNm9NTGVxN0R2MlF1MG1CLy8ySUox?=
 =?utf-8?B?OHJPTGx3TnNITE43MThIQ09CYXBZV3NNNnhOL1ZGY2dsejh2K3lORHB0Yk45?=
 =?utf-8?B?UGs1clR4VE4velRVbE1jT3IyU2tGcko2RHRmTmNndGY5SjlEd2QrTTltTE9x?=
 =?utf-8?B?b0hyaHJNS1pUa1RhZ3ZLb2VkVHhacXFuUmpTYXEwVDlxbVNuSHNockxkWWxS?=
 =?utf-8?B?OHE4Q3pQcXM2K2JVV1RVaHd2YThTdldjTXMyRGkwbStWUDdJTWpqazJnOGI0?=
 =?utf-8?B?U2c5TEIrQm5vMDJUWUFRektxbEpMOTFwS3YxcEh2QWpGQjRqVzdVNHFYcW5k?=
 =?utf-8?B?Y3FXUHBwUjdIMVFiNEdTd2ozcjVXait6SHlDckNMWG9XVG45TnRFUTNTeUFT?=
 =?utf-8?B?UWwvZ254dlVDd1IyYTMrSEpCeEg5ZHZrOUdUZlZpT2ZYV3M4NnlOalJCSG82?=
 =?utf-8?B?TmJMQ0tzbHgvZ2pzdGtIOUE2TVlKbzdiTUp1dzFQOE9tVG9kbktvSEc4amtB?=
 =?utf-8?B?M2JTT1Q1ME1sYTFBSGNUSFphbzhlTmJ3L01CMmFlNjJ3c1JZNkdYOEw1QTRz?=
 =?utf-8?B?T3krQTRRSXBoZTdJK093a2swSDVwSm1RT0JJNUU3aENWeE5BUExJSDE2R1Jy?=
 =?utf-8?B?czhVcW9HcGtGUHh1czB3b21RRk43MTN2bk5MUTB5UHhzaDJiL2hHT3RPTkgr?=
 =?utf-8?B?UzJGT2R6elhibERqUWx1TXc5T3FENnBVSmxSUlZBSUFhRHp4ZURJVFhuNk5T?=
 =?utf-8?B?WVhiZE5Wa3NMTXJDTE5odGZWQS9HYVJkdGdJR2NyL1JMQWJXV0lqWmNMVEJh?=
 =?utf-8?B?dmQ1WEp3QmpIcmdDZjd3U0loSHVyb1hnajVzY0NySitURnZtWU50N3ROT1M2?=
 =?utf-8?B?Q2tUOEVqbEdKWEJrUWlpWHJBZTlPRFIxM1M0T0k4eFdDRVRRVXpWMEdsd09V?=
 =?utf-8?B?WVIwTEFJRml6S3V0RXg0K2hKVGJtZG1hdVNNTkMySERkWjNPcENKdTh3SGdv?=
 =?utf-8?B?NUd2V1ZLbDQ0anN3SnJoSVI4U3hHby9WY3dDQlBzaG5SckYvZWV0VjZkMHZG?=
 =?utf-8?Q?kqXHeg7q8ZI=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Y0VqY3A4Vlgvc3N2cHNZK094eU5Ed2VRUFFvN3Z5dC9wallIRWxmMFZBdVdy?=
 =?utf-8?B?cFZLc1NYRlcxT2YvenVucFkrcWV3SHZoU1FpRUVDaEEwWUh2cXYvbW41alV2?=
 =?utf-8?B?ckxXbzRyR0ljL3UrbkRnWktqckQrMUNSMVlGSi9LQWZ2WTZmeXBUTjRvaGdo?=
 =?utf-8?B?WFYvV0xEYlIzL3pNeVR0ZlRSQTNNTnBxek1PNXhnUis4ZnpRcng0MG9NZXhF?=
 =?utf-8?B?NGl3SjVZbEtYSjJOZC8xd2ZNV29xN283Z0xNMkdBLzl4YWxkQ1o0Z1lWVmdu?=
 =?utf-8?B?NDg3QlFab2h6ejF5UVE1a0hZaW1PRzg4YXFYcGIwN2R0eGdsL0N2QU1xNzNI?=
 =?utf-8?B?dHdsVHNiQ2U2NE5hMTkxVVdCazczOFZHMWJkNHJzM3M4K3pubzh0QU5YT3FK?=
 =?utf-8?B?V28vV0lrMXJIVGUyc00veUJjWXIxRWZLL2cyMlk3czlWazk0VEFHcnYzZU0z?=
 =?utf-8?B?dlJaYlllVFQyT1lidXlyZTBnNmVwY2ZiRkpNZFBZL1NBQ0w3OENBckt2UWpM?=
 =?utf-8?B?U0JhOWVqa2k0RENxMmZ2OXRmRG1kZTRHN2I4OFdkVkZQTXBQOGtwQVhPejM4?=
 =?utf-8?B?cVo5WlYyc0VSa05LeWVrVnVqM25sL3hFSzBEN1ZjTkw4VjZ6Y2VzVkxuQWFq?=
 =?utf-8?B?Z1JzcGZ3dU5HbmdVaUVsdVowNWZYb2NPUCtuSGMzTkordHByQ2h6M0M1YXla?=
 =?utf-8?B?bWI3c0FLdm5NY0laN2pJcVFsQ1pKR25OL2h2RVhiK1M3Q0xwcCtGd0tVQVFX?=
 =?utf-8?B?VUpjRFhMaTRPY3ZvZW56eXVOazdXRTBZaUVKUjlXWWtvMzlSWmcxTUJpUCtW?=
 =?utf-8?B?azBEcEZxMDFOaWlCU3gzeWlIQXo3V09mT3l4WE5BU25INEZmdDZhVG1HVE5r?=
 =?utf-8?B?Mk9aamZvbTRFMUM3eWNrbmRKbTlRTUJwVVZLL2E4MVJFb1dleC9XSm5BMWEy?=
 =?utf-8?B?Vmk3aWhmbjJiZEhqYTBCcmY2bXMwMkVUM3pvc09qc2NPL0JaUHBNTC9SVmdx?=
 =?utf-8?B?elBzYjFJa1BVbFhoWGJGVGE1NFFROGc5WDBvaXEyeklOWnF3bmVGR0JGVGxI?=
 =?utf-8?B?NXBkU3YvcVdNRjJzaHZ3S21XaG5STGRkMlpFV2VQWXNZSUJEMlpxaGV4V1Bn?=
 =?utf-8?B?U0Z6ZzkrV21UYzZUQ2JiM21qaDlra3U1ZzBxMnlaMlJGK1RERTUzVDh1Tkto?=
 =?utf-8?B?Q2RiQ1o1VzIvb2IxTTN2SzkrMGFOQkhsYlc3MU42aFE0RGQ5azlSMHhVQldt?=
 =?utf-8?B?ZU9mVVNSK3RYT1grVURHZ2tqdHZUbmlsdjdlRkFMQ1MzejZhK3d0OXB1bVp4?=
 =?utf-8?B?UFZLN2lhUDd5d0ZFZjc5VFVvN3JjK1dvcGxpaFJmbUU4SE1KajcrSjBrWXFs?=
 =?utf-8?B?VlExdWxBVGhrM05iYXh3aVJrM1BnQWVUQmlMMUp2QktqSnhHN1pQLzRCV0tt?=
 =?utf-8?B?bHQvN3FHSjFkOGJBTUJLOURQdHVTNW5tZGZQVDV6T2dxYW1ZVWVRRlFjV2pG?=
 =?utf-8?B?akRGS25XM3BNaXkvb0ZUWnNKOVQwSjNncFEwa1BkY294QzBKOW81VllYQ3cv?=
 =?utf-8?B?eE1sWDN0c1p6T3k0SGhPNXQ1VE5jOUtXakJJcTBjOVRmS3FCOTZNVTE1emlz?=
 =?utf-8?B?RXNUUmJyaXNiWGF1cVU4R2tMam1QQ2JhV0ppSUtkZWsxRGlKQmZPOW9jN2Ns?=
 =?utf-8?B?UGptK3NFSzRqZUkxbFVIR0R4TFFhdkN1VHh6cThrSXNuZFFFVUhZOWxXM2t0?=
 =?utf-8?B?VWQ5VGdadnRWSDlSQjhNZC9XbVk0ZWFBOHBMUXUxOXRNZWx2NkFROW12MjdY?=
 =?utf-8?B?OVpmbThmY1dZbURMQTd3UU1NQW1nK0p1VGlHMkprU1BxZ2hpVEc3blVMNlFy?=
 =?utf-8?B?ZUQ1VWNQVVFhM3RDcm9xQjJmNWlHU3B6TXJwMUdZOFpQeGpJNjhrck9tZ3cr?=
 =?utf-8?B?NkZEYXZCZldHRUxsRG9aWFYxZ3YvaEptdVdEVi9nUWtIWDMwSmNoM2IrR0g1?=
 =?utf-8?B?VElYYUhUQkMvekRXZFcyQU0zL0VMWi9lTnRkN1poU0wvd1BvK1Y4TjRiZ21W?=
 =?utf-8?B?djVucm1Nb0NGYXR3SDZFSk9CWXQvTU5BdVMvdVR6MWVuUGxzazk3RHBEazll?=
 =?utf-8?Q?AE0Q=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f7838db5-5e84-4937-dba7-08dd9917abb3
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 10:01:50.2639
 (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: KtwS31M9x/SQs/0eHBJRPM9O5kOmxhq1fLiwFfy9hGYg6NuEYX2xXaj1hmiHJ7+/
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR12MB9350



On 22/05/2025 11:56, Luca Fancellu wrote:
> Hi Michal,
> 
>>> +
>>> +/*
>>> + * Set limit address of MPU protection region.
>>> + *
>>> + * @pr: pointer to the protection region structure.
>>> + * @limit: exclusive address as limit of the protection region.
>>> + */
>>> +static inline void pr_set_limit(pr_t *pr, paddr_t limit)
>>> +{
>>> +    pr->prlar.reg.limit = (((limit - 1) & ~MPU_REGION_RES0)
>> Might be worth adding a comment that PRLAR expects inclusive limit hence (limit -1).
> 
> You mean on top of the assignment? I’ve probably misunderstood you comment in the past version
> and thought that the @limit description was enough, I’m ok to add also this comment.
The comment says that the address must be exclusive. The code then transforms it
into inclusive before the write, so one might wonder why.

~Michal



From xen-devel-bounces@lists.xenproject.org Thu May 22 10:02:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 10:02:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993540.1376852 (Exim 4.92)
	(envelope-from )
	id 1uI2l3-0001Mp-KU; Thu, 22 May 2025 10:02:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993540.1376852; Thu, 22 May 2025 10:02: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 1uI2l3-0001Mg-Hq; Thu, 22 May 2025 10:02:37 +0000
Received: by outflank-mailman (input) for mailman id 993540;
 Thu, 22 May 2025 10:02:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI2l2-0001Jv-VF
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 10:02:37 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20610.outbound.protection.outlook.com
 [2a01:111:f403:2415::610])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e0fbafc7-36f3-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 12:02:33 +0200 (CEST)
Received: from MN2PR17CA0019.namprd17.prod.outlook.com (2603:10b6:208:15e::32)
 by CY5PR12MB6177.namprd12.prod.outlook.com (2603:10b6:930:26::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.31; Thu, 22 May
 2025 10:02:29 +0000
Received: from BL02EPF0001A102.namprd05.prod.outlook.com
 (2603:10b6:208:15e:cafe::23) by MN2PR17CA0019.outlook.office365.com
 (2603:10b6:208:15e::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.29 via Frontend Transport; Thu,
 22 May 2025 10:02:29 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A102.mail.protection.outlook.com (10.167.241.134) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Thu, 22 May 2025 10:02:28 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 22 May
 2025 05:02: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" 
X-Inumbo-ID: e0fbafc7-36f3-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jlFpmVnyYiluJhtJz/diImoQXgYGlV4Ik4u6zdIwwXEAXzXUrdNYGiXaO8Q6FlG+clturrTUVL2lkiTJjFaPyJ5TlRzMdzONPohPh4FtqK2Q4mn7zzd7AIbrovrzh4MMWojp6xMR7ZHy/M+v+emkGuh1JOadLM+ATzq6kz9DDDlNjLsCxez5PlHnOevLibvsjdkXtfYb2N27mTZtQC8lRS2YU00Kp6QxIWORGePplWi69GhWWdBpinGJSj0Cev59I+9fBxKAT44BPu/QCZojEOXjZSqAYOKO7JI3RZHjUp9eQoEwCBhoqrTSQF8AdHmMO7asBjIkGmcRzrY6cMm/bA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PDuwohqFm9W06N3m1OX1PgjDeBTjdxPpYim1t1NuvIc=;
 b=mB89g5qLFRJLADfT8gDnA8lEw4mGsJJRyCK4FN3vURAhxcohxksazeXggd4aNL/fC0DIBef+7TEsm0XSNqz9iKmFx0PCyaIKmtIC04zYxpKM3L1FaDXtI4CZm6X/I6h8Wvs0Mcq7eBbtXtNtYTO46vWXUq4GCns6515ZLoXMOr82fhREJ17TJ+G3sKsw2C0NRhW0BDKfQ94QwuAZWyfRDoHKbKfzWhMTltCLiAQtaH/S23VQAeEaxDHjVrA3TeV2pxP+QYxlmxL07EFKiAOn1AIifEEdOpnVXerDJfr5PZPo4AA3xQDWhkexqrAAH5ouuxIiox8juhZUIq5qnLEXVQ==
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=PDuwohqFm9W06N3m1OX1PgjDeBTjdxPpYim1t1NuvIc=;
 b=R0m5xPFMfQNQKtrG7c3CTSlmh39qHUNOz3GRpkvffH+a5WAgXHFLh6z7AvoMcQp1haySkSTmzMFB7MuZlClC+hQkCyEA9FsSfHlOOWYbckmulRBwNzeKHf/P1wuwQnr20cqCtyXKA+FqdYgd/UEoqs4MmWNWGkSZSL5yBf4LS9U=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 22 May 2025 12:02:25 +0200
Message-ID: 
From: Alejandro Vallejo 
To: "Daniel P. Smith" , Xen-devel
	
CC: Xen-devel 
Subject: Re: Hyperlaunch Device Tree Discussion
X-Mailer: aerc 0.20.1
References: <85d65163-6120-4653-8ed5-e7752ae7ce48@apertussolutions.com>
 
In-Reply-To: 
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A102:EE_|CY5PR12MB6177:EE_
X-MS-Office365-Filtering-Correlation-Id: 279692b0-7a0f-4fc1-81ec-08dd9917c297
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eHppR2JmdTBMVUpic1RCeVRVUUpxRnhxTDdNbDRDODJXNUpGU29jNndZVHVw?=
 =?utf-8?B?Ty85bGR6a1VGQTZuSTQ5MFdIRUkweFFvcVdEYjYxdkgwanMxT0J4bUUyMXJ1?=
 =?utf-8?B?UEdhbktkSFJYUDEwUkRScFZGaHpTV1RaV3FraFBFVVQzem5kV3NpdU1uTytM?=
 =?utf-8?B?OVdsQXNFcGdMQVJ1TCtGMG43cmwzeDBuQmlMUXVDZGpxUm1lUkp5RjhOT0hq?=
 =?utf-8?B?UFh4MHlObnRFZWVaYVUycTU4QVQ0MWJBQ3lRVTZPMVR5ZGNwNDVBUkFvMUM2?=
 =?utf-8?B?WGJiNm1vV2ZuZDdpK21jMEhPMWpHQVRXaFk2cjhwYXdUUzR6V2NrTzBudTE1?=
 =?utf-8?B?bklhWk1WbzdCclRjWVgxSHo1eXhXRjBkYVlaZzZMWm1Fc3d3MDBJVTViVzk4?=
 =?utf-8?B?S0k0Vm0zdmlzVHZ0c2lrdzJsMTVSR1p3R3l3eWNGVHpBbFczK2EwZjk1TkRU?=
 =?utf-8?B?OEpML2xlVEpnNFl3ays2YjVOelhRTWVpNmZGMGNlVmxSQ21wUXozWHlxY2FM?=
 =?utf-8?B?V2hGMlc3NWhHNFVXSXlqN3BNWk1SR0V2RE50SUg0d3hhVTEyOVI4Q3hmQkxH?=
 =?utf-8?B?cGRDVTF4Y1RoQmpXSmdMWE9oUHRsOGVQb0g2ZlFKbld6VTQzV21xYytKVWhG?=
 =?utf-8?B?VFoxZ050Mk1vNFpkTlkvbTR6SGRyMkcxUFhCdmFQRGRuUGJxRjJ4YXVKYVpy?=
 =?utf-8?B?a2l1Y2wrWTgycVNxSEpXRVZIK200T3pLTUFtOWJKNXBMZTdVd3VOK0FWcEw2?=
 =?utf-8?B?QzQzUmtoUWMwN3hzVE5haVVMbTE5Y2pFSWE0OEw0NFdoeDRlczVhaFc2R3NW?=
 =?utf-8?B?TnRTcHVUZGFxYnVNcEh3RTdnOEE1R1RPbTRjdGZYTDNnWmlCdnNMVGU0YVJq?=
 =?utf-8?B?RjB0RjIrRDJvL3ppYk1YZTJlTkQrbmE4SFhVbzJBa3p1UllRdmpUU0tKQ0c3?=
 =?utf-8?B?VmxER2t3THdObG40MW9nL1YyclpUK3hsaDM0b09VTVEzRWxkcWtPMS9PdlFG?=
 =?utf-8?B?OXdqdThIUVV6QWVzUklLSjVhUlVUeGFqNkljMjdGdVlKNDJRMDVYSVNVQlpM?=
 =?utf-8?B?SzV0NlRFY3ZxTWZqU3ZWeTBwaHlSeEg2RitZa0taSFkyNHBjWXZMTnBWaUd4?=
 =?utf-8?B?aWZaVW5ScVJZRmk3czJRUXRuemJ0eGFOeTlUcUZNb3lmb2FvSmZpRW5sNmFI?=
 =?utf-8?B?NVF2ait6RFc0a2d0QUp5ZVRTMXJsK3FvdTNjdXNqdVgzUUhob1NyQWRTcmc3?=
 =?utf-8?B?cFZxRXpEOXJ2ZitzYW5QeVEzejRYaXNybG9YY1A4TUxFc0hEYVdPYUZrbXRB?=
 =?utf-8?B?MWhRQ2t0SGRUNGtUenhSajFxdW84a3dVUFp1ME9WL3JnNkhpRk1wNDVJWHFo?=
 =?utf-8?B?NlFKZS9TMkZ1Y2k0c3BRRkZjaTRRdkhwcTdRTVlPcXd1eWg3Q0E5RU15djJC?=
 =?utf-8?B?MUwvU3pmMEVhRWU1bXhkZmJDRTFJN0dmTmtCL2VVazc2alg4dndzQWgxWE1X?=
 =?utf-8?B?TDd5OXJJSHRGM0Z4dTlaaVF4WG9QWERiR3lFNEZnQ2tKZ0ZxY2VOUzNzS2U0?=
 =?utf-8?B?UE9nVTRkV3NBaE05N05NYWY3OGRvSkFheGRPdkpCWlFZN25pa1EwenIwRG80?=
 =?utf-8?B?Nzk5S1pGOEdTM2hqSkJyZUYwRHMwYjBSclI3SkNGM05JcDNJWW55bXZLM0tR?=
 =?utf-8?B?QURIQXUyV01KQVp3bVJFK3ZrRDB3allKUnVHK1gyTHU4Q3haaDJzQTBtSmZD?=
 =?utf-8?B?eG1Tc01zS0VGa09oVVBVTXlxRE5oajlNZVVFaVJjQkR5b2ZYZ0VzMC9CRDVw?=
 =?utf-8?B?d2NkTlVQTkVzZ0ovOUVxS0x2Zk5aejhoaHd4alMxdTlqUlhwUlpXT2N1R2Fx?=
 =?utf-8?B?YXNHdzVSSlRCclZBdmdMNnhGR29SaGtNZnFodVNjVEoxWUpUS0RTZXBMVFdV?=
 =?utf-8?B?UXF3b2ltS2wwOGNER2FmTm43aHZCRUxjaFRIU3RHNVdrL243SzZJWlhaTG9S?=
 =?utf-8?B?V25PMWlMb0FlemFFcFZBTG9UWU5oRXdKeU1lQWY5VjF5REt1UzB2S1gyYWhi?=
 =?utf-8?Q?fVhfhb?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 10:02:28.4047
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 279692b0-7a0f-4fc1-81ec-08dd9917c297
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A102.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6177

On Wed May 21, 2025 at 5:39 PM CEST, Daniel P. Smith wrote:
> Greetings,
>
> Per my response to Allejandro's message, here is the response sent the=20
> the DTB working group formed last year to discuss DTB parsing for x86.
>
>
> Original Message:
>
> I have copied everyone that attended the hyperlaunch working group a few=
=20
> weeks back to ensure everyone has a chance to review and comment.
>
> As a start and to provide a common understanding, first is a quick=20
> overview of Flattened Device Tree and Xen's "Unflattened Device Tree".=20
> The intent is to assist everyone in having an equal footing when=20
> considering the impacts that Device Tree parsing brings.
>
> A Flattened Device Tree (FDT) is a nested linear tree structure that=20
> uses a combination of tags, layout definition, and headers to allow=20
> navigation through the tree. Because the layout is nested, if given the=
=20
> offset for a node in the FDT, it is possible to start at that node and=20
> jump directly into the tree to access child nodes and properties.=20
> Provided below is a visual representation of what any parent node,=20
> including the root node, may look like:
>
> +------------------------------+
> | NODE TAG (parent node)       |
> +------------------------------+
> | Null-term String (node name) |
> +------------------------------+
> | PROPERTY TAG                 |
> +------------------------------+
> | struct property {            |
> |   u32 len                    |
> |   u32 name_offset            |
> | }                            |
> +------------------------------+
> | Property Data                |
> +------------------------------+
> | NODE TAG (child node)        |
> +------------------------------+
> | Null-term String (node name) |
> +------------------------------+
> | PROPERTY TAG                 |
> +------------------------------+
> | struct property {            |
> |   u32 len                    |
> |   u32 name_offset            |
> | }                            |
> +------------------------------+
> | Property Data                |
> +------------------------------+
> | END NODE TAG (child node)    |
> +------------------------------+
> | END NODE TAG (parent node)   |
> +------------------------------+
>
> Before moving forward, let us clarify some terminology to ensure a=20
> common understanding when discussing a tree.
>
>   - node path: represents a series of hierarchical child nodes starting=
=20
> at the root node
>   - adjacent node: the logically next node that is at the same level in=
=20
> the tree
>   - child node: a node that is a one level lower leaf to another node,=20
> the parent node
>   - tree walk: incrementally walking the nodes, to locate a specific=20
> node or to iterate over the whole tree
>
> The libfdt library provides handlers for finding the offset of a node,=20
> as well as handlers to jump to a node offset and iterate only on the=20
> child nodes. While the libfdt is fairly optimized, the reality is that=20
> to find a node, the library must do a tree walk starting with the first=
=20
> node written in the FDT. If a node is not a path match at the current=20
> depth, it must cross a null terminated string, all the node's property=20
> entries and all children nodes to reach the next adjacent node. Once a=20
> path match for the depth is found, then the search may descend into the=
=20
> next depth and repeat the process until a match at that level is found.
>
> This brings us to Xen's "Unflattened Device Tree" (UDT), for which I am=
=20
> quoting as I find myself thinking of it in another way, which IMHO is a=
=20
> more descriptive name, which is that it is an FDT lookup index. It just=
=20
> happens that the implementation for the lookup index structure is a tree=
=20
> structure. UDT uses a structure to represent a node and one to represent=
=20
> a property. The node structure is a traditional tree structure with=20
> adjacent and child node pointers. The contents of both structures are=20
> pointers to the respective memory locations within the FDT. As with the=
=20
> FDT, in order to locate a node in the index, a tree walk of the index=20
> must be done. The difference comes when a node is not a path match, to=20
> reach the adjacent node, it only needs to access the node pointed to by=
=20
> the adjacent node pointer of the current node. UDT provides an API for=20
> walking the node tree, walking the property list for a node, and methods=
=20
> for type-interpreted extraction of property values. NB: the=20
> type-interpreted extraction API is codified around taking a UDT property=
=20
> structure, but the interpreted extraction logic isn't UDT specific as it=
=20
> is still reading the property value from the FDT.
>
> The benefit UDT brings is when repeated node lookups and/or repeated=20
> phandle dereferencing are done. For both FDT and UDT, a tree walk must=20
> be done. The walk will start with a node, either the root node or one=20
> for which a reference has already been found, walking each adjacent node=
=20
> and descending into a node's children when a path match occurs. For=20
> phandle dereferencing, the benefit is greater due to the fact that when=
=20
> indexing the FDT, phandles get dereferenced, thus allowing direct=20
> reference in the index. For comparison, a phandle dereference using=20
> libfdt does a walk of the tree to find the node referenced by the phandle=
.
>
> The UDT, as implemented, is not without cost. The current implementation=
=20
> takes two complete walks of the entire FDT using libfdt. The first pass=
=20
> is to obtain the amount of memory that is required to allocate enough=20
> instances of the UDT node and property structures to represent the full=
=20
> tree. The second pass is when the FDT nodes and properties are indexed=20
> into the UDT.
>
> With the expense of using FDT and UDT established, it is important to=20
> put that expense into context. Consider hyperlaunch on x86 where the=20
> arch itself has no DT requirements. In all likelihood, an FDT=20
> constructed for this arch would only contain the nodes necessary for=20
> hyperlaunch. If hyperlaunch were constructed x86 only, loading the=20
> configuration could be done in a single full walk of the FDT, even when=
=20
> considering phandle usage. The reason this is true for the phandles=20
> case, is that as nodes known to be a phandle target are encountered,=20
> their offset into the FDT could be stored with dereferencing resolved=20
> post walk.
>
> For DT based archs, currently accepted costs are two FDT node lookups=20
> along with the two full walks to construct the UDT. These first two node=
=20
> lookups being the memory allocation table and the Xen command line. As=20
> noted above, an FDT node lookup requires a walk of the linear tree until=
=20
> the node is located. AIUI at this point is that the number of nodes that=
=20
> must be crossed is indeterminate. I did not see anything in the device=20
> tree specification that the FDT must be packed in the same order as the=
=20
> string representation. NB: I have not reviewed the DT compiler to see if=
=20
> it optimizes for early access nodes to be packed at the beginning of the=
=20
> linear tree to reduce the number of nodes that must be crossed.
>
> While the aforementioned strategy for x86 would be optimal for x86, it=20
> is not necessarily the best for DT based archs. Hyperlaunch started, and=
=20
> currently is, focused on the x86 arch, but long term it was always=20
> understood that its more expansive design would be desirable by all=20
> archs. Like anything that moves into common, a slightly less efficient=20
> approach for one platform is accepted for the benefit of a common=20
> implementation that reduces the amount of code while increasing the=20
> number of reviewers.
>
> After listening to everyone's concerns, re-reviewing all of Arm's device=
=20
> tree logic, and considering everything in totality, the conclusion is=20
> that there is a core root cause from with which all the concerns raised=
=20
> flow. First a summary of the main concerns raised,
>
>   - The issue of memory allocator(s) available at the time when the=20
> first FDT walk/parsing occurs.
>   - Overhead of doing a more than one FDT walk to obtain the hyperlaunch=
=20
> configuration when phandles are in use.
>   - Supporting FDT would require the introduction of a=20
> duplicate/competing set of property parsers.
>
> This root cause is due to a design decision difference made for the=20
> hyperlaunch domain builder versus the dom0less domain builder and Arm's=
=20
> approach to device tree parsing. For dom0less, the approach is to walk=20
> the UDT index tree at the domain construction time, which appears to=20
> stem from Arm's need and practice of repeatedly accessing device tree=20
> entries. Whereas x86 has no need for the device tree and took the=20
> approach to do a single walk to extract its configuration into a code=20
> usable structure.
>
> With that understanding, it is believed that these two approaches are=20
> not diametrically opposed and in fact can be blended together to result=
=20
> in a generally optimized approach. The approach will be to conduct two=20
> full walks of the FDT, an early boot pass before memory allocation is=20
> available and a second pass after a memory allocator is set up. Both=20
> passes serve to populate the proposed boot info structure, specifically=
=20
> the scope of these passes are as follows:
>
> Early FDT Walk: (static values)
>   - calculate the space required for the device tree index
>   - count the number of domains defined
>   - Xen command line
>   - XSM policy
>   - arch specific static values, via an arch_early_fdt()
>
> Late FDT Walk: (dynamic values)
>   - construct device tree index, aka "unflattened device tree"
>   - populate boot modules entries (NB: boot modules are expected to be=20
> static array)
>   - store device tree node index for top level index and hyperlaunch node
>   - populate boot domain entries, basis will be device tree index node
>   - arch specific dynamic values, via an arch_late_fdt()
>
> By taking this approach which is constructed around a set of arch=20
> neutral structures will enable another goal of the hyperlaunch series,=20
> which is to move to having a common domain creation/construction logic.=
=20
> Currently, there is a significant amount of duplication in each arch's=20
> branch for boot time construction of domains. It will also allow=20
> removing arch specific code from the initialization of common=20
> infrastructure such as XSM.
>
> V/r,
> Daniel P. Smith

This is helpful context, thanks for digging it up. I'll keep the answers
on the other thread to avoid spreading the discussion.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu May 22 12:01:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 12:01:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993815.1376942 (Exim 4.92)
	(envelope-from )
	id 1uI4bY-0007uY-VB; Thu, 22 May 2025 12:00:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993815.1376942; Thu, 22 May 2025 12:00:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI4bY-0007uR-RE; Thu, 22 May 2025 12:00:56 +0000
Received: by outflank-mailman (input) for mailman id 993815;
 Thu, 22 May 2025 12:00:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI4bX-0007uJ-HE
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 12:00:55 +0000
Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com
 [2607:f8b0:4864:20::c30])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 68dbdc76-3704-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 14:00:53 +0200 (CEST)
Received: by mail-oo1-xc30.google.com with SMTP id
 006d021491bc7-6065251725bso5263313eaf.1
 for ; Thu, 22 May 2025 05:00: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" 
X-Inumbo-ID: 68dbdc76-3704-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747915252; x=1748520052; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=t0jE1d+dj1aqJlckob85ctjFQf41u4ekM7bLajv9lWg=;
        b=Ol3iWFWvV2Feyli0Wbz3Zgi8t5TbJdSrdrBD5kM5Fn2DqDfC5q8Rm8SqulGv4uI3v2
         S06GiN5gQsMPThuNI0RJ8AZSqd1Izs9TLixHT+IbbxUrEPhuxLPevUhhtDefkLevLvtK
         PbUtcHUhiBzqG+m5NRao5qg2u/oD+0a5GzniWzXDEZmnWWEz7bQgWic2fg5gfL7Gizq/
         +URflzLCRI61+A9iFP+2/glJ5gsn8uaLIvHFsUTu74/2bTr5vS/mTL+GTQpnIH8dkpBZ
         wKc2Jsa1TAGsO3vY24WsprXNH4Nf8mrA3o+q+R3lCo7c9gvy2NIqQH5mkWHO2R9ug6+O
         Mpxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747915252; x=1748520052;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=t0jE1d+dj1aqJlckob85ctjFQf41u4ekM7bLajv9lWg=;
        b=WxxdG6/BmdLjkurTH+xt85TNGQdbk+v3Ju2GgN9Hd2JxyGfK0c9LkvqDDUGyw0AvMH
         qlgjlXACb4RKn0J9ml7s6vyPKIgZ2pRcFiOYBGPgMLwP6YVfH0oC+3NnKXunQqao+f4P
         GZeRG/ViMo9vh8pun2GQkVYyNNCmKpSubjlCD3NHYDUMaxYePiErA+OtHsGejj6iry+7
         gMxyFykuhxe6u99laWGIvYsmf5dj0MquEgEGk3WI9r2r/cztZPrV91WKVqF+evSOrw2I
         MQnTM5+DemAb0vD/2OPjqshGEVC1/fEGATEmIA7xHboE+dUq+YMxDxCvhXwwM0wvpxv9
         m/6w==
X-Gm-Message-State: AOJu0Yw9fzx5GKPVNlqhXbeaBUvRoUrHuZVKoNnvKAUWWatVg2IasALA
	9yeTo8EXsXb0T8BmehyyhzEEsvo+Y+mjh6kXU4vJAp9q1QQWVQevQ92is3Ot2KbAYrnyZjeNnvm
	3QnoSqKJHuIxxL4ciJlSkMiIaZgzOaWpZvGu1mVYIxw==
X-Gm-Gg: ASbGncsgZwLV69NYeXjBcLUvlONlJsmztVlKRiTyu+9U+7n8RHS9tOfy88iOmg13YXD
	96HbT8BliPjuyap6HCbhrzrffZnxU6BNOyeNJm2V5DyKny5nIFGCp53OCWfvM0S0tAXuvhOiyfl
	HFNDObnYer693DjrQwubxxkNAPJ21u16ybsg==
X-Google-Smtp-Source: AGHT+IEs9ijzmYMadIx8/CsvSaL2OprLQIPbSRo1y19l4Q/MMeIk57HgwvmgGGPUvtrre0Zy5nh4BfVIfhODPgQhMOg=
X-Received: by 2002:a4a:c38d:0:b0:609:f8f1:ce72 with SMTP id
 006d021491bc7-609f8f1d126mr9942167eaf.1.1747915251774; Thu, 22 May 2025
 05:00:51 -0700 (PDT)
MIME-Version: 1.0
References: 
 
 
  
 <54AE155E-5D83-4C45-B21C-7BB264ADB7E9@arm.com>
In-Reply-To: <54AE155E-5D83-4C45-B21C-7BB264ADB7E9@arm.com>
From: Jens Wiklander 
Date: Thu, 22 May 2025 14:00:40 +0200
X-Gm-Features: AX0GCFvYwc_Rsismc8yTv_iyWWWmXuSYMwTEKrcgTBNoVNQjmQh_lCdebJgEjDY
Message-ID: 
Subject: Re: [PATCH v5 6/6] xen/arm: ffa: Enable VM to VM without firmware
To: Bertrand Marquis 
Cc: "xen-devel@lists.xenproject.org" , 
	Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Michal Orzel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bertrand,

On Thu, May 22, 2025 at 11:11=E2=80=AFAM Bertrand Marquis
 wrote:
>
> Hi Jens,
>
> > On 22 May 2025, at 10:30, Jens Wiklander  wr=
ote:
> >
> > Hi,
> >
> > On Thu, May 22, 2025 at 10:18=E2=80=AFAM Bertrand Marquis
> >  wrote:
> >>
> >> Hi Jens,
> >>
> >>> On 22 May 2025, at 10:00, Jens Wiklander  =
wrote:
> >>>
> >>> Hi Bertrand,
> >>>
> >>> On Wed, Apr 16, 2025 at 9:40=E2=80=AFAM Bertrand Marquis
> >>>  wrote:
> >>>>
> >>>> When VM to VM support is activated and there is no suitable FF-A sup=
port
> >>>> in the firmware, enable FF-A support for VMs to allow using it for V=
M to
> >>>> VM communications.
> >>>> If there is OP-TEE running in the secure world and using the non FF-=
A
> >>>> communication system, having CONFIG_FFA_VM_TO_VM could be non functi=
onal
> >>>> (if optee is probed first) or OP-TEE could be non functional (if FF-=
A is
> >>>> probed first) so it is not recommended to activate the configuration
> >>>> option for such systems.
> >>>>
> >>>> To make buffer full notification work between VMs when there is no
> >>>> firmware, rework the notification handling and modify the global fla=
g to
> >>>> only be used as check for firmware notification support instead.
> >>>>
> >>>> Signed-off-by: Bertrand Marquis 
> >>>> ---
> >>>> Changes in v5:
> >>>> - init ctx list when there is no firmware
> >>>> - rework init a bit to prevent duplicates
> >>>> - Remove Jens R-b due to changes done
> >>>> Changes in v4:
> >>>> - Fix Optee to OP-TEE in commit message
> >>>> - Add Jens R-b
> >>>> Changes in v3:
> >>>> - fix typos in commit message
> >>>> - add spaces around <<
> >>>> - move notification id fix back into buffer full patch
> >>>> - fix | position in if
> >>>> Changes in v2:
> >>>> - replace ifdef with IS_ENABLED when possible
> >>>> ---
> >>>> xen/arch/arm/tee/ffa.c       |  24 ++++++--
> >>>> xen/arch/arm/tee/ffa_notif.c | 104 ++++++++++++++++-----------------=
--
> >>>> 2 files changed, 67 insertions(+), 61 deletions(-)
> >>>>
> >>>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> >>>> index c1c4c0957091..b86c88cefa8c 100644
> >>>> --- a/xen/arch/arm/tee/ffa.c
> >>>> +++ b/xen/arch/arm/tee/ffa.c
> >>>> @@ -342,8 +342,9 @@ static int ffa_domain_init(struct domain *d)
> >>>>    struct ffa_ctx *ctx;
> >>>>    int ret;
> >>>>
> >>>> -    if ( !ffa_fw_version )
> >>>> +    if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !ffa_fw_version )
> >>>>        return -ENODEV;
> >>>> +
> >>>>    /*
> >>>>     * We are using the domain_id + 1 as the FF-A ID for VMs as FF-A =
ID 0 is
> >>>>     * reserved for the hypervisor and we only support secure endpoin=
ts using
> >>>> @@ -579,11 +580,8 @@ static bool ffa_probe(void)
> >>>>        goto err_rxtx_destroy;
> >>>>
> >>>>    ffa_notif_init();
> >>>> -    INIT_LIST_HEAD(&ffa_teardown_head);
> >>>> -    INIT_LIST_HEAD(&ffa_ctx_head);
> >>>> -    init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NU=
LL, 0);
> >>>>
> >>>> -    return true;
> >>>> +    goto exit;
> >>>>
> >>>> err_rxtx_destroy:
> >>>>    ffa_rxtx_destroy();
> >>>> @@ -592,6 +590,22 @@ err_no_fw:
> >>>>    bitmap_zero(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
> >>>>    printk(XENLOG_WARNING "ARM FF-A No firmware support\n");
> >>>>
> >>>> +exit:
> >>>> +    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) || ffa_fw_version )
> >>>> +    {
> >>>> +        INIT_LIST_HEAD(&ffa_teardown_head);
> >>>> +        INIT_LIST_HEAD(&ffa_ctx_head);
> >>>> +        init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback=
, NULL, 0);
> >>>> +    }
> >>>> +
> >>>> +    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> >>>> +    {
> >>>> +        printk(XENLOG_INFO "ARM FF-A only available between VMs\n")=
;
> >>>
> >>> This should only be printed if ffa_fw_version =3D=3D 0
> >>
> >> Right i will fix but ...
> >>
> >>>
> >>>> +        return true;
> >>>> +    }
> >>>> +    else if ( ffa_fw_version )
> >>>
> >>> The else isn't needed.
> >>
> >> the else is needed so that we return true and not false.
> >
> > I meant the "else" isn't needed, the "if" is still needed, as you expla=
in.
> >
> >>
> >> We have 3 cases:
> >> - firmware is there: return true
> >> - firmware not there but vm to vm enable: return true
> >> - otherwise: return false
> >>
> >> I will modify it like this to make it clearer:
> >> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> >> index 57b648a22840..768b4e9ec968 100644
> >> --- a/xen/arch/arm/tee/ffa.c
> >> +++ b/xen/arch/arm/tee/ffa.c
> >> @@ -601,13 +601,13 @@ exit:
> >>         init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, N=
ULL, 0);
> >>     }
> >>
> >> -    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> >> +    if ( ffa_fw_version )
> >> +        return true;
> >> +    else if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> >>     {
> >>         printk(XENLOG_INFO "ARM FF-A only available between VMs\n");
> >>         return true;
> >>     }
> >> -    else if ( ffa_fw_version )
> >> -        return true;
> >>
> >>     return false;
> >> }
> >>
> >> Tell me if you agree.
> >
> > Yes, this is an improvement. A return at the end of an if block makes
> > the eventual following "else" redundant. I suppose there are coding
> > styles where it's still preferred. I'm not sure if that applies in
> > Xen, though.
>
> I now get what you mean and you would like the return false to be in a el=
se.
>
> Relooking at the code, i actually do not like the fact that we do so much=
 in
> exit and i think i can move a bit the code to be clearer:
> - put the fw init in a sub function
> - create a vm_to_vm init function
> - in probe call both functions and do the common init part if at least on=
e succeded

I was starting to think along those lines, too. :-)

>
> Something like this:
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 57b648a22840..42dfc71a12d7 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -478,38 +478,12 @@ static void ffa_init_secondary(void)
>      ffa_notif_init_interrupt();
>  }
>
> -static bool ffa_probe(void)
> +static bool ffa_probe_fw(void)
>  {
>      uint32_t vers;
>      unsigned int major_vers;
>      unsigned int minor_vers;
>
> -    /*
> -     * FF-A often works in units of 4K pages and currently it's assumed
> -     * that we can map memory using that granularity. See also the comme=
nt
> -     * above the FFA_PAGE_SIZE define.
> -     *
> -     * It is possible to support a PAGE_SIZE larger than 4K in Xen, but
> -     * until that is fully handled in this code make sure that we only u=
se
> -     * 4K page sizes.
> -     */
> -    BUILD_BUG_ON(PAGE_SIZE !=3D FFA_PAGE_SIZE);
> -
> -    printk(XENLOG_INFO "ARM FF-A Mediator version %u.%u\n",
> -           FFA_MY_VERSION_MAJOR, FFA_MY_VERSION_MINOR);
> -
> -    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> -    {
> -        /*
> -         * When FFA VM to VM is enabled, the current implementation does=
 not
> -         * offer any way to limit which VM can communicate with which VM=
 using
> -         * FF-A.
> -         * Signal this in the xen console and taint the system as insecu=
re.
> -         * TODO: Introduce a solution to limit what a VM can do through =
FFA.
> -         */
> -        printk(XENLOG_ERR "ffa: VM to VM is enabled, system is insecure =
!!\n");
> -        add_taint(TAINT_MACHINE_INSECURE);
> -    }
>      /*
>       * psci_init_smccc() updates this value with what's reported by EL-3
>       * or secure world.
> @@ -528,11 +502,6 @@ static bool ffa_probe(void)
>          goto err_no_fw;
>      }
>
> -    /* Some sanity check in case we update the version we support */
> -    BUILD_BUG_ON(FFA_MIN_SPMC_VERSION > FFA_MY_VERSION);
> -    BUILD_BUG_ON(FFA_VERSION_MAJOR(FFA_MIN_SPMC_VERSION) !=3D
> -                                   FFA_MY_VERSION_MAJOR);
> -
>      major_vers =3D FFA_VERSION_MAJOR(vers);
>      minor_vers =3D FFA_VERSION_MINOR(vers);
>
> @@ -584,7 +553,7 @@ static bool ffa_probe(void)
>
>      ffa_notif_init();
>
> -    goto exit;
> +    return true;
>
>  err_rxtx_destroy:
>      ffa_rxtx_destroy();
> @@ -593,23 +562,59 @@ err_no_fw:
>      bitmap_zero(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
>      printk(XENLOG_WARNING "ARM FF-A No firmware support\n");
>
> -exit:
> -    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) || ffa_fw_version )
> -    {
> -        INIT_LIST_HEAD(&ffa_teardown_head);
> -        INIT_LIST_HEAD(&ffa_ctx_head);
> -        init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NUL=
L, 0);
> -    }
> +    return false;
> +}
>
> -    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> -    {
> +static bool ffa_probe_vm_to_vm(void)
> +{
> +    if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
> +        return false;
> +
> +    /*
> +     * When FFA VM to VM is enabled, the current implementation does not
> +     * offer any way to limit which VM can communicate with which VM usi=
ng
> +     * FF-A.
> +     * Signal this in the xen console and taint the system as insecure.
> +     * TODO: Introduce a solution to limit what a VM can do through FFA.
> +     */
> +    printk(XENLOG_ERR "ffa: VM to VM is enabled, system is insecure !!\n=
");
> +    add_taint(TAINT_MACHINE_INSECURE);
> +
> +    return true;
> +}
> +
> +static bool ffa_probe(void)
> +{
> +    /*
> +     * FF-A often works in units of 4K pages and currently it's assumed
> +     * that we can map memory using that granularity. See also the comme=
nt
> +     * above the FFA_PAGE_SIZE define.
> +     *
> +     * It is possible to support a PAGE_SIZE larger than 4K in Xen, but
> +     * until that is fully handled in this code make sure that we only u=
se
> +     * 4K page sizes.
> +     */
> +    BUILD_BUG_ON(PAGE_SIZE !=3D FFA_PAGE_SIZE);
> +
> +    /* Some sanity check in case we update the version we support */
> +    BUILD_BUG_ON(FFA_MIN_SPMC_VERSION > FFA_MY_VERSION);
> +    BUILD_BUG_ON(FFA_VERSION_MAJOR(FFA_MIN_SPMC_VERSION) !=3D
> +                                   FFA_MY_VERSION_MAJOR);
> +
> +    printk(XENLOG_INFO "ARM FF-A Mediator version %u.%u\n",
> +           FFA_MY_VERSION_MAJOR, FFA_MY_VERSION_MINOR);
> +
> +    if ( !ffa_probe_fw() && !ffa_probe_vm_to_vm() )
> +        return false;
> +
> +    if ( !ffa_fw_version )
>          printk(XENLOG_INFO "ARM FF-A only available between VMs\n");
> -        return true;
> -    }
> -    else if ( ffa_fw_version )
> -        return true;
>
> -    return false;
> +    INIT_LIST_HEAD(&ffa_teardown_head);
> +    INIT_LIST_HEAD(&ffa_ctx_head);
> +    init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NULL, 0=
);
> +
> +    return true;
>  }
>
>  static const struct tee_mediator_ops ffa_ops =3D
>
> I think this makes the code cleaner as we also get the proper error handl=
ing with goto
> inside the fw probe instead of the previous one which was trying to handl=
e both cases.
>
> What do you think ?

This is good. It's much easier to follow.

Cheers,
Jens


From xen-devel-bounces@lists.xenproject.org Thu May 22 12:02:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 12:02:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993826.1376952 (Exim 4.92)
	(envelope-from )
	id 1uI4d7-0000Ij-8f; Thu, 22 May 2025 12:02:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993826.1376952; Thu, 22 May 2025 12: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 1uI4d7-0000Ic-5J; Thu, 22 May 2025 12:02:33 +0000
Received: by outflank-mailman (input) for mailman id 993826;
 Thu, 22 May 2025 12:02:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI4d5-0000HA-8v
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 12:02:31 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20625.outbound.protection.outlook.com
 [2a01:111:f403:2413::625])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a1dfddf1-3704-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 14:02:29 +0200 (CEST)
Received: from BLAPR03CA0037.namprd03.prod.outlook.com (2603:10b6:208:32d::12)
 by CY8PR12MB9036.namprd12.prod.outlook.com (2603:10b6:930:78::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 12:02:25 +0000
Received: from BL6PEPF0001AB4E.namprd04.prod.outlook.com
 (2603:10b6:208:32d:cafe::eb) by BLAPR03CA0037.outlook.office365.com
 (2603:10b6:208:32d::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Thu,
 22 May 2025 12:02:25 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB4E.mail.protection.outlook.com (10.167.242.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Thu, 22 May 2025 12:02:24 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 22 May
 2025 07:02:22 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1dfddf1-3704-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=No9qwNZEfinG8VZTFYbVUqHk/fE1OEgqu8bNc/y5tuxD0ojCoc9zMrBRqeQt/1PUMFhJA6/8m7xT7pXQE3wTQgKnPqIaUDkiz4LIPlNro6z0yKFAeLhyRNZ3dkvp31U4N1wvDjdlefxYIAWZwH/Nk9YRAca0ZsjXpoB8PUkCCuSgztgq0mR/g2uYBNfN1+gyvx5lbfv/Hj0NAgoderZ9qvAYn4ovvCWQwAJnMwNIP++GEsnRhRavxJX7uuIg53AmuAcxEr7yvECTqooSTmwYaWpMY1Cpg0D4DuhAaPjuUCJWhGARTRdmzmrk0RUsoLKWs8kQiXQvJmXoE+C/oUEbIg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jex+Qt+qWx5kNzevt+0dG6ZIVPt4PtXsw3oH3ptE2Aw=;
 b=CvzP/q374AIrxNy/F1gtda0NxoPSKSALkFc1E6lHPt3tWS0MXJFPyDyepWbqfzhwa6xpnutaCMfro7tH27iSJGPqGLVUlilpJu1+b1prdCO+0qp2GevFdvNGCO7rsa9UexL6JF4iPwiUQjol7h0nXx80V/yg100Sl9SrnGjZgmFj2oFqtlWZ3Ll7y1H0Cv7ga8WtGZbiqu/LLRnY8MQjKOfYJ+a2csp1r57VPLf8Ox4k8uL8v+BNTHKeD4uU3MPqJz26Y6RwBkj88HyzN5wpm7Ivgyiiwna49YV5HNRsmFys5M5HxyuJRBmQVDsMMKrFRj07gs/By5kly8dfmSTxTg==
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=jex+Qt+qWx5kNzevt+0dG6ZIVPt4PtXsw3oH3ptE2Aw=;
 b=2X8SjZbAVYw7f6f6rfhR+0m2MfTD3mVW1ujMpOHTCsqGCZ5aMgFFkV2f2P1HMgDud/BIHVOzZqpmwVt3JExpxcYNoGXm32i1lGDIirb/rb23cQFs5eXjC3HPqUyd3TPpvQSHn4/Bg7ZR6nBeiDI4G8mAqDlGX5NR6O/0f691N9A=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 22 May 2025 14:02:21 +0200
Message-ID: 
To: "Daniel P. Smith" ,
	
CC: Andrew Cooper , Michal Orzel
	, Jan Beulich , Jason Andryuk
	, =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Stefano Stabellini , "Xenia
 Ragiadakou" 
Subject: Re: Hyperlaunch/dom0less code sharing
From: Alejandro Vallejo 
X-Mailer: aerc 0.20.1
References: 
 <958f591f-35ac-4a10-93e2-9301ccfc5353@apertussolutions.com>
In-Reply-To: <958f591f-35ac-4a10-93e2-9301ccfc5353@apertussolutions.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB4E:EE_|CY8PR12MB9036:EE_
X-MS-Office365-Filtering-Correlation-Id: 94a14ceb-1e21-4984-866e-08dd99288417
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?c0VtVXdrZTFheW5NTHFNNUJPeGw5dmpPcEJZVVRUTlBoN04wTTJEUHNIVkRG?=
 =?utf-8?B?NXI5U3NNNC85N20rYXVsQ2owM1VPWnUyVmxFc2ZGbFl0eWZpT3VCQTl5QzFt?=
 =?utf-8?B?bWJNeVN6ZWtvRnZrZnlReWhQWkNlb0JXSS9iUzlieHJxZFRsUEYyd1Z1ZTNR?=
 =?utf-8?B?OHJraiszby9hcTZ4a3R3d0dOOFBocU4vR2tvZk9YcE8xWXJTWStyZDZ5djhG?=
 =?utf-8?B?N3lFWEtybHdFWnVrV0hkY1BRVE5DUG9LKzhyRzFlYk03UUlKcjRhNEYrUHhm?=
 =?utf-8?B?eldlcWZoam5tM3hNYy9JSWF2TEdxck5QQ3ZhRlRHL3g2cWpEZ0xoVUxDSHVM?=
 =?utf-8?B?OTlJeEVZbHlXS2pXcGo3d1o3SzMzdUdONU95eGduQU9nSzlMKzB1bW94ZHRK?=
 =?utf-8?B?K2pBZ3VaWFZQaHFUdWNuU1ZGKzdNaGpmSmF2ZUdwYlEraDNQL0d4QU1RWith?=
 =?utf-8?B?Q2ZSaFF4MTNNYWNGeENRam53TTRab1lhVlhsVlZNcDVicm5VYmNPRE5PR1lB?=
 =?utf-8?B?aFZvVTduWk9VRWdVcXMyQTdaR1dGeTRPL1dVQWdZK3lFTStSVHh3QWZ0Ync4?=
 =?utf-8?B?bTErakUwNzVzS2s2WTVza29Hc3VJclhpMVdGd3JudSt0QnU1UTcrZ2FHNkt2?=
 =?utf-8?B?SUg4cUNkYkZvOEU1amJpUGwyMis5YmdaUjEzbUtGVEJuZjdLWjJqQ0hiQ0JO?=
 =?utf-8?B?Vk9kbm1raUhVV0g1NHY2cmtmSzBJdWJEbklTdjZKWjR4Tm1DNDhnZ1VMV2Zp?=
 =?utf-8?B?ak9LWjlVUVBYQVV5VnkwcU8vNjVuMUdXWDNHQjFLU3pCWm54UmlDM1E4QUxI?=
 =?utf-8?B?eUpQSmFFOXJZdjc0MHBKNmFvSVFCT3BrOCtCZ0YvQ29UcElGQ1pQOFlQd01j?=
 =?utf-8?B?UHZjWHNxZVhYSFlzcnVRZW54d3kzZFczV0ZwaU5DaGdERm9pTk91cVZiamFq?=
 =?utf-8?B?am9yT0pxdDRMQ2c5aDJtTmYzM0UxbnNENjhZTDlXeWhzY2Izd3RQTzlsVUx6?=
 =?utf-8?B?VVp0S1hyaFJVV05XU2tJRzU0MTlyZVJUblUwOTRMM3BnN1Q1L3FaK3oyQ1F4?=
 =?utf-8?B?TFB3cXR6bndXcUcrWGp5c2VEVmlWV2Z0NlhGNjdDLzUrR3dvTi9TT0ZVUDhh?=
 =?utf-8?B?c283SE1YNzBWU2U5R0dsZVVPd1h2ckZBMWU3Q3JNT0FMeE8rMStMR3BFZk5U?=
 =?utf-8?B?eWMxdjlUWDBLekdxMERJdjR2b0EwdC9qZmV4bzByYUttWElnZXBzMFVEeEFS?=
 =?utf-8?B?U05kaGhOWmNNRk9xb1JFNHpBeE9rWnlvL0R3anpYWUI4SHhYMmpKRnlhSU5z?=
 =?utf-8?B?NE9GOUNFODl6clpHeUFjUjZJOGcxN2pFWTk5T1N5aEU0SWZXaTlEQ1ZUYlBG?=
 =?utf-8?B?MWwzZEFUbU9ISHNaTHlmOHJjbWtzNzV3Ulh1emNIVjJTUy8zTU5DRzRxZWs1?=
 =?utf-8?B?V0d6elAvdS9xejVwL0c4TGw5SkEyMWdsU1ZpVDh3a1l2Q1RTMWxpa1I3U2Yv?=
 =?utf-8?B?YTVxbU9YTnI2cms3NTNPZExFa3hRVnFHRXNwM3MwclNvQ1VDQlpITm9RTkF2?=
 =?utf-8?B?NUtOMTJaRnBpeHpVaHZrSzRuWnBNSFZUWngxdzUrcmtSMyswaktDQzVYVTRm?=
 =?utf-8?B?eVVtTTVTU2xEVktaZ09jQXFnMG9zUXllOUR2RjRkOGw4QjRtSk9xS05QWnlu?=
 =?utf-8?B?RHRlUDdSNzJPcVNPM3llcDJTMlZWUDF6MU1WSUQ5L1FnRmRvLzh1K2NoZjFr?=
 =?utf-8?B?S3ZqSnFrd1FjbXdlOEU1VVh0YUdBb3hWMHlCZjhjRWhTMXpRNXRvUkQ5SEh6?=
 =?utf-8?B?WS9QVTYvODRNSktlb2FRY2xSK21mNVAvQitEdlpNYW5WTEpLRXpjNzRiWkFN?=
 =?utf-8?B?WE5uaElyVG9wUDBtRlFmKzl3SDdwMGJBMXR3Z1NET0d5dnVwRkdBYkVOR3M4?=
 =?utf-8?B?MzdCUTQzc1g1T05YRjR1cFY2SlZabXA3VzgvbU1JMnMvNkg0Mlc4eXZKc3N5?=
 =?utf-8?B?Y2FwUWJUWnhBPT0=?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 12:02:24.9888
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 94a14ceb-1e21-4984-866e-08dd99288417
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF0001AB4E.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB9036

Hi,

On Wed May 21, 2025 at 5:31 PM CEST, Daniel P. Smith wrote:
> On 5/21/25 10:35, Alejandro Vallejo wrote:
>> Hi,
>>=20
>> (There's a TL;DR at the end)
>>=20
>> While working on preparing and reworking the hyperlaunch series for
>> upstreaming it's slowly becoming apparent the degree of duplication with
>> dom0less.
>
> Yes, this was by design so that when we got to the point of convergence=
=20
> it would be apparent where the commonalities are and thus be collapsed.

I'd say they are already fairly apparent. So long as we're all in
agreement I'd like to collapse them sooner when the differences are
small rather than later when it'll be a bigger PITA.

I'll prepare and send what I have so far. It'll all be code motion and
non-functional changes to remove struct duplication.

>
>> Oleksii's latest effort to move all that code into common[*] (see
>> ad03faa942b9("xen/common: dom0less: make some...) makes this even cleare=
r.
>> There are 1:1 relationships for every key data strucutre, and by deviati=
ng
>> we're overcomplicating the ability to share code.
>>=20
>>    [*] https://lore.kernel.org/xen-devel/cover.1746468003.git.oleksii.ku=
rochko@gmail.com/
>>=20
>>      dom0less           Hyperlaunch
>>      ------------------------------
>>      kernel_info        boot_domain
>>      bootmodule         boot_module
>>      bootmodule_kind   bootmod_type
>>      membanks                memmap
>>      bootinfo             boot_info
>
> If you go back, you will see less of these differences. A lot of the=20
> variations have been the results of reviewer's request. And that goes to=
=20
> the fact that dom0less was developed with Arm mentality in terminology,=
=20
> eg. memory banks verse memory map.

bootinfo and banks/maps are more complicated to merge (I do want to
merge them, though, but one elephant at a time). All the others can be
merged without much hassle with minor code adjustments.

>
>> The difficulty in code sharing is not just unfortunate from a vague sens=
e of
>> elegance or neatness. Having different code paths parsing the same DT bi=
ndings
>> means it's a matter of time before x86 and all other Xen ports have diff=
erent
>> bindings, which would would only worsen the situation wrt code sharing a=
nd user
>> confusion.
>
> Only if we allowed it,

Granted. But mistakes happen, and if detected late enough you end up
with aberrations like x86's compat layer for hypercall parsing. I know I
don't want to see that kind of thing ever again if I can help it.

> but with that said there are subtleties between the arch that will
> require variation. Such as mode, which is primarily an x86 specific.

Yes. Common code can't mean exclusively common. Fortunately, dom0less in
common gained provisions for per-ach bindings (see arch_create_domUs()
in staging). With those hunks extracted (keeping the arch hook in them),
x86 could use the same, keeping private bindings where appropriate.

>
>> I've been trying to get _somewhere_ in using parts of dom0less on x86
>> and develop a credible PoC that highlights the use of dom0less parsing
>> code paths. The results are interesting.
>>=20
>> While I didn't get to a full integration in the hyperlaunch series as I =
hoped
>> due to time constraints I did get far enough to:
>>=20
>>    1. Replace boot_module, boot_domain and bootmod_type with their dom0l=
ess
>>       counterparts (pending some cleanup).
>>    2. Isolate binding parsing code in common/device-tree so it's dettach=
ed from
>>       the not-so-common dom0less domain building logic in dom0less-build=
.c
>>    3. Do early module kind detection from x86 using code in (2).
>>    4. Do late binding parsing also using code in (2) after unflattening =
the DTB.
>>=20
>> And it works well enough under QEMU to populate boot_info to a first
>> approximation. It's missing hyperlaunch-specific bindings (like "domid"
>> or "mode"), but that's just a matter of adding them to the already
>> existing per-arch binding parser ("mode", maybe, would be a candidate
>> for this) or retrofit them in dom0less ("domid" is a very clear
>> candidate for this) and integrating in the larger series to be able to
>> actually boot domains.
>>=20
>> The PoC does not go all the way due to time constraints, as I said, but
>> I think it goes far enough to convince me it's both feasible and
>> beneficial to go in this direction rather than that of a full
>> reimplementation on x86, specially seeing how Oleksii already aims to
>> have full code reuse on riscv.
>>=20
>> A brave new world would reuse all data (including bootinfo) and code
>> (bootfdt.c/bootinfo.c), but I couldn't get that far, and I don't think
>> I'll be able to in a timely manner. IOW: I compiled-in device-tree.c,
>> but NOT bootfdt.c or bootinfo.c, or any of the others. I merely
>> extracted from those files the binding parsing bits of interest.
>>=20
>> It'd be nice to use them, but the domain construction logic is just too
>> different at present. As for the code I tested with,  I need to do some =
serious
>> cleanup before it's ready for sharing, and even moreso for review, but b=
efore I
>> go through that I'd like to reach consensus on the following points befo=
re
>> investing any more of my time working on the side.
>>=20
>> TL;DR:
>>=20
>> I think we should aim to share binding code wherever possible, using com=
mon
>> datastructures (kernel_info and bootmodule) as dumping ground for the re=
sults
>> of the binding parsing functions. I seek agreement on the following 3 po=
ints
>> for the end goal of DTB multidomain boots on x86 before I start slicing
>> my hacks into reasonable chunks.
>>=20
>>    1. We want common data structures, with arch-specific fields to hold
>>       information from xen,domain DT nodes
>>    2. We want to have a single collection of DTB parsers in the code.
>>    3. We want to operate on the unflattened DTB for the majority of pars=
ing.
>>      (plus a minimal version on the FDT in order to bootstrap, also comm=
on)
>
> As for 3, I can repost my original analysis that went to the working=20
> group on why using this is not the best idea. Doing 3 would require=20
> doing at least two, if not three passes on the DTB for x86 with zero=20
> benefit/need since, unlike Arm, we never have to read from it after=20
> boot. The way the x86 parser is today, we are walking the DTB only once.

Note that some libfdt wrappers are deceptive and have hideous time
complexities. Doing one pass might not mean a monotonically increasing
cursor. Regardless, DTBs are always quite small (particularly so in
x86), so the time complexity of the parsing algorithm is of little
consequence. We could do 512 passes and the time it would take would
still be negligible.

>
> What I would suggest for 2 is that, perhaps, it might be an opportune=20
> time to review the existing DTB parsing code. Providing a common=20
> interface to parse standard/spec DTB structures regardless if it is=20
> coming from an FTB or via the FTB index, aka "unflattened" DTB. Doing so=
=20
> would enable a complete reuse within the DTB parsers and remove then=20
> need for 3.

The biggest reason for using the DTB unflattened is (imo) having arm and
x86 parsing the same data structure. The unflattened tree is not merely
an FDT with pointers. There's logic to merge nodes with the same names,
remove duplicates, etc. A "quirky" DTB (e.g: with overlapping nodes),
would thus behave differently on arm and x86 unless they both use the
FDT or the unflattened DT.

Furthermore, parsing strictly in the order you find properties in
creates a danger to synthesise different systems when fed DTBs that have
properties in different orders. imagebuilder could be instructed to
reduce the danger of this by having a canonical order of properties, but
I really dislike having room for diverging interpretations of identical
source data. This isn't necessarily an issue with FDT parsing per se,
but it is with the way it's been done in the existing series, whereas
the code in dom0less looks up properties in a specific order.

>
>> (2) and (3) are tightly related. There's many reasons for wanting to use=
 the
>> unflattened blobs as much as possible. They range from quirks in specifi=
c "dtc"
>> versions, to complexities parsing phandles, to corner cases involving du=
plicate
>> properties (i.e: due to .dtsi files), etc. Unflattening an FDT brings a
>> lots of "maybe-ok-after-sanitising" FDTs back into canonically correct D=
Ts.
>>=20
>> I'll share the PoC code as soon as as it's in a presentable state.
>> Hopefully by the end of the week. But I'm sending this ahead of time to
>> start collecting thoughts right away.
>>=20
>> So. Thoughts?
>
>
> v/r,
> dps

All this said, the analysis (thanks for sharing) seems still relevant
and also seems like a reasonable goal for all architectures, but having
everyone parsing the DTB in the exact same way leads to far better
predictability. Once all the code is in common and in use, it'll be a
lot easier to simply modify arm to use the FDT on the grounds of keeping
arch-symmetry and the drop of code it'd mean for x86.

For the time being, however, I'm more interested in getting staging to a
working state where it can boot multiple domains off a DTB, without
endangering arch-symmetry. Then the rest is refinement and optimisation.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu May 22 12:09:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 12:09:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993840.1376962 (Exim 4.92)
	(envelope-from )
	id 1uI4jv-0000zb-3X; Thu, 22 May 2025 12:09:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993840.1376962; Thu, 22 May 2025 12:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI4ju-0000zU-W7; Thu, 22 May 2025 12:09:34 +0000
Received: by outflank-mailman (input) for mailman id 993840;
 Thu, 22 May 2025 12:09:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI4jt-0000zN-7e
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 12:09:33 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20626.outbound.protection.outlook.com
 [2a01:111:f403:2415::626])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9d86cd47-3705-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 14:09:31 +0200 (CEST)
Received: from BY5PR16CA0026.namprd16.prod.outlook.com (2603:10b6:a03:1a0::39)
 by SN7PR12MB8060.namprd12.prod.outlook.com (2603:10b6:806:343::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.20; Thu, 22 May
 2025 12:09:26 +0000
Received: from SJ1PEPF00001CEB.namprd03.prod.outlook.com
 (2603:10b6:a03:1a0:cafe::a2) by BY5PR16CA0026.outlook.office365.com
 (2603:10b6:a03:1a0::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.27 via Frontend Transport; Thu,
 22 May 2025 12:09:25 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CEB.mail.protection.outlook.com (10.167.242.27) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Thu, 22 May 2025 12:09:25 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 22 May
 2025 07:09: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" 
X-Inumbo-ID: 9d86cd47-3705-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FuCChqeO7yeLHq469TCzC7PhXksB3jiRJ0xsVoPSAbQI6w+/z8jMYIEOAv6c5zOT2ETuYnpfyK2VPgffer7N/bgnZGb7lnEv75qVnRtqsq+uNxrHXrDrj/f7l3aZIQfEi7rxdwutxKzsGmUE/6KXZTXcjBjFA+0FKXILwLhorBEhubDWicfTSjezB8vSFQ+NpKaOtec0wXRDoa7+RtCD3o1Mld8LkLVKX81EMYthP2dIDh9bk+Bwr5/qnIFglovbhjrV4c+qcTVzdqqp7Jgz/LJeCr9BbkOZAnbDF95uivThobDFmHpNEKareV35Kn0vQl1VKc4Iy704lqX4xETYsg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5yo6JcFNN/IEQDveHnx9Bzv6eOfNIFeZqCYxwX/8Trc=;
 b=I1kZJaWcB++hFc5MN2kjPMpcQDUUUIVZjxraKh3qNwPObBfJ6EsOt9PW6+xzJteXqsjql6BES+nSqV/QoWvHL3AxIpWakDm9bkA6uCMr823fR5BPZdGviHDXb1B8UjW0kTjdiOTGNSYbggrDe7Z24kWAKRAezYPSnA3C4/+XZtNCkNKRMpNFw9Yxdo9LZi8HlqlMaAuinm5ekZMiNQvLbyf93xowPwdOMGx38TETSXDJaoWOnJ6yfB3nE6qYvtLtPP3yx2fI3zGysU3ATmY2F/2uiqjRVYEVj63Avd/0oHfOBabXdm2VGGGrDsCBZhLvOZK2lV0/8Llrru1bNnOknw==
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=5yo6JcFNN/IEQDveHnx9Bzv6eOfNIFeZqCYxwX/8Trc=;
 b=fzaI8vgCeUDjFYHTfuQ+eT4XSoAc6SiD02I8CyZ02QBF9e5JkqoIL9qIGjHoiuToIXaNqF/rmcMVO4Jt2eiDX5EjcC8Kc5+fBLR2eh7t6WP1juiaPvGxTAtopLLeftEZ4DQ+nw5BU+Ug0Iw29yPe2kmd67VRU+1AJc4h4EyDVCc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 22 May 2025 14:09:21 +0200
Message-ID: 
From: Alejandro Vallejo 
To: Jan Beulich 
CC: "Daniel P. Smith" , Andrew Cooper
	, =?utf-8?q?Roger_Pau_Monn=C3=A9?=
	, Anthony PERARD , "Michal
 Orzel" , Julien Grall , "Stefano
 Stabellini" , Jason Andryuk ,
	Denis Mukhin , 
Subject: Re: [PATCH v6 02/12] common/hyperlaunch: introduce the domain
 builder
X-Mailer: aerc 0.20.1
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-3-agarciav@amd.com>
 
In-Reply-To: 
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CEB:EE_|SN7PR12MB8060:EE_
X-MS-Office365-Filtering-Correlation-Id: 5b6f200a-197b-4200-a8d9-08dd99297ed7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?a2VKQ2IxYWVZalpsYTZmUm10RXBmMkVFRkw4d3dXcDU5a1JVbVp0R0ViTVNU?=
 =?utf-8?B?OGtqK1hhdVYvdmE0a0tpam03cWNSODBxdWgrQ0NMU1hyYXRmN04xeDhWWGcv?=
 =?utf-8?B?d0VXZDVIbS9pR2RKMDZUeWhtRGlIbTRUWkpRWDd2UGQ5eEpLeE9EME5rL005?=
 =?utf-8?B?d1FHd3FPL0J1OVVWSUlTYzBhRU9QblVFTUN6d1hNUStuSHgxcU9WS0lWWXdk?=
 =?utf-8?B?ZUJ5S3NEejlRcDhPekxEOVA4SGRwUDBTNGIvWDFxL1Y2cU5IUzhYblFScWc4?=
 =?utf-8?B?emE4K1dLcktoc3ZLbEtjY002STFGTFBvSmlNeHk0UzczQit1VE42V0M4aXFC?=
 =?utf-8?B?OXNhQzgrVnpRRUVYYkd6OEs1VittSFQ4TmxIZUJWWmdFNWJEMXZQem5vZE9U?=
 =?utf-8?B?ZUc0SW51bjZWUVZwWUtWY0hPbzdPYVhLSGl4aXNOZ29oZ2NVQnJ4MldpVXhK?=
 =?utf-8?B?ZnBBUVE3bW5UVXhXK3hLNFdNMElIbHJLWElnRkpZRFpsQWpCSklsSFB1NmZ0?=
 =?utf-8?B?eEU4akJ6Nktrc0VmUStib244cjlrL1A1TkdraC9nOUMyU3NzbWM2c003aGJK?=
 =?utf-8?B?OVRteVhTZFI1UEdjYk5zK20xZzNSWUNCTVFaMldiNjhXcUhCb1JTSTZKTkFM?=
 =?utf-8?B?U3F5VmhJOU5IUFA2ODdsa1B3MERBYVZrdC9rMGVTaVp4Vm1rSnlaNGp1Tm9Z?=
 =?utf-8?B?OVdDVys1Z1ZiNDNBQkMrQ2REUFFYU2RVazcvL0ZrMTdyWm9KTWswYWJLUU5n?=
 =?utf-8?B?OFE5UWQ4ZlZzZFlLYzlNeU15d014SlV4ZnpranNha3hZZmx2RklBanN4c3Js?=
 =?utf-8?B?YmkyUGJyZWFvUldEQi9kc2t1eVNLNzBkaHZRMGpkaEJmZmlDeGJoMUk3bW5Z?=
 =?utf-8?B?cm1Hd2s1ZlNVRHJzMkh3WEh2UzNIR0VLVndrNDhXU0J3NHdGc0xzUXZhblBF?=
 =?utf-8?B?U3pqMVUwL0o1dElZQjRNNXFLMzV6STNScGJQTWUvMnV0T24rbWJWUEdhbGpB?=
 =?utf-8?B?VVptRjlGbSswT1MzSmFVb3lCcXYwZHYxSmFTMGN3USt1OHAvaUwxdmJNZEM3?=
 =?utf-8?B?NFVYcFU3d0w4Zm85dk9LV3U1TjlNeWtXTHhVUXNXQjZtZVpMaERFeTlOL3hN?=
 =?utf-8?B?Z0tMTSs0d1pLVzRFakV4Um9WbCs2REZuUUtVbkhjVm5YZHovdVVkMkd2TnYw?=
 =?utf-8?B?ZlRvYmt0a1FneTFJbVFEMGNTRlA5Y08wQlhRNW04SEI1aGhYaHRqVTYzR05J?=
 =?utf-8?B?VlJoc0JGekgvc3NNay93Q1JEK3pXMmkrd0IyZUVIL3U2VkhFK1FWd3ZCcEtU?=
 =?utf-8?B?VkJ3UTlhOFdzcjJFdE9qSlZTNjcxaTZSOG9LUnJNVGFTZjBIamdJelFiWXk5?=
 =?utf-8?B?YXIyWjI4aytiVlJtQktTaVBvWUFIcGVhNWJjQ08yRXg0V3BobVVTSzFJWWMr?=
 =?utf-8?B?UFQ1M2hwd3J2am1yRStZaTNtcGtCQ242SDcvaUlQNjdWYU1jSGZvRlg2SnpH?=
 =?utf-8?B?U0hueEU3cUdqQ0JuVElLdFd5OUtSWWVmZDF3b3VUdU1OaDFqazUxZllpZXUw?=
 =?utf-8?B?elNNVVV3MVIvVmtZRUhaT092UEZUS1E4VFdvbnVSTlBPdmgwOEg4YlpOUktK?=
 =?utf-8?B?TVpZU3VHdkxvQTdlVTI5a3YrZkRHWGt6bUYwVXJFTElyNXNhdmkzMlBiMWow?=
 =?utf-8?B?NjI0UkNhdHVOOVIyZDhjc3dKVjh0ZWx2YXpVYVpKS3EvTmd3dXprR2VCNld0?=
 =?utf-8?B?NmE2MVRTQS9XZjZENHlmcVdBY05ISFpXbFRqNER5clpmWHZVWUtNWUIyMy9P?=
 =?utf-8?B?SGxObDg1SGgydmU2enkrUlFtU3ZFVE9ocHdkZHdpZGdIbUpzSlcxVXc3L1FV?=
 =?utf-8?B?WnU5djY2d2dvZVNXNmpSL1JxakJyTmJ4di83M1dVOEhBZTU3VHFiU0lvcC8z?=
 =?utf-8?B?NmFpNzhqVzlOVWtWSk5KcVJ4NS9mQkJVdEppbjQ5R1hMRGhaTkV1R0RKcGlh?=
 =?utf-8?B?b2o5ZGlPdXJDaFNJOXl6QWJ1VDBXa1U2d0ZvdmJ4L05wWWdIejJDN2VSTVVJ?=
 =?utf-8?Q?rOUgEy?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 12:09:25.5909
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b6f200a-197b-4200-a8d9-08dd99297ed7
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00001CEB.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8060

On Wed May 21, 2025 at 10:54 AM CEST, Jan Beulich wrote:
> On 29.04.2025 14:36, Alejandro Vallejo wrote:
>> @@ -1284,9 +1285,14 @@ void asmlinkage __init noreturn __start_xen(void)
>>                 bi->nr_modules);
>>      }
>> =20
>> -    /* Dom0 kernel is always first */
>> -    bi->mods[0].type =3D BOOTMOD_KERNEL;
>> -    bi->domains[0].kernel =3D &bi->mods[0];
>> +    if ( builder_init(bi) =3D=3D FDT_KIND_NONE )
>
> With this, can ...
>
>> +    {
>> +        /* Find first unknown boot module to use as dom0 kernel */
>> +        i =3D first_boot_module_index(bi, BOOTMOD_UNKNOWN);
>
> ... i ever be anything else than 0? If not, perhaps keeping the call here=
 is
> still fine (kind of for doc purposes), but an assertion may then want add=
ing.

I don't think so, no. It's there for symmetry with the way the initrd is
discovered later on, as that might be on module1, or 2, or 3 depending
on whether there's microcode, or an XSM policy or anything else. in
other modules.

>
>> +        bi->mods[i].type =3D BOOTMOD_KERNEL;
>> +        bi->domains[0].kernel =3D &bi->mods[i];
>> +        bi->hyperlaunch_enabled =3D false;
>
> Is this necessary, when the field is supposed to be starting out clear?

It isn't necessary, but I think it gave a sense of intent. That said I'm
pondering removing that boolean though in favour of something like

  bi->mods[0].type =3D=3D BOOTMOD_FDT

At which point that assignment disappears.

>
>> --- /dev/null
>> +++ b/xen/common/domain-builder/Makefile
>> @@ -0,0 +1,2 @@
>> +obj-y +=3D fdt.init.o
>> +obj-y +=3D core.init.o
>
> Any reason for these not both adding to obj-bin-y, like we do elsewhere f=
or
> *.init.o?
>
> Also please sort object lists alphabetically.
>
>> --- /dev/null
>> +++ b/xen/include/xen/domain-builder.h
>> @@ -0,0 +1,29 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef __XEN_DOMAIN_BUILDER_H__
>> +#define __XEN_DOMAIN_BUILDER_H__
>> +
>> +struct boot_info;
>> +
>> +/* Return status of builder_init(). Shows which boot mechanism was dete=
cted */
>> +enum fdt_kind
>> +{
>> +    /* FDT not found. Skipped builder. */
>> +    FDT_KIND_NONE,
>> +    /* Found an FDT that wasn't hyperlaunch. */
>> +    FDT_KIND_UNKNOWN,
>> +};
>> +
>> +/*
>> + * Initialises `bi` if it detects a compatible FDT. Otherwise returns
>> + * FDT_KIND_NONE and leaves initialisation up to the caller.
>> + */
>> +#if IS_ENABLED(CONFIG_DOMAIN_BUILDER)
>
> For the pre-processor it wants to be the simpler #ifdef.

True. Don't know what I was thinking.

>
> Jan

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu May 22 12:46:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 12:46:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993860.1376971 (Exim 4.92)
	(envelope-from )
	id 1uI5J4-0006bT-Mq; Thu, 22 May 2025 12:45:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993860.1376971; Thu, 22 May 2025 12:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI5J4-0006bM-KK; Thu, 22 May 2025 12:45:54 +0000
Received: by outflank-mailman (input) for mailman id 993860;
 Thu, 22 May 2025 12:45:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI5J2-0006bG-Mw
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 12:45:53 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b0fb3357-370a-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 14:45:51 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id DBFC24EE0737;
 Thu, 22 May 2025 14:45: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" 
X-Inumbo-ID: b0fb3357-370a-11f0-a2fb-13f23c93f187
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=1747917950;
	b=ku5n8v/yax0xZ5Cve20i2DM/J5ihSpqynsFSJrpR3a4Whg+DL4X5b/tjOWBuUcPWmi7k
	 GjLJlNqGtCC42chPPI0aTr98jXbuaSCns1/tsWKUxyRH2V12l63AnQNMmgrI1z5K2pMav
	 WbZhyZ1sb4PgYFvsGvO6UZlAAyfgi0Ur7jygr3115XyF7XoKdWSkqFjcq8E0KSvaemrfQ
	 wPYE4PZ3fJTkK/2missN0vylYny3SCRrb5AWQ2pHac6KQU1fnB7iGKzzG1Q6xyvFshvOf
	 1RkWHVObGxvHNY8pEvn0iLNcJMnyLyM0voWkgJnsgswnJ81yBowOZiHw3KS3nRvVDqP+7
	 k/Rd1+s3x8jS2FngnyIlnZUgNma18FC2CQsOMGxNY/FMEB7zaf+CiVVof3O6NHDYJo2aq
	 1QxavB32ZzfbMrPx/JzAebFgwOhkzTflO8Bq/yQBCM6XsFb4mq3NQ81F50JOvqW3uSysl
	 6HoKasgF9gNrOGlx9h5pWlb1P8hjP2CWjI1RpUAod4nWPSEyRhNdebzU1rMZqYPQAWqgT
	 0PPT4FBQJn3PCeuNhvgpmdf3E7c+V1yLgK2LSpvAjpn7TZmY05Vps1KkmGYYgFUDNsrqM
	 h9JUyH1YAkCwrsKIr2VarvfzAgXamKQNE0J1r8zFsY2jSSHL6SLDzH4iyV89mZc=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1747917950;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=/byCIgRj4kR7pIiwC4BW3reIywL/OWkrGjOXyNmD55k=;
	b=r9RABhdWscKDn1w7fZ6LMKi3emqBlzzusz4sGcViVKOBcWsWmJgXWabo0TNtua0ILtpe
	 WEJKvJB66LONKiMuI7SKZ1xkgWknNsnxfM1tugii+UgSzW1x/gxiyiAnOd/ppqOrWujKJ
	 XC9kxinrGlh6xtWe9SzmkZ1Utx1CPVFzAaWZhXjQ3t90oXu/LjRqTpm5963tTlkV7hOW3
	 hmPECtHKBlA07dQuBgwa+JgDTIm/+Q41pSb2NZZ6YOkr13PdCBNMZin6A87GPsb8R3oGj
	 E2ScTYZMMB9wmYU+VyJkukGmgjehbQkVTTjoIgzFwSbKbhEFfzr42YHLELo7BkECIL5V9
	 i5dxBXJwkYYnkxF4ErcOVNsbQ0xFBESs4xaKGTIEPrzGk/zdNvUJpPa2XoF7JiGhgVvT6
	 Jf+ZKG4+9hLvcSezSZzsEhDTrLedG/K6Nv0p0F+GfekE3hM8OfFoo8Qg7tChyPGTOhIjs
	 VD4Rhzb5f09Ox16YtJjKlD/cRbxTrm+59x/2fmuiRePUSxtPEodXbgkaz3bstfM8bDz69
	 bw/B1GUCSW4+INqkd+HeQGCjRBfkNnrBrUVIYwJ447mpqQZUnmTcrigwnh5j0303Wdh2y
	 d/lW/Ywv+D7kDcclLvQk+2603pSk9So3uAKeiOkNZQjyvspkI4WqP+5xE2GNzyI=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1747917950; bh=bGVo0mC4dfPvIYYkEfT5dmbRsPvlQNOENL1aBSZWmow=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=VDyYLLLtnA+Qk7V5AI96a5rFXCSQsgAecgauBAwwWBDMsH1K39MDfgaXX1QCJgUNq
	 yHOKsiOuPR2uWZMfhnK9sx75Ois0HLMswSjRDmEO/xDmTK8+PRnB6X6oXBScQpwDJT
	 nKiVK06p8qAofuTYeVBhnz2jC8L3Jdu4kmK+wTZVpbBjC81OrX92tbtyDRS1wkyl+G
	 BPBhhwjME3pD+gX9W22Ag2nI984svu8PeeJikV6M2RmqA7jcYXlLFWFwH9rUY2Libp
	 t2DYLgEPqt4AWPNMckYOX1c/ckEEE+Q5jbKWGZP8+ASB/oaN9FxlMABJTAgL29d87Z
	 iMDeVR8MwUkiA==
MIME-Version: 1.0
Date: Thu, 22 May 2025 14:45:49 +0200
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , consulting@bugseng.com, Stefano Stabellini
 
Subject: Re: [Eclair false positive] Re: [PATCH] x86/msr: Rework wrmsr_safe()
 using asm goto()
In-Reply-To: <8504aab1-c48a-4981-a502-93a2fd18880b@citrix.com>
References: <20250521143658.312514-1-andrew.cooper3@citrix.com>
 <8504aab1-c48a-4981-a502-93a2fd18880b@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

On 2025-05-21 20:00, Andrew Cooper wrote:
> On 21/05/2025 3:36 pm, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/include/asm/msr.h 
>> b/xen/arch/x86/include/asm/msr.h
>> index 0d3b1d637488..4c4f18b3a54d 100644
>> --- a/xen/arch/x86/include/asm/msr.h
>> +++ b/xen/arch/x86/include/asm/msr.h
>> @@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr, uint32_t 
>> lo, uint32_t hi)
>>  /* wrmsr with exception handling */
>>  static inline int wrmsr_safe(unsigned int msr, uint64_t val)
>>  {
>> -    int rc;
>> -    uint32_t lo, hi;
>> -    lo = (uint32_t)val;
>> -    hi = (uint32_t)(val >> 32);
>> -
>> -    __asm__ __volatile__(
>> -        "1: wrmsr\n2:\n"
>> -        ".section .fixup,\"ax\"\n"
>> -        "3: movl %5,%0\n; jmp 2b\n"
>> -        ".previous\n"
>> -        _ASM_EXTABLE(1b, 3b)
>> -        : "=&r" (rc)
>> -        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
>> -    return rc;
>> +    uint32_t lo = val, hi = val >> 32;
>> +
>> +    asm_inline goto (
>> +        "1: wrmsr\n\t"
>> +        _ASM_EXTABLE(1b, %l[fault])
>> +        :
>> +        : "a" (lo), "c" (msr), "d" (hi)
>> +        :
>> +        : fault );
>> +
>> +    return 0;
>> +
>> + fault:
>> +    return -EFAULT;
>>  }
> 
> It turns out this is the first piece of Eclair-scanned code using asm 
> goto.
> 
> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10108558677
> (The run also contained an equivalent change to xsetbv())
> 
> We're getting R1.1 and R2.6 violations.
> 
> R1.1 complains about [STD.adrslabl] "label address" not being valid 
> C99.
> 
> R2.6 complains about unused labels.
> 
> I expect this means that Eclair doesn't know how to interpret asm 
> goto()
> yet.  The labels listed are reachable from inside the asm block.
> 

That has been fixed upstream. I'll reach out to you when that fix 
trickles down to the runners, so that you're able to test and push that 
change.

Thanks,
  Nicola

> From a qualification point of view, this allows for some extensive
> optimisations dropping emitted code.
> 
> ~Andrew

-- 
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 May 22 12:50:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 12:50:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993868.1376982 (Exim 4.92)
	(envelope-from )
	id 1uI5Nf-000881-7Y; Thu, 22 May 2025 12:50:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993868.1376982; Thu, 22 May 2025 12:50: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 1uI5Nf-00087u-4c; Thu, 22 May 2025 12:50:39 +0000
Received: by outflank-mailman (input) for mailman id 993868;
 Thu, 22 May 2025 12:50:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI5Nd-00087m-Vw
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 12:50:38 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20602.outbound.protection.outlook.com
 [2a01:111:f403:260e::602])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5aaaf327-370b-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 14:50:35 +0200 (CEST)
Received: from AS4P191CA0005.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:5d5::15)
 by AM9PR08MB6163.eurprd08.prod.outlook.com (2603:10a6:20b:2de::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 12:50:32 +0000
Received: from AMS1EPF0000004A.eurprd04.prod.outlook.com
 (2603:10a6:20b:5d5:cafe::fd) by AS4P191CA0005.outlook.office365.com
 (2603:10a6:20b:5d5::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Thu,
 22 May 2025 12:50:32 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS1EPF0000004A.mail.protection.outlook.com (10.167.16.134) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Thu, 22 May 2025 12:50:30 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 DU5PR08MB10657.eurprd08.prod.outlook.com (2603:10a6:10:51f::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Thu, 22 May
 2025 12:49:58 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8746.030; Thu, 22 May 2025
 12:49:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5aaaf327-370b-11f0-b892-0df219b8e170
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=DGXgiwJdyTNKFPplPIQUXvkXxZdRkxzXj/y2cFgobnacbNj+yAb1T8Ngg5FEjsytfhg10x0EDaiZBlg60ZOF37fhaHM+YAalYAk0erxJ+fL6okWviYdD0ymXab0vYa8pobHLoGAE32Vteojc8W9H3i/E820mCXsXcsJc1iLzEE5X1d98Nw2qb2cGKlsmxEFsdB7Bp/WZEtqIw7MWLBV4BDtpbcc3TjtrxtAdatBcOY3OiiPcch+N8nG2eKZfsLgaZJeAyqahbby6bUWrJp/xv3HBDvO/X72yp2l2lfy5x1w0aJbawBbO+G8vjl7MTiDWpWb5ne7IONqCoxsu3tp1AQ==
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=WAzyU6d9kX4RtXlRuczQHHpwxjnnsPMeEzp+de58qZA=;
 b=J7EbxDWHu3fDPuFzufXX9Yy3s2kmL1SzWr/d1mzquqxzxqgaCT60iWGvcKhkH/PH5Awbk7u7ycP5flZfQKg+rc5cePTaaoTPHahDpT4fuWZQ5GVQWocx/YMN9/fKvlrd8ZMfpi7W1qzGmMDuDsWPbD7Y8pWh4PpZp2zLTSkyYPoq5lWOO/XUW3fcxynOayFXO6krB5nDE6fyrAwPgodMhdLSF/rNnOvZqpzpP9g9uhYsoELgK4E4aHAC2LOUdOKRTZ9jzTvlh9xn7jP8FLk5mbZuVGhlZVjrrcbwwCYJgIwWi3CwC5u1Xw5asIrhvctAwWCfvDiQIgU+EzixuJlaqA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.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=WAzyU6d9kX4RtXlRuczQHHpwxjnnsPMeEzp+de58qZA=;
 b=fvjFwfxm57p1ctJqOYCVrDUJoTSYs2Wp/O9B09s347nwnCyvQpRWnrP/3f7z1yf9ONikgRPxS25xxzUxguz0CpoFCKuoD7lgXnnpAWMMZN/77XNq46N2ZuSdVukFR4va2oPyvJ/0b8unmhsvba/lzZizCo1WinIHTKndrJ7f8Xc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dfafZ3Zh35X763bbtIWsqZqrTG2sa9bJd2jP6y0hnQbBb4pX+TLqZtXdmLt1pL4mpu2Xaagi1lQTuwjCA3nDm7RjnJ82LIg1czUgtfYjLS+15z2GCNLWLr7FfkdlM2HXx39V8afOQTJfK9aK5gxUK5piGWvHm3wDlNKmvIYNw7tGbyweVTUYfsCoaya5ZaO9i69y8M87l/WObLNqPGdDqVbgObqYC1g6E8Eh8CEk0oTd29NeeskisVVfk3bDXz9SRmEqEJCvGnRAfRvxRCzOEP0t4dRlTWCNkKXoa9SoGQ0TTuwbwlveViHiEz1AppAfUqxRji0Bx0qjKQDOOVWzHA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WAzyU6d9kX4RtXlRuczQHHpwxjnnsPMeEzp+de58qZA=;
 b=RWumEsMi057NGjCEOtL+1aEomaz6Q1q1ZJJELqZiERDmvE5iZSD0E/AqA9ZJhHHy+Q7cqQp2j2M36vFpIgQMivR5u6EgH3mcmPx7FA0T9cv+F/4ZOGRwGlphe+JF4iYFvWonkINZiLPcmSq3P4nL9LfrUUY9vrvDJTpE1BfqYCqtpsDx9F6CFTmupJ1TsPCF+KPYVjeKPIiPG08hLtCWSX8T/jPd3aBgOLxd+LiTTJBIuMd5yVlXdHjiDllVXFPhZVlAzZxYqgkXUNQZ2Crrxp2SXvYOAtB4GmnKdr0nA7XSEcCEiRWQu0GtglhWdj1MiksLrU8S6pnAK1aF0v0eCA==
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=WAzyU6d9kX4RtXlRuczQHHpwxjnnsPMeEzp+de58qZA=;
 b=fvjFwfxm57p1ctJqOYCVrDUJoTSYs2Wp/O9B09s347nwnCyvQpRWnrP/3f7z1yf9ONikgRPxS25xxzUxguz0CpoFCKuoD7lgXnnpAWMMZN/77XNq46N2ZuSdVukFR4va2oPyvJ/0b8unmhsvba/lzZizCo1WinIHTKndrJ7f8Xc=
From: Luca Fancellu 
To: "Orzel, Michal" 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	
Subject: Re: [PATCH v5 6/6] arm/mpu: Provide a constructor for pr_t type
Thread-Topic: [PATCH v5 6/6] arm/mpu: Provide a constructor for pr_t type
Thread-Index: AQHbw+N/uOYJE2XMKkGQJY+Wc9WWnLPebdYAgAA6SoA=
Date: Thu, 22 May 2025 12:49:58 +0000
Message-ID: <6D22B504-4D83-48BD-8679-CB68DFE444E7@arm.com>
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-7-luca.fancellu@arm.com>
 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|DU5PR08MB10657:EE_|AMS1EPF0000004A:EE_|AM9PR08MB6163:EE_
X-MS-Office365-Filtering-Correlation-Id: 53006085-671c-40e5-babf-08dd992f3c51
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?q4yI1v/Rr2JWRWY+8v2N8gncPabGhxR8GSSb/4TNRNy77Q5KncmHlmGdaYr8?=
 =?us-ascii?Q?4q3eplaO+Frnksp5ldvYURwTnxksKpfPlTNVda5eBuurHhyxa57cBLJTzsKG?=
 =?us-ascii?Q?jX45RD7A2M5G5xJavc9E6udhv/j+3KjBpiPBD5XBWvlaYvblUrpo7NfkcOKf?=
 =?us-ascii?Q?5tCeGi4nclMd+eyK4HhCMWY3883bVF8Ucza5eFb1uQ4oHGy6v3GN0dyM2pwa?=
 =?us-ascii?Q?KL5xTqLEq08KxcT/BDKoewNqHBXMtCjl9vZkQXpLSajeueFMFmpTk0OQArd0?=
 =?us-ascii?Q?xuM6Yp8v9keqWDRTNxKENepvaPGLnhbPqSAUXehzLaabZ2vfJgc0ZPcPgTav?=
 =?us-ascii?Q?//zk6bPIEzCrr/qhQqWJolaXRid6Z4gQtKmW5nVCI3dL9+cPU/2wCYb6ulfY?=
 =?us-ascii?Q?OXUvWXWgMuRExqyz6Z8IVKHuBOANnG8b9pcq0ReuYuKTlW2QhXfpFdXoqhas?=
 =?us-ascii?Q?v+ArQqcf0IVIuCLplH2mqtoj8egTDU4pzZFKIxwHzLechdDOQGeOHBpcN9pC?=
 =?us-ascii?Q?x9hpeJeZpjDbPDcPoeVlJxUPUVSK22gzdwJQOZkt4kjxxvgMZSLGrXan4rAB?=
 =?us-ascii?Q?UiAnu/UncdJQ1Ob4/HMSBngzU8ZjYonA0GbHQ9bsrffDIjBogn31bcy/O7tL?=
 =?us-ascii?Q?+b8SAhVM+g5TZ5suPXlbgluH2kJUnoI3eflsxLg9YbitZRzFgPH0V5/NPpN8?=
 =?us-ascii?Q?VcEH3duvtbndoBjyZ4IqORyxsVHTC0hBNCQP3vc79v5cQD0SwPZIfK36wLcW?=
 =?us-ascii?Q?9UmfEKYPEwniGNAWtnkgtg9wAZ+Lg30TsvmjGsjcEQMiiE/l2UmCqcHO748I?=
 =?us-ascii?Q?3SIKJUdUl449ZB25jt7BqlNvMR76PmErqcYX47bJVPWNIcRY1sYQpkcri4s0?=
 =?us-ascii?Q?Fhvg2YRqLg/EERmMWtIDo+XmCCQTz7KY1irNNJTdf0dLhH2HKB2TgH/8WSYx?=
 =?us-ascii?Q?q+2lIEYNjWnb30LuIGVPEw1ypVDNjXT/lNvifzdUKm+5/MVks77ckimpOQAQ?=
 =?us-ascii?Q?QyzUrEDH8inXaaw8bjXQqTpWm4k27jf3S1aS9bIMBOHDtn/fJjFl5g/BtH/O?=
 =?us-ascii?Q?y2ciF2l9EgP/Luz7cP2JSjLihn6Q/RVZsj8ufTMK1wCkmuyTkY9NFg6fazkW?=
 =?us-ascii?Q?/Zr8toRoB7CfGtatqylKvGFiNjB3BvoL3cm3EJD8OKo8NM8UaaoO1Ja/ApB4?=
 =?us-ascii?Q?DOWtDvyQccPxYPkEjK7m7YBvtVht0mQxCH1kKPVwNfYuDri9ZLTOb2I6l04V?=
 =?us-ascii?Q?fyZNX4/itKSblYX2AhcmD8LIqG9onXDqaWfkFlnsjSKLKWfFO63ogG7vheIn?=
 =?us-ascii?Q?qIrwC5tinnt+GIajlilWk4uU0YioBPOPEj6j++5T3qurdsMoRur2YoDD8OZv?=
 =?us-ascii?Q?8cVhQmKWV+b8xM1iHaZ8Kct5VWtkwbhsAR9OdEAw/WVeG25XvEDWUO+xzDCs?=
 =?us-ascii?Q?NuzK0DOBGR1sdybfw0AcE0SIkSR6YW28JDFcdw2XU9xmmfb8pQtNEQ=3D=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5DE4A5145982874B95D2EB96C6C6CE73@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR08MB10657
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS1EPF0000004A.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	d1c56268-320c-4abc-210d-08dd992f28c7
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|36860700013|82310400026|1800799024|14060799003|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?RFN6BfxZte1GTGkIoFCgHDjUnlDGenYtbOpApjE/Aus0d9ypiPwuf1+IAVFM?=
 =?us-ascii?Q?7C3wB2HGNdwBprwAwnYA2fqsGdi/g1zCCuIaQGB205A9jYJEU64uKc+8NIGq?=
 =?us-ascii?Q?H2IvhMwEdRUYPiofU8rrd4PCuuFThUJGyAA8iP58yN1kSrQtqKUwSSsfTz0F?=
 =?us-ascii?Q?4at9meq1/NixWDODBGRNh9Ie+dhpH7j51NyWMmY68reedDjHhCo+34Ht9mUA?=
 =?us-ascii?Q?d+ABa1+fbdVXMcPbfjQVUaBm3vxcw3dmmS8/kMxAjsD2ahhvTQMysA2wuuc5?=
 =?us-ascii?Q?H5yfk8a4MCol0foNESCwObLMMoHrzYlomVHzDeAnraYebZYWmmbd/aVUxb3a?=
 =?us-ascii?Q?o9EXeYPcNg+lfJUbFFPB8xwK+DIIR0gjs7ZjmsAZMqOS6mWFlGz3slHqd7Mm?=
 =?us-ascii?Q?tkb+R9JMTNfPXMi63CedINvQPk8Luf7M8DTjZbpWsSe8OTlPFp3xUi4JOnp1?=
 =?us-ascii?Q?b4UUCtDKUxfOFndMV4SNZrWOgzKMZVW9BbNOf8Ml7DqrQByTkQCBShIo9Ira?=
 =?us-ascii?Q?ObVZ+4/ClU9uHw/emXDNuIrTB71NGaFFP7qkdBxNNkmhSSKDSpbA8uKC8USu?=
 =?us-ascii?Q?BcJeW2wyydxNe909/0bl2+KRyQ6N/gewjFpp9ok2kNPNHsHRCLhPciN3BcRZ?=
 =?us-ascii?Q?mD5j7WYvuOlHtWkPAwFLWWlMMC/z7UZmvOS/UWGrQ2GtD1a/nt5ukrufBiE3?=
 =?us-ascii?Q?chod/avK7J7Jv6Gjqm2pkaIKU8keC9iz6wOj+PgGHvuGqb/M37RvglLWUI2N?=
 =?us-ascii?Q?5/oYlm4Fz6eN+GOsyyn63Hzl2OCdmbgWwWQS49ylh/Q5Tz0aNO1asLIjA2Bq?=
 =?us-ascii?Q?rLfZTvzrw6p1isYUkqdSQkBkaJz0M+rloUX/ji5QJEpEZg5i2JuRDXZikG71?=
 =?us-ascii?Q?CLB6qSWGioZPjqo2a6eiMIEZ871geeyEoHfbsdF3T/MOftNOqQc+ClbvDM6H?=
 =?us-ascii?Q?6gnUOR5Ch5sMHMtZ8jMVKeeceQyvyCcjU+UuNibAMAWAh87utJFkOONea99o?=
 =?us-ascii?Q?NBQ9AQCOBYZfE7Uprx1HWn88BJmroJpkoDb+97Nf11s8V4JaIGnb8vOhmYDw?=
 =?us-ascii?Q?VMlxObFIpoF6ZMKeE5ecW8JxqRIqLOxs3BfEalS/4rAbR1z20GiiuH7PF4r5?=
 =?us-ascii?Q?DuY9QedrOYPaBifhQgSCGiNPfAuilxvPmpJW7ufCmMUow1qJbgNcmpe9nlUH?=
 =?us-ascii?Q?5oeP5KDw6Qt4+2YFZAy6jDCO76IYPyycs9uYeZvN+s+1+AZtwfJTYIuglm4u?=
 =?us-ascii?Q?gu8Xp+8Wm1blTJyLGcVhUIM50H9fGiFNA2dlakr/ttgRZIX7EuSk6f688yJh?=
 =?us-ascii?Q?rNFnhwOST83Bs1pbRJbYLx8BkxvAGtucroP9InAEArhVAAc8MQoViLtMOoR+?=
 =?us-ascii?Q?Jq856KTc5Ds+Y+yBj0mG+k+qvyQ7DPi2Bvoz3Nffqn0Lt1wzGLQtuW25t8+I?=
 =?us-ascii?Q?pKsqiwLE8h+jkVACWFhEj11/shqzcRluVdwKyogI7u8DPeGyoHh15MGoZgnh?=
 =?us-ascii?Q?lXw+IauSHxK7nXKjEencLwHXzIUzjlDGDw/n?=
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)(36860700013)(82310400026)(1800799024)(14060799003)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 12:50:30.9895
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 53006085-671c-40e5-babf-08dd992f3c51
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:
	AMS1EPF0000004A.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6163

Hi Michal,

>> +
>> +pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
>> +{
>> +    unsigned int attr_idx =3D PAGE_AI_MASK(flags);
>> +    prbar_t prbar;
>> +    prlar_t prlar;
>> +    pr_t region;
>> +
>> +    /* Build up value for PRBAR_EL2. */
>> +    prbar =3D (prbar_t) {
>> +        .reg =3D {
>> +            .ro =3D PAGE_RO_MASK(flags),
>> +            .xn =3D PAGE_XN_MASK(flags),
> Shouldn't you also initialize .xn_0 and .ap_0 or you rely on compound lit=
eral
> implicit zero initialization of unspecified fields? But then you do initi=
alize
> .ns to 0 fror prlar...

Yes, because there I would like to specify that value 0 means Hyp in secure=
 world,
but of course if you want I can explicitly initialise also these two

>=20
>> +        }};
>> +
>> +    switch ( attr_idx )
>> +    {
>> +    /*
>> +     * ARM ARM: Shareable, Inner Shareable, and Outer Shareable Normal =
memory
>> +     * (DDI 0487L.a B2.10.1.1.1 Note section):
>> +     *
>> +     * Because all data accesses to Non-cacheable locations are data co=
herent
>> +     * to all observers, Non-cacheable locations are always treated as =
Outer
>> +     * Shareable
>> +     *
>> +     * ARM ARM: Device memory (DDI 0487L.a B2.10.2)
>> +     *
>> +     * All of these memory types have the following properties:
>> +     * [...]
>> +     *  - Data accesses to memory locations are coherent for all observ=
ers in
>> +     *    the system, and correspondingly are treated as being Outer Sh=
areable
>> +     */
>> +    case MT_NORMAL_NC:
>> +        /* Fall through */
>> +    case MT_DEVICE_nGnRnE:
>> +        /* Fall through */
>> +    case MT_DEVICE_nGnRE:
>> +        prbar.reg.sh =3D LPAE_SH_OUTER;
>> +        break;
>> +    default:
>> +        /* Xen mappings are SMP coherent */
>> +        prbar.reg.sh =3D LPAE_SH_INNER;
>> +        break;
>> +    }
>> +
>> +    /* Build up value for PRLAR_EL2. */
>> +    prlar =3D (prlar_t) {
>> +        .reg =3D {
>> +            .ns =3D 0,        /* Hyp mode is in secure world */
>> +            .ai =3D attr_idx,
>> +            .en =3D 1,        /* Region enabled */
>> +        }};
>> +
>> +    /* Build up MPU memory region. */
>> +    region =3D (pr_t) {
>> +        .prbar =3D prbar,
>> +        .prlar =3D prlar,
>> +    };
>> +
>> +    /* Set base address and limit address. */
>> +    pr_set_base(®ion, base);
>> +    pr_set_limit(®ion, limit);
>> +
>> +    return region;
>> +}
>> #endif
>>=20
>> void __init setup_mm(void)
>=20
> Other than that:
> Reviewed-by: Michal Orzel 
>=20
> ~Michal
>=20

Cheers,
Luca



From xen-devel-bounces@lists.xenproject.org Thu May 22 13:04:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 13:04:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993896.1376992 (Exim 4.92)
	(envelope-from )
	id 1uI5aY-0001dm-BL; Thu, 22 May 2025 13:03:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993896.1376992; Thu, 22 May 2025 13:03: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 1uI5aY-0001df-89; Thu, 22 May 2025 13:03:58 +0000
Received: by outflank-mailman (input) for mailman id 993896;
 Thu, 22 May 2025 13:03:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI5aW-0001dZ-NR
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 13:03:56 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2415::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 35b50dae-370d-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 15:03:53 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by SA1PR12MB6678.namprd12.prod.outlook.com (2603:10b6:806:251::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 13:03:49 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.019; Thu, 22 May 2025
 13:03: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" 
X-Inumbo-ID: 35b50dae-370d-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rgd6Jf30CdURN3NEiUE7Xc5EVm4a2VS41mcRvEgKWtIsl3DvrSDYHvRDGyOpqQGHAeUH2LvV49ScvYxMKu/s8RqueROhTqBVdf9BIxBTg37B51qPjOYAzWfNos7CyowS9s8Vh2JVdlvoHn1aNhcQoOq4JTqkm1o4CQjmCIZSct3WDVvKqRMPDFHCjW8WIIXBjMOJUYP35MVgjKRaDBcrBxCYdujuPwzl4wnKtiwg6qFO94KZUqqKd5It7EQRIiRGPO9d8shtOL/aRJ8Muigr0Rraiw2WH3bOPJhoC5qYtAtD3I+f3C61/030KIGhXh+/NxJrBhlDakBO6HRyTUP/zg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Hq5kkqhGKm3VtH2CM+Frn7msdUuj/TqissD2VKZONv4=;
 b=QvivRcqP+04zH+4FuzeaNvx6IqSg6tzPmUvrJvAcbs8JMFcNztd3TJH30fq2nfQZAdfd+fpb9l+H69GPd6qBg9hhEsWNvzr3sYkOP/9Yo75NVurnXvf6SftLHrt5aXoKVWFUQsjxXOmX1HmIkPB9a38CjZnbg+Jvo9DU5NpoOjw2JSuM/O2U+ghL9gybLlp4V6aKqmxVKaJ/ZVeCO6hvW3yeCHix6hry2kVmTWFnME6UEf8DsfG5LckcVNAWC+Iqk1iiFNYy2vrRb482xnFaEr05vgiid4ajb2GSoTLPPOO5gDK4DvLLKWC2zGW8WvpQZ9zYzgGngt1LUi+LWNzfNg==
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=Hq5kkqhGKm3VtH2CM+Frn7msdUuj/TqissD2VKZONv4=;
 b=F/TXZt9R5nJ1CjvsMIwUJg5mXJbBhBIY1Rw17BOYC0gVES86X9EyFxurvG+uRHtwWcZki9MTQtMEX1FE/TU+px+CT4IY6i4gfombPu+fx4LzCdto4Xitl9LvbrUSegaP7i+Aco5WhoA5jDTAQUj1bk+5jphSO587vLL2GLTSxdk=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <4a09b020-9d94-45f3-aeb6-e2281e212f57@amd.com>
Date: Thu, 22 May 2025 15:03:45 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 6/6] arm/mpu: Provide a constructor for pr_t type
To: Luca Fancellu 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250513084532.4059388-1-luca.fancellu@arm.com>
 <20250513084532.4059388-7-luca.fancellu@arm.com>
 
 <6D22B504-4D83-48BD-8679-CB68DFE444E7@arm.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <6D22B504-4D83-48BD-8679-CB68DFE444E7@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AM6P194CA0079.EURP194.PROD.OUTLOOK.COM
 (2603:10a6:209:8f::20) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|SA1PR12MB6678:EE_
X-MS-Office365-Filtering-Correlation-Id: 00aa881f-e561-499e-e67b-08dd99311818
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?LzdvZzNSdmlOQmtqNEVxemZTRzBsTDRDQ0V5SDl3MG1EV3cxZkNudkMyZCtN?=
 =?utf-8?B?eW1xeTU4UVJGT1NXYmVndGZwUnRqS2cxR2FUeUxVUXVDKzZ5bS9JV1E4VFlw?=
 =?utf-8?B?dTkvRkdMM3JCT0tVNWdVWDYzZ3Z3WmF1emFNVVhZRHRKSmRpbG1NdWZOT2xo?=
 =?utf-8?B?b3crWUI5UlBWRElnRnM3ZmlHbW1qOUVHaXoxOVU1OHc3WTRWOE9rVUMwSE5G?=
 =?utf-8?B?Yk0yeXRtR2E2bFhOdHpCV1FRdlRJK1V4UGVpOWpIYkR1MDBIZCtmNkEvbmFZ?=
 =?utf-8?B?YmxzRVpONDBObGFWcjY2RWg2cDJ0U0czYzF3T1hrRkRQT1BERWpqcW1UR0VH?=
 =?utf-8?B?Uy9jM2tmbWViR3BtOVJ2dmZvUVo2K3ZheGxvWjlmYXJyd0ZSUE1zZ09tamM1?=
 =?utf-8?B?QkY3dDY5dzNmWWN3MXVGTW42OEJYQkFJYUkzRk14bHVJM3FESWhWclZ4OGhK?=
 =?utf-8?B?cjV4UzlWY3J1N1Jwcy9ZL282R0crYzRyeVFPa1NabFRFSEUzSHRyaDJtQ2JC?=
 =?utf-8?B?eEs2QldrNnNUcWticG5leS9OUEl6ZmNaQnU4L2RhdHU1elJsa0JHWEJLMUVX?=
 =?utf-8?B?bFUrc1cyQnV3dk5CZkVQT0NuWXE5VDI5d2VHdlhHbGNDQ3c4TkdZZzgwRkdR?=
 =?utf-8?B?T1FRUHE2M3BGZnVWbWNGcE5LeHhuYW40Q1VNMy8rUFdWUytRLzEwdS9qVUZj?=
 =?utf-8?B?dXQrVStHY3MzMXBjQlI2cm80U1dLNE9qbVR4UUxYaWoxaTZqdDZHY0loSE5l?=
 =?utf-8?B?bThWZm5xKzFHTkhtanFKeHdvMVkrcjh3SDREWWRRQTczSkZKNnUzRmVUdG9T?=
 =?utf-8?B?OHdCYktqRkZDOWtHbUl0WkZJRHBLc0taMTR4ZWRNOWsyQTJOaU12bE1sK3p1?=
 =?utf-8?B?dzVWeE9vRzFYT0NhM3NYTktxNVBBQjF2OWZreVVIcnhrRHNnOVZDbXU0K2py?=
 =?utf-8?B?Q3luS0wwdXEzSmRNeWNubzhaYWJiMng0NWVZeUZtZnFyNzdabXpzV1dNaHpq?=
 =?utf-8?B?dUlUZ2pKTlhaaENLTFRjMTMvdlM4Myt0aVU0bURoVlNURVZPVWlITTBDRm0x?=
 =?utf-8?B?RnVNTkVSNDF6bldIdzdjQ2xHZnlTSDlKaXJHcmFSNkdVK2RZYm5yWW5qWktT?=
 =?utf-8?B?Z0FHeEkzclpndGtSMG5JWkxrZmE0R1N2WDFjTmVha1ZoUXprK3k2RVlFeC9w?=
 =?utf-8?B?VTgyOEF4bVd5UVVJdGR5L0hmZXBuSkNhZFdxcTFxcHlpdkIwTnUrcWpBV3Y3?=
 =?utf-8?B?WjduQ1FjZEI0ODQyMzQwWVRCY0pGZ0xOWGN0UVFGenpNeE9YWU1YdkhLOERr?=
 =?utf-8?B?YzhlNGNFZmFxbW1CUlQzNmhLd1N1VTFEdmVOalpmRjdnb1ZBcUxyYWZJTGFR?=
 =?utf-8?B?cnNRYnZ6ODRtTkg4TG9YSmZCelcrZmpiOWxyNjllbjFtVHMya0ZpbFJCaHlZ?=
 =?utf-8?B?c2liY1o2LzNOYVhTMTcxbWh6UWphTC84LzNRSWZXd0pUYzRsVStwN3hScUhU?=
 =?utf-8?B?RExlRzZMU1JabFJYcDZqREpPbmRXUzlPbHkvQ3hhRUNtZUExUGs5bFc5R3pK?=
 =?utf-8?B?NmFuSlN0MG1BRTA5TlFuazNhNldIdURzQ21VcHhXWklQTzl2YjgyVXBMUDR6?=
 =?utf-8?B?eGlUS0lGMnBhRmZnODVvRFFFZElRVzJvNXE5RHhmNmwwR2JwM0diOHNJQlV2?=
 =?utf-8?B?cXMzMGJFanFXZjBJbzBwaGpjVDRsNnFUNUJTNmgzUnZNWERnbjVWdzBoek9K?=
 =?utf-8?B?bkp4ejhxdk1NSGsvQ0JqNFBLUzhsR1Z6MWxRR3ZwNHhNV0NHQ24xZ2lpSnRE?=
 =?utf-8?B?SzFPbTVrSU1HbGN5UmFMNWFaVWQrUUFUTUdqYThiZWVOMGd4K1dJblE1QXFs?=
 =?utf-8?B?VVgwM3NjbUM5UXgwTEJ4WnpsczAyaS9HaW0rWDQzSUpZRkt5NmMzSVpXV05x?=
 =?utf-8?Q?xPN97Jq5Hfo=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZDN6N3BTdmFJNDgwQmg3T3JnRVlCYVRxOUY3MFM0SEw1Vk9vV3E4amNGelNi?=
 =?utf-8?B?K3pxVDZZWW8rMHIvNm9BOTdPSElzaUdXVUV0czRzbFNUaXpTMFcrbXZDcHd1?=
 =?utf-8?B?NUtoUzdyYW5TNWlxSFpzd1dSaFJhaFk4QjNJK250Q242RlpmR2pteTBZdjBx?=
 =?utf-8?B?ZFc3N1cybFRJT1JsdEpmbFRoTlBXZHlXTE0wa3dIUjR1dWtpQ0pIYk1iRlpy?=
 =?utf-8?B?YkxESDVxMitsUSt2MmdzRnM4ZG9kdm1MYUVaTGRYNTNydFAwV1V2eVY0ZmlH?=
 =?utf-8?B?ZWNFamJGY25xaXJPelBNTkxLbjRhRHJjWCtEamdQL3Y4Wk5pd0ZMY2VhWkgw?=
 =?utf-8?B?VGlwZ0xDVGxCTy9xOHhFSTNnUmpKZGw3dGQzQTFDTzF3a3RTdFQwUGlRek9y?=
 =?utf-8?B?UUUvMXFtM2c5cUJXQTVWSkFKS3hzKzBramkrZEtVbHBOV1NYdUNaS0pzRUtT?=
 =?utf-8?B?ZllHU3pnMEJwWWo2Ym1ZYnkvUlk3eDdUZ2pnZmhSWWRQSG1pQWhtajJ5b0s5?=
 =?utf-8?B?RGxkUTRydHRRVWlUdlVOZS9YM1dUcEs4RVB4UlhVR2ZiOUo5Rkt0SDRpWXVZ?=
 =?utf-8?B?eFpGZFFkY2kxa0VIbytpR0daLzE0T0ZMQWJqbU4yVXVDVmI1M3FoalRDV0NF?=
 =?utf-8?B?N3Z2UEcrUi9CZzhRdFMxQTFMSElaZFNNeHl5TEV1QUFXSXpnKzN4WWRqYmt3?=
 =?utf-8?B?MVB4RTN4WUZnd01BZ3JRRW1FSDRJNEtKWFpkanVScFdjMjdoNk5rRm5kbExn?=
 =?utf-8?B?Rmw0WXIrWGkzdk52NE0vUzJQZDljcTVSWnVlYTdzWW5VSE5RTHAyYlZrbm1T?=
 =?utf-8?B?dEZmS2JocnlzZDJ5YzJFRmZaTDBrR2Z6UWYrUHhHUGNVek0zNDJpU0VqN3pr?=
 =?utf-8?B?b29MRUNjMzd2TWRjTCtFdmVjOUtVT3dVZHpTcG01ZFJsMTUySXNjUS8vR08v?=
 =?utf-8?B?Z2lPMzZheFowUVk0cWxYdERtRmJNd0U4eHZxOWxYckNhK3crM2FGSW84L2dS?=
 =?utf-8?B?cUFHenE5WkEzL1FDcFlaTmVzUTg3U3lSWGRGRTRYRVJrVDR4ald3VllCSHFU?=
 =?utf-8?B?MWIzL1dUUzV5ektCdTUzMUdjT0F0REJSbEpoNThmb2VNOXZUbThTZDhhZHpP?=
 =?utf-8?B?Z1Nwc2phMFpsWTI2MmV1S1RiaHJEQXF0a3FBL2ZaYW5TTS9Sckh6cGI4WERa?=
 =?utf-8?B?VmJPeE95S0NPL3dPUFQ4Rkl4cEJYUmo3dVBwS1Fwd1V4cE1wTUJNLzhvZ0JR?=
 =?utf-8?B?MGg1eEI5QjVtQnAwUmZnekJVeGV1ZkdVR1Y0dEVLd21sa00ySmVqVzhBK01m?=
 =?utf-8?B?eWpBRkNiT29Da2lWS1QyMldPQStsWGlVbW1iakU2YVpZaCtvWFgzSkl2TUVY?=
 =?utf-8?B?SDkrbW1FU2lvT2N4RVM4c2Fsbk9aMzZnR3pxVFIxRFBzNzZzU2IwS2JOUS9U?=
 =?utf-8?B?SmtiaGpYQVJ3TFAwbVU0YTZ1aUZhaG1OR3RjZmFzZjk4dU9teE1tdXpXemZQ?=
 =?utf-8?B?WFp3ZXgxKzVVUGRaMHcydTRrQmJLWTR1VU12MDFLeHl2UlN3dHlXV2xuTUJy?=
 =?utf-8?B?dUhWM1BLWC9sU1pRRlVLWElReUpzNXo4NEN0SjhNYktnMkFGRGg1empwa0N5?=
 =?utf-8?B?cWFCY3FPbVJGdEE2WWc3cWtwNVZYcGpJZzViMExUb0VRWHZXQjF6SE5VcFNN?=
 =?utf-8?B?bDJGeERiVGJsTlFla0wvMEFRakc3UmM1ckxDc1RRUnhFTWROOHRnZlRWUFk1?=
 =?utf-8?B?L2NFdGFzR1FjRDBXMElaSlFyM3luSkkxcW5xUWhENHF4L3EvT2g1czlOTzhP?=
 =?utf-8?B?Q0pNMDBSY0p3VDNiZ1hxdlBkdStVdlVkMXYrSEtiMTZmemlKcEc0TWdPdzIv?=
 =?utf-8?B?UFJ4Z2diQkxWaHRDZlVETjRzNlFxRFhIdUhQZXAvSXpOVmY0aVorQ2dHTXNO?=
 =?utf-8?B?U1B3T3BaMUNwdWs4WUlvN1JBbzdSOGJXQU9EaFNJakdVaHdnN1NKb1F0OTJL?=
 =?utf-8?B?c0tSclhqN2ttQ1I4VnNHM2YvdE1jaGs3MkZXUThOWTNhVGdidFZ1eW9SR3dD?=
 =?utf-8?B?cXJXc0ljVitVcUNLYkZHUUdHTXpuWXhSMXJKd0YrSEx2Y2RuaU50aWJ2eFcz?=
 =?utf-8?Q?g7ld4FTEiYfqv/aYgzGwxoCCS?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 00aa881f-e561-499e-e67b-08dd99311818
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 13:03:49.5217
 (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: H24UbsNsOVaySo7jF3BLpWrGbCs5srQ04JbAQa2J+KSrUdFeYhPf4IS/CL7xCooW
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6678



On 22/05/2025 14:49, Luca Fancellu wrote:
> Hi Michal,
> 
>>> +
>>> +pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
>>> +{
>>> +    unsigned int attr_idx = PAGE_AI_MASK(flags);
>>> +    prbar_t prbar;
>>> +    prlar_t prlar;
>>> +    pr_t region;
>>> +
>>> +    /* Build up value for PRBAR_EL2. */
>>> +    prbar = (prbar_t) {
>>> +        .reg = {
>>> +            .ro = PAGE_RO_MASK(flags),
>>> +            .xn = PAGE_XN_MASK(flags),
>> Shouldn't you also initialize .xn_0 and .ap_0 or you rely on compound literal
>> implicit zero initialization of unspecified fields? But then you do initialize
>> .ns to 0 fror prlar...
> 
> Yes, because there I would like to specify that value 0 means Hyp in secure world,
> but of course if you want I can explicitly initialise also these two
I'd prefer that way (so that it's more clear what are all the fields initialized
to) but I can understand that this is very subjective so you have a freedom of
choice here.

~Michal



From xen-devel-bounces@lists.xenproject.org Thu May 22 13:29:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 13:29:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993945.1377018 (Exim 4.92)
	(envelope-from )
	id 1uI5za-0005jF-In; Thu, 22 May 2025 13:29:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993945.1377018; Thu, 22 May 2025 13:29:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI5za-0005j8-FZ; Thu, 22 May 2025 13:29:50 +0000
Received: by outflank-mailman (input) for mailman id 993945;
 Thu, 22 May 2025 13:29:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI5zZ-0005iy-Hm
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 13:29:49 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2416::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d3705959-3710-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 15:29:47 +0200 (CEST)
Received: from BN6PR17CA0054.namprd17.prod.outlook.com (2603:10b6:405:75::43)
 by CH3PR12MB8484.namprd12.prod.outlook.com (2603:10b6:610:158::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.20; Thu, 22 May
 2025 13:29:42 +0000
Received: from BN2PEPF000044A1.namprd02.prod.outlook.com
 (2603:10b6:405:75:cafe::8f) by BN6PR17CA0054.outlook.office365.com
 (2603:10b6:405:75::43) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.32 via Frontend Transport; Thu,
 22 May 2025 13:29:42 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A1.mail.protection.outlook.com (10.167.243.152) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Thu, 22 May 2025 13:29:42 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 22 May
 2025 08:29: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" 
X-Inumbo-ID: d3705959-3710-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cVNsksL4pXgVb/5A6/5z+yIPFLJzG9XKGt4nlznWq5ls5WOBzzCUEmha9pc1Ibd6JzZej8njPrsALl5jFgwJWPdHIoCt3PVdyUola2bXZFWqoK5hDcBWahCHSsf2TGajOoxzLj6hrzg7daM+QcTZgRZbpow2wt6AEKORCMSRspujeCtdKOSklmz2kexYHWAym9zbrB3Q6nEulHET1isCVShNQysIZy0J87So80jGZ8dMxtVDfUQtXux9I0+0KsM5MqkI8OsSw+VjpTAxCdzhEd0hxzeDUKlsE0sRYKRqMqZYjhEHfW0UFJjhcL10iV13MSt4LcxGr8APktsiVzmXyw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Q48z1X16UrwC5dEANiAHs0bWd3cvCyH1Z5pCnzkrAEY=;
 b=Sx8Jmt2wWUt//Gz2+T/hq7QEMSKUfbRm7mjNHJ1pTgdf9twqo54qJ5C55Q98DtuzIlqxjljNqJ583HkU/dI8H9umf6R2+/3u+P3aOA6eVgiHICOf/3aV1nY13s9tmlrABNvycXY0zIx/5072ka0erf6uFRsliBm3Gw3Po8vyTp+vbywsokU0i2vdGPfkurIC0JYWWlDx7slpfVGwa47VLgmp8tnh3Ypdes+QYQai2C36kH+5Ogpx5BKDGZKd+qTxVeBt7X7X4YRXJCPX37y5AX1URbLqhfwQXoncoo2aXxrMGbRKUBebVwMVETLnZlIqeZR1BkW8SemuIYdBW9lFqg==
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=Q48z1X16UrwC5dEANiAHs0bWd3cvCyH1Z5pCnzkrAEY=;
 b=oh2IH4gx5jFv7UaGlmg/HGuwEJRgFqbYssx4wp9mAvQdaEg7vOodXQ5jUPqO1FK+yytzl94m86ijYMQo0vfuRGkWBArUlhtaf/EWLpN7+a0f4/B2ifE+e/uWwfAF9IqdfQW5KyXpUdJjbyBY4OYQm11UJx3NcX6/hTHFSCJJr1U=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Date: Thu, 22 May 2025 15:29:40 +0200
From: "Edgar E. Iglesias" 
To: Julien Grall 
CC: Stefano Stabellini , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , "Edgar E. Iglesias"
	, 
Subject: Re: xen/arm: Virtio-PCI for dom0less on ARM
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/2.2.14+84 (2efcabc4) (2025-03-23)
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A1:EE_|CH3PR12MB8484:EE_
X-MS-Office365-Filtering-Correlation-Id: 695c3515-7812-42f8-fecf-08dd9934b5be
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cjltL2R6UXZ5emRYb2VQbytzbUNNQnVBUUdSaEZpdTFIWkNFUEpTQmlqakJr?=
 =?utf-8?B?VWR3UnY0MmdzcmVZc25DYWgzVmNxRE80U3QveUFlUklmc1BEMTBCcjhKSEtR?=
 =?utf-8?B?bWV5SkRFVnhOeGZ5Qmh4RmhzOWNDQTBxS2piWmhybFNLcXJCVVc3dUF5S2N0?=
 =?utf-8?B?dzk3RnFoNXRIenlKVDUyUlVFZ0hHanVNMTdzQWRvNStpOWFnM0ZBeVZwdzQ2?=
 =?utf-8?B?akJMTmNZTUhzSzVtNWNZMTRmVkkxSlhzakM5WTA3VFFTN0Z6TlBQMUI5R0tr?=
 =?utf-8?B?V2tGaVlETVpOcWNsdzlPVmt6cVJzVGdibnl4TkcrQ3dXQ0RBK21nalZ3SmEy?=
 =?utf-8?B?cWlRbm1pTVNiYytWWU1IN3FRT1ZqWlVnL04vaXZROTc4VFJzU3FETHFIbFRs?=
 =?utf-8?B?Z0dtb1NEeXliaGpaNW1xclcweDJvTDAzaDVObk5vMFpYUmF0TDRZUmRHWGxZ?=
 =?utf-8?B?NXRDc2J6Mis4ek8rWTUrYWRYYTZ4cEg3bUs5bHBEd2VSNjFLMm5qODNDQW56?=
 =?utf-8?B?L0EzRGFjQ2UxYXdUYkFaM1RoVzhiZGVERkQ3VE5EOW1qZEplZHJZUWN1eEZn?=
 =?utf-8?B?QmdjRUdKb3d6QXgydmc5aVVRSmphMnlyOTd6dElNellRbmEwbjVCR3A3cDYx?=
 =?utf-8?B?Mk1Qc2ZGWmZSTTdpVHNkaE50cnZMcU1zd1NudjJuTUd0MmJHNnhFNjVZWEUw?=
 =?utf-8?B?TnFqbmlCVW1remF3Z1Z6NkV1QUtqQVlaWWJkc0g3clZRUWVhK2N4UERKTGhu?=
 =?utf-8?B?YWRzZlFmZ0xmbUpsMkxKSTBjd1RIL0U2bzhNYUZoZVNIL2xINWtubmVQY1Bx?=
 =?utf-8?B?bHZ4WlllWFBiTVZRaUcwT3lwRXU5L1hFY1lhcW5CRExncTR4U3ZkU0xyQUNI?=
 =?utf-8?B?S0U2aWNWc1hpMkRvTURGSnJjbWJNMzNMRjA3dmEwOGJ4KzVtSHBtSXlPZ0RQ?=
 =?utf-8?B?L05YazFjY0M4cU9PZmVkeW11ZVUzcDJValNkWGJTRmZhRHZWSXZyNDRMc3Yy?=
 =?utf-8?B?Q2lqUHIvQUJxaWttdG8wS2ZBZzZxNmNqbEZpVkUwOWk1eXlzTGUvZXY4bmd4?=
 =?utf-8?B?dFllZlh1MHNkM0cxVWVidXltZkpFRTFIRmZOaXdTTWN1UlE2a0dzZFEyVUF4?=
 =?utf-8?B?WTZaV0pIbnpFUDBtK0gra2pqYTFSalFUZWswbEFPcnE1U3J5YllqODlWNk1v?=
 =?utf-8?B?eDNxZ2dRaUlZdVhVbG50dytpem1yNURZNlpJa0NXcC9SYmpmMm94b3pQSG53?=
 =?utf-8?B?cnJHdnFZcXBwYzNndlJMRmc5TVZ1QzBudThuVVpxQjNocUF0NHdaZUJMTjZo?=
 =?utf-8?B?Szl4em1NVzZMS0YrTTFPMlNYVjFwZURhbWFVNGRpRGRoRDE5cVl6dG9kR0Ro?=
 =?utf-8?B?Ny91N2U0S0xKYTdrR2lWQ1doeXZpSzZQbzdYa2ovaktUTklpelNjQ2R1NXVt?=
 =?utf-8?B?b1ltQXI4dHFLN1U3US9DUEI3a3paaThUVzlqd1VBbnBkTlkwSnJWcEZlVjUz?=
 =?utf-8?B?Ym9mVjJyeTQ1cTZGSE43S0JTSXE4Y01sRjB4SHRVSGo0VjRIZ3NEMldNUE4x?=
 =?utf-8?B?bjFRYVBoVUw2QnlmR0FpbGxoME9QejZQUzMvaUtoSFVkQUlydHd2OFZCTTZn?=
 =?utf-8?B?d00rUURvcFMwN0FnRTF5MzdLYTVUelMzaWphNFIrYm52c0llMWROWFZYVlND?=
 =?utf-8?B?aWdsMzR5TWJDMm5zRFRacHJTLzlqSk9IZHRJRXZldVdMemVpV3hpaGlERlBD?=
 =?utf-8?B?em5oTWVLMFNLNWhRMlBPbkF6NXFUMm8ycU1OREZoSHZvOFpDcmg5NnovQTZJ?=
 =?utf-8?B?NVZDUm9NN2JLMWdhVm5XTlZZWWZkcVVTVjZsdzRpV1BDUW9DcVZFcDk3S1gw?=
 =?utf-8?B?S0NXL0tMa2gxOXY5VEFURGZtVDBacHFHMG1qL0pBSWJxc25FYkdXS3l6R2Yr?=
 =?utf-8?B?aW9KQVpHTjNoOE9kbC9tL0RQRGRrL2RqRzMrTnpXcFlDSDB6bGZMSmtXT1U5?=
 =?utf-8?B?RkZQUm5RUmphSTBwSmJ0Z3h0TkRYcmpPK0cxYktGMGJnQnVaVXhFSVdLYWlX?=
 =?utf-8?B?aDVmcGkrM1pNYXVUNWd1bm0yaE1YdUFQQ3dMUT09?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 13:29:42.2591
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 695c3515-7812-42f8-fecf-08dd9934b5be
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A1.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8484

On Wed, May 21, 2025 at 01:22:11PM +0100, Julien Grall wrote:
> Hi Edgar,
> 
> Thanks for the write-up.
> 

Thanks for commenting!


> On 20/05/2025 09:04, Edgar E. Iglesias wrote:
> > Hi all,
> > 
> > Following up on the ARM virtio-pci series I posted a while back ago.
> > 
> > There have been some concerns around the delayed and silent apperance of
> > devices on the ECAM area. The spec is not super clear wether this is OK or
> > not but I'm providing some references to the PCI specs and to some real cases
> > where this is used for FPGAs.
> > 
> > There are two options how to implement virtio-pci that we've discussed:
> > 1. VPCI + IOREQ
> > 2. IOREQ only
> > 
> > There are pros and cons with both. For example with #1, has the benefit that
> > we would only have a single PCIe RC (in Xen) and we could emulate a hotplug
> > capable expansion port with a standard way to notify when PCI devices plug in.
> > Approach #2 has the benefit that there is (almost) no additional complexity
> > or code added to Xen, almost everything lives outside.
> > IMO, both options have merit and both could co-exist.
> > > For dynamic xl flows, options #2 already works without modifications to
> Xen.
> > Users need to pass the correct command-line options to QEMU and a device-tree
> > fragment with the pci-generic-ecam-host device.
> 
> IIUC, in approach #2, QEMU will emulate the host controller. In Xen, we also
> support multiple IOREQ servers. For instance IOREQ A may emulate a GPU
> device, whereas IOREQ B could emulate a disk. This is usuful in case where
> one may want a separate domain to handle GPUs.
> 
> With the approach #2, it sounds like you will end up to have one host
> controller per IOREQ server. The user will also need to know them in
> advance. Is my understanding correct? If so, then it feels like this is
> defeating the purpose of IOREQ.

I don't think that is necessarily the case.

Option #2 would have the controller outside of Xen and an implementation
is free to split it up into multiple processes each with an IOREQ server.
It is also free to do a monolithic implementation or some kind of mix.

Today, QEMU supports 3 ways:
1. A monolithic PCI host bridge + PCI Endpoints all in the same process.
2. A PCI host bridge in one process and distributed PCI Endpoints in separate
   processes (vfio-user).
3. A PCI host bridge with partial virtio-PCI transports in a single process
   + distributed virtio backends (over vhost-user) in separate processes.

If you refer to guest's knowing about PCIe controllers in advance, yes but
I don't see why we couldn't use something like dt-overlays and kernel
modules to enable them at runtime. For PCI endpoints behind the controller,
an expansion port with hotplug can be emulated allowing the hot plugin of
devices at runtime.

With regards to isolation, I don't really see a benefit with option #1.


> 
> This is the first reason why I feel approach #1 is more suitable.
> 
> > 
> > For static dom0less flows, we can do the same as for xl flows but we have the
> > additional problem of domU's PCI bus enumeration racing with QEMU.
> > On x86, when domU's access a memory range that has not yet got IOREQ's
> > connected to it, the accesses succeeds with reads returning 0xFFFFFFFF and
> > writes ignored. This makes it easy for guests to wait for IOREQ devices to
> > pop up since guests will find an empty bus and can initiate a rescan later
> > when QEMU attaches. On ARM, we trap on these accesses.
> > > If we on ARM add support for MMIO background regions with a default
> read value,
> > i.e mmio handlers that have lower priority than IOREQs and that are
> > read-const + writes-ignored, we could support the same flow on ARM.
> > This may be generally useful for other devices as well (e.g virtio-mmio or
> > something else). We could also use this to defer PCI enumeration.
> 
> Regardless what I wrote above, if we are going down the route of returning
> 0xFFFFFFFF, I would just do it for every IOs rather than the one specify in
> the device-tree. This could still behind a per-domain option, but it would
> at least make simpler to setup the system (AFAIU, in your current proposal,
> we would need to specify the range in multiple places).

Yes, the range would go into Xen's static domain config node and into the
passthrough fragment describing the PCI host bridge. Typically only one
range is needed (ECAM).

In my prototype, I've got this for the static domain config:
domU1 {
  compatible = "xen,domain";
  ...
  mmio-background-regions = < 0xf1 0x0                // Base
                              0x0 0x10000000          // Size
                              0xffffffff 0xffffffff   // Read-value

                              // Additional ranges may follow
                              >;
};

> 
> > 
> > So the next versions of this series I was thinking to remove the PCI specifics
> > and instead add FDT bindings to ARM dom0less enabling setup of user
> > configurable (by address-range and read-value) background mmio regions.
> > Xen would then support option #2 without any PCI specifics added.
> > 
> > Thoughts?
> > 
> > Cheers,
> > Edgar
> > 
> > # References to spec
> > 
> > PCI express base specification:
> > 7.5.1.1.1 Vendor ID Register (Offset 00h)
> > The Vendor ID register is HwInit and the value in this register identifies the manufacturer of the Function. In keeping with
> > PCI-SIG procedures, valid vendor identifiers must be allocated by the PCI-SIG to ensure uniqueness. Each vendor must
> > have at least one Vendor ID. It is recommended that software read the Vendor ID register to determine if a Function is
> > present, where a value of FFFFh indicates that no Function is present.
> > 
> > PCI Firmware Specification:
> > 3.5 Device State at Firmware/Operating System Handoff
> > Page 34:
> > The operating system is required to configure PCI subsystems:
> >  During hotplug
> >  For devices that take too long to come out of reset
> >  PCI-to-PCI bridges that are at levels below what firmware is designed to configure
> > 
> > Page 36:
> > Note: The operating system does not have to walk all buses during boot. The kernel can
> > automatically configure devices on request; i.e., an event can cause a scan of I/O on demand.
> 
> I am not sure why you quote this. To me it reads like this is up to the OS
> to decide when to access the PCI bus. As we don't control the OS, this
> doesn't seem a behavior Xen can rely on.
> 
> > 
> > FPGA's can be programmed at runtime and appear on the ECAM bus silently.
> > An PCI rescan needs to be triggered for the OS to discover the device:
> > Intel FPGAs:
> > https://www.intel.com/content/www/us/en/docs/programmable/683190/1-3-1/how-to-rescan-bus-and-re-enable-aer.html
> 
> To clarify, you are saying the ECAM bus may be completely empty (e.g.
> everything is reading as ~0) and some part of the ECAM will return a non ~0
> value when the FPGA run.
> 
> That said, the FPGA behavior is IMHO slightly different. I would expect for
> FPGA, one would now when the device is present because they would have
> programmed the FPGA. In our case, we are trying to solve a race introduce by
> Xen (not the user itself). So it feels wrong to ask the user to "probe in a
> loop until it works".
> 
> This is the other reason why the approach #1 looks more appealing to me.

FPGA's loading has many scenarios, it can be done by the user that also
triggers the PCI rescan or it can by done at boot by another machine or
by another VM. There are ways to get the PCI link up quickly at boot
but they are not always used, introducing a similar problem as the one
with virtio-pci in Xen.

Note that approach #1 does not remove boot dependencies.
For example if a guest wants to boot from a virtio-blk disk, it will get
notified when the disk gets hot-plugged but the kernel may have already
failed to mount the disk. We would need a way to configure guests to
wait for a specific device to appear.

Cheers,
Edgar


From xen-devel-bounces@lists.xenproject.org Thu May 22 13:41:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 13:41:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.993972.1377028 (Exim 4.92)
	(envelope-from )
	id 1uI6Au-0000DZ-Jh; Thu, 22 May 2025 13:41:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 993972.1377028; Thu, 22 May 2025 13:41: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 1uI6Au-0000DS-GP; Thu, 22 May 2025 13:41:32 +0000
Received: by outflank-mailman (input) for mailman id 993972;
 Thu, 22 May 2025 13:41:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI6At-00009Z-BL
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 13:41:31 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 76848c54-3712-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 15:41:28 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-601ab204085so8911653a12.1
 for ; Thu, 22 May 2025 06:41:28 -0700 (PDT)
Received: from [10.0.5.8] ([213.235.133.42]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4ca2bfsm1075931566b.157.2025.05.22.06.41.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 06: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" 
X-Inumbo-ID: 76848c54-3712-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747921288; x=1748526088; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=dO80HXkGB8fOypjW2hkXwE66Di8Sv1KGNxTyMQdy+4o=;
        b=ZK3AdrMHaOTwlr9BbG3UboXsUOarEQDZA5qnh59nOqvywn+hhrqGbY4k/gj29UloLu
         IZTRANkiZMwyGvQMO+39qjZE1PBb3EwB1d6q3v7rUNTps92yzYLpjz9gmeYzBu3L2qAv
         szTEYwtWDbEc32JJTMAMxEFaqNEu1eiJiIZ7cHkTrV2F3jI+lFew0QDphfP/iHYHik8d
         6wMenW9zP3Cj7Di4cartQ/ba5ocm4CcF2B/tJFWbF5EU0CUgvSgbaDwtybQC38vvMuMN
         TxpLF96+N7qjj/mpaj7cmIZMlVJ72Tdf6iqnEAU60S67N5zdA3qIkAnFwpWLT1jhZVD1
         jBFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747921288; x=1748526088;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=dO80HXkGB8fOypjW2hkXwE66Di8Sv1KGNxTyMQdy+4o=;
        b=sUF/1bf9O+TPNfXuVwYDTS3WDREm9PKWMGM0+OXwYvdcGK1sL4mMnurqG/Q6wlVPZU
         bWJp4UszlcLXJG1sFXaDCyaPXyl8oPYNuZo1hIeCh4oSLZW5+q4umJpjt+vFGYQcGm7D
         2GUq8dkggyQFYCNo3r9ki2CLwQzILmZSTyXZ/pHqfctZbdaDyqkzUwRsV411XOdryfs5
         MPXbKoKLKHK4+OBTZhuG24aZOYL4YtxbBHccMMEx4ib8pk3PdfU7itUvzwQVfbLbx6qk
         dkPoo9wW4Po9ix1H9pirWSqxzHJ3+r/XMDGLJgRpsOmoV4zb26CtwfVxKHg59id+HWTF
         WrJQ==
X-Forwarded-Encrypted: i=1; AJvYcCUpnKb8QQty5b6p5iq47xXtoGXRC+sIDYTy56NP/1F1ryOqHu9xFMNC1UmNGhmaOFgVh4l3bCuFlp0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx2OlzQvmkhplPCeYQ/7yZ8N0uRk4TrnzJElSQoBUjTogSf3Q29
	h6pWc7QR1KHeFSMLopKw2JzCxnSlxjMZ1BgOs1a/WlK+kJVe+5P7uCG4yGdPk3KlQw==
X-Gm-Gg: ASbGncvcG/8OD9xUm/53anGBom0XIxm48b/j8qdPlKJ8L1ayLRv1Mm668tMuUTRlB+c
	PhtD454iDa+TeOGXJHs/K49LMVHUlrRyiA7L0wYDp8lHgHITlX0zoHwmNwv/UD4X4JaWHA8mKnQ
	Fgiq9RjT7HU7Tr05k4Pe1/Re5ekPtH6Ya0sD056Uz2Uq1CwtxE2YWcq3Kn6MRXaHgv3Pqix/0SL
	mVrTNV7sq6g0t5f0+0pM3TI7sJUHUUZKI0EwCkejZRIFTC3wsGZSIZpcoAqu7Lirzyc9zVjLpp/
	HTUbFYjpd37FCafnyMs=
X-Google-Smtp-Source: AGHT+IFAJKTB998SAkkTy93emFS7tGj18XqoaAZ77lM1d0AefeYkYVnWlDw9Eo2gqL0G+VsGKLz1+A==
X-Received: by 2002:a17:907:3e28:b0:ad5:2d5d:206f with SMTP id a640c23a62f3a-ad52fa567ccmr2460222766b.19.1747921288077;
        Thu, 22 May 2025 06:41:28 -0700 (PDT)
Message-ID: 
Date: Thu, 22 May 2025 15:41:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] x86/traps: split code to dump execution state to a
 separate helper
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250522075440.99882-1-roger.pau@citrix.com>
 <20250522075440.99882-4-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250522075440.99882-4-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.05.2025 09:54, Roger Pau Monne wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -714,13 +714,15 @@ static cpumask_t show_state_mask;
>  static bool opt_show_all;
>  boolean_param("async-show-all", opt_show_all);
>  
> +static bool force_show_all;
> +
>  static int cf_check nmi_show_execution_state(
>      const struct cpu_user_regs *regs, int cpu)
>  {
>      if ( !cpumask_test_cpu(cpu, &show_state_mask) )
>          return 0;
>  
> -    if ( opt_show_all )
> +    if ( opt_show_all || force_show_all )
>          show_execution_state(regs);
>      else if ( guest_mode(regs) )
>          printk(XENLOG_ERR "CPU%d\t%pv\t%04x:%p in guest\n",
> @@ -734,6 +736,38 @@ static int cf_check nmi_show_execution_state(
>      return 1;
>  }
>  
> +void show_execution_state_nmi(const cpumask_t *mask, bool show_all)
> +{
> +    unsigned int msecs, pending;
> +
> +    force_show_all = show_all;

Prior (v1) comments here still apply.

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 13:49:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 13:49:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994006.1377038 (Exim 4.92)
	(envelope-from )
	id 1uI6IU-0000uD-Ch; Thu, 22 May 2025 13:49:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994006.1377038; Thu, 22 May 2025 13:49: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 1uI6IU-0000u6-9W; Thu, 22 May 2025 13:49:22 +0000
Received: by outflank-mailman (input) for mailman id 994006;
 Thu, 22 May 2025 13:49:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI6IS-0000u0-N7
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 13:49:20 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8f1a3c72-3713-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 15:49:19 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad5a11c2942so499392466b.3
 for ; Thu, 22 May 2025 06:49:19 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4909e1sm1070910166b.125.2025.05.22.06.49.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 06:49: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" 
X-Inumbo-ID: 8f1a3c72-3713-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747921759; x=1748526559; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=sx+KRYDTbT4B3nMPYW7GWFPVoLXsATxjAtZIdY4HVh8=;
        b=n3Xg/H/C9+09K/Wz8wehAEfeI/tauu+ZfELGEP9h4hJqIAPqTBmhWInQ9iKezON7L6
         3gaI1VuO7Dl8is3SeapVqIXFc4O0aoCJ6DgnyLK2ATjY/WQ62yCVPyvrIXSSp88cUqcm
         9wrdKobf42ZIulDWaC33CnsqR+sWVchEOrCKE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747921759; x=1748526559;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sx+KRYDTbT4B3nMPYW7GWFPVoLXsATxjAtZIdY4HVh8=;
        b=MhEHA50plYwvszTNgMqDEp7dmVq0kAk+5evWxp5Gjoat1zx2L2np1tiBr92ZMixZNq
         mw0eSMUyYBL5m56AxamThrhQZP4eyyd60PzqeMZlv6fXD09gTDPrWZY6qMJ7ZZtddUxu
         /hoQnCAxHwBoULmkUbvC/gU8YHAuBktjdQkYR8oEGhiguUju44FyHjKNfCqP+rSMDwCj
         8RbyHmTxqKtzA65ne3b8UovclLAZBqx/dhdWMASDefQdHC0JOTCpUKNXNgPIr7T6nr9K
         J0sEtlNQRrvI+g1dsycFZgCfyTAQ+fu7VUIC+rqHJLMzoAGZBu0KbYDQDlX1M4ThrKTB
         65Fw==
X-Gm-Message-State: AOJu0Yy3mkqKN6ZtylErr70vxovFc3qMPRZNUatF1m4IyQ1NOFds8Mze
	E9jdJmLZgxq4fzkeIApCVUFy5rH7BRpwkUusfS3bj+IBTP5GaPbNt8Lq7S2AS+yo8/o=
X-Gm-Gg: ASbGncuu6I2hS/tlFBDiNnAU4BbyiPGeOanxJgJ+JCXSq9HKjfACE094BpkRBY0n6Ht
	ngZLB9WGnl7n5GzHEPTzwneJ/HNj/tdOj6ZFXhCqFpW11XU0AokHeqvlRrf5tyX7jRE4GS2gcvj
	b5oowooOX4LKGF1HCR5fMLqBEQSkaIkHqkBt1HlZ0HSkmtS1GFNYHEBUK8FceIvMpUW8kMGpLrP
	tr0NSM5eDIA0vN+w86OdS6pQRh9/DV4dJv0FjOdfjwpAXdHBnp9REXk2OAKlXdVK+FSGjRyh0gS
	xgAaeC5nP8ADde545E0WMNnFRqDa1ftC7oq1AVM8Anm/4WqdvVVGopvru9DDARV/opZ2lq1xDX1
	BhQMAP/USE/1xgdLk2tNpi8dBu2c=
X-Google-Smtp-Source: AGHT+IGamR/mwYWGakxFKoH/whk9DRF2mx2ZZvJF6DwpwquDxCkWl4+GhlCILc/2o1OYheiWa3Kz0g==
X-Received: by 2002:a17:907:1b1b:b0:ad2:40a1:7894 with SMTP id a640c23a62f3a-ad536f9db58mr2124747766b.41.1747921758820;
        Thu, 22 May 2025 06:49:18 -0700 (PDT)
Message-ID: <49f092f9-c0fb-4b66-af20-368c736dde91@citrix.com>
Date: Thu, 22 May 2025 14:49:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [Eclair false positive] Re: [PATCH] x86/msr: Rework wrmsr_safe()
 using asm goto()
To: Nicola Vetrini 
Cc: Xen-devel ,
 Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , consulting@bugseng.com,
 Stefano Stabellini 
References: <20250521143658.312514-1-andrew.cooper3@citrix.com>
 <8504aab1-c48a-4981-a502-93a2fd18880b@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

On 22/05/2025 1:45 pm, Nicola Vetrini wrote:
> On 2025-05-21 20:00, Andrew Cooper wrote:
>> On 21/05/2025 3:36 pm, Andrew Cooper wrote:
>>> diff --git a/xen/arch/x86/include/asm/msr.h
>>> b/xen/arch/x86/include/asm/msr.h
>>> index 0d3b1d637488..4c4f18b3a54d 100644
>>> --- a/xen/arch/x86/include/asm/msr.h
>>> +++ b/xen/arch/x86/include/asm/msr.h
>>> @@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr,
>>> uint32_t lo, uint32_t hi)
>>>  /* wrmsr with exception handling */
>>>  static inline int wrmsr_safe(unsigned int msr, uint64_t val)
>>>  {
>>> -    int rc;
>>> -    uint32_t lo, hi;
>>> -    lo = (uint32_t)val;
>>> -    hi = (uint32_t)(val >> 32);
>>> -
>>> -    __asm__ __volatile__(
>>> -        "1: wrmsr\n2:\n"
>>> -        ".section .fixup,\"ax\"\n"
>>> -        "3: movl %5,%0\n; jmp 2b\n"
>>> -        ".previous\n"
>>> -        _ASM_EXTABLE(1b, 3b)
>>> -        : "=&r" (rc)
>>> -        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
>>> -    return rc;
>>> +    uint32_t lo = val, hi = val >> 32;
>>> +
>>> +    asm_inline goto (
>>> +        "1: wrmsr\n\t"
>>> +        _ASM_EXTABLE(1b, %l[fault])
>>> +        :
>>> +        : "a" (lo), "c" (msr), "d" (hi)
>>> +        :
>>> +        : fault );
>>> +
>>> +    return 0;
>>> +
>>> + fault:
>>> +    return -EFAULT;
>>>  }
>>
>> It turns out this is the first piece of Eclair-scanned code using asm
>> goto.
>>
>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10108558677
>> (The run also contained an equivalent change to xsetbv())
>>
>> We're getting R1.1 and R2.6 violations.
>>
>> R1.1 complains about [STD.adrslabl] "label address" not being valid C99.
>>
>> R2.6 complains about unused labels.
>>
>> I expect this means that Eclair doesn't know how to interpret asm goto()
>> yet.  The labels listed are reachable from inside the asm block.
>>
>
> That has been fixed upstream. I'll reach out to you when that fix
> trickles down to the runners, so that you're able to test and push
> that change.

Oh, fantastic thanks.

I'll hold off pushing until then.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu May 22 13:49:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 13:49:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994009.1377048 (Exim 4.92)
	(envelope-from )
	id 1uI6Ir-0001Hg-Jk; Thu, 22 May 2025 13:49:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994009.1377048; Thu, 22 May 2025 13:49: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 1uI6Ir-0001HZ-G8; Thu, 22 May 2025 13:49:45 +0000
Received: by outflank-mailman (input) for mailman id 994009;
 Thu, 22 May 2025 13:49:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI6Ip-0000u0-Ka
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 13:49:43 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9d2895d1-3713-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 15:49:43 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-602346b1997so3355164a12.3
 for ; Thu, 22 May 2025 06:49:43 -0700 (PDT)
Received: from [10.0.5.8] ([213.235.133.42]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d490794sm1086836666b.131.2025.05.22.06.49.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 06:49:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9d2895d1-3713-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747921782; x=1748526582; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=bguN6QIP6SXRfeuBxWBu86UjfJCaa83xJednlwyBjlY=;
        b=DQt/nE2+ZXNW4mXFQvHNubPhMWTiSwkRRc/4hdaReOZd8i8z5vFHQRs9kbeRRI91NI
         ZoQilUFZ+SntI++TXoc5vMyP97HA62LHpiK5D/47DKNtVDECfCmwGPSuQj42l3adh8i8
         aSDjNCpxWwMOJCBSmspbvRNB+l1Zt+INMGFvFSHM0Z4szIIsIId0NXCLyKkCp09jKiXU
         ohzKxmYXdn+kNxvoSoDErunwg73dRX2Q2lxqmxX4w2DiQB3Lq/rTCmaa7xnlbvdFBDvk
         Cqk0lBzffi4W8P/3gOgv8gNkp0YB4dc+mHGx53UxLMWh5GtIU6lQRQKESwUjmCPYDqcB
         m5dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747921782; x=1748526582;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=bguN6QIP6SXRfeuBxWBu86UjfJCaa83xJednlwyBjlY=;
        b=PZXfvk1jnfKDmw4hwqI2bz6I/jVNitBGzxU0bOLG+dgTjX1XOsoOlwKPydj7B/tXBv
         E/q2nf5nWkWiC93w0Q7ITUm2VFxmQVT22iOY6f2RqB4OQY0EZDMQV6Gg20XwZrbBSELg
         1CpeyM71XROCOdBuC2tbf8SBE6e/nUerBfgT8ZL1GShonOWcxgamrlqlQHUlgy+T/QMz
         prFFUauhKyVpaUwDEEAp0aB+LlxEKKOf4SBKnGqyi39sfGkGFQ/POgLz3POsL+p7vkIT
         iGJAp6+JpDBw4v/zi7SuI2t8QyEKlJi/wwA1EMGdPnbhnPcUMHCnB96zsOpIggQLrJDJ
         8mdA==
X-Forwarded-Encrypted: i=1; AJvYcCVrpMwuwNDK0TWwZYvkk/DmX6GDchL2oESJjF5islOInMxkg1SfY0c3D56Tb1d8+8xFIXAnjdDavg0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyienNYYo6rwUgMCx4CQO44sUwkcItl+3iXYQK00iMOzqv6Lhs1
	Xkb3ekPfMpAA9H2TRuXPkbw3RgMDOj5Cq7rAiw+ZrXuyqx0m/kxvmRwaeyw7pyjWXg==
X-Gm-Gg: ASbGnctEnNcDXPf71iIv9+k8+3OCTSMWVFJ8XAgRWPlZfrCj5uSNIm/KBo+xzBxvaxg
	XFMGt43LMVI9xnYEPCyx9Hl5CSHkekhABEIf5zbKr1Kkxl0dy5C6YcnCS8Ur6r60xhM4bOmDhV1
	stp894a0bKPv+rv6zR30awWwTVFahLfVBbWTdjqb7DNZIeoM0aTIFlyxo7TR1pKEtcZnyaPT9Is
	4S4eU2LjdpSqdVlXO5bMGHLkGCX8u5ECi5/WhMQcO6d0a8Y/vnoC+OjlT/CD6odf3/424SIVlpr
	eMJPSNcgaL3l18SpgUM=
X-Google-Smtp-Source: AGHT+IHVZTm7TS2S00qnyi38JmIODR3gNER1tTUeFvB+3ypKJ7tIJe5QmJQTZaxgqr60N+QceaFTSg==
X-Received: by 2002:a17:907:708:b0:ad5:c462:3f60 with SMTP id a640c23a62f3a-ad5c46240c4mr368090166b.16.1747921782430;
        Thu, 22 May 2025 06:49:42 -0700 (PDT)
Message-ID: <3d87f964-4836-43db-8d98-cfa8bcb0c167@suse.com>
Date: Thu, 22 May 2025 15:49:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 07/14] xen/riscv: introduce register_intc_ops() and
 intc_hw_ops.
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> Introduce the intc_hw_operations structure to encapsulate interrupt
> controller-specific data and operations. This structure includes:
> - A pointer to interrupt controller information (`intc_info`)
> - Callbacks to initialize the controller and set IRQ type/priority
> - A reference to an interupt controller descriptor (`host_irq_type`)
> - number of interrupt controller irqs.
> 
> Add function register_intc_ops() to mentioned above structure.
> 
> Co-developed-by: Romain Caritey 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu May 22 13:59:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 13:59:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994023.1377058 (Exim 4.92)
	(envelope-from )
	id 1uI6SB-0003HF-D3; Thu, 22 May 2025 13:59:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994023.1377058; Thu, 22 May 2025 13:59: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 1uI6SB-0003H8-A2; Thu, 22 May 2025 13:59:23 +0000
Received: by outflank-mailman (input) for mailman id 994023;
 Thu, 22 May 2025 13:59:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI6S9-0003H2-Pl
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 13:59:22 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20618.outbound.protection.outlook.com
 [2a01:111:f403:2613::618])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f46ed1bf-3714-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 15:59:19 +0200 (CEST)
Received: from AS4PR09CA0025.eurprd09.prod.outlook.com (2603:10a6:20b:5d4::15)
 by VI1PR08MB5517.eurprd08.prod.outlook.com (2603:10a6:803:139::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 13:59:16 +0000
Received: from AMS0EPF000001B7.eurprd05.prod.outlook.com
 (2603:10a6:20b:5d4:cafe::1a) by AS4PR09CA0025.outlook.office365.com
 (2603:10a6:20b:5d4::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 22 May 2025 13:59:16 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF000001B7.mail.protection.outlook.com (10.167.16.171) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Thu, 22 May 2025 13:59:14 +0000
Received: from AM8PR08MB6578.eurprd08.prod.outlook.com (2603:10a6:20b:36a::15)
 by GV1PR08MB8331.eurprd08.prod.outlook.com (2603:10a6:150:86::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Thu, 22 May
 2025 13:58:41 +0000
Received: from AM8PR08MB6578.eurprd08.prod.outlook.com
 ([fe80::bb1a:3ac6:3110:e2d5]) by AM8PR08MB6578.eurprd08.prod.outlook.com
 ([fe80::bb1a:3ac6:3110:e2d5%4]) with mapi id 15.20.8769.019; Thu, 22 May 2025
 13:58: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" 
X-Inumbo-ID: f46ed1bf-3714-11f0-a2fb-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=qOpWW4US4b/qXM2hcFYpRmO7HQ77vM+i19M/h0aSnLp7zLZRaP3tNbZyYbYT48vPxjRAce+0iJgirTVIBdgo+B3U5W+ZWDIijnUSDzEcyPknSMFA9C2o5PT39PRElV3IODPb+hTEfBxfkCXQ0WmKS45uVSfmuzkUEy9gtPxPZgICVnXA9hsAwoLIpdRQm9iP+MHeFQ+6sp2wrkaRa7VXymzMFVIDSDoPfyWyEtoKlNgnGd5YIenPD22cSTw0QW3LS3wA5LsWZAzhXSGREe9Vb9xp3apZJpC3f/2ASB2lnt1MtNqfuJxUudKNkLKo/UUODrM3TZekPVlfAaFvYqXkhg==
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=A1mILizijNvBHuu2LUFDZabhTpAs+Wfc8l4lB3Q9dnk=;
 b=HmSDyrj94PuiUa0iYaXYw2nQHhzfjupptbdrFRS7KSrZLbD7UgUrPbOO7tbjfA2qX1ADwR2k8ui55epywi3VYhvV9DHm0I7J9Ub2/1aa/AOst/ppiGlB9lzmW0Bt0DMJfrba2+X16rIzUmz5SjGW2ZyDFSbH4A3Cpk8OFwdevdkggKAIQDQB4Tdiy4LUFeBzV+VJ6CPBMf5P8K3Z74Jfj3c2JeDvEBcVXV9OoFKIdjN0dHC7O3x9hRQldV9dHyx5uGiTKH6cVOVOsbaykNAcOYpk4WJ+HMLXF+hPdfiBNOI6QRZ3oLsGbnVzeVMEqNZ/Cob4Ycb0n0QnKnp8dTwOgQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=linaro.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=A1mILizijNvBHuu2LUFDZabhTpAs+Wfc8l4lB3Q9dnk=;
 b=oqbFOuaxwgjxdjRxNwpID9YMZzoU3Pa8zk1vFgQ40qv8flGsC+3H6gTW+/YVSK0CNHj7XwpfqBJqx3afT1vheSsogTYYbXoMgu1qRdP9hdcnOHmJmAPV2XxoyJAQLSKNEKBzrKI5fmkGT2DIf/PkdBrHIOayGrj1hsP4bVSztcY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=f6C2B02cIi3coKL6f9WGI0QhJLWfZ+XWqhI9MnJXhyQcCIT+rU0O16lH8oHpeK5dU2RcIc/z93mhQNzxJ4Nmwu5QNvA1l+vsOwd0+6yCuKVXxYVftQoluUeKX+3JXf2X3n24s1rU4gKYWcnpZ9X2hVL1+JWqSZpTqybN7pnC+WrDtWI0+DuUXFOHIf5uEU0a7lBjO/y5F3b1Hh54bzF55Pato+gIZgCoQzciWEJxZ6Qhqd+sbaTt8stc/qbWKMRhRtkgKyqQI5KyLoZi9RbpIg/saFddNBsIJjHXCAV9IAJaTM5yWHWmWqUNm3myU9dy9alPFZjD9j+JlXGw1HOLHg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=A1mILizijNvBHuu2LUFDZabhTpAs+Wfc8l4lB3Q9dnk=;
 b=pECCeQD/A4qbacfF7n+fbVjfsy4w8Pe2rEaK0rNHFIBvyfaCmcUXD3XhDaCAWhMAbwoMZU2ms4xbgMsG54xxKklEZBwqMWR8GqmmUOTCSRKZN8prukM/gqAxBm/r5Q8zU+bkY7mbPPE23ffvKIj72KtVt6gNNN7AhzuOTZlaZHQ1DV4SUt7XCrdXe/RnhrDuiWufMlq7DcGfqEnMm234sj/fWsHesYQPXUtPvBObQSq10E3mlDKqymZ/pRdsLglzeyYsQz7hD31LxxrS7VRJqOgd/NiQd9hMlTUjCa8Bt9OfSZnAKzfYZ9JSWf1l++FAXHRkSK+zO01AO0zkSHyKlw==
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=A1mILizijNvBHuu2LUFDZabhTpAs+Wfc8l4lB3Q9dnk=;
 b=oqbFOuaxwgjxdjRxNwpID9YMZzoU3Pa8zk1vFgQ40qv8flGsC+3H6gTW+/YVSK0CNHj7XwpfqBJqx3afT1vheSsogTYYbXoMgu1qRdP9hdcnOHmJmAPV2XxoyJAQLSKNEKBzrKI5fmkGT2DIf/PkdBrHIOayGrj1hsP4bVSztcY=
From: Bertrand Marquis 
To: Jens Wiklander 
CC: "xen-devel@lists.xenproject.org" ,
	Volodymyr Babchuk , Stefano Stabellini
	, Julien Grall , Michal Orzel
	
Subject: Re: [PATCH v5 6/6] xen/arm: ffa: Enable VM to VM without firmware
Thread-Topic: [PATCH v5 6/6] xen/arm: ffa: Enable VM to VM without firmware
Thread-Index:
 AQHbrqLcLBT6scPDY02nTshBGWfMDLPegcqAgAAE8ICAAAOdgIAACw0AgAAvnACAACDtgA==
Date: Thu, 22 May 2025 13:58:41 +0000
Message-ID: <0448FE4F-68B3-4320-B3CC-DA8C87FF6181@arm.com>
References: 
 
 
 
 
 <54AE155E-5D83-4C45-B21C-7BB264ADB7E9@arm.com>
 
In-Reply-To:
 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.500.181.1.5)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	AM8PR08MB6578:EE_|GV1PR08MB8331:EE_|AMS0EPF000001B7:EE_|VI1PR08MB5517:EE_
X-MS-Office365-Filtering-Correlation-Id: 5702aa7a-7744-43a7-3084-08dd9938d62c
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|366016|10070799003|1800799024|376014|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?Z0pFazUzOHJNM1drRkRxa0VUNTlMUjFWM1kwRlphbWdjbUlZVkpDU0NYTm5H?=
 =?utf-8?B?VUlUWW5EaTNXdUhIb0RkZ3FCL1NoZ1h6MkY0WDI5bXNxelc2Tld2NlFtc2l5?=
 =?utf-8?B?ejBWOExrTmtzQTZVb25wNFpNdlZZZFRXWVJoMnFxZjdBZGU4Y0RSSmZqUUdq?=
 =?utf-8?B?cCt6b1lyZnNWVklKRjVSWnJPTTJ6QXprS2FEeFU1cS9lSGNxejlqRmZLbUVq?=
 =?utf-8?B?VGtBZ2drWmVHTEhteTN5bE1XNEJocjRiajhORmUzTU9icjdrM2dqKzBOTVl1?=
 =?utf-8?B?cytReVFNQnB2NDBXOGszNGZBK3Z1QzJtUzlSY0xaemw4K0pTbU1rb08yWEk1?=
 =?utf-8?B?RmkxbGluNVhqYUdIZFNibm1vWUFsV0FxbDBSdGFFeU1xUEI5Y20wYmxBSnNM?=
 =?utf-8?B?cnhqb3VjK3lxNnI4KzF0V3NHYVlYeEthbG5VNjlZeVJyQldNcGdwRFlGcW41?=
 =?utf-8?B?eEVudzkzWkxjelFaSFUyWVc1bXpKT1VzVmNkQkNIUGhYWDQrdlpRRkUyWHFV?=
 =?utf-8?B?QVdmKzBCTjJZcHpDU2RQZ2pWOVVHUTQ4YlZKcStLMEFKSDZBSGdQU3ZHQ2F0?=
 =?utf-8?B?WXUrc2ZrMWlicklRQ0pnOCtqaXBRcUxIaW40eHlldVk3YUhrb1QvWC84UXB1?=
 =?utf-8?B?TjdvQTFKdTd4aW5hVUZOVnAyUEdkdVBDZGJFVWIyZDhEdk9INDRVVklRNmFD?=
 =?utf-8?B?UTV2K2d6clc1dFBNalQ0UjZRYWZlbzZBRWNrNXluNmFnYVFDZnIwbGxFQXM4?=
 =?utf-8?B?S2lBc0xyTzZsWFI4ejEzTlFtdVZVQlpnMWFyamdUMFJ6dmxndDdWMS9PY0t1?=
 =?utf-8?B?dGZSS0toQUs4N25iTmpaU2FBSm5YWlByWGgzS3NQL0dtREh3SGRCMEk0ME81?=
 =?utf-8?B?WHpXY3cvVkYzZWdxSUloeENvOE0vTTJVNGJTa04xT0NtU0RyS3pDbkhKYnRX?=
 =?utf-8?B?Nm5jaGluUEx2K3ZFUTk1T0oxZHo1eU5sQlY1MlpYRE5YQ1lQMXJodUZ5U2N2?=
 =?utf-8?B?WkpocEJGRGVTcVFmd3hLZnArOE90VU52R0NNaDNYcmFxbzV5UUZJQXB0QWhY?=
 =?utf-8?B?VzJjeW5KajFIN0tmUjhobVVuRHpyaWhYVWRJM1ZWb1krQVhWNU15WFBtdTh5?=
 =?utf-8?B?S0thL2JjL2FURjBzVWJudUkzRnp1Rms2Y2pnNlVCKy9JdWprOEkwN0R5MFFV?=
 =?utf-8?B?WFM0SDlNWERoR2ZTS09jM3Voaml0UitUWStsek5IOUpQeFVEZ1BKaldLcWF5?=
 =?utf-8?B?dzB5NEJFTHRXckV6OGZXOHNQTVpuZDdJVHEvSy9CKy96NUNIc0Z1bC9iR0cv?=
 =?utf-8?B?UnhHSlM2aDBkMFBZeUZYMkNYL2dzd00yMS9qSE9YQ2tYNFJ3Sm45OGptWjFO?=
 =?utf-8?B?QnEvcGxNT1M3WU9DeHd0dFFtbFFWR29UNjJHVTVxMFFjWm13ZUhEc2RLSVln?=
 =?utf-8?B?Ukt6L21WUld5a0F2MmJzNklHUFlsTEdKSkQ1RjQrc25JNUlTTDNaaUNPNnhT?=
 =?utf-8?B?VERkei9zbTBnT0l3dU5hbFNQb3ByNU5tSnUyckdrUCtoUlNWRWZ2Qjh0MGxG?=
 =?utf-8?B?OXZ0bG5PbWlBVkZTSFZoTFpsNjdKdGExQUpkTEg3LzdQZS94cFg4cEVMakhG?=
 =?utf-8?B?clA1MlM2YUxmcmduNHNpTGVkb1pPUUxsS0paNHMzZU5zd0NTbW5SS1VjUytG?=
 =?utf-8?B?djgrS0srVVJKTm0rUnVsNGI3Ty9Ja29MaXNKWE9xTUlwL3Q2aUZSaFZ2MDZj?=
 =?utf-8?B?SEJ4RW5aa0UwakZNN3ZKMmhjL0tsVjV5NDFJRkkzYUlLRzlaVnVvbmNXNzlo?=
 =?utf-8?B?eFNMcTJmSTVWZk1NcEYyYWhibzdISUNlRzZoRmpkZk92OEdlYVRlNmpwT0dl?=
 =?utf-8?B?RVpIaFZ5d3c0eXhiQkVrYTd0MjdPcDBCMnU0RUVicUsyVmJpczdyN0FjMGtR?=
 =?utf-8?B?SDVDMjBodDBsZUZ0NXhEa0tQcU03c2M5bjRrYlRWZU5LRXppeGc5RGxMcXhD?=
 =?utf-8?B?MHp3aEM2QkRRPT0=?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM8PR08MB6578.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(10070799003)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <631BA1A74C4A454DAA0849C2004BFD4D@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB8331
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF000001B7.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	5b749c7a-d2b4-4412-3292-08dd9938c251
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|35042699022|1800799024|14060799003|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dVl2ZElPT09mc3JjUnJLRHNYdFR3aXBOSGlEa2xFQVNkZlU0NUJCZnd3RmFz?=
 =?utf-8?B?bzJEMTVZU0dyYXNOeEhzZDBSeE4rWjZXVURhRDdoaDhoc0VucjloMVdyRjNV?=
 =?utf-8?B?U1lla2ZOc1kxRGdIak00SDJlSThPVU5wcDJrU1dCdkNmb1hHTUFhcTdweDc5?=
 =?utf-8?B?b3o3VjZvZ09jalRxZTIvY3pzUHNsS0M3RTN1ME1pOVhIQ0VaU2tad0l4bFZz?=
 =?utf-8?B?TEt3b3RGRnZjbUR2U3RSUldPSDZmSkd4dUlsSVRCK0Y2eUVDeGVhSW9wbmh5?=
 =?utf-8?B?ZGpRT1JNUmtRS01hNVN5M2dGTEFmZjAybGpreVJNci8zbnhod2ZKWnNaSkJ4?=
 =?utf-8?B?aklSNmZnQ3I2SUJ6RUJlUVRjRk1PL2ZsUW9ieU5ha1FYUEhPR2JsdzVJdzFW?=
 =?utf-8?B?Y2laSGIrdUt2TmU0aE9VdDJvckFSU0lkTVJkUFErT3VqcDl1NlYxbjVIOXkw?=
 =?utf-8?B?TnZ5cjNxTi9tdDZWUVZUWHpyd3N2S2dWaStPb1hRYkoyUXV6Rm96Y1BEVXNw?=
 =?utf-8?B?VEpGU203MDg0UVhZcjVRM3h6bzlwaU5jLzYwbTBNOVE1aVAweXZkNDQ4M2NP?=
 =?utf-8?B?aGdxdGJOL1VIUFNpdy9CaGRhbFJKN2g4eWVHckZEelpwbWFnSjcxV2w4Qm1r?=
 =?utf-8?B?T2pENWNHZEpzdlZhZlByQ1AxYXB6Y1I0Z3NFUVVrNkFVWGNIUVpZcmp4UFlI?=
 =?utf-8?B?bzk1L3JsZ2FhNGpDMDZhbFhOcTR6WnZOMW54dXpYSDYrQUN4QUJZQ3NuK0I2?=
 =?utf-8?B?VEs0VFNGalIySWlaVUVOaGZCSWk3cFUwNEd0bHJENklKcEdzTlphazVOcWNE?=
 =?utf-8?B?OW5jS2YvbG9lVGMvOFNzRWMrTHlwT1F2dVI1RkMvNlNQUjBVN1h3ZmkzRkFr?=
 =?utf-8?B?ZWoyVCtZOVB4aCt2ZVU1Mzdha05LMUc2anYyNUxIWmVCaENObTU3UmZoRXJS?=
 =?utf-8?B?VC9GSFpoNEEvbU42NDh3cXVob2E4ZjV0Q2E5VURYcXZJQlJrUmxzODdzWi9U?=
 =?utf-8?B?STVZVWsyUkVwSFh1cmZMTEYzc25qWjhwRHQ5YjRHKzcwdUpWclAzcnYwTytN?=
 =?utf-8?B?WU9GTEpnSzI2a0lVallORXNQeXNjd2Y3UGQvbi9EMGRncnFFMG1WOHZaVHla?=
 =?utf-8?B?OEdWZGVzVFZMOC9ycXNjdUN4UEJhVTFkVWlObVBGa1NhTG5rZ3hVaVd0cm1r?=
 =?utf-8?B?MysrcllsbENyY0VvenRnODRIVnlibjlZQjUvR2N3ZEZpZnpVMERFZFpJRm5L?=
 =?utf-8?B?aHBza2hqNW55bkNhN3NuRDNwejRRL0hMR1dzKzhraVR3QUpRMDZ0QVYrL3Ns?=
 =?utf-8?B?UmMyUGphc2lheTU1N1dUTWRtOVJsYm0rWXNSZVNGMWxKUnhlejl6eDd1ekg1?=
 =?utf-8?B?b3NrMERNcUxIM1ptaGU2dCtOb2VnTlhsVWhXWWVsZ202K3VpVFFZb2dMbWln?=
 =?utf-8?B?eDh5NzM1M0hBZ2w4RSsrdU13WDd0UHc5MjRHZnVoNlNGMzVPVWxiODhVUjlk?=
 =?utf-8?B?bFRra1E5bHdLQWUwMkpyL1BNUW5XVGxvZkxrZE5URTNKSmQzWlB4U0hYUEdj?=
 =?utf-8?B?cnlLWUlaQjlzSUVuQVNWcjc1dlhPbm1iQmk3NlYwTWZERE9ndHAzWEVjU1ZE?=
 =?utf-8?B?bnFzZ21FdnpWK2NSYmJCcU92bnpqNXVpK2dGWkhDQWJrNEQ5RmNnWk9BcWhu?=
 =?utf-8?B?dGsvTFJnbjRzT1piRmxkNi9iQTc1U1piRmIvTUE3V3NXczJBdTBYQ0Vld0dZ?=
 =?utf-8?B?RXVLaUpIVU5PZkpxcityczFnOW5lRUZGSFlWL2xzMHJXOXEwY0VMQTQwUUY2?=
 =?utf-8?B?SlhtNUxxL1VFcTBNTER4T2xhVTNaVmdUcUVHa00xZ2h6YW5aZ0I1a1IrcTFY?=
 =?utf-8?B?clNZTlJicWN5d3ZDSk9hd2F0VlJ0czc2M1BvRGFwdGllaVhOWG9NVzZhY3N0?=
 =?utf-8?B?NEkrRjlYZzErUFBKVHE1SGYzM1hCMkZIdVpheVpVQVZIdzBZWHdTRmRPODhz?=
 =?utf-8?B?cmNBMC96OEhSbmZmS1daTWlhOHBNRVZuL0sxMUZpc0poWkVtdi9QNDhmSUdE?=
 =?utf-8?Q?qJdgGN?=
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)(36860700013)(376014)(35042699022)(1800799024)(14060799003)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 13:59:14.5982
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5702aa7a-7744-43a7-3084-08dd9938d62c
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:
	AMS0EPF000001B7.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5517

SGkgSmVucywNCg0KPiBPbiAyMiBNYXkgMjAyNSwgYXQgMTQ6MDAsIEplbnMgV2lrbGFuZGVyIDxq
ZW5zLndpa2xhbmRlckBsaW5hcm8ub3JnPiB3cm90ZToNCj4gDQo+IEhpIEJlcnRyYW5kLA0KPiAN
Cj4gT24gVGh1LCBNYXkgMjIsIDIwMjUgYXQgMTE6MTHigK9BTSBCZXJ0cmFuZCBNYXJxdWlzDQo+
IDxCZXJ0cmFuZC5NYXJxdWlzQGFybS5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBKZW5zLA0KPj4g
DQo+Pj4gT24gMjIgTWF5IDIwMjUsIGF0IDEwOjMwLCBKZW5zIFdpa2xhbmRlciA8amVucy53aWts
YW5kZXJAbGluYXJvLm9yZz4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGksDQo+Pj4gDQo+Pj4gT24gVGh1
LCBNYXkgMjIsIDIwMjUgYXQgMTA6MTjigK9BTSBCZXJ0cmFuZCBNYXJxdWlzDQo+Pj4gPEJlcnRy
YW5kLk1hcnF1aXNAYXJtLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBIaSBKZW5zLA0KPj4+PiAN
Cj4+Pj4+IE9uIDIyIE1heSAyMDI1LCBhdCAxMDowMCwgSmVucyBXaWtsYW5kZXIgPGplbnMud2lr
bGFuZGVyQGxpbmFyby5vcmc+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiBIaSBCZXJ0cmFuZCwNCj4+
Pj4+IA0KPj4+Pj4gT24gV2VkLCBBcHIgMTYsIDIwMjUgYXQgOTo0MOKAr0FNIEJlcnRyYW5kIE1h
cnF1aXMNCj4+Pj4+IDxiZXJ0cmFuZC5tYXJxdWlzQGFybS5jb20+IHdyb3RlOg0KPj4+Pj4+IA0K
Pj4+Pj4+IFdoZW4gVk0gdG8gVk0gc3VwcG9ydCBpcyBhY3RpdmF0ZWQgYW5kIHRoZXJlIGlzIG5v
IHN1aXRhYmxlIEZGLUEgc3VwcG9ydA0KPj4+Pj4+IGluIHRoZSBmaXJtd2FyZSwgZW5hYmxlIEZG
LUEgc3VwcG9ydCBmb3IgVk1zIHRvIGFsbG93IHVzaW5nIGl0IGZvciBWTSB0bw0KPj4+Pj4+IFZN
IGNvbW11bmljYXRpb25zLg0KPj4+Pj4+IElmIHRoZXJlIGlzIE9QLVRFRSBydW5uaW5nIGluIHRo
ZSBzZWN1cmUgd29ybGQgYW5kIHVzaW5nIHRoZSBub24gRkYtQQ0KPj4+Pj4+IGNvbW11bmljYXRp
b24gc3lzdGVtLCBoYXZpbmcgQ09ORklHX0ZGQV9WTV9UT19WTSBjb3VsZCBiZSBub24gZnVuY3Rp
b25hbA0KPj4+Pj4+IChpZiBvcHRlZSBpcyBwcm9iZWQgZmlyc3QpIG9yIE9QLVRFRSBjb3VsZCBi
ZSBub24gZnVuY3Rpb25hbCAoaWYgRkYtQSBpcw0KPj4+Pj4+IHByb2JlZCBmaXJzdCkgc28gaXQg
aXMgbm90IHJlY29tbWVuZGVkIHRvIGFjdGl2YXRlIHRoZSBjb25maWd1cmF0aW9uDQo+Pj4+Pj4g
b3B0aW9uIGZvciBzdWNoIHN5c3RlbXMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gVG8gbWFrZSBidWZmZXIg
ZnVsbCBub3RpZmljYXRpb24gd29yayBiZXR3ZWVuIFZNcyB3aGVuIHRoZXJlIGlzIG5vDQo+Pj4+
Pj4gZmlybXdhcmUsIHJld29yayB0aGUgbm90aWZpY2F0aW9uIGhhbmRsaW5nIGFuZCBtb2RpZnkg
dGhlIGdsb2JhbCBmbGFnIHRvDQo+Pj4+Pj4gb25seSBiZSB1c2VkIGFzIGNoZWNrIGZvciBmaXJt
d2FyZSBub3RpZmljYXRpb24gc3VwcG9ydCBpbnN0ZWFkLg0KPj4+Pj4+IA0KPj4+Pj4+IFNpZ25l
ZC1vZmYtYnk6IEJlcnRyYW5kIE1hcnF1aXMgPGJlcnRyYW5kLm1hcnF1aXNAYXJtLmNvbT4NCj4+
Pj4+PiAtLS0NCj4+Pj4+PiBDaGFuZ2VzIGluIHY1Og0KPj4+Pj4+IC0gaW5pdCBjdHggbGlzdCB3
aGVuIHRoZXJlIGlzIG5vIGZpcm13YXJlDQo+Pj4+Pj4gLSByZXdvcmsgaW5pdCBhIGJpdCB0byBw
cmV2ZW50IGR1cGxpY2F0ZXMNCj4+Pj4+PiAtIFJlbW92ZSBKZW5zIFItYiBkdWUgdG8gY2hhbmdl
cyBkb25lDQo+Pj4+Pj4gQ2hhbmdlcyBpbiB2NDoNCj4+Pj4+PiAtIEZpeCBPcHRlZSB0byBPUC1U
RUUgaW4gY29tbWl0IG1lc3NhZ2UNCj4+Pj4+PiAtIEFkZCBKZW5zIFItYg0KPj4+Pj4+IENoYW5n
ZXMgaW4gdjM6DQo+Pj4+Pj4gLSBmaXggdHlwb3MgaW4gY29tbWl0IG1lc3NhZ2UNCj4+Pj4+PiAt
IGFkZCBzcGFjZXMgYXJvdW5kIDw8DQo+Pj4+Pj4gLSBtb3ZlIG5vdGlmaWNhdGlvbiBpZCBmaXgg
YmFjayBpbnRvIGJ1ZmZlciBmdWxsIHBhdGNoDQo+Pj4+Pj4gLSBmaXggfCBwb3NpdGlvbiBpbiBp
Zg0KPj4+Pj4+IENoYW5nZXMgaW4gdjI6DQo+Pj4+Pj4gLSByZXBsYWNlIGlmZGVmIHdpdGggSVNf
RU5BQkxFRCB3aGVuIHBvc3NpYmxlDQo+Pj4+Pj4gLS0tDQo+Pj4+Pj4geGVuL2FyY2gvYXJtL3Rl
ZS9mZmEuYyAgICAgICB8ICAyNCArKysrKystLQ0KPj4+Pj4+IHhlbi9hcmNoL2FybS90ZWUvZmZh
X25vdGlmLmMgfCAxMDQgKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+
PiAyIGZpbGVzIGNoYW5nZWQsIDY3IGluc2VydGlvbnMoKyksIDYxIGRlbGV0aW9ucygtKQ0KPj4+
Pj4+IA0KPj4+Pj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jIGIveGVuL2Fy
Y2gvYXJtL3RlZS9mZmEuYw0KPj4+Pj4+IGluZGV4IGMxYzRjMDk1NzA5MS4uYjg2Yzg4Y2VmYThj
IDEwMDY0NA0KPj4+Pj4+IC0tLSBhL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+Pj4+PiArKysg
Yi94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jDQo+Pj4+Pj4gQEAgLTM0Miw4ICszNDIsOSBAQCBzdGF0
aWMgaW50IGZmYV9kb21haW5faW5pdChzdHJ1Y3QgZG9tYWluICpkKQ0KPj4+Pj4+ICAgc3RydWN0
IGZmYV9jdHggKmN0eDsNCj4+Pj4+PiAgIGludCByZXQ7DQo+Pj4+Pj4gDQo+Pj4+Pj4gLSAgICBp
ZiAoICFmZmFfZndfdmVyc2lvbiApDQo+Pj4+Pj4gKyAgICBpZiAoICFJU19FTkFCTEVEKENPTkZJ
R19GRkFfVk1fVE9fVk0pICYmICFmZmFfZndfdmVyc2lvbiApDQo+Pj4+Pj4gICAgICAgcmV0dXJu
IC1FTk9ERVY7DQo+Pj4+Pj4gKw0KPj4+Pj4+ICAgLyoNCj4+Pj4+PiAgICAqIFdlIGFyZSB1c2lu
ZyB0aGUgZG9tYWluX2lkICsgMSBhcyB0aGUgRkYtQSBJRCBmb3IgVk1zIGFzIEZGLUEgSUQgMCBp
cw0KPj4+Pj4+ICAgICogcmVzZXJ2ZWQgZm9yIHRoZSBoeXBlcnZpc29yIGFuZCB3ZSBvbmx5IHN1
cHBvcnQgc2VjdXJlIGVuZHBvaW50cyB1c2luZw0KPj4+Pj4+IEBAIC01NzksMTEgKzU4MCw4IEBA
IHN0YXRpYyBib29sIGZmYV9wcm9iZSh2b2lkKQ0KPj4+Pj4+ICAgICAgIGdvdG8gZXJyX3J4dHhf
ZGVzdHJveTsNCj4+Pj4+PiANCj4+Pj4+PiAgIGZmYV9ub3RpZl9pbml0KCk7DQo+Pj4+Pj4gLSAg
ICBJTklUX0xJU1RfSEVBRCgmZmZhX3RlYXJkb3duX2hlYWQpOw0KPj4+Pj4+IC0gICAgSU5JVF9M
SVNUX0hFQUQoJmZmYV9jdHhfaGVhZCk7DQo+Pj4+Pj4gLSAgICBpbml0X3RpbWVyKCZmZmFfdGVh
cmRvd25fdGltZXIsIGZmYV90ZWFyZG93bl90aW1lcl9jYWxsYmFjaywgTlVMTCwgMCk7DQo+Pj4+
Pj4gDQo+Pj4+Pj4gLSAgICByZXR1cm4gdHJ1ZTsNCj4+Pj4+PiArICAgIGdvdG8gZXhpdDsNCj4+
Pj4+PiANCj4+Pj4+PiBlcnJfcnh0eF9kZXN0cm95Og0KPj4+Pj4+ICAgZmZhX3J4dHhfZGVzdHJv
eSgpOw0KPj4+Pj4+IEBAIC01OTIsNiArNTkwLDIyIEBAIGVycl9ub19mdzoNCj4+Pj4+PiAgIGJp
dG1hcF96ZXJvKGZmYV9md19hYmlfc3VwcG9ydGVkLCBGRkFfQUJJX0JJVE1BUF9TSVpFKTsNCj4+
Pj4+PiAgIHByaW50ayhYRU5MT0dfV0FSTklORyAiQVJNIEZGLUEgTm8gZmlybXdhcmUgc3VwcG9y
dFxuIik7DQo+Pj4+Pj4gDQo+Pj4+Pj4gK2V4aXQ6DQo+Pj4+Pj4gKyAgICBpZiAoIElTX0VOQUJM
RUQoQ09ORklHX0ZGQV9WTV9UT19WTSkgfHwgZmZhX2Z3X3ZlcnNpb24gKQ0KPj4+Pj4+ICsgICAg
ew0KPj4+Pj4+ICsgICAgICAgIElOSVRfTElTVF9IRUFEKCZmZmFfdGVhcmRvd25faGVhZCk7DQo+
Pj4+Pj4gKyAgICAgICAgSU5JVF9MSVNUX0hFQUQoJmZmYV9jdHhfaGVhZCk7DQo+Pj4+Pj4gKyAg
ICAgICAgaW5pdF90aW1lcigmZmZhX3RlYXJkb3duX3RpbWVyLCBmZmFfdGVhcmRvd25fdGltZXJf
Y2FsbGJhY2ssIE5VTEwsIDApOw0KPj4+Pj4+ICsgICAgfQ0KPj4+Pj4+ICsNCj4+Pj4+PiArICAg
IGlmICggSVNfRU5BQkxFRChDT05GSUdfRkZBX1ZNX1RPX1ZNKSApDQo+Pj4+Pj4gKyAgICB7DQo+
Pj4+Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19JTkZPICJBUk0gRkYtQSBvbmx5IGF2YWlsYWJs
ZSBiZXR3ZWVuIFZNc1xuIik7DQo+Pj4+PiANCj4+Pj4+IFRoaXMgc2hvdWxkIG9ubHkgYmUgcHJp
bnRlZCBpZiBmZmFfZndfdmVyc2lvbiA9PSAwDQo+Pj4+IA0KPj4+PiBSaWdodCBpIHdpbGwgZml4
IGJ1dCAuLi4NCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+PiArICAgICAgICByZXR1cm4gdHJ1ZTsNCj4+
Pj4+PiArICAgIH0NCj4+Pj4+PiArICAgIGVsc2UgaWYgKCBmZmFfZndfdmVyc2lvbiApDQo+Pj4+
PiANCj4+Pj4+IFRoZSBlbHNlIGlzbid0IG5lZWRlZC4NCj4+Pj4gDQo+Pj4+IHRoZSBlbHNlIGlz
IG5lZWRlZCBzbyB0aGF0IHdlIHJldHVybiB0cnVlIGFuZCBub3QgZmFsc2UuDQo+Pj4gDQo+Pj4g
SSBtZWFudCB0aGUgImVsc2UiIGlzbid0IG5lZWRlZCwgdGhlICJpZiIgaXMgc3RpbGwgbmVlZGVk
LCBhcyB5b3UgZXhwbGFpbi4NCj4+PiANCj4+Pj4gDQo+Pj4+IFdlIGhhdmUgMyBjYXNlczoNCj4+
Pj4gLSBmaXJtd2FyZSBpcyB0aGVyZTogcmV0dXJuIHRydWUNCj4+Pj4gLSBmaXJtd2FyZSBub3Qg
dGhlcmUgYnV0IHZtIHRvIHZtIGVuYWJsZTogcmV0dXJuIHRydWUNCj4+Pj4gLSBvdGhlcndpc2U6
IHJldHVybiBmYWxzZQ0KPj4+PiANCj4+Pj4gSSB3aWxsIG1vZGlmeSBpdCBsaWtlIHRoaXMgdG8g
bWFrZSBpdCBjbGVhcmVyOg0KPj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3RlZS9mZmEu
YyBiL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+Pj4gaW5kZXggNTdiNjQ4YTIyODQwLi43Njhi
NGU5ZWM5NjggMTAwNjQ0DQo+Pj4+IC0tLSBhL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+Pj4g
KysrIGIveGVuL2FyY2gvYXJtL3RlZS9mZmEuYw0KPj4+PiBAQCAtNjAxLDEzICs2MDEsMTMgQEAg
ZXhpdDoNCj4+Pj4gICAgICAgIGluaXRfdGltZXIoJmZmYV90ZWFyZG93bl90aW1lciwgZmZhX3Rl
YXJkb3duX3RpbWVyX2NhbGxiYWNrLCBOVUxMLCAwKTsNCj4+Pj4gICAgfQ0KPj4+PiANCj4+Pj4g
LSAgICBpZiAoIElTX0VOQUJMRUQoQ09ORklHX0ZGQV9WTV9UT19WTSkgKQ0KPj4+PiArICAgIGlm
ICggZmZhX2Z3X3ZlcnNpb24gKQ0KPj4+PiArICAgICAgICByZXR1cm4gdHJ1ZTsNCj4+Pj4gKyAg
ICBlbHNlIGlmICggSVNfRU5BQkxFRChDT05GSUdfRkZBX1ZNX1RPX1ZNKSApDQo+Pj4+ICAgIHsN
Cj4+Pj4gICAgICAgIHByaW50ayhYRU5MT0dfSU5GTyAiQVJNIEZGLUEgb25seSBhdmFpbGFibGUg
YmV0d2VlbiBWTXNcbiIpOw0KPj4+PiAgICAgICAgcmV0dXJuIHRydWU7DQo+Pj4+ICAgIH0NCj4+
Pj4gLSAgICBlbHNlIGlmICggZmZhX2Z3X3ZlcnNpb24gKQ0KPj4+PiAtICAgICAgICByZXR1cm4g
dHJ1ZTsNCj4+Pj4gDQo+Pj4+ICAgIHJldHVybiBmYWxzZTsNCj4+Pj4gfQ0KPj4+PiANCj4+Pj4g
VGVsbCBtZSBpZiB5b3UgYWdyZWUuDQo+Pj4gDQo+Pj4gWWVzLCB0aGlzIGlzIGFuIGltcHJvdmVt
ZW50LiBBIHJldHVybiBhdCB0aGUgZW5kIG9mIGFuIGlmIGJsb2NrIG1ha2VzDQo+Pj4gdGhlIGV2
ZW50dWFsIGZvbGxvd2luZyAiZWxzZSIgcmVkdW5kYW50LiBJIHN1cHBvc2UgdGhlcmUgYXJlIGNv
ZGluZw0KPj4+IHN0eWxlcyB3aGVyZSBpdCdzIHN0aWxsIHByZWZlcnJlZC4gSSdtIG5vdCBzdXJl
IGlmIHRoYXQgYXBwbGllcyBpbg0KPj4+IFhlbiwgdGhvdWdoLg0KPj4gDQo+PiBJIG5vdyBnZXQg
d2hhdCB5b3UgbWVhbiBhbmQgeW91IHdvdWxkIGxpa2UgdGhlIHJldHVybiBmYWxzZSB0byBiZSBp
biBhIGVsc2UuDQo+PiANCj4+IFJlbG9va2luZyBhdCB0aGUgY29kZSwgaSBhY3R1YWxseSBkbyBu
b3QgbGlrZSB0aGUgZmFjdCB0aGF0IHdlIGRvIHNvIG11Y2ggaW4NCj4+IGV4aXQgYW5kIGkgdGhp
bmsgaSBjYW4gbW92ZSBhIGJpdCB0aGUgY29kZSB0byBiZSBjbGVhcmVyOg0KPj4gLSBwdXQgdGhl
IGZ3IGluaXQgaW4gYSBzdWIgZnVuY3Rpb24NCj4+IC0gY3JlYXRlIGEgdm1fdG9fdm0gaW5pdCBm
dW5jdGlvbg0KPj4gLSBpbiBwcm9iZSBjYWxsIGJvdGggZnVuY3Rpb25zIGFuZCBkbyB0aGUgY29t
bW9uIGluaXQgcGFydCBpZiBhdCBsZWFzdCBvbmUgc3VjY2VkZWQNCj4gDQo+IEkgd2FzIHN0YXJ0
aW5nIHRvIHRoaW5rIGFsb25nIHRob3NlIGxpbmVzLCB0b28uIDotKQ0KPiANCj4+IA0KPj4gU29t
ZXRoaW5nIGxpa2UgdGhpczoNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5j
IGIveGVuL2FyY2gvYXJtL3RlZS9mZmEuYw0KPj4gaW5kZXggNTdiNjQ4YTIyODQwLi40MmRmYzcx
YTEyZDcgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jDQo+PiArKysgYi94
ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jDQo+PiBAQCAtNDc4LDM4ICs0NzgsMTIgQEAgc3RhdGljIHZv
aWQgZmZhX2luaXRfc2Vjb25kYXJ5KHZvaWQpDQo+PiAgICAgZmZhX25vdGlmX2luaXRfaW50ZXJy
dXB0KCk7DQo+PiB9DQo+PiANCj4+IC1zdGF0aWMgYm9vbCBmZmFfcHJvYmUodm9pZCkNCj4+ICtz
dGF0aWMgYm9vbCBmZmFfcHJvYmVfZncodm9pZCkNCj4+IHsNCj4+ICAgICB1aW50MzJfdCB2ZXJz
Ow0KPj4gICAgIHVuc2lnbmVkIGludCBtYWpvcl92ZXJzOw0KPj4gICAgIHVuc2lnbmVkIGludCBt
aW5vcl92ZXJzOw0KPj4gDQo+PiAtICAgIC8qDQo+PiAtICAgICAqIEZGLUEgb2Z0ZW4gd29ya3Mg
aW4gdW5pdHMgb2YgNEsgcGFnZXMgYW5kIGN1cnJlbnRseSBpdCdzIGFzc3VtZWQNCj4+IC0gICAg
ICogdGhhdCB3ZSBjYW4gbWFwIG1lbW9yeSB1c2luZyB0aGF0IGdyYW51bGFyaXR5LiBTZWUgYWxz
byB0aGUgY29tbWVudA0KPj4gLSAgICAgKiBhYm92ZSB0aGUgRkZBX1BBR0VfU0laRSBkZWZpbmUu
DQo+PiAtICAgICAqDQo+PiAtICAgICAqIEl0IGlzIHBvc3NpYmxlIHRvIHN1cHBvcnQgYSBQQUdF
X1NJWkUgbGFyZ2VyIHRoYW4gNEsgaW4gWGVuLCBidXQNCj4+IC0gICAgICogdW50aWwgdGhhdCBp
cyBmdWxseSBoYW5kbGVkIGluIHRoaXMgY29kZSBtYWtlIHN1cmUgdGhhdCB3ZSBvbmx5IHVzZQ0K
Pj4gLSAgICAgKiA0SyBwYWdlIHNpemVzLg0KPj4gLSAgICAgKi8NCj4+IC0gICAgQlVJTERfQlVH
X09OKFBBR0VfU0laRSAhPSBGRkFfUEFHRV9TSVpFKTsNCj4+IC0NCj4+IC0gICAgcHJpbnRrKFhF
TkxPR19JTkZPICJBUk0gRkYtQSBNZWRpYXRvciB2ZXJzaW9uICV1LiV1XG4iLA0KPj4gLSAgICAg
ICAgICAgRkZBX01ZX1ZFUlNJT05fTUFKT1IsIEZGQV9NWV9WRVJTSU9OX01JTk9SKTsNCj4+IC0N
Cj4+IC0gICAgaWYgKCBJU19FTkFCTEVEKENPTkZJR19GRkFfVk1fVE9fVk0pICkNCj4+IC0gICAg
ew0KPj4gLSAgICAgICAgLyoNCj4+IC0gICAgICAgICAqIFdoZW4gRkZBIFZNIHRvIFZNIGlzIGVu
YWJsZWQsIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uIGRvZXMgbm90DQo+PiAtICAgICAgICAg
KiBvZmZlciBhbnkgd2F5IHRvIGxpbWl0IHdoaWNoIFZNIGNhbiBjb21tdW5pY2F0ZSB3aXRoIHdo
aWNoIFZNIHVzaW5nDQo+PiAtICAgICAgICAgKiBGRi1BLg0KPj4gLSAgICAgICAgICogU2lnbmFs
IHRoaXMgaW4gdGhlIHhlbiBjb25zb2xlIGFuZCB0YWludCB0aGUgc3lzdGVtIGFzIGluc2VjdXJl
Lg0KPj4gLSAgICAgICAgICogVE9ETzogSW50cm9kdWNlIGEgc29sdXRpb24gdG8gbGltaXQgd2hh
dCBhIFZNIGNhbiBkbyB0aHJvdWdoIEZGQS4NCj4+IC0gICAgICAgICAqLw0KPj4gLSAgICAgICAg
cHJpbnRrKFhFTkxPR19FUlIgImZmYTogVk0gdG8gVk0gaXMgZW5hYmxlZCwgc3lzdGVtIGlzIGlu
c2VjdXJlICEhXG4iKTsNCj4+IC0gICAgICAgIGFkZF90YWludChUQUlOVF9NQUNISU5FX0lOU0VD
VVJFKTsNCj4+IC0gICAgfQ0KPj4gICAgIC8qDQo+PiAgICAgICogcHNjaV9pbml0X3NtY2NjKCkg
dXBkYXRlcyB0aGlzIHZhbHVlIHdpdGggd2hhdCdzIHJlcG9ydGVkIGJ5IEVMLTMNCj4+ICAgICAg
KiBvciBzZWN1cmUgd29ybGQuDQo+PiBAQCAtNTI4LDExICs1MDIsNiBAQCBzdGF0aWMgYm9vbCBm
ZmFfcHJvYmUodm9pZCkNCj4+ICAgICAgICAgZ290byBlcnJfbm9fZnc7DQo+PiAgICAgfQ0KPj4g
DQo+PiAtICAgIC8qIFNvbWUgc2FuaXR5IGNoZWNrIGluIGNhc2Ugd2UgdXBkYXRlIHRoZSB2ZXJz
aW9uIHdlIHN1cHBvcnQgKi8NCj4+IC0gICAgQlVJTERfQlVHX09OKEZGQV9NSU5fU1BNQ19WRVJT
SU9OID4gRkZBX01ZX1ZFUlNJT04pOw0KPj4gLSAgICBCVUlMRF9CVUdfT04oRkZBX1ZFUlNJT05f
TUFKT1IoRkZBX01JTl9TUE1DX1ZFUlNJT04pICE9DQo+PiAtICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBGRkFfTVlfVkVSU0lPTl9NQUpPUik7DQo+PiAtDQo+PiAgICAgbWFqb3Jf
dmVycyA9IEZGQV9WRVJTSU9OX01BSk9SKHZlcnMpOw0KPj4gICAgIG1pbm9yX3ZlcnMgPSBGRkFf
VkVSU0lPTl9NSU5PUih2ZXJzKTsNCj4+IA0KPj4gQEAgLTU4NCw3ICs1NTMsNyBAQCBzdGF0aWMg
Ym9vbCBmZmFfcHJvYmUodm9pZCkNCj4+IA0KPj4gICAgIGZmYV9ub3RpZl9pbml0KCk7DQo+PiAN
Cj4+IC0gICAgZ290byBleGl0Ow0KPj4gKyAgICByZXR1cm4gdHJ1ZTsNCj4+IA0KPj4gZXJyX3J4
dHhfZGVzdHJveToNCj4+ICAgICBmZmFfcnh0eF9kZXN0cm95KCk7DQo+PiBAQCAtNTkzLDIzICs1
NjIsNTkgQEAgZXJyX25vX2Z3Og0KPj4gICAgIGJpdG1hcF96ZXJvKGZmYV9md19hYmlfc3VwcG9y
dGVkLCBGRkFfQUJJX0JJVE1BUF9TSVpFKTsNCj4+ICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcg
IkFSTSBGRi1BIE5vIGZpcm13YXJlIHN1cHBvcnRcbiIpOw0KPj4gDQo+PiAtZXhpdDoNCj4+IC0g
ICAgaWYgKCBJU19FTkFCTEVEKENPTkZJR19GRkFfVk1fVE9fVk0pIHx8IGZmYV9md192ZXJzaW9u
ICkNCj4+IC0gICAgew0KPj4gLSAgICAgICAgSU5JVF9MSVNUX0hFQUQoJmZmYV90ZWFyZG93bl9o
ZWFkKTsNCj4+IC0gICAgICAgIElOSVRfTElTVF9IRUFEKCZmZmFfY3R4X2hlYWQpOw0KPj4gLSAg
ICAgICAgaW5pdF90aW1lcigmZmZhX3RlYXJkb3duX3RpbWVyLCBmZmFfdGVhcmRvd25fdGltZXJf
Y2FsbGJhY2ssIE5VTEwsIDApOw0KPj4gLSAgICB9DQo+PiArICAgIHJldHVybiBmYWxzZTsNCj4+
ICt9DQo+PiANCj4+IC0gICAgaWYgKCBJU19FTkFCTEVEKENPTkZJR19GRkFfVk1fVE9fVk0pICkN
Cj4+IC0gICAgew0KPj4gK3N0YXRpYyBib29sIGZmYV9wcm9iZV92bV90b192bSh2b2lkKQ0KPj4g
K3sNCj4+ICsgICAgaWYgKCAhSVNfRU5BQkxFRChDT05GSUdfRkZBX1ZNX1RPX1ZNKSApDQo+PiAr
ICAgICAgICByZXR1cm4gZmFsc2U7DQo+PiArDQo+PiArICAgIC8qDQo+PiArICAgICAqIFdoZW4g
RkZBIFZNIHRvIFZNIGlzIGVuYWJsZWQsIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uIGRvZXMg
bm90DQo+PiArICAgICAqIG9mZmVyIGFueSB3YXkgdG8gbGltaXQgd2hpY2ggVk0gY2FuIGNvbW11
bmljYXRlIHdpdGggd2hpY2ggVk0gdXNpbmcNCj4+ICsgICAgICogRkYtQS4NCj4+ICsgICAgICog
U2lnbmFsIHRoaXMgaW4gdGhlIHhlbiBjb25zb2xlIGFuZCB0YWludCB0aGUgc3lzdGVtIGFzIGlu
c2VjdXJlLg0KPj4gKyAgICAgKiBUT0RPOiBJbnRyb2R1Y2UgYSBzb2x1dGlvbiB0byBsaW1pdCB3
aGF0IGEgVk0gY2FuIGRvIHRocm91Z2ggRkZBLg0KPj4gKyAgICAgKi8NCj4+ICsgICAgcHJpbnRr
KFhFTkxPR19FUlIgImZmYTogVk0gdG8gVk0gaXMgZW5hYmxlZCwgc3lzdGVtIGlzIGluc2VjdXJl
ICEhXG4iKTsNCj4+ICsgICAgYWRkX3RhaW50KFRBSU5UX01BQ0hJTkVfSU5TRUNVUkUpOw0KPj4g
Kw0KPj4gKyAgICByZXR1cm4gdHJ1ZTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGJvb2wgZmZh
X3Byb2JlKHZvaWQpDQo+PiArew0KPj4gKyAgICAvKg0KPj4gKyAgICAgKiBGRi1BIG9mdGVuIHdv
cmtzIGluIHVuaXRzIG9mIDRLIHBhZ2VzIGFuZCBjdXJyZW50bHkgaXQncyBhc3N1bWVkDQo+PiAr
ICAgICAqIHRoYXQgd2UgY2FuIG1hcCBtZW1vcnkgdXNpbmcgdGhhdCBncmFudWxhcml0eS4gU2Vl
IGFsc28gdGhlIGNvbW1lbnQNCj4+ICsgICAgICogYWJvdmUgdGhlIEZGQV9QQUdFX1NJWkUgZGVm
aW5lLg0KPj4gKyAgICAgKg0KPj4gKyAgICAgKiBJdCBpcyBwb3NzaWJsZSB0byBzdXBwb3J0IGEg
UEFHRV9TSVpFIGxhcmdlciB0aGFuIDRLIGluIFhlbiwgYnV0DQo+PiArICAgICAqIHVudGlsIHRo
YXQgaXMgZnVsbHkgaGFuZGxlZCBpbiB0aGlzIGNvZGUgbWFrZSBzdXJlIHRoYXQgd2Ugb25seSB1
c2UNCj4+ICsgICAgICogNEsgcGFnZSBzaXplcy4NCj4+ICsgICAgICovDQo+PiArICAgIEJVSUxE
X0JVR19PTihQQUdFX1NJWkUgIT0gRkZBX1BBR0VfU0laRSk7DQo+PiArDQo+PiArICAgIC8qIFNv
bWUgc2FuaXR5IGNoZWNrIGluIGNhc2Ugd2UgdXBkYXRlIHRoZSB2ZXJzaW9uIHdlIHN1cHBvcnQg
Ki8NCj4+ICsgICAgQlVJTERfQlVHX09OKEZGQV9NSU5fU1BNQ19WRVJTSU9OID4gRkZBX01ZX1ZF
UlNJT04pOw0KPj4gKyAgICBCVUlMRF9CVUdfT04oRkZBX1ZFUlNJT05fTUFKT1IoRkZBX01JTl9T
UE1DX1ZFUlNJT04pICE9DQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBG
RkFfTVlfVkVSU0lPTl9NQUpPUik7DQo+PiArDQo+PiArICAgIHByaW50ayhYRU5MT0dfSU5GTyAi
QVJNIEZGLUEgTWVkaWF0b3IgdmVyc2lvbiAldS4ldVxuIiwNCj4+ICsgICAgICAgICAgIEZGQV9N
WV9WRVJTSU9OX01BSk9SLCBGRkFfTVlfVkVSU0lPTl9NSU5PUik7DQo+PiArDQo+PiArICAgIGlm
ICggIWZmYV9wcm9iZV9mdygpICYmICFmZmFfcHJvYmVfdm1fdG9fdm0oKSApDQo+PiArICAgICAg
ICByZXR1cm4gZmFsc2U7DQo+PiArDQo+PiArICAgIGlmICggIWZmYV9md192ZXJzaW9uICkNCj4+
ICAgICAgICAgcHJpbnRrKFhFTkxPR19JTkZPICJBUk0gRkYtQSBvbmx5IGF2YWlsYWJsZSBiZXR3
ZWVuIFZNc1xuIik7DQo+PiAtICAgICAgICByZXR1cm4gdHJ1ZTsNCj4+IC0gICAgfQ0KPj4gLSAg
ICBlbHNlIGlmICggZmZhX2Z3X3ZlcnNpb24gKQ0KPj4gLSAgICAgICAgcmV0dXJuIHRydWU7DQo+
PiANCj4+IC0gICAgcmV0dXJuIGZhbHNlOw0KPj4gKyAgICBJTklUX0xJU1RfSEVBRCgmZmZhX3Rl
YXJkb3duX2hlYWQpOw0KPj4gKyAgICBJTklUX0xJU1RfSEVBRCgmZmZhX2N0eF9oZWFkKTsNCj4+
ICsgICAgaW5pdF90aW1lcigmZmZhX3RlYXJkb3duX3RpbWVyLCBmZmFfdGVhcmRvd25fdGltZXJf
Y2FsbGJhY2ssIE5VTEwsIDApOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gdHJ1ZTsNCj4+IH0NCj4+
IA0KPj4gc3RhdGljIGNvbnN0IHN0cnVjdCB0ZWVfbWVkaWF0b3Jfb3BzIGZmYV9vcHMgPQ0KPj4g
DQo+PiBJIHRoaW5rIHRoaXMgbWFrZXMgdGhlIGNvZGUgY2xlYW5lciBhcyB3ZSBhbHNvIGdldCB0
aGUgcHJvcGVyIGVycm9yIGhhbmRsaW5nIHdpdGggZ290bw0KPj4gaW5zaWRlIHRoZSBmdyBwcm9i
ZSBpbnN0ZWFkIG9mIHRoZSBwcmV2aW91cyBvbmUgd2hpY2ggd2FzIHRyeWluZyB0byBoYW5kbGUg
Ym90aCBjYXNlcy4NCj4+IA0KPj4gV2hhdCBkbyB5b3UgdGhpbmsgPw0KPiANCj4gVGhpcyBpcyBn
b29kLiBJdCdzIG11Y2ggZWFzaWVyIHRvIGZvbGxvdy4NCg0KR3JlYXQsIEkgd2lsbCBwdXQgdGhh
dCBpbiB2Ni4NCg0KQ2hlZXJzDQpCZXJ0cmFuZA0KDQo+IA0KPiBDaGVlcnMsDQo+IEplbnMNCg0K
DQo=


From xen-devel-bounces@lists.xenproject.org Thu May 22 14:04:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:04:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994036.1377067 (Exim 4.92)
	(envelope-from )
	id 1uI6Wr-0005Fe-1O; Thu, 22 May 2025 14:04:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994036.1377067; Thu, 22 May 2025 14:04: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 1uI6Wq-0005FX-V5; Thu, 22 May 2025 14:04:12 +0000
Received: by outflank-mailman (input) for mailman id 994036;
 Thu, 22 May 2025 14:04:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI6Wq-0005FJ-AJ
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:04:12 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a2208d6c-3715-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 16:04:10 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-445b11306abso33485425e9.3
 for ; Thu, 22 May 2025 07:04:10 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f78aeb7fsm103243965e9.26.2025.05.22.07.04.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 07: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" 
X-Inumbo-ID: a2208d6c-3715-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747922649; x=1748527449; 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;
        bh=BNd1TLZwIjZh2L8Aq9WRMg/g0VDJfEai8NT+RXQuKT0=;
        b=KroUIZhJvOuIXWq998irEXZzlZGupfmWY2DmhLu6HI0BSy0Tk9ev5U44Rrrx7m9rZ+
         zITYO/vvWDGK4tdoSvakLh4Di4NAnMq3d0KHpgtrGgueepGBD01JGNok6s/RFWZW6kaH
         ptALsi7HgHCqv4inLWwfKC05I8lz1p7Le44tU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747922649; x=1748527449;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=BNd1TLZwIjZh2L8Aq9WRMg/g0VDJfEai8NT+RXQuKT0=;
        b=Zukka4j+uBTAcmxv+qMM5wiVJec9RetI2CK5x8IMOa8xA+4vcoiZlkaVwjUXc56YO1
         ujqmOg8vuVBak6WXkt1k6AfN7I/cK3eGGofD38+XVzLYXsJstkHRSbh4oTONn0IdcEbl
         f6J4cS3nj+kevGe9JVHoBNygb3rExlrX9rMj7FObyNyyMDPhr2GKiW9+Uiiwru+dHYBw
         eMLPtfdcBTWTCqDhpOZSFStp5RmXRIxo/t2zmYLg5VVlJ8q7YSz8YlSo9YQKUW+XP5Kd
         lLLYKFdJzXnCc6ZrkxX0/b9EHO5MNdtLOjM03m/tHgUhzprcSTP7Zb81fY6oX2g3EzgD
         ABww==
X-Gm-Message-State: AOJu0YzHvlr4+RM+roJapsvcO/encOdSXvQP2njQWmoGt1xjwLsgmUZN
	HGR0y4a+OSsRzYNqFQikVwGrb2rnJmq3K1YC1GlWayQ77SJpr4e3sz2+Bo21npWQ0R0HSkmRxHN
	mdH5j
X-Gm-Gg: ASbGncvoZsFcCAmk7Uw/SK5dkXXKNo+dc/SmkecJvmU6+RmsbIPWFU+AIFMrgpVUuHT
	wrLNKiPOXqIQhdRBkUpIKuNEKQ2+/Xei1Pv3bFE5SNN1UA7yalRAMAHt1Az5Fvb2G3+Bgihn1yZ
	if/qcgLhXLUTi241SRTqBWkzchTsd1SonSLqUuQvrApEoMR6ZDtuZb8T9umCBJqDBXILxDT7UXu
	1w3ZPFP1+IqCqlST6qcwSKiKJh2iT6Zx+BDyIqbewAL7vDyaCfklumSk74+6CKMhmIR4SEIAEQr
	2o9mBF3r2pmcQAVR/bCclpCWiedlK7mDYevJT9U7aQrYlrxz+h0ehhoITVEOheqCGJz4V2IrrT8
	DneHFrEjGaHnxLOOYGzk=
X-Google-Smtp-Source: AGHT+IFBSad0APJuUkl25AiE+Q62FS1rUuD/ZDEN/BzWK5tpqROfLzRlnGevS3RW8xQuZ6W0Gxo5Lg==
X-Received: by 2002:a05:600c:3d8e:b0:43c:eeee:b706 with SMTP id 5b1f17b1804b1-442ff032801mr222028065e9.24.1747922648967;
        Thu, 22 May 2025 07:04:08 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 0/2] x86/vpci: two fixes
Date: Thu, 22 May 2025 16:03:54 +0200
Message-ID: <20250522140356.5653-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

Patch 1 fixes a regression reported by the Qubes ADL runner, so it's
required to unblock the testing.  Patch 2 is possibly more controversial,
it's not strictly required to unblock the testing, but might be good to
consider.

Thanks, Roger.

Roger Pau Monne (2):
  x86/vpci: fix off-by-one
  x86/vpci: refuse to map BARs at position 0

 xen/arch/x86/pci.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 22 14:04:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:04:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994037.1377071 (Exim 4.92)
	(envelope-from )
	id 1uI6Wr-0005In-8a; Thu, 22 May 2025 14:04:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994037.1377071; Thu, 22 May 2025 14:04: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 1uI6Wr-0005HZ-4q; Thu, 22 May 2025 14:04:13 +0000
Received: by outflank-mailman (input) for mailman id 994037;
 Thu, 22 May 2025 14:04:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI6Wq-0005FK-CZ
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:04:12 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a2e4d617-3715-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 16:04:11 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-44b1f5b917fso991515e9.3
 for ; Thu, 22 May 2025 07:04:11 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca8896dsm23041682f8f.73.2025.05.22.07.04.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 07:04: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" 
X-Inumbo-ID: a2e4d617-3715-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747922651; x=1748527451; 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;
        bh=0FktwtEW0Fmw4rJHIOF3iKnfB159BdV//CCT1areduY=;
        b=WxjEoPvaVWa9gq9LLUDmBhAb6Ac5EeJZmyWg0oYGMmI4kiS62SbS1mYKbRHpKNnIsD
         5+XcBlP9+I9IyNhkhSpvgKcf8x0BzXVPvS/n6C9QUNSKg1UHiTkEdQ6mUBLNnvrwgvZT
         0m5KabIv8xYGCA4m2fsljgzF0w52aqSSyYQEA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747922651; x=1748527451;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=0FktwtEW0Fmw4rJHIOF3iKnfB159BdV//CCT1areduY=;
        b=Awc95+IA4P729VYQnkXibMzrjFLRtTdbh5Tif9Ik6Tyexr1Ce3+GSNkZKVQWmK9cZc
         fN/DCODlHVQws9/VBpZDSuT3l9Z/p5H55Ht0JpQhTZ9RXHoWcr1Kdij3TolM/tt1sPhr
         YOPW0Rp+pcCN9Y8GixJ7KfFyZTnKJZhmb2rnqacIp98vuC4B8cb05xNZAvdX/z013Ull
         Bo/BbKgq5shVtAfGYnckl7wQ2LttCLTgU+8baUB0Hel2Z0ThmM6pFd0Vw54WUryKfqNR
         y3F34BS+wrhZrdfVNyy164fx4qbzN4+PaUh4ndkZx8Z2+LIEbKAyqu6hpv3hoojHdr2s
         z+zg==
X-Gm-Message-State: AOJu0YzWYNl5xYdBYPY1ajAz8R53MI35P5wWEWMjPIh6pTVn4g5bKz0u
	tHLW1V7kJwe7qlaBQo1w8hV3jzzZDZAir9tNVXhfjGV9e8W2hzsplpsB+YdtXq5I/xQIaRXDAHf
	he2K/
X-Gm-Gg: ASbGnct2qUFM5d9afsOEeTYVJrKlFTNiJonONJkikLqZRKlaCX/TGAkZrzoQMXwYug8
	vlU0DdyNKZkmy23suxwGGZMc4NNLqX6iS8ZuuAqy2yLadBmVJVmZIJs+dgqXJeAim/DkswphMuz
	xj06fidk8Ona8pAofbUg2SkWeC4sxyX6BZKKiwN73PG3H8lYXH3chWc1K44xS6NP6BxQVwNxUBQ
	80xMt8/YeIVmRC1uWx8KRyxbPF3+Fq8iucKxCjdB0X4PugT0Yn7pvwPLbihStosaMVReFWXQhPC
	zZ36L+vOTuTVO9AarVNtUjgKaBCiSnx1p1feX/zxkh5p5jXo/hxyislZiEShJZWlwT58HL6OfCF
	N4asxwbhbpt4MfC6eyMLyKpSXCd/mbA==
X-Google-Smtp-Source: AGHT+IF3POTYR7vwEVPnwq1opDQsoIMzXDAVykkFgf+t7uK8/81M9xz8IcuajOR1zLPq+mVUT9YB8A==
X-Received: by 2002:a05:6000:4212:b0:3a3:7ba5:960e with SMTP id ffacd0b85a97d-3a37ba598e7mr10049647f8f.59.1747922650637;
        Thu, 22 May 2025 07:04:10 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 1/2] x86/vpci: fix off-by-one
Date: Thu, 22 May 2025 16:03:55 +0200
Message-ID: <20250522140356.5653-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250522140356.5653-1-roger.pau@citrix.com>
References: <20250522140356.5653-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

rangeset_remove_range() uses inclusive ranges, and hence the end of the
range should be calculated using PFN_DOWN(), not PFN_UP().

Fixes: 4acab25a9300 ('x86/vpci: fix handling of BAR overlaps with non-hole regions')
Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
index afaf9fe1c053..26bb7f6a3c3a 100644
--- a/xen/arch/x86/pci.c
+++ b/xen/arch/x86/pci.c
@@ -131,7 +131,7 @@ int pci_sanitize_bar_memory(struct rangeset *r)
             continue;
 
         rc = rangeset_remove_range(r, PFN_DOWN(entry->addr),
-                                   PFN_UP(entry->addr + entry->size - 1));
+                                   PFN_DOWN(entry->addr + entry->size - 1));
         if ( rc )
             return rc;
     }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 22 14:04:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:04:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994038.1377088 (Exim 4.92)
	(envelope-from )
	id 1uI6Wu-0005iv-GB; Thu, 22 May 2025 14:04:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994038.1377088; Thu, 22 May 2025 14:04: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 1uI6Wu-0005im-D7; Thu, 22 May 2025 14:04:16 +0000
Received: by outflank-mailman (input) for mailman id 994038;
 Thu, 22 May 2025 14:04:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI6Wt-0005FJ-2D
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:04:15 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a3fd8eab-3715-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 16:04:13 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a37a243388so3013307f8f.1
 for ; Thu, 22 May 2025 07:04:13 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca5a7cbsm23663863f8f.35.2025.05.22.07.04.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 07:04: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" 
X-Inumbo-ID: a3fd8eab-3715-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747922652; x=1748527452; 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;
        bh=AtChMzwK5++U3Ymy4zTRlMVtRVgKCf/lu2BCXNEbl+o=;
        b=HutKwm5YkmDHOKtirX2SGvDRUM2yxYBpZy0cF8+YmrGPnAsGBcZT0cV5FzwXDpSJqi
         Rcdk/79se3EzvL2282NTz36HySTE0XQwLOol4VKRHmoOUtBacxrqbKNl5kFUEGZxDI+b
         WuVOsIElzfZIdEz7/mWWOWXbAfEm2ensjZgzM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747922652; x=1748527452;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=AtChMzwK5++U3Ymy4zTRlMVtRVgKCf/lu2BCXNEbl+o=;
        b=UswjwW3WRx8LoFHRn4WvUlR17xZ0zm3zfaVXtpiM3BKs7wyrZPuKarfGkE9FMH2AW+
         5r7AKjHQCFQZLs3QrR9uTu4Y+mRtTBNERctXtsxi9PRflxpf6B6o0s2I4ujq8Mc/9I5G
         1PKSeSeO3nY3LiWPhA+SdKP0wpnazcQwAIlR9zHcCaJ1deDrPurp/mNJH9eIlINjAYFx
         p6aSwO95Aer3TNPgclWgqpHguwoQ7lAVtBgxPSjTFWUHkB3CFIcyzlR+YcEaZUWOlbdT
         PY9SsL8L8v2MYiY4+M81bJ6I7SLT8KIpog4tGfS9xk4vYFwWjdTGn9CU7SdpLFr4zR+i
         cNiA==
X-Gm-Message-State: AOJu0YzQu5A/t8IZRm28TaOOqzvDO/qSWoEQWr+p3lq8112TOAsVPAAj
	vPGopeIwggSvk830tJeEYi/KOu/f6zCR2uBI86s/DPj6b3LjD61FVxD1MTumcN1vzn9MOFFxdU3
	LfB4A
X-Gm-Gg: ASbGncv8ycQvl7gGplI+dfbvOTQKTIEwvt/ibmtSp2ZtGje+0texSo7MiAengU8OJng
	kzlhRJ54t6VWVwO9qP95gLgJyRPYGfQ3JNtMYNBw/fIxqDeQw7j5ZPDV7L1/kjvIy1/BqeGcZZY
	ATXiN2USqIIFi38Fh1gjIpDfNoppjkX4yQrZiiKMa/TDF3amzTNlQvKnF9vVMGymPtF+aPOTqnF
	G89bhuPGkw3vawSqCpGeYhI22gMwctuG8EdtTmuftAp6sTUNFlTM5tsceoU2YB2LyIEFhMkeEYt
	HQr8vyQV6b+8oquft3/anN/6CkZE0u98bGg8K/8A+6jK4omyzbRB2Cu1lBuXZLaPO/B95TQWHxn
	YZFICyVKBUTjBWMOwvB0=
X-Google-Smtp-Source: AGHT+IEQSmb2g2Tp5adBDx1cXodRHDdoZCyJp+7sZXMZRxMGwnl4cqfYrfNVxG+DHBoMHXMs2rQN7Q==
X-Received: by 2002:a05:6000:400f:b0:39f:175b:a68d with SMTP id ffacd0b85a97d-3a35c808b3dmr22770652f8f.11.1747922652530;
        Thu, 22 May 2025 07:04:12 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH 2/2] x86/vpci: refuse to map BARs at position 0
Date: Thu, 22 May 2025 16:03:56 +0200
Message-ID: <20250522140356.5653-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250522140356.5653-1-roger.pau@citrix.com>
References: <20250522140356.5653-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A BAR at position 0 is not initialized (not positioned).  While Xen could
attempt to map it into the p2m, marking it as mapped will prevent dom0 to
change the position of the BAR, as the vPCI code has a shortcomming of not
allowing to write to BAR registers while the BAR is mapped on the p2m.

Workaround this limitation by returning false from pci_check_bar() if the
BAR address is 0, thus causing the bar->enabled field to also be set to
false and allowing bar_write() to change the BAR position.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/pci.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
index 26bb7f6a3c3a..39fd5a16a4aa 100644
--- a/xen/arch/x86/pci.c
+++ b/xen/arch/x86/pci.c
@@ -101,6 +101,15 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
 
 bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
 {
+    /*
+     * Refuse to map BARs at position 0, those are not initialized.  This might
+     * be required by Linux, that can reposition BARs with memory decoding
+     * enabled.  By returning false here bar->enabled will be set to false, and
+     * bar_write() will work as expected.
+     */
+    if ( mfn_eq(start, _mfn(0)) )
+        return false;
+
     /*
      * Check if BAR is not overlapping with any memory region defined
      * in the memory map.
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Thu May 22 14:07:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:07:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994058.1377098 (Exim 4.92)
	(envelope-from )
	id 1uI6a1-0006oX-Uv; Thu, 22 May 2025 14:07:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994058.1377098; Thu, 22 May 2025 14: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 1uI6a1-0006oQ-Rv; Thu, 22 May 2025 14:07:29 +0000
Received: by outflank-mailman (input) for mailman id 994058;
 Thu, 22 May 2025 14:07:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI6a0-0006oK-Lb
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:07:28 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2417::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1616f900-3716-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 16:07:26 +0200 (CEST)
Received: from SJ0PR05CA0038.namprd05.prod.outlook.com (2603:10b6:a03:33f::13)
 by SA3PR12MB9089.namprd12.prod.outlook.com (2603:10b6:806:39f::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.20; Thu, 22 May
 2025 14:07:22 +0000
Received: from BY1PEPF0001AE1C.namprd04.prod.outlook.com
 (2603:10b6:a03:33f:cafe::50) by SJ0PR05CA0038.outlook.office365.com
 (2603:10b6:a03:33f::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.16 via Frontend Transport; Thu,
 22 May 2025 14:07:22 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BY1PEPF0001AE1C.mail.protection.outlook.com (10.167.242.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Thu, 22 May 2025 14:07:21 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 22 May
 2025 09:07: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" 
X-Inumbo-ID: 1616f900-3716-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QjBIzlRu/rLQIFJThF0i7xDdBs4mirk5wY4YTCyn32gUx864E0xbiqRpGs028TmJHrPAsvNA/xHdanS7lR4hmt2sBojgiv2obLFspPzEALlJ/IQN80HV+vd8aScfyIYtWbjAKIUiXfLzPCEe6AB/3Y9WoMJgelHlTDMmUCIJgLGVoUqhPC8VRaBDOHkC5CRu9491T4JKBXV7MpUj2loRiYmxyH44GzLJ0rD1quA1NkoIi8kzqohM1vdNTbOyDJCc0DyJdB3Mg1d4HG9UeSc9xSkBZfQ1Yi5U1mXJQsdGG/dQTYMFGlvnW4hUAIbU9hdfUJMo89GjA1TGaJfDD6iNiw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IV6cTio2L9OT3+QQPqcHUlzTFaFVxKZcp8ZxyuZ4dqA=;
 b=qcALVtDAE2gatPfXl4oJOkUmYlJ7ptk8m+B/pgvIAP/pqofe8l8TUBY+cCC8FIN25IacFu4dUkw4IZh8aLqjIvZTGMkxEUj+sM5p3CQCMed6BA+Sd/VeK2JFXvCjVAj0IrD2pjt/6Y7hgDf+uAdhzhjSdfZzrSPXSv5q/sKhixNt1OzVJLJIyfofuxjybFk4OWmBIPtIsPpTeKotDPKc04Rle5HR28dq0MB+mmzk+Qn4kUIhRtMTObFVlZTgftabkGYcilsY7WYyh7vBIxIpAiGc8cS71STCQgeFaB7EdOfMWJ+6K9mr/dwRu8spPw3bw9ZOOsX07dyqPGbwa7P1QA==
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=IV6cTio2L9OT3+QQPqcHUlzTFaFVxKZcp8ZxyuZ4dqA=;
 b=PF/8dSFT5quHWncwmLeCJHy9mcm7plttwMPP7hxbL4XfRHG7drCyVNLUOQuMasgbdZPNPH0GXBIOFsBe/qNA/CJ1h8VGu13W7xDFr6Q0PlOQR4BVGymUBspyxN/vECMQoPtBFGMaPlXzVh1NP2rJYDaCttbj/O3MkbQIYIkZEhE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 22 May 2025 16:07:17 +0200
Message-ID: 
To: "Daniel P. Smith" , Jan Beulich
	
CC: Andrew Cooper ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini , "Jason
 Andryuk" , Denis Mukhin ,
	
Subject: Re: [PATCH v6 02/12] common/hyperlaunch: introduce the domain
 builder
From: Alejandro Vallejo 
X-Mailer: aerc 0.20.1
References: <20250429123629.20839-1-agarciav@amd.com>
 <20250429123629.20839-3-agarciav@amd.com>
 <9021c878-9605-4d6e-95b8-ab97da186542@apertussolutions.com>
 <29a55d44-c26e-4834-b93b-47cbd98f885e@suse.com>
 
 
 <6e3f3727-d084-40b9-a42a-46c52e770c88@apertussolutions.com>
In-Reply-To: <6e3f3727-d084-40b9-a42a-46c52e770c88@apertussolutions.com>
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BY1PEPF0001AE1C:EE_|SA3PR12MB9089:EE_
X-MS-Office365-Filtering-Correlation-Id: 5232ccfc-25b9-4420-7ed3-08dd9939f890
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?QkpDMSs3YXpLQlBLYUYzb1Y4Sml2NXhRRHJuUlZMM1lXSm52Zkw4N2dCbVlN?=
 =?utf-8?B?YWV4WU56NG9hZEU5SHBzb2lsT3RNZU9qUHJSMWIwUnpmb0pvM0drbjJtMkty?=
 =?utf-8?B?aHlCVlY5Z2tmeitINTVXUVRwUUFoZUJOZ2JJMlhMQ3hpaTl6U04zREZPbjh2?=
 =?utf-8?B?OE02Y2ZaekRySWFTRlZIS21seFlZdlpKUnJQelBkZFpCUXVFQzU4UTJPbXJ4?=
 =?utf-8?B?c2lVZVVWbU9oQ1ZXVVNuQU5FcHdCV3loaTB2VWF6aGowOGJteHRiVDRocGlL?=
 =?utf-8?B?aGRJczd3MStPM2Nlckk5M3l1NUxnZDdtSWUrUUcvUzh6Z1lFSDVMQjlnT3Iw?=
 =?utf-8?B?c2hUOHhYOFd2OTRHbVR2SGwzYnhvd2Q3aHNIL0Rpb2MyY2h6R2tUY0d4ZVZB?=
 =?utf-8?B?dnN6cmJMU010TzQxblYyNmRvTExHbVNpZUF3Q0NiMU90cnlYUDBxc1VHWjZa?=
 =?utf-8?B?N0ZVNy9GV0I2K0RlMVlqV0N0Zm5MaTNyeVFrWGJVeTRUTEpaK3Rmb0VYb3FI?=
 =?utf-8?B?OEhLbTVHUTkxYWV1dXc3RVBSRmM4QzFTMGViWWVkMWh0amFORVVlcmtub3JT?=
 =?utf-8?B?Rkt4ajhwYzNpYnJwTnNEUnJ5VkZaeUZsUDB5eDRrWEYxcWdabndTNnFKazVD?=
 =?utf-8?B?dGtwSStpQWw3UU9TSUVuRnBjZVdxWGxyVE81c2hkcFVlYjZZR1plM3oxa1la?=
 =?utf-8?B?L0dkZFRwcXBMZUMyaHpRdVNpd1ZzdERTN3VJQ1lXbnMwYnNjTSs4dlc3bkhX?=
 =?utf-8?B?M3FYcHJteFowSkQxODAvOE5obm1nK2NsYzlVbVVNOUJRTDVJN1pUN0Q1WU9D?=
 =?utf-8?B?SWZWcGN0WjFKK3hNTnh3V0NIbkJtMW5RS1ZRYkkyc0Z6empoMEEzRHJBbHVK?=
 =?utf-8?B?SnZiWE1kaGhFdW4rTk5qdmQ3VStDc1UzeXdkYThJUFM1WXJmY1hKNDY4OFJs?=
 =?utf-8?B?dUJCdFVGb0lBbVJEWWlnTGN0QVVHQk5DbVlYb2VrMGRVb00vM0FjS0t2azRk?=
 =?utf-8?B?TmwyOWJTZmk4MHFrdU9MeXhTWTd4L2loZGh1NlkyQnovVTh0VXFiMm92ZFR0?=
 =?utf-8?B?WGs2N2xNZ2pJUVR1UjZldFdKUDArQmtWd0VJN0NGbGNSdm82SVhGRUgrTFdU?=
 =?utf-8?B?bTRoajJ5MkE4cm9yUWdXcVZJUVcvV2R4YnR5SWtHWU9leEdMcklGdVVtT1NP?=
 =?utf-8?B?ZVRzZ1duSzdPK2J2MXFYeDVybis2V3ZUditZUzBJQllFbmVPNE1VWGdCUXFx?=
 =?utf-8?B?UklZa054WXRJVkpXOXZ1UnNXZDBHNkVic3gyNmN6TFRZT2cxQTJFQTE3a1M4?=
 =?utf-8?B?VGxmRXZud2FJUWhJQkIzQUUxUmtVeUFUUngzbklQelp2NEdWcXhRMkwxWnFz?=
 =?utf-8?B?cmNsMS90Y1Nzdkd6ZFc4YjBpOWQxNFZXNG5xaC9JWlo5eWhmN0V1NlhINXEr?=
 =?utf-8?B?SkhJSHNmdTQ5L1dSTGtETnJCSUg3ODBYaTExdFZaR2g5cTYxSGtETzhEak1z?=
 =?utf-8?B?UFFKYkRmaUFPTm4zSllGcjNhbmFyVmY1Q1JUYTdzU01KelF5UTRpOGJJdm5V?=
 =?utf-8?B?UW1uV3gweWh0ZUhFN1JWc2M3M0cvSzZVV0ZPdXlhcythb0hCeC9yc1lROVJU?=
 =?utf-8?B?NzFoUDUyWHVqSFJObEtxRUQ5czdDK1V6YzhGbUlOaUh5KysvNkdycndoNGlo?=
 =?utf-8?B?ZTh3TVRyY0IyWGY1SXNBcHo4UFFmV0MrckM4MFBIRzFwMktrVTVCNDR3Y3Vn?=
 =?utf-8?B?Q0dWOHBTcGZWekdOWGNUYnpVSHliem5sN28yUUlJYjdCSWI0V2J2UXp3VUY3?=
 =?utf-8?B?ODMvdjBNTkJZTytteFhwOUlRT1lqalAyc2ozUkUvUkhGeUZhZ2U3enpNTTMz?=
 =?utf-8?B?V3ZqZ1NPS3k5V2sxbWFxamdTOW84SVFuejl0ZytFWmtoVXhYWERabGthSy9i?=
 =?utf-8?B?dXI4czNuRDZCUHNrRGFuaHJlZ1JLS2ZtOVVTdW9EU2RidHh2OHhIdEp2OXBt?=
 =?utf-8?B?VElNcFdDdVZibmx4a2hvMVBVcW5jMzVuYmtCYjZIYWZDNkVDMlRUeXY2eU1n?=
 =?utf-8?Q?vfPeOY?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 14:07:21.7623
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5232ccfc-25b9-4420-7ed3-08dd9939f890
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BY1PEPF0001AE1C.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB9089

On Wed May 14, 2025 at 12:23 AM CEST, Daniel P. Smith wrote:
> On 5/13/25 04:05, Jan Beulich wrote:
>> On 06.05.2025 21:29, Daniel P. Smith wrote:
>>> On 5/2/25 03:21, Jan Beulich wrote:
>>>> On 30.04.2025 20:56, Daniel P. Smith wrote:
>>>>> On 4/29/25 08:36, Alejandro Vallejo wrote:
>>>>>> --- a/xen/common/Makefile
>>>>>> +++ b/xen/common/Makefile
>>>>>> @@ -11,6 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) +=
=3D device.o
>>>>>>     obj-$(CONFIG_HAS_DEVICE_TREE) +=3D device-tree/
>>>>>>     obj-$(CONFIG_IOREQ_SERVER) +=3D dm.o
>>>>>>     obj-y +=3D domain.o
>>>>>> +obj-$(CONFIG_DOMAIN_BUILDER) +=3D domain-builder/
>>>>>
>>>>> Please don't do this, use IF_ENABLED in core.c and then hide the
>>>>> unnecessary units in domain-builder/Makefile as I originally had it.
>>>>> This allows for a much easier time incrementally converting the dom0
>>>>> construction path into a generalized domain construction path.
>>>>
>>>> That is, are you viewing this as a transitional thing only? If the end
>>>> goal is to have it as Alejandro has it above, that may be acceptable
>>>> (even if not nice).
>>>
>>> There is/will be shared domain construction code between dom0-only and
>>> multidomain construction, with it will all living under domain builder.
>>> So no, the end goal is not what Alejandro just did. The end result will
>>> be the way I had it, with a different kconfig option to enable/disable
>>> the multidomain construction path.
>>=20
>> Isn't CONFIG_DOMAIN_BUILDER a misnomer then?
>
> Which is why I originally had two kconfig flags, one to enable dtb=20
> parsing for domain configuration, which allowed dom0 construction from=20
> dtb. Then there was the second flag that was to enable multi-domain=20
> construction. I have reworked a portion of the approach in the RFC based=
=20
> on feedback, which is based off of this series. In it, I tried to=20
> minimize how much went into common, but you will see how I still had to=
=20
> rework the kconfig flags.
>
> v/r,
> dps

Does it really make sense to have a flag to restrict multidomain while
allowing parsing the DTB? There's virtually nothing compiled out in that
case.

If you did it that way because it doesn't initially build several
domains, that's just transitional and to be expected on any feature
tagged as unsupported with (EXPERIMENTAL) in the name.

What if I collapse everything under a single CONFIG_MULTIDOMAIN_BUILDER
that compiles-in support for parsing DTBs while introducing an
unconditional builder as I go? From what I'm seeing, there are no
breaking changes in the series and the end goal is to have the builder
be unconditionally used, after all.

In fact, with the bindings code in common, I can also collapse everything
in core.c (and later domain.c) into a single arch/x86/domain-builder.c
that is unconditionally compiled in. The DTB parsing logic is already=20
in separate files and that can be compiled out with
CONFIG_MULTIDOMAIN_BUILDER flag.

In retrospect, after looking at dom0less long enough there's bootfdt.c and
bootinfo.c with similar intent, but far more ad-hoc cohesion. While the
builder wants to be in common, no other arch is in a position to take
it. It needs merging with the stuff done in bootfdt.c/bootinfo.c

So, in short. I'm planning to:

  1. Collapse domain-builder/{core,domain}.c into domain-builder.c
     under arch/x86. There's little reason to have them separate.
  2. Remove CONFIG_DOMAIN_BUILDER, and replace it with something that
     reflects the intent of using a DTB. Either CONFIG_MULTIDOMAIN_BUILDER
     or CONFIG_DTB_BUILDER. Or maybe even CONFIG_DTB_BOOT.
      * I specifically want to avoid CONFIG_BOOTFDT, because that'd
        create confusion with the already existing bootfdt.c in common.

and, from the discussion in the other thread about code sharing in the
spirit of getting somewhere soon:

  3. Do minimal parsing at builder_init() (module identification,
  basically), and do the full parsing by the create_dom0() mark,
  immediately before constructing all domains. With the unflattened
  tree.

Moving forward I for sure want to merge the boot paths in the x86
builder with those of arm/riscv. Having a unified boot frontend can only
bring niceness.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Thu May 22 14:11:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:11:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994066.1377108 (Exim 4.92)
	(envelope-from )
	id 1uI6eC-0000Mf-Du; Thu, 22 May 2025 14:11:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994066.1377108; Thu, 22 May 2025 14:11: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 1uI6eC-0000MY-B2; Thu, 22 May 2025 14:11:48 +0000
Received: by outflank-mailman (input) for mailman id 994066;
 Thu, 22 May 2025 14:11:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI6eA-0000MS-P7
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:11:46 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b1481bd5-3716-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 16:11:45 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43cfdc2c8c9so49746465e9.2
 for ; Thu, 22 May 2025 07:11:45 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-442ebd6fe86sm235038105e9.0.2025.05.22.07.11.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 07:11: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" 
X-Inumbo-ID: b1481bd5-3716-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747923105; x=1748527905; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=oIr3xsAWBxp5cUCCFMKmy9bFr8l6tisioRoXZYH2AS0=;
        b=QQ5daXO29JxuHd19fB5MRktcrO53hkCqXeluOF/rU31vgU8qG+vzniv6MKzXAfm97L
         z48yhdmlE+0fs53vzm5S4KIM2eNGNY5WdtryxqozP3p5bmJkDD455oz8I4Joue3lwP3V
         8Blgn1wja/KoNd/rCjQrqfBYKG5bwtdz/6gqI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747923105; x=1748527905;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oIr3xsAWBxp5cUCCFMKmy9bFr8l6tisioRoXZYH2AS0=;
        b=LuVkLzJHfbG3vygULq07SUDdlZvG7EDD6Ti1hqMRcZYPCl/HsG7PBzksULR5wo9Nmn
         U8g6QFb4dFiD8MRFSJEXcdj8laZq8/5crbR/QDT2U3/auwFnoLmM8SKWyDr/LqzXx42j
         4NUpYJ71ynyDcL1FZLs18yZFJkn+1SXYIGsJyWVLh+5MkJLhvppnotKp77kDGPq5kLf6
         HyRlLjZmFy8lqB9eeLQMywx/i746K3OiTz8+n2B/PVRwbSbfFV8/QwcCGoH959rjdLhi
         MM6RB/OH+DIIJKN3LvsOVSYy+3QX5G5UAfB3PPm8TAENZMluWyt2n2JJfs/2Lzop+eeQ
         i2yw==
X-Forwarded-Encrypted: i=1; AJvYcCXHCwsFMGOvF8kzfBV1BgJmNVUx+KTmEJXCgrgIryrFWeyJWgpmMPoFasI3vNrbFKXP9gE0rXlsDpI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YztTHYwmoS46B5+burZmD4NTn/CXIiRfAqZNu69MWXjAvt0m7z1
	4rYozAAs5zbNwAFSE+E5SFRsrZLS+dfmNHGS1/HWLxM0dYPfIJF2qrjiw0XOaiELhnE=
X-Gm-Gg: ASbGncv5T3IiRuybrOmGLFu+rV5IcV03HY0YkDwzaE84gyKvgT13HzIXJ0ACnHfya17
	vpDnoAoWY2rJZyYeiD4bqAjBSaLrV4od8gVHW4gmp4LmXGyj2anzR3rby7Ujbj+HWbZvOVANLBE
	tVUGZSBZ1xmvqiod2pPy1XsqfKwkNVvC030VctfcF4rI5lGsBTt0Vpl9w4+1g4t6D0jJE5YOmwC
	0sYZhyZ3cFBVD+CFXOv5X60NYCRVoDVWFeDnsL3g70790pi33+k2Y5PBD+fP/KMJV3nVf+LKMx9
	xH4x/vpe5j8DNVcVwGn9BQjznJdE9bcXYXxlLFI3dpQ+7l6j705DaPGwSgcPPyCo8bXXTauG8OZ
	pMJSPrVBnZ2FG8F1IfpY=
X-Google-Smtp-Source: AGHT+IGvvKaJaa4HL46t7/H21xRC5EjyP4/XTw1vAmcnwKAU2CGKFCDT+Uv7bI7zxB2E7jMew5XhHg==
X-Received: by 2002:a05:600c:474a:b0:442:f44f:65b with SMTP id 5b1f17b1804b1-442fd675a33mr212277955e9.32.1747923104657;
        Thu, 22 May 2025 07:11:44 -0700 (PDT)
Date: Thu, 22 May 2025 16:11:43 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/2] x86/boot: attempt to print trace and panic on AP
 bring up stall
Message-ID: 
References: <20250521165504.89885-1-roger.pau@citrix.com>
 <20250521165504.89885-3-roger.pau@citrix.com>
 <8a39ec76-f050-488e-bf4c-ba378fae7275@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <8a39ec76-f050-488e-bf4c-ba378fae7275@suse.com>

On Thu, May 22, 2025 at 09:18:57AM +0200, Jan Beulich wrote:
> On 21.05.2025 18:55, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/traps.c
> > +++ b/xen/arch/x86/traps.c
> > @@ -714,13 +714,15 @@ static cpumask_t show_state_mask;
> >  static bool opt_show_all;
> >  boolean_param("async-show-all", opt_show_all);
> >  
> > +static bool force_show_all;
> > +
> >  static int cf_check nmi_show_execution_state(
> >      const struct cpu_user_regs *regs, int cpu)
> >  {
> >      if ( !cpumask_test_cpu(cpu, &show_state_mask) )
> >          return 0;
> >  
> > -    if ( opt_show_all )
> > +    if ( opt_show_all || force_show_all )
> >          show_execution_state(regs);
> >      else if ( guest_mode(regs) )
> >          printk(XENLOG_ERR "CPU%d\t%pv\t%04x:%p in guest\n",
> > @@ -734,6 +736,40 @@ static int cf_check nmi_show_execution_state(
> >      return 1;
> >  }
> >  
> > +void show_execution_state_nmi(const cpumask_t *mask, bool show_all)
> > +{
> > +    unsigned int msecs, pending;
> > +
> > +    force_show_all = show_all;

Sorry, I did send v2 before seeing your comments.

> Both forms of the call can, aiui, in principle race with one another.
> I think you want to avoid setting the static to false once it was set
> to true.
> 
> Furthermore, as long as all calls here with the 2nd argument being
> true are followed by panic() or alike, I see no reason why you couldn't
> simply re-use opt_show_all, setting that one to true. (Or else there
> would then also be some resetting of the new static.)

So basically do something like:

if ( show_all )
    opt_show_all = true;

And only overwrite opt_show_all when the caller requests full traces?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 22 14:12:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994076.1377117 (Exim 4.92)
	(envelope-from )
	id 1uI6ep-0000tc-QW; Thu, 22 May 2025 14:12:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994076.1377117; Thu, 22 May 2025 14:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI6ep-0000tV-Na; Thu, 22 May 2025 14:12:27 +0000
Received: by outflank-mailman (input) for mailman id 994076;
 Thu, 22 May 2025 14:12:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI6eo-0000MS-Kg
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:12:26 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c9babec6-3716-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 16:12:26 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-acbb85ce788so1570544766b.3
 for ; Thu, 22 May 2025 07:12:26 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d047749sm1081122966b.8.2025.05.22.07.12.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 07:12: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" 
X-Inumbo-ID: c9babec6-3716-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747923146; x=1748527946; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=5WT1DkfFx7R81SVI8Q9vhMQ65BedfWeBngMhtjc/b2Q=;
        b=AKX8bV/SoWVdCjAW65127GZjESsKqsoT9FQ1b7mo72rKQLkChr6wZ5lmNpnhcCK1RD
         zdwZcOVZ6G5PPTypZ4i5VL05aboulLN6VMvCJ1vKi5nVeFnIK+xf4SEMBgawMOWNy+PL
         yLeGw/pKXACNNly+ICIXLqcqMv0DZgIDRipig=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747923146; x=1748527946;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5WT1DkfFx7R81SVI8Q9vhMQ65BedfWeBngMhtjc/b2Q=;
        b=b00RYatHwfOK+ff+Wy2BzqqEsn88g2IibxpSxoaUaIBPo5V4C5fpmbV+o5tNgBctQP
         R1CSEvHNr7QiVClQYTI5u9DBqXMqJri01KLPzMuJNY34zGC8XrMLV/IQgfd0aiMEVTfg
         lIkC5iYYP1yJTc5dRq1LR8wmL/eiDRPZ4gRXADRbBUGcANWSXe3ZLMYAcWWX9RBe5HS1
         FrpvITsxuPZOM/HPa/fHIGIe4XCOe3cFcAk25QelFuRtZm1ccjb0iOaw0yJ8akHGynkn
         HaHGusOb4/jvexFpoPBw+/uBJP76SSLxbaO6OIYmtvGStJEngx9fimM8no3E24pjVBWD
         iO9Q==
X-Forwarded-Encrypted: i=1; AJvYcCWvdTwhZf6MyMsFMiObRyN4St/1LQzXO0n+5GyPgMthPAs+DveQDwC/rm8AQjLMAgmLpTlYgLL3fOA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhY2lbMgmCyqKlRPWEmsTSPWxY8S+s/z/KVoAS7aCu6sLe2Rmz
	o946yVQ577M4/nanyBTtNhk7uIZa5YSvLDdCbaQ/VdtaUdFS9nBFrS7IQwHDdvWe06c=
X-Gm-Gg: ASbGncumLaoNxhN65RsLph3V1ItWwkecTUag3M6Bngu20hw+4cTWVKEgNrm5O3jsmJM
	FIWbX9/1hKu5eL2o10qHgBdjhmej3wJfmgqsu9AoE7xLcfFKnPzY6FBSZCbNfZuz4dknkEF/Ven
	L+zWMzYCRBFZPQrUfav1wMSRge7V2igM1Ho9KXvOaPXCkutq4TCDMEgIFs4VQZ1zbRIt/fJk49E
	SwIMO3Of0V3K/bFlC0d0AJM9Jd2lXteUlNFlPhLbSNhWMmUGiYQ7BWA2+oLyNo/nDU5A+ClZG9I
	oHle5PyuZUTXWcWx3wXFxuKUFGObZqdggysRXY43jyrVEvPBdJeUnJNQaG3//Qw2kZfQvHqna2p
	qyrZF0gnaBmIl9r1ZXxRH1y7alSI=
X-Google-Smtp-Source: AGHT+IFzFozByInXjK711z2SmgVoJDgP+jbq+yfahBG3zec5Y3bpOA/R548xnRLW6gVGtX2NawndsQ==
X-Received: by 2002:a17:907:6096:b0:ac7:e5c4:1187 with SMTP id a640c23a62f3a-ad52d45acebmr2290383066b.11.1747923145720;
        Thu, 22 May 2025 07:12:25 -0700 (PDT)
Message-ID: <4391373f-55d4-4e37-aa97-16b2e82fefc9@citrix.com>
Date: Thu, 22 May 2025 15:12:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] x86/vpci: fix off-by-one
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich 
References: <20250522140356.5653-1-roger.pau@citrix.com>
 <20250522140356.5653-2-roger.pau@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: <20250522140356.5653-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22/05/2025 3:03 pm, Roger Pau Monne wrote:
> rangeset_remove_range() uses inclusive ranges, and hence the end of the
> range should be calculated using PFN_DOWN(), not PFN_UP().
>
> Fixes: 4acab25a9300 ('x86/vpci: fix handling of BAR overlaps with non-hole regions')
> Signed-off-by: Roger Pau Monné 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Thu May 22 14:23:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:23:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994090.1377132 (Exim 4.92)
	(envelope-from )
	id 1uI6oy-00032O-P1; Thu, 22 May 2025 14:22:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994090.1377132; Thu, 22 May 2025 14:22: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 1uI6oy-00032H-ME; Thu, 22 May 2025 14:22:56 +0000
Received: by outflank-mailman (input) for mailman id 994090;
 Thu, 22 May 2025 14:22:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI6ox-0002zG-PP
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:22:55 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 40a33811-3718-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 16:22:55 +0200 (CEST)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-ad56cbc7b07so664067166b.0
 for ; Thu, 22 May 2025 07:22:55 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d06b497sm1073300766b.42.2025.05.22.07.22.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 07:22: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" 
X-Inumbo-ID: 40a33811-3718-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747923775; x=1748528575; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=0Ix5KPQ+kVCua0Abuh8XfJpV2LATPjGLg5HSelMo16c=;
        b=FqbgJYza002xkTUT47CL+5Gv08EnxbQzKlPpnb5hvFS4i+w1/Ox8bWTLWiq98FPsw8
         s5OhVfpXlRTBTPEx9hL8dHEtbIP/O7Dv2CdAjCH+ZRil/fzwaWpmrKk86vqCN9J5hjTx
         pClj59AjBQCb2QPcI1i6DN8ZX4Yrhv4RRhaaA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747923775; x=1748528575;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0Ix5KPQ+kVCua0Abuh8XfJpV2LATPjGLg5HSelMo16c=;
        b=dOtzyBlrPOogaDgz1uFwah7wAoqXM/Z3Y4EUsgvu8gBVFUkhjUMMOZ1MNSySwZzwaH
         XEIVG805KRWxdAS/A32N0eZSbrYFm+T7gZxN9Fx8376Uw2LBEMkGlPWyHek+7PPxOq/H
         dEWFYnMcyTgA7t+Uw0hzyjJoRtQfj+FHVBl4O0EtMyxhy4MRWwnqtddlR/ub2EXFgM4W
         g9mKG0l2cXWGaluRfsTB5e5p6IT92BESHuAUuk3UvctdzbMwRIo0t6lsdhqorrwBPhu8
         HCxYWE+fIEjnd5FsXdEssRTseomr8p3JiEDHocyQ4DG+m2gZsNRHyBjK5N2WI4+qsZiT
         JPKg==
X-Forwarded-Encrypted: i=1; AJvYcCWXqe7e0/RE9H7g/bIIqBfR57oJKUK4dusPpNfL0uQLfurZZsOQQESLVIRMKlHn9/Xz6cLTJeydeQs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz6Wd4jv2PdgI/pii7UK7z+NBM7vczPgb1ojiZUTrYiE3FAst2Y
	49jOJfNmoPWxvzD0646qFk2DtgSDkTzKy/mjvsK2kv9qpXK4T9QSwuY11N75VHvJUT8=
X-Gm-Gg: ASbGncuMwWELdsE7PlQjF/tCmnUfTVadk8bOGRVuYPXewVcITm9m8tbN35RosJZV6gs
	yHDkX3uCNEMkAYXsaVXEtyZaoss1/gTBbCJrAr0w4LMBbY1Mj5bAz/lnrvgf4fAsCvcBqrggIZf
	90HwycRN5RCo8heIxIKfdI8ACAdmIQW/dbqezJARE2Il72uevpqRr4jwjXZYDPsZ0ZX4S21754N
	oMNNqI3MpeDfI2E6nQEgPbysNA1YE50+OgQnTOZHXK99hbhecxKamAG+/hKtpkbHBoVouj4SDSL
	JVZt5hd+LlxnVjax+p9aPoE1/056akDR8Louawn8nZ61GR2+4lrFWwrB3KBrcz8/5XnvzTJ/NsH
	92lfRDsElRQto/d9V
X-Google-Smtp-Source: AGHT+IG9jJvmklsdYecQkZ3q4OJUM3b3nBNP1034iCLd8MQFDiZCcAmX19fOcFfHbEf2/qU72TqcHQ==
X-Received: by 2002:a17:907:97cf:b0:ad2:4eef:d33a with SMTP id a640c23a62f3a-ad52d49b55cmr2251551066b.15.1747923774662;
        Thu, 22 May 2025 07:22:54 -0700 (PDT)
Message-ID: 
Date: Thu, 22 May 2025 15:22:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/vpci: refuse to map BARs at position 0
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich 
References: <20250522140356.5653-1-roger.pau@citrix.com>
 <20250522140356.5653-3-roger.pau@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: <20250522140356.5653-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22/05/2025 3:03 pm, Roger Pau Monne wrote:
> A BAR at position 0 is not initialized (not positioned).  While Xen could
> attempt to map it into the p2m, marking it as mapped will prevent dom0 to
> change the position of the BAR, as the vPCI code has a shortcomming of not

Minor grammar point.  "prevent dom0 from changing".

> allowing to write to BAR registers while the BAR is mapped on the p2m.
>
> Workaround this limitation by returning false from pci_check_bar() if the
> BAR address is 0, thus causing the bar->enabled field to also be set to
> false and allowing bar_write() to change the BAR position.
>
> Signed-off-by: Roger Pau Monné 
> ---
>  xen/arch/x86/pci.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
> index 26bb7f6a3c3a..39fd5a16a4aa 100644
> --- a/xen/arch/x86/pci.c
> +++ b/xen/arch/x86/pci.c
> @@ -101,6 +101,15 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
>  
>  bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
>  {
> +    /*
> +     * Refuse to map BARs at position 0, those are not initialized.  This might

"0, as they are not"

> +     * be required by Linux, that can reposition BARs with memory decoding

"Linux, which may reposition".

Otherwise, Acked-by: Andrew Cooper 

> +     * enabled.  By returning false here bar->enabled will be set to false, and
> +     * bar_write() will work as expected.
> +     */
> +    if ( mfn_eq(start, _mfn(0)) )
> +        return false;
> +
>      /*
>       * Check if BAR is not overlapping with any memory region defined
>       * in the memory map.



From xen-devel-bounces@lists.xenproject.org Thu May 22 14:32:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:32:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994100.1377142 (Exim 4.92)
	(envelope-from )
	id 1uI6xq-0004uT-JG; Thu, 22 May 2025 14:32:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994100.1377142; Thu, 22 May 2025 14:32:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI6xq-0004uM-Gd; Thu, 22 May 2025 14:32:06 +0000
Received: by outflank-mailman (input) for mailman id 994100;
 Thu, 22 May 2025 14:32:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI6xo-0004uG-Uv
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:32:04 +0000
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
 [2a00:1450:4864:20::32c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 879d568f-3719-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 16:32:04 +0200 (CEST)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43cf680d351so55434895e9.0
 for ; Thu, 22 May 2025 07:32:03 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca4d305sm23770512f8f.16.2025.05.22.07.32.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 07:32: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" 
X-Inumbo-ID: 879d568f-3719-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747924323; x=1748529123; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=r3ZXUsm2FdR51NJZ2VeI2WqISLgifbIejrHURXc0RAo=;
        b=C0fPbcL5Pua94uzAoIh9uuhTvvJrwA4VtIpxVpYt5iCHkSiqwQKxvEgsHIbORmqP1o
         yPACPhm6xWsk5ZgmdmpLa7Gs4uQUI00ru0tkfTa+rhLY1hEbkRpo0K+JPwzRlc18JfKj
         dTmCYnErQ5dtKvjrF5B4Q53G1DUqwQ1uwRO8A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747924323; x=1748529123;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=r3ZXUsm2FdR51NJZ2VeI2WqISLgifbIejrHURXc0RAo=;
        b=bCRTuM9fDP74Om/tD4gMq8j51S2/BHqt3+KVUDw9vlDjk8NZb/x6QdhvXNqt+rfXG/
         AB32r6gAHUyhB7bFXQ9pDTMFOe5xSAXpaekCh6fmF2r3mc/V1QBZs0a2NFMbSY6D9OL9
         as0UspuoDlitLjxtE9oFJibxSwOF9odGS8BLIitKEt0GdWCg0ihOFy4T2ZvhrWmoN35q
         sdOPJMbFEQV74a1ChFwef/ATz8VVJ2BdFXN0Be3NpVHNJtpJB4GqXjqvndKijX97nqld
         W4LELIsR90PUZx8rUsS7TXRBoezSAfc1oF2olQRVqTR6hXep6fKCWCx5yDdO40S1hB6M
         6kmQ==
X-Gm-Message-State: AOJu0YxPMuKMZFr/XyeyeWb70miCueT+y4nuitBSlgKBWnf1kxwtcoU+
	aaLcHeBGEt4x42hzHeNAlKbQFUtv2pEqms+oE13dKdrYF4pvDrBUEBuxzvVOp6q5lJyxsEOox0Z
	5FPw6
X-Gm-Gg: ASbGncusiF4VmJjgskb5S/xbVo8rq0ZJMjCfGY1McA6GNauKySRYAYYdQWm8NDsqKDM
	jJ4CTnpMgX3E32q43UZeDiw0O8YFS2krjHypgL3ghoZyM+/i8LisW9ILK7GhcEghkcXaWF4/O8s
	3fqtQZKyFAEZXQ0HyyKuwH9Xb62RiLf3zAss53/GAN3OcTdxP2k15sMUE2Ck3KZfw7fUTwdjT+E
	M9i+ntV45MHamEvjyZsopNc+wwng9rjrly4mt30DYFYvw6UWb2O+mNBkZAet4EaAy74/34gDo7s
	DNLxBcQn6nqH2YVkR4th9zc+g8L9jcE9xDO+1ZOnvDX53L/rq9DkiFnQYd99WlZZR0owDyY3vG0
	cH09MP7R+9WzJxpJyO630n36w
X-Google-Smtp-Source: AGHT+IGMY5dr0m5V9aUT9SX1concwJPlyu83+cW/UJSm2XeB3BDlhOMW9GN1HiD1Ztqfybn5webd7A==
X-Received: by 2002:a05:6000:144f:b0:3a3:7ba5:9a68 with SMTP id ffacd0b85a97d-3a37ba59a94mr8890561f8f.18.1747924323182;
        Thu, 22 May 2025 07:32:03 -0700 (PDT)
Date: Thu, 22 May 2025 16:32:02 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, Jan Beulich 
Subject: Re: [PATCH 2/2] x86/vpci: refuse to map BARs at position 0
Message-ID: 
References: <20250522140356.5653-1-roger.pau@citrix.com>
 <20250522140356.5653-3-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Thu, May 22, 2025 at 03:22:53PM +0100, Andrew Cooper wrote:
> On 22/05/2025 3:03 pm, Roger Pau Monne wrote:
> > A BAR at position 0 is not initialized (not positioned).  While Xen could
> > attempt to map it into the p2m, marking it as mapped will prevent dom0 to
> > change the position of the BAR, as the vPCI code has a shortcomming of not
> 
> Minor grammar point.  "prevent dom0 from changing".
> 
> > allowing to write to BAR registers while the BAR is mapped on the p2m.
> >
> > Workaround this limitation by returning false from pci_check_bar() if the
> > BAR address is 0, thus causing the bar->enabled field to also be set to
> > false and allowing bar_write() to change the BAR position.
> >
> > Signed-off-by: Roger Pau Monné 
> > ---
> >  xen/arch/x86/pci.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
> > index 26bb7f6a3c3a..39fd5a16a4aa 100644
> > --- a/xen/arch/x86/pci.c
> > +++ b/xen/arch/x86/pci.c
> > @@ -101,6 +101,15 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
> >  
> >  bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
> >  {
> > +    /*
> > +     * Refuse to map BARs at position 0, those are not initialized.  This might
> 
> "0, as they are not"
> 
> > +     * be required by Linux, that can reposition BARs with memory decoding
> 
> "Linux, which may reposition".
> 
> Otherwise, Acked-by: Andrew Cooper 

Thanks, since this is not blocking the CI right now I will probably
wait a bit to gather more feedback.

Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 22 14:40:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:40:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994108.1377152 (Exim 4.92)
	(envelope-from )
	id 1uI75V-0005ic-BC; Thu, 22 May 2025 14:40:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994108.1377152; Thu, 22 May 2025 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 1uI75V-0005i4-80; Thu, 22 May 2025 14:40:01 +0000
Received: by outflank-mailman (input) for mailman id 994108;
 Thu, 22 May 2025 14:40:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI75U-0005hS-31
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:40:00 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a30ed5df-371a-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 16:39:59 +0200 (CEST)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-601dbd75b74so7532764a12.1
 for ; Thu, 22 May 2025 07:39:59 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4ca358sm1089705766b.159.2025.05.22.07.39.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 07:39: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" 
X-Inumbo-ID: a30ed5df-371a-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747924799; x=1748529599; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9ztd2eHgaCnm9ZXAs6NqoZr1LzxEFZN7X/GWXBUY5RE=;
        b=SFZ7CH858Ot+/wUYHsBTgzirae2d/XU/UMNlcuCR0kHvw/ska+7sIXGoKGLSgbNr8Y
         6sNm8DykmKGMYRVoaDLD/D23+zRzSSfH4YA+JN3sEyFdKc1lcfHoXOkVV0vSpFC+N8go
         jDupr28PbM7cUFvja9Anu6+9suuAdGE9Isqc8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747924799; x=1748529599;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9ztd2eHgaCnm9ZXAs6NqoZr1LzxEFZN7X/GWXBUY5RE=;
        b=NIWnnBBZ8jun7CkxHuWctn9evFRDPRm8LkNZLEpAyQeuCNNz6ClECxPgAydpNbgjhL
         DkoquuaNgFjTjzw62ezh3zkMSlRMpcnbDRx3T7xfru7B2OsFfNXFYB7r5NoYcrJSLJP5
         dHeO+LnUcsFb2YqMJr7Iz1eIdGfiULNnIjvq8eJ+HGKhy1kXwM/iIkpWnTZc3AfgJHxX
         Z52SNRYJeH7bCH1yHAMyg/VbTvkQAjM/W3Nt7aAs7wQpB692sqjFPFWT+LyVcb+ZAGXL
         G1HD26wworU0lxM260tRjwoh1dlwSEm8xnLX59ScE9UED0JPmvcaLsPXtUKt/zFT84Ob
         hOhQ==
X-Gm-Message-State: AOJu0YyJbkP6PnN6l0o2wgIX0SjClRVlZtGflIy+Wr4xmives2tHzZHB
	5f6BwxI2AXkVHc2t78mFWrsTuORL5FHrQhsRmIiPHPg//OeiR6DWZeVqI19NTBWf+S0=
X-Gm-Gg: ASbGncvjkaaSIMwYPCjKMZp/zIbS65txWer7WOEv5UYBm5aCq5s6Raw8nESwESjsUbL
	/gPBlSbQePSb7bmUEB35oouylrR9XPRTSksWGGG3SuxElpwYqVCYt07ZQMF8kvrZj2lF0IVvi7v
	YMuvcsg+i2ZJlQirfBX3qYRuxgysv9R6hjkNLXOmAEjHWfJe7qRjE0kSzwHY/x+1sFDmvnZX/dA
	UIwgkkVSTgxYowpf3cHpXgmflIgoDZWVaeBENR1kMp0y/RpmtyPg6/CafsKZ3xmxOuf8LBTBj1v
	8/LwJlOllhsn6ay6Ic7Pb6GQz6cgAs5Qv0O+gqTidxNLZ1pV6te1W3iAoT8+bQB/M0+TeUDhJhI
	jNV9n1r7M3wvicA8U7LuGhoW7PJg=
X-Google-Smtp-Source: AGHT+IHTNdWMcY7VZtf912e15tflPTPWuc2fb6pzsg1CCqNP1rWgYFbN0FtsWjm7LCoJ4rDQBk4z9Q==
X-Received: by 2002:a17:907:930b:b0:ad2:2e99:8d9b with SMTP id a640c23a62f3a-ad5370339c4mr2601115366b.58.1747924798762;
        Thu, 22 May 2025 07:39:58 -0700 (PDT)
Message-ID: <8c1156a8-a626-4b62-9cc1-7790184b2b9b@citrix.com>
Date: Thu, 22 May 2025 15:39:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] x86/boot: print CPU and APIC ID in bring up
 failure
To: Jan Beulich , Roger Pau Monne 
Cc: xen-devel@lists.xenproject.org
References: <20250522075440.99882-1-roger.pau@citrix.com>
 <20250522075440.99882-2-roger.pau@citrix.com>
 <0028ad37-95e7-4b6e-87b6-07cadcac64aa@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: <0028ad37-95e7-4b6e-87b6-07cadcac64aa@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22/05/2025 10:10 am, Jan Beulich wrote:
> On 22.05.2025 09:54, Roger Pau Monne wrote:
>> Print the CPU and APIC ID that fails to respond to the init sequence, or
>> that didn't manage to reach the "callin" state.  Expand a bit the printed
>> error messages.  Otherwise the "Not responding." message is not easy to
>> understand by users.
>>
>> Reported-by: Andrew Cooper 
>> Signed-off-by: Roger Pau Monné 
>> ---
>> Changes since v1:
>>  - Also print APIC ID.
>> ---
>>  xen/arch/x86/smpboot.c | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>> index 0189d6c332a4..dbc2f2f1d411 100644
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -618,10 +618,12 @@ static int do_boot_cpu(int apicid, int cpu)
>>              smp_mb();
>>              if ( bootsym(trampoline_cpu_started) == 0xA5 )
>>                  /* trampoline started but...? */
>> -                printk("Stuck ??\n");
>> +                printk("CPU%u/APICID%u: Didn't finish startup sequence\n",
>> +                       cpu, apicid);
>>              else
>>                  /* trampoline code not run */
>> -                printk("Not responding.\n");
>> +                printk("CPU%u/APICID%u: Not responding to startup\n",
>> +                       cpu, apicid);
>>          }
>>      }
>>  
> Elsewhere I think we print AIC IDs in hex; may be better to do so here, too.
> That may then want some text re-arrangement though, e.g.
>
> "CPU%u: APICID %#x not responding to startup\n"
>
> Thoughts?

Definitely hex.  Elsewhere APIC_ID always has an underscore.

I'd suggest:

"APIC_ID %#x (CPU%u) didn't respond to SIPI\n"

The APIC_ID is the critical detail, and the CPU number is fairly incidental.

Also as we're changing things, lets not retain the STARTUP name seeing
as it only exists on pre-Pentium APICs.  SIPI is what we use these days.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu May 22 14:42:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:42:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994119.1377162 (Exim 4.92)
	(envelope-from )
	id 1uI78G-0007K5-RG; Thu, 22 May 2025 14:42:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994119.1377162; Thu, 22 May 2025 14:42: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 1uI78G-0007Jy-OX; Thu, 22 May 2025 14:42:52 +0000
Received: by outflank-mailman (input) for mailman id 994119;
 Thu, 22 May 2025 14:42:51 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI78F-0007Jn-Iu
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:42:51 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 089eb91d-371b-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 16:42:49 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-601609043cfso9762871a12.0
 for ; Thu, 22 May 2025 07:42:49 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ae3953esm10653845a12.73.2025.05.22.07.42.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 07:42: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" 
X-Inumbo-ID: 089eb91d-371b-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747924969; x=1748529769; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=y3NTkdgLVJmWzTRtqaYUwk6F+4R/sk6sNQTp3bKkVpo=;
        b=BcWnidNz6EKQdSOlUSbP4/QH9g7vbq6UxYmSJl+D16QGhdav1+Q0QElPUaKzn80Y52
         3Is8iqhCnvbCxXroemSDkZL6bGUxzBHmx9D+5JDNMiSSWDkZKClZY5sa4kRnq+s/+Ben
         xXsMFIXScgsSKUyfY2l4kk54SEbDPNzaEKYzs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747924969; x=1748529769;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=y3NTkdgLVJmWzTRtqaYUwk6F+4R/sk6sNQTp3bKkVpo=;
        b=Ydc5T/bz1JHRr5V0hlZjL13xHP5syewGtOS7S0e1oOYq0UGksPgpm0SvdX3tVleT1v
         H1oMyL8IfD2xqLb3U6Z9jx/+C3wEnbVNRLBKmmw2HuTsVMwug4JnTZP4Iz7fSiQ7K84p
         mncy884AomlFuBtkojctfG1XjEq8fkGUY6CAv+1XrkXr1w+QRMglRykOJitZHsvhEQKh
         IEIcJyrMye/DlyzyYPnzgRWqc+ylSET7wBFVbc7Gz7uGcxesP5eWrMhCuL59V+n56BmH
         hrmrFmLDKUwaMp6mClKlyz6zi8cJ8wKrwQAl8D0i7RJHGQYcvLc9VzzvMOGIg1dEbcVS
         PqHA==
X-Forwarded-Encrypted: i=1; AJvYcCWnq8BX3LQ62bSFnweKvQDzauoo7jMqgVLmlIc+wvcZrsTAAlYWWRebF+gNB9It6J4xlHx4ZHh6GCQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzRtEfgbFbp3gZBZUYwCtVxsNA1qxT4qkLgOTMETHn4Rq2SORaA
	Q+tbQKNkX4eR1kCNNvmRsS4h11N2VWZWeeFU864QD50nn1msv5Xj249+0xJ22oNqO301POMUMWy
	z2Jnv
X-Gm-Gg: ASbGncvwoCwOF/wWIXmYS/nsO4g2MXsGOvunhj8I/0GaTr2S5svsMzjxYYrvsOt+gx3
	rHeLHgD+6Kph1tC9H72YSoRq1DMp3rqTgU6Ll0ukv+gJ9o6c9WeU759gmA7us0hnIwWAEJNFv8X
	uDHNH0ovYXYJ5J8fXwTNukLgGDn8WqKsB0khjbduL7TA+ETlZ50HX0sGSOi/HCEIr+KK+Sde1aI
	Cwve5jI6kV6zmt4HPmElE0zEJ/V2L5jFgOKxjhDgzrh3LY2l9roMxCfVJeujW2H+tBLOjHlMO10
	TRkBL3OqcUhGE9atyXvLJMeixhNWAoHJh615HZwLfQjQbh4LtW4y84CCGqC2EWm+9dRn4rgr678
	GmKr2AtVtTxitsx8F
X-Google-Smtp-Source: AGHT+IGNxH2U655aZK4F4n3D8eX7l68brGYlTtqeoZLMuGAfgxuvWLjFuQNbx2OhWc+OLmKMj9yPVQ==
X-Received: by 2002:a05:6402:42c1:b0:5ec:c990:b578 with SMTP id 4fb4d7f45d1cf-6009008eb55mr20726488a12.19.1747924969155;
        Thu, 22 May 2025 07:42:49 -0700 (PDT)
Message-ID: 
Date: Thu, 22 May 2025 15:42:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/4] x86/boot: attempt to print trace and panic on AP
 bring up stall
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich 
References: <20250522075440.99882-1-roger.pau@citrix.com>
 <20250522075440.99882-5-roger.pau@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: <20250522075440.99882-5-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22/05/2025 8:54 am, Roger Pau Monne wrote:
> With the current AP bring up code, Xen can get stuck indefinitely if an AP
> freezes during boot after the 'callin' step.  Introduce a 5s timeout while
> waiting for APs to finish startup.
>
> On failure of an AP to complete startup, send an NMI to trigger the
> printing of a stack backtrace on the stuck AP and panic on the BSP.
>
> This patch was done while investigating the issue caused by Intel erratum
> ICX143.  It wasn't helpful in that case, but it's still and improvement
> when debugging AP bring up related issues.
>
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Thu May 22 14:47:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:47:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994128.1377172 (Exim 4.92)
	(envelope-from )
	id 1uI7Cb-0008E2-Ab; Thu, 22 May 2025 14:47:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994128.1377172; Thu, 22 May 2025 14: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 1uI7Cb-0008Dv-7g; Thu, 22 May 2025 14:47:21 +0000
Received: by outflank-mailman (input) for mailman id 994128;
 Thu, 22 May 2025 14:47:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI7CZ-0008Dn-Tg
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:47:20 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a8c7e7a9-371b-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 16:47:18 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad5533c468cso842549566b.0
 for ; Thu, 22 May 2025 07:47:18 -0700 (PDT)
Received: from [10.0.5.8] ([213.235.133.42]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d2720b7sm1075601866b.70.2025.05.22.07.47.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 07: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" 
X-Inumbo-ID: a8c7e7a9-371b-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747925238; x=1748530038; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=gOZxNsCX6wG3tpIQHO5zMjjXtstA1cqpxf8cNPhrzes=;
        b=XZ8oscRsqFnTjX9m5xuikm25MCulVemHbOsPY/TjHn0ZuHKxl/tm8v9iJnYJdY5Lqd
         JLI7S9sYANp9b/JevXGblqHMAVOGn9Jek4su8a58XbcXVhJh0LdR4iStsI86fL/tVnJ0
         31R0Ern+fM/R3n8sflhlxIutWfYo+gPU/WLScRQcPRv8QLm10ooRodclMHR6zwJzDSk9
         lSFhFC+Gq2z7MVFTCTRSApR+mEn0zmHvnxg2dNh3v6G0jiPvkEgen4kwkMjPG4p087N+
         sFlkEw8fq8to9bHLBGvo+z2EkIAk/s1fZNvYtcvFKBbchc3gFD8577g53knc/kTxfkSs
         yoVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747925238; x=1748530038;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=gOZxNsCX6wG3tpIQHO5zMjjXtstA1cqpxf8cNPhrzes=;
        b=EadAFTo/N4O5+hcw4hkgdmWpyCccvcMZv2BV2O94Z8Ha4RJC9aEIk7/QRE0jfJIzH8
         KbSEGdZ0uS4qN/wcK2Oc/Hzv1XiwcMfZ2qtuPmgjncp/k8FHnzrDTTtaRmXZF0jH0T/q
         U9aIgZ9k6efpprtU9dpXGoxsGqBAas4i40xVrsRXJpat5QaONanU6drjPBri3TntN3xz
         1sNN5OpHnfIiflifZUmTvyH+/9Vh5BpceSW7p7hgJUbx5wXBZzOPvOVNkbQQq5tG34UH
         loqS98BwnE3Lz8/HB4/010N1By3uwQ5mw/pX25LpQSVcpeqC+xd4oeI3/tSfAC6sF3MC
         M/cw==
X-Forwarded-Encrypted: i=1; AJvYcCVObyYqBbFpKpniouOdnhRGXHLfMh6RzKk9SNcisunbCUgqZdu30snLFlltJf2tzbJT0ytricbG36w=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxuby4XxugXCH4tRhAvfePVAvUmFjyqO0KL/TsG5rvMpK8EV8np
	6Zrw40DxSV5bEV++lpy7sNwltJfscLEBDbKY2RpuaEH7v5ar/NkZlQPHxwX2y5Cz7Q==
X-Gm-Gg: ASbGncuwy0kume+NfFIKuh9h4ezZs66JaOawu/86wnpLJ09gFKRzgz+FSOqhp5a2TJA
	9d/jt/OO8FM+lRzNPgBcwaQun6EyJS0TZkNinf6eohLKI8ZZMJ2RpCQDJyfrDeHBL1JalPU0ysw
	76TiSywP985YFTNHMAmM/KB66sfTAPW09RBEipJ4cXq6SOYjwjpXCFMkOnybI9k4gpvZINbq9tB
	/ZYzvEJzuwwrV1pz0qoPE2giq9MJqXdU62frElAq5me6PbIOgzJ8OuoVqkVqok5klouSeDOdQvA
	VYq0kvE22RQ7wZV2mVzQ/de7PTmrPQ==
X-Google-Smtp-Source: AGHT+IFvLG2r0FNKYXg+YicOYkmTMCbUk3UmFoba8PeD9m8xcef5QzUH/0PBx4h/5ZusWIoHKzimOA==
X-Received: by 2002:a17:907:3e03:b0:ad4:c55e:ef8b with SMTP id a640c23a62f3a-ad536f9db9emr2044586466b.48.1747925237702;
        Thu, 22 May 2025 07:47:17 -0700 (PDT)
Message-ID: 
Date: Thu, 22 May 2025 16:46:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/imsic.c
> @@ -0,0 +1,354 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/imsic.c
> + *
> + * RISC-V Incoming MSI Controller support
> + *
> + * (c) Microchip Technology Inc.
> + * (c) Vates
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +static struct imsic_config imsic_cfg;
> +
> +/* Callers aren't expected to changed imsic_cfg so return const. */
> +const struct imsic_config *imsic_get_config(void)
> +{
> +    return &imsic_cfg;
> +}

Minor remark regarding the comment: Consider replacing "expected" by "supposed"
or "intended"?

> +/*
> + * Parses IMSIC DT node.
> + *
> + * Returns 0 if initialization is successful, a negative value on failure,
> + * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
> + * which should be ignored by the hypervisor.
> + */
> +static int imsic_parse_node(const struct dt_device_node *node,
> +                            unsigned int *nr_parent_irqs)
> +{
> +    int rc;
> +    unsigned int tmp;
> +    paddr_t base_addr;
> +    uint32_t *irq_range;
> +
> +    *nr_parent_irqs = dt_number_of_irq(node);
> +    if ( !*nr_parent_irqs )
> +        panic("%s: irq_num can be 0. Check %s node\n", __func__,
> +              dt_node_full_name(node));

DYM "can't be"?

> +    irq_range = xzalloc_array(uint32_t, *nr_parent_irqs * 2);
> +    if ( !irq_range )
> +        panic("%s: irq_range[] allocation failed\n", __func__);
> +
> +    if ( (rc = dt_property_read_u32_array(node, "interrupts-extended",
> +                                    irq_range, *nr_parent_irqs * 2)) )
> +        panic("%s: unable to find interrupt-extended in %s node: %d\n",
> +              __func__, dt_node_full_name(node), rc);
> +
> +    if ( irq_range[1] == IRQ_M_EXT )
> +    {
> +        /* Machine mode imsic node, ignore it. */
> +        rc = IRQ_M_EXT;
> +        goto cleanup;
> +    }

Wouldn't this better be done ...

> +    /* Check that interrupts-extended property is well-formed. */
> +    for ( unsigned int i = 2; i < (*nr_parent_irqs * 2); i += 2 )
> +    {
> +        if ( irq_range[i + 1] != irq_range[1] )
> +            panic("%s: mode[%d] != %d\n", __func__, i + 1, irq_range[1]);
> +    }

... after this consistency check?

Also %u please when you log unsigned values.

> +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
> +                               &imsic_cfg.guest_index_bits) )
> +        imsic_cfg.guest_index_bits = 0;
> +    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
> +    if ( tmp < imsic_cfg.guest_index_bits )
> +    {
> +        printk(XENLOG_ERR "%s: guest index bits too big\n",
> +               dt_node_name(node));
> +        rc = -ENOENT;
> +        goto cleanup;
> +    }
> +
> +    /* Find number of HART index bits */
> +    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
> +                               &imsic_cfg.hart_index_bits) )
> +    {
> +        /* Assume default value */
> +        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
> +        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
> +            imsic_cfg.hart_index_bits++;

Since fls() returns a 1-based bit number, isn't it rather that in the
exact-power-of-2 case you'd need to subtract 1?

> +    }
> +    tmp -= imsic_cfg.guest_index_bits;
> +    if ( tmp < imsic_cfg.hart_index_bits )
> +    {
> +        printk(XENLOG_ERR "%s: HART index bits too big\n",
> +               dt_node_name(node));
> +        rc = -ENOENT;
> +        goto cleanup;
> +    }
> +
> +    /* Find number of group index bits */
> +    if ( !dt_property_read_u32(node, "riscv,group-index-bits",
> +                               &imsic_cfg.group_index_bits) )
> +        imsic_cfg.group_index_bits = 0;
> +    tmp -= imsic_cfg.hart_index_bits;
> +    if ( tmp < imsic_cfg.group_index_bits )
> +    {
> +        printk(XENLOG_ERR "%s: group index bits too big\n",
> +               dt_node_name(node));
> +        rc = -ENOENT;
> +        goto cleanup;
> +    }
> +
> +    /* Find first bit position of group index */
> +    tmp = IMSIC_MMIO_PAGE_SHIFT * 2;
> +    if ( !dt_property_read_u32(node, "riscv,group-index-shift",
> +                               &imsic_cfg.group_index_shift) )
> +        imsic_cfg.group_index_shift = tmp;
> +    if ( imsic_cfg.group_index_shift < tmp )
> +    {
> +        printk(XENLOG_ERR "%s: group index shift too small\n",
> +               dt_node_name(node));
> +        rc = -ENOENT;
> +        goto cleanup;
> +    }
> +    tmp = imsic_cfg.group_index_bits + imsic_cfg.group_index_shift - 1;
> +    if ( tmp >= BITS_PER_LONG )
> +    {
> +        printk(XENLOG_ERR "%s: group index shift too big\n",
> +               dt_node_name(node));
> +        rc = -EINVAL;
> +        goto cleanup;
> +    }
> +
> +    /* Find number of interrupt identities */
> +    if ( !dt_property_read_u32(node, "riscv,num-ids", &imsic_cfg.nr_ids) )
> +    {
> +        printk(XENLOG_ERR "%s: number of interrupt identities not found\n",
> +               node->name);
> +        rc = -ENOENT;
> +        goto cleanup;
> +    }
> +
> +    if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) ||
> +         (imsic_cfg.nr_ids > IMSIC_MAX_ID) ||
> +         ((imsic_cfg.nr_ids & IMSIC_MIN_ID) != IMSIC_MIN_ID) )

Now that you've explained to me what the deal is with these constants: Isn't
the 1st of the three checks redundant with the last one?

> +    {
> +        printk(XENLOG_ERR "%s: invalid number of interrupt identities\n",
> +               node->name);
> +        rc = -EINVAL;
> +        goto cleanup;
> +    }
> +
> +    /* Compute base address */
> +    imsic_cfg.nr_mmios = 0;
> +    rc = dt_device_get_address(node, imsic_cfg.nr_mmios, &base_addr, NULL);
> +    if ( rc )
> +    {
> +        printk(XENLOG_ERR "%s: first MMIO resource not found: %d\n",
> +               dt_node_name(node), rc);
> +        goto cleanup;
> +    }
> +
> +    imsic_cfg.base_addr = base_addr;
> +    imsic_cfg.base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
> +                                 imsic_cfg.hart_index_bits +
> +                                 IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
> +    imsic_cfg.base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
> +                             imsic_cfg.group_index_shift);
> +
> +    /* Find number of MMIO register sets */
> +    do {
> +        imsic_cfg.nr_mmios++;
> +    } while ( !dt_device_get_address(node, imsic_cfg.nr_mmios, &base_addr, NULL) );
> +
> + cleanup:
> +    xfree(irq_range);

Afacit you could free this array way earlier. That would then simplify quite
a few of the error paths, I think.

> +/*
> + * Initialize the imsic_cfg structure based on the IMSIC DT node.
> + *
> + * Returns 0 if initialization is successful, a negative value on failure,
> + * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
> + * which should be ignored by the hypervisor.
> + */
> +int __init imsic_init(const struct dt_device_node *node)
> +{
> +    int rc;
> +    unsigned long reloff, hartid;
> +    unsigned int nr_parent_irqs, index, nr_handlers = 0;
> +    paddr_t base_addr;
> +    unsigned int nr_mmios;
> +
> +    /* Parse IMSIC node */
> +    rc = imsic_parse_node(node, &nr_parent_irqs);
> +    /*
> +     * If machine mode imsic node => ignore it.
> +     * If rc < 0 => parsing of IMSIC DT node failed.
> +     */
> +    if ( (rc == IRQ_M_EXT) || rc )
> +        return rc;

The former of the checks is redundant with the latter. Did you perhaps mean
"rc < 0" for that one?

> +    nr_mmios = imsic_cfg.nr_mmios;
> +
> +    /* Allocate MMIO resource array */
> +    imsic_cfg.mmios = xzalloc_array(struct imsic_mmios, nr_mmios);

How large can this and ...

> +    if ( !imsic_cfg.mmios )
> +    {
> +        rc = -ENOMEM;
> +        goto imsic_init_err;
> +    }
> +
> +    imsic_cfg.msi = xzalloc_array(struct imsic_msi, nr_parent_irqs);

... this array grow (in principle)? I think you're aware that in principle
new code is expected to use xvmalloc() and friends unless there are specific
reasons speaking against that.

> +    if ( !imsic_cfg.msi )
> +    {
> +        rc = -ENOMEM;
> +        goto imsic_init_err;
> +    }
> +
> +    /* Check MMIO register sets */
> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
> +    {
> +        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
> +        {
> +            rc = -ENOMEM;
> +            goto imsic_init_err;
> +        }
> +
> +        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
> +                                   &imsic_cfg.mmios[i].size);
> +        if ( rc )
> +        {
> +            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
> +                   node->name, i);
> +            goto imsic_init_err;
> +        }
> +
> +        base_addr = imsic_cfg.mmios[i].base_addr;
> +        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
> +                           imsic_cfg.hart_index_bits +
> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
> +                       imsic_cfg.group_index_shift);
> +        if ( base_addr != imsic_cfg.base_addr )
> +        {
> +            rc = -EINVAL;
> +            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
> +                   node->name, i);
> +            goto imsic_init_err;
> +        }

Maybe just for my own understanding: There's no similar check for the
sizes to match / be consistent wanted / needed?

> +    }
> +
> +    /* Configure handlers for target CPUs */
> +    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
> +    {
> +        unsigned long xen_cpuid;
> +
> +        rc = imsic_get_parent_hartid(node, i, &hartid);
> +        if ( rc )
> +        {
> +            printk(XENLOG_WARNING "%s: cpu ID for parent irq%u not found\n",
> +                   node->name, i);
> +            continue;
> +        }
> +
> +        xen_cpuid = hartid_to_cpuid(hartid);

I'm probably biased by "cpuid" having different meaning on x86, but: To
be consistent with variable names elsewhere, couldn't this variable simply
be named "cpu"? With the other item named "hartid" there's no ambiguity
there anymore.

> +        if ( xen_cpuid >= num_possible_cpus() )
> +        {
> +            printk(XENLOG_WARNING "%s: unsupported cpu ID=%lu for parent irq%u\n",
> +                   node->name, hartid, i);

The message continues to be ambiguous (to me as a non-RISC-V person at
least): You log a hart ID, while you say "cpu ID". Also, as I think I
said elsewhere already, the hart ID may better be logged using %#lx.

> +            continue;
> +        }
> +
> +        /* Find MMIO location of MSI page */
> +        reloff = i * BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ;
> +        for ( index = 0; index < nr_mmios; index++ )
> +        {
> +            if ( reloff < imsic_cfg.mmios[index].size )
> +                break;
> +
> +            /*
> +             * MMIO region size may not be aligned to
> +             * BIT(global->guest_index_bits) * IMSIC_MMIO_PAGE_SZ
> +             * if holes are present.
> +             */
> +            reloff -= ROUNDUP(imsic_cfg.mmios[index].size,
> +                BIT(imsic_cfg.guest_index_bits, UL) * IMSIC_MMIO_PAGE_SZ);

Nit: Indentation once again.

> +        }
> +
> +        if ( index == nr_mmios )
> +        {
> +            printk(XENLOG_WARNING "%s: MMIO not found for parent irq%u\n",
> +                   node->name, i);
> +            continue;
> +        }
> +
> +        if ( !IS_ALIGNED(imsic_cfg.msi[xen_cpuid].base_addr + reloff, PAGE_SIZE) )

If this is the crucial thing to check, ...

> +        {
> +            printk(XENLOG_WARNING "%s: MMIO address %#lx is not aligned on a page\n",
> +                   node->name, imsic_cfg.msi[xen_cpuid].base_addr + reloff);
> +            imsic_cfg.msi[xen_cpuid].offset = 0;
> +            imsic_cfg.msi[xen_cpuid].base_addr = 0;
> +            continue;
> +        }
> +
> +        cpumask_set_cpu(xen_cpuid, imsic_cfg.mmios[index].cpus);
> +
> +        imsic_cfg.msi[xen_cpuid].base_addr = imsic_cfg.mmios[index].base_addr;
> +        imsic_cfg.msi[xen_cpuid].offset = reloff;

... why is it that the two parts are stored separately? If their sum needs to
be page-aligned, I'd kind of expect it's only ever the sum which is used?

Also is it really PAGE_SHIFT or rather IMSIC_MMIO_PAGE_SHIFT that needs
chacking against?

Further please pay attention to line length limits - there are at least two
violations around my earlier comment here.

> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/imsic.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/include/asm/imsic.h
> + *
> + * RISC-V Incoming MSI Controller support
> + *
> + * (c) Microchip Technology Inc.
> + */
> +
> +#ifndef ASM__RISCV__IMSIC_H
> +#define ASM__RISCV__IMSIC_H

Please update according to the most recent naming rules change (all it takes
may be to shrink the double underscores).

> +#include 
> +
> +#define IMSIC_MMIO_PAGE_SHIFT   12
> +#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
> +
> +#define IMSIC_MIN_ID            63
> +#define IMSIC_MAX_ID            2047
> +
> +struct imsic_msi {
> +    paddr_t base_addr;
> +    unsigned long offset;
> +};
> +
> +struct imsic_mmios {
> +    paddr_t base_addr;
> +    unsigned long size;
> +    cpumask_var_t cpus;
> +};
> +
> +struct imsic_config {
> +    /* Base address */
> +    paddr_t base_addr;
> +
> +    /* Bits representing Guest index, HART index, and Group index */
> +    unsigned int guest_index_bits;
> +    unsigned int hart_index_bits;
> +    unsigned int group_index_bits;
> +    unsigned int group_index_shift;
> +
> +    /* IMSIC phandle */
> +    unsigned int phandle;
> +
> +    /* Number of parent irq */
> +    unsigned int nr_parent_irqs;
> +
> +    /* Number off interrupt identities */
> +    unsigned int nr_ids;
> +
> +    /* MMIOs */
> +    unsigned int nr_mmios;
> +    struct imsic_mmios *mmios;

Are the contents of this and ...

> +    /* MSI */
> +    struct imsic_msi *msi;

... this array ever changing post-init? If not, the pointers here may want
to be pointer-to-const (requiring local variables in the function populating
the field).

> @@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
>      return pcpu_info[cpuid].hart_id;
>  }
>  
> +static inline unsigned long hartid_to_cpuid(unsigned long hartid)
> +{
> +    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
> +    {
> +        if ( hartid == cpuid_to_hartid(cpuid) )
> +            return cpuid;
> +    }
> +
> +    /* hartid isn't valid for some reason */
> +    return NR_CPUS;
> +}

Considering the values being returned, why's the function's return type
"unsigned long"?

Why the use of ARRAY_SIZE() in the loop header? You don't use pcpu_info[]
in the loop body.

Finally - on big systems this is going to be pretty inefficient a lookup.
This may want to at least have a TODO comment attached.

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 14:53:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:53:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994139.1377185 (Exim 4.92)
	(envelope-from )
	id 1uI7IR-0001kP-8H; Thu, 22 May 2025 14:53:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994139.1377185; Thu, 22 May 2025 14:53: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 1uI7IR-0001kI-5h; Thu, 22 May 2025 14:53:23 +0000
Received: by outflank-mailman (input) for mailman id 994139;
 Thu, 22 May 2025 14:53:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI7IP-0001kC-Uv
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:53:21 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 80b1cec3-371c-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 16:53:20 +0200 (CEST)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-acae7e7587dso1194249566b.2
 for ; Thu, 22 May 2025 07:53:20 -0700 (PDT)
Received: from [10.0.5.8] ([213.235.133.42]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4c516dsm1082632766b.154.2025.05.22.07.53.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 07:53: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" 
X-Inumbo-ID: 80b1cec3-371c-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747925600; x=1748530400; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=VEg1fqgSn+yG5ljEwaLpHIjQFbYXD7XUpvkK1Lj8BDg=;
        b=HCszTBy6ihRUwdQXAh29ewJK5M5mIO5+VN8pbK24IyM2jIVu66HdeiQbcwEGt1gZC4
         rumDH42SoP3v6yNZGxXpSC0Q7sQPCo+zd3ZmQoVsNiC/0NKu7dyRPv5clpNEKjUZyPmD
         +Zy77pGWn2YBf66UJsSNIuYMXMj8W5uAUOPUdMSYNY4XJAlaeLSEXbYPhrCD47GrIbeY
         Pv+QvcsftCBWauMf8iXuhR11ZlBQ8OSDT8ak31JdzxUDv3eb9cgpffwV6TdSTqjA//wU
         b8+ckSBl8JU9PC3Jca1oHkvydspWalC3x7qnEQwIYCRw/a0brAawpnHrCHDMIfb6cbGM
         K/WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747925600; x=1748530400;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=VEg1fqgSn+yG5ljEwaLpHIjQFbYXD7XUpvkK1Lj8BDg=;
        b=Nzlzz/84VX3rTFJEvGltty/aP9OHjnMjdEzs2uqrDbgXqXEtodgLTEwmKoBmz3Uqy/
         bxfoNqT71znJhO+A+ShdYAsVQXQZ/qWD+LrvthP8tfZH+G68lckgi0q+vYYZkNmlz/uH
         IT7d6p34nMKHhSAAnOyhGYaj2EjPpnFPgmPs70GcEhRQE49NvqHJS/eWBNm2CuAjST3z
         jgiZZy4OSkYS1jo0umIL/wQNEPl6+0vsKYbrOBD5Ig9G9DXvgfKS35ab02vbjEwXXact
         6EENqqbNOl6CUcQfEOK/8O6l+jiPLVYEqtbIlAFnuSTNCPTXgZJJv/BQIwLw4ql0PbCk
         358g==
X-Forwarded-Encrypted: i=1; AJvYcCXPo950hTTqyx1ZVV4Z2D+oGdDuBF/Ajpsa3Zu9IHlxDsTcyThc6GjWTqxquC6uf05S/IX4Mw4IopQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxlRxuO5P8374XR0pmazwiO9NDLbVKpI5id1Lo3EcB59/DjanLK
	eppekKRmygVXrLi57I6UyC1KVljgbG8yc6LEmBvj0rYkut7FrGJPV/Tsx1P6OOk5KQ==
X-Gm-Gg: ASbGncsTes0DFlHd4/iobriWzI5hU+qBpHQ8ZCbMJEAA3ImUjwIZmQm5+rkERsJAkXd
	bP/VNB/xeUwzJs8DLBCKC/JrVXXyBrcjkV/UUAxBRKvXsWKBz7QpcN7oNXPR3gUTTt3eCq2oWNH
	v6q2EoGJyXJXI+F3BJk+uKE6ysXnz6/ON1LH21zkRp74/UGSxs7IcmRLO21GHTH/GUX8fTOe4oF
	fiCSMvLT8+eTd3wSUtcN/oD59InaRTKYrlw4EmxzvHl2bv1wiBvQrj+bXPXp98spKm7q7QUy3rf
	i7fDsWFBD3h7dI/4RYk=
X-Google-Smtp-Source: AGHT+IETXLzJwAvXix9Cn5rUU9e236fbuJXs54DfCmNruV7irP9jNvFdcdcudDHLaIDQNQjx65TWJA==
X-Received: by 2002:a17:906:ef09:b0:ad2:42f3:86e0 with SMTP id a640c23a62f3a-ad52d548672mr2461316766b.27.1747925600163;
        Thu, 22 May 2025 07:53:20 -0700 (PDT)
Message-ID: <9b1555cf-507e-4b05-ab3d-91f994e334dc@suse.com>
Date: Thu, 22 May 2025 16:53:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/boot: attempt to print trace and panic on AP
 bring up stall
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250521165504.89885-1-roger.pau@citrix.com>
 <20250521165504.89885-3-roger.pau@citrix.com>
 <8a39ec76-f050-488e-bf4c-ba378fae7275@suse.com>
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.05.2025 16:11, Roger Pau Monné wrote:
> On Thu, May 22, 2025 at 09:18:57AM +0200, Jan Beulich wrote:
>> On 21.05.2025 18:55, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -714,13 +714,15 @@ static cpumask_t show_state_mask;
>>>  static bool opt_show_all;
>>>  boolean_param("async-show-all", opt_show_all);
>>>  
>>> +static bool force_show_all;
>>> +
>>>  static int cf_check nmi_show_execution_state(
>>>      const struct cpu_user_regs *regs, int cpu)
>>>  {
>>>      if ( !cpumask_test_cpu(cpu, &show_state_mask) )
>>>          return 0;
>>>  
>>> -    if ( opt_show_all )
>>> +    if ( opt_show_all || force_show_all )
>>>          show_execution_state(regs);
>>>      else if ( guest_mode(regs) )
>>>          printk(XENLOG_ERR "CPU%d\t%pv\t%04x:%p in guest\n",
>>> @@ -734,6 +736,40 @@ static int cf_check nmi_show_execution_state(
>>>      return 1;
>>>  }
>>>  
>>> +void show_execution_state_nmi(const cpumask_t *mask, bool show_all)
>>> +{
>>> +    unsigned int msecs, pending;
>>> +
>>> +    force_show_all = show_all;
> 
> Sorry, I did send v2 before seeing your comments.
> 
>> Both forms of the call can, aiui, in principle race with one another.
>> I think you want to avoid setting the static to false once it was set
>> to true.
>>
>> Furthermore, as long as all calls here with the 2nd argument being
>> true are followed by panic() or alike, I see no reason why you couldn't
>> simply re-use opt_show_all, setting that one to true. (Or else there
>> would then also be some resetting of the new static.)
> 
> So basically do something like:
> 
> if ( show_all )
>     opt_show_all = true;
> 
> And only overwrite opt_show_all when the caller requests full traces?

Yes, that's what I think it boils down to.

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 14:59:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 14:59:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994160.1377195 (Exim 4.92)
	(envelope-from )
	id 1uI7O7-0002PZ-Vv; Thu, 22 May 2025 14:59:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994160.1377195; Thu, 22 May 2025 14: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 1uI7O7-0002PS-Sg; Thu, 22 May 2025 14:59:15 +0000
Received: by outflank-mailman (input) for mailman id 994160;
 Thu, 22 May 2025 14:59:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI7O6-0002PM-7f
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 14:59:14 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 52435690-371d-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 16:59:12 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5fbfdf7d353so10730404a12.0
 for ; Thu, 22 May 2025 07:59:12 -0700 (PDT)
Received: from [10.0.5.8] ([213.235.133.42]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d4f5fe5sm10612020a12.7.2025.05.22.07.59.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 07:59: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" 
X-Inumbo-ID: 52435690-371d-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747925952; x=1748530752; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=pM2cuzmldAVHXAvYRXC5A6v9k3tta05rC2y/rRN+iEk=;
        b=cnbj3VHRo3UrsAINFd18GKg4MKPsmy+i54ye5lWL22RVq44JDt3nxhRI2UDHj66oy2
         jQtwzPfY8XnXQitAbNIaWZwig8pFCDWtBgaFRK2om0XOEeK0KWYKDK/xoYdfdOXUe7IY
         9C7ol/F+RHoku5H7wm8KdqwYDhf3r8UDZSSxxPVmlv3sFD+0/z5go0HudIOH52qi9uwl
         39aLmcaP93Mr7NCd27VR6QdoaXbSoGeOVXjQ2rnbi2QzQmRzxxqMNOW+D4W3+ozeddpr
         tzeflF3cVMVfI/f3Lwypky1RC1njVUp37jfaAUhgAzx7OGX2vQbyt0tnetAu1nX9ighp
         Ablw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747925952; x=1748530752;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=pM2cuzmldAVHXAvYRXC5A6v9k3tta05rC2y/rRN+iEk=;
        b=oySsl2RquUgbjs2GaJNF+hWmRCFmKIn6H0BLMPoWf1KQRaBmJjtTka3ZeMAE/JsVUC
         FpQlI3bPg2/5t/U/zM+YOoytCkE/KiBtH9dsFMiFpcEGfao+la6eN2Wim+u5Jrdns5XQ
         xZrpedsE95Lap68+Nha7PmaOmPxDTLkeBwuioswst5Ea1oFRU5pPv0QGe7VaXSPetiSx
         ulI/BT1xaG555ZcCEDR1wOlAQHmG8p7OvA6aIL0oVTM8YkzQVSBEevT2GcrCqCo51qZU
         knBG2OEsuovIBjbUYPoquhrt9CGWAd0Z1kdcLFQ5hndVyL7Q2AfUp+A76bvnFi8OR3AP
         T/bQ==
X-Forwarded-Encrypted: i=1; AJvYcCW3UPOIvrhxXge5gZWZ+Tbqb4j/WlnQdvfutifcN6mqQD/aMoJ9mK40noejUUTeod3GiE5ntSg9sVw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+xgSgGjuxiRcEsiHV0vcVCcSb/WaN6g9n7jHrfvaB7hk8kNKD
	iskgIJJL90Yhr9XQblKG/+Ye/7YosvhwlYLZQdzwkIPhNH4JbAc4VbDUVPs90dJAKg==
X-Gm-Gg: ASbGnctiDSYtUaeJRgsKDTDt6jSQAiBjn+n59hTW1UMtDS171uTwW8bdI/nwC4yUGbz
	+KTn1mqINo1NndjsN6rSIPvkMetyKrEN4+j2kcZbaZ8pH01HzSe9PuJrr8rE+/RymY6Ra+55HsB
	Af/i/Fm+30RRVaHdeqjnODqVQJ4gHfBD22Es+mzLLCgZAx6rlAptLNMYRKsSRaQIw5G5lKK18lp
	2Ie8X7LMALhQSY21OOeCT4N0QIRmkS5ipmBAwpX1fUxZSo3epSX2FL1Dvxptzpmstz2/ue2AInT
	Ybc78lmekuuFS0QGbnHaOA8DT8ZCkQ==
X-Google-Smtp-Source: AGHT+IHFNg77pH5AaRO6DiDTSLdXnu7sDoV6wxxiYB+cOjO+uenCJXJoFaLAR1E9q5BniHoNb7dF2A==
X-Received: by 2002:a05:6402:2816:b0:5ff:83db:96cd with SMTP id 4fb4d7f45d1cf-600900f5268mr22868424a12.18.1747925951654;
        Thu, 22 May 2025 07:59:11 -0700 (PDT)
Message-ID: <3f274948-92bb-40c4-bcaf-7b538300140a@suse.com>
Date: Thu, 22 May 2025 16:59:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/vpci: refuse to map BARs at position 0
To: Roger Pau Monne 
Cc: Andrew Cooper , xen-devel@lists.xenproject.org
References: <20250522140356.5653-1-roger.pau@citrix.com>
 <20250522140356.5653-3-roger.pau@citrix.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <20250522140356.5653-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 22.05.2025 16:03, Roger Pau Monne wrote:
> A BAR at position 0 is not initialized (not positioned).  While Xen could
> attempt to map it into the p2m, marking it as mapped will prevent dom0 to
> change the position of the BAR,

With memory decoding enabled, that is?

> as the vPCI code has a shortcomming of not
> allowing to write to BAR registers while the BAR is mapped on the p2m.

Again only under that extra condition, aiui.

> Workaround this limitation by returning false from pci_check_bar() if the
> BAR address is 0, thus causing the bar->enabled field to also be set to
> false and allowing bar_write() to change the BAR position.
> 
> Signed-off-by: Roger Pau Monné 
> ---
>  xen/arch/x86/pci.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
> index 26bb7f6a3c3a..39fd5a16a4aa 100644
> --- a/xen/arch/x86/pci.c
> +++ b/xen/arch/x86/pci.c
> @@ -101,6 +101,15 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
>  
>  bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
>  {
> +    /*
> +     * Refuse to map BARs at position 0, those are not initialized.  This might
> +     * be required by Linux, that can reposition BARs with memory decoding
> +     * enabled.  By returning false here bar->enabled will be set to false, and
> +     * bar_write() will work as expected.
> +     */
> +    if ( mfn_eq(start, _mfn(0)) )
> +        return false;

Is this really x86-specific?

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 15:00:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:00:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994167.1377208 (Exim 4.92)
	(envelope-from )
	id 1uI7PE-0003t9-Ea; Thu, 22 May 2025 15:00:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994167.1377208; Thu, 22 May 2025 15: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 1uI7PE-0003rz-BN; Thu, 22 May 2025 15:00:24 +0000
Received: by outflank-mailman (input) for mailman id 994167;
 Thu, 22 May 2025 15:00:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7PC-0003kR-H3
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:00:22 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7ba248ee-371d-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 17:00:21 +0200 (CEST)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5f3f04b5dbcso12271962a12.1
 for ; Thu, 22 May 2025 08:00:21 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac32a7fsm10550119a12.56.2025.05.22.08.00.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 08:00: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" 
X-Inumbo-ID: 7ba248ee-371d-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747926021; x=1748530821; 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;
        bh=ljRP4y1r3tEpwonUwcR95PojX/tUgMS8XUn01iePeGU=;
        b=qFzqVxcz/TBe1GR0f3imECCEGXt8ucop/9QAXy1s60al7tItVAoL8eXEBwrhXr4SGZ
         i1QzKF661PYgswjsyEzI2vv2RBPO57qGlXtnSs+RhuQy1tDqyavAPv0uWbg3BrGhzBmN
         f5jvKbr1DWcFFzjEH/umAiBtPqjnhjm+uWdak=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747926021; x=1748530821;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ljRP4y1r3tEpwonUwcR95PojX/tUgMS8XUn01iePeGU=;
        b=GKaGDYVktCkEf8jdvHXTg7629u2pNDIUaaRBxBFJoMllo2zVyJz8qwmRUkR+BWBk57
         1fLGDdS7VYruKDTDJNTdbOoRLsFw9CgG8QEqWVV4jqNPkd8mrGv/9kUjs7E7VWSVvWeO
         oPkISRULr6iFJkFKb0+gdGq2grOqxPRRf4xHcla+gNIANexmNGBM2d/ygYayKzPcA3Rf
         eHCITLMTuDbb+PBfGbvM3dG3q6+g85hG81dRPluaWKn5XLYIicUkmIykRGSyiLrf/sCF
         5V6c9tEJhyJgZHxXRuOH+Ioi7wfdvrQI8jTAkjbfbFW7n8MHZrjKiQik+qqQ0LPcrvFb
         QvgQ==
X-Gm-Message-State: AOJu0YwTpESXE5v72dT7f0Pa/ogufRk3H9/0B9I4sTWUfXWjsiDn/rg7
	vL/FWZRgArjkp1dXQRLCQbJAx86vzlX+mZBKo5IuzIWMY/dshTQTsa4HUVkUdQmBZFSASDs11hT
	8jCHa
X-Gm-Gg: ASbGncs6T/wECEm+yFtc/w7lb0kMZ2lYugVcx+4PeitvIkWv4UZHLLYzMgo5cFoVb+N
	jJzLfrHvTn0Syx18RWs7miX8O2WuhEj+umFmmUpb00A3Yfp8+pCHFlQlFLvtey50xsZtHe3t37A
	zPBiyWkKDZGm9tvz+QmlWFS/DkuVsQQVbye9OlmulcPWteXkSO1IF+QE2wbphqn2IE6FNRQyLAX
	HCD0dSbKXMFUwouiwSNoh+eibIBOxWVaUpvbdFLaptfEdDQqwKDEvI453Jeejdydo0NEb4VtGy+
	/xu5F83T62qVXYNu8gVjnFXOJkuH9HjY7AoW9b+XSu56gU8WO7XWkwuqPG+kZn9vNubbxUJYCwp
	Z4USqRsS35D6vwko/npp3ovU7
X-Google-Smtp-Source: AGHT+IEmxj6rPzsElnxUfYxYT7ERgKr+r2Hy5iHlkty1zrydVqmvddsQiDbNWydC/aVOLZzOLCtaxQ==
X-Received: by 2002:a05:6402:358f:b0:602:2d06:6b19 with SMTP id 4fb4d7f45d1cf-6022d066f47mr6642878a12.1.1747926020894;
        Thu, 22 May 2025 08:00:20 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 1/3] x86/alternatives: Factor out access to ideal_nops[]
Date: Thu, 22 May 2025 16:00:13 +0100
Message-Id: <20250522150015.555492-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250522150015.555492-1-andrew.cooper3@citrix.com>
References: <20250522150015.555492-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

... in order to rework the calculation.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/alternative.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index ecc56964bd9c..cc2d0c89aca3 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -86,6 +86,11 @@ static bool init_or_livepatch_read_mostly toolchain_nops_are_ideal;
 # define toolchain_nops_are_ideal false
 #endif
 
+static const unsigned char *get_ideal_nops(unsigned int noplen)
+{
+    return ideal_nops[noplen];
+}
+
 static void __init arch_init_ideal_nops(void)
 {
     switch ( boot_cpu_data.x86_vendor )
@@ -116,7 +121,7 @@ static void __init arch_init_ideal_nops(void)
     }
 
 #ifdef HAVE_AS_NOPS_DIRECTIVE
-    if ( memcmp(ideal_nops[ASM_NOP_MAX], toolchain_nops, ASM_NOP_MAX) == 0 )
+    if ( memcmp(get_ideal_nops(ASM_NOP_MAX), toolchain_nops, ASM_NOP_MAX) == 0 )
         toolchain_nops_are_ideal = true;
 #endif
 }
@@ -127,9 +132,11 @@ void init_or_livepatch add_nops(void *insns, unsigned int len)
     while ( len > 0 )
     {
         unsigned int noplen = len;
+
         if ( noplen > ASM_NOP_MAX )
             noplen = ASM_NOP_MAX;
-        memcpy(insns, ideal_nops[noplen], noplen);
+
+        memcpy(insns, get_ideal_nops(noplen), noplen);
         insns += noplen;
         len -= noplen;
     }
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:00:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:00:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994166.1377205 (Exim 4.92)
	(envelope-from )
	id 1uI7PE-0003r0-98; Thu, 22 May 2025 15:00:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994166.1377205; Thu, 22 May 2025 15: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 1uI7PE-0003qt-5B; Thu, 22 May 2025 15:00:24 +0000
Received: by outflank-mailman (input) for mailman id 994166;
 Thu, 22 May 2025 15:00:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7PC-0003qi-Da
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:00:22 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7b04efd6-371d-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:00:20 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5f3f04b5dbcso12271921a12.1
 for ; Thu, 22 May 2025 08:00:20 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac32a7fsm10550119a12.56.2025.05.22.08.00.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 08:00:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7b04efd6-371d-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747926020; x=1748530820; 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;
        bh=D0Qeom5nlma+YCwLHQnK5pcO1J4EMkRMoGec4Oh/qEI=;
        b=IDtsAq7DsVKMiDfSk20EItQ/1FTyQB/ff4/xU9kyS1yYDaUWdMw1vRL5cQOiPCZQYF
         Bwy9LRFyGZ7zuZ2AF7uArQ9eEk9P8hIZwfh8jVqmiLtYh161VR3p3axyOajbc1FyJn0N
         g8iQmchIwm06UIMsaBbhBmjbe5LvG5hZ3mNWQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747926020; x=1748530820;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=D0Qeom5nlma+YCwLHQnK5pcO1J4EMkRMoGec4Oh/qEI=;
        b=XndDymleJNtS8zerp12+hXVBRu5XcZTB00zlV84SBQClKAqqEzjPmqOydlVoSAQeVJ
         Cuuum4dweTTpDv9CIk105fsJXQY0tXLgY6VgKDEG8XewDSHATB5+6H6xf3//4tHgRUU+
         Y7I2TXpW4k+dSvcwfAFRr8JmEdv26Y9iFx96Yjm2LRYgSfQ8Xh6mChu6koESYvKqWJFe
         fk5fa5KHOWaEbfIgf1zF0J2pabx/ed3bvwM2RFDfMqCEh2mRM71Ml93MtJq0OdhwBJ9X
         Z8YcX1lXR00UcWtz7UVjaso/LGXQgr7Lntjh56OnOOaVM+07qiMCLKlakdsLpMbPSEHV
         X9jg==
X-Gm-Message-State: AOJu0Yz1bUMP5y9QPrBNASs94oJybK1UclH90rhpGY17XGHDSA6XsSDx
	MFMtMXKEDSaGMbUcP/sHT+eCqAhnBDy3hBP3SLBGsnnWSEm5Z8mHIAJb62mmmRVVjt90lRDJLCQ
	KtUhm
X-Gm-Gg: ASbGncsbU85DiMR2vnbSNLaAw4gqzoukgCDTc42+1gB6sL7pKlx3meUt3hup2fiRGi2
	Ach93BHQwvXr3xriRVXQwvfvFoQnYQp2lBi1bGpZK9gqA3zSlngbyZN8UT+hU1QA4S6W9Roz4Hx
	2r7AhvFn3dtL3+8K884Vo+RylVi71k473yoXW7i3esMdIdf+BWcKzEqfWNYJGJ0eOVkravDVKdh
	GhNbaYSablkGgcFTBGvXXrg2ZcrS0Xvb9RSLNOoGAD+ZfvDwqyPF3o/ka69ckQuja2yiVQ1RkMs
	LrAik2k8l3KSHNqPqVWe1m9JCcAJIl7WzbPpBhl25/OqMsyxXkVzoNBLhYBZkUpzBsMRdoogV0P
	nctL65TUTfVU45JI06b7ZkevVkUO+KILcA5A=
X-Google-Smtp-Source: AGHT+IHWxTt4kKSid9W4YOdJaCq5uMBKesGFCWk88T29a4kl+xZwY6yK6pjLYH9aum7n2WSAfxNSMQ==
X-Received: by 2002:a05:6402:254a:b0:601:9aeb:3d9 with SMTP id 4fb4d7f45d1cf-6019aeb05f4mr18783040a12.20.1747926019821;
        Thu, 22 May 2025 08:00:19 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 0/3] x86/alt: Simplify nops handling
Date: Thu, 22 May 2025 16:00:12 +0100
Message-Id: <20250522150015.555492-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

Mostly patch 2, with tidyup either side

Andrew Cooper (3):
  x86/alternatives: Factor out access to ideal_nops[]
  x86/alternatives: Rework get_ideal_nops()
  x86/alternatives: Introduce init_or_livepatch_ro_after_init

 xen/arch/x86/alternative.c  | 51 +++++++++++++++----------------------
 xen/include/xen/livepatch.h |  2 ++
 2 files changed, 23 insertions(+), 30 deletions(-)


base-commit: 1f75bd375d0757d6646ca2029a9559d535f6b511
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:00:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:00:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994168.1377225 (Exim 4.92)
	(envelope-from )
	id 1uI7PF-0004IV-OO; Thu, 22 May 2025 15:00:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994168.1377225; Thu, 22 May 2025 15: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 1uI7PF-0004H5-KD; Thu, 22 May 2025 15:00:25 +0000
Received: by outflank-mailman (input) for mailman id 994168;
 Thu, 22 May 2025 15:00:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7PE-0003qi-A4
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:00:24 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7c4769fb-371d-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:00:22 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-601a6e2e93cso1078856a12.1
 for ; Thu, 22 May 2025 08:00:22 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac32a7fsm10550119a12.56.2025.05.22.08.00.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 08:00: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" 
X-Inumbo-ID: 7c4769fb-371d-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747926022; x=1748530822; 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;
        bh=3Ul/tNZRZ1TlH45ain/OMZmy2A/UotZfS6GWeE2NRSQ=;
        b=qy2JAXsno9K7JStIq8vmmLp9fL6Yrq8IJSeSjDLqSt4wjW1gWm6oTmW5SxCuj/jyrH
         O7FN1N7pXdf/lGsdBzdn+yHVYe+658tL+yjM9qXQ6iAySeo6PpVJZMYvP9GdjKCyUbsG
         eyw0DLeo6cEJTPsVcHIpHfDquxtOOHPB/xsuU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747926022; x=1748530822;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=3Ul/tNZRZ1TlH45ain/OMZmy2A/UotZfS6GWeE2NRSQ=;
        b=Ohb2G6bDafR2nqpzwdHrjabZ06OFdHBi2wEv4VH4bmCnS8NKvN6Ya9zalEfHBtbIeG
         a5DlxC1zAK+K+QRB8hON2MDWu9cTecveIhR/FRs3awVCGiwSjdjRmlUrKHu2a0xbJUz9
         75ZzUsLynP4PLHEVCCDmZm0AKQ4OxeKj/9Jf1GsQCwVikvxKBYvd6/GU3YOcRJ+Tpe7P
         UhYt1GmCHXf4ec+RB6cPVoeY/hyUBAYlgy/cMStOAcVV6qdLcwvfHivrqA4G/TPhhX76
         0hrfl/e6Mki2U9n5DFuPKVnVQaOFsJ4euXgQZlNtwKTUsDO6zb2r5i++VL/PGtCf3HKP
         o+YQ==
X-Gm-Message-State: AOJu0Yz2P0ZCxmRThUyMDjIB1fIorKSO3CHVvgN7oN7FRsBCiPcYubYM
	WdQsqyUoyvFK0siepVp3e88KMMBuk/AeM8j3i7pz5xQtvRZhsfbtg26FTTaX97oLMjOJ4A3ua/0
	F/Zb6
X-Gm-Gg: ASbGncuD/3BlD4r/EIYAsLT/J0xEteYsdn5gs7xo/2cYTmW3ZBo0I+917ZjQvbAgZLB
	LVF3VucMK4VbQeJ4Kt4A5xBA7CfuN1+uJION92WJ8+1RoUNKvLGlaR0U5WBQJtZ9tauLvQ+dKkQ
	X/EV5WMKG69HpIXlFhOKEP/IxH9kf5JdQ5uY+z7Cae1BhsN9ftFJYzINAn/pexEymAU9iM3nEDj
	WvMaknhE6HcQqCBmvtnEqlKNAC1LjsLB5cZrsX9UHNyXmXaUPjseWdyxHnZIFryafqr/7XrFeWG
	zIdcKiflCssQuaYetB3A3p91AfQ8kH4gTphrI+lczX/4PwTtKdgZh3H7/yZ8ped4/ya0PxRPSMO
	GFSpuBLzYeSrXvlYcWnkt2V3aZgsQFyAwlxo=
X-Google-Smtp-Source: AGHT+IFASlcGlaKb1Z2UunBUZ54ibZHHQNVikl7rpE8jSvm4IynpdunZ+amUYf3dZh7NQwzlRJx06g==
X-Received: by 2002:a05:6402:2105:b0:602:d98:5d83 with SMTP id 4fb4d7f45d1cf-6020d9860bamr9635108a12.5.1747926021934;
        Thu, 22 May 2025 08:00:21 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 2/3] x86/alternatives: Rework get_ideal_nops()
Date: Thu, 22 May 2025 16:00:14 +0100
Message-Id: <20250522150015.555492-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250522150015.555492-1-andrew.cooper3@citrix.com>
References: <20250522150015.555492-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The {k8,p6}_nops[] arrays are both 80-byte structures indexing 45-byte
structures.  Furthermore, perhaps unusually for C, the source layout is an
obvious hint about the trangular nature of the structure.

Therefore, we can replace the pointer chase with some simple arithmatic.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

The implemenation of get_ideal_nops() changes from:

    mov    0x19bc41(%rip),%rax        # 
    mov    %edi,%edi
    mov    (%rax,%rdi,8),%rax
    jmp    <__x86_return_thunk>

to:

    lea    -0x1(%rdi),%eax
    imul   %edi,%eax
    shr    %eax
    add    0x67fc1(%rip),%rax        # 
    jmp    <__x86_return_thunk>

The imul has a latency of 3 cycles on all CPUs back to the K8 and Nehalem.
It's better than an extra deference on all CPUs, even the older ones.
---
 xen/arch/x86/alternative.c | 40 ++++++++++++--------------------------
 1 file changed, 12 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index cc2d0c89aca3..ff7d83c0ddbd 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -20,7 +20,7 @@
 #define MAX_PATCH_LEN (255-1)
 
 #ifdef K8_NOP1
-static const unsigned char k8nops[] init_or_livepatch_const = {
+static const unsigned char k8_nops[] init_or_livepatch_const = {
     K8_NOP1,
     K8_NOP2,
     K8_NOP3,
@@ -31,22 +31,10 @@ static const unsigned char k8nops[] init_or_livepatch_const = {
     K8_NOP8,
     K8_NOP9,
 };
-static const unsigned char * const k8_nops[ASM_NOP_MAX+1] init_or_livepatch_constrel = {
-    NULL,
-    k8nops,
-    k8nops + 1,
-    k8nops + 1 + 2,
-    k8nops + 1 + 2 + 3,
-    k8nops + 1 + 2 + 3 + 4,
-    k8nops + 1 + 2 + 3 + 4 + 5,
-    k8nops + 1 + 2 + 3 + 4 + 5 + 6,
-    k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7,
-    k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8,
-};
 #endif
 
 #ifdef P6_NOP1
-static const unsigned char p6nops[] init_or_livepatch_const = {
+static const unsigned char p6_nops[] init_or_livepatch_const = {
     P6_NOP1,
     P6_NOP2,
     P6_NOP3,
@@ -57,21 +45,9 @@ static const unsigned char p6nops[] init_or_livepatch_const = {
     P6_NOP8,
     P6_NOP9,
 };
-static const unsigned char * const p6_nops[ASM_NOP_MAX+1] init_or_livepatch_constrel = {
-    NULL,
-    p6nops,
-    p6nops + 1,
-    p6nops + 1 + 2,
-    p6nops + 1 + 2 + 3,
-    p6nops + 1 + 2 + 3 + 4,
-    p6nops + 1 + 2 + 3 + 4 + 5,
-    p6nops + 1 + 2 + 3 + 4 + 5 + 6,
-    p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7,
-    p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8,
-};
 #endif
 
-static const unsigned char * const *ideal_nops init_or_livepatch_data = p6_nops;
+static const unsigned char *ideal_nops init_or_livepatch_data = p6_nops;
 
 #ifdef HAVE_AS_NOPS_DIRECTIVE
 
@@ -86,9 +62,17 @@ static bool init_or_livepatch_read_mostly toolchain_nops_are_ideal;
 # define toolchain_nops_are_ideal false
 #endif
 
+/*
+ * Both k8_nops[] and p6_nops[] are flattened triangular data structures,
+ * making the offsets easy to calculate.
+ *
+ * To get the start of NOP $N, we want to calculate T($N - 1)
+ */
 static const unsigned char *get_ideal_nops(unsigned int noplen)
 {
-    return ideal_nops[noplen];
+    unsigned int offset = ((noplen - 1) * noplen) / 2;
+
+    return &ideal_nops[offset];
 }
 
 static void __init arch_init_ideal_nops(void)
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:00:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:00:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994169.1377230 (Exim 4.92)
	(envelope-from )
	id 1uI7PG-0004Kg-0O; Thu, 22 May 2025 15:00:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994169.1377230; Thu, 22 May 2025 15: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 1uI7PF-0004KC-RT; Thu, 22 May 2025 15:00:25 +0000
Received: by outflank-mailman (input) for mailman id 994169;
 Thu, 22 May 2025 15:00:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7PE-0003kR-B6
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:00:24 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7cf75ed1-371d-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 17:00:24 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-601f278369bso9150926a12.1
 for ; Thu, 22 May 2025 08:00:24 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac32a7fsm10550119a12.56.2025.05.22.08.00.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 08:00:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7cf75ed1-371d-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747926023; x=1748530823; 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;
        bh=Lr3f4QVXBQIDCvAtm/J7FXqG+fuDtkqVk40mCLaFjM8=;
        b=rXjMiK9JnMJRdG4PnhsWg2h4PlT+CAz96h165SNajgQoZNEin7atLn6c/iWpVjpTsi
         Wv962se85Z+3GjDberiNeUkE9LoYBJ0BaeE+yyUCjs6hBH5luQ9SMJEwqsC/BRkTzvsg
         k5Z6enxHV6YgqDl9Dtuaqyx6GAMtJtQETr04k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747926023; x=1748530823;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Lr3f4QVXBQIDCvAtm/J7FXqG+fuDtkqVk40mCLaFjM8=;
        b=IAflsfANmTnaLivvIBKFLpXUjWqcqIAnmWoeYOB8daT0wpnxO+1DlA/s7nHyY6z3+f
         9Hj5ctAlqJla8CPY04sC4B9Bj4iKfy/ejr+csO+mukAn5+MFN89pacWs/qoUrcei9UoC
         hgRIsl2f3vU4A35JNtpD4OGtcqffB9RT01YzjqUj7PoG8dZVZ85s6+/zPsuTiTgFZYRu
         Q/J0c+Ox+5LySfZDSI9YrnEvGTHmRDj2RmV0RdzYUik9LxPRQY6SoCbDMXe5NkoExNli
         nXRRV7X6Vtwv3+TSnivLSRP69AY3NAwSpkKzit+Q5KvWV9sf0oS04cFYIc7DKd2BQSVm
         q1vw==
X-Gm-Message-State: AOJu0YwGuMX2wPBcgZrIhwkWrOW5V9hJd5D/UkFUy6tMEnH3/BBbc4cI
	0HmLKUxmECNToJaKG2weg+DgcePIj+xMYbvxreIa/gG3jd+m2q9ELEF3GhBMaZhO/4XJ3E6vgiZ
	ABEgs
X-Gm-Gg: ASbGncuclKk9nRqynWHj8RCsTd+nvINalFWzDkYTgd+f9XYVsrLYzhwA5unCTP0bURh
	V3r/p3lfZ8fK/z/Q5hdx55HD41eF8c671Eu0aDSqpqfbHeYM1rcOQc1x6q3fOkwBDkBwoRkK4fC
	pHHFXG6RapxSW369miThBx7OWFQ6rU66fPM78A3bfRfX16qo8nMaPjZ+Zit1GCRNYBlDnRXA85P
	qxWKLez+VlWtxPlX71n/008Q61hpKxh86NxTGksfYzO8fQ/dUkXL2IlCSS4i72j6rVxFDaJZdsm
	zOA6bxFRz+rcmjXjjORP3bY8Z+7WHKtr9T/7TVl2uKLCmrnIm68JIuu9oBuCsd1F8MubbxOwzXZ
	V5vpVaqg6eemavYXw1cthqX+l
X-Google-Smtp-Source: AGHT+IGwN3+4ZGB1CCik2Dp+hZVMQfvh8ozffLpfJ+B7Xqh8901rhiCpfdZYsF8r17CSvH0+QTy0rw==
X-Received: by 2002:a05:6402:50cc:b0:601:9dc3:2795 with SMTP id 4fb4d7f45d1cf-6019dc32e17mr18470941a12.7.1747926023055;
        Thu, 22 May 2025 08:00:23 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 3/3] x86/alternatives: Introduce init_or_livepatch_ro_after_init
Date: Thu, 22 May 2025 16:00:15 +0100
Message-Id: <20250522150015.555492-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250522150015.555492-1-andrew.cooper3@citrix.com>
References: <20250522150015.555492-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

... and use it for ideal_nops and toolchain_nops_are_ideal; both of which are
invariant after arch_init_ideal_nops() has run.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/alternative.c  | 4 ++--
 xen/include/xen/livepatch.h | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index ff7d83c0ddbd..058a8b22d41f 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -47,7 +47,7 @@ static const unsigned char p6_nops[] init_or_livepatch_const = {
 };
 #endif
 
-static const unsigned char *ideal_nops init_or_livepatch_data = p6_nops;
+static const unsigned char *ideal_nops init_or_livepatch_ro_after_init = p6_nops;
 
 #ifdef HAVE_AS_NOPS_DIRECTIVE
 
@@ -56,7 +56,7 @@ asm ( ".pushsection .init.rodata, \"a\", @progbits\n\t"
       "toolchain_nops: .nops " __stringify(ASM_NOP_MAX) "\n\t"
       ".popsection\n\t");
 extern char toolchain_nops[ASM_NOP_MAX];
-static bool init_or_livepatch_read_mostly toolchain_nops_are_ideal;
+static bool init_or_livepatch_ro_after_init toolchain_nops_are_ideal;
 
 #else
 # define toolchain_nops_are_ideal false
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index d074a5bebecc..62f8db2b55b4 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -29,6 +29,7 @@ struct xen_sysctl_livepatch_op;
 #define init_or_livepatch_constrel
 #define init_or_livepatch_data
 #define init_or_livepatch_read_mostly __read_mostly
+#define init_or_livepatch_ro_after_init __ro_after_init
 #define init_or_livepatch
 
 /* Convenience define for printk. */
@@ -153,6 +154,7 @@ void revert_payload_tail(struct payload *data);
 #define init_or_livepatch_constrel    __initconstrel
 #define init_or_livepatch_data        __initdata
 #define init_or_livepatch_read_mostly __initdata
+#define init_or_livepatch_ro_after_init __initdata
 #define init_or_livepatch             __init
 
 static inline int livepatch_op(struct xen_sysctl_livepatch_op *op)
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:08:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:08:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994202.1377244 (Exim 4.92)
	(envelope-from )
	id 1uI7X7-0006dm-Pi; Thu, 22 May 2025 15:08:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994202.1377244; Thu, 22 May 2025 15: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 1uI7X7-0006df-N5; Thu, 22 May 2025 15:08:33 +0000
Received: by outflank-mailman (input) for mailman id 994202;
 Thu, 22 May 2025 15:08:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7X6-0006dU-L4
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:08:32 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 9eb9640d-371e-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:08:30 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3CDFB1A2D;
 Thu, 22 May 2025 08:08:15 -0700 (PDT)
Received: from C3HXLD123V.arm.com (unknown [10.57.50.224])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 840413F673;
 Thu, 22 May 2025 08:08:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9eb9640d-371e-11f0-b892-0df219b8e170
From: Bertrand Marquis 
To: xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Volodymyr Babchuk 
Subject: [PATCH v6 0/6] FF-A VM to VM support
Date: Thu, 22 May 2025 17:08:01 +0200
Message-ID: 
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch serie adds support to use FF-A between VM for communications
using indirect messages.

It adds a Kconfig parameter to enable this feature and marks it as
experimental as for now there is no system to restrict communication
rights between VM using this system.

It also adds support to use VM to VM communications using FF-A even if
there is no firmware support for FF-A. As this feature enables FF-A
support in all cases, we also introduce a new command line parameter to
allow the user to force which tee is to be used between FF-A and Optee
to have a solution to enable optee support if FF-A VM to VM is enabled.

Changes since v5:
- coding style fixes
- rework version negociation to use the context lock
- split probe into fw and vm to vm probe to make code clearer
- add some R-b from Jens

Changes since v4:
- fix typos and optimize command line parameter
- split VM to VM support in 2 patches to ease review
- organize ffa contexts in a chain list to be able to build the partinfo
  result without taking the global domain lock
- introduce a maximum number of SPs to prevent holding the CPU for too
  long during partinfo call
- use an atomic to store the number of FF-A VMs
- prevent potential overflows in indirect message handling
- fix copy bug in indirect message introduced in v4

Changes since v3:
- reintroduce firmare v1.0 support in partinfo
- fix a possible TOC/TOU issue in indirect message handling
- typos and small fixes

Changes since v2:
- Rework partition_info_get implementation
- Taint Xen and display a message when VM to VM is enabled
- Various fixes explained in each patch

Changes since v1 (rfc):
- add a tee command line parameter
- use IS_ENABLED instead of ifdef when possible
- rebase on latest staging


Bertrand Marquis (6):
  xen/arm: Create tee command line parameter
  xen/arm: ffa: Rework partinfo_get implementation
  xen/arm: ffa: Introduce VM to VM support
  xen/arm: ffa: Add buffer full notification support
  xen/arm: ffa: Add indirect message between VM
  xen/arm: ffa: Enable VM to VM without firmware

 docs/misc/xen-command-line.pandoc  |  14 ++
 xen/arch/arm/include/asm/tee/tee.h |   4 +
 xen/arch/arm/tee/Kconfig           |  11 ++
 xen/arch/arm/tee/ffa.c             | 115 +++++++++---
 xen/arch/arm/tee/ffa_msg.c         | 117 ++++++++++--
 xen/arch/arm/tee/ffa_notif.c       | 140 +++++++-------
 xen/arch/arm/tee/ffa_partinfo.c    | 286 ++++++++++++++++++++---------
 xen/arch/arm/tee/ffa_private.h     | 157 +++++++++++++---
 xen/arch/arm/tee/tee.c             |  32 ++++
 9 files changed, 660 insertions(+), 216 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:08:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:08:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994204.1377265 (Exim 4.92)
	(envelope-from )
	id 1uI7XD-00076P-6R; Thu, 22 May 2025 15:08:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994204.1377265; Thu, 22 May 2025 15: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 1uI7XD-00076I-32; Thu, 22 May 2025 15:08:39 +0000
Received: by outflank-mailman (input) for mailman id 994204;
 Thu, 22 May 2025 15:08:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7XC-0006dU-6A
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:08:38 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id a272a7ce-371e-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:08:36 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 81D161A32;
 Thu, 22 May 2025 08:08:21 -0700 (PDT)
Received: from C3HXLD123V.arm.com (unknown [10.57.50.224])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7EE623F673;
 Thu, 22 May 2025 08:08: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" 
X-Inumbo-ID: a272a7ce-371e-11f0-b892-0df219b8e170
From: Bertrand Marquis 
To: xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Michal Orzel 
Subject: [PATCH v6 2/6] xen/arm: ffa: Rework partinfo_get implementation
Date: Thu, 22 May 2025 17:08:03 +0200
Message-ID: 
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch is in preparation for VM to VM support in order to do the
changes on the SP handling part of partinfo_get before adding support
for the VM part.

This patches is doing the following changes:
- split partinfo_get into 3 functions to have the locking handling and
  proper exit on error handled more clearly
- add some potential overflow checks to validate the offset and sizes
  passed by the VM on partinfo call.
- Introduce a maximum number of SPs (for now set to 64) to prevent
  holding the CPU for too long in case there would be a lot of
  partitions in the secure world. The limit currently set is thought to
  be realistic for most use cases as 64 secure partitions is a very high
  number compared to current seen usage (more 3 or 4).
- fix include ordering in ffa_private.h to be in alphabetic order

Signed-off-by: Bertrand Marquis 
Reviewed-by: Jens Wiklander 
---
Changes in v6:
- add missing empty line before ffa_handle_partition_info_get
- add Jens R-b
Changes in v5:
- patch added
---
 xen/arch/arm/tee/ffa_partinfo.c | 202 +++++++++++++++++++-------------
 xen/arch/arm/tee/ffa_private.h  |  18 ++-
 2 files changed, 132 insertions(+), 88 deletions(-)

diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_partinfo.c
index c0510ceb8338..dfa0b23eaf38 100644
--- a/xen/arch/arm/tee/ffa_partinfo.c
+++ b/xen/arch/arm/tee/ffa_partinfo.c
@@ -63,9 +63,96 @@ static int32_t ffa_partition_info_get(uint32_t *uuid, uint32_t flags,
     return ret;
 }
 
-void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
+static int32_t ffa_get_sp_count(uint32_t *uuid, uint32_t *sp_count)
+{
+    uint32_t src_size;
+
+    return ffa_partition_info_get(uuid, FFA_PARTITION_INFO_GET_COUNT_FLAG,
+                                  sp_count, &src_size);
+}
+
+static int32_t ffa_get_sp_partinfo(uint32_t *uuid, uint32_t *sp_count,
+                                   void *dst_buf, void *end_buf,
+                                   uint32_t dst_size)
 {
     int32_t ret;
+    uint32_t src_size, real_sp_count;
+    void *src_buf = ffa_rx;
+    uint32_t count = 0;
+
+    /* Do we have a RX buffer with the SPMC */
+    if ( !ffa_rx )
+        return FFA_RET_DENIED;
+
+    /* We need to use the RX buffer to receive the list */
+    spin_lock(&ffa_rx_buffer_lock);
+
+    ret = ffa_partition_info_get(uuid, 0, &real_sp_count, &src_size);
+    if ( ret )
+        goto out;
+
+    /* We now own the RX buffer */
+
+    /* Validate the src_size we got */
+    if ( src_size < sizeof(struct ffa_partition_info_1_0) ||
+         src_size >= FFA_PAGE_SIZE )
+    {
+        ret = FFA_RET_NOT_SUPPORTED;
+        goto out_release;
+    }
+
+    /*
+     * Limit the maximum time we hold the CPU by limiting the number of SPs.
+     * We just ignore the extra ones as this is tested during init in
+     * ffa_partinfo_init so the only possible reason is SP have been added
+     * since boot.
+     */
+    if ( real_sp_count > FFA_MAX_NUM_SP )
+        real_sp_count = FFA_MAX_NUM_SP;
+
+    /* Make sure the data fits in our buffer */
+    if ( real_sp_count > (FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE) / src_size )
+    {
+        ret = FFA_RET_NOT_SUPPORTED;
+        goto out_release;
+    }
+
+    for ( uint32_t sp_num = 0; sp_num < real_sp_count; sp_num++ )
+    {
+        struct ffa_partition_info_1_1 *fpi = src_buf;
+
+        /* filter out SP not following bit 15 convention if any */
+        if ( FFA_ID_IS_SECURE(fpi->id) )
+        {
+            if ( dst_buf > (end_buf - dst_size) )
+            {
+                ret = FFA_RET_NO_MEMORY;
+                goto out_release;
+            }
+
+            memcpy(dst_buf, src_buf, MIN(src_size, dst_size));
+            if ( dst_size > src_size )
+                memset(dst_buf + src_size, 0, dst_size - src_size);
+
+            dst_buf += dst_size;
+            count++;
+        }
+
+        src_buf += src_size;
+    }
+
+    *sp_count = count;
+
+out_release:
+    ffa_hyp_rx_release();
+out:
+    spin_unlock(&ffa_rx_buffer_lock);
+    return ret;
+}
+
+void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
+{
+    int32_t ret = FFA_RET_OK;
     struct domain *d = current->domain;
     struct ffa_ctx *ctx = d->arch.tee;
     uint32_t flags = get_user_reg(regs, 5);
@@ -75,8 +162,8 @@ void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
         get_user_reg(regs, 3),
         get_user_reg(regs, 4),
     };
-    uint32_t src_size, dst_size;
-    void *dst_buf;
+    uint32_t dst_size = 0;
+    void *dst_buf, *end_buf;
     uint32_t ffa_sp_count = 0;
 
     /*
@@ -89,31 +176,26 @@ void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
     else
         dst_size = sizeof(struct ffa_partition_info_1_1);
 
-    /*
-     * FF-A v1.0 has w5 MBZ while v1.1 allows
-     * FFA_PARTITION_INFO_GET_COUNT_FLAG to be non-zero.
-     *
-     * FFA_PARTITION_INFO_GET_COUNT is only using registers and not the
-     * rxtx buffer so do the partition_info_get directly.
-     */
-    if ( flags == FFA_PARTITION_INFO_GET_COUNT_FLAG &&
-         ctx->guest_vers == FFA_VERSION_1_1 )
+    /* Only count requested */
+    if ( flags )
     {
+        /*
+         * FF-A v1.0 has w5 MBZ while v1.1 allows
+         * FFA_PARTITION_INFO_GET_COUNT_FLAG to be non-zero.
+         */
+        if ( ctx->guest_vers == FFA_VERSION_1_0 ||
+                flags != FFA_PARTITION_INFO_GET_COUNT_FLAG )
+        {
+            ret = FFA_RET_INVALID_PARAMETERS;
+            goto out;
+        }
+
         if ( ffa_fw_supports_fid(FFA_PARTITION_INFO_GET) )
-            ret = ffa_partition_info_get(uuid, flags, &ffa_sp_count,
-                                        &src_size);
-        else
-            ret = FFA_RET_OK;
+            ret = ffa_get_sp_count(uuid, &ffa_sp_count);
 
         goto out;
     }
 
-    if ( flags )
-    {
-        ret = FFA_RET_INVALID_PARAMETERS;
-        goto out;
-    }
-
     if ( !ffa_fw_supports_fid(FFA_PARTITION_INFO_GET) )
     {
         /* Just give an empty partition list to the caller */
@@ -121,80 +203,33 @@ void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
         goto out;
     }
 
+    /* Get the RX buffer to write the list of partitions */
     ret = ffa_rx_acquire(d);
     if ( ret != FFA_RET_OK )
         goto out;
 
     dst_buf = ctx->rx;
+    end_buf = ctx->rx + ctx->page_count * FFA_PAGE_SIZE;
 
-    if ( !ffa_rx )
-    {
-        ret = FFA_RET_DENIED;
-        goto out_rx_release;
-    }
-
-    spin_lock(&ffa_rx_buffer_lock);
-
-    ret = ffa_partition_info_get(uuid, 0, &ffa_sp_count, &src_size);
-
-    if ( ret )
-        goto out_rx_hyp_unlock;
+    /* An entry should be smaller than a page */
+    BUILD_BUG_ON(sizeof(struct ffa_partition_info_1_1) > FFA_PAGE_SIZE);
 
     /*
-     * ffa_partition_info_get() succeeded so we now own the RX buffer we
-     * share with the SPMC. We must give it back using ffa_hyp_rx_release()
-     * once we've copied the content.
+     * Check for overflow and that we can at least store one entry.
+     * page_count cannot be 0 so we have at least one page.
      */
-
-    /* we cannot have a size smaller than 1.0 structure */
-    if ( src_size < sizeof(struct ffa_partition_info_1_0) )
-    {
-        ret = FFA_RET_NOT_SUPPORTED;
-        goto out_rx_hyp_release;
-    }
-
-    if ( ctx->page_count * FFA_PAGE_SIZE < ffa_sp_count * dst_size )
+    if ( dst_buf >= end_buf || dst_buf > (end_buf - dst_size) )
     {
-        ret = FFA_RET_NO_MEMORY;
-        goto out_rx_hyp_release;
+        ret = FFA_RET_INVALID_PARAMETERS;
+        goto out_rx_release;
     }
 
-    if ( ffa_sp_count > 0 )
-    {
-        uint32_t n, n_limit = ffa_sp_count;
-        void *src_buf = ffa_rx;
-
-        /* copy the secure partitions info */
-        for ( n = 0; n < n_limit; n++ )
-        {
-            struct ffa_partition_info_1_1 *fpi = src_buf;
-
-            /* filter out SP not following bit 15 convention if any */
-            if ( FFA_ID_IS_SECURE(fpi->id) )
-            {
-                memcpy(dst_buf, src_buf, dst_size);
-                dst_buf += dst_size;
-            }
-            else
-                ffa_sp_count--;
+    ret = ffa_get_sp_partinfo(uuid, &ffa_sp_count, dst_buf, end_buf,
+                              dst_size);
 
-            src_buf += src_size;
-        }
-    }
 
-out_rx_hyp_release:
-    ffa_hyp_rx_release();
-out_rx_hyp_unlock:
-    spin_unlock(&ffa_rx_buffer_lock);
 out_rx_release:
-    /*
-     * The calling VM RX buffer only contains data to be used by the VM if the
-     * call was successful, in which case the VM has to release the buffer
-     * once it has used the data.
-     * If something went wrong during the call, we have to release the RX
-     * buffer back to the SPMC as the VM will not do it.
-     */
-    if ( ret != FFA_RET_OK )
+    if ( ret )
         ffa_rx_release(d);
 out:
     if ( ret )
@@ -353,9 +388,10 @@ bool ffa_partinfo_init(void)
         goto out;
     }
 
-    if ( count >= UINT16_MAX )
+    if ( count >= FFA_MAX_NUM_SP )
     {
-        printk(XENLOG_ERR "ffa: Impossible number of SPs: %u\n", count);
+        printk(XENLOG_ERR "ffa: More SPs than the maximum supported: %u - %u\n",
+               count, FFA_MAX_NUM_SP);
         goto out;
     }
 
diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
index c4cd65538908..0a9c1082db28 100644
--- a/xen/arch/arm/tee/ffa_private.h
+++ b/xen/arch/arm/tee/ffa_private.h
@@ -6,15 +6,15 @@
 #ifndef __FFA_PRIVATE_H__
 #define __FFA_PRIVATE_H__
 
+#include 
 #include 
-#include 
-#include 
-#include 
 #include 
-#include 
+#include 
 #include 
+#include 
+#include 
 #include 
-#include 
+#include 
 
 /* Error codes */
 #define FFA_RET_OK                      0
@@ -108,6 +108,14 @@
  */
 #define FFA_CTX_TEARDOWN_DELAY          SECONDS(1)
 
+/*
+ * The maximum number of Secure partitions we support for partinfo_get.
+ * This prevents holding the CPU during potentially to long time during
+ * a partinfo_get call. Value choosen seems realistic for any configuration
+ * but can be incremented here if needed.
+ */
+#define FFA_MAX_NUM_SP                  64
+
 /*
  * We rely on the convention suggested but not mandated by the FF-A
  * specification that secure world endpoint identifiers have the bit 15
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:08:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:08:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994203.1377255 (Exim 4.92)
	(envelope-from )
	id 1uI7XB-0006sC-W2; Thu, 22 May 2025 15:08:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994203.1377255; Thu, 22 May 2025 15:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI7XB-0006s5-Sy; Thu, 22 May 2025 15:08:37 +0000
Received: by outflank-mailman (input) for mailman id 994203;
 Thu, 22 May 2025 15:08:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7XA-0006dU-Hq
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:08:36 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id a18761d7-371e-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:08:34 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 01A871A2D;
 Thu, 22 May 2025 08:08:20 -0700 (PDT)
Received: from C3HXLD123V.arm.com (unknown [10.57.50.224])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 429CC3F673;
 Thu, 22 May 2025 08:08: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" 
X-Inumbo-ID: a18761d7-371e-11f0-b892-0df219b8e170
From: Bertrand Marquis 
To: xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Volodymyr Babchuk 
Subject: [PATCH v6 1/6] xen/arm: Create tee command line parameter
Date: Thu, 22 May 2025 17:08:02 +0200
Message-ID: <896de1bf9055e38ba77f7762b7e2a1e1ec1b2d1e.1747925287.git.bertrand.marquis@arm.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new command line parameter "tee=" to be used to explicitly select
what tee mediator is to be used by Xen and fail if it does not exist
or the probe function for it failed.

Without specifying which tee is to be used, Xen will use the first one
for which the probe function succeeds which depends on the order of the
mediator list which depends on the compiler.
Using the command line argument, it is now possible to explicit request
a specific TEE mediator and panic on boot if it is not available.

Signed-off-by: Bertrand Marquis 
Reviewed-by: Jens Wiklander 
---
Changes in v6:
- Add Jens R-b
Changes in v5:
- Typo fix and rewording in command line doc (Julien)
- fix include order in tee.c (Julien)
- use a local bool instead of retesting the string each time in tee_init
  (Julien)
Changes in v4:
- None
Changes in v3:
- Properly classify tee as arm specific (Jan)
Changes in v2:
- Patch introduced to add a command line selection of the TEE
---
 docs/misc/xen-command-line.pandoc  | 14 +++++++++++++
 xen/arch/arm/include/asm/tee/tee.h |  4 ++++
 xen/arch/arm/tee/tee.c             | 32 ++++++++++++++++++++++++++++++
 3 files changed, 50 insertions(+)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 89db6e83be66..472de1911363 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2651,6 +2651,20 @@ Specify the per-cpu trace buffer size in pages.
 
 Flag to enable TSC deadline as the APIC timer mode.
 
+### tee (arm)
+> `= `
+
+Specify the TEE mediator to be probed and use.
+
+The default behaviour is to probe all TEEs supported by Xen and use
+the first one successfully probed. When this parameter is passed, Xen will
+probe only the TEE mediator passed as argument and boot will fail if this
+mediator is not properly probed or if the requested TEE is not supported by
+Xen.
+
+This parameter can be set to `optee` or `ffa` if the corresponding mediators
+are compiled in.
+
 ### tevt_mask
 > `= `
 
diff --git a/xen/arch/arm/include/asm/tee/tee.h b/xen/arch/arm/include/asm/tee/tee.h
index 0169fd746bcd..15d664e28dce 100644
--- a/xen/arch/arm/include/asm/tee/tee.h
+++ b/xen/arch/arm/include/asm/tee/tee.h
@@ -55,6 +55,9 @@ struct tee_mediator_desc {
     /* Printable name of the TEE. */
     const char *name;
 
+    /* Command line name of the TEE (to be used with tee= cmdline option) */
+    const char *cmdline_name;
+
     /* Mediator callbacks as described above. */
     const struct tee_mediator_ops *ops;
 
@@ -77,6 +80,7 @@ void tee_free_domain_ctx(struct domain *d);
 static const struct tee_mediator_desc __tee_desc_##_name __used     \
 __section(".teemediator.info") = {                                  \
     .name = _namestr,                                               \
+    .cmdline_name = #_name,                                         \
     .ops = _ops,                                                    \
     .tee_type = _type                                               \
 }
diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c
index 3f65e45a7892..8501443c8e57 100644
--- a/xen/arch/arm/tee/tee.c
+++ b/xen/arch/arm/tee/tee.c
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -25,6 +26,10 @@
 extern const struct tee_mediator_desc _steemediator[], _eteemediator[];
 static const struct tee_mediator_desc __read_mostly *cur_mediator;
 
+/* Select the TEE mediator using a name on command line. */
+static char __initdata opt_mediator[16] = "";
+string_param("tee", opt_mediator);
+
 /*
  * TODO: Add function to alter Dom0 DTB, so we can properly describe
  * present TEE.
@@ -80,15 +85,42 @@ uint16_t tee_get_type(void)
 static int __init tee_init(void)
 {
     const struct tee_mediator_desc *desc;
+    bool select_mediator = strcmp(opt_mediator, "");
+
+    if ( select_mediator )
+        printk(XENLOG_INFO "TEE Mediator %s selected from command line\n",
+               opt_mediator);
 
+    /*
+     * When a specific TEE is selected using the 'tee=' command line
+     * argument, we panic if the probe fails or if the requested TEE is not
+     * supported.
+     */
     for ( desc = _steemediator; desc != _eteemediator; desc++ )
     {
+        if ( select_mediator &&
+             strncmp(opt_mediator, desc->cmdline_name, sizeof(opt_mediator)) )
+            continue;
+
         if ( desc->ops->probe() )
         {
             printk(XENLOG_INFO "Using TEE mediator for %s\n", desc->name);
             cur_mediator = desc;
             return 0;
         }
+        else if ( select_mediator )
+        {
+            panic("TEE mediator %s from command line probe failed\n",
+                  opt_mediator);
+            return -EFAULT;
+        }
+    }
+
+    if ( select_mediator )
+    {
+        panic("TEE Mediator %s from command line not supported\n",
+              opt_mediator);
+        return -EINVAL;
     }
 
     return 0;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:08:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:08:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994205.1377276 (Exim 4.92)
	(envelope-from )
	id 1uI7XF-0007Me-Fg; Thu, 22 May 2025 15:08:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994205.1377276; Thu, 22 May 2025 15: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 1uI7XF-0007MM-AW; Thu, 22 May 2025 15:08:41 +0000
Received: by outflank-mailman (input) for mailman id 994205;
 Thu, 22 May 2025 15:08:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7XD-0006dU-Rg
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:08:39 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id a36916e0-371e-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:08:38 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3423C1A2D;
 Thu, 22 May 2025 08:08:23 -0700 (PDT)
Received: from C3HXLD123V.arm.com (unknown [10.57.50.224])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1521D3F673;
 Thu, 22 May 2025 08:08: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" 
X-Inumbo-ID: a36916e0-371e-11f0-b892-0df219b8e170
From: Bertrand Marquis 
To: xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Michal Orzel 
Subject: [PATCH v6 3/6] xen/arm: ffa: Introduce VM to VM support
Date: Thu, 22 May 2025 17:08:04 +0200
Message-ID: <3405d6a545c5ad8fadf7b252c98ce4120fe63fd2.1747925287.git.bertrand.marquis@arm.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
between VMs.
When activated list VMs in the system with FF-A support in part_info_get.

When VM to VM is activated, Xen will be tainted as Insecure and a
message is displayed to the user during the boot as there is no
filtering of VMs in FF-A so any VM can communicate or see any other VM
in the system.

WARNING: There is no filtering for now and all VMs are listed !!

This patch is reorganizing the ffa_ctx structure to make clear which
lock is protecting what parts.

This patch is introducing a chain list of the ffa_ctx with a FFA Version
negociated allowing to create the partinfo results for VMs without
taking a lock on the global domain list in Xen.

Signed-off-by: Bertrand Marquis 
---
Changes in v6:
- remove ACCESS_ONCE for guest_vers access and take the context lock
  before modifying it
- move guest_vers in context declaration to fields protected by the
  context lock and add a comment to state that lock in only needed when
  modifying it
Changes in v5:
- remove invalid comment about 1.1 firmware support
- rename variables from d and dom to curr_d and dest_d (Julien)
- add a TODO in the code for potential holding for long of the CPU
  (Julien)
- use an atomic global variable to store the number of VMs instead of
  recomputing the value each time (Julien)
- add partinfo information in ffa_ctx (id, cpus and 64bit) and create a
  chain list of ctx. Use this chain list to create the partinfo result
  without holding a global lock to prevent concurrency issues.
- Move some changes in a preparation patch modifying partinfo for sps to
  reduce this patch size and make the review easier
Changes in v4:
- properly handle SPMC version 1.0 header size case in partinfo_get
- switch to local counting variables instead of *pointer += 1 form
- coding style issue with missing spaces in if ()
Changes in v3:
- break partinfo_get in several sub functions to make the implementation
  easier to understand and lock handling easier
- rework implementation to check size along the way and prevent previous
  implementation limits which had to check that the number of VMs or SPs
  did not change
- taint Xen as INSECURE when VM to VM is enabled
Changes in v2:
- Switch ifdef to IS_ENABLED
- dom was not switched to d as requested by Jan because there is already
  a variable d pointing to the current domain and it must not be
  shadowed.
---
 xen/arch/arm/tee/Kconfig        |  11 +++
 xen/arch/arm/tee/ffa.c          |  50 +++++++++++++-
 xen/arch/arm/tee/ffa_partinfo.c |  94 +++++++++++++++++++++++---
 xen/arch/arm/tee/ffa_private.h  | 116 ++++++++++++++++++++++++++------
 4 files changed, 239 insertions(+), 32 deletions(-)

diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
index c5b0f88d7522..88a4c4c99154 100644
--- a/xen/arch/arm/tee/Kconfig
+++ b/xen/arch/arm/tee/Kconfig
@@ -28,5 +28,16 @@ config FFA
 
 	  [1] https://developer.arm.com/documentation/den0077/latest
 
+config FFA_VM_TO_VM
+    bool "Enable FF-A between VMs (UNSUPPORTED)" if UNSUPPORTED
+    default n
+    depends on FFA
+    help
+      This option enables to use FF-A between VMs.
+      This is experimental and there is no access control so any
+      guest can communicate with any other guest.
+
+      If unsure, say N.
+
 endmenu
 
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 3bbdd7168a6b..6d71c665ac35 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -118,6 +118,13 @@ void *ffa_tx __read_mostly;
 DEFINE_SPINLOCK(ffa_rx_buffer_lock);
 DEFINE_SPINLOCK(ffa_tx_buffer_lock);
 
+struct list_head ffa_ctx_head;
+/* Lock to protect addition/removal in ffa_ctx_head */
+DEFINE_SPINLOCK(ffa_ctx_list_lock);
+
+#ifdef CONFIG_FFA_VM_TO_VM
+atomic_t ffa_vm_count;
+#endif
 
 /* Used to track domains that could not be torn down immediately. */
 static struct timer ffa_teardown_timer;
@@ -151,6 +158,7 @@ static void handle_version(struct cpu_user_regs *regs)
     struct domain *d = current->domain;
     struct ffa_ctx *ctx = d->arch.tee;
     uint32_t vers = get_user_reg(regs, 1);
+    uint32_t old_vers;
 
     /*
      * Guest will use the version it requested if it is our major and minor
@@ -160,10 +168,23 @@ static void handle_version(struct cpu_user_regs *regs)
      */
     if ( FFA_VERSION_MAJOR(vers) == FFA_MY_VERSION_MAJOR )
     {
+        spin_lock(&ctx->lock);
+        old_vers = ctx->guest_vers;
+
         if ( FFA_VERSION_MINOR(vers) > FFA_MY_VERSION_MINOR )
-            ctx->guest_vers = FFA_MY_VERSION;
+           ctx->guest_vers = FFA_MY_VERSION;
         else
-            ctx->guest_vers = vers;
+           ctx->guest_vers = vers;
+        spin_unlock(&ctx->lock);
+
+        if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !old_vers )
+        {
+            /* One more VM with FF-A support available */
+            inc_ffa_vm_count();
+            spin_lock(&ffa_ctx_list_lock);
+            list_add_tail(&ctx->ctx_list, &ffa_ctx_head);
+            spin_unlock(&ffa_ctx_list_lock);
+        }
     }
     ffa_set_regs(regs, FFA_MY_VERSION, 0, 0, 0, 0, 0, 0, 0);
 }
@@ -345,6 +366,10 @@ static int ffa_domain_init(struct domain *d)
     ctx->teardown_d = d;
     INIT_LIST_HEAD(&ctx->shm_list);
 
+    ctx->ffa_id = ffa_get_vm_id(d);
+    ctx->num_vcpus = d->max_vcpus;
+    ctx->is_64bit = is_64bit_domain(d);
+
     /*
      * ffa_domain_teardown() will be called if ffa_domain_init() returns an
      * error, so no need for cleanup in this function.
@@ -421,6 +446,14 @@ static int ffa_domain_teardown(struct domain *d)
     if ( !ctx )
         return 0;
 
+    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) && ctx->guest_vers )
+    {
+        dec_ffa_vm_count();
+        spin_lock(&ffa_ctx_list_lock);
+        list_del(&ctx->ctx_list);
+        spin_unlock(&ffa_ctx_list_lock);
+    }
+
     ffa_rxtx_domain_destroy(d);
     ffa_notif_domain_destroy(d);
 
@@ -464,6 +497,18 @@ static bool ffa_probe(void)
     printk(XENLOG_INFO "ARM FF-A Mediator version %u.%u\n",
            FFA_MY_VERSION_MAJOR, FFA_MY_VERSION_MINOR);
 
+    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
+    {
+        /*
+         * When FFA VM to VM is enabled, the current implementation does not
+         * offer any way to limit which VM can communicate with which VM using
+         * FF-A.
+         * Signal this in the xen console and taint the system as insecure.
+         * TODO: Introduce a solution to limit what a VM can do through FFA.
+         */
+        printk(XENLOG_ERR "ffa: VM to VM is enabled, system is insecure !!\n");
+        add_taint(TAINT_MACHINE_INSECURE);
+    }
     /*
      * psci_init_smccc() updates this value with what's reported by EL-3
      * or secure world.
@@ -538,6 +583,7 @@ static bool ffa_probe(void)
 
     ffa_notif_init();
     INIT_LIST_HEAD(&ffa_teardown_head);
+    INIT_LIST_HEAD(&ffa_ctx_head);
     init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NULL, 0);
 
     return true;
diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_partinfo.c
index dfa0b23eaf38..66ea1860e97a 100644
--- a/xen/arch/arm/tee/ffa_partinfo.c
+++ b/xen/arch/arm/tee/ffa_partinfo.c
@@ -150,6 +150,67 @@ out:
     return ret;
 }
 
+static int32_t ffa_get_vm_partinfo(uint32_t *vm_count, void *dst_buf,
+                                   void *end_buf, uint32_t dst_size)
+{
+    struct ffa_ctx *curr_ctx = current->domain->arch.tee;
+    struct ffa_ctx *dest_ctx, *tmp;
+    uint32_t count = 0;
+
+    /*
+     * There could potentially be a lot of VMs in the system and we could
+     * hold the CPU for long here.
+     * Right now there is no solution in FF-A specification to split
+     * the work in this case.
+     * TODO: Check how we could delay the work or have preemption checks.
+     */
+    list_for_each_entry_safe(dest_ctx, tmp, &ffa_ctx_head, ctx_list)
+    {
+        /*
+         * Do not include an entry for the caller VM as the spec is not
+         * clearly mandating it and it is not supported by Linux.
+         */
+        if ( dest_ctx != curr_ctx )
+        {
+            /*
+             * We do not have UUID info for VMs so use
+             * the 1.0 structure so that we set UUIDs to
+             * zero using memset
+             */
+            struct ffa_partition_info_1_0 info;
+
+            if  ( dst_buf > (end_buf - dst_size) )
+            {
+                return FFA_RET_NO_MEMORY;
+            }
+
+            /*
+             * Context might has been removed since we go it or being removed
+             * right now so we might return information for a VM not existing
+             * anymore. This is acceptable as we return a view of the system
+             * which could change at any time.
+             */
+            info.id = dest_ctx->ffa_id;
+            info.execution_context = dest_ctx->num_vcpus;
+            info.partition_properties = FFA_PART_VM_PROP;
+            if ( dest_ctx->is_64bit )
+                info.partition_properties |= FFA_PART_PROP_AARCH64_STATE;
+
+            memcpy(dst_buf, &info, MIN(sizeof(info), dst_size));
+
+            if ( dst_size > sizeof(info) )
+                memset(dst_buf + sizeof(info), 0,
+                       dst_size - sizeof(info));
+
+            dst_buf += dst_size;
+            count++;
+        }
+    }
+    *vm_count = count;
+
+    return FFA_RET_OK;
+}
+
 void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
 {
     int32_t ret = FFA_RET_OK;
@@ -164,7 +225,7 @@ void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
     };
     uint32_t dst_size = 0;
     void *dst_buf, *end_buf;
-    uint32_t ffa_sp_count = 0;
+    uint32_t ffa_vm_count = 0, ffa_sp_count = 0;
 
     /*
      * If the guest is v1.0, he does not get back the entry size so we must
@@ -191,15 +252,18 @@ void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
         }
 
         if ( ffa_fw_supports_fid(FFA_PARTITION_INFO_GET) )
+        {
             ret = ffa_get_sp_count(uuid, &ffa_sp_count);
+            if ( ret )
+                goto out;
+        }
 
-        goto out;
-    }
+        /*
+         * Do not count the caller VM as the spec is not clearly mandating it
+         * and it is not supported by Linux.
+         */
+        ffa_vm_count = get_ffa_vm_count() - 1;
 
-    if ( !ffa_fw_supports_fid(FFA_PARTITION_INFO_GET) )
-    {
-        /* Just give an empty partition list to the caller */
-        ret = FFA_RET_OK;
         goto out;
     }
 
@@ -224,9 +288,19 @@ void ffa_handle_partition_info_get(struct cpu_user_regs *regs)
         goto out_rx_release;
     }
 
-    ret = ffa_get_sp_partinfo(uuid, &ffa_sp_count, dst_buf, end_buf,
-                              dst_size);
+    if ( ffa_fw_supports_fid(FFA_PARTITION_INFO_GET) )
+    {
+        ret = ffa_get_sp_partinfo(uuid, &ffa_sp_count, dst_buf, end_buf,
+                                  dst_size);
+
+        if ( ret )
+            goto out_rx_release;
+
+        dst_buf += ffa_sp_count * dst_size;
+    }
 
+    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
+        ret = ffa_get_vm_partinfo(&ffa_vm_count, dst_buf, end_buf, dst_size);
 
 out_rx_release:
     if ( ret )
@@ -235,7 +309,7 @@ out:
     if ( ret )
         ffa_set_regs_error(regs, ret);
     else
-        ffa_set_regs_success(regs, ffa_sp_count, dst_size);
+        ffa_set_regs_success(regs, ffa_sp_count + ffa_vm_count, dst_size);
 }
 
 static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
index 0a9c1082db28..08dbdf9fcddd 100644
--- a/xen/arch/arm/tee/ffa_private.h
+++ b/xen/arch/arm/tee/ffa_private.h
@@ -195,6 +195,18 @@
  */
 #define FFA_PARTITION_INFO_GET_COUNT_FLAG BIT(0, U)
 
+/*
+ * Partition properties we give for a normal world VM:
+ * - can send direct message but not receive them
+ * - can handle indirect messages
+ * - can receive notifications
+ * 32/64 bit flag is set depending on the VM
+ */
+#define FFA_PART_VM_PROP    (FFA_PART_PROP_DIRECT_REQ_SEND | \
+                             FFA_PART_PROP_INDIRECT_MSGS | \
+                             FFA_PART_PROP_RECV_NOTIF | \
+                             FFA_PART_PROP_IS_PE_ID)
+
 /* Flags used in calls to FFA_NOTIFICATION_GET interface  */
 #define FFA_NOTIF_FLAG_BITMAP_SP        BIT(0, U)
 #define FFA_NOTIF_FLAG_BITMAP_VM        BIT(1, U)
@@ -297,36 +309,70 @@ struct ffa_ctx_notif {
 };
 
 struct ffa_ctx {
-    void *rx;
-    const void *tx;
-    struct page_info *rx_pg;
-    struct page_info *tx_pg;
+    /*
+     * Chain list of all FF-A contexts, to prevent locking access to this list,
+     * all "unlocked" data from the structure must be set before adding an
+     * entry in the list and an entry must be removed from the list before
+     * freeing a context.
+     */
+    struct list_head ctx_list; /* chain list of all FF-A contexts */
+
+    /*
+     * Data access unlocked (mainly for part_info_get in VM to VM).
+     * Those should be set before the ctx is added in the list.
+     */
+    /* FF-A Endpoint ID */
+    uint16_t ffa_id;
+    uint16_t num_vcpus;
+    bool is_64bit;
+
+    /*
+     * Global data accessed atomically or using ACCES_ONCE.
+     */
+    struct ffa_ctx_notif notif;
+
+    /*
+     * Global data accessed with lock locked.
+     */
+    spinlock_t lock;
+    /*
+     * FF-A version negociated by the guest, only modifications to
+     * this field are done with the lock held as this is expected to
+     * be done once at init by a guest.
+     */
+    uint32_t guest_vers;
     /* Number of 4kB pages in each of rx/rx_pg and tx/tx_pg */
     unsigned int page_count;
-    /* FF-A version used by the guest */
-    uint32_t guest_vers;
-    bool rx_is_free;
-    /* Used shared memory objects, struct ffa_shm_mem */
-    struct list_head shm_list;
     /* Number of allocated shared memory object */
     unsigned int shm_count;
-    struct ffa_ctx_notif notif;
+    /* Used shared memory objects, struct ffa_shm_mem */
+    struct list_head shm_list;
+
     /*
-     * tx_lock is used to serialize access to tx
-     * rx_lock is used to serialize access to rx_is_free
-     * lock is used for the rest in this struct
+     * Rx buffer, accessed with rx_lock locked.
+     * rx_is_free is used to serialize access.
      */
-    spinlock_t tx_lock;
     spinlock_t rx_lock;
-    spinlock_t lock;
-    /* Used if domain can't be torn down immediately */
+    bool rx_is_free;
+    void *rx;
+    struct page_info *rx_pg;
+
+    /*
+     * Tx buffer, access with tx_lock locked.
+     */
+    spinlock_t tx_lock;
+    const void *tx;
+    struct page_info *tx_pg;
+
+
+    /*
+     * Domain teardown handling if data shared or used by other domains
+     * do not allow to teardown the domain immediately.
+     */
     struct domain *teardown_d;
     struct list_head teardown_list;
     s_time_t teardown_expire;
-    /*
-     * Used for ffa_domain_teardown() to keep track of which SPs should be
-     * notified that this guest is being destroyed.
-     */
+    /* Keep track of SPs that should be notified of VM destruction */
     unsigned long *vm_destroy_bitmap;
 };
 
@@ -334,8 +380,15 @@ extern void *ffa_rx;
 extern void *ffa_tx;
 extern spinlock_t ffa_rx_buffer_lock;
 extern spinlock_t ffa_tx_buffer_lock;
+extern spinlock_t ffa_ctx_list_lock;
 extern DECLARE_BITMAP(ffa_fw_abi_supported, FFA_ABI_BITMAP_SIZE);
 
+extern struct list_head ffa_ctx_head;
+
+#ifdef CONFIG_FFA_VM_TO_VM
+extern atomic_t ffa_vm_count;
+#endif
+
 bool ffa_shm_domain_destroy(struct domain *d);
 void ffa_handle_mem_share(struct cpu_user_regs *regs);
 int ffa_handle_mem_reclaim(uint64_t handle, uint32_t flags);
@@ -368,6 +421,29 @@ int ffa_handle_notification_set(struct cpu_user_regs *regs);
 void ffa_handle_msg_send_direct_req(struct cpu_user_regs *regs, uint32_t fid);
 int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs);
 
+#ifdef CONFIG_FFA_VM_TO_VM
+static inline uint16_t get_ffa_vm_count(void)
+{
+    return atomic_read(&ffa_vm_count);
+}
+
+static inline void inc_ffa_vm_count(void)
+{
+    atomic_inc(&ffa_vm_count);
+}
+
+static inline void dec_ffa_vm_count(void)
+{
+    ASSERT(atomic_read(&ffa_vm_count) > 0);
+    atomic_dec(&ffa_vm_count);
+}
+#else
+/* Only count the caller VM */
+#define get_ffa_vm_count()  ((uint16_t)1UL)
+#define inc_ffa_vm_count()  do {} while(0)
+#define dec_ffa_vm_count()  do {} while(0)
+#endif
+
 static inline uint16_t ffa_get_vm_id(const struct domain *d)
 {
     /* +1 since 0 is reserved for the hypervisor in FF-A */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:08:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:08:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994206.1377285 (Exim 4.92)
	(envelope-from )
	id 1uI7XG-0007cM-R0; Thu, 22 May 2025 15:08:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994206.1377285; Thu, 22 May 2025 15: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 1uI7XG-0007cF-Mm; Thu, 22 May 2025 15:08:42 +0000
Received: by outflank-mailman (input) for mailman id 994206;
 Thu, 22 May 2025 15:08:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7XF-0006dU-Av
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:08:41 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id a45a25eb-371e-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:08:39 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C4C251A32;
 Thu, 22 May 2025 08:08:24 -0700 (PDT)
Received: from C3HXLD123V.arm.com (unknown [10.57.50.224])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BAC293F673;
 Thu, 22 May 2025 08:08:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a45a25eb-371e-11f0-b892-0df219b8e170
From: Bertrand Marquis 
To: xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Michal Orzel 
Subject: [PATCH v6 4/6] xen/arm: ffa: Add buffer full notification support
Date: Thu, 22 May 2025 17:08:05 +0200
Message-ID: <7e206a2e4f093af965a134bda23e3c4104267826.1747925287.git.bertrand.marquis@arm.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add support to raise a Rx buffer full notification to a VM.
This function will be used for indirect message support between VM and
is only activated if CONFIG_FFA_VM_TO_VM is selected.

Even if there are 32 framework notifications possible, right now only
one is defined so the implementation is simplified to only handle the
buffer full notification using a boolean. If other framework
notifications have to be supported one day, the design will have to be
modified to handle it properly.

Signed-off-by: Bertrand Marquis 
Reviewed-by: Jens Wiklander 
---
Changes in v6:
- None
Changes in v5:
- None
Changes in v4:
- Add Jens R-b
Changes in v3:
- introduce a vm_pending boolean to track if VM notifications are
  pending and allow to decorelate pending secure notifications from
  pending vm ones
- remove ifdef around boolean entries for notifications and make use of
  IS_ENABLED instead of ifdefs when possible
- Fix notification number signaled to VMs for buffer full to use the
  proper GUEST_FFA_NOTIF_PEND_INTR_ID instead of the identifier received
  from the SPMC.
- Move back into this patch ffa_private.h part which was wrongly in the
  patch for indirect messages between VM
Changes in v2:
- Switch ifdef to IS_ENABLED when possible
---
 xen/arch/arm/tee/ffa_notif.c   | 36 ++++++++++++++++++++++++++++------
 xen/arch/arm/tee/ffa_private.h | 23 +++++++++++++++++++++-
 2 files changed, 52 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c
index 00efaf8f7353..f6df2f15bb00 100644
--- a/xen/arch/arm/tee/ffa_notif.c
+++ b/xen/arch/arm/tee/ffa_notif.c
@@ -69,6 +69,7 @@ void ffa_handle_notification_info_get(struct cpu_user_regs *regs)
 {
     struct domain *d = current->domain;
     struct ffa_ctx *ctx = d->arch.tee;
+    bool notif_pending;
 
     if ( !notif_enabled )
     {
@@ -76,7 +77,11 @@ void ffa_handle_notification_info_get(struct cpu_user_regs *regs)
         return;
     }
 
-    if ( test_and_clear_bool(ctx->notif.secure_pending) )
+    notif_pending = test_and_clear_bool(ctx->notif.secure_pending);
+    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
+        notif_pending |= test_and_clear_bool(ctx->notif.vm_pending);
+
+    if ( notif_pending )
     {
         /* A pending global notification for the guest */
         ffa_set_regs(regs, FFA_SUCCESS_64, 0,
@@ -93,6 +98,7 @@ void ffa_handle_notification_info_get(struct cpu_user_regs *regs)
 void ffa_handle_notification_get(struct cpu_user_regs *regs)
 {
     struct domain *d = current->domain;
+    struct ffa_ctx *ctx = d->arch.tee;
     uint32_t recv = get_user_reg(regs, 1);
     uint32_t flags = get_user_reg(regs, 2);
     uint32_t w2 = 0;
@@ -132,11 +138,7 @@ void ffa_handle_notification_get(struct cpu_user_regs *regs)
          */
         if ( ( flags  & FFA_NOTIF_FLAG_BITMAP_SP ) &&
              ( flags & FFA_NOTIF_FLAG_BITMAP_SPM ) )
-        {
-                struct ffa_ctx *ctx = d->arch.tee;
-
-                ACCESS_ONCE(ctx->notif.secure_pending) = false;
-        }
+            ACCESS_ONCE(ctx->notif.secure_pending) = false;
 
         arm_smccc_1_2_smc(&arg, &resp);
         e = ffa_get_ret_code(&resp);
@@ -156,6 +158,14 @@ void ffa_handle_notification_get(struct cpu_user_regs *regs)
             w6 = resp.a6;
     }
 
+    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) &&
+          flags & FFA_NOTIF_FLAG_BITMAP_HYP &&
+          test_and_clear_bool(ctx->notif.buff_full_pending) )
+    {
+        ACCESS_ONCE(ctx->notif.vm_pending) = false;
+        w7 = FFA_NOTIF_RX_BUFFER_FULL;
+    }
+
     ffa_set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, w4, w5, w6, w7);
 }
 
@@ -178,6 +188,20 @@ int ffa_handle_notification_set(struct cpu_user_regs *regs)
                            bitmap_hi);
 }
 
+#ifdef CONFIG_FFA_VM_TO_VM
+void ffa_raise_rx_buffer_full(struct domain *d)
+{
+    struct ffa_ctx *ctx = d->arch.tee;
+
+    if ( !ctx )
+        return;
+
+    ACCESS_ONCE(ctx->notif.buff_full_pending) = true;
+    if ( !test_and_set_bool(ctx->notif.vm_pending) )
+        vgic_inject_irq(d, d->vcpu[0], GUEST_FFA_NOTIF_PEND_INTR_ID, true);
+}
+#endif
+
 /*
  * Extract a 16-bit ID (index n) from the successful return value from
  * FFA_NOTIFICATION_INFO_GET_64 or FFA_NOTIFICATION_INFO_GET_32. IDs are
diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
index 08dbdf9fcddd..d39aca4500b9 100644
--- a/xen/arch/arm/tee/ffa_private.h
+++ b/xen/arch/arm/tee/ffa_private.h
@@ -218,6 +218,8 @@
 #define FFA_NOTIF_INFO_GET_ID_COUNT_SHIFT   7
 #define FFA_NOTIF_INFO_GET_ID_COUNT_MASK    0x1F
 
+#define FFA_NOTIF_RX_BUFFER_FULL        BIT(0, U)
+
 /* Feature IDs used with FFA_FEATURES */
 #define FFA_FEATURE_NOTIF_PEND_INTR     0x1U
 #define FFA_FEATURE_SCHEDULE_RECV_INTR  0x2U
@@ -303,9 +305,20 @@ struct ffa_mem_region {
 struct ffa_ctx_notif {
     /*
      * True if domain is reported by FFA_NOTIFICATION_INFO_GET to have
-     * pending global notifications.
+     * pending notifications from the secure world.
      */
     bool secure_pending;
+
+    /*
+     * True if domain is reported by FFA_NOTIFICATION_INFO_GET to have
+     * pending notifications from VMs (including framework ones).
+     */
+    bool vm_pending;
+
+    /*
+     * True if domain has buffer full notification pending
+     */
+    bool buff_full_pending;
 };
 
 struct ffa_ctx {
@@ -418,6 +431,14 @@ void ffa_handle_notification_info_get(struct cpu_user_regs *regs);
 void ffa_handle_notification_get(struct cpu_user_regs *regs);
 int ffa_handle_notification_set(struct cpu_user_regs *regs);
 
+#ifdef CONFIG_FFA_VM_TO_VM
+void ffa_raise_rx_buffer_full(struct domain *d);
+#else
+static inline void ffa_raise_rx_buffer_full(struct domain *d)
+{
+}
+#endif
+
 void ffa_handle_msg_send_direct_req(struct cpu_user_regs *regs, uint32_t fid);
 int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs);
 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:08:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:08:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994207.1377295 (Exim 4.92)
	(envelope-from )
	id 1uI7XI-0007s2-3N; Thu, 22 May 2025 15:08:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994207.1377295; Thu, 22 May 2025 15: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 1uI7XH-0007rp-V4; Thu, 22 May 2025 15:08:43 +0000
Received: by outflank-mailman (input) for mailman id 994207;
 Thu, 22 May 2025 15:08:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7XG-0006dU-LQ
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:08:42 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id a538790b-371e-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:08:41 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6497D293B;
 Thu, 22 May 2025 08:08:26 -0700 (PDT)
Received: from C3HXLD123V.arm.com (unknown [10.57.50.224])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 578443F673;
 Thu, 22 May 2025 08:08: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" 
X-Inumbo-ID: a538790b-371e-11f0-b892-0df219b8e170
From: Bertrand Marquis 
To: xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Michal Orzel 
Subject: [PATCH v6 5/6] xen/arm: ffa: Add indirect message between VM
Date: Thu, 22 May 2025 17:08:06 +0200
Message-ID: <594a9d91dc499c219489111e0c896825fae32300.1747925287.git.bertrand.marquis@arm.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add support for indirect messages between VMs.
This is only enabled if CONFIG_FFA_VM_TO_VM is selected.

Signed-off-by: Bertrand Marquis 
Reviewed-by: Jens Wiklander 
---
Changes in v6:
- fix code alignment (Jens)
- add Jens R-b
Changes in v5:
- Prevent potential overflow in send2 handling (Julien)
- Only use page_count with rx lock acquired
- Fix an issue where send2 between VMs was not doing the copy from the
  tx buffer but from a wrong location in the stack. This bug was
  introduced in v4 when switching to a local copy for the header.
Changes in v4:
- Use a local copy of the message header to prevent a TOC/TOU possible
  issue when using the payload size
Changes in v3:
- Move vm to vm indirect message handling in a sub function to simplify
  lock handling and make implementation easier to read
Changes in v2:
- Switch ifdef to IS_ENABLED
---
 xen/arch/arm/tee/ffa_msg.c | 117 ++++++++++++++++++++++++++++++++-----
 1 file changed, 102 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
index ee594e737fc7..c20c5bec0f76 100644
--- a/xen/arch/arm/tee/ffa_msg.c
+++ b/xen/arch/arm/tee/ffa_msg.c
@@ -88,43 +88,130 @@ out:
                  resp.a7 & mask);
 }
 
+static int32_t ffa_msg_send2_vm(uint16_t dst_id, const void *src_buf,
+                                struct ffa_part_msg_rxtx *src_msg)
+{
+    struct domain *dst_d;
+    struct ffa_ctx *dst_ctx;
+    struct ffa_part_msg_rxtx *dst_msg;
+    int err;
+    int32_t ret;
+
+    if ( dst_id == 0 )
+        /* FF-A ID 0 is the hypervisor, this is not valid */
+        return FFA_RET_INVALID_PARAMETERS;
+
+    /* This is also checking that dest is not src */
+    err = rcu_lock_live_remote_domain_by_id(dst_id - 1, &dst_d);
+    if ( err )
+        return FFA_RET_INVALID_PARAMETERS;
+
+    if ( dst_d->arch.tee == NULL )
+    {
+        ret = FFA_RET_INVALID_PARAMETERS;
+        goto out_unlock;
+    }
+
+    dst_ctx = dst_d->arch.tee;
+    if ( !dst_ctx->guest_vers )
+    {
+        ret = FFA_RET_INVALID_PARAMETERS;
+        goto out_unlock;
+    }
+
+    /* This also checks that destination has set a Rx buffer */
+    ret = ffa_rx_acquire(dst_d);
+    if ( ret )
+        goto out_unlock;
+
+    /* we need to have enough space in the destination buffer */
+    if ( (dst_ctx->page_count * FFA_PAGE_SIZE -
+          sizeof(struct ffa_part_msg_rxtx)) < src_msg->msg_size )
+    {
+        ret = FFA_RET_NO_MEMORY;
+        ffa_rx_release(dst_d);
+        goto out_unlock;
+    }
+
+    dst_msg = dst_ctx->rx;
+
+    /* prepare destination header */
+    dst_msg->flags = 0;
+    dst_msg->reserved = 0;
+    dst_msg->msg_offset = sizeof(struct ffa_part_msg_rxtx);
+    dst_msg->send_recv_id = src_msg->send_recv_id;
+    dst_msg->msg_size = src_msg->msg_size;
+
+    memcpy(dst_ctx->rx + sizeof(struct ffa_part_msg_rxtx),
+           src_buf + src_msg->msg_offset, src_msg->msg_size);
+
+    /* receiver rx buffer will be released by the receiver*/
+
+out_unlock:
+    rcu_unlock_domain(dst_d);
+    if ( !ret )
+        ffa_raise_rx_buffer_full(dst_d);
+
+    return ret;
+}
+
 int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs)
 {
     struct domain *src_d = current->domain;
     struct ffa_ctx *src_ctx = src_d->arch.tee;
-    const struct ffa_part_msg_rxtx *src_msg;
+    struct ffa_part_msg_rxtx src_msg;
     uint16_t dst_id, src_id;
     int32_t ret;
 
-    if ( !ffa_fw_supports_fid(FFA_MSG_SEND2) )
-        return FFA_RET_NOT_SUPPORTED;
+    BUILD_BUG_ON(sizeof(struct ffa_part_msg_rxtx) >= FFA_PAGE_SIZE);
 
     if ( !spin_trylock(&src_ctx->tx_lock) )
         return FFA_RET_BUSY;
 
-    src_msg = src_ctx->tx;
-    src_id = src_msg->send_recv_id >> 16;
-    dst_id = src_msg->send_recv_id & GENMASK(15,0);
+    /* create a copy of the message header */
+    memcpy(&src_msg, src_ctx->tx, sizeof(src_msg));
 
-    if ( src_id != ffa_get_vm_id(src_d) || !FFA_ID_IS_SECURE(dst_id) )
+    src_id = src_msg.send_recv_id >> 16;
+    dst_id = src_msg.send_recv_id & GENMASK(15,0);
+
+    if ( src_id != ffa_get_vm_id(src_d) )
     {
         ret = FFA_RET_INVALID_PARAMETERS;
-        goto out_unlock_tx;
+        goto out;
     }
 
     /* check source message fits in buffer */
-    if ( src_ctx->page_count * FFA_PAGE_SIZE <
-         src_msg->msg_offset + src_msg->msg_size ||
-         src_msg->msg_offset < sizeof(struct ffa_part_msg_rxtx) )
+    if ( src_msg.msg_offset < sizeof(struct ffa_part_msg_rxtx) ||
+            src_msg.msg_size == 0 ||
+            src_msg.msg_offset > src_ctx->page_count * FFA_PAGE_SIZE ||
+            src_msg.msg_size > (src_ctx->page_count * FFA_PAGE_SIZE -
+                                src_msg.msg_offset) )
     {
         ret = FFA_RET_INVALID_PARAMETERS;
-        goto out_unlock_tx;
+        goto out;
     }
 
-    ret = ffa_simple_call(FFA_MSG_SEND2,
-                          ((uint32_t)ffa_get_vm_id(src_d)) << 16, 0, 0, 0);
+    if ( FFA_ID_IS_SECURE(dst_id) )
+    {
+        /* Message for a secure partition */
+        if ( !ffa_fw_supports_fid(FFA_MSG_SEND2) )
+        {
+            ret = FFA_RET_NOT_SUPPORTED;
+            goto out;
+        }
+
+        ret = ffa_simple_call(FFA_MSG_SEND2,
+                              ((uint32_t)ffa_get_vm_id(src_d)) << 16, 0, 0, 0);
+    }
+    else if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
+    {
+        /* Message for a VM */
+        ret = ffa_msg_send2_vm(dst_id, src_ctx->tx, &src_msg);
+    }
+    else
+        ret = FFA_RET_INVALID_PARAMETERS;
 
-out_unlock_tx:
+out:
     spin_unlock(&src_ctx->tx_lock);
     return ret;
 }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:08:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:08:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994208.1377304 (Exim 4.92)
	(envelope-from )
	id 1uI7XJ-00088K-B4; Thu, 22 May 2025 15:08:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994208.1377304; Thu, 22 May 2025 15:08: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 1uI7XJ-00087h-84; Thu, 22 May 2025 15:08:45 +0000
Received: by outflank-mailman (input) for mailman id 994208;
 Thu, 22 May 2025 15:08:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7XI-0006dU-C2
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:08:44 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id a631e9ad-371e-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:08:42 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 03B101A32;
 Thu, 22 May 2025 08:08:28 -0700 (PDT)
Received: from C3HXLD123V.arm.com (unknown [10.57.50.224])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E79E03F673;
 Thu, 22 May 2025 08:08: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" 
X-Inumbo-ID: a631e9ad-371e-11f0-b892-0df219b8e170
From: Bertrand Marquis 
To: xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org,
	Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Michal Orzel 
Subject: [PATCH v6 6/6] xen/arm: ffa: Enable VM to VM without firmware
Date: Thu, 22 May 2025 17:08:07 +0200
Message-ID: <6e85a4a2de01aee23a366f33b3a856b52171bc40.1747925288.git.bertrand.marquis@arm.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

When VM to VM support is activated and there is no suitable FF-A support
in the firmware, enable FF-A support for VMs to allow using it for VM to
VM communications.
If there is OP-TEE running in the secure world and using the non FF-A
communication system, having CONFIG_FFA_VM_TO_VM could be non functional
(if optee is probed first) or OP-TEE could be non functional (if FF-A is
probed first) so it is not recommended to activate the configuration
option for such systems.

To make buffer full notification work between VMs when there is no
firmware, rework the notification handling and modify the global flag to
only be used as check for firmware notification support instead.

Also split probe function into one for firmware and one for vm to vm to
make the implementation clearer.

Signed-off-by: Bertrand Marquis 
---
Changes in v6:
- split probe into fw and vm_to_vm probe
Changes in v5:
- init ctx list when there is no firmware
- rework init a bit to prevent duplicates
- Remove Jens R-b due to changes done
Changes in v4:
- Fix Optee to OP-TEE in commit message
- Add Jens R-b
Changes in v3:
- fix typos in commit message
- add spaces around <<
- move notification id fix back into buffer full patch
- fix | position in if
Changes in v2:
- replace ifdef with IS_ENABLED when possible
---
 xen/arch/arm/tee/ffa.c       |  91 ++++++++++++++++++------------
 xen/arch/arm/tee/ffa_notif.c | 104 ++++++++++++++++-------------------
 2 files changed, 103 insertions(+), 92 deletions(-)

diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 6d71c665ac35..42dfc71a12d7 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -345,8 +345,9 @@ static int ffa_domain_init(struct domain *d)
     struct ffa_ctx *ctx;
     int ret;
 
-    if ( !ffa_fw_version )
+    if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !ffa_fw_version )
         return -ENODEV;
+
     /*
      * We are using the domain_id + 1 as the FF-A ID for VMs as FF-A ID 0 is
      * reserved for the hypervisor and we only support secure endpoints using
@@ -477,38 +478,12 @@ static void ffa_init_secondary(void)
     ffa_notif_init_interrupt();
 }
 
-static bool ffa_probe(void)
+static bool ffa_probe_fw(void)
 {
     uint32_t vers;
     unsigned int major_vers;
     unsigned int minor_vers;
 
-    /*
-     * FF-A often works in units of 4K pages and currently it's assumed
-     * that we can map memory using that granularity. See also the comment
-     * above the FFA_PAGE_SIZE define.
-     *
-     * It is possible to support a PAGE_SIZE larger than 4K in Xen, but
-     * until that is fully handled in this code make sure that we only use
-     * 4K page sizes.
-     */
-    BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
-
-    printk(XENLOG_INFO "ARM FF-A Mediator version %u.%u\n",
-           FFA_MY_VERSION_MAJOR, FFA_MY_VERSION_MINOR);
-
-    if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
-    {
-        /*
-         * When FFA VM to VM is enabled, the current implementation does not
-         * offer any way to limit which VM can communicate with which VM using
-         * FF-A.
-         * Signal this in the xen console and taint the system as insecure.
-         * TODO: Introduce a solution to limit what a VM can do through FFA.
-         */
-        printk(XENLOG_ERR "ffa: VM to VM is enabled, system is insecure !!\n");
-        add_taint(TAINT_MACHINE_INSECURE);
-    }
     /*
      * psci_init_smccc() updates this value with what's reported by EL-3
      * or secure world.
@@ -527,11 +502,6 @@ static bool ffa_probe(void)
         goto err_no_fw;
     }
 
-    /* Some sanity check in case we update the version we support */
-    BUILD_BUG_ON(FFA_MIN_SPMC_VERSION > FFA_MY_VERSION);
-    BUILD_BUG_ON(FFA_VERSION_MAJOR(FFA_MIN_SPMC_VERSION) !=
-                                   FFA_MY_VERSION_MAJOR);
-
     major_vers = FFA_VERSION_MAJOR(vers);
     minor_vers = FFA_VERSION_MINOR(vers);
 
@@ -582,9 +552,6 @@ static bool ffa_probe(void)
         goto err_rxtx_destroy;
 
     ffa_notif_init();
-    INIT_LIST_HEAD(&ffa_teardown_head);
-    INIT_LIST_HEAD(&ffa_ctx_head);
-    init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NULL, 0);
 
     return true;
 
@@ -598,6 +565,58 @@ err_no_fw:
     return false;
 }
 
+static bool ffa_probe_vm_to_vm(void)
+{
+    if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
+        return false;
+
+    /*
+     * When FFA VM to VM is enabled, the current implementation does not
+     * offer any way to limit which VM can communicate with which VM using
+     * FF-A.
+     * Signal this in the xen console and taint the system as insecure.
+     * TODO: Introduce a solution to limit what a VM can do through FFA.
+     */
+    printk(XENLOG_ERR "ffa: VM to VM is enabled, system is insecure !!\n");
+    add_taint(TAINT_MACHINE_INSECURE);
+
+    return true;
+}
+
+static bool ffa_probe(void)
+{
+    /*
+     * FF-A often works in units of 4K pages and currently it's assumed
+     * that we can map memory using that granularity. See also the comment
+     * above the FFA_PAGE_SIZE define.
+     *
+     * It is possible to support a PAGE_SIZE larger than 4K in Xen, but
+     * until that is fully handled in this code make sure that we only use
+     * 4K page sizes.
+     */
+    BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
+
+    /* Some sanity check in case we update the version we support */
+    BUILD_BUG_ON(FFA_MIN_SPMC_VERSION > FFA_MY_VERSION);
+    BUILD_BUG_ON(FFA_VERSION_MAJOR(FFA_MIN_SPMC_VERSION) !=
+                                   FFA_MY_VERSION_MAJOR);
+
+    printk(XENLOG_INFO "ARM FF-A Mediator version %u.%u\n",
+           FFA_MY_VERSION_MAJOR, FFA_MY_VERSION_MINOR);
+
+    if ( !ffa_probe_fw() && !ffa_probe_vm_to_vm() )
+        return false;
+
+    if ( !ffa_fw_version )
+        printk(XENLOG_INFO "ARM FF-A only available between VMs\n");
+
+    INIT_LIST_HEAD(&ffa_teardown_head);
+    INIT_LIST_HEAD(&ffa_ctx_head);
+    init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NULL, 0);
+
+    return true;
+}
+
 static const struct tee_mediator_ops ffa_ops =
 {
     .probe = ffa_probe,
diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c
index f6df2f15bb00..86bef6b3b2ab 100644
--- a/xen/arch/arm/tee/ffa_notif.c
+++ b/xen/arch/arm/tee/ffa_notif.c
@@ -16,7 +16,7 @@
 
 #include "ffa_private.h"
 
-static bool __ro_after_init notif_enabled;
+static bool __ro_after_init fw_notif_enabled;
 static unsigned int __ro_after_init notif_sri_irq;
 
 int ffa_handle_notification_bind(struct cpu_user_regs *regs)
@@ -27,21 +27,17 @@ int ffa_handle_notification_bind(struct cpu_user_regs *regs)
     uint32_t bitmap_lo = get_user_reg(regs, 3);
     uint32_t bitmap_hi = get_user_reg(regs, 4);
 
-    if ( !notif_enabled )
-        return FFA_RET_NOT_SUPPORTED;
-
     if ( (src_dst & 0xFFFFU) != ffa_get_vm_id(d) )
         return FFA_RET_INVALID_PARAMETERS;
 
     if ( flags )    /* Only global notifications are supported */
         return FFA_RET_DENIED;
 
-    /*
-     * We only support notifications from SP so no need to check the sender
-     * endpoint ID, the SPMC will take care of that for us.
-     */
-    return ffa_simple_call(FFA_NOTIFICATION_BIND, src_dst, flags, bitmap_lo,
-                           bitmap_hi);
+    if ( FFA_ID_IS_SECURE(src_dst >> 16) && fw_notif_enabled )
+        return ffa_simple_call(FFA_NOTIFICATION_BIND, src_dst, flags,
+                               bitmap_lo, bitmap_hi);
+
+    return FFA_RET_NOT_SUPPORTED;
 }
 
 int ffa_handle_notification_unbind(struct cpu_user_regs *regs)
@@ -51,18 +47,14 @@ int ffa_handle_notification_unbind(struct cpu_user_regs *regs)
     uint32_t bitmap_lo = get_user_reg(regs, 3);
     uint32_t bitmap_hi = get_user_reg(regs, 4);
 
-    if ( !notif_enabled )
-        return FFA_RET_NOT_SUPPORTED;
-
     if ( (src_dst & 0xFFFFU) != ffa_get_vm_id(d) )
         return FFA_RET_INVALID_PARAMETERS;
 
-    /*
-     * We only support notifications from SP so no need to check the
-     * destination endpoint ID, the SPMC will take care of that for us.
-     */
-    return  ffa_simple_call(FFA_NOTIFICATION_UNBIND, src_dst, 0, bitmap_lo,
-                            bitmap_hi);
+    if ( FFA_ID_IS_SECURE(src_dst >> 16) && fw_notif_enabled )
+        return  ffa_simple_call(FFA_NOTIFICATION_UNBIND, src_dst, 0, bitmap_lo,
+                                bitmap_hi);
+
+    return FFA_RET_NOT_SUPPORTED;
 }
 
 void ffa_handle_notification_info_get(struct cpu_user_regs *regs)
@@ -71,7 +63,7 @@ void ffa_handle_notification_info_get(struct cpu_user_regs *regs)
     struct ffa_ctx *ctx = d->arch.tee;
     bool notif_pending;
 
-    if ( !notif_enabled )
+    if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !fw_notif_enabled )
     {
         ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
         return;
@@ -108,7 +100,7 @@ void ffa_handle_notification_get(struct cpu_user_regs *regs)
     uint32_t w6 = 0;
     uint32_t w7 = 0;
 
-    if ( !notif_enabled )
+    if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !fw_notif_enabled )
     {
         ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
         return;
@@ -120,7 +112,8 @@ void ffa_handle_notification_get(struct cpu_user_regs *regs)
         return;
     }
 
-    if ( flags & ( FFA_NOTIF_FLAG_BITMAP_SP | FFA_NOTIF_FLAG_BITMAP_SPM ) )
+    if ( fw_notif_enabled && (flags & ( FFA_NOTIF_FLAG_BITMAP_SP |
+                                        FFA_NOTIF_FLAG_BITMAP_SPM )) )
     {
         struct arm_smccc_1_2_regs arg = {
             .a0 = FFA_NOTIFICATION_GET,
@@ -177,15 +170,14 @@ int ffa_handle_notification_set(struct cpu_user_regs *regs)
     uint32_t bitmap_lo = get_user_reg(regs, 3);
     uint32_t bitmap_hi = get_user_reg(regs, 4);
 
-    if ( !notif_enabled )
-        return FFA_RET_NOT_SUPPORTED;
-
     if ( (src_dst >> 16) != ffa_get_vm_id(d) )
         return FFA_RET_INVALID_PARAMETERS;
 
-    /* Let the SPMC check the destination of the notification */
-    return ffa_simple_call(FFA_NOTIFICATION_SET, src_dst, flags, bitmap_lo,
-                           bitmap_hi);
+    if ( FFA_ID_IS_SECURE(src_dst >> 16) && fw_notif_enabled )
+        return ffa_simple_call(FFA_NOTIFICATION_SET, src_dst, flags, bitmap_lo,
+                               bitmap_hi);
+
+    return FFA_RET_NOT_SUPPORTED;
 }
 
 #ifdef CONFIG_FFA_VM_TO_VM
@@ -371,7 +363,7 @@ void ffa_notif_init_interrupt(void)
 {
     int ret;
 
-    if ( notif_enabled && notif_sri_irq < NR_GIC_SGI )
+    if ( fw_notif_enabled && notif_sri_irq < NR_GIC_SGI )
     {
         /*
          * An error here is unlikely since the primary CPU has already
@@ -402,41 +394,41 @@ void ffa_notif_init(void)
     int ret;
 
     /* Only enable fw notification if all ABIs we need are supported */
-    if ( !(ffa_fw_supports_fid(FFA_NOTIFICATION_BITMAP_CREATE) &&
-           ffa_fw_supports_fid(FFA_NOTIFICATION_BITMAP_DESTROY) &&
-           ffa_fw_supports_fid(FFA_NOTIFICATION_GET) &&
-           ffa_fw_supports_fid(FFA_NOTIFICATION_INFO_GET_64)) )
-        return;
-
-    arm_smccc_1_2_smc(&arg, &resp);
-    if ( resp.a0 != FFA_SUCCESS_32 )
-        return;
-
-    irq = resp.a2;
-    notif_sri_irq = irq;
-    if ( irq >= NR_GIC_SGI )
-        irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
-    ret = request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL);
-    if ( ret )
+    if ( ffa_fw_supports_fid(FFA_NOTIFICATION_BITMAP_CREATE) &&
+         ffa_fw_supports_fid(FFA_NOTIFICATION_BITMAP_DESTROY) &&
+         ffa_fw_supports_fid(FFA_NOTIFICATION_GET) &&
+         ffa_fw_supports_fid(FFA_NOTIFICATION_INFO_GET_64) )
     {
-        printk(XENLOG_ERR "ffa: request_irq irq %u failed: error %d\n",
-               irq, ret);
-        return;
-    }
+        arm_smccc_1_2_smc(&arg, &resp);
+        if ( resp.a0 != FFA_SUCCESS_32 )
+            return;
 
-    notif_enabled = true;
+        irq = resp.a2;
+        notif_sri_irq = irq;
+        if ( irq >= NR_GIC_SGI )
+            irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
+        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);
+            return;
+        }
+        fw_notif_enabled = true;
+    }
 }
 
 int ffa_notif_domain_init(struct domain *d)
 {
     int32_t res;
 
-    if ( !notif_enabled )
-        return 0;
+    if ( fw_notif_enabled )
+    {
 
-    res = ffa_notification_bitmap_create(ffa_get_vm_id(d), d->max_vcpus);
-    if ( res )
-        return -ENOMEM;
+        res = ffa_notification_bitmap_create(ffa_get_vm_id(d), d->max_vcpus);
+        if ( res )
+            return -ENOMEM;
+    }
 
     return 0;
 }
@@ -447,6 +439,6 @@ void ffa_notif_domain_destroy(struct domain *d)
      * Call bitmap_destroy even if bitmap create failed as the SPMC will
      * return a DENIED error that we will ignore.
      */
-    if ( notif_enabled )
+    if ( fw_notif_enabled )
         ffa_notification_bitmap_destroy(ffa_get_vm_id(d));
 }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:27:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:27:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994273.1377327 (Exim 4.92)
	(envelope-from )
	id 1uI7ot-0004qH-2N; Thu, 22 May 2025 15:26:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994273.1377327; Thu, 22 May 2025 15:26: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 1uI7os-0004qA-Uk; Thu, 22 May 2025 15:26:54 +0000
Received: by outflank-mailman (input) for mailman id 994273;
 Thu, 22 May 2025 15:26:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI7os-0004q4-1t
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:26:54 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2ef3da2f-3721-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:26:51 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-ad51ef2424bso1301331066b.0
 for ; Thu, 22 May 2025 08:26:50 -0700 (PDT)
Received: from [10.0.5.8] ([213.235.133.42]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d498d05sm1106889966b.149.2025.05.22.08.26.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 08:26: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" 
X-Inumbo-ID: 2ef3da2f-3721-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747927610; x=1748532410; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=w3IKMIDfnGzqMyfIXj44a4dok1PV18dQ4mP+tjrajBc=;
        b=IlB6QErKLrACjiwxv3tSDVXS3lWTc2QA9KVDDQB6RYWlnCQa0LAE7O5Gz6KUkQoYxY
         kNmmTbLyqJ1kYYxRd2AO8ukFbEdsLeOLYINjTAJbRw1iqjJLONYzOI3MH2lkR6yKU4F5
         PIoQH7AW+zhGXYTd3n02BQj4XHsKuA7zZyfAUvC8fHVA+c6UPwAsOLio15qep8GGNdhq
         L0BOkGdt9Y2ni0bykFuhB0jZqs/zyO6Rf2YMHKz1lPmT+NY+KK0T44tL/rE6ACz/N7KC
         dgevsEvDc98OmseU6SdfZt/Z81mYpSILzkobD8+tWKumey00dHQMU67TDu2uGceHG0zQ
         sndA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747927610; x=1748532410;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=w3IKMIDfnGzqMyfIXj44a4dok1PV18dQ4mP+tjrajBc=;
        b=wnKcG9wQvsTYjKLIaXIJRrwS8H8lDlBqYOpYReEVkEgDegjoiwqJPXVzqCPaWIMSmC
         oS1HIJuwHmgyEyu0V3zFcNZRp2ETGnvbpmlUDjL+LvLSbQSF176IN15vZEbaWfMWc5Mr
         PgiTK6IxZTcNJvJ87rENOE0+nx8M8An5Wj47/Yja0G6XPxXHRegfq4/8coiJXKpK+Hm9
         2weLr/gSr9IogNlp9ULbfW5OPnhXhZqSeS0ayIxIg6fhxtrRC5F1HMt/VCVeeGd2516z
         cbizSW3N5RsWNqvlJubRN6gCG8m7Q4Y2zGjsBFJIUudARmv1O8iIhANDS4Zh6qf2+V89
         jPKw==
X-Forwarded-Encrypted: i=1; AJvYcCUZUmjHjl/jMrJyVVSKnLPWmfS/msI+/+im/3dzBztr7jAkGvFwIaCkS4uIM/7szgkKg1uPgiC7wwk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyQlhsgVEVtfGv7NlS2/s2wmDnV4NILDVDYA8ScYVdTH0kAwHNJ
	DIevgvXnYH1hduw2m0oepgfEA/EQgYsYiLj/kFoFaYu6NUl/SmrpANjm09hHWh95lA==
X-Gm-Gg: ASbGncsvPZzpdF32OxSbHIxnIL/6+ipk9siBEhHlVs9qS4UQXXgI6ESTX3YRC5MLcy9
	QjyfDHzmHasOacyKB+wn38uNqatILCDrC1jzaIvDMiPd6DVbsHIm8Wyh4BGm6BNgZhiGm8BRBF5
	s1spBLo3buZsP0PE59PdwIhBecMiNvyc6OHd24eA30gsRmL5no3+uobivps0+cT3WGhnCy3ana2
	CbYSaJkxAnySL/k+QyJI/QVacQPn3eRY0bXdULo1y6rcPSIhMR2h9qx3SPf2V1dEr7whtpOAh+A
	bCHTub8Xc/KAn9s4Ndk=
X-Google-Smtp-Source: AGHT+IGjyEHs7fWOD4uwDOriIouD9c4tgfl0GETpwffTGQvJnz6EJnplxTs2+3kVFUkIY3CYmvN00Q==
X-Received: by 2002:a17:907:7f03:b0:ad1:77ae:d18e with SMTP id a640c23a62f3a-ad52d606a59mr2284826766b.56.1747927610403;
        Thu, 22 May 2025 08:26:50 -0700 (PDT)
Message-ID: <058d0610-0f48-4366-b1bc-4e31ecc79084@suse.com>
Date: Thu, 22 May 2025 17:26:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 09/14] xen/riscv: aplic_init() implementation
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/aplic-priv.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/aplic-priv.h
> + *
> + * Private part of aplic.h header.
> + *
> + * RISC-V Advanced Platform-Level Interrupt Controller support
> + *
> + * Copyright (c) Microchip.
> + * Copyright (c) Vates.
> + */
> +
> +#ifndef ASM__RISCV_PRIV_APLIC_H
> +#define ASM__RISCV_PRIV_APLIC_H

Nit: This one conforms to neither prior nor current rules.

> --- a/xen/arch/riscv/aplic.c
> +++ b/xen/arch/riscv/aplic.c
> @@ -9,19 +9,113 @@
>   * Copyright (c) 2024-2025 Vates
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +
> +#include "aplic-priv.h"
>  
>  #include 
> +#include 
>  #include 
> +#include 
> +
> +#define APLIC_DEFAULT_PRIORITY  1
> +
> +/* The maximum number of wired interrupt sources supported by APLIC domain. */
> +#define APLIC_MAX_NUM_WIRED_IRQ_SOURCES 1023

Wait - what's "wired" here? There's only MSI you said elsewhere?

Further - how's this 1023 related to any of the other uses of that number?
Is this by chance ARRAY_SIZE(aplic.regs->sourcecfg)? If so, it wants
expressing like that, to allow making the connection.

> +static struct aplic_priv aplic;
>  
>  static struct intc_info __ro_after_init aplic_info = {
>      .hw_version = INTC_APLIC,
>  };
>  
> +static void __init aplic_init_hw_interrupts(void)
> +{
> +    unsigned int i;
> +
> +    /* Disable all interrupts */
> +    for ( i = 0; i < ARRAY_SIZE(aplic.regs->clrie); i++)
> +        writel(~0U, &aplic.regs->clrie[i]);
> +
> +    /* Set interrupt type and default priority for all interrupts */
> +    for ( i = 0; i < aplic_info.num_irqs; i++ )
> +    {
> +        writel(0, &aplic.regs->sourcecfg[i]);
> +        /*
> +         * 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.
> +         */
> +        writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i]);
> +    }
> +
> +    writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg);
> +}
> +
> +static int __init cf_check aplic_init(void)
> +{
> +    dt_phandle imsic_phandle;
> +    const __be32 *prop;
> +    uint64_t size, paddr;
> +    const struct dt_device_node *imsic_node;
> +    const struct dt_device_node *node = aplic_info.node;
> +    int rc;
> +
> +    /* Check for associated imsic node */
> +    if ( !dt_property_read_u32(node, "msi-parent", &imsic_phandle) )
> +        panic("%s: IDC mode not supported\n", node->full_name);
> +
> +    imsic_node = dt_find_node_by_phandle(imsic_phandle);
> +    if ( !imsic_node )
> +        panic("%s: unable to find IMSIC node\n", node->full_name);
> +
> +    rc = imsic_init(imsic_node);
> +    if ( rc == IRQ_M_EXT )
> +        /* Machine mode imsic node, ignore this aplic node */
> +        return 0;
> +    else if ( rc )

As before: No "else" please when the earlier if() ends in an unconditional
control flow change.

> +        panic("%s: Failded to initialize IMSIC\n", node->full_name);
> +
> +    /* Find out number of interrupt sources */
> +    if ( !dt_property_read_u32(node, "riscv,num-sources",
> +                               &aplic_info.num_irqs) )
> +        panic("%s: failed to get number of interrupt sources\n",
> +              node->full_name);
> +
> +    if ( aplic_info.num_irqs > APLIC_MAX_NUM_WIRED_IRQ_SOURCES )
> +        panic("%s: too big number of riscv,num-source: %u\n",
> +               __func__, aplic_info.num_irqs);

Is it actually necessary to panic() in this case? Can't you just lower
.num_irqs instead (rendering higher IRQs,if any, non-functional)?

> +    prop = dt_get_property(node, "reg", NULL);
> +    dt_get_range(&prop, node, &paddr, &size);
> +    if ( !paddr )
> +        panic("%s: first MMIO resource not found\n", node->full_name);
> +
> +    aplic.paddr_start = paddr;
> +    aplic.size = size;
> +
> +    aplic.regs = ioremap(paddr, size);

Doesn't size need to match certain constraints? If too low, you may
need to panic(), while if too high you may not need to map the entire
range?

Does paddr perhaps also need to match certain contraints, like having
the low so many bits clear?

> +static struct intc_hw_operations __ro_after_init aplic_ops = {
> +    .info                = &aplic_info,
> +    .init                = aplic_init,
> +};

Why's this __ro_after_init and not simply const? I can't spot any write
to it.

> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/aplic.h
> @@ -0,0 +1,64 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * xen/arch/riscv/asm/include/aplic.h
> + *
> + * RISC-V Advanced Platform-Level Interrupt Controller support
> + *
> + * Copyright (c) Microchip.
> + */
> +
> +#ifndef ASM__RISCV__APLIC_H
> +#define ASM__RISCV__APLIC_H

Wants updating again.

> +#include 
> +
> +#include 
> +
> +#define APLIC_DOMAINCFG_IE      BIT(8, UL)
> +#define APLIC_DOMAINCFG_DM      BIT(2, UL)

Why UL when ...

> +struct aplic_regs {
> +    uint32_t domaincfg;

... this is just 32 bits wide?

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 15:32:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:32:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994281.1377337 (Exim 4.92)
	(envelope-from )
	id 1uI7ue-0006cA-M6; Thu, 22 May 2025 15:32:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994281.1377337; Thu, 22 May 2025 15:32: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 1uI7ue-0006c3-J2; Thu, 22 May 2025 15:32:52 +0000
Received: by outflank-mailman (input) for mailman id 994281;
 Thu, 22 May 2025 15:32:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI7uc-0006bs-KU
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:32:50 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2406::61c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 03b33d6c-3722-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 17:32:49 +0200 (CEST)
Received: from SJ0PR13CA0017.namprd13.prod.outlook.com (2603:10b6:a03:2c0::22)
 by DS7PR12MB8203.namprd12.prod.outlook.com (2603:10b6:8:e1::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 15:32:44 +0000
Received: from CO1PEPF000044FD.namprd21.prod.outlook.com
 (2603:10b6:a03:2c0:cafe::f5) by SJ0PR13CA0017.outlook.office365.com
 (2603:10b6:a03:2c0::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.17 via Frontend Transport; Thu,
 22 May 2025 15:32:44 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CO1PEPF000044FD.mail.protection.outlook.com (10.167.241.203) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.4 via Frontend Transport; Thu, 22 May 2025 15:32:43 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 22 May
 2025 10:32:43 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 22 May
 2025 10:32:42 -0500
Received: from [172.26.39.227] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 22 May 2025 10:32: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" 
X-Inumbo-ID: 03b33d6c-3722-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Nl8pkgak3yG0AQAmyXLZ88pqOazsTiaMX0Ga4bvdAqZa/4EZRR4czOaf1bZ+7PJY6qvn6pVtDDl2Uuu5y+nX2/AOA6yl7xIOVNrZBW1W9Vek/C9sJkqDbv+4ODVQjFSoUm5x+Z5xR/yi+TiY58RbooOqjrUCc0XyzPMajpBZPadAe4MnKfyV4GZp2Ow4hySzhDacJBUnRFLS7jS4Q+JW4owrA1zy1IvzQFfvE2ds/nVBlaFu2Qu1mlvLI86AdOCWabSYM+isFQ/ElNmRdXW4xtTqO1HR4BGADdF7VNKKtHEjbqDBJdeceFugmPqGg4cn0pPcQ+eB1S7ufSgT6meGUQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3aTIUxbrNKrFuWYt64pC+6rVE4rT4AH36+tbPlLPOv4=;
 b=TcuCx06uwdM93MHqUzZ5UCJQCqjjiKKDrx78o59iqJhtoQhZWVf47qD428M61OYckAxNqWrPEWT6RnqvEGulDiXTIqsjz7Rw6YXkPcc05QsjNSu5oArKCDiB1hRyk49ZIchfNjTAAM/iefd8slJ9Hg4cBHH88zW3L94Moa52+BXQADgTLxjeiry67GJn2QiUK9tJcveLL6CmKWXZe/x7IbdO+Z/0P5+poF6alA0yrQaPRelz0Wlt/1aBsRc1sp3iAScWIBFRIIzaBPCdR+3dSM7Lc+1qJvTg79vlOGlX3GeInv4DEEFUwjkSORFg2ynxWPvPKAREx6YcEt9+/kKGag==
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=3aTIUxbrNKrFuWYt64pC+6rVE4rT4AH36+tbPlLPOv4=;
 b=Rol3RLkuoDilUWO7S9Il77QJ8tY22j0IMHeowB3uICJqQ5ogYzEYf4/4iaymu2ZYu6vHbu40w+hr7PD8yWmX7CIgnfyPjdVogEINw7SKkYGa49kIZRk2U6WhbJzupM3huSF6eWXIgl4/jt5LOVEt1YfusriUPL2GHRaLU01jbFA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <54324f51-c0f9-4f42-b662-3de5676f1352@amd.com>
Date: Thu, 22 May 2025 11:32:38 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/vpci: refuse to map BARs at position 0
To: Roger Pau Monne , 
CC: Jan Beulich , Andrew Cooper 
References: <20250522140356.5653-1-roger.pau@citrix.com>
 <20250522140356.5653-3-roger.pau@citrix.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <20250522140356.5653-3-roger.pau@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000044FD:EE_|DS7PR12MB8203:EE_
X-MS-Office365-Filtering-Correlation-Id: 8fbd75e9-321f-441b-fe0b-08dd9945e594
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VSsxS1RCdS8rbkg1WlgvdDMrcXZmdGdiOXFQQzhKaHZNY2dFK3dEbUthS045?=
 =?utf-8?B?R3NnMTIyTmdEKzR6a3FPaW54bzQ0S1RQMVhDdlBqV0lZamJ6bk5xSXczZjdI?=
 =?utf-8?B?N0tYOFltWjJla01RNHA2SHJESXkxVU9KbzE2dVBHdmZIcHRvQWw3WGRIbGRj?=
 =?utf-8?B?SkdGN1JrRGtsVUlVTTRzKzlFalpyTFQ0djBFbWxXRHlaUDBFcmZkM3NTTGFq?=
 =?utf-8?B?UmhLVUZoTkxGMTVTeWJNa0dzUllPeU4vVXRlMitwalEyL3RCS2RNZURlNVZI?=
 =?utf-8?B?dEhsR1ZiNHVSOFljdDVkNG52WXZYbUVYUkNrMTZhTWQ2bTFSSERpMi9XNlpo?=
 =?utf-8?B?eHc0K0hwZWw0c21tanBNZEhEcURWQXNjM3dGVUVzSmdrRDV2NHpqN3RkZnVt?=
 =?utf-8?B?QW42V2RGQzFuVnhwazZTcXdnVndDSjhkdlZXamR4aWFUR1NxZ3FMN0pNNzUw?=
 =?utf-8?B?SzVIbW1lWHFvWnUyUy9KQWJDS1k3N29PbEtXdzRSaVJYRE8wNFpJS2Z1d0E5?=
 =?utf-8?B?c243Z1RRc0w3UEtFZGlRZXVtWFdMUUJXQU9qSlR6dzVGNVZwa2Y2RE42SW5l?=
 =?utf-8?B?RUUybmhKN2lQeUx6RW1VYVF4UllYMWdzenFMWnBpdWtBellxMm5JSGZhaUcz?=
 =?utf-8?B?Y01TL1BJQjVpK2diMm1mbUY0YVl0QzRtVlEzSDhxa2pQMWh1QUZoY0FnVXlS?=
 =?utf-8?B?b2ZodEk5bFhHbkpOMDdQei9tU0hhRG1EOVlKeVZXMWJNRW4vVzNPVVlqdXZ4?=
 =?utf-8?B?N0VPNGtOZEFZb0l3eGpCUEpsbzRVaFJRMnMvMXpkNGp1UENBSXRueks1OU10?=
 =?utf-8?B?SkgxWnBTWDZIMlovZlFSNDNCckY0V3pHdmp3YTB3eUQ0YnFpWnd5WHpxbXMw?=
 =?utf-8?B?Nnh0UlRINlZZWURyTWVjaU5mLzJOQllwak56elJvYW9jSTgraThPNEkzemk2?=
 =?utf-8?B?YUxMcDlUUXFJNmEycGM0WnZya21ibnpJNW54cEdqOHkvSEQwZzVialdXWEN0?=
 =?utf-8?B?OHVtaXlHTU54cVFwUXV4L3EzQzArcVJta2o0Q3hkU3RONzJ2WDlOT3Uycmtt?=
 =?utf-8?B?SUlreDJyNS8yVGIwQ09tSTlsVDlZMnI1WVIyZmQySk0wN2JvTGdtSGxRQ0hx?=
 =?utf-8?B?SzNIM1IxZXBzL2Z4aWRKZGVwZ29yWTJMUUdBSldLZGZ6OVRuZXNiaWk5Tm56?=
 =?utf-8?B?WkZLWGZsWE8rWXQ1Rm1LTjJ3bWx3OE1Obmg2RXo4SVBxQjFKTkZZbDlZckhS?=
 =?utf-8?B?Q21RZS9FTWpsdk12NzdxdU94OGN4OHp5UFRpWEIwV1cyK0VzMFBkL2FybjB5?=
 =?utf-8?B?NzdOaGVGWXJYVVJJUGRSQ1hLYWlrTHo4UG1ZRERXeUNDa3FsaWd2T0ZGMVE0?=
 =?utf-8?B?ekNxSlRMTUlBeGE5eFc0ckRxOHovVDVJYkI5MGVSa3BuNXBScEpKUXo1bjhz?=
 =?utf-8?B?ZmZLaUJkcnJ2dDEzeGJFQ1VObUVseHlLY28wNXc5THdRYUNzR2poRmRONExX?=
 =?utf-8?B?NWpJZWgwYnlaRkxIM2xreHVtazFYSURzRXNwYjhjVFZUT2Z6WEc1WTFuVFVo?=
 =?utf-8?B?b1lmSWlLOWQwbEZ1Z0xhV1d2YnE5YUFuZEpLUmVrS2JtUnlPcm9KSG4vUjkx?=
 =?utf-8?B?dEUrMFdWK1RRSW5JZEE3UHI5ZDdtSzdrU1VQOFJYclJsZXVvSjVtZFVXV2pK?=
 =?utf-8?B?SjlOUUllV011RW9GWjk4S2QyODJqeUZNb3BvRjgzUGJHQ216ZjNzTTNXOUZJ?=
 =?utf-8?B?S0lZeVc3RTRHVXlYRVM3dWNIOEsyUVBCdXpxWUZYaHNGOHdtT3d5d01NeUhk?=
 =?utf-8?B?cEUyaHBEOEVRblpiaVNteGdKRGxub2JlZkIvU3lYa1V4bzdPc1VoQnYvcGpj?=
 =?utf-8?B?L2FxSGVHRWdST0FTRUIzeThLMDlJQlRnbmpabTJxczJtbjZzVnFrQmZyNFZ0?=
 =?utf-8?B?YVdiQm9rNm9MY094ZXI1SVJsbGFRR253RzRTT2kyamlkOENibVpDT24rclQ3?=
 =?utf-8?B?K0VIeEhpUVVWYUR1UFZWbDFoSXFqL0tpUGtxNTAwTDI1dkFZOEp2YjNpZC9n?=
 =?utf-8?Q?TayA7Z?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 15:32:43.8556
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8fbd75e9-321f-441b-fe0b-08dd9945e594
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000044FD.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB8203

On 5/22/25 10:03, Roger Pau Monne wrote:
> A BAR at position 0 is not initialized (not positioned).  While Xen could
> attempt to map it into the p2m, marking it as mapped will prevent dom0 to
> change the position of the BAR, as the vPCI code has a shortcomming of not
> allowing to write to BAR registers while the BAR is mapped on the p2m.
> 
> Workaround this limitation by returning false from pci_check_bar() if the
> BAR address is 0, thus causing the bar->enabled field to also be set to
> false and allowing bar_write() to change the BAR position.
> 
> Signed-off-by: Roger Pau Monné 
> ---
>  xen/arch/x86/pci.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
> index 26bb7f6a3c3a..39fd5a16a4aa 100644
> --- a/xen/arch/x86/pci.c
> +++ b/xen/arch/x86/pci.c
> @@ -101,6 +101,15 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
>  
>  bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
>  {
> +    /*
> +     * Refuse to map BARs at position 0, those are not initialized.  This might
> +     * be required by Linux, that can reposition BARs with memory decoding
> +     * enabled.  By returning false here bar->enabled will be set to false, and
> +     * bar_write() will work as expected.
> +     */

Technically speaking, the particular corner case is plausible.

However, if I understand it correctly, when Linux finds an uninitialized
BAR, it checks if the BAR (resource) has been allocated, and won't
enable memory decoding if unallocated. See Linux
drivers/pci/setup-res.c:pci_enable_resources().

So I would consider dropping the "This might be required by Linux"
part from the comment.

> +    if ( mfn_eq(start, _mfn(0)) )
> +        return false;
> +
>      /*
>       * Check if BAR is not overlapping with any memory region defined
>       * in the memory map.



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:32:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:32:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994282.1377347 (Exim 4.92)
	(envelope-from )
	id 1uI7uf-0006pq-TY; Thu, 22 May 2025 15:32:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994282.1377347; Thu, 22 May 2025 15:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uI7uf-0006ph-QV; Thu, 22 May 2025 15:32:53 +0000
Received: by outflank-mailman (input) for mailman id 994282;
 Thu, 22 May 2025 15:32:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI7ue-0006bs-3R
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:32:52 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 05d97bfa-3722-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 17:32:51 +0200 (CEST)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-601a9e65228so4367063a12.2
 for ; Thu, 22 May 2025 08:32:51 -0700 (PDT)
Received: from [10.0.5.8] ([213.235.133.42]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad5b192cb0asm304924066b.170.2025.05.22.08.32.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 08:32: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" 
X-Inumbo-ID: 05d97bfa-3722-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747927971; x=1748532771; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=0ME/8N8eNfh+ICyV22mNqwvI/okvN6ReKjQi2OCzXUE=;
        b=KNGMoLAwlFPPGoGNSdeZaomgkWoWrhWeuVqRv67p7dPnf7WTbYIkN5DLpjaCsRRVJX
         If7yxM/C4QfPZ8oecoaveQDbI7lJq59TaatoeeiBcHIrMTyAWbCDVz4+Sa8d/2/xET5i
         IFP9hP8brLXoIJ0nn/kVIGoTAV8bH1Xk2YI+LmQTnqvmve6ExztJRkdHC226dHSirzye
         MtTLRMLACloVtN5ZR55O+iCR3vkBaqZJft2onN0EbjPu6xeoJHh8JuoTbjcVR87Yjo9k
         tUS5AKeVoG7vHBc8En/k4FEpGFUsjeqiJvQCyB41pHl9cTePSK0UZkAu08steRf6UyuF
         q6Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747927971; x=1748532771;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=0ME/8N8eNfh+ICyV22mNqwvI/okvN6ReKjQi2OCzXUE=;
        b=AxLWzFMUWmuHMP2e+TghAekJ9vzhR04pyki5pQc3AR7BtW79n8xiNSdXYqA3GW7a6Z
         rJimsjGl/OlOvy26ZMjwszRSjmHEUS7snMmswmxZxgGVMMCj81GsisvDy3b+J6/Rzk5N
         cvHqdJcvi4eikIyOeIzSCEXUlTI1yhgauCeHzdDqlM8J2ILS8T1x1RpKO/Taa5NE0AH2
         EM70cYiE8t3vgaEaB99rccfM9f1ZLfN1T9NjqhwYTdhJ9GSyUpL6DtOz1T5wVzpNLn/2
         qfh4S0mjOkhex68yvnvwCNL63iT2TY31zZADk0AQAvkTHmPL0tWlpuh8D67hna0lBakf
         WKcg==
X-Forwarded-Encrypted: i=1; AJvYcCViJxlGbAkleXnhEJoVy3H6vMO9BsKyRVqy/dgOjInv2jfGsDvsOFKAT/5qIHdpJs9Zlx+GUTNuTd0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2wzE02kdWCKofcFehLoyMS38cLMwzqjuLpKweDlW4GBjsZ6RV
	pb35+r8L6nknxWF7AN5UEZxr0c25u1K3PDrRyI8A8IuIV3PqzpDza8wVdp9iv+nKyg==
X-Gm-Gg: ASbGnctPuKFRWlfN73ytX4J108Bbq/9jb1zTOZL38ibyME8VeXFKeEosDHLQ8tCWIoo
	bDnsWxGJzSwCeNeuaqU4/0ZqfWsome8PiUVy/T8n1djgQyjHMIajsrOY/Nkz6Kzxevj84w0WkeA
	ztYk92oheRXOgkcKxqzsLCHPVhOVLDJwbhLrB+EMSXJFcJ72huqVYwZmvaAS1nRdmoiFmEN20mq
	4iMXYNZrJE/2KdsCe7843kY3yqJo6qFMsfhvjKp7w93TGgQYo63I/Yakrg2SL/tb0DvdWX8ymdU
	zjQILMhoOlg5UVR7M9s=
X-Google-Smtp-Source: AGHT+IF5KJzSEoAZGBMzN4YVn4HLrgpsu/UXGRFxbV8KFdrqTxEieKpAflTw74PkmrGxvJwXEIVPIw==
X-Received: by 2002:a17:907:868f:b0:ad5:45d6:5fd5 with SMTP id a640c23a62f3a-ad545d66146mr2238979766b.30.1747927971066;
        Thu, 22 May 2025 08:32:51 -0700 (PDT)
Message-ID: 
Date: Thu, 22 May 2025 17:32:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 10/14] xen/riscv: introduce intc_init() and helpers
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> Introduce intc_init() to initialize the interrupt controller using the
> registered hardware ops.
> Also add intc_route_irq_to_xen() to route IRQs to Xen, with support for
> setting IRQ type and priority via new internal helpers intc_set_irq_type()
> and intc_set_irq_priority().
> 
> Call intc_init() to do basic initialization steps for APLIC and IMSIC.
> 
> Co-developed-by: Romain Caritey 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:44:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:44:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994299.1377356 (Exim 4.92)
	(envelope-from )
	id 1uI85h-0000bN-SJ; Thu, 22 May 2025 15:44:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994299.1377356; Thu, 22 May 2025 15:44: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 1uI85h-0000bG-PQ; Thu, 22 May 2025 15:44:17 +0000
Received: by outflank-mailman (input) for mailman id 994299;
 Thu, 22 May 2025 15:44:16 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI85g-0000b3-Hi
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:44:16 +0000
Received: from mail133-21.atl131.mandrillapp.com
 (mail133-21.atl131.mandrillapp.com [198.2.133.21])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9c83f8b0-3723-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:44:14 +0200 (CEST)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4b3CJX6qRzz1XdCyw
 for ; Thu, 22 May 2025 15:44:12 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 38279da09137419b8047aef6d5d12fd8; Thu, 22 May 2025 15:44: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" 
X-Inumbo-ID: 9c83f8b0-3723-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1747928653; x=1748198653;
	bh=lcpqq7hcTnh6r+A62ErUkxcMa+qXDJULjg3m1WtVDKM=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=0iPymMPIzqRJsa71/OuRtBaHy1DN3sNKT+IdUlxzvqOl50fqlbr6QgYVQCai0Gx7u
	 uAYTdKdn4WFFSvOcjSEkK01p3hqxkkP1HWv4kLuIpxZ6pqkQVq+cwmJZo2sC8wI6P3
	 LfTHSIR4bMRf1guw6yGIGT5/Li1xhe1tPLluq8M600qjI8xDTv/HgyTxhyjoCLKQWV
	 NDRLWnSPcAl7AZCm+RvTIBLJHZPZ9zJ+apYAIxNzcQl8LAIVNqaL0qZmlp43v7+vSk
	 th+fw+Oi4r+qItTXM32fobFjzS0737J66McCikD0Zv9hVN5zWrnkO7ccdzRmcg30fw
	 BiBp6EJ5ewczw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1747928652; x=1748189152; i=teddy.astie@vates.tech;
	bh=lcpqq7hcTnh6r+A62ErUkxcMa+qXDJULjg3m1WtVDKM=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=MdqrghRHvWqcWqM5FoQyPUocKdfxirgj/Z9T8u9hQyaBhfOoh3FJhKhfFUZbwKGqS
	 zqaq7FIH8+Qdwc60hyVa4Emv7+liMqBjpNoOMcsWlXcdQVqq8SNWfYK45wUF6lIIbO
	 49IaR/Iw+Te1MIsc1zJTqi8PSFsUGN25p1ufJARV9c7+uVWVJztA3aOm2oN1A+wiGC
	 KrC1lSkebfBvodiYS4t6m+452zro2LT/1fyNIZ9vSImNVNeivwljx6bE0HSUqrgamv
	 XkAtLPiUdaS2fmu7RL+FgPohGFnSyv4mTZE7920OUuM7qq9w11Ab4TRi6qObeBMk6L
	 qJiKykmzfyz+Q==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[PATCH]=20iommu/amd:=20Remove=20dead=20non-atomic=20update=20checking?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1747928651689
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Message-Id: <761f464ae56a449291e38724a1f823606f3ba9d0.1747924653.git.teddy.astie@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.38279da09137419b8047aef6d5d12fd8?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250522:md
Date: Thu, 22 May 2025 15:44:12 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

When updating a DTE, amd_iommu_setup_domain_device checks if the update had been
non-atomic (i.e rc > 0) and eventually throws a warning but since [1], rc can
no longer be positive, making this check never taken.

[1] x86/iommu: remove non-CX16 logic from DMA remapping
    https://gitlab.com/xen-project/xen/-/commit/3fc44151d83d3d63320036bcf06634dfbebe1ff3

Signed-off-by: Teddy Astie 
---
 xen/drivers/passthrough/amd/iommu_map.c     |  4 +---
 xen/drivers/passthrough/amd/pci_amd_iommu.c | 18 ------------------
 2 files changed, 1 insertion(+), 21 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_map.c b/xen/drivers/passthrough/amd/iommu_map.c
index dde393645a..07f405ed63 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -157,9 +157,7 @@ static void set_iommu_ptes_present(unsigned long pt_mfn,
 /*
  * This function returns
  * - -errno for errors,
- * - 0 for a successful update, atomic when necessary
- * - 1 for a successful but non-atomic update, which may need to be warned
- *   about by the caller.
+ * - 0 for a successful update
  */
 int amd_iommu_set_root_page_table(struct amd_iommu_dte *dte,
                                   uint64_t root_ptr, uint16_t domain_id,
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index d00697edb3..409752ffc8 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -225,24 +225,6 @@ static int __must_check amd_iommu_setup_domain_device(
             spin_unlock_irqrestore(&iommu->lock, flags);
             return rc;
         }
-        if ( rc &&
-             domain != pdev->domain &&
-             /*
-              * By non-atomically updating the DTE's domain ID field last,
-              * during a short window in time TLB entries with the old domain
-              * ID but the new page tables may have been inserted.  This could
-              * affect I/O of other devices using this same (old) domain ID.
-              * Such updating therefore is not a problem if this was the only
-              * device associated with the old domain ID.  Diverting I/O of any
-              * of a dying domain's devices to the quarantine page tables is
-              * intended anyway.
-              */
-             !pdev->domain->is_dying &&
-             pdev->domain != dom_io &&
-             (any_pdev_behind_iommu(pdev->domain, pdev, iommu) ||
-              pdev->phantom_stride) )
-            AMD_IOMMU_WARN(" %pp: reassignment may cause %pd data corruption\n",
-                           &PCI_SBDF(pdev->seg, bus, devfn), pdev->domain);
 
         /*
          * Check remaining settings are still in place from an earlier call
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Thu May 22 15:44:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:44:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994309.1377367 (Exim 4.92)
	(envelope-from )
	id 1uI863-0000zf-6f; Thu, 22 May 2025 15:44:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994309.1377367; Thu, 22 May 2025 15: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 1uI863-0000zY-3u; Thu, 22 May 2025 15:44:39 +0000
Received: by outflank-mailman (input) for mailman id 994309;
 Thu, 22 May 2025 15:44:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI862-0000b3-8q
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:44:38 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20607.outbound.protection.outlook.com
 [2a01:111:f403:240a::607])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a8c96a08-3723-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:44:36 +0200 (CEST)
Received: from SJ0P220CA0005.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:41b::12)
 by MN2PR12MB4335.namprd12.prod.outlook.com (2603:10b6:208:1d4::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 22 May
 2025 15:44:31 +0000
Received: from SJ1PEPF00001CE4.namprd03.prod.outlook.com
 (2603:10b6:a03:41b:cafe::39) by SJ0P220CA0005.outlook.office365.com
 (2603:10b6:a03:41b::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu,
 22 May 2025 15:44:29 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ1PEPF00001CE4.mail.protection.outlook.com (10.167.242.20) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Thu, 22 May 2025 15:44:29 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 22 May
 2025 10:44:28 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 22 May
 2025 10:44:28 -0500
Received: from [172.26.39.227] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 22 May 2025 10:44: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" 
X-Inumbo-ID: a8c96a08-3723-11f0-b892-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=oI5G+pclb17yxaM7baF4BXrqsKu8kG54J+GaR8NnGWw4wVggHDmWVyuH2avKv1NMN9F9XbE5TJPOewhKztskCuuNemnSiNEe1BIE4xMjJHVQAQioYdl+juxeKrHj+aXOL3zOi1BQVkHUtVqpDBrpvTkJl1HjwpHTo9/EjjmV7ViUE7s54VCFYRZ4XC3KFyblGgSudcEITilhmQUh4aIgUaBOT34e/0UDhLiaKFAG3utLbddRnw/2Zxh1bNqIZUJL9dpOlUHrD9oppj9uWvu0MS2LbaQJm/D8Xat2HtEVpteSo3Z9xd/DJWQxQoiI31wKuy4DE4FLISTbOS7JhM0A5g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=eHwft3HEcPANxL9VLsIeuPPFsrYsAWz/qnq5FcH6Eko=;
 b=RnXONPhKj3EaEA1DTn/ToQrN82dr4UrU10BP80mgdz+seI0sx2tCBEk22Bg+da8/mJXaehwanUIMoPZu/SjCm9mHQKsLE/S5MZgk3TVuyeC5LmQen6EDPk8kVyD8LN3srRJKbSz0XLM1xSD+vBCp4GeCkXLk3aBppDvJndd7zLwuODZFIMz6zg78S1Q4tAPvTDMaZkHsme1DTgM5083ZO/CaZQmm8TAxjoZrQs6M+Ig/6Xj84oVy4GLRCE7sqMLbtXUW+n4Yg+GXtSukHLRAaQ2VOSwRHl2hJFofIzSu4hi75l+ThoPAvgpsLAyGGeWm56sqIPmrUaWTpd/he7RwPg==
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=eHwft3HEcPANxL9VLsIeuPPFsrYsAWz/qnq5FcH6Eko=;
 b=mcjkgi4Sv6tV/xFO54SpRflqq0dCgHW7XA+tErMwwUKkTW4TAsDxsMOQY7tZkYmogRwTVlTDWnYF/Zur4VcHu8/TTDbG1lgcXb6KtHazE30jg1gIthkkqmuN55rfTK23W7m8uw/Ad7vvJeePfnJ3yn/XYOH8SZYbaM4kUhH9Rug=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Thu, 22 May 2025 11:44:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] x86/vpci: refuse to map BARs at position 0
To: Jan Beulich , Roger Pau Monne 
CC: Andrew Cooper ,
	
References: <20250522140356.5653-1-roger.pau@citrix.com>
 <20250522140356.5653-3-roger.pau@citrix.com>
 <3f274948-92bb-40c4-bcaf-7b538300140a@suse.com>
Content-Language: en-US
From: Stewart Hildebrand 
In-Reply-To: <3f274948-92bb-40c4-bcaf-7b538300140a@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CE4:EE_|MN2PR12MB4335:EE_
X-MS-Office365-Filtering-Correlation-Id: df10256d-ac82-49f2-fc1b-08dd99478a3e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZzBsOVV0RXRLcEtSR1ZmSGMzRjkxOEREL1plUHpsZXhMUDBYSXM1ZWVtL1di?=
 =?utf-8?B?T2V1OStFeW01SzNtdlhDRnRvUW0vMHRiSGp4VmZzenJmdkxVU3h4TVFCUDlr?=
 =?utf-8?B?OVNUUXp3Tzh6eHR1S0pWUTZxMDhvZUhpbWlYT0xGMU5kOGJsUVh0VU5zRUg1?=
 =?utf-8?B?NjJINStjeEpyakVsL0F2MlAranlGWTNYRFpkeCtwWHVpSTFGZzRFekdQUW56?=
 =?utf-8?B?NDRIK0QzcSszQ0svV1VoQzZTS0ROMytZUE1uUCtRbUJ4a2hlNFMzMkdTbnUz?=
 =?utf-8?B?SGxSbHNBbEg5OTJ6MHh4d3ZKeFo4N1pkeE9SL25rSUw2QmhQQ2ZmQWlseVln?=
 =?utf-8?B?eERlQlpyZTVHT2ZzZU1VUG55L0hyTktiMlJlMWNnTTFrWFpKN3ZhTXRiM2RH?=
 =?utf-8?B?U2tQOEY2cEg0M240OGRTUG9kRzQzRTVGTGkwc0pZMHcrN0w1b2JYRzYySG9M?=
 =?utf-8?B?MUw5TFJIangyMjh6aGpYaGhOQ2x4czN1SnNCeWQ4U21Ja2N4V3pkSm9BSnQ5?=
 =?utf-8?B?RjNUNEw3ZllFS28renlsK1FKUE1VWXo1T1Z6MGhRWEw4N2F4V2NVdGlvWFVv?=
 =?utf-8?B?VzgzN0llTEtscytsWlBXZ1lPU0xldFBIYlVEWVFRWDAySm1ZcDlHVnN1M3pj?=
 =?utf-8?B?eVNlVUdSSnZMQ256cUpZVU5FTXVnTUV4VGYwZmpid2hqVHN6Z0VMYUVUM2VR?=
 =?utf-8?B?T2pxR1J3akNZQTlLcUxvS25jUWRBSlc4eHR1Q3hHN1MxUlY4MVV1VVpra1Fv?=
 =?utf-8?B?R1g3WHNZemNUQlhRVmRENVY5STJJMzM0bmxoK09LK3F6OVJTL3RQWEIxeEFI?=
 =?utf-8?B?RU1XU3lySGRvSzNxZ3ZPUHZlQXZjU2szV2VueWRiVlozaCttRnVRa1VXeE9p?=
 =?utf-8?B?dm9LU2JZR3puSHRuc0lNVC9ndVJqYnU4OTlvYlRaM2NoeVp6c25uakp6M0xr?=
 =?utf-8?B?MXRta1M5S3p5Z0plZnV2KzJOclBqRDZqOFpaSUROaEpSSlhyaE1NNVJzdVhV?=
 =?utf-8?B?SGVYQmxoU3h1UFpDZjRCUUdIZnh4S3VHN2JRa3V3elBHYlRHY3Jxd25CVFV4?=
 =?utf-8?B?MmpobEtuZ0YrWk5XdERLVVZyMHA3MUYxWk1hVkJLRXpEOFg5di8yUUxMbGtx?=
 =?utf-8?B?cWdkSk94U0xHdk5neVdiMWhjUHV4cE4xNkR3dXhJcnZBTy9RMGo0QW52djc0?=
 =?utf-8?B?Wm1zK2VpbUZhemUrUisyMVRDS0FMSXJzM29oT0lacUR5aGl4anp2V3d1Qmhj?=
 =?utf-8?B?VWwzTWhOZlVxM2J2bVZYSkp3eTB4WllFMC9ncnQxZzJtTDhvejFYczVsZ0c4?=
 =?utf-8?B?emtiL2VZb3pGbFMzT0p0UjB1SG1JcjBGZjRCWkJ3cENDMVc0WnZHQlZzbC9J?=
 =?utf-8?B?bXFQaExZMGwrZFZBUWlqdm9HWmU2OVV4eVMzMFpjKzVPTEh4YTlHUm1Nd1c1?=
 =?utf-8?B?eEpaQ3Q3L0dQWExNbkxRMVdxS2tTMmttb0pScW5RS3Avb1pqMjJqcVZTdlBx?=
 =?utf-8?B?V0x1YlFmbVJVU3NWQyt6UWZycjlta3Jta3U4dzhjUjFFRzdMMnV6dnVjRHZJ?=
 =?utf-8?B?S0J6TEY0USs0MjErTWRnNEU5bFBkb3VpU1FJTW4vd2VBcGRxeWpkRWQwVmQ4?=
 =?utf-8?B?a2FxYy8zRDlRSFB5eEVHTVM3Rmd2Z1JVWTQyN2VXT3h6eHRVQ004QkpXcjFL?=
 =?utf-8?B?ZWEwdHV1THR2bVZEOFdGQ2MxOG5MZHo4V2xGU1FwRVRJdUpRZUI4OFdic0VV?=
 =?utf-8?B?SERhZjUxVUs5U05FQ2hBQmZPU3JnUjFrYU12L05YTzJLKzhnam1hc1JvUXJy?=
 =?utf-8?B?L2J5aG1VNWc1N052SUVRU2lJbWpta1hYamNZR0VreXRKUW1la2ZNL3FSSjBW?=
 =?utf-8?B?aWp6VGtvV0o5ekdqSnRMcFdkUms2UlRaUW5vSkk0ZDZSTWVJZy9GbTN5TGlH?=
 =?utf-8?B?dHNsY0hramwvMzlkYUtqNDF0K2xLWWxCalF6cWNaZ0xTMjJkMllERHBMRU5H?=
 =?utf-8?B?QThZckMwZ1VmbWtzSjdwSHd5cWpLQm54UFc5K3dJVU5ENHhpSXFhRllIc3V2?=
 =?utf-8?Q?4tok99?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2025 15:44:29.6315
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: df10256d-ac82-49f2-fc1b-08dd99478a3e
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00001CE4.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4335

On 5/22/25 10:59, Jan Beulich wrote:
> On 22.05.2025 16:03, Roger Pau Monne wrote:
>> diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
>> index 26bb7f6a3c3a..39fd5a16a4aa 100644
>> --- a/xen/arch/x86/pci.c
>> +++ b/xen/arch/x86/pci.c
>> @@ -101,6 +101,15 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
>>  
>>  bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
>>  {
>> +    /*
>> +     * Refuse to map BARs at position 0, those are not initialized.  This might
>> +     * be required by Linux, that can reposition BARs with memory decoding
>> +     * enabled.  By returning false here bar->enabled will be set to false, and
>> +     * bar_write() will work as expected.
>> +     */
>> +    if ( mfn_eq(start, _mfn(0)) )
>> +        return false;
> 
> Is this really x86-specific?

No, I think Arm would benefit from this check too. I'm in favor of
moving the check to common.


From xen-devel-bounces@lists.xenproject.org Thu May 22 15:53:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:53:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994339.1377378 (Exim 4.92)
	(envelope-from )
	id 1uI8Ed-00035p-2s; Thu, 22 May 2025 15:53:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994339.1377378; Thu, 22 May 2025 15:53: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 1uI8Ec-00035i-Uh; Thu, 22 May 2025 15:53:30 +0000
Received: by outflank-mailman (input) for mailman id 994339;
 Thu, 22 May 2025 15:53:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI8Eb-00035V-Iy
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:53:29 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e71268c5-3724-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 17:53:28 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5f3f04b5dbcso12371956a12.1
 for ; Thu, 22 May 2025 08:53:28 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d490789sm1100706166b.130.2025.05.22.08.53.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 08:53: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" 
X-Inumbo-ID: e71268c5-3724-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747929208; x=1748534008; darn=lists.xenproject.org;
        h=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;
        bh=5T+4F+BevpbyJhSD1mtoloF5rTRkKw3a00s5qodp4XQ=;
        b=e1YYaZqg1y0ec+DYmQgCjORPesENJ94Hy3y7gIUh7tiuyq9JaZoc2RwIB9P7lDuGeW
         Xn4nYvGiTuUbsr4hna2g6Otgo1Ecwf0wNuW0uFiSquJRYlTZDvaj49wtRz0Oj8B/ZI7z
         qOIDK5dwHxFK3/+KkJPDrH3r+PBDfgIxvsXjzUpTXkR9es/F1VGYu1u2mlro5S+7VTRD
         WmTBkT2eiTCdwhWyaLN/RtI4R+swotd5iWuholKc1DyD16MmjLyVygz9qh0iehZpm9b6
         Qfq+yf3A0yqzCW/+XtzYQ8Avyt+dYQmlGxxLVUBURNBXLRkSBM5seJ3bj7685AtirLm6
         OCSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747929208; x=1748534008;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=5T+4F+BevpbyJhSD1mtoloF5rTRkKw3a00s5qodp4XQ=;
        b=ftffQs8J0tvZxcdR1RDtowP5cAGUkTPJWhA8TTfZnLq7HwdU68IPtBi3+ttAO0RXoW
         J+d1zJlzCPysQ5lsmIQ7HGhqei9IFonWjWhrULUtd0wud4T1wB7CaOtIhvh4Km4/5Lbv
         AlqYeNHWBiKmRNE3TWwqFsCqcxXvU12MYAZMBtFHsCR9Xu2iE+VGGnanI8hrScIq1Yyp
         72ETpe57pbUoKOYxhjgmqUCxPwSL5Ue9YbbsOic5PtoiOlVplk6j6NnjqRpZvWbWOfLx
         vU3ZZpwi2jac2n8kvNAw0GWvtG5nuqfCXThL07FTEXjFJdVc65PXQp6TgkatsOTrFNKT
         hcmA==
X-Forwarded-Encrypted: i=1; AJvYcCWis5VDab0oXQU2ydSB6/4lEn1dvDZSO7G068FgEV0VFRscetrslVrdKFDivVWox/N3Xmj4gEoTNc4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyJErpVHdKKv6nmDJ3KtjLct/CtEi+Jx4dsgZKo3fd9XuFwuB0W
	lGKWAkAd9GP9XZEf2z5oPRiVnAcE0bXlBwrzffYBzdgR+MU+WqQHwS0om6hR0A==
X-Gm-Gg: ASbGnctwhR6mdjF+D3DcvYJS85XJP+9avsCwBf7wNZfSlIzOMNz7U7BjNVTG+NVH4a6
	b9yYPoaBZyQ1PL5nCgE2hAKmfKBrFtxg3HGpVfQcm+B811g5nRpNoxl1JvHvd1ANZyLgLPyrCuE
	spBpBKs/MLJCKwq9fop/5N6QbZHRRNRWm300MvefF97l8ODM6KFqM0izJpd981mH9SjsfMIk/nx
	tojDsaA0Goqqchfworh2woTMTR0A6LDNxW+TzzkxPAs5BCQgHJoGG8FDfsyoquCiiyFQEqdnK1r
	dqK/H+KKVaZNgVtJPC8l0TFRV4ODFixQaj7Olq6xHjQRQoXcEt+5pMdg69gsEuMPVXvYN7nEYc7
	QG1nOBOdcBdhrp3RNWBhFxkjc
X-Google-Smtp-Source: AGHT+IEzLqx0c2jzSPB3oPprrg/78sOFFSOnsIbNJSEekqqr6YSuKCIBx0eVnPV3oImdCGAryd4WUg==
X-Received: by 2002:a17:907:c29:b0:ad5:4923:a024 with SMTP id a640c23a62f3a-ad54923a173mr2198525566b.16.1747929207286;
        Thu, 22 May 2025 08:53:27 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------nN0PHet1fX3NuT67iu0u457E"
Message-ID: <1a0d3084-9e77-4df5-936a-c1a1317c0f18@gmail.com>
Date: Thu, 22 May 2025 17:53:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m
 initialization
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
 <7ef3ca26-05f5-4e86-b7c7-852b6c74a3d0@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <7ef3ca26-05f5-4e86-b7c7-852b6c74a3d0@suse.com>

This is a multi-part message in MIME format.
--------------nN0PHet1fX3NuT67iu0u457E
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/20/25 3:37 PM, Jan Beulich wrote:
> On 09.05.2025 17:57, Oleksii Kurochko wrote:
>> --- /dev/null
>> +++ b/xen/arch/riscv/p2m.c
>> +static void clear_and_clean_page(struct page_info *page)
>> +{
>> +    void *p = __map_domain_page(page);
>> +
>> +    clear_page(p);
>> +    unmap_domain_page(p);
>> +}
> What's the "clean" about in the function name? The "clear" is referring
> to the clear_page() call afaict.

Missed to add clean_dcache_va_range() between clear_page() and unmap_domain_page().

> Also aren't you largely open-coding
> clear_domain_page() here?

Yes, missed that it is almost the sane as clear_domain_page(), so we could re-write
this function as:
   static void clear_and_clean_page(struct page_info *page)
   {
       clean_dcache_va_range(page, PAGE_SIZE);
       clear_domain_page(page_to_mfn(page));
   }

>> +static struct page_info *p2m_get_clean_page(struct domain *d)
>> +{
>> +    struct page_info *page;
>> +
>> +    /*
>> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
>> +     * As explained in Section 18.5.1, for the paged virtual-memory schemes
>> +     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
>> +     * and must be aligned to a 16-KiB boundary.
>> +     */
>> +    page = alloc_domheap_pages(NULL, 2, 0);
> Shouldn't this allocation come from the domain's P2M pool (which is yet
> to be introduced)?

First, I will drop p2m_get_clean_page() as it will be used only for p2m root page
table allocation.

p2m_init() is called by domain_create() [->arch_domain_create()->p2m_init()] from create_domUs():
[https://gitlab.com/xen-project/xen/-/blob/staging/xen/common/device-tree/dom0less-build.c?ref_type=heads#L984].

When p2m_init() is called, p2m pool isn't ready and domain isn't created yet. Last one
is also crucial for usage of p2m pool as p2m pool belongs to domain and thereby it is
using alloc_domheap_page(d, ...) (Not NULL as for allocation of p2m root table above),
so domain should be created first.

And only after domain_create() will created domain, p2m pool could be initialized during
domain construction:
   https://gitlab.com/xen-project/xen/-/blob/staging/xen/common/device-tree/dom0less-build.c?ref_type=heads#L756
and the size of p2m pool depends on the value from memory property of domain node in DT.
(line 748, the link the same as above).

Also, if CONFIG_ARCH_PAGING_MEMPOOL=n, then p2m pool isn't used. But it isn't a case for RISC-V
for the moment. Probably one day it would be useful if someone wanted to add support for MMU-less
case. Something like Arm is doing now for R-cores.

> Also hard-coding 2 here as order effectively builds
> in an assumption that PAGE_SIZE will only ever be 4k. I think to wants
> properly calculating instead.

I haven't thought about that. I will update it with:
   page = alloc_domheap_pages(NULL, get_order_from_bytes(KB(16)), 0);

>
>> +    if ( page == NULL )
>> +        return NULL;
>> +
>> +    clear_and_clean_page(page);
>> +
>> +    return page;
>> +}
> Contrary to the function name you obtained 4 pages here, which is suitable
> for ...
>
>> +static struct page_info *p2m_allocate_root(struct domain *d)
>> +{
>> +    return p2m_get_clean_page(d);
>> +}
> ... this but - I expect - no anywhere else.

Totally agree, as mentioned above this function is used only for p2m_allocate_root().
I will just open-code it in p2m_allocate_root().

>> +{
>> +    unsigned long ppn;
>> +    unsigned long hgatp_mode;
>> +
>> +    ppn = PFN_DOWN(page_to_maddr(page_info)) & HGATP_PPN;
>> +
>> +    /* ASID (VMID) not supported yet */
>> +
>> +#if RV_STAGE1_MODE == SATP_MODE_SV39
>> +    hgatp_mode = HGATP_MODE_SV39X4;
>> +#elif RV_STAGE1_MODE == SATP_MODE_SV48
>> +    hgatp_mode = HGATP_MODE_SV48X4;
>> +#else
>> +    #error "add HGATP_MODE"
> As before, please have the # of pre-processor directives in the first column.
>
>> +#endif
>> +
>> +    return ppn | (hgatp_mode << HGATP_MODE_SHIFT);
> Use MASK_INSR()?

Do you mean MASK_INSR(hgatp_mode, HGATP_MODE_MASK)?
If yes, then I didn't get what is the point then?

>
>> +}
>> +
>> +static int p2m_alloc_table(struct domain *d)
>> +{
>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +
>> +    p2m->root = p2m_allocate_root(d);
>> +    if ( !p2m->root )
>> +        return -ENOMEM;
>> +
>> +    p2m->hgatp = hgatp_from_page_info(p2m->root);
>> +
>> +    /*
>> +     * Make sure that all TLBs corresponding to the new VMID are flushed
>> +     * before using it.
>> +     */
>> +    p2m_write_lock(p2m);
>> +    p2m_force_tlb_flush_sync(p2m);
>> +    p2m_write_unlock(p2m);
> While Andrew directed you towards a better model in general, it won't be
> usable here then, as the guest didn't run on any pCPU(s) yet. Imo you
> want to do a single global flush e.g. when VMIDs wrap around. That'll be
> fewer global flushes than one per VM creation.

I am not sure that I get a phrase 'VMIDs wrap around'.

I am going to implement, p2m_force_tlb_flush_sync() as:
  static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
  {
    ...
      sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0);
    ...
  }

With such implementation if the guest didn't run on any pCPU(s) yet
then d->dirty_cpumask is empty, then sbi_remote_hfence_gvma() will do nothing
as hmask will be NULL (https://gitlab.com/xen-project/people/olkur/xen/-/blob/staging/xen/arch/riscv/sbi.c?ref_type=heads#L238).
I am not sure that it is a good idea as I can't find a guarantee in the spec
that TLB will be empty during boot time.

But if another VM is being created then we should flush stage2 before run a VM
so, the new VM won't re-use something from the old VM.
Or in case of VMID if VMID is reused by new VM in case if, for example, the
previous owner(domain) was destroyed and a new domain is reusing VMID, it is
needed to flush stage2.

p2m_alloc_table() looks a good place for that and I am not sure that we can
do a single global flush, and I don't really know in first glance where it
should be done.


>> +    p2m->default_access = p2m_access_rwx;
>> +
>> +    radix_tree_init(&p2m->p2m_type);
>> +
>> +#ifdef CONFIG_HAS_PASSTHROUGH
>> +    /*
>> +     * Some IOMMUs don't support coherent PT walk. When the p2m is
>> +     * shared with the CPU, Xen has to make sure that the PT changes have
>> +     * reached the memory
>> +     */
>> +    p2m->clean_pte = is_iommu_enabled(d) &&
>> +        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
>> +#else
>> +    p2m->clean_pte = true;
> When there's no IOMMU (in use), doesn't this want to be "false"?

I think you are right, "false" is more correct here.

>
>> +#endif
>> +
>> +    /*
>> +     * "Trivial" initialisation is now complete.  Set the backpointer so
>> +     * p2m_teardown() and friends know to do something.
>> +     */
>> +    p2m->domain = d;
> And where is that p2m_teardown(), to cross-check the comment against?

It is not introduced now as I expected it is need only when domain is needed to
be stop for some reason. And it isn't really needed now.

Anyway, it seems like it is a stale comment as on other arch-es p2m_teardown() has
an argument with struct domain *d.

I can update the commit to:
  "Trivial" initialisation is now complete.  Set the backpointer so the users of p2m
   could get an access to domain structure.

~ Oleksii

--------------nN0PHet1fX3NuT67iu0u457E
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/20/25 3:37 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 09.05.2025 17:57, Oleksii Kurochko wrote:

    
      
    
        
    --- /dev/null
+++ b/xen/arch/riscv/p2m.c
+static void clear_and_clean_page(struct page_info *page)
+{
+    void *p = __map_domain_page(page);
+
+    clear_page(p);
+    unmap_domain_page(p);
+}

    
      
    
    
    
    
    
      
    What's the "clean" about in the function name? The "clear" is referring
to the clear_page() call afaict.
    
    
    
    
    Missed to add clean_dcache_va_range() between clear_page() and unmap_domain_page().

    
    
    
      
    Also aren't you largely open-coding
clear_domain_page() here?
    
    
    
    
    Yes, missed that it is almost the sane as clear_domain_page(), so we could re-write
this function as:
  static void clear_and_clean_page(struct page_info *page)
  {
      clean_dcache_va_range(page, PAGE_SIZE);
      clear_domain_page(page_to_mfn(page));
  }


    
    
    
      
    
        
    +static struct page_info *p2m_get_clean_page(struct domain *d)
+{
+    struct page_info *page;
+
+    /*
+     * As mentioned in the Priviliged Architecture Spec (version 20240411)
+     * As explained in Section 18.5.1, for the paged virtual-memory schemes
+     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
+     * and must be aligned to a 16-KiB boundary.
+     */
+    page = alloc_domheap_pages(NULL, 2, 0);

    
      
    
      
    Shouldn't this allocation come from the domain's P2M pool (which is yet
to be introduced)? 
    
    
    
    
    First, I will drop p2m_get_clean_page() as it will be used only for p2m root page
table allocation.

p2m_init() is called by domain_create() [->arch_domain_create()->p2m_init()] from create_domUs():
[https://gitlab.com/xen-project/xen/-/blob/staging/xen/common/device-tree/dom0less-build.c?ref_type=heads#L984].

When p2m_init() is called, p2m pool isn't ready and domain isn't created yet. Last one
is also crucial for usage of p2m pool as p2m pool belongs to domain and thereby it is
using alloc_domheap_page(d, ...) (Not NULL as for allocation of p2m root table above),
so domain should be created first.

And only after domain_create() will created domain, p2m pool could be initialized during
domain construction:
  https://gitlab.com/xen-project/xen/-/blob/staging/xen/common/device-tree/dom0less-build.c?ref_type=heads#L756
and the size of p2m pool depends on the value from memory property of domain node in DT.
(line 748, the link the same as above).

Also, if CONFIG_ARCH_PAGING_MEMPOOL=n, then p2m pool isn't used. But it isn't a case for RISC-V
for the moment. Probably one day it would be useful if someone wanted to add support for MMU-less
case. Something like Arm is doing now for R-cores.


    
    
    
      
    Also hard-coding 2 here as order effectively builds
in an assumption that PAGE_SIZE will only ever be 4k. I think to wants
properly calculating instead.
    
    
    
    
    I haven't thought about that. I will update it with:
  page = alloc_domheap_pages(NULL, get_order_from_bytes(KB(16)), 0);


    
    
    
      
    

    
      
    
        
    +    if ( page == NULL )
+        return NULL;
+
+    clear_and_clean_page(page);
+
+    return page;
+}

    
      
    
      
    Contrary to the function name you obtained 4 pages here, which is suitable
for ...


    
      
    
        
    +static struct page_info *p2m_allocate_root(struct domain *d)
+{
+    return p2m_get_clean_page(d);
+}

    
      
    
      
    ... this but - I expect - no anywhere else.
    
    
    
    
    Totally agree, as mentioned above this function is used only for p2m_allocate_root().
I will just open-code it in p2m_allocate_root().
    
    
    
      
    
        
    +{
+    unsigned long ppn;
+    unsigned long hgatp_mode;
+
+    ppn = PFN_DOWN(page_to_maddr(page_info)) & HGATP_PPN;
+
+    /* ASID (VMID) not supported yet */
+
+#if RV_STAGE1_MODE == SATP_MODE_SV39
+    hgatp_mode = HGATP_MODE_SV39X4;
+#elif RV_STAGE1_MODE == SATP_MODE_SV48
+    hgatp_mode = HGATP_MODE_SV48X4;
+#else
+    #error "add HGATP_MODE"

    
      
    
      
    As before, please have the # of pre-processor directives in the first column.


    
      
    
        
    +#endif
+
+    return ppn | (hgatp_mode << HGATP_MODE_SHIFT);

    
      
    
      
    Use MASK_INSR()?
    
    
    
    
    Do you mean MASK_INSR(hgatp_mode, HGATP_MODE_MASK)?
If yes, then I didn't get what is the point then?


    
    
    
      
    

    
      
    
        
    +}
+
+static int p2m_alloc_table(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    p2m->root = p2m_allocate_root(d);
+    if ( !p2m->root )
+        return -ENOMEM;
+
+    p2m->hgatp = hgatp_from_page_info(p2m->root);
+
+    /*
+     * Make sure that all TLBs corresponding to the new VMID are flushed
+     * before using it.
+     */
+    p2m_write_lock(p2m);
+    p2m_force_tlb_flush_sync(p2m);
+    p2m_write_unlock(p2m);

    
      
    
      
    While Andrew directed you towards a better model in general, it won't be
usable here then, as the guest didn't run on any pCPU(s) yet. Imo you
want to do a single global flush e.g. when VMIDs wrap around. That'll be
fewer global flushes than one per VM creation.
    
    
    
    
    I am not sure that I get a phrase 'VMIDs wrap around'.

I am going to implement, p2m_force_tlb_flush_sync() as:
 static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
 {
   ...
     sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0);
   ...
 }

With such implementation if the guest didn't run on any pCPU(s) yet
then d->dirty_cpumask is empty, then sbi_remote_hfence_gvma() will do nothing
as hmask will be NULL (https://gitlab.com/xen-project/people/olkur/xen/-/blob/staging/xen/arch/riscv/sbi.c?ref_type=heads#L238).
I am not sure that it is a good idea as I can't find a guarantee in the spec
that TLB will be empty during boot time.

But if another VM is being created then we should flush stage2 before run a VM
so, the new VM won't re-use something from the old VM.
Or in case of VMID if VMID is reused by new VM in case if, for example, the
previous owner(domain) was destroyed and a new domain is reusing VMID, it is
needed to flush stage2.

p2m_alloc_table() looks a good place for that and I am not sure that we can
do a single global flush, and I don't really know in first glance where it
should be done.



    
    
    
      
    
        
    +    p2m->default_access = p2m_access_rwx;
+
+    radix_tree_init(&p2m->p2m_type);
+
+#ifdef CONFIG_HAS_PASSTHROUGH
+    /*
+     * Some IOMMUs don't support coherent PT walk. When the p2m is
+     * shared with the CPU, Xen has to make sure that the PT changes have
+     * reached the memory
+     */
+    p2m->clean_pte = is_iommu_enabled(d) &&
+        !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
+#else
+    p2m->clean_pte = true;

    
      
    
      
    When there's no IOMMU (in use), doesn't this want to be "false"?
    
    
    
    
    I think you are right, "false" is more correct here.


    
    
    
      
    

    
      
    
        
    +#endif
+
+    /*
+     * "Trivial" initialisation is now complete.  Set the backpointer so
+     * p2m_teardown() and friends know to do something.
+     */
+    p2m->domain = d;

    
      
    
      
    And where is that p2m_teardown(), to cross-check the comment against?
    
    
    
    
    It is not introduced now as I expected it is need only when domain is needed to
be stop for some reason. And it isn't really needed now.

Anyway, it seems like it is a stale comment as on other arch-es p2m_teardown() has
an argument with struct domain *d.

I can update the commit to:
 "Trivial" initialisation is now complete.  Set the backpointer so the users of p2m
  could get an access to domain structure.

~ Oleksii
    
  


--------------nN0PHet1fX3NuT67iu0u457E--


From xen-devel-bounces@lists.xenproject.org Thu May 22 15:56:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 15:56:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994350.1377386 (Exim 4.92)
	(envelope-from )
	id 1uI8H4-0003fq-GD; Thu, 22 May 2025 15:56:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994350.1377386; Thu, 22 May 2025 15: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 1uI8H4-0003fj-Dl; Thu, 22 May 2025 15:56:02 +0000
Received: by outflank-mailman (input) for mailman id 994350;
 Thu, 22 May 2025 15:56:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI8H3-0003fb-0D
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 15:56:01 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 40cb1305-3725-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 17:55:59 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ac34257295dso1320341266b.2
 for ; Thu, 22 May 2025 08:55:58 -0700 (PDT)
Received: from [10.0.5.8] ([213.235.133.42]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d498914sm1081890666b.151.2025.05.22.08.55.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 08: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" 
X-Inumbo-ID: 40cb1305-3725-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747929358; x=1748534158; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=S6N45kppNUXEw61TvIEL2O5MfJPLFBwbUFCC1akRvRg=;
        b=ZM07FmeIl0qsSkuyrf/UZhsZ2gVu7tEgSDIjthd7yS00mF6Q78za5usPr4BQiIgG3g
         LG+SVMJRtk8pUMGcvbSz32AuUW+QDo1xD3pch0tCRLoUDikhqusbRFdjym0twHtoFIsa
         vWW4QJEob1Qc0RGCgmMlBdL2wsSeKhogaTcd0QQDAgbHKbRHZ6TYa92OAEVhyrEYVVBr
         YCVny1iYdUOZo6YfUefjKzj4EuDvSO1ccmvUwp/FN9qbcqLM6qTGCyU7mrlldQMs/iAH
         B2i8t8slZjICz7gzeu9/Kfq+2gfHLthIrutT8Tg8VRA1xV2/EnpPpa0Abueyw7dCOLYB
         gv3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747929358; x=1748534158;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=S6N45kppNUXEw61TvIEL2O5MfJPLFBwbUFCC1akRvRg=;
        b=RGRFBd4spntOqokU9wq6tCO0Rce77JgCmoxaHZSx5qkjCQNRJDAO7DnqodwgZAVwd5
         P3DMEdP4mVIWHWTYwyYxt7JmBOdRZEhe2qdQTtFwIeH/mSNoFpnBP+RmNHgy9jvB8voB
         1vM5qaJXcv6OVQ7ONCIzo5IVyKLb4UZDGHtpay9o1F/3XTzyoVY0bcG5sdJ9EvyRU69D
         FTzT+aQHR4F/2E4x25a39aPYRQISDTQgYyi16ygXkspo+YQtZAjQBknWlv9el7acp2D2
         mLfWjVk8GfLJ+6NkyuvVjloEbnpoKaRFrL0fMQoP+ay2WRzw+lzEpID/bZ8+NXOk86OG
         zd4g==
X-Forwarded-Encrypted: i=1; AJvYcCWJfIX8W7J7laApAbsSEYyy7Ng8borS4bXC3bfwowk+A6KObwbQEC6mqbw8LZYRz8a1xYsmNqN0+hM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzQh5MDsvRpIWfwVbknE8CD1eQqUT8yxA3c8VnIMeorV2OOhO9T
	2CzxpwybxJeW09Ko9yuVeGipC1LF8j3cAkgEY0OArObgp5O1d5pvcxco3hUv9MUjwA==
X-Gm-Gg: ASbGnctmrK6d3YeHXfALjiOZKwtk9pHMEAjYczsNhjFOVK78kgqgDBfRry/amOlBFwG
	efKU3WHvPzlyIXJ0BbMpv5dQI1pwPljeQTo5l2E2wpD8lymJIvLmFJMWS2MLsJmq7WtnNA1F6A7
	gwdO2Qr8qCQbjUleoZj+pdGsa3D6D6icIttbf6o9Gfk2pKaOfpEYlC5rXIoEtW4toPV2D0g2jtL
	nzTfRh2lJxdEt/xHVVC7PhmV+dt1f/ARvGsuWpKpx99vUDlcOv+m+rRE8GRO8ERPed7bWG99wpH
	pN41HIdQnk/jg8+2G+Q=
X-Google-Smtp-Source: AGHT+IHuAfzgm88bWv6ns1K507Hufo1vcHk3/ptzembOI0UZj1Kkzp1h9jOBUYAPUX+1tEAHqhycoA==
X-Received: by 2002:a17:907:7b99:b0:ad5:2719:f6ae with SMTP id a640c23a62f3a-ad52d4cc604mr2475527366b.20.1747929358267;
        Thu, 22 May 2025 08:55:58 -0700 (PDT)
Message-ID: <26893680-4467-4e42-89e5-b9020529f03d@suse.com>
Date: Thu, 22 May 2025 17:55:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 11/14] xen/riscv: implementation of aplic and imsic
 operations
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <33f0952f0d05e4fe8fff926df31987e006c6eacf.1747843009.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <33f0952f0d05e4fe8fff926df31987e006c6eacf.1747843009.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> +static void 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;

Nit: Comma vs blank placement.

> +    const struct imsic_config *imsic = aplic.imsic_cfg;
> +
> +    /*
> +     * TODO: Currently, APLIC is supported only with MSI interrupts.
> +     *       If APLIC without MSI interrupts is required in the future,
> +     *       this function will need to be updated accordingly.
> +     */
> +    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
> +
> +    ASSERT(!cpumask_empty(mask));
> +
> +    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;
> +    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);

Nit: Line length.

I'm also puzzled by the various uses of IMSIC_MMIO_PAGE_SHIFT. Why do you
subtract double the value when calculating hhxs, just to add the value
back in here? There's no other usee of the variable afaics.

> +    value = desc->irq;
> +    value |= cpu << APLIC_TARGET_HART_IDX_SHIFT;
> +    value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT) ;

Nit: Stray blank.

> +    spin_lock(&aplic.lock);
> +
> +    writel(value, &aplic.regs->target[desc->irq - 1]);
> +
> +    spin_unlock(&aplic.lock);
> +}
> +
> +static const hw_irq_controller aplic_xen_irq_type = {
> +    .typename     = "aplic",
> +    .startup      = aplic_irq_startup,
> +    .shutdown     = aplic_irq_disable,
> +    .enable       = aplic_irq_enable,
> +    .disable      = aplic_irq_disable,
> +    .set_affinity = aplic_set_irq_affinity,

As indicated before, for functions you use as hooks you want to save
yourself (or someone else) future work by marking them cf_check right
away.

> --- a/xen/arch/riscv/imsic.c
> +++ b/xen/arch/riscv/imsic.c
> @@ -22,7 +22,124 @@
>  
>  #include 
>  
> -static struct imsic_config imsic_cfg;
> +static struct imsic_config imsic_cfg = {
> +    .lock = SPIN_LOCK_UNLOCKED,
> +};
> +
> +#define IMSIC_DISABLE_EIDELIVERY    0
> +#define IMSIC_ENABLE_EIDELIVERY     1
> +#define IMSIC_DISABLE_EITHRESHOLD   1
> +#define IMSIC_ENABLE_EITHRESHOLD    0
> +
> +#define imsic_csr_write(c, v)   \
> +do {                            \
> +    csr_write(CSR_SISELECT, c); \
> +    csr_write(CSR_SIREG, v);    \
> +} while (0)
> +
> +#define imsic_csr_set(c, v)     \
> +do {                            \
> +    csr_write(CSR_SISELECT, c); \
> +    csr_set(CSR_SIREG, v);      \
> +} while (0)
> +
> +#define imsic_csr_clear(c, v)   \
> +do {                            \
> +    csr_write(CSR_SISELECT, c); \
> +    csr_clear(CSR_SIREG, v);    \
> +} while (0)
> +
> +void __init imsic_ids_local_delivery(bool enable)
> +{
> +    if ( enable )
> +    {
> +        imsic_csr_write(IMSIC_EITHRESHOLD, IMSIC_ENABLE_EITHRESHOLD);
> +        imsic_csr_write(IMSIC_EIDELIVERY, IMSIC_ENABLE_EIDELIVERY);
> +    }
> +    else
> +    {
> +        imsic_csr_write(IMSIC_EITHRESHOLD, IMSIC_DISABLE_EITHRESHOLD);
> +        imsic_csr_write(IMSIC_EIDELIVERY, IMSIC_DISABLE_EIDELIVERY);
> +    }
> +}
> +
> +static void imsic_local_eix_update(unsigned long base_id, unsigned long num_id,
> +                                   bool pend, bool val)
> +{
> +    unsigned long id = base_id, last_id = base_id + num_id;
> +
> +    while ( id < last_id )
> +    {
> +        unsigned long isel, ireg;
> +        unsigned long start_id = id & (__riscv_xlen - 1);
> +        unsigned long chunk = __riscv_xlen - start_id;
> +        unsigned long count = (last_id - id < chunk) ? last_id - id : chunk;

Any reason you open-code min() here?

> +        isel = id / __riscv_xlen;
> +        isel *= __riscv_xlen / IMSIC_EIPx_BITS;
> +        isel += pend ? IMSIC_EIP0 : IMSIC_EIE0;
> +
> +        ireg = GENMASK(start_id + count - 1, start_id);
> +
> +        id += count;
> +
> +        if ( val )
> +            imsic_csr_set(isel, ireg);
> +        else
> +            imsic_csr_clear(isel, ireg);
> +    }
> +}
> +
> +void imsic_irq_enable(unsigned int irq)
> +{
> +    /*
> +    * The only caller of imsic_irq_enable() is aplic_irq_enable(), which
> +    * already runs with IRQs disabled. Therefore, there's no need to use
> +    * spin_lock_irqsave() in this function.
> +    *
> +    * This ASSERT is added as a safeguard: if imsic_irq_enable() is ever
> +    * called from a context where IRQs are not disabled,
> +    * spin_lock_irqsave() should be used instead of spin_lock().
> +    */
> +    ASSERT(!local_irq_is_enabled());
> +
> +    spin_lock(&imsic_cfg.lock);
> +    /*
> +     * There is no irq - 1 here (look at aplic_set_irq_type()) because:
> +     * From the spec:
> +     *   When an interrupt file supports distinct interrupt identities,
> +     *   valid identity numbers are between 1 and inclusive. The identity
> +     *   numbers within this range are said to be implemented by the interrupt
> +     *   file; numbers outside this range are not implemented. The number zero
> +     *   is never a valid interrupt identity.
> +     *   ...
> +     *   Bit positions in a valid eiek register that don’t correspond to a
> +     *   supported interrupt identity (such as bit 0 of eie0) are read-only zeros.
> +     *
> +     * So in EIx registers interrupt i corresponds to bit i in comparison wiht
> +     * APLIC's sourcecfg which starts from 0.
> +     */
> +    imsic_local_eix_update(irq, 1, false, true);
> +    spin_unlock(&imsic_cfg.lock);
> +}
> +
> +void imsic_irq_disable(unsigned int irq)
> +{
> +   /*
> +    * The only caller of imsic_irq_disable() is aplic_irq_enable(), which

s/enable/disable/ ?

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 16:09:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 16:09:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994371.1377396 (Exim 4.92)
	(envelope-from )
	id 1uI8U1-00069h-Kn; Thu, 22 May 2025 16:09:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994371.1377396; Thu, 22 May 2025 16:09: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 1uI8U1-00069a-IB; Thu, 22 May 2025 16:09:25 +0000
Received: by outflank-mailman (input) for mailman id 994371;
 Thu, 22 May 2025 16:09:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uI8U0-000699-Kb
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 16:09:24 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 20047bb9-3727-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 18:09:23 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-602039559d8so7522649a12.1
 for ; Thu, 22 May 2025 09:09:23 -0700 (PDT)
Received: from [10.0.5.8] ([213.235.133.42]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005a6e745fsm10951938a12.48.2025.05.22.09.09.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 09:09: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" 
X-Inumbo-ID: 20047bb9-3727-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1747930162; x=1748534962; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=v1XHYKOuBrBkEc4056xakayK/63ljFdwhAyjCiQnKYM=;
        b=IotdCdx/c9ExTotAHH/mOPJ6gApS4Q4TEiuOuz8t9NPxKjMIlPiF+WBZy7qx/T/yid
         M+hpZf7WVsbjexEWqhbcp4/pajto5cSNMxjxypJ3sdTbrgFNgus0CX0jeEb4EUEYK//4
         kDJxUdHrXSA5B/tLOjWJMrdIqcuWWToYI/WWorLWk1XFN2qAaZuwJjO6l21Ag72yvZh7
         nnRJ3fs8eqYUYfW6SqGv62mTwkREeo4M85riKigiJmgJnoHdAubRGikm4Yx4ROl4emMR
         w1idg0Gn3MaqQf9DCZojXazh3dbp4Exbtx8F6Af0bao1rLFwG1X4b82042uDgs2ezLok
         duOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747930162; x=1748534962;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=v1XHYKOuBrBkEc4056xakayK/63ljFdwhAyjCiQnKYM=;
        b=IVClal2MmNq2zXJzP25V/DhLq7RkmP/J7JoA1BipywhYc/R+enJ2ZqQ8QbyuUXSxtv
         3qiaguJZMGkFGHwWfqLe/ig8Fcu3fRt2L1hPG5h5Qh4r+a8LIQNPWKomuXI7Zv4tYCOF
         0B6ZZ4meODsO1nOlGUr8PWT7Ss0BDH6u30lhdNq1iugreAfi/QfOcP7tZie5niHu1gbQ
         17xSjVZpQIMe3AJ3sqQaWbEQ8XTt4pqo6Gn/cHncqOs/Pzr9MpasE3UMNJkqX8d/9cs+
         yGU8IwS+5yMaZdid6w2b6jHUa9RQdGk+za27lQPCP5H7B/+5wmHn+MEkgk0pqsWiAwLN
         t4Og==
X-Forwarded-Encrypted: i=1; AJvYcCUxTYhticMg0twwse/Q4mAEXJszdp7Is12ptJ6r88JxJ9pvAPG1smaYe1EE6l5BAD8GjztMML+5yUk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz0D7FzYslMbFy32KdDUFez/ZYG1idAHjnuexenxg/xMlibgHFf
	8nWuBHtqYd3t/sWmOtTcADg2AFAKnxpP4trX7M5ti4lCQOaMyxG0jmDUkmChWq/b2g==
X-Gm-Gg: ASbGncu7aHZVQyFtyhIOApoE8c4LVwruqrjPwUugytLv9HP3qgztjAcV0PBjwL7Vkz8
	iylTQCbm/Fd0FBO9OdbxzvblF6RiLpbLhPN0ZDWPc1JJG95x/W0F/wVyXx3ktxz6t6SkN4ZMgCL
	X8mENTW3WJNrbjBi1p+rg0EaArvYVDE0xDu17dHNnsuZZwgLPj/YvrxPdcHUc6Ai9TIhFojbqkn
	RsjxGGVi+eC4Fx/A5cTygMryT8vXDHtEL8zTsUcnunh/EqOZfP4Tng+e/x0Uel2C4MBI4+eYWPZ
	bIjBjx/+nY6da8gvYSE=
X-Google-Smtp-Source: AGHT+IGiOTnHHedpigHcKYha0AJTLV0lscn5NO1bxfkY3xhcCZiv8GzGx8tZmBww3TIMlBHYrzYa4w==
X-Received: by 2002:a05:6402:90c:b0:602:4405:778e with SMTP id 4fb4d7f45d1cf-60244057b23mr5171288a12.33.1747930162383;
        Thu, 22 May 2025 09:09:22 -0700 (PDT)
Message-ID: 
Date: Thu, 22 May 2025 18:09:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m
 initialization
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
 <7ef3ca26-05f5-4e86-b7c7-852b6c74a3d0@suse.com>
 <1a0d3084-9e77-4df5-936a-c1a1317c0f18@gmail.com>
Content-Language: en-US
From: Jan Beulich 
In-Reply-To: <1a0d3084-9e77-4df5-936a-c1a1317c0f18@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.05.2025 17:53, Oleksii Kurochko wrote:
> On 5/20/25 3:37 PM, Jan Beulich wrote:
>> On 09.05.2025 17:57, Oleksii Kurochko wrote:
>>> +static struct page_info *p2m_get_clean_page(struct domain *d)
>>> +{
>>> +    struct page_info *page;
>>> +
>>> +    /*
>>> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
>>> +     * As explained in Section 18.5.1, for the paged virtual-memory schemes
>>> +     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
>>> +     * and must be aligned to a 16-KiB boundary.
>>> +     */
>>> +    page = alloc_domheap_pages(NULL, 2, 0);
>> Shouldn't this allocation come from the domain's P2M pool (which is yet
>> to be introduced)?
> 
> First, I will drop p2m_get_clean_page() as it will be used only for p2m root page
> table allocation.
> 
> p2m_init() is called by domain_create() [->arch_domain_create()->p2m_init()] from create_domUs():
> [https://gitlab.com/xen-project/xen/-/blob/staging/xen/common/device-tree/dom0less-build.c?ref_type=heads#L984].
> 
> When p2m_init() is called, p2m pool isn't ready and domain isn't created yet. Last one
> is also crucial for usage of p2m pool as p2m pool belongs to domain and thereby it is
> using alloc_domheap_page(d, ...) (Not NULL as for allocation of p2m root table above),
> so domain should be created first.

Yet that is part of my point: This allocation should be against the domain,
so it is properly accounted. What's the problem with allocating the root
table when the pools is being created / filled?

>>> +{
>>> +    unsigned long ppn;
>>> +    unsigned long hgatp_mode;
>>> +
>>> +    ppn = PFN_DOWN(page_to_maddr(page_info)) & HGATP_PPN;
>>> +
>>> +    /* ASID (VMID) not supported yet */
>>> +
>>> +#if RV_STAGE1_MODE == SATP_MODE_SV39
>>> +    hgatp_mode = HGATP_MODE_SV39X4;
>>> +#elif RV_STAGE1_MODE == SATP_MODE_SV48
>>> +    hgatp_mode = HGATP_MODE_SV48X4;
>>> +#else
>>> +    #error "add HGATP_MODE"
>> As before, please have the # of pre-processor directives in the first column.
>>
>>> +#endif
>>> +
>>> +    return ppn | (hgatp_mode << HGATP_MODE_SHIFT);
>> Use MASK_INSR()?
> 
> Do you mean MASK_INSR(hgatp_mode, HGATP_MODE_MASK)?
> If yes, then I didn't get what is the point then?

The point is that generally ..._SHIFT is redundant when you also have
..._MASK; that's what MASK_EXTR() and MASK_INSR() leverage.

>>> +static int p2m_alloc_table(struct domain *d)
>>> +{
>>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>> +
>>> +    p2m->root = p2m_allocate_root(d);
>>> +    if ( !p2m->root )
>>> +        return -ENOMEM;
>>> +
>>> +    p2m->hgatp = hgatp_from_page_info(p2m->root);
>>> +
>>> +    /*
>>> +     * Make sure that all TLBs corresponding to the new VMID are flushed
>>> +     * before using it.
>>> +     */
>>> +    p2m_write_lock(p2m);
>>> +    p2m_force_tlb_flush_sync(p2m);
>>> +    p2m_write_unlock(p2m);
>> While Andrew directed you towards a better model in general, it won't be
>> usable here then, as the guest didn't run on any pCPU(s) yet. Imo you
>> want to do a single global flush e.g. when VMIDs wrap around. That'll be
>> fewer global flushes than one per VM creation.
> 
> I am not sure that I get a phrase 'VMIDs wrap around'.

You have to allocate them somehow. Typically you'll use the next one available.
At some point you will need to start over, searching from the beginning. Prior
to that now allocation of a new one will require any flush, as none of them
had be in use before (after boot or the last such flush).

> I am going to implement, p2m_force_tlb_flush_sync() as:
>   static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
>   {
>     ...
>       sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0);
>     ...
>   }
> 
> With such implementation if the guest didn't run on any pCPU(s) yet
> then d->dirty_cpumask is empty, then sbi_remote_hfence_gvma() will do nothing
> as hmask will be NULL (https://gitlab.com/xen-project/people/olkur/xen/-/blob/staging/xen/arch/riscv/sbi.c?ref_type=heads#L238).
> I am not sure that it is a good idea as I can't find a guarantee in the spec
> that TLB will be empty during boot time.

If in doubt, do one global flush while booting.

Jan


From xen-devel-bounces@lists.xenproject.org Thu May 22 16:25:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 16:25:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994380.1377407 (Exim 4.92)
	(envelope-from )
	id 1uI8j2-0000kw-Rn; Thu, 22 May 2025 16:24:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994380.1377407; Thu, 22 May 2025 16:24: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 1uI8j2-0000kp-On; Thu, 22 May 2025 16:24:56 +0000
Received: by outflank-mailman (input) for mailman id 994380;
 Thu, 22 May 2025 16:24:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI8j1-0000kZ-G6
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 16:24:55 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4b95ce56-3729-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 18:24:55 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a36f26584bso2915897f8f.0
 for ; Thu, 22 May 2025 09:24:55 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a36c6eeaf8sm16032214f8f.48.2025.05.22.09.24.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 09:24: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" 
X-Inumbo-ID: 4b95ce56-3729-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747931094; x=1748535894; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=+VbyuGdmApotSy2XpQAnkCSLpSiOSHc4CYf4Pg7DI7c=;
        b=WxorxFL4UBqknxGCD4rLygLH2Go7lczWR/euD/xh+7TZd3eU9E7/w1UQK4zif25nCK
         MOHNUfd8hccPXLhSU5HRUwAomMJ3ge9kK9GD9iU594TLCvGbBtzDl7lIzrDTxhTbjx3f
         VQadLTgcMmg8jVcP4uWyAOsHQ4LxyCnTMuNXA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747931094; x=1748535894;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+VbyuGdmApotSy2XpQAnkCSLpSiOSHc4CYf4Pg7DI7c=;
        b=kEFMnmCi2svKHNOm9ym7Hph1emwojZa4irZIzxXrsUcThvDaIvNTgMbdRJQ/ggI5bD
         o670CaSqD+pofxsIL/fweFeFPkSH1YUA+cyCTRZBdcxJ0o5sS8U8dsDMJXdTHqkcFOYX
         eC+epoH0Xu9gHYTum8+WNnTUKijRa/e+YAFgTIyZaKUqBcM64JnRmcL2GEEAZrdtTxay
         sD+ejgcHQ/EngoccJ+5m6SVxp//5bh94j33PrbMxq/uobZaRth2HqzaiLAXVG5qS2qYG
         sspbBCzdF2dCpkv3TaQRDPGilICQfriBsg0Cj18ReDvYBqkggHkbz6h+C9FdrUHuiqnu
         GxoQ==
X-Forwarded-Encrypted: i=1; AJvYcCUPTwCzPr8558L+gGU5cv1xbBT9tdiFkYMR7BFHl33gPUtZ4v5tpdTWCJPICex3SnuPMD6jN0JPxr8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw3dl+xbDEaa9TzCYvjvfuoYieyuqmfXu+KnLh4LkQCuxJkDZU/
	kUjSdf6rDj77dL9rwO0Vh6Wvyp1nURXRmhdYRwHZoRnFzQcPAANucyKwf+JH4XjC4BY=
X-Gm-Gg: ASbGnctC+PAlfzHwwZnjGRd3vLnIK5feCSmrx7K0MyacpItDR+n7iWDxfckHkwlgvDn
	q8gBb4JdRu6wV0uGYmVWgAUGzdfF5i9pv1G1FEdLFp+hmPalMKT+8heiT1ljksXN9mULe34FUqj
	RW+CYCTv63Qwu+eajT+zE3zf9pmO6oaBry99dggKBlGO1chYp8X6l80Y8D4aELmkoNBu9oZI6ol
	7lhukHcuGjoGCJ72l65jK9KEt7YLjzqVNBZAoUUpIVnRcchQbIUjRwQ2DbQGF469dwLUOJkrcyY
	OEjcML3el6tYdOuo9ERg5snBfDYUIrPWiHPP29M00PZ5uIw17cUgL5kKNqAMUwbDy+guSzI0mRH
	jYiJfa9O+WmRekqwHhPI=
X-Google-Smtp-Source: AGHT+IF/W4PeCp4SCSV1X9CAzRjwurVV2GhB7kVIveKPIPmcVj7PEY+Bhw9c7zrQNLVv6YvD2388Fg==
X-Received: by 2002:a5d:64eb:0:b0:3a3:6e85:a523 with SMTP id ffacd0b85a97d-3a36e85a8e2mr15340386f8f.42.1747931094488;
        Thu, 22 May 2025 09:24:54 -0700 (PDT)
Date: Thu, 22 May 2025 18:24:53 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: Jan Beulich ,
	Andrew Cooper ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/2] x86/vpci: refuse to map BARs at position 0
Message-ID: 
References: <20250522140356.5653-1-roger.pau@citrix.com>
 <20250522140356.5653-3-roger.pau@citrix.com>
 <3f274948-92bb-40c4-bcaf-7b538300140a@suse.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Thu, May 22, 2025 at 11:44:24AM -0400, Stewart Hildebrand wrote:
> On 5/22/25 10:59, Jan Beulich wrote:
> > On 22.05.2025 16:03, Roger Pau Monne wrote:
> >> diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
> >> index 26bb7f6a3c3a..39fd5a16a4aa 100644
> >> --- a/xen/arch/x86/pci.c
> >> +++ b/xen/arch/x86/pci.c
> >> @@ -101,6 +101,15 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
> >>  
> >>  bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
> >>  {
> >> +    /*
> >> +     * Refuse to map BARs at position 0, those are not initialized.  This might
> >> +     * be required by Linux, that can reposition BARs with memory decoding
> >> +     * enabled.  By returning false here bar->enabled will be set to false, and
> >> +     * bar_write() will work as expected.
> >> +     */
> >> +    if ( mfn_eq(start, _mfn(0)) )
> >> +        return false;
> > 
> > Is this really x86-specific?
> 
> No, I think Arm would benefit from this check too. I'm in favor of
> moving the check to common.

I think on ARM pci_check_bar() is more strict, and doesn't really need
this check since it explicitly checks whether the BAR falls inside of
a bridge window.

So unless you have a bridge window at mfn 0 this won't make a
difference.  And if you have a bridge window at mfn 0 you really want
to be able to position BARs at address 0.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 22 16:50:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 16:50:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994409.1377417 (Exim 4.92)
	(envelope-from )
	id 1uI980-0004sa-Qb; Thu, 22 May 2025 16:50:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994409.1377417; Thu, 22 May 2025 16:50: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 1uI980-0004sT-O2; Thu, 22 May 2025 16:50:44 +0000
Received: by outflank-mailman (input) for mailman id 994409;
 Thu, 22 May 2025 16:50:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI97z-0004sN-7K
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 16:50:43 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e537de80-372c-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 18:50:41 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43ede096d73so61345075e9.2
 for ; Thu, 22 May 2025 09:50:41 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca5a04csm23390670f8f.23.2025.05.22.09.50.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 09:50: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" 
X-Inumbo-ID: e537de80-372c-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747932641; x=1748537441; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=HoEeXAhluvwOo92HLwJ8Kfu/IuX2U+5O0BxMnCuG17Q=;
        b=W+fSYRe5iSQKIR+PwYzAQoHNF0qmmpC8xKdnJTQUVUELqNreHElq6IPtyaxTbelJML
         2RFOlHCmS4/sGPu0uEZNMsRa9k70pGMA4qk1tWGf38AJkCYQHUmREIxkPHymfI5fLsYn
         EJp3fh9S6XMaLj/Rpx35+FL3K86ElYik0mSVA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747932641; x=1748537441;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=HoEeXAhluvwOo92HLwJ8Kfu/IuX2U+5O0BxMnCuG17Q=;
        b=XffTDiIZnqy39a8yYlunO6HkbQZSFE+IfLdb/Q9raPdmgS3FHd57gttpGgSJx1OmAA
         ou0BKP/IWx+qgjBDlML02twZz9FJBnEBWF3noA2m+JeGr1jpmwB2+c5NJtRlKbwPO/eJ
         1zSvBkNgm2dFdt5xvLq7vndGUthxoNZxOybvgkHdAhXNu4spqwZrMJ63rincMTuC3vbm
         MxTAsGAnxVOnFeaOG3N5NiMmxjndkWlBIOoj2Z5rh9RAoda6n5hsVY08x8X59NF2XaWc
         FUd/+FhwW5DC6KMDZLAu+1CdeBBxHe6MOPODPb28I4WgPSVng1nfhJYkfToaVm5wsHHP
         lohA==
X-Forwarded-Encrypted: i=1; AJvYcCV04eZuLItSTIUn/uDhDbeHAK/Ecr8YQ7Btlq+27Hg75rSPzYAxpA4EYxG3D+dPTQqiIFS/c8TG7K0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyTTHNonuBZuKW6c2znX0h3VMaH488spUC5x6RBMWK/eT510r4+
	msQMLVW1EPYrkPVroKhr6/cIBARjENsPFaAe8VPzFhuLIx6oPL16XGO2sLD42DcWhQnapQt6LUD
	VMWNT
X-Gm-Gg: ASbGnctAvdEjHYv8r4L9EwJvK1XinXary7O3CIegfvU79MwYz85xWqYtMFvwflQzi2/
	4JdRyCmd6NPa68Qb9w8385rhHZTY651sFeSGf0w2kLOiyMsPC/dOmD3q6fCs60uOPic4ItzUmOd
	aTNR+7RR5kYJfrZRTVWOoD0vFCqbXUxQyHQHXXfGPR+7OyYVHM70F7zy5JIMrPakh/e9aMKIMsD
	8FdJ76AN6nuURYAc2ZmmM6ZNH06pi2Nm+4GCR05My4U2OSlpVT5dNNnbGZS82Mo4HULvJux/7ix
	2V10/mdPPD/0kncQv8zWhSuLfLeBbbbybb9GPfSdxJCNTy3s1pgNjoGvxeksLIfK33WEqs3a3pD
	G86jHyEze81H9MYup9GY=
X-Google-Smtp-Source: AGHT+IGXp+x3Stus1k6Cbrd+wthlo2UV7WDRRs9oxBAaxamguTGWsvvxs8yAsIXawhugG11em3XyXg==
X-Received: by 2002:a05:600c:3f07:b0:43d:77c5:9c1a with SMTP id 5b1f17b1804b1-442fd60b516mr268915745e9.4.1747932640493;
        Thu, 22 May 2025 09:50:40 -0700 (PDT)
Date: Thu, 22 May 2025 18:50:39 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Jan Beulich , xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/4] x86/boot: print CPU and APIC ID in bring up
 failure
Message-ID: 
References: <20250522075440.99882-1-roger.pau@citrix.com>
 <20250522075440.99882-2-roger.pau@citrix.com>
 <0028ad37-95e7-4b6e-87b6-07cadcac64aa@suse.com>
 <8c1156a8-a626-4b62-9cc1-7790184b2b9b@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8c1156a8-a626-4b62-9cc1-7790184b2b9b@citrix.com>

On Thu, May 22, 2025 at 03:39:57PM +0100, Andrew Cooper wrote:
> On 22/05/2025 10:10 am, Jan Beulich wrote:
> > On 22.05.2025 09:54, Roger Pau Monne wrote:
> >> Print the CPU and APIC ID that fails to respond to the init sequence, or
> >> that didn't manage to reach the "callin" state.  Expand a bit the printed
> >> error messages.  Otherwise the "Not responding." message is not easy to
> >> understand by users.
> >>
> >> Reported-by: Andrew Cooper 
> >> Signed-off-by: Roger Pau Monné 
> >> ---
> >> Changes since v1:
> >>  - Also print APIC ID.
> >> ---
> >>  xen/arch/x86/smpboot.c | 6 ++++--
> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> >> index 0189d6c332a4..dbc2f2f1d411 100644
> >> --- a/xen/arch/x86/smpboot.c
> >> +++ b/xen/arch/x86/smpboot.c
> >> @@ -618,10 +618,12 @@ static int do_boot_cpu(int apicid, int cpu)
> >>              smp_mb();
> >>              if ( bootsym(trampoline_cpu_started) == 0xA5 )
> >>                  /* trampoline started but...? */
> >> -                printk("Stuck ??\n");
> >> +                printk("CPU%u/APICID%u: Didn't finish startup sequence\n",
> >> +                       cpu, apicid);
> >>              else
> >>                  /* trampoline code not run */
> >> -                printk("Not responding.\n");
> >> +                printk("CPU%u/APICID%u: Not responding to startup\n",
> >> +                       cpu, apicid);
> >>          }
> >>      }
> >>  
> > Elsewhere I think we print AIC IDs in hex; may be better to do so here, too.
> > That may then want some text re-arrangement though, e.g.
> >
> > "CPU%u: APICID %#x not responding to startup\n"
> >
> > Thoughts?
> 
> Definitely hex.  Elsewhere APIC_ID always has an underscore.

Maybe I'm confused, but I don't think Xen uses an underscore, it's
always 'APIC ID' when printed.  I don't mind adding it here, I assume
what you mean with elsewhere is other projects like Linux?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu May 22 17:22:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 17:22:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994470.1377443 (Exim 4.92)
	(envelope-from )
	id 1uI9ce-0001pJ-IK; Thu, 22 May 2025 17:22:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994470.1377443; Thu, 22 May 2025 17:22: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 1uI9ce-0001pC-Ff; Thu, 22 May 2025 17:22:24 +0000
Received: by outflank-mailman (input) for mailman id 994470;
 Thu, 22 May 2025 17:22:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI9cd-0001p6-V3
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 17:22:23 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 51f6f543-3731-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 19:22:21 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5fbfdf7d353so10971495a12.0
 for ; Thu, 22 May 2025 10:22:21 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d4f2f06sm10767263a12.9.2025.05.22.10.22.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 22 May 2025 10:22: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" 
X-Inumbo-ID: 51f6f543-3731-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747934541; x=1748539341; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=kUw65lHC+ZJ+XnQAHuP1UgZqy34vprisAwKn9Gylths=;
        b=i4Q2flVeLVl033FM2dQ+E6XnKzIJYN+2zgdpNRvuw4gysn6eXtVKS15Dbn+pj2Avbu
         TN5or3ZpFmVBwd45VKCzOgefxCqqodU8KuvDH0aJ2CHrii+ydA0s1W/KEHSsl1Xwjfb3
         Fv0Hb9LBCsSxDcJTTi/2tTA0OPi7UB39E/qmo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747934541; x=1748539341;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kUw65lHC+ZJ+XnQAHuP1UgZqy34vprisAwKn9Gylths=;
        b=Z7QAqFh0wOugkxkZEK2895q6ig5lpkzolHfbZCkp4rYhUnUFMW+M8Y0GnBpXOoY3K6
         nvRZDb1w+5BJbkGBElE/kKQWtoGmC9TIa1sbMXaEeFuv9epIWJXYGHPlOucDcE2CXIls
         eJZD8tI9aClpRhtrVT0LJByHQxNCiYQsSzHCBTK6Ji2ptO03HqpYIrnSW1PRLe0tXKcp
         3J16AG7kpktdSPxKEVac0Cwl+6zU+N7bHHJjuqSYvgbtNKBeSB5hBxbMX+mEKsyhK+sg
         2MkofQIk5PZ2ZlTjqrAD/5Di8niI3N1AWwuJ0nuuz+tSArbuHkX1C4lntQ/qjn7pi3p1
         ZIQQ==
X-Forwarded-Encrypted: i=1; AJvYcCWz7uLI+k4JB4pgT/myz2erbQL2UwS0Dy0yaqu0OgOVzQXxxU/PIvUBaYu+dH+G2uQkkrc8lmXR5u0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxM14qFY8P5En0Xy6HJulX4K4lg76Css+rO312FCy6B8pcPcM7n
	kTptQcfclK9n4hHme6uQTJE4sFco2/pQ6VKpOe0e8O+KE9EOgb10yTGtSj8aB+YfthrBniSoU4m
	gV3NN
X-Gm-Gg: ASbGncsKLWOZDtCjH2D6yKGkANzZyFdA2wnxHagRGEmq0UIaeULJa2nqh8sYnm1yt2x
	phs5L8dI1DAuyP9taPxJbi+fA/WmMm9+mw2pJYl8aEECXf+IZvHVCN3BqzdiPuWI7+xiVq0RKNF
	DmFE17nrxsaPc0MRr1Wwx5t82lgMqbGoSdDh9PfQlS2YTHjzHp837Z8ZhfcxBdz9O6Ee6PKIQ8M
	HTRC2E2EKghUa0x5fD6godjZXID+I7W8AzbrEf00zkc9JYu5wjLHVY5EQIo8WyuC/RXLqUvMNWf
	inD77LQc87o1r8DiBtHoD4d3OleyHS19ejAtKy8tQAooCj10LSkKQ1pfQfgUKH6QERYN1j9Iv5g
	4lwS1ucp1SUICKPOL5ss5Kz93Nmo=
X-Google-Smtp-Source: AGHT+IH/BxWRMvHirNraPte1nu2QKQImepKXlBdQsR0q+tI3IVBcxrhV1yY/3GNW+uRgD03xiFg9lQ==
X-Received: by 2002:a05:6402:50cf:b0:5fc:aa51:4d9b with SMTP id 4fb4d7f45d1cf-600901af4damr25335074a12.27.1747934541100;
        Thu, 22 May 2025 10:22:21 -0700 (PDT)
Message-ID: <71b4666e-0efa-4020-83bb-ecaa9ede7ca9@citrix.com>
Date: Thu, 22 May 2025 18:22:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] x86/boot: print CPU and APIC ID in bring up
 failure
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Jan Beulich , xen-devel@lists.xenproject.org
References: <20250522075440.99882-1-roger.pau@citrix.com>
 <20250522075440.99882-2-roger.pau@citrix.com>
 <0028ad37-95e7-4b6e-87b6-07cadcac64aa@suse.com>
 <8c1156a8-a626-4b62-9cc1-7790184b2b9b@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

On 22/05/2025 5:50 pm, Roger Pau Monné wrote:
> On Thu, May 22, 2025 at 03:39:57PM +0100, Andrew Cooper wrote:
>> On 22/05/2025 10:10 am, Jan Beulich wrote:
>>> On 22.05.2025 09:54, Roger Pau Monne wrote:
>>>> Print the CPU and APIC ID that fails to respond to the init sequence, or
>>>> that didn't manage to reach the "callin" state.  Expand a bit the printed
>>>> error messages.  Otherwise the "Not responding." message is not easy to
>>>> understand by users.
>>>>
>>>> Reported-by: Andrew Cooper 
>>>> Signed-off-by: Roger Pau Monné 
>>>> ---
>>>> Changes since v1:
>>>>  - Also print APIC ID.
>>>> ---
>>>>  xen/arch/x86/smpboot.c | 6 ++++--
>>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>>>> index 0189d6c332a4..dbc2f2f1d411 100644
>>>> --- a/xen/arch/x86/smpboot.c
>>>> +++ b/xen/arch/x86/smpboot.c
>>>> @@ -618,10 +618,12 @@ static int do_boot_cpu(int apicid, int cpu)
>>>>              smp_mb();
>>>>              if ( bootsym(trampoline_cpu_started) == 0xA5 )
>>>>                  /* trampoline started but...? */
>>>> -                printk("Stuck ??\n");
>>>> +                printk("CPU%u/APICID%u: Didn't finish startup sequence\n",
>>>> +                       cpu, apicid);
>>>>              else
>>>>                  /* trampoline code not run */
>>>> -                printk("Not responding.\n");
>>>> +                printk("CPU%u/APICID%u: Not responding to startup\n",
>>>> +                       cpu, apicid);
>>>>          }
>>>>      }
>>>>  
>>> Elsewhere I think we print AIC IDs in hex; may be better to do so here, too.
>>> That may then want some text re-arrangement though, e.g.
>>>
>>> "CPU%u: APICID %#x not responding to startup\n"
>>>
>>> Thoughts?
>> Definitely hex.  Elsewhere APIC_ID always has an underscore.
> Maybe I'm confused, but I don't think Xen uses an underscore, it's
> always 'APIC ID' when printed.  I don't mind adding it here, I assume
> what you mean with elsewhere is other projects like Linux?

It's apic_id in plenty of smpboot.c, but fine - lets do it with a space.

We do need to reduce from $N ways of rendering this down to 1.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu May 22 17:36:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 17:36:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994479.1377454 (Exim 4.92)
	(envelope-from )
	id 1uI9qZ-0003Zw-Qn; Thu, 22 May 2025 17:36:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994479.1377454; Thu, 22 May 2025 17: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 1uI9qZ-0003Zp-Ky; Thu, 22 May 2025 17:36:47 +0000
Received: by outflank-mailman (input) for mailman id 994479;
 Thu, 22 May 2025 17:36:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI9qY-0003ZZ-8x
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 17:36:46 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 53f4af67-3733-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 19:36:44 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad560321ed9so697422266b.1
 for ; Thu, 22 May 2025 10:36:44 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d442069sm1116063366b.103.2025.05.22.10.36.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 10:36: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" 
X-Inumbo-ID: 53f4af67-3733-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747935403; x=1748540203; 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;
        bh=Jlg5b00ly6v1BGwroJTag38z3lVLNHAEgODPbkiybR4=;
        b=PA40mZ+iXGCyfKJuxPR5HeF5mr7PqriuEydxJxyAVGZMG0wVyDTY1MblDgb3Ju0QXf
         Uv+BGtvZe1bbUSQPK1NcZCENaMu9qgs8B5+62Fnwgm2x6NLZXsW9ldSA753qM4QzITgs
         z+KgB17/DSrtZZmTBoRyPdqaIy5+iv5r40xNs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747935403; x=1748540203;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Jlg5b00ly6v1BGwroJTag38z3lVLNHAEgODPbkiybR4=;
        b=t/9+BpT4tdJZ5ckSpKnHZ5j2qihkBfC/PIC/fNfsaTPMad5i2jZK+vP7PmiwQDIUCD
         3DhLtmd8XDeKuHT3uGkJacTks3MrPA4H7EjkmE48ElZWA5JpS/pWU54EXgJ3fMTPjKhF
         ovqVdnr0ZPbyu6elvvffiMy9CtiQnurluoUvZ7pcu/Bk/jUp/9LCjsSLfZ+g01Jh9AdD
         zVvJLCDSpG/E1ZBXHsrm3dcyiZBmJoLAkDjZCXeUtdSvhQL0frp5TvZZP/+yduphGlty
         08H+0qC0k2lQLLkfjckDCFqq3uJWaMd4o61+4uNCJD13hvJNXJfZeKY9yhsfdnikZKpJ
         3erA==
X-Gm-Message-State: AOJu0YxNQglyWhggEczjPUGEwJHZIW8u/Avce92ks7WP8zih+VH+gHgI
	+WtpfZraYrI4xT8/EDfpEUZf6D8k020BT/Qxsj7jlnnci5hKOZmBMOhn2LCtz1bQ5BYPuUI+KFH
	paMa0
X-Gm-Gg: ASbGncuslbWFl9eG7mfPSVW8WPimq0xzqZb2O93LbjWfztLFbHJNwSge5LfVnp5NbXT
	Qy0HOqceZboUx5bZqn2eEVMcDh20TEsdNo1/0zrG/dcu8HmpBDlX3OAY0vXYvDdtDJMuJy8B+dw
	qZwtuPLWBWs/6qbguxJSprevNBDCAeY554EwTyljFoYhHIDpYCImUALbX9gA0oU1n4Zzc6wPYj3
	A3EneTM7BUPoFgOev44hEgNyHA1JFoILQ4JbvZzjsanWUKFwNf7O8eTqxoG1ribIu8XdkUBKSBs
	QvTS7QlOJGAtFKIfnlPG0mKn97OxWpDU2kT3RviCISAiolF15AsAPqvtcSUD1+2Iusudu2JmZdW
	zxpCt3aGwDFkQj3gFTRezDsRWff07uk7YdBM=
X-Google-Smtp-Source: AGHT+IExHm8o6ocEIwcqqG1QAc876IpnGu3pGCbDYf6FWjYf0RjbIdp+0NSXlrhcL76QSN0VnUrJWg==
X-Received: by 2002:a17:906:ef0d:b0:ad5:a0e3:dab1 with SMTP id a640c23a62f3a-ad5a0e3db0cmr813415966b.35.1747935403216;
        Thu, 22 May 2025 10:36:43 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH 0/3] CI: Improve domU handling
Date: Thu, 22 May 2025 18:36:37 +0100
Message-Id: <20250522173640.575452-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

A follow-up to an RFC patch on the initrd handling improvements, this time
non-RFC.

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1831808006

Andrew Cooper (3):
  CI/qubes: Deduplicate the handling of ${dom0_check}
  CI: Use bash arrays to simplfy dom0 rootfs construction
  CI: Adjust how domU is packaged in dom0

 automation/scripts/qubes-x86-64.sh            | 39 ++++++++++++-------
 .../scripts/xilinx-smoke-dom0-x86_64.sh       | 32 +++++++++------
 2 files changed, 46 insertions(+), 25 deletions(-)


base-commit: 7ab4b392b78b5ac1c7a1fb1d085637526e67521a
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 22 17:36:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 17:36:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994481.1377472 (Exim 4.92)
	(envelope-from )
	id 1uI9qb-00041G-69; Thu, 22 May 2025 17:36:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994481.1377472; Thu, 22 May 2025 17:36: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 1uI9qb-000419-3E; Thu, 22 May 2025 17:36:49 +0000
Received: by outflank-mailman (input) for mailman id 994481;
 Thu, 22 May 2025 17:36:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI9qZ-0003Za-Ic
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 17:36:47 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 55b7818f-3733-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 19:36:47 +0200 (CEST)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-acacb8743a7so23655266b.1
 for ; Thu, 22 May 2025 10:36:47 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d442069sm1116063366b.103.2025.05.22.10.36.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 10:36: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" 
X-Inumbo-ID: 55b7818f-3733-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747935406; x=1748540206; 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;
        bh=GYyhCSHRy5HjeJM5vXD7f7xwD1MyIqvj5Lom+JBxOYs=;
        b=hGGlNNGpf4xm0malAJyrycBtckdjd/f2vJSZi3jPs24FZ6/IZRyq9Gmu4/jFmhvLsu
         V7yUdk0YnMPb0ajFHr0RP+x4TkTU1bEGrAwbv6J90HfuRyBTE2qAfUvZ3ysYBHoxGIHC
         nr//62h1qj3ikfRHSiGVvQpczaZNU4hOhpB30=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747935406; x=1748540206;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GYyhCSHRy5HjeJM5vXD7f7xwD1MyIqvj5Lom+JBxOYs=;
        b=ufvoWUMB7dcEyPbLmFn924EgUyGOeGuxf2Gsw/W86Ah/VW7QltxhzDtc/yT1OqfyX+
         ZjnRDWZPANhTglDf7Egm2wgoDF4Dirj94rvj7yxnAPn1kXvMePVuakKDQBI4UxJBMdlY
         iFy5cCO0jfERtF5TimCXNpCmClentK/ZtvKaHvnyAmJmp4KqUvsrvBrJLnEpMgs19TlE
         CXldlKHTx3S/MRimiaemrm+BVaDgF+eHEeiMCSYp6fhb0pU/6EPT3OSI0kr6sPJuRD7p
         BzjYvh2p9W7y/F6NAVeRAzYti/2Ce3XgeCF/1BhynAs48rEUy9aDFVKpdTbKyNGwjICv
         euvw==
X-Gm-Message-State: AOJu0YxSr71VpNmnqnENeEZGX8eqtprYkReOoSeiMwH1VjWiUqD2GwRg
	hs2LDeOT6BYaNvYm5yPLrq9JpFLywtwwsHGKbMtbI3ztnpdzQ2x3DFDkDmLKoXF8RFskkFkiFEg
	wLO6x
X-Gm-Gg: ASbGncsKfm0djOTC9J4g5CPRW4ltEObZzg3jKDnp5H8oC+rQm4O5jVSdhHPBwtv9OPJ
	qfo8gpL3+aMyZLZPjVIFWsGVRP7qJUaoJwurc9GHcPVXADcuIyi0rInOdbW515sQyPlKmKfTDth
	reSkDWu5BKCBic5kjvp2OWjyXpXwfgIgEUQtuicibcaHIyHYoI+SIJJhRM870sqF6wgPYWB/lCg
	M9nfbW06+bAlpqFd7P0uRhprjLs2qoUzBiBWc89rMQlUQUPSB0ZEvyKBaSaOxjXNiOgj4/iZHG/
	NVAY0Eg8CnF30IBKT8/cDdY62vRsKLNV+mE87AkbCW0kG4a3QXPVjgLUVOKvUTlstk1CIOtIqUm
	qlgEaJQN57F0M0AG+AZi6AYKW
X-Google-Smtp-Source: AGHT+IHWMogHCQeB9SJwpxg6yOOzinf1lZpu5URRocfLqaqgAeyz6UskeDQJ/1eJJRMxZON6lgEIug==
X-Received: by 2002:a17:907:f497:b0:aca:95eb:12e with SMTP id a640c23a62f3a-ad64e921e3cmr26741466b.24.1747935406203;
        Thu, 22 May 2025 10:36:46 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH 3/3] CI: Adjust how domU is packaged in dom0
Date: Thu, 22 May 2025 18:36:40 +0100
Message-Id: <20250522173640.575452-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250522173640.575452-1-andrew.cooper3@citrix.com>
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Package domU in /root for dom0 and insert into the uncompressed part of dom0's
rootfs, rather than recompressing it as part of the overlay.

For Qubes, this avoids putting the domU kernel in dom0's rootfs for tests
which aren't going to boot a guest.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Stefano Stabellini 
CC: Michal Orzel 
CC: Marek Marczykowski-Górecki 
---
 automation/scripts/qubes-x86-64.sh            | 20 +++++++++++++------
 .../scripts/xilinx-smoke-dom0-x86_64.sh       | 16 +++++++++++----
 2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index 1dd3f48b3d29..17a37134f46a 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -154,8 +154,8 @@ esac
 domU_config="
 type = '${domU_type}'
 name = 'domU'
-kernel = '/boot/vmlinuz'
-ramdisk = '/boot/initrd-domU'
+kernel = '/root/vmlinuz-domU'
+ramdisk = '/root/initrd-domU'
 cmdline = 'root=/dev/ram0 console=hvc0'
 memory = 512
 vif = [ ${domU_vif} ]
@@ -185,12 +185,24 @@ Kernel \r on an \m (\l)
     find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
     cd ..
     rm -rf rootfs
+
+    # Package domU kernel+rootfs in /root for dom0 (uncompressed)
+    mkdir -p rootfs/root
+    cd rootfs
+    cp ../binaries/bzImage root/vmlinuz-domU
+    cp ../binaries/domU-rootfs.cpio.gz root/initrd-domU
+    find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
+    cd ..
+    rm -rf rootfs
 fi
 
 # Dom0 rootfs.  The order or concatination is important; ucode wants to come
 # first, and all uncompressed must be ahead of compressed.
 parts=(
     binaries/ucode.cpio
+)
+[ -n "$domU_check" ] && parts+=(binaries/domU-in-dom0.cpio)
+parts+=(
     binaries/rootfs.cpio.gz
     binaries/xen-tools.cpio.gz
 )
@@ -238,10 +250,6 @@ mkdir -p etc/default
 echo "XENCONSOLED_TRACE=all" >> etc/default/xencommons
 echo "QEMU_XEN=/bin/false" >> etc/default/xencommons
 mkdir -p var/log/xen/console
-cp ../binaries/bzImage boot/vmlinuz
-if [ -n "$domU_check" ]; then
-    cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
-fi
 find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
 cd ..
 
diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
index 0fbabb41054a..29817ff81d0a 100755
--- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
+++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
@@ -22,8 +22,8 @@ DOMU_CMD=""
 DOMU_CFG='
 type = "pvh"
 name = "domU"
-kernel = "/boot/vmlinuz"
-ramdisk = "/boot/initrd-domU"
+kernel = "/root/vmlinuz-domU"
+ramdisk = "/root/initrd-domU"
 extra = "root=/dev/ram0 console=hvc0"
 memory = 512
 '
@@ -103,10 +103,20 @@ find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
 cd ..
 rm -rf rootfs
 
+# Package domU kernel+rootfs in /root for dom0 (uncompressed)
+mkdir -p rootfs/root
+cd rootfs
+cp ../binaries/bzImage root/vmlinuz-domU
+cp ../binaries/domU-rootfs.cpio.gz root/initrd-domU
+find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
+cd ..
+rm -rf rootfs
+
 # Dom0 rootfs.  The order or concatination is important; ucode wants to come
 # first, and all uncompressed must be ahead of compressed.
 parts=(
     binaries/ucode.cpio
+    binaries/domU-in-dom0.cpio
     binaries/rootfs.cpio.gz
     binaries/xen-tools.cpio.gz
 )
@@ -127,8 +137,6 @@ echo "${DOMU_CFG}${DOMU_CFG_EXTRA}" > etc/xen/domU.cfg
 echo "XENCONSOLED_TRACE=all" >> etc/default/xencommons
 echo "QEMU_XEN=/bin/false" >> etc/default/xencommons
 mkdir -p var/log/xen/console
-cp ../binaries/bzImage boot/vmlinuz
-cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
 find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
 cd ..
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 22 17:36:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 17:36:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994480.1377460 (Exim 4.92)
	(envelope-from )
	id 1uI9qa-0003dC-2b; Thu, 22 May 2025 17:36:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994480.1377460; Thu, 22 May 2025 17: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 1uI9qZ-0003bB-SD; Thu, 22 May 2025 17:36:47 +0000
Received: by outflank-mailman (input) for mailman id 994480;
 Thu, 22 May 2025 17:36:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI9qY-0003Za-Km
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 17:36:46 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 54a20982-3733-11f0-a2fb-13f23c93f187;
 Thu, 22 May 2025 19:36:45 +0200 (CEST)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-601aa0cb92eso7322829a12.0
 for ; Thu, 22 May 2025 10:36:45 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d442069sm1116063366b.103.2025.05.22.10.36.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 10:36: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" 
X-Inumbo-ID: 54a20982-3733-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747935404; x=1748540204; 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;
        bh=lTQLVGcychOhPHjn+s3ORj8cl5Yx5oWPYxlLPQZX4qE=;
        b=a63EIgYNicZo4Xeey+MhEaGzhbKmCrmU7QZUjp0KZqbVL0TrLSo9zoejsMQjpqh8r5
         QR4Cxb7jGH4YiirEqWWeONUYCH8O+3I952YEfuw0zJh2CXtjL/A5mMoyvMqm3tHnaWTJ
         TNF4+KjLAStzOcGwEnHHBhH4EiEvQRzvNvf/w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747935404; x=1748540204;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=lTQLVGcychOhPHjn+s3ORj8cl5Yx5oWPYxlLPQZX4qE=;
        b=b5wtsZ9ZGZ9N6073C7fk3twkucO+5hha/0hWjMNtSduv0QfefpacuZSrJmsv4/ELTb
         DAwF+5YB048O6YxCMnO/i55RYOConmOBolAuVOOdFwwDMvTQGvLW6emZpLbNjDdqJJkI
         AnM3LLnmS6E7ZyLAzb2b/mly0K5CoJpar0s0So3V9rvbUaEUlVYifMS+Z34d/fIXLjmZ
         BRKMQcV62zgxVMXuD3WDlB9TYjuVqKFc2R3+sbelDgyB0Ktta5gRZpNpMvh+dFrFe87W
         5xACaCIKPzAw+vn+T4D+HruizMRWZqsRXSuD+sbHEGQkKOznALQ2Bh9g0C5c9B7IOyqO
         GocA==
X-Gm-Message-State: AOJu0Yz8a7IzUv55aPGfngxnE/wB86rNioXi+O1slJ1KwceJkA7i8rZO
	XfSMxzJCHfdLg82WFjFbRS1wELrOw/lyZOnIQB9Hl654ttTkwybgz963TMpKM90q5ZsXL8ABVQr
	4Clkh
X-Gm-Gg: ASbGncvjOjAQesvxpZSCC5owtVS1o3AGXxPSvYQXy6Yf4Uy37OKuuZjVFKJFpzP3Xek
	S8FTPT33SDC68j0Pf2QpFkGEpeTffSZWTwR1m2tgXEOLKcRNimvsFiboCVtBK3EI36Htm4DeY46
	9PkTMhQpfzQj/jae4ZjSLX/3/j+e0q76zjMWOZI9Pz9jDXlnMckamhOPBUUsSE3u6SXm4CvaItz
	pNhvMGWbjirA7koedcKN69vrDysKNlIO8+UbmtJcgMCNqG3n9wXnP9v0e8yzrDlprPiN7SBA9KT
	npDDC6hie3ckLZqG+RWtUmrQrYPK5dQndoHgqh5Ju5yzSgmEyYdNg38qWKr/5utbgzj8VeYEyyT
	cdh6GF52nNM3H8gx1RK0rSDlb
X-Google-Smtp-Source: AGHT+IG6wD0gHXecI2/fRDvo/BDNeQHU4TT47xd98TYkH6tVgsPoTHFYWe7u6nAGRyWoez+AnoAwGQ==
X-Received: by 2002:a17:906:c408:b0:ad5:4919:6317 with SMTP id a640c23a62f3a-ad549196826mr1543346166b.49.1747935404325;
        Thu, 22 May 2025 10:36:44 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH 1/3] CI/qubes: Deduplicate the handling of ${dom0_check}
Date: Thu, 22 May 2025 18:36:38 +0100
Message-Id: <20250522173640.575452-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250522173640.575452-1-andrew.cooper3@citrix.com>
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Make it clear that ${dom0_check} is unconditional.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Stefano Stabellini 
CC: Michal Orzel 
CC: Marek Marczykowski-Górecki 
---
 automation/scripts/qubes-x86-64.sh | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index bfdd2ceb99ba..10af274a0ba7 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -221,12 +221,11 @@ if [ -n "$domU_check" ]; then
 tail -F /var/log/xen/console/guest-domU.log 2>/dev/null | sed -e \"s/^/(domU) /\" &
 tail -F /var/log/xen/qemu-dm-domU.log 2>/dev/null | sed -e \"s/^/(qemu-dm) /\" &
 xl -vvv create /etc/xen/domU.cfg
-${dom0_check}
 " >> etc/local.d/xen.start
-else
-    echo "${dom0_check}" >> etc/local.d/xen.start
 fi
 
+echo "${dom0_check}" >> etc/local.d/xen.start
+
 chmod +x etc/local.d/xen.start
 mkdir -p etc/xen
 echo "$domU_config" > etc/xen/domU.cfg
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 22 17:36:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 17:36:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994482.1377478 (Exim 4.92)
	(envelope-from )
	id 1uI9qb-00043S-EE; Thu, 22 May 2025 17:36:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994482.1377478; Thu, 22 May 2025 17:36: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 1uI9qb-000432-9f; Thu, 22 May 2025 17:36:49 +0000
Received: by outflank-mailman (input) for mailman id 994482;
 Thu, 22 May 2025 17:36:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uI9qZ-0003ZZ-Ll
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 17:36:47 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 553117a6-3733-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 19:36:46 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-601c5cd15ecso7805412a12.2
 for ; Thu, 22 May 2025 10:36:46 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d442069sm1116063366b.103.2025.05.22.10.36.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 10:36: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" 
X-Inumbo-ID: 553117a6-3733-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747935405; x=1748540205; 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;
        bh=ZadyQ1dGPInWsa7+i4u+dOHgUQQBDu0QP3e67vZGDBU=;
        b=c++HdavcNLa4vAnsAAM3dvr6ZZhMV1YwVBErgoWrRvNvYpDwfjYAQjmGI6RXPOf6ct
         K4aQm8DROpMIW0aZybfusnKDrWTOrxUd/3eNOV3gvK2AFZCrGFfpicViUyZ50BC0oLnx
         qoQPHzcOQr2O/yeFWAEQlCrUQLgo9ks5P5Tiw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747935405; x=1748540205;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ZadyQ1dGPInWsa7+i4u+dOHgUQQBDu0QP3e67vZGDBU=;
        b=tyRsjiovXxbodeqq2EUfDQQTuEBH6T00/D1Gf0Jzn5T5kBc7sFaVw6cxD/fqS5YnhO
         j9Ef3WfI4DA9vnF0CizEi74+J1sGKfIcJdw1O7wdx/LZkn1JhN29oojfQNbQ0lXnFZIs
         VzS91rXulXfTWPgnFoYKm7wdoD5I05m5YV9Bi6Sv0UyJCMSnVilM8kx1l2QKWBkR+UdT
         9x4Oicll4CpDPeCHySdVb5kw1wHDcTEVCp9Wh+spPk32PWzH2v51QpSihJG+8tDUNSF+
         6wkNexzHlOhe8VnjFFmEcDD0dK1gkGIjcu1GvL876+AkZFe8tPckExTdQ2F6tLBg1wEe
         nl+A==
X-Gm-Message-State: AOJu0YwhXRauIP8om0yV7ddPzEQLWxmvA9mDVEz8wk1NMYXVxLYR7x/j
	ufIdqZxvgQx/5CcdE76j1SyLpATmyWVTzl5/UbSNBuHgkogV20Q92h0VgTRq1pEuUI8FeP4bQ7j
	TQ3Em
X-Gm-Gg: ASbGncvKZUnRGLu3+LymNOQyp0eugyEpKQW6dL5QxnzBdxIP8HRDx/X9OWoZoxW15hm
	B2nWUt+BYoKMsXAv7GDgqBxpDc7kvG7JCd9T7YnjoXGmwbhLB8mbmN5zGhQYy1DFJIyiwGshKO2
	AEzHqFQ8+p3+INAH2O47NeQXJMR7hO7f9s6l3HnuXfnUjrgU/ZH2G/415ZsnoqhWR/rHbTIehx9
	RJ2SM54TUFTIvnoQpMMadocOpNRndqcVwQZjoC7oFSj+ARR161u1pHyiEwz/mgnY/YfIeuYxMRl
	GvJAZMZb2KPYbzhAVQgsfNyZ817XZyA1fZwqQ2KtuE3t6DOVTa6cQx9P6SfWyRoHrrQJClz2hjD
	9P/dLJWXtTPzir+3D9Eweh9w/bD0L2jIEN5Q=
X-Google-Smtp-Source: AGHT+IGpajxmUsPPYguIJRowQVROWmkBbc6c75BLnT1q+SBw/DEbc5kCmLDo8Qb2Z9sBZzuuh/yIBw==
X-Received: by 2002:a17:907:96a1:b0:ad2:3f54:1834 with SMTP id a640c23a62f3a-ad536dce664mr2444664566b.40.1747935405312;
        Thu, 22 May 2025 10:36:45 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH 2/3] CI: Use bash arrays to simplfy dom0 rootfs construction
Date: Thu, 22 May 2025 18:36:39 +0100
Message-Id: <20250522173640.575452-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20250522173640.575452-1-andrew.cooper3@citrix.com>
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

For Qubes, this requires switching from sh to bash.

This reduces the number of times the target filename needs to be written to 1.

Expand the comment to explain the concatination constraints.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Stefano Stabellini 
CC: Michal Orzel 
CC: Marek Marczykowski-Górecki 

I would like to find a slightly nicer way of conditional parts, but nothing
comes to mind.
---
 automation/scripts/qubes-x86-64.sh             | 14 +++++++++-----
 automation/scripts/xilinx-smoke-dom0-x86_64.sh | 16 +++++++++-------
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
index 10af274a0ba7..1dd3f48b3d29 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/automation/scripts/qubes-x86-64.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 set -ex -o pipefail
 
@@ -187,10 +187,14 @@ Kernel \r on an \m (\l)
     rm -rf rootfs
 fi
 
-# Dom0 rootfs
-cp binaries/ucode.cpio binaries/dom0-rootfs.cpio.gz
-cat binaries/rootfs.cpio.gz >> binaries/dom0-rootfs.cpio.gz
-cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
+# Dom0 rootfs.  The order or concatination is important; ucode wants to come
+# first, and all uncompressed must be ahead of compressed.
+parts=(
+    binaries/ucode.cpio
+    binaries/rootfs.cpio.gz
+    binaries/xen-tools.cpio.gz
+)
+cat "${parts[@]}" > binaries/dom0-rootfs.cpio.gz
 
 # test-local configuration
 mkdir -p rootfs
diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
index 8f02fa73bd06..0fbabb41054a 100755
--- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
+++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
@@ -103,13 +103,15 @@ find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
 cd ..
 rm -rf rootfs
 
-# Dom0 rootfs
-cp binaries/ucode.cpio binaries/dom0-rootfs.cpio.gz
-cat binaries/rootfs.cpio.gz >> binaries/dom0-rootfs.cpio.gz
-cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
-if [[ "${TEST}" == argo ]]; then
-    cat binaries/argo.cpio.gz >> binaries/dom0-rootfs.cpio.gz
-fi
+# Dom0 rootfs.  The order or concatination is important; ucode wants to come
+# first, and all uncompressed must be ahead of compressed.
+parts=(
+    binaries/ucode.cpio
+    binaries/rootfs.cpio.gz
+    binaries/xen-tools.cpio.gz
+)
+[[ "${TEST}" == argo ]] && parts+=(binaries/argo.cpio.gz)
+cat "${parts[@]}" > binaries/dom0-rootfs.cpio.gz
 
 # test-local configuration
 mkdir -p rootfs
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu May 22 18:08:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 18:08:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994550.1377493 (Exim 4.92)
	(envelope-from )
	id 1uIALC-0001FN-0C; Thu, 22 May 2025 18:08:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994550.1377493; Thu, 22 May 2025 18:08: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 1uIALB-0001FG-To; Thu, 22 May 2025 18:08:25 +0000
Received: by outflank-mailman (input) for mailman id 994550;
 Thu, 22 May 2025 18:08:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uIAL9-0001FA-Ja
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 18:08:24 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bed4d3e0-3737-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 20:08: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" 
X-Inumbo-ID: bed4d3e0-3737-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1747937300; x=1748196500;
	bh=reUAAhVWVNWDEvGUgHpJqYIYTgi/PaLrMgGyf/TKwe4=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=DQHklkfNFePrpeCGOJACqLidARCgjsVIrbUt+xpg09XtYi51gv6RVE+R4YoswGsau
	 Vn1T9CBK9rCP74YNSp49BxlS9V3v9HKriDGdyEEJ5Pjje7m4f2sCU2r9DUNbuGmgRJ
	 AC3tV+LzLSSvs94vEhIZFJfKYvpqsS0upDrbyy6UdFaTcwg8NBucMfqSajBC/FlJTq
	 8tNYGaX9rYn9HsoaJlXUFhG4dj0Ki4Yz5p46dSKCahDIU5Dily89e41qDoxX2D5wDb
	 CAoFBUeCzqQm5X/5YrbJkU6VyPB2b5RTAiLVWFOIWuiAXmIE6hssWfAV9rK7N/hp9D
	 wbt6bXnKwNLFw==
Date: Thu, 22 May 2025 18:08:13 +0000
To: Jan Beulich 
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v8 3/3] xen/domain: introduce CONFIG_MAX_DOMID
Message-ID: 
In-Reply-To: <3b203f39-756b-4fb3-b0e5-0f790701c23a@suse.com>
References: <20250521000024.2944685-1-dmukhin@ford.com> <20250521000024.2944685-4-dmukhin@ford.com> <54945bd5-333e-4ffd-8ff1-bb89d22c7ef4@suse.com>  <3b203f39-756b-4fb3-b0e5-0f790701c23a@suse.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 5581f2ba9d0e0f4f2bd2882fab2b9e0270f5ab79
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 22, 2025 at 09:01:51AM +0200, Jan Beulich wrote:
> On 22.05.2025 02:09, dmkhn@proton.me wrote:
> > On Wed, May 21, 2025 at 09:31:34AM +0200, Jan Beulich wrote:
> >> On 21.05.2025 02:00, dmkhn@proton.me wrote:
> >>> --- a/xen/arch/arm/tee/ffa.c
> >>> +++ b/xen/arch/arm/tee/ffa.c
> >>> @@ -331,10 +331,9 @@ static int ffa_domain_init(struct domain *d)
> >>>       * reserved for the hypervisor and we only support secure endpoi=
nts using
> >>>       * FF-A IDs with BIT 15 set to 1 so make sure those are not used=
 by Xen.
> >>>       */
> >>> -    BUILD_BUG_ON(DOMID_FIRST_RESERVED >=3D UINT16_MAX);
> >>
> >> Why's this being moved to common code? It certainly may have a purpose=
 here
> >> (which I'm simply unaware of); I don't see what purpose it has in comm=
on
> >> code.
> >
> > My understanding having DOMID_FIRST_RESERVED compile-time checks in one=
 place
> > is good for testability: the check in question also applies to x86.
> >
> > I will drop that hunk.
>=20
> And also the other one, unless you can explain what exactly you're checki=
ng.
> The connection between DOMID_FIRST_RESERVED and UINT16_MAX is at best
> indirect, through domid_t. Yet if domid_t was widened (possible in princi=
ple,
> but breaking the ABI) that check would end up wrong without the compiler
> noticing (unless DOMID_FIRST_RESERVED was also bumped, which however is a=
n
> independent thing).

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 82b9c05a76..452d9f63dc 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -572,7 +572,7 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
 #endif
=20
 /* Domain ids >=3D DOMID_FIRST_RESERVED cannot be used for ordinary domain=
s. */
-#define DOMID_FIRST_RESERVED xen_mk_uint(0x7FF0)
+#define DOMID_FIRST_RESERVED xen_mk_uint(0xFFFF7FF0)
=20
 /* DOMID_SELF is used in certain contexts to refer to oneself. */
 #define DOMID_SELF           xen_mk_uint(0x7FF0)


The above patch ^^ pretty much passes the compilation on x86.
The compile time check in question currently exists for Arm only but could
catch such mistake when the limit is bumped (if any), it is easy to
spot.

>=20
> >>> --- a/xen/common/Kconfig
> >>> +++ b/xen/common/Kconfig
> >>> @@ -576,4 +576,11 @@ config BUDDY_ALLOCATOR_SIZE
> >>>  =09  Amount of memory reserved for the buddy allocator to serve Xen =
heap,
> >>>  =09  working alongside the colored one.
> >>>
> >>> +config MAX_DOMID
> >>> +=09int "Maximum number of user domains"
> >>> +=09range 1 32752
> >>> +=09default 32752
> >>> +=09help
> >>> +=09  Specifies the maximum number of domains a user can create.
> >>
> >> My prior comment remains: The description and help needs to be accurat=
e, in
> >> order to not cause any confusion. In a true dom0less environment I'm n=
ot
> >> sure the "user" can create any domains (post boot, that is). And when =
there
> >> is Dom0 (or late hwdom), the number specified already isn't the number=
 of
> >> domains one can create (again, post boot, which is how I understand "u=
ser
> >> domains"). If someone picked 1 as the value here, it's unclear to me h=
ow
> >> late hwdom or dom0less would work in the first place.
> >
> > Do you think something like the following will be more accurate?
> >
> >     config MAX_DOMID
> >        int "Maximum number of domains"
> >        range 1 32752
> >        default 32752
> >        help
> >          Specifies the maximum number of domains: dom0 or late hwdom,
> >          predefined domains, post-boot domains, excluding Xen system do=
mains
> >          (domid >=3D DOMID_FIRST_RESERVED).
>=20
> Especially the mention of DOMID_FIRST_RESERVED is too much of an implemen=
tation
> detail here, imo. Beyond that - maybe, but I'm not overly happy this way =
either.

Will the following description will be satisfactory?

config MAX_DOMID
       int "Maximum domain ID"
       range 1 32752
       default 32752
       help
         Specifies the maximum domain ID (dom0 or late hwdom, predefined
         domains, post-boot domains, excluding Xen system domains).

>=20
> As an aside - MAX_DOMID and "Maximum number of domains" are conflicting
> with one another, too: Do you mean "maximum ID" or "maximum number of"? T=
he two
> are different by 1.

That would be "maximum ID", thank you.

>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Thu May 22 18:23:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 18:23:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994559.1377503 (Exim 4.92)
	(envelope-from )
	id 1uIAZ9-00044M-8f; Thu, 22 May 2025 18:22:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994559.1377503; Thu, 22 May 2025 18: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 1uIAZ9-00044F-65; Thu, 22 May 2025 18:22:51 +0000
Received: by outflank-mailman (input) for mailman id 994559;
 Thu, 22 May 2025 18:22:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uIAZ8-000449-DX
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 18:22:50 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c3781cbe-3739-11f0-b892-0df219b8e170;
 Thu, 22 May 2025 20:22: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" 
X-Inumbo-ID: c3781cbe-3739-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=cczqkjxgnne2rjpo5wnagi35ae.protonmail; t=1747938167; x=1748197367;
	bh=DFX322PTsMIiiFiKx2+gLa3uC8B6hzAOkAv30kk+U3U=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=RmqQh7wGFRfREnGxXq647m6MLXiqKNZOKFgXx8C0XxF4iO4ccapGt8otQ3QZGHiVa
	 HijYM/3doHO6gccoEW/H3rihaKfI9Yabm01nPWjtfTwvNFWR//UpeUM2tRqWzI/46b
	 99P1KaqVVS15kfFYO+Qyw8aL9ZWy9/vFtanGNjki3R7D+E9GdEfdzKnceUHAfaK3Ze
	 NE389u+wRDbp7Sw7MWnm24+43Aow8yvLflVMPPoYEmQDeWuSjlwYN/UiY2tQiQMGF5
	 R+uVzVskB+dhosPZ7Dzoic3NRwAPyAll0pp3QG8GIzhYD7Yn4iPBJ/1CLZ02o52RcG
	 TkMaLjKqToWdA==
Date: Thu, 22 May 2025 18:22:41 +0000
To: Andrew Cooper 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, christopher.w.clark@gmail.com, dpsmith@apertussolutions.com, michal.orzel@amd.com, persaur@gmail.com, dmukhin@ford.com
Subject: Re: [XTF PATCH v2 2/2] tests/argo: use event channel to get own domain ID
Message-ID: 
In-Reply-To: <850d4bf8-3e98-4aee-9d41-e298be34893a@citrix.com>
References: <20250521211742.2997890-1-dmukhin@ford.com> <20250521211742.2997890-3-dmukhin@ford.com> <850d4bf8-3e98-4aee-9d41-e298be34893a@citrix.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 73a3e0eba0f3f41e2f7f2277a65217da46c5ac34
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 21, 2025 at 10:37:40PM +0100, Andrew Cooper wrote:
> On 21/05/2025 10:18 pm, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > The existing argo test depends on xenstore to retrieve the domain ID.
> >
> > Also, test does not perform peer-to-peer communication using Argo hyper=
call, it
> > communicates with itself.
> >
> > Since xenstore currently runs in dom0, xenstore adds unnecessary depend=
ency on
> > dom0 for the test in x86 QEMU environment.
> >
> > Use event channel to identify the domain ID which eliminates dom0 depen=
dency
> > for the test.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v1:
> > - dropped hack of hardcoding test's own domain ID to 0, reworked gettin=
g own
> >   domain ID by relying on message channel.
> >
> > Thanks to Michal Orzel and Andrew Cooper for helping with that.
>=20
> Thanks, although this needs integrating into the pending series I've
> already got.=C2=A0 Notably, we want to use the CPUID if it's available.
>=20
> It also needs to be ahead of the argo test to avoid a bisection hazard.
>=20
> I'll pick this up and sort things out.

Thank you!

>=20
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994737.1377556 (Exim 4.92)
	(envelope-from )
	id 1uIFiP-0000Gi-9W; Thu, 22 May 2025 23:52:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994737.1377556; Thu, 22 May 2025 23:52: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 1uIFiP-0000Ep-43; Thu, 22 May 2025 23:52:45 +0000
Received: by outflank-mailman (input) for mailman id 994737;
 Thu, 22 May 2025 23:23:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uIFFc-0004Yx-5I
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:23:00 +0000
Received: from outbound.qs.icloud.com
 (p-east3-cluster1-host2-snip4-10.eps.apple.com [57.103.87.23])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b1bbd007-3763-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 01:22:57 +0200 (CEST)
Received: from outbound.qs.icloud.com (localhost [127.0.0.1])
 by outbound.qs.icloud.com (Postfix) with ESMTPS id 08E1D18001D9
 for ; Thu, 22 May 2025 23:22:55 +0000 (UTC)
Received: from smtpclient.apple (qs-asmtp-me-k8s.p00.prod.me.com
 [17.57.155.37])
 by outbound.qs.icloud.com (Postfix) with ESMTPSA id 690C2180012D
 for ; Thu, 22 May 2025 23:22: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" 
X-Inumbo-ID: b1bbd007-3763-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alex0.net; s=sig1;
	bh=W4igLNWEpJdS+ajzjNyCAoqzb9V+DG8pjtCGb23spVg=;
	h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:x-icloud-hme;
	b=pQA47SytSi4NDaGJen0AKZZPDX28fadWhK+mf3OfhXCjs7WxTPrs/Zif1GqifH1Pa
	 Ws7XkkKUhZbj5JEcCGZtqGgJbLSkqIIdzdoNi2ZEt/XibzFAKZuKBHETXQhlGn47VB
	 gFd+9cFaVU8CmDf8J/b9OXCTG0nqMfVyBU1c7UOHZGYCC1WdIVK4zQ8TNnLeBmMpOz
	 qh60G52sxNf/tZMnljJt5idwvQjrh4+cRy48AffjRp41RGtBUhUhiB1fsNs+QZi4En
	 jWqLid4LMRoiVGPJc2vBs8GiTU4Nx6HjwTr9nlCpqZeAVXBcFTWKY3rCPkEsCBR0S5
	 8Ut/YSqrHSSuA==
From: me@alex0.net
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CDA98334-DDE1-4A16-9E49-F8DC6B31E240"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: xen_acpi_processor driver is bound to dom0 vcpu count
Message-Id: 
Date: Fri, 23 May 2025 00:22:44 +0100
To: xen-devel@lists.xenproject.org
X-Mailer: Apple Mail (2.3826.500.181.1.5)
X-Proofpoint-GUID: 08OLpaYwqyWuO0fGwWXqHDti4i2hrTNe
X-Proofpoint-ORIG-GUID: 08OLpaYwqyWuO0fGwWXqHDti4i2hrTNe
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-05-22_10,2025-05-22_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0
 bulkscore=0 clxscore=1030 phishscore=0 adultscore=0 suspectscore=0
 mlxlogscore=999 spamscore=0 malwarescore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.22.0-2503310001 definitions=main-2505220234


--Apple-Mail=_CDA98334-DDE1-4A16-9E49-F8DC6B31E240
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think I=E2=80=99ve just uncovered a rather nasty bug in the =
xen_acpi_processor driver in dom0. If the vcpu count in dom0 is set to =
anything other than the exact number of physical cores, the =
xen_acpi_processor kernel driver will fail to upload the C-state =
information for those cores to Xen, resulting in Xen never knowing about =
the C-states, which significantly impacts battery life on mobile =
platforms.

This can impact users who set dom0_max_vcpus to a lesser value than =
their number of CPU cores, but is particularly relevant if SMT is =
enabled in firmware but disabled in Xen. As the cores are disabled =
manually by Xen, dom0 will only see the number of active cores; but as =
this is a lesser number of cores than Xen knows of it will mismatch and =
half the cores will not see C-state information.

The bug is reproducible easily by setting dom0_max_vcpus to less than =
your physical core count and running xenpm start 1. See if there are any =
cores that only display C0 and C1 C-states.

Alex


--Apple-Mail=_CDA98334-DDE1-4A16-9E49-F8DC6B31E240
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I think I=E2=80=99=
ve just uncovered a rather nasty bug in the xen_acpi_processor driver in =
dom0. If the vcpu count in dom0 is set to anything other than the exact =
number of physical cores, the xen_acpi_processor kernel driver will fail =
to upload the C-state information for those cores to Xen, resulting in =
Xen never knowing about the C-states, which significantly impacts =
battery life on mobile platforms.

    This can impact =
users who set dom0_max_vcpus to a lesser value than their number of CPU =
cores, but is particularly relevant if SMT is enabled in firmware but =
disabled in Xen. As the cores are disabled manually by Xen, dom0 will =
only see the number of active cores; but as this is a lesser number of =
cores than Xen knows of it will mismatch and half the cores will not see =
C-state information.

    The bug is reproducible =
easily by setting dom0_max_vcpus to less than your physical core count and =
running xenpm start 1. See if there are any cores that only display C0 =
and C1 =
C-states.

    Alex

    =
=

--Apple-Mail=_CDA98334-DDE1-4A16-9E49-F8DC6B31E240--


From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994741.1377525 (Exim 4.92)
	(envelope-from )
	id 1uIFiL-000850-0e; Thu, 22 May 2025 23:52:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994741.1377525; Thu, 22 May 2025 23: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 1uIFiK-00084t-UD; Thu, 22 May 2025 23:52:40 +0000
Received: by outflank-mailman (input) for mailman id 994741;
 Thu, 22 May 2025 23:52:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFiJ-0007r8-GG
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:39 +0000
Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com
 [2607:f8b0:4864:20::1049])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d6642a4a-3767-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 01:52:37 +0200 (CEST)
Received: by mail-pj1-x1049.google.com with SMTP id
 98e67ed59e1d1-30ec5cc994eso4775751a91.2
 for ; Thu, 22 May 2025 16:52:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d6642a4a-3767-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957956; x=1748562756; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=fNuJRaVfcGFWhloS77D8uzxF90F27fj3ZGGYCvgzPHs=;
        b=S02NSlmYBHb6e/jE0SOApVE9sJVKrNUnG+JQPBLhpF4CiV7+g68wUE5zeGXKwp5zxp
         SwAhu/WvpLafS6T3cqt6/VsXU8ZAF4lFE4Lohj7FKdJyBD6Ce5HSr9t0mim3dG+dilm4
         99cy6cpu82ixzsmXEzeG27iISFWawFFqI8tUdXwilMdt7om+n3qQw6b0QkthLtzFfiEP
         NwnOIO5wcNKL03OEeELbSAKmQCT9d8pX0oeYZU0dxZz5baeG6tfLzOoBwokEed8eLGCs
         wlZzaI2mw0ZoEenh138vq9on9k+1xzD+aF28XDDfQwhMiLBJfFu5fmXYhwCpcU+UZIDU
         gjmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957956; x=1748562756;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=fNuJRaVfcGFWhloS77D8uzxF90F27fj3ZGGYCvgzPHs=;
        b=ezNAKSoWom/Yb9gRic13X9ksMF5ci1gSGpBHgJFWIVDqfuAPHZ41reCsTxIq6Muwnd
         KqjupuQsEECD9+C5xtDf/k3A/OsMb0Ez3v/JEDL+OwddT41pjtpH3/6fJ75WElEFg92Z
         kex2FYNWRBp3Pebr5YuXZKH8CeiVrp/TpychmC7iVvTBOAIsqTJh2CJbImhQOyGKS3rV
         hzxSVGtA5YWHAbnuF947hAf+BtUof/ZlGNdHheXAev/topjpia017QTEGTItl4pb6wRX
         g/9DUPa1ebHRZjBukchIQH2tPIZ+09FypVU3DyLH3obLPt4aofUglMy8Vz9NGFHKKJMJ
         vj2w==
X-Forwarded-Encrypted: i=1; AJvYcCXZsfMXzAxx5lyuoRY0Oh0aZ+uDeC9XX99ek4ZCwI/6HhUMkKBR24XUiImQzpRI5kmsWncuM17eVZg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwlT6b0Nd94ceg60s/9Rl72xR7O5lmURZTjCagQXfuoPOFBk+0H
	tRFzZw4sR9exjaMsSOEU4R+BkCqKHVzBnE3AZdjlqJrkjKAd/arIS3XzEdDKWW0rujLVs1oY8y7
	5ZdCWhQ==
X-Google-Smtp-Source: AGHT+IHgxAzddO6m+7e1Ux4Efuqi1mCB//KSOWWOaHVhE0t5XleZFmJZnVv1KlYKH2ltYJauaNiIFWTKLOM=
X-Received: from pjbqo12.prod.google.com ([2002:a17:90b:3dcc:b0:2ea:3a1b:f493])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:4a50:b0:2fa:157e:c790
 with SMTP id 98e67ed59e1d1-30e7d4fe8c3mr35719761a91.5.1747957956077; Thu, 22
 May 2025 16:52:36 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:11 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-2-seanjc@google.com>
Subject: [PATCH v3 01/13] KVM: Use a local struct to do the initial vfs_poll()
 on an irqfd
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Use a function-local struct for the poll_table passed to vfs_poll(), as
nothing in the vfs_poll() callchain grabs a long-term reference to the
structure, i.e. its lifetime doesn't need to be tied to the irqfd.  Using
a local structure will also allow propagating failures out of the polling
callback without further polluting kvm_kernel_irqfd.

Opportunstically rename irqfd_ptable_queue_proc() to kvm_irqfd_register()
to capture what it actually does.

Signed-off-by: Sean Christopherson 
---
 include/linux/kvm_irqfd.h |  1 -
 virt/kvm/eventfd.c        | 26 +++++++++++++++++---------
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/include/linux/kvm_irqfd.h b/include/linux/kvm_irqfd.h
index 8ad43692e3bb..44fd2a20b09e 100644
--- a/include/linux/kvm_irqfd.h
+++ b/include/linux/kvm_irqfd.h
@@ -55,7 +55,6 @@ struct kvm_kernel_irqfd {
 	/* Used for setup/shutdown */
 	struct eventfd_ctx *eventfd;
 	struct list_head list;
-	poll_table pt;
 	struct work_struct shutdown;
 	struct irq_bypass_consumer consumer;
 	struct irq_bypass_producer *producer;
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 11e5d1e3f12e..39e42b19d9f7 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -245,12 +245,17 @@ irqfd_wakeup(wait_queue_entry_t *wait, unsigned mode, int sync, void *key)
 	return ret;
 }
 
-static void
-irqfd_ptable_queue_proc(struct file *file, wait_queue_head_t *wqh,
-			poll_table *pt)
+struct kvm_irqfd_pt {
+	struct kvm_kernel_irqfd *irqfd;
+	poll_table pt;
+};
+
+static void kvm_irqfd_register(struct file *file, wait_queue_head_t *wqh,
+			       poll_table *pt)
 {
-	struct kvm_kernel_irqfd *irqfd =
-		container_of(pt, struct kvm_kernel_irqfd, pt);
+	struct kvm_irqfd_pt *p = container_of(pt, struct kvm_irqfd_pt, pt);
+	struct kvm_kernel_irqfd *irqfd = p->irqfd;
+
 	add_wait_queue_priority(wqh, &irqfd->wait);
 }
 
@@ -305,6 +310,7 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
 {
 	struct kvm_kernel_irqfd *irqfd, *tmp;
 	struct eventfd_ctx *eventfd = NULL, *resamplefd = NULL;
+	struct kvm_irqfd_pt irqfd_pt;
 	int ret;
 	__poll_t events;
 	int idx;
@@ -394,7 +400,6 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
 	 * a callback whenever someone signals the underlying eventfd
 	 */
 	init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
-	init_poll_funcptr(&irqfd->pt, irqfd_ptable_queue_proc);
 
 	spin_lock_irq(&kvm->irqfds.lock);
 
@@ -416,11 +421,14 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
 	spin_unlock_irq(&kvm->irqfds.lock);
 
 	/*
-	 * Check if there was an event already pending on the eventfd
-	 * before we registered, and trigger it as if we didn't miss it.
+	 * Register the irqfd with the eventfd by polling on the eventfd.  If
+	 * there was en event pending on the eventfd prior to registering,
+	 * manually trigger IRQ injection.
 	 */
-	events = vfs_poll(fd_file(f), &irqfd->pt);
+	irqfd_pt.irqfd = irqfd;
+	init_poll_funcptr(&irqfd_pt.pt, kvm_irqfd_register);
 
+	events = vfs_poll(fd_file(f), &irqfd_pt.pt);
 	if (events & EPOLLIN)
 		schedule_work(&irqfd->inject);
 
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994746.1377586 (Exim 4.92)
	(envelope-from )
	id 1uIFiS-00017G-PT; Thu, 22 May 2025 23:52:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994746.1377586; Thu, 22 May 2025 23:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uIFiS-000179-LS; Thu, 22 May 2025 23:52:48 +0000
Received: by outflank-mailman (input) for mailman id 994746;
 Thu, 22 May 2025 23:52:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFiR-0007r7-Hw
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:47 +0000
Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com
 [2607:f8b0:4864:20::104a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id db5f549f-3767-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 01:52:45 +0200 (CEST)
Received: by mail-pj1-x104a.google.com with SMTP id
 98e67ed59e1d1-30ebd48a3c7so5673946a91.1
 for ; Thu, 22 May 2025 16:52:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: db5f549f-3767-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957964; x=1748562764; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=MSc6nvEfNa3Mk9v70O2GwrdpOydgfEuVH7IGLa1xnl8=;
        b=BN/j17S13O0j8U8TMB/UMTIZnTXHFTHCfSLnIQTLDl+xYGwj6VUI0tQPd89lFP35hW
         PAlHNo4wvvsxmpoZgHbNdA4/H8leSnjA+AF7vcsiKQ03GiTNWyAB5zy1gZUdrIGAd80t
         k9so4UVYWTxUH3PSZsnill7l0acSsbQmiYLAPtPcKRe1l+k/TSJHfyfhg7vXmVOXcZ8I
         ucv33kgs/Z4BpqSMX12mv/gBAb3X0/9SO5GWTBi3OK+Ovq2N2dt76A+VhdfjUByjc6z5
         GZWK1IFw/rYjYNYgsuOZD6jQJq3ie4OMIp43A3O8GP4XlfrK+C7p+bZPYT2M/xnU8tTQ
         ILsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957964; x=1748562764;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=MSc6nvEfNa3Mk9v70O2GwrdpOydgfEuVH7IGLa1xnl8=;
        b=X517fQJFGl0KEaQ2XQQWdSSNhcuacAVSG7/SeVDlwUDg5Q/vlljgqSGei6tYv9beYI
         MwgTgfNDh1WTzxOaAQc04e/PUcEamQijM9D0faCFDhNgCuNtCjnwvIxzCsyiWNAro4SU
         /nPPl/JLteCQymAxGCpcC8AgxVLLpRU/ojtxdnltOXTY3gF6jW4kzk0qc4/eFCEmNOia
         budMpaPk1n3I4hPEyv0G2NmgeY+OKn7bcI2uvVBSmDUAkgX4ucTP9/Gy2JOSY4SN2Iqj
         oZrn9XzZZLRMs+AjUTZAzy85gxT240uOYLM++Dro9oPHxEZUEGdQiQ4ArEYmDUv2bIyx
         Zq+Q==
X-Forwarded-Encrypted: i=1; AJvYcCU6TzH4MdYgtdimx/Yq/QrcUtlhCcs88He4wWxMmWxV2bkUyfxMGH14VK9AUo6AYJOgnbjGjGlXF9A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxREAwsIimhYqejSb6QCD11fpPJPBakjZdI3EH/MUXUErQl5axJ
	BSo8Pj1zZsDKpPXjipvxRj4zaRKSp2Ho/kZior94ndBghGHHYqLOFNf1mDo9bGXYhGRrdd5EGHH
	ZFOO6Xg==
X-Google-Smtp-Source: AGHT+IFtihXA1ixlkcjuYPXGi/3nyMcTJqsYkMUIphzCaA6DcRFEslloczpIHH8OqTcj441vz3MgX+UAWJI=
X-Received: from pjb7.prod.google.com ([2002:a17:90b:2f07:b0:2fe:800f:23a])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:4c02:b0:2fe:80cb:ac05
 with SMTP id 98e67ed59e1d1-310e96c946emr1657552a91.9.1747957964380; Thu, 22
 May 2025 16:52:44 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:16 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-7-seanjc@google.com>
Subject: [PATCH v3 06/13] sched/wait: Drop WQ_FLAG_EXCLUSIVE from add_wait_queue_priority()
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Drop the setting of WQ_FLAG_EXCLUSIVE from add_wait_queue_priority() and
instead have callers manually add the flag prior to adding their structure
to the queue.  Blindly setting WQ_FLAG_EXCLUSIVE is flawed, as the nature
of exclusive, priority waiters means that only the first waiter added will
ever receive notifications.

Pushing the flawed behavior to callers will allow fixing the problem one
hypervisor at a time (KVM added the flawed API, and then KVM's code was
copy+pasted nearly verbatim by Xen and Hyper-V), and will also allow for
adding an API that provides true exclusivity, i.e. that guarantees at most
one priority waiter is in the queue.

Opportunistically add a comment in Hyper-V to call out the mess.  Xen
privcmd's irqfd_wakefup() doesn't actually operate in exclusive mode, i.e.
can be "fixed" simply by dropping WQ_FLAG_EXCLUSIVE.  And KVM is primed to
switch to the aforementioned fully exclusive API, i.e. won't be carrying
the flawed code for long.

No functional change intended.

Signed-off-by: Sean Christopherson 
---
 drivers/hv/mshv_eventfd.c | 8 ++++++++
 drivers/xen/privcmd.c     | 1 +
 kernel/sched/wait.c       | 4 ++--
 virt/kvm/eventfd.c        | 1 +
 4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/mshv_eventfd.c b/drivers/hv/mshv_eventfd.c
index 8dd22be2ca0b..b348928871c2 100644
--- a/drivers/hv/mshv_eventfd.c
+++ b/drivers/hv/mshv_eventfd.c
@@ -368,6 +368,14 @@ static void mshv_irqfd_queue_proc(struct file *file, wait_queue_head_t *wqh,
 			container_of(polltbl, struct mshv_irqfd, irqfd_polltbl);
 
 	irqfd->irqfd_wqh = wqh;
+
+	/*
+	 * TODO: Ensure there isn't already an exclusive, priority waiter, e.g.
+	 * that the irqfd isn't already bound to another partition.  Only the
+	 * first exclusive waiter encountered will be notified, and
+	 * add_wait_queue_priority() doesn't enforce exclusivity.
+	 */
+	irqfd->irqfd_wait.flags |= WQ_FLAG_EXCLUSIVE;
 	add_wait_queue_priority(wqh, &irqfd->irqfd_wait);
 }
 
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 13a10f3294a8..c08ec8a7d27c 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -957,6 +957,7 @@ irqfd_poll_func(struct file *file, wait_queue_head_t *wqh, poll_table *pt)
 	struct privcmd_kernel_irqfd *kirqfd =
 		container_of(pt, struct privcmd_kernel_irqfd, pt);
 
+	kirqfd->wait.flags |= WQ_FLAG_EXCLUSIVE;
 	add_wait_queue_priority(wqh, &kirqfd->wait);
 }
 
diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index 51e38f5f4701..4ab3ab195277 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -40,7 +40,7 @@ void add_wait_queue_priority(struct wait_queue_head *wq_head, struct wait_queue_
 {
 	unsigned long flags;
 
-	wq_entry->flags |= WQ_FLAG_EXCLUSIVE | WQ_FLAG_PRIORITY;
+	wq_entry->flags |= WQ_FLAG_PRIORITY;
 	spin_lock_irqsave(&wq_head->lock, flags);
 	__add_wait_queue(wq_head, wq_entry);
 	spin_unlock_irqrestore(&wq_head->lock, flags);
@@ -64,7 +64,7 @@ EXPORT_SYMBOL(remove_wait_queue);
  * the non-exclusive tasks. Normally, exclusive tasks will be at the end of
  * the list and any non-exclusive tasks will be woken first. A priority task
  * may be at the head of the list, and can consume the event without any other
- * tasks being woken.
+ * tasks being woken if it's also an exclusive task.
  *
  * There are circumstances in which we can try to wake a task which has already
  * started to run but is not in state TASK_RUNNING. try_to_wake_up() returns
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 04877b297267..c7969904637a 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -316,6 +316,7 @@ static void kvm_irqfd_register(struct file *file, wait_queue_head_t *wqh,
 	init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
 
 	spin_release(&kvm->irqfds.lock.dep_map, _RET_IP_);
+	irqfd->wait.flags |= WQ_FLAG_EXCLUSIVE;
 	add_wait_queue_priority(wqh, &irqfd->wait);
 	spin_acquire(&kvm->irqfds.lock.dep_map, 0, 0, _RET_IP_);
 
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994745.1377576 (Exim 4.92)
	(envelope-from )
	id 1uIFiQ-0000l0-Lh; Thu, 22 May 2025 23:52:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994745.1377576; Thu, 22 May 2025 23: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 1uIFiQ-0000je-Eh; Thu, 22 May 2025 23:52:46 +0000
Received: by outflank-mailman (input) for mailman id 994745;
 Thu, 22 May 2025 23:52:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFiO-0007r8-Rz
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:44 +0000
Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com
 [2607:f8b0:4864:20::549])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id da6b248c-3767-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 01:52:44 +0200 (CEST)
Received: by mail-pg1-x549.google.com with SMTP id
 41be03b00d2f7-b26db9af463so7984317a12.2
 for ; Thu, 22 May 2025 16:52: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" 
X-Inumbo-ID: da6b248c-3767-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957963; x=1748562763; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=LLDErP7lwjTldw1/pS35D8l5zAYowrsUowCS37TMy6E=;
        b=4Z9HlAh0tIAtkeGWx2MKYDQeKydD6nTNydX7x10wNJMA00pbuOzz6ENBFpM85VhCmQ
         r6o8aje4oIo0pSJKXY0Z9nJzDgaVXalyJxcfnmN0q0qslADmp26OVxyuJ5nXsQk4wtnG
         fP2nGZJmCRzEzrHT3mXelUVWF2l9AmhHtJXLlhrC6ZYNq+In/z6iVECUW2ht2Hjka9re
         REbPLCQWAOtMe0ndDarvjbZwlI6HEFQ7rGpnzwwb9NFtYu5f7JdXszi7ZMYcE7y2GiPz
         uqNDTR6TFED8fjOUVWq35jTo30rvHnP4fWkHYYTBf6SQ/m59cCM6lG4qNDhlfl+02bQA
         Ev4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957963; x=1748562763;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=LLDErP7lwjTldw1/pS35D8l5zAYowrsUowCS37TMy6E=;
        b=h7t+bDUeVP6cffMOW6e/NYYFGW05EpuHxzdTA6E4fkbN19rTxZXNlGMHof9WabT5zs
         yZTkO/cT0tj4EfkjsjcKIPYtXsuHV/roJ2XDmQzOTQJXMq7qFzPOgLeZ4BZVzavXyZnQ
         gfqYoPmkezJxJdQQ5oBJubewhb9IzuE86kTjxoy4TXEUz8xI/sVMvOkLqRR9qPendpfM
         gMnuFrIgjY+5P6nqCVp3s6eCfhonIKihfwdazyu3fr9pHVvfFZtWJuE1BcXV//RzBnJG
         24L7FrmGTKEYzU5rXVhgxt52CwK18gMZysWgaoCxfLWzfk0cs8FIfoQTnZChY6+i4ZWx
         30fA==
X-Forwarded-Encrypted: i=1; AJvYcCWoznDIyUEmGGyWWuafqJlAvO4LE/UFGvtrVvpiHPpVKCHtzCEsHWU+bPZTz8rDgCVaybVn3tCIlv4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyQ/uytPyI5dunC0cfvq/nvdIYzYKx91lJ3qtk6XXPcYi429SRi
	pDBMJBh5P0seY/qb+BByb9RNNfY7/1YTycHtxt4Me/0rMdiNIcgX4FEZcj2nNqJZfBnXyNjPbFf
	vvYSylQ==
X-Google-Smtp-Source: AGHT+IHOq6Cu35CTphJBsObc11lhP6kmwx8FMCg+YC2dNqr/wE8KG8ou9486KEEIS+EkPDFQhABlYWoiNSA=
X-Received: from plhi16.prod.google.com ([2002:a17:903:2ed0:b0:22e:4a61:5545])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:e808:b0:22e:3c2:d477
 with SMTP id d9443c01a7336-233f21ae905mr11694945ad.25.1747957962830; Thu, 22
 May 2025 16:52:42 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:15 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-6-seanjc@google.com>
Subject: [PATCH v3 05/13] KVM: Add irqfd to eventfd's waitqueue while holding irqfds.lock
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Add an irqfd to its target eventfd's waitqueue while holding irqfds.lock,
which is mildly terrifying but functionally safe.  irqfds.lock is taken
inside the waitqueue's lock, but if and only if the eventfd is being
released, i.e. that path is mutually exclusive with registration as KVM
holds a reference to the eventfd (and obviously must do so to avoid UAF).

This will allow using the eventfd's waitqueue to enforce KVM's requirement
that eventfd is assigned to at most one irqfd, without introducing races.

Signed-off-by: Sean Christopherson 
---
 virt/kvm/eventfd.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 99274d60335d..04877b297267 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -204,6 +204,11 @@ irqfd_wakeup(wait_queue_entry_t *wait, unsigned mode, int sync, void *key)
 	int ret = 0;
 
 	if (flags & EPOLLIN) {
+		/*
+		 * WARNING: Do NOT take irqfds.lock in any path except EPOLLHUP,
+		 * as KVM holds irqfds.lock when registering the irqfd with the
+		 * eventfd.
+		 */
 		u64 cnt;
 		eventfd_ctx_do_read(irqfd->eventfd, &cnt);
 
@@ -225,6 +230,11 @@ irqfd_wakeup(wait_queue_entry_t *wait, unsigned mode, int sync, void *key)
 		/* The eventfd is closing, detach from KVM */
 		unsigned long iflags;
 
+		/*
+		 * Taking irqfds.lock is safe here, as KVM holds a reference to
+		 * the eventfd when registering the irqfd, i.e. this path can't
+		 * be reached while kvm_irqfd_add() is running.
+		 */
 		spin_lock_irqsave(&kvm->irqfds.lock, iflags);
 
 		/*
@@ -296,16 +306,21 @@ static void kvm_irqfd_register(struct file *file, wait_queue_head_t *wqh,
 
 	list_add_tail(&irqfd->list, &kvm->irqfds.items);
 
-	spin_unlock_irq(&kvm->irqfds.lock);
-
 	/*
 	 * Add the irqfd as a priority waiter on the eventfd, with a custom
 	 * wake-up handler, so that KVM *and only KVM* is notified whenever the
-	 * underlying eventfd is signaled.
+	 * underlying eventfd is signaled.  Temporarily lie to lockdep about
+	 * holding irqfds.lock to avoid a false positive regarding potential
+	 * deadlock with irqfd_wakeup() (see irqfd_wakeup() for details).
 	 */
 	init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
 
+	spin_release(&kvm->irqfds.lock.dep_map, _RET_IP_);
 	add_wait_queue_priority(wqh, &irqfd->wait);
+	spin_acquire(&kvm->irqfds.lock.dep_map, 0, 0, _RET_IP_);
+
+	spin_unlock_irq(&kvm->irqfds.lock);
+
 	p->ret = 0;
 }
 
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994743.1377547 (Exim 4.92)
	(envelope-from )
	id 1uIFiO-00007N-NX; Thu, 22 May 2025 23:52:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994743.1377547; Thu, 22 May 2025 23: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 1uIFiO-00007D-GQ; Thu, 22 May 2025 23:52:44 +0000
Received: by outflank-mailman (input) for mailman id 994743;
 Thu, 22 May 2025 23:52:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFiM-0007r7-G9
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:42 +0000
Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com
 [2607:f8b0:4864:20::1049])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d870caa6-3767-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 01:52:41 +0200 (CEST)
Received: by mail-pj1-x1049.google.com with SMTP id
 98e67ed59e1d1-30e895056f0so9150893a91.3
 for ; Thu, 22 May 2025 16:52: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" 
X-Inumbo-ID: d870caa6-3767-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957959; x=1748562759; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=xAZka5nPnl0zzhBog63136UQG1pDC/RMIYFF12/LKjA=;
        b=MfriG8WAWJLdD2wlERMwN89EIDy+/ncmRYs8fyD7yjdTDWe0PioxwzLRblp4vZzPjV
         BJ3k4k0vhCICdd/tkxpp0E3H2CIBFw9QqryATTbaTvVi2Tnt9Mn9zeL8/x9yaVp/jtbU
         5g08/k+2qGN7M8FKSFv+u7bObQRtqXeyUdyURrfT48I5WGBj+aTiaUulnZn7qCU5aqtx
         0KQQJb5WF8hT79cGTZ1E2n7nCk3FSpFTTCDe7Hn1WR4lkjUWiZ5Ii2r6owG5YurXAJBM
         KL0ad9eYzLedPE3du7aNzldwXgj9GGpUZ3axY6nDfAp+Fkz0/4yZnjJCRke4IL3IFNqH
         0CGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957959; x=1748562759;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=xAZka5nPnl0zzhBog63136UQG1pDC/RMIYFF12/LKjA=;
        b=u0xje4XRU1MFa7OBZs34YZD73CSfyQXriTYkAbD56yz7LWXsXOn48rMV83FRNp7QqP
         1+5HH+yH+6wBYnwS2e+XtKH1lQyi4wEntABMjQeuI7FnMptkxw2roaTn2+Uu31kVsXgm
         CYHvaIlRKQ9jZftq5BYUhuTeuXrafUeO4nJuOM29ODzNQn31+bajBSpetrxRrabMuND6
         WrIyL9CHzaf9Zzib7faVQG9+nO4N8baxXGsEqU8WP15DxYyymtjPaqZ6Hx2q+oGpoZjM
         k9qMhY9de/RbVExoetD8q3rHoQet8plon851XkguAAtmkYL6vmfywzTGjX70p+ixD7Et
         To7g==
X-Forwarded-Encrypted: i=1; AJvYcCXHemQDUJjr01+EMurf2cbkwtaOvJ/Mzw0FsSTLWmU+I4y0ExjeSUwweSJRgJl0Mze0XxG85WD1GGc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwEE3c8B0k9Cchu4a0lKmMZ8UWZ305LzHUdWZX2GQopcrU+J593
	t2mj4ypjmKmNvbWr8+jfLWGvMO4iBj3Je12BGD6zSV9usJlCQlhp8DcMORcV/9EhEbFfBS/hSvS
	JStyTBg==
X-Google-Smtp-Source: AGHT+IFTlML74x7TQE+fmnLc60J6Zc3gXJFbZA8aAHEiRQLh+dPZA/uq2RIsrb3gSzl5/rJlFLqbanul+U8=
X-Received: from pja13.prod.google.com ([2002:a17:90b:548d:b0:2ef:786a:1835])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:51cb:b0:2ee:fa0c:cebc
 with SMTP id 98e67ed59e1d1-310e96e87e5mr1351003a91.20.1747957959540; Thu, 22
 May 2025 16:52:39 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:13 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-4-seanjc@google.com>
Subject: [PATCH v3 03/13] KVM: Initialize irqfd waitqueue callback when adding
 to the queue
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Initialize the irqfd waitqueue callback immediately prior to inserting the
irqfd into the eventfd's waitqueue.  Pre-initializing the state in a
completely different context is all kinds of confusing, and incorrectly
suggests that the waitqueue function needs to be initialize prior to
vfs_poll().

Signed-off-by: Sean Christopherson 
---
 virt/kvm/eventfd.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 42c02c35e542..8b9a87daa2bb 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -256,6 +256,13 @@ static void kvm_irqfd_register(struct file *file, wait_queue_head_t *wqh,
 	struct kvm_irqfd_pt *p = container_of(pt, struct kvm_irqfd_pt, pt);
 	struct kvm_kernel_irqfd *irqfd = p->irqfd;
 
+	/*
+	 * Add the irqfd as a priority waiter on the eventfd, with a custom
+	 * wake-up handler, so that KVM *and only KVM* is notified whenever the
+	 * underlying eventfd is signaled.
+	 */
+	init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
+
 	add_wait_queue_priority(wqh, &irqfd->wait);
 }
 
@@ -395,12 +402,6 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
 		mutex_unlock(&kvm->irqfds.resampler_lock);
 	}
 
-	/*
-	 * Install our own custom wake-up handling so we are notified via
-	 * a callback whenever someone signals the underlying eventfd
-	 */
-	init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
-
 	/*
 	 * Set the irqfd routing and add it to KVM's list before registering
 	 * the irqfd with the eventfd, so that the routing information is valid
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994744.1377552 (Exim 4.92)
	(envelope-from )
	id 1uIFiP-0000Aa-0U; Thu, 22 May 2025 23:52:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994744.1377552; Thu, 22 May 2025 23: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 1uIFiO-0000A0-Or; Thu, 22 May 2025 23:52:44 +0000
Received: by outflank-mailman (input) for mailman id 994744;
 Thu, 22 May 2025 23:52:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFiN-0007r8-9m
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:43 +0000
Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com
 [2607:f8b0:4864:20::54a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d9627086-3767-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 01:52:42 +0200 (CEST)
Received: by mail-pg1-x54a.google.com with SMTP id
 41be03b00d2f7-b090c7c2c6aso5541503a12.0
 for ; Thu, 22 May 2025 16:52: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" 
X-Inumbo-ID: d9627086-3767-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957961; x=1748562761; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=f7qvTnT5s0mxP5eCWb+NaTk8UKR3m+k6rkKzLbxKznI=;
        b=d/pYycVGIAw9dOdEkv1ZwdExtSGoDw3+LkySo2/0B3lQ667/oUPDoRbTBkQBqZdLac
         BC72uYdMjf9fdA1wJ0nP8Amu7jG15GhoWm0fODVQEcRDnK4lJwY7VqOTq5eRPzxeC1kT
         ED3UUGN5EBWPgexAd8MgGlQo53I1m7ETxf7GVD3sDeaGY1DB9185ezrFHXff9CKpqD3X
         rAuv/zMS6BZRtMfS95ZPQmco3R3b4c9sUrVW15JG3pyKqw36H7QHf/uJhRsGSsd98QMC
         EBrTfZAZNlina0eH6g3W9EM10dQoJXv+lxGAn4oHYHavBL3M2jl6KTm2i79U6bsANo7+
         oAGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957961; x=1748562761;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=f7qvTnT5s0mxP5eCWb+NaTk8UKR3m+k6rkKzLbxKznI=;
        b=fe9VIcU49zOybkcXPPDSSkNYEDRbOQdPWQJmfKxj2WuOaxdc6Zh1LU385PoIZNAbMh
         syyJd/zu3x1DfuY/eAn1EH6Xqsi9xhpiaYAZ73fsdhW9gjQ2AGwyU7lAMfvbPJEOpQdX
         nxen1jw99nIpKeROQ18UwPo3huO3ulkKGnc2VBM0CZrinyxDudFROFQ9uMvId4BVZEPZ
         nR+3++1r2jyHC1LhS67B5TKhaBBgktZVdgBj3sFP8mp2utwN+l1N8ewJSJAE9q2PZSxv
         OF02DQ1r2in6PgINhPf1u1cW1+MpWkGJXWYworrSDqRxH5M4cfg+MY2Vl786J7FmLJcs
         ko/g==
X-Forwarded-Encrypted: i=1; AJvYcCVbtrjSLR/iFmzfjgta9ASnb9n/J4iBIDYZKXUvSXt1wuHGkVYmvSYfz1aZNbCqqxj63EgahTigkww=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwrpxGU2ACbm8ZhBxajLd/LFboO6rf/X61FnRWHNfAfDcugUCb9
	Ry8KqGe6rN+xsg+IK+sdpF+uGJPoAhZKZ5rSvTjbB362l2KYHhdgth0IzGAPIJ1A5JL758eqxn6
	1H3Pixg==
X-Google-Smtp-Source: AGHT+IFhLIWMr3ct7tle+BqkfXynUt92dE5T1Ga0fMI6fA92WD5PFOynQ9QIYOuFaunMobUQi3Ht7v2BK94=
X-Received: from pjbsz13.prod.google.com ([2002:a17:90b:2d4d:b0:30e:7d59:f3a7])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:dfc7:b0:301:c5cb:7b13
 with SMTP id 98e67ed59e1d1-30e830c6247mr35762810a91.3.1747957961111; Thu, 22
 May 2025 16:52:41 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:14 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-5-seanjc@google.com>
Subject: [PATCH v3 04/13] KVM: Add irqfd to KVM's list via the vfs_poll() callback
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Add the irqfd structure to KVM's list of irqfds in kvm_irqfd_register(),
i.e. via the vfs_poll() callback.  This will allow taking irqfds.lock
across the entire registration sequence (add to waitqueue, add to list),
and more importantly will allow inserting into KVM's list if and only if
adding to the waitqueue succeeds (spoiler alert), without needing to
juggle return codes in weird ways.

Signed-off-by: Sean Christopherson 
---
 virt/kvm/eventfd.c | 102 +++++++++++++++++++++++++--------------------
 1 file changed, 57 insertions(+), 45 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 8b9a87daa2bb..99274d60335d 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -245,34 +245,14 @@ irqfd_wakeup(wait_queue_entry_t *wait, unsigned mode, int sync, void *key)
 	return ret;
 }
 
-struct kvm_irqfd_pt {
-	struct kvm_kernel_irqfd *irqfd;
-	poll_table pt;
-};
-
-static void kvm_irqfd_register(struct file *file, wait_queue_head_t *wqh,
-			       poll_table *pt)
-{
-	struct kvm_irqfd_pt *p = container_of(pt, struct kvm_irqfd_pt, pt);
-	struct kvm_kernel_irqfd *irqfd = p->irqfd;
-
-	/*
-	 * Add the irqfd as a priority waiter on the eventfd, with a custom
-	 * wake-up handler, so that KVM *and only KVM* is notified whenever the
-	 * underlying eventfd is signaled.
-	 */
-	init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
-
-	add_wait_queue_priority(wqh, &irqfd->wait);
-}
-
-/* Must be called under irqfds.lock */
 static void irqfd_update(struct kvm *kvm, struct kvm_kernel_irqfd *irqfd)
 {
 	struct kvm_kernel_irq_routing_entry *e;
 	struct kvm_kernel_irq_routing_entry entries[KVM_NR_IRQCHIPS];
 	int n_entries;
 
+	lockdep_assert_held(&kvm->irqfds.lock);
+
 	n_entries = kvm_irq_map_gsi(kvm, entries, irqfd->gsi);
 
 	write_seqcount_begin(&irqfd->irq_entry_sc);
@@ -286,6 +266,49 @@ static void irqfd_update(struct kvm *kvm, struct kvm_kernel_irqfd *irqfd)
 	write_seqcount_end(&irqfd->irq_entry_sc);
 }
 
+struct kvm_irqfd_pt {
+	struct kvm_kernel_irqfd *irqfd;
+	struct kvm *kvm;
+	poll_table pt;
+	int ret;
+};
+
+static void kvm_irqfd_register(struct file *file, wait_queue_head_t *wqh,
+			       poll_table *pt)
+{
+	struct kvm_irqfd_pt *p = container_of(pt, struct kvm_irqfd_pt, pt);
+	struct kvm_kernel_irqfd *irqfd = p->irqfd;
+	struct kvm_kernel_irqfd *tmp;
+	struct kvm *kvm = p->kvm;
+
+	spin_lock_irq(&kvm->irqfds.lock);
+
+	list_for_each_entry(tmp, &kvm->irqfds.items, list) {
+		if (irqfd->eventfd != tmp->eventfd)
+			continue;
+		/* This fd is used for another irq already. */
+		p->ret = -EBUSY;
+		spin_unlock_irq(&kvm->irqfds.lock);
+		return;
+	}
+
+	irqfd_update(kvm, irqfd);
+
+	list_add_tail(&irqfd->list, &kvm->irqfds.items);
+
+	spin_unlock_irq(&kvm->irqfds.lock);
+
+	/*
+	 * Add the irqfd as a priority waiter on the eventfd, with a custom
+	 * wake-up handler, so that KVM *and only KVM* is notified whenever the
+	 * underlying eventfd is signaled.
+	 */
+	init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
+
+	add_wait_queue_priority(wqh, &irqfd->wait);
+	p->ret = 0;
+}
+
 #if IS_ENABLED(CONFIG_HAVE_KVM_IRQ_BYPASS)
 void __attribute__((weak)) kvm_arch_irq_bypass_stop(
 				struct irq_bypass_consumer *cons)
@@ -315,7 +338,7 @@ bool __attribute__((weak)) kvm_arch_irqfd_route_changed(
 static int
 kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
 {
-	struct kvm_kernel_irqfd *irqfd, *tmp;
+	struct kvm_kernel_irqfd *irqfd;
 	struct eventfd_ctx *eventfd = NULL, *resamplefd = NULL;
 	struct kvm_irqfd_pt irqfd_pt;
 	int ret;
@@ -414,32 +437,22 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
 	 */
 	idx = srcu_read_lock(&kvm->irq_srcu);
 
-	spin_lock_irq(&kvm->irqfds.lock);
-
-	ret = 0;
-	list_for_each_entry(tmp, &kvm->irqfds.items, list) {
-		if (irqfd->eventfd != tmp->eventfd)
-			continue;
-		/* This fd is used for another irq already. */
-		ret = -EBUSY;
-		goto fail_duplicate;
-	}
-
-	irqfd_update(kvm, irqfd);
-
-	list_add_tail(&irqfd->list, &kvm->irqfds.items);
-
-	spin_unlock_irq(&kvm->irqfds.lock);
-
 	/*
-	 * Register the irqfd with the eventfd by polling on the eventfd.  If
-	 * there was en event pending on the eventfd prior to registering,
-	 * manually trigger IRQ injection.
+	 * Register the irqfd with the eventfd by polling on the eventfd, and
+	 * simultaneously and the irqfd to KVM's list.  If there was en event
+	 * pending on the eventfd prior to registering, manually trigger IRQ
+	 * injection.
 	 */
 	irqfd_pt.irqfd = irqfd;
+	irqfd_pt.kvm = kvm;
 	init_poll_funcptr(&irqfd_pt.pt, kvm_irqfd_register);
 
 	events = vfs_poll(fd_file(f), &irqfd_pt.pt);
+
+	ret = irqfd_pt.ret;
+	if (ret)
+		goto fail_poll;
+
 	if (events & EPOLLIN)
 		schedule_work(&irqfd->inject);
 
@@ -460,8 +473,7 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
 	srcu_read_unlock(&kvm->irq_srcu, idx);
 	return 0;
 
-fail_duplicate:
-	spin_unlock_irq(&kvm->irqfds.lock);
+fail_poll:
 	srcu_read_unlock(&kvm->irq_srcu, idx);
 fail:
 	if (irqfd->resampler)
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994740.1377516 (Exim 4.92)
	(envelope-from )
	id 1uIFiJ-0007rQ-Ps; Thu, 22 May 2025 23:52:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994740.1377516; Thu, 22 May 2025 23:52: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 1uIFiJ-0007rJ-N0; Thu, 22 May 2025 23:52:39 +0000
Received: by outflank-mailman (input) for mailman id 994740;
 Thu, 22 May 2025 23:52:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFiJ-0007r7-8G
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:39 +0000
Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com
 [2607:f8b0:4864:20::1049])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d56e26af-3767-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 01:52:36 +0200 (CEST)
Received: by mail-pj1-x1049.google.com with SMTP id
 98e67ed59e1d1-30e6980471cso6915926a91.1
 for ; Thu, 22 May 2025 16:52: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" 
X-Inumbo-ID: d56e26af-3767-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957954; x=1748562754; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:mime-version:date:reply-to:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Tip5ipIFHbSR2IYZnXAE5GbVsPWdm0Tjm7OJATFbViQ=;
        b=zXpFV5PRdu0ve+1cxT3eEh62ss/B8NbfeQp4AubYb5W65veR5+bByEytTs+2UUIAad
         kcgMxELiJiS42rxKSUxtOxpv3d/4KApZQ1+aZI0O1yzZke8nSCByLuRaf/dihUTC5wX+
         Y9PKrSPH+ZYCHiQlVfYWoXQthkeM2BVqK0P9O/+Fv05neuDEmJ/oWjSIM9JoYO4viGaw
         Utag76cp22qeFZkBjUoCk80MQzxN+aqsSEhDMXwOxJW3vd+5CkjuQhHJnca+prn0d+AK
         JCH+5PAsGev6/eU+YeV9HaZIeuBtbJfSzC9dPat8elLNR6XaSiTjcWlP9ztN/zxzXP5i
         Sr6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957954; x=1748562754;
        h=cc:to:from:subject:message-id:mime-version:date:reply-to
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Tip5ipIFHbSR2IYZnXAE5GbVsPWdm0Tjm7OJATFbViQ=;
        b=aWQ+PmMteAssY4lQW6Ow9+xzBqH3so9yrNbpCXePvEAXxutR47JXBtnyeNDyZO0g+h
         LZ7fk1D8VQassDduK+YfqZWJQSEuQ4JYu0FndEzHG3GClnEH2PxlzdoVkd4nfARWGDmf
         vSSs5x1hS+UpM9a3McVCW+uqVCIzt9nk55B7k5KeGjXt5o/zzZLPO6V/dsHnpWzPexuU
         MlZkR5e8i5kFPU3LErCjaqxvv9L7iB3gu0p1nVG3QyJONjPZoGbVWMbUCSZh0v/L495Q
         iNv2smCabzwJt6CNQ2L6/QHwKRJ7hnVv6zQgGqag7A51rIamssqcHw25Jog8X1W3yiKC
         8Rhw==
X-Forwarded-Encrypted: i=1; AJvYcCV1tdmt7DwOtbn3kNhD32SGsXMTOxxChL4FZ4yfFUx8mlqSFplBvKTgzltIc20haiE0sm9bdFo0inc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+TUtLtUkh1eUWdeQ2gGjqH3GbTjNgxSM0Ql6eVyltFKJPCWNx
	axbArih7sBS+H61ZAkvS6/wwShn4W+fSbN36ML2EII4DetQrkPTBseHzJbDKKx0mT7Robmbk4mx
	qkCJ09w==
X-Google-Smtp-Source: AGHT+IFoFNCkbt8aJJ0xnDKCzmCnIh6gGll4rd5AbALinv7jGcAxGvJdpWgEmk1cX+UlvCwIOcTYID0HpNU=
X-Received: from pjtu15.prod.google.com ([2002:a17:90a:c88f:b0:30a:2020:e2bd])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:d604:b0:303:75a7:26a4
 with SMTP id 98e67ed59e1d1-30e7d4fea75mr43035958a91.7.1747957954327; Thu, 22
 May 2025 16:52:34 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:10 -0700
Mime-Version: 1.0
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-1-seanjc@google.com>
Subject: [PATCH v3 00/13] KVM: Make irqfd registration globally unique
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Non-KVM folks,

I am hoping to route this through the KVM tree (6.17 or later), as the non-KVM
changes should be glorified nops.  Please holler if you object to that idea.

Hyper-V folks in particular, let me know if you want a stable topic branch/tag,
e.g. on the off chance you want to make similar changes to the Hyper-V code,
and I'll make sure that happens.


As for what this series actually does...

Rework KVM's irqfd registration to require that an eventfd is bound to at
most one irqfd throughout the entire system.  KVM currently disallows
binding an eventfd to multiple irqfds for a single VM, but doesn't reject
attempts to bind an eventfd to multiple VMs.

This is obviously an ABI change, but I'm fairly confident that it won't
break userspace, because binding an eventfd to multiple irqfds hasn't
truly worked since commit e8dbf19508a1 ("kvm/eventfd: Use priority waitqueue
to catch events before userspace").  A somewhat undocumented, and perhaps
even unintentional, side effect of suppressing eventfd notifications for
userspace is that the priority+exclusive behavior also suppresses eventfd
notifications for any subsequent waiters, even if they are priority waiters.
I.e. only the first VM with an irqfd+eventfd binding will get notifications.

And for IRQ bypass, a.k.a. device posted interrupts, globally unique
bindings are a hard requirement (at least on x86; I assume other archs are
the same).  KVM and the IRQ bypass manager kinda sorta handle this, but in
the absolute worst way possible (IMO).  Instead of surfacing an error to
userspace, KVM silently ignores IRQ bypass registration errors.

The motivation for this series is to harden against userspace goofs.  AFAIK,
we (Google) have never actually had a bug where userspace tries to assign
an eventfd to multiple VMs, but the possibility has come up in more than one
bug investigation (our intra-host, a.k.a. copyless, migration scheme
transfers eventfds from the old to the new VM when updating the host VMM).

v3:
 - Retain WQ_FLAG_EXCLUSIVE in mshv_eventfd.c, which snuck in between v1
   and v2. [Peter]
 - Use EXPORT_SYMBOL_GPL. [Peter]
 - Move WQ_FLAG_EXCLUSIVE out of add_wait_queue_priority() in a prep patch
   so that the affected subsystems are more explicitly documented (and then
   immediately drop the flag from drivers/xen/privcmd.c, which amusingly
   hides that file from the diff stats).

v2:
 - https://lore.kernel.org/all/20250519185514.2678456-1-seanjc@google.com
 - Use guard(spinlock_irqsave). [Prateek]

v1: https://lore.kernel.org/all/20250401204425.904001-1-seanjc@google.com


Sean Christopherson (13):
  KVM: Use a local struct to do the initial vfs_poll() on an irqfd
  KVM: Acquire SCRU lock outside of irqfds.lock during assignment
  KVM: Initialize irqfd waitqueue callback when adding to the queue
  KVM: Add irqfd to KVM's list via the vfs_poll() callback
  KVM: Add irqfd to eventfd's waitqueue while holding irqfds.lock
  sched/wait: Drop WQ_FLAG_EXCLUSIVE from add_wait_queue_priority()
  xen: privcmd: Don't mark eventfd waiter as EXCLUSIVE
  sched/wait: Add a waitqueue helper for fully exclusive priority
    waiters
  KVM: Disallow binding multiple irqfds to an eventfd with a priority
    waiter
  KVM: Drop sanity check that per-VM list of irqfds is unique
  KVM: selftests: Assert that eventfd() succeeds in Xen shinfo test
  KVM: selftests: Add utilities to create eventfds and do KVM_IRQFD
  KVM: selftests: Add a KVM_IRQFD test to verify uniqueness requirements

 drivers/hv/mshv_eventfd.c                     |   8 ++
 include/linux/kvm_irqfd.h                     |   1 -
 include/linux/wait.h                          |   2 +
 kernel/sched/wait.c                           |  22 ++-
 tools/testing/selftests/kvm/Makefile.kvm      |   1 +
 tools/testing/selftests/kvm/arm64/vgic_irq.c  |  12 +-
 .../testing/selftests/kvm/include/kvm_util.h  |  40 ++++++
 tools/testing/selftests/kvm/irqfd_test.c      | 130 ++++++++++++++++++
 .../selftests/kvm/x86/xen_shinfo_test.c       |  21 +--
 virt/kvm/eventfd.c                            | 130 +++++++++++++-----
 10 files changed, 302 insertions(+), 65 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/irqfd_test.c


base-commit: 45eb29140e68ffe8e93a5471006858a018480a45
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994742.1377531 (Exim 4.92)
	(envelope-from )
	id 1uIFiL-00087O-9u; Thu, 22 May 2025 23:52:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994742.1377531; Thu, 22 May 2025 23:52: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 1uIFiL-00086H-4S; Thu, 22 May 2025 23:52:41 +0000
Received: by outflank-mailman (input) for mailman id 994742;
 Thu, 22 May 2025 23:52:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFiJ-0007r8-Oi
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:39 +0000
Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com
 [2607:f8b0:4864:20::1049])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d76ab4e3-3767-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 01:52:39 +0200 (CEST)
Received: by mail-pj1-x1049.google.com with SMTP id
 98e67ed59e1d1-30ed6bd1b4cso7380217a91.0
 for ; Thu, 22 May 2025 16:52: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" 
X-Inumbo-ID: d76ab4e3-3767-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957958; x=1748562758; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=tVNl4A6Kx8naMJGZ1E0eQITkQbAsVFllM1f24lX+kzQ=;
        b=noDC6S+BticMiYcuNJKOkeTMtP4beT8fdjgXk6B0+hiVy6R4DQwfvLSFf21OvymTih
         nTzV4rpqxWLOHdP2cy4SQqKuSX7TDw7regP1JEJ2H5LSDrxoPjx20v1xw7WYZ/li4WfM
         51IwvFOB8odrMuDFYooBdP1tDMxeuDTkn1NUTXyfK74vsu0plcOYPXlyXdjDAj/4mBI0
         /c70B+VBReZWhFoqOsTqELQvNrAyPWYIYw6pAtm9GOLKQlKJg5v+oAhTjp/QiLZnO1Mw
         6oVQnu+cil44dTm77E/dOJKzMKbMWXwpR/TsrnUAZKzpdQ4/VaJ7erUVhsWEZVLrpkSZ
         Zgng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957958; x=1748562758;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=tVNl4A6Kx8naMJGZ1E0eQITkQbAsVFllM1f24lX+kzQ=;
        b=E2/ibupDYlJfZkUNUPUjtLEEHkM7fSppU/ifN1Xw9anmuT18PVHDzWlAd2tfOw4Qsj
         uWc7dl+vkhvUg/JQPJ1C8bLuWYMM9/KXJeTaQOv5khcom48eJuwzhxGpf1iwa+Fj9kQW
         IB+FIKG8rixLKu8fQDJgi2pmyYrRuX/SiviSywaPuy46eU3w6N3wZ1BjbQdHByD1UBIF
         9hooiGurwmiTM9SZAlOzmehOm2mi2js6f/yxn2UV6n8gfnmLqJmydHp99pfXHpvZfLnj
         Axvpbqdubezv+E1uXpZ6SzXyT/8mwxNgfuylW4zjkC5SoVWZ1JLbYd0RTe/AgEn9HpeA
         8UHQ==
X-Forwarded-Encrypted: i=1; AJvYcCXuf7GVcReFheD8cvFIk7Mt5ivddB1yGj+xnRSJirVKjFDgXi9Ce6/H6rUHFBsgskFgk9Wo3syk3YI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx5PBSRBY6LxxtNi6IA9XmnURghqLf8d669twTPw8cxhrNaTWib
	Yi7bQKgUoRhruaRWFtTd7aKI6g1LRwtAgthU2ZZIt0QMCvWRJF+9ZnvmDw2x3SmCuFoayGEr1XX
	JdY1YUw==
X-Google-Smtp-Source: AGHT+IE81WM2WL+8EnB/6FCP5IRyDnOFUDXq+HJraLf558ghdMXYLyDo9m5RHDzKNMgflX319IgqoMhIQGU=
X-Received: from pjg13.prod.google.com ([2002:a17:90b:3f4d:b0:2ee:4a90:3d06])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:e70f:b0:30a:2173:9f0b
 with SMTP id 98e67ed59e1d1-30e8322596bmr38028577a91.28.1747957957818; Thu, 22
 May 2025 16:52:37 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:12 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-3-seanjc@google.com>
Subject: [PATCH v3 02/13] KVM: Acquire SCRU lock outside of irqfds.lock during assignment
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Acquire SRCU outside of irqfds.lock so that the locking is symmetrical,
and add a comment explaining why on earth KVM holds SRCU for so long.

Signed-off-by: Sean Christopherson 
---
 virt/kvm/eventfd.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 39e42b19d9f7..42c02c35e542 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -401,6 +401,18 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
 	 */
 	init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
 
+	/*
+	 * Set the irqfd routing and add it to KVM's list before registering
+	 * the irqfd with the eventfd, so that the routing information is valid
+	 * and stays valid, e.g. if there are GSI routing changes, prior to
+	 * making the irqfd visible, i.e. before it might be signaled.
+	 *
+	 * Note, holding SRCU ensures a stable read of routing information, and
+	 * also prevents irqfd_shutdown() from freeing the irqfd before it's
+	 * fully initialized.
+	 */
+	idx = srcu_read_lock(&kvm->irq_srcu);
+
 	spin_lock_irq(&kvm->irqfds.lock);
 
 	ret = 0;
@@ -409,11 +421,9 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
 			continue;
 		/* This fd is used for another irq already. */
 		ret = -EBUSY;
-		spin_unlock_irq(&kvm->irqfds.lock);
-		goto fail;
+		goto fail_duplicate;
 	}
 
-	idx = srcu_read_lock(&kvm->irq_srcu);
 	irqfd_update(kvm, irqfd);
 
 	list_add_tail(&irqfd->list, &kvm->irqfds.items);
@@ -449,6 +459,9 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
 	srcu_read_unlock(&kvm->irq_srcu, idx);
 	return 0;
 
+fail_duplicate:
+	spin_unlock_irq(&kvm->irqfds.lock);
+	srcu_read_unlock(&kvm->irq_srcu, idx);
 fail:
 	if (irqfd->resampler)
 		irqfd_resampler_shutdown(irqfd);
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994749.1377595 (Exim 4.92)
	(envelope-from )
	id 1uIFiU-0001P5-B1; Thu, 22 May 2025 23:52:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994749.1377595; Thu, 22 May 2025 23: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 1uIFiU-0001Oj-4v; Thu, 22 May 2025 23:52:50 +0000
Received: by outflank-mailman (input) for mailman id 994749;
 Thu, 22 May 2025 23:52:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFiT-0007r7-7e
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:49 +0000
Received: from mail-pf1-x44a.google.com (mail-pf1-x44a.google.com
 [2607:f8b0:4864:20::44a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dc73a312-3767-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 01:52:47 +0200 (CEST)
Received: by mail-pf1-x44a.google.com with SMTP id
 d2e1a72fcca58-745e89b0c32so1323987b3a.3
 for ; Thu, 22 May 2025 16:52: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" 
X-Inumbo-ID: dc73a312-3767-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957966; x=1748562766; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=rhj01gCo8zRE4ihm7mjL7ntGfsdvBwkWydK82rp0ihs=;
        b=KeKegVuRjwnB7wkfg8niwpFF/dEqbqYM7fJ8MhyLQ3m0zFsBP2poa/ch89APCFSsXt
         7WRKQbFdM7MXIFNXsbl8Ehh6dZC6fBAQUJf5rUyrkhvFeIfAYYS5GaWWO/IEC2WoL8mo
         B4GhmEbbWGKapMMsltjH9OdeP0CSRfT1Y/Ap+zkVBVIBpxizBHzTFpKnTdcKqKoSIICB
         TY++uZEpKEffxaS6OAWHjEYYOEpZhnSKfGJie4y7DYqxNEWYlHI2sVgJ0xqNUVdPuERl
         eRuadfMsUdmGvfwTb+m1RlVvajirmZpt0HqtA0KVkE2qY5tMZc1Iqai3OJTzRpo9BM56
         zyww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957966; x=1748562766;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=rhj01gCo8zRE4ihm7mjL7ntGfsdvBwkWydK82rp0ihs=;
        b=O5fYeaK0QgrIjtZMAGfFIXKISmLr/VfcVGAJaICItaefjhVIUeaHg5bzXLGKub6uvf
         tTBgOCouYVrdDLIdfkTM0XYcTmUficdhRDx2gH70DdWHSd0eS4/uQbCRQustkkP9i/Kv
         mr2G8lHfl/PUzTbrx5ImBDQDzlVWi3NQtbstPCksj+esujEyrEx8LGUO5Hr0Zz5QWS9H
         Iqda9U0Q6kv6dtOe0UxbU9c6aoSd1W5KaS4k7BaQxfn9LoscTIw1fpKoNu4LHSaB5nMl
         ibZu45YZSFcVydp4XNOv/cQpEvHk7Zm0ikgd/FqawQp1iIi4eqdk2C4aYSbHzOhQkUoY
         qM9w==
X-Forwarded-Encrypted: i=1; AJvYcCWz04Uca2fY7eVfmcA4sG0+r5pASOdaSzETP7Vo6tRn7W69MR8M+NOW8LknSY9rUo7tOYlGhzh3pc4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyF05nu+dseOUX1mNCGPjIc3i66Ncswve15f9CI4pw9Y/sZ33R+
	NzoxiNmOv6LYxfRDVYSauBK+r85CkfYcRbfMDkrlBvQWbaRh40vLpGF5/a0e/5xhHPjjyrp5z7I
	kzbK80Q==
X-Google-Smtp-Source: AGHT+IFcXQOzVhyYyYRvvhxCpwMSPB5FWKzf2e+esBNAhvIROXYgtUD8Jyc4OswUVSapVQEWgVgXYmNxl9c=
X-Received: from pfbhd3.prod.google.com ([2002:a05:6a00:6583:b0:742:a60b:3336])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:8594:b0:740:9a42:a356
 with SMTP id d2e1a72fcca58-742acce36c5mr31613679b3a.11.1747957966116; Thu, 22
 May 2025 16:52:46 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:17 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-8-seanjc@google.com>
Subject: [PATCH v3 07/13] xen: privcmd: Don't mark eventfd waiter as EXCLUSIVE
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Don't set WQ_FLAG_EXCLUSIVE when adding an irqfd to a wait queue, as
irqfd_wakeup() unconditionally returns '0', i.e. doesn't actually operate
in exclusive mode.

Note, the use of WQ_FLAG_PRIORITY is also dubious, but that's a problem
for another day.

Signed-off-by: Sean Christopherson 
---
 drivers/xen/privcmd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index c08ec8a7d27c..13a10f3294a8 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -957,7 +957,6 @@ irqfd_poll_func(struct file *file, wait_queue_head_t *wqh, poll_table *pt)
 	struct privcmd_kernel_irqfd *kirqfd =
 		container_of(pt, struct privcmd_kernel_irqfd, pt);
 
-	kirqfd->wait.flags |= WQ_FLAG_EXCLUSIVE;
 	add_wait_queue_priority(wqh, &kirqfd->wait);
 }
 
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994750.1377606 (Exim 4.92)
	(envelope-from )
	id 1uIFiV-0001hi-Ps; Thu, 22 May 2025 23:52:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994750.1377606; Thu, 22 May 2025 23:52: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 1uIFiV-0001gU-Gs; Thu, 22 May 2025 23:52:51 +0000
Received: by outflank-mailman (input) for mailman id 994750;
 Thu, 22 May 2025 23:52:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFiT-0007r8-Vp
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:49 +0000
Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com
 [2607:f8b0:4864:20::549])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dd5eaf73-3767-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 01:52:49 +0200 (CEST)
Received: by mail-pg1-x549.google.com with SMTP id
 41be03b00d2f7-b0e0c573531so5862164a12.3
 for ; Thu, 22 May 2025 16:52:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dd5eaf73-3767-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957968; x=1748562768; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=vuHVtgMNklQ3DNdNkMUrgN1tyOO7CrPEj2V6DIP2LQI=;
        b=z1FOj35cJ/Nz/F/qzEhCbePRqrmWrwKSN5oFtorPj3GY9LLhQUr7hC4vrnCpAeSbST
         6ZcmhYxpV8PFOLiC5q9UnDP8t9Zes2+vd06LVXe0plWzphnCPgSMWj8GXwBRUxxwT/+h
         aARKadhL/W9/v7ZxSc//6jLy5MIVZeEdJoR7D5cGkt8QVRh6c7xipG9IANc/TgVevYWz
         kD1cXuWk2R72RUMu4GPyZ0d63qaw5/X+yNinBJGOEZ1jchoaZLyRCPOjGtz7Y8CPTdcd
         AItQbcaAzWPdwEIf5THA9eRvYXHfY7YFGhbGvNaIc1ttPBBvRJn9idwdYdqyEOjWzNEt
         ZVGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957968; x=1748562768;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=vuHVtgMNklQ3DNdNkMUrgN1tyOO7CrPEj2V6DIP2LQI=;
        b=Jw5AChvUXGZB9obxXd+wPoY/m2Dp/znCXxsbSwS7TXKq4DNpQikOJKOlUHlMnKi3ge
         CRSk7AKAl1+FstNW1rt/L65APsaISS84HEh3D61r0KRDgc9ra/Nd/KX3I+1LYzKMYqcz
         4MahdzgxewEuL52H4fvkc3VwoBhJBCg36DQb9LaNSAMHFPDiDDh2Lhi6q2r5lXY5VSxh
         Qe0dAouSvmam82fjhfmjTi/U+x5yHIFwljWDZq/+0eQTKArywU//+ZYMZTEqGJjrOLoW
         1E/7VwE1+5ajlArvJ71DcF2+yTvfyEsEsGgAJAysTXIxDS2UsH4QOl4GL8pehL1wthvR
         UG/w==
X-Forwarded-Encrypted: i=1; AJvYcCWThNiX+b6eG45BmP4ZNaJnvMBpQ0uChncwWU8fN3Li6BjjN69LaG7sCpfTY873Jjs+gttA6Fjd0JY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyg2ezylpXLOn+CdiKrQyxi6YooupFlDGtuRncN4guCY1Nf5mAa
	zlErvj/7xRnLhmhskjriJZN+4kwOqxI6H9J5onZoE1NMrrrnHJXO45nAQsunZ4exDuqmtquUyuv
	5q5wSGg==
X-Google-Smtp-Source: AGHT+IHikqs98z49j0Kkg2uX1c0LCZJ4TnpoZgPhfD1i2QFTska6FVqOIcx30KNoejfw/K9L53iBDs4oCi4=
X-Received: from pga7.prod.google.com ([2002:a05:6a02:4f87:b0:b26:e751:bb70])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:faf:b0:223:62f5:fd44
 with SMTP id d9443c01a7336-231d459a467mr365010445ad.40.1747957967798; Thu, 22
 May 2025 16:52:47 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:18 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-9-seanjc@google.com>
Subject: [PATCH v3 08/13] sched/wait: Add a waitqueue helper for fully
 exclusive priority waiters
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Add a waitqueue helper to add a priority waiter that requires exclusive
wakeups, i.e. that requires that it be the _only_ priority waiter.  The
API will be used by KVM to ensure that at most one of KVM's irqfds is
bound to a single eventfd (across the entire kernel).

Open code the helper instead of using __add_wait_queue() so that the
common path doesn't need to "handle" impossible failures.

Cc: K Prateek Nayak 
Signed-off-by: Sean Christopherson 
---
 include/linux/wait.h |  2 ++
 kernel/sched/wait.c  | 18 ++++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/include/linux/wait.h b/include/linux/wait.h
index 965a19809c7e..09855d819418 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -164,6 +164,8 @@ static inline bool wq_has_sleeper(struct wait_queue_head *wq_head)
 extern void add_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry);
 extern void add_wait_queue_exclusive(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry);
 extern void add_wait_queue_priority(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry);
+extern int add_wait_queue_priority_exclusive(struct wait_queue_head *wq_head,
+					     struct wait_queue_entry *wq_entry);
 extern void remove_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry);
 
 static inline void __add_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index 4ab3ab195277..15632c89c4f2 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -47,6 +47,24 @@ void add_wait_queue_priority(struct wait_queue_head *wq_head, struct wait_queue_
 }
 EXPORT_SYMBOL_GPL(add_wait_queue_priority);
 
+int add_wait_queue_priority_exclusive(struct wait_queue_head *wq_head,
+				      struct wait_queue_entry *wq_entry)
+{
+	struct list_head *head = &wq_head->head;
+
+	wq_entry->flags |= WQ_FLAG_EXCLUSIVE | WQ_FLAG_PRIORITY;
+
+	guard(spinlock_irqsave)(&wq_head->lock);
+
+	if (!list_empty(head) &&
+	    (list_first_entry(head, typeof(*wq_entry), entry)->flags & WQ_FLAG_PRIORITY))
+		return -EBUSY;
+
+	list_add(&wq_entry->entry, head);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(add_wait_queue_priority_exclusive);
+
 void remove_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
 {
 	unsigned long flags;
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994753.1377616 (Exim 4.92)
	(envelope-from )
	id 1uIFiX-00026m-WA; Thu, 22 May 2025 23:52:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994753.1377616; Thu, 22 May 2025 23:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uIFiX-00026Z-S9; Thu, 22 May 2025 23:52:53 +0000
Received: by outflank-mailman (input) for mailman id 994753;
 Thu, 22 May 2025 23:52:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFiW-0007r8-00
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:52 +0000
Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com
 [2607:f8b0:4864:20::449])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id de6add53-3767-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 01:52:51 +0200 (CEST)
Received: by mail-pf1-x449.google.com with SMTP id
 d2e1a72fcca58-742d077bdfaso6775833b3a.2
 for ; Thu, 22 May 2025 16:52: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" 
X-Inumbo-ID: de6add53-3767-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957969; x=1748562769; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=m999gU/AqGpWG+L7ciDbK5wL4BJk8SCse59imt7h3LE=;
        b=hsB98DvMK1p82HYlVdLnCcji2tPQ8OoFh2bEdK/16AtowbJoKG9ERQTi4zQTa5F6hy
         DE4n3NKL1rkCfOtNPtAuR7lwqPiaeqyrkzvasoMzdP8b8zLs3qcw/59v0YbEgVTsS+P2
         IqsVFunr8yrfeUf/nMZOnZsT1LRUvQN8PnB7Mx2MtBkpo/l2NMLj0gMIcED6aZh9uMXh
         mVUvCQYe2zhHE5IV6kQkIvBB8lrBJ48qtkV/EpvWGt0KV6l10V+5q6snkPqnDMeGwoOi
         2DwjdAG8dyoGSlpQ9HYqxpGAtskR3YlcAxIMwlYqFxGoVXMMJT1bIIFHnMRAm/eZEtVC
         XVBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957969; x=1748562769;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=m999gU/AqGpWG+L7ciDbK5wL4BJk8SCse59imt7h3LE=;
        b=vTulvtqjSBjjrowQ7+Nd3cu3BtcMODpaNT/QdTKNfWO9d9QaqgzxqA+2vkBpu6UAjp
         EL0oVpFvftd7ETiMPmp2aGPIS6kOQe0JbbvGTlKMyxzgiWRC5VSnwJRhtSKvsXvZdONg
         xgpZiJl/SkjETeYNjVwB9mOUiDxdQkq4N0AQxjleqWeDs62WZznaureh4p4Akom7TUIt
         EOqXhdwTKKAsWftNHi+nuNVHNg+/geGh1rAm9ZGltv0p78RLB7l0+afP2CY9ADtZwDJg
         k8bXgeRkzGR+QJB3TkASvZyE3Ey4FJzkxt9j2T0bDPd1MNGXFqseU/sXyLRKMT18CvMt
         2/9g==
X-Forwarded-Encrypted: i=1; AJvYcCWlVpA22LZ7B3O8j5eOGQwH3gdAQs8Gcz2oYgqcjiU9XKQYVu2b1Zqq6OBmvUqxV7Lz364a3Z4va7A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzN4u9C1TO88OkuZLpWlx++evAN4u/GoFZpVojxrEB48n6D2uej
	LeWCxm9YIG+Y7upPKA7hvgGB3Wb/wnEw/ZFwmX6PYIZzJl8w1WiqdzTc8EEQL7kXhYeDdjqazGR
	rC30gcg==
X-Google-Smtp-Source: AGHT+IGGw5zwjY0zFLgdg4fHQ7nOB9U/xbrTeYpuWgtfAceUKGlpNANWH4gnTKB5jligEj9ALMrYFDn6jAg=
X-Received: from pfjd1.prod.google.com ([2002:a05:6a00:2441:b0:730:743a:f2b0])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3c82:b0:742:b3a6:db16
 with SMTP id d2e1a72fcca58-745ed90b8e2mr1286378b3a.20.1747957969447; Thu, 22
 May 2025 16:52:49 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:19 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-10-seanjc@google.com>
Subject: [PATCH v3 09/13] KVM: Disallow binding multiple irqfds to an eventfd
 with a priority waiter
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Disallow binding an irqfd to an eventfd that already has a priority waiter,
i.e. to an eventfd that already has an attached irqfd.  KVM always
operates in exclusive mode for EPOLL_IN (unconditionally returns '1'),
i.e. only the first waiter will be notified.

KVM already disallows binding multiple irqfds to an eventfd in a single
VM, but doesn't guard against multiple VMs binding to an eventfd.  Adding
the extra protection reduces the pain of a userspace VMM bug, e.g. if
userspace fails to de-assign before re-assigning when transferring state
for intra-host migration, then the migration will explicitly fail as
opposed to dropping IRQs on the destination VM.

Temporarily keep KVM's manual check on irqfds.items, but add a WARN, e.g.
to allow sanity checking the waitqueue enforcement.

Cc: Oliver Upton 
Cc: David Matlack 
Signed-off-by: Sean Christopherson 
---
 virt/kvm/eventfd.c | 55 +++++++++++++++++++++++++++++++---------------
 1 file changed, 37 insertions(+), 18 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index c7969904637a..7b2e1f858f6d 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -291,38 +291,57 @@ static void kvm_irqfd_register(struct file *file, wait_queue_head_t *wqh,
 	struct kvm_kernel_irqfd *tmp;
 	struct kvm *kvm = p->kvm;
 
+	/*
+	 * Note, irqfds.lock protects the irqfd's irq_entry, i.e. its routing,
+	 * and irqfds.items.  It does NOT protect registering with the eventfd.
+	 */
 	spin_lock_irq(&kvm->irqfds.lock);
 
-	list_for_each_entry(tmp, &kvm->irqfds.items, list) {
-		if (irqfd->eventfd != tmp->eventfd)
-			continue;
-		/* This fd is used for another irq already. */
-		p->ret = -EBUSY;
-		spin_unlock_irq(&kvm->irqfds.lock);
-		return;
-	}
-
+	/*
+	 * Initialize the routing information prior to adding the irqfd to the
+	 * eventfd's waitqueue, as irqfd_wakeup() can be invoked as soon as the
+	 * irqfd is registered.
+	 */
 	irqfd_update(kvm, irqfd);
 
-	list_add_tail(&irqfd->list, &kvm->irqfds.items);
-
 	/*
 	 * Add the irqfd as a priority waiter on the eventfd, with a custom
 	 * wake-up handler, so that KVM *and only KVM* is notified whenever the
-	 * underlying eventfd is signaled.  Temporarily lie to lockdep about
-	 * holding irqfds.lock to avoid a false positive regarding potential
-	 * deadlock with irqfd_wakeup() (see irqfd_wakeup() for details).
+	 * underlying eventfd is signaled.
 	 */
 	init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
 
+	/*
+	 * Temporarily lie to lockdep about holding irqfds.lock to avoid a
+	 * false positive regarding potential deadlock with irqfd_wakeup()
+	 * (see irqfd_wakeup() for details).
+	 *
+	 * Adding to the wait queue will fail if there is already a priority
+	 * waiter, i.e. if the eventfd is associated with another irqfd (in any
+	 * VM).  Note, kvm_irqfd_deassign() waits for all in-flight shutdown
+	 * jobs to complete, i.e. ensures the irqfd has been removed from the
+	 * eventfd's waitqueue before returning to userspace.
+	 */
 	spin_release(&kvm->irqfds.lock.dep_map, _RET_IP_);
-	irqfd->wait.flags |= WQ_FLAG_EXCLUSIVE;
-	add_wait_queue_priority(wqh, &irqfd->wait);
+	p->ret = add_wait_queue_priority_exclusive(wqh, &irqfd->wait);
 	spin_acquire(&kvm->irqfds.lock.dep_map, 0, 0, _RET_IP_);
+	if (p->ret)
+		goto out;
 
+	list_for_each_entry(tmp, &kvm->irqfds.items, list) {
+		if (irqfd->eventfd != tmp->eventfd)
+			continue;
+
+		WARN_ON_ONCE(1);
+		/* This fd is used for another irq already. */
+		p->ret = -EBUSY;
+		goto out;
+	}
+
+	list_add_tail(&irqfd->list, &kvm->irqfds.items);
+
+out:
 	spin_unlock_irq(&kvm->irqfds.lock);
-
-	p->ret = 0;
 }
 
 #if IS_ENABLED(CONFIG_HAVE_KVM_IRQ_BYPASS)
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994754.1377625 (Exim 4.92)
	(envelope-from )
	id 1uIFiZ-0002Ni-FN; Thu, 22 May 2025 23:52:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994754.1377625; Thu, 22 May 2025 23: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 1uIFiZ-0002N2-7l; Thu, 22 May 2025 23:52:55 +0000
Received: by outflank-mailman (input) for mailman id 994754;
 Thu, 22 May 2025 23:52:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFiX-0007r8-0D
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:53 +0000
Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com
 [2607:f8b0:4864:20::1049])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id df4313dd-3767-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 01:52:52 +0200 (CEST)
Received: by mail-pj1-x1049.google.com with SMTP id
 98e67ed59e1d1-30e6980471cso6916035a91.1
 for ; Thu, 22 May 2025 16:52: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" 
X-Inumbo-ID: df4313dd-3767-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957971; x=1748562771; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=pJUovYaxFJgcXRp1TDFKS/NrFefgEp1AkGzEV1OM9Zc=;
        b=tciWqeq/yd7qi1qocfjWZN36EgEvzsjUGIhgmQEUgGapNR9y4XD3tVprslkOkuwRvM
         wzGL/lAFwdcZZ4tZM4PKqtDhM38u6//Zc61KLMeCPfhlsZZ/v8hPF81PqNBvqCN5uivw
         AIA6/FHU1ixmxc/WX67DttCAV6GCsRPxkvwWL8xV/+KUBaVItzdIc5pFDO/rjI3woAdl
         USPGc49sOuQ2fdm7vQqsuC2S8OOQjcNdwTh9ShXXjWf0K3SMmfjWvOIMkQIEkohBwmNN
         VIJehnKI5LorTndn0GiVElmot/wmSSNDkPrW933M1PV9hiLDbFfmG8jbaH5YVGqre6CL
         ZYsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957971; x=1748562771;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=pJUovYaxFJgcXRp1TDFKS/NrFefgEp1AkGzEV1OM9Zc=;
        b=OkES+3tVYSyYG6d+BZheEy1OSsGE7Qd6AeoTNZdLWJJjtnQ5Ootu0c6/ewg4GlNhih
         m3AY/Jiy0DdGL01IAoLHWn4keDmrgeKdxYl0SyjOHvWJLPrXC99aj7xO2xcNRLZ5VRpQ
         H/i+dVN6USSElusbiUjzUC8pAFX8wzbeZK+imoFe0mTiqmtQFmP94hHeM79Ef7siEuQu
         8IFuyG5qj97SbNaITh2as9nT5j0vfgDM7u8qpkC76PH7yAEr/f/aLXfVYyybyO6gj4cP
         m57r0haZ70P2hINY50ofwqsfc0DRBh5Dbt9pbPWo0Vjf7wj7U9CuGFQr3+NJfe6uSbzu
         j8tQ==
X-Forwarded-Encrypted: i=1; AJvYcCVRlj59Xq3FHHTqIR3hv1X8thTzatmiajL+PrWJ75gtOyduCuStLmHNNlSW8j0sWz5bvL8tiLvb1C0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzpWZUr5ftt2soth/UMq2W3W3WNFpnY7wFp3q55nGuBb4wQ2H8f
	vmkPskXXerNk3727EW32EzMdgNOQCqn4AXRxL/W8tUWMIEFNduQ8kjNwvnUP5aziQ6Se7kwJ268
	FynlV8A==
X-Google-Smtp-Source: AGHT+IEDndqxTWcCtq5oGwy52YECfaW+Ize1PqvGwCK7FSF7/oiShVYNO6fCIsKX/sBpVCvd/V18cyz4IiY=
X-Received: from pjx8.prod.google.com ([2002:a17:90b:5688:b0:30a:31eb:ec8e])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:33c2:b0:2ee:edae:780
 with SMTP id 98e67ed59e1d1-30e7d548c90mr43873310a91.15.1747957970976; Thu, 22
 May 2025 16:52:50 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:20 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-11-seanjc@google.com>
Subject: [PATCH v3 10/13] KVM: Drop sanity check that per-VM list of irqfds is unique
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Now that the eventfd's waitqueue ensures it has at most one priority
waiter, i.e. prevents KVM from binding multiple irqfds to one eventfd,
drop KVM's sanity check that eventfds are unique for a single VM.

Signed-off-by: Sean Christopherson 
---
 virt/kvm/eventfd.c | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 7b2e1f858f6d..d5258fd16033 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -288,7 +288,6 @@ static void kvm_irqfd_register(struct file *file, wait_queue_head_t *wqh,
 {
 	struct kvm_irqfd_pt *p = container_of(pt, struct kvm_irqfd_pt, pt);
 	struct kvm_kernel_irqfd *irqfd = p->irqfd;
-	struct kvm_kernel_irqfd *tmp;
 	struct kvm *kvm = p->kvm;
 
 	/*
@@ -328,16 +327,6 @@ static void kvm_irqfd_register(struct file *file, wait_queue_head_t *wqh,
 	if (p->ret)
 		goto out;
 
-	list_for_each_entry(tmp, &kvm->irqfds.items, list) {
-		if (irqfd->eventfd != tmp->eventfd)
-			continue;
-
-		WARN_ON_ONCE(1);
-		/* This fd is used for another irq already. */
-		p->ret = -EBUSY;
-		goto out;
-	}
-
 	list_add_tail(&irqfd->list, &kvm->irqfds.items);
 
 out:
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994757.1377636 (Exim 4.92)
	(envelope-from )
	id 1uIFib-0002op-Qd; Thu, 22 May 2025 23:52:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994757.1377636; Thu, 22 May 2025 23:52: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 1uIFib-0002oZ-LM; Thu, 22 May 2025 23:52:57 +0000
Received: by outflank-mailman (input) for mailman id 994757;
 Thu, 22 May 2025 23:52:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFia-0007r7-3I
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:56 +0000
Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com
 [2607:f8b0:4864:20::1049])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e03f2c8b-3767-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 01:52:54 +0200 (CEST)
Received: by mail-pj1-x1049.google.com with SMTP id
 98e67ed59e1d1-30e8aec4689so7733011a91.0
 for ; Thu, 22 May 2025 16:52: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" 
X-Inumbo-ID: e03f2c8b-3767-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957972; x=1748562772; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=jjMNjs+bdNtZTb3Wdy6sSLCs56ksmcfEkIHqJR2gBFc=;
        b=UeglZ0gAZC/jLBoMIB9KNvdoRZnuqbQwj7Vr2df98rbD5hMnj5FwYpLTLo2sKd1eDv
         f1ZKiSoPOoX8i8jwPWTBZ/jvDUjoFyFbyPLv8l6LnlnrnPAO2olYnieASNnQmpkj2+Cx
         IMQDIGWC+GumCz/anvk9X7xwezzZKn3MNVd6ih0QhWZbXqbXgmGI8T0DjcELH9mChp3F
         oJIl5nFUvEKoBEbPPS7g0V7oRbN19TvogXV1/okSJNdjvW1tZUTaJDIoCWhAhXVlwspK
         GGrpHF9rHOox9AWvdF1YeMotFF7mfRS4Y//H1J/NOfIfEUVyIRLo+z00LmLMyp9u/Xi+
         rxng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957972; x=1748562772;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=jjMNjs+bdNtZTb3Wdy6sSLCs56ksmcfEkIHqJR2gBFc=;
        b=HyPihbm4pe3Ca1feTGEKtWp5PaAlsfY+/z13uFHoEwDcayM3WGHD8oz6q8WGby0SCZ
         J8YSkh4mqOoND1YRTuZDLKkzjp1uWXrchulynkP0IGtNRBsp7Y12RqVApeEFeNnw3zOO
         uiuhmUSs32PUORxCOI9/XI82n4NAMGfkRozkBbw6xxPzWo2mKQK6zaDBTEyA2jFZTiUB
         yzreGS1aAdacZw5lQEYXC2eeOSrWRDNVz1PPp6OiWUQGnZf+GjvC4wgXQfkEMe4vNkYc
         gR+AIxea6ALlC9v+toOImiTxcx+/wEjf1gOPDCiBDm0FyJuImrJirS+7avyfckFKx50k
         SrOg==
X-Forwarded-Encrypted: i=1; AJvYcCUN2a1G4hB2ocrLiDOoWAJyM5tUivGtWNb8SSP82nogtj6HBLHtlQJPnG+ZiXcrN91f2Sl8J7YddWs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YybjHXswrrmn5TYTN2Hc4kUb6lmqPwo+ELLL1e1veOjde0SFEEy
	2YrBTMFN5bG312gyb8Fd7eoQv3FpPvAVBGMa5zMWF69Dp4FX4FwFftaTn373/2m7yrxCYPY7Sst
	CgHJjdA==
X-Google-Smtp-Source: AGHT+IH+y/4Vqk1KMF3LjOCFUbppIPh5ZUErAvUoiEDW2SE/2hXGiqyTLKxlZ9Xh8ZuSjxO0WF45GST49oM=
X-Received: from pjbdy5.prod.google.com ([2002:a17:90b:6c5:b0:2fc:1356:bcc3])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:510f:b0:2ff:58e1:2bb1
 with SMTP id 98e67ed59e1d1-310e973e510mr1311217a91.32.1747957972660; Thu, 22
 May 2025 16:52:52 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:21 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-12-seanjc@google.com>
Subject: [PATCH v3 11/13] KVM: selftests: Assert that eventfd() succeeds in
 Xen shinfo test
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Assert that eventfd() succeeds in the Xen shinfo test instead of skipping
the associated testcase.  While eventfd() is outside the scope of KVM, KVM
unconditionally selects EVENTFD, i.e. the syscall should always succeed.

Signed-off-by: Sean Christopherson 
---
 tools/testing/selftests/kvm/x86/xen_shinfo_test.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/kvm/x86/xen_shinfo_test.c b/tools/testing/selftests/kvm/x86/xen_shinfo_test.c
index 287829f850f7..34d180cf4eed 100644
--- a/tools/testing/selftests/kvm/x86/xen_shinfo_test.c
+++ b/tools/testing/selftests/kvm/x86/xen_shinfo_test.c
@@ -548,14 +548,11 @@ int main(int argc, char *argv[])
 
 	if (do_eventfd_tests) {
 		irq_fd[0] = eventfd(0, 0);
+		TEST_ASSERT(irq_fd[0] >= 0, __KVM_SYSCALL_ERROR("eventfd()", irq_fd[0]));
+
 		irq_fd[1] = eventfd(0, 0);
+		TEST_ASSERT(irq_fd[1] >= 0, __KVM_SYSCALL_ERROR("eventfd()", irq_fd[1]));
 
-		/* Unexpected, but not a KVM failure */
-		if (irq_fd[0] == -1 || irq_fd[1] == -1)
-			do_evtchn_tests = do_eventfd_tests = false;
-	}
-
-	if (do_eventfd_tests) {
 		irq_routes.info.nr = 2;
 
 		irq_routes.entries[0].gsi = 32;
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Thu May 22 23:52:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 22 May 2025 23:52:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994758.1377646 (Exim 4.92)
	(envelope-from )
	id 1uIFid-000384-H5; Thu, 22 May 2025 23:52:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994758.1377646; Thu, 22 May 2025 23:52: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 1uIFid-00037p-A3; Thu, 22 May 2025 23:52:59 +0000
Received: by outflank-mailman (input) for mailman id 994758;
 Thu, 22 May 2025 23:52:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFib-0007r7-D4
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:57 +0000
Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com
 [2607:f8b0:4864:20::54a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e13ed2dc-3767-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 01:52:55 +0200 (CEST)
Received: by mail-pg1-x54a.google.com with SMTP id
 41be03b00d2f7-b270145b864so3364564a12.3
 for ; Thu, 22 May 2025 16: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" 
X-Inumbo-ID: e13ed2dc-3767-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957974; x=1748562774; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=EKiGsGdj01NsitpTuPJ3Ew8X7lvRxIwEPSz2u8YI9Cs=;
        b=aIEeDpG0kVlc73Z4xovesQ5Bk5o65TfuMnQIPzHxq/0LQUd02gHrh6wOjpnmXfIJag
         gXFQzh/lV1j85Hi4rbxuYoq/is9ctigG+xsITwi9d70lQo573zTTQQg/GuGnKl/s83Ro
         Mu9vJKhqKvZmhsDvI2UWOD55TF7ZLMM7iW1RQhXnTq6FHv3ab1XTQsuqXXkYP1Mb7tid
         h+V/rYpA1V03p+SKTiDMNIL1T6YRK4rXQQ/lK6pqdY1jPoyscOIpO0MPynI89uMIU3i2
         eJPOnEGHw2H2TUjYjYR8uSX2LWB+82ztmek9uM5s9x5bDBeZUDT7OT4mJNPgZsybjfBR
         lRKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957974; x=1748562774;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=EKiGsGdj01NsitpTuPJ3Ew8X7lvRxIwEPSz2u8YI9Cs=;
        b=Qnfg2Yx6gJp+34TGvQUQ5YSi16YLtCOCjyxOBLz2r39SL398wWJPYKv+p95hBly0FS
         4kIzTGWPCFRZN6siuNW7ntYLho6/q8by1YLc9K1Hq+ItGMVfq237MAESvHBuMcPf72W6
         i8n2BW38Oku1ScXBdwTAF/xD11zVHDTPugZpcvCDaagEEEId/gJkhvAXGAPLrr5A6EYp
         brbDbVKsGmTkMPrK/4hvD3lSxbwuqUhgH844f6wUgK7JQFHYaqFe4oC5LqaN6DPo+DKH
         /cMIktxoWg7n9JMQvkdN5dRAL6EE1xnG+rmaVRjf1HF+jOOYQGXRuuxR/9emlOT3PRoX
         yRpg==
X-Forwarded-Encrypted: i=1; AJvYcCWSX0qXdz+1hBOfcH5W6y2wg5pJx9vCT1PQsD0OFpt3P0mF3heayEgoCm/dMRX9v9dZfWeij6+dVVg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy74fnaiH2sjXWPTlwtMZoiNk1mczqKi1Ya7jb/Cs78DodCLbnx
	vUqwcYIjHQL2WLJEyx/XpqT2V7eSNN+PevIAFm2DPV5wubA7aQ86dMjGpx6sO6QgDYrMjH74PZF
	48NxOKw==
X-Google-Smtp-Source: AGHT+IFfHuwPoraxH7fHOxcJKjCs5i19crB1g3gqYt+qVLkDFB/zR2OG4BEQkHLANHuLxCZWJd/rEXtT30s=
X-Received: from pga16.prod.google.com ([2002:a05:6a02:4f90:b0:af2:3385:de87])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:d527:b0:206:aa42:8e7c
 with SMTP id adf61e73a8af0-2170cc715a0mr39501029637.18.1747957974292; Thu, 22
 May 2025 16:52:54 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:22 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-13-seanjc@google.com>
Subject: [PATCH v3 12/13] KVM: selftests: Add utilities to create eventfds and
 do KVM_IRQFD
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Add helpers to create eventfds and to (de)assign eventfds via KVM_IRQFD.

Signed-off-by: Sean Christopherson 
---
 tools/testing/selftests/kvm/arm64/vgic_irq.c  | 12 ++----
 .../testing/selftests/kvm/include/kvm_util.h  | 40 +++++++++++++++++++
 .../selftests/kvm/x86/xen_shinfo_test.c       | 18 ++-------
 3 files changed, 47 insertions(+), 23 deletions(-)

diff --git a/tools/testing/selftests/kvm/arm64/vgic_irq.c b/tools/testing/selftests/kvm/arm64/vgic_irq.c
index f4ac28d53747..a09dd423c2d7 100644
--- a/tools/testing/selftests/kvm/arm64/vgic_irq.c
+++ b/tools/testing/selftests/kvm/arm64/vgic_irq.c
@@ -620,18 +620,12 @@ static void kvm_routing_and_irqfd_check(struct kvm_vm *vm,
 	 * that no actual interrupt was injected for those cases.
 	 */
 
-	for (f = 0, i = intid; i < (uint64_t)intid + num; i++, f++) {
-		fd[f] = eventfd(0, 0);
-		TEST_ASSERT(fd[f] != -1, __KVM_SYSCALL_ERROR("eventfd()", fd[f]));
-	}
+	for (f = 0, i = intid; i < (uint64_t)intid + num; i++, f++)
+		fd[f] = kvm_new_eventfd();
 
 	for (f = 0, i = intid; i < (uint64_t)intid + num; i++, f++) {
-		struct kvm_irqfd irqfd = {
-			.fd  = fd[f],
-			.gsi = i - MIN_SPI,
-		};
 		assert(i <= (uint64_t)UINT_MAX);
-		vm_ioctl(vm, KVM_IRQFD, &irqfd);
+		kvm_assign_irqfd(vm, i - MIN_SPI, fd[f]);
 	}
 
 	for (f = 0, i = intid; i < (uint64_t)intid + num; i++, f++) {
diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h
index 373912464fb4..4f7bf8f000bb 100644
--- a/tools/testing/selftests/kvm/include/kvm_util.h
+++ b/tools/testing/selftests/kvm/include/kvm_util.h
@@ -18,6 +18,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include "kvm_util_arch.h"
@@ -496,6 +497,45 @@ static inline int vm_get_stats_fd(struct kvm_vm *vm)
 	return fd;
 }
 
+static inline int __kvm_irqfd(struct kvm_vm *vm, uint32_t gsi, int eventfd,
+			      uint32_t flags)
+{
+	struct kvm_irqfd irqfd = {
+		.fd = eventfd,
+		.gsi = gsi,
+		.flags = flags,
+		.resamplefd = -1,
+	};
+
+	return __vm_ioctl(vm, KVM_IRQFD, &irqfd);
+}
+
+static inline void kvm_irqfd(struct kvm_vm *vm, uint32_t gsi, int eventfd,
+			      uint32_t flags)
+{
+	int ret = __kvm_irqfd(vm, gsi, eventfd, flags);
+
+	TEST_ASSERT_VM_VCPU_IOCTL(!ret, KVM_IRQFD, ret, vm);
+}
+
+static inline void kvm_assign_irqfd(struct kvm_vm *vm, uint32_t gsi, int eventfd)
+{
+	kvm_irqfd(vm, gsi, eventfd, 0);
+}
+
+static inline void kvm_deassign_irqfd(struct kvm_vm *vm, uint32_t gsi, int eventfd)
+{
+	kvm_irqfd(vm, gsi, eventfd, KVM_IRQFD_FLAG_DEASSIGN);
+}
+
+static inline int kvm_new_eventfd(void)
+{
+	int fd = eventfd(0, 0);
+
+	TEST_ASSERT(fd >= 0, __KVM_SYSCALL_ERROR("eventfd()", fd));
+	return fd;
+}
+
 static inline void read_stats_header(int stats_fd, struct kvm_stats_header *header)
 {
 	ssize_t ret;
diff --git a/tools/testing/selftests/kvm/x86/xen_shinfo_test.c b/tools/testing/selftests/kvm/x86/xen_shinfo_test.c
index 34d180cf4eed..23909b501ac2 100644
--- a/tools/testing/selftests/kvm/x86/xen_shinfo_test.c
+++ b/tools/testing/selftests/kvm/x86/xen_shinfo_test.c
@@ -547,11 +547,8 @@ int main(int argc, char *argv[])
 	int irq_fd[2] = { -1, -1 };
 
 	if (do_eventfd_tests) {
-		irq_fd[0] = eventfd(0, 0);
-		TEST_ASSERT(irq_fd[0] >= 0, __KVM_SYSCALL_ERROR("eventfd()", irq_fd[0]));
-
-		irq_fd[1] = eventfd(0, 0);
-		TEST_ASSERT(irq_fd[1] >= 0, __KVM_SYSCALL_ERROR("eventfd()", irq_fd[1]));
+		irq_fd[0] = kvm_new_eventfd();
+		irq_fd[1] = kvm_new_eventfd();
 
 		irq_routes.info.nr = 2;
 
@@ -569,15 +566,8 @@ int main(int argc, char *argv[])
 
 		vm_ioctl(vm, KVM_SET_GSI_ROUTING, &irq_routes.info);
 
-		struct kvm_irqfd ifd = { };
-
-		ifd.fd = irq_fd[0];
-		ifd.gsi = 32;
-		vm_ioctl(vm, KVM_IRQFD, &ifd);
-
-		ifd.fd = irq_fd[1];
-		ifd.gsi = 33;
-		vm_ioctl(vm, KVM_IRQFD, &ifd);
+		kvm_assign_irqfd(vm, 32, irq_fd[0]);
+		kvm_assign_irqfd(vm, 33, irq_fd[1]);
 
 		struct sigaction sa = { };
 		sa.sa_handler = handle_alrm;
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Fri May 23 00:07:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 00:07:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.994872.1377655 (Exim 4.92)
	(envelope-from )
	id 1uIFwu-0001Rn-I7; Fri, 23 May 2025 00:07:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 994872.1377655; Fri, 23 May 2025 00:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uIFwu-0001Rg-F7; Fri, 23 May 2025 00:07:44 +0000
Received: by outflank-mailman (input) for mailman id 994872;
 Fri, 23 May 2025 00:07:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIFid-0007r7-3l
 for xen-devel@lists.xenproject.org; Thu, 22 May 2025 23:52:59 +0000
Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com
 [2607:f8b0:4864:20::104a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e21b213e-3767-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 01:52:57 +0200 (CEST)
Received: by mail-pj1-x104a.google.com with SMTP id
 98e67ed59e1d1-30e896e116fso5559719a91.2
 for ; Thu, 22 May 2025 16:52: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" 
X-Inumbo-ID: e21b213e-3767-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1747957976; x=1748562776; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:from:to:cc:subject:date:message-id:reply-to;
        bh=iNuUWcLjakGfkNNM+8DkBjBlwJhpM767OVzB+eUiNIQ=;
        b=w6B+1R/lodL5bHDVCn89QkY3h46a2X/l0bVftv5L7rvPV2Wrec1a1wUaplsOvZGejR
         iLDQfgYct9y03UMOYftoWBjSCG0NGaH3CzajzqpxXoO012pfDR6tcvmoJtLuIbk+6ioG
         rkCT4rOUYJJGeEW3qx7C6YRRoKeQKv5rDM//L2EyQm6LIWq9QgDGC5TXsbfZTZvIlMAk
         EASL8O76ykgq7cI+7nr5wdlxYtql4egc7iHgDOtQyZUtqaJkjhv2iytml/K2q3UasbSK
         zwzttWSvVl9oTRtCPSslAz6ihYc+bApadr8/TwaQ1t4HScEguH8yBi9rc+yhYUW46KRD
         UtGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747957976; x=1748562776;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=iNuUWcLjakGfkNNM+8DkBjBlwJhpM767OVzB+eUiNIQ=;
        b=F+updsJRw0v7xKlxQ5lqNJX7MPrSrLV64yOARFPWr01fr29wlqMYJGTflDMGWI6zXt
         nHctLGFwiMgfEbJPwzbKxaminYK4BF8D51OAscR7msrcQbTPsQw9Em5ck+6q4Hw5IRsk
         WZwhM2QEpYpoN+x+38gkjfqildYEjt0L7OXCAqy09pdHqYmZdYY51VPrMQNpWCKlBLVI
         EK1MGRHY0pueZmdmKbIQ9V2vJr2u8Ti4YxK454LVgVgwXCiFWCSuD9Zp7XL11GSEiIek
         seQxVexO8Qb1IaJZboE2K2wnu8H0Cio1xI9T4Ig0rpRuwv+bt5pvqwGYjz/3JrFMRajB
         brsQ==
X-Forwarded-Encrypted: i=1; AJvYcCX+mU0OYJaVKfFo0J9KBevv5v3O1jvAtFDsDkjA4LO1LOx9HCIUUU+E6hiiknY/DIgWhWajNzLiEzQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxnnKt97+S4ukax71rsjlxlzsK7HAV1lecLKCe4NwxT+EK+klCi
	+0RxvzW9734dmTfnJlnWqRWoP38P0uhT7htc9g4zHx1vduKn3T47h1ExK0O2AWtdHGY6s9d3RIA
	pd4xQoQ==
X-Google-Smtp-Source: AGHT+IEoOvxAnrgVMqS3TC3RLkVh5nLtBQqPosDJG4xPj/XHWemBkiBPXcS2x1YfUhLo+1j7jd9m06w7XHM=
X-Received: from pjbpm5.prod.google.com ([2002:a17:90b:3c45:b0:30a:9720:ea33])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:dfc7:b0:30c:5479:c92e
 with SMTP id 98e67ed59e1d1-30e830c7988mr39961520a91.4.1747957975748; Thu, 22
 May 2025 16:52:55 -0700 (PDT)
Reply-To: Sean Christopherson 
Date: Thu, 22 May 2025 16:52:23 -0700
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com>
X-Mailer: git-send-email 2.49.0.1151.ga128411c76-goog
Message-ID: <20250522235223.3178519-14-seanjc@google.com>
Subject: [PATCH v3 13/13] KVM: selftests: Add a KVM_IRQFD test to verify
 uniqueness requirements
From: Sean Christopherson 
To: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , 
	Sean Christopherson 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org, 
	linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	kvmarm@lists.linux.dev, K Prateek Nayak , 
	David Matlack 
Content-Type: text/plain; charset="UTF-8"

Add a selftest to verify that eventfd+irqfd bindings are globally unique,
i.e. that KVM doesn't allow multiple irqfds to bind to a single eventfd,
even across VMs.

Signed-off-by: Sean Christopherson 
---
 tools/testing/selftests/kvm/Makefile.kvm |   1 +
 tools/testing/selftests/kvm/irqfd_test.c | 130 +++++++++++++++++++++++
 2 files changed, 131 insertions(+)
 create mode 100644 tools/testing/selftests/kvm/irqfd_test.c

diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index f62b0a5aba35..318adf3ef6b6 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -54,6 +54,7 @@ TEST_PROGS_x86 += x86/nx_huge_pages_test.sh
 TEST_GEN_PROGS_COMMON = demand_paging_test
 TEST_GEN_PROGS_COMMON += dirty_log_test
 TEST_GEN_PROGS_COMMON += guest_print_test
+TEST_GEN_PROGS_COMMON += irqfd_test
 TEST_GEN_PROGS_COMMON += kvm_binary_stats_test
 TEST_GEN_PROGS_COMMON += kvm_create_max_vcpus
 TEST_GEN_PROGS_COMMON += kvm_page_table_test
diff --git a/tools/testing/selftests/kvm/irqfd_test.c b/tools/testing/selftests/kvm/irqfd_test.c
new file mode 100644
index 000000000000..286f2b15fde6
--- /dev/null
+++ b/tools/testing/selftests/kvm/irqfd_test.c
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "kvm_util.h"
+
+static struct kvm_vm *vm1;
+static struct kvm_vm *vm2;
+static int __eventfd;
+static bool done;
+
+/*
+ * KVM de-assigns based on eventfd *and* GSI, but requires unique eventfds when
+ * assigning (the API isn't symmetrical).  Abuse the oddity and use a per-task
+ * GSI base to avoid false failures due to cross-task de-assign, i.e. so that
+ * the secondary doesn't de-assign the primary's eventfd and cause assign to
+ * unexpectedly succeed on the primary.
+ */
+#define GSI_BASE_PRIMARY	0x20
+#define GSI_BASE_SECONDARY	0x30
+
+static void juggle_eventfd_secondary(struct kvm_vm *vm, int eventfd)
+{
+	int r, i;
+
+	/*
+	 * The secondary task can encounter EBADF since the primary can close
+	 * the eventfd at any time.  And because the primary can recreate the
+	 * eventfd, at the safe fd in the file table, the secondary can also
+	 * encounter "unexpected" success, e.g. if the close+recreate happens
+	 * between the first and second assignments.  The secondary's role is
+	 * mostly to antagonize KVM, not to detect bugs.
+	 */
+	for (i = 0; i < 2; i++) {
+		r = __kvm_irqfd(vm, GSI_BASE_SECONDARY, eventfd, 0);
+		TEST_ASSERT(!r || errno == EBUSY || errno == EBADF,
+			    "Wanted success, EBUSY, or EBADF, r = %d, errno = %d",
+			    r, errno);
+
+		/* De-assign should succeed unless the eventfd was closed. */
+		r = __kvm_irqfd(vm, GSI_BASE_SECONDARY + i, eventfd, KVM_IRQFD_FLAG_DEASSIGN);
+		TEST_ASSERT(!r || errno == EBADF,
+			    "De-assign should succeed unless the fd was closed");
+	}
+}
+
+static void *secondary_irqfd_juggler(void *ign)
+{
+	while (!READ_ONCE(done)) {
+		juggle_eventfd_secondary(vm1, READ_ONCE(__eventfd));
+		juggle_eventfd_secondary(vm2, READ_ONCE(__eventfd));
+	}
+
+	return NULL;
+}
+
+static void juggle_eventfd_primary(struct kvm_vm *vm, int eventfd)
+{
+	int r1, r2;
+
+	/*
+	 * At least one of the assigns should fail.  KVM disallows assigning a
+	 * single eventfd to multiple GSIs (or VMs), so it's possible that both
+	 * assignments can fail, too.
+	 */
+	r1 = __kvm_irqfd(vm, GSI_BASE_PRIMARY, eventfd, 0);
+	TEST_ASSERT(!r1 || errno == EBUSY,
+		    "Wanted success or EBUSY, r = %d, errno = %d", r1, errno);
+
+	r2 = __kvm_irqfd(vm, GSI_BASE_PRIMARY + 1, eventfd, 0);
+	TEST_ASSERT(r1 || (r2 && errno == EBUSY),
+		    "Wanted failure (EBUSY), r1 = %d, r2 = %d, errno = %d",
+		    r1, r2, errno);
+
+	/*
+	 * De-assign should always succeed, even if the corresponding assign
+	 * failed.
+	 */
+	kvm_irqfd(vm, GSI_BASE_PRIMARY, eventfd, KVM_IRQFD_FLAG_DEASSIGN);
+	kvm_irqfd(vm, GSI_BASE_PRIMARY + 1, eventfd, KVM_IRQFD_FLAG_DEASSIGN);
+}
+
+int main(int argc, char *argv[])
+{
+	pthread_t racing_thread;
+	int r, i;
+
+	/* Create "full" VMs, as KVM_IRQFD requires an in-kernel IRQ chip. */
+	vm1 = vm_create(1);
+	vm2 = vm_create(1);
+
+	WRITE_ONCE(__eventfd, kvm_new_eventfd());
+
+	kvm_irqfd(vm1, 10, __eventfd, 0);
+
+	r = __kvm_irqfd(vm1, 11, __eventfd, 0);
+	TEST_ASSERT(r && errno == EBUSY,
+		    "Wanted EBUSY, r = %d, errno = %d", r, errno);
+
+	r = __kvm_irqfd(vm2, 12, __eventfd, 0);
+	TEST_ASSERT(r && errno == EBUSY,
+		    "Wanted EBUSY, r = %d, errno = %d", r, errno);
+
+	kvm_irqfd(vm1, 11, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
+	kvm_irqfd(vm1, 12, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
+	kvm_irqfd(vm1, 13, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
+	kvm_irqfd(vm1, 14, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
+	kvm_irqfd(vm1, 10, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
+
+	close(__eventfd);
+
+	pthread_create(&racing_thread, NULL, secondary_irqfd_juggler, vm2);
+
+	for (i = 0; i < 10000; i++) {
+		WRITE_ONCE(__eventfd, kvm_new_eventfd());
+
+		juggle_eventfd_primary(vm1, __eventfd);
+		juggle_eventfd_primary(vm2, __eventfd);
+		close(__eventfd);
+	}
+
+	WRITE_ONCE(done, true);
+	pthread_join(racing_thread, NULL);
+}
-- 
2.49.0.1151.ga128411c76-goog



From xen-devel-bounces@lists.xenproject.org Fri May 23 06:51:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 06:51:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995182.1377698 (Exim 4.92)
	(envelope-from )
	id 1uIMFh-0001eg-9M; Fri, 23 May 2025 06:51:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995182.1377698; Fri, 23 May 2025 06: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 1uIMFh-0001eZ-6h; Fri, 23 May 2025 06:51:33 +0000
Received: by outflank-mailman (input) for mailman id 995182;
 Fri, 23 May 2025 06:51:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMFf-0001eT-Fw
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 06:51:31 +0000
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com
 [2607:f8b0:4864:20::134])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5853271c-37a2-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 08:51:26 +0200 (CEST)
Received: by mail-il1-x134.google.com with SMTP id
 e9e14a558f8ab-3da8e1259dfso64382315ab.3
 for ; Thu, 22 May 2025 23: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" 
X-Inumbo-ID: 5853271c-37a2-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747983085; x=1748587885; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Jv2FlgL6Ms54XQlvM5VUyvHV4/YVXgzvos+Dpzbmm2M=;
        b=Z9g2yZJnLwgeUM6LI3QrVozgn6yxQiAthgwEg7xUgCZhn9ulsU2/Mi/zshohSKugx7
         yxs2emzcR4W/wZazBdpbI4jBG97fcTDGAbhUspmDh1PCbiiz/XpLtiFVv0QtfSM1yLHa
         uOktBnmMmu3FLwe8CEdIQg2q9kjbZjCfkA3U/ciXLoLVXrCwLWjgFc2/hZE/OgS8ZgUm
         zh10wy6j/ap7qQZ9QLXGV/eUr0t7GJi44l2GGqVjEnMK5Y9sJi59wugoQwR+kZCzXSBI
         g6+XJq9oHr+U5/XcqJOA4xK7/lcosbnu24/JNznO874j8wa5vQVISEmoe8wTKcDNFfEF
         zA9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747983085; x=1748587885;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Jv2FlgL6Ms54XQlvM5VUyvHV4/YVXgzvos+Dpzbmm2M=;
        b=J3lHsNU4pGTMptGUtqXrS44Ck41rmghWUEXm7MzxUxQOEcy+ZgLiR6zTpcdLQ2SREu
         qzPJa9BjVz2F3PJkt3YICx3YxO/IZ0YEbfec12UyD8nL7dr6yvcLY02JdFs9jYKMRimo
         IO1l8Hgokl4eX1eIXoejHcy9f4kO115jr51CfLUyK8F5Il5R+tgYvD61SeFXcPZ51k6P
         /NCYrt2ks0qkuIxh/FBwvHtD8lxzOq41T1JbrCzuQ6np99RWf3w8VrvfGAPEkdTtk3a8
         8eZwyos63CCnr9IKhx0mArFKTq9AgdxN4HMwzuKIOIGzhZ7gE1HOnerxrsfMrhlR1SiA
         mnWw==
X-Gm-Message-State: AOJu0YzNb62Li3erW1aF/0iBq15Pwe/y5pvGrt/E3mkHZPvVOyWWrnEg
	dW0NUk4MR5WwxuO9u/01HSF8bqdizwhdR7wYFkOCeIYv13GLwYyZOEDqECf6iSy1or30oljnA+r
	JrXCyln/6UGvGnny5jxV7N7cyvc8RaeW55DBFdqaU5toyGOVl0qykjxk=
X-Gm-Gg: ASbGncuyUjYX+TgaoICR+BHnErP+GL2YUor7w6eAoFVr/YXuAKPn6RNfxBN5NHMiNGY
	ZieePmSBci6/Xj9uOBnttAyXxhECrjIKirm0J4y7A3Pc0YsuYDXM8ODXjCu3qmj5XmWgM6S12fG
	H1PiqGHJ0/DKlr7cBCnq+W6wf79Xrk1kSJhQ==
X-Google-Smtp-Source: AGHT+IFukozhMqaUDxabO/uMuohfJ7UiENQV4cPF2rk2OAC2W+PdWDZlHwhTnWWf36xAWFEjlMQGX5qa3l2/KvWu1Jo=
X-Received: by 2002:a4a:ec49:0:b0:607:dd61:9c33 with SMTP id
 006d021491bc7-609f48646b0mr15960985eaf.1.1747983073932; Thu, 22 May 2025
 23:51:13 -0700 (PDT)
MIME-Version: 1.0
References:  <3405d6a545c5ad8fadf7b252c98ce4120fe63fd2.1747925287.git.bertrand.marquis@arm.com>
In-Reply-To: <3405d6a545c5ad8fadf7b252c98ce4120fe63fd2.1747925287.git.bertrand.marquis@arm.com>
From: Jens Wiklander 
Date: Fri, 23 May 2025 08:51:01 +0200
X-Gm-Features: AX0GCFuYk_q4tgQfcUyO6KQYcR52qBieNTLlOxr2SRafveq64FXPsFmTAKoxi58
Message-ID: 
Subject: Re: [PATCH v6 3/6] xen/arm: ffa: Introduce VM to VM support
To: Bertrand Marquis 
Cc: xen-devel@lists.xenproject.org, 
	Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Michal Orzel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bertrand,

On Thu, May 22, 2025 at 5:08=E2=80=AFPM Bertrand Marquis
 wrote:
>
> Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
> between VMs.
> When activated list VMs in the system with FF-A support in part_info_get.
>
> When VM to VM is activated, Xen will be tainted as Insecure and a
> message is displayed to the user during the boot as there is no
> filtering of VMs in FF-A so any VM can communicate or see any other VM
> in the system.
>
> WARNING: There is no filtering for now and all VMs are listed !!
>
> This patch is reorganizing the ffa_ctx structure to make clear which
> lock is protecting what parts.
>
> This patch is introducing a chain list of the ffa_ctx with a FFA Version
> negociated allowing to create the partinfo results for VMs without

negotiated

> taking a lock on the global domain list in Xen.
>
> Signed-off-by: Bertrand Marquis 

[...]
> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat=
e.h
> index 0a9c1082db28..08dbdf9fcddd 100644
> --- a/xen/arch/arm/tee/ffa_private.h
> +++ b/xen/arch/arm/tee/ffa_private.h
> @@ -195,6 +195,18 @@
>   */
>  #define FFA_PARTITION_INFO_GET_COUNT_FLAG BIT(0, U)
>
> +/*
> + * Partition properties we give for a normal world VM:
> + * - can send direct message but not receive them
> + * - can handle indirect messages
> + * - can receive notifications
> + * 32/64 bit flag is set depending on the VM
> + */
> +#define FFA_PART_VM_PROP    (FFA_PART_PROP_DIRECT_REQ_SEND | \
> +                             FFA_PART_PROP_INDIRECT_MSGS | \
> +                             FFA_PART_PROP_RECV_NOTIF | \
> +                             FFA_PART_PROP_IS_PE_ID)
> +
>  /* Flags used in calls to FFA_NOTIFICATION_GET interface  */
>  #define FFA_NOTIF_FLAG_BITMAP_SP        BIT(0, U)
>  #define FFA_NOTIF_FLAG_BITMAP_VM        BIT(1, U)
> @@ -297,36 +309,70 @@ struct ffa_ctx_notif {
>  };
>
>  struct ffa_ctx {
> -    void *rx;
> -    const void *tx;
> -    struct page_info *rx_pg;
> -    struct page_info *tx_pg;
> +    /*
> +     * Chain list of all FF-A contexts, to prevent locking access to thi=
s list,
> +     * all "unlocked" data from the structure must be set before adding =
an
> +     * entry in the list and an entry must be removed from the list befo=
re
> +     * freeing a context.
> +     */
> +    struct list_head ctx_list; /* chain list of all FF-A contexts */
> +
> +    /*
> +     * Data access unlocked (mainly for part_info_get in VM to VM).
> +     * Those should be set before the ctx is added in the list.
> +     */
> +    /* FF-A Endpoint ID */
> +    uint16_t ffa_id;
> +    uint16_t num_vcpus;
> +    bool is_64bit;
> +
> +    /*
> +     * Global data accessed atomically or using ACCES_ONCE.
> +     */
> +    struct ffa_ctx_notif notif;
> +
> +    /*
> +     * Global data accessed with lock locked.
> +     */
> +    spinlock_t lock;
> +    /*
> +     * FF-A version negociated by the guest, only modifications to

negotiated

With the two spell errors fixed.
Reviewed-by: Jens Wiklander 

Cheers,
Jens


From xen-devel-bounces@lists.xenproject.org Fri May 23 06:54:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 06:54:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995192.1377707 (Exim 4.92)
	(envelope-from )
	id 1uIMIN-0002CQ-LH; Fri, 23 May 2025 06:54:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995192.1377707; Fri, 23 May 2025 06:54: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 1uIMIN-0002CJ-IX; Fri, 23 May 2025 06:54:19 +0000
Received: by outflank-mailman (input) for mailman id 995192;
 Fri, 23 May 2025 06:54:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMIN-0002CD-4a
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 06:54:19 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id be710152-37a2-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 08:54:17 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0DEB31764;
 Thu, 22 May 2025 23:54:02 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3C57C3F673;
 Thu, 22 May 2025 23:54: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" 
X-Inumbo-ID: be710152-37a2-11f0-b892-0df219b8e170
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Ayan Kumar Halder ,
	Julien Grall 
Subject: [PATCH v6 1/6] docs/arm: Document Xen booting protocol on Armv8-R
Date: Fri, 23 May 2025 07:54:01 +0100
Message-Id: <20250523065406.3795420-2-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250523065406.3795420-1-luca.fancellu@arm.com>
References: <20250523065406.3795420-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Document the requirement needed to boot Xen on Armv8-R platforms.

Signed-off-by: Luca Fancellu 
Reviewed-by: Ayan Kumar Halder 
Reviewed-by: Michal Orzel 
Acked-by: Julien Grall 
---
v6 changes:
 - Add Julien's Ack-by, add " Cache state shall follow [1], [2] for MPU."
v5 changes:
 - restructured and removed some EL3 reference that might not
   be there on Armv8-R aarch64
 - add R-by Ayan and Michal
v4 changes:
 - New patch
---
 docs/misc/arm/booting.txt | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
index 21ae74837dcc..e9b511cae4a8 100644
--- a/docs/misc/arm/booting.txt
+++ b/docs/misc/arm/booting.txt
@@ -56,12 +56,17 @@ image header to determine the load address, entry point, etc.
 Firmware/bootloader requirements
 --------------------------------
 
-Xen relies on some settings the firmware has to configure in EL3 before starting Xen.
+Xen relies on some settings the firmware has to configure before starting Xen.
 
-* Xen must be entered in NS EL2 mode
+* Xen must be entered in:
+  * Non-Secure EL2 mode for Armv8-A Arm64 and Arm32, Armv8-R Arm32.
+  * Secure EL2 mode for Armv8-R Arm64.
 
-* The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1.
+* When EL3 is supported, the bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must
+  be set to 1.
 
+* Xen must be entered with MMU/MPU off and data cache disabled (SCTLR_EL2.M bit
+  and SCTLR_EL2.C set to 0). Cache state shall follow [1], [2] for MPU.
 
 [1] linux/Documentation/arm/booting.rst
 Latest version: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arch/arm/booting.rst
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 23 06:54:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 06:54:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995193.1377718 (Exim 4.92)
	(envelope-from )
	id 1uIMIP-0002Qm-05; Fri, 23 May 2025 06:54:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995193.1377718; Fri, 23 May 2025 06:54: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 1uIMIO-0002Qc-TO; Fri, 23 May 2025 06:54:20 +0000
Received: by outflank-mailman (input) for mailman id 995193;
 Fri, 23 May 2025 06:54:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMIO-0002FX-4s
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 06:54:20 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id bf88b215-37a2-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 08:54:18 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D024E1A2D;
 Thu, 22 May 2025 23:54:03 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BFBC03F673;
 Thu, 22 May 2025 23: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" 
X-Inumbo-ID: bf88b215-37a2-11f0-a2fb-13f23c93f187
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Penny Zheng ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Penny Zheng ,
	Wei Chen ,
	Julien Grall 
Subject: [PATCH v6 2/6] arm/mpu: Introduce MPU memory region map structure
Date: Fri, 23 May 2025 07:54:02 +0100
Message-Id: <20250523065406.3795420-3-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250523065406.3795420-1-luca.fancellu@arm.com>
References: <20250523065406.3795420-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Penny Zheng 

Introduce pr_t typedef which is a structure having the prbar
and prlar members, each being structured as the registers of
the AArch64 Armv8-R architecture.

Signed-off-by: Penny Zheng 
Signed-off-by: Wei Chen 
Signed-off-by: Luca Fancellu 
Acked-by: Julien Grall 
Reviewed-by: Michal Orzel 
---
Changes in v6:
 - Add Julien's Ack-by
 - modified header guard by new code style
 - Add R-by Michal
Changes in v5:
 - Given some comments on the page.h flags, I had to rework some
   fields here to better match the flags usage and avoid duplication
Changes in v4:
 - Fixed typos, changed name for reserved bitfields, add emacs bits
   to arm64/mpu.h.
   Now base and limit are 42 bits as we consider FEAT_LPA disabled,
   since we support max 1TB of memory.
   Moved data structure in commit that uses it
---
 xen/arch/arm/include/asm/arm64/mpu.h | 52 ++++++++++++++++++++++++++++
 xen/arch/arm/include/asm/mpu.h       |  4 +++
 2 files changed, 56 insertions(+)
 create mode 100644 xen/arch/arm/include/asm/arm64/mpu.h

diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h
new file mode 100644
index 000000000000..4737868507d9
--- /dev/null
+++ b/xen/arch/arm/include/asm/arm64/mpu.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef ARM_ARM64_MPU_H
+#define ARM_ARM64_MPU_H
+
+#ifndef __ASSEMBLY__
+
+/* Protection Region Base Address Register */
+typedef union {
+    struct __packed {
+        unsigned long xn_0:1;     /* Execute-Never XN[0] */
+        unsigned long xn:1;       /* Execute-Never XN[1] */
+        unsigned long ap_0:1;     /* Access Permission AP[0] */
+        unsigned long ro:1;       /* Access Permission AP[1] */
+        unsigned long sh:2;       /* Shareability */
+        unsigned long base:42;    /* Base Address */
+        unsigned long res0:16;    /* RES0 */
+    } reg;
+    uint64_t bits;
+} prbar_t;
+
+/* Protection Region Limit Address Register */
+typedef union {
+    struct __packed {
+        unsigned long en:1;     /* Region enable */
+        unsigned long ai:3;     /* Memory Attribute Index */
+        unsigned long ns:1;     /* Not-Secure */
+        unsigned long res0:1;   /* RES0 */
+        unsigned long limit:42; /* Limit Address */
+        unsigned long res1:16;  /* RES0 */
+    } reg;
+    uint64_t bits;
+} prlar_t;
+
+/* MPU Protection Region */
+typedef struct {
+    prbar_t prbar;
+    prlar_t prlar;
+} pr_t;
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* ARM_ARM64_MPU_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index d4ec4248b62b..bb83f5a5f580 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -6,6 +6,10 @@
 #ifndef __ARM_MPU_H__
 #define __ARM_MPU_H__
 
+#if defined(CONFIG_ARM_64)
+# include 
+#endif
+
 #define MPU_REGION_SHIFT  6
 #define MPU_REGION_ALIGN  (_AC(1, UL) << MPU_REGION_SHIFT)
 #define MPU_REGION_MASK   (~(MPU_REGION_ALIGN - 1))
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 23 06:54:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 06:54:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995194.1377727 (Exim 4.92)
	(envelope-from )
	id 1uIMIQ-0002fZ-6l; Fri, 23 May 2025 06:54:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995194.1377727; Fri, 23 May 2025 06:54:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uIMIQ-0002fQ-2r; Fri, 23 May 2025 06:54:22 +0000
Received: by outflank-mailman (input) for mailman id 995194;
 Fri, 23 May 2025 06:54:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMIO-0002CD-OS
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 06:54:20 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id bd87fdf4-37a2-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 08:54:15 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7FE3B1758;
 Thu, 22 May 2025 23:54:00 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 98A1A3F673;
 Thu, 22 May 2025 23:54: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" 
X-Inumbo-ID: bd87fdf4-37a2-11f0-b892-0df219b8e170
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v6 0/6] First chunk for Arm R82 and MPU support
Date: Fri, 23 May 2025 07:54:00 +0100
Message-Id: <20250523065406.3795420-1-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi all,

This is the first chunk of work to support MPU and R82 on Xen, this serie
reaches the early boot stages just before early_fdt_map(), just to give an idea
about which stage of the boot is reached.

v6:
 - general fixes listed on each patch
v5:
 - dropped patch that touches page.h, it is not needed
 - general fixes listed on each patch
v4:
 - dropped setup_mpu() patch and early_fdt_map() patch (needs rework)
 - add new patches: boot protocol and early asm MPU structure update
 - general fixes listed on each patch
v3 changes:
 - stated on each patch
v2 changes for this serie:
 - rebased serie on the MPU skeleton that allow compilation
 - removed some patches already merged in the MPU skeleton

Luca Fancellu (5):
  docs/arm: Document Xen booting protocol on Armv8-R
  arm/mpu: Provide and populate MPU C data structures
  arm/mpu: Provide access to the MPU region from the C code
  arm/mpu: Introduce utility functions for the pr_t type
  arm/mpu: Provide a constructor for pr_t type

Penny Zheng (1):
  arm/mpu: Introduce MPU memory region map structure

 docs/misc/arm/booting.txt                |  11 +-
 xen/arch/arm/arm64/asm-offsets.c         |   7 +
 xen/arch/arm/arm64/cache.S               |  21 +++
 xen/arch/arm/arm64/mpu/head.S            |  25 +++
 xen/arch/arm/include/asm/arm32/mpu.h     |  25 +++
 xen/arch/arm/include/asm/arm64/mpu.h     |  54 ++++++
 xen/arch/arm/include/asm/bitmap-op.inc   |  63 +++++++
 xen/arch/arm/include/asm/mpu.h           |  75 +++++++++
 xen/arch/arm/include/asm/mpu/mm.h        |  41 +++++
 xen/arch/arm/include/asm/mpu/regions.inc |  38 +++++
 xen/arch/arm/mpu/mm.c                    | 205 +++++++++++++++++++++++
 11 files changed, 562 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/arm/include/asm/arm32/mpu.h
 create mode 100644 xen/arch/arm/include/asm/arm64/mpu.h
 create mode 100644 xen/arch/arm/include/asm/bitmap-op.inc

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 23 06:54:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 06:54:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995195.1377732 (Exim 4.92)
	(envelope-from )
	id 1uIMIQ-0002ip-Fz; Fri, 23 May 2025 06:54:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995195.1377732; Fri, 23 May 2025 06:54:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uIMIQ-0002i2-BQ; Fri, 23 May 2025 06:54:22 +0000
Received: by outflank-mailman (input) for mailman id 995195;
 Fri, 23 May 2025 06:54:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMIP-0002FX-1v
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 06:54:21 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id c052e6ea-37a2-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 08:54:20 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 49EBF1764;
 Thu, 22 May 2025 23:54:05 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8D3313F673;
 Thu, 22 May 2025 23:54:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c052e6ea-37a2-11f0-a2fb-13f23c93f187
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v6 3/6] arm/mpu: Provide and populate MPU C data structures
Date: Fri, 23 May 2025 07:54:03 +0100
Message-Id: <20250523065406.3795420-4-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250523065406.3795420-1-luca.fancellu@arm.com>
References: <20250523065406.3795420-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Provide some data structure in the C world to track the MPU
status, these structures will be filled at boot by the assembly
early code with the boot MPU regions and afterwards they will be
used at runtime.

Provide methods to update a bitmap created with DECLARE_BITMAP
from the assembly code for both Arm32 and Arm64.

Modify Arm64 assembly boot code to reset any unused MPU region,
initialise 'max_mpu_regions' with the number of supported MPU
regions and modify the common asm macro 'prepare_xen_region' to
load into xen_mpumap the MPU status and set/clear the bitmap
'xen_mpumap_mask' used to track the enabled regions.

Provide a stub implementation for the pr_t type and asm macro
for the Arm32 to prevent compilation break, they will be
implemented later.

Signed-off-by: Luca Fancellu 
---
v6 changes:
 - Improved comments on bitmap-op.inc
 - invalidate cache for max_mpu_regions, provide a function to
   invalidate a range, used for xen_mpumap_mask and xen_mpumap
 - code style fixes
v5 changes:
 - changed variable name from 'max_xen_mpumap' to 'max_mpu_regions'
 - code style fixes
 - reverted back changes about parameter name of prepare_xen_region
 - optimised address computation for xen_mpumap entries
 - modified MAX_MPU_REGION_NR
v4 changes:
 - new patch
---
 xen/arch/arm/arm64/asm-offsets.c         |  7 +++
 xen/arch/arm/arm64/cache.S               | 21 ++++++++
 xen/arch/arm/arm64/mpu/head.S            | 25 ++++++++++
 xen/arch/arm/include/asm/arm32/mpu.h     | 25 ++++++++++
 xen/arch/arm/include/asm/bitmap-op.inc   | 63 ++++++++++++++++++++++++
 xen/arch/arm/include/asm/mpu.h           |  5 ++
 xen/arch/arm/include/asm/mpu/mm.h        |  7 +++
 xen/arch/arm/include/asm/mpu/regions.inc | 38 ++++++++++++++
 xen/arch/arm/mpu/mm.c                    | 16 ++++++
 9 files changed, 207 insertions(+)
 create mode 100644 xen/arch/arm/include/asm/arm32/mpu.h
 create mode 100644 xen/arch/arm/include/asm/bitmap-op.inc

diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
index 602ffa5b5472..320289b281c5 100644
--- a/xen/arch/arm/arm64/asm-offsets.c
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -68,6 +69,12 @@ void __dummy__(void)
    OFFSET(ARM_SMCCC_1_2_REGS_X14_OFFS, struct arm_smccc_1_2_regs, a14);
    OFFSET(ARM_SMCCC_1_2_REGS_X16_OFFS, struct arm_smccc_1_2_regs, a16);
    BLANK();
+
+#ifdef CONFIG_MPU
+   DEFINE(XEN_MPUMAP_MASK_sizeof, sizeof(xen_mpumap_mask));
+   DEFINE(XEN_MPUMAP_sizeof, sizeof(xen_mpumap));
+   BLANK();
+#endif
 }
 
 /*
diff --git a/xen/arch/arm/arm64/cache.S b/xen/arch/arm/arm64/cache.S
index c0a8ca163a47..d3c13d98cc12 100644
--- a/xen/arch/arm/arm64/cache.S
+++ b/xen/arch/arm/arm64/cache.S
@@ -50,3 +50,24 @@ FUNC(__flush_dcache_area)
 	dsb	sy
 	ret
 END(__flush_dcache_area)
+
+/*
+ *	__invalidate_dcache_area(addr, size)
+ *
+ *	Ensure that the data held in the cache for the buffer is invalidated.
+ *
+ *	- addr    - start address of the buffer
+ *	- size    - size of the buffer
+ */
+FUNC(__invalidate_dcache_area)
+	dcache_line_size x2, x3
+	add	x1, x0, x1
+	sub	x3, x2, #1
+	bic	x0, x0, x3
+1:	dc	ivac, x0			/* invalidate D line / unified line */
+	add	x0, x0, x2
+	cmp	x0, x1
+	b.lo	1b
+	dsb	sy
+	ret
+END(__invalidate_dcache_area)
diff --git a/xen/arch/arm/arm64/mpu/head.S b/xen/arch/arm/arm64/mpu/head.S
index 6d336cafbbaf..5df0af571e1c 100644
--- a/xen/arch/arm/arm64/mpu/head.S
+++ b/xen/arch/arm/arm64/mpu/head.S
@@ -40,6 +40,10 @@ FUNC(enable_boot_cpu_mm)
     mrs   x5, MPUIR_EL2
     and   x5, x5, #NUM_MPU_REGIONS_MASK
 
+    ldr   x0, =max_mpu_regions
+    strb  w5, [x0]
+    dc ivac, x0                 /* Invalidate cache for max_mpu_regions addr */
+
     /* x0: region sel */
     mov   x0, xzr
     /* Xen text section. */
@@ -74,6 +78,27 @@ FUNC(enable_boot_cpu_mm)
     prepare_xen_region x0, x1, x2, x3, x4, x5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR
 #endif
 
+zero_mpu:
+    /* Reset remaining MPU regions */
+    cmp   x0, x5
+    beq   out_zero_mpu
+    mov   x1, #0
+    mov   x2, #1
+    prepare_xen_region x0, x1, x2, x3, x4, x5, attr_prlar=REGION_DISABLED_PRLAR
+    b     zero_mpu
+
+out_zero_mpu:
+    /* Invalidate data cache for MPU data structures */
+    mov x4, lr
+    ldr x0, =xen_mpumap_mask
+    mov x1, #XEN_MPUMAP_MASK_sizeof
+    bl __invalidate_dcache_area
+
+    ldr x0, =xen_mpumap
+    mov x1, #XEN_MPUMAP_sizeof
+    bl __invalidate_dcache_area
+    mov lr, x4
+
     b    enable_mpu
     ret
 END(enable_boot_cpu_mm)
diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h
new file mode 100644
index 000000000000..f0d4d4055cb2
--- /dev/null
+++ b/xen/arch/arm/include/asm/arm32/mpu.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef ARM_ARM32_MPU_H
+#define ARM_ARM32_MPU_H
+
+#ifndef __ASSEMBLY__
+
+/* MPU Protection Region */
+typedef struct {
+    uint32_t prbar;
+    uint32_t prlar;
+} pr_t;
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* ARM_ARM32_MPU_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/include/asm/bitmap-op.inc b/xen/arch/arm/include/asm/bitmap-op.inc
new file mode 100644
index 000000000000..dd8563e02a33
--- /dev/null
+++ b/xen/arch/arm/include/asm/bitmap-op.inc
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+/*
+ * Sets a bit in a bitmap declared by DECLARE_BITMAP, symbol name passed through
+ * bitmap_symbol.
+ *
+ * bitmap_set_bit:      symbol of the bitmap declared by DECLARE_BITMAP
+ * bit:                 bit number to be set in the bitmap
+ * tmp1-tmp4:           temporary registers used for the computation
+ *
+ * Preserves: bit.
+ * Clobbers:  tmp1, tmp2, tmp3, tmp4.
+ */
+.macro bitmap_set_bit bitmap_symbol, bit, tmp1, tmp2, tmp3, tmp4
+    adr_l   \tmp1, \bitmap_symbol
+    mov     \tmp2, #(BYTES_PER_LONG - 1)
+    mvn     \tmp2, \tmp2                        /* mask for the alignment ~(BYTES_PER_LONG - 1) */
+    lsr     \tmp3, \bit, #3                     /* retrieve byte offset (bit/8) */
+    and     \tmp2, \tmp3, \tmp2                 /* word offset = (bit/8) & ~(BYTES_PER_LONG - 1) */
+    add     \tmp1, \tmp1, \tmp2                 /* bitmap_symbol + word offset */
+    and     \tmp2, \bit, #(BITS_PER_LONG - 1)   /* bit offset inside word */
+
+    ldr     \tmp3, [\tmp1]
+    mov     \tmp4, #1
+    lsl     \tmp4, \tmp4, \tmp2                 /* (1 << offset) */
+    orr     \tmp3, \tmp3, \tmp4                 /* set the bit */
+    str     \tmp3, [\tmp1]
+.endm
+
+/*
+ * Clears a bit in a bitmap declared by DECLARE_BITMAP, symbol name passed
+ * through bitmap_symbol.
+ *
+ * bitmap_set_bit:      symbol of the bitmap declared by DECLARE_BITMAP
+ * bit:                 bit number to be set in the bitmap
+ * tmp1-tmp4:           temporary registers used for the computation
+ *
+ * Preserves: bit.
+ * Clobbers:  tmp1, tmp2, tmp3, tmp4.
+ */
+.macro bitmap_clear_bit bitmap_symbol, bit, tmp1, tmp2, tmp3, tmp4
+    adr_l   \tmp1, \bitmap_symbol
+    mov     \tmp2, #(BYTES_PER_LONG - 1)
+    mvn     \tmp2, \tmp2                        /* mask for the alignment ~(BYTES_PER_LONG - 1) */
+    lsr     \tmp3, \bit, #3                     /* retrieve byte offset (bit/8) */
+    and     \tmp2, \tmp3, \tmp2                 /* word offset = (bit/8) & ~(BYTES_PER_LONG - 1) */
+    add     \tmp1, \tmp1, \tmp2                 /* bitmap_symbol + word offset */
+    and     \tmp2, \bit, #(BITS_PER_LONG - 1)   /* bit offset inside word */
+
+    ldr     \tmp3, [\tmp1]
+    mov     \tmp4, #1
+    lsl     \tmp4, \tmp4, \tmp2                 /* (1 << offset) */
+    mvn     \tmp4, \tmp4                        /* ~(1 << offset) */
+    and     \tmp3, \tmp3, \tmp4                 /* clear the bit */
+    str     \tmp3, [\tmp1]
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index bb83f5a5f580..fb93b8b19d24 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -8,6 +8,10 @@
 
 #if defined(CONFIG_ARM_64)
 # include 
+#elif defined(CONFIG_ARM_32)
+# include 
+#else
+# error "unknown ARM variant"
 #endif
 
 #define MPU_REGION_SHIFT  6
@@ -17,6 +21,7 @@
 #define NUM_MPU_REGIONS_SHIFT   8
 #define NUM_MPU_REGIONS         (_AC(1, UL) << NUM_MPU_REGIONS_SHIFT)
 #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
+#define MAX_MPU_REGION_NR       NUM_MPU_REGIONS_MASK
 
 #endif /* __ARM_MPU_H__ */
 
diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
index bfd840fa5d31..409b4dd53dc6 100644
--- a/xen/arch/arm/include/asm/mpu/mm.h
+++ b/xen/arch/arm/include/asm/mpu/mm.h
@@ -8,9 +8,16 @@
 #include 
 #include 
 #include 
+#include 
 
 extern struct page_info *frame_table;
 
+extern uint8_t max_mpu_regions;
+
+extern DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR);
+
+extern pr_t xen_mpumap[MAX_MPU_REGION_NR];
+
 #define virt_to_maddr(va) ((paddr_t)((vaddr_t)(va) & PADDR_MASK))
 
 #ifdef CONFIG_ARM_32
diff --git a/xen/arch/arm/include/asm/mpu/regions.inc b/xen/arch/arm/include/asm/mpu/regions.inc
index 47868a152662..aab2246ee72b 100644
--- a/xen/arch/arm/include/asm/mpu/regions.inc
+++ b/xen/arch/arm/include/asm/mpu/regions.inc
@@ -1,14 +1,34 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include 
 #include 
 #include 
 
 /* Backgroud region enable/disable */
 #define SCTLR_ELx_BR    BIT(17, UL)
 
+#define REGION_DISABLED_PRLAR   0x00    /* NS=0 ATTR=000 EN=0 */
 #define REGION_NORMAL_PRLAR     0x0f    /* NS=0 ATTR=111 EN=1 */
 #define REGION_DEVICE_PRLAR     0x09    /* NS=0 ATTR=100 EN=1 */
 
+#define PRLAR_ELx_EN            0x1
+
+#ifdef CONFIG_ARM_64
+#define XEN_MPUMAP_ENTRY_SHIFT  0x4     /* 16 byte structure */
+
+.macro store_pair reg1, reg2, dst
+    stp \reg1, \reg2, [\dst]
+.endm
+
+#else
+#define XEN_MPUMAP_ENTRY_SHIFT  0x3     /* 8 byte structure */
+
+.macro store_pair reg1, reg2, dst
+    .word 0xe7f000f0                    /* unimplemented */
+.endm
+
+#endif
+
 /*
  * Macro to prepare and set a EL2 MPU memory region.
  * We will also create an according MPU memory region entry, which
@@ -59,6 +79,24 @@
     dsb   sy
     isb
 
+    /* Load pair into xen_mpumap and invalidate cache */
+    adr_l \base, xen_mpumap
+    add   \base, \base, \sel, LSL #XEN_MPUMAP_ENTRY_SHIFT
+    store_pair \prbar, \prlar, \base
+
+    /* Set/clear xen_mpumap_mask bitmap */
+    tst   \prlar, #PRLAR_ELx_EN
+    bne   2f
+    /* Region is disabled, clear the bit in the bitmap */
+    bitmap_clear_bit xen_mpumap_mask, \sel, \base, \limit, \prbar, \prlar
+    b     3f
+
+2:
+    /* Region is enabled, set the bit in the bitmap */
+    bitmap_set_bit xen_mpumap_mask, \sel, \base, \limit, \prbar, \prlar
+
+3:
+
     add   \sel, \sel, #1
 
 1:
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 07c8959f4ee9..2f31b7b78763 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -7,9 +7,25 @@
 #include 
 #include 
 #include 
+#include 
 
 struct page_info *frame_table;
 
+/* Maximum number of supported MPU memory regions by the EL2 MPU. */
+uint8_t __ro_after_init max_mpu_regions;
+
+/*
+ * Bitmap xen_mpumap_mask is to record the usage of EL2 MPU memory regions.
+ * Bit 0 represents MPU memory region 0, bit 1 represents MPU memory
+ * region 1, ..., and so on.
+ * If a MPU memory region gets enabled, set the according bit to 1.
+ */
+DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
+    __cacheline_aligned __section(".data");
+
+/* EL2 Xen MPU memory region mapping table. */
+pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR];
+
 static void __init __maybe_unused build_assertions(void)
 {
     /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 23 06:54:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 06:54:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995196.1377748 (Exim 4.92)
	(envelope-from )
	id 1uIMIS-0003Ak-OR; Fri, 23 May 2025 06:54:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995196.1377748; Fri, 23 May 2025 06:54:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uIMIS-0003Aa-KR; Fri, 23 May 2025 06:54:24 +0000
Received: by outflank-mailman (input) for mailman id 995196;
 Fri, 23 May 2025 06:54:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMIQ-0002FX-G8
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 06:54:22 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id c12a4fa4-37a2-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 08:54:21 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8FAC91758;
 Thu, 22 May 2025 23:54:06 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 07E183F673;
 Thu, 22 May 2025 23:54: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" 
X-Inumbo-ID: c12a4fa4-37a2-11f0-a2fb-13f23c93f187
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v6 4/6] arm/mpu: Provide access to the MPU region from the C code
Date: Fri, 23 May 2025 07:54:04 +0100
Message-Id: <20250523065406.3795420-5-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250523065406.3795420-1-luca.fancellu@arm.com>
References: <20250523065406.3795420-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement some utility functions in order to access the MPU regions
from the C world.

Signed-off-by: Luca Fancellu 
Reviewed-by: Michal Orzel 
---
v6 changes:
 - add break to default in the switch
 - modify comment and style fixes
 - Add R-by Michal
v5 changes:
 - move MPU_REGION_RES0 to arm64, fixed typos and code style.
v4 changes:
 - moved back PRBAR0_EL2/PRLAR0_EL2 to mm.c and protect
   them with CONFIG_ARM_64, changed comments, fixed typos and code
   style
 - Add PRBAR_EL2_(n) definition, to be overriden by Arm32
 - protect prepare_selector, read_protection_region,
   write_protection_region by Arm64 to ensure compilation on both
   arm32 and arm64, Arm32 will modify that later while introducing
   the arm32 bits.
v3 changes:
 - Moved PRBAR0_EL2/PRLAR0_EL2 to arm64 specific
 - Modified prepare_selector() to be easily made a NOP
   for Arm32, which can address up to 32 region without
   changing selector and it is also its maximum amount
   of MPU regions.
---
---
 xen/arch/arm/include/asm/arm64/mpu.h |   2 +
 xen/arch/arm/include/asm/mpu/mm.h    |  24 ++++++
 xen/arch/arm/mpu/mm.c                | 121 +++++++++++++++++++++++++++
 3 files changed, 147 insertions(+)

diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h
index 4737868507d9..f0ce344e789b 100644
--- a/xen/arch/arm/include/asm/arm64/mpu.h
+++ b/xen/arch/arm/include/asm/arm64/mpu.h
@@ -5,6 +5,8 @@
 
 #ifndef __ASSEMBLY__
 
+#define MPU_REGION_RES0        (0xFFFFULL << 48)
+
 /* Protection Region Base Address Register */
 typedef union {
     struct __packed {
diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
index 409b4dd53dc6..d7950d9b4fbb 100644
--- a/xen/arch/arm/include/asm/mpu/mm.h
+++ b/xen/arch/arm/include/asm/mpu/mm.h
@@ -41,6 +41,30 @@ static inline struct page_info *virt_to_page(const void *v)
     return mfn_to_page(mfn);
 }
 
+/* Utility function to be used whenever MPU regions are modified */
+static inline void context_sync_mpu(void)
+{
+    /*
+     * ARM DDI 0600B.a, C1.7.1
+     * Writes to MPU registers are only guaranteed to be visible following a
+     * Context synchronization event and DSB operation.
+     */
+    dsb(sy);
+    isb();
+}
+
+/*
+ * The following API requires context_sync_mpu() after being used to modify MPU
+ * regions:
+ *  - write_protection_region
+ */
+
+/* Reads the MPU region (into @pr_read) with index @sel from the HW */
+void read_protection_region(pr_t *pr_read, uint8_t sel);
+
+/* Writes the MPU region (from @pr_write) with index @sel to the HW */
+void write_protection_region(const pr_t *pr_write, uint8_t sel);
+
 #endif /* __ARM_MPU_MM_H__ */
 
 /*
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 2f31b7b78763..9c5789cdf1f9 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 struct page_info *frame_table;
 
@@ -26,6 +28,35 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \
 /* EL2 Xen MPU memory region mapping table. */
 pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR];
 
+#ifdef CONFIG_ARM_64
+/*
+ * The following are needed for the cases: GENERATE_WRITE_PR_REG_CASE
+ * and GENERATE_READ_PR_REG_CASE with num==0
+ */
+#define PRBAR0_EL2 PRBAR_EL2
+#define PRLAR0_EL2 PRLAR_EL2
+
+#define PRBAR_EL2_(n)   PRBAR##n##_EL2
+#define PRLAR_EL2_(n)   PRLAR##n##_EL2
+
+#endif /* CONFIG_ARM_64 */
+
+#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
+    case num:                                                               \
+    {                                                                       \
+        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
+        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
+        break;                                                              \
+    }
+
+#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
+    case num:                                                   \
+    {                                                           \
+        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
+        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
+        break;                                                  \
+    }
+
 static void __init __maybe_unused build_assertions(void)
 {
     /*
@@ -36,6 +67,96 @@ static void __init __maybe_unused build_assertions(void)
     BUILD_BUG_ON(PAGE_SIZE != SZ_4K);
 }
 
+#ifdef CONFIG_ARM_64
+/*
+ * Armv8-R supports direct access and indirect access to the MPU regions through
+ * registers:
+ *  - indirect access involves changing the MPU region selector, issuing an isb
+ *    barrier and accessing the selected region through specific registers
+ *  - direct access involves accessing specific registers that point to
+ *    specific MPU regions, without changing the selector, avoiding the use of
+ *    a barrier.
+ * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR_ELx (for n=1..15) are
+ * used for the direct access to the regions selected by
+ * PRSELR_EL2.REGION<7:4>:n, so 16 regions can be directly accessed when the
+ * selector is a multiple of 16, giving access to all the supported memory
+ * regions.
+ */
+static void prepare_selector(uint8_t *sel)
+{
+    uint8_t cur_sel = *sel;
+
+    /*
+     * {read,write}_protection_region works using the direct access to the 0..15
+     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
+     * only when needed, so when the upper 4 bits of the selector will change.
+     */
+    cur_sel &= 0xF0U;
+    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
+    {
+        WRITE_SYSREG(cur_sel, PRSELR_EL2);
+        isb();
+    }
+    *sel &= 0xFU;
+}
+
+void read_protection_region(pr_t *pr_read, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_READ_PR_REG_CASE(0, pr_read);
+        GENERATE_READ_PR_REG_CASE(1, pr_read);
+        GENERATE_READ_PR_REG_CASE(2, pr_read);
+        GENERATE_READ_PR_REG_CASE(3, pr_read);
+        GENERATE_READ_PR_REG_CASE(4, pr_read);
+        GENERATE_READ_PR_REG_CASE(5, pr_read);
+        GENERATE_READ_PR_REG_CASE(6, pr_read);
+        GENERATE_READ_PR_REG_CASE(7, pr_read);
+        GENERATE_READ_PR_REG_CASE(8, pr_read);
+        GENERATE_READ_PR_REG_CASE(9, pr_read);
+        GENERATE_READ_PR_REG_CASE(10, pr_read);
+        GENERATE_READ_PR_REG_CASE(11, pr_read);
+        GENERATE_READ_PR_REG_CASE(12, pr_read);
+        GENERATE_READ_PR_REG_CASE(13, pr_read);
+        GENERATE_READ_PR_REG_CASE(14, pr_read);
+        GENERATE_READ_PR_REG_CASE(15, pr_read);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+
+void write_protection_region(const pr_t *pr_write, uint8_t sel)
+{
+    prepare_selector(&sel);
+
+    switch ( sel )
+    {
+        GENERATE_WRITE_PR_REG_CASE(0, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(1, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(2, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(3, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(4, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(5, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(6, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(7, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(8, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(9, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(10, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(11, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(12, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(13, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(14, pr_write);
+        GENERATE_WRITE_PR_REG_CASE(15, pr_write);
+    default:
+        BUG(); /* Can't happen */
+        break;
+    }
+}
+#endif /* CONFIG_ARM_64 */
+
 void __init setup_mm(void)
 {
     BUG_ON("unimplemented");
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 23 06:54:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 06:54:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995197.1377754 (Exim 4.92)
	(envelope-from )
	id 1uIMIT-0003JC-Ay; Fri, 23 May 2025 06:54:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995197.1377754; Fri, 23 May 2025 06:54: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 1uIMIT-0003H6-6N; Fri, 23 May 2025 06:54:25 +0000
Received: by outflank-mailman (input) for mailman id 995197;
 Fri, 23 May 2025 06:54:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMIR-0002FX-L5
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 06:54:23 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id c1e8c1fc-37a2-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 08:54:22 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D4A021A2D;
 Thu, 22 May 2025 23:54:07 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4C7183F673;
 Thu, 22 May 2025 23:54: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" 
X-Inumbo-ID: c1e8c1fc-37a2-11f0-a2fb-13f23c93f187
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v6 5/6] arm/mpu: Introduce utility functions for the pr_t type
Date: Fri, 23 May 2025 07:54:05 +0100
Message-Id: <20250523065406.3795420-6-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250523065406.3795420-1-luca.fancellu@arm.com>
References: <20250523065406.3795420-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce a few utility functions to manipulate and handle the
pr_t type.

Signed-off-by: Luca Fancellu 
---
v6 changes:
 - constify pointer arguments when needed, code style fix,
   add clarification comment in pr_set_limit
v5 changes:
 - Don't rely on bitfield and use the mask MPU_REGION_RES0 for
   pr_set_base and pr_set_limit to make it explicit. Fixed typos
   in commit message.
v4 changes:
 - Modify comment on top of the helpers. Clarify pr_set_limit
   takes exclusive address.
   Protected common code with #ifdef Arm64 until Arm32 is ready
   with pr_t
---
 xen/arch/arm/include/asm/mpu.h | 66 ++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
index fb93b8b19d24..8f06ddac0fb1 100644
--- a/xen/arch/arm/include/asm/mpu.h
+++ b/xen/arch/arm/include/asm/mpu.h
@@ -23,6 +23,72 @@
 #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
 #define MAX_MPU_REGION_NR       NUM_MPU_REGIONS_MASK
 
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_ARM_64
+/*
+ * Set base address of MPU protection region.
+ *
+ * @pr: pointer to the protection region structure.
+ * @base: base address as base of the protection region.
+ */
+static inline void pr_set_base(pr_t *pr, paddr_t base)
+{
+    pr->prbar.reg.base = ((base & ~MPU_REGION_RES0) >> MPU_REGION_SHIFT);
+}
+
+/*
+ * Set limit address of MPU protection region.
+ *
+ * @pr: pointer to the protection region structure.
+ * @limit: exclusive address as limit of the protection region.
+ */
+static inline void pr_set_limit(pr_t *pr, paddr_t limit)
+{
+    /* PRLAR_ELx.LIMIT expects inclusive limit */
+    pr->prlar.reg.limit = (((limit - 1) & ~MPU_REGION_RES0)
+                           >> MPU_REGION_SHIFT);
+}
+
+/*
+ * Access to get base address of MPU protection region.
+ * The base address shall be zero extended.
+ *
+ * @pr: pointer to the protection region structure.
+ * @return: Base address configured for the passed protection region.
+ */
+static inline paddr_t pr_get_base(const pr_t *pr)
+{
+    return (paddr_t)(pr->prbar.reg.base << MPU_REGION_SHIFT);
+}
+
+/*
+ * Access to get limit address of MPU protection region.
+ * The limit address shall be concatenated with 0x3f.
+ *
+ * @pr: pointer to the protection region structure.
+ * @return: Inclusive limit address configured for the passed protection region.
+ */
+static inline paddr_t pr_get_limit(const pr_t *pr)
+{
+    return (paddr_t)((pr->prlar.reg.limit << MPU_REGION_SHIFT)
+                     | ~MPU_REGION_MASK);
+}
+
+/*
+ * Check if the protection region is valid (enabled).
+ *
+ * @pr: pointer to the protection region structure.
+ * @return: True if the region is valid (enabled), false otherwise.
+ */
+static inline bool region_is_valid(const pr_t *pr)
+{
+    return pr->prlar.reg.en;
+}
+#endif /* CONFIG_ARM_64 */
+
+#endif /* __ASSEMBLY__ */
+
 #endif /* __ARM_MPU_H__ */
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 23 06:54:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 06:54:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995199.1377768 (Exim 4.92)
	(envelope-from )
	id 1uIMIV-0003jG-LA; Fri, 23 May 2025 06:54:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995199.1377768; Fri, 23 May 2025 06: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 1uIMIV-0003j2-Gy; Fri, 23 May 2025 06:54:27 +0000
Received: by outflank-mailman (input) for mailman id 995199;
 Fri, 23 May 2025 06:54:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMIU-0002CD-5P
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 06:54:26 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id c2ae0e57-37a2-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 08:54:24 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 24FF11764;
 Thu, 22 May 2025 23:54:09 -0700 (PDT)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 917D33F673;
 Thu, 22 May 2025 23:54: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" 
X-Inumbo-ID: c2ae0e57-37a2-11f0-b892-0df219b8e170
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v6 6/6] arm/mpu: Provide a constructor for pr_t type
Date: Fri, 23 May 2025 07:54:06 +0100
Message-Id: <20250523065406.3795420-7-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250523065406.3795420-1-luca.fancellu@arm.com>
References: <20250523065406.3795420-1-luca.fancellu@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Provide a function that creates a pr_t object from a memory
range and some attributes.

Signed-off-by: Luca Fancellu 
Reviewed-by: Michal Orzel 
---
v6 changes:
 - explicitly initialise also xn_0 and ap_0.
v5 changes:
 - removed AP_RW_EL2 used only by pr_of_xenaddr(), fixed
   comments and typos
 - Given some comments to the page.h flags and modifications
   to the prbar_t fields ap, xn, the constructor now takes
   flags instead of attr_idx, which I believe it's better,
   deleted PRBAR_EL2_XN_ENABLED since now the PAGE_XN_MASK()
   is used instead.
 - renamed to pr_of_addr since it will be used also in p2m
v4 changes:
 - update helper comments
 - rename XN_EL2_ENABLED to PRBAR_EL2_XN_ENABLED
 - protected pr_of_xenaddr() with #ifdef Arm64 until Arm32
   can build with it
---
 xen/arch/arm/include/asm/mpu/mm.h | 10 +++++
 xen/arch/arm/mpu/mm.c             | 68 +++++++++++++++++++++++++++++++
 2 files changed, 78 insertions(+)

diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h
index d7950d9b4fbb..a7f970b465fe 100644
--- a/xen/arch/arm/include/asm/mpu/mm.h
+++ b/xen/arch/arm/include/asm/mpu/mm.h
@@ -65,6 +65,16 @@ void read_protection_region(pr_t *pr_read, uint8_t sel);
 /* Writes the MPU region (from @pr_write) with index @sel to the HW */
 void write_protection_region(const pr_t *pr_write, uint8_t sel);
 
+/*
+ * Creates a pr_t structure describing a protection region.
+ *
+ * @base: base address as base of the protection region.
+ * @limit: exclusive address as limit of the protection region.
+ * @flags: memory flags for the mapping.
+ * @return: pr_t structure describing a protection region.
+ */
+pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags);
+
 #endif /* __ARM_MPU_MM_H__ */
 
 /*
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 9c5789cdf1f9..86fbe105af45 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct page_info *frame_table;
@@ -155,6 +156,73 @@ void write_protection_region(const pr_t *pr_write, uint8_t sel)
         break;
     }
 }
+
+pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags)
+{
+    unsigned int attr_idx = PAGE_AI_MASK(flags);
+    prbar_t prbar;
+    prlar_t prlar;
+    pr_t region;
+
+    /* Build up value for PRBAR_EL2. */
+    prbar = (prbar_t) {
+        .reg = {
+            .xn_0 = 0,
+            .xn = PAGE_XN_MASK(flags),
+            .ap_0 = 0,
+            .ro = PAGE_RO_MASK(flags)
+        }};
+
+    switch ( attr_idx )
+    {
+    /*
+     * ARM ARM: Shareable, Inner Shareable, and Outer Shareable Normal memory
+     * (DDI 0487L.a B2.10.1.1.1 Note section):
+     *
+     * Because all data accesses to Non-cacheable locations are data coherent
+     * to all observers, Non-cacheable locations are always treated as Outer
+     * Shareable
+     *
+     * ARM ARM: Device memory (DDI 0487L.a B2.10.2)
+     *
+     * All of these memory types have the following properties:
+     * [...]
+     *  - Data accesses to memory locations are coherent for all observers in
+     *    the system, and correspondingly are treated as being Outer Shareable
+     */
+    case MT_NORMAL_NC:
+        /* Fall through */
+    case MT_DEVICE_nGnRnE:
+        /* Fall through */
+    case MT_DEVICE_nGnRE:
+        prbar.reg.sh = LPAE_SH_OUTER;
+        break;
+    default:
+        /* Xen mappings are SMP coherent */
+        prbar.reg.sh = LPAE_SH_INNER;
+        break;
+    }
+
+    /* Build up value for PRLAR_EL2. */
+    prlar = (prlar_t) {
+        .reg = {
+            .ns = 0,        /* Hyp mode is in secure world */
+            .ai = attr_idx,
+            .en = 1,        /* Region enabled */
+        }};
+
+    /* Build up MPU memory region. */
+    region = (pr_t) {
+        .prbar = prbar,
+        .prlar = prlar,
+    };
+
+    /* Set base address and limit address. */
+    pr_set_base(®ion, base);
+    pr_set_limit(®ion, limit);
+
+    return region;
+}
 #endif /* CONFIG_ARM_64 */
 
 void __init setup_mm(void)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri May 23 06:59:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 06:59:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995238.1377777 (Exim 4.92)
	(envelope-from )
	id 1uIMNP-0005u5-5J; Fri, 23 May 2025 06:59:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995238.1377777; Fri, 23 May 2025 06:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uIMNP-0005ty-2c; Fri, 23 May 2025 06:59:31 +0000
Received: by outflank-mailman (input) for mailman id 995238;
 Fri, 23 May 2025 06:59:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMNN-0005ts-GH
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 06:59:29 +0000
Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com
 [2607:f8b0:4864:20::c35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 772c869f-37a3-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 08:59:27 +0200 (CEST)
Received: by mail-oo1-xc35.google.com with SMTP id
 006d021491bc7-6063462098eso5297859eaf.0
 for ; Thu, 22 May 2025 23:59: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" 
X-Inumbo-ID: 772c869f-37a3-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1747983566; x=1748588366; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pzv5Uzo3oVDQWCbe0urs8nyJkbsNIvksTp0BxiMzQZw=;
        b=DP9w3zIcr1eYeR4AYT7Tm3ZN67NjdVjnn02KJ2nX9V6s/VJXgPzG8Kjf2L5IjpF+WT
         nCe6HHwvd/aBbD1Ts4c+4pzmPUicbTrOThkGFwtkFgq2s/I9yBKFph12ZvacEsEqWAVQ
         uoP57YeJTvQk88IHk6t4tvl8XUyU67e3Fvn8bsa3IBMVY00RAKDS9PSv+eRMbXz+uKUF
         EJ9+72CWMZy9KOKCWYggdTalrPDM3r8fT+M/sKXP5lmcoOk6txCQINA1gHCCsLATguoU
         w7+eSwgoYNCX2pC6d3NZVrlEWhOGdS4aRsXpWptvkY9eoM1GJL4ZXY3m1GpG7Fqzxg+q
         8Alw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747983566; x=1748588366;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=pzv5Uzo3oVDQWCbe0urs8nyJkbsNIvksTp0BxiMzQZw=;
        b=dTkbLvjiVdnMJQ/GozSwLY9nmkA5akz48MJ8/DHos1ul+JUVRa5mLqZoxR2VaEdRyV
         ZYjmiaI/Ukqm5pPCp2odzLAbDpoSDS3I6H6iKt0/qk/yW1gvPsValzMFPGZNb/i7Zg6w
         URf1RJjTsvG7XrGqUkBzXL36IH5d86BxfHEflDonni4ZA4cenqN9xRmlusMtJUEBMTQ/
         0bNTJccNeRHteF+KXYDq09/sjXjQuEfUb6y6+fAAmnEOrBZM+O2g6km8/Vectua+dg1h
         i6V+EuxP93SqHz7dmSm2X8ZcHRBzaar/r+1EAs64koV6bfZc9k3f5OSwyhZu09BR9xKx
         GiJg==
X-Gm-Message-State: AOJu0YyDYCnSRwBChiu6L8dtcZYFTQmusfY9WtPxPw9P3DGOFmSVdflx
	APZSvgWYbqP/CfqsGupAYMg9HAJxGmNZ9oZJy1pHfBOYCFTo5QA17HVcR9ugmdDS93gSybDRWQy
	xJkkCT//Qw8JJtHo4BkVnENomtsyl53yG84uGRUnJzA==
X-Gm-Gg: ASbGncsyBxOnCTg/4YEy1V8KAuejj8vjbQ1QpU6MDyq99azjnzl2hzn3iPVQZJyBQ7L
	wlMfJy0qEi6ZDcREfL8CLMKwvDGUsahUyBWArG31jpoKyysFaomnCc8b2qQ4xSH00eGzz1NKcM6
	HGgV4N8B6SdSQs+Czmnk3lQm3Ty5g5l6M84LgK2xgCT0r2
X-Google-Smtp-Source: AGHT+IGaQBeM73r2QZ8edujeAX3PLx+H/hd3tEUcuHnfA3fDC1BVTxGNdf8omk3HSd99MGGsL1x2wuXFivhnWwtf4+c=
X-Received: by 2002:a05:6820:c8a:b0:60b:814a:c1c1 with SMTP id
 006d021491bc7-60b95418911mr922104eaf.8.1747983566190; Thu, 22 May 2025
 23:59:26 -0700 (PDT)
MIME-Version: 1.0
References:  <6e85a4a2de01aee23a366f33b3a856b52171bc40.1747925288.git.bertrand.marquis@arm.com>
In-Reply-To: <6e85a4a2de01aee23a366f33b3a856b52171bc40.1747925288.git.bertrand.marquis@arm.com>
From: Jens Wiklander 
Date: Fri, 23 May 2025 08:59:14 +0200
X-Gm-Features: AX0GCFtiffptfe235zSBaeBOpm4bf6J6-DRrePRsoTyS9vxzwRJrlQb7IpjPlus
Message-ID: 
Subject: Re: [PATCH v6 6/6] xen/arm: ffa: Enable VM to VM without firmware
To: Bertrand Marquis 
Cc: xen-devel@lists.xenproject.org, 
	Volodymyr Babchuk , Stefano Stabellini , 
	Julien Grall , Michal Orzel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bertrand,

On Thu, May 22, 2025 at 5:08=E2=80=AFPM Bertrand Marquis
 wrote:
>
> When VM to VM support is activated and there is no suitable FF-A support
> in the firmware, enable FF-A support for VMs to allow using it for VM to
> VM communications.
> If there is OP-TEE running in the secure world and using the non FF-A
> communication system, having CONFIG_FFA_VM_TO_VM could be non functional
> (if optee is probed first) or OP-TEE could be non functional (if FF-A is
> probed first) so it is not recommended to activate the configuration
> option for such systems.
>
> To make buffer full notification work between VMs when there is no
> firmware, rework the notification handling and modify the global flag to
> only be used as check for firmware notification support instead.
>
> Also split probe function into one for firmware and one for vm to vm to
> make the implementation clearer.
>
> Signed-off-by: Bertrand Marquis 

Looks good!

Reviewed-by: Jens Wiklander 

Cheers,
Jens


From xen-devel-bounces@lists.xenproject.org Fri May 23 07:20:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 07:20:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995303.1377788 (Exim 4.92)
	(envelope-from )
	id 1uIMh8-0000k0-NO; Fri, 23 May 2025 07:19:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995303.1377788; Fri, 23 May 2025 07:19: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 1uIMh8-0000jt-KR; Fri, 23 May 2025 07:19:54 +0000
Received: by outflank-mailman (input) for mailman id 995303;
 Fri, 23 May 2025 07:19:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMh8-0000jn-09
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 07:19:54 +0000
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com
 [2a00:1450:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 513eb175-37a6-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 09:19:51 +0200 (CEST)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43ede096d73so64981175e9.2
 for ; Fri, 23 May 2025 00:19:51 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f6b29672sm138336565e9.3.2025.05.23.00.19.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 23 May 2025 00:19: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" 
X-Inumbo-ID: 513eb175-37a6-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747984791; x=1748589591; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=WubEsBbl7epRqvikWw8YjkhJNj7xX8Sbr3wrYsv9VoA=;
        b=OBV2wF3NPd2EJstax4NNSlfZCBFULZPTtksXHt6VuovYRn6qYhLzcwSyS7HqEidfQG
         ECo3Gf+c1VPV23H9DZwAAb6iPAMWMTAx5MbdUokk89LCR6a2agC00VbKbmHLyXxEaBwl
         DuXGZMMENfVsufGRRq41Wie+WV7YNJvoMU9kk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747984791; x=1748589591;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=WubEsBbl7epRqvikWw8YjkhJNj7xX8Sbr3wrYsv9VoA=;
        b=Pv3Q9rZNacPJad0x11voG0cEVJ3DrEDGcxQ/kllBFobq0hSlpBAkdHev013KXIU6pZ
         C68++Kq+ZhebJdDgxdYOuMBSNYC3gp1HdY0iAkDqgFxov+mxgclYy3mD8gk2pNIpcMAN
         fbTDtcb7AKWpyr49oc/pmWEQdSXlCWIagt8zScC7C5j6akzx72r+GF8T3as+aUo7u2rI
         EMm8fn3sm715+zW9K/FPXWS2Bw2+mkSF6kUQzc3yOykqVwNLFVnKf52rpz8eN+CGyGfU
         WUe/qf4WJ/gfLmK6p1TxhGKDp8vFBv7+dUD9dXQJeZHWQnYUE8X+KQ+FEPNMtVGkRH5J
         7TfA==
X-Forwarded-Encrypted: i=1; AJvYcCWdi+IUI+a3VwIC4pxtubJNJ9aI/0duQa4lISH9aV24/PDLpDbrchmH+yzSXJpziAkH0iZ/VKqT9jE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx95pTuYnHhd5lpoEakyvXkrA7U0Eq2bsaqQPRXO50BhIXXamIH
	2MI+3CY4qXNCCEmJXNuJnsl+eyfBjMG/GMwN6bhExVytweazi4dJPuDRmcbZzY2oLADCFaPiH1z
	Pqjv7
X-Gm-Gg: ASbGncvkdeA9hEkXVKIlW8iR8Tsgy2fyGR7KNcdphQ+kDR8nBlICHD+NZhjBrw+2sTf
	59oX2I+urNB0QGHXx3lhR9bhr3Y5PUpIOhOcT+8BjSkTssJk7g+lNhLYrCl1Q9+8WyhfTZSFs+U
	sD8NCBXGYgGKJa/Ggd0zKN67hhJeb0TOHEFKzlZTccsUk21MbDfIH5D2Dthn9Q6wyZE6jBQw3nF
	NG9wTcZPAlszbTIg8id+2MhOinNJ9liBrrImqmiEIdRkfttTiJCbvhRhLcAfyaNOQ0OQElZh2Xf
	BJows9HJsZ+lkBcGrDVIW8BHaXd91GlJT8G6uRRGHHrbelVaF+UVzACPVUCnsRc9u1jQZtLmTNu
	U8A7vF+coqQeXcN3m3WVUtVeMreDsxw==
X-Google-Smtp-Source: AGHT+IGxLEUvlCla7HMUlLreziIFmZleTjvp1LgzQbHS6EA2JArMY518yM8EsZHxLPIA6+A9rXvxyg==
X-Received: by 2002:a05:600c:8487:b0:43d:683:8caa with SMTP id 5b1f17b1804b1-44b6d6b6939mr25527865e9.15.1747984791075;
        Fri, 23 May 2025 00:19:51 -0700 (PDT)
Date: Fri, 23 May 2025 09:19:49 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Jan Beulich , xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/4] x86/boot: print CPU and APIC ID in bring up
 failure
Message-ID: 
References: <20250522075440.99882-1-roger.pau@citrix.com>
 <20250522075440.99882-2-roger.pau@citrix.com>
 <0028ad37-95e7-4b6e-87b6-07cadcac64aa@suse.com>
 <8c1156a8-a626-4b62-9cc1-7790184b2b9b@citrix.com>
 
 <71b4666e-0efa-4020-83bb-ecaa9ede7ca9@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <71b4666e-0efa-4020-83bb-ecaa9ede7ca9@citrix.com>

On Thu, May 22, 2025 at 06:22:19PM +0100, Andrew Cooper wrote:
> On 22/05/2025 5:50 pm, Roger Pau Monné wrote:
> > On Thu, May 22, 2025 at 03:39:57PM +0100, Andrew Cooper wrote:
> >> On 22/05/2025 10:10 am, Jan Beulich wrote:
> >>> On 22.05.2025 09:54, Roger Pau Monne wrote:
> >>>> Print the CPU and APIC ID that fails to respond to the init sequence, or
> >>>> that didn't manage to reach the "callin" state.  Expand a bit the printed
> >>>> error messages.  Otherwise the "Not responding." message is not easy to
> >>>> understand by users.
> >>>>
> >>>> Reported-by: Andrew Cooper 
> >>>> Signed-off-by: Roger Pau Monné 
> >>>> ---
> >>>> Changes since v1:
> >>>>  - Also print APIC ID.
> >>>> ---
> >>>>  xen/arch/x86/smpboot.c | 6 ++++--
> >>>>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> >>>> index 0189d6c332a4..dbc2f2f1d411 100644
> >>>> --- a/xen/arch/x86/smpboot.c
> >>>> +++ b/xen/arch/x86/smpboot.c
> >>>> @@ -618,10 +618,12 @@ static int do_boot_cpu(int apicid, int cpu)
> >>>>              smp_mb();
> >>>>              if ( bootsym(trampoline_cpu_started) == 0xA5 )
> >>>>                  /* trampoline started but...? */
> >>>> -                printk("Stuck ??\n");
> >>>> +                printk("CPU%u/APICID%u: Didn't finish startup sequence\n",
> >>>> +                       cpu, apicid);
> >>>>              else
> >>>>                  /* trampoline code not run */
> >>>> -                printk("Not responding.\n");
> >>>> +                printk("CPU%u/APICID%u: Not responding to startup\n",
> >>>> +                       cpu, apicid);
> >>>>          }
> >>>>      }
> >>>>  
> >>> Elsewhere I think we print AIC IDs in hex; may be better to do so here, too.
> >>> That may then want some text re-arrangement though, e.g.
> >>>
> >>> "CPU%u: APICID %#x not responding to startup\n"
> >>>
> >>> Thoughts?
> >> Definitely hex.  Elsewhere APIC_ID always has an underscore.
> > Maybe I'm confused, but I don't think Xen uses an underscore, it's
> > always 'APIC ID' when printed.  I don't mind adding it here, I assume
> > what you mean with elsewhere is other projects like Linux?
> 
> It's apic_id in plenty of smpboot.c, but fine - lets do it with a space.
> 
> We do need to reduce from $N ways of rendering this down to 1.

Oh, so it's lowercase with underscore.  Anyway, will use uppercase and
space as agreed.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 23 07:20:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 07:20:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995311.1377798 (Exim 4.92)
	(envelope-from )
	id 1uIMhx-0002Fh-1Y; Fri, 23 May 2025 07:20:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995311.1377798; Fri, 23 May 2025 07:20: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 1uIMhw-0002FD-T3; Fri, 23 May 2025 07:20:44 +0000
Received: by outflank-mailman (input) for mailman id 995311;
 Fri, 23 May 2025 07:20:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMhv-0000jR-6G
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 07:20:43 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6f517023-37a6-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 09:20:42 +0200 (CEST)
Received: from nico.tail79467d.ts.net (unknown [46.228.253.214])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPSA id 2BDED4EE8F7B;
 Fri, 23 May 2025 09:20: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" 
X-Inumbo-ID: 6f517023-37a6-11f0-a2fb-13f23c93f187
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=46.228.253.214
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1747984841;
	b=i/sOJpfDGh7JbbQoE74t8J9ZiD5r29g6xwihvWFPFr6MbHETFsRP8qTg4Dyw5EaUXYGq
	 amstJF30T5FNysfRquw9aLicRo4hm2/BSMWyZ5S+4x5BbhByyFVLo1VjBFSnWwhB3vMsp
	 Pgyr4xfQcpi0Bpt8ojLOXChyFB7OD6i8CAzRVNWdOar5bRsWtynSa7ex3Cks1i+5DW31E
	 xfMTVyjhyWLBCZaDjxZnsXFEJheUd6Prne4fkYRzfdjBN08kpTN/CCPgDRWEIjzlGyb4H
	 Bz77YvK+dJ6lINaaqp0PBRJpCtJT5qI5N/cfvjUjlLWcy6IdGwhiBTsmVTDyu0AAZEINp
	 CVyn/JwEDt6kK3TJs8Lrv2QYyO94wQZzh4GzvR4hMmuMDiCrVO1EFRdgtQe1k3HTe9/g2
	 jvVALq1LpTgjaddDx9GOHUkSbz3fSSE7C7ksstN9198dturS4WLMyKDHERbVQiKIJJvnu
	 P1kHSWhKGay0HvGPi9uNS68t+lPArNjv5d+IpL9tEpyMlezRg61Iu5OAi5mt6x26aePag
	 mSvwPBjQlUjjRho2Zupb94sEJx+0EvQGG+ylUAxRHQvt9iV+UNSyBqvzPmi8aUeJBzXdO
	 RHx0QgfV/Kbg8sR8m1II6A9xgxCUKZVQRF3EowfxnoHrJbXPtlzgZBZuqKCSjW0=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1747984841;
	h=DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer:
	 MIME-Version:Content-Transfer-Encoding;
	bh=YPZz2jEAMMC36xD6hgsUyWuFj29BV8c7vMGDII9rtok=;
	b=4zaQy2JYxqeUuZ85eHei8qSQD+2CzNSAHbpQzgi9z//kbnMlPMPIh/NKnfsW8QO7ks0R
	 QHarQaskrY4WW4HihvxsteeAHOQq7/HVJ8NBqoIGeIGk01b4V/aavPnd0hZToxC+rX6Nk
	 +r9M2kcvpg15jSTmiFjYN4TVhrJlgE80BgCnXgq6WxjeBFwzAExj8nawWCHQYDn1W+D0m
	 ecwSwP5MWE9S0xFUWK52z38E7pjvTdT6lBuo9KmxZHQgj1SHrcs+YQS+fNE+tRiCF/Skv
	 wG+qmHmFpIxJskYq4uwunYA156WaSvIr1vEeLG9RO9zi029ZYoeFc0tCSDNU3Ab5YtlSi
	 VuE1GdBFHxntRP/JIhjSDaJM2YmPOcvzm5abDbHO6VCyPSShnsyqOHh4thD3cGfshNTeM
	 FFr/koqqwfA5WWqgsk78RgQEC8sIPCoh00iSH3aj8qirgk/HIKP4zvX3B9Zyz7lInKQ2/
	 pDQtbDo3LTLC4IY5Oj5jsORhn7ySvvsAOg6eZN8AfoJeUVXFENxPZqcMJAyYgejnrEBdu
	 lBeDWZ/E6a/A+lcZZgBagXTkaRVaRyVGFFhstXEIJgFkZKHZXQQ0Guc9ULnD6qX5NXRnd
	 pVpLVBf/YYNeLx7pEFV3x5Mrm7//THBl5Nyq/8YPwqbdZ1NdDDkZ+CUspCJ7PN4=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=46.228.253.214
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1747984841; bh=76iPtDtJiqJQwHtwd12Grf/gpmigtPd82qm3J8cUx08=;
	h=From:To:Cc:Subject:Date:From;
	b=XtuGPOYm/VFcNoXC6HMoT8WkdbMWi291e3D49h+Yi6F8ASDyCj6yjluzNt3dW04yO
	 3IUvcIQGw0rrke/D1W6Cln/s33cEQrIoeRcLWDbRD1jtXnwVFQUeA3xgrcz4Vft2UK
	 EBDy/zBoApVrhp9UuoFw0B3ujwcBpZVL5yzgIZw5EZTt+AmjmLtALkZyvYkfMoQTSJ
	 xbAMfp8JLACetaZn+BeGwHNY07k6EvBehAzTClOK84fW+8/+hk6YG/FVgvuyj8mmw/
	 wMfZwqKn38EjjdoQyVBKJqvcKc+4cTL3CsBIBStSnr9uV/RLiqyLwacHusZ6K1QcX2
	 WJ9L1w3Tm14Fw==
From: Nicola Vetrini 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Nicola Vetrini ,
	Doug Goldstein ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH] eclair: allow and document use of GCC extension for label addresses
Date: Fri, 23 May 2025 09:20:35 +0200
Message-ID: 
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

No functional change.

Signed-off-by: Nicola Vetrini 
---
This fixes the CI error for R1.1 on this patch that stems from using the label inside asm goto:
https://lore.kernel.org/xen-devel/20250521143658.312514-1-andrew.cooper3@citrix.com/
---
 automation/eclair_analysis/ECLAIR/toolchain.ecl | 5 +++++
 docs/misra/C-language-toolchain.rst             | 4 ++++
 2 files changed, 9 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl b/automation/eclair_analysis/ECLAIR/toolchain.ecl
index 8ebf9f132cf2..842f8377e561 100644
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -108,6 +108,11 @@ volatile"
 -config=STD.funojptr,behavior+={c99,GCC_X86_64,specified}
 -doc_end
 
+-doc_begin="See section \"6.3 Labels as Values\" of "GCC_MANUAL"."
+-config=STD.adrslabl,behavior={c99,GCC_ARM64,specified}
+-config=STD.adrslabl,behavior={c99,GCC_X86_64,specified}
+-doc_end
+
 -doc_begin="
     ext_c_missing_varargs_arg: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
     ext_enum_value_not_int: non-documented GCC extension.
diff --git a/docs/misra/C-language-toolchain.rst b/docs/misra/C-language-toolchain.rst
index 3a1ce651d7fd..cb81f5c09872 100644
--- a/docs/misra/C-language-toolchain.rst
+++ b/docs/misra/C-language-toolchain.rst
@@ -214,6 +214,10 @@ The table columns are as follows:
      - All architectures
      - See Section "4.5 Integers" of GCC_MANUAL.
 
+   * - Taking the address of a label
+     - All architectures
+     - See Section "6.3 Labels as Values" of GCC_MANUAL.
+
 Translation Limits
 __________________
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 23 08:08:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 08:08:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995326.1377808 (Exim 4.92)
	(envelope-from )
	id 1uINSA-0000ON-GW; Fri, 23 May 2025 08:08:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995326.1377808; Fri, 23 May 2025 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 1uINSA-0000OG-Dy; Fri, 23 May 2025 08:08:30 +0000
Received: by outflank-mailman (input) for mailman id 995326;
 Fri, 23 May 2025 07:23:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIMki-00034r-03
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 07:23:36 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20611.outbound.protection.outlook.com
 [2a01:111:f403:2408::611])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d56d087b-37a6-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 09:23:34 +0200 (CEST)
Received: from BN7PR06CA0069.namprd06.prod.outlook.com (2603:10b6:408:34::46)
 by IA1PR12MB6532.namprd12.prod.outlook.com (2603:10b6:208:3a3::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Fri, 23 May
 2025 07:23:29 +0000
Received: from BN1PEPF0000468B.namprd05.prod.outlook.com
 (2603:10b6:408:34:cafe::db) by BN7PR06CA0069.outlook.office365.com
 (2603:10b6:408:34::46) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Fri,
 23 May 2025 07:23:29 +0000
Received: from SATLEXMB04.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_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 23 May 2025 07:23:29 +0000
Received: from [10.252.206.76] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 23 May
 2025 02:23:22 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d56d087b-37a6-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZgplzmR2ZWgceVGpqNh64nahYk2AIcXIKmZ6+qNqxQEBYbzDpXf5SzZ1+rG/4y0z/LmT9cKmBOfSV6dMMy3XHkfuXjcfqykKAClhP2QPI8gWfe+PLWplz9njJSj2Ccr+2rTIwpy8M0YfcStzXb1tZHQJWXEI2zfcMuLIHwl6UrWPyn2JTgn0Ow6Ku85svZ6TZx74NmMiBryTmwew6ZqTWYuilGVz/vsi7Trthy9hCwNpL3eL9xQ8toyFE6drqHTeEdMa0s8TwqF/i+QpTPWgYXzwBhSJ3aw8zjN0GAZRjhYJtQlGPVqbQdmjEtcBgJZe1a0hzPDGWFCFsJ9B6PxntQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jJudB0MHTWMo1Cv70g5UMQe8b9A5acgzYPfE7bqls9E=;
 b=jaGO6e+2ZRPlM4L7SP8RzOdmCG8r050In+1YjvYPosQBdHpeE4ABP4E0vlJpiUgphuFxPw+Msq9aF0O2EbqdfDTkdwaZqpjapubS4q2QzFIDYZeRBmfuWEoyBk0JtIO8Dv4qExkiv28UTyae7lpboHkySg7m8YoU1wUNh0gr342xMyAKEnMb3ARtIwhjfRGhNafVLTWgyfioHWPOwm2C44neGVOscL+WHMXcprCLjHbfLA8VtsaZsBC+GrUGPL2vnldsrgHXkEmdO1TYciG4w94H9CKlbHGsTYkRa9iKpmvjfAsPw2vgPy2L7839LdiQ5SQWKL2x3c91CdrF3iw/1A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=google.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=jJudB0MHTWMo1Cv70g5UMQe8b9A5acgzYPfE7bqls9E=;
 b=rVHzZIAyTBwPCfK66Hbe9XMeJK7HDjV25lrtlra8+ygkxUZlXQCWYMeUT/Y0JNoQOWFX56PVSE1QzIs5jox/VaO3umf5IdVJ2zS54pDFULFix5sEYqakwvJlNKeJAC/kVj3tcbn/cMN0Dshmi3+Zfdrko85Tv402l281375eoZs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <2c52daad-0b64-48a9-8e73-d1aba977993b@amd.com>
Date: Fri, 23 May 2025 12:53:19 +0530
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 13/13] KVM: selftests: Add a KVM_IRQFD test to verify
 uniqueness requirements
To: Sean Christopherson , "K. Y. Srinivasan"
	, Haiyang Zhang , Wei Liu
	, Dexuan Cui , Juergen Gross
	, Stefano Stabellini , Paolo Bonzini
	, Ingo Molnar , Peter Zijlstra
	, Juri Lelli , Vincent Guittot
	, Shuah Khan , Marc Zyngier
	, Oliver Upton 
CC: , ,
	, ,
	, ,
	, K Prateek Nayak , "David
 Matlack" 
References: <20250522235223.3178519-1-seanjc@google.com>
 <20250522235223.3178519-14-seanjc@google.com>
Content-Language: en-US
From: Sairaj Kodilkar 
In-Reply-To: <20250522235223.3178519-14-seanjc@google.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF0000468B:EE_|IA1PR12MB6532:EE_
X-MS-Office365-Filtering-Correlation-Id: 09cdb81f-cf79-4bc0-f097-08dd99cab76c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024|7416014|921020;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SVZLVE8xang3VndRdm9OanJ6a2pUS1QwMUVHVFJwTkhjRWhDWnlzMWVJVnlI?=
 =?utf-8?B?WXBHSklxbzEweFlvY3plNkMySFV2N3E5K25kbENoRnRkRXkrVmF6RHF1ODNU?=
 =?utf-8?B?S1pOMnVhOElpNkQ5dFFra011aEFtUTE0dmJIa1piNEE0NmdDeUZEejdrZjA3?=
 =?utf-8?B?U05YZFdRaXE1TEtBN3EyZEJVWUdEOUMzOVoyRGdpaUlTdGF2YXhTUU9KUTl3?=
 =?utf-8?B?cVlxaXpkajVxVlBLb0tTZGNaeS9qWlNFcXlPbnRUUUtLUVF4SFI4N0pIR0sz?=
 =?utf-8?B?Wlp2MHhBRG5RaVNzVmhKeDhEV3Z5M0FPNjkwZk5ZN210M2ljMlhNMWxDWldr?=
 =?utf-8?B?T3psVy9rNUcraEtlK1N6dUozUjR4a3ZCcU5OTFpCZk5GT3MrL3d6aUZwNHpH?=
 =?utf-8?B?eEswZXFvTk0ySVd6dWlPZ0ZwNmIyaUh0QTBFaTM4Q0dZU0hFNmtIMmc2clJ0?=
 =?utf-8?B?bEREZUI1N1EyS3JzTkRnWDVQOUQ0aE93OENsbHliaUloN0cwSUVPTTc2OGpF?=
 =?utf-8?B?WUdMcmtHTGtiK05DYklaZ3JGcWtmTzFBMnhSdDhKTEhscHBvQ3JVWncxb0li?=
 =?utf-8?B?c2dZRGJ5M1g0Ym85TXhzVTlJREhaWldvR3ZraElmYnpTSkxzRDhJZ2t2amZ1?=
 =?utf-8?B?bS9DcEE3YWtBcTBMem1UNUpFeDNuYml4WjJRdGlTSDk1dlVDdllvZkxyd0dM?=
 =?utf-8?B?RWNEWkc0UTJWZ0tQa01aUlV3dUt2cDNxMVZZREN1WFVhdTV2VmlEUjA3c3J1?=
 =?utf-8?B?M2xxWFFNVGE4K00xQXRaUUhQSkpXK1FzQm5nVGY0aHdZcUIydFlBa1R1ZlJM?=
 =?utf-8?B?UGlPbWlnR2M5WEtPOFpZeXc0Z0tPYzJxTEF4bUtYWEhaN2JWV25ocks3SERH?=
 =?utf-8?B?cStsTlRSSnpoYkxRRnQzcHdwa1Z3amhyV3N3dGhweWlVQ1ByUjFVTUkxYjRQ?=
 =?utf-8?B?eEx0UW9PYW9VTFcva2JLcXk2dnJRd0tCb0djVHVhTHpJdkp3cVE2N1RoUnQv?=
 =?utf-8?B?dFFDTy9wUHYrZ1Z6RW9hdGMwbE9XZFhmTUZtQUNTOVF5TWJwTm9LQmVwUk1Y?=
 =?utf-8?B?ZWV6UWdlMGtkWFdSSUMrb2FYYWJlZDV3TUxnWkhuR21DU1MyMGJldEJ3K0I5?=
 =?utf-8?B?VS95WVVudjcxUi96NFhCR0FDQ3Z2bGswUEd4SWhGcGM2Z1BWK24rend6ODBk?=
 =?utf-8?B?MkM1YlVIdzk5Um5KaTM4QVFsMkZEVUk4d0ZTWUNsY1pDVzlVTDNLSmJIZ0FD?=
 =?utf-8?B?dUI0alN1aU5ieTUrTGFlL0FIUXJ1VFZXc1hkYkZNOTJYWHRMdk1vZ0FpajVs?=
 =?utf-8?B?L1dZU2JvZW1CNUVkaS8yWUhTWmVVNHNRVVpnbkt3bC9hb3NYbUNmQWovZU91?=
 =?utf-8?B?V0k3bERlRksxcHcyU3d6ZklqTjUyWWFXOTAxOW5DMTBOU2NGNkxUa2prTFhN?=
 =?utf-8?B?blFHbWNyOHVKVHZqczlQdTFaWUNxQ3BVUFAzazlreUJOeGlCN0xacTIzY3dD?=
 =?utf-8?B?NDlydEZuZjhMajltRkx4dnNqb1RZbVJkRlAxMFJHN0hEWTlXYlJ1RmhWVmlW?=
 =?utf-8?B?d0ZOaEJXbVFHM3hjYmJOdVZUaWQvN1ovN2N1M2RUanNBQWc3c0ViYTBza3FH?=
 =?utf-8?B?WDNrZHNPbytRSmRDaGNuNVFOQzdJdDJMWm9lM0xiRS9oZXEreU5FRHZiWjl4?=
 =?utf-8?B?TmRQQXJkZkl3NkswTlNmVHA3cXFsdVNyazc0VzdVZ0Z3Y1ZDMFU0NjZHdG1D?=
 =?utf-8?B?YTZJTzJxa1dFaDB1UkJtNk1LTkxqZnJDWFdhZ1hHakYrMkN2UnlnQlNvaDVt?=
 =?utf-8?B?cmxwMUljdlYvbk55S3NmaWlDUW9ac3lBMkM0ZEZqWEJPUmJyTXkwRGUwMlZG?=
 =?utf-8?B?aTI1RFVOUUlETmI5eEt4QW1ieHFNcGI1cEx6czZ6TVpNUWMraFJqdDNvL0tp?=
 =?utf-8?B?emJHSDZYb0ZxR2NtSXNCbXNBZVhLR0RzaXJNa3UreEcxSWJwMENqamQrY243?=
 =?utf-8?B?Mi9VdVR6SjhRUnI2cmRsMU9MRXRreGJGaFAzRFljL2xITktoUXQrcVNqWXZ1?=
 =?utf-8?B?NUppWWpxWVRPdXRQcWxJY2YyRUt1cytBVEpjZz09?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024)(7416014)(921020);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2025 07:23:29.5870
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 09cdb81f-cf79-4bc0-f097-08dd99cab76c
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=[SATLEXMB04.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: IA1PR12MB6532

On 5/23/2025 5:22 AM, Sean Christopherson wrote:

> +
> +int main(int argc, char *argv[])
> +{
> +	pthread_t racing_thread;
> +	int r, i;
> +
> +	/* Create "full" VMs, as KVM_IRQFD requires an in-kernel IRQ chip. */
> +	vm1 = vm_create(1);
> +	vm2 = vm_create(1);
> +
> +	WRITE_ONCE(__eventfd, kvm_new_eventfd());
> +
> +	kvm_irqfd(vm1, 10, __eventfd, 0);
> +
> +	r = __kvm_irqfd(vm1, 11, __eventfd, 0);
> +	TEST_ASSERT(r && errno == EBUSY,
> +		    "Wanted EBUSY, r = %d, errno = %d", r, errno);
> +
> +	r = __kvm_irqfd(vm2, 12, __eventfd, 0);
> +	TEST_ASSERT(r && errno == EBUSY,
> +		    "Wanted EBUSY, r = %d, errno = %d", r, errno);
> +
> +	kvm_irqfd(vm1, 11, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
> +	kvm_irqfd(vm1, 12, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
> +	kvm_irqfd(vm1, 13, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
> +	kvm_irqfd(vm1, 14, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);

Hi Sean,
I dont see any allocation for the GSI 13 and 14..
Is there any reason for the deassigning these two GSIs ?

Regards
Sairaj Kodilkar

> +	kvm_irqfd(vm1, 10, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
> +
> +	close(__eventfd);
> +
> +	pthread_create(&racing_thread, NULL, secondary_irqfd_juggler, vm2);
> +
> +	for (i = 0; i < 10000; i++) {
> +		WRITE_ONCE(__eventfd, kvm_new_eventfd());
> +
> +		juggle_eventfd_primary(vm1, __eventfd);
> +		juggle_eventfd_primary(vm2, __eventfd);
> +		close(__eventfd);
> +	}
> +
> +	WRITE_ONCE(done, true);
> +	pthread_join(racing_thread, NULL);
> +}



From xen-devel-bounces@lists.xenproject.org Fri May 23 08:22:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 08:22:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995382.1377855 (Exim 4.92)
	(envelope-from )
	id 1uINfi-0003u3-Gg; Fri, 23 May 2025 08:22:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995382.1377855; Fri, 23 May 2025 08: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 1uINfi-0003tq-DC; Fri, 23 May 2025 08:22:30 +0000
Received: by outflank-mailman (input) for mailman id 995382;
 Fri, 23 May 2025 08:22:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uINfg-0003rz-MR
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 08:22:28 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0d846f84-37af-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 10:22:23 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a366843fa6so4070795f8f.1
 for ; Fri, 23 May 2025 01:22:23 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f1825457sm137419755e9.1.2025.05.23.01.22.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 23 May 2025 01:22: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" 
X-Inumbo-ID: 0d846f84-37af-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747988543; x=1748593343; 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;
        bh=GB5SoZGsyV9907UeSThTMXgLvSHWtuKbvETz0zUwdfc=;
        b=A14LvtI7DpPJJ60x2Ko40ABXp1hR0AVwigsqyAFNQh0u8iwam6En6EJMfiP9rraYXO
         5x4SKfX10CdJhZNGrQjpcPYt4NtcdQkLtP2WWfMomrpeA3QXzEwKkCZeB4F1tx+saHQC
         PVC9Mp52p6RausvSEPvjIBORjiGupRE744HHM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747988543; x=1748593343;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GB5SoZGsyV9907UeSThTMXgLvSHWtuKbvETz0zUwdfc=;
        b=jZYtxJ0zZoPLTY1+CJdi3WGCdbN+KnsM/8TFA8ecxLNR7lAwYXoYRGVwu+KLT7/Wkg
         cCQ3cy+EHuLYN/8kfvgJE0Hwh/vuxH83Si1/VXzN7BzNHyV49AghW5X2fqH3CbqQdICY
         Zfr3JMrfBLopd08zjfHf7ynS7XBpK31PR6fMKYSfZnU/DBmsm5uUS35KtXTHY4LcJhZV
         gXzWvmlvHwMj95jZzZHwZWCeGJsRU+ysmvmx0NHJECa5jtx5Q1RzTICS8akefWStBQaa
         69DYv8x714IzsIj78pGWSjhStWdEH2qGyJofxw/ZyBQYPLBMue/3BwGqGa3o+vbBZ5Nn
         HBjA==
X-Gm-Message-State: AOJu0Yx2yyZZRzFoQvUARXk8T0w+jVOfRmDbK6LbD+pn1IqrYJwA+3cc
	w3gLVKkBcqg9w5R5RlBkeHdN+ny/+cf2/pjfVI+4DPsv1K0XOX5zglC1cihWWkDbub+w8k4k463
	Itkxu
X-Gm-Gg: ASbGnctnrDxkUh/cFqW+VrxsRJRTj51FEl05M6pUfXXj1Wv7ygBMYpBg+mB/YovhYFW
	wGvqDt2Z93kGJhevhqWs0HX3R3Zv7CBWpDFqL9eushh62+0a+vZV5jlbL2frhb/b/j1IXOJvBmm
	N9Q5Jexbvcpnih+tFI5MkfwHv1gsSqCvCMasarne9HCaY//dHOqjwiw0hFMV478NSlAoDMOKq/+
	cBDRXYbtbaWPqU7ouNF3j5Lz8kxtXAFGXlNA4VbhPVqKrakHCzZS/FHoeODNc9z9LZDrJd44QRV
	wUyGLusAPH1Hn7OwtC8LSqBpt4zUffUTgAQWAnjmNx+cJdNOeNAk5fLDrS/Agz5dE05QW5ycvFF
	smiF3kt6vM6dV7uvomD1xftljg2gV6A==
X-Google-Smtp-Source: AGHT+IHZldEWad0nbpScWJrwcpZvfgjnSRtHv53NQ5qCJ1OYi5pr2d/nl8GnYpFZRAEmYzDiB3J/lQ==
X-Received: by 2002:a5d:5f46:0:b0:3a0:b816:5a44 with SMTP id ffacd0b85a97d-3a35fe964dcmr25515836f8f.35.1747988542734;
        Fri, 23 May 2025 01:22:22 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v3 1/3] x86/boot: print CPU and APIC ID in bring up failure
Date: Fri, 23 May 2025 10:21:33 +0200
Message-ID: <20250523082135.18088-2-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250523082135.18088-1-roger.pau@citrix.com>
References: <20250523082135.18088-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Print the CPU and APIC ID that fails to respond to the init sequence, or
that didn't manage to reach the "callin" state.  Expand a bit the printed
error messages.  Otherwise the "Not responding." message is not easy to
understand by users.

Reported-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Changes since v2:
 - Adjust format string.

Changes since v1:
 - Also print APIC ID.
---
 xen/arch/x86/smpboot.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 0189d6c332a4..b5dcc77bd574 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -618,10 +618,12 @@ static int do_boot_cpu(int apicid, int cpu)
             smp_mb();
             if ( bootsym(trampoline_cpu_started) == 0xA5 )
                 /* trampoline started but...? */
-                printk("Stuck ??\n");
+                printk("APIC ID %#x (CPU%u) didn't finish start sequence\n",
+                       apicid, cpu);
             else
                 /* trampoline code not run */
-                printk("Not responding.\n");
+                printk("APIC ID %#x (CPU%u) didn't respond to SIPI\n",
+                       apicid, cpu);
         }
     }
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 23 08:22:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 08:22:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995381.1377845 (Exim 4.92)
	(envelope-from )
	id 1uINff-0003dp-5A; Fri, 23 May 2025 08:22:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995381.1377845; Fri, 23 May 2025 08:22: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 1uINff-0003dg-1z; Fri, 23 May 2025 08:22:27 +0000
Received: by outflank-mailman (input) for mailman id 995381;
 Fri, 23 May 2025 08:22:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uINfe-0003CJ-78
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 08:22:26 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0eda90b5-37af-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 10:22:25 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-442ea341570so62115555e9.1
 for ; Fri, 23 May 2025 01:22:25 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a35ca8896dsm25534645f8f.73.2025.05.23.01.22.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 23 May 2025 01:22: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" 
X-Inumbo-ID: 0eda90b5-37af-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747988545; x=1748593345; 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;
        bh=fraFe1zTdvy9EaNNK6KT5rkWZR7WnEeg3OgF6ED/J8A=;
        b=tAlPw8zE58fW71aIXqxN9JWSUeKDQs5p92lgHf2NjeRY8myT519JDlujT8uxYLy1Mu
         G/uevgehutcJLYVdM0g6vXZnIwEwOBeFTPtZuOmyqaIagIbErUxWfMJAxaF9BsweS+sP
         uSmxmqgthSLpcL5+Ktn4fpJo2IboLCVYQ88Jc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747988545; x=1748593345;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fraFe1zTdvy9EaNNK6KT5rkWZR7WnEeg3OgF6ED/J8A=;
        b=A/u1jPmN8EiTP8PonTBnFj0AEldB52u7DLPciCvhFLoockALwq2Ozb7/I5LNZ1M1Lo
         lmlOz+uVXywj7v8U+aiXfhibb+51q8bld2s/37LthAYwHEm4POhXztyyteyf1Yq50FFV
         TP7NUYFd/qF5FmBu61IAxW1idcLOQh+97M3dzy23t+AQiZDeP0N6/afZSe3BEuGwz257
         buQqgYF8SSKzP+yiVXtmqPc3F8YdWeYhdmYWsezx0JUMRzbzw3hGzkt1dcLZ0d3LrF61
         tX/5r9H+MibekP0vdvl1JkAQ+NFBjY6gP/d8IkAORmMMt7qqAFR/TKSnCDtZSwv+voAi
         T9dQ==
X-Gm-Message-State: AOJu0Yw3pjXjHMrEyRqTau5EWoYlI9ADJGNkX8nTKg1pDNMFokPZIY/r
	71ekxD/X4+Ug0ZiP9PaW1WPVJghvjzjFexUx5t8VvDmj4VARa3RewHOY5Ea/lPJG7epRSOJzBgl
	d26Oj
X-Gm-Gg: ASbGnctkBDB1YUKKdYJmUVQ4NuBY6MaChxgGH3Az4uCHrBb2rhk3jQitI/9/J5/hceV
	VQ1x8Xb5wybAikKIez/iQvs7TpAm7VGbLbmcp5qIbmIUDeRpOwTW3PD7HtQS/BLaVQ9N6I/ru91
	vogypB7qX9ZjJQ05ewYHv6n3r6OM+MMNR2tLOxHjYvu/8hxEmz/IJmXRSLg+JeBCayZt5FsLtJt
	Gim61bF9UGL51zprWU2R3qrrz5ni/QYvrsXV4veTcZ6WO5okUalZLwzz+dhpd9Kh1QpqRQPR0xd
	sCJVwjxsIYGURvaBjZin89MXCHg3Im3+Wou80luo4gLeKCtN5Kgg516hTNlHFyJycSgdc+7InU0
	FCEbBRsSJt5a3G1TWx40=
X-Google-Smtp-Source: AGHT+IH8WDpyb6K81BVOvpUEla557CAOvPbAlfr6x81iASyAMoDVtSY94hnMYALKX46FZeaLB0zJcA==
X-Received: by 2002:a05:6000:2501:b0:3a3:6d1e:a517 with SMTP id ffacd0b85a97d-3a36d1ea854mr18226804f8f.31.1747988544941;
        Fri, 23 May 2025 01:22:24 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v3 3/3] x86/boot: attempt to print trace and panic on AP bring up stall
Date: Fri, 23 May 2025 10:21:35 +0200
Message-ID: <20250523082135.18088-4-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250523082135.18088-1-roger.pau@citrix.com>
References: <20250523082135.18088-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With the current AP bring up code, Xen can get stuck indefinitely if an AP
freezes during boot after the 'callin' step.  Introduce a 5s timeout while
waiting for APs to finish startup.

On failure of an AP to complete startup, send an NMI to trigger the
printing of a stack backtrace on the stuck AP and panic on the BSP.

This patch was done while investigating the issue caused by Intel erratum
ICX143.  It wasn't helpful in that case, but it's still and improvement
when debugging AP bring up related issues.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
---
Changes since v2:
 - Adjust panic message to match the similar ones printed for AP start
   failures.

Changes since v1:
 - Use 5s timeout.
 - Print APICID.
 - Split NMI dispatch code movement to a pre-patch.
 - Reorder timeout check condition.
---
 xen/arch/x86/smpboot.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index b5dcc77bd574..ac7bfca8b5c8 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1372,6 +1372,7 @@ int cpu_add(uint32_t apic_id, uint32_t acpi_id, uint32_t pxm)
 int __cpu_up(unsigned int cpu)
 {
     int apicid, ret;
+    s_time_t start;
 
     if ( (apicid = x86_cpu_to_apicid[cpu]) == BAD_APICID )
         return -ENODEV;
@@ -1390,10 +1391,18 @@ int __cpu_up(unsigned int cpu)
     time_latch_stamps();
 
     set_cpu_state(CPU_STATE_ONLINE);
+    start = NOW();
     while ( !cpu_online(cpu) )
     {
         cpu_relax();
         process_pending_softirqs();
+        if ( (NOW() - start) > SECONDS(5) )
+        {
+            /* AP is stuck, send NMI and panic. */
+            show_execution_state_nmi(cpumask_of(cpu), true);
+            panic("APIC ID %#x (CPU%u) stuck while starting up\n",
+                  apicid, cpu);
+        }
     }
 
     return 0;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 23 08:22:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 08:22:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995379.1377825 (Exim 4.92)
	(envelope-from )
	id 1uINfd-0003Cb-M7; Fri, 23 May 2025 08:22:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995379.1377825; Fri, 23 May 2025 08:22: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 1uINfd-0003CU-Ii; Fri, 23 May 2025 08:22:25 +0000
Received: by outflank-mailman (input) for mailman id 995379;
 Fri, 23 May 2025 08:22:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uINfb-0003CJ-Oy
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 08:22:23 +0000
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [2a00:1450:4864:20::42b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0ce9a0ff-37af-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 10:22:22 +0200 (CEST)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a375888197so2971379f8f.0
 for ; Fri, 23 May 2025 01:22:22 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a360b0b766sm25503071f8f.56.2025.05.23.01.22.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 23 May 2025 01:22:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0ce9a0ff-37af-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747988542; x=1748593342; 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;
        bh=xgZEePaEwVB0+m6G/JqFr58XnjU0IvSkKGo6kRFhqJU=;
        b=i1OmdZ3schu0Brufn3lydtYtN3t53BT9EFK1xNsGNJJ4NiW651V1VNSOThnTSi7x0G
         +aVD/gGbye/lm7BPgkP7en59OEyeGrCfFEpzNwlYZI+58+ql6LWLVz4WbQ15AJ2lveB/
         yqXWAEZYyjbglb8n6RXA13rF1a25HYmP2j4xE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747988542; x=1748593342;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=xgZEePaEwVB0+m6G/JqFr58XnjU0IvSkKGo6kRFhqJU=;
        b=llBVqCKoXBqP2n8Y5NFkNSbl5+fd/wfpw1JFtsLf7p4EUIF1ZySBhq1Ti1VlEWZTqP
         t/I7DgELsWlALBzboRcho5ygVQsPcS8oQgqJH9cu/My97DrDef7/WmxWl5GDRZ++SWBO
         rbnbeMmgHW4JzTxaTZ/AURsIk6uSow4K7y3KAtfTwoFp2BHQ4NFNpMrc1nQlpRgDXx3+
         NEs1NG32r1XXh/QW5bpQtHuSa/9OaPsqgtjSt6qYW74R/ELzOQsYpT1KGTqHkCUqCSMf
         WXhTB0YI/20P13g+C8iIQqc9hnnDpVt7YrkJT69K+oMI2iIIsuQUXH8v8vfLNwv5L3XT
         /1UQ==
X-Gm-Message-State: AOJu0YxnLyqrQvD8OaZAAgRGjOf3016stMm8/KS8cP2voRdxIttfGeQ4
	HKi2twW9/ysSj2bpinbAFZaGwO9mXCyn8mH9Xxb8QxJHe44WWxNYsj9Bh6w1ORHDPqq7KVa5cMw
	IpapZ
X-Gm-Gg: ASbGncsImS3RB/Fi5f9y0r4fnnaHp2LuTzFzgsemhK78nYiSCBmiJi7VumkQacRcs6Q
	9tDt8c1avhWhoqmKC7w2DxSpApxbltg/4Q5aAwR6GuMIq9b3xuSpyCleEMLqH+RM7jhyhUDOqlX
	qkWw7B3LxtFD8n9KVbI1V6g5txZnXTxJdPXPaENDAghgQMS7pUrdlKKFS3RyKHEQVE4pWQwWI6E
	rckW6YHLUGegB65DrqOZ6sLc6hpYbbCMxYcqK/KiTpgMSfrtWSUx9NN0/KowkszfxNKts0nBTzM
	rH+0kiEtNIs81xXK/gqqnLBm2SE3pvTG1qmJMzCcdsgoXEmSC9YHJNfHogHkCZUFRV/EjrBjyXZ
	cpy4lln7qiQEbDf1N8Ww=
X-Google-Smtp-Source: AGHT+IHwEpcM/WpnbnTHNgQ0C57KGN3yGk3JTYSr2dSsvpgBIgQfRMWN/ifbBebgdtO+nHBgHs9l7w==
X-Received: by 2002:a5d:4884:0:b0:3a4:c535:47c7 with SMTP id ffacd0b85a97d-3a4c535490emr426127f8f.28.1747988541716;
        Fri, 23 May 2025 01:22:21 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v3 0/3] x86/boot: provide better diagnostics in AP boot failure
Date: Fri, 23 May 2025 10:21:32 +0200
Message-ID: <20250523082135.18088-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

This series attempts to improve AP boot failure diagnosis by improving
the printed failure messages (patch 1) and detecting AP getting stuck
during bringup (patch 3).  Patch 2 is preparatory changes for the work
done in patch 3.

They should be non-functional changes for systems working correctly.

Thanks, Roger.

Roger Pau Monne (3):
  x86/boot: print CPU and APIC ID in bring up failure
  x86/traps: split code to dump execution state to a separate helper
  x86/boot: attempt to print trace and panic on AP bring up stall

 xen/arch/x86/include/asm/processor.h |  1 +
 xen/arch/x86/smpboot.c               | 15 ++++++-
 xen/arch/x86/traps.c                 | 63 ++++++++++++++++++----------
 3 files changed, 54 insertions(+), 25 deletions(-)

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 23 08:22:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 08:22:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995380.1377830 (Exim 4.92)
	(envelope-from )
	id 1uINfd-0003FD-Ts; Fri, 23 May 2025 08:22:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995380.1377830; Fri, 23 May 2025 08:22: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 1uINfd-0003EU-P3; Fri, 23 May 2025 08:22:25 +0000
Received: by outflank-mailman (input) for mailman id 995380;
 Fri, 23 May 2025 08:22:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uINfd-0003CJ-3G
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 08:22:25 +0000
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
 [2a00:1450:4864:20::32e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0e303ee5-37af-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 10:22:24 +0200 (CEST)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43cfebc343dso68743475e9.2
 for ; Fri, 23 May 2025 01:22:24 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f3dd99f9sm131732165e9.40.2025.05.23.01.22.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 23 May 2025 01:22:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0e303ee5-37af-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747988544; x=1748593344; 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;
        bh=b9OhwSh2sFBPinPT7yDdzAD3rTaDbrlVbBuLtIBte3k=;
        b=ceLdLcdf1ycaNA83FNfFso/brLkJPC71VSciLYuaDbdF8FNap5lfx8uxk2ikgjeU84
         N3JydetGlK8O5KLxznxVBtm0VdTG23LNkwY60Pz/lZDbSf3qpSKJWtnpdYKUw8SGZxJt
         9h+lmborOXtB2JqGSuoSoN+wNlYCGx4FzEfo0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747988544; x=1748593344;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=b9OhwSh2sFBPinPT7yDdzAD3rTaDbrlVbBuLtIBte3k=;
        b=nqIuMwWo2J/r4q6r1HINXwLn8/GKNcWc+40tPxSy8o/PicP5U6AfEoGgejidEvtwtM
         y8Fyt/9zE+ziWEQsQRtPO91qveGzmUYpWjq0ACLJLd/jyKqjRIQkHCfM3slJCeodzgsF
         8nm6J/idKnerdOe113UCF0b/fCfHqaqbxQmRxqHgWSi/3VvTJDTO8YYL6/xHFpvP6vIH
         P8hAiHGgNEYKmv66tgOS/tDlnS0y3friX2KqF29YFf0w5Ev4TL+DWep1iKgLnZ2MYTuY
         hRTgJAHN7kuLc4UX9LbTvnpgCP1dEMCKVhWoUffoGS1rCkKjGl7kh/EoBM/sL+hXrpRD
         ALnA==
X-Gm-Message-State: AOJu0Yz4Y8Nv5/4yc6Fo6/gc1mgjXdvrZbHfxI3qn66kVofywSHVjE+Z
	MZuybqdwR4j4P0aiExqAZZcxuvau77F/u13a0MxFho6FYhXWVQJLHdOJMZft9xz9EqUG3gZlGBX
	4xA/p
X-Gm-Gg: ASbGncvi0sQ+JzfXhg2sul2svTtYZdk1U4+aFQWYHN4oafBXOZvMZkU2vGtmrb8XsHw
	5EIx8O4mY1hIgSE913ujLBaDvCtQVdla8AxDRHtEoz1AcvhVazw6cc2MML6WxnaXSJDWC/UpsSx
	MxHpskf0L21x3t/9gJrfTP7wLN/fB5SDTS7AZ6rSmRLVfmDCYlBvsbzRTRptbaa5MfJYUYEPFFw
	1ssPSvfr6TUQz4BQTyUJ7CpoaUIgBESt9KGRWz6fPf6DRzCKcf7k02pDJUXz9M6mFmfvEpIeoUT
	iEcebj/01MNMRrOUJ6g6C2PndnShlZzjGCDLNPKglmrAV8i58A9qpnVz9r8Lz9vTUbTNOfF0aDJ
	djIa09Ned3d7zRP4kpu8=
X-Google-Smtp-Source: AGHT+IENE8YAu5CgQBp8ad8E9VUooRZ67jjAeumiY9NWwvm4KNgrBaatHEO+EhUp5AHbWMiYfXkIsg==
X-Received: by 2002:a05:600c:a378:b0:442:f482:c432 with SMTP id 5b1f17b1804b1-442fd64e32amr260346245e9.18.1747988543765;
        Fri, 23 May 2025 01:22:23 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper 
Subject: [PATCH v3 2/3] x86/traps: split code to dump execution state to a separate helper
Date: Fri, 23 May 2025 10:21:34 +0200
Message-ID: <20250523082135.18088-3-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250523082135.18088-1-roger.pau@citrix.com>
References: <20250523082135.18088-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Split the code that triggers remote CPUs to dump stacks into a separate
function.  Also introduce a parameter that can be set by the caller of the
newly introduced function to force CPUs to dump the full stack, rather than
just dumping the current function name.

No functional change intended.

Signed-off-by: Roger Pau Monné 
---
Changes since v2:
 - Use parameter opt_show_all variable.
---
 xen/arch/x86/include/asm/processor.h |  1 +
 xen/arch/x86/traps.c                 | 63 ++++++++++++++++++----------
 2 files changed, 41 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index eacd425c5350..10d8078cc1ca 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -371,6 +371,7 @@ void show_registers(const struct cpu_user_regs *regs);
 #define dump_execution_state() run_in_exception_handler(show_execution_state)
 void show_page_walk(unsigned long addr);
 void noreturn fatal_trap(const struct cpu_user_regs *regs, bool show_remote);
+void show_execution_state_nmi(const cpumask_t *mask, bool show_all);
 
 extern void mtrr_ap_init(void);
 extern void mtrr_bp_init(void);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 22f20629327d..559bb1d2029b 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -734,6 +734,43 @@ static int cf_check nmi_show_execution_state(
     return 1;
 }
 
+void show_execution_state_nmi(const cpumask_t *mask, bool show_all)
+{
+    unsigned int msecs, pending;
+
+    /*
+     * Overwrite the global variable, caller is expected to panic after having
+     * dumped the execution state.
+     */
+    if ( show_all )
+        opt_show_all = true;
+
+    watchdog_disable();
+    console_start_sync();
+
+    cpumask_copy(&show_state_mask, mask);
+    set_nmi_callback(nmi_show_execution_state);
+    send_IPI_mask(mask, APIC_DM_NMI);
+
+    /* Wait at most 10ms for some other CPU to respond. */
+    msecs = 10;
+    pending = cpumask_weight(&show_state_mask);
+    while ( pending && msecs-- )
+    {
+        unsigned int left;
+
+        mdelay(1);
+        left = cpumask_weight(&show_state_mask);
+        if ( left < pending )
+        {
+            pending = left;
+            msecs = 10;
+        }
+    }
+    if ( pending )
+        printk("Non-responding CPUs: {%*pbl}\n", CPUMASK_PR(&show_state_mask));
+}
+
 const char *vector_name(unsigned int vec)
 {
     static const char names[][4] = {
@@ -780,31 +817,11 @@ void fatal_trap(const struct cpu_user_regs *regs, bool show_remote)
 
         if ( show_remote )
         {
-            unsigned int msecs, pending;
+            cpumask_t *scratch = this_cpu(scratch_cpumask);
 
-            cpumask_andnot(&show_state_mask, &cpu_online_map,
+            cpumask_andnot(scratch, &cpu_online_map,
                            cpumask_of(smp_processor_id()));
-            set_nmi_callback(nmi_show_execution_state);
-            smp_send_nmi_allbutself();
-
-            /* Wait at most 10ms for some other CPU to respond. */
-            msecs = 10;
-            pending = cpumask_weight(&show_state_mask);
-            while ( pending && msecs-- )
-            {
-                unsigned int left;
-
-                mdelay(1);
-                left = cpumask_weight(&show_state_mask);
-                if ( left < pending )
-                {
-                    pending = left;
-                    msecs = 10;
-                }
-            }
-            if ( pending )
-                printk("Non-responding CPUs: {%*pbl}\n",
-                       CPUMASK_PR(&show_state_mask));
+            show_execution_state_nmi(scratch, false);
         }
     }
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 23 09:24:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 09:24:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995492.1377868 (Exim 4.92)
	(envelope-from )
	id 1uIOdI-0004Qq-OQ; Fri, 23 May 2025 09:24:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995492.1377868; Fri, 23 May 2025 09:24: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 1uIOdI-0004Qj-LF; Fri, 23 May 2025 09:24:04 +0000
Received: by outflank-mailman (input) for mailman id 995492;
 Fri, 23 May 2025 09:24:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIOdH-0004Qd-9y
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 09:24:03 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a8f110c3-37b7-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 11:24:00 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-43ede096d73so65694955e9.2
 for ; Fri, 23 May 2025 02:24:00 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-44ab793a7d5sm45063185e9.1.2025.05.23.02.23.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 23 May 2025 02:23: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" 
X-Inumbo-ID: a8f110c3-37b7-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1747992240; x=1748597040; darn=lists.xenproject.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=IZJNTmOBPKYosd+xCBlKV6aSMJxN28zdgo/kHzmHxHA=;
        b=GckQR0feSKl0EbsEo9P2dxlVQR714X4F5Ybt6U5rc9s2NE4fOUsv5Jxbi2DR9MYjP3
         ZlR3eg7hk9eceu+r7djsaJUaESe4He4CgRmRT7Ds7f93W1RYcLNfewDQu+KSoK7juAOO
         P8LMOTBsMUEqQHWlfeb8pfK4oGmg0rKT7Nmjo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747992240; x=1748597040;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IZJNTmOBPKYosd+xCBlKV6aSMJxN28zdgo/kHzmHxHA=;
        b=k3yS/sXQUSpFsLbn8DMYpLNgmJ6OkdzrSsNXktp2J7uI1OFsfXA3XfpoAXUhj2dM79
         ismijvF2Bfkb6VIw+IRjwgP6PHqsgrlgFFFY3c0BzV/H3KY/45/JuS4KDx7KZxSMDF8z
         2OExd/l4OWpLZtlPsfjCJDSXenam722E97qU6ZNzUswAAoKoE+f1niR/SVrX84lFN7zH
         gnBbUrt5iRwgrH2cqXgGYyMImn3fiNub7QMlOPi1kwWxtyf+dTdew0s59ZKAGdOMKZeT
         WP6uZxxZTGogL1HpNjEa92jMyvn6N7wr6mMqZQm8e5duJhY8AVwpw8U/eGTPJgMlaZOy
         viDQ==
X-Gm-Message-State: AOJu0YxsPh8Qb+r1g6fAMdCrfE4skSIxLXSWMkfDpYGltGOT83o9S/lx
	0IxzvEB8oHMrxMxoG24QsJK/FksOnS3s41XeuwHahPYJ6Y1qglX8H08bqNcJ5XeNexS/OFyqgfA
	yh4g4
X-Gm-Gg: ASbGncumasBf6g+8LiOw3RLD5Mh+Sh+whhei2zLwxyAFeiFa6aYmUGB9F/D0lKCFvVa
	lTIqsnH+guZeXioG7xM/noOrE6pTqRTeS/mNfi/k+8spgm/wCzsg6sJTN/vM4DWe/FCk5h3j+Hr
	D+bnobDoMWodB66luXFgWXykWAEapzRnKU8PKKP/vhXQ9c5iANjpRD4psbZXZOVJbuXLXrDBKgy
	B7u9umGng/FzZukPHmRxCsInXBoz+D7N5fV+hiaQroDFcR8ZXNlI39FQAmguHYNuW6C9LN2AH3+
	YS1Fo+ZROeiy/CJrgkAW7BHX5oRbPYxH2M2kJPTEk3tU6fbbN7Yct1/rv9NzthDQ/yeocDCv5HN
	wMeGPQ1398XrWH23NtbMMXBc8
X-Google-Smtp-Source: AGHT+IGWQQyFxCg8OVdmZSzMnxZAnpvNtcD2gChq/YGOm+N986cciKgVkG9Cy2HbQFiotccAMNUWOA==
X-Received: by 2002:a05:600c:4688:b0:442:f4a3:8c5c with SMTP id 5b1f17b1804b1-44b6d2cc4a9mr33037755e9.10.1747992239640;
        Fri, 23 May 2025 02:23:59 -0700 (PDT)
Date: Fri, 23 May 2025 11:23:58 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Teddy Astie 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper 
Subject: Re: [PATCH] iommu/amd: Remove dead non-atomic update checking
Message-ID: 
References: <761f464ae56a449291e38724a1f823606f3ba9d0.1747924653.git.teddy.astie@vates.tech>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <761f464ae56a449291e38724a1f823606f3ba9d0.1747924653.git.teddy.astie@vates.tech>

On Thu, May 22, 2025 at 03:44:12PM +0000, Teddy Astie wrote:
> When updating a DTE, amd_iommu_setup_domain_device checks if the update had been
> non-atomic (i.e rc > 0) and eventually throws a warning but since [1], rc can
> no longer be positive, making this check never taken.
> 
> [1] x86/iommu: remove non-CX16 logic from DMA remapping
>     https://gitlab.com/xen-project/xen/-/commit/3fc44151d83d3d63320036bcf06634dfbebe1ff3

I would avoid putting links to commits, and just reference the commit
by hash:

"When updating a DTE, amd_iommu_setup_domain_device() would check if
the update had been non-atomic (i.e rc > 0) and throw a warning if
such non-atomic update could be dangerous.  However since commit
3fc44151d83d, rc can no longer be positive, making this branch
unreachable code.

No functional change intended."

> Signed-off-by: Teddy Astie 
> ---
>  xen/drivers/passthrough/amd/iommu_map.c     |  4 +---
>  xen/drivers/passthrough/amd/pci_amd_iommu.c | 18 ------------------
>  2 files changed, 1 insertion(+), 21 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/amd/iommu_map.c b/xen/drivers/passthrough/amd/iommu_map.c
> index dde393645a..07f405ed63 100644
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -157,9 +157,7 @@ static void set_iommu_ptes_present(unsigned long pt_mfn,
>  /*
>   * This function returns
>   * - -errno for errors,
> - * - 0 for a successful update, atomic when necessary
> - * - 1 for a successful but non-atomic update, which may need to be warned
> - *   about by the caller.
> + * - 0 for a successful update

I think you can remove the comment completely.  Returning -errno or 0
is the expected behavior.  We just add those comments when functions
diverge from the classic -errno/0 return codes.

>   */
>  int amd_iommu_set_root_page_table(struct amd_iommu_dte *dte,
>                                    uint64_t root_ptr, uint16_t domain_id,
> diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> index d00697edb3..409752ffc8 100644
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -225,24 +225,6 @@ static int __must_check amd_iommu_setup_domain_device(
>              spin_unlock_irqrestore(&iommu->lock, flags);
>              return rc;
>          }

You might want to also adjust the previous if condition (out of
context here) so it's if ( rc ) rather than rc < 0.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 23 09:44:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 09:44:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995521.1377883 (Exim 4.92)
	(envelope-from )
	id 1uIOxH-0007Zu-DX; Fri, 23 May 2025 09:44:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995521.1377883; Fri, 23 May 2025 09: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 1uIOxH-0007Zn-Aj; Fri, 23 May 2025 09:44:43 +0000
Received: by outflank-mailman (input) for mailman id 995521;
 Fri, 23 May 2025 09:44:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIOxG-0007Zh-Fj
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 09:44:42 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8bd4f348-37ba-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 11:44:39 +0200 (CEST)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-30bf7d0c15eso83550811fa.0
 for ; Fri, 23 May 2025 02:44:39 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6004d50364dsm11641844a12.32.2025.05.23.02.44.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 23 May 2025 02:44: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" 
X-Inumbo-ID: 8bd4f348-37ba-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747993479; x=1748598279; darn=lists.xenproject.org;
        h=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;
        bh=ihhV+WqyW2bpvcZYh20Nass9MEvkKP4sCuZ/GLVGPI4=;
        b=j7m1sXXU2wFDEUcwuyCfoH6400P6aBvuY35nBB32m771cJMj+f+nWz/xAYMykezj90
         7tBrk0mbfIyGbjM6UFfFt7wNfs7xlea8obRd4iPtY0tPlSEBlqVa1+pmRQIYsPzOybS+
         38nJ6XgE6+OAxgWjJf/NzYVHC850ZXHFywIx2R7d9+KSxp9rXXkmu0tLlXbDtBXgHgUJ
         kCftjHnEq2gNif7fT5ZzbmXc6VDoaS9u/v56w2IQz8Ihr99/5OU6cUAh7lipDe+1IfXw
         9TVSlr3oITmZsskm0cxoNwc9ahJ164pslje0K7fmTKO7y1L8fTrab3WSgPs6uTOEXdeL
         UCLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747993479; x=1748598279;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=ihhV+WqyW2bpvcZYh20Nass9MEvkKP4sCuZ/GLVGPI4=;
        b=AmkVstSLu6WSnJlUZsYCPOmUROo4ELEIy9/l6tUR0HQKOGpxbV1N8Uzi24jBhIpebE
         K8QOMvohD3E5na1pd+j0MUOuqKyJSK76tv18WaR3kFFhUt3Woz6tArIjliZ5lt4ERZ01
         XqV20DAhSt4K69MCF9Z0pnhxqkjGGW+TJgEi8x9FVuVSuEcpAAfgr/VqY4pkExjoPzDS
         7LwyLcOQmf/tmaueTSPQ7CKMo3D8nInGC912egmjLdJU5gAKBz0mNID6G7wEB2DjSK50
         y0IRKICHrj4MPMYSr7rMWOA9kAleN4O2VPTjlQuezG3ke/7BDjDXB0QU/b+CDSuF3aUv
         dDeg==
X-Forwarded-Encrypted: i=1; AJvYcCWVJUeUKb5YtOvXclpKznv+Sh8qy8ETCOZDefmQ6sMhtK2LNvdz9g25wpMCR8frhQ4rAFl0jheQZZc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzLmZ09Pa1QSRp9hzAz0Da5eN0vbFVIdiTn4Ppe+uRQwxWXnaPh
	L88XTRDKeSU3WyzFcQ0rtwjzypMpXeAUb0f2oB8DWzWyNKyI+vCacdwcZ13t6w==
X-Gm-Gg: ASbGncssVyixnErs0iO3vBnjUHh/2wfnbyCUZWyheq6x48y/0SIaEMm44rNaFiLD3oW
	frNOF2aJELBrVLLC4khSN7tCSv+L16GdzHFOUJvQCWeXrzBl4xAcz21kVjskg/7YtKLRMyDRb3N
	gEr1bBe3Fnu9C9bIqcHXUj29DJEyNqB0WzoVNklEh25hpJeWdUzjS4hys5JwMejCEEYmKQGegA/
	GIHHbK78t80JfOhWuIx0SeLzggzZa1rs3T7mZzxkbc3wvGzWNNpblzH2MzmXkf/JW1Sx8OjbRzh
	GiJrPGenBQ8TeXcWHSqSaYEupN7f5FMUoQxaGFTm/uubZlm6Dx9tSWjq39Di0lVgpN2KDs5AKt7
	1oXYkPZ8wtJjILqeORlmN8W91
X-Google-Smtp-Source: AGHT+IHAfiPdpprb5QW/qb/pAbK1qdtfyHv7zhyAzyhbhiut5Y+NPaiXZlIIHjF6MMYjAWUN7/5dRQ==
X-Received: by 2002:a05:6402:90b:b0:5ff:addb:653e with SMTP id 4fb4d7f45d1cf-6011411aa27mr21622109a12.23.1747993468343;
        Fri, 23 May 2025 02:44:28 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------csSNPe6BUR10LVf3d2LeJe3N"
Message-ID: 
Date: Fri, 23 May 2025 11:44:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/6] xen/riscv: introduce things necessary for p2m
 initialization
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <0a03d1f38649cfd8656147f209652dff0f9d170c.1746805907.git.oleksii.kurochko@gmail.com>
 <7ef3ca26-05f5-4e86-b7c7-852b6c74a3d0@suse.com>
 <1a0d3084-9e77-4df5-936a-c1a1317c0f18@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------csSNPe6BUR10LVf3d2LeJe3N
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/22/25 6:09 PM, Jan Beulich wrote:
> On 22.05.2025 17:53, Oleksii Kurochko wrote:
>> On 5/20/25 3:37 PM, Jan Beulich wrote:
>>> On 09.05.2025 17:57, Oleksii Kurochko wrote:
>>>> +static struct page_info *p2m_get_clean_page(struct domain *d)
>>>> +{
>>>> +    struct page_info *page;
>>>> +
>>>> +    /*
>>>> +     * As mentioned in the Priviliged Architecture Spec (version 20240411)
>>>> +     * As explained in Section 18.5.1, for the paged virtual-memory schemes
>>>> +     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
>>>> +     * and must be aligned to a 16-KiB boundary.
>>>> +     */
>>>> +    page = alloc_domheap_pages(NULL, 2, 0);
>>> Shouldn't this allocation come from the domain's P2M pool (which is yet
>>> to be introduced)?
>> First, I will drop p2m_get_clean_page() as it will be used only for p2m root page
>> table allocation.
>>
>> p2m_init() is called by domain_create() [->arch_domain_create()->p2m_init()] from create_domUs():
>> [https://gitlab.com/xen-project/xen/-/blob/staging/xen/common/device-tree/dom0less-build.c?ref_type=heads#L984].
>>
>> When p2m_init() is called, p2m pool isn't ready and domain isn't created yet. Last one
>> is also crucial for usage of p2m pool as p2m pool belongs to domain and thereby it is
>> using alloc_domheap_page(d, ...) (Not NULL as for allocation of p2m root table above),
>> so domain should be created first.
> Yet that is part of my point: This allocation should be against the domain,
> so it is properly accounted. What's the problem with allocating the root
> table when the pools is being created / filled?

I can't use pages from pool for root table as they aren't properly aligned.

At the moment, creation of p2m pool looks like:
  int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
  {
      struct page_info *pg;

      ASSERT(spin_is_locked(&d->arch.paging.lock));

      for ( ; ; )
      {
          if ( d->arch.paging.p2m_total_pages < pages )
          {
              /* Need to allocate more memory from domheap */
              pg = alloc_domheap_page(d, MEMF_no_owner);
              if ( pg == NULL )
              {
                  printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
                  return -ENOMEM;
              }
              ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
                  d->arch.paging.p2m_total_pages + 1;
              page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
          }
          ...
      }

      return 0;
  }
alloc_domheap_page(d, MEMF_no_owner) allocates page table with order 0, so 4k-aligned page table.
But if I needed 16k for root table and it should be 16k-aligned then I still have to use
alloc_domheap_pages(NULL, 2, 0);

Or do you mean that I have to something like:
  int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
  {
      struct page_info *pg;
  
      ASSERT(spin_is_locked(&d->arch.paging.lock));
  
+    if ( !d->arch.p2m.root )
+    {
+        unsigned int order = get_order_from_bytes(KB(16));
+        unsigned int nr_pages = _AC(1,U) << order;
+        /*
+        * As mentioned in the Priviliged Architecture Spec (version 20240411)
+        * As explained in Section 18.5.1, for the paged virtual-memory schemes
+        * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
+        * and must be aligned to a 16-KiB boundary.
+        */
+        d->arch.p2m.root = alloc_domheap_pages(d, order, MEMF_no_owner);
+        if ( d->arch.p2m.root == NULL )
+            panic("root page table hasn't been allocated\n");
+
+        clear_and_clean_page(d->arch.p2m.root);
+
+        /* TODO: do I need TLB flush here? */
+
+        ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
+            d->arch.paging.p2m_total_pages + nr_pages;
+    }
+
...
}
(I will the current version of p2m_alloc_table() instead of open-coding.)


>>>> +{
>>>> +    unsigned long ppn;
>>>> +    unsigned long hgatp_mode;
>>>> +
>>>> +    ppn = PFN_DOWN(page_to_maddr(page_info)) & HGATP_PPN;
>>>> +
>>>> +    /* ASID (VMID) not supported yet */
>>>> +
>>>> +#if RV_STAGE1_MODE == SATP_MODE_SV39
>>>> +    hgatp_mode = HGATP_MODE_SV39X4;
>>>> +#elif RV_STAGE1_MODE == SATP_MODE_SV48
>>>> +    hgatp_mode = HGATP_MODE_SV48X4;
>>>> +#else
>>>> +    #error "add HGATP_MODE"
>>> As before, please have the # of pre-processor directives in the first column.
>>>
>>>> +#endif
>>>> +
>>>> +    return ppn | (hgatp_mode << HGATP_MODE_SHIFT);
>>> Use MASK_INSR()?
>> Do you mean MASK_INSR(hgatp_mode, HGATP_MODE_MASK)?
>> If yes, then I didn't get what is the point then?
> The point is that generally ..._SHIFT is redundant when you also have
> ..._MASK; that's what MASK_EXTR() and MASK_INSR() leverage.

At the moment, there is no mask for HGATP_MODE so if to use *_MASK then I
have to introduce it if it better to have *_MASK instead of *_SHIFT.

>
>>>> +static int p2m_alloc_table(struct domain *d)
>>>> +{
>>>> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>>> +
>>>> +    p2m->root = p2m_allocate_root(d);
>>>> +    if ( !p2m->root )
>>>> +        return -ENOMEM;
>>>> +
>>>> +    p2m->hgatp = hgatp_from_page_info(p2m->root);
>>>> +
>>>> +    /*
>>>> +     * Make sure that all TLBs corresponding to the new VMID are flushed
>>>> +     * before using it.
>>>> +     */
>>>> +    p2m_write_lock(p2m);
>>>> +    p2m_force_tlb_flush_sync(p2m);
>>>> +    p2m_write_unlock(p2m);
>>> While Andrew directed you towards a better model in general, it won't be
>>> usable here then, as the guest didn't run on any pCPU(s) yet. Imo you
>>> want to do a single global flush e.g. when VMIDs wrap around. That'll be
>>> fewer global flushes than one per VM creation.
>> I am not sure that I get a phrase 'VMIDs wrap around'.
> You have to allocate them somehow. Typically you'll use the next one available.
> At some point you will need to start over, searching from the beginning. Prior
> to that now allocation of a new one will require any flush, as none of them
> had be in use before (after boot or the last such flush).

Thanks. Now I get your point.

Won't be better to do TLB flushing during destroying of a domain so then we will
be sure that TLBs connected to freed VMID aren't present in TLB anymore?

IIUC, it will work only if VMID is used, right?
In case if VMID isn't used, probably we can drop flushing here and do a flush
during booting, right?
Won't be enough to flushing of guest TLB only during context switch?

>
>> I am going to implement, p2m_force_tlb_flush_sync() as:
>>    static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
>>    {
>>      ...
>>        sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0);
>>      ...
>>    }
>>
>> With such implementation if the guest didn't run on any pCPU(s) yet
>> then d->dirty_cpumask is empty, then sbi_remote_hfence_gvma() will do nothing
>> as hmask will be NULL (https://gitlab.com/xen-project/people/olkur/xen/-/blob/staging/xen/arch/riscv/sbi.c?ref_type=heads#L238).
>> I am not sure that it is a good idea as I can't find a guarantee in the spec
>> that TLB will be empty during boot time.
> If in doubt, do one global flush while booting.

By booting you mean somewhere in continue_new_vcpu()?

~ Oleksii


--------------csSNPe6BUR10LVf3d2LeJe3N
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/22/25 6:09 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 22.05.2025 17:53, Oleksii Kurochko wrote:

    
      
    
        
    On 5/20/25 3:37 PM, Jan Beulich wrote:

    
        
    
          
    On 09.05.2025 17:57, Oleksii Kurochko wrote:

    
          
    
            
    +static struct page_info *p2m_get_clean_page(struct domain *d)
+{
+    struct page_info *page;
+
+    /*
+     * As mentioned in the Priviliged Architecture Spec (version 20240411)
+     * As explained in Section 18.5.1, for the paged virtual-memory schemes
+     * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
+     * and must be aligned to a 16-KiB boundary.
+     */
+    page = alloc_domheap_pages(NULL, 2, 0);

    
          
    
          
    Shouldn't this allocation come from the domain's P2M pool (which is yet
to be introduced)?

    
        
    
        
    First, I will drop p2m_get_clean_page() as it will be used only for p2m root page
table allocation.

p2m_init() is called by domain_create() [->arch_domain_create()->p2m_init()] from create_domUs():
[https://gitlab.com/xen-project/xen/-/blob/staging/xen/common/device-tree/dom0less-build.c?ref_type=heads#L984].

When p2m_init() is called, p2m pool isn't ready and domain isn't created yet. Last one
is also crucial for usage of p2m pool as p2m pool belongs to domain and thereby it is
using alloc_domheap_page(d, ...) (Not NULL as for allocation of p2m root table above),
so domain should be created first.

    
      
    
      
    Yet that is part of my point: This allocation should be against the domain,
so it is properly accounted. What's the problem with allocating the root
table when the pools is being created / filled?
    
    
    
    
    I can't use pages from pool for root table as they aren't properly aligned.

At the moment, creation of p2m pool looks like:
 int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
 {
     struct page_info *pg;

     ASSERT(spin_is_locked(&d->arch.paging.lock));

     for ( ; ; )
     {
         if ( d->arch.paging.p2m_total_pages < pages )
         {
             /* Need to allocate more memory from domheap */
             pg = alloc_domheap_page(d, MEMF_no_owner);
             if ( pg == NULL )
             {
                 printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
                 return -ENOMEM;
             }
             ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
                 d->arch.paging.p2m_total_pages + 1;
             page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
         }
         ...
     }

     return 0;
 }
alloc_domheap_page(d, MEMF_no_owner) allocates page table with order 0, so 4k-aligned page table.
But if I needed 16k for root table and it should be 16k-aligned then I still have to use
alloc_domheap_pages(NULL, 2, 0);

Or do you mean that I have to something like:
 int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
 {
     struct page_info *pg;
 
     ASSERT(spin_is_locked(&d->arch.paging.lock));
 
+    if ( !d->arch.p2m.root )
+    {
+        unsigned int order = get_order_from_bytes(KB(16));
+        unsigned int nr_pages = _AC(1,U) << order;
+        /*
+        * As mentioned in the Priviliged Architecture Spec (version 20240411)
+        * As explained in Section 18.5.1, for the paged virtual-memory schemes
+        * (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the root page table is 16 KiB
+        * and must be aligned to a 16-KiB boundary.
+        */
+        d->arch.p2m.root = alloc_domheap_pages(d, order, MEMF_no_owner);
+        if ( d->arch.p2m.root == NULL )
+            panic("root page table hasn't been allocated\n");
+
+        clear_and_clean_page(d->arch.p2m.root);
+
+        /* TODO: do I need TLB flush here? */
+
+        ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
+            d->arch.paging.p2m_total_pages + nr_pages;
+    }
+
...
}
(I will the current version of p2m_alloc_table() instead of open-coding.)



    
    
    
      
    
      
    
        
    
          
    
            
    +{
+    unsigned long ppn;
+    unsigned long hgatp_mode;
+
+    ppn = PFN_DOWN(page_to_maddr(page_info)) & HGATP_PPN;
+
+    /* ASID (VMID) not supported yet */
+
+#if RV_STAGE1_MODE == SATP_MODE_SV39
+    hgatp_mode = HGATP_MODE_SV39X4;
+#elif RV_STAGE1_MODE == SATP_MODE_SV48
+    hgatp_mode = HGATP_MODE_SV48X4;
+#else
+    #error "add HGATP_MODE"

    
          
    
          
    As before, please have the # of pre-processor directives in the first column.


    
          
    
            
    +#endif
+
+    return ppn | (hgatp_mode << HGATP_MODE_SHIFT);

    
          
    
          
    Use MASK_INSR()?

    
        
    
        
    Do you mean MASK_INSR(hgatp_mode, HGATP_MODE_MASK)?
If yes, then I didn't get what is the point then?

    
      
    
      
    The point is that generally ..._SHIFT is redundant when you also have
..._MASK; that's what MASK_EXTR() and MASK_INSR() leverage.
    
    
    
    
    At the moment, there is no mask for HGATP_MODE so if to use *_MASK then I
have to introduce it if it better to have *_MASK instead of *_SHIFT.


    
    
    
      
    

    
      
    
        
    
          
    
            
    +static int p2m_alloc_table(struct domain *d)
+{
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    p2m->root = p2m_allocate_root(d);
+    if ( !p2m->root )
+        return -ENOMEM;
+
+    p2m->hgatp = hgatp_from_page_info(p2m->root);
+
+    /*
+     * Make sure that all TLBs corresponding to the new VMID are flushed
+     * before using it.
+     */
+    p2m_write_lock(p2m);
+    p2m_force_tlb_flush_sync(p2m);
+    p2m_write_unlock(p2m);

    
          
    
          
    While Andrew directed you towards a better model in general, it won't be
usable here then, as the guest didn't run on any pCPU(s) yet. Imo you
want to do a single global flush e.g. when VMIDs wrap around. That'll be
fewer global flushes than one per VM creation.

    
        
    
        
    I am not sure that I get a phrase 'VMIDs wrap around'.

    
      
    
      
    You have to allocate them somehow. Typically you'll use the next one available.
At some point you will need to start over, searching from the beginning. Prior
to that now allocation of a new one will require any flush, as none of them
had be in use before (after boot or the last such flush).
    
    
    
    
    Thanks. Now I get your point.

Won't be better to do TLB flushing during destroying of a domain so then we will
be sure that TLBs connected to freed VMID aren't present in TLB anymore?

IIUC, it will work only if VMID is used, right?
In case if VMID isn't used, probably we can drop flushing here and do a flush
during booting, right?
Won't be enough to flushing of guest TLB only during context switch?


    
    
    
      
    

    
      
    
        
    I am going to implement, p2m_force_tlb_flush_sync() as:
  static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
  {
    ...
      sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0);
    ...
  }

With such implementation if the guest didn't run on any pCPU(s) yet
then d->dirty_cpumask is empty, then sbi_remote_hfence_gvma() will do nothing
as hmask will be NULL (https://gitlab.com/xen-project/people/olkur/xen/-/blob/staging/xen/arch/riscv/sbi.c?ref_type=heads#L238).
I am not sure that it is a good idea as I can't find a guarantee in the spec
that TLB will be empty during boot time.

    
      
    
      
    If in doubt, do one global flush while booting.
    
    
    
    
    By booting you mean somewhere in continue_new_vcpu()?

~ Oleksii

    
    
    
  


--------------csSNPe6BUR10LVf3d2LeJe3N--


From xen-devel-bounces@lists.xenproject.org Fri May 23 10:27:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 10:27:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995540.1377893 (Exim 4.92)
	(envelope-from )
	id 1uIPcM-0004ns-IU; Fri, 23 May 2025 10:27:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995540.1377893; Fri, 23 May 2025 10: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 1uIPcM-0004nl-FQ; Fri, 23 May 2025 10:27:10 +0000
Received: by outflank-mailman (input) for mailman id 995540;
 Fri, 23 May 2025 10:27:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIPcL-0004nf-Jn
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 10:27:09 +0000
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
 [2a00:1450:4864:20::62a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7833a52c-37c0-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 12:27:04 +0200 (CEST)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-ace94273f0dso1580986166b.3
 for ; Fri, 23 May 2025 03:27:03 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d08058bsm1214064066b.68.2025.05.23.03.27.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 23 May 2025 03:27:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7833a52c-37c0-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747996023; x=1748600823; darn=lists.xenproject.org;
        h=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;
        bh=PQixmKowOgi/xT5sg3HR+0dsIMV2HyQ1ZDXzHmr7bCs=;
        b=GG6QKgvi8o8oAmxqkej3uRBKU5aQf9VnFaCLMQ7EZgrXT/8BCExYbjsD3QgCAGKcki
         KFu/d4/1He8WIF6DrxnrGYJTo/S9B3lvu23tW015sReqgOX0Qvn/wW4ci+04n3LQ5exI
         qOjo037ybNdLl2u44kdodGCdpAdagCu600CqCSDNoFXikjwJuLlAY+KPNJ022Kl85lyn
         nJYoP+1Uyg72fRvwet6M4zPpVsYHkcrMYg8aJp/jFWayhQP+TZN5kFoJqS7rCzfSQwaH
         WEjLtaZjFzuSdp5iZka7yw9RZplRiJy52+ED5d0ldqnfGwMVsQcAIMgtfblvZa30ewFi
         vB9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747996023; x=1748600823;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=PQixmKowOgi/xT5sg3HR+0dsIMV2HyQ1ZDXzHmr7bCs=;
        b=TFHkmgK4WHlFF+Yk+9Ga8piHfdvPam09/CoZ2M1+rNs+isMLoGuPbBo7IomRUoGZT2
         v/eSncnQbF5doFVEvymAF99oueO0EH4t/QvSpkv6DhFRDU7HPX/4aSAR/EM18j4vpuo9
         qc9IuViniqMlrrMj6yux87Qws/xenCtftuFoC8rC6PqV4AcQAYmme4Zd8DZqmcrKrX2h
         +gowuvATFDM8r3ukr+Q7yN+iElRcjjjjqTiFwUgl4HfL/LZixTVvI/U3oWcb/Y2sd+d6
         YnNO81aO4wqHUazZKoK64D7dPyaow9yuAzHZEpn3G/UVSL9kFM6aUn4mF845b7n0zZBY
         BzYg==
X-Forwarded-Encrypted: i=1; AJvYcCVNKmt0MCfwcTTG+nXItGcAq8OC5c2MAXReTYxez0MErXCuBy6pNU9YOt8+Uy39svNMC42HAtiW41k=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx2SrMN1doWZKewjPR9voYya3c17CRnUi+rlZiT/j5ntPZuGKqE
	GInw1LISoiMdrY/WfecwbFFFWSOHbeRfGIylW/K4vLCnBPrZoNJ07C3L
X-Gm-Gg: ASbGncv2SXCdWojolW+kK3e/Q3HlBYzx4cjcl1S6funTBW3GdDx5DDaiJiTUT2q4nLM
	gkZWKQFs5+A4pTdpXqftQ+aer80qAesAxrDcx2jTVhyLIctM062wvuhbB6S6Ot+gyZZkDzsES30
	9jA5Iyabfp8pXeoPaDxTPQDaD7YNgDblSrJbtDNMlpAgylJVtjgQcHYd+qzpLIoq75SlUsaJfnB
	GaVP6GRy8uM+s0pf03bGz4CafBKs18V9tx1hBJjyYsFamEbxyIF4zZjz9DoDI3IfAd7YM8zvl0V
	zi0SSgi7ocqgZSNkYTlnxIDG9F2eTo+oh4KXddadVD9AYgesXbpJLj5GDJTNh9/vMO6GOJjSafM
	upTUR6y/J7hyZxVjsiKILlaJw
X-Google-Smtp-Source: AGHT+IFrfMKLMXqHcxme/UtexrlHdSez1xPTYQqEGN9hWt8Dvq99V74yipb53e4USELAJmArdHo/sA==
X-Received: by 2002:a17:907:7e8b:b0:ad2:35db:a732 with SMTP id a640c23a62f3a-ad7083c5e02mr215299566b.22.1747996023007;
        Fri, 23 May 2025 03:27:03 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------S4txwQopjWVzSFoXxOBkm2ib"
Message-ID: <4a6136c3-4146-48e6-85d5-4a6f30bc9920@gmail.com>
Date: Fri, 23 May 2025 12:27:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/6] xen/riscv: construct the P2M pages pool for guests
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 

This is a multi-part message in MIME format.
--------------S4txwQopjWVzSFoXxOBkm2ib
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/20/25 4:38 PM, Jan Beulich wrote:
> On 09.05.2025 17:57, Oleksii Kurochko wrote:
>> Implement p2m_set_allocation() to construct p2m pages pool for guests
>> based on required number of pages.
>>
>> This is implemented by:
>> - Adding a `struct paging_domain` which contains a freelist, a
>>    counter variable and a spinlock to `struct arch_domain` to
>>    indicate the free p2m pages and the number of p2m total pages in
>>    the p2m pages pool.
>> - Adding a helper `p2m_set_allocation` to set the p2m pages pool
>>    size. This helper should be called before allocating memory for
>>    a guest and is called from domain_p2m_set_allocation(), the latter
>>    is a part of common dom0less code.
>>
>> Signed-off-by: Oleksii Kurochko
> As already indicated in reply to patch 2, I expect this pool will want
> introducing ahead of that.
>
>> --- a/xen/arch/riscv/p2m.c
>> +++ b/xen/arch/riscv/p2m.c
>> @@ -1,4 +1,12 @@
>>   #include 
>> +/*
>> + * Because of general_preempt_check() from xen/sched.h which uses
>> + * local_events_need_delivery() but latter is declared in .
>> + * Thereby it is needed to icnlude  here before xen/sched.h.
>> + *
>> + * Shouldn't be xen/event.h be included in ?
>> + */
>> +#include 
> The question doesn't belong here; such could be put in the post-commit-
> message area. And the answer depends on what dependency you found missing.

It is needed for local_events_need_delivery() which is used by general_preempt_check()
in p2m_set_allocation(). Otherwise, the following issue will occur:

In file included from ././include/xen/config.h:17,
                  from :
arch/riscv/p2m.c: In function 'p2m_set_allocation':
./include/xen/sched.h:941:36: error: implicit declaration of function 'local_events_need_delivery' [-Werror=implicit-function-declaration]
   941 |         (!is_idle_vcpu(current) && local_events_need_delivery())    \
       |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
./include/xen/compiler.h:26:43: note: in definition of macro 'unlikely'
    26 | #define unlikely(x)   __builtin_expect(!!(x),0)
       |                                           ^
arch/riscv/p2m.c:244:27: note: in expansion of macro 'general_preempt_check'
   244 |         if ( preempted && general_preempt_check() )
       |                           ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

>
>> @@ -166,3 +176,60 @@ int p2m_init(struct domain *d)
>>   
>>       return 0;
>>   }
>> +
>> +/*
>> + * Set the pool of pages to the required number of pages.
>> + * Returns 0 for success, non-zero for failure.
>> + * Call with d->arch.paging.lock held.
>> + */
>> +int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
>> +{
>> +    struct page_info *pg;
>> +
>> +    ASSERT(spin_is_locked(&d->arch.paging.lock));
>> +
>> +    for ( ; ; )
>> +    {
>> +        if ( d->arch.paging.p2m_total_pages < pages )
>> +        {
>> +            /* Need to allocate more memory from domheap */
>> +            pg = alloc_domheap_page(d, MEMF_no_owner);
>> +            if ( pg == NULL )
>> +            {
>> +                printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
>> +                return -ENOMEM;
>> +            }
>> +            ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
>> +                d->arch.paging.p2m_total_pages + 1;
> Looks like you copied this from Arm, but this code is bogus: Using
> ACCESS_ONCE() just on the lhs is pretty pointless. Once also used on the
> rhs the expression can easily become
>
>                  ACCESS_ONCE(d->arch.paging.p2m_total_pages) += 1;
>
> or even
>
>                  ACCESS_ONCE(d->arch.paging.p2m_total_pages)++;
>
> .
>
>> +            page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
>> +        }
>> +        else if ( d->arch.paging.p2m_total_pages > pages )
>> +        {
>> +            /* Need to return memory to domheap */
>> +            pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
>> +            if( pg )
>> +            {
>> +                ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
>> +                    d->arch.paging.p2m_total_pages - 1;
> Same here then, obviously.
>
>> +                free_domheap_page(pg);
>> +            }
>> +            else
>> +            {
>> +                printk(XENLOG_ERR
>> +                       "Failed to free P2M pages, P2M freelist is empty.\n");
>> +                return -ENOMEM;
>> +            }
>> +        }
>> +        else
>> +            break;
>> +
>> +        /* Check to see if we need to yield and try again */
>> +        if ( preempted && general_preempt_check() )
> While it's this way on both Arm and x86, I wonder how useful it is
> to check on every iteration, especially when freeing pages back to the
> buddy allocator.

IIUC, but a preemption request could happen for both cases. And destroying of
a domain could also consume long time and so not to block hypervisor if something
more urgent should be handled it could be also have this check for the case of
freeng pages back to the buddy allocator.

~ Oleksii

--------------S4txwQopjWVzSFoXxOBkm2ib
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/20/25 4:38 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 09.05.2025 17:57, Oleksii Kurochko wrote:

    
      
    
        
    Implement p2m_set_allocation() to construct p2m pages pool for guests
based on required number of pages.

This is implemented by:
- Adding a `struct paging_domain` which contains a freelist, a
  counter variable and a spinlock to `struct arch_domain` to
  indicate the free p2m pages and the number of p2m total pages in
  the p2m pages pool.
- Adding a helper `p2m_set_allocation` to set the p2m pages pool
  size. This helper should be called before allocating memory for
  a guest and is called from domain_p2m_set_allocation(), the latter
  is a part of common dom0less code.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

    
      
    
      
    As already indicated in reply to patch 2, I expect this pool will want
introducing ahead of that.


    
      
    
        
    --- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -1,4 +1,12 @@
 #include <xen/domain_page.h>
+/*
+ * Because of general_preempt_check() from xen/sched.h which uses
+ * local_events_need_delivery() but latter is declared in <asm/event.h>.
+ * Thereby it is needed to icnlude <xen/event.h> here before xen/sched.h.
+ *
+ * Shouldn't be xen/event.h be included in <xen/sched.h>?
+ */
+#include <xen/event.h>

    
      
    
      
    The question doesn't belong here; such could be put in the post-commit-
message area. And the answer depends on what dependency you found missing.
    
    
    
    
    It is needed for local_events_need_delivery() which is used by general_preempt_check()
in p2m_set_allocation(). Otherwise, the following issue will occur:

In file included from ././include/xen/config.h:17,
                 from <command-line>:
arch/riscv/p2m.c: In function 'p2m_set_allocation':
./include/xen/sched.h:941:36: error: implicit declaration of function 'local_events_need_delivery' [-Werror=implicit-function-declaration]
  941 |         (!is_idle_vcpu(current) && local_events_need_delivery())    \
      |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
./include/xen/compiler.h:26:43: note: in definition of macro 'unlikely'
   26 | #define unlikely(x)   __builtin_expect(!!(x),0)
      |                                           ^
arch/riscv/p2m.c:244:27: note: in expansion of macro 'general_preempt_check'
  244 |         if ( preempted && general_preempt_check() )
      |                           ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors


    
    
    
      
    

    
      
    
        
    @@ -166,3 +176,60 @@ int p2m_init(struct domain *d)
 
     return 0;
 }
+
+/*
+ * Set the pool of pages to the required number of pages.
+ * Returns 0 for success, non-zero for failure.
+ * Call with d->arch.paging.lock held.
+ */
+int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted)
+{
+    struct page_info *pg;
+
+    ASSERT(spin_is_locked(&d->arch.paging.lock));
+
+    for ( ; ; )
+    {
+        if ( d->arch.paging.p2m_total_pages < pages )
+        {
+            /* Need to allocate more memory from domheap */
+            pg = alloc_domheap_page(d, MEMF_no_owner);
+            if ( pg == NULL )
+            {
+                printk(XENLOG_ERR "Failed to allocate P2M pages.\n");
+                return -ENOMEM;
+            }
+            ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
+                d->arch.paging.p2m_total_pages + 1;

    
      
    
      
    Looks like you copied this from Arm, but this code is bogus: Using
ACCESS_ONCE() just on the lhs is pretty pointless. Once also used on the
rhs the expression can easily become

                ACCESS_ONCE(d->arch.paging.p2m_total_pages) += 1;

or even

                ACCESS_ONCE(d->arch.paging.p2m_total_pages)++;

.


    
      
    
        
    +            page_list_add_tail(pg, &d->arch.paging.p2m_freelist);
+        }
+        else if ( d->arch.paging.p2m_total_pages > pages )
+        {
+            /* Need to return memory to domheap */
+            pg = page_list_remove_head(&d->arch.paging.p2m_freelist);
+            if( pg )
+            {
+                ACCESS_ONCE(d->arch.paging.p2m_total_pages) =
+                    d->arch.paging.p2m_total_pages - 1;

    
      
    
      
    Same here then, obviously.


    
      
    
        
    +                free_domheap_page(pg);
+            }
+            else
+            {
+                printk(XENLOG_ERR
+                       "Failed to free P2M pages, P2M freelist is empty.\n");
+                return -ENOMEM;
+            }
+        }
+        else
+            break;
+
+        /* Check to see if we need to yield and try again */
+        if ( preempted && general_preempt_check() )

    
      
    
      
    While it's this way on both Arm and x86, I wonder how useful it is
to check on every iteration, especially when freeing pages back to the
buddy allocator.
    
    
    
    
    IIUC, but a preemption request could happen for both cases. And destroying of
a domain could also consume long time and so not to block hypervisor if something
more urgent should be handled it could be also have this check for the case of
freeng pages back to the buddy allocator.

~ Oleksii

    
  


--------------S4txwQopjWVzSFoXxOBkm2ib--


From xen-devel-bounces@lists.xenproject.org Fri May 23 10:48:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 10:48:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995570.1377904 (Exim 4.92)
	(envelope-from )
	id 1uIPxH-0007sD-3a; Fri, 23 May 2025 10:48:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995570.1377904; Fri, 23 May 2025 10: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 1uIPxG-0007rf-Vm; Fri, 23 May 2025 10:48:46 +0000
Received: by outflank-mailman (input) for mailman id 995570;
 Fri, 23 May 2025 10:48:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIPxF-0007rZ-PN
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 10:48:45 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7f4f0025-37c3-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 12:48:44 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad56cbc7b07so797422166b.0
 for ; Fri, 23 May 2025 03:48:44 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d06df95sm1224891966b.56.2025.05.23.03.48.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 23 May 2025 03:48: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" 
X-Inumbo-ID: 7f4f0025-37c3-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747997324; x=1748602124; darn=lists.xenproject.org;
        h=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;
        bh=+A1cJGqWgP5bAJfb8biQqWtC6WRG6IS7NoQbEdLXSgE=;
        b=DXtO3TmSNmeJVSz3wkxVuY/UD/sIu1mCkx5mpzMdgJgeEK1IZz4KeTELRBlOkFqDa7
         L9Rcjw5Iv8XeLI0z7Ch9rhcmUimg61dvZDWi5oiLEBgdisAk/N6u/C1oTgbsn4UC3W2y
         lRfyM4TSo/6hBlakmakjT/sDosi5QPkM98c1guPguC6nxEV3KaxvKIFefi6hhonUEa2v
         l4AAtS081hXF6Hn0QIGLVD1QjC8AudOXBqPlX67/QEGlGQrjiETlyDU8rgJZTnoe21yi
         9eVrgBXCrKEVlKmXaL8v7uUn/q3/WeamU5LGIEF4rsewFFftlf3F53UMd8FXX/zeN0MY
         K4Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747997324; x=1748602124;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=+A1cJGqWgP5bAJfb8biQqWtC6WRG6IS7NoQbEdLXSgE=;
        b=Wt9sxLSuuapGFqteCFso28V/1o9TnZbJb5MNUMnGhNsDv+TceyAJ4DhVF3eb0CjGAO
         VJwRc+OA6N5ABZOgtIDIvxpweV/nDCE/hQ/emLI+HPYpRy8uT1wDX/9NgczuL8ebVJcQ
         27yzYR23hbhY7d8w6pVyvvS3x9LT9dAbobsuX0JIspiTxdzYs4qjIn8PLGm3lthDqIFv
         Utt0/c0xWtpR2f4vOTFYogZdwHGuSlPjpm8NLZmdJWEUXWtQ/yFb+f803gGhyg1rff/G
         7K55lvCYTH299gjiqHhZZIbRiuCwVMFgmIBATujk+qUX/4eUYX9qZ4iPn38dMVAQk9vy
         4KAg==
X-Forwarded-Encrypted: i=1; AJvYcCXiC32qooWP1nbH2bltmw6FUNUL5KAk/XGxe0BxPdiF7YMmkkRk6QyikIN+UWc5pdl33vofKhI862U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxYj6+4P48b3a06ADUQ79RjRQjCbXsyal02Um/lWKmP9pBUex2M
	WxpQbP9WXmqzlnr6GTl1WfOf3OZKO85Cw8XVU/UEhNQbDywUVFbyjvaZ
X-Gm-Gg: ASbGncscTm9R72C2TQ8tQYEClSy9yvNZ2acg0kD4YyTKiGg4v3r02ROH8AFRXBqE9eh
	3o5vVa+DyDp7Nmk1B9CswtXS2sFJtQbAw+gdoZm1rY4818gaOAzEB5Y3iWQavfacFwt/sWaYMZl
	orLixe8Skz6K5JvowSTwnmmugudM5CnanMfH6ZnrsnfohIKihvl19mJbE1FedCfD+ujDfOO+S/m
	1X5jZA91hEyg2BLVgWOTXVfuNXZBbeUUSlV2NuH2vnG84g5DHE3uhPCEw5mUJFOZvj6dJK12jz3
	4N/qlQhuFWzVtpPz6nAFyCafZFMU7srXg9Qr7aM0U/Q4eWUXDgc+OQ1T7Pi7yg59SJK0wjYQ/ip
	K79fCNJHT0H98EsqKjurYxnC+0LxauqjeLNo=
X-Google-Smtp-Source: AGHT+IF73ODRYeUHr6WPb8eNaBmOWS3qpC7GDp+naTBEA1yis6bD5H+jD2V+qwQjNnXO9Sx4O51k0w==
X-Received: by 2002:a17:907:cd0e:b0:ad2:1b0e:bfe5 with SMTP id a640c23a62f3a-ad708387de3mr248074266b.7.1747997323893;
        Fri, 23 May 2025 03:48:43 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------QCDiYtWx5Vc5VkJ7z2UP5fLh"
Message-ID: <5e17710a-cac3-409d-99fd-454d836ed3a8@gmail.com>
Date: Fri, 23 May 2025 12:48:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 4/6] xen/riscv: define pt_t and pt_walk_t structures
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <9f822cfaa058167982c85b3ca3f722881552a75e.1746805907.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------QCDiYtWx5Vc5VkJ7z2UP5fLh
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/20/25 5:04 PM, Jan Beulich wrote:
> On 09.05.2025 17:57, Oleksii Kurochko wrote:
>> Refactor pte_t to be a union which hold page table entry plus
>> pt_t and pt_walk_t structures to simpilfy p2m functions.
> Is this really simplifying things? I really view ...
>
>> Also, introduce some helpers which are using pt_walk_t.
> ... these helpers as confusing things, by using the wrong part of the
> union relative to what their names are. (I'll re-phrase this some at
> the bottom.)
>
> With the union it's also unclear to me how to know which part of the
> union is the one that's valid to use, when there's no auxiliary info
> available.

Everything is valid to use and depends on the context if it is convenient
or not. It is hard to come up with a rule when and what should be used.

>
>> --- a/xen/arch/riscv/include/asm/page.h
>> +++ b/xen/arch/riscv/include/asm/page.h
>> @@ -99,15 +99,67 @@
>>   
>>   #endif
>>   
>> -/* Page Table entry */
>>   typedef struct {
>> +    unsigned long v:1;
>> +    unsigned long r:1;
>> +    unsigned long w:1;
>> +    unsigned long x:1;
>> +    unsigned long u:1;
>> +    unsigned long g:1;
>> +    unsigned long a:1;
>> +    unsigned long d:1;
>> +    unsigned long rsw:2;
>> +#if RV_STAGE1_MODE == SATP_MODE_SV39
>> +    unsigned long ppn0:9;
>> +    unsigned long ppn1:9;
>> +    unsigned long ppn2:26;
>> +    unsigned long rsw2:7;
>> +    unsigned long pbmt:2;
>> +    unsigned long n:1;
>> +#elif RV_STAGE1_MODE == SATP_MODE_SV48
>> +    unsigned long ppn0:9;
>> +    unsigned long ppn1:9;
>> +    unsigned long ppn2:9;
>> +    unsigned long ppn3:17;
>> +    unsigned long rsw2:7;
>> +    unsigned long pbmt:2;
>> +    unsigned long n:1;
>> +#else
> Imo you want to settle on whether you want to use bitfields or #define-s
> to manipulate page table entries. Using a mix is going to be confusing
> (or worse).

Generally, I am okay to use something one.
But technically it is the same things from result point of view, just
different is access of a field by using a union or do a bit manipulation operations.

>
>> +#error "Add proper bits for SATP_MODE"
>> +#endif
>> +} pt_t;
>> +
>> +typedef struct {
>> +    unsigned long rsw:10;
>> +#if RV_STAGE1_MODE == SATP_MODE_SV39 || RV_STAGE1_MODE == SATP_MODE_SV48
>> +    unsigned long ppn: 44;
> Nit: Why's there a blank after the colon here when there's none anywhere else?
>
>> +static inline void pte_set_mfn(pte_t *pte, mfn_t mfn)
>> +{
>> +    pte->walk.ppn = mfn_x(mfn);
>> +}
>> +
>> +static inline mfn_t pte_get_mfn(pte_t pte)
>> +{
>> +    return _mfn(pte.walk.ppn);
>> +}
> Following to my remark at the top - if you do it this way, what use are the
> ppn fields?

|ppn| isn't actually used; it was added only to follow the PTE format specified
in the architecture spec. Technically,|ppn| could be merged into|ppn|,
but IMO, keeping|ppn| improves self-documentation of the page table format.

~ Oleksii

--------------QCDiYtWx5Vc5VkJ7z2UP5fLh
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/20/25 5:04 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 09.05.2025 17:57, Oleksii Kurochko wrote:

    
      
    
        
    Refactor pte_t to be a union which hold page table entry plus
pt_t and pt_walk_t structures to simpilfy p2m functions.

    
      
    
      
    Is this really simplifying things? I really view ...


    
      
    
        
    Also, introduce some helpers which are using pt_walk_t.

    
      
    
      
    ... these helpers as confusing things, by using the wrong part of the
union relative to what their names are. (I'll re-phrase this some at
the bottom.)

With the union it's also unclear to me how to know which part of the
union is the one that's valid to use, when there's no auxiliary info
available.
    
    
    
    
    Everything is valid to use and depends on the context if it is convenient
or not. It is hard to come up with a rule when and what should be used.


    
    
    
      
    

    
      
    
        
    --- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -99,15 +99,67 @@
 
 #endif
 
-/* Page Table entry */
 typedef struct {
+    unsigned long v:1;
+    unsigned long r:1;
+    unsigned long w:1;
+    unsigned long x:1;
+    unsigned long u:1;
+    unsigned long g:1;
+    unsigned long a:1;
+    unsigned long d:1;
+    unsigned long rsw:2;
+#if RV_STAGE1_MODE == SATP_MODE_SV39
+    unsigned long ppn0:9;
+    unsigned long ppn1:9;
+    unsigned long ppn2:26;
+    unsigned long rsw2:7;
+    unsigned long pbmt:2;
+    unsigned long n:1;
+#elif RV_STAGE1_MODE == SATP_MODE_SV48
+    unsigned long ppn0:9;
+    unsigned long ppn1:9;
+    unsigned long ppn2:9;
+    unsigned long ppn3:17;
+    unsigned long rsw2:7;
+    unsigned long pbmt:2;
+    unsigned long n:1;
+#else

    
      
    
      
    Imo you want to settle on whether you want to use bitfields or #define-s
to manipulate page table entries. Using a mix is going to be confusing
(or worse).
    
    
    
    
    Generally, I am okay to use something one.
But technically it is the same things from result point of view, just
different is access of a field by using a union or do a bit manipulation operations.


    
    
    
      
    

    
      
    
        
    +#error "Add proper bits for SATP_MODE"
+#endif
+} pt_t;
+
+typedef struct {
+    unsigned long rsw:10;
+#if RV_STAGE1_MODE == SATP_MODE_SV39 || RV_STAGE1_MODE == SATP_MODE_SV48
+    unsigned long ppn: 44;

    
      
    
      
    Nit: Why's there a blank after the colon here when there's none anywhere else?


    
      
    
        
    +static inline void pte_set_mfn(pte_t *pte, mfn_t mfn)
+{
+    pte->walk.ppn = mfn_x(mfn);
+}
+
+static inline mfn_t pte_get_mfn(pte_t pte)
+{
+    return _mfn(pte.walk.ppn);
+}

    
      
    
      
    Following to my remark at the top - if you do it this way, what use are the
ppn<N> fields?
    
    
    
    
    ppn<N> isn't actually used; it was added only to follow the PTE format specified
in the architecture spec. Technically, ppn<N> could be merged into ppn,
but IMO, keeping ppn<N> improves self-documentation of the page table format.

~ Oleksii

    
  


--------------QCDiYtWx5Vc5VkJ7z2UP5fLh--


From xen-devel-bounces@lists.xenproject.org Fri May 23 11:14:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 11:14:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995622.1377914 (Exim 4.92)
	(envelope-from )
	id 1uIQME-0003dv-0G; Fri, 23 May 2025 11:14:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995622.1377914; Fri, 23 May 2025 11: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 1uIQMD-0003do-TQ; Fri, 23 May 2025 11:14:33 +0000
Received: by outflank-mailman (input) for mailman id 995622;
 Fri, 23 May 2025 11:14:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIQMB-0003di-Dn
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 11:14:31 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 14100e4d-37c7-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 13:14:28 +0200 (CEST)
Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252]
 helo=noisy.programming.kicks-ass.net)
 by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux))
 id 1uIQLx-00000007VFJ-22r2; Fri, 23 May 2025 11:14:17 +0000
Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000)
 id 10E13300583; Fri, 23 May 2025 13:14:17 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 14100e4d-37c7-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=qFE8tg2hkqL/QDMRDxBmyrXVviTv054S7EmAHGK1Cu8=; b=VTm6YpXt+rg+boo/Y2XlDLHfjF
	uTUdFDuv7CRduVt0vgcpt1H3qXyWcKOUKwBJyBzjyRnEO9SE7JRpGZOhTfBBSEBXLgYIEYKbXlZDB
	tpsVGBoReZXjDVnjHYqsbdp3l9lenZI0uN4sGBmjoTHFC/oSTcCk06BRBBvKukbRvtHnIoQOohxFp
	AAk2xVkEy/ZUzR6Fa5IR24TYqZXrrQUCbpTsXVqK4NnKuLMx7BbaRzGqb7TLhfaz4cV5tvbk6Bwys
	vuAtkKS5Ar3GY61i/vpDcdclGEPpTbtP7i+0lOv6wFveWet/d/4Gtx0J7aORLDJMVameaAuX32RZ0
	m/g+9Shg==;
Date: Fri, 23 May 2025 13:14:16 +0200
From: Peter Zijlstra 
To: Sean Christopherson 
Cc: "K. Y. Srinivasan" ,
	Haiyang Zhang ,
	Wei Liu , Dexuan Cui ,
	Juergen Gross ,
	Stefano Stabellini ,
	Paolo Bonzini , Ingo Molnar ,
	Juri Lelli ,
	Vincent Guittot ,
	Shuah Khan , Marc Zyngier ,
	Oliver Upton , linux-kernel@vger.kernel.org,
	linux-hyperv@vger.kernel.org, xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	K Prateek Nayak ,
	David Matlack 
Subject: Re: [PATCH v3 00/13] KVM: Make irqfd registration globally unique
Message-ID: <20250523111416.GJ39944@noisy.programming.kicks-ass.net>
References: <20250522235223.3178519-1-seanjc@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>

On Thu, May 22, 2025 at 04:52:10PM -0700, Sean Christopherson wrote:
>   sched/wait: Drop WQ_FLAG_EXCLUSIVE from add_wait_queue_priority()
>   sched/wait: Add a waitqueue helper for fully exclusive priority
>     waiters

Acked-by: Peter Zijlstra (Intel) 


From xen-devel-bounces@lists.xenproject.org Fri May 23 11:35:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 11:35:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995639.1377923 (Exim 4.92)
	(envelope-from )
	id 1uIQg2-0006Wi-JT; Fri, 23 May 2025 11:35:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995639.1377923; Fri, 23 May 2025 11:35: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 1uIQg2-0006Wb-Gw; Fri, 23 May 2025 11:35:02 +0000
Received: by outflank-mailman (input) for mailman id 995639;
 Fri, 23 May 2025 11:35:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIQg1-0006WV-FX
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 11:35:01 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f5532836-37c9-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 13:34:59 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad5297704aaso1530101866b.2
 for ; Fri, 23 May 2025 04:34:59 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d4420ccsm1197136366b.110.2025.05.23.04.34.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 23 May 2025 04:34: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" 
X-Inumbo-ID: f5532836-37c9-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748000099; x=1748604899; darn=lists.xenproject.org;
        h=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;
        bh=m/B3enXGVCVlxeacnZp2rSb6m1gRv4OfVjhKViwqA/U=;
        b=WeHcmB9Bk4OzWzib8+V0aC58FdMyJ0ThpKcySCWfG39FNDkJvcxEhfzHK6XPGALraD
         EhBc3bpHyyltaC+w6Kn4bmvejr+Aee12Pn2iAiokpvcZeSprvsxVJq3Qn9CdJgRkC5ur
         582/f0jHhM44XYYLZ2kR5Fmvgv1AsQiXJgZLKElJaWQwQ2Mxkpgzdzol2UMYB2WXVJJF
         i7SgQKBfIebxxmVGf9WDU1NgekWeHqXYXOIC5bbKubOU/iuRwwX815SO+y0sib0IDU+0
         C5+9nJPuxoFcCRgGYnryXKZa3XtLNXZa064vSuWUjdvT262vyGffb2QSuDg0WyU+D0OA
         CkGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748000099; x=1748604899;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=m/B3enXGVCVlxeacnZp2rSb6m1gRv4OfVjhKViwqA/U=;
        b=UsqMZV30E4ImfeVyUCjMMWxAFNfPw1u/14FDmTSvStUHselYE7GnjN1vSMzU+OLueD
         64VeDqD5e8GmItILMNgIibJLk7LlDfEbAU+rvqpJrvtrU/OTXXcKFenmRSbkKdDHvPib
         mMXDSeoKNkLT8xFC7BTR6tU+lqXxqCNZtEEWe60OpWclg+u7RIsInrOUF54GCVIw/YBb
         kfqUlVvovU+x0wmnQbuyjFFNoGBTXa7LyZ0uQLmXUk7HJNnNZWSJwVPBO0TSV8z9Xb+U
         nW5Oth/GN0zsgyO8iuH/xmFB84Dwv+QMG+wUi3Yzm1plPj5wBM1hT64PeMhXvwJrs2oz
         PHfg==
X-Forwarded-Encrypted: i=1; AJvYcCVdc89/9jaYp3r6MW6YxxvP3u3/SJg/zbBxoizD4xNzD+mNNR9xpytgsmZHpGlFVE7Cmnu+UGdOmIE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz7mkkczmak2DICxgW3B1HMKWsNeE3U+/DiExQDV24bbfiuKAnQ
	YALLJAzcL9gCnG65GxJu8vZFAaBy0fpvdP6p3+kWnwulqW03t/DTUEys
X-Gm-Gg: ASbGncucrNO0hCHsSkmUD4jF4+cBCHlPdMpEtKXHBwqmGz8wr20fTDT3lmYBClFain2
	Xkk3q2J7Op6MIoPxz51KD1yPMnNc82gKZaDEhHnI0y4m5QuOSlWVDRTNPZ+neoXN8M46RjHbs0c
	2W8gc3zRyvB+jiKy9N2uk8lgmjQlJoCmYrEuhiYRTimXE/InCM9VJPxCcKTPE33UNItbur3uXzu
	GDNznl6wDpK5zP2Z+AIMTnAtL3an7qMVQYNwuL6gF2xRZriTOg9/NAyTZYH8Jt0kolz1scuFXvX
	EfqtKP/7s/m3e4j+l9sHt6uGMJFlrLrgD/0OhySLXqEdz//m4NzDQEP3SPL3EUVzL8NKQeqNGY+
	uFURpmjX18qT3QXUqblj6IGAhvIM1zwi8sIo=
X-Google-Smtp-Source: AGHT+IGHggtOf2c5gJg+CfrPL62I+mF8eF+SUMqk7FJZdqFlNKhxg8kkplPwJeNoFjsoI6q7nmDbew==
X-Received: by 2002:a17:907:97c6:b0:abf:7453:1f1a with SMTP id a640c23a62f3a-ad52d5174e6mr2725320066b.36.1748000098682;
        Fri, 23 May 2025 04:34:58 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------A8TRKA4dtCKZX41CdgjuMFbv"
Message-ID: 
Date: Fri, 23 May 2025 13:34:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 5/6] xen/riscv: add new p2m types and helper macros for
 type classification
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <52861198c7c363c4b0caf818345f4ffbec056337.1746805907.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------A8TRKA4dtCKZX41CdgjuMFbv
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/20/25 5:11 PM, Jan Beulich wrote:
> On 09.05.2025 17:57, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/include/asm/p2m.h
>> +++ b/xen/arch/riscv/include/asm/p2m.h
>> @@ -80,8 +80,36 @@ struct p2m_domain {
>>   typedef enum {
>>       p2m_invalid = 0,    /* Nothing mapped here */
>>       p2m_ram_rw,         /* Normal read/write domain RAM */
>> +    p2m_ram_ro,         /* Read-only; writes are silently dropped */
> This is pretty special a type, which imo better wouldn't be introduced
> without there being proper support for it. (I don't suppose RISC-V
> hardware alone can effect this type?)

It is possible to make ro by using r, w, x bits of page table entry in the
same way Arm does that:
     case p2m_ram_ro:
         e->p2m.xn = 0;
         e->p2m.write = 0;
         break;

>
>> +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
>> +    p2m_map_foreign_rw, /* Read/write RAM pages from foreign domain */
>> +    p2m_map_foreign_ro, /* Read-only RAM pages from foreign domain */
> Aiui you took these from Arm. Looking at its sole use, I'm not convinced
> it's used correctly. If it is, the same comment as for p2m_ram_ro above
> would apply here, too.

p2m_mmio_direct_dev - this one is defintely needed as it is used for device
pass through to guest domain to map device's MMIO. It seems to me like it is
correctly used.

Others we don't really use now in private branches but it seems like they could be
useful, so I added them now.

I can drop them now and return back if such functionality which uses them will be
introduced for RISC-V, and at that moment I think it will be
more clear if it is used correctly or not.
Right now, I am not sure if it is.

~ Oleksii


--------------A8TRKA4dtCKZX41CdgjuMFbv
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/20/25 5:11 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 09.05.2025 17:57, Oleksii Kurochko wrote:

    
      
    
        
    --- a/xen/arch/riscv/include/asm/p2m.h
+++ b/xen/arch/riscv/include/asm/p2m.h
@@ -80,8 +80,36 @@ struct p2m_domain {
 typedef enum {
     p2m_invalid = 0,    /* Nothing mapped here */
     p2m_ram_rw,         /* Normal read/write domain RAM */
+    p2m_ram_ro,         /* Read-only; writes are silently dropped */

    
      
    
      
    This is pretty special a type, which imo better wouldn't be introduced
without there being proper support for it. (I don't suppose RISC-V
hardware alone can effect this type?)
    
    
    
    
    It is possible to make ro by using r, w, x bits of page table entry in the
same way Arm does that:
    case p2m_ram_ro:
        e->p2m.xn = 0;
        e->p2m.write = 0;
        break;


    
    
    
      
    

    
      
    
        
    +    p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
+    p2m_map_foreign_rw, /* Read/write RAM pages from foreign domain */
+    p2m_map_foreign_ro, /* Read-only RAM pages from foreign domain */

    
      
    
      
    Aiui you took these from Arm. Looking at its sole use, I'm not convinced
it's used correctly. If it is, the same comment as for p2m_ram_ro above
would apply here, too.
    
    
    
    
    p2m_mmio_direct_dev - this one is defintely needed as it is used for device
pass through to guest domain to map device's MMIO. It seems to me like it is
correctly used.

Others we don't really use now in private branches but it seems like they could be
useful, so I added them now.

I can drop them now and return back if such functionality which uses them will be
introduced for RISC-V, and at that moment I think it will be
more clear if it is used correctly or not.
Right now, I am not sure if it is.

~ Oleksii



    
  


--------------A8TRKA4dtCKZX41CdgjuMFbv--


From xen-devel-bounces@lists.xenproject.org Fri May 23 11:48:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 11:48:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995661.1377934 (Exim 4.92)
	(envelope-from )
	id 1uIQsX-0008Jl-Mz; Fri, 23 May 2025 11:47:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995661.1377934; Fri, 23 May 2025 11:47: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 1uIQsX-0008Je-K0; Fri, 23 May 2025 11:47:57 +0000
Received: by outflank-mailman (input) for mailman id 995661;
 Fri, 23 May 2025 11:47:56 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIQsW-0008JY-AP
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 11:47:56 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c23b1cf7-37cb-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 13:47:52 +0200 (CEST)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-3105ef2a08dso81711781fa.0
 for ; Fri, 23 May 2025 04:47:52 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-328084caa90sm35702521fa.43.2025.05.23.04.47.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 23 May 2025 04:47: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" 
X-Inumbo-ID: c23b1cf7-37cb-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748000872; x=1748605672; darn=lists.xenproject.org;
        h=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;
        bh=c6GYp5639k1wRrhYrb3T+vDFQxM4wMPkfHBk6H9Ink0=;
        b=D0Ok5Eh2naTBnZzcakFItsJg9F4UmSnU36raTgll140EAdfBJq6Z2jX6JVlPH7u4Un
         rpItsdS/7X9I1Q6aS/zrIZBKM8BPy2b1e0N4qf5xU6T/zgo1VXIqL0/LMljgAA32NKSK
         CZSXOvECbxpUlDwPsHmhBFj5praabHfFtY0v/IYqbVzNkCCASak3JSXOjj3ubFYZhBgB
         JHoPUIgaAZEb2THiXQ9T7Nydvtidlo4R/u8LS7lT2ll5+RNEmTrR2rJ/Wd/oSvx9z7Hs
         Jw3Aoed6z1YLLzTp8OH+fIXCEdGni8+0z2mQl+xil9s4k+ySaWlQ0brWbunb6z3nEXpk
         BXew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748000872; x=1748605672;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=c6GYp5639k1wRrhYrb3T+vDFQxM4wMPkfHBk6H9Ink0=;
        b=syp9FBj/LdjACx4k4wc52PvP2PGcm2LKGU5WQLX32IMyjf/Dlk0KqcB96FMy+BKTbz
         4+2pQuDrMwD6rAIhnXxv+xQBCItOu4K6KocPszesVXxaeSfWnKcieThzz7WBAKG8HUrw
         wIKbMf4/BiuDI4+sjmGeOJTZke/T7oFqSIqqArrnda3zmaxlrKrscRNuKXXjUKKCngJY
         R8FPkGTEF/mmj9Kr273jRR9BsCQC5DVzsVWrQT6oQCYSEAt1dFDWnh/b6aBvWZh/4sOB
         8M4XsMmn5DogwqNM1wfTvdJSIMCNzreWjNaIvdUQP6tkfUjHtguGZi3ICK5GM1Iz7XgE
         QG8w==
X-Forwarded-Encrypted: i=1; AJvYcCVEx1RhCqPeFSWLdibXvkhlEWerbJ4kQ8ORn5wPIjM2PywLKcs7LJ71NibiMiajEpei3+SFGasqT+M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxFms5ms8FwaWfF/U7zA1WdrB71moB8GYOvq9vcX2kJOiJpm8Rk
	mM2TdZZQdfK1fGenFkuJm9vfDSUqUfs58b219k55NidX5WxmpwE1fz7Q
X-Gm-Gg: ASbGncuYlEvIRBNWa6uN7qv3OPYrMBvKfSDFlaEITRY9ZrAPas9XGYUIVhPGsHOJRPS
	YqkxSAFL9j9l6bXuMQUckr4C2Ud/rn6f+r8bJqRFR9LzukbYVqYKiyJepPThRzsZ1v4gx4y7Asv
	2O+UnG4hytEYu/FaE8vhtHuZt5elnoeitPWEE2ix5zXBbYo/BYXJwiotdDD+KO9H6fOE2q1PtY/
	r+x5LffurO+9v9+nojtHE7wgYqZPM1HoHCP0KSmMiK81wYp/abvU8BsDvhykcwyhSM9LCfpRlIg
	HVmEOFHjqvE5Iv7aGy/NRxB99CwxAzRDV6+dWpGxmrphjxMOl9bFMNE35UafUg7dh+E4BwtqOwZ
	5Sj6V3eRsEXpwOH2X3OyUIiRJWAP/GOXAgMA=
X-Google-Smtp-Source: AGHT+IG19HrYp4DTtFLsYl8KAJfQ1k6OQaPVubRcmjzn2rNzWs/LFdBxiFj/dHZQ+8veSym8KOv6hA==
X-Received: by 2002:a2e:ae10:0:b0:328:d9f:5ae7 with SMTP id 38308e7fff4ca-32950b95cffmr5897261fa.23.1748000871636;
        Fri, 23 May 2025 04:47:51 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------CzanOoIozGJjy35Mu0ppKWop"
Message-ID: 
Date: Fri, 23 May 2025 13:47:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 6/6] xen/riscv: implement p2m mapping functionality
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 
 <701620bf-b76f-4f21-8703-4a6d172eb812@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <701620bf-b76f-4f21-8703-4a6d172eb812@suse.com>

This is a multi-part message in MIME format.
--------------CzanOoIozGJjy35Mu0ppKWop
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/20/25 5:16 PM, Jan Beulich wrote:
> On 09.05.2025 17:57, Oleksii Kurochko wrote:
>> These utilities are needed for building and managing RISC-V guest page
>> tables and MMIO mappings by using functions map_regions_p2mt() and
>> guest_physmap_add_entry().
>>
>> To implement p2m mapping functionality the following is introduced:
>> - Define P2M root level/order and entry count.
>> - Introdude radix type for p2m types as it isn't enough free bits in pte
>>    and the helpers (p2m_type_radix_{get,set}()) to deal with them.
>> - Introduce p2m_is_*() helpers() as  pte_is_*() helpers are checking
>>    the valid bit set in the PTE but we have to check p2m_type instead
>>    (look at the comment above p2m_is_valid() for some details).
> May I suggest to name them at least p2me_is_*() then, as they check entries
> rather than entire P2Ms? Same perhaps elsewhere.

Sure, I will handle that during a work on v2.

>
>> - Introduce helper to set p2m's pte permission: p2m_set_permissions().
>> - Introduce helper to create p2m entry based on mfn, p2m_type_t and
>>    p2m_access_t.
>> - Introduce helper to generate table entry with correct attributes:
>>    page_to_p2m_table().
>> - Introduce p2m page allocation function: p2m_alloc_page().
>> - Introduce functions to write/remove p2m's entries: p2m_{write,remove}_pte().
>> - Introduce function to allocate p2m table: p2m_create_table().
>> - Introduce functions used to free p2m entry.
>> - Introduce function for table walking: p2m_next_level().
>> - Introduce function to insert an entry in the p2m (p2m_set_entry()).
>> - Introduce superpage splitting: p2m_split_superpage()).
>> - Introduce page table type defines (PGT_{none,writable_page}, etc).
>>
>> Signed-off-by: Oleksii Kurochko
>> ---
>>   xen/arch/riscv/include/asm/mm.h   |  32 +-
>>   xen/arch/riscv/include/asm/p2m.h  |  17 +-
>>   xen/arch/riscv/include/asm/page.h |  11 +
>>   xen/arch/riscv/p2m.c              | 780 ++++++++++++++++++++++++++++++
>>   4 files changed, 829 insertions(+), 11 deletions(-)
> It's imo too many things you do in one go here.

I will split to smaller patches.

Thanks.

~ Oleksii


--------------CzanOoIozGJjy35Mu0ppKWop
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/20/25 5:16 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 09.05.2025 17:57, Oleksii Kurochko wrote:

    
      
    
        
    These utilities are needed for building and managing RISC-V guest page
tables and MMIO mappings by using functions map_regions_p2mt() and
guest_physmap_add_entry().

To implement p2m mapping functionality the following is introduced:
- Define P2M root level/order and entry count.
- Introdude radix type for p2m types as it isn't enough free bits in pte
  and the helpers (p2m_type_radix_{get,set}()) to deal with them.
- Introduce p2m_is_*() helpers() as  pte_is_*() helpers are checking
  the valid bit set in the PTE but we have to check p2m_type instead
  (look at the comment above p2m_is_valid() for some details).

    
      
    
      
    May I suggest to name them at least p2me_is_*() then, as they check entries
rather than entire P2Ms? Same perhaps elsewhere.
    
    
    
    
    Sure, I will handle that during a work on v2.


    
    
    
      
    

    
      
    
        
    - Introduce helper to set p2m's pte permission: p2m_set_permissions().
- Introduce helper to create p2m entry based on mfn, p2m_type_t and
  p2m_access_t.
- Introduce helper to generate table entry with correct attributes:
  page_to_p2m_table().
- Introduce p2m page allocation function: p2m_alloc_page().
- Introduce functions to write/remove p2m's entries: p2m_{write,remove}_pte().
- Introduce function to allocate p2m table: p2m_create_table().
- Introduce functions used to free p2m entry.
- Introduce function for table walking: p2m_next_level().
- Introduce function to insert an entry in the p2m (p2m_set_entry()).
- Introduce superpage splitting: p2m_split_superpage()).
- Introduce page table type defines (PGT_{none,writable_page}, etc).

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/riscv/include/asm/mm.h   |  32 +-
 xen/arch/riscv/include/asm/p2m.h  |  17 +-
 xen/arch/riscv/include/asm/page.h |  11 +
 xen/arch/riscv/p2m.c              | 780 ++++++++++++++++++++++++++++++
 4 files changed, 829 insertions(+), 11 deletions(-)

    
      
    
      
    It's imo too many things you do in one go here.
    
    
    
    
    I will split to smaller patches.

Thanks.

~ Oleksii
    
    
    
  


--------------CzanOoIozGJjy35Mu0ppKWop--


From xen-devel-bounces@lists.xenproject.org Fri May 23 12:46:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 12:46:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995702.1377944 (Exim 4.92)
	(envelope-from )
	id 1uIRnN-0007b5-42; Fri, 23 May 2025 12:46:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995702.1377944; Fri, 23 May 2025 12:46: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 1uIRnN-0007ay-18; Fri, 23 May 2025 12:46:41 +0000
Received: by outflank-mailman (input) for mailman id 995702;
 Fri, 23 May 2025 12:46:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIRnL-0007as-97
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 12:46:39 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f4ec0d76-37d3-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 14:46:33 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-442f9043f56so53346355e9.0
 for ; Fri, 23 May 2025 05:46:33 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f6f0554fsm138195795e9.9.2025.05.23.05.46.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 23 May 2025 05:46: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" 
X-Inumbo-ID: f4ec0d76-37d3-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748004393; x=1748609193; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KcdT1Ulu68Zz2c66rwWlTA83N4IJSTMfY3EqHrN6onE=;
        b=ujre3UJW6DX5pnNKtFPKwW9aEbuMjz55nt6s1b6UoCj8KH7tTT0Vqu9zKbAjc+zid2
         KGSvoWMa7J2rJc8swBS6aNbyx5fKw7I7PjtMfPMUIh99oX0ETQVyATKcfS+qkdK1VfON
         uXmjPWc3YwmqfADdiiEcgr68m3UdKj9CCjl+s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748004393; x=1748609193;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KcdT1Ulu68Zz2c66rwWlTA83N4IJSTMfY3EqHrN6onE=;
        b=q7WTWQF9pLFJNi25VuLsJHvwD+BXrNTja1P/9u8z6Gx1zo9c8Hlizd6/TsEKE+DEvx
         heTIFCwYqt6QhHYDlQCrCS/35J6BbYfArMRws63QrLsmtc61lhg5S5ozjDbWmh32Pve6
         urrEShCpZ1qFr1z0Xdblwa4iqKCt2DKUpRP/1fu+zgI8g+ggfjDtGsWnqez+bVcosHyS
         /pAbUQJ+F58JEwcBT8EQS6S5w/3y8ABqQ/XS7bVc47cUk0fjOUJrPzgv+amiuJ1Oqg/W
         +Q/B72mtpuZ1UEw29g+O1MCcC7z/iY4sX9hITSbQ+mjcVjRY5QgnxHCkIS1i67hDmA1m
         e8Zg==
X-Forwarded-Encrypted: i=1; AJvYcCXmYxDwYrsln3MKO91AC1y28choUCoezIPMQPj/E0cgLFErDMMzWmoOKXbDv2NjPdjIoXep/Pq6yYY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyDrMjwLblDN/Zahef8TlrLHXaJnjKqA10QwId+3oUGdc6g5F++
	iTMHPDc8ugQcC6NCVNkT9tIO72ziZ6/nXMRepumSTmbe1bC4wyUvpFMOXCRxT8OaFAE=
X-Gm-Gg: ASbGncsLh4UNBDVnlsKMbHNZAwVTUFv0P8VB2kGER/RLMbJxDLkG/vBwrfiNU6kjXe2
	O8PXlcqqfSWal2D2VVLB/QRnEDWtFFfi5a5o5gEPdn4AqFVkax2qj7Yexo5FYZelyizfQr6JQxt
	CXwPDV12EWQQtZJBkbci6nUVG/JsBT1bQWp4+uhJymG/TDzCYoEYPGnxBWSVA+czEZRHA8Il/KG
	chNZYy2uflDU/iPwfaqdTwoQxyF36YWF/B9FOp4gjLu72LuHYaTwl/6FkjHkTIX8ydnz5i7ZMJL
	cOGzFh4i8cUEl28RiJ8jJb2Zu3/oKbvB/tK/NwYxJse2ZEsv6Z6N/JAAD+kMqoANzWgVxFonN0B
	MPCH07FZ7kTLisyTv
X-Google-Smtp-Source: AGHT+IF79mOdDEdvF75j4e/cR13n5aGSqSj/s3La+i2e7z1n+BDC5AnjNIpCFq+joRM1S8KLAgdlMQ==
X-Received: by 2002:a05:600c:4e15:b0:44b:1f5b:8c85 with SMTP id 5b1f17b1804b1-44b6d2cc557mr40883075e9.13.1748004393091;
        Fri, 23 May 2025 05:46:33 -0700 (PDT)
Message-ID: <014e27ab-4262-4821-bd1e-8d9ad9d745d2@citrix.com>
Date: Fri, 23 May 2025 13:46:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/3] x86/boot: print CPU and APIC ID in bring up
 failure
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich 
References: <20250523082135.18088-1-roger.pau@citrix.com>
 <20250523082135.18088-2-roger.pau@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: <20250523082135.18088-2-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23/05/2025 9:21 am, Roger Pau Monne wrote:
> Print the CPU and APIC ID that fails to respond to the init sequence, or
> that didn't manage to reach the "callin" state.  Expand a bit the printed
> error messages.  Otherwise the "Not responding." message is not easy to
> understand by users.
>
> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Fri May 23 12:49:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 12:49:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995708.1377954 (Exim 4.92)
	(envelope-from )
	id 1uIRpy-00087E-HH; Fri, 23 May 2025 12:49:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995708.1377954; Fri, 23 May 2025 12:49: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 1uIRpy-000877-EL; Fri, 23 May 2025 12:49:22 +0000
Received: by outflank-mailman (input) for mailman id 995708;
 Fri, 23 May 2025 12:49:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIRpy-000871-33
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 12:49:22 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 58da08f2-37d4-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 14:49:21 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5efe8d9ebdfso17086941a12.3
 for ; Fri, 23 May 2025 05:49:21 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6005ac33757sm11894907a12.59.2025.05.23.05.49.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 23 May 2025 05: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" 
X-Inumbo-ID: 58da08f2-37d4-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748004561; x=1748609361; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=9CVl9Kxzo6lE9JOiVku/hr4UIbWy7NMEmzAFYkSpUlE=;
        b=RBBinJxg3n+2uPxNikgM5YePQndgaFs1bcbZu4iQ051lqSO6EuxRjy3FOg3eG5bzjC
         bBZ+/kJlcPOF+WN0Y4cxw2kawui5v//h1crS7MhgV+HrJ61G6GlbmlxDRleqyEi7ytJ7
         GZsr4vS6iiqioUsKMhRmNkfJnRej9ppnflTqY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748004561; x=1748609361;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9CVl9Kxzo6lE9JOiVku/hr4UIbWy7NMEmzAFYkSpUlE=;
        b=f0Ug5OI7Wlg4++ZWZ458me2peK512U9SLkBg2wiPliLH1LC1aaNVNhQg4h8xoVshjX
         Y1EMxzAYFquEMPZh18etn0PYnFyXD74h8MpVEn8ujgV9/4K0auJIymcEn2sJF74tzAOw
         LPlG7yZOkkg1KDmKt3Vds8+gbaEyjyvWsHUDzOmzsyEso46i6D4P6kBtxTO6CJd5sngU
         SW0Fw3buzRbf50w2q9rOZcbObrQlqZNGCCMV8z/xGFY12AnZRFP+fFQxqE4cfBT6A7M8
         0KLpA5c89CfxshWRGDDd8JyGuirOyiR/nzEgcIKDuoLUN88tdooh//rsJyNhvWNYWT6p
         P6RQ==
X-Forwarded-Encrypted: i=1; AJvYcCXBWrrSWYxgPo5ljK21mxhVUGY++6Z70lZWO6haeYlotrUkGPrJT6SgXeP/Tb+HgOH7Ho307kHtsWU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwtrSHoJ5uJJt78ugQ1HPbB8O5Vplp7VqHDuCnsMY7IOjCPVWbf
	vVqP/Sc9pNjU6tMGUHxg6ypbqadYT3oICkxWxIyuuKLhDOtzXUapcmSO2Fwi2MLePPU=
X-Gm-Gg: ASbGnctroFW2pG+Y4A+qM0g0PaChhG1itSpOMvFdPi4yiXbyCoYtCJohMMXrIrn57v0
	Lt1JQI69l1QUL4wi7gMCWUN2tQd+cfXYzG5g00bnIsSe3xJHU7BsNOFwgiyrG9IB4BvpwkYYuHd
	S3FLK+I4u5+T+79Y9yxrdYKRgaQfOoIPKBzw9PXylRSrmtHrF1/7bluBwDMcScu8JWzdtJw2yXL
	nDT6IJJIG3nrqL6/6oYw7BMRNAU47DE45gkEUarE4rcXoXkP7yA2QNb0tJwx0fgAhsQ0XBDEETj
	4liSrBga1q8uYLVIpIbNywXoLKwqs1s1B6YdShNb0tzOoJumRVOOIHBhOeyg1coknQ9B9XEiHam
	y0qWKlF2Hh3yLZEP6
X-Google-Smtp-Source: AGHT+IEgGVF0a8o4FOy7JKbGAyKw98PJDdVmQ8wzS+s2fGxMRsg+DEcPFW5xTuKWyOM0MUfTYxl+lA==
X-Received: by 2002:a05:6402:5252:b0:5fa:82a4:4879 with SMTP id 4fb4d7f45d1cf-601140b5286mr25794126a12.16.1748004560706;
        Fri, 23 May 2025 05:49:20 -0700 (PDT)
Message-ID: 
Date: Fri, 23 May 2025 13:49:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/3] x86/traps: split code to dump execution state to a
 separate helper
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich 
References: <20250523082135.18088-1-roger.pau@citrix.com>
 <20250523082135.18088-3-roger.pau@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: <20250523082135.18088-3-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23/05/2025 9:21 am, Roger Pau Monne wrote:
> Split the code that triggers remote CPUs to dump stacks into a separate
> function.  Also introduce a parameter that can be set by the caller of the
> newly introduced function to force CPUs to dump the full stack, rather than
> just dumping the current function name.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Fri May 23 12:57:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 12:57:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995735.1377964 (Exim 4.92)
	(envelope-from )
	id 1uIRy8-0001S9-9i; Fri, 23 May 2025 12:57:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995735.1377964; Fri, 23 May 2025 12: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 1uIRy8-0001S2-6k; Fri, 23 May 2025 12:57:48 +0000
Received: by outflank-mailman (input) for mailman id 995735;
 Fri, 23 May 2025 12:57:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIRy7-0001Rw-6o
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 12:57:47 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 853625ce-37d5-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 14:57:45 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43edb40f357so76011615e9.0
 for ; Fri, 23 May 2025 05:57:45 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a366e08747sm23449171f8f.95.2025.05.23.05.57.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 23 May 2025 05:57:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 853625ce-37d5-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748005065; x=1748609865; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=MZPfaqjK/oRJFHgil/CdCmK1hYNGccxbjdeNMoweZXc=;
        b=q76dSIg7ho924eJ1X1dpHwMjxYyOtIzrESoLVZBNHhWWnogai+3J8+6XirlrDu/i7B
         QLAEwwg2QJWBFYQxyVHodSjN6A+TcrDmMTz+jjZoBcF4WSL13wULToGLVZbaZMjC9omP
         w4WGdDDc//p5ehKvokk8POCiGD98eIlj8gOCE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748005065; x=1748609865;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=MZPfaqjK/oRJFHgil/CdCmK1hYNGccxbjdeNMoweZXc=;
        b=s0A673m3+3Ylkq/dzlYoeQwsldsEgW6JZZGu27rZoZCZBegFuXWoXEqGkik5/WJeUH
         If/JDBpGM2EOR3NPZCd81XjAxLlF/1+hliP3N6sUWGcy/EDAl8287+kIPOErw2y1SzxI
         dSg3l8gWLlzCuv/7QCc+HIBLEnCJVvlb2Bf7IGCesBw7MKOXvDP4P0z6RXOQvrWON6qH
         64RxIRtZzEt2xbiyi5GrPuCsr2LE2S28OIL2hQLLF264IBKdfU2WOuBx+ohniLExW0kO
         sFNmEFIQhFeOWBfgPMpxd/qerrpOrdGCs2iOSZhYcNP9lh46LVpnctPIsxJhMy5Jn9Pn
         nB/w==
X-Forwarded-Encrypted: i=1; AJvYcCX1odDFHRb+cPUOtZSfIDOJtd8KtkEq0iMLkW6hUjZ2pb7SVJ7gryzeXOBydYi8mTkyTWUkXrQ8KS8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJYxLJuCislhjcEqDcW0PBjcxo1ku0W1Ybsd4YOAEvGui1Shka
	AaG91lCBmSywRCLMQSN4Zmxsc7e5bGQl5OWBO3Fa+MCNrPMWjWS+hoPWokywO/SsMXE=
X-Gm-Gg: ASbGnctcqD9ERtDSTKii43yA7J3oPaSKJ+BlYJlrKXGdSMleLQMYi3xyMu2Q9u46Xzu
	hconii0lEBStg5xjLi9MsdnDb6LvcR/TCoqHa6aJjvgF1f6lgsUAN7uY9vslHyV40pS1rzCLuic
	Zi89L0dNb2N/yrPHcGqmsQyqz7kJxznDBxuSE2OmJUEycVyvaA1pNVBaKnavqWa/LXmDaNll3uL
	+PDwTqT7O0QzNkbHdsoHZ99F8AmXanVNEdYezhhAhaBL1QISwLz3vUJ3Y6Q4HGFlM3EwsFXcziU
	V8W6bf8KUDtdTH3SkKUjsLvcE9y3aEtmKwWcKB1Bx4Qe4OgsFllqWFFk/E3korcUVLBl306o6RG
	QavoB+EkKXvZRrA4B
X-Google-Smtp-Source: AGHT+IGgKAYE0eZYEoknWGJOxGCeBHfXSZcNpNTOt8IjWdFk3nb93TDIQ6MCtWyOpNkDI9XmjZn58w==
X-Received: by 2002:a5d:5f91:0:b0:3a4:bafb:add2 with SMTP id ffacd0b85a97d-3a4bafbb48bmr6093623f8f.0.1748005064661;
        Fri, 23 May 2025 05:57:44 -0700 (PDT)
Message-ID: <7486eb78-50e8-4959-b494-5bd58e123af4@citrix.com>
Date: Fri, 23 May 2025 13:57:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] eclair: allow and document use of GCC extension for
 label addresses
To: Nicola Vetrini ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Doug Goldstein ,
 Anthony PERARD , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
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

On 23/05/2025 8:20 am, Nicola Vetrini wrote:
> No functional change.
>
> Signed-off-by: Nicola Vetrini 

Ah, very nice and easy.

Acked-by: Andrew Cooper 

Is this dependent on the updated Eclair, or can it go in now?

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 23 13:02:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 13:02:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995743.1377974 (Exim 4.92)
	(envelope-from )
	id 1uIS2y-0003Ew-RE; Fri, 23 May 2025 13:02:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995743.1377974; Fri, 23 May 2025 13:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uIS2y-0003Ep-Nt; Fri, 23 May 2025 13:02:48 +0000
Received: by outflank-mailman (input) for mailman id 995743;
 Fri, 23 May 2025 13:02:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIS2x-0003Ej-JB
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 13:02:47 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3873f40e-37d6-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 15:02:46 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id E627F4EE7BD6;
 Fri, 23 May 2025 15:02: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" 
X-Inumbo-ID: 3873f40e-37d6-11f0-a2fb-13f23c93f187
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=1748005365;
	b=eeAV/aai1PQnEefO5xKhvClq4hrEVHinntSJsw0Qhbs7FBWk6NiN9y2hVqskMYiCZVxE
	 k8khlKMg4+JXHR006boSkMo1FFvQtn/EBmJmZ+lswOBUUxK3PmMC9lA3+UsJBUQ77UvZM
	 M4LU2JQ/P5O2OVC6nYEzBbxVamIcqWI7SUpnQIEfqpjRB+PNepgCPtZCezA+Sqvf9M2QF
	 464iy9x6CI+uArVlRPgSEoPlhOOauJKgCdlgXge41uxIkuSfMLSIcNufFuOxsS0pCqf84
	 EqQ1f+AAYAjAXiSsuwVB1/+/BXagUoHKMYkoEPwHM6Rqi2fhHsfPkx9To4Yc37ogOAbP7
	 4p5mPnqwrJECt1KcRWmuoMscY9WkNC5WpdpQTZW5RYmZxu/1zCSmrToBuCFTfSmFyvoIv
	 pwFCTKVPV8UTtEnkRt/+0V0xloei5IsZn3yNnk4SJwOz/hccyMX7JPfDG3DFOGo7u5LLW
	 MY0CRULfUh/LyA8pGIohL6qBPsQ1WWxo1OttmxQ6HTaCGVE18CnlwJIB3nX2OhdWgbytC
	 SKxON/O439UA2wg8imicqiT9wm0AGRKZi4hbMX3EV7nQS+fKMyscgYDZOEoAFoHd+ZcNK
	 ramAViRUgAeCexwUlvJpCjL7z6n6hR0buEoTWGCvKzx0tczWAhHErh+7pQ5mmWI=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1748005365;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=QMhOkikQblqSeiPEaylQHLkswdulAMttTtfH5q+coI0=;
	b=OQ41NEHitoyGTfVE2gsi21589rD954yUfozNKqIG0iSndIyvy21pwWhaZ7Kf1JwYL3Bp
	 2CBoSJcuiAEW1SUz8jVRR/VXSa5mShZEBgr5uNmVru8jgUtm2unIQFAnI/XJF7QEw7XYO
	 g8uYIG3FCjP6vbh6FgRTE4CGh/aPrJBMGxfs1KMbfReMr2TWxmHE1LkBzFkhi4xTZ05mT
	 Rg/kDKzRv3b88lS5bLlR08b+pXftFt8SdDOaLtqs7egFdC6Rn5TEk2TnXGPbfU9aXyGSj
	 9O8DFtClfPvB3bYyENtWS0xXI9EspTrJx3WAKpMwsxaTueqQj85mxYI+Zj6E7DvQADwe7
	 Cnu05aCDEMsRRkazyYIWduFITQM39yAuXoWo/LuZtxMKEf2/Jx/80YcHfqhO6JkLrYNRR
	 up703mm1gr8fVlYedEvHfB2qUaC/ZcleLSgD5df5+mbfVzMX4fY8pmuBct20/ZUuBe7kX
	 8wn+Rh+fxO1tQgrHiOXWH1qwPoP8VTUU/s9d304jC0zbawDzhqmp4KuPEpMdL15b4eHuN
	 AsqLolOgl04DYexAmvc1WeTie4M4MGF8qpryi72mm2qI75w3f/ojacjww24yb8qB40tmz
	 stqSqrAQeGmT0jQiQVylmF0I5e5O71VfzSsT4IrfwyBVhh4Rfut/osF+Ys6M/UI=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1748005365; bh=LKM8JtUvIntWKxk9g+9bwG/Hl0rdwJTNx/O0T6hZcRQ=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=dQ50955XaaAE26x5hbIOfNMzG3KLx/ouerMxFJM4kFseY1HnniMZdswcT26ISJrD8
	 pnZlfxalJKXtG9dq4lY8ZW2haJq38c/pxKdjIR7aJzqiQS/uPTeINaVEQ51R9HcxNw
	 OhQvr3g4Wkx5xLSDOvQX4I8qKcNL9PiedOdHMnmYLyfJ6DkhWU7HWKCvLfJR5+sn7Z
	 lzPb5VP4z8BaW5yUdJPqfgdDJW2AWj8rtA1RLiT0Y1kkw/uaQErq508rzHuuH7U2G0
	 BN4QuVzmy8/7egEPCyOBIMvzda9AYe+9ui8d1pPxzC7bnWro5aMYtBCLeLUa6G95tI
	 1BL1Vxj4Tmeqw==
MIME-Version: 1.0
Date: Fri, 23 May 2025 15:02:44 +0200
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
 michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com,
 consulting@bugseng.com, Doug Goldstein , Anthony PERARD
 , Jan Beulich , Julien Grall
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [XEN PATCH] eclair: allow and document use of GCC extension for
 label addresses
In-Reply-To: <7486eb78-50e8-4959-b494-5bd58e123af4@citrix.com>
References: 
 <7486eb78-50e8-4959-b494-5bd58e123af4@citrix.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

On 2025-05-23 14:57, Andrew Cooper wrote:
> On 23/05/2025 8:20 am, Nicola Vetrini wrote:
>> No functional change.
>> 
>> Signed-off-by: Nicola Vetrini 
> 
> Ah, very nice and easy.
> 
> Acked-by: Andrew Cooper 
> 
> Is this dependent on the updated Eclair, or can it go in now?
> 

Hi Andrew,

it's independent on the updated ECLAIR.

Thanks,
  Nicola

-- 
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 May 23 14:33:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 14:33:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995818.1377984 (Exim 4.92)
	(envelope-from )
	id 1uITSv-0006IC-Vc; Fri, 23 May 2025 14:33:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995818.1377984; Fri, 23 May 2025 14:33: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 1uITSv-0006I5-Sm; Fri, 23 May 2025 14:33:41 +0000
Received: by outflank-mailman (input) for mailman id 995818;
 Fri, 23 May 2025 14:33:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uITSt-0006Hz-QF
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 14:33:39 +0000
Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com
 [2607:f8b0:4864:20::54a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e9e10396-37e2-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 16:33:38 +0200 (CEST)
Received: by mail-pg1-x54a.google.com with SMTP id
 41be03b00d2f7-b26e4fe0c08so5576687a12.3
 for ; Fri, 23 May 2025 07:33:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e9e10396-37e2-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1748010817; x=1748615617; darn=lists.xenproject.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=/uvu6aXDIrLF08vsxpzyNfXk0GOFzmWSaZdsX/BEX7c=;
        b=2FoHgpKqd4XgsPJLmFoMnyWQrnLjU1898pRbBgOkjlb9qiCpc1CnQSDP3tZ3JFv8XO
         bfr0bQNBcJcW30H+tu1IQkI/4ElEFugvKqUTeLaZSShhH04e+9YQII0NQIu3Hl7x0zdL
         6FGRs3cdcORoJiGtg2iGDaFAaymCFyd3VbI6mFXcl87E0M5wb6nxl/N/Apy9DLCvx6F4
         dpC1Rc51mBAgUO3TMAJ9igHcKuIfs2z39ltyaIBo7Alq1cJAHuQqje0djMsw8EJHOrhr
         xDK6CvgaUEob5nNVkmqXlAg6ZrvxjybYVk9YBuJgag79XrJhF4/SeQgz7VKX2fd6QghK
         lU4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748010817; x=1748615617;
        h=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;
        bh=/uvu6aXDIrLF08vsxpzyNfXk0GOFzmWSaZdsX/BEX7c=;
        b=xDOrvjDbWLSkuHMXRYe6bU0/3H3eLLDP7jD4Jdiyb7DWA3AxrbX5l4hKWF9J3g62N5
         bYdBnrejE2oWms671leJPJPkt5MAaLV3xXCOIilbDPzZb7l6Y3ZTm+eNMtAL9QhhAx7G
         w+xmjPpfUf5jx4h0T6wi5a12Z+CI+rMvIOGZeiBHPCyEKf2VT39Wi6bpkyRMsJGxQUQi
         8u0Yjde8NjCGNJh7aobA8B61zh3eSFOA/J/yQ8xo3S93o00d7Cn6Ktmao5fKKKrG12e/
         8bCLrHx07M71lCZpFZUlluVhQW6Ko98BjrVQPg5RkFWYwijcUC1FZfViE1jd2vtZuBU6
         rzFg==
X-Forwarded-Encrypted: i=1; AJvYcCUmd8+tnwW0ud+c79VPfUxWkbjd5rAsyuLdDk1JdYC2EwczO7KZDtmVRwymOdAsQ9r38epPldmRHDo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzoF38FXYIaZ+p/ttRT1jn8xpOEp5YZoXAMtfosTVJZm0wACMWh
	caM1+08mbWltql7wtqV/x5yzWsdv4DQDXWnaFIM+BRSoYBGcHEQsOzOjXorod2NRb2O9nLYNRTj
	a4X6tFQ==
X-Google-Smtp-Source: AGHT+IHsZ0QnOLBFT5oLqgFlsou+V6RqzdnkAMpT1uyTVqCC/FSYHIecluEf4Yy5p3wiVYxCHPutaUGV15c=
X-Received: from pjbmf7.prod.google.com ([2002:a17:90b:1847:b0:30e:7b26:f68b])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:1846:b0:301:9f62:a944
 with SMTP id 98e67ed59e1d1-30e7d5ca287mr50858908a91.33.1748010816755; Fri, 23
 May 2025 07:33:36 -0700 (PDT)
Date: Fri, 23 May 2025 07:33:30 -0700
In-Reply-To: <2c52daad-0b64-48a9-8e73-d1aba977993b@amd.com>
Mime-Version: 1.0
References: <20250522235223.3178519-1-seanjc@google.com> <20250522235223.3178519-14-seanjc@google.com>
 <2c52daad-0b64-48a9-8e73-d1aba977993b@amd.com>
Message-ID: 
Subject: Re: [PATCH v3 13/13] KVM: selftests: Add a KVM_IRQFD test to verify
 uniqueness requirements
From: Sean Christopherson 
To: Sairaj Kodilkar 
Cc: "K. Y. Srinivasan" , Haiyang Zhang , 
	Wei Liu , Dexuan Cui , 
	Juergen Gross , Stefano Stabellini , 
	Paolo Bonzini , Ingo Molnar , 
	Peter Zijlstra , Juri Lelli , 
	Vincent Guittot , Shuah Khan , 
	Marc Zyngier , Oliver Upton , linux-kernel@vger.kernel.org, 
	linux-hyperv@vger.kernel.org, xen-devel@lists.xenproject.org, 
	kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, 
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, 
	K Prateek Nayak , David Matlack 
Content-Type: text/plain; charset="us-ascii"

On Fri, May 23, 2025, Sairaj Kodilkar wrote:
> On 5/23/2025 5:22 AM, Sean Christopherson wrote:
> 
> > +
> > +int main(int argc, char *argv[])
> > +{
> > +	pthread_t racing_thread;
> > +	int r, i;
> > +
> > +	/* Create "full" VMs, as KVM_IRQFD requires an in-kernel IRQ chip. */
> > +	vm1 = vm_create(1);
> > +	vm2 = vm_create(1);
> > +
> > +	WRITE_ONCE(__eventfd, kvm_new_eventfd());
> > +
> > +	kvm_irqfd(vm1, 10, __eventfd, 0);
> > +
> > +	r = __kvm_irqfd(vm1, 11, __eventfd, 0);
> > +	TEST_ASSERT(r && errno == EBUSY,
> > +		    "Wanted EBUSY, r = %d, errno = %d", r, errno);
> > +
> > +	r = __kvm_irqfd(vm2, 12, __eventfd, 0);
> > +	TEST_ASSERT(r && errno == EBUSY,
> > +		    "Wanted EBUSY, r = %d, errno = %d", r, errno);
> > +
> > +	kvm_irqfd(vm1, 11, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
> > +	kvm_irqfd(vm1, 12, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
> > +	kvm_irqfd(vm1, 13, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
> > +	kvm_irqfd(vm1, 14, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
> 
> Hi Sean,
> I dont see any allocation for the GSI 13 and 14..
> Is there any reason for the deassigning these two GSIs ?

Yes, KVM's rather bizarre ABI is that DEASSIGN is allowed even if the VM doesn't
have a corresponding assigned irqfd.  The reason I added these early DEASSIGN
calls is so that there will be an easier-to-debug failure if KVM's behavior
changes (the racing threads part of the test abuses KVM's ABI).  I didn't add a
comment because the helpers already have comments, but looking at this again, I
agree that main() needs a better comment.


From xen-devel-bounces@lists.xenproject.org Fri May 23 15:49:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 15:49:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995913.1377994 (Exim 4.92)
	(envelope-from )
	id 1uIUeO-0006gw-7E; Fri, 23 May 2025 15:49:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995913.1377994; Fri, 23 May 2025 15:49: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 1uIUeO-0006gp-4X; Fri, 23 May 2025 15:49:36 +0000
Received: by outflank-mailman (input) for mailman id 995913;
 Fri, 23 May 2025 15:49:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIUeM-0006gh-9V
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 15:49:34 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7cb51faa-37ed-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 17:49:18 +0200 (CEST)
Received: from [192.168.1.113] (93-36-220-193.ip62.fastwebnet.it
 [93.36.220.193]) (Authenticated sender: federico)
 by support.bugseng.com (Postfix) with ESMTPSA id F07554EE7BD7;
 Fri, 23 May 2025 17:49: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" 
X-Inumbo-ID: 7cb51faa-37ed-11f0-b892-0df219b8e170
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=93.36.220.193
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1748015358;
	b=WyDj1HBuySEiT3i17PxzAc9WrDx3X7l7YQqEdHQ05RQGTTt2YNQWDcDXHgO9slYIZF4d
	 EG1wu1kUDxGXSAuN3l4Ye9vFA7uW5uDPZx1vBGCe6rQc7KA6zHVLFmgTqcIdzBTJrpt1p
	 1kK6n9ZZ/ilXsfFf3m3o6frR++q2BgreKSq1xwTVfZrrlbxLVliMnB07syr+QedMmx7Sb
	 SUz1KPwsf/4E7Mw1xrEgDNWxc+NE5xIYgD6q55mjDkVETWuVhWf3RQeWMppDxI8Ld45Z7
	 GSf6xhJTcGgMT9zFlrVTJQ9OQYwyNxLO8kPKb9THq87NnMe6y1zhXl5LSvJgpnWaRPo8b
	 reDcysuvEnpWto8jRmkG4vlizzO116byryVuMOGgavtCwQOjbKYrp7IiJo2WwmirPwYLt
	 tjEdf+rKI6X6nHG9SkahFSdgGjCygvtmzTx6gyXZXiK/2hh5LSTTp1zKpPeiqXAATHvUb
	 +pH/zX+Y9UwSFEbSXdhxtx5iVNU44TmLM8XEVrbhPRMAVfSwU5J3WvgmcVpKuWN0jlPM+
	 fajYBSkdS3cMjIVFRWeeQkeOKgB0SCMcy8gwwtJsr8sDz1Gez9Nw3jO1LYz0W7U0CcZym
	 qiYXm2bSHoagcsa+3V/ICAiJCwUxF5MFOntoxk+1uyY8Zv4YHkG7XN6axDqpiZ0=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1748015358;
	h=DKIM-Signature:Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:
	 References:Content-Language:From:Organization:In-Reply-To:
	 Content-Type:Content-Transfer-Encoding;
	bh=DHB7xELPQb6xTpfcv4i+qjGK9XFnqTIs65litDkrJIw=;
	b=WPC+t4/gealOHiCR41pvlHP5cYpEkGuyFZX4p+A9ZvuprPODLTYUhjvDomfYK2rl+AXQ
	 jMGGtaceMzxG376Y+OhWGfLpQ2YM2ONT3pOGlEcobnWgk0Eahx0s6RPzaX5MF3PI6tSNt
	 VaRuxMlzptS3tWEfPt1ZsSFKpUjBH4hHCKkhf/bBJPUCDuoIADBHEuHNFRjFQTDnOXMfn
	 5dU/7IxR5viN85i0GPwgHMpdFZ9el/zRhIgCXCD3vmiQqQX3VMtLpRVMmrphfFfVIPAXW
	 OucCHnXKE5roeviwlimiJ5mOu1oY1bPtKdc7Xi94Z5FgSxI2IW38EhaBcs+85V3w5rePs
	 ezo6/q5+QIL/ZyYY9eFphHWp28n2NJKgbxrP7eNDOyeZI2w7m2/Cab3ecIi3EPDhYADaC
	 Rxo6bp4qW09kuYkB/y7YIUqvdXeQFei0IHYT01Q3mqah85VRQkmu5xfAYPqKAY21mOFmU
	 kt0DmGkoUNnjzMjzG3W0h8gOcsFwaOAJ9Kg8bj/RY+kG7ZCOCDiqnei74bjIdVa0rQc6s
	 qFhTmfTATHQBb6QApJ6S/MOQ3mKnfLvJWbiNdixu9wEGspWiEPGWM6K2PoYN/Rpt2ocvj
	 BZAwy99ipHiK9BOVEs+AsjNW/hbGLZj0shQLfPuJriODFX6nSsrDCBZyXy+vGpQ=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=93.36.220.193
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1748015358; bh=26v7dN7ZyGhNwwgmpGQ00pfxTGoocFLFJoN48GMDJOc=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=N4NTslKsCPudVLvfWf9AiaYt2CE5ujLXAp/JrAgvJBQMktMPc9HSyTiqgSkyLRzts
	 0fYebHVFu9RZEu2oh/sUzEDzi6+KB4puvAwKnoD5cgCS4BmDtqJOSdcVsbsa0HUG/J
	 a97SK7CJoLAM2ZUwnIcEqmsC8F10diWw+uVgSvuVs8x4MUcfvvZRbfQ0sEVkxn/hs0
	 IBX1uy1vY0HKTE/tfFTzphSTh3VCM1PHLS2mVnC/FW3H3Im9PwiaZzJiZmMjr/TulF
	 6KtSAn8EWmxwQcodg0m53zYlrOFOaKkZcZSMtmBZt1fYdSazZJIGEql1ocJ4xiRLx6
	 R0FyO1/bYyOaA==
Message-ID: 
Date: Fri, 23 May 2025 17:49:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/6] automation/eclair: update configuration of D4.10
To: Stefano Stabellini 
Cc: Andrew Cooper ,
 Stefano Stabellini ,
 xen-devel@lists.xenproject.org, michal.orzel@amd.com, jbeulich@suse.com,
 julien@xen.org, roger.pau@citrix.com, bertrand.marquis@arm.com
References: 
 <20250516232130.835779-6-stefano.stabellini@amd.com>
 <5c2aa885-8877-4708-90cc-d65a76b729b3@citrix.com>
 
 
Content-Language: en-US, it
From: Federico Serafini 
Organization: BUGSENG
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 19/05/25 23:36, Stefano Stabellini wrote:
> On Mon, 19 May 2025, Federico Serafini wrote:
>> Hi,
>>
>> On 17/05/25 01:57, Andrew Cooper wrote:
>>>
>>>> +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated
>>>> file, do not edit! \\*/$, begin-2))"}
>>>>    -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated
>>>> file, do not edit! \\*/$, begin-3))"}
>>>
>>> These seem to only differ by the begin-$N.  Why doesn't the regex work
>>> in both cases?
>>
>> "begin-N" expresses the position of a single line, not a range.
>> For example, begin-2 means "two lines before the first reported area"
>> and deviates:
>>
>> https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/hardware/xen/ECLAIR_normal/staging/X86_64/10063944407/PROJECT.ecd;/sources/xen/include/xen/hypercall-defs.h.html#R174_1{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":false,"selector":{"enabled":true,"negated":false,"kind":2,"children":[]}}}
>>
>> If you prefer, I think we can use ranges and merge the two
>> configurations.
> 
> I think that would be better


The configurations can be merged into a single one:

-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated 
file, do not edit! \\*/$, begin-3...begin-2))"}

-- 
Federico Serafini, MSc
Software Engineer, BUGSENG (https://bugseng.com)
LinkedIn: https://linkedin.com/in/federico-serafini



From xen-devel-bounces@lists.xenproject.org Fri May 23 16:01:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 16:01:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995934.1378004 (Exim 4.92)
	(envelope-from )
	id 1uIUq9-0001cw-7j; Fri, 23 May 2025 16:01:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995934.1378004; Fri, 23 May 2025 16:01: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 1uIUq9-0001cp-3x; Fri, 23 May 2025 16:01:45 +0000
Received: by outflank-mailman (input) for mailman id 995934;
 Fri, 23 May 2025 16:01:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIUq7-0001cg-LU
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 16:01:43 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3661a783-37ef-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 18:01:41 +0200 (CEST)
Received: from pps.filterd (m0246627.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54NFxT4H011710;
 Fri, 23 May 2025 16:01:37 GMT
Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta02.appoci.oracle.com [147.154.114.232])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46tv4q8079-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 23 May 2025 16:01:37 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 54NFvE9H001898; Fri, 23 May 2025 16:01:36 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 46rwev5r1b-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 23 May 2025 16:01:36 +0000
Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 54NG1Zq7032523;
 Fri, 23 May 2025 16:01:35 GMT
Received: from lmerwick-vm-ol8.osdevelopmeniad.oraclevcn.com
 (lmerwick-vm-ol8.allregionaliads.osdevelopmeniad.oraclevcn.com
 [100.100.255.219])
 by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTP id
 46rwev5qyx-1; Fri, 23 May 2025 16:01: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" 
X-Inumbo-ID: 3661a783-37ef-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=
	content-transfer-encoding:content-type:date:from:message-id
	:mime-version:subject:to; s=corp-2025-04-25; bh=/HSM8HF+XvdzD7AJ
	OUGZLdAp3QeqS8wTKQhywnwBqrU=; b=TjHYYmKPXQxfff6avkU4904RFrpK6MxZ
	78zUWbATL69DasbWSJ3BVrtJXfCF0q31N20tHWeo45l7H8DQoiiKGtR05VT310z2
	+xjiAhIqw0PLW4n7mVms9vfF/bPJDLfxFTzy/KYGEr8ZpsBzFNtjsTahdYzqKtfc
	xVpY1GLYAGF0eS2AB5Cm7deF4/ZXuOEqRgb2b+3nr5zR/hxTx9o1fT3lS1zBCEK7
	t7cTxg6R1JqqIYSd6g2JWwZVEF2jw6QqvtDjrkNalQ1WVxq7Eh+70EAR8DPA5wlK
	8NMhWQZ3GNBx0DWuM57161MJQ0a0JuAAFRCJY50nrmXDZOU+Zh5y9w==
From: Liam Merwick 
To: dwmw@amazon.co.uk, anthony.perard@vates.tech, roger.pau@citrix.com,
        xen-devel@lists.xenproject.org, qemu-devel@nongnu.org,
        liam.merwick@oracle.com
Subject: [PATCH] hw/xen: Fix trace_xs_node_read() params
Date: Fri, 23 May 2025 16:01:34 +0000
Message-ID: <20250523160134.218997-1-liam.merwick@oracle.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-05-23_05,2025-05-22_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=963
 spamscore=0 bulkscore=0 adultscore=0 mlxscore=0 suspectscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2505160000 definitions=main-2505230145
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTIzMDE0NSBTYWx0ZWRfXzKhc12nOACPq ry0AdFC6085lYP89tiCbsgK59zp6dbmGaRNLjkmSFkTDJLkCByJwoyBoF7T3ms3Km+VGNsBnv0w bcZQCvQbXst7hNmq8vXblCJsOpzLCj8E4Z77T2KILxalaY2J528WJ8rXiSN3pqT55wXq4LLyvJa
 Lf7EOYZDKVWD0rIrrp1Nt/vkgpoIO6J5HBgV6LPif/qf5xReyirOybjbk1fJ2lg+Ut+5RN3TQbF 4BPh0x/POI6wgvyXoI0XIFzRNl8qN9Okqk8okEBJrV8D0Y2rdnmgyKO3SuKzGTW2Fy1yr2XB9ot aeun3TTD6dparyeqlownuPfW9DdzbFufu4CF+EwADGThttaShBZbXZeVjBeK1rULfVdaTzsMKjm
 EF7FuUwlUsMQBvtmJMMSbTuJI4UizbVeXBDKJJEtpXb4csCcfm9MV08Kanh2eGa4ciqAhYdk
X-Authority-Analysis: v=2.4 cv=VoUjA/2n c=1 sm=1 tr=0 ts=68309be1 cx=c_pps a=OOZaFjgC48PWsiFpTAqLcw==:117 a=OOZaFjgC48PWsiFpTAqLcw==:17 a=IkcTkHD0fZMA:10 a=dt9VzEwgFbYA:10 a=yPCof4ZbAAAA:8 a=bOG54WbAxldRIBuYn70A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10
X-Proofpoint-GUID: yj_f9Ug9G2CAGoj9LV9uUD-tIWKa7atM
X-Proofpoint-ORIG-GUID: yj_f9Ug9G2CAGoj9LV9uUD-tIWKa7atM

When the '--enable-trace-backends=syslog' build option is configured,
the following compilation error is encountered.

In file included from /usr/include/sys/syslog.h:207,
                 from /usr/include/syslog.h:1,
                 from ./trace/trace-hw_xen.h:224,
                 from ../hw/xen/trace.h:1,
                 from ../hw/xen/xen-bus-helper.c:13:
In function ‘syslog’,
    inlined from ‘_nocheck__trace_xs_node_read’ at ../hw/xen/trace-events:41:9,
    inlined from ‘trace_xs_node_read’ at trace/trace-hw_xen.h:903:9,
    inlined from ‘xs_node_read’ at ../hw/xen/xen-bus-helper.c:154:5:
/usr/include/bits/syslog.h:45:3: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
   45 |   __syslog_chk (__pri, __USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Add a check that 'value' is not null before passing it to trace_xs_node_read().

Fixes: e6cdeee95990 ("hw/xen: Add xs_node_read() helper function")
Signed-off-by: Liam Merwick 
---
 hw/xen/xen-bus-helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
index 288fad422be3..1087a585cc71 100644
--- a/hw/xen/xen-bus-helper.c
+++ b/hw/xen/xen-bus-helper.c
@@ -151,7 +151,7 @@ char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
     va_end(ap);
 
     value = qemu_xen_xs_read(h, tid, path, len);
-    trace_xs_node_read(path, value);
+    trace_xs_node_read(path, value ? value : "");
     if (!value) {
         error_setg_errno(errp, errno, "failed to read from '%s'", path);
     }
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri May 23 16:06:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 16:06:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.995944.1378014 (Exim 4.92)
	(envelope-from )
	id 1uIUuL-0002Az-NF; Fri, 23 May 2025 16:06:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 995944.1378014; Fri, 23 May 2025 16:06: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 1uIUuL-0002As-JG; Fri, 23 May 2025 16:06:05 +0000
Received: by outflank-mailman (input) for mailman id 995944;
 Fri, 23 May 2025 16:06:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIUuJ-0002Am-V8
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 16:06:04 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d251b4b6-37ef-11f0-b892-0df219b8e170;
 Fri, 23 May 2025 18:06:01 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a3673e12c4so57227f8f.2
 for ; Fri, 23 May 2025 09:06:01 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a35ca4d2ddsm26749906f8f.7.2025.05.23.09.05.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 23 May 2025 09:06:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d251b4b6-37ef-11f0-b892-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748016361; x=1748621161; 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;
        bh=cKRGcqOB4K7R/otJOmMfsqC3TxSzOnxP7UoS9tqRNfk=;
        b=Fhqala2VzIEoou5vCl7m8hTIWPtsNQZAinNc1kEhWzMm/lwpEiyLCqiFoDY/J4BXZ3
         WuAzuZFy1Ja7JHa4klcXMngf9XtxM53+jXnWiqES+mValXb54tffqEpl4e+eAYPuKOFu
         lyG/8MvNUyxiwq5bbmG1ATpT/DsxvVB1RrDZ8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748016361; x=1748621161;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=cKRGcqOB4K7R/otJOmMfsqC3TxSzOnxP7UoS9tqRNfk=;
        b=ssyXHfI2lO6/tLuwOrsWTn9xY7owdT0wYSI9G7KIUErM5j8wDkkCaUca8kDCCFPSga
         ybj7g1AmaPrbTSgXHrX+dBATdrn4Fl3bAFqufeqAL4AfslQxPZHDnd+V83rYnn4DszqU
         O2gVSEN78mu/Qo2yKuMqOEprr482h3AH6gHAf5sQ3ZOXLbaRK0345F4ckOd508sFitmp
         BCjOg+yZ+pdEjkGT1wa+j65R8I/8/SyP7yMFoWH91wDpYyGseoc6WtamrB+Pdr0u2/Fd
         WDjgXaWA5fho+/wTqTG/WQdt4gu+UTn35vqnJ0vYTAzbLzcloehtoYwsTNgCk6MKiNf4
         IXCg==
X-Gm-Message-State: AOJu0Yxqgui2jIgYsC+/LYr4EgrjseE9ii//Zg80/9IgAPwFmM0Rp2tn
	nYgIujUdSD4XBvVrASWp58y5pVb71aWMBCS0RvJpOYge7cgR0LVqx1MXdOscyT1Vt6HNHpAa/id
	WIXUQ
X-Gm-Gg: ASbGncvWxJCsiJgYPgVs+3UWI+l98HX5tycVpuMyIGFUeJQSL9+A/eTij5rwICrX5yG
	/MmKhMcwfwus/vQIPksQ1SF8tWmbptLRDzVdXecyDwAch2jVP0YYajmBUGiKOuOlRQPsg04y7n1
	DnywKBrdONE9zs2+DWdhSN+x7opzJb6w3pJGaWG3ogRybEdH+ZSk3uwoY6NmGSFZEKFvlaNLCk3
	EkLqMM7B+1NJvBYcB4obke/0TkuskfdbFv4zf977XhYAA2j4rvh9bkvSE1fLDC0kY2OXbt1xorj
	mn0Q5EoPHYcPKbo3V2d4TZgh7nbRksy+ou0JerM9r7mMtQ/i9Fv33f/HQu3eGS/n/aM+75/3W1h
	uh3Yl1Z+gUYjGp/mRax3qZxYi
X-Google-Smtp-Source: AGHT+IGmLLWJsOobbgnRwrrAYeL7Wcsod6zD75J7hJ6LkhurtLXwRxr8Achj60krJmZW+TqCZIwmHw==
X-Received: by 2002:a05:6000:2892:b0:3a4:c2e4:11b with SMTP id ffacd0b85a97d-3a4c2e40151mr3483242f8f.51.1748016360670;
        Fri, 23 May 2025 09:06:00 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	=?UTF-8?q?Petr=20Bene=C5=A1?= ,
	Tamas K Lengyel ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH] x86/vmx: Fix VMEntry failure on ADL/SPR with shadow guests
Date: Fri, 23 May 2025 17:05:58 +0100
Message-Id: <20250523160558.593849-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

Paging Writeable depends on EPT, so must disabled in non-EPT guests like the
other EPT dependent features.  Otherwise, VMEntry fails with bad control
state.

Drop a piece of trailing whitepsace in context.

Fixes: ff10aa9d8f90 ("x86: Add Support for Paging-Write Feature")
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Petr Beneš 
CC: Tamas K Lengyel 
CC: Marek Marczykowski-Górecki 

This is the cause of the XTF Shadow failures in Gitlab CI.  Working run:

https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10133481327
---
 xen/arch/x86/hvm/vmx/vmcs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 59f4d1d86f02..57d49364db56 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1132,9 +1132,11 @@ static int construct_vmcs(struct vcpu *v)
     else
     {
         v->arch.hvm.vmx.secondary_exec_control &=
-            ~(SECONDARY_EXEC_ENABLE_EPT | 
+            ~(SECONDARY_EXEC_ENABLE_EPT |
               SECONDARY_EXEC_UNRESTRICTED_GUEST |
               SECONDARY_EXEC_ENABLE_INVPCID);
+        v->arch.hvm.vmx.tertiary_exec_control &=
+            ~(TERTIARY_EXEC_EPT_PAGING_WRITE);
         vmexit_ctl &= ~(VM_EXIT_SAVE_GUEST_PAT |
                         VM_EXIT_LOAD_HOST_PAT);
         vmentry_ctl &= ~VM_ENTRY_LOAD_GUEST_PAT;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri May 23 16:46:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 16:46:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.996016.1378040 (Exim 4.92)
	(envelope-from )
	id 1uIVXQ-0000BO-UE; Fri, 23 May 2025 16:46:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 996016.1378040; Fri, 23 May 2025 16:46: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 1uIVXQ-0000BG-Qr; Fri, 23 May 2025 16:46:28 +0000
Received: by outflank-mailman (input) for mailman id 996016;
 Fri, 23 May 2025 16:46:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIVXN-000086-Vy
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 16:46:27 +0000
Received: from desiato.infradead.org (desiato.infradead.org
 [2001:8b0:10b:1:d65d:64ff:fe57:4e05])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 766707ef-37f5-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 18:46:24 +0200 (CEST)
Received: from [172.31.31.140] (helo=u09cd745991455d.ant.amazon.com)
 by desiato.infradead.org with esmtpsa (Exim 4.98.1 #2 (Red Hat Linux))
 id 1uIVXI-00000001M1n-27ql; Fri, 23 May 2025 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" 
X-Inumbo-ID: 766707ef-37f5-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=desiato.20200630; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:To:From:Subject:Message-ID:Sender:Reply-To:Cc:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=DSo+3iRpAKjbqKRR6RJC/r/W1BxEyLxiqZAtmn6Od9Y=; b=JgVPyqxDu9OlwOK9EV5e09f+EU
	rn/skQWRwn7fTruW6Mv2sA+3emmgzVux6l9QYlvxMxcVmVZ7YiGIglqz3CiasVaFf0NNI/8ejMv9g
	pDdA8x+E/Kho9EsE7npPWk27fuWaD7V00wuBj2kZ7Rqp5EmKEJnePlqQW/ZmxerVH0vayVNnll03J
	q7IQjuOYQ2CFwNOlbSEaRrNliAnxKSoJH2x/FWdt5Ecwk3fmq1MMMAAX3+jPowaZ7hN2vzloZ4rAS
	YGOBpfU8u0ed6lFUH25wtZ7d5iyYZ7aiNHuxL4Dnv3HL9lbKZeeg2hggzoj6VLDbJpKW/Yt1hrK8i
	hJtGE/KQ==;
Message-ID: <9ddde4627ed42c55ba7ea56d6e3c9b4870b606bc.camel@infradead.org>
Subject: Re: [EXTERNAL] [PATCH] hw/xen: Fix trace_xs_node_read() params
From: David Woodhouse 
To: Liam Merwick , anthony.perard@vates.tech, 
	roger.pau@citrix.com, xen-devel@lists.xenproject.org, qemu-devel@nongnu.org
Date: Fri, 23 May 2025 17:46:19 +0100
In-Reply-To: <20250523160134.218997-1-liam.merwick@oracle.com>
References: <20250523160134.218997-1-liam.merwick@oracle.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-1qEj1gTPazsQRVxc738m"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from  by desiato.infradead.org. See http://www.infradead.org/rpr.html


--=-1qEj1gTPazsQRVxc738m
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2025-05-23 at 16:01 +0000, Liam Merwick wrote:
> When the '--enable-trace-backends=3Dsyslog' build option is configured,
> the following compilation error is encountered.
>=20
> In file included from /usr/include/sys/syslog.h:207,
> =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 from /usr/include/syslog.h: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=A0=C2=A0=C2=A0 from ./trace/trace-hw_xen.h:224,
> =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 from ../hw/xen/trace.h: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=A0=C2=A0=C2=A0 from ../hw/xen/xen-bus-helper.c:13:
> In function =E2=80=98syslog=E2=80=99,
> =C2=A0=C2=A0=C2=A0 inlined from =E2=80=98_nocheck__trace_xs_node_read=E2=
=80=99 at ../hw/xen/trace-events:41:9,
> =C2=A0=C2=A0=C2=A0 inlined from =E2=80=98trace_xs_node_read=E2=80=99 at t=
race/trace-hw_xen.h:903:9,
> =C2=A0=C2=A0=C2=A0 inlined from =E2=80=98xs_node_read=E2=80=99 at ../hw/x=
en/xen-bus-helper.c:154:5:
> /usr/include/bits/syslog.h:45:3: error: =E2=80=98%s=E2=80=99 directive ar=
gument is null [-Werror=3Dformat-overflow=3D]
> =C2=A0=C2=A0 45 |=C2=A0=C2=A0 __syslog_chk (__pri, __USE_FORTIFY_LEVEL - =
1, __fmt, __va_arg_pack ());
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>=20
> Add a check that 'value' is not null before passing it to trace_xs_node_r=
ead().
>=20
> Fixes: e6cdeee95990 ("hw/xen: Add xs_node_read() helper function")
> Signed-off-by: Liam Merwick 

Acked-by: David Woodhouse 

Thanks.

--=-1qEj1gTPazsQRVxc738m
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw
ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx
MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv
a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj
jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et
GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06
aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7
nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre
8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw
HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en
IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI
KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB
BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD
QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0
QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB
ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H
/CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa
uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6
xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG
W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl
c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD
VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5
NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ
sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt
w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN
i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0
kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc
0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR
ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS
blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV
hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC
VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw
HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh
ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE
AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0
cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB
AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq
hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv
iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im
8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt
JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL
xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC
EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT
B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw
MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ
KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj
Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg
nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP
WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj
W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1
nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL
g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0
9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA
9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP
sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53
a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET
ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF
AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E
dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu
Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt
YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch
4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9
6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w
QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2
nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA
MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX
VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg
ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDUyMzE2NDYx
OVowLwYJKoZIhvcNAQkEMSIEINZcEptfkeU8/S49PsOPTkFl9eoHVTylBw6doIM1n1ieMGQGCSsG
AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl
cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg
VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1
cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIASDshdhug3J9q
RBKMSe483yG3Pljs+RasGvmJHz/cec7U0Z21+mTXKor/SCGPVZEbRBf61f4RzD3nkhOTqY/xi4Nc
1GvJmJT40FAZSR5iBkan9/QU3MSXe3aCCohyLHK4eLAI6je+/T09Eu9SNTIIsLyGo4EGU/FHL1lT
dNP/i3ps13PiFkOp2xMtzsLyQmSXvuUDRzJ+bPvqOfChg2IjBls1Jznem+IO55ZjrZc4ghEjl8fm
8sZTEgAyZ3DoJ5bODW0dgiF5kA01U7c7GWzTW/tDFJrwHUPVy/W48oIFIIgRLRKq6hN9kSxyvKjn
lELRgs8PdY9A3pNXpVwoeAFM/IXR5x0sjdzqiH3keIdYjS0KP7M1hcTbxdiFgVT+A5G+r/rnEhr/
z5+0ZDBbz+PgPWTtGau2xBEwkMuRFS94lN0KQoVc7jd1UeiskKTlryBcS+1+kBWzSU6k0R0x0Zb0
jlulo4PhUUSCpxOueR931ZNWHgMU90rvAxTnokKgsMbaP6RAmtLpMWRLxkzIwr+zgX4rmdQJ0MhF
y1gPm42ZurVRUDfgJhiK9XjpYI5z7EyrNkYvb+xzO+8pJMHSccU8jy3IvTAItiKfveQ7I1JXe7M9
Tlo5EDY1U562/IVFaO0uvU96T6rJmDo0aa2n4r0hKMpaS3KYu6hbeHbwTOLjZgIAAAAAAAA=


--=-1qEj1gTPazsQRVxc738m--


From xen-devel-bounces@lists.xenproject.org Fri May 23 19:51:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 19:51:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.996163.1378049 (Exim 4.92)
	(envelope-from )
	id 1uIYQS-0005zU-MY; Fri, 23 May 2025 19:51:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 996163.1378049; Fri, 23 May 2025 19: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 1uIYQS-0005zN-Ju; Fri, 23 May 2025 19:51:28 +0000
Received: by outflank-mailman (input) for mailman id 996163;
 Fri, 23 May 2025 19:51:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIYQQ-0005yv-FO
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 19:51:27 +0000
Received: from 19.mo550.mail-out.ovh.net (19.mo550.mail-out.ovh.net
 [178.32.97.206]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4f1bb8eb-380f-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 21:51:25 +0200 (CEST)
Received: from director7.ghost.mail-out.ovh.net (unknown [10.108.25.252])
 by mo550.mail-out.ovh.net (Postfix) with ESMTP id 4b3wlJ6W08z1X3m
 for ; Fri, 23 May 2025 19:51:24 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-64jxq (unknown [10.111.174.252])
 by director7.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 1F4C5C0172;
 Fri, 23 May 2025 19:51:23 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.99])
 by ghost-submission-5b5ff79f4f-64jxq with ESMTPSA
 id Hn3EMrrRMGjqVwgAy2U9Ww
 (envelope-from ); Fri, 23 May 2025 19:51: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" 
X-Inumbo-ID: 4f1bb8eb-380f-11f0-a2fb-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-99G003418991f1-cdd2-4265-b496-d9e85f61f423,
                    DECC013598DA6D3AE1F8C2A8A824853595AB319A) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Fri, 23 May 2025 22:51:08 +0300
From: Sergii Dmytruk 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Andrew Cooper ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Lukasz Hawrylko ,
	Mateusz =?iso-8859-1?Q?M=F3wka?= ,
	trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and
 accessors for TXT registers and heap
Message-ID: 
References: 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Ovh-Tracer-Id: 15112954452181103705
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdeljeegucdltddurdegfedvrddttddmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpedvgfevgedtfffhudegveeiheekteduveeffeegtdeljeelvdefuedtteduieevleenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekgedrvddvuddpfeejrdehledrudegvddrleelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheehtdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=IU0l1u6qAv9taEL9PpuZcs9iUvtNe4BnrJAHTbXWExs=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748029884; v=1;
 b=BTcm2TGRE1fervoCyUPfX8bgXPIedzP1NnN43e43cabsVJHLVhITqbwFiJemaUGPDd11/ZOu
 BxeO4j+Lf2srB+OAFEznAD2buTj4y0itIvYwYPcgRAiJo46dWO9/ZMG0V7QGu5SwV3Hy5dlIVVb
 hL01aOBKLhNYlGJWKGQ6yLbAiYZUTpVGHtOBpiwcGa22TJynfOeQtjxKHSOQcpL/KRXZRGHHOqg
 Lr1Rhte0/xa7SxYlVUrGoepg+ubwQSaRC+GQfFC3/M5+B7QgX+J9iooVKXddf9z4sVxRA2WNeLd
 XrfGGYFLf2rDFTxok613F7Mt+Kaq3HGE4gIXVaJZnpCHA==

On Wed, May 21, 2025 at 05:19:57PM +0200, Jan Beulich wrote:
> > +/*
> > + * The same set of registers is exposed twice (with different permissions) and
> > + * they are allocated continuously with page alignment.
> > + */
> > +#define NR_TXT_CONFIG_SIZE \
> > +    (TXT_PUB_CONFIG_REGS_BASE - TXT_PRIV_CONFIG_REGS_BASE)
>
> What does the NR_ in the identifier try to express?

That's a leftover from the original name inside tboot.c, I'll rename it
to TXT_CONFIG_SPACE_SIZE.

> > +/*
> > + * Secure Launch defined OS/MLE TXT Heap table
> > + */
> > +struct txt_os_mle_data {
> > +    uint32_t version;
> > +    uint32_t reserved;
> > +    uint64_t slrt;
> > +    uint64_t txt_info;
> > +    uint32_t ap_wake_block;
> > +    uint32_t ap_wake_block_size;
> > +    uint8_t mle_scratch[64];
> > +} __packed;
>
> This being x86-specific, what's the __packed intended to achieve here?

This structure is passed to Xen by a bootloader, __packed makes sure the
structure has a compatible layout.

> > +/*
> > + * TXT specification defined BIOS data TXT Heap table
> > + */
> > +struct txt_bios_data {
> > +    uint32_t version; /* Currently 5 for TPM 1.2 and 6 for TPM 2.0 */
> > +    uint32_t bios_sinit_size;
> > +    uint64_t reserved1;
> > +    uint64_t reserved2;
> > +    uint32_t num_logical_procs;
> > +    /* Versions >= 3 && < 5 */
> > +    uint32_t sinit_flags;
> > +    /* Versions >= 5 with updates in version 6 */
> > +    uint32_t mle_flags;
> > +    /* Versions >= 4 */
> > +    /* Ext Data Elements */
> > +} __packed;
>
> It does affect sizeof() here, which I'm unsure is going to matter.

It doesn't hurt anything and makes sure offsets match those in the
specification.

> > +static inline uint64_t txt_bios_data_size(void *heap)
>
> Here, below, and in general: Please try to have code be const-correct, i.e.
> use pointers-to-const wherever applicable.

I assume this doesn't apply to functions returning `void *`.  The
approach used in libc is to accept pointers-to-const but then cast the
constness away for the return value, but this header isn't a widely-used
code.

> > +{
> > +    return *((uint64_t *)heap) - sizeof(uint64_t);
>
> For readability it generally helps if excess parentheses like the ones here
> are omitted.

OK.

> > +static inline uint64_t txt_os_mle_data_size(void *heap)
> > +{
> > +    return *((uint64_t *)(txt_bios_data_start(heap) +
> > +                          txt_bios_data_size(heap))) -
> > +        sizeof(uint64_t);
>
> This line wants indenting a little further, such that the"sizeof" aligns
> with the start of the expression. (Same elsewhere below.)
>
> Jan

Will update.

Regards


From xen-devel-bounces@lists.xenproject.org Fri May 23 20:06:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 20:06:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.996184.1378060 (Exim 4.92)
	(envelope-from )
	id 1uIYeo-000800-Tz; Fri, 23 May 2025 20:06:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 996184.1378060; Fri, 23 May 2025 20:06: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 1uIYeo-0007zt-Qu; Fri, 23 May 2025 20:06:18 +0000
Received: by outflank-mailman (input) for mailman id 996184;
 Fri, 23 May 2025 20:06:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIYen-0007zn-J6
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 20:06:17 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 60d8c93f-3811-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 22:06:14 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 46CBC5C64F4;
 Fri, 23 May 2025 20:03:55 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBAF3C4CEE9;
 Fri, 23 May 2025 20:06: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" 
X-Inumbo-ID: 60d8c93f-3811-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748030771;
	bh=3XuEmljY1PbJ57GjbHXPHclDRoGaKlnj49iLuTE5wJ8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=il4vVWnKGi8ls1RwZcZgUvF314Y6m1zORSsfl5HVK3VmUZmLTnFzsP9zVqjLcIE+3
	 D0YQ/jEb3FkL8lCcrXlpAfPh3T7W4+9tVBP1nwaQJwZghc31R9Zj2FQgf7SBGkzs2h
	 xImK/KPt+X4MwVO8543id1c47mo2hO6Cum7wnIXnCxIQGcdlyC71U8Ql+l1BO3ea1l
	 2QxOegPlv2pQ9krAZe3HGoZu7gbBO7Brd7ti6OpWTqnNInzFEGKw4lzsWkfkBTbcLI
	 iMOMhDNCO+w/BHVp3Sj5462rfPvZG8ogu5dW1P9knfPPtxrHkreTzet8IgthYHCHs/
	 UOlBVHGckcymw==
Date: Fri, 23 May 2025 13:06:08 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
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?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC
 multi-agent driver
In-Reply-To: <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
Message-ID: 
References:  <318044ae12f13b6b297b3f5fda577a1a6cd143da.1747669845.git.oleksii_moisieiev@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

One question for Bertrand below


On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A
> (TF-A) which provides SCMI interface with multi-agnet support, as shown
> below.
> 
>   +-----------------------------------------+
>   |                                         |
>   | EL3 TF-A SCMI                           |
>   +-------+--+-------+--+-------+--+-------++
>   |shmem0 |  |shmem1 |  |shmem2 |  |shmemX |
>   +-----+-+  +---+---+  +--+----+  +---+---+
> smc-id0 |        |         |           |
> agent0  |        |         |           |
>   +-----v--------+---------+-----------+----+
>   |              |         |           |    |
>   |              |         |           |    |
>   +--------------+---------+-----------+----+
>          smc-id1 |  smc-id2|    smc-idX|
>          agent1  |  agent2 |    agentX |
>                  |         |           |
>             +----v---+  +--v-----+  +--v-----+
>             |        |  |        |  |        |
>             | Dom0   |  | Dom1   |  | DomX   |
>             |        |  |        |  |        |
>             |        |  |        |  |        |
>             +--------+  +--------+  +--------+
> 
> The EL3 SCMI multi-agent firmware expected to provide SCMI SMC/HVC shared
> memory transport for every Agent in the system.
> 
> The SCMI Agent transport channel defined by pair:
>  - smc-id: SMC/HVC id used for Doorbell
>  - shmem: shared memory for messages transfer, Xen page aligned,
>  p2m_mmio_direct_nc.
> 
> The follwoing SCMI Agents expected to be defined by SCMI FW to enable SCMI
> multi-agent functionality under Xen:
> - Xen manegement 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 expected to implement following Base protocol messages:
> - BASE_DISCOVER_AGENT
> - BASE_RESET_AGENT_CONFIGURATION (optional)
> - BASE_SET_DEVICE_PERMISSIONS (optional)
> 
> The SCI SCMI SMC multi-agent driver implements following functionality:
> - It's initialized based on the Host DT SCMI node (only one SCMI interface
> is supported) which describes Xen management agent SCMI interface.
> 
> scmi_shm_0 : sram@47ff0000 {
>     compatible = "arm,scmi-shmem";
>     reg = <0x0 0x47ff0000 0x0 0x1000>;
> };
> firmware {
>     scmi: scmi {
>         compatible = "arm,scmi-smc";
>         arm, smc - id = <0x82000002>; // Xen manegement agent smc-id

some extra spaces, it might be a copy/paste error


>         \#address-cells = < 1>;
>         \#size-cells = < 0>;
>         \#access-controller - cells = < 1>;
>         shmem = <&scmi_shm_0>; // Xen manegement agent shmem
> 
>         protocol@X{
>         };
>     };
> };
> 
> - It obtains Xen specific SCMI Agent's configuration from the Host DT,
> probes Agents and build SCMI Agents list; The Agents configuration is taken from:
> 
> chosen {
>   xen,scmi-secondary-agents = <
> 		1 0x82000003 &scmi_shm_1
> 		2 0x82000004 &scmi_shm_2
> 		3 0x82000005 &scmi_shm_3
> 		4 0x82000006 &scmi_shm_4>;
> }
> 
> /{
> 	scmi_shm_1: sram@47ff1000 {
> 		compatible = "arm,scmi-shmem";
> 		reg = <0x0 0x47ff1000 0x0 0x1000>;
> 	};
> 	scmi_shm_2: sram@47ff2000 {
> 		compatible = "arm,scmi-shmem";
> 		reg = <0x0 0x47ff2000 0x0 0x1000>;
> 	};
> 	scmi_shm_3: sram@47ff3000 {
> 		compatible = "arm,scmi-shmem";
> 		reg = <0x0 0x47ff3000 0x0 0x1000>;
> 	};
> }
>   where first item is "agent_id", second - "arm,smc-id", and third - "arm,scmi-shmem" for
>   this agent_id.
> 
>   Note that Xen is the only one entry in the system which need to know
>   about SCMI multi-agent support.
> 
> - 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/HVC 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/HVC 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:
>  - pass dom0_scmi_agent_id= in Xen command line. if not provided
>    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 = "type=scmi_smc_multiagent,agent_id=2"
> 
>  - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond assigned agent_id for
>    the domain, for example:
> 
> iomem = [
>     "47ff2,1@22001",
> ]

Looking at the code and the configuration options, it looks like it is
possible to map a scmi-shmem channel at a different address for the
guest. It seems like it would work. Is that correct?


>  - 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 = "arm,scmi-shmem";
>        reg = <0x0 0x22001000 0x0 0x1000>;
>    };
> 
>    firmware {
>         compatible = "simple-bus";
>             scmi: scmi {
>                 compatible = "arm,scmi-smc";
>                 arm,smc-id = <0x82000004>;
>                 shmem = <&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=<1>" property and DT devices should be bound
> to the Xen SCMI.
> 
> &i2c1 {
> 	access-controllers = <&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
> shell be used:
> 
> dtdev = [
>     "/soc/i2c@e6508000",
> ]
> 
> xl.cfg:dtdev will contain all nodes which are under SCMI management (not only those which are behind IOMMU).
> 
> [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-controllers.yaml
> Signed-off-by: Oleksii Moisieiev 
> Signed-off-by: Grygorii Strashko 

Thanks for the long explanation, great work! I am really looking forward
to have this feature in the tree soon.


> ---
> 
> Changes in v4:
> - toolstack comments from Anthony PERARD
> - added dom0less support
> - added doc for "xen,scmi-secondary-agents"
> 
>  docs/man/xl.cfg.5.pod.in                    |  13 +
>  docs/misc/arm/device-tree/booting.txt       |  60 ++
>  docs/misc/xen-command-line.pandoc           |   9 +
>  tools/libs/light/libxl_arm.c                |   4 +
>  tools/libs/light/libxl_types.idl            |   4 +-
>  tools/xl/xl_parse.c                         |  12 +
>  xen/arch/arm/dom0less-build.c               |  11 +
>  xen/arch/arm/domain_build.c                 |   3 +-
>  xen/arch/arm/firmware/Kconfig               |  11 +
>  xen/arch/arm/firmware/Makefile              |   1 +
>  xen/arch/arm/firmware/scmi-proto.h          | 164 ++++
>  xen/arch/arm/firmware/scmi-shmem.c          | 173 ++++
>  xen/arch/arm/firmware/scmi-shmem.h          |  45 +
>  xen/arch/arm/firmware/scmi-smc-multiagent.c | 860 ++++++++++++++++++++
>  xen/include/public/arch-arm.h               |   3 +
>  15 files changed, 1371 insertions(+), 2 deletions(-)
>  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/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 1ccf50b8ea..302c46d8bc 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -3122,8 +3122,21 @@ single SCMI OSPM agent support.
>  Should be used together with B Xen command line
>  option.
>  
> +=item B
> +
> +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over
> +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmware-A)
> +with a multi SCMI OSPM agent support. The SCMI B should be
> +specified for the guest.
> +
>  =back
>  
> +=item B
> +
> +Specifies a non-zero ARM SCI agent id for the guest. This option is mandatory
> +if the SCMI SMC support is enabled for the guest. The agent ids of domains
> +existing on a single host must be unique and in the range [1..255].
> +
>  =back
>  
>  =back
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> index 8943c04173..c8923ab8b2 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -296,6 +296,20 @@ with the following properties:
>      Should be used together with dom0_scmi_smc_passthrough Xen command line
>      option.
>  
> +    - "scmi_smc_multiagent"
> +
> +    Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI 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_agent_id"
> +    property.
> +
> +- "xen,sci_agent_id"
> +
> +    Specifies a non-zero ARM SCI 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 [1..255].
> +
>  Under the "xen,domain" compatible node, one or more sub-nodes are present
>  for the DomU kernel and ramdisk.
>  
> @@ -764,3 +778,49 @@ The automatically allocated static shared memory will get mapped at
>  0x80000000 in DomU1 guest physical address space, and at 0x90000000 in DomU2
>  guest physical address space. DomU1 is explicitly defined as the owner domain,
>  and DomU2 is the borrower domain.
> +
> +SCMI SMC multi-agent support
> +============================
> +
> +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_SMC_MA)
> +the Xen specific SCMI Agent's configuration shell be provided in the Host DT
> +according to the SCMI compliant EL3 Firmware specification with
> +ARM SMC/HVC transport using property "xen,scmi-secondary-agents" under
> +the top-level "chosen" node:
> +
> +- xen,scmi-secondary-agents
> +
> +    Defines a set of SCMI agents configuration supported by SCMI EL3 FW and
> +    available for Xen. Each Agent defined as triple consisting of:
> +    SCMI agent_id,
> +    SMC/HVC function_id assigned for the agent transport ("arm,smc-id"),
> +    phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem").
> +
> +As an example:
> +
> +chosen {
> +    xen,scmi-secondary-agents = <
> +        1 0x82000003 &scmi_shm_1
> +        2 0x82000004 &scmi_shm_2
> +        3 0x82000005 &scmi_shm_3
> +        4 0x82000006 &scmi_shm_4>;
> +}

NIT: it should be };

Looking at scmi_probe, collect_agents, and the following SCMI
SCMI_BASE_DISCOVER_AGENT request, I wonder: do we actually need this
information?

It looks like we can discover the agend_ids for every channel, I guess
what we need to know is the shmem location for every channel? But the
full list of shmem channel is available below thanks to the scmi-shmem
nodes.

So, we have the list of scmi-shmem anyway, and we can probe the
agent_id. The only parameter left is the smc_id/func_id.

Or maybe smc_id/func_id can be calculated from agent_id?

I am asking mostly because if a user is supposed to add this
xen,scmi-secondary-agents property, where are they supposed to find the
smc_id/func_id information?

It is important that we write down in this document how the user is
expected to find out what 1 is 0x82000003 which is scmi_shm_1.


> +/{
> +        scmi_shm_1: sram@47ff1000 {
> +                compatible = "arm,scmi-shmem";
> +                reg = <0x0 0x47ff1000 0x0 0x1000>;
> +        };
> +        scmi_shm_2: sram@47ff2000 {
> +                compatible = "arm,scmi-shmem";
> +                reg = <0x0 0x47ff2000 0x0 0x1000>;
> +        };
> +        scmi_shm_3: sram@47ff3000 {
> +                compatible = "arm,scmi-shmem";
> +                reg = <0x0 0x47ff3000 0x0 0x1000>;
> +        };
> +        scmi_shm_3: sram@47ff4000 {
> +                compatible = "arm,scmi-shmem";
> +                reg = <0x0 0x47ff4000 0x0 0x1000>;
> +        };

Are these scmi_shm_1 - scmi_shm_3 under the top level device tree node?
Or are under /firmware? Or are they under /chosen?

I take they are under the top level node together with scmi_shm_0?

Can you please also clarify in the document as well?


> +}
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 8e50f6b7c7..bc3c64d6ec 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1091,6 +1091,15 @@ which serves as Driver domain. The SCMI will be disabled for Dom0/hwdom and
>  SCMI nodes removed from Dom0/hwdom device tree.
>  (for example, thin Dom0 with Driver domain use-case).
>  
> +### dom0_scmi_agent_id (ARM)
> +> `= `
> +
> +The option is available when `CONFIG_SCMI_SMC_MA` is compiled in, and allows to
> +enable SCMI functionality for Dom0 by specifying a non-zero ARM SCMI agent id.
> +The SCMI will be disabled for Dom0 if this option is not specified
> +(for example, thin Dom0 or dom0less use-cases).
> +The agent ids of domains existing on a single host must be unique.
> +
>  ### dtuart (ARM)
>  > `= path [:options]`
>  
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index 28ba9eb787..7712f53cd4 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -229,6 +229,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>      case LIBXL_ARM_SCI_TYPE_SCMI_SMC:
>          config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
>          break;
> +    case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT:
> +        config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
> +        config->arch.arm_sci_agent_id = d_config->b_info.arch_arm.arm_sci.agent_id;
> +        break;
>      default:
>          LOG(ERROR, "Unknown ARM_SCI type %d",
>              d_config->b_info.arch_arm.arm_sci.type);
> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
> index aa2190ab5b..11e31ce786 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -553,11 +553,13 @@ libxl_sve_type = Enumeration("sve_type", [
>  
>  libxl_arm_sci_type = Enumeration("arm_sci_type", [
>      (0, "none"),
> -    (1, "scmi_smc")
> +    (1, "scmi_smc"),
> +    (2, "scmi_smc_multiagent")
>      ], init_val = "LIBXL_ARM_SCI_TYPE_NONE")
>  
>  libxl_arm_sci = Struct("arm_sci", [
>      ("type", libxl_arm_sci_type),
> +    ("agent_id", uint8)
>      ])
>  
>  libxl_rdm_reserve = Struct("rdm_reserve", [
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index bd22be9d33..81aa3797e3 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci,
>              }
>          }
>  
> +        if (MATCH_OPTION("agent_id", ptr, oparg)) {
> +            unsigned long val = parse_ulong(oparg);
> +
> +            if (!val || val > 255) {
> +                fprintf(stderr, "An invalid ARM_SCI agent_id specified (%lu). Valid range [1..255]\n",
> +                        val);
> +                ret = ERROR_INVAL;
> +                goto parse_error;
> +            }
> +            arm_sci->agent_id = val;
> +        }
> +
>          ptr = strtok(NULL, ",");
>      }
>  
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index 0a00f03a25..43d21eb889 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -835,6 +835,17 @@ int __init domu_dt_sci_parse(struct dt_device_node *node,
>          d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
>      else if ( !strcmp(sci_type, "scmi_smc") )
>          d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
> +    else if ( !strcmp(sci_type, "scmi_smc_multiagent") )
> +    {
> +        uint32_t agent_id = 0;
> +
> +        if ( !dt_property_read_u32(node, "xen,sci_agent_id", &agent_id) ||
> +             !agent_id )

shouldn't we check that agent_id <= 255 ?


> +            return -EINVAL;
> +
> +        d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
> +        d_cfg->arch.arm_sci_agent_id = 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 36d28b52a4..0c9274a2b3 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -616,7 +616,8 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
>                   dt_property_name_is_equal(prop, "linux,uefi-mmap-start") ||
>                   dt_property_name_is_equal(prop, "linux,uefi-mmap-size") ||
>                   dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-size") ||
> -                 dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver"))
> +                 dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver") ||
> +                 dt_property_name_is_equal(prop, "xen,scmi-secondary-agents") )
>                  continue;
>  
>              if ( dt_property_name_is_equal(prop, "xen,dom0-bootargs") )
> diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
> index 5c5f0880c4..6b051c8ada 100644
> --- a/xen/arch/arm/firmware/Kconfig
> +++ b/xen/arch/arm/firmware/Kconfig
> @@ -29,6 +29,17 @@ 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"
> +	select ARM_SCI
> +	help
> +	  Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from Domains
> +	  to EL3 firmware (TF-A) which supports multi-agent feature.
> +	  This feature allows to enable SCMI per Domain using unique SCMI agent_id,
> +	  so Domain is identified by EL3 firmware as an SCMI Agent and can access
> +	  allowed platform resources through dedicated SMC/HVC Shared memory based
> +	  transport.
> +
>  endchoice
>  
>  endmenu
> diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile
> index 71bdefc24a..37927e690e 100644
> --- a/xen/arch/arm/firmware/Makefile
> +++ b/xen/arch/arm/firmware/Makefile
> @@ -1,2 +1,3 @@
>  obj-$(CONFIG_ARM_SCI) += sci.o
>  obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
> +obj-$(CONFIG_SCMI_SMC_MA) += scmi-shmem.o scmi-smc-multiagent.o
> diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/scmi-proto.h
> new file mode 100644
> index 0000000000..3f4b9c5d6b
> --- /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) 2024 EPAM Systems
> + */
> +
> +#ifndef XEN_ARCH_ARM_SCI_SCMI_PROTO_H_
> +#define XEN_ARCH_ARM_SCI_SCMI_PROTO_H_

NIT: 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 = SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr);
> +    hdr->type = SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr);
> +    hdr->protocol = SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr);
> +}
> +
> +static inline int scmi_to_xen_errno(int scmi_status)
> +{
> +    if ( scmi_status == 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 /* XEN_ARCH_ARM_SCI_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/scmi-shmem.c
> new file mode 100644
> index 0000000000..dd613ee0b5
> --- /dev/null
> +++ b/xen/arch/arm/firmware/scmi-shmem.c
> @@ -0,0 +1,173 @@
> +/* 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
> + */
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +
> +#include "scmi-proto.h"
> +#include "scmi-shmem.h"

This code is written more generically than the description implies. If
we only want to make SMC calls to TF-A on EL3 and exchange data with it
over shared memory, then I think:
- we don't need the __iomem tag, as there is no MMIO
- we only need a DMB, not a DSB (readl and writel imply DSB, use only
  readl_relaxed and writel_relaxed)

On the other hand, if we also want to handle the case where the SCMI
server could be on a separate co-processor, then what this code is doing
is not sufficient because we also need a dcache flush, in addition to
the DSB.

Bertrand, can you double-check?


> +/*
> + * Copy data from IO memory space to "real" memory space.
> + */
> +static void __memcpy_fromio(void *to, const volatile void __iomem *from,
> +                            size_t count)
> +{
> +    while ( count && !IS_ALIGNED((unsigned long)from, 4) )
> +    {
> +        *(u8 *)to = readb_relaxed(from);
> +        from++;
> +        to++;
> +        count--;
> +    }
> +
> +    while ( count >= 4 )
> +    {
> +        *(u32 *)to = readl_relaxed(from);
> +        from += 4;
> +        to += 4;
> +        count -= 4;
> +    }
> +
> +    while ( count )
> +    {
> +        *(u8 *)to = readb_relaxed(from);
> +        from++;
> +        to++;
> +        count--;
> +    }
> +}
> +
> +/*
> + * Copy data from "real" memory space to IO memory space.
> + */
> +static void __memcpy_toio(volatile void __iomem *to, const void *from,
> +                          size_t count)
> +{
> +    while ( count && !IS_ALIGNED((unsigned long)to, 4) )
> +    {
> +        writeb_relaxed(*(u8 *)from, to);
> +        from++;
> +        to++;
> +        count--;
> +    }
> +
> +    while ( count >= 4 )
> +    {
> +        writel_relaxed(*(u32 *)from, to);
> +        from += 4;
> +        to += 4;
> +        count -= 4;
> +    }
> +
> +    while ( count )
> +    {
> +        writeb_relaxed(*(u8 *)from, to);
> +        from++;
> +        to++;
> +        count--;
> +    }
> +}

I don't understand why we need __memcpy_fromio and __memcpy_toio: can't
we use a simple memcpy?


> +static inline int
> +shmem_channel_is_free(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, int len)
> +{
> +    int ret;
> +
> +    if ( (len + sizeof(shmem->msg_header)) > SCMI_SHMEM_MAPPED_SIZE )
> +    {
> +        printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is invalid\n");
> +        return -EINVAL;
> +    }
> +
> +    ret = shmem_channel_is_free(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 *shmem,
> +                       scmi_msg_header_t *hdr, void *data, int len)
> +{
> +    int recv_len;
> +    int ret;
> +    int pad = sizeof(hdr->status);
> +
> +    if ( len >= SCMI_SHMEM_MAPPED_SIZE - sizeof(shmem) )
> +    {
> +        printk(XENLOG_ERR
> +               "scmi: Wrong size of input smc message. Data may be invalid\n");
> +        return -EINVAL;
> +    }
> +
> +    ret = shmem_channel_is_free(shmem);
> +    if ( ret )
> +        return ret;
> +
> +    recv_len = 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 = readl(&shmem->msg_payload);
> +    recv_len = recv_len > pad ? recv_len - pad : 0;
> +
> +    ret = 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/scmi-shmem.h
> new file mode 100644
> index 0000000000..2f8e23ff76
> --- /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 XEN_ARCH_ARM_SCI_SCMI_SHMEM_H_
> +#define XEN_ARCH_ARM_SCI_SCMI_SHMEM_H_

NIT: 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, int len);
> +
> +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shmem,
> +                       scmi_msg_header_t *hdr, void *data, int len);
> +#endif /* XEN_ARCH_ARM_SCI_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/firmware/scmi-smc-multiagent.c
> new file mode 100644
> index 0000000000..e023bca3a1
> --- /dev/null
> +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c
> @@ -0,0 +1,860 @@
> +/* 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 "scmi-proto.h"
> +#include "scmi-shmem.h"
> +
> +#define SCMI_AGENT_ID_INVALID 0xFF
> +
> +static uint8_t __initdata opt_dom0_scmi_agent_id = SCMI_AGENT_ID_INVALID;
> +integer_param("dom0_scmi_agent_id", opt_dom0_scmi_agent_id);
> +
> +#define SCMI_SECONDARY_AGENTS "xen,scmi-secondary-agents"
> +
> +#define HYP_CHANNEL 0x0
> +
> +struct scmi_channel {
> +    uint32_t agent_id;
> +    uint32_t func_id;
> +    domid_t domain_id;
> +    uint64_t paddr;
> +    uint64_t len;
> +    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;
> +    struct dt_device_node *dt_dev;
> +};
> +
> +static struct scmi_data scmi_data;
> +
> +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 = shmem_put_message(chan_info->shmem, hdr, data, len);
> +    if ( ret )
> +        return ret;
> +
> +    arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0, &resp);
> +
> +    if ( resp.a0 )
> +        return -EOPNOTSUPP;

Why if repo.a0 != 0 then we assume -EOPNOTSUPP? Is this part of the SCMI
specification?


> +    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 = 0;
> +
> +    ASSERT(chan_info && chan_info->shmem);
> +
> +    if ( !hdr )
> +        return -EINVAL;
> +
> +    spin_lock(&chan_info->lock);
> +
> +    printk(XENLOG_DEBUG
> +           "scmi: agent_id = %d msg_id = %x type = %d, proto = %x\n",
> +           chan_info->agent_id, hdr->id, hdr->type, hdr->protocol);
> +
> +    ret = send_smc_message(chan_info, hdr, tx_data, tx_size);
> +    if ( ret )
> +        goto clean;
> +
> +    ret = shmem_get_response(chan_info->shmem, hdr, rx_data, rx_size);
> +
> +clean:
> +    printk(XENLOG_DEBUG
> +           "scmi: get smc response agent_id = %d msg_id = %x proto = %x res=%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 = false;
> +
> +    spin_lock(&scmi_data.channel_list_lock);
> +    list_for_each_entry(curr, &scmi_data.channel_list, list)
> +    {
> +        if ( curr->agent_id == agent_id )
> +        {
> +            found = 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 = ERR_PTR(-ENOENT);
> +
> +    spin_lock(&scmi_data.channel_list_lock);
> +    list_for_each_entry(curr, &scmi_data.channel_list, list)
> +    {
> +        if ( curr->agent_id == agent_id )
> +        {
> +            if ( curr->domain_id != DOMID_INVALID )
> +            {
> +                ret = ERR_PTR(-EEXIST);
> +                break;
> +            }
> +
> +            curr->domain_id = d->domain_id;
> +            ret = curr;
> +            break;
> +        }
> +    }
> +
> +    spin_unlock(&scmi_data.channel_list_lock);
> +
> +    return ret;
> +}
> +
> +static void relinquish_scmi_channel(struct scmi_channel *channel)
> +{
> +    ASSERT(channel != NULL);
> +
> +    spin_lock(&scmi_data.channel_list_lock);
> +    channel->domain_id = DOMID_INVALID;
> +    spin_unlock(&scmi_data.channel_list_lock);
> +}
> +
> +static int map_channel_memory(struct scmi_channel *channel)
> +{
> +    ASSERT(channel && channel->paddr);
> +    channel->shmem = ioremap_nocache(channel->paddr, SCMI_SHMEM_MAPPED_SIZE);

ioremap is for MMIO, if these shared memory channels are on DDR, then it
would not be the right call. Are the "arm,scmi-shmem" address ranges
part of the memory node ranges? Or are they completely separate?

Also, why nocache? Wouldn't we want ioremap_cache?


> +    if ( !channel->shmem )
> +        return -ENOMEM;
> +
> +    channel->shmem->channel_status = SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE;
> +    printk(XENLOG_DEBUG "scmi: Got shmem %lx after vmap %p\n", channel->paddr,
> +           channel->shmem);
> +
> +    return 0;
> +}
> +
> +static void unmap_channel_memory(struct scmi_channel *channel)
> +{
> +    ASSERT(channel && channel->shmem);
> +    iounmap(channel->shmem);
> +    channel->shmem = NULL;
> +}
> +
> +static struct scmi_channel *smc_create_channel(uint32_t agent_id,
> +                                               uint32_t func_id, uint64_t addr)
> +{
> +    struct scmi_channel *channel;
> +
> +    channel = get_channel_by_id(agent_id);
> +    if ( channel )
> +        return ERR_PTR(EEXIST);
> +
> +    channel = xmalloc(struct scmi_channel);
> +    if ( !channel )
> +        return ERR_PTR(ENOMEM);
> +
> +    spin_lock_init(&channel->lock);
> +    channel->agent_id = agent_id;
> +    channel->func_id = func_id;
> +    channel->domain_id = DOMID_INVALID;
> +    channel->shmem = NULL;
> +    channel->paddr = addr;
> +    list_add_tail(&channel->list, &scmi_data.channel_list);
> +    return channel;
> +}
> +
> +static void free_channel_list(void)
> +{
> +    struct scmi_channel *curr, *_curr;
> +
> +    list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list)
> +    {
> +        list_del(&curr->list);
> +        xfree(curr);
> +    }
> +}
> +
> +static int __init
> +scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *addr,
> +                              u64 *size)
> +{
> +    struct dt_device_node *shmem_node;
> +    const __be32 *prop;
> +
> +    prop = dt_get_property(scmi_node, "shmem", NULL);
> +    if ( !prop )
> +        return -EINVAL;
> +
> +    shmem_node = dt_find_node_by_phandle(be32_to_cpup(prop));
> +    if ( IS_ERR_OR_NULL(shmem_node) )
> +    {
> +        printk(XENLOG_ERR
> +               "scmi: Device tree error, can't parse reserved memory %ld\n",
> +               PTR_ERR(shmem_node));
> +        return PTR_ERR(shmem_node);
> +    }
> +
> +    return dt_device_get_address(shmem_node, 0, addr, size);
> +}
> +
> +/*
> + * Handle Dom0 SCMI specific DT nodes
> + *
> + * Make a decision on copying SCMI specific nodes into Dom0 device tree.
> + * For SCMI multi-agent case:
> + * - shmem nodes will not be copied and generated instead if SCMI
> + *   is enabled for Dom0
> + * - scmi node will be copied if SCMI is enabled for Dom0
> + */
> +static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node *node)
> +{
> +    static const struct dt_device_match skip_matches[] __initconst = {
> +        DT_MATCH_COMPATIBLE("arm,scmi-shmem"),
> +        { /* sentinel */ },
> +    };
> +    static const struct dt_device_match scmi_matches[] __initconst = {
> +        DT_MATCH_PATH("/firmware/scmi"),
> +        { /* sentinel */ },
> +    };
> +
> +    if ( !scmi_data.initialized )
> +        return false;
> +
> +    /* always drop shmem */
> +    if ( dt_match_node(skip_matches, node) )
> +    {
> +        dt_dprintk("  Skip scmi shmem\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;
> +}
> +
> +/*
> + * Finalize Dom0 SCMI specific DT nodes
> + *
> + * if SCMI is enabled for Dom0:
> + * - generate shmem node
> + * - map SCMI shmem MMIO into Dom0
> + */
> +static int scmi_dt_finalize(struct domain *d, void *fdt)
> +{
> +    __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
> +    struct scmi_channel *channel;
> +    int nodeoffset;
> +    __be32 *cells;
> +    __be32 val;
> +    char buf[64];
> +    int res, rc;
> +
> +    if ( !sci_domain_is_enabled(d) )
> +        return 0;
> +
> +    channel = d->arch.sci_data;
> +
> +    /*
> +     * Replace "arm,smc-id" with proper value assigned for Dom0 SCMI channel
> +     */
> +    nodeoffset = fdt_node_offset_by_compatible(fdt, -1, "arm,scmi-smc");
> +    if ( nodeoffset < 0 )
> +        return -ENODEV;
> +
> +    cells = (__be32 *)&val;
> +    dt_set_cell(&cells, 1, channel->func_id);
> +    res = fdt_setprop_inplace(fdt, nodeoffset, "arm,smc-id", &val, sizeof(val));
> +    if ( res )
> +        return -EINVAL;
> +

Are you sure it is worth to go through all this trouble to modify FDT in
place when we could simply generate the DT node from scratch like we do
for example for the GIC? This seems to be more error prone as well. Is
generating it from scratch is really difficult? If it is difficult then OK.


> +    /*
> +     * All SCMI shmem nodes should be removed from Dom0 DT at this point, so
> +     * the shmem node for Dom0 need to be generated from SCMI channel assigned
> +     * to Dom0.
> +     * The original SCMI shmem node from platform DT is used by Xen SCMI driver
> +     * itself as privileged channel (agent_id=0) to manage other SCMI
> +     * agents (domains).
> +     */
> +    snprintf(buf, sizeof(buf), "scmi-shmem@%lx", channel->paddr);
> +
> +    res = fdt_begin_node(fdt, buf);
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_string(fdt, "compatible", "arm,scmi-shmem");
> +    if ( res )
> +        return res;
> +
> +    cells = ®[0];
> +
> +    dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
> +                       channel->paddr, SCMI_SHMEM_MAPPED_SIZE);
> +
> +    res = fdt_property(fdt, "reg", reg, sizeof(reg));
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_cell(fdt, "phandle", scmi_data.shmem_phandle);
> +    if ( res )
> +        return res;
> +
> +    res = fdt_end_node(fdt);
> +    if ( res )
> +        return res;
> +
> +    /*
> +     * Map SCMI shmem into Dom0 here as shmem nodes are excluded from
> +     * generic Dom0 DT processing
> +     */
> +    res = iomem_permit_access(d, paddr_to_pfn(channel->paddr),
> +                              paddr_to_pfn(channel->paddr +
> +                                           SCMI_SHMEM_MAPPED_SIZE - 1));
> +    if ( res )
> +        return res;
> +
> +    res = map_regions_p2mt(d, gaddr_to_gfn(channel->paddr),
> +                           PFN_UP(SCMI_SHMEM_MAPPED_SIZE),
> +                           maddr_to_mfn(channel->paddr), p2m_mmio_direct_nc);
> +    if ( res )
> +    {
> +        rc = iomem_deny_access(d, paddr_to_pfn(channel->paddr),
> +                               paddr_to_pfn(channel->paddr +
> +                                            SCMI_SHMEM_MAPPED_SIZE - 1));
> +        if ( rc )
> +            printk(XENLOG_ERR "scmi: Unable to deny iomem access , err = %d\n",
> +                   rc);
> +    }
> +
> +    return res;
> +}
> +
> +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;
> +    int ret;
> +
> +    channel = get_channel_by_id(HYP_CHANNEL);
> +    if ( !channel )
> +        return -EINVAL;
> +
> +    hdr.id = SCMI_BASE_SET_DEVICE_PERMISSIONS;
> +    hdr.type = 0;
> +    hdr.protocol = SCMI_BASE_PROTOCOL;
> +
> +    tx.agent_id = agent_id;
> +    tx.device_id = device_id;
> +    tx.flags = flags;
> +
> +    ret = do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0);
> +    if ( ret == -EOPNOTSUPP )
> +        return 0;

Is it actually OK to pretend that everything worked if the return is
-EOPNOTSUPP? I mean that in this case can we assume that the device is
actually assigned anyway? Wouldn't follow up SCMI operations on this
device fail?


> +    return ret;
> +}
> +
> +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 = 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 ( ac_spec->np != scmi_data.dt_dev )
> +        return 0;

I wonder if this should be an error


> +    agent_channel = d->arch.sci_data;
> +
> +    spin_lock(&agent_channel->lock);
> +
> +    ret = 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 __init int collect_agents(struct dt_device_node *scmi_node)
> +{
> +    const struct dt_device_node *chosen_node;
> +    const __be32 *prop;
> +    uint32_t len, i;
> +
> +    chosen_node = dt_find_node_by_path("/chosen");
> +    if ( !chosen_node )
> +    {
> +        printk(XENLOG_ERR "scmi: chosen node not found\n");
> +        return -ENOENT;
> +    }
> +
> +    prop = dt_get_property(chosen_node, SCMI_SECONDARY_AGENTS, &len);
> +    if ( !prop )
> +    {
> +        printk(XENLOG_WARNING "scmi: No %s property found\n",
> +               SCMI_SECONDARY_AGENTS);
> +        return -ENODEV;
> +    }
> +
> +    if ( len % (3 * sizeof(uint32_t)) )
> +    {
> +        printk(XENLOG_ERR "scmi: Invalid length of %s property: %d\n",
> +               SCMI_SECONDARY_AGENTS, len);
> +        return -EINVAL;
> +    }
> +
> +    for ( i = 0; i < len / (3 * sizeof(uint32_t)); i++ )
> +    {
> +        uint32_t agent_id = be32_to_cpu(*prop++);
> +        uint32_t smc_id = be32_to_cpu(*prop++);
> +        uint32_t shmem_phandle = be32_to_cpu(*prop++);
> +        struct dt_device_node *node = dt_find_node_by_phandle(shmem_phandle);
> +        u64 addr, size;
> +        int ret;
> +
> +        if ( !node )
> +        {
> +            printk(XENLOG_ERR "scmi: Could not find shmem node for agent %d\n",
> +                   agent_id);
> +            return -EINVAL;
> +        }
> +
> +        ret = dt_device_get_address(node, 0, &addr, &size);
> +        if ( ret )
> +        {
> +            printk(XENLOG_ERR
> +                   "scmi: Could not read shmem address for agent %d: %d",
> +                   agent_id, ret);
> +            return ret;
> +        }
> +
> +        if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) )
> +        {
> +            printk(XENLOG_ERR "scmi: shmem memory is not aligned\n");
> +            return -EINVAL;
> +        }
> +
> +        ret = PTR_RET(smc_create_channel(agent_id, smc_id, addr));
> +        if ( ret )
> +        {
> +            printk(XENLOG_ERR "scmi: Could not create channel for agent %d: %d",
> +                   agent_id, ret);
> +            return ret;
> +        }
> +
> +        printk(XENLOG_DEBUG "scmi: Agent %d SMC %X addr %lx\n", agent_id,
> +               smc_id, addr);
> +    }
> +
> +    return 0;
> +}
> +
> +static int scmi_domain_init(struct domain *d,
> +                            struct xen_domctl_createdomain *config)
> +{
> +    struct scmi_channel *channel;
> +    int ret;
> +
> +    if ( !scmi_data.initialized )
> +        return 0;
> +
> +    /*
> +     * Special case for Dom0 - the SCMI support is enabled basing on
> +     * "dom0_sci_agent_id" Xen command line parameter
> +     */
> +    if ( is_hardware_domain(d) )
> +    {
> +        if ( opt_dom0_scmi_agent_id != SCMI_AGENT_ID_INVALID )
> +        {
> +            config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
> +            config->arch.arm_sci_agent_id = opt_dom0_scmi_agent_id;
> +        }
> +        else
> +            config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE;
> +    }
> +
> +    if ( config->arch.arm_sci_type == XEN_DOMCTL_CONFIG_ARM_SCI_NONE )
> +        return 0;
> +
> +    channel = 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 = 0x%x, domain_id = %d paddr = 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_permission
> +     * domctl.

Ideally this should not be needed but I understand we don't have an
easy solution, I think we can go ahead with this for now.


> +     */
> +    if ( hardware_domain && !is_hardware_domain(d) )
> +    {
> +        ret = iomem_permit_access(hardware_domain, paddr_to_pfn(channel->paddr),
> +                                  paddr_to_pfn(channel->paddr + PAGE_SIZE - 1));
> +        if ( ret )
> +            goto error;
> +    }
> +
> +    d->arch.sci_data = channel;
> +    d->arch.sci_enabled = true;
> +
> +    return 0;
> +
> +error:
> +    relinquish_scmi_channel(channel);
> +    return ret;
> +}
> +
> +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config)
> +{
> +    if ( config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_NONE &&
> +         config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA )
> +    {
> +        dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n");
> +        return -EINVAL;
> +    }
> +    else if ( config->arch.arm_sci_type ==
> +              XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA &&
> +              config->arch.arm_sci_agent_id == 0 )
> +    {
> +        dprintk(XENLOG_INFO,
> +                "scmi: A zero ARM SCMI agent_id is not supported\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 = d->arch.sci_data;
> +
> +    spin_lock(&agent_channel->lock);
> +    tx.agent_id = agent_channel->agent_id;
> +    spin_unlock(&agent_channel->lock);
> +
> +    channel = get_channel_by_id(HYP_CHANNEL);
> +    if ( !channel )
> +    {
> +        printk(XENLOG_ERR
> +               "scmi: Unable to get Hypervisor scmi channel for domain %d\n",
> +               d->domain_id);
> +        return -EINVAL;
> +    }
> +
> +    hdr.id = SCMI_BASE_RESET_AGENT_CONFIGURATION;
> +    hdr.type = 0;
> +    hdr.protocol = SCMI_BASE_PROTOCOL;
> +
> +    tx.flags = 0;
> +
> +    ret = do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0);
> +    if ( ret == -EOPNOTSUPP )
> +        return 0;
> +
> +    return ret;
> +}
> +
> +static void scmi_domain_destroy(struct domain *d)
> +{
> +    struct scmi_channel *channel;
> +
> +    if ( !d->arch.sci_data )
> +        return;
> +
> +    channel = 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 = NULL;
> +    d->arch.sci_enabled = true;
> +
> +    spin_unlock(&channel->lock);
> +}
> +
> +static bool scmi_handle_call(struct cpu_user_regs *regs)
> +{
> +    uint32_t fid = (uint32_t)get_user_reg(regs, 0);
> +    struct scmi_channel *agent_channel;
> +    struct domain *d = current->domain;
> +    struct arm_smccc_res resp;
> +    bool res = false;
> +
> +    if ( !sci_domain_is_enabled(d) )
> +        return false;
> +
> +    agent_channel = d->arch.sci_data;
> +    spin_lock(&agent_channel->lock);
> +
> +    if ( agent_channel->func_id != fid )
> +    {
> +        res = false;
> +        goto unlock;
> +    }
> +
> +    arm_smccc_1_1_smc(fid,
> +                      get_user_reg(regs, 1),
> +                      get_user_reg(regs, 2),
> +                      get_user_reg(regs, 3),
> +                      get_user_reg(regs, 4),
> +                      get_user_reg(regs, 5),
> +                      get_user_reg(regs, 6),
> +                      get_user_reg(regs, 7),
> +                      &resp);
> +
> +    set_user_reg(regs, 0, resp.a0);
> +    set_user_reg(regs, 1, resp.a1);
> +    set_user_reg(regs, 2, resp.a2);
> +    set_user_reg(regs, 3, resp.a3);
> +    res = true;
> +unlock:
> +    spin_unlock(&agent_channel->lock);
> +
> +    return res;
> +}
> +
> +static const struct sci_mediator_ops scmi_ops = {
> +    .domain_init = scmi_domain_init,
> +    .domain_destroy = scmi_domain_destroy,
> +    .relinquish_resources = scmi_relinquish_resources,
> +    .handle_call = scmi_handle_call,
> +    .dom0_dt_handle_node = scmi_dt_handle_node,
> +    .dom0_dt_finalize = scmi_dt_finalize,
> +    .domain_sanitise_config = scmi_domain_sanitise_config,
> +    .assign_dt_device = 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 __init int scmi_probe(struct dt_device_node *scmi_node, const void *data)
> +{
> +    u64 addr, size;
> +    int ret, i;
> +    struct scmi_channel *channel, *agent_channel;
> +    int n_agents;
> +    scmi_msg_header_t hdr;
> +    struct scmi_msg_base_attributes_p2a rx;
> +
> +    ASSERT(scmi_node != NULL);
> +
> +    INIT_LIST_HEAD(&scmi_data.channel_list);
> +    spin_lock_init(&scmi_data.channel_list_lock);
> +
> +    if ( !acpi_disabled )
> +    {
> +        printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n");
> +        return -EINVAL;
> +    }
> +
> +    ret = scmi_check_smccc_ver();
> +    if ( ret )
> +        return ret;
> +
> +    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;
> +    }
> +
> +    /* save shmem phandle and re-use it fro Dom0 DT shmem node */
> +    if ( !dt_property_read_u32(scmi_node, "shmem", &scmi_data.shmem_phandle) )
> +    {
> +        printk(XENLOG_ERR "scmi: unable to read shmem phandle from DT\n");
> +        return -ENOENT;
> +    }
> +
> +    ret = scmi_dt_read_hyp_channel_addr(scmi_node, &addr, &size);
> +    if ( IS_ERR_VALUE(ret) )
> +        return -ENOENT;
> +
> +    if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) )
> +    {
> +        printk(XENLOG_ERR "scmi: shmem memory is not aligned\n");
> +        return -EINVAL;
> +    }
> +
> +    scmi_data.dt_dev = scmi_node;
> +
> +    channel = smc_create_channel(HYP_CHANNEL, scmi_data.func_id, addr);
> +    if ( IS_ERR(channel) )
> +        goto out;
> +
> +    ret = map_channel_memory(channel);
> +    if ( ret )
> +        goto out;
> +
> +    channel->domain_id = DOMID_XEN;
> +
> +    hdr.id = SCMI_BASE_PROTOCOL_ATTIBUTES;
> +    hdr.type = 0;
> +    hdr.protocol = SCMI_BASE_PROTOCOL;
> +
> +    ret = do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx));
> +    if ( ret )
> +        goto error;
> +
> +    n_agents = SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes);
> +    printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents);
> +
> +    ret = collect_agents(scmi_node);
> +    if ( ret )
> +        goto error;
> +
> +    i = 1;
> +
> +    list_for_each_entry(agent_channel, &scmi_data.channel_list, list)
> +    {
> +        struct scmi_msg_base_discover_agent_p2a da_rx;
> +        struct scmi_msg_base_discover_agent_a2p da_tx;
> +
> +        ret = map_channel_memory(agent_channel);
> +        if ( ret )
> +            goto error;
> +
> +        hdr.id = SCMI_BASE_DISCOVER_AGENT;
> +        hdr.type = 0;
> +        hdr.protocol = SCMI_BASE_PROTOCOL;
> +
> +        da_tx.agent_id = agent_channel->agent_id;
> +
> +        ret = do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_rx,
> +                          sizeof(da_rx));
> +        if ( agent_channel->domain_id != DOMID_XEN )
> +            unmap_channel_memory(agent_channel);
> +        if ( ret )
> +            goto error;
> +
> +        printk(XENLOG_DEBUG "id=0x%x name=%s\n", da_rx.agent_id, da_rx.name);
> +
> +        agent_channel->agent_id = da_rx.agent_id;

It is OK to set agent_channel->agent_id to the value provided by the
SCMI server, but if we are also taking the agent_channel->agent_id value
from the user via device tree, shouldn't we throw an error if there is a
mismatch?

Or even better: can we avoid taking the value via device tree to make it
easier to configure?


> +        if ( i > n_agents )
> +            break;
> +
> +        i++;
> +    }
> +
> +    ret = sci_register(&scmi_ops);
> +    if ( ret )
> +    {
> +        printk(XENLOG_ERR "SCMI: mediator already registered (ret = %d)\n",
> +               ret);
> +        return ret;
> +    }
> +
> +    scmi_data.initialized = true;
> +    goto out;
> +
> +error:
> +    unmap_channel_memory(channel);
> +    free_channel_list();
> +out:
> +    return ret;
> +}
> +
> +static const struct dt_device_match scmi_smc_match[] __initconst = {
> +    DT_MATCH_COMPATIBLE("arm,scmi-smc"),
> +    { /* sentinel */ },
> +};
> +
> +DT_DEVICE_START(scmi_smc_ma, "SCMI SMC MEDIATOR", DEVICE_FIRMWARE)
> +        .dt_match = scmi_smc_match,
> +        .init = 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 095b1a23e3..30e46de6d7 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
>  
>  struct xen_arch_domainconfig {
>      /* IN/OUT */
> @@ -355,6 +356,8 @@ struct xen_arch_domainconfig {
>      uint32_t clock_frequency;
>      /* IN */
>      uint8_t arm_sci_type;
> +    /* IN */
> +    uint8_t arm_sci_agent_id;
>  };
>  #endif /* __XEN__ || __XEN_TOOLS__ */
>  
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Fri May 23 20:19:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 20:19:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.996201.1378070 (Exim 4.92)
	(envelope-from )
	id 1uIYrl-0001Ps-4y; Fri, 23 May 2025 20:19:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 996201.1378070; Fri, 23 May 2025 20:19: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 1uIYrl-0001Pl-2H; Fri, 23 May 2025 20:19:41 +0000
Received: by outflank-mailman (input) for mailman id 996201;
 Fri, 23 May 2025 20:19:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIYrj-0001Pf-H1
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 20:19:39 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3f7d7b59-3813-11f0-a2fb-13f23c93f187;
 Fri, 23 May 2025 22:19:38 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 24AAA435AF;
 Fri, 23 May 2025 20:19:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15AFCC4CEE9;
 Fri, 23 May 2025 20:19: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" 
X-Inumbo-ID: 3f7d7b59-3813-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748031576;
	bh=5AJ+0bOdoSPrkraz5Ud3mdFPqMrnrxqcw8RFggALXH4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=eyQANeDhq7mswN9RKVt8WjPcIPK6UkAGaIiXDEd+LpGwIjirXc3UKYy+t1yGMOmu/
	 ObZDS5pneYwihmUU0wElFunhW/lDDcSqfZaS8wFv/fk5+ds5D6bcKga6XS8g/lvy6O
	 vIMRafzO8gttH8GAe7Spl40OC8mPXRCRtZzT5WHFArSAYP57Gf42nYI7Em5jhgs+Lw
	 JK61esqAr0pUkk8kUlRNr+MhmyAX4dhfYUZ/D+wjleKO8GyOPZHN1zsGV2WMPpO4sR
	 IZ/fMkY/Z+8pMf9TZua7CANiCJBlaDkWDFtCsVXH9Aqkf1I/Tl4Tp2uywfDQiCKmF5
	 3VdEWXZTH99Rg==
Date: Fri, 23 May 2025 13:19:32 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
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?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Volodymyr Babchuk , 
    Grygorii Strashko 
Subject: Re: [RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node
 for Xen agent
In-Reply-To: <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
Message-ID: 
References:  <3f7e1e99f5d1018064f3c4825aff16bd487cf558.1747669845.git.oleksii_moisieiev@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1382825891-1748031575=:147219"

  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-1382825891-1748031575=:147219
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> From: Grygorii Strashko 
> 
> Proposal description to add separate SCMI DT node for Xen management agent
> under "chosen" or xen-config node, like Hyperlaunch "xen,config".

I think it is OK to place a larger "xen,config" node under /chosen with
more information for Xen to setup SCMI more easily.


> This proposal introduces a new approach to the Xen multi-domain
> configuration, where all Xen-specific configuration has been moved
> under the "/chosen" node. This requires less Dom0 device tree
> manipulation and isolates Xen configuration from domain configuration.
> 
> This approach provides the following device tree (DT) parameters:
> 
> - "xen,scmi-secondary-agents": A Xen-specific parameter under the
> "/chosen" node, which describes the SCMI agent configuration for
> the domains.
> - the SCMI configuration for Xen (privileged agent) and the shared
> memory configuration for all agents are provided under the "/chosen"
> node and are used strictly by Xen for its initial configuration.
> - the scmi_shm and SCMI configuration for Dom0 are placed in the
> "/firmware/scmi" node so that they can be moved to Dom0 without
> any changes.

Isn't the SCMI configuration present in /firmware/scmi referring to the
privileged agent=0 meant to be used by Xen?

I certainly see benefits in simplifying the configuration and especially
reducing the amount of changes a user might have to make on the
underlying device tree, but if the user needs to change /firmware/scmi
with the Dom0 information, it seems more dangerous and error prone than
the previous approach.


> This configuration allows the use of Xen-specific nodes to provide
> information strictly needed by Xen while using the default SCMI
> configuration for Dom0 and other domains. As a result, no additional
> bindings need to be introduced to the device tree.

This is not actually implemented by this patch series, right?


> Signed-off-by: Grygorii Strashko 
> Signed-off-by: Oleksii Moisieiev 
> ---
> 
> 
> 
>  .../arm/firmware/arm-scmi-proposal.rst        | 224 ++++++++++++++++++
>  1 file changed, 224 insertions(+)
>  create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
> 
> diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst b/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
> new file mode 100644
> index 0000000000..fcc2ed2b65
> --- /dev/null
> +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
> @@ -0,0 +1,224 @@
> +
> +Proposal for SCMI multi-agent driver bindings
> +=============================================
> +
> +Now the Xen configuration for SCMI multi-agent support is done in a bit complicated way, especially
> +from SCMI multi-agent driver initialization and Dom0 DT manipulation point of view.
> +Also it does not take into account future requirements to support SCP SCMI FW.
> +
> +To enable SCMI multi-agent user need:
> +
> +* take host DT with basic SCMI enabled
> +* add SCMI shared-memory nodes for all agents
> +* update SCMI node to point on SCMI Xen management channel (``[smc-id, shmem]``)
> +* add "xen,scmi-secondary-agents" property to the "\chosen" node
> +
> +.. code::
> +
> +   chosen {
> +      xen,scmi-secondary-agents = <
> +                    1 0x82000003 &scmi_shm_1
> +                    2 0x82000004 &scmi_shm_2
> +                    3 0x82000005 &scmi_shm_3
> +                    4 0x82000006 &scmi_shm_4>;
> +    }
> +
> +    /{
> +            // SCMI shared-memory nodes for all agents
> +            scmi_shm_0 : sram@47ff0000 {
> +                compatible = "arm,scmi-shmem";
> +                reg = <0x0 0x47ff0000 0x0 0x1000>;
> +            };
> +            scmi_shm_1: sram@47ff1000 {
> +                    compatible = "arm,scmi-shmem";
> +                    reg = <0x0 0x47ff1000 0x0 0x1000>;
> +            };
> +            scmi_shm_2: sram@47ff2000 {
> +                    compatible = "arm,scmi-shmem";
> +                    reg = <0x0 0x47ff2000 0x0 0x1000>;
> +            };
> +            scmi_shm_3: sram@47ff3000 {
> +                    compatible = "arm,scmi-shmem";
> +                    reg = <0x0 0x47ff3000 0x0 0x1000>;
> +            };
> +            scmi_shm_4: sram@47ff4000 {
> +                    compatible = "arm,scmi-shmem";
> +                    reg = <0x0 0x47ff4000 0x0 0x1000>;
> +            };
> +
> +            firmware {
> +                scmi: scmi {
> +                    compatible = "arm,scmi-smc";
> +                    arm, smc - id = <0x82000002>; <--- Xen management agent channel "smc-id"
> +                    #address-cells = < 1>;
> +                    #size-cells = < 0>;
> +                    #access-controller-cells = < 1>;
> +                    shmem = <&scmi_shm_0>; <--- Xen management agent channel "shmem"
> +
> +                    protocol@X{
> +                    };
> +                };
> +            };
> +    }
> +
> +Important thing to note is that all information about multi-channel support is strictly Xen specific.
> +
> +During initialization the SCMI multi-agent driver uses Host DT SCMI node and
> +"xen,scmi-secondary-agents" property to init itself and then, during Dom0 creation, manipulates
> +Dom0 DT to remove Xen specific SCMI info and update dom0 SCMI nodes with Dom0 SCMI agent specific
> +information.
> +
> +There are two negative points:
> +
> +1) Double DT modification - one is user to set up SCMI Xen support in Host DT, second -
> +   Dom0 DT manipulation.
> +2) In case of future support of mailbox shared-memory transport there could be up to 4 mailboxes and
> +   up to 2 shared-memories per SCMI agent channel.
> +
> +Hence SCMI multi-agent support is Xen specific knowledge there is a proposal to add it as Xen
> +specific DT definitions and so minimize Host and Dom0 DT manipulations.
> +Those definitions can be added in "/chosen" or, ideally, in "xen,config" node (like in Hyperlaunch design).
> +
> +The SCMI binding stays generic, just two SCMI nodes defined - one for Xen management channel and
> +one for Host Dom0 OSPM.
> +
> +Example of using "chosen" for configuration:
> +
> +.. code::
> +
> +    /{
> +
> +        chosen {
> +            ...
> +
> +            // Xen SCMI management channel
> +            scmi_shm_0 : sram@47ff0000 {
> +                compatible = "arm,scmi-shmem";
> +                reg = <0x0 0x47ff0000 0x0 0x1000>;
> +            };
> +            scmi_xen: scmi {
> +                compatible = "arm,scmi-smc";
> +                arm,smc-id = <0x82000002>; <--- Xen manegement agent smc-id
> +                #address-cells = < 1>;
> +                #size-cells = < 0>;
> +                #access-controller-cells = < 1>;
> +                shmem = <&scmi_shm_0>; <--- Xen manegement agent shmem
> +            };
> +
> +            // SCMI multi-agent configuration
> +            scmi_shm_2: sram@47ff2000 {
> +                    compatible = "arm,scmi-shmem";
> +                    reg = <0x0 0x47ff2000 0x0 0x1000>;
> +            };
> +            scmi_shm_3: sram@47ff3000 {
> +                    compatible = "arm,scmi-shmem";
> +                    reg = <0x0 0x47ff3000 0x0 0x1000>;
> +            };
> +            scmi_shm_4: sram@47ff4000 {
> +                    compatible = "arm,scmi-shmem";
> +                    reg = <0x0 0x47ff4000 0x0 0x1000>;
> +            };
> +            xen,scmi-secondary-agents = <
> +                        1 0x82000003 &scmi_shm
> +                        2 0x82000004 &scmi_shm_2
> +                        3 0x82000005 &scmi_shm_3
> +                        4 0x82000006 &scmi_shm_4>;
> +        };
> +
> +        // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI enabled for it
> +        scmi_shm: sram@47ff1000 {
> +                compatible = "arm,scmi-shmem";
> +                reg = <0x0 0x47ff1000 0x0 0x1000>;
> +        };
> +
> +        firmware {
> +            scmi: scmi {
> +                compatible = "arm,scmi-smc";
> +                arm,smc-id = <0x82000003>; <--- Host OSPM agent smc-id
> +                #address-cells = < 1>;
> +                #size-cells = < 0>;
> +                shmem = <&scmi_shm>; <--- Host OSPM agent shmem

By OSPM you mean Dom0 and not Xen? So this is a change compared to a
device tree for baremetal Linux without Xen?

Let me ask the same question differently. In the case of barematal Linux
without Xen (no KVM), what would Linux see under /firmware/scmi as
smc-id and shmem? The same as the one that Xen would use for itself? Or
the same as the ones that Dom0 would use when Xen is present?


> +                protocol@X{
> +                };
> +            };
> +        };
> +    }
> +
> +
> +In the above case:
> +
> +1) Xen SCMI multi-agent can be probed with DT configuration from "chosen" (or special "xen,config")
> +   node and all Xen related nodes can be easily dropped from Dom0 DT.
> +2) Host SCMI OSPM channel DT nodes can be copied to Dom0 DT without changes if SCMI enabled for it.
> +3) Future support for mailbox shared-memory transport (SCP SCMI FW) can be simplified as no more
> +   manipulation required with Dom0 SCMI "arm,smc-id" and "shmem" DT properties.

Yes, I can see the benefit if we can arrange it so that the underlying
host device tree is the same that Linux would use baremetal. And all the
extra configuration is placed under /chosen in "xen,config" node or
similar. I would probably call it "xen,scmi".


> +Example of using "xen,config" for configuration:
> +
> +.. code::
> +
> +    hypervisor {
> +        compatible = “hypervisor,xen”
> +
> +        // Configuration container
> +        config {
> +            compatible = "xen,config";
> +            ...
> +
> +            // Xen SCMI management channel
> +            scmi_shm_0 : sram@47ff0000 {
> +                compatible = "arm,scmi-shmem";
> +                reg = <0x0 0x47ff0000 0x0 0x1000>;
> +            };
> +            scmi_xen: scmi {
> +                compatible = "arm,scmi-smc";
> +                arm,smc-id = <0x82000002>; <--- Xen manegement agent smc-id
> +                #address-cells = < 1>;
> +                #size-cells = < 0>;
> +                #access-controller-cells = < 1>;
> +                shmem = <&scmi_shm_0>; <--- Xen manegement agent shmem
> +            };
> +
> +            // SCMI multi-agent configuration
> +            scmi_shm_2: sram@47ff2000 {
> +                    compatible = "arm,scmi-shmem";
> +                    reg = <0x0 0x47ff2000 0x0 0x1000>;
> +            };
> +            scmi_shm_3: sram@47ff3000 {
> +                    compatible = "arm,scmi-shmem";
> +                    reg = <0x0 0x47ff3000 0x0 0x1000>;
> +            };
> +            scmi_shm_4: sram@47ff4000 {
> +                    compatible = "arm,scmi-shmem";
> +                    reg = <0x0 0x47ff4000 0x0 0x1000>;
> +            };
> +            xen,scmi-secondary-agents = <
> +                        1 0x82000003 &scmi_shm
> +                        2 0x82000004 &scmi_shm_2
> +                        3 0x82000005 &scmi_shm_3
> +                        4 0x82000006 &scmi_shm_4>;
> +        };
> +    };
> +
> +    /{
> +        // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI enabled for it
> +        scmi_shm: sram@47ff1000 {
> +                compatible = "arm,scmi-shmem";
> +                reg = <0x0 0x47ff1000 0x0 0x1000>;
> +        };
> +
> +        firmware {
> +            scmi: scmi {
> +                compatible = "arm,scmi-smc";
> +                arm,smc-id = <0x82000003>; <--- Host OSPM agent smc-id
> +                #address-cells = < 1>;
> +                #size-cells = < 0>;
> +                shmem = <&scmi_shm>; <--- Host OSPM agent shmem
> +
> +                protocol@X{
> +                };
> +            };
> +        };
> +    }
> -- 
> 2.34.1
> 
--8323329-1382825891-1748031575=:147219--


From xen-devel-bounces@lists.xenproject.org Fri May 23 22:19:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 23 May 2025 22:19:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.996284.1378080 (Exim 4.92)
	(envelope-from )
	id 1uIajn-00089r-Ja; Fri, 23 May 2025 22:19:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 996284.1378080; Fri, 23 May 2025 22: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 1uIajn-00089k-Gh; Fri, 23 May 2025 22:19:35 +0000
Received: by outflank-mailman (input) for mailman id 996284;
 Fri, 23 May 2025 22:19:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uIajl-00089e-Jj
 for xen-devel@lists.xenproject.org; Fri, 23 May 2025 22:19:34 +0000
Received: from 11.mo584.mail-out.ovh.net (11.mo584.mail-out.ovh.net
 [46.105.34.195]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ffc653bc-3823-11f0-a2fb-13f23c93f187;
 Sat, 24 May 2025 00:19:31 +0200 (CEST)
Received: from director7.ghost.mail-out.ovh.net (unknown [10.108.25.12])
 by mo584.mail-out.ovh.net (Postfix) with ESMTP id 4b402C1hNgz1F9b
 for ; Fri, 23 May 2025 22:19:31 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-d7x5r (unknown [10.110.96.204])
 by director7.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 70ED3C0152;
 Fri, 23 May 2025 22:19:30 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.96])
 by ghost-submission-5b5ff79f4f-d7x5r with ESMTPSA
 id tj8sEnL0MGiFCAwASDrGwQ
 (envelope-from ); Fri, 23 May 2025 22:19: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" 
X-Inumbo-ID: ffc653bc-3823-11f0-a2fb-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-96R0014b5fd9bb-90f1-4b7c-bdb6-c6f1abd9979a,
                    CD0F819BC38912917CA9DC5475EC3E7C21FBB083) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
Date: Sat, 24 May 2025 01:19:17 +0300
From: Sergii Dmytruk 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 02/22] include/xen/slr-table.h: Secure Launch Resource
 Table definitions
Message-ID: 
References: 
 
 <4896ab0b-f45e-43e9-bcee-f5496717eb2a@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4896ab0b-f45e-43e9-bcee-f5496717eb2a@suse.com>
X-Ovh-Tracer-Id: 17614422570925012057
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddutddtfeculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvdfgveegtdffhfdugeevieehkeetudevfeefgedtleejledvfeeutdetudeiveelnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdelieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkeegmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=hnb3sgRi2PbChx3uTtxmnmJ701Vr32dxeYKoEIZN/2g=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748038771; v=1;
 b=dEy0nCeXc6MHHc0gg/1Fmv3NYRd7j63FIhVM48Wo++kvgRURdpfB3WWJ05R5AiCK56h+7Ini
 +OrJaw5yl8Xrrl2cbvnWwWTsUw43v2ykFh2hLutlv3U6s0f3Q3B2jI36Dax6daFcNyr9VbKrEks
 sftsjfkkgLv1IT3uyMiIZflRVChp1u82kiQoI5QeuTYSnCRtpwiIoHLMfTZ17ITGkH2hDlj7odb
 /HG5OHUFHNMslmUwWfQR8lS4+0gcZZa/Q0buIHZp0eD3WmWb15NS/e9V09eg7IzTLjEWfTtmIXh
 AVEN1ciyjiC8m1xhrXhXtpLLgYJ38JzecuweTphqyMQkA==

On Wed, May 21, 2025 at 05:45:04PM +0200, Jan Beulich wrote:
> > +/* SPDX-License-Identifier: GPL-2.0 */
>
> GPL-2.0-only is, I think, the one to use for new code.

Right.

> > +/*
> > + *  Copyright (c) 2025 Apertus Solutions, LLC
> > + *  Copyright (c) 2025 Oracle and/or its affiliates.
> > + *  Copyright (c) 2025 3mdeb Sp. z o.o
>
> I'm curious: Considering the (just) 2 S-o-b, where's the 3rd copyright
> line coming from?

I'll add "Daniel P. Smith" (already in CC), not sure why his S-o-B
wasn't there.

> > +#include 
>
> Looks like xen/stdint.h would suffice?

It would for types, but there is also use of `NULL`.

> > +#define UEFI_SLR_TABLE_GUID \
> > +    { 0x877a9b2aU, 0x0385, 0x45d1, { 0xa0, 0x34, 0x9d, 0xac, 0x9c, 0x9e, 0x56, 0x5f } }
>
> I'm not sure this is a good place to put UEFI GUIDs. Considering e.g ...

It's here because the GUID is related more to SLRT than to EFI.  I can
move it if there is a more fitting place for table GUIDs.

> > +/* SLR table header values */
> > +#define SLR_TABLE_MAGIC         0x4452544d
> > +#define SLR_TABLE_REVISION      1
> > +
> > +/* Current revisions for the policy and UEFI config */
> > +#define SLR_POLICY_REVISION         1
> > +#define SLR_UEFI_CONFIG_REVISION    1
>
> ... this, is the whole concept perhaps bound to UEFI? In which casethe
> whole header may want to move to the efi/ subdir?

This isn't EFI-specific, legacy boot is supported.  Some types of
entries are there to provide EFI-specific information.

> > +/* SLR defined architectures */
> > +#define SLR_INTEL_TXT   1
> > +#define SLR_AMD_SKINIT  2
>
> These are both x86, yet the header is put in the common include dir?

It's x86-specific with the goal to add more architectures in the future.
I don't know, maybe the header should start as arch-specific and be
moved later, your call.

> > +/*
> > + * Primary SLR Table Header
> > + */
> > +struct slr_table
> > +{
> > +    uint32_t magic;
> > +    uint16_t revision;
> > +    uint16_t architecture;
> > +    uint32_t size;
> > +    uint32_t max_size;
> > +    /* entries[] */
> > +} __packed;
>
> If x86-specific, the question on the need for some of the __packed arises
> again.

The table is used to communicate data from pre-DRTM world to DRTM-world
and is produced and consumed by unrelated software components that don't
necessarily pad structures the same way by default.

> > +/*
> > + * Prototype of a function pointed to by slr_entry_dl_info::dl_handler.
> > + */
> > +typedef void (*dl_handler_func)(struct slr_bl_context *bl_context);
>
> It being an internal header, ...
> > +    uint64_t dl_handler;
>
> ... why can't this type be used here then? This would presumably avoid a
> typecast later.

It's not an internal header in my understanding of the phrase, Xen
parses what a bootloader has passed to it.  In principle, pointers could
be 32-bit here.

> > +static inline void *
> > +slr_end_of_entries(struct slr_table *table)
> > +{
> > +    return (uint8_t *)table + table->size;
>
> Considering the function's return type, why not cast to void * (or perhaps
> const void *, if the return type also can be such)?

No particular reason other than that pointer arithmetic on
pointers-to-void typically causes build issues.  Can be changed for Xen.

> > +static inline struct slr_entry_hdr *
> > +slr_next_entry(struct slr_table *table, struct slr_entry_hdr *curr)
> > +{
> > +    struct slr_entry_hdr *next = (struct slr_entry_hdr *)
> > +                                 ((uint8_t *)curr + curr->size);
> > +
> > +    if ( (void *)next >= slr_end_of_entries(table) )
> > +        return NULL;
>
> Is this sufficient as a check? With it fulfilled, ...
>
> > +    if ( next->tag == SLR_ENTRY_END )
>
> ... this member access may still be out of bounds. IOW the question is what
> level of checking is really adequate here.

SLR_ENTRY_END should really end the table, but it won't hurt to check
for out of bounds.  Thanks, will correct the checks.

> > +static inline struct slr_entry_hdr *
> > +slr_next_entry_by_tag (struct slr_table *table,
> > +                       struct slr_entry_hdr *entry,
> > +                       uint16_t tag)
> > +{
> > +    if ( !entry ) /* Start from the beginning */
> > +        entry = (struct slr_entry_hdr *)((uint8_t *)table + sizeof(*table));
>
> Extending from the earlier comment - if the inner cast was to void * here,
> the outer one could be dropped altogether.
>
> Jan

Will update.

Regards


From xen-devel-bounces@lists.xenproject.org Sun May 25 07:34:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 May 2025 07:34:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997060.1378090 (Exim 4.92)
	(envelope-from )
	id 1uJ5s0-00087r-8w; Sun, 25 May 2025 07:34:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997060.1378090; Sun, 25 May 2025 07:34:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJ5s0-00087k-65; Sun, 25 May 2025 07:34:08 +0000
Received: by outflank-mailman (input) for mailman id 997060;
 Sun, 25 May 2025 07:34:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJ5rz-00087e-Dy
 for xen-devel@lists.xenproject.org; Sun, 25 May 2025 07:34:07 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a2e918b4-393a-11f0-a2fb-13f23c93f187;
 Sun, 25 May 2025 09:34:05 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 6B2134EE99B0;
 Sun, 25 May 2025 09:34:04 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a2e918b4-393a-11f0-a2fb-13f23c93f187
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=1748158444;
	b=w/Qj20s1bo9x4pawXnuMK7oQoZnzlqlCubC3wwOZQJQRGUl3F03bEI3b4Ej8fzj/IOUz
	 eFZ/FnB5gMx1pt2r81DOs7VuglowOvZwBc/1PUFiZCUKtMNQcLESj0JSndbWpb0GOhMU+
	 nNLxrWrhpSi7tzBYR73bs8KmdKTSudaWhhAAjuWzts4+nQeh+n59fqrDKtdznPKActruK
	 WOje8xKhgtb3BSe/XsnIabRipW5PWfYds4CbdaGwj9NA052+cXemlxXWOr20FD6ooNscb
	 vbD9SLQ7YvHBaG15K9SqySaNtyvSUsddDtLpS/zexNfVZ/4ANHWB8lFP4IE7vAaWiss6W
	 B/EiOIdZaLJ4LAWQ+VwmCPSX/npQ5JOTNWjTu7hxp13Kim6XlX+2i3B7qTpELBTxTaX05
	 6bcgNIfc/tLJPFsh4GFzrm8OrWIz46OvBbY0/Ryy+irhmp4LNeOT3nKqfQjXFTnauOlGk
	 iX2Ve0tHab31SJ6P4sDDzwBL/lpWhN2OCKNkpa7bM/booXCdEUxOcb1xjF7uaoklbHXLD
	 6oNMzZ+UA7heB4y1mTPeofp86i10ub1+BpwDuGHIEneLR83ZMIwfWtAGSovHd8DJFTo5A
	 THxcLF8fNRfcu6absQ913+GlQoMHHNAZwq+aW+xnxtPqzO5CvrkF54eQHFpxSF8=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1748158444;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=faJ8k823wZEhLda1cYFvYfjBkRjovX6qCNGjUUvMt70=;
	b=uUFgBEsU1xvV8NYzFrerulJoQG1wC5dWAdYSZ1D+aEds0wIN/PWgM6J/681I+u4U6SKT
	 fnqhG1a4IpbTDHVW8EzF00yBD0jJJXEmp2oJwnrQb/P0ALHaveVcvsHXC7ybL6IQ43bOW
	 diqkfcCQY0DJr0mCahD62ByS3mbOWBNzYCXUSDiFt3AHdctukfvc306r6cBHTcMUQurmd
	 6MCe43MHuec1DxvKyi9OjBNSl85JL2eEW63BxupYAU3KCkc01jVMfDNz+g4nP6V90cmeR
	 BCY6kvO2xU+vFDp4Z02NMptutvsiwWmWadVXlLvXd4Rttpr58km8g4zOmLECX6kADIj++
	 PUM0z+Ok4QXXLIkfH+nN24TJB4fcrCh0WEbikzzUqOVpH539EAOp2d6aX6xNf7tT3C6h8
	 y/T52rwxJ2eQuqJyYQk0bQlR2DrKa+d8Is3PGQQG2Sk8PainI8SWbjbtXs2IP8vheu9Bn
	 9Wg1Gdw4PzgENX8Tdtd8nWIDASCVMqiumGFd9p3uUS5Z99qhKm9itBOjvYkJ5B51l+r/n
	 DVUBNZGBOmR1We0XS0mtyMM92ZlRHYJwsoaAhj6E1EO4Zpq1H0SA9y1lERA6fri6H+fwV
	 SOOenkEktSWyvhCn5IeDCCug7Ii+D8GhsjHocrz4gscNGm/i+Bu3l3Y7DxPJFRo=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1748158444; bh=7hBZWCNuA0RsOsR4BznSUhPqoXdSeUP+JJwjUVzDVLE=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=WUTdZfce59sEltHCpgYHMCOx8RA+Nu8beF0RyuxgACh0urKbFw0jyUNh9CGyXh7cA
	 9M2MQzrEFK4kTR/kGkTDDRjnp5IvJZxQ35DcZpOJVaP1eCuUouA2Rd6RsyuJy6aol/
	 iOFzFlbWqwj2QK58WwIQXRhnxPOM0K7BPM3xuIct22FUmTv7avecTdnwNFt9Bcr8h0
	 W15nTijFfyn36SFPDbEfQ/Yo6Kdcd61QZglfrooIgj6ouI669L9HkBX3FP2NTIZsce
	 9YXN3V40c64QjC45/6weDthc9///wrC52UPFtaSXwWISnzw0M4CxssPOydt6pDxZ8a
	 Csl5AU7S3dFrA==
MIME-Version: 1.0
Date: Sun, 25 May 2025 09:34:04 +0200
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , consulting@bugseng.com, Stefano Stabellini
 
Subject: Re: [Eclair false positive] Re: [PATCH] x86/msr: Rework wrmsr_safe()
 using asm goto()
In-Reply-To: <49f092f9-c0fb-4b66-af20-368c736dde91@citrix.com>
References: <20250521143658.312514-1-andrew.cooper3@citrix.com>
 <8504aab1-c48a-4981-a502-93a2fd18880b@citrix.com>
 
 <49f092f9-c0fb-4b66-af20-368c736dde91@citrix.com>
Message-ID: <526fe46bf2e4b5985d1b8cd3361e5730@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2025-05-22 15:49, Andrew Cooper wrote:
> On 22/05/2025 1:45 pm, Nicola Vetrini wrote:
>> On 2025-05-21 20:00, Andrew Cooper wrote:
>>> On 21/05/2025 3:36 pm, Andrew Cooper wrote:
>>>> diff --git a/xen/arch/x86/include/asm/msr.h
>>>> b/xen/arch/x86/include/asm/msr.h
>>>> index 0d3b1d637488..4c4f18b3a54d 100644
>>>> --- a/xen/arch/x86/include/asm/msr.h
>>>> +++ b/xen/arch/x86/include/asm/msr.h
>>>> @@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr,
>>>> uint32_t lo, uint32_t hi)
>>>>  /* wrmsr with exception handling */
>>>>  static inline int wrmsr_safe(unsigned int msr, uint64_t val)
>>>>  {
>>>> -    int rc;
>>>> -    uint32_t lo, hi;
>>>> -    lo = (uint32_t)val;
>>>> -    hi = (uint32_t)(val >> 32);
>>>> -
>>>> -    __asm__ __volatile__(
>>>> -        "1: wrmsr\n2:\n"
>>>> -        ".section .fixup,\"ax\"\n"
>>>> -        "3: movl %5,%0\n; jmp 2b\n"
>>>> -        ".previous\n"
>>>> -        _ASM_EXTABLE(1b, 3b)
>>>> -        : "=&r" (rc)
>>>> -        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
>>>> -    return rc;
>>>> +    uint32_t lo = val, hi = val >> 32;
>>>> +
>>>> +    asm_inline goto (
>>>> +        "1: wrmsr\n\t"
>>>> +        _ASM_EXTABLE(1b, %l[fault])
>>>> +        :
>>>> +        : "a" (lo), "c" (msr), "d" (hi)
>>>> +        :
>>>> +        : fault );
>>>> +
>>>> +    return 0;
>>>> +
>>>> + fault:
>>>> +    return -EFAULT;
>>>>  }
>>> 
>>> It turns out this is the first piece of Eclair-scanned code using asm
>>> goto.
>>> 
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10108558677
>>> (The run also contained an equivalent change to xsetbv())
>>> 
>>> We're getting R1.1 and R2.6 violations.
>>> 
>>> R1.1 complains about [STD.adrslabl] "label address" not being valid 
>>> C99.
>>> 
>>> R2.6 complains about unused labels.
>>> 
>>> I expect this means that Eclair doesn't know how to interpret asm 
>>> goto()
>>> yet.  The labels listed are reachable from inside the asm block.
>>> 
>> 
>> That has been fixed upstream. I'll reach out to you when that fix
>> trickles down to the runners, so that you're able to test and push
>> that change.
> 
> Oh, fantastic thanks.
> 
> I'll hold off pushing until then.
> 
> ~Andrew

Hi Andrew,

both runners are now updated with the new images, so you can rerun the 
tests.

Thanks,
  Nicola

-- 
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 Sun May 25 10:53:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 May 2025 10:53:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997107.1378100 (Exim 4.92)
	(envelope-from )
	id 1uJ8yW-0006Ee-K9; Sun, 25 May 2025 10:53:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997107.1378100; Sun, 25 May 2025 10:53: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 1uJ8yW-0006EX-Gv; Sun, 25 May 2025 10:53:04 +0000
Received: by outflank-mailman (input) for mailman id 997107;
 Sun, 25 May 2025 10:53:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJ8yU-0006EQ-VG
 for xen-devel@lists.xenproject.org; Sun, 25 May 2025 10:53:02 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6d442096-3956-11f0-a2fb-13f23c93f187;
 Sun, 25 May 2025 12:53:01 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a376ba6f08so817578f8f.1
 for ; Sun, 25 May 2025 03:53:01 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f7baaf2asm205144295e9.34.2025.05.25.03.52.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 25 May 2025 03:53: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" 
X-Inumbo-ID: 6d442096-3956-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748170381; x=1748775181; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Mh5to5YPyXW4Cyj+AC3f58IlxOZ7WUyFpM4CaU07C9U=;
        b=vPBHMkwtwV2V/vqGrX2wN4Oi54uZ/Fafgc4RXjAKlThVxNY88mka5F97ZkEfYJUjWr
         g5wLVJYsGN77HGAUfsgp6npAZNTAoXNFs7Y0w0DgM4h8SI0FQkQ3fU5sr54qXF9s5JT/
         wy5QjrONyepPDq9eCpD8ovp9Q9DPM3MRT096U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748170381; x=1748775181;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Mh5to5YPyXW4Cyj+AC3f58IlxOZ7WUyFpM4CaU07C9U=;
        b=ZaesBscm5m/SPiBzlDh283beFda7NYbd84w5oUl8chAiSIa9NaQSTmaykyi4RRUUoB
         gONyGBMiBSKAyimVehCb40yb2Xia1y6HLkyw67i/1B0vZeBIU2TroqtQeFJRczJBNQof
         v8TbmRRS1APCTqt33Q5Jel+3SiYcfl76HN/xdq9DvuIHXvga8ekzB02gzhkdnXR3zgul
         HmKWpqC17e/t+0vPC2ilrrXyycubnM7YTLg6feBxlG5b8wm6c8PN6xOlRMoU4QXmgDn3
         zMS1N49rxO4kpf83umIOB6SzEMpsKdocXBgbCA3aZYwsejivAJZ3hTqHHWoq7OJOvGwg
         KLdg==
X-Gm-Message-State: AOJu0Yz80n99je5UmoRrSbyeLnhcFFc99t9XPMY9eO9gOCn68UxpHu0+
	3/LXy43tgiJkZt8UK/iNaZxHO2DIhzj1swlde3L/3O2/P3cnEoqmUUldBSLpm0nirIs=
X-Gm-Gg: ASbGnctHH1JdmJQFNtNfnQ3N+hf5cED2FDGFF6uIoVpafWs0PTHZF+YznK9Qe8NN0Eb
	R3Bsc2lCcGS4sjOpzaig1A/++3w3vf8iXvrhOPM0y42VxxaDd42AqOJLWVrT2i6hFKjlFZZqY3o
	GJJmYT3phPWGd1JcbhbQfgiYHR9/ejV5stux0eR9+thdjXrjLWzvp5n0kzrpBBaaMP64o3NfLhb
	2H1vwJYRvwcNc+YSvt7mZsVNNwl3acEenyl3KzYtNKEfQEPR6hxGl1TZx81awTghGY+CycFqQOn
	5reEfiYtpfcwo1d8zoc0sg0W5RqFPGSvKGonaPRCfC4pvwpqmy79Isb7NF3KAU057pEte7Tg6qY
	7jSCyEAV3Jm5vBkO55wh1bs5dixk=
X-Google-Smtp-Source: AGHT+IHdvnY5R5zaPGuM50cVRKBB0Ktbe2nMagFCYQR94N4ssT1LrVUaVOglyTLV8qv+KP8nMHvapg==
X-Received: by 2002:a05:6000:2388:b0:3a4:d83a:eb2a with SMTP id ffacd0b85a97d-3a4d83aed39mr401447f8f.55.1748170380716;
        Sun, 25 May 2025 03:53:00 -0700 (PDT)
Message-ID: 
Date: Sun, 25 May 2025 11:52:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [Eclair false positive] Re: [PATCH] x86/msr: Rework wrmsr_safe()
 using asm goto()
To: Nicola Vetrini 
Cc: Xen-devel ,
 Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , consulting@bugseng.com,
 Stefano Stabellini 
References: <20250521143658.312514-1-andrew.cooper3@citrix.com>
 <8504aab1-c48a-4981-a502-93a2fd18880b@citrix.com>
 
 <49f092f9-c0fb-4b66-af20-368c736dde91@citrix.com>
 <526fe46bf2e4b5985d1b8cd3361e5730@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: <526fe46bf2e4b5985d1b8cd3361e5730@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25/05/2025 8:34 am, Nicola Vetrini wrote:
> On 2025-05-22 15:49, Andrew Cooper wrote:
>> On 22/05/2025 1:45 pm, Nicola Vetrini wrote:
>>> On 2025-05-21 20:00, Andrew Cooper wrote:
>>>> On 21/05/2025 3:36 pm, Andrew Cooper wrote:
>>>>> diff --git a/xen/arch/x86/include/asm/msr.h
>>>>> b/xen/arch/x86/include/asm/msr.h
>>>>> index 0d3b1d637488..4c4f18b3a54d 100644
>>>>> --- a/xen/arch/x86/include/asm/msr.h
>>>>> +++ b/xen/arch/x86/include/asm/msr.h
>>>>> @@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr,
>>>>> uint32_t lo, uint32_t hi)
>>>>>  /* wrmsr with exception handling */
>>>>>  static inline int wrmsr_safe(unsigned int msr, uint64_t val)
>>>>>  {
>>>>> -    int rc;
>>>>> -    uint32_t lo, hi;
>>>>> -    lo = (uint32_t)val;
>>>>> -    hi = (uint32_t)(val >> 32);
>>>>> -
>>>>> -    __asm__ __volatile__(
>>>>> -        "1: wrmsr\n2:\n"
>>>>> -        ".section .fixup,\"ax\"\n"
>>>>> -        "3: movl %5,%0\n; jmp 2b\n"
>>>>> -        ".previous\n"
>>>>> -        _ASM_EXTABLE(1b, 3b)
>>>>> -        : "=&r" (rc)
>>>>> -        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
>>>>> -    return rc;
>>>>> +    uint32_t lo = val, hi = val >> 32;
>>>>> +
>>>>> +    asm_inline goto (
>>>>> +        "1: wrmsr\n\t"
>>>>> +        _ASM_EXTABLE(1b, %l[fault])
>>>>> +        :
>>>>> +        : "a" (lo), "c" (msr), "d" (hi)
>>>>> +        :
>>>>> +        : fault );
>>>>> +
>>>>> +    return 0;
>>>>> +
>>>>> + fault:
>>>>> +    return -EFAULT;
>>>>>  }
>>>>
>>>> It turns out this is the first piece of Eclair-scanned code using asm
>>>> goto.
>>>>
>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10108558677
>>>> (The run also contained an equivalent change to xsetbv())
>>>>
>>>> We're getting R1.1 and R2.6 violations.
>>>>
>>>> R1.1 complains about [STD.adrslabl] "label address" not being valid
>>>> C99.
>>>>
>>>> R2.6 complains about unused labels.
>>>>
>>>> I expect this means that Eclair doesn't know how to interpret asm
>>>> goto()
>>>> yet.  The labels listed are reachable from inside the asm block.
>>>>
>>>
>>> That has been fixed upstream. I'll reach out to you when that fix
>>> trickles down to the runners, so that you're able to test and push
>>> that change.
>>
>> Oh, fantastic thanks.
>>
>> I'll hold off pushing until then.
>>
>> ~Andrew
>
> Hi Andrew,
>
> both runners are now updated with the new images, so you can rerun the
> tests.

Both Eclair runs are unhappy, and not even completing analysis.

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1835567532

This is the same branch as before, plus your config change for R1.1

~Andrew


From xen-devel-bounces@lists.xenproject.org Sun May 25 13:36:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 May 2025 13:36:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997139.1378110 (Exim 4.92)
	(envelope-from )
	id 1uJBWk-0007yA-JR; Sun, 25 May 2025 13:36:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997139.1378110; Sun, 25 May 2025 13:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJBWk-0007y3-GP; Sun, 25 May 2025 13:36:34 +0000
Received: by outflank-mailman (input) for mailman id 997139;
 Sun, 25 May 2025 13:36:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJBWi-0007xx-MR
 for xen-devel@lists.xenproject.org; Sun, 25 May 2025 13:36:33 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41e3fc24-396d-11f0-b893-0df219b8e170;
 Sun, 25 May 2025 15:36:27 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 565FC4EE99B0;
 Sun, 25 May 2025 15:36: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" 
X-Inumbo-ID: 41e3fc24-396d-11f0-b893-0df219b8e170
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=1748180186;
	b=FyFe0LrcXEByIHSS5dxJkfpx3NkNww43cGXQ6itQAn49tJavluplxggfDfDpSiGmuKaF
	 J1CNza8Zhe9ctTovr6GGHFG3/O8mGSql0OFZ35drnUk45ps4fjJkRZI7b3Kr3V/SgQDs1
	 W1Fl79T4kzOyrX8vbZ7GjpbmqHG/0t2IQIW0KCI9DNVPyQJYxIokH7F7zxRrjilhl7gcP
	 2E4QWTKmhrrLPrb43/Wgb8S4rI4RHJQ/DYgNYEXcEmXpnOBL7+RSZ5rOZUCcWUb4ys2S0
	 /AKgjF4UhC5VpGUh8rttswriuUJKFxGYNicYSx9Ng3dVKbVgKGgl/uoZ8PD5d4h2UnE7H
	 PTuc4wHDjAruxuTwQ0t250dRVrSl0l3cedl+90s6V/8UavLHs/wy9hkc6qWXElq3rei3v
	 UaJEKOS1PKYKf22vm3MZ3gFq+BXIJIEeoqhVsSwioywCNGkYtF219Fxlv/1Se5Lb1JNj2
	 TgVoq2/oMsTaQ+XYS4tq4Qe4iLXs/qSmWyJRAZd7YEbxP5JEvNig5FQPH1iewQMEc1tjh
	 Yjk+pHhyfE/3HvM16vZBswIRry1mxxCNJRSaJgx3K4tdIlV3xS3qtvTTArLQt6BHNgvn4
	 FbcluZTmrOvSP5GuuooW+w7ZDtqmfuUB/hJ/c/DHkfGbIvVWi+tdwRd4qkewOMc=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1748180186;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=D6qxs26nemEEsj9jWOSkfznRuu1jVd0UrUKVudtJrpU=;
	b=AuRg+fQmQiU2HzDuS9ct90irQtI3J04N1A6ljbH9eFHwfjsnYom8M4lbp6wdV/lQvIcL
	 d31pvrykQS1mzP6B/fWNc8wTgGuEJ3uVnH70CREn9nbPQ5z7iOeJc7frmkm7vDr79dZQA
	 YytXq0em1ZsGs2ds1iBwHqueDpbmHjMqDgXckoUzcX051JmxwFj3pB8W5xhftkvW/bQS7
	 W8DTB6rdtH6d3WKw+wnuWTZ40PsVmae4K9d9xQJIya2xcM/6aU22bVis12cAqbIswi+Ao
	 EKxfoyXSzerkx1gHyclr3Iq1779HrgPH+3Y7P650jAU/E7ZSF7AQc8mdjftPaf1Y+b1ys
	 8jDvmY1TIEk6tMPEWKb848DVDcyQdUbDcGGUSoH0CWyY7KMKHOUcS13KAO/MJfDPvEG54
	 tBcfvRHhu41rLOdnhpdx8Jphaooi7AuUyedO72ULoEM2KrSb5/GcfgY8pJNyxDlhFvWxF
	 rWS6qQajs3gc/eaL9Fn2Lndqi6oPgPfoZjqWfVOfXNZTHwPQQLRFMWeJLxh5k8h1ho49P
	 LfKn0ozwZLMOLj6cp3HIf3YG05FGUAJ2+pXNe4lsXO59ZJQIry0AN4YM4PMVH8WTcgdw3
	 o8VJ4zlKwi10geXf84M8ulZJRujdG6l1vxVE2Nnn4LdGRVL132HSEAsKszR3Ycw=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1748180186; bh=+A0zv/q17hU1roItLIJ0qAHpk6xGREPt5/UYEvvFxlU=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=yVVD66pnPfi57zcNskvCPS2XJ9sG2MM44JzNDCTRleXwpNOEX6myKKtYwBGR3yA9W
	 IogXlIN3mVLENYCVGS7NPf5gjNfSN3vhtkazsLA3iczpZiK8BCXfB0YxzpUMNdRZPG
	 CVy50xdhNAUj2rvCgSVzetT93HFGsV4o1wQqWAGTCoDuVEFe35+PAk0q/gwVa/Cfe7
	 860GCHWUSj+JyjGmxWLxhxADR1kEWKCY5pauNBuUMG6xzgIEkjxUrIiSVQ1pYT1yi9
	 zLG2pOMZegTvc+071asZF3saI7fYVVbDa/dwJmcHWZ8F3KlIqwd8qxQLik4RIngxp3
	 WaHsEnSl5RPYw==
MIME-Version: 1.0
Date: Sun, 25 May 2025 15:36:26 +0200
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , consulting@bugseng.com, Stefano Stabellini
 
Subject: Re: [Eclair false positive] Re: [PATCH] x86/msr: Rework wrmsr_safe()
 using asm goto()
In-Reply-To: 
References: <20250521143658.312514-1-andrew.cooper3@citrix.com>
 <8504aab1-c48a-4981-a502-93a2fd18880b@citrix.com>
 
 <49f092f9-c0fb-4b66-af20-368c736dde91@citrix.com>
 <526fe46bf2e4b5985d1b8cd3361e5730@bugseng.com>
 
Message-ID: <76634ee243f9e51a777428904a8c0d5d@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2025-05-25 12:52, Andrew Cooper wrote:
> On 25/05/2025 8:34 am, Nicola Vetrini wrote:
>> On 2025-05-22 15:49, Andrew Cooper wrote:
>>> On 22/05/2025 1:45 pm, Nicola Vetrini wrote:
>>>> On 2025-05-21 20:00, Andrew Cooper wrote:
>>>>> On 21/05/2025 3:36 pm, Andrew Cooper wrote:
>>>>>> diff --git a/xen/arch/x86/include/asm/msr.h
>>>>>> b/xen/arch/x86/include/asm/msr.h
>>>>>> index 0d3b1d637488..4c4f18b3a54d 100644
>>>>>> --- a/xen/arch/x86/include/asm/msr.h
>>>>>> +++ b/xen/arch/x86/include/asm/msr.h
>>>>>> @@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr,
>>>>>> uint32_t lo, uint32_t hi)
>>>>>>  /* wrmsr with exception handling */
>>>>>>  static inline int wrmsr_safe(unsigned int msr, uint64_t val)
>>>>>>  {
>>>>>> -    int rc;
>>>>>> -    uint32_t lo, hi;
>>>>>> -    lo = (uint32_t)val;
>>>>>> -    hi = (uint32_t)(val >> 32);
>>>>>> -
>>>>>> -    __asm__ __volatile__(
>>>>>> -        "1: wrmsr\n2:\n"
>>>>>> -        ".section .fixup,\"ax\"\n"
>>>>>> -        "3: movl %5,%0\n; jmp 2b\n"
>>>>>> -        ".previous\n"
>>>>>> -        _ASM_EXTABLE(1b, 3b)
>>>>>> -        : "=&r" (rc)
>>>>>> -        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" (-EFAULT));
>>>>>> -    return rc;
>>>>>> +    uint32_t lo = val, hi = val >> 32;
>>>>>> +
>>>>>> +    asm_inline goto (
>>>>>> +        "1: wrmsr\n\t"
>>>>>> +        _ASM_EXTABLE(1b, %l[fault])
>>>>>> +        :
>>>>>> +        : "a" (lo), "c" (msr), "d" (hi)
>>>>>> +        :
>>>>>> +        : fault );
>>>>>> +
>>>>>> +    return 0;
>>>>>> +
>>>>>> + fault:
>>>>>> +    return -EFAULT;
>>>>>>  }
>>>>> 
>>>>> It turns out this is the first piece of Eclair-scanned code using 
>>>>> asm
>>>>> goto.
>>>>> 
>>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10108558677
>>>>> (The run also contained an equivalent change to xsetbv())
>>>>> 
>>>>> We're getting R1.1 and R2.6 violations.
>>>>> 
>>>>> R1.1 complains about [STD.adrslabl] "label address" not being valid
>>>>> C99.
>>>>> 
>>>>> R2.6 complains about unused labels.
>>>>> 
>>>>> I expect this means that Eclair doesn't know how to interpret asm
>>>>> goto()
>>>>> yet.  The labels listed are reachable from inside the asm block.
>>>>> 
>>>> 
>>>> That has been fixed upstream. I'll reach out to you when that fix
>>>> trickles down to the runners, so that you're able to test and push
>>>> that change.
>>> 
>>> Oh, fantastic thanks.
>>> 
>>> I'll hold off pushing until then.
>>> 
>>> ~Andrew
>> 
>> Hi Andrew,
>> 
>> both runners are now updated with the new images, so you can rerun the
>> tests.
> 
> Both Eclair runs are unhappy, and not even completing analysis.
> 
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1835567532
> 
> This is the same branch as before, plus your config change for R1.1
> 
> ~Andrew

There might be something wrong with the image I used, it's erroring on a 
speculative call to the compiler. I rolled back to the previous images 
(without the fix for R2.6). I will investigate tomorrow.

Thanks,
  Nicola

-- 
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 Sun May 25 14:20:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 May 2025 14:20:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997153.1378129 (Exim 4.92)
	(envelope-from )
	id 1uJCD2-0005wm-Qz; Sun, 25 May 2025 14:20:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997153.1378129; Sun, 25 May 2025 14:20: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 1uJCD2-0005wf-OE; Sun, 25 May 2025 14:20:16 +0000
Received: by outflank-mailman (input) for mailman id 997153;
 Sun, 25 May 2025 14:20:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJCD0-0005ip-Oc
 for xen-devel@lists.xenproject.org; Sun, 25 May 2025 14:20:14 +0000
Received: from fhigh-b6-smtp.messagingengine.com
 (fhigh-b6-smtp.messagingengine.com [202.12.124.157])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5f64952b-3973-11f0-a2fb-13f23c93f187;
 Sun, 25 May 2025 16:20:14 +0200 (CEST)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 9600A25400D1;
 Sun, 25 May 2025 10:20:12 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-04.internal (MEProxy); Sun, 25 May 2025 10:20:13 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 25 May 2025 10:20:10 -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" 
X-Inumbo-ID: 5f64952b-3973-11f0-a2fb-13f23c93f187
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
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm3; t=1748182812; x=1748269212; bh=8CMSnPMAp3
	syd0lBA/8zYatGO1sF4jnrTcxo0LaBsrA=; b=b4lucCwqi3SvL0HUvsVIP8vjlH
	+EYrfwvSMGJXO9DviZVhTXkh01oJ4CFToSRW0pGVXk6CMvGZUjEf9J8v01EuKbib
	DRi4E41mQ95IAV9Bh2D7Lo2D9kClBnbPmRK0qAGDZ59URFFQVcB6qfvFp8CVQEud
	mVYYO0uCJpPPzaQR1W7TrkAEUjANU2NZ6KHGG/l/BQF+GOg+PkFxtDlDqtoUtbgp
	5J3jMWYrYrkxrtuCjSqqG5hRRhhPvzHfruM/wUHZi7n08+Wf8+XM6pSrMqSVO4BE
	wp9Nlb1cOmG2kaVj51xyrwMB1glCrpsY067wPMGBw9PbFzXS9Qp/NR5neRSA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1748182812; x=
	1748269212; bh=8CMSnPMAp3syd0lBA/8zYatGO1sF4jnrTcxo0LaBsrA=; b=C
	po66eGfPKySe+NvrvRO3Nv/TA4Dtu/A3MGL9EGl73luPSliCSU/CiRkveEJLBIqB
	3O6B4y/VRDLxK4yvoZYD+PMlYoqyUHn6DQk//TnD6DCnWv8ZvoXIb9H9LdCIIaMj
	gJcrhPbQG874uuDc+CWi6LUmrd9SPEpuFuwogwL2KJVqqXfXVEslyUzr4uHwUacO
	r95B7rvVcE+pjhlD0v6rufnUrQXwUfzezPyK4vb11Oa7aHxJhRqdlLmjfxiDAPF0
	te3zmUbU5nRV2dr9L/JQCLfvkD7TbMT+pU+tL9x6V5Mg5IJf5uhFEguOKDA85ptE
	n5sFmuR9cE+3t/4xViYkg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddugeekfeculddtuddrgeefvddrtd
    dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
    fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
    dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffo
    jghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofi
    hskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhn
    ghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeuudehgfdvfeehhedujeehfe
    duveeugefhkefhheelgeevudetueeiudfggfffnecuvehluhhsthgvrhfuihiivgeptden
    ucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvth
    hhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepledpmhhouggvpehsmhhtphho
    uhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtg
    htrdhorhhgpdhrtghpthhtohepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhn
    ghhslhgrsgdrtghomhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghith
    hrihigrdgtohhmpdhrtghpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghs
    rdhtvggthhdprhgtphhtthhopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdprh
    gtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtohepjhhulhhi
    vghnseigvghnrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrd
    gtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhg
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 v1 2/5] drivers/char: Handle Xen relocation in the XHCI console driver
Date: Sun, 25 May 2025 16:15:43 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The XHCI uses DMA for a bunch of configuration structures and also for
transfer rings. Since those buffers live in .bss it's sensitive for Xen
relocation. Use the newly added hooks to handle this case:

In pre-relocation hook wait for all the data already sent to be handled
and pause sending any more.

In the post-relocation hook detect if relocation happened (check if
physical address of one of the structures matches what was programmed
into hardware) and if so - re-initialize all structures carying
physical addresses and program XHCI with new addresses. And then resume
console - this needs to happen in no-relocation case too, to undo
pausing done in pre-relocation.

Move the iommu_add_extra_reserved_device_memory() call post relocation,
as it needs physical addresses. It needs to happen before setting up
IOMMU (specifically before the acpi_iommu_init() call) but that's the
only ordering constraint - moving it is simpler than doing it initially
with pre-relocation addresses and then un-doing during relocation. This
is also the place where calling post-relocation hook unconditionally
(even if relocation didn't actually happened) is helpful - otherwise the
iommu_add_extra_reserved_device_memory() call would need to be done
conditionally in two places.

Finally, move dbc_dma_bufs declaration near top of the file, as it's
used earlier now.

Unfortunately, changes to several registers require flipping DCE (Debug
Capability Enable) to 0 and then back to 1 which results in the device
disconnect for a short time. Linux's xhci_dbc driver appears to do some
synchronization (or buffering?) so if one re-connects to the /dev/USB0
fast enough (for example by running minicom/picocom/etc in a loop), no
messages are lost. But technically there is no guarantee of that...

Signed-off-by: Marek Marczykowski-Górecki 
---
I tried to avoid flipping DCE, but it seems to be a limitation actually
enforced by the hardware. The XHCI spec says "just" this about a bunch
of registers:

    Software shall initialize this register before setting the Debug
    Capability Enable bit in the Debug Capability Control Register to ‘1’.

As for the implicit console flush in pre-relocation hook, technically it
could be avoided in the no-relocation case, but that would complicate
code structure (see note about reserved device memory). For the
relocation case, avoiding it might be possible, if the driver could
access old pages somehow (as without the flush the device might have
modified them in the meantime), but again - IMO it's not worth it.
Alternative would be flipping DCE also in the no-relocation case, which
is IMO worse than just the flush.
---
 xen/drivers/char/xhci-dbc.c | 89 +++++++++++++++++++++++++++-----------
 1 file changed, 64 insertions(+), 25 deletions(-)

diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c
index c45e4b6825cc..c4bb371ff78f 100644
--- a/xen/drivers/char/xhci-dbc.c
+++ b/xen/drivers/char/xhci-dbc.c
@@ -264,6 +264,24 @@ struct dbc {
     uint16_t pci_cr;
 };
 
+/* Those are accessed via DMA. */
+struct 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];
+    uint8_t out_wrk_buf[DBC_WORK_RING_CAP];
+    uint8_t in_wrk_buf[DBC_WORK_RING_CAP];
+    struct xhci_erst_segment erst __aligned(16);
+    struct xhci_dbc_ctx ctx __aligned(16);
+    struct xhci_string_descriptor str_buf[DBC_STRINGS_COUNT];
+    /*
+     * Don't place anything else on this page - it will be
+     * DMA-reachable by the USB controller.
+     */
+};
+static struct dbc_dma_bufs __section(".bss.page_aligned") __aligned(PAGE_SIZE)
+    dbc_dma_bufs;
+
 static void *dbc_sys_map_xhc(uint64_t phys, size_t size)
 {
     size_t i;
@@ -1189,6 +1207,50 @@ static void __init cf_check dbc_uart_init_preirq(struct serial_port *port)
     uart->lock = &port->tx_lock;
 }
 
+static void __init cf_check dbc_uart_init_pre_relocate(struct serial_port *port)
+{
+    struct dbc_uart *uart = port->uart;
+    struct dbc *dbc = &uart->dbc;
+
+    /* Wait for all the data already sent to be handled. */
+    while ( xhci_trb_ring_size(&dbc->dbc_oring) )
+        dbc_pop_events(dbc);
+    /* Do not send any more data until after relocation. */
+    dbc->suspended = true;
+}
+
+static void __init cf_check dbc_uart_init_post_relocate(struct serial_port *port)
+{
+    struct dbc_uart *uart = port->uart;
+    struct dbc *dbc = &uart->dbc;
+
+    if ( readq(&dbc->dbc_reg->erstba) != virt_to_maddr(dbc->dbc_erst) )
+    {
+        /*
+         * Do not use dbc_init_work_ring() to not discard queued data, just
+         * update the DMA address.
+         */
+        dbc->dbc_owork.dma = virt_to_maddr(dbc->dbc_owork.buf);
+        dbc->dbc_iwork.dma = virt_to_maddr(dbc->dbc_iwork.buf);
+
+        if ( !dbc_init_dbc(dbc) )
+        {
+            dbc_error("relocate failed\n");
+            return;
+        }
+
+        dbc_enable_dbc(dbc);
+    }
+
+    dbc->suspended = false;
+
+    iommu_add_extra_reserved_device_memory(
+            PFN_DOWN(virt_to_maddr(&dbc_dma_bufs)),
+            PFN_UP(sizeof(dbc_dma_bufs)),
+            uart->dbc.sbdf,
+            "XHCI console");
+}
+
 static void __init cf_check dbc_uart_init_postirq(struct serial_port *port)
 {
     struct dbc_uart *uart = port->uart;
@@ -1310,6 +1372,8 @@ static void cf_check dbc_uart_resume(struct serial_port *port)
 static struct uart_driver dbc_uart_driver = {
     .init_preirq = dbc_uart_init_preirq,
     .init_postirq = dbc_uart_init_postirq,
+    .init_pre_relocate = dbc_uart_init_pre_relocate,
+    .init_post_relocate = dbc_uart_init_post_relocate,
     .tx_ready = dbc_uart_tx_ready,
     .putc = dbc_uart_putc,
     .getc = dbc_uart_getc,
@@ -1318,24 +1382,6 @@ static struct uart_driver dbc_uart_driver = {
     .resume = dbc_uart_resume,
 };
 
-/* Those are accessed via DMA. */
-struct 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];
-    uint8_t out_wrk_buf[DBC_WORK_RING_CAP];
-    uint8_t in_wrk_buf[DBC_WORK_RING_CAP];
-    struct xhci_erst_segment erst __aligned(16);
-    struct xhci_dbc_ctx ctx __aligned(16);
-    struct xhci_string_descriptor str_buf[DBC_STRINGS_COUNT];
-    /*
-     * Don't place anything else on this page - it will be
-     * DMA-reachable by the USB controller.
-     */
-};
-static struct dbc_dma_bufs __section(".bss.page_aligned") __aligned(PAGE_SIZE)
-    dbc_dma_bufs;
-
 static int __init cf_check xhci_parse_dbgp(const char *opt_dbgp)
 {
     struct dbc_uart *uart = &dbc_uart;
@@ -1425,14 +1471,7 @@ void __init xhci_dbc_uart_init(void)
     dbc->dbc_str = dbc_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)),
-                uart->dbc.sbdf,
-                "XHCI console");
         serial_register_uart(SERHND_XHCI, &dbc_uart_driver, &dbc_uart);
-    }
 }
 
 #ifdef DBC_DEBUG
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Sun May 25 14:20:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 May 2025 14:20:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997152.1378119 (Exim 4.92)
	(envelope-from )
	id 1uJCD0-0005j2-Jr; Sun, 25 May 2025 14:20:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997152.1378119; Sun, 25 May 2025 14:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJCD0-0005iv-HN; Sun, 25 May 2025 14:20:14 +0000
Received: by outflank-mailman (input) for mailman id 997152;
 Sun, 25 May 2025 14:20:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJCCz-0005ip-Hn
 for xen-devel@lists.xenproject.org; Sun, 25 May 2025 14:20:13 +0000
Received: from fhigh-b6-smtp.messagingengine.com
 (fhigh-b6-smtp.messagingengine.com [202.12.124.157])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5c5d187f-3973-11f0-a2fb-13f23c93f187;
 Sun, 25 May 2025 16:20:09 +0200 (CEST)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 95F3325400E5;
 Sun, 25 May 2025 10:20:07 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-03.internal (MEProxy); Sun, 25 May 2025 10:20:07 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 25 May 2025 10:20:06 -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" 
X-Inumbo-ID: 5c5d187f-3973-11f0-a2fb-13f23c93f187
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=fm3;
	 t=1748182807; x=1748269207; bh=wmGTDjl+RO4WCPUxF9h21I+ISdQwEoLG
	xy64Vn/J5Fs=; b=DP+92jO7r/AlGqRiaVKSPMMPT/GekBaqn6zRv5nBX9txNmZl
	twpC1SftGOpz0vRxjnoXxNKrA7n+mqTNZFzmak2OiIltI5Yfy5wHm6ykDd4dS9h3
	5/qpB144hJCZVqM2t6376xsjkvde/5bGCNgbGsFd82iU9Ol4HsTsej1Zpf8lind6
	Bm15BHaUr3VfyTRf0omalSdxZaxp2Jz9dw7U6dkD9ct0Ptmodpid7DjbiLhrowlC
	+oaf9COPrErBbT9SDbd15wX1rfF4rNV6bnNlq08oT9iBsDNfoFcV2JvkB9iDukGb
	nDnty0QNFUmwaOHc0nr8s2hz2Y3NnmRWH9eDTQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; t=1748182807; x=1748269207; bh=wmGTDjl+RO4WCPUxF9h21I+ISdQw
	EoLGxy64Vn/J5Fs=; b=plVsI0LZxEIL7wluJyTo58e+jyd+AU5RZYw5C2bD3hGt
	0mOJbb0QZohFf3XYqb1yoJD3a/Ki2B1RsHi3066lfJSVpT5ho1rvlFmIGDtNX2OU
	Mi30uuRZGyhIL0luHAmcOMeLsnXM2/2vOV4PBi8f5XgnTW46K28foQy8cUIHYZgM
	9wwhPWdImjtNjBq+05YKlu3i8wi/EHw97LNN6y4yqBUv5Cs7ahgasgyo7gfg+D+6
	oICth3FObJNU91oILq8fgh61gd9aAkeeghPVAwDtJHtbBlzJ5rWFgV0AKAUF4aU+
	p0UIQNvMTlT8/76pb+GK+HYjbyLcVNLoT04FgOalpw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddugeekfeculddtuddrgeefvddrtd
    dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
    fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
    dtnecunecujfgurhephffvvefufffkofggtgfgsehtkeertdertdejnecuhfhrohhmpefo
    rghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkh
    esihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhn
    peelkefhudelteelleelteetveeffeetffekteetjeehlefggeekleeghefhtdehvdenuc
    evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgr
    rhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtth
    hopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeigvghnqdguvghvvghlsehl
    ihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehmrghrmhgrrhgvkh
    esihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm
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?= 
Subject: [PATCH v1 0/5] Fix XHCI console on legacy MB2 boot
Date: Sun, 25 May 2025 16:15:41 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

XHCI console works fine with UEFI boot, as Xen doesn't relocate itself. But on
legacy boot, relocation is a problem, as the hardware is programmed with
physical addresses of structures that are moved. Fix this by adding new console
init hooks. This series includes also few minor improvements that were useful
when working on the fix.

Marek Marczykowski-Górecki (5):
  console: add relocation hook
  drivers/char: Handle Xen relocation in the XHCI console driver
  drivers/char: make dbc_uart_dump() a bit more useful
  drivers/char: remove outdated comment in xhci driver
  console: support multiple serial console simultaneously

 docs/misc/xen-command-line.pandoc |   4 +-
 xen/arch/x86/setup.c              |   8 ++-
 xen/drivers/char/Kconfig          |  11 +++-
 xen/drivers/char/console.c        | 108 ++++++++++++++++++++++++-------
 xen/drivers/char/serial.c         |  18 +++++-
 xen/drivers/char/xhci-dbc.c       |  98 +++++++++++++++++++---------
 xen/include/xen/console.h         |   2 +-
 xen/include/xen/serial.h          |   7 ++-
 8 files changed, 204 insertions(+), 52 deletions(-)

base-commit: 7ab4b392b78b5ac1c7a1fb1d085637526e67521a
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Sun May 25 14:20:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 May 2025 14:20:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997154.1378140 (Exim 4.92)
	(envelope-from )
	id 1uJCD5-0006BW-2Y; Sun, 25 May 2025 14:20:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997154.1378140; Sun, 25 May 2025 14: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 1uJCD4-0006BL-Vq; Sun, 25 May 2025 14:20:18 +0000
Received: by outflank-mailman (input) for mailman id 997154;
 Sun, 25 May 2025 14:20:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJCD4-0006Ah-Dd
 for xen-devel@lists.xenproject.org; Sun, 25 May 2025 14:20:18 +0000
Received: from fhigh-b6-smtp.messagingengine.com
 (fhigh-b6-smtp.messagingengine.com [202.12.124.157])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 60c7751d-3973-11f0-b893-0df219b8e170;
 Sun, 25 May 2025 16:20:16 +0200 (CEST)
Received: from phl-compute-02.internal (phl-compute-02.phl.internal
 [10.202.2.42])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 2D70C25400CC;
 Sun, 25 May 2025 10:20:15 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-02.internal (MEProxy); Sun, 25 May 2025 10:20:15 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 25 May 2025 10:20: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" 
X-Inumbo-ID: 60c7751d-3973-11f0-b893-0df219b8e170
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
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm3; t=1748182815; x=1748269215; bh=nvcA2fXb3e
	hl89J7/qQltbJE5fahzJ7yWRoiR9gW1UA=; b=N7xmPgvQPZcNs9lOryH9mVo0H2
	C/IMDast8elvfpA7z4GK4FC9KtXik2CKq5cQgep7UrNSlve3fom8gGMCsKtTxTXd
	wKmjdjcW8VQ3104kRF9ldRH63pXNilT4SKDcvj5NuWKVnvtJIEPJiIxpiL6oOuJR
	oSW/xipriiITpzsF/N0GWi7rnC/EwokrVItsP/gkVlAe4zBt9LS3709/iGmRyram
	YTsgO6cKMx3D6obygIQa5p3gBcFftAI5jwyVZ3fl9HohxQyAFD0oK8Qu1iFqvbDm
	BN/wCG/aO2NRCzQdckuB8O3OS9qKwQqQ4ZChLqH1ps2TJg1Z0kQq7DlK1AcQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1748182815; x=
	1748269215; bh=nvcA2fXb3ehl89J7/qQltbJE5fahzJ7yWRoiR9gW1UA=; b=X
	XtrMxeAK/jPJSKa3qy4t50Q+dIe/AwjbOrOR4Fz7gr1zS+NFoIMoLghJrTW1Loyq
	p38mTYO4/WVQeDjAZ/+iPC5lnXNV39p1OgMVUhOka/Dh4hZ+poign3YXWDGgcJz/
	kl3Nw7cizV05yon97NW4At+j6LfknwoM0V46iJzlfZeAZNAr0KpPakM18AA+psYw
	rhhdZTZkffBbfIp+sKfehKMFC6bX8uQ+piF4ZlFwzIVBX5qrTMq3eaPWhlMPXBwc
	3NK50R6ZazKciR9ocVifr9GdREpp9Kvtk/lmpnx3Ledg2JoePqxUX7wQg3RnvUZj
	VVCyELCWkb3IIRWEEbzVg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddugeekfeculddtuddrgeefvddrtd
    dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
    fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
    dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffo
    jghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofi
    hskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhn
    ghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeuudehgfdvfeehhedujeehfe
    duveeugefhkefhheelgeevudetueeiudfggfffnecuvehluhhsthgvrhfuihiivgeptden
    ucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvth
    hhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepledpmhhouggvpehsmhhtphho
    uhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtg
    htrdhorhhgpdhrtghpthhtohepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhn
    ghhslhgrsgdrtghomhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghith
    hrihigrdgtohhmpdhrtghpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghs
    rdhtvggthhdprhgtphhtthhopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdprh
    gtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtohepjhhulhhi
    vghnseigvghnrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrd
    gtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhg
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 v1 3/5] drivers/char: make dbc_uart_dump() a bit more useful
Date: Sun, 25 May 2025 16:15:44 +0200
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Make it safe to call also if xhci console is not enabled. And make it
non-static, to require one less modification when actually using it.
When using it, one still needs to add its declaration in some header
(or just next to the call site).

Signed-off-by: Marek Marczykowski-Górecki 
---
IIUC Misra would not be happy about a declaration of an usused function.
And I'd rather avoid extending DBC_DEBUG scope beyond that single file.
---
 xen/drivers/char/xhci-dbc.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c
index c4bb371ff78f..ced28cae0a29 100644
--- a/xen/drivers/char/xhci-dbc.c
+++ b/xen/drivers/char/xhci-dbc.c
@@ -1498,11 +1498,14 @@ static void dbc_dump(struct dbc *dbc)
               readq(&r->cp) == virt_to_maddr(dbc->dbc_ctx));
 }
 
-static void dbc_uart_dump(void)
+void dbc_uart_dump(void)
 {
     struct dbc_uart *uart = &dbc_uart;
     struct dbc *dbc = &uart->dbc;
 
+    if ( !dbc->enable )
+        return;
+
     dbc_dump(dbc);
 }
 #endif
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Sun May 25 14:20:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 May 2025 14:20:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997155.1378149 (Exim 4.92)
	(envelope-from )
	id 1uJCD6-0006R3-Ea; Sun, 25 May 2025 14:20:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997155.1378149; Sun, 25 May 2025 14:20: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 1uJCD6-0006Qj-9x; Sun, 25 May 2025 14:20:20 +0000
Received: by outflank-mailman (input) for mailman id 997155;
 Sun, 25 May 2025 14:20:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJCD5-0005ip-7H
 for xen-devel@lists.xenproject.org; Sun, 25 May 2025 14:20:19 +0000
Received: from fhigh-b6-smtp.messagingengine.com
 (fhigh-b6-smtp.messagingengine.com [202.12.124.157])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5dd335ca-3973-11f0-a2fb-13f23c93f187;
 Sun, 25 May 2025 16:20:11 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 2CB1325400E4;
 Sun, 25 May 2025 10:20:10 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Sun, 25 May 2025 10:20:10 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 25 May 2025 10:20:07 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 5dd335ca-3973-11f0-a2fb-13f23c93f187
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
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm3; t=1748182810; x=1748269210; bh=mWRLy4XWSq
	kSuh6T5T7Y3St8a2sE7Qw37t+DvXZ+raM=; b=Da3ocC0z9Oj3C3eZsJM8FFZPuo
	kE6bc1tOLyO/0duJYj1Id7jy5QyMJd9Z5gEL9iDx9aAfHt2a1Z77Pb5bIuXMgf1x
	hX49WmOgmIxVLiat9nAdwCjAZnnyWrk9C6KiV+qk6z9+Lq+9ejiB5OK3KCVvqCMD
	wG6SScj5crRiFKkz/HOx6SELcFxkLc6AKNSWO6YPyBRQTJwtj6bUuvyWjBmC8hH0
	ZvST6VCHWOanhCqBdGwdCRvDvm9TcJPT9bBXlmZUrPYV6kPOh8w1w1fb4+ulEV4P
	f5G5UujJr2ELQ0E7PWWebuMXEdvMIjqCC9jX1P0HBkclvagvJDr4heIeWFUQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1748182810; x=
	1748269210; bh=mWRLy4XWSqkSuh6T5T7Y3St8a2sE7Qw37t+DvXZ+raM=; b=m
	r1wNI8FH5Td8UIM+Lxd6D01f9iNgGooYb1lpw4FZ9rrQdiM7aqB8W0LqogNfPaaD
	n3ylZGqgHAICqKjIRr1fr+V4OPi6c8A4eUMH9hdm7zchfyWd8NyWdQZTnr5MaY3H
	V+zuqhW3da+qZnzaqqf/KTg55kX5qLQqjjbCZ29cLcO3pRQcZ1Z7ysWcSrwoP16c
	+L5JOFEDQRKaVbNC0KeLgsE5aZ3AI16UBkKPanBbGz+N4ue2g79khPgLy2j6lxfW
	1IRvtAexWAyUilqw2x8Gm1HLQAuUfU0+Rr1rCfn2CaVwcsPSh1pQJWSyeZ4Pz6F1
	cpTvSMkwBdCEoXBQRwzfg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddugeekfeculddtuddrgeefvddrtd
    dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
    fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
    dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffo
    jghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofi
    hskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhn
    ghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeuudehgfdvfeehhedujeehfe
    duveeugefhkefhheelgeevudetueeiudfggfffnecuvehluhhsthgvrhfuihiivgeptden
    ucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvth
    hhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepledpmhhouggvpehsmhhtphho
    uhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtg
    htrdhorhhgpdhrtghpthhtohepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhn
    ghhslhgrsgdrtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhmpd
    hrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgt
    phhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgtphhtthhopegrnh
    hthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitghh
    rghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrd
    horhhgpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhg
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?= ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH v1 1/5] console: add relocation hook
Date: Sun, 25 May 2025 16:15:42 +0200
Message-ID: <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The XHCI console uses DMA, so it's sensitive for relocating its
structures, even if their virtual addresses remain the same. Add a new
console initialization hooks called before+after Xen relocation.
Relocation happens conditionally, but call the hooks unconditionally, as
that simplifies logic in the driver (and if needed, the driver can
easily detect if relocation happened anyway). Thanks to that, a driver
may use it to finalize init steps that need physical address but can be
delayed - this way, it doesn't need un-doing on relocation.
The most important part is the post-relocation hook, but add also
pre-relocation one to simplify clean handling of in-flight data.

Signed-off-by: Marek Marczykowski-Górecki 
---
I considered more limited scope - calling them just around move_xen()
(or even from within that function), but that complicates
iommu_add_extra_reserved_device_memory() call - see the next patch.
As for the post-relocation hook, I have considered a parameter with info
whether the relocation actually happened, but driver can figure it out
on its own anyway.
---
 xen/arch/x86/setup.c       |  8 ++++++++
 xen/drivers/char/console.c | 10 ++++++++++
 xen/drivers/char/serial.c  | 18 ++++++++++++++++++
 xen/include/xen/console.h  |  2 ++
 xen/include/xen/serial.h   |  6 ++++++
 5 files changed, 44 insertions(+)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 25189541244d..3ef819a252e4 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1481,6 +1481,8 @@ void asmlinkage __init noreturn __start_xen(void)
         highmem_start &= ~((1UL << L3_PAGETABLE_SHIFT) - 1);
 #endif
 
+    console_init_pre_relocate();
+
     /*
      * Iterate backwards over all superpage-aligned RAM regions.
      *
@@ -1606,6 +1608,12 @@ void asmlinkage __init noreturn __start_xen(void)
     if ( !xen_phys_start )
         panic("Not enough memory to relocate Xen\n");
 
+    /*
+     * Notify console drivers about relocation, before reusing old Xen's
+     * memory.
+     */
+    console_init_post_relocate();
+
     /* FIXME: Putting a hole in .bss would shatter the large page mapping. */
     if ( using_2M_mapping() )
         efi_boot_mem_unused(NULL, NULL);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c15987f5bbe2..12898b684b5e 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -1120,6 +1120,16 @@ void __init console_init_ring(void)
     printk("Allocated console ring of %u KiB.\n", opt_conring_size >> 10);
 }
 
+void __init console_init_pre_relocate(void)
+{
+    serial_init_pre_relocate();
+}
+
+void __init console_init_post_relocate(void)
+{
+    serial_init_post_relocate();
+}
+
 void __init console_init_irq(void)
 {
     serial_init_irq();
diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
index 591a00900869..95f7410afa9c 100644
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -447,6 +447,24 @@ void __init serial_init_preirq(void)
             com[i].driver->init_preirq(&com[i]);
 }
 
+void __init serial_init_pre_relocate(void)
+{
+    unsigned int i;
+
+    for ( i = 0; i < ARRAY_SIZE(com); i++ )
+        if ( com[i].driver && com[i].driver->init_pre_relocate )
+            com[i].driver->init_pre_relocate(&com[i]);
+}
+
+void __init serial_init_post_relocate(void)
+{
+    unsigned int i;
+
+    for ( i = 0; i < ARRAY_SIZE(com); i++ )
+        if ( com[i].driver && com[i].driver->init_post_relocate )
+            com[i].driver->init_post_relocate(&com[i]);
+}
+
 void __init serial_init_irq(void)
 {
     unsigned int i;
diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
index 83cbc9fbdafc..d563777ad9e2 100644
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -18,6 +18,8 @@ void console_init_preirq(void);
 void console_init_ring(void);
 void console_init_irq(void);
 void console_init_postirq(void);
+void console_init_pre_relocate(void);
+void console_init_post_relocate(void);
 void console_endboot(void);
 int console_has(const char *device);
 
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 63a82b032dde..1ee3df2624fb 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -64,6 +64,9 @@ struct uart_driver {
     void (*init_preirq)(struct serial_port *port);
     void (*init_irq)(struct serial_port *port);
     void (*init_postirq)(struct serial_port *port);
+    /* Hooks around optional Xen relocation. */
+    void (*init_pre_relocate)(struct serial_port *port);
+    void (*init_post_relocate)(struct serial_port *port);
     /* Hook to clean up after Xen bootstrap (before domain 0 runs). */
     void (*endboot)(struct serial_port *port);
     /* Driver suspend/resume. */
@@ -103,6 +106,9 @@ struct uart_driver {
 void serial_init_preirq(void);
 void serial_init_irq(void);
 void serial_init_postirq(void);
+/* Notify drivers about Xen relocation (relevant for those using DMA). */
+void serial_init_pre_relocate(void);
+void serial_init_post_relocate(void);
 
 /* Clean-up hook before domain 0 runs. */
 void serial_endboot(void);
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Sun May 25 14:20:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 May 2025 14:20:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997156.1378160 (Exim 4.92)
	(envelope-from )
	id 1uJCD7-0006gA-Lx; Sun, 25 May 2025 14:20:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997156.1378160; Sun, 25 May 2025 14: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 1uJCD7-0006fr-I2; Sun, 25 May 2025 14:20:21 +0000
Received: by outflank-mailman (input) for mailman id 997156;
 Sun, 25 May 2025 14:20:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJCD6-0005ip-7J
 for xen-devel@lists.xenproject.org; Sun, 25 May 2025 14:20:20 +0000
Received: from fout-b8-smtp.messagingengine.com
 (fout-b8-smtp.messagingengine.com [202.12.124.151])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6231fc7c-3973-11f0-a2fb-13f23c93f187;
 Sun, 25 May 2025 16:20:19 +0200 (CEST)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfout.stl.internal (Postfix) with ESMTP id 863F611400ED;
 Sun, 25 May 2025 10:20:17 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-03.internal (MEProxy); Sun, 25 May 2025 10:20:17 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 25 May 2025 10:20:15 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6231fc7c-3973-11f0-a2fb-13f23c93f187
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
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm3; t=1748182817; x=1748269217; bh=mL74JBhQ+2
	8XfBxZeuQdBPRzlrPHx/K6JFX3Qfsm+Mw=; b=mZuX5yyLOH1As6zDQ0bvZXIkZr
	x8RcEnx3vLGN05OtAp+wE0D7ZyCoyFVq95tvks9N7C5fOhBI78ZGcJZXyXVw9Zag
	n/dZLeoMtd+5syfcHE1M5edt4/QrQErQlWom0S2YqyxLADzqwzSPaVBRQsqQ1TtS
	iDaIplHtE1EBQ/nwu38Dn3zIyghjJZQCTtvUik4PqQFqNfuxyzZcb/SpctY21MEM
	BS5dxzslSHmlPY2nXanrQbkgW9IkJcNOxj1MbL4zLHuomRZmxu+TFiJTO7CydwN1
	s69MBrID0YrKqh5rn/xiK1aLOlTipE/DYX52JubYcAcrkO46OMV+IueDPW9w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1748182817; x=
	1748269217; bh=mL74JBhQ+28XfBxZeuQdBPRzlrPHx/K6JFX3Qfsm+Mw=; b=n
	GKnhgb+GwXDV0n1D9jjRkF3m6YHQIMUbFmAeD14kCSxjme86uJrdCRblS07Bpr76
	OOGXiyZoJaXbW3YFOZ/4V0gcL983+QWpokrklGNShWSKEzkEFS1Owiz2lGOJUy/F
	vqkoayyuHznvd3+HecxsgkiO3NmAWW5Mit9hHH6nHp1b6IumGcDL6eKSJn05uFv0
	W2/7qtx+QJ9P6MsWqjqtf16bC39ztVmkX6VXkiY7bH0fxjVzveCc9/y01n0Y1vIE
	egLxDPNpqzOto/eiQAkVeaeAlk2bXwMTAaPVO1h9525iUkUW6BRsMkwACeQD6tkr
	aBCL6VbAAIvbpbVeLKRUw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddugeekfeculddtuddrgeefvddrtd
    dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
    fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
    dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffo
    jghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofi
    hskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhn
    ghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfeuudehgfdvfeehhedujeehfe
    duveeugefhkefhheelgeevudetueeiudfggfffnecuvehluhhsthgvrhfuihiivgeptden
    ucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvth
    hhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepledpmhhouggvpehsmhhtphho
    uhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtg
    htrdhorhhgpdhrtghpthhtohepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhn
    ghhslhgrsgdrtghomhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghith
    hrihigrdgtohhmpdhrtghpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghs
    rdhtvggthhdprhgtphhtthhopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdprh
    gtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtohepjhhulhhi
    vghnseigvghnrdhorhhgpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrd
    gtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhg
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 v1 4/5] drivers/char: remove outdated comment in xhci driver
Date: Sun, 25 May 2025 16:15:45 +0200
Message-ID: <6abaf3a05c8ea7204bea2046a799bc577e0b77e8.1748182535.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The input handling is already implemented, and that limitation is not
there anymore.

Signed-off-by: Marek Marczykowski-Górecki 
---
 xen/drivers/char/xhci-dbc.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c
index ced28cae0a29..3692776cec11 100644
--- a/xen/drivers/char/xhci-dbc.c
+++ b/xen/drivers/char/xhci-dbc.c
@@ -672,10 +672,6 @@ static void dbc_rx_trb(struct dbc *dbc, struct xhci_trb *trb,
         cache_flush(&ring->buf[start], end - start);
 }
 
-/*
- * Note that if IN transfer support is added, then this
- * will need to be changed; it assumes an OUT transfer ring only
- */
 static void dbc_pop_events(struct dbc *dbc)
 {
     struct dbc_reg *reg = dbc->dbc_reg;
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Sun May 25 14:20:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 25 May 2025 14:20:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997158.1378170 (Exim 4.92)
	(envelope-from )
	id 1uJCDC-00072W-Vq; Sun, 25 May 2025 14:20:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997158.1378170; Sun, 25 May 2025 14:20: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 1uJCDC-00072F-SO; Sun, 25 May 2025 14:20:26 +0000
Received: by outflank-mailman (input) for mailman id 997158;
 Sun, 25 May 2025 14:20:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJCDA-0006Ah-Os
 for xen-devel@lists.xenproject.org; Sun, 25 May 2025 14:20:24 +0000
Received: from fhigh-b6-smtp.messagingengine.com
 (fhigh-b6-smtp.messagingengine.com [202.12.124.157])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 638175e0-3973-11f0-b893-0df219b8e170;
 Sun, 25 May 2025 16:20:20 +0200 (CEST)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.stl.internal (Postfix) with ESMTP id B9CF425400CA;
 Sun, 25 May 2025 10:20:19 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Sun, 25 May 2025 10:20:19 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 25 May 2025 10:20:17 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 638175e0-3973-11f0-b893-0df219b8e170
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
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm3; t=1748182819; x=1748269219; bh=8N0UZzKt4D
	QbodDXdvRtwVlKHw5NKvan8QfhJwtoCk8=; b=BhL1n/QeRiZ5LIM3pw/lE4MNPI
	jnNyVsgCW6EOTbt2MYUlrmmicZ0DHbaaY66u0Tn3MULNqBXJQ7ZdxerNg4aoFKto
	7AVB++4Ow+EemU1aLbdkOXf90Zm9A2ONnf2HrrtKe/wwNPr5ruBFtbpTzMVG9xBW
	AL2GLp319pmzi+eqYbDN6kXnMYYDoSSp31gtGfdJCvoH3UA+sVArHJuDBm7Cnffg
	1NKQHXOUPdgv0xI1EjoTslHWNuyKr6lXNlkNd7HNgHVlJ+GE3ps3FkdsVOEAap0A
	VQQLRT6ZyLJbUgOTfZOhZbP7IjZvcoVnBVQnS062uUHVl46niQ2qL7r71wgQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1748182819; x=
	1748269219; bh=8N0UZzKt4DQbodDXdvRtwVlKHw5NKvan8QfhJwtoCk8=; b=U
	J6bOiBqrsmflyAGrQZRClJtBba3espjZkLKDVsCaIB8dyAhfwDIAyqZVTidk47dV
	XwHNuU3Ych4r/eXVYN9e7Z+/GyPgAeh/HvIHIiNTrwvli+uIu/YfWEqpA8S3FWXa
	W1JjiawMc6IJj6NxOWbaRn6mh91IqZCrCgHcjK/tC4pObbxyjKRwhIsqUSJakS/q
	M+lklnhY6RTixkKJ1ddubGMVO67JYgGPFCBEbBQI66I5RghW6JL9oC2bW/c/KQ+J
	yGr1g47hL2hLsbCyWjVu6J949DJER4yrQavgKkYL9p5Z2IDn3Up0270ej9Nr7FWU
	0Uovp1mdjiPYRHICDMQiQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddugeekfeculddtuddrgeefvddrtd
    dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
    fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
    dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffo
    jghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofi
    hskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhn
    ghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepffeitdegveffteelvdeghffhve
    fghfefkeelheeujeejgedvvdfgffejuedtvdelnecuffhomhgrihhnpehkvghrnhgvlhdr
    ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggp
    rhgtphhtthhopeelpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeigvghnqdguvg
    hvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehmrghr
    mhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhrtghpthhtoh
    eprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopegr
    nhhthhhonhihrdhpvghrrghrugesvhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitg
    hhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehs
    uhhsvgdrtghomhdprhgtphhtthhopehjuhhlihgvnhesgigvnhdrohhrghdprhgtphhtth
    hopehrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgtphhtthhopehsshhtrggs
    vghllhhinhhisehkvghrnhgvlhdrohhrgh
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 v1 5/5] console: support multiple serial console simultaneously
Date: Sun, 25 May 2025 16:15:46 +0200
Message-ID: <98ff383ff2ee3dc162b2d12afaea2b3f1406d99e.1748182535.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Previously only one serial console was supported at the same time. Using
console=com1,dbgp,vga silently ignored all but last serial console (in
this case: only dbgp and vga were active).

Fix this by storing not a single sercon_handle, but an array of them, up
to MAX_SERCONS entries. The value of MAX_SERCONS can be chosen in
kconfig, the default (4) is arbitrary, inspired by the number of
SERHND_IDX values.

Make console_steal() aware of multiple consoles too. It can now either
steal output from specific console (for gdbstub), or from all of them at
once (for console suspend).

Signed-off-by: Marek Marczykowski-Górecki 
---
This was posted before as part of initial xhci console submission, it
reached v6 (but last changes were in v4), but wasn't considered useful
enough to review/ack:
https://lore.kernel.org/xen-devel/Yu0XHUhsebE+WG0g@mail-itl/

Since I needed this feature again, to debug xhci console issue, I'm
including this patch again in the series.

Changes in v4:
- use unsigned int for loop counters
- other minor changes
Changes in v3:
- adjust console_steal() for multiple consoles too
- add MAX_SERCONS to kconfig
- add warning about sync_console impact
- add warning if too many consoles are configured
- log issue with PCI spec parsing
---
 docs/misc/xen-command-line.pandoc |  4 +-
 xen/drivers/char/Kconfig          | 11 ++++-
 xen/drivers/char/console.c        | 98 ++++++++++++++++++++++++--------
 xen/include/xen/serial.h          |  1 +-
 4 files changed, 92 insertions(+), 22 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index b0eadd2c5d58..052c01f87bfc 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -456,6 +456,9 @@ only available when used together with `pv-in-pvh`.
 `none` indicates that Xen should not use a console.  This option only
 makes sense on its own.
 
+Specifying more than one serial console will increase console latency,
+especially when `sync_console` option is used.
+
 ### console_timestamps
 > `= none | date | datems | boot | raw`
 
@@ -2637,6 +2640,7 @@ Intel SA-00982.  Intel suggest that some workloads will benefit from this.
 
 Flag to force synchronous console output.  Useful for debugging, but
 not suitable for production environments due to incurred overhead.
+If multiple consoles are configured, the incurred overhead is even bigger.
 
 ### tboot (x86)
 > `= 0x`
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index e6e12bb41397..76305fcb4afa 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -96,6 +96,17 @@ config SERIAL_TX_BUFSIZE
 
 	  Default value is 32768 (32KiB).
 
+config MAX_SERCONS
+	int "Maximum number of serial consoles active at once"
+	default 4
+	help
+	  Controls how many serial consoles can be active at once. Configuring more
+	  using `console=` parameter will be ignored.
+	  When multiple consoles are configured, overhead of `sync_console` option
+	  is even bigger.
+
+	  Default value is 4.
+
 config XHCI
 	bool "XHCI DbC UART driver"
 	depends on X86
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 12898b684b5e..e306986bfcbc 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -134,7 +134,9 @@ static char *__read_mostly conring = _conring;
 static uint32_t __read_mostly conring_size = _CONRING_SIZE;
 static uint32_t conringc, conringp;
 
-static int __read_mostly sercon_handle = -1;
+#define MAX_SERCONS CONFIG_MAX_SERCONS
+static int __read_mostly sercon_handle[MAX_SERCONS];
+static unsigned int __read_mostly nr_sercon_handle = 0;
 
 #ifdef CONFIG_X86
 /* Tristate: 0 disabled, 1 user enabled, -1 default enabled */
@@ -424,32 +426,61 @@ long read_console_ring(struct xen_sysctl_readconsole *op)
 static char serial_rx_ring[SERIAL_RX_SIZE];
 static unsigned int serial_rx_cons, serial_rx_prod;
 
-static void (*serial_steal_fn)(const char *str, size_t nr) = early_puts;
+/* The last entry means "steal from all consoles" */
+static void (*serial_steal_fn[])(const char *str, size_t nr) = {
+    [MAX_SERCONS] = early_puts,
+};
 
+/*
+ * Redirect console *handle* output to *fn*. Use SERHND_STEAL_ALL as *handle* to
+ * redirect all the consoles. 
+ */
 int console_steal(int handle, void (*fn)(const char *str, size_t nr))
 {
-    if ( (handle == -1) || (handle != sercon_handle) )
-        return 0;
+    unsigned int i;
+
+    if ( handle == -1 )
+        return -ENOENT;
+    if ( serial_steal_fn[MAX_SERCONS] != NULL )
+        return -EBUSY;
+    if ( handle == SERHND_STEAL_ALL )
+    {
+        serial_steal_fn[MAX_SERCONS] = fn;
+        return MAX_SERCONS;
+    }
+    for ( i = 0; i < nr_sercon_handle; i++ )
+        if ( handle == sercon_handle[i] )
+            break;
+    if ( i == nr_sercon_handle )
+        return -ENOENT;
 
-    if ( serial_steal_fn != NULL )
+    if ( serial_steal_fn[i] != NULL )
         return -EBUSY;
 
-    serial_steal_fn = fn;
-    return 1;
+    serial_steal_fn[i] = fn;
+    return i;
 }
 
 void console_giveback(int id)
 {
-    if ( id == 1 )
-        serial_steal_fn = NULL;
+    if ( id >= 0 && id <= MAX_SERCONS )
+        serial_steal_fn[id] = NULL;
 }
 
 void console_serial_puts(const char *s, size_t nr)
 {
-    if ( serial_steal_fn != NULL )
-        serial_steal_fn(s, nr);
+    unsigned int i;
+
+    if ( serial_steal_fn[MAX_SERCONS] != NULL )
+        serial_steal_fn[MAX_SERCONS](s, nr);
     else
-        serial_puts(sercon_handle, s, nr);
+        for ( i = 0; i < nr_sercon_handle; i++ )
+        {
+            if ( serial_steal_fn[i] != NULL )
+                serial_steal_fn[i](s, nr);
+            else
+                serial_puts(sercon_handle[i], s, nr);
+        }
 }
 
 /*
@@ -1026,6 +1057,7 @@ void __init console_init_preirq(void)
 {
     char *p;
     int sh;
+    unsigned int i;
 
     serial_init_preirq();
 
@@ -1046,8 +1078,12 @@ void __init console_init_preirq(void)
             continue;
         else if ( (sh = serial_parse_handle(p)) >= 0 )
         {
-            sercon_handle = sh;
-            serial_steal_fn = NULL;
+            if ( nr_sercon_handle < MAX_SERCONS )
+                sercon_handle[nr_sercon_handle++] = sh;
+            else
+                printk("Too many consoles (max %d), ignoring '%s'\n",
+                       MAX_SERCONS, p);
+            serial_steal_fn[MAX_SERCONS] = NULL;
         }
         else
         {
@@ -1065,7 +1101,8 @@ void __init console_init_preirq(void)
         opt_console_xen = 0;
 #endif
 
-    serial_set_rx_handler(sercon_handle, serial_rx);
+    for ( i = 0; i < nr_sercon_handle; i++ )
+        serial_set_rx_handler(sercon_handle[i], serial_rx);
     pv_console_set_rx_handler(serial_rx);
 
     /* NB: send conring contents to all enabled physical consoles, if any */
@@ -1084,7 +1121,8 @@ void __init console_init_preirq(void)
 
     if ( opt_sync_console )
     {
-        serial_start_sync(sercon_handle);
+        for ( i = 0; i < nr_sercon_handle; i++ )
+            serial_start_sync(sercon_handle[i]);
         add_taint(TAINT_SYNC_CONSOLE);
         printk("Console output is synchronous.\n");
         warning_add(warning_sync_console);
@@ -1201,13 +1239,19 @@ int __init console_has(const char *device)
 
 void console_start_log_everything(void)
 {
-    serial_start_log_everything(sercon_handle);
+    unsigned int i;
+
+    for ( i = 0; i < nr_sercon_handle; i++ )
+        serial_start_log_everything(sercon_handle[i]);
     atomic_inc(&print_everything);
 }
 
 void console_end_log_everything(void)
 {
-    serial_end_log_everything(sercon_handle);
+    unsigned int i;
+
+    for ( i = 0; i < nr_sercon_handle; i++ )
+        serial_end_log_everything(sercon_handle[i]);
     atomic_dec(&print_everything);
 }
 
@@ -1223,23 +1267,32 @@ void console_unlock_recursive_irqrestore(unsigned long flags)
 
 void console_force_unlock(void)
 {
+    unsigned int i;
+
     watchdog_disable();
     spin_debug_disable();
     rspin_lock_init(&console_lock);
-    serial_force_unlock(sercon_handle);
+    for ( i = 0 ; i < nr_sercon_handle ; i++ )
+        serial_force_unlock(sercon_handle[i]);
     conring_no_notify = true;
     console_start_sync();
 }
 
 void console_start_sync(void)
 {
+    unsigned int i;
+
     atomic_inc(&print_everything);
-    serial_start_sync(sercon_handle);
+    for ( i = 0 ; i < nr_sercon_handle ; i++ )
+        serial_start_sync(sercon_handle[i]);
 }
 
 void console_end_sync(void)
 {
-    serial_end_sync(sercon_handle);
+    unsigned int i;
+
+    for ( i = 0; i < nr_sercon_handle; i++ )
+        serial_end_sync(sercon_handle[i]);
     atomic_dec(&print_everything);
 }
 
@@ -1362,7 +1415,8 @@ static int suspend_steal_id;
 
 int console_suspend(void)
 {
-    suspend_steal_id = console_steal(sercon_handle, suspend_steal_fn);
+    if ( nr_sercon_handle )
+        suspend_steal_id = console_steal(SERHND_STEAL_ALL, suspend_steal_fn);
     serial_suspend();
     return 0;
 }
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 1ee3df2624fb..31159814d883 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -101,6 +101,7 @@ struct uart_driver {
 #define SERHND_HI       (1<<2) /* Mux/demux each transferred char by MSB. */
 #define SERHND_LO       (1<<3) /* Ditto, except that the MSB is cleared.  */
 #define SERHND_COOKED   (1<<4) /* Newline/carriage-return translation?    */
+#define SERHND_STEAL_ALL 0xff  /* Synthetic handle used in console_steal() */
 
 /* Three-stage initialisation (before/during/after IRQ-subsystem setup). */
 void serial_init_preirq(void);
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Mon May 26 04:56:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 04:56:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997257.1378180 (Exim 4.92)
	(envelope-from )
	id 1uJPsl-0000mr-Cm; Mon, 26 May 2025 04:56:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997257.1378180; Mon, 26 May 2025 04: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 1uJPsl-0000mZ-79; Mon, 26 May 2025 04:56:15 +0000
Received: by outflank-mailman (input) for mailman id 997257;
 Mon, 26 May 2025 03:36:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJOe0-0000D9-Li
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 03:36:56 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20622.outbound.protection.outlook.com
 [2a01:111:f403:2414::622])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id aa716f2a-39e2-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 05:36:54 +0200 (CEST)
Received: from MW4P222CA0008.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::13)
 by BL3PR12MB9049.namprd12.prod.outlook.com (2603:10b6:208:3b8::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Mon, 26 May
 2025 03:36:48 +0000
Received: from SJ1PEPF00001CE7.namprd03.prod.outlook.com
 (2603:10b6:303:114:cafe::91) by MW4P222CA0008.outlook.office365.com
 (2603:10b6:303:114::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Mon,
 26 May 2025 03:36:48 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ1PEPF00001CE7.mail.protection.outlook.com (10.167.242.23) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 03:36:47 +0000
Received: from [10.85.47.107] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sun, 25 May
 2025 22:36: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" 
X-Inumbo-ID: aa716f2a-39e2-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cyOutsl0JWDdUi3VF7Fbf6XYNd983YSiFIUvcFbSIxsKWZ4E6PtF+PVkPMa+ox7yk8Af/jYb3/UIcjv7IPJJJQfpjEaGN8z3GwksmThm2mDxJEnchROPa2UJ5JY4XZpWum38F2Vhc+r/fb52x97T84egFUubcPHej6YBun/lkC8WGqFMi3fzIJuW/set3BJapPWeOatbCEyfy2CBc+lTUF3mEydLN9kUsyJurUXCmRY+k0X4GNeb5ry6D6UrZ6PRfBqOanMSfmqJPiMY77UfMBfBPn7EuTHhxEhJ+l5oPjInk4t7lW4OxcQNT6N3O0sUypGc0vrPIeShI1ESgu9Leg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=AcW/L6v+m+CrfjHxmtlsRoH+9g7AQSR4jQVgl1NCXok=;
 b=YWI93GBpJHbad4AzFVb6m92G5KJiIgT/GGpN4+agPRR/zGkGHnZfCvsLblFJcStwqyqcLQLv7Q2vgDDWjbjXW12wGI4oR0ER3zgmpimtKDw+BQFUECeaUA4wqRxhvOjzRrYnTGQkEQz+8Pg0U/tl0zrosiCL6QiMoEJBQp6o/3FE4khYJlvWkVDaVPW4Ag2mGcPAe44i06tnikyagiOqGVRLWIazAD0Vfpjla9hCErNEBLDc44T6VsBFZhor4dJZnRBGrdguCJQRowXe/FvBJ1+s6SebKKQ4yeCnPgfrwKhwNZrBVBiEZxfB6QEJEQMNytCfkVcus3Y4IVR9zuhffA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=google.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=AcW/L6v+m+CrfjHxmtlsRoH+9g7AQSR4jQVgl1NCXok=;
 b=rG+8xNaa9F+5+WBOHbfSXgrc2X6ucBKfObO64gzRjAaLgcg5FEHYT82PL2sjILB1KLX9iS+JkPN5zxYguN6RWEy6PGe3h9Xk6ruVUktZ5d8g/WeBJtS2BLWAi1G40SbRM5nW4Mz6Bqk0pUGjUGFaYMGbb4OFTPjS+aMlshLEyyA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <432193cf-e4bd-4cfb-a146-25b19c02d78e@amd.com>
Date: Mon, 26 May 2025 09:06:35 +0530
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 13/13] KVM: selftests: Add a KVM_IRQFD test to verify
 uniqueness requirements
To: Sean Christopherson 
CC: "K. Y. Srinivasan" , Haiyang Zhang
	, Wei Liu , Dexuan Cui
	, Juergen Gross , Stefano Stabellini
	, Paolo Bonzini , Ingo Molnar
	, Peter Zijlstra , Juri Lelli
	, Vincent Guittot , "Shuah
 Khan" , Marc Zyngier , Oliver Upton
	, ,
	, ,
	, ,
	, , "K Prateek
 Nayak" , David Matlack 
References: <20250522235223.3178519-1-seanjc@google.com>
 <20250522235223.3178519-14-seanjc@google.com>
 <2c52daad-0b64-48a9-8e73-d1aba977993b@amd.com> 
Content-Language: en-US
From: Sairaj Kodilkar 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CE7:EE_|BL3PR12MB9049:EE_
X-MS-Office365-Filtering-Correlation-Id: 93188829-a743-42d1-a849-08dd9c068b78
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?a0EralROS043WjhCbHFOZ2lydDZJaGFDRUdGR3JxZVVwT3FYbTZJOUdvZGhZ?=
 =?utf-8?B?YktPQXg5Zy9EMXcwMzFHaFNFOVBPc0UxUHBiUFlIeThjRmVaSW5IbDNKekpI?=
 =?utf-8?B?bWFnbTR5VXZ6WEVoTUFRcWN2alVDbHlKRU9BRzA4bEU2Qlp5aXZZcVl4cTgx?=
 =?utf-8?B?UHFqYm9Wbkx6ak9oWGpMRldMbmxsdy9OQ3ZxWVN6cTFSK2dmdy9pMFlHYVU5?=
 =?utf-8?B?MnNUWHZRRFNYNXRhR3o4blBQbksxM1FkN2dqL0hjdHhpRE9oTkRwRmFKY1Na?=
 =?utf-8?B?bUN6NG04UlBxM0tZczJqSEVOZ0FSNW44NFNLTWZMTDFCbERJQklhWnVvalFK?=
 =?utf-8?B?RDJsOXMxL2txVWl5cGJqdFU1OEwwSGU2eGtWaVNweWdJWVRscWFsNDQyNFdL?=
 =?utf-8?B?QTZBYW5Fd1RyY3pENHYzNmJsME0xOU5XOGovNmNkWmlkaDRIME5ncEFJQ0Fh?=
 =?utf-8?B?N2MwT2JydW15VWFOQ255VGxxNXhiM2FxSnFFRzl6dVo3UEo4bGRnS3ZzbnFq?=
 =?utf-8?B?SERiUGZpQnJndmRmbGc3eko5aFFhNGozUUI3d1U4TkorOHlpSFp3USs1NnZU?=
 =?utf-8?B?TjNJTnVTYVhlR0dnRWQzODlNQWQxTk4vWTgvVjI5Vm5pTnJEam5mOHdBWVdK?=
 =?utf-8?B?akE4MlVqRzM5R2UxTUZMSjFZbVA2T2hWQ1VHVHVkaC9mWWlldXFEdCs3NTk5?=
 =?utf-8?B?Mkd4Z21aSXViUG92ZHJaUkZxeHlteFcyNnRiTEZEd2F6QWhURS9ESkNFbmlB?=
 =?utf-8?B?N2FZT0tnTmZkdzU0eDFoSzhHbS8ydHJsWmRTN3FWdGlOVUhVa09ydSt5N3Fm?=
 =?utf-8?B?UjIvZnpVYkluSVVUdENzMzE2ZGdtd1I5WHZ1bmIxSGNtRzhLaElWc1JWZjFt?=
 =?utf-8?B?VW14b3dOVDMxU1B2bnQ3d0RBam5mcWwwUzdCRkZjWFJHUk1tTEN6aE9TTFhI?=
 =?utf-8?B?OVUvUzg2d2N1QjZGdjI0QkxFMzZDTEZOanYxQWdJcURDT3J4bnFZVkxhajht?=
 =?utf-8?B?dEF0cEs4SUhyRVNyVTErZzRqRS91ZXU2d2pDd3B4L0tJN2VBMEV6cDlidGJX?=
 =?utf-8?B?NkhxQnM3dDAyQnNpVDhqTVM3Ly9QS25NMWtUa3IvbE0vM2pVMmlrOHFPampn?=
 =?utf-8?B?LythNmVYUDN4ajFQWmdjbXpMbzdDUW1mUWpJb0E2aGdTc2dLZkNTdXU2MlBD?=
 =?utf-8?B?TnFLakZzWUlROWJNWDRXL3Rsb0dDYWhzcTFIQ0pPakp6VEVkWWNub1A0dFpP?=
 =?utf-8?B?MTRKSk1LRkYvYnJYb2gvTjRDbkx3ZFRqL3BtdUtoeUZmcFh2ZHBRMlJWSkRF?=
 =?utf-8?B?R0xVOEVEU1crVEJlV0ZzVlFTcWtCQmt0NWpHdnp6S2JmN3hacmgvMG5jOS9E?=
 =?utf-8?B?RWg3ZjhNMy9CRjhCS1Z4VGppKzdoYzdjbVhJREJ5ZGZobUFGTUtPVEFWZVUv?=
 =?utf-8?B?OVhySWhOVzBORXdmajJxK25TWE5JWnlxb05IRUVkcGt3RElRek1ycStzbFFG?=
 =?utf-8?B?NkFkTi8zb29TYUd1bGVWdXdtTENaQUFKOHpka0JSaUF0NVZZU2ZwVE9OM2M4?=
 =?utf-8?B?UGVRWHdTWE5KNis4STd1Mm9pU0FjUU9MUnBPT3l0cnpPTTRLaGY1dXZEL0Qx?=
 =?utf-8?B?czNURXVwUkFKS0JoMzFOalo5VzVNU3VYVHFtQnFSVkxzbGdicndNbU03dDla?=
 =?utf-8?B?TnRReVQ3eFM2dysxNThZWUgwZU9YUWRKNjFRb3RMMFNLdWdqUDFGcDAyS0VN?=
 =?utf-8?B?NldMbW5sWXNwb1JGYmxmd2lBUS9SRUZTNDdiT0l5MWtpc3YxaDFIdUdnQTFM?=
 =?utf-8?B?dmFtWEtaVEhtdUxjMjFCZU5rSXpCMFBUREJQdytINW5BN3dWT1NhT3FrQnMr?=
 =?utf-8?B?dGgvQThnVmJsd1VnVnIzRy83NlQ1bUdDWStmaVRoczk2WnhXSk9HZVFVcGQ4?=
 =?utf-8?B?WFhOL3FiZUxsck5KZ2lObjZTNXlIcWM3ajgzd3IzU1pUVmNqeVpzTUduYm16?=
 =?utf-8?B?bnNhWnJORGlUcVRZNGNuV21vbEFqYkl2Y2huT2dxTkwyYWIvbmQ3VktodCtF?=
 =?utf-8?Q?nSkLAd?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 03:36:47.8886
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 93188829-a743-42d1-a849-08dd9c068b78
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00001CE7.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB9049



On 5/23/2025 8:03 PM, Sean Christopherson wrote:
> On Fri, May 23, 2025, Sairaj Kodilkar wrote:
>> On 5/23/2025 5:22 AM, Sean Christopherson wrote:
>>
>>> +
>>> +int main(int argc, char *argv[])
>>> +{
>>> +	pthread_t racing_thread;
>>> +	int r, i;
>>> +
>>> +	/* Create "full" VMs, as KVM_IRQFD requires an in-kernel IRQ chip. */
>>> +	vm1 = vm_create(1);
>>> +	vm2 = vm_create(1);
>>> +
>>> +	WRITE_ONCE(__eventfd, kvm_new_eventfd());
>>> +
>>> +	kvm_irqfd(vm1, 10, __eventfd, 0);
>>> +
>>> +	r = __kvm_irqfd(vm1, 11, __eventfd, 0);
>>> +	TEST_ASSERT(r && errno == EBUSY,
>>> +		    "Wanted EBUSY, r = %d, errno = %d", r, errno);
>>> +
>>> +	r = __kvm_irqfd(vm2, 12, __eventfd, 0);
>>> +	TEST_ASSERT(r && errno == EBUSY,
>>> +		    "Wanted EBUSY, r = %d, errno = %d", r, errno);
>>> +
>>> +	kvm_irqfd(vm1, 11, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
>>> +	kvm_irqfd(vm1, 12, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
>>> +	kvm_irqfd(vm1, 13, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
>>> +	kvm_irqfd(vm1, 14, READ_ONCE(__eventfd), KVM_IRQFD_FLAG_DEASSIGN);
>>
>> Hi Sean,
>> I dont see any allocation for the GSI 13 and 14..
>> Is there any reason for the deassigning these two GSIs ?
> 
> Yes, KVM's rather bizarre ABI is that DEASSIGN is allowed even if the VM doesn't
> have a corresponding assigned irqfd.  The reason I added these early DEASSIGN
> calls is so that there will be an easier-to-debug failure if KVM's behavior
> changes (the racing threads part of the test abuses KVM's ABI).  I didn't add a
> comment because the helpers already have comments, but looking at this again, I
> agree that main() needs a better comment.

Makes sense, thanks for the explanation.

Thanks
Sairaj Kodilkar



From xen-devel-bounces@lists.xenproject.org Mon May 26 06:33:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 06:33:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997312.1378206 (Exim 4.92)
	(envelope-from )
	id 1uJROd-0005yP-BW; Mon, 26 May 2025 06:33:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997312.1378206; Mon, 26 May 2025 06:33: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 1uJROd-0005yI-8d; Mon, 26 May 2025 06:33:15 +0000
Received: by outflank-mailman (input) for mailman id 997312;
 Mon, 26 May 2025 06:33:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uJROc-0005yC-4T
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 06:33:14 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 49b22c72-39fb-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 08:33:08 +0200 (CEST)
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 22E3F1FD8F;
 Mon, 26 May 2025 06:33:08 +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 EA65413964;
 Mon, 26 May 2025 06:33:07 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id X3I1NyMLNGgrJAAAD6G6ig
 (envelope-from ); Mon, 26 May 2025 06:33: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" 
X-Inumbo-ID: 49b22c72-39fb-11f0-b893-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748241188; 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=zGNZ+JLXDJRRpx6LE3gwjhIvbIY7oVcOX1mEu7WDYc8=;
	b=CkVCcY2l9LFAwNUuVz2jbCyutW0gPIWROrOY4Y1ZfJqlmAHoNX1ehAuTKDmSOrpfiA3k3d
	3FIrTPceGsxN2/sDiBg1CKYYGcWkr7fH4Fn97ewGsYn9qW5JMB8bDu1WPjClHRZtxbAatn
	g1pOZI4Ru9AmBjP0Uin7St2fGPOM/+w=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748241188; 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=zGNZ+JLXDJRRpx6LE3gwjhIvbIY7oVcOX1mEu7WDYc8=;
	b=CkVCcY2l9LFAwNUuVz2jbCyutW0gPIWROrOY4Y1ZfJqlmAHoNX1ehAuTKDmSOrpfiA3k3d
	3FIrTPceGsxN2/sDiBg1CKYYGcWkr7fH4Fn97ewGsYn9qW5JMB8bDu1WPjClHRZtxbAatn
	g1pOZI4Ru9AmBjP0Uin7St2fGPOM/+w=
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 v6.16-rc1
Date: Mon, 26 May 2025 08:33:07 +0200
Message-ID: <20250526063307.10920-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spam-Flag: NO
X-Spam-Score: 0.20
X-Spamd-Result: default: False [0.20 / 50.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.16-rc1-tag

xen: branch for v6.16-rc1

It contains the following patches:

- A fix for running as a Xen dom0 on the iMX8QXP Arm platform.

- An update of the xen.config adding XEN_UNPOPULATED_ALLOC for better
  support of PVH dom0.

- A fix of the Xen balloon driver when running without
  CONFIG_XEN_UNPOPULATED_ALLOC.

- A fix of the dm_op Xen hypercall on Arm needed to pass user space
  buffers to the hypervisor in certain configurations.


Thanks.

Juergen

 arch/arm64/xen/hypercall.S | 21 ++++++++++++++++++++-
 drivers/xen/balloon.c      | 13 ++++++++-----
 drivers/xen/swiotlb-xen.c  |  1 +
 kernel/configs/xen.config  |  3 +++
 4 files changed, 32 insertions(+), 6 deletions(-)

John Ernberg (1):
      xen: swiotlb: Wire up map_resource callback

Roger Pau Monne (2):
      xen: enable XEN_UNPOPULATED_ALLOC as part of xen.config
      xen/x86: fix initial memory balloon target

Stefano Stabellini (1):
      xen/arm: call uaccess_ttbr0_enable for dm_op hypercall


From xen-devel-bounces@lists.xenproject.org Mon May 26 08:48:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 08:48:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997325.1378216 (Exim 4.92)
	(envelope-from )
	id 1uJTVG-0004wb-Mb; Mon, 26 May 2025 08:48:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997325.1378216; Mon, 26 May 2025 08:48: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 1uJTVG-0004wU-Jn; Mon, 26 May 2025 08:48:14 +0000
Received: by outflank-mailman (input) for mailman id 997325;
 Mon, 26 May 2025 08:48:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJTVG-0004wO-1Y
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 08:48:14 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 26ba3354-3a0e-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 10:48:10 +0200 (CEST)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-55324587a53so350691e87.0
 for ; Mon, 26 May 2025 01:48:10 -0700 (PDT)
Received: from EPUAKYIW02F7.epam.com (ll-22.209.223.85.sovam.net.ua.
 [85.223.209.22]) by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-55221dd8ebbsm681271e87.152.2025.05.26.01.48.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 26 May 2025 01:48: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" 
X-Inumbo-ID: 26ba3354-3a0e-11f0-b893-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748249289; x=1748854089; 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;
        bh=eYXbSvTNBknTdvjpQDxcbW9o3Gr73MB+dKdmFiZcULI=;
        b=dS3ZdhWsYlfxyuXOvS/zFftG6q1LvErBVvghHvaiMlVrzHFDtDEAIkmSfXThmn0KlZ
         vXTdKgsva5psN0A8e849NwRJUPhJTC4czx/nPix3oxavgibr0aDPRHak+KKWlHiUoRdK
         NrZx2bWFBCfi5a6iZXfl8kKFdyo6a9esPRSi62m4uAkj9nyY1IcBx6/fCIowKB6W4jJg
         3RbG3Qh4Jd2N7Qx0DetXu59cWtKNXM/CsXGMBhNb6kyxLB5ToeQkYcrv6n2jGRl9eMT1
         2DvV7l0u78HPlHkVh177B7D4gSQ6mtKn/LMvbwJ31wlMMli+sWTE1Qp3KWZOqj+1DT3w
         +Zdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748249289; x=1748854089;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=eYXbSvTNBknTdvjpQDxcbW9o3Gr73MB+dKdmFiZcULI=;
        b=kz80G7n9V/7uQN9YNcl03SipVNQ7YkplF50YIqJpBvA0huehf79NLb8+TRNwFoAaxK
         nKh/tIz9586WqORr92l+yWk1aBHgq9qWoN3YtTndXz586XkLaFfCwljwVNQpu/OF8OAl
         SaPBFj8yPaH+Madil4Mlnb6q5YOsTecpJqEua5QQ9O6UoUAHRj+2uGkBTqTusK7AzME2
         F0sl/4/va119JKFEax0voFr+sK8MAB0eom7lIAQND2+HuN2c0u6RCRlIZYhbLkV/V6a4
         KmA4igVWovEcIhXJZgAuXudEa9eHZDXrSbxRPTYgUTWANu0baz/BGwYKp0PVadYBwNLd
         wB+w==
X-Gm-Message-State: AOJu0YzYd+Dcbe4WK0S7gTey4GGnveBCTRN087pOodXr2NTVBSLkqGXo
	GI0kh7ljNIFI/nFqqWEzIYQJ5l48ubwIkxoMMMENtrPZd3lwv5sVoCMp1/7SXQ==
X-Gm-Gg: ASbGnctimLOAP79/VTA9Xe3hRRpWoBBVU7oWTkPKf8Z/SqDyehDvWVLWEaBSEZ1dR1y
	fqbL8WBHJifojSegexcvkcnGa+sMSkgPlGNaP8X8kIZFd+4XVTUwSUVG7r31v2s8boKRjvZ1enC
	5LaQizylFPXmhJExveKkqayc8hF+/GyGqLM0GX7vsrxW3l/y2eU+luAT+lssXgay/LYIvxdLWLU
	WVpACWDcx67777iNP3rypcxtifxtuHhY5G9MSAXDEPzUi+hTwr6XQJugbrq9t8BASaSzjKxpVm8
	2PATDjRy+ya6PvAzEk9n0u+lq9VV54JWx8lpe00s7lhHexiPL2Ih4qXjjK5j0+wFeKr5omyWRyI
	vv0mMZ4b9GKHLSgFjyAR/nw==
X-Google-Smtp-Source: AGHT+IGCt+/TQ61WJm5BeFSGB5Vw6KM7c3QUZUp9y1wyt7jjl6pew9S26jW+kvqpPDJ1tgtTh1GqAQ==
X-Received: by 2002:a05:6512:3da7:b0:550:e7fc:352 with SMTP id 2adb3069b0e04-552156e7b1dmr3614987e87.25.1748249289199;
        Mon, 26 May 2025 01:48:09 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Mykola Kvach 
Subject: [PATCH v2] arm/irq: Reduce size of irq_desc array to exclude local IRQs
Date: Mon, 26 May 2025 11:46:59 +0300
Message-ID: <3563c1fa071f8f3a65f168f5a50ebe3d982dd75b.1748248867.git.xakep.amatop@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

SGI and PPI descriptors are banked and stored in the per-CPU local_irq_desc
array, so not all elements of the global irq_desc array are used. This is
already accounted for in the descriptor lookup logic inside __irq_to_desc:
    return &irq_desc[irq - NR_LOCAL_IRQS];

Therefore, the size of the irq_desc array can be reduced by NR_LOCAL_IRQS,
saving (NR_LOCAL_IRQS * L1_CACHE_BYTES) bytes of memory.

Signed-off-by: Mykola Kvach 
Reviewed-by: Michal Orzel 
---
Changes in V2: added the RB tag.
---
 xen/arch/arm/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index b9757d7ad3..03fbb90c6c 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -45,7 +45,7 @@ void irq_end_none(struct irq_desc *irq)
     gic_hw_ops->gic_host_irq_type->end(irq);
 }
 
-static irq_desc_t irq_desc[NR_IRQS];
+static irq_desc_t irq_desc[NR_IRQS - NR_LOCAL_IRQS];
 static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
 
 struct irq_desc *__irq_to_desc(unsigned int irq)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon May 26 09:46:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 09:46:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997342.1378233 (Exim 4.92)
	(envelope-from )
	id 1uJUPb-0003oZ-A4; Mon, 26 May 2025 09:46:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997342.1378233; Mon, 26 May 2025 09:46:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJUPb-0003nm-4X; Mon, 26 May 2025 09:46:27 +0000
Received: by outflank-mailman (input) for mailman id 997342;
 Mon, 26 May 2025 09:46:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJUPa-0003hN-Kj
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 09:46:26 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20625.outbound.protection.outlook.com
 [2a01:111:f403:2412::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4869a737-3a16-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 11:46:24 +0200 (CEST)
Received: from MN2PR13CA0008.namprd13.prod.outlook.com (2603:10b6:208:160::21)
 by PH7PR12MB9101.namprd12.prod.outlook.com (2603:10b6:510:2f9::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Mon, 26 May
 2025 09:46:19 +0000
Received: from BL02EPF0001A105.namprd05.prod.outlook.com
 (2603:10b6:208:160:cafe::17) by MN2PR13CA0008.outlook.office365.com
 (2603:10b6:208:160::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.15 via Frontend Transport; Mon,
 26 May 2025 09:46:18 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A105.mail.protection.outlook.com (10.167.241.137) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 09:46:18 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 26 May
 2025 04:46:16 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4869a737-3a16-11f0-b893-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YwnjWgcs0IiU43Xwx6GaXKIyJcm42vMmljHS0dQXhOqykzWMTsBPLdfhrt/B3MMKudZbp2gRDR8UQ0Zj8H+rs+GWTXcJcOKYTGuRE/+/fTcNT7ayb7bG2S95yktbkLvSL0xA6lw8Ngdve8A2xxsKE58D1qBHmEFtfO6WGIksLQTM5+5PvqQ61Sa0WGvLkQux9r8c5K9BfSALCioj0uZQDpPASA1nO7ORs2raGC10rlPCAsV5rmc+k9gDhcXTrUx9/ycGeyAE1hfhgU9bpWTHvUr2P12mUgEn5FtNhgh3dc02wBadI4nqS2fFR/Sz+BjqELEu+BOx6s1dFMTWtbTQlw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=w2/1tROtTobp55suc1IUtXBV9vnatZqXAC4xP78p8Uo=;
 b=a7BPAM7QuG3ZNkBbSFqJjS4rT+ehjwhgDSrEEMjI+5IhTxWDkSwKg7U2UYT7e/xHoX6elWJ/gqiq6we5oI2FxAkqyMloBuiEUQPjXBLGoTDtff7VOs588cd0GxJ6tPGLY8bLJkW6Mtk4b//zXVvpxXdcKuHanrSqCtB8rcJWmIUM2wE0m0iBcarIo5zlBJ4F2rOka8TyOWmNB+HIEMc6b9xd95eVxIFBhVslAX1MYG/LzGsYflw7lJJP1n2BouJ9nOLN8Rx1BXtyE8OY+vk4WbNEJ32Qv2lBJA/cP2tUmB83q0ub9Z20bIQf1n1nvemXDo8KNzn3LPa6ngVFTK0yqA==
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=w2/1tROtTobp55suc1IUtXBV9vnatZqXAC4xP78p8Uo=;
 b=1iGbNVhx9tlc9SJX9MNunw5XGeRXZpSn2PNOnbLjEI4bMTrrh26ssYQTDNmFSzMZjQFEtNfb2lWJzlNsKSji6FFnco9uQSvhHdSuNQ9lwpdv1BY6f4Jtj3wLaGwxZqrmhbd4kmbVJUbUdg8w3CKM0HSjwojC7hA83XQmb/JHbig=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 01/10] vpci/header: Move emulating cap list logic into new function
Date: Mon, 26 May 2025 17:45:50 +0800
Message-ID: <20250526094559.140423-2-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250526094559.140423-1-Jiqian.Chen@amd.com>
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A105:EE_|PH7PR12MB9101:EE_
X-MS-Office365-Filtering-Correlation-Id: d653b429-c45c-4ab6-d0df-08dd9c3a29f3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cTRtUS9BYmorTDZzbVdkcGlHMFFWbHZyOEUwSEZTVVJJRUpiME5BMDBNWkdU?=
 =?utf-8?B?dDBUQ1IvQWdlYjMrbHZZQk9jSUFFUS9ROXpHWWFUM0dmUDhGTjQ4c1gyeFd1?=
 =?utf-8?B?TjhIZXpGZlVlcHltcjhHbUtRUlF3RFZ4c1Nic0NwTTF6K3RwT1IvbjlkaDky?=
 =?utf-8?B?S1hTNG1tdWY4L2lZSWs4QUxJTmVSb3Vkam9EbHpLblplMW16MVR1S3F2SnhC?=
 =?utf-8?B?SXVSU0pwQUJZMXJsZ1l6WkdXS09NemMrMEJZQkVzb0U4OGpzeHk4d3BzRUFH?=
 =?utf-8?B?M3NTQ3pZdzR3NWMxdVpEN24yQjFWakdxNnkrZmIvUmdaMEY3T3BObWNneUJa?=
 =?utf-8?B?NkVxcm1xRmxEVnlnMnRvcTI3ZlZTTVJvT2o4WE81MERjajhTVGtqb1VPZ01F?=
 =?utf-8?B?Umh0czRvMFhQelVTbjZMZG5Ha25IL29WbVRnd0tHUWdtVGUzME85ejZZUlZY?=
 =?utf-8?B?cHRaSGRUZmlMb0NDQm1UNzF6cDg1MnQwNmVzK25WM09zZzdLRng2TFlCRXls?=
 =?utf-8?B?QTdBZk0xS1Q0dktLSlU0VnVvSW8zdDIrWitCVEI5TXFkMnMrY2l6VzFvM2Rl?=
 =?utf-8?B?Z1JYM1RnWjJZT092YjFWcjNkYmhoMHp1ZEdTRnRPaUlxbU0wTHpkN0Rhb2JJ?=
 =?utf-8?B?UTZIS1N6SUtiZHF3Y2ovWVdtNC8zb3ZnZDN1RWE1aVJxSjdCbU5xVUx3UUdX?=
 =?utf-8?B?OUhBdnlFOHZQR2FhcE9QVWhQRTE5aWVJaW1DV0VHeVpic3dLWmxOTEpXTUVu?=
 =?utf-8?B?bFFXY2NMU1pwQXVPWU94TWFrVlgxTnR6aGkvTVhnaFJHSy9RUzJTMzRSWGJk?=
 =?utf-8?B?bklXQnNOaHNRdEdjVmJ6QjJ4WGJMYWxlNlE0S2E3anRSMEF4UmpOTnV6UjV6?=
 =?utf-8?B?SUtmWlBCR3lrSXQycDNpT3JXUGxqblVDUlFGUUNRRlBDV3VqZE9xTGFROFVm?=
 =?utf-8?B?NlZLZDhEc1RZcTRwcHd2UlQxTjczNnVZUEFGUzA2b2xiblhXQnNxU0QwbEk3?=
 =?utf-8?B?RUt6WGtROEtsYmpDSVhvNlh1SGdBcTRpNmMxSFdMbk5QSVo5RjVrSUVGeHBN?=
 =?utf-8?B?ZVFSblBJSWhNWWoxdUxkZGdOUklYcjM5b3lEdnRGclJXOXJUWTB4K2FGamFT?=
 =?utf-8?B?U2h4VXlnQU4yOFJWbnluYU9FM0lpUWcwcHI4ck5qZUVRZFZ3ZDFHWjREaXlX?=
 =?utf-8?B?ZCtLYXJwUDBpWDV5OUNVOFlLQWhSc2VXejE4WlJPbG1rUVBrUmo0YnpMMGx4?=
 =?utf-8?B?eFp3RXF3ZStIMStjWnp2WC9uNkVmbFRFS1hmQ1N4SWUxeTBHSm1OSkg3NDhU?=
 =?utf-8?B?M3lvNDYvR2tybGNuWVlvWXZEb1d1eExyK0laZlZGZTJzQ3p1cHVCaTRQMWJL?=
 =?utf-8?B?Q20yRU9vYWhqeHpsRVZ3L29mTmFmUjNPY215ZVJVaXBjcU1oeWE4TlI5OCs4?=
 =?utf-8?B?VHZLNEZHZnlBc1F4RmVNUVBqQVVBSTZ1QXBlZk1pYW9hNFpMN0xUd04rdTFm?=
 =?utf-8?B?RHJSMVE1ejliWlFSaTFIWmxQbDE0aGlVMFdKaVlNS1JXR3hhU0FMVVNuNGhT?=
 =?utf-8?B?UUhVT2kxK3NwUlYrWjJ3SzN6L25yL2RSbjBtNFVmMEtXZE1udFYvemxIeC9Z?=
 =?utf-8?B?c0IxK1kyWnFQbTFUVTJRQ1F6QmlkQ2lIV24yamV3WjNJUnhvK0pHalN1bkQ3?=
 =?utf-8?B?QUlmMU1XRUMxcjBMR0dvVGxHbi9Hc1I4dTZKcjdrT3RXaU93N1NjZjdPR0FN?=
 =?utf-8?B?U05QaVRGV2RvYy9YcnlKd0xYblpRUjZwMUF2VSttUHgyQTh3aHdIV1BFaEhk?=
 =?utf-8?B?WWROUzg1QmlpaE5KaWxRSmFTNStIYWRQakFIczVzVkQ4SVFybmF6SXNKMWkw?=
 =?utf-8?B?RW42TUF4dFYvVU5udmlwUnUzczFQbGZJQmkyaVA5UWFJVU8zNGNCeWV3Ym90?=
 =?utf-8?B?MGN2am5zN1pNbVpodUl2Rlhub2VuYXoxWnRFZVJzNzlTQ3FWSDVGYWMxNU1R?=
 =?utf-8?B?bEora2xSSE43R3NxYTNIMEkyM21tY1JzR0RJdEtHZVpldThYU0xYeFhMenlx?=
 =?utf-8?Q?CGjnDg?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 09:46:18.1910
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d653b429-c45c-4ab6-d0df-08dd9c3a29f3
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A105.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9101

No functional changes.
Follow-on changes will benifit from this.

Signed-off-by: Jiqian Chen 
Acked-by: Roger Pau Monné 
---
cc: "Roger Pau Monné" 
---
v4->v5 changes:
No.

v3->v4 changes:
* Add Acked-by of Roger.

v2->v3 changes:
new patch.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/header.c | 138 ++++++++++++++++++++------------------
 1 file changed, 73 insertions(+), 65 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 1f48f2aac64e..0fb3cfa6a376 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -754,6 +754,75 @@ static int bar_add_rangeset(const struct pci_dev *pdev, struct vpci_bar *bar,
     return !bar->mem ? -ENOMEM : 0;
 }
 
+static int vpci_init_capability_list(struct pci_dev *pdev)
+{
+    int rc;
+    bool mask_cap_list = false;
+
+    if ( !is_hardware_domain(pdev->domain) &&
+         pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
+    {
+        /* Only expose capabilities to the guest that vPCI can handle. */
+        unsigned int next, ttl = 48;
+        static const unsigned int supported_caps[] = {
+            PCI_CAP_ID_MSI,
+            PCI_CAP_ID_MSIX,
+        };
+
+        next = pci_find_next_cap_ttl(pdev->sbdf, PCI_CAPABILITY_LIST,
+                                     supported_caps,
+                                     ARRAY_SIZE(supported_caps), &ttl);
+
+        rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
+                               PCI_CAPABILITY_LIST, 1,
+                               (void *)(uintptr_t)next);
+        if ( rc )
+            return rc;
+
+        next &= ~3;
+
+        if ( !next )
+            /*
+             * If we don't have any supported capabilities to expose to the
+             * guest, mask the PCI_STATUS_CAP_LIST bit in the status
+             * register.
+             */
+            mask_cap_list = true;
+
+        while ( next && ttl )
+        {
+            unsigned int pos = next;
+
+            next = pci_find_next_cap_ttl(pdev->sbdf,
+                                         pos + PCI_CAP_LIST_NEXT,
+                                         supported_caps,
+                                         ARRAY_SIZE(supported_caps), &ttl);
+
+            rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
+                                   pos + PCI_CAP_LIST_ID, 1, NULL);
+            if ( rc )
+                return rc;
+
+            rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
+                                   pos + PCI_CAP_LIST_NEXT, 1,
+                                   (void *)(uintptr_t)next);
+            if ( rc )
+                return rc;
+
+            next &= ~3;
+        }
+    }
+
+    /* Utilize rsvdp_mask to hide PCI_STATUS_CAP_LIST from the guest. */
+    return vpci_add_register_mask(pdev->vpci, vpci_hw_read16, vpci_hw_write16,
+                                  PCI_STATUS, 2, NULL,
+                                  PCI_STATUS_RO_MASK &
+                                    ~(mask_cap_list ? PCI_STATUS_CAP_LIST : 0),
+                                  PCI_STATUS_RW1C_MASK,
+                                  mask_cap_list ? PCI_STATUS_CAP_LIST : 0,
+                                  PCI_STATUS_RSVDZ_MASK);
+}
+
 static int cf_check init_header(struct pci_dev *pdev)
 {
     uint16_t cmd;
@@ -762,7 +831,6 @@ static int cf_check init_header(struct pci_dev *pdev)
     struct vpci_header *header = &pdev->vpci->header;
     struct vpci_bar *bars = header->bars;
     int rc;
-    bool mask_cap_list = false;
     bool is_hwdom = is_hardware_domain(pdev->domain);
 
     ASSERT(rw_is_write_locked(&pdev->domain->pci_lock));
@@ -803,61 +871,12 @@ static int cf_check init_header(struct pci_dev *pdev)
     if ( rc )
         return rc;
 
+    rc = vpci_init_capability_list(pdev);
+    if ( rc )
+        return rc;
+
     if ( !is_hwdom )
     {
-        if ( pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
-        {
-            /* Only expose capabilities to the guest that vPCI can handle. */
-            unsigned int next, ttl = 48;
-            static const unsigned int supported_caps[] = {
-                PCI_CAP_ID_MSI,
-                PCI_CAP_ID_MSIX,
-            };
-
-            next = pci_find_next_cap_ttl(pdev->sbdf, PCI_CAPABILITY_LIST,
-                                         supported_caps,
-                                         ARRAY_SIZE(supported_caps), &ttl);
-
-            rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
-                                   PCI_CAPABILITY_LIST, 1,
-                                   (void *)(uintptr_t)next);
-            if ( rc )
-                return rc;
-
-            next &= ~3;
-
-            if ( !next )
-                /*
-                 * If we don't have any supported capabilities to expose to the
-                 * guest, mask the PCI_STATUS_CAP_LIST bit in the status
-                 * register.
-                 */
-                mask_cap_list = true;
-
-            while ( next && ttl )
-            {
-                unsigned int pos = next;
-
-                next = pci_find_next_cap_ttl(pdev->sbdf,
-                                             pos + PCI_CAP_LIST_NEXT,
-                                             supported_caps,
-                                             ARRAY_SIZE(supported_caps), &ttl);
-
-                rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
-                                       pos + PCI_CAP_LIST_ID, 1, NULL);
-                if ( rc )
-                    return rc;
-
-                rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
-                                       pos + PCI_CAP_LIST_NEXT, 1,
-                                       (void *)(uintptr_t)next);
-                if ( rc )
-                    return rc;
-
-                next &= ~3;
-            }
-        }
-
         /* Extended capabilities read as zero, write ignore */
         rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL, 0x100, 4,
                                (void *)0);
@@ -865,17 +884,6 @@ static int cf_check init_header(struct pci_dev *pdev)
             return rc;
     }
 
-    /* Utilize rsvdp_mask to hide PCI_STATUS_CAP_LIST from the guest. */
-    rc = vpci_add_register_mask(pdev->vpci, vpci_hw_read16, vpci_hw_write16,
-                                PCI_STATUS, 2, NULL,
-                                PCI_STATUS_RO_MASK &
-                                    ~(mask_cap_list ? PCI_STATUS_CAP_LIST : 0),
-                                PCI_STATUS_RW1C_MASK,
-                                mask_cap_list ? PCI_STATUS_CAP_LIST : 0,
-                                PCI_STATUS_RSVDZ_MASK);
-    if ( rc )
-        return rc;
-
     if ( pdev->ignore_bars )
         return 0;
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon May 26 09:46:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 09:46:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997344.1378256 (Exim 4.92)
	(envelope-from )
	id 1uJUPe-0004OT-Rm; Mon, 26 May 2025 09:46:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997344.1378256; Mon, 26 May 2025 09: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 1uJUPe-0004OM-O5; Mon, 26 May 2025 09:46:30 +0000
Received: by outflank-mailman (input) for mailman id 997344;
 Mon, 26 May 2025 09:46:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJUPd-0003hN-Nf
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 09:46:29 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2405::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4ae3034e-3a16-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 11:46:28 +0200 (CEST)
Received: from MN0P222CA0021.NAMP222.PROD.OUTLOOK.COM (2603:10b6:208:531::28)
 by PH0PR12MB7790.namprd12.prod.outlook.com (2603:10b6:510:289::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.20; Mon, 26 May
 2025 09:46:21 +0000
Received: from BL02EPF0001A101.namprd05.prod.outlook.com
 (2603:10b6:208:531:cafe::aa) by MN0P222CA0021.outlook.office365.com
 (2603:10b6:208:531::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Mon,
 26 May 2025 09:46:21 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A101.mail.protection.outlook.com (10.167.241.132) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 09:46:21 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 26 May
 2025 04:46: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" 
X-Inumbo-ID: 4ae3034e-3a16-11f0-b893-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lx6W9cl9NxFVafl8qTeA616ClSSeFeb92H8/IILu1F8ZAohB4AuOrQbUTZXNaj21+Jb3RUuy0mjIFb1rTr+W0JRcgu3ZQoEJqdPC40J2l3OYz3WtgaM9PE+gMY4bzyezCVCiuc4hRiabr0J5CtnthzcQtBuNPAeVlqhDphgpPePuwL6dTHtRlk5K9mgUTSTF8vUHJlaZ7rEoCOSgQpdaWTTgFIPvKrGWiP7Is7sQoILtZg0hQ6ylRVlV3K9n1XIZHqOWFUntnW+VBA2qIoB78XxvXJHpNwJceeqs6t98z345yAqdfEYkkVyKC0WeDsNpUHJgeGgCbEVfXFmarvPnEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KgWjqDD6QFXmhNcGRKv57wsy+lqnZUw9leCF2c/u6zQ=;
 b=dZIPHM89afK0nXY8JmNRrBMCIsAPXFVmj/SOYVERzB7sIigkP/WnFICmszTLEXO/qK3HHgl1fTx2cn0te9OIa5xMqMfFQviIAq2fqJefIbaZLF4ldgAh7KVCSrXseBwgrvvPJnjxIATIqdIcZDaygsbzbqCDgrUSLiECijO3YTkAZN/P05+0/IqxmqYF4mKFitG5Ss+wSQNF/+Ha6rxSa3/5zP+UpHAuN9Z9EjX1AuL9LQQ6bgWPElwqlSE3ExprsXhaGdqH7ikdTtCBJ4+oFLGYXks+LHqNGczO4SBVlsO5MmhVee+iSFyzUyTQ4sPVhEoZMoAQwAKglsznalKLcQ==
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=KgWjqDD6QFXmhNcGRKv57wsy+lqnZUw9leCF2c/u6zQ=;
 b=Xu/YN7pKpzc6waIL9u+D3+WxzubgRKyA3PTeVA2h12uS6zq2Wra713eLIkXtydoiM999Wmf+mfACzmNIjaDVx46SpJrpDtUtf1OKjdWZEEjChfdHZWkFv2RV4CPZa8g3+CIWfbOFGe9ssNPGyBgJcag+WHGjW7hbT9TeAYa2fEw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 03/10] vpci/header: Emulate extended capability list for dom0
Date: Mon, 26 May 2025 17:45:52 +0800
Message-ID: <20250526094559.140423-4-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250526094559.140423-1-Jiqian.Chen@amd.com>
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A101:EE_|PH0PR12MB7790:EE_
X-MS-Office365-Filtering-Correlation-Id: 3cbac272-2ad3-45d2-ba38-08dd9c3a2bd9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VVdGTHVFaG5JbEliK1NxZndBZ1pZeGIxQVpISWlDdDJxNTNHU3lOUU0xMVFr?=
 =?utf-8?B?WS95M2FLRVZVM2ZvNmlyYy93dHg3TDJnYzhZRXNkMmxCOHJITUI3OEd0ODFR?=
 =?utf-8?B?ZnJpbWxVWDcwd3NVYmdCcGdpd0l0RGM0TnFDZmNkMG1yYTFyMURQaFJITVRV?=
 =?utf-8?B?MEx3ckNJcGliMWZKQ0xpZitIYVMza2ozS2FIUlZTYVdqcVpCSk82Z1ZmUXFH?=
 =?utf-8?B?TllEa2x0NWc1VllyRGlQcUk2Z0RKNGtZbVQ1U1FOUW9vS0hjTDhHUW41bXNM?=
 =?utf-8?B?SUJSaGlvQUlkWnNLQXVIQW1xSVdMZnNONW9TVlVxTUU3YkJmcGdwMlBDUnFG?=
 =?utf-8?B?aVQvWDd0UVExeEpXcnA4S1N5OWRpanhJaWpwNUgxQnNhY2s0MEhOUWZwS0p0?=
 =?utf-8?B?V01XM083NlhUMWtQT2phN3lyR0Y3RjBmbFJMaVFqcWlKK2xtazNNOTJWYVQy?=
 =?utf-8?B?T1poeDlkd2cyQU41QzdjdVdXQ2dGeTJmZENqOGFQcUdPZmI0ZzNBZVN1eVh2?=
 =?utf-8?B?MVo0dGdlRms5UGE4N0VCK3RnRzM5NUlNRi9xWUVyVGxDbVBrNEJHYmJ1RDBw?=
 =?utf-8?B?R0wxZGNJSXdsczg1eksvOXBxdklERXJUU1dzZ012Z0svWGtVbHNXNDhNeDVa?=
 =?utf-8?B?SzNicVlncjcwOFNRZVdONFFmSDV0d0RIOU5CaVdreXlCYTJ1M3BPOVFQdXRK?=
 =?utf-8?B?MWJmZkxlUFpiZ2RuN3lZRXVrRmY1UFR0Ty9kaTVtVlN6c29PRGYxakpxWXYz?=
 =?utf-8?B?YndvcityNmt0eGd5ck9zaVlGb0tBZGpESVNtWmJaN3k4b2lVVGJWOWhrRHE4?=
 =?utf-8?B?bjQ1azZpTkNZN0RzZWduMDlxRGJSSVpsSy85Mk5KdWUwb1dlY1VTUXdyQWtl?=
 =?utf-8?B?anBVWm5zTnJVd0E4OGp5ak5aRDFOZnF3R1VuT3VwaU1yVTBBSWtlaHZrckVt?=
 =?utf-8?B?Y05ubThGY0ZCOVFkTGs0VjBPeDRhS0o5anRSbENnRnhDRDVvMXlRVnZUQnoz?=
 =?utf-8?B?ZkVIK29yS1VKeno2QUdOVzg3Rm5QM1hqZ2d5MEtzQ1BhS0xlb2NkYm9xQlZG?=
 =?utf-8?B?MHlJT04walBGTGFwcXZCYjI5SUVRM2tuVzFMbjZXZVBSUVcyOUE0dXlhYWVE?=
 =?utf-8?B?cjVYUUY4UjRqM1pnMHJJcmxsdXVKRDRlTlFvckdyRWRuMU5Wd3pNR1d1VEt1?=
 =?utf-8?B?MlNrb20vTyszaFN0aXFiWC9tK2U4UGEwdXcyOFZkemN2N28zU0hvQkwzQ0RQ?=
 =?utf-8?B?Y3NsSjloTEpXNUNqSWRGNXVjUCtWR1RZcFpuSzFrcG5aeFM0ZDVlTGJKc2ND?=
 =?utf-8?B?cHp3T2JndUR0TW9aNXNpVi9XYXN1NzBGTHIrK0lpSmg5Rk85a2ZQQkdDVzM5?=
 =?utf-8?B?dE81a0pYc2ZadVdGVjZneXRYUGtxYmE4OFFnQ3Q3VVQ1MHRlNGtmM202Rmk0?=
 =?utf-8?B?dWQwdGY3Q2tOMVZtR2hHOExFZmlteVpQd290a3E1eEM2c05Veitkb0FQNmdD?=
 =?utf-8?B?ZCtmeXV1SFByKzFKdk52VDg5b0grVUFxKzh5QVpvTkVIcytFZmxmb0xRd1RU?=
 =?utf-8?B?R0EzaDVrWkp0VWVjQytWSTd5bm95bjRBL3cyaHBiOVNMc05YelRMTHVkR0Ji?=
 =?utf-8?B?VEloL0tXRUsyZVdiSis3SEg2RmJhbXF6L0VYNGgrb2VyeCtRVVBoaW5MN3Zu?=
 =?utf-8?B?SHVKWHZOSHAvTDZyOHJOY3Q1VzlLbGxmMWhoTW1xRUJWS0R1L043WTZ5QmZV?=
 =?utf-8?B?ZTVIbGs1bFFTM2p4VlYzK3BTK3lFVG1sVFpJazkzbWxLTXp2dUczZzR2Ymh2?=
 =?utf-8?B?ankzVkVPeXliMDVYOG5hYW1vT2RrYXA1ck03dG9NU1M1NStrRngzM3k5TTQ5?=
 =?utf-8?B?ZW9rS2hna2FMOVkvbkNmeUtyWTVkaFZrL1VQY3hrYTVtdlZwSWxLNWYvbHFT?=
 =?utf-8?B?THJ1VytsYW5XVnlOVFJEN0xLM0FjaUFIZkc3OGN0eDdlcGlIR2dTamdESE4z?=
 =?utf-8?B?R1BMQzBQTTRrYWM5bVFtODVmVzNWT3R3MGEwWHU4YktPdS9RaUE2aDd2SUJv?=
 =?utf-8?Q?0C5i3O?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 09:46:21.3753
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3cbac272-2ad3-45d2-ba38-08dd9c3a2bd9
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A101.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7790

Add a new function to emulate extended capability list for dom0,
and call it in init_header(). So that it will be easy to hide a
extended capability whose initialization fails.

As for the extended capability list of domU, just move the logic
into above function and keep hiding it for domU.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v4->v5 changes:
* Add check: if capability list of hardware has a overlap, print warning and return 0.

v3->v4 changes:
* Add check "if ( !header )   return 0;" to avoid adding handler for
  device that has no extended capabilities.

v2->v3 changes:
* In vpci_init_ext_capability_list(), when domain is domU, directly return after adding a handler(hiding all extended capability for domU).
* In vpci_init_ext_capability_list(), change condition to be "while ( pos >= 0x100U && ttl-- )" instead of "while ( pos && ttl-- )".
* Add new function vpci_hw_write32, and pass it to extended capability handler for dom0.

v1->v2 changes:
new patch

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/header.c | 47 ++++++++++++++++++++++++++++++++-------
 xen/drivers/vpci/vpci.c   |  6 +++++
 xen/include/xen/vpci.h    |  2 ++
 3 files changed, 47 insertions(+), 8 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index d26cbba08ee1..4b2f761c9c24 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -836,6 +836,42 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
                                   PCI_STATUS_RSVDZ_MASK);
 }
 
+static int vpci_init_ext_capability_list(struct pci_dev *pdev)
+{
+    unsigned int pos = PCI_CFG_SPACE_SIZE, ttl = 480;
+
+    if ( !is_hardware_domain(pdev->domain) )
+        /* Extended capabilities read as zero, write ignore for guest */
+        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
+                                 pos, 4, (void *)0);
+
+    while ( pos >= PCI_CFG_SPACE_SIZE && ttl-- )
+    {
+        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
+        int rc;
+
+        if ( !header )
+            return 0;
+
+        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
+                               pos, 4, (void *)(uintptr_t)header);
+        if ( rc == -EEXIST )
+        {
+            printk(XENLOG_WARNING
+                   "%pd %pp: overlap in extended cap list, offset %#x\n",
+                   pdev->domain, &pdev->sbdf, pos);
+            return 0;
+        }
+
+        if ( rc )
+            return rc;
+
+        pos = PCI_EXT_CAP_NEXT(header);
+    }
+
+    return 0;
+}
+
 static int cf_check init_header(struct pci_dev *pdev)
 {
     uint16_t cmd;
@@ -888,14 +924,9 @@ static int cf_check init_header(struct pci_dev *pdev)
     if ( rc )
         return rc;
 
-    if ( !is_hwdom )
-    {
-        /* Extended capabilities read as zero, write ignore */
-        rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL, 0x100, 4,
-                               (void *)0);
-        if ( rc )
-            return rc;
-    }
+    rc = vpci_init_ext_capability_list(pdev);
+    if ( rc )
+        return rc;
 
     if ( pdev->ignore_bars )
         return 0;
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 09988f04c27c..8474c0e3b995 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -267,6 +267,12 @@ void cf_check vpci_hw_write16(
     pci_conf_write16(pdev->sbdf, reg, val);
 }
 
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
+{
+    pci_conf_write32(pdev->sbdf, reg, val);
+}
+
 int vpci_add_register_mask(struct vpci *vpci, vpci_read_t *read_handler,
                            vpci_write_t *write_handler, unsigned int offset,
                            unsigned int size, void *data, uint32_t ro_mask,
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index fc8d5b470b0b..61d16cc8b897 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -80,6 +80,8 @@ void cf_check vpci_hw_write8(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 void cf_check vpci_hw_write16(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 
 /*
  * Check for pending vPCI operations on this vcpu. Returns true if the vcpu
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon May 26 09:46:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 09:46:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997341.1378226 (Exim 4.92)
	(envelope-from )
	id 1uJUPa-0003hZ-TB; Mon, 26 May 2025 09:46:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997341.1378226; Mon, 26 May 2025 09: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 1uJUPa-0003hO-Oh; Mon, 26 May 2025 09:46:26 +0000
Received: by outflank-mailman (input) for mailman id 997341;
 Mon, 26 May 2025 09:46:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJUPY-0003hH-Qo
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 09:46:24 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20626.outbound.protection.outlook.com
 [2a01:111:f403:2417::626])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 48acaf7d-3a16-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 11:46:23 +0200 (CEST)
Received: from BL1PR13CA0184.namprd13.prod.outlook.com (2603:10b6:208:2be::9)
 by BL3PR12MB9051.namprd12.prod.outlook.com (2603:10b6:208:3ba::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Mon, 26 May
 2025 09:46:17 +0000
Received: from BL02EPF0001A107.namprd05.prod.outlook.com
 (2603:10b6:208:2be:cafe::f8) by BL1PR13CA0184.outlook.office365.com
 (2603:10b6:208:2be::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.16 via Frontend Transport; Mon,
 26 May 2025 09:46:17 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A107.mail.protection.outlook.com (10.167.241.136) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 09:46:16 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 26 May
 2025 04:46: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" 
X-Inumbo-ID: 48acaf7d-3a16-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=slYlmZfcpqhgJj3EDDX1mRY/r/1BdT3cAYgrmbzjuLDqqKwCyXtIEr7hDg/35ayOK1X2oigpxPMbk05uc8dJzL2qpL/apLFyUv3suAFlT1KuzXC+m94iKeajwksz96seG6twZ94D8gm+lPbQAmyTUrXaXNJsLiKntXLNRAJg+zd7yMLJfDbe0/GQfMA5PyWqzMuKPEU93AkMhMsaJX0fPBxsF5XyC+lAlyXi1ywcMHZRpVuBz+1t7IfgkMN+7Wf1f+XBclj1tGaf85buqSwrd3AisYP7LQz5Wk20gcLZfdQIetM+eVv64UDpWIoNVuNsDrOUbOf+Ner4zDxFzFHv3A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dgCGQ36mKt8+nLsWda08/hpIxoIRAEZAIVomHicqwAM=;
 b=imWSnaZT7eCnoEnM+igtfTZZ9H6GbIJdlrnkirW2bB4yO1mICu+NbcLEDdvF3DWTro0ewV7OISWNolclpO7qLoJP7viXoYoNML+TTzPubfToQmGAbhyUimD/hKcgLvvcpN4agx/N6ExgAUhJI+D6L1RX83J2QwdOqfZ0eEynZoJ/K6D1+bbHLmEY33BzYNgDPDwfumHCfoshhsJsZ12I4neprifZ1jB3Oa2oAdwtA+9oEH9hhPOk7fM8SrRn2BbvbwgFsu1U7ZL0qFX/iFSiBGh5JXEVt0r+151OvE9GSWVR9TBwWKK9WiwuMmzb0eyOJZZsJeaX5/i+oKpJbIWp3A==
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=dgCGQ36mKt8+nLsWda08/hpIxoIRAEZAIVomHicqwAM=;
 b=2QsxPgPv7H7Gh6gQ/3BohOSoT+Uh+hS7xwxwfLoaMikUUwCUlBmhgW1f8pAes8fq1MQLNge6CtxqC4bdEfLXfs4Fscs5UoazAE6owjyojOouV/CE0zTJ0d1wDGJR3HPLXG/r2UzYX3Gb/asu+W6XnXPCCIP52nVPNFoODD7JIvc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen , "Andrew
 Cooper" , Anthony PERARD
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" 
Subject: [PATCH v5 00/10] Support hiding capability when its initialization fails
Date: Mon, 26 May 2025 17:45:49 +0800
Message-ID: <20250526094559.140423-1-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A107:EE_|BL3PR12MB9051:EE_
X-MS-Office365-Filtering-Correlation-Id: 61e8ce00-9f75-484a-b5e3-08dd9c3a28f9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UUhCYzhzTVE5S0dNS0xjM3JEbk5kaUt0a1JVSHRrcGVNY1lUbVFLdStoT1Ar?=
 =?utf-8?B?UldXTWJpY0QrNmJ1ZmUvQmlUc084M2FBMUl5WEF2ZVZMdHdGUHVxdXN6SmY3?=
 =?utf-8?B?clNhK0wzN0tGdVBraU1mMjZKSy92aTh4dit3enNabnc0ME5IbXhpcDRTYk8z?=
 =?utf-8?B?OEVwK2ZQZVFwTHkzbzhkS2U2d0NzOVdOSDJNdmtDS1pKYlZBcm0xVUdaK2t2?=
 =?utf-8?B?TE5wUFZrOUJhNDdEZWxVbWQ4U2drZEQ1YTBJLyswSEIxTXY5OUhHaTFTMXR2?=
 =?utf-8?B?WGFjeXpHM1l3bHdMNXJlUlhiRW5RT1JMR0FkZDI1RGxHaFZmQ0hKYjhnVjBu?=
 =?utf-8?B?N1prSzlDbVlhUlpnSG9ZdDBkVkJoOUlHYkpTczVyN3VlZ1FpSlUvWDg0a1lM?=
 =?utf-8?B?VVdlSWZ6WStCUVNYdW5uai93bThkQVNOR1NNQlI0SlhwUWVFYythMW9NZVYr?=
 =?utf-8?B?bWtzOFFwSlNIK1M0bmJPbk1ReWlacXJseURoVDRkNm9UNGo3N1dDUnFNQTZC?=
 =?utf-8?B?U1ZiaHBIbk51M1lSL1NYZDVycWYrdVZ5amh5YUR0QWkvMk5vUnVWV1p2d3N1?=
 =?utf-8?B?U3lnRXUxbndWRmE3RWszV203YWdHalJacDlIV2w5eThVRWtnbmlxVUR5UG01?=
 =?utf-8?B?c3ZsQkRPUGg1Wm5YbUtlbkVPbnN3a29wVmJRMlVTUEtraFcwZndMcE4rRmJk?=
 =?utf-8?B?MFlWdW53ZHNLbFk5TnJIZmJaZTlIL3lha2EycXFkcFBWTWpwdVBkWjd5dmFT?=
 =?utf-8?B?bmZKOGMrYXc4enFNU0RFNkd1NW1FMEY2RFVxL3FkWHhIaHJDZThsQStBUGJz?=
 =?utf-8?B?UHdNT290S3RpSnR4N0lZbVRueldEK3BURzJueXpiOStJWktXaVM4NlhPSFFo?=
 =?utf-8?B?Y0xSaGZWVmM4cnFnNS9yNERucHQ1SmRndUNpRm5SZFNmMkxWNkRsY242MFh4?=
 =?utf-8?B?aGNtcUd4dS9UbGd4VC9TKys2S21Vc01EazVYbDU5LzdKVXg3bldSTlZxSndw?=
 =?utf-8?B?a0tkaEZaOE1Hb0M3b04zWjNMWk83VGI4SWZCcWZiRWlVMzF4S1BkTmFGRGFF?=
 =?utf-8?B?L1RmSEhmMGNqdC9KRkFjejlnWXR6SGZVK2M2allwbU53TkM3OThPY0JlMHNF?=
 =?utf-8?B?NjFIR1V6a0lUL0F6clVYZnpTc053dTllcHlRWWFxT1V4TUxGczBCVWl0cTc0?=
 =?utf-8?B?SGNjSGx5a2VSYjJsK3JFRHdBMkU5cHRBb0o4TzdUNjlsTXVUam1rclB1bTly?=
 =?utf-8?B?SDE1Z0kzcXQ4R1M2Ym85aC9UU3E4azFQWW1VTzgxM3V6bHB0cXFmNnB0cW1h?=
 =?utf-8?B?QkxnVGU3Ym15NkxHN2ZSNGpMTEdQditBUFBXUHZ6VUdyeDdOOGk2R2NsdnAx?=
 =?utf-8?B?QW9VZ2E5aWZNNk5zRHhDLzVoVlV5ZkZmYi9BTkxZMXhHelQ2QTJEU1p4OVJy?=
 =?utf-8?B?N3lJR2F4OERXcXZCeDAzSS8wNkJBbStCN3NkVlNuZkhmMDVyNDM0akdlTjhH?=
 =?utf-8?B?VHovMFdCVXNzd2UyVnNMS2oyaDVMR1FsVTFobVN0bVJwR1UzRVZnUTFQc2x3?=
 =?utf-8?B?V0FYRUViY1JNK3dMeWdhRWZKNTdZWjhmUmxRQndxd0pSWkljcEl6ZThlVHl4?=
 =?utf-8?B?Q3NQZFhyekE0WUM1ZTJVeEJpS2g0K1pWMDJ3L3crZDlnL0lOajA0dmhqR1Vr?=
 =?utf-8?B?RGYxZjZ6TEtReG9YNjF4QkNZUWE3b3FvdmVZdlJXNXFQQ3VTWDBQSi9uaE1G?=
 =?utf-8?B?V2plNUNlUUN2VUVkQWg4MzNQRXVBOFJuL2RTTm84Mi9OekMzUUh0WmcxdHZ5?=
 =?utf-8?B?QjMweDBUc0tkZnMxaVNFUExkTVBMcTZSa1BoNzRKSk1VYjFBYlB5Wmsrenpx?=
 =?utf-8?B?bGlxR1JkT2YxYk9JU0V1WkRpNmx4VlhSTFN4L08yMkxDaGxjU1VFdmRWWlVE?=
 =?utf-8?B?WXFqUU5iTzFBTHNlSHlOTDZhdWlUQ1p1ZWVJT3YrT1BaYXM2cW40cmRkRkdZ?=
 =?utf-8?B?eWRZTHM1THZpWWFWOU9VS2wvSGZCeHRLN3BhSnVSY0xpZjlzRDFTR2JnU21R?=
 =?utf-8?Q?dygwZK?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 09:46:16.5537
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 61e8ce00-9f75-484a-b5e3-08dd9c3a28f9
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A107.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB9051

Hi,

This series is to
emulate legacy and extended capability list for dom0, including patch #1, #2, #3.
hide legacy and extended capability when its initialization fails, including patch #4, #5, #6.
remove all related registers and other resources when initializing capability fails, including patch #7, #8, #9, #10.

Best regards,
Jiqian Chen.
---
cc: Andrew Cooper 
cc: Anthony PERARD 
cc: Michal Orzel 
cc: Jan Beulich 
cc: Julien Grall 
cc: "Roger Pau Monné" 
cc: Stefano Stabellini 
---
Jiqian Chen (10):
  vpci/header: Move emulating cap list logic into new function
  vpci/header: Emulate legacy capability list for dom0
  vpci/header: Emulate extended capability list for dom0
  vpci: Refactor REGISTER_VPCI_INIT
  vpci: Hide legacy capability when it fails to initialize
  vpci: Hide extended capability when it fails to initialize
  vpci: Refactor vpci_remove_register to remove matched registers
  vpci/rebar: Free Rebar resources when init_rebar() fails
  vpci/msi: Free MSI resources when init_msi() fails
  vpci/msix: Free MSIX resources when init_msix() fails

 tools/tests/vpci/main.c    |   4 +-
 xen/drivers/vpci/header.c  | 195 +++++++++++++++---------
 xen/drivers/vpci/msi.c     |  29 +++-
 xen/drivers/vpci/msix.c    |  35 ++++-
 xen/drivers/vpci/rebar.c   |  35 +++--
 xen/drivers/vpci/vpci.c    | 293 +++++++++++++++++++++++++++++++++----
 xen/include/xen/pci_regs.h |   5 +-
 xen/include/xen/vpci.h     |  38 +++--
 xen/include/xen/xen.lds.h  |   2 +-
 9 files changed, 510 insertions(+), 126 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon May 26 09:46:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 09:46:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997343.1378246 (Exim 4.92)
	(envelope-from )
	id 1uJUPc-000492-EZ; Mon, 26 May 2025 09:46:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997343.1378246; Mon, 26 May 2025 09:46: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 1uJUPc-00048v-BO; Mon, 26 May 2025 09:46:28 +0000
Received: by outflank-mailman (input) for mailman id 997343;
 Mon, 26 May 2025 09:46:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJUPb-0003hN-9K
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 09:46:27 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20624.outbound.protection.outlook.com
 [2a01:111:f403:200a::624])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 492600b0-3a16-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 11:46:25 +0200 (CEST)
Received: from MN2PR15CA0043.namprd15.prod.outlook.com (2603:10b6:208:237::12)
 by DS0PR12MB7993.namprd12.prod.outlook.com (2603:10b6:8:14b::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Mon, 26 May
 2025 09:46:20 +0000
Received: from BL02EPF0001A108.namprd05.prod.outlook.com
 (2603:10b6:208:237:cafe::cf) by MN2PR15CA0043.outlook.office365.com
 (2603:10b6:208:237::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Mon,
 26 May 2025 09:46:20 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A108.mail.protection.outlook.com (10.167.241.138) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 09:46:19 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 26 May
 2025 04:46: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" 
X-Inumbo-ID: 492600b0-3a16-11f0-b893-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lW2van0nJzyJr+30QYBsW2ppzr1OfdkFN+PnI92ub2b3MO2Rdo6vbMINEKV8ayCI+yh77ZtitmMD/0Prc8EIEQIG3yVxs4uRL23Mw8AwUljVPSgI+sqMxC5LYPnlRl2NaoLJcUFBamsKWpDQqZztowePF2W7iBNhUh6d+QeBnpvi+L6QO9wdRGJ/y5HKuGhoWvJCrhdqYE3clevKxahaxzSXBRiNEaHiTmg+Nwuo1mTee6zYBJsoUVpqDr8zDinTnRdAR7uEcyyK07wWNN6BkzFkLBg4fAXpKFlzFz6QW+bX4vxg5+JIAbZ1oNA3egxsoTHEm9i8ABc76U2XrU3bFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GuyCxUQ97UVFVG8LWs3GMa6eIbl8t+L0KXIZRR7uPyI=;
 b=IUy10aRIfGX1fsFNSGR3GqmZenhqVddvsx4F2i84JCNN92sKkfov+Kh5NmboLJnL69dSFzEIZRjcjI5bQzgLn13AFmW4ysU7mQLCaPGJojRUQIZo3updO/PUr8oj/VpgnSByZFl7QVod8uqRhZOvhHpki9dwZEmOJweJpRNNecAvF9lOSI7ldPpaXS47HVo7SmWbw2I1yx4cXs6DV7J7YCefA8Ky4sHLhxS2dgu1YV0ZWKgN1LiBK09iSrDcOUXmZEAffTJMsVoULbI676HI7VcqN6LEIpT15pdmOvXTOA12BeE84wrvS+tkzu78aDhUjDBPnZ7t9tl5CJmU8YNZvA==
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=GuyCxUQ97UVFVG8LWs3GMa6eIbl8t+L0KXIZRR7uPyI=;
 b=xyh9NU1ml5gug9mbuxLeklfCpugp+E9hY4nCKuqmZX3bcAmuecyjA9o9fIACGh+6j/zaNcJkE7G/wKoX/sP4OpHa4DIwd2EXUsy5BxBE5L+Clybk2TmvcoBAA20inlpurIYdhjytEAGhSaA5xjidG1kmmXMKE4cYgkuXOrjZNAY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 02/10] vpci/header: Emulate legacy capability list for dom0
Date: Mon, 26 May 2025 17:45:51 +0800
Message-ID: <20250526094559.140423-3-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250526094559.140423-1-Jiqian.Chen@amd.com>
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A108:EE_|DS0PR12MB7993:EE_
X-MS-Office365-Filtering-Correlation-Id: ba72d00d-6046-4b9e-64c2-08dd9c3a2ae5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OU5semlvVFBlZmFGOVp2bWlTMkd6VHVMZjYxamM1MXJTdXNLQytBaE9vRWVt?=
 =?utf-8?B?dDc5Z1RqMVZNd3pYWnN3cFR1a1ljMHBKMXlBMjlwR25pd3haZFZVK0JraUp4?=
 =?utf-8?B?akxTM3IxZGdKZG92Tmh4LzV1NkxKRWdjVGNjd1lrbGNpMXRBUWxMVFFrMFh2?=
 =?utf-8?B?bjlReGlwSnJJajYzTHE0QmtvU2NmZkw2NHp3S3U0b1hPYkZTamVLR2dKbzIr?=
 =?utf-8?B?VS9QMlFmamlXbVRkWm92LzEvSEFzWjJyTmJWTk1QcVlSTmF6M3ZMZm1qWFgz?=
 =?utf-8?B?ZE5tK2JCV242SjZWNVFBQlFFRUJVa09DWk5ybS9iejdIWjBMRkorU3h2bGRx?=
 =?utf-8?B?Rmg4OGFUTFpTTVZpZUdlMlkrS2Jlb3FKRHh5QldmZnhYa1dmd2M3NVA0N01S?=
 =?utf-8?B?VHgva3ZxVy8vMnpzT3BxMkQ4emltTXNpNjE0UDdrcG9sRW9FbWtXTUZacUc5?=
 =?utf-8?B?bGZnL044ODdDTjlPUEZCQS8xOXNqemgrNlZieDBTYWFoRGZsQU1POFVHUHlh?=
 =?utf-8?B?bUNNL2huY0FBWXJDUkNvVnlESWVSUWtDTnVKUzQ0dEJlVEdQYXQ2dHJrV0ht?=
 =?utf-8?B?MVkxWjZVWk1Sc3I3czFwSXpweW9JaWQ2QjhPUWJVMEZQeDV5YVNydEF2aVRx?=
 =?utf-8?B?cElGZnVoM3NORTdOZ2RhMHdmR0dQQXRnam1TRWZKY2xCTXJvZGN6NGpEYkha?=
 =?utf-8?B?RG04b2NtMDU2RS9KYnlkNEJySHRleHh5eTV1OWxuVlNKb0F5QXo0UmlEY3JU?=
 =?utf-8?B?UUU1OS81SmdJNVl0aTEzVjV1RmZXM0tvQWV2YjZ5TVhhelprRHBaRFpNMGFB?=
 =?utf-8?B?UDZMakFFV1VLMGRhNHNqaXEyODhxZE5wS09mOUZYcWtxNWw3MHhVNTNlV3M3?=
 =?utf-8?B?U2RBSjFKMUpTYWVTc0J6N2wybTNQSThMMEU2OXpXTGFCRkpMa2JBUTZ3a0h1?=
 =?utf-8?B?Q3JNaFMrL2xTblNKUHVsQmZuMlUxWmptVE5EV2pKM01HTGJuUUFCY0U1YjJl?=
 =?utf-8?B?QUFRQWxMVzBjZStCNzBWWkZocGZLbmN5VjVBUUpBQWZsY0NiY1d2ZVhVNk16?=
 =?utf-8?B?SXJMeUVOa0VDNE1OSFplcjYwaHo1bjl3STRHREFZSXpOV1c0eE5JNSs4YkR5?=
 =?utf-8?B?Zjl5eWdpaC9VemU4WjViSmhyclVZb2ViZ0NpMW1XaGlQTldPQ3VHZ1dqMGpK?=
 =?utf-8?B?ZDBkVDFqb3F6QXE3Rk93UXlQSUUwNkozcW1CbjA3dTFwd2JPcUVNbC9TTE14?=
 =?utf-8?B?OXJHeTdYVjVzNGdBZGtmRC9xWXF4VWRhZERXUjlqUjhxYmFmUzFYZVQ3OG9R?=
 =?utf-8?B?V2hWNk4rR0cwcjJtWHM5YW4xQnIwWTlzY2NyYkdTMEgxYi9UaS9qWTN2M2pQ?=
 =?utf-8?B?bkxBczdiWGd2UDNQUEZQVG5yVC9WTGtkRzNuamc3SGFPK3NPT1RvdEZjRzZj?=
 =?utf-8?B?Qmd6b0pTdFBya0gycmNtRnNvaEtGOWxsY25idkJlRFRuZjZ5aE01aGZWTXdv?=
 =?utf-8?B?dTBaQ2ovOFZ1SVdQSkFUMlNjNnBPQnJsaEUySVNHNUFjTEo1aThWVVdxZ2pQ?=
 =?utf-8?B?Zk44UFhOWWFwT1NxaGtqUm9zY0FhSWdsRVV6cWc1T0ZNdzRBMk82QnZIY29V?=
 =?utf-8?B?YjhDUWl4bFZIY1c3Zk0zbjNjbXFRbVc5N1pFS25vTndxbkJGYlc1amdibnNE?=
 =?utf-8?B?TGpuT0liZkZWalhUVktwampxM2kwTXdkQlZTWlR6ZmRxVm5aNWY4VjlmNjNC?=
 =?utf-8?B?b2IrTVl3c3k3VnlNOFdFSmdhZzYzcVlXK3AzR1BXRW5lNVVKRTFwcjFrN1R2?=
 =?utf-8?B?NTdWNnVuVzJkWmFleGdjZEsvelRwTjhYeDZzVmV4eDhWbEZUOEVpUVRsM0Nl?=
 =?utf-8?B?QTd1eWNWVXV4My9uRVhSZWE3Z0NOUDFMWm9aNmtoRnc3bmk1dEhmT1Jrd3Ns?=
 =?utf-8?B?ZE5qeXVRWThVOE41M0gvOENtRFNJOE4vZDduVEVsc2Fld0p5Y241T2ZWSnJm?=
 =?utf-8?B?QlRKMWh0NmJMY1Vsc0R1QW1TbG93QkIvcFBlWkd5ZmJ1RkxPc0lIMjFINmhP?=
 =?utf-8?Q?HHNVSR?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 09:46:19.7747
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ba72d00d-6046-4b9e-64c2-08dd9c3a2ae5
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A108.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7993

Current logic of emulating legacy capability list is only for domU.
So, expand it to emulate for dom0 too. Then it will be easy to hide
a capability whose initialization fails in a function.

And restrict adding PCI_STATUS register only for domU since dom0
has no limitation to access that register.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v4->v5 changes:
* Return early if dom0, so that I didn't need to change the exiting return chunk.

v3->v4 changes:
* Also pass supported_caps to pci_find_next_cap_ttl() for dom0 since the n is zero when dom0,
  and add a comment to explain it.
* Restrict adding PCI_STATUS register only for domU since dom0 has no limitation to access that register.
* For dom0 register handler, set vpci_hw_write8 to it instead of NULL.

v2->v3 changes:
* Not to add handler of PCI_CAP_LIST_ID when domain is dom0.

v1->v2 changes:
new patch.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/header.c | 39 ++++++++++++++++++++++++++-------------
 xen/drivers/vpci/vpci.c   |  6 ++++++
 xen/include/xen/vpci.h    |  2 ++
 3 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 0fb3cfa6a376..d26cbba08ee1 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -758,9 +758,9 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
 {
     int rc;
     bool mask_cap_list = false;
+    bool is_hwdom = is_hardware_domain(pdev->domain);
 
-    if ( !is_hardware_domain(pdev->domain) &&
-         pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
+    if ( pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
     {
         /* Only expose capabilities to the guest that vPCI can handle. */
         unsigned int next, ttl = 48;
@@ -768,12 +768,18 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
             PCI_CAP_ID_MSI,
             PCI_CAP_ID_MSIX,
         };
+        /*
+         * For dom0, we should expose all capabilities instead of a fixed
+         * capabilities array, so setting n to 0 here is to get the next
+         * capability position directly in pci_find_next_cap_ttl.
+         */
+        const unsigned int n = is_hwdom ? 0 : ARRAY_SIZE(supported_caps);
 
         next = pci_find_next_cap_ttl(pdev->sbdf, PCI_CAPABILITY_LIST,
-                                     supported_caps,
-                                     ARRAY_SIZE(supported_caps), &ttl);
+                                     supported_caps, n, &ttl);
 
-        rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
+        rc = vpci_add_register(pdev->vpci, vpci_read_val,
+                               is_hwdom ? vpci_hw_write8 : NULL,
                                PCI_CAPABILITY_LIST, 1,
                                (void *)(uintptr_t)next);
         if ( rc )
@@ -781,7 +787,7 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
 
         next &= ~3;
 
-        if ( !next )
+        if ( !next && !is_hwdom )
             /*
              * If we don't have any supported capabilities to expose to the
              * guest, mask the PCI_STATUS_CAP_LIST bit in the status
@@ -795,15 +801,18 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
 
             next = pci_find_next_cap_ttl(pdev->sbdf,
                                          pos + PCI_CAP_LIST_NEXT,
-                                         supported_caps,
-                                         ARRAY_SIZE(supported_caps), &ttl);
+                                         supported_caps, n, &ttl);
 
-            rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
-                                   pos + PCI_CAP_LIST_ID, 1, NULL);
-            if ( rc )
-                return rc;
+            if ( !is_hwdom )
+            {
+                rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
+                                       pos + PCI_CAP_LIST_ID, 1, NULL);
+                if ( rc )
+                    return rc;
+            }
 
-            rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
+            rc = vpci_add_register(pdev->vpci, vpci_read_val,
+                                   is_hwdom ? vpci_hw_write8 : NULL,
                                    pos + PCI_CAP_LIST_NEXT, 1,
                                    (void *)(uintptr_t)next);
             if ( rc )
@@ -813,6 +822,10 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
         }
     }
 
+    /* Return early for the hw domain, no masking of PCI_STATUS. */
+    if ( is_hwdom )
+        return 0;
+
     /* Utilize rsvdp_mask to hide PCI_STATUS_CAP_LIST from the guest. */
     return vpci_add_register_mask(pdev->vpci, vpci_hw_read16, vpci_hw_write16,
                                   PCI_STATUS, 2, NULL,
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index d2f0f97e0a04..09988f04c27c 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -255,6 +255,12 @@ uint32_t cf_check vpci_hw_read32(
     return pci_conf_read32(pdev->sbdf, reg);
 }
 
+void cf_check vpci_hw_write8(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
+{
+    pci_conf_write8(pdev->sbdf, reg, val);
+}
+
 void cf_check vpci_hw_write16(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
 {
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 475981cb8155..fc8d5b470b0b 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -76,6 +76,8 @@ uint32_t cf_check vpci_hw_read16(
     const struct pci_dev *pdev, unsigned int reg, void *data);
 uint32_t cf_check vpci_hw_read32(
     const struct pci_dev *pdev, unsigned int reg, void *data);
+void cf_check vpci_hw_write8(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 void cf_check vpci_hw_write16(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon May 26 09:46:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 09:46:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997345.1378266 (Exim 4.92)
	(envelope-from )
	id 1uJUPh-0004f3-4M; Mon, 26 May 2025 09:46:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997345.1378266; Mon, 26 May 2025 09:46:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJUPh-0004eo-0k; Mon, 26 May 2025 09:46:33 +0000
Received: by outflank-mailman (input) for mailman id 997345;
 Mon, 26 May 2025 09:46:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJUPe-0003hH-UB
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 09:46:30 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20614.outbound.protection.outlook.com
 [2a01:111:f403:2415::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4ce2042d-3a16-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 11:46:30 +0200 (CEST)
Received: from MN2PR15CA0063.namprd15.prod.outlook.com (2603:10b6:208:237::32)
 by CH3PR12MB9124.namprd12.prod.outlook.com (2603:10b6:610:1a7::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.25; Mon, 26 May
 2025 09:46:25 +0000
Received: from BL02EPF0001A108.namprd05.prod.outlook.com
 (2603:10b6:208:237:cafe::22) by MN2PR15CA0063.outlook.office365.com
 (2603:10b6:208:237::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Mon,
 26 May 2025 09:46:25 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A108.mail.protection.outlook.com (10.167.241.138) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 09:46:25 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 26 May
 2025 04:46: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" 
X-Inumbo-ID: 4ce2042d-3a16-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hWsjEDzNCh53YBZMPzNv8owVUajKZ3rIfxdID1DjkXPtEMmSJRzbQoVbWwL9cvMutN9C+L4bnLmy7R3P+8lsXyV1cf7TlGfreTk4lUdDhzuOr/GVfFGEjWkCvoAPV3Xv4ALHXQf/7h/BHbAqvYi9IqgIckT38tshgW7+POQCLP851qETYN0REXgEEaTNenQilX0Bq4wkF2HKqw/0JyDrvUGgcxww+LC/0Vj98F+yViEjuNG0zunH8RQ1DHeq0+LmTG99lSR+z8KKF1G+NjH9HutZ2kyVBqz4jW7a2VJ0XOlPZ125aqk609VjWHiV0oOiWN0PemB66aKoIJu1JQhSXA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RKPMNclJOluHYnlqetY+d81+gl5XyN6bNJSpIWX/+lI=;
 b=fQtleOzZUCP01ZwD7z14LVZ6qpZMlCUFRLMpUObmPIFCNpW5p9VQV1nagioVFEe611L9Hhfyo9ZH2/LICz0w9NuNmJatGF9kA9MSt2NXSwH33slH7kxT/ONhHRF1q7rSNwjcgMwYhbDLF2/BFhzsA4SPVQQQC1ijg8AvZI5cN+oU1oMenbMKM8aoTG4rEnfS4rYfQz7lIBoxFu0GNDax0fkYrZrQ9UtrRa/WvO3Sz688CYM+L5w7Jmr2WDYECgBYeJdYbJORCAljchcarvUfZIz/UEgtGgm/BdJRue0Lsyv5Vs596+XaUs0Ej9brF/Ja/qZ+zzLwssPBh0o99fqPdw==
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=RKPMNclJOluHYnlqetY+d81+gl5XyN6bNJSpIWX/+lI=;
 b=TCvLHTzZ/cAWHRMfWjEe7kGZj8h0J1daxIKzUJ+PTORTGG9vRzJeCVHWcBNHhUn7IoTZGbLT2j4masSaLcCaVaPdRNMiAcPKidliavm/6Vl3Hirlo8nQaDWU4jTsUZLj+hnz9f1LjzGEgfvOSXR866BxNU5zWCSRu96oavRDOwo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 05/10] vpci: Hide legacy capability when it fails to initialize
Date: Mon, 26 May 2025 17:45:54 +0800
Message-ID: <20250526094559.140423-6-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250526094559.140423-1-Jiqian.Chen@amd.com>
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A108:EE_|CH3PR12MB9124:EE_
X-MS-Office365-Filtering-Correlation-Id: b98aa00b-3e19-45e4-3721-08dd9c3a2e6f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RTlaY3FVc1dTYWRkbDBsNjVPaytlMmVhdDFuNVZDY0wvbmJiWWVhaG5Rem9H?=
 =?utf-8?B?SFM0OER0Mk9YQVFwRUh1a1NOYUtURlBNb0FVZVBVYURGaXFua3lsY1VWV3Nl?=
 =?utf-8?B?d2tKdjh2clRoVkJnM003eEQ2b1oxdmQ0ekg0RUZ1L1JjRlVnQ1lGbW1IRFBs?=
 =?utf-8?B?ZUdKd1dXWWxOb1hHUExYV1FiOGI4ckpWYzNxSDA3Z1VyczlLeTBZcVFQMk5h?=
 =?utf-8?B?Q3NqN0Z2alRqSzEvMEQ5UlZTRTFuczVGZmFCM1pVRmtSSEZMZXpLL2R5bHJ2?=
 =?utf-8?B?a3AwdE1qVkxuell1RC9kSTJ3RWhnRk1nQ0VZQmt6c053RitQemRkSGNvOGs1?=
 =?utf-8?B?bmpRZjIrdWxsMm40NDNPb1Q4c1JkTHZmbGJSTXZxSHFDRGF0bmFkT2VJQ2Y0?=
 =?utf-8?B?RmNGY2RvalJvWWRUaTdHL0FWemJSWE8wSGdYY0lscFpXQ3BsK3ZqZlZjbU9F?=
 =?utf-8?B?aGFhdTMvd2tOaUxBeHpCZ1BVSXhmY3ZUamFiNzJST01BcytQdmdCMGhzYWlG?=
 =?utf-8?B?eTFOY2RDbGRiWWIxa2Y2STFqK3NWanRhMTFIM0dFR0tubldmcE5WVnNyTnVT?=
 =?utf-8?B?bmx4VVNpNlVXdUJJcURtVkg2YXNJSUJ6NkJYQ3I5dVM1S2NGYWZCM0YwUndO?=
 =?utf-8?B?MHVPbWdMZzJZMGhCck92ck5iL0VtOFg3S3Y4R2I1QkdRTGF2d0Z0Z0lodHJK?=
 =?utf-8?B?d2hFQWJOWnlEWU81eHRQbW5CNHpFaDVrdHRMUXF3c2t0NjVJaG56T2dmbVla?=
 =?utf-8?B?ZnFjN21DU0h4ZkFqeEVXOGcrSGtld2FDSDFJSG1vajhYb0xDZEtRejlaYVZ4?=
 =?utf-8?B?ZmxIV0NibW9mbDVUT3F3KzBtT3VGUXNYTlJsRGdlOElNL2tWZVZoeW1DUDNv?=
 =?utf-8?B?VkhtbGhPQ2tScWhXeHRrRzFoV1dKTTI1eHl4cExTUS9mTXVPLzBKNUdKTHNL?=
 =?utf-8?B?V25KQ1lKay80ZjIzYU9Hcy84NlUzUVhyN3ZDMER0S043V3lOV0haQWtnZG44?=
 =?utf-8?B?akJvL3NNaW52MjZOditSekRNUXFwNmNYY1RiOVVjNFg2YjV3SkhOQXI4TUdZ?=
 =?utf-8?B?NThqbmZWcURDS1RGREVQU2orc3JVUUdtdGZaYnhLWVVBNmpsSXFybEZwK216?=
 =?utf-8?B?Yml0TFc3SHYrTk5GWWNSbGt3U01TU0xQOHVqSnJpNHRPNmxGNUpTQWZyaDF4?=
 =?utf-8?B?TEJJSVdxUHhoZU9hRmo1MkxOTDJiVXV1MFV4dTB5WFVZd0JzUTJNNGlPcFVH?=
 =?utf-8?B?bERzWENnWWQzODZyc1hnZWdycFdKV0ZUOXhSZm5HVWYzbGcxbkFWTk9ERUR3?=
 =?utf-8?B?MjJoUFRHS0NrYnMvNTBDMlZBU3JZeFJUQUFvdVdoSEVvOHVmTzRXSWZoWlpx?=
 =?utf-8?B?SVRuWU1pUGMwSlBTakJxR281N3hkMTRtQVMrNnQ2VUJkTFo4TFk5Zmxkb3Fl?=
 =?utf-8?B?cDBlcDFHcmxKTCtZelhPMUtIZXNKUjN6L0hSdWZwRXZuRk9zUjJ1alhubWJ5?=
 =?utf-8?B?UzR6U0E5cGxYcEs4MnBYcjBGSjNBaXNIbDRvaFBUb3puUGx1MGQvUmgzMVBH?=
 =?utf-8?B?L2NzeUZxYU5HTjZEY2pTMnJERnN0OU5Wdjd5VEpxWmhDVlp5TllGbzBqSVdL?=
 =?utf-8?B?bHdFTmlralZWbkg5a1V5ZSt4eDl5OFBmeVJGSkMyZ0dhYlRvdkZrTUlhK2Vr?=
 =?utf-8?B?TDBZejF5U1ZGbWgyRG5QN2R5Y0Z6RlBHNzNjUHJ2QmExS1hhWTdHNiszUjJM?=
 =?utf-8?B?bk5mNWV2NUg2NWtDa3Zzcm0xa0x5TkVRTExNYk1ZekNBZi8vUk9iejVRUlZp?=
 =?utf-8?B?KzZBT2N2bnZrUlBDZmMwMDQrVVFUWkFidVRVbDQ5L3RESVR4TEtQMm9NQjE0?=
 =?utf-8?B?V0h3V3hkenFwQUl1NDhuWCtmMUthQ3BkeElIcnVKYjBwVS9oVHE0MVJpQnpi?=
 =?utf-8?B?RlpHU3NQaDUveGcxbU11TTVibjBNRlBiNk9QY2xoR1F0aHJzSkxlTk5yVnk5?=
 =?utf-8?B?OG9kMUdXWnBoU0YvTFJ0SGszSERkOWM1WURNWEgxUjI1Y2ZMdFUrb2xYSGFz?=
 =?utf-8?Q?48wY9y?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 09:46:25.7128
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b98aa00b-3e19-45e4-3721-08dd9c3a2e6f
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A108.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9124

When vpci fails to initialize a legacy capability of device, it just
returns an error and vPCI gets disabled for the whole device.  That
most likely renders the device unusable, plus possibly causing issues
to Xen itself if guest attempts to program the native MSI or MSI-X
capabilities if present.

So, add new function to hide legacy capability when initialization
fails. And remove the failed legacy capability from the vpci emulated
legacy capability list.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v4->v5 changes:
* Modify vpci_get_register() to delete some unnecessary check, so that I don't need to move function vpci_register_cmp().
* Rename vpci_capability_mask() to vpci_capability_hide().

v3->v4 changes:
* Modify the commit message.
* In function vpci_get_previous_cap_register(), add an ASSERT_UNREACHABLE() if offset below 0x40.
* Modify vpci_capability_mask() to return error instead of using ASSERT.
* Use vpci_remove_register to remove PCI_CAP_LIST_ID register instead of open code.
* Add check "if ( !offset )" in vpci_capability_mask().

v2->v3 changes:
* Separated from the last version patch "vpci: Hide capability when it fails to initialize"
* Whole implementation changed because last version is wrong.
  This version adds a new helper function vpci_get_register() and uses it to get
  target handler and previous handler from vpci->handlers, then remove the target.

v1->v2 changes:
* Removed the "priorities" of initializing capabilities since it isn't used anymore.
* Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
  remove failed capability from list.
* Called vpci_make_msix_hole() in the end of init_msix().

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/vpci.c | 117 ++++++++++++++++++++++++++++++++++++++--
 1 file changed, 113 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 2861557e06d2..60e7654ec377 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -83,6 +83,99 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
 
 #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
 
+static struct vpci_register *vpci_get_register(struct vpci *vpci,
+                                               unsigned int offset,
+                                               unsigned int size)
+{
+    struct vpci_register *rm;
+
+    ASSERT(spin_is_locked(&vpci->lock));
+
+    list_for_each_entry ( rm, &vpci->handlers, node )
+    {
+        if ( rm->offset == offset && rm->size == size )
+            return rm;
+
+        if ( offset <= rm->offset )
+            break;
+    }
+
+    return NULL;
+}
+
+static struct vpci_register *vpci_get_previous_cap_register(
+    struct vpci *vpci, unsigned int offset)
+{
+    uint32_t next;
+    struct vpci_register *r;
+
+    if ( offset < 0x40 )
+    {
+        ASSERT_UNREACHABLE();
+        return NULL;
+    }
+
+    r = vpci_get_register(vpci, PCI_CAPABILITY_LIST, 1);
+    if ( !r )
+        return NULL;
+
+    next = (uint32_t)(uintptr_t)r->private;
+    while ( next >= 0x40 && next != offset )
+    {
+        r = vpci_get_register(vpci, next + PCI_CAP_LIST_NEXT, 1);
+        if ( !r )
+            return NULL;
+        next = (uint32_t)(uintptr_t)r->private;
+    }
+
+    if ( next < 0x40 )
+        return NULL;
+
+    return r;
+}
+
+static int vpci_capability_hide(struct pci_dev *pdev, unsigned int cap)
+{
+    const unsigned int offset = pci_find_cap_offset(pdev->sbdf, cap);
+    struct vpci_register *prev_next_r, *next_r;
+    struct vpci *vpci = pdev->vpci;
+
+    if ( !offset )
+    {
+        ASSERT_UNREACHABLE();
+        return 0;
+    }
+
+    spin_lock(&vpci->lock);
+    next_r = vpci_get_register(vpci, offset + PCI_CAP_LIST_NEXT, 1);
+    if ( !next_r )
+    {
+        spin_unlock(&vpci->lock);
+        return -ENODEV;
+    }
+
+    prev_next_r = vpci_get_previous_cap_register(vpci, offset);
+    if ( !prev_next_r )
+    {
+        spin_unlock(&vpci->lock);
+        return -ENODEV;
+    }
+
+    prev_next_r->private = next_r->private;
+    /*
+     * Not calling vpci_remove_register() here is to avoid redoing
+     * the register search
+     */
+    list_del(&next_r->node);
+    spin_unlock(&vpci->lock);
+    xfree(next_r);
+
+    if ( !is_hardware_domain(pdev->domain) )
+        return vpci_remove_register(vpci, offset + PCI_CAP_LIST_ID, 1);
+
+    return 0;
+}
+
 static int vpci_init_capabilities(struct pci_dev *pdev)
 {
     for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
@@ -91,7 +184,6 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
         const unsigned int cap = capability->id;
         const bool is_ext = capability->is_ext;
         unsigned int pos;
-        int rc;
 
         if ( !is_ext )
             pos = pci_find_cap_offset(pdev->sbdf, cap);
@@ -103,9 +195,26 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
         if ( !pos )
             continue;
 
-        rc = capability->init(pdev);
-        if ( rc )
-            return rc;
+        if ( capability->init(pdev) )
+        {
+            int rc;
+
+            if ( capability->cleanup ) {
+                rc = capability->cleanup(pdev);
+                if ( rc )
+                    return rc;
+            }
+
+            printk(XENLOG_WARNING "%pd %pp: %s cap %u init fail, mask it\n",
+                   pdev->domain, &pdev->sbdf,
+                   is_ext ? "extended" : "legacy", cap);
+            if ( !is_ext )
+            {
+                rc = vpci_capability_hide(pdev, cap);
+                if ( rc )
+                    return rc;
+            }
+        }
     }
 
     return 0;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon May 26 09:46:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 09:46:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997346.1378271 (Exim 4.92)
	(envelope-from )
	id 1uJUPh-0004hS-Df; Mon, 26 May 2025 09:46:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997346.1378271; Mon, 26 May 2025 09:46:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJUPh-0004h5-8Q; Mon, 26 May 2025 09:46:33 +0000
Received: by outflank-mailman (input) for mailman id 997346;
 Mon, 26 May 2025 09:46:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJUPf-0003hH-UO
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 09:46:32 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2414::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4c248069-3a16-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 11:46:30 +0200 (CEST)
Received: from BL6PEPF00013DF9.NAMP222.PROD.OUTLOOK.COM
 (2603:10b6:22e:400:0:1001:0:c) by SN7PR12MB7882.namprd12.prod.outlook.com
 (2603:10b6:806:348::16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Mon, 26 May
 2025 09:46:25 +0000
Received: from BL02EPF0001A103.namprd05.prod.outlook.com
 (2a01:111:f403:c922::3) by BL6PEPF00013DF9.outlook.office365.com
 (2603:1036:903:4::4) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Mon,
 26 May 2025 09:46:24 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A103.mail.protection.outlook.com (10.167.241.133) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 09:46:24 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 26 May
 2025 04:46: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" 
X-Inumbo-ID: 4c248069-3a16-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pZNcvluNG6GQdfWF4G0nlv/cxQmeZ/eWjgW8oiCa9zfPRL90y7wABTeF/SPp0M5DfWje2Xb3G7O9v+wcy6UjyNwFddBiGZ7uyv1CNs43fG8cyOTcup+MMvDXHRjbDD3moX+C0FRMAOHL7KpkSVpY7jsFT9Fgno58LGArqOqXxrKVu3hicNfl3GXbHNqhe0cfOB8w66aVqQBRMcY+pE2ZCke/HJhQ0GrW90oAYptrSrFjayGznsqonWrWZyq9B9C9qh8OVvKtIsbZousaLXHBoVhbr29l9GKXVWqnZA5iAg0q1JTBQvWwBUTk90XuW7Uk3VikrOduo57Qu8chpjVbMw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZipsPW/ns1bYXVu9iRhK77+DF2OaAhLQxGjFTNkOoi0=;
 b=WqGKTiNXEaiAM0d5ppcbEGjsjsoY/vucawaaBxlj4FH6dOvkctu+g4wCg1prFWzZmmhMiXLP9ppopvVlwWeMFLPbr5OvA1TcMfO+9iAE/j/oyL0vqyOoKhBsMYIY26VGJcnI7v5SF3HzZPEK7CW4ATb1zEwEiaaYiwPT9dTuP91C5EA0w2aSeZyAQbCEkn3iurXcFhRm12WF9B9/97INwyxcIke4aZtJ4VnGDibRwKYVMaqwyQKz5JAZBsPkDSg9iHUTQaNpp4CpirVsCwMZ2vicrn3kGexS6FCCG4CAdjvTXK4WW4lcZ2imDrW8uvfFSQbZJxVjJ7XF3SZwqQfdgQ==
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=ZipsPW/ns1bYXVu9iRhK77+DF2OaAhLQxGjFTNkOoi0=;
 b=KCaahkoOQg09xeREJdIRjlk0u/hOF0vwcaO0XABiYXFZT9VNoQneZbYkl5zH5Z/QvN/iepplNExuKPtAn+X6uZyfbMeonMmzgLn+DjrepOsOPsfT3tBwXRxNv54khjxzihJb6duuKwzhxbLsM9UlUlhUM/zwm6uug7YxSmzbsNc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT
Date: Mon, 26 May 2025 17:45:53 +0800
Message-ID: <20250526094559.140423-5-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250526094559.140423-1-Jiqian.Chen@amd.com>
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A103:EE_|SN7PR12MB7882:EE_
X-MS-Office365-Filtering-Correlation-Id: c28d7e39-a65a-4d7a-aef9-08dd9c3a2d74
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Ymd4WEZzNURJMXVRQVNMcEJWNmptOHZ0YkxCY1lPdk5HVXNXaFVtNjYwTlRk?=
 =?utf-8?B?QnhtVVQxQ1RlRyt1SlhmSUxTTE13SG8yTFplQWJack5kS3Zidlp6WGdySkx2?=
 =?utf-8?B?ZHJKSTFWamdzaFNXYWV0YVZHRU1OL0RvTUtnWjJvRTk0MmoyTnhZaHprQkg0?=
 =?utf-8?B?anRwWGhQNm1ibnZOM1lQWmNrNWE5Yk95SW1VYTEySDJ2VWJ0LzBoTXRTd2k1?=
 =?utf-8?B?Q0JHR0NVV0pRVnJFS0puVjJxRDlTcFpMT1MzWWhteElId2wrUkR6Z0RUN0Ev?=
 =?utf-8?B?OG82cnBvRHJhV1k2S0g3cFFpVzZvWE5aUFdJbnNUVmVYYzFuQjh5UDREWDNt?=
 =?utf-8?B?ZnVpWGY1dTVLMVhUMEV4UHYzc0l4a0JkNnJXOHJNQVdYTzViUzZZcDh5Sklq?=
 =?utf-8?B?Y1YvK0JKb1RjNjN6d1BPS3RSNnk5RVVXcEg2MzZHdTBPaWNFR2ZZcTNWc21E?=
 =?utf-8?B?aGhwMXZPNThrZm5TSWZXREpDSUdOdjMxRzc3THpYdVZqQTBwQ0NwMXJ1K3FD?=
 =?utf-8?B?c1pjV0FQRXJKTVpybzJwRzVmdnIzZWd2L0RIeW1aU3V3M1lZekN4d3JNVlIy?=
 =?utf-8?B?ZE1mOTdWVkRiWWlDYytqWmloR1pCejFDUUhHejlMT05MTitqQzcxcUtsMnF2?=
 =?utf-8?B?NTIrcDNtQUdBci9tbkpPTldQZWdZUDdvTllHTTMwQ1RyTHZxdHNaaHhaSktw?=
 =?utf-8?B?dVZLdVVsVFdWVWRrYnVvZERaTkpZZzJVbkZVVWsxUldsZ3lUOWovUytVWlJZ?=
 =?utf-8?B?KzkxR24zNTRZWnUxb0YraGhGM0FZZUZ5N21ycEE2ZDdoL1hnTjN5RWgxdlgr?=
 =?utf-8?B?RWY3L3ExemRaMXhJN2Vwd1ltakxvcGkvRzFUK1RiVEM0ZVd2dGRzMWdoaStt?=
 =?utf-8?B?ZjhHUi9xR0t6Q2pLckF6aVdUWGZGNnQvYkJ2clhWRERWeEpRdjhES21IZEN4?=
 =?utf-8?B?N2RPM0x0My9Dd2ZKSU1oYUhDQmZjSEFqMXdncEFBenJaeWFYNndkNDZXSmNM?=
 =?utf-8?B?c0lJR3FNVGpqVXJDNm5lS1Qwc05CVnlTQXdSMHJsZVczKzFzVHZjYVNlRGhW?=
 =?utf-8?B?TE8vZTRhbjhWVlZvU1dXczZxWlUreGxoR3VjUFAxQ2dCdUlZKzVUUisrcEFF?=
 =?utf-8?B?cUUwdjNBYnVmY1RkaUFZN2dxR0JyeU5EWlNyYkllMzdob0I1VGlHTjdqVlJm?=
 =?utf-8?B?YjlUSGxEMzRkaWxGamgvTDJyL1pqdUZLOThXSjdQMkFUZmR4Ti9rYzdZRlhU?=
 =?utf-8?B?NXpoUDJHOTBtUnhHSitqUDdJd21vYmV2UjcvOEFhOGhxdlQ2c2hyV0hXRHhC?=
 =?utf-8?B?UXZ2djNrZlJ6RGpPY0VUTUIvSWhGbHl0c2dCZmhaZlQ0NTBZelpSeUw3QVdu?=
 =?utf-8?B?bHJ4TWxvNHVuNHhMd0d0YWt1dldId0R3U1VLc3FFbHlCQWxuN1ZSYVQ0ODBN?=
 =?utf-8?B?RWhDbEVncTlKaE1FMFE1Y0lBemFDbVVqOUczL09qWDg2aFFBSXpya0o3V0xq?=
 =?utf-8?B?aVpMVm1pVUFKSFFJa0l4RVNRY1FtTVZ4YTRaMDVQMTg5YXhjNzNGRHRqMUJQ?=
 =?utf-8?B?TEZ2YUF0eVNqa3dRczRZNXYwTTJRQ3NMVDVsZlh6aUMrODJuaXFDdDB2c3Za?=
 =?utf-8?B?NGxSUk5leEE3VzBiTVh3M0ZucFpjbWEyVTcyM1lVMHNpb2NYQytWRUxETm5M?=
 =?utf-8?B?NWZwQjd5Z01nZG05SDJWZC9VS1pSNG1sRkdjYXpPMGR0YkhwZU9ISDhzTFNw?=
 =?utf-8?B?aXFEUFl0ZmluMFIrenN4dFRTM0dackJSTXRiUTAvaGhqMnBRWVRNdVlkOFlK?=
 =?utf-8?B?MkFUU0N6S0swR1dKcGJyL2JXSUY3VHhzcllKZjRnZTlDTlR6NTUzeFFEZFd5?=
 =?utf-8?B?Wm9PM2loZUVkVnJaK0FLaEQ3ZnVpN1dxSnBIRzZlUWRoS3JkWUVPMkNDMXR3?=
 =?utf-8?B?aUlQQlhrajFBanR0aVpZME04MVZPOFZOd0pST0hzU3BYa1h3ZVluS1hUck5v?=
 =?utf-8?B?QkVuV1pjN2RPM0k3OE04M0h5VmJGVERwR21sREtwUDl3WXBLV1J6eDRHeVA3?=
 =?utf-8?Q?LL65X5?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 09:46:24.0702
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c28d7e39-a65a-4d7a-aef9-08dd9c3a2d74
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A103.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7882

Refactor REGISTER_VPCI_INIT to contain more capability specific
information, this is benefit for follow-on changes to hide capability
when initialization fails.

What's more, change the definition of init_header() since it is
not a capability and it is needed for all devices' PCI config space.

After refactor, the "priority" of initializing capabilities isn't
needed anymore, so delete its related codes.

Note:
Call vpci_make_msix_hole() in the end of init_msix() since the change
of sequence of init_header() and init_msix().

The cleanup hook is also added in this change, even if it's still
unused. Further changes will make use of it.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
cc: Andrew Cooper 
cc: Anthony PERARD 
cc: Michal Orzel 
cc: Jan Beulich 
cc: Julien Grall 
cc: Stefano Stabellini 
---
v4->v5 changes:
* Rename REGISTER_VPCI_CAP to REGISTER_PCI_CAPABILITY, rename REGISTER_VPCI_LEGACY_CAP to REGISTER_VPCI_CAP, rename REGISTER_VPCI_EXTENDED_CAP to REGISTER_VPCI_EXTCAP.
* Change cleanup hook of vpci_capability_t from void to int.

v3->v4 changes
* Delete the useless trailing dot of section ".data.vpci".
* Add description about priority since this patch removes the initializing priority of capabilities and priority is not needed anymore.
* Change the hook name from fini to cleanup.
* Change the name x and y to be finit and fclean.
* Remove the unnecessary check "!capability->init"

v2->v3 changes:
* This is separated from patch "vpci: Hide capability when it fails to initialize" of v2.
* Delete __maybe_unused attribute of "out" in function vpci_assign_devic().
* Rename REGISTER_VPCI_EXTEND_CAP to REGISTER_VPCI_EXTENDED_CAP.

v1->v2 changes:
* Removed the "priorities" of initializing capabilities since it isn't used anymore.
* Added new function vpci_capability_mask() and vpci_ext_capability_mask() to remove failed capability from list.
* Called vpci_make_msix_hole() in the end of init_msix().

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/header.c |  3 +--
 xen/drivers/vpci/msi.c    |  2 +-
 xen/drivers/vpci/msix.c   |  8 +++++--
 xen/drivers/vpci/rebar.c  |  2 +-
 xen/drivers/vpci/vpci.c   | 46 ++++++++++++++++++++++++++++++---------
 xen/include/xen/vpci.h    | 30 ++++++++++++++++++-------
 xen/include/xen/xen.lds.h |  2 +-
 7 files changed, 68 insertions(+), 25 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 4b2f761c9c24..9fa1cda23151 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -872,7 +872,7 @@ static int vpci_init_ext_capability_list(struct pci_dev *pdev)
     return 0;
 }
 
-static int cf_check init_header(struct pci_dev *pdev)
+int vpci_init_header(struct pci_dev *pdev)
 {
     uint16_t cmd;
     uint64_t addr, size;
@@ -1068,7 +1068,6 @@ static int cf_check init_header(struct pci_dev *pdev)
     pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd);
     return rc;
 }
-REGISTER_VPCI_INIT(init_header, VPCI_PRIORITY_MIDDLE);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index 66e5a8a116be..2d45c7867de7 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -270,7 +270,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_INIT(init_msi, VPCI_PRIORITY_LOW);
+REGISTER_VPCI_CAP(PCI_CAP_ID_MSI, init_msi, NULL);
 
 void vpci_dump_msi(void)
 {
diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 74211301ba10..674815ead025 100644
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -703,9 +703,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
     pdev->vpci->msix = msix;
     list_add(&msix->next, &d->arch.hvm.msix_tables);
 
-    return 0;
+    spin_lock(&pdev->vpci->lock);
+    rc = vpci_make_msix_hole(pdev);
+    spin_unlock(&pdev->vpci->lock);
+
+    return rc;
 }
-REGISTER_VPCI_INIT(init_msix, VPCI_PRIORITY_HIGH);
+REGISTER_VPCI_CAP(PCI_CAP_ID_MSIX, init_msix, NULL);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
index 793937449af7..9cafd80ca2c9 100644
--- a/xen/drivers/vpci/rebar.c
+++ b/xen/drivers/vpci/rebar.c
@@ -118,7 +118,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
+REGISTER_VPCI_EXTCAP(PCI_EXT_CAP_ID_REBAR, init_rebar, NULL);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 8474c0e3b995..2861557e06d2 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -36,8 +36,8 @@ struct vpci_register {
 };
 
 #ifdef __XEN__
-extern vpci_register_init_t *const __start_vpci_array[];
-extern vpci_register_init_t *const __end_vpci_array[];
+extern vpci_capability_t *const __start_vpci_array[];
+extern vpci_capability_t *const __end_vpci_array[];
 #define NUM_VPCI_INIT (__end_vpci_array - __start_vpci_array)
 
 #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
@@ -83,6 +83,34 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
 
 #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
 
+static int vpci_init_capabilities(struct pci_dev *pdev)
+{
+    for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
+    {
+        const vpci_capability_t *capability = __start_vpci_array[i];
+        const unsigned int cap = capability->id;
+        const bool is_ext = capability->is_ext;
+        unsigned int pos;
+        int rc;
+
+        if ( !is_ext )
+            pos = pci_find_cap_offset(pdev->sbdf, cap);
+        else if ( !is_hardware_domain(pdev->domain) )
+            continue;
+        else
+            pos = pci_find_ext_capability(pdev->sbdf, cap);
+
+        if ( !pos )
+            continue;
+
+        rc = capability->init(pdev);
+        if ( rc )
+            return rc;
+    }
+
+    return 0;
+}
+
 void vpci_deassign_device(struct pci_dev *pdev)
 {
     unsigned int i;
@@ -128,7 +156,6 @@ void vpci_deassign_device(struct pci_dev *pdev)
 
 int vpci_assign_device(struct pci_dev *pdev)
 {
-    unsigned int i;
     const unsigned long *ro_map;
     int rc = 0;
 
@@ -159,14 +186,13 @@ int vpci_assign_device(struct pci_dev *pdev)
         goto out;
 #endif
 
-    for ( i = 0; i < NUM_VPCI_INIT; i++ )
-    {
-        rc = __start_vpci_array[i](pdev);
-        if ( rc )
-            break;
-    }
+    rc = vpci_init_header(pdev);
+    if ( rc )
+        goto out;
+
+    rc = vpci_init_capabilities(pdev);
 
- out: __maybe_unused;
+ out:
     if ( rc )
         vpci_deassign_device(pdev);
 
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 61d16cc8b897..e5e3f23ca39c 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -13,11 +13,12 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev, unsigned int reg,
 typedef void vpci_write_t(const struct pci_dev *pdev, unsigned int reg,
                           uint32_t val, void *data);
 
-typedef int vpci_register_init_t(struct pci_dev *dev);
-
-#define VPCI_PRIORITY_HIGH      "1"
-#define VPCI_PRIORITY_MIDDLE    "5"
-#define VPCI_PRIORITY_LOW       "9"
+typedef struct {
+    unsigned int id;
+    bool is_ext;
+    int (*init)(struct pci_dev *pdev);
+    int (*cleanup)(struct pci_dev *pdev);
+} vpci_capability_t;
 
 #define VPCI_ECAM_BDF(addr)     (((addr) & 0x0ffff000) >> 12)
 
@@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev *dev);
  */
 #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
 
-#define REGISTER_VPCI_INIT(x, p)                \
-  static vpci_register_init_t *const x##_entry  \
-               __used_section(".data.vpci." p) = (x)
+#define REGISTER_PCI_CAPABILITY(cap, finit, fclean, ext) \
+  static vpci_capability_t finit##_t = { \
+        .id = (cap), \
+        .init = (finit), \
+        .cleanup = (fclean), \
+        .is_ext = (ext), \
+  }; \
+  static vpci_capability_t *const finit##_entry  \
+               __used_section(".data.vpci") = &finit##_t
+
+#define REGISTER_VPCI_CAP(cap, finit, fclean) \
+                REGISTER_PCI_CAPABILITY(cap, finit, fclean, false)
+#define REGISTER_VPCI_EXTCAP(cap, finit, fclean) \
+                REGISTER_PCI_CAPABILITY(cap, finit, fclean, true)
+
+int __must_check vpci_init_header(struct pci_dev *pdev);
 
 /* Assign vPCI to device by adding handlers. */
 int __must_check vpci_assign_device(struct pci_dev *pdev);
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index 793d0e11450c..84ec506b00da 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -188,7 +188,7 @@
 #define VPCI_ARRAY               \
        . = ALIGN(POINTER_ALIGN); \
        __start_vpci_array = .;   \
-       *(SORT(.data.vpci.*))     \
+       *(.data.vpci)             \
        __end_vpci_array = .;
 #else
 #define VPCI_ARRAY
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon May 26 09:46:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 09:46:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997347.1378286 (Exim 4.92)
	(envelope-from )
	id 1uJUPj-0005AX-PH; Mon, 26 May 2025 09:46:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997347.1378286; Mon, 26 May 2025 09: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 1uJUPj-0005AK-L2; Mon, 26 May 2025 09:46:35 +0000
Received: by outflank-mailman (input) for mailman id 997347;
 Mon, 26 May 2025 09:46:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJUPi-0003hH-94
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 09:46:34 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20630.outbound.protection.outlook.com
 [2a01:111:f403:200a::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4e12c9f4-3a16-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 11:46:33 +0200 (CEST)
Received: from BL0PR0102CA0026.prod.exchangelabs.com (2603:10b6:207:18::39) by
 DS4PR12MB9707.namprd12.prod.outlook.com (2603:10b6:8:278::9) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8769.24; Mon, 26 May 2025 09:46:30 +0000
Received: from BL02EPF0001A106.namprd05.prod.outlook.com
 (2603:10b6:207:18:cafe::b3) by BL0PR0102CA0026.outlook.office365.com
 (2603:10b6:207:18::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Mon,
 26 May 2025 09:46:18 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A106.mail.protection.outlook.com (10.167.241.139) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 09:46:29 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 26 May
 2025 04:46: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" 
X-Inumbo-ID: 4e12c9f4-3a16-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IP/vku6xvFOnVqfNrX34k5zc5lCLDS+ew9JVoGJhKlNnEm21LT9tAy1M61awkuYyOw8zLryTN6Bm0fbPoLt4CXCr7QcFuTT9G1drAXO19SLOFlwVAdU6olfGI+I6iKWLTROxNfXJy2OkyWDxIQe4mp7OldtHSu1uX/+uDOdd1mj46F+U0xgeA1gNPKg9BhbYWmwH17j1vGIYcSKPY6XgcRDARAkEtpB8yyI64fflJYdj96wlsyxmc9KwDRCnWQ8gxVhqUnc9bpXhYkzyfU+Qm98RuKev9Z3CkgBB5CkY3I/YCp+PUev2a2canuAzZfP1A72hHprygBYYPmjIwOq7Rg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xzigtSLOhnEm/3jzO+ojdi4ugIrKKVRZMdTKswuh48k=;
 b=ujsLU93NBWWUX69VWe5/xaO7lxpA4xEVmTM8gSRhvqOY54LpFLU2CTuAWR73o8GCX4LeixYERTux34AVRhRYQ3ti7A9zaPHHHATSUEK9KlL5dcuNQs2FXLnD8M7oSw7h2sMVlccgUk4Uj84sJR2BEKYUY2V9NDUDoAwqnreJfczOsChDd4aYSpxZz/SzEzX5UGi6i6clPPyG04wYPlxOfaN5FJWAJoI/GaTcgOOVtEyvxZ1GlrsohaPkM8MsRFPZh9XYpGvAPbLS+k7i2j9FFaceDHhFjItIQyAnMyQN1XEKW6UGnouP2/CfITLKenPx1t1lHu22MyfG2Hi/xDWYww==
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=xzigtSLOhnEm/3jzO+ojdi4ugIrKKVRZMdTKswuh48k=;
 b=Cnn7FgGd29aMfD0r8+jqS6g3nxK7UBUXTIwOs24oGAXy3FZAqaIDO9tshp1Y9HjZvqEPTfY85NTb/82IzkiK7raejh3ghQt40yb6L7768Eae8h8sZxHnJ4Ao+Qybk0Eo74+e8RUf0UMbmtv3TNTHwoZ+S1WdTrbcaJH9a/44P4E=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v5 06/10] vpci: Hide extended capability when it fails to initialize
Date: Mon, 26 May 2025 17:45:55 +0800
Message-ID: <20250526094559.140423-7-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250526094559.140423-1-Jiqian.Chen@amd.com>
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A106:EE_|DS4PR12MB9707:EE_
X-MS-Office365-Filtering-Correlation-Id: f472eaff-55aa-42d4-969b-08dd9c3a30cf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dU1hSmNscXNrWENJaklXQ3JwQjBpaHMyN3o1bngxOEM2eGdSSzdKRU9Kd0tR?=
 =?utf-8?B?aWtMN0tWcSs1OVVYV3d0SXlJem53Mk5vblJ0SlFSbFNHL1NZV3FFcXNQMVhE?=
 =?utf-8?B?SjR5TXhjT1c2b2l4a2pDbTRZR3NBZkdUdEJ4dFJkcHZuRGtYdjU1T2kwTW5L?=
 =?utf-8?B?TzcvYk80K2dKS2J0c3pJUWlzTFBSbEdBZFlKRUFkZHNWYTFjK1hsVUpURmN5?=
 =?utf-8?B?eUZveDJDb1BqT2w1aUo3RmpQb3dkcTBwNG9PeXlReXF1T09BeWpCdGZndk5k?=
 =?utf-8?B?UDZXc0ZnWWlxTEtPbFVJVlFnWTlkdGF0QmFaK1g4NUtQa29ucGFOaWxKZWEv?=
 =?utf-8?B?dElPN0NxenJOT3YvOXpZV2dkcHlYeTdzcWZtcm9Mcmp4eVRYalM2a3g5RDZp?=
 =?utf-8?B?NEd1UjMwdHRTTUNlbGlsMU9wZ2lHUnA0V2h6VHhVdDZwRjdXVERhcmdTTnBl?=
 =?utf-8?B?WWpPUHNRRXV5dmt3V0Nsc3BFdFBzSVN2eEFQS3RmbmwyTzZHVVNWcllYMHQw?=
 =?utf-8?B?Q01tTTRKZ2JNKzdlN2ZVU2FBcjJSVVR1RWNXbFlFb09aNFVOb3ptUjFlMnpy?=
 =?utf-8?B?TkdzdFZNZW5iS1N6RnNyZlAvSjZHNG11d0liaW1xdWFHOHYyNHZMRm85bi9X?=
 =?utf-8?B?WEYzaXh6YXRZUTlHQmJPMmM3NllNeGQ2YmQrRWtWSW5RZ20wQUl6Tnh1bXdr?=
 =?utf-8?B?eE9tYVg0TzBVd1RvK0U4SUtMdmRNMjdtdFpOTTFiMC9ZRjQ5S1RDYUdINEpa?=
 =?utf-8?B?VkdtV2FyeG5qdC9LbGVEclFSUDFuT3VxUkFDcVhrME9xN1FlWWdVNHhRQ3Q0?=
 =?utf-8?B?b0R3WFdnOGRPdndKU1Z6a0ptMkNnSW5jNE9RZE4rblc4a3F2REpqWDRPZWZK?=
 =?utf-8?B?VTk4U0lBZjVHaWRpME9NbGRkU3JRL2V4U0gxUHpPUXF1NGU1d3ZxUDJ0YThJ?=
 =?utf-8?B?a0F1RlJ0andQRWVldUJsYVlyaDBrNWVDUlQ1K0lpMXJyM0pqaEJYTjJaQXVH?=
 =?utf-8?B?aXBMUjVTUWsyclJmanpzNEhGbjQ5bGJCekxTbzk3Rk1ncGJnbTM3UzdCQzBB?=
 =?utf-8?B?QnpLT3BWR0R1aXNjTW1kZmRRamh4NDZIeGVGd0tWYVlaTTZ4N0JqZEVESXlH?=
 =?utf-8?B?WEU1OUhwSG0zMnAxRDF4aFh4blQ3LytLL3BoREhYUkJKeWZnbUhPeWtvbEpE?=
 =?utf-8?B?dWE3VnhVVlIwYVlCZVg0MmFnZHY1L0hyMFJZYTdxT04vQXc4Z0gyMEV4RW9o?=
 =?utf-8?B?aCtmeDdDQnRwY0ZSa2MvTFdDdnloSHBmekRDOWVSVUoydUVtVHBWaTNXMThG?=
 =?utf-8?B?YnkrRC84Z1V6VHQrRGFuK01rU2VjbE82aXdLdHRKOHlHdmh5cEZ2WXlPMTFq?=
 =?utf-8?B?UVlsL2JodkVveHVDSk5NeVB3WFdOdSt4andPT1JMSlN2ZDdnV3NucEhlUWZS?=
 =?utf-8?B?RlFwZGFrYVpzWmVKTjlWR2twVktPV1pPRlhMd1BPbkpLUkx1RnFoVm1CWTdC?=
 =?utf-8?B?Y25zTHV1WUVRUTZFQzNXNW5YdGI2NHBXbTZFTlptUVZrWW1jM05mb1F2ZzlP?=
 =?utf-8?B?Q3lKa0sra0RPZ243UDFUR2w3Zzhvam9BMmdIcXhLb0tNVHRBZElPQzcxd1lv?=
 =?utf-8?B?bW5VeVZKM1Rkd3dVbk9pVFk5OCszcVJFeE96ODE5Vzh1bFlXMlpOQkdicFQv?=
 =?utf-8?B?V09tNGpiZG9wMTF2bTArWEpNNDJCNytsK0Q5bU8zQ2haRXpEV0poMTFka01H?=
 =?utf-8?B?S0N3akJ0amxKTUhuZlUvRDMxMVR6ZWV2a1Fic3J4WUZYa29MK2ZjQjRvb08v?=
 =?utf-8?B?cldBbHFaRjJPRGo5WW9Sc084dzFpS1dhcHdCNXRlWW1pb3VmcnV2eUZpdmQy?=
 =?utf-8?B?RzFQU1FicWJybHhxQTB4UGFsWmozNXp4MDNqTHBxdllaUzRwN0dPejQyM2lU?=
 =?utf-8?B?dkJicWcrdHNkRGg5a0owS0VxdmVRcVpEYk5TTG5yRWtMbDlHdldIMXNBWk42?=
 =?utf-8?B?MWRrQ1NTS25DRFJDY3Z0VnlZWEhVbzZlay81TXVrMGxOK0VMb001cTI2Y1lk?=
 =?utf-8?Q?T1N0H/?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 09:46:29.6973
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f472eaff-55aa-42d4-969b-08dd9c3a30cf
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A106.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB9707

When vpci fails to initialize a extended capability of device, it
just returns an error and vPCI gets disabled for the whole device.

So, add function to hide extended capability when initialization
fails. And remove the failed extended capability handler from vpci
extended capability list.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
cc: Andrew Cooper 
cc: Anthony PERARD 
cc: Michal Orzel 
cc: Jan Beulich 
cc: Julien Grall 
cc: Stefano Stabellini 
---
v4->v5 changes:
* Modify the hex digits of PCI_EXT_CAP_NEXT_MASK and PCI_EXT_CAP_NEXT to be low case.
* Rename vpci_ext_capability_mask to vpci_ext_capability_hide.

v3->v4 changes:
* Change definition of PCI_EXT_CAP_NEXT to be "#define PCI_EXT_CAP_NEXT(header) (MASK_EXTR(header, PCI_EXT_CAP_NEXT_MASK) & 0xFFCU)" to avoid redundancy.
* Modify the commit message.
* Change vpci_ext_capability_mask() to return error instead of using ASSERT.
* Set the capability ID part to be zero when we need to hide the capability of position 0x100U.
* Add check "if ( !offset )" in vpci_ext_capability_mask().

v2->v3 changes:
* Separated from the last version patch "vpci: Hide capability when it fails to initialize".
* Whole implementation changed because last version is wrong.
  This version gets target handler and previous handler from vpci->handlers, then remove the target.
* Note: a case in function vpci_ext_capability_mask() needs to be discussed,
  because it may change the offset of next capability when the offset of target
  capability is 0x100U(the first extended capability), my implementation is just to
  ignore and let hardware to handle the target capability.

v1->v2 changes:
* Removed the "priorities" of initializing capabilities since it isn't used anymore.
* Added new function vpci_capability_mask() and vpci_ext_capability_mask() to
  remove failed capability from list.
* Called vpci_make_msix_hole() in the end of init_msix().

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/vpci.c    | 100 +++++++++++++++++++++++++++++++++++--
 xen/include/xen/pci_regs.h |   5 +-
 2 files changed, 100 insertions(+), 5 deletions(-)

diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 60e7654ec377..2d4794ff3dea 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -176,6 +176,98 @@ static int vpci_capability_hide(struct pci_dev *pdev, unsigned int cap)
     return 0;
 }
 
+static struct vpci_register *vpci_get_previous_ext_cap_register(
+    struct vpci *vpci, unsigned int offset)
+{
+    uint32_t header;
+    unsigned int pos = PCI_CFG_SPACE_SIZE;
+    struct vpci_register *r;
+
+    if ( offset <= PCI_CFG_SPACE_SIZE )
+    {
+        ASSERT_UNREACHABLE();
+        return NULL;
+    }
+
+    r = vpci_get_register(vpci, pos, 4);
+    if ( !r )
+        return NULL;
+
+    header = (uint32_t)(uintptr_t)r->private;
+    pos = PCI_EXT_CAP_NEXT(header);
+    while ( pos > PCI_CFG_SPACE_SIZE && pos != offset )
+    {
+        r = vpci_get_register(vpci, pos, 4);
+        if ( !r )
+            return NULL;
+        header = (uint32_t)(uintptr_t)r->private;
+        pos = PCI_EXT_CAP_NEXT(header);
+    }
+
+    if ( pos <= PCI_CFG_SPACE_SIZE )
+        return NULL;
+
+    return r;
+}
+
+static int vpci_ext_capability_hide(struct pci_dev *pdev, unsigned int cap)
+{
+    const unsigned int offset = pci_find_ext_capability(pdev->sbdf, cap);
+    struct vpci_register *rm, *prev_r;
+    struct vpci *vpci = pdev->vpci;
+    uint32_t header, pre_header;
+
+    if ( !offset )
+    {
+        ASSERT_UNREACHABLE();
+        return 0;
+    }
+
+    spin_lock(&vpci->lock);
+    rm = vpci_get_register(vpci, offset, 4);
+    if ( !rm )
+    {
+        spin_unlock(&vpci->lock);
+        return -ENODEV;
+    }
+
+    header = (uint32_t)(uintptr_t)rm->private;
+    if ( offset == PCI_CFG_SPACE_SIZE )
+    {
+        if ( PCI_EXT_CAP_NEXT(header) <= PCI_CFG_SPACE_SIZE )
+            rm->private = (void *)(uintptr_t)0;
+        else
+            /*
+             * If this case removes target capability of position 0x100U, then
+             * it needs to move the next capability to be in position 0x100U,
+             * that would cause the offset of next capability in vpci different
+             * from the hardware, then cause error accesses, so here chooses to
+             * set the capability ID part to be zero.
+             */
+            rm->private = (void *)(uintptr_t)(header &
+                                              ~PCI_EXT_CAP_ID(header));
+
+        spin_unlock(&vpci->lock);
+        return 0;
+    }
+
+    prev_r = vpci_get_previous_ext_cap_register(vpci, offset);
+    if ( !prev_r )
+    {
+        spin_unlock(&vpci->lock);
+        return -ENODEV;
+    }
+
+    pre_header = (uint32_t)(uintptr_t)prev_r->private;
+    prev_r->private = (void *)(uintptr_t)((pre_header &
+                                           ~PCI_EXT_CAP_NEXT_MASK) |
+                                          (header & PCI_EXT_CAP_NEXT_MASK));
+    list_del(&rm->node);
+    spin_unlock(&vpci->lock);
+    xfree(rm);
+    return 0;
+}
+
 static int vpci_init_capabilities(struct pci_dev *pdev)
 {
     for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
@@ -209,11 +301,11 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
                    pdev->domain, &pdev->sbdf,
                    is_ext ? "extended" : "legacy", cap);
             if ( !is_ext )
-            {
                 rc = vpci_capability_hide(pdev, cap);
-                if ( rc )
-                    return rc;
-            }
+            else
+                rc = vpci_ext_capability_hide(pdev, cap);
+            if ( rc )
+                return rc;
         }
     }
 
diff --git a/xen/include/xen/pci_regs.h b/xen/include/xen/pci_regs.h
index 27b4f44eedf3..3b6963133dbd 100644
--- a/xen/include/xen/pci_regs.h
+++ b/xen/include/xen/pci_regs.h
@@ -448,7 +448,10 @@
 /* Extended Capabilities (PCI-X 2.0 and Express) */
 #define PCI_EXT_CAP_ID(header)		((header) & 0x0000ffff)
 #define PCI_EXT_CAP_VER(header)		(((header) >> 16) & 0xf)
-#define PCI_EXT_CAP_NEXT(header)	(((header) >> 20) & 0xffc)
+#define PCI_EXT_CAP_NEXT_MASK		0xfff00000U
+/* Bottom two bits of next capability position are reserved. */
+#define PCI_EXT_CAP_NEXT(header) \
+    (MASK_EXTR(header, PCI_EXT_CAP_NEXT_MASK) & 0xffcU)
 
 #define PCI_EXT_CAP_ID_ERR	1
 #define PCI_EXT_CAP_ID_VC	2
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon May 26 09:46:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 09:46:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997349.1378296 (Exim 4.92)
	(envelope-from )
	id 1uJUPn-0005Ws-32; Mon, 26 May 2025 09:46:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997349.1378296; Mon, 26 May 2025 09:46: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 1uJUPm-0005Wc-Vg; Mon, 26 May 2025 09:46:38 +0000
Received: by outflank-mailman (input) for mailman id 997349;
 Mon, 26 May 2025 09:46:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJUPl-0003hH-3q
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 09:46:37 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20604.outbound.protection.outlook.com
 [2a01:111:f403:2412::604])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4fbf4d14-3a16-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 11:46:36 +0200 (CEST)
Received: from BL0PR0102CA0017.prod.exchangelabs.com (2603:10b6:207:18::30) by
 PH7PR12MB8426.namprd12.prod.outlook.com (2603:10b6:510:241::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Mon, 26 May
 2025 09:46:31 +0000
Received: from BL02EPF0001A106.namprd05.prod.outlook.com
 (2603:10b6:207:18:cafe::d5) by BL0PR0102CA0017.outlook.office365.com
 (2603:10b6:207:18::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Mon,
 26 May 2025 09:46:22 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A106.mail.protection.outlook.com (10.167.241.139) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 09:46:30 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 26 May
 2025 04:46: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" 
X-Inumbo-ID: 4fbf4d14-3a16-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JJ8Esg4i7wvHMrzqORg86Mh9U0IN2HBwdlNGfqbS3XtoIULUBFw8t9fjUm9hWqMs1SplsSk0W2/hx88ZthdLd+ygwxpK15LxNEx6HjwNZfI1RKLblE6XR5DB9vXJ/tAhRV/dcAXZIUSYOBKjXdf5zEwzkfKiCW7tGGduz+rZdfNUFxUj209FMNJWFtP4+NNa1P9i5BCO+pFPdKpzE1SM925vL1rIU5lWAsF1zqASdlk1soKsMzrgVGHJEJsRuQHYwLqTcfZxqi8tp6/fQ+7bx7sUC9iHDciVowEUrrSXH/6WsiqMRsJLDpg6Er9RTl/7iUP3Gb63/V6MIOkATLCzLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=K+CghjyF0DfUwZBc7m8sGLxK/5lEr3a3ULjAAbU6V14=;
 b=AhD61NMgmWkvzoegxQX7NPI4cDqz09GTXuDPg49+UGImRMufmSeoNGzSlR5VxHlgBy47+ld+JjPVJXYjgwicg+UY3EqPT3P69Pa0kLRz/CLNhWXnZnE9YH+2X/87Ad6UQd1PKcyWuCbUgr+f5bWcwjre9ibvHkAabOwJ5ALZ0A5rvtsWNqY2Silcyq+owyDIb9RDYJFTSFHR9fs0PdL32fq0GWUxHaAfPuglvHmm3LUuHJRQFJjthIY3X39ENzxbsf77X0Ms+Kmy2r27s2Ou35evYnKKYx72zKHVOCqIm0wQzlI6U90eWpZkSEGIy+usFdWNuuvzD8Ff6LUre4kGew==
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=K+CghjyF0DfUwZBc7m8sGLxK/5lEr3a3ULjAAbU6V14=;
 b=aJL7pNmGIoVNvSrwmK6b4lTMpgzDKDw0jGr338ihcwr/K0BSkaFzsCYK/ZyhfuxUZ/VIrLqBLnVzddlP88rblO0VCQdT60h25UaQAN/X2U3YC7alAUwSdKnmIM4TPQvXFMVDyh9zf+P6gIcqu2VB5U6Wpyuy6N5snKbYXjIu7zU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	
Subject: [PATCH v5 07/10] vpci: Refactor vpci_remove_register to remove matched registers
Date: Mon, 26 May 2025 17:45:56 +0800
Message-ID: <20250526094559.140423-8-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250526094559.140423-1-Jiqian.Chen@amd.com>
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A106:EE_|PH7PR12MB8426:EE_
X-MS-Office365-Filtering-Correlation-Id: 589ce9b0-eea3-4ff4-0fd1-08dd9c3a3166
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TDdYNHk5ek1KWnFEZGJTdmVjSU5KSjdVdGtFVkpBN3E5VEpPYTRDNTJkWUpt?=
 =?utf-8?B?bWxFWWdCRUplNUxLcTdxVC85MUxmaDhUSW9td0syaWYzeW5TVE5EVnM1ODc2?=
 =?utf-8?B?aGQyaUt1SVM0OHFNZ2p1NzNqdnB2TUVLbHFiNTJiTlpFN2gxdWpkWnZiQ2pI?=
 =?utf-8?B?RldBdDZrdUo4S0VzemcvZUtiV1NKWTlFdFJkam5hMjZ5Nm1QSFlTTGpTZXVN?=
 =?utf-8?B?VTN4T2hHMlRNQ2pOTC9tSTFrU24xRUYzRDNOSVNRUFZtTlhPbkpWVzJQWXRE?=
 =?utf-8?B?aXNjbGZobnFKWWRkOHREYjdoZmllWDJlWnJZT0FDQWorcGV4dlR2RUVqekl1?=
 =?utf-8?B?OStHaWU2VklERW1lRXVUQWZBazJFTGtUNUlmd1NnS0plejVCTWF2cklqTFd6?=
 =?utf-8?B?dVdPVDVlVG13dmNCNTNUS2d5YWZVeXBFNTUwc0puWTRMVkd0VWJEeUw0VzJP?=
 =?utf-8?B?Z0x5dHluMmRkaEZiZG1FSlFWWkFqa0d5V2dTMWNUTGM4K1p0NmZrcyt6SHBY?=
 =?utf-8?B?UlJ0UmlRQ0cwWVVJUWlwNkMvQThodEc3R3ZhL1NWWm9wODJrazNIVUViTCt3?=
 =?utf-8?B?aDhBamdRUGhISVFwTGs4anVyWDlwMWt6Y045RjNFbWU5ZjliSVd4d0dNcDg4?=
 =?utf-8?B?OCtrSzZyL2dSYTkyNkIveTJ5bnZ4dUZkNHpjUk83RlhMNkJrQjA0eXRQMldK?=
 =?utf-8?B?bzhXNWdIWTVNaUNFUmRVMXBSS3JJQkpmRmJWdXZpcUl4U3JhMDhPM1dxOFBi?=
 =?utf-8?B?TjVaSlZqZGlCRlA3VEloMmc0ekZCR0NwbE5JRjhZcXk0NmJhWUpRekNUK2JG?=
 =?utf-8?B?ZE4wZzZDRUlFTU5LT1NKNzYxQ2lndXA0dmJDSENPK1htS1FsY2RKTHUzV0My?=
 =?utf-8?B?bVd3S0VLU0VURFFpTEtBU2J0Z0ROSDdmRm5PWlI5Mkw1N1A1dzNRcVF3YjU5?=
 =?utf-8?B?TWYxbkJnZWdyckRHeVJINE5Sd1RBYWpFYklaeUVySkVYMmlCYjloYUlESmdE?=
 =?utf-8?B?cHRZL3J4ZkRBOXJKaEwzYk9UNXArMFJkbThMS2dYd09iUXhKOEg4bW1pUUZ4?=
 =?utf-8?B?K094ejFiRnlYeXNMb0tpUWRTNHhzZXlYUDJnbVJQMldoYUZZU1hrcmpYYnJv?=
 =?utf-8?B?RnFOQWp2NXR1MnVMUEZjOTJOd3VXaldhSUJYaDFSbTluU2ExazJaQXIzWFZT?=
 =?utf-8?B?SmVYdURzcGpTWWxPM2hKZkdLTG56UkM3ckswRzVLb3Jycm1TK0JFMmc4cjEr?=
 =?utf-8?B?VTc0diszTmk1U2pjbnBQL0pqeWFoNnUwTm9jUFRhSTR6cFVCSGZGM3c3am1y?=
 =?utf-8?B?Zyt2a0w4RWZ2dklRc08xOWFCSGl0aWJld3lPL25qZGx0dzJJckp0aFVVTmJp?=
 =?utf-8?B?bUZteHFrWkF2MlNCL2RScGdWMDZJejdvMXAvZEZQdm03UGQxc01JSXdCRDh0?=
 =?utf-8?B?WmxBVitsZUw3RDZxTmVYQWRPWUIvRmdvbGhIRTVHZzFPQzIzbjNWcWNlY1dR?=
 =?utf-8?B?MTN0ZkxxUGR2aDlZQVk2U2cybGRLa1lnZzBtNXFSQTZqVnVQOHljU2l2ZFRj?=
 =?utf-8?B?dlcralRPQXR1L3h6RjdQTFVTUXNDUWFwRzVtNEJudnVSQkdZclFvRVZ0VmMz?=
 =?utf-8?B?d1Uzb1E3RXE5OElKQlF6L1VnWnFjeGRCK3pWTmQxVVdhamlpN2tHbkJJWDFl?=
 =?utf-8?B?Y2E5a2UzZlBpbTdJOERFaDl5YkNNQ3JkbkJxMFdHMmI3VW1BM0lmbmV2Vkh5?=
 =?utf-8?B?aHY1OWtxNW5YYzc0eWtlWHRBZ3lvanhJWlBFNnRwSEJSTjU0WlBwS1pIWnBX?=
 =?utf-8?B?VjdmMVdvWEtHWGxRblZFbTlrTG1LQ20zQ0xjaHdKWHp2OEVpc1h2c3hmUEtv?=
 =?utf-8?B?dHlkQWo2RElYZnZYdVdPQkxjUEVEMzMwNDVLa0pCSGpQbTBXdHpCTjJBbkRS?=
 =?utf-8?B?V3dHNGVXMkVQR1hIN0EwNDFXZUM2SmN1em1mRXNpM0F2N3hpOVZWcEZKc3g4?=
 =?utf-8?B?VmVnRzBoQ3NGRVUyN3pkT3lPR2crWHhTYjZrQlRGd1pMYW5qVmhtSzBtanVv?=
 =?utf-8?Q?Me0ufd?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 09:46:30.6831
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 589ce9b0-eea3-4ff4-0fd1-08dd9c3a3166
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A106.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB8426

vpci_remove_register() only supports removing a register in a time,
but the follow-on changes need to remove all registers within a range.
So, refactor it to support removing all matched registers in a calling
time.

And it is no matter to remove a non exist register, so remove the
__must_check prefix.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
cc: Anthony PERARD 
---
v4->v5 changes:
No.

v3->v4 changes:
* Use list_for_each_entry_safe instead of list_for_each_entry.
* Return ERANGE if overlap.

v2->v3 changes:
* Add new check to return error if registers overlap but not inside range.

v1->v2 changes:
new patch

Best regards,
Jiqian Chen.
---
 tools/tests/vpci/main.c |  4 ++--
 xen/drivers/vpci/vpci.c | 38 ++++++++++++++++++++------------------
 xen/include/xen/vpci.h  |  4 ++--
 3 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/tools/tests/vpci/main.c b/tools/tests/vpci/main.c
index 33223db3eb77..ca72877d60cd 100644
--- a/tools/tests/vpci/main.c
+++ b/tools/tests/vpci/main.c
@@ -132,10 +132,10 @@ static void vpci_write32_mask(const struct pci_dev *pdev, unsigned int reg,
                                   rsvdz_mask))
 
 #define VPCI_REMOVE_REG(off, size)                                          \
-    assert(!vpci_remove_register(test_pdev.vpci, off, size))
+    assert(!vpci_remove_registers(test_pdev.vpci, off, size))
 
 #define VPCI_REMOVE_INVALID_REG(off, size)                                  \
-    assert(vpci_remove_register(test_pdev.vpci, off, size))
+    assert(vpci_remove_registers(test_pdev.vpci, off, size))
 
 /* Read a 32b register using all possible sizes. */
 void multiread4_check(unsigned int reg, uint32_t val)
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 2d4794ff3dea..d3e9a76d0cf6 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -163,7 +163,7 @@ static int vpci_capability_hide(struct pci_dev *pdev, unsigned int cap)
 
     prev_next_r->private = next_r->private;
     /*
-     * Not calling vpci_remove_register() here is to avoid redoing
+     * Not calling vpci_remove_registers() here is to avoid redoing
      * the register search
      */
     list_del(&next_r->node);
@@ -171,7 +171,7 @@ static int vpci_capability_hide(struct pci_dev *pdev, unsigned int cap)
     xfree(next_r);
 
     if ( !is_hardware_domain(pdev->domain) )
-        return vpci_remove_register(vpci, offset + PCI_CAP_LIST_ID, 1);
+        return vpci_remove_registers(vpci, offset + PCI_CAP_LIST_ID, 1);
 
     return 0;
 }
@@ -561,34 +561,36 @@ int vpci_add_register_mask(struct vpci *vpci, vpci_read_t *read_handler,
     return 0;
 }
 
-int vpci_remove_register(struct vpci *vpci, unsigned int offset,
-                         unsigned int size)
+int vpci_remove_registers(struct vpci *vpci, unsigned int start,
+                          unsigned int size)
 {
-    const struct vpci_register r = { .offset = offset, .size = size };
-    struct vpci_register *rm;
+    struct vpci_register *rm, *tmp;
+    unsigned int end = start + size;
 
     spin_lock(&vpci->lock);
-    list_for_each_entry ( rm, &vpci->handlers, node )
+    list_for_each_entry_safe ( rm, tmp, &vpci->handlers, node )
     {
-        int cmp = vpci_register_cmp(&r, rm);
-
-        /*
-         * NB: do not use a switch so that we can use break to
-         * get out of the list loop earlier if required.
-         */
-        if ( !cmp && rm->offset == offset && rm->size == size )
+        /* Remove rm if rm is inside the range. */
+        if ( rm->offset >= start && rm->offset + rm->size <= end )
         {
             list_del(&rm->node);
-            spin_unlock(&vpci->lock);
             xfree(rm);
-            return 0;
+            continue;
         }
-        if ( cmp <= 0 )
+
+        /* Return error if registers overlap but not inside. */
+        if ( rm->offset + rm->size > start && rm->offset < end )
+        {
+            spin_unlock(&vpci->lock);
+            return -ERANGE;
+        }
+
+        if ( start < rm->offset )
             break;
     }
     spin_unlock(&vpci->lock);
 
-    return -ENOENT;
+    return 0;
 }
 
 /* Wrappers for performing reads/writes to the underlying hardware. */
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index e5e3f23ca39c..67a831d8e9a0 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -71,8 +71,8 @@ static inline int __must_check vpci_add_register(struct vpci *vpci,
                                   size, data, 0, 0, 0, 0);
 }
 
-int __must_check vpci_remove_register(struct vpci *vpci, unsigned int offset,
-                                      unsigned int size);
+int vpci_remove_registers(struct vpci *vpci, unsigned int start,
+                          unsigned int size);
 
 /* Generic read/write handlers for the PCI config space. */
 uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon May 26 09:46:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 09:46:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997350.1378306 (Exim 4.92)
	(envelope-from )
	id 1uJUPo-0005nj-Hx; Mon, 26 May 2025 09:46:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997350.1378306; Mon, 26 May 2025 09:46: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 1uJUPo-0005ms-BT; Mon, 26 May 2025 09:46:40 +0000
Received: by outflank-mailman (input) for mailman id 997350;
 Mon, 26 May 2025 09:46:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJUPm-0003hH-48
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 09:46:38 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2407::61c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5074f9b2-3a16-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 11:46:37 +0200 (CEST)
Received: from MN2PR13CA0028.namprd13.prod.outlook.com (2603:10b6:208:160::41)
 by MW3PR12MB4427.namprd12.prod.outlook.com (2603:10b6:303:52::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.20; Mon, 26 May
 2025 09:46:32 +0000
Received: from BL02EPF0001A105.namprd05.prod.outlook.com
 (2603:10b6:208:160:cafe::c) by MN2PR13CA0028.outlook.office365.com
 (2603:10b6:208:160::41) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.15 via Frontend Transport; Mon,
 26 May 2025 09:46:31 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A105.mail.protection.outlook.com (10.167.241.137) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 09:46:31 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 26 May
 2025 04:46: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" 
X-Inumbo-ID: 5074f9b2-3a16-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ikcbm6HD4qH2L/2d2H/bs2mbVHQHqBqSomNiMa0xrMUwtQ9Fpwrd1O5HBvxJpK/e4B9k207vuiMHdMsAhisqqCqw34gKEj48igtx9ZgnhfBoJCNCejYJhlRqtuVNHrhuLOLK7IUCfosVf6Md++PwgsGwJiE01By/3NN7uL9EhC67qZ6+oOGLZEXshxraHBR+btZbLd4WOUrxW6fAog3fBjbb41v1Ykq6ipZtoQMsIAQhJTcv3r9BKdR6LHqk8qz6Bd8Ozmc2q8ONpMS7cTt+kmw5pYqnsmNTwLRQW2msGG+8zLrHlvxVX7haqvUWXiTOJXPNqSeeZ2JFRfua6C84oQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fd0GbwbRrEi2YvKEmsoXyPAhLSxsOxC7xEEZ+gZkL0U=;
 b=F4pwAjSxYDA0Vz/kwj/WR+cvsAHb/isYncvU/cVz546pkb6udP1btDSyUmnYP/xM1Gxo7Uhklv/4nOlSWwfVS5o/5bx8CAigdkzobbard50CaEFcF9a1iIeBYi5PjJkyVMqU6+Z+X12TjcRdaXpAiTwqc38p8ELCR/JCvMdEaA8AArMNibdmeFdJkA1z9L+vjWgh+dhuMRgee4YybQkcPd3bbJlXuD0hQoqUlOpfaZJsJDFBYE4yLKxf5GVhgrpw9ALXiGNo7OiiJXYDviZZq0jYw/sMCsV4OXOVe3ejc3rCL1MJpWaOI45SVbjACscNprlm4XrC5JZiINLsThMyQw==
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=fd0GbwbRrEi2YvKEmsoXyPAhLSxsOxC7xEEZ+gZkL0U=;
 b=RwCt7JSIapsW4Kdmhj4iZAEAPD+vuIAD5PHcEGEdR0iP071zx7YtpwPKO4hz4ssKWRHOP3NoaEMAQSERRK9jmAfblgJMslu31/KG8zfnggVeeNUns3xl+N3vAFZqHak6WID6rLbKhKm40X1JJ2TN/lz8lsR3aLF1QV0Y5tRleT4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 08/10] vpci/rebar: Free Rebar resources when init_rebar() fails
Date: Mon, 26 May 2025 17:45:57 +0800
Message-ID: <20250526094559.140423-9-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250526094559.140423-1-Jiqian.Chen@amd.com>
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A105:EE_|MW3PR12MB4427:EE_
X-MS-Office365-Filtering-Correlation-Id: 1362b4e4-b37d-4666-54e6-08dd9c3a321f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RFV5aU5HcEtiWjFEQ0RSM2VrU29iSjM4U055VjM4SWpCU0JMbFVCRU9RL3lv?=
 =?utf-8?B?eGVsOVVJVDdmU3VRb1IwMkh6cGM0TSt6dGFaQU5FZ1F2UVVYZ3VlOFlNNDZT?=
 =?utf-8?B?OEZnRUZtZm44Z3JWY1h3cWgyVHJiL3hyN2xOTFByN0FtUi9Hb045WS9EQUl2?=
 =?utf-8?B?ZFdyUVZSMzBoUnBrekQwSjNmQnVGdGkvdjNhR0F2UXIrMHowZ05jQWh1VlhQ?=
 =?utf-8?B?N0tTWTljZHd4UjR2RHpabUdGVmcxRHZ0TXZXdFhzMnNuUGprVm5kOXBMR2M4?=
 =?utf-8?B?NWxac1hDaVFjVUlCUWNPa3A0WG9xRTFTNEhTWHJNeHRWSzh4TW5wVnBDTUtZ?=
 =?utf-8?B?OEY3UDF1NTRHZzZPV290RTR5Nk5pVGhiWnZWd2ZhRjc3NUNsd2owcU84SGE3?=
 =?utf-8?B?a1prZk1ISjlXRkFFOVJiYXNobVNxcUR3U0VjcVlVbkVpQ0x1UHVNNlRscmN0?=
 =?utf-8?B?TTk4UE1YWDN5QmZoNWZhTnQ4bitZSXJZU0p0bUpyb3VzS0w1Q2J3OS9MUnFG?=
 =?utf-8?B?RkpOdmdCQUo3alAxaGwwWTh6ZHhLOVI5TmpHMG9LR1ErcWxIT0VJaWdSZUF1?=
 =?utf-8?B?NGRxTEpQakgzWW8wS2VQeTdXOGRuNHVKOEJkL1R1NUpOdVJYNGFOWFBHOXBC?=
 =?utf-8?B?cysvd1Z5cFJqOFVmUzFUWUhld0k3SHNyb1BldWVIOWdjVkdCN25WazllMzdH?=
 =?utf-8?B?M2hDOFFOYXBqNUlWQnZadTFjN2FVNHI2V1JSWmFBRUl6VTVzb0RFa01na2lB?=
 =?utf-8?B?YTVGSGt0ZHhyN0lpUW8zdllKRWFXL2tKQ2hZdUJOa0lzOXNwN2dmRG9mUHJR?=
 =?utf-8?B?aCtMRFUxampNNDBTVmdpb05ob2JzcUU0aWVWanZYbVhhN3JSWkowUHoweVZk?=
 =?utf-8?B?b3JEbml0bjNpNjZCb2dPSVN5YzFsdmhuOUhKREQzR0x6TEplNXlkNEZKczdW?=
 =?utf-8?B?ZWFpeTBCTWtKaEFjeDZVSVVXZ0UzZVd3eEZYN1JmNTZJbHZyeDNYMENwbHk2?=
 =?utf-8?B?NDhXQ000akpjTjZ2Mjg0RVFnQ3VhbUxrNDhxelNRNk5zOThzc1hxWmpBQk1P?=
 =?utf-8?B?NXRwOTE0UlFTVmhHKzI3ekhLaEUveDRRQ0ZMVVNNbTIzZWtRQjd5UTNWbDZV?=
 =?utf-8?B?M09xNkdzenJEak9VV1VHVTRjT0h3RDhsanJURDlKMUpXNTMzK1I1V0IyUzlE?=
 =?utf-8?B?RmM5ZTVBNjJaSWpnMVZaVWJoUmQxdDdMeEtTZUVQbGgyOGI5eHZnSGQvbE5l?=
 =?utf-8?B?cDROSWV0czZXMmtLa0g5YTdCd2U3RVFRR0Jod0hJb3l5STZNeVpvTGtCRmta?=
 =?utf-8?B?QitLTGllSEM0WmhNMFhtYlhsK3BOZ2ptTmxMMjc2eDU5bUlDOCtjMytKeGNo?=
 =?utf-8?B?SENQN2tFa0dNanFtWlg1dWllMU1zcmZxSWtNVW56NlNXQWsyR3BGOFN3Umdq?=
 =?utf-8?B?WUdoWDd0dzBhWDA0TkRmNWUvTktDQy9XeHRuTGxrMmhXMDVLMlo3N3VuWGZv?=
 =?utf-8?B?NnNSK24wSHN6dDZsRGFLT3lVL3NhbFhPb0I2SHdncjkyZjhVZGRvYXhKdEcz?=
 =?utf-8?B?ZEZUOTNKSkJtRTU5WCtWNEVKM212M2MvTzkwb2JldkszM0Y2cW1nLzBJaENM?=
 =?utf-8?B?U21BRno5Zmpxazd4Ylg1em96UzdyUWtzUURVKzgwWHg1aG5hY0dEaEp2VEJv?=
 =?utf-8?B?dDdlamhsS1lRakYram1BZlJWWkw0VzJwMjZNUU5QTU5DZ2NwdjV4Q2dqQURB?=
 =?utf-8?B?Ui85Y2ZUSzJKSEE3Zk1DYzNxT2hkcjhVNUxvUFRGbWwyMUVwS084M2RDV2Iz?=
 =?utf-8?B?dGptV2VWb0JyYjFoQUd1azZGRU9PdjR4bjVQUEJnczRPOFVkNkt3NmVXbDNS?=
 =?utf-8?B?MkxNUDY3aXUzcnZrV0dpQ3dVaXA1QWdtem8yUnlrR1BDL1dDbEMweER3NWQ3?=
 =?utf-8?B?bGZJdHpvcFR1NnZWWk5VVWhSY0JYVEdZdVFiMW9uOVdnaVpnZm54bEFWVElz?=
 =?utf-8?B?SUI2dHk5QkJ6WjU5VENRd01LcjBEN1RlQW9uSnZIeUN5b1VSdnV3cjV1RmpX?=
 =?utf-8?Q?yqM9Vr?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 09:46:31.8988
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1362b4e4-b37d-4666-54e6-08dd9c3a321f
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A105.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4427

When init_rebar() fails, current logic return fail and free Rebar-related
resources in vpci_deassign_device(). But the previous new changes will
hide Rebar capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed in cleanup function of Rebar.

To do that, implement cleanup function for Rebar.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v4->v5 changes:
* Change definition "static void cleanup_rebar" to "static int cf_check cleanup_rebar" since cleanup hook is changed to be int.

v3->v4 changes:
* Change function name from fini_rebar() to cleanup_rebar().
* Change the error number to be E2BIG and ENXIO in init_rebar().

v2->v3 changes:
* Use fini_rebar() to remove all register instead of in the failure path of init_rebar();

v1->v2 changes:
* Called vpci_remove_registers() to remove all possible registered registers instead of using a array to record all registered register.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/rebar.c | 35 ++++++++++++++++++++++++-----------
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
index 9cafd80ca2c9..4b1892fab3d6 100644
--- a/xen/drivers/vpci/rebar.c
+++ b/xen/drivers/vpci/rebar.c
@@ -49,6 +49,26 @@ static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
     bar->guest_addr = bar->addr;
 }
 
+static int cf_check cleanup_rebar(struct pci_dev *pdev)
+{
+    uint32_t ctrl;
+    unsigned int nbars;
+    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
+                                                        PCI_EXT_CAP_ID_REBAR);
+
+    if ( !rebar_offset || !is_hardware_domain(pdev->domain) )
+    {
+        ASSERT_UNREACHABLE();
+        return 0;
+    }
+
+    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
+    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
+
+    return vpci_remove_registers(pdev->vpci, rebar_offset + PCI_REBAR_CAP(0),
+                                 PCI_REBAR_CTRL(nbars - 1));
+}
+
 static int cf_check init_rebar(struct pci_dev *pdev)
 {
     uint32_t ctrl;
@@ -80,7 +100,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
         {
             printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
                    pdev->domain, &pdev->sbdf, index);
-            continue;
+            return -E2BIG;
         }
 
         bar = &pdev->vpci->header.bars[index];
@@ -88,7 +108,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
         {
             printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
                    pdev->domain, &pdev->sbdf, index);
-            continue;
+            return -ENXIO;
         }
 
         rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
@@ -97,14 +117,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
         {
             printk(XENLOG_ERR "%pd %pp: BAR%u fail to add reg of REBAR_CTRL rc=%d\n",
                    pdev->domain, &pdev->sbdf, index, rc);
-            /*
-             * Ideally we would hide the ReBar capability on error, but code
-             * for doing so still needs to be written. Use continue instead
-             * to keep any already setup register hooks, as returning an
-             * error will cause the hardware domain to get unmediated access
-             * to all device registers.
-             */
-            continue;
+            return rc;
         }
 
         bar->resizable_sizes =
@@ -118,7 +131,7 @@ static int cf_check init_rebar(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_EXTCAP(PCI_EXT_CAP_ID_REBAR, init_rebar, NULL);
+REGISTER_VPCI_EXTCAP(PCI_EXT_CAP_ID_REBAR, init_rebar, cleanup_rebar);
 
 /*
  * Local variables:
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon May 26 09:46:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 09:46:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997352.1378310 (Exim 4.92)
	(envelope-from )
	id 1uJUPp-0005xH-9w; Mon, 26 May 2025 09:46:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997352.1378310; Mon, 26 May 2025 09:46: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 1uJUPp-0005wE-3F; Mon, 26 May 2025 09:46:41 +0000
Received: by outflank-mailman (input) for mailman id 997352;
 Mon, 26 May 2025 09:46:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJUPn-0003hH-48
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 09:46:39 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20617.outbound.protection.outlook.com
 [2a01:111:f403:2415::617])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5091a631-3a16-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 11:46:37 +0200 (CEST)
Received: from BL1PR13CA0181.namprd13.prod.outlook.com (2603:10b6:208:2be::6)
 by IA0PR12MB8279.namprd12.prod.outlook.com (2603:10b6:208:40c::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.25; Mon, 26 May
 2025 09:46:33 +0000
Received: from BL02EPF0001A107.namprd05.prod.outlook.com
 (2603:10b6:208:2be:cafe::6c) by BL1PR13CA0181.outlook.office365.com
 (2603:10b6:208:2be::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Mon,
 26 May 2025 09:46:33 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A107.mail.protection.outlook.com (10.167.241.136) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 09:46:33 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 26 May
 2025 04:46: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" 
X-Inumbo-ID: 5091a631-3a16-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tq1kJrnr/fvzqqisowZKymlNS2/GoPbzezudxgpFD+jNGFvd5rNS3Wxow27lLS9wc9gfVTsrz1y6c1URbpRwCxb71yiCqKdAOJAhB7j6VMfeDWmsH/VmFjmYcMy6SzuomsR6/9r+a83EfBzF2vpyjxrCtXYf4/Zfd02XO+BT/2hZ5OymQtAOoz4bmW3b6perZV9To7EbQKHEjzZ2vkJN/6FSxwV6NQkT5m/+GX67LwKVyFQcc58FRVv3fgK6H5e9dyJgaJQF8wHXlEzS6a/IgWrsTNEIfKuL3lyUBkCmgBYz14zBuIvizMLyIVBgu1fI5Lk5qEt4ShKu8BawykXxMw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8aE/xhQc1ScjD8FKImKyyPi2cNcNucokrC3sZcN9VTw=;
 b=KEBZOc7AOiLriDlJPOLVXx7f5wfrWHX7/kSI5t7WHx+EqyJUr8OkxuMc33WXGi2xngMuPz4OlmOwZrC917EtJnnV0zVJNLpaxNL9hGXXI7stTjEJkMMvsxx0NNzYRfnAxr919CFS7pcA5yOTKnYPcR5D0el6sUC5SCtVizTUFV1OjWE37lPE+NYG3846zlh+WOmVMHBB0FqSduj0kQVgZZYGUoIANKo4c+KBkE2oVK8PkK6qcGYEUJR7Mtj73ERgPe6fa8oPBdjlHUnKmbIHv+D8xjy1Uc3BrwZlEocXqgjHHSctxFID+Ek1ob2PSbLk0Xy/a8plDh4fp1z44dUSnA==
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=8aE/xhQc1ScjD8FKImKyyPi2cNcNucokrC3sZcN9VTw=;
 b=cIakaQFL8jpEI8ibgtzEkWtOy0QBXReimvA6eU6NJ6Lcgu12y716Z5y4EOFz//IcsG8vm6p43fsRWxwud1ZwsdArpbB/rKX5nLZS9SgZOB6hlnlvzhdevCYRc11GKj1uvyuV7IHDK09Anjkwgkk29Ba3oJXz/foGL4KFYYcKyy0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 09/10] vpci/msi: Free MSI resources when init_msi() fails
Date: Mon, 26 May 2025 17:45:58 +0800
Message-ID: <20250526094559.140423-10-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250526094559.140423-1-Jiqian.Chen@amd.com>
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A107:EE_|IA0PR12MB8279:EE_
X-MS-Office365-Filtering-Correlation-Id: 135ec16f-577d-4648-bb7b-08dd9c3a3317
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dlJqa0F3T0pnYXBPRDdtajdOeUsxRUpnRjBCekVzTmo2cks2UEVjUFlQcmtr?=
 =?utf-8?B?SWw1QmdEcTMxWGZiU2JkMG5RYlp6c2FSOFVvWFMwNktiUGxXM0JEaFA4R0xZ?=
 =?utf-8?B?aUd3Zk1BNWEzc1ZNbUl2ZFc2anlKRnBFaFlISmpFR1lycnZYK0wrZUNLcXRX?=
 =?utf-8?B?N2MzZDdlY213ZFQ4eE4rOVIvSkNXN1ZMLzAxQ2tkY3p0eW56K2dDZ1NKMTV4?=
 =?utf-8?B?VnBOV2lKK056dGZDaWZlRWIyUW9BVnFLendRSm11OXQzb254Q1NLeEVGeHNr?=
 =?utf-8?B?eUczVExacXE2MXltVkVvVkpXeDdLOEFuQmdKeGl3NnZxU2hOYmwwSkg1R2p1?=
 =?utf-8?B?SjBjZjQrRzQ2VFlmY0ZjeVpMSHpGYmtSWG9jalNOWTQwVW9BaExRVGZxUEUy?=
 =?utf-8?B?dXJHZDE2emdFR0dxRWg1aStZaEhzUERmQUluUzJIcUhsUjcxWVJqbzE2TWRS?=
 =?utf-8?B?OE13R0dxQWF4T0hqZ2dMU2wvQ0hibFVDdzVjU0NyRHh1K0lZVCtTKzA2TFBk?=
 =?utf-8?B?SGVxcXdNKzh3eHgxWXQwa2ZqM3RnTFpVQU9sQ2tGNjdKTGFpZE5aQUI4U1dh?=
 =?utf-8?B?ZGJ4OE5XV01jL1hvZG5vNXAwb0lKZGRiclFRNUYyb1VmdVRNTm1aa0NrSHBR?=
 =?utf-8?B?b3NiV3hkRHNZL2hKdzcvaWp5cDdBN1ZacUJTcGpsakVSS1crbFp6b0RFU1JG?=
 =?utf-8?B?MFk2OWlZSm5wTHI0ekhPbmxJblNVeWZKajYyT3JUdC9IN0xtZHBxSmhpcXcy?=
 =?utf-8?B?YUw5OWFrWVQxdzBDa2RLVUhrTldyU3Zwek9PdnZsd2o2OVB3b3E5WnZiT3JX?=
 =?utf-8?B?OGxZWjgva1MrRFVJQVVROUc0c2pnMDhRWm4rNnhRclF3dXBVcmMxVjFMVk4v?=
 =?utf-8?B?S2lqdmpzRkF3dU9LMDBHWldQWWhQWFkzMzFJSkpSZHRaMHRRNHlMNVFoNTZP?=
 =?utf-8?B?YVRHdlFZSVRTN0FTdFY5WlBuZWh6VmZjcDFjQzFxM211YVh4bTF6d2hqYWh2?=
 =?utf-8?B?UHRBRWVOOVhLR0dNM1FyajlPYTVJYjNocys0QWJDNFZ4NE9RNDc1VkFxV3F1?=
 =?utf-8?B?Z3d1TldzNG1DdmF3WDFUWFlIUVEwZ051NGFxR2FTVHlWWisyTS9ndzVzN01y?=
 =?utf-8?B?aGwxV0daL3U4aXJPUDZ0MG9jaFY5Z3RZQi9XeWJKVU1TMUorT0grQUh5TFlT?=
 =?utf-8?B?VjJCNGlRRDFMYkV1NXZqdGorZjhGWlZUS0NoMUU2anBTTTI4eFlxMUpKUi9Z?=
 =?utf-8?B?TEVEb25LbFUxdFJEaGNsQVBzc2V2U2I5NWFzTEZHWXJTUG1GOENpbDMwYU42?=
 =?utf-8?B?c2Jud1ErQTFsNlBsZ3B5UFlsZlU4Q3F4cnJhNDlTcjFzbUdEZ3hyanA5Ykxl?=
 =?utf-8?B?SlZvd25za1dBMzc3RjFMUzA4OVd6UUJiWDMyc0NMY2orU3g4cjk5RGNRT3Vj?=
 =?utf-8?B?WjlpOE83blhVRE9qTWNqLzY3dTI0eForWE83Y1M3c1J1N3dHK3AvR0UwZTY5?=
 =?utf-8?B?cGo3RkVGN0Q1OUFFODN5TmZPR1VoemJLdkNSbVQ2Q0xIcEFFRStKZTB4ZTZ2?=
 =?utf-8?B?eVREZnR6WXdrS0w4MDZQd1NWcnk4NHNPT05FVnFqME8yTjRvQktNM2RydzZp?=
 =?utf-8?B?ZTJLU1NuZ3NZMzg0ejNLTm5reUlqRUZBY2J5VmhqUUp6RTlCQ0pwMUVxa1FP?=
 =?utf-8?B?dU1yVVhEeHZiUUdaYUJ0VHZVdUpHbkFDVnNvc0lTZEtoNmJxLzB0cG1ZL21p?=
 =?utf-8?B?VFB3emk4bkh1aEtDQVVTaEUydkYvTWIvRi9ISXFsTFY0a3g1SFRVVlh4UVVW?=
 =?utf-8?B?eEpCS2pGQk9ReHA4YmdpVXlDemg5Qm00NkRwcFpyRG04TmdQVnFSYkJUMXFn?=
 =?utf-8?B?VHFTU0FXbURvYmZmbEhvQng0ZDhpK2Eyc3NCY29tTFhsbHcxaDBrcllFdmxu?=
 =?utf-8?B?UG0rNkh2bzF2Z3I5bU53U1pLSjRMOXFXeTkvdFFxVjhZT0Nvd1hSbTRwdWFW?=
 =?utf-8?B?ODBPbXphVExGRHVucWdURms1U09yUEowOXJvaUNEMXljL29QZU02K3pNbGJp?=
 =?utf-8?Q?dNDChj?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 09:46:33.5274
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 135ec16f-577d-4648-bb7b-08dd9c3a3317
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A107.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8279

When init_msi() fails, current logic return fail and free MSI-related
resources in vpci_deassign_device(). But the previous new changes will
hide MSI capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed in cleanup function of MSI.

To do that, implement cleanup function for MSI.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v4->v5 changes:
* Change definition "static void cleanup_msi" to "static int cf_check cleanup_msi" since cleanup hook is changed to be int.
* Add a read-only register for MSI Control Register in the end of cleanup_msi.

v3->v4 changes:
* Change function name from fini_msi() to cleanup_msi().
* Remove unnecessary comment.
* Change to use XFREE to free vpci->msi.

v2->v3 changes:
* Remove all fail path, and use fini_msi() hook instead.
* Change the method to calculating the size of msi registers.

v1->v2 changes:
* Added a new function fini_msi to free all MSI resources instead of using an array to record registered registers.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/msi.c | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index 2d45c7867de7..4e106c39efae 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -193,6 +193,33 @@ static void cf_check mask_write(
     msi->mask = val;
 }
 
+static int cf_check cleanup_msi(struct pci_dev *pdev)
+{
+    int rc;
+    unsigned int end, size;
+    struct vpci *vpci = pdev->vpci;
+    const unsigned int msi_pos = pdev->msi_pos;
+    const unsigned int ctrl = msi_control_reg(msi_pos);
+
+    if ( !msi_pos || !vpci->msi )
+        return 0;
+
+    if ( vpci->msi->masking )
+        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
+    else
+        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
+
+    size = end - ctrl;
+
+    rc = vpci_remove_registers(vpci, ctrl, size);
+    if ( rc )
+        return rc;
+
+    XFREE(vpci->msi);
+
+    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);
+}
+
 static int cf_check init_msi(struct pci_dev *pdev)
 {
     unsigned int pos = pdev->msi_pos;
@@ -270,7 +297,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
 
     return 0;
 }
-REGISTER_VPCI_CAP(PCI_CAP_ID_MSI, init_msi, NULL);
+REGISTER_VPCI_CAP(PCI_CAP_ID_MSI, init_msi, cleanup_msi);
 
 void vpci_dump_msi(void)
 {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon May 26 09:46:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 09:46:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997354.1378324 (Exim 4.92)
	(envelope-from )
	id 1uJUPq-0006LB-VB; Mon, 26 May 2025 09:46:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997354.1378324; Mon, 26 May 2025 09:46: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 1uJUPq-0006Iu-ME; Mon, 26 May 2025 09:46:42 +0000
Received: by outflank-mailman (input) for mailman id 997354;
 Mon, 26 May 2025 09:46:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJUPp-0003hH-6E
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 09:46:41 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2009::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 527b233b-3a16-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 11:46:40 +0200 (CEST)
Received: from BL0PR0102CA0027.prod.exchangelabs.com (2603:10b6:207:18::40) by
 CH1PPF931B95D07.namprd12.prod.outlook.com (2603:10b6:61f:fc00::619)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.27; Mon, 26 May
 2025 09:46:35 +0000
Received: from BL02EPF0001A106.namprd05.prod.outlook.com
 (2603:10b6:207:18:cafe::93) by BL0PR0102CA0027.outlook.office365.com
 (2603:10b6:207:18::40) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Mon,
 26 May 2025 09:46:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0001A106.mail.protection.outlook.com (10.167.241.139) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Mon, 26 May 2025 09:46:35 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 26 May
 2025 04:46: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" 
X-Inumbo-ID: 527b233b-3a16-11f0-a2fb-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GmgZEmrcDTqPmcvlYDCxSSxtBFhRAegAkgVpuX/L5WS4ELCI0XrwZIaf0rwq+VuXN/s/6lqD1WPwSVIaN/NadlXTelZjnufctCfnEOke1FogHrkUUPN5fb1+yvICX8oRYyTQ93pevc+chm0Ox88EWEoGsHjxJrkHVdhpP9C5lPhM638aQQmpYY9JNx0iD4L4QI6vx+MbiH1945+3xaUBuSVbn+D5Gsm0+lJlubi0a974E8qYfzDP5JL65X0j26pF4FocM8FP+idywfkvdezz4npKhlSoSSGY4H5GVJUwXLfD2GhW0h9RHbeMNss35DHXP58yepAb2pJQoS5eHxtvlg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fUJWfL2DY49Egk7Lf4LkxsuGcBQxC7mWhWoHagyWnjk=;
 b=vi0Dvoe3iBTq/IDVPnLD1SnB/dLAq2BJDZrWKsZVjHs51XJx/k9cXwl6ubItncVjgwoJ/EEQH5u3ns89vfVFirQpyw/lncID0Z/guxBFIb4ftSrXgWy2O+TVbvsBkZjPrxVE0g+tEWIKDJxrJBDraA5h1rb+l5kX0/6IlGSRzDHGpld7UBYREwJGksVe4MQjqBbdZJTygBkvVXqAzvCs4VV0uksskMZfZZbmWGMoJK/8DOl8lNleDpWmTOTcnVV4Muao9r7ZJh0MgZgrfXDqG6lMhgptEy27i11kqo4rv6voGHFSSplXYZbWzdCjNCzsn9X1zZ0pV/ZLbixMZdv/aA==
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=fUJWfL2DY49Egk7Lf4LkxsuGcBQxC7mWhWoHagyWnjk=;
 b=X3E/pPG1QHTm+p7JgW5sT2Av3IxCBrRkdDTsqTCVAcykp7K1OML2EymjVs5dvmNrimdA54BHEjb8Jky2RP0fV3uh7keEZEH/ata7fnnr01EgB7Lotq1ZeokK6L7I5An1RXh0ZHbeUph8P+0dWRfpnA1gIs4ZyIDjCKDBFbgF/7o=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: Huang Rui , Jiqian Chen ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 10/10] vpci/msix: Free MSIX resources when init_msix() fails
Date: Mon, 26 May 2025 17:45:59 +0800
Message-ID: <20250526094559.140423-11-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250526094559.140423-1-Jiqian.Chen@amd.com>
References: <20250526094559.140423-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A106:EE_|CH1PPF931B95D07:EE_
X-MS-Office365-Filtering-Correlation-Id: f9a88e34-37e9-45b7-4b49-08dd9c3a3409
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?REk2bHFEWURVZmRYd1FYWkVrTFJuVzdqWGpMOEF4N2QwZHZtRXdDc1ZvVVpG?=
 =?utf-8?B?S2RvMW1LemtuNDVPRUQ2ZWUraUk0V2VRTlY5bm50U1RRVkRKNWNXOFBNaHo4?=
 =?utf-8?B?bjMrYi9BRG9VWDJWaE1Ba3VhM1N2VGpCZllqcGlWWWNDa3ZScENuUi9SRjhB?=
 =?utf-8?B?ZnhEZzJHVWcxbWk4S0tuNlFKMHZ3MGdDZHE5S3dCNWgwaWVVM3RWOWtFd0o0?=
 =?utf-8?B?c212WjJYTmpuTVEvc1pqY2tKR21FaElycE5xNUF3UHcwcEFGcjNsMk5CV0t2?=
 =?utf-8?B?MVBEMkRPaXJZRDZVTVNzbkJ3bm1LdnJYUGdXV25nMkFQUzlIdWJnVEhjZXJu?=
 =?utf-8?B?czl6eGdlY21EZldOTU9iUzNUV2RUTnBnc1hXcUNuUjZ1UkxCemtucjdRU29y?=
 =?utf-8?B?bG5IMndha3plMzdDK2ZZZUpoM1BjWTBEbjNUdUNWcys0bkVDS2RWYmpieEZ1?=
 =?utf-8?B?TkhaSEVteno1OU9xbk9uekVkVklvQVVVbWhzL28zdUk0ZmVtb1FJRnpEN0VZ?=
 =?utf-8?B?eW5DUGQ5NHFSZ2F1QllmamxJMlk4T204M1N5cFczeUluZ09wRmpmN2tXUElz?=
 =?utf-8?B?MllSSUE2OEY1eWpKWTBHaWFZbnpqQ21qR2JmS0dQUFlsN3RZSnpDRGJucHNz?=
 =?utf-8?B?UzFnQi9tVkRiWERVbDJTSTNMV29mdndubWowNVcwRGh0SnhpRmpzV1ZYa2RV?=
 =?utf-8?B?eitSdGU0eWw5TFRpdVp1Y1ljdWtMZi9jUHc5UVcxR29zcjVnNWRtemZkNmNn?=
 =?utf-8?B?d1k5TDNUK1IwaGhiWkpIRkJMSEx6bVJwa01yaEFZUmk2QTJyVXdlMW5EUm1S?=
 =?utf-8?B?QjZKWXd0QXhmQnM4MDl0ekVKVlpoV1pqS3RtcU9HK3E4U2V3QVRHaVNDODNM?=
 =?utf-8?B?UDVKQWJoaXZrNUp2eUd6ZDdQbmFVSGhVcHJQQml0WHVkUEw0QlgwVFI2NDEv?=
 =?utf-8?B?RmVJOVZya1dyb0M2aXRZbHRtd2VJN3Vlb3pQLzNnL3JFdS9EUEhWMm1KWm1z?=
 =?utf-8?B?dUVMRXptSzl6UHM3cVV2RSsvQTZPYzNMNVAyUzZ6QWZvN1VzUEZDV1AvZHBF?=
 =?utf-8?B?eis3bnBZZ3RPdHNXbC9RZmZxU3RRQTczd1VZSlFudFk5ais1d1QvQ29PQ3VZ?=
 =?utf-8?B?V0dxazkvUHdsWW9YM1FtYnp2amVIeDlJMnpCQUhmYUY5UW4wTnFiRjdqa2hU?=
 =?utf-8?B?c2tRL2llRUZISDJCT1ZhcitlQVpLTEFKZjAzc2pqZStmdGZUT3pkZDRHVlBq?=
 =?utf-8?B?VHFqRFJ1UGxjN29PRDNvYkNhWU1PckZONU90TnVYRnFmN2xPeFJxdEJuTklv?=
 =?utf-8?B?YXgzR2t6YlAzQTEzY0t4cmY4aTJMN0lGSTFPNThGZjZja1BYcTRKMEVjUm5V?=
 =?utf-8?B?TFdxazNxVlh3ei9PTU4yemQxVVppZitKWkgxZTFWc3lhZDhtMlpSay9LKzBq?=
 =?utf-8?B?OG5DZ3RVbHFIaTFESWlaYUlrNXFSZVd6dmJmaEtLZGNmT2F3S0RhdGQ0RVNr?=
 =?utf-8?B?VDd3czUxb2duakZrS2ZDak1xQnJCcTZIM2EzcFJaeWhGcWxLQytBbkdWamRT?=
 =?utf-8?B?U2xaTDVsc2NTQkhIZTNzYjNCRmoxZ2pRK1VUYkVtaHoxQmpJQWdZb29VU2hR?=
 =?utf-8?B?Uk1jSG8vWDAvT29TZnZRY09pTHBMQkgvVWEyaGF4TFZmY1hIL3dBUGg3eGt3?=
 =?utf-8?B?Ui9IT0w1bDdQbmtWVGsySnorUXlmKzlzY01TYjZWUjIzY2w5TnI3NXZwSXV1?=
 =?utf-8?B?TlJMK1ZHTC9ENjhienBjS1FBYkIvUmxRODBZOWxoMGtVNHlqSVlaa1ZsWW9n?=
 =?utf-8?B?NEV6cXZ0WDh2SmVoSlhxTGpLVmw4RDZkaEhoYVg2V1g5YW1QQ3J5R2hjUHhX?=
 =?utf-8?B?ak9zS0U4S0JCTTI1Smd4WjdPeXh4bGd4SmhIT1A4ay9rS2h4SWlWYlZ6ZXdL?=
 =?utf-8?B?VWJmRGdWTEl4OFJ5YmJ2UjNWdTNCRGZnQkpEekRtMmxhcDJkdzZLbEhqYkdE?=
 =?utf-8?B?cnMxNlZOSU5MVzFMR3hPR0I2aExia1VqOGZ3WnlrcDBPUGZ4NGk5MUdweHFW?=
 =?utf-8?Q?d7djrV?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2025 09:46:35.1103
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f9a88e34-37e9-45b7-4b49-08dd9c3a3409
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A106.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PPF931B95D07

When init_msix() fails, current logic return fail and free MSIX-related
resources in vpci_deassign_device(). But the previous new changes will
hide MSIX capability and return success, it can't reach
vpci_deassign_device() to remove resources if hiding success, so those
resources must be removed in cleanup function of MSIX.

To do that, implement cleanup function for MSIX.

Signed-off-by: Jiqian Chen 
---
cc: "Roger Pau Monné" 
---
v4->v5 changes:
* Change definition "static void cleanup_msix" to "static int cf_check cleanup_msix" since cleanup hook is changed to be int.
* Add a read-only register for MSIX Control Register in the end of cleanup_msix().

v3->v4 changes:
* Change function name from fini_msix() to cleanup_msix().
* Change to use XFREE to free vpci->msix.
* In cleanup function, change the sequence of check and remove action according to init_msix().

v2->v3 changes:
* Remove unnecessary clean operations in fini_msix().

v1->v2 changes:
new patch.

Best regards,
Jiqian Chen.
---
 xen/drivers/vpci/msix.c | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 674815ead025..cf79320d3b6f 100644
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -655,6 +655,33 @@ int vpci_make_msix_hole(const struct pci_dev *pdev)
     return 0;
 }
 
+static int cf_check cleanup_msix(struct pci_dev *pdev)
+{
+    int rc;
+    struct vpci *vpci = pdev->vpci;
+    const unsigned int msix_pos = pdev->msix_pos;
+
+    if ( !msix_pos )
+        return 0;
+
+    rc = vpci_remove_registers(vpci, msix_control_reg(msix_pos), 2);
+    if ( rc )
+        return rc;
+
+    if ( !vpci->msix )
+        return 0;
+
+    for ( unsigned int i = 0; i < ARRAY_SIZE(vpci->msix->table); i++ )
+        if ( vpci->msix->table[i] )
+            iounmap(vpci->msix->table[i]);
+
+    list_del(&vpci->msix->next);
+    XFREE(vpci->msix);
+
+    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL,
+                             msix_control_reg(msix_pos), 2, NULL);
+}
+
 static int cf_check init_msix(struct pci_dev *pdev)
 {
     struct domain *d = pdev->domain;
@@ -709,7 +736,7 @@ static int cf_check init_msix(struct pci_dev *pdev)
 
     return rc;
 }
-REGISTER_VPCI_CAP(PCI_CAP_ID_MSIX, init_msix, NULL);
+REGISTER_VPCI_CAP(PCI_CAP_ID_MSIX, init_msix, cleanup_msix);
 
 /*
  * Local variables:
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon May 26 10:46:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 10:46:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997485.1378336 (Exim 4.92)
	(envelope-from )
	id 1uJVLh-0001DR-7x; Mon, 26 May 2025 10:46:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997485.1378336; Mon, 26 May 2025 10:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJVLh-0001DK-4t; Mon, 26 May 2025 10:46:29 +0000
Received: by outflank-mailman (input) for mailman id 997485;
 Mon, 26 May 2025 10:46:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJVLf-0001DE-Sg
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 10:46:27 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id abf57e0f-3a1e-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 12:46:25 +0200 (CEST)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-ad5273c1fd7so403381866b.1
 for ; Mon, 26 May 2025 03:46:25 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d49886esm1677493066b.144.2025.05.26.03.46.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 03:46:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: abf57e0f-3a1e-11f0-b893-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748256385; x=1748861185; darn=lists.xenproject.org;
        h=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;
        bh=lh0J/KhR0RJ3yq6/xTnrXE/lER6llAbp0fp+6wrKs3U=;
        b=Lwrqhg+obqsBDazeRKozuIUWAdq9DBHahylchI+OBLM0/DarDZo1ZUo/k41tSUciH/
         azcn9qdvuNg0WAP2HWs8cBFOMrgFyY2cEzSfh4ZpYv0DMKn8erJGxi0xb0NSylQwa1xo
         mEIAfBPCzuSkkrgf49NoS18iuHWQtifZ7oiBdqYArLZCndXRGszYC+VP9sWeNEce1Yxg
         nFwBGiI1fr9TVA4IV4cnXw7Bs4G8zA6UHStb+YsBmz5IDJkc2t4px9aAsP957UqnD9Wh
         tPFDFViKw9EyAiwLX3GoTgMmZSA+12Ie1EFZnoxC1QlIGuQJoiyMotfK+UYeGVhZcU/O
         AWqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748256385; x=1748861185;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=lh0J/KhR0RJ3yq6/xTnrXE/lER6llAbp0fp+6wrKs3U=;
        b=qs3LWDHuS7KaKZAiniJgdDWG8+U7Cca9V/em/nDuCRl3EV4EOxdfNeVKiQA3QaXys7
         jdAZQPTDyYF14rgZGM7dKdvtyCgzQQxmJTBDIoTPu9qHTmUXttaj0BqXzNjxuGcyEGxB
         Y4q6gp614DNwOyCl4owRwQUnHV5DJmnDAIZ7yRaCtQm3qzAJCPprGYWzF/QT/Vqg5X+r
         dgzbvPfxwyJhDnovNit8s5aEaKov7bx+jI8V7F2eb+u6j3NGAUmIsF1el0/lymy+nQOA
         wBfH9uXdYYdV0v3pq5/oINv7le9Ll3Cnq+TrVOU7gIMBBIRIEqi6ITai0fWvps5twMmq
         iefg==
X-Forwarded-Encrypted: i=1; AJvYcCWbb/eJMMw26QNQf9iby8snUF34dX1//ZJO8TvvGD8z9+vgaHsgTR5ysz4mYAGX0LoF3pYHpQXy6rk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAUF0bN/5HaqvlVAous99s+dpw5eUiIwKB7/dr0Nraf3N59tWV
	2lQxjN+0fewo4eDhdRC8pZ47kPiKx590R8zumM7g/Y2jzPufcCi5f3n2
X-Gm-Gg: ASbGnctGcjHqTTb0y9sp4mmm4iUxzC9GHJNTSlUPxrd9BCs21+p0E2Wr2485ERrf2M0
	41ShYavwyALCG9peUaHCS27AJ7mZqWy0hcCUNbIWIM7dxgnG7sOIstVPy6MEjsYOi+yq9sTGivR
	uIkgdXmlDR8gnos6E/CcdTI03KL9qnFm/xThEFQHP4I+sFFC8u+ILbufD8m+SWacZ3H2XR0KwJ3
	6qan/v//NvGjLl1GZ5VN5GlBUVA2uFUamhWQvEgZSJAOBgrrNmOSaEejyvLTJQhO/Q/1e7aOEgc
	l+LYS5YP/kyyMqKW//beDK7LJ13CjBFeiNBAI9wjmbdwHAc3+UvHsmBl2OFbBDj1hfieB7XeP8K
	w0U4fksTp8x5jYJq3p0+qzdte
X-Google-Smtp-Source: AGHT+IHv7AG+unLmpvyVQGDehwFSBo1mDE1EFrcZup+7CRT26smAqvA9EL0+k0UUjqXtQEKwrPDwXg==
X-Received: by 2002:a17:906:1e4d:b0:ad5:4806:4f07 with SMTP id a640c23a62f3a-ad85b0507dfmr543414666b.2.1748256384962;
        Mon, 26 May 2025 03:46:24 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------q26XMfnJ0n5CxtIjpnhciyOE"
Message-ID: 
Date: Mon, 26 May 2025 12:46:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 06/14] xen/riscv: dt_processor_hartid() implementation
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <5aec324c04c67ba88336244358542f3faa6726b2.1747843009.git.oleksii.kurochko@gmail.com>
 <12e3ad4c-b7cc-4166-940f-b2301349680c@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <12e3ad4c-b7cc-4166-940f-b2301349680c@suse.com>

This is a multi-part message in MIME format.
--------------q26XMfnJ0n5CxtIjpnhciyOE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/22/25 9:50 AM, Jan Beulich wrote:
> On 21.05.2025 18:03, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/smpboot.c
>> +++ b/xen/arch/riscv/smpboot.c
>> @@ -1,5 +1,8 @@
>>   #include 
>> +#include 
>> +#include 
>>   #include 
>> +#include 
>>   #include 
> Nit: The latter insertion wants to move one line down. Yet then - isn't
> xen/stdint.h sufficient here?

__be32 used in dt_get_hartid() is defined in xen/types.h.

>
>> @@ -14,3 +17,69 @@ void __init smp_prepare_boot_cpu(void)
>>       cpumask_set_cpu(0, &cpu_possible_map);
>>       cpumask_set_cpu(0, &cpu_online_map);
>>   }
>> +
>> +/**
>> + * dt_get_hartid - Get the hartid from a CPU device node
>> + *
>> + * @cpun: CPU number(logical index) for which device node is required
>> + *
>> + * Return: The hartid for the CPU node or ~0UL if not found.
>> + */
>> +static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
>> +{
>> +    const __be32 *cell;
>> +    unsigned int ac;
>> +    uint32_t len;
>> +
>> +    ac = dt_n_addr_cells(cpun);
>> +    cell = dt_get_property(cpun, "reg", &len);
>> +    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
> Does DT make any guarantees for this multiplication to not overflow?

I haven't tried of DTC checks such things during compilation but considering that
ac value is uin32_t value (according to DT spec) then overflow could really happen.
I will add the following to check an overflow:
     if ( ac > ((sizeof(size_t) * BIT_PER_BYTE) / sizeof(*cell)) )
     {
         printk("%s: overflow detected\n", __func__);
         return ~0UL;
     }

>
>> +        return ~0UL;
>> +
>> +    return dt_read_number(cell, ac);
>> +}
>> +
>> +/*
>> + * Returns the hartid of the given device tree node, or -ENODEV if the node
>> + * isn't an enabled and valid RISC-V hart node.
>> + */
>> +int dt_processor_hartid(const struct dt_device_node *node,
>> +                        unsigned long *hartid)
>> +{
>> +    const char *isa;
>> +    int ret;
>> +
>> +    if ( !dt_device_is_compatible(node, "riscv") )
>> +    {
>> +        printk("Found incompatible CPU\n");
>> +        return -ENODEV;
>> +    }
>> +
>> +    *hartid = dt_get_hartid(node);
>> +    if ( *hartid == ~0UL )
>> +    {
>> +        printk("Found CPU without CPU ID\n");
>> +        return -ENODATA;
>> +    }
>> +
>> +    if ( !dt_device_is_available(node))
>> +    {
>> +        printk("CPU with hartid=%lu is not available\n", *hartid);
> Considering that hart ID assignment is outside of our control, would we
> perhaps better (uniformly) log such using %#lx?

It makes sense, DTC when generates dts from dtb also uses hex number, so it could
help to find a failure node faster.

>
>> +        return -ENODEV;
>> +    }
>> +
>> +    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
>> +    {
>> +        printk("CPU with hartid=%lu has no \"riscv,isa\" property\n", *hartid);
>> +        return ret;
>> +    }
>> +
>> +    if ( isa[0] != 'r' || isa[1] != 'v' )
>> +    {
>> +        printk("CPU with hartid=%lu has an invalid ISA of \"%s\"\n", *hartid,
>> +               isa);
>> +        return -EINVAL;
> As before -EINVAL is appropriate when input arguments have wrong values.
> Here, however, you found an unexpected value in something the platform
> has presented to you. While not entirely appropriate either, maybe
> -ENODEV again (if nothing better can be found)?

I don't see better candidate.

Interesting if some reserved region exists for user
defined errors.

~ Oleksii

--------------q26XMfnJ0n5CxtIjpnhciyOE
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/22/25 9:50 AM, Jan Beulich wrote:
    
    
    
    
    
      
    On 21.05.2025 18:03, Oleksii Kurochko wrote:

    
      
    
        
    --- a/xen/arch/riscv/smpboot.c
+++ b/xen/arch/riscv/smpboot.c
@@ -1,5 +1,8 @@
 #include <xen/cpumask.h>
+#include <xen/device_tree.h>
+#include <xen/errno.h>
 #include <xen/init.h>
+#include <xen/types.h>
 #include <xen/sections.h>

    
      
    
      
    Nit: The latter insertion wants to move one line down. Yet then - isn't
xen/stdint.h sufficient here?
    
    
    
    
    __be32 used in dt_get_hartid() is defined in xen/types.h.


    
    
    
      
    

    
      
    
        
    @@ -14,3 +17,69 @@ void __init smp_prepare_boot_cpu(void)
     cpumask_set_cpu(0, &cpu_possible_map);
     cpumask_set_cpu(0, &cpu_online_map);
 }
+
+/**
+ * dt_get_hartid - Get the hartid from a CPU device node
+ *
+ * @cpun: CPU number(logical index) for which device node is required
+ *
+ * Return: The hartid for the CPU node or ~0UL if not found.
+ */
+static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
+{
+    const __be32 *cell;
+    unsigned int ac;
+    uint32_t len;
+
+    ac = dt_n_addr_cells(cpun);
+    cell = dt_get_property(cpun, "reg", &len);
+    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )

    
      
    
      
    Does DT make any guarantees for this multiplication to not overflow?
    
    
    
    
    I haven't tried of DTC checks such things during compilation but considering that
ac value is uin32_t value (according to DT spec) then overflow could really happen.
I will add the following to check an overflow:
    if ( ac > ((sizeof(size_t) * BIT_PER_BYTE) / sizeof(*cell)) )
    {
        printk("%s: overflow detected\n", __func__);
        return ~0UL;
    }


    
    
    
      
    

    
      
    
        
    +        return ~0UL;
+
+    return dt_read_number(cell, ac);
+}
+
+/*
+ * Returns the hartid of the given device tree node, or -ENODEV if the node
+ * isn't an enabled and valid RISC-V hart node.
+ */
+int dt_processor_hartid(const struct dt_device_node *node,
+                        unsigned long *hartid)
+{
+    const char *isa;
+    int ret;
+
+    if ( !dt_device_is_compatible(node, "riscv") )
+    {
+        printk("Found incompatible CPU\n");
+        return -ENODEV;
+    }
+
+    *hartid = dt_get_hartid(node);
+    if ( *hartid == ~0UL )
+    {
+        printk("Found CPU without CPU ID\n");
+        return -ENODATA;
+    }
+
+    if ( !dt_device_is_available(node))
+    {
+        printk("CPU with hartid=%lu is not available\n", *hartid);

    
      
    
      
    Considering that hart ID assignment is outside of our control, would we
perhaps better (uniformly) log such using %#lx?
    
    
    
    
    It makes sense, DTC when generates dts from dtb also uses hex number, so it could
help to find a failure node faster.


    
    
    
      
    

    
      
    
        
    +        return -ENODEV;
+    }
+
+    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
+    {
+        printk("CPU with hartid=%lu has no \"riscv,isa\" property\n", *hartid);
+        return ret;
+    }
+
+    if ( isa[0] != 'r' || isa[1] != 'v' )
+    {
+        printk("CPU with hartid=%lu has an invalid ISA of \"%s\"\n", *hartid,
+               isa);
+        return -EINVAL;

    
      
    
      
    As before -EINVAL is appropriate when input arguments have wrong values.
Here, however, you found an unexpected value in something the platform
has presented to you. While not entirely appropriate either, maybe
-ENODEV again (if nothing better can be found)?
    
    
    
    
    I don't see better candidate.

Interesting if some reserved region exists for user
defined errors.

~ Oleksii

    
  


--------------q26XMfnJ0n5CxtIjpnhciyOE--


From xen-devel-bounces@lists.xenproject.org Mon May 26 11:41:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 11:41:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997502.1378345 (Exim 4.92)
	(envelope-from )
	id 1uJWCQ-0000Fh-4Y; Mon, 26 May 2025 11:40:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997502.1378345; Mon, 26 May 2025 11:40: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 1uJWCQ-0000FY-1X; Mon, 26 May 2025 11:40:58 +0000
Received: by outflank-mailman (input) for mailman id 997502;
 Mon, 26 May 2025 11:40:57 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uJWCO-0000FS-Vz
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 11:40:56 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJWCO-003L8R-12;
 Mon, 26 May 2025 11:40:56 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uJWCO-007ZHg-1a;
 Mon, 26 May 2025 11:40:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=5AGsV5efjr3mZOxDQLdBN5qaFWI/pprCRN+A6/BZmdQ=; b=PbuvZjIZkiseEDIdaxNct3g5/D
	+9BnOP+lUaFoZHbF1aP0Owuuaq4LBuxihCpL1yqQoQzRdFERhULXjqYwq5BrtuRyE3aJuk6AdLb7U
	pJb3c82TxtqL/sWB6cydHhMn+7N43jFRE0uEZSRr5rREKlTWzvdWbInFTLbisDioAh08=;
Date: Mon, 26 May 2025 13:40:54 +0200
From: Anthony PERARD 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [PATCH v3 2/2] tools/arm: exclude iomem from domU extended
 regions
Message-ID: 
References: <20250513195452.699600-1-stewart.hildebrand@amd.com>
 <20250513195452.699600-3-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250513195452.699600-3-stewart.hildebrand@amd.com>

On Tue, May 13, 2025 at 03:54:50PM -0400, Stewart Hildebrand wrote:
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index 75c811053c7c..8ae16a1726fc 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -1542,20 +1556,90 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
>      if (info.gpaddr_bits > 64)
>          return ERROR_INVAL;
>  
> +    qsort(b_info->iomem, b_info->num_iomem, sizeof(libxl_iomem_range),
> +          compare_iomem);
> +
>      /*
>       * Try to allocate separate 2MB-aligned extended regions from the first
>       * and second RAM banks taking into the account the maximum supported
>       * guest physical address space size and the amount of memory assigned
>       * to the guest.
>       */
> -    for (i = 0; i < GUEST_RAM_BANKS; i++) {
> -        region_base[i] = bankbase[i] +
> +    for (i = 0; i < GUEST_RAM_BANKS && nr_regions < MAX_NR_EXT_REGIONS; i++) {
> +        struct {
> +            uint64_t start;
> +            uint64_t end; /* inclusive */
> +        } unallocated;
> +        uint64_t size = 0;
> +
> +        unallocated.start = bankbase[i] +
>              ALIGN_UP_TO_2MB((uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT);
>  
> -        bankend[i] = ~0ULL >> (64 - info.gpaddr_bits);
> -        bankend[i] = min(bankend[i], bankbase[i] + banksize[i] - 1);
> -        if (bankend[i] > region_base[i])
> -            region_size[i] = bankend[i] - region_base[i] + 1;
> +        unallocated.end = ~0ULL >> (64 - info.gpaddr_bits);
> +        unallocated.end = min(unallocated.end, bankbase[i] + banksize[i] - 1);
> +
> +        if (unallocated.end > unallocated.start)
> +            size = unallocated.end - unallocated.start + 1;
> +
> +        if (size < EXT_REGION_MIN_SIZE)
> +            continue;
> +
> +        /* Exclude iomem */
> +        for (j = 0; j < b_info->num_iomem && nr_regions < MAX_NR_EXT_REGIONS;
> +             j++) {
> +            struct {
> +                uint64_t start;
> +                uint64_t end; /* inclusive */
> +            } iomem;
> +
> +            iomem.start = b_info->iomem[j].gfn << XC_PAGE_SHIFT;
> +            iomem.end = ((b_info->iomem[j].gfn + b_info->iomem[j].number)
> +                         << XC_PAGE_SHIFT) - 1;
> +
> +            if (iomem.end >= unallocated.start
> +                && iomem.start <= unallocated.end) {
> +
> +                if (iomem.start <= unallocated.start) {
> +                    unallocated.start = iomem.end + 1;
> +
> +                    if (iomem.end >= unallocated.end)
> +                        /* Complete overlap, discard unallocated region */
> +                        break;
> +
> +                    /* Beginning overlap */
> +                    continue;

Instead of a `continue` and a comment that I don't understand what it is
supposed to mean, you could just do if-else:

if (iomem.start <= unallocated.start) {
    // code before this continue
} else { // we have: iomem.start > unallocated.start
    // the block of code bellow.
}

> +                }
> +
> +                if (iomem.start > unallocated.start) {
> +                    assert(unallocated.end > unallocated.start);

I think this assert should be removed.

Instead, you could check that this property hold true every time there's
a modification to `unallocated.start` in this function.

Maybe one way to make the algo easier to read, and to check that this
property is still true, is to rewrite:

    unallocated.start = iomem.end + 1;
    if (iomem.end >= unallocated.end)
        // discard `unallocated`
        break;

with

    unallocated.start = iomem.end + 1;
    if (unallocated.start > unallocated.end)
        // obvious: all allocated already
        break;

Because checking for:
    iomem.end >= unallocated.end
is the same as checking for:
    iomem.end + 1 > unallocated.end
    unallocated.start > unallocated.end

> +                    size = iomem.start - unallocated.start;

Isn't `size` the size of the unallocated region? Why is it recalculated
with `iomem`? I think it would be better to create a new variable.

> +
> +                    if (size >= EXT_REGION_MIN_SIZE) {
> +                        region_base[nr_regions] = unallocated.start;
> +                        region_size[nr_regions] = size;
> +                        nr_regions++;
> +                    }
> @@ -1565,16 +1649,12 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
>      set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
>                GUEST_GNTTAB_BASE, GUEST_GNTTAB_SIZE);
>  
> -    for (i = 0; i < GUEST_RAM_BANKS; i++) {
> -        if (region_size[i] < EXT_REGION_MIN_SIZE)
> -            continue;
> -
> +    for (i = 0; i < nr_regions; i++) {
>          LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"",
> -            nr_regions, region_base[i], region_base[i] + region_size[i]);
> +            i, region_base[i], region_base[i] + region_size[i]);

Shouldn't we print "base + size - 1" for the end address?

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 26 12:57:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 12:57:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997527.1378355 (Exim 4.92)
	(envelope-from )
	id 1uJXNv-0000H6-KR; Mon, 26 May 2025 12:56:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997527.1378355; Mon, 26 May 2025 12: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 1uJXNv-0000Gz-Hd; Mon, 26 May 2025 12:56:55 +0000
Received: by outflank-mailman (input) for mailman id 997527;
 Mon, 26 May 2025 12:56:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJXNu-0000Gt-0e
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 12:56:54 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e3971867-3a30-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 14:56:50 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-602346b1997so3339244a12.3
 for ; Mon, 26 May 2025 05:56:50 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad52d497214sm1688059466b.146.2025.05.26.05.56.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 05:56: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" 
X-Inumbo-ID: e3971867-3a30-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748264209; x=1748869009; darn=lists.xenproject.org;
        h=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;
        bh=ChVp86LF6pNA1X83+c8xGdYu9ASIEbw1MOjMGQRZCQo=;
        b=XRhPTqKgV3qJzCwu98azvOqMcqXbwjlNMrqNDxalOpiBTwI581rOHYdMF+4P43DrZb
         m650tPVrtUsIM/At0Y9oeJal2HJdsk+dEnCYhp89ldG7EywUWkyWXcTcJV8weTM1L+OU
         hVfpM5fV1gjaD3IcIXnp1pNUmgLkHcKyz47Jl2xLqAURS80mXrPscMaLNvD5X4vumN03
         ico6SuNaBmJfImIa0YwbSHPnCHX97CoCfC1kh5PRH+7zpXqMKS+QBuC5HmUa3YLU279C
         Z1/KTlArSWAzCyuTUg07aQWFOtetCLXk7pT33KGeZTRyF3ap1z9LLOHGyeaRfqjiVnQa
         Wtmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748264209; x=1748869009;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=ChVp86LF6pNA1X83+c8xGdYu9ASIEbw1MOjMGQRZCQo=;
        b=lqpJv9sRjA4zY+GNQYC7l0p0LqVLgccMTvAHi8F2vaByUT4tPdGxCOLs/RkTCLCGVe
         5OPv6gKLJCkaEyWaBdUM14ehV3h+5vmGcFy3pl/Yxh83PxclH8cXNw8wOkJqNBRDigVd
         OfHTP/6blMH26z9c+EuyAIzGDvJWoFS80oZBCQDInVpD+b/Kw/E75BTR9G4j++RKiAtA
         XP+9bJOosM6ktej6KLviDJhVmyHiAZ1z0Z6k1yUV0T/BhHDpyudskFxpVGC/sCDvsEgb
         7XvBL9asu0XStUeufmdL6i52ds33+zOi1Cr0hrskXEKKv7bnK5R/x4SAMSLSfMAmPgON
         JpOQ==
X-Forwarded-Encrypted: i=1; AJvYcCUypFWfXeKHgjFE5Nvhlj7vE2ApjFUrM75OOfwEYUXyZFWnn4A3bdsm1rEYJ00cvARc4Y77FRhiPi0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwPvN2iWqqeEZHOcIiMeVQzlh8+v21wIqJxCf0o5PszmLj/K8/c
	cNKqy8qyjhKJU7pXg2DpmapLuefezCyOkXhBTuR0rUSSRq5NNteqlfC6
X-Gm-Gg: ASbGncvRUePxBFNmEZd2QHqCTEyuMhBY3O6WKQ5AyM0TkxDW+Czo/IPOc3dz1YaNJTI
	6X7xrmct/mZyqlzOV5D0jI7chql2kDztIOVV7CLPhTLe7XOFdPfLKH71H0dZ4euCI6iNjY68mTV
	W3630pWRIaRzMi3vEcSDYC1ztarNSDUIMyPWIMW2zMDE1dLEm/esUFzMsDA4DN+a1Nbuy6GMSgF
	fK04q3ILQhUyQW1dMEI6v+KzkENcpAfCp0YRXgFrNsgBbeQjwgozz9rnE4tufb6T9YMfjOemLIY
	T/anPwho9pBbkAKUX8WusCSxIb4GuB1TIVBcpBSs8FGbfHrKR5oNk1ZhcY6y0vjpTcvSwMi+a5b
	WKp6AKuZTrZ3iVub7DE8BmiGM
X-Google-Smtp-Source: AGHT+IETOSAfx9D9xxYPhcDk8JY3HfJdASZjMAaTgZISynvYLegOZ9VOO6jIHaLlO08mImHJ+oUXAQ==
X-Received: by 2002:a17:906:7945:b0:ad5:430b:9013 with SMTP id a640c23a62f3a-ad85b2d6f1fmr808672766b.42.1748264208961;
        Mon, 26 May 2025 05:56:48 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------VE7FDKaOts0sTevQqQLOlAUd"
Message-ID: 
Date: Mon, 26 May 2025 14:56:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 06/14] xen/riscv: dt_processor_hartid() implementation
From: Oleksii Kurochko 
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <5aec324c04c67ba88336244358542f3faa6726b2.1747843009.git.oleksii.kurochko@gmail.com>
 <12e3ad4c-b7cc-4166-940f-b2301349680c@suse.com>
 
Content-Language: en-US
In-Reply-To: 

This is a multi-part message in MIME format.
--------------VE7FDKaOts0sTevQqQLOlAUd
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/26/25 12:46 PM, Oleksii Kurochko wrote:
>
>
> On 5/22/25 9:50 AM, Jan Beulich wrote:
>> On 21.05.2025 18:03, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/smpboot.c
>>> +++ b/xen/arch/riscv/smpboot.c
>>> @@ -1,5 +1,8 @@
>>>   #include 
>>> +#include 
>>> +#include 
>>>   #include 
>>> +#include 
>>>   #include 
>> Nit: The latter insertion wants to move one line down. Yet then - isn't
>> xen/stdint.h sufficient here?
> __be32 used in dt_get_hartid() is defined in xen/types.h.
>
>>> @@ -14,3 +17,69 @@ void __init smp_prepare_boot_cpu(void)
>>>       cpumask_set_cpu(0, &cpu_possible_map);
>>>       cpumask_set_cpu(0, &cpu_online_map);
>>>   }
>>> +
>>> +/**
>>> + * dt_get_hartid - Get the hartid from a CPU device node
>>> + *
>>> + * @cpun: CPU number(logical index) for which device node is required
>>> + *
>>> + * Return: The hartid for the CPU node or ~0UL if not found.
>>> + */
>>> +static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
>>> +{
>>> +    const __be32 *cell;
>>> +    unsigned int ac;
>>> +    uint32_t len;
>>> +
>>> +    ac = dt_n_addr_cells(cpun);
>>> +    cell = dt_get_property(cpun, "reg", &len);
>>> +    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )
>> Does DT make any guarantees for this multiplication to not overflow?
> I haven't tried of DTC checks such things during compilation but considering that
> ac value is uin32_t value (according to DT spec) then overflow could really happen.
> I will add the following to check an overflow:
>      if ( ac > ((sizeof(size_t) * BIT_PER_BYTE) / sizeof(*cell)) )
>      {
>          printk("%s: overflow detected\n", __func__);
>          return ~0UL;
>      }

Oops, I meant here size_t_max instead of (sizeof(size_t) * BIT_PER_BYTE), lost power of 2 minus 1.
Probably, SIZE_T_MAX or something similar exists. I have to check.

~ Oleksii

>
>>> +        return ~0UL;
>>> +
>>> +    return dt_read_number(cell, ac);
>>> +}
>>> +
>>> +/*
>>> + * Returns the hartid of the given device tree node, or -ENODEV if the node
>>> + * isn't an enabled and valid RISC-V hart node.
>>> + */
>>> +int dt_processor_hartid(const struct dt_device_node *node,
>>> +                        unsigned long *hartid)
>>> +{
>>> +    const char *isa;
>>> +    int ret;
>>> +
>>> +    if ( !dt_device_is_compatible(node, "riscv") )
>>> +    {
>>> +        printk("Found incompatible CPU\n");
>>> +        return -ENODEV;
>>> +    }
>>> +
>>> +    *hartid = dt_get_hartid(node);
>>> +    if ( *hartid == ~0UL )
>>> +    {
>>> +        printk("Found CPU without CPU ID\n");
>>> +        return -ENODATA;
>>> +    }
>>> +
>>> +    if ( !dt_device_is_available(node))
>>> +    {
>>> +        printk("CPU with hartid=%lu is not available\n", *hartid);
>> Considering that hart ID assignment is outside of our control, would we
>> perhaps better (uniformly) log such using %#lx?
> It makes sense, DTC when generates dts from dtb also uses hex number, so it could
> help to find a failure node faster.
>
>>> +        return -ENODEV;
>>> +    }
>>> +
>>> +    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
>>> +    {
>>> +        printk("CPU with hartid=%lu has no \"riscv,isa\" property\n", *hartid);
>>> +        return ret;
>>> +    }
>>> +
>>> +    if ( isa[0] != 'r' || isa[1] != 'v' )
>>> +    {
>>> +        printk("CPU with hartid=%lu has an invalid ISA of \"%s\"\n", *hartid,
>>> +               isa);
>>> +        return -EINVAL;
>> As before -EINVAL is appropriate when input arguments have wrong values.
>> Here, however, you found an unexpected value in something the platform
>> has presented to you. While not entirely appropriate either, maybe
>> -ENODEV again (if nothing better can be found)?
> I don't see better candidate.
>
> Interesting if some reserved region exists for user
> defined errors.
>
> ~ Oleksii
--------------VE7FDKaOts0sTevQqQLOlAUd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/26/25 12:46 PM, Oleksii Kurochko
      wrote:
    
    
    
    
    
      
      

    
      
    
      
    On 5/22/25 9:50 AM, Jan Beulich
        wrote:
    
      
    
      
    
        
    On 21.05.2025 18:03, Oleksii Kurochko wrote:

    
        
    
          
    --- a/xen/arch/riscv/smpboot.c
+++ b/xen/arch/riscv/smpboot.c
@@ -1,5 +1,8 @@
 #include <xen/cpumask.h>
+#include <xen/device_tree.h>
+#include <xen/errno.h>
 #include <xen/init.h>
+#include <xen/types.h>
 #include <xen/sections.h>

    
        
    
        
    Nit: The latter insertion wants to move one line down. Yet then - isn't
xen/stdint.h sufficient here?
    
      
    
      
    __be32 used in dt_get_hartid() is defined in xen/types.h.


    
      
    
        
    
          
    @@ -14,3 +17,69 @@ void __init smp_prepare_boot_cpu(void)
     cpumask_set_cpu(0, &cpu_possible_map);
     cpumask_set_cpu(0, &cpu_online_map);
 }
+
+/**
+ * dt_get_hartid - Get the hartid from a CPU device node
+ *
+ * @cpun: CPU number(logical index) for which device node is required
+ *
+ * Return: The hartid for the CPU node or ~0UL if not found.
+ */
+static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
+{
+    const __be32 *cell;
+    unsigned int ac;
+    uint32_t len;
+
+    ac = dt_n_addr_cells(cpun);
+    cell = dt_get_property(cpun, "reg", &len);
+    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )

    
        
    
        
    Does DT make any guarantees for this multiplication to not overflow?
    
      
    
      
    I haven't tried of DTC checks such things during compilation but considering that
ac value is uin32_t value (according to DT spec) then overflow could really happen.
I will add the following to check an overflow:
    if ( ac > ((sizeof(size_t) * BIT_PER_BYTE) / sizeof(*cell)) )
    {
        printk("%s: overflow detected\n", __func__);
        return ~0UL;
    }
    
    
    
    
    Oops, I meant here size_t_max instead of (sizeof(size_t) * BIT_PER_BYTE), lost power of 2 minus 1.
Probably, SIZE_T_MAX or something similar exists. I have to check.

~ Oleksii

    
    
    
      
    

    
      
    
        
    
          
    +        return ~0UL;
+
+    return dt_read_number(cell, ac);
+}
+
+/*
+ * Returns the hartid of the given device tree node, or -ENODEV if the node
+ * isn't an enabled and valid RISC-V hart node.
+ */
+int dt_processor_hartid(const struct dt_device_node *node,
+                        unsigned long *hartid)
+{
+    const char *isa;
+    int ret;
+
+    if ( !dt_device_is_compatible(node, "riscv") )
+    {
+        printk("Found incompatible CPU\n");
+        return -ENODEV;
+    }
+
+    *hartid = dt_get_hartid(node);
+    if ( *hartid == ~0UL )
+    {
+        printk("Found CPU without CPU ID\n");
+        return -ENODATA;
+    }
+
+    if ( !dt_device_is_available(node))
+    {
+        printk("CPU with hartid=%lu is not available\n", *hartid);

    
        
    
        
    Considering that hart ID assignment is outside of our control, would we
perhaps better (uniformly) log such using %#lx?
    
      
    
      
    It makes sense, DTC when generates dts from dtb also uses hex number, so it could
help to find a failure node faster.


    
      
    
        
    
          
    +        return -ENODEV;
+    }
+
+    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
+    {
+        printk("CPU with hartid=%lu has no \"riscv,isa\" property\n", *hartid);
+        return ret;
+    }
+
+    if ( isa[0] != 'r' || isa[1] != 'v' )
+    {
+        printk("CPU with hartid=%lu has an invalid ISA of \"%s\"\n", *hartid,
+               isa);
+        return -EINVAL;

    
        
    
        
    As before -EINVAL is appropriate when input arguments have wrong values.
Here, however, you found an unexpected value in something the platform
has presented to you. While not entirely appropriate either, maybe
-ENODEV again (if nothing better can be found)?
    
      
    
      
    I don't see better candidate.

Interesting if some reserved region exists for user
defined errors.

~ Oleksii

    
    
    
  


--------------VE7FDKaOts0sTevQqQLOlAUd--


From xen-devel-bounces@lists.xenproject.org Mon May 26 13:03:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 13:03:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997537.1378366 (Exim 4.92)
	(envelope-from )
	id 1uJXU8-0001sc-AV; Mon, 26 May 2025 13:03:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997537.1378366; Mon, 26 May 2025 13: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 1uJXU8-0001sV-6R; Mon, 26 May 2025 13:03:20 +0000
Received: by outflank-mailman (input) for mailman id 997537;
 Mon, 26 May 2025 13:03:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJXU7-0001sP-6j
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 13:03:19 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cac2aa78-3a31-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 15:03:17 +0200 (CEST)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-551fe540b74so2536146e87.0
 for ; Mon, 26 May 2025 06:03: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" 
X-Inumbo-ID: cac2aa78-3a31-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748264597; x=1748869397; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Go//RU6xzmSyHgSW+OWt7KIVzBB+xYiGlRtxx8cg2M4=;
        b=Kz2WsjJoQeLStQgNh2sPeZ8O80vVHPBbl3L1sWDN2GFpjavOnyfo6vlZeGwf7pvZi4
         kCmEZqj0nEE5JJyL0xrzE4FexPH0BscMGnHD0JRxKbt1q17Sy5CWzXZXBvDtLJM/4XxM
         49/0KOb2brNzNthOp/QxFsRGUz8PflyslQ6SMXMs+1tWThBTZUx+gjzUs7yhSJq0HeE4
         j8+quN557mbx5hKsaoL9KNPYFNP80aPsw1Xkyi1Rfpp2JZu8yYgWfjHxnPTg0tFKmNYz
         BDzDA9yS1Ioi/cEJ8Zq5LEGB1Q1KMVVZvzwnT+B/Sr6uE3j//DgHrQyBTNctUuLwHOGy
         jr7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748264597; x=1748869397;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Go//RU6xzmSyHgSW+OWt7KIVzBB+xYiGlRtxx8cg2M4=;
        b=YqzYfERxsC4aEwe7rxJvEWmgDWBN4+j/MTrH45XJ3ngx/5P2KgS9tYCbIH7kA1ICzE
         HUUuashUInThi/RWSxy51+yOVM2zvr+osbBjXqoGDFwPB++WE96QLfUA1lBmhYNn/gf7
         3LOtKQh2guNSn3gZ+VNDAavd+p8qIJYf/3pgE2y1grWYLCJZatWr+l961pe2rB/W33M8
         8bhZ/YishcSBx6/OYCfSdMy4D3vklB/jg2FA7+2AQSlv/66krapJdD6EjJjFM+lCvhp2
         NEPewKGE57HJqlQuzJ/YSm55bJGpENyUUxhOkWunZO9a0SLxHoWbNWQVEBlD1X6sRaOp
         ol+A==
X-Gm-Message-State: AOJu0YziP+dz0jyCW27G7Tcv7ZzWHIA4X39gO7/5m+oLZd/7yW+GV3YM
	nsm2LmOquxriS1NeKXf+y9GWz14lWZLX0D3Nud6t+r2I9ytuDGZ6t8+2+gp67MY3VmByj8B8ddE
	QwuV8JGVQ2mVouJf+FhYojulvtzLlLVU=
X-Gm-Gg: ASbGncvZKiM+nwGaWN1q3UKRmt8XkgsWd6/r8axP01jfCToZdBmCi9jLTsctA4Ocv/7
	EEi8sqiL80Y+HLJwGns6ryWNavutkvdJKyIvfUhBvq5zWIqu6u5xkz5mL2Vu5nYaCY6uiXisnXb
	MJlnKHPFlfIi4c2G2kcCcwb4q/mGOTLODs
X-Google-Smtp-Source: AGHT+IGiJ4M4+crjYAYAgHgFUEBl99Y+jSLo4E4ffi4kwcnYHqaIr4uKrZwu6rGLhtAOK3uPStvoa4q8gGlpG8LBQU0=
X-Received: by 2002:a05:6512:1094:b0:553:241d:4e77 with SMTP id
 2adb3069b0e04-553241d5142mr779742e87.22.1748264596010; Mon, 26 May 2025
 06:03:16 -0700 (PDT)
MIME-Version: 1.0
References:  <15604985aae5333670467a84cccbaaa403a10000.1741164138.git.xakep.amatop@gmail.com>
 <0d0ed573-d810-4e78-9a12-985e9150c107@xen.org>
In-Reply-To: <0d0ed573-d810-4e78-9a12-985e9150c107@xen.org>
From: Mykola Kvach 
Date: Mon, 26 May 2025 16:03:04 +0300
X-Gm-Features: AX0GCFuLBB0b0bWW883QrRHs4mQ1Zl7lhgsoGfQcw3woFop11TlL2PyofXX8xkM
Message-ID: 
Subject: Re: [PATCH 08/16] xen/arm: add watchdog domain suspend/resume helpers
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach , 
	Dario Faggioli , Juergen Gross , George Dunlap , 
	Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Jan Beulich , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , Mirela Simonovic , 
	Saeed Nowshadi , Mykyta Poturai 
Content-Type: multipart/alternative; boundary="00000000000037fb820636099278"

--00000000000037fb820636099278
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, @Julien Grall

On Tue, Mar 11, 2025 at 11:04=E2=80=AFPM Julien Grall  wrot=
e:
>
> Hi Mykola,
>
> On 05/03/2025 09:11, Mykola Kvach wrote:
> > From: Mykola Kvach 
> >
> > This patch implements suspend/resume helpers for the watchdog.
> > While a domain is suspended its watchdogs must be paused. Otherwise,
> > if the domain stays in the suspend state for a longer period of time
> > compared to the watchdog period, the domain would be shutdown on resume=
.
> > Proper solution to this problem is to stop (suspend) the watchdog timer=
s
> > after the domain suspends and to restart (resume) the watchdog timers
> > before the domain resumes. The suspend/resume of watchdog timers is don=
e
> > in Xen and is invisible to the guests.
> >
> > Signed-off-by: Mirela Simonovic 
> > Signed-off-by: Saeed Nowshadi 
> > Signed-off-by: Mykyta Poturai 
> > Signed-off-by: Mykola Kvach 
> > ---
> > Changes in v3:
> > - cover the code with CONFIG_SYSTEM_SUSPEND
> >
> > Changes in v2:
> > - drop suspended field from timer structure
> > - drop the call of watchdog_domain_resume from ctxt_switch_to
> > ---
> >   xen/common/sched/core.c | 39 +++++++++++++++++++++++++++++++++++++++
> >   xen/include/xen/sched.h |  9 +++++++++
> >   2 files changed, 48 insertions(+)
> >
> > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
> > index b1c6b6b9fa..6c2231826a 100644
> > --- a/xen/common/sched/core.c
> > +++ b/xen/common/sched/core.c
> > @@ -1605,6 +1605,45 @@ void watchdog_domain_destroy(struct domain *d)
> >           kill_timer(&d->watchdog_timer[i].timer);
> >   }
> >
> > +#ifdef CONFIG_SYSTEM_SUSPEND
>
> The config option is Arm specific, yet this is common code. As x86,
> already suspend/resume, then shouldn't the config option be common?
>
> But more importantly, why do we need to save/restore the watchdogs for
> Arm but not x86? Is this a latent issue or design choice?

I=E2=80=99ve looked into this a bit. Here's what I've found:

A watchdog timer is created and initialized (but not started) for each
domain during the domain_create call. This timer can be triggered either by
the Linux kernel (I refer to Linux kernel=E2=80=93based operating systems b=
ecause I
have access to the code and can confirm that the Xen watchdog timer is
implemented there. I don=E2=80=99t have knowledge about the existence or
implementation of the Xen watchdog driver in other operating systems) Xen
watchdog driver or by the xenwatchdogd service.

Case 1: Watchdog started by the Linux kernel driver (I hope that operating
systems not based on the Linux kernel also implement proper handling for
the Xen watchdog timer driver during suspend and resume)
When the Xen watchdog is started by the Linux kernel driver, everything
works as expected. The driver correctly handles system suspend events:
https://elixir.bootlin.com/linux/v6.14.8/source/drivers/watchdog/xen_wdt.c#=
L169

Case 2: Watchdog started by xenwatchdogd service
However, when the watchdog is started by the xenwatchdogd service, neither
the underlying OS nor the daemon takes care of stopping the watchdog timer
during suspend:

https://elixir.bootlin.com/xen/v4.20.0/source/tools/hotplug/Linux/init.d/xe=
n-watchdog.in

https://elixir.bootlin.com/xen/v4.20.0/source/tools/hotplug/NetBSD/rc.d/xen=
-watchdog

Behavior on x86 during suspend:
- Linux guest is configured with xenwatchdogd, and the Xen watchdog is
started at boot
- the OS initiates suspend (we request)
- at that moment, there's an active watchdog timer in Xen for the domain,
set to, say, 15 seconds
- after suspend preparations, domain_shutdown() is called with the
SHUTDOWN_suspend argument inside Xen hypervisor internals
- inside this function, the is_shutting_down flag is set in the domain
structure
- when the watchdog timer expires, the Xen handler skips the reset action
because the domain is marked as shutting down:

https://elixir.bootlin.com/xen/v4.20.0/source/xen/common/sched/core.c#L1539

So far, everything behaves correctly.

*BUT* *for the second case there is another flow. The domain starts
resuming from suspend. As part of the resume process, the is_shutting_down
flag inside the domain is cleared, which re-enables normal watchdog
behavior. However, the watchdog timer=E2=80=94set before suspend=E2=80=94ha=
s nearly
expired. Because the OS and its user-space services (such as the watchdog
pinging daemon) have not yet fully resumed and restarted, the watchdog
timeout occurs before the ping can be sent. As a result, the watchdog
triggers a reset or shutdown (as far as i know can't be another action of
watchdog expiry, but we aren't interested in these options right now)
before the service has a chance to take control again =E2=80=94 effectively=
 making
a clean resume impossible.*

It's also unclear how common this situation is on x86 systems =E2=80=94
specifically, whether xenwatchdogd is typically used in domU or dom0, or
whether the kernel driver is more commonly relied upon instead.
---

In my opinion, since the guest OS is the one starting the Xen watchdog, it
should also manage its state during suspend/resume transitions. The general
expectation across architectures is that the OS handles device state
management when transitioning between power states. This includes stopping
or parking watchdog timers during suspend.
I think proper handling should be added to the relevant services to avoid
unexpected triggers.

What=E2=80=99s your take on this?

>
> > +
> > +void watchdog_domain_suspend(struct domain *d)
> > +{
> > +    unsigned int i;
> > +
> > +    spin_lock(&d->watchdog_lock);
> > +
> > +    for ( i =3D 0; i < NR_DOMAIN_WATCHDOG_TIMERS; i++ )
> > +    {
> > +        if ( test_bit(i, &d->watchdog_inuse_map) )
> > +        {
> > +            stop_timer(&d->watchdog_timer[i].timer);
> > +        }
> > +    }
> > +
> > +    spin_unlock(&d->watchdog_lock);
> > +}
> > +
> > +void watchdog_domain_resume(struct domain *d)
> > +{
> > +    unsigned int i;
> > +
> > +    spin_lock(&d->watchdog_lock);
> > +
> > +    for ( i =3D 0; i < NR_DOMAIN_WATCHDOG_TIMERS; i++ )
> > +    {
> > +        if ( test_bit(i, &d->watchdog_inuse_map) )
> > +        {
> > +            set_timer(&d->watchdog_timer[i].timer,
> > +                      NOW() + SECONDS(d->watchdog_timer[i].timeout));
> > +        }
> > +    }
> > +
> > +    spin_unlock(&d->watchdog_lock);
> > +}
> > +
> > +#endif /* CONFIG_SYSTEM_SUSPEND */
> > +
> >   /*
> >    * Pin a vcpu temporarily to a specific CPU (or restore old pinning
state if
> >    * cpu is NR_CPUS).
> > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> > index d0d10612ce..caab4aad93 100644
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -1109,6 +1109,15 @@ void scheduler_disable(void);
> >   void watchdog_domain_init(struct domain *d);
> >   void watchdog_domain_destroy(struct domain *d);
> >
> > +#ifdef CONFIG_SYSTEM_SUSPEND
> > +/*
> > + * Suspend/resume watchdogs of domain (while the domain is suspended
its
> > + * watchdogs should be on pause)
> > + */
> > +void watchdog_domain_suspend(struct domain *d);
> > +void watchdog_domain_resume(struct domain *d);
> > +#endif /* CONFIG_SYSTEM_SUSPEND */
> > +
> >   /*
> >    * Use this check when the following are both true:
> >    *  - Using this feature or interface requires full access to the
hardware
>
> Cheers,
>
> --
> Julien Grall
>

Kind regards,
Mykola

--00000000000037fb820636099278
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    Hi, @Julien Grall

    On Tue, Mar 11, 2025 at 11:04=E2=
=80=AFPM Julien Grall <julien@xen.org<=
/a>> wrote:
    >
    > Hi Mykola,
    >
    > On 05/03/2025 09:=
11, Mykola Kvach wrote:
    > > From: Mykola Kvach <    mykola_kvach@epam.com>
    > >
    >=
; > This patch implements suspend/resume helpers for the watchdog.
    &g=
t; > While a domain is suspended its watchdogs must be paused. Otherwise=
,
    > > if the domain stays in the suspend state for a longer period=
 of time
    > > compared to the watchdog period, the domain would be =
shutdown on resume.
    > > Proper solution to this problem is to stop=
 (suspend) the watchdog timers
    > > after the domain suspends and t=
o restart (resume) the watchdog timers
    > > before the domain resum=
es. The suspend/resume of watchdog timers is done
    > > in Xen and i=
s invisible to the guests.
    > >
    > > Signed-off-by: Mirela =
Simonovic <mirela.simonov=
ic@aggios.com>
    > > Signed-off-by: Saeed Nowshadi <saeed.nowshadi@xilinx.com>> > Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
    > > Signed-off-by: My=
kola Kvach <mykola_kvach@epam.c=
om>
    > > ---
    > > Changes in v3:
    > > - cove=
r the code with CONFIG_SYSTEM_SUSPEND
    > >
    > > Changes in =
v2:
    > > - drop suspended field from timer structure
    > > -=
 drop the call of watchdog_domain_resume from ctxt_switch_to
    > > -=
--
    > > =C2=A0 xen/common/sched/core.c | 39 +++++++++++++++++++++++=
++++++++++++++++
    > > =C2=A0 xen/include/xen/sched.h | =C2=A09 ++++=
+++++
    > > =C2=A0 2 files changed, 48 insertions(+)
    > >> > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c> > index b1c6b6b9fa..6c2231826a 100644
    > > --- a/xen/comm=
on/sched/core.c
    > > +++ b/xen/common/sched/core.c
    > > @@ =
-1605,6 +1605,45 @@ void watchdog_domain_destroy(struct domain *d)
    > =
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kill_timer(&d->watchdog_time=
r[i].timer);
    > > =C2=A0 }
    > > =C2=A0
    > > +#ifdef=
 CONFIG_SYSTEM_SUSPEND
    >
    > The config option is Arm specific, y=
et this is common code. As x86,
    > already suspend/resume, then should=
n't the config option be common?
    >
    > But more importantly, =
why do we need to save/restore the watchdogs for
    > Arm but not x86? I=
s this a latent issue or design choice?

    I=E2=80=99ve looked into thi=
s a bit. Here's what I've found:

    A watchdog timer is created=
 and initialized (but not started) for each domain during the domain_create=
 call. This timer can be triggered either by the Linux kernel (I refer to L=
inux kernel=E2=80=93based operating systems because I have access to the co=
de and can confirm that the Xen watchdog timer is implemented there. I don=
=E2=80=99t have knowledge about the existence or implementation of the Xen =
watchdog driver in other operating systems) Xen watchdog driver or by the x=
enwatchdogd service.

    Case 1: Watchdog started by the Linux kernel dr=
iver (I hope that operating systems not based on the Linux kernel also impl=
ement proper handling for the Xen watchdog timer driver during suspend and =
resume)
    When the Xen watchdog is started by the Linux kernel driver, eve=
rything works as expected. The driver correctly handles system suspend even=
ts:
    https://elixir.bootlin.com/linux/v6.14.8/source/dri=
vers/watchdog/xen_wdt.c#L169

    Case 2: Watchdog started by xenwatc=
hdogd service
    However, when the watchdog is started by the xenwatchdogd =
service, neither the underlying OS nor the daemon takes care of stopping th=
e watchdog timer during suspend:
    =C2=A0 =C2=A0 https://elixir.bootlin.com/xen/v4.20.0/source/tools/hotplug/Linux/init.d/x=
en-watchdog.in
    =C2=A0 =C2=A0 https://elixir.bo=
otlin.com/xen/v4.20.0/source/tools/hotplug/NetBSD/rc.d/xen-watchdog
    =

    Behavior on x86 during suspend:
    - Linux guest is configured with xen=
watchdogd, and the Xen watchdog is started at boot
    - the OS initiates su=
spend (we request)
    - at that moment, there's an active watchdog time=
r in Xen for the domain, set to, say, 15 seconds
    - after suspend prepara=
tions, domain_shutdown() is called with the SHUTDOWN_suspend argument insid=
e Xen hypervisor internals
    - inside this function, the is_shutting_down =
flag is set in the domain structure
    - when the watchdog timer expires, t=
he Xen handler skips the reset action because the domain is marked as shutt=
ing down:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0https://elixir.bootlin=
.com/xen/v4.20.0/source/xen/common/sched/core.c#L1539

    So far, ev=
erything behaves correctly.

    BUT for the second case there =
is another flow. The domain starts resuming from suspend. As part of the re=
sume process, the is_shutting_down flag inside the domain is cleared, which=
 re-enables normal watchdog behavior. However, the watchdog timer=E2=80=94s=
et before suspend=E2=80=94has nearly expired. Because the OS and its user-s=
pace services (such as the watchdog pinging daemon) have not yet fully resu=
med and restarted, the watchdog timeout occurs before the ping can be sent.=
 As a result, the watchdog triggers a reset or shutdown (as far as i know c=
an't be another action of watchdog expiry, but we aren't interested=
 in these options right now) before the service has a chance to take contro=
l again =E2=80=94 effectively making a clean resume impossible.

    =
It's also unclear how common this situation is on x86 systems =E2=80=94=
 specifically, whether xenwatchdogd is typically used in domU or dom0, or w=
hether the kernel driver is more commonly relied upon instead.
    ---<=
/div>

    In my opinion, since the guest OS is the one starting t=
he Xen watchdog, it should also manage its state during suspend/resume tran=
sitions. The general expectation across architectures is that the OS handle=
s device state management when transitioning between power states. This inc=
ludes stopping or parking watchdog timers during suspend.
    I think proper=
 handling should be added to the relevant services to avoid unexpected trig=
gers.

    What=E2=80=99s your take on this?

    >
    > > +> > +void watchdog_domain_suspend(struct domain *d)
    > > +{=

    > > + =C2=A0 =C2=A0unsigned int i;
    > > +
    > > + =
=C2=A0 =C2=A0spin_lock(&d->watchdog_lock);
    > > +
    > &g=
t; + =C2=A0 =C2=A0for ( i =3D 0; i < NR_DOMAIN_WATCHDOG_TIMERS; i++ )> > + =C2=A0 =C2=A0{
    > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0if ( =
test_bit(i, &d->watchdog_inuse_map) )
    > > + =C2=A0 =C2=A0 =
=C2=A0 =C2=A0{
    > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stop=
_timer(&d->watchdog_timer[i].timer);
    > > + =C2=A0 =C2=A0 =
=C2=A0 =C2=A0}
    > > + =C2=A0 =C2=A0}
    > > +
    > > + =
=C2=A0 =C2=A0spin_unlock(&d->watchdog_lock);
    > > +}
    >=
 > +
    > > +void watchdog_domain_resume(struct domain *d)
    >=
 > +{
    > > + =C2=A0 =C2=A0unsigned int i;
    > > +
    >=
 > + =C2=A0 =C2=A0spin_lock(&d->watchdog_lock);
    > > +> > + =C2=A0 =C2=A0for ( i =3D 0; i < NR_DOMAIN_WATCHDOG_TIMERS; =
i++ )
    > > + =C2=A0 =C2=A0{
    > > + =C2=A0 =C2=A0 =C2=A0 =C2=
=A0if ( test_bit(i, &d->watchdog_inuse_map) )
    > > + =C2=A0 =
=C2=A0 =C2=A0 =C2=A0{
    > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0set_timer(&d->watchdog_timer[i].timer,
    > > + =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NOW() + S=
ECONDS(d->watchdog_timer[i].timeout));
    > > + =C2=A0 =C2=A0 =C2=
=A0 =C2=A0}
    > > + =C2=A0 =C2=A0}
    > > +
    > > + =C2=
=A0 =C2=A0spin_unlock(&d->watchdog_lock);
    > > +}
    > &g=
t; +
    > > +#endif /* CONFIG_SYSTEM_SUSPEND */
    > > +
    >=
; > =C2=A0 /*
    > > =C2=A0 =C2=A0* Pin a vcpu temporarily to a sp=
ecific CPU (or restore old pinning state if
    > > =C2=A0 =C2=A0* cpu=
 is NR_CPUS).
    > > diff --git a/xen/include/xen/sched.h b/xen/inclu=
de/xen/sched.h
    > > index d0d10612ce..caab4aad93 100644
    > >=
; --- a/xen/include/xen/sched.h
    > > +++ b/xen/include/xen/sched.h<=
br>> > @@ -1109,6 +1109,15 @@ void scheduler_disable(void);
    > &=
gt; =C2=A0 void watchdog_domain_init(struct domain *d);
    > > =C2=A0=
 void watchdog_domain_destroy(struct domain *d);
    > > =C2=A0
    >=
; > +#ifdef CONFIG_SYSTEM_SUSPEND
    > > +/*
    > > + * Susp=
end/resume watchdogs of domain (while the domain is suspended its
    > &=
gt; + * watchdogs should be on pause)
    > > + */
    > > +void =
watchdog_domain_suspend(struct domain *d);
    > > +void watchdog_doma=
in_resume(struct domain *d);
    > > +#endif /* CONFIG_SYSTEM_SUSPEND =
*/
    > > +
    > > =C2=A0 /*
    > > =C2=A0 =C2=A0* Use th=
is check when the following are both true:
    > > =C2=A0 =C2=A0* =C2=
=A0- Using this feature or interface requires full access to the hardware>
    > Cheers,
    >
    > --
    > Julien Grall
    >=


    Kind regards,
    Mykola
    

--00000000000037fb820636099278--


From xen-devel-bounces@lists.xenproject.org Mon May 26 14:04:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 14:04:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997554.1378376 (Exim 4.92)
	(envelope-from )
	id 1uJYRI-0000sL-Oi; Mon, 26 May 2025 14:04:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997554.1378376; Mon, 26 May 2025 14: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 1uJYRI-0000sE-Lq; Mon, 26 May 2025 14:04:28 +0000
Received: by outflank-mailman (input) for mailman id 997554;
 Mon, 26 May 2025 14:04:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uJYRH-0000s8-Kp
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 14:04:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJYRH-003NqO-0P;
 Mon, 26 May 2025 14:04:27 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uJYRH-00B4Pv-0v;
 Mon, 26 May 2025 14:04: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=5BgaXdr/vKuzsg8WVwZCxL7LG1BCWICSR08CUjVVBdc=; b=x3/bdbaEuuUEyAz5NWtt+IJYcX
	tCcU+p2N4QeFVT3BS0nyVGuxBbXdgqXKgrmYLrFoUs8h8vvdptMy/4ud6SnrEDD4J1V7uWlcqqSAm
	zNUuAqmKSGUjJ+UrU4hV2iWWSjOoj+ud1ye7At8/Kq/vUANH9/xRK/t5w54QHC0KohU0=;
Date: Mon, 26 May 2025 16:04:25 +0200
From: Anthony PERARD 
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Juergen Gross , Jan Beulich 
Subject: Re: [PATCH v2 4/5] libxc/PM: Ensure pxstat buffers are correctly
 sized
Message-ID: 
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
 <20250512144656.314925-5-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250512144656.314925-5-ross.lagerwall@citrix.com>

On Mon, May 12, 2025 at 03:46:55PM +0100, Ross Lagerwall wrote:
> diff --git a/tools/libs/ctrl/xc_pm.c b/tools/libs/ctrl/xc_pm.c
> index ff7b5ada053f..cffbd1b8a955 100644
> --- a/tools/libs/ctrl/xc_pm.c
> +++ b/tools/libs/ctrl/xc_pm.c
> @@ -46,35 +46,33 @@ int xc_pm_get_pxstat(xc_interface *xch, int cpuid, struct xc_px_stat *pxpt)
>  {
>      struct xen_sysctl sysctl = {};
>      /* Sizes unknown until xc_pm_get_max_px */

This comment can be removed now.

> -    DECLARE_NAMED_HYPERCALL_BOUNCE(trans, pxpt->trans_pt, 0, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> -    DECLARE_NAMED_HYPERCALL_BOUNCE(pt, pxpt->pt, 0, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> +    DECLARE_NAMED_HYPERCALL_BOUNCE(trans, pxpt->trans_pt,
> +                                   pxpt->total * pxpt->total,
> +                                   XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> +    DECLARE_NAMED_HYPERCALL_BOUNCE(pt, pxpt->pt, pxpt->total,
> +                                   XC_HYPERCALL_BUFFER_BOUNCE_BOTH);

I don't think the macro takes the sizeof(*pt) or sizeof(*trans_pt) into
account when using the size provided. So it doesn't looks like you can
use `pxpt->total` alone, and you still need to multiple it by sizeof(*)
like it was done in the HYPERCALL_BOUNCE_SET_SIZE() call.

[...]
> -    HYPERCALL_BOUNCE_SET_SIZE(trans, max_px * max_px * sizeof(uint64_t));
> -    HYPERCALL_BOUNCE_SET_SIZE(pt, max_px * sizeof(struct xc_px_val));


Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 26 14:34:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 14:34:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997566.1378385 (Exim 4.92)
	(envelope-from )
	id 1uJYu4-0004bM-Vk; Mon, 26 May 2025 14:34:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997566.1378385; Mon, 26 May 2025 14:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJYu4-0004bF-TG; Mon, 26 May 2025 14:34:12 +0000
Received: by outflank-mailman (input) for mailman id 997566;
 Mon, 26 May 2025 14:34:11 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uJYu3-0004b9-8f
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 14:34:11 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJYu2-003OP6-2v;
 Mon, 26 May 2025 14:34:10 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uJYu3-00Bmtu-0J;
 Mon, 26 May 2025 14:34:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=1ENZNcDzO+xScv+fTFRC0CFrTj/9FwGl3dHz7I3b7Og=; b=UCMY+tXhXjlhS2R3VjSZL2LoCK
	9OYd0tjKWne37PRTfLakndjWbbUgu+jKTGvcSlZMTwOY6738x+GRbyy08wPfcq8W7Me72zkVhWpXi
	LZm8YkC1iTl9gTjvXWSagURgxWN+LLoggV+NUf5GjxwfzxPSk5BQOvLzs6NcLELCrA+Y=;
Date: Mon, 26 May 2025 16:34:09 +0200
From: Anthony PERARD 
To: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD 
Subject: Re: [PATCH v2 5/5] libxc/PM: Retry get_pxstat if data is incomplete
Message-ID: 
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
 <20250512144656.314925-6-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250512144656.314925-6-ross.lagerwall@citrix.com>

On Mon, May 12, 2025 at 03:46:56PM +0100, Ross Lagerwall wrote:
> If the total returned by Xen is more than the number of elements
> allocated, it means that the buffer was too small and so the data is
> incomplete. Retry to get all the data.
> 
> Signed-off-by: Ross Lagerwall 

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 26 15:08:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 15:08:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997576.1378396 (Exim 4.92)
	(envelope-from )
	id 1uJZRB-0008Tq-He; Mon, 26 May 2025 15:08:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997576.1378396; Mon, 26 May 2025 15:08: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 1uJZRB-0008Tj-Es; Mon, 26 May 2025 15:08:25 +0000
Received: by outflank-mailman (input) for mailman id 997576;
 Mon, 26 May 2025 15:08:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJZRA-0008Td-HE
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 15:08:24 +0000
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com
 [2a00:1450:4864:20::32b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41fa6105-3a43-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 17:08:19 +0200 (CEST)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-442eb5d143eso25681165e9.0
 for ; Mon, 26 May 2025 08:08:19 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f381420fsm236861095e9.32.2025.05.26.08.08.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 08:08: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" 
X-Inumbo-ID: 41fa6105-3a43-11f0-b893-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748272099; x=1748876899; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=EU1exnmsdBRhmeyGaKYuOGMB6KVcO4ERcW6t4jayRq8=;
        b=pKgHJLnfOplLOoxa5fma30EPaKHRW5qo+7v4X1bIFicMiwH+dc9YP3Vhem6hiHVuSH
         aWCZ8LB4N1T28wIkAWIeCTh5qYjm4oUlaGhymMdwk2wjw86dh1aUTo3IxjkHMHTys+Jz
         Q8JIhtI1lLwYa7+LOQ2a0Y8ojrCJjSCXi1trA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748272099; x=1748876899;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EU1exnmsdBRhmeyGaKYuOGMB6KVcO4ERcW6t4jayRq8=;
        b=tS/B8YxMOIGKLxOsctuNoSHNd49gH2yxi45gcuMcM/GkwPSBSz4mER2PYSJ6Mlt6wM
         V6dpB9nAy+3Q5JsS+oFYUsNhe+oimupGkHGmnU8BP1rBhu8bSTfTjLe4bgS8riYKlw8i
         phYlqvP01mYY0xh9VgGZssQiA+pwWkiJrH/F7EaJYgTfu7GYVUV1wziwZtZIIxTn2FhE
         bNzuiDIXnwZhSWG7mRc2aQnrTeDEUyPOp7tFx5Rdjhe7P2xmf4LlhujqnnSb2PFtGEDh
         P1YZ019sUqZyWoqnzAIulk+I+dveR+ubF88UH5GG+adKGWbW6e+e6ktGMfIrtttaok8+
         GkFQ==
X-Forwarded-Encrypted: i=1; AJvYcCVNzPT7+H/x2yVRd7JtstiD4mNtCRZz35XKMLGTbth4ThSGI/AooGMFnAgc1CSzWGCXdTjW6rKxvx4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy2USMsNA+zM60Wz2us1yJumI8e8qsfAyAK7JUsQSLuR4jiJIx9
	ghar2+QcRsMwjxUYjnjjWjaNCs7fCYx2RO3wgLL4LbBN/m1nZfbEgwwSnNiRokkLIY8=
X-Gm-Gg: ASbGnctgGrvyhJifdwW10+KnJ3giX21FhsSB1o7Qy+VTsHP6rMQIwdexSNzf7pUAeuv
	eloOa7UrL//sAZVLrmZGQXB2bFa9zeUKa1oJXXzEp+5rEE6mkG+IlrQI/Wb4AVyC2IL4GyoUhcm
	hl3ULeUxNO2kFVKTYRnx4ZWmWvOyuG7/ajvye2kgqH9YteMhEzS+dQBvG+60vlzMbuHAwV/7mdx
	OJjW0sZH8ax6dz7UVHuIVh3iLKO1VKpscwG9/fj7lBRF7ZOyFF8mnrs3xv+mE5fPmspt0CP+86J
	BUmb9Sz93H2V4qfiIfMfmpekVMhM0bO8scHXT9JfrGOl7Js+91ZpvTkmAmc7lmpTtOG9rA7XGNR
	YRq0cwnoHrIHCwrQN
X-Google-Smtp-Source: AGHT+IG/OaRwlDk9jTrJ4xxl8oP7SVSrG+mhYG+J8/vnrLQfrrYekKMFLSaYebwbWTFsBF/6Bue5WA==
X-Received: by 2002:a05:600c:470b:b0:441:ac58:eb31 with SMTP id 5b1f17b1804b1-44c92d351d5mr69366565e9.20.1748272098725;
        Mon, 26 May 2025 08:08:18 -0700 (PDT)
Message-ID: <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com>
Date: Mon, 26 May 2025 16:08:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/5] console: add relocation hook
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini 
References: 
 <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.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: <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 25/05/2025 3:15 pm, Marek Marczykowski-Górecki wrote:
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 25189541244d..3ef819a252e4 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1481,6 +1481,8 @@ void asmlinkage __init noreturn __start_xen(void)
>          highmem_start &= ~((1UL << L3_PAGETABLE_SHIFT) - 1);
>  #endif
>  
> +    console_init_pre_relocate();
> +
>      /*
>       * Iterate backwards over all superpage-aligned RAM regions.
>       *
> @@ -1606,6 +1608,12 @@ void asmlinkage __init noreturn __start_xen(void)
>      if ( !xen_phys_start )
>          panic("Not enough memory to relocate Xen\n");
>  
> +    /*
> +     * Notify console drivers about relocation, before reusing old Xen's
> +     * memory.
> +     */
> +    console_init_post_relocate();
> +

With reference to the next patch, there are printk()'s in this region
which want to work (in case something goes very wrong), so I don't think
setting dbc->suspended is the best approach.

In dbc_uart_init_pre_relocate(), you just wait for all transfers to
complete.  Can't this be merged with post_relocate(), at which point the
intermediate printk()'s will work too?  It will also remove a hook.

Meanwhile, we have things like:

    /* Cache {,compat_}gdt_l1e now that physically relocation is done. */
    this_cpu(gdt_l1e) =
        l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW);
    if ( IS_ENABLED(CONFIG_PV32) )
        this_cpu(compat_gdt_l1e) =
            l1e_from_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR_RW);


in traps_init() which really doesn't belong here, but does belong in
some kind of general "relocation done" mechanism.

I wonder if we want a new type of initcall for this, allowing individual
areas of code to opt in with less boilerpate?

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 26 15:38:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 15:38:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997585.1378405 (Exim 4.92)
	(envelope-from )
	id 1uJZtu-00041R-PW; Mon, 26 May 2025 15:38:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997585.1378405; Mon, 26 May 2025 15:38: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 1uJZtu-00041K-Mo; Mon, 26 May 2025 15:38:06 +0000
Received: by outflank-mailman (input) for mailman id 997585;
 Mon, 26 May 2025 15:38:05 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uJZtt-00041E-Pk
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 15:38:05 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJZtt-003Pq1-1N;
 Mon, 26 May 2025 15:38:05 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uJZtt-00DIzM-1Z;
 Mon, 26 May 2025 15:38: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=h2dW67t6mSTTssdF81HMWWxn3bRr8RAmt/V+DPxNSCs=; b=nGr95KXbQiaqVQ4dH6sTV8dE+i
	DYyrMSleAZizju+gHjH+7rnDoCE63yJaZf6k0sHMDRUiNpq6dFhJl5uV1w0xYmH3/lvMNvb13GUrn
	pwk5KclT6EnpmMcQe/xZxUa2BBSn/xuPMZb620Jag8Eh/f9pvXlIiV951jcs+PR30sH8=;
Date: Mon, 26 May 2025 17:38:03 +0200
From: Anthony PERARD 
To: Andrew Cooper 
Cc: Xen-devel ,
	Jan Beulich ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH] tools: Add install/uninstall targets to
 tests/x86_emulator
Message-ID: 
References: <20240516110710.3446-1-alejandro.vallejo@cloud.com>
 <724b77b5-3b78-436e-bd20-726c34bef03b@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <724b77b5-3b78-436e-bd20-726c34bef03b@citrix.com>

On Tue, May 20, 2025 at 10:02:05PM +0100, Andrew Cooper wrote:
> On 16/05/2024 12:07 pm, Alejandro Vallejo wrote:
> > Bring test_x86_emulator in line with other tests by adding
> > install/uninstall rules.
> >
> > Signed-off-by: Alejandro Vallejo 
> > ---
> >  tools/tests/x86_emulator/Makefile | 11 +++++++++--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile
> > index 834b2112e7fe..30edf7e0185d 100644
> > --- a/tools/tests/x86_emulator/Makefile
> > +++ b/tools/tests/x86_emulator/Makefile
> > @@ -269,8 +269,15 @@ clean:
> >  .PHONY: distclean
> >  distclean: clean
> >  
> > -.PHONY: install uninstall
> > -install uninstall:
> > +.PHONY: install
> > +install: all
> > +	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
> > +	$(if $(TARGET-y),$(INSTALL_PROG) $(TARGET-y) $(DESTDIR)$(LIBEXEC_BIN))
> > +
> > +.PHONY: uninstall
> > +uninstall:
> > +	$(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/,$(TARGET-y))
> > +
> >  
> >  .PHONY: run32 clean32
> >  ifeq ($(XEN_COMPILE_ARCH),x86_64)
> 
> [starting a clean thread]
> 
> x86_emulator is not special enough to behave differently to the rest of
> tools/.
> 
> Theoretical concerns over cross compiling test_x86_emulator for non-x86
> can be fixed by whomever first wants to do this.

I think we are fine with regards to cross compiling. It's probably
broken.

Sometime, XEN_COMPILE_ARCH is used as XEN_TARGET_ARCH.

Also the makefile is executed only if the target is x86 (in the makefile
in the parent directory). So if the target is not x86, nothing is
install or built. But if the target is x86 and the host is !x86 then the
build is probably going to fail.

> The very real problem is that this doesn't run in x86 CI, because and
> only because it doesn't have an install target.

So, the patch seems fine to me:
Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 26 15:39:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 15:39:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997593.1378417 (Exim 4.92)
	(envelope-from )
	id 1uJZvT-0004YF-4D; Mon, 26 May 2025 15:39:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997593.1378417; Mon, 26 May 2025 15:39: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 1uJZvS-0004Y8-WC; Mon, 26 May 2025 15:39:42 +0000
Received: by outflank-mailman (input) for mailman id 997593;
 Mon, 26 May 2025 15:39:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJZvR-0004Y2-Kq
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 15:39:41 +0000
Received: from fout-a1-smtp.messagingengine.com
 (fout-a1-smtp.messagingengine.com [103.168.172.144])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a1d3160d-3a47-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 17:39:39 +0200 (CEST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfout.phl.internal (Postfix) with ESMTP id 9AF20138046A;
 Mon, 26 May 2025 11:39:37 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Mon, 26 May 2025 11:39:37 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 26 May 2025 11:39:35 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1d3160d-3a47-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1748273977;
	 x=1748360377; bh=esvQVRH0bPyN7dluy4hxzi4y7JXLpesQLXxu/LYNZ+w=; b=
	rntbuXRyKUku3V6Kh3/QvfSLltVRTDiott60X+/1nws5875rtkrgfbzYc4GqTmaf
	viOeM/p3598h0L29HySFZMDhsSS2BkhIkue6EQoOy2WFPuH1yZbkRBze2aUSQW1L
	+JpGnJoGIQf7ukoe8KGUF17zIN5fleD7ie7jswjZmvirYmEQU2aXahlEyF9P07oG
	8am5etM85oW7agFIuQPY/Hrmmt3lsxxnKT3lEnApoOjtplYMsdu6J/hUlvf+wpMu
	KlLC4wbntMe42BFClqfLgLVVqYVGHps7uqOrza2LrY/+t8Y0aZMdfr7RpLZm3au+
	SP2jg4laqfIJrxwYTFGl9w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
	1748273977; x=1748360377; bh=esvQVRH0bPyN7dluy4hxzi4y7JXLpesQLXx
	u/LYNZ+w=; b=DbtSAphPMyAmUGoRxMX3z1YPotAbyZHbejZhT6ULjDkrMlWn63J
	B+GUMDBpCzcFBZaxp+nISLEgMzCe2V1TohI6hbYH7tmXlXYgK//plRWcW0rtI87d
	ii/JetOouO/wJBZ/y7izUzPy62OA1bPp2emjWw0OGUFpcZ80eQOlmpSR57SewA64
	mw9YKhFn24KcDJLblx47yo1hg1zN60UZh/wK6d6qcoy5Sm62NCA7XT4hJaAFU0F0
	BKK9g6hNt7jmmP0LPyANm2wHWd+ewmQwKgjtKEpU2B91LkYKbeLGSE+Vp6s85DwR
	9XRmTdoVtpTqphVmOYKh2Pi+yRTrrxd4uxA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddujeeludculddtuddrgeefvddrtd
    dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
    fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
    dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhf
    gggtuggjsehgtdorredttdejnecuhfhrohhmpeforghrvghkucforghrtgiihihkohifsh
    hkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhg
    shhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpedttedvhfekudetvdelffeguedtke
    ethfethfffhfefteeghfeigeelvddttdektdenucevlhhushhtvghrufhiiigvpedtnecu
    rfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthh
    hinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeekpdhmohguvgepshhmthhpohhu
    thdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpd
    hrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdho
    rhhgpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhope
    hrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhih
    rdhpvghrrghrugesvhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorh
    iivghlsegrmhgurdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhr
    tghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Mon, 26 May 2025 17:39:32 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v1 1/5] console: add relocation hook
Message-ID: 
References: 
 <4f1889dc03ec4aa2cc0cd2bd14523a2c6f670bdb.1748182535.git-series.marmarek@invisiblethingslab.com>
 <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="MVNS/Wq1QzvNXy9/"
Content-Disposition: inline
In-Reply-To: <0b17da9c-57db-4a8b-90af-e53e45cb1243@citrix.com>


--MVNS/Wq1QzvNXy9/
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 May 2025 17:39:32 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v1 1/5] console: add relocation hook

On Mon, May 26, 2025 at 04:08:17PM +0100, Andrew Cooper wrote:
> On 25/05/2025 3:15 pm, Marek Marczykowski-G=C3=B3recki wrote:
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 25189541244d..3ef819a252e4 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -1481,6 +1481,8 @@ void asmlinkage __init noreturn __start_xen(void)
> >          highmem_start &=3D ~((1UL << L3_PAGETABLE_SHIFT) - 1);
> >  #endif
> > =20
> > +    console_init_pre_relocate();
> > +
> >      /*
> >       * Iterate backwards over all superpage-aligned RAM regions.
> >       *
> > @@ -1606,6 +1608,12 @@ void asmlinkage __init noreturn __start_xen(void)
> >      if ( !xen_phys_start )
> >          panic("Not enough memory to relocate Xen\n");
> > =20
> > +    /*
> > +     * Notify console drivers about relocation, before reusing old Xen=
's
> > +     * memory.
> > +     */
> > +    console_init_post_relocate();
> > +
>=20
> With reference to the next patch, there are printk()'s in this region
> which want to work (in case something goes very wrong), so I don't think
> setting dbc->suspended is the best approach.

I guess the post_relocate hook might be moved a bit earlier, but still,
once relocation happens, the xhci console is not functional until it
gets relocated too (for example - it would post new TRBs into a ring
that isn't actually monitored by the controller).

> In dbc_uart_init_pre_relocate(), you just wait for all transfers to
> complete.=C2=A0 Can't this be merged with post_relocate(), at which point=
 the
> intermediate printk()'s will work too?

Not really, because the structure that driver watches is not the one
that the controller DMA into anymore... The driver would need to watch
the old physical pages (specifically, the event ring buffer there).

> =C2=A0 It will also remove a hook.
>=20
> Meanwhile, we have things like:
>=20
> =C2=A0=C2=A0=C2=A0 /* Cache {,compat_}gdt_l1e now that physically relocat=
ion is done. */
> =C2=A0=C2=A0=C2=A0 this_cpu(gdt_l1e) =3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 l1e_from_pfn(virt_to_mfn(boot_=
gdt), __PAGE_HYPERVISOR_RW);
> =C2=A0=C2=A0=C2=A0 if ( IS_ENABLED(CONFIG_PV32) )
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this_cpu(compat_gdt_l1e) =3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 l1e_fr=
om_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR_RW);
>=20
>=20
> in traps_init() which really doesn't belong here, but does belong in
> some kind of general "relocation done" mechanism.
>=20
> I wonder if we want a new type of initcall for this, allowing individual
> areas of code to opt in with less boilerpate?

Maybe? But for the console specifically, we also need pre-relocation
hook (more context also in the next patch description).

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--MVNS/Wq1QzvNXy9/
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg0izUACgkQ24/THMrX
1ywanQf/QbeKKV4DSDv9LjG0sSBWpNo6Q1gggZo/tST/V4ksZzoT3gCC3Soslh+/
7F9MfqfFJW7Uc1wSCdSfqBA6bBo2RG9dCt21CYv4VfAirV4tUu5OCJwzrgK3UIpo
am/kv9aKP58yWXWLanqRLzsEKnRT0QCi5iMMprizgKx3ich5fz+YnNNWqb6r9CQk
rhO6u2o/avAsFJWUgm6zzgkmw9komRU2n/sG7oemtBwiu/HfX/9b/E9Ur9AtcctY
h4floEdyopD7TsnzwLzZRoAu9h852upuFGWocz7bAeu3YrAnJ6zFO7/EoQEKebST
WlkuQvZE0C3Ch6vUd6pZOdQUSs7JBA==
=j94w
-----END PGP SIGNATURE-----

--MVNS/Wq1QzvNXy9/--


From xen-devel-bounces@lists.xenproject.org Mon May 26 16:19:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 16:19:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997608.1378427 (Exim 4.92)
	(envelope-from )
	id 1uJaXg-0001nM-2t; Mon, 26 May 2025 16:19:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997608.1378427; Mon, 26 May 2025 16:19: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 1uJaXf-0001nF-Ur; Mon, 26 May 2025 16:19:11 +0000
Received: by outflank-mailman (input) for mailman id 997608;
 Mon, 26 May 2025 16:19:10 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uJaXe-0001n9-Sj
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 16:19:10 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJaXd-003R7Z-0N;
 Mon, 26 May 2025 16:19:09 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uJaXd-00EFKx-0X;
 Mon, 26 May 2025 16:19: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=TOX79ZSmgRULME2Nk+t8dw5ev91nIx7AxNQiiFtsGbI=; b=yq8Ra8XR+FLBIw4lnHakNx4rqr
	ccdqJqBawJiZ5pL2iuGinOI6+RGKft2Jk/X2JmoExCCsv39a1hNmeXxNT3B43Sn61usPWjtF6cfHW
	GyzzvqofNsZG2Ofw5bOzpw3ApY/w95APDqYmjC7YYyy1eSm3BlRJ8hcTOf0d7KQUoDb8=;
Date: Mon, 26 May 2025 18:19:06 +0200
From: Anthony PERARD 
To: Liam Merwick 
Cc: dwmw@amazon.co.uk, roger.pau@citrix.com, xen-devel@lists.xenproject.org,
	qemu-devel@nongnu.org
Subject: Re: [PATCH] hw/xen: Fix trace_xs_node_read() params
Message-ID: 
References: <20250523160134.218997-1-liam.merwick@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250523160134.218997-1-liam.merwick@oracle.com>

On Fri, May 23, 2025 at 04:01:34PM +0000, Liam Merwick wrote:
> When the '--enable-trace-backends=syslog' build option is configured,
> the following compilation error is encountered.
> 
> In file included from /usr/include/sys/syslog.h:207,
>                  from /usr/include/syslog.h:1,
>                  from ./trace/trace-hw_xen.h:224,
>                  from ../hw/xen/trace.h:1,
>                  from ../hw/xen/xen-bus-helper.c:13:
> In function ‘syslog’,
>     inlined from ‘_nocheck__trace_xs_node_read’ at ../hw/xen/trace-events:41:9,
>     inlined from ‘trace_xs_node_read’ at trace/trace-hw_xen.h:903:9,
>     inlined from ‘xs_node_read’ at ../hw/xen/xen-bus-helper.c:154:5:
> /usr/include/bits/syslog.h:45:3: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
>    45 |   __syslog_chk (__pri, __USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
>       |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Add a check that 'value' is not null before passing it to trace_xs_node_read().
> 
> Fixes: e6cdeee95990 ("hw/xen: Add xs_node_read() helper function")
> Signed-off-by: Liam Merwick 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 26 16:42:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 16:42:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997618.1378435 (Exim 4.92)
	(envelope-from )
	id 1uJauD-0005U7-QF; Mon, 26 May 2025 16:42:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997618.1378435; Mon, 26 May 2025 16: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 1uJauD-0005U0-Nd; Mon, 26 May 2025 16:42:29 +0000
Received: by outflank-mailman (input) for mailman id 997618;
 Mon, 26 May 2025 16:42:28 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uJauC-0005Tu-PT
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 16:42:28 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJauC-003RYJ-1j;
 Mon, 26 May 2025 16:42:28 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uJauC-00Elf8-2F;
 Mon, 26 May 2025 16:42: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=VSofmng+UEEd3Pj+eqQVa0l7wxDuJSywpc8oL7TRy7Q=; b=TUDiR9Zdtnj+uYmU/kzf2l7/yO
	pcE7JEWzAmvn0Y1UfRbsw7sC+XY4gP7V0Yvp7Akqvp1OGQCIH41z1kN65iLdhijhFPUcvn3CE2K+2
	5C9LSxKlNrsosOq11TjrEGqkI8xAvlACFoYOxsLuVCC5EpWXk2OLYH3PBUevMUeIm+Dw=;
Date: Mon, 26 May 2025 18:42:26 +0200
From: Anthony PERARD 
To: Andrew Cooper 
Cc: Xen-devel ,
	Stefano Stabellini ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Subject: Re: [PATCH 1/3] tools/tests: Drop depriv-fd-checker
Message-ID: 
References: <20250520205239.203253-1-andrew.cooper3@citrix.com>
 <20250520205239.203253-2-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250520205239.203253-2-andrew.cooper3@citrix.com>

On Tue, May 20, 2025 at 09:52:37PM +0100, Andrew Cooper wrote:
> Unlike the other tests, this is not standalone.  It requires poking at a live
> system, making it unweildly to use.
> 
> It hasn't been touched in 7 years, despite changes in libraries and kernel
> devices using the deprivilege infrastructure.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 26 16:45:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 16:45:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997626.1378446 (Exim 4.92)
	(envelope-from )
	id 1uJaxB-00062j-7q; Mon, 26 May 2025 16:45:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997626.1378446; Mon, 26 May 2025 16: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 1uJaxB-00062c-4c; Mon, 26 May 2025 16:45:33 +0000
Received: by outflank-mailman (input) for mailman id 997626;
 Mon, 26 May 2025 16:45:32 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJaxA-00062V-ET
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 16:45:32 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d5f46a29-3a50-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 18:45:31 +0200 (CEST)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3a36f26584bso1443966f8f.0
 for ; Mon, 26 May 2025 09:45:31 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-448ba3d8facsm226287045e9.6.2025.05.26.09.45.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 09:45: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" 
X-Inumbo-ID: d5f46a29-3a50-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748277930; x=1748882730; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=fyXOXxhlosJ0vM0icbHvhADN4MndrEURkzLjhSKJsVY=;
        b=HCH4BokTurOn+U5vdxLpaPFLQG3hu0IaA04Fuc8qAqZWN4/6RMlKhIkijJYmhevNHO
         Y3nFAVNRjgJjUc4OdFBT1VE82NLAMi/gdO1eOqKmLRS50yCJqdW374uSAznYm8wyfdeI
         RSB2cUHwaZOjXkkJkCTbTNCkH/oMtXPbbMetc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748277930; x=1748882730;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fyXOXxhlosJ0vM0icbHvhADN4MndrEURkzLjhSKJsVY=;
        b=TaHmGxwT5SN/zm7eqJE0Jokp0kgU6iE54NksW1p6O1BNHXf6Lo3QTK6HaZ7bn7eumP
         /uKLv+QQUn9yMTSMVVYhzWk5/mQW8k8lvUij9eZWIInibUsg2iUnvnrBcLZJlASTxRfa
         WM55xQ46x2GnacLZ0Fm3vBMwRuPFT9CYk2ycSZszAK0h4Pj5TEFebK95CF6OlVMzXn2S
         0istAFiWFQ8ck4aT4P99f1gIt+/enY0FFHciZNTt2ckzFng+8cmc54vxtvu9bPwvMm83
         RjUNr0iArLQn0NQvNC+Wymc4BRE+ESUYBUoKBhk77zS5LJCZkI4N9XBBydlMcfXoaOnN
         cdtQ==
X-Gm-Message-State: AOJu0Yz9IlpPCGwimtaw7ukANU7JlCNod+wBs3Bg/AW3EKJDrkJcXp3i
	0n3AaXa0YJagQE7nK559Vmh9R+14e8yEQzuCKeDlH4En+f2M6C7oa2S6vdkKQc3lwdvfF0i9rnK
	4IFwS
X-Gm-Gg: ASbGncuJ6RV/mnHe+VBk7lz7mKoZvKky2785bECwVg6W5lr82t66daQwJ/73rmmUE4h
	PsJoK02gr1LWcYv+Xaw7/AG/EuLTGb43MmX2SdDGWAR2Os3TtSA6cPP3q2tod4BAJ7Sk+bTdSx/
	i7bsADwLUnKKQI6PJLzem1IWcZ1cZ6CdNgR2D9Uwro1zoWIYyn/m996h41QhHNN1+ErkPqR0yOW
	Jpyb1Gj419vLk67dZi759PqhvGR9ocD4s+aBPn1h8XQUbc2l0TTddKejBZEypVJp7GuXySrhJRX
	3hSQ/gF1IkzuHpcaFiXuaf445jSVJo6+y8RA/jaZGQm4aoaBvEqeuRXtqnzObaacZlucb1Hs38p
	1jw511N/DHHWdyeeg
X-Google-Smtp-Source: AGHT+IHk2WiF5g8BuY1p64NQAopfrZ0ffH5enUmAejJhLLC8Vqdm01JlZPvCNSUJWJWDb+ayqeGMQg==
X-Received: by 2002:a05:6000:2083:b0:3a0:9f24:7742 with SMTP id ffacd0b85a97d-3a4cb4b8b07mr6622234f8f.41.1748277930338;
        Mon, 26 May 2025 09:45:30 -0700 (PDT)
Message-ID: <1e690ecb-5060-4dfe-a515-acbbf214bc99@citrix.com>
Date: Mon, 26 May 2025 17:45:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/3] CI: Drop custom handling of tools/tests
To: Xen-devel 
Cc: Anthony PERARD ,
 Stefano Stabellini ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
References: <20250520205239.203253-1-andrew.cooper3@citrix.com>
 <20250520205239.203253-4-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: <20250520205239.203253-4-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20/05/2025 9:52 pm, Andrew Cooper wrote:
> diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
> index 770e97c3e943..8d7aa8fa5140 100755
> --- a/automation/scripts/run-tools-tests
> +++ b/automation/scripts/run-tools-tests
> @@ -12,30 +12,25 @@ printf '\n' > "$xml_out"
>  printf '\n' >> "$xml_out"
>  printf ' \n' >> "$xml_out"
>  failed=
> -for dir in "$1"/*; do
> -    [ -d "$dir" ] || continue
> -    echo "Running test in $dir"
> -    printf '  \n' "$dir" >> "$xml_out"
> -    ret=
> -    for f in "$dir"/*; do
> -        [ -f "$f" ] || continue
> -        [ -x "$f" ] || continue
> -        "$f" 2>&1 | tee /tmp/out
> -        ret=$?
> -        if [ "$ret" -ne 0 ]; then
> -            echo "FAILED: $ret"
> -            failed+=" $dir"
> -            printf '   \n' "$f" "$ret" >> "$xml_out"
> -            # TODO: could use xml escaping... but current tests seems to
> -            # produce sane output
> -            cat /tmp/out >> "$xml_out"
> -            printf '   \n' >> "$xml_out"
> -        else
> -            echo "PASSED"
> -        fi
> -    done
> -    if [ -z "$ret" ]; then
> -        printf '   \n' "$dir" >> "$xml_out"
> +for f in "$1"/*; do
> +    if [ -x "$f" ]; then
> +        echo "SKIP: $f not executable"
> +        continue

This should be ! -x

I had that hunk in the wrong patch when posting this series.

~Andrew

> +    fi
> +    echo "Running $f"
> +    printf '  \n' "$f" >> "$xml_out"
> +    "$f" 2>&1 | tee /tmp/out
> +    ret=$?
> +    if [ "$ret" -ne 0 ]; then
> +        echo "FAILED: $f"
> +        failed+=" $f"
> +        printf '   \n' "$f" "$ret" >> "$xml_out"
> +        # TODO: could use xml escaping... but current tests seems to
> +        # produce sane output
> +        cat /tmp/out >> "$xml_out"
> +        printf '   \n' >> "$xml_out"
> +    else
> +        echo "PASSED"
>      fi
>      printf '  \n' >> "$xml_out"
>  done



From xen-devel-bounces@lists.xenproject.org Mon May 26 16:57:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 16:57:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997636.1378455 (Exim 4.92)
	(envelope-from )
	id 1uJb8F-0007g5-58; Mon, 26 May 2025 16:56:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997636.1378455; Mon, 26 May 2025 16: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 1uJb8F-0007fy-2H; Mon, 26 May 2025 16:56:59 +0000
Received: by outflank-mailman (input) for mailman id 997636;
 Mon, 26 May 2025 16:56:57 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uJb8D-0007fs-QJ
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 16:56:57 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJb8D-003RoL-1l;
 Mon, 26 May 2025 16:56:57 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uJb8D-00FC3r-26;
 Mon, 26 May 2025 16:56: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-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=NYsP6hm3oXrQG7LZgr4CxkNpnBUs3ma87bQjcRHyHAk=; b=gKkqS9LPj/rD9dvRSWR+7uKo5v
	B5NsNGV32eVKHnk1IzXehNaT1bMXaS/JssEcqhZveHF7T9IIkcAL7tU+d+9KQr8gt/HpmSSdU8eHc
	ohavY2KLmuAr8SaEvciO8bstwwfVTZLYAWmrOrG8aNus6TqIQ/suPrnTB61Urk0+y+cM=;
Date: Mon, 26 May 2025 18:56:55 +0200
From: Anthony PERARD 
To: Andrew Cooper 
Cc: Xen-devel ,
	Stefano Stabellini ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Subject: Re: [PATCH 2/3] tools/tests: Install tests into $(LIBEXEC)/tests
Message-ID: 
References: <20250520205239.203253-1-andrew.cooper3@citrix.com>
 <20250520205239.203253-3-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250520205239.203253-3-andrew.cooper3@citrix.com>

On Tue, May 20, 2025 at 09:52:38PM +0100, Andrew Cooper wrote:
> $(LIBEXEC_BIN) is a dumping ground of many things.  Separate the "clearly
> tests" from everything else so we can clean up how they're run in CI.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 26 17:23:05 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 17:23:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997650.1378466 (Exim 4.92)
	(envelope-from )
	id 1uJbXJ-00033A-35; Mon, 26 May 2025 17:22:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997650.1378466; Mon, 26 May 2025 17:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJbXI-000333-W0; Mon, 26 May 2025 17:22:52 +0000
Received: by outflank-mailman (input) for mailman id 997650;
 Mon, 26 May 2025 17:22:51 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uJbXH-00032x-PG
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 17:22:51 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJbXH-003SI8-18;
 Mon, 26 May 2025 17:22:51 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uJbXH-00FpCS-1P;
 Mon, 26 May 2025 17:22: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=gkSN7NhEVv4Jf4w5l8i4Gd9TSE2wB9xRZRWHG6SDaaM=; b=0I865X994fZjsYaPjYZ9WbXnhZ
	Dx/wDv4FgGrr0e3mppZ1xjYPk3meftKdXNzWIR0QI+CFlgucwXMfx7oOSEj6aux4V4lzQ5p5H+BE1
	QKQgaP52U3AJazejxDF14/grac3Pd2W1yzNLh2wyoluHyUpu5qn6HdSv91BtU30cxZY4=;
Date: Mon, 26 May 2025 19:22:49 +0200
From: Anthony PERARD 
To: Andrew Cooper 
Cc: Xen-devel ,
	Stefano Stabellini ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Subject: Re: [PATCH 3/3] CI: Drop custom handling of tools/tests
Message-ID: 
References: <20250520205239.203253-1-andrew.cooper3@citrix.com>
 <20250520205239.203253-4-andrew.cooper3@citrix.com>
 <1e690ecb-5060-4dfe-a515-acbbf214bc99@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1e690ecb-5060-4dfe-a515-acbbf214bc99@citrix.com>

On Mon, May 26, 2025 at 05:45:29PM +0100, Andrew Cooper wrote:
> On 20/05/2025 9:52 pm, Andrew Cooper wrote:
> > diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
> > index 770e97c3e943..8d7aa8fa5140 100755
> > --- a/automation/scripts/run-tools-tests
> > +++ b/automation/scripts/run-tools-tests
> > @@ -12,30 +12,25 @@ printf '\n' > "$xml_out"
> >  printf '\n' >> "$xml_out"
> >  printf ' \n' >> "$xml_out"
> >  failed=
> > -for dir in "$1"/*; do
> > -    [ -d "$dir" ] || continue
> > -    echo "Running test in $dir"
> > -    printf '  \n' "$dir" >> "$xml_out"
> > -    ret=
> > -    for f in "$dir"/*; do
> > -        [ -f "$f" ] || continue
> > -        [ -x "$f" ] || continue
> > -        "$f" 2>&1 | tee /tmp/out
> > -        ret=$?
> > -        if [ "$ret" -ne 0 ]; then
> > -            echo "FAILED: $ret"
> > -            failed+=" $dir"
> > -            printf '   \n' "$f" "$ret" >> "$xml_out"
> > -            # TODO: could use xml escaping... but current tests seems to
> > -            # produce sane output
> > -            cat /tmp/out >> "$xml_out"
> > -            printf '   \n' >> "$xml_out"
> > -        else
> > -            echo "PASSED"
> > -        fi
> > -    done
> > -    if [ -z "$ret" ]; then
> > -        printf '   \n' "$dir" >> "$xml_out"
> > +for f in "$1"/*; do
> > +    if [ -x "$f" ]; then
> > +        echo "SKIP: $f not executable"
> > +        continue
> 
> This should be ! -x
> 
> I had that hunk in the wrong patch when posting this series.

With that fixed:
Reviewed-by: Anthony PERARD 

But I think there's an issue with the script...

> > +    "$f" 2>&1 | tee /tmp/out
> > +    ret=$?
> > +    if [ "$ret" -ne 0 ]; then

Is this checking the correct exit value? It seems that without `set -o
pipefail`, we only have the exit value of `tee` which should never fail.
But I think we should grab the value of ${PIPESTATUS[0]} to actually
read the exit value of $f.

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Mon May 26 17:31:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 17:31:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997659.1378475 (Exim 4.92)
	(envelope-from )
	id 1uJbfF-0004d9-QD; Mon, 26 May 2025 17:31:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997659.1378475; Mon, 26 May 2025 17:31:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJbfF-0004d2-NW; Mon, 26 May 2025 17:31:05 +0000
Received: by outflank-mailman (input) for mailman id 997659;
 Mon, 26 May 2025 17:31:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJbfE-0004cw-MM
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 17:31:04 +0000
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com
 [2a00:1450:4864:20::32a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 324af79c-3a57-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 19:31:03 +0200 (CEST)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-43ea40a6e98so29535195e9.1
 for ; Mon, 26 May 2025 10:31:03 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f1ef0b20sm250860605e9.14.2025.05.26.10.31.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 10:31: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" 
X-Inumbo-ID: 324af79c-3a57-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748280662; x=1748885462; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bvNJ+N/BEp5lGbtN6GJv/Y00BO2+ci/AE44x/veE+Pk=;
        b=Z1B8M11LTUHgfJUprSyVK1jo+rI4ORsXyr1wWmPDOusDZo3FpZMasrhFvUMqfTvwcS
         2R9T2z8GVQVjVR1xHH0xX10Qs2snLMli207e98Q63FUmNH9O2X7aB3cv8984+8hlAN3q
         oJXlbyQUyeApr/a725okpjlZhx7vruVDiJt78=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748280662; x=1748885462;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bvNJ+N/BEp5lGbtN6GJv/Y00BO2+ci/AE44x/veE+Pk=;
        b=WsMON3K3+vOORBc9DpaBG1DUplWO6cN2PzbDG9TAOAnrnSD4v/Xxt/TsexBMIbunUP
         l9mdHGVnwV4vKw0Y1ngA49o1Ur57Pj6NPITrcV0JntFoIfbMgq9K82yg3qNcoYW4xV5k
         mTi3ljak7crp/fKJmg0y9Ziz5FlHYJuXc1eudBSkKhbaNETOLafbbr/zlPzOzY0nwvJF
         gAh1ICvhYDhUqOV725CHQzFrM+b56VCLyFe6VPHf2S3IcvPQAEAth9bqnmP7QOVV+2+Q
         cCoXN0DueByumwYbSmJEUvaR9+24x4bKrjp5kaiOUomLbuWrBJ8x9EsOAPnmwpWrDazG
         Fx1A==
X-Gm-Message-State: AOJu0YwCNbUC7PsyHme9VSafsAv5XRHha2VU9oxH1Pb1VTcGr5TyLyGF
	BnHPUbc06o1yej3uf/oU/dl3iDWg/9ziPq5GnFE4odzpwhFx3Q8sTUKZ5ctk5gtkXoAhlMozZUB
	bf1mX
X-Gm-Gg: ASbGncvfS3vkLpcsFZ5sLAIY/UAJh2pW1fl3Z0/TPG//aekcIwvb43AXeh1Z4coUoPi
	CAwpmOru8uE87Z3BYbRfQw2RqyL4ruZhZyapJ4NRGD+G9IhBbYddVbBEB+A3U4mdirasjmsTk5Q
	RXnHM8ij2rJssbfMUtC8H0fJMMX3CY6bfQ51JtBB1Vn4+2F6KiYbHhMTYodA47JyDEdtGQhc5WO
	+sswRczw2hYykH3q7xBwvRoTuL4mCLEC8j9EKdnacGHvHmGtxd7kPqRN25Ih54ZNDKTlEmmIo0g
	5koUF4LjsDZGLjAjqf0ag3U0YEzg23YOC4rCDjlPKWrYyvaKsblygiMimKUUr5dinlsCFSeEy8a
	wvO6ExpIWN0XrnLW5
X-Google-Smtp-Source: AGHT+IHM8+7w6CK1cXqVSZFKLdG8vy3l0UIlCo4uRq1gi4B1ucEHkrWHkcTwkUY9lg8HRSXUrnkEcA==
X-Received: by 2002:a05:600c:699a:b0:43c:f64c:44a4 with SMTP id 5b1f17b1804b1-44c91dd08c7mr88293095e9.8.1748280662442;
        Mon, 26 May 2025 10:31:02 -0700 (PDT)
Message-ID: <23aeac17-6fd0-4515-8c84-1a867c57a68d@citrix.com>
Date: Mon, 26 May 2025 18:31:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/3] CI: Drop custom handling of tools/tests
To: Anthony PERARD 
Cc: Xen-devel ,
 Stefano Stabellini ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
References: <20250520205239.203253-1-andrew.cooper3@citrix.com>
 <20250520205239.203253-4-andrew.cooper3@citrix.com>
 <1e690ecb-5060-4dfe-a515-acbbf214bc99@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

On 26/05/2025 6:22 pm, Anthony PERARD wrote:
> On Mon, May 26, 2025 at 05:45:29PM +0100, Andrew Cooper wrote:
>> On 20/05/2025 9:52 pm, Andrew Cooper wrote:
>>> diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
>>> index 770e97c3e943..8d7aa8fa5140 100755
>>> --- a/automation/scripts/run-tools-tests
>>> +++ b/automation/scripts/run-tools-tests
>>> @@ -12,30 +12,25 @@ printf '\n' > "$xml_out"
>>>  printf '\n' >> "$xml_out"
>>>  printf ' \n' >> "$xml_out"
>>>  failed=
>>> -for dir in "$1"/*; do
>>> -    [ -d "$dir" ] || continue
>>> -    echo "Running test in $dir"
>>> -    printf '  \n' "$dir" >> "$xml_out"
>>> -    ret=
>>> -    for f in "$dir"/*; do
>>> -        [ -f "$f" ] || continue
>>> -        [ -x "$f" ] || continue
>>> -        "$f" 2>&1 | tee /tmp/out
>>> -        ret=$?
>>> -        if [ "$ret" -ne 0 ]; then
>>> -            echo "FAILED: $ret"
>>> -            failed+=" $dir"
>>> -            printf '   \n' "$f" "$ret" >> "$xml_out"
>>> -            # TODO: could use xml escaping... but current tests seems to
>>> -            # produce sane output
>>> -            cat /tmp/out >> "$xml_out"
>>> -            printf '   \n' >> "$xml_out"
>>> -        else
>>> -            echo "PASSED"
>>> -        fi
>>> -    done
>>> -    if [ -z "$ret" ]; then
>>> -        printf '   \n' "$dir" >> "$xml_out"
>>> +for f in "$1"/*; do
>>> +    if [ -x "$f" ]; then
>>> +        echo "SKIP: $f not executable"
>>> +        continue
>> This should be ! -x
>>
>> I had that hunk in the wrong patch when posting this series.
> With that fixed:
> Reviewed-by: Anthony PERARD 

Thanks.

>
> But I think there's an issue with the script...
>
>>> +    "$f" 2>&1 | tee /tmp/out
>>> +    ret=$?
>>> +    if [ "$ret" -ne 0 ]; then
> Is this checking the correct exit value? It seems that without `set -o
> pipefail`, we only have the exit value of `tee` which should never fail.
> But I think we should grab the value of ${PIPESTATUS[0]} to actually
> read the exit value of $f.

Hmm yes, I think this needs adjusting.

It turns out there are multiple problems with junit, including the fact
that putting failures in here doesn't cause the outer job to fail. 

The internet suggest having a 'script: grep "
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 17:46:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997673.1378485 (Exim 4.92)
	(envelope-from )
	id 1uJbuM-0006RM-61; Mon, 26 May 2025 17:46:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997673.1378485; Mon, 26 May 2025 17:46: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 1uJbuM-0006RF-3O; Mon, 26 May 2025 17:46:42 +0000
Received: by outflank-mailman (input) for mailman id 997673;
 Mon, 26 May 2025 17:46:41 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uJbuL-0006Qr-AI
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 17:46:41 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJbuK-003SjM-1K;
 Mon, 26 May 2025 17:46:40 +0000
Received: from [2a02:8012:3a1:0:1d61:c8e1:4c80:6981]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uJbuK-00GPOc-1n;
 Mon, 26 May 2025 17:46:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=opX6bwnQQAfk4qljAyrpESc8Fh+iqX/iDD2BUyhkMRU=; b=erfpvz3m4CygCjOqVS48XxYPCF
	V/loZ057IELwl/fHDK0LnY+vDMPPIC6SouAj+xcIvljzGOeWtJJZKKNoaRiUl+geQby2AEXOmWihI
	MIsKlaNUkr/RaPjMvDJgE7cX9WHvBFKHVhJk+mQ9sbK4FaiKQM4oWXVs/qaOFZy2/Qq8=;
Message-ID: 
Date: Mon, 26 May 2025 18:46:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/6] xen/arm: Create tee command line parameter
Content-Language: en-GB
To: Bertrand Marquis ,
 xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org, Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Volodymyr Babchuk 
References: 
 <896de1bf9055e38ba77f7762b7e2a1e1ec1b2d1e.1747925287.git.bertrand.marquis@arm.com>
From: Julien Grall 
In-Reply-To: <896de1bf9055e38ba77f7762b7e2a1e1ec1b2d1e.1747925287.git.bertrand.marquis@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Bertrand,

On 22/05/2025 16:08, Bertrand Marquis wrote:
> Add a new command line parameter "tee=" to be used to explicitly select
> what tee mediator is to be used by Xen and fail if it does not exist
> or the probe function for it failed.
> 
> Without specifying which tee is to be used, Xen will use the first one
> for which the probe function succeeds which depends on the order of the
> mediator list which depends on the compiler.
> Using the command line argument, it is now possible to explicit request
> a specific TEE mediator and panic on boot if it is not available.
> 
> Signed-off-by: Bertrand Marquis 
> Reviewed-by: Jens Wiklander 

Acked-by: Julien Grall 

Cheers,

> ---
> Changes in v6:
> - Add Jens R-b
> Changes in v5:
> - Typo fix and rewording in command line doc (Julien)
> - fix include order in tee.c (Julien)
> - use a local bool instead of retesting the string each time in tee_init
>    (Julien)
> Changes in v4:
> - None
> Changes in v3:
> - Properly classify tee as arm specific (Jan)
> Changes in v2:
> - Patch introduced to add a command line selection of the TEE
> ---
>   docs/misc/xen-command-line.pandoc  | 14 +++++++++++++
>   xen/arch/arm/include/asm/tee/tee.h |  4 ++++
>   xen/arch/arm/tee/tee.c             | 32 ++++++++++++++++++++++++++++++
>   3 files changed, 50 insertions(+)
> 
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 89db6e83be66..472de1911363 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2651,6 +2651,20 @@ Specify the per-cpu trace buffer size in pages.
>   
>   Flag to enable TSC deadline as the APIC timer mode.
>   
> +### tee (arm)
> +> `= `
> +
> +Specify the TEE mediator to be probed and use.
> +
> +The default behaviour is to probe all TEEs supported by Xen and use
> +the first one successfully probed. When this parameter is passed, Xen will
> +probe only the TEE mediator passed as argument and boot will fail if this
> +mediator is not properly probed or if the requested TEE is not supported by
> +Xen.
> +
> +This parameter can be set to `optee` or `ffa` if the corresponding mediators
> +are compiled in.
> +
>   ### tevt_mask
>   > `= `
>   
> diff --git a/xen/arch/arm/include/asm/tee/tee.h b/xen/arch/arm/include/asm/tee/tee.h
> index 0169fd746bcd..15d664e28dce 100644
> --- a/xen/arch/arm/include/asm/tee/tee.h
> +++ b/xen/arch/arm/include/asm/tee/tee.h
> @@ -55,6 +55,9 @@ struct tee_mediator_desc {
>       /* Printable name of the TEE. */
>       const char *name;
>   
> +    /* Command line name of the TEE (to be used with tee= cmdline option) */
> +    const char *cmdline_name;
> +
>       /* Mediator callbacks as described above. */
>       const struct tee_mediator_ops *ops;
>   
> @@ -77,6 +80,7 @@ void tee_free_domain_ctx(struct domain *d);
>   static const struct tee_mediator_desc __tee_desc_##_name __used     \
>   __section(".teemediator.info") = {                                  \
>       .name = _namestr,                                               \
> +    .cmdline_name = #_name,                                         \
>       .ops = _ops,                                                    \
>       .tee_type = _type                                               \
>   }
> diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c
> index 3f65e45a7892..8501443c8e57 100644
> --- a/xen/arch/arm/tee/tee.c
> +++ b/xen/arch/arm/tee/tee.c
> @@ -18,6 +18,7 @@
>   
>   #include 
>   #include 
> +#include 
>   #include 
>   
>   #include 
> @@ -25,6 +26,10 @@
>   extern const struct tee_mediator_desc _steemediator[], _eteemediator[];
>   static const struct tee_mediator_desc __read_mostly *cur_mediator;
>   
> +/* Select the TEE mediator using a name on command line. */
> +static char __initdata opt_mediator[16] = "";
> +string_param("tee", opt_mediator);
> +
>   /*
>    * TODO: Add function to alter Dom0 DTB, so we can properly describe
>    * present TEE.
> @@ -80,15 +85,42 @@ uint16_t tee_get_type(void)
>   static int __init tee_init(void)
>   {
>       const struct tee_mediator_desc *desc;
> +    bool select_mediator = strcmp(opt_mediator, "");
> +
> +    if ( select_mediator )
> +        printk(XENLOG_INFO "TEE Mediator %s selected from command line\n",
> +               opt_mediator);
>   
> +    /*
> +     * When a specific TEE is selected using the 'tee=' command line
> +     * argument, we panic if the probe fails or if the requested TEE is not
> +     * supported.
> +     */
>       for ( desc = _steemediator; desc != _eteemediator; desc++ )
>       {
> +        if ( select_mediator &&
> +             strncmp(opt_mediator, desc->cmdline_name, sizeof(opt_mediator)) )
> +            continue;
> +
>           if ( desc->ops->probe() )
>           {
>               printk(XENLOG_INFO "Using TEE mediator for %s\n", desc->name);
>               cur_mediator = desc;
>               return 0;
>           }
> +        else if ( select_mediator )
> +        {
> +            panic("TEE mediator %s from command line probe failed\n",
> +                  opt_mediator);
> +            return -EFAULT;
> +        }
> +    }
> +
> +    if ( select_mediator )
> +    {
> +        panic("TEE Mediator %s from command line not supported\n",
> +              opt_mediator);
> +        return -EINVAL;
>       }
>   
>       return 0;

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon May 26 17:59:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 17:59:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997682.1378495 (Exim 4.92)
	(envelope-from )
	id 1uJc6b-0008EE-6p; Mon, 26 May 2025 17:59:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997682.1378495; Mon, 26 May 2025 17:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJc6b-0008E7-3o; Mon, 26 May 2025 17:59:21 +0000
Received: by outflank-mailman (input) for mailman id 997682;
 Mon, 26 May 2025 17:59:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJc6a-0008E1-5x
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 17:59:20 +0000
Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 22209aa1-3a5b-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 19:59:14 +0200 (CEST)
Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2])
 by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 54QHxCjA008740
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
 for ; Mon, 26 May 2025 19:59:13 +0200 (CEST)
Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133])
 by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 54QHxC4p025064
 for ; Mon, 26 May 2025 19:59:12 +0200 (MEST)
Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331)
 id 18E531038E; Mon, 26 May 2025 19:59: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" 
X-Inumbo-ID: 22209aa1-3a5b-11f0-b893-0df219b8e170
Date: Mon, 26 May 2025 19:59:14 +0200
From: Manuel Bouyer 
To: xen-devel@lists.xenproject.org
Subject: Xen 4.18.5 PV dbregs fail
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Mon, 26 May 2025 19:59:13 +0200 (CEST)
X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2

Hello,
since I updated to Xen 4.18.5 (from 4.18.4), NetBSD's dbregs-related tests
are failing. Only for PV; PVH and HVM guests are fine. They are
failing for both 32bits and 64bits guests.

I tracked it down to dr6 being 0xffff0ff0 after the trace trap, when at
last one of the lower bits should be 1 (I think it's bit 0, from the code).

I looked at the commit log between 4.18.4 and 4.18.5 but didn't see
anything obvious.

Any idea ?

-- 
Manuel Bouyer 
     NetBSD: 26 ans d'experience feront toujours la difference
--


From xen-devel-bounces@lists.xenproject.org Mon May 26 18:06:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 18:06:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997690.1378506 (Exim 4.92)
	(envelope-from )
	id 1uJcDA-0001bR-SY; Mon, 26 May 2025 18:06:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997690.1378506; Mon, 26 May 2025 18:06: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 1uJcDA-0001bK-Pq; Mon, 26 May 2025 18:06:08 +0000
Received: by outflank-mailman (input) for mailman id 997690;
 Mon, 26 May 2025 18:06:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJcD9-0001bE-90
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 18:06:07 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 17b862e6-3a5c-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 20:06:06 +0200 (CEST)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3a375888297so1654495f8f.1
 for ; Mon, 26 May 2025 11:06:05 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4cd0cf5ccsm7901774f8f.8.2025.05.26.11.06.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 11:06: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" 
X-Inumbo-ID: 17b862e6-3a5c-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748282765; x=1748887565; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=mdhKoeHJE9uLImQ64Dk2jdJxQNc9M0ZS4u4S5vrAKOs=;
        b=s8IcLGcG+s9oNyMgPZBN/fTVz0g8kkd2Z9LOq2hPU4vpaPXzkKZg0+Li9kMqHOZuG/
         zThJUJ4wNtAKBl0PlBR31BMhZMd0Qqcsfl8BCMBtvBCeVxYPyriLWGk2WcT5Y3y+Ha5/
         WNVyN6RZPmH5XIftROg3c9BQsM6HCnzJP5b1Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748282765; x=1748887565;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=mdhKoeHJE9uLImQ64Dk2jdJxQNc9M0ZS4u4S5vrAKOs=;
        b=LzGfbsgYF2CTlhYE3EAEZkJ/QnBuOQFNlqJL7S8io36PLRvKx9oBYTY2UAUwEr4rjc
         M7zxN4M6lEU9wEDbwVAwelbe1ODkzweP1p43AO6WyXeVcUptLrG9nUWk5ITUFLiX+KE5
         2kbEC+24NlQwT8cqehmGY0E9PWLdBRABBdoElEeo7EkYUNolS/tJOFgHtCDuY+noI+Ru
         DuILoxiP/iUrhVulDexLBMTaHHtGEDv7tONY9Io7vEvwZh5jQUGDcOefXBW8gCtte19A
         tQqhBe0OBm2QBknMxyXpqh32XSOy3mSwDuCqLWGYghn2tJkxDDfcW9mnfSq6LOEmqS3X
         k6FQ==
X-Forwarded-Encrypted: i=1; AJvYcCVA0JEsGofMP19ltne6YouwUBcy9GsWvf0ETGbX/gMLYhgxPJ3u9GqM2zmid5ScTn/lI4R/SOhQZiw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw64B6g+cGmw0arVbcZrf1woU+N3VRS693A+vNmO6LYDfsDjHdF
	wr1LKnx58ni67AcNUxFnH/xs1aw6DttiZgabj0hyLPQsmYZIsThsZd0m3/TJk39qQP/Xw3tigWx
	JgWPv
X-Gm-Gg: ASbGncuYXkw3SUIj/yD/tnaZmyQPhPXpw24Ex+yeOtTCW2uWTPkMpmYBk3PB3JJfzsy
	nkrVZEJnRqtuwXF05X8H5S18QCnGDgk6uGDjgbVKe/cQkvgWVyHZ2Mmuy5t2PNFQnGIv2OhTpva
	PUeJ5kZensLWmfvwLnbL/F/8O9kzm5rp7bgX2TukIvctdowZh7mL/S+Ho7WWPX3OiBjoqVeFm5/
	I+qhYy2jphxwHEsnAaOKCrUPUUahtm0QxYDK/adQRrPo3CB71Q/Ld0Cx/GnLW6O7s/WbBJfPMKl
	XUHjTZcX/jPPoZrkJnrDpUn20yjQzvh4rMZyXa5hjkmHMGN7BEEGcpVCgXG/ttsBJpVN9Mk3Dn7
	agmMlSpVMVaRM33KZ
X-Google-Smtp-Source: AGHT+IG8nCUeoWZn9mIuscIv/K9zpDAj3VImeG6zjJ9wtH5/KEhu99d++bIEnBvyBmikE5wEct55bQ==
X-Received: by 2002:a05:6000:2083:b0:3a3:76d8:67a7 with SMTP id ffacd0b85a97d-3a4ca544fc7mr9107017f8f.20.1748282765278;
        Mon, 26 May 2025 11:06:05 -0700 (PDT)
Message-ID: 
Date: Mon, 26 May 2025 19:06:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen 4.18.5 PV dbregs fail
To: Manuel Bouyer , 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

On 26/05/2025 6:59 pm, Manuel Bouyer wrote:
> Hello,
> since I updated to Xen 4.18.5 (from 4.18.4), NetBSD's dbregs-related tests
> are failing. Only for PV; PVH and HVM guests are fine. They are
> failing for both 32bits and 64bits guests.
>
> I tracked it down to dr6 being 0xffff0ff0 after the trace trap, when at
> last one of the lower bits should be 1 (I think it's bit 0, from the code).
>
> I looked at the commit log between 4.18.4 and 4.18.5 but didn't see
> anything obvious.
>
> Any idea ?
>

Have you got a link to the test in question?

We've had a couple of bugfixes in this area, although debug handling
isn't helped by the fact that both the SDM and APM are factually
incorrect on how to write a #DB handler (and the vendors are moving at a
glacial pace to correct them).

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 26 18:11:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 18:11:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997703.1378515 (Exim 4.92)
	(envelope-from )
	id 1uJcI6-0003JG-EF; Mon, 26 May 2025 18:11:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997703.1378515; Mon, 26 May 2025 18:11: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 1uJcI6-0003J9-Ba; Mon, 26 May 2025 18:11:14 +0000
Received: by outflank-mailman (input) for mailman id 997703;
 Mon, 26 May 2025 18:11:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uJcI4-0003J3-NV
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 18:11:12 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c66a33bd-3a5c-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 20:10:59 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43cfe63c592so33037155e9.2
 for ; Mon, 26 May 2025 11:10:59 -0700 (PDT)
Received: from [192.168.69.138] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f38142f1sm243665085e9.31.2025.05.26.11.10.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 11:10: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" 
X-Inumbo-ID: c66a33bd-3a5c-11f0-b893-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1748283058; x=1748887858; darn=lists.xenproject.org;
        h=content-transfer-encoding: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;
        bh=4hX3H0nQ/uRGryOBXGKaAFz/GEsqKixCKRGKQGRw0Nw=;
        b=nlQtU3PmiaVrB3eJWmauJtpcRk49q2yHYuMAqTMRVv9zr3DDX3S4Q1Hn9Iy5lRbsDE
         Cbv3RaJ1XNwkIeLFUsuehhMqWZNNAqB8+ovyvM827+d2EocP6ZZG+/e4zOOBEv+yI5VY
         DTqKDRKN0exeWMEyTbPMVzA4UCR0kZeiLOUr1iZlxIVtqXxp9ja6yDcXVFQj3f4phYpG
         /RgkwQpa6pMn5gL0f4hwIJ7vHYnYEImSpKggX72+gTQ9scrGu0UGCC93xKWOjk5di+hr
         z89qhfHdQ9A1aPMCzUVZufraQ2T92gpz+Yr8LubosOYwsfVtU3v/Hci+cahXGeDAVafI
         hu7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748283058; x=1748887858;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=4hX3H0nQ/uRGryOBXGKaAFz/GEsqKixCKRGKQGRw0Nw=;
        b=lw9/4EYydRjaNq7UTKdfqryTauPTjxeqvOi7CETiCeG4SGzUyA1x6d8TUHOpY62AsF
         9seZ+xawQT4BOZkwKghQEr+b3PICeyeX83Bhz1yo5JX5hZTQ2kuLMyncQXQiL3RqC1BT
         TFKp3JTSbvhuBIiHyUSP6XAgAu04d0gxyeUrSUQd+/xGyMp0cGI9XEsOv+Zh2fDo7BNb
         Zx9molUYEIFbK62UJCjfEMwj/xMktmvuM7fQW+MnBMLArzCCcRqGfVg6uziWXhqtTLvb
         j0aL7Bnhz0EtOOlOCBFV/nlcC9nKQ5jZ5KU/gHyIi0g14UZIvLOBFvo94r9jorcE7PXv
         cw0g==
X-Forwarded-Encrypted: i=1; AJvYcCXzrgC4rxzeymCQJSyAurrlko2UZoYhS6hUG65+tf+v2UBblka8sk4qcGJdVrCLczM3G9yIKe620J8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxD5PVXI28B31WtwuHcYIeotxVADmcLQPqtxbNeiFNTK2tqxJmi
	VJy4g2nU1Qowg8+fbK9B0kZGEsJhgYEFRgvQJls0s+M1WaYoXyxlwu3uq23k8XWQ4ac=
X-Gm-Gg: ASbGncutn3UymA+Kz3qqORodAokP0gzzcP5Fj1Bg0DjkLOoZj4+kX8FGxs8+K0KmcOy
	Ldrw7h634PBGrynPfvuOH/la/d3UgKYjaFBiPlDulqGl6prua4aa7/Y8f5I6RE0W3gkq+iYGnYK
	Rf1DEFYGf+iUCc/XeTLLcSb7FOD21zX3hmDynNIMmM1OP2Dhn/KjMiFy29FH9tC5KWBrHqA6Sri
	SmypipyB/eYipk8c0wjlYqCsF/WIh4s4JA7XPbqNjyBAgrCRe7yd4w3vGAurijlsWJuqYieEWWa
	pllMfgyngkY/rfcYm/Gyy2pplD0JA41adFjchG/cHFBL5qH4MGwPmTQzwPNMnAqez7RMFxxM1lg
	NKsRcFHgcK5rXIYgcJQDdSmUQ
X-Google-Smtp-Source: AGHT+IFFgr/ne1qcBJDMbJQAu1YEVf6uq+N/Ex3btwBHU7LvVD1MvYujkqcNtnDbggk9BtKqdPocFQ==
X-Received: by 2002:a05:600c:3849:b0:439:6118:c188 with SMTP id 5b1f17b1804b1-44c91dd166bmr82436095e9.19.1748283058397;
        Mon, 26 May 2025 11:10:58 -0700 (PDT)
Message-ID: <3a7386f9-a4ba-4268-a3fe-45c18360d878@linaro.org>
Date: Mon, 26 May 2025 20:10:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] hw/xen: Fix trace_xs_node_read() params
To: Liam Merwick , dwmw@amazon.co.uk,
 anthony.perard@vates.tech, roger.pau@citrix.com,
 xen-devel@lists.xenproject.org, qemu-devel@nongnu.org
References: <20250523160134.218997-1-liam.merwick@oracle.com>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
In-Reply-To: <20250523160134.218997-1-liam.merwick@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 23/5/25 18:01, Liam Merwick wrote:
> When the '--enable-trace-backends=syslog' build option is configured,
> the following compilation error is encountered.
> 
> In file included from /usr/include/sys/syslog.h:207,
>                   from /usr/include/syslog.h:1,
>                   from ./trace/trace-hw_xen.h:224,
>                   from ../hw/xen/trace.h:1,
>                   from ../hw/xen/xen-bus-helper.c:13:
> In function ‘syslog’,
>      inlined from ‘_nocheck__trace_xs_node_read’ at ../hw/xen/trace-events:41:9,
>      inlined from ‘trace_xs_node_read’ at trace/trace-hw_xen.h:903:9,
>      inlined from ‘xs_node_read’ at ../hw/xen/xen-bus-helper.c:154:5:
> /usr/include/bits/syslog.h:45:3: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
>     45 |   __syslog_chk (__pri, __USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
>        |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Add a check that 'value' is not null before passing it to trace_xs_node_read().
> 
> Fixes: e6cdeee95990 ("hw/xen: Add xs_node_read() helper function")
> Signed-off-by: Liam Merwick 
> ---
>   hw/xen/xen-bus-helper.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
> index 288fad422be3..1087a585cc71 100644
> --- a/hw/xen/xen-bus-helper.c
> +++ b/hw/xen/xen-bus-helper.c
> @@ -151,7 +151,7 @@ char *xs_node_read(struct qemu_xs_handle *h, xs_transaction_t tid,
>       va_end(ap);
>   
>       value = qemu_xen_xs_read(h, tid, path, len);
> -    trace_xs_node_read(path, value);
> +    trace_xs_node_read(path, value ? value : "");
>       if (!value) {
>           error_setg_errno(errp, errno, "failed to read from '%s'", path);
>       }

Alternatively, since this is an error path:

-- >8 --
diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
index 288fad422be..1e49e60e147 100644
--- a/hw/xen/xen-bus-helper.c
+++ b/hw/xen/xen-bus-helper.c
@@ -143,7 +143,8 @@ char *xs_node_read(struct qemu_xs_handle *h, 
xs_transaction_t tid,
                     unsigned int *len, Error **errp,
                     const char *path_fmt, ...)
  {
-    char *path, *value;
+    g_autofree char *value;
+    char *path;
      va_list ap;

      va_start(ap, path_fmt);
@@ -151,12 +152,11 @@ char *xs_node_read(struct qemu_xs_handle *h, 
xs_transaction_t tid,
      va_end(ap);

      value = qemu_xen_xs_read(h, tid, path, len);
-    trace_xs_node_read(path, value);
      if (!value) {
          error_setg_errno(errp, errno, "failed to read from '%s'", path);
+        return NULL;
      }
-
-    g_free(path);
+    trace_xs_node_read(path, value);

      return value;
  }
---

But your patch isn't wrong, so:
Reviewed-by: Philippe Mathieu-Daudé 



From xen-devel-bounces@lists.xenproject.org Mon May 26 18:17:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 18:17:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997712.1378526 (Exim 4.92)
	(envelope-from )
	id 1uJcNy-0003tT-1Q; Mon, 26 May 2025 18:17:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997712.1378526; Mon, 26 May 2025 18:17: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 1uJcNx-0003tM-V6; Mon, 26 May 2025 18:17:17 +0000
Received: by outflank-mailman (input) for mailman id 997712;
 Mon, 26 May 2025 18:17:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJcNw-0003tG-4v
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 18:17:16 +0000
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [2a00:1450:4864:20::331])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a6b50e8d-3a5d-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 20:17:15 +0200 (CEST)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-442ccf0e1b3so35578205e9.3
 for ; Mon, 26 May 2025 11:17:15 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4481ca9f2d9sm248745775e9.19.2025.05.26.11.17.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 11:17:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a6b50e8d-3a5d-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748283435; x=1748888235; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:to:from:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=uT7MFMIBahtSoJ63NquYomc3Bx/JlsKkNqQA0fqnIKA=;
        b=dJEX0RJxGZoBXx+jqxB3KEXqH36/23qCQpnaRItt6hVn2FlrxpfA9p15zacqheDoU6
         AGDAONfqpjf3xrVz5xS/WnzvzP83GRh9JnA3qDC3AFodVJ9UEn2PeakHBUsTzH1V5FPY
         DblwLtWRpX8DtaSKFP2CGlTJDbYd09gjr43Bg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748283435; x=1748888235;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:to:from:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=uT7MFMIBahtSoJ63NquYomc3Bx/JlsKkNqQA0fqnIKA=;
        b=OK+LinOtjM2FAJ72XVW4LHZ6SMG93eng9Dls/XpPH5VXLzz7yOURlkntoousfId+ed
         z4OvH8unUCY/2/Jf17BzB1FAkMoDzKYrK3t6amLQhssZpLZon/14SUxKQRfRN8bz6KK3
         b7514r9NYVsFhNO6LrtkA1Dg3len2rH7BSBbnErL3GXgU7H5DQ/V4GZU6E9UV5TdyT4n
         qAaRuWdzVlNx7i+w3EC9tbGmWo2hjPIoQMrkeK2d1ankYVQUbo2NiIHNMkN33aIc6z+l
         kjiCzdZs/SvDmcU8WYj+V+jAQfcJRr3DMlbnvQT/Ah4blqIF/phUaEnZCicDGeqSS5ZE
         HaoQ==
X-Forwarded-Encrypted: i=1; AJvYcCWUA950vksswfzPaSqsWsd0gl+otGsm3JTnDelB6CfqW2n1H04vd/d4YcMJylOcko8zlu+xp8Olgt0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxQAiVbswU0f+pw4klxr0D75pJCfUl1Ep4u41qTYul2orWoClfP
	57nWGVHTYvOoSSqfT3glMIEVDFfMI7xbPx9xCvyODaWkz6MvCJxq5Y9qvHrb9teK4W7pPQBvQWY
	9vMTB
X-Gm-Gg: ASbGncsnbXR5aMVizKU5KWmQiHbTJT1XmsF/c+gmXWe/fZQ9/GwxM5nt3j2rBGLD0NI
	kQdHDJ6ythQjDCEOvSDv11wbJtWiTVmwY7wAzhfr1bihvwggcvxyGfpZEESFheZkAw4T6+MJsGR
	9xBEJlT50MdVKC3YwS59q8NSYJQlU/gP3s+pXWJ0ty5CZ/heuXQdELaiBuYlwB0TBptHEP00AMp
	GRPoO2GYkiaq398DbkdCQSoHNY6IwIp34CUCBO3H2LpRLsB6xi+U8T5H5gp9qvNY7C0AKQqmDKq
	OlXl1B49jMFkRZIzLXtQiPuCfEAhefG/1MKZIHg+n49Chst4q9OkZ2JYvaFtV1SHZdvUusJfi4T
	iSbD3dLahwGSJiarY
X-Google-Smtp-Source: AGHT+IF5W3O6TPk7e+LNd2sqAVYEmytSNfjUVZC6qzt3rMNA2T82wSq3belaG83TFf0+SfJGaNxBOg==
X-Received: by 2002:a05:600c:3d0b:b0:43c:fe15:41c9 with SMTP id 5b1f17b1804b1-44f96fadce5mr19923225e9.9.1748283434634;
        Mon, 26 May 2025 11:17:14 -0700 (PDT)
Message-ID: 
Date: Mon, 26 May 2025 19:17:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen 4.18.5 PV dbregs fail
From: Andrew Cooper 
To: Manuel Bouyer , xen-devel@lists.xenproject.org
References: 
 
Content-Language: en-GB
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

On 26/05/2025 7:06 pm, Andrew Cooper wrote:
> On 26/05/2025 6:59 pm, Manuel Bouyer wrote:
>> Hello,
>> since I updated to Xen 4.18.5 (from 4.18.4), NetBSD's dbregs-related tests
>> are failing. Only for PV; PVH and HVM guests are fine. They are
>> failing for both 32bits and 64bits guests.
>>
>> I tracked it down to dr6 being 0xffff0ff0 after the trace trap, when at
>> last one of the lower bits should be 1 (I think it's bit 0, from the code).
>>
>> I looked at the commit log between 4.18.4 and 4.18.5 but didn't see
>> anything obvious.
>>
>> Any idea ?
>>
> Have you got a link to the test in question?
>
> We've had a couple of bugfixes in this area, although debug handling
> isn't helped by the fact that both the SDM and APM are factually
> incorrect on how to write a #DB handler (and the vendors are moving at a
> glacial pace to correct them).

But yes, having looked between 4.18.4 and 4.18.5, I can't see anything
relevant to debug handling either.

Judging from your description, it looks like a breakpoint is going missing.

The relevant recent change for that is
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=54ef601a66e8d812a6a6a308f02524e81201825e
although it's a bit older than 4.18.4.

I suppose it's possible that we call x86_merge_dr6() more than once when
forwarding #DB to the guest, which might lose the breakpoint bits?

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 26 18:42:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 18:42:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997725.1378539 (Exim 4.92)
	(envelope-from )
	id 1uJclp-0008Ed-1F; Mon, 26 May 2025 18:41:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997725.1378539; Mon, 26 May 2025 18:41: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 1uJclo-0008EW-Ux; Mon, 26 May 2025 18:41:56 +0000
Received: by outflank-mailman (input) for mailman id 997725;
 Mon, 26 May 2025 18:41:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJclo-0008EO-BI
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 18:41:56 +0000
Received: from chassiron.antioche.eu.org (chassiron.antioche.eu.org
 [2001:41d0:fc2c:4d01::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 173484b9-3a61-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 20:41:53 +0200 (CEST)
Received: from rochebonne.antioche.eu.org (rochebonne [10.0.0.1])
 by chassiron.antioche.eu.org (8.18.1/8.16.1) with ESMTP id 54QIfpR1004279;
 Mon, 26 May 2025 20:41:51 +0200 (MEST)
Received: by rochebonne.antioche.eu.org (Postfix, from userid 1210)
 id 4BDD31A4D0; Mon, 26 May 2025 20:41: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" 
X-Inumbo-ID: 173484b9-3a61-11f0-a2fb-13f23c93f187
Date: Mon, 26 May 2025 20:41:16 +0200
From: Manuel Bouyer 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org
Subject: Re: Xen 4.18.5 PV dbregs fail
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (chassiron.antioche.eu.org [109.190.99.82]); Mon, 26 May 2025 20:41:51 +0200 (MEST)

On Mon, May 26, 2025 at 07:06:04PM +0100, Andrew Cooper wrote:
> On 26/05/2025 6:59 pm, Manuel Bouyer wrote:
> > Hello,
> > since I updated to Xen 4.18.5 (from 4.18.4), NetBSD's dbregs-related tests
> > are failing. Only for PV; PVH and HVM guests are fine. They are
> > failing for both 32bits and 64bits guests.
> >
> > I tracked it down to dr6 being 0xffff0ff0 after the trace trap, when at
> > last one of the lower bits should be 1 (I think it's bit 0, from the code).
> >
> > I looked at the commit log between 4.18.4 and 4.18.5 but didn't see
> > anything obvious.
> >
> > Any idea ?
> >
> 
> Have you got a link to the test in question?

For example, dbregs_dr0_trap_code in 
https://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libc/sys/t_ptrace_x86_wait.h?rev=1.33;content-type=text%2Fplain

What's failing is
	ATF_REQUIRE_EQ(info.psi_siginfo.si_code, TRAP_DBREG);

I added printfs in the kernel to show the debug registers when
the process traps, this is where the 0xffff0ff0 value comes from.

-- 
Manuel Bouyer 
     NetBSD: 26 ans d'experience feront toujours la difference
--


From xen-devel-bounces@lists.xenproject.org Mon May 26 18:44:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 18:44:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997732.1378550 (Exim 4.92)
	(envelope-from )
	id 1uJcoD-0000Mq-D3; Mon, 26 May 2025 18:44:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997732.1378550; Mon, 26 May 2025 18: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 1uJcoD-0000Mj-A3; Mon, 26 May 2025 18:44:25 +0000
Received: by outflank-mailman (input) for mailman id 997732;
 Mon, 26 May 2025 18:44:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJcoB-0000Lp-Ic
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 18:44:23 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 707ef9d6-3a61-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 20:44:22 +0200 (CEST)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-acae7e7587dso323325566b.2
 for ; Mon, 26 May 2025 11:44:22 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad8741d84d2sm235449466b.157.2025.05.26.11.44.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 11:44: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" 
X-Inumbo-ID: 707ef9d6-3a61-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748285062; x=1748889862; darn=lists.xenproject.org;
        h=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;
        bh=7zbIUHxKfg9VMrK+vYDE2a0s1LLC/5CyFtnS/47115E=;
        b=m9vrs+Vl8Pgj0caHfR0ekupXtl+32uoHKWePCZAukROj+oFQP7Har0ST+odMPW1lkD
         Ra/OraHEHcaEE3/yZzIJj54ImBls1xfNdwr5aVgXfDSu1VEZhYEqEOK4XVocddkB6AxH
         3UJOjN+YFZs75tfJSq7O04/HMLP/uKOY3DVFDvNwEF7QFTHqq/UlCl1v5KzneNg/iCVm
         1K9A+9LJ7vU6pE1pKIdHiEhkcczQs3wi6MMrtyVLT7Tiumiymh8BFtBnK0Ne2Cf26eRG
         Jf7Ks4WHqs0r8Eamn5zTKCQqtN7PnM8ZBxXFBDOxeiuxYmW35jU+wd3GN2d/K4au2sUU
         TCDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748285062; x=1748889862;
        h=in-reply-to:content-language:references:cc:to:subject:from
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=7zbIUHxKfg9VMrK+vYDE2a0s1LLC/5CyFtnS/47115E=;
        b=ENm2QL70ENgRcTa/w0/u7zFKEBkG3RAcao3VwPFpmoxX4Vt6XX0DcKub+MJ5WOSThZ
         xXtTafh4iysNIKiHhULwgoqJYMcwgGNlJbR0TEpSQY9uvxDBBDQFMa8d4ilNe25VIoOf
         izcUrGvs4b7nNv7ckbwKJ32lJ6doak2Evnl6upOguYdgl+/zliEOobLVxXn3YgfCErJo
         x77i92oc60E+UB5UtczS7UDP83c/P0TLLweZ4JGPL7tAfyU9iQMzG3F4dPdXDDIW2H6s
         DUv9j1S5OSToHFEXnCDpO4/wn0bn9OTI4Q71ZUwDuww681UspAzvWAxfhC9zNeoV96IQ
         4k/A==
X-Forwarded-Encrypted: i=1; AJvYcCVGJJJh8YVcZW62IWqSxRUtNdQu+S4BWjjJogA7CPDkgi6vsVWaFLmnf1zil6lh0XtmJlTNNknM8RA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywu0iBC1i8AuYLOD6mVhe2fOKveiydi6vgf1X3pdfyHRaUwP2jZ
	jTxN8U0BdYMKLYq1ozj66/It8KkjQtxHmPUuHcMvMedaTfESALMeQhwj
X-Gm-Gg: ASbGncv1LYXEgiY2WpvgjpCr4cZhiGmkldzpGDp41RwozXz1eI50rjlgY12oG2ilHqO
	Fi62ZPIrsgxG1oDos3CUXaIMue2MCZm5LJObTmXBJAchiJpBNpGiR3fWwAHyatCeQwhCvf0Fi0K
	tPUc4piOyD1kVvNDJukfDiA9YtGuCC0DzIQq2xBC3MDkWCUNYyQe1HKd8vwJfVjxeIf+taGq7cm
	hPyko66S6GeExeRD8pPlZ3Q0swjhik1RIDeFlXn8nk0N73rs26gwcbqZLmX+wgfrGvXawykvv2w
	ZZzv9CE8+QwmYC54BAluAnoNszuUCrU1rXfGXzHTdD1/yKYTUxm5OmRek1dnRtnRkbXZFayET4f
	IUxGewFOeUbrR+PhlZEapkZSe
X-Google-Smtp-Source: AGHT+IFAcBXwB3Q1BettWjyewq6IJDsKoWpo6DQfqhZ2gm9sACTdlt+hpw2XLNmJ+dw6D+uMfkzLIQ==
X-Received: by 2002:a17:906:b84c:b0:ad8:883b:f10d with SMTP id a640c23a62f3a-ad8883bf140mr72433966b.34.1748285061378;
        Mon, 26 May 2025 11:44:21 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------b063iq5IA1s7JvZwmei5Oz9Y"
Message-ID: 
Date: Mon, 26 May 2025 20:44:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko 
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
In-Reply-To: 

This is a multi-part message in MIME format.
--------------b063iq5IA1s7JvZwmei5Oz9Y
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/22/25 4:46 PM, Jan Beulich wrote:
> On 21.05.2025 18:03, Oleksii Kurochko wrote:
>> --- /dev/null
>> +++ b/xen/arch/riscv/imsic.c
>> @@ -0,0 +1,354 @@
>> +/* SPDX-License-Identifier: MIT */
>> +
>> +/*
>> + * xen/arch/riscv/imsic.c
>> + *
>> + * RISC-V Incoming MSI Controller support
>> + *
>> + * (c) Microchip Technology Inc.
>> + * (c) Vates
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +static struct imsic_config imsic_cfg;
>> +
>> +    irq_range = xzalloc_array(uint32_t, *nr_parent_irqs * 2);
>> +    if ( !irq_range )
>> +        panic("%s: irq_range[] allocation failed\n", __func__);
>> +
>> +    if ( (rc = dt_property_read_u32_array(node, "interrupts-extended",
>> +                                    irq_range, *nr_parent_irqs * 2)) )
>> +        panic("%s: unable to find interrupt-extended in %s node: %d\n",
>> +              __func__, dt_node_full_name(node), rc);
>> +
>> +    if ( irq_range[1] == IRQ_M_EXT )
>> +    {
>> +        /* Machine mode imsic node, ignore it. */
>> +        rc = IRQ_M_EXT;
>> +        goto cleanup;
>> +    }
> Wouldn't this better be done ...
>
>> +    /* Check that interrupts-extended property is well-formed. */
>> +    for ( unsigned int i = 2; i < (*nr_parent_irqs * 2); i += 2 )
>> +    {
>> +        if ( irq_range[i + 1] != irq_range[1] )
>> +            panic("%s: mode[%d] != %d\n", __func__, i + 1, irq_range[1]);
>> +    }
> ... after this consistency check?

My intention was: if the first|irq_range| isn't|IRQ_M_EXT|, then there's no
point in parsing the full|interrupts-extended| property.

However, on the other hand, it might be important to ensure that the
|interrupts-extended| property is properly formed.

So yes, it makes sense to move the check above, before the|for| loop.

> Also %u please when you log unsigned values.
>
>> +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
>> +                               &imsic_cfg.guest_index_bits) )
>> +        imsic_cfg.guest_index_bits = 0;
>> +    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
>> +    if ( tmp < imsic_cfg.guest_index_bits )
>> +    {
>> +        printk(XENLOG_ERR "%s: guest index bits too big\n",
>> +               dt_node_name(node));
>> +        rc = -ENOENT;
>> +        goto cleanup;
>> +    }
>> +
>> +    /* Find number of HART index bits */
>> +    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>> +                               &imsic_cfg.hart_index_bits) )
>> +    {
>> +        /* Assume default value */
>> +        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
>> +        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>> +            imsic_cfg.hart_index_bits++;
> Since fls() returns a 1-based bit number, isn't it rather that in the
> exact-power-of-2 case you'd need to subtract 1?

Agree, in this case, -1 should be taken into account.


>> +    }
>> +    tmp -= imsic_cfg.guest_index_bits;
>> +    if ( tmp < imsic_cfg.hart_index_bits )
>> +    {
>> +        printk(XENLOG_ERR "%s: HART index bits too big\n",
>> +               dt_node_name(node));
>> +        rc = -ENOENT;
>> +        goto cleanup;
>> +    }
>> +
>> +    /* Find number of group index bits */
>> +    if ( !dt_property_read_u32(node, "riscv,group-index-bits",
>> +                               &imsic_cfg.group_index_bits) )
>> +        imsic_cfg.group_index_bits = 0;
>> +    tmp -= imsic_cfg.hart_index_bits;
>> +    if ( tmp < imsic_cfg.group_index_bits )
>> +    {
>> +        printk(XENLOG_ERR "%s: group index bits too big\n",
>> +               dt_node_name(node));
>> +        rc = -ENOENT;
>> +        goto cleanup;
>> +    }
>> +
>> +    /* Find first bit position of group index */
>> +    tmp = IMSIC_MMIO_PAGE_SHIFT * 2;
>> +    if ( !dt_property_read_u32(node, "riscv,group-index-shift",
>> +                               &imsic_cfg.group_index_shift) )
>> +        imsic_cfg.group_index_shift = tmp;
>> +    if ( imsic_cfg.group_index_shift < tmp )
>> +    {
>> +        printk(XENLOG_ERR "%s: group index shift too small\n",
>> +               dt_node_name(node));
>> +        rc = -ENOENT;
>> +        goto cleanup;
>> +    }
>> +    tmp = imsic_cfg.group_index_bits + imsic_cfg.group_index_shift - 1;
>> +    if ( tmp >= BITS_PER_LONG )
>> +    {
>> +        printk(XENLOG_ERR "%s: group index shift too big\n",
>> +               dt_node_name(node));
>> +        rc = -EINVAL;
>> +        goto cleanup;
>> +    }
>> +
>> +    /* Find number of interrupt identities */
>> +    if ( !dt_property_read_u32(node, "riscv,num-ids", &imsic_cfg.nr_ids) )
>> +    {
>> +        printk(XENLOG_ERR "%s: number of interrupt identities not found\n",
>> +               node->name);
>> +        rc = -ENOENT;
>> +        goto cleanup;
>> +    }
>> +
>> +    if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) ||
>> +         (imsic_cfg.nr_ids > IMSIC_MAX_ID) ||
>> +         ((imsic_cfg.nr_ids & IMSIC_MIN_ID) != IMSIC_MIN_ID) )
> Now that you've explained to me what the deal is with these constants: Isn't
> the 1st of the three checks redundant with the last one?

Agree, one of them could be dropped.

>> +/*
>> + * Initialize the imsic_cfg structure based on the IMSIC DT node.
>> + *
>> + * Returns 0 if initialization is successful, a negative value on failure,
>> + * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
>> + * which should be ignored by the hypervisor.
>> + */
>> +int __init imsic_init(const struct dt_device_node *node)
>> +{
>> +    int rc;
>> +    unsigned long reloff, hartid;
>> +    unsigned int nr_parent_irqs, index, nr_handlers = 0;
>> +    paddr_t base_addr;
>> +    unsigned int nr_mmios;
>> +
>> +    /* Parse IMSIC node */
>> +    rc = imsic_parse_node(node, &nr_parent_irqs);
>> +    /*
>> +     * If machine mode imsic node => ignore it.
>> +     * If rc < 0 => parsing of IMSIC DT node failed.
>> +     */
>> +    if ( (rc == IRQ_M_EXT) || rc )
>> +        return rc;
> The former of the checks is redundant with the latter. Did you perhaps mean
> "rc < 0" for that one?

Yes, like the comment is correct but in code I did a mistake.

>
>> +    nr_mmios = imsic_cfg.nr_mmios;
>> +
>> +    /* Allocate MMIO resource array */
>> +    imsic_cfg.mmios = xzalloc_array(struct imsic_mmios, nr_mmios);
> How large can this and ...
>
>> +    if ( !imsic_cfg.mmios )
>> +    {
>> +        rc = -ENOMEM;
>> +        goto imsic_init_err;
>> +    }
>> +
>> +    imsic_cfg.msi = xzalloc_array(struct imsic_msi, nr_parent_irqs);
> ... this array grow (in principle)?

Roughly speaking, this is the number of processors. The highests amount of processors
on the market I saw it was 32. But it was over a year ago when I last checked this.

>   I think you're aware that in principle
> new code is expected to use xvmalloc() and friends unless there are specific
> reasons speaking against that.

Oh, missed 'v'...

>
>> +    if ( !imsic_cfg.msi )
>> +    {
>> +        rc = -ENOMEM;
>> +        goto imsic_init_err;
>> +    }
>> +
>> +    /* Check MMIO register sets */
>> +    for ( unsigned int i = 0; i < nr_mmios; i++ )
>> +    {
>> +        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
>> +        {
>> +            rc = -ENOMEM;
>> +            goto imsic_init_err;
>> +        }
>> +
>> +        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
>> +                                   &imsic_cfg.mmios[i].size);
>> +        if ( rc )
>> +        {
>> +            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
>> +                   node->name, i);
>> +            goto imsic_init_err;
>> +        }
>> +
>> +        base_addr = imsic_cfg.mmios[i].base_addr;
>> +        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
>> +                           imsic_cfg.hart_index_bits +
>> +                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
>> +        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
>> +                       imsic_cfg.group_index_shift);
>> +        if ( base_addr != imsic_cfg.base_addr )
>> +        {
>> +            rc = -EINVAL;
>> +            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
>> +                   node->name, i);
>> +            goto imsic_init_err;
>> +        }
> Maybe just for my own understanding: There's no similar check for the
> sizes to match / be consistent wanted / needed?

If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will
provide, IMO.
So I don't what is possible range for imsic_cfg.mmios[i].size.

>> +    }
>> +
>> +    /* Configure handlers for target CPUs */
>> +    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
>> +    {
>> +        unsigned long xen_cpuid;
>> +
>> +        rc = imsic_get_parent_hartid(node, i, &hartid);
>> +        if ( rc )
>> +        {
>> +            printk(XENLOG_WARNING "%s: cpu ID for parent irq%u not found\n",
>> +                   node->name, i);
>> +            continue;
>> +        }
>> +
>> +        xen_cpuid = hartid_to_cpuid(hartid);
> I'm probably biased by "cpuid" having different meaning on x86, but: To
> be consistent with variable names elsewhere, couldn't this variable simply
> be named "cpu"? With the other item named "hartid" there's no ambiguity
> there anymore.

Sure, I will use "cpu"/"xen_cpu" for instead of xen_cpuid.

>
>> +        if ( xen_cpuid >= num_possible_cpus() )
>> +        {
>> +            printk(XENLOG_WARNING "%s: unsupported cpu ID=%lu for parent irq%u\n",
>> +                   node->name, hartid, i);
> The message continues to be ambiguous (to me as a non-RISC-V person at
> least): You log a hart ID, while you say "cpu ID". Also, as I think I
> said elsewhere already, the hart ID may better be logged using %#lx.

I will correct the message.

>> +        }
>> +
>> +        if ( index == nr_mmios )
>> +        {
>> +            printk(XENLOG_WARNING "%s: MMIO not found for parent irq%u\n",
>> +                   node->name, i);
>> +            continue;
>> +        }
>> +
>> +        if ( !IS_ALIGNED(imsic_cfg.msi[xen_cpuid].base_addr + reloff, PAGE_SIZE) )
> If this is the crucial thing to check, ...
>
>> +        {
>> +            printk(XENLOG_WARNING "%s: MMIO address %#lx is not aligned on a page\n",
>> +                   node->name, imsic_cfg.msi[xen_cpuid].base_addr + reloff);
>> +            imsic_cfg.msi[xen_cpuid].offset = 0;
>> +            imsic_cfg.msi[xen_cpuid].base_addr = 0;
>> +            continue;
>> +        }
>> +
>> +        cpumask_set_cpu(xen_cpuid, imsic_cfg.mmios[index].cpus);
>> +
>> +        imsic_cfg.msi[xen_cpuid].base_addr = imsic_cfg.mmios[index].base_addr;
>> +        imsic_cfg.msi[xen_cpuid].offset = reloff;
> ... why is it that the two parts are stored separately? If their sum needs to
> be page-aligned, I'd kind of expect it's only ever the sum which is used?

Because in APLIC's target register it is used only base_addr and which one interrupt
file to use is chosen by hart/guest index:
   static void vaplic_update_target(const struct imsic_config *imsic,
                                    int guest_id, unsigned long hart_id,
                                    uint32_t *value)
   {
       unsigned long group_index;
       uint32_t hhxw = imsic->group_index_bits;
       uint32_t lhxw = imsic->hart_index_bits;
       uint32_t hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2;
       unsigned long base_ppn = imsic->msi[hart_id].base_addr >> IMSIC_MMIO_PAGE_SHIFT;

       group_index = (base_ppn >> (hhxs + 12)) & (BIT(hhxw, UL) - 1);

       *value &= APLIC_TARGET_EIID_MASK;
       *value |= guest_id << APLIC_TARGET_GUEST_IDX_SHIFT;
       *value |= hart_id << APLIC_TARGET_HART_IDX_SHIFT;
       *value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT) ;
   }


> Also is it really PAGE_SHIFT or rather IMSIC_MMIO_PAGE_SHIFT that needs
> chacking against?

I think more correct will be IMSIC_MMIO_PAGE_SHIFT.

>
> Further please pay attention to line length limits - there are at least two
> violations around my earlier comment here.
>
>> --- /dev/null
>> +++ b/xen/arch/riscv/include/asm/imsic.h
>> @@ -0,0 +1,65 @@
>> +/* SPDX-License-Identifier: MIT */
>> +
>> +/*
>> + * xen/arch/riscv/include/asm/imsic.h
>> + *
>> + * RISC-V Incoming MSI Controller support
>> + *
>> + * (c) Microchip Technology Inc.
>> + */
>> +
>> +#ifndef ASM__RISCV__IMSIC_H
>> +#define ASM__RISCV__IMSIC_H
> Please update according to the most recent naming rules change (all it takes
> may be to shrink the double underscores).
>
>> +#include 
>> +
>> +#define IMSIC_MMIO_PAGE_SHIFT   12
>> +#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
>> +
>> +#define IMSIC_MIN_ID            63
>> +#define IMSIC_MAX_ID            2047
>> +
>> +struct imsic_msi {
>> +    paddr_t base_addr;
>> +    unsigned long offset;
>> +};
>> +
>> +struct imsic_mmios {
>> +    paddr_t base_addr;
>> +    unsigned long size;
>> +    cpumask_var_t cpus;
>> +};
>> +
>> +struct imsic_config {
>> +    /* Base address */
>> +    paddr_t base_addr;
>> +
>> +    /* Bits representing Guest index, HART index, and Group index */
>> +    unsigned int guest_index_bits;
>> +    unsigned int hart_index_bits;
>> +    unsigned int group_index_bits;
>> +    unsigned int group_index_shift;
>> +
>> +    /* IMSIC phandle */
>> +    unsigned int phandle;
>> +
>> +    /* Number of parent irq */
>> +    unsigned int nr_parent_irqs;
>> +
>> +    /* Number off interrupt identities */
>> +    unsigned int nr_ids;
>> +
>> +    /* MMIOs */
>> +    unsigned int nr_mmios;
>> +    struct imsic_mmios *mmios;
> Are the contents of this and ...
>
>> +    /* MSI */
>> +    struct imsic_msi *msi;
> ... this array ever changing post-init? If not, the pointers here may want
> to be pointer-to-const (requiring local variables in the function populating
> the field).

No, they will be initialized once.

Even more I think we can drop  *mmios and nr_mmios from this struct as it is used only
in imsic_init(), so could be allocated and freed there.

Only *msi is used in the function (vaplic_update_target) mentioned above.

>
>> @@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
>>       return pcpu_info[cpuid].hart_id;
>>   }
>>   
>> +static inline unsigned long hartid_to_cpuid(unsigned long hartid)
>> +{
>> +    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
>> +    {
>> +        if ( hartid == cpuid_to_hartid(cpuid) )
>> +            return cpuid;
>> +    }
>> +
>> +    /* hartid isn't valid for some reason */
>> +    return NR_CPUS;
>> +}
> Considering the values being returned, why's the function's return type
> "unsigned long"?

mhartid register has MXLEN length, so theoretically we could have from 0 to MXLEN-1
Harts and so we could have the same amount of Xen's CPUIDs. and MXLEN is 32 for RV32
and MXLEN is 64 for RV64.

>
> Why the use of ARRAY_SIZE() in the loop header? You don't use pcpu_info[]
> in the loop body.

I will chang to NR_CPUs. I thought that it would be more generic if pcpu_info will
be initialized with something else, not NR_CPUs, but I don't rembember why I think
it would be better.

>
> Finally - on big systems this is going to be pretty inefficient a lookup.
> This may want to at least have a TODO comment attached.

Sure, I will add.

Thanks.

~ Oleksii

--------------b063iq5IA1s7JvZwmei5Oz9Y
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/22/25 4:46 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 21.05.2025 18:03, Oleksii Kurochko wrote:

    
      
    
        
    --- /dev/null
+++ b/xen/arch/riscv/imsic.c
@@ -0,0 +1,354 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/imsic.c
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) Microchip Technology Inc.
+ * (c) Vates
+ */
+
+#include <xen/bitops.h>
+#include <xen/const.h>
+#include <xen/cpumask.h>
+#include <xen/device_tree.h>
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/macros.h>
+#include <xen/smp.h>
+#include <xen/spinlock.h>
+#include <xen/xmalloc.h>
+
+#include <asm/imsic.h>
+
+static struct imsic_config imsic_cfg;
+
+    irq_range = xzalloc_array(uint32_t, *nr_parent_irqs * 2);
+    if ( !irq_range )
+        panic("%s: irq_range[] allocation failed\n", __func__);
+
+    if ( (rc = dt_property_read_u32_array(node, "interrupts-extended",
+                                    irq_range, *nr_parent_irqs * 2)) )
+        panic("%s: unable to find interrupt-extended in %s node: %d\n",
+              __func__, dt_node_full_name(node), rc);
+
+    if ( irq_range[1] == IRQ_M_EXT )
+    {
+        /* Machine mode imsic node, ignore it. */
+        rc = IRQ_M_EXT;
+        goto cleanup;
+    }

    
      
    
      
    Wouldn't this better be done ...


    
      
    
        
    +    /* Check that interrupts-extended property is well-formed. */
+    for ( unsigned int i = 2; i < (*nr_parent_irqs * 2); i += 2 )
+    {
+        if ( irq_range[i + 1] != irq_range[1] )
+            panic("%s: mode[%d] != %d\n", __func__, i + 1, irq_range[1]);
+    }

    
      
    
      
    ... after this consistency check?
    
    
    
    
    My intention was: if the first irq_range isn't IRQ_M_EXT, then there's no
point in parsing the full interrupts-extended property.
    
    
    However, on the other hand, it might be important to ensure that the
interrupts-extended property is properly formed.

So yes, it makes sense to move the check above, before the for loop.

    
    
    
      
    Also %u please when you log unsigned values.


    
      
    
        
    +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
+                               &imsic_cfg.guest_index_bits) )
+        imsic_cfg.guest_index_bits = 0;
+    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
+    if ( tmp < imsic_cfg.guest_index_bits )
+    {
+        printk(XENLOG_ERR "%s: guest index bits too big\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    /* Find number of HART index bits */
+    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
+                               &imsic_cfg.hart_index_bits) )
+    {
+        /* Assume default value */
+        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
+        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
+            imsic_cfg.hart_index_bits++;

    
      
    
      
    Since fls() returns a 1-based bit number, isn't it rather that in the
exact-power-of-2 case you'd need to subtract 1?
    
    
    
    
    Agree, in this case, -1 should be taken into account.

    
    

    
    
    
    
    
      
    
        
    +    }
+    tmp -= imsic_cfg.guest_index_bits;
+    if ( tmp < imsic_cfg.hart_index_bits )
+    {
+        printk(XENLOG_ERR "%s: HART index bits too big\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    /* Find number of group index bits */
+    if ( !dt_property_read_u32(node, "riscv,group-index-bits",
+                               &imsic_cfg.group_index_bits) )
+        imsic_cfg.group_index_bits = 0;
+    tmp -= imsic_cfg.hart_index_bits;
+    if ( tmp < imsic_cfg.group_index_bits )
+    {
+        printk(XENLOG_ERR "%s: group index bits too big\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    /* Find first bit position of group index */
+    tmp = IMSIC_MMIO_PAGE_SHIFT * 2;
+    if ( !dt_property_read_u32(node, "riscv,group-index-shift",
+                               &imsic_cfg.group_index_shift) )
+        imsic_cfg.group_index_shift = tmp;
+    if ( imsic_cfg.group_index_shift < tmp )
+    {
+        printk(XENLOG_ERR "%s: group index shift too small\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+    tmp = imsic_cfg.group_index_bits + imsic_cfg.group_index_shift - 1;
+    if ( tmp >= BITS_PER_LONG )
+    {
+        printk(XENLOG_ERR "%s: group index shift too big\n",
+               dt_node_name(node));
+        rc = -EINVAL;
+        goto cleanup;
+    }
+
+    /* Find number of interrupt identities */
+    if ( !dt_property_read_u32(node, "riscv,num-ids", &imsic_cfg.nr_ids) )
+    {
+        printk(XENLOG_ERR "%s: number of interrupt identities not found\n",
+               node->name);
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) ||
+         (imsic_cfg.nr_ids > IMSIC_MAX_ID) ||
+         ((imsic_cfg.nr_ids & IMSIC_MIN_ID) != IMSIC_MIN_ID) )

    
      
    
      
    Now that you've explained to me what the deal is with these constants: Isn't
the 1st of the three checks redundant with the last one?

    
    
    
    
    Agree, one of them could be dropped.


    
    
    
      
    
        
    +/*
+ * Initialize the imsic_cfg structure based on the IMSIC DT node.
+ *
+ * Returns 0 if initialization is successful, a negative value on failure,
+ * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
+ * which should be ignored by the hypervisor.
+ */
+int __init imsic_init(const struct dt_device_node *node)
+{
+    int rc;
+    unsigned long reloff, hartid;
+    unsigned int nr_parent_irqs, index, nr_handlers = 0;
+    paddr_t base_addr;
+    unsigned int nr_mmios;
+
+    /* Parse IMSIC node */
+    rc = imsic_parse_node(node, &nr_parent_irqs);
+    /*
+     * If machine mode imsic node => ignore it.
+     * If rc < 0 => parsing of IMSIC DT node failed.
+     */
+    if ( (rc == IRQ_M_EXT) || rc )
+        return rc;

    
      
    
      
    The former of the checks is redundant with the latter. Did you perhaps mean
"rc < 0" for that one?
    
    
    
    
    Yes, like the comment is correct but in code I did a mistake.


    
    
    
      
    

    
      
    
        
    +    nr_mmios = imsic_cfg.nr_mmios;
+
+    /* Allocate MMIO resource array */
+    imsic_cfg.mmios = xzalloc_array(struct imsic_mmios, nr_mmios);

    
      
    
      
    How large can this and ...


    
      
    
        
    +    if ( !imsic_cfg.mmios )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    imsic_cfg.msi = xzalloc_array(struct imsic_msi, nr_parent_irqs);

    
      
    
      
    ... this array grow (in principle)?
    
    
    
    
    Roughly speaking, this is the number of processors. The highests amount of processors
on the market I saw it was 32. But it was over a year ago when I last checked this.


    
    
    
      
     I think you're aware that in principle
new code is expected to use xvmalloc() and friends unless there are specific
reasons speaking against that.
    
    
    
    
    Oh, missed 'v'...


    
    
    
      
    

    
      
    
        
    +    if ( !imsic_cfg.msi )
+    {
+        rc = -ENOMEM;
+        goto imsic_init_err;
+    }
+
+    /* Check MMIO register sets */
+    for ( unsigned int i = 0; i < nr_mmios; i++ )
+    {
+        if ( !alloc_cpumask_var(&imsic_cfg.mmios[i].cpus) )
+        {
+            rc = -ENOMEM;
+            goto imsic_init_err;
+        }
+
+        rc = dt_device_get_address(node, i, &imsic_cfg.mmios[i].base_addr,
+                                   &imsic_cfg.mmios[i].size);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%s: unable to parse MMIO regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }
+
+        base_addr = imsic_cfg.mmios[i].base_addr;
+        base_addr &= ~(BIT(imsic_cfg.guest_index_bits +
+                           imsic_cfg.hart_index_bits +
+                           IMSIC_MMIO_PAGE_SHIFT, UL) - 1);
+        base_addr &= ~((BIT(imsic_cfg.group_index_bits, UL) - 1) <<
+                       imsic_cfg.group_index_shift);
+        if ( base_addr != imsic_cfg.base_addr )
+        {
+            rc = -EINVAL;
+            printk(XENLOG_ERR "%s: address mismatch for regset %u\n",
+                   node->name, i);
+            goto imsic_init_err;
+        }

    
      
    
      
    Maybe just for my own understanding: There's no similar check for the
sizes to match / be consistent wanted / needed?

    
    
    
    
    If you are speaking about imsic_cfg.mmios[i].size then it depends fully on h/w will
provide, IMO.
So I don't what is possible range for imsic_cfg.mmios[i].size.


    
    
    
      
    
      
    
        
    +    }
+
+    /* Configure handlers for target CPUs */
+    for ( unsigned int i = 0; i < nr_parent_irqs; i++ )
+    {
+        unsigned long xen_cpuid;
+
+        rc = imsic_get_parent_hartid(node, i, &hartid);
+        if ( rc )
+        {
+            printk(XENLOG_WARNING "%s: cpu ID for parent irq%u not found\n",
+                   node->name, i);
+            continue;
+        }
+
+        xen_cpuid = hartid_to_cpuid(hartid);

    
      
    
      
    I'm probably biased by "cpuid" having different meaning on x86, but: To
be consistent with variable names elsewhere, couldn't this variable simply
be named "cpu"? With the other item named "hartid" there's no ambiguity
there anymore.
    
    
    
    
    Sure, I will use "cpu"/"xen_cpu" for instead of xen_cpuid.


    
    
    
      
    

    
      
    
        
    +        if ( xen_cpuid >= num_possible_cpus() )
+        {
+            printk(XENLOG_WARNING "%s: unsupported cpu ID=%lu for parent irq%u\n",
+                   node->name, hartid, i);

    
      
    
      
    The message continues to be ambiguous (to me as a non-RISC-V person at
least): You log a hart ID, while you say "cpu ID". Also, as I think I
said elsewhere already, the hart ID may better be logged using %#lx.
    
    
    
    
    I will correct the message.


    
    
    
      
    
        
    +        }
+
+        if ( index == nr_mmios )
+        {
+            printk(XENLOG_WARNING "%s: MMIO not found for parent irq%u\n",
+                   node->name, i);
+            continue;
+        }
+
+        if ( !IS_ALIGNED(imsic_cfg.msi[xen_cpuid].base_addr + reloff, PAGE_SIZE) )

    
      
    
      
    If this is the crucial thing to check, ...


    
      
    
        
    +        {
+            printk(XENLOG_WARNING "%s: MMIO address %#lx is not aligned on a page\n",
+                   node->name, imsic_cfg.msi[xen_cpuid].base_addr + reloff);
+            imsic_cfg.msi[xen_cpuid].offset = 0;
+            imsic_cfg.msi[xen_cpuid].base_addr = 0;
+            continue;
+        }
+
+        cpumask_set_cpu(xen_cpuid, imsic_cfg.mmios[index].cpus);
+
+        imsic_cfg.msi[xen_cpuid].base_addr = imsic_cfg.mmios[index].base_addr;
+        imsic_cfg.msi[xen_cpuid].offset = reloff;

    
      
    
      
    ... why is it that the two parts are stored separately? If their sum needs to
be page-aligned, I'd kind of expect it's only ever the sum which is used?

    
    
    
    
    Because in APLIC's target register it is used only base_addr and which one interrupt
file to use is chosen by hart/guest index:
  static void vaplic_update_target(const struct imsic_config *imsic,
                                   int guest_id, unsigned long hart_id,
                                   uint32_t *value)
  {
      unsigned long group_index;
      uint32_t hhxw = imsic->group_index_bits;
      uint32_t lhxw = imsic->hart_index_bits;
      uint32_t hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2;
      unsigned long base_ppn = imsic->msi[hart_id].base_addr >> IMSIC_MMIO_PAGE_SHIFT;

      group_index = (base_ppn >> (hhxs + 12)) & (BIT(hhxw, UL) - 1);

      *value &= APLIC_TARGET_EIID_MASK;
      *value |= guest_id << APLIC_TARGET_GUEST_IDX_SHIFT;
      *value |= hart_id << APLIC_TARGET_HART_IDX_SHIFT;
      *value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT) ;
  }



    
    
    
      
    Also is it really PAGE_SHIFT or rather IMSIC_MMIO_PAGE_SHIFT that needs
chacking against?
    
    
    
    
    I think more correct will be IMSIC_MMIO_PAGE_SHIFT.


    
    
    
      
    
Further please pay attention to line length limits - there are at least two
violations around my earlier comment here.


    
      
    
        
    --- /dev/null
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/include/asm/imsic.h
+ *
+ * RISC-V Incoming MSI Controller support
+ *
+ * (c) Microchip Technology Inc.
+ */
+
+#ifndef ASM__RISCV__IMSIC_H
+#define ASM__RISCV__IMSIC_H

    
      
    
      
    Please update according to the most recent naming rules change (all it takes
may be to shrink the double underscores).


    
      
    
        
    +#include <xen/types.h>
+
+#define IMSIC_MMIO_PAGE_SHIFT   12
+#define IMSIC_MMIO_PAGE_SZ      (1UL << IMSIC_MMIO_PAGE_SHIFT)
+
+#define IMSIC_MIN_ID            63
+#define IMSIC_MAX_ID            2047
+
+struct imsic_msi {
+    paddr_t base_addr;
+    unsigned long offset;
+};
+
+struct imsic_mmios {
+    paddr_t base_addr;
+    unsigned long size;
+    cpumask_var_t cpus;
+};
+
+struct imsic_config {
+    /* Base address */
+    paddr_t base_addr;
+
+    /* Bits representing Guest index, HART index, and Group index */
+    unsigned int guest_index_bits;
+    unsigned int hart_index_bits;
+    unsigned int group_index_bits;
+    unsigned int group_index_shift;
+
+    /* IMSIC phandle */
+    unsigned int phandle;
+
+    /* Number of parent irq */
+    unsigned int nr_parent_irqs;
+
+    /* Number off interrupt identities */
+    unsigned int nr_ids;
+
+    /* MMIOs */
+    unsigned int nr_mmios;
+    struct imsic_mmios *mmios;

    
      
    
      
    Are the contents of this and ...


    
      
    
        
    +    /* MSI */
+    struct imsic_msi *msi;

    
      
    
      
    ... this array ever changing post-init? If not, the pointers here may want
to be pointer-to-const (requiring local variables in the function populating
the field).
    
    
    
    
    No, they will be initialized once.

Even more I think we can drop  *mmios and nr_mmios from this struct as it is used only
in imsic_init(), so could be allocated and freed there.

Only *msi is used in the function (vaplic_update_target) mentioned above.

    
    
    
      
    

    
      
    
        
    @@ -18,6 +19,18 @@ static inline unsigned long cpuid_to_hartid(unsigned long cpuid)
     return pcpu_info[cpuid].hart_id;
 }
 
+static inline unsigned long hartid_to_cpuid(unsigned long hartid)
+{
+    for ( unsigned int cpuid = 0; cpuid < ARRAY_SIZE(pcpu_info); cpuid++ )
+    {
+        if ( hartid == cpuid_to_hartid(cpuid) )
+            return cpuid;
+    }
+
+    /* hartid isn't valid for some reason */
+    return NR_CPUS;
+}

    
      
    
      
    Considering the values being returned, why's the function's return type
"unsigned long"?
    
    
    
    
    mhartid register has MXLEN length, so theoretically we could have from 0 to MXLEN-1
Harts and so we could have the same amount of Xen's CPUIDs. and MXLEN is 32 for RV32
and MXLEN is 64 for RV64.


    
    
    
      
    
Why the use of ARRAY_SIZE() in the loop header? You don't use pcpu_info[]
in the loop body.
    
    
    
    
    I will chang to NR_CPUs. I thought that it would be more generic if pcpu_info will
be initialized with something else, not NR_CPUs, but I don't rembember why I think
it would be better.

    
    
    
      
    
Finally - on big systems this is going to be pretty inefficient a lookup.
This may want to at least have a TODO comment attached.
    
    
    
    
    Sure, I will add.

Thanks.

~ Oleksii
    
  


--------------b063iq5IA1s7JvZwmei5Oz9Y--


From xen-devel-bounces@lists.xenproject.org Mon May 26 18:46:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 18:46:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997746.1378560 (Exim 4.92)
	(envelope-from )
	id 1uJcqR-0000yB-So; Mon, 26 May 2025 18:46:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997746.1378560; Mon, 26 May 2025 18: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 1uJcqR-0000y4-Pa; Mon, 26 May 2025 18:46:43 +0000
Received: by outflank-mailman (input) for mailman id 997746;
 Mon, 26 May 2025 18:46:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJcqQ-0000xh-7p
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 18:46:42 +0000
Received: from chassiron.antioche.eu.org (chassiron.antioche.eu.org
 [2001:41d0:fc2c:4d01::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c27e8e8c-3a61-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 20:46:40 +0200 (CEST)
Received: from rochebonne.antioche.eu.org (rochebonne [10.0.0.1])
 by chassiron.antioche.eu.org (8.18.1/8.16.1) with ESMTP id 54QIkcGX017645;
 Mon, 26 May 2025 20:46:38 +0200 (MEST)
Received: by rochebonne.antioche.eu.org (Postfix, from userid 1210)
 id 3E33D1A4D0; Mon, 26 May 2025 20:46: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" 
X-Inumbo-ID: c27e8e8c-3a61-11f0-b893-0df219b8e170
Date: Mon, 26 May 2025 20:46:04 +0200
From: Manuel Bouyer 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org
Subject: Re: Xen 4.18.5 PV dbregs fail
Message-ID: 
References: 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (chassiron.antioche.eu.org [109.190.99.82]); Mon, 26 May 2025 20:46:39 +0200 (MEST)

On Mon, May 26, 2025 at 07:17:13PM +0100, Andrew Cooper wrote:
> On 26/05/2025 7:06 pm, Andrew Cooper wrote:
> > On 26/05/2025 6:59 pm, Manuel Bouyer wrote:
> >> Hello,
> >> since I updated to Xen 4.18.5 (from 4.18.4), NetBSD's dbregs-related tests
> >> are failing. Only for PV; PVH and HVM guests are fine. They are
> >> failing for both 32bits and 64bits guests.
> >>
> >> I tracked it down to dr6 being 0xffff0ff0 after the trace trap, when at
> >> last one of the lower bits should be 1 (I think it's bit 0, from the code).
> >>
> >> I looked at the commit log between 4.18.4 and 4.18.5 but didn't see
> >> anything obvious.
> >>
> >> Any idea ?
> >>
> > Have you got a link to the test in question?
> >
> > We've had a couple of bugfixes in this area, although debug handling
> > isn't helped by the fact that both the SDM and APM are factually
> > incorrect on how to write a #DB handler (and the vendors are moving at a
> > glacial pace to correct them).
> 
> But yes, having looked between 4.18.4 and 4.18.5, I can't see anything
> relevant to debug handling either.
> 
> Judging from your description, it looks like a breakpoint is going missing.
> 
> The relevant recent change for that is
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=54ef601a66e8d812a6a6a308f02524e81201825e
> although it's a bit older than 4.18.4.

Well, my previous xen-debug.gz kernel is from Oct, 3 so it can't be
4.18.4, it's 4.18.3_20240909 which points to commit
bd51e573a730efc569646379cd59ccba967cde97

looks like I forgot to update this server. So I need to looks deeper in
the commit logs

-- 
Manuel Bouyer 
     NetBSD: 26 ans d'experience feront toujours la difference
--


From xen-devel-bounces@lists.xenproject.org Mon May 26 18:50:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 18:50:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997756.1378569 (Exim 4.92)
	(envelope-from )
	id 1uJctv-0002SY-9v; Mon, 26 May 2025 18:50:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997756.1378569; Mon, 26 May 2025 18:50: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 1uJctv-0002SR-7C; Mon, 26 May 2025 18:50:19 +0000
Received: by outflank-mailman (input) for mailman id 997756;
 Mon, 26 May 2025 18:50:17 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJctt-0002SL-DQ
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 18:50:17 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 43213846-3a62-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 20:50:15 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a4d877dfb3so1470337f8f.1
 for ; Mon, 26 May 2025 11:50:15 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4dc1172ecsm2772568f8f.48.2025.05.26.11.50.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 11: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" 
X-Inumbo-ID: 43213846-3a62-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748285415; x=1748890215; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=dMgi0QgXs77Mpd4Q9ev0Za22fefEGuaIzkhcn020kQs=;
        b=KZrfO07bNh8nJAPXbtk+/JWhWWBs8Wnc2eN2qFMrLg224EkxlQsHo3+SybbJReldvJ
         7VlUu2xK1h65edozRQQc0Wp/0rl0Wt4o6xA2VEvVt9qUc6uC33n/VF07yyjio9Kc2wSA
         9uzEEV1jPxgskTeHz8UNxMwJQ+uycp8gO3z4I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748285415; x=1748890215;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=dMgi0QgXs77Mpd4Q9ev0Za22fefEGuaIzkhcn020kQs=;
        b=WcWS2kAqlYX4cvXxcqsKcF6CNxj6noAuoGmqUqc4axE1LVh6xc6OLQbrQJFivBR3Lh
         Te4ApMzlrlz2n8cWcz2wucoCcUnFfIKkLW1Rf1Q7Iv7EP2eEuRb3r8jCFODFiFedy2rX
         7kIX8kOqoH5ob7z+T4288xf6l59Uj9Uf1gozaFkqEUbzlOLCKMyvK7v0OiZTHbgd+by+
         ULfKQ9vSF0vuB2CJYxRIPGBfrh1Q8cV+ZFerbtd5jN/NhZGho2Ybl2f6TUFwBPbTTaxM
         Rt0qUt59zrPbOdOB86e8yvM7sluS1VWAN+6SRiveOT6SNtf6NgeRICfmkfbtXGaU+v6Z
         viTA==
X-Gm-Message-State: AOJu0Yxajx7D23ocYtxpODAobiCwmkoNgwiGf8NHXQaVgzbKds8vCDVo
	Ento2uxRnkb1ZUkvd5VZlSwZPccN8DafiC1OvKxP5nr9CFiCWFw+a2Mveg0HyJe0wTUDsLfRoAC
	zn11x
X-Gm-Gg: ASbGncv2xLFGmVL9ATtFwkPofiGw3Is1kUsnL/MRHkMKOW0QZv8J4W/98I5Bcep2M+Q
	Y02+wwDxR6dW6AVREU9PdNYZeZ6jZjx61BlHEEyLLGP8q1SvpnYgOl0FxvFOWChuGd2G6R8vVH9
	6dcfAHYyRpxEeOfXlZbl/wzaW3zpQ9PQqzv5Chd8cTegNoLxEKntlYxmTwaxzb5q9pbapKlmbP2
	c8TUN8b2At+xgpAI1yih1fuqeVwuNvK9ShdHRz+bbVXxB3UqSNeV5Jkbudh3DZex+TP/n6XKmE0
	tE4fXXS/0ixaShf2/YxbyFZQuoiuy0+dkEIyTJ7QWtoCAy10AwsqE4qpKPHOVsE4PGDf4HcSINI
	6ue9L+UFMKX8z6nFmXyidBtROny0=
X-Google-Smtp-Source: AGHT+IF/TtQ3KdmmZVTgqVxqmuJrezXc3EmQatcxi9rTtJeDECxBjDhi4G+0NHVwDK/ACkMuDeT4kg==
X-Received: by 2002:a05:6000:4203:b0:3a3:6595:9209 with SMTP id ffacd0b85a97d-3a4cb4899e8mr8332909f8f.36.1748285415081;
        Mon, 26 May 2025 11:50:15 -0700 (PDT)
Message-ID: <0733f3dc-9f01-4e15-98ab-d7fd7c3e303d@citrix.com>
Date: Mon, 26 May 2025 19:50:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen 4.18.5 PV dbregs fail
To: Manuel Bouyer 
Cc: 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

On 26/05/2025 7:46 pm, Manuel Bouyer wrote:
> On Mon, May 26, 2025 at 07:17:13PM +0100, Andrew Cooper wrote:
>> On 26/05/2025 7:06 pm, Andrew Cooper wrote:
>>> On 26/05/2025 6:59 pm, Manuel Bouyer wrote:
>>>> Hello,
>>>> since I updated to Xen 4.18.5 (from 4.18.4), NetBSD's dbregs-related tests
>>>> are failing. Only for PV; PVH and HVM guests are fine. They are
>>>> failing for both 32bits and 64bits guests.
>>>>
>>>> I tracked it down to dr6 being 0xffff0ff0 after the trace trap, when at
>>>> last one of the lower bits should be 1 (I think it's bit 0, from the code).
>>>>
>>>> I looked at the commit log between 4.18.4 and 4.18.5 but didn't see
>>>> anything obvious.
>>>>
>>>> Any idea ?
>>>>
>>> Have you got a link to the test in question?
>>>
>>> We've had a couple of bugfixes in this area, although debug handling
>>> isn't helped by the fact that both the SDM and APM are factually
>>> incorrect on how to write a #DB handler (and the vendors are moving at a
>>> glacial pace to correct them).
>> But yes, having looked between 4.18.4 and 4.18.5, I can't see anything
>> relevant to debug handling either.
>>
>> Judging from your description, it looks like a breakpoint is going missing.
>>
>> The relevant recent change for that is
>> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=54ef601a66e8d812a6a6a308f02524e81201825e
>> although it's a bit older than 4.18.4.
> Well, my previous xen-debug.gz kernel is from Oct, 3 so it can't be
> 4.18.4, it's 4.18.3_20240909 which points to commit
> bd51e573a730efc569646379cd59ccba967cde97
>
> looks like I forgot to update this server. So I need to looks deeper in
> the commit logs

Well, that range does include the aforementioned commit.

Can you bisect around d32c77f471fb8400b6512c171a14cdd58f04f0a3 which is
the backport of ^ in 4.18 ?

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 26 20:14:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 20:14:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997769.1378584 (Exim 4.92)
	(envelope-from )
	id 1uJeDI-000421-8L; Mon, 26 May 2025 20:14:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997769.1378584; Mon, 26 May 2025 20:14:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJeDI-00041o-3z; Mon, 26 May 2025 20:14:24 +0000
Received: by outflank-mailman (input) for mailman id 997769;
 Mon, 26 May 2025 20:14:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJeDG-00040P-Kl
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 20:14:22 +0000
Received: from chassiron.antioche.eu.org (chassiron.antioche.eu.org
 [2001:41d0:fc2c:4d01::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0140dfbe-3a6e-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 22:14:19 +0200 (CEST)
Received: from rochebonne.antioche.eu.org
 ([IPv6:2001:41d0:fc2c:4d00:96de:80ff:fe21:bec0])
 by chassiron.antioche.eu.org (8.18.1/8.16.1) with ESMTP id 54QKEEee007167;
 Mon, 26 May 2025 22:14:15 +0200 (MEST)
Received: by rochebonne.antioche.eu.org (Postfix, from userid 1210)
 id 447071A4D0; Mon, 26 May 2025 22:13: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" 
X-Inumbo-ID: 0140dfbe-3a6e-11f0-b893-0df219b8e170
Date: Mon, 26 May 2025 22:13:40 +0200
From: Manuel Bouyer 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org
Subject: Re: Xen 4.18.5 PV dbregs fail
Message-ID: 
References: 
 
 
 
 <0733f3dc-9f01-4e15-98ab-d7fd7c3e303d@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0733f3dc-9f01-4e15-98ab-d7fd7c3e303d@citrix.com>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (chassiron.antioche.eu.org [IPv6:2001:41d0:fc2c:4d01:0:0:0:1]); Mon, 26 May 2025 22:14:15 +0200 (MEST)

On Mon, May 26, 2025 at 07:50:14PM +0100, Andrew Cooper wrote:
> [...]
> Well, that range does include the aforementioned commit.
> 
> Can you bisect around d32c77f471fb8400b6512c171a14cdd58f04f0a3 which is
> the backport of ^ in 4.18 ?

Sure,
with 0d5f15e and d32c77f the test pass, with cecee35 it fails.

-- 
Manuel Bouyer 
     NetBSD: 26 ans d'experience feront toujours la difference
--


From xen-devel-bounces@lists.xenproject.org Mon May 26 20:31:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 20:31:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997777.1378594 (Exim 4.92)
	(envelope-from )
	id 1uJeTN-0006d0-I3; Mon, 26 May 2025 20:31:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997777.1378594; Mon, 26 May 2025 20: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 1uJeTN-0006ct-EG; Mon, 26 May 2025 20:31:01 +0000
Received: by outflank-mailman (input) for mailman id 997777;
 Mon, 26 May 2025 20:31:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJeTM-0006cn-F4
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 20:31:00 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 52cde1e9-3a70-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 22:30:55 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43ce71582e9so23940175e9.1
 for ; Mon, 26 May 2025 13:30:55 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f23c07bfsm248208045e9.23.2025.05.26.13.30.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 13:30: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" 
X-Inumbo-ID: 52cde1e9-3a70-11f0-b893-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748291454; x=1748896254; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=IcSCIPKCYzq3xMUPyqz+c2UB2LSl8Sj1A3zJWV6wQU8=;
        b=PZN0HNSzxtQ4jziHDMp7nWDGeZD7i8kvpvdFzgdY9Z4S5qKjZ/jaxiwKH0cnVVl7zL
         reu+6Eimm45EERFOLSgu9PXgiWPu2sjwTgnjgqUS6NkoWWmTJBEdkgXsx/1n0VF+amE9
         wpIVg/gXaQvS57bHlubgcnR3gkezOlyYq4unk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748291454; x=1748896254;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IcSCIPKCYzq3xMUPyqz+c2UB2LSl8Sj1A3zJWV6wQU8=;
        b=gVksy0IvAmFDp2WkGJ0cHDfTyquPyriNTxTeIdHk9FgoTT/d9vZ3HZovm5K5QJJhQX
         q7Cdm7f8XzXZW+7/CSH7gIHEP8QcYOmXI6cO1TQ7eMK0jyePqQ4JZBEHZSDuL7W5z3jG
         3GxmiGNmlUDUHOztnA0cSDhtyN7itEC5GUTq0UoHBZ8WasFCLcJk6I9LgRtSWoAHHVCa
         q5zyspq3MciDKnWx9X3YkeYDGMMt5rqQpJSaPJkvnp7e7wscOZDB9h8O4nReSxmHe5gj
         rCMJT6mxl7seK1+Trs0IDPtfy8M6lbzNu4+6bKiYsBjSo+Z2AwyNdriM20wNq22wdcXP
         y/vw==
X-Gm-Message-State: AOJu0YwcdW8Mci/7imW83Jsqq2G4FYibnghtHILo/7JpU6EM7yqMpyAZ
	6UT0MhRfTpIb0jtTW0dd9OfROzlz03nmovmxKAjSbb3AZYVWzsq+Mv6HvmRMOQ241LTrwwdtFVF
	qqf06
X-Gm-Gg: ASbGnctvZ0IalwzPLMeqYDCn0KHADswwY7J5ULfCAIUnXz3XFX4P7PFGYUtWPvorPGU
	7wx/polrPvrn3lHPIyEL8zrEUt4s9bzy6s48gcsEvrs44g7NgUZqf7hqqVet2CipDQl5YTgz/U/
	yC6UPP3+xIZLrj7kw+UorXkS0S31VBi6vXGMt+b/vQL+BtzzE8NDgY11uUDS1JyAynQzxUF6/yO
	YtlxPSHy07zZtkuAo4NZpiBHT6qf+D0ccHSL+dF6pzUBUd/gzj3yNHDi2TVmO8aGj7rnPctczDb
	/R9aKDCuU64eLud0/N/AqmWzp80XiptKWByJh/3mxzMtksgXu/sx4iMoJdeCBv/+8YBJ7Tdmlb3
	5UDypiCxTAZddHzQv
X-Google-Smtp-Source: AGHT+IF7reztmZ3BQHn1M9VVzMOPz5+ZOHv1u3l0bkqIiNtWbZ0SktchYVfi+UnzOu4J+dOQvr0pQw==
X-Received: by 2002:a05:600c:512a:b0:44b:2f53:351c with SMTP id 5b1f17b1804b1-44c91dcb6e7mr96586375e9.18.1748291454393;
        Mon, 26 May 2025 13:30:54 -0700 (PDT)
Message-ID: 
Date: Mon, 26 May 2025 21:30:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen 4.18.5 PV dbregs fail
To: Manuel Bouyer 
Cc: xen-devel@lists.xenproject.org
References: 
 
 
 
 <0733f3dc-9f01-4e15-98ab-d7fd7c3e303d@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

On 26/05/2025 9:13 pm, Manuel Bouyer wrote:
> On Mon, May 26, 2025 at 07:50:14PM +0100, Andrew Cooper wrote:
>> [...]
>> Well, that range does include the aforementioned commit.
>>
>> Can you bisect around d32c77f471fb8400b6512c171a14cdd58f04f0a3 which is
>> the backport of ^ in 4.18 ?
> Sure,
> with 0d5f15e and d32c77f the test pass, with cecee35 it fails.
>

Oh interesting, so the basic forwarding of #DB back into a guest
(d32c77f) works fine, but the changes to emulated debug exceptions
(cecee35) break.

Anyway, I think I've spotted a logical error.  We do indeed end up
calling x86_merge_dr6() twice, because of the TODO just out of context. 
Does this help?

~Andrew


diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 6d75b59b1e97..01b8be02b055 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1798,7 +1798,7 @@ void asmlinkage do_debug(struct cpu_user_regs *regs)
         return;
     }
 
-    pv_inject_DB(0 /* N/A, already merged */);
+    pv_inject_DB(dr6 ^ X86_DR6_DEFAULT);
 }
 
 void asmlinkage do_entry_CP(struct cpu_user_regs *regs)



From xen-devel-bounces@lists.xenproject.org Mon May 26 20:32:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 20:32:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997784.1378603 (Exim 4.92)
	(envelope-from )
	id 1uJeV2-00078Z-RF; Mon, 26 May 2025 20:32:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997784.1378603; Mon, 26 May 2025 20:32: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 1uJeV2-00078S-Oe; Mon, 26 May 2025 20:32:44 +0000
Received: by outflank-mailman (input) for mailman id 997784;
 Mon, 26 May 2025 20:32:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJeV1-000786-8j
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 20:32:43 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 91fd5cff-3a70-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 22:32:41 +0200 (CEST)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id C455B4EE8E26;
 Mon, 26 May 2025 22:32: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" 
X-Inumbo-ID: 91fd5cff-3a70-11f0-a2fb-13f23c93f187
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=1748291560;
	b=Rl6FSbowBz+CBbxdZSW/FKWeAERgigb1sJCek7f5H4pmXVh3IlfomFMWp23lKbEGlcff
	 qBKPra2NqdlEkzGUaMaxj7t853CO7IAEVYFBaLixVcXphN2mB9u+XCAWxSGTkgVg4wZD8
	 IxtzCBWHCuwpZOrYRwZqNIpiVIMHp4OosIdEL7hIYIpJFi22n3vyXqQe86/1TMa5G2Rax
	 1+2EZZvfYZHA/yIIUh94r3eECtdEBd3RKR//8FPm4P7yeVD4csNt1VWXDi1FImTKYUt1B
	 eNOvHfzwklR9i2hp5/aAci9rqEISDC3Jj2PbVi3oAc7xgk0en9sJAiBfHZWKNapLwYHOX
	 sQSuWLydGqUxnB64rjV7KrmR/mZjiXsrOkALdfZYYcYJgrZ8CmBPJ9qQ01WefAU/DHrrb
	 xSJm7PxGMHCXxWNbYR+CFfKpXwY6Fqcfw4uzhT0mxr7zj+DjZnMCLqWedBlvA9Z/lERxu
	 ACgK42uUuwrTPquwDfClYTFnfKz8jmfq0hiugUDoFOvJVoQ7iko+qTfV8gJKLl1kh1Ab5
	 7J1k9UGDo5u/91MNTiFXB2TnC00Wm+Pcqg7qgRzevEHQI0mORth++oj7Zwte6/AlcJShx
	 lO1wqZG2a4GLZHntd+tcoOaLhmYEIknSXEShug4K/7yFc01K85DcQg88ik1QlMo=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1748291560;
	h=DKIM-Signature:MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:
	 References:Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=8yUKAiDNYHfFbobrtgzhNXm2dFqyLcF4xxhdylDJrr4=;
	b=rSa4pMdHYhCOuteng9oXdAv8HmbGM9xrYzKqNQCiqw58qF6rgmnUWcchpjC9NXnzwIKB
	 YCfOnfwJTqvN4470zPU11TPfO3WgPWhtF6/uKxVXjbz9Dm22KQAK/EwnxW+evfviUVa/q
	 LHKkjLZ8+0iNYJUjUaRPwvkyrL5xjzOogCi7WKmbbmclmspRU1MZCNh/LnMNQqM4YR5Qe
	 apfZvnM7QNN7BK87loRpRvaIFJ+qviIgtXtmwhki2kR8ytxbo7xC2H6MJDj/bcuq+5YBe
	 oIAC1tk7W7ihZuwYwCCTds23rUo9JHsF2WIeYtkripsfn9Xf8ZhImcCs94WuMSy1OPOyZ
	 Fywbu22JU6fXIQUulr+en5lw1ftPqCSMAufXjTcH0uRXLNloxWT/aLx7U48TGFz2S4yQX
	 9ms9p00F05eC0QOE93bm4l8/Fm14wpHlY3F7pIDrg9hhEw1bX6NMPYhUPntpPTxWWwG9t
	 AVi25XvWZm0BxCe6DNqUhs8qPrptUZJ27X2RALG4LHs761vjrLxHBstp9sQtPC1vEbTlm
	 2AuBlxFmXw/L024w/MN+Xwxq2SWOS0sY1Bpxc+v8RMHWso6wOeme2Sgbm/wQOCkgLD5cb
	 OtzFmy9Sme8I6LBt4bRsvO1evFWpDOuwUAOgauFSXSR2whxaFrNOzJYM0jjHFSo=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1748291560; bh=KLnQtA+kgQvNLbrHD0a5M+wnASmHFfwYRWwS/5XvNNw=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=vMFCPOjmdE650tiiyMyyQl99f9JuLjbRcvfkKmwpzhgEx7AZXp5a8kh+VRR+4NuXS
	 0RZ1cmXLTK13n46M2qnN5VYDKRbuZBtHt1YPlz6de0O+0CA5odYGiZQrLJbB4r3BVr
	 OUKpE9n496+t5KS7ECK0Bnwb8vB/sdRkuhRcdOm4ReHwT+OgPZxKph1WGj5zOUln0D
	 HEPm9zsKCllDa9dSyylAGiC+AikgwfDzeoOu64wT1gtIBwK20kPSHWbL8JIVYeVt2g
	 9NQzdhgDuRDDHmvoSt53M6odWXlhMi2OyzXyfmsEiIcBGQGV3pxuEDpEIAx7dxKcjj
	 bqnm6x7tl1rCw==
MIME-Version: 1.0
Date: Mon, 26 May 2025 22:32:40 +0200
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: Xen-devel , Jan Beulich
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , consulting@bugseng.com, Stefano Stabellini
 
Subject: Re: [Eclair false positive] Re: [PATCH] x86/msr: Rework wrmsr_safe()
 using asm goto()
In-Reply-To: <76634ee243f9e51a777428904a8c0d5d@bugseng.com>
References: <20250521143658.312514-1-andrew.cooper3@citrix.com>
 <8504aab1-c48a-4981-a502-93a2fd18880b@citrix.com>
 
 <49f092f9-c0fb-4b66-af20-368c736dde91@citrix.com>
 <526fe46bf2e4b5985d1b8cd3361e5730@bugseng.com>
 
 <76634ee243f9e51a777428904a8c0d5d@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

On 2025-05-25 15:36, Nicola Vetrini wrote:
> On 2025-05-25 12:52, Andrew Cooper wrote:
>> On 25/05/2025 8:34 am, Nicola Vetrini wrote:
>>> On 2025-05-22 15:49, Andrew Cooper wrote:
>>>> On 22/05/2025 1:45 pm, Nicola Vetrini wrote:
>>>>> On 2025-05-21 20:00, Andrew Cooper wrote:
>>>>>> On 21/05/2025 3:36 pm, Andrew Cooper wrote:
>>>>>>> diff --git a/xen/arch/x86/include/asm/msr.h
>>>>>>> b/xen/arch/x86/include/asm/msr.h
>>>>>>> index 0d3b1d637488..4c4f18b3a54d 100644
>>>>>>> --- a/xen/arch/x86/include/asm/msr.h
>>>>>>> +++ b/xen/arch/x86/include/asm/msr.h
>>>>>>> @@ -69,20 +69,20 @@ static inline void wrmsr_ns(uint32_t msr,
>>>>>>> uint32_t lo, uint32_t hi)
>>>>>>>  /* wrmsr with exception handling */
>>>>>>>  static inline int wrmsr_safe(unsigned int msr, uint64_t val)
>>>>>>>  {
>>>>>>> -    int rc;
>>>>>>> -    uint32_t lo, hi;
>>>>>>> -    lo = (uint32_t)val;
>>>>>>> -    hi = (uint32_t)(val >> 32);
>>>>>>> -
>>>>>>> -    __asm__ __volatile__(
>>>>>>> -        "1: wrmsr\n2:\n"
>>>>>>> -        ".section .fixup,\"ax\"\n"
>>>>>>> -        "3: movl %5,%0\n; jmp 2b\n"
>>>>>>> -        ".previous\n"
>>>>>>> -        _ASM_EXTABLE(1b, 3b)
>>>>>>> -        : "=&r" (rc)
>>>>>>> -        : "c" (msr), "a" (lo), "d" (hi), "0" (0), "i" 
>>>>>>> (-EFAULT));
>>>>>>> -    return rc;
>>>>>>> +    uint32_t lo = val, hi = val >> 32;
>>>>>>> +
>>>>>>> +    asm_inline goto (
>>>>>>> +        "1: wrmsr\n\t"
>>>>>>> +        _ASM_EXTABLE(1b, %l[fault])
>>>>>>> +        :
>>>>>>> +        : "a" (lo), "c" (msr), "d" (hi)
>>>>>>> +        :
>>>>>>> +        : fault );
>>>>>>> +
>>>>>>> +    return 0;
>>>>>>> +
>>>>>>> + fault:
>>>>>>> +    return -EFAULT;
>>>>>>>  }
>>>>>> 
>>>>>> It turns out this is the first piece of Eclair-scanned code using 
>>>>>> asm
>>>>>> goto.
>>>>>> 
>>>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/10108558677
>>>>>> (The run also contained an equivalent change to xsetbv())
>>>>>> 
>>>>>> We're getting R1.1 and R2.6 violations.
>>>>>> 
>>>>>> R1.1 complains about [STD.adrslabl] "label address" not being 
>>>>>> valid
>>>>>> C99.
>>>>>> 
>>>>>> R2.6 complains about unused labels.
>>>>>> 
>>>>>> I expect this means that Eclair doesn't know how to interpret asm
>>>>>> goto()
>>>>>> yet.  The labels listed are reachable from inside the asm block.
>>>>>> 
>>>>> 
>>>>> That has been fixed upstream. I'll reach out to you when that fix
>>>>> trickles down to the runners, so that you're able to test and push
>>>>> that change.
>>>> 
>>>> Oh, fantastic thanks.
>>>> 
>>>> I'll hold off pushing until then.
>>>> 
>>>> ~Andrew
>>> 
>>> Hi Andrew,
>>> 
>>> both runners are now updated with the new images, so you can rerun 
>>> the
>>> tests.
>> 
>> Both Eclair runs are unhappy, and not even completing analysis.
>> 
>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1835567532
>> 
>> This is the same branch as before, plus your config change for R1.1
>> 
>> ~Andrew
> 
> There might be something wrong with the image I used, it's erroring on 
> a speculative call to the compiler. I rolled back to the previous 
> images (without the fix for R2.6). I will investigate tomorrow.

Fixed, I will let you know when runners are updated. It was a change 
unrelated to Rule 2.6.

Thanks,
  Nicola

-- 
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 May 26 20:53:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 20:53:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997799.1378614 (Exim 4.92)
	(envelope-from )
	id 1uJeom-0001hB-Ii; Mon, 26 May 2025 20:53:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997799.1378614; Mon, 26 May 2025 20:53: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 1uJeom-0001h4-GB; Mon, 26 May 2025 20:53:08 +0000
Received: by outflank-mailman (input) for mailman id 997799;
 Mon, 26 May 2025 20:53:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJeom-0001gy-2C
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 20:53:08 +0000
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [2a00:1450:4864:20::336])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6be53ef9-3a73-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 22:53:05 +0200 (CEST)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-442ea341570so18939665e9.1
 for ; Mon, 26 May 2025 13:53:05 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f18251basm243682185e9.4.2025.05.26.13.53.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 26 May 2025 13:53: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" 
X-Inumbo-ID: 6be53ef9-3a73-11f0-b893-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748292785; x=1748897585; 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;
        bh=Qb25bEXVG3p9CU9Sg8KmV/sBuke8+/L1M/Zbvd+67i8=;
        b=aeIEDEZM9nnq7weJdN+06u4w3NXYTGKHJQuQJiMWS3Kn+OPyT1UFoWFjEycmUgO2BV
         Kb6De4PD7nZi4ZUQpS0wCXrqc1LlDGNgLvncFzXGhBAcjA/zjwfwI2SfNFfHBFYnnuPB
         3Y4pGTZiPT4fmVK+gHLZaKehVHR/txpQfqjHw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748292785; x=1748897585;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Qb25bEXVG3p9CU9Sg8KmV/sBuke8+/L1M/Zbvd+67i8=;
        b=ZiX85G8Qw6nrwMjZ2MAXKY3yOHa3sgl8TiGlBO4AOSE5vwVmmBY8cVMNFOC3RWP0dG
         Q4IJE2Wbs7dxUi9SdN04g6UYedhQte2WVKR0CYa6ggCqWmizSKuqtvAD1B0OaNFgyP6d
         VsRbOsUPXSa+yhxPGwtNf3HDxIJppnqykvo7V/LCXs6h0BU3DA0pVNT141ZEIGW1yWIb
         w+cXRkjv/HjBNP+fqB8iHOr7xiFmgDzowQQq3oSnucj35w1EGaTnjRAM50RTnnsKDsVZ
         6OA9CdA5mAt6G1R3al68NgKMC1Ilki6WyTfKbXKJG4pCOn11nkNmc6f4X/FUzD3SZtf8
         NGRQ==
X-Gm-Message-State: AOJu0YySUTj2WX04EQ5wmKsdEXZ04sUWeMqO+FARsyPgM/gUlSvUGwKi
	oNcwmZCWHN8XHbNW5f61FaB0h8d/BV0mzuNgtfgGGYFRqr/a64QxjtAMGY8qkSXpaS8p7b5yQ1G
	WP4RZ
X-Gm-Gg: ASbGncu63YGWcf6eL5eqeU0Oltmsdybogo4PbDESEaV7fOt4sgY+GVolYGHrvZDx1aI
	+tOqA3ON5CwlGttifh3aPndXnm6f4z2+odIiq+TTrmwUoHXLALibX00c267p60UE2yfWpG3lXQU
	Df8D2Hf104uunEfQqemmAauKTessDtq+xYvrkg03vYtLXBs9fcGca03GTgRBSTGbA0torMZM2Hp
	Vy3J8nnm4mFNQBHYOykaxf3joRu6m2qyVnjY7p+fIWHNDyiZ5Dry6zfA7c5dHGJftcqMxiLOggA
	q6QheaSYAsr45/hQ9A5gNjQxjzomPjJDd+w9feErmEj/kIzbZetmz30wjVMpJlL2Vg0dMqeGsMc
	gk5KjkKmklx4SRIGDenHRua1y
X-Google-Smtp-Source: AGHT+IFhtiPVFvy2L+RuChqZ8Sza3/nbyDe0zbfKlBB5ArCPhO1/1PN5F+kb5kRipzYLeRLpiawOqA==
X-Received: by 2002:a05:600c:1e1c:b0:441:d438:4ea5 with SMTP id 5b1f17b1804b1-44c9493e6b1mr78478795e9.20.1748292784695;
        Mon, 26 May 2025 13:53:04 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Manuel Bouyer ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/pv: Fix breakpoint reporting
Date: Mon, 26 May 2025 21:53:02 +0100
Message-Id: <20250526205302.997387-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

x86_merge_dr6() is not a no-op when 0 is passed in; it will discard the
previously latched breakpoint bits.

The combination of do_debug()'s manual call to x86_merge_dr6() for external
debuggers, and pv_inject_DB() calling pv_inject_event(), results in two
x86_merge_dr6() calls.

Feed the same pending_dbg in the second time.  This makes pv_inject_event()'s
update of dr6 effectively a no-op, retaining the correct breakpoint bits.

Fixes: db39fa4b27ea ("x86/pv: Fix merging of new status bits into %dr6")
Reported-by: Manuel Bouyer 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Manuel Bouyer 

Now to figure out why my testing didn't spot this...
---
 xen/arch/x86/traps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 22f20629327d..e7b4693415cd 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1823,7 +1823,7 @@ void asmlinkage do_debug(struct cpu_user_regs *regs)
         return;
     }
 
-    pv_inject_DB(0 /* N/A, already merged */);
+    pv_inject_DB(dr6 ^ X86_DR6_DEFAULT);
 }
 
 void asmlinkage do_entry_CP(struct cpu_user_regs *regs)

base-commit: 6cfe3ae346fc84fbd4380fc45c70780935da590a
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon May 26 20:57:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 20:57:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997808.1378624 (Exim 4.92)
	(envelope-from )
	id 1uJess-0002GP-3Y; Mon, 26 May 2025 20:57:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997808.1378624; Mon, 26 May 2025 20:57: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 1uJesr-0002GI-WC; Mon, 26 May 2025 20:57:21 +0000
Received: by outflank-mailman (input) for mailman id 997808;
 Mon, 26 May 2025 20:57:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJesq-0002GC-Sv
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 20:57:20 +0000
Received: from chassiron.antioche.eu.org (chassiron.antioche.eu.org
 [2001:41d0:fc2c:4d01::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 02df9a39-3a74-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 22:57:19 +0200 (CEST)
Received: from rochebonne.antioche.eu.org
 ([IPv6:2001:41d0:fc2c:4d00:96de:80ff:fe21:bec0])
 by chassiron.antioche.eu.org (8.18.1/8.16.1) with ESMTP id 54QKvGBN014557;
 Mon, 26 May 2025 22:57:16 +0200 (MEST)
Received: by rochebonne.antioche.eu.org (Postfix, from userid 1210)
 id 470451A4D0; Mon, 26 May 2025 22:56: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" 
X-Inumbo-ID: 02df9a39-3a74-11f0-b893-0df219b8e170
Date: Mon, 26 May 2025 22:56:41 +0200
From: Manuel Bouyer 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org
Subject: Re: Xen 4.18.5 PV dbregs fail
Message-ID: 
References: 
 
 
 
 <0733f3dc-9f01-4e15-98ab-d7fd7c3e303d@citrix.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (chassiron.antioche.eu.org [IPv6:2001:41d0:fc2c:4d01:0:0:0:1]); Mon, 26 May 2025 22:57:16 +0200 (MEST)

On Mon, May 26, 2025 at 09:30:53PM +0100, Andrew Cooper wrote:
> On 26/05/2025 9:13 pm, Manuel Bouyer wrote:
> > On Mon, May 26, 2025 at 07:50:14PM +0100, Andrew Cooper wrote:
> >> [...]
> >> Well, that range does include the aforementioned commit.
> >>
> >> Can you bisect around d32c77f471fb8400b6512c171a14cdd58f04f0a3 which is
> >> the backport of ^ in 4.18 ?
> > Sure,
> > with 0d5f15e and d32c77f the test pass, with cecee35 it fails.
> >
> 
> Oh interesting, so the basic forwarding of #DB back into a guest
> (d32c77f) works fine, but the changes to emulated debug exceptions
> (cecee35) break.
> 
> Anyway, I think I've spotted a logical error. We do indeed end up
> calling x86_merge_dr6() twice, because of the TODO just out of context.
> Does this help?

Yes, it works for cecee35; now testing with 4.18.5

-- 
Manuel Bouyer 
     NetBSD: 26 ans d'experience feront toujours la difference
--


From xen-devel-bounces@lists.xenproject.org Mon May 26 21:11:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 21:11:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997816.1378633 (Exim 4.92)
	(envelope-from )
	id 1uJf6S-00050A-4X; Mon, 26 May 2025 21:11:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997816.1378633; Mon, 26 May 2025 21:11: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 1uJf6S-000503-13; Mon, 26 May 2025 21:11:24 +0000
Received: by outflank-mailman (input) for mailman id 997816;
 Mon, 26 May 2025 21:11:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJf6Q-0004zx-Lb
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 21:11:22 +0000
Received: from chassiron.antioche.eu.org (chassiron.antioche.eu.org
 [2001:41d0:fc2c:4d01::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f882e708-3a75-11f0-b893-0df219b8e170;
 Mon, 26 May 2025 23:11:20 +0200 (CEST)
Received: from rochebonne.antioche.eu.org
 ([IPv6:2001:41d0:fc2c:4d00:96de:80ff:fe21:bec0])
 by chassiron.antioche.eu.org (8.18.1/8.16.1) with ESMTP id 54QLBHoS003215;
 Mon, 26 May 2025 23:11:17 +0200 (MEST)
Received: by rochebonne.antioche.eu.org (Postfix, from userid 1210)
 id 4A2F01A4D0; Mon, 26 May 2025 23:10: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" 
X-Inumbo-ID: f882e708-3a75-11f0-b893-0df219b8e170
Date: Mon, 26 May 2025 23:10:42 +0200
From: Manuel Bouyer 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org
Subject: Re: Xen 4.18.5 PV dbregs fail
Message-ID: 
References: 
 
 
 
 <0733f3dc-9f01-4e15-98ab-d7fd7c3e303d@citrix.com>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (chassiron.antioche.eu.org [IPv6:2001:41d0:fc2c:4d01:0:0:0:1]); Mon, 26 May 2025 23:11:17 +0200 (MEST)

On Mon, May 26, 2025 at 10:56:41PM +0200, Manuel Bouyer wrote:
> On Mon, May 26, 2025 at 09:30:53PM +0100, Andrew Cooper wrote:
> > On 26/05/2025 9:13 pm, Manuel Bouyer wrote:
> > > On Mon, May 26, 2025 at 07:50:14PM +0100, Andrew Cooper wrote:
> > >> [...]
> > >> Well, that range does include the aforementioned commit.
> > >>
> > >> Can you bisect around d32c77f471fb8400b6512c171a14cdd58f04f0a3 which is
> > >> the backport of ^ in 4.18 ?
> > > Sure,
> > > with 0d5f15e and d32c77f the test pass, with cecee35 it fails.
> > >
> > 
> > Oh interesting, so the basic forwarding of #DB back into a guest
> > (d32c77f) works fine, but the changes to emulated debug exceptions
> > (cecee35) break.
> > 
> > Anyway, I think I've spotted a logical error. We do indeed end up
> > calling x86_merge_dr6() twice, because of the TODO just out of context.
> > Does this help?
> 
> Yes, it works for cecee35; now testing with 4.18.5

yes, it works with 4.18.5 too. All dbreg-related tests now pass again
thanks !

-- 
Manuel Bouyer 
     NetBSD: 26 ans d'experience feront toujours la difference
--


From xen-devel-bounces@lists.xenproject.org Mon May 26 21:17:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 21:17:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997825.1378643 (Exim 4.92)
	(envelope-from )
	id 1uJfC2-0005a5-MW; Mon, 26 May 2025 21:17:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997825.1378643; Mon, 26 May 2025 21:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJfC2-0005Zy-Je; Mon, 26 May 2025 21:17:10 +0000
Received: by outflank-mailman (input) for mailman id 997825;
 Mon, 26 May 2025 21:17:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJfC1-0005Zr-9t
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 21:17:09 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c7adb61e-3a76-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 23:17:08 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a36e090102so1489406f8f.2
 for ; Mon, 26 May 2025 14:17:08 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4d3a74422sm5992051f8f.18.2025.05.26.14.17.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 14:17:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c7adb61e-3a76-11f0-a2fb-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748294227; x=1748899027; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=F65WcQOxSpURa+C44yxcgHUue79IRuVXFTMohhUsTEs=;
        b=HMf7PL08tu2lxtU0diY6UD1MfyNeXvk3VjM7VdGEJa0GTy6OdgWzVoRNNL7PU+2Mlf
         Eb3p/Su8TmXKK/Rakmp4kOIlPTbwGfSohbomeWKMqolxmzTv3AKYIYeSPnes4tRU+TJc
         sPJfvMjpFhz/88CUnLFq6tejNQFkErDuBeWJk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748294227; x=1748899027;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=F65WcQOxSpURa+C44yxcgHUue79IRuVXFTMohhUsTEs=;
        b=LRZx/HOI92AveJaN2ztA4m6pYP+lVvfGz4q18wmJ/jb8G1mO++DdcNudjp/J+vz2fP
         FYs78Bezo+dQpImWHxFo30kx47lmcv1r5siwoqWNuVmZw4LEU02NXamgcnZS9Xr7lX0Q
         wdybckMRx/kYNglzucbLfpxURMQuVEi1HrCEnjxIOzab+iiLJZHKaV4rx0tPb7AEBdyT
         LnJu4hZMDqaXu73u+XFT4j7OvjqWCRG4GOMitrJQQjx7b2YToZrJVBxHKBQz4dQfbuff
         lLHeXEi5NIzGqgo+eqyeOD4zzIDD+EgQzPoenXt4uQr8q2qSqJPnaTNW9zKk/ExbEyX6
         520w==
X-Gm-Message-State: AOJu0Ywbg4LcQJsZYrjc8m2OGEXBVFCWpyw3VbCR2BK3sOMdKIIe+eQ2
	JUHwYhzHZ5C8gKiSSiN7LiOZ9IGhY1MBPcfAuTWzcvl+ezA28Zlj8lwRWWeoV9M2UiA=
X-Gm-Gg: ASbGncuTrJID/ZiiuOirP8HhgDTc2e1iwfjkbX+y6zO2VomkNM4mabJEptl53+edI7a
	eHKijNtD7LWHRnTJnM+uC35AmI5P0//V4XhdzfPFKbG3Sa7XY4z5zzjsoTe8FJFZbEF0B4IP8f0
	NIEH230mmFBrs1n12gdk+yKfw4fwYv7HFd+Cg+hKd4rLE9j18O9/6lF497f6y4Gtn01/l+kAxhl
	xmz6V7nGHLEknH2EFLot8tEogU6dw1zlHcxdv8ecA3rFDGpXBdSRi8fM/tBbl/VoI3b/Rr8HLI6
	U1EzkOublY6yhy/yMA23zIhimoxU3lKBgYqHAB4z1XX0t41b+I9sIk//V9CJ0cuJTNHT6BYRech
	rPsOenBIR1o34RUJz
X-Google-Smtp-Source: AGHT+IF3AfM8d4/JtmjhQvPFMwZMMs4imGmH9Gq9ldB+MondZgKG6OW4dGBqwtKoUoyv1SzpadS4CA==
X-Received: by 2002:a5d:61cc:0:b0:3a4:cfbf:5197 with SMTP id ffacd0b85a97d-3a4cfbf52b1mr5035394f8f.18.1748294227490;
        Mon, 26 May 2025 14:17:07 -0700 (PDT)
Message-ID: <11ea8686-ac41-44b5-8271-408c775c776a@citrix.com>
Date: Mon, 26 May 2025 22:17:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen 4.18.5 PV dbregs fail
To: Manuel Bouyer 
Cc: xen-devel@lists.xenproject.org
References: 
 
 
 
 <0733f3dc-9f01-4e15-98ab-d7fd7c3e303d@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

On 26/05/2025 10:10 pm, Manuel Bouyer wrote:
> On Mon, May 26, 2025 at 10:56:41PM +0200, Manuel Bouyer wrote:
>> On Mon, May 26, 2025 at 09:30:53PM +0100, Andrew Cooper wrote:
>>> On 26/05/2025 9:13 pm, Manuel Bouyer wrote:
>>>> On Mon, May 26, 2025 at 07:50:14PM +0100, Andrew Cooper wrote:
>>>>> [...]
>>>>> Well, that range does include the aforementioned commit.
>>>>>
>>>>> Can you bisect around d32c77f471fb8400b6512c171a14cdd58f04f0a3 which is
>>>>> the backport of ^ in 4.18 ?
>>>> Sure,
>>>> with 0d5f15e and d32c77f the test pass, with cecee35 it fails.
>>>>
>>> Oh interesting, so the basic forwarding of #DB back into a guest
>>> (d32c77f) works fine, but the changes to emulated debug exceptions
>>> (cecee35) break.
>>>
>>> Anyway, I think I've spotted a logical error.  We do indeed end up
>>> calling x86_merge_dr6() twice, because of the TODO just out of context. 
>>> Does this help?
>> Yes, it works for cecee35; now testing with 4.18.5
> yes, it works with 4.18.5 too. All dbreg-related tests now pass again
> thanks !
>

Sorry I screwed it up so badly, and apparently also my own testing...

May I take that as a Tested-by tag on the patch then?

I'll get the fix merged once it's been reviewed, but 4.18 is in
security-only support right now and is unlikely to get this as a backport.

Are you able to take the patch logically for NetBSD?

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon May 26 21:31:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 26 May 2025 21:31:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997834.1378653 (Exim 4.92)
	(envelope-from )
	id 1uJfPq-0008Lr-Rj; Mon, 26 May 2025 21:31:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997834.1378653; Mon, 26 May 2025 21:31: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 1uJfPq-0008Lk-PD; Mon, 26 May 2025 21:31:26 +0000
Received: by outflank-mailman (input) for mailman id 997834;
 Mon, 26 May 2025 21:31:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJfPo-0008Le-LA
 for xen-devel@lists.xenproject.org; Mon, 26 May 2025 21:31:24 +0000
Received: from chassiron.antioche.eu.org (chassiron.antioche.eu.org
 [2001:41d0:fc2c:4d01::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c54ff169-3a78-11f0-a2fb-13f23c93f187;
 Mon, 26 May 2025 23:31:23 +0200 (CEST)
Received: from rochebonne.antioche.eu.org
 ([IPv6:2001:41d0:fc2c:4d00:96de:80ff:fe21:bec0])
 by chassiron.antioche.eu.org (8.18.1/8.16.1) with ESMTP id 54QLV8Rn013208;
 Mon, 26 May 2025 23:31:08 +0200 (MEST)
Received: by rochebonne.antioche.eu.org (Postfix, from userid 1210)
 id D42BF1A4D0; Mon, 26 May 2025 23:30: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" 
X-Inumbo-ID: c54ff169-3a78-11f0-a2fb-13f23c93f187
Date: Mon, 26 May 2025 23:30:33 +0200
From: Manuel Bouyer 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org
Subject: Re: Xen 4.18.5 PV dbregs fail
Message-ID: 
References: 
 
 
 
 <0733f3dc-9f01-4e15-98ab-d7fd7c3e303d@citrix.com>
 
 
 
 
 <11ea8686-ac41-44b5-8271-408c775c776a@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <11ea8686-ac41-44b5-8271-408c775c776a@citrix.com>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (chassiron.antioche.eu.org [IPv6:2001:41d0:fc2c:4d00:a00:20ff:fe1c:276e]); Mon, 26 May 2025 23:31:08 +0200 (MEST)

On Mon, May 26, 2025 at 10:17:06PM +0100, Andrew Cooper wrote:
> On 26/05/2025 10:10 pm, Manuel Bouyer wrote:
> > On Mon, May 26, 2025 at 10:56:41PM +0200, Manuel Bouyer wrote:
> >> On Mon, May 26, 2025 at 09:30:53PM +0100, Andrew Cooper wrote:
> >>> On 26/05/2025 9:13 pm, Manuel Bouyer wrote:
> >>>> On Mon, May 26, 2025 at 07:50:14PM +0100, Andrew Cooper wrote:
> >>>>> [...]
> >>>>> Well, that range does include the aforementioned commit.
> >>>>>
> >>>>> Can you bisect around d32c77f471fb8400b6512c171a14cdd58f04f0a3 which is
> >>>>> the backport of ^ in 4.18 ?
> >>>> Sure,
> >>>> with 0d5f15e and d32c77f the test pass, with cecee35 it fails.
> >>>>
> >>> Oh interesting, so the basic forwarding of #DB back into a guest
> >>> (d32c77f) works fine, but the changes to emulated debug exceptions
> >>> (cecee35) break.
> >>>
> >>> Anyway, I think I've spotted a logical error. We do indeed end up
> >>> calling x86_merge_dr6() twice, because of the TODO just out of context.
> >>> Does this help?
> >> Yes, it works for cecee35; now testing with 4.18.5
> > yes, it works with 4.18.5 too. All dbreg-related tests now pass again
> > thanks !
> >
> 
> Sorry I screwed it up so badly, and apparently also my own testing...
> 
> May I take that as a Tested-by tag on the patch then?

Sure

> 
> I'll get the fix merged once it's been reviewed, but 4.18 is in
> security-only support right now and is unlikely to get this as a backport.
> 
> Are you able to take the patch logically for NetBSD?

Yes, I can add it to pkgsrc, no problem.

I need to package 4.20 too ...

-- 
Manuel Bouyer 
     NetBSD: 26 ans d'experience feront toujours la difference
--


From xen-devel-bounces@lists.xenproject.org Tue May 27 00:12:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 00:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997848.1378664 (Exim 4.92)
	(envelope-from )
	id 1uJhvU-0001e4-FI; Tue, 27 May 2025 00:12:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997848.1378664; Tue, 27 May 2025 00: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 1uJhvU-0001dx-C0; Tue, 27 May 2025 00:12:16 +0000
Received: by outflank-mailman (input) for mailman id 997848;
 Tue, 27 May 2025 00:12:14 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJhvS-0001dr-HJ
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 00:12:14 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20628.outbound.protection.outlook.com
 [2a01:111:f403:260e::628])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 33e574d8-3a8f-11f0-b893-0df219b8e170;
 Tue, 27 May 2025 02:11:58 +0200 (CEST)
Received: from PR3PR03MB6412.eurprd03.prod.outlook.com (2603:10a6:102:7d::8)
 by DBBPR03MB10559.eurprd03.prod.outlook.com (2603:10a6:10:53b::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.25; Tue, 27 May
 2025 00:11:54 +0000
Received: from PR3PR03MB6412.eurprd03.prod.outlook.com
 ([fe80::2887:9068:38f6:8340]) by PR3PR03MB6412.eurprd03.prod.outlook.com
 ([fe80::2887:9068:38f6:8340%6]) with mapi id 15.20.8769.025; Tue, 27 May 2025
 00:11: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" 
X-Inumbo-ID: 33e574d8-3a8f-11f0-b893-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eag9UkjrgEy3J4s2MzsgucPHduymncGWZNtD2B5k++yQGNpi/GiRm89Pcwgv4Gyq1GumeNYwN0bh1YHpnKI9KVTG5r3g54eFXXIKypTrtfAX2GANtLV8ZzD8fnfpmpf8oEtXzpUTTLKaGLatAht/Rrc9IGWmnWYrQQjQL/MAXbckxJc5hlRn1UjpKQ7YO9x0dl+ZvkhLmBsu5QEd8AqzrXsqB6jsafz7inRMQrjQAtxHooiVXtCZv1d5RRxURbbLFDhsELJ75bxSMNUFH3iNJO/GwyyM07iJqmJYttlThtEnU5DhJLLqhVwQiLc51cjhdxOJ9G7ovWhplPoBCET0CQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=w0UC2uVhves3JMuCM7fsnRk6dFJ47wZaR/LSaZmPfjk=;
 b=KOurWadc9FUbLGn2PIJeLoRkNnSwZgcSSCFOMtFv4swefTCvXE5mCBG00tE+gOxUAvNtddsUYeDvRZFkrD4E9oA4tyWvMg2wJGy466ZRkZKn00koDmHlWPtsF/F0TQ3UPT5cN6KwMhHp8CjhwcuWjKI9meYLmdO7OJ3IePpLXTjkzXXQUdM870vOMeFQxhRQvSdqsHXBUvmfUGhMqFV1svsSkPkh7dr05ORLfi9ez2Gn9QS/7OdP5/ngMZmBQGOZ5YK0S1oJPblwO/u2jUp9c9un8azRyjzrTygKBesiEO5rMRdGjkKi+YAE3O7s5ROoSGc22AtKv53TP1celjVZMQ==
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=w0UC2uVhves3JMuCM7fsnRk6dFJ47wZaR/LSaZmPfjk=;
 b=IOUIhGhs4T6XwxDf8zbBmCfqVZ9xkoRhe6Mu+y4W8DAWOmtGuGgSCOdEtPJQee0TCrXnOJ3TWVUnd6LvdlfsZgSFBMnijKMrk05OZfhO+KzZyP6XWI7KrSQ+sYNroUUskEZfy1hl7iDh9GxBU/+PImE5xCHZPa2IoB8pN75Hy0LPACQlGa6OeVYxuCLo6AM7C8gKEsEAaTTfkzF+glBImdCP47ZPlvxR/bmUpBuj+rGZc3XX97ok2n5hFM64rzuvGR/yw5/r2fc30ZbGDJso6WdzoWO40iQqOs7smaAMKD7dDjMeV6b+VU5sqgV+2r27W43858wqjIoO1DjdVdAncw==
From: Oleksandr Tyshchenko 
To: "xen-devel@lists.xenproject.org" 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk 
Subject: [PATCH] arm/vgic-v3: Fix GICD_ICPENDR read access in
 __vgic_v3_distr_common_mmio_read()
Thread-Topic: [PATCH] arm/vgic-v3: Fix GICD_ICPENDR read access in
 __vgic_v3_distr_common_mmio_read()
Thread-Index: AQHbzpvyD0IOuzZwNE60YXhXy//Nyg==
Date: Tue, 27 May 2025 00:11:52 +0000
Message-ID: <20250527001151.3804521-1-oleksandr_tyshchenko@epam.com>
Accept-Language: en-US, ru-RU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PR3PR03MB6412:EE_|DBBPR03MB10559:EE_
x-ms-office365-filtering-correlation-id: c8fb11b6-f7f8-4dbc-004c-08dd9cb31548
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?IzG31bOzYibb1elIpimdc1OTLKeoDciXOJuBde0Oi09Ad247KXFvQuLKfW?=
 =?iso-8859-1?Q?+u4GssAb1RVmkDLTdr781MlkY46IksTTG8y9xYbLjk8N034aQK/3PsD136?=
 =?iso-8859-1?Q?NzWdNOfZy42GBCyQ/+whC5D2IetjlYbPwlDfFWgGtDUdDjPTrew/sfk9kP?=
 =?iso-8859-1?Q?C46Fj27NOPKEdD9aL1tixA/61gkwpuY/S+xUDGoN2qXjeo4LGHTSf7A364?=
 =?iso-8859-1?Q?MKEv0u8Z9lyv/imdEvJJlVJqdmCJUw7m1xff6H8o+SlZAtCeMpwlCpPA/F?=
 =?iso-8859-1?Q?jJzlY4f02lvghl5r2itQ+/dynr7MMCU2eL5CSKdyzy6AxM6Q2RFCv5ah+E?=
 =?iso-8859-1?Q?G+fTNetOve3lxde1kKLCdsjsePzY6R82Sw8akYKjqMokl6MRZp7c0GNzCQ?=
 =?iso-8859-1?Q?8DDxASkqJPk8rlD3zpRVFn5FTwZc16VKenLKv1a+ojDlj6J1F3Fuf+tSWL?=
 =?iso-8859-1?Q?h56JGN3erkEsIAZBEg4vc0Fy7Dvfas563ytRqtBBfIRCrVjpArV8QiExl7?=
 =?iso-8859-1?Q?1FfBwE4DNrYuoFN3d26qjkIxTHy/Y9UV/V0d2JLPlVRyi0TivDMg5uN2Rc?=
 =?iso-8859-1?Q?5WxJAxc1GtcJKXnBRLPfprBEixMHf2RFhqMJQfeaKJo+a7H/dy1YmKxR1E?=
 =?iso-8859-1?Q?UnecKSNPkaOGZ5BboTuir3QpZP063WPPdLQM3gm3V8KrQuh2hsWpG1VmcE?=
 =?iso-8859-1?Q?JVPNuzSp/ZNet1qOmiaol3qDihDoIXIxXVm8Nsj2PTBCB/7CxIjj9Irks9?=
 =?iso-8859-1?Q?hBlX4rrc0agNP3qLMtSI3sZ9gIfCxLhGUEJUZhG1jJ9ADFon5/tl/OF+bl?=
 =?iso-8859-1?Q?v/gKR3jAmXeJEqg1Z5u+CgXsfhOsVjRPFxKBIQfy9MJdK8nvHUV9ySgyQn?=
 =?iso-8859-1?Q?08a+rryEWgFGkFYywNi7wtrAQA7qhqEKK1vWv1vWXQA+oRMtotopD63jEN?=
 =?iso-8859-1?Q?/siWNevMM5k+XHEyOHoKGE3pCaOc8oicCf86IvOz1Rqy5NiLV+yXH3cM7f?=
 =?iso-8859-1?Q?X5bFH4LM69OA/Dt547yjI4FWxI1KA/Mk0t50yA065+LbT2X/7d4hLaZ5C6?=
 =?iso-8859-1?Q?qEUH43fkTrhvM6KbIwWmjZesxDkK7Z9bbMGqDa7tZGkkBBKN8fCIw0mVfG?=
 =?iso-8859-1?Q?TXx1o6l2Qi97LYeA6LEsjLk900SmH63WoMuefTBmS8u2wy45QyvdBB3tLy?=
 =?iso-8859-1?Q?jPXDi/0ak7eafqmo0Wh+9ee8mpS/T5alvUDJFpxC8aE2VUvAnQiOpVYpQV?=
 =?iso-8859-1?Q?H+JJ2lyY03Wm3Gjyr4cGLgAV7+H7j25/hvZUNQMG2cy0FGoGQw3l68Ompj?=
 =?iso-8859-1?Q?r5lbxmLUFnSrB4J8ahfTH8Q1Ba0gHFXSx9sDPXaD5tfS/m3ORQ5CvUF7Bc?=
 =?iso-8859-1?Q?9tNYhGxmFfI8MiPkBXxKragpNuWwuk4YJjkkc6d8PWquW+4ieWZgUmixGW?=
 =?iso-8859-1?Q?6PzQzZvSA5gKR6b6wZrWrDGJl8XRcjLIacvZszHM1taPdX43UPx2YGQlt9?=
 =?iso-8859-1?Q?ItP3Va2ARySkZ09tm7LBEWG4FotAr1KfctN9RgteZOHA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR03MB6412.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?NS+gzp6IkJNBp8hTewZL3GW2Qrs8YdkqFcJBzl5nkuZaPTrWXlTQ5qMZ5Q?=
 =?iso-8859-1?Q?fWJCjRfW8wmGt46BB9ugwQXo6qnVueN+0qqEmLhccu7PvBr81BjtkFiB79?=
 =?iso-8859-1?Q?i3gju9EGWUVDeRJ6bpueOG+eNY60PYVyEP13m+IHtFfQJgsoXxRvkLRgnU?=
 =?iso-8859-1?Q?XbV0gq0Rr205joWELp/r70E5NkozK9BtRnBJwbA2LsdWEiNzTeLaRePJCK?=
 =?iso-8859-1?Q?tuKMWZm/6ECQokHyA4uTmNwOqolrrhbieGuIa9V5MkB1iWRmVlZR4j5Pfy?=
 =?iso-8859-1?Q?r6WnAqM4gU3C9fD6CZh7f3eFioir+kdDNKNdr4E0bMZ7Vxbs/1rE1Gk3WJ?=
 =?iso-8859-1?Q?06amSWjdsh7zLbiyPmg6C3oVF5/yfZNVW7Xsvo8JhGZKnroALjiLT5I3u2?=
 =?iso-8859-1?Q?LQQx5Z3IMnBxxAP/8HV/eQ4zApGWf9P49Oi12chfjVMkwMlKTvZNqmOqN8?=
 =?iso-8859-1?Q?H7MLkK0/q7/DGgQ2oGnIR7USlXM9H9Hq3JcIqvakGLeo+Vz0q0o6tcZMvv?=
 =?iso-8859-1?Q?ui4UwPSyamE3426Q6+hsHSSU+XSTXHyWmWaBN24vrOurzqVtQBkJ99jtqz?=
 =?iso-8859-1?Q?vRpuTITBCd5Jr7gZbgOuTRg2ycc0Lfk7fAhlTTwZK6LytOhxHeQS4nnvZb?=
 =?iso-8859-1?Q?rPA1LQsaU76yPJDeQdWXTYo7hi14vXilIh40mqDyZAaldno0SCwZ/6gTev?=
 =?iso-8859-1?Q?cfIuaapwrFEMW+G5CjwcibvJ7EsLDYhy4+IG8TfFnObAlveQ+wBitP60K+?=
 =?iso-8859-1?Q?RG4BSpFFIgIc89XAxxwEeHfOwYpZxpVK5Lx1VVIQN1fF2z0ZdnjdoUGMLG?=
 =?iso-8859-1?Q?4SHp60wQ659ep/Ts1gxkJPfWQrsYSmyNNDeMUQ/zmDOej38kZvYrDz/IPD?=
 =?iso-8859-1?Q?juFuUOLDVKQ0AGy24/AiDKnYJnGgPei4k8ZFoJCBJYguPdH3dxNyLXkSm9?=
 =?iso-8859-1?Q?BcR6Yujl/PvpK6wEh+4dt+25a8E5m+sKHKa1D1MRJEAJpygOZ75r4Du4rC?=
 =?iso-8859-1?Q?pnQbkzZiIrh1kcKiU+knE9q+4BTOAJ4y0R4Wx2HEWSgi1jTuCiDcJsc+0f?=
 =?iso-8859-1?Q?ODfnbmRsWxlzpFSr5FTn9dBI9PnA9qTudAh5DZ4TIF1bI0ZIN24CFSPkoE?=
 =?iso-8859-1?Q?K/p9B+uhH4GgaSpEcdOrOqIsxPBr71rOMUNwePJIYYkC8804OGB8grWEZw?=
 =?iso-8859-1?Q?ycK4VPI8Tcw8rGBrP6C7CauCnoMdZTKfyCJeebT4t0bdJu2E+qTInqzcZ2?=
 =?iso-8859-1?Q?sU1PMCI2P5lO0KtMkK9grpQ4f2l/jsUgHUEDPjXhS6FD6Dy+/3/Y6lTOeH?=
 =?iso-8859-1?Q?03Wun3+YQjbFuqu4TTkHcdndXUxgW9hW777xEqBpJvhfKfQJI2S9jKp4aN?=
 =?iso-8859-1?Q?qU0I6JHN96C/KQFMw4so3JiGgVoRKPC6sN5KDr9urPQXCji3N+NxNKOqcN?=
 =?iso-8859-1?Q?3q8esi+vXcSlH7fwu6JY3QSa6sWGl1M0CwRHheoC7zteLYZgPSYzYb2WEG?=
 =?iso-8859-1?Q?V6k7ToRVFHdFCAThbYZlwupN4+2R4erRO2QpylMvuRh/y2PEKBlT2CqAs9?=
 =?iso-8859-1?Q?VEfFC19DgoGq2ZprJDEgnxfGnUUDE92Cwc5G4Fh7Em7q5WK5s639XKqLwq?=
 =?iso-8859-1?Q?KO4dNI2Y4pGRtIarlsMEubsuk627t79y0pSo8ywDGWuPjDxuGJHhuuogtE?=
 =?iso-8859-1?Q?PviBFcJtge0sSdsGa54=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: PR3PR03MB6412.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c8fb11b6-f7f8-4dbc-004c-08dd9cb31548
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2025 00:11:52.6261
 (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: wD2f9rsiOK4+Vm35B2PLZXhIUmFcS8y8xUAkiJXpObaRk5hA1zivGB9uUUMh5W+pxJmbD+KDkzH/Ux6GHRmR/TWbE5D9k8VvalrTwiMMSXE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB10559

An attempt to read access the GICD_ICPENDR register (where n > 0)
which should be RAZ (as not supported) causes the guest data abort
due to incorrect end offset (GICD_ICPENDR) in the case range.
Fix that by using the proper end offset (GICD_ICPENDRN).

Fixes: a2b83f95bfa ("xen/arm: vgic: Properly emulate the full register")
Signed-off-by: Oleksandr Tyshchenko 
---
 xen/arch/arm/vgic-v3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index f20249f731..4369c55177 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -709,7 +709,7 @@ static int __vgic_v3_distr_common_mmio_read(const char =
*name, struct vcpu *v,
=20
     /* Read the pending status of an IRQ via GICD/GICR is not supported */
     case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN):
-    case VRANGE32(GICD_ICPENDR, GICD_ICPENDR):
+    case VRANGE32(GICD_ICPENDR, GICD_ICPENDRN):
         goto read_as_zero;
=20
     /* Read the active status of an IRQ via GICD/GICR is not supported */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Tue May 27 06:49:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 06:49:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997889.1378674 (Exim 4.92)
	(envelope-from )
	id 1uJo7g-0002jX-40; Tue, 27 May 2025 06:49:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997889.1378674; Tue, 27 May 2025 06:49: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 1uJo7f-0002jP-VL; Tue, 27 May 2025 06:49:15 +0000
Received: by outflank-mailman (input) for mailman id 997889;
 Tue, 27 May 2025 06:49:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJo7e-0002jJ-Sk
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 06:49:15 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on2060a.outbound.protection.outlook.com
 [2a01:111:f403:240a::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ab174de0-3ac6-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 08:49:01 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by PH7PR12MB7018.namprd12.prod.outlook.com (2603:10b6:510:1b8::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Tue, 27 May
 2025 06:48:56 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.025; Tue, 27 May 2025
 06:48: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" 
X-Inumbo-ID: ab174de0-3ac6-11f0-a2fd-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WDslE75ptcNkoCyaXI9kus90ILcwaeJfOMuJasm+TEBzAIVUZr9Ba9LN5cGPoEx+XzUngRbTwS7qUJxXS2vJD6Uj4/rkdo/PmY2NaLM6LkU7WAdu6XWNkTsPNlITLFFMJ4JBwsdZVj9E5EC+hSCJXegSRGjQmuI/+UBgvKbTKL8Tvy1M3F01je6ADBq1n3w73GOYzArGsIWKqsm6TXl5Hc2a82tfo+Ramse5Hcc25OYX00qe1huGBJP4JuxUIU3tjhdYZH3Gr6tqy2yu0Mtj/tSOfappmNH5m2jqxlRdZxuBs8QOMF5s0t4j1i4CVnqFFhUbbBa+WHTAauw3mUQdbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WRO9yt6TVAFdho2d8tnHuRwZW6RfvoYX6bnVpba72ZQ=;
 b=FswTfcqOtaLWh+VZnJUbT3/a9cQ7sFMiUtDlszTjPJyTx1CSr++7XOcv3YEGNnnj7e3TlssVVdrh/V4VfiZfIlciRUNL+k+WmVrrNMempFg0ETyBP/GPThUSACca8JlSoSNtoC0jLNUmLH/hMBZWKjEaGGantsZNz/IEydQSHbDO14Pg0KeQ/3S6StofWhUuqmVjv6AP2bJo+vQa+maMm2WXcVsxLKJEM241lvRv7LXAi0MayFxRfSr3Rnt8/36wCbiPJMbzo4qjLqNsjGvbYASzodRdZmThxA/qZM8GuEyYo0vH2vEFbE616rOdh+ovnEWChXddfxc5/9SKdBBnbA==
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=WRO9yt6TVAFdho2d8tnHuRwZW6RfvoYX6bnVpba72ZQ=;
 b=kaV2VnuqoKH9R4eTAe0DizK/gw1exfHNW2dVZyvbQ82HrTlZlU73ZjfTo/9qIC4sezTd7BaIbAjLGcQwZoUGBvJddRgIht+2J/YzmHLofnqE/B4PsKuOdqLrAWGiTZzLEwl5VsWlWlF9+DTEO1Iih2nKHhY+ToQThM71g5cabuA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <51a4f845-1337-415d-ba01-40f530a7cb95@amd.com>
Date: Tue, 27 May 2025 08:48:52 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm/vgic-v3: Fix GICD_ICPENDR read access in
 __vgic_v3_distr_common_mmio_read()
To: Oleksandr Tyshchenko ,
 "xen-devel@lists.xenproject.org" 
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250527001151.3804521-1-oleksandr_tyshchenko@epam.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250527001151.3804521-1-oleksandr_tyshchenko@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: PAZP264CA0160.FRAP264.PROD.OUTLOOK.COM
 (2603:10a6:102:1f9::22) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|PH7PR12MB7018:EE_
X-MS-Office365-Filtering-Correlation-Id: 6a51ba9f-baad-4e46-88ad-08dd9cea8d12
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cWJ0ZXBXL0N2MUp1RXpYRkpEbjJ6aGpQRjZ3ek5oVjRsS2VhdjY4TXk5ZW5G?=
 =?utf-8?B?T3FBbUhYU3BHVWozeTdrSWl1dmZpMkN4MHd6eEFhdll3V01xTEZkcm1NdFZh?=
 =?utf-8?B?NTlqcmRLemREU1R4WFd1aFM5TzIrVUNrWW1udnFWMlVjUnhSU1JZK3VXM3dq?=
 =?utf-8?B?aHEyOVcxSkVCZ3BzTE5OTCtwQXR2NDFjbjM4dVUzcE1MRGdQWWFKWTV1OEJ2?=
 =?utf-8?B?d3FhQmNqMTB2WVNlRzFadW5xTXFoYi9WWTBtRGdxN05TUkRmZDhJRzJFY25t?=
 =?utf-8?B?SUJTSk0xUE1INmNwdm1sOEp6OG8rbWY0VjJrQ3I0WTExa2U3bk1IUWJCUG5V?=
 =?utf-8?B?cDRpY3FxMDhvWldzV01pOUFObDAwUldDNE9WSWs1Q1BPMTJ5ZWU3K08wbUdZ?=
 =?utf-8?B?L0M4UktLYVJ0UWsyK01oSXI5blBnd2kwS3dJZ29naUJ6N29PWWJBS1VEZjM2?=
 =?utf-8?B?amNTR1JvcCtDQ0trb2FwMW9Uc1RBVjY4dVhHZXhieW9neUN5UUlCU0JwbXEv?=
 =?utf-8?B?YzFKQ2t5TEM3cjJ2SDRRVkQyRjNFMXAzcDJrd2hacGtpNndxVFNQV09ndmE1?=
 =?utf-8?B?anh1enZTa29uVzBoVzNTdXhlRmpQdUp2OHREM2RZUHV2Z0tZQjQrUGRMLzIw?=
 =?utf-8?B?T2hmNDlEam90dWxlaTl1SlNCaFZaR1hvSFB0Y3QzMnhiUzRKanFTazZCS0p4?=
 =?utf-8?B?eTFpSnVxRndyZWpNZHdmQ2MzbUUyTlFLUU9XNmd3MlVnSTFCaW5zR2JLc08w?=
 =?utf-8?B?cm90OC9sL0orSER6eTZ3Z1U5Wi9nVGlQN0JsQURxUFBJck9FSkNwVnQvbS9i?=
 =?utf-8?B?alMzMHFpS0t2ZGk4TWYzeTArd05saGJBNDRYbWUraFdnaUpCd0oycE9qd25l?=
 =?utf-8?B?RlRxcDZQYVg2THkrNnRFUVNaOS9tbUN2b0tsS1JQVks4NmlxUFBqQTY2Tzh4?=
 =?utf-8?B?Y1ZJRUNCMlBTMkZLNzZ4eFR6RmtaT0x3RTd0eEVDVkE2eEF2MWdKbk0waWla?=
 =?utf-8?B?T1gxWWRMOVVpZzFib3loVThPcGlBRVBGV0xaZys0UU9NMDVjVjBQMmdPS1hK?=
 =?utf-8?B?c014dDk2Q3RvVUowUFBlRXZiQW5LL1B5SXdKYnludUJyamlSdTRxajVCUStn?=
 =?utf-8?B?K2pCRXNUb05VSk1DQ01vc3pBanc3VjNCeVpYL3ZBZndQTHJCRnBkRmtzdTNu?=
 =?utf-8?B?U1pjcG1Gc2QwazkzNER0SGlxTGZBYllwUXM1c0R2WFhJbVJwT0pzdEtaZWU5?=
 =?utf-8?B?eFpzVjR0ZUoyMEJ5dmNJaWN1bkFWeDZVUDN4a0huUmd2N3Nwd0JINjBuaFlw?=
 =?utf-8?B?bEtzOFBFMHNiWXJGNkFLenRIcVpGcUpKMWZza0NwbnJ6aEJnaGVBSXdMNTFs?=
 =?utf-8?B?OVg5LzRNY0tNaUhFV0h4V2VHa1E3VmFFVHl1SkVrcHRIeCtSYlBXMmJlcWh4?=
 =?utf-8?B?QXd5cWluS0k4VFJLeU5QTnM1RTMrZGg2cXM3SFF4Z3U0akpnMmMwTEUvT3pI?=
 =?utf-8?B?OTFpaUh4TytwY3BPK0I4SkpLeHlib3JTOFdYcUxVSmVoMUw4Mi9MWmtIdjla?=
 =?utf-8?B?dUVYK3haZ2RJYXFJRGU4YVBJdzlBUy9naGRzYmVrL0o0TEpHZGdvcTdsY0J6?=
 =?utf-8?B?M1ByOEdYOWxaVjNLZ1BaQSsyTGRuZVNPNCt5amZvUDkwOXk4L1JRK2Yvd1dU?=
 =?utf-8?B?ME5VNHJSZUxQaTByYzhaY2FZUzV2T0R2T2RHNm5UeGNtT0pONWZYVGVjeXpG?=
 =?utf-8?B?ZndBOTRzL1FDSmFvOVF0ODhWVEI5SkhDSnFnYkxZUEQwUkhtZ3BTaXd6bHo4?=
 =?utf-8?B?ZTQvUHE4Rmc3Mmxkc3NNaGJJSE8zSElBd1dJZGp5Q2JDaDVoVjJianFDbjF3?=
 =?utf-8?B?RUFzUDEzWlFqQ09Md0YvRUFnakFkbG9zWkV5b2V4a21FR1ZBUWFCU1ZFb2s2?=
 =?utf-8?Q?yIZ1UXeilWs=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?emlYT3o1aHM5YTNoMnFXVFdTT1BiZmVQT1g5ZS90WFBhNVFkUXpMUnpFdDJi?=
 =?utf-8?B?eXlwcVQwa055dmVjTUVPWUZpeHc1Ukd2b3ZiUEFvc2E4UU5qekRhRlpvT1RI?=
 =?utf-8?B?SDRsN1ExeE8vL0loYnRVY1dMTUN5WkFNR1VrMDczRHdZcmxoaHRkSDBJcjdy?=
 =?utf-8?B?RVR0YlJxQWR2em1PUUxQd01TYzBJZ1FmekhQWkgxTHNaeVBwejFZV3NNWVNG?=
 =?utf-8?B?V2JJZW1rTG85T1VMZEUwdjhUOVZ6WmpFMXdJNytlUUxtYWhiZzJVU2U3UVYz?=
 =?utf-8?B?WmNRTmtZeDNuZXlxTHNKNmoxSmpTWEdZRmRSMk5kejh0OW5pZUJZQjhFTG5l?=
 =?utf-8?B?ZGVwZ2JJcEpadzVJb0VpSWp1bDRzNnpMaHhDVlRvaGFwNlJaQ3l1eStCcnBE?=
 =?utf-8?B?Y2lTZjNVa0ZyUTYzUUc2TWUrM0Jmb0pndDRnYzhzMVk5dWx1citLLzVGZm5U?=
 =?utf-8?B?WWluL0lZSVIxaEJtTUNLR1pJVWJPWWVDdVFWUGtQRnFMWStuejhyaU5EVDVm?=
 =?utf-8?B?TFFwbnBBVWlNdFVXSWZacUJBQ2p1a0lSVW4vbjFnOHo5b3ZVY2VPL1VtM28w?=
 =?utf-8?B?TTNRU1lwcm8wZE1qcTRnUUZlWkFOeUhQYXU3cWw3SkNQWTBWQ2drK3NXRVBH?=
 =?utf-8?B?MEprQ09JZU5yVy9XNDhhRHRxSkVqaVF6ZHBkaThJY3RvL1lReWJmUE9wVDY5?=
 =?utf-8?B?eS8zNnR3eVNqcjFwclgycDVqODRyM3dlV204aTQwWW1xRGszOENDa3ZrUmV5?=
 =?utf-8?B?K044TkcxaHI0dmh2bmZqRllLVHV6N0Y3Rlh3cVFQNEgrZW9IbVUrMlVTQ2E1?=
 =?utf-8?B?L2NIaC8xN0V2U1Z6V0xFai9PTmZaZCsydXBCekpnZTQ2azBiclFWckFoTmJu?=
 =?utf-8?B?U0E4b3JpeHk1ell6QWZEK3ErMURGa3I5bnlpclBOdDNVTnE2WjlEdzU1c0hq?=
 =?utf-8?B?ZTJ5ak5DWGNiUjd4ZTdoRWRGNkI4bWdTd2hpUmt6VEIvN3ZZeGRXN2M3OGF1?=
 =?utf-8?B?dlA4cE4yaVU5RWZQeExJcUJEeXVwY3FIWUozS1NqdG1TVlFnWVpPTXhpeW9Y?=
 =?utf-8?B?QU02WGdUcGFTbERXUHVrbjk2MXNBRi9mYlBwRmY5VWNOQWE0NFRueGdDNkh4?=
 =?utf-8?B?TjFaSFRDaVllL0lONmV3VmRlckxyOWoya0FtR2J6WkZVbGdzM0tSNmtCNEVY?=
 =?utf-8?B?QkZpd0ZLeFNzTGladU9VVktzRklWZThkL0t6WFBlOGcvazBrMi9kbmtSTHo1?=
 =?utf-8?B?aFVGcmk2VXU0UnZnZm0yaUVHK0JhRllMSmtqekhPV3JMWkdMaksyMmtOOCsr?=
 =?utf-8?B?dGVQenYvNmJYSHI5VVY2L3NHZlY3TjdlWS9VVjVDaXRSK05kUnpIR3lLYTdY?=
 =?utf-8?B?Y2xXR1htZHpiKy9rZFJRazBFbTJ1cFpubkgrNDYwSXZUbTl1ZlFGbFlpTlNQ?=
 =?utf-8?B?VS9rWEZuNlVvai95QXQxcmc4dnZvaWJpRG9zemZUbFN6aTNBNkRiaEZJQ2Zu?=
 =?utf-8?B?Ym1KQ1UyOERsZFAzSUtoN2JKamtEMTdpQmp4U3pCa3NlVW5FYWdYMHE2b0dx?=
 =?utf-8?B?eUxxK3BrVi9vWmpGaDB4VXZkZ3BFZVIzeWtLejdxZU1jN3ptNlBYTHhSQXpS?=
 =?utf-8?B?K0pWREhyN2ZTUXRpUVJ6a3owS1UrK0d2LzJUeHpTL3p1bXl2MUowVFUrNzZm?=
 =?utf-8?B?ZkJGSGpBaVYrdC9ONi9SOXB1b3NUejdMV0s5eUNZaDkwYU52OEtNa2dhYW56?=
 =?utf-8?B?ZUNXWERmcDZjL2k0UUZLdW9DY1MzSFdvMmd0SmxzSWVWSnNieUl6OXo1YWFo?=
 =?utf-8?B?RU9LMUF1T2cvV1dxODVtV2QvR1BZMjd0ay9PdXR1dUJDcWJCMVlLUm5hQ0F0?=
 =?utf-8?B?YzhoVzB0NC96VmM1SjdlVzZiaVdjYWFQNUZFL1ovMVYwUGt5ckwzeUsyRkRR?=
 =?utf-8?B?cks3SDVxeEVBMGZtKzV2WmtCaC9ZWHJMTmVrQ0JBQVpCZ2Jwb2NEMHlEMHU5?=
 =?utf-8?B?TTFUT1NkbXhaYzI1dGFMK08wMEwwdlBHSFRmUjM5SkJ3ZkxLR2R6UjZLTTJP?=
 =?utf-8?B?T0g1QUZ2eHVxYlQwMi9qRzBPYjU5cU1vRE5qUmdXSHkxSnBXTkgySDdKK21z?=
 =?utf-8?Q?8kpII3gEdLPNLQgHq4WZZLxux?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a51ba9f-baad-4e46-88ad-08dd9cea8d12
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 06:48:56.1851
 (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: ktflc0Bbi9FWOMoEAdZ35OiYbnHbXQRD5b50QnTTj7p08y+qpsve6RJ03cuEB2K9
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7018



On 27/05/2025 02:11, Oleksandr Tyshchenko wrote:
> An attempt to read access the GICD_ICPENDR register (where n > 0)
> which should be RAZ (as not supported) causes the guest data abort
> due to incorrect end offset (GICD_ICPENDR) in the case range.
> Fix that by using the proper end offset (GICD_ICPENDRN).
> 
> Fixes: a2b83f95bfa ("xen/arm: vgic: Properly emulate the full register")
> Signed-off-by: Oleksandr Tyshchenko 
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Tue May 27 07:18:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 07:18:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997897.1378684 (Exim 4.92)
	(envelope-from )
	id 1uJoa6-0006e7-7T; Tue, 27 May 2025 07:18:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997897.1378684; Tue, 27 May 2025 07:18: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 1uJoa6-0006e0-4i; Tue, 27 May 2025 07:18:38 +0000
Received: by outflank-mailman (input) for mailman id 997897;
 Tue, 27 May 2025 07:18:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJoa5-0006dt-0Y
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 07:18:37 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20605.outbound.protection.outlook.com
 [2a01:111:f403:200a::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ca1da2da-3aca-11f0-b893-0df219b8e170;
 Tue, 27 May 2025 09:18:31 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by PH7PR12MB5950.namprd12.prod.outlook.com (2603:10b6:510:1d9::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Tue, 27 May
 2025 07:18:27 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.025; Tue, 27 May 2025
 07:18: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" 
X-Inumbo-ID: ca1da2da-3aca-11f0-b893-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qQufNGK64L57zpp5X0Y48pkZFeCN7CR6C44ew70Xfxkfq3vNX2axPWDt322IukTI/2pKX7RPyrU/30qfJ0js7YJh1t4mrvK6Xbbx2zN4hysp7JTeTyptZ4lJz/w1oVw7k8bxDFspziepNWOmSQbTPUytyR6xrDWGPxxHo/jHWeZLyECorBBDiS5OG2OXFXpdUBnsj69PlEm4mZxNiJLeRwyJdvLJ9d4oLGvlYuEW/Z+Xg9m+mSv/Q43vFWNsTR/2DI4EBgRQnktC5FIIZ2zoY8HusZd6KSDMMHYNL3cA3cZ605RXSc2GlMJevCD7LPtOhemvEgdg4Q+bxsLkEk3pAA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5CxRwfMVLpvN9JfypqnMpIo1g/Jw7lYx0ffz23Z85nQ=;
 b=q37rEpBZS3Ks1QBloQK2LCvpiXPZCDKOZuyp567lP8JCcZK5vi/qzL49pBM9p9h9QrbEsOL7MMDvMxfN4oDDhy+R87uBOQnGCjE+Z1hCunBWom704tAvMm9MfDSY9eQy/Qi+sJV+Q9dDBWi/MthZVBZzGc80JDJlc4/xyYEh5Z/C28lU1WoCON1I44qPAYNzbAkgflYkdwISWP4696GLvs6x2ZVLg4eM4YYRtDyTLmpjl61PlUFWTWxVvMxbXLi55uX4PLtOYkMwNfjZBigraw9znitkx5Zjz8iIYL8+Brf8i4n3hV7JK4BVOGtbMA1l6JG1kuh3hwT0Y1wjkCF8pA==
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=5CxRwfMVLpvN9JfypqnMpIo1g/Jw7lYx0ffz23Z85nQ=;
 b=LFlsCkJ5HidDBYmu3eCT7pt1fCeGM9U1gR1nxxsR15RZTN7AHWJ2IOU7DxLlX3uruEJAvaIjo0fxgbTb3PRKiz/kuMMnFhXu1I4O5z+gmJ/AQ2hIqipTLAEch/kZZhEVkVAt5EnxBBSHp3V8uScFwwWbMcCv1CVeog/o9VB6ISE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Tue, 27 May 2025 09:18:23 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 5/6] arm/mpu: Introduce utility functions for the pr_t
 type
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20250523065406.3795420-1-luca.fancellu@arm.com>
 <20250523065406.3795420-6-luca.fancellu@arm.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250523065406.3795420-6-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: HE1P189CA0010.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::23)
 To BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|PH7PR12MB5950:EE_
X-MS-Office365-Filtering-Correlation-Id: 94d63d06-2ecc-4472-2f5b-08dd9ceeacc5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bzIrY0dqelNudkpKZVhPUVhIK3VaVVgyTENweTZSbmkxWE1yVjdnQncrUmJ0?=
 =?utf-8?B?cFVRcjNtdHdMMW04Umk1VVd5MnpZT00zNWNyYVhYeGR2QVduamtRYzE1OVJm?=
 =?utf-8?B?Vy9pWjlsRC9YU0tra25OMVh6UDZNVnNuaUQzSXprbW4vZVVkUEI2UFNJdzVN?=
 =?utf-8?B?bkxxak1IL2hLTnVjdjVEVHlsdXo2K05HYWN5NHNxOGdtYkpKY2lTVlpLaWxO?=
 =?utf-8?B?eHBxbW5VeTg0VEpQRlUyVmZXSUluMkNhTkNDQngrNi9KZytjQzNXRGlRTXRM?=
 =?utf-8?B?dUUyYmJKOGwvYWVESnpGV1Rvd01PT2Rld2NKQ2FWQUozaXBXY1BZa0NpQ3Zq?=
 =?utf-8?B?Nm5QMHk2UlBIMHBHeXB4RWMwbWY5ajlXOEsxT2ZLV0dXSXQyb2Jwb2tzWjdV?=
 =?utf-8?B?QURtdWtUYk1iL1Q3YTVJaDA0NXRtZDdZSnVualpFTjBQWUJkYlFnT0dVbnJI?=
 =?utf-8?B?bWI3MFBybStDbFJVNXczMm1FUGFxSDF6TjBvdmE5WUwrL3hORHBwb0dBRWZU?=
 =?utf-8?B?MGhReVZ3Q1dKMmdiR3lPL2ZHUFJVNWJoWngzYkpPdTdMUThDVGNBUlNDaHpB?=
 =?utf-8?B?b3BaWVhlbXY3YjlwajZLdFJBdzZTa0ErNEtzb1ZKOGlGLzZHYnhSMWNIL3VR?=
 =?utf-8?B?T2piM1dkM2hHZjZ5YlJTcEZINEZadFBid1lNTjZwaHY1em5TRHcwektpSEE5?=
 =?utf-8?B?U2ZUcnVySWFESkxMTmlFOFBHSnBEZWZxanNScDV4Z3N3VERZNjJ4TFA5N0JQ?=
 =?utf-8?B?b2Vad1VkNXo0QmRlM3grVFVadmVxM1pGNXRiZEVndzM5STc5R09EbGFnN0da?=
 =?utf-8?B?SFBwRlFzTWtyY2ZadE5BMHE2c1RWZndNNWpsRm9HQlFyeU5wSzN6STRjb1Yr?=
 =?utf-8?B?THl2eXZpRHhtYnJkL3FkZHUvV3MvWmtKN1EwWWNsWXptU2g5ZnpmbnM3QnF0?=
 =?utf-8?B?RWxPVk1tRFpKV1p5ZUU5U01JSVZEVkllL3FGQWNXWGErc2N5bVVlcStaVXRU?=
 =?utf-8?B?UzJEQ3VFSTdJdUR2VGh3NFBqcWpqemxnMzF2Sko5SGN2c05ZdkZlakhNN1oz?=
 =?utf-8?B?UlZBNlIybE16S1dvSXdOalp5WFFQNnQ3WkFGU2tta3pUTUQrdWdXdWtiL3Ay?=
 =?utf-8?B?VHYyQVZBb25xTUV1cm85Q3Ztb2RKYzAxVmdScjFWZ3IwaFByZUVFMkszVmxl?=
 =?utf-8?B?cnVWbGNUUjA3MjZKUTBvTzdBcGNIU04zOUpSbUJwc1hxZHdEdVR1UTJNTDcv?=
 =?utf-8?B?aVM0UWJuai9vVXVUb1BaQTl5dW0yZUxncmZaY2tpZWRHR2Yvamw0L3V3QlVu?=
 =?utf-8?B?c09DMkJPZk9zZC81N1hPVi9jd1VNSmZIeEZwY1dXV2hqNzFGcmNUT2Rncm9M?=
 =?utf-8?B?c1JqS2RRSURmbzEzQ1NHSHZiQ3ZkRFBCUGdZemRMV2NrdXBGY1dlYlpHNHg3?=
 =?utf-8?B?V0p2QjlUVWVrVHdKTUFCNWtiQXN6cy9kT2o2d2drSFpJRDlBZjRoRldFVFFp?=
 =?utf-8?B?cmQwOUg2b1QwaFN0SlI5a1VVSFZEVDk1d3FoZVR6MXJSR0pJT1BLaExnL05T?=
 =?utf-8?B?QjVqc0p3QjA3NlgvQUNwa01WeVZ0aDhheTJBWFc0QjI0Wi9WREJrczFmaDhP?=
 =?utf-8?B?VndjNTIzNVNzNWxON2xwSmtSRlVqVmNJeFBYZWtvMThCOXZzdnk2b1NCOXJk?=
 =?utf-8?B?a2RpL0k3Z3BSdWpEa09vYTNHYTk5T2NNUVdKMEJhQ0M2Yjh0T1lodzRPa1RZ?=
 =?utf-8?B?R0tGaUtuRzVlbFNmQ3A4dzdvRk03K0xuOGdrNE51bUFIUVZNSFIrbmQwWVJB?=
 =?utf-8?B?cDZRVUxiYkFPSkZFS1lsSmlYallQOGRMd3B2NkplY0xSeWJHOGNYKzNsTkFy?=
 =?utf-8?B?dU05a2JFV216UVMwckhURGozKytJZHlnK2h2Z2djWkhTQkk1MEswdFRHU2do?=
 =?utf-8?Q?tJjOAmp/05M=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?U2hsK2IzdCtOdmxRcjZnNXhMSlhxV1NIVG1mL2JUa0tCbXNrcVpHV2V5Qld4?=
 =?utf-8?B?R0YzMDhYZ3loRVFuNGl2dHVHRW9KcURJS3ZFWFdDblR0djhRdktzZTRwNzUv?=
 =?utf-8?B?WTNpa3haZjBJRzY5VGpwYUtqNFppTXN0dVJiZnNLV251dlBoQjBvUGR4Uy9h?=
 =?utf-8?B?dXlybkxJVEk4aXY0NkNiUWoxK2FBUmxOaXJEb0NCTVJMQ3FKQWovd2RFZDVT?=
 =?utf-8?B?Y3VKcE5hOWs2UHdnSFhHMEtJTjhuRzd6Nlh0a2xpZW9RTE1PWXNGckNUc0dt?=
 =?utf-8?B?enU5NFNURUY3VWNabFBjY2NjOHhkVVRjaWp4UCtTaW9mbEF5T0xvNW1mVUJ5?=
 =?utf-8?B?dlZ6MUZNTWZ3MXZobU43VXI4cFpicnNWb2FOWjRFMU9kODhrNDNNK2k2Nmp5?=
 =?utf-8?B?MTI3UlgydXNnUlducU92bzVlTXBNL1pRaUppRUE3Z05OdmlpR1hvaWRXRExR?=
 =?utf-8?B?Rk54dDNSamlXVWJ2RWNmK05zeFBhOEl3anUyTzlsemkvS0pNU0ZTU0tUOG82?=
 =?utf-8?B?ZFlhWGt4d0pwWjdHOHJDcjB0K29zT1JUV1BOR3hjajF6QU9oV21EalZpYWRy?=
 =?utf-8?B?c3ROQVpWL0w1bUdONWFTcmRvOW5rbS9pTkQyVnA1OENFaUtrS2tCN1VXTXVL?=
 =?utf-8?B?d3U5Yi82V0MrdW5xVFlXMWF4dmRIUHZZVm5iRHQ3cjMvWFJMQ1lDd0dnM2ZW?=
 =?utf-8?B?WFhjZk1oY3gwRWw1eDhvcFVEYzVLZWdvY1Q5bVZTOUU5TUtlUm9TVGNVVzNu?=
 =?utf-8?B?R3dMUlBaUUI2VzFGa3dxQW5ta2lrVEt2NVN6cE9Nd2NWRFlvKy9EVGhVSzV1?=
 =?utf-8?B?UHArMWVGYlJtVkxEcVU3TVVLbFZYQ2FuZUpMK1VHTGxQRFBqcmZhYmJUU2Mw?=
 =?utf-8?B?eEx1MTRxbXhnMXJZS1ZCOEQ3UEM5bCs1NHljZG5qUHZHdUJ1TXhvOWVKeWpR?=
 =?utf-8?B?UzRpWUJSY3hBVlc3cmpicDJETllJVzk0c3ZsR0FpdVdFTmhndlpyeEQ4QU4v?=
 =?utf-8?B?ZkxxNkZBVTBkUkk4VC8wME9hMHVITWNhay9YMVZERmF2N2xOTXNCeU5hcXhQ?=
 =?utf-8?B?N2NhK2pMckVCS2d4b3B3bDFKRnpQM2ZoZGlrQmc4RjBZcmwzTG5YaklvT0Zy?=
 =?utf-8?B?T1NDZ2RtaGdYWmNidUprdzhKbEY0QktORHl5UW91REdtY0lCbm9oaG1keGxi?=
 =?utf-8?B?Qk9wWnpiRWp6Wlp1cFdKaS8wQndoamtjZHdLRythVVVYeFRycEpXQVowODFZ?=
 =?utf-8?B?QTVxTWdjeVIrVzVWQU9ycXBKc2tPM1JaMm0xSzlSM3hmZEpMdEp0TWk3SjJh?=
 =?utf-8?B?Zlc5cG0xM1dQRnFwQk96VlpVQ3hnblh6bXRQWnY4anlCVlZEZHprZFRlVmUw?=
 =?utf-8?B?ZVl1Y3ZJenk5NUlMN255MkNuRE5sbGcxMWdnNlZ2NEpJdmNKWnhmZ05KeGZk?=
 =?utf-8?B?d1JMekdWT3MzaytwZVUwd2RnbHlteWNmankwY2Z1Y0JVZ1pMaE1aeGV4eEp2?=
 =?utf-8?B?ZFpscjBNaGF3dzN0NU1PYzJ3a1N2NmVxMmkvS2tXdE8zMFk3ZjUrQm1HM3Fn?=
 =?utf-8?B?NnZjSXFlU0xRREVsZVdUVkJqUFcyMFloalhub0FEQUtvamRhZkdYV3dNNkFB?=
 =?utf-8?B?V1RMS3o3SUJMTzd0cjVrS1dMVzNJTjF5WldOT0JOdmpoeEZxWWd5b0ZoTXJa?=
 =?utf-8?B?cTFVa2FFak1oellFMUVsMkI2VVh0Vngvb3hycHM0Y1Uyb3YyMjJFN1l0cHZP?=
 =?utf-8?B?V0RLV1pvKys2RVJZMmZpUDJnblljZW9MWmVycmhmYVQ1Wm04SUFMbG1Nb1NH?=
 =?utf-8?B?VGJvc1JGc0VTWDhNS2lJRktGYzhydEpuWWlrZ1kvUnpFOVRvNHJkR1BiVmJN?=
 =?utf-8?B?UkkxcGtZN3hMWXRiTllZZjNNeUxMMzVwTkk5OERER0JYTm5QUVdsRE4rV0I4?=
 =?utf-8?B?Mi95T2U1R0lLaTBCd0luU05qSzN4dE02Q3pGQkFIRXUvWU9lK1NMRFU1RkVh?=
 =?utf-8?B?WHRSY3BvQjNYMnRnbzVsVHZJbVB3YjlhNUkwa2Z2cTFWNU9DVnF4TUhHandu?=
 =?utf-8?B?VUs5KzJ2QTJKODJaSS9jQm1zN2cyWnZGVHE2ODhTSE5lck0zNFR4bi9aMHhZ?=
 =?utf-8?Q?Knn51am08vdwNvwU+A8nf1Zad?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 94d63d06-2ecc-4472-2f5b-08dd9ceeacc5
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 07:18:27.3993
 (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: qQGcwz5g0E3SVG3AsuZyNpqV7yw+6HhNDACEMOY6nJ/LXX9zCGl0Ur9dLnYWcKmh
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5950



On 23/05/2025 08:54, Luca Fancellu wrote:
> Introduce a few utility functions to manipulate and handle the
> pr_t type.
> 
> Signed-off-by: Luca Fancellu 
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Tue May 27 07:24:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 07:24:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997905.1378694 (Exim 4.92)
	(envelope-from )
	id 1uJofq-0008Gi-QJ; Tue, 27 May 2025 07:24:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997905.1378694; Tue, 27 May 2025 07: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 1uJofq-0008Gb-Nd; Tue, 27 May 2025 07:24:34 +0000
Received: by outflank-mailman (input) for mailman id 997905;
 Tue, 27 May 2025 07:24:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJofp-0008GV-Kc
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 07:24:33 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9fb366ad-3acb-11f0-b893-0df219b8e170;
 Tue, 27 May 2025 09:24:28 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43cf848528aso31965105e9.2
 for ; Tue, 27 May 2025 00:24:28 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f74cce5bsm254662365e9.24.2025.05.27.00.24.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 00:24: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" 
X-Inumbo-ID: 9fb366ad-3acb-11f0-b893-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748330668; x=1748935468; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=nmBoGMb65jQencl+T6MB+gJjSD6HDzfiSCDyL4OuV+4=;
        b=BULzsyXvbOu0NGQ7N4x5HY3fJem2a4HTZixfYxOX/dhOHIMi4cdwietZRe7foZM7gW
         AEUgvUyQkvBbQMjgi3+/CVjnDk5xa7NHJYOOMdITOVFO4BmoA5hynnQAs5HxBfV3CEZG
         gMa+DwfHR0zFtOQY9o5BkPi71jDdog6FjPOdI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748330668; x=1748935468;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=nmBoGMb65jQencl+T6MB+gJjSD6HDzfiSCDyL4OuV+4=;
        b=tmDKAp8zl8s7NXlOBLM8hP1yFO6TzE/KN5hAgZOUv7FqqmxZ061KsHq0Bt7AvTn6pp
         C7LEFFncncuYruK+4gqsXr2Bw91zeuFWVCBeCc/P9HrAFJTDGOo0WVawxcWoFRYnKokx
         a4VBq8dftegC1cx3jwD1dew4HbJhceA3bLA/G49SsOgAP1JKpYpIps0RseXx1T9SMsRi
         f49Umpl4TjV0W+QbxCE3s8q95P225q9YEoOkiJZh/ZoWYsM+Io7XRTNQ0iP2gmowL6Mg
         0H06sB36m0d1csCkQojkDqedzIpJRDOjojYtItn7b0+lWblrIg6huv3nKBoj4cDyiWBe
         nqjg==
X-Gm-Message-State: AOJu0Yw/4yJDG02LeWNmJ5YaVwdyjeX6dhGsPG0Fsre3aw7gJifAfuF8
	1XJzBgdEKKkX+NWK/6gW49Pm2S+7xfdnQp2eWs3o+36K7Qw7q/m/vuqHLOrv12iNKkw=
X-Gm-Gg: ASbGnctpsR7qqgpj0xNjXdqWkFnh6sC7/fzqAGjKES2jEOaLXRJWGLVgbt5EC8ZakeH
	D4/MLC8SHZJWS5qhNNty7n4Hf5suJaZnxHtZovFtUB5cbUyRUmBpWUWI36ezZRxwedUmgsGxRaD
	Csd4BLC0S63TO6k3tauQaySMW6D6dL1u/JRd1T4qzLVbXPrPNMaR60jqKe3gvmB2CjhR0wDDkG6
	Cd2VEzfMEDl+e8q+TqsVIr/pwXWSKNTuq6V2A24FXLNxC2O5c3Hc+pT8Ugpk9mupplmYKV2gCB6
	+S8C2L0Nd2SBTGTyokbjkgFR0W7ziqFL+JHp7drxeq3zf3LYUZY44v4iozbfi8/Y9zMdKqgVhm2
	tC6UUmLVsAVtK3Iixlz8emifRbN6tUw==
X-Google-Smtp-Source: AGHT+IGTRVf8wYKXNuKcMvVnjEQey6aNYisfZ4LGPtXtCShGgi2PVXgNHIUW59cGp5qdDFFM/FgfUw==
X-Received: by 2002:a05:600c:3b19:b0:442:e9eb:cba2 with SMTP id 5b1f17b1804b1-44c8f25dab7mr122447655e9.0.1748330667983;
        Tue, 27 May 2025 00:24:27 -0700 (PDT)
Date: Tue, 27 May 2025 09:24:26 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Jan Beulich ,
	Petr =?utf-8?B?QmVuZcWh?= ,
	Tamas K Lengyel ,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH] x86/vmx: Fix VMEntry failure on ADL/SPR with shadow
 guests
Message-ID: 
References: <20250523160558.593849-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: <20250523160558.593849-1-andrew.cooper3@citrix.com>

On Fri, May 23, 2025 at 05:05:58PM +0100, Andrew Cooper wrote:
> Paging Writeable depends on EPT, so must disabled in non-EPT guests like the
> other EPT dependent features.  Otherwise, VMEntry fails with bad control
> state.
> 
> Drop a piece of trailing whitepsace in context.
> 
> Fixes: ff10aa9d8f90 ("x86: Add Support for Paging-Write Feature")
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 27 08:14:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:14:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997920.1378704 (Exim 4.92)
	(envelope-from )
	id 1uJpRt-0006bC-9R; Tue, 27 May 2025 08:14:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997920.1378704; Tue, 27 May 2025 08:14: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 1uJpRt-0006b5-5b; Tue, 27 May 2025 08:14:13 +0000
Received: by outflank-mailman (input) for mailman id 997920;
 Tue, 27 May 2025 08:14:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJpRr-0006au-DY
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:14:11 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on20608.outbound.protection.outlook.com
 [2a01:111:f403:260e::608])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9037a8e3-3ad2-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 10:14:08 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by PAVPR03MB9600.eurprd03.prod.outlook.com
 (2603:10a6:102:30f::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.22; Tue, 27 May
 2025 08:14:04 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8769.022; Tue, 27 May 2025
 08: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" 
X-Inumbo-ID: 9037a8e3-3ad2-11f0-a2fd-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rVzIuSq6wNJ6WoPCz+F2RThux3S8bCVpXN9jcbYF4hHX44xZuONR/sk3+DiXPpHNyfYrJc5HX7wiU2d4RfK80662i1ESrpL2rC4IrFNxWHlaUTfafcBR2ZXIHnTzeC8eEls56tYGl7u+CjE5kD2q5csrvrLwGiMH7EGfYd1lGu9MRkdZfRqoCTzO28tpYBMT0jcdp9yUN80I0kBf5f6AJBVI6T2o0S1vML3qOUUg3b8f6RidrvGT8vIg9O8mJKYHyhu0HEcTeWC099uOXtbP/l7YvJE9v2tnNdDLPwHGuy8pr5iPRrIntukUNcJjJZmEqyrzy0aA5Ika/fkgoVqh5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3mGVgixyFqAjabOC8dXkIkUxj2XKxnmKxYam2jZBwt8=;
 b=UrY4QEp5kdEoU2DrKyDiq9PvMDyB+ryyzymxCakP9Mxi0s2/19AdZTYhQVRT96N9Kcn2ITiLF2bJux/HxRsYWUpIkaJkDxyAOig6pJrKOaQXeaAQlNopnf5OtnyWsdzQfH6d3XNjqPAT/gYuSH7y8RaHXhzS97RYg0YoE5R1YNKIsMlRq8xe8FAtL4mooadGjzoCUYKzdcxrJXdzqFi42Jijj7Nm/99j36bNZJCnnGDuXf4eqOq2T+14Wa8b0Z0akQ+yNSK+QE02yCcJM3zOO3ZUNlO4rFmIDZkHD2nq7Pp5ONHjRfrpeIa+Nx7M/3KI4lKGvhz3tPCYjMlg63f8wg==
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=3mGVgixyFqAjabOC8dXkIkUxj2XKxnmKxYam2jZBwt8=;
 b=Hyp4OQOMHoF+uR2BQ4jzGnH3/uxfb3s9kNprBx6PAEzEvHFktD1NUwkaldbJhhYly30QQPB8xlUtvXxtl19uE8YFj5wy+O6tcl98NyM5zlKZz47rspsoVfG5ocdmumDHmvUc9ILBhlXle0lHx5NC49ZWzDgnuc01EMYZeeoqdpwT6FMjnIGRH2nSkO+zwyjCiEFc6h6y6xIuiIjFeqz+I/otN/GHZNnGtgO2lVCr2kmeMDraOtOFYyI2xEuHJEpsVhqdgtdEBqNa3yPyT9TldzWgBwyGOgvAAQMadSU3dM3gShkaTweQ+qowVZv1eDMvpRWmeHDqeLtbK68yJFpprA==
From: Mykyta Poturai 
To: Jan Beulich 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Andrew Cooper
	, Anthony PERARD ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v10 6/7] xen/arm: enable dom0 to use PCI devices with
 pci-passthrough=no
Thread-Topic: [PATCH v10 6/7] xen/arm: enable dom0 to use PCI devices with
 pci-passthrough=no
Thread-Index: AQHbuP0k0QR8aqz5V029F3Jm2fq6qrO6kBmAgCu8ioA=
Date: Tue, 27 May 2025 08:14: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: 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_|PAVPR03MB9600:EE_
x-ms-office365-filtering-correlation-id: 06167b80-ff67-4d06-6d15-08dd9cf671df
x-ld-processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?d2owS1RpbHp1ekRHQnZXMDlQU0hPTWRhRTVyeG92UTB0SUtkZkZwb0dwSUhy?=
 =?utf-8?B?a2VobnpLcEhQSUM4UTNEUlNZUkIrcW4ycFR0dUs1U0dOV3hsdFpXUkdJRmp6?=
 =?utf-8?B?L08zcVlSdlN2eVI5TEYwZUdTU2VUb3RYekhodm9TQlY2azFtNk80cE9GZ3VU?=
 =?utf-8?B?Z3NsbnExWFdWYlBzUUFEcmIyM1AvbXdTdGtTS2dSREE2bTBXRU9ibHdTbDZN?=
 =?utf-8?B?ek1scEc5dExuZ0tGUEpGVHd6Yjd6aFR4Vzl3Nmk3cFZRQ25YalFNVE9qbkdT?=
 =?utf-8?B?SU54Ym00VzRuNFVuOVphcVltdkpJUXhsYlkyMEVvZE11OUNXaUJkRnFVWDNL?=
 =?utf-8?B?WERMR3pNS3RwNDdxb2lpNHMvdkxyR25LWmNUUStRYWxtWG9yNFNFVDY3ZHR1?=
 =?utf-8?B?d1krbVFySWVQZjFHWTFkZHZOUXRXVWFyQzdSMEpYam1MK0RLZ1NLRExQY3I1?=
 =?utf-8?B?NkxMZndKUGJJWTkxVm1pVTlaYkZWYU5iN1QzcEJOVDhEMlpHRzBPbWxYamdx?=
 =?utf-8?B?SVVhTWdoQ2RmbEJsdERBM0krd2VaOGxNK3FDRXZXQjBCN1ZUaisxMXBCeitr?=
 =?utf-8?B?L3BJbVoyY1Y4QjhMa0h2UTBzakVRdCtlTEFBWHVxeWxXM2tpSm5qWmI3ek5D?=
 =?utf-8?B?V0kvbG9XMGlTN3gzZStDSzFNVWxJWTB6M2xhVFVQV1drdFQ1Wmhlakc3N3Vr?=
 =?utf-8?B?Uy9QVG1QanJWM2MvTVNwYVN1MXl6d29vVEo1VjdqLy9JMEJlRU1laVZwbmhC?=
 =?utf-8?B?MGlnQ0wzbTNncFNabGhzeHc5dVFkOTNaaWh6TTQrdjMvczl1UFpvSWFMeWE5?=
 =?utf-8?B?eUZ6eDZBRzAyVUxVbysrL08wcnBOeGZWaDdFcyszS0VJYzBKQTBUWWNRREk5?=
 =?utf-8?B?YlZJN2xtUTB4REpKWE9ibGx2eG85eHVTL2EzMUc0Zlk4dXB3bW12OEU4NDcz?=
 =?utf-8?B?dXp5MHdLd2FKck91MzdWdFFBeFNodmZqR2YxZEtlK1dQTHdqd2JGdERiSkE3?=
 =?utf-8?B?Z0J6dDBEa3pKQU5Qdm5CQnB6ek5wVWpOQ3FZVFE4dFc1bFRHOVVvRmNBV3NJ?=
 =?utf-8?B?eDV6K29md3ZZWXdTRjlMcXpLUmZRaTJhYXFQdzlMckplZWI1NXJIbGFpWDlV?=
 =?utf-8?B?RW53dFZFdDRSQ1lGeW5tOGhLUkYxQ0QvQTlBZm5wUWZjdEpycUk5MGY0MTlP?=
 =?utf-8?B?bm1pK0M2VEZvaFlOVHBPOHRXZXlLeHMvclVEcnJISjdWUmxwVTQ2bEYydVlO?=
 =?utf-8?B?OCtYQlAyVkVqY2NYd251OHNQc2ZnYWtzN2ZUZ1k4dnUvNWU1VnVJRW1SdlY2?=
 =?utf-8?B?SHhraUdSQVN5eW0rbVpEU2lnNE1QaXhDWEdaTWtIelp5NWRnYjVSclR3aVZm?=
 =?utf-8?B?YkZKaUJwd0c3em1YOWJCWk1aWEJmbGswTUZnS3l0WDlKZmtFb0psTWovaE1F?=
 =?utf-8?B?K1NFdGJadG9JOUxIRm9JUVBpWDdIdyt3Nko2cEttZ2ZJL2MxbElqQ2pmVzNI?=
 =?utf-8?B?TGI0dXczY1A4aWVjTkVqWG9mYWQ5cFJKM3V3QjQvMkl3R3dlRHpSUWV1ckF5?=
 =?utf-8?B?UCs0T2pXZ3hTRE14NWNleEw5L0JDQzBDKzk4eHFXTXNsTWN1VDVjOWdTcUlv?=
 =?utf-8?B?bVQ2bEhQSHYrYytqd21HazlRYmo3dDNSdEIwOWpRVEJpZVIyM1VMbWUrNjgr?=
 =?utf-8?B?TWxIdHVMY05GYURyVkJ1TjlNUFZ2VEo4eGdWTURPRHAvUEYybS9jTUdWTktL?=
 =?utf-8?B?bmRRSHJWTDB0Z0RwdWZLTUI0UWtzZnRMdUlHdW1BQWIvVENqVGYyVjdIRTIw?=
 =?utf-8?B?TGtXZU1vdWJaK0lMR0M2ZEs5c1ZJQUVFNHJQK2tLOFZ3QVErcFlwd213bE5l?=
 =?utf-8?B?UkVLV1ZIUVN0eFdQcU5Kcm8wTndCejJjN3NUKzhlUGRMZ2NxZENLS3hVeTZK?=
 =?utf-8?B?Z1VlSUNWOGh2Nm1xTUpudnY5NGluZ2FmMS9DOVhHM3NaV1Qwa3RTOHdEQVlS?=
 =?utf-8?Q?M38k9DuyFn3hO/Ez30M+YUIZAukWCI=3D?=
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)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?UDIzVU80MXJFYkpWWitwTTduWER2WWxob0hvMGo1TjcydDk3RlljOW5NTEZs?=
 =?utf-8?B?V09qWHpyQkdSbU04b3lNSFpNUE5TbWtsTERyU1Mva2xVVHN4NCsreEl4UHEx?=
 =?utf-8?B?T3RhaGxFRTRobmRBY2VQN0x0dzl5czJvMmtXdWQzb0cvNlN1SFo2MnZVSUhB?=
 =?utf-8?B?YjZJUlJ5YjdKbHJsTWtZVDd5K3VUanJGaDE4QmFuY2hFMC9wVnpqODZkTVhJ?=
 =?utf-8?B?WTBETWdyS2hDajFGVzhsOXZoUEhuSlA5eWc5cVVEdUZhZnBPYWtnSEJ2R2lC?=
 =?utf-8?B?NzR6d2QrT09wMXBNWm9BeGpRU3pIK3o2a2FyK1Rid01tM0MzZndyNkg4ZHcx?=
 =?utf-8?B?SVNZZlhkR2dHVkMrSkVYbUxNZ1ZhRzBDK2VEcjdVNmlES3ljaVZlT3ZOZGl6?=
 =?utf-8?B?cWlJYy9STEdQdzFVRVlnWS9LVXlIc3k4Z1d1UjdKL1dBdWJGZWRZNFJUeE4w?=
 =?utf-8?B?dXdTWC9OVjcvRXRsenAweVlLdVY0ekxZcDVDVE9iNWZuWFIwZFdjeHVBZW9y?=
 =?utf-8?B?c0FzSDNJdVFPMldGaHIzT0xSY3czeUpFaXJkdnAxVFNVYytnLzQrR29NQlJm?=
 =?utf-8?B?T0FqT0traEpaOXpWbTNtRW9yTXNaUk9Zd3VURkxyL1dRajFpQTNsNlhmZE1q?=
 =?utf-8?B?bmRVeTVxckNiZTVkUENtL0Z6cUJ4RG1NR2U5b1hnT3JRcHVxclNVRktIekdQ?=
 =?utf-8?B?Y1YyRXdBVWpTUHdlc1VJUWd0OHZvckRRaWhGZmNUcFFwa1pQWWRSeFlOYjNE?=
 =?utf-8?B?WkRYZG50eSs4MSt3cjk4TnU1Wm9uTXE1UVFKcHZCVXNSVGdJVlMyRDBURUp5?=
 =?utf-8?B?ZGdKNUNWN2gvSUt0SHVoeWxzS1pWME1qQjhKTVliYlpjM2d1M09jMkdSRDBv?=
 =?utf-8?B?RVgzTnN2bjhoUk5hWXR1QzZZc1czSEhjd29JT0I3VXJwTHdObUJrZGpWTkp3?=
 =?utf-8?B?SzdLY3FDTGdmSzBLT1lMemI2eVZmTlU2K2lycWJxQzFKOFRYd3dvVWZzYnRU?=
 =?utf-8?B?d3FFU2FDT01rZ3lxei9PMjZjS21jcXJIWGVXRTNKZjlYbHprcGtPaUx5ZlRy?=
 =?utf-8?B?VnVHWnU4YlpUKzU4bk1Fd3ZoOGdrbXloaHpGWEgvNDk0dDdNSUNVT054T3lS?=
 =?utf-8?B?c2pQVWtKZ1oyNS8rVnQ4TE8rb0pnRU9YTCtQK0ZuRFBUc0dBUDZNd2pLSk9Q?=
 =?utf-8?B?U0Z3TjU1RHBtUXQxVHI0dGRrb1lVRnYrSFNqdmo5U2RId2RrcE5IdFhYQ0RE?=
 =?utf-8?B?dm1OUXh4TUQ2SWdVdXFPbnZQK083dVN4TzB5eW1FNThRdyt1MVBIRmlPQVB2?=
 =?utf-8?B?dmFaSkE4Z3NVMWJrbzJkdjgwNjhyWVZrM3NOVDdEU0tKbllsMXBBc0hvUEg4?=
 =?utf-8?B?N1AyUGpsWENkZlowVzdYNDZJSkw3U0Zqak0yaGQyR0JjMFZKbm5HNm5vdG5O?=
 =?utf-8?B?VVU2WGRHQkJ6SWdOd2gzRHE2WHp4blF2T285VFdkYmdmcjI1aXA1QWZpTDFs?=
 =?utf-8?B?NUR4eThDd256amNVNWh6eHJxV0dTZVB6UjhVaWlrUGZjQVlHL2JUTkdOc2FL?=
 =?utf-8?B?ZzhiT3N6OFNvQ1l5OE1lZDZBbTFTNElKOTA1QUZXem12WXVMUXo0T0hwUW9v?=
 =?utf-8?B?WnBVZHMrSWgwRjhUSUN6WHlCR0VTSllOUWFhazdveVlKUnFhNytxMDFtSEdq?=
 =?utf-8?B?ZHdHUW1IV3dNMHVPYkdIa2ZoVThQMzByMmU2YTVRQjRicVgwaE5hOW16aVF2?=
 =?utf-8?B?QU5jRXc3WnVDNUNjWGU0QmlESlcxMUhNVXlWWjB5ZUFPakliNHFkWkpuWmdF?=
 =?utf-8?B?bUxVWThhc0pYamVDaXJuc2p3UmozeGJGWnNSYnlTWDhOZTNhNHlSc21yc0lR?=
 =?utf-8?B?VzVtYzQvVEQ2d3ZMbFFTOWZ3WHo2WlJOMStBQVRMMFpIQUlXUlloS3NjbFhs?=
 =?utf-8?B?VnNRNm1BY1VaZ3B1QzVaZFJiSDl4cGlUNFdkbW1JOFJ2Vk04V291NXlZWm9T?=
 =?utf-8?B?OE1BMjNsUWI1Y1NEZy9ySWJlcDM4MXordEFTRmx3cFd0RU1tKytXMGo5SHZW?=
 =?utf-8?B?a3V0SWFFVk82SEVWaFVmbGI5TjlDTE8xOFZvOS9iR2dvK2g4LzBkbUVyZFpG?=
 =?utf-8?B?KzVCSUJrSnA4ZXVGSDE3cjJIK2c0bjhMSUhOaXVsdVBQVjNRRlJHQ0tXM0ZZ?=
 =?utf-8?B?WHc9PQ==?=
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: 06167b80-ff67-4d06-6d15-08dd9cf671df
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2025 08:14:04.2670
 (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: XbzJL+ngI6vkz2NpclMIUU07KFWCBQAt6H/gQrokV9ZrBsII8a0FL2fMGW0dPOqzs3BTm+XvWenl+Sr58G/vzg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9600

T24gMjkuMDQuMjUgMTU6MjAsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyOS4wNC4yMDI1IDEz
OjUyLCBNeWt5dGEgUG90dXJhaSB3cm90ZTogDQo+IEkgZnVydGhlciBub3RpY2UgdGhhdCB5b3Ug
ZGlkbid0IGFkanVzdCB0aGUgInJlc2V0IiBzdWItb3AgaGFuZGxpbmcsIGRlc3BpdGUNCj4gbXkg
ZWFybGllciBoaW50IGluIHRoYXQgZGlyZWN0aW9uLiBMb29raW5nIGF0IHRoZSBjb21taXQgbWVz
c2FnZSwgeW91IG9ubHkNCj4gbWVudGlvbiBQSFlTREVWT1BfcGNpX2RldmljZV9hZGQgYW55d2F5
LiBJIHRoaW5rIGFsbCB0aHJlZSBuZWVkIG1lbnRpb25pbmcNCj4gdGhlcmUsIHdoaWNoIHdvdWxk
IHRoZW4gKGhvcGVmdWxseSkgY2xhcmlmeSB3aGF0IHRoZSBkZWFsIGlzIHdpdGgNCj4gUEhZU0RF
Vk9QX3BjaV9kZXZpY2VfcmVzZXQuDQo+IA0KPiBKYW4NCg0KUEhZU0RFVk9QX3BjaV9kZXZpY2Vf
cmVzZXQgZG9lc24ndCBjaGVjayBpZiBQQ0kgcGFzc3Rocm91Z2ggaXMgZW5hYmxlZCANCm9yIG5v
dCwgc28gdGhlcmUgaXMgbm8gcmVhc29uIHRvIGFkZCBzcGVjaWFsIGNsYXVzZXMuIEkgd2lsbCBh
ZGQgdGhpcyB0byANCnRoZSBjb21taXQgbWVzc2FnZSB0byBiZSBjbGVhci4NCg0KLS0gDQpNeWt5
dGE=


From xen-devel-bounces@lists.xenproject.org Tue May 27 08:21:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:21:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997932.1378713 (Exim 4.92)
	(envelope-from )
	id 1uJpZB-0008IV-3G; Tue, 27 May 2025 08:21:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997932.1378713; Tue, 27 May 2025 08: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 1uJpZB-0008IO-0j; Tue, 27 May 2025 08:21:45 +0000
Received: by outflank-mailman (input) for mailman id 997932;
 Tue, 27 May 2025 08:21:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJpZA-0008II-61
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:21:44 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20623.outbound.protection.outlook.com
 [2a01:111:f403:2417::623])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9dc925d0-3ad3-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 10:21:42 +0200 (CEST)
Received: from DS7PR05CA0103.namprd05.prod.outlook.com (2603:10b6:8:56::18) by
 IA1PR12MB7709.namprd12.prod.outlook.com (2603:10b6:208:423::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.22; Tue, 27 May
 2025 08:21:36 +0000
Received: from DS1PEPF00017090.namprd03.prod.outlook.com
 (2603:10b6:8:56:cafe::4f) by DS7PR05CA0103.outlook.office365.com
 (2603:10b6:8:56::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Tue,
 27 May 2025 08:21:36 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS1PEPF00017090.mail.protection.outlook.com (10.167.17.132) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:21:35 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 27 May
 2025 03:21:35 -0500
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 27 May 2025 03:21: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" 
X-Inumbo-ID: 9dc925d0-3ad3-11f0-a2fd-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uPfW6FHIi0EOMa1iJwafhJivyP2sCXK7bYjaqWBerQ3Ege+2upNOSG9dGG4n4Hn9tOu17A2bdOHPRwlNi+KfNB+DlE1uZXKsrH1rM6kdMuwrGGuigGQMaVtcd/xQ/eq4mOhDXmURM5vbXk0VIJWawkZM3nbCMWtvHDqe6BkhmMzzYeX72iO22Rb9s2y8fQnIK7DyxI75Scj5XJt5hAfI8YAczhBJkVhG7EMVmvUr2d6DDUpyYO3lecuCF4sieZsp7gkpqZ7ctj3tElPssGY+KKJKunCj1l9umlMgCNf0oegiLBSJ4DkzPP4wJLXHbW428Tw/cflrPYhAATICgvo67A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=W0Z01jTySH/EuzySEtYep7TaxXxwh8oPDWV487W9Gjo=;
 b=XcupaXMNCZ1Jsf3KKG+bmyuWvwzfe4dbhpV17E7KvmXDqnzS/SP552RvBZj90u01MNvKNcwa9N54uIgCKtlc1062C9e7AQNJG0dx2551SxJAeDZenBPHeX+zaWODYbV7zunTqDorgMZ/TYkx4l5EmeWPwEqynmwlfx6h1ax1/Hrpp5DLUwo3X/9H7AdiJ7es6UYENPgB531Xpj3tWprI/jglIQrZi9yMCj/zOeqMCDdcw0zPYb20BiDT2ULKwE6U7AJBRwzVFne7ENiZ+o0Jlxso23LGw2rlYXVZF476b7r3KMh2Id8pSpyr9WPkAYABr9qbQu6+obDOebGSXzhkbQ==
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=W0Z01jTySH/EuzySEtYep7TaxXxwh8oPDWV487W9Gjo=;
 b=Fsz3QgLCY18Gq8bxoAUFj5U3vNuVpFjOFEcVT6/QEUGQRZlIA3LzQ5PD0dOXRN0TVoffrxBpOc4mhr+F8jgxWPYT4R0O9CrebnahFCxsOuE8tEffHHE7uYy1gLMVNCugu1EgPoSG/xuel3pWWcOpXjXldYPprUKXrvGufXKr640=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.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] device-tree: Move Arm's static-evtchn feature to common
Date: Tue, 27 May 2025 10:21:17 +0200
Message-ID: <20250527082117.120214-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS1PEPF00017090:EE_|IA1PR12MB7709:EE_
X-MS-Office365-Filtering-Correlation-Id: db11e12c-15a8-4251-c6e7-08dd9cf77f14
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?M4kGJMApsy61b9c72cHEK7Kfi67wI/0Mh2YdfDwTikTQUFIyYSY2kZca/2uo?=
 =?us-ascii?Q?iEwuaV5rvn5JH/0VCGNSeZii9ifWJrPTTw9ltVA1yD1YO8nWm2EyAS5srtiT?=
 =?us-ascii?Q?8wB5zI1kqNODMM7CZZ7ODFP70G5zdQpkCByofOrKvLVNoEzZ0VIYggYeuVl4?=
 =?us-ascii?Q?fzwMrF35dR3tzUMZYLfzA+hGg07ZGNhQmeYoAXrt8dFBp3fMg6SU5UtOImZH?=
 =?us-ascii?Q?EHnwBksHh9IxeyUhLN6UVlACaDkNmUTtML3jC85mB35AC9JN3ltofOk8kfT6?=
 =?us-ascii?Q?ne9vIdezgBn8XR9PDzxGVrMZcoT9xkIFmENWljOwsWzyAlIxubncfRAOJZbr?=
 =?us-ascii?Q?vC5zlqWlO5vkVIYptxeb3Poa/KxQhllhFp+GhvodRS9NkwsyshP2h91sVfsO?=
 =?us-ascii?Q?p8crPUjx7x5hIZNMER+6pLfgZdUPNuRi74jsA3qqz8XT307qld0KCP3xZaXy?=
 =?us-ascii?Q?xxb1wll8IF9BYx+fc5f1Zz1bd5pnUnO0Cg60/OnNgAalYSnEZqNj8BJnaO3g?=
 =?us-ascii?Q?U8t15G1mO/KxlWCg7+ydwXJTNJqvA1BA6945ErpEzXk26Ena3D/k6XM3/TFi?=
 =?us-ascii?Q?3Ger748O7HUCSgNVy7LzXLdO99YJ1Vw8ZuMTa1ZrT3lHlQWYCqpw+lofnL+8?=
 =?us-ascii?Q?iMduHPDmU5rph2wsFdhUFKMSX7mWb6EhWvOEmFucREFCNujUhOnxuRpxLW/+?=
 =?us-ascii?Q?AfebuaAr8ehb1mmhOsS3pbiSugSUh5w5ymOsuvIqGpDtsF61dk8Ri14WGFP2?=
 =?us-ascii?Q?u0LUFgjuZrFP7P10GN9BGtqC1zOcpRodC+Q5sNvgt8Mf2CRTmJTN2Lfkwsfk?=
 =?us-ascii?Q?wvyrolrxcI6oZLG86RD0Fb5v5Df52pK4cgNqOWgJfBMKxFO9pI//3L7mbBeI?=
 =?us-ascii?Q?YZ/VwilNlJyuJdzuDggDaYeL7p/IKM9t3INggEh8duEjWHDFDr9TxcNT4RQT?=
 =?us-ascii?Q?txEOmOZeXJ395czcg2Rnn0qf9+0xhv4LiMlayoekSGg6+rh3qlyMbBnqoTVp?=
 =?us-ascii?Q?YZZb0LzMt6exViEVIiBvJBBPYlXbpShZsqdHPHEcH5A1vIyoyHIwYavgl89v?=
 =?us-ascii?Q?vdM9ZtSYsQdVYkYnjsDqJPSuYhREbJzZg2a1VL7CanNY+0r6D81iST04m8xw?=
 =?us-ascii?Q?WNp3LQmDljEcaRNS3zC3sH2tnA0kUrFv/cZRb2wFsE1vv0micePKXiBYB4JH?=
 =?us-ascii?Q?aNLWRTSmcwW2+FuBuokdaPn+1AiU88LjUNymDtOfw8QyFOkVFql1EPnQhCdp?=
 =?us-ascii?Q?+eRgwtqFtwKHclydTeLFqOkWPEB8lghRpFwqXDtEPSrqIc4tXTHSwQsPpDor?=
 =?us-ascii?Q?xAFtfDW8toLsXuZ3Yba/NyJxmChdN6nQLtrGWbbj0+5pXsnJhWW/xXk/KuQN?=
 =?us-ascii?Q?CUXOO+lBmg9KrIhHXk7o/ut4jqAz1IijWV1s8vAcx/D3+XYvmwpdh0++Wv+G?=
 =?us-ascii?Q?ARhUw03G3A0jRuRLR2ptlO6wBpSYeDjIVC+iILkFieVYIPTNEZ9k4B9/yz1O?=
 =?us-ascii?Q?LBnZPZxPjF7biUkmP2CAKhbrBRzUH4+/jNY7?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:21:35.8604
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: db11e12c-15a8-4251-c6e7-08dd9cf77f14
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS1PEPF00017090.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7709

There's nothing Arm specific about this feature. Move it to common as
part of a larger activity to commonalize device tree related features.
For now, select it only for ARM until others (e.g. RISC-V) verify it
works for them too.

Signed-off-by: Michal Orzel 
---
Other candidates: static memory, shared memory
---
 xen/arch/arm/Kconfig                                      | 8 --------
 xen/arch/arm/Makefile                                     | 1 -
 xen/arch/arm/setup.c                                      | 2 +-
 xen/common/Kconfig                                        | 8 ++++++++
 xen/common/device-tree/Makefile                           | 1 +
 xen/{arch/arm => common/device-tree}/static-evtchn.c      | 3 +--
 xen/{arch/arm/include/asm => include/xen}/static-evtchn.h | 6 +++---
 7 files changed, 14 insertions(+), 15 deletions(-)
 rename xen/{arch/arm => common/device-tree}/static-evtchn.c (99%)
 rename xen/{arch/arm/include/asm => include/xen}/static-evtchn.h (77%)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a5aad97a688e..57919d8b3ac8 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -253,14 +253,6 @@ config STATIC_SHM
 	help
 	  This option enables statically shared memory on a dom0less system.
 
-config STATIC_EVTCHN
-	bool "Static event channel support on a dom0less system"
-	depends on DOM0LESS_BOOT
-	default y
-	help
-	  This option enables establishing static event channel communication
-	  between domains on a dom0less system (domU-domU as well as domU-dom0).
-
 config PARTIAL_EMULATION
 	bool "Enable partial emulation of system/coprocessor registers"
 	default y
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 129a109d6ec5..eeeac4e653ec 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -51,7 +51,6 @@ obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
 obj-y += smpboot.o
-obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
 obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
 obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
 obj-y += sysctl.o
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 10b46d068405..734e23da4408 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,7 +40,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 3d66d0939738..0951d4c2f286 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -162,6 +162,14 @@ config STATIC_MEMORY
 
 	  If unsure, say N.
 
+config STATIC_EVTCHN
+	bool "Static event channel support on a dom0less system"
+	depends on DOM0LESS_BOOT && ARM
+	default y
+	help
+	  This option enables establishing static event channel communication
+	  between domains on a dom0less system (domU-domU as well as domU-dom0).
+
 menu "Speculative hardening"
 
 config INDIRECT_THUNK
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 831b91399b74..2df7eb27222e 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
+obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
diff --git a/xen/arch/arm/static-evtchn.c b/xen/common/device-tree/static-evtchn.c
similarity index 99%
rename from xen/arch/arm/static-evtchn.c
rename to xen/common/device-tree/static-evtchn.c
index 49db08d5c6fc..8b82e6b3d8a6 100644
--- a/xen/arch/arm/static-evtchn.c
+++ b/xen/common/device-tree/static-evtchn.c
@@ -1,8 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
 #include 
-
-#include 
+#include 
 
 #define STATIC_EVTCHN_NODE_SIZE_CELLS 2
 
diff --git a/xen/arch/arm/include/asm/static-evtchn.h b/xen/include/xen/static-evtchn.h
similarity index 77%
rename from xen/arch/arm/include/asm/static-evtchn.h
rename to xen/include/xen/static-evtchn.h
index f964522f6a62..31ae92741aad 100644
--- a/xen/arch/arm/include/asm/static-evtchn.h
+++ b/xen/include/xen/static-evtchn.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#ifndef __ASM_STATIC_EVTCHN_H_
-#define __ASM_STATIC_EVTCHN_H_
+#ifndef XEN_STATIC_EVTCHN_H
+#define XEN_STATIC_EVTCHN_H
 
 #ifdef CONFIG_STATIC_EVTCHN
 
@@ -13,7 +13,7 @@ static inline void alloc_static_evtchn(void) {};
 
 #endif /* CONFIG_STATIC_EVTCHN */
 
-#endif /* __ASM_STATIC_EVTCHN_H_ */
+#endif /* XEN_STATIC_EVTCHN_H */
 
 /*
  * Local variables:
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:49:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:49:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997943.1378744 (Exim 4.92)
	(envelope-from )
	id 1uJpzy-0003EU-K0; Tue, 27 May 2025 08:49:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997943.1378744; Tue, 27 May 2025 08: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 1uJpzy-0003EL-Gl; Tue, 27 May 2025 08:49:26 +0000
Received: by outflank-mailman (input) for mailman id 997943;
 Tue, 27 May 2025 08:49:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJpzw-0002ks-UW
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:24 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20609.outbound.protection.outlook.com
 [2a01:111:f403:2412::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78a08d85-3ad7-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:49:18 +0200 (CEST)
Received: from MW4PR04CA0155.namprd04.prod.outlook.com (2603:10b6:303:85::10)
 by SJ1PR12MB6026.namprd12.prod.outlook.com (2603:10b6:a03:48b::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.27; Tue, 27 May
 2025 08:49:15 +0000
Received: from SJ5PEPF000001F6.namprd05.prod.outlook.com
 (2603:10b6:303:85:cafe::55) by MW4PR04CA0155.outlook.office365.com
 (2603:10b6:303:85::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Tue,
 27 May 2025 08:49:14 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F6.mail.protection.outlook.com (10.167.242.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:14 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 78a08d85-3ad7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nY/VuKhGIY2Cjxz6Qe0YYIWYqJzIp+UMHZvjmDpHVNr33Le8UQUHgmZ7FS3KBD9ReAv46PGwH2Vj4HuHbV+YfT4UO2FKVAXy4rG7Acy7Lj5T3/hveOutHuTrmq6UDyTfFZmRuHX9jxMPPAlJS649tnODzn2dCJHZ3cI/s1IBabhNF00NMsTl/XDkIJA1awi+RCXR3UdOD3SQEioivr5ivEqCUBZm7vjrCX45duWWVEVmaRFGeMthPzwcgJfppRbdlI82kXuVKx9EBd9M+nf4b7wKI5utt3lxLPFyD6edkPjWHyRWbMrggF+S0AfqzGQGtTIzmd1+XJINOmBH4fMFUg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GM8OZuCvDFaV06J9Gzt1WwF6Tfxsr646qNHeVMRmifA=;
 b=ehVusa4wf7oNcsLdZM3n3cAHASPCh/eGANM9bFBF0dzVgr/haOpDMhryL18ZfrufyRbFwY/9SGONsxVtiCAU/z2inhw2SKq2aJJ40l15u2CTZdEXVC3Yl5iwkfKDZoElf8G6W8C5qCKXiAQ5rQsQw/AsRqmZYEiqetLH5+YJmSIiBQbvuAOZX7WUDrkBpUeusPycCldIPiJazBEulkcn0MZIEZHSftvzCZSkRapRNDzG5wA3MUI3azKpqovr0AkfUUnkqQxGSKsvlCitMmL978WF0a6VQdswoMpDDvex7Ta2iSPWZI1iES7EfLVxeDdJP+IeE3ezSn9rz4eql+YnWA==
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=GM8OZuCvDFaV06J9Gzt1WwF6Tfxsr646qNHeVMRmifA=;
 b=YCqE/ruBk0VGbR9WnEbaYlFpMKvcmxiCwF5k6lUff0iFff/4g08hUIcVbozc3e3KISrqvzLXDwtOOMvVZ9nMYvpbP3hgzxJYNytWXdfNqqhuUsnXuaWyNzrcsGiUKJ1cO7V29XHSoiGkhU1cWJ/NgDgeoIC8yG6lqbQ5C1bh58E=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	
Subject: [PATCH v5 01/18] xen/pmstat: guard perf.states[] access with XEN_PX_INIT
Date: Tue, 27 May 2025 16:48:16 +0800
Message-ID: <20250527084833.338427-2-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F6:EE_|SJ1PR12MB6026:EE_
X-MS-Office365-Filtering-Correlation-Id: 1cf9b58e-c9eb-4852-bbc0-08dd9cfb5be3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?i7MnWAohelBN//pyrp9s1twi4DqIhkVlXGAWuJLyKzDmNiSbrbnUv4lAiNjJ?=
 =?us-ascii?Q?+C158nMOcy5tu9oa8+/daHIvRiLF/gbqcMZ/ioU+NlS8ebC1xmc1iEQ3Itmg?=
 =?us-ascii?Q?AQhFACE3syFflzS3PIblNng8U9DrnpP7gkT4XD+6x/kIrp7BArhYNA+Phq0L?=
 =?us-ascii?Q?oajVkrIa6PCqzBiV1u1mZ3H6Ts+SjRO0JrYyUqvOA5EJ5cw9tAcjTtJvGItv?=
 =?us-ascii?Q?KtDqsxfLGu8aAMjBBIdpNiI/LjoZUfmfg45yUg5pVjFd/Hmn6s1u11TvQSjU?=
 =?us-ascii?Q?FswAK8XWEaXNF38Ev3el8P9TyiZfz9Jat8KLv0bIbZ3x80K3GQw23hrt7VeA?=
 =?us-ascii?Q?1mFkQ/jxC9xX0bAHRgHwjsY3V9yr9US9dV6imh+xjQokZ+PtodpEGAzYW1Ks?=
 =?us-ascii?Q?Lc9M0WRX03GA5Rb/rUrEluw7lRlx0tmdmWmEwjxGg3u9f08F5rNzaQwb7ysT?=
 =?us-ascii?Q?N6VDMgdqmzY1B2axky1aVUeDGk9iavgcNgqE2JXkktkJ+mjVgCklAabZtg+V?=
 =?us-ascii?Q?ELSDN8jWK7cHykAYYnzV5by/7YaAnKFO0pZnxRBHPQEXgkxAvrYN0708nEmv?=
 =?us-ascii?Q?biQ5jxk11+TeR9PYNMkSAX/LCDYR9EeiNk0rvUhknDDBkpn2VukZkzh4YoWL?=
 =?us-ascii?Q?OMxjFDlLB9RqdeMGh79dMXYKzGW3+mfr9daQeJzqWQnD+u1wk8m7Jbs2+c2i?=
 =?us-ascii?Q?kJ8cjXCTwnfGVCwSr7LAxSOOKJkJ5v29D3oqW2DP5OkJZbdJo93nJTyA2Gx7?=
 =?us-ascii?Q?SA7Z+dRlQxK+v8fqrcKBuym1IceL2Kj4bapIwoGWLspfMPjmlSZ2Sht38puq?=
 =?us-ascii?Q?dsQPIAT7DLDKWlOvZ+stFUsO9n2V3WduZyASbHYFKfyhelUkIBoCJaHMPd1T?=
 =?us-ascii?Q?ZHisVQKw1BXhChAW9J3KIPM1HP0nDMGh9xC3+KpqXlgniOPFdlCbZrDWOHJs?=
 =?us-ascii?Q?AFmuUozhtDPVyciOwez9jH0m3kBifbrA7/P/PrNLdIreCBxxV6cp/60gN0Yr?=
 =?us-ascii?Q?r1HoLooJzqgAT/Mj2974IJWrFHU1s+RLtmAYoI0kFMvi9nTD5GkimyWD9ZZr?=
 =?us-ascii?Q?PsNMazTzCbdy4gGYJmH1Mrqe9DYgMtorG4mwJD8PBxIJ1bt8AhVHFk/B1aUS?=
 =?us-ascii?Q?HjDO0uLbSqDYd/PeFZamE4B5OvggqNfyOcijWzOvptq9zTiGFd8Z6q+KEQDe?=
 =?us-ascii?Q?ho+RlxY6wdfVNPYc+PTCCi3i2BzT3qR6SmnmJjiESoDERuPXYgtkjwmGPxuZ?=
 =?us-ascii?Q?Ykm9CXaYNmpXnzQouURMJAIftRhz2JPLnVZHIitNtr+Hn/xFA+LsVxTuPORH?=
 =?us-ascii?Q?j7nqfdjX9azvVp3GQMFP8/xk9T1gU7WaunoaSqVGCTlKvsiB1Bmx9N/12qtJ?=
 =?us-ascii?Q?7mFqSTDcf4rr/S6s8HYgWOd24Fbt48aWZeYFxdaVXN8Eh9LhIyCh/nM4Hqcm?=
 =?us-ascii?Q?SWoFE4/nFxQtluZ0G7b74mXuoAUePdVyPhYSCCweVXCG5Rv3T+1S8VPvddC3?=
 =?us-ascii?Q?nDkCY4N1Im9pF1J1Nj5q1ek9DByjLhoAE1PY?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:14.7514
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1cf9b58e-c9eb-4852-bbc0-08dd9cfb5be3
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6026

Accessing to perf.states[] array shall not be only guarded with user-defined
hypercall input, so we add XEN_PX_INIT check to gain safety.

Signed-off-by: Penny Zheng 
---
v4 -> v5:
- new commit
---
 xen/drivers/acpi/pmstat.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index c51b9ca358..b7fcc02db9 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -228,10 +228,13 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
     ret = copy_to_guest(op->u.get_para.affected_cpus,
                         data, op->u.get_para.cpu_num);
 
-    for ( i = 0; i < op->u.get_para.freq_num; i++ )
-        data[i] = pmpt->perf.states[i].core_frequency * 1000;
-    ret += copy_to_guest(op->u.get_para.scaling_available_frequencies,
-                         data, op->u.get_para.freq_num);
+    if ( pmpt->perf.init & XEN_PX_INIT )
+    {
+        for ( i = 0; i < op->u.get_para.freq_num; i++ )
+            data[i] = pmpt->perf.states[i].core_frequency * 1000;
+        ret += copy_to_guest(op->u.get_para.scaling_available_frequencies,
+                             data, op->u.get_para.freq_num);
+    }
 
     xfree(data);
     if ( ret )
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:49:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:49:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997946.1378774 (Exim 4.92)
	(envelope-from )
	id 1uJq01-0003x7-Ny; Tue, 27 May 2025 08:49:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997946.1378774; Tue, 27 May 2025 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 1uJq01-0003wv-Jp; Tue, 27 May 2025 08:49:29 +0000
Received: by outflank-mailman (input) for mailman id 997946;
 Tue, 27 May 2025 08:49:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJpzz-0002ks-Fb
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:27 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20630.outbound.protection.outlook.com
 [2a01:111:f403:2417::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7b5d7f03-3ad7-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:49:22 +0200 (CEST)
Received: from MW4PR04CA0163.namprd04.prod.outlook.com (2603:10b6:303:85::18)
 by CY8PR12MB7611.namprd12.prod.outlook.com (2603:10b6:930:9b::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Tue, 27 May
 2025 08:49:20 +0000
Received: from SJ5PEPF000001F6.namprd05.prod.outlook.com
 (2603:10b6:303:85:cafe::a1) by MW4PR04CA0163.outlook.office365.com
 (2603:10b6:303:85::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Tue,
 27 May 2025 08:49:18 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F6.mail.protection.outlook.com (10.167.242.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:18 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49:17 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7b5d7f03-3ad7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yIeZ2eQo10zwcE1r+5ujiBRNlSsmDquBZcKsyQ7mhD+q7b+HZsGJcY+vkQiT6cbXTw/XdSAK8uUHTJWsZ943VY9rZ/JGpWAI1Xd4d8YnKy79ijWg6RnZHGZt08pOX/uQx69HEt8GdQjD3kqgnFaSJBYw5FJAJYMKsKaCHDw6P+fdOy/YfSnUPvXsrQMgWoliO8PR2ZgbQUrWF6lr9y6Qs7XyOI1txW/7rwvjJKfd8pU1Mw0OeV1/Gzq0VqtErLM4Z9u9Ds5YJ5IFkDnUmQKGGyQeniogX0kReTcu1EEyAPHlXWJMPddlWq7F2MVTNirtPRvON5zRcWXMYypF41eClA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7Jy/8v14iiBy4RKFkuZ6/LcMiLpi/ycMhiWhZ/kpWtk=;
 b=f7SeKjaxeaZ4Hm5x0xcKMDOIrjT6vJ6BBpMU8eM94swkYeM+sAp+NfQu3p/3ZV9btyJKaXT1s9gPUBPMjxAcsyvB8KV4TrSwQ77Z5rgqWfgkA4OYQRH5JUen9gk7Jmya5J+pHQ6b8YHHtMagXq+gpyHb4ddZO7A9Thw89QVyrjyZCMhfp+PZfUduTY/8bLMMh7QvvPO6+bZv8ANNMxm4TCJMHel8bq2k46uUmZYbxISL9tyRrAPwMPsxGK7685TSmz29R8JG1AkiUiUAIA8YOZvfFKWEr+W2Ck0NsW5ixX6Fjw0Ph4rmaGfqJewB3PrVtRAHuBDeC6CNDGlB7BbA0w==
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=7Jy/8v14iiBy4RKFkuZ6/LcMiLpi/ycMhiWhZ/kpWtk=;
 b=sMeEUm+9pMjaQA4UzpqSyyz7spoaY1e8ymZ7ATkV5vbkXaMEGEfhFyrTQVa6xK4LJCm5BwGoNmlAr5XaQqRzfgBdy8Op7GiCIZkuLDzxPxNhTuKs7zbDpiZS+KXybs/kofpXQRNymkhmnq1Bp9alF+3RUuOxHZMIaxoDHOGhmy0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	
Subject: [PATCH v5 05/18] xen/cpufreq: refactor cmdline "cpufreq=xxx"
Date: Tue, 27 May 2025 16:48:20 +0800
Message-ID: <20250527084833.338427-6-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F6:EE_|CY8PR12MB7611:EE_
X-MS-Office365-Filtering-Correlation-Id: 87963892-470d-472a-bfdf-08dd9cfb5e49
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?OqJJzblkk6wbTBFBY4VTGPtyIJsK8ia7ADdNaueXzcLIQ0JHxVTZnCMfQdFs?=
 =?us-ascii?Q?w24/b3+G1kg4NbaKVqcqcjgkZybJafnz+J0zSfhg2Rku+GLqkvwqCcjkTS7m?=
 =?us-ascii?Q?MG1xja7Srw7LLgcB8jcEEsosEx157YqWw0vkBwz7AczEFn6ibOWZu+l4jp3I?=
 =?us-ascii?Q?kz0THwUUmcGOw/Tee7O3yeoy4A7IkWFDn1xsnDDr+LbTD1yl5EuveiPXI9m+?=
 =?us-ascii?Q?cp00//bIoWm0sBbS5MB+WRMLTmf8Mw9mg9Wg52ZjIDvt2mn9oT++K3t55glJ?=
 =?us-ascii?Q?XBSyo9KWZV/bsJjXuoayNh1wlLXZ0vdjsyc0hNAUVrQUlAwucDTZqDXkB81k?=
 =?us-ascii?Q?KDVYE+xwBMNARUBuCQa9SJbVS2mTygg5dXjvPRBLXnVsZGFEMcfIguw10LF5?=
 =?us-ascii?Q?VbU9M4Tj5LWtczcX2k2q52Kbtj9sLMjx+3icdRfb1i1TXmbQosE2GuvckIgB?=
 =?us-ascii?Q?ozcSTGPX1s+dvkOAdJ/dcVGEZfyJ83qHXkiaWXIKJjW9GkiznYdHjZpDqKYf?=
 =?us-ascii?Q?rTnR54QV18cmn0aYmGsjJebtqQdCRxIA3LvEP586jcZJdSr8CI3yAIwrn980?=
 =?us-ascii?Q?lBhP2RnyGjbXR7x+POaa1yVVuvVuiFlq1pQL7pbXt1cKSUGn55lxgWni2Vel?=
 =?us-ascii?Q?1/MDWdrz2yC2uWmmIVJNMzSwA2SYS1MZ9p6yzOw41YXMSiEE4+VkiA3WPg/r?=
 =?us-ascii?Q?jcuoKkRXkvSPI9lPEF36Zsqbm2vufeCmy7nq7uiAhL8h5mEwigBv8s/YAbbp?=
 =?us-ascii?Q?wlsxTWtKE7Cl5TH9G3qsb9CErqy+ZSWf9p2av8wQBC2Vy43EJ03Gi6N6AsoY?=
 =?us-ascii?Q?QWoNeFpbf6X3LFv6ZVbELGS8ggv9RH2I50MdOVROKm7VPMzDXb5ghtx5f2Dq?=
 =?us-ascii?Q?1BP2pPPsADcNy9f6calrZPOfCn54+iMOlBpD6gFbZ2ZcBMNaYTDZoUxB1QRQ?=
 =?us-ascii?Q?+US0qoXAT0YurgJH6KsVMIMhSm+uywtKrgCxdClo8rMdTiR/BmV/M1vKT9nr?=
 =?us-ascii?Q?Nl/JRT5AXn2iA4SSNZDrvtzqbDICDduvIPGLDYFMtgiLhLeyuKkIyTR3hNOC?=
 =?us-ascii?Q?oP3DK5/tv/T5pXFy9WMnhfqjw1GN/fyRO72EFVsvc2uqggQ0MTHyWY9W8JtZ?=
 =?us-ascii?Q?fg3SahfiRWfmKMw2lwGxHkalxi+m/HfcEBSzzeWCOdgV4eIfZqfC+QPn/C4Y?=
 =?us-ascii?Q?8cXl47kC11ec6jLaqqN4UTm/0tAhi4fqJnwXBze/xdIA139usWvWnZvzyuQk?=
 =?us-ascii?Q?jXL3AEYd0izKgGGls5/eD0c13YY/QdqxiKH5M8HWnQdRwsDcuQJX/IuqajsE?=
 =?us-ascii?Q?ix+eSTQMYtEOHDGumKUvTyYGUrFRychsCv2s7go9cDgqzFdgtqX2Usu49myF?=
 =?us-ascii?Q?aRvuF6sFXVGx93NeT0ffq+304Pt1rmJzoBbKjx9wYEFtw/ErPO3fZ8Ifqf5C?=
 =?us-ascii?Q?kUV52GieTjyYBCPefafWVYbpUnbkYLD9V+V2cxoVbwQMvBdLXKGKAX1sVLOr?=
 =?us-ascii?Q?i3FE4lenjpfrtNU19UABRXyt01jS3iA7+YOP?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:18.7827
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 87963892-470d-472a-bfdf-08dd9cfb5e49
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7611

A helper function handle_cpufreq_cmdline() is introduced to tidy different
handling pathes.
We also add a new helper cpufreq_opts_contain() to ignore and warn user
redundant setting, like "cpufreq=hwp;hwp;xen"

Signed-off-by: Penny Zheng 
---
v2 -> v3:
- new commit
---
v3 -> v4:
- add one single helper to do the tidy work
- ignore and warn user redundant setting
---
v4 -> v5:
- make "cpufreq_opts_str" static and the string literals end up in
  .init.rodata.
- use "CPUFREQ_xxx" as array slot index
- blank line between non-fall-through case blocks
---
 xen/drivers/cpufreq/cpufreq.c | 57 ++++++++++++++++++++++++++++++-----
 1 file changed, 49 insertions(+), 8 deletions(-)

diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index d6b6c844d8..d1b51c8dd0 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -69,8 +69,55 @@ enum cpufreq_xen_opt __initdata cpufreq_xen_opts[2] = { CPUFREQ_xen,
                                                         CPUFREQ_none };
 unsigned int __initdata cpufreq_xen_cnt = 1;
 
+static const char __initconst cpufreq_opts_str[][5] = {
+    [CPUFREQ_none] = "none",
+    [CPUFREQ_xen] = "xen",
+    [CPUFREQ_hwp] = "hwp",
+};
+
 static int __init cpufreq_cmdline_parse(const char *s, const char *e);
 
+static bool __init cpufreq_opts_contain(enum cpufreq_xen_opt option)
+{
+    unsigned int count = cpufreq_xen_cnt;
+
+    while ( count )
+    {
+        if ( cpufreq_xen_opts[--count] == option )
+            return true;
+    }
+
+    return false;
+}
+
+static int __init handle_cpufreq_cmdline(enum cpufreq_xen_opt option)
+{
+    int ret = 0;
+
+    if ( cpufreq_opts_contain(option) )
+    {
+        printk(XENLOG_WARNING "Duplicate cpufreq driver option: %s\n",
+               cpufreq_opts_str[option]);
+        return 0;
+    }
+
+    cpufreq_controller = FREQCTL_xen;
+    cpufreq_xen_opts[cpufreq_xen_cnt++] = option;
+    switch ( option )
+    {
+    case CPUFREQ_hwp:
+    case CPUFREQ_xen:
+        xen_processor_pmbits |= XEN_PROCESSOR_PM_PX;
+        break;
+
+    default:
+        ret = -EINVAL;
+        break;
+    }
+
+    return ret;
+}
+
 static int __init cf_check setup_cpufreq_option(const char *str)
 {
     const char *arg = strpbrk(str, ",:;");
@@ -114,20 +161,14 @@ static int __init cf_check setup_cpufreq_option(const char *str)
 
         if ( choice > 0 || !cmdline_strcmp(str, "xen") )
         {
-            xen_processor_pmbits |= XEN_PROCESSOR_PM_PX;
-            cpufreq_controller = FREQCTL_xen;
-            cpufreq_xen_opts[cpufreq_xen_cnt++] = CPUFREQ_xen;
-            ret = 0;
+            ret = handle_cpufreq_cmdline(CPUFREQ_xen);
             if ( arg[0] && arg[1] )
                 ret = cpufreq_cmdline_parse(arg + 1, end);
         }
         else if ( IS_ENABLED(CONFIG_INTEL) && choice < 0 &&
                   !cmdline_strcmp(str, "hwp") )
         {
-            xen_processor_pmbits |= XEN_PROCESSOR_PM_PX;
-            cpufreq_controller = FREQCTL_xen;
-            cpufreq_xen_opts[cpufreq_xen_cnt++] = CPUFREQ_hwp;
-            ret = 0;
+            ret = handle_cpufreq_cmdline(CPUFREQ_hwp);
             if ( arg[0] && arg[1] )
                 ret = hwp_cmdline_parse(arg + 1, end);
         }
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:49:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:49:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997944.1378751 (Exim 4.92)
	(envelope-from )
	id 1uJpzz-0003I0-0S; Tue, 27 May 2025 08:49:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997944.1378751; Tue, 27 May 2025 08: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 1uJpzy-0003HT-Pl; Tue, 27 May 2025 08:49:26 +0000
Received: by outflank-mailman (input) for mailman id 997944;
 Tue, 27 May 2025 08:49:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJpzx-00031E-M4
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:25 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20621.outbound.protection.outlook.com
 [2a01:111:f403:2418::621])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7c02f8df-3ad7-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 10:49:23 +0200 (CEST)
Received: from MW4PR04CA0177.namprd04.prod.outlook.com (2603:10b6:303:85::32)
 by PH0PR12MB7907.namprd12.prod.outlook.com (2603:10b6:510:28d::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.22; Tue, 27 May
 2025 08:49:16 +0000
Received: from SJ5PEPF000001F6.namprd05.prod.outlook.com
 (2603:10b6:303:85:cafe::d9) by MW4PR04CA0177.outlook.office365.com
 (2603:10b6:303:85::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Tue,
 27 May 2025 08:49:15 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F6.mail.protection.outlook.com (10.167.242.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:15 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 7c02f8df-3ad7-11f0-a2fd-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wCG2C4Bp7gqVUeII16p7l9MRN65Vyg95KVcVdTfuIC46Grbh/Ols386RnS71jm4hKiqQlqzLVdxkxyrgm33bpLB4NqWPHAJ+ABKQPLQuxzjLZLC1eRuo9tQeBhUIIxDNnBXPOKGx9UxGgwnHk2u2hnNTnErW2XH/PKVdQSkFwprDa39Dp1aPbCMXIimVXMG6PZNZqtAydP0oKxKdrVdxKVsnbyhpoXuultnzDFsOgLekq5Y1RQsULq5nzIcdZin3esWnuQ7DiPG/11M062L652qqQqOyLw5obz5+dm28d/JYfUn+j/9Vjdv10ctT5VtpTT0vnZuYT908+LxlmFtb4A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=d4m9MyBy1xfClJaMl4Tf2AJuBzOa30FJWa7hBBPvoTo=;
 b=u0QyNsvVTBbQwVnquXp2D0i9fljA/+7NMpZhx9HH8phlnHbVeqKTQhd2p1RX8w/ltXJdoKY/+ABQVvuVXrAqHIQYwrfm1ZllIdkQ7NbtkxN3WwGyUmf45opBfe2fGdm1Lb9spcz9NxksN9bYpBLjnAcYu3aMYwtVwCU6ww/BsrkX23eQmwfk3sbHFd+xUf6fnOg+ehSf1VWqLD0r5Fd5MHLvFRaPfNOVvdPMmABpuJtscNZ8iZzDGjf+YBmF48neyXL19tnv2BlIwcbGVT9hJ6IjVDEOtpyaPWkXnI0TxNAIkOQ3Vq+st7S2BLjTFHZfK3j2IfyT8ndWYloPgDXWJA==
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=d4m9MyBy1xfClJaMl4Tf2AJuBzOa30FJWa7hBBPvoTo=;
 b=tOY2/r9mbe22cU5cUDWjaEOV4slyYU00KBqJChQXuzDuFr9pBz1R5S16+FAbknnMV99s3TOTb6L7xIOxCsadcicB8k2hOy79fXJkBJv1h8PX1yXhRlUpY+V0Kx4tAKtU/cWA0Y3xaIKkzjatZk4/zWBnihjd+egjqeqTLEKGf7Q=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	
Subject: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from "struct xen_processor_performance"
Date: Tue, 27 May 2025 16:48:18 +0800
Message-ID: <20250527084833.338427-4-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F6:EE_|PH0PR12MB7907:EE_
X-MS-Office365-Filtering-Correlation-Id: 5f459e77-b13c-45de-f145-08dd9cfb5c67
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?m2p9VgpfY6RUQzZGqRdRJKY2TfFV55f5LcdIP7Zhm8TFhjfGLoeSNRngv9NN?=
 =?us-ascii?Q?u9FBwiqnufte5I98HK+lEnLPZ8VTKTJE+JcpxHOKAFCb4oW8pibLIVuomtMa?=
 =?us-ascii?Q?nrzVeJZ9wOVEXX4YNbMWt2vTndsSe/L46GJsHUZtd+HBPhiTUrShToBz8ssf?=
 =?us-ascii?Q?NXofj6WhJTucIpYW2iOjupv7iHkGXfCuwHDf2yY1aCC7S2o1mGOStpeoDYYM?=
 =?us-ascii?Q?HKBkJiKcAV99P1wdj9EXhMr2smIn1UWqnNiF0F2ps7TPE3B7rfps1Hq5O68u?=
 =?us-ascii?Q?ppjVRURvqUhQqmjFGp4QJnq/vxE+GQgvBLOxrkS3+Yt8PUKSvAEAvsEBf6BH?=
 =?us-ascii?Q?Ndq20gS9NSQbmPDUYe8vkgQhWE1YYARiZWi5+EAN085EhQ5EISivAIYUjjDK?=
 =?us-ascii?Q?399D6fCuwzOOTsIHH3ATsgzFDaWbtAOf37UwFP02VHH1pUpcSk6kQgeyhOxC?=
 =?us-ascii?Q?PSfHgJGLxfWrsUo2uwCwjEBrBYLvwGqbigD/GulExveF9cIut2PKmYr91PIW?=
 =?us-ascii?Q?vMU3EjotFt/OQv8ow5da0N+OJUsdPYa0Heg9RXM+R9eAzJcA47bjo3A3h3hh?=
 =?us-ascii?Q?oOs+Vtq+oYXqwmWMxRX66S4e9+HSHcOvTSYbYBnnuoA0aFTyuzUM1tsi1wG0?=
 =?us-ascii?Q?uvxHQIcibTStHHpGinUTbd9lsa6IaETrBLz2CF4ww8gW1Uzy3PyvvY1cSk4b?=
 =?us-ascii?Q?QIRDryl/HnNwoxQxHyaIdlZd8XRemMikJb4Fxlss42s7m4R4kPrZCJ1oYm59?=
 =?us-ascii?Q?zRwEbRm0lfEniV7ofT6T8m+5IVhwEeC0Butu1bY1CEwu8IooDl3QIbCxPsJm?=
 =?us-ascii?Q?FBpQymnzn2ar/uBu13X3wszxg9uC+FdkoJFEyI8Mtzrmg1QMzxJXqg06/jJN?=
 =?us-ascii?Q?VJIAKMvgLVbyYQ1XlAX11RPmp9MeElXWGL0T1izWdCCo9gZEwcAQMyn2VRy4?=
 =?us-ascii?Q?Gk3CvI52XORqaohMSkcWwZagz3ysuNRuIMjM1MVXK7pfTW84p5QP/EJLzP+F?=
 =?us-ascii?Q?b0GP75uvmRhO6JvxX7IzMEohZgaq3wFIZIRFr75u6UQH/CQJiOvs981CTNHx?=
 =?us-ascii?Q?hBJJ30Iy/5CfSVtfyHlFsWHJaA0Dqd+1Tx56QPFna3oL4ElwLYjTx4ToQL9+?=
 =?us-ascii?Q?JHNRz1QhyLvBVILL2uq5UT6hP0GKmOkYhOFzlNvnJAkxh9xT1nyTkN1A0s3x?=
 =?us-ascii?Q?+cOU6oa6w23pNdI6J+3ZzVa3XmlELX6w1yvFweCxH7+PRlnRosKCoNqR4RAt?=
 =?us-ascii?Q?QANYpEJjsw+C4gvqnn2BbZjdZaVNyPIT1UDWvhDJwVHMhQeu3IHSeMih8fod?=
 =?us-ascii?Q?maROHB5BXVUlTtt04AhoCkPiMvsro9XjFzKBuEbXDvKQJyqGBTQEWt1QkJnB?=
 =?us-ascii?Q?qkuZLSOjM6VkpvqvxE2n2CAYvvDXpDhHkHc47xQZLyuB7t1aAsx8oYaeYTl1?=
 =?us-ascii?Q?nsTIL3Y6WX122OxQVIVj+/Q/KHSo6sTCWrXAe+rBzCS1c1swIFuSDzvXQZ5H?=
 =?us-ascii?Q?B85Y1p1nK4rgjY7Allq4IrOp6KEr+rIEtAKQ?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:15.6264
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5f459e77-b13c-45de-f145-08dd9cfb5c67
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7907

_PSD info, consisted of "shared_type" and "struct xen_psd_package", will not
only be provided from px-specific "struct xen_processor_performance", but also
in CPPC data.

In cpufreq_add/del_cpu(), a new helper get_psd_info() is introduced to
extract common _PSD info from px-specific "struct xen_processor_performance",
in the meantime, the following style corrections get applied at the same time:
- add extra space before and after bracket of if()
- remove redundant parenthesis
- no need to put brace for printk() at a seperate line

Signed-off-by: Penny Zheng 
---
v3 -> v4:
- new commit
---
v4 -> v5:
- let check_psd_pminfo() pass in "uint32_t shared_type"
- replace unnessary parameter "uint32_t init" with processor_pminfo[cpu]->init
- replace structure copy with const pointer delivery through
  "const struct xen_psd_package **"
- blank line between non-fall-through switch-case blocks
- remove unnessary "define XEN_CPUPERF_SHARED_TYPE_xxx" movement
---
 xen/drivers/cpufreq/cpufreq.c | 111 ++++++++++++++++++++++++----------
 1 file changed, 79 insertions(+), 32 deletions(-)

diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index 08d027317c..9567221d97 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -191,9 +191,29 @@ int cpufreq_limit_change(unsigned int cpu)
     return __cpufreq_set_policy(data, &policy);
 }
 
-int cpufreq_add_cpu(unsigned int cpu)
+static int get_psd_info(unsigned int cpu, uint32_t *shared_type,
+                        const struct xen_psd_package **domain_info_ptr)
 {
     int ret = 0;
+
+    switch ( processor_pminfo[cpu]->init )
+    {
+    case XEN_PX_INIT:
+        *shared_type = processor_pminfo[cpu]->perf.shared_type;
+        *domain_info_ptr = &processor_pminfo[cpu]->perf.domain_info;
+        break;
+
+    default:
+        ret = -EINVAL;
+        break;
+    }
+
+    return ret;
+}
+
+int cpufreq_add_cpu(unsigned int cpu)
+{
+    int ret;
     unsigned int firstcpu;
     unsigned int dom, domexist = 0;
     unsigned int hw_all = 0;
@@ -201,14 +221,14 @@ int cpufreq_add_cpu(unsigned int cpu)
     struct cpufreq_dom *cpufreq_dom = NULL;
     struct cpufreq_policy new_policy;
     struct cpufreq_policy *policy;
-    struct processor_performance *perf;
+    const struct xen_psd_package *domain_info;
+    const struct xen_psd_package **domain_info_ptr = &domain_info;
+    uint32_t shared_type;
 
     /* to protect the case when Px was not controlled by xen */
     if ( !processor_pminfo[cpu] || !cpu_online(cpu) )
         return -EINVAL;
 
-    perf = &processor_pminfo[cpu]->perf;
-
     if ( !(processor_pminfo[cpu]->init & XEN_PX_INIT) )
         return -EINVAL;
 
@@ -218,10 +238,15 @@ int cpufreq_add_cpu(unsigned int cpu)
     if (per_cpu(cpufreq_cpu_policy, cpu))
         return 0;
 
-    if (perf->shared_type == CPUFREQ_SHARED_TYPE_HW)
+    ret = get_psd_info(cpu, &shared_type, domain_info_ptr);
+    if ( ret )
+        return ret;
+    domain_info = *domain_info_ptr;
+
+    if ( shared_type == CPUFREQ_SHARED_TYPE_HW )
         hw_all = 1;
 
-    dom = perf->domain_info.domain;
+    dom = domain_info->domain;
 
     list_for_each(pos, &cpufreq_dom_list_head) {
         cpufreq_dom = list_entry(pos, struct cpufreq_dom, node);
@@ -244,21 +269,30 @@ int cpufreq_add_cpu(unsigned int cpu)
         cpufreq_dom->dom = dom;
         list_add(&cpufreq_dom->node, &cpufreq_dom_list_head);
     } else {
+        uint32_t firstcpu_shared_type;
+        const struct xen_psd_package *firstcpu_domain_info;
+        const struct xen_psd_package **firstcpu_domain_info_ptr =
+                                                        &firstcpu_domain_info;
+
         /* domain sanity check under whatever coordination type */
         firstcpu = cpumask_first(cpufreq_dom->map);
-        if ((perf->domain_info.coord_type !=
-            processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
-            (perf->domain_info.num_processors !=
-            processor_pminfo[firstcpu]->perf.domain_info.num_processors)) {
-
+        ret = get_psd_info(firstcpu, &firstcpu_shared_type,
+                           firstcpu_domain_info_ptr);
+        if ( ret )
+            return ret;
+        firstcpu_domain_info = *firstcpu_domain_info_ptr;
+
+        if ( domain_info->coord_type != firstcpu_domain_info->coord_type ||
+             domain_info->num_processors !=
+             firstcpu_domain_info->num_processors )
+        {
             printk(KERN_WARNING "cpufreq fail to add CPU%d:"
                    "incorrect _PSD(%"PRIu64":%"PRIu64"), "
                    "expect(%"PRIu64"/%"PRIu64")\n",
-                   cpu, perf->domain_info.coord_type,
-                   perf->domain_info.num_processors,
-                   processor_pminfo[firstcpu]->perf.domain_info.coord_type,
-                   processor_pminfo[firstcpu]->perf.domain_info.num_processors
-                );
+                   cpu, domain_info->coord_type,
+                   domain_info->num_processors,
+                   firstcpu_domain_info->coord_type,
+                   firstcpu_domain_info->num_processors);
             return -EINVAL;
         }
     }
@@ -304,8 +338,9 @@ int cpufreq_add_cpu(unsigned int cpu)
     if (ret)
         goto err1;
 
-    if (hw_all || (cpumask_weight(cpufreq_dom->map) ==
-                   perf->domain_info.num_processors)) {
+    if ( hw_all || cpumask_weight(cpufreq_dom->map) ==
+                   domain_info->num_processors )
+    {
         memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
 
         /*
@@ -360,29 +395,35 @@ err0:
 
 int cpufreq_del_cpu(unsigned int cpu)
 {
+    int ret;
     unsigned int dom, domexist = 0;
     unsigned int hw_all = 0;
     struct list_head *pos;
     struct cpufreq_dom *cpufreq_dom = NULL;
     struct cpufreq_policy *policy;
-    struct processor_performance *perf;
+    uint32_t shared_type;
+    const struct xen_psd_package *domain_info;
+    const struct xen_psd_package **domain_info_ptr = &domain_info;
 
     /* to protect the case when Px was not controlled by xen */
     if ( !processor_pminfo[cpu] || !cpu_online(cpu) )
         return -EINVAL;
 
-    perf = &processor_pminfo[cpu]->perf;
-
     if ( !(processor_pminfo[cpu]->init & XEN_PX_INIT) )
         return -EINVAL;
 
     if (!per_cpu(cpufreq_cpu_policy, cpu))
         return 0;
 
-    if (perf->shared_type == CPUFREQ_SHARED_TYPE_HW)
+    ret = get_psd_info(cpu, &shared_type, domain_info_ptr);
+    if ( ret )
+        return ret;
+    domain_info = *domain_info_ptr;
+
+    if ( shared_type == CPUFREQ_SHARED_TYPE_HW )
         hw_all = 1;
 
-    dom = perf->domain_info.domain;
+    dom = domain_info->domain;
     policy = per_cpu(cpufreq_cpu_policy, cpu);
 
     list_for_each(pos, &cpufreq_dom_list_head) {
@@ -398,8 +439,8 @@ int cpufreq_del_cpu(unsigned int cpu)
 
     /* for HW_ALL, stop gov for each core of the _PSD domain */
     /* for SW_ALL & SW_ANY, stop gov for the 1st core of the _PSD domain */
-    if (hw_all || (cpumask_weight(cpufreq_dom->map) ==
-                   perf->domain_info.num_processors))
+    if ( hw_all || cpumask_weight(cpufreq_dom->map) ==
+                   domain_info->num_processors )
         __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
 
     cpufreq_statistic_exit(cpu);
@@ -464,6 +505,17 @@ static void print_PPC(unsigned int platform_limit)
     printk("\t_PPC: %d\n", platform_limit);
 }
 
+static int check_psd_pminfo(uint32_t shared_type)
+{
+    /* check domain coordination */
+    if ( shared_type != CPUFREQ_SHARED_TYPE_ALL &&
+         shared_type != CPUFREQ_SHARED_TYPE_ANY &&
+         shared_type != CPUFREQ_SHARED_TYPE_HW )
+        return -EINVAL;
+
+    return 0;
+}
+
 int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf)
 {
     int ret = 0, cpu;
@@ -545,14 +597,9 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf)
 
     if ( perf->flags & XEN_PX_PSD )
     {
-        /* check domain coordination */
-        if ( perf->shared_type != CPUFREQ_SHARED_TYPE_ALL &&
-             perf->shared_type != CPUFREQ_SHARED_TYPE_ANY &&
-             perf->shared_type != CPUFREQ_SHARED_TYPE_HW )
-        {
-            ret = -EINVAL;
+        ret = check_psd_pminfo(perf->shared_type);
+        if ( ret )
             goto out;
-        }
 
         pxpt->shared_type = perf->shared_type;
         memcpy(&pxpt->domain_info, &perf->domain_info,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:49:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:49:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997942.1378734 (Exim 4.92)
	(envelope-from )
	id 1uJpzx-00030I-9t; Tue, 27 May 2025 08:49:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997942.1378734; Tue, 27 May 2025 08:49: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 1uJpzx-00030B-7G; Tue, 27 May 2025 08:49:25 +0000
Received: by outflank-mailman (input) for mailman id 997942;
 Tue, 27 May 2025 08:49:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJpzv-0002ks-US
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:23 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2413::61b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 776ab30a-3ad7-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:49:14 +0200 (CEST)
Received: from MW4PR04CA0159.namprd04.prod.outlook.com (2603:10b6:303:85::14)
 by DM6PR12MB4073.namprd12.prod.outlook.com (2603:10b6:5:217::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.25; Tue, 27 May
 2025 08:49:14 +0000
Received: from SJ5PEPF000001F6.namprd05.prod.outlook.com
 (2603:10b6:303:85:cafe::2c) by MW4PR04CA0159.outlook.office365.com
 (2603:10b6:303:85::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Tue,
 27 May 2025 08:49:13 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F6.mail.protection.outlook.com (10.167.242.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:12 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 776ab30a-3ad7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=k9LxXrz4Ck6RanNgT2/Dv41yYywfygHIo9mFVp31FFpRIJgj4f2Kf41FI2Zjm2NCJZdBhpFb0XJTr/IFJFZozcAk4DqmAYx/wEV9+sJsqUD++7sF2H0+QgyKsCmwUeLEQrnAer1+4FZoEifJ6Z+Nwpo5lOpLcdfw1ibuYCzGIn4eL/rxATAcNgPSqY9A+XA2lEKjiJQxJB4BJP9ioQCbSyN/t1eQ1dstAxf5fMf47kVLyY7f4V72LfrnGrUrKGRwYlk43eguQ2y+avu63xKPdR/BUt3b5aq2uos09QHgrp8WD3T0chdsahmDpjfIn07bEQy+uB3PSsx+NkxHlO7TFQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uz/bPWf90rgKVsHMue4aMMms4AT0/+u95OXPEnMq1ew=;
 b=TQJjlacmSn5f7zRskxrlLkQlqtZXYLgdx7GClSrDaXHEIHJurUumjpGnjWjGhDxFmtrqGZhOADGuF1m3nRaGdwGF/XbneRMiz+d3S5Pc4BZ4AdmbQETR+IAPVx36qnMkXv55rwNpHfXBsBI2KgT1KnCVZu4ESdkZYKkyLydvKjKCnR9VLsCZHzqJb8BL9am/U04RLKiras/KF2BDtmmJz34Q9XLNoPO69Zb21u4bDfXGUpXkApgtwpMEqw1hhCBPJBXlMqceUgrjM4H4nlqkkC9ILuuaWmsvVSfzEJmbj0fLvAdQ5NOeelFOaOUg6ufj0K7n++eCfQ/hxRtJlTahJA==
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=uz/bPWf90rgKVsHMue4aMMms4AT0/+u95OXPEnMq1ew=;
 b=MWh2TGMrb2CCDl4SSYkENK0MlGoJbIGk2XVQSWqw4PotJ9NgU6YXm0oceW4AwZB/a1NDwDvzntvwJVzUoyWzKcAqgbLoxgjTwH+JH03zIQTm+8HgZEDR+PCqpQuHY/fIXJAuaviRGNkT0NDeTh9D4CfBHpSOfFWBdb//5CRzixQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini ,
	"Juergen Gross" 
Subject: [PATCH v5 00/18] amd-cppc CPU Performance Scaling Driver
Date: Tue, 27 May 2025 16:48:15 +0800
Message-ID: <20250527084833.338427-1-Penny.Zheng@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: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F6:EE_|DM6PR12MB4073:EE_
X-MS-Office365-Filtering-Correlation-Id: a002f5d1-dacc-4a0d-a014-08dd9cfb5ab8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?XruPRAI6/PE1Fl6lUZ3lfphdI81K2FYySVy8/2YAJySmaqqY9+I1e67YtKZg?=
 =?us-ascii?Q?j5ushAVdcGryscR9IvL2Iy6N9Fm9DuzhYbHlqI0i9jSYeRbO/zCr5tr32owJ?=
 =?us-ascii?Q?Wp9EngIrZmNMzMN7DJ7HMmt+0mZQlxQr0HFUNxmKRiYDhmV/IK8lqH7kZFvZ?=
 =?us-ascii?Q?D1kNbsax3Zik0xbkNpwzqtElrOstKqKICQ+zxuG0sfbKl+rMY539dv9MHsAB?=
 =?us-ascii?Q?qQzA2JjGOnvT/O4Wo7jUqkmoCxfKYEpSp7mCgd969f/4e36nNVOlfZ8qVYJ3?=
 =?us-ascii?Q?dT0vUmKKicqxTf3dx6UiGeyUmQQeSFXFIp0VAP8DaoHAxeHBR5tVyp9Go4wx?=
 =?us-ascii?Q?HMRdwc9gX//Tw3fAfJ3aSpuIE9CMOgtasgr82gg9t7YhNmTrabd7uyJb0q25?=
 =?us-ascii?Q?41Rl9wiqInWf5uPM5aoTs5ltmBgP9UeINi25OIVmK7ZczPJ7QEY3Y9Oarsmp?=
 =?us-ascii?Q?5oEXX7c+0iI7lc05BdJeN3gFp2ELTMvPcHKEJesr377KCwrj+SSDtgEBcBw1?=
 =?us-ascii?Q?/2vxnnBO/b5Jdn5hx/5HzyOTo9nXdmnL0RzcthZt9SAgRV+9gQoUWKZWX11x?=
 =?us-ascii?Q?pvzOe7+KXcVAJ6+29eyP/1+P93b5f7mv9Fn4mmALZpXsK441tyFKS0rVPMWo?=
 =?us-ascii?Q?2cHMCA5Jbh1TnOFS6KGb5h1K7YjwnBz0rLPUeFKlb1TkV5inrvR46EAcKqpy?=
 =?us-ascii?Q?juhex9RqUzU4Uvwd9sm+tfZUo2WCOoMLwXDfRS19YTZQBnW4/TFtU82p1gbX?=
 =?us-ascii?Q?zAztUnCdWTbERhsRdaFZ+exTz9I+q74gkEaMLY0y+yIM8Bc8iBK8h0bdnwi2?=
 =?us-ascii?Q?seDfBYkEcX4i7/VWxwnIajZtZ2i5FAo++GhSn1LRBOiTyn0/IuhL9jXYJ1Hl?=
 =?us-ascii?Q?iOTIkD27HmbFIMCYAW+glwLxN0YQ3jpiJWeqU9NV5z/4zJhLR5FAP7lyx5V3?=
 =?us-ascii?Q?W+oyn/h1WulmdKAnzq6ZoLjFhVp6W7MUoX8T0/4+DXR/Gr7jIQSWanXhHBpi?=
 =?us-ascii?Q?pjJPC/3Srn9kjm00lJQkJ29/WUKJ4TcjifpxxVy1WPL2vh/hdlj4AMQYAsu5?=
 =?us-ascii?Q?w7UKqRm+SniF9q3EH8j4JGiaQdIRnhx9Z0Nk0TTkEf0n4YlwhX+boCeFoI/Z?=
 =?us-ascii?Q?eropwn2XYcQCYgwSKyAVbfrDSBDkvSHWOOL7X48Pg2vk+JMJG+xCciXq/XzJ?=
 =?us-ascii?Q?pHhCn3kGRaYlL/pvGXwIXm0TWhXQKfqJgq1zEkduYanynihfsqr+tUB6dvt9?=
 =?us-ascii?Q?Orwf1PBtgYL8jYaVIE/vhRs+79RABTRI/OcZaIx//uJ9HwPyOjJ0Vk6SCspw?=
 =?us-ascii?Q?z+6t0V8zYfZb7m+jBrc80jl+DMhftfZpJTA+iN9gdqAT3c4KZzHCVbL8ZmK9?=
 =?us-ascii?Q?vsxG+YIhZZj4jVm4bazscMqd5sVYGVYjlpk+kphKjBmt3oLfW1q78tgvQAP9?=
 =?us-ascii?Q?rDTjHL0huELD4aG7NbmxW0fGZ2t8IOMa4up0vBjem+1EKrQkBNerWtbVrW/R?=
 =?us-ascii?Q?IuUc4Eh6pOdWbCkD7YFeoIpmB34FBFS9b5hj?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:12.7983
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a002f5d1-dacc-4a0d-a014-08dd9cfb5ab8
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4073

amd-cppc is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism on modern AMD APU and CPU series in
Xen. The new mechanism is based on Collaborative Processor Performance
Control (CPPC) which provides finer grain frequency management than
legacy ACPI hardware P-States. Current AMD CPU/APU platforms are using
the ACPI P-states driver to manage CPU frequency and clocks with
switching only in 3 P-states. CPPC replaces the ACPI P-states controls
and allows a flexible, low-latency interface for Xen to directly
communicate the performance hints to hardware.

amd_cppc driver has 2 operation modes: autonomous (active) mode,
and non-autonomous (passive) mode. We register different CPUFreq driver
for different modes, "amd-cppc" for passive mode and "amd-cppc-epp"
for active mode.

The passive mode leverages common governors such as *ondemand*,
*performance*, etc, to manage the performance tuning. While the active mode
uses epp to provides a hint to the hardware if software wants to bias
toward performance (0x0) or energy efficiency (0xff). CPPC power algorithm
in hardware will automatically calculate the runtime workload and adjust the
realtime cpu cores frequency according to the power supply and thermal, core
voltage and some other hardware conditions.

amd-cppc is enabled on passive mode with a top-level `cpufreq=amd-cppc` option,
while users add extra `active` flag to select active mode.

With `cpufreq=amd-cppc,active`, we did a 60s sampling test to see the CPU
frequency change, through tweaking the energy_perf preference from
`xenpm set-cpufreq-cppc powersave` to `xenpm set-cpufreq-cppc performance`.
The outputs are as follows:
```
Setting CPU in powersave mode
Sampling and Outputs:
  Avg freq      580000 KHz
  Avg freq      580000 KHz
  Avg freq      580000 KHz
Setting CPU in performance mode
Sampling and Outputs:
  Avg freq      4640000 KHz
  Avg freq      4220000 KHz
  Avg freq      4640000 KHz

Penny Zheng (18):
  xen/cpufreq: guard perf.states[] access with XEN_PX_INIT
  xen/cpufreq: move "init" flag into common structure
  xen/cpufreq: extract _PSD info from "struct xen_processor_performance"
  xen/cpufreq: introduce new sub-hypercall to propagate CPPC data
  xen/cpufreq: refactor cmdline "cpufreq=xxx"
  xen/cpufreq: introduce "cpufreq=amd-cppc" xen cmdline
  xen/cpufreq: disable px statistic info in amd-cppc mode
  xen/cpu: Expand core frequency calculation for AMD Family 1Ah CPUs
  xen/amd: introduce amd_process_freq() to get processor frequency
  xen/cpufreq: introduce a new amd cppc driver for cpufreq scaling
  xen/cpufreq: implement EPP support for the amd-cppc driver in active
    mode
  xen/cpufreq: get performance policy from governor set via xenpm
  xen/cpufreq: normalize hwp driver check with hwp_active()
  xen/cpufreq: introduce GET_CPUFREQ_CPPC sub-cmd
  xen/cpufreq: bypass governor-related para for amd-cppc-epp
  tools: drop "has_num" condition check for cppc mode
  tools: optimize cpufreq average freq print
  xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc
    driver

 docs/misc/xen-command-line.pandoc         |  15 +-
 tools/include/xenctrl.h                   |   3 +-
 tools/libs/ctrl/xc_pm.c                   |  71 ++-
 tools/misc/xenpm.c                        | 121 ++--
 xen/arch/x86/acpi/cpufreq/Makefile        |   1 +
 xen/arch/x86/acpi/cpufreq/amd-cppc.c      | 674 ++++++++++++++++++++++
 xen/arch/x86/acpi/cpufreq/cpufreq.c       |  63 +-
 xen/arch/x86/cpu/amd.c                    |  83 ++-
 xen/arch/x86/include/asm/amd.h            |   2 +
 xen/arch/x86/include/asm/msr-index.h      |   6 +
 xen/arch/x86/platform_hypercall.c         |  18 +-
 xen/arch/x86/x86_64/cpufreq.c             |  19 +
 xen/arch/x86/x86_64/platform_hypercall.c  |   3 +
 xen/drivers/acpi/pmstat.c                 |  65 ++-
 xen/drivers/cpufreq/cpufreq.c             | 316 ++++++++--
 xen/drivers/cpufreq/utility.c             |  15 +
 xen/include/acpi/cpufreq/cpufreq.h        |  24 +-
 xen/include/acpi/cpufreq/processor_perf.h |  11 +-
 xen/include/public/platform.h             |  30 +
 xen/include/public/sysctl.h               |  10 +-
 xen/include/xen/pmstat.h                  |   5 +
 xen/include/xlat.lst                      |   1 +
 22 files changed, 1416 insertions(+), 140 deletions(-)
 create mode 100644 xen/arch/x86/acpi/cpufreq/amd-cppc.c

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:49:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:49:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997947.1378784 (Exim 4.92)
	(envelope-from )
	id 1uJq03-0004Ci-0B; Tue, 27 May 2025 08:49:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997947.1378784; Tue, 27 May 2025 08: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 1uJq02-0004CX-T5; Tue, 27 May 2025 08:49:30 +0000
Received: by outflank-mailman (input) for mailman id 997947;
 Tue, 27 May 2025 08:49:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq02-00031E-C6
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:30 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2061d.outbound.protection.outlook.com
 [2a01:111:f403:200a::61d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7f506cf6-3ad7-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 10:49:29 +0200 (CEST)
Received: from MW4PR04CA0160.namprd04.prod.outlook.com (2603:10b6:303:85::15)
 by MN2PR12MB4128.namprd12.prod.outlook.com (2603:10b6:208:1dd::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.27; Tue, 27 May
 2025 08:49:22 +0000
Received: from SJ5PEPF000001F6.namprd05.prod.outlook.com
 (2603:10b6:303:85:cafe::b9) by MW4PR04CA0160.outlook.office365.com
 (2603:10b6:303:85::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.23 via Frontend Transport; Tue,
 27 May 2025 08:49:21 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F6.mail.protection.outlook.com (10.167.242.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:21 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 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" 
X-Inumbo-ID: 7f506cf6-3ad7-11f0-a2fd-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=N3rh5QKtwSeme2xscV4SNSIuuAmwinGmBtE2B0k4FMB0zhw6ivkt3HPRRDeSDcZadikvP4Wqi/f5AbsBukuryZlUCHTkfTZsgpI20h3ZSjbm1mMIOGC10KTCjTBvJmhyCxZQ2REZlvlykF2SisJw8rWRclSknJrWo2e2yw2z8/yiWF1r9AGQXHHn0iP/J1z+zBNqXYA7RSDXmvoMlzYssV7xdqCaD7V4QPkq+ph1kdyLQoPSeZCw+pOgaZerxHa22ywrIwEMehtB/sefYmvgrbZzPafZGKn5TeiM9K8O9c2MXmKuKy3QBu0BhDPUx1pHmQSx+/nGLUDNbqHFATY89g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=h9erWVpE/ZTcLZIIbo/RSG1FVEIUzVM1kHU7GnlvLeo=;
 b=mPwkGpujwNQtWKC0LV4RCtNG8vcO6NOGM74dHrcwLJ002ELAEaGOlRHtFWh4RchfbqwaLb4FWbjYR5GAZojClGCC9pEg2a20v/qJDEUVtcO5zcznjZDRB7gM6usTFYtmLLjMe8kvsABMVGOB6vP1BbJa1Tw5E5iSdUFfXFcigQsTJO2m/SMYnCO5eTNTc7dXd+NG3CeaNjUifn+W+yQFcLcUA3xPtqwbm9KbnoiJlSnf+AKZ1DMVBRxSSF/Lg+HdzgqGazgLvH6KmH6a7YHfG3wykVYFb9JiL6wMD/hWi/1gkJymvkmgi+K44ZH8RNjWbBQAzrNwBRXX7aJqQNYA0w==
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=h9erWVpE/ZTcLZIIbo/RSG1FVEIUzVM1kHU7GnlvLeo=;
 b=EtAbKtMcKs8+SKkK+gaHmKUumMiN+wzp0WOU9fFRYBC0K/rSBpdSZS2StDSj9alc0xqpRZT18y4PhUaMluVAOSJ/Gm6UotT3UObmD+r+iWJC38UW8+m/5/e6H8no4PHsUagjz4AWnbji8O9WovJsUWRXAsNDTP0ezMRcQ5QIILc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v5 06/18] xen/x86: introduce "cpufreq=amd-cppc" xen cmdline
Date: Tue, 27 May 2025 16:48:21 +0800
Message-ID: <20250527084833.338427-7-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F6:EE_|MN2PR12MB4128:EE_
X-MS-Office365-Filtering-Correlation-Id: 09ce0d71-04b9-47c8-1ea7-08dd9cfb600a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?UJXu5iH9JqbJlHz3O7eEbqJVQ8WynXcwnG3NZPTn+gRCKT5s7H6xP5+j2rcc?=
 =?us-ascii?Q?5OOQIr+WP8vWlTsUWbUiAn6GG33xspDhPQ+FV7B/jzSQVVxj/q6ZGw2CoomK?=
 =?us-ascii?Q?HcHEFtPELLCJOjhO+q9hVBKQLJeQORjUhbv9GqAj3KMxlsBPl9f9SXW9tnxg?=
 =?us-ascii?Q?IQgG/7mfwnN5sdyIONo/2uPCP+NtNJclmKv91WAyxaOHgCwzooFpyGGXX+KW?=
 =?us-ascii?Q?IPBDcU29Fvd0/8vCVgoTC2lfro0JroZTLezfdxid4LWcpIkMunHrJ8lkv2JS?=
 =?us-ascii?Q?AKgHys0WNAI9EcUzbn93O4wAGYAJ+rp6OKQ6r4kuZDnh0wq3+ZToVsP0FZNp?=
 =?us-ascii?Q?8btAMBmE2GlCyZcyHwg14OQmwT1Xhut3xYMdq++qBF98q8DFjhYlIS+hHCda?=
 =?us-ascii?Q?Xad+umHgrTvCfy0qqew9x2jrcoseQUzTrxLPwgb6pKt4kZsUCpR+MQLmoDK0?=
 =?us-ascii?Q?bIS8VN93lrgtj1LWDl7lbIy1BhrKlmUB7/D2pZus1k5ut+qNquBTidKkH/qy?=
 =?us-ascii?Q?IEHM0iI+PHnliUO2UxpO1EboOyLbQPHywMkjAmaKlpgE5rg21sE7/eiGYMo+?=
 =?us-ascii?Q?aE9Ovxfe/ME7TU8RRGAcArRqmEZRgdwFQnEhgfvRAnXABZ2inrDi7OsItqiX?=
 =?us-ascii?Q?2o8Ep6bRcfdtxgHQDFiz35oMIAHk0C8MduZTekIJYz6jMOLrFt4o4j52Etd+?=
 =?us-ascii?Q?8PEVd9l6zIlbMydoBBVSegkDvrN+oQc49Gwxkn7l1LUY4AduAkFZUt1Lx1vT?=
 =?us-ascii?Q?X5vda2y3douDxc7c5wjhlpdgy9n4BDVILg7MPnuzYrrQ5+fjRKsJiU/nFF2m?=
 =?us-ascii?Q?GhYE8iV+4kAVaEOK9gknryLsFsOwWjZaJyATSbvTDNupSOvPoXeIr8FfX++J?=
 =?us-ascii?Q?3lRemqbecFUmDV+x4dKW1xS5DWVeQjfUP9IweFl8/OpSowJ+cMjTq2xo6Iaf?=
 =?us-ascii?Q?hdee8Wac50OoZqBMRkyiMMPNwUY46gehbB+h8X/Y3VEjixrrNez669ftywzx?=
 =?us-ascii?Q?yEv1y4ta3f6CMtsIZ4I6TF/y7mQIYTWumehtduvhI6DG1RyF3G2sNRG7x4Ha?=
 =?us-ascii?Q?dKWQGYrhNspfzjOTN4icIe8iG2wKh64FoncXr5cUUbKftzL51mO2a268lfCN?=
 =?us-ascii?Q?hCLMDVFTmCuX55dQpd/saEKMT4gQI8YI41qJ1xWhi+vQ1HjrxH2RP9T5lNK7?=
 =?us-ascii?Q?EmoKGNulWsUYD0vEnfN/VaBomJf21da2UTxhnlj6IItgNvcvcbG1afw2Dd0s?=
 =?us-ascii?Q?wRkJqRSwiD25x3QXsa1ZrcXVdF2nsKNjYs9v9Zy7taoCjlF/upmVeHFa1PM9?=
 =?us-ascii?Q?CV63+BzAhCjNuF1SDBSgthH/5PTo4DK/DfRmmKhoYKgbHy1WFg+vRgRGggKS?=
 =?us-ascii?Q?GyoO4bU2Sj3S8slWmxtx0/u/sEaCVZjb/fFgkS2GE0E230B4MDIUN08sR4g3?=
 =?us-ascii?Q?I/WOi4J195mLcPgPbyt/DsrU0E0Q7zui73iFKq8zmoV4RapI39uEfJTgaqmm?=
 =?us-ascii?Q?cScBpJ4WimPB85LNS2KpWx1wPEJXkYU/KK2K?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:21.7202
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 09ce0d71-04b9-47c8-1ea7-08dd9cfb600a
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4128

Users need to set "cpufreq=amd-cppc" in xen cmdline to enable
amd-cppc driver, which selects ACPI Collaborative Performance
and Power Control (CPPC) on supported AMD hardware to provide a
finer grained frequency control mechanism.
`verbose` option can also be included to support verbose print.

When users setting "cpufreq=amd-cppc", a new amd-cppc driver
shall be registered and used. All hooks for amd-cppc driver are transiently
missing and will be implemented in the ongoing commits.

New xen-pm internal flag XEN_PROCESSOR_PM_CPPC is introduced, to be
differentiated with legacy XEN_PROCESSOR_PM_PX. We define
XEN_PROCESSOR_PM_CPPC 0x100, as it is the next value to use after 8-bits wide
public xen-pm options. All xen-pm flag checking involving XEN_PROCESSOR_PM_PX
shall also be updated to consider XEN_PROCESSOR_PM_CPPC now.

Xen is not expected to support both or mixed mode (CPPC & legacy PSS, _PCT,
_PPC) operations, so only one cpufreq driver gets registerd, either amd-cppc
or legacy P-states driver, which is reflected and asserted by the incompatible
flags XEN_PROCESSOR_PM_PX and XEN_PROCESSOR_PM_CPPC.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- Obey to alphabetic sorting and also strict it with CONFIG_AMD
- Remove unnecessary empty comment line
- Use __initconst_cf_clobber for pre-filled structure cpufreq_driver
- Make new switch-case code apply to Hygon CPUs too
- Change ENOSYS with EOPNOTSUPP
- Blanks around binary operator
- Change all amd_/-pstate defined values to amd_/-cppc
---
v2 -> v3
- refactor too long lines
- Make sure XEN_PROCESSOR_PM_PX and XEN_PROCESSOR_PM_CPPC incompatible flags
after cpufreq register registrantion
---
v3 -> v4:
- introduce XEN_PROCESSOR_PM_CPPC in xen internal header
- complement "Hygon" in log message
- remove unnecessary if()
- grow cpufreq_xen_opts[] array
---
v4 -> v5:
- remove XEN_PROCESSOR_PM_xxx flag sanitization from individual driver
- prefer ! over "== 0" in purely boolean contexts
- Blank line between non-fall-through case blocks
- add build-time checking between internal and public XEN_PROCESSOR_PM_*
values
- define XEN_PROCESSOR_PM_CPPC with 0x100, as it is the next value to use
after public interface, and public mask SIF_PM_MASK is 8 bits wide.
- as Dom0 will send the CPPC/Px data whenever it could, the return value shall
be 0 instead of -ENOSYS/EOPNOTSUP when platform doesn't require these data.
---
 docs/misc/xen-command-line.pandoc         |  7 ++-
 xen/arch/x86/acpi/cpufreq/Makefile        |  1 +
 xen/arch/x86/acpi/cpufreq/amd-cppc.c      | 68 +++++++++++++++++++++++
 xen/arch/x86/acpi/cpufreq/cpufreq.c       | 63 ++++++++++++++++++++-
 xen/arch/x86/platform_hypercall.c         | 13 ++++-
 xen/drivers/acpi/pmstat.c                 |  3 +-
 xen/drivers/cpufreq/cpufreq.c             | 18 +++++-
 xen/include/acpi/cpufreq/cpufreq.h        |  6 +-
 xen/include/acpi/cpufreq/processor_perf.h |  3 +
 xen/include/public/sysctl.h               |  1 +
 10 files changed, 175 insertions(+), 8 deletions(-)
 create mode 100644 xen/arch/x86/acpi/cpufreq/amd-cppc.c

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 89db6e83be..9ef847a336 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -515,7 +515,7 @@ If set, force use of the performance counters for oprofile, rather than detectin
 available support.
 
 ### cpufreq
-> `= none | {{  | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]]`
+> `= none | {{  | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-cppc[:[verbose]]`
 
 > Default: `xen`
 
@@ -526,7 +526,7 @@ choice of `dom0-kernel` is deprecated and not supported by all Dom0 kernels.
 * `` and `` are integers which represent max and min processor frequencies
   respectively.
 * `verbose` option can be included as a string or also as `verbose=`
-  for `xen`.  It is a boolean for `hwp`.
+  for `xen`.  It is a boolean for `hwp` and `amd-cppc`.
 * `hwp` selects Hardware-Controlled Performance States (HWP) on supported Intel
   hardware.  HWP is a Skylake+ feature which provides better CPU power
   management.  The default is disabled.  If `hwp` is selected, but hardware
@@ -534,6 +534,9 @@ choice of `dom0-kernel` is deprecated and not supported by all Dom0 kernels.
 * `` is a boolean to enable Hardware Duty Cycling (HDC).  HDC enables the
   processor to autonomously force physical package components into idle state.
   The default is enabled, but the option only applies when `hwp` is enabled.
+* `amd-cppc` selects ACPI Collaborative Performance and Power Control (CPPC)
+  on supported AMD hardware to provide finer grained frequency control
+  mechanism. The default is disabled.
 
 There is also support for `;`-separated fallback options:
 `cpufreq=hwp;xen,verbose`.  This first tries `hwp` and falls back to `xen` if
diff --git a/xen/arch/x86/acpi/cpufreq/Makefile b/xen/arch/x86/acpi/cpufreq/Makefile
index e7dbe434a8..a2ba34bda0 100644
--- a/xen/arch/x86/acpi/cpufreq/Makefile
+++ b/xen/arch/x86/acpi/cpufreq/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_INTEL) += acpi.o
+obj-$(CONFIG_AMD) += amd-cppc.o
 obj-y += cpufreq.o
 obj-$(CONFIG_INTEL) += hwp.o
 obj-$(CONFIG_AMD) += powernow.o
diff --git a/xen/arch/x86/acpi/cpufreq/amd-cppc.c b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
new file mode 100644
index 0000000000..9e64bf957a
--- /dev/null
+++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * amd-cppc.c - AMD Processor CPPC Frequency Driver
+ *
+ * Copyright (C) 2025 Advanced Micro Devices, Inc. All Rights Reserved.
+ *
+ * Author: Penny Zheng 
+ *
+ * AMD CPPC cpufreq driver introduces a new CPU performance scaling design
+ * for AMD processors using the ACPI Collaborative Performance and Power
+ * Control (CPPC) feature which provides finer grained frequency control range.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static bool __init amd_cppc_handle_option(const char *s, const char *end)
+{
+    int ret;
+
+    ret = parse_boolean("verbose", s, end);
+    if ( ret >= 0 )
+    {
+        cpufreq_verbose = ret;
+        return true;
+    }
+
+    return false;
+}
+
+int __init amd_cppc_cmdline_parse(const char *s, const char *e)
+{
+    do {
+        const char *end = strpbrk(s, ",;");
+
+        if ( !amd_cppc_handle_option(s, end) )
+        {
+            printk(XENLOG_WARNING
+                   "cpufreq/amd-cppc: option '%.*s' not recognized\n",
+                   (int)((end ?: e) - s), s);
+
+            return -EINVAL;
+        }
+
+        s = end ? end + 1 : NULL;
+    } while ( s && s < e );
+
+    return 0;
+}
+
+static const struct cpufreq_driver __initconst_cf_clobber
+amd_cppc_cpufreq_driver =
+{
+    .name   = XEN_AMD_CPPC_DRIVER_NAME,
+};
+
+int __init amd_cppc_register_driver(void)
+{
+    if ( !cpu_has_cppc )
+    {
+        xen_processor_pmbits &= ~XEN_PROCESSOR_PM_CPPC;
+        return -ENODEV;
+    }
+
+    return cpufreq_register_driver(&amd_cppc_cpufreq_driver);
+}
diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 61e98b67bd..c40b610c86 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -148,6 +148,11 @@ static int __init cf_check cpufreq_driver_init(void)
                 case CPUFREQ_none:
                     ret = 0;
                     break;
+
+                default:
+                    printk(XENLOG_WARNING
+                           "Unsupported cpufreq driver for vendor Intel\n");
+                    break;
                 }
 
                 if ( ret != -ENODEV )
@@ -157,7 +162,63 @@ static int __init cf_check cpufreq_driver_init(void)
 
         case X86_VENDOR_AMD:
         case X86_VENDOR_HYGON:
-            ret = IS_ENABLED(CONFIG_AMD) ? powernow_register_driver() : -ENODEV;
+            unsigned int i;
+
+            if ( !IS_ENABLED(CONFIG_AMD) )
+            {
+                ret = -ENODEV;
+                break;
+            }
+            ret = -ENOENT;
+
+            for ( i = 0; i < cpufreq_xen_cnt; i++ )
+            {
+                switch ( cpufreq_xen_opts[i] )
+                {
+                case CPUFREQ_xen:
+                    ret = powernow_register_driver();
+                    break;
+
+                case CPUFREQ_amd_cppc:
+                    ret = amd_cppc_register_driver();
+                    break;
+
+                case CPUFREQ_none:
+                    ret = 0;
+                    break;
+
+                default:
+                    printk(XENLOG_WARNING
+                           "Unsupported cpufreq driver for vendor AMD or Hygon\n");
+                    break;
+                }
+
+                if ( ret != -ENODEV )
+                    break;
+            }
+
+            /*
+             * After cpufreq driver registeration, XEN_PROCESSOR_PM_CPPC
+             * and XEN_PROCESSOR_PM_PX shall become exclusive flags.
+             */
+            if ( !ret && i < cpufreq_xen_cnt )
+            {
+                switch ( cpufreq_xen_opts[i] )
+                {
+                case CPUFREQ_amd_cppc:
+                    xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
+                    break;
+
+                case CPUFREQ_xen:
+                    xen_processor_pmbits &= ~XEN_PROCESSOR_PM_CPPC;
+                    break;
+
+                case CPUFREQ_none:
+                default:
+                    break;
+                }
+            }
+
             break;
         }
     }
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 49717e9ca9..231912ed27 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -539,9 +539,12 @@ ret_t do_platform_op(
         case XEN_PM_PX:
             if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
             {
-                ret = -ENOSYS;
+                ret = 0;
                 break;
             }
+            /* Xen doesn't support mixed mode */
+            ASSERT(!(xen_processor_pmbits & XEN_PROCESSOR_PM_CPPC));
+
             ret = set_px_pminfo(op->u.set_pminfo.id, &op->u.set_pminfo.u.perf);
             break;
  
@@ -573,6 +576,14 @@ ret_t do_platform_op(
         }
 
         case XEN_PM_CPPC:
+            if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_CPPC) )
+            {
+                ret = 0;
+                break;
+            }
+            /* Xen doesn't support mixed mode */
+            ASSERT(!(xen_processor_pmbits & XEN_PROCESSOR_PM_PX));
+
             ret = set_cppc_pminfo(op->u.set_pminfo.id,
                                   &op->u.set_pminfo.u.cppc_data);
             break;
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index f7351f219d..330bc3a1c2 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -464,7 +464,8 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
     switch ( op->cmd & PM_PARA_CATEGORY_MASK )
     {
     case CPUFREQ_PARA:
-        if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
+        if ( !(xen_processor_pmbits & (XEN_PROCESSOR_PM_PX |
+                                       XEN_PROCESSOR_PM_CPPC)) )
             return -ENODEV;
         if ( !pmpt || !(pmpt->init & (XEN_PX_INIT | XEN_CPPC_INIT)) )
             return -EINVAL;
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index d1b51c8dd0..fe55720afd 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -65,14 +65,15 @@ LIST_HEAD_READ_MOSTLY(cpufreq_governor_list);
 /* set xen as default cpufreq */
 enum cpufreq_controller cpufreq_controller = FREQCTL_xen;
 
-enum cpufreq_xen_opt __initdata cpufreq_xen_opts[2] = { CPUFREQ_xen,
+enum cpufreq_xen_opt __initdata cpufreq_xen_opts[3] = { CPUFREQ_xen,
                                                         CPUFREQ_none };
 unsigned int __initdata cpufreq_xen_cnt = 1;
 
-static const char __initconst cpufreq_opts_str[][5] = {
+static const char __initconst cpufreq_opts_str[][9] = {
     [CPUFREQ_none] = "none",
     [CPUFREQ_xen] = "xen",
     [CPUFREQ_hwp] = "hwp",
+    [CPUFREQ_amd_cppc] = "amd-cppc",
 };
 
 static int __init cpufreq_cmdline_parse(const char *s, const char *e);
@@ -94,6 +95,8 @@ static int __init handle_cpufreq_cmdline(enum cpufreq_xen_opt option)
 {
     int ret = 0;
 
+    /* Do not occupy bits reserved for public xen-pm */
+    BUILD_BUG_ON(MASK_INSR(XEN_PROCESSOR_PM_CPPC, SIF_PM_MASK));
     if ( cpufreq_opts_contain(option) )
     {
         printk(XENLOG_WARNING "Duplicate cpufreq driver option: %s\n",
@@ -105,6 +108,10 @@ static int __init handle_cpufreq_cmdline(enum cpufreq_xen_opt option)
     cpufreq_xen_opts[cpufreq_xen_cnt++] = option;
     switch ( option )
     {
+    case CPUFREQ_amd_cppc:
+        xen_processor_pmbits |= XEN_PROCESSOR_PM_CPPC;
+        break;
+
     case CPUFREQ_hwp:
     case CPUFREQ_xen:
         xen_processor_pmbits |= XEN_PROCESSOR_PM_PX;
@@ -172,6 +179,13 @@ static int __init cf_check setup_cpufreq_option(const char *str)
             if ( arg[0] && arg[1] )
                 ret = hwp_cmdline_parse(arg + 1, end);
         }
+        else if ( IS_ENABLED(CONFIG_AMD) && choice < 0 &&
+                  !cmdline_strcmp(str, "amd-cppc") )
+        {
+            ret = handle_cpufreq_cmdline(CPUFREQ_amd_cppc);
+            if ( arg[0] && arg[1] )
+                ret = amd_cppc_cmdline_parse(arg + 1, end);
+        }
         else
             ret = -EINVAL;
 
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index a3c84143af..83050c58b2 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -28,8 +28,9 @@ enum cpufreq_xen_opt {
     CPUFREQ_none,
     CPUFREQ_xen,
     CPUFREQ_hwp,
+    CPUFREQ_amd_cppc,
 };
-extern enum cpufreq_xen_opt cpufreq_xen_opts[2];
+extern enum cpufreq_xen_opt cpufreq_xen_opts[3];
 extern unsigned int cpufreq_xen_cnt;
 struct cpufreq_governor;
 
@@ -277,4 +278,7 @@ int set_hwp_para(struct cpufreq_policy *policy,
 
 int acpi_cpufreq_register(void);
 
+int amd_cppc_cmdline_parse(const char *s, const char *e);
+int amd_cppc_register_driver(void);
+
 #endif /* __XEN_CPUFREQ_PM_H__ */
diff --git a/xen/include/acpi/cpufreq/processor_perf.h b/xen/include/acpi/cpufreq/processor_perf.h
index f1f4f3138d..9b6466e705 100644
--- a/xen/include/acpi/cpufreq/processor_perf.h
+++ b/xen/include/acpi/cpufreq/processor_perf.h
@@ -5,6 +5,9 @@
 #include 
 #include 
 
+/* Internal ability bits */
+#define XEN_PROCESSOR_PM_CPPC   0x100
+
 #define XEN_CPPC_INIT 0x40000000U
 #define XEN_PX_INIT   0x80000000U
 
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index b0fec271d3..42997252ef 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -423,6 +423,7 @@ struct xen_set_cppc_para {
     uint32_t activity_window;
 };
 
+#define XEN_AMD_CPPC_DRIVER_NAME "amd-cppc"
 #define XEN_HWP_DRIVER_NAME "hwp"
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:49:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:49:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997941.1378724 (Exim 4.92)
	(envelope-from )
	id 1uJpzw-0002mS-54; Tue, 27 May 2025 08:49:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997941.1378724; Tue, 27 May 2025 08:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJpzw-0002mL-1O; Tue, 27 May 2025 08:49:24 +0000
Received: by outflank-mailman (input) for mailman id 997941;
 Tue, 27 May 2025 08:49:23 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJpzv-0002ks-9W
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:23 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2414::60f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7887d64a-3ad7-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:49:17 +0200 (CEST)
Received: from MW4PR04CA0152.namprd04.prod.outlook.com (2603:10b6:303:85::7)
 by SA1PR12MB9470.namprd12.prod.outlook.com (2603:10b6:806:459::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.22; Tue, 27 May
 2025 08:49:16 +0000
Received: from SJ5PEPF000001F6.namprd05.prod.outlook.com
 (2603:10b6:303:85:cafe::66) by MW4PR04CA0152.outlook.office365.com
 (2603:10b6:303:85::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.21 via Frontend Transport; Tue,
 27 May 2025 08:49:15 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F6.mail.protection.outlook.com (10.167.242.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:15 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 7887d64a-3ad7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XH+1rhaavDfDwBCH8HXrYcrbqNOTupBCt8lI50yyBM95NoYZEUTZohZHLKfkHe2ksOmext4rkgoqB3YNWrXf7D69rUd/5VHHx4j8XBZZHTv4px/bfaktemi56+cg89WvNnuwQvrovtVTMOPmyfPuxn3DSSI8Tu7F5D/EQJPlC8rt6KMxzhTCgjNEEfF97GCL9d4ZwMkC5gHP9KsS0FR0l3FvyiijmXBkeYfsfmu5MQKtt+vQ+QF5Tbdf/y+ls4deVwOX4L8wabnvN0FnndH5R55aJRb3pLWuW2zPopp8Hh0BSmpK6XAYzYGDIhfF14IJ/oubmr0SBWGxsqTLkYlrpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fi/3Ae0XClQrJGJypXXAtKw9kybaw/jzcKrEH2+kynE=;
 b=sFQytABQGmyw7FNdyPK/+EqLWKVhmfk76xJ1oZN2h+ZX2O0f8OIBCha2tVbd6K8I7AzmVaQjC//ZZf0nzPWDe2BP4V1eVyBchx2xZ+OOd2rcb3vEduXGwSM1nO9QS1S7PFM/Kb9ch7xFgUXAbGiT2WK2ZWANjxy2Li543aN0y4bJj2++Ba8IF7Tn9+zCOi5o2d2JUcHJQf8PHhJxm8Mk4hsCSGzkUUGJciXBJeAuRvvRFZn//uTtO+0Xh6aK0Ro1Uh8Y0RzhRGGhrA8pGosrYl32IIilXTOrrqA1zFS/vvCiaxZjtURipNdDKOjVaLq0ytkgnw5oaTNtxiL2tuiSVA==
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=fi/3Ae0XClQrJGJypXXAtKw9kybaw/jzcKrEH2+kynE=;
 b=S+XZkPPCdXAJWXXEr7+0JY00sZMNIz+fP86JRXIVQIKEGkdu1yh+3rNuL+Bf0a/ZfSre8znrT3+qgba6uSAc9EccMpT+sJ/nr75GjBD5STWzuVLOQ+yaAwOU+nnlsE0wC2HD4hL+MEBBoC55CFsV/ENHXqR1/8X0DuOcFy35Hnw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	
Subject: [PATCH v5 02/18] xen/cpufreq: move "init" flag into common structure
Date: Tue, 27 May 2025 16:48:17 +0800
Message-ID: <20250527084833.338427-3-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F6:EE_|SA1PR12MB9470:EE_
X-MS-Office365-Filtering-Correlation-Id: 1fbeb641-8768-4968-9ca5-08dd9cfb5c52
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?v3k7aF9UT+SK3STyAWHp4/4GGkyDW9KbQoaTc78Sqz+bFxnZZZSz5wxX3kaV?=
 =?us-ascii?Q?9JEd75MrHaclknsdzvwDILk6e1vNrXZ1fQr8QMIm76HXj8BdI1iV+pX0rv0t?=
 =?us-ascii?Q?5p4moyUlNIMRSM3VeoxGwv3e7pGSMUngD589rqX5eb2UMXI4ESev/tbu/M6B?=
 =?us-ascii?Q?0cVy86IIaHbUbr2BndxHwj2UmGbIsoG717ijJX2mFiCF8WybPOj44RuhKdag?=
 =?us-ascii?Q?N1aS+rt2Dut311bjS8VlAmMSxa5NZUGWOg7FpKHgKlPwMEV2yu9VHPbrSr7G?=
 =?us-ascii?Q?JxB0GoAoiBpobEtKtdqhWrX2SIHenoZLqpW4f0gERrsdzb+kwguCh7qAsOS3?=
 =?us-ascii?Q?IFibDTNJXhlyX1aaiOG8y6CnK3EFNmn0Qth/SGAr27G6xPEkURPrCj+W4hSC?=
 =?us-ascii?Q?KbGh5v7yfW2CveBfaZKKRO75NbiTl7L0e27/NXrt2Df5sgutKAWsdUohdRlY?=
 =?us-ascii?Q?euhTnQG6o5o+EGGDZ9Kz0lFxQVNccoqbflagOmn2onUOHN4YRudBuhTElBQy?=
 =?us-ascii?Q?wmDdKEmPCniwPe0ETgNNOv+IqhPdB39BLtgC97NQtjKSU06qw6H017gdaTh1?=
 =?us-ascii?Q?Yw/EedZGWepA9blJ+T4+5PIhLE7irs4y/q1ylTDdWxPVtWj1CBLbyxjDFhmw?=
 =?us-ascii?Q?NeA0ioNAsMo7GGOnieKOlc7OvVzjppkD2kL7P+j0u0XrGaKbQ6Nqd2w39X47?=
 =?us-ascii?Q?PcN2bkT9YPlqjRiu/gjFTXNSIeZLi1s9C7aycixA9+LeIO3fkQUH5JFEjSdY?=
 =?us-ascii?Q?t8X2y5ni98yxEhyqDiAgwQTmX4CsgMG4NNoPUwRZ1k5+a6t3/e/IPmuweSOA?=
 =?us-ascii?Q?EU1QHFYfD3pDpZRepWKvOzuxmQqxgAXrIsVWRgV8wUYabT1crqcY9Vx6akUj?=
 =?us-ascii?Q?ueFBfboYnA5tCmveukqYrNKfeNY36sXfk+TRED6d/hlLjXdaT6orTJNee+hB?=
 =?us-ascii?Q?Y9mMvtcxWIrOwBMdpTbfa//3St1Smh+NUG8oPmzbGVMUBD7W7Mp7xUJ90vFB?=
 =?us-ascii?Q?Jkdxzvk2YM6PY2orI5mwuBx0Z7BAwz8KSLupJirpRMjrzlQRYpJWRX/WA447?=
 =?us-ascii?Q?DOR8K24/NcMqqSN0kfPGzfwPs6j0HzJhKXMCtGFNjpih5JV1QL1ihs3KpaBO?=
 =?us-ascii?Q?4R7x253QHyC0/BpdA367z64KLn23B+FsE8l3rQViqaThWA0cgWg+/JepM0ns?=
 =?us-ascii?Q?o+/YRkZS4+RYBNM+8//b0FToqNiXHZu/SZydmHYnKZ+6+RjzooXdNsIpG/oL?=
 =?us-ascii?Q?ts5P4N00ezLU6gK6B+npzIID0VeG57mYJJQcgXlzHQHcBOpJTSz7tnVuoEKZ?=
 =?us-ascii?Q?0V00m+GSi9w3Lh1cMvveEYGM2RS/33E9iO6mSsU3oAtxYuMn0vZozhgwnPsb?=
 =?us-ascii?Q?SBoPoSaEuGglzu+Xlg75fgLnYYutupJRzgjckas6lfair0IlYpid6yDZPD26?=
 =?us-ascii?Q?llBPX+Rok6NJ0iDekkFfXzviIUQR0rlboXeHME8eejigp0s4lzG1GYySOOcO?=
 =?us-ascii?Q?gOUs5Xn3U3+Nhz+XDXPXC+SY0U4/m6b8fvxV?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:15.4858
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1fbeb641-8768-4968-9ca5-08dd9cfb5c52
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB9470

AMD cpufreq cores will be intialized in two modes, legacy P-state mode,
and CPPC mode. So "init" flag shall be extracted from px-specific
"struct xen_processor_perf", and placed in the common
"struct processor_pminfo". Otherwise, later when introducing a new
sub-hypercall to propagate CPPC data, we need to pass irrelevant px-specific
"struct xen_processor_perf" to just set init flag.

Signed-off-by: Penny Zheng 
---
v3 -> v4:
- new commit
---
v4 -> v5:
- commit message refactor
---
 xen/drivers/acpi/pmstat.c                 | 6 +++---
 xen/drivers/cpufreq/cpufreq.c             | 8 ++++----
 xen/include/acpi/cpufreq/processor_perf.h | 4 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index b7fcc02db9..6a1a900f78 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -68,7 +68,7 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
             return -ENODEV;
         if ( hwp_active() )
             return -EOPNOTSUPP;
-        if ( !pmpt || !(pmpt->perf.init & XEN_PX_INIT) )
+        if ( !pmpt || !(pmpt->init & XEN_PX_INIT) )
             return -EINVAL;
         break;
     default:
@@ -228,7 +228,7 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
     ret = copy_to_guest(op->u.get_para.affected_cpus,
                         data, op->u.get_para.cpu_num);
 
-    if ( pmpt->perf.init & XEN_PX_INIT )
+    if ( pmpt->init & XEN_PX_INIT )
     {
         for ( i = 0; i < op->u.get_para.freq_num; i++ )
             data[i] = pmpt->perf.states[i].core_frequency * 1000;
@@ -466,7 +466,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
     case CPUFREQ_PARA:
         if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
             return -ENODEV;
-        if ( !pmpt || !(pmpt->perf.init & XEN_PX_INIT) )
+        if ( !pmpt || !(pmpt->init & XEN_PX_INIT) )
             return -EINVAL;
         break;
     }
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index 19e2992335..08d027317c 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -209,7 +209,7 @@ int cpufreq_add_cpu(unsigned int cpu)
 
     perf = &processor_pminfo[cpu]->perf;
 
-    if ( !(perf->init & XEN_PX_INIT) )
+    if ( !(processor_pminfo[cpu]->init & XEN_PX_INIT) )
         return -EINVAL;
 
     if (!cpufreq_driver.init)
@@ -373,7 +373,7 @@ int cpufreq_del_cpu(unsigned int cpu)
 
     perf = &processor_pminfo[cpu]->perf;
 
-    if ( !(perf->init & XEN_PX_INIT) )
+    if ( !(processor_pminfo[cpu]->init & XEN_PX_INIT) )
         return -EINVAL;
 
     if (!per_cpu(cpufreq_cpu_policy, cpu))
@@ -569,7 +569,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf)
         if ( cpufreq_verbose )
             print_PPC(pxpt->platform_limit);
 
-        if ( pxpt->init == XEN_PX_INIT )
+        if ( pmpt->init == XEN_PX_INIT )
         {
             ret = cpufreq_limit_change(cpu);
             goto out;
@@ -578,7 +578,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf)
 
     if ( perf->flags == ( XEN_PX_PCT | XEN_PX_PSS | XEN_PX_PSD | XEN_PX_PPC ) )
     {
-        pxpt->init = XEN_PX_INIT;
+        pmpt->init = XEN_PX_INIT;
 
         ret = cpufreq_cpu_init(cpu);
         goto out;
diff --git a/xen/include/acpi/cpufreq/processor_perf.h b/xen/include/acpi/cpufreq/processor_perf.h
index 301104e16f..5f2612b15a 100644
--- a/xen/include/acpi/cpufreq/processor_perf.h
+++ b/xen/include/acpi/cpufreq/processor_perf.h
@@ -29,14 +29,14 @@ struct processor_performance {
     struct xen_processor_px *states;
     struct xen_psd_package domain_info;
     uint32_t shared_type;
-
-    uint32_t init;
 };
 
 struct processor_pminfo {
     uint32_t acpi_id;
     uint32_t id;
     struct processor_performance    perf;
+
+    uint32_t init;
 };
 
 extern struct processor_pminfo *processor_pminfo[NR_CPUS];
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:49:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:49:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997945.1378756 (Exim 4.92)
	(envelope-from )
	id 1uJpzz-0003OH-92; Tue, 27 May 2025 08:49:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997945.1378756; Tue, 27 May 2025 08:49:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJpzz-0003Mc-3m; Tue, 27 May 2025 08:49:27 +0000
Received: by outflank-mailman (input) for mailman id 997945;
 Tue, 27 May 2025 08:49:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJpzy-0002ks-3d
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:26 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2412::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7a2f0480-3ad7-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:49:20 +0200 (CEST)
Received: from MW4PR04CA0172.namprd04.prod.outlook.com (2603:10b6:303:85::27)
 by MW6PR12MB8867.namprd12.prod.outlook.com (2603:10b6:303:249::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.25; Tue, 27 May
 2025 08:49:18 +0000
Received: from SJ5PEPF000001F6.namprd05.prod.outlook.com
 (2603:10b6:303:85:cafe::7a) by MW4PR04CA0172.outlook.office365.com
 (2603:10b6:303:85::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Tue,
 27 May 2025 08:49:18 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F6.mail.protection.outlook.com (10.167.242.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:18 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 7a2f0480-3ad7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BK/v4no0pxDIAg1xZeHEzqp6jGARdlUNRlbr1oKnRnBpuAxZAVa/qKpln88Zw8MDPfzlCc1h02yaDs8ZF01rDKLSdC6k10eA0393d1UnC0G5Vled3sgfEZQcbm7WTwHgNhYxio6yogHN7slQtfukWH62k1VgF+WQTc2wPfgESNHr0hiByxdIw5hSg29y2sBMgRp/bt7yuhEsP9K+q4FhDlX7ubW+Gandj03g8Gm7+NJGbkRH7mAifGFp1NVKzhOvlAquTu9giJ1GI3dGXCG+YD3ZPaMiqYBMVEh57eOfzrlkBXHv28u+87pgH+AveK4PvxIWqVuCD8OCfhVGqXzqpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hPo1OVjRKmEYvcsDmuocigHTLx4OfLHa+FzOOo/dHs4=;
 b=OdOjmHS68nJ+xtTqRd2vgj3M61kXKpO0bfFY5Qke7bKvDTR27YVbODonMm6wY4vowdi/zKfCmFUkTmTMrHTg4dVDJDwHMOgGfrhkn3fPDQS3MGzuTA26n6rpE3MI+aQPGL85I6t2PAagwbUjVd3kC/lpRpLzwXrm67c8cXJ7aCsI7JyeJFJQDarCyJARMl8D255i+9f3CRB6oSrrwlwXU27zvOzqb0/W543tWp7TxTKBREOU86kEN3k753egJLuz0fRcJRrgqe+HUImvKUASZDCFFkdwJPKPR1vbODL2kB68o6TCPb4KZXLraIspMo8Lpmy6CDRoQ/kt4HA0UoG1rg==
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=hPo1OVjRKmEYvcsDmuocigHTLx4OfLHa+FzOOo/dHs4=;
 b=F1YOfno3r7ZPa1eCmwWqH26SVthXqzp5TCWWcGmZZl2KO2KnqXibWr66aReEQ3kwJ8z654ns8M/aJ7k6EzDI+eNQOT392JnRQCNIc4mJPOKm99n9G1/w4aQCkLA4H4a2dMcxL42Wp8ZTBXMzc1lpGocjt9pDxXD2Bg2t12GfPLc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to propagate CPPC data
Date: Tue, 27 May 2025 16:48:19 +0800
Message-ID: <20250527084833.338427-5-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F6:EE_|MW6PR12MB8867:EE_
X-MS-Office365-Filtering-Correlation-Id: 0f462b3d-7960-4e39-c4f0-08dd9cfb5de0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Hlp5v/MTcFRpei0U8ECjawVR3ADYLqsJ/Oo1RhBr7oji48nPXwnEc2rl59Gz?=
 =?us-ascii?Q?IKAfwpdqLTStWj3pbl7BBLr73Cb89iXeLnjcd+d5sgFJp7M/W9faN/8qgq2J?=
 =?us-ascii?Q?pPQdQeSw2FhpNoqdp97EvLbjl/iOw+OTb1v5XMZ3ImjLyHL+1gwFLNe3k2Xr?=
 =?us-ascii?Q?bQgQ9A6n8KHw4x93J8nu2atL4j3Ma6X/vTfQzbgIwxGLrRmpqRNkiIxVYa0V?=
 =?us-ascii?Q?Ei9GgU3kzxmw4tLgRxSkl0lvHbdsc+NTquNLJTsvWeU75dSd6Yv9T0UFxryh?=
 =?us-ascii?Q?tpz4/XfUnicWwsuz9/EBVcYdHr3Qmualuep9TL+PuyM736A62ZmQqKIZDEN0?=
 =?us-ascii?Q?QGK0gi8rYXr5sX9UkY7hBpptFW3eagmGq5YTtrSf97q3gNzocY54V6gfJofl?=
 =?us-ascii?Q?3ntGPpDnzgXQf2R841f2hirANxMomnmPsPPqjz36pLK8hflDpD53vTRDQenT?=
 =?us-ascii?Q?54wY+suRO5pgXRHzh04EQCKgrtE1Anaph++1szi2UBqk6ArLvbJWl+Rjwp+5?=
 =?us-ascii?Q?u1Jp7BXD7jcKq0GIP07zHNLD+EOmB/py3lcKT4ouGbIe6gUEkoMHfntTo1BR?=
 =?us-ascii?Q?5B9j9RKH7RRIvaDqpGNQoBbEpyIHsuE+m6WFla5cIfIse5JAR9oiwIHNm/W2?=
 =?us-ascii?Q?RK7HGBJsFTma00B7o0KIHxLOMDXV+2EAq73FxS9VgeRCQlbjWvPs17nYhPTp?=
 =?us-ascii?Q?0Eapgh+qLV4JMeinH661qv/cUMNG6ZumNZd2ygJ7RGQQA0VhsFn7Oem7ldy2?=
 =?us-ascii?Q?BbLS/N7ieXE7ZBhIWO+TBNYmXQoVqQdgipYPaR9AWfnXGRYXlxLhWIc5V7Iu?=
 =?us-ascii?Q?3cJpyN/JWxjt0z/FAMF37CNoQ4DgyZK81LHAaRY1SBbwAtAIQLHKe4ougTpb?=
 =?us-ascii?Q?mobk6+eysy74rbb1kByQ+mO60epa8FW8BbAwqEUzloF+0Os+Jp9vqxCfb/qd?=
 =?us-ascii?Q?sF0qQYDjuoydtoqRTWH1HtCiByAu+2YPJ+sEb9KTqC020/3PMUlZnP3n8j9A?=
 =?us-ascii?Q?y4dgnHOBmuBgBqt5DDoCCqIo1ETCrpVOuBf6m4NGSlTxoPOtk4h8X5yrtIZq?=
 =?us-ascii?Q?dKgYUYVn3EsyMvFW/kaNNL4D5r9AHrqRIvPr3/R396cdMYQ0tGrTf06wD5Xu?=
 =?us-ascii?Q?K71buSQNnTJd2b6OnsedFUv5AxpVNRzCMGgyhYyTQkp8PE/oIiz+TzoGwQlm?=
 =?us-ascii?Q?mcQDq3YWHjPDUHJlHPrAxnXlHBZP4BJvCjGeRBmNy3gL//K2uQVrthYdtXCf?=
 =?us-ascii?Q?CBljRecCkAU1aQnf7+R6PgkneZ6FjR877lV7H2/M+EXkGWtIVtLdppEtzKss?=
 =?us-ascii?Q?OaUcgEmW8VC29Krg02bFL80u7MV+CBhswNmfZTl8MtoKJfp9XbRPAl6EahTv?=
 =?us-ascii?Q?PDkitABnkUN/bzQ/JEsDKOemY/PKrgRy4+gkwLa99HCsoBGjLqZj1K/wI/1b?=
 =?us-ascii?Q?ULKoxio7zk5Im1fRIjAMsb9ES8WIdz69nr2ZNXLoSLO1OHvt1xnZ3DSTTKZY?=
 =?us-ascii?Q?JsY2lJLfhB89h+85xf2Cbx1Q4VOCllbdeFJs?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:18.0951
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f462b3d-7960-4e39-c4f0-08dd9cfb5de0
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8867

In order to provide backward compatibility with existing governors
that represent performance as frequency, like ondemand, the _CPC
table can optionally provide processor frequency range values, Lowest
frequency and Nominal frequency, to let OS use Lowest Frequency/
Performance and Nominal Frequency/Performance as anchor points to
create linear mapping of CPU frequency to CPPC performance.

As Xen is uncapable of parsing the ACPI dynamic table, we'd like to
introduce a new sub-hypercall "XEN_PM_CPPC" to propagate required CPPC
data from dom0 kernel to Xen.
In the according handler set_cppc_pminfo(), we do _CPC and _PSD
sanitization check, as both _PSD and _CPC info are necessary for correctly
initializing cpufreq cores in CPPC mode.
Users shall be warned that if we failed at this point,
no fallback scheme, like legacy P-state could be switched to.

A new flag "XEN_CPPC_INIT" is also introduced to differentiate cpufreq core
initialised in Px mode. Then all .init flag checking shall be updated to
consider "XEN_CPPC_INIT" too.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- Remove unnecessary figure braces
- Pointer-to-const for print_CPPC and set_cppc_pminfo
- Structure allocation shall use xvzalloc()
- Unnecessary memcpy(), and change it to a (type safe) structure assignment
- Add comment for struct xen_processor_cppc, and keep the chosen fields
in the order _CPC has them
- Obey to alphabetic sorting, and prefix compat structures with ? instead
of !
---
v2 -> v3:
- Trim too long line
- Re-place set_cppc_pminfo() past set_px_pminfo()
- Fix Misra violations: Declaration and definition ought to agree
in parameter names
- Introduce a new flag XEN_PM_CPPC to reflect processor initialised in CPPC
mode
---
v3 -> v4:
- Refactor commit message
- make "acpi_id" unsigned int
- Add warning message when cpufreq_cpu_init() failed only under debug mode
- Expand "struct xen_processor_cppc" to include _PSD and shared type
- add sanity check for ACPI CPPC data
---
v4 -> v5:
- remove the ordering check between lowest_nonlinear_perf and lowest_perf
- use printk_once() for cppc perf value warning
- complement comment for cppc perf value check
- remove redundant check and pointless parenthesizing
- use dprintk() for warning under #ifndef NDEBUG
- refactor warning message when having non-zero ret of cpufreq_cpu_init()
- With introduction of "struct xen_psd_package" in "struct xen_processor_cppc",
use ! and the respective XLAT_* macro(s) to wrap.
---
 xen/arch/x86/platform_hypercall.c         |   5 +
 xen/arch/x86/x86_64/cpufreq.c             |  19 ++++
 xen/arch/x86/x86_64/platform_hypercall.c  |   3 +
 xen/drivers/acpi/pmstat.c                 |   4 +-
 xen/drivers/cpufreq/cpufreq.c             | 128 +++++++++++++++++++++-
 xen/include/acpi/cpufreq/processor_perf.h |   4 +-
 xen/include/public/platform.h             |  30 +++++
 xen/include/xen/pmstat.h                  |   5 +
 xen/include/xlat.lst                      |   1 +
 9 files changed, 194 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 90abd3197f..49717e9ca9 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -572,6 +572,11 @@ ret_t do_platform_op(
             break;
         }
 
+        case XEN_PM_CPPC:
+            ret = set_cppc_pminfo(op->u.set_pminfo.id,
+                                  &op->u.set_pminfo.u.cppc_data);
+            break;
+
         default:
             ret = -EINVAL;
             break;
diff --git a/xen/arch/x86/x86_64/cpufreq.c b/xen/arch/x86/x86_64/cpufreq.c
index e4f3d5b436..8d57f67c2e 100644
--- a/xen/arch/x86/x86_64/cpufreq.c
+++ b/xen/arch/x86/x86_64/cpufreq.c
@@ -54,3 +54,22 @@ int compat_set_px_pminfo(uint32_t acpi_id,
 
     return set_px_pminfo(acpi_id, xen_perf);
 }
+
+int compat_set_cppc_pminfo(unsigned int acpi_id,
+                           const struct compat_processor_cppc *cppc_data)
+
+{
+    struct xen_processor_cppc *xen_cppc;
+    unsigned long xlat_page_current;
+
+    xlat_malloc_init(xlat_page_current);
+
+    xen_cppc = xlat_malloc_array(xlat_page_current,
+                                 struct xen_processor_cppc, 1);
+    if ( unlikely(xen_cppc == NULL) )
+        return -EFAULT;
+
+    XLAT_processor_cppc(xen_cppc, cppc_data);
+
+    return set_cppc_pminfo(acpi_id, xen_cppc);
+}
diff --git a/xen/arch/x86/x86_64/platform_hypercall.c b/xen/arch/x86/x86_64/platform_hypercall.c
index 9ab631c17f..0288f68df9 100644
--- a/xen/arch/x86/x86_64/platform_hypercall.c
+++ b/xen/arch/x86/x86_64/platform_hypercall.c
@@ -14,6 +14,9 @@ EMIT_FILE;
 #define efi_get_info        efi_compat_get_info
 #define efi_runtime_call(x) efi_compat_runtime_call(x)
 
+#define xen_processor_cppc  compat_processor_cppc
+#define set_cppc_pminfo     compat_set_cppc_pminfo
+
 #define xen_processor_performance compat_processor_performance
 #define set_px_pminfo       compat_set_px_pminfo
 
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index 6a1a900f78..f7351f219d 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -201,7 +201,7 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
     pmpt = processor_pminfo[op->cpuid];
     policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
 
-    if ( !pmpt || !pmpt->perf.states ||
+    if ( !pmpt || ((pmpt->init & XEN_PX_INIT) && !pmpt->perf.states) ||
          !policy || !policy->governor )
         return -EINVAL;
 
@@ -466,7 +466,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
     case CPUFREQ_PARA:
         if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
             return -ENODEV;
-        if ( !pmpt || !(pmpt->init & XEN_PX_INIT) )
+        if ( !pmpt || !(pmpt->init & (XEN_PX_INIT | XEN_CPPC_INIT)) )
             return -EINVAL;
         break;
     }
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index 9567221d97..d6b6c844d8 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -203,6 +204,11 @@ static int get_psd_info(unsigned int cpu, uint32_t *shared_type,
         *domain_info_ptr = &processor_pminfo[cpu]->perf.domain_info;
         break;
 
+    case XEN_CPPC_INIT:
+        *shared_type = processor_pminfo[cpu]->cppc_data.shared_type;
+        *domain_info_ptr = &processor_pminfo[cpu]->cppc_data.domain_info;
+        break;
+
     default:
         ret = -EINVAL;
         break;
@@ -229,7 +235,7 @@ int cpufreq_add_cpu(unsigned int cpu)
     if ( !processor_pminfo[cpu] || !cpu_online(cpu) )
         return -EINVAL;
 
-    if ( !(processor_pminfo[cpu]->init & XEN_PX_INIT) )
+    if ( !(processor_pminfo[cpu]->init & (XEN_PX_INIT | XEN_CPPC_INIT)) )
         return -EINVAL;
 
     if (!cpufreq_driver.init)
@@ -409,7 +415,7 @@ int cpufreq_del_cpu(unsigned int cpu)
     if ( !processor_pminfo[cpu] || !cpu_online(cpu) )
         return -EINVAL;
 
-    if ( !(processor_pminfo[cpu]->init & XEN_PX_INIT) )
+    if ( !(processor_pminfo[cpu]->init & (XEN_PX_INIT | XEN_CPPC_INIT)) )
         return -EINVAL;
 
     if (!per_cpu(cpufreq_cpu_policy, cpu))
@@ -635,6 +641,124 @@ out:
     return ret;
 }
 
+static void print_CPPC(const struct xen_processor_cppc *cppc_data)
+{
+    printk("\t_CPC: highest_perf=%u, lowest_perf=%u, "
+           "nominal_perf=%u, lowest_nonlinear_perf=%u, "
+           "nominal_mhz=%uMHz, lowest_mhz=%uMHz\n",
+           cppc_data->cpc.highest_perf, cppc_data->cpc.lowest_perf,
+           cppc_data->cpc.nominal_perf, cppc_data->cpc.lowest_nonlinear_perf,
+           cppc_data->cpc.nominal_mhz, cppc_data->cpc.lowest_mhz);
+}
+
+int set_cppc_pminfo(unsigned int acpi_id,
+                    const struct xen_processor_cppc *cppc_data)
+{
+    int ret = 0, cpuid;
+    struct processor_pminfo *pm_info;
+
+    cpuid = get_cpu_id(acpi_id);
+    if ( cpuid < 0 || !cppc_data )
+    {
+        ret = -EINVAL;
+        goto out;
+    }
+
+    if ( cppc_data->pad[0] || cppc_data->pad[1] || cppc_data->pad[2] )
+    {
+        ret = -EINVAL;
+        goto out;
+    }
+
+    if ( cpufreq_verbose )
+        printk("Set CPU acpi_id(%u) cpuid(%d) CPPC State info:\n",
+               acpi_id, cpuid);
+
+    pm_info = processor_pminfo[cpuid];
+    if ( !pm_info )
+    {
+        pm_info = xvzalloc(struct processor_pminfo);
+        if ( !pm_info )
+        {
+            ret = -ENOMEM;
+            goto out;
+        }
+        processor_pminfo[cpuid] = pm_info;
+    }
+    pm_info->acpi_id = acpi_id;
+    pm_info->id = cpuid;
+    pm_info->cppc_data = *cppc_data;
+
+    if ( cppc_data->flags & XEN_CPPC_PSD )
+    {
+        ret = check_psd_pminfo(cppc_data->shared_type);
+        if ( ret )
+            goto out;
+    }
+
+    if ( cppc_data->flags & XEN_CPPC_CPC )
+    {
+        if ( cppc_data->cpc.highest_perf == 0 ||
+             cppc_data->cpc.highest_perf > UINT8_MAX ||
+             cppc_data->cpc.nominal_perf == 0 ||
+             cppc_data->cpc.nominal_perf > UINT8_MAX ||
+             cppc_data->cpc.lowest_nonlinear_perf == 0 ||
+             cppc_data->cpc.lowest_nonlinear_perf > UINT8_MAX ||
+             cppc_data->cpc.lowest_perf == 0 ||
+             cppc_data->cpc.lowest_perf > UINT8_MAX ||
+             cppc_data->cpc.lowest_perf >
+                cppc_data->cpc.nominal_perf ||
+             cppc_data->cpc.lowest_nonlinear_perf >
+                cppc_data->cpc.nominal_perf ||
+             cppc_data->cpc.nominal_perf > cppc_data->cpc.highest_perf )
+            /*
+             * Right now, Xen doesn't actually use highest_perf/nominal_perf/
+             * lowest_nonlinear_perf/lowest_perf values read from ACPI _CPC
+             * table. Xen reads CPPC capability MSR to get these four values.
+             * So warning is enough.
+             */
+            printk_once(XENLOG_WARNING
+                        "Broken CPPC perf values: lowest(%u), nonlinear_lowest(%u), nominal(%u), highest(%u)\n",
+                        cppc_data->cpc.lowest_perf,
+                        cppc_data->cpc.lowest_nonlinear_perf,
+                        cppc_data->cpc.nominal_perf,
+                        cppc_data->cpc.highest_perf);
+
+        /* lowest_mhz and nominal_mhz are optional value */
+        if ( cppc_data->cpc.lowest_mhz > cppc_data->cpc.nominal_mhz )
+        {
+            printk_once(XENLOG_WARNING
+                        "Broken CPPC freq values: lowest(%u), nominal(%u)\n",
+                        cppc_data->cpc.lowest_mhz,
+                        cppc_data->cpc.nominal_mhz);
+            /* Re-set with zero values, instead of keeping invalid values */
+            pm_info->cppc_data.cpc.nominal_mhz = 0;
+            pm_info->cppc_data.cpc.lowest_mhz = 0;
+        }
+    }
+
+    if ( cppc_data->flags == (XEN_CPPC_PSD | XEN_CPPC_CPC) )
+    {
+        if ( cpufreq_verbose )
+        {
+            print_PSD(&pm_info->cppc_data.domain_info);
+            print_CPPC(&pm_info->cppc_data);
+        }
+
+        pm_info->init = XEN_CPPC_INIT;
+        ret = cpufreq_cpu_init(cpuid);
+#ifndef NDEBUG
+        if ( ret )
+            dprintk(XENLOG_WARNING,
+                    "CPU %u failed to be initialized with amd-cppc mode, and users could only reboot and re-define cmdline with \"cpufreq=xen\"",
+                    cpuid);
+#endif
+    }
+
+ out:
+    return ret;
+}
+
 static void cpufreq_cmdline_common_para(struct cpufreq_policy *new_policy)
 {
     if (usr_max_freq)
diff --git a/xen/include/acpi/cpufreq/processor_perf.h b/xen/include/acpi/cpufreq/processor_perf.h
index 5f2612b15a..f1f4f3138d 100644
--- a/xen/include/acpi/cpufreq/processor_perf.h
+++ b/xen/include/acpi/cpufreq/processor_perf.h
@@ -5,7 +5,8 @@
 #include 
 #include 
 
-#define XEN_PX_INIT 0x80000000U
+#define XEN_CPPC_INIT 0x40000000U
+#define XEN_PX_INIT   0x80000000U
 
 unsigned int powernow_register_driver(void);
 unsigned int get_measured_perf(unsigned int cpu, unsigned int flag);
@@ -35,6 +36,7 @@ struct processor_pminfo {
     uint32_t acpi_id;
     uint32_t id;
     struct processor_performance    perf;
+    struct xen_processor_cppc cppc_data;
 
     uint32_t init;
 };
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 2725b8d104..0bf7543fff 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -363,6 +363,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t);
 #define XEN_PM_PX   1
 #define XEN_PM_TX   2
 #define XEN_PM_PDC  3
+#define XEN_PM_CPPC 4
 
 /* Px sub info type */
 #define XEN_PX_PCT   1
@@ -370,6 +371,10 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t);
 #define XEN_PX_PPC   4
 #define XEN_PX_PSD   8
 
+/* CPPC sub info type */
+#define XEN_CPPC_PSD   1
+#define XEN_CPPC_CPC   2
+
 struct xen_power_register {
     uint32_t     space_id;
     uint32_t     bit_width;
@@ -457,6 +462,30 @@ struct xen_processor_performance {
 typedef struct xen_processor_performance xen_processor_performance_t;
 DEFINE_XEN_GUEST_HANDLE(xen_processor_performance_t);
 
+struct xen_processor_cppc {
+    uint8_t flags; /* flag for CPPC sub info type */
+    uint8_t pad[3]; /* padding and must be zero */
+    /*
+     * Subset _CPC fields useful for CPPC-compatible cpufreq
+     * driver's initialization
+     */
+    struct {
+        uint32_t highest_perf;
+        uint32_t nominal_perf;
+        uint32_t lowest_nonlinear_perf;
+        uint32_t lowest_perf;
+        uint32_t lowest_mhz;
+        uint32_t nominal_mhz;
+    } cpc;
+    /* Coordination type of this processor */
+#define XEN_CPUPERF_SHARED_TYPE_HW   1 /* HW does needed coordination */
+#define XEN_CPUPERF_SHARED_TYPE_ALL  2 /* All dependent CPUs should set freq */
+#define XEN_CPUPERF_SHARED_TYPE_ANY  3 /* Freq can be set from any dependent CPU */
+    uint32_t shared_type;
+    struct xen_psd_package domain_info; /* _PSD */
+};
+typedef struct xen_processor_cppc xen_processor_cppc_t;
+
 struct xenpf_set_processor_pminfo {
     /* IN variables */
     uint32_t id;    /* ACPI CPU ID */
@@ -465,6 +494,7 @@ struct xenpf_set_processor_pminfo {
         struct xen_processor_power          power;/* Cx: _CST/_CSD */
         struct xen_processor_performance    perf; /* Px: _PPC/_PCT/_PSS/_PSD */
         XEN_GUEST_HANDLE(uint32)            pdc;  /* _PDC */
+        xen_processor_cppc_t                cppc_data; /* _CPC and _PSD */
     } u;
 };
 typedef struct xenpf_set_processor_pminfo xenpf_set_processor_pminfo_t;
diff --git a/xen/include/xen/pmstat.h b/xen/include/xen/pmstat.h
index 8350403e95..1f21f43a13 100644
--- a/xen/include/xen/pmstat.h
+++ b/xen/include/xen/pmstat.h
@@ -7,8 +7,13 @@
 
 int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf);
 long set_cx_pminfo(uint32_t acpi_id, struct xen_processor_power *power);
+int set_cppc_pminfo(unsigned int acpi_id,
+                    const struct xen_processor_cppc *cppc_data);
 
 #ifdef CONFIG_COMPAT
+struct compat_processor_cppc;
+int compat_set_cppc_pminfo(unsigned int acpi_id,
+                           const struct compat_processor_cppc *cppc_data);
 struct compat_processor_performance;
 int compat_set_px_pminfo(uint32_t acpi_id, struct compat_processor_performance *perf);
 struct compat_processor_power;
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3c7b6c6830..a800671f2f 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -168,6 +168,7 @@
 !	processor_performance		platform.h
 !	processor_power			platform.h
 ?	processor_px			platform.h
+!	processor_cppc			platform.h
 !	psd_package			platform.h
 ?	xenpf_enter_acpi_sleep		platform.h
 ?	xenpf_pcpu_version		platform.h
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:49:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:49:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997948.1378793 (Exim 4.92)
	(envelope-from )
	id 1uJq04-0004Tc-Aj; Tue, 27 May 2025 08:49:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997948.1378793; Tue, 27 May 2025 08:49: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 1uJq04-0004TH-7A; Tue, 27 May 2025 08:49:32 +0000
Received: by outflank-mailman (input) for mailman id 997948;
 Tue, 27 May 2025 08:49:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq03-0002ks-Dk
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:31 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2415::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7d9f72c5-3ad7-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:49:26 +0200 (CEST)
Received: from MW4PR04CA0168.namprd04.prod.outlook.com (2603:10b6:303:85::23)
 by DS7PR12MB6240.namprd12.prod.outlook.com (2603:10b6:8:94::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Tue, 27 May
 2025 08:49:23 +0000
Received: from SJ5PEPF000001F6.namprd05.prod.outlook.com
 (2603:10b6:303:85:cafe::ad) by MW4PR04CA0168.outlook.office365.com
 (2603:10b6:303:85::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Tue,
 27 May 2025 08:49:23 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F6.mail.protection.outlook.com (10.167.242.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:23 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 7d9f72c5-3ad7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HQJuWyfgUcSW5EWmCEOpawdrIcmRWaw44IlnMO/acLFqL150kFStkvIyrIMzLagvVUl10uLnpWIQTFn32ShuYOgQDyZAe33JfCuaxz6rTJQuxd7mZO8bBd9gauwWnz74HE/0OAxi1AmrVrX/yo2/nlFPorJvW4TyRc9PRFrdFRfgjvyYGkNYaAqjrBo0cgZjI7ujoL8iQV6+d5sroEzVjJflUcg/7E4Vdj8Viz8dKezQhoSn6eCP+Pee3QUiMSyzqBve/T6bPWOiRn1AwS6gMkg/q6eHPSwTOEFQwWMvcVIUslWxLEQtB6Qk0+M6ukGqhH5549EmgGrTTUnJ5mLf/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=93mFFL37UWEreuoxsuCgjzGv/0KWiWMS2KGPmS4EzyY=;
 b=Br9KoLFEX/Wf5n92tFkIsK9UPqaBogzFgYYaHT96hDnb5i6woXHdvZVDLsfla56rgqeXAI0ZprEIWC9LNXh7kDMvG3aBJLFSuULob0X4WHk4UjsBj/jjxHvygWA7HqhrUJUCdfPG2AUNqaI0TPZkoNVQ1BePu8sL0dkCNHwGMRxKz/pl2xinHdE7BYhPMZsAz61Vn9Ya2tKDeO6aCu+oieNWTrCLXPoxRjbGeUFnoRKaKcS8YpUSW6Ud6VVKW5oHNkbbxAp9kDfB1ZS4eJfRaQKhnXsD/pyi194CZEKTlYY9kCRIgGPirePllVxZlowNgX3c/KeeE/TB5y6IGysUwA==
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=93mFFL37UWEreuoxsuCgjzGv/0KWiWMS2KGPmS4EzyY=;
 b=050QCEvHZcvX3U+EgOE6nmGnxThJFlGVfEqI0DwP5X6VAxIbCXFIqNDMDa/wDklWbBxFvVVMWjy2ED9s0BT7eqnJj3nJDyLiHK8VXQwUIwQc4rkyVlNefblL5qrw82rZ5O21fOE4vFJXDp29ZhThugBSBs59VgwyhYyjeRY4d/s=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	
Subject: [PATCH v5 07/18] xen/cpufreq: disable px statistic info in amd-cppc mode
Date: Tue, 27 May 2025 16:48:22 +0800
Message-ID: <20250527084833.338427-8-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F6:EE_|DS7PR12MB6240:EE_
X-MS-Office365-Filtering-Correlation-Id: 026dcc5b-e27c-48a9-f7df-08dd9cfb60d6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?1uChrA5QQCJsBrY/Lg1/t3Df+4WmQZA83uxtXmWRgue53CLw/eSRv91M6lPQ?=
 =?us-ascii?Q?dYJZ5/9f/B0gBKgMwfTHCWt5tfwSX8AwggW5Vdy4X1uWmwPXOeyZieYv3M7f?=
 =?us-ascii?Q?ZLvAsfBCihKyxIxpY6Sk090YKVJAlrMB0Lj34ib2RkupA3uBa2RB8Lw0bO4c?=
 =?us-ascii?Q?n5tKnp9WOgdoHzWfaN7mWh5dyuuif5Cx0V/xLBP9tFmixJgjIaQK++dt+x2s?=
 =?us-ascii?Q?DaquNh+yRvF5Zd1by5z4rbRAn8nWEqHU1rtTjjmr135ihmZLT6qi7axTlXkl?=
 =?us-ascii?Q?8aLZXTwnFtRYJQ1J9OEHZG2Cz24jjgeEVPGqatjdZHzCLbONY5eJcG7uqkTK?=
 =?us-ascii?Q?afEzSQEYtXFndVjP8+dEdhADxIHc4HBelYyLUUTiZOVcvDHjSriF0kuoMxuV?=
 =?us-ascii?Q?ysL6fzIrfyM3yoa5QPTkqcevBXR24EnCDCFJooQQdEx7prBJzFnJbH4jx/2p?=
 =?us-ascii?Q?YOiyDMKnU7a3DeUDAjMc8uEvOyq8SRg11ya18DL0R/xwyzLYJsTOeNY56b2Q?=
 =?us-ascii?Q?q+rlTrWV9xvCXD3i4T3dwaCfszX2v9TZe3UgnUjiR2lCG+0KDhGp/2qBtEt7?=
 =?us-ascii?Q?mucGAoTC95NLJDCW8AHKukUlqzoxnBt8rx91kfPyD/P/x89PL7Bz3w0iULos?=
 =?us-ascii?Q?MGn/LBaO5o3zPST0lah2KLhwc1WDU963+d6OTfMED/3T7/Y4AlKFnFiuF+cL?=
 =?us-ascii?Q?wnhllMEkNrSe5Hc0XsMQSNNHba5wkkLlPXE1POQt8+G3BiiZ0N0Z+YUGZOto?=
 =?us-ascii?Q?PYl1dw9GG97OYdGdjzE6gmB/Ag+RhLnPZhZFqTQhK661F+MAH48iuYfOvf51?=
 =?us-ascii?Q?LjzDILNzYQxwrZbp5mAibIL2IkbzigbNYnCdkNjcr8fAilu4AujYnqQt4s4h?=
 =?us-ascii?Q?ekGrlvjC3vBr0g6ETitfAbGRycTERhAXROkVuQQx1tmXhtzrfUa/A/JaoALe?=
 =?us-ascii?Q?alruiAZSnBNQ2A9fa7kl6VzAYg6amJTHzGvM/3GxhPqsSuSLDr3Q5lYe+DN3?=
 =?us-ascii?Q?NJnApaFMiagli234X8waQ6LUIXETsVN4z8YkwdcEQrlmfFKn1XoFZ+xYTMHn?=
 =?us-ascii?Q?ZvRGWG1zJEY5qLZ1gIPgpxOr/zqjRuhA9zGcFU2yze25J9FoMx5Nn1jtZF79?=
 =?us-ascii?Q?HRJws8nFBaRpZ5c4+UDC3NHzgJLWJXfPtQJjsUSTww67/E4y8iNH6xkU76ou?=
 =?us-ascii?Q?uEuz/p01EWnsEz7y4WZsUbMFw0VQiR9MTyGubctgBaKM1Ytq/aAvELlzWOAr?=
 =?us-ascii?Q?qKHAXzF9LW2rYyHp0IfsbvduKk+Ss/Ryh3QLCN04dieZzdPJrdYAWZTRM2fw?=
 =?us-ascii?Q?J7xCq0ivMf8W7XoyUzyMcGc2dLIK9uuQy5KaL9VBx+NUKqxMYMXYW38uawOF?=
 =?us-ascii?Q?/4QfTMNgwj9eE+kdOr7zPdx2wZS/nedSEKz89ITtfphM3G3903JSVZC+8Qil?=
 =?us-ascii?Q?/p/ERrhNGU5uzW2n36Q1JjXb9rNZzvsCN+vP2WEF8Hr93vADaeh8Rhohf+Yb?=
 =?us-ascii?Q?JQAwUi346cz4lcHHOdRtRHSM617HXGHb0oNa?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:23.0639
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 026dcc5b-e27c-48a9-f7df-08dd9cfb60d6
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F6.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6240

We want to bypass construction of px statistic info, while not bypassing
cpufreq_statistic_lock initialization for a good reason, in
cpufreq_statistic_init() for amd-cppc mode, as P-states is not necessary there.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich 
---
v3 -> v4:
- remove unnecessary stub for cpufreq_statistic_exit()
---
v4 -> v5:
- refactor commit message
---
 xen/drivers/cpufreq/utility.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index e690a484f1..b35e2eb1b6 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -98,6 +98,9 @@ int cpufreq_statistic_init(unsigned int cpu)
     if ( !pmpt )
         return -EINVAL;
 
+    if ( !(pmpt->init & XEN_PX_INIT) )
+        return 0;
+
     spin_lock(cpufreq_statistic_lock);
 
     pxpt = per_cpu(cpufreq_statistic_data, cpu);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:49:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:49:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997950.1378804 (Exim 4.92)
	(envelope-from )
	id 1uJq06-0004pR-Lc; Tue, 27 May 2025 08:49:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997950.1378804; Tue, 27 May 2025 08:49: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 1uJq06-0004pA-HZ; Tue, 27 May 2025 08:49:34 +0000
Received: by outflank-mailman (input) for mailman id 997950;
 Tue, 27 May 2025 08:49:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq05-0002ks-IU
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:33 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20602.outbound.protection.outlook.com
 [2a01:111:f403:2406::602])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7edf1484-3ad7-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:49:27 +0200 (CEST)
Received: from MW4PR04CA0111.namprd04.prod.outlook.com (2603:10b6:303:83::26)
 by SA5PPFF3CB57EDE.namprd12.prod.outlook.com
 (2603:10b6:80f:fc04::8eb) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.27; Tue, 27 May
 2025 08:49:26 +0000
Received: from SJ5PEPF000001F2.namprd05.prod.outlook.com
 (2603:10b6:303:83:cafe::4a) by MW4PR04CA0111.outlook.office365.com
 (2603:10b6:303:83::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Tue,
 27 May 2025 08:49:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F2.mail.protection.outlook.com (10.167.242.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:25 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 7edf1484-3ad7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GwoXOERUPPlwihA55ZpHz2ggry8FuEpPnVwi9HdvUVcGYEYfiBs1ZSKb2/LJjdclkjzt9Cqo8u651xvzbnrCwK4hCZKKN4z5QMIecv6VShEp3BOM2dkPVDtky5Mx6ivcroPgFqeg73qh0eqUx+k+aqdOASevopqp6Ta6+NeUT/KQtoOfukNo0cwPod9lUkw50O5bFaGUxpuR5gkAoHWpM83AEPcmj4IxoIdR0apvg9fmpe4Kggh+Uj/NgTFK4to5RabI9BWfbUmN7HcruIixbuou9tmT1uYDOfN8o4+8gS8fn3fkk8arUr4ytHzyVqkI2JeXsyPg/9yJ1kzldpDnYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SqussZlEDCnPtBb5mzZXqL0cjmGI/C8X5Nz/eBwRzwE=;
 b=qgr0J63srFFuB7XMSJySF5a4WNFEeSrNsDq6UL4n+7c6s2M5QBv6BYJ6dROVRMf+x+nErmnVMQ8ij2Ck3GeBvy0sCcbvCWLwRxst9YAvd+f44qKMDmg5aAxXoYOnMIc4n9gtew3akiNH24V6/G6LPV+p+l/iPhB961zVhhZ13eBz9Cr/OKXGp+NTTJIR+rx18FyG35ZPqq1lQ/wqbwRPUbGvCVJh1rKLIKwfRRD5/rPsDNZpikyv4QRiFFMR0g6r2x2Xl8Vap+LCanI1NuEsXe48Id7e8ymIpOkKeTEyTGNVEW4W30VCTZ8cZFIVPd20QH6o4/I4OO6YoJGtb8li9Q==
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=SqussZlEDCnPtBb5mzZXqL0cjmGI/C8X5Nz/eBwRzwE=;
 b=P5mO4zhWgXhB7jTuBFJnf7C1djQ7zx1IgFJYl16cyY81XHZjBBJs78sbSboJvqRCRGxzOUQqoBdkBd06aaY+bE/21UelU39JrzuvwW7ODTXbFiHthNNt0rS5/kSuZPuRhIL29OK128KxceQJ35Eela4qQ6JdOGT7u7I8EaJ6N8s=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 08/18] xen/cpu: Expand core frequency calculation for AMD Family 1Ah CPUs
Date: Tue, 27 May 2025 16:48:23 +0800
Message-ID: <20250527084833.338427-9-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F2:EE_|SA5PPFF3CB57EDE:EE_
X-MS-Office365-Filtering-Correlation-Id: c53ac519-4550-44db-00b0-08dd9cfb623e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?DX1FKoRp5aCZj7LmXYX31ELx7kEIWUadWj6/jNGNTvxijWJ5As9eM3Y7F4Xz?=
 =?us-ascii?Q?qDlyH/9niJKKJNJhQlx9aByzjOzUm0Nx40Ml86eoq4pA9YHmWEwtTg39OouM?=
 =?us-ascii?Q?iNR3Zg0YAv2EW7baQdVUHDTProdbnaRmuZbN00oxwiOFdq7fTE3PfgrHMLIK?=
 =?us-ascii?Q?5MESZN8un7kzyo3EmG4+/AMlWcXyCf9AJpg1bXLcp2lsXSn+ZvFAWo6xiupj?=
 =?us-ascii?Q?XI5eHRS2cpU3S95XKHyZ/sglYqAVvVaUrgKsXhJMpI1+8RU/x/m3UoCmNZKi?=
 =?us-ascii?Q?v5NSAzNL+Ah1IdWmNw065VdAcCGcKZcjv+feDtgUGRZOR2+gWWWtogDIzZYk?=
 =?us-ascii?Q?SwpbtXJK5php8mkjQS252nsuuABE1863nMd9AXrsEJTQlmi+j0+YZA2Q1o86?=
 =?us-ascii?Q?YqA8JQ7GTTSirs0oPYUh2yk4tnSkk9oN+G1JdVA7SPzBXGV7FUyg6Iu+oa54?=
 =?us-ascii?Q?DzSU0ulqbAQvliXiNcU7YNbhvm+eefu55LsJwcNtf4ptRpAKPlMrRBkyCqPm?=
 =?us-ascii?Q?r2GkOiNWSsU9JO0BfaWdP1Nu7RotboVZd0izUSXhT+QELEzZe0etBZ+UjEce?=
 =?us-ascii?Q?XdJlJqdCLtyWN3r5xQPSiT+NTPNJ9/Fl6zpEgy/EDCwDyS0D3G3YIWAxCcfb?=
 =?us-ascii?Q?/qkYCvOaxjdqYopXUxEU7q08w4ABOMGqEv2RP6wkO8+jVlqdow2JyE/9HC0e?=
 =?us-ascii?Q?ENYTgZSUE/aUDbh3ydHUulYKxa9BUGt/36Edb8v+1raUKpQXGWnmaE0dSqf6?=
 =?us-ascii?Q?KnLwiffw2B2v3l79DlUqBcYSRBMdvlJnQNrjEAl+diQd2MLRBm4AIL94SAPe?=
 =?us-ascii?Q?5X3Zx4NkWX/rTMJTHIOoykbs8I5UPh3MlTXkbMrLQzVKiHBOo7ZxQwC2oshh?=
 =?us-ascii?Q?NvBuie8CliewznvvUSke5tFPXYwA4ZAeEPy29Q3BhJDrL1FjHPw6D7VUNs9f?=
 =?us-ascii?Q?XEcWOpRDh8G9VVt4c286anA9hc3+78LgCrfp6IvLrI+skIyAzINbMg19caDk?=
 =?us-ascii?Q?UWos78+HmOv0wp14J8t0qK+BGJ6nxuBfkE/qVEALAabFx74ygioPZoBX67IO?=
 =?us-ascii?Q?W2rc2RpDr9LqTGAFNIRM7FVix/S2pu2G/dCYuNJoOP/5cme67xySTY6RWIzj?=
 =?us-ascii?Q?rj1GQjPiZyjKHiKdkzCNaLTICUW8xOwssM25YJulNEqUGXUzOjgb7aswoqKD?=
 =?us-ascii?Q?FKqjm2DANsBUv+/wUYrDRcMbKtlTpphadLVGsXvtylVgE0s58xM7cNv6ST5Q?=
 =?us-ascii?Q?Yx6qrLJbKVhShgIRswsHM2H4wS3wzlcpzZaL4ZO9sD+OSWXie2nmHtXaDnac?=
 =?us-ascii?Q?nbCANK0xpqRpPfRMAeSnqj1u8k6BXGAhRov+F8SE5hYDn/P7R/Vf7goqvDHb?=
 =?us-ascii?Q?SwSuXPe/qFQmPUWSy19ruI1XQGc/LNCGvcXbVs7qNfJeqPlUL43UNAUzyEBc?=
 =?us-ascii?Q?oy48+bSLIBiq7Z5e/BLUR5+g6F8TbQ+oAtYi8KjVPVpzGK4kh7TtU28w/Ic1?=
 =?us-ascii?Q?j6nQUg2rWlYoN7L1tTHPO19GTZ+5FHcoOkz3?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:25.4165
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c53ac519-4550-44db-00b0-08dd9cfb623e
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F2.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PPFF3CB57EDE

AMD Family 1Ah CPU needs a different COF(Core Operating Frequency) formula,
due to a change in the PStateDef MSR layout in AMD Family 1Ah.
In AMD Family 1Ah, Core current operating frequency in MHz is calculated as
follows:
    CoreCOF = Core::X86::Msr::PStateDef[CpuFid[11:0]] * 5MHz

We introduce a helper amd_parse_freq() to parse COF(Core Operating Frequency)
from PstateDef register, to replace the original macro FREQ(v).
amd_parse_freq() is declared as const, as it mainly consists of mathematical
conputation.

Signed-off-by: Penny Zheng 
---
v2 -> v3:
- new commit
---
v3 -> v4:
 - introduce amd_parse_freq() and declare it as const
 - express if-else-arry() as switch()
---
v4 -> v5:
- change title from "fix xxx" to "expand xxx"
- change function parameter type and return type to "unsigned int"
- blank lines between non-fall-through case blocks
---
 xen/arch/x86/cpu/amd.c | 49 ++++++++++++++++++++++++++++++++++--------
 1 file changed, 40 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 37d67dd15c..3770d75150 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -583,12 +583,40 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
                                                           : c->cpu_core_id);
 }
 
+static unsigned int attr_const amd_parse_freq(unsigned int family,
+					      unsigned int value)
+{
+	unsigned int freq = 0;
+
+	switch (family) {
+	case 0x10 ... 0x16:
+		freq = (((value & 0x3f) + 0x10) * 100) >> ((value >> 6) & 7);
+		break;
+
+	case 0x17 ... 0x19:
+		freq = ((value & 0xff) * 25 * 8) / ((value >> 8) & 0x3f);
+		break;
+
+	case 0x1A:
+		freq = (value & 0xfff) * 5;
+		break;
+
+	default:
+		printk(XENLOG_ERR
+		       "Unsupported cpu family 0x%x on cpufreq parsing",
+		       family);
+		break;
+	}
+
+	return freq;
+}
+
 void amd_log_freq(const struct cpuinfo_x86 *c)
 {
 	unsigned int idx = 0, h;
 	uint64_t hi, lo, val;
 
-	if (c->x86 < 0x10 || c->x86 > 0x19 ||
+	if (c->x86 < 0x10 || c->x86 > 0x1A ||
 	    (c != &boot_cpu_data &&
 	     (!opt_cpu_info || (c->apicid & (c->x86_num_siblings - 1)))))
 		return;
@@ -669,19 +697,22 @@ void amd_log_freq(const struct cpuinfo_x86 *c)
 	if (!(lo >> 63))
 		return;
 
-#define FREQ(v) (c->x86 < 0x17 ? ((((v) & 0x3f) + 0x10) * 100) >> (((v) >> 6) & 7) \
-		                     : (((v) & 0xff) * 25 * 8) / (((v) >> 8) & 0x3f))
 	if (idx && idx < h &&
 	    !rdmsr_safe(0xC0010064 + idx, val) && (val >> 63) &&
 	    !rdmsr_safe(0xC0010064, hi) && (hi >> 63))
-		printk("CPU%u: %lu (%lu ... %lu) MHz\n",
-		       smp_processor_id(), FREQ(val), FREQ(lo), FREQ(hi));
+		printk("CPU%u: %u (%u ... %u) MHz\n",
+		       smp_processor_id(),
+		       amd_parse_freq(c->x86, val),
+		       amd_parse_freq(c->x86, lo),
+		       amd_parse_freq(c->x86, hi));
 	else if (h && !rdmsr_safe(0xC0010064, hi) && (hi >> 63))
-		printk("CPU%u: %lu ... %lu MHz\n",
-		       smp_processor_id(), FREQ(lo), FREQ(hi));
+		printk("CPU%u: %u ... %u MHz\n",
+		       smp_processor_id(),
+		       amd_parse_freq(c->x86, lo),
+		       amd_parse_freq(c->x86, hi));
 	else
-		printk("CPU%u: %lu MHz\n", smp_processor_id(), FREQ(lo));
-#undef FREQ
+		printk("CPU%u: %u MHz\n", smp_processor_id(),
+		       amd_parse_freq(c->x86, lo));
 }
 
 void cf_check early_init_amd(struct cpuinfo_x86 *c)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:49:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:49:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997952.1378814 (Exim 4.92)
	(envelope-from )
	id 1uJq08-0005Ae-UU; Tue, 27 May 2025 08:49:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997952.1378814; Tue, 27 May 2025 08:49: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 1uJq08-0005AU-R0; Tue, 27 May 2025 08:49:36 +0000
Received: by outflank-mailman (input) for mailman id 997952;
 Tue, 27 May 2025 08:49:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq06-00031E-S4
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:34 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20608.outbound.protection.outlook.com
 [2a01:111:f403:2412::608])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 822d7d1a-3ad7-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 10:49:34 +0200 (CEST)
Received: from MW4PR04CA0118.namprd04.prod.outlook.com (2603:10b6:303:83::33)
 by PH7PR12MB9076.namprd12.prod.outlook.com (2603:10b6:510:2f6::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Tue, 27 May
 2025 08:49:27 +0000
Received: from SJ5PEPF000001F2.namprd05.prod.outlook.com
 (2603:10b6:303:83:cafe::e9) by MW4PR04CA0118.outlook.office365.com
 (2603:10b6:303:83::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Tue,
 27 May 2025 08:49:27 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F2.mail.protection.outlook.com (10.167.242.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:27 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 822d7d1a-3ad7-11f0-a2fd-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=urRXYl3tw+ppii7D9eVrfmRZztVCoCRuR58fL01kMrhYX8IC2XJwXG6c+sQtPlQd0RgKshAnzgwrceT6orvWs+zt6f0rZEwqZMEkNDDidf31wwL7VlZgjQnOwZjxKawbMEGFPOrL/p0aqUHhZEhIWsfrOqvne6502GCF/lonJzVOoidRF8y078ijc784Ymn/Wb5wnoZLNzUf5xQWDcALcmv/lX2Qx3noqf87b6meo6t5PboBiBgW8fy1saFN+gftiKKny0RZ6Luk7pfgGKNrFP24Hit6qB+kM88W6ULZzWuq9tvVdnFwp3zEq7tGIMYrjyVI7GkDlQ5xzLrKCPy65Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6BWhhOPQucu2ODRuY7WWAlw1Er6mBiipSyVknf/cvyA=;
 b=KZRMFERKW1dPcfjzPLA8RYdB7mEZQ3Fa3Jer5FmWIWbeEsEih1Q9/NWbwley/De0QPrBoqWDUPHOdRNd5GzTm6ahLZPiaTxhdi+wJF/x2yHxzcWZhqlNFY/HIHGDYCF6tzGg9gMuX/VEJc2x8lgIL6X/LKK8TeVHRwoOpkIM4A4m3bW7oFXf2BaR1ui7eIei+dkWayvZRojr4Em19rjzGl9FrlfxYzZLCq2j6UNck5fwlrjfUI+d98kT9POixFp9K8Q7ulKDjC7teOJPpRv1nCZMWdSRzHe+yWrwx1ktcFRoTSksy2hYBU2dJBLs0o7T56EZm2EvJr8cgzB3jhl26w==
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=6BWhhOPQucu2ODRuY7WWAlw1Er6mBiipSyVknf/cvyA=;
 b=m5lDl64Mm0RXJXvvX2cbaqx1+3gAQBxQUJjHgxE6fWR1ypsOlIb8fEUkL9htK8tlPRTBisCwsY4lmQX1byoWuUv4zeHw4hQKr2aOQf+NxC8r46ev4mEooMcr4mhBDYRZVxcb+gfOueNaplmwTjjIjT9/6Nd29a3twsDkI8gtjbw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 09/18] xen/amd: introduce amd_process_freq() to get processor frequency
Date: Tue, 27 May 2025 16:48:24 +0800
Message-ID: <20250527084833.338427-10-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F2:EE_|PH7PR12MB9076:EE_
X-MS-Office365-Filtering-Correlation-Id: 3092af6a-75ee-4d88-0e99-08dd9cfb6336
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?hAikFCHUKY9Vdc34o/wCC1vQHcedoivFVBHtZwrSkfoD6SzUfizKv14SIfKY?=
 =?us-ascii?Q?n3s0D+3O6SDwvA7VqJ1J62qQ0zqdpri6oR0Zylwy3hCP7o7Bl7xhMroa3GB/?=
 =?us-ascii?Q?4xAA3tDUq/uX0STEvtFKHITVR5Aon9JMPqFR8pn9hRzcmmkEf7Uwgmdu0264?=
 =?us-ascii?Q?bbLWdtJlRQsZsJMb7mSDh8Wq3G4ueZDmvfbQy2ctqK5RUFDgh3tXSRjfKYLI?=
 =?us-ascii?Q?3+V3NUCfbsk4SI59ykXrslF+oUnJFP3YlHoi1dPkbrzcSdkZwVckBXex1tYT?=
 =?us-ascii?Q?9MmMt77ipAsAA/CCCPlTfBQTfAJRah4lVUE72qMvN9j/fPEwM59zzsXRGW+H?=
 =?us-ascii?Q?+nBZY+C0Ab7RwdwjLMP2GEUF/AtLwdOsNqpFk6x+AK520G9mww9V+0fWX4pD?=
 =?us-ascii?Q?XuR8aDQZQ610cVv0onuNmZMH/TjIj+roig7pFKKSIgFmAxG2wDJlut37+9Rz?=
 =?us-ascii?Q?ik+IDAJClwNKEo6sWETdqcDNeE5tCaQ++VJmttKDi5ggvFoLx3RF+uK0HOF0?=
 =?us-ascii?Q?hj2gZs8JITOlBRKF6I3qZvOzdWQxfuVoDWAFIAwXszHvW2+lTMh6EpM/9bHT?=
 =?us-ascii?Q?CWGbfKFnVej5sBt979PO1dGrMRQEaPDQ2Ucicygl7r+n/8zL4hxLu4DtVmqU?=
 =?us-ascii?Q?ya9z+9kWEuPJahRH/c6q069x2m56njVsuQmpei0A+mY96YEedFgn/yEOAEZl?=
 =?us-ascii?Q?f1rSqmK6b7pJuvXFNJpO56La/FBBVtD62w/ZALCNppzvU/h6TYUwR2tmgLCl?=
 =?us-ascii?Q?jxFtbyrPtR4V4/Gw65AqqRC2IkacqQ/ZzozPI4nsejbAbqxQyXLAUMGZKceM?=
 =?us-ascii?Q?KVWiLuwUidxuTMzVsOegFNWFncS4GbHMobzyExfvE7WtCq3ZBR1uvpvPZ4In?=
 =?us-ascii?Q?dA00OO2Pd89l0KpMNbcJFZOVrTXgBoN42owe0aezo+YBYOIRsiAuyfWir9Mq?=
 =?us-ascii?Q?voFPWWyLDm/XmoMCedG4pk7+fUmvdZIJVEI5KKTEJIORLZctHhRoZeR3BfWZ?=
 =?us-ascii?Q?5jMWSQ9imDPQSUwAQTNqo3+dMb58AWr2wjZH+GR1WyenY5XH+gPgxvOUByo6?=
 =?us-ascii?Q?YhtPJDW8rWajPR/t9yfde7G7kcfFAO5FIhCpkDgcxsO5aPNdN0mS5kR3fS4d?=
 =?us-ascii?Q?mNHj5RJnSJaF8dHZ9uH3XXPhzmaFV69NsOkgnTaJmmZy3ZYK1AIxJG3UKWOP?=
 =?us-ascii?Q?ryHryK+vtKYYS0qX8y0a8KKOo7gwhG0YHHL0YdPv/XTc/xJXF+t4AavokwwN?=
 =?us-ascii?Q?uCoZRWLbbH8nT45NZDNNNM/C275dM1vzwcMANnmUIq0IYxgxxGMMo6nqUlAp?=
 =?us-ascii?Q?HNR5QOcrNKs+YOCft4uPufciNtHSGGTw+hInaV+2toOgODiZuR0moWE/xtp3?=
 =?us-ascii?Q?uG/nFsrMBNALWCaT4TZfrABJ4IrclMlWaRU133Ra0lgule7jOOS0Ceufqz4V?=
 =?us-ascii?Q?fkI6fSy3HPqWwq03B7WxP1dBiSl3IkA14jGxEz1QAI5XQmmML/arXaGNi+Gv?=
 =?us-ascii?Q?+2imevSLrtwQAAyEDQgTk2QY4/zp8r7I2O3N?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:27.0416
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3092af6a-75ee-4d88-0e99-08dd9cfb6336
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F2.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9076

When _CPC table could not provide processor frequency range
values for Xen governor, we need to read processor max frequency
as anchor point.
So we extract amd cpu core frequency calculation logic from amd_log_freq(),
and wrap it as a new helper amd_process_freq().

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- new commit
---
v3 -> v4
- introduce amd_process_freq()
---
v4 -> v5:
- make amd_process_freq() static to statisfy Misra demand
- change "low_mhz", "nom_mhz" and "hi_mhz" parameter to unsigned int
- fix order of logged frequencies
---
 xen/arch/x86/cpu/amd.c | 58 +++++++++++++++++++++++++++++-------------
 1 file changed, 40 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 3770d75150..8c985466fa 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -611,14 +611,15 @@ static unsigned int attr_const amd_parse_freq(unsigned int family,
 	return freq;
 }
 
-void amd_log_freq(const struct cpuinfo_x86 *c)
+static void amd_process_freq(const struct cpuinfo_x86 *c,
+			     unsigned int *low_mhz,
+			     unsigned int *nom_mhz,
+			     unsigned int *hi_mhz)
 {
 	unsigned int idx = 0, h;
 	uint64_t hi, lo, val;
 
-	if (c->x86 < 0x10 || c->x86 > 0x1A ||
-	    (c != &boot_cpu_data &&
-	     (!opt_cpu_info || (c->apicid & (c->x86_num_siblings - 1)))))
+	if (c->x86 < 0x10 || c->x86 > 0x1A)
 		return;
 
 	if (c->x86 < 0x17) {
@@ -699,20 +700,20 @@ void amd_log_freq(const struct cpuinfo_x86 *c)
 
 	if (idx && idx < h &&
 	    !rdmsr_safe(0xC0010064 + idx, val) && (val >> 63) &&
-	    !rdmsr_safe(0xC0010064, hi) && (hi >> 63))
-		printk("CPU%u: %u (%u ... %u) MHz\n",
-		       smp_processor_id(),
-		       amd_parse_freq(c->x86, val),
-		       amd_parse_freq(c->x86, lo),
-		       amd_parse_freq(c->x86, hi));
-	else if (h && !rdmsr_safe(0xC0010064, hi) && (hi >> 63))
-		printk("CPU%u: %u ... %u MHz\n",
-		       smp_processor_id(),
-		       amd_parse_freq(c->x86, lo),
-		       amd_parse_freq(c->x86, hi));
-	else
-		printk("CPU%u: %u MHz\n", smp_processor_id(),
-		       amd_parse_freq(c->x86, lo));
+	    !rdmsr_safe(0xC0010064, hi) && (hi >> 63)) {
+		if (nom_mhz)
+			*nom_mhz = amd_parse_freq(c->x86, val);
+		if (low_mhz)
+			*low_mhz = amd_parse_freq(c->x86, lo);
+		if (hi_mhz)
+			*hi_mhz = amd_parse_freq(c->x86, hi);
+	} else if (h && !rdmsr_safe(0xC0010064, hi) && (hi >> 63)) {
+		if (low_mhz)
+			*low_mhz = amd_parse_freq(c->x86, lo);
+		if (hi_mhz)
+			*hi_mhz = amd_parse_freq(c->x86, hi);
+	} else if (low_mhz)
+		*low_mhz = amd_parse_freq(c->x86, lo);
 }
 
 void cf_check early_init_amd(struct cpuinfo_x86 *c)
@@ -723,6 +724,27 @@ void cf_check early_init_amd(struct cpuinfo_x86 *c)
 	ctxt_switch_levelling(NULL);
 }
 
+void amd_log_freq(const struct cpuinfo_x86 *c)
+{
+	unsigned int low_mhz = 0, nom_mhz = 0, hi_mhz = 0;
+
+	if (c != &boot_cpu_data &&
+	    (!opt_cpu_info || (c->apicid & (c->x86_num_siblings - 1))))
+		return;
+
+	amd_process_freq(c, &low_mhz, &nom_mhz, &hi_mhz);
+
+	if (!low_mhz && !nom_mhz && !hi_mhz)
+		printk("CPU%u: %u (%u ... %u) MHz\n",
+		       smp_processor_id(),
+		       nom_mhz, low_mhz, hi_mhz);
+	else if (!low_mhz && !hi_mhz)
+		printk("CPU%u: %u ... %u MHz\n",
+		       smp_processor_id(), low_mhz, hi_mhz);
+	else if (!low_mhz)
+		printk("CPU%u: %u MHz\n", smp_processor_id(), low_mhz);
+}
+
 void amd_init_lfence(struct cpuinfo_x86 *c)
 {
 	uint64_t value;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:49:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:49:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997956.1378824 (Exim 4.92)
	(envelope-from )
	id 1uJq0B-0005Wj-Hq; Tue, 27 May 2025 08:49:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997956.1378824; Tue, 27 May 2025 08:49: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 1uJq0B-0005WL-B0; Tue, 27 May 2025 08:49:39 +0000
Received: by outflank-mailman (input) for mailman id 997956;
 Tue, 27 May 2025 08:49:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq0A-00031E-G9
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:38 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20626.outbound.protection.outlook.com
 [2a01:111:f403:200a::626])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 84d79d29-3ad7-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 10:49:37 +0200 (CEST)
Received: from BYAPR01CA0049.prod.exchangelabs.com (2603:10b6:a03:94::26) by
 DS0PR12MB9447.namprd12.prod.outlook.com (2603:10b6:8:1b4::20) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8769.26; Tue, 27 May 2025 08:49:30 +0000
Received: from SJ5PEPF000001F7.namprd05.prod.outlook.com
 (2603:10b6:a03:94:cafe::9d) by BYAPR01CA0049.outlook.office365.com
 (2603:10b6:a03:94::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Tue,
 27 May 2025 08:49:41 +0000
Received: from SATLEXMB04.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_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:29 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 84d79d29-3ad7-11f0-a2fd-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ML3pp4+qWYfy++A+Xm0dOw62UoeZ7ZfJHn/PjWAJjUGK0zRMBy5tENHumA77BlRLZGhv97Uhn2Qgis02zgay9ub1T3SOAV7iWBzEzRrhPNcQ15FLbFBZXE5ZE92Qh73vcuuT0iec4KjCKTxR5yO02Dcp2C6tinwDTQXVIhcZz0hUzS7VuF9Hxz4VL17avKO6Ogt6rpuE48ixap0eAWSZF4GdfvKXYhOsBVteZq3sEITeythCvXACyrSH8+S8QG8qauLWBVFHv/KshshKmtYa/dc2YfmL+YPPxMOyyXlv8ycDHMeqUTfETuTGBxgTJqJXByaIgsmv+YTckxn5qs6juA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ok2GRvrOFV+vUIk3LP8uwsuOY7g8Xv1FP+QzlfgdZtc=;
 b=vkeSpLsCtf/e0UN4b/WyTzKWEzjOucFUe7gLsIxor9BOK7yN+mJTM9TSui9ZDLjPnhWWHEzdEmANo8r86sfbAKRVBH9L+0mDosnUdHNxXMDTBQ/v+3ltc9zkKLLa3s9pKZugS+E4K+T33zY7/h2Sa31pDukyCjLvLMGVwfkvy8Qu5cA+fmsju2TXGz7Gy99A4pge7YquHFlUCv6l7Qfthoc1W74rKyj+qkrnDc1UrejffiRDlWaVOlKZCvzhTcesM7zmUXe2adZozwGMJZRpYnl54NLsHViAo0S0u84rJV9pSu96NwEZREMajxmqLMliw/maXPTrWZu8vaujHamI0g==
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=ok2GRvrOFV+vUIk3LP8uwsuOY7g8Xv1FP+QzlfgdZtc=;
 b=dYpZTQbMinkpSVBp9LWL4eZCuEHU7Bab5wrS1fGnYG4zU4rnIyjegmYkT01XG3fpDmn0iabpviK+cpBLM6mFtaLHrBwGktmj+6P6MYNzIe/tglpTfFwARHMFC7C+MkkWiw2nr68CU4XVEvt5ujuYfskJkpGzG+3juSckEnO5fFQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v5 10/18] xen/cpufreq: introduce a new amd cppc driver for cpufreq scaling
Date: Tue, 27 May 2025 16:48:25 +0800
Message-ID: <20250527084833.338427-11-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F7:EE_|DS0PR12MB9447:EE_
X-MS-Office365-Filtering-Correlation-Id: 3a3dfeaa-d45d-4af4-3e34-08dd9cfb6496
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cHdsZEs5QzlFUGN3TU9BWlJIb0MxYWhHQ2VIaUc5b0FSWGFud1ZxcWIvTDFC?=
 =?utf-8?B?bmxkdUhaNWFZa0JnWUk0Sm1aUEw3eld0TlpvWmtVdkJ5NHJVT090cFhpZEZ2?=
 =?utf-8?B?cXVVeWx6NmsyWno1dnRqYnFVbGVwbDZMdTVTVDFTYTVNU2wwV0FhVmsra0tx?=
 =?utf-8?B?T2s5eTR4QzBnbTlFemFYNFNBd3RwN3hQSW1KNUZTUUJKK1BwSzF5ZEFjckdx?=
 =?utf-8?B?bFFDeE1BN0dBNDlxeGdZclNDK0xXL1luVzFuVzQ0Q3M3bnFYdUIxcExrZWkv?=
 =?utf-8?B?QU9CYTdjZU5HUHB4NThVUSt1MisyZzRxa29YQ2txd3JqTnZsbWZMYTdEbGFn?=
 =?utf-8?B?S3J3aFpvRERVVHJ0cGRXeHZaR1NhRUY3UkdudjNEUUZCL3N5R0E4U1ZxRS9F?=
 =?utf-8?B?MU5UR1ZlTlE2UndZNk5xSEpwcDVycVh0RC9vazU3WUhYUEhRNUZHUEUwa0Y2?=
 =?utf-8?B?UTM1b20wdGovWUNnbTJpb2ozcVdkbkRYQy9GNTJ5UXlyWXU3Zk1kY3ZBSnRF?=
 =?utf-8?B?ZURPbVhSTGpuYlpzaUttc0ZENjZMeWdKaWRkM2hyREtUOURlcEl2T3dHR3Rq?=
 =?utf-8?B?ZWhlUHk4NnhRTGRCd1dNUkdmSE5rQ2kzcWQ2dEJsdVRReWY5Q2k3Sjh3MzNz?=
 =?utf-8?B?WHlKZVQvdlNNQ2RDdWRXb1pKbHVHd1hBWXM3ZlZDUVhsRjZ2ODVIMzFDZmpx?=
 =?utf-8?B?enAvcjFhaW5PbkZJd0JqYWN1akQvVDRRQ3FDMVBDU3dFem5RcTFTakZuV2c5?=
 =?utf-8?B?K2ppb2dRZk05RHU3eWIxbEJoYkIxMUs5UzdKMlNMNzZUSzhJQUk4MGVBZXBa?=
 =?utf-8?B?Y0ljUjBBcGYvM1l1aGJvVHRCdTFGM3R6NGpScXBRWGJOQ1lJUlZBSExFMGph?=
 =?utf-8?B?bDFFbjBKYVk4bHN5anh5b1B2cGIrdm9jUEN4TFhrb0Y4Q25SYWNXSkFBY0dS?=
 =?utf-8?B?RytuV01Xc0NycFVMWVhxVk5qTzg4NnR5TCs4a3l4c1pmS3JrZnJVUkNNaGlM?=
 =?utf-8?B?U3BMdUJVMVN5bWJ2YXVIUVhGOVluVWQxNjY1Qk15RmFQRFJReDFrTGlQUVIr?=
 =?utf-8?B?ZUEydkpnM25vRS9rMzhjdFpxU1EyNm5OWU1Bb09HRDc4NzVYR09FLzVMTGl1?=
 =?utf-8?B?ZERpR3JZU2NlaURFR3hqeFpWWGUxdndjUjQyS1R5cnpqaHg4QlowMTY2UDAy?=
 =?utf-8?B?ZG9IeVMvS21CaHFjbFMvYnZrZlRnVkp1b09xSFBDSDBCYXZuMjVlZFYxKzMy?=
 =?utf-8?B?N1BMak1Ub05kc0tRVjRadHhLR2NId1JMVS9rZU1uZDBYeTErKzE0RUNrVFVs?=
 =?utf-8?B?Q3BFWGlVTU8xbmx5MjdKb2hQUTN5SVhmMjdGVktpNVVaTHM2WU92eG9BQ2FM?=
 =?utf-8?B?aS9sZjkrbS9FcDZFWmtCZWFrR3gvZkxpWm5HNmdqZXZyTnFXWTEwZkhsVWZi?=
 =?utf-8?B?Sm0vYjZwZjYzZm1ZNXpFbnB5aTJOUGtOa0svZWxlZVk0UjRkSmxlWDd5THNR?=
 =?utf-8?B?MEJKZzNyNDd6UG54eGdSd1lWN1lKbHFhcmZyNzRJZ0dGb1hRVzJjMGF1SWxy?=
 =?utf-8?B?Vmc4T0ZiNkZLMXpKQ0EwK2s1YnVtZmp5Q1A5UWI4OTZEUHZlNkJCZk1udkxQ?=
 =?utf-8?B?eUlqZ1RXOXdURjZmVkZ0VmRmTE12dkpFczIzdDNGSGxBODBtK2Z0MEtSWjJq?=
 =?utf-8?B?NVc2TDNwYjdXeVZKYkRDc3dxNnBsTy9jSDJrNlcxUFIzQ1FHUmovVEt3d25j?=
 =?utf-8?B?TG5tWWdMYy9vTkx2cC9GSmNOY0tVNk9VZTlCdk5qVVh1QUZmemxFYlNhN1ZK?=
 =?utf-8?B?NFBhaDdGUEo0cGxXc3NwRVlLZzRzRHFQQ3BQV01Yc292d2ZTaEZLakdGQ1FC?=
 =?utf-8?B?RUpWdVhPTEExakNKR2JHbjRTcTl6ajNCend0YkVOZGNETlRNU0ZnaE02ZFVt?=
 =?utf-8?B?TVpsT053S3hISHUwejhFWFlkaWFSamVGb3ZYb2haMFpLdXRNbEMyQVAwNVpT?=
 =?utf-8?B?TmRZV2RKd0ZickdFd2xNd3FvU1pvSnBSaUh6YjE4eXhsZE5nd3RJcU9BQWRi?=
 =?utf-8?Q?FLhUov?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:29.3512
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a3dfeaa-d45d-4af4-3e34-08dd9cfb6496
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=[SATLEXMB04.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: DS0PR12MB9447

amd-cppc is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism. The new mechanism is based on
Collaborative Processor Performance Control (CPPC) which is a finer grain
frequency management than legacy ACPI hardware P-States.
Current AMD CPU platforms are using the ACPI P-states driver to
manage CPU frequency and clocks with switching only in 3 P-states, while the
new amd-cppc allows a more flexible, low-latency interface for Xen
to directly communicate the performance hints to hardware.

Default "amd-cppc" driver still leverages Xen governors such as
*ondemand*, *performance*, etc, to calculate the performance hints. In the
future, we will introduce an advanced active mode to enable autonomous
performence level selection.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- re-construct union caps and req to have anonymous struct instead
- avoid "else" when the earlier if() ends in an unconditional control flow statement
- Add check to avoid chopping off set bits from cast
- make pointers pointer-to-const wherever possible
- remove noisy log
- exclude families before 0x17 before CPPC-feature MSR op
- remove useless variable helpers
- use xvzalloc and XVFREE
- refactor error handling as ENABLE bit can only be cleared by reset
---
v2 -> v3:
- Move all MSR-definations to msr-index.h and follow the required style
- Refactor opening figure braces for struct/union
- Sort overlong lines throughout the series
- Make offset/res int covering underflow scenario
- Error out when amd_max_freq_mhz isn't set
- Introduce amd_get_freq(name) macro to decrease redundancy
- Supported CPU family checked ahead of smp-function
- Nominal freq shall be checked between the [min, max]
- Use APERF/MPREF to calculate current frequency
- Use amd_cppc_cpufreq_cpu_exit() to tidy error path
---
v3 -> v4:
- verbose print shall come with a CPU number
- deal with res <= 0 in amd_cppc_khz_to_perf()
- introduce a single helper amd_get_lowest_or_nominal_freq() to cover both
lowest and nominal scenario
- reduce abuse of wrmsr_safe()/rdmsr_safe() with wrmsrl()/rdmsrl()
- move cf_check from amd_cppc_write_request() to amd_cppc_write_request_msrs()
- add comment to explain why setting non_linear_lowest in passive mode
- add check to ensure perf values in
lowest <= non_linear_lowest <= nominal <= highset
- refactor comment for "data->err != 0" scenario
- use "data->err" instead of -ENODEV
- add U suffixes for all msr macro
---
v4 -> v5:
- all freq-values shall be unsigned int type
- remove shortcuts as it is rarely taken
- checking cpc.nominal_mhz and cpc.lowest_mhz are non-zero values is enough
- drop the explicit type cast
- null pointer check is in no need for internal functions
- change amd_get_lowest_or_nominal_freq() to amd_get_cpc_freq()
- clarifying function-wide that the calculated frequency result is to be in kHz
- use array notation
- with cpu_has_cppc check, no need to do cpu family check
---
 xen/arch/x86/acpi/cpufreq/amd-cppc.c | 362 +++++++++++++++++++++++++++
 xen/arch/x86/cpu/amd.c               |   8 +-
 xen/arch/x86/include/asm/amd.h       |   2 +
 xen/arch/x86/include/asm/msr-index.h |   5 +
 4 files changed, 373 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/acpi/cpufreq/amd-cppc.c b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
index 9e64bf957a..8f0a30c19d 100644
--- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
+++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
@@ -14,7 +14,56 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
+
+#define amd_cppc_err(cpu, fmt, args...)                             \
+    printk(XENLOG_ERR "AMD_CPPC: CPU%u error: " fmt, cpu, ## args)
+#define amd_cppc_warn(cpu, fmt, args...)                            \
+    printk(XENLOG_WARNING "AMD_CPPC: CPU%u warning: " fmt, cpu, ## args)
+#define amd_cppc_verbose(cpu, fmt, args...)                         \
+({                                                                  \
+    if ( cpufreq_verbose )                                          \
+        printk(XENLOG_DEBUG "AMD_CPPC: CPU%u " fmt, cpu, ## args);  \
+})
+
+struct amd_cppc_drv_data
+{
+    const struct xen_processor_cppc *cppc_data;
+    union {
+        uint64_t raw;
+        struct {
+            unsigned int lowest_perf:8;
+            unsigned int lowest_nonlinear_perf:8;
+            unsigned int nominal_perf:8;
+            unsigned int highest_perf:8;
+            unsigned int :32;
+        };
+    } caps;
+    union {
+        uint64_t raw;
+        struct {
+            unsigned int max_perf:8;
+            unsigned int min_perf:8;
+            unsigned int des_perf:8;
+            unsigned int epp:8;
+            unsigned int :32;
+        };
+    } req;
+
+    int err;
+};
+
+static DEFINE_PER_CPU_READ_MOSTLY(struct amd_cppc_drv_data *,
+                                  amd_cppc_drv_data);
+/*
+ * Core max frequency read from PstateDef as anchor point
+ * for freq-to-perf transition
+ */
+static DEFINE_PER_CPU_READ_MOSTLY(unsigned int, pxfreq_mhz);
 
 static bool __init amd_cppc_handle_option(const char *s, const char *end)
 {
@@ -50,10 +99,323 @@ int __init amd_cppc_cmdline_parse(const char *s, const char *e)
     return 0;
 }
 
+/*
+ * If CPPC lowest_freq and nominal_freq registers are exposed then we can
+ * use them to convert perf to freq and vice versa. The conversion is
+ * extrapolated as an linear function passing by the 2 points:
+ *  - (Low perf, Low freq)
+ *  - (Nominal perf, Nominal freq)
+ * Parameter freq is always in kHz.
+ */
+static int amd_cppc_khz_to_perf(const struct amd_cppc_drv_data *data,
+                                unsigned int freq, uint8_t *perf)
+{
+    const struct xen_processor_cppc *cppc_data = data->cppc_data;
+    unsigned int mul, div;
+    int offset = 0, res;
+
+    if ( cppc_data->cpc.lowest_mhz && cppc_data->cpc.nominal_mhz )
+    {
+        mul = data->caps.nominal_perf - data->caps.lowest_perf;
+        div = cppc_data->cpc.nominal_mhz - cppc_data->cpc.lowest_mhz;
+
+        /*
+         * We don't need to convert to kHz for computing offset and can
+         * directly use nominal_mhz and lowest_mhz as the division
+         * will remove the frequency unit.
+         */
+        offset = data->caps.nominal_perf -
+                 (mul * cppc_data->cpc.nominal_mhz) / div;
+    }
+    else
+    {
+        /* Read Processor Max Speed(MHz) as anchor point */
+        mul = data->caps.highest_perf;
+        div = this_cpu(pxfreq_mhz);
+        if ( !div )
+            return -EINVAL;
+    }
+
+    res = offset + (mul * freq) / (div * 1000);
+    if ( res > UINT8_MAX )
+    {
+        printk_once(XENLOG_WARNING
+                    "Perf value exceeds maximum value 255: %d\n", res);
+        *perf = 0xff;
+        return 0;
+    }
+    if ( res < 0 )
+    {
+        printk_once(XENLOG_WARNING
+                    "Perf value smaller than minimum value 0: %d\n", res);
+        *perf = 0;
+        return 0;
+    }
+    *perf = res;
+
+    return 0;
+}
+
+/*
+ * _CPC may define nominal frequecy and lowest frequency, if not, use
+ * Processor Max Speed as anchor point to calculate.
+ * Output freq stores cpc frequency in kHz
+ */
+static int amd_get_cpc_freq(const struct amd_cppc_drv_data *data,
+                            uint32_t cpc_mhz, uint8_t perf, unsigned int *freq)
+{
+    unsigned int mul, div, res;
+
+    if ( cpc_mhz )
+    {
+        /* Switch to kHz */
+        *freq = cpc_mhz * 1000;
+        return 0;
+    }
+
+    /* Read Processor Max Speed(MHz) as anchor point */
+    mul = this_cpu(pxfreq_mhz);
+    if ( !mul )
+    {
+        printk_once(XENLOG_ERR
+                    "Failed to read valid processor max frequency as anchor point: %u\n",
+                    mul);
+        return -EINVAL;
+    }
+    div = data->caps.highest_perf;
+    res = (mul * perf * 1000) / div;
+    if ( !res )
+        return -EINVAL;
+    *freq = res;
+
+    return 0;
+}
+
+/* Output max_freq stores calculated maximum frequency in kHz */
+static int amd_get_max_freq(const struct amd_cppc_drv_data *data,
+                            unsigned int *max_freq)
+{
+    unsigned int nom_freq = 0;
+    int res;
+
+    res = amd_get_cpc_freq(data, data->cppc_data->cpc.nominal_mhz,
+                           data->caps.nominal_perf, &nom_freq);
+    if ( res )
+        return res;
+
+    *max_freq = (data->caps.highest_perf * nom_freq) / data->caps.nominal_perf;
+
+    return 0;
+}
+
+static int cf_check amd_cppc_cpufreq_verify(struct cpufreq_policy *policy)
+{
+    cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
+                                 policy->cpuinfo.max_freq);
+
+    return 0;
+}
+
+static void cf_check amd_cppc_write_request_msrs(void *info)
+{
+    const struct amd_cppc_drv_data *data = info;
+
+    wrmsrl(MSR_AMD_CPPC_REQ, data->req.raw);
+}
+
+static void amd_cppc_write_request(unsigned int cpu, uint8_t min_perf,
+                                   uint8_t des_perf, uint8_t max_perf)
+{
+    struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data, cpu);
+    uint64_t prev = data->req.raw;
+
+    data->req.min_perf = min_perf;
+    data->req.max_perf = max_perf;
+    data->req.des_perf = des_perf;
+
+    if ( prev == data->req.raw )
+        return;
+
+    on_selected_cpus(cpumask_of(cpu), amd_cppc_write_request_msrs, data, 1);
+}
+
+static int cf_check amd_cppc_cpufreq_target(struct cpufreq_policy *policy,
+                                            unsigned int target_freq,
+                                            unsigned int relation)
+{
+    unsigned int cpu = policy->cpu;
+    const struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data, cpu);
+    uint8_t des_perf;
+    int res;
+
+    if ( unlikely(!target_freq) )
+        return 0;
+
+    res = amd_cppc_khz_to_perf(data, target_freq, &des_perf);
+    if ( res )
+        return res;
+
+    /*
+     * Setting with "lowest_nonlinear_perf" to ensure governoring
+     * performance in P-state range.
+     */
+    amd_cppc_write_request(policy->cpu, data->caps.lowest_nonlinear_perf,
+                           des_perf, data->caps.highest_perf);
+    return 0;
+}
+
+static void cf_check amd_cppc_init_msrs(void *info)
+{
+    struct cpufreq_policy *policy = info;
+    struct amd_cppc_drv_data *data = this_cpu(amd_cppc_drv_data);
+    uint64_t val;
+    unsigned int min_freq = 0, nominal_freq = 0, max_freq;
+
+    /* Package level MSR */
+    rdmsrl(MSR_AMD_CPPC_ENABLE, val);
+    /*
+     * Only when Enable bit is on, the hardware will calculate the processor’s
+     * performance capabilities and initialize the performance level fields in
+     * the CPPC capability registers.
+     */
+    if ( !(val & AMD_CPPC_ENABLE) )
+    {
+        val |= AMD_CPPC_ENABLE;
+        wrmsrl(MSR_AMD_CPPC_ENABLE, val);
+    }
+
+    rdmsrl(MSR_AMD_CPPC_CAP1, data->caps.raw);
+
+    if ( data->caps.highest_perf == 0 || data->caps.lowest_perf == 0 ||
+         data->caps.nominal_perf == 0 || data->caps.lowest_nonlinear_perf == 0 ||
+         data->caps.lowest_perf > data->caps.nominal_perf ||
+         data->caps.lowest_nonlinear_perf > data->caps.nominal_perf ||
+         data->caps.nominal_perf > data->caps.highest_perf )
+    {
+        amd_cppc_err(policy->cpu,
+                     "Out of range values: highest(%u), lowest(%u), nominal(%u), lowest_nonlinear(%u)\n",
+                     data->caps.highest_perf, data->caps.lowest_perf,
+                     data->caps.nominal_perf, data->caps.lowest_nonlinear_perf);
+        goto err;
+    }
+
+    amd_process_freq(&cpu_data[policy->cpu],
+                     NULL, NULL, &this_cpu(pxfreq_mhz));
+
+    data->err = amd_get_cpc_freq(data, data->cppc_data->cpc.lowest_mhz,
+                                 data->caps.lowest_perf, &min_freq);
+    if ( data->err )
+        return;
+
+    data->err = amd_get_cpc_freq(data, data->cppc_data->cpc.nominal_mhz,
+                                 data->caps.nominal_perf, &nominal_freq);
+    if ( data->err )
+        return;
+
+    data->err = amd_get_max_freq(data, &max_freq);
+    if ( data->err )
+        return;
+
+    if ( min_freq > nominal_freq || nominal_freq > max_freq )
+    {
+        amd_cppc_err(policy->cpu,
+                     "min(%u), or max(%u), or nominal(%u) freq value is incorrect\n",
+                     min_freq, max_freq, nominal_freq);
+        goto err;
+    }
+
+    policy->min = min_freq;
+    policy->max = max_freq;
+
+    policy->cpuinfo.min_freq = min_freq;
+    policy->cpuinfo.max_freq = max_freq;
+    policy->cpuinfo.perf_freq = nominal_freq;
+    /*
+     * Set after policy->cpuinfo.perf_freq, as we are taking
+     * APERF/MPERF average frequency as current frequency.
+     */
+    policy->cur = cpufreq_driver_getavg(policy->cpu, GOV_GETAVG);
+
+    return;
+
+ err:
+    /*
+     * No fallback shceme is available here, see more explanation at call
+     * site in amd_cppc_cpufreq_cpu_init().
+     */
+    data->err = -EINVAL;
+}
+
+/*
+ * AMD CPPC driver is different than legacy ACPI hardware P-State,
+ * which has a finer grain frequency range between the highest and lowest
+ * frequency. And boost frequency is actually the frequency which is mapped on
+ * highest performance ratio. The legacy P0 frequency is actually mapped on
+ * nominal performance ratio.
+ */
+static void amd_cppc_boost_init(struct cpufreq_policy *policy,
+                                const struct amd_cppc_drv_data *data)
+{
+    if ( data->caps.highest_perf <= data->caps.nominal_perf )
+        return;
+
+    policy->turbo = CPUFREQ_TURBO_ENABLED;
+}
+
+static int cf_check amd_cppc_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+{
+    XVFREE(per_cpu(amd_cppc_drv_data, policy->cpu));
+
+    return 0;
+}
+
+static int cf_check amd_cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+    unsigned int cpu = policy->cpu;
+    struct amd_cppc_drv_data *data;
+
+    data = xvzalloc(struct amd_cppc_drv_data);
+    if ( !data )
+        return -ENOMEM;
+
+    data->cppc_data = &processor_pminfo[cpu]->cppc_data;
+
+    per_cpu(amd_cppc_drv_data, cpu) = data;
+
+    on_selected_cpus(cpumask_of(cpu), amd_cppc_init_msrs, policy, 1);
+
+    /*
+     * The enable bit is sticky, as we need to enable it at the very first
+     * begining, before CPPC capability values sanity check.
+     * If error path takes effective, not only amd-cppc cpufreq core fails
+     * to initialize, but also we could not fall back to legacy P-states
+     * driver, irrespective of the command line specifying a fallback option.
+     */
+    if ( data->err )
+    {
+        amd_cppc_err(cpu, "Could not initialize cpufreq cores in CPPC mode\n");
+        amd_cppc_cpufreq_cpu_exit(policy);
+        return data->err;
+    }
+
+    policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR;
+
+    amd_cppc_boost_init(policy, data);
+
+    amd_cppc_verbose(policy->cpu,
+                     "CPU initialized with amd-cppc passive mode\n");
+
+    return 0;
+}
+
 static const struct cpufreq_driver __initconst_cf_clobber
 amd_cppc_cpufreq_driver =
 {
     .name   = XEN_AMD_CPPC_DRIVER_NAME,
+    .verify = amd_cppc_cpufreq_verify,
+    .target = amd_cppc_cpufreq_target,
+    .init   = amd_cppc_cpufreq_cpu_init,
+    .exit   = amd_cppc_cpufreq_cpu_exit,
 };
 
 int __init amd_cppc_register_driver(void)
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 8c985466fa..7ec154e9e7 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -611,10 +611,10 @@ static unsigned int attr_const amd_parse_freq(unsigned int family,
 	return freq;
 }
 
-static void amd_process_freq(const struct cpuinfo_x86 *c,
-			     unsigned int *low_mhz,
-			     unsigned int *nom_mhz,
-			     unsigned int *hi_mhz)
+void amd_process_freq(const struct cpuinfo_x86 *c,
+		      unsigned int *low_mhz,
+		      unsigned int *nom_mhz,
+		      unsigned int *hi_mhz)
 {
 	unsigned int idx = 0, h;
 	uint64_t hi, lo, val;
diff --git a/xen/arch/x86/include/asm/amd.h b/xen/arch/x86/include/asm/amd.h
index 9c9599a622..72df42a6f6 100644
--- a/xen/arch/x86/include/asm/amd.h
+++ b/xen/arch/x86/include/asm/amd.h
@@ -173,5 +173,7 @@ extern bool amd_virt_spec_ctrl;
 bool amd_setup_legacy_ssbd(void);
 void amd_set_legacy_ssbd(bool enable);
 void amd_set_cpuid_user_dis(bool enable);
+void amd_process_freq(const struct cpuinfo_x86 *c, unsigned int *low_mhz,
+                      unsigned int *nom_mhz, unsigned int *hi_mhz);
 
 #endif /* __AMD_H__ */
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 22d9e76e55..e4401186c7 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -238,6 +238,11 @@
 
 #define MSR_AMD_CSTATE_CFG                  0xc0010296U
 
+#define MSR_AMD_CPPC_CAP1                   0xc00102b0U
+#define MSR_AMD_CPPC_ENABLE                 0xc00102b1U
+#define  AMD_CPPC_ENABLE                    (_AC(1, ULL) << 0)
+#define MSR_AMD_CPPC_REQ                    0xc00102b3U
+
 /*
  * Legacy MSR constants in need of cleanup.  No new MSRs below this comment.
  */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:50:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:50:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997984.1378833 (Exim 4.92)
	(envelope-from )
	id 1uJq17-0000k5-RO; Tue, 27 May 2025 08:50:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997984.1378833; Tue, 27 May 2025 08:50: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 1uJq17-0000ju-Oe; Tue, 27 May 2025 08:50:37 +0000
Received: by outflank-mailman (input) for mailman id 997984;
 Tue, 27 May 2025 08:50:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq0L-0002ks-Da
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:49 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20606.outbound.protection.outlook.com
 [2a01:111:f403:2416::606])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 89004f6a-3ad7-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:49:44 +0200 (CEST)
Received: from SJ2PR07CA0015.namprd07.prod.outlook.com (2603:10b6:a03:505::28)
 by DS5PPF78FC67EBA.namprd12.prod.outlook.com (2603:10b6:f:fc00::655)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.33; Tue, 27 May
 2025 08:49:43 +0000
Received: from SJ5PEPF000001F1.namprd05.prod.outlook.com
 (2603:10b6:a03:505:cafe::e9) by SJ2PR07CA0015.outlook.office365.com
 (2603:10b6:a03:505::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Tue,
 27 May 2025 08:49:43 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F1.mail.protection.outlook.com (10.167.242.69) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:42 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 89004f6a-3ad7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QdBXsxIG/ci/tcVUBdtGlKDzQXfQ0Nk902E9Z9iuRTQ6mfIXzk4iJ2MaB9ivPUmw4UtCRjj7TKEj8ZMbTQrR5zOvPcfqc21oUk9rfROEpD/sh7jTOgW+dH9ht2BgQW7RMVIaEWFonkM6e70Sdbud8485/PcGBJCb1Z2wYDT/ffkrvKnGOghcLivaRDBPwgf3VeoXkGM9jKjHjoVp7+365GkZOqWXU5yszVtKycQMT1FrAso8mbzpPILLSW8NUx/9kxt/bFL3cV/XFBy4xOmpgJX9QcS5yLHOs/e0lbll9MQutGUir0eUyZQmOxUmRYOh8aMzB1PNx20NId0pzz8hAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=L3Tn87xWwjj3VP5ECGhcDNI0MAhylxGbzcaSKHPCXC4=;
 b=AxTMKWgFoLFEDzYz+REysTjcdYUoahqHgcmLOU9L7KlyhGopmHyX1F7oW2EjIBIErNzUk9/E8N0zZcivoRHPlozVwt44SCS13RD+1xf3e4lTaDPpTlxaFTGHl3uXiQHjDEwbSOuWzdbjrV4SJbuSR5nQ3aexijM+vwKBjTnfeMUlLivLEXXYzM8ofB8HMg2gbgoEFpt4t6DIRKtFowSqtGK2KEV3lHlSa0HC1xADlnnVSaXbW22kflbWH/DrbnRhoTl3ISPRe5kqS8aL8+VOvVx5UH4KZhwODQ6K/oCZQpAkwfliAowXsBGFqZIUR8u0iobJZJqzSC4GrNj5mjfMfA==
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=L3Tn87xWwjj3VP5ECGhcDNI0MAhylxGbzcaSKHPCXC4=;
 b=0DkIXM1MkreuXk1OjEXtElaRcls6k8D7uKfM2N4YhRWCAih7RnpsRDriIfdz+1iZz9BejeEZILNjjPQ2l1Mv9e3fqprHoESbTgnkppkmRsXU0LS2Ph5kaxe5l6MDIi/Dde4Vb9jJIgJbRZ72l/XjoLVKDcMcXngtuCPUnKeXbFA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Anthony PERARD
	
Subject: [PATCH v5 17/18] tools: optimize cpufreq average freq print
Date: Tue, 27 May 2025 16:48:32 +0800
Message-ID: <20250527084833.338427-18-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F1:EE_|DS5PPF78FC67EBA:EE_
X-MS-Office365-Filtering-Correlation-Id: 2daf20f8-ab1a-4be8-b8d6-08dd9cfb6caf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?ZW6qtrRa5F1TVvmHcRjpCB1LV5hy+A/PYfTgi7NoUMKyf7UDRDAc98CfXHMp?=
 =?us-ascii?Q?d8NO1asPptPNr53VxEX5QmBCzxCfTCepfchGR/+ksQBLRDVXrOLp2WzTGVZ1?=
 =?us-ascii?Q?youdddWJSam+NuO8N2Oqs4xtnWwhlpPC8q+l/CTHFaP0puAOAAKO6ujT3GlI?=
 =?us-ascii?Q?fN8ag4bv2fWUPsoQBFaDUFBnuq7CPxMQoaNqvPYdwy8WPEPk3TUwtP94A+4B?=
 =?us-ascii?Q?18NT+IP1KSCVZXuNBXwkeHtnh2sLL/iFQY5f5SMFp/MmyaRya2GBptQhmpnR?=
 =?us-ascii?Q?OpNa8iFHTDp+nglu9RIch4wB96Quhd2klIQiXoNeIPSCjM7Pd5HB01y1fsQ0?=
 =?us-ascii?Q?5BwUHprcA85KYlWNH53wiFwKrLfAGLk4ZpHpcNsB9XHfMzer+lELeA1wWK9P?=
 =?us-ascii?Q?NOqf5jFN/G8+mf0RNgyjnF9ImTgzfQucOa3T8REnWTld+uAeCPv0fTDL3cYv?=
 =?us-ascii?Q?1o4rA8uAc69cBirvJ5Oy+LZm+IeDNZQenLrb88WW0MIHfOIuvdphqaxFr/Rc?=
 =?us-ascii?Q?2NOw6BAgdJOAoZ4yaw/bhdILL7BP3UrKSxRGJHk6La+3QcFo1l6tUitZzPw/?=
 =?us-ascii?Q?1u0Aofu7D9NAUshO+vS3sfhN4SvwzUvIQ2dL7XWkKVhtkj59+Oa8b7QxfVy9?=
 =?us-ascii?Q?7Y9RuFOpiRH/sNu40JeMp2rKy/vqEJ7cNfJWyEN4gsYZfVH/THQwwX4dP0fM?=
 =?us-ascii?Q?rXYGVjxbgT86dl76RI5msJ1V+KD2mRIkZrbhqR5/GJAeodfI/RQuYxDDUGu0?=
 =?us-ascii?Q?fVLOMjP1wFPyQEMTOyZVYKQa/7ye6ReAlM+6PwBvhlhPnpXLIcIrscsSShSl?=
 =?us-ascii?Q?AcE32ix4g5HAcvONcswWXXp2fiSEdtuAxefkAgQuKf7uWcHOlbfQ48KqLaXc?=
 =?us-ascii?Q?wMDU5/93tZ185dJF5ULMpHIku5MfL/HeJObGxXO+eqNj64DapzxzXKbbcMjF?=
 =?us-ascii?Q?gMLc9qZyU6MFemRwwnRQzzuAYvIgyoybkNYcUosiXzQth8J55ECrYeyRbzYR?=
 =?us-ascii?Q?s7nMo+9NjtdXRA4biICzAKh5EhZ0jVpgmJJrwWU/b5bw+fSViXEv4r12Vp+7?=
 =?us-ascii?Q?8yMpFnXX3IMqm39aKPAVp1I+aRj2N9I0JBsxxOFxOuUMfLadwVi42H1p7FMc?=
 =?us-ascii?Q?IRDAP1kC24Umog5xbj4gt8yrGd77I+Jj4xayUURrkxWwkheBA7S8ncmgp1/o?=
 =?us-ascii?Q?EezpZ9gRPe3bgXv8pILqmkw6EygX4XMmozjKNLojCGixNp2LNjVBxFMJ+/r0?=
 =?us-ascii?Q?3ERnbSxM+Fwn7e1rXgZn1Hbmxt0qnnLecNZRkBAUaOhZBUXD+0qmMn1H2am+?=
 =?us-ascii?Q?WSBjE1hN5UZL26yTG0kaXAcnGNX3xLgCqV+Ti6Jv7+JkZN2VkKGLsG8Lp8iV?=
 =?us-ascii?Q?mDflazH65B1t1XCAjqirklJpXHmQeKdLq+EOUksiOKyvjCJjPs+3gqhVnB3A?=
 =?us-ascii?Q?CtnFabfc4MtiLQJP3JzcMUrGaZEBOLWL4Uno9azVaW7i7syVDAfeKVxZ4VcV?=
 =?us-ascii?Q?xpmm5mcbZ/uWXZ5dg7Row9qHBsXLTJoTJqra?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:42.9399
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2daf20f8-ab1a-4be8-b8d6-08dd9cfb6caf
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPF78FC67EBA

Unlike Cx/Px states, for which we need an extra loop to summerize residency (
sum_cx[]/sum_px[]), we could call get_avgfreq_by_cpuid() right before printing.
Also, with introduction of CPPC mode, average frequency print shall
not depend on the existence of legacy P-states, so we remove "px_cap"
dependancy check.

Fixes: add6160d7 (Add cpufreq actual average freq information to xenpm tools)
Signed-off-by: Penny Zheng 
---
v3 -> v4:
- new commit
---
v4 -> v5:
- refactor title and commit message
- call get_avgfreq_by_cpuid() right before printing
---
 tools/misc/xenpm.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index f173e598ea..2864506da4 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -497,9 +497,6 @@ static void signal_int_handler(int signo)
                                  pxstat_start[i].pt[j].residency;
     }
 
-    for ( i = 0; i < max_cpu_nr; i++ )
-        get_avgfreq_by_cpuid(xc_handle, i, &avgfreq[i]);
-
     printf("Elapsed time (ms): %"PRIu64"\n", (usec_end - usec_start) / 1000UL);
     for ( i = 0; i < max_cpu_nr; i++ )
     {
@@ -540,7 +537,8 @@ static void signal_int_handler(int signo)
                         res / 1000000UL, 100UL * res / (double)sum_px[i]);
             }
         }
-        if ( px_cap && avgfreq[i] )
+        get_avgfreq_by_cpuid(xc_handle, i, &avgfreq[i]);
+        if ( avgfreq[i] )
             printf("  Avg freq\t%d\tKHz\n", avgfreq[i]);
     }
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:50:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:50:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997991.1378843 (Exim 4.92)
	(envelope-from )
	id 1uJq1B-000162-80; Tue, 27 May 2025 08:50:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997991.1378843; Tue, 27 May 2025 08:50: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 1uJq1B-00015q-4Q; Tue, 27 May 2025 08:50:41 +0000
Received: by outflank-mailman (input) for mailman id 997991;
 Tue, 27 May 2025 08:50:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq0I-00031E-I6
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:46 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20619.outbound.protection.outlook.com
 [2a01:111:f403:2418::619])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 88161911-3ad7-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 10:49:43 +0200 (CEST)
Received: from BY5PR20CA0015.namprd20.prod.outlook.com (2603:10b6:a03:1f4::28)
 by BY5PR12MB4114.namprd12.prod.outlook.com (2603:10b6:a03:20c::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Tue, 27 May
 2025 08:49:38 +0000
Received: from SJ5PEPF000001F4.namprd05.prod.outlook.com
 (2603:10b6:a03:1f4:cafe::63) by BY5PR20CA0015.outlook.office365.com
 (2603:10b6:a03:1f4::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.40 via Frontend Transport; Tue,
 27 May 2025 08:49:38 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F4.mail.protection.outlook.com (10.167.242.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:38 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 88161911-3ad7-11f0-a2fd-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LcIAPpNUuK1QalVq1OlHwlte4hKmqDq/eECqk4QxjrMsvrQnR39m41ZtWvW0HJ0UaM6u0mq4tVgyzbIOpeVM7WcPRfrQ/l5CIwbFPjjyHNchZ9g9n85WmO+yVr91Xp2btsCH131n47NcKChWrYRHoQ8rtS8JVenRNN9kuw9wI3dzOmJF4fUfKcMQooCj2iLAnwuQmgVlvsqBAY0ikq5CflMyqWQeJCfROtfl7UjJqcXUkHdQJYgHGJtjYJRq18L2d5/bihT9pv4+WZoAJmSiGwPDI0L5trZdX/vRm7HC9iROsUiq9QOnS4dtC2VJOLr6LVb6MzzKPQ7zN0p0RjKNlg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vXUlUm4d0wql5IcMZNTgxdbV0uwQON7fY64Zus5RrVI=;
 b=MwCaYnyTtXjkcu4Z3cFGmVXVyU8+XQrbddqLbzbF+1HrymDhP6ZCOVbt1XgRvIyX97e2/yg4nbs4qEaTUpkktrMLyreZRvuc3WYPVnaUpw6FVsgg1lapOcauhadsm9V+lFLJ9Eil5ASla+pdgZybc6iihaDqii5NQUeHU+K0LUgtP/nTHy6Fzmzy/AKANgW9mCnFgAtlpCVXvRwvwPRB9VD13MeENdtQGa0kviyJzMm9N+/+p3boNwHbkFqLpwZWkxvZhSx21w0swegQBdRoZlJoyl1PE6d1TDViUEnhh7RdGGYRGZhHAHNboSMNBTmXw+MVpvSGOgGV4fFd4ReWwA==
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=vXUlUm4d0wql5IcMZNTgxdbV0uwQON7fY64Zus5RrVI=;
 b=IZd6nmDq5+g9M50YTUTxQ+dWFNTAlHHXBwmOaNkXHM5w9pZvuIqDYrs0plYdDGx9pjalQ3sfObCKqSuT8N8YCYq0FSfAQXUbFrzz/vR8g8eYtHWPPo9qn2hCkP8yXM7Iv89qmcR5UUHBvkfokDXDJ+nIp6mY8wY6M8OHpL3mD5U=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Anthony PERARD
	, Juergen Gross , Andrew Cooper
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" 
Subject: [PATCH v5 14/18] xen/cpufreq: introduce GET_CPUFREQ_CPPC sub-cmd
Date: Tue, 27 May 2025 16:48:29 +0800
Message-ID: <20250527084833.338427-15-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F4:EE_|BY5PR12MB4114:EE_
X-MS-Office365-Filtering-Correlation-Id: 03ad8595-4bea-4ada-6b23-08dd9cfb69d9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?8c7J9+mnkKg15xE0pNV5pCkQM7W+XTe96cIrUWyPDC0nu6zGGX44DLXJG71b?=
 =?us-ascii?Q?sFJOfNGwENCiAtQd6wyv+hq9cfwLV2Hai9pHb5peWulMtrE5JCvsD5DwXeBk?=
 =?us-ascii?Q?mEh3GSPUlTxo6zLc84R8n2mSuuWX18YHkowCmChXdY7/wlortpm++/E05vl4?=
 =?us-ascii?Q?+h4PGK9UOFBKpWHWPIZqBPEmRWaPmFa7vZLYFv9Dw1FZFTYgpEwNuWwambia?=
 =?us-ascii?Q?EmC9X9wUl7rjk/TIsRUdV4LTC31lJigw5HNEdf6YwlaEdi1RLRtWCB/zP3hl?=
 =?us-ascii?Q?HiDiBb6y4CcQFCKB7+KErxYrAaTrji61n7BEKnSqKKkoBqTZeAxGkRP0EKu7?=
 =?us-ascii?Q?gosxLG/fJV5oC7NbFzGA8R3io9Q3bQvaO0fVPInyP5nJGNn9HygeA67O2Ep5?=
 =?us-ascii?Q?2cDGipVjqVeg68E4Hu0c6DqFHe+mOiHhndI5XtvKfHpN01VqGJEo+5YYSji4?=
 =?us-ascii?Q?S5V8rDKsnQR4aJDoVEkK7f5Jo2RxdlM8duRxijwBZXLHXhSYyowImJA312YN?=
 =?us-ascii?Q?BmVJiwIfy4p85Ju2IlOwsBSNxEB6nES3tH1Qmn1IDIT8pUrXsmA+uIrsSP6B?=
 =?us-ascii?Q?2JAnuIeBZ16pPtObybwWlx7Fo7NKa6FrIc7wRETMcg7jkFYoiT9r4s533pfu?=
 =?us-ascii?Q?ZkyUOj/GKDVzDGjDZl2s0m8+rlP+uh/aKKm7L2KbKnAkk5KvXgO4lwO380QB?=
 =?us-ascii?Q?vIgCJ63dUMx0WkFWO15VklrRFID2ku6eztvT/UdL6MSciAxQtNTDoR+rCWq2?=
 =?us-ascii?Q?nc/tAUlULZ7msTEm9XATNGxgQ2cQuTiY03FD0Ajq4ZyuNIkW89vbuoBlrSKN?=
 =?us-ascii?Q?bdCwC1Di6+PiamdfsXJ0C5ByEG5kZPK8dZ+QeIBgwS1I/maHxEylTKTwcKTk?=
 =?us-ascii?Q?/bW/M4DHJqS5m4w9Xw2cPxosu6tbbsF/rmn/c1BM+ya9xZfeb11WToWZ5j/N?=
 =?us-ascii?Q?yaBd4DeE62GETo6SmjBo5PFZULkk6OViL/OT3o1cD5MgOsmgfd3qq5WUpn7k?=
 =?us-ascii?Q?Ox617eUBsIq2fk3Mmc4uFUFzJUDq+DKpw8ezrKyGudR9QRqJvaNLQEDHuY8b?=
 =?us-ascii?Q?BGcTCLaWNYU5S40rr6HMTOri2fYOYE1WyeNoDgSZvJ9LhSY9irPP8BnagvZ5?=
 =?us-ascii?Q?+7xcQxIHIz98uYsrpiaClAYslyCwBw/Xn5TMqhL6w39EKt8RGeoGkXsrooae?=
 =?us-ascii?Q?rlRG4BvyHCzZySe54lgkV6CwyYaXahGImfl6Q2qJffC1ZHPsLk6sZ5uXFmEl?=
 =?us-ascii?Q?BVAz6aoo6LgNVJC2YiMoWPZX1wEnu+r7oK67suVZyfoMOUiB9ks/Us/sn1B/?=
 =?us-ascii?Q?6VSUeH2xOPolRPBlQBn08T7mtGykGZug90GvuufagHFg4p5iLQOAtq01BnXE?=
 =?us-ascii?Q?5whtv5GhzKXeJ/fJyZQ4l3vMh0UpSBVPlXBrTJR/K+O96JspIwXcfMBFAfBy?=
 =?us-ascii?Q?aue4aAoR4f8DJs/cqE56Kzw/ikdR1C9SIW4EwBxAqyEPlIaZBN6n/AQU/XrZ?=
 =?us-ascii?Q?VWKNaJ+79Ys9RSrbDUNKarRZGEtVUoNvtPtW?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:38.1797
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 03ad8595-4bea-4ada-6b23-08dd9cfb69d9
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F4.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4114

In amd-cppc passive mode, it's Xen governor which is responsible for
performance tuning, so governor and CPPC could co-exist. That is, both
governor-info and CPPC-info could be printed together via xenpm tool.

To achieve that, "struct xen_cppc_para" needs to be moved out of the union
and also "struct xen_get_cpufreq_para". Also if still putting it in
"struct xen_get_cpufreq_para" (e.g. just move out of union),
"struct xen_get_cpufreq_para" will enlarge too much to further make
xen_sysctl.u exceed 128 bytes.
We introduce a new sub-cmd GET_CPUFREQ_CPPC to specifically print
CPPC-related para and clear cppc print in GET_CPUFREQ_PARA.

Signed-off-by: Penny Zheng 
---
v4 -> v5:
- new commit
---
 tools/include/xenctrl.h     |  3 +-
 tools/libs/ctrl/xc_pm.c     | 28 ++++++++++-
 tools/misc/xenpm.c          | 97 ++++++++++++++++++++++++++-----------
 xen/drivers/acpi/pmstat.c   | 18 +++++--
 xen/include/public/sysctl.h |  3 +-
 5 files changed, 116 insertions(+), 33 deletions(-)

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 4955981231..79523d2d73 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -1938,7 +1938,6 @@ struct xc_get_cpufreq_para {
                 xc_ondemand_t ondemand;
             } u;
         } s;
-        xc_cppc_para_t cppc_para;
     } u;
 
     int32_t turbo_enabled;
@@ -1953,6 +1952,8 @@ int xc_set_cpufreq_para(xc_interface *xch, int cpuid,
                         int ctrl_type, int ctrl_value);
 int xc_set_cpufreq_cppc(xc_interface *xch, int cpuid,
                         xc_set_cppc_para_t *set_cppc);
+int xc_get_cppc_para(xc_interface *xch, unsigned int cpuid,
+                     xc_cppc_para_t *cppc_para);
 int xc_get_cpufreq_avgfreq(xc_interface *xch, int cpuid, int *avg_freq);
 
 int xc_set_sched_opt_smt(xc_interface *xch, uint32_t value);
diff --git a/tools/libs/ctrl/xc_pm.c b/tools/libs/ctrl/xc_pm.c
index ff7b5ada05..3c9e272aee 100644
--- a/tools/libs/ctrl/xc_pm.c
+++ b/tools/libs/ctrl/xc_pm.c
@@ -289,7 +289,6 @@ int xc_get_cpufreq_para(xc_interface *xch, int cpuid,
         CHK_FIELD(s.scaling_min_freq);
         CHK_FIELD(s.u.userspace);
         CHK_FIELD(s.u.ondemand);
-        CHK_FIELD(cppc_para);
 
 #undef CHK_FIELD
 
@@ -367,6 +366,33 @@ int xc_set_cpufreq_cppc(xc_interface *xch, int cpuid,
     return ret;
 }
 
+int xc_get_cppc_para(xc_interface *xch, unsigned int cpuid,
+                     xc_cppc_para_t *cppc_para)
+{
+    int ret;
+    struct xen_sysctl sysctl = {};
+    struct xen_cppc_para *sys_cppc_para = &sysctl.u.pm_op.u.cppc_para;
+
+    if ( !xch  || !cppc_para )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    sysctl.cmd = XEN_SYSCTL_pm_op;
+    sysctl.u.pm_op.cmd = GET_CPUFREQ_CPPC;
+    sysctl.u.pm_op.cpuid = cpuid;
+
+    ret = xc_sysctl(xch, &sysctl);
+    if ( ret )
+        return ret;
+
+    BUILD_BUG_ON(sizeof(*cppc_para) != sizeof(*sys_cppc_para));
+    memcpy(cppc_para, sys_cppc_para, sizeof(*sys_cppc_para));
+
+    return ret;
+}
+
 int xc_get_cpufreq_avgfreq(xc_interface *xch, int cpuid, int *avg_freq)
 {
     int ret = 0;
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index db658ebadd..2a87f7ae8a 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -69,6 +69,7 @@ void show_help(void)
             " set-max-cstate        |'unlimited' [|'unlimited']\n"
             "                                     set the C-State limitation ( >= 0) and\n"
             "                                     optionally the C-sub-state limitation ( >= 0)\n"
+            " get-cpufreq-cppc      [cpuid]       list cpu cppc parameter of CPU  or all\n"
             " set-cpufreq-cppc      [cpuid] [balance|performance|powersave] *\n"
             "                                     set Hardware P-State (HWP) parameters\n"
             "                                     on CPU  or all if omitted.\n"
@@ -812,33 +813,7 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
 
     printf("scaling_driver       : %s\n", p_cpufreq->scaling_driver);
 
-    if ( hwp )
-    {
-        const xc_cppc_para_t *cppc = &p_cpufreq->u.cppc_para;
-
-        printf("cppc variables       :\n");
-        printf("  hardware limits    : lowest [%"PRIu32"] lowest nonlinear [%"PRIu32"]\n",
-               cppc->lowest, cppc->lowest_nonlinear);
-        printf("                     : nominal [%"PRIu32"] highest [%"PRIu32"]\n",
-               cppc->nominal, cppc->highest);
-        printf("  configured limits  : min [%"PRIu32"] max [%"PRIu32"] energy perf [%"PRIu32"]\n",
-               cppc->minimum, cppc->maximum, cppc->energy_perf);
-
-        if ( cppc->features & XEN_SYSCTL_CPPC_FEAT_ACT_WINDOW )
-        {
-            unsigned int activity_window;
-            const char *units;
-
-            activity_window = calculate_activity_window(cppc, &units);
-            printf("                     : activity_window [%"PRIu32" %s]\n",
-                   activity_window, units);
-        }
-
-        printf("                     : desired [%"PRIu32"%s]\n",
-               cppc->desired,
-               cppc->desired ? "" : " hw autonomous");
-    }
-    else
+    if ( !hwp )
     {
         if ( p_cpufreq->gov_num )
             printf("scaling_avail_gov    : %s\n",
@@ -981,6 +956,73 @@ void cpufreq_para_func(int argc, char *argv[])
         show_cpufreq_para_by_cpuid(xc_handle, cpuid);
 }
 
+/* print out parameters about cpu cppc */
+static void print_cppc_para(unsigned int cpuid,
+                            const xc_cppc_para_t *cppc)
+{
+    printf("cpu id               : %u\n", cpuid);
+    printf("cppc variables       :\n");
+    printf("  hardware limits    : lowest [%"PRIu32"] lowest nonlinear [%"PRIu32"]\n",
+           cppc->lowest, cppc->lowest_nonlinear);
+    printf("                     : nominal [%"PRIu32"] highest [%"PRIu32"]\n",
+           cppc->nominal, cppc->highest);
+    printf("  configured limits  : min [%"PRIu32"] max [%"PRIu32"] energy perf [%"PRIu32"]\n",
+           cppc->minimum, cppc->maximum, cppc->energy_perf);
+
+    if ( cppc->features & XEN_SYSCTL_CPPC_FEAT_ACT_WINDOW )
+    {
+        unsigned int activity_window;
+        const char *units;
+
+        activity_window = calculate_activity_window(cppc, &units);
+        printf("                     : activity_window [%"PRIu32" %s]\n",
+               activity_window, units);
+    }
+
+    printf("                     : desired [%"PRIu32"%s]\n",
+           cppc->desired,
+           cppc->desired ? "" : " hw autonomous");
+    printf("\n");
+}
+
+/* show cpu cppc parameters information on CPU cpuid */
+static int show_cppc_para_by_cpuid(xc_interface *xc_handle, unsigned int cpuid)
+{
+    int ret;
+    xc_cppc_para_t cppc_para;
+
+    ret = xc_get_cppc_para(xc_handle, cpuid, &cppc_para);
+    if ( ret == 0 )
+        print_cppc_para(cpuid, &cppc_para);
+    else if ( errno == ENODEV )
+    {
+        ret = -ENODEV;
+        fprintf(stderr, "CPPC is not available!\n");
+    }
+    else
+        fprintf(stderr, "[CPU%u] failed to get cppc parameter\n", cpuid);
+
+    return ret;
+}
+
+static void cppc_para_func(int argc, char *argv[])
+{
+    int cpuid = -1;
+
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpuid);
+
+    if ( cpuid < 0 )
+    {
+        /* show cpu cppc information on all cpus */
+        for ( unsigned int i = 0; i < max_cpu_nr; i++ )
+            if ( show_cppc_para_by_cpuid(xc_handle, i) == -ENODEV )
+                break;
+    }
+    else
+        show_cppc_para_by_cpuid(xc_handle, cpuid);
+}
+
 void scaling_max_freq_func(int argc, char *argv[])
 {
     int cpuid = -1, freq = -1;
@@ -1561,6 +1603,7 @@ struct {
     { "get-cpufreq-average", cpufreq_func },
     { "start", start_gather_func },
     { "get-cpufreq-para", cpufreq_para_func },
+    { "get-cpufreq-cppc", cppc_para_func },
     { "set-cpufreq-cppc", cppc_set_func },
     { "set-scaling-maxfreq", scaling_max_freq_func },
     { "set-scaling-minfreq", scaling_min_freq_func },
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index c09e001ec3..6e9178ade1 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -253,9 +253,7 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
     else
         strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
 
-    if ( hwp_active() )
-        ret = get_hwp_para(policy->cpu, &op->u.get_para.u.cppc_para);
-    else
+    if ( !hwp_active() )
     {
         if ( !(scaling_available_governors =
                xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) )
@@ -328,6 +326,16 @@ static int set_cpufreq_gov(struct xen_sysctl_pm_op *op)
     return __cpufreq_set_policy(old_policy, &new_policy);
 }
 
+static int get_cpufreq_cppc(struct xen_sysctl_pm_op *op)
+{
+    int ret = -ENODEV;
+
+    if ( hwp_active() )
+        ret = get_hwp_para(op->cpuid, &op->u.cppc_para);
+
+    return ret;
+}
+
 static int set_cpufreq_para(struct xen_sysctl_pm_op *op)
 {
     int ret = 0;
@@ -498,6 +506,10 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
         break;
     }
 
+    case GET_CPUFREQ_CPPC:
+        ret = get_cpufreq_cppc(op);
+        break;
+
     case SET_CPUFREQ_CPPC:
         ret = set_cpufreq_cppc(op);
         break;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index fa431fd983..29872fe508 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -462,7 +462,6 @@ struct xen_get_cpufreq_para {
                 struct  xen_ondemand ondemand;
             } u;
         } s;
-        struct xen_cppc_para cppc_para;
     } u;
 
     int32_t turbo_enabled;
@@ -493,6 +492,7 @@ struct xen_sysctl_pm_op {
     #define SET_CPUFREQ_PARA           (CPUFREQ_PARA | 0x03)
     #define GET_CPUFREQ_AVGFREQ        (CPUFREQ_PARA | 0x04)
     #define SET_CPUFREQ_CPPC           (CPUFREQ_PARA | 0x05)
+    #define GET_CPUFREQ_CPPC           (CPUFREQ_PARA | 0x06)
 
     /* set/reset scheduler power saving option */
     #define XEN_SYSCTL_pm_op_set_sched_opt_smt    0x21
@@ -517,6 +517,7 @@ struct xen_sysctl_pm_op {
     uint32_t cpuid;
     union {
         struct xen_get_cpufreq_para get_para;
+        struct xen_cppc_para        cppc_para;
         struct xen_set_cpufreq_gov  set_gov;
         struct xen_set_cpufreq_para set_para;
         struct xen_set_cppc_para    set_cppc;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:50:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:50:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997995.1378849 (Exim 4.92)
	(envelope-from )
	id 1uJq1B-00019v-K5; Tue, 27 May 2025 08:50:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997995.1378849; Tue, 27 May 2025 08:50: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 1uJq1B-00018q-F2; Tue, 27 May 2025 08:50:41 +0000
Received: by outflank-mailman (input) for mailman id 997995;
 Tue, 27 May 2025 08:50:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq0K-00031E-IQ
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:48 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2414::60e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 89819fbc-3ad7-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 10:49:45 +0200 (CEST)
Received: from SJ0PR13CA0107.namprd13.prod.outlook.com (2603:10b6:a03:2c5::22)
 by SJ0PR12MB8167.namprd12.prod.outlook.com (2603:10b6:a03:4e6::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.24; Tue, 27 May
 2025 08:49:40 +0000
Received: from SJ5PEPF000001F0.namprd05.prod.outlook.com
 (2603:10b6:a03:2c5:cafe::2c) by SJ0PR13CA0107.outlook.office365.com
 (2603:10b6:a03:2c5::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.17 via Frontend Transport; Tue,
 27 May 2025 08:49:40 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F0.mail.protection.outlook.com (10.167.242.68) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:39 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 89819fbc-3ad7-11f0-a2fd-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fzDbpWQJVSD4gE9YS0S0YmAsgQ8CzVZAO8+e4G1tkMFNEqJB/89XmUO3ZIc0WpbQZ7b4WMH5hOc4ypy9RcUDUnaJhgep4eTGIx6fooI/s/DYRtIeQWKwAvN235LoMPdu8ZuYD1ePiZH5jMO/W35n951ay49AUK4IP3xMMPRy10Njkw67zV1U7SkJ84g9AKFecsJttTbcvS2aIAvSc26MZqEMO1wD93qBIBXTFEBXmt5+41Z2F2mqkZBljTpsgNhvR9Fndk7lhRvEfsxBC4hVI4hnjLa9Xet6kTGDJHDsqYQKqrU+WzUGPtNdeHw6OYE4+t2DlHLsAOYLGVRtEElwhQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LB3Mek026fWNFIQDzjs+lsqQvvJxYv/q/FC2PzT8yzo=;
 b=lG3361jcMkvWKaOkdb2QtqSKiER5QMpapQTai4qbdpz2zlPk18z2TDiFgjp82i9McnaYBJVYuxb+P0neZan3LdUKf6obaZhlOB/JwV8CnZVNMky/VxUHlJB13bR3O2hG7Ar3V0DitR2tKGh1/QI26CMsyxwDVHR/TTub06d+Z/Iv9rxg4LGdHTG3U+zd2XN1zWl1wH/SFi9s6NUQoGg1SKQXJI49KmKeCcvuPY2ujClduFygQ5blzc4FlOVEvEsxMsWtLWBEiMcPO8FtIoMFAgqJvoIgG2ZsZpDdF03u4a9nJVbbML9jeJXGrDiuD+9q6slhzin7YYg8UazJgjZnOw==
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=LB3Mek026fWNFIQDzjs+lsqQvvJxYv/q/FC2PzT8yzo=;
 b=qGiyCVmKplWh10jNH06VD4UXfNk8iz7c3yHWiiaKtmhWCVXyI8eCbZ3Pi8FsZam4eavidll487O1cHep76B5bOW8NSPb7X3+kxweWjO4v2Hc/yXTkOAIgLzrjn5Af9EOlrgB7sbLAE7W0EQlwKhiiOTck7va8ckbBzuRuv0NF5Y=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Anthony PERARD
	, Jan Beulich 
Subject: [PATCH v5 15/18] xen/cpufreq: bypass governor-related para for amd-cppc-epp
Date: Tue, 27 May 2025 16:48:30 +0800
Message-ID: <20250527084833.338427-16-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F0:EE_|SJ0PR12MB8167:EE_
X-MS-Office365-Filtering-Correlation-Id: 58ac84a1-a730-4625-3add-08dd9cfb6ae0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?KWrDju3zLvhxBHu6z8VU0Rb3L32I4qpoaWVC3RH8B2TD311+zaz5KZnVzqKX?=
 =?us-ascii?Q?6TyvBqKOfN42qAnrKzbBaZiTQcqLNUbl98ZggyTFRtiMiAf3h88hSraTEGkZ?=
 =?us-ascii?Q?kzmPxCbcodd4F5oRD5+So2ZReN5gP4sHysm5V+Pwm0sbnwIpX4evKC0ldP2E?=
 =?us-ascii?Q?BhqMt0yuggdXKI8MOtufNpp6EVlvKo4cvnTUn8wfGk+UcMkvYovMCUB6w5Go?=
 =?us-ascii?Q?A8SQ1yV2XAOAd4+17W97LHOwwVM0ZAYvKOZ/1vaIYCOa3dIFCc2NvFWNPKuv?=
 =?us-ascii?Q?+OoYES5Il9GZD87boPJ2Il6a6GDHh9aZLucP3V7tSVA1U4rtsr9uoLJPQDcH?=
 =?us-ascii?Q?pj15NcMQ80r1Lckh5zmBXQeNown//nSTPfjPZ6Q5RmNlq8T+376fodOQLcFd?=
 =?us-ascii?Q?JV8L29T0Z8reKdcmupe0cXEqivYxoeHgU1tWNpKN5VdCgziL9JwEaVDveZ/1?=
 =?us-ascii?Q?GAiLEdaE72pn64Z/RuDMVZ+LFfOWQSgXHQ7L2flxyovkG6VqU4wkSKC1qCRL?=
 =?us-ascii?Q?puC5w770raY8uIDIvNzQBa7aMRUO/dugYsrD8VO7vEm+Wr/6lxw29XDrAE0n?=
 =?us-ascii?Q?XVC1ooaWgIZcQBtZAlACDGL7ZcoDAffiRj1xDMkNRXv3LEmD9JehRE7YKJU8?=
 =?us-ascii?Q?YDqN/032uYZWVf7WgfDqeEXzuj/pEPbF491cNd+XuXOHmyTirHVrm230MiV5?=
 =?us-ascii?Q?/QV8ojF4xJ3IK7nca9+wueOg6vPJFIDuAzNby8O3qnqCI4JZTfxj0GrFQWSp?=
 =?us-ascii?Q?wdnnUzSvd/irPb5aRk979Zfezl+1WoeJ0kI9dm+Y5yRCMxRtbhSdQ8a114DI?=
 =?us-ascii?Q?iBlb9OJfjr1vr7Sw2k68L991GR3bnPb8UtLu1en6vmJRWzU88N8YisYUKVa9?=
 =?us-ascii?Q?jNyfamQ3XpSOYygn+d1trAZTUwLsGHjlZUcURTwpZ4yTjaVPq8gG7sIrKwB/?=
 =?us-ascii?Q?lSVvBNBSGGoIx/NFSE28796i4iYDmdvttrwJfVGtUP/G1TqilJr1mkd2efzT?=
 =?us-ascii?Q?sBX8tUzFbKCu83n4jGf7yFi7fhjvRkJELVlMC5pvqwexbREt4sTpvY6Beb/r?=
 =?us-ascii?Q?yur/Rf+YxxTFg+usB1pIE25POVb1RqgWLce1Q6uCDZCLhnFfJqigiw0f9zzU?=
 =?us-ascii?Q?jn5l9PzSvjEpym3FP/KQ3m3pnuC1WH++RsQgO3wP92wUMOFTyc4DgANHDAfe?=
 =?us-ascii?Q?MOC5b2LCU/qU98/HueEs1/s1uJBDsXbiw6XSt3UJMHI3fPa5PxWXQBZPlio6?=
 =?us-ascii?Q?hgzt58kf1ZrPCgPxv6OW74Qm7ifFrLZ8EIh9wEWZi9/mRahu/9IV+uSy2Qxc?=
 =?us-ascii?Q?y2sQrT86Weko9K5xKH5SVxHyvjj/85hwvgJ9whuP6CGfExa+FCyUy/PpBKUM?=
 =?us-ascii?Q?RUIuBTf3k22ewibph0rLClnhWdEgXZMQzw2vaxdlaEyr64TTgNNkhadZ+kZz?=
 =?us-ascii?Q?quf+uFNkabrUnchGpB0i6euwdCfvjypsWWpEbXn3y371SieYSnbBrRdrEJla?=
 =?us-ascii?Q?x9BBhf/dcEl5PAzkNrjDa649Ni8Map5c2IYe?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:39.9018
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 58ac84a1-a730-4625-3add-08dd9cfb6ae0
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB8167

HWP and amd-cppc-epp are both governor-less driver,
so we introduce "hw_auto" flag to together bypass governor-related print in
print_cpufreq_para().

In get/set_cpufreq_para(), we are adding "cpufreq_driver.setpolicy == NULL"
check to exclude governor-related para for amd-cppc-epp driver.

Signed-off-by: Penny Zheng 
---
v3 -> v4:
- Include validation check fix here
---
v4 -> v5:
- validation check has beem moved to where XEN_PROCESSOR_PM_CPPC and
XEN_CPPC_INIT have been firstly introduced
- adding "cpufreq_driver.setpolicy == NULL" check to exclude governor-related
para for amd-cppc-epp driver in get/set_cpufreq_para()
---
 tools/misc/xenpm.c        | 10 +++++++---
 xen/drivers/acpi/pmstat.c |  6 ++++--
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 2a87f7ae8a..f173e598ea 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -791,9 +791,13 @@ static unsigned int calculate_activity_window(const xc_cppc_para_t *cppc,
 /* print out parameters about cpu frequency */
 static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
 {
-    bool hwp = strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) == 0;
+    bool hw_auto = false;
     int i;
 
+    if ( !strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) ||
+         !strcmp(p_cpufreq->scaling_driver, XEN_AMD_CPPC_EPP_DRIVER_NAME) )
+        hw_auto = true;
+
     printf("cpu id               : %d\n", cpuid);
 
     printf("affected_cpus        :");
@@ -801,7 +805,7 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
         printf(" %d", p_cpufreq->affected_cpus[i]);
     printf("\n");
 
-    if ( hwp )
+    if ( hw_auto )
         printf("cpuinfo frequency    : base [%"PRIu32"] max [%"PRIu32"]\n",
                p_cpufreq->cpuinfo_min_freq,
                p_cpufreq->cpuinfo_max_freq);
@@ -813,7 +817,7 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq)
 
     printf("scaling_driver       : %s\n", p_cpufreq->scaling_driver);
 
-    if ( !hwp )
+    if ( !hw_auto )
     {
         if ( p_cpufreq->gov_num )
             printf("scaling_avail_gov    : %s\n",
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index 6e9178ade1..e5f375921a 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -253,7 +253,8 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
     else
         strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
 
-    if ( !hwp_active() )
+    /* bypass hwp and amd-cppc-epp driver */
+    if ( !hwp_active() && cpufreq_driver.setpolicy == NULL )
     {
         if ( !(scaling_available_governors =
                xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) )
@@ -346,7 +347,8 @@ static int set_cpufreq_para(struct xen_sysctl_pm_op *op)
     if ( !policy || !policy->governor )
         return -EINVAL;
 
-    if ( hwp_active() )
+    /* bypass hwp and amd-cppc-epp driver */
+    if ( hwp_active() || cpufreq_driver.setpolicy == NULL )
         return -EOPNOTSUPP;
 
     switch(op->u.set_para.ctrl_type)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:50:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:50:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.997997.1378856 (Exim 4.92)
	(envelope-from )
	id 1uJq1C-0001Jp-9d; Tue, 27 May 2025 08:50:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 997997.1378856; Tue, 27 May 2025 08:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJq1C-0001I1-0q; Tue, 27 May 2025 08:50:42 +0000
Received: by outflank-mailman (input) for mailman id 997997;
 Tue, 27 May 2025 08:50:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq0S-00031E-Jl
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:56 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20605.outbound.protection.outlook.com
 [2a01:111:f403:2413::605])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8ca97f44-3ad7-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 10:49:51 +0200 (CEST)
Received: from SJ0PR13CA0091.namprd13.prod.outlook.com (2603:10b6:a03:2c5::6)
 by LV2PR12MB5895.namprd12.prod.outlook.com (2603:10b6:408:173::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Tue, 27 May
 2025 08:49:46 +0000
Received: from SJ5PEPF000001F0.namprd05.prod.outlook.com
 (2603:10b6:a03:2c5:cafe::ff) by SJ0PR13CA0091.outlook.office365.com
 (2603:10b6:a03:2c5::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.15 via Frontend Transport; Tue,
 27 May 2025 08:49:46 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F0.mail.protection.outlook.com (10.167.242.68) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:46 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 8ca97f44-3ad7-11f0-a2fd-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TuZcWS5V+RmzS9kND5IYgH0rJyLGTHgREl4FY+qUXgHREHBCJZ9+wiRKTeu6flOv6hRONa37VxAurf2ao6S2wolbkBLFIBWfi5qvPhXSZNqufnqF5XViW5EYFL7Qsb6PpY3s6Fpzb1xVNGate5c91MA3lW561yLMmzfIdTlMoBoU0cuVOAvdJjlLB6MYxBBi6NjxD4N/P9RTQWmoFdvhRfu0bqMUZFVnY8OPF3En2jT+OaF07owiHaes2Hk5wzsN+keIBpTn1VvABV5xlnrtRMWw3IFvq47l9EozhY0z9KwNA3NCoFlCuslsoJv6/fswjvBzwFSpP2K4/RDmok7ZSA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qDagGZO2RtNskUq1QiXQkXAONydlZKUYORV/JjISAuM=;
 b=kd2ePY798t00IyIm96Hv/EuN7xhKPxYpGC+aB6fXA+xKLHAqXjPQPhwO8qYDmM8F3UxxWdFyEAJpurznFtisY/RVK+KuBsmrMRylEnMJxXz/fihO48RDh7j6TFb8yf9V0B9w4iWtBMpwG9E3rQKyQtF4YVFk6VoBb5b2TX9Q85vyAYqSF64Dhqb0RVvWF3KaDCvjNO+2fAMpOXq39jAy4/w78Pv6gfdyzJ7lso0wXRHc/3SdS4qsmUc4X7uIACoxhWL7/JLT4Gh54gYuL0yNcUsowWhqLba6kJFtmcEAYm5jIkxY0G4QzHDCL32czb/D4Tbhn7+IWFcHrL5IMsIljg==
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=qDagGZO2RtNskUq1QiXQkXAONydlZKUYORV/JjISAuM=;
 b=SBRF7aex/lNFS+5xYBbpQvTrd7oF8M2SSciVyobOCt7kKq+sVq4FjAIVUyZRqdeKkPpisAwDfeAWt1nOcYHP2/jirX9aVMBZFeZqk9X/8fYGMQUjlelBqQiyjs0GFoBdsXzGmP7MAdvEdvhAfkcRRAY0OhEkVaKzcQSMLTETlOQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Anthony PERARD
	, Andrew Cooper ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v5 18/18] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-cppc driver
Date: Tue, 27 May 2025 16:48:33 +0800
Message-ID: <20250527084833.338427-19-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F0:EE_|LV2PR12MB5895:EE_
X-MS-Office365-Filtering-Correlation-Id: 4a664462-af30-4823-8602-08dd9cfb6e8d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?F7hmuFWIrW43PPJFzv/OGojC1AP6jdziNA1p8pxmF/DulCcLhWcVbgxjWMtW?=
 =?us-ascii?Q?HNf24N+7MEUkYYx2Lzy4EsZCvZTqd6kOBO4gDBvtgeZ6TroE9uIxHZP7z2RP?=
 =?us-ascii?Q?CABb1c4XC7UJA2nJBt5sATMbertA4N7zptPJjEXhiB7Kxd+0mL4iVadHl/lv?=
 =?us-ascii?Q?afJfK5jtRVCYhQbR1AmhsixP4FNiBGb/4HqprfbWfEkcNXVpHoCrQgfNOAi4?=
 =?us-ascii?Q?HRm55cz/TCTWtJ/R/HW9e8PY+O0X1ZFi+j7ykV8HGdzbVp8X3cPORvDUElPb?=
 =?us-ascii?Q?SuhBYYRFWuBFdc5YYqhk18bYpLFT3q6QvxX3MQmK6SioQeXEHV92n+feKk9q?=
 =?us-ascii?Q?Ab+N47ZXJ8IKGyEmMQbE2GK61A7SqjqJBE7Gjv+eRGjbgJnkytoGY5b3lSTa?=
 =?us-ascii?Q?+k0xEUqt6WRg8BQbm43hsXzNVikr1MzFJEMkdj0Y4NL4B2ZNLhSiNaZ6PV3M?=
 =?us-ascii?Q?HisAMhr7JgNYasM8GE0cnFQJXlc26HDtCk+ku5giHX0OhKZr5Ao0RW9CNAKJ?=
 =?us-ascii?Q?WIe1A97P9uOS+1P+W2dO2v8N0KM+CFDfQxV3dWwAie4fOBnyzR2swSSD7Wot?=
 =?us-ascii?Q?dbp7S6Efq2T/Sd/yKDmOzonb4pQV1KACXQVQXQp+af2bqI8Pk/9lbIqgdiW/?=
 =?us-ascii?Q?/4oLu+LxC0EQDT/WcxS8aukT1y8a0IFdfhtVRmdyUHYvtkOhytjS+pReoHYz?=
 =?us-ascii?Q?llRVjS+UUcqyFj/z6NMJUquj1a48igeZKpH375UTUIrey+NN0rQtaVcqTQLJ?=
 =?us-ascii?Q?Ib0TQmxED2QqM365VlAxV4necd5YehGUDePMCWfYaU1k4n28SnGvbCT9RiX1?=
 =?us-ascii?Q?Q2cyMZX4EOWJ+7WprVBOUsSX8OhwgejIm7tenbc8sGyQfPoLRSyvt4q5VyGM?=
 =?us-ascii?Q?B9Uvc+jFn4dd/J/o/Aa/x5GMehE9JznFbWCp83m47WQqoOR05rgYE98XIWZh?=
 =?us-ascii?Q?ZBiQzyd/MOkTOSjYh1LHQpYCU0CCQWDJUl/HIUBF7nSSH8qyEFU6+URNgatF?=
 =?us-ascii?Q?ApofF9dLXRN7HIuQKef5IQTT4FHUzTXOOlAmKYNdhqKzoIq/iMEbSiSICpER?=
 =?us-ascii?Q?VNtn2UkpY/7yQZbKVPODwG1Ah7djYXSnjKROGE+y1MNhXvuoEYRcqh84HmOw?=
 =?us-ascii?Q?ZirItNimbvR4j5Kz+JopTkt+tSAIdaid5kVokXEAOIXIkpgirfiWixL5wAUw?=
 =?us-ascii?Q?trGslwdCpKf3kJpbZ2kt5gvl8iFAJXKsBZjwZe2CZxXtTYSHKiXAw0m6hq2G?=
 =?us-ascii?Q?t6+O/1bFQ7CAjbjqvktU0pgKE3uTa4g/Re4o/RVKZ45imbl2cUWkvMQuASGZ?=
 =?us-ascii?Q?7VNMCqduWXUL1CslCxcbDRxZU5BINy4b4VqNihMBp643XYzg8IaxZrMilqBz?=
 =?us-ascii?Q?B1L7F83pBXAnSFpei/AWgjKKgjMPHzpWV+YezkoZ7TD3+R7QGjhhI/k8h5aM?=
 =?us-ascii?Q?7qdVXeXHPuXotVx0KRmJsD+JMfoGynhp0XOjugtwSmpT/S7KnXv48eKjRy9C?=
 =?us-ascii?Q?2RH6mv9xaMAnlKgmrtj+TmshEiV3WtaP88LQ?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:46.0563
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a664462-af30-4823-8602-08dd9cfb6e8d
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5895

Introduce helper set_amd_cppc_para() and get_amd_cppc_para() to
SET/GET CPPC-related para for amd-cppc/amd-cppc-epp driver.

In get_cpufreq_cppc()/set_cpufreq_cppc(), we use
"processor_pminfo[cpuid]->init & XEN_CPPC_INIT" to identify
cpufreq driver is amd-cppc/amd-cppc-epp. Furthermore, using whether
->setpolicy isn't null to tell whether amd-cppc in active mode.

Also, a new field "policy" has also been added in "struct xen_cppc_para" to
describe performance policy in active mode. It gets printed with other
cppc paras. A set of public macro XEN_CPUFREQ_POLICY_xxx is introduced
to be sync with internal ones CPUFREQ_POLICY_xxx.
A new policy XEN_CPUFREQ_POLICY_BALANCE is introduced, and could be achieved
only via xenpm XEN_SYSCTL_CPPC_SET_PRESET_BALANCE preset.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- Give the variable des_perf an initializer of 0
- Use the strncmp()s directly in the if()
---
v3 -> v4
- refactor comments
- remove double blank lines
- replace amd_cppc_in_use flag with XEN_PROCESSOR_PM_CPPC
---
- add new field "policy" in "struct xen_cppc_para"
- add new performamce policy XEN_CPUFREQ_POLICY_BALANCE
- drop string comparisons with "processor_pminfo[cpuid]->init & XEN_CPPC_INIT"
and "cpufreq.setpolicy == NULL"
- Blank line ahead of the main "return" of a function
- refactor comments, commit message and title
---
 tools/misc/xenpm.c                   |  10 +++
 xen/arch/x86/acpi/cpufreq/amd-cppc.c | 129 +++++++++++++++++++++++++++
 xen/drivers/acpi/pmstat.c            |  13 ++-
 xen/include/acpi/cpufreq/cpufreq.h   |  12 ++-
 xen/include/public/sysctl.h          |   5 ++
 5 files changed, 163 insertions(+), 6 deletions(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 2864506da4..2e5975cae4 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -38,6 +38,13 @@
 static xc_interface *xc_handle;
 static unsigned int max_cpu_nr;
 
+static const char cpufreq_policy_str[][12] = {
+    [XEN_CPUFREQ_POLICY_UNKNOWN] = "none",
+    [XEN_CPUFREQ_POLICY_POWERSAVE] = "powersave",
+    [XEN_CPUFREQ_POLICY_PERFORMANCE] = "performance",
+    [XEN_CPUFREQ_POLICY_BALANCE] = "balance",
+};
+
 /* help message */
 void show_help(void)
 {
@@ -984,6 +991,9 @@ static void print_cppc_para(unsigned int cpuid,
     printf("                     : desired [%"PRIu32"%s]\n",
            cppc->desired,
            cppc->desired ? "" : " hw autonomous");
+
+    printf("  performance policy : %s\n",
+           cpufreq_policy_str[cppc->policy]);
     printf("\n");
 }
 
diff --git a/xen/arch/x86/acpi/cpufreq/amd-cppc.c b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
index 5f15e86dc4..490446018c 100644
--- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
+++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
@@ -506,6 +506,135 @@ static int cf_check amd_cppc_epp_set_policy(struct cpufreq_policy *policy)
     return 0;
 }
 
+int get_amd_cppc_para(const struct cpufreq_policy *policy,
+                      struct xen_cppc_para *cppc_para)
+{
+    const struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data,
+                                                   policy->cpu);
+
+    if ( data == NULL )
+        return -ENODATA;
+
+    cppc_para->policy           = policy->policy;
+    cppc_para->lowest           = data->caps.lowest_perf;
+    cppc_para->lowest_nonlinear = data->caps.lowest_nonlinear_perf;
+    cppc_para->nominal          = data->caps.nominal_perf;
+    cppc_para->highest          = data->caps.highest_perf;
+    cppc_para->minimum          = data->req.min_perf;
+    cppc_para->maximum          = data->req.max_perf;
+    cppc_para->desired          = data->req.des_perf;
+    cppc_para->energy_perf      = data->req.epp;
+
+    return 0;
+}
+
+int set_amd_cppc_para(struct cpufreq_policy *policy,
+                      const struct xen_set_cppc_para *set_cppc)
+{
+    unsigned int cpu = policy->cpu;
+    struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data, cpu);
+    uint8_t max_perf, min_perf, des_perf = 0, epp;
+
+    if ( data == NULL )
+        return -ENOENT;
+
+    /* Validate all parameters */
+    if ( set_cppc->minimum > UINT8_MAX || set_cppc->maximum > UINT8_MAX ||
+         set_cppc->desired > UINT8_MAX || set_cppc->energy_perf > UINT8_MAX )
+        return -EINVAL;
+
+    /* Only allow values if params bit is set. */
+    if ( (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED) &&
+          set_cppc->desired) ||
+         (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM) &&
+          set_cppc->minimum) ||
+         (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM) &&
+          set_cppc->maximum) ||
+         (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF) &&
+          set_cppc->energy_perf) )
+        return -EINVAL;
+
+    /* Activity window not supported in MSR */
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW )
+        return -EOPNOTSUPP;
+
+    /* Return if there is nothing to do. */
+    if ( set_cppc->set_params == 0 )
+        return 0;
+
+    epp = per_cpu(epp_init, cpu);
+    /*
+     * Apply presets:
+     * XEN_SYSCTL_CPPC_SET_DESIRED reflects whether desired perf is set, which
+     * is also the flag to distinguish between passive mode and active mode.
+     * When it is set, CPPC in passive mode, only
+     * XEN_SYSCTL_CPPC_SET_PRESET_NONE could be chosen.
+     * when it is not set, CPPC in active mode, three different profile
+     * XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE/PERFORMANCE/BALANCE are provided,
+     */
+    switch ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_PRESET_MASK )
+    {
+    case XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE:
+        if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
+            return -EINVAL;
+        policy->policy = CPUFREQ_POLICY_POWERSAVE;
+        min_perf = data->caps.lowest_perf;
+        /* Lower max frequency to lowest */
+        max_perf = data->caps.lowest_perf;
+        epp = CPPC_ENERGY_PERF_MAX_POWERSAVE;
+        break;
+
+    case XEN_SYSCTL_CPPC_SET_PRESET_PERFORMANCE:
+        if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
+            return -EINVAL;
+        /* Increase idle frequency to highest */
+        policy->policy = CPUFREQ_POLICY_PERFORMANCE;
+        min_perf = data->caps.highest_perf;
+        max_perf = data->caps.highest_perf;
+        epp = CPPC_ENERGY_PERF_MAX_PERFORMANCE;
+        break;
+
+    case XEN_SYSCTL_CPPC_SET_PRESET_BALANCE:
+        if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
+            return -EINVAL;
+        policy->policy = CPUFREQ_POLICY_BALANCE;
+        min_perf = data->caps.lowest_perf;
+        max_perf = data->caps.highest_perf;
+        epp = CPPC_ENERGY_PERF_BALANCE;
+        break;
+
+    case XEN_SYSCTL_CPPC_SET_PRESET_NONE:
+        /*
+         * In paasive mode, Xen governor is responsible for perfomance tuning.
+         * we shall set lowest_perf with "lowest_nonlinear_perf" to ensure
+         * governoring performance in P-states range.
+         */
+        min_perf = data->caps.lowest_nonlinear_perf;
+        max_perf = data->caps.highest_perf;
+        break;
+
+    default:
+        return -EINVAL;
+    }
+
+    /* Further customize presets if needed */
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM )
+        min_perf = set_cppc->minimum;
+
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM )
+        max_perf = set_cppc->maximum;
+
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF )
+        epp = set_cppc->energy_perf;
+
+    if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED )
+        des_perf = set_cppc->desired;
+
+    amd_cppc_write_request(cpu, min_perf, des_perf, max_perf, epp);
+
+    return 0;
+}
+
 static const struct cpufreq_driver __initconst_cf_clobber
 amd_cppc_cpufreq_driver =
 {
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index e5f375921a..9e1ed29a0a 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -334,6 +334,10 @@ static int get_cpufreq_cppc(struct xen_sysctl_pm_op *op)
     if ( hwp_active() )
         ret = get_hwp_para(op->cpuid, &op->u.cppc_para);
 
+    if ( processor_pminfo[op->cpuid]->init & XEN_CPPC_INIT )
+        ret = get_amd_cppc_para(per_cpu(cpufreq_cpu_policy, op->cpuid),
+                                &op->u.cppc_para);
+
     return ret;
 }
 
@@ -429,10 +433,13 @@ static int set_cpufreq_cppc(struct xen_sysctl_pm_op *op)
     if ( !policy || !policy->governor )
         return -ENOENT;
 
-    if ( !hwp_active() )
-        return -EOPNOTSUPP;
+    if ( hwp_active() )
+        return set_hwp_para(policy, &op->u.set_cppc);
+
+    if ( processor_pminfo[op->cpuid]->init & XEN_CPPC_INIT )
+        return set_amd_cppc_para(policy, &op->u.set_cppc);
 
-    return set_hwp_para(policy, &op->u.set_cppc);
+    return -EOPNOTSUPP;
 }
 
 int do_pm_op(struct xen_sysctl_pm_op *op)
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index 6f31009e82..c542a6e633 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -134,14 +134,16 @@ extern int cpufreq_register_governor(struct cpufreq_governor *governor);
 extern struct cpufreq_governor *__find_governor(const char *governor);
 #define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_dbs
 
-#define CPUFREQ_POLICY_UNKNOWN      0
+#define CPUFREQ_POLICY_UNKNOWN      XEN_CPUFREQ_POLICY_UNKNOWN
 /*
  * If cpufreq_driver->target() exists, the ->governor decides what frequency
  * within the limits is used. If cpufreq_driver->setpolicy() exists, these
  * two generic policies are available:
  */
-#define CPUFREQ_POLICY_POWERSAVE    1
-#define CPUFREQ_POLICY_PERFORMANCE  2
+#define CPUFREQ_POLICY_POWERSAVE    XEN_CPUFREQ_POLICY_POWERSAVE
+#define CPUFREQ_POLICY_PERFORMANCE  XEN_CPUFREQ_POLICY_PERFORMANCE
+/* Achieved only via xenpm XEN_SYSCTL_CPPC_SET_PRESET_BALANCE preset */
+#define CPUFREQ_POLICY_BALANCE      XEN_CPUFREQ_POLICY_BALANCE
 
 unsigned int cpufreq_policy_from_governor(const struct cpufreq_governor *gov);
 
@@ -292,5 +294,9 @@ int acpi_cpufreq_register(void);
 
 int amd_cppc_cmdline_parse(const char *s, const char *e);
 int amd_cppc_register_driver(void);
+int get_amd_cppc_para(const struct cpufreq_policy *policy,
+                      struct xen_cppc_para *cppc_para);
+int set_amd_cppc_para(struct cpufreq_policy *policy,
+                      const struct xen_set_cppc_para *set_cppc);
 
 #endif /* __XEN_CPUFREQ_PM_H__ */
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 29872fe508..18c38744ae 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -308,6 +308,11 @@ struct xen_ondemand {
 
 struct xen_cppc_para {
     /* OUT */
+#define XEN_CPUFREQ_POLICY_UNKNOWN      0
+#define XEN_CPUFREQ_POLICY_POWERSAVE    1
+#define XEN_CPUFREQ_POLICY_PERFORMANCE  2
+#define XEN_CPUFREQ_POLICY_BALANCE      4
+    uint32_t policy;
     /* activity_window supported if set */
 #define XEN_SYSCTL_CPPC_FEAT_ACT_WINDOW  (1 << 0)
     uint32_t features; /* bit flags for features */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:50:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:50:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998000.1378870 (Exim 4.92)
	(envelope-from )
	id 1uJq1D-0001hD-Lo; Tue, 27 May 2025 08:50:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998000.1378870; Tue, 27 May 2025 08:50: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 1uJq1D-0001fp-Bk; Tue, 27 May 2025 08:50:43 +0000
Received: by outflank-mailman (input) for mailman id 998000;
 Tue, 27 May 2025 08:50:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq0E-0002ks-81
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:42 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20625.outbound.protection.outlook.com
 [2a01:111:f403:2414::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 84058220-3ad7-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:49:36 +0200 (CEST)
Received: from SJ0PR13CA0097.namprd13.prod.outlook.com (2603:10b6:a03:2c5::12)
 by CH3PR12MB7763.namprd12.prod.outlook.com (2603:10b6:610:145::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.24; Tue, 27 May
 2025 08:49:34 +0000
Received: from SJ5PEPF000001F0.namprd05.prod.outlook.com
 (2603:10b6:a03:2c5:cafe::a8) by SJ0PR13CA0097.outlook.office365.com
 (2603:10b6:a03:2c5::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.15 via Frontend Transport; Tue,
 27 May 2025 08:49:33 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F0.mail.protection.outlook.com (10.167.242.68) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:33 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 84058220-3ad7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XMmlld2VPjyKlHcYfHGImSreZGxmHsc5X831ga8NQnUA8l2pujC4idddpvb3q5pWwKg9RdHaHw1zpqZN/RuZjUov4C3/9H1Ibr8l0pqdurbBvTqQI3mNM61ysTQco6ZuzNCe55/uWxFqULbrqMFV2IaZFONUXxX5Gyn2nS6o118tXsWmQ8xWn/M8zyumB4fG1GoYokaN+EeN0UltAN6JqVRrPHalGL8j2O/YbCZFgNYeRLr4jj2N4ZH1myz8C4Ui8n8yJDd7V1TTWcuAP3nx1W1SBBlAUcaBkctH4j1Mro04beNHac1PI2io4ujbIx+ZzOv3CugQBiFxMlZKKQdeBw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uKMq5MghF8UFPlQJDia7shL8Q+N/pOobWNyzD8HVQKI=;
 b=mAZ3azt71GQbQnMIuaOFsHCuE2+su7gCdnHmS60eSR48e6W/TMYlRg2E8TC8VAlUxBpx89h9sykNWqsL24xkaARSmz8NBsiPbXI4nPotPORZzsI8eCqc0LERuSbfrhSQ4gbTbqH2EULv23+KwFoCbh5amSWuxpurXMufS/7GZUcYptq47PYDR9LV1g9AO7QjLTuLHsxDz0L6zWtkixoAt/RUlxOqhDsoHZyEvMAbNTI83ty/YIAWTV/JlNQuGl6atkAtlg4rPtpcb4E+5fio/g49gB6VbcLtDrLrStRgNhtfMlgL/4ZxgZPg/7f2NH6K6p3ah/yidMsBHBCBj7uz+g==
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=uKMq5MghF8UFPlQJDia7shL8Q+N/pOobWNyzD8HVQKI=;
 b=YuS2gFTbJEPcn+aOz5m18Z8mwOwSo6JT5o9l4mO6yC86Y3sjM5Ucuo8etTclsOH8YG/6e/f+3uc2nCtXhgWz4YKC4BSXMJafNaCrXg2fHB0/mTYDdorXCbqlQrvMV9B5fpV7Ew8TjW9EYdbS6vL7KHTHe2rR7w/Yem0G6oolKAM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	
Subject: [PATCH v5 12/18] xen/cpufreq: get performance policy from governor set via xenpm
Date: Tue, 27 May 2025 16:48:27 +0800
Message-ID: <20250527084833.338427-13-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F0:EE_|CH3PR12MB7763:EE_
X-MS-Office365-Filtering-Correlation-Id: b3ca16e1-e993-4cb3-ed29-08dd9cfb672f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?tnMPAPpq/aq/cYKy2p0s5ZUIXBWJIOZS64pI8OkzeZoqN3AcTzQqO6eXYLY4?=
 =?us-ascii?Q?y0cq1Mbw7mqOS4EqIAivSfRDTeRhKkjH7E8Q33wbH4PEeB2JWfsBFu4g93im?=
 =?us-ascii?Q?ObrQ4P5tg46cLvN5+Gbu5R0rJcmp9GOys+e64wZlW8+e+eCXuz/ZHh6kiG/m?=
 =?us-ascii?Q?jYgQHcqtt0cMu54M9d4C1/Qzc4olBDsSMiiEzp1oDcGnxOt+9T37v2wFD3EV?=
 =?us-ascii?Q?JAt5kCzXevaoiFwyK01Ty82HLEfUYfuqNfVYwX8Fx7PsRmjP9mGRO6PZGe/Z?=
 =?us-ascii?Q?WfHIspdLZoDyQF6H/0XjtskFXyRVFbHEhGi3Jk9tlKx6/eTgs72fKnU7EDtj?=
 =?us-ascii?Q?fuxvboH1G06jo2+A8M86NZZ6eN7Uyy0ltH421faxwbljR/JSVRROKEZJD7VI?=
 =?us-ascii?Q?eq0Jf/L3QUHecZE4UHZYkPG+hnt4iprNDzIAL7TZxYIaNk3KCzxvqrafr+0i?=
 =?us-ascii?Q?ZDQ3X7eiVS5e+Bx4eBA8+fzGxFFQ3pBkEffWgr54kqHFnbZlDhJ5v+K8AZT9?=
 =?us-ascii?Q?PwgA89sOVj/zQVO2q+/muBDsKC2FKMLhQuxOfOA5SC2KD7hucuyfyTP/jTYu?=
 =?us-ascii?Q?4PbpwZpg9DspuZUZsXkNwuxs9aWIgM5OPpd3l0smsu9wM2HAGqzgzMQ9Tai/?=
 =?us-ascii?Q?obz/zeyFATX39TVMe2dsqhxtpwWYOciyJevlY2TWokqtzUHMg4FiBV9mYh5c?=
 =?us-ascii?Q?adbzYVPC1XnsJosT434TQw7bh0YDCy9C9cSjj6WNH4nQ7l33QUKXMgfg5j2K?=
 =?us-ascii?Q?QxlQNX7dA6S9ma+NVLhx6EhkvHIUIbxbevuLkdXzPHim5Kjm4tuxsA6F6bz4?=
 =?us-ascii?Q?x9SxUJIouK42ZWiyZPpndDz6phIk/GhW1JHMvOWnOF0e4gPfym+COFimloQp?=
 =?us-ascii?Q?R6ZvObJDt9JXSG7iphS7WPFIjWzdzg6K01ogHbAKt63RFsifmiBwXMPfERsC?=
 =?us-ascii?Q?yvKNQKOf3IRoa5RWti+AkX5oVMjzvkmcOSq73+EA86Lkwcpza8WNqz1cDw+O?=
 =?us-ascii?Q?ddqYjc9z2paDIbjHHQhztEpqS0DEZxPdtBY0TYlIkl+omEH3cPGuWF4kDpr4?=
 =?us-ascii?Q?LPMbCE8RIkybrsyiqg2ua3tLIGbiniBexZXgSRn9mO30Qf+Jr0ABEKDHPgD6?=
 =?us-ascii?Q?UW0arxvUxI3EC0dy2IfqV6VaHr6x2gdRqkkxcdtMREhdZ9qvgxknqBWWaVsu?=
 =?us-ascii?Q?5BoN5lRBpp2urDPcarvevuGiGeN24qESx4VfN5U1o4aAIZwU0n1WP/KW3/kn?=
 =?us-ascii?Q?2ZryeJ0GWfvm3I59jRwXVsUeC2Wes7t8AHBqziYFbtZ70pVjQCLb8deq6Uvd?=
 =?us-ascii?Q?GhU3yU9r06psh+3z8qFOSEAKemm/sIRIrLcdVjRHMyGS2mNpiT+btwBLFhFb?=
 =?us-ascii?Q?/Jd1VhFAle1ElpssHVannktkZ2a7KiMPzYLA9+nD7hsDSn7tDXfzZjJmjKVb?=
 =?us-ascii?Q?2Acvy4z0AJMwJi5EgQQHYQGqjuvQl9zxX7SMt1EZU+6o+8TV+f0PNjXqJbg6?=
 =?us-ascii?Q?t+ZSIR4z+RfWiW9q3GX3o22Gs/2oCGMZsLcs?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:33.7131
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b3ca16e1-e993-4cb3-ed29-08dd9cfb672f
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7763

Even if Xen governor is not used in amd-cppc active mode, we could
somehow deduce which performance policy (CPUFREQ_POLICY_xxx) user wants to
apply through which governor they choose, such as:
If user chooses performance governor, they want maximum performance.
If user chooses powersave governor, they want the least power consumption.
Function cpufreq_policy_from_governor() is responsible for above transition,
and it shall be also effective when users setting new governor through xenpm.

ondemand and userspace are forbidden choices, and if users specify
such options, we shall not only give warning message, but also error out.

Signed-off-by: Penny Zheng 
---
v4 -> v5:
- new commit
---
 xen/drivers/acpi/pmstat.c     | 8 ++++++++
 xen/drivers/cpufreq/utility.c | 1 +
 2 files changed, 9 insertions(+)

diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index 330bc3a1c2..514475cf5c 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -319,6 +319,14 @@ static int set_cpufreq_gov(struct xen_sysctl_pm_op *op)
     if (new_policy.governor == NULL)
         return -EINVAL;
 
+    new_policy.policy = cpufreq_policy_from_governor(new_policy.governor);
+    if ( new_policy.policy == CPUFREQ_POLICY_UNKNOWN )
+    {
+        printk("Failed to get performance policy from %s, and users shall write epp values to deliver preference towards performance over efficiency",
+               new_policy.governor->name);
+        return -EINVAL;
+    }
+
     return __cpufreq_set_policy(old_policy, &new_policy);
 }
 
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 2617581125..734cd84be1 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -456,6 +456,7 @@ int __cpufreq_set_policy(struct cpufreq_policy *data,
     data->min = policy->min;
     data->max = policy->max;
     data->limits = policy->limits;
+    data->policy = policy->policy;
     if (cpufreq_driver.setpolicy)
         return alternative_call(cpufreq_driver.setpolicy, data);
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:50:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:50:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998004.1378878 (Exim 4.92)
	(envelope-from )
	id 1uJq1E-0001rN-FU; Tue, 27 May 2025 08:50:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998004.1378878; Tue, 27 May 2025 08:50: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 1uJq1E-0001oo-31; Tue, 27 May 2025 08:50:44 +0000
Received: by outflank-mailman (input) for mailman id 998004;
 Tue, 27 May 2025 08:50:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq0L-0002ks-6j
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:49 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2407::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8888d0f4-3ad7-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:49:44 +0200 (CEST)
Received: from SJ2PR07CA0011.namprd07.prod.outlook.com (2603:10b6:a03:505::20)
 by IA0PR12MB7529.namprd12.prod.outlook.com (2603:10b6:208:431::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.22; Tue, 27 May
 2025 08:49:42 +0000
Received: from SJ5PEPF000001F1.namprd05.prod.outlook.com
 (2603:10b6:a03:505:cafe::c5) by SJ2PR07CA0011.outlook.office365.com
 (2603:10b6:a03:505::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.21 via Frontend Transport; Tue,
 27 May 2025 08:49:41 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F1.mail.protection.outlook.com (10.167.242.69) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:41 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 8888d0f4-3ad7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CxkEoPzguB/T28ljyQp+pCHyZEIqZDL6Hb+Ynn+WE6bfMbpeWi3RkzAAPW/ljD74Yu+DH1Wf1C74Q69aGrD2ieKQ95zepCpqKo6QBQNWlcHpvQxLoF+aYpfLevv/wUPuJ3WSTYH71SWlbY/gV0SmdGnwybEdfXs3en009ny0Dch0oArIHNqQhBGqZ1l7OYxce/JgMMCJwdeJ2EVVsIgcsaDJeOmh2PT1sHQgHxbAMzsi+kRrTowdTbgDfdCWx0SvDc/G84M+v8RgL3goYWBSipaxn47EHVANi+qx1iAggjMu4Z6nfoWmAgOi6DodMFmltS4APSPoG7XPRqyC8KmNnA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=udVnsou+9c+YNjZiXHLgK6AMVgKetWIyil6Opn22eBs=;
 b=w58F/lrGu7Ji22vueQwhYyi4XKoVOyiuEWztjoKXDFlCz9iFJbCORM9YQ8S3nNFfAz6w7aUVUmTPQiqR738VoGzjG7UDyZtgaH9OuqOAptUaxD8LYYu4Yy47eBR9jMI+A7/+IzP+3a35W/ks1suwFT61y/PeVJR/Vdb6boiVxTEdChnF6PTSPzfagtwHPyWpk4dyPcFnXsetz3Np6Aidpb9ElfXNbavqbKqLnKSC2qhNmMJjpM60db+KyhK1ob6vl6g7Xum+JWnBeJxuOrvNXbA2YSQ2o4AYlKpjPgPilCdBM25pWDr/zpDRLafZMRxT8eMFVWSmiYrgSz447kb/ww==
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=udVnsou+9c+YNjZiXHLgK6AMVgKetWIyil6Opn22eBs=;
 b=mGpedRMGv1hb7fEFm/mH9RdsrwADqG/XuiqF5dZ5A630+gOs+ra0KYHsMBKZDps66JFsB4WwPnI++ZHGOBqJo3pcVbYpoZEciYj6/8vYfGtvPcYC99LqFytOZxB+eH6ZSgJXWe+YHy9EpgWKtQTfifN6SNTq6EwYBH3FZPc/vWY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Anthony PERARD
	, Juergen Gross 
Subject: [PATCH v5 16/18] tools: drop "has_num" condition check for cppc mode
Date: Tue, 27 May 2025 16:48:31 +0800
Message-ID: <20250527084833.338427-17-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F1:EE_|IA0PR12MB7529:EE_
X-MS-Office365-Filtering-Correlation-Id: 9fb66d1a-e742-4b2c-49fc-08dd9cfb6bf8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?jQqiZc/nDcgZbWmQeA/kE+kCLsdPZ+qHNdLCdtVxuSuMDsiI5bsh7iO7kKzU?=
 =?us-ascii?Q?caK50ZzqsUjzpphPnaFQLtwwVSWrdHUJASBFG6ynfAj2J4mNViH7OuYwGW9G?=
 =?us-ascii?Q?/xlZ/ALJ8ir/dFSeQg7ecmBKKNPujT+rq3T0S8F2TbaZWl50xwMchqT98FYF?=
 =?us-ascii?Q?RrN97dBU/AqAfFW272ASsbmjT06ewxxnu5nfauL2FUbVS9ntSGzECWVOrbQc?=
 =?us-ascii?Q?yu1s23PN4fMTZZX5+FKKD9n4xRn2SKWPV6/B01QoqYZd0/U/cM2TPCoLOKdg?=
 =?us-ascii?Q?ZKbvCcxfEblSY2P+nkxiBrVA7SDetiZBt4v5pLO4gV3zmdkjFgUnXTr5lvsO?=
 =?us-ascii?Q?iQeJjhZqOp7wGNSYjdW/is+rger+fdxHuU2w6vPJIYllmHLP8NQuEQUoPSTt?=
 =?us-ascii?Q?afZwr+LbZ/bcDZR3O/OrNYGquU0oMmBUzWp6bWvA0a566nG21JoGssdRvwGm?=
 =?us-ascii?Q?IbigfrseONoEf35LfAz33H2BP4yvGBqu9C00XfbD2+Fsd+OjgB8gn8AqdLME?=
 =?us-ascii?Q?YthEiKEv4/2vJz0oUfKOh5b+UAU9ftqifsWPxwD9n0A8JDnfZ0ksMt50LvUQ?=
 =?us-ascii?Q?tKt4H+IlAiHLDyQGYTbYBOBxUi8KdgYfSd6tVckTTA+EXZadlsiLj+3ahhhX?=
 =?us-ascii?Q?yXmFq/OHTJFhE/wSraNMfRqm37waK2TgikMii9oQ+Q6PPwpEMNZL/poyjwqm?=
 =?us-ascii?Q?WdRxnCxmIxH+y9i8yux+k4L1vEy4xFq6r+BOrMpPVLUbWx/HGCFGJQMaOTP5?=
 =?us-ascii?Q?oOB0dIaQbOxxtPEmSZQCVDs5HE4HncXgE3vX5quMTTtABfOn24hluy3Jhri9?=
 =?us-ascii?Q?X9FyrOG5NKpWwnmLnzkDRrnvFJ6kji4fJMDPWYyCvHQOX1Trp5YQBnoIQ3Hk?=
 =?us-ascii?Q?rmf19EAQSIG1OlFh2XCaTeQxn02lXbcEn2sxUAPOu2Y0MA8z/hUhPEEXUQDN?=
 =?us-ascii?Q?LH0xU+fBuxBV3Ts7/gqB1o28v5wW9426JGG0amv8TfFpkxamPyFZppGgJ7zC?=
 =?us-ascii?Q?Xs8Qj150KtndkU4+Og319kN8NCf9kqsqKdlebrLaT20KZ1ce+qrcxxHbw2RV?=
 =?us-ascii?Q?BDjpaFnOGrGcMjFsfKnBN5B3SI2MTdBB64CMWay2IHmJBhiPmTIMdWxzouXZ?=
 =?us-ascii?Q?nTtsni3j4k83g2MqzE53OeKPIUAmRJNtWJ7ilKYMWCFcNc6l1d2Z+9GbEe1t?=
 =?us-ascii?Q?O3efLIM2U9nXjnpsmPqkSpxaDJm0Z5fs8GgLCd4sh+36V4qa9S2n50d5GXis?=
 =?us-ascii?Q?cIyb/YUOlYhLO/zkD42gGA5ats2KuuVW4fRd3r37SaaZ9dSRY4nw2lM/XSnR?=
 =?us-ascii?Q?WhUo0ph9OsxQ79hmCx/FYBkUoRdfW8hZvGxHvQhwikqLCr5BrysxNpCSjBwx?=
 =?us-ascii?Q?exFnbrgJsi8mR91B+eAg08YFzO6EOWb2vfJ0axA4rDRILV024VN97iUKF7pH?=
 =?us-ascii?Q?KtqjVXEOyKA5/3Tyb2EIrZCxEEFM917wDxGzc7Vx4hvF/XBbssQpjJ97EWCP?=
 =?us-ascii?Q?7ThRtQzvcSCTBanWUotzYGnqHLn3nWjrexEV?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:41.7369
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9fb66d1a-e742-4b2c-49fc-08dd9cfb6bf8
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7529

In `xenpm get-cpufreq-para `, ->freq_num and ->cpu_num checking are
tied together via variable "has_num", while ->freq_num only has non-zero value
when cpufreq driver in legacy P-states mode.

So we drop the "has_num" condition check, and mirror the ->gov_num check for
both ->freq_num and ->cpu_num in xc_get_cpufreq_para().

Signed-off-by: Penny Zheng 
---
v3 -> v4:
- drop the "has_num" condition check
---
v4 -> v5:
- refactor title and commit
- make all three pieces (xc_hypercall_bounce_pre()) be as similar as possible
---
 tools/libs/ctrl/xc_pm.c | 43 +++++++++++++++++++++++------------------
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/tools/libs/ctrl/xc_pm.c b/tools/libs/ctrl/xc_pm.c
index 3c9e272aee..cdc072e757 100644
--- a/tools/libs/ctrl/xc_pm.c
+++ b/tools/libs/ctrl/xc_pm.c
@@ -212,34 +212,41 @@ int xc_get_cpufreq_para(xc_interface *xch, int cpuid,
     DECLARE_NAMED_HYPERCALL_BOUNCE(scaling_available_governors,
 			 user_para->scaling_available_governors,
 			 user_para->gov_num * CPUFREQ_NAME_LEN * sizeof(char), XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
-    bool has_num = user_para->cpu_num && user_para->freq_num;
 
-    if ( has_num )
+    if ( (user_para->cpu_num && !user_para->affected_cpus) ||
+         (user_para->freq_num && !user_para->scaling_available_frequencies) ||
+         (user_para->gov_num && !user_para->scaling_available_governors) )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+    if ( user_para->cpu_num )
     {
-        if ( (!user_para->affected_cpus)                    ||
-             (!user_para->scaling_available_frequencies)    ||
-             (user_para->gov_num && !user_para->scaling_available_governors) )
-        {
-            errno = EINVAL;
-            return -1;
-        }
         ret = xc_hypercall_bounce_pre(xch, affected_cpus);
         if ( ret )
             return ret;
+    }
+    if ( user_para->freq_num )
+    {
         ret = xc_hypercall_bounce_pre(xch, scaling_available_frequencies);
         if ( ret )
             goto unlock_2;
-        if ( user_para->gov_num )
-            ret = xc_hypercall_bounce_pre(xch, scaling_available_governors);
+    }
+    if ( user_para->gov_num )
+    {
+        ret = xc_hypercall_bounce_pre(xch, scaling_available_governors);
         if ( ret )
             goto unlock_3;
+    }
 
+    if ( user_para->cpu_num )
         set_xen_guest_handle(sys_para->affected_cpus, affected_cpus);
-        set_xen_guest_handle(sys_para->scaling_available_frequencies, scaling_available_frequencies);
-        if ( user_para->gov_num )
-            set_xen_guest_handle(sys_para->scaling_available_governors,
-                                 scaling_available_governors);
-    }
+    if ( user_para->freq_num )
+        set_xen_guest_handle(sys_para->scaling_available_frequencies,
+                             scaling_available_frequencies);
+    if ( user_para->gov_num )
+        set_xen_guest_handle(sys_para->scaling_available_governors,
+                             scaling_available_governors);
 
     sysctl.cmd = XEN_SYSCTL_pm_op;
     sysctl.u.pm_op.cmd = GET_CPUFREQ_PARA;
@@ -258,9 +265,7 @@ int xc_get_cpufreq_para(xc_interface *xch, int cpuid,
             user_para->gov_num  = sys_para->gov_num;
         }
 
-        if ( has_num )
-            goto unlock_4;
-        return ret;
+        goto unlock_4;
     }
     else
     {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:51:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:51:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998066.1378893 (Exim 4.92)
	(envelope-from )
	id 1uJq1c-0004VE-JO; Tue, 27 May 2025 08:51:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998066.1378893; Tue, 27 May 2025 08: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 1uJq1c-0004V5-G3; Tue, 27 May 2025 08:51:08 +0000
Received: by outflank-mailman (input) for mailman id 998066;
 Tue, 27 May 2025 08:51:06 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq0F-00031E-HV
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:43 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20606.outbound.protection.outlook.com
 [2a01:111:f403:2412::606])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 86839a97-3ad7-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 10:49:40 +0200 (CEST)
Received: from SJ0PR13CA0105.namprd13.prod.outlook.com (2603:10b6:a03:2c5::20)
 by BY5PR12MB4274.namprd12.prod.outlook.com (2603:10b6:a03:206::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.23; Tue, 27 May
 2025 08:49:32 +0000
Received: from SJ5PEPF000001F0.namprd05.prod.outlook.com
 (2603:10b6:a03:2c5:cafe::2a) by SJ0PR13CA0105.outlook.office365.com
 (2603:10b6:a03:2c5::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.16 via Frontend Transport; Tue,
 27 May 2025 08:49:32 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F0.mail.protection.outlook.com (10.167.242.68) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:32 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 86839a97-3ad7-11f0-a2fd-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xDuHygYFY121d5CqPVsYnxL7KlQzMsQV8wsIxbglHhKZB3KkGdM4A/MkeCoaScaMOLSHeK8D/9dXSNIiFZPfDALq/7TLqTQqyO0QDYZ1tAkEO4AiAbszWgtiogg0HFIaKrj6MmBusDoiE3S5RhWQGCdA0qc2G6Q9VDgSaONlolXibUBWZnENImuWXLjyG+gm8Qi1mfZEDKGxEYhAsUIO8AHGzhnW1EUA7aLDoYE6bAOuI9yGTcZsriDJ5zbuntazd/WiWFvEOq+aeDsErVmH1JyJM7M8gGR9vYxeVKF+3ugSnp8pNSBRfG+cpg5W9rAWAZniGtKF5AinxAX5SbT4iQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Yck7AKHKtbmxCUvtsRyzheF4rrJVBYbut7aEbRVxucI=;
 b=sBTlnLL5wIwPprtT9PYSdZ67L+bwbuNOS+mgTVs4ku2ZTRzZwPzKxk9Lnt2cOUlD6QgCzX+gZ0yUz2KbLwLcxsSYFq6QbU+IvFghx/7TTobj19dSO0BeIO2nAreJ55NpGYe7W66FlzlOOR1N5Ms38Qi7wwQy4wNiCEtBcMFW4Cp/YyXEv3NbJ1owjQ1hVCP7IvS+M2doBIjQtbTmR9VQigwGBi76VWx0z4uu2PL98iil8Jr9j231FesNG58+z9C/yvNNimPg3rzAKt05fyDgRTFm+OKkdIAOa/PTCKXTaMLwGwNuh7HYuLiZeIDBytHGx7F/iq/gbJAjhFL+fRQBwA==
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=Yck7AKHKtbmxCUvtsRyzheF4rrJVBYbut7aEbRVxucI=;
 b=njIeBczp2sQ21hxsElk+YLOD+yerYtA8n5iDCf9htqA5pQLi+ZkNcOLwuHt/dx+wh+eT6l+/w7F3zvwEAF6Hp/mObO2rOQvCtiuTTiHmZhwqJNwqEcDaFZ+aFsvc7Vr9orrWrt9akyUuVwgdVVv5kd3NOozoccwyMCjgUR79q8g=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v5 11/18] xen/x86: implement EPP support for the amd-cppc driver in active mode
Date: Tue, 27 May 2025 16:48:26 +0800
Message-ID: <20250527084833.338427-12-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F0:EE_|BY5PR12MB4274:EE_
X-MS-Office365-Filtering-Correlation-Id: c268a789-cbec-46ad-05cf-08dd9cfb6675
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?+aCMLJa+WILE1FEcHoJAnq4S+aw6ray7ULDI1TkK7a583z8wHfcYuwmTM/og?=
 =?us-ascii?Q?fgz9FjiSMYWCFJmyg0/OBfr4qNmZokXQYkt64ptbEc3uMYdaAIQ8d9clBd3Y?=
 =?us-ascii?Q?dSCbLPjmaquxZHe5ZvOnnfTGYFFWkoa1/yv6VJGUDk23RzKvCXLkn701ojNc?=
 =?us-ascii?Q?5WJEjon1GUrwUJvgO38PMNo+EqrR8+KRLhCfLiM0kPOoG15JPIVYhCFdumw8?=
 =?us-ascii?Q?IL0sUu+Fn4vuPzzENAglNq6h/fzyArEiF/58eY9/22VAgC9ELk1S/Sqgr9mf?=
 =?us-ascii?Q?vbiJTs7DluCKG9oHw0jkxuZMgnLEho4xE090Ie1ZFbdplABvGI2EHPjkJBTp?=
 =?us-ascii?Q?8M4aB0kkpn3kBknQNjLhQm2sXpOV+17b1K1kRHgoukOLtZg70N71Qx+Rq/80?=
 =?us-ascii?Q?Y25sKn5F1Ssm28kPrr10w5EWsfU1Rgv9BGa5576EBGPFlEx+2OJIsIJ6w8ih?=
 =?us-ascii?Q?uMPxAAb53avMN1SksLDoupOm+8EgBgLGX8wz5I3A8bKVDoe4TbvpXSJt+30B?=
 =?us-ascii?Q?UPq99TNIJl1O1DA0ajUGaOi2w09gPrzCvSZ58brg3yLNqpaL8hW1k+3OiyI5?=
 =?us-ascii?Q?ykaR9Iom4d3voONbdR8KZ7+xpKckAASuHdwUeBlgCsihb2PVfen87g7z+Dlk?=
 =?us-ascii?Q?VeTs4sp0Khg93Te98qmDrvGOlpkxdD7mxTj68ywmWRQTmPA4rnJidZQNqx2h?=
 =?us-ascii?Q?TjIIW0JzkQE1l0EaZ4M7E9J0HLYM20cWsVtTPvYL08c7k8zovryUa7H83GLM?=
 =?us-ascii?Q?FXDGpsIlNd+HSDZHcjYg3ZTV+c3qh3hp8VEOw1lBtXBa0T24r+zJGRfZ+1D8?=
 =?us-ascii?Q?edAwSpckqr9XCZ+KC0tKY056LaWkcrUjiwFyj+VgrKZURyWUjTHEZEQJPCZ5?=
 =?us-ascii?Q?dlE4da2RQI7gOIwZEvb5BYwz/IsSCq8kYRtTSZ0RA8ZAGhfFXUnLJo9XEk+Q?=
 =?us-ascii?Q?b5MVBGcDJqo2aKAEpMDO8x7rtULwmAtbnguuSvB0hehdS6aMknqADRV0u5rr?=
 =?us-ascii?Q?+N5jgp1gIRliv3W3afSbxRNmSIFuJIeN9qEWdaq7TacJwUu4Gy1H/qmQsNLQ?=
 =?us-ascii?Q?jQcC1X1BEgTJCUDirHf+A183Ew/lQKzwiwYDTRQ3RKaqkvhwIhFB1glb4Vj9?=
 =?us-ascii?Q?zR9qnSkgMNZmjlONIZc0GOJGJGe/1oeQHoWoMkW+JSd91n4ENg4iqAuAqQxw?=
 =?us-ascii?Q?eVKuzUYuBuBIWl8ajE6A3WO3xUMMZM1knujdSVN0H5vpa6XILzl2RVG2iQiz?=
 =?us-ascii?Q?hjsKZ/GGqnBM3l0BzPbAnWyXimpL8xpBCOSHuRATQOsIA26E2FJpKLBsZFpe?=
 =?us-ascii?Q?pdKV36dxjIk1SMobXLCyGmqXClY4LIvS4OEAJzWTy2hd9vkFrREyk0cVIRVu?=
 =?us-ascii?Q?AQP+jIlWv7qW3pbaU82sAkWShR1GIxHAxkUoK0aiacWGyYtvfVbFPnZUI8EA?=
 =?us-ascii?Q?tp8D4qgngCN1FLExBXwVSB6qNnns3ZGIxzF3Du72fOen+AnRioyArxxYJ36z?=
 =?us-ascii?Q?9JlIvaLTqP9LsW8uNSif/OT5E+GgWu4VJnDY?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:32.4883
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c268a789-cbec-46ad-05cf-08dd9cfb6675
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4274

amd-cppc has 2 operation modes: autonomous (active) mode and
non-autonomous (passive) mode.
In active mode, we don't need Xen governor to calculate and tune the cpu
frequency, while hardware built-in CPPC power algorithm will calculate the
runtime workload and adjust cores frequency automatically according to the
power supply, thermal, core voltage and some other hardware conditions.

Users could set EPP register to tell hardware their preference ratio toward
performance over energy efficiency, which is configured on a scale from 0 to
255 where 0 represents maximum performance and 255 represents maximum
efficiency.

We implement a new AMD CPU frequency driver `amd-cppc-epp` for active mode.
It requires `active` tag for users to explicitly select active mode.
In driver `active-cppc-epp`, ->setpolicy() is hooked, not the ->target(), as
it does not depend on xen governor to do performance tuning.

Users could re-use "governor" in Xen cmdline to deliver which performance
policy they want to apply, represented by a new field "policy"
(CPUFREQ_POLICY_xxx), CPUFREQ_POLICY_PERFORMANCE as maximum performance,
CPUFREQ_POLICY_POWERSAVE as the least power consumption.
Function cpufreq_policy_from_governor() is responsible for tranforming
governor into policy. Right now, only "performance" and "powersave" are
considered.

Signed-off-by: Penny Zheng 
---
v1 -> v2:
- Remove redundant epp_mode
- Remove pointless initializer
- Define sole caller read_epp_init_once and epp_init value to read
pre-defined BIOS epp value only once
- Combine the commit "xen/cpufreq: introduce policy type when
cpufreq_driver->setpolicy exists"
---
v2 -> v3:
- Combined with commit "x86/cpufreq: add "cpufreq=amd-cppc,active" para"
- Refactor doc about "active mode"
- Change opt_cpufreq_active to opt_active_mode
- Let caller pass epp_init when unspecified to allow the function parameter
to be of uint8_t
- Make epp_init per-cpu value
---
v3 -> v4:
- doc refinement
- use MASK_EXTR() to get epp value
- fix indentation
- replace if-else() with switch()
- combine successive comments and do refinement
- no need to introduce amd_cppc_epp_update_limit() as a wrapper
- rename cpufreq_parse_policy() with cpufreq_policy_from_governor()
- no need to use case-insensitive comparison
---
v4 -> v5:
- refine doc to state what the default is for "active" sub-option and it's of
boolean nature
- excess blank after << for AMD_CPPC_EPP_MASK
- set max_perf with lowest_perf to get utmost powersave
- refine commit message to include description about relation between "policy"
and "governor"
---
 docs/misc/xen-command-line.pandoc    |  10 ++-
 xen/arch/x86/acpi/cpufreq/amd-cppc.c | 123 ++++++++++++++++++++++++++-
 xen/arch/x86/include/asm/msr-index.h |   1 +
 xen/drivers/cpufreq/utility.c        |  11 +++
 xen/include/acpi/cpufreq/cpufreq.h   |  12 +++
 xen/include/public/sysctl.h          |   1 +
 6 files changed, 153 insertions(+), 5 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 9ef847a336..23518b2ae4 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -515,7 +515,7 @@ If set, force use of the performance counters for oprofile, rather than detectin
 available support.
 
 ### cpufreq
-> `= none | {{  | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-cppc[:[verbose]]`
+> `= none | {{  | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-cppc[:[active][,verbose]]`
 
 > Default: `xen`
 
@@ -537,6 +537,14 @@ choice of `dom0-kernel` is deprecated and not supported by all Dom0 kernels.
 * `amd-cppc` selects ACPI Collaborative Performance and Power Control (CPPC)
   on supported AMD hardware to provide finer grained frequency control
   mechanism. The default is disabled.
+* `active` is a boolean to enable amd-cppc driver in active(autonomous) mode.
+  In this mode, users could write to energy performance preference
+  register(epp) to tell hardware if they want to bias toward performance or
+  energy efficiency. Built-in CPPC power algorithm will calculate the runtime
+  workload and adjust cores frequency automatically according to the power
+  supply, thermal, core voltage and some other hardware conditions.
+  The default is disabled, and the option only applies when `amd-cppc` is
+  enabled.
 
 There is also support for `;`-separated fallback options:
 `cpufreq=hwp;xen,verbose`.  This first tries `hwp` and falls back to `xen` if
diff --git a/xen/arch/x86/acpi/cpufreq/amd-cppc.c b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
index 8f0a30c19d..5f15e86dc4 100644
--- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
+++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
@@ -30,6 +30,9 @@
         printk(XENLOG_DEBUG "AMD_CPPC: CPU%u " fmt, cpu, ## args);  \
 })
 
+static bool __ro_after_init opt_active_mode;
+static DEFINE_PER_CPU_READ_MOSTLY(uint8_t, epp_init);
+
 struct amd_cppc_drv_data
 {
     const struct xen_processor_cppc *cppc_data;
@@ -76,6 +79,13 @@ static bool __init amd_cppc_handle_option(const char *s, const char *end)
         return true;
     }
 
+    ret = parse_boolean("active", s, end);
+    if ( ret >= 0 )
+    {
+        opt_active_mode = ret;
+        return true;
+    }
+
     return false;
 }
 
@@ -224,11 +234,18 @@ static void cf_check amd_cppc_write_request_msrs(void *info)
 }
 
 static void amd_cppc_write_request(unsigned int cpu, uint8_t min_perf,
-                                   uint8_t des_perf, uint8_t max_perf)
+                                   uint8_t des_perf, uint8_t max_perf,
+                                   uint8_t epp)
 {
     struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data, cpu);
     uint64_t prev = data->req.raw;
 
+    if ( !opt_active_mode )
+        data->req.des_perf = des_perf;
+    else
+        data->req.des_perf = 0;
+    data->req.epp = epp;
+
     data->req.min_perf = min_perf;
     data->req.max_perf = max_perf;
     data->req.des_perf = des_perf;
@@ -239,6 +256,14 @@ static void amd_cppc_write_request(unsigned int cpu, uint8_t min_perf,
     on_selected_cpus(cpumask_of(cpu), amd_cppc_write_request_msrs, data, 1);
 }
 
+static void read_epp_init(void)
+{
+    uint64_t val;
+
+    rdmsrl(MSR_AMD_CPPC_REQ, val);
+    this_cpu(epp_init) = MASK_EXTR(val, AMD_CPPC_EPP_MASK);
+}
+
 static int cf_check amd_cppc_cpufreq_target(struct cpufreq_policy *policy,
                                             unsigned int target_freq,
                                             unsigned int relation)
@@ -260,7 +285,10 @@ static int cf_check amd_cppc_cpufreq_target(struct cpufreq_policy *policy,
      * performance in P-state range.
      */
     amd_cppc_write_request(policy->cpu, data->caps.lowest_nonlinear_perf,
-                           des_perf, data->caps.highest_perf);
+                           des_perf, data->caps.highest_perf,
+                           /* Pre-defined BIOS value for passive mode */
+                           per_cpu(epp_init, policy->cpu));
+
     return 0;
 }
 
@@ -336,6 +364,8 @@ static void cf_check amd_cppc_init_msrs(void *info)
      */
     policy->cur = cpufreq_driver_getavg(policy->cpu, GOV_GETAVG);
 
+    read_epp_init();
+
     return;
 
  err:
@@ -369,7 +399,7 @@ static int cf_check amd_cppc_cpufreq_cpu_exit(struct cpufreq_policy *policy)
     return 0;
 }
 
-static int cf_check amd_cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
+static int amd_cppc_cpufreq_init_perf(struct cpufreq_policy *policy)
 {
     unsigned int cpu = policy->cpu;
     struct amd_cppc_drv_data *data;
@@ -402,12 +432,80 @@ static int cf_check amd_cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
 
     amd_cppc_boost_init(policy, data);
 
+    return 0;
+}
+
+static int cf_check amd_cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+    int ret;
+
+    ret = amd_cppc_cpufreq_init_perf(policy);
+    if ( ret )
+        return ret;
+
     amd_cppc_verbose(policy->cpu,
                      "CPU initialized with amd-cppc passive mode\n");
 
     return 0;
 }
 
+static int cf_check amd_cppc_epp_cpu_init(struct cpufreq_policy *policy)
+{
+    int ret;
+
+    ret = amd_cppc_cpufreq_init_perf(policy);
+    if ( ret )
+        return ret;
+
+    policy->policy = cpufreq_policy_from_governor(policy->governor);
+
+    amd_cppc_verbose(policy->cpu,
+                     "CPU initialized with amd-cppc active mode\n");
+
+    return 0;
+}
+
+static int cf_check amd_cppc_epp_set_policy(struct cpufreq_policy *policy)
+{
+    const struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data,
+                                                   policy->cpu);
+    uint8_t max_perf, min_perf, epp;
+
+    /*
+     * min_perf represents the idle frequency, while max_perf represents
+     * the maximum frequency
+     */
+    max_perf = data->caps.highest_perf;
+    min_perf = data->caps.lowest_perf;
+
+    /*
+     * We set min_perf with highest_perf in performance mode
+     * and max_perf with lowest_perf in powersave mode, to achieve
+     * ultmost performance and power savings.
+     */
+    switch ( policy->policy )
+    {
+    case CPUFREQ_POLICY_PERFORMANCE:
+        /* Force the epp value to be zero for performance policy */
+        epp = CPPC_ENERGY_PERF_MAX_PERFORMANCE;
+        min_perf = data->caps.highest_perf;
+        break;
+    case CPUFREQ_POLICY_POWERSAVE:
+        /* Force the epp value to be 0xff for powersave policy */
+        epp = CPPC_ENERGY_PERF_MAX_POWERSAVE;
+        max_perf = data->caps.lowest_perf;
+        break;
+    default:
+        epp = per_cpu(epp_init, policy->cpu);
+        break;
+    }
+
+    amd_cppc_write_request(policy->cpu, min_perf,
+                           0 /* no des_perf for epp mode */,
+                           max_perf, epp);
+    return 0;
+}
+
 static const struct cpufreq_driver __initconst_cf_clobber
 amd_cppc_cpufreq_driver =
 {
@@ -418,13 +516,30 @@ amd_cppc_cpufreq_driver =
     .exit   = amd_cppc_cpufreq_cpu_exit,
 };
 
+static const struct cpufreq_driver __initconst_cf_clobber
+amd_cppc_epp_driver =
+{
+    .name       = XEN_AMD_CPPC_EPP_DRIVER_NAME,
+    .verify     = amd_cppc_cpufreq_verify,
+    .setpolicy  = amd_cppc_epp_set_policy,
+    .init       = amd_cppc_epp_cpu_init,
+    .exit       = amd_cppc_cpufreq_cpu_exit,
+};
+
 int __init amd_cppc_register_driver(void)
 {
+    int ret;
+
     if ( !cpu_has_cppc )
     {
         xen_processor_pmbits &= ~XEN_PROCESSOR_PM_CPPC;
         return -ENODEV;
     }
 
-    return cpufreq_register_driver(&amd_cppc_cpufreq_driver);
+    if ( opt_active_mode )
+        ret = cpufreq_register_driver(&amd_cppc_epp_driver);
+    else
+        ret = cpufreq_register_driver(&amd_cppc_cpufreq_driver);
+
+    return ret;
 }
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index e4401186c7..3e2522a862 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -242,6 +242,7 @@
 #define MSR_AMD_CPPC_ENABLE                 0xc00102b1U
 #define  AMD_CPPC_ENABLE                    (_AC(1, ULL) << 0)
 #define MSR_AMD_CPPC_REQ                    0xc00102b3U
+#define  AMD_CPPC_EPP_MASK                  (_AC(0xff, ULL) << 24)
 
 /*
  * Legacy MSR constants in need of cleanup.  No new MSRs below this comment.
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index b35e2eb1b6..2617581125 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -487,3 +487,14 @@ int __cpufreq_set_policy(struct cpufreq_policy *data,
 
     return __cpufreq_governor(data, CPUFREQ_GOV_LIMITS);
 }
+
+unsigned int cpufreq_policy_from_governor(const struct cpufreq_governor *gov)
+{
+    if ( !strncmp(gov->name, "performance", CPUFREQ_NAME_LEN) )
+        return CPUFREQ_POLICY_PERFORMANCE;
+
+    if ( !strncmp(gov->name, "powersave", CPUFREQ_NAME_LEN) )
+        return CPUFREQ_POLICY_POWERSAVE;
+
+    return CPUFREQ_POLICY_UNKNOWN;
+}
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index 83050c58b2..6f31009e82 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -83,6 +83,7 @@ struct cpufreq_policy {
     int8_t              turbo;  /* tristate flag: 0 for unsupported
                                  * -1 for disable, 1 for enabled
                                  * See CPUFREQ_TURBO_* below for defines */
+    unsigned int        policy; /* CPUFREQ_POLICY_* */
 };
 DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy);
 
@@ -133,6 +134,17 @@ extern int cpufreq_register_governor(struct cpufreq_governor *governor);
 extern struct cpufreq_governor *__find_governor(const char *governor);
 #define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_dbs
 
+#define CPUFREQ_POLICY_UNKNOWN      0
+/*
+ * If cpufreq_driver->target() exists, the ->governor decides what frequency
+ * within the limits is used. If cpufreq_driver->setpolicy() exists, these
+ * two generic policies are available:
+ */
+#define CPUFREQ_POLICY_POWERSAVE    1
+#define CPUFREQ_POLICY_PERFORMANCE  2
+
+unsigned int cpufreq_policy_from_governor(const struct cpufreq_governor *gov);
+
 /* pass a target to the cpufreq driver */
 extern int __cpufreq_driver_target(struct cpufreq_policy *policy,
                                    unsigned int target_freq,
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 42997252ef..fa431fd983 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -424,6 +424,7 @@ struct xen_set_cppc_para {
 };
 
 #define XEN_AMD_CPPC_DRIVER_NAME "amd-cppc"
+#define XEN_AMD_CPPC_EPP_DRIVER_NAME "amd-cppc-epp"
 #define XEN_HWP_DRIVER_NAME "hwp"
 
 /*
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:51:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:51:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998067.1378898 (Exim 4.92)
	(envelope-from )
	id 1uJq1c-0004Y5-R3; Tue, 27 May 2025 08:51:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998067.1378898; Tue, 27 May 2025 08: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 1uJq1c-0004XN-Nn; Tue, 27 May 2025 08:51:08 +0000
Received: by outflank-mailman (input) for mailman id 998067;
 Tue, 27 May 2025 08:51:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq0F-0002ks-81
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:49:43 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2413::60c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 84ab588a-3ad7-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:49:36 +0200 (CEST)
Received: from SJ2PR07CA0009.namprd07.prod.outlook.com (2603:10b6:a03:505::6)
 by SN7PR12MB7810.namprd12.prod.outlook.com (2603:10b6:806:34c::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Tue, 27 May
 2025 08:49:36 +0000
Received: from SJ5PEPF000001F1.namprd05.prod.outlook.com
 (2603:10b6:a03:505:cafe::21) by SJ2PR07CA0009.outlook.office365.com
 (2603:10b6:a03:505::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.20 via Frontend Transport; Tue,
 27 May 2025 08:49:35 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SJ5PEPF000001F1.mail.protection.outlook.com (10.167.242.69) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 08:49:35 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Tue, 27 May 2025 03:49: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" 
X-Inumbo-ID: 84ab588a-3ad7-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=i7Zm4GZQMTHpOJ/utqLehAb078P5Mxqsc/OC+NByfLRAW9CHiM2PxiYe/9BzNhd0/mQmb3ajefmTFcFdYeJ5g0it0dvh6kmedbvND57q9MPH5nB3soYWxzXdnkA69dqZqkL7QaTmqUKE3GJS2vPFWTZJe1Cbu+SswpEYMbyVP4JJchBhd7vNQCgDMCjSMRrzspojY/w02TQCYubqzrnZvXgsJ6poIC6v4qlg781CrHAmoWkE1VKRcDqH+3F+2EqIyZmH3xAa0KzlDPIRXWVjMnlIsJuBd/YUGXDScq0se/tNKLT0B6GGwyzIx4KksRPCSXLZbQThoo2o/KY9r5/LOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=w8UNDtkJ77Jej48aHtABIfIEduYhPVXTw5TZb7gBSLo=;
 b=YvTzvSsz7/Y1BCH3fzCW1X0fZmsXmJA4mxJp2ELz8HJt2M7KFygjcDAwmEhb9RWecgaejtsdKzhjywqtCDUHQ1N4/3QNEHaPRFXAv/TYk/FSfTxntWqTK2srlnNgHR6aFU4S39Zkc3T5fNC52NsiQwZW4UM2T6w7K5Qw/vtILV0YjS7yH1jC9YXQldDey3DmTh6FVoi1BfUSQpRrKs1MDGMTPrzQlGRLxhcO6E3ob/LYgtM2EAaB5NwG1/lRnsdA0h+7P+9Qcy4lNnnfWIWDPDwCCMA0SZcdSKGroHRB34OgDYRgEJ9VP0zHdp/JKNU5EM/WPhGH4ivLwTyEh3YJ+w==
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=w8UNDtkJ77Jej48aHtABIfIEduYhPVXTw5TZb7gBSLo=;
 b=vfFE3rA2KdTTHGJfe43JYLfF6lEC237f1NuYuSDG2YbV8oUlWjMfw+g1XD2O7Jl4+7Un8OI2FfqGg3NZYurc/XB6nDswgDsC4xqQwympdjgLZ2g3r2cRq0Kipfr7ZlYHntKW0vnwSp2DL6xUZHwFo6XEk8/L9/IeJhzqvbRgBKI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	
Subject: [PATCH v5 13/18] xen/cpufreq: normalize hwp driver check with hwp_active()
Date: Tue, 27 May 2025 16:48:28 +0800
Message-ID: <20250527084833.338427-14-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250527084833.338427-1-Penny.Zheng@amd.com>
References: <20250527084833.338427-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F1:EE_|SN7PR12MB7810:EE_
X-MS-Office365-Filtering-Correlation-Id: 9596d741-2bc9-4640-f764-08dd9cfb6815
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?2V7q0DghCvDVWe4wE1IsFwapW+XICSdq2t0EU9CYOyD+3+XeMU8qRswEGPl1?=
 =?us-ascii?Q?o95I9+COMKNn4R9/3b5BiKc7FHXvlW5Kkc88uXFFbjMJFY1e2elPTa4rDX8K?=
 =?us-ascii?Q?ArapXye+P/zVbB6iosEFwvGk67cgTafYy5fNKV6U2alfQj/0f9ktjU/Jip4z?=
 =?us-ascii?Q?v1uN8ekJwwp1MNfqAF67fZ9k9YBeX5CC095xEo+R1lVQnOR5RQW4QKD08JxN?=
 =?us-ascii?Q?cAkNDaG19k12bC50jAGLqP7byyytt+IQC9So9gsulodIlKgBJI15W7GM02b3?=
 =?us-ascii?Q?m8W1OjG/u8VFwsU7LsQwsZ47ZCHoeWJ8A8eJed5VVCgb4udP2CugXyaXp73p?=
 =?us-ascii?Q?bEt82dS979WH/Okk6eSoWm4wIFQ+5fsKnd04UJxuH3AS9eSpoF4YiwrqLz7v?=
 =?us-ascii?Q?8KkhYB9pjqhhfcfFcVkIieP2+vE9n3HdoXFBB8QdvBh6MkIS5lXgGwcXM21w?=
 =?us-ascii?Q?zl4wogqG6DycIPYwTafHLNvFq8RBmoJIZunk+ehP1SkJH26CiVphaaXVmTd1?=
 =?us-ascii?Q?Z7J1f4yZYvHVNsYoMKeMAiANcFSFlACz6RA6kEurD16ks5T8evNhBUBO3diH?=
 =?us-ascii?Q?H0cVHeMaspWrXBzrpooldUpSoiKmJKxjetbvkVsTIueFlr4qDavTAQY2xo1h?=
 =?us-ascii?Q?9zLls8jywPLAqQmNO7WYpoGGeahHwoqZ+sUxoTrW7Le0fAMKhHW0HOSJGg1a?=
 =?us-ascii?Q?Y/F5bKOnhAyyE0wnKJ3pNt8XSFxRpQyOfKzrU7IzNs3XJOskMGzPxKSQ9tmW?=
 =?us-ascii?Q?cZ9aLGWKi7GO67/uGYwTnD3rK0KKnrrPn19jnT9TqeOjOr5KnyHKjKVoj7kC?=
 =?us-ascii?Q?xBkeKY+nL1Gu1JGHWAOIXzFhZB5YLbtX/rKPlwk/5QuXU3diTwk+rSvMtlok?=
 =?us-ascii?Q?iBFt+8uIqPIBjm1HHe2TQNbz+LhShTO2YTIt/OXjQ9u9HrAvifd0SgdeYR7k?=
 =?us-ascii?Q?auRiPk1qFD1KX+tk9F80jhDpFWlUGC9tnWkh6tj1jVvHRS6fl6XyVVoSA4Wg?=
 =?us-ascii?Q?uvtfpZw0QY3fMaL82U6dIhXMVc2NVvPyF3g2ehxG94VibRU/fFx5xGB9GSjc?=
 =?us-ascii?Q?15NbVk9J+6x0t0jQ5+7y439GzS86cLQLsql6h8S6l7JgJwAUGDhM8QPcZPI0?=
 =?us-ascii?Q?BERffxby6ECVayc0/OfngGPmEWbqnx3DKyJquz6KnztVQE4EyFkWRtJ0MmOq?=
 =?us-ascii?Q?78h5K5lGeKiVChtkI27IAnB81MZyGFtkh6UIVoQJ6LmplY7vwUJAeOS6iH/6?=
 =?us-ascii?Q?iaxdJvSgJRtCubmxMm2QzOahkO7k0u+PzymvpU6tBZXe1B2nRdUr9aGv0P5p?=
 =?us-ascii?Q?T4ixIzFdTmOpBCRhVrS6vfksv6h0m7wDYhi1eS9Ufoa7oqD/iXF3yPNT+nn8?=
 =?us-ascii?Q?F8CMWs5R/6azFQGeR/cQF18H5UBCrlJlFZbnRvx+FSeMvCxOFLDqgVz4w3eZ?=
 =?us-ascii?Q?z4PBJL1IzC/TDFQo4pwa2RZ25GTUJijAGawbgaCKFbRZsApkwQjMPsdXhZyq?=
 =?us-ascii?Q?Bxbt0cJaH68nvhwKyZu+V/Bad03tk+N+VvlW?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 08:49:35.2211
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9596d741-2bc9-4640-f764-08dd9cfb6815
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7810

Instead of using hypercall passing parameter to identify hwp driver,
we shall use hwp_active(). Also, we've already used hwp_active() in
do_get_pm_info() in the same file to do hwp driver check, it's
better syncing with same way.

Signed-off-by: Penny Zheng 
---
v4 -> v5:
- new commit
---
 xen/drivers/acpi/pmstat.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index 514475cf5c..c09e001ec3 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -253,9 +253,7 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
     else
         strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
 
-    if ( IS_ENABLED(CONFIG_INTEL) &&
-         !strncmp(op->u.get_para.scaling_driver, XEN_HWP_DRIVER_NAME,
-                  CPUFREQ_NAME_LEN) )
+    if ( hwp_active() )
         ret = get_hwp_para(policy->cpu, &op->u.get_para.u.cppc_para);
     else
     {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 08:55:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 08:55:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998098.1378913 (Exim 4.92)
	(envelope-from )
	id 1uJq5f-00068K-Hs; Tue, 27 May 2025 08:55:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998098.1378913; Tue, 27 May 2025 08: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 1uJq5f-00068D-FP; Tue, 27 May 2025 08:55:19 +0000
Received: by outflank-mailman (input) for mailman id 998098;
 Tue, 27 May 2025 08:55:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJq5e-000687-7N
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 08:55:18 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4ae94275-3ad8-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 10:55:09 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a363d15c64so2183766f8f.3
 for ; Tue, 27 May 2025 01:55:13 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4e1fe9430sm1235287f8f.75.2025.05.27.01.55.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 01: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" 
X-Inumbo-ID: 4ae94275-3ad8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748336112; x=1748940912; 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;
        bh=NJRlsrbIftpUn3xrkDPhph5ZHApo2Tvm5YsE6Cw+Mkg=;
        b=C7q3COS6kPd4Y5xgPKM7b/QgBkltNK1btGLum2BfQ62hCIWIns245lLLiWS7mAqGs3
         b37wFcYfH7bdwTzwHUv9R4QEIrHYFYZmbRgUdvCwjwGCbhNABHN6CSnF2jXOBUGX3h1Y
         aR0a11aIjxoFACeCy95bu++QjqILfDgF6PYT8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748336112; x=1748940912;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=NJRlsrbIftpUn3xrkDPhph5ZHApo2Tvm5YsE6Cw+Mkg=;
        b=eYOuTE0Dr3iclE2jmYay+g7o+2WBE9P+s5XVn52FI178rhwNnn/KuattzsVmIfCled
         ktdGrTeLijJ4IECHv3xIGPWtivArn6Lgun5Rgx0WX/RUPkjE05gC+b18At7hYUX9mjmk
         Gct64W0d/J6wZL5qMhxNAhNx/Kl+t4/5fLRvNTXmvMonPB3xXv4HsM8ndmqQPPPHQP6l
         v6iApDKpKFyVfeHdpZ2xOjU/4OxGCpT2jApeoCpKvisllYjJfqTNmvy3GG6glQycySoX
         6PkuYZFXuiN1/KBQn8PsxD2gqxGZ+AVyb85cvf4S60zzaGb6ogQVSI01Jmbx827JDc1J
         yuHw==
X-Gm-Message-State: AOJu0YyLdPWCuCn6ruKlh0b2Vv+Dr4UoKxoa5n0r1MPR0tdAsbsNf9A0
	UlQb4aoh4B+EY47CNy9tkbTQiPJh292JoB9ns/V3xyhrI19V+ht47i5FlleqPjMC4Qa8J6vpMiw
	ZXQoN
X-Gm-Gg: ASbGncvvsNDIFC7q8FcvXyVTcPz2uO0VFa7oDSCmSTvXd+HqckiVJG8YGQh2PVv6HPB
	mvTZOpXThZoIi2lh15MUlcA7RgV2xxGIBZQab//aL38i0WLl0c6DxQUUzguL+W0TitDep6PzRDO
	AhId6cf2f2q+StvaXitgOYkXAuv4sgsIbRXjfr2lKSrN7QcrmxvmNZMZ6/lgqWa/0RiqSnq8gZc
	InWiE9pX9EmdG406vk4yTaQQXuyNtMXKns3gq/7QsopRMagqSTs5UUhZoSqShZ6P3oXgzVpEfFi
	ODyoNRKBu+nU0aIEAVKOljlYR7r+kUCLJu7zKWbj0etV/ATcNgAI4N4CjtC9ZIO0SI3MHbOaeAL
	8FAH/3IhZAUEnRM2vvtM=
X-Google-Smtp-Source: AGHT+IFtiEhpA67zYypSi6+yw6uitOWJdUGyd5D1vCU9xy9ipwh9IBLKHSFbWvQQB6l0LwJo+1zkoQ==
X-Received: by 2002:a5d:5848:0:b0:3a4:de27:e00f with SMTP id ffacd0b85a97d-3a4de27e06emr4372551f8f.7.1748336112077;
        Tue, 27 May 2025 01:55:12 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD 
Subject: [PATCH] x86/hvmloader: fix order of PCI vs MTRR initialization
Date: Tue, 27 May 2025 10:55:04 +0200
Message-ID: <20250527085504.77444-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

After some recent change the order of MTRR vs PCI initialization is
inverted.  MTRR will get initialization ahead of PCI scanning and sizing of
MMIO regions.  As a result when setting up MTRRs the MMIO window below 4GB
will always have the same size, and there will be no window above 4GB.
This results in malformed and incomplete MTRRs being setup.

Fix by making sure PCI is initialized ahead of MTRR, also add a comment to
notice the ordering dependency.

Fixes: 2c3dffbaa324 ('tools/hvmloader: Replace LAPIC_ID() with cpu_to_apicid[]')
Signed-off-by: Roger Pau Monné 
---
 tools/firmware/hvmloader/hvmloader.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index 4e330fc1e241..6d23150fc9fd 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -341,10 +341,16 @@ int main(void)
 
     printf("CPU speed is %u MHz\n", get_cpu_mhz());
 
+    /*
+     * PCI setup must be done before SMP initialization, as the later also does
+     * the MTRR setup and so the size of the PCI MMIO windows must be known at
+     * that point.
+     */
+    pci_setup();
+
     smp_initialise();
 
     apic_setup();
-    pci_setup();
 
     perform_tests();
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 09:20:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 09:20:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998157.1378964 (Exim 4.92)
	(envelope-from )
	id 1uJqTW-0003XV-IQ; Tue, 27 May 2025 09:19:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998157.1378964; Tue, 27 May 2025 09:19: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 1uJqTW-0003XN-ES; Tue, 27 May 2025 09:19:58 +0000
Received: by outflank-mailman (input) for mailman id 998157;
 Tue, 27 May 2025 09:19:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJqTV-0002b1-6B
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 09:19:57 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id beaf89f8-3adb-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 11:19:52 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-551fb4d153dso3840975e87.3
 for ; Tue, 27 May 2025 02:19:55 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5521b9f9decsm1663715e87.157.2025.05.27.02.19.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 02:19: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" 
X-Inumbo-ID: beaf89f8-3adb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748337594; x=1748942394; 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;
        bh=py4ZIKoZa8cJlUFwF3FJvX8V7ahYkhYaZmzaoKgX5pA=;
        b=BgL8laUBS5eZFPFEsegtPdXpTZpYDQepkm8nFMPnlhohx5+IfpjY8zEmZuCexAdRio
         ioPjKNqkd/THiXmqgkdbroPmcjAAtWvkH8uJl+zreTgg0uc0+ixAe/Chv+OhtlqV+QZX
         pFN1M7np12lh15gRB2xULuraypG2FnaV7iV0KJ5CEMhRh/+TMlH+m9VwpAIpaD9LRcy3
         WI+7rcCS846pMxtdJZzpg38PT1O2nb0fb+wCvsmzblMC2+SPrqZeibvZcEz6u3SgWOv8
         /Hiw8YznABNmAJzB1Rpz1IyYpeHxaJCNYeMjposwZOcv2/j8nEl91NaF8Aa5ldh85Hrw
         v12w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748337594; x=1748942394;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=py4ZIKoZa8cJlUFwF3FJvX8V7ahYkhYaZmzaoKgX5pA=;
        b=QG6faCXi8zeaeE172SBwkC+cNlkHXpWHuw4NCOvr0mGLfJw0vSmHCSfqhDSZzV4rgj
         mFvQHEEDN6SxyKrvhiEooRkZok+3v91vVBp6nTv8AgqEKBK9zFRaxDSVy03teidfL1g2
         Jutmtm5QUTxPB66IRwKS1b7z/ETXu9a467bL1zrCHGaPMgpJb+Seym+n64Mxw8TWljrG
         NTiRGDjndcXCEegROdjgSgQZUjzdTlCkadyF49j8V8iCbucmBucWsgGalGzxAYbc2mym
         idPhymN8RckYDRKeylxHOxcvYQg4MKBUZvFn3mxNAtr7TTRl+srbe62RvXmfLJhIIi6Z
         ts/Q==
X-Gm-Message-State: AOJu0YyvW54dnChcYvKt3ZtyGNDqfIYWHMtbZ3OtyH/eYLZZ+pE/MEr5
	85RrcAjNoLmzdnBjU7TPlcyqT6IFFHeTrFLD3ytxOE1EQSTl6ahmq2BWjlmRlQ==
X-Gm-Gg: ASbGncszlRBMgZUsMnWVUQTYGoc4iRrDUFH9PuLNYbDGVPB+IjrpPUSDai76Kj5Huxq
	p9ArRcon5sID4oowC5QhjTxB727AFbCrJ9mU5Ho1Yt49OCcMB5QXTRtoudm0StVhPa0flgkN8l6
	ASsSECmd7USSOaTWUNSnpFU3DdQ4wINS5Kd9P1DUUIIpsEgHZKKw+pCmxIAqzRBgjHiWySbYA5Z
	z2XGRSRfDCZPaA8fNd1T0G3yKoXhsoUBmSD+e4Df2EGvFxHsjWWv+PlGYYZMQ4dbh8N4G8KV/pa
	EVy0CdD3Dv7v6c583oTQpUqGpAqNfgnNmf32VlBMUnrz3dd/fJd5XH39gViYw68pUg5tE7OKdPZ
	tDyj8WIYGT068cjU=
X-Google-Smtp-Source: AGHT+IGkPlHMkXyFexySvAYIMb1Jy40xU2JqZkz3BSDBtk9BTrQvCDz9C+w87HzDsLV4wiJpogetgw==
X-Received: by 2002:a05:6512:158d:b0:54f:c186:ecf7 with SMTP id 2adb3069b0e04-5521cbafde3mr2926091e87.57.1748337594304;
        Tue, 27 May 2025 02:19:54 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Oleksii Kurochko ,
	Community Manager 
Subject: [PATCH v4][PART 1 4/4] CHANGELOG: Mention Xen suspend/resume to RAM feature on arm64
Date: Tue, 27 May 2025 12:18:57 +0300
Message-ID: <1035d97375bad4b3e6f86e78cbe4e46abdbc2de9.1748337249.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

Signed-off-by: Mykola Kvach 
---
 CHANGELOG.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index ec452027f5..fc89ed6e09 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -26,6 +26,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
  - On Arm:
     - Ability to enable stack protector
+    - Support guest suspend/resume to/from RAM
 
 ### Removed
  - On x86:
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 09:20:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 09:20:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998156.1378949 (Exim 4.92)
	(envelope-from )
	id 1uJqTT-00037q-8L; Tue, 27 May 2025 09:19:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998156.1378949; Tue, 27 May 2025 09:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJqTT-00036P-5W; Tue, 27 May 2025 09:19:55 +0000
Received: by outflank-mailman (input) for mailman id 998156;
 Tue, 27 May 2025 09:19:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJqTS-0002b2-5t
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 09:19:54 +0000
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com
 [2a00:1450:4864:20::12c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bf942269-3adb-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 11:19:53 +0200 (CEST)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-5532a30ac41so304797e87.0
 for ; Tue, 27 May 2025 02:19:53 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5521b9f9decsm1663715e87.157.2025.05.27.02.19.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 02:19: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" 
X-Inumbo-ID: bf942269-3adb-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748337593; x=1748942393; 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;
        bh=047svu4VMPtrVn1GtLrAbtidBhKsG4dxvFgzkgEe5XM=;
        b=Z1bXUWCX/5iyTTbddfgCwLV30sPct8xwbrQRNHvs+pgjWpnkgg69OCY8ZUchXH3HrP
         DP1rsSxAn5ntaim9Mp4mXcyv1eGlEm5UEh6HAHepcpH0gNV4YOpaYN25nI2thsSCQ1l7
         sjdwmNUaLN8YzqSQ4sPBHCQMvTuKs7C7oPuIH+N85vHCIwiz24cF9pXiz0Ivbm6wmnL+
         JNStSWL7sIY92kXSe+VcicAFXAql8nUOAHgTBE4qpoV5hpRudmpIS0sa6AUZ/VwjmOA6
         iGE1ciaJuJLtnYNmRjt31KG3KMtUrO9gqDz0y6q3M9pLyQT+7GiLIQOgSjiSSNrMrUzw
         hDfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748337593; x=1748942393;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=047svu4VMPtrVn1GtLrAbtidBhKsG4dxvFgzkgEe5XM=;
        b=KP+Y+tIu20t6GWEEaZicsoG+QAAv5S3THYbsvXikMIvk2EPwKY45Qztf9ZZjgNdxCB
         cCDg6zslVRnWmqq6Db/xN+NY5hEwbfh0YjsHQONFOKLuzOj1+D9wdBiWDCwiOsYLGdH8
         f1iJJwXzqMr1h4W5TMtv1RYy8d4Ve5nmPU+yjMu1UYb8rTHmUhiqxBPn6vh7IkA2V+oz
         zXobBvNgp5deTnwJmQI/1FdOftDLxo+usej07jQCEivHs4xWKtc/6kgczT78GKv9Trmc
         GgvHhNP2VRCBny5oeLHex5apg3RxwfSjxdhyP4TF0kg0DmVOYk1xiuNNYW762ftCLfmf
         VdlQ==
X-Gm-Message-State: AOJu0YxNQD+cgVmln0G+XgVEtSBUmfrLUJx3hgptPN8OlLfKtZEXKGnn
	kO/xCBwaIha2oUuzVAOvNdgKlcGXjLr03vdgR4aLwuilmSLNO0xCTu/7UuknAQXv
X-Gm-Gg: ASbGncvyLqNsTgjHhFhGfKlZl89tPJPUX8AkWN6Rj83SMk1iUY3CO6f09loC8G7idKn
	V+PRKr3Ovr9rKWhXY90k28pQqXdsixdRnYrW1tsVhtGxu3S7XUolLFIZfrEQ8e14RVLWHnYQFBk
	qxQ5TqU06rEc1UvkXHG7MapspyYE+Rdv2/EezfFjb6pwr1TtwkIvSjqo3CqnC1zG1V9UwQNvC4A
	Vhd7j7ZGanvjPkT1B1XVgxkYmRiKASHnFmAUIgEnP5kAh62FtkTJEx8v36REruAfvY9lf1HWDKc
	lpCWhvhYv2Z+CGmc99//w9SETjbeKfqOxqsD3OlTaBbtKAZwzm+nTQJouBclZFFSjVMwEMUO0EA
	6xGSgqU99lnQK0x53ByEg9aOdxA==
X-Google-Smtp-Source: AGHT+IFxb/5W18oyk/0gBgsHOaXnhplOGuj1SCrklarCGv704LxYWGmqaRHYVe9H1zyfxO2++M3bSg==
X-Received: by 2002:a05:6512:3191:b0:54b:117b:b54b with SMTP id 2adb3069b0e04-5521cba15a2mr3250533e87.54.1748337592683;
        Tue, 27 May 2025 02:19:52 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v4][PART 1 3/4] SUPPORT.md: Document ARM PSCI and vPSCI support
Date: Tue, 27 May 2025 12:18:56 +0300
Message-ID: 
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

Add a new entry under "Host hardware support" to document Xen's use of the
PSCI interface to interact with EL3 firmware via SMC calls. Supported PSCI
functions include CPU_ON, CPU_OFF, SYSTEM_RESET, and SYSTEM_OFF.
SYSTEM_SUSPEND is not yet supported.

Add a separate entry under "Virtual Hardware, Hypervisor" for vPSCI,
which describes the emulated PSCI interface exposed to guests.
SYSTEM_SUSPEND is not yet supported for hardware domain.

Signed-off-by: Mykola Kvach 
---
 SUPPORT.md | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index e8fd0c251e..31ad4c96fd 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -73,6 +73,12 @@ For the Cortex A77 r0p0 - r1p0, see Errata 1508412.
     Status, x86 PV: Supported
     Status, ARM: Experimental
 
+### ARM/PSCI
+
+    Status: Supported
+
+SYSTEM_SUSPEND is not yet supported.
+
 ### Host EFI Boot
 
     Status, x86: Supported
@@ -946,6 +952,15 @@ by hwdom. Some platforms use SCMI for access to system-level resources.
 
     Status: Supported
 
+### Arm: vPSCI (virtual PSCI interface for guests)
+
+Emulated PSCI interface exposed to guests to support CPU_ON, CPU_OFF,
+SYSTEM_RESET, SYSTEM_OFF, etc.
+
+    Status: Supported
+
+SYSTEM_SUSPEND is not yet supported for hardware domain.
+
 ## Virtual Hardware, QEMU
 
 This section describes supported devices available in HVM mode using a
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 09:20:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 09:20:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998153.1378924 (Exim 4.92)
	(envelope-from )
	id 1uJqTR-0002bi-EU; Tue, 27 May 2025 09:19:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998153.1378924; Tue, 27 May 2025 09: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 1uJqTR-0002bb-B1; Tue, 27 May 2025 09:19:53 +0000
Received: by outflank-mailman (input) for mailman id 998153;
 Tue, 27 May 2025 09:19:52 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJqTQ-0002b1-EP
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 09:19:52 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bb4fc0e5-3adb-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 11:19:46 +0200 (CEST)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-54d6f933152so5271645e87.1
 for ; Tue, 27 May 2025 02:19:50 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5521b9f9decsm1663715e87.157.2025.05.27.02.19.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 02:19: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" 
X-Inumbo-ID: bb4fc0e5-3adb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748337589; x=1748942389; 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;
        bh=p8R2uwd0TUV2vq9idtVEqlqIwSBIFPpKCtLoSAbkW/o=;
        b=E8D6Mh1WR2ZTCq68Se7mQkdBmBja3/MYIT8LHbKw43T6XORaJnKCa5tz7VSnltZSR6
         B1WkMJLRFzFpcAkSPq14paBHmUpAWrnqGFuMWX/w2Kd5PxvscqI1J/hfQx7Ekxl3Dgc2
         aLhqqynDLY6J5Jw7b4EDXsq94aFP5CHGg9o5Le8ZRonR17aPr+BDjihE/OVOhw/f83B3
         8cWj4yD3ENI2QzCbM7AU8xRpoxgsozm959FwlioyoLBIdIKUevDmaavJIN6wolPbPCHX
         pcQ4zY4bis9ekFM+aFcMC4MxvQyscqkIuypumzGOHiy3T4DUNV/5gAU997GbjGcNGBR7
         0WmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748337589; x=1748942389;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=p8R2uwd0TUV2vq9idtVEqlqIwSBIFPpKCtLoSAbkW/o=;
        b=OHtpwu60bpK1HwAzSQnHzlzYIgWcrbJbg/qxyVVhQr3gOWdWWftji//bQ4cjCVaUsN
         U/UaqClPV+TN0I7RGkgJnJDaVBqqAD0YqspvuiQ4Jq+ZPvsKdqZik2Fx8N6zFLMAlHEE
         SO3xdqjQZf25PQ7PFRswaQQQMrbOc+Rj1b59Q9lkEzmgo4LyA1BDyVccHAxxOftJNwvg
         V6P8z5NWvOlPABIxL0BvlyrIf+19mwMpwJVSgy9BLAvPaMVDqQ6+GrrrwQ8hYa6Bg62w
         W5wVoombnKMqZin6fe8xRBB6WTB3MPh+oCuQ5gP7RbWlQOLWCj/W+Bttj05L2Boc11dp
         Jr4Q==
X-Gm-Message-State: AOJu0YxCe11CeqqlaAyl+J29tq0Tk7vwqD7J/EFeAR+NfljpU2bRlNqZ
	41K9qZ2AhbrCKk82bN+TuQ94/RglUa6g4HOXhN1ckaOiGM1WMJdv4KUO2VfwPG6O
X-Gm-Gg: ASbGncso99wnW/MDuS9IqEOBjW4ZRmEP+Q3SY1yHltnyv4+5hBbozBj5lDlQfI53LUy
	pSx0XXj8wx+5sdJaZRX2vBzMz9RI+Qcl1VOqrNZZHxAV4Sld5IPuXpdQI0k+RvulTLir+7A3VF9
	0OZFduTUSQJ2JweimxnL4fe6mlrZMM03glOvil4u3tee8wrPd8/Q/c3pim4rnWWsAnIhPjWtXSu
	OmkzRVNoT0IbMiUjEaqMI1VTdIaCQ9nQ+cn9uDE/ajZfogQ6nav0ryISst+cJIs0wyxDnZjSlf1
	9jByyusrlbQvnD1pUZIv49RF1kGLhIJu2C0Oa9RlQNMmlFVBz6nZaAMcrM7BAbB+BxP/MqxGu7D
	/C/i1ww3BYDdNtks=
X-Google-Smtp-Source: AGHT+IGCQsvJkMXA2rfh8Zw6Ppmsb2SJ+rmcvCHFBUWkn1BHLN+8iXRIgxUHSicUk39ZpAtQqSKg1w==
X-Received: by 2002:a05:6512:3083:b0:54f:c580:af96 with SMTP id 2adb3069b0e04-5521cbafba7mr3274636e87.50.1748337588876;
        Tue, 27 May 2025 02:19:48 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Anthony PERARD ,
	Juergen Gross ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Oleksii Kurochko ,
	Community Manager 
Subject: [PATCH v4][PART 1 0/4] Enable guest suspend/resume support on ARM via vPSCI
Date: Tue, 27 May 2025 12:18:53 +0300
Message-ID: 
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

This patch series introduces the initial support for guest suspend
and resume on ARM platforms using the PSCI SYSTEM_SUSPEND interface. The main
goal is to allow ARM guests to request suspension using PSCI and be resumed
by the control domain (e.g., via "xl resume").

### Background

The PSCI SYSTEM_SUSPEND call is part of the PSCI v1.0+ specification and is
used by guests to enter the deepest possible power state. On Xen/ARM, we
emulate this interface in the virtual PSCI (vPSCI) layer for guests.

This series includes:

1. A new vPSCI implementation of the PSCI SYSTEM_SUSPEND function for guests
2. Documentation updates to SUPPORT.md to reflect PSCI and vPSCI support status
3. Enabling "xl resume" command compilation for ARM, which was previously disabled

### Usage

For Linux-based guests:
  - Suspend can be triggered using: "echo mem > /sys/power/state" or "systemctl suspend"
  - Resume can be performed from control domain using: "xl resume "

For more information, refer to the official Linux kernel documentation on power management.

Note that currently, SYSTEM_SUSPEND is supported only for guest domains (not for
the hardware domain), and behaves as a logical standby. More details can be found in
the appropriate commit message and in the code comments.
---

TODO: enable "xl suspend" for ARM
---
Previous versions of this patch series:
  V1: https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg01093.html
  V2: https://marc.info/?l=xen-devel&m=166514782207736&w=2
  V3: https://lists.xenproject.org/archives/html/xen-devel/2025-03/msg00168.html


This is the first part of previous patch series and originally consist only
with necessary changes needed for guest domain suspend.

Mykola Kvach (4):
  tools/xl: allow resume command compilation for arm
  xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests
  SUPPORT.md: Document ARM PSCI and vPSCI support
  CHANGELOG: Mention Xen suspend/resume to RAM feature on arm64

 CHANGELOG.md                          |  1 +
 SUPPORT.md                            | 15 +++++++
 tools/include/libxl.h                 |  1 -
 tools/xl/xl.h                         |  2 +-
 tools/xl/xl_cmdtable.c                |  2 +-
 tools/xl/xl_vmcontrol.c               | 12 ++---
 xen/arch/arm/include/asm/perfc_defn.h |  1 +
 xen/arch/arm/include/asm/psci.h       |  2 +
 xen/arch/arm/vpsci.c                  | 64 +++++++++++++++++++++++++++
 9 files changed, 91 insertions(+), 9 deletions(-)

-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 09:20:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 09:20:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998155.1378944 (Exim 4.92)
	(envelope-from )
	id 1uJqTS-00032l-Sf; Tue, 27 May 2025 09:19:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998155.1378944; Tue, 27 May 2025 09:19: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 1uJqTS-00032e-P4; Tue, 27 May 2025 09:19:54 +0000
Received: by outflank-mailman (input) for mailman id 998155;
 Tue, 27 May 2025 09:19:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJqTR-0002b2-5d
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 09:19:53 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bede1c3a-3adb-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 11:19:52 +0200 (CEST)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-549b116321aso4270147e87.3
 for ; Tue, 27 May 2025 02:19:52 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5521b9f9decsm1663715e87.157.2025.05.27.02.19.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 02:19: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" 
X-Inumbo-ID: bede1c3a-3adb-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748337592; x=1748942392; 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;
        bh=V0A4iHWHgJ3OVUk46IxGg4V5avDY0YuDEfMj7z0UPvo=;
        b=dbXL7Ja27hauio6FLNp81DWR9NNrbkljcjODV8KKh1W4qmuAcexv3j/2UAe8OW4uBr
         L+LDTlGUMRoaQDdrMN5+t1vDFKMgE+2Ww8SWZdwxSFSj5Lv95v8mT/2Tj+seyl7PirKJ
         NO0gqbiw9wReLv1WGP3t0WgrNz4cVVZ0nH9VaW44rcQJtJ8dEzq66Ihevvg7Ljy5gzO/
         SF6kzbsLvGVm6+BGccgcOAF5/FT/Dx/nv4sflgsCdaV3Cqn9IwQPwMhtNjft/LxmUxYJ
         HceDd3EzD+MDd/aou225tnXicbtzJ8pZP78+IaezthZb+8HcjeyOkEaVN//qaJC7q6YZ
         oB9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748337592; x=1748942392;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=V0A4iHWHgJ3OVUk46IxGg4V5avDY0YuDEfMj7z0UPvo=;
        b=a7NjPVBIZafRkgoHfXoGMo9uASx2l9NnIiH4EXBCZnn8AfCQpM2jxFi5WKJSX/ap3r
         NCTxouooE12C+Ny8t++YgfVomKvCxbIpWFMpIb+ezJ+JCpnc7N5xdX5ZY8IuVTcuzE2Y
         tD5ywN8cw7vjSKHa2nntbGThaZGfDRSEWlrVlg6CF0g+bxeP50rGT2Ul/FvYVm341c/M
         LKFXvReCQeRTxjFdwZjJYZg1Od66N4xpQ25s/MIhAFmwRqqospRWZlqmrDhUDMlyFDHo
         QwtYKh5PoXGo0EZS7cw2bE6MvgGXuqTtsJKPGW8cCZOpPxXsGk4Pntft8I3vsvVnMd8Y
         Mbwg==
X-Gm-Message-State: AOJu0YxSckoflaRMyeJI1Q7kkWWwV7vdUA5rimw+pApF5S0n1ytOc0jH
	DETe0jXHab5cu4A2nPmxFOMOb/yMHdWaCufewl53uofcC8Q5cF7kCBlGdqnKPUJs
X-Gm-Gg: ASbGncshhydX6C/lQX7mvHWsy3tV/fvWR8GiHU9WIZPI51Wx5WUoIhV1+k5CZfKRPfy
	+tOyExSlnryfbT693pWxkfCeWzdJ0Oya0XN1bx3ITNWBmR/1ih9sl/1Jkt3CyqJfJZDKQY5Q1pS
	JRDpTdXI3dKWNLIKhNL65BEtZ/1STctVr0E8TBXsHssf2wlNmGim/MUoFrCJiqNreP+676rbiY5
	yTB96pdBAKBnTrD3Zwu2svhjaSozHUzbr5tLk4i+HzGlqBsH9vrQLG46RisRwcCSlEo0Sn6mZNV
	WtxUUiDuUzD5RMDa+zdZ+W1G4FY5e+Ax4wj4pgfKDmTqoE9Hpa3NtnIUiHPq83tcpQ+IN4eW8c4
	Zp8kQ8plqyO3L8hk=
X-Google-Smtp-Source: AGHT+IHTg8h0ECxQ6SiPB5yOGc+qjrBov5X5L6YLzQJlCTfel3hBbXp6k05FA1Guj3dGKyh/SP23OA==
X-Received: by 2002:a05:6512:3985:b0:553:2633:8a65 with SMTP id 2adb3069b0e04-55326338bcamr1101322e87.30.1748337591419;
        Tue, 27 May 2025 02:19:51 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v4][PART 1 2/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests
Date: Tue, 27 May 2025 12:18:55 +0300
Message-ID: <1a8313537603bee36636b0fcd2fdc2f76a2374fb.1748337249.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

This patch adds support for the PSCI SYSTEM_SUSPEND function in the vPSCI
(virtual PSCI) interface, allowing guests to request suspend via the PSCI
v1.0 SYSTEM_SUSPEND call (both 32-bit and 64-bit variants).

The implementation:
- Adds SYSTEM_SUSPEND function IDs to PSCI definitions
- Implements trapping and handling of SYSTEM_SUSPEND in vPSCI
- Allows only non-hardware domains to invoke SYSTEM_SUSPEND; for the
  hardware domain, PSCI_NOT_SUPPORTED is returned to avoid halting the
  system in hwdom_shutdown() called from domain_shutdown
- Ensures all secondary VCPUs of the calling domain are offline before
  allowing suspend due to PSCI spec
- Treats suspend as a "standby" operation: the domain is shut down with
  SHUTDOWN_suspend, and resumes execution at the instruction following
  the call

Usage:

For Linux-based guests, suspend can be initiated with:
    echo mem > /sys/power/state
or via:
    systemctl suspend

Resuming the guest is performed from control domain using:
      xl resume 

Signed-off-by: Mykola Kvach 
---
Changes in V3:
Dropped all domain flags and related code (which touched common functions like
vcpu_unblock), keeping only the necessary changes for Xen suspend/resume, i.e.
suspend/resume is now fully supported only for the hardware domain.
Proper support for domU suspend/resume will be added in a future patch.
This patch does not yet include VCPU context reset or domain context
restoration in VCPU.

Changes in V4:
Dropped all changes related to watchdog, domain is marked as shutting
down in domain_shutdown and watchdog timeout handler won't trigger
because of it.

Previous versions included code to manage Xen watchdog timers during suspend,
but this was removed. When a guest OS starts the Xen watchdog (either via the
kernel driver or xenwatchdogd), it is responsible for managing that state
across suspend/resume. On Linux, the Xen kernel driver properly stops the
watchdog during suspend. However, when xenwatchdogd is used instead, suspend
handling is incomplete, potentially leading to watchdog-triggered resets on
resume. Xen leaves watchdog handling to the guest OS and its services.

Dropped all changes related to VCPU context, because instead domain_shutdown
is used, so we don't need any extra changes for suspending domain.
---
 xen/arch/arm/include/asm/perfc_defn.h |  1 +
 xen/arch/arm/include/asm/psci.h       |  2 +
 xen/arch/arm/vpsci.c                  | 64 +++++++++++++++++++++++++++
 3 files changed, 67 insertions(+)

diff --git a/xen/arch/arm/include/asm/perfc_defn.h b/xen/arch/arm/include/asm/perfc_defn.h
index effd25b69e..8dfcac7e3b 100644
--- a/xen/arch/arm/include/asm/perfc_defn.h
+++ b/xen/arch/arm/include/asm/perfc_defn.h
@@ -33,6 +33,7 @@ PERFCOUNTER(vpsci_system_reset,        "vpsci: system_reset")
 PERFCOUNTER(vpsci_cpu_suspend,         "vpsci: cpu_suspend")
 PERFCOUNTER(vpsci_cpu_affinity_info,   "vpsci: cpu_affinity_info")
 PERFCOUNTER(vpsci_features,            "vpsci: features")
+PERFCOUNTER(vpsci_system_suspend,      "vpsci: system_suspend")
 
 PERFCOUNTER(vcpu_kick,                 "vcpu: notify other vcpu")
 
diff --git a/xen/arch/arm/include/asm/psci.h b/xen/arch/arm/include/asm/psci.h
index 4780972621..48a93e6b79 100644
--- a/xen/arch/arm/include/asm/psci.h
+++ b/xen/arch/arm/include/asm/psci.h
@@ -47,10 +47,12 @@ void call_psci_system_reset(void);
 #define PSCI_0_2_FN32_SYSTEM_OFF          PSCI_0_2_FN32(8)
 #define PSCI_0_2_FN32_SYSTEM_RESET        PSCI_0_2_FN32(9)
 #define PSCI_1_0_FN32_PSCI_FEATURES       PSCI_0_2_FN32(10)
+#define PSCI_1_0_FN32_SYSTEM_SUSPEND      PSCI_0_2_FN32(14)
 
 #define PSCI_0_2_FN64_CPU_SUSPEND         PSCI_0_2_FN64(1)
 #define PSCI_0_2_FN64_CPU_ON              PSCI_0_2_FN64(3)
 #define PSCI_0_2_FN64_AFFINITY_INFO       PSCI_0_2_FN64(4)
+#define PSCI_1_0_FN64_SYSTEM_SUSPEND      PSCI_0_2_FN64(14)
 
 /* PSCI v0.2 affinity level state returned by AFFINITY_INFO */
 #define PSCI_0_2_AFFINITY_LEVEL_ON      0
diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index d1615be8a6..866bd3128b 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -197,6 +197,57 @@ static void do_psci_0_2_system_reset(void)
     domain_shutdown(d,SHUTDOWN_reboot);
 }
 
+static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
+{
+    struct vcpu *v;
+    struct domain *d = current->domain;
+
+    /* Drop this check once SYSTEM_SUSPEND is supported in hardware domain */
+    if ( is_hardware_domain(d) )
+        return PSCI_NOT_SUPPORTED;
+
+    /* Ensure that all CPUs other than the calling one are offline */
+    for_each_vcpu ( d, v )
+    {
+        if ( v != current && is_vcpu_online(v) )
+            return PSCI_DENIED;
+    }
+
+    /*
+     * System suspend requests are treated as performing standby
+     * as this simplifies Xen implementation.
+     *
+     * Arm Power State Coordination Interface (DEN0022F.b)
+     *
+     * 5.20.2 Caller responsibilities
+     * The call is equivalent to using the CPU_SUSPEND call for the deepest
+     * possible platform powerdown state. Consequently, the caller must observe
+     * all the rules described for CPU_SUSPEND. See section 5.4.
+     *
+     * 5.4.5 Caller responsibilities
+     * The caller must not assume that a powerdown request will return using
+     * the specified entry point address. The powerdown request might not
+     * complete due, for example, to pending interrupts. It is also possible
+     * that, because of coordination with other cores, the actual state entered
+     * is shallower than the one requested. Because of this it is possible for
+     * an implementation to downgrade the powerdown state request to a standby
+     * state. In the case of a downgrade to standby, the implementation returns
+     * at the instruction following the PSCI call, at the Exception level of
+     * the caller, instead of returning by the specified entry point address.
+     * The return code in this case is SUCCESS. In the case of an early return
+     * due to a pending wakeup event, the implementation can return at the next
+     * instruction, with a return code of SUCCESS, or resume at the specified
+     * entry point address.
+     *
+     * 5.4.9 Implementation responsibilities: State on return
+     * When returning from a standby state, the caller must observe no change in
+     * core state, other than any timer changes expected because of the time
+     * spent in the state, and changes in the CPU interface because of the
+     * wakeup reason.
+     */
+    return domain_shutdown(d, SHUTDOWN_suspend) ? PSCI_DENIED : PSCI_SUCCESS;
+}
+
 static int32_t do_psci_1_0_features(uint32_t psci_func_id)
 {
     /* /!\ Ordered by function ID and not name */
@@ -214,6 +265,8 @@ static int32_t do_psci_1_0_features(uint32_t psci_func_id)
     case PSCI_0_2_FN32_SYSTEM_OFF:
     case PSCI_0_2_FN32_SYSTEM_RESET:
     case PSCI_1_0_FN32_PSCI_FEATURES:
+    case PSCI_1_0_FN32_SYSTEM_SUSPEND:
+    case PSCI_1_0_FN64_SYSTEM_SUSPEND:
     case ARM_SMCCC_VERSION_FID:
         return 0;
     default:
@@ -344,6 +397,17 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
         return true;
     }
 
+    case PSCI_1_0_FN32_SYSTEM_SUSPEND:
+    case PSCI_1_0_FN64_SYSTEM_SUSPEND:
+    {
+        register_t epoint = PSCI_ARG(regs,1);
+        register_t cid = PSCI_ARG(regs,2);
+
+        perfc_incr(vpsci_system_suspend);
+        PSCI_SET_RESULT(regs, do_psci_1_0_system_suspend(epoint, cid));
+        return true;
+    }
+
     default:
         return false;
     }
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 09:20:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 09:20:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998154.1378926 (Exim 4.92)
	(envelope-from )
	id 1uJqTR-0002ep-Km; Tue, 27 May 2025 09:19:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998154.1378926; Tue, 27 May 2025 09: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 1uJqTR-0002dr-Hb; Tue, 27 May 2025 09:19:53 +0000
Received: by outflank-mailman (input) for mailman id 998154;
 Tue, 27 May 2025 09:19:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJqTQ-0002b2-Gm
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 09:19:52 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id be366883-3adb-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 11:19:51 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-54e816aeca6so4798523e87.2
 for ; Tue, 27 May 2025 02:19:51 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5521b9f9decsm1663715e87.157.2025.05.27.02.19.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 02:19: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" 
X-Inumbo-ID: be366883-3adb-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748337590; x=1748942390; 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;
        bh=xndwR7wynsamXNuzcvxrIWc5e/ezZRdE6L/HotvgLv0=;
        b=LPecsNnOwRmo7ZV+j3R904wouyQPqee2ADhGnc3onSEHdfzADGcOQWL0ddGbaP8JSj
         fAlRIsaE/OOjdR4KqVmahCqgYPbfr5sTsTR70A7IDP7hITcsqVSOAqE4ixq7NPnAOgTP
         Aths3454ZMvCiIq1q7TpspZ8rjRqP8NTGujw88F4JWG/t+TY5wNIvVezYZMsmBxCgg3Y
         UG/uhPGgpCVndiiO9+OjRVc7wXb9bPgQNusNoHBpRZLcdT2++M4jrrpeW0u7h17NkPQB
         5kUNbFLchFoCs7RX1MiEXsY/blez0965S1Y8UVbd4HJwJ/gEcLjqwZamT6lnRTur3+Tp
         VL9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748337590; x=1748942390;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=xndwR7wynsamXNuzcvxrIWc5e/ezZRdE6L/HotvgLv0=;
        b=lKKp+WwCsd3sybYeLTXSwoFRz2Ml7xyLEnbaYWnA/cAEgCH26v695E9wCrutl6w84P
         SrYY/YEH+MHYBDCHzPgyazkYoRCesw2qWWGn/VIxjp37pamIsW8Jz5Klv3I287Em4VvP
         LI+v5NH0wAyWWqhaqfUmV/Ti0LTq4ZS8+UnBF2Ws2XfZQe2zDtAP4/DdPZ62YC2OGN3D
         f/TkXegl5u34J3xVq4tkiS3TvupEyzm+PTn/iaQAPoL7bLf8RRbXxqYKHI9YsMhc8i8C
         ehK0lKOOYtmWQyBm2RQw1tpPc8EgRYsJGnkheLVFtRQSog9hK1Z2nSeRLGWVDr1tsPpK
         fAUw==
X-Gm-Message-State: AOJu0YwZKEo3L3DT1QeVIdd19KmD4RJI0nYrFourf9HRxTllZwSKgZfM
	s3+lM8elWWuMcYcYB/aVyvNFyrQ4/6a8U/2GipudxYaEhcsvlayVxpXBMOUaDA==
X-Gm-Gg: ASbGncuZ5bgeD2Qyg5jlx5iYG4drhuFyXhyMMFIg2BH6/YEsFiDB73+K/F+kaRDqiRn
	kmcOthjJiu7kFIm1BOzNm1Qx70rJHBsY2pYTSNEI90HOGA2eRpKq9azLT04rkCP9KBm5sq9mzaj
	w/4w5FrNpbyU56o7L/n0s9y6vK9FaZTyNO1D0/103GCCs8uyAaJSVXrN3RLrU3G89W8h3fGjxo/
	e9S46nrN0WBz5C5f1D4HJJYYO3CTJ8imCShIdtyX59Lg1nsf7gn8VlAPsFNOrTh5QpIGe97typT
	wbafUCgRqpK09j9QLHUnZa+wn3ftXEbawTAO460kX5OElQJpaJ+5OUU8ncpHZF4qZvqICWb5Mrq
	+eBR6W7DetOVmvDw=
X-Google-Smtp-Source: AGHT+IEar2zBpSm2cqvH5LJ4fHxhg4H/HPUjTGCisIBKLZ1qxzlhX1cFPOwGFry+U/sjyhplSp/9aQ==
X-Received: by 2002:a05:6512:695:b0:549:8e5e:9d8e with SMTP id 2adb3069b0e04-5521c5a2ae1mr3943163e87.0.1748337590093;
        Tue, 27 May 2025 02:19:50 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Anthony PERARD ,
	Juergen Gross 
Subject: [PATCH v4][PART 1 1/4] tools/xl: allow resume command compilation for arm
Date: Tue, 27 May 2025 12:18:54 +0300
Message-ID: <0ec82eb500493370a2e4658c971ba225fef0ce0d.1748337249.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

The "xl resume" command was previously excluded from ARM builds because
system suspend/resume (e.g., `SYSTEM_SUSPEND`) via vPSCI was not
implemented. On x86, the command is used for ACPI S3 suspend/resume.

This change enables compilation of `xl resume` on ARM regardless of the
underlying implementation status, making the tool available for use in
testing or for future support. The libxl infrastructure and handler
functions are already present and usable.

Note: This does not imply full system suspend/resume support on ARM.
      "xl suspend" command still not work for arm platforms.

Signed-off-by: Mykola Kvach 
---
 tools/include/libxl.h   |  1 -
 tools/xl/xl.h           |  2 +-
 tools/xl/xl_cmdtable.c  |  2 +-
 tools/xl/xl_vmcontrol.c | 12 ++++++------
 4 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index b7ad7735ca..7216095570 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -1127,7 +1127,6 @@ typedef struct libxl__ctx libxl_ctx;
  * restoring or migrating a domain. In this case the related functions
  * should be expected to return failure. That is:
  *  - libxl_domain_suspend
- *  - libxl_domain_resume
  *  - libxl_domain_remus_start
  */
 #if defined(__arm__) || defined(__aarch64__)
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 45745f0dbb..5b0a481456 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -130,8 +130,8 @@ int main_migrate_receive(int argc, char **argv);
 int main_save(int argc, char **argv);
 int main_migrate(int argc, char **argv);
 int main_suspend(int argc, char **argv);
-int main_resume(int argc, char **argv);
 #endif
+int main_resume(int argc, char **argv);
 int main_dump_core(int argc, char **argv);
 int main_pause(int argc, char **argv);
 int main_unpause(int argc, char **argv);
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 06a0039718..4f662a4189 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -198,12 +198,12 @@ const struct cmd_spec cmd_table[] = {
       "Suspend a domain to RAM",
       "",
     },
+#endif
     { "resume",
       &main_resume, 0, 1,
       "Resume a domain from RAM",
       "",
     },
-#endif
     { "dump-core",
       &main_dump_core, 0, 1,
       "Core dump a domain",
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index c813732838..ebacde5482 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -38,11 +38,6 @@ static void suspend_domain(uint32_t domid)
     libxl_domain_suspend_only(ctx, domid, NULL);
 }
 
-static void resume_domain(uint32_t domid)
-{
-    libxl_domain_resume(ctx, domid, 1, NULL);
-}
-
 int main_suspend(int argc, char **argv)
 {
     int opt;
@@ -55,6 +50,12 @@ int main_suspend(int argc, char **argv)
 
     return EXIT_SUCCESS;
 }
+#endif
+
+static void resume_domain(uint32_t domid)
+{
+    libxl_domain_resume(ctx, domid, 1, NULL);
+}
 
 int main_resume(int argc, char **argv)
 {
@@ -68,7 +69,6 @@ int main_resume(int argc, char **argv)
 
     return EXIT_SUCCESS;
 }
-#endif
 
 static void pause_domain(uint32_t domid)
 {
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 09:25:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 09:25:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998198.1378974 (Exim 4.92)
	(envelope-from )
	id 1uJqYU-0007CZ-42; Tue, 27 May 2025 09:25:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998198.1378974; Tue, 27 May 2025 09: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 1uJqYU-0007CS-19; Tue, 27 May 2025 09:25:06 +0000
Received: by outflank-mailman (input) for mailman id 998198;
 Tue, 27 May 2025 09:25:04 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJqYS-0007CM-AG
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 09:25:04 +0000
Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com
 [2607:f8b0:4864:20::c31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 77616ff3-3adc-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 11:25:02 +0200 (CEST)
Received: by mail-oo1-xc31.google.com with SMTP id
 006d021491bc7-60402c94319so1447449eaf.1
 for ; Tue, 27 May 2025 02:25:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 77616ff3-3adc-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748337901; x=1748942701; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6DlyIgc4wsP5dpgdX2dvlV7LQrMg+Z3uJEcYLJjrogk=;
        b=elYcwug0BvYPM8HlXsW+sHr/6DeBHoJQKYJNiDjIr0tjs488o7SWqFu5+cjTTJa9zR
         co3ODExsPqIoDFcxmPK3Ye5hYDN9Kh30hI9r0PVGvbtFNiVqA9JprWDP5QrGDjmRU66z
         dioS8E0cS+TmSnfO1HOix93mwygzl8w+rDqk0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748337901; x=1748942701;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=6DlyIgc4wsP5dpgdX2dvlV7LQrMg+Z3uJEcYLJjrogk=;
        b=gOCAdMtvRQQTVeymUZC6tDO0DenbUbuny5B3hw0Cw3s3L89IlncF7NKCnbuQ8Uc2MF
         CnAHqf1ls4pCjtFgrXHoqh9CAUT7vDHyE7zXp0D2qJm1eiVsdQFDurOFpwYoOCJDJolB
         bow8baRfLWnUoMN2mrlsmxtRulFT6eOfectcc42cwYPK2g8WvCtRC0xxb3N05o8UBRXg
         X6EjVwyt1huz0SigA2iBOyNJEJ7rc5k9W1mh1Pn4FnIB4DxMhpZAsrKh7m7atpT0KFKs
         seVmkDF1TiydGWspasxp7ko2rerDXos8uvStyObVv4bNEgUzXBwFUuWTlkbkC2ICOP5U
         yimg==
X-Gm-Message-State: AOJu0YyR3M5duw2h9bX9owSMbJwF3ft+4QESyYhP/h6ZvcTnDdh07mFm
	FaXa6QNJwv4e0ne945eepZIPdUJQOhLgA4AGFLVoNYImjg7RmgVjiH39rTe6LKFKKBaqcICGpvz
	zlzWSWaB2e6okcUdbjAqEZccs02t2rALOwAQarwiA
X-Gm-Gg: ASbGncsSK3mXWMBN0hBQMvWMZ9OLSuQ/jOMPS8kOwEHufi0mcK1NuksMX6UIr/p0Ri6
	31fGivw0CJJJ9obbn6gg5fS9/USV/ORW//lmp9vyh676N66wv6Pzrt8jM0fnmA+uo30h1zw1uW2
	Xp7TxsyGKluwRvAMysnYb01dqGkcrE6Cc=
X-Google-Smtp-Source: AGHT+IHjnGh+A5raDR6s7GdT0JaNmMLoghM0PB6lFoveyzPD+FVw8RnwN8+Zq53E5tdjFyJXvfi9jeQN8NzYFm4JjYY=
X-Received: by 2002:a4a:ec42:0:b0:60b:c9a6:1d3d with SMTP id
 006d021491bc7-60bc9a61da2mr1337107eaf.4.1748337901295; Tue, 27 May 2025
 02:25:01 -0700 (PDT)
MIME-Version: 1.0
References: <20250512144656.314925-1-ross.lagerwall@citrix.com>
 <20250512144656.314925-5-ross.lagerwall@citrix.com> 
In-Reply-To: 
From: Ross Lagerwall 
Date: Tue, 27 May 2025 10:24:49 +0100
X-Gm-Features: AX0GCFsc-BcA2B-DvBZ5R3DEkSvnrZnZqzUQvAUFCj_YuTxzM9goCBYwNd3qSto
Message-ID: 
Subject: Re: [PATCH v2 4/5] libxc/PM: Ensure pxstat buffers are correctly sized
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD , 
	Juergen Gross , Jan Beulich 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 26, 2025 at 3:04=E2=80=AFPM Anthony PERARD  wrote:
>
> On Mon, May 12, 2025 at 03:46:55PM +0100, Ross Lagerwall wrote:
> > diff --git a/tools/libs/ctrl/xc_pm.c b/tools/libs/ctrl/xc_pm.c
> > index ff7b5ada053f..cffbd1b8a955 100644
> > --- a/tools/libs/ctrl/xc_pm.c
> > +++ b/tools/libs/ctrl/xc_pm.c
> > @@ -46,35 +46,33 @@ int xc_pm_get_pxstat(xc_interface *xch, int cpuid, =
struct xc_px_stat *pxpt)
> >  {
> >      struct xen_sysctl sysctl =3D {};
> >      /* Sizes unknown until xc_pm_get_max_px */
>
> This comment can be removed now.
>
> > -    DECLARE_NAMED_HYPERCALL_BOUNCE(trans, pxpt->trans_pt, 0, XC_HYPERC=
ALL_BUFFER_BOUNCE_BOTH);
> > -    DECLARE_NAMED_HYPERCALL_BOUNCE(pt, pxpt->pt, 0, XC_HYPERCALL_BUFFE=
R_BOUNCE_BOTH);
> > +    DECLARE_NAMED_HYPERCALL_BOUNCE(trans, pxpt->trans_pt,
> > +                                   pxpt->total * pxpt->total,
> > +                                   XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> > +    DECLARE_NAMED_HYPERCALL_BOUNCE(pt, pxpt->pt, pxpt->total,
> > +                                   XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
>
> I don't think the macro takes the sizeof(*pt) or sizeof(*trans_pt) into
> account when using the size provided. So it doesn't looks like you can
> use `pxpt->total` alone, and you still need to multiple it by sizeof(*)
> like it was done in the HYPERCALL_BOUNCE_SET_SIZE() call.

Indeed I realized this when testing a v3 of this series. I'll send a
new version now.

Thanks,
Ross


From xen-devel-bounces@lists.xenproject.org Tue May 27 10:05:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 10:05:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998219.1378995 (Exim 4.92)
	(envelope-from )
	id 1uJrBT-0006rx-5C; Tue, 27 May 2025 10:05:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998219.1378995; Tue, 27 May 2025 10:05: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 1uJrBT-0006rq-22; Tue, 27 May 2025 10:05:23 +0000
Received: by outflank-mailman (input) for mailman id 998219;
 Tue, 27 May 2025 10:05:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJrBS-0006rk-Fo
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 10:05:22 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 197e8360-3ae2-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 12:05:21 +0200 (CEST)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-55324e35f49so1760313e87.3
 for ; Tue, 27 May 2025 03:05:21 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32a701214afsm1042331fa.72.2025.05.27.03.05.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 03:05: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" 
X-Inumbo-ID: 197e8360-3ae2-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748340321; x=1748945121; 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;
        bh=cl9xmdJKDQyhi2sVddtS7UKISQv1pEk5JbYWfqtFKVc=;
        b=cDy03u8ysCz/cwOETnE5IjSxgMJdTl419Ch8cSWLyf/4Sq4pkUFxJb0DvJrV5PonT1
         IB/EWwmpjaxdK2WSfO1eU/aGBpUDqwEvdfMUIFkqKrPX3bKIx8M3Lgv0u1pqPuaVbVPZ
         ZFrzCQsFE51KSfBSFcOCnabpCX18XD5bFnX/yCkIk0q04ykVpr4vjEIdWMHdMXD2cnUi
         dF1h3xRFhvgHBjg/5JhPa4pMYy+fFXs/g+IHZxR19o7+8ogKD5kYvBAuGPgKzVfn29IV
         wuXNHkh95/UoWY/pAPX1/j77+Pvd9Xq5e6XlOyBqR8mndCpQ8L8KdCYUamF0Px2v+MY3
         Jegg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748340321; x=1748945121;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=cl9xmdJKDQyhi2sVddtS7UKISQv1pEk5JbYWfqtFKVc=;
        b=MnzwvNAz3UgVItoke4YDbRiPeMrK8CEKgTvsR7hoslJLVhcN5C2Ro6eYnPCdVgEi7/
         jQ3i6f4mu7xc7m8zzF7ON5qPieSvQnl5DJ0sITeGr3I4MTORXth3P/y34WA1yhcwEeUS
         njT/+qx4rFhlYb/bNs1w96d+tBY6R0lCr/bob8fC2j0/+LlfMuh0IcbrTtFSmGzhiFVa
         MK+zoyDpjmB2C4xzjJekHWj1xs3jUSc1kGlX9DyxnwWDhy4C3JBDk5kmnXxLI9osyJp7
         0LmEPT6tMxX8laSNey6izU+GNuAofE6coLlCCPwwGGQuOwRZNeTzyJ28ePMVuJe6o2EO
         Mb0w==
X-Gm-Message-State: AOJu0YwWD3arSGckA4dbNSow5cFULZ28u05nR/HPGYG9Nko3BlmU1T1u
	cwIxOZK6GE75q2xykH+jKreH2352rk76PsqLqcdv/PmVTjC7hgJ0oUbjL3IRow==
X-Gm-Gg: ASbGnctfvoc3t/yd/iabLCaazF9I7iaZQt3OhGbaGVtxXJe5JcIdKi8CIvDxZH1OMiq
	8ydLJSbKdR2o17nA3I7bwkuR6KK0OuD4cj/ixszn03kyR3i0CYA0vbmWf8yfw+1IJP0EYUlqt8i
	7kXfR9yUgQkZD6A6/KmNTmXgdX4qeb62GCVxXKygk6C67PmC+wGd10TJrmLjiVZMlz/iZhE9foY
	tJtarLrZNKt7txasx1uSV/OUmPCia9P1aA1v9BYq98xjA99L1JAi+uPwzVuTxuQuN8+rM5hyDTd
	dEKtJT31taSa0Umm7zgLTLomAPMpzV1fEceKQWbs3qFFRHbGDQQnpb8ylsucccbthyp8vveS274
	+NeBHUQQHLvtb9S0vcym3bbLQTw==
X-Google-Smtp-Source: AGHT+IHtA5cbQXcv66vLIJ+B0V9HQvGx0l9+/ek5jA6SaPzu3djOQb096zzrHJ5YSqEbRokBPx7zTQ==
X-Received: by 2002:a2e:a595:0:b0:32a:72de:c640 with SMTP id 38308e7fff4ca-32a72dec858mr850851fa.38.1748340320292;
        Tue, 27 May 2025 03:05:20 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/ACPI: move scheduler enable/disable calls out of freeze/thaw_domains
Date: Tue, 27 May 2025 13:04:16 +0300
Message-ID: <974033e9ff0df3ce8a74efaa33f1cee1dcbdb030.1748340071.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

The scheduler_disable and scheduler_enable calls have been removed
from freeze_domains and thaw_domains, respectively, and relocated
to their usage context in enter_state. This change addresses
the concern about misleading function semantics, as the scheduler
operations are not directly related to the domain pausing/resuming
implied by the freeze/thaw naming.

Suggested-by: Jan Beulich 
Signed-off-by: Mykola Kvach 
---
The discussion about these changes can be found here:
https://lists.xenproject.org/archives/html/xen-devel/2025-03/msg00229.html
---
 xen/arch/x86/acpi/power.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 095ca391ad..448aa9f3a7 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -151,16 +151,12 @@ static void freeze_domains(void)
     for_each_domain ( d )
         domain_pause(d);
     rcu_read_unlock(&domlist_read_lock);
-
-    scheduler_disable();
 }
 
 static void thaw_domains(void)
 {
     struct domain *d;
 
-    scheduler_enable();
-
     rcu_read_lock(&domlist_read_lock);
     for_each_domain ( d )
         domain_unpause(d);
@@ -216,6 +212,7 @@ static int enter_state(u32 state)
     printk(XENLOG_INFO "Preparing system for ACPI S%d state.\n", state);
 
     freeze_domains();
+    scheduler_disable();
 
     acpi_dmar_reinstate();
 
@@ -334,6 +331,7 @@ static int enter_state(u32 state)
     mtrr_aps_sync_end();
     iommu_adjust_irq_affinities();
     acpi_dmar_zap();
+    scheduler_enable();
     thaw_domains();
     system_state = SYS_STATE_active;
     spin_unlock(&pm_lock);
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 10:28:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 10:28:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998232.1379006 (Exim 4.92)
	(envelope-from )
	id 1uJrXR-00021A-OH; Tue, 27 May 2025 10:28:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998232.1379006; Tue, 27 May 2025 10: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 1uJrXR-000213-LB; Tue, 27 May 2025 10:28:05 +0000
Received: by outflank-mailman (input) for mailman id 998232;
 Tue, 27 May 2025 10:28:04 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJrXQ-00020v-TW
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 10:28:04 +0000
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com
 [2a00:1450:4864:20::329])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3e86f851-3ae5-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 12:27:52 +0200 (CEST)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-442eb5d143eso34488155e9.0
 for ; Tue, 27 May 2025 03:27:55 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4d9982c96sm5323425f8f.64.2025.05.27.03.27.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 03:27: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" 
X-Inumbo-ID: 3e86f851-3ae5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748341675; x=1748946475; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/Cn3kZtLDnaDZ3kTw3vFwSxIIaokAbnFgenElSMn6SE=;
        b=g+U6AkI8fHEiiHVa/fDsxeuOz03Ae4/jfd9ZsFXYRApv9P1AETHodUZW/uOo1+H55W
         cMq0qmo3inae1GJahIQSu/vTEsjMz2D1ZCZxsJbjzDgFme+x8Oqta4x0JWzPNgQZw11X
         cE7KijSMlU1kgwQ5XfOaqZh/ILqh8+YDazNj0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748341675; x=1748946475;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/Cn3kZtLDnaDZ3kTw3vFwSxIIaokAbnFgenElSMn6SE=;
        b=lijh/H5YluHvd+TwCR5atHJowt7FgW/NPhDoPI2ZqLFD87yvhSc5O64csx3hctRmet
         6yikeNk5nL8NN5oi1dgUuR7BKDR4grMMtQVXpVAcxMsl57qqyCQ3BWsr2rgfcjJ3Udxh
         +AoN6TpnEWk25fZL9B2+MMAaJi7PcoOsaX5BeGVlSKhTGjhMqtDITR38EAi7a67I+In6
         eDKGcWC2AMm0LggK+n2wp8+CZNsAswXbt7WtN4IFNxZ5GUe4HriLVxJ6CD6PmLer+qqf
         myTt+iUU8/btgshNOt0Sj8kHVAhNsF97M1qyUsLymWaTHWt2+c7eBbbR7bHPxZY2yvx+
         43xg==
X-Forwarded-Encrypted: i=1; AJvYcCUXbP9Daz08vEIOK0jyN5o9UOEwUL54TcgmbYUvoY1uB/tgJd7LZF/TVo8DjXfuT+9XeoZidXh7eeQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwZ2DkXR+71hqcZizMXF/DHWrrJTUdNW0HZ0i45D7XdEYdSUs+Z
	wdqdg7D2aFi0QvnthFc7HpXQo3Wtn/89pV5V4WLyZPsAVNU8Va0VunGmjPxVVFrl8Jg=
X-Gm-Gg: ASbGncs9EaMhMxgbCMZ5as2bfBgJx2wa/sKJCNKilBGFCU0UpcSfG4QYltnF8C0e4hQ
	T4lFlfKEvyn989mhInt6hyMRcOQfEK7QLtkTjdS0Y2c688WqSCu479hxAo3W9EYYgKF9rc7crvK
	Ls3BWu6ye7nX/VO+vQ/Qh7ixj8Tb82N5JesT9/dTISewrLg19lmwUcVrCltWWnK+woQ2C03OvaT
	VAETfwk/pm1BL1fMw2F5P/RhqCFf+71QW078vjqxcVl+/qbMtIx/xizPJ3OkUmJ51+CQTNHQQc9
	HL9yMecCs7OqWcD66OnLlLTnn8Jx1YCtAq/UwVQ/p22PtImxl4qyMwzfdDcHWN9N3wimqlmgxOX
	66pOyfjV4QZT4ECV4
X-Google-Smtp-Source: AGHT+IHMXI6/cx7U53XJhevZs9GwhIg+y+pzU9y72Jg938zG3dASdMd3d45Ri1xyAltcjOUOEMZxNw==
X-Received: by 2002:a05:600c:4683:b0:43c:fe5e:f03b with SMTP id 5b1f17b1804b1-44c932f9572mr117959115e9.30.1748341675095;
        Tue, 27 May 2025 03:27:55 -0700 (PDT)
Message-ID: 
Date: Tue, 27 May 2025 11:27:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/hvmloader: fix order of PCI vs MTRR initialization
To: Roger Pau Monne , xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
 Anthony PERARD 
References: <20250527085504.77444-1-roger.pau@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: <20250527085504.77444-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27/05/2025 9:55 am, Roger Pau Monne wrote:
> After some recent change the order of MTRR vs PCI initialization is
> inverted.  MTRR will get initialization ahead of PCI scanning and sizing of
> MMIO regions.  As a result when setting up MTRRs the MMIO window below 4GB
> will always have the same size, and there will be no window above 4GB.
> This results in malformed and incomplete MTRRs being setup.
>
> Fix by making sure PCI is initialized ahead of MTRR, also add a comment to
> notice the ordering dependency.
>
> Fixes: 2c3dffbaa324 ('tools/hvmloader: Replace LAPIC_ID() with cpu_to_apicid[]')
> Signed-off-by: Roger Pau Monné 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Tue May 27 10:59:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 10:59:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998251.1379027 (Exim 4.92)
	(envelope-from )
	id 1uJs1p-0006mG-2T; Tue, 27 May 2025 10:59:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998251.1379027; Tue, 27 May 2025 10: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 1uJs1o-0006m9-Vf; Tue, 27 May 2025 10:59:28 +0000
Received: by outflank-mailman (input) for mailman id 998251;
 Tue, 27 May 2025 10:59:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJs1n-0006lz-Jy
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 10:59:27 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a4eda8ae-3ae9-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 12:59:21 +0200 (CEST)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3a4c9024117so2462410f8f.0
 for ; Tue, 27 May 2025 03:59:25 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-447f38142f1sm264813715e9.31.2025.05.27.03.59.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 03:59: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" 
X-Inumbo-ID: a4eda8ae-3ae9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748343565; x=1748948365; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=h29etSjYCith9Rt5c0e0WrcOLkdV6ZSMP06fnHdPpL4=;
        b=goMv7xAZEp2Naixd32ZF6IDWG9JKaSQY7nZBf6eeKhZZNiBotryLlidlze/VFGlpBG
         9q1ElIYfRfTGTXv5WIL6UuBqizB2hWvJX5/tNk400+V+eFJBt/RM4qRbx/mS0zBJ3LeB
         WMNq+x8BCyRtqUZ4R5qTfQ6A6mSVlZClhPT1w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748343565; x=1748948365;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=h29etSjYCith9Rt5c0e0WrcOLkdV6ZSMP06fnHdPpL4=;
        b=Kse17QXrtnAJcbT/4+nNKXj/x5x9vRixn1uYJv8JHU7FDbeVu6PE7VSPCa9VK5mwR2
         GbCq98YhLSoz93zwgDmFAfmw7zebS8hntvpx9usz7rrKSVTUjXVbEk4WSm4HoaAE+xCw
         8l3l5D87J7qELMyb1rx6Gvdz6lLXE1pFKhbOTVaUgguwWv0PuYBhDHFfqvOuiaPS7fJb
         tBoginfkku7JUPHGk0dKibIdpyK+ayMuECWI5aCiVFsmbh3vEufqsxMlqWJDrDFcGEp7
         hEa+Jk8dw4fy5EAxfhwM0+/6N4m8llwon3hvBKVZ068nWXoM/PCfsBuvvos2NI+UGwQm
         VRoA==
X-Gm-Message-State: AOJu0YyruyejfAVpnXyxKzWlohgcrnzF3Wsd6KAeJrQ8K2v7hUsfhT8V
	ul0K0ewB9FYSLejcuwWKn6Dkl8Z0Q2dIgmyY2Gtu1nwKFFFtli7/0G6ykTyQPIiJESw=
X-Gm-Gg: ASbGncs5W663Dcs4dPeK46SdsG645aWYx9PyzJBbwQM4Hcjy/QwmDpByAwv3XRsqlkl
	UA9JLQDRyHMPI8MMaBON8DQjT6T7xEw71trOrtRQHoDfJCnw9hsLo8yBLy11xJ8i8ah7GQUhD6Z
	AQif+c5JhZKu/0UgCymfNSxEqZOWYNKj6+aDHGrb8tJCKwUtRV5yhfr9u/crXKd0P6hz40fmmQQ
	D0pQYuk3iiJIA997KlPGRgOlSVLE92bAkXopmX7lcqf+lXVe1tbhIa/MNSwBCHjPQ+/1d1nMolr
	VWQkAm+YBusQHpCGcLvu4y/q2MmC4/JuRnWabtfW1kZA4ILCcNIe5iDKDz+f/fo71XrBTpCtVAl
	KaHHG3hvJEOtAVlLOPc/L8GhA
X-Google-Smtp-Source: AGHT+IEKuiuhECiy38BXHjHEquj1+nXtx9Zw7dyv3TzAo0XzE968/F4NksSqH+zi9ZhjBTz0iGE8yw==
X-Received: by 2002:a05:6000:4012:b0:3a4:e238:6496 with SMTP id ffacd0b85a97d-3a4e5e9e265mr103570f8f.18.1748343564908;
        Tue, 27 May 2025 03:59:24 -0700 (PDT)
Date: Tue, 27 May 2025 12:59:23 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Manuel Bouyer ,
	Jan Beulich 
Subject: Re: [PATCH] x86/pv: Fix breakpoint reporting
Message-ID: 
References: 
 <20250526205302.997387-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: <20250526205302.997387-1-andrew.cooper3@citrix.com>

On Mon, May 26, 2025 at 09:53:02PM +0100, Andrew Cooper wrote:
> x86_merge_dr6() is not a no-op when 0 is passed in; it will discard the
> previously latched breakpoint bits.
> 
> The combination of do_debug()'s manual call to x86_merge_dr6() for external
> debuggers, and pv_inject_DB() calling pv_inject_event(), results in two
> x86_merge_dr6() calls.
> 
> Feed the same pending_dbg in the second time.  This makes pv_inject_event()'s
> update of dr6 effectively a no-op, retaining the correct breakpoint bits.
> 
> Fixes: db39fa4b27ea ("x86/pv: Fix merging of new status bits into %dr6")
> Reported-by: Manuel Bouyer 
> Signed-off-by: Andrew Cooper 

Acked-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue May 27 11:30:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 11:30:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998259.1379037 (Exim 4.92)
	(envelope-from )
	id 1uJsVY-0003Vu-9W; Tue, 27 May 2025 11:30:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998259.1379037; Tue, 27 May 2025 11:30:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJsVY-0003Vn-6y; Tue, 27 May 2025 11:30:12 +0000
Received: by outflank-mailman (input) for mailman id 998259;
 Tue, 27 May 2025 11:30:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJsVW-0003Vh-QU
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 11:30:10 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f0110930-3aed-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 13:30:06 +0200 (CEST)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-6049431b409so3343918a12.3
 for ; Tue, 27 May 2025 04:30:06 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60451d367cfsm4440534a12.22.2025.05.27.04.30.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 04: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" 
X-Inumbo-ID: f0110930-3aed-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748345405; x=1748950205; darn=lists.xenproject.org;
        h=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;
        bh=1GQfAaP+lLUrK5yrJj9zn8WsI4xfEXBm9NfT0JYhQ6o=;
        b=KsPwsMCiO1gw9b/DmcF/4gJWBJrQjIuVaDrDY0WW1wA+0tvYtrEiwGiyvb8/n0QHbF
         nd5fFPzcwGgTTeEZBjrQiHedvSDsqyh5Xxv4BDwqU7pum8I3ZRJrWtWb4votTXbDwXI1
         E+IbrRm6T8+7FSpFrL2LO1V2qgTYNcAv8b54f1WZ7nPQqw0z6YGnoQn5caNCiBFAOHDq
         9piKfkXfzj0+0R4B6Ns+LfLLeFZ3YavvA/qFbAJLoGBdju7VBUhDNFGIDGWq4LfnYzl3
         p02gWeeJWUGn4RTI1wHwrmk4hMuIHw7k5BaJof8a5mxVV4RFjpPovlfb6FtEX2i6ZclD
         Y5tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748345405; x=1748950205;
        h=in-reply-to:content-language:references:cc:to:from:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=1GQfAaP+lLUrK5yrJj9zn8WsI4xfEXBm9NfT0JYhQ6o=;
        b=DX2KtgNkDphKi996h+cKBomx+CwMrZ5EcPPMU1+LlygPuRz8SGKtfOjziBYzui42rF
         uFaGqkLckxwCl5GPuSuEo/+WlNm6yVTLdwNvRdlv9dhmAHrFLi8CmGm9Pjk1B2itCrOY
         gkA7CEy/XKHLpEqAzb4Mfz/eTcexffsP1rXI2qRGT6kOnKmvqtGw4v9w4ggp2BBJdxPP
         JJlPXXGY5y7B6zDk2r8GNF+Wk9cFwAlzMQA+Y5+yLcH7NmVbrdHYEFygd8im77PVfi1s
         zkqFRKUTV1D4o0VzKjVMSzOBt0NIr61D6xsctDGB98udPmsm7l09IWveLGh+iZOjOShk
         bpOg==
X-Forwarded-Encrypted: i=1; AJvYcCW0LT977i1xpuPYtbgErwZxYwTMwaiRAvdhNgVtwTowla+rwsMF8UOBodov3f7Col8tqKw61LpSqK0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyqAy5WwNftDUHSg58hEinELdP4M3GhT4RxGfT9OfHnleL0mr5y
	8wVrN9S2cucr1gclY4Z9LUOu3fXGb4MvYRvkEnaZmXggr7wITXZgr9G4
X-Gm-Gg: ASbGnctmUccQLUlNWOhb3dDuedjpS76Y9ik1FF5rHYnXjDUcrSCFM3qkqoS+dnnvaRv
	8KhvpHLFC55kD3fF2XkGUCMdhJ4kpibxPpeZL6Mc1nEnukLYh/dhOh7lb8yB3MNQNVQh4UGQbEU
	jrGeLpCuFjoGxtIh306lHDjx5PZYs4L5eMrw22MlC5jvxSQcrfWemkNdGt1gL78PsgkpONSRdsT
	DKvP5ts5KxOCAzaAcO2WzOBgcvGbrFFQQnWwz+CTEWCRy1b4/1GFShf5mGTpVdgXAlgpbFLWDWj
	bByfcpr26b8cyqHrJ+DHzrJaZ3YadGgqSGeWk7tABsMUalnvc61gMz2OzCv6LX+2p2BsGYly7Lj
	dCWDN6gh34w+LwpSx9Nmq6BPq
X-Google-Smtp-Source: AGHT+IHaxnl3Dfkx0Do1O/z3xSjAT/Xe64liVkJCAfXwRpUIVDj7vgNrKWpkMAL8HleLV7usLg/d7w==
X-Received: by 2002:a05:6402:35c7:b0:601:9943:2eb9 with SMTP id 4fb4d7f45d1cf-602da5f8c2cmr10001492a12.24.1748345405103;
        Tue, 27 May 2025 04:30:05 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------m9za0OYIcoAqlIfaLFoZTiUk"
Message-ID: <84c9f65a-b278-4be4-b053-5bfa410f9a97@gmail.com>
Date: Tue, 27 May 2025 13:30:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/14] xen/riscv: imsic_init() implementation
From: Oleksii Kurochko 
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <421dad1bbd014a2d7ff588af088eadbd56345dbe.1747843009.git.oleksii.kurochko@gmail.com>
 
 
Content-Language: en-US
In-Reply-To: 

This is a multi-part message in MIME format.
--------------m9za0OYIcoAqlIfaLFoZTiUk
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/26/25 8:44 PM, Oleksii Kurochko wrote:
>>> +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
>>> +                               &imsic_cfg.guest_index_bits) )
>>> +        imsic_cfg.guest_index_bits = 0;
>>> +    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
>>> +    if ( tmp < imsic_cfg.guest_index_bits )
>>> +    {
>>> +        printk(XENLOG_ERR "%s: guest index bits too big\n",
>>> +               dt_node_name(node));
>>> +        rc = -ENOENT;
>>> +        goto cleanup;
>>> +    }
>>> +
>>> +    /* Find number of HART index bits */
>>> +    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
>>> +                               &imsic_cfg.hart_index_bits) )
>>> +    {
>>> +        /* Assume default value */
>>> +        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
>>> +        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
>>> +            imsic_cfg.hart_index_bits++;
>> Since fls() returns a 1-based bit number, isn't it rather that in the
>> exact-power-of-2 case you'd need to subtract 1?
> Agree, in this case, -1 should be taken into account.

Hmm, it seems like in case of fls() returns a 1-based bit number there
is not need for the check:
  (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )

We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without
checking *nr_parent_irqs is power-of-two or not, and then just leave the
check (2).
And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if
I amn't mistaken something. And if I'm not mistaken, then probably it make
sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this
case is so special.

Does it make sense?

~ Oleksii

--------------m9za0OYIcoAqlIfaLFoZTiUk
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/26/25 8:44 PM, Oleksii Kurochko
      wrote:
    
    
    
    
    
      
    
        
    
          
    +    if ( !dt_property_read_u32(node, "riscv,guest-index-bits",
+                               &imsic_cfg.guest_index_bits) )
+        imsic_cfg.guest_index_bits = 0;
+    tmp = BITS_PER_LONG - IMSIC_MMIO_PAGE_SHIFT;
+    if ( tmp < imsic_cfg.guest_index_bits )
+    {
+        printk(XENLOG_ERR "%s: guest index bits too big\n",
+               dt_node_name(node));
+        rc = -ENOENT;
+        goto cleanup;
+    }
+
+    /* Find number of HART index bits */
+    if ( !dt_property_read_u32(node, "riscv,hart-index-bits",
+                               &imsic_cfg.hart_index_bits) )
+    {
+        /* Assume default value */
+        imsic_cfg.hart_index_bits = fls(*nr_parent_irqs);
+        if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )
+            imsic_cfg.hart_index_bits++;

    
        
    
        
    Since fls() returns a 1-based bit number, isn't it rather that in the
exact-power-of-2 case you'd need to subtract 1?
    
      
    
      
    Agree, in this case, -1 should be taken into account.
    
    
    
    
    Hmm, it seems like in case of fls() returns a 1-based bit number there
is not need for the check:
 (2) if ( BIT(imsic_cfg.hart_index_bits, UL) < *nr_parent_irqs )

We could do imsic_cfg.hart_index_bits = fls(*nr_parent_irqs - 1) (1) without
checking *nr_parent_irqs is power-of-two or not, and then just leave the
check (2).
And with (1), the check (2) is only needed for the case *nr_parent_irqs=1, if
I amn't mistaken something. And if I'm not mistaken, then probably it make
sense to change (2) to if ( *nr_parent_irqs == 1 ) + some comment why this
case is so special.

Does it make sense?

~ Oleksii

    
  


--------------m9za0OYIcoAqlIfaLFoZTiUk--


From xen-devel-bounces@lists.xenproject.org Tue May 27 12:07:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 12:07:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998282.1379067 (Exim 4.92)
	(envelope-from )
	id 1uJt5u-000815-3D; Tue, 27 May 2025 12:07:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998282.1379067; Tue, 27 May 2025 12:07: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 1uJt5t-0007z0-Sh; Tue, 27 May 2025 12:07:45 +0000
Received: by outflank-mailman (input) for mailman id 998282;
 Tue, 27 May 2025 12:07:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJt5s-0007kN-Ld
 for xen-devel@lists.xen.org; Tue, 27 May 2025 12:07:44 +0000
Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2bad0926-3af3-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 14:07:35 +0200 (CEST)
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJt5c-0051aO-2v;
 Tue, 27 May 2025 12:07:28 +0000
Received: from julieng by xenbits.xenproject.org with local (Exim 4.96)
 (envelope-from ) id 1uJt5c-007iTv-2W;
 Tue, 27 May 2025 12:07: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" 
X-Inumbo-ID: 2bad0926-3af3-11f0-b894-0df219b8e170
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 468 v3 (CVE-2025-27462,CVE-2025-27463,CVE-2025-27464)
 - WinPVDrivers: Excessive permissions on user-exposed devices
Message-Id: 
Date: Tue, 27 May 2025 12:07:28 +0000

--=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-2025-27462,CVE-2025-27463,CVE-2025-27464 / XSA-468
                                   version 3

      WinPVDrivers: Excessive permissions on user-exposed devices

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

The Windows PV drivers expose various facilities to userspace.  Several
of these have no security descriptor, and are therefore fully accessible
to unprivileged users.  These are:

  1. XenCons,  CVE-2025-27462
  2. XenIface, CVE-2025-27463
  3. XenBus,   CVE-2025-27464

IMPACT
======

Unprivileged users inside the guest can escalate privilege to that of
the guest kernel.

VULNERABLE SYSTEMS
==================

All Windows virtual machines running the Windows PV drivers are
vulnerable.

The xencons driver was first available in the 9.0.0 release, and is
vulnerable since its introduction.

The xeniface and xenbus drivers are vulnerable in all releases.

MITIGATION
==========

A PowerShell script to mitigate the issue in the XenIface driver has been
developed.  It is a single-shot script which can either scan for the
vulnerabilities, or fix them by inserting the relevant security descriptors
into the registry and the running device objects.  See the script for full
invocation information.

Because attaching PowerShell scripts to emails causes them to be
rejected by several major service providers, the script is instead
available from:

  https://paste.vates.tech/?415ce4adb9dde353#6REZBQosbawepd8RcCWrhZ5H3euYSNXGcfHr6hrwU2om
  password: 79322bc8-94fe-42f6-8b81-8373fa9458d0
  sha256: db45e6123312cf9a3a2136f903f82826556915b76b5149b00eeefbe0a2912107

It has only been lightly reviewed by the Xen Security Team.  Feedback
welcome.

CREDITS
=======

This issue was discovered by Tu Dinh of Vates

RESOLUTION
==========

Applying the attached paches resolves this issue.

xsa468/xenbus-01.patch             Windows xenbus
xsa468/xencons-0?.patch            Windows xencons
xsa468/xeniface-0?.patch           Windows xeniface

Note: xeniface-03 and 04 are not being treated as security issues, but
are included for downstreams wishing to include them in the same WHQL
testing run.

$ sha256sum xsa468*/*
3c4fbc0526c2a099e0866f9483c545605ab30c7bae8cfbfc7deea7f491b34ac3  xsa468/xenbus-01.patch
7336ce0fd1df73921ec4246bf71ccd8709a8fae20c056e7aba231f34ebccefc9  xsa468/xencons-01.patch
bbacf952c8f78ec6d0ea8ae25d6b1a5e4789c651bfbe6a357adbfc681c49809f  xsa468/xencons-02.patch
0e65525d0a89d693b0b62074e593be332a431cbe245aa8f7d94db4f93a0e7c78  xsa468/xeniface-01.patch
d9193ea2f120281b3ff0886f65ab87723520577826a347db539ef8904eaffa02  xsa468/xeniface-02.patch
f5a6da368cd0114e8d462d7959590e2abff0523574091427896d7092face0e6a  xsa468/xeniface-03.patch
01fadfd4906db35a14cba6d17cc2d28020f554564741c764db876dca43205ad3  xsa468/xeniface-04.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of patches or mitigations 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 the fixes change in-guest behaviour.

Deployment is permitted only AFTER the embargo ends.


(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/4UyVfoK9kFAmg1o+EMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZB4IH+QGuIpu1qNVMNNL6rsWSHXJO764VIS8nn6sadMPI
heKoqWr9RMzPZsFDK5qWtckUR4Mfloj/3OD3VDb7a+qeeHFRHCvtpJ5L+q+JYAW6
5Fi5mGqNxTZWjCiwyKtKpJqRj7xSSb49TAi7BrshToV5jD66IyKUW44qFEeXPrs8
KTg2M3MhOO+OJrnHZHcKbhXd2IyhcYL96wg6KteVoQb35uyiDRpj1/mT4BQvp03n
3MJe3uQCavorEPiiWk+Zy/DXSBzFsGpsCSwGOYgjC7HZfWvtsmWeREQhai32LpBi
HW7yufiHwn/sC4hJT98CR1UvH/IJRbEG4kqVX4J6dxau9bw=
=QxLI
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa468/xenbus-01.patch"
Content-Disposition: attachment; filename="xsa468/xenbus-01.patch"
Content-Transfer-Encoding: base64

RnJvbSBmYmU2ODZjMDA4ZDVjMDM3MzE4OGIzNzM4ZGZlM2U3NTI1MGQzY2Q3
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBUdSBEaW5oIDxuZ29j
LXR1LmRpbmhAdmF0ZXMudGVjaD4KRGF0ZTogVHVlLCAxIEFwciAyMDI1IDEw
OjM2OjEyICswMDAwClN1YmplY3Q6IFByb3Blcmx5IGxpbWl0IHhlbnN0b3Jl
IHdyaXRlIGxlbmd0aHMKClhlbmJ1cydzIHdyaXRlIGludGVyZmFjZSBvbmx5
IGNoZWNrcyB3cml0ZSBkYXRhIHNpemVzIHVzaW5nIGFzc2VydHMuClRoZSBz
aXplIG9mIG92ZXJseS1sYXJnZSB3cml0ZXMgKGUuZy4gdGhyb3VnaCBYZW5p
ZmFjZSBJT0NUTHMpIGlzIG5vdApjaGVja2VkIGluIHJlbGVhc2UgYnVpbGRz
LgoKVmVyaWZ5IHdyaXRlIGxlbmd0aHMgdXNpbmcgZnVsbCBjaGVja3MgaW5z
dGVhZCBvZiBhc3NlcnRzIHRvIGZpeCB0aGlzCmlzc3VlLgoKVGhpcyBpcyBY
U0EtNDY4IC8gQ1ZFLTIwMjUtMjc0NjQuCgpTaWduZWQtb2ZmLWJ5OiBUdSBE
aW5oIDxuZ29jLXR1LmRpbmhAdmF0ZXMudGVjaD4KQWNrZWQtYnk6IFBhdWwg
RHVycmFudCA8cGF1bEB4ZW4ub3JnPgpSZXZpZXdlZC1ieTogT3dlbiBTbWl0
aCA8b3dlbi5zbWl0aEBjbG91ZC5jb20+Ci0tLQogc3JjL3hlbmJ1cy9zdG9y
ZS5jIHwgMjQgKysrKysrKysrKysrKysrKysrKy0tLS0tCiAxIGZpbGUgY2hh
bmdlZCwgMTkgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkKCmRpZmYg
LS1naXQgYS9zcmMveGVuYnVzL3N0b3JlLmMgYi9zcmMveGVuYnVzL3N0b3Jl
LmMKaW5kZXggMDJkM2NjMjdiNWNjLi4wMmNkZDE3OWVhZDEgMTAwNjQ0Ci0t
LSBhL3NyYy94ZW5idXMvc3RvcmUuYworKysgYi9zcmMveGVuYnVzL3N0b3Jl
LmMKQEAgLTMyLDYgKzMyLDcgQEAKIAogI2luY2x1ZGUgPG50ZGRrLmg+CiAj
aW5jbHVkZSA8bnRzdHJzYWZlLmg+CisjaW5jbHVkZSA8bnRpbnRzYWZlLmg+
CiAjaW5jbHVkZSA8c3RkYXJnLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAj
aW5jbHVkZSA8eGVuLmg+CkBAIC0yMTAsNiArMjExLDcgQEAgU3RvcmVQcmVw
YXJlUmVxdWVzdCgKICAgICBTZWdtZW50LT5MZW5ndGggPSBzaXplb2YgKHN0
cnVjdCB4c2Rfc29ja21zZyk7CiAKICAgICB2YV9zdGFydChBcmd1bWVudHMs
IFR5cGUpOworICAgIHN0YXR1cyA9IFNUQVRVU19VTlNVQ0NFU1NGVUw7CiAg
ICAgZm9yICg7OykgewogICAgICAgICBQQ0hBUiAgIERhdGE7CiAgICAgICAg
IFVMT05HICAgTGVuZ3RoOwpAQCAtMjIyLDE0ICsyMjQsMTkgQEAgU3RvcmVQ
cmVwYXJlUmVxdWVzdCgKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICB9
CiAKKyAgICAgICAgaWYgKFJlcXVlc3QtPkNvdW50ID49IFhFTkJVU19TVE9S
RV9SRVFVRVNUX1NFR01FTlRfQ09VTlQpCisgICAgICAgICAgICBnb3RvIGZh
aWwyOwogICAgICAgICBTZWdtZW50ID0gJlJlcXVlc3QtPlNlZ21lbnRbUmVx
dWVzdC0+Q291bnQrK107Ci0gICAgICAgIEFTU0VSVDNVKFJlcXVlc3QtPkNv
dW50LCA8LCBYRU5CVVNfU1RPUkVfUkVRVUVTVF9TRUdNRU5UX0NPVU5UKTsK
IAogICAgICAgICBTZWdtZW50LT5EYXRhID0gRGF0YTsKICAgICAgICAgU2Vn
bWVudC0+T2Zmc2V0ID0gMDsKICAgICAgICAgU2VnbWVudC0+TGVuZ3RoID0g
TGVuZ3RoOwogCi0gICAgICAgIFJlcXVlc3QtPkhlYWRlci5sZW4gKz0gU2Vn
bWVudC0+TGVuZ3RoOworICAgICAgICBpZiAoIU5UX1NVQ0NFU1MoUnRsVUxv
bmdBZGQoUmVxdWVzdC0+SGVhZGVyLmxlbiwKKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFNlZ21lbnQtPkxlbmd0aCwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZSZXF1ZXN0LT5IZWFkZXIu
bGVuKSkgfHwKKyAgICAgICAgICAgIFJlcXVlc3QtPkhlYWRlci5sZW4gPiBY
RU5TVE9SRV9QQVlMT0FEX01BWCkKKyAgICAgICAgICAgIGdvdG8gZmFpbDM7
CiAgICAgfQogICAgIHZhX2VuZChBcmd1bWVudHMpOwogCkBAIC0yMzcsNiAr
MjQ0LDEwIEBAIFN0b3JlUHJlcGFyZVJlcXVlc3QoCiAKICAgICByZXR1cm4g
U1RBVFVTX1NVQ0NFU1M7CiAKK2ZhaWwzOgorZmFpbDI6CisgICAgUnRsWmVy
b01lbW9yeShSZXF1ZXN0LCBzaXplb2YgKFhFTkJVU19TVE9SRV9SRVFVRVNU
KSk7CisKIGZhaWwxOgogICAgIHJldHVybiBzdGF0dXM7CiB9CkBAIC0xMjcy
LDEwICsxMjgzLDEyIEBAIFN0b3JlVlByaW50ZigKICAgICAgICAgaWYgKHN0
YXR1cyAhPSBTVEFUVVNfQlVGRkVSX09WRVJGTE9XKQogICAgICAgICAgICAg
Z290byBmYWlsMjsKIAotICAgICAgICBfX1N0b3JlRnJlZShCdWZmZXIpOwor
ICAgICAgICBzdGF0dXMgPSBTVEFUVVNfSU5WQUxJRF9CVUZGRVJfU0laRTsK
ICAgICAgICAgTGVuZ3RoIDw8PSAxOworICAgICAgICBpZiAoTGVuZ3RoID4g
MTAyNCkKKyAgICAgICAgICAgIGdvdG8gZmFpbDM7CiAKLSAgICAgICAgQVNT
RVJUM1UoTGVuZ3RoLCA8PSwgMTAyNCk7CisgICAgICAgIF9fU3RvcmVGcmVl
KEJ1ZmZlcik7CiAgICAgfQogCiAgICAgc3RhdHVzID0gU3RvcmVXcml0ZShD
b250ZXh0LApAQCAtMTI4NCwxMiArMTI5NywxMyBAQCBTdG9yZVZQcmludGYo
CiAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vZGUsCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIEJ1ZmZlcik7CiAgICAgaWYgKCFOVF9TVUNDRVNT
KHN0YXR1cykpCi0gICAgICAgIGdvdG8gZmFpbDM7CisgICAgICAgIGdvdG8g
ZmFpbDQ7CiAKICAgICBfX1N0b3JlRnJlZShCdWZmZXIpOwogCiAgICAgcmV0
dXJuIFNUQVRVU19TVUNDRVNTOwogCitmYWlsNDoKIGZhaWwzOgogZmFpbDI6
CiAgICAgX19TdG9yZUZyZWUoQnVmZmVyKTsKLS0gCjIuNDcuMQoK

--=separator
Content-Type: application/octet-stream; name="xsa468/xencons-01.patch"
Content-Disposition: attachment; filename="xsa468/xencons-01.patch"
Content-Transfer-Encoding: base64

RnJvbSA5ZjVmMDI5NTQ0ZWI5Mzg0YzEwNmE2Y2NjNmYyNTMxYzkwMjEyNWJi
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBUdSBEaW5oIDxuZ29j
LXR1LmRpbmhAdmF0ZXMudGVjaD4KRGF0ZTogV2VkLCA1IE1hciAyMDI1IDA5
OjQzOjM2ICswMDAwClN1YmplY3Q6IFJlc3RyaWN0IGRlZmF1bHQgYWNjZXNz
IHRvIFhlbmNvbnMgUERPCgpXaXRob3V0IGFzc2lnbmluZyBhbiBleHBsaWNp
dCBTRERMIHZpYSBJb0NyZWF0ZURldmljZVNlY3VyZSwgYW55IHVzZXIKY2Fu
IG9wZW4gdGhlIFhlbmNvbnMgUERPIHZpYSBpdHMgZGVmYXVsdCBzZWN1cml0
eSBkZXNjcmlwdG9yLgoKVGhpcyBpcyBwYXJ0IG9mIFhTQS00NjggLyBDVkUt
MjAyNS0yNzQ2Mi4KCkZpeGVzOiAyOGEwODE5MTE4OGYgKCJBZGQgYm9pbGVy
cGxhdGUgUGRvIikKU2lnbmVkLW9mZi1ieTogVHUgRGluaCA8bmdvYy10dS5k
aW5oQHZhdGVzLnRlY2g+ClJldmlld2VkLUJ5OiBPd2VuIFNtaXRoIDxvd2Vu
LnNtaXRoQGNsb3VkLmNvbT4KCmRpZmYgLS1naXQgYS9zcmMveGVuY29ucy9j
b25zb2xlLmMgYi9zcmMveGVuY29ucy9jb25zb2xlLmMKaW5kZXggOTM5ZDhj
ODUwZTgyLi43MjQyMWNlMmEzOGQgMTAwNjQ0Ci0tLSBhL3NyYy94ZW5jb25z
L2NvbnNvbGUuYworKysgYi9zcmMveGVuY29ucy9jb25zb2xlLmMKQEAgLTM2
LDYgKzM2LDcgQEAKICNpbmNsdWRlIDx3ZG1ndWlkLmg+CiAjaW5jbHVkZSA8
bnRzdHJzYWZlLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CisjaW5jbHVkZSA8
d2Rtc2VjLmg+CiAKICNpbmNsdWRlIDx4ZW5jb25zX2RldmljZS5oPgogCkBA
IC0yODcsNiArMjg4LDEwIEBAIF9fQ29uc29sZURldmljZUNvbnRyb2woCiAg
ICAgT3V0cHV0QnVmZmVyTGVuZ3RoID0gU3RhY2tMb2NhdGlvbi0+UGFyYW1l
dGVycy5EZXZpY2VJb0NvbnRyb2wuT3V0cHV0QnVmZmVyTGVuZ3RoOwogICAg
IEJ1ZmZlciA9IElycC0+QXNzb2NpYXRlZElycC5TeXN0ZW1CdWZmZXI7CiAK
KyAgICBzdGF0dXMgPSBXZG1saWJJb1ZhbGlkYXRlRGV2aWNlSW9Db250cm9s
QWNjZXNzKElycCwgRklMRV9SRUFEX0FDQ0VTUyk7CisgICAgaWYgKHN0YXR1
cyAhPSBTVEFUVVNfU1VDQ0VTUykKKyAgICAgICAgcmV0dXJuIHN0YXR1czsK
KwogICAgIHN3aXRjaCAoSW9Db250cm9sQ29kZSkgewogICAgIGNhc2UgSU9D
VExfWEVOQ09OU19HRVRfSU5TVEFOQ0U6CiAgICAgICAgIFZhbHVlID0gIjAi
OwpkaWZmIC0tZ2l0IGEvc3JjL3hlbmNvbnMvcGRvLmMgYi9zcmMveGVuY29u
cy9wZG8uYwppbmRleCA2OGNjY2RlZmUzZjcuLjg3MjZmN2RhMmU4OCAxMDA2
NDQKLS0tIGEvc3JjL3hlbmNvbnMvcGRvLmMKKysrIGIvc3JjL3hlbmNvbnMv
cGRvLmMKQEAgLTM2LDYgKzM2LDcgQEAKICNpbmNsdWRlIDx3ZG1ndWlkLmg+
CiAjaW5jbHVkZSA8bnRzdHJzYWZlLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+
CisjaW5jbHVkZSA8d2Rtc2VjLmg+CiAKICNpbmNsdWRlIDxzdXNwZW5kX2lu
dGVyZmFjZS5oPgogI2luY2x1ZGUgPHhlbmNvbnNfZGV2aWNlLmg+CkBAIC0x
OTE1LDEzICsxOTE2LDE1IEBAIFBkb0NyZWF0ZSgKICAgICBOVFNUQVRVUyAg
ICAgICAgICAgIHN0YXR1czsKIAogI3ByYWdtYSBwcmVmYXN0KHN1cHByZXNz
OjI4MTk3KSAvLyBQb3NzaWJseSBsZWFraW5nIG1lbW9yeSAnUGh5c2ljYWxE
ZXZpY2VPYmplY3QnCi0gICAgc3RhdHVzID0gSW9DcmVhdGVEZXZpY2UoRHJp
dmVyR2V0RHJpdmVyT2JqZWN0KCksCi0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgc2l6ZW9mKFhFTkNPTlNfRFgpLAotICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIE5VTEwsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
RklMRV9ERVZJQ0VfVU5LTk9XTiwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBGSUxFX0RFVklDRV9TRUNVUkVfT1BFTiB8IEZJTEVfQVVUT0dFTkVS
QVRFRF9ERVZJQ0VfTkFNRSwKLSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBGQUxTRSwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAmUGh5c2lj
YWxEZXZpY2VPYmplY3QpOworICAgIHN0YXR1cyA9IElvQ3JlYXRlRGV2aWNl
U2VjdXJlKERyaXZlckdldERyaXZlck9iamVjdCgpLAorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHNpemVvZihYRU5DT05TX0RYKSwKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOVUxMLAorICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZJTEVfREVWSUNFX1VOS05P
V04sCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRklMRV9E
RVZJQ0VfU0VDVVJFX09QRU4gfCBGSUxFX0FVVE9HRU5FUkFURURfREVWSUNF
X05BTUUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRkFM
U0UsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJlNERExf
REVWT0JKX1NZU19BTExfQURNX0FMTCwKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmR1VJRF9YRU5DT05TX0RFVklDRV9DTEFTUywKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmUGh5c2ljYWxEZXZp
Y2VPYmplY3QpOwogICAgIGlmICghTlRfU1VDQ0VTUyhzdGF0dXMpKQogICAg
ICAgICBnb3RvIGZhaWwxOwogCmRpZmYgLS1naXQgYS9zcmMveGVuY29ucy9w
ZG8uaCBiL3NyYy94ZW5jb25zL3Bkby5oCmluZGV4IGM1M2YzNjFmMmRiNi4u
NTJkNzhhNTdjMWQxIDEwMDY0NAotLS0gYS9zcmMveGVuY29ucy9wZG8uaAor
KysgYi9zcmMveGVuY29ucy9wZG8uaApAQCAtMzcsNiArMzcsMTAgQEAKIAog
I2luY2x1ZGUgImRyaXZlci5oIgogCisvLyB7NTAwMDYxMjMtMDk0MC00Qzc4
LUE1NEItQTQzREM4MzE2NEVGfQorREVGSU5FX0dVSUQoR1VJRF9YRU5DT05T
X0RFVklDRV9DTEFTUywKKyAgICAweDUwMDA2MTIzLCAweDk0MCwgMHg0Yzc4
LCAweGE1LCAweDRiLCAweGE0LCAweDNkLCAweGM4LCAweDMxLCAweDY0LCAw
eGVmKTsKKwogZXh0ZXJuIFZPSUQKIFBkb1NldERldmljZVBucFN0YXRlKAog
ICAgIElOICBQWEVOQ09OU19QRE8gICAgICAgIFBkbywK

--=separator
Content-Type: application/octet-stream; name="xsa468/xencons-02.patch"
Content-Disposition: attachment; filename="xsa468/xencons-02.patch"
Content-Transfer-Encoding: base64

RnJvbSAwYWQwNTg2NDVhZmM2MGFhMmU3NmUzOWJmY2MwY2MyMjNiOTNhMDE5
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBUdSBEaW5oIDxuZ29j
LXR1LmRpbmhAdmF0ZXMudGVjaD4KRGF0ZTogRnJpLCAyOCBNYXIgMjAyNSAy
Mjo1ODo1MCArMDAwMApTdWJqZWN0OiBTZWN1cmUgWGVuY29ucyBtb25pdG9y
IG5hbWVkIHBpcGVzCgoqIENyZWF0ZSBtb25pdG9yIG5hbWVkIHBpcGVzIHVu
ZGVyIHRoZQogIFxcLlxwaXBlXFByb3RlY3RlZFByZWZpeFxBZG1pbmlzdHJh
dG9ycyBwcmVmaXggdG8gcHJldmVudCB1bnByaXZpbGVnZWQKICB1c2VycyBm
cm9tIGNyZWF0aW5nIG5hbWVkIHBpcGUgaW5zdGFuY2VzIHVuZGVyIHRoZSBz
YW1lIHBhdGg7CiogQXNzaWduIGEgcmVzdHJpY3RpdmUgc2VjdXJpdHkgZGVz
Y3JpcHRvciB0byBtb25pdG9yIG5hbWVkIHBpcGVzIHRvCiAgcHJldmVudCB1
bnByaXZpbGVnZWQgdXNlcnMgZnJvbSByZWFkaW5nIGNvbnNvbGUgaW5wdXRz
OwoqIFNldCBQSVBFX1JFSkVDVF9SRU1PVEVfQ0xJRU5UUyB0byBwcmV2ZW50
IG1vbml0b3IgbmFtZWQgcGlwZXMgZnJvbQogIGJlaW5nIGV4cG9zZWQgdG8g
dGhlIG5ldHdvcmsuCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2OCAvIENWRS0y
MDI1LTI3NDYyLgoKU2lnbmVkLW9mZi1ieTogVHUgRGluaCA8bmdvYy10dS5k
aW5oQHZhdGVzLnRlY2g+ClJldmlld2VkLWJ5OiBPd2VuIFNtaXRoIDxvd2Vu
LnNtaXRoQGNsb3VkLmNvbT4KLS0tCiBzcmMvbW9uaXRvci9tb25pdG9yLmMg
fCAzNiArKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0KIHNy
Yy90dHkvdHR5LmMgICAgICAgICB8ICAyICstCiAyIGZpbGVzIGNoYW5nZWQs
IDI5IGluc2VydGlvbnMoKyksIDkgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0
IGEvc3JjL21vbml0b3IvbW9uaXRvci5jIGIvc3JjL21vbml0b3IvbW9uaXRv
ci5jCmluZGV4IDU5ZTZhYjZhZWU3OC4uZWM4YTYzODYzOGY4IDEwMDY0NAot
LS0gYS9zcmMvbW9uaXRvci9tb25pdG9yLmMKKysrIGIvc3JjL21vbml0b3Iv
bW9uaXRvci5jCkBAIC00MCw2ICs0MCw3IEBACiAjaW5jbHVkZSA8Y2ZnbWdy
MzIuaD4KICNpbmNsdWRlIDxkYnQuaD4KICNpbmNsdWRlIDxzZXR1cGFwaS5o
PgorI2luY2x1ZGUgPHNkZGwuaD4KICNpbmNsdWRlIDxtYWxsb2MuaD4KICNp
bmNsdWRlIDxhc3NlcnQuaD4KIApAQCAtOTMsNyArOTQsOSBAQCB0eXBlZGVm
IHN0cnVjdCBfTU9OSVRPUl9DT05ORUNUSU9OIHsKIAogc3RhdGljIE1PTklU
T1JfQ09OVEVYVCBNb25pdG9yQ29udGV4dDsKIAotI2RlZmluZSBQSVBFX0JB
U0VfTkFNRSAiXFxcXC5cXHBpcGVcXHhlbmNvbnNcXCIKKyNkZWZpbmUgUElQ
RV9CQVNFX05BTUUgIlxcXFwuXFxwaXBlXFxQcm90ZWN0ZWRQcmVmaXhcXEFk
bWluaXN0cmF0b3JzXFx4ZW5jb25zXFwiCisvLyBGSUxFX0dFTkVSSUNfQUxM
IGZvciBTWVNURU0gYW5kIEJ1aWx0aW5cQWRtaW5pc3RyYXRvcnMsIG5vdGhp
bmcgZm9yIHRoZSByZXN0CisjZGVmaW5lIFBJUEVfU0RETCAiRDooQTs7RkE7
OztTWSkoQTs7RkE7OztCQSkiCiAKICNkZWZpbmUgTUFYSU1VTV9CVUZGRVJf
U0laRSAxMDI0CiAKQEAgLTQzNiw2ICs0MzksNyBAQCBTZXJ2ZXJUaHJlYWQo
CiAgICAgRFdPUkQgICAgICAgICAgICAgICBPYmplY3Q7CiAgICAgUE1PTklU
T1JfQ09OTkVDVElPTiBDb25uZWN0aW9uOwogICAgIEhSRVNVTFQgICAgICAg
ICAgICAgRXJyb3I7CisgICAgU0VDVVJJVFlfQVRUUklCVVRFUyBTZWN1cml0
eUF0dHJpYnV0ZXM7CiAKICAgICBMb2coIj09PT0+ICVzIiwgQ29uc29sZS0+
RGV2aWNlTmFtZSk7CiAKQEAgLTQ2MCwxNyArNDY0LDI2IEBAIFNlcnZlclRo
cmVhZCgKIAogICAgIExvZygiJXMiLCBQaXBlTmFtZSk7CiAKKyAgICBaZXJv
TWVtb3J5KCZTZWN1cml0eUF0dHJpYnV0ZXMsIHNpemVvZihTRUNVUklUWV9B
VFRSSUJVVEVTKSk7CisgICAgU2VjdXJpdHlBdHRyaWJ1dGVzLm5MZW5ndGgg
PSBzaXplb2YoU0VDVVJJVFlfQVRUUklCVVRFUyk7CisgICAgU2VjdXJpdHlB
dHRyaWJ1dGVzLmJJbmhlcml0SGFuZGxlID0gRkFMU0U7CisgICAgaWYgKCFD
b252ZXJ0U3RyaW5nU2VjdXJpdHlEZXNjcmlwdG9yVG9TZWN1cml0eURlc2Ny
aXB0b3JBKFBJUEVfU0RETCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0RETF9SRVZJ
U0lPTl8xLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmU2VjdXJpdHlBdHRyaWJ1dGVz
LmxwU2VjdXJpdHlEZXNjcmlwdG9yLAorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOVUxM
KSkKKyAgICAgICAgZ290byBmYWlsMzsKKwogICAgIGZvciAoOzspIHsKICAg
ICAgICAgUGlwZSA9IENyZWF0ZU5hbWVkUGlwZShQaXBlTmFtZSwKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBQSVBFX0FDQ0VTU19EVVBMRVgg
fCBGSUxFX0ZMQUdfT1ZFUkxBUFBFRCwKLSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBQSVBFX1RZUEVfTUVTU0FHRSB8IFBJUEVfUkVBRE1PREVf
TUVTU0FHRSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQSVBF
X1RZUEVfTUVTU0FHRSB8IFBJUEVfUkVBRE1PREVfTUVTU0FHRSB8IFBJUEVf
UkVKRUNUX1JFTU9URV9DTElFTlRTLAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFBJUEVfVU5MSU1JVEVEX0lOU1RBTkNFUywKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBNQVhJTVVNX0JVRkZFUl9TSVpFLAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1BWElNVU1fQlVGRkVS
X1NJWkUsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCwKLSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOVUxMKTsKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmU2VjdXJpdHlBdHRyaWJ1dGVzKTsK
ICAgICAgICAgaWYgKFBpcGUgPT0gSU5WQUxJRF9IQU5ETEVfVkFMVUUpCi0g
ICAgICAgICAgICBnb3RvIGZhaWwzOworICAgICAgICAgICAgZ290byBmYWls
NDsKIAogICAgICAgICAoVk9JRCkgQ29ubmVjdE5hbWVkUGlwZShQaXBlLAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmT3ZlcmxhcHBlZCk7
CkBAIC00ODgsNyArNTAxLDcgQEAgU2VydmVyVGhyZWFkKAogCiAgICAgICAg
IENvbm5lY3Rpb24gPSAoUE1PTklUT1JfQ09OTkVDVElPTiltYWxsb2Moc2l6
ZW9mKE1PTklUT1JfQ09OTkVDVElPTikpOwogICAgICAgICBpZiAoQ29ubmVj
dGlvbiA9PSBOVUxMKQotICAgICAgICAgICAgZ290byBmYWlsNDsKKyAgICAg
ICAgICAgIGdvdG8gZmFpbDU7CiAKICAgICAgICAgX19Jbml0aWFsaXplTGlz
dEhlYWQoJkNvbm5lY3Rpb24tPkxpc3RFbnRyeSk7CiAgICAgICAgIENvbm5l
Y3Rpb24tPkNvbnNvbGUgPSBDb25zb2xlOwpAQCAtNTAwLDI0ICs1MTMsMzEg
QEAgU2VydmVyVGhyZWFkKAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgMCwKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIE5VTEwpOwogICAgICAgICBpZiAoQ29ubmVjdGlv
bi0+VGhyZWFkID09IE5VTEwpCi0gICAgICAgICAgICBnb3RvIGZhaWw1Owor
ICAgICAgICAgICAgZ290byBmYWlsNjsKICAgICB9CiAKKyAgICBMb2NhbEZy
ZWUoJlNlY3VyaXR5QXR0cmlidXRlcy5scFNlY3VyaXR5RGVzY3JpcHRvcik7
CisKICAgICBDbG9zZUhhbmRsZShPdmVybGFwcGVkLmhFdmVudCk7CiAKICAg
ICBMb2coIjw9PT09ICVzIiwgQ29uc29sZS0+RGV2aWNlTmFtZSk7CiAKICAg
ICByZXR1cm4gMDsKIAorZmFpbDY6CisgICAgTG9nKCJmYWlsNiIpOworCisg
ICAgZnJlZShDb25uZWN0aW9uKTsKKwogZmFpbDU6CiAgICAgTG9nKCJmYWls
NSIpOwogCi0gICAgZnJlZShDb25uZWN0aW9uKTsKKyAgICBDbG9zZUhhbmRs
ZShQaXBlKTsKIAogZmFpbDQ6CiAgICAgTG9nKCJmYWlsNCIpOwogCi0gICAg
Q2xvc2VIYW5kbGUoUGlwZSk7CisgICAgTG9jYWxGcmVlKCZTZWN1cml0eUF0
dHJpYnV0ZXMubHBTZWN1cml0eURlc2NyaXB0b3IpOwogCiBmYWlsMzoKICAg
ICBMb2coImZhaWwzIik7CmRpZmYgLS1naXQgYS9zcmMvdHR5L3R0eS5jIGIv
c3JjL3R0eS90dHkuYwppbmRleCBjM2I2ZjhlMTgzNDUuLjA4ZDM3MjQzNTc3
MiAxMDA2NDQKLS0tIGEvc3JjL3R0eS90dHkuYworKysgYi9zcmMvdHR5L3R0
eS5jCkBAIC00NCw3ICs0NCw3IEBAIHR5cGVkZWYgc3RydWN0IF9UVFlfU1RS
RUFNIHsKICAgICBIQU5ETEUgIFdyaXRlOwogfSBUVFlfU1RSRUFNLCAqUFRU
WV9TVFJFQU07CiAKLSNkZWZpbmUgUElQRV9OQU1FIFRFWFQoIlxcXFwuXFxw
aXBlXFx4ZW5jb25zXFxkZWZhdWx0IikKKyNkZWZpbmUgUElQRV9OQU1FIFRF
WFQoIlxcXFwuXFxwaXBlXFxQcm90ZWN0ZWRQcmVmaXhcXEFkbWluaXN0cmF0
b3JzXFx4ZW5jb25zXFxkZWZhdWx0IikKICNkZWZpbmUgTUFYSU1VTV9CVUZG
RVJfU0laRSAxMDI0CiAKIHR5cGVkZWYgc3RydWN0IF9UVFlfQ09OVEVYVCB7
Ci0tIAoyLjQ3LjEKCg==

--=separator
Content-Type: application/octet-stream; name="xsa468/xeniface-01.patch"
Content-Disposition: attachment; filename="xsa468/xeniface-01.patch"
Content-Transfer-Encoding: base64

RnJvbSA2MmU0ZGM0MDM5NDk2NDkyNmY5MTMzYWU2NzVlZmEwMzUwYWYxZTY2
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBUdSBEaW5oIDxuZ29j
LXR1LmRpbmhAdmF0ZXMudGVjaD4KRGF0ZTogV2VkLCA1IE1hciAyMDI1IDA5
OjQzOjU0ICswMDAwClN1YmplY3Q6IFJlc3RyaWN0IGRlZmF1bHQgYWNjZXNz
IHRvIFhlbmlmYWNlIGRldmljZQoKV2l0aG91dCBhc3NpZ25pbmcgYW4gZXhw
bGljaXQgU0RETCB2aWEgeGVuaWZhY2UuaW5mLCBhbnkgdXNlciBjYW4gb3Bl
bgp0aGUgWGVuaWZhY2UgRkRPIHZpYSBpdHMgZGVmYXVsdCBzZWN1cml0eSBk
ZXNjcmlwdG9yLgoKQWRkaXRpb25hbGx5LCB2YWxpZGF0ZSB1c2VyIHJlYWQr
d3JpdGUgYWNjZXNzIHRvIHRoZSBYZW5pZmFjZSBGRE8gYmVmb3JlCmFsbG93
aW5nIElPQ1RMcyB0byB0aGlzIGludGVyZmFjZS4KClRoaXMgaXMgcGFydCBv
ZiBYU0EtNDY4IC8gQ1ZFLTIwMjUtMjc0NjMuCgpGaXhlczogYzY0OWVkYzg0
Zjg1ICgiSW5pdGlhbCBjb21taXQgb2YgZnVsbHkgb3BlbiB4ZW5pZmFjZSBj
b2RlIikKU2lnbmVkLW9mZi1ieTogVHUgRGluaCA8bmdvYy10dS5kaW5oQHZh
dGVzLnRlY2g+ClJldmlld2VkLUJ5OiBPd2VuIFNtaXRoIDxvd2VuLnNtaXRo
QGNsb3VkLmNvbT4KCmRpZmYgLS1naXQgYS9zcmMveGVuaWZhY2UuaW5mIGIv
c3JjL3hlbmlmYWNlLmluZgppbmRleCBmZTVlYTc1NWU4ZjcuLmI1NDMzOTIw
ZTk4NyAxMDA2NDQKLS0tIGEvc3JjL3hlbmlmYWNlLmluZgorKysgYi9zcmMv
eGVuaWZhY2UuaW5mCkBAIC03Miw2ICs3MiwxMiBAQCB4ZW5hZ2VudF9ATUFK
T1JfVkVSU0lPTkBfQE1JTk9SX1ZFUlNJT05AX0BNSUNST19WRVJTSU9OQF9A
QlVJTERfTlVNQkVSQC5kbGwseGVuYQogQ29weUZpbGVzPVhlbklmYWNlX0Nv
cHlGaWxlcwogQ29weUZpbGVzPVhlbkFnZW50X0NvcHlGaWxlcwogCitbWGVu
SWZhY2VfSW5zdC5IV10KK0FkZFJlZz1YZW5JZmFjZV9JbnN0LkhXLkFkZFJl
ZworCitbWGVuSWZhY2VfSW5zdC5IVy5BZGRSZWddCitIS1IsLFNlY3VyaXR5
LCwiRDpQKEE7O0dBOzs7U1kpKEE7O0dBOzs7QkEpIiAgOyBTRERMX0RFVk9C
Sl9TWVNfQUxMX0FETV9BTEwKKwogW1hlbmlmYWNlX0luc3QuU2VydmljZXNd
CiBBZGRTZXJ2aWNlID0geGVuaWZhY2UsIDB4MDAwMiwgWGVuSWZhY2VfU2Vy
dmljZQogQWRkU2VydmljZSA9IHhlbmFnZW50LCAweDA4MDAsIFhlbkFnZW50
X1NlcnZpY2UsWGVuQWdlbnRfRXZlbnRMb2cKZGlmZiAtLWdpdCBhL3NyYy94
ZW5pZmFjZS9pb2N0bHMuYyBiL3NyYy94ZW5pZmFjZS9pb2N0bHMuYwppbmRl
eCA2MjgyZTc3YWJhNDQuLjA3Njc1MGE2NTM2OSAxMDA2NDQKLS0tIGEvc3Jj
L3hlbmlmYWNlL2lvY3Rscy5jCisrKyBiL3NyYy94ZW5pZmFjZS9pb2N0bHMu
YwpAQCAtMzMsNiArMzMsNyBAQAogCiAjaW5jbHVkZSA8bnRpZnMuaD4KICNp
bmNsdWRlIDxwcm9jZ3JwLmg+CisjaW5jbHVkZSA8d2Rtc2VjLmg+CiAjaW5j
bHVkZSAiZHJpdmVyLmgiCiAjaW5jbHVkZSAiaW9jdGxzLmgiCiAjaW5jbHVk
ZSAieGVuaWZhY2VfaW9jdGxzLmgiCkBAIC0yNTMsNiArMjU0LDEwIEBAIFhl
bklmYWNlSW9jdGwoCiAgICAgaWYgKEZkby0+SW50ZXJmYWNlc0FjcXVpcmVk
ID09IEZBTFNFKQogICAgICAgICBnb3RvIGRvbmU7CiAKKyAgICBzdGF0dXMg
PSBXZG1saWJJb1ZhbGlkYXRlRGV2aWNlSW9Db250cm9sQWNjZXNzKElycCwg
RklMRV9SRUFEX0FDQ0VTUyB8IEZJTEVfV1JJVEVfQUNDRVNTKTsKKyAgICBp
ZiAoc3RhdHVzICE9IFNUQVRVU19TVUNDRVNTKQorICAgICAgICBnb3RvIGRv
bmU7CisKICAgICBzd2l0Y2ggKENvbnRyb2xDb2RlKSB7CiAgICAgICAgIC8v
IHN0b3JlCiAgICAgY2FzZSBJT0NUTF9YRU5JRkFDRV9TVE9SRV9SRUFEOgpk
aWZmIC0tZ2l0IGEvdnMyMDE5L3hlbmlmYWNlL3hlbmlmYWNlLnZjeHByb2og
Yi92czIwMTkveGVuaWZhY2UveGVuaWZhY2UudmN4cHJvagppbmRleCAxYzVj
MTViNGY5ZmUuLjlmOGY3NjYxOTdlMSAxMDA2NDQKLS0tIGEvdnMyMDE5L3hl
bmlmYWNlL3hlbmlmYWNlLnZjeHByb2oKKysrIGIvdnMyMDE5L3hlbmlmYWNl
L3hlbmlmYWNlLnZjeHByb2oKQEAgLTMxLDcgKzMxLDcgQEAKICAgICAgIDxB
ZGRpdGlvbmFsSW5jbHVkZURpcmVjdG9yaWVzPi4uXC4uXGluY2x1ZGU7JShB
ZGRpdGlvbmFsSW5jbHVkZURpcmVjdG9yaWVzKTwvQWRkaXRpb25hbEluY2x1
ZGVEaXJlY3Rvcmllcz4KICAgICA8L1Jlc291cmNlQ29tcGlsZT4KICAgICA8
TGluaz4KLSAgICAgIDxBZGRpdGlvbmFsRGVwZW5kZW5jaWVzPiQoRERLX0xJ
Ql9QQVRIKVxudHN0cnNhZmUubGliOyQoRERLX0xJQl9QQVRIKVxwcm9jZ3Jw
LmxpYjslKEFkZGl0aW9uYWxEZXBlbmRlbmNpZXMpPC9BZGRpdGlvbmFsRGVw
ZW5kZW5jaWVzPgorICAgICAgPEFkZGl0aW9uYWxEZXBlbmRlbmNpZXM+JChE
REtfTElCX1BBVEgpXG50c3Ryc2FmZS5saWI7JChEREtfTElCX1BBVEgpXHBy
b2NncnAubGliOyQoRERLX0xJQl9QQVRIKVx3ZG1zZWMubGliOyUoQWRkaXRp
b25hbERlcGVuZGVuY2llcyk8L0FkZGl0aW9uYWxEZXBlbmRlbmNpZXM+CiAg
ICAgICA8QWRkaXRpb25hbE9wdGlvbnM+L0lOVEVHUklUWUNIRUNLICUoQWRk
aXRpb25hbE9wdGlvbnMpPC9BZGRpdGlvbmFsT3B0aW9ucz4KICAgICAgIDxM
aW5rVGltZUNvZGVHZW5lcmF0aW9uPlVzZUxpbmtUaW1lQ29kZUdlbmVyYXRp
b248L0xpbmtUaW1lQ29kZUdlbmVyYXRpb24+CiAgICAgICA8Q0VUQ29tcGF0
PnRydWU8L0NFVENvbXBhdD4KZGlmZiAtLWdpdCBhL3ZzMjAyMi94ZW5pZmFj
ZS94ZW5pZmFjZS52Y3hwcm9qIGIvdnMyMDIyL3hlbmlmYWNlL3hlbmlmYWNl
LnZjeHByb2oKaW5kZXggNzc2ZTY4ZTgyNmE4Li4yNjlhZTNmZDVmNGEgMTAw
NjQ0Ci0tLSBhL3ZzMjAyMi94ZW5pZmFjZS94ZW5pZmFjZS52Y3hwcm9qCisr
KyBiL3ZzMjAyMi94ZW5pZmFjZS94ZW5pZmFjZS52Y3hwcm9qCkBAIC0zMSw3
ICszMSw3IEBACiAgICAgICA8QWRkaXRpb25hbEluY2x1ZGVEaXJlY3Rvcmll
cz4uLlwuLlxpbmNsdWRlOyUoQWRkaXRpb25hbEluY2x1ZGVEaXJlY3Rvcmll
cyk8L0FkZGl0aW9uYWxJbmNsdWRlRGlyZWN0b3JpZXM+CiAgICAgPC9SZXNv
dXJjZUNvbXBpbGU+CiAgICAgPExpbms+Ci0gICAgICA8QWRkaXRpb25hbERl
cGVuZGVuY2llcz4kKERES19MSUJfUEFUSClcbnRzdHJzYWZlLmxpYjskKERE
S19MSUJfUEFUSClccHJvY2dycC5saWI7JShBZGRpdGlvbmFsRGVwZW5kZW5j
aWVzKTwvQWRkaXRpb25hbERlcGVuZGVuY2llcz4KKyAgICAgIDxBZGRpdGlv
bmFsRGVwZW5kZW5jaWVzPiQoRERLX0xJQl9QQVRIKVxudHN0cnNhZmUubGli
OyQoRERLX0xJQl9QQVRIKVxwcm9jZ3JwLmxpYjskKERES19MSUJfUEFUSClc
d2Rtc2VjLmxpYjslKEFkZGl0aW9uYWxEZXBlbmRlbmNpZXMpPC9BZGRpdGlv
bmFsRGVwZW5kZW5jaWVzPgogICAgICAgPEFkZGl0aW9uYWxPcHRpb25zPi9J
TlRFR1JJVFlDSEVDSyAlKEFkZGl0aW9uYWxPcHRpb25zKTwvQWRkaXRpb25h
bE9wdGlvbnM+CiAgICAgICA8TGlua1RpbWVDb2RlR2VuZXJhdGlvbj5Vc2VM
aW5rVGltZUNvZGVHZW5lcmF0aW9uPC9MaW5rVGltZUNvZGVHZW5lcmF0aW9u
PgogICAgICAgPENFVENvbXBhdD50cnVlPC9DRVRDb21wYXQ+Cg==

--=separator
Content-Type: application/octet-stream; name="xsa468/xeniface-02.patch"
Content-Disposition: attachment; filename="xsa468/xeniface-02.patch"
Content-Transfer-Encoding: base64

RnJvbSBhNmRmMjFjNDY1MDEyZTZlMWE3ZGE0YWMyYmU2NjhhNjNmZDUwYTA3
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBUdSBEaW5oIDxuZ29j
LXR1LmRpbmhAdmF0ZXMudGVjaD4KRGF0ZTogTW9uLCA3IEFwciAyMDI1IDA5
OjM0OjQ2ICswMDAwClN1YmplY3Q6IFJlc3RyaWN0IGFjY2VzcyB0byBYZW5p
ZmFjZSBXTUkgY2xhc3NlcwoKVGhlIGRlZmF1bHQgc2VjdXJpdHkgZGVzY3Jp
cHRvciBwcm92aWRlZCB0byBXTUkgR1VJRHMgYWxsb3dzIHhlbnN0b3JlCmFj
Y2VzcyB0byBMb2NhbFNlcnZpY2UgYW5kIE5ldHdvcmtTZXJ2aWNlIGFjY291
bnRzLCB3aGljaCBhcmUgc3VwcG9zZWQKdG8gaGF2ZSBtaW5pbXVtIHByaXZp
bGVnZXMgb24gdGhlIGxvY2FsIHN5c3RlbS4KCkFzc2lnbiBhIHNlY3VyaXR5
IGRlc2NyaXB0b3IgaW4geGVuaWZhY2UuaW5mIHRvIHJlc3RyaWN0IGFsbCBX
TUkgR1VJRHMuCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2OCAvIENWRS0yMDI1
LTI3NDYzLgoKU2lnbmVkLW9mZi1ieTogVHUgRGluaCA8bmdvYy10dS5kaW5o
QHZhdGVzLnRlY2g+ClJldmlld2VkLWJ5OiBPd2VuIFNtaXRoIDxvd2VuLnNt
aXRoQGNsb3VkLmNvbT4KLS0tCiBzcmMveGVuaWZhY2UuaW5mIHwgMTAgKysr
KysrKysrKwogMSBmaWxlIGNoYW5nZWQsIDEwIGluc2VydGlvbnMoKykKCmRp
ZmYgLS1naXQgYS9zcmMveGVuaWZhY2UuaW5mIGIvc3JjL3hlbmlmYWNlLmlu
ZgppbmRleCBiNTQzMzkyMGU5ODcuLjA3ZTJhOTFlZmEzOCAxMDA2NDQKLS0t
IGEvc3JjL3hlbmlmYWNlLmluZgorKysgYi9zcmMveGVuaWZhY2UuaW5mCkBA
IC03Miw2ICs3MiwxNiBAQCB4ZW5hZ2VudF9ATUFKT1JfVkVSU0lPTkBfQE1J
Tk9SX1ZFUlNJT05AX0BNSUNST19WRVJTSU9OQF9AQlVJTERfTlVNQkVSQC5k
bGwseGVuYQogQ29weUZpbGVzPVhlbklmYWNlX0NvcHlGaWxlcwogQ29weUZp
bGVzPVhlbkFnZW50X0NvcHlGaWxlcwogCitbWGVuSWZhY2VfSW5zdC5XTUld
CitXTUlJbnRlcmZhY2U9ezFEODBFQjk5LUExRDYtNDQ5Mi1CNjJGLThCNDU0
OUZGMEI1RX0sLFhlbklmYWNlX0luc3QuV01JLlNlY3VyaXR5CitXTUlJbnRl
cmZhY2U9ezEyMTM4QTY5LTk3QjItNDlERC1COURFLTU0NzQ5QUFCQzc4OX0s
LFhlbklmYWNlX0luc3QuV01JLlNlY3VyaXR5CitXTUlJbnRlcmZhY2U9e0FC
ODEzNkJGLThFQTctNDIwRC1BREFELTg5QzgzRTU4NzkyNX0sLFhlbklmYWNl
X0luc3QuV01JLlNlY3VyaXR5CisKK1tYZW5JZmFjZV9JbnN0LldNSS5TZWN1
cml0eV0KKzsgb3duZWQgYnkgQlVJTFRJTlxBZG1pbmlzdHJhdG9ycworOyBn
cmFudCBHRU5FUklDX0FMTCBhY2Nlc3MgdG8gQlVJTFRJTlxBZG1pbmlzdHJh
dG9ycyBhbmQgTlQgQVVUSE9SSVRZXFNZU1RFTQorU2VjdXJpdHk9Ik86QkFH
OkJBRDooQTs7R0E7OztCQSkoQTs7R0E7OztTWSkiCisKIFtYZW5JZmFjZV9J
bnN0LkhXXQogQWRkUmVnPVhlbklmYWNlX0luc3QuSFcuQWRkUmVnCiAKLS0g
CjIuNDcuMQoK

--=separator
Content-Type: application/octet-stream; name="xsa468/xeniface-03.patch"
Content-Disposition: attachment; filename="xsa468/xeniface-03.patch"
Content-Transfer-Encoding: base64

RnJvbSAxM2JkNzUzMzE4NjFlNTJkOTk3YWFhOWYyZWE0NTRlMGVmNDE0MWI1
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBPd2VuIFNtaXRoIDxv
d2VuLnNtaXRoQGNsb3VkLmNvbT4KRGF0ZTogVGh1LCAzIEFwciAyMDI1IDEz
OjUzOjMzICswMTAwClN1YmplY3Q6IERvbnQgcmVmZXJlbmNlIEluIGJ1ZmZl
ciBhZnRlciB3cml0aW5nIHRvIE91dCBidWZmZXIKCkluIGFuZCBPdXQgYm90
aCByZWZlciB0byB0aGUgc2FtZSBJL08gYnVmZmVyLCBzbyByZWZlcmVuY2lu
ZyB0aGUgSW4gc3RydWN0dXJlCmFmdGVyIHVwZGF0aW5nIHRoZSB2YWx1ZSBp
biB0aGUgT3V0IHN0cnVjdHVyZSBjYWwgbGVhZCB0byB0aGUgd3JvbmcgcmVz
dWx0cywKaWYgdGhlIGZpZWxkcyBvdmVybGFwLgoKQWxzbyByZWZvcm1hdHMg
dGhlIGZ1bmN0aW9uIGFyZ3VtZW50cyBhbmQgdmFyaWFibGUgZGVmaW5pdGlv
bnMuCgpTaWduZWQtb2ZmLWJ5OiBPd2VuIFNtaXRoIDxvd2VuLnNtaXRoQGNs
b3VkLmNvbT4KUmV2aWV3ZWQtYnk6IFR1IERpbmggPG5nb2MtdHUuZGluaEB2
YXRlcy50ZWNoPgpSZXZpZXdlZC1ieTogUGF1bCBEdXJyYW50IDxwYXVsQHhl
bi5vcmc+Ci0tLQogc3JjL3hlbmlmYWNlL2lvY3RsX2V2dGNobi5jIHwgMTIg
KysrKysrLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgNiBpbnNlcnRpb25zKCsp
LCA2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy94ZW5pZmFjZS9p
b2N0bF9ldnRjaG4uYyBiL3NyYy94ZW5pZmFjZS9pb2N0bF9ldnRjaG4uYwpp
bmRleCBmNTI4NDg1ODA3NmUuLjZkNjM5OTY1MGU1NCAxMDA2NDQKLS0tIGEv
c3JjL3hlbmlmYWNlL2lvY3RsX2V2dGNobi5jCisrKyBiL3NyYy94ZW5pZmFj
ZS9pb2N0bF9ldnRjaG4uYwpAQCAtMjEwLDkgKzIxMCw2IEBAIElvY3RsRXZ0
Y2huQmluZFVuYm91bmQoCiAKICAgICBFeEludGVybG9ja2VkSW5zZXJ0VGFp
bExpc3QoJkZkby0+RXZ0Y2huTGlzdCwgJkNvbnRleHQtPkVudHJ5LCAmRmRv
LT5FdnRjaG5Mb2NrKTsKIAotICAgIE91dC0+TG9jYWxQb3J0ID0gQ29udGV4
dC0+TG9jYWxQb3J0OwotICAgICpJbmZvID0gc2l6ZW9mKFhFTklGQUNFX0VW
VENITl9CSU5EX1VOQk9VTkRfT1VUKTsKLQogICAgIGlmICghSW4tPk1hc2sp
IHsKICAgICAgICAgKFZPSUQpIFhFTkJVU19FVlRDSE4oVW5tYXNrLAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmRmRvLT5FdnRjaG5JbnRlcmZh
Y2UsCkBAIC0yMjEsNiArMjE4LDkgQEAgSW9jdGxFdnRjaG5CaW5kVW5ib3Vu
ZCgKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVFJVRSk7CiAgICAg
fQogCisgICAgT3V0LT5Mb2NhbFBvcnQgPSBDb250ZXh0LT5Mb2NhbFBvcnQ7
CisgICAgKkluZm8gPSBzaXplb2YoWEVOSUZBQ0VfRVZUQ0hOX0JJTkRfVU5C
T1VORF9PVVQpOworCiAgICAgVHJhY2UoIjwgTG9jYWxQb3J0ICVsdSwgQ29u
dGV4dCAlcFxuIiwgQ29udGV4dC0+TG9jYWxQb3J0LCBDb250ZXh0KTsKICAg
ICByZXR1cm4gU1RBVFVTX1NVQ0NFU1M7CiAKQEAgLTMwNCw5ICszMDQsNiBA
QCBJb2N0bEV2dGNobkJpbmRJbnRlcmRvbWFpbigKIAogICAgIEV4SW50ZXJs
b2NrZWRJbnNlcnRUYWlsTGlzdCgmRmRvLT5FdnRjaG5MaXN0LCAmQ29udGV4
dC0+RW50cnksICZGZG8tPkV2dGNobkxvY2spOwogCi0gICAgT3V0LT5Mb2Nh
bFBvcnQgPSBDb250ZXh0LT5Mb2NhbFBvcnQ7Ci0gICAgKkluZm8gPSBzaXpl
b2YoWEVOSUZBQ0VfRVZUQ0hOX0JJTkRfSU5URVJET01BSU5fT1VUKTsKLQog
ICAgIGlmICghSW4tPk1hc2spIHsKICAgICAgICAgKFZPSUQpIFhFTkJVU19F
VlRDSE4oVW5tYXNrLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
RmRvLT5FdnRjaG5JbnRlcmZhY2UsCkBAIC0zMTUsNiArMzEyLDkgQEAgSW9j
dGxFdnRjaG5CaW5kSW50ZXJkb21haW4oCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFRSVUUpOwogICAgIH0KIAorICAgIE91dC0+TG9jYWxQb3J0
ID0gQ29udGV4dC0+TG9jYWxQb3J0OworICAgICpJbmZvID0gc2l6ZW9mKFhF
TklGQUNFX0VWVENITl9CSU5EX0lOVEVSRE9NQUlOX09VVCk7CisKICAgICBU
cmFjZSgiPCBMb2NhbFBvcnQgJWx1LCBDb250ZXh0ICVwXG4iLCBDb250ZXh0
LT5Mb2NhbFBvcnQsIENvbnRleHQpOwogCiAgICAgcmV0dXJuIFNUQVRVU19T
VUNDRVNTOwotLSAKMi40Ny4xCgo=

--=separator
Content-Type: application/octet-stream; name="xsa468/xeniface-04.patch"
Content-Disposition: attachment; filename="xsa468/xeniface-04.patch"
Content-Transfer-Encoding: base64

RnJvbSBjZDIyY2M1Y2IzZTcyZTM2MzRiNzE5MjkwMDE1ZGM1ZmZmZTJiM2Vj
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBPd2VuIFNtaXRoIDxv
d2VuLnNtaXRoQGNsb3VkLmNvbT4KRGF0ZTogVGh1LCAzIEFwciAyMDI1IDE0
OjM0OjM2ICswMTAwClN1YmplY3Q6IFtQQVRDSCAyLzJdIEZpeCBsZWFrIGlu
IFBlcm1pc3Npb24gbGlzdAoKU2lnbmVkLW9mZi1ieTogT3dlbiBTbWl0aCA8
b3dlbi5zbWl0aEBjbG91ZC5jb20+ClJldmlld2VkLWJ5OiBUdSBEaW5oIDxu
Z29jLXR1LmRpbmhAdmF0ZXMudGVjaD4KUmV2aWV3ZWQtYnk6IFBhdWwgRHVy
cmFudCA8cGF1bEB4ZW4ub3JnPgotLS0KIHNyYy94ZW5pZmFjZS9pb2N0bF9z
dG9yZS5jIHwgMSArCiAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKykK
CmRpZmYgLS1naXQgYS9zcmMveGVuaWZhY2UvaW9jdGxfc3RvcmUuYyBiL3Ny
Yy94ZW5pZmFjZS9pb2N0bF9zdG9yZS5jCmluZGV4IDEzNTI3NzM4ZGJiNi4u
MGZhODUwZjJkZjgzIDEwMDY0NAotLS0gYS9zcmMveGVuaWZhY2UvaW9jdGxf
c3RvcmUuYworKysgYi9zcmMveGVuaWZhY2UvaW9jdGxfc3RvcmUuYwpAQCAt
NDM1LDYgKzQzNSw3IEBAIElvY3RsU3RvcmVTZXRQZXJtaXNzaW9ucygKICAg
ICBpZiAoIU5UX1NVQ0NFU1Moc3RhdHVzKSkKICAgICAgICAgZ290byBmYWls
NjsKIAorICAgIF9fRnJlZVBlcm1pc3Npb25zKFBlcm1pc3Npb25zKTsKICAg
ICBfX0ZyZWVDYXB0dXJlZEJ1ZmZlcihQYXRoKTsKICAgICByZXR1cm4gc3Rh
dHVzOwogCi0tIAoyLjQ3LjEKCg==

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue May 27 12:53:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 12:53:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998386.1379112 (Exim 4.92)
	(envelope-from )
	id 1uJtoJ-0007K2-Gi; Tue, 27 May 2025 12:53:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998386.1379112; Tue, 27 May 2025 12:53: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 1uJtoJ-0007Jv-EA; Tue, 27 May 2025 12:53:39 +0000
Received: by outflank-mailman (input) for mailman id 998386;
 Tue, 27 May 2025 12:53:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJtoI-0007Jo-9V
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 12:53:38 +0000
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [2a00:1450:4864:20::333])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9ae248aa-3af9-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 14:53:37 +0200 (CEST)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43edecbfb94so45857415e9.1
 for ; Tue, 27 May 2025 05:53:37 -0700 (PDT)
Received: from [10.81.43.171] ([46.149.103.14])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f6b29633sm281869405e9.8.2025.05.27.05.53.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 05:53: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" 
X-Inumbo-ID: 9ae248aa-3af9-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748350416; x=1748955216; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=jDxMqCbJ31GJsysLj04fvyIc49yzVVvkUrD0csHQrik=;
        b=jNP2WAIEvKtJuzcowbVZm3fQ+XuioeWY0HwMCLPH9WWcVKTr2uxx45wvQ0iKLhEima
         c6wEga9tKDk8xxrPmnGlwppra+fxtr7lCHYmgEBMJWAB8vGgZDLRJlBwwT8jhvG7eF43
         5KrCGIHHui606x5c12S6iMtUlmcjIE8Jgi9Ig=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748350416; x=1748955216;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jDxMqCbJ31GJsysLj04fvyIc49yzVVvkUrD0csHQrik=;
        b=iN/bOQwHPp8/HEm5dhTJHRi1k3jIRCK9KMtEYcT0vzVIpmYLvx5qrGIqnLVmAGbJbx
         hOToXg6TIYfGZ9HO70OIeZbn9WmpRcCoHXyVoDtNOdwxCP06mFwqUGCtoPE0itaUCRHi
         P97Dde9Ubpcywf/UQIzbo8cKPpKrTqhZ3EjI28sHjY5ir1+8Tx3zJM83wSea5u53XHSk
         MdLoDwoldT/YwxScTW353ykK5ekjKkD423xERkUGzPK4kWlbJwamAkMxAx/m/Jc46QtL
         G/TsEYUpLelasVoV+xotByuGUQMbL9kS4z0ikLs3kpoPiaoUWWELfhIY5C33Was8MkCw
         H7uA==
X-Forwarded-Encrypted: i=1; AJvYcCXN3dWC53wqnFhRbVmSDVosvpTQNZuW+WuPRVMXw7seqDqYkXcKSHHchpeih8aH2JqdWwLgLQZeo9s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyB++/60Du780eRb+OeAmsHPVbHiTg2smnY0yCjWSD+UycmxI/4
	X6IoTxRtmArSNLCIgoN9etRiP1yQhnct578YYF6KryGNkwIOJGzbuTIAHKDVC0AGy78=
X-Gm-Gg: ASbGncud/OqJFoXwk4/LMnzRAv4pO38ORLnY9JfMJvwJWpCO3WOBB7+rDM1yCjRwhB9
	+85nuEubdFWEwBRFu/+ag1giuMcXcNuPsAnvJjsdYQV/0G5KocPG61OOIRwlqr5G2NVu8+zzKYN
	h0GBrcAt2OQEXmOtFhrT87AUWRDn32317JZwtVOX1HULbTFFI3zvRvJK/1FIPIV4CYUPTRUO8EN
	bCiaNsjYDtCTPECzjemTWLvmmwS8O5LBKtC3C4BR2JRyAlJxNj5ZOY3G70/VJb2fwgrQygYwnRj
	dwclarGPIuG4Z/lOFsoHRdHWJHH9Ba/ziRbJ1GcP3pzcyElb4yqvey+Oc7EvUg==
X-Google-Smtp-Source: AGHT+IHZ18+0WLyq2lWNQ0tbsHv2rtYT4Rkp8J9sAVYbYze0jr/srmFucbmheW5Kwm5bRqWhmzBdkQ==
X-Received: by 2002:a05:600c:4e0c:b0:442:faa3:fadb with SMTP id 5b1f17b1804b1-44c917f3ea8mr133628375e9.2.1748350416322;
        Tue, 27 May 2025 05:53:36 -0700 (PDT)
Message-ID: 
Date: Tue, 27 May 2025 13:53:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/ACPI: move scheduler enable/disable calls out of
 freeze/thaw_domains
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mykola Kvach , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <974033e9ff0df3ce8a74efaa33f1cee1dcbdb030.1748340071.git.mykola_kvach@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: <974033e9ff0df3ce8a74efaa33f1cee1dcbdb030.1748340071.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27/05/2025 11:04 am, Mykola Kvach wrote:
> From: Mykola Kvach 
>
> The scheduler_disable and scheduler_enable calls have been removed
> from freeze_domains and thaw_domains, respectively, and relocated
> to their usage context in enter_state. This change addresses
> the concern about misleading function semantics, as the scheduler
> operations are not directly related to the domain pausing/resuming
> implied by the freeze/thaw naming.
>
> Suggested-by: Jan Beulich 
> Signed-off-by: Mykola Kvach 

FYI I've kicked off a run with this patch:

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1838715729

which includes the real suspend/resume testing on several pieces of
hardware.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 27 13:20:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 13:20:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998394.1379124 (Exim 4.92)
	(envelope-from )
	id 1uJuET-0002fj-Di; Tue, 27 May 2025 13:20:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998394.1379124; Tue, 27 May 2025 13: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 1uJuET-0002fc-8f; Tue, 27 May 2025 13:20:41 +0000
Received: by outflank-mailman (input) for mailman id 998394;
 Tue, 27 May 2025 13:20:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uJuES-0002fW-R5
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 13:20:40 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 61bd2c9b-3afd-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 15:20:39 +0200 (CEST)
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 7406122006;
 Tue, 27 May 2025 13:20:38 +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 0B5441388B;
 Tue, 27 May 2025 13:20:38 +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 MoKqACa8NWiwKAAAD6G6ig
 (envelope-from ); Tue, 27 May 2025 13:20: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" 
X-Inumbo-ID: 61bd2c9b-3afd-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748352038; 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=n1tNRQt6zFhFYYvUhdqgR/JquhHinbRBa7p6fBgvX4M=;
	b=Vbv6WMhHpFngSkWk8Kd8De1gl6c6Y3uo23yOgmjq6cRe8BHOpKDsaB/Sr4iSkXfCQz54WA
	9ZglBJhBpSRpQGrQt9lAz6xzZJYEbVPbSf6i6Pr4SONqJFJUGOpNrwKZsx9NAsZhcwPyZm
	/CB9TttvkkqTvc2gU9cR4IQi9bbxqR8=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=Vbv6WMhH
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748352038; 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=n1tNRQt6zFhFYYvUhdqgR/JquhHinbRBa7p6fBgvX4M=;
	b=Vbv6WMhHpFngSkWk8Kd8De1gl6c6Y3uo23yOgmjq6cRe8BHOpKDsaB/Sr4iSkXfCQz54WA
	9ZglBJhBpSRpQGrQt9lAz6xzZJYEbVPbSf6i6Pr4SONqJFJUGOpNrwKZsx9NAsZhcwPyZm
	/CB9TttvkkqTvc2gU9cR4IQi9bbxqR8=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Oleksii Kurochko ,
	Community Manager ,
	Samuel Thibault 
Subject: [PATCH v4 0/4] remove qemu-traditional
Date: Tue, 27 May 2025 15:20:29 +0200
Message-ID: <20250527132035.985-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	MIME_TRACE(0.00)[0:+];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCPT_COUNT_TWELVE(0.00)[13];
	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];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_CC(0.00)[suse.com,vates.tech,citrix.com,amd.com,xen.org,kernel.org,invisiblethingslab.com,gmail.com,xenproject.org,ens-lyon.org];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:dkim];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Queue-Id: 7406122006
X-Spam-Flag: NO
X-Spam-Level: 
X-Spam-Score: -1.51

Remove the qemu-traditional support. This includes the Mini-OS
based ioemu-stubdom.

Don't remove ROMBIOS for now, as it can be used with qemu (XenServer
is doing that).

After adding the series a run of autoconf should be done.

Changes in V2:
- addressed comments

Changes in V3:
- patches 1 and 5 of V2 have been applied already
- addressed comments

Changes in V4:
- addressed comments

Juergen Gross (4):
  docs: remove qemu-traditional support from documentation
  tools: remove support for running a guest with qemu-traditional
  tools: remove qemu-traditional
  build: don't require full tools build for building stubdoms

 .gitignore                                    |   3 -
 CHANGELOG.md                                  |   2 +
 Config.mk                                     |  38 --
 INSTALL                                       |  13 -
 MAINTAINERS                                   |   4 -
 Makefile                                      |   2 +-
 README                                        |   2 +-
 SUPPORT.md                                    |  16 -
 config/Paths.mk.in                            |   3 +-
 config/Tools.mk.in                            |   1 -
 docs/man/xl-pci-configuration.5.pod           |   4 +-
 docs/man/xl.cfg.5.pod.in                      |  49 +--
 docs/misc/stubdom.txt                         |  52 ---
 docs/misc/xenstore-paths.pandoc               |   3 +-
 docs/process/branching-checklist.txt          |   4 -
 docs/process/release-technician-checklist.txt |   3 -
 docs/process/xen-release-management.pandoc    |   2 +-
 stubdom/.gitignore                            |   3 -
 stubdom/Makefile                              |  97 +-----
 stubdom/configure                             |  89 -----
 stubdom/configure.ac                          |  15 -
 stubdom/ioemu-minios.cfg                      |   6 -
 tools/Makefile                                |  58 ----
 tools/Rules.mk                                |   3 -
 tools/config.h.in                             |   3 -
 tools/configure                               |  42 +--
 tools/configure.ac                            |  21 +-
 tools/firmware/hvmloader/Makefile             |   4 +-
 tools/firmware/hvmloader/pci.c                |  17 +-
 tools/firmware/hvmloader/util.c               |   9 +-
 tools/libacpi/mk_dsdt.c                       | 185 +++-------
 tools/libs/light/libxl_create.c               |  78 +----
 tools/libs/light/libxl_device.c               |  19 -
 tools/libs/light/libxl_disk.c                 |   7 -
 tools/libs/light/libxl_dm.c                   | 327 +-----------------
 tools/libs/light/libxl_dom.c                  |  10 -
 tools/libs/light/libxl_dom_save.c             | 140 --------
 tools/libs/light/libxl_dom_suspend.c          |  65 ----
 tools/libs/light/libxl_domain.c               |  15 -
 tools/libs/light/libxl_exec.c                 |  75 ----
 tools/libs/light/libxl_internal.c             |   6 +-
 tools/libs/light/libxl_internal.h             |  68 +---
 tools/libs/light/libxl_pci.c                  | 183 ----------
 tools/libs/light/libxl_sr_stream_format.h     |   2 +-
 tools/libs/light/libxl_stream_write.c         |   4 -
 tools/libs/light/libxl_types.idl              |   2 +-
 tools/python/xen/migration/libxl.py           |   2 -
 tools/xl/xl_parse.c                           |   5 +-
 48 files changed, 107 insertions(+), 1654 deletions(-)
 delete mode 100644 stubdom/ioemu-minios.cfg

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 13:20:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 13:20:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998395.1379133 (Exim 4.92)
	(envelope-from )
	id 1uJuEa-0002vH-Ip; Tue, 27 May 2025 13:20:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998395.1379133; Tue, 27 May 2025 13: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 1uJuEa-0002v8-Fb; Tue, 27 May 2025 13:20:48 +0000
Received: by outflank-mailman (input) for mailman id 998395;
 Tue, 27 May 2025 13:20:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uJuEZ-0002tx-7a
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 13:20:47 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 64e50872-3afd-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 15:20:44 +0200 (CEST)
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 392D922008;
 Tue, 27 May 2025 13:20: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 E41E91388B;
 Tue, 27 May 2025 13:20: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 3Ps7Niu8NWi2KAAAD6G6ig
 (envelope-from ); Tue, 27 May 2025 13:20: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" 
X-Inumbo-ID: 64e50872-3afd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748352044; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=sMkmTH35IgkTQldbS4H8ZzVZy4JQeGd0sxoFnseahf0=;
	b=LswAkzh9f3xBU5tbrBBMpxjYN5laRPi7NNGr73LG/HEJPx5KpTAOhuBtWKRYB1A+rjFcpn
	GSyWYh7Rq30wJXskMNxt8fn8ZcqUAklXEAZcAgKCdq1fGxB9X6pfi1LCBvpETYDgEMwoQx
	GOemHmjAiy+K5s994sGYOZaTt5DE/2M=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748352044; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=sMkmTH35IgkTQldbS4H8ZzVZy4JQeGd0sxoFnseahf0=;
	b=LswAkzh9f3xBU5tbrBBMpxjYN5laRPi7NNGr73LG/HEJPx5KpTAOhuBtWKRYB1A+rjFcpn
	GSyWYh7Rq30wJXskMNxt8fn8ZcqUAklXEAZcAgKCdq1fGxB9X6pfi1LCBvpETYDgEMwoQx
	GOemHmjAiy+K5s994sGYOZaTt5DE/2M=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v4 1/4] docs: remove qemu-traditional support from documentation
Date: Tue, 27 May 2025 15:20:30 +0200
Message-ID: <20250527132035.985-2-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250527132035.985-1-jgross@suse.com>
References: <20250527132035.985-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [0.20 / 50.00];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[9];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Score: 0.20
X-Spam-Level: 

In preparation to no longer support qemu-traditional (including
qemu-stubdom), remove it from documentation.

Signed-off-by: Juergen Gross 
Reviewed-by: Anthony PERARD 
---
V2:
- mention "qemu_xen_traditional" in xenstore-paths.pandoc as a removed
  device model variant (Andrew Cooper)
- don't drop Config.mk related documentation for QEMU_TRADITIONAL_REVISION
  (Jan Beulich)
V3:
- drop another opengl reference (Anthony Perard)
- drop 2 superfluous sentences for gfx_passthru (Anthony Perard)
- reword a bios_path_override note (Anthony Perard)
---
 docs/man/xl-pci-configuration.5.pod           |  4 +-
 docs/man/xl.cfg.5.pod.in                      | 49 +++--------------
 docs/misc/stubdom.txt                         | 52 -------------------
 docs/misc/xenstore-paths.pandoc               |  3 +-
 docs/process/branching-checklist.txt          |  3 --
 docs/process/release-technician-checklist.txt |  2 -
 docs/process/xen-release-management.pandoc    |  2 +-
 7 files changed, 13 insertions(+), 102 deletions(-)

diff --git a/docs/man/xl-pci-configuration.5.pod b/docs/man/xl-pci-configuration.5.pod
index ec76f590b7..0691f06ad3 100644
--- a/docs/man/xl-pci-configuration.5.pod
+++ b/docs/man/xl-pci-configuration.5.pod
@@ -111,8 +111,8 @@ if this parameter is not specified.
 =item Description
 
 By default pciback only allows PV guests to write "known safe" values
-into PCI configuration space, likewise QEMU (both qemu-xen and
-qemu-xen-traditional) imposes the same constraint on HVM guests.
+into PCI configuration space, likewise QEMU imposes the same constraint
+on HVM guests.
 However, many devices require writes to other areas of the configuration space
 in order to operate properly.  This option tells the backend (pciback or QEMU)
 to allow all writes to the PCI configuration space of this device by this
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 7339c44efd..c388899306 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -841,7 +841,7 @@ This option does not control the emulated graphics card presented to
 an HVM guest. See B below for how to
 configure the emulated device. If B options
 are used in a PV guest configuration, B will pick up B, B,
-B, B, B, B, B and
+B, B, B, B and
 B to construct the paravirtual framebuffer device for the guest.
 
 Each B is a comma-separated list of C
@@ -895,12 +895,6 @@ is used.
 Specifies the path to the X authority file that should be used to
 connect to the X server when the B option is used.
 
-=item B
-
-Enable OpenGL acceleration of the SDL display. Only effects machines
-using B and only if the
-device-model was compiled with OpenGL support. The default is 0 (disabled).
-
 =item B
 
 Configure the keymap to use for the keyboard associated with this
@@ -1215,17 +1209,11 @@ working graphics passthrough. See the XenVGAPassthroughTestedAdapters
 L wiki page
 for graphics cards currently supported by B.
 
-B is currently supported both with the qemu-xen-traditional
-device-model and upstream qemu-xen device-model.
-
 When given as a boolean the B option either disables graphics
 card passthrough or enables autodetection.
 
 When given as a string the B option describes the type
-of device to enable. Note that this behavior is only supported with the
-upstream qemu-xen device-model. With qemu-xen-traditional IGD (Intel Graphics
-Device) is always assumed and options other than autodetect or explicit IGD
-will result in an error.
+of device to enable.
 
 Currently, valid values for the option are:
 
@@ -1903,10 +1891,7 @@ it may be useful to request a different one, like UEFI.
 
 =item B
 
-Loads ROMBIOS, a 16-bit x86 compatible BIOS. This is used by default
-when B. This is the only BIOS
-option supported when B. This is
-the BIOS used by all previous Xen versions.
+Loads ROMBIOS, a 16-bit x86 compatible BIOS.
 
 =item B
 
@@ -1926,8 +1911,7 @@ Override the path to the blob to be used as BIOS. The blob provided here MUST
 be consistent with the B which you have specified. You should not
 normally need to specify this option.
 
-This option does not have any effect if using B or
-B.
+Requires B.
 
 =item B
 
@@ -2516,15 +2500,10 @@ Sets the amount of RAM which the emulated video card will contain,
 which in turn limits the resolutions and bit depths which will be
 available.
 
-When using the qemu-xen-traditional device-model, the default as well as
-minimum amount of video RAM for stdvga is 8 MB, which is sufficient for e.g.
-1600x1200 at 32bpp. For the upstream qemu-xen device-model, the default and
-minimum is 16 MB.
+When using stdvga, the default and minimum is 16 MB.
 
-When using the emulated Cirrus graphics card (B) and the
-qemu-xen-traditional device-model, the amount of video RAM is fixed at 4 MB,
-which is sufficient for 1024x768 at 32 bpp. For the upstream qemu-xen
-device-model, the default and minimum is 8 MB.
+When using the emulated Cirrus graphics card (B), the
+default and minimum is 8 MB.
 
 For QXL vga, both the default and minimal are 128MB.
 If B is set less than 128MB, an error will be triggered.
@@ -2590,12 +2569,6 @@ B manpage. The default is B.
 Specifies that the display should be presented via an X window (using
 Simple DirectMedia Layer). The default is (0) not enabled.
 
-=item B
-
-Enable OpenGL acceleration of the SDL display. Only effects machines
-using B and only if the
-device-model was compiled with OpenGL support. Default is (0) false.
-
 =item B
 
 Enable or disable the virtual graphics device.  The default is to
@@ -2925,11 +2898,6 @@ Valid values are:
 Use the device-model merged into the upstream QEMU project.
 This device-model is the default for Linux dom0.
 
-=item B
-
-Use the device-model based upon the historical Xen fork of QEMU.
-This device-model is still the default for NetBSD dom0.
-
 =back
 
 It is recommended to accept the default value for new guests.  If
@@ -2949,8 +2917,7 @@ to specify this option.
 Override the path to the kernel image used as device-model stubdomain.
 The binary provided here MUST be consistent with the
 B which you have specified.
-In case of B it is expected to be MiniOS-based stubdomain
-image, in case of B it is expected to be Linux-based stubdomain
+In case of B it is expected to be Linux-based stubdomain
 kernel.
 
 =item B
diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
index 64c220db20..cfcba4ba96 100644
--- a/docs/misc/stubdom.txt
+++ b/docs/misc/stubdom.txt
@@ -23,58 +23,6 @@ and https://wiki.xen.org/wiki/Device_Model_Stub_Domains for more
 information on device model stub domains
 
 
-Toolstack to MiniOS ioemu stubdomain protocol
----------------------------------------------
-
-This section describe communication protocol between toolstack and
-qemu-traditional running in MiniOS stubdomain. The protocol include
-expectations of both qemu and stubdomain itself.
-
-Setup (done by toolstack, expected by stubdomain):
- - Block devices for target domain are connected as PV disks to stubdomain,
-   according to configuration order, starting with xvda
- - Network devices for target domain are connected as PV nics to stubdomain,
-   according to configuration order, starting with 0
- - if graphics output is expected, VFB and VKB devices are set for stubdomain
-   (its backend is responsible for exposing them using appropriate protocol
-   like VNC or Spice)
- - other target domain's devices are not connected at this point to stubdomain
-   (may be hot-plugged later)
- - QEMU command line (space separated arguments) is stored in
-   /vm//image/dmargs xenstore path
- - target domain id is stored in /local/domain//target xenstore path
-?? - bios type is stored in /local/domain//hvmloader/bios
- - stubdomain's console 0 is connected to qemu log file
- - stubdomain's console 1 is connected to qemu save file (for saving state)
- - stubdomain's console 2 is connected to qemu save file (for restoring state)
- - next consoles are connected according to target guest's serial console configuration
-
-Startup:
-1. PV stubdomain is started with ioemu-stubdom.gz kernel and no initrd
-2. stubdomain initialize relevant devices
-3. stubdomain signal readiness by writing "running" to /local/domain//device-model//state xenstore path
-4. now stubdomain is considered running
-
-Runtime control (hotplug etc):
-Toolstack can issue command through xenstore. The sequence is (from toolstack POV):
-1. Write parameter to /local/domain//device-model//parameter.
-2. Write command to /local/domain//device-model//command.
-3. Wait for command result in /local/domain//device-model//state (command specific value).
-4. Write "running" back to /local/domain//device-model//state.
-
-Defined commands:
- - "pci-ins" - PCI hot plug, results:
-   - "pci-inserted" - success
-   - "pci-insert-failed" - failure
- - "pci-rem" - PCI hot remove, results:
-   - "pci-removed" - success
-   - ??
- - "save" - save domain state to console 1, results:
-   - "paused" - success
- - "continue" - resume domain execution, after loading state from console 2 (require -loadvm command argument), results:
-   - "running" - success
-
-
 Toolstack to Linux ioemu stubdomain protocol
 --------------------------------------------
 
diff --git a/docs/misc/xenstore-paths.pandoc b/docs/misc/xenstore-paths.pandoc
index a604f6b1c6..01a340fafc 100644
--- a/docs/misc/xenstore-paths.pandoc
+++ b/docs/misc/xenstore-paths.pandoc
@@ -636,7 +636,8 @@ Trustworthy copy of /local/domain/$DOMID/backend/$KIND/$DEVID/$NODE.
 
 #### /libxl/$DOMID/dm-version ("qemu_xen"|"qemu_xen_traditional") = [n,INTERNAL]
 
-The device model version for a domain.
+The device model version for a domain. Note that "qemu_xen_traditional" is
+a device model variant which has been removed from Xen.
 
 #### /libxl/$DOMID/remus/netbuf/$DEVID/ifb = STRING [n,INTERNAL]
 
diff --git a/docs/process/branching-checklist.txt b/docs/process/branching-checklist.txt
index 3dfa8ec257..aa7a27eed5 100644
--- a/docs/process/branching-checklist.txt
+++ b/docs/process/branching-checklist.txt
@@ -14,8 +14,6 @@ ov=4.0
     cd ~/git/qemu-xen.git
     git branch staging-$v staging
     git branch stable-$v master
-    cd ~/git/qemu-xen-traditional.git
-    git branch stable-$v master
 
 # make branch in libvirt
     ssh xen@xenbits.xen.org
@@ -63,7 +61,6 @@ ov=4.0
     cp xen--staging.patchbot-reported-heads xen--staging-$v.patchbot-reported-heads
     cp qemu-xen--master.patchbot-reported-heads  qemu-xen--stable-$v.patchbot-reported-heads
     cp qemu-xen--staging.patchbot-reported-heads  qemu-xen--staging-$v.patchbot-reported-heads
-    cp qemu-xen-traditional--master.patchbot-reported-heads qemu-xen-traditional--stable-$v.patchbot-reported-heads
 
     #emacs versions
     perl -i~ -pe 'next unless m/\b\Q'$ov'\E\b/; $x=$_; $x=~ s/\b\Q'$ov'\E\b/'$v'/g; print $x;' versions
diff --git a/docs/process/release-technician-checklist.txt b/docs/process/release-technician-checklist.txt
index 7bbe7c1489..829e8ec47b 100644
--- a/docs/process/release-technician-checklist.txt
+++ b/docs/process/release-technician-checklist.txt
@@ -32,8 +32,6 @@ t=RELEASE-$r
   git show # should show appropriate intended commit
   git-tag -u 'Xen.org Xen tree code signing' -m "Xen $v" xen-$v
 
-  git-push xenbits.xen.org:/home/xen/git/qemu-xen-traditional.git $s:stable-$x xen-$v
-
 # consider making tag in minios, and updating xen.git Config.mk
   git checkout SOMETHING
   git show # should show appropriate intended commit
diff --git a/docs/process/xen-release-management.pandoc b/docs/process/xen-release-management.pandoc
index 7826419dad..5da18f6da1 100644
--- a/docs/process/xen-release-management.pandoc
+++ b/docs/process/xen-release-management.pandoc
@@ -193,7 +193,7 @@ from the last RC:
 
 1. Send out commit moratorium emails to committers@.
 
-2. Check all the trees (mini-os, qemu-trad, qemu-xen, seabios, ovmf etc).
+2. Check all the trees (mini-os, qemu-xen, seabios, ovmf etc).
 They have the correct commits and all security patches applied. There will be
 tools provided.
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 13:20:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 13:20:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998396.1379143 (Exim 4.92)
	(envelope-from )
	id 1uJuEf-0003D9-TC; Tue, 27 May 2025 13:20:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998396.1379143; Tue, 27 May 2025 13:20: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 1uJuEf-0003Cx-QF; Tue, 27 May 2025 13:20:53 +0000
Received: by outflank-mailman (input) for mailman id 998396;
 Tue, 27 May 2025 13:20:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uJuEe-0002tx-P0
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 13:20:53 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 686240e2-3afd-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 15:20:50 +0200 (CEST)
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 0F0CF1FCF7;
 Tue, 27 May 2025 13:20:50 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id AA25F1388B;
 Tue, 27 May 2025 13:20:49 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id jK35JzG8NWi7KAAAD6G6ig
 (envelope-from ); Tue, 27 May 2025 13:20: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" 
X-Inumbo-ID: 686240e2-3afd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748352050; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=tU5QFICkNQ7hlXTT5UCIPUv95/pjHx0DdiUteXwYvsU=;
	b=auBuQJ6x+H3XjeCh2O3rj8a9Oa6iHxHlpaglaMU4p+Xd/o5f55UShpk04wpWKWiyAgsuc9
	X4hgdicghp+RDVP8W5Yn0yq8x3ZNe2ZQ7xXi1L/I/oh1NKfOAFGsVPCbQj3hHy0W81USFq
	FrhQ2CsLmeGexsyfJcb+Z1PrCxA51z4=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=auBuQJ6x
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748352050; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=tU5QFICkNQ7hlXTT5UCIPUv95/pjHx0DdiUteXwYvsU=;
	b=auBuQJ6x+H3XjeCh2O3rj8a9Oa6iHxHlpaglaMU4p+Xd/o5f55UShpk04wpWKWiyAgsuc9
	X4hgdicghp+RDVP8W5Yn0yq8x3ZNe2ZQ7xXi1L/I/oh1NKfOAFGsVPCbQj3hHy0W81USFq
	FrhQ2CsLmeGexsyfJcb+Z1PrCxA51z4=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH v4 2/4] tools: remove support for running a guest with qemu-traditional
Date: Tue, 27 May 2025 15:20:31 +0200
Message-ID: <20250527132035.985-3-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250527132035.985-1-jgross@suse.com>
References: <20250527132035.985-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-2.01 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	TO_DN_SOME(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];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_TLS_ALL(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	RCPT_COUNT_SEVEN(0.00)[7];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	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:mid,suse.com:dkim,suse.com:email]
X-Rspamd-Queue-Id: 0F0CF1FCF7
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 

Remove the code in tools for running a guest with qemu-traditional.
This covers xl, libxl, libacpi, hvmloader and the related python and
go bindings.

Signed-off-by: Juergen Gross 
Acked-by: Jan Beulich  # hvmloader
Reviewed-by: Anthony PERARD 
---
V2:
- Keep most of the removed comment in hvmloader, while removing parts
  of another one (Jan Beulich)
V3:
- keep the default of allow_memory_relocate = 1; (Anthony Perard)
- expand a comment in hvmloader's pci_setup() (Anthony Perard)
- don't build in dsdt_anycpu and dsdt_15cpu if not needed (Anthony Perard)
- make --dm_version a mandatory mk_dsdt parameter (Anthony Perard)
- simplify code in libxl__domain_build_info_setdefault() (Anthony Perard)
- make comments in libxl_dm.c more clear (Anthony Perard)
- remove some more no longer used libxl functions (Anthony Perard)
- keep QEMU_XEN_TRADITIONAL define (Anthony Perard)
V4:
- always reset DSDT_FILES in hvmloader Makefile (Jan Beulich)
- fix typos in comments (Anthone Perard)
- avoid build failure on Arm (Anthony Perard)
---
 tools/firmware/hvmloader/Makefile         |   4 +-
 tools/firmware/hvmloader/pci.c            |  17 +-
 tools/firmware/hvmloader/util.c           |   9 +-
 tools/libacpi/mk_dsdt.c                   | 185 +++---------
 tools/libs/light/libxl_create.c           |  78 +-----
 tools/libs/light/libxl_device.c           |  19 --
 tools/libs/light/libxl_disk.c             |   7 -
 tools/libs/light/libxl_dm.c               | 327 +---------------------
 tools/libs/light/libxl_dom.c              |  10 -
 tools/libs/light/libxl_dom_save.c         | 140 ---------
 tools/libs/light/libxl_dom_suspend.c      |  65 -----
 tools/libs/light/libxl_domain.c           |  15 -
 tools/libs/light/libxl_exec.c             |  75 -----
 tools/libs/light/libxl_internal.c         |   6 +-
 tools/libs/light/libxl_internal.h         |  68 +----
 tools/libs/light/libxl_pci.c              | 183 ------------
 tools/libs/light/libxl_sr_stream_format.h |   2 +-
 tools/libs/light/libxl_stream_write.c     |   4 -
 tools/libs/light/libxl_types.idl          |   2 +-
 tools/python/xen/migration/libxl.py       |   2 -
 tools/xl/xl_parse.c                       |   5 +-
 21 files changed, 77 insertions(+), 1146 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index cc5dc00498..ec1f452a7e 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -53,12 +53,14 @@ endif
 endif
 
 ROMS := 
+DSDT_FILES := 
 
 ifeq ($(CONFIG_ROMBIOS),y)
 OBJS += optionroms.o 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM)
+DSDT_FILES += dsdt_anycpu.c dsdt_15cpu.c
 endif
 
 # Suppress the warning about LOAD segments with RWX permissions, as what we
@@ -76,7 +78,7 @@ rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
 ACPI_PATH = ../../libacpi
-DSDT_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+DSDT_FILES += dsdt_anycpu_qemu_xen.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(DSDT_FILES)) build.o static_tables.o
 $(ACPI_OBJS): CFLAGS += -iquote . -DLIBACPI_STDUTILS=\"$(CURDIR)/util.h\"
 CFLAGS += -I$(ACPI_PATH)
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index c3c61ca060..cc67b18c03 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -113,17 +113,7 @@ void pci_setup(void)
      * increase the size of the lowmem MMIO hole?  Defaulting to 1
      * here will mean that non-libxl toolstacks (including xend and
      * home-grown ones) means that those using qemu-xen will still
-     * experience the memory relocation bug described below; but it
-     * also means that those using qemu-traditional will *not*
-     * experience any change; and it also means that there is a
-     * work-around for those using qemu-xen, namely switching to
-     * qemu-traditional.
-     *
-     * If we defaulted to 0, and failing to resize the hole caused any
-     * problems with qemu-traditional, then there is no work-around.
-     *
-     * Since xend can only use qemu-traditional, I think this is the
-     * option that will have the least impact.
+     * experience the memory relocation bug described below.
      */
     bool allow_memory_relocate = 1;
 
@@ -347,9 +337,8 @@ void pci_setup(void)
     {
         /*
          * At the moment qemu-xen can't deal with relocated memory regions.
-         * It's too close to the release to make a proper fix; for now,
-         * only allow the MMIO hole to grow large enough to move guest memory
-         * if we're running qemu-traditional.  Items that don't fit will be
+         * Only allow the MMIO hole to grow large enough to move guest memory
+         * if allow_memory_relocate is true.  Items that don't fit will be
          * relocated into the 64-bit address space.
          *
          * This loop now does the following:
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 2d07ce1290..79c0e6bd4a 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -843,14 +843,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 
     /* If the device model is specified switch to the corresponding tables */
     s = xenstore_read("platform/device-model", "");
-    if ( !strncmp(s, "qemu_xen_traditional", 21) )
-    {
-        config->dsdt_anycpu = dsdt_anycpu;
-        config->dsdt_anycpu_len = dsdt_anycpu_len;
-        config->dsdt_15cpu = dsdt_15cpu;
-        config->dsdt_15cpu_len = dsdt_15cpu_len;
-    }
-    else if ( !strncmp(s, "qemu_xen", 9) )
+    if ( !strncmp(s, "qemu_xen", 9) )
     {
         config->dsdt_anycpu = dsdt_anycpu_qemu_xen;
         config->dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len;
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 34f6753f61..8ac4f9d0b4 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -19,8 +19,8 @@ static bool debug = false;
 
 typedef enum dm_version {
     QEMU_NONE,
-    QEMU_XEN_TRADITIONAL,
     QEMU_XEN,
+    QEMU_INVALID
 } dm_version;
 
 static void indent(void)
@@ -68,30 +68,6 @@ static void pop_block(void)
     printf("}\n");
 }
 
-#ifdef CONFIG_X86
-static void pci_hotplug_notify(unsigned int slt)
-{
-    stmt("Notify", "\\_SB.PCI0.S%02X, EVT", slt);
-}
-
-static void decision_tree(
-    unsigned int s, unsigned int e, char *var, void (*leaf)(unsigned int))
-{
-    if ( s == (e-1) )
-    {
-        (*leaf)(s);
-        return;
-    }
-
-    push_block("If", "And(%s, 0x%02x)", var, (e-s)/2);
-    decision_tree((s+e)/2, e, var, leaf);
-    pop_block();
-    push_block("Else", NULL);
-    decision_tree(s, (s+e)/2, var, leaf);
-    pop_block();
-}
-#endif
-
 static struct option options[] = {
     { "maxcpu", 1, 0, 'c' },
 #ifdef CONFIG_X86
@@ -105,7 +81,7 @@ int main(int argc, char **argv)
 {
     unsigned int cpu, max_cpus;
 #if defined(CONFIG_X86)
-    dm_version dm_version = QEMU_XEN_TRADITIONAL;
+    dm_version dm_version = QEMU_INVALID;
     unsigned int slot, dev, intx, link;
 
     max_cpus = HVM_MAX_VCPUS;
@@ -141,8 +117,6 @@ int main(int argc, char **argv)
         case 'q':
             if (strcmp(optarg, "qemu-xen") == 0) {
                 dm_version = QEMU_XEN;
-            } else if (strcmp(optarg, "qemu-xen-traditional") == 0) {
-                dm_version = QEMU_XEN_TRADITIONAL;
             } else if (strcmp(optarg, "none") == 0) {
                 dm_version = QEMU_NONE;
             } else {
@@ -160,6 +134,13 @@ int main(int argc, char **argv)
         }
     }
 
+#ifdef CONFIG_X86
+    if (dm_version == QEMU_INVALID) {
+        fprintf(stderr, "--dm_version is a mandatory parameter.\n");
+        return -1;
+    }
+#endif
+
     /**** DSDT DefinitionBlock start ****/
     /* (we append to existing DSDT definition block) */
     indent_level++;
@@ -278,9 +259,7 @@ int main(int argc, char **argv)
 
     /* Define GPE control method. */
     push_block("Scope", "\\_GPE");
-    push_block("Method",
-               dm_version == QEMU_XEN_TRADITIONAL ? "_L%02d" : "_E%02d",
-               XEN_ACPI_GPE0_CPUHP_BIT);
+    push_block("Method", "_E%02d", XEN_ACPI_GPE0_CPUHP_BIT);
     stmt("\\_SB.PRSC ()", NULL);
     pop_block();
     pop_block();
@@ -302,17 +281,10 @@ int main(int argc, char **argv)
      */
     push_block("Device", "HP0"); {
         stmt("Name", "_HID, EISAID(\"PNP0C02\")");
-        if (dm_version == QEMU_XEN_TRADITIONAL) {
-            stmt("Name", "_CRS, ResourceTemplate() {"
-                 "  IO (Decode16, 0x10c0, 0x10c0, 0x00, 0x82)"
-                 "  IO (Decode16, 0xb044, 0xb044, 0x00, 0x04)"
-                 "}");
-        } else {
-            stmt("Name", "_CRS, ResourceTemplate() {"
-                 "  IO (Decode16, 0xae00, 0xae00, 0x00, 0x10)"
-                 "  IO (Decode16, 0xb044, 0xb044, 0x00, 0x04)"
-                 "}");
-        }
+        stmt("Name", "_CRS, ResourceTemplate() {"
+             "  IO (Decode16, 0xae00, 0xae00, 0x00, 0x10)"
+             "  IO (Decode16, 0xb044, 0xb044, 0x00, 0x04)"
+             "}");
     } pop_block();
 
     /*** PCI-ISA link definitions ***/
@@ -397,60 +369,27 @@ int main(int argc, char **argv)
      * QEMU provides a simple hotplug controller with some I/O to handle
      * the hotplug action and status, which is beyond the ACPI scope.
      */
-    if (dm_version == QEMU_XEN_TRADITIONAL) {
-        for ( slot = 0; slot < 0x100; slot++ )
-        {
-            push_block("Device", "S%02X", slot);
-            /* _ADR == dev:fn (16:16) */
-            stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot & 7));
-            /* _SUN == dev */
-            stmt("Name", "_SUN, 0x%08x", slot >> 3);
-            push_block("Method", "_EJ0, 1");
-            if (debug)
-            {
-                stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-                stmt("Store", "0x88, \\_GPE.DPT2");
-            }
-            stmt("Store", "0x%02x, \\_GPE.PH%02X", /* eject */
-                 (slot & 1) ? 0x10 : 0x01, slot & ~1);
-            pop_block();
-            push_block("Method", "_STA, 0");
-            if (debug)
-            {
-                stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-                stmt("Store", "0x89, \\_GPE.DPT2");
-            }
-            if ( slot & 1 )
-                stmt("ShiftRight", "\\_GPE.PH%02X, 0x04, Local1", slot & ~1);
-            else
-                stmt("And", "\\_GPE.PH%02X, 0x0f, Local1", slot & ~1);
-            stmt("Return", "Local1"); /* IN status as the _STA */
-            pop_block();
-            pop_block();
-        }
-    } else {
-        stmt("OperationRegion", "SEJ, SystemIO, 0xae08, 0x08");
-        push_block("Field", "SEJ, DWordAcc, NoLock, WriteAsZeros");
-        indent(); printf("B0EJ, 32,\n");
-        indent(); printf("B0RM, 32,\n");
-        pop_block();
+    stmt("OperationRegion", "SEJ, SystemIO, 0xae08, 0x08");
+    push_block("Field", "SEJ, DWordAcc, NoLock, WriteAsZeros");
+    indent(); printf("B0EJ, 32,\n");
+    indent(); printf("B0RM, 32,\n");
+    pop_block();
 
-        /* hotplug_slot */
-        for (slot = 1; slot <= 31; slot++) {
-            push_block("Device", "S%i", slot); {
-                stmt("Name", "_ADR, %#06x0000", slot);
-                push_block("Method", "_EJ0,1"); {
-                    stmt("Store", "%#010x, B0EJ", 1 << slot);
-                } pop_block();
-                stmt("Name", "_SUN, %i", slot);
-                push_block("Method", "_STA, 0"); {
-                    push_block("If", "And(B0RM, ShiftLeft(1, %i))", slot);
-                    stmt("Return", "0xF");
-                    pop_block();
-                    stmt("Return", "0x0");
-                } pop_block();
+    /* hotplug_slot */
+    for (slot = 1; slot <= 31; slot++) {
+        push_block("Device", "S%i", slot); {
+            stmt("Name", "_ADR, %#06x0000", slot);
+            push_block("Method", "_EJ0,1"); {
+                stmt("Store", "%#010x, B0EJ", 1 << slot);
             } pop_block();
-        }
+            stmt("Name", "_SUN, %i", slot);
+            push_block("Method", "_STA, 0"); {
+                push_block("If", "And(B0RM, ShiftLeft(1, %i))", slot);
+                stmt("Return", "0xF");
+                pop_block();
+                stmt("Return", "0x0");
+            } pop_block();
+        } pop_block();
     }
 
     pop_block();
@@ -460,26 +399,11 @@ int main(int argc, char **argv)
     /**** GPE start ****/
     push_block("Scope", "\\_GPE");
 
-    if (dm_version == QEMU_XEN_TRADITIONAL) {
-        stmt("OperationRegion", "PHP, SystemIO, 0x10c0, 0x82");
-
-        push_block("Field", "PHP, ByteAcc, NoLock, Preserve");
-        indent(); printf("PSTA, 8,\n"); /* hotplug controller event reg */
-        indent(); printf("PSTB, 8,\n"); /* hotplug controller slot reg */
-        for ( slot = 0; slot < 0x100; slot += 2 )
-        {
-            indent();
-            /* Each hotplug control register manages a pair of pci functions. */
-            printf("PH%02X, 8,\n", slot);
-        }
-        pop_block();
-    } else {
-        stmt("OperationRegion", "PCST, SystemIO, 0xae00, 0x08");
-        push_block("Field", "PCST, DWordAcc, NoLock, WriteAsZeros");
-        indent(); printf("PCIU, 32,\n");
-        indent(); printf("PCID, 32,\n");
-        pop_block();
-    }
+    stmt("OperationRegion", "PCST, SystemIO, 0xae00, 0x08");
+    push_block("Field", "PCST, DWordAcc, NoLock, WriteAsZeros");
+    indent(); printf("PCIU, 32,\n");
+    indent(); printf("PCID, 32,\n");
+    pop_block();
 
     stmt("OperationRegion", "DG1, SystemIO, 0xb044, 0x04");
 
@@ -487,35 +411,16 @@ int main(int argc, char **argv)
     indent(); printf("DPT1, 8, DPT2, 8\n");
     pop_block();
 
-    if (dm_version == QEMU_XEN_TRADITIONAL) {
-        push_block("Method", "_L03, 0, Serialized");
-        /* Detect slot and event (remove/add). */
-        stmt("Name", "SLT, 0x0");
-        stmt("Name", "EVT, 0x0");
-        stmt("Store", "PSTA, Local1");
-        stmt("And", "Local1, 0xf, EVT");
-        stmt("Store", "PSTB, Local1"); /* XXX: Store (PSTB, SLT) ? */
-        stmt("And", "Local1, 0xff, SLT");
-        if (debug)
-        {
-            stmt("Store", "SLT, DPT1");
-            stmt("Store", "EVT, DPT2");
-        }
-        /* Decision tree */
-        decision_tree(0x00, 0x100, "SLT", pci_hotplug_notify);
+    push_block("Method", "_E01");
+    for (slot = 1; slot <= 31; slot++) {
+        push_block("If", "And(PCIU, ShiftLeft(1, %i))", slot);
+        stmt("Notify", "\\_SB.PCI0.S%i, 1", slot);
         pop_block();
-    } else {
-        push_block("Method", "_E01");
-        for (slot = 1; slot <= 31; slot++) {
-            push_block("If", "And(PCIU, ShiftLeft(1, %i))", slot);
-            stmt("Notify", "\\_SB.PCI0.S%i, 1", slot);
-            pop_block();
-            push_block("If", "And(PCID, ShiftLeft(1, %i))", slot);
-            stmt("Notify", "\\_SB.PCI0.S%i, 3", slot);
-            pop_block();
-        }
+        push_block("If", "And(PCID, ShiftLeft(1, %i))", slot);
+        stmt("Notify", "\\_SB.PCI0.S%i, 3", slot);
         pop_block();
     }
+    pop_block();
 
     pop_block();
     /**** GPE end ****/
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index e03599ea99..8bc768b515 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -99,35 +99,14 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         b_info->device_model_ssidref = SECINITSID_DOMDM;
 
     if (!b_info->device_model_version) {
-        if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-            if (libxl_defbool_val(b_info->device_model_stubdomain)) {
-                b_info->device_model_version =
-                    LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
-            } else {
-                b_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
-            }
-        } else {
-            b_info->device_model_version =
-                LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
-        }
-        if (b_info->device_model_version
-                == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
-            const char *dm;
-
-            dm = libxl__domain_device_model(gc, b_info);
-            rc = access(dm, X_OK);
-            if (rc < 0) {
-                /* qemu-xen unavailable, use qemu-xen-traditional */
-                if (errno == ENOENT) {
-                    LOGE(INFO, "qemu-xen is unavailable"
-                         ", using qemu-xen-traditional instead");
-                    b_info->device_model_version =
-                        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
-                } else {
-                    LOGE(ERROR, "qemu-xen access error");
-                    return ERROR_FAIL;
-                }
-            }
+        const char *dm;
+
+        b_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
+        dm = libxl__domain_device_model(gc, b_info);
+        rc = access(dm, X_OK);
+        if (rc < 0) {
+            LOGE(ERROR, "qemu-xen access error");
+            return ERROR_FAIL;
         }
     }
 
@@ -137,8 +116,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
     if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!b_info->u.hvm.bios)
             switch (b_info->device_model_version) {
-            case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-                b_info->u.hvm.bios = LIBXL_BIOS_TYPE_ROMBIOS; break;
             case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
                 b_info->u.hvm.bios = LIBXL_BIOS_TYPE_SEABIOS; break;
             default:
@@ -148,12 +125,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 
         /* Enforce BIOS<->Device Model version relationship */
         switch (b_info->device_model_version) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            if (b_info->u.hvm.bios != LIBXL_BIOS_TYPE_ROMBIOS) {
-                LOG(ERROR, "qemu-xen-traditional requires bios=rombios.");
-                return ERROR_INVAL;
-            }
-            break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
             if (b_info->u.hvm.bios == LIBXL_BIOS_TYPE_ROMBIOS) {
                 LOG(ERROR, "qemu-xen does not support bios=rombios.");
@@ -176,10 +147,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         libxl_defbool_val(b_info->device_model_stubdomain)) {
         if (!b_info->stubdomain_kernel) {
             switch (b_info->device_model_version) {
-                case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-                    b_info->stubdomain_kernel =
-                        libxl__abs_path(NOGC, "ioemu-stubdom.gz", libxl__xenfirmwaredir_path());
-                    break;
                 case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
                     b_info->stubdomain_kernel =
                         libxl__abs_path(NOGC,
@@ -192,8 +159,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         }
         if (!b_info->stubdomain_ramdisk) {
             switch (b_info->device_model_version) {
-                case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-                    break;
                 case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
                     b_info->stubdomain_ramdisk =
                         libxl__abs_path(NOGC,
@@ -299,33 +264,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
             b_info->u.hvm.hdtype = LIBXL_HDTYPE_IDE;
 
         switch (b_info->device_model_version) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            switch (b_info->u.hvm.vga.kind) {
-            case LIBXL_VGA_INTERFACE_TYPE_NONE:
-                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
-                    b_info->video_memkb = 0;
-                break;
-            case LIBXL_VGA_INTERFACE_TYPE_QXL:
-                LOG(ERROR,"qemu upstream required for qxl vga");
-                return ERROR_INVAL;
-                break;
-            case LIBXL_VGA_INTERFACE_TYPE_STD:
-                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
-                    b_info->video_memkb = 8 * 1024;
-                if (b_info->video_memkb < 8 * 1024) {
-                    LOG(ERROR, "videoram must be at least 8 MB for STDVGA on QEMU_XEN_TRADITIONAL");
-                    return ERROR_INVAL;
-                }
-                break;
-            case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
-            default:
-                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
-                    b_info->video_memkb = 4 * 1024;
-                if (b_info->video_memkb != 4 * 1024)
-                    LOG(WARN, "ignoring videoram other than 4 MB for CIRRUS on QEMU_XEN_TRADITIONAL");
-                break;
-            }
-            break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
         default:
             switch (b_info->u.hvm.vga.kind) {
diff --git a/tools/libs/light/libxl_device.c b/tools/libs/light/libxl_device.c
index 4faa5fa3bd..42d71c17bc 100644
--- a/tools/libs/light/libxl_device.c
+++ b/tools/libs/light/libxl_device.c
@@ -1440,25 +1440,6 @@ static void devices_remove_callback(libxl__egc *egc,
     return;
 }
 
-int libxl__wait_for_device_model_deprecated(libxl__gc *gc,
-                                 uint32_t domid, char *state,
-                                 libxl__spawn_starting *spawning,
-                                 int (*check_callback)(libxl__gc *gc,
-                                                       uint32_t domid,
-                                                       const char *state,
-                                                       void *userdata),
-                                 void *check_callback_userdata)
-{
-    char *path;
-    uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
-
-    path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, "/state");
-    return libxl__xenstore_child_wait_deprecated(gc, domid,
-                                     LIBXL_DEVICE_MODEL_START_TIMEOUT,
-                                     "Device Model", path, state, spawning,
-                                     check_callback, check_callback_userdata);
-}
-
 int libxl__wait_for_backend(libxl__gc *gc, const char *be_path,
                             const char *state)
 {
diff --git a/tools/libs/light/libxl_disk.c b/tools/libs/light/libxl_disk.c
index 6a0b6e06fe..456b5450ca 100644
--- a/tools/libs/light/libxl_disk.c
+++ b/tools/libs/light/libxl_disk.c
@@ -1007,13 +1007,6 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk,
         disk->backend = LIBXL_DISK_BACKEND_PHY;
     }
 
-    if (cis->dm_ver == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
-        stubdomid) {
-        LOGD(ERROR, domid, "cdrom-insert doesn't work for Mini-OS stubdoms");
-        rc = ERROR_INVAL;
-        goto out;
-    }
-
     disks = libxl__device_list(gc, &libxl__disk_devtype, cis->disk_domid, &num);
     for (i = 0; i < num; i++) {
         if (disks[i].is_cdrom && !strcmp(disk->vdev, disks[i].vdev))
diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
index 4627564c0d..511ec76a65 100644
--- a/tools/libs/light/libxl_dm.c
+++ b/tools/libs/light/libxl_dm.c
@@ -328,9 +328,6 @@ const char *libxl__domain_device_model(libxl__gc *gc,
         dm = libxl__strdup(gc, info->device_model);
     } else {
         switch (info->device_model_version) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            dm = libxl__abs_path(gc, "qemu-dm", libxl__private_bindir_path());
-            break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN: {
             const char *configured_dm = qemu_xen_path(gc);
             if (configured_dm[0] == '/')
@@ -704,272 +701,6 @@ static const char *dm_keymap(const libxl_domain_config *guest_config)
         return NULL;
 }
 
-static int libxl__build_device_model_args_old(libxl__gc *gc,
-                                        const char *dm, int domid,
-                                        const libxl_domain_config *guest_config,
-                                        char ***args, char ***envs,
-                                        const libxl__domain_build_state *state)
-{
-    const libxl_domain_create_info *c_info = &guest_config->c_info;
-    const libxl_domain_build_info *b_info = &guest_config->b_info;
-    const libxl_device_nic *nics = guest_config->nics;
-    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
-    const libxl_sdl_info *sdl = dm_sdl(guest_config);
-    const int num_nics = guest_config->num_nics;
-    const char *keymap = dm_keymap(guest_config);
-    int i;
-    flexarray_t *dm_args, *dm_envs;
-    dm_args = flexarray_make(gc, 16, 1);
-    dm_envs = flexarray_make(gc, 16, 1);
-
-    assert(state->dm_monitor_fd == -1);
-
-    flexarray_vappend(dm_args, dm,
-                      "-d", GCSPRINTF("%d", domid), NULL);
-
-    if (c_info->name)
-        flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
-
-    if (vnc) {
-        char *vncarg = NULL;
-
-        flexarray_append(dm_args, "-vnc");
-
-        /*
-         * If vnc->listen is present and contains a :, and
-         *  - vnc->display is 0, use vnc->listen
-         *  - vnc->display is non-zero, be confused
-         * If vnc->listen is present but doesn't, use vnc->listen:vnc->display.
-         * If vnc->listen is not present, use 127.0.0.1:vnc->display
-         * (Remembering that vnc->display already defaults to 0.)
-         */
-        if (vnc->listen) {
-            if (strchr(vnc->listen, ':') != NULL) {
-                if (vnc->display) {
-                    LOGD(ERROR, domid, "vncdisplay set, vnclisten contains display");
-                    return ERROR_INVAL;
-                }
-                vncarg = vnc->listen;
-            } else {
-                vncarg = GCSPRINTF("%s:%d", vnc->listen, vnc->display);
-            }
-        } else
-            vncarg = GCSPRINTF("127.0.0.1:%d", vnc->display);
-
-        if (vnc->passwd && vnc->passwd[0]) {
-            vncarg = GCSPRINTF("%s,password", vncarg);
-        }
-
-        flexarray_append(dm_args, vncarg);
-
-        if (libxl_defbool_val(vnc->findunused)) {
-            flexarray_append(dm_args, "-vncunused");
-        }
-    } else if (!sdl) {
-        /*
-         * VNC is not enabled by default by qemu-xen-traditional,
-         * however skipping -vnc causes SDL to be
-         * (unexpectedly) enabled by default. If undesired, disable graphics at
-         * all.
-         */
-        flexarray_append(dm_args, "-nographic");
-    }
-
-    if (sdl) {
-        flexarray_append(dm_args, "-sdl");
-        if (!libxl_defbool_val(sdl->opengl)) {
-            flexarray_append(dm_args, "-disable-opengl");
-        }
-        if (sdl->display)
-            flexarray_append_pair(dm_envs, "DISPLAY", sdl->display);
-        if (sdl->xauthority)
-            flexarray_append_pair(dm_envs, "XAUTHORITY", sdl->xauthority);
-    }
-    if (keymap) {
-        flexarray_vappend(dm_args, "-k", keymap, NULL);
-    }
-    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        int ioemu_nics = 0;
-        int nr_set_cpus = 0;
-        char *s;
-
-        flexarray_append_pair(dm_envs, "XEN_DOMAIN_ID", GCSPRINTF("%d", domid));
-
-        if (b_info->kernel) {
-            LOGD(ERROR, domid, "HVM direct kernel boot is not supported by "
-                 "qemu-xen-traditional");
-            return ERROR_INVAL;
-        }
-
-        if (b_info->u.hvm.serial || b_info->u.hvm.serial_list) {
-            if ( b_info->u.hvm.serial && b_info->u.hvm.serial_list )
-            {
-                LOGD(ERROR, domid, "Both serial and serial_list set");
-                return ERROR_INVAL;
-            }
-            if (b_info->u.hvm.serial) {
-                flexarray_vappend(dm_args,
-                                  "-serial", b_info->u.hvm.serial, NULL);
-            } else if (b_info->u.hvm.serial_list) {
-                char **p;
-                for (p = b_info->u.hvm.serial_list;
-                     *p;
-                     p++) {
-                    flexarray_vappend(dm_args,
-                                      "-serial",
-                                      *p, NULL);
-                }
-            }
-        }
-
-        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
-            flexarray_append(dm_args, "-nographic");
-        }
-
-        if (b_info->video_memkb) {
-            flexarray_vappend(dm_args, "-videoram",
-                    GCSPRINTF("%d", libxl__sizekb_to_mb(b_info->video_memkb)),
-                    NULL);
-        }
-
-        switch (b_info->u.hvm.vga.kind) {
-        case LIBXL_VGA_INTERFACE_TYPE_STD:
-            flexarray_append(dm_args, "-std-vga");
-            break;
-        case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
-            break;
-        case LIBXL_VGA_INTERFACE_TYPE_NONE:
-            flexarray_append_pair(dm_args, "-vga", "none");
-            break;
-        case LIBXL_VGA_INTERFACE_TYPE_QXL:
-            break;
-        default:
-            LOGD(ERROR, domid, "Invalid emulated video card specified");
-            return ERROR_INVAL;
-        }
-
-        if (b_info->u.hvm.boot) {
-            flexarray_vappend(dm_args, "-boot", b_info->u.hvm.boot, NULL);
-        }
-        if (libxl_defbool_val(b_info->u.hvm.usb)
-            || b_info->u.hvm.usbdevice
-            || libxl_string_list_length(&b_info->u.hvm.usbdevice_list)) {
-            if (b_info->u.hvm.usbdevice
-                && libxl_string_list_length(&b_info->u.hvm.usbdevice_list)) {
-                LOGD(ERROR, domid, "Both usbdevice and usbdevice_list set");
-                return ERROR_INVAL;
-            }
-            flexarray_append(dm_args, "-usb");
-            if (b_info->u.hvm.usbdevice) {
-                flexarray_vappend(dm_args,
-                                  "-usbdevice", b_info->u.hvm.usbdevice, NULL);
-            } else if (b_info->u.hvm.usbdevice_list) {
-                char **p;
-                for (p = b_info->u.hvm.usbdevice_list;
-                     *p;
-                     p++) {
-                    flexarray_vappend(dm_args,
-                                      "-usbdevice",
-                                      *p, NULL);
-                }
-            }
-        }
-        if (b_info->u.hvm.soundhw) {
-            flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
-        }
-        if (libxl__acpi_defbool_val(b_info)) {
-            flexarray_append(dm_args, "-acpi");
-        }
-        if (b_info->max_vcpus > 1) {
-            flexarray_vappend(dm_args, "-vcpus",
-                              GCSPRINTF("%d", b_info->max_vcpus),
-                              NULL);
-        }
-
-        nr_set_cpus = libxl_bitmap_count_set(&b_info->avail_vcpus);
-        s = libxl_bitmap_to_hex_string(CTX, &b_info->avail_vcpus);
-        flexarray_vappend(dm_args, "-vcpu_avail",
-                              GCSPRINTF("%s", s), NULL);
-        free(s);
-
-        for (i = 0; i < num_nics; i++) {
-            if (nics[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU) {
-                char *smac = GCSPRINTF(
-                                   LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nics[i].mac));
-                const char *ifname = libxl__device_nic_devname(gc,
-                                                domid, nics[i].devid,
-                                                LIBXL_NIC_TYPE_VIF_IOEMU);
-                flexarray_vappend(dm_args,
-                                  "-net",
-                                  GCSPRINTF(
-                                      "nic,vlan=%d,macaddr=%s,model=%s",
-                                      nics[i].devid, smac, nics[i].model),
-                                  "-net",
-                                  GCSPRINTF(
-                                      "tap,vlan=%d,ifname=%s,bridge=%s,"
-                                      "script=%s,downscript=%s",
-                                      nics[i].devid, ifname, nics[i].bridge,
-                                      libxl_tapif_script(gc),
-                                      libxl_tapif_script(gc)),
-                                  NULL);
-                ioemu_nics++;
-            }
-        }
-        /* If we have no emulated nics, tell qemu not to create any */
-        if ( ioemu_nics == 0 ) {
-            flexarray_vappend(dm_args, "-net", "none", NULL);
-        }
-        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
-            switch (b_info->u.hvm.gfx_passthru_kind) {
-            case LIBXL_GFX_PASSTHRU_KIND_DEFAULT:
-            case LIBXL_GFX_PASSTHRU_KIND_IGD:
-                flexarray_append(dm_args, "-gfx_passthru");
-                break;
-            default:
-                LOGD(ERROR, domid, "unsupported gfx_passthru_kind.");
-                return ERROR_INVAL;
-            }
-        }
-    } else {
-        if (!sdl && !vnc)
-            flexarray_append(dm_args, "-nographic");
-    }
-
-    if (libxl_defbool_val(b_info->dm_restrict)) {
-        LOGD(ERROR, domid,
-             "dm_restrict not supported by qemu-xen-traditional");
-        return ERROR_INVAL;
-    }
-
-    if (state->saved_state) {
-        flexarray_vappend(dm_args, "-loadvm", state->saved_state, NULL);
-    }
-    for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
-        flexarray_append(dm_args, b_info->extra[i]);
-    flexarray_append(dm_args, "-M");
-    switch (b_info->type) {
-    case LIBXL_DOMAIN_TYPE_PVH:
-    case LIBXL_DOMAIN_TYPE_PV:
-        flexarray_append(dm_args, "xenpv");
-        for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
-            flexarray_append(dm_args, b_info->extra_pv[i]);
-        break;
-    case LIBXL_DOMAIN_TYPE_HVM:
-        flexarray_append(dm_args, "xenfv");
-        for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
-            flexarray_append(dm_args, b_info->extra_hvm[i]);
-        break;
-    default:
-        abort();
-    }
-    flexarray_append(dm_args, NULL);
-    *args = (char **) flexarray_contents(dm_args);
-    flexarray_append(dm_envs, NULL);
-    if (envs)
-        *envs = (char **) flexarray_contents(dm_envs);
-    return 0;
-}
-
 static char *dm_spice_options(libxl__gc *gc,
                                     const libxl_spice_info *spice)
 {
@@ -2096,11 +1827,6 @@ static int libxl__build_device_model_args(libxl__gc *gc,
  * and therefore will be passing a filename rather than a fd. */
 {
     switch (guest_config->b_info.device_model_version) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm,
-                                                  guest_domid, guest_config,
-                                                  args, envs,
-                                                  state);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
         if (!libxl_defbool_val(guest_config->b_info.device_model_stubdomain)) {
             assert(dm_state_fd != NULL);
@@ -2463,16 +2189,15 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
                         "%s",
                         libxl_bios_type_to_string(guest_config->b_info.u.hvm.bios));
     }
-    /* Disable relocating memory to make the MMIO hole larger
-     * unless we're running qemu-traditional and vNUMA is not
-     * configured. */
+
+    /*
+     * Disable relocating memory, having a larger MMIO hole isn't
+     * implemented with qemu-xen.
+     */
     libxl__xs_printf(gc, XBT_NULL,
                      libxl__sprintf(gc, "%s/hvmloader/allow-memory-relocate",
                                     libxl__xs_get_dompath(gc, guest_domid)),
-                     "%d",
-                     guest_config->b_info.device_model_version
-                        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
-                     !libxl__vnuma_configured(&guest_config->b_info));
+                     "0");
     ret = xc_domain_set_target(ctx->xch, dm_domid, guest_domid);
     if (ret<0) {
         LOGED(ERROR, guest_domid, "setting target domain %d -> %d",
@@ -3156,13 +2881,9 @@ static void device_model_launch(libxl__egc *egc,
     libxl_domain_config *guest_config = dmss->guest_config;
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
-    const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     char *path;
     int logfile_w, null;
     char **args, **arg, **envs;
-    xs_transaction_t t;
-    char *vm_path;
-    char **pass_stuff;
     int dm_state_fd = -1;
 
     /* convenience aliases */
@@ -3196,26 +2917,19 @@ static void device_model_launch(libxl__egc *egc,
         libxl__xs_printf(gc, XBT_NULL,
                          GCSPRINTF("%s/hvmloader/bios", path),
                          "%s", libxl_bios_type_to_string(b_info->u.hvm.bios));
-        /* Disable relocating memory to make the MMIO hole larger
-         * unless we're running qemu-traditional and vNUMA is not
-         * configured. */
+        /*
+         * Disable relocating memory, having a larger MMIO hole isn't
+         * implemented with qemu-xen.
+         */
         libxl__xs_printf(gc, XBT_NULL,
                          GCSPRINTF("%s/hvmloader/allow-memory-relocate", path),
-                         "%d",
-                         b_info->device_model_version==LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
-                         !libxl__vnuma_configured(b_info));
+                         "0");
         free(path);
     }
 
     path = DEVICE_MODEL_XS_PATH(gc, LIBXL_TOOLSTACK_DOMID, domid, "");
     xs_mkdir(ctx->xsh, XBT_NULL, path);
 
-    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
-        b_info->device_model_version
-        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL)
-        libxl__xs_printf(gc, XBT_NULL, GCSPRINTF("%s/disable_pf", path),
-                         "%d", !libxl_defbool_val(b_info->u.hvm.xen_platform_pci));
-
     logfile_w = libxl__create_qemu_logfile(gc, GCSPRINTF("qemu-dm-%s",
                                                          c_info->name));
     if (logfile_w < 0) {
@@ -3240,25 +2954,6 @@ static void device_model_launch(libxl__egc *egc,
                          GCSPRINTF("%s/image/device-model-kill-uid", dom_path),
                          "%s", state->dm_kill_uid);
 
-    if (vnc && vnc->passwd) {
-        /* This xenstore key will only be used by qemu-xen-traditionnal.
-         * The code to supply vncpasswd to qemu-xen is later. */
-retry_transaction:
-        /* Find uuid and the write the vnc password to xenstore for qemu. */
-        t = xs_transaction_start(ctx->xsh);
-        vm_path = libxl__xs_read(gc,t,GCSPRINTF("%s/vm", dom_path));
-        if (vm_path) {
-            /* Now write the vncpassword into it. */
-            pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
-            pass_stuff[0] = "vncpasswd";
-            pass_stuff[1] = vnc->passwd;
-            libxl__xs_writev(gc,t,vm_path,pass_stuff);
-            if (!xs_transaction_end(ctx->xsh, t, 0))
-                if (errno == EAGAIN)
-                    goto retry_transaction;
-        }
-    }
-
     LOGD(DEBUG, domid, "Spawning device-model %s with arguments:", dm);
     for (arg = args; *arg; arg++)
         LOGD(DEBUG, domid, "  %s", *arg);
diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
index 94fef37401..4d67b0d282 100644
--- a/tools/libs/light/libxl_dom.c
+++ b/tools/libs/light/libxl_dom.c
@@ -881,7 +881,6 @@ static int libxl__domain_firmware(libxl__gc *gc,
             switch (info->device_model_version)
             {
             case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
                 firmware = "hvmloader";
                 break;
             default:
@@ -1212,15 +1211,6 @@ out:
     return rc;
 }
 
-int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
-                                const char *cmd)
-{
-    char *path = NULL;
-    uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
-    path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, "/command");
-    return libxl__xs_printf(gc, XBT_NULL, path, "%s", cmd);
-}
-
 /*==================== Miscellaneous ====================*/
 
 char *libxl__uuid2string(libxl__gc *gc, const libxl_uuid uuid)
diff --git a/tools/libs/light/libxl_dom_save.c b/tools/libs/light/libxl_dom_save.c
index 32e3cb5a13..d64fd64f2e 100644
--- a/tools/libs/light/libxl_dom_save.c
+++ b/tools/libs/light/libxl_dom_save.c
@@ -28,19 +28,6 @@ static void domain_save_done(libxl__egc *egc,
 
 /*----- complicated callback, called by xc_domain_save -----*/
 
-/*
- * We implement the other end of protocol for controlling qemu-dm's
- * logdirty.  There is no documentation for this protocol, but our
- * counterparty's implementation is in
- * qemu-xen-traditional.git:xenstore.c in the function
- * xenstore_process_logdirty_event
- */
-
-static void domain_suspend_switch_qemu_xen_traditional_logdirty
-                               (libxl__egc *egc, int domid, unsigned enable,
-                                libxl__logdirty_switch *lds);
-static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
-                            const char *watch_path, const char *event_path);
 static void domain_suspend_switch_qemu_xen_logdirty
                                (libxl__egc *egc, int domid, unsigned enable,
                                 libxl__logdirty_switch *lds);
@@ -69,10 +56,6 @@ void libxl__domain_common_switch_qemu_logdirty(libxl__egc *egc,
     STATE_AO_GC(lds->ao);
 
     switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        domain_suspend_switch_qemu_xen_traditional_logdirty(egc, domid, enable,
-                                                            lds);
-        break;
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
         domain_suspend_switch_qemu_xen_logdirty(egc, domid, enable, lds);
         break;
@@ -83,129 +66,6 @@ void libxl__domain_common_switch_qemu_logdirty(libxl__egc *egc,
     }
 }
 
-static void domain_suspend_switch_qemu_xen_traditional_logdirty
-                               (libxl__egc *egc, int domid, unsigned enable,
-                                libxl__logdirty_switch *lds)
-{
-    STATE_AO_GC(lds->ao);
-    int rc;
-    xs_transaction_t t = 0;
-    const char *got;
-
-    if (!lds->cmd_path) {
-        uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
-        lds->cmd_path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid,
-                                             "/logdirty/cmd");
-        lds->ret_path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid,
-                                             "/logdirty/ret");
-    }
-    lds->cmd = enable ? "enable" : "disable";
-
-    rc = libxl__ev_xswatch_register(gc, &lds->watch,
-                                switch_logdirty_xswatch, lds->ret_path);
-    if (rc) goto out;
-
-    rc = libxl__ev_time_register_rel(ao, &lds->timeout,
-                                switch_logdirty_timeout, 10*1000);
-    if (rc) goto out;
-
-    for (;;) {
-        rc = libxl__xs_transaction_start(gc, &t);
-        if (rc) goto out;
-
-        rc = libxl__xs_read_checked(gc, t, lds->cmd_path, &got);
-        if (rc) goto out;
-
-        if (got) {
-            const char *got_ret;
-            rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got_ret);
-            if (rc) goto out;
-
-            if (!got_ret || strcmp(got, got_ret)) {
-                LOGD(ERROR, domid, "controlling logdirty: qemu was already sent"
-                     " command `%s' (xenstore path `%s') but result is `%s'",
-                     got, lds->cmd_path, got_ret ? got_ret : "");
-                rc = ERROR_FAIL;
-                goto out;
-            }
-            rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
-            if (rc) goto out;
-        }
-
-        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
-        if (rc) goto out;
-
-        rc = libxl__xs_write_checked(gc, t, lds->cmd_path, lds->cmd);
-        if (rc) goto out;
-
-        rc = libxl__xs_transaction_commit(gc, &t);
-        if (!rc) break;
-        if (rc<0) goto out;
-    }
-
-    /* OK, wait for some callback */
-    return;
-
- out:
-    LOGD(ERROR, domid, "logdirty switch failed (rc=%d), abandoning suspend",rc);
-    libxl__xs_transaction_abort(gc, &t);
-    switch_logdirty_done(egc,lds,rc);
-}
-
-static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch *watch,
-                            const char *watch_path, const char *event_path)
-{
-    libxl__logdirty_switch *lds = CONTAINER_OF(watch, *lds, watch);
-    STATE_AO_GC(lds->ao);
-    const char *got;
-    xs_transaction_t t = 0;
-    int rc;
-
-    for (;;) {
-        rc = libxl__xs_transaction_start(gc, &t);
-        if (rc) goto out;
-
-        rc = libxl__xs_read_checked(gc, t, lds->ret_path, &got);
-        if (rc) goto out;
-
-        if (!got) {
-            rc = +1;
-            goto out;
-        }
-
-        if (strcmp(got, lds->cmd)) {
-            LOG(ERROR,"logdirty switch: sent command `%s' but got reply `%s'"
-                " (xenstore paths `%s' / `%s')", lds->cmd, got,
-                lds->cmd_path, lds->ret_path);
-            rc = ERROR_FAIL;
-            goto out;
-        }
-
-        rc = libxl__xs_rm_checked(gc, t, lds->cmd_path);
-        if (rc) goto out;
-
-        rc = libxl__xs_rm_checked(gc, t, lds->ret_path);
-        if (rc) goto out;
-
-        rc = libxl__xs_transaction_commit(gc, &t);
-        if (!rc) break;
-        if (rc<0) goto out;
-    }
-
- out:
-    /* rc < 0: error
-     * rc == 0: ok, we are done
-     * rc == +1: need to keep waiting
-     */
-    libxl__xs_transaction_abort(gc, &t);
-
-    if (rc <= 0) {
-        if (rc < 0)
-            LOG(ERROR,"logdirty switch: failed (rc=%d)",rc);
-        switch_logdirty_done(egc,lds,rc);
-    }
-}
-
 static void domain_suspend_switch_qemu_xen_logdirty
                                (libxl__egc *egc, int domid, unsigned enable,
                                 libxl__logdirty_switch *lds)
diff --git a/tools/libs/light/libxl_dom_suspend.c b/tools/libs/light/libxl_dom_suspend.c
index 6091a5f3f6..f0a74fc82c 100644
--- a/tools/libs/light/libxl_dom_suspend.c
+++ b/tools/libs/light/libxl_dom_suspend.c
@@ -85,15 +85,8 @@ void libxl__domain_suspend_device_model(libxl__egc *egc,
     STATE_AO_GC(dsps->ao);
     int rc = 0;
     uint32_t const domid = dsps->domid;
-    const char *const filename = dsps->dm_savefile;
 
     switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        LOGD(DEBUG, domid, "Saving device model state to %s", filename);
-        libxl__qemu_traditional_cmd(gc, domid, "save");
-        libxl__wait_for_device_model_deprecated(gc, domid, "paused", NULL, NULL, NULL);
-        break;
-    }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
         /* calls dsps->callback_device_model_done when done */
         libxl__qmp_suspend_save(egc, dsps); /* must be last */
@@ -420,21 +413,7 @@ static void domain_suspend_callback_common_done(libxl__egc *egc,
 
 int libxl__domain_resume_device_model_deprecated(libxl__gc *gc, uint32_t domid)
 {
-    const char *path, *state;
-
     switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
-
-        path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, "/state");
-        state = libxl__xs_read(gc, XBT_NULL, path);
-        if (state != NULL && !strcmp(state, "paused")) {
-            libxl__qemu_traditional_cmd(gc, domid, "continue");
-            libxl__wait_for_device_model_deprecated(gc, domid, "running",
-                                                    NULL, NULL, NULL);
-        }
-        break;
-    }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
         if (libxl__qmp_resume(gc, domid))
             return ERROR_FAIL;
@@ -493,8 +472,6 @@ static void dm_resume_dispose(libxl__gc *gc,
     libxl__ev_xswatch_deregister(gc, &dmrs->watch);
 }
 
-static void dm_resume_xswatch_cb(libxl__egc *egc,
-    libxl__ev_xswatch *, const char *watch_path, const char *);
 static void dm_resume_qmp_done(libxl__egc *egc,
     libxl__ev_qmp *qmp, const libxl__json_object *, int rc);
 static void dm_resume_timeout(libxl__egc *egc,
@@ -521,27 +498,6 @@ void libxl__dm_resume(libxl__egc *egc,
     if (rc) goto out;
 
     switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
-        const char *path, *state;
-
-        path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, "/state");
-        rc = libxl__xs_read_checked(gc, XBT_NULL, path, &state);
-        if (rc) goto out;
-        if (!state || strcmp(state, "paused")) {
-            /* already running */
-            rc = 0;
-            goto out;
-        }
-
-        rc = libxl__qemu_traditional_cmd(gc, domid, "continue");
-        if (rc) goto out;
-        rc = libxl__ev_xswatch_register(gc, &dmrs->watch,
-                                        dm_resume_xswatch_cb,
-                                        path);
-        if (rc) goto out;
-        break;
-    }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
         qmp->ao = dmrs->ao;
         qmp->domid = domid;
@@ -561,27 +517,6 @@ out:
     dm_resume_done(egc, dmrs, rc);
 }
 
-static void dm_resume_xswatch_cb(libxl__egc *egc,
-                                 libxl__ev_xswatch *xsw,
-                                 const char *watch_path,
-                                 const char *event_path)
-{
-    EGC_GC;
-    libxl__dm_resume_state *dmrs = CONTAINER_OF(xsw, *dmrs, watch);
-    int rc;
-    const char *value;
-
-    rc = libxl__xs_read_checked(gc, XBT_NULL, watch_path, &value);
-    if (rc) goto out;
-
-    if (!value || strcmp(value, "running"))
-        return;
-
-    rc = 0;
-out:
-    dm_resume_done(egc, dmrs, rc);
-}
-
 static void dm_resume_qmp_done(libxl__egc *egc,
                                libxl__ev_qmp *qmp,
                                const libxl__json_object *response,
diff --git a/tools/libs/light/libxl_domain.c b/tools/libs/light/libxl_domain.c
index 6751fc785f..dd2e5e9a19 100644
--- a/tools/libs/light/libxl_domain.c
+++ b/tools/libs/light/libxl_domain.c
@@ -1877,8 +1877,6 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid,
     switch (libxl__domain_type(gc, domid)) {
     case LIBXL_DOMAIN_TYPE_HVM:
         switch (libxl__device_model_version_running(gc, domid)) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
             rc = libxl__ev_time_register_rel(ao, &svos->timeout,
                                              set_vcpuonline_timeout,
@@ -2116,7 +2114,6 @@ static void domain_s3_resume(libxl__ao *ao, libxl__egc *egc, int domid)
     AO_GC;
     libxl__ev_qmp *qmp;
     int rc = 0;
-    int r;
 
     GCNEW(qmp);
     libxl__ev_qmp_init(qmp);
@@ -2128,14 +2125,6 @@ static void domain_s3_resume(libxl__ao *ao, libxl__egc *egc, int domid)
     switch (libxl__domain_type(gc, domid)) {
     case LIBXL_DOMAIN_TYPE_HVM:
         switch (libxl__device_model_version_running(gc, domid)) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            r = xc_hvm_param_set(CTX->xch, domid, HVM_PARAM_ACPI_S_STATE, 0);
-            if (r) {
-                LOGED(ERROR, domid, "Send trigger '%s' failed",
-                      libxl_trigger_to_string(LIBXL_TRIGGER_S3RESUME));
-                rc = ERROR_FAIL;
-            }
-            break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
             rc = libxl__ev_qmp_send(egc, qmp, "system_wakeup", NULL);
             if (rc) goto out;
@@ -2481,10 +2470,6 @@ static void retrieve_domain_configuration_end(libxl__egc *egc,
             case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
                 libxl_bitmap_copy(CTX, map, &rdcs->qemuu_cpus);
                 break;
-            case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-                rc = libxl__update_avail_vcpus_xenstore(gc, domid,
-                                                        max_vcpus, map);
-                break;
             default:
                 abort();
             }
diff --git a/tools/libs/light/libxl_exec.c b/tools/libs/light/libxl_exec.c
index a8b949b193..7a59c050b2 100644
--- a/tools/libs/light/libxl_exec.c
+++ b/tools/libs/light/libxl_exec.c
@@ -157,81 +157,6 @@ out:
     return rc ? SIGTERM : 0;
 }
 
-int libxl__xenstore_child_wait_deprecated(libxl__gc *gc,
-                                 uint32_t domid,
-                                 uint32_t timeout, char *what,
-                                 char *path, char *state,
-                                 libxl__spawn_starting *spawning,
-                                 int (*check_callback)(libxl__gc *gc,
-                                                       uint32_t domid,
-                                                       const char *state,
-                                                       void *userdata),
-                                 void *check_callback_userdata)
-{
-    char *p;
-    unsigned int len;
-    int rc = 0;
-    struct xs_handle *xsh;
-    int nfds;
-    fd_set rfds;
-    struct timeval tv;
-    unsigned int num;
-    char **l = NULL;
-
-    xsh = xs_open(0);
-    if (xsh == NULL) {
-        LOG(ERROR, "Unable to open xenstore connection");
-        goto err;
-    }
-
-    xs_watch(xsh, path, path);
-    tv.tv_sec = timeout;
-    tv.tv_usec = 0;
-    nfds = xs_fileno(xsh) + 1;
-    assert(!spawning);
-
-    while (rc > 0 || (!rc && tv.tv_sec > 0)) {
-        p = xs_read(xsh, XBT_NULL, path, &len);
-        if ( NULL == p )
-            goto again;
-
-        if ( NULL != state && strcmp(p, state) )
-            goto again;
-
-        if ( NULL != check_callback ) {
-            rc = (*check_callback)(gc, domid, p, check_callback_userdata);
-            if ( rc > 0 )
-                goto again;
-        }
-
-        free(p);
-        xs_unwatch(xsh, path, path);
-        xs_close(xsh);
-        return rc;
-again:
-        free(p);
-        FD_ZERO(&rfds);
-        FD_SET(xs_fileno(xsh), &rfds);
-        rc = select(nfds, &rfds, NULL, NULL, &tv);
-        if (rc > 0) {
-            if (FD_ISSET(xs_fileno(xsh), &rfds)) {
-                l = xs_read_watch(xsh, &num);
-                if (l != NULL)
-                    free(l);
-                else
-                    goto again;
-            }
-        }
-    }
-    LOG(ERROR, "%s not ready", what);
-
-    xs_unwatch(xsh, path, path);
-    xs_close(xsh);
-err:
-    return -1;
-}
-
-
 /*----- spawn implementation -----*/
 
 /*
diff --git a/tools/libs/light/libxl_internal.c b/tools/libs/light/libxl_internal.c
index c95624933f..2941ca0bbd 100644
--- a/tools/libs/light/libxl_internal.c
+++ b/tools/libs/light/libxl_internal.c
@@ -387,11 +387,9 @@ int libxl__device_model_version_running(libxl__gc *gc, uint32_t domid)
     path = libxl__xs_libxl_path(gc, domid);
     path = GCSPRINTF("%s/dm-version", path);
     dm_version = libxl__xs_read(gc, XBT_NULL, path);
-    if (!dm_version) {
-        return LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
-    }
 
-    if (libxl_device_model_version_from_string(dm_version, &value) < 0) {
+    if (!dm_version ||
+        libxl_device_model_version_from_string(dm_version, &value) < 0) {
         LOGD(ERROR, domid, "fatal: %s contain a wrong value (%s)", path, dm_version);
         return -1;
     }
diff --git a/tools/libs/light/libxl_internal.h b/tools/libs/light/libxl_internal.h
index 408a771310..75bb0b94cf 100644
--- a/tools/libs/light/libxl_internal.h
+++ b/tools/libs/light/libxl_internal.h
@@ -1423,8 +1423,6 @@ _hidden int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
               libxl_domain_config *d_config,
               libxl__domain_build_state *state);
 
-_hidden int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
-                                        const char *cmd);
 _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
@@ -1914,50 +1912,6 @@ static inline int libxl__spawn_inuse(const libxl__spawn_state *ss)
 _hidden int libxl__spawn_record_pid(libxl__gc*, libxl__spawn_state*,
                                     pid_t innerchild);
 
-/*
- * libxl__xenstore_child_wait_deprecated - Wait for daemonic child IPC
- *
- * This is a NOT function for waiting for ordinary child processes.
- * If you want to run (fork/exec/wait) subprocesses from libxl:
- *  - Make your libxl entrypoint use the ao machinery
- *  - Use libxl__ev_child_fork, and use the callback programming style
- *
- * This function is intended for interprocess communication with a
- * service process.  If the service process does not respond quickly,
- * the whole caller may be blocked.  Therefore this function is
- * deprecated.  This function is currently used only by
- * libxl__wait_for_device_model_deprecated.
- *
- * gc: allocation pool
- * domid: guest to work with
- * timeout: how many seconds to wait for the state to appear
- * what: string describing the spawned process
- * path: path to the state file in xenstore
- * state: expected string to wait for in path (optional)
- * spawning: malloc'd pointer to libxl__spawn_starting (optional)
- * check_callback: (optional)
- * check_callback_userdata: data to pass to the callback function
- *
- * Returns 0 on success, and < 0 on error.
- *
- * This function waits the given timeout for the given path to appear
- * in xenstore, and optionally for state in path.
- * If path appears and state matches, check_callback is called.
- * If check_callback returns > 0, waiting for path or state continues.
- * Otherwise libxl__xenstore_child_wait_deprecated returns.
- */
-_hidden int libxl__xenstore_child_wait_deprecated(libxl__gc *gc,
-                                 uint32_t domid,
-                                 uint32_t timeout, char *what,
-                                 char *path, char *state,
-                                 libxl__spawn_starting *spawning,
-                                 int (*check_callback)(libxl__gc *gc,
-                                                       uint32_t domid,
-                                                       const char *state,
-                                                       void *userdata),
-                                 void *check_callback_userdata);
-
-
  /* low-level stuff, for synchronous subprocesses etc. */
 
 /*
@@ -2022,25 +1976,6 @@ _hidden int libxl__domain_device_construct_rdm(libxl__gc *gc,
                                    uint64_t rdm_mem_guard,
                                    struct xc_dom_image *dom);
 
-/*
- * This function will cause the whole libxl process to hang
- * if the device model does not respond.  It is deprecated.
- *
- * Instead of calling this function:
- *  - Make your libxl entrypoint use the ao machinery
- *  - Use libxl__ev_xswatch_register, and use the callback programming
- *    style
- */
-_hidden int libxl__wait_for_device_model_deprecated(libxl__gc *gc,
-                                uint32_t domid, char *state,
-                                libxl__spawn_starting *spawning
-                                                    /* NULL allowed */,
-                                int (*check_callback)(libxl__gc *gc,
-                                                      uint32_t domid,
-                                                      const char *state,
-                                                      void *userdata),
-                                void *check_callback_userdata);
-
 _hidden const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *g_cfg);
 
 _hidden char *libxl__abs_path(libxl__gc *gc, const char *s, const char *path);
@@ -2315,8 +2250,7 @@ _hidden char *libxl__json_object_to_json(libxl__gc *gc,
 #define JSON(o) \
     (libxl__json_object_to_json(gc, (o)) ? : "")
 
-  /* Based on /local/domain/$domid/dm-version xenstore key
-   * default is qemu xen traditional */
+  /* Based on /local/domain/$domid/dm-version xenstore key */
 _hidden int libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 static inline
diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
index a8460fb3ec..2ea2caeb66 100644
--- a/tools/libs/light/libxl_pci.c
+++ b/tools/libs/light/libxl_pci.c
@@ -1023,82 +1023,6 @@ static int pci_multifunction_check(libxl__gc *gc, libxl_device_pci *pci, unsigne
     return 0;
 }
 
-static int pci_ins_check(libxl__gc *gc, uint32_t domid, const char *state, void *priv)
-{
-    char *orig_state = priv;
-
-    if ( !strcmp(state, "pci-insert-failed") )
-        return -1;
-    if ( !strcmp(state, "pci-inserted") )
-        return 0;
-    if ( !strcmp(state, orig_state) )
-        return 1;
-
-    return 1;
-}
-
-static int qemu_pci_add_xenstore(libxl__gc *gc, uint32_t domid,
-                                 libxl_device_pci *pci)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    int rc = 0;
-    char *path;
-    char *state, *vdevfn;
-    uint32_t dm_domid;
-
-    dm_domid = libxl_get_stubdom_id(CTX, domid);
-    path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, "/state");
-    state = libxl__xs_read(gc, XBT_NULL, path);
-    path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, "/parameter");
-    if (pci->vdevfn) {
-        libxl__xs_printf(gc, XBT_NULL, path, PCI_BDF_VDEVFN","PCI_OPTIONS,
-                         pci->domain, pci->bus, pci->dev,
-                         pci->func, pci->vdevfn, pci->msitranslate,
-                         pci->power_mgmt);
-    } else {
-        libxl__xs_printf(gc, XBT_NULL, path, PCI_BDF","PCI_OPTIONS,
-                         pci->domain,  pci->bus, pci->dev,
-                         pci->func, pci->msitranslate, pci->power_mgmt);
-    }
-
-    libxl__qemu_traditional_cmd(gc, domid, "pci-ins");
-    rc = libxl__wait_for_device_model_deprecated(gc, domid, NULL, NULL,
-                                      pci_ins_check, state);
-    path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, "/parameter");
-    vdevfn = libxl__xs_read(gc, XBT_NULL, path);
-    path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, "/state");
-    if ( rc < 0 )
-        LOGD(ERROR, domid, "qemu refused to add device: %s", vdevfn);
-    else if ( sscanf(vdevfn, "0x%x", &pci->vdevfn) != 1 ) {
-        LOGD(ERROR, domid, "wrong format for the vdevfn: '%s'", vdevfn);
-        rc = -1;
-    }
-    xs_write(ctx->xsh, XBT_NULL, path, state, strlen(state));
-
-    return rc;
-}
-
-static int check_qemu_running(libxl__gc *gc,
-                              libxl_domid domid,
-                              libxl__xswait_state *xswa,
-                              int rc,
-                              const char *state)
-{
-    if (rc) {
-        if (rc == ERROR_TIMEDOUT) {
-            LOGD(ERROR, domid, "%s not ready", xswa->what);
-        }
-        goto out;
-    }
-
-    if (!state || strcmp(state, "running"))
-        return ERROR_NOT_READY;
-
-out:
-    libxl__xswait_stop(gc, xswa);
-    return rc;
-}
-
 typedef struct pci_add_state {
     /* filled by user of do_pci_add */
     libxl__ao_device *aodev;
@@ -1119,8 +1043,6 @@ typedef struct pci_add_state {
     int retries;
 } pci_add_state;
 
-static void pci_add_qemu_trad_watch_state_cb(libxl__egc *egc,
-    libxl__xswait_state *xswa, int rc, const char *state);
 static void pci_add_qmp_device_add(libxl__egc *, pci_add_state *);
 static void pci_add_qmp_device_add_cb(libxl__egc *,
     libxl__ev_qmp *, const libxl__json_object *, int rc);
@@ -1156,16 +1078,6 @@ static void do_pci_add(libxl__egc *egc,
 
     if (type == LIBXL_DOMAIN_TYPE_HVM) {
         switch (libxl__device_model_version_running(gc, domid)) {
-            case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-                pas->xswait.ao = ao;
-                pas->xswait.what = "Device Model";
-                pas->xswait.path = DEVICE_MODEL_XS_PATH(gc,
-                    libxl_get_stubdom_id(CTX, domid), domid, "/state");
-                pas->xswait.timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
-                pas->xswait.callback = pci_add_qemu_trad_watch_state_cb;
-                rc = libxl__xswait_start(gc, &pas->xswait);
-                if (rc) goto out;
-                return;
             case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
                 rc = libxl__ev_time_register_rel(ao, &pas->timeout,
                                                  pci_add_timeout,
@@ -1186,29 +1098,6 @@ out:
     pci_add_dm_done(egc, pas, rc); /* must be last */
 }
 
-static void pci_add_qemu_trad_watch_state_cb(libxl__egc *egc,
-                                             libxl__xswait_state *xswa,
-                                             int rc,
-                                             const char *state)
-{
-    pci_add_state *pas = CONTAINER_OF(xswa, *pas, xswait);
-    STATE_AO_GC(pas->aodev->ao);
-
-    /* Convenience aliases */
-    libxl_domid domid = pas->domid;
-    libxl_device_pci *pci = &pas->pci;
-
-    rc = check_qemu_running(gc, domid, xswa, rc, state);
-    if (rc == ERROR_NOT_READY)
-        return;
-    if (rc)
-        goto out;
-
-    rc = qemu_pci_add_xenstore(gc, domid, pci);
-out:
-    pci_add_dm_done(egc, pas, rc); /* must be last */
-}
-
 static void pci_add_qmp_device_add(libxl__egc *egc, pci_add_state *pas)
 {
     STATE_AO_GC(pas->aodev->ao);
@@ -1882,42 +1771,6 @@ static void add_pcis_done(libxl__egc *egc, libxl__multidev *multidev,
     aodev->callback(egc, aodev);
 }
 
-static int qemu_pci_remove_xenstore(libxl__gc *gc, uint32_t domid,
-                                    libxl_device_pci *pci, int force)
-{
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-    char *state;
-    char *path;
-    uint32_t dm_domid;
-
-    dm_domid = libxl_get_stubdom_id(CTX, domid);
-
-    path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, "/state");
-    state = libxl__xs_read(gc, XBT_NULL, path);
-    path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, "/parameter");
-    libxl__xs_printf(gc, XBT_NULL, path, PCI_BDF, pci->domain,
-                     pci->bus, pci->dev, pci->func);
-
-    /* Remove all functions at once atomically by only signalling
-     * device-model for function 0 */
-    if ( !force && (pci->vdevfn & 0x7) == 0 ) {
-        libxl__qemu_traditional_cmd(gc, domid, "pci-rem");
-        if (libxl__wait_for_device_model_deprecated(gc, domid, "pci-removed",
-                                         NULL, NULL, NULL) < 0) {
-            LOGD(ERROR, domid, "Device Model didn't respond in time");
-            /* This depends on guest operating system acknowledging the
-             * SCI, if it doesn't respond in time then we may wish to
-             * force the removal.
-             */
-            return ERROR_FAIL;
-        }
-    }
-    path = DEVICE_MODEL_XS_PATH(gc, dm_domid, domid, "/state");
-    xs_write(ctx->xsh, XBT_NULL, path, state, strlen(state));
-
-    return 0;
-}
-
 typedef struct pci_remove_state {
     libxl__ao_device *aodev;
     libxl_domid domid;
@@ -1940,8 +1793,6 @@ static void libxl__device_pci_remove_common(libxl__egc *egc,
 static void device_pci_remove_common_next(libxl__egc *egc,
     pci_remove_state *prs, int rc);
 
-static void pci_remove_qemu_trad_watch_state_cb(libxl__egc *egc,
-    libxl__xswait_state *xswa, int rc, const char *state);
 static void pci_remove_qmp_device_del(libxl__egc *egc,
     pci_remove_state *prs);
 static void pci_remove_qmp_device_del_cb(libxl__egc *egc,
@@ -1987,16 +1838,6 @@ static void do_pci_remove(libxl__egc *egc, pci_remove_state *prs)
     if (type == LIBXL_DOMAIN_TYPE_HVM) {
         prs->hvm = true;
         switch (libxl__device_model_version_running(gc, domid)) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            prs->xswait.ao = ao;
-            prs->xswait.what = "Device Model";
-            prs->xswait.path = DEVICE_MODEL_XS_PATH(gc,
-                libxl_get_stubdom_id(CTX, domid), domid, "/state");
-            prs->xswait.timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
-            prs->xswait.callback = pci_remove_qemu_trad_watch_state_cb;
-            rc = libxl__xswait_start(gc, &prs->xswait);
-            if (rc) goto out_fail;
-            return;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
             pci_remove_qmp_device_del(egc, prs); /* must be last */
             return;
@@ -2010,30 +1851,6 @@ out_fail:
     pci_remove_detached(egc, prs, rc); /* must be last */
 }
 
-static void pci_remove_qemu_trad_watch_state_cb(libxl__egc *egc,
-                                                libxl__xswait_state *xswa,
-                                                int rc,
-                                                const char *state)
-{
-    pci_remove_state *prs = CONTAINER_OF(xswa, *prs, xswait);
-    STATE_AO_GC(prs->aodev->ao);
-
-    /* Convenience aliases */
-    libxl_domid domid = prs->domid;
-    libxl_device_pci *const pci = &prs->pci;
-
-    rc = check_qemu_running(gc, domid, xswa, rc, state);
-    if (rc == ERROR_NOT_READY)
-        return;
-    if (rc)
-        goto out;
-
-    rc = qemu_pci_remove_xenstore(gc, domid, pci, prs->force);
-
-out:
-    pci_remove_detached(egc, prs, rc);
-}
-
 static void pci_remove_qmp_device_del(libxl__egc *egc,
                                       pci_remove_state *prs)
 {
diff --git a/tools/libs/light/libxl_sr_stream_format.h b/tools/libs/light/libxl_sr_stream_format.h
index 75f5190886..f8f4723c2e 100644
--- a/tools/libs/light/libxl_sr_stream_format.h
+++ b/tools/libs/light/libxl_sr_stream_format.h
@@ -45,7 +45,7 @@ typedef struct libxl__sr_emulator_hdr
 } libxl__sr_emulator_hdr;
 
 #define EMULATOR_UNKNOWN             0x00000000U
-#define EMULATOR_QEMU_TRADITIONAL    0x00000001U
+#define EMULATOR_QEMU_TRADITIONAL    0x00000001U /* Dropped in Xen 4.21 */
 #define EMULATOR_QEMU_UPSTREAM       0x00000002U
 
 typedef struct libxl_sr_checkpoint_state
diff --git a/tools/libs/light/libxl_stream_write.c b/tools/libs/light/libxl_stream_write.c
index 634f3240d1..98d44597a7 100644
--- a/tools/libs/light/libxl_stream_write.c
+++ b/tools/libs/light/libxl_stream_write.c
@@ -252,10 +252,6 @@ void libxl__stream_write_start(libxl__egc *egc,
         stream->device_model_version =
             libxl__device_model_version_running(gc, dss->domid);
         switch (stream->device_model_version) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            stream->emu_sub_hdr.id = EMULATOR_QEMU_TRADITIONAL;
-            break;
-
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
             stream->emu_sub_hdr.id = EMULATOR_QEMU_UPSTREAM;
             break;
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 9bb2969931..1985153830 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -104,7 +104,7 @@ libxl_channel_connection = Enumeration("channel_connection", [
 
 libxl_device_model_version = Enumeration("device_model_version", [
     (0, "UNKNOWN"),
-    (1, "QEMU_XEN_TRADITIONAL"), # Historical qemu-xen device model (qemu-dm)
+    (1, "QEMU_XEN_TRADITIONAL"), # Historical dm (qemu-dm, no longer supported)
     (2, "QEMU_XEN"),             # Upstream based qemu-xen device model
     ])
 
diff --git a/tools/python/xen/migration/libxl.py b/tools/python/xen/migration/libxl.py
index 5dcb50fe02..dc5c7ac355 100644
--- a/tools/python/xen/migration/libxl.py
+++ b/tools/python/xen/migration/libxl.py
@@ -51,12 +51,10 @@ rec_type_to_str = {
 EMULATOR_HEADER_FORMAT = "II"
 
 EMULATOR_ID_unknown       = 0x00000000
-EMULATOR_ID_qemu_trad     = 0x00000001
 EMULATOR_ID_qemu_upstream = 0x00000002
 
 emulator_id_to_str = {
     EMULATOR_ID_unknown       : "Unknown",
-    EMULATOR_ID_qemu_trad     : "Qemu Traditional",
     EMULATOR_ID_qemu_upstream : "Qemu Upstream",
 }
 
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 089a88935a..219e924779 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2733,10 +2733,7 @@ skip_usbdev:
     xlu_cfg_replace_string (config, "device_model_override",
                             &b_info->device_model, 0);
     if (!xlu_cfg_get_string (config, "device_model_version", &buf, 0)) {
-        if (!strcmp(buf, "qemu-xen-traditional")) {
-            b_info->device_model_version
-                = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
-        } else if (!strcmp(buf, "qemu-xen")) {
+        if (!strcmp(buf, "qemu-xen")) {
             b_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
         } else {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 13:21:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 13:21:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998399.1379153 (Exim 4.92)
	(envelope-from )
	id 1uJuEm-0003XP-96; Tue, 27 May 2025 13:21:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998399.1379153; Tue, 27 May 2025 13:21: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 1uJuEm-0003XI-6B; Tue, 27 May 2025 13:21:00 +0000
Received: by outflank-mailman (input) for mailman id 998399;
 Tue, 27 May 2025 13:20:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uJuEk-0002tx-7w
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 13:20:58 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6bd9a9e7-3afd-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 15:20:56 +0200 (CEST)
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 DD4CC1FCF7;
 Tue, 27 May 2025 13:20:55 +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 76D8F1388B;
 Tue, 27 May 2025 13:20:55 +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 o195Gze8NWjFKAAAD6G6ig
 (envelope-from ); Tue, 27 May 2025 13:20:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6bd9a9e7-3afd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748352056; 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=x/nT5CRSPMWdLHDeMl5yNjZHr/rQcrajQHBAXAslVsI=;
	b=Q02RXOQoaOxvIEkjVyV0qLWzCcAvIH07p5TCoWKM+cS2vrez/gx2KcVF8Ma6OzoukuSMxt
	8cpE9nKIDPasrHlV42cA0PHdaLM52W9bGTh2raSXXqBhtqyEKPtdMt5v3xY+0jdNOGlRtz
	C16hm9/cq8okgyhlt9ZmOYwQMrvU5R0=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748352055; 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=x/nT5CRSPMWdLHDeMl5yNjZHr/rQcrajQHBAXAslVsI=;
	b=pGJiOyQBTXExoWvfCnKJz4LV2NPWc4u47wXYSV44EzW6EWKCBp6UZBcauHR4WExnNTVSVG
	G2GqOmq7RO0PhAUNqzuvG3/1JltKZ0+7e3GrTb5TyBxpZWVbrDbsb+jCbif/hfSJxLhlH1
	9FiUzHz7EVc5aKHr0dC2mEv3Yl55HjU=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Oleksii Kurochko ,
	Community Manager ,
	Samuel Thibault 
Subject: [PATCH v4 3/4] tools: remove qemu-traditional
Date: Tue, 27 May 2025 15:20:32 +0200
Message-ID: <20250527132035.985-4-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250527132035.985-1-jgross@suse.com>
References: <20250527132035.985-1-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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];
	TAGGED_RCPT(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[12];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[suse.com,citrix.com,vates.tech,amd.com,xen.org,kernel.org,gmail.com,xenproject.org,ens-lyon.org];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo]
X-Spam-Flag: NO
X-Spam-Score: -1.80
X-Spam-Level: 

Remove qemu traditional from the tree.

Signed-off-by: Juergen Gross 
Acked-by: Oleksii Kurochko  # CHANGELOG.md
Reviewed-by: Anthony PERARD 
---
V3:
- remove another ioemu reference in INSTALL (Anthony Perard)
- remove generating stubdompath.sh and related makefile helpers
  (Anthony Perard)
---
 .gitignore                                    |  3 -
 CHANGELOG.md                                  |  2 +
 Config.mk                                     | 38 --------
 INSTALL                                       | 13 ---
 MAINTAINERS                                   |  4 -
 README                                        |  2 +-
 SUPPORT.md                                    | 16 ---
 config/Paths.mk.in                            |  3 +-
 config/Tools.mk.in                            |  1 -
 docs/process/branching-checklist.txt          |  1 -
 docs/process/release-technician-checklist.txt |  1 -
 stubdom/.gitignore                            |  3 -
 stubdom/Makefile                              | 97 ++-----------------
 stubdom/configure                             | 89 -----------------
 stubdom/configure.ac                          | 15 ---
 stubdom/ioemu-minios.cfg                      |  6 --
 tools/Makefile                                | 58 -----------
 tools/Rules.mk                                |  3 -
 tools/config.h.in                             |  3 -
 tools/configure                               | 42 +-------
 tools/configure.ac                            | 21 +---
 21 files changed, 16 insertions(+), 405 deletions(-)
 delete mode 100644 stubdom/ioemu-minios.cfg

diff --git a/.gitignore b/.gitignore
index 53f5df0003..ccc0bebee6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -255,9 +255,6 @@ LibVNCServer*
 tools/qemu-xen-dir-remote
 tools/qemu-xen-dir
 
-tools/qemu-xen-traditional-dir-remote
-tools/qemu-xen-traditional-dir
-
 tools/firmware/seabios-dir-remote
 tools/firmware/seabios-dir
 
diff --git a/CHANGELOG.md b/CHANGELOG.md
index ec452027f5..1ee2f42e74 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -32,6 +32,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - GNTTABOP_cache_flush: it's unused on x86 and the implementation is
      broken.
 
+ - Support of qemu-traditional has been removed.
+
 ## [4.20.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.20.0) - 2025-03-05
 
 ### Changed
diff --git a/Config.mk b/Config.mk
index 8be7733d9e..3ebc9ac125 100644
--- a/Config.mk
+++ b/Config.mk
@@ -165,20 +165,6 @@ define move-if-changed
 	if ! cmp -s $(1) $(2); then mv -f $(1) $(2); else rm -f $(1); fi
 endef
 
-BUILD_MAKE_VARS := sbindir bindir LIBEXEC LIBEXEC_BIN libdir SHAREDIR \
-                   XENFIRMWAREDIR XEN_CONFIG_DIR XEN_SCRIPT_DIR XEN_LOCK_DIR \
-                   XEN_RUN_DIR XEN_PAGING_DIR XEN_DUMP_DIR XEN_LOG_DIR \
-                   XEN_LIB_DIR XEN_RUN_STORED
-
-buildmakevars2file = $(eval $(call buildmakevars2file-closure,$(1)))
-define buildmakevars2file-closure
-    $(1): .phony
-	rm -f $(1).tmp; \
-	$(foreach var, $(BUILD_MAKE_VARS), \
-	          echo "$(var)=\"$($(var))\"" >>$(1).tmp;) \
-	$(call move-if-changed,$(1).tmp,$(1))
-endef
-
 CFLAGS += -fno-strict-aliasing
 
 CFLAGS += -std=gnu99
@@ -208,22 +194,12 @@ XEN_EXTFILES_URL ?= https://xenbits.xen.org/xen-extfiles
 
 # Where to look for inlined subtrees (for example, from a tarball)
 QEMU_UPSTREAM_INTREE ?= $(XEN_ROOT)/tools/qemu-xen
-QEMU_TRADITIONAL_INTREE ?= $(XEN_ROOT)/tools/qemu-xen-traditional
 
 
 # Handle legacy options
 ifneq (,$(SEABIOS_UPSTREAM_TAG))
 SEABIOS_UPSTREAM_REVISION ?= $(SEABIOS_UPSTREAM_TAG)
 endif
-ifneq (,$(QEMU_REMOTE))
-QEMU_TRADITIONAL_URL ?= $(QEMU_REMOTE)
-endif
-ifneq (,$(CONFIG_QEMU))
-QEMU_TRADITIONAL_LOC ?= $(CONFIG_QEMU)
-endif
-ifneq (,$(QEMU_TAG))
-QEMU_TRADITIONAL_REVISION ?= $(QEMU_TAG)
-endif
 
 OVMF_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/ovmf.git
 OVMF_UPSTREAM_REVISION ?= ba91d0292e593df8528b66f99c1b0b14fadc8e16
@@ -239,20 +215,6 @@ SEABIOS_UPSTREAM_REVISION ?= rel-1.16.3
 
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
-
-QEMU_TRADITIONAL_URL ?= https://xenbits.xen.org/git-http/qemu-xen-traditional.git
-QEMU_TRADITIONAL_REVISION ?= 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764
-# Wed Jul 15 10:01:40 2020 +0100
-# qemu-trad: remove Xen path dependencies
-
-# Specify which qemu-dm to use. This may be `ioemu' to use the old
-# Mercurial in-tree version, or a local directory, or a git URL.
-# QEMU_UPSTREAM_LOC ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
-
-# Defaults for subtree locations
-QEMU_TRADITIONAL_LOC ?= $(call or,$(wildcard $(QEMU_TRADITIONAL_INTREE)),\
-                                  $(QEMU_TRADITIONAL_URL))
-
 QEMU_UPSTREAM_LOC ?= $(call or,$(wildcard $(QEMU_UPSTREAM_INTREE)),\
                                $(QEMU_UPSTREAM_URL))
 
diff --git a/INSTALL b/INSTALL
index 88c1464816..eadf108aa5 100644
--- a/INSTALL
+++ b/INSTALL
@@ -113,15 +113,6 @@ Build a private copy of SeaBIOS.
 Use the given SeaBIOS binary instead of compiling a private copy.
   --with-system-seabios=PATH
 
-Build the old qemu used by xm/xend. This is required if existing domUs
-should be migrated to this host, or if existing domU snapshots should be
-started with this version of the tools. Only if all domUs used the new
-upstream qemu during initial start it is safe to disable this option.
-The old qemu requires rombios, which can be disable along with
-qemu-traditional.
-  --enable-qemu-traditional
-  --enable-rombios
-
 The libxl toolstack uses the upstream qemu per default. A private copy
 will be built. If desired this private copy can be configured with
 additional options passed to its configure script.
@@ -161,7 +152,6 @@ this detection and the sysv runlevel scripts have to be used.
 
 Build various stubom components, some are only example code. Its usually
 enough to specify just --enable-stubdom and leave these options alone.
-  --enable-ioemu-stubdom
   --enable-c-stubdom
   --disable-pv-grub
   --disable-xenstore-stubdom
@@ -245,7 +235,6 @@ locations.
 XEN_EXTFILES_URL=
 OVMF_UPSTREAM_URL=
 QEMU_UPSTREAM_URL=
-QEMU_TRADITIONAL_URL=
 SEABIOS_UPSTREAM_URL=
 MINIOS_UPSTREAM_URL=
 
@@ -253,7 +242,6 @@ Using additional CFLAGS to build tools which will run in dom0 is
 required when building distro packages. These variables can be used to
 pass RPM_OPT_FLAGS.
 EXTRA_CFLAGS_XEN_TOOLS=
-EXTRA_CFLAGS_QEMU_TRADITIONAL=
 EXTRA_CFLAGS_QEMU_XEN=
 
 Additional CFLAGS may be supplied to the build of the hypervisor by
@@ -340,7 +328,6 @@ sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi
 export WGET=$(type -P false)
 export GIT=$(type -P false)
 export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
-export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
 export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
 %configure \
         --with-initddir=%{_initddir}
diff --git a/MAINTAINERS b/MAINTAINERS
index c11b82eca9..7d1b3b8641 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -466,10 +466,6 @@ M:	Marek Marczykowski-Górecki 
 S:	Supported
 F:	tools/python
 
-QEMU-DM
-S:	Supported
-T:	git https://xenbits.xenproject.org/git-http/qemu-xen-traditional.git
-
 QEMU UPSTREAM
 M:	Stefano Stabellini 
 M:	Anthony Perard 
diff --git a/README b/README
index be90be3910..6ee58f7b35 100644
--- a/README
+++ b/README
@@ -80,7 +80,7 @@ disabled at compile time:
       libnl-3-dev, etc).  Required if network buffering is desired
       when using Remus with libxl.  See docs/README.remus for detailed
       information.
-    * 16-bit x86 assembler, loader and compiler for qemu-traditional / rombios
+    * 16-bit x86 assembler, loader and compiler for rombios
       (dev86 rpm or bin86 & bcc debs)
     * Development install of liblzma for rombios
     * Development install of libbz2, liblzma, liblzo2, and libzstd for DomU
diff --git a/SUPPORT.md b/SUPPORT.md
index e8fd0c251e..5eecf1dcbc 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -998,21 +998,6 @@ See the section **Blkback** for image formats supported by QEMU.
 
     Status: Supported, not security supported
 
-### qemu-xen-traditional ###
-
-The Xen Project provides an old version of qemu with modifications
-which enable use as a device model stub domain.  The old version is
-normally selected by default only in a stub dm configuration, but it
-can be requested explicitly in other configurations, for example in
-`xl` with `device_model_version="QEMU_XEN_TRADITIONAL"`.
-
-    Status, Device Model Stub Domains: Supported, with caveats
-    Status, as host process device model: No security support, not recommended
-
-qemu-xen-traditional is security supported only for those available
-devices which are supported for mainstream QEMU (see above), with
-trusted driver domains (see Device Model Stub Domains).
-
 ## Virtual Firmware
 
 ### x86/HVM iPXE
@@ -1031,7 +1016,6 @@ as the guest itself.
 Booting a guest via guest BIOS firmware
 
     Status, SeaBIOS (qemu-xen): Supported
-    Status, ROMBIOS (qemu-xen-traditional): Supported
 
 ### x86/HVM OVMF
 
diff --git a/config/Paths.mk.in b/config/Paths.mk.in
index 38b1bb6b1f..bc42748b7a 100644
--- a/config/Paths.mk.in
+++ b/config/Paths.mk.in
@@ -5,8 +5,7 @@
 # because of this these variables are defined on one master input source file
 # and is generated after running ./configure. The master source is located
 # on the xen source tree at under config/Paths.mk.in and it is used to
-# generate shell or header files by the build system upon demand through the
-# use of the helper makefile helper buildmakevars2file().
+# generate shell or header files by the build system upon demand.
 #
 # For more documentation you can refer to the wiki:
 #
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 37c071961e..463ab75965 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -43,7 +43,6 @@ CONFIG_OVMF         := @ovmf@
 CONFIG_ROMBIOS      := @rombios@
 CONFIG_SEABIOS      := @seabios@
 CONFIG_IPXE         := @ipxe@
-CONFIG_QEMU_TRAD    := @qemu_traditional@
 CONFIG_QEMU_XEN     := @qemu_xen@
 CONFIG_QEMUU_EXTRA_ARGS:= @EXTRA_QEMUU_CONFIGURE_ARGS@
 CONFIG_LIBNL        := @libnl@
diff --git a/docs/process/branching-checklist.txt b/docs/process/branching-checklist.txt
index aa7a27eed5..9632888a56 100644
--- a/docs/process/branching-checklist.txt
+++ b/docs/process/branching-checklist.txt
@@ -71,7 +71,6 @@ ov=4.0
 Ensure references to qemu trees and Mini-OS in xen.git's Config.mk are updated.
 The variables and there content should be:
   * QEMU_UPSTREAM_REVISION: qemu-xen-X.Y.0
-  * QEMU_TRADITIONAL_REVISION: xen-X.Y.0
   * MINIOS_UPSTREAM_REVISION: xen-RELEASE-X.Y.0
 Where X.Y is the release version (e.g. 4.17).
 
diff --git a/docs/process/release-technician-checklist.txt b/docs/process/release-technician-checklist.txt
index 829e8ec47b..64ed9fd5b2 100644
--- a/docs/process/release-technician-checklist.txt
+++ b/docs/process/release-technician-checklist.txt
@@ -56,7 +56,6 @@ t=RELEASE-$r
 
 * change xen-unstable Config.mk
 #   QEMU_UPSTREAM_REVISION,
-#   QEMU_TRADITIONAL_REVISION
 #   MINIOS_UPSTREAM_REVISION
 #     (drop any references to the specific commits, e.g. date or title)
 * change SUPPORT.md heading version number; -unstable or -rc tag
diff --git a/stubdom/.gitignore b/stubdom/.gitignore
index 23350446b9..1b69656d45 100644
--- a/stubdom/.gitignore
+++ b/stubdom/.gitignore
@@ -11,8 +11,6 @@
 /gmp-*
 /grub-*
 /include
-/ioemu
-/ioemu/
 /libs-*
 /libxencall-*
 /libxenevtchn-*
@@ -29,7 +27,6 @@
 /pciutils-*
 /pkg-config/*
 /polarssl-*
-/stubdompath.sh
 /tpm_emulator-*
 /vtpm/vtpm_manager.h
 /xenstore
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 724ce40365..666c3221dc 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -7,7 +7,6 @@ export PKG_CONFIG_DIR = $(CURDIR)/pkg-config
 
 # Remove flags which are meant for tools, e.g. "-m64"
 export EXTRA_CFLAGS_XEN_TOOLS=
-export EXTRA_CFLAGS_QEMU_TRADITIONAL=
 
 export stubdom=y
 export debug=y
@@ -71,16 +70,12 @@ TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
 TARGETS=$(STUBDOM_TARGETS)
 
-STUBDOMPATH="stubdompath.sh"
-genpath-target = $(call buildmakevars2file,$(STUBDOMPATH))
-$(eval $(genpath-target))
-
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: $(STUBDOMPATH) $(STUBDOM_BUILD)
+build: $(STUBDOM_BUILD)
 else
-build: $(STUBDOMPATH)
+build:
 endif
 
 ##############
@@ -267,43 +262,6 @@ cross-tpmemu: $(TPMEMU_STAMPFILE)
 .PHONY: $(CROSS_ROOT)
 $(CROSS_ROOT): cross-newlib cross-zlib cross-libpci
 
-QEMU_ROOT := $(shell if [ -d "$(QEMU_TRADITIONAL_LOC)" ]; then echo "$(QEMU_TRADITIONAL_LOC)"; else echo .; fi)
-
-ifneq ($(filter ioemu,$(STUBDOM_TARGETS)),)
-IOEMU_LINKFARM_TARGET := ioemu/linkfarm.stamp
-endif
-
-ifeq ($(QEMU_ROOT),.)
-$(XEN_ROOT)/tools/qemu-xen-traditional-dir:
-	$(MAKE) DESTDIR= -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find
-
-ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir
-	mkdir -p ioemu
-	set -e;									\
-	$(buildmakevars2shellvars);						\
-	cd ioemu;								\
-	src="$$XEN_ROOT/tools/qemu-xen-traditional-dir"; export src;		\
-	(cd $$src && find * -type d						\
-		$(addprefix ! -path , '*-softmmu*' '*-linux-user*') -print)	\
-		| xargs mkdir -p;						\
-	(cd $$src && find *	! -type l  -type f  $(addprefix ! -path ,	\
-			'*.[oda1]' 'config-*' config.mak qemu-dm qemu-img-xen	\
-			'*.html' '*.pod' '*-softmmu*' '*-linux-user*'		\
-			)) >linkfarm.stamp.tmp;				\
-	cmp -s linkfarm.stamp.tmp linkfarm.stamp &&			\
-		rm linkfarm.stamp.tmp || {				\
-		mv linkfarm.stamp.tmp linkfarm.stamp;			\
-		cat linkfarm.stamp | while read f;			\
-			do rm -f "$$f"; ln -s "$$src/$$f" "$$f"; done;	\
-	}
-else
-export QEMU_ROOT
-
-ioemu/linkfarm.stamp:
-	mkdir -p ioemu
-	touch ioemu/linkfarm.stamp
-endif
-
 #######
 # libraries under tools/libs
 #######
@@ -380,29 +338,6 @@ $(TARGETS_MINIOS): mini-os-%:
                 mkdir -p $@/$$i ; \
 	done
 
-#######
-# ioemu
-#######
-
-ioemu-minios.gen.cfg: APP_LIBS = evtchn gnttab ctrl guest
-ioemu-minios.gen.cfg: ioemu-minios.cfg Makefile
-	$(GEN_config) >$@
-
-ioemu-minios-config.mk: ioemu-minios.gen.cfg
-	MINIOS_CONFIG="$(CURDIR)/$<" CONFIG_FILE="$(CURDIR)/$@" $(MAKE) DESTDIR= -C $(MINI_OS) config
-
-.PHONY: ioemu
-ioemu: cross-zlib cross-libpci libxenguest ioemu-minios-config.mk
-	[ -f ioemu/config-host.mak ] || \
-	  ( $(buildmakevars2shellvars); \
-	    cd ioemu ; \
-	    LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) \
-	    TARGET_CPPFLAGS="$(TARGET_CPPFLAGS) $(shell cat ioemu-minios-config.mk)" \
-	    TARGET_CFLAGS="$(TARGET_CFLAGS)" \
-	    TARGET_LDFLAGS="$(TARGET_LDFLAGS)" \
-	    $(QEMU_ROOT)/xen-setup-stubdom )
-	$(MAKE) DESTDIR= -C ioemu -f $(QEMU_ROOT)/Makefile
-
 ###
 # C
 ###
@@ -496,11 +431,6 @@ xenstorepvh: $(CROSS_ROOT) xenstorepvh-minios-config.mk
 # minios
 ########
 
-.PHONY: ioemu-stubdom
-ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a
-ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxenguest ioemu
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.gen.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
-
 .PHONY: c-stubdom
 c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxenguest c
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
@@ -539,18 +469,11 @@ xenstorepvh-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstorepvh $(XENSTORE_DEPS) xen
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: $(STUBDOMPATH) $(STUBDOM_INSTALL)
+install: $(STUBDOM_INSTALL)
 else
-install: $(STUBDOMPATH)
+install:
 endif
 
-install-ioemu: ioemu-stubdom
-	$(INSTALL_DIR) "$(DESTDIR)$(LIBEXEC_BIN)"
-	$(INSTALL_PROG) stubdom-dm "$(DESTDIR)$(LIBEXEC_BIN)"
-	$(INSTALL_DATA) stubdompath.sh "$(DESTDIR)$(LIBEXEC_BIN)"
-	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
-	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-ioemu/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/ioemu-stubdom.gz"
-
 install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
@@ -593,11 +516,6 @@ else
 uninstall:
 endif
 
-uninstall-ioemu:
-	rm -f $(DESTDIR)$(LIBEXEC_BIN)/stubdom-dm
-	rm -f $(DESTDIR)$(LIBEXEC_BIN)/stubdompath.sh
-	rm -f $(DESTDIR)$(XENFIRMWAREDIR)/ioemu-stubdom.gz
-
 uninstall-grub:
 	rm -f $(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz
 
@@ -617,11 +535,10 @@ uninstall-vtpmmgr:
 # clean
 #######
 
-# Only clean the libxc/ioemu/mini-os part
+# Only clean the libxc/mini-os part
 .PHONY: clean
 clean: $(foreach lib,$(STUB_LIBS),clean-libxen$(lib))
 clean:
-	rm -fr mini-os-$(XEN_TARGET_ARCH)-ioemu
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
@@ -632,11 +549,9 @@ clean:
 	$(MAKE) -C vtpm clean
 	$(MAKE) -C vtpmmgr clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
-	rm -f $(STUBDOMPATH)
 	rm -f *-minios-config.mk
 	rm -f *.gen.cfg
 	rm -fr pkg-config
-	-[ ! -d ioemu ] || $(MAKE) DESTDIR= -C ioemu clean
 	-[ ! -d xenstore ] || $(MAKE) -f $(CURDIR)/xenlibs.mk -C xenstore clean
 	-[ ! -d xenstorepvh ] || $(MAKE) -f $(CURDIR)/xenlibs.mk -C xenstorepvh clean
 
@@ -647,7 +562,7 @@ crossclean: clean
 	rm -fr newlib-$(XEN_TARGET_ARCH)
 	rm -fr zlib-$(XEN_TARGET_ARCH) pciutils-$(XEN_TARGET_ARCH)
 	rm -fr libs-$(XEN_TARGET_ARCH)
-	rm -fr ioemu xenstore xenstorepvh
+	rm -fr xenstore xenstorepvh
 	rm -fr gmp-$(XEN_TARGET_ARCH)
 	rm -fr polarssl-$(XEN_TARGET_ARCH)
 	rm -fr tpm_emulator-$(XEN_TARGET_ARCH)
diff --git a/stubdom/configure b/stubdom/configure
index 08cacf764c..9dd0e7c796 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -622,7 +622,6 @@ STUBDOM_UNINSTALL
 STUBDOM_INSTALL
 STUBDOM_BUILD
 STUBDOM_TARGETS
-ioemu
 vtpmmgr
 vtpm
 TPMEMU_VERSION
@@ -713,14 +712,12 @@ SHELL'
 ac_subst_files=''
 ac_user_opts='
 enable_option_checking
-enable_ioemu_stubdom
 enable_c_stubdom
 enable_pv_grub
 enable_xenstore_stubdom
 enable_xenstorepvh_stubdom
 enable_vtpm_stubdom
 enable_vtpmmgr_stubdom
-enable_qemu_traditional
 enable_debug
 enable_extfiles
 '
@@ -1363,7 +1360,6 @@ Optional Features:
   --disable-option-checking  ignore unrecognized --enable/--with options
   --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
   --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
-  --enable-ioemu-stubdom  Build and install ioemu-stubdom
   --enable-c-stubdom      Build and install c-stubdom (default is DISABLED)
   --enable-pv-grub        Build and install pv-grub (default is DISABLED)
   --disable-xenstore-stubdom
@@ -1375,7 +1371,6 @@ Optional Features:
   --enable-vtpm-stubdom   Build and install vtpm-stubdom
   --enable-vtpmmgr-stubdom
                           Build and install vtpmmgr-stubdom
-
   --disable-debug         Disable debug build of stubdom (default is ENABLED)
   --disable-extfiles      Use xen extfiles repository for libraries (default
                           is ENABLED)
@@ -2411,40 +2406,6 @@ case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
 
 # Enable/disable stub domains
 
-# Check whether --enable-ioemu-stubdom was given.
-if test ${enable_ioemu_stubdom+y}
-then :
-  enableval=$enable_ioemu_stubdom;
-
-if test "x$enableval" = "xyes"
-then :
-
-
-ioemu=y
-STUBDOM_TARGETS="$STUBDOM_TARGETS ioemu"
-STUBDOM_BUILD="$STUBDOM_BUILD ioemu-stubdom"
-STUBDOM_INSTALL="$STUBDOM_INSTALL install-ioemu"
-STUBDOM_UNINSTALL="$STUBDOM_UNINSTALL install-ioemu"
-
-
-else $as_nop
-
-if test "x$enableval" = "xno"
-then :
-
-
-ioemu=n
-
-
-fi
-
-fi
-
-
-fi
-
-
-
 # Check whether --enable-c-stubdom was given.
 if test ${enable_c_stubdom+y}
 then :
@@ -2685,35 +2646,6 @@ fi
 
 
 
-# Check whether --enable-qemu-traditional was given.
-if test ${enable_qemu_traditional+y}
-then :
-  enableval=$enable_qemu_traditional;
-fi
-
-if test "x$enable_qemu_traditional" = "xyes"
-then :
-
-    qemu_traditional=y
-else $as_nop
-
-    qemu_traditional=n
-
-fi
-if test "x$ioemu" = "x"
-then :
-
-    ioemu=$qemu_traditional
-
-fi
-echo "x$ioemu$qemu_traditional"
-if test "x$ioemu$qemu_traditional" = "xyn"
-then :
-
-    as_fn_error $? "IOEMU stubdomain requires qemu-traditional" "$LINENO" 5
-
-fi
-
 
 # Check whether --enable-debug was given.
 if test ${enable_debug+y}
@@ -4358,27 +4290,6 @@ fi
 
 
 
-if test "x$ioemu" = "xy" || test "x$ioemu" = "x"
-then :
-
-
-ioemu=y
-STUBDOM_TARGETS="$STUBDOM_TARGETS ioemu"
-STUBDOM_BUILD="$STUBDOM_BUILD ioemu-stubdom"
-STUBDOM_INSTALL="$STUBDOM_INSTALL install-ioemu"
-STUBDOM_UNINSTALL="$STUBDOM_UNINSTALL install-ioemu"
-
-
-else $as_nop
-
-
-ioemu=n
-
-
-fi
-
-
-
 
 
 
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index fc736c0387..f07b08c5b3 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -18,7 +18,6 @@ m4_include([../m4/depends.m4])
 m4_include([../m4/fetcher.m4])
 
 # Enable/disable stub domains
-AX_STUBDOM_CONDITIONAL([ioemu-stubdom], [ioemu])
 AX_STUBDOM_DEFAULT_DISABLE([c-stubdom], [c])
 AX_STUBDOM_DEFAULT_DISABLE([pv-grub], [grub])
 AX_STUBDOM_DEFAULT_ENABLE([xenstore-stubdom], [xenstore])
@@ -26,19 +25,6 @@ AX_STUBDOM_DEFAULT_ENABLE([xenstorepvh-stubdom], [xenstorepvh])
 AX_STUBDOM_CONDITIONAL([vtpm-stubdom], [vtpm])
 AX_STUBDOM_CONDITIONAL([vtpmmgr-stubdom], [vtpmmgr])
 
-AC_ARG_ENABLE([qemu-traditional])
-AS_IF([test "x$enable_qemu_traditional" = "xyes"], [
-    qemu_traditional=y],[
-    qemu_traditional=n
-])
-AS_IF([test "x$ioemu" = "x"], [
-    ioemu=$qemu_traditional
-])
-echo "x$ioemu$qemu_traditional"
-AS_IF([test "x$ioemu$qemu_traditional" = "xyn"], [
-    AC_MSG_ERROR(IOEMU stubdomain requires qemu-traditional)
-])
-
 AX_ARG_DEFAULT_ENABLE([debug], [Disable debug build of stubdom])
 AX_ARG_DEFAULT_ENABLE([extfiles], [Use xen extfiles repository for libraries])
 
@@ -69,7 +55,6 @@ AX_STUBDOM_AUTO_DEPENDS([vtpmmgr], [vtpm])
 #Conditionally enable these stubdoms based on the presense of dependencies
 AX_STUBDOM_CONDITIONAL_FINISH([vtpm-stubdom], [vtpm])
 AX_STUBDOM_CONDITIONAL_FINISH([vtpmmgr-stubdom], [vtpmmgr])
-AX_STUBDOM_CONDITIONAL_FINISH([ioemu-stubdom], [ioemu])
 
 AX_STUBDOM_FINISH
 AC_OUTPUT()
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
deleted file mode 100644
index 6153ae05f8..0000000000
--- a/stubdom/ioemu-minios.cfg
+++ /dev/null
@@ -1,6 +0,0 @@
-CONFIG_LIBC=y
-CONFIG_LWIP=y
-CONFIG_START_NETWORK=n
-CONFIG_QEMU_XS_ARGS=y
-CONFIG_PCIFRONT=y
-XEN_INTERFACE_VERSION=__XEN_LATEST_INTERFACE_VERSION__
diff --git a/tools/Makefile b/tools/Makefile
index e9e1cda305..6ecf7c0da8 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -24,7 +24,6 @@ SUBDIRS-$(CONFIG_Linux) += vchan
 
 # do not recurse in to a dir we are about to delete
 ifneq "$(MAKECMDGOALS)" "distclean"
-SUBDIRS-$(CONFIG_QEMU_TRAD) += qemu-xen-traditional-dir
 SUBDIRS-$(CONFIG_QEMU_XEN) += qemu-xen-dir
 endif
 
@@ -79,7 +78,6 @@ clean: subdirs-clean
 
 .PHONY: distclean
 distclean: subdirs-distclean clean
-	rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote
 	rm -rf qemu-xen-dir qemu-xen-dir-remote qemu-xen-build
 	rm -rf ../config/Tools.mk config.h config.log config.status \
 		config.cache autom4te.cache
@@ -97,11 +95,6 @@ QEMU_UPSTREAM_RPATH := -Wl,-rpath,$(LIBEXEC_LIB)
 IOEMU_EXTRA_LDFLAGS :=
 endif
 
-QEMU_ROOT := $(shell if [ -d "$(QEMU_TRADITIONAL_LOC)" ]; then echo "$(QEMU_TRADITIONAL_LOC)"; else echo .; fi)
-ifneq ($(QEMU_ROOT),.)
-export QEMU_ROOT
-endif
-
 # Targets for external trees:
 #  ${target}-dir-find
 #    See if the directory exists and check it out if not.
@@ -136,54 +129,6 @@ endif
 #   ${TARGET}_LOC
 #     The ultimate location of the source (either a local dir or remote URL)
 
-# External target: qemu-xen-traditional
-qemu-xen-traditional-dir-find:
-	set -ex; \
-	if test -d $(QEMU_TRADITIONAL_LOC); then \
-		mkdir -p qemu-xen-traditional-dir; \
-	else \
-		export GIT=$(GIT); \
-		$(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_TRADITIONAL_LOC) $(QEMU_TRADITIONAL_REVISION) qemu-xen-traditional-dir; \
-	fi
-
-.PHONY: qemu-xen-traditional-dir-force-update
-qemu-xen-traditional-dir-force-update: qemu-xen-traditional-dir-find
-	set -ex; \
-	if [ "$(QEMU_TRADITIONAL_REVISION)" ]; then \
-		cd qemu-xen-traditional-dir-remote; \
-		$(GIT) fetch origin; \
-		$(GIT) reset --hard $(QEMU_TRADITIONAL_REVISION); \
-	fi
-
-qemu-traditional-recurse = \
-	set -e; \
-		$(buildmakevars2shellvars); \
-		export CONFIG_BLKTAP1=n; \
-		export BUILDING_QEMU_TRAD=y; \
-		cd qemu-xen-traditional-dir; \
-		$(1)
-
-subdir-all-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
-	$(call qemu-traditional-recurse,\
-		$(QEMU_ROOT)/xen-setup \
-		--extra-cflags="-D__XEN_TOOLS__ $(EXTRA_CFLAGS_QEMU_TRADITIONAL)" \
-		$(IOEMU_EXTRA_LDFLAGS) \
-		--cpu=$(IOEMU_CPU_ARCH) \
-		$(IOEMU_CONFIGURE_CROSS); \
-		$(MAKE) all \
-	)
-
-subdir-install-qemu-xen-traditional-dir: subdir-all-qemu-xen-traditional-dir
-	$(call qemu-traditional-recurse,$(MAKE) install)
-
-subdir-clean-qemu-xen-traditional-dir:
-	set -e; if test -d qemu-xen-traditional-dir/.; then \
-		$(MAKE) -C qemu-xen-traditional-dir clean; \
-	fi
-subdir-uninstall-qemu-xen-traditional-dir:
-	rm -f $(D)$(bindir)/qemu-nbd*
-	rm -f $(D)$(bindir)/qemu-img*
-
 # External target: qemu-xen
 qemu-xen-dir-find:
 	if test -d $(QEMU_UPSTREAM_LOC) ; then \
@@ -276,9 +221,6 @@ subtree-force-update:
 ifeq ($(CONFIG_QEMU_XEN),y)
 	$(MAKE) qemu-xen-dir-force-update
 endif
-ifeq ($(CONFIG_QEMU_TRAD),y)
-	$(MAKE) qemu-xen-traditional-dir-force-update
-endif
 ifeq ($(CONFIG_X86),y)
 	$(MAKE) -C firmware subtree-force-update
 endif
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 6bd636709f..725c3c32e9 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -134,12 +134,9 @@ endif
 
 CFLAGS_libxenlight += $(CFLAGS_libxenctrl)
 
-# Don't add -Werror if we are used by qemu-trad build system.
-ifndef BUILDING_QEMU_TRAD
 ifeq ($(CONFIG_WERROR),y)
 CFLAGS += -Werror
 endif
-endif
 
 ifeq ($(debug),y)
 # Use -Og if available, -O0 otherwise
diff --git a/tools/config.h.in b/tools/config.h.in
index 0bab3cb136..fe2a94cfc4 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -42,9 +42,6 @@
 /* pygrub enabled */
 #undef HAVE_PYGRUB
 
-/* Qemu traditional enabled */
-#undef HAVE_QEMU_TRADITIONAL
-
 /* ROMBIOS enabled */
 #undef HAVE_ROMBIOS
 
diff --git a/tools/configure b/tools/configure
index e1f6ea6bf5..27ae7c52fb 100755
--- a/tools/configure
+++ b/tools/configure
@@ -726,7 +726,6 @@ BCC
 LD86
 AS86
 ipxe
-qemu_traditional
 LINUX_BACKEND_MODULES
 pygrub
 golang
@@ -835,7 +834,6 @@ enable_seabios
 enable_golang
 enable_pygrub
 with_linux_backend_modules
-enable_qemu_traditional
 enable_ipxe
 with_system_ipxe
 enable_rombios
@@ -1518,13 +1516,10 @@ Optional Features:
   --disable-seabios       Disable SeaBIOS (default is ENABLED)
   --disable-golang        Disable Go tools (default is ENABLED)
   --disable-pygrub        Disable pygrub (default is ENABLED)
-  --enable-qemu-traditional
-                          Enable qemu traditional device model, (DEFAULT is
-                          off)
   --enable-ipxe           Enable in-tree IPXE, (DEFAULT is off, see also
                           --with-system-ipxe)
-  --enable-rombios        Enable ROMBIOS, (DEFAULT is on if qemu-traditional
-                          or ipxe is enabled, otherwise off)
+  --enable-rombios        Enable ROMBIOS, (DEFAULT is on if ipxe is enabled,
+                          otherwise off)
   --enable-libfsimage     Enable libfsimage, (DEFAULT is on if pygrub is
                           enabled, otherwise off)
   --enable-systemd        Enable systemd support (default is DISABLED)
@@ -4838,45 +4833,16 @@ fi
 LINUX_BACKEND_MODULES="`eval echo $LINUX_BACKEND_MODULES`"
 
 
-# Check whether --enable-qemu-traditional was given.
-if test ${enable_qemu_traditional+y}
-then :
-  enableval=$enable_qemu_traditional;
-fi
-
-if test "x$enable_qemu_traditional" = "xyes"
-then :
-
-
-printf "%s\n" "#define HAVE_QEMU_TRADITIONAL 1" >>confdefs.h
-
-    qemu_traditional=y
-else $as_nop
-
-    qemu_traditional=n
-
-fi
-
-
 # Check whether --enable-ipxe was given.
 if test ${enable_ipxe+y}
 then :
   enableval=$enable_ipxe;
-else $as_nop
-
-    if test "x$enable_qemu_traditional" = "xyes"
-then :
-
-        enable_ipxe="yes"
-
 else $as_nop
 
         enable_ipxe="no"
 
 fi
 
-fi
-
 if test "x$enable_ipxe" = "xno"
 then :
   ipxe=n
@@ -4912,7 +4878,7 @@ then :
   enableval=$enable_rombios;
 else $as_nop
 
-    if test "x$enable_qemu_traditional" = "xyes" -o "x$enable_ipxe" = "xyes"
+    if test "x$enable_ipxe" = "xyes"
 then :
 
         enable_rombios="yes"
@@ -4928,7 +4894,7 @@ fi
 if test "x$enable_rombios" = "xyes"
 then :
 
-                # Extract the first word of "as86", so it can be a program name with args.
+    # Extract the first word of "as86", so it can be a program name with args.
 set dummy as86; ac_word=$2
 { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 printf %s "checking for $ac_word... " >&6; }
diff --git a/tools/configure.ac b/tools/configure.ac
index 0dd6d747ab..dada1c3b15 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -121,25 +121,11 @@ esac])
 LINUX_BACKEND_MODULES="`eval echo $LINUX_BACKEND_MODULES`"
 AC_SUBST(LINUX_BACKEND_MODULES)
 
-AC_ARG_ENABLE([qemu-traditional],
-    AS_HELP_STRING([--enable-qemu-traditional],
-                   [Enable qemu traditional device model, (DEFAULT is off)]))
-AS_IF([test "x$enable_qemu_traditional" = "xyes"], [
-AC_DEFINE([HAVE_QEMU_TRADITIONAL], [1], [Qemu traditional enabled])
-    qemu_traditional=y],[
-    qemu_traditional=n
-])
-AC_SUBST(qemu_traditional)
-
 AC_ARG_ENABLE([ipxe],
     AS_HELP_STRING([--enable-ipxe],
                    [Enable in-tree IPXE,
                     (DEFAULT is off, see also --with-system-ipxe)]),,[
-    AS_IF([test "x$enable_qemu_traditional" = "xyes"], [
-        enable_ipxe="yes"
-    ], [
         enable_ipxe="no"
-    ])
 ])
 AS_IF([test "x$enable_ipxe" = "xno"], [ipxe=n], [ipxe=y])
 AC_ARG_WITH([system-ipxe],
@@ -162,18 +148,15 @@ AC_SUBST(ipxe)
 
 AC_ARG_ENABLE([rombios],
     AS_HELP_STRING([--enable-rombios],
-                   [Enable ROMBIOS, (DEFAULT is on if qemu-traditional or ipxe is enabled,
+                   [Enable ROMBIOS, (DEFAULT is on if ipxe is enabled,
                     otherwise off)]),,[
-    AS_IF([test "x$enable_qemu_traditional" = "xyes" -o "x$enable_ipxe" = "xyes"], [
+    AS_IF([test "x$enable_ipxe" = "xyes"], [
         enable_rombios="yes"
     ], [
         enable_rombios="no"
     ])
 ])
 AS_IF([test "x$enable_rombios" = "xyes"], [
-    dnl as86, ld86, and bcc are only required when building rombios. They
-    dnl are only needed when the host system is x86 but that check is done
-    dnl for us above when checking if we should build with qemu-traditional.
     AX_PATH_PROG_OR_FAIL([AS86], [as86])
     AX_PATH_PROG_OR_FAIL([LD86], [ld86])
     AX_PATH_PROG_OR_FAIL([BCC], [bcc])
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 13:21:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 13:21:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998403.1379163 (Exim 4.92)
	(envelope-from )
	id 1uJuEq-0003sr-MM; Tue, 27 May 2025 13:21:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998403.1379163; Tue, 27 May 2025 13:21: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 1uJuEq-0003sk-IX; Tue, 27 May 2025 13:21:04 +0000
Received: by outflank-mailman (input) for mailman id 998403;
 Tue, 27 May 2025 13:21:03 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uJuEp-0002tx-TD
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 13:21:03 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6f5759b3-3afd-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 15:21:01 +0200 (CEST)
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 DFA6021F4F;
 Tue, 27 May 2025 13:21:01 +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 592451388B;
 Tue, 27 May 2025 13:21:01 +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 gwMkFD28NWjMKAAAD6G6ig
 (envelope-from ); Tue, 27 May 2025 13:21: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" 
X-Inumbo-ID: 6f5759b3-3afd-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748352061; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=y55XTVwicAky48KdmH1pLa3enVuUsFXVNUj0TUNNUWs=;
	b=uycHtx9fldTzRwQpF3B0ZItvG72Jb+SBbgNQFSXf7HRVMkwFcEb1a7P6YhIw1SbQ2nJ6gD
	6E2LFVzRKU/Ust+pCs8lyBUrREEnqOj0suH2pJMyZbG9H6NyN2zGpJLvId1D7YvQL8q6KI
	m8MhBOtFNYS/smaf8Qfd0OpmAq8IYn0=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1748352061; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=y55XTVwicAky48KdmH1pLa3enVuUsFXVNUj0TUNNUWs=;
	b=uycHtx9fldTzRwQpF3B0ZItvG72Jb+SBbgNQFSXf7HRVMkwFcEb1a7P6YhIw1SbQ2nJ6gD
	6E2LFVzRKU/Ust+pCs8lyBUrREEnqOj0suH2pJMyZbG9H6NyN2zGpJLvId1D7YvQL8q6KI
	m8MhBOtFNYS/smaf8Qfd0OpmAq8IYn0=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v4 4/4] build: don't require full tools build for building stubdoms
Date: Tue, 27 May 2025 15:20:33 +0200
Message-ID: <20250527132035.985-5-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250527132035.985-1-jgross@suse.com>
References: <20250527132035.985-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.80
X-Spam-Flag: NO
X-Spamd-Result: default: False [-1.80 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[9];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:email,suse.com:mid];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Level: 

With the drop of qemu-traditional "make stubdom" no longer requires
"make tools" to have finished.

It is enough to add "install-tools-public-headers" as a prereq of
"install-stubdom".

Signed-off-by: Juergen Gross 
Acked-by: Anthony PERARD 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index c9d80a6dc6..67b71ac3d4 100644
--- a/Makefile
+++ b/Makefile
@@ -147,7 +147,7 @@ install-tools: install-tools-public-headers
 	$(MAKE) -C tools install
 
 .PHONY: install-stubdom
-install-stubdom: mini-os-dir install-tools
+install-stubdom: mini-os-dir install-tools-public-headers
 	$(MAKE) -C stubdom install
 ifeq (x86_64,$(XEN_TARGET_ARCH))
 	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub-if-enabled
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 13:42:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 13:42:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998451.1379172 (Exim 4.92)
	(envelope-from )
	id 1uJuZ9-00087p-64; Tue, 27 May 2025 13:42:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998451.1379172; Tue, 27 May 2025 13:42: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 1uJuZ9-00087i-3K; Tue, 27 May 2025 13:42:03 +0000
Received: by outflank-mailman (input) for mailman id 998451;
 Tue, 27 May 2025 13:42:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uJuZ8-00087c-3q
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 13:42:02 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJuZ7-0053Lp-2i;
 Tue, 27 May 2025 13:42:01 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uJuZ8-00A3a2-03;
 Tue, 27 May 2025 13:42: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=3jcIE3AZCA5b2l0xa8fnUJSl81DISlLs88JjwIVQqD4=; b=JzjaTRy3XVZFa/+5Nin9bS0M70
	yJfktD/zdDy3LDFJ/RcTKTGWGUKdUwx1eaAo+4ntJ9HQHoR9pLtmuiK609w5HTncEllX6uFToZFSk
	NNa+8CPDVlVc3CzP5eLyF79U+4PG4LlBI2ukS5snsKeyzILetLDPhD8I5eUxiv6v+vBQ=;
Date: Tue, 27 May 2025 15:41:59 +0200
From: Anthony PERARD 
To: Andrew Cooper 
Cc: Xen-devel ,
	Stefano Stabellini ,
	Michal Orzel ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Subject: Re: [PATCH 1/3] CI/qubes: Deduplicate the handling of ${dom0_check}
Message-ID: 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
 <20250522173640.575452-2-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250522173640.575452-2-andrew.cooper3@citrix.com>

On Thu, May 22, 2025 at 06:36:38PM +0100, Andrew Cooper wrote:
> Make it clear that ${dom0_check} is unconditional.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue May 27 13:55:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 13:55:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998460.1379184 (Exim 4.92)
	(envelope-from )
	id 1uJum8-0001Vv-AU; Tue, 27 May 2025 13:55:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998460.1379184; Tue, 27 May 2025 13:55: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 1uJum8-0001Vo-6T; Tue, 27 May 2025 13:55:28 +0000
Received: by outflank-mailman (input) for mailman id 998460;
 Tue, 27 May 2025 13:55:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJum6-0001Vg-Ha
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 13:55:26 +0000
Received: from fout-a7-smtp.messagingengine.com
 (fout-a7-smtp.messagingengine.com [103.168.172.150])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 39d9a2a1-3b02-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 15:55:20 +0200 (CEST)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfout.phl.internal (Postfix) with ESMTP id 51B921383AAF;
 Tue, 27 May 2025 09:55:19 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-03.internal (MEProxy); Tue, 27 May 2025 09:55:19 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 27 May 2025 09:55:17 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 39d9a2a1-3b02-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1748354119;
	 x=1748440519; bh=nFL9UMqLY6lge/cznspNadDv3MceWLjgTiSDAGd2w/w=; b=
	uA3NzNqKnpYK2lrqFO+i9hdd+xeWyp9S+nx/o3Bo8UZa9ppGu3FZa4GYp3i5maJR
	7Mqh3KnPSAjj+JPbNjM9ZxMj8RDi7AlweoCn3rKRyHxiID/9a/M2o3TnmlXx4Qvm
	4r9nGFnAWWNot82fyv0x5Y0ot7XeNLyoe9WWGkqlXK7//xePiayzkkQ6CEWzB+oO
	5JmP0Rs6vdtKroFhDJ5E2cdFFBtKjUKeb9uk6djWR8Y8sGnDnS9G2V0v3/h79gkE
	xDMctJ20lPG3o78f6ayvIBdQOHWhjYb5KKJG5dRZh7+cEpcjeH0CeDVpg8caRqt3
	8NxaB3ZXsiiggrzP1GsWUA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
	1748354119; x=1748440519; bh=nFL9UMqLY6lge/cznspNadDv3MceWLjgTiS
	DAGd2w/w=; b=CcfbgyodLn/0SfXDc0y4A6nyElMBCEnpREtYiuwiDgeRiPBkTvA
	I8S3nYXnBcnB2grBynK4zLJJ0J7HwxJbSJUtLbXR+4UvF9xTos0XFD2dmuc/xujL
	zS1oNEr7yBnPwAANevzMmm88K1LlFBoxX5j1Pn0EmYUAg3nkDIxPsd521vBl8RxY
	jQTXSc/ngkhH4pwL46XVPrlvYK4kxYNbTNs/KAx79LF1lVeqfdp/fQn0HOzs/RuC
	1CoTC/C3ztWArqt+W1S2Rfip129FqyyOCv9oHwKLrN62XL71jlWsCA0GIZm0fqhW
	V09G7nVGSvo8XSPrMGlES32e65MF3DKCA3Q==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvtdehheculddtuddrgeefvddrtd
    dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
    fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
    dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhf
    gggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucforghrtgiihihkohifsh
    hkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhg
    shhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteefvefhfeehieetleeihf
    ejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvghrufhiiigvpedtnecu
    rfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthh
    hinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeehpdhmohguvgepshhmthhpohhu
    thdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpd
    hrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdho
    rhhgpdhrtghpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthh
    dprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphht
    thhopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 27 May 2025 15:55:15 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel 
Subject: Re: [PATCH 3/3] CI: Adjust how domU is packaged in dom0
Message-ID: 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
 <20250522173640.575452-4-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="p3jWn/E45DBNiCxB"
Content-Disposition: inline
In-Reply-To: <20250522173640.575452-4-andrew.cooper3@citrix.com>


--p3jWn/E45DBNiCxB
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 May 2025 15:55:15 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Stefano Stabellini ,
	Michal Orzel 
Subject: Re: [PATCH 3/3] CI: Adjust how domU is packaged in dom0

On Thu, May 22, 2025 at 06:36:40PM +0100, Andrew Cooper wrote:
> Package domU in /root for dom0 and insert into the uncompressed part of d=
om0's
> rootfs, rather than recompressing it as part of the overlay.

It doesn't really need moving to /root to achieve this, no? The
domU-in-dom0.cpio can very well contain boot/* files.

> For Qubes, this avoids putting the domU kernel in dom0's rootfs for tests
> which aren't going to boot a guest.
>=20
> Signed-off-by: Andrew Cooper 
> ---
> CC: Anthony PERARD 
> CC: Stefano Stabellini 
> CC: Michal Orzel 
> CC: Marek Marczykowski-G=C3=B3recki 
> ---
>  automation/scripts/qubes-x86-64.sh            | 20 +++++++++++++------
>  .../scripts/xilinx-smoke-dom0-x86_64.sh       | 16 +++++++++++----
>  2 files changed, 26 insertions(+), 10 deletions(-)
>=20
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qube=
s-x86-64.sh
> index 1dd3f48b3d29..17a37134f46a 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -154,8 +154,8 @@ esac
>  domU_config=3D"
>  type =3D '${domU_type}'
>  name =3D 'domU'
> -kernel =3D '/boot/vmlinuz'
> -ramdisk =3D '/boot/initrd-domU'
> +kernel =3D '/root/vmlinuz-domU'
> +ramdisk =3D '/root/initrd-domU'
>  cmdline =3D 'root=3D/dev/ram0 console=3Dhvc0'
>  memory =3D 512
>  vif =3D [ ${domU_vif} ]
> @@ -185,12 +185,24 @@ Kernel \r on an \m (\l)
>      find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
>      cd ..
>      rm -rf rootfs
> +
> +    # Package domU kernel+rootfs in /root for dom0 (uncompressed)
> +    mkdir -p rootfs/root
> +    cd rootfs
> +    cp ../binaries/bzImage root/vmlinuz-domU
> +    cp ../binaries/domU-rootfs.cpio.gz root/initrd-domU
> +    find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
> +    cd ..
> +    rm -rf rootfs
>  fi
> =20
>  # Dom0 rootfs.  The order or concatination is important; ucode wants to =
come
>  # first, and all uncompressed must be ahead of compressed.
>  parts=3D(
>      binaries/ucode.cpio
> +)
> +[ -n "$domU_check" ] && parts+=3D(binaries/domU-in-dom0.cpio)
> +parts+=3D(
>      binaries/rootfs.cpio.gz
>      binaries/xen-tools.cpio.gz
>  )
> @@ -238,10 +250,6 @@ mkdir -p etc/default
>  echo "XENCONSOLED_TRACE=3Dall" >> etc/default/xencommons
>  echo "QEMU_XEN=3D/bin/false" >> etc/default/xencommons
>  mkdir -p var/log/xen/console
> -cp ../binaries/bzImage boot/vmlinuz
> -if [ -n "$domU_check" ]; then
> -    cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
> -fi
>  find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
>  cd ..
> =20
> diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/=
scripts/xilinx-smoke-dom0-x86_64.sh
> index 0fbabb41054a..29817ff81d0a 100755
> --- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> +++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> @@ -22,8 +22,8 @@ DOMU_CMD=3D""
>  DOMU_CFG=3D'
>  type =3D "pvh"
>  name =3D "domU"
> -kernel =3D "/boot/vmlinuz"
> -ramdisk =3D "/boot/initrd-domU"
> +kernel =3D "/root/vmlinuz-domU"
> +ramdisk =3D "/root/initrd-domU"
>  extra =3D "root=3D/dev/ram0 console=3Dhvc0"
>  memory =3D 512
>  '
> @@ -103,10 +103,20 @@ find . | cpio -H newc -o | gzip >> ../binaries/domU=
-rootfs.cpio.gz
>  cd ..
>  rm -rf rootfs
> =20
> +# Package domU kernel+rootfs in /root for dom0 (uncompressed)
> +mkdir -p rootfs/root
> +cd rootfs
> +cp ../binaries/bzImage root/vmlinuz-domU
> +cp ../binaries/domU-rootfs.cpio.gz root/initrd-domU
> +find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
> +cd ..
> +rm -rf rootfs
> +
>  # Dom0 rootfs.  The order or concatination is important; ucode wants to =
come
>  # first, and all uncompressed must be ahead of compressed.
>  parts=3D(
>      binaries/ucode.cpio
> +    binaries/domU-in-dom0.cpio
>      binaries/rootfs.cpio.gz
>      binaries/xen-tools.cpio.gz
>  )
> @@ -127,8 +137,6 @@ echo "${DOMU_CFG}${DOMU_CFG_EXTRA}" > etc/xen/domU.cfg
>  echo "XENCONSOLED_TRACE=3Dall" >> etc/default/xencommons
>  echo "QEMU_XEN=3D/bin/false" >> etc/default/xencommons
>  mkdir -p var/log/xen/console
> -cp ../binaries/bzImage boot/vmlinuz
> -cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
>  find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
>  cd ..
> =20
> --=20
> 2.39.5
>=20

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--p3jWn/E45DBNiCxB
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg1xEQACgkQ24/THMrX
1yxnZQf8CcIqAT9+qIN1TkU1D+rJbFFe8mval3SeokAdxJlmN0huM2mJYcfKmWLp
esqhotPZY6BaWv79qsdrn8ueq+qEAQk72SYGjOpQLrbiWs/+npSC6SHcxsIEHSON
K0lIsZ7oZ4Am3dNh6GinWfxO+rQ7dacaXgTKmQsgZzyZJHEbwFydp22YwfpQ3WLj
TUsrtGlLOP3pDFhxjQKXUO1YJ4zQtLlJa6WffkrKmCSE83mitPbKBRL0ruazlGaA
d1LK5sKyjUOkBJjJdz5Ub/KnMV/0qKSS1SxFrQm9eAfSq5wkXkeSJaJt5Hkt77aP
5XB8HuwGHFlmXR+pmI30ZtVw6dCbgg==
=UHsO
-----END PGP SIGNATURE-----

--p3jWn/E45DBNiCxB--


From xen-devel-bounces@lists.xenproject.org Tue May 27 14:01:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 14:01:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998471.1379192 (Exim 4.92)
	(envelope-from )
	id 1uJus5-000390-TT; Tue, 27 May 2025 14:01:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998471.1379192; Tue, 27 May 2025 14:01: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 1uJus5-00038t-Qk; Tue, 27 May 2025 14:01:37 +0000
Received: by outflank-mailman (input) for mailman id 998471;
 Tue, 27 May 2025 14:01:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uJus4-00038n-Uz
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 14:01:36 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uJus4-0053ou-29;
 Tue, 27 May 2025 14:01:36 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uJus4-00AY08-2Z;
 Tue, 27 May 2025 14:01: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=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=rqbwXwjMP7vK3NmLgSzJprV7uK4nyJPjRabhk7YYEyE=; b=RKEqdBvXO0A8t8fK1WYqlr//oE
	Y/I7RA5+qfqDlblkU4HXAUUD0pri+hrRgwQtxe/34Ynp236glEr7vqSGlyw9gAiVoIIMnBKnLHc2I
	2zl1i3mq+rfjTlBX4i00G+vDJOuw8RUYYWMi9pWeZ12GaNeGfbxQemXWNRmzYp6PsV/s=;
Date: Tue, 27 May 2025 16:01:34 +0200
From: Anthony PERARD 
To: Andrew Cooper 
Cc: Xen-devel ,
	Stefano Stabellini ,
	Michal Orzel ,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Subject: Re: [PATCH 2/3] CI: Use bash arrays to simplfy dom0 rootfs
 construction
Message-ID: 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
 <20250522173640.575452-3-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250522173640.575452-3-andrew.cooper3@citrix.com>

On Thu, May 22, 2025 at 06:36:39PM +0100, Andrew Cooper wrote:
> For Qubes, this requires switching from sh to bash.
> 
> This reduces the number of times the target filename needs to be written to 1.
> 
> Expand the comment to explain the concatination constraints.

Isn't the correct spelling "concatenation"? Same for the two comments.

> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 
> ---
> I would like to find a slightly nicer way of conditional parts, but nothing
> comes to mind.

Well, one way I can think of is having a new variable which can carry
the rootfs part associated with a particular test, then that variable
can be updated at the time we configure for that test. Something like:

# init
declare -a append_rootfs_part
# or append_rootfs_part=() is probably fine too.

case $test in
  argo)
    append_rootfs_part+=(argo.cpio.gz)
    # ... other test configuration
    ;;
esac

# Dom0 rootfs
parts=(
    rootfs.cpio.gz
    xen-tools.cpio.gz
    "${append_rootfs_part[@]}"
)

And that should works fine, even if there isn't any extra rootfs part.

> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> index 10af274a0ba7..1dd3f48b3d29 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -187,10 +187,14 @@ Kernel \r on an \m (\l)
>      rm -rf rootfs
>  fi
>  
> -# Dom0 rootfs
> -cp binaries/ucode.cpio binaries/dom0-rootfs.cpio.gz
> -cat binaries/rootfs.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> -cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> +# Dom0 rootfs.  The order or concatination is important; ucode wants to come

                             ^ of concatenation

Same typo in the other comment.

Beside the typo, patch looks fine:
Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Tue May 27 14:48:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 14:48:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998485.1379204 (Exim 4.92)
	(envelope-from )
	id 1uJvbH-000097-9e; Tue, 27 May 2025 14:48:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998485.1379204; Tue, 27 May 2025 14: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 1uJvbH-000090-5S; Tue, 27 May 2025 14:48:19 +0000
Received: by outflank-mailman (input) for mailman id 998485;
 Tue, 27 May 2025 14:48:17 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJvbF-00008r-30
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 14:48:17 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9b982b58-3b09-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 16:48:11 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ad1b94382b8so581415266b.0
 for ; Tue, 27 May 2025 07:48:10 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad8962b2c1asm58390366b.122.2025.05.27.07.48.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 07:48: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" 
X-Inumbo-ID: 9b982b58-3b09-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748357289; x=1748962089; darn=lists.xenproject.org;
        h=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;
        bh=aHrRN9zT09E3ejynPxXB+8SYv8/sfMdxs/rspADcXhg=;
        b=IHRveK2P6kDJ53R3JBxOfzw5StthX7rX7xgUeMRa0c+pHXhMzlubKarYTEXsn1+qXn
         CFdiQk319jlp5Hr5SABYSDD1yW1CmjloKaYXlaC8isbAAArtU+aqRyw4jbuj/Wu5cuux
         TozFFgN/zYXr1to5sK/HnGKIDcg/qL1GXhYawyUjEXlVeBjO9QRxQo9qWKHaZJ5utf1q
         JhHjObiqB/AND0Ti95Z70tm44WJkcLC2oanenj1pTlfQYTQrXzVynYMKpN4UCWeDLSjE
         32ccCC7Tvmr4F5GNqnD4HqOnss+2nlwvUbT7mP3LMpR6u/0TNex7R9WufEbCtdJW8qgz
         W34g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748357289; x=1748962089;
        h=in-reply-to:content-language:references:cc:to:subject:from
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=aHrRN9zT09E3ejynPxXB+8SYv8/sfMdxs/rspADcXhg=;
        b=Be7F86dI0sbDluuiW85qKrqGF0rQVHZKqZ0IGsTf3UeqQAEXemUHIZj3kVIYiVMM2r
         ZNwt09Ka2RrBrH4ZgAQ2YdSrzb+B5Rqt8vGf4NAGD/q0oZhw8mi0/9Do0xcJGSQNv0N8
         mt48U0ki5QJKdbBBXQB/OU2e+TH8YvnUooLO9Iy5Cf6hi1jNpdcbNYxoMH6Aaoo84c6z
         CNufdcIHSujFjtz3KqKlIC/ulLR5ygCKtgdSp7GqKHxH3HfaQjCGnY+TfAcnX/cN3D8O
         1OGIw8MBs5pmTTjtIpxw9GF01LqIiend1M7iJKNPixDUg7Q0oaZ06EbNJgkRRGKM6Ys7
         HcpA==
X-Forwarded-Encrypted: i=1; AJvYcCW0/dBDuOkgSqHrgxynqoaHZ0wgCvLdxvIHp9ZA48sYUQdLFXM/mVZ+GqYoW788nt5OLQa6LyESRVE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YynyBEKkFHK022o1GGmM7kbPOPRLifWmf8+qGI+XH3JPUCnvDen
	ASDv0Wzj8W7FgcPofgr2aXkSSuK8BFyK/AvhRLmQqR/4hLlwSUqnPxay
X-Gm-Gg: ASbGncskrmkySKbXa5k7/YnZe+BxJ9mHRudBO+9OQwv2rxPhggHHDtx432xRB5lBHjf
	Qoa2ULkiU0VWYTNoJUk5qhBECnme9ouhuERKl/FIG3x+oa+A2RWWo2Ujy36itXVrJpWjrNJ5bx8
	hqrf8Pfnf60YYScRYh2IR/uVZODWgbcoXwIf/DZHxJ8srIc4LDkB6JzKkZkzcUy/Mhiv7ouc84u
	KAbpMC/haydbu/tjmlB321JsorwvUL283Z/vM/pHNEVVY76HpR2A/D79b6k29XlyaWzY9SiAw55
	sowgFr3xYddvkwsBnVLiy/T+hXRwRaLykmYeg910S7HMRkZeDIKxpiUgmuVEDzAfrHzSZ9xqawK
	BYkHK2TtGXcjXtbdYVyM46BSe
X-Google-Smtp-Source: AGHT+IHGHrScA9m+pJ8Kl3SjzxXHbEyGw8gTRnS84zxttGZe4851HCB2+zomF77dLps61INarQfpZg==
X-Received: by 2002:a17:907:c26:b0:ad2:43b6:dd6d with SMTP id a640c23a62f3a-ad85b051c94mr1283502366b.12.1748357289261;
        Tue, 27 May 2025 07:48:09 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------6NkVv0mXUkRV1V7FI08DK8ty"
Message-ID: <9b9d4226-88c0-4286-9157-34788b3e1159@gmail.com>
Date: Tue, 27 May 2025 16:48:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko 
Subject: Re: [PATCH v3 09/14] xen/riscv: aplic_init() implementation
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 
 <058d0610-0f48-4366-b1bc-4e31ecc79084@suse.com>
Content-Language: en-US
In-Reply-To: <058d0610-0f48-4366-b1bc-4e31ecc79084@suse.com>

This is a multi-part message in MIME format.
--------------6NkVv0mXUkRV1V7FI08DK8ty
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/22/25 5:26 PM, Jan Beulich wrote:
> On 21.05.2025 18:03, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/aplic.c
> +++ b/xen/arch/riscv/aplic.c
> @@ -9,19 +9,113 @@
>    * Copyright (c) 2024-2025 Vates
>    */
>   
> +#include 
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
> +#include 
> +
> +#include "aplic-priv.h"
>   
>   #include 
> +#include 
>   #include 
> +#include 
> +
> +#define APLIC_DEFAULT_PRIORITY  1
> +
> +/* The maximum number of wired interrupt sources supported by APLIC domain. */
> +#define APLIC_MAX_NUM_WIRED_IRQ_SOURCES 1023
> Wait - what's "wired" here? There's only MSI you said elsewhere?

This what was mentioned in DT binding:
   riscv,num-sources:
     $ref: /schemas/types.yaml#/definitions/uint32
     minimum: 1
     maximum: 1023
     description:
       Specifies the number of wired interrupt sources supported by this
       APLIC domain.

But 'wired' isn't really mention in AIA spec:
   For each possible interrupt source , register sourcecfg[ ] controls the source
   mode for source in this interrupt domain as well as any delegation of the source
   to a child domain.

So IMO it isn't connected to wired or not interrupts. So ...

>
> Further - how's this 1023 related to any of the other uses of that number?
> Is this by chance ARRAY_SIZE(aplic.regs->sourcecfg)? If so, it wants
> expressing like that, to allow making the connection.

...ARRAY_SIZE(aplic.regs->sourcecfg) perfectly match and will be used 
instead of APLIC_MAX_NUM_WIRED_IRQ_SOURCES.

>> +static struct aplic_priv aplic;
>>   
>>   static struct intc_info __ro_after_init aplic_info = {
>>       .hw_version = INTC_APLIC,
>>   };
>>   
>> +static void __init aplic_init_hw_interrupts(void)
>> +{
>> +    unsigned int i;
>> +
>> +    /* Disable all interrupts */
>> +    for ( i = 0; i < ARRAY_SIZE(aplic.regs->clrie); i++)
>> +        writel(~0U, &aplic.regs->clrie[i]);
>> +
>> +    /* Set interrupt type and default priority for all interrupts */
>> +    for ( i = 0; i < aplic_info.num_irqs; i++ )
>> +    {
>> +        writel(0, &aplic.regs->sourcecfg[i]);
>> +        /*
>> +         * 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.
>> +         */
>> +        writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i]);
>> +    }
>> +
>> +    writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg);
>> +}
>> +
>> +static int __init cf_check aplic_init(void)
>> +{
>> +    dt_phandle imsic_phandle;
>> +    const __be32 *prop;
>> +    uint64_t size, paddr;
>> +    const struct dt_device_node *imsic_node;
>> +    const struct dt_device_node *node = aplic_info.node;
>> +    int rc;
>> +
>> +    /* Check for associated imsic node */
>> +    if ( !dt_property_read_u32(node, "msi-parent", &imsic_phandle) )
>> +        panic("%s: IDC mode not supported\n", node->full_name);
>> +
>> +    imsic_node = dt_find_node_by_phandle(imsic_phandle);
>> +    if ( !imsic_node )
>> +        panic("%s: unable to find IMSIC node\n", node->full_name);
>> +
>> +    rc = imsic_init(imsic_node);
>> +    if ( rc == IRQ_M_EXT )
>> +        /* Machine mode imsic node, ignore this aplic node */
>> +        return 0;
>> +    else if ( rc )
> As before: No "else" please when the earlier if() ends in an unconditional
> control flow change.
> +        panic("%s: Failded to initialize IMSIC\n", node->full_name);
> +
> +    /* Find out number of interrupt sources */
> +    if ( !dt_property_read_u32(node, "riscv,num-sources",
> +                               &aplic_info.num_irqs) )
> +        panic("%s: failed to get number of interrupt sources\n",
> +              node->full_name);
> +
> +    if ( aplic_info.num_irqs > APLIC_MAX_NUM_WIRED_IRQ_SOURCES )
> +        panic("%s: too big number of riscv,num-source: %u\n",
> +               __func__, aplic_info.num_irqs);
> Is it actually necessary to panic() in this case? Can't you just lower
> .num_irqs instead (rendering higher IRQs,if any, non-functional)?

Good point. I think we can just use aplic_info.num_irqs =ARRAY_SIZE(aplic.regs->sourcecfg);

>
>> +    prop = dt_get_property(node, "reg", NULL);
>> +    dt_get_range(&prop, node, &paddr, &size);
>> +    if ( !paddr )
>> +        panic("%s: first MMIO resource not found\n", node->full_name);
>> +
>> +    aplic.paddr_start = paddr;
>> +    aplic.size = size;
>> +
>> +    aplic.regs = ioremap(paddr, size);
> Doesn't size need to match certain constraints? If too low, you may
> need to panic(), while if too high you may not need to map the entire
> range?
>
> Does paddr perhaps also need to match certain contraints, like having
> the low so many bits clear?

Good question. According to AIA spec:
   4.5. Memory-mapped control region for an interrupt domain
   For each interrupt domain that an APLIC supports, there is a dedicated memory-mapped control
   region for managing interrupts in that domain. This control region is a multiple of 4 KiB in size and
   aligned to a 4-KiB address boundary. The smallest valid control region is 16 KiB. An interrupt domain’s
   control region is populated by a set of 32-bit registers. The first 16 KiB contains the registers listed in
   Table 6

The best what I can do is:
1. Check that the size is a multiple of 4KiB is size and is not less then 16Kib. But nothing I can do with
    the high boundary.
2. Regarding paddr the best I can do it is to check that it is a 4-KiB aligned.

I added the following:
     if ( !IS_ALIGNED(paddr, KB(4)) )
         panic("%s: paddr of memory-mapped control region should be 4Kb "
               "aligned:%#lx\n", __func__, paddr);
     
     if ( !IS_ALIGNED(size, KB(4)) && (size < KB(16)) )
         panic("%s: memory-mapped control region should be a multiple of 4 KiB "
               "in size and the smallest valid control is 16Kb: %#lx\n",
               __func__, size);

Would it be enough?

>> +static struct intc_hw_operations __ro_after_init aplic_ops = {
>> +    .info                = &aplic_info,
>> +    .init                = aplic_init,
>> +};
> Why's this __ro_after_init and not simply const? I can't spot any write
> to it.

It could be const. I added __ro_after_init when I misinterpreted a correct usage of it.
I will return back const instead of __ro_after_init.

>
>> --- /dev/null
>> +++ b/xen/arch/riscv/include/asm/aplic.h
>> @@ -0,0 +1,64 @@
>> +/* SPDX-License-Identifier: MIT */
>> +
>> +/*
>> + * xen/arch/riscv/asm/include/aplic.h
>> + *
>> + * RISC-V Advanced Platform-Level Interrupt Controller support
>> + *
>> + * Copyright (c) Microchip.
>> + */
>> +
>> +#ifndef ASM__RISCV__APLIC_H
>> +#define ASM__RISCV__APLIC_H
> Wants updating again.
>
>> +#include 
>> +
>> +#include 
>> +
>> +#define APLIC_DOMAINCFG_IE      BIT(8, UL)
>> +#define APLIC_DOMAINCFG_DM      BIT(2, UL)
> Why UL when ...
>
>> +struct aplic_regs {
>> +    uint32_t domaincfg;
> ... this is just 32 bits wide?

Agree, BIT(x,U) would be more correct.

Thanks.

~ Oleksii


--------------6NkVv0mXUkRV1V7FI08DK8ty
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    

    
    
    
    
    On 5/22/25 5:26 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 21.05.2025 18:03, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,19 +9,113 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include <xen/device_tree.h>
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/irq.h>
+#include <xen/mm.h>
 #include <xen/sections.h>
 #include <xen/types.h>
+#include <xen/vmap.h>
+
+#include "aplic-priv.h"
 
 #include <asm/device.h>
+#include <asm/imsic.h>
 #include <asm/intc.h>
+#include <asm/riscv_encoding.h>
+
+#define APLIC_DEFAULT_PRIORITY  1
+
+/* The maximum number of wired interrupt sources supported by APLIC domain. */
+#define APLIC_MAX_NUM_WIRED_IRQ_SOURCES 1023

    
      
    Wait - what's "wired" here? There's only MSI you said elsewhere?
    
    
    
    
    This what was mentioned in DT binding:
  riscv,num-sources:
    $ref: /schemas/types.yaml#/definitions/uint32
    minimum: 1
    maximum: 1023
    description:
      Specifies the number of wired interrupt sources supported by this
      APLIC domain.

But 'wired' isn't really mention in AIA spec:
  For each possible interrupt source , register sourcecfg[ ] controls the source
  mode for source in this interrupt domain as well as any delegation of the source
  to a child domain.

So IMO it isn't connected to wired or not interrupts. So ...

    
    
    
      
    
Further - how's this 1023 related to any of the other uses of that number?
Is this by chance ARRAY_SIZE(aplic.regs->sourcecfg)? If so, it wants
expressing like that, to allow making the connection.
    
    
    
    
    ... ARRAY_SIZE(aplic.regs->sourcecfg) perfectly match and will be used instead
of APLIC_MAX_NUM_WIRED_IRQ_SOURCES.


    
    
    
      
    
        
    +static struct aplic_priv aplic;
 
 static struct intc_info __ro_after_init aplic_info = {
     .hw_version = INTC_APLIC,
 };
 
+static void __init aplic_init_hw_interrupts(void)
+{
+    unsigned int i;
+
+    /* Disable all interrupts */
+    for ( i = 0; i < ARRAY_SIZE(aplic.regs->clrie); i++)
+        writel(~0U, &aplic.regs->clrie[i]);
+
+    /* Set interrupt type and default priority for all interrupts */
+    for ( i = 0; i < aplic_info.num_irqs; i++ )
+    {
+        writel(0, &aplic.regs->sourcecfg[i]);
+        /*
+         * 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.
+         */
+        writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i]);
+    }
+
+    writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg);
+}
+
+static int __init cf_check aplic_init(void)
+{
+    dt_phandle imsic_phandle;
+    const __be32 *prop;
+    uint64_t size, paddr;
+    const struct dt_device_node *imsic_node;
+    const struct dt_device_node *node = aplic_info.node;
+    int rc;
+
+    /* Check for associated imsic node */
+    if ( !dt_property_read_u32(node, "msi-parent", &imsic_phandle) )
+        panic("%s: IDC mode not supported\n", node->full_name);
+
+    imsic_node = dt_find_node_by_phandle(imsic_phandle);
+    if ( !imsic_node )
+        panic("%s: unable to find IMSIC node\n", node->full_name);
+
+    rc = imsic_init(imsic_node);
+    if ( rc == IRQ_M_EXT )
+        /* Machine mode imsic node, ignore this aplic node */
+        return 0;
+    else if ( rc )

    
      
    
      
    As before: No "else" please when the earlier if() ends in an unconditional
control flow change.
    
    
    
    
    
      
    +        panic("%s: Failded to initialize IMSIC\n", node->full_name);
+
+    /* Find out number of interrupt sources */
+    if ( !dt_property_read_u32(node, "riscv,num-sources",
+                               &aplic_info.num_irqs) )
+        panic("%s: failed to get number of interrupt sources\n",
+              node->full_name);
+
+    if ( aplic_info.num_irqs > APLIC_MAX_NUM_WIRED_IRQ_SOURCES )
+        panic("%s: too big number of riscv,num-source: %u\n",
+               __func__, aplic_info.num_irqs);

    
    
    
    
    
      
     
    
      
    Is it actually necessary to panic() in this case? Can't you just lower
.num_irqs instead (rendering higher IRQs,if any, non-functional)?
    
    
    
    
    Good point. I think we can just use aplic_info.num_irqs = ARRAY_SIZE(aplic.regs->sourcecfg);


    
    
    
      
    

    
      
    
        
    +    prop = dt_get_property(node, "reg", NULL);
+    dt_get_range(&prop, node, &paddr, &size);
+    if ( !paddr )
+        panic("%s: first MMIO resource not found\n", node->full_name);
+
+    aplic.paddr_start = paddr;
+    aplic.size = size;
+
+    aplic.regs = ioremap(paddr, size);

    
      
    
      
    Doesn't size need to match certain constraints? If too low, you may
need to panic(), while if too high you may not need to map the entire
range?

Does paddr perhaps also need to match certain contraints, like having
the low so many bits clear?
    
    
    
    
    Good question. According to AIA spec:
  4.5. Memory-mapped control region for an interrupt domain
  For each interrupt domain that an APLIC supports, there is a dedicated memory-mapped control
  region for managing interrupts in that domain. This control region is a multiple of 4 KiB in size and
  aligned to a 4-KiB address boundary. The smallest valid control region is 16 KiB. An interrupt domain’s
  control region is populated by a set of 32-bit registers. The first 16 KiB contains the registers listed in
  Table 6

    
    
    The best what I can do is:
1. Check that the size is a multiple of 4KiB is size and is not less then 16Kib. But nothing I can do with
   the high boundary.
2. Regarding paddr the best I can do it is to check that it is a 4-KiB aligned.

I added the following:
    if ( !IS_ALIGNED(paddr, KB(4)) )
        panic("%s: paddr of memory-mapped control region should be 4Kb "
              "aligned:%#lx\n", __func__, paddr);
    
    if ( !IS_ALIGNED(size, KB(4)) && (size < KB(16)) )
        panic("%s: memory-mapped control region should be a multiple of 4 KiB "
              "in size and the smallest valid control is 16Kb: %#lx\n",
              __func__, size);

Would it be enough?


    
    
    
      
    
        
    +static struct intc_hw_operations __ro_after_init aplic_ops = {
+    .info                = &aplic_info,
+    .init                = aplic_init,
+};

    
      
    
      
    Why's this __ro_after_init and not simply const? I can't spot any write
to it.
    
    
    
    
    It could be const. I added __ro_after_init when I misinterpreted a correct usage of it.
I will return back const instead of __ro_after_init.


    
    
    
      
    

    
      
    
        
    --- /dev/null
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * xen/arch/riscv/asm/include/aplic.h
+ *
+ * RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ */
+
+#ifndef ASM__RISCV__APLIC_H
+#define ASM__RISCV__APLIC_H

    
      
    
      
    Wants updating again.


    
      
    
        
    +#include <xen/types.h>
+
+#include <asm/imsic.h>
+
+#define APLIC_DOMAINCFG_IE      BIT(8, UL)
+#define APLIC_DOMAINCFG_DM      BIT(2, UL)

    
      
    
      
    Why UL when ...


    
      
    
        
    +struct aplic_regs {
+    uint32_t domaincfg;

    
      
    
      
    ... this is just 32 bits wide?
    
    
    
    
    Agree, BIT(x,U) would be more correct.

Thanks.

~ Oleksii
    
    
    
  


--------------6NkVv0mXUkRV1V7FI08DK8ty--


From xen-devel-bounces@lists.xenproject.org Tue May 27 15:00:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:00:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998502.1379218 (Exim 4.92)
	(envelope-from )
	id 1uJvnG-000351-FT; Tue, 27 May 2025 15:00:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998502.1379218; Tue, 27 May 2025 15:00: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 1uJvnG-00034u-CA; Tue, 27 May 2025 15:00:42 +0000
Received: by outflank-mailman (input) for mailman id 998502;
 Tue, 27 May 2025 15:00:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJvnF-00034o-Ey
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:00:41 +0000
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
 [2a00:1450:4864:20::430])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5a2a48ce-3b0b-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 17:00:39 +0200 (CEST)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3a4c6c0a9c7so2447774f8f.3
 for ; Tue, 27 May 2025 08:00:39 -0700 (PDT)
Received: from gmail.com (163.red-2-139-141.dynamicip.rima-tde.net.
 [2.139.141.163]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4d0884cabsm9243985f8f.82.2025.05.27.08.00.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 08: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" 
X-Inumbo-ID: 5a2a48ce-3b0b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748358039; x=1748962839; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=EbcGE31liYygPaQlvfT4jgI++U+bqFAoIpuS740Bkik=;
        b=OotDrrKPVy03v42PWnbkb9yYI5UzLqupOLsEUAVy9CvJ5U8IeCpVfOdRr5gh9irxmk
         D1AWwOz31l9f8wmbhYUl/zEOqWm1VSUA9uMxNJy1K3R3EXBOYzNLxsrGUs+sPqpzk7D+
         tnD5kft+RmGhIPD0oTsOa2UP2CTEVip9OU1uqM8IMmiukrrllEIIGLHx1hmct4ZsnFYV
         ZgdP6Jkoc7SJuhMvL7PkV8Tu1YoApIl8iMKbq+JFfh493T4yLGptLJCGzQJwYvmJR8BN
         1eNcRAwDmTkC6HYzE6eccak3zxnZWG9UttX2GN3eZKInbZdNRasLVPU1+F0CUkC51Ch3
         A7uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748358039; x=1748962839;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EbcGE31liYygPaQlvfT4jgI++U+bqFAoIpuS740Bkik=;
        b=ZtiTq2wbEHlGjkCvRFHDWpkOSzbh6/bmmx4K9f+IgAFcnazxExpo2RekP+2yemiTFM
         cF/5tQxvQZmkNN3zZ5tNpl5PlGB0UUDYjIdBRXTFJL1lqb5GJljQdNl+BoprNAq6ikYB
         or9VfjjYBwb9+9WANVly0Y58fOnoyNDLoE2s+xVkZNDgFdpJQG25lYeHw32+3N5WpUs+
         UKJP3UzWMuxxILAttKnknLSWNHDu5nYdX4nhji1M89Nven1RiCLi2Or0GjHIoE7p5rOF
         qSkcMIafOyshML7wbhKj9hwekWBceQzfE8eDNk7+JUPC3/1vO/PWawvwc9ZPhEBeIodz
         q6kg==
X-Gm-Message-State: AOJu0YyTSp7QHQWCqT42Td31WP5P+CbbXJqzWNJJxORFGTC7yLR0JndL
	yhK3Ra8i8hwCfjfoYVkN8oAZOrkYIyF8EOpFbDo+PG+zyPTrbYciGG0+cXTznFc43aE=
X-Gm-Gg: ASbGncvmOzubntl6zLMnIUHzSCEqE72jAuDt4vgHC3jzbJlrj2ZCf7uLj78xUmluOCZ
	AHKISgBO9cc+YuHWFxgQBXvKSIT4HD36VnnAZ9ikZ677197t+i+ee2iNVIi8ShbGevPylQHacnU
	TFzY6bgMJ7LLLIMZgR2TH7zoth8VLcIBFZCVNmafqqN29l4EzXzxkNveKIh8/2kA7DmDLL5Nx4b
	4t+Eg1asvANtVLe8ZblYo6cMY+tK7zsWU4Evw0rbME+HrSmSSdQB4WefE2Jnq7iilWaoRfVFu2X
	RHRu1FI6tEmCTANn6LER/HUMyv8VlZqiTiL0NLf8996q5MNCcQX21jtNrNoeQ5BUK1jMg+3koPQ
	foMwdLB6y6bQlTeAdA69IXv9wlRfARxwGrU1SNGY=
X-Google-Smtp-Source: AGHT+IH15dJpxkf7h50kEGkZNLHlucOkokN10sU+swFjECtylsCGjkGPcaoYMRF9DqmdzO0zdwfXGg==
X-Received: by 2002:a05:6000:2503:b0:3a4:d7b2:4b16 with SMTP id ffacd0b85a97d-3a4d7b24cd5mr6113681f8f.16.1748358037694;
        Tue, 27 May 2025 08:00:37 -0700 (PDT)
Date: Tue, 27 May 2025 17:00:35 +0200
From: Anthoine Bourgeois 
To: Roger Pau Monne 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD 
Subject: Re: [PATCH] x86/hvmloader: fix order of PCI vs MTRR initialization
Message-ID: 
References: <20250527085504.77444-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250527085504.77444-1-roger.pau@citrix.com>

On Tue, May 27, 2025 at 10:55:04AM +0200, Roger Pau Monne wrote:
>After some recent change the order of MTRR vs PCI initialization is
>inverted.  MTRR will get initialization ahead of PCI scanning and sizing of
>MMIO regions.  As a result when setting up MTRRs the MMIO window below 4GB
>will always have the same size, and there will be no window above 4GB.
>This results in malformed and incomplete MTRRs being setup.
>
>Fix by making sure PCI is initialized ahead of MTRR, also add a comment to
>notice the ordering dependency.
>
>Fixes: 2c3dffbaa324 ('tools/hvmloader: Replace LAPIC_ID() with cpu_to_apicid[]')
>Signed-off-by: Roger Pau Monn 

Reviewed-by: Anthoine Bourgeois 


From xen-devel-bounces@lists.xenproject.org Tue May 27 15:03:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:03:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998508.1379228 (Exim 4.92)
	(envelope-from )
	id 1uJvq3-0003fs-RW; Tue, 27 May 2025 15:03:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998508.1379228; Tue, 27 May 2025 15: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 1uJvq3-0003fl-Ou; Tue, 27 May 2025 15:03:35 +0000
Received: by outflank-mailman (input) for mailman id 998508;
 Tue, 27 May 2025 15:03:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJvq3-0003ff-3r
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:03:35 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c21ec47a-3b0b-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 17:03:33 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43cfa7e7f54so27384505e9.1
 for ; Tue, 27 May 2025 08:03:33 -0700 (PDT)
Received: from andrew-laptop.. ([46.149.103.12])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f24b6471sm273166855e9.24.2025.05.27.08.03.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 08:03: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" 
X-Inumbo-ID: c21ec47a-3b0b-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748358213; x=1748963013; 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;
        bh=ztdVfT4mxbj+5WIVFfsMLxndJVFXBgQyRQpEKpBUWUw=;
        b=mD23X3tDxgYLIbxrA6baMxtSkj3iWJqgACi7iCEqiezbGACX12jy7UVNgSWmxM7pB4
         mMf5M4zj+uDh9FmXCvcDkzzoJKBcNLLpvHxhxO9iFmPs0ASmzK4dLJcGD49W9x9yF2/u
         BgMCHR4tmtgsn2Sx1Hx3MerUwEWAIDo1RT8/4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748358213; x=1748963013;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ztdVfT4mxbj+5WIVFfsMLxndJVFXBgQyRQpEKpBUWUw=;
        b=VhGh1BBNpidTvaFMH5yGBm8Iuw7K0CBy15i8rwcD2v2Yv4H+rlaGEyllr5YdXcYY9N
         DQN12fING3yZlftRna858vbkGuoHH/7NhIjiaVL7EDOg1DYd3+VC802rGXIaq/32O+Te
         SSi46CMz72/BbpVC1aUbkPz0Fx5TZ60GnpvNoR+etkivmucUWWC2fsWjsM6UmS5Jpbau
         TAT+dWVWTz80l+d3pa5HoNc05AJfvB+gF+Y0NhD9wb3VMqWMBlVXCOuO/jMN1uUuV8Bx
         452nGsAGJoIkeOI6zVHhtlvI6hotRYILnhr56vGifcq3ao6aydsKyq6W/99Tuod9vAVj
         COWA==
X-Gm-Message-State: AOJu0YyEn+cvt3Q8iAPgptaFBMkOR+w5GkGbyDBUNw4KnVbRuURruFtI
	DUEhgexV/2UEfe6CCx16TaLBbDfI+B+ljOArWUnS1C5tzkQ/Z7nr5hpYIAZIDESXi5Jj2tnHKvk
	0EQZO
X-Gm-Gg: ASbGncuhTeqmbOHpHxPSbWRB7flVZSWzFrHVNAwPMdEprGL4ESk+Y9A+tcIjlVXXWVg
	BioAk2U9YSTwbG5EfKZ51S1mCLg81VJTc4kgGXr9yS5affB+hy0k92XzDSzVqgXhAN8sG69RMiF
	ht5kgfoIOWnA0NvDewrqVVUL2zOoVmJomjQddWWkJhbRa1JrD5zO3BmQiT9DLhy6WAMsRBLH8Lq
	pwhFHCx8Bbqh6eguO0CprSm7tl4S/JyIDRkx4A0sMppyZceRZdUvnFfSX+CoKzT15XZndORhySz
	iBCNvO73hWy8YbhPRAGkWgbDRmyrsbNruZYlwEm+MsyDXbbn5EHfSgkQ+kcjkOg=
X-Google-Smtp-Source: AGHT+IG8HOx/gt8VB9bumc5o8u1nlVH9jDCaITTRPrJJXYfW8RzY/eJFn3rZDzNXzv69KuKhQCH/qw==
X-Received: by 2002:a05:600c:529b:b0:439:8878:5029 with SMTP id 5b1f17b1804b1-44fd1a021c5mr9943355e9.2.1748358212764;
        Tue, 27 May 2025 08:03:32 -0700 (PDT)
From: Andrew Cooper 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/hvm: Drop unused vpic.h includes
Date: Tue, 27 May 2025 16:03:30 +0100
Message-Id: <20250527150330.47108-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It's only hvm.c, irq.c and vcpi.c which need this header, and they all
get it via asm/hvm/irq.h.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/hvm/io.c       | 1 -
 xen/arch/x86/hvm/vioapic.c  | 1 -
 xen/arch/x86/hvm/vmsi.c     | 1 -
 xen/arch/x86/hvm/vmx/intr.c | 1 -
 xen/arch/x86/hvm/vmx/vmx.c  | 1 -
 5 files changed, 5 deletions(-)

diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index de6ee6c4dd4d..23a5ea0e6197 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
index f896b9ea121b..7c725f9e471f 100644
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 61b89834d97d..32e417bc1592 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -38,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index 91b407e6bcc2..b35dc8c586f6 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index c2262c584822..d8879c304e15 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -32,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 15:13:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:13:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998520.1379239 (Exim 4.92)
	(envelope-from )
	id 1uJvzL-0005SY-OB; Tue, 27 May 2025 15:13:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998520.1379239; Tue, 27 May 2025 15: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 1uJvzL-0005SR-KQ; Tue, 27 May 2025 15:13:11 +0000
Received: by outflank-mailman (input) for mailman id 998520;
 Tue, 27 May 2025 15:13:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJvzK-0005SL-Is
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:13:10 +0000
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [2a00:1450:4864:20::330])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 16ab0c25-3b0d-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 17:13:05 +0200 (CEST)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43edecbfb46so32001925e9.0
 for ; Tue, 27 May 2025 08:13:05 -0700 (PDT)
Received: from andrew-laptop.. ([46.149.103.14])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f3814297sm267290705e9.28.2025.05.27.08.13.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 08:13: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" 
X-Inumbo-ID: 16ab0c25-3b0d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748358784; x=1748963584; 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;
        bh=j94w7onphUS7sz4qhPWku28OxN8fikM6yz6LhRbY63o=;
        b=N9ylKvd2c0VBpOcdStEvnUyHNC3ZrW4ji1/J4YgSWKYvIMeJn3otRLKQyelPPvBbji
         x9JnRQ++z0b6EY1nzZ9PWz1RADK9hhIeeiqW4JjesyQ+8j43meOHHW1uZ9mytuARrIgQ
         AKH7BERRktcmfnVxdLiE8gVHtyO7Lk5VT1+eY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748358784; x=1748963584;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=j94w7onphUS7sz4qhPWku28OxN8fikM6yz6LhRbY63o=;
        b=W4Kwq3iJhC4T5NK4UBH2UfF8HiTqCkCQfMr7DmE0nmMofasMgWEzbTAdNlWQmRv5GO
         15F/3EBGOeol5te0vA/pXx9kj3e5Vjb4iBIBgPOCU5FS3XGZL9/yoD5lxOSWhO3SPgy4
         z4rJixBajtPdjeMQ7gfFPe/YYwc61pxS0hghiLmZDq1bwwI5KUOKcqT5EtfmWZp45yic
         2iJAtF6Z4AjKIJYHcqtQbdMaev5Bdhw7OcDjNRC5C8NeHABnw2D+UePkHiHIQB7ZGZMs
         UT8OYGNol6d4Ry2uS4Ma7BUDGd7dX7lUVHd0+7OXjSuVYC30cXeNgvXwdcFOHtZjWNVM
         O1WA==
X-Gm-Message-State: AOJu0YzszKhNqXYIhhPR+1fiOEnv7V7RMNh8Af1NINFQBzGJV9Qgp6Bw
	gBZTokQkCfXQUtYnlxGB/zk25Uw7Imm6cz0kVa0FH6A0ODU4mhpZjJifOTtdbHZ23uP1PESUnNr
	5scSr
X-Gm-Gg: ASbGncvc8B4YBEgdUR2Z1PwKo9ViUh+kp1T1P0MTP7HsG+EKSvrm9ZoiwxBoi+NFdql
	6qVtB3ppbiom9qXTa1eddfF3aADRKS6cj+WCs/c5oIqupfiuC2NtLkkVQM+Hk6AX2J25HjD56BO
	/QCy/JZZbndTtO8Tso8Cx97UWiSmsQ/0v9Gw9hqXDBy9MG7JxWXmeriFAoxnv08h5+LUV+tXRiv
	xryVrEy8QQFB2Heq+1pPq+D+AuDJ6nfh1t3ltH26LhxKwam5Zjr53hZJPMi0DzeXNIelFbuzSqc
	U6/CrMMBk9G43PfcNlMUdBZW6RsPdxO8ugfTE+ASvmu1Cl0H0tol/MR4EUlpjUYrPYcNX3XpTQ=
	=
X-Google-Smtp-Source: AGHT+IFLRNQEy389P7KNUH3D8z2W+kmnsMWaDHTO7Id/8dggQ27ARvWdkGcAPNr1t2FMqgWR0uB4HA==
X-Received: by 2002:a05:600c:5494:b0:442:f44f:678 with SMTP id 5b1f17b1804b1-44c94c2afafmr124240215e9.31.1748358784159;
        Tue, 27 May 2025 08:13:04 -0700 (PDT)
From: Andrew Cooper 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/setup: Trim includes
Date: Tue, 27 May 2025 16:13:02 +0100
Message-Id: <20250527151302.63291-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

None of these are used by setup.c today.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/setup.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1f5cb67bd0ee..4181df97754a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -3,14 +3,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -25,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -36,12 +32,10 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -62,7 +56,6 @@
 
 #include 
 
-#include 
 #ifdef CONFIG_COMPAT
 #include 
 #include 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 15:14:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:14:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998528.1379248 (Exim 4.92)
	(envelope-from )
	id 1uJw0m-0005z8-0t; Tue, 27 May 2025 15:14:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998528.1379248; Tue, 27 May 2025 15: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 1uJw0l-0005z0-UC; Tue, 27 May 2025 15:14:39 +0000
Received: by outflank-mailman (input) for mailman id 998528;
 Tue, 27 May 2025 15:14:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJw0k-0005ys-4m
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:14:38 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4da3cf0f-3b0d-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 17:14:37 +0200 (CEST)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-32a6a1a5f6dso13814301fa.1
 for ; Tue, 27 May 2025 08:14:37 -0700 (PDT)
Received: from andrew-laptop.. ([46.149.103.10])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f6b297easm284079475e9.6.2025.05.27.08.09.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 08:09:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4da3cf0f-3b0d-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748358876; x=1748963676; 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;
        bh=VCodU9jGR8msSOdWdi9DvFF2loiFVgvwENQEVsCaS+Q=;
        b=M02Uhd4IE0pyOuu5zyosxBF+Gm+Ln2p0ShyJc160sKFdDMJ3Kbkiwh2+P7tS3ybfx0
         x3GsScoAq9F4VGqP5TUVXCoeWBqcdR3nzlr78JddLVuKesx9MXK8HhlBSi3OY4Q3ZmoE
         3nbHra12K5mnTqToJBB3O8pd76NDIbhNv5ylo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748358876; x=1748963676;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=VCodU9jGR8msSOdWdi9DvFF2loiFVgvwENQEVsCaS+Q=;
        b=IvWrsLeTA0Vcn5Tz6kaagVgba1udShSWWdcFHJOdFEDbS33XAoFNfMM/6/556ZMf58
         DuIFJV/Kpef9xrJZY6gQfejQo85v7jxin2trtsC7oF1z+8uWkGUu/rjzorZ5ms/pWvqG
         nSuGZdKa0owBmRc1i/wB6Lyd5x4F9INC8O4FEmxjbuYHR+z7k2OtyiE94M8dgjdZBo9n
         KWQoFCs8rsbZ0O/UDCPfvBbMiJVIYk4jq/EeCCO5m/YjXxaXtSWb7+uNVeLzvrzmSWFE
         wnl2f2M/9KuY9uDPMhSUj9Y/8BNNtB6aFmz0d1ULzHRPOxfw+7ciMPaYRVTAeAqGPdyJ
         GIeQ==
X-Gm-Message-State: AOJu0Yy8067Tyu1RXG6L64LcT+IrYyF5AsXVx4AGTiBsOmbwgckp0S0p
	rxI9+dS7DZF5iU3iESdUpCwBWI/AZmKz0KXvpK6FnRFhhDiZd4kG5t66Z4sSSb9/uAehufGdju5
	m0kHQ
X-Gm-Gg: ASbGncus2CKo7oPsh8tH6jucK5N5Z9ufLNzgy9e8WZlPDqHnu//Jz3/y6OBaVD76Cye
	lUm2YrEYJ+W7bhY6c3u3oEH8k9m6ev1uXU/NMoU5wAutj46Mhnknhkj+oRTXLVm8CQ3zUndPqq/
	EmCboxmcYe5BwpkKHgSh0hMy7uy9iEyV4U+tx31cRjvFyAW/A7uQbtwUoVhOyYsNF5JRk+X4fBM
	gfv6v9CwgWvPjfeyQz20bW+tJA+XnK585ngqog59gxGYL/7xprwVCE2UdITnumOfJZ6vA1SvgRs
	BiItMDoln0jCsKAw/7g+wRWKOTyhzOTmymlrdKpJZ1psA+poSBH4tlafCXvyd08=
X-Google-Smtp-Source: AGHT+IEE0z3ChNgO7reWEl9PjWTRTVrymGJ9o8Pf7TWX7UgdKFl3SosYdL2qFcqTl3g3B/KWjdYJzw==
X-Received: by 2002:a05:600c:3f07:b0:44a:4fe3:3a28 with SMTP id 5b1f17b1804b1-44c916fc5bamr104120465e9.1.1748358553822;
        Tue, 27 May 2025 08:09:13 -0700 (PDT)
From: Andrew Cooper 
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/traps: Trim includes
Date: Tue, 27 May 2025 16:09:11 +0100
Message-Id: <20250527150911.59744-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

None of these are used by traps.c today.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

I'm experimenting with include-what-you-use but it's not the most
ergonomic of tools to use.

xen.git/xen$ wc -l arch/x86/traps-{before,after}.i
  29647 arch/x86/traps-before.i
  25355 arch/x86/traps-after.i
---
 xen/arch/x86/traps.c | 25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index f9e17e015947..092c7e419748 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -17,47 +17,25 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
 
-#include 
-
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -70,10 +48,7 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
 
 /*
  * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue May 27 15:19:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:19:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998538.1379258 (Exim 4.92)
	(envelope-from )
	id 1uJw5W-0006Zp-Fc; Tue, 27 May 2025 15:19:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998538.1379258; Tue, 27 May 2025 15: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 1uJw5W-0006Zi-Cj; Tue, 27 May 2025 15:19:34 +0000
Received: by outflank-mailman (input) for mailman id 998538;
 Tue, 27 May 2025 15:19:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJw5V-0006Zc-2f
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:19:33 +0000
Received: from fhigh-a2-smtp.messagingengine.com
 (fhigh-a2-smtp.messagingengine.com [103.168.172.153])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f888c1c8-3b0d-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 17:19:24 +0200 (CEST)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 62D221140193;
 Tue, 27 May 2025 11:19:23 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Tue, 27 May 2025 11:19:23 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 27 May 2025 11:19:22 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f888c1c8-3b0d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1748359163;
	 x=1748445563; bh=XuWySyI/piapIHyfe2ibu0ahhtanbL1ez1d4vkonc2E=; b=
	XWSRd9vFiC56rLUyDckiAYWLqNCeksX4yIXRMPLJIrXMzaT00hkdBrn4Y2Aslaf3
	0D+Jh+RDse2V5uPdFdcAfY7GB9CTLh6ETX92PYSjnG8/SIv/f4nadfioR9gD7s9i
	IL0/Rf1H6Nw9x1n0Me08Vph7bBIki/76wawPtFrWXweDOzmFkBq59OJfrW8cuf2C
	Kd0oL710kIOquwhLpIEfrJrmHF3uXuYGZfRG38Bbio4nU9JUbNkmn2uQA4mzBVWh
	svqe9JekaxqfplmcjO8dJQFgT0Hntlk97H88OeX0DDOQP6cH4pzHgD3rQl6GxYE+
	BCfOnsaptHUztcNIm7JNWg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
	1748359163; x=1748445563; bh=XuWySyI/piapIHyfe2ibu0ahhtanbL1ez1d
	4vkonc2E=; b=dQ15MJ6Bm/diuFsEiaKRWBWHBNKI0FdbD4N3odohCueuNLjVN5P
	QCRx7CpMVYX8gFHT1Q+PJ/3sGlbhHQ8olh8laz/7wcXKt3WAYoFXqGCFY2S5c8SR
	dtL4d17FyeDTwi/gLAJwaIPZSFoYAZf+Xb2rtUz9Uiu91WuKjgrb/YXXpYOd6hrL
	60+UaZOyDOZY6vt1BseINenSuLMrS+SAB7eAYR9WeIz+wU3pZww+ANQskVXdIZDB
	Cqk+a2j5IRNFHPuDgZb2HVqaT8jc93QzO/kOvRH/36rwmPDjp25FeQgX8CGB+6e5
	TxVxp+9HDVauXpsj6SeHzsVF0MaFd5w4g5g==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvtdejvdculddtuddrgeefvddrtd
    dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
    fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
    dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhf
    gggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucforghrtgiihihkohifsh
    hkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhg
    shhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgudelteefvefhfeehieetleeihf
    ejhfeludevteetkeevtedtvdegueetfeejudenucevlhhushhtvghrufhiiigvpedtnecu
    rfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthh
    hinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeehpdhmohguvgepshhmthhpohhu
    thdprhgtphhtthhopegrnhhthhhonhihseigvghnphhrohhjvggtthdrohhrghdprhgtph
    htthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthht
    ohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtg
    hpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohep
    mhhitghhrghlrdhorhiivghlsegrmhgurdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 27 May 2025 17:19:19 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Anthony PERARD 
Cc: Andrew Cooper ,
	Xen-devel ,
	Stefano Stabellini ,
	Michal Orzel 
Subject: Re: [PATCH 2/3] CI: Use bash arrays to simplfy dom0 rootfs
 construction
Message-ID: 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
 <20250522173640.575452-3-andrew.cooper3@citrix.com>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="mntzzDVDpcy+dZNG"
Content-Disposition: inline
In-Reply-To: 


--mntzzDVDpcy+dZNG
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 May 2025 17:19:19 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Anthony PERARD 
Cc: Andrew Cooper ,
	Xen-devel ,
	Stefano Stabellini ,
	Michal Orzel 
Subject: Re: [PATCH 2/3] CI: Use bash arrays to simplfy dom0 rootfs
 construction

On Tue, May 27, 2025 at 04:01:34PM +0200, Anthony PERARD wrote:
> On Thu, May 22, 2025 at 06:36:39PM +0100, Andrew Cooper wrote:
> > For Qubes, this requires switching from sh to bash.
> >=20
> > This reduces the number of times the target filename needs to be writte=
n to 1.
> >=20
> > Expand the comment to explain the concatination constraints.
>=20
> Isn't the correct spelling "concatenation"? Same for the two comments.
>=20
> >=20
> > No functional change.
> >=20
> > Signed-off-by: Andrew Cooper 
> > ---
> > I would like to find a slightly nicer way of conditional parts, but not=
hing
> > comes to mind.
>=20
> Well, one way I can think of is having a new variable which can carry
> the rootfs part associated with a particular test, then that variable
> can be updated at the time we configure for that test. Something like:
>=20
> # init
> declare -a append_rootfs_part
> # or append_rootfs_part=3D() is probably fine too.
>=20
> case $test in
>   argo)
>     append_rootfs_part+=3D(argo.cpio.gz)
>     # ... other test configuration
>     ;;
> esac
>=20
> # Dom0 rootfs
> parts=3D(
>     rootfs.cpio.gz
>     xen-tools.cpio.gz
>     "${append_rootfs_part[@]}"
> )
>=20
> And that should works fine, even if there isn't any extra rootfs part.

That would work for compressed parts, but not for uncompressed - which
need to come before all compressed. But maybe there could be two arrays
- one for uncompressed and another for compressed? Then, each could be
extended anywhere, without messing the order.

>=20
> > diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qu=
bes-x86-64.sh
> > index 10af274a0ba7..1dd3f48b3d29 100755
> > --- a/automation/scripts/qubes-x86-64.sh
> > +++ b/automation/scripts/qubes-x86-64.sh
> > @@ -187,10 +187,14 @@ Kernel \r on an \m (\l)
> >      rm -rf rootfs
> >  fi
> > =20
> > -# Dom0 rootfs
> > -cp binaries/ucode.cpio binaries/dom0-rootfs.cpio.gz
> > -cat binaries/rootfs.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> > -cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> > +# Dom0 rootfs.  The order or concatination is important; ucode wants t=
o come
>=20
>                              ^ of concatenation
>=20
> Same typo in the other comment.
>=20
> Beside the typo, patch looks fine:
> Reviewed-by: Anthony PERARD 
>=20
> Thanks,
>=20
> --=20
> Anthony PERARD

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--mntzzDVDpcy+dZNG
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmg11/gACgkQ24/THMrX
1ywIYQf+O4V/eZf4NybbLa8AHCV4k3IC5q+26rMH8M1HkFV/gY0ZZ/SS5A8OJszZ
CKzIvbh3QIF7pfBgqjrkpn5HI+smtLULjLZlGWRngR9XkBg60wsFI++2wxlf1swj
HKi8AJIEkI2eEKOMPTl19hlMPoPoJoehEb9D+atyn3ZG5tlXG8wkoBna4lkDdNwt
r+vjdxxPipthxOShBeoa5zsNftEYTxxQd9HVCQnIjcl/6+BdIRfrwpC6PU5lF6Go
+QcBGzAvaLtHWaJx/BztRmGRiLENX1dbkBNQOoki9mYjxPksHwXuqNPZyAhyc5pq
Ztwo59gDy9J6a/MVxEi7McqyabfSIA==
=bpg8
-----END PGP SIGNATURE-----

--mntzzDVDpcy+dZNG--


From xen-devel-bounces@lists.xenproject.org Tue May 27 15:25:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:25:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998549.1379268 (Exim 4.92)
	(envelope-from )
	id 1uJwAp-0008Ta-4V; Tue, 27 May 2025 15:25:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998549.1379268; Tue, 27 May 2025 15:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJwAp-0008TT-12; Tue, 27 May 2025 15:25:03 +0000
Received: by outflank-mailman (input) for mailman id 998549;
 Tue, 27 May 2025 15:25:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJwAo-0008TN-KF
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:25:02 +0000
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com
 [2607:f8b0:4864:20::735])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c18869d9-3b0e-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 17:25:01 +0200 (CEST)
Received: by mail-qk1-x735.google.com with SMTP id
 af79cd13be357-7c559b3eb0bso202905685a.1
 for ; Tue, 27 May 2025 08:25:01 -0700 (PDT)
Received: from [10.81.43.171] ([46.149.103.10])
 by smtp.gmail.com with ESMTPSA id
 af79cd13be357-7cd468cb4e0sm1733995285a.91.2025.05.27.08.24.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 08:24: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" 
X-Inumbo-ID: c18869d9-3b0e-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748359500; x=1748964300; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=xvHAl8YUlbeq9ZsDMffJsYnLgyhpPHQc2K2St+lVIl0=;
        b=o5Gz3YJD/pLSlh6aslwK7KSut/AOCekTPW920fRSdMGnFkJHF3ewdB+W7JpMCy919q
         9E7uavJtdgiaa6qCR9r24kbfYvbbtLVYjnvjeRi8zuHuyV2q30CkkNGogKOm/eb41eH/
         j6kGBTOXHIZUFrBwm1nSEl/64a/kXzmKABWMM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748359500; x=1748964300;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=xvHAl8YUlbeq9ZsDMffJsYnLgyhpPHQc2K2St+lVIl0=;
        b=cgBlk8WY8tgJbmr1IWboNwWp81r/rHR4JDWbRzAXS69wL2Nk9Vp3D8BM1i68uFzGgo
         +RSSBaZ0P27sX+tRu558cHhjQHULagzq8+hvKM2HNZW/qpypBTNBWPi7mjQT7KD41F++
         OGgUEWoRf3FnTIBeon3PYv3Cd+bswKyZLhUHO9rf6LLJ6JZqluhvOnMRRd2/N1yKoP9K
         ZF8GpPIvtZfdJPMBTz+b/3tPgZ3xQaLi36Q9L7EeYTcShYsFWs9kL6dWrPnFTWr0oL40
         Z6nAouXt+7h4m0jHxvBzJSZDBceKBlzF7fYJ4/oZFtSb6TJH4AJ4HCVkFg04x3bjYeWj
         ZRRg==
X-Gm-Message-State: AOJu0YyQWIqWBGMs07nt9+mfYfxe89FbtcdPmjSG7j6LhzSuz2FeGA7P
	S9rX+jAWMuSwzIzPgPl7Cb3xWpDdcK4eM4095LLQGLJ1WWst4yYPpSy7ikDDAP2ZX3g=
X-Gm-Gg: ASbGncuvqzSapHuZMhkHJSiZIQ7pc8DJVI3FPmL2TGvQ2e+h1KaUxkwG+raZgSjHjuO
	VxBy1BqxBnJ2/iYsdT9QbrpmDR4ClLMFanB1ZCdwpcgGeNLeG4AEJkeZowMaUyjT3tpP510M4sp
	TUmi0ibHUclQn6ff630b7gjARMxFiHI+NWzAvq78CWsg+prnU9LRdvQJ5TKQNPXfoFAjfNfENUF
	kywK2Y1XH5wD54jr2yak0ZlzZIA/TsKoJYDZvCigXlWWoVXacaD3uUF1h7PhMm9ceq3uV1b6rrl
	0MyC1kF3k4uAPYX1+zk+WTYFv1rSVlmxsC9GS6wDqk2DbWqDrV1J6eoEEtzWBA==
X-Google-Smtp-Source: AGHT+IFK2G0n2BxBtCRpvhJ511swp0KxHtzJIrD+n/H5SdZ0rkk6FE8dM+HdZ1yNh2wn558/JvHn8w==
X-Received: by 2002:a05:620a:4482:b0:7ca:f09d:1473 with SMTP id af79cd13be357-7ceecb95b11mr1730610585a.28.1748359500392;
        Tue, 27 May 2025 08:25:00 -0700 (PDT)
Message-ID: 
Date: Tue, 27 May 2025 16:24:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/3] CI: Use bash arrays to simplfy dom0 rootfs
 construction
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Anthony PERARD 
Cc: Xen-devel ,
 Stefano Stabellini ,
 Michal Orzel 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
 <20250522173640.575452-3-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

On 27/05/2025 4:19 pm, Marek Marczykowski-Górecki wrote:
> On Tue, May 27, 2025 at 04:01:34PM +0200, Anthony PERARD wrote:
>> On Thu, May 22, 2025 at 06:36:39PM +0100, Andrew Cooper wrote:
>>> For Qubes, this requires switching from sh to bash.
>>>
>>> This reduces the number of times the target filename needs to be written to 1.
>>>
>>> Expand the comment to explain the concatination constraints.
>> Isn't the correct spelling "concatenation"? Same for the two comments.
>>
>>> No functional change.
>>>
>>> Signed-off-by: Andrew Cooper 
>>> ---
>>> I would like to find a slightly nicer way of conditional parts, but nothing
>>> comes to mind.
>> Well, one way I can think of is having a new variable which can carry
>> the rootfs part associated with a particular test, then that variable
>> can be updated at the time we configure for that test. Something like:
>>
>> # init
>> declare -a append_rootfs_part
>> # or append_rootfs_part=() is probably fine too.
>>
>> case $test in
>>   argo)
>>     append_rootfs_part+=(argo.cpio.gz)
>>     # ... other test configuration
>>     ;;
>> esac
>>
>> # Dom0 rootfs
>> parts=(
>>     rootfs.cpio.gz
>>     xen-tools.cpio.gz
>>     "${append_rootfs_part[@]}"
>> )
>>
>> And that should works fine, even if there isn't any extra rootfs part.
> That would work for compressed parts, but not for uncompressed - which
> need to come before all compressed. But maybe there could be two arrays
> - one for uncompressed and another for compressed? Then, each could be
> extended anywhere, without messing the order.

Hmm, two might work, but they surely need to not be quoted when forming
parts=(), or having multiple entries will go wrong on the eventual cat
command line.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 27 15:26:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:26:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998558.1379278 (Exim 4.92)
	(envelope-from )
	id 1uJwCT-0000ZF-E4; Tue, 27 May 2025 15:26:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998558.1379278; Tue, 27 May 2025 15: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 1uJwCT-0000Z8-BE; Tue, 27 May 2025 15:26:45 +0000
Received: by outflank-mailman (input) for mailman id 998558;
 Tue, 27 May 2025 15:26:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJwCS-0000Yz-Mq
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:26:44 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id febdff96-3b0e-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 17:26:44 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-6045a8a59c5so4893175a12.1
 for ; Tue, 27 May 2025 08:26:44 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6049d482cc7sm3442712a12.19.2025.05.27.08.26.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 08:26:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: febdff96-3b0e-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748359603; x=1748964403; 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;
        bh=f4zPih8KENWeN6thgWYfkXf1bdKX5fZSG2XUP/lLAmM=;
        b=JVxG5UyN7598WqrTAhpnPygHJx6WJRwNG00yKaEGcWDZ1Cvht2Ef7h7GyyseD6IEmn
         hp8W+4Du1DQRB6nqdQVS63Bz0kkpILSPmz4T4aETosJ9/4XjwWczIa6t3gYsayfaSiA7
         UttYhYHqgxQMBxCfbnPGkHOLZTaPv77Pqgka8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748359603; x=1748964403;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=f4zPih8KENWeN6thgWYfkXf1bdKX5fZSG2XUP/lLAmM=;
        b=bQzs7XjjHS0gwp3PBDHVl31Y2p/9k8S7WYMsils5+fSvo+iIh80sdWiCMvZBceprqJ
         fOS/wS3OhR8SW1YlnsSc07dgZeXqSLlKOyEd2McwaqZJzodQ3Ja4SVhCXtoWU228NAAV
         PnWmwGjz95jNqnSDmu/xOd+DRbre1vjlwisyRcn2vjn1ptDSJzg7HGSB2KajSbw3I3Sk
         PG2eDwnI8Sj/3IT588CveJgxkWQoqW8YrQo2qBluqzGBiXk/AeUhGP/kyRARce/pUAFA
         zsijRoXBk90zOhMfbYnMBlKYO+hH6EdNjBOukpYSurF3qw3xzg3U7RMXqO1xh5P5hLpZ
         dUyA==
X-Gm-Message-State: AOJu0Yyr3g+own8hKnWDBVL9Cfnoj03UMyd28DgPUSXlwX/SxyxbSyk+
	YF9AzBFm2HJtCR/joZX3/xA67qn49T1pCPpFYev+JvbcWIVJ9fX0rmEzMCLnJwQIBShT4PVIRD8
	yB/I=
X-Gm-Gg: ASbGncuv0v580YjEhnSlkBc+1fxRbQ5z2kPNqIzK1MLEWkvUzA3wyAOoZbm2RCGuL/+
	U0scYQK5PrIogflcDnBoKATceIN17sNsWLeZxMKPW5SaaNt8QiTyUs6TLOOQrp7MQUxORGzk95h
	e3QcGSrjIO/NdBtDAdjpSVEJS+46AM7PyASD3PSp7574WDi3YnnRaSep0lD6fBs2/agsCYfFK4/
	GEqGBAhv7OHCcyD1gPXAE767WK4gzuWbI5zchLEnDqwBoBIwJqq7SDk8U1TWolYijpAtxD6hW+A
	tItOk2fMvndaaFvLhXvPY+mSRgNORTYfYQ71TNDf8ENVk/yz42KEcqyKiH5gBt+f0i52/U+S6Rn
	gkis7KDE/N6KF7CcE8cx6
X-Google-Smtp-Source: AGHT+IGONYKqkGAr2A7Y4JQSqqgb3WyFAgxXEN/mVswVccTduaodlntO6/Or2lsSZQ3Pmb7GNWhySA==
X-Received: by 2002:a17:907:7288:b0:ad8:9a3b:b274 with SMTP id a640c23a62f3a-ad89a3bb390mr67755766b.52.1748359602951;
        Tue, 27 May 2025 08:26:42 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Juergen Gross 
Subject: [PATCH v3 0/5] pmstat interface fixes
Date: Tue, 27 May 2025 16:26:30 +0100
Message-ID: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Clarify and fix usage of the pmstat hypervisor and tools interfaces
regarding sizes of buffers passed in.

Ross Lagerwall (5):
  x86/pmstat: Check size of PMSTAT_get_pxstat buffers
  public/sysctl: Clarify usage of pm_{px,cx}_stat
  cpufreq: Avoid potential buffer overrun and leak
  libxc/PM: Ensure pxstat buffers are correctly sized
  libxc/PM: Retry get_pxstat if data is incomplete

 tools/libs/ctrl/xc_pm.c       | 21 +++++++-------
 tools/misc/xenpm.c            | 48 ++++++++++++++++++++-----------
 xen/drivers/acpi/pmstat.c     |  7 +++--
 xen/drivers/cpufreq/cpufreq.c |  3 +-
 xen/include/public/sysctl.h   | 54 +++++++++++++++++++++++++++--------
 5 files changed, 90 insertions(+), 43 deletions(-)

-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 15:26:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:26:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998559.1379288 (Exim 4.92)
	(envelope-from )
	id 1uJwCX-0000oB-KX; Tue, 27 May 2025 15:26:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998559.1379288; Tue, 27 May 2025 15: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 1uJwCX-0000o4-HZ; Tue, 27 May 2025 15:26:49 +0000
Received: by outflank-mailman (input) for mailman id 998559;
 Tue, 27 May 2025 15:26:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJwCW-0000Yz-71
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:26:48 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 011ee120-3b0f-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 17:26:47 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-603fdd728ccso5129860a12.2
 for ; Tue, 27 May 2025 08:26:47 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6049d482cc7sm3442712a12.19.2025.05.27.08.26.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 08:26: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" 
X-Inumbo-ID: 011ee120-3b0f-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748359607; x=1748964407; 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;
        bh=qTriMCUpsmVzD3Jivpx0DCt9g1tummWqKXoec3hAy9A=;
        b=gXnb4CsWQqhjfuAPOKpuGa3LrOWxPjlU0tx4QjfbpqirRKIyrl6VtyKPmv4BQISD2m
         MzRafvAq2FRv6qjC32W6gCYQzubiCw5OYDxdV392YBgNEnXbbvdWGiT0OZc02x5EBO3Z
         PVzB8NGBDDDj9kBCqAh0a3yYRxBiSOwgWK+fc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748359607; x=1748964407;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=qTriMCUpsmVzD3Jivpx0DCt9g1tummWqKXoec3hAy9A=;
        b=jEF/WuVuk3ZUS5EFR+b1P75/8LWWPxIDLMpmOMU+ko5/jUSGycfDMr+h6olwrxjUKd
         +3bS/bvNQEb47nDT+JiiyCCcFMHl6+e2jrkm3WwYSqIQmvqxPBgyEFVSpsLhkXfvw+ja
         hPxnpef1M1/rl/o1dkroZhKM1BiUPC1l3RF4Q9JpTmwsi7pzaJws5JZuFD6um5AeB7j1
         RzbkQ7utOsatsjy0qdqiYg3fP/LXShu+trSMUhNEKjSTxVtCHsL5AL3Q2rHCjwI6eDiv
         +0vLD5pQKVH4WGjnH9Ic+o6uo2APW6Es+C/Im5BT1Qe1JIR7ko3FtcmwKV6OvRuxHjpz
         +qYw==
X-Gm-Message-State: AOJu0YwkGMMVbvNMAZXHyozvKPeYoSeyUdsJcr0fzMjaauMCofIqcHDJ
	SvqwsQe3NHfGPPy4D3OhHJWBdGt3zi2cesNt5u7t0+cOwD+MO+QNUIvx93+djULg3/ANCJgtSHJ
	zOe8=
X-Gm-Gg: ASbGnctepFZWtoq+sWix6w4DvuGZG7+HOKZWP4zbWACxoUc9lvLXPu+4Y1U6l0B03LN
	QEBG2i1yco+TBokKRBVcJDuzuSHeyNkhvQJuDmVPUUwg2ALzItiTjARuaqkD+Pwvs86J3GelR3d
	LXKFsG9Maez1/ko37ultR88KW06XxBxdYIRg8xc6TmMM63H8ueUiJrMqBUpmU8krChbAPpsz1a8
	OphVltAp0srYq7Hm3JhURuIOTK/AI40jOYv9NgWASc4KVXuLPXz+56Mu/Z1glJpEzZ813ZZXQCY
	OFKE8N3JKIhITw4v6CyWRTg9c3Xe1fUjkI46adiMj8UsHJlYidGkuzWLOsKUQJXYm/fuVxqRx1Q
	=
X-Google-Smtp-Source: AGHT+IGPiRyn9Jyzp+w5FlpiZc0eFrl84dMxOvxZYx6V5NsGForpQSY6lEG2moiGtlnV3uaoTQHBYQ==
X-Received: by 2002:a05:6402:520b:b0:604:e33f:e5ac with SMTP id 4fb4d7f45d1cf-604e33fe6efmr4416878a12.2.1748359606947;
        Tue, 27 May 2025 08:26:46 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 2/5] public/sysctl: Clarify usage of pm_{px,cx}_stat
Date: Tue, 27 May 2025 16:26:32 +0100
Message-ID: <20250527152635.2451449-3-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
References: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Suggested-by: Jan Beulich 
Signed-off-by: Ross Lagerwall 
---

In v3:

* Moved some changes to patch 1
* Clarified some comments

 xen/include/public/sysctl.h | 39 +++++++++++++++++++++++++++----------
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 906a3364fbd9..b1e3a48194d8 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -221,9 +221,9 @@ struct pm_px_stat {
      * OUT: total Px states (PMSTAT_get_max_px, PMSTAT_get_pxstat)
      */
     uint8_t total;
-    uint8_t usable;       /* usable Px states */
-    uint8_t last;         /* last Px state */
-    uint8_t cur;          /* current Px state */
+    uint8_t usable;       /* OUT: usable Px states (PMSTAT_get_pxstat) */
+    uint8_t last;         /* OUT: last Px state (PMSTAT_get_pxstat) */
+    uint8_t cur;          /* OUT: current Px state (PMSTAT_get_pxstat) */
     /*
      * OUT: Px transition table. This should have total * total elements.
      *      As it is a 2-D array, this will not be copied if it is smaller than
@@ -235,14 +235,33 @@ struct pm_px_stat {
 };
 
 struct pm_cx_stat {
-    uint32_t nr;    /* entry nr in triggers & residencies, including C0 */
-    uint32_t last;  /* last Cx state */
-    uint64_aligned_t idle_time;                 /* idle time from boot */
-    XEN_GUEST_HANDLE_64(uint64) triggers;    /* Cx trigger counts */
-    XEN_GUEST_HANDLE_64(uint64) residencies; /* Cx residencies */
-    uint32_t nr_pc;                          /* entry nr in pc[] */
-    uint32_t nr_cc;                          /* entry nr in cc[] */
     /*
+     * IN:  Number of elements in triggers, residencies (PMSTAT_get_cxstat)
+     * OUT: entry nr in triggers & residencies, including C0
+     *      (PMSTAT_get_cxstat, PMSTAT_get_max_cx)
+     */
+    uint32_t nr;
+    uint32_t last;  /* OUT: last Cx state (PMSTAT_get_cxstat) */
+    /* OUT: idle time from boot (PMSTAT_get_cxstat)*/
+    uint64_aligned_t idle_time;
+    /* OUT: Cx trigger counts, nr elements (PMSTAT_get_cxstat) */
+    XEN_GUEST_HANDLE_64(uint64) triggers;
+    /* OUT: Cx residencies, nr elements (PMSTAT_get_cxstat) */
+    XEN_GUEST_HANDLE_64(uint64) residencies;
+    /*
+     * IN: entry nr in pc[] (PMSTAT_get_cxstat)
+     * OUT: Required size of pc[] for all known to Xen entries to be written
+     *      (PMSTAT_get_cxstat)
+     */
+    uint32_t nr_pc;
+    /*
+     * IN: entry nr in cc[] (PMSTAT_get_cxstat)
+     * OUT: Required size of cc[] for all known to Xen entries to be written
+     *      (PMSTAT_get_cxstat)
+     */
+    uint32_t nr_cc;
+    /*
+     * OUT: (PMSTAT_get_cxstat)
      * These two arrays may (and generally will) have unused slots; slots not
      * having a corresponding hardware register will not be written by the
      * hypervisor. It is therefore up to the caller to put a suitable sentinel
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 15:26:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:26:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998560.1379298 (Exim 4.92)
	(envelope-from )
	id 1uJwCZ-00013O-RN; Tue, 27 May 2025 15:26:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998560.1379298; Tue, 27 May 2025 15: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 1uJwCZ-00013D-OT; Tue, 27 May 2025 15:26:51 +0000
Received: by outflank-mailman (input) for mailman id 998560;
 Tue, 27 May 2025 15:26:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJwCY-0000Yz-8P
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:26:50 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 024560e4-3b0f-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 17:26:49 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-604bf67b515so3630672a12.0
 for ; Tue, 27 May 2025 08:26:49 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6049d482cc7sm3442712a12.19.2025.05.27.08.26.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 08:26: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" 
X-Inumbo-ID: 024560e4-3b0f-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748359609; x=1748964409; 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;
        bh=AAAB6Ax8rjWfGs7QV2koFNVF7HO+1ITwf906wvazW68=;
        b=dZ4Awufab2w/KJq4Rdzh1jIMy+U/lig1k9ldY0Jj0Qm/k/78tu7YyydLTNjVTsJADw
         wZpoIiTtpmdauBmwloznPR7VkkDrGNqavPlRzjuO4vu3ZfB3CoytM1cAS3vNaThYi5Ll
         WFEP/lI4O12hgp9RjNYP2Sza+RuYpUnHe0Hto=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748359609; x=1748964409;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=AAAB6Ax8rjWfGs7QV2koFNVF7HO+1ITwf906wvazW68=;
        b=rvw7vzvN3vTNGl48sfo5skcJ/1cZ2Kxsec1R0RB9B/vwOWuMB0hrAFIZf9Ulv0GMSF
         Jy+ZhFcq0XW/Ym/N8Tx7C8FHg3naC1M2uiZe9JObzvIeB28XqLxjhCWGXw/B9cvqB1db
         1HQm2KKpcMuJxTnC1MyzztFpXQllct823uJahb/vVZlU3eGtaL23RNVfvCmdbKwqoBGX
         hdeXvlrR7c7qVOlsCj1qcXwn7GOfu8W44BqoJwICP+nVo0TcCe6zv5stewUyVPs6WZCH
         AwN4T6e+zgjqRCi58EkeghpMITxbQDVfAruNazLQjCzP3IrXmYUYn22Cof6oI7632RTo
         UjmA==
X-Gm-Message-State: AOJu0YzB/8oI7tx7TiUvxm1QU1yvyKYWEUuVm25P9uCMF7Pj2JnAiww2
	4szIcXAccHqKPoWMwX6xI3ckxTLElX2HAn1ZCHKgcJgy1qpI3ceQye/XUoPmRbTRjYjkfjBrkg9
	xGos=
X-Gm-Gg: ASbGnctSb9GGO2yzY/nK7JSQBqY3sKfN1vJbSBZiDHadpvXlMyc1DUTCyE3py2mmVNh
	0fxwBjnJ9TUH2G+BZmfOfyVfSROh81L+GfSoBLfwFgaj/QYYtipq+sDP2+u4WNR7N+JNjtka5+Q
	6r7BIkHxPG8kzsBKr2dcy54li2xV4lxtNFn+9O7Ye4yKHTCzyVzsD9HE7Tj399wZGGr0yZ7MKDx
	sIaCpfKftnUrNyLMx9IIcAaAbnoFXQW+1eOxRCFI5orX5xV+WA71hNKZt0to7ELxw1XliD8r/1a
	sHk6REzbedLq1Iv97zJu9E5mkeh0bE0sDZKKnIoNOTxTXTo72zaRjtgiiWr+fx7N9LDXJgUY4Zo
	=
X-Google-Smtp-Source: AGHT+IF6W+B3q07a3sgflbxcPGboBeFgqOuctbLzCA5Hi8E3OAZoFx+1iizjtjmFdXDygdJOzzIA0w==
X-Received: by 2002:aa7:ccd6:0:b0:601:8335:e96b with SMTP id 4fb4d7f45d1cf-602da8dde90mr8762324a12.34.1748359608950;
        Tue, 27 May 2025 08:26:48 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich 
Subject: [PATCH v3 3/5] cpufreq: Avoid potential buffer overrun and leak
Date: Tue, 27 May 2025 16:26:33 +0100
Message-ID: <20250527152635.2451449-4-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
References: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

If set_px_pminfo is called a second time with a larger state_count than
the first call, calls to PMSTAT_get_pxstat will read beyond the end of
the pt and trans_pt buffers allocated in cpufreq_statistic_init() since
they would have been allocated with the original state_count.

Secondly, the states array leaks on each subsequent call of
set_px_pminfo.

Fix both these issues by ignoring subsequent calls to set_px_pminfo if
it completed successfully previously. Return success rather than an
error to avoid errors in the dom0 kernel log when reloading the
xen_acpi_processor module.

At the same time, fix a leak of the states array on error.

Signed-off-by: Ross Lagerwall 
---

In v3:

* Return success rather than an error when called a second time
* Use XFREE
 xen/drivers/cpufreq/cpufreq.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index 19e29923356a..635f6e8c61a5 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -517,7 +517,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf)
         }
     }
 
-    if ( perf->flags & XEN_PX_PSS )
+    if ( perf->flags & XEN_PX_PSS && !pxpt->states )
     {
         /* capability check */
         if ( perf->state_count <= 1 )
@@ -534,6 +534,7 @@ int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf)
         }
         if ( copy_from_guest(pxpt->states, perf->states, perf->state_count) )
         {
+            XFREE(pxpt->states);
             ret = -EFAULT;
             goto out;
         }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 15:26:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:26:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998561.1379308 (Exim 4.92)
	(envelope-from )
	id 1uJwCd-0001L9-4s; Tue, 27 May 2025 15:26:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998561.1379308; Tue, 27 May 2025 15:26: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 1uJwCd-0001Kp-1F; Tue, 27 May 2025 15:26:55 +0000
Received: by outflank-mailman (input) for mailman id 998561;
 Tue, 27 May 2025 15:26:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJwCb-0001GX-4Y
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:26:53 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 03270ecf-3b0f-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 17:26:51 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5fbfdf7d353so4655936a12.0
 for ; Tue, 27 May 2025 08:26:51 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6049d482cc7sm3442712a12.19.2025.05.27.08.26.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 08:26: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" 
X-Inumbo-ID: 03270ecf-3b0f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748359610; x=1748964410; 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;
        bh=nVr7GtnMIQOWD4+rFj7EsFStMBOYAHWO5pkXs+hAwww=;
        b=gh0R4KGom0tb89yJwqHZYqQV/ZFYD1iTL1bmQY3Q8AhmTx2YxA30+FdkZSOM7dW8xe
         QizyAQ4Qpw8NTI7koGvE8PX+7JLdbptm0oJYFedHLGthxTmQnzzVL86Z2wXAW6unZ1QQ
         ZWzRQ2o8b+b2dlLHAEC9r1glJAXc9EmZhHZ2Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748359610; x=1748964410;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=nVr7GtnMIQOWD4+rFj7EsFStMBOYAHWO5pkXs+hAwww=;
        b=VfMYFdXVCkIDXUXQz8mad+1KaMzMANZTYE7tSeWgmmSARaJ0Okp1pwz55xNDvZLrOq
         tgsinfZrAZfcSstWQAQteryZFAnPQk3vakBODzIxDObEutYssG2ftEK5vvufNNILnh8C
         DLqvSgtcEoWVcvs9zseY8BgA9xDeyRChDMMecVuRPkjvfGeorsxHqFM0mAVmX2SMy8eK
         lJARNOh/Z2YM2R+xHhMSMxqucXcXlNSxgtweeVQBwldwXM1EF4dEvrhuKok+6+n007Is
         NbIZkcEvWmDyG1Py+27cLRGELHazXNp56AkdsxVWYqR6QzDY8yL1l1MIt6BG/zQ+lWvB
         rHZg==
X-Gm-Message-State: AOJu0YzGYkzu2Tkacfqx/YILcr1zwGyGdxHEqzxilQLqN9XuzbBihwvy
	hE7E4aykNn9FpAMZLl6ZipyKkyuMeELzzYNEzZcGIPOPxUv3zIe3ersa2j2w+pm+3llSKioGD/c
	E5zM=
X-Gm-Gg: ASbGncuEkJy9yj3SazCfpOorV+V/wu+yYs/cciOydFao5zt9qwjEcuDJm8urTGBw0Kp
	dVAQXdsNx+Zrx+ijdH4N8yGPI94eCpttTtq4jqvaoGiFzBcymByqO6atVInN7F88JhJmsvuobLB
	85pOer8gB/b3Gj9vUD3IynQmlidpvfkZ84CSm5l/gDIYY3OWmzyE2jCfDD+5pSct+vtl03YUuO4
	nOT2sLk3Xua/9bFkbFhaOEt8N7jA1MQh9nZkFMXHSfNUJoNQRk8ppoBk+Dv50ddyfxqPfg0rIwt
	c+XPZb5X6q4v+ZFJkE8eSC9+FAZ2Vhr+2qo/7HLE9pVvwN8M5GOB0byOj7Uc915jjX73YVCtFtw
	=
X-Google-Smtp-Source: AGHT+IEbEqJnJpwWGP8JbPpoco9C+hNCmnaaNfW2gX0K5XBjHWhjLa3skuvniV1lilvf6tP1E56FWQ==
X-Received: by 2002:a05:6402:2809:b0:604:e99e:b765 with SMTP id 4fb4d7f45d1cf-604e99eb86dmr2814956a12.9.1748359610418;
        Tue, 27 May 2025 08:26:50 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Anthony PERARD ,
	Juergen Gross ,
	Jan Beulich 
Subject: [PATCH v3 4/5] libxc/PM: Ensure pxstat buffers are correctly sized
Date: Tue, 27 May 2025 16:26:34 +0100
Message-ID: <20250527152635.2451449-5-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
References: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

xc_pm_get_pxstat() requires the caller to allocate the pt and trans_pt
buffers but then calls xc_pm_get_max_px() to determine how big they are
(and hence how much Xen will copy into them). This is susceptible to
races if xc_pm_get_max_px() changes so avoid the problem by requiring
the caller to also pass in the size of the buffers.

Suggested-by: Jan Beulich 
Signed-off-by: Ross Lagerwall 
---

In v3:

* Fix DECLARE_NAMED_HYPERCALL_BOUNCE size

 tools/libs/ctrl/xc_pm.c | 21 ++++++++++-----------
 tools/misc/xenpm.c      |  1 +
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/tools/libs/ctrl/xc_pm.c b/tools/libs/ctrl/xc_pm.c
index ff7b5ada053f..0bd79031044f 100644
--- a/tools/libs/ctrl/xc_pm.c
+++ b/tools/libs/ctrl/xc_pm.c
@@ -46,35 +46,34 @@ int xc_pm_get_pxstat(xc_interface *xch, int cpuid, struct xc_px_stat *pxpt)
 {
     struct xen_sysctl sysctl = {};
     /* Sizes unknown until xc_pm_get_max_px */
-    DECLARE_NAMED_HYPERCALL_BOUNCE(trans, pxpt->trans_pt, 0, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
-    DECLARE_NAMED_HYPERCALL_BOUNCE(pt, pxpt->pt, 0, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+    DECLARE_NAMED_HYPERCALL_BOUNCE(trans, pxpt->trans_pt,
+                                   pxpt->total * pxpt->total * sizeof(uint64_t),
+                                   XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+    DECLARE_NAMED_HYPERCALL_BOUNCE(pt, pxpt->pt,
+                                   pxpt->total * sizeof(struct xc_px_val),
+                                   XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
 
-    int max_px, ret;
+    int ret;
 
     if ( !pxpt->trans_pt || !pxpt->pt )
     {
         errno = EINVAL;
         return -1;
     }
-    if ( (ret = xc_pm_get_max_px(xch, cpuid, &max_px)) != 0)
-        return ret;
-
-    HYPERCALL_BOUNCE_SET_SIZE(trans, max_px * max_px * sizeof(uint64_t));
-    HYPERCALL_BOUNCE_SET_SIZE(pt, max_px * sizeof(struct xc_px_val));
 
     if ( xc_hypercall_bounce_pre(xch, trans) )
-        return ret;
+        return -1;
 
     if ( xc_hypercall_bounce_pre(xch, pt) )
     {
         xc_hypercall_bounce_post(xch, trans);
-        return ret;
+        return -1;
     }
 
     sysctl.cmd = XEN_SYSCTL_get_pmstat;
     sysctl.u.get_pmstat.type = PMSTAT_get_pxstat;
     sysctl.u.get_pmstat.cpuid = cpuid;
-    sysctl.u.get_pmstat.u.getpx.total = max_px;
+    sysctl.u.get_pmstat.u.getpx.total = pxpt->total;
     set_xen_guest_handle(sysctl.u.get_pmstat.u.getpx.trans_pt, trans);
     set_xen_guest_handle(sysctl.u.get_pmstat.u.getpx.pt, pt);
 
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index db658ebaddd5..de319329e6b0 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -319,6 +319,7 @@ static int get_pxstat_by_cpuid(xc_interface *xc_handle, int cpuid, struct xc_px_
     if ( !pxstat)
         return -EINVAL;
 
+    pxstat->total = max_px_num;
     pxstat->trans_pt = malloc(max_px_num * max_px_num *
                               sizeof(uint64_t));
     if ( !pxstat->trans_pt )
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 15:26:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:26:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998562.1379314 (Exim 4.92)
	(envelope-from )
	id 1uJwCd-0001Rp-Js; Tue, 27 May 2025 15:26:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998562.1379314; Tue, 27 May 2025 15:26: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 1uJwCd-0001Pv-EP; Tue, 27 May 2025 15:26:55 +0000
Received: by outflank-mailman (input) for mailman id 998562;
 Tue, 27 May 2025 15:26:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJwCc-0001GX-9e
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:26:54 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 04068e36-3b0f-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 17:26:52 +0200 (CEST)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-602039559d8so6967152a12.1
 for ; Tue, 27 May 2025 08:26:52 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6049d482cc7sm3442712a12.19.2025.05.27.08.26.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 08:26: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" 
X-Inumbo-ID: 04068e36-3b0f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748359612; x=1748964412; 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;
        bh=z+VEb8t0VEsYQfvMjLE4L2oQ6RvTwDmIbkwe2PQDnDw=;
        b=CH8auMAvQtviTHcGhPc3AN8TeobWt8Bjg8DS3y6Gck5YLMVVsqsaugkpBCp7eSzacA
         MG+Rz+VBYkA/tP6N9GLEEmhxLsfkh8Q4fdGntXo2qP7hKD/ntnKjTHrRe1emT9dwDOur
         GxxVPp8NKJC1s66zcRRV/ZcuM8rJHciFEfT3s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748359612; x=1748964412;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=z+VEb8t0VEsYQfvMjLE4L2oQ6RvTwDmIbkwe2PQDnDw=;
        b=EoBxk+W1uv62FgD/mcOxDVl5sTANfKsKOGb7JKFCShs209oEQbsyPBZXOFpfn27LqH
         58DVe9EBTY9U5IoA4OjWV+SVMI4VkkNJtk3JwYoelvQZSS6ekyXPq/WF8L3OAHNJ4Qtd
         4G/iwUbMqvNvUE4eZyapLO3WH1/GdJV5elbrlVQ/ayXrwlkyQpdR2K8o5V6MVSs6VXH6
         vKxMEDTM6Eky+RBPOyaFxM80tqrQuqn3nki2yRw7V2DxVzoCPIAo69PV5447nOpOwT4l
         ml2K4z0bPxM8vxHJVErmX7kAZiwuoYQb25vHlR4UE7ZEs28iDJwdRbZKwH8yC2Ui/bk1
         C9zQ==
X-Gm-Message-State: AOJu0YxKBOUS8QiYRUXiR3jUK5liyDCaEuZnnUV0u1ZtLxHNxzosNhec
	tkUJX+Oq4/lDTaN5QrVELw7oorRDG92cwYYtmWrAixzxN5XwSBE1oMDa//urV0v0hgV+WACuRQM
	5wyA=
X-Gm-Gg: ASbGncsRK+zsmQvHH4lZy1SFuwetU5rEjfTYxsU+vzoD8N+d/UZlEs0R6PuE/PNTiTk
	5XeHRSBndd4AIhdIq6kWZKcsGZc3V+g8nGkyEpPJgzLhsg5sCXpPGxUdujnxTFTYBeSk5QNllHc
	LvWuWdECozzDX36qrHw8hXDmcaaljv7Xa6vEhRd7q0BOHEJ8Zik/gdIjV2JGl/zcfq/W39v0e1m
	g2C5k1VlwqdqTOJ25eE++mqxw+D7wcOK3UKxE1Sb/bpcpDVV1j7CJZ+/8J9kqNCdJUVGPLdtDIV
	+IGLndeArFRjUmAr8UeQ7IE3TP/3cWXT+PPPaNqTu6yqaas07uBqU6hs/3Gfb4uYO7R+Ae9fXCU
	=
X-Google-Smtp-Source: AGHT+IHmacdcV8Xv0A2x8fYmDlkSIjjTWVtLBb7+07rSusdS1QTYhHRiXc70jGeNg3TJSWPuYpLYXQ==
X-Received: by 2002:a05:6402:34d6:b0:5fb:455f:ac40 with SMTP id 4fb4d7f45d1cf-602d9061f6amr12010075a12.4.1748359611915;
        Tue, 27 May 2025 08:26:51 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Anthony PERARD 
Subject: [PATCH v3 5/5] libxc/PM: Retry get_pxstat if data is incomplete
Date: Tue, 27 May 2025 16:26:35 +0100
Message-ID: <20250527152635.2451449-6-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
References: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

If the total returned by Xen is more than the number of elements
allocated, it means that the buffer was too small and so the data is
incomplete. Retry to get all the data.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Anthony PERARD 
---
 tools/misc/xenpm.c | 49 +++++++++++++++++++++++++++++-----------------
 1 file changed, 31 insertions(+), 18 deletions(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index de319329e6b0..d5387f5f0693 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -312,29 +312,42 @@ static int get_pxstat_by_cpuid(xc_interface *xc_handle, int cpuid, struct xc_px_
     int ret = 0;
     int max_px_num = 0;
 
-    ret = xc_pm_get_max_px(xc_handle, cpuid, &max_px_num);
-    if ( ret )
-        return -errno;
-
     if ( !pxstat)
         return -EINVAL;
 
-    pxstat->total = max_px_num;
-    pxstat->trans_pt = malloc(max_px_num * max_px_num *
-                              sizeof(uint64_t));
-    if ( !pxstat->trans_pt )
-        return -ENOMEM;
-    pxstat->pt = malloc(max_px_num * sizeof(struct xc_px_val));
-    if ( !pxstat->pt )
+    for ( ; ; )
     {
-        free(pxstat->trans_pt);
-        return -ENOMEM;
-    }
+        ret = xc_pm_get_max_px(xc_handle, cpuid, &max_px_num);
+        if ( ret )
+            return -errno;
 
-    ret = xc_pm_get_pxstat(xc_handle, cpuid, pxstat);
-    if( ret )
-    {
-        ret = -errno;
+        pxstat->total = max_px_num;
+        pxstat->trans_pt = malloc(max_px_num * max_px_num *
+                                  sizeof(uint64_t));
+        if ( !pxstat->trans_pt )
+            return -ENOMEM;
+        pxstat->pt = malloc(max_px_num * sizeof(struct xc_px_val));
+        if ( !pxstat->pt )
+        {
+            free(pxstat->trans_pt);
+            return -ENOMEM;
+        }
+
+        ret = xc_pm_get_pxstat(xc_handle, cpuid, pxstat);
+        if ( ret )
+        {
+            ret = -errno;
+            free(pxstat->trans_pt);
+            free(pxstat->pt);
+            pxstat->trans_pt = NULL;
+            pxstat->pt = NULL;
+            break;
+        }
+
+        if ( pxstat->total <= max_px_num )
+            break;
+
+        /* get_max_px changed under our feet so the data is incomplete. */
         free(pxstat->trans_pt);
         free(pxstat->pt);
         pxstat->trans_pt = NULL;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 15:27:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:27:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998565.1379328 (Exim 4.92)
	(envelope-from )
	id 1uJwCh-0001wR-Sz; Tue, 27 May 2025 15:26:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998565.1379328; Tue, 27 May 2025 15: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 1uJwCh-0001w9-ON; Tue, 27 May 2025 15:26:59 +0000
Received: by outflank-mailman (input) for mailman id 998565;
 Tue, 27 May 2025 15:26:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJwCg-0001GX-T7
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:26:58 +0000
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [2a00:1450:4864:20::531])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 06c2159b-3b0f-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 17:26:57 +0200 (CEST)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5efe8d9ebdfso6763637a12.3
 for ; Tue, 27 May 2025 08:26:57 -0700 (PDT)
Received: from rossla-pc.eng.citrite.net ([185.25.67.249])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6049d482cc7sm3442712a12.19.2025.05.27.08.26.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 08:26: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" 
X-Inumbo-ID: 06c2159b-3b0f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748359616; x=1748964416; 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;
        bh=7EiuJMdCLjFWOEnoMYbjUzW+ITRH6U+JRE5WHKaDcw4=;
        b=I7Efd4m+AeIF8SnpByKXCXsQg+4anwVbyB5WwWzbZ4k/xftCa7UaOfVwNWW8ocqbGS
         Co6ROjBiaaSYS2eq7u0Dvh7o5grbA89U/+OIh9F6YIVowjJvhpH9jkNNEKfn42FtvJ7i
         Hp/gdnQoKWVgJ2jNV5uwfgXcVbrIVUfOloQJw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748359616; x=1748964416;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=7EiuJMdCLjFWOEnoMYbjUzW+ITRH6U+JRE5WHKaDcw4=;
        b=oNWcX4rFNtU17tZvXchbknyyVFoNHUyKWF4qqcxnZLP4mKuXR/WPjLziqGYR6xeWq0
         7xsOfN/7ZJ7n4MBGgapxPqWgU11Lsy6ScNrQKhvTf19rDgse3EqnMmaNU11zLuZH3NLn
         M7W/4ylUaJ+P7jnyxX0vx0IWI1TS7oxLYxUJcHxiFgwEsZ83nHXJELTH1tOpTuNid7NN
         mpDOAjaHuI9ShDczdpBSW6V9Sao+AZRjEU8VBzOpi6OTQuhlaBdzljDFL1xJ4/NVnmpq
         87II/Z9oIVqKFXnUwApmjdkcxHwK0nTCJYpp/q5OI/hXFlyHweW2fBo6mn/YNIM3TDx+
         y4XA==
X-Gm-Message-State: AOJu0YyTSOQZtMSIvK5jv9IBhDeYpx199LG6VgI0nNVbqr0K4G9dViPm
	PsQAYrjH8ZY/ySIRYQbEimJYWAI40Ap75orp4xT1+29+iHobZuHIp9SSbWrLKO2hy0HkfGvoaTV
	jsWA=
X-Gm-Gg: ASbGncufOhz3OaJMXxinb06JGEwuABhesCHi6QDeD5h2bGssF8xxe6lcJ9y8hY52WwM
	BdcUBgLSf4zOHv5g9u/0h9FvL6mNHM7bpVk8ZeOOAmwweTkvfFDfOCXWkez53caDCdU+4gPyuHI
	kGf1dDccWfGUwc+UMKWNZsv5r3Ib7svz+LZjW71bMjc4lbA/vNhwVGsoa0xOd/FZkBDp355q8Lf
	mgEXxIU0hSfEiR2Q1hb6pCJCGAtVV4sipAax0gKi2s6GTb6gMajyWKxz2bJDQVxeMIwBkJxpwCg
	Q1LNUCoBcm7G3Q8nDoTl+PWPusf28jIUGgxGUVINziGqHITY40j+XXzotGfeGgsT1vS+1CDFtgc
	=
X-Google-Smtp-Source: AGHT+IHYE2hnovzy6W1PgNLaxLFKR7wewuV0GiqQDMScRgK3xO82ngXX7l+Zt1GJ0pZEMQ86Wh/Frg==
X-Received: by 2002:a05:6402:84f:b0:5ff:ef95:333a with SMTP id 4fb4d7f45d1cf-602d953574emr10518215a12.13.1748359605055;
        Tue, 27 May 2025 08:26:45 -0700 (PDT)
From: Ross Lagerwall 
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 1/5] x86/pmstat: Check size of PMSTAT_get_pxstat buffers
Date: Tue, 27 May 2025 16:26:31 +0100
Message-ID: <20250527152635.2451449-2-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
References: <20250527152635.2451449-1-ross.lagerwall@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Check that the total number of states passed in and hence the size of
buffers is sufficient to avoid writing more than the caller has
allocated.

The interface is not explicit about whether getpx.total is expected to
be set by the caller in this case but since it is always set in
libxenctrl it seems reasonable to check it and make it explicit.

Signed-off-by: Ross Lagerwall 
Fixes: c06a7db0c547 ("X86 and IA64: Update cpufreq statistic logic for supporting both x86 and ia64")
---

In v3:

* Fix if condition
* Move some header comments from patch 2
* Clarify some comments

 xen/drivers/acpi/pmstat.c   |  7 +++++--
 xen/include/public/sysctl.h | 15 +++++++++++++--
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index c51b9ca358c2..0d570e28bf11 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -103,8 +103,11 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
 
         cpufreq_residency_update(op->cpuid, pxpt->u.cur);
 
-        ct = pmpt->perf.state_count;
-        if ( copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct*ct) )
+        ct = min(pmpt->perf.state_count, op->u.getpx.total + 0U);
+
+        /* Avoid partial copying of 2-D array */
+        if ( ct == op->u.getpx.total &&
+             copy_to_guest(op->u.getpx.trans_pt, pxpt->u.trans_pt, ct * ct) )
         {
             spin_unlock(cpufreq_statistic_lock);
             ret = -EFAULT;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 9eca72865b87..906a3364fbd9 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -215,11 +215,22 @@ typedef struct pm_px_val pm_px_val_t;
 DEFINE_XEN_GUEST_HANDLE(pm_px_val_t);
 
 struct pm_px_stat {
-    uint8_t total;        /* total Px states */
+    /*
+     * IN: Number of elements in pt, number of rows/columns in trans_pt
+     *     (PMSTAT_get_pxstat)
+     * OUT: total Px states (PMSTAT_get_max_px, PMSTAT_get_pxstat)
+     */
+    uint8_t total;
     uint8_t usable;       /* usable Px states */
     uint8_t last;         /* last Px state */
     uint8_t cur;          /* current Px state */
-    XEN_GUEST_HANDLE_64(uint64) trans_pt;   /* Px transition table */
+    /*
+     * OUT: Px transition table. This should have total * total elements.
+     *      As it is a 2-D array, this will not be copied if it is smaller than
+     *      the hypervisor's Px transition table. (PMSTAT_get_pxstat)
+     */
+    XEN_GUEST_HANDLE_64(uint64) trans_pt;
+    /* OUT: This should have total elements (PMSTAT_get_pxstat) */
     XEN_GUEST_HANDLE_64(pm_px_val_t) pt;
 };
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 15:38:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:38:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998616.1379337 (Exim 4.92)
	(envelope-from )
	id 1uJwO3-0005JF-Up; Tue, 27 May 2025 15:38:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998616.1379337; Tue, 27 May 2025 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 1uJwO3-0005J8-SJ; Tue, 27 May 2025 15:38:43 +0000
Received: by outflank-mailman (input) for mailman id 998616;
 Tue, 27 May 2025 15:38:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJwO2-0005J1-Nx
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:38:42 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a9fb2510-3b10-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 17:38:40 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad574992fcaso675749366b.1
 for ; Tue, 27 May 2025 08:38:40 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad8962b2c3bsm65688466b.113.2025.05.27.08.38.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 08:38: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" 
X-Inumbo-ID: a9fb2510-3b10-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748360320; x=1748965120; darn=lists.xenproject.org;
        h=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;
        bh=VrUl5ky/RX3+pJxj1HeD9lpoWrX2PDQKHjieULJvXWw=;
        b=CbU5c72U+ZiF3Z957akoxHspa7fnBd3PJgNhY3XDUpu6mMRp2an10wj9kCB7kMH7cF
         XXmSmKpYyuVENddJt7VX3yOZCflB8DgNVTmbFKut56oSYg9DuM2qcCEUbjPmzdJiAsGG
         CwDPeAi3XwkxYHGc2gwdSjo1QTOEgGzTVY+qlm9P+taBZc2+5lC+IML+mKOMFKTVsXOR
         8HAQQ1WBqxV76099G/kXAYXQNMggwRyP54m6VbBAFyxrHL9KOG8TT01k0HW/mnacySxm
         xFTSC+XKVFxdMSAb9IISWFbcEIaQuBpBB3zTcikmNOO5CjwHM2QgFidF1EyeCZEV8Lcg
         SfYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748360320; x=1748965120;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=VrUl5ky/RX3+pJxj1HeD9lpoWrX2PDQKHjieULJvXWw=;
        b=pYgPQQN6aDk/8SRo+sMFFgLVjOmaut+ZmPfDTTa+GO1mjz4MfN8wC2xEcuYZjzbopr
         Z/TlqzoyvpNVTMJkxoLsnMrn6r3UDc23p8JWQQpzNO0uCZ7eXeMUO7hVj0Mjgo+zxGWm
         Y6d8GDfvVS3SPVbGd+SW4ipdqp9XR2dJqQOmIE52HLIAL6sP+d5s/S94xRYjdyHCkPe/
         VHI6sdRY6QFyvvrjWxPcTxjbBmwDwsRuj4I1wny5RByZHvcEM8eUPRmO0WcAxUFvwN0B
         u4cUfKn/kXnzJq+qBVrsdJ/8pWSVqaeA/eiVCoIWmmSODuoKL3EDcZ9FKCpmBTqiGNb+
         Zt7g==
X-Forwarded-Encrypted: i=1; AJvYcCUsUPHlPNt7EESJvTYV5TY250Whxbrkf4+i6SAPBoDGbhOTUCRx2K42QYRzhjBj0O/c09nhgRcFkfw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzRQZHDy5oBgLa/FUtFFoJ8xdEq6GO2iuypJYSQVVRkabk/h435
	47LA9PDBDw/HjKJsuYTg3DkX7hzpeo3HwDjZw9dryl/3FJ9k7Io+uYJm
X-Gm-Gg: ASbGncuoe13OeLCZgdi3ZpeMo3qholgJp4r+PFNwD4+oe5EAmsJ/mQtxrCzThC25hbv
	7eePrzl6XPJtfvKxD9DoNCNA8hKeG0Krj74CDP/82GN766i7oTMQ2b/s6yLPVggKRlwGHx/bers
	iqALOu9/wiZT08Q4wO/Dcgfi0ig/VFVCIq2r8+Qi8Bf3DtnoMveMULVWz/5bCABu/375UkLjXH5
	XLQB4vCxsxUplMLTkI2TWT3/6ENnmR/OrslukB/KgOduMQ/cZjp3y0rvhMY0asuEh2PXFs6fHAU
	x6PdQh0GCNhNBDMfFwt+Aez1gIfsqrhkgXQ5MX121TByutCgW7zdb9JngaUeOFUK56GkhszElFN
	oUX7fo+gxtBsDFNhX7hNE/8d/
X-Google-Smtp-Source: AGHT+IGLkFPPrTnYJz476VtYH4bTIKtYsc+EPSdVu6KwMrPCyuoI1lV0Cf8mej6vVORg02CnKYbPqw==
X-Received: by 2002:a17:906:c153:b0:ad5:55db:e40d with SMTP id a640c23a62f3a-ad85b12060fmr1104796666b.34.1748360319989;
        Tue, 27 May 2025 08:38:39 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------SlhkdWn3jvvfRgtLnKhgME1i"
Message-ID: <87034726-3a26-4146-ad05-655058b9eba9@gmail.com>
Date: Tue, 27 May 2025 17:38:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4][PART 1 4/4] CHANGELOG: Mention Xen suspend/resume to
 RAM feature on arm64
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
 Community Manager 
References: 
 <1035d97375bad4b3e6f86e78cbe4e46abdbc2de9.1748337249.git.mykola_kvach@epam.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <1035d97375bad4b3e6f86e78cbe4e46abdbc2de9.1748337249.git.mykola_kvach@epam.com>

This is a multi-part message in MIME format.
--------------SlhkdWn3jvvfRgtLnKhgME1i
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Mykola,

On 5/27/25 11:18 AM, Mykola Kvach wrote:
> From: Mykola Kvach
>
> Signed-off-by: Mykola Kvach
> ---
>   CHANGELOG.md | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index ec452027f5..fc89ed6e09 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -26,6 +26,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>   
>    - On Arm:
>       - Ability to enable stack protector
> +    - Support guest suspend/resume to/from RAM
>   
>   ### Removed
>    - On x86:

According to your commit message, suspend/resume will only work for Arm64.
I think it would be good to mention that in the|CHANGELOG.md| as well.

Also, this implementation adds suspend/resume support via vPSCI, which
I believe is also worth noting in the|CHANGELOG.md|.

Thanks.

~ Oleksii

--------------SlhkdWn3jvvfRgtLnKhgME1i
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    
    Hello Mykola,

    
    
    On 5/27/25 11:18 AM, Mykola Kvach
      wrote:
    
    
    
    
    
      
    From: Mykola Kvach <mykola_kvach@epam.com>

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
 CHANGELOG.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index ec452027f5..fc89ed6e09 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -26,6 +26,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
  - On Arm:
     - Ability to enable stack protector
+    - Support guest suspend/resume to/from RAM
 
 ### Removed
  - On x86:

    
    
    
    
    According to your commit message, suspend/resume will only work for Arm64.
I think it would be good to mention that in the CHANGELOG.md as well.
    
    
    Also, this implementation adds suspend/resume support via vPSCI, which
I believe is also worth noting in the CHANGELOG.md.
    
    
    Thanks.
    
    
    ~ Oleksii

    
  


--------------SlhkdWn3jvvfRgtLnKhgME1i--


From xen-devel-bounces@lists.xenproject.org Tue May 27 15:57:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 15:57:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998626.1379348 (Exim 4.92)
	(envelope-from )
	id 1uJwgJ-0000Xp-EZ; Tue, 27 May 2025 15:57:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998626.1379348; Tue, 27 May 2025 15: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 1uJwgJ-0000Xi-Bs; Tue, 27 May 2025 15:57:35 +0000
Received: by outflank-mailman (input) for mailman id 998626;
 Tue, 27 May 2025 15:57:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJwgH-0000Xb-PL
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 15:57:33 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4c4c2457-3b13-11f0-a2fd-13f23c93f187;
 Tue, 27 May 2025 17:57:32 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a37a243388so3606109f8f.1
 for ; Tue, 27 May 2025 08:57:32 -0700 (PDT)
Received: from [10.81.43.171] ([46.149.103.11])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4d0884cabsm9372270f8f.82.2025.05.27.08.57.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 08: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" 
X-Inumbo-ID: 4c4c2457-3b13-11f0-a2fd-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748361451; x=1748966251; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=bXDP4i8pkv+pNGyPRXUxcPNPE68glxEtXFUBdwlcmnE=;
        b=fJQpPYcKwb6U0D5jfnYYk2S1lAkSzHipC8gvdLsaZRebcl5+2iki5/ouBWmx7Lhnn1
         BAZBAeOP5u2Dju8s458oX/livfcyxpsMO5AvZT3Q139yBVRJKlYCGB+b0AVk3adpcjcU
         hFcCzo1KRdz1f21MNia3xgzAD+zRKusJJtg+c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748361451; x=1748966251;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bXDP4i8pkv+pNGyPRXUxcPNPE68glxEtXFUBdwlcmnE=;
        b=iLqRtbaR2HwETA0w5ge8PvwwDeQ3/4KxlPIAwJcvJw+NjC6j/K8Ij0Tdvrb7hrdNZe
         1rjzDXW9vKR8X1Rv6wFZwiOXpCM64gCOYGZwP3zMzd80PjrsX/w0UKmAtVc6Tu9sYncS
         7dAhkcbzQT2fviEES8U1PZh0Ay1z5x5SFluG2nJSNj65MEaUTabEPdDdZ0Ovv4FEW/0u
         nPhzukdQZvAsnTZnKZ2XWkW6LMju3ECbR0mtWVvrYUEb4M4mdNtrFNv7AuDS7RY6tKBX
         SrhI8m2Q9fix0LzoDqzBG2ZHdTVyA5BtaR+H4ozgHTOitXZqbeWD5PsSx0Nu5T50pAA/
         /Etg==
X-Gm-Message-State: AOJu0YxJGTFJ/wHnvgLX1OCb07v5QCWLa3SIYkW1UcJ5YjQmUhD11zid
	stIk9WL6ekVqVD+xL6gYnHmaz6I0vNm5cRvYr3c72inNY+XEKggzpXcOtGUo4wmAvKM=
X-Gm-Gg: ASbGnctOZkraW252BK46djj1EaEg6FtEUvxSnzIDrWvphR3rq9zjTywDKs1xxNLYxhi
	nvjuQyX3+VR3u+lPNzDmhGq4WIZCRyW2sdqCCKpeFVpWmVCTWiypeLfcuQEO63nxyYuDJcrnO3G
	/xS3R6UM8lNNvatlnX90CcSCl7A19XaCschwGYXPxr817Zdozc3yQCRz1Lb5IdXLeOuS3Ki5BzJ
	maWDLEsDE44+8kR7Bc/ZYEQPTHyIyDjqXdWCiecJv1E8gtmXOBYB5WQlKXNLKhCs1+BfG8k5D+5
	anly6jaxALO7DH14bLQnT9Gv6YLBLxR8/lFP0Qdj0JnaDniLg7EMvOi2lQh7A2VCPdvZInXj
X-Google-Smtp-Source: AGHT+IHMtADaUNtBOe1sCbFGeVjRbe48Y/vGv2bj7uE8BRtuXxt0+5t2xiRgk5tR5PkYrZH/2EC0bQ==
X-Received: by 2002:a05:6000:e4d:b0:3a3:75d7:5864 with SMTP id ffacd0b85a97d-3a4cb4834cdmr9322585f8f.47.1748361451484;
        Tue, 27 May 2025 08:57:31 -0700 (PDT)
Message-ID: 
Date: Tue, 27 May 2025 16:57:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/3] CI: Adjust how domU is packaged in dom0
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 
Cc: Xen-devel ,
 Anthony PERARD ,
 Stefano Stabellini ,
 Michal Orzel 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
 <20250522173640.575452-4-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

On 27/05/2025 2:55 pm, Marek Marczykowski-Górecki wrote:
> On Thu, May 22, 2025 at 06:36:40PM +0100, Andrew Cooper wrote:
>> Package domU in /root for dom0 and insert into the uncompressed part of dom0's
>> rootfs, rather than recompressing it as part of the overlay.
> It doesn't really need moving to /root to achieve this, no? The
> domU-in-dom0.cpio can very well contain boot/* files.

Yes, but is /boot really an appropriate place to be putting test artefacts?

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 27 16:05:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 16:05:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998636.1379358 (Exim 4.92)
	(envelope-from )
	id 1uJwnl-0002yj-0L; Tue, 27 May 2025 16:05:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998636.1379358; Tue, 27 May 2025 16:05: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 1uJwnk-0002yc-Ty; Tue, 27 May 2025 16:05:16 +0000
Received: by outflank-mailman (input) for mailman id 998636;
 Tue, 27 May 2025 16:05:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJwnj-0002yT-7r
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 16:05:15 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5f5616c7-3b14-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 18:05:13 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-551efcb745eso4420252e87.2
 for ; Tue, 27 May 2025 09: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" 
X-Inumbo-ID: 5f5616c7-3b14-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748361913; x=1748966713; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GhYBjKtDHXYKRUMKJVj8jFgV9Y7ogyhIcysWSkhwnj4=;
        b=YJ/oWms2eO7JvIgWnan837seweum7537jQ/1QCxFYh2mzet5RQNacV3aY/+nSQuB7I
         c8O08W3qqr0Znmqoy075Bmm44dQv15ZPZq8vZql4Vz7W/0i6AZ6KE2LUEOSRh4HWJoM7
         QIrdrUYN5aKsFX+KnFk4vPVuiQ7Xc08EweF/HtWv+3ScA2mtQ6rqfyI2VgZqij+Hga9S
         gXUk7g3IzB1903ejhnXR/Q4UuQc8rexxjm86K00ym94E1rMQcB/mVyY01Uw+JUIcIxV+
         QEoGG56E8ILU7UlFZYzSOt42v9sFM6O4mosITp0PEmLdgeNDH1BUVK0VQWwPZKOztnq3
         JsLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748361913; x=1748966713;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GhYBjKtDHXYKRUMKJVj8jFgV9Y7ogyhIcysWSkhwnj4=;
        b=GLPN7WxtTRQTrDXDWDzbzwYHknUlahx84LzsPmnEkrOGM/SoMpmXkjn9YpI6LU5gP/
         zWHxAWiksaDQ9ON6XP92uok9BQV5HDLf7l2gIzfwm8xLj8V6x3fKi0/Fpy+WFp0WS2PH
         9qJVnadp/0O8NuHrNGFnLi+l6MHUT95r7y9GvdxDI5x1OhWVf3volQDXc6vdu466+/9d
         G2ehVtkd83x9zpJI7XwT7Z2qpRxZVxn1ZMSheqUJCjPN6LhAfjjmN9VGm/MLXgDjeeAi
         pKOW3YSoEHcCgKKK+SFaYQZwq4NLSELecl3Kd83FTlHEmZDjFf6hmRCTWhCU+4Ui2xmC
         ReDw==
X-Gm-Message-State: AOJu0Yw5ShPfJ8T68p7SG8yU4rrzhzUz3pS8Hgw3F0T+c6lAqUgtqzDx
	7N20GidBcuQR0+2EOyWagCnS3jB1ocVJdMlN7nKiWisve4jRrxve1UGEBcluA8ZiIwBSpyvAqhH
	b4QJ35fEITRCxgAoZdmm72kabqSrwbAI=
X-Gm-Gg: ASbGncu9eUz9YzGPPqpvfz6eCn+FxkUFpR6DzjAsIPYH3IwchOssrY5/Ips4QCftmCc
	mpkyTWkhg122gKhFIoWruR4N9gV6ljn6xHZROb+42P//URsiaSojl6SecWsatYesslXVFmhGZ+Q
	QpDvtOQBBK/UVcja/nam5PhlMXZkT0JpJ4bmu+TpJl9g==
X-Google-Smtp-Source: AGHT+IFe5kmraUvAs79PsRsply9d2ipKfeoxYM9ZLGKgzRyaBz/g/ln+u+fHXqY3NM1ViF2NCeaZ62zXDrsrem0OKFc=
X-Received: by 2002:a05:6512:3c8e:b0:552:1c1b:556 with SMTP id
 2adb3069b0e04-5521c7ae35emr4596587e87.24.1748361912471; Tue, 27 May 2025
 09:05:12 -0700 (PDT)
MIME-Version: 1.0
References:  <1035d97375bad4b3e6f86e78cbe4e46abdbc2de9.1748337249.git.mykola_kvach@epam.com>
 <87034726-3a26-4146-ad05-655058b9eba9@gmail.com>
In-Reply-To: <87034726-3a26-4146-ad05-655058b9eba9@gmail.com>
From: Mykola Kvach 
Date: Tue, 27 May 2025 19:05:01 +0300
X-Gm-Features: AX0GCFubT5IjTcKeb9dWPSKlz5xxutsuio3g6YNWS4fTwMdGIFiQF0yIHPh-SBw
Message-ID: 
Subject: Re: [PATCH v4][PART 1 4/4] CHANGELOG: Mention Xen suspend/resume to
 RAM feature on arm64
To: Oleksii Kurochko 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach , 
	Community Manager 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, @Oleksii Kurochko

On Tue, May 27, 2025 at 6:38=E2=80=AFPM Oleksii Kurochko
 wrote:
>
> Hello Mykola,
>
> On 5/27/25 11:18 AM, Mykola Kvach wrote:
>
> From: Mykola Kvach 
>
> Signed-off-by: Mykola Kvach 
> ---
>  CHANGELOG.md | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index ec452027f5..fc89ed6e09 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -26,6 +26,7 @@ The format is based on [Keep a Changelog](https://keepa=
changelog.com/en/1.0.0/)
>
>   - On Arm:
>      - Ability to enable stack protector
> +    - Support guest suspend/resume to/from RAM
>
>  ### Removed
>   - On x86:
>
> According to your commit message, suspend/resume will only work for Arm64=
.
> I think it would be good to mention that in the CHANGELOG.md as well.

Thank you for pointing that out =E2=80=94 in this case, I forgot to drop
"arm64" from the commit message.
For non-hardware domain guests, suspend/resume support is available
for both ARM32 and ARM64.
When PSCI SYSTEM_SUSPEND is triggered from the hardware domain, the
system ultimately uses
Host PSCI =E2=80=94 that is, a full system suspend is performed.

>
> Also, this implementation adds suspend/resume support via vPSCI, which
> I believe is also worth noting in the CHANGELOG.md.

You're right =E2=80=94 in this context, "guest suspend/resume" refers to
handling via the virtual PSCI (vPSCI) interface.
When regular PSCI is used, it's typically referred to as Host PSCI.
That sentence could probably be rephrased for better clarity. Thank you.

>
> Thanks.
>
> ~ Oleksii

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue May 27 16:18:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 16:18:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998650.1379368 (Exim 4.92)
	(envelope-from )
	id 1uJx0F-0004xV-50; Tue, 27 May 2025 16:18:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998650.1379368; Tue, 27 May 2025 16:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uJx0F-0004xO-2C; Tue, 27 May 2025 16:18:11 +0000
Received: by outflank-mailman (input) for mailman id 998650;
 Tue, 27 May 2025 16:18:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJx0E-0004xI-8q
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 16:18:10 +0000
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com
 [2a00:1450:4864:20::129])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2d50b52b-3b16-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 18:18:08 +0200 (CEST)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-55320ddb9edso2570762e87.1
 for ; Tue, 27 May 2025 09:18: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" 
X-Inumbo-ID: 2d50b52b-3b16-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748362688; x=1748967488; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=puVX/UZDeRCc5Pjbb5mwx3GCh2Zttj75h/9u+6oI/hU=;
        b=EDHZ5jqxD/VKO2lpj+M/jTE5v2Jl5nZxIjW/FCqde1aCPk03m1t6ifUJteZY7TTUys
         nrhQtvnCa42RSv3HaviJym6hlBsd+ZiD6Wo39yRsYOra4kgjivG+lR10SUc646st+cWe
         9tWPikeMwWtmeXzKTCzXXGOTqq3+/DyOkoF4d+oPDNyBGFiLfWoQz4QX6DEnxvzW6iYr
         NgNnB1RGkRllMQW7vrk2kKaWyi8rqxCqOiNzozbAYWdY5eXWiX3eVLpujQgb3D/wjkQu
         4WV60V7DPOD0Oac3DOwqfSLaPRs3HI9fX6rVp3McZzFnM9FRz7dH+aXya3oFHGjpmgRR
         PjUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748362688; x=1748967488;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=puVX/UZDeRCc5Pjbb5mwx3GCh2Zttj75h/9u+6oI/hU=;
        b=Dd+9GoZbMSrzdxAEKqFL+sGldN+35Ic11Bjce9LjeKNHYQWQM4ckn3s5HgmPaPF3P9
         QAsGGEv7UTyINRTuqkbxSioaEI6yanLj0ebthBSUDkGKYvxhcH+s22/OH/u/hxPOdZ0+
         qHBPAuZXVfMVGo8mHkI3nZfYh/5jqfuuD99Y21Nyq2x0Geduegt0C/3Uff4/+lQ34/4E
         as/1DHSLYaEMSPM8fmXwD+k0L77nZmC+l0Cvo2f1y3IDyq9Zds/nrgEDdckGSer9AI0I
         bQDRsN70mca19t1AWW5S4ZMrxRtLqEUDTt0M7/OQmPyiTOTVPoGpMrcf867w3nckgmgy
         luAw==
X-Gm-Message-State: AOJu0YzyY8UFrmzi8ID1I+fUTQdiLaXUuVpquchhb/mPFvmfsPDYoQm3
	P61FReSiEP/UKiQ02taDQxrQJ2/uWWCmeESFLdCbwhNJzDON+fmI9l91IUPc6jD46B0Iz6fCcrk
	VewcA8WUNWJHVMFT7ne1gle6V8dRJKGw=
X-Gm-Gg: ASbGncs7gKE+suYEeIH4ZeDRXi82fqVMVMW+uDlg53PXsWhIbsE2Ip30XEFQ/KVtIMv
	WcMjgDyhwtNyVmP6f7RWA+zpKsH7bTHZ74nWz4w7qAZVtD/H6LiBubzhxqBcC6sAf05pB9o/Jyt
	OiMrgnG7VN2vNwxXJa7/LC8xbRIAWsGY8=
X-Google-Smtp-Source: AGHT+IHZEfAl9F0825CuXG58CnxCxRt27OhPxdFcI4uGsnqSxV0nfAskgg3qli2TWo211mf50Z0hMPkCD8ECzU+0OA0=
X-Received: by 2002:a05:6512:3d20:b0:553:2868:6357 with SMTP id
 2adb3069b0e04-55328686477mr1056901e87.50.1748362687569; Tue, 27 May 2025
 09:18:07 -0700 (PDT)
MIME-Version: 1.0
References: <974033e9ff0df3ce8a74efaa33f1cee1dcbdb030.1748340071.git.mykola_kvach@epam.com>
 
In-Reply-To: 
From: Mykola Kvach 
Date: Tue, 27 May 2025 19:17:56 +0300
X-Gm-Features: AX0GCFtX3rICOjN9MTe0o7gzWF3cVtUtL4F-eomG1vNWqUokK6s0Ia7LXdcxTWo
Message-ID: 
Subject: Re: [PATCH] x86/ACPI: move scheduler enable/disable calls out of freeze/thaw_domains
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach , 
	Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, @Andrew Cooper

On Tue, May 27, 2025 at 3:53=E2=80=AFPM Andrew Cooper  wrote:
>
> On 27/05/2025 11:04 am, Mykola Kvach wrote:
> > From: Mykola Kvach 
> >
> > The scheduler_disable and scheduler_enable calls have been removed
> > from freeze_domains and thaw_domains, respectively, and relocated
> > to their usage context in enter_state. This change addresses
> > the concern about misleading function semantics, as the scheduler
> > operations are not directly related to the domain pausing/resuming
> > implied by the freeze/thaw naming.
> >
> > Suggested-by: Jan Beulich 
> > Signed-off-by: Mykola Kvach 
>
> FYI I've kicked off a run with this patch:
>
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/183871572=
9
>
> which includes the real suspend/resume testing on several pieces of
> hardware.

It appears I made a mistake by failing to mark this patch as
containing only non-functional changes.

>
> ~Andrew

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue May 27 17:39:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 17:39:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998673.1379401 (Exim 4.92)
	(envelope-from )
	id 1uJyGr-0006sR-0g; Tue, 27 May 2025 17:39:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998673.1379401; Tue, 27 May 2025 17: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 1uJyGq-0006sK-UH; Tue, 27 May 2025 17:39:24 +0000
Received: by outflank-mailman (input) for mailman id 998673;
 Tue, 27 May 2025 17:39:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uJyGp-0006rR-Lm
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 17:39:23 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 865fc468-3b21-11f0-a2fe-13f23c93f187;
 Tue, 27 May 2025 19:39:22 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a367ec7840so2692381f8f.2
 for ; Tue, 27 May 2025 10:39:22 -0700 (PDT)
Received: from [10.81.43.171] ([46.149.103.8])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4dc1172ecsm5711170f8f.48.2025.05.27.10.39.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 10:39: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" 
X-Inumbo-ID: 865fc468-3b21-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748367562; x=1748972362; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=QvXF0o55WDzckzvMIu7yAb1vLxPpKzgHIIhlrrwMM70=;
        b=fLIEGMu6opAH4jzJLqFXnMfFbfvppqMQR3UEyCcM680TndXg5ZccDLuIfJPmNQHYJ3
         zbmmlh/OcnJjMLpRDNT1X+CRD3AeXCBXpxXxY5j5YnGvFUU1yEzJzKzJ3Qg6kUOqJ4aq
         2ToivHDj0p0aqv9vMVMwHd0zv00wCsEFxF008=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748367562; x=1748972362;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=QvXF0o55WDzckzvMIu7yAb1vLxPpKzgHIIhlrrwMM70=;
        b=D4Ub+U3TXzU/5/o6oMMr8MKkW42+YN0UuuSaIIFaneZbt3WbigSXTpxZRDlbADgTJK
         RmBd8WgM+9bgWHs0B9MykRYcrRDesqtdlcalnYpeuVpHbR/zkpsmDipqlUtSlu2J6OLI
         MYR/JPv/CI+yRmA3fALay94SWPKA3NXWkKRtEFqxROYZv5PNz0+aBPGpaG9N60DCI6K5
         WoNsVUpOVOsnEEm6pEQwOa0uSavfKhomCiCKkxjDqeoI1/nM4ZTRDNKveGZIvZZUizC4
         tjlCnvqsOrKvUH8hJAvP0f+L6zBbBLh/JoQk7+sPVK/VSA/BalLn475hY2EPU3h6TZvW
         jxBQ==
X-Gm-Message-State: AOJu0YzGm9RozNe23zUUWP9tcK1PDeZCvUmnY0sn8qySMh+CGJQXqmSV
	bXKzrFTHf6gcC2KwbWi1jCQkx3bjtGqOfTWnG6sgCFBuAmKaSWqDQWOrTUYwBRMx1FE=
X-Gm-Gg: ASbGncvAl7/BfXyciZx3iGaEkU7J7iJVIePjPTefT1dpeUWOEqkjF/y6DFeN//JFrKA
	sp+FClcAfm0lZ4o8N2KfiUwGUmd6BJXSW7Ihw1bKs1+ws/YlSc6SEXzTclgiQdE9ZSlb1kwshtx
	yCZroqR+J5vFnja9EcHFtVSUYLmUURbXP4kYCL6rDH+/PU8ZtKrzVgE+MTGHqXt14NXFas2HS3p
	MZG97qEBEc5jwnEtQjTgzPNklJB4JbroY6OR56KacLm9q4b7npKbZaQRe42anA9QIx6hTzc8NZI
	h533qCLjfAXI9MpKl8xd6wQ4gI689ZS50exzAIJx+yv1qZ5v3nimlorlOXP1
X-Google-Smtp-Source: AGHT+IFGP9Q9Ra0qDS6F9YtZKKUK7gp31Xom7HJcchn2POZnvWlQq1OWJJsv1FTEWbuIMCg2h7kXSQ==
X-Received: by 2002:a5d:64c5:0:b0:391:3aaf:1d5f with SMTP id ffacd0b85a97d-3a4cb4c6b6amr13879968f8f.52.1748367561719;
        Tue, 27 May 2025 10:39:21 -0700 (PDT)
Message-ID: <9dc93703-7758-42a1-a4b3-49fa35b881ae@citrix.com>
Date: Tue, 27 May 2025 18:39:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/ACPI: move scheduler enable/disable calls out of
 freeze/thaw_domains
To: Mykola Kvach 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach ,
 Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <974033e9ff0df3ce8a74efaa33f1cee1dcbdb030.1748340071.git.mykola_kvach@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: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27/05/2025 5:17 pm, Mykola Kvach wrote:
> Hi, @Andrew Cooper
>
> On Tue, May 27, 2025 at 3:53 PM Andrew Cooper  wrote:
>> On 27/05/2025 11:04 am, Mykola Kvach wrote:
>>> From: Mykola Kvach 
>>>
>>> The scheduler_disable and scheduler_enable calls have been removed
>>> from freeze_domains and thaw_domains, respectively, and relocated
>>> to their usage context in enter_state. This change addresses
>>> the concern about misleading function semantics, as the scheduler
>>> operations are not directly related to the domain pausing/resuming
>>> implied by the freeze/thaw naming.
>>>
>>> Suggested-by: Jan Beulich 
>>> Signed-off-by: Mykola Kvach 
>> FYI I've kicked off a run with this patch:
>>
>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1838715729
>>
>> which includes the real suspend/resume testing on several pieces of
>> hardware.
> It appears I made a mistake by failing to mark this patch as
> containing only non-functional changes.

x86 suspend/resume is sufficiently fragile that you only have to
threaten a change for something to break.

But yes, "No functional change." goes a long way towards helping the
reviewer.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 27 19:34:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 19:34:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998692.1379412 (Exim 4.92)
	(envelope-from )
	id 1uK04P-0003rq-Rh; Tue, 27 May 2025 19:34:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998692.1379412; Tue, 27 May 2025 19: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 1uK04P-0003rj-Ou; Tue, 27 May 2025 19:34:41 +0000
Received: by outflank-mailman (input) for mailman id 998692;
 Tue, 27 May 2025 19:34:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK04O-0003ra-0N
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 19:34:40 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2416::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9cab4688-3b31-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 21:34:33 +0200 (CEST)
Received: from BN9PR03CA0518.namprd03.prod.outlook.com (2603:10b6:408:131::13)
 by BN7PPF7B4E3DFF8.namprd12.prod.outlook.com
 (2603:10b6:40f:fc02::6d4) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.19; Tue, 27 May
 2025 19:34:28 +0000
Received: from BN2PEPF000055DE.namprd21.prod.outlook.com
 (2603:10b6:408:131:cafe::1d) by BN9PR03CA0518.outlook.office365.com
 (2603:10b6:408:131::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Tue,
 27 May 2025 19:34:28 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000055DE.mail.protection.outlook.com (10.167.245.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8813.0 via Frontend Transport; Tue, 27 May 2025 19:34:28 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 27 May
 2025 14:34:25 -0500
Received: from [172.31.32.79] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 27 May 2025 14:34: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" 
X-Inumbo-ID: 9cab4688-3b31-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NOmBKyC1JWbSd47fSMGyL2OUwmsYNWtBeuMMmZzKaaAdAXN+lrR84alK8DECvRKJ62HblfSeiBbjBGr4XyaRH5Rgrry1HzIaOllpU/4znQyJnCnaFBtScFds1IKA9VcmA0uwcfIQePOrJeRkHSDPieX+TTXQd/sbRsoCUwK5XkRL0TbEAlGazitNvTKmZZMJzlh72k/PIovdBY8nvG8yzzyoSiLc/xSWHMCJ6fhSML7nnVouxqVj2XmJQ2GxLl2Ehw6DCoD7NzpCOmPF4S+c9f9pfc3T44u59z2R7fqZ/LJDjZDMC9LxVWq/X0KMhg8LqLYvW/uZH9cltVHzWflLxw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ElUKYOw/rBcVOW+adollVjkLiSajyL2NiEoQ4A9UA2k=;
 b=TsihWP3SCLV22kOvDrMFjSjAk5AsM70LzPp3ScZDaEdsBZQkFY2ExOwVYXYQsh54lg/V3swm+pdnNWGGfc9l3jE/HWj9fVOTDoituQsR86Q5EedE/WZRjbFl/X+5+CyMXkvgzW+H4wj7uKnbofxPRc70l4VSWqnETVoRmH34AmiKJvYcmDTnNn5Kk7DSjDwGaYk6J/8J5q1T3X2F8kxznitiWxCr16zeBWRMHv6vWkOKlJ+Zhdj/K3RZSQleh3EdRvJir2V9QY+WrgdiChxYlkhCOgA6xhG0kNWNz+0DI9Ouiuo8wym5FmE60eF7LR7n6qDcvGBpffzuOv4WEZ3llw==
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=ElUKYOw/rBcVOW+adollVjkLiSajyL2NiEoQ4A9UA2k=;
 b=o6enH5QLgB2gz82Hhq3YeuyMsasinp+DR2r24PYF4lvWjtgJ2IkVFPYW7wS38uOGHLJ9ifYHaf51qsRJOc7Mrv1FleRP0u8rXvESzlz4zal4n9ifEeyztE6PrKHZ5sf5pTW/MvCS0EK4lmsE5wMXaU29IXlv1RQn1TayyuR+8u0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Tue, 27 May 2025 15:34:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/hvm: Drop unused vpic.h includes
To: Andrew Cooper ,
	
CC: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <20250527150330.47108-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250527150330.47108-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000055DE:EE_|BN7PPF7B4E3DFF8:EE_
X-MS-Office365-Filtering-Correlation-Id: 6d5b1fa3-c61a-4052-32ae-08dd9d557ed4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WTVFWVJzWlJoWXFaVkJiNlN4V2Y2Vy84ZW5ZK1grWHFkZkUvc1paUG03M09v?=
 =?utf-8?B?VVdMT2V4b1loTytRR0gwNGRMVDhYVHVJWDNXM1YrcjIxWHM1L1k0bVovSnZX?=
 =?utf-8?B?NDhqejNaOVAwQjlBbmExTitFdFR3dnJRN2RsWVI0VUNNbnMrYVpVejJqMmZZ?=
 =?utf-8?B?eDV1cTF4dmJNMmtZVmppWGZqZUxhM1dqMEhuZnV5bmtRMG5GeGEzL2hYb2Yx?=
 =?utf-8?B?ZTd2dVc2bkZOWjQ2N1hhRzdlQWREVzNIV3lFUy9lZ3c5SlpYS0pEM0ZMS2Zv?=
 =?utf-8?B?RlA0ZmpzMTZsWjM5ekI0Zm0rQ2tlUFdFeldQd0lmQ2hqU1QwT0pvSzl1eS9S?=
 =?utf-8?B?QUtpNjc1eUhhNURPV0NZTDY4SC8rMTVncnlzdi9ENjV0L3cvcFBNTm45QzFp?=
 =?utf-8?B?a0RMd0h0K2hQaTJTNm1WaE5EVFJnMThoQ3BqZUVkRGpoL0NQWWE5WFVkRk00?=
 =?utf-8?B?aktOMldCQzRpaXh1VEJGNzhsb1llZHMwSjRhSGlDWW1GVzhYZmp3Y1ZpbXRY?=
 =?utf-8?B?M0RIV3JVelRmZGEzK0lBRTBFVTlpUUdjOXd1dHpWTXNuaUxqSG1nYzkxRTZ3?=
 =?utf-8?B?Si9nVGFZRll1V0ZHNktoeVF5R3pneXVkU0ZUNTlKUU9GbWNYOThWUGRNeGRN?=
 =?utf-8?B?RDJ6SG5XNVlvUnB4TUVKNlZzV0VDQ2hBQTFUQ3RpT1VwR0xFSlFhdllOZGFT?=
 =?utf-8?B?WVN5WGFqS0JlUHlrUlRPZi91MVFXajBMaTR2NWw5dUVxb3VxTE5qTDNEOUFp?=
 =?utf-8?B?ZzgyU0kvdUJvV09tWlFvYitpeVZ1eDdnNUNJQ0lxRC9hcTF5a0gvRnBidkda?=
 =?utf-8?B?S3hNMDFUc0VhdFZJdkp3OXpYK2JvOXE2TmJtR0U5R2NMZUlobkovWTVObzlQ?=
 =?utf-8?B?Si9QNEV4Z1FqWHRyOXRWQUovc1pmc09kWERtL3dNcnByQ0lUSy9rTzJrRkZE?=
 =?utf-8?B?aWlJeStyVDZQeVR3c2lYYXg0VnVkdGplaW5lclpBeU1YZnQzcUhCcDRGK0k4?=
 =?utf-8?B?bjdkMmtTYmVZcjFmbW5zaWNxVlFlMlBzdVgxdkRCQXBqWlVlbzB4UWZJR0dz?=
 =?utf-8?B?d1FRWEMwT0hreFlmcHB2V2ZkTjJUL04zWTkrQ0pMNUNYdUM0L3FYKzh2S1ZP?=
 =?utf-8?B?OGRMKzJ2UDVTZi9nT04zaW5ya3RtS2hCUGZaazhycnZHaVl5M2xqcDM1SFZr?=
 =?utf-8?B?ZnVraGNaU3lTZ0ZMVVdSbTRPSTBTQU5jY0tMQzBSOEoxUlRkYVRUd3RldlZk?=
 =?utf-8?B?QTVJTVl0d3RGTkR6bGxUSWJHSnA5M0pldDdodXNFSXlzMWRaeER1akYrM09m?=
 =?utf-8?B?enBsYzN1SFhiRXpRRXgyY2RrUUVaRGFzNnV3Z2dyRXhVYVJRTW5XSHlHNC9p?=
 =?utf-8?B?aVRFbzBOT0tzdTBIb1dTZEtGemEwZGs0Si9QdWpDYW5LNzZnNkVPRy8wZjBu?=
 =?utf-8?B?cW1UYmhVYytLaG1PUno0TG05QlNXZjFTd3M3aWE4THAzWHVHUzU3U3F1dk9h?=
 =?utf-8?B?a3oxakhHUzYxSjdWV1ZPWU5KVkZTMVVsUVdhK1VidHhZVDZPbTNzZC9xZTB1?=
 =?utf-8?B?UHJoSWRld09mOUptcnhiVWc1SWkrY2ZsN2JsMnU0TVZ5RGVGMDBXVDd2Szdu?=
 =?utf-8?B?cjNyQjBqMnlscGVvVW1pVmVEZUlWTHlCNmY5MWROcjdWT1pYaFVoSGZxWGE2?=
 =?utf-8?B?TkNVdThUUHVmRmN3SS9hanc0eS85YkxGOEtKTXB6UjIvQk5kMVRCakZFdURS?=
 =?utf-8?B?VzdJR2ZzV2wzekFrcGtKR3VEZW1RMnlGSGxkdVNhbUpGeWVCb05zdW56ZTBM?=
 =?utf-8?B?a0ZHVGplcFVndlMxMGJ2M3htd1ZOdU1uNEZPNW9VdE5XdEZ2T1YzaXBLU0Z2?=
 =?utf-8?B?VFRaUXNFVFg5WVVHa01Rck9EZTZCSTVYaHNLeHBuUFdKWktxdGhHRDVMVDM2?=
 =?utf-8?B?bGNyQmt0Tjl4NndKVG5mdHZQUm9oM0FlMlNrYU1TM1gzaFB5QTZMYXU3Tm11?=
 =?utf-8?B?ak9NaWtxTFRiZzRlaURNR0RRT1BBbDFhOEdVQU1yOW1ESHpQWUlVNko2TmFB?=
 =?utf-8?Q?RdPCOZ?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 19:34:28.1670
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6d5b1fa3-c61a-4052-32ae-08dd9d557ed4
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000055DE.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF7B4E3DFF8

On 2025-05-27 11:03, Andrew Cooper wrote:
> It's only hvm.c, irq.c and vcpi.c which need this header, and they all

s/vcpi/vpic/

> get it via asm/hvm/irq.h.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Tue May 27 19:56:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 19:56:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998701.1379422 (Exim 4.92)
	(envelope-from )
	id 1uK0PP-0006gE-Gz; Tue, 27 May 2025 19:56:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998701.1379422; Tue, 27 May 2025 19:56: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 1uK0PP-0006g7-DQ; Tue, 27 May 2025 19:56:23 +0000
Received: by outflank-mailman (input) for mailman id 998701;
 Tue, 27 May 2025 19:56:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK0PO-0006fw-3s
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 19:56:22 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a90a2266-3b34-11f0-a2fe-13f23c93f187;
 Tue, 27 May 2025 21:56:20 +0200 (CEST)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-54b10594812so4949667e87.1
 for ; Tue, 27 May 2025 12:56:20 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5532edde873sm7648e87.42.2025.05.27.12.56.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 12:56: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" 
X-Inumbo-ID: a90a2266-3b34-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748375779; x=1748980579; 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;
        bh=M0ACmCi6DjDOLF0IFUFMx4BwdOZTd31cVjcN0muT9K0=;
        b=PKH6pNohFcesOuUBnCGogR6sFf2pxhTPLfmZlbcCVap646UEtGUNJJ7H9Z4XRSPaiH
         xA90cS5NEh1zwPPqZhzDr4FMq0SsuUSNXcZfSnw5dLg/SVsQrTgpwh8wEuYhjbqJvz/G
         Ej4Wf1O8kzl68UeNpwveC+2NqkZZmfbVDVxILf7kw35rGhhsYurFPWEIY+aJLCjsUroO
         XkMdNkpGjgEPS5YMeP853kjOCoXE3EBaVgk1ue/uYqACNuTwdtVPdm5afzQew/FvLd7G
         5zotiKubdxyp/+qRgvkUz92QcXAE4MyjONuIc4VeAR2oby1EpcYKiqt9i1RlT9NmekS8
         cggg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748375779; x=1748980579;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=M0ACmCi6DjDOLF0IFUFMx4BwdOZTd31cVjcN0muT9K0=;
        b=UPmlEt3jyZsDkQI4e6FP8vzLXi1eWmoZScf/LEWpuVEsAJsnX8kSPqMvVJqH0kB1u7
         0WIYkYlLiqwYOiXAccuVNfhUD0M93zpxXph0NwcPOJrQX07WLonIRsrD0oMnorhrYO0r
         21JPLgnxgXmYHpwaSt4GANqu21WZWRa66ufPHkjk0p7Lrw5dscUBFFL75t5XjIf1/ujI
         toSZJ4t+xng7phJs8dIy7Y7avmzARKbB1IhNqf4NW3p8bIzimq/LijofVemRIOmDz4GZ
         0fHIi+fLehQ2pE2kSgo9OWJ9u+g7QQNqMO0C0jiyjdDEmjkQOHu5Cd/b2ZtxiN+Bj6rP
         Tq9A==
X-Gm-Message-State: AOJu0YxDN7rLib2GroIY0DltbChrS4Z4pNtQ7QFVXi9600ngNt6ltdar
	TOUYIRmOwAuNmUw1v7nBBX3EcYqmpeDgsgTy/h29w95jCEco1bt3vv4kiGI5agi6vvs=
X-Gm-Gg: ASbGncs7zkdF3eVHMXJ5ZNZaY+/F0wJondSSkeOdA2xhDrZmUpgC8IwgFZ7cYFuNe21
	CpH4FORAEMRlZNrlIPj4z/6elCrV8nJ4Ngu1fPRpXWD0dL1qYXJXjm1Zmk/bBH5mlDlJt3vocec
	mD7v3j0YqrHQM79jZ29MHH7/VK/1aOA/mJcDhrO/kYZbGRHMWzKYQlpmoMO9oDf68g8T36Bw/0L
	xdc7VJ7oUJbNiwwKHXajEoheLMzmc6iHmZRdyEDnIkidTMiFAfvxMBdnYstkOdusQqeTBFXP23z
	czIwBJPzdfXcZ+mL4s/7Wd9f9MrYyJZoC2XyHaRu4e36SMaPHRi6bDpSvrLDRliIpADRfBGndS3
	Sk4n/+5d0p1q/uoGi2dAG+n0=
X-Google-Smtp-Source: AGHT+IFR1tPw/3LurGIgiLuwjbvfYjKS2oLzFBFxDyCMQ+QLj3atqPptmGtPiO10TwYPMQ/C2k1O3A==
X-Received: by 2002:a05:6512:224b:b0:550:e4f5:741 with SMTP id 2adb3069b0e04-5521c7a8422mr4711395e87.9.1748375779265;
        Tue, 27 May 2025 12:56:19 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com
Subject: [PATCH v1 0/3] xen/arm: Add option to optionally disable trapping on unmapped mmio
Date: Tue, 27 May 2025 21:56:13 +0200
Message-ID: <20250527195616.874614-1-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

This follows up on the virtio-pci discussion and adds a per-domain
option to select the behaviour of accesses to unmapped mmio ranges.
The new option is trap-unmapped-mmio. For dom0less I negated it to
be able to use a boolean prop and keep existing behaviour, i.e
trap-unmapped-mmio-disabled.

I'm happy with any name though so if you have better ideas please
suggest them!

For the domain config i followed the example of x86 flags
and XEN_X86_MSR_RELXED, creating a flags field for ARM.

Thanks,
Edgar

Edgar E. Iglesias (3):
  xen/arm: Add a way to disable traps on unmapped MMIO
  xen/arm: dom0less: Add trap-unmapped-mmio-disabled
  tools/arm: Add the trap_unmapped_mmio xl config option

 docs/man/xl.cfg.5.pod.in              |  6 +++++
 docs/misc/arm/device-tree/booting.txt |  7 ++++++
 tools/golang/xenlight/helpers.gen.go  |  3 ++-
 tools/golang/xenlight/types.gen.go    |  1 +
 tools/libs/light/libxl_arm.c          |  7 ++++++
 tools/libs/light/libxl_types.idl      |  1 +
 tools/xl/xl_parse.c                   |  3 +++
 xen/arch/arm/dom0less-build.c         |  4 ++++
 xen/arch/arm/domain.c                 |  2 ++
 xen/arch/arm/domain_build.c           |  3 +++
 xen/arch/arm/include/asm/domain.h     |  2 ++
 xen/arch/arm/io.c                     | 33 +++++++++++++++++++++++++--
 xen/include/public/arch-arm.h         |  9 ++++++++
 13 files changed, 78 insertions(+), 3 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 19:56:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 19:56:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998703.1379439 (Exim 4.92)
	(envelope-from )
	id 1uK0PR-00070r-5R; Tue, 27 May 2025 19:56:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998703.1379439; Tue, 27 May 2025 19:56:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uK0PR-0006zU-1A; Tue, 27 May 2025 19:56:25 +0000
Received: by outflank-mailman (input) for mailman id 998703;
 Tue, 27 May 2025 19:56:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK0PQ-0006fw-HI
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 19:56:24 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id aae83a57-3b34-11f0-a2fe-13f23c93f187;
 Tue, 27 May 2025 21:56:24 +0200 (CEST)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-551fb4d153dso4512477e87.3
 for ; Tue, 27 May 2025 12:56:24 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5532ede9ffdsm7253e87.69.2025.05.27.12.56.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 12:56: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" 
X-Inumbo-ID: aae83a57-3b34-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748375783; x=1748980583; 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;
        bh=vngFOrYt1JIZC6w4O6KMiqSaaieHXb8/DgKrm2QoDwc=;
        b=OBUpXaPx5pGiFnIsa0NhKGsRlku4XM6txbbT9Si18Nn9P/2DEQatNLw6a3Avnar3tL
         3HozaU5jW5cN95MXwOfb1GLaBKN14OHPtbB3zBu4TF3P1CBlhr2413PsW3XBl4BfRXwA
         mutHK4wlipAOgBkoTKxEpIPAW1shYI9mbl8CiDANnFn8p1SzDOvsGNNrhflcFFL1KWkQ
         KnAsEOWZ80ZvxlBeWg/YIbqo8RKP8kS6oG+6fxV0A0GkJf2cIZsMvgXHma1tBCN7SIi9
         SAkapv5Sl/hua4dgBU28scbs1GHG9KaQ/ntJlBiA+FlFeVKfel2ZBq8rhMQOGWpnhtjS
         FBpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748375783; x=1748980583;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=vngFOrYt1JIZC6w4O6KMiqSaaieHXb8/DgKrm2QoDwc=;
        b=b6RNeAZOhHVbxwsXE6DFp7jPwW635S0xsYNg6I/qBSMV7f7VdG24kQMwtfmtW0BS0c
         d1U9J5I6h701m+6772QSUljWA+LnXjuoI5z2/rataUG0anXs8BZn5W1a4BasnRESgOCr
         iHA0pL6DP0pZOgv62slbfkc/GqTvmadyw+GwFIQJLE0yTpQ07MAv3s/fouinXGZw+SYN
         R/nFaD729H97WkTOG4eB+r6P13djCOYAlLoJ/1cMb7x5ieDKNb45LV4afFT0/Iutt1r5
         zVQMHPVwH7sJ6y+wSYYjnmevjgAgznc0wVlWRvgIOT5sncG9LjiFORAc+LlMGpItnH+I
         Tgcw==
X-Gm-Message-State: AOJu0YxlHvVEcnnyhlkD4RecZXVa3G2QK12lLT87ANnwtmDVwwhIpbQf
	c4mGIkpabUgkp1ShiBHk+Alh8u5u7P3RYaMa6JJmSd/KtjfKvk/4qphIC04HUKfvGqw=
X-Gm-Gg: ASbGncv3ebk+28CMxoyUVi+wa780b10DCXpbYvzeVgLnm8gtSdchqPn+k/v84quqA35
	QkaTM28uU1VdinxbHuE+dAAGPaYVTkDzEhYaWubcBfJ17MLcMm2a+KLMGpRygMAo87066kGLwPt
	OfLu42p1tXuzeqddpOTQ84vvUf4aJZpBRRv+OKduokaEOkzAvjQOlDWv30m6CFHYpQfGo+zLkzf
	7X6H5z4y0y/Nj2B8Q8JoYH7yiJzBZHukgegvsu5GwEzx+2dR47CyNVFKBolvyKR9xQFvBfrxlCe
	yQwqjFCyMLDlfzUP2brl8R+2npFQhFlweapWjCzyvyW3Ut8GrBUCoLQxJ9Y/fh8Et2sTnJcuEjN
	DTbXa726kZVRU2nVOr0MjiD8=
X-Google-Smtp-Source: AGHT+IHR+DnsITbWw3w2KJ6g1xT+1csv74B4Ak8LZYh+iyCpIdRa16eHii8xvgpf58bV561Lmfxtbw==
X-Received: by 2002:a05:6512:39c3:b0:54b:117c:1356 with SMTP id 2adb3069b0e04-5521cbafc09mr4298306e87.56.1748375782892;
        Tue, 27 May 2025 12:56:22 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com
Subject: [PATCH v1 2/3] xen/arm: dom0less: Add trap-unmapped-mmio-disabled
Date: Tue, 27 May 2025 21:56:15 +0200
Message-ID: <20250527195616.874614-3-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250527195616.874614-1-edgar.iglesias@gmail.com>
References: <20250527195616.874614-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Add the trap-unmapped-mmio-disabled per-domain fdt property.

Signed-off-by: Edgar E. Iglesias 
---
 docs/misc/arm/device-tree/booting.txt | 7 +++++++
 xen/arch/arm/dom0less-build.c         | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index 59fa96a82e..75fbb245d1 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -225,6 +225,13 @@ with the following properties:
     option is provided with a non zero value, but the platform doesn't support
     SVE.
 
+- trap-unmapped-mmio-disabled
+
+    Optional. A boolean property that configures handling of accesses to
+    unmapped MMIO ranges.
+    If set, guest accesses will read 0xFFFFFFFF and writes ignored.
+    If not set, guest accesses will trap.
+
 - xen,enhanced
 
     A string property. Possible property values are:
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index e5e13e07d0..cd1ef05d89 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -344,8 +344,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
 #endif
     }
 
-    /* Trap accesses to unmapped MMIO. */
     d_cfg->arch.flags = XEN_ARM_TRAP_UNMAPPED_MMIO;
+    if ( dt_property_read_bool(node, "trap-unmapped-mmio-disabled") )
+        d_cfg->arch.flags &= ~XEN_ARM_TRAP_UNMAPPED_MMIO;
 }
 
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 19:56:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 19:56:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998702.1379432 (Exim 4.92)
	(envelope-from )
	id 1uK0PQ-0006tn-OE; Tue, 27 May 2025 19:56:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998702.1379432; Tue, 27 May 2025 19: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 1uK0PQ-0006tg-JR; Tue, 27 May 2025 19:56:24 +0000
Received: by outflank-mailman (input) for mailman id 998702;
 Tue, 27 May 2025 19:56:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK0PO-0006fw-S7
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 19:56:22 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a9ee8c48-3b34-11f0-a2fe-13f23c93f187;
 Tue, 27 May 2025 21:56:22 +0200 (CEST)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-553280c345cso1315068e87.0
 for ; Tue, 27 May 2025 12:56:22 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5532ee71af1sm4355e87.212.2025.05.27.12.56.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 12:56: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" 
X-Inumbo-ID: a9ee8c48-3b34-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748375781; x=1748980581; 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;
        bh=PW4Ul/brgurN+ahlG/LjWsE4mRdaFGlUa4ZnyTf/6ck=;
        b=bw/xY25X28E+cPcQavaGvMJAf8FI5XSin7ALy7NZHdn/AUSjuZjd4AATsf/QHh+c7v
         hNdJQV1Svwmvenii3WIOZ/+1bLWwB0p9FBbe6g+9efqpT1mMFSuQKih0dCYLIViwSw1G
         IV94JfpaseMJJdkI1NWZE7PJUNTJrpu8oeCJmWe885E3ppSr5ndmfzn01yiyyCOO53nJ
         +zM0y58S59wI0kupc+0IiF9K/sv89gxjnio6OsBe+5VgGRFcx4TxjR0CDoKt0vmejyHd
         GCvk0rKVexm+2uIos9t/FCdqVpDr5Jlgs2YYRW8RwJm25m3A/Ay2VPWX73WKf8Uc3qpW
         pzyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748375781; x=1748980581;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=PW4Ul/brgurN+ahlG/LjWsE4mRdaFGlUa4ZnyTf/6ck=;
        b=NIp+2Q5dkuRjdl/ugDSn7IJETKfLdPIZMt1dDRhBT//trBbqzWaVJsqtSCLbTl3d26
         1W+9nzdjMrZcYbad5OEw5zdsiGfxtVjziH8MPZOD3p04vtfb0wS0nNVRR2Sq2mIhA+Zm
         P1jzWu5ml+OPEV29VSSs09ZynRMH9+1ZLMTwYwvfRufzvhLq8Gvmv3vYpAsYoRQIQ/4n
         H4eO4NmxW6wXojthmMDn1TapfGC/qU+s0/ZeUCKoOaJMDgh4IbLVa6YGSjInbqx3IkB5
         EYdhMpMd7CbZvOicFNRfBKBsXxvdNcGhdcdY1W31OaLNrFD1mlRi92LgZzqbovjzyY/X
         MEOA==
X-Gm-Message-State: AOJu0YwC3B1Jy/3sVacn574JU/hr9Lgr8A1dK+fwPwu8+NiQxm0P2bHh
	hBK/wMJk2vNkF6hMBrp0aCgjeRe/8V+GvhdQ5k2ODJ0OsJBQtDzBzOHdnDMkDFN0i2k=
X-Gm-Gg: ASbGnctaAUr7RSASOg/0jpGySVIqh67gh++EIhuN1BLglusxCHb94rUyiLGbMJA87R6
	U/VtZa0N8IkZIXCSFsff0fJUQnl7iHv6pko+27j/x0rCUhSFkPGchGWQ0JtrriDykcq1askFUgO
	cKqDIqv3qsA370JTnh5Kdwf4EtzSiKEAaVWJf/7R0IMNILihLWQiY1XxaOGR2ykzNz6IOVTHN+p
	I4k/vp6STwr2t05zxBHkFzJYgKqax6X0MR016a8FMkgN3Xsa0fRFsJKFChK/DUikjk7BFzCWAzi
	i6Kg8cWwtUKRaChvAWKMr6P59Gdilqt4iIBACTVPx8gjyg9wxAna3293CgqQwPzBjV1TU4VXzt5
	osk67u6bB7n8Uuh5uiHQpxK0=
X-Google-Smtp-Source: AGHT+IHrDm2Qy6vp9VEqaHnRTakLi2LeAuU7KzcB3N2VPuRneBPy+2xU8AZM4IMeoq4oAeVXe0vaGA==
X-Received: by 2002:a05:6512:68f:b0:54f:cc4e:a9ef with SMTP id 2adb3069b0e04-5521cba987cmr4748985e87.43.1748375781216;
        Tue, 27 May 2025 12:56:21 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com,
	Anthony PERARD ,
	Juergen Gross 
Subject: [PATCH v1 1/3] xen/arm: Add a way to disable traps on unmapped MMIO
Date: Tue, 27 May 2025 21:56:14 +0200
Message-ID: <20250527195616.874614-2-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250527195616.874614-1-edgar.iglesias@gmail.com>
References: <20250527195616.874614-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Add a per-domain way to optionally disable traps on unmapped MMIO.

Signed-off-by: Edgar E. Iglesias 
---
 tools/libs/light/libxl_arm.c      |  3 +++
 xen/arch/arm/dom0less-build.c     |  3 +++
 xen/arch/arm/domain.c             |  2 ++
 xen/arch/arm/domain_build.c       |  3 +++
 xen/arch/arm/include/asm/domain.h |  2 ++
 xen/arch/arm/io.c                 | 33 +++++++++++++++++++++++++++++--
 xen/include/public/arch-arm.h     |  9 +++++++++
 7 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 75c811053c..40cd005619 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -233,6 +233,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
     }
 
+    /* Trap accesses to unmapped MMIO. */
+    config->arch.flags = XEN_ARM_TRAP_UNMAPPED_MMIO;
+
     return 0;
 }
 
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a49764f0ad..e5e13e07d0 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -343,6 +343,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
         panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
 #endif
     }
+
+    /* Trap accesses to unmapped MMIO. */
+    d_cfg->arch.flags = XEN_ARM_TRAP_UNMAPPED_MMIO;
 }
 
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 45aeb8bddc..54c6ae7678 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -714,6 +714,8 @@ int arch_domain_create(struct domain *d,
     ioreq_domain_init(d);
 #endif
 
+    d->arch.trap_unmapped_mmio = config->arch.flags & XEN_ARM_TRAP_UNMAPPED_MMIO;
+
     /* p2m_init relies on some value initialized by the IOMMU subsystem */
     if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 )
         goto fail;
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..c3c8212260 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2018,6 +2018,9 @@ void __init create_dom0(void)
     dom0_cfg.arch.tee_type = tee_get_type();
     dom0_cfg.max_vcpus = dom0_max_vcpus();
 
+    /* Dom0 always traps on unmapped MMIO.  */
+    dom0_cfg.arch.flags |= XEN_ARM_TRAP_UNMAPPED_MMIO;
+
     if ( iommu_enabled )
         dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
 
diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
index a3487ca713..4d1a180ce2 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -121,6 +121,8 @@ struct arch_domain
     void *tee;
 #endif
 
+    bool trap_unmapped_mmio;
+
 }  __cacheline_aligned;
 
 struct arch_vcpu
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 5a4b0e8f25..11ffa48969 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -21,6 +21,32 @@
 
 #include "decode.h"
 
+/* Handler for unmapped ranges. Writes ignored, reads return all ones.  */
+static int unmapped_read(struct vcpu *v, mmio_info_t *info, register_t *r,
+                         void *priv)
+{
+    uint64_t mask = GENMASK_ULL((1U << info->dabt.size) * 8 - 1, 0);
+
+    /* Mask off upper bits.  */
+    *r = UINT64_MAX & mask;
+    return 1;
+}
+
+static int unmapped_write(struct vcpu *v, mmio_info_t *info, register_t r,
+                          void *priv)
+{
+    return 1;
+}
+
+static const struct mmio_handler_ops unmapped_ops = {
+    .read = unmapped_read,
+    .write = unmapped_write
+};
+
+static const struct mmio_handler unmapped_handler = {
+    .ops = &unmapped_ops
+};
+
 static enum io_state handle_read(const struct mmio_handler *handler,
                                  struct vcpu *v,
                                  mmio_info_t *info)
@@ -178,8 +204,11 @@ enum io_state try_handle_mmio(struct cpu_user_regs *regs,
         rc = try_fwd_ioserv(regs, v, info);
         if ( rc == IO_HANDLED )
             return handle_ioserv(regs, v);
-
-        return rc;
+        else if ( rc == IO_UNHANDLED && !v->domain->arch.trap_unmapped_mmio ) {
+            /* Fallback to the unmapped handler. */
+            handler = &unmapped_handler;
+        } else
+            return rc;
     }
 
     /*
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e2412a1747..32b023504d 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -350,6 +350,15 @@ struct xen_arch_domainconfig {
      *
      */
     uint32_t clock_frequency;
+    /*
+     * IN
+     *
+     * XEN_ARM_TRAP_UNMAPPED_MMIO enables trapping of memory accesses
+     * into unmapped ranges. When disabled, Xen will handle the access
+     * by reading 0xFFFFFFFF and ignoring writes.
+     */
+#define XEN_ARM_TRAP_UNMAPPED_MMIO (1U << 0)
+    uint32_t flags;
 };
 #endif /* __XEN__ || __XEN_TOOLS__ */
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 19:56:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 19:56:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998704.1379452 (Exim 4.92)
	(envelope-from )
	id 1uK0PV-0007PW-BH; Tue, 27 May 2025 19:56:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998704.1379452; Tue, 27 May 2025 19: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 1uK0PV-0007PN-80; Tue, 27 May 2025 19:56:29 +0000
Received: by outflank-mailman (input) for mailman id 998704;
 Tue, 27 May 2025 19:56:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK0PT-0007N3-No
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 19:56:27 +0000
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com
 [2a00:1450:4864:20::231])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id abe1bb51-3b34-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 21:56:25 +0200 (CEST)
Received: by mail-lj1-x231.google.com with SMTP id
 38308e7fff4ca-32a63ff3bdfso16209101fa.3
 for ; Tue, 27 May 2025 12:56:25 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32a7610ce19sm589641fa.14.2025.05.27.12.56.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 12:56: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" 
X-Inumbo-ID: abe1bb51-3b34-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748375785; x=1748980585; 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;
        bh=8uoMcemAbIQbPzslSOx3EYsiOCGjdfZV67/ilufqHkE=;
        b=fhbn8DtQNQqbnqIFfw/CYkBzAXcw557zAWEMDYHQbHO1L2ZDuQfBTuX6xUIOdQr6eg
         jpymoWSNBfl5xMUtf9PFDz8QBvCGe+sML20CIHDhNpBz8YJOJIykQ5XEYDTbPWxW+P79
         FPPTTvjAVjyy8D2JNFhp8EcGfi/u9zrFOBrElSM4dRFn3N3xYqXdVWqfQ4q/qDPRGBFK
         +QStzAh7/ZNMQsEL4oYEBiBg59J/KaS9BCEYQ9/p6+Kivu/dg1X3DPYc9TMwU5MFPAAN
         bT49CcRLFM4jp2l2O2c42E1Gl2jsXMOu3/Y2VDi9fE18lgqKWMpAgNqdthKsDGR7VBWJ
         1QKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748375785; x=1748980585;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=8uoMcemAbIQbPzslSOx3EYsiOCGjdfZV67/ilufqHkE=;
        b=Iw6d7HrjNglTSwINbPYhd3184mMKzAUUS63EGTbp/Ib28NAXl/GIgu6uej4rxr2wDI
         VzM/QSlMAX3HGh6qQsYNam0zlDj6Mizq4R5HYPZIPAItTtzJp/T4JH9oaHP17pqAS1iu
         aTmvmW1BcWY58rB1als2tQYjsdcLcOPPC25DVRrOxocRb1nlk6+x1TLJHSRRiMFtEcuQ
         uQL0487KoDoLYBF34uYXwROo9zhM0roggzuC/Og7klWqVJA/gEYGZtFs/WJljpH0xwVk
         aD4JNLEWQhbDAtR1LlvcWD0WWNbaD48DR1foxRRlPtPy7Fo9X06z94r+XL3XRcB8lagB
         tYVw==
X-Gm-Message-State: AOJu0YwRcE1iIdtGW7t+SNzgWyl37Tg3DCuh/QxrynzUvXUfcXDUTp2w
	1YOK9I1O19pQYpkZX6jBU7ucREZF7bm49p57mTtEvxzLsIBkZOGUzrwN7E8aBxTk+PQ=
X-Gm-Gg: ASbGncuO6ztNGmbpwvh/WSNSf0K2C5b3ufSm7Uxe2o8Aexvvsw7dbgheahTUvarbI6k
	MdD1e2HLTKuckNEVVx+qoXimlqLHBLwrCsWO6VUwXEJgUhj9a74D1+ULmAoRElP2X/k/+m8vY2y
	lW6J9ZgGj/6FhKtwG1zE1pOsZK0Fk1Ql5bPNGkIOegShUVvOpoI7u9ohIlp/OdsYVVt09sckZQF
	7IpUi5kV1ujMbSVcXLNUQBHil118Ts30xuVP4uI4afwFfRzTfE0tFDZykvlNcRwF0cGWGphXtn8
	KBs/z9IG2Y4EdHHY074qV9iXHZFgKwN0dSstPFs5n8eUsEGm0W4Go+j/X57ipj/V0US+AKmpzmo
	1wmVgsHzetKEJR4n1yVIKKvA=
X-Google-Smtp-Source: AGHT+IGGrSO3iFT/tQMaWnySP3c4+esSsUmT69PdcEitGWv/Yax8lntWxvFNYDU5c6s2y14seZ1z0Q==
X-Received: by 2002:a2e:9fc5:0:b0:32a:724e:ab8d with SMTP id 38308e7fff4ca-32a724eaef1mr9103641fa.40.1748375784578;
        Tue, 27 May 2025 12:56:24 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com,
	Anthony PERARD ,
	Nick Rosbrook ,
	George Dunlap ,
	Juergen Gross 
Subject: [PATCH v1 3/3] tools/arm: Add the trap_unmapped_mmio xl config option
Date: Tue, 27 May 2025 21:56:16 +0200
Message-ID: <20250527195616.874614-4-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250527195616.874614-1-edgar.iglesias@gmail.com>
References: <20250527195616.874614-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Signed-off-by: Edgar E. Iglesias 
---
 docs/man/xl.cfg.5.pod.in             | 6 ++++++
 tools/golang/xenlight/helpers.gen.go | 3 ++-
 tools/golang/xenlight/types.gen.go   | 1 +
 tools/libs/light/libxl_arm.c         | 8 ++++++--
 tools/libs/light/libxl_types.idl     | 1 +
 tools/xl/xl_parse.c                  | 3 +++
 6 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 7339c44efd..6dd0a05482 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3089,6 +3089,12 @@ will be used for the domain. Otherwise, the value specified by the `nr_spis`
 parameter will be used. The number of SPIs should match the highest interrupt
 ID that will be assigned to the domain.
 
+=item B
+
+An Optional boolean parameter that configures handling of accesses to unmapped
+MMIO ranges. If enabled, guest accesses will trap. If disabled, guest accesses
+will read 0xFFFFFFFF and writes ignored.
+
 =back
 
 =head3 x86
diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
index 90846ea8e8..b04561929c 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -1163,6 +1163,7 @@ x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version)
 x.ArchArm.Vuart = VuartType(xc.arch_arm.vuart)
 x.ArchArm.SveVl = SveType(xc.arch_arm.sve_vl)
 x.ArchArm.NrSpis = uint32(xc.arch_arm.nr_spis)
+x.ArchArm.TrapUnmappedMmio = uint32(xc.arch_arm.trap_unmapped_mmio)
 if err := x.ArchX86.MsrRelaxed.fromC(&xc.arch_x86.msr_relaxed);err != nil {
 return fmt.Errorf("converting field ArchX86.MsrRelaxed: %v", err)
 }
@@ -1687,7 +1688,7 @@ return fmt.Errorf("invalid union key '%v'", x.Type)}
 xc.arch_arm.gic_version = C.libxl_gic_version(x.ArchArm.GicVersion)
 xc.arch_arm.vuart = C.libxl_vuart_type(x.ArchArm.Vuart)
 xc.arch_arm.sve_vl = C.libxl_sve_type(x.ArchArm.SveVl)
-xc.arch_arm.nr_spis = C.uint32_t(x.ArchArm.NrSpis)
+xc.arch_arm.trap_unmapped_mmio = C.uint32_t(x.ArchArm.TrapUnmappedMmio)
 if err := x.ArchX86.MsrRelaxed.toC(&xc.arch_x86.msr_relaxed); err != nil {
 return fmt.Errorf("converting field ArchX86.MsrRelaxed: %v", err)
 }
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
index e7667f1ce3..89cc976bdc 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -599,6 +599,7 @@ GicVersion GicVersion
 Vuart VuartType
 SveVl SveType
 NrSpis uint32
+TrapUnmappedMmio Defbool
 }
 ArchX86 struct {
 MsrRelaxed Defbool
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 40cd005619..cce3fc4684 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -233,8 +233,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
     }
 
-    /* Trap accesses to unmapped MMIO. */
-    config->arch.flags = XEN_ARM_TRAP_UNMAPPED_MMIO;
+    config->arch.flags = 0;
+    if (libxl_defbool_val(d_config->b_info.arch_arm.trap_unmapped_mmio))
+        config->arch.flags |= XEN_ARM_TRAP_UNMAPPED_MMIO;
 
     return 0;
 }
@@ -1714,6 +1715,9 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
     /* ACPI is disabled by default */
     libxl_defbool_setdefault(&b_info->acpi, false);
 
+    /* Trapping of unmapped MMIO access enabled by default.  */
+    libxl_defbool_setdefault(&b_info->arch_arm.trap_unmapped_mmio, true);
+
     /* Sanitise SVE parameter */
     if (b_info->arch_arm.sve_vl) {
         unsigned int max_sve_vl =
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 9bb2969931..bd5425fe50 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -724,6 +724,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
                                ("vuart", libxl_vuart_type),
                                ("sve_vl", libxl_sve_type),
                                ("nr_spis", uint32, {'init_val': 'LIBXL_NR_SPIS_DEFAULT'}),
+                               ("trap_unmapped_mmio", libxl_defbool),
                               ])),
     ("arch_x86", Struct(None, [("msr_relaxed", libxl_defbool),
                               ])),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 089a88935a..3099086198 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2975,6 +2975,9 @@ skip_usbdev:
     if (!xlu_cfg_get_long (config, "nr_spis", &l, 0))
         b_info->arch_arm.nr_spis = l;
 
+    xlu_cfg_get_defbool(config, "trap_unmapped_mmio",
+                        &b_info->arch_arm.trap_unmapped_mmio, 0);
+
     parse_vkb_list(config, d_config);
 
     d_config->virtios = NULL;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 20:03:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 20:03:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998741.1379463 (Exim 4.92)
	(envelope-from )
	id 1uK0W5-0001mH-2V; Tue, 27 May 2025 20:03:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998741.1379463; Tue, 27 May 2025 20:03: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 1uK0W4-0001mA-Us; Tue, 27 May 2025 20:03:16 +0000
Received: by outflank-mailman (input) for mailman id 998741;
 Tue, 27 May 2025 20:03:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK0W3-0001m4-UV
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 20:03:15 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9f95cfd5-3b35-11f0-a2fe-13f23c93f187;
 Tue, 27 May 2025 22:03:14 +0200 (CEST)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-6049431b0e9so3688437a12.0
 for ; Tue, 27 May 2025 13:03:14 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60517a7cc93sm56762a12.56.2025.05.27.13.03.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 13:03: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" 
X-Inumbo-ID: 9f95cfd5-3b35-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748376194; x=1748980994; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Gu7H+m0Pzp9L3ltUVMxaOznZEZoo6E9N6ddLmDRYqvc=;
        b=ctfHe+O6tzrMLDaqRLBw53u1HuaCBhs3En6huaa9cn9ONRg+rehFkiAW2ln22lifkX
         bCwcsKkQKS1BKY06AO7tvLSujARTtfn5O2Oufei2L9SEOlQoc30Zp6sW40N0sJNjgiKX
         rlHr/ttgtOwGcatSlqw0wUKZ0ESf0n7tRleLg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748376194; x=1748980994;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Gu7H+m0Pzp9L3ltUVMxaOznZEZoo6E9N6ddLmDRYqvc=;
        b=OdeJ1sMR0TsJPIjM0jur3ua0Zdreuo8yLYdrroK7Z2nhAQBxtPCi9hpkEKxdURRoLU
         w+/1s+ohnHT5BJGpwOEF5bcfUVWJcNr2z5GS48rpqJsAkOA/hH9vn92cbADPWvUnAdS0
         PLKoBYoAd+c9KAPe4YH3qu3D6cM/wSW7944C/zhc7YfXwCcanrGIuaTORHuhNQfG9yVH
         wKRkHfxy7TxrU70gHqWHCqfwMKaRmTV0RL8sVgp024PhHVmsKLs3JWpoSeFAgvz1G/PF
         3S04OAfBI5OR23dzUMx3OuOY7KuhvTmW1TdT1gAZ+3R8CK6rK7xZmz0hbOcCZHxkdW1F
         AHYA==
X-Forwarded-Encrypted: i=1; AJvYcCW7u/kyJiIrXz07bfxMfuYOfxJ3CAghz2Wc40fq38iUT4VPBIJ8AAksaQuh6pT6fR3W9biPhoX/gf8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz54WLiVfoJFlqhJ/13AOG+KhXan4VCIxQZWkPHMpcyS//EVQPe
	L7eh0OG0BagbPs6+QwyyGcays3WUgWdonFtXh2n4nU4DYGMDbZf7t6J1boN/yi2XWMw=
X-Gm-Gg: ASbGncuTs98A9fXgOpwHQCsdI+WCmqheF82Rif7R8J79vqdhxqQK9Eb8/q8tYzunOXT
	VWgm50i84+Yb7E1310YMhkkU2pnZgOZK86pblkv47SxCG9LSPRxi6rzfFmkEguAutiAU7H6pbpM
	07I1ptivg4BIHZ05m6eUyDL8ZiXubBPrwDpxyJrVuJSTKSKFkijYzuhuHmDlwd8Ph7cDcExSm1G
	81+RKL/LiEV5wNyU/K/co5VnlJquarjd9sRXA6pw0o9A0//ZAPA9CUoNOGCdQPQSajCj/TxVhXO
	EUgd669yX2UIz/gu5uizLe8Sb9oKkfQ6mRXFmsmnPjyFNo3fQtexHAdzzrtOy54uDM1sMM+sMMd
	Cdpkkif7PLiwvrHgFGCld793+HOQ=
X-Google-Smtp-Source: AGHT+IFPDBILA9OVcgzewwmD3SFdqalhiUyaHGgLxDKAWIC8Alk/MmG6KWHKS4rNfpzmVClD1Wa8+Q==
X-Received: by 2002:a05:6402:350f:b0:600:1167:7333 with SMTP id 4fb4d7f45d1cf-602d906c71dmr11883927a12.10.1748376193936;
        Tue, 27 May 2025 13:03:13 -0700 (PDT)
Message-ID: <2eac2199-f3e2-4fa8-b6e3-f6cbf999d436@citrix.com>
Date: Tue, 27 May 2025 21:03:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 0/3] xen/arm: Add option to optionally disable trapping
 on unmapped mmio
To: "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, julien@xen.org, bertrand.marquis@arm.com,
 michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, edgar.iglesias@amd.com
References: <20250527195616.874614-1-edgar.iglesias@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: <20250527195616.874614-1-edgar.iglesias@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27/05/2025 8:56 pm, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
>
> This follows up on the virtio-pci discussion and adds a per-domain
> option to select the behaviour of accesses to unmapped mmio ranges.
> The new option is trap-unmapped-mmio. For dom0less I negated it to
> be able to use a boolean prop and keep existing behaviour, i.e
> trap-unmapped-mmio-disabled.
>
> I'm happy with any name though so if you have better ideas please
> suggest them!
>
> For the domain config i followed the example of x86 flags
> and XEN_X86_MSR_RELXED, creating a flags field for ARM.
>
> Thanks,
> Edgar

I think this should be common, rather than ARM specific.

Traditionally on x86, access to unimplemented address space was ignored
(write discard, read ~0), but these days you do get a machine check on
certain ranges, which is for all intents and purposes the same as a data
abort.

So even if x86 requires it to be false in the short term, I think the
control ought to be common, so x86 and others can opt in at a later point.

I don't have a good suggestion for the name, but it's not really about
MMIO space; it's about address space generally.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 27 22:29:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 22:29:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998771.1379471 (Exim 4.92)
	(envelope-from )
	id 1uK2nk-00029P-3h; Tue, 27 May 2025 22:29:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998771.1379471; Tue, 27 May 2025 22:29: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 1uK2nk-00029I-0q; Tue, 27 May 2025 22:29:40 +0000
Received: by outflank-mailman (input) for mailman id 998771;
 Tue, 27 May 2025 22:29:38 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK2ni-00029C-CX
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 22:29:38 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0fceeb35-3b4a-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 00:29:32 +0200 (CEST)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-acb39c45b4eso598802566b.1
 for ; Tue, 27 May 2025 15:29:32 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad89f0890easm20956566b.60.2025.05.27.15.29.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 27 May 2025 15:29: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" 
X-Inumbo-ID: 0fceeb35-3b4a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748384972; x=1748989772; 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;
        bh=3oiHMMn1gOhGUbZjQ+nPA545Sb+2MYIAsishPZ9ofHY=;
        b=neT+ZDog5GTry/drSZSUWQY4j3akrsAcBhtOpH/pRzRQLnrHK0Kw9/O82heihdTMKv
         gJUdbvnz36B2iK2gzxr+Unc9tLedE/w5xmykhw8iJTy4cKpz2AGogKMcW4AeeoT4Oyfh
         K3EjI+x4QOg7POtYtTSxOxTMWJo2u2MZ7HQ40=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748384972; x=1748989772;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=3oiHMMn1gOhGUbZjQ+nPA545Sb+2MYIAsishPZ9ofHY=;
        b=BvWotjMreITfBTd29GJdyWbRry8MuLCTUArAdVIoxtD6Tw2izUpB7JDEcuKN3SImlS
         wtbFQzvuPwxNl4b/DJIJiItoZr20n+WVSb8Zr482MAzwPiS1UYFTMEfsAS3/a94qHWPd
         Ekl5lFxKjQIuT9eKQl3sxY8OzYhuqYuKWR6gINHKCaAewGrpgbRxEGggg8kslkD3clDj
         PtP8eLluepLV4d+UoIrmEsSEI1XNEdrzw6S+eKDlh6rL65w8Ch4l48SRGe1FqJsdt7MV
         bgetbgyOLIlNUfD95uWh6bCgC8Mv6iM3D9HdIBO7Jy+MaXJEJfYxBbR7D3MRv9HzG8v9
         8fgQ==
X-Gm-Message-State: AOJu0YyA7JQEZUHnbOfq+20IHik6q8dvKkdkGtYvDrWv+L9s+Pb/9ggC
	d7ziASjPr3YWO1lAttU8PxU0DRob5o1SJfLtWInEBFbqk60v7/VSV7Xswn7Cnmx4VwcMOL481AR
	tbar9
X-Gm-Gg: ASbGncuYat/VviWuI5cttskvJxfikMAyh2AOXu8QsNrq3YLSJwnG24oOoKYhavbakS9
	OeCAAgsi+yrlc+PmC83EKLsZOwONqF8KlQt9DQt2UM/j7YvttzRkY9Unyo0B3FIzn/yO8KIx14v
	cOvfp6rK1H76+CmHUkRbIPgAiseMFx+1oMnzG/xpfAcGfZ+TRS+nAvNCHRv78x157BAO57KeMLj
	VNXfLbUuaCvSNeRNZYLc8sCXsX+B7Je9ESYyjE1kibtwJpuke7qj6SaHdsUnw38lh8hhzbqH484
	cbqim5uV2hD14BGOJM8xjOUY/zXh98BF1GueR0+4oIf7PUeVjXF65A7PN8p+7UxfXgMFKNCiuEI
	upukuSiSmsLfpYK38N4N5zCVdNsLvorD+b1k=
X-Google-Smtp-Source: AGHT+IFeYNMBj5gwWxSZAb2E+zf1Ivvq+P1Oe4aPcpNWSVMNsf5CJA+r/eltnskHMFCHKbuM7FAYhQ==
X-Received: by 2002:a17:907:9715:b0:ad8:8835:f794 with SMTP id a640c23a62f3a-ad88835f7bbmr492246066b.32.1748384972114;
        Tue, 27 May 2025 15:29:32 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/bitops: Optimise arch_ffs()/etc some more on AMD
Date: Tue, 27 May 2025 23:29:30 +0100
Message-Id: <20250527222930.1452674-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

One aspect of the old ffs()/etc infrastructure was the use of TZCNT/LZCNT
without a CPUID check.  Given no obvious justification, I dropped it during
the cleanup.

It turns out there is a good reason, on all but the most recent AMD CPUs.

Reinstate the use of "blind" TZCNT/LZCNT when safe to do so.  This happens to
be preferentially in loops where a repeated saving of 5-6 uops becomes far
more relevant than a one-off scenario.

Leave an explanation of why.

No functional change.

Fixes: 989e5f08d33e ("x86/bitops: Improve arch_ffs() in the general case")
Fixes: 5ed26fc0768d ("xen/bitops: Implement ffsl() in common logic")
Fixes: 54b10ef6c810 ("xen/bitops: Implement fls()/flsl() in common logic")
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/include/asm/bitops.h | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/include/asm/bitops.h b/xen/arch/x86/include/asm/bitops.h
index 87eac7782f10..62e6ca26f5b0 100644
--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bitops.h
@@ -399,9 +399,16 @@ static always_inline unsigned int arch_ffs(unsigned int x)
          *
          * and the optimiser really can work with the knowledge of x being
          * non-zero without knowing it's exact value, in which case we don't
-         * need to compensate for BSF's corner cases.  Otherwise...
+         * need to compensate for BSF's corner cases.
+         *
+         * That said, we intentionally use TZCNT on capable hardware when the
+         * behaviour for the 0 case doesn't matter.  On AMD CPUs prior to
+         * Zen4, TZCNT is 1-2 uops while BSF is 6-8 with a latency to match.
+         * Intel CPUs don't suffer this discrepancy.
+         *
+         * Otherwise...
          */
-        asm ( "bsf %[val], %[res]"
+        asm ( "rep bsf %[val], %[res]"
               : [res] "=r" (r)
               : [val] "rm" (x) );
     }
@@ -428,7 +435,7 @@ static always_inline unsigned int arch_ffsl(unsigned long x)
 
     /* See arch_ffs() for safety discussions. */
     if ( __builtin_constant_p(x > 0) && x > 0 )
-        asm ( "bsf %[val], %q[res]"
+        asm ( "rep bsf %[val], %q[res]"
               : [res] "=r" (r)
               : [val] "rm" (x) );
     else
@@ -446,7 +453,7 @@ static always_inline unsigned int arch_fls(unsigned int x)
 
     /* See arch_ffs() for safety discussions. */
     if ( __builtin_constant_p(x > 0) && x > 0 )
-        asm ( "bsr %[val], %[res]"
+        asm ( "rep bsr %[val], %[res]"
               : [res] "=r" (r)
               : [val] "rm" (x) );
     else
@@ -464,7 +471,7 @@ static always_inline unsigned int arch_flsl(unsigned long x)
 
     /* See arch_ffs() for safety discussions. */
     if ( __builtin_constant_p(x > 0) && x > 0 )
-        asm ( "bsr %[val], %q[res]"
+        asm ( "rep bsr %[val], %q[res]"
               : [res] "=r" (r)
               : [val] "rm" (x) );
     else

base-commit: d965e2ee07c56c341d8896852550914d87ea5374
prerequisite-patch-id: 8da89000c73c38aab6abfa6622217ea9eff07fbd
prerequisite-patch-id: 74830838bac94ed1e036a8173cf3210a314b35d8
prerequisite-patch-id: 0654835c28df8d40b6c97006d041c4d31447a9a6
prerequisite-patch-id: 2d47d646c6a6e0019918c57753d6c01a752c377f
prerequisite-patch-id: d8f8c4221a2d7039bae6f3d38e93fe90b2091d01
prerequisite-patch-id: e0397c86b545a1d65f2e6b2049c282b926c40c64
prerequisite-patch-id: ea21abe4540ee229f4f8725ce3f701d9ba4bd4a8
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue May 27 22:38:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 22:38:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998786.1379481 (Exim 4.92)
	(envelope-from )
	id 1uK2vw-0003nr-Vu; Tue, 27 May 2025 22:38:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998786.1379481; Tue, 27 May 2025 22:38: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 1uK2vw-0003nk-TM; Tue, 27 May 2025 22:38:08 +0000
Received: by outflank-mailman (input) for mailman id 998786;
 Tue, 27 May 2025 22:38:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK2vw-0003ne-7S
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 22:38:08 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20627.outbound.protection.outlook.com
 [2a01:111:f403:2412::627])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3e6f77a4-3b4b-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 00:38:02 +0200 (CEST)
Received: from BN1PR14CA0023.namprd14.prod.outlook.com (2603:10b6:408:e3::28)
 by CY8PR12MB7586.namprd12.prod.outlook.com (2603:10b6:930:99::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Tue, 27 May
 2025 22:37:58 +0000
Received: from BN1PEPF0000467F.namprd03.prod.outlook.com
 (2603:10b6:408:e3:cafe::86) by BN1PR14CA0023.outlook.office365.com
 (2603:10b6:408:e3::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.27 via Frontend Transport; Tue,
 27 May 2025 22:37:57 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF0000467F.mail.protection.outlook.com (10.167.243.84) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 22:37:57 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 27 May
 2025 17:37:56 -0500
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 27 May 2025 17:37: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" 
X-Inumbo-ID: 3e6f77a4-3b4b-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WThV6PPiYzwQdFsduHl7ho0mbPFeYTf+YEpT5ZouXGog5oDIvkhxu2H+3Xwt+dRaW3hn9aE9zrzqFVwYhKggeAIcjB/c+DxuAguURPsBgv4KMZXKnm+OHgaphWd2sfOY/lu3YI3y9nz/Ekj4RVYpflD069fi/aFOGZQltU42RJZzMhSBlLbKtxNxovoCGjkiZAcrUTlUBQJ0VUuzlzLBOgWZutFwhKrVDjeUyuKkeqiEwN6wI5dz2y5A0eGam2bbcLvTsqLoxw5MPRxDECi1VbA2TlL9eNTjxKCpWEt5V+zkLEKsaePdbsLEcSZvzGldnTh8Yyq/odcZkBKorU9pTw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iOCIgSrhE370bSBnQ7ALiF16fphr5HjFCjkf66s7g44=;
 b=ODiwtcVsbnpYzMroyciNnA6sW8+EN3Rnnmn41KmvWgDi5mYSl+sqtPh4dxiCHnpT2kd3Z1HnLztB0CHIogoX0OHC+7WPgRZKgYH4qf6/sC0z0lcm7aqDk4YFbrkdON7JA/Mgw4t/RmL+3CFIFp6FVNf+twQgGeSrlbz5NXA/Xu7Z4BMP95SNZaegQOJvJTc2iMgMnmqHeOa6nzLBICUMQyFF3fK+itPMqh9hxGd/AfmR0Audsow6lqG2uzd3M3EA6SisvWBHbQgT2Stu30y84vehExULTzQ4lMhHY1JBlThw9944gWpr0K8jLDee3hRLxUZYoOBgp51B4kP+G53v7A==
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=iOCIgSrhE370bSBnQ7ALiF16fphr5HjFCjkf66s7g44=;
 b=ryT/3Ds537G4Re3U5n/vIN7cVHRHEr1ml3pe3GxnB8Om5H2isa9QNKHmRy0wnuSMBFPhW0q5EL58LM9MoAh4IqgEwWlr7FXl/IYHv2o1uFC1xqLLQBy+uArIWx1hBg5oacEWrtUksXSclcVssQ5oCGZCCZLhZL8wVExkCQ8vi60=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] xen/x86: Remove is_periodic_irq() prototype
Date: Tue, 27 May 2025 18:37:53 -0400
Message-ID: <20250527223753.47055-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF0000467F:EE_|CY8PR12MB7586:EE_
X-MS-Office365-Filtering-Correlation-Id: d9937ee1-07d6-4a6d-8186-08dd9d6f20cb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?v43PRb4JSHpxicjZwLQ7O+04lOpkkhffFX9j2nj7FIhGLSTytLdP8uysODjL?=
 =?us-ascii?Q?np3yf4mBWb6CXtGPpYhEvC9Hj2MrSruVqcGrT1uU7kFy8B3/qQ5VC0SRqnPz?=
 =?us-ascii?Q?AA+43kCwB5OlmrfC9N1DZ1xZV8dzKh/tZu+wDl/7oOTZajH/WmV2baP7dbpg?=
 =?us-ascii?Q?LpE3oXIzFKdUHD5cf+mulVZbQONdPHc0OaHnk/CNwraDIgAp0/QeHd0DiEYS?=
 =?us-ascii?Q?M0I+uRd49AfGD8ApzgkpHDjsCN9U836DOcHroQ1wNwlWwgvsO6fwEN34HGG4?=
 =?us-ascii?Q?wfzl1/szb4PvvgVwtr1L/elWat+AuGqr0Kz3ObI3fUjUdAEub2rkTpl7s9td?=
 =?us-ascii?Q?YcB+ppL7xbxfOFgSWRzkjaIfsy1ZKiEdaxKBb0K8QGvTYkjw0HQ5CDJizVT8?=
 =?us-ascii?Q?fV2a23lFJ9qfgPqeq92JUTXc1A7q18vwYfX9kkx73QLVJ6JKkOddBL9THPRL?=
 =?us-ascii?Q?VmDcGIyhtc/8KoVPWa0/N94b23mHOsW3k8pVCvByRwRR7yjdDK5rDttah4h0?=
 =?us-ascii?Q?Hg821co4kmHSaXyqOKkendSeMznN1x4Mn5FpX9dpn+iee/9nzNZrMuA/1hr2?=
 =?us-ascii?Q?fgzZH6wwIXzYsrW1RKczxjwQxeCEjSJ73lxVYbAeP1Av/3EReIaQbiiIYRZt?=
 =?us-ascii?Q?R5TtulfhYj7OXX9RBHZz0r7VHI6o24WdTPuhB5O5u88xGQ59EzFJe2fnS4x9?=
 =?us-ascii?Q?7/sU3YxlCCyqA692df3jCwuPpuADUTZqjGgsNK3MJdtAJWHIDV0YQorHTuhy?=
 =?us-ascii?Q?MKSf5I3+qGKy+ua9zKjFSA9egFF5FVxZaAVIiyx/dEbLsQiRE6M5p08ACWqy?=
 =?us-ascii?Q?2+irdFOJuF7ToQTsf9N8lbYWADeUtdAqp5boUBcOlaW+3VgFijBEmFjBxCaf?=
 =?us-ascii?Q?Hb6XVizn1l54um0HPQpCRzeriHNPZsLfsF8436+1r7oZQuy9djUeZkBhWMIb?=
 =?us-ascii?Q?ABHtxojCgX+6RIR1qyPg2LyDZtylp7SDzRUDwqPZM2OFqZ5MYEDDR0ArQTEE?=
 =?us-ascii?Q?LhMbsohSpBVxF68VtSyyQKrSp09qckt/HQDu6ICmR/hnn+u+lyOnjwssIhh5?=
 =?us-ascii?Q?8F/B04ne3qf0kmDgeFAVqfH7+kt2rdIHpOVlKlKJg9ui1Q7+vbRRBL/4EN7V?=
 =?us-ascii?Q?EyXvD97J7flC25qtdyDpyKbFXQA0MHxfnszO9NpH2+Q11wDlo1lH3fN+yjDO?=
 =?us-ascii?Q?CQY/BrmGbZPmFluPRRhgkaURW5+rqNlF91TbEtWKsXKEHiCIDYCmWn615+vc?=
 =?us-ascii?Q?7Se6882FHC3wkXwe5kt7D2mgIxm9xmlRKiCWNq2mQO+24uC+YGHJLt66vkAf?=
 =?us-ascii?Q?RlbXCKlwbJy0pANCd0itW5Fljc0wIyXN6szI4z1HVn3bshuCS5svyMst7DNx?=
 =?us-ascii?Q?55G6/sruOKyqnkqOwNTkFtNEFjh4qrEfV/p7r8iBa6z1NG2D6FkfLopXw0vm?=
 =?us-ascii?Q?czow5+lgRrD6rWONbDUZof1G8JRDLaxgRXN4/3AJDYOkGW3Sg0AOuensOz1L?=
 =?us-ascii?Q?X9rcw39pyCRXO/dl9Bny9G6xlj1hNXXIcGt6?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 22:37:57.3186
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d9937ee1-07d6-4a6d-8186-08dd9d6f20cb
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF0000467F.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7586

is_periodic_irq() was removed in the Fixes commit, but the prototype
remained.  Drop it now.

Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer...")
Signed-off-by: Jason Andryuk 
---
The full Fixes line is:
Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer (PIT/RTC/HPET) programmed as periodic timer and adds them to abstract layer, which keeps track of pending_intr_nr to avoid time interrupt lost and sync'ed timer with TSC.")
---
 xen/arch/x86/include/asm/hvm/vpic.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/arch/x86/include/asm/hvm/vpic.h b/xen/arch/x86/include/asm/hvm/vpic.h
index d71b270193..78ed33e9aa 100644
--- a/xen/arch/x86/include/asm/hvm/vpic.h
+++ b/xen/arch/x86/include/asm/hvm/vpic.h
@@ -35,6 +35,5 @@ void vpic_irq_negative_edge(struct domain *d, int irq);
 void vpic_init(struct domain *d);
 void vpic_reset(struct domain *d);
 int vpic_ack_pending_irq(struct vcpu *v);
-int is_periodic_irq(struct vcpu *v, int irq, int type);
 
 #endif  /* __ASM_X86_HVM_VPIC_H__ */  
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Tue May 27 22:39:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 22:39:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998794.1379491 (Exim 4.92)
	(envelope-from )
	id 1uK2xb-0004LW-9I; Tue, 27 May 2025 22:39:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998794.1379491; Tue, 27 May 2025 22: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 1uK2xb-0004LP-6Z; Tue, 27 May 2025 22:39:51 +0000
Received: by outflank-mailman (input) for mailman id 998794;
 Tue, 27 May 2025 22:39:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK2xa-0004LJ-AJ
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 22:39:50 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7ea6307f-3b4b-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 00:39:48 +0200 (CEST)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-601f278369bso7951513a12.1
 for ; Tue, 27 May 2025 15:39:48 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60517a79c74sm196034a12.60.2025.05.27.15.39.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 15:39: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" 
X-Inumbo-ID: 7ea6307f-3b4b-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748385588; x=1748990388; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=XkSMD/lxSawBxTNjjf0XnVBgNz4fkITonywo0sDpDQs=;
        b=qTrtnMHfiqb6LhjuDRCi88XhFeCsaCKsn7E/a/OXfaRSZDcNxmZnUKBq20aATNEzDF
         h5zREc18wqV0SILgYb0PTT4AOTOSUXUSPwvML+TxeJpvpRu2gB2B/szM09cg3URqP/9f
         YpwAJ3PYJRxpek5AKuepXf25pFx3p8+APkJbk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748385588; x=1748990388;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XkSMD/lxSawBxTNjjf0XnVBgNz4fkITonywo0sDpDQs=;
        b=mOv58oEfpD/WUvjKlkVU3ejK+7hJuMfwL8kdZm5ynuga4II7epb2IxayxxWD9VVrMm
         conh0vTR3BCgRErqmGfk2/OiwdZw6lmkrkszjTP/Q61c/8MndW4FQ3j1fDoHLKBoMNso
         GRXy34pE5P+0sPJRrd/nqneTz0Z0FNOctCoA/1+cjAn7QSWTIHCpjVdpSjcKflhdNBLy
         onid389k09rnhACl+rhAuj/elRMaP8jS8XQUkhLalfoZK0X7SFKDt4l8+EALhF1kZ/a3
         /S+EEOtCZJKK0OG1IM+xKaJ2ffIaYWYuwwRc99S3N3ZHpzBzhxvRT8wH0L2Il8OyJt+f
         QM9g==
X-Forwarded-Encrypted: i=1; AJvYcCV8HrBtsgyrkARY+D1O0WOCyHb6RKfsy4vQdFTbyL5XCewFTZ8/+UQOUydD9DbOxlAyxg+fPxVtGqw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOOHnnyWHiNecIgM13uZHczEv5NbFZ7Wmp81v+98mWk1Q4fazT
	fx61JU58jzMEpYv64MCNnBOuqaAfzRVGBOREoWTH6QHDtJOhmHFBwJqXPRjmTh1H4xi1c8z8nOY
	HmotL
X-Gm-Gg: ASbGnct8Z2AIzb+SIsS7DZYAShP7MY3XA1usqjrzqm7MBRZGZYx3tn+0EdgQsF++xwH
	nguRbJ8HjYtgaWWlbcvJPFn+7S/Fbh6//u2tJdEAjCk3nBzTy9UTJ97mbRfszTTtUrJiqW02ZQK
	54fXOxHKoiarMKOQqHCioAZhnA2iTlSCxgCt+msTK2OuVKDJLEZD5ebbxCEZG9AuZoVgooLG/ju
	/IjbUYBDpMKx4kvDelYfzx7RXmZVKP08TTylBLBssztfUA3VMuNN0Si0HUa2uqDaXwzz9nRjEFP
	1p5UYcnBpYSdO82qstvWcjTGTWHVXZslSL1ErVBmGnlbzEOfAsCQ95gZh/KvcmPSk9ptNkezQJz
	Ytyk4A5Ttc8EJ79Ok
X-Google-Smtp-Source: AGHT+IE4LT/hexQBC5HD63F2TgFgLFFz68CpYI7oKOoafahYfZezEPpKVg9mk7kPhjVgHerI6kP/UA==
X-Received: by 2002:a05:6402:5c8:b0:601:9dc3:2795 with SMTP id 4fb4d7f45d1cf-602d9bf99d9mr11138804a12.7.1748385587733;
        Tue, 27 May 2025 15:39:47 -0700 (PDT)
Message-ID: <1c850e02-0d87-4fd1-8504-0aee53949136@citrix.com>
Date: Tue, 27 May 2025 23:39:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/x86: Remove is_periodic_irq() prototype
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <20250527223753.47055-1-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: <20250527223753.47055-1-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27/05/2025 11:37 pm, Jason Andryuk wrote:
> is_periodic_irq() was removed in the Fixes commit, but the prototype
> remained.  Drop it now.
>
> Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer...")
> Signed-off-by: Jason Andryuk 

Acked-by: Andrew Cooper 

> ---
> The full Fixes line is:
> Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer (PIT/RTC/HPET) programmed as periodic timer and adds them to abstract layer, which keeps track of pending_intr_nr to avoid time interrupt lost and sync'ed timer with TSC.")

Yeah, the older commit messages weren't as well structured as we insist
on them being these days.

How did you find this?  inspection, or a tool?

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue May 27 22:55:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 22:55:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998803.1379502 (Exim 4.92)
	(envelope-from )
	id 1uK3CA-0007E1-Gu; Tue, 27 May 2025 22:54:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998803.1379502; Tue, 27 May 2025 22:54: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 1uK3CA-0007Du-E6; Tue, 27 May 2025 22:54:54 +0000
Received: by outflank-mailman (input) for mailman id 998803;
 Tue, 27 May 2025 22:54:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK3C9-0007Dm-4K
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 22:54:53 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20624.outbound.protection.outlook.com
 [2a01:111:f403:2418::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 984baed0-3b4d-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 00:54:51 +0200 (CEST)
Received: from MW4PR04CA0209.namprd04.prod.outlook.com (2603:10b6:303:86::34)
 by DS7PR12MB6007.namprd12.prod.outlook.com (2603:10b6:8:7e::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.22; Tue, 27 May
 2025 22:54:47 +0000
Received: from MWH0EPF000971E2.namprd02.prod.outlook.com
 (2603:10b6:303:86:cafe::f6) by MW4PR04CA0209.outlook.office365.com
 (2603:10b6:303:86::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Tue,
 27 May 2025 22:54:46 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000971E2.mail.protection.outlook.com (10.167.243.69) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Tue, 27 May 2025 22:54:46 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 27 May
 2025 17:54:45 -0500
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 27 May
 2025 17:54:45 -0500
Received: from [172.31.32.79] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 27 May 2025 17:54: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" 
X-Inumbo-ID: 984baed0-3b4d-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=d60D5/QZRAEgRXphK4Rdq6ous9PPg+SJczJghFfA9yxymF3lauObIATyUsTLsAnqKiigYUlvKbOW4BCAqMZvKTWTun+PZGcu+rntIK0MEuY4OConIkVYaKXDTbBdZjlA/93KjL2wcTXN9ZLQKjKOupotu2McS58e8tKjhAWyvg27UxLwa+GuddnrWcLaIWYZL8A9ITZZBn6XcFPToSEkj5TlVIMkRfTk6fQOQbY2OKPAeAre82fnziDJWOH0oTsAEOddktx5wr3pVTB1NODH9QhJzfW585zl2FFCALwIvJBOr+8lfj3BLuCAfy0p1kJzhv9Hf4WIkeG+IpDzzk7pQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wAm369P1Yl+9qv/sZTUPGuqQePdOUbvJfCryarsCOE4=;
 b=aRFn+446NHSyDZfqsUpECa577AjvPXH67Mwr/uA/v3T4o5QFHoSvvO8oo9DEqPuUP8ObtJ2WRIr5ZVpwwrK+yM0uTVSpjwIZibMjDnkPFyaLcpmcTEsSHb12nG2kVmVbOHYGNwe+OntcnrF0cjtkCXOnMvmQSpLrMi7C43RvmURCgFH4h1vFYWt9kaUKWwaRZ7b4fNvkSktE9Cl2zARMoK/MyHh0MaSmDAAA9nayvEMyB8h0d+Eaji4T3MIEqespy3cpR5wRNSAEnNrLpz5+dFSS6xJv/wO0zf2a6zUos0028RLbZ8fwMcMtQG9BfPNj4DxwCIi4/veDoQLExGPl3Q==
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=wAm369P1Yl+9qv/sZTUPGuqQePdOUbvJfCryarsCOE4=;
 b=N7F153fPPFElps0Wo5qjfCPIQMUiFV6vQzRagcz31S7TFH4AlpIfYe63OoRL0DEjUPuWvOt0sibsebjLSI9e9LfCOOa2piHcRWL+1KT5QZsaW6REhsroi4gUU9oLD3yTfUZsdK8YPMLTi55YlVHRh+XQrRmjo2r090yTC5IslZM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <50b2500d-f732-471c-ab0d-cd2e4d0136e5@amd.com>
Date: Tue, 27 May 2025 18:54:44 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/x86: Remove is_periodic_irq() prototype
To: Andrew Cooper ,
	
CC: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <20250527223753.47055-1-jason.andryuk@amd.com>
 <1c850e02-0d87-4fd1-8504-0aee53949136@citrix.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <1c850e02-0d87-4fd1-8504-0aee53949136@citrix.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000971E2:EE_|DS7PR12MB6007:EE_
X-MS-Office365-Filtering-Correlation-Id: 2e27c94d-4259-4653-7bf9-08dd9d717a69
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dHJXcXlnRzBaR1BUV0F0WVZacm9pbnFSTzFQS0pmUDRTeFdYdWR2Y2xBb3J0?=
 =?utf-8?B?aC96U2RlQnRpSmExY3BVN0YrWFJ5TXRZcVptRFhIa0xIdHNTSGx3RC91RXlH?=
 =?utf-8?B?cXN6Y2xwdmJFUTdVdi94bEhvWTdJRng5NTVEbEQyb1pzSGFldWFEUFlyZVZF?=
 =?utf-8?B?bE1kYXIrbzNHREwyMzNMQ2VqM20xZ3dpbzZ5L1hROWVrY0hyMUpvN1ZoUnJZ?=
 =?utf-8?B?bEl1L2JIb0RPd3U4ZXQ2bEp2bjJDSlNOTGRScGhuSU9EVk1yMjd6WEJ5eTZN?=
 =?utf-8?B?RkNmTk1ld3RHekZJZzFlelJUa0FmZTkzSzYwWmhpTXBjSDA1RVJISDdOY1Nk?=
 =?utf-8?B?VXlQTXhBVUJESDUvZFNxOTBCY0tVbTNDTzVRcFpOcEF0Nm9NMVppWnlTSVlO?=
 =?utf-8?B?K1lIRXpHZVUrZ21lUDdKTVhtaThNb3RveXV5eFBOYVg1QytWRUFFeU9oTjYx?=
 =?utf-8?B?RWZFU1VpaDJ3L1dzeTNDQmY4TjdKUzBiS0tNOEU0REkvM2htZFZjalN6ZVJK?=
 =?utf-8?B?RnRpVVp0Vm5NZytzUHRqaE5odFB3ZlJaM1VLRDNNRnFBc2hkTWl2T2ZrWTlD?=
 =?utf-8?B?dktrSjY5VEJ4MExnTU9yZEZudERJSWdFKzRaQXg5Sk9jQWJPbERnaENhRXZC?=
 =?utf-8?B?UW5CZmpUQzUvT3krZmNjcVBJK2tleUgrZlprb1BuMkdDa2FaUkM3Y2tOYmNu?=
 =?utf-8?B?b081S25ydXJRWWtkd1RTSXdtTmpRQUJwREE1Z1E5WHlDelFUSzdkbzBZRll2?=
 =?utf-8?B?R0RmNkZKZ0VHZFdOazlXWmRUREdRWnJEcU1zWS84MmdVemJOczZPdGpvUyty?=
 =?utf-8?B?R2lTUXUwZVVhZFpTSm1GWjM4azMzL0t0YVpDd21uUStFSEFWQitqTExobFdp?=
 =?utf-8?B?M3lPdkk0NEdOT0wvaXQyZ2ViMHFmWDd0NzBBRnNTdFJZUGg0R2FLRU0zZEtZ?=
 =?utf-8?B?WkJtWkd5UzNGVEhFelBONW5VOWxTT09XOW8yWGFLdVhuZytCZ0wwM1g0N3hx?=
 =?utf-8?B?NUw0VUVaNVlFcHVkMUxBTHRxVThNNGtVUnFmaWxkVHdNNEVlaHNra1hLVnJh?=
 =?utf-8?B?SjdobklGWHc3N1VRK1FLU203UUxDbU9lMWZIbHgzWnhBaHVzVVpJS3FEeDYz?=
 =?utf-8?B?UlFpL1I1OUxGVC83T0lpeHdkNW02d0pwTkRwd0tCa0M4T043Lzl0TEhLL2Jx?=
 =?utf-8?B?U1VnTUxyc0Y0bFd2WkxJcEw5eUVhR1Y5bGEyMFRYNm9IdjBUMkJkNGFvUDF5?=
 =?utf-8?B?WnIyWlZ2YXRRbSt1bDdxZTUybHdHeElVSWZPcDJwNjNKTmFXSUxRYkREdzF3?=
 =?utf-8?B?OEQ0WVRodXVOV3VxQzJ6WDRPZEVmWThvL01XRmcxOCtidHRJSmlSaVlvdjhj?=
 =?utf-8?B?L1FMeWVaYjZZWUtmTEtiaEtJeDRiTE9BTU9jb0JPUi9QcW15VWJ0dnJoRVgr?=
 =?utf-8?B?aDR4OHQ5ZXNaWCtwOTV6ZUtEY3dlMWpsZHNJRXRZSEsrUHoxL25xR2h3d0Ny?=
 =?utf-8?B?ZlFBa0VpTGozT2RuUkkwR1dxZGVmOU1yRThmVUdOeXkzOXk4eFN6czlXTlpG?=
 =?utf-8?B?SUQzUE9SMnZZRU4rSSthMFlFRHJ4WjRqcWx5MGVqK3d4T0RLRnJmOHFSNnVW?=
 =?utf-8?B?ZUVLY1R2azR6ZjFQZ0tLTWVFeVkwN0pOVmlGdHdabFA2VXJXRzhTQlpyc1NJ?=
 =?utf-8?B?NEp4dVhiRmVKOEpOM0tMMUIza0d6TElYaFZlQWtSMDc1R1NUeVNrZ0V5Y2Nj?=
 =?utf-8?B?eVNNMDhLVDcrYm1RSGIxa241VUJscVRPUVFoWGZDSjF3ck9qNzhXNk4zOHBm?=
 =?utf-8?B?SGREMWNlSVBpeWFOeE9pcFdqa2tPQm16QjR3QnRqT08yb1lqZ1VQN0d2N24x?=
 =?utf-8?B?ZlVVNXhhWlB2bEhnN2IvN1o1LzJGYy83L1ltaWNUQ2dNRGhMeGlkS1pJRVp3?=
 =?utf-8?B?VU0yV0JsdytJOFNiWVQ5QjhUelFhZDFsOEZnVkd3UXd1TVR1Z1NabHh2cEtr?=
 =?utf-8?B?MUxjL0I4VGZmbmg4TVFzcjZNWFU3SGZGYUZEdHdGTmwxZXpVYkd1WUFtTDRp?=
 =?utf-8?Q?9mKFCu?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2025 22:54:46.5615
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e27c94d-4259-4653-7bf9-08dd9d717a69
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000971E2.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6007

On 2025-05-27 18:39, Andrew Cooper wrote:
> On 27/05/2025 11:37 pm, Jason Andryuk wrote:
>> is_periodic_irq() was removed in the Fixes commit, but the prototype
>> remained.  Drop it now.
>>
>> Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer...")
>> Signed-off-by: Jason Andryuk 
> 
> Acked-by: Andrew Cooper 

Thanks!

>> ---
>> The full Fixes line is:
>> Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer (PIT/RTC/HPET) programmed as periodic timer and adds them to abstract layer, which keeps track of pending_intr_nr to avoid time interrupt lost and sync'ed timer with TSC.")
> 
> Yeah, the older commit messages weren't as well structured as we insist
> on them being these days.
> 
> How did you find this?  inspection, or a tool?

grep after looking at your vpic.h patch :)

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Tue May 27 22:56:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 27 May 2025 22:56:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998810.1379511 (Exim 4.92)
	(envelope-from )
	id 1uK3Dw-0007kQ-Py; Tue, 27 May 2025 22:56:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998810.1379511; Tue, 27 May 2025 22: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 1uK3Dw-0007kJ-NR; Tue, 27 May 2025 22:56:44 +0000
Received: by outflank-mailman (input) for mailman id 998810;
 Tue, 27 May 2025 22:56:43 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK3Dv-0007k9-07
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 22:56:43 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id da3a5a87-3b4d-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 00:56:41 +0200 (CEST)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-ad1f6aa2f84so71744566b.0
 for ; Tue, 27 May 2025 15:56:41 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad89f288de2sm22160566b.182.2025.05.27.15.56.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 15:56: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" 
X-Inumbo-ID: da3a5a87-3b4d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748386600; x=1748991400; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=b+8YzaJoOBsvDEn/qHxo5/cmfOi88AtNOe7OBfbl31o=;
        b=s+Cx9zRxGPuDknd0MhY6BR0boGR+VffLcZA0whd6TPUEkoHll6CiDnRiFGarqufTdn
         xqXIRJHuyNsTajkA2qjlH4Xz2I8wfL/bQyrk4wBvP6NFKhVBBSS3fsorwuftoHUL+uJr
         DD9mYM+XNKANyppyQDj/OfCdzc2hRCIeePBJo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748386600; x=1748991400;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=b+8YzaJoOBsvDEn/qHxo5/cmfOi88AtNOe7OBfbl31o=;
        b=KWey11ezlWUCSFteNJdTwJpadNdNoAMNXQfR5GiDjyc2QXM4qnC/t1pPL1IEMv40Bw
         Yr5+Xt6PSk1tpeqDHRp6e5tV626KX1MPr8tgAt8oN6Y6h067LMdeKhAmT8CCm/Vck3Of
         toLbD9Kf0Jtc57+tG/f8lPOYkiF7bxAZ7da/2vkQJXnZyX28E2Y9Uqj2hMz7TFcLF+g6
         5NMvcelCUGDE9V1CRHekN9EnEMrI+G+EZ3X6t/ksA/NJ8eWZm9OVUM5rkcZHF795oDIL
         1MnJ65a3HBKdu5AUaP/QQVE14ts0O9/uuUMHNuYm4aCPDrSVier+e3NqHbK1p6LDagQq
         OFcg==
X-Forwarded-Encrypted: i=1; AJvYcCWNHF+v7cEU9DC3KUOX/2GBkwF24NX/xT6LvMWQyfwirKQAnqbGt9DN10iNkjp+Havzy/ecGUAQQtc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxbUgyBYJRaaAXt+2QBsexpz2lELU14mp6faQYPtMwGxTl8thEb
	Ya9CjMkSYMopChlbkyTg01dQ/P8FT9ET0PVQxygDZB+wFbjgv8ShA+xKAlLYHN1KD/k=
X-Gm-Gg: ASbGncupEM4YCzHwn8sipGKn7Gu0KntDJv6qzrUpScCOAiHNSZh4+tHwsiGFhqvGrs+
	0yFlz4oWZIOi6cpW3kVDdXyXA9+yLYBAJSERxzZtjD1cHc/ly3uUjyu+QW9L9qRIWUE2443/4c0
	smjD/6Mw5FrsGS37P6YOngB4B3jD1hep2lu19eeIDa/ejETyWDC+zjaAenaxDGQOhG2P3v2pl+v
	/6auhnhXiAVey9lvMsDVPWxV7gnkjroOUCm7hg3rkrzeYZ2ZZ82BM/+W9M2mcPI2ef/hlD4gY4Y
	rSaEM4Q5UufBy4ON8taY5k9df2QHedYa91ZfeNHp7N2k5uHtZ+WPC+K/G0tffyomKhPf/zfJ1ND
	bZnjqbCjoauHsBBCn
X-Google-Smtp-Source: AGHT+IH+bn6Q19H9YlsViR7T71cbSOgHe6jOJAbxmcdsx/V8zD5+BFrUyZWHoTe3w9T1VxQsGmb35w==
X-Received: by 2002:a17:907:94d0:b0:ad5:6e40:9830 with SMTP id a640c23a62f3a-ad8989f83b2mr224562766b.20.1748386600334;
        Tue, 27 May 2025 15:56:40 -0700 (PDT)
Message-ID: 
Date: Tue, 27 May 2025 23:56:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/x86: Remove is_periodic_irq() prototype
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <20250527223753.47055-1-jason.andryuk@amd.com>
 <1c850e02-0d87-4fd1-8504-0aee53949136@citrix.com>
 <50b2500d-f732-471c-ab0d-cd2e4d0136e5@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: <50b2500d-f732-471c-ab0d-cd2e4d0136e5@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27/05/2025 11:54 pm, Jason Andryuk wrote:
> On 2025-05-27 18:39, Andrew Cooper wrote:
>> On 27/05/2025 11:37 pm, Jason Andryuk wrote:
>>> is_periodic_irq() was removed in the Fixes commit, but the prototype
>>> remained.  Drop it now.
>>>
>>> Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer...")
>>> Signed-off-by: Jason Andryuk 
>>
>> Acked-by: Andrew Cooper 
>
> Thanks!
>
>>> ---
>>> The full Fixes line is:
>>> Fixes: ddc35d1cc994 ("[HVM] Enable more than one platform timer
>>> (PIT/RTC/HPET) programmed as periodic timer and adds them to
>>> abstract layer, which keeps track of pending_intr_nr to avoid time
>>> interrupt lost and sync'ed timer with TSC.")
>>
>> Yeah, the older commit messages weren't as well structured as we insist
>> on them being these days.
>>
>> How did you find this?  inspection, or a tool?
>
> grep after looking at your vpic.h patch :)

I grepped all prototypes in one go, which is why I missed it...

I had a more extreme version of this patch moving vpic.h into hvm/, but
that's the only header of the set you can do this with.  All others have
a contributing part of struct domain or struct vcpu, and I don't have
time to untangle sched.h today.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 28 00:07:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 00:07:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998825.1379521 (Exim 4.92)
	(envelope-from )
	id 1uK4KK-0000cw-25; Wed, 28 May 2025 00:07:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998825.1379521; Wed, 28 May 2025 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 1uK4KJ-0000cp-VE; Wed, 28 May 2025 00:07:23 +0000
Received: by outflank-mailman (input) for mailman id 998825;
 Wed, 28 May 2025 00:07:22 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK4KH-0000cj-Qg
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 00:07:21 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b8218388-3b57-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 02:07:19 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id EA7A7A4F23B;
 Wed, 28 May 2025 00:07:17 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id DFCDDC4CEE9;
 Wed, 28 May 2025 00:07: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" 
X-Inumbo-ID: b8218388-3b57-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748390837;
	bh=hMi9VbDT7He5JUpkxI5juV513vfu1z7Dcmt8BzdXlNI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=swE9Unmnh+uAzIq9TZiiWam5kmwGyN54tzdYLrKbF/VycRhMxWGrvXgL4B9twKD2E
	 JRXi+XZBNocA7AcfAj3Elh0ISYW2QQUhdQqKL+Rpx8LGuTnPXJGJrSP3CoP+ZmmAwL
	 jVrvfGEVNUCFvCG5YztRNSDPLoP0xJrZuk50PJAfDBFF3/S6gsguQ2qtxoDnWdKMM+
	 3lHu3x79/dzFw3wYiHw5FqmBxZ/7pvFkA198VwAnyfCT/Mdigslfu4FsH8EFeHaBfE
	 01tMMB96ucdkKCNme8ev9cLJWS8xiifDM7buzMqdL52yEEV54elmAJ9WSaB8uPeTWF
	 CEEm38EOLyCfA==
Date: Tue, 27 May 2025 17:07:15 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Anthony PERARD 
cc: Andrew Cooper , 
    Xen-devel , 
    Stefano Stabellini , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH 1/3] tools/tests: Drop depriv-fd-checker
In-Reply-To: 
Message-ID: 
References: <20250520205239.203253-1-andrew.cooper3@citrix.com> <20250520205239.203253-2-andrew.cooper3@citrix.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 26 May 2025, Anthony PERARD wrote:
> On Tue, May 20, 2025 at 09:52:37PM +0100, Andrew Cooper wrote:
> > Unlike the other tests, this is not standalone.  It requires poking at a live
> > system, making it unweildly to use.
> > 
> > It hasn't been touched in 7 years, despite changes in libraries and kernel
> > devices using the deprivilege infrastructure.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> Acked-by: Anthony PERARD 

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Wed May 28 00:07:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 00:07:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998832.1379532 (Exim 4.92)
	(envelope-from )
	id 1uK4Kr-00014e-91; Wed, 28 May 2025 00:07:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998832.1379532; Wed, 28 May 2025 00:07: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 1uK4Kr-00014X-6N; Wed, 28 May 2025 00:07:57 +0000
Received: by outflank-mailman (input) for mailman id 998832;
 Wed, 28 May 2025 00:07:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK4Kq-0000rc-QE
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 00:07:56 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cd83fdee-3b57-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 02:07:55 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id BD602614B3;
 Wed, 28 May 2025 00:07:53 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B56B1C4CEE9;
 Wed, 28 May 2025 00:07: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" 
X-Inumbo-ID: cd83fdee-3b57-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748390873;
	bh=M1+i/XHruc3Dm6VRBbhQy2b1KfoqoxA04Ngy73RPfjg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=B7/X4KzwRD50SW5V1NTqg0jhnzAbWLvWWcAQn22rswcKl2N50ayS/kU1MubYoFlVw
	 qP1DGGJrkjHRgAg1MiwbjGkEEQnb3C7tlXJU3njQzZqguXugIVIxww+K5wcrqvOZRx
	 aCAzOV5If7OWKQmtYSVEw0jhZMKSChzQxDxD4BpFkBONFqW1tUVoDiCUUbdbj9O5EG
	 93PGYsx+rx2+FxHWHBjZUlfLKa705C4GM/iMg8UTO8+dUmCes1+UJTP6FuMSldDKs0
	 MlJ1cBYMuysMkFhTL096+Ef3ltdeaA9+ymdqrD8ElOq2/XH/0DYoxirBJ8HH0dSOwI
	 DlPtyhGSzzEKQ==
Date: Tue, 27 May 2025 17:07:51 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Anthony PERARD 
cc: Andrew Cooper , 
    Xen-devel , 
    Stefano Stabellini , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH 2/3] tools/tests: Install tests into $(LIBEXEC)/tests
In-Reply-To: 
Message-ID: 
References: <20250520205239.203253-1-andrew.cooper3@citrix.com> <20250520205239.203253-3-andrew.cooper3@citrix.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 26 May 2025, Anthony PERARD wrote:
> On Tue, May 20, 2025 at 09:52:38PM +0100, Andrew Cooper wrote:
> > $(LIBEXEC_BIN) is a dumping ground of many things.  Separate the "clearly
> > tests" from everything else so we can clean up how they're run in CI.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> Acked-by: Anthony PERARD 

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Wed May 28 00:16:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 00:16:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998844.1379541 (Exim 4.92)
	(envelope-from )
	id 1uK4T4-0002rV-15; Wed, 28 May 2025 00:16:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998844.1379541; Wed, 28 May 2025 00:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uK4T3-0002rO-Um; Wed, 28 May 2025 00:16:25 +0000
Received: by outflank-mailman (input) for mailman id 998844;
 Wed, 28 May 2025 00:16:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK4T2-0002rI-Iq
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 00:16:24 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fae57606-3b58-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 02:16:21 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 750A844175;
 Wed, 28 May 2025 00:16:19 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E0F3C4CEE9;
 Wed, 28 May 2025 00:16: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" 
X-Inumbo-ID: fae57606-3b58-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748391379;
	bh=WzhABPYJaAG4UTp5WISdWDZZsIZA/fOnZhZA+NM+Bfk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=J8ZIy36QR+cDxL7+XaZtlxjvUsNuNQq3cdEqfSCeC+atd2nKaslrjM3t3572nAkKT
	 xhHPsPiVdV7pFaHcWW6eMpK9DjBJyhUTXLpWhSYbrafyURFpHI+9WLsIAwlfnI8+7K
	 8jjcNbQRKlNXRgME/8QvL+2HYeC++765/Ck2tHKnCZ0mmp1j+TSTC6q9GAEtt/pesD
	 bW2DUBBBV4DpoMsseQ98/4G+oXe5kALlIP6ssvc1yHnHKJ3CX7UT9G6D4IZYCo+P2/
	 vpZQRREbsACGazkQOorRiRfbfqWx1+w/4JmzT1+97jNlItDHuGh3CpI7yX0Pj9VOPt
	 gdqctBBgM2ayA==
Date: Tue, 27 May 2025 17:16:17 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Anthony PERARD , 
    Xen-devel , 
    Stefano Stabellini , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH 3/3] CI: Drop custom handling of tools/tests
In-Reply-To: <23aeac17-6fd0-4515-8c84-1a867c57a68d@citrix.com>
Message-ID: 
References: <20250520205239.203253-1-andrew.cooper3@citrix.com> <20250520205239.203253-4-andrew.cooper3@citrix.com> <1e690ecb-5060-4dfe-a515-acbbf214bc99@citrix.com>  <23aeac17-6fd0-4515-8c84-1a867c57a68d@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1555113110-1748391379=:135336"

  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-1555113110-1748391379=:135336
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Mon, 26 May 2025, Andrew Cooper wrote:
> On 26/05/2025 6:22 pm, Anthony PERARD wrote:
> > On Mon, May 26, 2025 at 05:45:29PM +0100, Andrew Cooper wrote:
> >> On 20/05/2025 9:52 pm, Andrew Cooper wrote:
> >>> diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
> >>> index 770e97c3e943..8d7aa8fa5140 100755
> >>> --- a/automation/scripts/run-tools-tests
> >>> +++ b/automation/scripts/run-tools-tests
> >>> @@ -12,30 +12,25 @@ printf '\n' > "$xml_out"
> >>>  printf '\n' >> "$xml_out"
> >>>  printf ' \n' >> "$xml_out"
> >>>  failed=
> >>> -for dir in "$1"/*; do
> >>> -    [ -d "$dir" ] || continue
> >>> -    echo "Running test in $dir"
> >>> -    printf '  \n' "$dir" >> "$xml_out"
> >>> -    ret=
> >>> -    for f in "$dir"/*; do
> >>> -        [ -f "$f" ] || continue
> >>> -        [ -x "$f" ] || continue
> >>> -        "$f" 2>&1 | tee /tmp/out
> >>> -        ret=$?
> >>> -        if [ "$ret" -ne 0 ]; then
> >>> -            echo "FAILED: $ret"
> >>> -            failed+=" $dir"
> >>> -            printf '   \n' "$f" "$ret" >> "$xml_out"
> >>> -            # TODO: could use xml escaping... but current tests seems to
> >>> -            # produce sane output
> >>> -            cat /tmp/out >> "$xml_out"
> >>> -            printf '   \n' >> "$xml_out"
> >>> -        else
> >>> -            echo "PASSED"
> >>> -        fi
> >>> -    done
> >>> -    if [ -z "$ret" ]; then
> >>> -        printf '   \n' "$dir" >> "$xml_out"
> >>> +for f in "$1"/*; do
> >>> +    if [ -x "$f" ]; then
> >>> +        echo "SKIP: $f not executable"
> >>> +        continue
> >> This should be ! -x
> >>
> >> I had that hunk in the wrong patch when posting this series.
> > With that fixed:
> > Reviewed-by: Anthony PERARD 

Reviewed-by: Stefano Stabellini 


> Thanks.
> 
> >
> > But I think there's an issue with the script...
> >
> >>> +    "$f" 2>&1 | tee /tmp/out
> >>> +    ret=$?
> >>> +    if [ "$ret" -ne 0 ]; then
> > Is this checking the correct exit value? It seems that without `set -o
> > pipefail`, we only have the exit value of `tee` which should never fail.
> > But I think we should grab the value of ${PIPESTATUS[0]} to actually
> > read the exit value of $f.
> 
> Hmm yes, I think this needs adjusting.
> 
> It turns out there are multiple problems with junit, including the fact
> that putting failures in here doesn't cause the outer job to fail. 
> 
> The internet suggest having a 'script: grep " to work around this.
> 
> I think that wants to be a separate series.  The question is whether to
> do this series first or second.  I expect I'm going to need to backport
> all of this work to eventually get XTF back onto the older trees.
 
I'll leave the choice to you
--8323329-1555113110-1748391379=:135336--


From xen-devel-bounces@lists.xenproject.org Wed May 28 00:18:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 00:18:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998852.1379551 (Exim 4.92)
	(envelope-from )
	id 1uK4Uo-0003Ng-BV; Wed, 28 May 2025 00:18:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998852.1379551; Wed, 28 May 2025 00: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 1uK4Uo-0003NZ-8m; Wed, 28 May 2025 00:18:14 +0000
Received: by outflank-mailman (input) for mailman id 998852;
 Wed, 28 May 2025 00:18:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK4Un-0003NR-G6
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 00:18:13 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3cc33f19-3b59-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 02:18:11 +0200 (CEST)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-601dfef6a8dso6741695a12.1
 for ; Tue, 27 May 2025 17:18:11 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6051795c408sm287640a12.10.2025.05.27.17.18.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 17:18: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" 
X-Inumbo-ID: 3cc33f19-3b59-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748391490; x=1748996290; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=CVenNw4WWospg7BIoIUfh/e5A8VtTGTiLRaONiqwZEA=;
        b=b9zqwgNGIwBzSrJ6hB8spJK1mURaXgRZxwa4lF0DUUAWQqSrh/D0ropas12NSfkiVR
         Q2jc42UKmOb3SIiQmydbH1EdJEQ4rPTofdoZd77de3epd4Lp8YLdoOW7Yqh+p6ed5q9e
         xb9SMvVRCzn/JJ0JryoGgDhH6Xb2vNfC86oOw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748391490; x=1748996290;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CVenNw4WWospg7BIoIUfh/e5A8VtTGTiLRaONiqwZEA=;
        b=sqD23mlodmRrpIuwAxN0vukln2hO3P5FJ8xLzLQ6D9+bNEweL58SdBHmwdJ+TqgjjL
         lKvV0k71KrYNro9n901b207oKqXCxBSWpqumoCscb+SNMHXb5V6Oa9SQENWTtW+GM6P1
         otxeNnGmQwGqt+E1fIIVq+YgGJJEo2YsgShAUWX9zPriqGtwqh4Wz7V27FMmj9nCxstV
         yOYLWG3OAdhmtNqjl1/fQXc5ToLejLf7g5j6dtQqhr77J8LymqUJcJxya6o6Esqk0DPe
         BG3eMx6xzSwRCIudEXCIFZrtKDtrMI9ylBIbf6bV+0FR+oS98GSDgEFV0wyAmOJjglTV
         jo4Q==
X-Forwarded-Encrypted: i=1; AJvYcCWvhb2nYlh5QuXFA4Y4uIraYa3MCIqGSaNskUfgzUP8xLeyT5/+ZlpSFd3vrJ87lLVxaQhfkZgtUgo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyC+rtzfaiavOnYqeZ9y9CFcaKrjg4PqQZMkY4gU+2mUG0QlxJ5
	YJ/C2cy59eqCLFf2xbk7d5Xxkk6dEgz6GjKl3oyGVeYy45a/Gwf+WLCNb+lp3ji0CRWBNHxwMb+
	Y2h4O
X-Gm-Gg: ASbGncs8G1I8+bQu5hJn/t00hUljZ8wZchfN1jDr8HtuHLc65otdlIJb5djlDT2MBnA
	T9DuJZDlscULL/2MnyTK1kEol12CIZjuLHwGhDL/OqFBz5LY/RHz+uwLD4zbWgWs/bpLqvOp+Yw
	gxKtraRzT+VDBs8G1JjnnRwMPtesf9lmjnjF0h6qNdx4WVHHoVX5BlY5kYFo4H1dptoL6YT/YHk
	InbFBpDttr6v57vP3UObTH3aU4q+fJQttgnfFnDfA/BTokMmVjw9vcGoXgkyIJS7bKWUjkrDX44
	X1A0ZkcuVPgRhmt0NBkwXg21PXWcYIzUYEe6FWHS/b+/wbHohN+jswxUXUpHXB6kV94LmZlkvi+
	iV5uLG0k+M1cOmrBV
X-Google-Smtp-Source: AGHT+IHk1JuyknHt1Fc7xo7cB/k8TcJxZ7M3nRcWO4V4b3upJ5hC//I0FMNJMUwrjyUb/IoKDZueDg==
X-Received: by 2002:a05:6402:51d2:b0:604:e6fb:e2e1 with SMTP id 4fb4d7f45d1cf-604e6fbe41cmr5416958a12.33.1748391490118;
        Tue, 27 May 2025 17:18:10 -0700 (PDT)
Message-ID: <73568a36-8462-4268-93a2-1abf6d168b1a@citrix.com>
Date: Wed, 28 May 2025 01:18:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/3] CI: Drop custom handling of tools/tests
To: Stefano Stabellini 
Cc: Anthony PERARD ,
 Xen-devel ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
References: <20250520205239.203253-1-andrew.cooper3@citrix.com>
 <20250520205239.203253-4-andrew.cooper3@citrix.com>
 <1e690ecb-5060-4dfe-a515-acbbf214bc99@citrix.com> 
 <23aeac17-6fd0-4515-8c84-1a867c57a68d@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

On 28/05/2025 1:16 am, Stefano Stabellini wrote:
> On Mon, 26 May 2025, Andrew Cooper wrote:
>> On 26/05/2025 6:22 pm, Anthony PERARD wrote:
>>> On Mon, May 26, 2025 at 05:45:29PM +0100, Andrew Cooper wrote:
>>>> On 20/05/2025 9:52 pm, Andrew Cooper wrote:
>>>>> diff --git a/automation/scripts/run-tools-tests b/automation/scripts/run-tools-tests
>>>>> index 770e97c3e943..8d7aa8fa5140 100755
>>>>> --- a/automation/scripts/run-tools-tests
>>>>> +++ b/automation/scripts/run-tools-tests
>>>>> @@ -12,30 +12,25 @@ printf '\n' > "$xml_out"
>>>>>  printf '\n' >> "$xml_out"
>>>>>  printf ' \n' >> "$xml_out"
>>>>>  failed=
>>>>> -for dir in "$1"/*; do
>>>>> -    [ -d "$dir" ] || continue
>>>>> -    echo "Running test in $dir"
>>>>> -    printf '  \n' "$dir" >> "$xml_out"
>>>>> -    ret=
>>>>> -    for f in "$dir"/*; do
>>>>> -        [ -f "$f" ] || continue
>>>>> -        [ -x "$f" ] || continue
>>>>> -        "$f" 2>&1 | tee /tmp/out
>>>>> -        ret=$?
>>>>> -        if [ "$ret" -ne 0 ]; then
>>>>> -            echo "FAILED: $ret"
>>>>> -            failed+=" $dir"
>>>>> -            printf '   \n' "$f" "$ret" >> "$xml_out"
>>>>> -            # TODO: could use xml escaping... but current tests seems to
>>>>> -            # produce sane output
>>>>> -            cat /tmp/out >> "$xml_out"
>>>>> -            printf '   \n' >> "$xml_out"
>>>>> -        else
>>>>> -            echo "PASSED"
>>>>> -        fi
>>>>> -    done
>>>>> -    if [ -z "$ret" ]; then
>>>>> -        printf '   \n' "$dir" >> "$xml_out"
>>>>> +for f in "$1"/*; do
>>>>> +    if [ -x "$f" ]; then
>>>>> +        echo "SKIP: $f not executable"
>>>>> +        continue
>>>> This should be ! -x
>>>>
>>>> I had that hunk in the wrong patch when posting this series.
>>> With that fixed:
>>> Reviewed-by: Anthony PERARD 
> Reviewed-by: Stefano Stabellini 

Thanks.

>
>
>> Thanks.
>>
>>> But I think there's an issue with the script...
>>>
>>>>> +    "$f" 2>&1 | tee /tmp/out
>>>>> +    ret=$?
>>>>> +    if [ "$ret" -ne 0 ]; then
>>> Is this checking the correct exit value? It seems that without `set -o
>>> pipefail`, we only have the exit value of `tee` which should never fail.
>>> But I think we should grab the value of ${PIPESTATUS[0]} to actually
>>> read the exit value of $f.
>> Hmm yes, I think this needs adjusting.
>>
>> It turns out there are multiple problems with junit, including the fact
>> that putting failures in here doesn't cause the outer job to fail. 
>>
>> The internet suggest having a 'script: grep "> to work around this.
>>
>> I think that wants to be a separate series.  The question is whether to
>> do this series first or second.  I expect I'm going to need to backport
>> all of this work to eventually get XTF back onto the older trees.
>  
> I'll leave the choice to you

In which case I'll get this committed now, because it's one useful step
forward and reduces my queue a bit.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 28 00:18:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 00:18:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998853.1379562 (Exim 4.92)
	(envelope-from )
	id 1uK4Uu-0003cu-JC; Wed, 28 May 2025 00:18:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998853.1379562; Wed, 28 May 2025 00: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 1uK4Uu-0003cn-GF; Wed, 28 May 2025 00:18:20 +0000
Received: by outflank-mailman (input) for mailman id 998853;
 Wed, 28 May 2025 00:18:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK4Us-0003cD-TX
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 00:18:18 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 408d946c-3b59-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 02:18:17 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 660D7A4F62C;
 Wed, 28 May 2025 00:18:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D70BBC4CEE9;
 Wed, 28 May 2025 00:18: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" 
X-Inumbo-ID: 408d946c-3b59-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748391495;
	bh=YVFMd9a9fxgrp8rH+OMWzKbAEDFwZu4TisRwD3RK+Xs=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=AlC9319JkTgvqHF7DKjYbDPKNH27f7MU4sLFTEmP3AWqElU2uSakdzftj6VAuxyjG
	 AbFpABZuABgATVZpFTiT6Di+n6IBN9ph1e+KIuxmBjjhOiNuRfDj/C/WMdwt+KYTfz
	 zc1JkuK2vc+tfIAN/0GhlvpdGJIO31L4NaCMfphcDBYNH126Qn8FqrtT/ukWhvgamu
	 /T8C0wx0A5oEJAKQ/f9ycSO5Y9l35B5trz7X2ExQd0smt04Gd/j0wa/Pkv4tEncFG5
	 IbS78UTcRQvu3TGtMwh048sNLpO/PkGU3oCOXHaCxv7k4o77lwJ+lfor/8DEK/JVeW
	 AK+23qElvBMAA==
Date: Tue, 27 May 2025 17:18:13 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Anthony PERARD 
cc: Andrew Cooper , 
    Xen-devel , 
    Stefano Stabellini , 
    Michal Orzel , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH 1/3] CI/qubes: Deduplicate the handling of
 ${dom0_check}
In-Reply-To: 
Message-ID: 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com> <20250522173640.575452-2-andrew.cooper3@citrix.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 27 May 2025, Anthony PERARD wrote:
> On Thu, May 22, 2025 at 06:36:38PM +0100, Andrew Cooper wrote:
> > Make it clear that ${dom0_check} is unconditional.
> > 
> > No functional change.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Anthony PERARD 

Reviewed-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Wed May 28 00:19:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 00:19:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998868.1379572 (Exim 4.92)
	(envelope-from )
	id 1uK4W8-0004Ok-SZ; Wed, 28 May 2025 00:19:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998868.1379572; Wed, 28 May 2025 00:19: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 1uK4W8-0004Od-Pv; Wed, 28 May 2025 00:19:36 +0000
Received: by outflank-mailman (input) for mailman id 998868;
 Wed, 28 May 2025 00:19:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK4W7-0004OR-DI
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 00:19:35 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6e602045-3b59-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 02:19:34 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 99002A4F62C;
 Wed, 28 May 2025 00:19:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6ECCFC4CEED;
 Wed, 28 May 2025 00:19: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" 
X-Inumbo-ID: 6e602045-3b59-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748391573;
	bh=QL99KBAZLyx/i6cfSBkiqr95rX6p/l42oLqqn06jaPY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=YXMKx//r9mLgq6q1ty3drsos6ngUY4FVEMyPyJEbHaBtZqcCDzt+yj3kLyK9/Eee5
	 XFkURDcLE03EqPMdgLwtwr5FY0/ogvltt0dFDrHrY3uPovW/hPqA6TCknVVdNYUxIw
	 l/ooQmqonQ5Wpl3pqknzC52Tz+gfvQjQh1DAenYI639BPqDASFIUBfSjt9VLjyOyrR
	 aciJWPtOFK1v+ryItbBNyTJNyvBd7JGnFy/MPv3Eg5fvHmYLxMs4AY7Qjl0mRJ2pVU
	 WwrorYAVBBG2cXsfnfMKT6fwqxYMYWluDYhbQj1bmwjP/yPLlrksH0GqRTkLsDRXEI
	 7t4WLYEURQgPA==
Date: Tue, 27 May 2025 17:19:31 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Anthony PERARD 
cc: Andrew Cooper , 
    Xen-devel , 
    Stefano Stabellini , 
    Michal Orzel , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH 2/3] CI: Use bash arrays to simplfy dom0 rootfs
 construction
In-Reply-To: 
Message-ID: 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com> <20250522173640.575452-3-andrew.cooper3@citrix.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 27 May 2025, Anthony PERARD wrote:
> On Thu, May 22, 2025 at 06:36:39PM +0100, Andrew Cooper wrote:
> > For Qubes, this requires switching from sh to bash.
> > 
> > This reduces the number of times the target filename needs to be written to 1.
> > 
> > Expand the comment to explain the concatination constraints.
> 
> Isn't the correct spelling "concatenation"? Same for the two comments.
> 
> > 
> > No functional change.
> > 
> > Signed-off-by: Andrew Cooper 
> > ---
> > I would like to find a slightly nicer way of conditional parts, but nothing
> > comes to mind.
> 
> Well, one way I can think of is having a new variable which can carry
> the rootfs part associated with a particular test, then that variable
> can be updated at the time we configure for that test. Something like:
> 
> # init
> declare -a append_rootfs_part
> # or append_rootfs_part=() is probably fine too.
> 
> case $test in
>   argo)
>     append_rootfs_part+=(argo.cpio.gz)
>     # ... other test configuration
>     ;;
> esac
> 
> # Dom0 rootfs
> parts=(
>     rootfs.cpio.gz
>     xen-tools.cpio.gz
>     "${append_rootfs_part[@]}"
> )
> 
> And that should works fine, even if there isn't any extra rootfs part.
> 
> > diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> > index 10af274a0ba7..1dd3f48b3d29 100755
> > --- a/automation/scripts/qubes-x86-64.sh
> > +++ b/automation/scripts/qubes-x86-64.sh
> > @@ -187,10 +187,14 @@ Kernel \r on an \m (\l)
> >      rm -rf rootfs
> >  fi
> >  
> > -# Dom0 rootfs
> > -cp binaries/ucode.cpio binaries/dom0-rootfs.cpio.gz
> > -cat binaries/rootfs.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> > -cat binaries/xen-tools.cpio.gz >> binaries/dom0-rootfs.cpio.gz
> > +# Dom0 rootfs.  The order or concatination is important; ucode wants to come
> 
>                              ^ of concatenation
> 
> Same typo in the other comment.
> 
> Beside the typo, patch looks fine:
> Reviewed-by: Anthony PERARD 

Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Wed May 28 00:30:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 00:30:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998889.1379582 (Exim 4.92)
	(envelope-from )
	id 1uK4ge-0007MY-1m; Wed, 28 May 2025 00:30:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998889.1379582; Wed, 28 May 2025 00:30: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 1uK4gd-0007MR-Uy; Wed, 28 May 2025 00:30:27 +0000
Received: by outflank-mailman (input) for mailman id 998889;
 Wed, 28 May 2025 00:30:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK4gd-0007ML-3p
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 00:30:27 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f29b930e-3b5a-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 02:30:25 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 9AB0D61137;
 Wed, 28 May 2025 00:30:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7606CC4CEE9;
 Wed, 28 May 2025 00:30: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" 
X-Inumbo-ID: f29b930e-3b5a-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748392224;
	bh=6uq1/wOLluLNtznQ+Tc8w1a6hzuCTCLFk8smqttfnzI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=lGZBNrRlqZjW6lWOGX9uXz1um2YamtClV5G2YeXlNX8vnw1SIRDizzQTUVmeU2RFa
	 IC7J65fgicB7wR2GRb3kH4e13R8PwzdWg8Qhcdqnc8WrkHMBSC1yq2mGG3J8V43GYU
	 dUtU5o/v+B9Ie/dz/hk9mByO5VTgjHyu4DMGaWqJ4xUCenMTPkkShx88JzHEn8JIwQ
	 ptNR8Osns5kCTGM/Csh5iJ7Y80UNMQ3JCkLAaSuGPNIwEqSkR9iY7psT6RVrkuZrdW
	 jbfMF8W4Ls4mxL0+SGl9pM5yHUwJGnBbna93bMW4LuQamApYIoFFgcqsNzZFn36uCY
	 x5RyHRy+dcakA==
Date: Tue, 27 May 2025 17:30:22 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Xen-devel , 
    Anthony PERARD , 
    Stefano Stabellini , 
    Michal Orzel , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH 3/3] CI: Adjust how domU is packaged in dom0
In-Reply-To: <20250522173640.575452-4-andrew.cooper3@citrix.com>
Message-ID: 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com> <20250522173640.575452-4-andrew.cooper3@citrix.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1921944850-1748392224=:135336"

  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-1921944850-1748392224=:135336
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 22 May 2025, Andrew Cooper wrote:
> Package domU in /root for dom0 and insert into the uncompressed part of dom0's
> rootfs, rather than recompressing it as part of the overlay.
> 
> For Qubes, this avoids putting the domU kernel in dom0's rootfs for tests
> which aren't going to boot a guest.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Anthony PERARD 
> CC: Stefano Stabellini 
> CC: Michal Orzel 
> CC: Marek Marczykowski-Górecki 
> ---
>  automation/scripts/qubes-x86-64.sh            | 20 +++++++++++++------
>  .../scripts/xilinx-smoke-dom0-x86_64.sh       | 16 +++++++++++----
>  2 files changed, 26 insertions(+), 10 deletions(-)
> 
> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> index 1dd3f48b3d29..17a37134f46a 100755
> --- a/automation/scripts/qubes-x86-64.sh
> +++ b/automation/scripts/qubes-x86-64.sh
> @@ -154,8 +154,8 @@ esac
>  domU_config="
>  type = '${domU_type}'
>  name = 'domU'
> -kernel = '/boot/vmlinuz'
> -ramdisk = '/boot/initrd-domU'
> +kernel = '/root/vmlinuz-domU'
> +ramdisk = '/root/initrd-domU'
>  cmdline = 'root=/dev/ram0 console=hvc0'
>  memory = 512
>  vif = [ ${domU_vif} ]
> @@ -185,12 +185,24 @@ Kernel \r on an \m (\l)
>      find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
>      cd ..
>      rm -rf rootfs
> +
> +    # Package domU kernel+rootfs in /root for dom0 (uncompressed)
> +    mkdir -p rootfs/root
> +    cd rootfs
> +    cp ../binaries/bzImage root/vmlinuz-domU
> +    cp ../binaries/domU-rootfs.cpio.gz root/initrd-domU
> +    find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
> +    cd ..
> +    rm -rf rootfs
>  fi
>  
>  # Dom0 rootfs.  The order or concatination is important; ucode wants to come
>  # first, and all uncompressed must be ahead of compressed.
>  parts=(
>      binaries/ucode.cpio
> +)
> +[ -n "$domU_check" ] && parts+=(binaries/domU-in-dom0.cpio)

This is a NIT but I have been trying to avoid this format in favor of

if [ -n "$domU_check" ]
then
    parts+=(binaries/domU-in-dom0.cpio)
fi

for readibility.


I can see the patch is correct. It adds a bit of complexity in exchange
for a small improvement. I am not sure if the trade off is worth it, but
I'll ack it anyway.

Reviewed-by: Stefano Stabellini 

I can change the style of the check on commit


> +parts+=(
>      binaries/rootfs.cpio.gz
>      binaries/xen-tools.cpio.gz
>  )
> @@ -238,10 +250,6 @@ mkdir -p etc/default
>  echo "XENCONSOLED_TRACE=all" >> etc/default/xencommons
>  echo "QEMU_XEN=/bin/false" >> etc/default/xencommons
>  mkdir -p var/log/xen/console
> -cp ../binaries/bzImage boot/vmlinuz
> -if [ -n "$domU_check" ]; then
> -    cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
> -fi
>  find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
>  cd ..
>  
> diff --git a/automation/scripts/xilinx-smoke-dom0-x86_64.sh b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> index 0fbabb41054a..29817ff81d0a 100755
> --- a/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> +++ b/automation/scripts/xilinx-smoke-dom0-x86_64.sh
> @@ -22,8 +22,8 @@ DOMU_CMD=""
>  DOMU_CFG='
>  type = "pvh"
>  name = "domU"
> -kernel = "/boot/vmlinuz"
> -ramdisk = "/boot/initrd-domU"
> +kernel = "/root/vmlinuz-domU"
> +ramdisk = "/root/initrd-domU"
>  extra = "root=/dev/ram0 console=hvc0"
>  memory = 512
>  '
> @@ -103,10 +103,20 @@ find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
>  cd ..
>  rm -rf rootfs
>  
> +# Package domU kernel+rootfs in /root for dom0 (uncompressed)
> +mkdir -p rootfs/root
> +cd rootfs
> +cp ../binaries/bzImage root/vmlinuz-domU
> +cp ../binaries/domU-rootfs.cpio.gz root/initrd-domU
> +find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
> +cd ..
> +rm -rf rootfs
> +
>  # Dom0 rootfs.  The order or concatination is important; ucode wants to come
>  # first, and all uncompressed must be ahead of compressed.
>  parts=(
>      binaries/ucode.cpio
> +    binaries/domU-in-dom0.cpio
>      binaries/rootfs.cpio.gz
>      binaries/xen-tools.cpio.gz
>  )
> @@ -127,8 +137,6 @@ echo "${DOMU_CFG}${DOMU_CFG_EXTRA}" > etc/xen/domU.cfg
>  echo "XENCONSOLED_TRACE=all" >> etc/default/xencommons
>  echo "QEMU_XEN=/bin/false" >> etc/default/xencommons
>  mkdir -p var/log/xen/console
> -cp ../binaries/bzImage boot/vmlinuz
> -cp ../binaries/domU-rootfs.cpio.gz boot/initrd-domU
>  find . | cpio -H newc -o | gzip >> ../binaries/dom0-rootfs.cpio.gz
>  cd ..
>  
> -- 
> 2.39.5
> 
--8323329-1921944850-1748392224=:135336--


From xen-devel-bounces@lists.xenproject.org Wed May 28 00:38:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 00:38:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998899.1379591 (Exim 4.92)
	(envelope-from )
	id 1uK4oG-0008IO-Oz; Wed, 28 May 2025 00:38:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998899.1379591; Wed, 28 May 2025 00:38:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uK4oG-0008IH-Ly; Wed, 28 May 2025 00:38:20 +0000
Received: by outflank-mailman (input) for mailman id 998899;
 Wed, 28 May 2025 00:38:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK4oG-0008IB-0P
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 00:38:20 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0cc28338-3b5c-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 02:38:18 +0200 (CEST)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-ad56cbc7b07so627182466b.0
 for ; Tue, 27 May 2025 17:38:18 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad8a1b5b865sm10559466b.168.2025.05.27.17.38.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 27 May 2025 17:38:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0cc28338-3b5c-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748392698; x=1748997498; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=6XII4U9fWpA94jxkMxjFFougZajWLFmoGQljKXx6uV0=;
        b=kRI9Gp24Gy3l2bLbWDsK5gynbfEDuhFVNU2oNr3TpUpRO8Rca3J4N19DJjUwxmBxLA
         1JWOVB3+JSk4BSbD774LjaPja7+l97LbW4ZN0Zyc+JYqnmGxsnhho0vw1Vs80uyhf6GC
         9Sj1vUGj+wAKsdqriuWw4aj8B+VwDmEgeXRY8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748392698; x=1748997498;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6XII4U9fWpA94jxkMxjFFougZajWLFmoGQljKXx6uV0=;
        b=ZQ4S8CYqqqlwpQhlZbBLuykQdyG1Th+2JWxNajulE1QM9cY6BFauAswgziFPFTwnRC
         X1Oa8t5ikBIHQOXLSfj1g9M5IQqKyq+w08bDUS7hc9cl0aOgMTaxHQmvhOYSKR9PK2cW
         Z5xCsj4/upOl4T3lhd8sLhAIubFlf9oQ78VblKuuiqA8u7wJP+rOObxZfsDURGCJl3xb
         iht4cid2b5ZjNA643N4FxnhZQZ4+Czt1YRbsoHoogSngEh6hOBdD0qa+kA0/w+m4ZNM9
         N+k4Q5wZjxhYkj5qSCSEd6SbKKGYQjuXOne0YAFNLMUINqFih/Av4ASFrXCTpjQIWWn9
         MH0g==
X-Gm-Message-State: AOJu0YyNrTzMalucH3JKlmMJ60v+NqWNKKlq58GKAAaIv6/oiKFqowib
	Prma0KTu20WwuYcZ2Cx3GmeV9OUhJT9ImdafaJYR8/N6CBrKOyq585KAw1VqMMtGAqw=
X-Gm-Gg: ASbGnct4E8qyQIfUmoAzT69QpjGu+DAWcCuBFykr7KmL/4EiD8tLHn7tdVFh82/4i9e
	xX0p+YmAo0j1UrxIhqGe+fcwZizouPoHC7Ogh+dk+f4u/VfitokP2BQghRhYLPulWaPHASnT4Hp
	Lym7ID4xo+kdpkTE+Tr2f4N/CUcizoPSQSBx/yR7j++IHBI0EshywtQLpdW7VdeOlLZty6pYu41
	iZ78n5PoDpZrzN6hiX4d3+803/R8UO3HEBjprpxL38pBstIn9cmquQMnT85livSDC7rdLGnIabl
	Zh4CYo30lwaNa9FGhbOUZ9eixgnq9aZK1Jx9jk7VGZ/3YwgJAk8miYl9YGBb8QP25sk92qUqKRT
	w3OaSPhXRP7dAj+GC
X-Google-Smtp-Source: AGHT+IFB719Q2GTrTdy5Ni70ywvwc65VKAez38EEtauMagA4sJcOWabt5/+p7tJUoZsx9aApKC6hLg==
X-Received: by 2002:a17:907:7215:b0:ad8:9b5d:2c1f with SMTP id a640c23a62f3a-ad89b5d2e9dmr155216766b.50.1748392698062;
        Tue, 27 May 2025 17:38:18 -0700 (PDT)
Message-ID: 
Date: Wed, 28 May 2025 01:38:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/3] CI: Adjust how domU is packaged in dom0
To: Stefano Stabellini 
Cc: Xen-devel ,
 Anthony PERARD ,
 Michal Orzel ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
 <20250522173640.575452-4-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

On 28/05/2025 1:30 am, Stefano Stabellini wrote:
> On Thu, 22 May 2025, Andrew Cooper wrote:
>> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
>> index 1dd3f48b3d29..17a37134f46a 100755
>> --- a/automation/scripts/qubes-x86-64.sh
>> +++ b/automation/scripts/qubes-x86-64.sh
>> @@ -185,12 +185,24 @@ Kernel \r on an \m (\l)
>>      find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
>>      cd ..
>>      rm -rf rootfs
>> +
>> +    # Package domU kernel+rootfs in /root for dom0 (uncompressed)
>> +    mkdir -p rootfs/root
>> +    cd rootfs
>> +    cp ../binaries/bzImage root/vmlinuz-domU
>> +    cp ../binaries/domU-rootfs.cpio.gz root/initrd-domU
>> +    find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
>> +    cd ..
>> +    rm -rf rootfs
>>  fi
>>  
>>  # Dom0 rootfs.  The order or concatination is important; ucode wants to come
>>  # first, and all uncompressed must be ahead of compressed.
>>  parts=(
>>      binaries/ucode.cpio
>> +)
>> +[ -n "$domU_check" ] && parts+=(binaries/domU-in-dom0.cpio)
> This is a NIT but I have been trying to avoid this format in favor of
>
> if [ -n "$domU_check" ]
> then
>     parts+=(binaries/domU-in-dom0.cpio)
> fi
>
> for readibility.

This is a weird one, because the (relevant) readability is the
components of parts, and it's easier to scan without the extra blank
lines.  Nevertheless, ...

>
>
> I can see the patch is correct. It adds a bit of complexity in exchange
> for a small improvement. I am not sure if the trade off is worth it, but
> I'll ack it anyway.

... see the thread on the previous patch.  This was the RFC "I'd like to
find a nicer way of doing it", and Anthony has made a suggestion which I
need to experiment with.

> Reviewed-by: Stefano Stabellini 

Thanks, but do you have any input on the /boot vs /root question on the
other part of the thread?

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 28 01:00:19 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 01:00:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998907.1379602 (Exim 4.92)
	(envelope-from )
	id 1uK59P-0007N4-EH; Wed, 28 May 2025 01:00:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998907.1379602; Wed, 28 May 2025 01:00: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 1uK59P-0007MG-BL; Wed, 28 May 2025 01:00:11 +0000
Received: by outflank-mailman (input) for mailman id 998907;
 Wed, 28 May 2025 01:00:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK59N-0006hB-Ps
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 01:00:09 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1601bb86-3b5f-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 03:00:03 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id DEFDF5C5527;
 Wed, 28 May 2025 00:57:43 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BCF16C4CEE9;
 Wed, 28 May 2025 00:59: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" 
X-Inumbo-ID: 1601bb86-3b5f-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748394000;
	bh=bKPm1y3NFIvS3iIJFfSjTTplJBpzzVHrcWXO3eeajEE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=u0L440G0by+6XYvoIoO7QzLHWSpyOJcQNHatVqCdQ2tJES6k5nxg86pKj0BLJq+Y6
	 G68VRUxXHD7AEuK2Zv4a7f8JsjqYGFJCGLbrc2k32hJhIvmJcV0a65EIDo2gvK0qQ2
	 xCeslOR12Kfek2WG81lKO5XOi6q1BUcXjsvepTBilw0cS32ZHb2p4TvaWFlSFy4CnO
	 bxvcWEMsP4m+k9dg/UbBSLMGbaFRRcGMc5Gq8gNCEDsnaNPEB0Aaw19tu2Fa0FR6Gr
	 PfD+0EddeQ2s43d1sDUsfc0jkW8SLJ+WU7s8ovg6cJcl76+nD71GnpVXMMoDygxHal
	 mhVGfmRr5IEPQ==
Date: Tue, 27 May 2025 17:59:58 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Andrew Cooper 
cc: Stefano Stabellini , 
    Xen-devel , 
    Anthony PERARD , 
    Michal Orzel , 
    =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Subject: Re: [PATCH 3/3] CI: Adjust how domU is packaged in dom0
In-Reply-To: 
Message-ID: 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com> <20250522173640.575452-4-andrew.cooper3@citrix.com>  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1730604225-1748394000=:135336"

  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-1730604225-1748394000=:135336
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Wed, 28 May 2025, Andrew Cooper wrote:
> On 28/05/2025 1:30 am, Stefano Stabellini wrote:
> > On Thu, 22 May 2025, Andrew Cooper wrote:
> >> diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh
> >> index 1dd3f48b3d29..17a37134f46a 100755
> >> --- a/automation/scripts/qubes-x86-64.sh
> >> +++ b/automation/scripts/qubes-x86-64.sh
> >> @@ -185,12 +185,24 @@ Kernel \r on an \m (\l)
> >>      find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz
> >>      cd ..
> >>      rm -rf rootfs
> >> +
> >> +    # Package domU kernel+rootfs in /root for dom0 (uncompressed)
> >> +    mkdir -p rootfs/root
> >> +    cd rootfs
> >> +    cp ../binaries/bzImage root/vmlinuz-domU
> >> +    cp ../binaries/domU-rootfs.cpio.gz root/initrd-domU
> >> +    find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio
> >> +    cd ..
> >> +    rm -rf rootfs
> >>  fi
> >>  
> >>  # Dom0 rootfs.  The order or concatination is important; ucode wants to come
> >>  # first, and all uncompressed must be ahead of compressed.
> >>  parts=(
> >>      binaries/ucode.cpio
> >> +)
> >> +[ -n "$domU_check" ] && parts+=(binaries/domU-in-dom0.cpio)
> > This is a NIT but I have been trying to avoid this format in favor of
> >
> > if [ -n "$domU_check" ]
> > then
> >     parts+=(binaries/domU-in-dom0.cpio)
> > fi
> >
> > for readibility.
> 
> This is a weird one, because the (relevant) readability is the
> components of parts, and it's easier to scan without the extra blank
> lines.  Nevertheless, ...
> 
> >
> >
> > I can see the patch is correct. It adds a bit of complexity in exchange
> > for a small improvement. I am not sure if the trade off is worth it, but
> > I'll ack it anyway.
> 
> ... see the thread on the previous patch.  This was the RFC "I'd like to
> find a nicer way of doing it", and Anthony has made a suggestion which I
> need to experiment with.

OK


> > Reviewed-by: Stefano Stabellini 
> 
> Thanks, but do you have any input on the /boot vs /root question on the
> other part of the thread?

I saw it. I don't have a strong opinion either way. Technically /boot is
correct but then things gets mixed up with Dom0 kernel and ramdisk.
/root allows it to be more clearly separated so I am OK with it.
--8323329-1730604225-1748394000=:135336--


From xen-devel-bounces@lists.xenproject.org Wed May 28 04:19:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 04:19:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998929.1379612 (Exim 4.92)
	(envelope-from )
	id 1uK8Fb-0000uw-IH; Wed, 28 May 2025 04:18:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998929.1379612; Wed, 28 May 2025 04: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 1uK8Fb-0000up-FG; Wed, 28 May 2025 04:18:47 +0000
Received: by outflank-mailman (input) for mailman id 998929;
 Wed, 28 May 2025 04:18:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK8Fa-0000uj-PM
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 04:18:46 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d8360efc-3b7a-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 06:18:45 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 6CA56A49F26;
 Wed, 28 May 2025 04:18:44 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1853CC4CEEE;
 Wed, 28 May 2025 04:18:44 +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
 70C423822D1A; Wed, 28 May 2025 04:19: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" 
X-Inumbo-ID: d8360efc-3b7a-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748405924;
	bh=tAWlwB6ykqQxS1QLPFAsLHiuVFSX900WKZppAKmrneg=;
	h=Subject:From:In-Reply-To:References:Date:To:Cc:From;
	b=QAQnFy55AckNf1DnJNOe/iehBt5q5cuCO2xYG8uiGAmvGukk6IK59vp9oGB70Bp0H
	 4ULDIqMRcUX2jXk4uQd0E+hF5CtEVVEN7SyqY/OUfp6SCqdzuiesA32qDJ1oo80qZC
	 fZzZXiOGb85gcI+2ASsjF8vjwo7DGvRgqvyjtenoSl8UtMcem/DdEjTnNuc+L3p2rr
	 1vpNSpmqWFoI5eLzaJKCP8lQETCZASINb2HJJ4zWofq11EhaJsZrJR2H42ik+uOQtY
	 RtKo/RYWesGfYnFwsti7iz2sUpQAklpnXI4jTSMUMZ/0wPpVxkI7iyFb9aB5RtCdIR
	 ngRpI18lwl6Ow==
Subject: Re: [GIT PULL] xen: branch for v6.16-rc1
From: pr-tracker-bot@kernel.org
In-Reply-To: <20250526063307.10920-1-jgross@suse.com>
References: <20250526063307.10920-1-jgross@suse.com>
X-PR-Tracked-List-Id: 
X-PR-Tracked-Message-Id: <20250526063307.10920-1-jgross@suse.com>
X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.16-rc1-tag
X-PR-Tracked-Commit-Id: 7f9bbc1140ff8796230bc2634055763e271fd692
X-PR-Merge-Tree: torvalds/linux.git
X-PR-Merge-Refname: refs/heads/master
X-PR-Merge-Commit-Id: 5cf5240991bcea3c0f38e36e65e1742d6db7912c
Message-Id: <174840595796.1893196.3827206882663532833.pr-tracker-bot@kernel.org>
Date: Wed, 28 May 2025 04:19:17 +0000
To: Juergen Gross 
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org

The pull request you sent on Mon, 26 May 2025 08:33:07 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.16-rc1-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5cf5240991bcea3c0f38e36e65e1742d6db7912c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From xen-devel-bounces@lists.xenproject.org Wed May 28 05:44:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 05:44:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998761.1379621 (Exim 4.92)
	(envelope-from )
	id 1uK9Zt-0003LU-Gc; Wed, 28 May 2025 05:43:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998761.1379621; Wed, 28 May 2025 05:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uK9Zt-0003LN-E6; Wed, 28 May 2025 05:43:49 +0000
Received: by outflank-mailman (input) for mailman id 998761;
 Tue, 27 May 2025 21:29:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uK1rh-00043H-Gk
 for xen-devel@lists.xenproject.org; Tue, 27 May 2025 21:29:41 +0000
Received: from mailrelay2-1.pub.mailoutpod3-cph3.one.com
 (mailrelay2-1.pub.mailoutpod3-cph3.one.com [2a02:2350:5:421::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aec6fc42-3b41-11f0-b894-0df219b8e170;
 Tue, 27 May 2025 23:29:39 +0200 (CEST)
Received: from onecom-webmail-backend-production-66cfbfc4bc-dsl4r
 (service.pub.live1-k8s-cph3.one.com [46.30.212.67])
 by mailrelay2.pub.mailoutpod3-cph3.one.com (Halon) with ESMTPSA
 id ae4d2930-3b41-11f0-bbb9-b37c246f863f;
 Tue, 27 May 2025 21:29: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" 
X-Inumbo-ID: aec6fc42-3b41-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1748381373; x=1748986173;
	d=contentwise.tech; s=rsa1;
	h=content-type:subject:reply-to:from:to:message-id:mime-version:date:from;
	bh=82lleuMVJ4vdnG8UNVg3X6/QtlcEgxb3VpDf/bSxoKI=;
	b=NHyXPsZnkPZm47AGHZBrBD1t7RwgvNWhatgOc/u7Hp6BQGuGYKaBE0ViCV1nWePsCa9204fIZOFqy
	 Iho+VenZbkNxFKShT8MQd4F3BBuVd1ErhRLE4AFTmGKnQuSH5qHBlkI9xBmK7Nc2+uxA4q6ItTXOA8
	 ihaai4oVKL9ym+Mq12Edu6TRm46FdWqRTLdhXjIiNBSn2KNVA6s3Ywk+48qoKQ3M2GqAMV9Wbd95Wp
	 oksMjf8fKf1CpskeAgFFPJpfcY9gygtpCK6AJP7J5o2i2X7OyCIM/GMHxFw2Cp3FnsQ83mVGON4T1r
	 8ohk8o/YkqtH1LWyjtYwGWUCr9zaNbQ==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1748381373; x=1748986173;
	d=contentwise.tech; s=ed1;
	h=content-type:subject:reply-to:from:to:message-id:mime-version:date:from;
	bh=82lleuMVJ4vdnG8UNVg3X6/QtlcEgxb3VpDf/bSxoKI=;
	b=tvKiGAyuTqX+9XB3X3gobfpfOCshhICay2uhWGCkbwfrTk1BwE2FUuuYHshANAex+dnA8OgGbxS94
	 7AJL1JUBQ==
X-HalOne-ID: ae4d2930-3b41-11f0-bbb9-b37c246f863f
X-Originating-IP: 83.44.120.208
User-Agent: One.com webmail 48.1.11
Date: Tue, 27 May 2025 23:29:32 +0200
MIME-Version: 1.0
Message-ID: <1748381372906.7.62038@webmail-backend-production-66cfbfc4bc-ddzt7>
To: , "Julien Grall" ,
 "Stefano Stabellini" , "Bertrand Marquis"
 , "Volodymyr Babchuk" ,
 , 
From: "Evgeny Beysembaev" 
Reply-To: 
Subject: [PATCH] BCM2711 reboot fix
Content-Type: multipart/mixed; boundary="----------62036-1748381372906-1"

This is a multipart message in MIME format.

------------62036-1748381372906-1
Content-Type: multipart/alternative;
 boundary="----------62036-1748381372906-2"

------------62036-1748381372906-2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8





------------62036-1748381372906-2
Content-Type: multipart/related; boundary="----------62036-1748381372906-3"

------------62036-1748381372906-3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8




    

------------62036-1748381372906-3--
------------62036-1748381372906-2--
------------62036-1748381372906-1
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=0001-BCM2711-reboot-fix.patch
Content-Type: text/x-patch; name="0001-BCM2711-reboot-fix.patch"

RnJvbSAwMDU3ZDE0NWRkZDkwYzAxOTIyNjM2MjA1NDg0MDg4YzAyYTBlNDVhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpNZXNzYWdlLUlEOiA8MDA1N2QxNDVkZGQ5MGMwMTkyMjYzNjIwNTQ4NDA4
OGMwMmEwZTQ1YS4xNzQ4MzgwODAwLmdpdC5tZWdhYm90dmFAZ21haWwuY29tPgpGcm9tOiBFdmdl
bnkgQmV5c2VtYmFldiA8ZXZnZW55QGNvbnRlbnR3aXNlLnRlY2g+CkRhdGU6IFR1ZSwgMjcgTWF5
IDIwMjUgMTM6NDg6MzEgKzAyMDAKU3ViamVjdDogW1BBVENIXSBCQ00yNzExIHJlYm9vdCBmaXgK
CkFjY29yZGluZyB0byB0aGUgY29tbWl0IGIzMzRjMWFmYWQxNzEzMmEzYzIzNjBkZTY0YzFjZmZm
OTA5MDg3MzkgaW4gTGludXgKa2VybmVsLCB0aGUgYGNvbXBhdGlibGVgIHN0cmluZyBmb3IgdGhl
IHdhdGNoZG9nIHBlcmlwaGVyYWwgaW4gdGhlIERUUyB3YXMgbW9kaWZpZWQgZnJvbQpgYnJjbSxi
Y20yODM1LXBtYCB0byBgYnJjbSxiY20yNzExLXBtYCwgd2hpY2ggY2F1c2VkCmBycGk0X21hcF93
YXRjaGRvZygpYCBmdW5jdGlvbiB0byBmYWlsLCBsZWFkaW5nIHRvIGluYWJpbGl0eSB0byByZWJv
b3QKdGhlIHN5c3RlbSB1bmRlciBYZW4gaHlwZXJ2aXNvci4KClNpZ25lZC1vZmYtYnk6IEV2Z2Vu
eSBCZXlzZW1iYWV2IDxldmdlbnlAY29udGVudHdpc2UudGVjaD4KLS0tCiB4ZW4vYXJjaC9hcm0v
cGxhdGZvcm1zL2JyY20tcmFzcGJlcnJ5LXBpLmMgfCAyICstCiAxIGZpbGUgY2hhbmdlZCwgMSBp
bnNlcnRpb24oKyksIDEgZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vcGxh
dGZvcm1zL2JyY20tcmFzcGJlcnJ5LXBpLmMgYi94ZW4vYXJjaC9hcm0vcGxhdGZvcm1zL2JyY20t
cmFzcGJlcnJ5LXBpLmMKaW5kZXggODExYjQwYjFhNi4uMTFlNzk4NTU3NSAxMDA2NDQKLS0tIGEv
eGVuL2FyY2gvYXJtL3BsYXRmb3Jtcy9icmNtLXJhc3BiZXJyeS1waS5jCisrKyBiL3hlbi9hcmNo
L2FybS9wbGF0Zm9ybXMvYnJjbS1yYXNwYmVycnktcGkuYwpAQCAtNjAsNyArNjAsNyBAQCBzdGF0
aWMgdm9pZCBfX2lvbWVtICpycGk0X21hcF93YXRjaGRvZyh2b2lkKQogICAgIHBhZGRyX3Qgc3Rh
cnQsIGxlbjsKICAgICBpbnQgcmV0OwogCi0gICAgbm9kZSA9IGR0X2ZpbmRfY29tcGF0aWJsZV9u
b2RlKE5VTEwsIE5VTEwsICJicmNtLGJjbTI4MzUtcG0iKTsKKyAgICBub2RlID0gZHRfZmluZF9j
b21wYXRpYmxlX25vZGUoTlVMTCwgTlVMTCwgImJyY20sYmNtMjcxMS1wbSIpOwogICAgIGlmICgg
IW5vZGUgKQogICAgICAgICByZXR1cm4gTlVMTDsKIAotLSAKMi40Ny4yCgo=

------------62036-1748381372906-1--



From xen-devel-bounces@lists.xenproject.org Wed May 28 08:06:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 08:06:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998971.1379641 (Exim 4.92)
	(envelope-from )
	id 1uKBnX-0003Cw-4a; Wed, 28 May 2025 08:06:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998971.1379641; Wed, 28 May 2025 08: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 1uKBnX-0003Cp-1i; Wed, 28 May 2025 08:06:03 +0000
Received: by outflank-mailman (input) for mailman id 998971;
 Wed, 28 May 2025 08:06:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKBnV-0002zC-NW
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 08:06:01 +0000
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [2a00:1450:4864:20::133])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 981d18a0-3b9a-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 10:06:01 +0200 (CEST)
Received: by mail-lf1-x133.google.com with SMTP id
 2adb3069b0e04-55324e35f49so3038485e87.3
 for ; Wed, 28 May 2025 01:06:01 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32a79f5478asm1437671fa.78.2025.05.28.01.05.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 28 May 2025 01:05: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" 
X-Inumbo-ID: 981d18a0-3b9a-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748419560; x=1749024360; 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;
        bh=nWHKDiY0thxryffwYCZVKNiFBLA5cr2n5GezmHVCMtI=;
        b=Rclji4/C+2uqJ/fusqYMZk9ouBX+bg+tNoTI6XS+4KHW45d4Se5q7HldrzNztUoUp0
         rbxgFw/MuunS3+LJdHpUNH8RqIyOqLjw0kdGzjzY2Os4WW6l+LMYxlm1pMaRObadu0EO
         lYqg3o+7JJvu2tRHPSbEvLtA8jkCphiEP1Q568squberN754C9WViIbF42BH7SsbblHQ
         nytKffHcXjUgIxY93Ayalpa2yC/rK2DE/R1MWWa0ZatXm7qzguF0ePFE2/hoPV3WQRUz
         3ucWYOf0q5e+anBVXfmRJMrZWiBRNOakmu2KB/2kMDWrPt4AeNyMjqOS7Rng4EK8ZQ73
         v3Pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748419560; x=1749024360;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=nWHKDiY0thxryffwYCZVKNiFBLA5cr2n5GezmHVCMtI=;
        b=gnHSPs1ZudQmG662oCjQNVcNDK+KGnWz8MTOGBxhJT7fqRRxjqJ9bHw8wGpDCCCA5M
         19A6sigk5472ZFwcEU3m9/dzthf+3WpnW/4Jkq+eJkFZsAzapM6fYaQzKkWCWkfGeHAr
         uKl/VL6ieH+YyPfH+g9MxSXmUAbQo4I2Y+BC2llhDiYOQYEjbpUr8ImH7GQ4tF1N0D+T
         mrk3mCYxvaQZIxBYjTfCtjUYGrhqB0VjjYDKRMNZzezw4kvrTWX0u/0OrHE4AWm6O0aA
         Fn+2sj4Jwm/zJJ0NieP/Fom17Mo/itn6gAF1ZlR/Dcn/FdcWD1z3SILWpJ5kFHaYi+Sv
         jQmA==
X-Gm-Message-State: AOJu0Yzu8wd/NIoHCx+p08RJ6JIh8x/yoZhh9QDSHpYA2rt0X2OXg/DM
	sGYNp5JWyZrg1oRAdhrfqcUrw7QMoqjs3RT4h8eQR/kgMVHV+OaXJ6gp0eMyug==
X-Gm-Gg: ASbGncs/YcuQzLEBSYxnhx/XgJwoKqiWV1FLYXUNIYv8xwUiuwNTugl6+KzuJ0sJcll
	g4M+np3MFST6Qu8HO7m7KvWokZq719HiRMu5WP+qtoLp7YF26YS27IFLuAJZoW7DSLbGXw8yvyY
	PeDhwQgUWLr6D9HyopR5mcYFWaALr9vKzqX/vVHpZJP1fRFOAN/Ai2OzmFu5qpv55v5mtMXvaWx
	mnDqo4KOhUAhiFBZu4BcJDxdXJcFJ1AIjf+fGEyNB+wil5MR0YrUCkiBxPPkpMymu8XnyABsYly
	cvSHspA7oxA62zbVmqTLS+DXgZFxnjFAqt7lmy3CRlKoLnufEF/eJ1vxztFDwaP4EN0fm53YUXh
	q/KM609U52LYDo+s=
X-Google-Smtp-Source: AGHT+IG46T1yCCola3jKBu0pKLJ9cYvzD+gAljJzZ9ZT8ZgrW91kJLWoq9Jcu3TK0gWyfe9oQp50dg==
X-Received: by 2002:a2e:ae0c:0:b0:30b:b908:ce06 with SMTP id 38308e7fff4ca-32a79accc61mr2898571fa.19.1748419559953;
        Wed, 28 May 2025 01:05:59 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Mykyta Poturai 
Subject: [PATCH v2 1/2] xen: Introduce system suspend config option
Date: Wed, 28 May 2025 11:05:18 +0300
Message-ID: 
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

This option enables the system suspend support. This is the mechanism that
allows the system to be suspended to RAM and later resumed.

The patch introduces three options:
- HAS_SYSTEM_SUSPEND: indicates suspend support is available on the platform.
- SYSTEM_SUSPEND_ALWAYS_ON: used for architectures where suspend must always
  be enabled.
- SYSTEM_SUSPEND: user-facing option to enable/disable suspend if supported.
  Defaults to enabled if SYSTEM_SUSPEND_ALWAYS_ON is set and depends on
  HAS_SYSTEM_SUSPEND.

On x86, both HAS_SYSTEM_SUSPEND and SYSTEM_SUSPEND_ALWAYS_ON are selected by
default, making suspend support always enabled. The options are designed to
be easily extensible to other architectures (e.g., PPC, RISC-V) as future
support is added.

Signed-off-by: Mykyta Poturai 
Signed-off-by: Mykola Kvach 
---
Discussion on adding the SYSTEM_SUSPEND config can be found here:
https://lists.xenproject.org/archives/html/xen-devel/2025-03/msg00169.html
---
 xen/arch/x86/Kconfig |  2 ++
 xen/common/Kconfig   | 17 +++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7afe879710..f7c026b0aa 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -33,6 +33,8 @@ config X86
 	select HAS_VMAP
 	select HAS_VPCI if HVM
 	select NEEDS_LIBELF
+	select HAS_SYSTEM_SUSPEND
+	select SYSTEM_SUSPEND_ALWAYS_ON
 
 config ARCH_DEFCONFIG
 	string
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 3d66d09397..3886a77e46 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -579,4 +579,21 @@ config BUDDY_ALLOCATOR_SIZE
 	  Amount of memory reserved for the buddy allocator to serve Xen heap,
 	  working alongside the colored one.
 
+config HAS_SYSTEM_SUSPEND
+	bool
+
+config SYSTEM_SUSPEND_ALWAYS_ON
+	bool
+
+config SYSTEM_SUSPEND
+	bool "System suspend support"
+	depends on HAS_SYSTEM_SUSPEND
+	default y if SYSTEM_SUSPEND_ALWAYS_ON
+	help
+	  This option enables the system suspend support. This is the
+	  mechanism that allows the system to be suspended to RAM and
+	  later resumed.
+
+	  If unsure, say N.
+
 endmenu
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 08:06:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 08:06:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998970.1379631 (Exim 4.92)
	(envelope-from )
	id 1uKBnV-0002zT-Ug; Wed, 28 May 2025 08:06:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998970.1379631; Wed, 28 May 2025 08: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 1uKBnV-0002zM-Rd; Wed, 28 May 2025 08:06:01 +0000
Received: by outflank-mailman (input) for mailman id 998970;
 Wed, 28 May 2025 08:06:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKBnU-0002zC-Pd
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 08:06:00 +0000
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [2a00:1450:4864:20::229])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 96e112f0-3b9a-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 10:05:59 +0200 (CEST)
Received: by mail-lj1-x229.google.com with SMTP id
 38308e7fff4ca-3106217268dso38454721fa.1
 for ; Wed, 28 May 2025 01:05:59 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32a79f5478asm1437671fa.78.2025.05.28.01.05.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 28 May 2025 01:05:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 96e112f0-3b9a-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748419558; x=1749024358; 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;
        bh=Pf1pYaaf9NAukq3r1Eh0Q6+adfJo6MUqgAu5HCoZAxo=;
        b=DSDBGFXlyTgEPMTwQa0/Yh0mniz5hSp4bhZY5GgNWvQvOgT/IzNU2tjetxQjgEez3c
         lqx9dF8JHlyGajpR6rLxddARhfI+ZjWjpykVr4uHET++pXVjKJMDSYnlVjeWyqN04F3r
         gFjc7HZIwCtLqeZ7HXujKH9/GpjniwM2y4XO6do5ufmoCYvBE89Z1cNVpsEjhOGkLYg0
         ahmntJ8T3GLZcWb5wlDpfMKvgQEubkPAZxWHCyKsVktEjyT/vQzWQfHFccomB6Hj9YID
         PBZUQ5AQ4zjVXQ6LB3AG8txk48vxipYf/TGTjCfuzJWHJUZKRE9G+nQc2jFdr9zsobTj
         jTqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748419558; x=1749024358;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Pf1pYaaf9NAukq3r1Eh0Q6+adfJo6MUqgAu5HCoZAxo=;
        b=MMEcx9mx4qK96GaAPm2fp4f8y4LWCcj+v/6fifrU180bCLGcovASIep1JGReXoEIR8
         7IFkI0SAKcc3zHcA6ltknjRroapZlDVzF/gkjUzmmNC//diZtX8JyGqmUncwbrp12caK
         TRg7xnYfETBSdZPWQghBCtdIZvbBWMpOJKhXrp1+bEtdk+PAKH4/wD1tfJGbreS7Ggqn
         7BdBET6oq+vnTZdLZszQeCqxYEkzdtL55R44flRf6QfG0LunPtmA8psUM+/0B2sOAjSo
         OBDunyO55giyTjc7jpbM9spopcu0lYgNkj2cYvaCD9Nvoy6FHOih7pvAwvAswXxY3pyP
         PV7w==
X-Gm-Message-State: AOJu0YwqENYz2SGKW8/UKzb6i0Q8El6tJ/OLS/z74JkTzcbT/tWQ/It6
	slGPW5p62jlBGDnXFc8fTaBPi7HQY150mj7jg9w7o1WBCppBzY7YzayIik/h4Q==
X-Gm-Gg: ASbGncv4zuulgvD81XLOzsfYUvHta0bbxl233c704DrEpbra7BuIRPFotiD9tfRtMQW
	A7H0oKflUWtlSDREBcZCauuh9F2owbZizsiiZ0ld+1Pe+5VzPQMnV8ngX7IGuuVsBed/mVTQfrP
	vR3QZQgxSybZc10eGvVMXoonjLS+kJ5N8Aahh3rLZhHZFG4uAkN/B6QUyv+LySd3u8FO4lGYWD3
	IyCsPyGYQyvcVTjiMM8uFyTZWniHbY9Q83KKHp9QMUnkSvxwOreVJYmNzgXXRXU69rllACMWLEG
	SUgyvLabwCNPMmcEL9AITTgwbqOJc3z6jXlM3P3ggaMkKLUVt8qEfv4mlOsjNNrEeAWzk13Pzlz
	RpmPBSDCn3ja9/MY6qvPJN45K/w76qVJqHmYn
X-Google-Smtp-Source: AGHT+IEJC6MZ/9R31TiqlrRoh+pl7vlJu08vXFaha9FalWLofKJTuuF37SHQM4ZbAPScCvROp4CgRA==
X-Received: by 2002:a05:651c:2207:b0:32a:7e4c:e915 with SMTP id 38308e7fff4ca-32a7e4ceb14mr1190761fa.29.1748419558020;
        Wed, 28 May 2025 01:05:58 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH v2 0/2] Add CONFIG_SYSTEM_SUSPEND and SCIF UART suspend/resume handlers
Date: Wed, 28 May 2025 11:05:17 +0300
Message-ID: 
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

Hi all,

This patch series introduces CONFIG_SYSTEM_SUSPEND to Xen and implements
suspend/resume handlers for the SCIF UART driver. These changes address
feedback and discussions on the Xen-devel mailing list:

    https://lists.xenproject.org/archives/html/xen-devel/2025-03/msg00169.html
    https://lists.xenproject.org/archives/html/xen-devel/2025-03/msg02188.html

I am marking this series as v2, as it is a logical continuation of the
discussion linked above regarding the SCIF driver changes.

Patch 1:
  Introduces the CONFIG_SYSTEM_SUSPEND infrastructure, which enables Xen to
support suspend-to-RAM functionality. It adds three new Kconfig options:
    - HAS_SYSTEM_SUSPEND: Indicates whether the architecture supports suspend.
    - SYSTEM_SUSPEND_ALWAYS_ON: Forces suspend support on platforms that
      require it (e.g., x86).
    - SYSTEM_SUSPEND: The user-facing option to enable suspend support,
      enabled by default when SYSTEM_SUSPEND_ALWAYS_ON is set.
      
  This approach is intended to be easily extendable to other architectures in
the future.

Patch 2:
  Implements suspend/resume callbacks for the SCIF UART driver. These functions
ensure proper shutdown and reinitialization of the UART hardware across
suspend/resume cycles. Their inclusion is gated by the CONFIG_SYSTEM_SUSPEND
option.
  The SCIF suspend/resume functionality has been tested on the Renesas R-Car H3
Starter Kit board.
  Compared to v1, the main change in this version is the addition of a
CONFIG_SYSTEM_SUSPEND check around the SCIF driver's suspend/resume logic.

Best regards,
Mykola Kvach


Mykola Kvach (1):
  xen: Introduce system suspend config option

Volodymyr Babchuk (1):
  xen/char: implement suspend/resume calls for SCIF driver

 xen/arch/x86/Kconfig         |  2 ++
 xen/common/Kconfig           | 17 +++++++++++++++
 xen/drivers/char/scif-uart.c | 40 ++++++++++++++++++++++++++++++++++--
 3 files changed, 57 insertions(+), 2 deletions(-)

-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 08:06:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 08:06:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998972.1379652 (Exim 4.92)
	(envelope-from )
	id 1uKBnb-0003TA-B6; Wed, 28 May 2025 08:06:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998972.1379652; Wed, 28 May 2025 08:06: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 1uKBnb-0003T3-7j; Wed, 28 May 2025 08:06:07 +0000
Received: by outflank-mailman (input) for mailman id 998972;
 Wed, 28 May 2025 08:06:05 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKBnZ-0003Ro-P5
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 08:06:05 +0000
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com
 [2a00:1450:4864:20::12b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 99029b4a-3b9a-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 10:06:02 +0200 (CEST)
Received: by mail-lf1-x12b.google.com with SMTP id
 2adb3069b0e04-54afb5fcebaso5384115e87.3
 for ; Wed, 28 May 2025 01:06:02 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32a79f5478asm1437671fa.78.2025.05.28.01.06.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 28 May 2025 01:06:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 99029b4a-3b9a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748419561; x=1749024361; 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;
        bh=9dWxP7Icxj1+b68Zu3OZEwOOJEHkIKPApD7TkfsOeh4=;
        b=JdpB73NzhO1Fnvap+aqJxwPlKOJWRow+OKWmBPv5vdxdoTBrPP86Briiekq8RNwyy5
         /XD8rif+RfkfVv1Bcn4hzmWSmvpmZtlgquFQDpmujOLCdRUDYqKbnw9bBOsBx7oxEAPI
         e19dM0q8kdO03D6TDFiKDPGvy94gBESMPrYtdZWYGN5TaVbFnZa2FMVSnynRqfCkJUsQ
         xbltNFIzF20jjDrSDmEuFdWzoyjo0LDL1fMdOZXnciLOAAGPy5HWu75C2+d/XpoNSN2w
         jgBp20Ga2TNBjxb7SS7Pw17ZIUJPatBFHRjG5jxiWvaN782CG4yMqRtdgtOcLc1/yhcp
         CC0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748419561; x=1749024361;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=9dWxP7Icxj1+b68Zu3OZEwOOJEHkIKPApD7TkfsOeh4=;
        b=s/wlnxmQdicrJ39MkELnSpHZ4AolkBTULc2jqoXODomyXDpNneiNzp+nFwwI/qbxIU
         teERRwlPlaR8qMUvsYwjzORdiplqFPo1IoE9Mj5k4cphYVeA0aCNkHtM1KlsX6qSOtWY
         FGgXTDgEqDtV/d3sWuSWcXJauq/6TJWJbX4+Hzi+OHEqsvvSJjzpkQXFj8BT6CEaoK3o
         L/r8aaO2/AuwK5fN4nd7axC94S5dm4jywJfUzhF9GMlwkBpGYgXzyqLhd1oP8mngdFpA
         sFKHxTUjK9S02GGDvl1AxG6e6ikRLdG0vdYGKGpPTJvtiQppDO80Fley89s23pfoy/6a
         QvuQ==
X-Gm-Message-State: AOJu0YzGmUItspWTThY0Z0UJG52bwmWxvmHGHPFfe+Ee5WljgwPc4gWv
	xq16P7diKA/8nxoLQ1n3S1mEC14ihVSRltZ7jagnk/DxuyQ11tEn2qu84oEfHw==
X-Gm-Gg: ASbGncsSGM2/51Ucyy2ry52kfAGPNRPHbsFWw1JJEZTEVza5z3laX9MVwJnYiujuyEX
	WA/fkNwMeXbCYo+ufNZqy4RObjZ4SHf95KqSCedHdtbqNChcvtbcrGD3ywfKtqOuXsJHhuSJ/ay
	wkBN/fe3FDFPas/+9yT9SpgG8etnNEX3/ZMfEdQpUqwYN56GOTENrKc7wHrCvR+JcVwChFofvR4
	lSAzBUZbbdWg19DjaKIm1nwBuKeA+A3EHt11mAI7taRQoNpuycTK2TyDCBEMtrIos/WICYdUlHK
	9qz/Tiypw8/P3egtlz/Oy8msNW/jHqxmI8WVsGHGIU3LpNsXtF4fH4bkDvPoQ5OWmPE6nM07PEK
	JrjlXq1wHfwvnTG4=
X-Google-Smtp-Source: AGHT+IG6u5YLRxmcByItaH8PWCNYHSyVYF7Eh3p2pFq0FQVKsPfgi80VcoNfxaXymwzalNg0N635lw==
X-Received: by 2002:a05:6512:3055:b0:553:2fb1:cfe9 with SMTP id 2adb3069b0e04-5532fb1e6aemr286965e87.21.1748419561240;
        Wed, 28 May 2025 01:06:01 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Volodymyr Babchuk ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Oleksandr Andrushchenko ,
	Mykola Kvach 
Subject: [PATCH v2 2/2] xen/char: implement suspend/resume calls for SCIF driver
Date: Wed, 28 May 2025 11:05:19 +0300
Message-ID: 
X-Mailer: git-send-email 2.48.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Volodymyr Babchuk 

The changes have been tested only on the Renesas R-Car H3 Starter Kit board.

Signed-off-by: Volodymyr Babchuk 
Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykola Kvach 
---
In patch v2, I just added a CONFIG_SYSTEM_SUSPEND check around
the suspend/resume functions in the SCIF driver.
---
 xen/drivers/char/scif-uart.c | 40 ++++++++++++++++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index 757793ca45..888821a3b8 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -139,9 +139,8 @@ static void scif_uart_interrupt(int irq, void *data)
     }
 }
 
-static void __init scif_uart_init_preirq(struct serial_port *port)
+static void scif_uart_disable(struct scif_uart *uart)
 {
-    struct scif_uart *uart = port->uart;
     const struct port_params *params = uart->params;
 
     /*
@@ -155,6 +154,14 @@ static void __init scif_uart_init_preirq(struct serial_port *port)
 
     /* Reset TX/RX FIFOs */
     scif_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
+}
+
+static void scif_uart_init_preirq(struct serial_port *port)
+{
+    struct scif_uart *uart = port->uart;
+    const struct port_params *params = uart->params;
+
+    scif_uart_disable(uart);
 
     /* Clear all errors and flags */
     scif_readw(uart, params->status_reg);
@@ -271,6 +278,31 @@ static void scif_uart_stop_tx(struct serial_port *port)
     scif_writew(uart, SCIF_SCSCR, scif_readw(uart, SCIF_SCSCR) & ~SCSCR_TIE);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
+static void scif_uart_suspend(struct serial_port *port)
+{
+    struct scif_uart *uart = port->uart;
+
+    scif_uart_stop_tx(port);
+    scif_uart_disable(uart);
+}
+
+static void scif_uart_resume(struct serial_port *port)
+{
+    struct scif_uart *uart = port->uart;
+    const struct port_params *params = uart->params;
+    uint16_t ctrl;
+
+    scif_uart_init_preirq(port);
+
+    /* Enable TX/RX and Error Interrupts  */
+    ctrl = scif_readw(uart, SCIF_SCSCR);
+    scif_writew(uart, SCIF_SCSCR, ctrl | params->irq_flags);
+}
+
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 static struct uart_driver __read_mostly scif_uart_driver = {
     .init_preirq  = scif_uart_init_preirq,
     .init_postirq = scif_uart_init_postirq,
@@ -281,6 +313,10 @@ static struct uart_driver __read_mostly scif_uart_driver = {
     .start_tx     = scif_uart_start_tx,
     .stop_tx      = scif_uart_stop_tx,
     .vuart_info   = scif_vuart_info,
+#ifdef CONFIG_SYSTEM_SUSPEND
+    .suspend      = scif_uart_suspend,
+    .resume       = scif_uart_resume,
+#endif
 };
 
 static const struct dt_device_match scif_uart_dt_match[] __initconst =
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 08:23:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 08:23:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.998996.1379661 (Exim 4.92)
	(envelope-from )
	id 1uKC4g-0006sS-Ob; Wed, 28 May 2025 08:23:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 998996.1379661; Wed, 28 May 2025 08:23: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 1uKC4g-0006sK-Lk; Wed, 28 May 2025 08:23:46 +0000
Received: by outflank-mailman (input) for mailman id 998996;
 Wed, 28 May 2025 08:23:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKC4f-0006sE-AY
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 08:23:45 +0000
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1112406a-3b9d-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 10:23:43 +0200 (CEST)
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 5358A21D18;
 Wed, 28 May 2025 08:23: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 CC0DA136E0;
 Wed, 28 May 2025 08:23: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 pmh/MA3INmgxVwAAD6G6ig
 (envelope-from ); Wed, 28 May 2025 08:23: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" 
X-Inumbo-ID: 1112406a-3b9d-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1748420622; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=IsYeUMzNWf+c4bLmoKUOHp5YpWvtC7v74oJ9jXBtnHM=;
	b=XQBmtfRd9f0BD+wpJmfsDg89bjVUFtWxyB8+k37xabISALbh+H9l1F8nnknU7GJur2Ir6r
	Kmlkb+phPU6vHmBUvrOzKLyPdCDiqZ5OX7tAinz1caXlC0ZC8KfcFq7XHirFV3R3ifXNaY
	lyqWj/ehrK8c6iCWlXr1VU2Q1LKJ/G4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1748420622;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=IsYeUMzNWf+c4bLmoKUOHp5YpWvtC7v74oJ9jXBtnHM=;
	b=dvJt6W9eqTR5Rd+KiuP01H+RwKo8jKPYSaFQcOmtWsSoyOZPFSM4P/6LbT/SZoQfSnPT4b
	VftOkM9jdhB63YBw==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1748420622; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=IsYeUMzNWf+c4bLmoKUOHp5YpWvtC7v74oJ9jXBtnHM=;
	b=XQBmtfRd9f0BD+wpJmfsDg89bjVUFtWxyB8+k37xabISALbh+H9l1F8nnknU7GJur2Ir6r
	Kmlkb+phPU6vHmBUvrOzKLyPdCDiqZ5OX7tAinz1caXlC0ZC8KfcFq7XHirFV3R3ifXNaY
	lyqWj/ehrK8c6iCWlXr1VU2Q1LKJ/G4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1748420622;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=IsYeUMzNWf+c4bLmoKUOHp5YpWvtC7v74oJ9jXBtnHM=;
	b=dvJt6W9eqTR5Rd+KiuP01H+RwKo8jKPYSaFQcOmtWsSoyOZPFSM4P/6LbT/SZoQfSnPT4b
	VftOkM9jdhB63YBw==
Message-ID: <1926848a-9334-4c15-a076-a93ef29c80d6@suse.de>
Date: Wed, 28 May 2025 10:23:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 00/25] drm/dumb-buffers: Fix and improve buffer-size
 calculation
To: simona@ffwll.ch, airlied@gmail.com, mripard@kernel.org,
 maarten.lankhorst@linux.intel.com, geert@linux-m68k.org,
 tomi.valkeinen@ideasonboard.com
Cc: dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org,
 freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
 imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
 nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
 spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org,
 linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org
References: <20250311155120.442633-1-tzimmermann@suse.de>
Content-Language: en-US
From: Thomas Zimmermann 
Autocrypt: addr=tzimmermann@suse.de; keydata=
 xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg
 XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0
 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc
 hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB
 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB
 AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb
 AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH
 AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo
 lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb
 U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf
 vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe
 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp
 j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb
 T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6
 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW
 GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv
 hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA
 EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T
 C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR
 yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A
 SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D
 Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ
 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
In-Reply-To: <20250311155120.442633-1-tzimmermann@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Flag: NO
X-Spam-Score: -2.80
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-0.996];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[ffwll.ch,gmail.com,kernel.org,linux.intel.com,linux-m68k.org,ideasonboard.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWELVE(0.00)[20];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
	RCVD_TLS_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid,imap1.dmz-prg2.suse.org:helo]
X-Spam-Level: 

ping

I'm still looking for more reviews; especially patches 1 and 2.

Best regards
Thomas

Am 11.03.25 um 16:47 schrieb Thomas Zimmermann:
> Dumb-buffer pitch and size is specified by width, height, bits-per-pixel
> plus various hardware-specific alignments. The calculation of these
> values is inconsistent and duplicated among drivers. The results for
> formats with bpp < 8 are sometimes incorrect.
>
> This series fixes this for most drivers. Default scanline pitch and
> buffer size are now calculated with the existing 4CC helpers. There is
> a new helper drm_mode_size_dumb() that calculates scanline pitch and
> buffer size according to driver requirements.
>
> The series fixes the common GEM implementations for DMA, SHMEM and
> VRAM. It further changes most implementations of dumb_create to use
> the new helper. A small number of drivers has more complicated
> calculations and will be updated by a later patches.
>
> v4:
> - improve UAPI documentation
> - document bpp special cases
> - use drm_warn_once()
> - add TODO lists
> - armada: fix pitch alignment
> v3:
> - document UAPI semantics
> - fall back to bpp-based allocation for unknown color modes
> - cleanups
> v2:
> - rewrite series
> - convert many individual drivers besides the shared GEM helpers
>
> Thomas Zimmermann (25):
>    drm/dumb-buffers: Sanitize output on errors
>    drm/dumb-buffers: Provide helper to set pitch and size
>    drm/gem-dma: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/gem-shmem: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/gem-vram: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/armada: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/exynos: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/gma500: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/hibmc: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/imx/ipuv3: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/loongson: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/mediatek: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/msm: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/nouveau: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/omapdrm: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/qxl: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/renesas/rcar-du: Compute dumb-buffer sizes with
>      drm_mode_size_dumb()
>    drm/renesas/rz-du: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/rockchip: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/tegra: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/virtio: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/vmwgfx: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/xe: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/xen: Compute dumb-buffer sizes with drm_mode_size_dumb()
>    drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
>
>   Documentation/gpu/todo.rst                    |  28 +++
>   drivers/gpu/drm/armada/armada_gem.c           |  16 +-
>   drivers/gpu/drm/drm_dumb_buffers.c            | 172 ++++++++++++++++--
>   drivers/gpu/drm/drm_gem_dma_helper.c          |   7 +-
>   drivers/gpu/drm/drm_gem_shmem_helper.c        |  16 +-
>   drivers/gpu/drm/drm_gem_vram_helper.c         |  89 +++------
>   drivers/gpu/drm/exynos/exynos_drm_gem.c       |   8 +-
>   drivers/gpu/drm/gma500/gem.c                  |  21 +--
>   .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |  25 ++-
>   drivers/gpu/drm/imx/ipuv3/imx-drm-core.c      |  29 ++-
>   drivers/gpu/drm/loongson/lsdc_gem.c           |  29 +--
>   drivers/gpu/drm/mediatek/mtk_gem.c            |  13 +-
>   drivers/gpu/drm/msm/msm_gem.c                 |  27 ++-
>   drivers/gpu/drm/nouveau/nouveau_display.c     |   7 +-
>   drivers/gpu/drm/omapdrm/omap_gem.c            |  15 +-
>   drivers/gpu/drm/qxl/qxl_dumb.c                |  17 +-
>   drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c |   7 +-
>   drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c  |   7 +-
>   drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  12 +-
>   drivers/gpu/drm/tegra/gem.c                   |   8 +-
>   drivers/gpu/drm/virtio/virtgpu_gem.c          |  11 +-
>   drivers/gpu/drm/vmwgfx/vmwgfx_surface.c       |  21 +--
>   drivers/gpu/drm/xe/xe_bo.c                    |   8 +-
>   drivers/gpu/drm/xen/xen_drm_front.c           |   7 +-
>   drivers/gpu/drm/xlnx/zynqmp_kms.c             |   7 +-
>   include/drm/drm_dumb_buffers.h                |  14 ++
>   include/drm/drm_gem_vram_helper.h             |   6 -
>   include/uapi/drm/drm_mode.h                   |  50 ++++-
>   28 files changed, 449 insertions(+), 228 deletions(-)
>   create mode 100644 include/drm/drm_dumb_buffers.h
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:12:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:12:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999014.1379675 (Exim 4.92)
	(envelope-from )
	id 1uKCpj-00059s-7M; Wed, 28 May 2025 09:12:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999014.1379675; Wed, 28 May 2025 09:12:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKCpj-00059l-4Y; Wed, 28 May 2025 09:12:23 +0000
Received: by outflank-mailman (input) for mailman id 999014;
 Wed, 28 May 2025 09:12:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCpi-00059a-E5
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:12:22 +0000
Received: from MRWPR03CU001.outbound.protection.outlook.com
 (mail-francesouthazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c207::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dbc35202-3ba3-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:12:20 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DB9PR03MB9709.eurprd03.prod.outlook.com
 (2603:10a6:10:459::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Wed, 28 May
 2025 09:12:16 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8769.022; Wed, 28 May 2025
 09:12: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" 
X-Inumbo-ID: dbc35202-3ba3-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PxP2o/vsJaoXujc6GPjsEzF/pbu3/mE2XMEpKizEAqx1r+7FJVQQh/vLXj5i6LQ9rk8f+kxBgJgDS1ND9gtscazLxS8W7z2zILdgnWlLfWUp8YpjwV+1jF6EE+aemSUsdpQFg5wTYzpvWE6171NbUoc2ppNlpDwCad6kMU9T0zFSjNNSlG3dy8XELWqq4pUBGAR9cB2WB7DYNrv1Ajk174zkudYmVw+5oXxiyMdzp63nldS2Dq4HgtrbZ5s2yfNO1tJElHoqxck4mVyl3EYyNHSDpSWG5vmJXM8tsFueTBhwb7rW3mjejE+IgArq53qPq+uf3i49a6nFNpahG2noQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6DIWgfuDUwCcIypaT33MplHEwx28ObYd4+JIfqhYtFs=;
 b=vwKNGRKPiX+r7+vzgZ5JdeWshOeJe549MHc8pQtzX4+LXMtgKZXqUznK3KMkADreiH8cVwoJK4RzDiopa7pKGKVvhbOiHWbLYjUBjP0IQwrC7xyP6LkfoYpHSz5DgWX2BlvWcWUE73c8WbfNJbFOJ1KqbotUqzmPowreWU6y0uB+WVJJtjBxytNKMZEBmy+QU/Sd+oySl5becki1aquPVK6ClVeBlZHOFDZjqyWjXcYg7yoDGtzuAkzpR+d9OuHKjgMpIr2C2+tB546N1eQb8z+EWuXcx6U2hCenBEHBXHshVtXwpeOpLuLcUJj1ZwMIT32Q0EVe7ytokIsiXAd+jQ==
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=6DIWgfuDUwCcIypaT33MplHEwx28ObYd4+JIfqhYtFs=;
 b=CXMAJu0IiBXUa3ASk+vuf5l7K6YVUTAYz4FnQhlJwoyWKn3z19UszbuIpFg9ZMPb5VrXQpmpev9NCxMBsLJKCPcw0WPlUwI6VTRkt/yLLyS5xVR+pkretED4ngTK1XIGUKEcUaZ4fRrUg8II8jRaKVHRAvGkakaucF4P17WC7N/Xj48mQUZMfD5ZR1EggflKXDhRD2UF/PLubVgCjsUqbJo3XVHeE3PT2hIABkYUyTw/I2Y8zs6R4DN7qMP9UbXMXhtk3+Y7eGROuUGPJPJX7RAkIdztBx9cmKuH6mLL+YwiT3iXvOZr57/jbe1IYT/yChVUSka9/v+kBeR0wbt0Yg==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Mykyta Poturai , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Jan Beulich ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Rahul Singh
	, Andrew Cooper , Anthony
 PERARD 
Subject: [PATCH v11 0/7] SMMU handling for PCIe Passthrough on ARM
Thread-Topic: [PATCH v11 0/7] SMMU handling for PCIe Passthrough on ARM
Thread-Index: AQHbz7CaDBc5HamPD0y+X5aTYJNRwQ==
Date: Wed, 28 May 2025 09:12:15 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|DB9PR03MB9709:EE_
x-ms-office365-filtering-correlation-id: cc817b02-be6e-4908-580d-08dd9dc7bd8f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|376014|1800799024|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?h9Zd+ajS0t+UZU9p+LtYgpuoL+7AVPNdwTfe3qTszyMtQSsB9Gh0Y99CK4?=
 =?iso-8859-1?Q?pXrsmLOrigBO7yjkq8qM5cBoxe5qYasMMKZOEQiRdJrKLrN0zmr/GX0NbA?=
 =?iso-8859-1?Q?4h8EKxW0n8Sd4f4bboL2MkhZBKePkrb184CHFjWGAvepWurl589DS1613i?=
 =?iso-8859-1?Q?Ev7P7YOu42qCeQMVH/PxtQ/iUiC/XmA1niBKlMhBIHnrpRIr+jG8ExwFNA?=
 =?iso-8859-1?Q?9JV1DcAVVflF6+XFag13DKOYR2iG4ARJ8NsoeRRunOmdhUnbSRyUBxHC01?=
 =?iso-8859-1?Q?b7AsvbHGvsIal0rcn6J57JzyqIysacDWTuwQi3/N35dZxzrboNT2vsuODj?=
 =?iso-8859-1?Q?ZIm5Dp/0AmaK69aO53IYw0VxBfSoa3pFilna4Dq6IvJ6VfPaQoHhAglMdB?=
 =?iso-8859-1?Q?LHyK5lyo8TTuOAa8Y859oLlbmbriqtC8heeMggp/5EpOTHDGlREuCuxz6u?=
 =?iso-8859-1?Q?LxCwQq7c68ZWUyqsCkotDIGlHZMLiRvqFSM4iDmhS1hhplTBjDJhaRAo6L?=
 =?iso-8859-1?Q?LeaTHHS5YH08v/OgfmDsIvp3kumoXkcZcY49ixOCQu/fLIbAUCduUsMjQm?=
 =?iso-8859-1?Q?5GpRKOp2qadgQp6WbSexT9kClT3/7Mp8ETrZXBGW3I6HlUGylZ+w7RTBsC?=
 =?iso-8859-1?Q?Nd+0GJEVYqu2tcsHw7Gav1Iw1JgMDzsui3IHTbew5iMl5VHbaIQb0J87BR?=
 =?iso-8859-1?Q?Tq+ymeh5SvEt94wf/EC3ayc4qBgBpsoMSm9/M104eOpX4Xwku5t7CVZpje?=
 =?iso-8859-1?Q?vHO1LRp3Hicjc7ftZn9lax89vIfXjaSm37hSB1vkUpEywHibF7xE9T8w2O?=
 =?iso-8859-1?Q?W354C32NOUONjhMliAtwweHfGaFbdzzoOIr18+qr1wdvYhx065tBu+UxXf?=
 =?iso-8859-1?Q?cYwHrlsilIUtOmjVgJCsAOtHaOhQwwHLvW1J3gGZ5Ztxfgu8CB+NTANtZv?=
 =?iso-8859-1?Q?aU2+CSid54iiYhURH27qzrx7J6y4166aGbk6rOA8rEDKIebcL+JqIrAepE?=
 =?iso-8859-1?Q?VSJGRjxTbakTBYOscdXGhOTBdBt3RJYRTvwAbIuSZ/RsfRnI9FKm/TwSUl?=
 =?iso-8859-1?Q?OpXiNlIbR3uYE6ydP5bAPy4EcBdsJbxX4lAxH3l3QXFRVuRXRPZVbNJtzg?=
 =?iso-8859-1?Q?TaEaxdeWqP7Bd2AsV/X4xeWi8f1z3fjzw28sis37eoABtxZFH945rD7tm+?=
 =?iso-8859-1?Q?YoXdwjIAnmPrC9oP5IrvdgkVtpSVMugKL5hyyyv78Mw8t3l+/WlB85lbIQ?=
 =?iso-8859-1?Q?myrYZbJSDhW67merWaJSY1WyEer/Mg7tOmIxB43YUK7uB21PvBWotEdA+h?=
 =?iso-8859-1?Q?RxCSh7Y6S1k+dkO3f1hwIOQrBE6c36bvZLK2pWAStTama6fk+IfDtnlApH?=
 =?iso-8859-1?Q?txoc11uFzikiPhWsFNxnI0vwCHkTr7YfC306jPieB9dp7PXCvzgSIGp6a8?=
 =?iso-8859-1?Q?ZOGA1u2BcMJbFQAVN0YZ62z0fYEjGxXnXPCT6yPZ6/PTwwnMUkMjAZ5fij?=
 =?iso-8859-1?Q?0=3D?=
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)(366016)(376014)(1800799024)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?1hugdUX/cdlftGCpZTTtEh5Q9LBkk9BkqdCUCOqYdlg1IEyjpx6C7/sdR2?=
 =?iso-8859-1?Q?9nLbjb7COQwG8CicUj0ClbTqiM+dkJAuEGsPSgNKbyEWnGUbQXUGpCPCcQ?=
 =?iso-8859-1?Q?YBWGY+jMKMaC1d+PU/meMOcuKavnqKL4K7Ne+psYE+UtgJAOg1Qiyxe0UZ?=
 =?iso-8859-1?Q?EQU+DsKgQYCHA9l3Vu5XX0Agg8d3/mE9SZKyqoVxOZ+aJJ+E0IpuYuv8e8?=
 =?iso-8859-1?Q?i3m+PFXajiMa22q9mtoyJVQWKtrjjtsM8i5YosjVuL/SjOg7GYpF8MxDj3?=
 =?iso-8859-1?Q?QSGz1FkMUDEC3WlAVaLjK8xt019CP+ulmj2T0Rinj/MONHOC7WsIAR11DU?=
 =?iso-8859-1?Q?XjQh+OzKqur5YQU+jvvDcjCXqCtngiKkXd6GjLSQ6KJeVYxdVgqgP3jI1q?=
 =?iso-8859-1?Q?6ei7kuVJjDp0mPsfM7i9WtOfj3qx0iHvSg9XlxhDqOti5UrO6cxT49D9TX?=
 =?iso-8859-1?Q?m26/vpD78vIxDTzW8t4CXoc6l6vRVQSyB81dE3tQSMkwwSkyDuBQJEaPGj?=
 =?iso-8859-1?Q?MjNeXrqIxMcpCqKH/ZljPeIKBpXmhkfjMhLCJ9CENtwEzGjzMXi7jQgupy?=
 =?iso-8859-1?Q?gc0or0Z3yDsAr/yYlTdZCs52okDDbgDnNfe3uLUcFJsJ0CdtpvBcr44ZzX?=
 =?iso-8859-1?Q?PeX6bIxMpDouwNB7r3gcI0mrmABgScFlfZ2S9X5rpEOFStcTruIPvN3IQs?=
 =?iso-8859-1?Q?u8tJuCu7XhDW/iEkqApBRWIBOOZdptwfzqyhfsehqqtDtJE4zIo+EYQKin?=
 =?iso-8859-1?Q?sJDx4fhoVapV+KiBgbcV8ekXw4zLPARZvr9uAJn3WqAd7Ah63s9sfci/na?=
 =?iso-8859-1?Q?Pu2bmwgsdz4tIuHMOrN3r10ZpcUyxsy2Fk3atZMi1n2TuOuf9ergWenYEu?=
 =?iso-8859-1?Q?CwTB47OOXu3NRGldyaaIQuURhV4rUmq0m0qG1gGixhvJJzddaY0ih2HrMI?=
 =?iso-8859-1?Q?g2dnguzL0ewLyIEGAKaDVAAqFmVYC+FUK1HS3mrdaaD710lP5QNqBJlijP?=
 =?iso-8859-1?Q?WCrlxhscsmZArLXLZKdAYB7L5N/F2UnD1etXxWRzT3Ulw7FFDuEeOF2LW2?=
 =?iso-8859-1?Q?eHvGk92Cm2X1FJfx0iA5WZdzGxT3tPH0lfFXPTfpi4GpPwKL0OHrA9yC7x?=
 =?iso-8859-1?Q?tOB7gkqOxGa0sH6RlzZXqa3XwIkZFoqSwTXYyVl7f8eomXLHag+O1CEU9p?=
 =?iso-8859-1?Q?4sNZgHe/b8+8WcFZMqIrkRv6S2GEeO02/MqHQcHj2HA0RYK9HID4dPUNX0?=
 =?iso-8859-1?Q?V2QiYf5swCT5/otmPJ44I1BgiSexR6OLekSwgQV3MDg7HG3vTDhf1qc9Ic?=
 =?iso-8859-1?Q?h+JOSz44Kv0Z6/1oqQAxDUXLpEtavSFxW1s9UiIAem9xNS1SOAZJgjiwXt?=
 =?iso-8859-1?Q?n8KRX0FUX+d5KWtJuciapfFHXpcHY9do8z1c2cmUgqpyHihgNr5QSryLvD?=
 =?iso-8859-1?Q?V82/QfeESvOU5XBvpg9HUCd80gJIIPC/xfXYwyQ07OVyLaEC7a1yOJsYAb?=
 =?iso-8859-1?Q?lg3CcqY8qktYgh19ucS1F1V2MpMFqBqYLPE6Hw2ocNy0Gu2qqRCNBqiilK?=
 =?iso-8859-1?Q?rFgCV4flt/dh4BvO+q/2L3OukpojONl7mezQdx/46Xf2IPmOFvKXltx68y?=
 =?iso-8859-1?Q?oo1XIvjcpRmA6H88juW6MjqjQfOZPgHAMEoAtffjcsV1aqspWHWe42lw?=
 =?iso-8859-1?Q?=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: cc817b02-be6e-4908-580d-08dd9dc7bd8f
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2025 09:12:16.0549
 (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: sDgkaZqKVehCuzv5hFVqO6Pn/F5WfYOW5jNGBaZtQ0vLBwyuM2Z6W0ndW9q2rHc8bFeZBKxHmubGAf8hA9i/yA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9709

This series introduces SMMU handling for PCIe passthrough on ARM. These pat=
ches
should be able to be upstreamed independently from the vPCI series [1]. See=
 [2]
for notes about test cases.

[1] https://lists.xenproject.org/archives/html/xen-devel/2023-10/msg00660.h=
tml
[2] https://lists.xenproject.org/archives/html/xen-devel/2023-06/msg01135.h=
tml

v10->v11:
* see individual patches

v9->v10:
* drop iommu/arm: Add iommu_dt_xlate()
* see individual patches

v8->v9:
* see individual patches

v7->v8:
* no changes

v6->v7:
* drop ("xen/arm: don't pass iommu properties to hwdom for iommu-map")

v5->v6:
* don't revert ("xen/arm: Add cmdline boot option "pci-passthrough =3D "")
* add ("xen/arm: enable dom0 to use PCI devices with pci-passthrough=3Dno")

v4->v5:
* drop ("xen/arm: Improve readability of check for registered devices")
* drop ("xen/arm: Move is_protected flag to struct device")
* add ("xen/arm: don't pass iommu properties to hwdom for iommu-map")
* add ("xen/arm: Fix mapping for PCI bridge mmio region")
* revert ("xen/arm: Add cmdline boot option "pci-passthrough =3D "=
")
* add ("xen/arm: Map ITS doorbell register to IOMMU page tables.")
* fix test case #1 with PCI device in dom0

v3->v4:
* split a change from ("xen/arm: Move is_protected flag to struct device") =
into
  a new separate patch
* see individual patches for further details

v2->v3:
* drop "pci/arm: Use iommu_add_dt_pci_device()"
* drop "RFC: pci/arm: don't do iommu call for phantom functions"
* move invocation of sideband ID mapping function to add_device()
  platform_ops/iommu_ops hook

Oleksandr Andrushchenko (1):
  xen/arm: smmuv2: Add PCI devices support for SMMUv2

Oleksandr Tyshchenko (1):
  iommu/arm: Introduce iommu_add_dt_pci_sideband_ids API

Rahul Singh (3):
  xen/arm: smmuv3: Add PCI devices support for SMMUv3
  xen/arm: Fix mapping for PCI bridge mmio region
  xen/arm: Map ITS doorbell register to IOMMU page tables

Stewart Hildebrand (2):
  iommu/arm: iommu_add_dt_pci_sideband_ids phantom handling
  xen/arm: enable dom0 to use PCI devices with pci-passthrough=3Dno

 xen/arch/arm/device.c                 |   2 +-
 xen/arch/arm/include/asm/iommu.h      |  15 ++
 xen/arch/arm/include/asm/pci.h        |   2 +
 xen/arch/arm/pci/pci.c                |  14 +-
 xen/arch/arm/vgic-v3-its.c            |  24 ++-
 xen/arch/x86/include/asm/pci.h        |   6 +
 xen/common/device-tree/device-tree.c  |  91 ++++++++++
 xen/drivers/passthrough/arm/iommu.c   |  13 ++
 xen/drivers/passthrough/arm/smmu-v3.c | 119 +++++++++++--
 xen/drivers/passthrough/arm/smmu.c    | 246 +++++++++++++++-----------
 xen/drivers/passthrough/device_tree.c |  49 +++++
 xen/drivers/pci/physdev.c             |   4 +-
 xen/include/xen/device_tree.h         |  23 +++
 xen/include/xen/iommu.h               |  21 ++-
 xen/include/xen/pci.h                 |   5 +
 15 files changed, 517 insertions(+), 117 deletions(-)

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 28 09:12:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:12:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999019.1379726 (Exim 4.92)
	(envelope-from )
	id 1uKCpo-0006JP-Pk; Wed, 28 May 2025 09:12:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999019.1379726; Wed, 28 May 2025 09:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKCpo-0006JI-M5; Wed, 28 May 2025 09:12:28 +0000
Received: by outflank-mailman (input) for mailman id 999019;
 Wed, 28 May 2025 09:12:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCpm-00059a-Ra
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:12:26 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dd7b1e04-3ba3-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:12:23 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DB9PR03MB9709.eurprd03.prod.outlook.com
 (2603:10a6:10:459::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Wed, 28 May
 2025 09:12:18 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8769.022; Wed, 28 May 2025
 09: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" 
X-Inumbo-ID: dd7b1e04-3ba3-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PnQSZ2BhXB6sybxX4u+Us22H3i2HXzd3rXhfYqL8guOHu+x00HnFvelLHrImIKyD5xhGWYlsIBqg3QKB+w8gOSVkXyZAsLqeRo7Yn3Id4gfePPgPJAIwo+Wh7iSglqIqMPfy+Lm1g7qJvZMcsjP477XaxzBRBrGfwjPFoCiiAdbDexf6DNSEVAqF+BDIhx6Z8U3ZMBLcJd9O1V0Pa/UQfazxIWTb/jhVqw9wzIx9SOcJuPaJsanmB9TKQCh5tqswkAheaxnCfDU6ba2iWGc7dioiU1ZNhrMDXHXow/KCyAsrMgIijoPiBa1hH1yTBzWsaVJzZpmLOt/+BvwbrfIP3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=eQZycESTBz9C6MbA7B3Hy4Wre4XE9BIA9Vmagsd9l+Y=;
 b=g43WCKwZbt6GPyLTYusOXdRzl055hnTXKYaYIs92mc09OmOCpV5/jPgFlMok7mCcu1LzaONnuaYKXNn4grjkpjXssUwmYbTIgHod07L0l2Za+1pJ5NbqbmhsM1eRoTBDu80eneC5wR9WLl29iErDG1KdMpH0oxg1RiWV9FNKt1dCiUe22GTF+1kJR815v3o9+zKDBfFQQKqCbCEsotDYkJ6uoVDgcMq4WHFirV5+YX62vUtY29Yp/shQPX/Fm25Ms81EXunv4IT/yfTbhcJVLRiSvdOYSoKwsoExF6sixw6amq2vaFANMeZnGICWulzp17MbtzD/y33SjKPibAygcw==
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=eQZycESTBz9C6MbA7B3Hy4Wre4XE9BIA9Vmagsd9l+Y=;
 b=j8vZBYqgWo3ZWDtxw1DLBgyvtZMpY0Fsxy7w4ivoiEP35HGm0GsgmNFy1OS9Q/wKc0m34BMQR0h/o0O32OsLzKmgD+CRke5D4TK9Bn8HmI8IRD1GcIfY3/OahDzZZqxCDu/0SoJJju5SYZMCWfWo/EQlfmGsO4kStS+6zQ4qdeDDEEBqNBV9QdIz7C3B5DI7F4FXATmk9qnxmLwvd5lEcztIsva0TYoB3K3U1umBq29XneT4c3nJCuo2pwdCSuIO2aBHx9dqR0/vD1Y9HIVGRtsrDakS7kihEEoopMI7rDSLY2VabvI6OLpc+jn1bPtDJnI/4X54fCimN9xkf1dCag==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Julien Grall
	, Rahul Singh , Stefano Stabellini
	, Bertrand Marquis , Michal
 Orzel , Volodymyr Babchuk ,
	Oleksandr Tyshchenko , Stewart Hildebrand
	, Mykyta Poturai 
Subject: [PATCH v11 3/7] xen/arm: smmuv2: Add PCI devices support for SMMUv2
Thread-Topic: [PATCH v11 3/7] xen/arm: smmuv2: Add PCI devices support for
 SMMUv2
Thread-Index: AQHbz7Cbv47KYV5h7kao9yNqlRrN2g==
Date: Wed, 28 May 2025 09:12:17 +0000
Message-ID:
 <3e52fa21f988a38e06511b629f54e2f5e7e2a332.1748422217.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: 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_|DB9PR03MB9709:EE_
x-ms-office365-filtering-correlation-id: bf2b71f1-b3dd-41d2-a5c8-08dd9dc7beac
x-ld-processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?UY2Q0t4Js9DfcdLj+24arf3XEMdkrLeI6ZVAMlrGW9WWPi+FV+OdJpEUje?=
 =?iso-8859-1?Q?YQYwZtVi+ACBB6BVY/0gTj8lyo1QBCZrzFIn4lsvTHXQG8upU2+P/XYwZ5?=
 =?iso-8859-1?Q?UURJNUZugXnFpT3MQ5l3pFg00EPoDN6tgLN40PoVPWfjQAgJhgzGm8Kp1/?=
 =?iso-8859-1?Q?88Ggy3rx6SD39kmIz4Yh9NYczD2xrQRPB53QBNHcJN2eYW/OK4KwQHT82Y?=
 =?iso-8859-1?Q?DzW3bYpx16DEMKOn0tuY1tv4LwNEcEvlIGXWiVuee+APYPckBtXMsCRfXA?=
 =?iso-8859-1?Q?lAl7wo66i/DN9MxA5bSMY2uL0eqUUfE4BVkxc1BbqK6xfg7JZKBjH2AVgf?=
 =?iso-8859-1?Q?NrmAbRfN9gSn3msc/6KRF8Xm+0zIL6tgyf69stkYosjP4sBMXduVx4VIx0?=
 =?iso-8859-1?Q?5BagueotGnhPzEjbMC6iS/148QbWIJM/WEc1SoviX/gxbpDT4HXfpCkpye?=
 =?iso-8859-1?Q?KDJh8XDckFkvXnSUTpKb4kKVNqUvM8ek+6hmlbF5Bd8mbB2dsPCTBNWliF?=
 =?iso-8859-1?Q?c9ye7vPf8BuEb4oxCQ82A1OSNG3n1pl9zHf/BHMTsu/+ns2Hqvl7S0OU9A?=
 =?iso-8859-1?Q?Y/d1nWPPAcOW1K93JyC4GbXAoNGyfRbJY10Hbiq9jCWfbs6gavs/R9J5YS?=
 =?iso-8859-1?Q?0BG82Vf15iJZD+2GSZZU5c3cEJ7cX9wl/XCdpg5TUYSspUhjUdxzSpoiol?=
 =?iso-8859-1?Q?zmOxdVE6Mfc2jdGUJlBDJlB4HqjMbaJ+B8DxvYKJYoCHyRHKP1y/veE4FQ?=
 =?iso-8859-1?Q?O79sbfFEiBLTuyp3Via4OO0pN6dso5/cPMun4B+ehsVijGlkalZesPCaJs?=
 =?iso-8859-1?Q?cZII4Pwz72e8rwHin96mr0UvmtkpOaPcifAbNg8E3awssCX8/kS1rHHH8A?=
 =?iso-8859-1?Q?ZRrUHM+H9hMRuQOuGhi6dv2MbvGrs1uZt9XZRlEhu67zn0yx5rIy06nxvl?=
 =?iso-8859-1?Q?1ChwVfDbbmnJ2UauIU4iZd++QiHnU7RV9j3wLVlNLdZHYVSe/eLZrTbLb4?=
 =?iso-8859-1?Q?Ja8g6gB4dJmuuuuiNBYG4GBXEKe1oie4RJalvEMCXphW0VCPVQXP/72APb?=
 =?iso-8859-1?Q?60masnwhLzGJVcPN3vlkPo8snK1Xe/KzkD6CPS3Z4u7VW9q8vwfJNIvzEx?=
 =?iso-8859-1?Q?uh43th8GcEGwI09rHkOv08wH+FXQM6vG5CWVdZZaBO5+9Gw5b3H1orN/Kh?=
 =?iso-8859-1?Q?d4SXuKMZ/oQpmxxlGujfwM741h07Zy0jPw2TKjnJah3KQVba0EDwK0LK4w?=
 =?iso-8859-1?Q?sXTnIXpzxGH/eAcMV0IF8ekVP0INGnTGzcOQoye1/ec4Qg2Jjp0FWE68f+?=
 =?iso-8859-1?Q?aNNabN4z+4UmZtwQYx7qvCmRLn8PTAk4Pqqo/nyXTANdCaQOTbYtkWrbwh?=
 =?iso-8859-1?Q?CowzvzupWl1tua2AqHdRZy+WcbjXmZ/dssJLF6NEAUNE4liNcO70T9LX0X?=
 =?iso-8859-1?Q?lV9pQ2/3VJO62lQNk5WQckhDzUsKczB9JG6pEevWGzxFV8Td+1PsvfWK7S?=
 =?iso-8859-1?Q?k=3D?=
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)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?pvGuMHazxQH2rMHVrDKrHvII2zCtrkiqthCcDJB6MawuP0A/QRl0Tx1kqa?=
 =?iso-8859-1?Q?62S1dF7TJkutt+R/RmdZfGdBqVfkodD3uUgwgyLtFLbeU7Y8+2g3r7fAt1?=
 =?iso-8859-1?Q?hNE0magTHr6QjcHhQL/D78xXKxFpalXBnyKHXKMANDqnorvQgXXQW8WFj4?=
 =?iso-8859-1?Q?2OF1LulAlX39Ksb8RhrCRHnswbLW5BLhFRrTH/mYpzfDXSszFnTRXj1har?=
 =?iso-8859-1?Q?RBCyEFgRvwHKdFYXAGeGdum319m8Y3Vhen+ECaYUKABdaFgdAWSAEnpKnX?=
 =?iso-8859-1?Q?Xe1fVoq9IENJEetgvzhvWhoVmTssCtL1OTDveJPhzMiM23ZyIG7igSrXLM?=
 =?iso-8859-1?Q?n/KsxQPecmWDuVjnp5eoq13fNzILDvqiat3JdxOpsEPupADQSzvZ9kBuss?=
 =?iso-8859-1?Q?UzRNH1szaD0v5dYDG6YkqUIzQkOM4SHA9EmyZNkM45RFp9xaugOUQK6mBc?=
 =?iso-8859-1?Q?aEkwhgv4eROZTTTBGl+1So5JgUT0Ip7vQSmSvk4o4XteF6zcmTlUBQhgRr?=
 =?iso-8859-1?Q?YkBxo/MRrJ55+ggNL1/K9BhAFanPLALE8Z9HKJEOnV61I3qGjGfWPGmdXn?=
 =?iso-8859-1?Q?VvU8MvDWNFEqNX6P0NEZeAkgOSIHjQemJjGh1gNezKhxiv+QwHAMkUTcRz?=
 =?iso-8859-1?Q?ehM4j6XhW5zrDOGdi5V9Z3zIX6psrc2IvbrcQMSL2zbaZTXwPmQG4G57+9?=
 =?iso-8859-1?Q?h0o5Oz7u+j5aLL6ZFSbH8PPSBSj8G9UmMkqSC9W258rpo+V+is2b8Zvhen?=
 =?iso-8859-1?Q?BCs+JOQF9v0PQ8PARufdr1nYSOotaP0DpkFpsiHd0eNWv8e6MH1wlSsvuj?=
 =?iso-8859-1?Q?rTHNCDPL4C0UqM5lTW6zqmUPPWQu3afxILMXnvMVY+rkTs3WMipXUVnVcU?=
 =?iso-8859-1?Q?32L/cbwUMnVW/Ik83Iixfcj+IIrAqcrQaYJuZAM3UF1LIeSpRBvRWi0c6k?=
 =?iso-8859-1?Q?12yN9xSaCQp5rtKKOfY6y55kcWAyjDOmauawP73SlqMM4Qhe1UeQ4xr1BK?=
 =?iso-8859-1?Q?Lh1Gv5vAzXzmSFd2xa3DEZjKA7yhf/q20oCD0BYyEnDHzUu8HQvZWlctkZ?=
 =?iso-8859-1?Q?bUFxstX6QD4dDPH8aTB6WyjATWY1eiXYh5ESIfOU7ycytgD4gEC8qd/9EU?=
 =?iso-8859-1?Q?s2X3yQjjdyZUGCjOzJR778P5fFp2q+PBUGAlX/NJsPCtQayOBKngCXZT5M?=
 =?iso-8859-1?Q?crGrkgm1o6KUmHpMVlGtjDFNzfq815xe8AXyoNOtgUTDF6L6/IitdAh0HJ?=
 =?iso-8859-1?Q?gtHNQ9IS6FZuC5AVeWbdGGw8s65NP1VDwpyxuyyt2hLSyhVwgf8N7s8276?=
 =?iso-8859-1?Q?tSXI36+R3ODky4mUpc33n9ZvAVGHDOUOEYqeJAbIwnL6zQgKtQQy4LUnhx?=
 =?iso-8859-1?Q?nNi7YVavZutKUvCjfYgomWxCNkukmU5ZjYNfTQLLnMlbYhA5tBCt8rdOP5?=
 =?iso-8859-1?Q?jZZ0pmdUTtjo793z4eclAOqY3Pk3CIjy2Bb7FaUCP5D0NLMhcFbiIy+31v?=
 =?iso-8859-1?Q?Qvb3JFaS/HvxmjiNYVrXy+bpUyVU7+izL+Fg7aHT3DclsM8VnFvUBb4BMU?=
 =?iso-8859-1?Q?mL1S5uNTTpw9VMvvnoqteWyuITvoBWkorIXb/OuanPnnLx7XOTqP5O0K+k?=
 =?iso-8859-1?Q?M3rXLbemosqeyMXoxUdSL1EEeI7f6ZjeeaoLZAU4lNXqESRQSB7ZsbVw?=
 =?iso-8859-1?Q?=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: bf2b71f1-b3dd-41d2-a5c8-08dd9dc7beac
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2025 09:12:17.2426
 (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: iY2pYXdSyfxFZcLoqGs4mc1Pdy+oDA/xGpuCcvWWjAxuR6EImbn1eAgm2IrwIfGAiW4XoNNAyVG16CSvVyuo0g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9709

From: Oleksandr Andrushchenko 

Implement support for PCI devices in the SMMU driver. Make arm_smmu_master
structure to hold a pointer to the device to allow it to hold PCI devices.
Trigger iommu-map parsing when new PCI device is added. Add checks to
assign/deassign functions to ensure PCI devices are handled correctly.
Implement basic quarantining.

All pci devices are automatically assigned to hardware domain if it exists
to ensure it can probe them.

TODO:
Implement scratch page quarantining support.

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Stewart Hildebrand 
Signed-off-by: Mykyta Poturai 
---
v10-v11:
* remove unused code
* remove unnecessary blocks

v9->v10:
* remove unused code
* return on error in arm_smmu_dt_add_device_generic

v8->v9:
* no change

v7->v8:
* no change

v6->v7:
* use d->pci_lock in arm_smmu_assign_dev()
* remove !is_hardware_domain and pdev->domain =3D=3D d checks in assign to
  support future dom0less use case when dom0 is using vPCI
* remove stale todo in dev_get_dev_node
* don't print ""
* remove redundant dt_device_is_protected check
* remove assign/deassing prints
* change assign logic to remove reassign reimplementation
* check if pdev->domain exists before assigning to it
* explain pdev->devfn check
* make reassign check stricter and update comment

v5->v6:
* check for hardware_domain =3D=3D NULL (dom0less test case)
* locking: assign pdev->domain before list_add()

v4->v5:
* assign device to pdev->domain (usually dom0) by default in add_device() h=
ook
* deassign from hwdom
* rebase on top of ("dynamic node programming using overlay dtbo") series
* remove TODO in comment about device prints
* add TODO regarding locking
* fixup after dropping ("xen/arm: Move is_protected flag to struct device")

v3->v4:
* add new device_is_protected check in add_device hook to match SMMUv3 and
  IPMMU-VMSA drivers

v2->v3:
* invoke iommu_add_pci_sideband_ids() from add_device hook

v1->v2:
* ignore add_device/assign_device/reassign_device calls for phantom functio=
ns
  (i.e. devfn !=3D pdev->devfn)

downstream->v1:
* wrap unused function in #ifdef 0
* remove the remove_device() stub since it was submitted separately to the =
list
  [XEN][PATCH v6 12/19] xen/smmu: Add remove_device callback for smmu_iommu=
 ops
  https://lists.xenproject.org/archives/html/xen-devel/2023-05/msg00204.htm=
l
* arm_smmu_(de)assign_dev: return error instead of crashing system
* update condition in arm_smmu_reassign_dev
* style fixup
* add && !is_hardware_domain(d) into condition in arm_smmu_assign_dev()

(cherry picked from commit 0c11a7f65f044c26d87d1e27ac6283ef1f9cfb7a from
 the downstream branch spider-master from
 https://github.com/xen-troops/xen.git)
---
 xen/drivers/passthrough/arm/smmu.c | 246 +++++++++++++++++------------
 1 file changed, 146 insertions(+), 100 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/a=
rm/smmu.c
index 0f8d47dc98..307c2f6837 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -120,11 +120,21 @@ enum irqreturn {
=20
 typedef enum irqreturn irqreturn_t;
=20
-/* Device logger functions
- * TODO: Handle PCI
- */
-#define dev_print(dev, lvl, fmt, ...)						\
-	 printk(lvl "smmu: %s: " fmt, dt_node_full_name(dev_to_dt(dev)), ## __VA_=
ARGS__)
+/* Device logger functions */
+#ifndef CONFIG_HAS_PCI
+#define dev_print(dev, lvl, fmt, ...)    \
+    printk(lvl "smmu: %s: " fmt, dev_name(dev), ## __VA_ARGS__)
+#else
+#define dev_print(dev, lvl, fmt, ...) ({                                \
+    if ( !dev_is_pci((dev)) )                                           \
+        printk(lvl "smmu: %s: " fmt, dev_name((dev)), ## __VA_ARGS__);  \
+    else                                                                \
+    {                                                                   \
+        struct pci_dev *pdev =3D dev_to_pci((dev));                       =
\
+        printk(lvl "smmu: %pp: " fmt, &pdev->sbdf, ## __VA_ARGS__);     \
+    }                                                                   \
+})
+#endif
=20
 #define dev_dbg(dev, fmt, ...) dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_A=
RGS__)
 #define dev_notice(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## __VA=
_ARGS__)
@@ -172,20 +182,6 @@ static void __iomem *devm_ioremap_resource(struct devi=
ce *dev,
 #define IOMMU_FAULT_READ	0
 #define IOMMU_FAULT_WRITE	1
=20
-/*
- * Xen: PCI functions
- * TODO: It should be implemented when PCI will be supported
- */
-#define to_pci_dev(dev)	(NULL)
-static inline int pci_for_each_dma_alias(struct pci_dev *pdev,
-					 int (*fn) (struct pci_dev *pdev,
-						    u16 alias, void *data),
-					 void *data)
-{
-	BUG();
-	return 0;
-}
-
 /* Xen: misc */
 #define PHYS_MASK_SHIFT		PADDR_BITS
=20
@@ -619,7 +615,7 @@ struct arm_smmu_master_cfg {
 	for (i =3D 0; idx =3D (cfg)->smendx[i], (i) < (num); ++(i))
=20
 struct arm_smmu_master {
-	struct device_node		*of_node;
+	struct device			*dev;
 	struct rb_node			node;
 	struct arm_smmu_master_cfg	cfg;
 };
@@ -711,7 +707,7 @@ arm_smmu_get_fwspec(struct arm_smmu_master_cfg *cfg)
 {
 	struct arm_smmu_master *master =3D container_of(cfg,
 			                                      struct arm_smmu_master, cfg);
-	return dev_iommu_fwspec_get(&master->of_node->dev);
+	return dev_iommu_fwspec_get(master->dev);
 }
=20
 static void parse_driver_options(struct arm_smmu_device *smmu)
@@ -730,21 +726,11 @@ static void parse_driver_options(struct arm_smmu_devi=
ce *smmu)
=20
 static struct device_node *dev_get_dev_node(struct device *dev)
 {
-#if 0 /* Xen: TODO: Add support for PCI */
-	if (dev_is_pci(dev)) {
-		struct pci_bus *bus =3D to_pci_dev(dev)->bus;
-
-		while (!pci_is_root_bus(bus))
-			bus =3D bus->parent;
-		return bus->bridge->parent->of_node;
-	}
-#endif
-
 	return dev->of_node;
 }
=20
 static struct arm_smmu_master *find_smmu_master(struct arm_smmu_device *sm=
mu,
-						struct device_node *dev_node)
+						struct device *dev)
 {
 	struct rb_node *node =3D smmu->masters.rb_node;
=20
@@ -753,9 +739,9 @@ static struct arm_smmu_master *find_smmu_master(struct =
arm_smmu_device *smmu,
=20
 		master =3D container_of(node, struct arm_smmu_master, node);
=20
-		if (dev_node < master->of_node)
+		if (dev < master->dev)
 			node =3D node->rb_left;
-		else if (dev_node > master->of_node)
+		else if (dev > master->dev)
 			node =3D node->rb_right;
 		else
 			return master;
@@ -790,9 +776,9 @@ static int insert_smmu_master(struct arm_smmu_device *s=
mmu,
 			=3D container_of(*new, struct arm_smmu_master, node);
=20
 		parent =3D *new;
-		if (master->of_node < this->of_node)
+		if (master->dev < this->dev)
 			new =3D &((*new)->rb_left);
-		else if (master->of_node > this->of_node)
+		else if (master->dev > this->dev)
 			new =3D &((*new)->rb_right);
 		else
 			return -EEXIST;
@@ -824,28 +810,30 @@ static int arm_smmu_dt_add_device_legacy(struct arm_s=
mmu_device *smmu,
 	struct arm_smmu_master *master;
 	struct device_node *dev_node =3D dev_get_dev_node(dev);
=20
-	master =3D find_smmu_master(smmu, dev_node);
+	master =3D find_smmu_master(smmu, dev);
 	if (master) {
 		dev_err(dev,
-			"rejecting multiple registrations for master device %s\n",
-			dev_node->name);
+			"rejecting multiple registrations for master device\n");
 		return -EBUSY;
 	}
=20
 	master =3D devm_kzalloc(dev, sizeof(*master), GFP_KERNEL);
 	if (!master)
 		return -ENOMEM;
-	master->of_node =3D dev_node;
+	master->dev =3D dev;
=20
-	/* Xen: Let Xen know that the device is protected by an SMMU */
-	dt_device_set_protected(dev_node);
+	if ( !dev_is_pci(dev) )
+	{
+		/* Xen: Let Xen know that the device is protected by an SMMU */
+		dt_device_set_protected(dev_node);
+	}
=20
 	for (i =3D 0; i < fwspec->num_ids; ++i) {
 		if (!(smmu->features & ARM_SMMU_FEAT_STREAM_MATCH) &&
 		     (fwspec->ids[i] >=3D smmu->num_mapping_groups)) {
 			dev_err(dev,
-				"stream ID for master device %s greater than maximum allowed (%d)\n",
-				dev_node->name, smmu->num_mapping_groups);
+				"SMMU stream ID %d is greater than maximum allowed (%d)\n",
+				fwspec->ids[i], smmu->num_mapping_groups);
 			return -ERANGE;
 		}
 		master->cfg.smendx[i] =3D INVALID_SMENDX;
@@ -860,7 +848,7 @@ static int arm_smmu_dt_remove_device_legacy(struct arm_=
smmu_device *smmu,
 	struct device_node *dev_node =3D dev_get_dev_node(dev);
 	int ret;
=20
-	master =3D find_smmu_master(smmu, dev_node);
+	master =3D find_smmu_master(smmu, dev);
 	if (master =3D=3D NULL) {
 		dev_err(dev,
 			"No registrations found for master device %s\n",
@@ -872,8 +860,9 @@ static int arm_smmu_dt_remove_device_legacy(struct arm_=
smmu_device *smmu,
 	if (ret)
 		return ret;
=20
-	/* Protected by dt_host_lock and dtdevs_lock as caller holds these locks.=
 */
-	dev_node->is_protected =3D false;
+	if ( !dev_is_pci(dev) )
+		/* Protected by dt_host_lock and dtdevs_lock as caller holds these locks=
. */
+		dev_node->is_protected =3D false;
=20
 	kfree(master);
 	return 0;
@@ -902,6 +891,12 @@ static int register_smmu_master(struct arm_smmu_device=
 *smmu,
 					     fwspec);
 }
=20
+/* Forward declaration */
+static int arm_smmu_assign_dev(struct domain *d, u8 devfn,
+			       struct device *dev, u32 flag);
+static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn,
+				 struct device *dev);
+
 /*
  * The driver which supports generic IOMMU DT bindings must have this
  * callback implemented.
@@ -926,6 +921,25 @@ static int arm_smmu_dt_add_device_generic(u8 devfn, st=
ruct device *dev)
 {
 	struct arm_smmu_device *smmu;
 	struct iommu_fwspec *fwspec;
+	int ret;
+
+#ifdef CONFIG_HAS_PCI
+	if ( dev_is_pci(dev) )
+	{
+		struct pci_dev *pdev =3D dev_to_pci(dev);
+		int ret;
+
+		/* Ignore calls for phantom functions */
+		if ( devfn !=3D pdev->devfn )
+			return 0;
+
+		ret =3D iommu_add_pci_sideband_ids(pdev);
+		if ( ret < 0 ) {
+			iommu_fwspec_free(dev);
+			return ret;
+		}
+	}
+#endif
=20
 	fwspec =3D dev_iommu_fwspec_get(dev);
 	if (fwspec =3D=3D NULL)
@@ -935,7 +949,25 @@ static int arm_smmu_dt_add_device_generic(u8 devfn, st=
ruct device *dev)
 	if (smmu =3D=3D NULL)
 		return -ENXIO;
=20
-	return arm_smmu_dt_add_device_legacy(smmu, dev, fwspec);
+	ret =3D arm_smmu_dt_add_device_legacy(smmu, dev, fwspec);
+	if ( ret )
+		return ret;
+
+#ifdef CONFIG_HAS_PCI
+	if ( dev_is_pci(dev) )
+	{
+		struct pci_dev *pdev =3D dev_to_pci(dev);
+
+		/*
+		 * During PHYSDEVOP_pci_device_add, Xen does not assign the
+		 * device, so we must do it here.
+		 */
+		if ( pdev->domain )
+			ret =3D arm_smmu_assign_dev(pdev->domain, devfn, dev, 0);
+	}
+#endif
+
+	return ret;
 }
=20
 static int arm_smmu_dt_xlate_generic(struct device *dev,
@@ -958,11 +990,10 @@ static struct arm_smmu_device *find_smmu_for_device(s=
truct device *dev)
 {
 	struct arm_smmu_device *smmu;
 	struct arm_smmu_master *master =3D NULL;
-	struct device_node *dev_node =3D dev_get_dev_node(dev);
=20
 	spin_lock(&arm_smmu_devices_lock);
 	list_for_each_entry(smmu, &arm_smmu_devices, list) {
-		master =3D find_smmu_master(smmu, dev_node);
+		master =3D find_smmu_master(smmu, dev);
 		if (master)
 			break;
 	}
@@ -2054,65 +2085,26 @@ static bool arm_smmu_capable(enum iommu_cap cap)
 }
 #endif
=20
-static int __arm_smmu_get_pci_sid(struct pci_dev *pdev, u16 alias, void *d=
ata)
-{
-	*((u16 *)data) =3D alias;
-	return 0; /* Continue walking */
-}
-
-static void __arm_smmu_release_pci_iommudata(void *data)
-{
-	kfree(data);
-}
-
 static int arm_smmu_add_device(struct device *dev)
 {
 	struct arm_smmu_device *smmu;
+	struct arm_smmu_master *master;
 	struct arm_smmu_master_cfg *cfg;
 	struct iommu_group *group;
 	void (*releasefn)(void *data) =3D NULL;
-	int ret;
=20
 	smmu =3D find_smmu_for_device(dev);
 	if (!smmu)
 		return -ENODEV;
=20
-	if (dev_is_pci(dev)) {
-		struct pci_dev *pdev =3D to_pci_dev(dev);
-		struct iommu_fwspec *fwspec;
-
-		cfg =3D kzalloc(sizeof(*cfg), GFP_KERNEL);
-		if (!cfg) {
-			return -ENOMEM;
-		}
-
-		ret =3D iommu_fwspec_init(dev, smmu->dev);
-		if (ret) {
-			kfree(cfg);
-			return ret;
-		}
-		fwspec =3D dev_iommu_fwspec_get(dev);
-
-		/*
-		 * Assume Stream ID =3D=3D Requester ID for now.
-		 * We need a way to describe the ID mappings in FDT.
-		 */
-		pci_for_each_dma_alias(pdev, __arm_smmu_get_pci_sid,
-				       &fwspec->ids[0]);
-		releasefn =3D __arm_smmu_release_pci_iommudata;
-		cfg->smmu =3D smmu;
-	} else {
-		struct arm_smmu_master *master;
-
-		master =3D find_smmu_master(smmu, dev->of_node);
-		if (!master) {
-			return -ENODEV;
-		}
-
-		cfg =3D &master->cfg;
-		cfg->smmu =3D smmu;
+	master =3D find_smmu_master(smmu, dev);
+	if (!master) {
+		return -ENODEV;
 	}
=20
+	cfg =3D &master->cfg;
+	cfg->smmu =3D smmu;
+
 	group =3D iommu_group_alloc();
 	if (IS_ERR(group)) {
 		dev_err(dev, "Failed to allocate IOMMU group\n");
@@ -2772,6 +2764,42 @@ static int arm_smmu_assign_dev(struct domain *d, u8 =
devfn,
 			return -ENOMEM;
 	}
=20
+#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());
+
+		write_lock(&pdev->domain->pci_lock);
+		list_del(&pdev->domain_list);
+		write_unlock(&pdev->domain->pci_lock);
+
+		pdev->domain =3D d;
+
+		write_lock(&d->pci_lock);
+		list_add(&pdev->domain_list, &d->pdev_list);
+		write_unlock(&d->pci_lock);
+
+		/* dom_io is used as a sentinel for quarantined devices */
+		if ( d =3D=3D dom_io )
+		{
+			struct iommu_domain *domain =3D dev_iommu_domain(dev);
+			if ( !iommu_quarantine )
+				return 0;
+
+			if ( domain && domain->priv )
+				arm_smmu_deassign_dev(domain->priv->cfg.domain, devfn, dev);
+
+			return 0;
+		}
+	}
+#endif
+
 	if (!dev_iommu_group(dev)) {
 		ret =3D arm_smmu_add_device(dev);
 		if (ret)
@@ -2821,11 +2849,27 @@ out:
 	return ret;
 }
=20
-static int arm_smmu_deassign_dev(struct domain *d, struct device *dev)
+static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn,
+				 struct device *dev)
 {
 	struct iommu_domain *domain =3D dev_iommu_domain(dev);
 	struct arm_smmu_xen_domain *xen_domain;
=20
+#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;
+
+		/* dom_io is used as a sentinel for quarantined devices */
+		if ( d =3D=3D dom_io )
+			return 0;
+	}
+#endif
+
 	xen_domain =3D dom_iommu(d)->arch.priv;
=20
 	if (!domain || domain->priv->cfg.domain !=3D d) {
@@ -2852,14 +2896,16 @@ static int arm_smmu_reassign_dev(struct domain *s, =
struct domain *t,
 {
 	int ret =3D 0;
=20
-	/* Don't allow remapping on other domain than hwdom */
-	if ( t && !is_hardware_domain(t) )
+	/* Don't allow remapping on other domain than hwdom
+	 * or dom_io for PCI devices
+	 */
+	if ( t && !is_hardware_domain(t) && (t !=3D dom_io || !dev_is_pci(dev)) )
 		return -EPERM;
=20
 	if (t =3D=3D s)
 		return 0;
=20
-	ret =3D arm_smmu_deassign_dev(s, dev);
+	ret =3D arm_smmu_deassign_dev(s, devfn, dev);
 	if (ret)
 		return ret;
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 28 09:12:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:12:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999018.1379711 (Exim 4.92)
	(envelope-from )
	id 1uKCpn-0005ss-C9; Wed, 28 May 2025 09:12:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999018.1379711; Wed, 28 May 2025 09:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKCpn-0005rF-61; Wed, 28 May 2025 09:12:27 +0000
Received: by outflank-mailman (input) for mailman id 999018;
 Wed, 28 May 2025 09:12:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCpl-00059a-RK
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:12:25 +0000
Received: from MRWPR03CU001.outbound.protection.outlook.com
 (mail-francesouthazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c207::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ddb0393d-3ba3-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:12:23 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DB9PR03MB9709.eurprd03.prod.outlook.com
 (2603:10a6:10:459::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Wed, 28 May
 2025 09:12:19 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8769.022; Wed, 28 May 2025
 09: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" 
X-Inumbo-ID: ddb0393d-3ba3-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NuuMcL5oTp20L3Tx+iYrtKrxciMhRKn911u9Nzn1tarSndhiVPh0CALi+4eEoQohwYV9bpOUt79ENj7zEhZrQLWTsV/VblJtvFM6UOP7ETEq/aFwFtkbDzZ6vsp5JxGBOcX9Id3adDbBkgUN35qd3Mo4E0GdrTkgqJ3kI+8bEMSCBX9RSIW1jUFqc6AcJX8ucOqAUlBdXwnrmDqxawyaCqjErUKEQodz6XS8n4KUDFv3Baw1U0p2wVS5HL1koRRWOq5bps1SpQslYKCphpIE6KfY+9JsuGsIO3gtgsDCMDSoRcuBGzK93dzhnPn+UyRfK0vlgLMloIB/pi473aGuGQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hsN3+Hc0Zyjf3eo6bzRyCdA+s2D30emzWYJHPOHFSwI=;
 b=he7L4hfSmLEkR16Ot248b5m0J1bUruDttaKO+ulToQkOmmFYiESswriafk5MYrdsBM8+MkFPldE0vzxSQ/w5uHs9G5V5VDpSYu9tV99A8cLvjc38VXN3vhhii1Nzu3218axHeYGMyxu2fI+H9QfJubDrHRxxrKFVmYKhpQCDSIYvNTCdHiycEcI3pz6NijiDQ/aJdDAgfbLWjwLK4sePquOpPkOqdicIvlsti+ayonmf/ftdZjHrtiku0lGbjpfSOli59eGYUEfw3TV//k2rfi6lpjqF1nS/y0/IW/OgkxKX8+NEPJqhZHKoj7v+b0WAE7TSO4eqWAcm1FiRRRT1RQ==
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=hsN3+Hc0Zyjf3eo6bzRyCdA+s2D30emzWYJHPOHFSwI=;
 b=b8x3KFgFVjI+1hSK+ZXJ8q5aSzp7e45Yrlxm7Hxy81aplW7hXK3eSyhOsR5uge4HinuYEAFm5T0D3kiAl2YSL+7uI5+fP0GL17jhxWjyTg0YxiYAYJ8XOpjPomBLclWSZpuqc7axLteBgagd1iDW4emhhr3xkTsrU9XNndX+XjWMW7nH/EyjrIu1NkvkV4D6w3pP884nK6gc9BgOBSTga46n3c2UXF8hCNfqs6uayYvzOJWapmIZL3MZ/IFzrEdrjff4kd7IcS82cvkKayZyNFV0/kaCHqAMRti7J3+opi7EIT8RMc0hzWnDbUDXz8nbw+fd0d/Wn0elqNpL2gMeRg==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Andrew Cooper
	, Anthony PERARD , Jan
 Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Mykyta Poturai 
Subject: [PATCH v11 6/7] xen/arm: enable dom0 to use PCI devices with
 pci-passthrough=no
Thread-Topic: [PATCH v11 6/7] xen/arm: enable dom0 to use PCI devices with
 pci-passthrough=no
Thread-Index: AQHbz7CcYslTkZ61QEOdjKGC2c9Bkg==
Date: Wed, 28 May 2025 09:12:18 +0000
Message-ID:
 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|DB9PR03MB9709:EE_
x-ms-office365-filtering-correlation-id: 4d743920-f541-4f9a-b257-08dd9dc7bf40
x-ld-processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|376014|1800799024|7416014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?daVNnpDbrn098FVLaweoZxClQHK6PkTXcNAV01FwSVAteT9/+znZ6IKUEX?=
 =?iso-8859-1?Q?6Kce/xwZPZm3ywxoyzf6dbCz5hbql2rI9IXplbKjHxG5eyfaf/oOYgo1c9?=
 =?iso-8859-1?Q?809t9GcVcaCVW1t9nwAsvTERnbx/6T2lcBISk4/m5vxXu6Mouj7mhdcxH9?=
 =?iso-8859-1?Q?YvWEo0oGsZjp3EJc2fl/D/+JrgIf/VxGiytP5p0nClx4oRsQJbTyXtZlbS?=
 =?iso-8859-1?Q?mUfJt8MkRwPBejkaQijngBAmzPUwtFudschGF0m7Rp96mVYa+xYjKM/RU1?=
 =?iso-8859-1?Q?fC9gVm70i1JRKV+oklIYFQ/q8N07iO1PeuUukaBgM5huZjPAZkyNNNcKsR?=
 =?iso-8859-1?Q?M8opHEikC36qo6rkoiKgTaweIrxf8S9LT78XhspOl8ohIY1ADruTsW9iGM?=
 =?iso-8859-1?Q?D6/E3Ck+8uNqHlD8Ng0pQY8hPNNl4QhYk/ti0LgwLDjFx3P0HOinkld4zW?=
 =?iso-8859-1?Q?XIFTmI4J7hSE5L036OX803woJvTXvalRBELGtKo+aCxEg4xqe8Qgsbwvhi?=
 =?iso-8859-1?Q?iVbISGxbWdJNabtjhkNF3xy2C2iHHQ4qntuYcZ1Vxj8n1Ob10b5sowOeBj?=
 =?iso-8859-1?Q?XUE/0YVu9bvsQxunO4O4djb76pQCcWA/cIUEr7s2KnmLbO9SVU3hP17qr7?=
 =?iso-8859-1?Q?W+uECASwdkMVqIlAG20Mu6AdsbISN1iJFmOMMi4HkmlmByb+r6znnTorUH?=
 =?iso-8859-1?Q?erSZq8v5bMMlJQK/uRC2QYxpUZLfxLUhRf0t4PD1dOk/4c0XH6ixMPLq1d?=
 =?iso-8859-1?Q?pzKx5fDs3hL9L9F4eWtP2N94sRpVRAkqBRyUojXPXJSzJiM6GqcNrhmsgV?=
 =?iso-8859-1?Q?P69RWRWMpUVLXEs8L9E1ord5HdyWGvMHkoviU32YZ2GKsPOLihc4qbvQBx?=
 =?iso-8859-1?Q?AQk0ybJXBGm4ylR1Dx/p+zUoIwhTobTdxiy8cdeMe2tVGPZy5GLTnY2795?=
 =?iso-8859-1?Q?JEmOw4qpjnso/qeAZfoDpzIG6oCT79FKZOTOcsmbP2p9nrIhdZ78p0Kur1?=
 =?iso-8859-1?Q?cXbnLfkTTBvK1IC8Sv3tDmxXMgmvu6FSeM/N6EsFZrQR12BjmHUndBUkpA?=
 =?iso-8859-1?Q?Gj0QLCKh3CMsQUUMxKgCoiHzTcjU+Jlu+uM+ZGWDqJD4Qc5mmttGM9wwJm?=
 =?iso-8859-1?Q?W9H4aEdH8lVUL69P9uz9agC3VZOsnRZI7prG3U7t/vViJ2bhWbw4ViDf70?=
 =?iso-8859-1?Q?Q5TALmL4U6j/7YiOFzg4q4lyf/RFVwVo0BYF5WKBVDI10HT8mLxAoxYZJs?=
 =?iso-8859-1?Q?08V6AzWNLbZr5VCZ3aCUK85SQdoiUl2nE5Ns9F9cypANPO8DlUk1sWvBwv?=
 =?iso-8859-1?Q?2Q6D/cNAqPZJFLAwfINH3wROQoG3AL+koXsaIBmGPOpWcToBFLQiWwXU3n?=
 =?iso-8859-1?Q?DI7pjcVk530yvYXDXQc4f637crnqfazyekTqKuzB7yUsd9/SSdDS42Frab?=
 =?iso-8859-1?Q?5PwwpLJrrivsOJIkyqaOLpRpUAogxf8yc0zSQPD3GcV1YXaajNfFcyew7W?=
 =?iso-8859-1?Q?3hdKFGPf/0J/oc+tbcDsv5gqwS9s5iDxOhttobKC6AgGKU0xF2k5XKVpgq?=
 =?iso-8859-1?Q?MgDRb84=3D?=
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)(366016)(376014)(1800799024)(7416014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?oTWkHRaixakLB7xik17MapjxoKrDVQECK0eTWiUZrij22Nipt8Jhhsw3+K?=
 =?iso-8859-1?Q?I502RzAHDv0I9PnfVg+yYdwDrFqFuk928RVvqO4VTXBKOqOt75s8WJqicJ?=
 =?iso-8859-1?Q?Qig8m9uYtZSXRZrnDWYA7gqP1SibR5QIQq4vAKzSFwhZhGTjfB0dyUQg9t?=
 =?iso-8859-1?Q?6FfiZZ60BODVe4zhA960n1f/MicSpjOf2LcjTYzhzgZoo6XrrKZECOZ62S?=
 =?iso-8859-1?Q?HwUqug2oOB8+6PB6I8Ouj36NZt/XoKAzXQQ009hktdV4t8/15SgSLL2vIh?=
 =?iso-8859-1?Q?EpbEaOuumKH0cicKJ6fbhSAtygoOPc5xQOiOnWVnlrrCjlSktrvNeZXKtu?=
 =?iso-8859-1?Q?QjkBrr6oI4piovGknOaS/F18ezfNv3J03aemcl8/PJCcflhN8/3Pzb/rX9?=
 =?iso-8859-1?Q?rn/k/3e9M1WsClJwdCmq0KDmBn1jp2GfBLsGDC3u0sQjfLhh9xfNCBDOxg?=
 =?iso-8859-1?Q?JX+hqMNm4O8bezrS6LXlYX+fISpIL/f4ziYVLpY9NoBywMIK6ys4rAONwi?=
 =?iso-8859-1?Q?s5OBnAPoAXry9JUUoWTA2lT9kK8k1432BeSbIbYi73Xi+/DF8OipvKj7ym?=
 =?iso-8859-1?Q?xPO/YrGqDONYCIzYBaibrNBR2dlWGTHAH8cOFBdJo/kx4k213oKudSpp6w?=
 =?iso-8859-1?Q?vtAXI1jYCSkQE1BjAvYmcMUNRP17/p5RYKvwcbygTgUZuHvSmZzyH2W1X1?=
 =?iso-8859-1?Q?qPOSMB5+LLVo1sh3bllQoiRDet+01AytzLrJnPc3ZmZIfaTN+1Jmu7P3Bk?=
 =?iso-8859-1?Q?OOoe8xAi/Y/ayTuE3ivEjQ6oALFaUSsNpWxl+WWlCMDJWiwVN7aRx62pcI?=
 =?iso-8859-1?Q?B1XvlegSeHMsNpWAaRXpnk06aRZCwliOgFEbWfKDNAFANWHVjEfUSIWuVS?=
 =?iso-8859-1?Q?Ev0QxpUhxW69xjUIsrF/i+KFJL9D/QyqvLVSH2dW9LDZWLMyGs7yFzNMmx?=
 =?iso-8859-1?Q?o/yPy1j0p5gv+OP+2pTtvzr7f9vjWjhE2jTc80/SuP/aTNoz/NwXgtkdqF?=
 =?iso-8859-1?Q?SpAKGSMAEIh0+hGPDMPPl7ivy7byL2I1zAD+yj47BNpatiQ+HZHjG37oCt?=
 =?iso-8859-1?Q?biWxcsOQFKzpuUNcO37O+/56gDSbY4iN7v3EUUxoIseH8Z7Ruu0JeExESg?=
 =?iso-8859-1?Q?ZD+WTnDoQSh6+UnscIcNo9BWSdnNviyYhWXbekEvjVNbs8ph0Uy0c1nX+X?=
 =?iso-8859-1?Q?c+f/1aZdEV7IjetjMxD2N8pzQlkjmiDclz3oGjk/sAjcwuRdQKgSqH4fXo?=
 =?iso-8859-1?Q?kpje1Gi1VH33OZVX72QYO2McIHMqLmsi0A8zbeRuUPTiExXsio3dDMkOWa?=
 =?iso-8859-1?Q?ddqWhnYgQy0jcRR+Tb42HFjLu0tB1kQA8vPkrf1+/9o/ZMEIc3HFfBPZjZ?=
 =?iso-8859-1?Q?2cuIUp7k2rtSC6jHjYGexWuakOM1oqMdvVw/KXuxZq/8xGMJlKzHDriCeM?=
 =?iso-8859-1?Q?g6LBdZfGVYlddma2FmTizWa6aoliLQR5y1S7IxxvCJxNfIElj1bIu+DIU4?=
 =?iso-8859-1?Q?9yChTL/RN/Ktl+ndU9fZRQkmVQOLQyDNJm7VYJwAz7Y1JxkxDGrQx7ajiO?=
 =?iso-8859-1?Q?kNKUFp4rmO3w+JrXuDcHlVmy74RkoSqp7EkdB/R7Syx65tyL3aG7/hV4vk?=
 =?iso-8859-1?Q?IxWtj9gT0oHAYk+KC42XqF7kOwWopuppnGV19R99QZgNdX2JaHe0zSPQ?=
 =?iso-8859-1?Q?=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: 4d743920-f541-4f9a-b257-08dd9dc7bf40
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2025 09:12:18.2184
 (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: UDp4VJdTEmb6VQxN4gV8MOiTNEJRL3+QCWa59wckpaFLP0b5xiT7HqnqvArA+Irlvk4zwHNR96Cy1sl3TH9JQA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9709

From: Stewart Hildebrand 

Enable the use of IOMMU + PCI in dom0 without having to specify
"pci-passthrough=3Dyes". Due to possible platform specific dependencies
of the PCI host, we rely on dom0 to initialize it and perform
a PHYSDEVOP_pci_device_add/remove call to add each device to SMMU.
PHYSDEVOP_pci_device_reset is left untouched as it does not have the
pci_passthrough_enabled check.

Because pci_passthrough is not always enabled on all architectures, add
a new function arch_pci_device_physdevop that checks if we need to enable
a subset of the PCI subsystem related to managing IOMMU configuration
for PCI devices.

Enable pci_init() for initializing Xen's internal PCI subsystem, and
allow PHYSDEVOP_pci_device_add when pci-passthrough is disabled.

Signed-off-by: Stewart Hildebrand 
Signed-off-by: Mykyta Poturai 
Reviewed-by: Stefano Stabellini 
---
hmm. Since
  dec9e02f3190 ("xen: avoid generation of stub  header")
Should we also move is_pci_passthrough_enabled() back to xen/arch/arm/inclu=
de/asm/pci.h ?
Not sure if PPC/RISC-V will plan on using this check.

v10->v11:
* always_inline -> inline
* add comments
* clarify reset sub-op handling in the commit message

v9->v10:
* move iommu_enabled check in a separate arch function
* add Stefano's RB

v8->v9:
* move iommu_enabled check inside is_pci_passthrough_enabled()

v7->v8:
* bring back x86 definition of is_pci_passthrough_enabled()

v6->v7:
* remove x86 definition of is_pci_passthrough_enabled()
* update comments
* make pci_physdev_op checks stricter

v5->v6:
* new patch - this effectively replaces
  ("Revert "xen/arm: Add cmdline boot option "pci-passthrough =3D =
""")
---
 xen/arch/arm/include/asm/pci.h |  2 ++
 xen/arch/arm/pci/pci.c         | 14 +++++++++++++-
 xen/arch/x86/include/asm/pci.h |  6 ++++++
 xen/drivers/pci/physdev.c      |  4 ++--
 xen/include/xen/pci.h          |  5 +++++
 5 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.=
h
index 7f77226c9b..d6e05f16b0 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -128,6 +128,8 @@ int pci_host_bridge_mappings(struct domain *d);
=20
 bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end);
=20
+bool arch_pci_device_physdevop(void);
+
 #else   /*!CONFIG_HAS_PCI*/
=20
 struct pci_dev;
diff --git a/xen/arch/arm/pci/pci.c b/xen/arch/arm/pci/pci.c
index 8d9692c92e..ca825ee3a6 100644
--- a/xen/arch/arm/pci/pci.c
+++ b/xen/arch/arm/pci/pci.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
=20
@@ -75,6 +76,17 @@ static int __init acpi_pci_init(void)
 }
 #endif
=20
+/*=20
+ * Platform-specific PCI host dependencies require dom0 to handle
+ * initialization and issue PHYSDEVOP_pci_device_add/remove calls for SMMU
+ * device registration. This check is used to enable the minimal PCI
+ * subsystem required for dom0 operation when PCI passthrough is disabled.
+ */
+bool arch_pci_device_physdevop(void)
+{
+    return iommu_enabled;
+}
+
 /* By default pci passthrough is disabled. */
 bool __read_mostly pci_passthrough_enabled;
 boolean_param("pci-passthrough", pci_passthrough_enabled);
@@ -85,7 +97,7 @@ static int __init pci_init(void)
      * Enable PCI passthrough when has been enabled explicitly
      * (pci-passthrough=3Don).
      */
-    if ( !pci_passthrough_enabled )
+    if ( !is_pci_passthrough_enabled() && !arch_pci_device_physdevop() )
         return 0;
=20
     if ( pci_add_segment(0) )
diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.=
h
index fd5480d67d..61d8043fa3 100644
--- a/xen/arch/x86/include/asm/pci.h
+++ b/xen/arch/x86/include/asm/pci.h
@@ -67,4 +67,10 @@ static inline bool pci_check_bar(const struct pci_dev *p=
dev,
     return is_memory_hole(start, end);
 }
=20
+/* PCI passthrough is always enabled on x86 so no special handling is need=
ed */
+static inline bool arch_pci_device_physdevop(void)
+{
+    return false;
+}
+
 #endif /* __X86_PCI_H__ */
diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c
index 0161a85e1e..21c8a3a90e 100644
--- a/xen/drivers/pci/physdev.c
+++ b/xen/drivers/pci/physdev.c
@@ -19,7 +19,7 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void=
) arg)
         struct pci_dev_info pdev_info;
         nodeid_t node =3D NUMA_NO_NODE;
=20
-        if ( !is_pci_passthrough_enabled() )
+        if ( !is_pci_passthrough_enabled() && !arch_pci_device_physdevop()=
)
             return -EOPNOTSUPP;
=20
         ret =3D -EFAULT;
@@ -57,7 +57,7 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void=
) arg)
     case PHYSDEVOP_pci_device_remove: {
         struct physdev_pci_device dev;
=20
-        if ( !is_pci_passthrough_enabled() )
+        if ( !is_pci_passthrough_enabled() && !arch_pci_device_physdevop()=
)
             return -EOPNOTSUPP;
=20
         ret =3D -EFAULT;
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index ef60196653..130c2a8c1a 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -79,6 +79,11 @@ static inline bool is_pci_passthrough_enabled(void)
     return false;
 }
=20
+static inline bool arch_pci_device_physdevop(void)
+{
+    return false;
+}
+
 #endif
=20
 struct pci_dev_info {
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 28 09:12:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:12:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999016.1379696 (Exim 4.92)
	(envelope-from )
	id 1uKCpl-0005b5-Kr; Wed, 28 May 2025 09:12:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999016.1379696; Wed, 28 May 2025 09:12: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 1uKCpl-0005ay-HN; Wed, 28 May 2025 09:12:25 +0000
Received: by outflank-mailman (input) for mailman id 999016;
 Wed, 28 May 2025 09:12:23 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCpj-00059a-Qx
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:12:23 +0000
Received: from MRWPR03CU001.outbound.protection.outlook.com
 (mail-francesouthazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c207::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dcb00c9c-3ba3-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:12:21 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DB9PR03MB9709.eurprd03.prod.outlook.com
 (2603:10a6:10:459::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Wed, 28 May
 2025 09:12:17 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8769.022; Wed, 28 May 2025
 09:12: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" 
X-Inumbo-ID: dcb00c9c-3ba3-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=g2PAgbAzijzRPJ0abU+W+PNMP2y7Ak2f8+5bfLQEaOBAEEEndUkTFm2Cv2umuhJ21eLJyv0byCCUOceP5Tigzn5QaWQhEN8XegEldpbrHDRNeJfrd1SF+qKCqlb3O/zFd4NSVGCeU+QeK1vYHvj440L7dX2+N7zL2SgAVHAxdw8auZYc0ePbxn3shLOxCuqxALYsnVKyud+pMvfzKA4GzseVFj6lWwtnn9OJQRTng1zysZ9DKos35z5bvSK2IybXdgzf8vZz/aTx+dn272x2K4dpPFLtYImrHzSSNPrqqvsh4X8h3NLUSw3ilZ6G3A9NSjFnJAwbBVNz9FIFH2e4hw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=feQP03lnAwZDb6Fdrdmses8POLR1iULn+/1Zr6zs7Ps=;
 b=jLCkr9GKCIqMqk0u/hLUVsrzBDwV0oWTKkvPou/BtEklGcB8eSYKmrJWai+Zvk3/oMMSwj6BsHxdekeSnit9csMOud63Hx+LfJBof5sPeqFs0Ot+s7ES/xQhz/5Vndl3O5jGZizxhKf8RzuXuCJ+P2nxRw/sqjQCg1rgWZNwN4VIoXV3MOgExTUSVsHt0qG0hda33+ydysM2kNwtigWzMlw9kYKmJ8wKf3LgrYfIpp5SwwgjUStExam12JypUXF1gbRIJqoqX23qLLjhqv+KEQQxyiiEapd2XnX9StdtVmA7Ir9R2n61aHRddfOvEcOpS7TBsXdYmwXXmwO0jPwntA==
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=feQP03lnAwZDb6Fdrdmses8POLR1iULn+/1Zr6zs7Ps=;
 b=TxVXcrZXbF9z1PDHnbC3fSNjqczpZbpVoyD88BzQ0YZQcwCCP36pqsxvjfVibrTsskMiaefIwEctmDOFOP6fHVXQwxHyehVW/+ph68fBMF0CKXj33VJUehjO110uDDsIANoyCV3Wx/T0IeQh2WNyO+Ggj/C7uwukS49hzyvY+R3Qxzna67WASeRqtHt2KR+47nc0rpX8iBBOUGPTuFlmqQSt7o/JWc5rb+D4U3wulIWNaJ1HzxhI6+ZLgTUPeIrUDIU9xDjfu62zT11xx7oTi+rxjx81U9LuCsbYN+IrBFWMOFKzmMu4XRf6N6QfhvUkmf2dE23m/hoNMyKPpnelRQ==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Tyshchenko , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Jan Beulich ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stewart Hildebrand
	, Mykyta Poturai 
Subject: [PATCH v11 1/7] iommu/arm: Introduce iommu_add_dt_pci_sideband_ids
 API
Thread-Topic: [PATCH v11 1/7] iommu/arm: Introduce
 iommu_add_dt_pci_sideband_ids API
Thread-Index: AQHbz7CbyxcxAhscKUi8K3dySuLaiA==
Date: Wed, 28 May 2025 09:12:16 +0000
Message-ID:
 <503fe598dd53b4023bc60e621592f4f0a0e0bf6c.1748422217.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: 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_|DB9PR03MB9709:EE_
x-ms-office365-filtering-correlation-id: ef271583-c17e-4123-f012-08dd9dc7be54
x-ld-processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?DP7M36L7vn8yaTbPmQH5Zgorm4bfNi5yCrIynIyEw+MVmwYGjHr+G+V5mD?=
 =?iso-8859-1?Q?s/JiGH0/wQ2MdIira2nZiGs/3ItNaPjfxOdjKyOGoYPgid8Y83vIFM+VDX?=
 =?iso-8859-1?Q?HS05WMKXqyerb5dSEJPOZgKKlGluVliKy5kD7ik9cyA/f2YUKWxazg6brp?=
 =?iso-8859-1?Q?wYkDWIU6DWBYWFG74zWC56Ln5CXV6T7iy4XHXYsuWPd2CyP9FmY5tvgJ0/?=
 =?iso-8859-1?Q?L0NOUaq3MebSKq3A3gxbWTb6XO3G2lrA0iiyCxa6BdghZYPdxPWMOKBav7?=
 =?iso-8859-1?Q?QsiHKuERGPKy8d3sTRNZpyyYF12pj6ec7pXt2u8keLuxU00i+TXMdlESor?=
 =?iso-8859-1?Q?pnSP0pZlCOGpCp6mu6IzslWNPD4qpiL3Z79Fn7Dtq1cw71P0OlcgA6zVbR?=
 =?iso-8859-1?Q?wF8W2QOf9Rgb3fTVPaoWna59hBOrRd5rAykaQ/UglfGkKkLqEjtPPF36Mn?=
 =?iso-8859-1?Q?VAVHWaz9y4VaZygyYU5O6Lm0Wlrl5PCFyuwrBROJm8OOqUr7C/WAufvy24?=
 =?iso-8859-1?Q?rH7jeCx2GyUEc4nHGAWvmoLqUbRHMYKzbmXPz00xkBo972EgAdZ/pYBeYx?=
 =?iso-8859-1?Q?VeLanSfJQgxcyIP6ItIxi7C40E1Ke39xJ5ORUuqQxjGBRkYohUoAM5FgOJ?=
 =?iso-8859-1?Q?F1vMEneEY0vconixnMKVvQqSHJfvK3wWAj8g/aqCKgaY5G6uOtiPGY7sy7?=
 =?iso-8859-1?Q?wc5lPkO+LU5+711bbIYo9S24sJyKjfKwDreQgcYbFLHSvSDrObUCQpBL0P?=
 =?iso-8859-1?Q?Gt1UdQJavcR9S7kaa3iHGrr1jzn6kDx/VRNCtW17rC3GR3CcUk3VtBFy0y?=
 =?iso-8859-1?Q?EzNclRfn/IwFgfCS0L0JIjVoL2eFO77IDFCEGwQ5RxiVm9BT2HoAinowh0?=
 =?iso-8859-1?Q?lVBsFPZGjorIkVRAKJEwNMnFytuUJYuiAgodSw2NIaaaK13jcOFfSbAJ9u?=
 =?iso-8859-1?Q?8oJ+eT3tgNCoIjxSwF6iibDPggl07XTlPYUAgMwbHfV1KG2Uf/ncf81Ec5?=
 =?iso-8859-1?Q?DLEwWNhGugS8SzarIsK6kfmWJxHMMgJxAAz+ITCcZsPX6eTT/8VvB9l0mp?=
 =?iso-8859-1?Q?XuBpAsK/z8jkgXyttZlv+1VhHpeJLZLvk2m6K/95F0lmshHdCLFrb6Q0cE?=
 =?iso-8859-1?Q?fNtH/M6cNAz8NTDYRAT2UEBG+ui8VUpx1glQS4NI6EsKlwXbszTlM5tE5q?=
 =?iso-8859-1?Q?qh4RVCOitrMEAtcFujeyC0FVYbgo/FeTBDats7mMp/4kvrncfA4UbZITRX?=
 =?iso-8859-1?Q?leiNu8EftL8KYDW3dqsFrrx04c9FVDPGgte7jKiT+oZHkXdwXt53KAlK8B?=
 =?iso-8859-1?Q?nvaFBkGsJ8szcB2Y4dKdcP8qiFkYn3Xg7tFY9WwAFhqYMPvH/DvjTqlgCi?=
 =?iso-8859-1?Q?4BHCYFT8aU0Ndkujnzv2fijpTRIEPYDJc8T4bmn2P9C7RWBanJDYcEvY4w?=
 =?iso-8859-1?Q?tXlvYojs2muA3SzyzKlzr9+EmCFmtzTxiXXrjPZjr47jn3SFUUYTIlo+U7?=
 =?iso-8859-1?Q?o=3D?=
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)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?c78s4QGtTZPo1+OoDcKflJXeTPZywsNMB5TW30hh3TOB9UCJ4gGN1162rc?=
 =?iso-8859-1?Q?Dwn8+KaFmbJ/AnweHBWgrwq0zRXo6M/DaWyvpKZ8U5OUHhealhRhlc9Fry?=
 =?iso-8859-1?Q?yVYZVwSBfeZDA43y3Ca6UoPyg/mGxmZK25u7YJ4fl2h90Z89U3n+HeY05M?=
 =?iso-8859-1?Q?4Q19+O8QITBbg8pIUoc0y9dmdlJDhLGN08+e3VxfWw5/r0FNHJBMHjhSH3?=
 =?iso-8859-1?Q?LLpiMBapx5iK3y7OOANKYTNlfVyTn+CUNh2Up8U9R2uT9An3Gxg6bCMxLT?=
 =?iso-8859-1?Q?uI/LUCfLCES6PaJv5d5dg/f3jpQMyGbRI36mvHL5ZubfpOYSzX7v4E4XWl?=
 =?iso-8859-1?Q?G6bZy8wM+AXe76WfCh+cdUwtJRZZpOxHGOwCwTEOj+fp7inMLV3lLB8Joa?=
 =?iso-8859-1?Q?Md9sGN+h2k2O087bVHrSFp4EZOXJVuxNbL1jKK3HnuNzd7DgrjcHlX+BrZ?=
 =?iso-8859-1?Q?jIdXOuJfYZsJzEyyzMCov9EvK8Af1SZn6tk9dMbHzbKlOcgyxiZWQYvZWE?=
 =?iso-8859-1?Q?6udkpLLLfK9c2nVskvpvEKse3tynu8LNYK0qJy613K/r8Btq/5u8DQfck8?=
 =?iso-8859-1?Q?asOyhuFjelCtHYsf16115Riz7mYLTQQQlcHNJ4rpmjTPfdF3/QjlPq+vWi?=
 =?iso-8859-1?Q?Z6b+4cvBmdPN/PcQykeI6zh05BbGOLWReBFHVZFjm0KzrwkFsUGrVqW9Um?=
 =?iso-8859-1?Q?LF3i/OgBPMsuxUIYmClLnnL98OGKghd/E3BICLlryNtXKs3zPcUdDUwh4k?=
 =?iso-8859-1?Q?xAnZ6V1fQMegV9wMoIGczCP4ztCp5fhTHyTZtTjQYHCigvbtaoFMPhpmlJ?=
 =?iso-8859-1?Q?vY65N0xPVx3g+N06Css3UIK++jrx+u8u5fNAjaMSTz8lxsQAq5cAzszKt5?=
 =?iso-8859-1?Q?K5TzW7J64ROVH5OuVth2T6mXS0Qw5shloJ6a5oMtEZ3e2r/15ihl2BpJB8?=
 =?iso-8859-1?Q?iYuNLrfiZ0O+pncCFZILryK6vDa0Sl88WMOtQO3X2YN9jg+g+vNJQKbGbr?=
 =?iso-8859-1?Q?2ymTtZbJtuSv7NQPOGQpHXBUxaPK9v0tLe9q1PLcoscxgXTlqK1T4J8yaf?=
 =?iso-8859-1?Q?K0hIdjiQd32hW/e3q5C/qes6D1YeLZECKHMNgN1k5ytosK5b0djc8hHL8Y?=
 =?iso-8859-1?Q?3SSbhcuq7aqT3asG+4TYUmw4Sy3gbtfsyNZX9heoIyCR66V9x65LDooqaH?=
 =?iso-8859-1?Q?a76BdHU4s30zA4uV16pmvHF+tZkjBEusF26P39GQCJMmz5lRGpG41515zq?=
 =?iso-8859-1?Q?dfHGoQzUefvdnrBubhalJ60qeUNgNf6R1n2/qHBveuUJEiM81AmKNnL9hn?=
 =?iso-8859-1?Q?d0Dzgk9rBw9jHNRCtUJUkiGe7kJqC+A5nUGqfrC8egqPEbNGe8HMfzxni6?=
 =?iso-8859-1?Q?d5H+KFBRoAPJSzIqTlk330qWUBvPgbPXzmcrRG815lQXT3/iuyZX5CH9NB?=
 =?iso-8859-1?Q?3CYNCvRFnEBaYrAARChNCDjxvxgwrrnTFryUlNFg7xdE269UMO/O9wUbIk?=
 =?iso-8859-1?Q?wbj8OQ0ktYpxNAhTjWpswoHJ66AGMjkLNDtsKD/GFRo6ThsDtHPIayRFAn?=
 =?iso-8859-1?Q?3QOdMyOzdSFgZdo1IebH/Y3/jidfPZHdS4C5S2e5ncj4NEjcTtlIIjFfFg?=
 =?iso-8859-1?Q?5CHXGSffP/bJtbOr1RBImP+H2MTMrva7JmaJS8SyJluc2KiYQ8gAiWWQ?=
 =?iso-8859-1?Q?=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: ef271583-c17e-4123-f012-08dd9dc7be54
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2025 09:12:16.4584
 (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: zjMi3UveGAYp08iwVBdRzmbqDn4xrwCbL8d8gOh2vVukXiW+ivMtgLgnAoPe4kGAKF+vz9jMBrAgI+EmjV2S5A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9709

From: Oleksandr Tyshchenko 

The main purpose of this patch is to add a way to register PCI device
(which is behind the IOMMU) using the generic PCI-IOMMU DT bindings [1]
before assigning that device to a domain.

This behaves similarly to the existing iommu_add_dt_device API, except it
handles PCI devices, and it is to be invoked from the add_device hook in th=
e
SMMU driver.

The function dt_map_id to translate an ID through a downstream mapping
(which is also suitable for mapping Requester ID) was borrowed from Linux
(v5.10-rc6) and updated according to the Xen code base.

[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/pci/pci-io=
mmu.txt

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Stewart Hildebrand 
Signed-off-by: Mykyta Poturai 
Reviewed-by: Stefano Stabellini 
---
Regarding pci_for_each_dma_alias question: getting host bridge node
directly seems like a simpler solution with the same result. AFAIU
with pci_for_each_dma_alias in linux we would arrive to the host brige
node anyway, but also try to call dt_map_id for each device along the
way. I am not sure why exactly it is done this way in linux, as
according to the pci-iommu.txt, iommu-map node can only be present in
the PCI root.

v10-v11:
* add Stefano's RB

v9->v10:
* move iommu_add_pci_sidebands_ids to arm/iommu.c
* replace be32_to_cpup with be32_to_cpu

v8->v9:
* replace DT_NO_IOMMU with 1
* guard iommu_add_pci_sideband_ids with CONFIG_ARM

v7->v8:
* ENOSYS->EOPNOTSUPP
* move iommu_add_pci_sideband_ids to iommu.c to fix x86 build
* simplify iommu_add_pci_sideband_ids
* add docstrings to iommu_add_{dt_}pci_sideband_ids

v6->v7:
* put iommu_add_pci_sideband_ids under ifdef
* remove ifdef CONFIG_APCI
* style: add newline for symmetry

v5->v6:
* pass ops to iommu_dt_xlate()

v4->v5:
* style: add newlines after variable declarations and before return in iomm=
u.h
* drop device_is_protected() check in iommu_add_dt_pci_sideband_ids()
* rebase on top of ("dynamic node programming using overlay dtbo") series
* fix typo in commit message
* remove #ifdef around dt_map_id() prototype
* move dt_map_id() to xen/common/device_tree.c
* add function name in error prints
* use dprintk for debug prints
* use GENMASK and #include 
* fix typo in comment
* remove unnecessary (int) cast in loop condition
* assign *id_out and return success in case of no translation in dt_map_id(=
)
* don't initialize local variable unnecessarily
* return error in case of ACPI/no DT in iommu_add_{dt_}pci_sideband_ids()

v3->v4:
* wrap #include  and if ( acpi_disabled ) in #ifdef CONFIG_ACPI
* fix Michal's remarks about style, parenthesis, and print formats
* remove !ops->dt_xlate check since it is already in iommu_dt_xlate helper
* rename s/iommu_dt_pci_map_id/dt_map_id/ because it is generic, not specif=
ic
  to iommu
* update commit description

v2->v3:
* new patch title (was: iommu/arm: Introduce iommu_add_dt_pci_device API)
* renamed function
  from: iommu_add_dt_pci_device
  to: iommu_add_dt_pci_sideband_ids
* removed stale ops->add_device check
* iommu.h: add empty stub iommu_add_dt_pci_sideband_ids for !HAS_DEVICE_TRE=
E
* iommu.h: add iommu_add_pci_sideband_ids helper
* iommu.h: don't wrap prototype in #ifdef CONFIG_HAS_PCI
* s/iommu_fwspec_free(pci_to_dev(pdev))/iommu_fwspec_free(dev)/

v1->v2:
* remove extra devfn parameter since pdev fully describes the device
* remove ops->add_device() call from iommu_add_dt_pci_device(). Instead, re=
ly on
  the existing iommu call in iommu_add_device().
* move the ops->add_device and ops->dt_xlate checks earlier

downstream->v1:
* rebase
* add const qualifier to struct dt_device_node *np arg in dt_map_id()
* add const qualifier to struct dt_device_node *np declaration in iommu_add=
_pci_device()
* use stdint.h types instead of u8/u32/etc...
* rename functions:
  s/dt_iommu_xlate/iommu_dt_xlate/
  s/dt_map_id/iommu_dt_pci_map_id/
  s/iommu_add_pci_device/iommu_add_dt_pci_device/
* add device_is_protected check in iommu_add_dt_pci_device
* wrap prototypes in CONFIG_HAS_PCI

(cherry picked from commit 734e3bf6ee77e7947667ab8fa96c25b349c2e1da from
 the downstream branch poc/pci-passthrough from
 https://gitlab.com/xen-project/people/bmarquis/xen-arm-poc.git)
---
 xen/arch/arm/include/asm/iommu.h      | 15 +++++
 xen/common/device-tree/device-tree.c  | 91 +++++++++++++++++++++++++++
 xen/drivers/passthrough/arm/iommu.c   | 13 ++++
 xen/drivers/passthrough/device_tree.c | 42 +++++++++++++
 xen/include/xen/device_tree.h         | 23 +++++++
 xen/include/xen/iommu.h               | 21 ++++++-
 6 files changed, 204 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/iommu.h b/xen/arch/arm/include/asm/io=
mmu.h
index d57bd8a38c..ad15477e24 100644
--- a/xen/arch/arm/include/asm/iommu.h
+++ b/xen/arch/arm/include/asm/iommu.h
@@ -34,6 +34,21 @@ int __must_check arm_iommu_unmap_page(struct domain *d, =
dfn_t dfn,
                                       unsigned int order,
                                       unsigned int *flush_flags);
=20
+/*
+ * This function is not strictly ARM-specific, but it is only used by ARM
+ * as of now. So put it here to avoid creating dead code on other
+ * architectures. When usage is extended to other architectures, it should
+ * be moved to the generic header.
+ *
+ *
+ * Fills out the device's IOMMU fwspec with IOMMU ids.
+ *
+ * Return values:
+ *  0 : iommu_fwspec is filled out successfully.
+ * <0 : error while filling out the iommu_fwspec.
+ * >0 : IOMMU is not enabled/present or device is not connected to it.
+ */
+int iommu_add_pci_sideband_ids(struct pci_dev *pdev);
 #endif /* __ARCH_ARM_IOMMU_H__ */
=20
 /*
diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/=
device-tree.c
index 886e6c7712..7bede20fa6 100644
--- a/xen/common/device-tree/device-tree.c
+++ b/xen/common/device-tree/device-tree.c
@@ -7,6 +7,7 @@
  * benh@kernel.crashing.org
  */
=20
+#include 
 #include 
 #include 
 #include 
@@ -2221,6 +2222,96 @@ int dt_get_pci_domain_nr(struct dt_device_node *node=
)
     return (u16)domain;
 }
=20
+int dt_map_id(const struct dt_device_node *np, uint32_t id,
+              const char *map_name, const char *map_mask_name,
+              struct dt_device_node **target, uint32_t *id_out)
+{
+    uint32_t map_mask, masked_id, map_len;
+    const __be32 *map =3D NULL;
+
+    if ( !np || !map_name || (!target && !id_out) )
+        return -EINVAL;
+
+    map =3D dt_get_property(np, map_name, &map_len);
+    if ( !map )
+    {
+        if ( target )
+            return -ENODEV;
+
+        /* Otherwise, no map implies no translation */
+        *id_out =3D id;
+        return 0;
+    }
+
+    if ( !map_len || (map_len % (4 * sizeof(*map))) )
+    {
+        printk(XENLOG_ERR "%s(): %s: Error: Bad %s length: %u\n", __func__=
,
+               np->full_name, map_name, map_len);
+        return -EINVAL;
+    }
+
+    /* The default is to select all bits. */
+    map_mask =3D GENMASK(31, 0);
+
+    /*
+     * Can be overridden by "{iommu,msi}-map-mask" property.
+     * If dt_property_read_u32() fails, the default is used.
+     */
+    if ( map_mask_name )
+        dt_property_read_u32(np, map_mask_name, &map_mask);
+
+    masked_id =3D map_mask & id;
+    for ( ; map_len > 0; map_len -=3D 4 * sizeof(*map), map +=3D 4 )
+    {
+        struct dt_device_node *phandle_node;
+        uint32_t id_base =3D be32_to_cpu(*(map + 0));
+        uint32_t phandle =3D be32_to_cpu(*(map + 1));
+        uint32_t out_base =3D be32_to_cpu(*(map + 2));
+        uint32_t id_len =3D be32_to_cpu(*(map + 3));
+
+        if ( id_base & ~map_mask )
+        {
+            printk(XENLOG_ERR "%s(): %s: Invalid %s translation - %s-mask =
(0x%"PRIx32") ignores id-base (0x%"PRIx32")\n",
+                   __func__, np->full_name, map_name, map_name, map_mask,
+                   id_base);
+            return -EFAULT;
+        }
+
+        if ( (masked_id < id_base) || (masked_id >=3D (id_base + id_len)) =
)
+            continue;
+
+        phandle_node =3D dt_find_node_by_phandle(phandle);
+        if ( !phandle_node )
+            return -ENODEV;
+
+        if ( target )
+        {
+            if ( !*target )
+                *target =3D phandle_node;
+
+            if ( *target !=3D phandle_node )
+                continue;
+        }
+
+        if ( id_out )
+            *id_out =3D masked_id - id_base + out_base;
+
+        dprintk(XENLOG_DEBUG, "%s: %s, using mask %08"PRIx32", id-base: %0=
8"PRIx32", out-base: %08"PRIx32", length: %08"PRIx32", id: %08"PRIx32" -> %=
08"PRIx32"\n",
+               np->full_name, map_name, map_mask, id_base, out_base, id_le=
n, id,
+               masked_id - id_base + out_base);
+        return 0;
+    }
+
+    dprintk(XENLOG_DEBUG, "%s: no %s translation for id 0x%"PRIx32" on %s\=
n",
+           np->full_name, map_name, id,
+           (target && *target) ? (*target)->full_name : NULL);
+
+    if ( id_out )
+        *id_out =3D id;
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/drivers/passthrough/arm/iommu.c b/xen/drivers/passthrough/=
arm/iommu.c
index fc453180f0..100545e23f 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -15,6 +15,7 @@
  * GNU General Public License for more details.
  */
=20
+#include 
 #include 
 #include 
 #include 
@@ -151,3 +152,15 @@ bool arch_iommu_use_permitted(const struct domain *d)
 {
     return true;
 }
+
+int iommu_add_pci_sideband_ids(struct pci_dev *pdev)
+{
+    int ret =3D -EOPNOTSUPP;
+
+#ifdef CONFIG_HAS_PCI
+    if ( acpi_disabled )
+        ret =3D iommu_add_dt_pci_sideband_ids(pdev);
+#endif
+
+    return ret;
+}
diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthroug=
h/device_tree.c
index 4a1971c3fc..37e1437b65 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -161,6 +161,48 @@ static int iommu_dt_xlate(struct device *dev,
     return ops->dt_xlate(dev, iommu_spec);
 }
=20
+#ifdef CONFIG_HAS_PCI
+int iommu_add_dt_pci_sideband_ids(struct pci_dev *pdev)
+{
+    const struct iommu_ops *ops =3D iommu_get_ops();
+    struct dt_phandle_args iommu_spec =3D { .args_count =3D 1 };
+    struct device *dev =3D pci_to_dev(pdev);
+    const struct dt_device_node *np;
+    int rc;
+
+    if ( !iommu_enabled )
+        return 1;
+
+    if ( !ops )
+        return -EINVAL;
+
+    if ( dev_iommu_fwspec_get(dev) )
+        return -EEXIST;
+
+    np =3D pci_find_host_bridge_node(pdev);
+    if ( !np )
+        return -ENODEV;
+
+    /*
+     * According to the Documentation/devicetree/bindings/pci/pci-iommu.tx=
t
+     * from Linux.
+     */
+    rc =3D dt_map_id(np, PCI_BDF(pdev->bus, pdev->devfn), "iommu-map",
+                   "iommu-map-mask", &iommu_spec.np, iommu_spec.args);
+    if ( rc )
+        return (rc =3D=3D -ENODEV) ? 1 : rc;
+
+    rc =3D iommu_dt_xlate(dev, &iommu_spec, ops);
+    if ( rc < 0 )
+    {
+        iommu_fwspec_free(dev);
+        return -EINVAL;
+    }
+
+    return rc;
+}
+#endif /* CONFIG_HAS_PCI */
+
 int iommu_remove_dt_device(struct dt_device_node *np)
 {
     const struct iommu_ops *ops =3D iommu_get_ops();
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6dc1fb5159..3de7ff9085 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -947,6 +947,29 @@ int dt_count_phandle_with_args(const struct dt_device_=
node *np,
  */
 int dt_get_pci_domain_nr(struct dt_device_node *node);
=20
+/**
+ * dt_map_id - Translate an ID through a downstream mapping.
+ * @np: root complex device node.
+ * @id: device ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on tha=
t
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will b=
e
+ * matched; if it points to a NULL value, it will receive the device node =
of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int dt_map_id(const struct dt_device_node *np, uint32_t id,
+              const char *map_name, const char *map_mask_name,
+              struct dt_device_node **target, uint32_t *id_out);
+
 struct dt_device_node *dt_find_node_by_phandle(dt_phandle handle);
=20
 #ifdef CONFIG_DEVICE_TREE_DEBUG
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 832775754b..ebfada1d88 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -241,7 +241,8 @@ int iommu_dt_domain_init(struct domain *d);
 int iommu_release_dt_devices(struct domain *d);
=20
 /*
- * Helper to add master device to the IOMMU using generic IOMMU DT binding=
s.
+ * Helpers to add master device to the IOMMU using generic (PCI-)IOMMU
+ * DT bindings.
  *
  * Return values:
  *  0 : device is protected by an IOMMU
@@ -251,6 +252,19 @@ int iommu_release_dt_devices(struct domain *d);
  */
 int iommu_add_dt_device(struct dt_device_node *np);
=20
+/*
+ * Fills out the device's IOMMU fwspec with IOMMU ids from the DT.
+ * Ids are specified in the iommu-map property in the host bridge node.
+ * More information on the iommu-map property format can be found in
+ * Documentation/devicetree/bindings/pci/pci-iommu.txt from Linux.
+ *
+ * Return values:
+ *  0 : iommu_fwspec is filled out successfully.
+ * <0 : error while filling out the iommu_fwspec.
+ * >0 : IOMMU is not enabled/present or device is not connected to it.
+ */
+int iommu_add_dt_pci_sideband_ids(struct pci_dev *pdev);
+
 int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
                        XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
=20
@@ -286,6 +300,11 @@ static inline int iommu_release_dt_devices(struct doma=
in *d)
     return 0;
 }
=20
+static inline int iommu_add_dt_pci_sideband_ids(struct pci_dev *pdev)
+{
+    return -EOPNOTSUPP;
+}
+
 #endif /* HAS_PASSTHROUGH */
=20
 #endif /* HAS_DEVICE_TREE */
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 28 09:12:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:12:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999020.1379736 (Exim 4.92)
	(envelope-from )
	id 1uKCpq-0006Yn-4M; Wed, 28 May 2025 09:12:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999020.1379736; Wed, 28 May 2025 09: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 1uKCpq-0006YY-0E; Wed, 28 May 2025 09:12:30 +0000
Received: by outflank-mailman (input) for mailman id 999020;
 Wed, 28 May 2025 09:12:27 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCpn-00059a-Rr
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:12:27 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170100001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id deda430f-3ba3-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:12:25 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DB9PR03MB9709.eurprd03.prod.outlook.com
 (2603:10a6:10:459::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Wed, 28 May
 2025 09:12:19 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8769.022; Wed, 28 May 2025
 09:12: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" 
X-Inumbo-ID: deda430f-3ba3-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JgK/+VqvlYCfjK55LP+uQ8zI9t0bUsDllbCaz57/Qci8k50nRALfhEsfQ6VrJyQ7PlENk0krnwHT3zx427CqGK93r6FLJhoa484PZ9pR61nPNSeWE5y9B8SwopULdOI1bXc8VUnfoywqjEivSK6/zL+1SAN/wp2sineCnqwxozgXFrkhUSzmLXJI9I9x+yiuhSCkd76qAdXqf26shuDSrm9CjDjVNwdZJu+DB9nmF1gwN+RZGPZUvdhe+US395/+T9Beh0SJ2mLWLJz6Atch/ts+QhAG1Q7rXddLs7yP+SFWY7jmNkX5mfAYn/AxE8LCwWrx/qozNTlKobbozz+xcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KEZ/g1/L7lCVbGr++G8wPspm9uPCGKIkFud3rE9aj+M=;
 b=xpe+1dEviCP2DiTAtqYJrqzAa6w/aEff41DKlMAxkBkzMnmaniDjKNPI7F5a6vkm9S3BzGO/uGiysavWxEvXg0Rd/a+rDNJDO5bAVE4NrclC2mdLk0jmbrHyY2OUpx2cNEC/2z9Gyikn+mpF3u1tPONqKfxCAKen/tOzTczF/8J6xwjIX2t3nF6g+RZcrIy4pMM9P1NnXJBiZ86JFvD995fbqaOxi/augJt/6kU/Nqdd9eq08F0CWKcXTdrXZ8jW+YAEIvhhpfHFLmOocf5f9ekFkf3BpqIKyUo+99WNAIKtprmSyJt4s0ROCvWn+qNBN2paF5EWRZqC5rDo98gT7g==
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=KEZ/g1/L7lCVbGr++G8wPspm9uPCGKIkFud3rE9aj+M=;
 b=GKlqze/D2ZjyWfQMaXAmU0a3ySuk9jrVXmSRy/dDFXzelXoGkOkZ9YzIZFgAYsQMtYyeGoTqLvVxNGeRCsLD3H71m6BLMRk3u876UnlCHrh8RhPYgBRcHIp7Q9esnfB9f+AcwCjJDt7sMoVUyTviX0XT+h2Kh8JS7veo+QDmAb/PjsV/4fGu5bcPoO0ty4IB4zZLuVA77Nf9yYc8JR8HKt4gsobr84/IJvbCoHQ8VFqQKDkQiIUiOy3r4/810iKZuM97SDatv93rGFJEl7IzsSmsNZv3dpmMN1DSJ8zwBKaYj1BJIdlA0qYBrWfSCXTl1zXQw3ZPuHMVtmRFJ0rf8A==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Rahul Singh , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Stewart Hildebrand
	, Mykyta Poturai 
Subject: [PATCH v11 7/7] xen/arm: Map ITS doorbell register to IOMMU page
 tables
Thread-Topic: [PATCH v11 7/7] xen/arm: Map ITS doorbell register to IOMMU page
 tables
Thread-Index: AQHbz7Ccn/ACVQMjDkycMZ0+lkfrtg==
Date: Wed, 28 May 2025 09:12:18 +0000
Message-ID:
 <893a21afbf4238ae3eedd2e32246937c7ece59b5.1748422217.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: 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_|DB9PR03MB9709:EE_
x-ms-office365-filtering-correlation-id: d9456772-05d7-4c5d-5298-08dd9dc7bf71
x-ld-processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?WGEwzkST5jK5NmtMnyHP2RjwHgLRx+fI75WaDY1eTEl4VMyfixS1eZxTy6?=
 =?iso-8859-1?Q?jEQuTROSvu84zVzabelCzuO7U0bP7RqVhDyHiKuWa154kYPp2L+l/6LwBg?=
 =?iso-8859-1?Q?BOXVlKxCmK4OwES/Zfd6q66oq+tpms/0llaNeb8437I3bmP2eWeaPEPtqv?=
 =?iso-8859-1?Q?I9uUSCVw4Joq1fKBXwD12CqAWiq9JGdJS7SqloAOeIyG5BjavE/rVbgklE?=
 =?iso-8859-1?Q?psWnQUKSTnsLBdzyRHfFhodhm0UXBE6IahLQNcQ7jKrxUPCJggq/W9fHxZ?=
 =?iso-8859-1?Q?FXi9yrGyJkjGgxWOQcpCFpA0l5hMvAb0xFqzY3dDWQioxX9TY/w7i9SO9I?=
 =?iso-8859-1?Q?sdvHXs6Q6caVZOIAGekdOisea+GxOL6s0bZqQ2o5L8/HgMgfRRsM6NxhOz?=
 =?iso-8859-1?Q?pyLGCFA1seUtzSjpxDFrmzs7JOL9Zr9NyfyxPfJFbvi+Tk6zsz4PE5imIg?=
 =?iso-8859-1?Q?R2XKl9w90no/1PhHO2SalQARIY3GKN3IDagr76n3ZBjuDyHzxpP0WaVGWI?=
 =?iso-8859-1?Q?/U2nu+2KCg3bhsrgTG10sOSvaTGPLnMWLJI1WBTYH08pzWtDkiKw7W1rGp?=
 =?iso-8859-1?Q?lIpKQxaFM44I1xew6vzh0PZu25Ah8mI/k8h7vmT7mzETOtr2RWcv3XL3R8?=
 =?iso-8859-1?Q?W5CSyEEG3Hton0AUzxdyTdjKdnbpnnq9jJE7YLr7X5sWkVIL3UDeyKBxDF?=
 =?iso-8859-1?Q?mv3ThE/+JRr77o02wcvu0EkzYhb7E5ry3Q/WdPjdVBqk724eMUCRAPJKiG?=
 =?iso-8859-1?Q?SDI8kpTlEHMlffloa8oS4JSQ6ZFZbR6/rnKm96qF7dk1paMsMuWzX1pULL?=
 =?iso-8859-1?Q?r+v88JULUIZb5xxGEumu6Hu8DMhxrjT91n59iJKolpwsWrihQs+saf9Qj4?=
 =?iso-8859-1?Q?pM2nbaxO9iZXjemknJFJu7NbaQ0dgVRHRU/CvEoxQ2Pw/5pHOOqf6PlYEk?=
 =?iso-8859-1?Q?rO3ap/vLc26Rd7ClaHAz6v37Kkv6TbZ6WLsqxNPgbH87EsWJChcR43Dc4e?=
 =?iso-8859-1?Q?w4SszXlm+gDvb266wWX9rayorRt9m85WCukkIU9Uolw7sBTH043ffxkoIk?=
 =?iso-8859-1?Q?yy1yb7kox3NiyiElFoprxF/jyGIkoYDChEhD9qxCWEQEEoNYnqpLUwA4Uk?=
 =?iso-8859-1?Q?QsPwz4ECPmfjOlcg8bIgDiz3rwm7Mqr1Zzmr0Xc2Qs39Ly56ro1Fc3sgGa?=
 =?iso-8859-1?Q?QDfXqPqGKqieEnIuYQUEND4ibFcn48G8F8zLaXbZ4WMbjzjj12qHal1JdJ?=
 =?iso-8859-1?Q?DqSW0DGm9GbRhGO84zoYHqlifXM2J13V0CLF2kH//2VVYrEVbuADZfikmm?=
 =?iso-8859-1?Q?IDTIChBLfXslHhWatMNFVubkjsKoXL0sa7YtkAt1PZRjEw+em8ZrEFlBQA?=
 =?iso-8859-1?Q?uobLpz/93wFb65okUKsP2OzAlkFHy4NBc77xWtmpaGrgeaB+CEGJx+33fI?=
 =?iso-8859-1?Q?xpAN9Xk6TAzg0yTs7fRCImSKUgrf7OCYPggRtYkYNY6wg4EHxJlMYb1cmI?=
 =?iso-8859-1?Q?o=3D?=
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)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?tiefqtjWfc+Xu/T9pOIRh3dDY9xrp4fcJHepI6NKM47yMm1UQGBfBsIBG0?=
 =?iso-8859-1?Q?TJc1BUAc8VBRvgoyycF1EprtuIsS6jVCA5uT70fjw+354HwcXnidw5DE9L?=
 =?iso-8859-1?Q?HjBa3nGSWnfkMHcKbTXeADA7dRAHcuzkROaIbIXoxLEgrt2VtGZfD4Gxds?=
 =?iso-8859-1?Q?6DnKxRRqLiULS3u48XQ54ECgu0zqBUJQ5Hsedq8BBo3IPyeyrgUa2y4fRX?=
 =?iso-8859-1?Q?ztBI6idKaHrRfPIJhHKfnl/SFxZXYPxcozxAd4t9s0Rj1dLsIq8gxRmUN6?=
 =?iso-8859-1?Q?UreXamOccrXKODoPU+4lTUO2KUIeLGLYhVlmDTGHAZLUymKdrINuLFRYZF?=
 =?iso-8859-1?Q?nQVbiuUi91CWMfojNftvVlalff8C06NEqStXb2WEY781iSR+d+FCsUU8vY?=
 =?iso-8859-1?Q?LyGGr9DQc8d5BkBBGn+rK9nuPBzJ6xhVOQJwlEo/Ddazoxu8gxTrKHUb6D?=
 =?iso-8859-1?Q?E1tucwm3iSamWuZuXku5oY5EDik3KnTAcEZNz1fh46ZBNNvK1OjNAmanGv?=
 =?iso-8859-1?Q?dYZPfH8EP6+Xzead/IdzKLI9Ai6cP2DbdsngSbKt7Pi0Vn7t0S+VCOo8cd?=
 =?iso-8859-1?Q?nUn4F2xkK+844vpeBgsDe9fz1ct22kMF8/P04b/UumtWNMMexGjcKdUHCb?=
 =?iso-8859-1?Q?BklcutL7Cqq+IhSjvo385B/U2fSr4qck5YBm9YtL/3aGCVxyvuxZPAAVfW?=
 =?iso-8859-1?Q?gBSFsrp6Jd65rJLPoyrogzt9TanapHQs0X0eVGbhlGUAbMEOZ5hmiZr+2+?=
 =?iso-8859-1?Q?PI+hzxyfIKgdD04ldTbDP8UzgfKIHbKypbHTU3hd542ErvHMP+EzaUGp6b?=
 =?iso-8859-1?Q?8W6CfjPdP/cl7QGuZod72D+I73JiCTts0VksWSMNPlUONsPyDrcVzx7Bim?=
 =?iso-8859-1?Q?HlpMrjiPrZd0GZ6SMyBl7bNhUF2AuNcXTJAGKoVynDU8GwrpIGbqLp/KVW?=
 =?iso-8859-1?Q?F87mbWwdvjAcTUYmZXmqpUdutlco8fwCQmw1X1XWdKvjI1uOxnhyM7G7lE?=
 =?iso-8859-1?Q?PZjmpe+51PaDLoiXjY4o9kNl/o7aaazUYxYWSrGJ3itst6ZvVVRKWAVAgz?=
 =?iso-8859-1?Q?olBqzQE6hi2ZxDoiL34oHCmN0AB6AbzkewwvIzWcuHbhR/D71KlQxvjjKM?=
 =?iso-8859-1?Q?qXKwF59YF/O904jAJ8Ia0OUdkAHrQ3oMu9GX4QJmV1dtnXUylXI7Ek7/Zn?=
 =?iso-8859-1?Q?6zARrP6/ydQc0sS/sz5/c0is7VrNqyLmigR4ZD3nuPiAT/TMtFQ/FM8bTS?=
 =?iso-8859-1?Q?HRRJRicUV9e6Xf61OARQ5bwvy6kjfu8KI4B4iHx0mnrLmfpSmH3D4xojl6?=
 =?iso-8859-1?Q?u4SJAfk/eG5mk/iVIawg/kUCls9t5QuLZXmiO15bte76/f7G+vNA+WWDRj?=
 =?iso-8859-1?Q?waQLPELpvESGq4YhfqeI6fW2vnqHnbn7bh4JE+yVCPkmHANJw7vNN4QybN?=
 =?iso-8859-1?Q?EExRL8saYuyjXmNip37Kopqo634wlyk5/fiHlo1/pFJfYxyPGBK6kcUotc?=
 =?iso-8859-1?Q?ODjGqaZmzUxg7NwqrCY6R6Z7oXMLgsy6N4iSgS+qECOeSkMj2UCo6DkvQa?=
 =?iso-8859-1?Q?PeCM7ifeC9zCdARAgTb/NlW7jw4vWAPcfEfJxnwTAhfePeoyL+aVzkztea?=
 =?iso-8859-1?Q?+EIVOPeu0o2F/KkQQ1xSDdILRM9WBwf1V6juV8epodKGFkipioCq9Z1w?=
 =?iso-8859-1?Q?=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: d9456772-05d7-4c5d-5298-08dd9dc7bf71
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2025 09:12:18.5745
 (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: RfMMT7lZq3C466D0jWbiMqrybygFd81evx/wfuppOMSlqFghAPecR5eZDPzG6I1xndS21yY9z9GtDmS/f0yhpg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9709

From: Rahul Singh 

When ITS is enabled and PCI devices that are behind an SMMU generate an
MSI interrupt, SMMU fault will be observed as there is currently no
mapping in p2m table for the ITS translation register (GITS_TRANSLATER).

A mapping is required in the iommu page tables so that the device can
generate the MSI interrupt writing to the GITS_TRANSLATER register.

The GITS_TRANSLATER register is a 32-bit register, and there is nothing
else in a page containing it, so map that page.

Add new host_addr parameter to vgic_v3_its_init_virtual to prepare the
foundation for DomU MSI support where guest doorbell address can differ
for the host's. Note that the 1:1 check in arm_iommu_map_page remains
for now, as virtual ITSes are currently only created for hwdom where the
doorbell mapping is always 1:1.

Signed-off-by: Rahul Singh 
Signed-off-by: Stewart Hildebrand 
Signed-off-by: Mykyta Poturai 
Reviewed-by: Stefano Stabellini 
---
This patch was originally picked up from [1], and commit description
loosely borrowed from [2].

Example SMMUv3 fault (qemu-system-aarch64 virt model), ITS base 0x8080000:

(XEN) SMMUv3: /smmuv3@9050000: event 0x10 received:
(XEN) SMMUv3: /smmuv3@9050000:  0x0000000800000010
(XEN) SMMUv3: /smmuv3@9050000:  0x0000008000000000
(XEN) SMMUv3: /smmuv3@9050000:  0x0000000008090040
(XEN) SMMUv3: /smmuv3@9050000:  0x0000000000000000

Example SMMUv2 fault (AMD/Xilinx Versal), ITS base 0xf9020000:

(XEN) smmu: /axi/smmu@fd800000: Unhandled context fault: fsr=3D0x402, iova=
=3D0xf9030040, fsynr=3D0x12, cb=3D0

v10->v11:
* add Stefano's RB

v9->v10:
* map vITS doorbell to host ITS doorbell instead of always 1:1
* use simpler addr to dfn conversion

v8->v9:
* no changes

v7->v8:
* no changes

v6->v7:
* add tlb flush after mapping
* style: update formatting
* revert back to printk with XENLOG_G_ERR

v5->v6:
* switch to iommu_map() interface
* fix page_count argument
* style fixup
* use gprintk instead of printk
* add my Signed-off-by
* move to vgic_v3_its_init_virtual()

v4->v5:
* new patch

[1] https://lists.xenproject.org/archives/html/xen-devel/2023-07/msg00483.h=
tml
[2] https://gitlab.com/xen-project/people/bmarquis/xen-arm-poc/-/commit/623=
2a0d53377009bb7fbc3c3ab81d0153734be6b
---
 xen/arch/arm/vgic-v3-its.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index c65c1dbf52..bc738614bb 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -1445,11 +1445,13 @@ static const struct mmio_handler_ops vgic_its_mmio_=
handler =3D {
 };
=20
 static int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr,
+                                    paddr_t host_addr,
                                     unsigned int devid_bits,
                                     unsigned int evid_bits)
 {
     struct virt_its *its;
     uint64_t base_attr;
+    paddr_t host_doorbell_addr =3D host_addr + ITS_DOORBELL_OFFSET;
=20
     its =3D xzalloc(struct virt_its);
     if ( !its )
@@ -1478,6 +1480,26 @@ static int vgic_v3_its_init_virtual(struct domain *d=
, paddr_t guest_addr,
=20
     register_mmio_handler(d, &vgic_its_mmio_handler, guest_addr, SZ_64K, i=
ts);
=20
+    if ( is_iommu_enabled(its->d) )
+    {
+        mfn_t mfn =3D maddr_to_mfn(host_doorbell_addr);
+        unsigned int flush_flags =3D 0;
+        int ret =3D iommu_map(its->d, _dfn(PFN_DOWN(its->doorbell_address)=
),
+                            mfn, 1, IOMMUF_writable, &flush_flags);
+
+        if ( ret < 0 )
+        {
+            printk(XENLOG_G_ERR
+                    "GICv3: Map ITS translation register for %pd failed.\n=
",
+                    its->d);
+            return ret;
+        }
+
+        ret =3D iommu_iotlb_flush(its->d, _dfn(PFN_DOWN(its->doorbell_addr=
ess)), 1, flush_flags);
+        if ( ret < 0 )
+            return ret;
+    }
+
     /* Register the virtual ITS to be able to clean it up later. */
     list_add_tail(&its->vits_list, &d->arch.vgic.vits_list);
=20
@@ -1522,7 +1544,7 @@ int vgic_v3_its_init_domain(struct domain *d)
              * base and thus doorbell address.
              * Use the same number of device ID and event ID bits as the h=
ost.
              */
-            ret =3D vgic_v3_its_init_virtual(d, hw_its->addr,
+            ret =3D vgic_v3_its_init_virtual(d, hw_its->addr, hw_its->addr=
,
                                            hw_its->devid_bits,
                                            hw_its->evid_bits);
             if ( ret )
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 28 09:12:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:12:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999017.1379706 (Exim 4.92)
	(envelope-from )
	id 1uKCpn-0005pa-0h; Wed, 28 May 2025 09:12:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999017.1379706; Wed, 28 May 2025 09:12: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 1uKCpm-0005pQ-TI; Wed, 28 May 2025 09:12:26 +0000
Received: by outflank-mailman (input) for mailman id 999017;
 Wed, 28 May 2025 09:12:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCpk-00059a-R0
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:12:24 +0000
Received: from MRWPR03CU001.outbound.protection.outlook.com
 (mail-francesouthazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c207::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dd40b35a-3ba3-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:12:22 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DB9PR03MB9709.eurprd03.prod.outlook.com
 (2603:10a6:10:459::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Wed, 28 May
 2025 09:12:18 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8769.022; Wed, 28 May 2025
 09: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" 
X-Inumbo-ID: dd40b35a-3ba3-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KnuE9FVI7CzAuo78+eJagKveINYuphJAYBuW9+VTm6F5AIdXH4D1ckC2bKceO+ZOu6xyYVerH+X/cX4oonzEh1zGw1FTwGDB+tfrUb140Y9AEAJUaeZs2aJGf5/ZuAgfkJMjskRLiJmOnHF9Q3zNPywEHdZLZcoIyRBi0oSd0rmhIrrtjt3m1V5TBaJ87gUuOXUGCznvF9Y/NpKyVrtGX99hsniaCLnQE+KBPNQhWQcj/NrrzCsnXEi77sbb5D8zGcZRiTDl84JZKVk2h8+ZBW99gijjXliy6KDV/COMgVnsxRr4Sj2iJIPE6LJD23PAJDO5uSzrSzBTUV9Hpy+B1w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fzo1xbl87gBEcJrut/a4fYUJmfRPUormJMze4Lg6xzk=;
 b=Gky3hKKG1KW8tYfvJdaxdTgabypV9lbhsLRvAT2ckhhFOz+1Yn1v3erjmJoyKxeiUD/D1lb0kdcvjaAA8d2MwdOch6bt8HKOB7bvoGrfofWMP1/MsqiD5RHCTkvl6rrIij++i6Fm4sZI+qWz13UjeYNjqrSHKlzSLIQnh43OiQRGVZfa4zquoQ/dSkUTxpMt4eWMOKRg48RI7aFevVBtdvOxdWgaOCrQEMt2S12rkbFdG5sLugSKYwu1AtcFYJY91f+Zk5SHW1LScRnCAf5963IiX90o1e8uB22ldU64H8A1/PgQf1lvUCV6UB+y5XK9wGNqDZuuE5N02/b+7uj1Mg==
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=fzo1xbl87gBEcJrut/a4fYUJmfRPUormJMze4Lg6xzk=;
 b=dpfwAOSVU7NpJV2jvkYQV6fZZUuQwZHRFA0BY0+ed+276KwsGBLDVL2ZDlgMDJQaMnrk4ecF3BsRaOlrjoGuKFIDLsNY2szbkoDSq/8UgOPUC18HjZI0JOJ5bHUo5Af/EHkhIVgf95RNoTSIVnJgdFY+KqV5wGyoDkNnakL7Hqo2ff3pH0KIkAd4h6Orf+Gr2PmO2Ym3Gcg2cpHhhVg+a4B3Au+dID3H6UUxRN1OmJnC1AYoYAARp0WC/JD9vo/M2Qm8WG+9go7CvqGimvS8E6f5eAYanbrHGflLhSIFSjwvJ4W+y98gK5Ro3pIPMQe0ObvuL8PKX0XVodw9BhMHHw==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Rahul Singh , Bertrand Marquis
	, Stefano Stabellini ,
	Julien Grall , Michal Orzel , Volodymyr
 Babchuk , Stewart Hildebrand
	, Mykyta Poturai 
Subject: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for SMMUv3
Thread-Topic: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for
 SMMUv3
Thread-Index: AQHbz7Cb+Z/yNKbLOEOjir1VN7bH5A==
Date: Wed, 28 May 2025 09:12:17 +0000
Message-ID:
 <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.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: 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_|DB9PR03MB9709:EE_
x-ms-office365-filtering-correlation-id: b9ab53d4-a4a6-4f03-1b3b-08dd9dc7bedd
x-ld-processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?Icytq4DxlUARu2DpdADweVqcbnotW2wlX4Sd4fYI/ne/g4cImMkxRYDkmv?=
 =?iso-8859-1?Q?Mzyp5k6f25toNe73/WDChHNmT2Ecp93N7WkzbdnprZk5Xacpkd3n3ZHi6V?=
 =?iso-8859-1?Q?CdH8ltMimw1tD6qX5jvzfjo0jXifxyZDhkdvziRojZGDMr6r63bgzJ3oG6?=
 =?iso-8859-1?Q?NA74uauRSDAgqeHImVx3nS8buEi15kvcVALkiMCAH7RZDOP4GCLuaC87NO?=
 =?iso-8859-1?Q?XaZgktNqAownS6Qik090b4+T593Ssg0Ezmwh73fSHzHBFn+trhp1XAsFQV?=
 =?iso-8859-1?Q?xAy2ALBOBqYXnRF52VyA58VBtPUKxAwvAp7ad/HAAr0rR6pPY+aNAUBjAa?=
 =?iso-8859-1?Q?zNfgYdhIFg//2wwExqE7CXNe9RBxjt540QSaYMIlTB2SxcYlC9pwJ5ScN3?=
 =?iso-8859-1?Q?x27sKUKYTD0kpLpbAKwOdGvYKEnX45Y9TsmBGts2cJbCVyHpwzt/6bsLcN?=
 =?iso-8859-1?Q?BdxrJbBzCUQK9KwFOQLyvVPQ16mGAItyUe7imorzILesXZZh2J9fPuUIFq?=
 =?iso-8859-1?Q?xkPm+9sAyRq3Go9JeDpDk5PlIkJ/1EaKibD9FnMAvDohGGSn4+u+nEH5ZL?=
 =?iso-8859-1?Q?DuEJsXhIl3wMyJRHhdE+mFMgL4LTJkgjb/bgN3Oz9DuoiEVE6mFSfL1G5N?=
 =?iso-8859-1?Q?ZzwdCD6BNcRV2v8rG0jqcJhr5ZwY7Fiyc0Amq82mvaKTFGw8jz0oNJBPcs?=
 =?iso-8859-1?Q?d39lQfARfHq7tr5KDbVy8hiFxrsaIEosDE6OsNv+Tp7PQLkFIUv2642zk2?=
 =?iso-8859-1?Q?nsmwt35DkbrGb3TKt9SUFwrUxIU9CMBJlgf9QJtfTIz+pxNGh1k7EFQB9Y?=
 =?iso-8859-1?Q?ip3LEnHWF0rh/s9A4dnu4yftuaVhIqD292AIkRXXswADDs0yWzdHUUZ5MT?=
 =?iso-8859-1?Q?719kcu6gUoPeceMazLfuq8SSwN8nOes0pI0Zil5IdALMp+3zn+fwJ01fdO?=
 =?iso-8859-1?Q?T+OjI+wV6snOPwmX5bzFGyvMshdF1fkHMDPFivc3EnoXQEksX/bEHfjTfv?=
 =?iso-8859-1?Q?kUhAeTa8i0DtYKF3YIsXe38/ZhsiNVXg6mjMWK2xZ77LG60D8A5eKIdta8?=
 =?iso-8859-1?Q?uFa63Hp62E2LUfe7eQb4xhzGlkIrCAEm7KJGOPAHCfN4bauTnAtpZZzi39?=
 =?iso-8859-1?Q?zKMwskB5Di9owiaexvDyQZ+QOprH+ACZYRUHSPCC2ojru4pAfrrp6YHrkM?=
 =?iso-8859-1?Q?b6rHyZHLUUuMfeNepK/QrUpNiFkS0HNFf9BD6LDCdm5nWO4BJZzycsbKme?=
 =?iso-8859-1?Q?WZsOodnea9josITlNCVGXJLR5Znhtx579pBrahhFsN8VqOzwRXvSyxQ+hC?=
 =?iso-8859-1?Q?Wq6KoxYoSNOAXSnIqsl9/kTOSxccI9gPlftE8DHl2qmeVhLkT9IkoIbmMo?=
 =?iso-8859-1?Q?yqYkVdpxXeiX1k5wN27shpnSmQ3rvnsGibLsX6qfTUoCmxuvMJ1VOY3F1D?=
 =?iso-8859-1?Q?+n+XffBsZ8BDRAiURmBHnSO3f0PLtff0/RG558kB8FOTEMoDant3th4jX1?=
 =?iso-8859-1?Q?U=3D?=
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)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?EXJk9V4Aip0f9PXqrtViCSuC0IW0gHUqYbpYX8C8lortREjH5VokBfLQPK?=
 =?iso-8859-1?Q?L9lTurv6nRqgG5dNKZQt+kw+UTIwu/tQ2QRtbfHVjyYDonT8J2h+47zg54?=
 =?iso-8859-1?Q?kBtfYGK5qMwfVcNqE3PJbTedEVFdZ816iJbdQBido3SmO5UcTdJ11Efq12?=
 =?iso-8859-1?Q?QtANphTgVRTifkkvINU0X+DCd8Qhg4XwKt/w3bAGTEPWtl+FZWc3Pp37kV?=
 =?iso-8859-1?Q?s8+cOvsGTxNFZ8+vuaOQFC51Dip5fKOmPKJ+7LJtvydKFHNPJkFhnXVFbp?=
 =?iso-8859-1?Q?I1vhml4aGD1eDvvpcbcS82+nrKw1Qr7eihz8F/USB7XcPpDxBOBXJRuFt6?=
 =?iso-8859-1?Q?8HAS3HXGBcBB2dkZEJgNB7r62pXaA6de3jyi4KpoRhBny3DSMLBNAPFj5o?=
 =?iso-8859-1?Q?7aCuYxPmX2v8mZc6JdjTOIH2zJlMsT4FTOCG0ZMxK0Opvr80Pj+ZrbUA3T?=
 =?iso-8859-1?Q?oLJznU5TUSelmpl6JUmeoIqMk29N3YmginujpVbWQl/wzi1udznY0BxmXr?=
 =?iso-8859-1?Q?EurX5QWMg5OeiCDMTjfFvMJh9OBPJEjWxTA3Qi3l0ZOE/3vP268WLNERPJ?=
 =?iso-8859-1?Q?s/1ZKQKqWTPWCkOfBJTFrTcevw7nz8GxewRCTOlUG51qrwkB/ubEjmBU/P?=
 =?iso-8859-1?Q?I75lKdAOcjQBoHE6cZ4h/5G1jRR/PasroWLyY+B0VwmKWKv5iQjxkCqPGN?=
 =?iso-8859-1?Q?TTSRyMFPaWzOOfSProYZTkQJdqqyqr64nPNfHbXLEg8+Xvuk0lxHAO/XlW?=
 =?iso-8859-1?Q?xTqxs/GhTVvTpbwVeps0mu1nxrjxLzhzCgo84cauRoxRSyBEPR7H5BMnC1?=
 =?iso-8859-1?Q?n4OYAup/E2XP9GBCEOUJmnqbRvbw5OLSb54Uom1/9RWpGa9qXv+3gbebvO?=
 =?iso-8859-1?Q?gfdsgbNDRTTzLheIL+MPS2J/a889MPII+raTxj5WDfk1P5bBl1kpoajSly?=
 =?iso-8859-1?Q?4wIbyHbH56m9G7d3MYeUM9runjUZckIaWbcPvLDBPpWrd/xaPPblxyQiec?=
 =?iso-8859-1?Q?X1BtpmlkuzG9ItmaFUQNQ7JSxPTerHMjSI7m/9AJyLJmr6LapFRC4WMU9y?=
 =?iso-8859-1?Q?JGsDyx6rha7TM0snPAZEy/Wf8XbnkXCPRIeKqNFR7CKS11e7gqpIwFI2eF?=
 =?iso-8859-1?Q?eAihMWvM98Fu/5eenDCdVzYno+ovbLNvwphCVmlYnoITVh+THPSblzrrIy?=
 =?iso-8859-1?Q?uff/IYFfyJx+19jhy1k+omgsGwJENvToAH0bsaqbs0beMW4lhEDZQ+nDwr?=
 =?iso-8859-1?Q?rYh2udy4/ctO6sOPNgzNlzqzSJh92E2MQYA3u8b6Lhj5sUBTis0q1nxQvp?=
 =?iso-8859-1?Q?lmKj/swrB/vJzPABi6T6saxXJ797E5NR5iVuH2OSyv7FtXQAJNrC07c69d?=
 =?iso-8859-1?Q?MByoSdCXvVosDtvTIxLGTtJ5g0gq2o6W1Av3R4BbwThfc77BoNgkZ1EDJd?=
 =?iso-8859-1?Q?OoiDdScJC7C7lucbDlT6CtcQTaGHOhBDBr+KW+FP8t0rzz6UcxNwQQ8YRp?=
 =?iso-8859-1?Q?7tg0duVS1i+fRitn+0OqaXQX0Uo686lSvf5lxGzLBbVLdbxLB8SDXIKt0F?=
 =?iso-8859-1?Q?c4IjbxifhYihTq0R0VQ0G2i94G74jlsmf4ZyHrVDhHKJ7N0RgfyaKderl+?=
 =?iso-8859-1?Q?vfAPqMBUNLGqg+sGniqZxB8l1Qh95LAtK4wv7JXZ6ad8lrGUd+68SY5w?=
 =?iso-8859-1?Q?=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: b9ab53d4-a4a6-4f03-1b3b-08dd9dc7bedd
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2025 09:12:17.5309
 (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: jI5T/KtBMw1uwqficforT4JyvLhqGM/bdDXD1GHs4KBMzLHXYZ2mmauZQamFNXaxAxS5kSatLZZT+hwKFnPR0g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9709

From: Rahul Singh 

Implement support for PCI devices in the SMMU driver. Trigger iommu-map
parsing when new PCI device is added. Add checks to assign/deassign
functions to ensure PCI devices are handled correctly. Implement basic
quarantining.

All pci devices are automatically assigned to hardware domain if it exists
to ensure it can probe them.

TODO:
Implement scratch page quarantining support.

Signed-off-by: Rahul Singh 
Signed-off-by: Stewart Hildebrand 
Signed-off-by: Mykyta Poturai 
---
v10->v11:
* no changes

v9->v10:
* return if iommu_add_pci_sidband_ids fails

v8->v9:
* no change

v7->v8:
* no change

v6->v7:
* address TODO: use d->pci_lock in arm_smmu_assign_dev()
* remove !is_hardware_domain and pdev->domain =3D=3D d checks in assign to
  support future dom0less use case when dom0 is using vPCI
* check if pdev->domain exists before assigning to it
* don't print ""
* change assign logic to remove reassign reimplementation
* explain pdev->devfn check
* make reassign check stricter and update comment

v5->v6:
* check for hardware_domain =3D=3D NULL (dom0less test case)
* locking: assign pdev->domain before list_add()

v4->v5:
* deassign from hwdom
* add TODO regarding locking
* fixup after dropping ("xen/arm: Move is_protected flag to struct device")

v3->v4:
* no change

v2->v3:
* rebase
* invoke iommu_add_pci_sideband_ids() from add_device hook

v1->v2:
* ignore add_device/assign_device/reassign_device calls for phantom functio=
ns
  (i.e. devfn !=3D pdev->devfn)

downstream->v1:
* rebase
* move 2 replacements of s/dt_device_set_protected(dev_to_dt(dev))/device_s=
et_protected(dev)/
  from this commit to ("xen/arm: Move is_protected flag to struct device")
  so as to not break ability to bisect
* adjust patch title (remove stray space)
* arm_smmu_(de)assign_dev: return error instead of crashing system
* remove arm_smmu_remove_device() stub
* update condition in arm_smmu_reassign_dev
* style fixup

(cherry picked from commit 7ed6c3ab250d899fe6e893a514278e406a2893e8 from
 the downstream branch poc/pci-passthrough from
 https://gitlab.com/xen-project/people/bmarquis/xen-arm-poc.git)
---
 xen/drivers/passthrough/arm/smmu-v3.c | 119 +++++++++++++++++++++++---
 1 file changed, 108 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthroug=
h/arm/smmu-v3.c
index df16235057..a3bbfda993 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -1469,14 +1469,37 @@ static bool arm_smmu_sid_in_range(struct arm_smmu_d=
evice *smmu, u32 sid)
 }
 /* Forward declaration */
 static struct arm_smmu_device *arm_smmu_get_by_dev(const struct device *de=
v);
+static int arm_smmu_assign_dev(struct domain *d, u8 devfn, struct device *=
dev,
+			       u32 flag);
+static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn,
+				 struct device *dev);
=20
 static int arm_smmu_add_device(u8 devfn, struct device *dev)
 {
 	int i, ret;
 	struct arm_smmu_device *smmu;
 	struct arm_smmu_master *master;
-	struct iommu_fwspec *fwspec =3D dev_iommu_fwspec_get(dev);
+	struct iommu_fwspec *fwspec;
+
+#ifdef CONFIG_HAS_PCI
+	if ( dev_is_pci(dev) )
+	{
+		struct pci_dev *pdev =3D dev_to_pci(dev);
+		int ret;
+			=09
+		/* Ignore calls for phantom functions */
+		if ( devfn !=3D pdev->devfn )
+			return 0;
+
+		ret =3D iommu_add_pci_sideband_ids(pdev);
+		if ( ret < 0 ) {
+			iommu_fwspec_free(dev);
+			return ret;
+		}
+	}
+#endif
=20
+	fwspec =3D dev_iommu_fwspec_get(dev);
 	if (!fwspec)
 		return -ENODEV;
=20
@@ -1521,17 +1544,38 @@ static int arm_smmu_add_device(u8 devfn, struct dev=
ice *dev)
 	 */
 	arm_smmu_enable_pasid(master);
=20
-	if (dt_device_is_protected(dev_to_dt(dev))) {
-		dev_err(dev, "Already added to SMMUv3\n");
-		return -EEXIST;
-	}
+	if ( !dev_is_pci(dev) )
+	{
+		if (dt_device_is_protected(dev_to_dt(dev))) {
+			dev_err(dev, "Already added to SMMUv3\n");
+			return -EEXIST;
+		}
=20
-	/* Let Xen know that the master device is protected by an IOMMU. */
-	dt_device_set_protected(dev_to_dt(dev));
+		/* Let Xen know that the master device is protected by an IOMMU. */
+		dt_device_set_protected(dev_to_dt(dev));
+	}
=20
 	dev_info(dev, "Added master device (SMMUv3 %s StreamIds %u)\n",
 			dev_name(fwspec->iommu_dev), fwspec->num_ids);
=20
+#ifdef CONFIG_HAS_PCI
+	if ( dev_is_pci(dev) )
+	{
+		struct pci_dev *pdev =3D dev_to_pci(dev);
+
+		/*
+		 * During PHYSDEVOP_pci_device_add, Xen does not assign the
+		 * device, so we must do it here.
+		 */
+		if ( pdev->domain )
+		{
+			ret =3D arm_smmu_assign_dev(pdev->domain, devfn, dev, 0);
+			if (ret)
+				goto err_free_master;
+		}
+	}
+#endif
+
 	return 0;
=20
 err_free_master:
@@ -2624,6 +2668,42 @@ static int arm_smmu_assign_dev(struct domain *d, u8 =
devfn,
 	struct arm_smmu_domain *smmu_domain;
 	struct arm_smmu_xen_domain *xen_domain =3D dom_iommu(d)->arch.priv;
=20
+#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());
+
+		write_lock(&pdev->domain->pci_lock);
+		list_del(&pdev->domain_list);
+		write_unlock(&pdev->domain->pci_lock);
+
+		pdev->domain =3D d;
+
+		write_lock(&d->pci_lock);
+		list_add(&pdev->domain_list, &d->pdev_list);
+		write_unlock(&d->pci_lock);
+
+		/* dom_io is used as a sentinel for quarantined devices */
+		if ( d =3D=3D dom_io )
+		{
+			struct arm_smmu_master *master =3D dev_iommu_priv_get(dev);
+			if ( !iommu_quarantine )
+				return 0;
+
+			if ( master && master->domain )
+				arm_smmu_deassign_dev(master->domain->d, devfn, dev);
+
+			return 0;
+		}
+	}
+#endif
+
 	spin_lock(&xen_domain->lock);
=20
 	/*
@@ -2657,7 +2737,7 @@ out:
 	return ret;
 }
=20
-static int arm_smmu_deassign_dev(struct domain *d, struct device *dev)
+static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn, struct d=
evice *dev)
 {
 	struct iommu_domain *io_domain =3D arm_smmu_get_domain(d, dev);
 	struct arm_smmu_xen_domain *xen_domain =3D dom_iommu(d)->arch.priv;
@@ -2669,6 +2749,21 @@ static int arm_smmu_deassign_dev(struct domain *d, s=
truct device *dev)
 		return -ESRCH;
 	}
=20
+#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;
+
+		/* dom_io is used as a sentinel for quarantined devices */
+		if ( d =3D=3D dom_io )
+			return 0;
+	}
+#endif
+
 	spin_lock(&xen_domain->lock);
=20
 	arm_smmu_detach_dev(master);
@@ -2687,14 +2782,16 @@ static int arm_smmu_reassign_dev(struct domain *s, =
struct domain *t,
 {
 	int ret =3D 0;
=20
-	/* Don't allow remapping on other domain than hwdom */
-	if ( t && !is_hardware_domain(t) )
+	/* Don't allow remapping on other domain than hwdom
+	 * or dom_io for PCI devices
+	 */
+	if ( t && !is_hardware_domain(t) && (t !=3D dom_io || !dev_is_pci(dev)) )
 		return -EPERM;
=20
 	if (t =3D=3D s)
 		return 0;
=20
-	ret =3D arm_smmu_deassign_dev(s, dev);
+	ret =3D arm_smmu_deassign_dev(s, devfn, dev);
 	if (ret)
 		return ret;
=20
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 28 09:12:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:12:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999015.1379686 (Exim 4.92)
	(envelope-from )
	id 1uKCpk-0005NP-DR; Wed, 28 May 2025 09:12:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999015.1379686; Wed, 28 May 2025 09: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 1uKCpk-0005NI-At; Wed, 28 May 2025 09:12:24 +0000
Received: by outflank-mailman (input) for mailman id 999015;
 Wed, 28 May 2025 09:12:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCpi-00059a-Qq
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:12:22 +0000
Received: from MRWPR03CU001.outbound.protection.outlook.com
 (mail-francesouthazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c207::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dc5baeb4-3ba3-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:12:21 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DB9PR03MB9709.eurprd03.prod.outlook.com
 (2603:10a6:10:459::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Wed, 28 May
 2025 09:12:17 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8769.022; Wed, 28 May 2025
 09:12: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" 
X-Inumbo-ID: dc5baeb4-3ba3-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IEtRd6Gj4QlKRM7jyTX9sNrXe4sLnRQpDqL1BUX1nhGohEXVyZdkIA+f6/eam2Kbq4yStI7vUZ85+KVTsu7giP9Xy8hXF6Yc9vfRIbG6gyJELIjzI4yZVz8yPo4JoejerUOU3kalZ2zpFOVgSdkWPHWy0cEsfSyHVXb8LOPRvFTNApwSIxg9fHPwL0HZBbZYTqwVCJ5rWg748A+VEgbBOXjVkvlTwQ9Tmdz7SYMYikS2ECkw/6pDWxclmK7XTfpm3k+B4u1jwTFMh5cytghF33T6GZaJ0mkXPgdh39VlPfqWTOdljze8bYkTsw5paXvbuNqHYV6hsHKR55oez5g8tw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bW09ij8yDtDHNbRk6iUPyTmNx4K+9cPqlktw8aDZDTE=;
 b=OwXBnl3L4BBRNpbpwKa9aONlmR0VTaYBAFHcXtZql9VMM1rzp3BL2zZuyeQNfhU+O/U6VVINnMKmkVnFQ+Ki2yFesy91+F0IS7xaAHC55sQ5yWlMHln7FcQmzKk54PeMTtcmdUcE42pkp6kAghT6ElYeV1lV1xHAgvbtFXtsPFjAv64P7yml4XVbzjfgG8XS8nYopwyl5Nf728bGztAVff9DHbjyUc+B6LOtbaka5ufHY1k2TACVZbU8uqc2S2rcBMFBdNX4HodJcUzC+yql/5wjUkgn7rubz0qnvf1LB2lSipXRBs3hr/gng0d2KdELxMPRvygBvsGJ8apcYSRpwg==
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=bW09ij8yDtDHNbRk6iUPyTmNx4K+9cPqlktw8aDZDTE=;
 b=X9Xp23zn9nxyQtIHTY+oDZWRE7GrqCRH/kXqYHjlpviLp6gsi52xqySC7aj1szpWeyRsD+0Nbdy4L0bCT3MbwIEMwzzYzUDpf5MLdOk2nTSQqGWGtzGGc6N1e81xfIkTtBTOfUnoQK4suva5vZ++/azWwXn1JNoZIet0tu8SvCbRHMexOuJSm/hEysIqU6yPptOaJZzBHZOSAysk23VWLLSh17vSgMgWg3CkBwLFlEygaEJr+UbPhCMmOzZyuvAmFXU0oBLP3etTRselTXplnmpncggtETo773RfQ7PiWR9xgO+WMjdc67Drf+ng6HQTkyDa2GENR+3XUXuoxZpFUA==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Stewart Hildebrand , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel 
Subject: [PATCH v11 2/7] iommu/arm: iommu_add_dt_pci_sideband_ids phantom
 handling
Thread-Topic: [PATCH v11 2/7] iommu/arm: iommu_add_dt_pci_sideband_ids phantom
 handling
Thread-Index: AQHbz7CbWtgUmPL5TUS+FvDNVVe4iw==
Date: Wed, 28 May 2025 09:12:16 +0000
Message-ID:
 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|DB9PR03MB9709:EE_
x-ms-office365-filtering-correlation-id: c98dc491-a5aa-47af-41e4-08dd9dc7be86
x-ld-processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?B4nvQOnWMgxK75Aaa7rXHtyjt7VyfQrXQfbFCbD3hdgBXrMkcC2QF38CbB?=
 =?iso-8859-1?Q?zvG1YCae9/1PR06dIaS+qZ9pgK03+IFb4nLSAi9AznYE8kw444EQTcSj87?=
 =?iso-8859-1?Q?NNjz1R77hamS8Kpo3Kwf1cze105p7SNrWARX8l6O/CImL+CbrCuLLOTdue?=
 =?iso-8859-1?Q?faE0Tso5rcJDIEBsTw1lg9zXabp+Jiv7vwHhRE415GcRlSO9ONbaVaTXS1?=
 =?iso-8859-1?Q?wsSf6zg0MbfyMS/kQA6kPTV/KFfUK1RYnX8CNJdFmxLdmtJttq6ae0Ic1f?=
 =?iso-8859-1?Q?fQc3uWuk0fpcNtrqkHR0+KUYVOn1l9i8GHacVF4oEBwvKNrEQeGTGjJ6t8?=
 =?iso-8859-1?Q?uqtKsDlvO3ycLzTzrLWKTX6PhFfHU/EwfnCJBX5YpXxGsA/RRknbk8y2Ur?=
 =?iso-8859-1?Q?ca1cApv4nlJUBWh7vGeov11F/7QjN5KU656vdIl5Cgg8OG+UDApazHdThH?=
 =?iso-8859-1?Q?pI6epXRX3p7Gpm2AJ3Byy/rRa/yvS16brzoy287/QqNlNNE5uWIS4j6MPF?=
 =?iso-8859-1?Q?OSej46rL9XgNNMFg9cSn7uK9S3qiV1VL6eSp7440D57OIKSNqmDKc8xeci?=
 =?iso-8859-1?Q?vNutf9yIpyq9+asBsxLS128iD4RbPhLTJzAKxkptnuLC0WMWOUyvm+p5AQ?=
 =?iso-8859-1?Q?Gxd1Saje1Ai37vWCH/hwqK5suRcGuI2BatsyVhvAI9jb+AsKTfYYGj0dwj?=
 =?iso-8859-1?Q?aF6vl6I3rER2ZM+TjVkat0KVm2VT+3g9oBOYkt0gwYym7vrx46qcAoV87o?=
 =?iso-8859-1?Q?amqT5lWjahY+LmyVAnJFbfvwEytyk8e+DQxIXewV7Al1D+zGfBNpgjnvVZ?=
 =?iso-8859-1?Q?WpsVOMjYXpAKMM/F6caAA367XBtct56nWDlh1w0iD47WVSIrbtRoUkLlaE?=
 =?iso-8859-1?Q?3HcQjW6/LxuZ6zOotu2M4IQDnOC9HWznuUZ99WhroXUAdYDEVdgyM1o80B?=
 =?iso-8859-1?Q?sfFJh2wWVYbDsnjOwf8frYR+Y0JE4iZYfiLZi8526S5dHb2IulnLP6B4z0?=
 =?iso-8859-1?Q?MPoojXpzbsA/l03wWVd9STjAtQiWQ+dM1CEVxjwzEw0iRjHJmV1Y//w9Bp?=
 =?iso-8859-1?Q?9EvEcvN5whFelES5DX2k9srcD2woSELJNZaLnF5LsyeIOodgsaYUnsXVpG?=
 =?iso-8859-1?Q?xCCayncvZmKMFBxbIkr1lODMs/RuDHHmuWHlmHXGimDxBf9MK7gAv0Bb72?=
 =?iso-8859-1?Q?tmZndy+fJmbfbrFxck9+vcvwRwmZYpvGZ/09oTMZHLpzLEcq85n3SNYmjy?=
 =?iso-8859-1?Q?odoaDL40CB6/He29XaZV6dk3Kqg5DxinszX4Bc87MrQigoIqLl9Cc1VBwS?=
 =?iso-8859-1?Q?Fwl2Y/ZjyZ4Poh15wAiMahLlNC03+/Z6454KTC4aWDri+SnjUk+SP4UlFv?=
 =?iso-8859-1?Q?xGUuW3jPbRf3uxFpoi3QJpp1dRQNTHdNrGpnmzr7T47fp6dL0c8hwf32aM?=
 =?iso-8859-1?Q?vUleHKMzohGrYaBKA+7hJzlOSETni5/oSdyU2dTmXIkLXqwZiObD+H3KXW?=
 =?iso-8859-1?Q?Ay/xn5DOfPpXJGWWdbJ3Be+s6wjZkLbp1/LZV6vXqxy7Kz87vPnZjF5Yml?=
 =?iso-8859-1?Q?6CBlC5M=3D?=
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)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Xnavr1p3tSJOB42AElEeJIgtGAlvPrB6Ou5uI6QWJxfNwjhjQmgkl2F2jc?=
 =?iso-8859-1?Q?Vij4oOT/MY0TVCJ3FzUkaT56KusVYl6PrvQNmbvf6CD03PuGr5PyJcIRFB?=
 =?iso-8859-1?Q?9PECtgKC9QZEkKPfNg76QzY2yvv710/rOVL9olSCTHOAbNzMJEsfjyf+TT?=
 =?iso-8859-1?Q?aCtHbPCNC+778LgFR2HScktN6/06F1O2kk/tWM64xp3kZiVgghQvU8/HZ5?=
 =?iso-8859-1?Q?liDnVTYXwYcOopQtiKiYYbgl4LDy45F8hIGYP3I8f1hwgAnyDgXCyR3YTA?=
 =?iso-8859-1?Q?hYgA7j1XG9QpwL4Y+kpEqnZUB8jOSMLFzhbLFEqGM4ygEGCmrFD2PL3/b+?=
 =?iso-8859-1?Q?yUnKIPUHTSsvS6eUjoA9NGQOWYQq4ttAtWvME665ocLmYCNcA0jbe+bMZ4?=
 =?iso-8859-1?Q?6khVqLEhs1h2X3iaWIdkL7p9t3JDDwIvPxww1U7tTbxuEND0ceRB/p00Gi?=
 =?iso-8859-1?Q?zTY8LxfLMoE7Mlwu64b1b48XN/eK2ITXBgO1xzCvqPmJrAVX6tL9BLMRA7?=
 =?iso-8859-1?Q?XCwL/2edRpqCdMR3hJH8REp6r+VUEao3bT8xXB+uQZRNIoIsParO34Kgkp?=
 =?iso-8859-1?Q?W1iDf0hXkebcXf+PzHLaUbJ+45C+KQCei7iAAToreknM7gItuppIjThRHe?=
 =?iso-8859-1?Q?9J1eXjX/K0Bh/QWc61q15sPuU/3NcePE13sBotzh4f8hSigTicEWZG6WB3?=
 =?iso-8859-1?Q?p3KVoQLxq0pSeEwRugM/IACB5rHltKWvtN5i9ys0T4+RYW3V+v4S+gG2QM?=
 =?iso-8859-1?Q?G+x8PD47xLH8VzLIRByJi9aun9wJYWMCu9TyH3p6cTyfFdo8RqBQkHlRWx?=
 =?iso-8859-1?Q?KrB6PgnhGYsH7juebNTD2NgAGCxH/fuyMXr9EXoZynwUnH/FOXTN395fZN?=
 =?iso-8859-1?Q?KSYlWhRJRFpv6ft4wBQQd8jYAC/L3jQ4uTSUvFNsVnywiQrhXFVt0FrYBn?=
 =?iso-8859-1?Q?jkpMd/YzubTRIOKK9TgQsLAA6e/5AYdCUDuqHgbn9itRzsWmTPKa89Z3e8?=
 =?iso-8859-1?Q?UwSiJqbnvLkhmBDOUoijKpEDhnbx0vypGwJSfRUK/FWBah0T3BFgeRT3tk?=
 =?iso-8859-1?Q?bij97n1+RfFmz/8LxPnLqeLCtM8dZt4CLsS6qZJwiEG2UTpknhTvKU66zY?=
 =?iso-8859-1?Q?JPq9eiAldzHNjbT6OAGpOZ/QupvfcrnX31D9pZy1My07XqqGz+KKjtyS37?=
 =?iso-8859-1?Q?w5OaSRcWqH9WTchF3yGROePGZYb19Y/5hfADecPTFJHVBL4HWyXkLswcbZ?=
 =?iso-8859-1?Q?Otc3h1KwEjV1zK1stoX73RywgJYu4oBTpX+pXFz3R+X47M4DurnQ4p8icE?=
 =?iso-8859-1?Q?LhZuHM5tbVoPY3wDcCG+VbXTSYdyhm5dYJOsbVzks+0lfMVVoyBYrxE7gV?=
 =?iso-8859-1?Q?+hboMfsYknQ9wrqEZ8x+uhj/cgrC5Hs9ZrDG+1iJDXpCRMdbuizsuakJ13?=
 =?iso-8859-1?Q?+rbLJx8Eupdicsc+s7iqWVvfBf6cBPlxuFg1i04VFkRoX2NC3bJmQZ3RiB?=
 =?iso-8859-1?Q?CIefKvBiJNwqWa7fPHmb1TPHHW2aF20JZsrDOQrBxAhvnlkfbvPbYJz+3B?=
 =?iso-8859-1?Q?9rx8gsUB+Z1LQfWxPfswwqKl+onDBJnPEgJbDl1K/ZHzx/q8NaC6yee4Qe?=
 =?iso-8859-1?Q?n5M4d87zkzHydwsmXPGst6rKoR3znn48wQkVLW+muihG3yCuZcKV8JLw?=
 =?iso-8859-1?Q?=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: c98dc491-a5aa-47af-41e4-08dd9dc7be86
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2025 09:12:16.8151
 (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: XqZNdbhDpwnYXllg2pi7t85ojxA395oDVTEGX1RMfssUS2Ls4kOzUgSO5jgtn4OdE0KZ6/feVzIfRmU6ttp/TQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9709

From: Stewart Hildebrand 

Handle phantom functions in iommu_add_dt_pci_sideband_ids(). Each phantom
function will have a unique requestor ID (RID)/BDF. On ARM, we need to
map/translate the RID/BDF to an AXI stream ID for each phantom function
according to the pci-iommu device tree mapping [1]. The RID/BDF -> AXI stre=
am ID
mapping in DT could allow phantom devices (i.e. devices with phantom functi=
ons)
to use different AXI stream IDs based on the (phantom) function.

[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/pci/pci-io=
mmu.txt

Signed-off-by: Stewart Hildebrand 
Reviewed-by: Stefano Stabellini 
---
v10->v11:
* no changes

v9->v10:
* Add Stefano's RB

v8->v9:
* replace DT_NO_IOMMU with 1

v7->v8:
* no change

v6->v7:
* no change

v5->v6:
* no change

v4->v5:
* no change

v3->v4:
* s/iommu_dt_pci_map_id/dt_map_id/

v2->v3:
* new patch title (was: iommu/arm: iommu_add_dt_pci_device phantom handling=
)
* rework loop to reduce duplication
* s/iommu_fwspec_free(pci_to_dev(pdev))/iommu_fwspec_free(dev)/

v1->v2:
* new patch

---
TODO: investigate Jan's comment [2]
[2] https://lore.kernel.org/xen-devel/806a2978-19fb-4d31-ab6a-35ea7317c8de@=
suse.com/
---
 xen/drivers/passthrough/device_tree.c | 33 ++++++++++++++++-----------
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthroug=
h/device_tree.c
index 37e1437b65..f5850a2607 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -169,6 +169,7 @@ int iommu_add_dt_pci_sideband_ids(struct pci_dev *pdev)
     struct device *dev =3D pci_to_dev(pdev);
     const struct dt_device_node *np;
     int rc;
+    unsigned int devfn =3D pdev->devfn;
=20
     if ( !iommu_enabled )
         return 1;
@@ -183,21 +184,27 @@ int iommu_add_dt_pci_sideband_ids(struct pci_dev *pde=
v)
     if ( !np )
         return -ENODEV;
=20
-    /*
-     * According to the Documentation/devicetree/bindings/pci/pci-iommu.tx=
t
-     * from Linux.
-     */
-    rc =3D dt_map_id(np, PCI_BDF(pdev->bus, pdev->devfn), "iommu-map",
-                   "iommu-map-mask", &iommu_spec.np, iommu_spec.args);
-    if ( rc )
-        return (rc =3D=3D -ENODEV) ? 1 : rc;
+    do {
+        /*
+         * According to the Documentation/devicetree/bindings/pci/pci-iomm=
u.txt
+         * from Linux.
+         */
+        rc =3D dt_map_id(np, PCI_BDF(pdev->bus, devfn), "iommu-map",
+                       "iommu-map-mask", &iommu_spec.np, iommu_spec.args);
+        if ( rc )
+            return (rc =3D=3D -ENODEV) ? 1 : rc;
=20
-    rc =3D iommu_dt_xlate(dev, &iommu_spec, ops);
-    if ( rc < 0 )
-    {
-        iommu_fwspec_free(dev);
-        return -EINVAL;
+        rc =3D iommu_dt_xlate(dev, &iommu_spec, ops);
+        if ( rc < 0 )
+        {
+            iommu_fwspec_free(dev);
+            return -EINVAL;
+        }
+
+        devfn +=3D pdev->phantom_stride;
     }
+    while ( (devfn !=3D pdev->devfn) &&
+            (PCI_SLOT(devfn) =3D=3D PCI_SLOT(pdev->devfn)) );
=20
     return rc;
 }
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 28 09:12:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:12:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999021.1379743 (Exim 4.92)
	(envelope-from )
	id 1uKCpq-0006gX-LH; Wed, 28 May 2025 09:12:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999021.1379743; Wed, 28 May 2025 09: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 1uKCpq-0006eI-GB; Wed, 28 May 2025 09:12:30 +0000
Received: by outflank-mailman (input) for mailman id 999021;
 Wed, 28 May 2025 09:12:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCpo-00059a-SB
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:12:28 +0000
Received: from MRWPR03CU001.outbound.protection.outlook.com
 (mail-francesouthazlp170110003.outbound.protection.outlook.com
 [2a01:111:f403:c207::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dedad733-3ba3-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:12:25 +0200 (CEST)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DB9PR03MB9709.eurprd03.prod.outlook.com
 (2603:10a6:10:459::22) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Wed, 28 May
 2025 09:12:18 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%4]) with mapi id 15.20.8769.022; Wed, 28 May 2025
 09: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" 
X-Inumbo-ID: dedad733-3ba3-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZFN5DZovh7IEAGJJ1pjeE5TUtHID5rFNren6IHyw3Y7LByhgx8xrmrhXrW3lWQ74hkAjXnYGvHIHKik0ONZEM5Eq0GgibNtuGdF+zAsGdgUIVwSapeXwURqgzxR1L2FhIgxQU6nYTAno/JnGN/m6Ghi2CbAU7OT3oheTfgxwb/Rlw9NlPB9UQEhtURMIQ6y31Sy13GQtu+D5GRqyluX5yqddFFdDIhkJVpYUSSAxyFl8AUW7UCswxxn6WBBovOQfhhgyxOTd0iUfSzju6PCx8xWJcA1AcnOCHlERjxWFAVrs1MMmio0scgNqfQXvbMLU31HmGQWZzU0jeRYbQ9q/LA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2hJipxXtGS84tqPWWkGQID4DWS/WfVqz4LfOOuxpUoY=;
 b=xZ2NVzpRHCOhl6GV3vyj8G8moJXTdyqiLZ2zCgSaFwFtl9SUmYKmpWN8Ky6FPm/mBtyN3VSel5cBpcKJbVIfD7wluvoTpu6Ko1q9PHwlmwI7YY4L91IhkjSXMXlJS0E07LmOEKxpiQ+P7yI3L3dBQiFxu5OIhGSjSa2NcKuQ+wxd+KFVro7XARsaSaoXFOASiaaJFycpHofenX5HWm+HdeHjOozuR5MOqKGwrRv+iXgswke0N6/H5nHHUvCLLAZ/c/H1/7fELQxAq73JVdgWI4K7sihIO3wDBZijcxMCpXqCaDAda/NXvW7DoQEEaxvC4oRekELMdB8xQ+8ioRhcgQ==
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=2hJipxXtGS84tqPWWkGQID4DWS/WfVqz4LfOOuxpUoY=;
 b=VQNFbRxdGIvHvKZj81sp9IU5asMYTBMjH9zOjeIPEjs7BCM3kUd4q0vBTFagd2P7bz1oWQ3PiUrSOE6mSDj94a7+ricit2LNFckqWWg/Xave7L3gRU/tbPWheM1ej1xOvbAeiLNPRk0UEeYwBDb1z67ZKFzRWwwAuZfRjAHUCKGvy4pyC6L61FVytcNib2B4bJb5xBkic61twpDuew0zPV6IqxLnsjHUiin7xs5jqbqXr4LjekbCfi14wLlEEhVegxPzVTwtDCwfkju1xsnLkCjHA4/yo8W4BXCK0jV1MjRIYJ6rNRA/lbzvK9QJU2kAlzUjJP2ql9/S4nZDOw/Bug==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Rahul Singh , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk , Stewart Hildebrand
	, Julien Grall 
Subject: [PATCH v11 5/7] xen/arm: Fix mapping for PCI bridge mmio region
Thread-Topic: [PATCH v11 5/7] xen/arm: Fix mapping for PCI bridge mmio region
Thread-Index: AQHbz7CcY3xN8amw40aBS5pduG3+AQ==
Date: Wed, 28 May 2025 09:12:17 +0000
Message-ID:
 <90bbde388d0a5ce445c16058fcc619206cc7d0f1.1748422217.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: 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_|DB9PR03MB9709:EE_
x-ms-office365-filtering-correlation-id: 4ef80455-f45c-4c15-f60f-08dd9dc7bf17
x-ld-processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?uI2D2sv6SM+ShFQXvoArRZu/zccy64K82035vcm5/bwDrwgWNY5AVakf1O?=
 =?iso-8859-1?Q?jISS/vE4gO3HtE5frMry4tO1HYMgJOWI1jEd0l4T/g9T0H3VKfMkCi9sdR?=
 =?iso-8859-1?Q?Hymwu3pTNYUywSnMydWr3BBlGIgH+9ipuzDoKMaM8ahb7gjANiKrCwZ5Ef?=
 =?iso-8859-1?Q?EDRrxv7x554wbnu2YIZKoCi6eCb5V3Y3whiS9KTHXXtlX4oKeO4KjNVEzp?=
 =?iso-8859-1?Q?yAq97YGdWoulcE6HyAAVrUdMn/MeNZoecWgffybd3JjuaB4fb02ngFQvq6?=
 =?iso-8859-1?Q?aZmMZ18ySR7XReFFrjYYyjCKNtSXAUORo4LSt3KbUgOtjgL/UkZGUZoCod?=
 =?iso-8859-1?Q?WN57Wh3YCaOhVCXPk6zoqTgIPTUDKuarpwxjsLkivkVvFUlWe10AitFMOZ?=
 =?iso-8859-1?Q?j4OSZ9BTdWeO12e0KNQgBhLy4Z7YZThShyUlUZzNVNGnyWuq3uJxXjQ5HR?=
 =?iso-8859-1?Q?nG2VOZw4pqagNZn3XKamI69J9Gh8OoIADCmSzSyUyTiU+5VYbMsSzwBkRN?=
 =?iso-8859-1?Q?pesunpKtb7l+NboBsk0cpKU3Tw/C5hqaDj3zHPfa5uHUf9RYQECAmoiDHu?=
 =?iso-8859-1?Q?Nyd2Due7+dUZC+J6XX1uPeDoyaVUB69AehEYUnEMcAVPvATn/gsxcILo9C?=
 =?iso-8859-1?Q?PM038P7k12dQeCu57ctSNhF3CtT1o4gW7sxFxnPFbz/l981aKa6dt5nl+2?=
 =?iso-8859-1?Q?0YGSQhqr1AIFMAJPT9mcOreiA5/Q7K8xszJmGcUBsE66GpDzo7K+kBuyZT?=
 =?iso-8859-1?Q?3ZoBMN11E2+55slW330OCWv01/1Gc/bkF3rOVJL1sxfu++3Q3a4gF34xbp?=
 =?iso-8859-1?Q?WtDYZm/gZet3Cv0FEqKpiv8ZO8XrhveOsxwjTcuID4WTqKXFfBkPxb5m7O?=
 =?iso-8859-1?Q?iKaN8HKfmB/4qdvxLg/S3Cn6iTIMEexwiIPwOwG3PCuJfmwejveaesF2lo?=
 =?iso-8859-1?Q?jycc1Kv2SHnqTxcOrbYvQ93dLM5eIWiwuYEy6wvzAsmMtBnyEoRghyVZE6?=
 =?iso-8859-1?Q?fDpH+GJqosQlSmQY5UZ6HuoJ15jqeTkYp4uumyOPhuBgO9rHIk9sBr+rJE?=
 =?iso-8859-1?Q?EMFMISCN02jjAARhi/bnNYxaUKln4cwSNpZglylz+tgVpKKX4j4Onv3/Hv?=
 =?iso-8859-1?Q?7smS85+lcHCC7546iI9eKpnwlX1H9i+cy/wPZmtB1bOjf53swt9cLgsEBo?=
 =?iso-8859-1?Q?a4/E29yIqWRsteKooTGoQQW7BrwAS7K9z9XSmSQiMQAHJcg8ZUy/yopuIx?=
 =?iso-8859-1?Q?j2VYKuBZmuXjaoous+hW3ly0HxaYCWSr0+3niFV52IiWbUD06viW9xKSqu?=
 =?iso-8859-1?Q?PjhDxmuYBklYRHTqtsmgbqRLW+37TFRO6brFB8aZnU/yzBy0gyFT515S39?=
 =?iso-8859-1?Q?yo5qZDqnN/xOZZmWRnfNHy/uvcNqNUOYehYD+bh4aJyqxkzmjFYrhXAI7R?=
 =?iso-8859-1?Q?+s91y2wkxQLVRw0MXE3JSJrwuI6ibytvKSve4JnkSB4+W9PZlpwaNNAE8/?=
 =?iso-8859-1?Q?8=3D?=
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)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?qmkvIdBkEmZ1q7D0lRzMmDwraLQr4yw+zRa4HKW8apqfEqwM6wIGCR6wMB?=
 =?iso-8859-1?Q?OaQjCR0G7/jGQERNMhlfF6oSyU3doRuI6C9rsEHsGDuXKr1d9HWMDHYMR2?=
 =?iso-8859-1?Q?zA2RKSYWtjWJBVsPn5LOyba5SMLDPaYAoG33Pq2H9cWEe/dZWteHwIyGg+?=
 =?iso-8859-1?Q?dzFVSQ9gTkcC1JoIy0NPcAJR648eEzaaQDKNNft+t85wTPNW0NNZXG5UAo?=
 =?iso-8859-1?Q?AC7aw3DaOu+5aKcqPwezbhwdBHKgpSZk8j5tsFAS7wkUiIBuBj6PEY/UnH?=
 =?iso-8859-1?Q?Z21hiY7JDx6ebONO9EIwnHWT+2HZV4asKGf+v4ssQAES5B/bBwE3IHO/Wd?=
 =?iso-8859-1?Q?446f3BTjjee2ZA9LYk0e/pPH9rWDQhhXOQu6J5UcPpe3VBhg+na+t7bTVS?=
 =?iso-8859-1?Q?nEJ3XvJercTJCtHJ11JRK+xqwApvkJCX4OAhV+vpFC0sJ2ildUXnu5IFyI?=
 =?iso-8859-1?Q?80V4oVZ89nxBPtr5IjiCYJg4tiVWHyANeOKnH+L7DFnJKLey/F0H9hbIEn?=
 =?iso-8859-1?Q?pQHu8Tt6gO+NanD45krBahQXE/5OrLQzAWm2oHMoGK3w07/qpVxdWiD095?=
 =?iso-8859-1?Q?JyTUeXUKOc3qpeaFJc0/mFSGI641ZrN4Ebhum0BslEAcDc7bec6eTs6v3k?=
 =?iso-8859-1?Q?9GddD57LgiAsiMMkw5ytSvpd9rjPvQNo7WCbrE/vGJU3+4ajzJj46Z4Siu?=
 =?iso-8859-1?Q?s49mbMDDHwKmb7FVXq+mQ8mIRQMEkgBGdzhmQpp8t2rdbHmJUH9MiwBLp3?=
 =?iso-8859-1?Q?j0mjnKdTIs7BwnKUBjklVNi3sXkUnL9riQaoxGhDeYgBiaErYLOn933Whv?=
 =?iso-8859-1?Q?EJ4s5SbUebZehGlEGdzjLboTU0j0b7FIwGi+NegSGr33oP488+UVQpAEjh?=
 =?iso-8859-1?Q?zkNeLXETZ2q9WOSTWzfx163QtHVBkBUWZBXLqtDqAwOpPnQv8cIa8ZuPaW?=
 =?iso-8859-1?Q?pZ6fE1H91XX/7MnWO8ZhFf3ftvZ+gnKWUvhMkjNNUloC129Cw0XE4hq0Yr?=
 =?iso-8859-1?Q?k3kCA2PGFSfBZdhXoihFBjjS98MwEeejMf4sYLLcy94PXP6sJnEDgUSZF7?=
 =?iso-8859-1?Q?pBYKDhg2G6tUumE11o+7NLsG5WKFZAyRDbnnJKsrQHyOa62QtfTB57rQjx?=
 =?iso-8859-1?Q?Ci+qpiSCngyKD7QHolKs8tybCNl3OWYRkZLhnEpUzCeLC3vHZ4YfQ36PZb?=
 =?iso-8859-1?Q?4Sduc7cQt6uu8hMJ1SFHqWyTALZJjqSI5N/gyijtKtfGKxX4MZBvrhticG?=
 =?iso-8859-1?Q?ive0aHoteY1T/1hYczE63bkc3zUVrFwwlX3rw7/PI6BRhcY10tAO6b9va6?=
 =?iso-8859-1?Q?LZC52IZplEjFxHUSJdplbm98pfAwgdjT9qZv9a3mpmJ1nt3aL1k1/YATxH?=
 =?iso-8859-1?Q?WDkEbWvKkYQHfCab6kXuA2opNf3J1jY4nM01QHDXQWSK7czg3lKLeYil8t?=
 =?iso-8859-1?Q?gMyCXVP7ZObWWQX7RbpBsvNQWfUh2FeGhimyUkT+g2oInYQzsH36pfCXYa?=
 =?iso-8859-1?Q?TZp0anwwqcm1voHwXFalh40mv5sFYEmYtPwORL0M9/+j248UV75xWqrhvW?=
 =?iso-8859-1?Q?eEGKMq1tyJ1C85BlSxgGTnuJuXujBG0l2G6v7jvtQlRvbNMDC3vr+6epw/?=
 =?iso-8859-1?Q?SE4dq/AOwnA7gBzCIJHuGRFEL1xkzjQo++uk8AMTc3p1xy0RvZeA/hOw?=
 =?iso-8859-1?Q?=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: 4ef80455-f45c-4c15-f60f-08dd9dc7bf17
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2025 09:12:17.8409
 (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: 0l1xf1x3uKraDFRweJojNMSY+36UI3M7Qa9iyAT8+vUeKw2YqFIgC6B4e7f+nTG74eJtpjfO5r4jYELPA4QTxA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB9709

From: Rahul Singh 

Current code skip the mapping for PCI bridge MMIO region to dom0 when
pci_passthrough_enabled flag is set. Mapping should be skip when
has_vpci(d) is enabled for the domain, as we need to skip the mapping
only when VPCI handler are registered for ECAM.

Signed-off-by: Rahul Singh 
Signed-off-by: Stewart Hildebrand 
Acked-by: Julien Grall 
---
This patch was originally picked up from [1]

v10->v11:
* no change

v9->v10:
* no change

v8->v9:
* no change

v7->v8:
* no change

v6->v7:
* add Julien's A-b

v5->v6:
* drop unrelated change in xen/arch/arm/domain_build.c:handle_linux_pci_dom=
ain()

v4->v5:
* new patch

changes since picking up from [1]:
* rebase on top of "dynamic node programming using overlay dtbo" series
* replace !is_pci_passthrough_enabled() check with !IS_ENABLED(CONFIG_HAS_P=
CI)
  instead of removing

[1] https://lists.xenproject.org/archives/html/xen-devel/2023-07/msg00483.h=
tml
---
 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 5e1c1cc326..11523750ae 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -268,7 +268,7 @@ int handle_device(struct domain *d, struct dt_device_no=
de *dev, p2m_type_t p2mt,
         .d =3D d,
         .p2mt =3D p2mt,
         .skip_mapping =3D !own_device ||
-                        (is_pci_passthrough_enabled() &&
+                        (has_vpci(d) &&
                         (device_get_class(dev) =3D=3D DEVICE_PCI_HOSTBRIDG=
E)),
         .iomem_ranges =3D iomem_ranges,
         .irq_ranges =3D irq_ranges
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Wed May 28 09:17:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:17:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999057.1379756 (Exim 4.92)
	(envelope-from )
	id 1uKCv0-0000yd-9Z; Wed, 28 May 2025 09:17:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999057.1379756; Wed, 28 May 2025 09:17:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKCv0-0000yW-70; Wed, 28 May 2025 09:17:50 +0000
Received: by outflank-mailman (input) for mailman id 999057;
 Wed, 28 May 2025 09:17:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCuy-0000yL-C1
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:17:48 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20627.outbound.protection.outlook.com
 [2a01:111:f403:2417::627])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9d3cf003-3ba4-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:17:46 +0200 (CEST)
Received: from SN4PR0501CA0108.namprd05.prod.outlook.com
 (2603:10b6:803:42::25) by PH0PR12MB8032.namprd12.prod.outlook.com
 (2603:10b6:510:26f::15) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.27; Wed, 28 May
 2025 09:17:41 +0000
Received: from SN1PEPF00036F42.namprd05.prod.outlook.com
 (2603:10b6:803:42:cafe::e2) by SN4PR0501CA0108.outlook.office365.com
 (2603:10b6:803:42::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.13 via Frontend Transport; Wed,
 28 May 2025 09:17:41 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F42.mail.protection.outlook.com (10.167.248.26) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:17:41 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:17: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" 
X-Inumbo-ID: 9d3cf003-3ba4-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=meU5uzdtMEinPF9z9C10dGXX1sEsghdzm+pHaFpAl8eZh+o85T0d+Jwp6YhcsRpBFZfrJ99aHrwo3qMOhLC3vWShya+Qf10/pLsFG72UDAIAMUYZJ2+yGuKgO3U1y4zSi2GJ3KfP+95eiIbYHLBRsn/nefzaOXsB/G5Q08xgHvIQpT2/3vJiTfYGRgCmCAFKm/mNmq+OiFiCTvfTqWpkZjlc8Jx55RHvjMOCL9LSm82e92ad9ZuhykFtwjXR08yLYiIScStOHOe7qkoGfMqCRM2c0vA5kgTvyWxtehh2laYB/k3Uut5zQh1OT3wYjcrA8tch39IKFB8AV4dCWy+aMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2fBy+00aMr8fjYdF68xRYh7Q/ZCOgcFRnmf07kIan4g=;
 b=K4dsj7wDAF8z96IA5UtN/Wkm6gAAvgTemw7QyKVjmmuXgFHgoR9RJQkajVdB3Gum9YTCTZa7ji0e2aF3nQJmjTGp1ih7Eqb/gbuvrQjbU0Y9WZ7PM7ZQz1ywTkCaWENIe4sQmJiCgyWLifFqFZvA6ePBiKJI97U4w9GFfZWW+d4eK3M7/swjr2R4yohuDy3IEyw/OmzHEV6VEwuk9nCba4e53oJldOqKWSxzf7PaV7F3da3yULqacbOR4lKkuxIneVXQgHhLrrkwn33sUps+S/kDr6+k7fNVhjXk/Emj73/CSrKtHkUWbE4650516aT3xpY3ahSjSf2w76Kb1UEZXw==
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=2fBy+00aMr8fjYdF68xRYh7Q/ZCOgcFRnmf07kIan4g=;
 b=FLWQiYxp+8CKVCKNqGa6VkXESezko9kuhmg3vc5FUNM45LOsY0vHjkkrodGcwBaxtkWmbnd4EzYniA6DT4AalrVqV+1VgvceTDT7hi3iKjtu5Lw9WqzMmgWM1f/kP1iTVy/rSqYcYvGdqoOdIKuy6XzpInWCfJ1MbxnhI7cyECw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: , 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper , "Anthony
 PERARD" , Michal Orzel ,
	Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini , "Daniel
 P. Smith" , Dario Faggioli
	, Juergen Gross , George Dunlap
	, Nathan Studer , "Stewart
 Hildebrand" , Bertrand Marquis ,
	Volodymyr Babchuk , Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko 
Subject: [PATCH v4 00/20] xen: introduce CONFIG_SYSCTL
Date: Wed, 28 May 2025 17:16:48 +0800
Message-ID: <20250528091708.390767-1-Penny.Zheng@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: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F42:EE_|PH0PR12MB8032:EE_
X-MS-Office365-Filtering-Correlation-Id: 6cae79f8-0bd2-494c-ad85-08dd9dc87f6e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|1800799024|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?xnB5gNhkOaBi/fMwNPIinQRmu6k9mxoNya/r3zEMMiGTe+d3KUIzLpaZJE8m?=
 =?us-ascii?Q?18aODG/JcruOEdzVX9v7VwpuTpQwlSCaKnf164elhfKg+FtQdK7VhsKftlrk?=
 =?us-ascii?Q?/F1w8A0/fo16cr87gzdNVlIthDd7OIdFOdHw/NJA3UiYXgBDNCTJhkjC4sp9?=
 =?us-ascii?Q?FgKb1+2BIolLwp62cqDgW8qD2l37Z/KsvuHHOV2Pnn/3tPINmHTC+9P9bY0u?=
 =?us-ascii?Q?jUKALdlS38fiuOwAvzy3qZEQLHYkoSfsEzZIj+KYmJ7KJnLGJQkU71D4xZda?=
 =?us-ascii?Q?9LP9KjSZnII8LtwRfJopDoS5HM1eBXvdokOhjtObEw9kXqfWncT/X14++bd0?=
 =?us-ascii?Q?p2XQ1AUwyLb74kpK12cfi1ulOzIHEnyvRrXeWFD6wDMzkH8o6W2fYy/5Z+cu?=
 =?us-ascii?Q?4/C5PS7Cd7jkkooXM1lMtIY9Nkz7uJffJBGcIjO9eoC8FL7Hv6F8/ybUDS1a?=
 =?us-ascii?Q?U6ms4Tfpc8B3KNuGIR6Fyo0/GRtJ13ezCZkQ7gjYOorVVl8HKFsCZjcukIRV?=
 =?us-ascii?Q?fq29eOLOVA5dWfxpfS7e2Alre9nOAI4brTQAvHEkjnvchtjFKTQ+Cb5YfDLb?=
 =?us-ascii?Q?coiYOQiflsRHc0EDkjGBKU9pHBAqdkhTwUosUxEUNIdV0gAt64aTAGloqYTU?=
 =?us-ascii?Q?Ah99d/fT8vUx1w6iBr8Y+vZvZMHowYGr50uv1Lf5Qfk8mKkGKBklegG6zBYa?=
 =?us-ascii?Q?BySiXU6v/6JalcbkCh8VZzjKmYtGwWeiHautNTh20urQeEAur/ToDveJNQ9x?=
 =?us-ascii?Q?fZzkvzXo3jIAfvAOu2OoBbh+pnji5vPCpxHyTVXiQ49VespHmh3rUv/1ONt1?=
 =?us-ascii?Q?qo0uwr9wq1LqrYeCiLhlzkFeaP3F8VltJb3QhEeTuMSypgsptl7xf2Gw7hpG?=
 =?us-ascii?Q?1mEPesPtcP1pqvLqQ7Gy2hB+y7DSZIyS0mgGGZlLU3pRIqg5l34rGNHU+okx?=
 =?us-ascii?Q?WINiY48o07BthoN8h/cXJRSIbVpDYzj3/OaydsHTMW5+ARa6Wc9yXcFrbq52?=
 =?us-ascii?Q?PsJNLqrCngaLEvaQ8XBpVWuutpH/nTAGW41GNy0i1EUYaGwnNqF7ppbUjosx?=
 =?us-ascii?Q?N7iP07lSMmUA0qVTCx/aRhwOGudjLCtmCIHfEP9zRTTgRjwW2toYqee+iR80?=
 =?us-ascii?Q?PQ+Ce7g4SiAjZWCA60Ntt4ri5LfrmBDLgzF3wvK2+I83gZdPjUfwKusR+Psc?=
 =?us-ascii?Q?6PYKm8M8Mdyz/rT4kcu/V/kqTYAiq73fMncfbL+hMotxHtAdXS26V8ew/JKa?=
 =?us-ascii?Q?FHOfEMOUZ0KBitFCqMvI2vvwSUdTZ26aDR/tQtDnvZJR+w36ndJe4cEAby9s?=
 =?us-ascii?Q?cNtA2ywNUIZSRaBAMtJANJY6Skpl8W/oZdOAoFvVZ1pfQzQBAT0YY8J5Npto?=
 =?us-ascii?Q?zyXwHA8FMoIGCew7vwMyp/cUvIEQarx0Xzk/LAg53/oPvUn8ZoQza3aW2irU?=
 =?us-ascii?Q?qVTk4BM6YG/HRSDop+HV2qmGDEEImBQ94/3LvrGEQRht7rnsffWCiV43I5Kv?=
 =?us-ascii?Q?j0QMpewCrDY8ecCzJL4labWTmlG7922PyECbnqhMAaZXkDc6DeL9XPj9vA?=
 =?us-ascii?Q?=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:17:41.2803
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6cae79f8-0bd2-494c-ad85-08dd9dc87f6e
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F42.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8032

It can be beneficial for some dom0less systems to further reduce Xen footprint
via disabling some hypercalls handling code, which may not to be used &
required in such systems. Each hypercall has a separate option to keep
configuration flexible.

Options to disable hypercalls:
- sysctl
- domctl
- hvm
- physdev
- platform

This patch serie is only focusing on introducing CONFIG_SYSCTL. Different
options will be covered in different patch serie.

Features, like LIVEPATCH, Overlay DTB, which fully rely on sysctl op, will
be wrapped with CONFIG_SYSCTL, to reduce Xen footprint as much as possible.

It is based on Stefano Stabellini's commit "xen: introduce kconfig options to
disable hypercalls"(
https://lore.kernel.org/xen-devel/20241219092917.3006174-1-Sergiy_Kibrik@epam.com)

Penny Zheng (18):
  xen/pmstat: consolidate code into pmstat.c
  xen: make avail_domheap_pages() inlined into get_outstanding_claims()
  xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
  xen/xsm: wrap around xsm_sysctl with CONFIG_SYSCTL
  xen/sysctl: wrap around XEN_SYSCTL_readconsole
  xen/sysctl: make CONFIG_TRACEBUFFER depend on CONFIG_SYSCTL
  xen/sysctl: wrap around XEN_SYSCTL_sched_id
  xen/sysctl: wrap around XEN_SYSCTL_perfc_op
  xen/sysctl: wrap around XEN_SYSCTL_lockprof_op
  xen/pmstat: introduce CONFIG_PM_OP
  xen/sysctl: introduce CONFIG_PM_STATS
  xen/sysctl: wrap around XEN_SYSCTL_page_offline_op
  xen/sysctl: wrap around XEN_SYSCTL_cpupool_op
  xen/sysctl: wrap around XEN_SYSCTL_scheduler_op
  xen/sysctl: wrap around XEN_SYSCTL_physinfo
  xen/sysctl: make CONFIG_COVERAGE depend on CONFIG_SYSCTL
  xen/sysctl: make CONFIG_LIVEPATCH depend on CONFIG_SYSCTL
  xen/sysctl: wrap around arch-specific arch_do_sysctl

Stefano Stabellini (2):
  xen: introduce CONFIG_SYSCTL
  xen/sysctl: wrap around sysctl hypercall

 xen/Kconfig.debug                            |   2 +-
 xen/arch/arm/Kconfig                         |   1 +
 xen/arch/arm/Makefile                        |   2 +-
 xen/arch/riscv/stubs.c                       |   2 +
 xen/arch/x86/Kconfig                         |   6 +-
 xen/arch/x86/Makefile                        |   2 +-
 xen/arch/x86/acpi/cpu_idle.c                 |   2 +
 xen/arch/x86/acpi/cpufreq/hwp.c              |   6 +
 xen/arch/x86/acpi/cpufreq/powernow.c         |   4 +
 xen/arch/x86/configs/pvshim_defconfig        |   6 +
 xen/arch/x86/hvm/Kconfig                     |   1 -
 xen/arch/x86/psr.c                           |  18 +
 xen/common/Kconfig                           |  29 +-
 xen/common/Makefile                          |   2 +-
 xen/common/page_alloc.c                      |  55 +-
 xen/common/perfc.c                           |   2 +
 xen/common/sched/arinc653.c                  |   6 +
 xen/common/sched/core.c                      |   4 +
 xen/common/sched/cpupool.c                   |   8 +
 xen/common/sched/credit.c                    |   4 +
 xen/common/sched/credit2.c                   |   4 +
 xen/common/sched/private.h                   |   4 +
 xen/common/spinlock.c                        |   2 +
 xen/common/sysctl.c                          |   4 +-
 xen/drivers/acpi/Makefile                    |   3 +-
 xen/drivers/acpi/pm-op.c                     | 397 +++++++++++++
 xen/drivers/acpi/pmstat.c                    | 559 ++++++-------------
 xen/drivers/char/console.c                   |   2 +
 xen/drivers/cpufreq/cpufreq.c                |  31 +
 xen/drivers/cpufreq/cpufreq_misc_governors.c |   2 +
 xen/drivers/cpufreq/cpufreq_ondemand.c       |   2 +
 xen/drivers/cpufreq/utility.c                | 204 -------
 xen/drivers/video/Kconfig                    |   4 +-
 xen/include/acpi/cpufreq/cpufreq.h           |   5 -
 xen/include/acpi/cpufreq/processor_perf.h    |  14 +-
 xen/include/hypercall-defs.c                 |   8 +-
 xen/include/xen/mm.h                         |   1 -
 xen/include/xsm/xsm.h                        |  18 +
 xen/xsm/dummy.c                              |   6 +
 xen/xsm/flask/hooks.c                        |  14 +
 40 files changed, 798 insertions(+), 648 deletions(-)
 create mode 100644 xen/drivers/acpi/pm-op.c

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:17:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:17:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999058.1379765 (Exim 4.92)
	(envelope-from )
	id 1uKCv1-0001CJ-Gc; Wed, 28 May 2025 09:17:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999058.1379765; Wed, 28 May 2025 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 1uKCv1-0001CC-Dp; Wed, 28 May 2025 09:17:51 +0000
Received: by outflank-mailman (input) for mailman id 999058;
 Wed, 28 May 2025 09:17:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCv0-0000yL-9S
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:17:50 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2418::60d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9f7c8793-3ba4-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:17:49 +0200 (CEST)
Received: from SN4PR0501CA0113.namprd05.prod.outlook.com
 (2603:10b6:803:42::30) by CY1PR12MB9700.namprd12.prod.outlook.com
 (2603:10b6:930:108::14) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Wed, 28 May
 2025 09:17:46 +0000
Received: from SN1PEPF00036F42.namprd05.prod.outlook.com
 (2603:10b6:803:42:cafe::92) by SN4PR0501CA0113.outlook.office365.com
 (2603:10b6:803:42::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.19 via Frontend Transport; Wed,
 28 May 2025 09:17:46 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F42.mail.protection.outlook.com (10.167.248.26) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:17:46 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:17: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" 
X-Inumbo-ID: 9f7c8793-3ba4-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Xa4WyhsDYigSBWc43dWjwF+tfVdvQhmxB7TP16qn6/NXh/edWcpBYP9Two97KfEEVzf9Vdd0S4HuSqrxbFzvOB3W+D4mRHzudWwaDX5CZCGE2Gv6uz0rldlPhln0VRPEJZ+Wmzb3+4KpGIZo8loDYehqOXsKZkx2KFzFctA8UIj0feI92t5KGTWsAM6X8H8BIYLLGtkZCfnH2V9jO10iKXQ/KmHcwwsX7uXIHWE7ckyuaSVg9SAmDNCb3ys5d+EnsA7I2hQFtrxhKYehkn1CWTZ/8fLiw4ElWYG5/tk5/idr4RBIbmDiouWF+9OYwkr+if9MCJda7oG2w1UieXzDZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/GfDRm9JhuMPhiHwATAYzNDZZibb4ZAY1VdgVn0JUz8=;
 b=kMyJEdVYQZyYlTmiEx1g1uqD5MGXhSDga7jVV9SfchVEXB+iZF8zRijNR5eAUjeQeKVUX76+JNLdKXxVP4/+ncVXLqRAt0O0Hkme86Ck4AcRcsFpvc57mrWNX+Eo4jmZy11Sp3KqTRb6aUh2ViN7SfhKCNM+p/YWPxgg0jGXJ86v5c/sbZqUOzD+38AW0ungPSK20OoHVHG6X80Vsyjkpkaaiuq1cQbkr061XCGX1uG8ibL0OANOQuuAZ3XdDvfXWUAQuMpUkFhwkcI6MK2lGsNID2BV24YYYH8Otd7CICYkbgyIpAnvp7ph6DXkykhlBL20qmGP26RFwD70wE/oZA==
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=/GfDRm9JhuMPhiHwATAYzNDZZibb4ZAY1VdgVn0JUz8=;
 b=NXGgtCc9eS48V3rPYpVVKp3uhizozXIWQLNuE1VtUzGXQBpJeKdC8GHrVj9JCo18Tpq6bmBx5Kimg1yKZT8etHpHe1KbNSMDlUr4gVbcmfG+A6VmlW1wMAIMsJlyMkUWBmhiXiR6cs2KzpGJGgfmVSw6AI/9Fm9TOhgOu9YsoQ0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v4 02/20] xen: make avail_domheap_pages() inlined into get_outstanding_claims()
Date: Wed, 28 May 2025 17:16:50 +0800
Message-ID: <20250528091708.390767-3-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F42:EE_|CY1PR12MB9700:EE_
X-MS-Office365-Filtering-Correlation-Id: f5d71637-5c8f-4e40-1214-08dd9dc8824a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Vonb12ej2Fs1zx9gJIj0+5j1J8VgLT/WcogGN8yvGteMatyScBJPT7ppeJD6?=
 =?us-ascii?Q?DL7HH8yYCGB5BFvZSTOee6IbGNjllSd2JLFy5LRKqvfUHQdJ1KK0kv3U3ogW?=
 =?us-ascii?Q?lMCwZek4U2u+X1Zg53bbQXoNmwu95UaPNivV6k78HdnbPLr/n7IftoJxyLqK?=
 =?us-ascii?Q?KfNeDq4+dNCBpmWiUaVK+BjBoPY9kG4TFm7DR8YmESbeaP1PB4TetF4jeyTE?=
 =?us-ascii?Q?4d2epXEwb/rTDfPsfnkRDawgm8AQLSe/r8tFyYTNbErfrBgg3gv9WKiHdelJ?=
 =?us-ascii?Q?VWK0+0HaJue2R5tk1mChBMPR0SOyd6tBM1QEQqjF5hJt8/jjexbtyhgSRFJP?=
 =?us-ascii?Q?2735X0h1qctK2OB+YTG74psC0yeZfC+qkkGGiPC0wfI/zKycBGjnUK/hra2R?=
 =?us-ascii?Q?1oX3xbIUrh+QqvboopPQ/iB0G7RfyxEQyco8vBXgdrxJxwnswC8iSRFqHnB0?=
 =?us-ascii?Q?TuyhLhjb40WqIM9oJsiQf+cJH6G0KmS/is0OpFw/i983z+BmwVn7HouzqJRS?=
 =?us-ascii?Q?1/6L/6D60fJuAtOd5wD4HEUe46gULTh5A26HUQLoUZAkLC0KbJ/rP12BDiQ4?=
 =?us-ascii?Q?ZuP0p0na+fg7pkYMPFgkZsHLSeihC4UTvRoDgn718eZ1vlsz9Y3fUFUpCQoy?=
 =?us-ascii?Q?pFA96ZKYSMRQVyJtCNGFAbNpQSoCDLz5nosiZvJ2yMaP909nD+YIIjuaa4mE?=
 =?us-ascii?Q?cf+vCMPFeKn+S7+GoDaG686Y0qfe/bQaebyF7kjo4V4HjUkWSiONZ9Sra2YP?=
 =?us-ascii?Q?sLlP9FZS1wbVk97CXrV4BlvmONIlvUH2+RoVLq7I/tVRvC+aMKT1exRt9t9k?=
 =?us-ascii?Q?MKtoRimpky/SEv+BgvRZ2jWq8yo/16G/oWOw+rCLIKqWW5pi0869bgh/PEs9?=
 =?us-ascii?Q?pLfsa+TooSwR4MNgZl/ZaiUEo57wQT7YCOaFnUbbFSSQbAt3Kfgd5ak/18hV?=
 =?us-ascii?Q?CnwX1x281xzKNTcUWQ3PqQ/O5RIcVN4Sxb0JYHq5ZHilU0AW9RnXM6sJjIxm?=
 =?us-ascii?Q?AkIO3Jk4CqvcdEsnxB/9qGT4RgpWs43gByKn/zWYIxpbaoFypvDpKfYeycHy?=
 =?us-ascii?Q?NiJmnanaFxLJc0i6tFVMtIW3euesFtuoEkePoGYYKrmRvPDQBlE/ajo/5Irv?=
 =?us-ascii?Q?cvTuWr7CDh9V6AV9aesJ7B8JJTJDO36FFsatRVTI3LhMzZavr/szG48ia1P7?=
 =?us-ascii?Q?01HRIt47zPXgCP+Db8Bsx2l3OZOwe1asxrLyjFZz4iyr1cp8/hnh2u+cK5fd?=
 =?us-ascii?Q?pOtJNb3iyLlhj+XYjDCMf0fbpVHLBjihkpExRp/f/ooUNtn1T/ep7yazKvUi?=
 =?us-ascii?Q?SU96wvpssKEAb/Oqce3UAf0apO9yc2YWK2l2J3K+/q9EyOayHND7SB2+h9sm?=
 =?us-ascii?Q?GFjgGrsCHg3DkyK9cWjIIMTdc3BzsCqHq1+wJbZeK1ZaT+uy0whlGOyl9INB?=
 =?us-ascii?Q?CX+ngVQUg8o0jyvKp2EhHa7lY9WcwF7ceXqynPkdZkAkkqoLSs4kWzgOqk7r?=
 =?us-ascii?Q?szkIaTeTBBcuuKpnF9PyPr4b9eaF+DofX+rP?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:17:46.0745
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f5d71637-5c8f-4e40-1214-08dd9dc8824a
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F42.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR12MB9700

Function avail_domheap_pages() is only invoked by get_outstanding_claims(),
so it could be inlined into get_outstanding_claims().
Move up avail_heap_pages() to avoid declaration before
get_outstanding_claims().

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v1 -> v2:
- let avail_domheap_pages() being inlined into its sole caller
- move up avail_heap_pages()
---
v2 -> v3:
- change the title
---
v4 -> v5:
- move ahead and could go in right away
---
 xen/common/page_alloc.c | 51 ++++++++++++++++++-----------------------
 xen/include/xen/mm.h    |  1 -
 2 files changed, 22 insertions(+), 30 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index e57a287133..b204f22f50 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -488,6 +488,27 @@ static long total_avail_pages;
 static DEFINE_SPINLOCK(heap_lock);
 static long outstanding_claims; /* total outstanding claims by all domains */
 
+static unsigned long avail_heap_pages(
+    unsigned int zone_lo, unsigned int zone_hi, unsigned int node)
+{
+    unsigned int i, zone;
+    unsigned long free_pages = 0;
+
+    if ( zone_hi >= NR_ZONES )
+        zone_hi = NR_ZONES - 1;
+
+    for_each_online_node(i)
+    {
+        if ( !avail[i] )
+            continue;
+        for ( zone = zone_lo; zone <= zone_hi; zone++ )
+            if ( (node == -1) || (node == i) )
+                free_pages += avail[i][zone];
+    }
+
+    return free_pages;
+}
+
 unsigned long domain_adjust_tot_pages(struct domain *d, long pages)
 {
     ASSERT(rspin_is_locked(&d->page_alloc_lock));
@@ -584,7 +605,7 @@ void get_outstanding_claims(uint64_t *free_pages, uint64_t *outstanding_pages)
 {
     spin_lock(&heap_lock);
     *outstanding_pages = outstanding_claims;
-    *free_pages =  avail_domheap_pages();
+    *free_pages = avail_heap_pages(MEMZONE_XEN + 1, NR_ZONES - 1, -1);
     spin_unlock(&heap_lock);
 }
 
@@ -1962,27 +1983,6 @@ static void init_heap_pages(
     }
 }
 
-static unsigned long avail_heap_pages(
-    unsigned int zone_lo, unsigned int zone_hi, unsigned int node)
-{
-    unsigned int i, zone;
-    unsigned long free_pages = 0;
-
-    if ( zone_hi >= NR_ZONES )
-        zone_hi = NR_ZONES - 1;
-
-    for_each_online_node(i)
-    {
-        if ( !avail[i] )
-            continue;
-        for ( zone = zone_lo; zone <= zone_hi; zone++ )
-            if ( (node == -1) || (node == i) )
-                free_pages += avail[i][zone];
-    }
-
-    return free_pages;
-}
-
 /*************************
  * COLORED SIDE-ALLOCATOR
  *
@@ -2796,13 +2796,6 @@ unsigned long avail_domheap_pages_region(
     return avail_heap_pages(zone_lo, zone_hi, node);
 }
 
-unsigned long avail_domheap_pages(void)
-{
-    return avail_heap_pages(MEMZONE_XEN + 1,
-                            NR_ZONES - 1,
-                            -1);
-}
-
 unsigned long avail_node_heap_pages(unsigned int nodeid)
 {
     return avail_heap_pages(MEMZONE_XEN, NR_ZONES -1, nodeid);
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index e89942b87d..93c037d618 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -141,7 +141,6 @@ struct page_info *alloc_domheap_pages(
 void free_domheap_pages(struct page_info *pg, unsigned int order);
 unsigned long avail_domheap_pages_region(
     unsigned int node, unsigned int min_width, unsigned int max_width);
-unsigned long avail_domheap_pages(void);
 unsigned long avail_node_heap_pages(unsigned int nodeid);
 #define alloc_domheap_page(d,f) (alloc_domheap_pages(d,0,f))
 #define free_domheap_page(p)  (free_domheap_pages(p,0))
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:17:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:17:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999059.1379776 (Exim 4.92)
	(envelope-from )
	id 1uKCv2-0001R0-SU; Wed, 28 May 2025 09:17:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999059.1379776; Wed, 28 May 2025 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 1uKCv2-0001Qt-PY; Wed, 28 May 2025 09:17:52 +0000
Received: by outflank-mailman (input) for mailman id 999059;
 Wed, 28 May 2025 09:17:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCv2-0000yL-7I
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:17:52 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on2060c.outbound.protection.outlook.com
 [2a01:111:f403:200a::60c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9f8c4909-3ba4-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:17:51 +0200 (CEST)
Received: from SN4PR0501CA0097.namprd05.prod.outlook.com
 (2603:10b6:803:42::14) by IA1PR12MB8309.namprd12.prod.outlook.com
 (2603:10b6:208:3fe::8) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.25; Wed, 28 May
 2025 09:17:43 +0000
Received: from SN1PEPF00036F42.namprd05.prod.outlook.com
 (2603:10b6:803:42:cafe::90) by SN4PR0501CA0097.outlook.office365.com
 (2603:10b6:803:42::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.12 via Frontend Transport; Wed,
 28 May 2025 09:17:43 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F42.mail.protection.outlook.com (10.167.248.26) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:17:43 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:17: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" 
X-Inumbo-ID: 9f8c4909-3ba4-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UMXTis3pwxQNSWBoFylsWj7q/JAk1fn2IIny1B4tX6fffRa/RXMDIFrhQecJ+igRUYRcTJsNuUJBtmuFMOS7+a1UnZn9KFPWQo1BzspM+hMhLtyMATkf1YAkgGA79Tql9qB/WSQNkpQjjb0TEXicPXtzuRovHsTCzI6kIMIU8n6ZpVwdwfe3Ak9fy5v9vj92obzrOgjujpCmW5n0n3guhyCWhmZDoOQpgXZtjjdH48K9tsBJUcmVq2lq+mtonZrHN3+GuxQEJXoXNUCD7UzKBLQGZ/nqs3aPscnHFRlZtAlwayf77GhvycYmXYPsQzVe/L+fet0ds6HJ1FtB23Yadg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sXU7lCQ0nW2QkCoxel+HoxiYxmOkuqM2DkeV3pZanMc=;
 b=nX6fRCMpaEE5lZCKx+ClKHSnHK1MTtXJZthP+ojZnJUykPUAHbOao8wj3j3QI3UJGBtxugWrXsQmMVABQOZK82LHqf1cU4fgM1JaWADMMN/oAPp5NriQlnqiXfVfohpQmdb4ZlIVj9OpVqWbXeIe+QhEfPgy/yWpjf7Lx5cEkCm9j1JATzdKliWAqeiCmo7JpnE/HsNvtwsvkS/39/sGZBUZ1GF0DUDVPfSKR1uEgWgQtQCeY06C+849upgJmXdE3sR3w54led7q+wFmjM8Uq4LPZqzKYyWskEMadnMo6uIW9zLEMylxKimXwxf2ksncBdtKaXgxPE5+bcVEFzJ3Lg==
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=sXU7lCQ0nW2QkCoxel+HoxiYxmOkuqM2DkeV3pZanMc=;
 b=3FPnwI/4Ib0Wvk/v1ZFsP1qvdP/2ozc8TmZ9ibUE8sFHUZNaGiSGQR/Qd22A583q55yokRcLdcWZ9ovz5twdKjDs+712Bo7OyY12M0QXZDN0F6noEQupFPpldh96nqz+nTHnIxvZv4aIjLDYBbrg89u0Ac7rDQgLDyPAtKVayxo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Stefano Stabellini 
Subject: [PATCH v4 01/20] xen/pmstat: consolidate code into pmstat.c
Date: Wed, 28 May 2025 17:16:49 +0800
Message-ID: <20250528091708.390767-2-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F42:EE_|IA1PR12MB8309:EE_
X-MS-Office365-Filtering-Correlation-Id: cd8ff61a-ae5e-4278-ac27-08dd9dc880b3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?rXlmgzl/JuTuBbb34mj2DJ9uthG2VwG1t+4DjQFr11JcMAMwbdGcgd9pvWIQ?=
 =?us-ascii?Q?VjO+CsV4kfP1u0IMHJuDQnrXVirBrRwW9YDYKCTiu2c7sbIvbiR/O2wEJZ5Z?=
 =?us-ascii?Q?mBfeZFcipuNRZ2bKDyM31SawX/ouxax8qTiz7P/LtXcl6eQOsyM8jfqxgG7F?=
 =?us-ascii?Q?YLKQDmd/5StVWaDIanWqpEUxU9wF/SoroAF+VBofGmCixAxchfdhG5EbnJtp?=
 =?us-ascii?Q?4CmClFLK8mn983gILY+mgjDGX0OooRYrFsutzrn8SmxYWiq+/w5nAsfFSDBl?=
 =?us-ascii?Q?xqqjQU+fxLhahZ3Kfz11zveCS2WzsZHBoTXK/Ofccf1EZtEE4jVy/geDLwz8?=
 =?us-ascii?Q?pdKVa1DVW9zrcprBa/nq9ZzZ7G/d+vhSHA5cF+BzGHwqtwGT0iasNhgz2JMh?=
 =?us-ascii?Q?LpEq0pmKjO/+bTa7RqF+3+yQKs7oF1ep8Y3u76MwUzpHDwWb9VsevP7JGvh6?=
 =?us-ascii?Q?2T2hFnelLHi1CgleSPlqB8JvCWJ9MzSu9vSVeNbv9gQ4AOA5SsU3RsbDThNJ?=
 =?us-ascii?Q?YoNUbTGfnaG67/bNoD5NukFt4oHB+itRxrt2MPEAHQtIxw78nRbKYYnWChi2?=
 =?us-ascii?Q?+BbNeeg8cwDHpDGEayFPCibXtlDJ7ccezGsOcNkjEm7t8N6d5OAzD1wWfxmr?=
 =?us-ascii?Q?ddk9shRaHIMMze3c62LpG1TtnBAr0QEW23kq+ImPJ+2C7dQ5A3OEgkuAHxdb?=
 =?us-ascii?Q?dpKNBXU9Tm8X4p2SIX0uUDauq5iMgOrOkWkoKR5mXbBDRHO5OQN7G06I4IWm?=
 =?us-ascii?Q?fiSxnewpbqNaCeTckQGWkTc3MHO2NdUkuFQ4hlZ9/1uCyPKDQYAzOznyYNIA?=
 =?us-ascii?Q?pUzabqRtSzFVEC1b+idyNfB1lVb9wSYJlGY8T+fwgpC3VTxUa4a/+xOhXlB+?=
 =?us-ascii?Q?L7O9j6MdUMnLATlUcX/jzP1drr4BMCzmZ/xVwpwqHNvcX/82zZpKbuzSjqzM?=
 =?us-ascii?Q?MGEo2aoWv1xMAqVcuAYZ9uPLS0/IyE1/OnbYmFenSZGmzib4LsZZwYclNjr0?=
 =?us-ascii?Q?MIi6y5V9FW+1gJDegmbBhUorWWojonbn2X/UI5DRzy9lrmLxvgHjwfEPnJu5?=
 =?us-ascii?Q?DDHpc4btj32a33bm+csHQZn0U6mzBGtyyOL8U9a1XPUbx1LZmEqBRBt5DfXo?=
 =?us-ascii?Q?lPUhmfutUDrg0Se/CIlKe9rWuZdgxNEuYEhk1q27/jucgajrbdzk2WJeqGco?=
 =?us-ascii?Q?4KagbO+iNEmPpKjy7zcW7MaH3q1T3Jm29FsdX889fKhvUjTWPcsDFfu48dmq?=
 =?us-ascii?Q?5BWH9hmSOA7p2cNHMNi8AOLDPdAwKnKaVeenbDEa4kouhGEYOOy0mSxYd3E0?=
 =?us-ascii?Q?98gjwevFAxpiRE1Sk3AkUu3O74we41IN2R4sAu6EUgE2pIldPPkN4Uykv7zZ?=
 =?us-ascii?Q?68Wb6p3kRDvyDalTsbAA0SXnsOT2htiFrkwVmFOAT9WiXZHznsIxOV0NcIi8?=
 =?us-ascii?Q?Joc6mGR6vlTWyld5Mo+AbHerNVwmAjIMwh4h0FhuKKzHKp5LhUAIcToRWI1g?=
 =?us-ascii?Q?Cs67oplEWRbUE2P3ppZjMQGcejLWLwq302Iq?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:17:43.4104
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cd8ff61a-ae5e-4278-ac27-08dd9dc880b3
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F42.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8309

We move the following functions into drivers/acpi/pmstat.c, as they
are all designed for performance statistic:
- cpufreq_residency_update()
- cpufreq_statistic_reset()
- cpufreq_statistic_update()
- cpufreq_statistic_init()
- cpufreq_statistic_exit()
Consequently, variable "cpufreq_statistic_data" and "cpufreq_statistic_lock"
shall become static.
We also move out acpi_set_pdc_bits(), as it is the handler for sub-hypercall
XEN_PM_PDC, and shall stay with the other handlers together in
drivers/cpufreq/cpufreq.c.

Various style corrections shall be applied at the same time while moving these
functions, including:
- brace for if() and for() shall live at a seperate line
- add extra space before and after bracket of if() and for()
- use array notation
- convert uint32_t into unsigned int
- convert u32 into uint32_t

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
v2 -> v3:
- brace for if() and for() shall live at a seperate line
- use array notation
- convert uint32_t into unsigned int
---
v3 -> v4:
- move ahead and could go in right away
---
 xen/drivers/acpi/pmstat.c                 | 202 ++++++++++++++++++----
 xen/drivers/cpufreq/cpufreq.c             |  31 ++++
 xen/drivers/cpufreq/utility.c             | 163 -----------------
 xen/include/acpi/cpufreq/cpufreq.h        |   2 -
 xen/include/acpi/cpufreq/processor_perf.h |   4 -
 5 files changed, 201 insertions(+), 201 deletions(-)

diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index c51b9ca358..abfdc45cc2 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -41,7 +41,176 @@
 #include 
 #include 
 
-DEFINE_PER_CPU_READ_MOSTLY(struct pm_px *, cpufreq_statistic_data);
+static DEFINE_PER_CPU_READ_MOSTLY(struct pm_px *, cpufreq_statistic_data);
+
+static DEFINE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
+
+/*********************************************************************
+ *                    Px STATISTIC INFO                              *
+ *********************************************************************/
+
+static void cpufreq_residency_update(unsigned int cpu, uint8_t state)
+{
+    uint64_t now, total_idle_ns;
+    int64_t delta;
+    struct pm_px *pxpt = per_cpu(cpufreq_statistic_data, cpu);
+
+    total_idle_ns = get_cpu_idle_time(cpu);
+    now = NOW();
+
+    delta = (now - pxpt->prev_state_wall) -
+            (total_idle_ns - pxpt->prev_idle_wall);
+
+    if ( likely(delta >= 0) )
+        pxpt->u.pt[state].residency += delta;
+
+    pxpt->prev_state_wall = now;
+    pxpt->prev_idle_wall = total_idle_ns;
+}
+
+void cpufreq_statistic_update(unsigned int cpu, uint8_t from, uint8_t to)
+{
+    struct pm_px *pxpt;
+    const struct processor_pminfo *pmpt = processor_pminfo[cpu];
+    spinlock_t *cpufreq_statistic_lock =
+               &per_cpu(cpufreq_statistic_lock, cpu);
+
+    spin_lock(cpufreq_statistic_lock);
+
+    pxpt = per_cpu(cpufreq_statistic_data, cpu);
+    if ( !pxpt || !pmpt )
+    {
+        spin_unlock(cpufreq_statistic_lock);
+        return;
+    }
+
+    pxpt->u.last = from;
+    pxpt->u.cur = to;
+    pxpt->u.pt[to].count++;
+
+    cpufreq_residency_update(cpu, from);
+
+    pxpt->u.trans_pt[from * pmpt->perf.state_count + to]++;
+
+    spin_unlock(cpufreq_statistic_lock);
+}
+
+int cpufreq_statistic_init(unsigned int cpu)
+{
+    unsigned int i, count;
+    struct pm_px *pxpt;
+    const struct processor_pminfo *pmpt = processor_pminfo[cpu];
+    spinlock_t *cpufreq_statistic_lock = &per_cpu(cpufreq_statistic_lock, cpu);
+
+    spin_lock_init(cpufreq_statistic_lock);
+
+    if ( !pmpt )
+        return -EINVAL;
+
+    spin_lock(cpufreq_statistic_lock);
+
+    pxpt = per_cpu(cpufreq_statistic_data, cpu);
+    if ( pxpt )
+    {
+        spin_unlock(cpufreq_statistic_lock);
+        return 0;
+    }
+
+    count = pmpt->perf.state_count;
+
+    pxpt = xzalloc(struct pm_px);
+    if ( !pxpt )
+    {
+        spin_unlock(cpufreq_statistic_lock);
+        return -ENOMEM;
+    }
+    per_cpu(cpufreq_statistic_data, cpu) = pxpt;
+
+    pxpt->u.trans_pt = xzalloc_array(uint64_t, count * count);
+    if ( !pxpt->u.trans_pt )
+    {
+        xfree(pxpt);
+        spin_unlock(cpufreq_statistic_lock);
+        return -ENOMEM;
+    }
+
+    pxpt->u.pt = xzalloc_array(struct pm_px_val, count);
+    if ( !pxpt->u.pt )
+    {
+        xfree(pxpt->u.trans_pt);
+        xfree(pxpt);
+        spin_unlock(cpufreq_statistic_lock);
+        return -ENOMEM;
+    }
+
+    pxpt->u.total = pmpt->perf.state_count;
+    pxpt->u.usable = pmpt->perf.state_count - pmpt->perf.platform_limit;
+
+    for ( i = 0; i < pmpt->perf.state_count; i++ )
+        pxpt->u.pt[i].freq = pmpt->perf.states[i].core_frequency;
+
+    pxpt->prev_state_wall = NOW();
+    pxpt->prev_idle_wall = get_cpu_idle_time(cpu);
+
+    spin_unlock(cpufreq_statistic_lock);
+
+    return 0;
+}
+
+void cpufreq_statistic_exit(unsigned int cpu)
+{
+    struct pm_px *pxpt;
+    spinlock_t *cpufreq_statistic_lock = &per_cpu(cpufreq_statistic_lock, cpu);
+
+    spin_lock(cpufreq_statistic_lock);
+
+    pxpt = per_cpu(cpufreq_statistic_data, cpu);
+    if ( !pxpt )
+    {
+        spin_unlock(cpufreq_statistic_lock);
+        return;
+    }
+
+    xfree(pxpt->u.trans_pt);
+    xfree(pxpt->u.pt);
+    xfree(pxpt);
+    per_cpu(cpufreq_statistic_data, cpu) = NULL;
+
+    spin_unlock(cpufreq_statistic_lock);
+}
+
+static void cpufreq_statistic_reset(unsigned int cpu)
+{
+    unsigned int i, j, count;
+    struct pm_px *pxpt;
+    const struct processor_pminfo *pmpt = processor_pminfo[cpu];
+    spinlock_t *cpufreq_statistic_lock = &per_cpu(cpufreq_statistic_lock, cpu);
+
+    spin_lock(cpufreq_statistic_lock);
+
+    pxpt = per_cpu(cpufreq_statistic_data, cpu);
+    if ( !pmpt || !pxpt || !pxpt->u.pt || !pxpt->u.trans_pt )
+    {
+        spin_unlock(cpufreq_statistic_lock);
+        return;
+    }
+
+    count = pmpt->perf.state_count;
+
+    for ( i = 0; i < count; i++ )
+    {
+        pxpt->u.pt[i].residency = 0;
+        pxpt->u.pt[i].count = 0;
+
+        for ( j = 0; j < count; j++ )
+            pxpt->u.trans_pt[i * count + j] = 0;
+    }
+
+    pxpt->prev_state_wall = NOW();
+    pxpt->prev_idle_wall = get_cpu_idle_time(cpu);
+
+    spin_unlock(cpufreq_statistic_lock);
+}
 
 /*
  * Get PM statistic info
@@ -518,34 +687,3 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
 
     return ret;
 }
-
-int acpi_set_pdc_bits(uint32_t acpi_id, XEN_GUEST_HANDLE(uint32) pdc)
-{
-    u32 bits[3];
-    int ret;
-
-    if ( copy_from_guest(bits, pdc, 2) )
-        ret = -EFAULT;
-    else if ( bits[0] != ACPI_PDC_REVISION_ID || !bits[1] )
-        ret = -EINVAL;
-    else if ( copy_from_guest_offset(bits + 2, pdc, 2, 1) )
-        ret = -EFAULT;
-    else
-    {
-        u32 mask = 0;
-
-        if ( xen_processor_pmbits & XEN_PROCESSOR_PM_CX )
-            mask |= ACPI_PDC_C_MASK | ACPI_PDC_SMP_C1PT;
-        if ( xen_processor_pmbits & XEN_PROCESSOR_PM_PX )
-            mask |= ACPI_PDC_P_MASK | ACPI_PDC_SMP_C1PT;
-        if ( xen_processor_pmbits & XEN_PROCESSOR_PM_TX )
-            mask |= ACPI_PDC_T_MASK | ACPI_PDC_SMP_C1PT;
-        bits[2] &= (ACPI_PDC_C_MASK | ACPI_PDC_P_MASK | ACPI_PDC_T_MASK |
-                    ACPI_PDC_SMP_C1PT) & ~mask;
-        ret = arch_acpi_set_pdc_bits(acpi_id, bits, mask);
-    }
-    if ( !ret && __copy_to_guest_offset(pdc, 2, bits + 2, 1) )
-        ret = -EFAULT;
-
-    return ret;
-}
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index 19e2992335..c2d777e0ec 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -588,6 +588,37 @@ out:
     return ret;
 }
 
+int acpi_set_pdc_bits(unsigned int acpi_id, XEN_GUEST_HANDLE(uint32) pdc)
+{
+    uint32_t bits[3];
+    int ret;
+
+    if ( copy_from_guest(bits, pdc, 2) )
+        ret = -EFAULT;
+    else if ( bits[0] != ACPI_PDC_REVISION_ID || !bits[1] )
+        ret = -EINVAL;
+    else if ( copy_from_guest_offset(bits + 2, pdc, 2, 1) )
+        ret = -EFAULT;
+    else
+    {
+        uint32_t mask = 0;
+
+        if ( xen_processor_pmbits & XEN_PROCESSOR_PM_CX )
+            mask |= ACPI_PDC_C_MASK | ACPI_PDC_SMP_C1PT;
+        if ( xen_processor_pmbits & XEN_PROCESSOR_PM_PX )
+            mask |= ACPI_PDC_P_MASK | ACPI_PDC_SMP_C1PT;
+        if ( xen_processor_pmbits & XEN_PROCESSOR_PM_TX )
+            mask |= ACPI_PDC_T_MASK | ACPI_PDC_SMP_C1PT;
+        bits[2] &= (ACPI_PDC_C_MASK | ACPI_PDC_P_MASK | ACPI_PDC_T_MASK |
+                    ACPI_PDC_SMP_C1PT) & ~mask;
+        ret = arch_acpi_set_pdc_bits(acpi_id, bits, mask);
+    }
+    if ( !ret && __copy_to_guest_offset(pdc, 2, bits + 2, 1) )
+        ret = -EFAULT;
+
+    return ret;
+}
+
 static void cpufreq_cmdline_common_para(struct cpufreq_policy *new_policy)
 {
     if (usr_max_freq)
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 309c0682cf..723045b240 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -35,169 +35,6 @@ struct cpufreq_driver __read_mostly cpufreq_driver;
 struct processor_pminfo *__read_mostly processor_pminfo[NR_CPUS];
 DEFINE_PER_CPU_READ_MOSTLY(struct cpufreq_policy *, cpufreq_cpu_policy);
 
-DEFINE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
-
-/*********************************************************************
- *                    Px STATISTIC INFO                              *
- *********************************************************************/
-
-void cpufreq_residency_update(unsigned int cpu, uint8_t state)
-{
-    uint64_t now, total_idle_ns;
-    int64_t delta;
-    struct pm_px *pxpt = per_cpu(cpufreq_statistic_data, cpu);
-
-    total_idle_ns = get_cpu_idle_time(cpu);
-    now = NOW();
-
-    delta = (now - pxpt->prev_state_wall) - 
-            (total_idle_ns - pxpt->prev_idle_wall);
-
-    if ( likely(delta >= 0) )
-        pxpt->u.pt[state].residency += delta;
-
-    pxpt->prev_state_wall = now;
-    pxpt->prev_idle_wall = total_idle_ns;
-}
-
-void cpufreq_statistic_update(unsigned int cpu, uint8_t from, uint8_t to)
-{
-    struct pm_px *pxpt;
-    struct processor_pminfo *pmpt = processor_pminfo[cpu];
-    spinlock_t *cpufreq_statistic_lock = 
-               &per_cpu(cpufreq_statistic_lock, cpu);
-
-    spin_lock(cpufreq_statistic_lock);
-
-    pxpt = per_cpu(cpufreq_statistic_data, cpu);
-    if ( !pxpt || !pmpt ) {
-        spin_unlock(cpufreq_statistic_lock);
-        return;
-    }
-
-    pxpt->u.last = from;
-    pxpt->u.cur = to;
-    pxpt->u.pt[to].count++;
-
-    cpufreq_residency_update(cpu, from);
-
-    (*(pxpt->u.trans_pt + from * pmpt->perf.state_count + to))++;
-
-    spin_unlock(cpufreq_statistic_lock);
-}
-
-int cpufreq_statistic_init(unsigned int cpu)
-{
-    uint32_t i, count;
-    struct pm_px *pxpt;
-    const struct processor_pminfo *pmpt = processor_pminfo[cpu];
-    spinlock_t *cpufreq_statistic_lock = &per_cpu(cpufreq_statistic_lock, cpu);
-
-    spin_lock_init(cpufreq_statistic_lock);
-
-    if ( !pmpt )
-        return -EINVAL;
-
-    spin_lock(cpufreq_statistic_lock);
-
-    pxpt = per_cpu(cpufreq_statistic_data, cpu);
-    if ( pxpt ) {
-        spin_unlock(cpufreq_statistic_lock);
-        return 0;
-    }
-
-    count = pmpt->perf.state_count;
-
-    pxpt = xzalloc(struct pm_px);
-    if ( !pxpt ) {
-        spin_unlock(cpufreq_statistic_lock);
-        return -ENOMEM;
-    }
-
-    pxpt->u.trans_pt = xzalloc_array(uint64_t, count * count);
-    if (!pxpt->u.trans_pt) {
-        xfree(pxpt);
-        spin_unlock(cpufreq_statistic_lock);
-        return -ENOMEM;
-    }
-
-    pxpt->u.pt = xzalloc_array(struct pm_px_val, count);
-    if (!pxpt->u.pt) {
-        xfree(pxpt->u.trans_pt);
-        xfree(pxpt);
-        spin_unlock(cpufreq_statistic_lock);
-        return -ENOMEM;
-    }
-
-    pxpt->u.total = count;
-    pxpt->u.usable = count - pmpt->perf.platform_limit;
-
-    for ( i = 0; i < count; i++ )
-        pxpt->u.pt[i].freq = pmpt->perf.states[i].core_frequency;
-
-    pxpt->prev_state_wall = NOW();
-    pxpt->prev_idle_wall = get_cpu_idle_time(cpu);
-
-    per_cpu(cpufreq_statistic_data, cpu) = pxpt;
-
-    spin_unlock(cpufreq_statistic_lock);
-
-    return 0;
-}
-
-void cpufreq_statistic_exit(unsigned int cpu)
-{
-    struct pm_px *pxpt;
-    spinlock_t *cpufreq_statistic_lock = &per_cpu(cpufreq_statistic_lock, cpu);
-
-    spin_lock(cpufreq_statistic_lock);
-
-    pxpt = per_cpu(cpufreq_statistic_data, cpu);
-    if (!pxpt) {
-        spin_unlock(cpufreq_statistic_lock);
-        return;
-    }
-
-    xfree(pxpt->u.trans_pt);
-    xfree(pxpt->u.pt);
-    xfree(pxpt);
-    per_cpu(cpufreq_statistic_data, cpu) = NULL;
-
-    spin_unlock(cpufreq_statistic_lock);
-}
-
-void cpufreq_statistic_reset(unsigned int cpu)
-{
-    uint32_t i, j, count;
-    struct pm_px *pxpt;
-    const struct processor_pminfo *pmpt = processor_pminfo[cpu];
-    spinlock_t *cpufreq_statistic_lock = &per_cpu(cpufreq_statistic_lock, cpu);
-
-    spin_lock(cpufreq_statistic_lock);
-
-    pxpt = per_cpu(cpufreq_statistic_data, cpu);
-    if ( !pmpt || !pxpt || !pxpt->u.pt || !pxpt->u.trans_pt ) {
-        spin_unlock(cpufreq_statistic_lock);
-        return;
-    }
-
-    count = pmpt->perf.state_count;
-
-    for (i=0; i < count; i++) {
-        pxpt->u.pt[i].residency = 0;
-        pxpt->u.pt[i].count = 0;
-
-        for (j=0; j < count; j++)
-            *(pxpt->u.trans_pt + i*count + j) = 0;
-    }
-
-    pxpt->prev_state_wall = NOW();
-    pxpt->prev_idle_wall = get_cpu_idle_time(cpu);
-
-    spin_unlock(cpufreq_statistic_lock);
-}
-
-
 /*********************************************************************
  *                   FREQUENCY TABLE HELPERS                         *
  *********************************************************************/
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index a3c84143af..241117a9af 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -20,8 +20,6 @@
 
 #include "processor_perf.h"
 
-DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
-
 extern bool cpufreq_verbose;
 
 enum cpufreq_xen_opt {
diff --git a/xen/include/acpi/cpufreq/processor_perf.h b/xen/include/acpi/cpufreq/processor_perf.h
index 301104e16f..6de43f8602 100644
--- a/xen/include/acpi/cpufreq/processor_perf.h
+++ b/xen/include/acpi/cpufreq/processor_perf.h
@@ -9,11 +9,9 @@
 
 unsigned int powernow_register_driver(void);
 unsigned int get_measured_perf(unsigned int cpu, unsigned int flag);
-void cpufreq_residency_update(unsigned int cpu, uint8_t state);
 void cpufreq_statistic_update(unsigned int cpu, uint8_t from, uint8_t to);
 int  cpufreq_statistic_init(unsigned int cpu);
 void cpufreq_statistic_exit(unsigned int cpu);
-void cpufreq_statistic_reset(unsigned int cpu);
 
 int  cpufreq_limit_change(unsigned int cpu);
 
@@ -56,7 +54,5 @@ struct pm_px {
     uint64_t prev_idle_wall;
 };
 
-DECLARE_PER_CPU(struct pm_px *, cpufreq_statistic_data);
-
 int cpufreq_cpu_init(unsigned int cpu);
 #endif /* __XEN_PROCESSOR_PM_H__ */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:17:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:17:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999061.1379786 (Exim 4.92)
	(envelope-from )
	id 1uKCv9-0001lk-3H; Wed, 28 May 2025 09:17:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999061.1379786; Wed, 28 May 2025 09: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 1uKCv9-0001lY-0e; Wed, 28 May 2025 09:17:59 +0000
Received: by outflank-mailman (input) for mailman id 999061;
 Wed, 28 May 2025 09:17:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCv7-0001jE-HX
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:17:57 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2412::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a2b298c8-3ba4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 11:17:55 +0200 (CEST)
Received: from SN4PR0501CA0121.namprd05.prod.outlook.com
 (2603:10b6:803:42::38) by SJ2PR12MB8692.namprd12.prod.outlook.com
 (2603:10b6:a03:543::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Wed, 28 May
 2025 09:17:49 +0000
Received: from SN1PEPF00036F42.namprd05.prod.outlook.com
 (2603:10b6:803:42:cafe::56) by SN4PR0501CA0121.outlook.office365.com
 (2603:10b6:803:42::38) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.13 via Frontend Transport; Wed,
 28 May 2025 09:17:49 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F42.mail.protection.outlook.com (10.167.248.26) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:17:48 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:17: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" 
X-Inumbo-ID: a2b298c8-3ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vtELuvqUjmE9If4ZLTj9dHDlGd8BKwsf8YatmKSpKFs/jauaoeTs5j4FYzcG+2yaXz+MZWwFYqO2O2bek4KEkMq0gHtBDFUtejcyYI/7JN8IcAU/g6jpreIRWWnLdVJBX1zRB2FrC85M6t3UnvvScv1331y9vEidtL8GG+/kLm9Snh4hBs8gNlN3l8FE2usr4a2pDK4LhcXTrq+Mh9woNkCx3+k89uAaeVbT7VdKAgY2eWuQSs8Ka3lEzvyVQe/+UsTV7cAdEW4+h/t6nVyxwmJKD3ZK9qjPEESY1xTp/a3IntsuVPwF50/JN/793D+sdMGNBSrvVzHAmNP4kigkNA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nEQJjo/wnWVr8f3Aer+P6n+okT/uMW1cOMLdB+X33/0=;
 b=e+IayQh7+7SRG97fa7AEBpXj6O4aMkQ/BqQ+N0q/kkMW5Zl+ixi3iRwwZWCoNdZt+pycVQ4zZahj/0/7i4Nkck++gT1LMpHAEr1vB5AxAyJw431LBbNkoc+vEFVqDcen5uS0nh33Or50lS0UjE13xYHpu2IxnsCSAwamC4S251p7aSIVf1mV8H6OuLaALBWF/D9Trfp/qaDgwAISjbbZQhVaHjm2skyMGfp7T6xdCUPGhDE6sQTd++/DuY6OoyQevIt3FSTsR+W2vV6FSeVdqlizXko+tc+vltcTGWdz+9indY0IWfanECdlDSnkIdoHLoims5WLmvwfMbcEbrQJtg==
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=nEQJjo/wnWVr8f3Aer+P6n+okT/uMW1cOMLdB+X33/0=;
 b=aH/fSU08nHzBl9BGD3LLYbd2pN99DyJvhHz0VOvtbIXKka8fqfde9h7juLg9dbG22TjTn6P9/cSgq4UZ/wZ1jPCtsI46x9HXk0VjVXXWuhR6OAraE1qoE4KY9S4grX2JDfRkwbDRzjBXiAQQIcgRP6K/2e9qPp4j1Y8g0ydYbTY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v4 03/20] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"
Date: Wed, 28 May 2025 17:16:51 +0800
Message-ID: <20250528091708.390767-4-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F42:EE_|SJ2PR12MB8692:EE_
X-MS-Office365-Filtering-Correlation-Id: ed927bc3-95d0-4425-c329-08dd9dc88401
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?66uNqdhPZh/3PfWpHzmKH1eZNta+L392t+5cXqaM0zP+jx8Ex+6/GutSCw12?=
 =?us-ascii?Q?oNUV/24Tp9xNq8MNaNgSamMaVSbC2KzHV+xsb7jVBSn95eMGsIUnUc0nc2di?=
 =?us-ascii?Q?f39XOR/Fbx4cU/gR+AxiUB2gi2uEztxxvW/ooaNxF4D82wrezM/qEZDdkwH9?=
 =?us-ascii?Q?3bMRvU4JCOZ7g0Ieh0D49Lw/81ukQduUqp/xekjXzHmkvpjOeh6934AStalN?=
 =?us-ascii?Q?b+8NoEQhsBBR10tin7tUmIhSAbyixz9EHGeZoAMyVSn0ZgH35an8UYnxy4FQ?=
 =?us-ascii?Q?U42I3/U3/ZfWJgymbYytfXBq0a5ZcwTPbf2ZQDFZGa9/kdouRNYBZV1rCzzM?=
 =?us-ascii?Q?5amv4f+U4wBJvql/rNOqDX/lzBAvBthLRaqcsYmOhSqy7dXgqKkdct+JGAhF?=
 =?us-ascii?Q?Fe7dDynSxzO9rgF3hGWskaON7mj2tp9bfHH5740D1bDh7ewhOJhHyDm+rLfq?=
 =?us-ascii?Q?Gogj9HmNp9Q/SacOOomzqiZOxXDSId9JeKrjfnYSELsCvqeyZkBjJwvCtlQv?=
 =?us-ascii?Q?il9PQCQavaTjLBK62QZnpUzfl9KB+35WIeDk46xvwMel2ZHMXAcK+vNFXFqG?=
 =?us-ascii?Q?fhR391TNX6WwJRNUH06wRSxYnQbmZVkehAteCZbKTwTWegsHe0vBNyk3Jnv6?=
 =?us-ascii?Q?WJ1qHaUxCrF+9HXJ0rGOTj+KTJKwf5vh5cfv6+4ONkdk+eae0GKslNMCsKnV?=
 =?us-ascii?Q?tN1b7lrqjUfm+f0TGVdHTQAVq3juPXDPzHCyQVb52ArxSHuBCLtjKtTZcQqb?=
 =?us-ascii?Q?H8BUuofxOynNU7Jig59lEykIR64GoUU7moT/aRU/MZfn3gzyJWy0m+K1faMe?=
 =?us-ascii?Q?oEqFZVokLyMg4nPG53Zl5hKdX4r9AsjV1qNeqbpxtKEy2/nlpEb0CfSnSf4L?=
 =?us-ascii?Q?Eo/OFCIkg+etH5fbvlYwXXA2m1Bfs6Px2Df3bUK4ge6aoY/JRgcW+1vvLZO9?=
 =?us-ascii?Q?imMDSGFLtpsCuks5RLIjTmIRho+RYHQ9HPKZndH8fV54mK12nTw3mob2AcZu?=
 =?us-ascii?Q?HCZ2FTH1BmgnV7rBz/jtGEJfEzDhHY40GOyMhB/eR1PMdDFRpuXCcKW1CvD1?=
 =?us-ascii?Q?jGODzMEdkFiHgOlL+iU6lRsyTUVKrh42PWyYGr5g4v+67TsW8n4ZUzzSLrng?=
 =?us-ascii?Q?g39ch+wa4g11bQuPxmIrW6DdZwH5JSgcXkN3NAKYtpWh+PC4uizFfQ++c57c?=
 =?us-ascii?Q?8c/IO+CUt8WktZsgk9P/vTJYljEEx9wiThct70CEWgZmpTq6ac3dh++XW9c3?=
 =?us-ascii?Q?5c7ZslvgimJGiOXz3tjQwr/FsbGMr+EcUv5omFL7YJDVnETq+ny5l4h6Sjrx?=
 =?us-ascii?Q?AjTFeG1OkhiqOdpbtzBgqUilQlVIzIl5UPXGESc71+ynyGj/fmoGrfAqbLpu?=
 =?us-ascii?Q?ggGUv4EVbpiqS+N+TxBEjNWNyszT0Dstyqh+Iy6X1A0HvDHCjqdouuUqdGyK?=
 =?us-ascii?Q?GQWUowOoihMAD2AOSC2IbTbQttIAAYX/wyAi02oMKltHLoTroAH4WDwRcdZq?=
 =?us-ascii?Q?SNNvfWRPM+NLRk4rP8Hg4ffYfRZBrd8+mJsi?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:17:48.9564
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ed927bc3-95d0-4425-c329-08dd9dc88401
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F42.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8692

Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally
equivalent "if !...") in Kconfig file, since negative dependancy will badly
affect allyesconfig. To make sure unchanging produced config file based
on "pvshim_defconfig", we shall explicitly state according Kconfig is not set

Add "default y" for SHADOW_PAGING and TBOOT, otherwise we will have unset
values when running make defconfig based on "x86_64_defconfig".

Signed-off-by: Penny Zheng 
---
v2 -> v3:
- remove comment for PV_SHIM_EXCLUSIVE
---
v3 -> v4:
- explicitly state "CONFIG_xxx is not set" in "pvshim_defconfig"
- Add "default y" for SHADOW_PAGING and TBOOT
- refactor commit message
---
 xen/arch/x86/Kconfig                  | 6 ++----
 xen/arch/x86/configs/pvshim_defconfig | 5 +++++
 xen/arch/x86/hvm/Kconfig              | 1 -
 xen/drivers/video/Kconfig             | 4 ++--
 4 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7afe879710..8c8e661d53 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -143,7 +143,7 @@ config XEN_IBT
 
 config SHADOW_PAGING
 	bool "Shadow Paging"
-	default !PV_SHIM_EXCLUSIVE
+	default y
 	depends on PV || HVM
 	help
 
@@ -175,7 +175,7 @@ config BIGMEM
 config TBOOT
 	bool "Xen tboot support (UNSUPPORTED)"
 	depends on INTEL && UNSUPPORTED
-	default !PV_SHIM_EXCLUSIVE
+	default y
 	select CRYPTO
 	help
 	  Allows support for Trusted Boot using the Intel(R) Trusted Execution
@@ -288,7 +288,6 @@ config PV_SHIM_EXCLUSIVE
 
 	  If unsure, say N.
 
-if !PV_SHIM_EXCLUSIVE
 
 config HYPERV_GUEST
 	bool "Hyper-V Guest"
@@ -298,7 +297,6 @@ config HYPERV_GUEST
 
 	  If unsure, say N.
 
-endif
 
 config REQUIRE_NX
 	bool "Require NX (No eXecute) support"
diff --git a/xen/arch/x86/configs/pvshim_defconfig b/xen/arch/x86/configs/pvshim_defconfig
index 2ad27f898e..6f652e145e 100644
--- a/xen/arch/x86/configs/pvshim_defconfig
+++ b/xen/arch/x86/configs/pvshim_defconfig
@@ -26,3 +26,8 @@ CONFIG_EXPERT=y
 # CONFIG_INTEL_IOMMU is not set
 # CONFIG_DEBUG is not set
 # CONFIG_GDBSX is not set
+# CONFIG_SHADOW_PAGING is not set
+# CONFIG_TBOOT is not set
+# HYPERV_HYPERV_GUEST is not set
+# CONFIG_HVM is not set
+# CONFIG_VGA is not set
diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
index 2def0f98e2..b903764bda 100644
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -1,6 +1,5 @@
 menuconfig HVM
 	bool "HVM support"
-	depends on !PV_SHIM_EXCLUSIVE
 	default !PV_SHIM
 	select COMPAT
 	select IOREQ_SERVER
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 245030beea..66ee1e7c9c 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -3,10 +3,10 @@ config VIDEO
 	bool
 
 config VGA
-	bool "VGA support" if !PV_SHIM_EXCLUSIVE
+	bool "VGA support"
 	select VIDEO
 	depends on X86
-	default y if !PV_SHIM_EXCLUSIVE
+	default y
 	help
 	  Enable VGA output for the Xen hypervisor.
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:17:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:17:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999062.1379790 (Exim 4.92)
	(envelope-from )
	id 1uKCv9-0001oK-DV; Wed, 28 May 2025 09:17:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999062.1379790; Wed, 28 May 2025 09: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 1uKCv9-0001nX-7g; Wed, 28 May 2025 09:17:59 +0000
Received: by outflank-mailman (input) for mailman id 999062;
 Wed, 28 May 2025 09:17:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCv8-0001jE-6p
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:17:58 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2415::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a340abee-3ba4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 11:17:56 +0200 (CEST)
Received: from SN4PR0501CA0114.namprd05.prod.outlook.com
 (2603:10b6:803:42::31) by MW4PR12MB6827.namprd12.prod.outlook.com
 (2603:10b6:303:20b::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Wed, 28 May
 2025 09:17:52 +0000
Received: from SN1PEPF00036F42.namprd05.prod.outlook.com
 (2603:10b6:803:42:cafe::98) by SN4PR0501CA0114.outlook.office365.com
 (2603:10b6:803:42::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.15 via Frontend Transport; Wed,
 28 May 2025 09:17:52 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F42.mail.protection.outlook.com (10.167.248.26) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:17:52 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:17: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" 
X-Inumbo-ID: a340abee-3ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rN0KWN0Cj7UQ7m5uKuGlie0Kr4uUvGzGzxqWOI3SF32pCPtAl70EMWW1gKzVIbWE0CqGiGKAixRA9Kpo1sMgG+K8C8SwGM3z8aTB6KU6VtRIrTCtiYfifiJ6HzQcTUKI1Sbl/OmUcO8hXu/yX+b5PreZnOHIGRoSO98mKLb6p8a98x+bvuPUszcXx683+cY7NOJ6pc+K5Q66D02YUUzZLgQTrfrsLOEwS5ux3UhYTP1vU+NXYN34lfoV3W7J9N1UM8tuUaraMjDZggBU5U3bI6fwUOgiYNY6ILqenMhxOgk01hYGRjgBqG4IOo2CSy1Rzrp5aVVl6Kw7HkNV3J/yeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IInfV2ukP7/cIfBLXmKwCiycp7vzTCpHzRB2edrn7tA=;
 b=ZEntzBlcHHYccXcyiXdlpeSIvehJbF4C0FGlTpj2pc7etUs9pnRxMrqsPgdYdvLPwjRIgSUh3XKvdA9TCwA+ODXl16wq+iGP+pXKmtNCZ262BFqgSaJnzDhP6Jx66mB2yl81L7C7tKWSpIUEdatfBzTxerqaZYsq7Q+Z/XkoVmqfekj0ckHwnYGksrqpBrvK+REpB4fJuXc+CfL9LfdbuIb984AJ0OWdksEIfGISOq1RpdkT4RnBJ1asQtEJ2bDKs2g+yAtPh1/HLSpxfxz2+flD9GfJvdDEBl8NsUU+B/W7sc/H/R+DEM4b1nTMNMTraWBPmkfIuwrLaHQakSBeQg==
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=IInfV2ukP7/cIfBLXmKwCiycp7vzTCpHzRB2edrn7tA=;
 b=U2WkvG00t2wc5ivWH5T+jZtKgdt2qlRJoBoVSk8zBTkScjQunEJI+xv1qVuDdpWgW03r7CnQpSjd7F3YB41clsrIfmDvss9TtJoyb9tbGtkMED/xTCjkbAMr+1acrzaRYpzBlwn728/OGPr2W1nXjS318aeRRbDSzEFIC6dRX3A=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Stefano Stabellini ,
	Andrew Cooper , Anthony PERARD
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Sergiy Kibrik ,
	Penny Zheng 
Subject: [PATCH v4 04/20] xen: introduce CONFIG_SYSCTL
Date: Wed, 28 May 2025 17:16:52 +0800
Message-ID: <20250528091708.390767-5-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F42:EE_|MW4PR12MB6827:EE_
X-MS-Office365-Filtering-Correlation-Id: 6af7723b-2623-4f05-a6d8-08dd9dc885eb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?RUm6UfY61yUKgzzTGCB5svrBqvDANV084lmt9bRDIx9zxNjbbmhSg5VXuBsf?=
 =?us-ascii?Q?XImz05P9kJ1eNiDHDqYIYSmpEefFEkiFtjTgNcukQoo1vHHG0c9aDxcHAKWZ?=
 =?us-ascii?Q?jLAao3GpBcZUCdVAoknYUQ1ctuwxz/rt6SoFTBHJJB1UDKvrVYjwEXPe8ux8?=
 =?us-ascii?Q?pLWmIJRRSUjDAufGIysoW0q3k10OU4JUboQr90G8fqngGhp7T9gcMuMHFnZN?=
 =?us-ascii?Q?LUthFXpKB/n8Dy1hNUJRRgy6gYGe/P2qlIEaq0IvLzSokQSj5LeNetrRe/AT?=
 =?us-ascii?Q?lcouxOQNnnZJZ7oeMBVCxn+fURLAsoeKBS1nkemAdihOCWEv1oKcjCbU+oOG?=
 =?us-ascii?Q?jLvSbEaN6XF7zMrhDfz8skudzW8JiO171FArBu5bsaoo9ODF5iuIxZ4FOB72?=
 =?us-ascii?Q?nNobK2em/qYu/Hd5rt2zMib0zy9Er66N4MxufCBr+P0V5ZdbJtjO1vKWVNI0?=
 =?us-ascii?Q?EPYG0W+mChYTn8sZBeCL9gqSR06WzqXPxwNsO5ZsrG1zSOO4Zyi1LrH/9evy?=
 =?us-ascii?Q?NAbFBdjPFnqkImHvw/ebfR26+Z0bahXY/QMf4GOaOLXrYycN2FBnacDsr6Bd?=
 =?us-ascii?Q?wGhLxyhs3eRiqI3C/uj83oLidG9Tb0SbkQV41KcPiwwHElvjIFiDCZjIaMz9?=
 =?us-ascii?Q?crKvje5XuEuh6euSBOAVomXO2+vVQ8xf6gwo2RQGPnrXW7ivwp6OKSgKIjS6?=
 =?us-ascii?Q?IJg9Slk2ZifiG00QL5p/cUUez2nNJ2ep7muqAQOT8KO+JzI7DE48kHK32ylP?=
 =?us-ascii?Q?tIkpmlgAt6Upu0Id1Qkz60ji7kQjff3dvDCEK94K+Voz+vFtQdoUPd8pfmNp?=
 =?us-ascii?Q?mDrd/aoqEKF4NmW+go3pZGwCG91OZHrFhRNSB944vPAtXA/t1fnKMqhHiW01?=
 =?us-ascii?Q?ocDuNaA3oRcNzMe7yPdsivgqe4p6Epxv9qKLmWGXF+2cclRQNmfaK2zp12SJ?=
 =?us-ascii?Q?7uAVPweDdsXNRGhbpek8psD8kHMvtUSOF1GpB1GjrZ8iV7HneQAzPLYj1BMi?=
 =?us-ascii?Q?q8vB7+JZtP56lFwZ2QlJCn6qKCSu5Av18wAX6RQ45ZqpNPBXzXeT+QDK7vpG?=
 =?us-ascii?Q?WGZd0afnmABwlOryTs11FH+wCXJW73/xudgPqhZgSD0QxV/NOpCFa9AbfLUW?=
 =?us-ascii?Q?S6khBsKh64t8P4WG5tzei3QHPDxR0Wo0m+JyIs3thS5D0dXhODBnM9/8KdK+?=
 =?us-ascii?Q?2RcV8dyyxSx56CqG0XwVV62aiyO0u6HGhbn7eM5zrFIvtcudlncTTD0DD79F?=
 =?us-ascii?Q?7YbeBQ8guCA+Sn8ZB0ZOTnCyqy8xr8YGLVc6F2P0nx8dNAma7/grYMZlinh9?=
 =?us-ascii?Q?by5pzZ2eN1Ks0qLtEGNwpuCpw+hyz8J/O+ximPxNY6Vk1uQsjvEU1PHOd3ZE?=
 =?us-ascii?Q?F953eIdsfJc1+hbtZ1y8DtR/5Melwz/Zr0/IP21mQwAb8/rjUYboY6L8rn4/?=
 =?us-ascii?Q?IaJyxOCKD2zCBTKMi/sRIQvE4iH2r384lyupQqLucsSrSM8GD19A0V8rT/SA?=
 =?us-ascii?Q?JCggcwz/srcP7uzZq4Uussil3NmVq6JoIRlY?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:17:52.1677
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6af7723b-2623-4f05-a6d8-08dd9dc885eb
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F42.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6827

From: Stefano Stabellini 

We introduce a new Kconfig CONFIG_SYSCTL, which shall only be disabled
on some dom0less systems or PV shim on x86, to reduce Xen footprint.

Making SYSCTL without prompt is transient and it will be fixed in the final
patch. Also, we will also state unsetting SYSCTL in pvshim_defconfig to
explicitly make it unavailable for PV shim in the final patch.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Sergiy Kibrik 
Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v2 -> v3:
- remove "intend to" in commit message
---
v3 -> v4:
- introduce the option without prompt (simply "defbool y") to eliminate the
need for transient "#ifdef CONFIG_SYSCTL"
- calling out the transient scenario in commit message
---
 xen/common/Kconfig | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 3d66d09397..28e6ac2142 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -579,4 +579,15 @@ config BUDDY_ALLOCATOR_SIZE
 	  Amount of memory reserved for the buddy allocator to serve Xen heap,
 	  working alongside the colored one.
 
+menu "Supported hypercall interfaces"
+	visible if EXPERT
+
+config SYSCTL
+	bool "Enable sysctl hypercall"
+	def_bool y
+	help
+	  This option shall only be disabled on some dom0less systems,
+	  to reduce Xen footprint.
+endmenu
+
 endmenu
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:18:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:18:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999063.1379805 (Exim 4.92)
	(envelope-from )
	id 1uKCvA-0002FV-RK; Wed, 28 May 2025 09:18:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999063.1379805; Wed, 28 May 2025 09: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 1uKCvA-0002EX-MK; Wed, 28 May 2025 09:18:00 +0000
Received: by outflank-mailman (input) for mailman id 999063;
 Wed, 28 May 2025 09:17:59 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCv9-0001jE-6t
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:17:59 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20624.outbound.protection.outlook.com
 [2a01:111:f403:2408::624])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a4871c12-3ba4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 11:17:57 +0200 (CEST)
Received: from SN7PR18CA0015.namprd18.prod.outlook.com (2603:10b6:806:f3::6)
 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.20.8769.27; Wed, 28 May
 2025 09:17:54 +0000
Received: from SN1PEPF00036F41.namprd05.prod.outlook.com
 (2603:10b6:806:f3:cafe::54) by SN7PR18CA0015.outlook.office365.com
 (2603:10b6:806:f3::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Wed,
 28 May 2025 09:17:54 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F41.mail.protection.outlook.com (10.167.248.25) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:17:53 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:17:51 -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" 
X-Inumbo-ID: a4871c12-3ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=E3aUIuUz0AG6CxhWJB11fyYZwqROfw4TFutkkodra1GAycoyY0I2ZkFMc4otD745YQRUpsmJsBjwoWeQGQEsQSh2DpDdtjfaxWbIWt7szwgagsurnyi/hG3B39uQvw4TF8IASg9ViFfUdSij9uGMo1Y8C87rfdGYbhUllo1ikT3WkK6nJWn/VaxxXMr06zNMY5NCXUbl0QyFCEYLUzUEz60CtMTCLa2Fu9n0Qkk7XtUDgpPkn7SzWCv3ubElhYGfDbrSl/MoetvU9Qk5DWFyDQsgFDJ8z6i5eNMs40xE36XQRrETU6WGVYyAvWa6pdbst+rlYpYSvHE2hKYnq0iLDg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XWDCQOD66ZKbLyRJ3ZdoNMgnP/71ZQbglzYq68MUnMQ=;
 b=xpnhPImnB73CSTsAbAwuXlRNBiSoLzb9XvuI3a2HBcBAKOTZfRZ5iEoc7uaL77owWMRCG4Y6uhkocHC0HvjX0Z22+ZySYjMENOsOwTEABc+PMTbSj2ZxqtMyHiC+LGMzWdTdf0J5O3If7QlCjEtQYHknQvvas3zdcxeeyaHM8e4FKWHy2ut3in1DmpBrj+BOD+FGOt6jX6hXFPr6b9ojiqoRmv1Eut59PdWvgbs3/GKTWgTUliZJ/+ruy6cDSVo+c9RzEQ0bb0B7yI7NMUaechmkKTerJF3PM1dfTf5WbGhkwT+ZZVS0FAJnDZ9YNC1SVXrZHMjlaNN7CjLheWUM/A==
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=XWDCQOD66ZKbLyRJ3ZdoNMgnP/71ZQbglzYq68MUnMQ=;
 b=2vZSF/Vfm9rc4GL50HJKlTHW9qUgXfz7IpFBwjEz4EYRFD0dbBkISPKPBZVoCSkJtqlnVHpH6WfWH1fhlxd51XpcRel7wdqRgluA3iv1JdR25Ew9cd9xTBN9N+mZn2OTKEZ+PJ06gCONvxjtkCUogxoATDoiYMY3lTK2yVCUD2I=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , "Daniel P. Smith"
	, Stefano Stabellini 
Subject: [PATCH v4 05/20] xen/xsm: wrap around xsm_sysctl with CONFIG_SYSCTL
Date: Wed, 28 May 2025 17:16:53 +0800
Message-ID: <20250528091708.390767-6-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F41:EE_|SA0PR12MB4366:EE_
X-MS-Office365-Filtering-Correlation-Id: 2388eed9-0070-4b79-4c89-08dd9dc886d4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?VEUdW4W8l6HYAwK1vUez4gxzVaffOJPXtITZyFiGYdEkrk4W8EkdEkjpNAtk?=
 =?us-ascii?Q?c2/lbDb2xg6ROe1aZOCxj/eggy9gHnQw0DzxMI8ltFQjY/YRwhQWCbhxD1jJ?=
 =?us-ascii?Q?Da69drKAon8hqZFWoRkHPqyq02JoPNTRLoW3GTcLJrSZ9WkmMqVBzhZGQUZR?=
 =?us-ascii?Q?gpiJbU6yPG0yFi8w7X+K1yKNbKPYjGJ+tNBiRhNFotaIzqvop9sZjp2K2FAg?=
 =?us-ascii?Q?8INDiKxUzoz29cXJ14D5Bj/8AoNqu28p6alF4Pi2qdbNAph62ms5NcjJy/K1?=
 =?us-ascii?Q?rIhlvDBuj0LwpUajQm4sCHTtb294TzVO5AnWHt+MOwpp+pklZLSNhOdy7K+p?=
 =?us-ascii?Q?mbQe96B9ug25XP4HnU0DFwI2Ki9f+Mai2fSx8FqoqrdoPjHQyPi/jyztR+yl?=
 =?us-ascii?Q?znHZttENgvN3lU7Hf0sgk4KUtd60GAFr/6E1IBVpmKDImEFIcq8xHu70KecW?=
 =?us-ascii?Q?h8R4Dt4MRJlVO33aKLcQTtdsJUujSx8EZnBXWBAmLVp+z4RS24mIR+Jgwk0f?=
 =?us-ascii?Q?hPzsvGkp7cDq0cbRHbZPaudJbL51zZU2Nu6trsNRwX74RaJhGqPM+I3InV8m?=
 =?us-ascii?Q?qkX4Ped9SRgceR0uNIgaiansPU01/SM2dESXf5D9RKxoauW1uqQGJSsaiBLk?=
 =?us-ascii?Q?AOsVRVzkZ8beT0FuIcs3F/lkynANGmyIUrMx9IdhSWFVymBQ0zmv0gr1n+sl?=
 =?us-ascii?Q?Uyq0+qCCaV9e/pc6keU9dD37vFAFR+qKwqGpdMQq1XLuZruZDc5rACbhyx2g?=
 =?us-ascii?Q?04f5yMV8M+qJTCgjFvfxrOwAPAmdppfJvMN5dPoU+dVaA8jw7t9koxU8G2W8?=
 =?us-ascii?Q?Iijz2Ne+WpCOvHiygZhs869Qz1KVNn6nF4X1/2LzZxQ315cQUdPjGuklvq78?=
 =?us-ascii?Q?q43BfX5sH8NoTt8jPH2RW1+0+h8KFFXfNA8rDVEEMQTRwNHwnCbxR3FvknGK?=
 =?us-ascii?Q?ZaFgIqDhaa/m9ivuMVashW2Rf0n44k/Fd+fNgEkCIizZdiXT5D12XiMck0PG?=
 =?us-ascii?Q?d99qKUsMS8TfyAkTKiOYGgAMKLH8RKh2ATcEQCfHM5jK/5KwseXayoLRtUi8?=
 =?us-ascii?Q?t4wz0FOzlBZxfzLbZoYesDrb3lUaiSx1/tg0pOF1x4rE6i4O8tYVWUFKW08K?=
 =?us-ascii?Q?Pqtp15PI3x78kg81DxQY9/lcwy9RfftWhTiUP6CV6EyMPIp87h9bPoQ3A8A4?=
 =?us-ascii?Q?+fDk3tX8TvynkjeOd5t1eLnrdcfipw3+7qKrO3cS4uX0Lx8Hl6FCGri+90Je?=
 =?us-ascii?Q?bur+locHgLhJpYduVaNxq21x4YwGQxnUAs3ILdJvJIWWwmsCvXqrcswp3IaO?=
 =?us-ascii?Q?hSrR+sY0JHiYTjwH0HB1mepYlBbarhQewfqPEzxucHl3RZu4NWmomeXfXokC?=
 =?us-ascii?Q?2YsZmdNo/JRUV0mo0avkGx2UaTfBobgRsO2+Rny8dF+KJCqLqH6dJCHAyFks?=
 =?us-ascii?Q?pBwWn9daVKdVrNKJdDnrxSFmSbg5lmBnz0ApmY/ZPFvU41Inu9WUa89LQeHl?=
 =?us-ascii?Q?atSHxmR0GZL16S/MW2/YBhAc9mPgAxqo/VUa?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:17:53.6852
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2388eed9-0070-4b79-4c89-08dd9dc886d4
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F41.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4366

As function xsm_sysctl() is solely invoked in sysctl.c, we need to
wrap around it with CONFIG_SYSCTL

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
 xen/include/xsm/xsm.h | 4 ++++
 xen/xsm/dummy.c       | 2 ++
 xen/xsm/flask/hooks.c | 4 ++++
 3 files changed, 10 insertions(+)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 24acc16125..22e2429f52 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -261,7 +261,11 @@ static inline int xsm_domctl(xsm_default_t def, struct domain *d,
 
 static inline int xsm_sysctl(xsm_default_t def, int cmd)
 {
+#ifdef CONFIG_SYSCTL
     return alternative_call(xsm_ops.sysctl, cmd);
+#else
+    return -EOPNOTSUPP;
+#endif
 }
 
 static inline int xsm_readconsole(xsm_default_t def, uint32_t clear)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 93fbfc43cc..93a0665ecc 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -22,7 +22,9 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .sysctl_scheduler_op           = xsm_sysctl_scheduler_op,
     .set_target                    = xsm_set_target,
     .domctl                        = xsm_domctl,
+#ifdef CONFIG_SYSCTL
     .sysctl                        = xsm_sysctl,
+#endif
     .readconsole                   = xsm_readconsole,
 
     .evtchn_unbound                = xsm_evtchn_unbound,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6a53487ea4..3a43e5a1d6 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -856,6 +856,7 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     }
 }
 
+#ifdef CONFIG_SYSCTL
 static int cf_check flask_sysctl(int cmd)
 {
     switch ( cmd )
@@ -933,6 +934,7 @@ static int cf_check flask_sysctl(int cmd)
         return avc_unknown_permission("sysctl", cmd);
     }
 }
+#endif /* CONFIG_SYSCTL */
 
 static int cf_check flask_readconsole(uint32_t clear)
 {
@@ -1884,7 +1886,9 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+#ifdef CONFIG_SYSCTL
     .sysctl = flask_sysctl,
+#endif
     .readconsole = flask_readconsole,
 
     .evtchn_unbound = flask_evtchn_unbound,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:18:06 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:18:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999067.1379816 (Exim 4.92)
	(envelope-from )
	id 1uKCvG-0002ir-2i; Wed, 28 May 2025 09:18:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999067.1379816; Wed, 28 May 2025 09:18: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 1uKCvF-0002ia-VB; Wed, 28 May 2025 09:18:05 +0000
Received: by outflank-mailman (input) for mailman id 999067;
 Wed, 28 May 2025 09:18:05 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvF-0000yL-8a
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:05 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20607.outbound.protection.outlook.com
 [2a01:111:f403:2405::607])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a85e61ee-3ba4-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:18:03 +0200 (CEST)
Received: from MW4PR04CA0062.namprd04.prod.outlook.com (2603:10b6:303:6b::7)
 by SN7PR12MB7105.namprd12.prod.outlook.com (2603:10b6:806:2a0::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.23; Wed, 28 May
 2025 09:17:59 +0000
Received: from SN1PEPF00036F3F.namprd05.prod.outlook.com
 (2603:10b6:303:6b:cafe::cd) by MW4PR04CA0062.outlook.office365.com
 (2603:10b6:303:6b::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.19 via Frontend Transport; Wed,
 28 May 2025 09:17:58 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F3F.mail.protection.outlook.com (10.167.248.23) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:17:58 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:17: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" 
X-Inumbo-ID: a85e61ee-3ba4-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=B66ofrYcdS8hRX4OqQIujY8x5VZyws54qL9DTCYX8wkTCgNTqtw1i2CVLCsPPMt8CIbtnYp3XlHp3VwwaLbC3qqDJyp5l8FYEkyKCCRGUQYNmc0paJ6M1Uhm7CvMRkhiySjN+B4ZkckEBxzCgHV3C+zj+Ko5k+5DQtc+HURT2BStQqassOo4RQShS4+t5o/+Rb8omUnFZ6WASnVBvhgIazStbHwFSH6DmxYM+QdcE37NkxL0pZaxN52WMzhux9/zrHoNUTeOBd/v6AxFlFOqPN2o3BxhRk9Ocbor3YeAD8wjWeucDdQwfBc0Ukiw+xIqkQhYY1Zq25PUVIOEhXaNHw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qImUlx0P5uZHWU7BQHSJftezN9uBylMqS/nrwHVyNac=;
 b=lfXCN/48/qlOsu0zGLNsegQ+6/plB1EdTce/z9fCHjMuHXB3AgoPJDBOq5UvmhiKRvr1YnVOJegHNh/X4HyrcYnhqDMv3YL7YlpiF0fyRe60nPrew1quaZq+78nIN2gOZl+qkFPCPHp4M3C5267iAAaQ1K/GpOFVgT95MGHsXMI86Wa3YcqZkGlPL7xSpS9MfAFRZm1/i6oXQLXaQT0k7lvzQbd8HtiAuRU4BeqBJWwKJ+aR0/wDFf21Bp1e7gupNyqou7SB67PdJffLMUdzBaf1WT/76vHsQY0Z5edGSBt2BjRy3RgyWztC4SFY1EyGnewoGzLSLZnz2rILqGm6Kg==
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=qImUlx0P5uZHWU7BQHSJftezN9uBylMqS/nrwHVyNac=;
 b=jlINwZBveFZu5KTSCPWLDxguqyFPVEi33vY06XnyrljL5Bclo1mbDjsaWNo2h6/Jp5J5IMoLSlZ/vTQ09s6r6VpyS1BPjicyuSHkb66Tobb4FstCRr5tQ+cDRQasqcaEmn6TXWeVGCTqmfVyujbkx7/M7CdAnlaVfuBCSXp0rnY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini , "Daniel
 P. Smith" 
Subject: [PATCH v4 06/20] xen/sysctl: wrap around XEN_SYSCTL_readconsole
Date: Wed, 28 May 2025 17:16:54 +0800
Message-ID: <20250528091708.390767-7-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F3F:EE_|SN7PR12MB7105:EE_
X-MS-Office365-Filtering-Correlation-Id: b0c19b35-1c55-41fc-c8e7-08dd9dc88971
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Rschc184AdWvIMqbMStz/gIZkMGjGRtGkmuh3ZLbVZsXAI6VgDhHU2ebCd9q?=
 =?us-ascii?Q?HJizJPuMZtdV5gihk2dizNbqCUKGMBpOe3Rsjicwsm5ER/2pHzOKejUSgeq+?=
 =?us-ascii?Q?CzDjZ6/fonAD/Y+gNUKxXqUarI0U4EirAN1neqHVi91x0Go5We97eOz8jX3C?=
 =?us-ascii?Q?+K6Oeo3+PbpmyWit1RljS7ygxq+37ds+tu5FyEYDnRlOJuOHQ3zgIuxPV0Ae?=
 =?us-ascii?Q?s/UGKpb5TWU+FiJK2OagNP/64q2Gi+YOw+FyMMQyMf8tgFjfTIboayHLW7k4?=
 =?us-ascii?Q?cPaJzzMio87TYwy1mMWAXT4zWEYEjdMg5N1wWGKxz8+vlOnImx4FOX5+Jmcm?=
 =?us-ascii?Q?6woFAppqYzTpI/Co4LOkXX6r9l+1OLSe8QbyZCPCx7I2WBSlIChe60NkwhXd?=
 =?us-ascii?Q?qFYzeuZGMOp3c0AtitNC8ix0X/INhSvkrELS3mOlpfWHNJLelZwtQaddi2MR?=
 =?us-ascii?Q?4ZHuZPAqjrlAGLOF+dyIW0XQ20cV8tRsUFSuzFhxaLbbo51YL1KZmFZ5/BnX?=
 =?us-ascii?Q?tPVPLrlpqkBu8FWKKSVHqoEypTPzi8Ki/svWTpARUecg2R4TXtSayELP1fAa?=
 =?us-ascii?Q?dOO3LJKQ7oR+JGUklTDR/Jt5DcgAeT3VhH9FeogJufw5GFs1R/7UULRF/APN?=
 =?us-ascii?Q?R4XmGkevp0NkgF//zFuumelo2A32+Bp3o2gLT+QffrWcmFcGG8vOHTM+SLCX?=
 =?us-ascii?Q?barj8nfpQs8afPObUhFizSBlLEsEeC3I65bna7hwOGQmBiIzUwTm90GiSUNF?=
 =?us-ascii?Q?A247RT3386aOAAvdehE4b0Tg2T76qP0fhQNiyIqcmqwsF86IlgAyGcr6h5mJ?=
 =?us-ascii?Q?3hOhR8q02ffoEz8U1k0wAYFgLn/E7Y+OTYDcfrQwHlSNvbUgvFSXONSMWc83?=
 =?us-ascii?Q?NYW00gsHCKWUKd/94qK14iQdQVtIK6bdTHe3IfumQtcigZYGWqpbeQVG4lD3?=
 =?us-ascii?Q?U7buVAuuSLw7zJIBfhCgfWsoo4mE6HPrl0hwBRACLTXdqVXl/6LxUZxu9XaA?=
 =?us-ascii?Q?Ni206UN7vVQBrfI8fs5NhKUGO90Mpzr3UoTp4snSnN1467UKt9wuUF46nwjS?=
 =?us-ascii?Q?aoJ1HLGZTuk3dz0XFZZQixgNDKKbjeRXcPnRaLxCfU1SJOE7aXStfq7+6DpZ?=
 =?us-ascii?Q?fgfniyeu3nPzdMEYjS9AIiw0XohjL/iANxyWM39eiOK7q1kWZH69q2a0ho1T?=
 =?us-ascii?Q?dugqMCNGT6YINXEsygq7/LUfi/K3e6QW6p4VWRJ3uzuBonet1vxzhTX4hjgF?=
 =?us-ascii?Q?+UGjCPrpn6p2WASbNiX32qyZ0Zt7eKDA+heBTfHQHaG6H+XQI1LrHXPT09H9?=
 =?us-ascii?Q?BinXvcVhs9VbED2u05uRcDbSeM5oy1eJ+IpATdFhOfq91RDh8mmGIamdDxz4?=
 =?us-ascii?Q?oyVXMxbf/Wbgr9hlUjDtq4irKlqCKG+NYBHDLiIX42Q/EPcOFMeVsBqyvxx4?=
 =?us-ascii?Q?5DhB2zyWzEk4gQdeDNl5PMN6KMpIbMX9SEMC5cqdTu9Lg2jDRh8bm6VJApaj?=
 =?us-ascii?Q?2nSwCK1NPLDCqJ2Zts/qJfq1/VeO/kh4Gpcj?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:17:58.0779
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b0c19b35-1c55-41fc-c8e7-08dd9dc88971
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F3F.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7105

The following functions is to deal with XEN_SYSCTL_readconsole sub-op, and
shall be wrapped:
- xsm_readconsole()
- read_console_ring()

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v2 -> v3:
- move #endif up ahead of the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/drivers/char/console.c | 2 ++
 xen/include/xsm/xsm.h      | 4 ++++
 xen/xsm/dummy.c            | 2 +-
 xen/xsm/flask/hooks.c      | 4 ++--
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c15987f5bb..2413cd6c51 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -368,6 +368,7 @@ static void conring_puts(const char *str, size_t len)
         conringc = conringp - conring_size;
 }
 
+#ifdef CONFIG_SYSCTL
 long read_console_ring(struct xen_sysctl_readconsole *op)
 {
     XEN_GUEST_HANDLE_PARAM(char) str;
@@ -410,6 +411,7 @@ long read_console_ring(struct xen_sysctl_readconsole *op)
 
     return 0;
 }
+#endif /* CONFIG_SYSCTL */
 
 
 /*
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 22e2429f52..042a99449f 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -270,7 +270,11 @@ static inline int xsm_sysctl(xsm_default_t def, int cmd)
 
 static inline int xsm_readconsole(xsm_default_t def, uint32_t clear)
 {
+#ifdef CONFIG_SYSCTL
     return alternative_call(xsm_ops.readconsole, clear);
+#else
+    return -EOPNOTSUPP;
+#endif
 }
 
 static inline int xsm_evtchn_unbound(
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 93a0665ecc..cd0e844fcf 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -24,8 +24,8 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .domctl                        = xsm_domctl,
 #ifdef CONFIG_SYSCTL
     .sysctl                        = xsm_sysctl,
-#endif
     .readconsole                   = xsm_readconsole,
+#endif
 
     .evtchn_unbound                = xsm_evtchn_unbound,
     .evtchn_interdomain            = xsm_evtchn_interdomain,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 3a43e5a1d6..df7e10775b 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -934,7 +934,6 @@ static int cf_check flask_sysctl(int cmd)
         return avc_unknown_permission("sysctl", cmd);
     }
 }
-#endif /* CONFIG_SYSCTL */
 
 static int cf_check flask_readconsole(uint32_t clear)
 {
@@ -945,6 +944,7 @@ static int cf_check flask_readconsole(uint32_t clear)
 
     return domain_has_xen(current->domain, perms);
 }
+#endif /* CONFIG_SYSCTL */
 
 static inline uint32_t resource_to_perm(uint8_t access)
 {
@@ -1888,8 +1888,8 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .domctl = flask_domctl,
 #ifdef CONFIG_SYSCTL
     .sysctl = flask_sysctl,
-#endif
     .readconsole = flask_readconsole,
+#endif
 
     .evtchn_unbound = flask_evtchn_unbound,
     .evtchn_interdomain = flask_evtchn_interdomain,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:18:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:18:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999069.1379826 (Exim 4.92)
	(envelope-from )
	id 1uKCvJ-0003BD-FN; Wed, 28 May 2025 09:18:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999069.1379826; Wed, 28 May 2025 09:18:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKCvJ-0003B6-CJ; Wed, 28 May 2025 09:18:09 +0000
Received: by outflank-mailman (input) for mailman id 999069;
 Wed, 28 May 2025 09:18:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvI-0001jE-96
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:08 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20602.outbound.protection.outlook.com
 [2a01:111:f403:2415::602])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a9c3109e-3ba4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 11:18:06 +0200 (CEST)
Received: from SN7PR18CA0015.namprd18.prod.outlook.com (2603:10b6:806:f3::6)
 by PH7PR12MB7020.namprd12.prod.outlook.com (2603:10b6:510:1ba::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Wed, 28 May
 2025 09:18:03 +0000
Received: from SN1PEPF00036F41.namprd05.prod.outlook.com
 (2603:10b6:806:f3:cafe::fe) by SN7PR18CA0015.outlook.office365.com
 (2603:10b6:806:f3::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Wed,
 28 May 2025 09:18:03 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F41.mail.protection.outlook.com (10.167.248.25) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:03 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:17:59 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a9c3109e-3ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gjZktzLymzXFzcWhDSCBI5r+c61LqGTP9wQk1uLSrasc3vk0tN3XX+OIDDXTKw6ESRQ51C15cuWvlRNUY/CHi2+nJzvCjCmUywb0P6nuGzysEP98LLGrmSJS1cqCqFJZ2jmrfxayspKhpEbXv3ceuTzvRdCQFdPDADcrP3V7zLoKMU0VlIcGa81Idp1g163Gj8GZm32eS5fu3iilI/psR3v6TDb5VhNpXcvXvKbkoYaqtHIU2yL97PljonfQvDXvi3zgdiyuDbzwAUna81OJvm0X968/JGsK+7cMJ8RU0ktRSkl1wYct+sWD33tYN0dUxE8EE0yVplNztK+z0b2gZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NI/6AN7Kc6qmUPgrDZbatiRRdKNwzya65ykPb1EYoB8=;
 b=O1jgzCCNksDS/8lqvCGvC2v01yXBkUh2oRtyR+Yo43gZA2eDz09IBagq6h1Dfd0zvnIYbDRHT0cnvndbC8+0lE3dbAzKtkkz4U2ETwF6+8mtulNBMtMtwlNmsXcpCXTZ32zs6O+FkTINH14d+FHhualayug8tpVW0z8rL/zSTfBW6T6ueZmh7WCu/x3ijDMVKCTHDGWGQngxmONyC93v4x2Ql58SBTjvMZFbwCIa+XRtMVCzuqccSqmXcVB1cF6vA7K4r5/pP3tlGWHgPZktvnJQ50V+UAHx+1n0W4f0Gv546m8aH159XVagehpfQaWTr+/MjiorfX1EJTisvIUaxg==
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=NI/6AN7Kc6qmUPgrDZbatiRRdKNwzya65ykPb1EYoB8=;
 b=T9HC93Sg9ZujVTZ179v+ooynKI8q3CAEGWmC1UAZjQ5IrE0wtzm2C+qRAsHaZ7ggNf9P3I+0XvzKDvIPSttApIzGFQLgnkIkk6VDApcMHQoMjN8O38bQ27tHkw86TEG+R55yTJAUSRAXjIahoaN4fes6cP3FuidMhVVj+x6QNcY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Dario Faggioli
	, Juergen Gross , George Dunlap
	, Stefano Stabellini 
Subject: [PATCH v4 08/20] xen/sysctl: wrap around XEN_SYSCTL_sched_id
Date: Wed, 28 May 2025 17:16:56 +0800
Message-ID: <20250528091708.390767-9-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F41:EE_|PH7PR12MB7020:EE_
X-MS-Office365-Filtering-Correlation-Id: 9509008b-acce-4e44-af6c-08dd9dc88c78
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Dwqw1CJ04FDWf9MVfHsVlWuImI20jFrl6Ajm86uJsW+x8oGBpHqUq5y63qzH?=
 =?us-ascii?Q?XdvM6DjXu1oIYfhnUITfKlVWRWgdbrw0cxWl91cmrA4yghh5boCN3ozP2yrr?=
 =?us-ascii?Q?PZlr0NNGf1vo1d+wJDy40zpxdDXTmRi6vhxNAgc7bNgWoxoeZP5YfdB5wg85?=
 =?us-ascii?Q?1remH6jK2YEZAHJr8xT18I+GeLG4KgUDnAzRDfLTEnZ1KuSaEz2Rmk/vDOGE?=
 =?us-ascii?Q?oCRdxyNeuwmFAFNF1U0haOOLOQv4rPKntYJLKurzfRZEKW5SViackie49Vka?=
 =?us-ascii?Q?Xl8mK01huss0fgSAaFEPyWGaQp3uvmhaSHJhd/2kMdYH+kSMHlrk0scFDaKX?=
 =?us-ascii?Q?9gHZnKeks0Wcj7VRgAFhivAoTR/wbgY2uCKb36ym6QCMFnGDB/0//tQHvTr6?=
 =?us-ascii?Q?2vx9kU1x8h8XdbTZszOl/ZGg7CHe0iG0PkE6lTdQyrLzm72fdHCYdY7tFZeS?=
 =?us-ascii?Q?bZoyfXZBiUU50mievaWKanKIz38jdFhltMLiqMIfsi0rxck3TqBXRAJ6MoMJ?=
 =?us-ascii?Q?JbJ+Qr4yt4cnhO1yOUDV5CiZRndlOqZRJqoMeImjV5iT5b+vIVxrH4GSsEmw?=
 =?us-ascii?Q?9cMbPpTmexKhTErMX8Lffc1eT4t+AS64xoLSDPRga8CxIPn5i5Nj5pQRrnon?=
 =?us-ascii?Q?KSn/2Xfp0ZEpyLR3iYR23cA27CRMWffl3ciOg2sP4Adl7ae3Mkdb5AfGfuCe?=
 =?us-ascii?Q?H7SuLPQL9MtFkUR6ENpVDHlw4aa8sy8V9ZPbVMUKIf9+BMSjy6wjNdn8xNIP?=
 =?us-ascii?Q?Y7Hz6V8VP57EjWrKhrSInFFDLFdP9f5cZc6+hhEZIJpuX1rljxyuZKPOraBB?=
 =?us-ascii?Q?qaCLsEZfwzOn8krXZWgB2NBZnUdc88W8v1O9W2ib1TQmGP37IwL+DDIe5cY6?=
 =?us-ascii?Q?gDVWAwynOrQh5DgjNNUQyfqBJQXS37ik/FOfJUiQkOtIu7DLnMVYaXCrNZy0?=
 =?us-ascii?Q?Ijjor1u/c8anZBcsCY22rPAYJRbtcCWwW+v0BG1w+O7Tzj0xfygXUFWg4CTH?=
 =?us-ascii?Q?oZ5ueoP/6s9T5rn/vWKVwcyshofObX6n82I9kF1338AljqHwWARS6pXZIbMV?=
 =?us-ascii?Q?m6qvLNfl7Bhsfr/KcRRq4x9qUKOWiigfB6ppgx2F17yKJpOW7xkMi1sTmE1g?=
 =?us-ascii?Q?UpCvucuZGsUZ/HMWPDNR1Gq7HlmlmgM6byORKXeByh92y3HOlQWx2PafyONX?=
 =?us-ascii?Q?8VK/NRH1/hfWnxCqB+M4C2nX9MGob66wSDFqiBt5rGWLrsDx3g/mgS0nGNx+?=
 =?us-ascii?Q?J7m2koVKBfVhGJ6W823S8ej+1ZKg/lcBp2usMPh023vafV34c57Gw1aH1Yla?=
 =?us-ascii?Q?pzrMpUtjPwzgGexR67MMJfIXg6GQ2epk4bQiylDn2HC49PymnUfyLedwGZuR?=
 =?us-ascii?Q?t0teSyDRpOZMhnIbnO84NP7GNTWA5DkvAwGJ1Y/8R+3JaoCt1vKcfXCG+uHl?=
 =?us-ascii?Q?snz8xV31RFYHHJD+vaXI0MNHEeQk+HhyTVzLB1ZsNPkVOJcIu4AsWooi/7bs?=
 =?us-ascii?Q?VAh5CHj1fhL/QGDsteR8E6FFfRQCVVAlQGkP?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:03.1578
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9509008b-acce-4e44-af6c-08dd9dc88c78
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F41.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7020

The following function shall be wrapped:
- scheduler_id()

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/sched/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 9043414290..13fdf57e57 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2069,11 +2069,13 @@ long do_set_timer_op(s_time_t timeout)
     return 0;
 }
 
+#ifdef CONFIG_SYSCTL
 /* scheduler_id - fetch ID of current scheduler */
 int scheduler_id(void)
 {
     return operations.sched_id;
 }
+#endif
 
 /* Adjust scheduling parameter for a given domain. */
 long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:18:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:18:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999070.1379836 (Exim 4.92)
	(envelope-from )
	id 1uKCvK-0003WQ-Qj; Wed, 28 May 2025 09:18:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999070.1379836; Wed, 28 May 2025 09:18: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 1uKCvK-0003VK-Mq; Wed, 28 May 2025 09:18:10 +0000
Received: by outflank-mailman (input) for mailman id 999070;
 Wed, 28 May 2025 09:18:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvJ-0001jE-9I
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:09 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20616.outbound.protection.outlook.com
 [2a01:111:f403:2417::616])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a97c655d-3ba4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 11:18:06 +0200 (CEST)
Received: from SN7PR18CA0001.namprd18.prod.outlook.com (2603:10b6:806:f3::15)
 by DS0PR12MB8574.namprd12.prod.outlook.com (2603:10b6:8:166::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Wed, 28 May
 2025 09:18:01 +0000
Received: from SN1PEPF00036F41.namprd05.prod.outlook.com
 (2603:10b6:806:f3:cafe::a7) by SN7PR18CA0001.outlook.office365.com
 (2603:10b6:806:f3::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.23 via Frontend Transport; Wed,
 28 May 2025 09:18:00 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F41.mail.protection.outlook.com (10.167.248.25) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:00 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:17: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" 
X-Inumbo-ID: a97c655d-3ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eXF9U7y6lzDyogwcLUNAtbUQwiZ6wmZ9odE0a0nKmTFrqRkQYXWmWoiogAW/O7kGcb1to+LN4xPTfbCGUcBDzaxdlxjlu90+XSNHWcdrpaRXgcb5/RTn9ZqAxCcSkYSESmIiJMjlcKQyhfxy9tBFuowqNVKNz/heYmcEt3vgqA1Z/opNqTTlWEuUA6L3/rFMia7t0rvdU81tcNn2teHYRU6VZMdqr6hdIjV/CgX8ndeUgArcM+GFPFl+jJV5LZOlhXsAWGozxtkvBdO8ZHCV5nmHPRnKDOo0ekWcwQtsU7acP3VvtNtJ+H2QUAvULxG2ZuVONjZHuz+qZ/Z3jLNAxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=70fq929cQ9GiOjsrnLMlQKa27q483NDF8TNgSR1MjVQ=;
 b=B3jIKwNTW0L1vOV/gdsNnvjS5Ke7ccX4mlKYJqg8dOvdudJvDaJXlrN9MGF+FBtUauYcpB3Pvv4mnDijmqH2bq7zeYUzIV5ZwggLI738jqwVUfPTgmuO/lrP1d6AVr8lzSDaLRs+70YUQdZa82W+WkrzJUiH5Ld7R/F6uaseFiFVvUVaYu4FOb/yC9lHcm41kEFeNABRBdydZot7TIlWBEvl7vjfVlKbe7OHfluOe3Zztai+cZSUx7ErV0gwX72hvBDn9HzxSvTxy1shXJ4i5C9PQTYgoQtEm1gFTX51S6wFXWHIIwMrMiWtDuozooNjX8tgnSjaxhQw0kHha6n+/g==
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=70fq929cQ9GiOjsrnLMlQKa27q483NDF8TNgSR1MjVQ=;
 b=UlLoxdgv82JA9wp4x1vfPBJkMENBX5hgfTxdRsA8/Ofv+dsexLkJDioElUBii8nIL5pn68xHV0WS0/iIpvWC5MmX5nZ0af4RqaHMQ2CN6DzF3FKf4ar0YRdneuYENJcMGthxMmS99N2++dwG6VDBR86QTWUfLumhYPR3v2dSRpo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v4 07/20] xen/sysctl: make CONFIG_TRACEBUFFER depend on CONFIG_SYSCTL
Date: Wed, 28 May 2025 17:16:55 +0800
Message-ID: <20250528091708.390767-8-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F41:EE_|DS0PR12MB8574:EE_
X-MS-Office365-Filtering-Correlation-Id: 62911c85-73b2-4c7b-8aea-08dd9dc88b0b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?jJ/upueOVX+P5yogIG7XRKTgTazZSeNT8MvayBtU19/m+sjQpb7NHeFSEudP?=
 =?us-ascii?Q?IxU1NoxpB7U1GLezmGk+bgx6vqr0Upnks1nqKQIzlF+Op8mGlhd0MjxhwMkr?=
 =?us-ascii?Q?QiTkUrwRks1iIFMfOM3jnnGCqnrrYQB95l0FScGR9bSyKxGl4kYYXw7Da8wj?=
 =?us-ascii?Q?l+n5V88l34lL5LbsvADqNW4oEXcO7qssXhu/d572/zR6HGTPbphGCgGrSg9y?=
 =?us-ascii?Q?A1blFY0mKlsv4oZsV+VtOR3RcZeSNsif+3w99pnaNfnVJdy2NVf1g9/urIR8?=
 =?us-ascii?Q?jx1lZUj2sHezm3b/fqzEVlhMyzaImJXMollY4yY679v8dfMUwrg1kJWP5z58?=
 =?us-ascii?Q?DTmMynCIOPvDESLAgI1wtpxiqlZ5GR1nPlbyR8oSZTe9MAcFYVh2gBFTbMj2?=
 =?us-ascii?Q?51rwWdvJCfh7rTc2jb9HTOpc5kA4+EfbPxaRDzi9K9ZL93UnxKvBDSPOgk/u?=
 =?us-ascii?Q?lf/GJkqdkXMW7E3QISEMd0/+juh2zh1DeOhIy5k1/Npns/L6wdJsyV3/n0HB?=
 =?us-ascii?Q?jy81vAJWJHMPfFANEHb54VWSY00hLw+OVvOtznHi/FCq2fNyg0yrCOWfzCkK?=
 =?us-ascii?Q?twQcg5w8BykjoIGybFjCEWW/d7LH9SaYcXxnZyaHqHSQYHfwVMteRqNhiU6L?=
 =?us-ascii?Q?QlyO4c6f1I7T5X82Wy5z4tU1qSSDeY1e3+P3wxvbyTWXGBJHadUQKDKjLdX/?=
 =?us-ascii?Q?Aa5+mkovT2ZVISAy+MOvi+dAQynvtEgwjsEySSUYBDb0cMOXacZADrIzIb/f?=
 =?us-ascii?Q?gsRPHUYyR3VnAA8/QP6dVjdtYQR6c/uNZtbFamMRhWszgBU2mN03megLdMin?=
 =?us-ascii?Q?/GroBXfaXUCMmOQZvbw4M/GiS0hmH013r2koNYJZm17WPDSqW27ifNJZ+UvN?=
 =?us-ascii?Q?z6gxZpDWUm3KEaawT/KH2OpehHsnTAC8Baj9FAtVN/Uf3kngvp9SG1t/cTcT?=
 =?us-ascii?Q?ctYuSALiUdQW6079ueCnSG92DAOeOhyaYo3t1t7DcSnbwj9xpfiYFKmSThfM?=
 =?us-ascii?Q?7Hh0QksfR3RauTkZBKrUNldvhtPEJYqEcqTFmx7dzm30lclKayP4rtRJg2v4?=
 =?us-ascii?Q?tSFoimVbuqIKsIOP+s9EuRSZBv/SEWp/uVAzmD/U3THla3Blavh5V67Rj17G?=
 =?us-ascii?Q?d13ZuKf6J1dqp1l8gL/qfYUAEdGik+3Fp2x0CTJWIQwcj6N3sABZUxKIyHDk?=
 =?us-ascii?Q?0kKkAxEaGdZpIgVAGLJuEs5aHSlEXSpfpTL0hhUHSjPjFK+wchsU8bG3pDhu?=
 =?us-ascii?Q?dUv0VLHfFoqg7j4pdOX2nxNRXtj2jkJ2AVgQIQ+XqeydN2V7AHiSADfjiAVS?=
 =?us-ascii?Q?alv8BuZcynLZKlwgQQtH3shXEaaPFEKg+XNFaMjMcDg5PUnqHpn8Gt8g3ChF?=
 =?us-ascii?Q?hPeTU750SfWDDecMj+iuKc8a+mneXPVRFz5GgXOfYA2Wb5KOYAcoBDhCivur?=
 =?us-ascii?Q?RZrpdLqOCQXwUU9e16k5yaO554n+VSnVxco8+5PrnEJSU0Bc/VqU44AswfpG?=
 =?us-ascii?Q?t9SUzUmyOCXZnPHTOphNJfjLTOBnjmhm0ZS2?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:00.7643
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 62911c85-73b2-4c7b-8aea-08dd9dc88b0b
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F41.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8574

Users could only access trace buffers via hypercall XEN_SYSCTL_tbuf_op,
so we shall make CONFIG_TRACEBUFFER depend on CONFIG_SYSCTL

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
 xen/common/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 28e6ac2142..d84906df24 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -547,6 +547,7 @@ config DTB_FILE
 config TRACEBUFFER
 	bool "Enable tracing infrastructure" if EXPERT
 	default y
+	depends on SYSCTL
 	help
 	  Enable tracing infrastructure and pre-defined tracepoints within Xen.
 	  This will allow live information about Xen's execution and performance
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:18:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:18:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999071.1379845 (Exim 4.92)
	(envelope-from )
	id 1uKCvM-0003oF-6Z; Wed, 28 May 2025 09:18:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999071.1379845; Wed, 28 May 2025 09:18:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKCvM-0003np-1j; Wed, 28 May 2025 09:18:12 +0000
Received: by outflank-mailman (input) for mailman id 999071;
 Wed, 28 May 2025 09:18:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvK-0001jE-9a
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:10 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2414::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aada3f53-3ba4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 11:18:07 +0200 (CEST)
Received: from SN7PR18CA0012.namprd18.prod.outlook.com (2603:10b6:806:f3::35)
 by SA0PR12MB4494.namprd12.prod.outlook.com (2603:10b6:806:94::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Wed, 28 May
 2025 09:18:04 +0000
Received: from SN1PEPF00036F41.namprd05.prod.outlook.com
 (2603:10b6:806:f3:cafe::60) by SN7PR18CA0012.outlook.office365.com
 (2603:10b6:806:f3::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Wed,
 28 May 2025 09:18:04 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F41.mail.protection.outlook.com (10.167.248.25) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:04 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:18:01 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: aada3f53-3ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cQSx5LbZ6+mjE4TN9TPP6BtZ4Anv15FvVEGDUAD4dUgWP3kvJqvS7DfbhwKYVXNT0AZ3mm8XNm78HfOtk5nP7epwl91fxPb4kg3xsbrjcKXRub7lxYdEvDsEn0IXpg8QNx4RrXvlt4BXAk5MTkFhWaSwYABnzee/2MhQyjmfZgCrKREWQqqPAlUR9ED9SEIJTBbVmJT+ASEXNiKg7VcBaRvjHQVQITxA1gNPvnMSqYbOd+OTBnoND+Gjmqh9SyTOaMhiINpsLtPGV2C9PgaUkvsQuHJZguHNwtNg/aikJ0OKb5cxpfK1EyIkUPg7Syqq8AtFDfrJKnZrS9SeXetkqA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DO6UlKiuVPi7TbpfR8fz/JNSlwLaSYSXABlcKqP5Puo=;
 b=JqgNkudZdkEQk4FPwK1fz8zQZGHqr/aNvwoQybKaDNeI0WmvsUtK7P6Mrcht6lgiD1fS+vc1dTrTu+s8lwKJvqmidpIakDox+pcQDPCu24G1Izd3EOrv7R+O44SOZxebt+9RVFX1lsj+f7qx3NWfflr028wRjT9qYTYVZPl5mUd3yRw1GsmU7pyOSPY9KTrxeN5BTxnIVFiyZgGvWRVwitvh8LwU35wjcYdBUrkdcVtDnJ4BcU/8OYOq7hKysSCfxL7rwjAHNzDPk8nE5Ff3+8WmnWZt+xNNU3ig/QGtOt64hwETS9GX62hjiHISiI+btyrnStjE+KaycCrIzn2kyw==
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=DO6UlKiuVPi7TbpfR8fz/JNSlwLaSYSXABlcKqP5Puo=;
 b=MGTnZqcN4Ylgmf9HSbkPpK/jUXECcEjLBYn2JRs+KB9x9Q00qoMH5F/3AXrL/mVS+ZvSo0CJKVRdKjch6xzQx8w1lTjixGRoxe8kfeXBkJ1ZmZgou0+9zR6wnVrBac8AyJffCO0a2+NC3Wva81tH9p6zYcZ5GcrGNum+i6jfeY0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v4 09/20] xen/sysctl: wrap around XEN_SYSCTL_perfc_op
Date: Wed, 28 May 2025 17:16:57 +0800
Message-ID: <20250528091708.390767-10-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F41:EE_|SA0PR12MB4494:EE_
X-MS-Office365-Filtering-Correlation-Id: 0b6c2526-3b3d-4cb6-af9a-08dd9dc88d14
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?8txRWvdFF1nBVuc7xNza9emlU+IoflcYqeaupPi5psuScCpRxw2us+LXTr0C?=
 =?us-ascii?Q?+gGDT/B+BmCL6ojpIJby1RNJSkK7ku8jb7ZPJd+L1iVqGhkLiYAd7j5XURzK?=
 =?us-ascii?Q?lvzsQZNjqmkoQ5byEYoG/9ZNyrfYENwDhtJcNax2O7BCOpvN4e9rrAK8HRyN?=
 =?us-ascii?Q?NcVy8ahTTC/YtIztt7mMbiIgFJPca6lF3s4KiLQVOrQFupCm9g46rcj9YdOo?=
 =?us-ascii?Q?adKJDlP7Au35VtbdHAEvP2x1WePOJ7W5LzruUScHYeLXOc3BmteyOMQqvT2w?=
 =?us-ascii?Q?6O+cHffcEwzc/VbjW1k1McGXwrb9wf43QE1lzTdWr5VPupbjvxTPJ9lkDNEv?=
 =?us-ascii?Q?vNiGY6+nYtVHWWNmkPF55hrbuwS3IVRJEEWqDqMXuovto+3x5+skct1fiReU?=
 =?us-ascii?Q?Rx616FH83B4m/txiDV9/TC5lzpUA4UWCfyk139L4gA8LZAAj1CadqGwzJjMj?=
 =?us-ascii?Q?v3OG5L262Dxn9Ykh0VeHbzVaPJBWil7KCDWaOL7UuBucYNxUWq9xDUiNuqfR?=
 =?us-ascii?Q?nx0w5YM7c2ocLhgNFaBMQsxsjd35yvQt5vnUR5MBCKTvlOjjNAJ6gJ8Cq+Kv?=
 =?us-ascii?Q?M4WKUFdvPG6dKxKcaMvUGubEDoe4QNw9/pjzDV9faELi5T79NNE0jHu5YFuD?=
 =?us-ascii?Q?ydWhj+YlujRFb3UTmuJUwiGDW6swkBwlACy7FgU7WzywJyI6XgtSZomxlgMP?=
 =?us-ascii?Q?9FhftV0eV710vlgGKPbPUgY5RRJGaSpqTpLCmNpDNSW4HeE9jhL6zfbpbhgx?=
 =?us-ascii?Q?MPbLUxV3957Fzjfp5agnMz7QAV9ZSyFDK5jjaQzmy8j5yzFPqXYqLs8+O0ot?=
 =?us-ascii?Q?8JZHgh3MKA5i2VY4EzJMnNGwcWIOq4ZMTJ828Wawn2uvbFXz1ejnqyGYODTO?=
 =?us-ascii?Q?1/lZF0YWTpx5QyRPD9vq201DR7sKoo7q66UPe4gg8LLa6Ij9UMUrHbEvktCb?=
 =?us-ascii?Q?xFAZ5Qi+y+DlNZiwNlLS7KzqfpAEY2KtP2EAIZ+6OsIboNC+2Vfh5re2dfvi?=
 =?us-ascii?Q?7P32vtBvpF3zTC6jMfTf0eS4FPJkbHM55NsAlTMEVLx6bXmGuGOWghdgTUw0?=
 =?us-ascii?Q?pi5G2tMcfvjRIfKJzcBKZKhWouI6uTCUKibgN9dmGj/ZriACDnpYj9u5xYhU?=
 =?us-ascii?Q?yZCBFbXIzUBzBIZ7gnlp3xZ0E2yYWPZQGCr4IRFBJdm9YdmSTi2hqX9cYLWN?=
 =?us-ascii?Q?didgjq2umbDaY0vKJ6aXYpBNJYEp+r/FheGsLdOl95WeVA3AWaM9lnmUwIbz?=
 =?us-ascii?Q?/YNdwQdq/6FrPr2PY0a0Jo8FpB0DhsFeEgPSHD+ybuJwn0o/jwVKYWn1Rxw8?=
 =?us-ascii?Q?phntOFcKr1P4kXKqYvEqEoqvpylSK9d5T6ttF26tpiS9FIUmJf56y8+hG+Ty?=
 =?us-ascii?Q?wyqkT/izDFUJgIK672E720s+agjHbwQw+HWIaj4M6WIKeluuryaF2nFdMjPS?=
 =?us-ascii?Q?ssfofIJEN3HMecAbS12TX7Qxp4MqPjs+Ccl1r/xT5DFMUOARACSnYvxiWAR5?=
 =?us-ascii?Q?1cTmDHdWz/i/1liwZMNP/Fa2QHVb1jMWMxeB?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:04.1798
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b6c2526-3b3d-4cb6-af9a-08dd9dc88d14
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F41.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4494

perfc_control() and perfc_copy_info() are responsible for providing control
of perf counters via XEN_SYSCTL_perfc_op in DOM0, so they both shall
be wrapped.

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v2 -> v3:
- add the blank line
---
v4 -> v5:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/perfc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/perfc.c b/xen/common/perfc.c
index 8302b7cf6d..0f3b89af2c 100644
--- a/xen/common/perfc.c
+++ b/xen/common/perfc.c
@@ -149,6 +149,7 @@ void cf_check perfc_reset(unsigned char key)
     }
 }
 
+#ifdef CONFIG_SYSCTL
 static struct xen_sysctl_perfc_desc perfc_d[NR_PERFCTRS];
 static xen_sysctl_perfc_val_t *perfc_vals;
 static unsigned int      perfc_nbr_vals;
@@ -265,6 +266,7 @@ int perfc_control(struct xen_sysctl_perfc_op *pc)
 
     return rc;
 }
+#endif /* CONFIG_SYSCTL */
 
 /*
  * Local variables:
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:20:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:20:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999103.1379856 (Exim 4.92)
	(envelope-from )
	id 1uKCxh-00078g-Kk; Wed, 28 May 2025 09:20:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999103.1379856; Wed, 28 May 2025 09: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 1uKCxh-00078Z-He; Wed, 28 May 2025 09:20:37 +0000
Received: by outflank-mailman (input) for mailman id 999103;
 Wed, 28 May 2025 09:20:36 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvs-0000yL-0D
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:44 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20605.outbound.protection.outlook.com
 [2a01:111:f403:240a::605])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bf03691b-3ba4-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:18:43 +0200 (CEST)
Received: from SN7PR18CA0009.namprd18.prod.outlook.com (2603:10b6:806:f3::17)
 by PH0PR12MB7079.namprd12.prod.outlook.com (2603:10b6:510:21d::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Wed, 28 May
 2025 09:18:35 +0000
Received: from SN1PEPF00036F3C.namprd05.prod.outlook.com
 (2603:10b6:806:f3:cafe::ef) by SN7PR18CA0009.outlook.office365.com
 (2603:10b6:806:f3::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Wed,
 28 May 2025 09:18:35 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F3C.mail.protection.outlook.com (10.167.248.20) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:34 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:18: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" 
X-Inumbo-ID: bf03691b-3ba4-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bqEIoEtyMbT7mazyXLDeQZveaD2Xkr1HjysOWYRBmaJTAETGUd5DO+waHQxIFj3FjUlQqT8LRn9sk83KwGhLAVXCe5GU7AwRmazbnEsMWMVbx5d1+4SxRz7h1og7nVzEs07TgWeLsNhYlMj7Ik6RZu4eicbOgFQyyQn53akagHpXLPn+E5FBavgsybjundFqlfKXFoDx34YE9VIw/ApUnEGolKp4OHsKANYskAvKUsLfLOK2aBqr0sGVDnaGN0yJlKe6v6l415Tfq7h2/6wm/WpTBpj+GGg4/LN5lWDabGE0ZW685dcdgp9vLxQarFDwtHZUOvaGtqCAcSOzuKdxZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=us3XyiiEJ1jpBaIa5d6mu+gEoTYclWxk5heaEhLXVv0=;
 b=QNRzCHXrohzv1DfFURMLZchFFi/JTzVn12m48XWXJk/3LEz6rDZVnSXb1RD0qu4aDkYNvwWJdjmwKKr90yLFMAySMt5LCggnOvt5pJbky49XzfMJIqn3ZIY1VHVgPBo3PPRkhGhNkhda2LG2ST7tgUbtlVEp5cQV1miu6Zbqg6xI0IhpVMg/QedlyEOsO/850bDHBkEaBLvu+h8YkFaN668+e70YQEZqgUlQvp7gyjIgtQlXKWnnnJ4rd5zGskAnk/JJma8Sa66GseLoZe/TcH4vyd1tJ9FLcGa8y4pRsWsTnmhJo2YkgiP2Og2Q0698wnYOMXDQtk/liYJahD+Mkw==
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=us3XyiiEJ1jpBaIa5d6mu+gEoTYclWxk5heaEhLXVv0=;
 b=Y48suomkiZkd7U0uceyFN3JcY/4AaKVSUbbrDUSZ2tVnmLo3L7CEg2pMYP/93bQPzFcf6ismwv+M37qluOvS82HqmLbzWpRv4er84ur52xwKZ9G0fTieTOOJJwhZTDUCVkF/zIj1izmKQnDaPu/64HUZ7W/wP6hqTGar26Dymr4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, Jan Beulich , Andrew Cooper
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Stefano Stabellini" ,
	Sergiy Kibrik 
Subject: [PATCH v4 19/20] xen/sysctl: wrap around arch-specific arch_do_sysctl
Date: Wed, 28 May 2025 17:17:07 +0800
Message-ID: <20250528091708.390767-20-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F3C:EE_|PH0PR12MB7079:EE_
X-MS-Office365-Filtering-Correlation-Id: 256563e6-d0eb-485b-a43b-08dd9dc89f05
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?FJG7a1T1UAyxnnL3LGwyUKUz1vmNOSoWNHc+MUPOtuaEiIvrJs15vgXyv8Op?=
 =?us-ascii?Q?2kLfsW/w0KM0+Qt1L1QvWoDt22bkVOqrUrQ5CCYa/j2raBT7NEuTX+YW7anq?=
 =?us-ascii?Q?CXv7oSyyIN584M3/0K7aWi5qtieeW9EQW39/V4QSVsL9Lyl1L8n4xbKECMvo?=
 =?us-ascii?Q?3OeNRCyvntX6vGH/o+Lw04XmfPf/q5Cb71JBTDy4Z9BnxnEKmz5kIH49Rsuf?=
 =?us-ascii?Q?ctcb4TsY3CGwVx+4lTg0uN2dt3niUgCtFkJSYQHiRZ8IsJubXdC6mHwEbutP?=
 =?us-ascii?Q?/A3L0OmgOcQEeiGCm+xb8SKQWLGYcIg6BH9esai2rJLHNl+VYExkQQHMJHmi?=
 =?us-ascii?Q?zMBBmN6oK6KwKt/2/Edlk69dL/ZyPcmeP4yBfT+jWi/G3GYCwr0UhSEyK/eG?=
 =?us-ascii?Q?2fzFQ5b/0rUaoiGCTTyQHCrBnF+rkbKn8DvgPzHpYsuDMywDnwRTxAK8SCzQ?=
 =?us-ascii?Q?XZBOfNe0MbFoYcLGYLqY/TNINka/M7MhOtX/tdqWV0gImKN/B8XihZIxVz9j?=
 =?us-ascii?Q?KPw0TvmBe0V7Kiy96BsFlRIswT+GXkQdS6gGbLebk5hbcXfGsvtIrt8jSx0R?=
 =?us-ascii?Q?lJkLLb+DC/BcFVEgXJkf/Qe8g/BOIpBfN9xYr81bYfYi9PuAnC3+hCBHRhjj?=
 =?us-ascii?Q?PUEr6YE023qwCForQE/PDP3GD9BqMp7Kb6IfDjNwCbE86B7s3QmE5IbThT02?=
 =?us-ascii?Q?wrO/fc9NR72tNbZpvSHbyVIFxIMp5k8TDKWnioWj24Rq8kBifsIjMx7RcwLu?=
 =?us-ascii?Q?17hCOnIiKpEmScLaRdZC01F16t09qeDQRm93b4dQxC+i4fl42WWBPJ8BTsWD?=
 =?us-ascii?Q?q95mVW4b6Ddjel79qOOm8IhrSBwkGQ5A3JFqN+LxuQu0rP8QpGPoMmWWRPaB?=
 =?us-ascii?Q?fl3w0J+Ujsjt3uWNo1Oyw0toRkVSuIIArmTck2eVaQVYzVX7MpoAFoiOE9HH?=
 =?us-ascii?Q?u79N5f+rF0ri5iZzHijJfqp3kzfb0Bc5ddcT5Hg4bA1aYVbEOgJzfyeWM3gP?=
 =?us-ascii?Q?02nSvoZcz+kejeTQwuSITi8lLpCFxMD3joa17/npS8okGFKifvzHMoVznsnl?=
 =?us-ascii?Q?D4Mj5d4By77wxbdpqV9lAFRCjo+3MsUCtyP8VsudmkFhR19MdGZbRUEGGVZJ?=
 =?us-ascii?Q?zzNIZX3YCkBo3VEh3wS3JsMcZrbLm/HfRkkVvQvpEMQS5D1RlbCVxjywTRYR?=
 =?us-ascii?Q?b/aBPmXe5yT323BwKCN2wy1LETeKmO+pQBpJW5Y9ANBdgUdG/1ruwCrYtCIb?=
 =?us-ascii?Q?PQ6S1BiZ2lgPVUo1kNpwpk54QZq88AyumUMqRPBnvCh7pb8u6rrts44urX5Y?=
 =?us-ascii?Q?GFN/+OjEULxwyRAw3rmXTsH1/A0mSZmHtUHR9715xdXC54TtZT9LBXaHaN1C?=
 =?us-ascii?Q?pyZQFJHIjKS1bn3DF+uf6BaSx2N5RHayL/e/rEsynWgShsDZhyB7hIHZiq62?=
 =?us-ascii?Q?0xYg2/3YgAsgtyQYmIFJrchVg59RWYc4fGqxYx08447afrNZPfDG3Dob6+1U?=
 =?us-ascii?Q?cTI2X6KyPNU3hX++ijUkjOIUHaNfkHUU+R++?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(7416014)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:34.2805
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 256563e6-d0eb-485b-a43b-08dd9dc89f05
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F3C.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7079

Function arch_do_sysctl is to perform arch-specific sysctl op.
Some functions, like psr_get_info() for x86, DTB overlay support for arm,
are solely available through sysctl op, then they all shall be wrapped
with CONFIG_SYSCTL

Also, remove all #ifdef CONFIG_SYSCTL-s in arch-specific sysctl.c, as
we put the guardian in Makefile for the whole file.
Since PV_SHIM_EXCLUSIVE needs sorting in the future, we move
obj-$(CONFIG_SYSCTL) += sysctl.o out of PV_SHIM_EXCLUSIVE condition.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Sergiy Kibrik 
Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
v1 -> v2:
- use "depends on" for config OVERLAY_DTB
- no need to wrap declaration
- add transient #ifdef in sysctl.c for correct compilation
---
v2 -> v3:
- move obj-$(CONFIG_SYSCTL) += sysctl.o out of PV_SHIM_EXCLUSIVE condition
- move copyback out of #ifdef
- add #else process for default label
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
- move #ifdef ahead of the comment
---
 xen/arch/arm/Kconfig   |  1 +
 xen/arch/arm/Makefile  |  2 +-
 xen/arch/arm/sysctl.c  |  2 --
 xen/arch/riscv/stubs.c |  2 +-
 xen/arch/x86/Makefile  |  2 +-
 xen/arch/x86/psr.c     | 18 ++++++++++++++++++
 xen/arch/x86/sysctl.c  |  2 --
 7 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a5aad97a68..91a77560a6 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -139,6 +139,7 @@ config HAS_ITS
 
 config OVERLAY_DTB
 	bool "DTB overlay support (UNSUPPORTED)" if UNSUPPORTED
+	depends on SYSCTL
 	help
 	  Dynamic addition/removal of Xen device tree nodes using a dtbo.
 
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 129a109d6e..dd455b4773 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -54,7 +54,7 @@ obj-y += smpboot.o
 obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
 obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
 obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
-obj-y += sysctl.o
+obj-$(CONFIG_SYSCTL) += sysctl.o
 obj-y += time.o
 obj-y += traps.o
 obj-y += vcpreg.o
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index 2d350b700a..32cab4feff 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm | XEN_SYSCTL_PHYSCAP_hap;
@@ -23,7 +22,6 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
     pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()),
                                        XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
 }
-#endif
 
 long arch_do_sysctl(struct xen_sysctl *sysctl,
                     XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index 295456d0c8..cca3767249 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -313,6 +313,7 @@ unsigned long raw_copy_from_guest(void *to, const void __user *from,
     BUG_ON("unimplemented");
 }
 
+#ifdef CONFIG_SYSCTL
 /* sysctl.c */
 
 long arch_do_sysctl(struct xen_sysctl *sysctl,
@@ -321,7 +322,6 @@ long arch_do_sysctl(struct xen_sysctl *sysctl,
     BUG_ON("unimplemented");
 }
 
-#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     BUG_ON("unimplemented");
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index ce724a9daa..96d63219e7 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -63,6 +63,7 @@ obj-y += smpboot.o
 obj-y += spec_ctrl.o
 obj-y += srat.o
 obj-y += string.o
+obj-$(CONFIG_SYSCTL) += sysctl.o
 obj-y += time.o
 obj-y += traps-setup.o
 obj-y += traps.o
@@ -78,7 +79,6 @@ ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
 obj-y += domctl.o
 obj-y += platform_hypercall.o
 obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
-obj-y += sysctl.o
 endif
 
 extra-y += asm-macros.i
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 5815a35335..499d320e61 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -133,9 +133,11 @@ static const struct feat_props {
      */
     enum psr_type alt_type;
 
+#ifdef CONFIG_SYSCTL
     /* get_feat_info is used to return feature HW info through sysctl. */
     bool (*get_feat_info)(const struct feat_node *feat,
                           uint32_t data[], unsigned int array_len);
+#endif
 
     /* write_msr is used to write out feature MSR register. */
     void (*write_msr)(unsigned int cos, uint32_t val, enum psr_type type);
@@ -418,6 +420,7 @@ static bool mba_init_feature(const struct cpuid_leaf *regs,
     return true;
 }
 
+#ifdef CONFIG_SYSCTL
 static bool cf_check cat_get_feat_info(
     const struct feat_node *feat, uint32_t data[], unsigned int array_len)
 {
@@ -430,6 +433,7 @@ static bool cf_check cat_get_feat_info(
 
     return true;
 }
+#endif /* CONFIG_SYSCTL */
 
 /* L3 CAT props */
 static void cf_check l3_cat_write_msr(
@@ -442,11 +446,14 @@ static const struct feat_props l3_cat_props = {
     .cos_num = 1,
     .type[0] = PSR_TYPE_L3_CBM,
     .alt_type = PSR_TYPE_UNKNOWN,
+#ifdef CONFIG_SYSCTL
     .get_feat_info = cat_get_feat_info,
+#endif
     .write_msr = l3_cat_write_msr,
     .sanitize = cat_check_cbm,
 };
 
+#ifdef CONFIG_SYSCTL
 /* L3 CDP props */
 static bool cf_check l3_cdp_get_feat_info(
     const struct feat_node *feat, uint32_t data[], uint32_t array_len)
@@ -458,6 +465,7 @@ static bool cf_check l3_cdp_get_feat_info(
 
     return true;
 }
+#endif /* CONFIG_SYSCTL */
 
 static void cf_check l3_cdp_write_msr(
     unsigned int cos, uint32_t val, enum psr_type type)
@@ -473,7 +481,9 @@ static const struct feat_props l3_cdp_props = {
     .type[0] = PSR_TYPE_L3_DATA,
     .type[1] = PSR_TYPE_L3_CODE,
     .alt_type = PSR_TYPE_L3_CBM,
+#ifdef CONFIG_SYSCTL
     .get_feat_info = l3_cdp_get_feat_info,
+#endif
     .write_msr = l3_cdp_write_msr,
     .sanitize = cat_check_cbm,
 };
@@ -489,11 +499,14 @@ static const struct feat_props l2_cat_props = {
     .cos_num = 1,
     .type[0] = PSR_TYPE_L2_CBM,
     .alt_type = PSR_TYPE_UNKNOWN,
+#ifdef CONFIG_SYSCTL
     .get_feat_info = cat_get_feat_info,
+#endif
     .write_msr = l2_cat_write_msr,
     .sanitize = cat_check_cbm,
 };
 
+#ifdef CONFIG_SYSCTL
 /* MBA props */
 static bool cf_check mba_get_feat_info(
     const struct feat_node *feat, uint32_t data[], unsigned int array_len)
@@ -508,6 +521,7 @@ static bool cf_check mba_get_feat_info(
 
     return true;
 }
+#endif /* CONFIG_SYSCTL */
 
 static void cf_check mba_write_msr(
     unsigned int cos, uint32_t val, enum psr_type type)
@@ -545,7 +559,9 @@ static const struct feat_props mba_props = {
     .cos_num = 1,
     .type[0] = PSR_TYPE_MBA_THRTL,
     .alt_type = PSR_TYPE_UNKNOWN,
+#ifdef CONFIG_SYSCTL
     .get_feat_info = mba_get_feat_info,
+#endif
     .write_msr = mba_write_msr,
     .sanitize = mba_sanitize_thrtl,
 };
@@ -808,6 +824,7 @@ static struct psr_socket_info *get_socket_info(unsigned int socket)
     return socket_info + socket;
 }
 
+#ifdef CONFIG_SYSCTL
 int psr_get_info(unsigned int socket, enum psr_type type,
                  uint32_t data[], unsigned int array_len)
 {
@@ -839,6 +856,7 @@ int psr_get_info(unsigned int socket, enum psr_type type,
 
     return -EINVAL;
 }
+#endif /* CONFIG_SYSCTL */
 
 int psr_get_val(struct domain *d, unsigned int socket,
                 uint32_t *val, enum psr_type type)
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index f64addbe2b..1b04947516 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -91,7 +91,6 @@ static long cf_check smt_up_down_helper(void *data)
     return ret;
 }
 
-#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     memcpy(pi->hw_cap, boot_cpu_data.x86_capability,
@@ -105,7 +104,6 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
     if ( IS_ENABLED(CONFIG_SHADOW_PAGING) )
         pi->capabilities |= XEN_SYSCTL_PHYSCAP_shadow;
 }
-#endif /* CONFIG_SYSCTL */
 
 long arch_do_sysctl(
     struct xen_sysctl *sysctl, XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:20:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:20:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999109.1379867 (Exim 4.92)
	(envelope-from )
	id 1uKCxr-0007VU-2U; Wed, 28 May 2025 09:20:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999109.1379867; Wed, 28 May 2025 09: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 1uKCxq-0007VI-SJ; Wed, 28 May 2025 09:20:46 +0000
Received: by outflank-mailman (input) for mailman id 999109;
 Wed, 28 May 2025 09:20:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvX-0001jE-PE
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:23 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on20615.outbound.protection.outlook.com
 [2a01:111:f403:2413::615])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b3682bc8-3ba4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 11:18:22 +0200 (CEST)
Received: from MW4PR04CA0074.namprd04.prod.outlook.com (2603:10b6:303:6b::19)
 by IA0PPF80FB91A80.namprd12.prod.outlook.com
 (2603:10b6:20f:fc04::bd5) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.32; Wed, 28 May
 2025 09:18:18 +0000
Received: from SN1PEPF00036F3F.namprd05.prod.outlook.com
 (2603:10b6:303:6b:cafe::8b) by MW4PR04CA0074.outlook.office365.com
 (2603:10b6:303:6b::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Wed,
 28 May 2025 09:18:17 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F3F.mail.protection.outlook.com (10.167.248.23) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:17 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:18: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" 
X-Inumbo-ID: b3682bc8-3ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sJ15Noy+EYTuZ+7buvWGPQwUo7rULps5eL1uMG9TzTB+fDe4clR/bjcjHkTX6aVF/Lk8pheAT9IoaZLcauFWPaI1ionvCbb4/YCJQoYmH1Y0RVhJM1mvisQhAorzhYM5rhsMQptbVgkTyGXUXmp2ybTn9mf/DBu2wFY/VeTOCBI7kOY3IGAvEqA+h2QAkcO8Cw4tLLVj1kmSZKumEUdQ+Z07l9cEFIOwtyBj17ev1PLhY1T+aZD8ar5DTBEjks5s28WW8+J7CMp+Fg1X8nubSKRy4of/nBuqb2ZWO0lJsJJlmtikT/KCYFLrYd5V8ryj26Py8T9t0VOMgjt/i8lqNA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IdgLxZJojMqTzA4uMqMuY2FrEHyVqR+LGLe1iCymvs4=;
 b=rWqO9Q4ddkHtt8iJG9ZJjFcC4pzkvq2VsYQ5EvpKib+5TdoJ6zn0XrR5Ts61CodISXOy+3lvku875GK4i7UV28Rawe0r1HMYXKOoXEwedj5pL3Rn+o/ndOOuTNmx7dfjKDR8X5kDuOB+vEUErHoDpocgtmVjPcqsWZIaQLv3ABShlsXqAOQ33hyBg6s3wCB5jy7TQbzBaKXTKw3SAQVyb+GG45s6z3Ti4BJQDagsVtTDm+ck92BSevMo/UHJZ9CCAetX0LOwOzdvgVwmrdPwXGtR/jpoXvDMTfSIaXnLfwiGYbT8Hzw3noaYUXIHDij1DZ1ZAkUCpiOYxa82OPSuaw==
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=IdgLxZJojMqTzA4uMqMuY2FrEHyVqR+LGLe1iCymvs4=;
 b=tHyE8dFktuxkOlRrCjAxiWEQpZ7rSXORnCPpCElrszlq9WBwhhMJmZ4VPx2NUiBThT/Vgs0GTHF9iiTsHgi2ylA8d06hw72zr27Qw1KPIl6m4jicjwNHi1EVp6F8FOn9zP2Km4Den1QIet4rhkODTXPPHrvs4LbEynftic14TTc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Dario Faggioli
	, Juergen Gross , George Dunlap
	, Stefano Stabellini 
Subject: [PATCH v4 14/20] xen/sysctl: wrap around XEN_SYSCTL_cpupool_op
Date: Wed, 28 May 2025 17:17:02 +0800
Message-ID: <20250528091708.390767-15-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F3F:EE_|IA0PPF80FB91A80:EE_
X-MS-Office365-Filtering-Correlation-Id: 47fa69c0-a522-4ab9-4c54-08dd9dc89522
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?mJyVDGlnX6/kadcqdRkjrkA0ym3J1w8o2gyDpvUYLBBx/RVrQCPmyZhR+Ga5?=
 =?us-ascii?Q?2qqmsLENPsrTLXCIW3T/FuMPaCuk0tgp0lmKJ7QF4jGrO0l+Ryp5qwoRfqyY?=
 =?us-ascii?Q?fLf4F1VJ0pWR+xJiXd+h3c0AcPpgbT/T++2qe/L93DzxSmUDZlvy+8TwRN9r?=
 =?us-ascii?Q?7NC08IElglODrydTn3uOjp7zjJfAmaND2GatI2ZtcllhZDg2ThYQfpe2wPIu?=
 =?us-ascii?Q?1Ol7bntNwc85hPtdTp4YmsjeQSXMgJBqQPsqowM9DeB6cyUs921yI6tN/G3O?=
 =?us-ascii?Q?A9qq9NmdnQaTxfYwlfjvmRBkOj8MSsauzrjT9IYa70rJw45+1Kmi8xIL7BRy?=
 =?us-ascii?Q?xGQ9uhnUaZ+Pv4rcrNa74H0PDQsPbdfTB7kfPfGD/U29/u0qY1mI8PdmlAqQ?=
 =?us-ascii?Q?07ZgNEvKpLMVzL1E1aBWjMRWRfhWLgUBX7ugs3XU0I6SR054mNkPnT+63Di5?=
 =?us-ascii?Q?3W/cTTxaa+7HYw063iSPd+1g4Y64l8y3hiJrQplqw5Q24/Y9EI2t9usTYstk?=
 =?us-ascii?Q?eq7CymoE4Ths4bnoknZMLmrIAUitfy0NWQYEjO5Xw8cJzOryOM55MXDyiBnI?=
 =?us-ascii?Q?qxCya6ebYBAFoEgp9cglGUwWz20vDMCfzye+7REXXyAtT70UGNF/C8+n+XC9?=
 =?us-ascii?Q?+hyczAUbhUwZTKD9ALzh1UUW7tnzEt1mntcMcCHZnMHYl1XMwRqANqF7AJSC?=
 =?us-ascii?Q?xXQ5Acm11/cc+P8tIkuiWPWra5Ak9i4PSXMiv9QciS0ohBV3t9R0695lm9L6?=
 =?us-ascii?Q?SDYynWsXSAsnhQutcsqit9E1rzpgkwJVOyPOsHLOfYM2s0UeXKTN1Vfwwyaw?=
 =?us-ascii?Q?pX2ymhWJ9eVQnRyHZI0rbUC+/OgMHhB28UjDZ1Vpu+1JsfWxnAHIfNdsVj6r?=
 =?us-ascii?Q?XuMA7s1mnOvqnFB0+5MVtT7ivWvuGVt6/IbUsmVktQmRyshOpxctagqHrkpH?=
 =?us-ascii?Q?2kxjEDPRTq0Y0vTwobyjAWk8rri3fqxeAKghLEwlHjuiq/0wp8G8t9xvtwo9?=
 =?us-ascii?Q?zFwc1zf/IsjE221MI1CQsFdMXCZxZzYHb+CiXuvOSKW92FuYTmuyPa64JzVL?=
 =?us-ascii?Q?EUC8KkS8aVKmyUHXyQAFVBYfohVkuOy7TwOTxsIqO7SxviQOgi7A+nTfGQIC?=
 =?us-ascii?Q?sFkc6rLiTfpVQQH1nzfyHyfS9IhYX2TUj4BKOgQlKZnSwuOhnu/Vat5vjh0Z?=
 =?us-ascii?Q?NosfQNaiFSUWT3JwZH/QntkTqihJDpBj1gHhchs7/cesSqqoC3qDzc8Hy85v?=
 =?us-ascii?Q?wB+ZLjCfH6v7Wmux0q+m7vQnwhPfubOOvH9PIy8cc5HGuwRzybvDVHHe95D4?=
 =?us-ascii?Q?agqQV9UM2QcXHfiSlayNGwgACSmHjU2akj46FcOIwsXSHUNp1rEVOPjtNGd/?=
 =?us-ascii?Q?ZcRLuglXRYGeymOi4JeNXXE5VCjojHyNsfX3TVWtIDX+atI5ONNT8VtKGnLF?=
 =?us-ascii?Q?3lyrn90TZgED9Xh1Wi9KWmKRIMnKZtchnY5bjKfhWiA+cNTXKMQJfxx0Tqt8?=
 =?us-ascii?Q?3ziAZTQx/uyldG0+uAbSl9e4PdLdZkH74f1F?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:17.6909
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 47fa69c0-a522-4ab9-4c54-08dd9dc89522
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F3F.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF80FB91A80

Function cpupool_do_sysctl is designed for doing cpupool related sysctl
operations, and shall be wrapped.

The following static functions are only called by cpupool_do_sysctl(), then
shall be wrapped too:
- cpupool_get_next_by_id
- cpupool_destroy
- cpupool_unassign_cpu_helper
- cpupool_unassign_cpu

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v1 -> v2:
- no need to wrap declaration
- add transient #ifdef in sysctl.c for correct compilation
---
v2 -> v3
- move #endif up ahead of the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/sched/cpupool.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 3d02c7b706..f5459c2779 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -241,10 +241,12 @@ struct cpupool *cpupool_get_by_id(unsigned int poolid)
     return __cpupool_get_by_id(poolid, true);
 }
 
+#ifdef CONFIG_SYSCTL
 static struct cpupool *cpupool_get_next_by_id(unsigned int poolid)
 {
     return __cpupool_get_by_id(poolid, false);
 }
+#endif /* CONFIG_SYSCTL */
 
 void cpupool_put(struct cpupool *pool)
 {
@@ -352,6 +354,7 @@ static struct cpupool *cpupool_create(unsigned int poolid,
 
     return ERR_PTR(ret);
 }
+#ifdef CONFIG_SYSCTL
 /*
  * destroys the given cpupool
  * returns 0 on success, 1 else
@@ -379,6 +382,7 @@ static int cpupool_destroy(struct cpupool *c)
     debugtrace_printk("cpupool_destroy(pool=%u)\n", c->cpupool_id);
     return 0;
 }
+#endif /* CONFIG_SYSCTL */
 
 /*
  * Move domain to another cpupool
@@ -568,6 +572,7 @@ static int cpupool_unassign_cpu_start(struct cpupool *c, unsigned int cpu)
     return ret;
 }
 
+#ifdef CONFIG_SYSCTL
 static long cf_check cpupool_unassign_cpu_helper(void *info)
 {
     struct cpupool *c = info;
@@ -633,6 +638,7 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
     }
     return continue_hypercall_on_cpu(work_cpu, cpupool_unassign_cpu_helper, c);
 }
+#endif /* CONFIG_SYSCTL */
 
 /*
  * add a new domain to a cpupool
@@ -810,6 +816,7 @@ static void cpupool_cpu_remove_forced(unsigned int cpu)
     rcu_read_unlock(&sched_res_rculock);
 }
 
+#ifdef CONFIG_SYSCTL
 /*
  * do cpupool related sysctl operations
  */
@@ -975,6 +982,7 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
 
     return ret;
 }
+#endif /* CONFIG_SYSCTL */
 
 unsigned int cpupool_get_id(const struct domain *d)
 {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:20:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:20:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999123.1379876 (Exim 4.92)
	(envelope-from )
	id 1uKCxy-0007yD-7k; Wed, 28 May 2025 09:20:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999123.1379876; Wed, 28 May 2025 09: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 1uKCxy-0007y4-4g; Wed, 28 May 2025 09:20:54 +0000
Received: by outflank-mailman (input) for mailman id 999123;
 Wed, 28 May 2025 09:20:53 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCva-0000yL-BG
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:26 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20613.outbound.protection.outlook.com
 [2a01:111:f403:2418::613])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b0e8e1b0-3ba4-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:18:18 +0200 (CEST)
Received: from SN7PR18CA0004.namprd18.prod.outlook.com (2603:10b6:806:f3::13)
 by DS0PR12MB6485.namprd12.prod.outlook.com (2603:10b6:8:c6::9) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8746.30; Wed, 28 May 2025 09:18:15 +0000
Received: from SN1PEPF00036F3C.namprd05.prod.outlook.com
 (2603:10b6:806:f3:cafe::51) by SN7PR18CA0004.outlook.office365.com
 (2603:10b6:806:f3::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Wed,
 28 May 2025 09:18:15 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F3C.mail.protection.outlook.com (10.167.248.20) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:15 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:18: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" 
X-Inumbo-ID: b0e8e1b0-3ba4-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ykJq8yy1UHtKmFvNbnv1JBg7SzJTkhbzaYyWhQSedH/cKIpu/lZtiDEXblp/datB5q3DVT9DtkHKyXnzU+k1OKog5halHZJJuYhGE9s4u12cgFa2uieMcoKkrqANxF+Q/2/tS7v/PEcjVBLwDPzYKxZFe2lFQdBSRu5g46J9iHD4GIjoZZoGjJfn1shA5I0vxhyA6lhxd0FS7vewWg6NPEyUkmUXm7FjYwXs6L4FLQQ3ddnslCqnl2qvg6IgFuHInPRMnqzC/pRcjbjaWPt+aN8LTR5k6bw8e1i6DdilCxE2v9T7UShy9S+///VSq5DuwUV8r9ND5fjBEqk0Ty8wYg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WurO22YY37NaFn6R/aK5cXS4C2DatHBPKOP8khrxpEY=;
 b=yiqZytG1XXqN2UXcUX1UTuFgmaaaUmhy/NODRZ5D7U+WwzKgPWrolgXDSmPcdG6x17gjbfbifg3I/shucm+h5hFno7KUPe8VQvG1kOIGIz8JMgdzwYRfQEwmbSpk9ehavPN4Ushcm0UnLg011B4XaTdglIghp7berk+tELTINpyozuydNG+SE1z/hZmCtNhDL/+4YYvhPNb9fU8BUKvVfkt1TfNBOA4A/U2+BY1YyXlorRwUIeZj/6ENS2wpbqykxY41J3u6Gs41XSQrt0Rasjq7NHieBG0ia+6SZSLTJRuHP5uLnYTtxaLOBLUjszYoCPIxem6a9CD6xoaxjs5hjQ==
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=WurO22YY37NaFn6R/aK5cXS4C2DatHBPKOP8khrxpEY=;
 b=v0GwN7HhBMpIFJ3g9/DBdKRaMeQBHyz7Ll9+iNJmX0YaCxKNMFKrLyWE/3ozjOIX/aPHTIkyaU2FLfZ0qDOLXEvr8ko1tYrzEiwQ0lInjEdY/bnIZyjX0gX9lUYwICCJgu08lEKdIdUzFymzwswVxOp7d8/IBQXFpo0DcAPAjac=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini , "Daniel
 P. Smith" 
Subject: [PATCH v4 13/20] xen/sysctl: wrap around XEN_SYSCTL_page_offline_op
Date: Wed, 28 May 2025 17:17:01 +0800
Message-ID: <20250528091708.390767-14-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F3C:EE_|DS0PR12MB6485:EE_
X-MS-Office365-Filtering-Correlation-Id: c5f79078-27e1-4d13-c6ee-08dd9dc893c1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?nIeEmvyZMha014u5xvbK/IZcBcV22JBIvxbVm9IhzUWs/3g1tbFXUIcjym12?=
 =?us-ascii?Q?7hn3eGa3PgR+OjwUpTcej4O/VoyOxaAhr8FMjqVn/jubNfa/T61jEzvYslz0?=
 =?us-ascii?Q?o8J/A/V2O84dRSvUyvQtaSSHDO0VAQtjilCx2CMaZ1rhbtyCeikw6JpIvaHb?=
 =?us-ascii?Q?5XdxTLH7+D4RGfmJmqj3apImkpfAAwaAFXrEH0JuvLkGRZe4H8q69+xtm/b5?=
 =?us-ascii?Q?351javU7Zcpm2EN4AT/ZO/XId04tmuE43M07eqMqd1aT8Co3/zxG/pNy8zuT?=
 =?us-ascii?Q?Q5BDyYLixn1WwFe6dm3P/I+3XJWPoi2qizZDmZhNfPDCfC2AElR0LgXfxxpi?=
 =?us-ascii?Q?NdQhv8eIBCt7ISGLVTPwe82mb7fuLeJXzKbcl6JJzqycorNTzCa9AwTcPVA/?=
 =?us-ascii?Q?OftEzA3OcbbwiOZoQP3Nkj4t06V1DpqTp7RjEhhSvMpPPPDT++XBf/Uu4f0k?=
 =?us-ascii?Q?E/x8QQyJBtg5axB5ZL5hu3N/rMhV07N44LgjZLkUoP/qevDlXTV0MKWV1mgn?=
 =?us-ascii?Q?zwa/HRPuziMBbuejeKe+zfiDKsLDoYOtqzwklKnjn3NowmuCibcReIXcer5l?=
 =?us-ascii?Q?4VWEHnHKLyYVDT8fRZQ2jDew3T2BafgMjZWQ/oxKSp+kqKksDONpyfyfOkpd?=
 =?us-ascii?Q?ySESZ1Py+aN/fAXNf0voJbKLLRKh1Npq4jwtuZnnO+eVrX6tT2/IxkR671p7?=
 =?us-ascii?Q?AHpODspuJtCGyZrqlZ17JtaRMX/hY4iuJaH0NTiov3bL82+u0xNWJFBau0sV?=
 =?us-ascii?Q?8P+7UiOc7msTI8mT8F3KTHjfhfe/G2vip7NdLuYoAayyG8/Zv2r3FdnFYyYn?=
 =?us-ascii?Q?o78uG5MotvNJo1oTuwDDLmykssbWgmYYIKuFMnGgL//tL0nC7I5q5lgHg4+w?=
 =?us-ascii?Q?z05oqfFYnqggjWwn5+HMnH0MUhuOU3jQFIZ4MQJIrMv2ZggA4K72xiWfQ56Y?=
 =?us-ascii?Q?YbSHBrtH01n1DVt5u9FEh083IM53F+2xVgt35L3jWFkrua4uvyOe2eXFI91t?=
 =?us-ascii?Q?SyIspVLY1Sas+YlamzOKvFbHvw8dk7BIjMKloQr57ZJABahmvg1KvXrm/sCA?=
 =?us-ascii?Q?7EIkBvl4fPcN7/7gvuM2lyhGg/zCcOBucyk0trvS26ZUxiaZaNLc4upUwoe8?=
 =?us-ascii?Q?YZzYnaWfCs8BZ8+g1ADATEwqj7+LYJ1HyfXGjzKiiQCx2+hZM0ao3Ny1eNy+?=
 =?us-ascii?Q?nTOWLxg6kxVRSx/bHMhCteC4+E2nHxWg5tX3gFHk51FOr7B26GRANCiVfnnb?=
 =?us-ascii?Q?7A2gAOBmJ1kBXvnlThcBDYAFo3RNQPlvdu0ePHagzZd0V3248m0//LrN3JO8?=
 =?us-ascii?Q?TlKzTXGWWHrGMMtRh3ouCoiTX9SZ0BsZ2MgxilXtIMFMTg6/6ZX0zknU/+W7?=
 =?us-ascii?Q?/ZBnzvK6h1qk63873Hv+CdRuMpkuxf1s5d8r6SIQC0l5pwhDA4ob95n+bfdv?=
 =?us-ascii?Q?7UN+oasN9Qwv2N1eN0/zgKs2/UUmO5BJHYhGqZ7FGAVgOY5VIJkFDbdG7gf4?=
 =?us-ascii?Q?s1a4VHKtApulPOohYwaKALDNJaIyLf9xk01O?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:15.3798
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c5f79078-27e1-4d13-c6ee-08dd9dc893c1
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F3C.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6485

The following functions are only to deal with XEN_SYSCTL_page_offline_op,
then shall be wrapped:
- xsm_page_offline()
- online_page()
- query_page_offline()

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v1 -> v2:
- add transient #ifdef in sysctl.c for correct compilation
- no need to wrap declarations
- place the #ifdef inside the function body to have less redundancy
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/page_alloc.c | 2 ++
 xen/include/xsm/xsm.h   | 6 ++++++
 xen/xsm/dummy.c         | 2 ++
 xen/xsm/flask/hooks.c   | 6 ++++++
 4 files changed, 16 insertions(+)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index b204f22f50..dec4cb2ab1 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1779,6 +1779,7 @@ int offline_page(mfn_t mfn, int broken, uint32_t *status)
     return 0;
 }
 
+#ifdef CONFIG_SYSCTL
 /*
  * Online the memory.
  *   The caller should make sure end_pfn <= max_page,
@@ -1863,6 +1864,7 @@ int query_page_offline(mfn_t mfn, uint32_t *status)
 
     return 0;
 }
+#endif /* CONFIG_SYSCTL */
 
 /*
  * This function should only be called with valid pages from the same NUMA
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 042a99449f..5ac99904c4 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -138,7 +138,9 @@ struct xsm_ops {
     int (*resource_setup_gsi)(int gsi);
     int (*resource_setup_misc)(void);
 
+#ifdef CONFIG_SYSCTL
     int (*page_offline)(uint32_t cmd);
+#endif
     int (*hypfs_op)(void);
 
     long (*do_xsm_op)(XEN_GUEST_HANDLE_PARAM(void) op);
@@ -597,7 +599,11 @@ static inline int xsm_resource_setup_misc(xsm_default_t def)
 
 static inline int xsm_page_offline(xsm_default_t def, uint32_t cmd)
 {
+#ifdef CONFIG_SYSCTL
     return alternative_call(xsm_ops.page_offline, cmd);
+#else
+    return -EOPNOTSUPP;
+#endif
 }
 
 static inline int xsm_hypfs_op(xsm_default_t def)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index cd0e844fcf..d46413ad8c 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -96,7 +96,9 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .resource_setup_gsi            = xsm_resource_setup_gsi,
     .resource_setup_misc           = xsm_resource_setup_misc,
 
+#ifdef CONFIG_SYSCTL
     .page_offline                  = xsm_page_offline,
+#endif
     .hypfs_op                      = xsm_hypfs_op,
     .hvm_param                     = xsm_hvm_param,
     .hvm_param_altp2mhvm           = xsm_hvm_param_altp2mhvm,
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index df7e10775b..45c12aa662 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1206,10 +1206,12 @@ static int cf_check flask_resource_unplug_core(void)
     return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
 }
 
+#ifdef CONFIG_SYSCTL
 static int flask_resource_use_core(void)
 {
     return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
 }
+#endif /* CONFIG_SYSCTL */
 
 static int cf_check flask_resource_plug_pci(uint32_t machine_bdf)
 {
@@ -1274,6 +1276,7 @@ static int cf_check flask_resource_setup_misc(void)
     return avc_current_has_perm(SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
 }
 
+#ifdef CONFIG_SYSCTL
 static inline int cf_check flask_page_offline(uint32_t cmd)
 {
     switch ( cmd )
@@ -1288,6 +1291,7 @@ static inline int cf_check flask_page_offline(uint32_t cmd)
         return avc_unknown_permission("page_offline", cmd);
     }
 }
+#endif /* CONFIG_SYSCTL */
 
 static inline int cf_check flask_hypfs_op(void)
 {
@@ -1948,7 +1952,9 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .resource_setup_gsi = flask_resource_setup_gsi,
     .resource_setup_misc = flask_resource_setup_misc,
 
+#ifdef CONFIG_SYSCTL
     .page_offline = flask_page_offline,
+#endif
     .hypfs_op = flask_hypfs_op,
     .hvm_param = flask_hvm_param,
     .hvm_param_altp2mhvm = flask_hvm_param_altp2mhvm,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:21:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:21:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999144.1379886 (Exim 4.92)
	(envelope-from )
	id 1uKCyE-0000Qu-Gp; Wed, 28 May 2025 09:21:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999144.1379886; Wed, 28 May 2025 09:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKCyE-0000Qn-DY; Wed, 28 May 2025 09:21:10 +0000
Received: by outflank-mailman (input) for mailman id 999144;
 Wed, 28 May 2025 09:21:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvg-0001jE-C8
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:32 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2415::61b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b704d4ce-3ba4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 11:18:29 +0200 (CEST)
Received: from SN7PR04CA0163.namprd04.prod.outlook.com (2603:10b6:806:125::18)
 by DM6PR12MB4418.namprd12.prod.outlook.com (2603:10b6:5:28e::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.25; Wed, 28 May
 2025 09:18:25 +0000
Received: from SN1PEPF00036F40.namprd05.prod.outlook.com
 (2603:10b6:806:125:cafe::7a) by SN7PR04CA0163.outlook.office365.com
 (2603:10b6:806:125::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Wed,
 28 May 2025 09:18:25 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F40.mail.protection.outlook.com (10.167.248.24) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:25 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04: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" 
X-Inumbo-ID: b704d4ce-3ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JxtMNzr+s/Jp7BgiIHOxtMJKJS1oc5+wzHWPxCODge/hcKhrkDKIrheVDO7Uwk//Wwl/HxK0apXumzcy77TN/Ggy2EaZzLaQ1JiBrLaGpCMYxbk/RJIsHCa60CjyxWuDQR9jehJGf32QPo619kXBGr7nbW+bsMtkF2L/P+10v8x+eJU7lzGyx44il+3Gzkpg3nh97ZlzkI7PzsDt+lsVwfyx7V5+1u5p8yYS28qMg4s2v0UXaAP6x8pvJaZS0KR21aOXpreRumcDeTLHCfkyckybJpt3gIL6JxyPb6cu9156n0kSoDSIfXcsGtgjXORs/9YjPlVpxXaS9H3hSCWQsQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MvEuxjyrKHpeWz5xkr9emMjeZhe7QGQkfrKWTsEegww=;
 b=Th5B1gAs4e0ZQi5S2hLwXoapaNQpQsf+x6w6C5lDwK8R4cNPSzfvWh1iarV6yZaJ2RMGaS8BYsVZK1yh74NDK6h1ICvAnY1km941SmDLOKlt8/OS6jS849UHMKsBpXL3Y7zujd30SVrg6emXllqZ0cjGPgLPuliKwotYYF2PqZnjbkYXfvRfNIZ5u+e8xdO01ySwj6Pwx7t3xQ8zAOJiUhgIoQPbrqWcExnT+nOF4DUqMtn9brO4h9pYrPyPedp/5hu20/Nrl7ILrEMTuiqWo1BPgbblzcvDtHu/l1cRBI0v5znF3srAtaJPTNSYcjwGRXWhlKN4SydAX1z8PNo6bw==
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=MvEuxjyrKHpeWz5xkr9emMjeZhe7QGQkfrKWTsEegww=;
 b=k/OgSanCbOn/9N9I2aVjZ5Tfsn512dFEC7mGlqFRSHsyqWaQ/YxvixjH8I+sKlZS995IE3kvAzDqUart/j885ilYWHQbsdsmPrvrRZWpWq+hg/SXKILBYLvXqBdfxDKnRgGoIRQP8R9G99rETRQuQacSoa9VJQQlUxd7astH1V0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Alistair Francis , "Bob
 Eshleman" , Connor Davis ,
	Oleksii Kurochko 
Subject: [PATCH v4 16/20] xen/sysctl: wrap around XEN_SYSCTL_physinfo
Date: Wed, 28 May 2025 17:17:04 +0800
Message-ID: <20250528091708.390767-17-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F40:EE_|DM6PR12MB4418:EE_
X-MS-Office365-Filtering-Correlation-Id: fa155ca8-bb51-4066-1644-08dd9dc89983
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|82310400026|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?culF3llLHhx9VxWqBxXaKFZfyStp9ITzCEZFTzYMcGpYKC3QKTcjrH+qjfPU?=
 =?us-ascii?Q?Eqec0bV2vRZvj3AjWP6znsMUmtj6ZjAoOHC34IAxnEqlLoh37iSmN89PgyyR?=
 =?us-ascii?Q?6+VA8NB1aRTEoIXtAeqoo1FzL0PUyh/icdDz4ePu7VPH9jVdtr0dXgZaS8pA?=
 =?us-ascii?Q?/eKmUMb/Y876x2jUHl5VeZnyo39VgSoqkfcIXJZO+Y/RbCS/U8eQaIOwF9+G?=
 =?us-ascii?Q?jyqtJBAC1FIj44QvPPQNBjUe+KQVpRpQ86FbGnX+3NHdIQkmsrZAsrXH9/1W?=
 =?us-ascii?Q?QUKm2iU4p29tvvNBU5sbd/kRACowwWXWZE9FPd/72RIW6V4DpATcCusNX4VU?=
 =?us-ascii?Q?bfiNZL5BsYHClVw4rjKbPsTuR+TvAttzF5GekR66ysKgtAoJHBFwwrQcR6U8?=
 =?us-ascii?Q?7FAHwRpPZqOtLbR5a07w9i5WYO+gZEH9GODuIhYozmgHn9Ubre0sVtmn/NMW?=
 =?us-ascii?Q?6C6E2OVql5CpVtf1x4LGGyMzQ2A5eg1q5M+vT87Yv90yhSluN8MGDqQbt+BY?=
 =?us-ascii?Q?HeJ6FE8b/iBMA62z9RPcNw5ZVqM9fa7xTZXC5RDG2wkOqQYHDOIYnIYBnlux?=
 =?us-ascii?Q?fMsHNtOXp8QZWPG8sVs/gHDU+UHIx5suTMigpHtbPF0YyT5FXoideiWhWEbi?=
 =?us-ascii?Q?lajKYWLWr9FFx/kQY8yTfXMyGGevvActMqztAXYaxSWZOjocsBVJ430QgB5R?=
 =?us-ascii?Q?BdjlrtrtFTdMFf+Ye+eUeFoD3ePUK/9kSgsaBATvyvUitkTs5qnf0UiMq9y2?=
 =?us-ascii?Q?g7b4fx3YK/PvrYg+lnVVR46mQtO8ZyujeezOJ5WpZaJBnjMSQeCneNXB6KC8?=
 =?us-ascii?Q?Galfu+mF2UUQ8Ywf7uH7l15P4TcLTaYcUHaE/JA5MvnpOzzrDue941luA6yv?=
 =?us-ascii?Q?JDkQ0bbhvHAGW8ueIDWEp4s3unqjuXACrvm2/wqUHXV1LwnQt8GdAzzFJeSU?=
 =?us-ascii?Q?US2fPzHgPoMQE2Dd0BD35mIdkZ4av5xFlQhuVNgxOqztEouYYkuvgE+dL/yB?=
 =?us-ascii?Q?oIs2T5xXb4piAhjxZyJpwXWwjNd9N/tlWUXBgIUZHH/D2s+OEBmdZfleij+x?=
 =?us-ascii?Q?uk4raRgL3/SL309JzWTujvCU9v58BEWGEbQg3JawZMu0A40mchpK5tzXNdti?=
 =?us-ascii?Q?zR5xUVpNgKBvE4k16DIha0OoTSSC8yUryxhLKq3bYF/Vz/ZzgX8fNK0UK+2W?=
 =?us-ascii?Q?EpsOLQ2nj0UjgZsgdNDJ1/z9sWt5fdjTKSmjxwbfMfJW3u++Lc8B3unji6g2?=
 =?us-ascii?Q?mF5XFeGdH7qYlfFqNnkNmn/N44yQ6AluzJw9A1pqUpVaddQTtIKqnhqL/o3v?=
 =?us-ascii?Q?s8WJIj+snDhJ8I7tbGbB+1zBJAPlrLs5ISPesLD/AENJu1QhEzgtlLZoP+1z?=
 =?us-ascii?Q?NQPekh3JnGtEA4sNRIiaRBVRxMSoJBKW0HIhW5044E8MPEQH5xLmm3iwBx57?=
 =?us-ascii?Q?jqcK2Tyz34CWC8rKw0YZNtSbsPLrgvVJ2W7Vp5FZNTGnxAvEwQnNsxfz//j0?=
 =?us-ascii?Q?6TawHmsmABa7jst1QglfH/qcbK8ANrUacuBF?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(7416014)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:25.0352
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fa155ca8-bb51-4066-1644-08dd9dc89983
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F40.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4418

The following functions are only used to deal with XEN_SYSCTL_physinfo,
then they shall be wrapped:
- arch_do_physinfo()
- get_outstanding_claims()

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
v1 -> v2:
- no need to wrap declaration
- add transient #ifdef in sysctl.c for correct compilation
---
v2 -> v3:
- move #endif up ahead of the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/arch/arm/sysctl.c   | 2 ++
 xen/arch/riscv/stubs.c  | 2 ++
 xen/arch/x86/sysctl.c   | 2 ++
 xen/common/page_alloc.c | 2 ++
 4 files changed, 8 insertions(+)

diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index 32cab4feff..2d350b700a 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 
+#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm | XEN_SYSCTL_PHYSCAP_hap;
@@ -22,6 +23,7 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
     pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()),
                                        XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
 }
+#endif
 
 long arch_do_sysctl(struct xen_sysctl *sysctl,
                     XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index 83416d3350..295456d0c8 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -321,10 +321,12 @@ long arch_do_sysctl(struct xen_sysctl *sysctl,
     BUG_ON("unimplemented");
 }
 
+#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     BUG_ON("unimplemented");
 }
+#endif /* CONFIG_SYSCTL */
 
 /* p2m.c */
 
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 1b04947516..f64addbe2b 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -91,6 +91,7 @@ static long cf_check smt_up_down_helper(void *data)
     return ret;
 }
 
+#ifdef CONFIG_SYSCTL
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
     memcpy(pi->hw_cap, boot_cpu_data.x86_capability,
@@ -104,6 +105,7 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
     if ( IS_ENABLED(CONFIG_SHADOW_PAGING) )
         pi->capabilities |= XEN_SYSCTL_PHYSCAP_shadow;
 }
+#endif /* CONFIG_SYSCTL */
 
 long arch_do_sysctl(
     struct xen_sysctl *sysctl, XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index dec4cb2ab1..8177d12f50 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -601,6 +601,7 @@ out:
     return ret;
 }
 
+#ifdef CONFIG_SYSCTL
 void get_outstanding_claims(uint64_t *free_pages, uint64_t *outstanding_pages)
 {
     spin_lock(&heap_lock);
@@ -608,6 +609,7 @@ void get_outstanding_claims(uint64_t *free_pages, uint64_t *outstanding_pages)
     *free_pages = avail_heap_pages(MEMZONE_XEN + 1, NR_ZONES - 1, -1);
     spin_unlock(&heap_lock);
 }
+#endif /* CONFIG_SYSCTL */
 
 static bool __read_mostly first_node_initialised;
 #ifndef CONFIG_SEPARATE_XENHEAP
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:21:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:21:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999150.1379892 (Exim 4.92)
	(envelope-from )
	id 1uKCyE-0000X4-TT; Wed, 28 May 2025 09:21:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999150.1379892; Wed, 28 May 2025 09:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKCyE-0000W4-OX; Wed, 28 May 2025 09:21:10 +0000
Received: by outflank-mailman (input) for mailman id 999150;
 Wed, 28 May 2025 09:21:09 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvZ-0000yL-BG
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:25 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2415::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b0de1479-3ba4-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:18:18 +0200 (CEST)
Received: from SN7PR18CA0009.namprd18.prod.outlook.com (2603:10b6:806:f3::17)
 by PH0PR12MB8049.namprd12.prod.outlook.com (2603:10b6:510:28f::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Wed, 28 May
 2025 09:18:13 +0000
Received: from SN1PEPF00036F3C.namprd05.prod.outlook.com
 (2603:10b6:806:f3:cafe::69) by SN7PR18CA0009.outlook.office365.com
 (2603:10b6:806:f3::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.30 via Frontend Transport; Wed,
 28 May 2025 09:18:13 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F3C.mail.protection.outlook.com (10.167.248.20) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:12 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:18: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" 
X-Inumbo-ID: b0de1479-3ba4-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=BQeVAEFQBwvVZKSbcqoFemztvRmo1skfN60fKd6jLfrDpJehsQm3cWlNI2KTuetNJD5UpnhBayqLOGpR+DblkoEwm4RWRqa+5doYY6XtLd9Y422t/L/jOTFeax4VawBl2B+7Y1SPkKtQ6ZjMbgkpz4avN/DB5k2zLRmxBeJvXzBWq6LalRtmGxGttvKtJycKO1K8DSM+uDNZYELe0hIptFtVcZR7+ORSa3U+3T1pZx5sravwj3QOepltyNQIjI3QBphma/toGcRkjcak7YjaNixLUNShDwMHSyh4jQqSroqJVVDiElhbxYjsKmHFCPQMyNVZtrkdgtLimuhPakE8OQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tIqBzSuJ/XN3+20akguQcfadUFZOlGGGnySlPyMwy4g=;
 b=QkBky4/Mx+cpF0jeWUP1FK+O8uBseKg4dYj2CLYCaszOiynxD8Kt8CeOwIIL22pKRQkaerv22ULSewz9FxOZon8jMc/8cAP1PlR4EuzbYgFERFjJEp7zvNXVw6V2oftULv4gbOe5OOmbALwPI3kcWRZoMDl9N3eiPCgO79n1XOAhPhrC2lBXofseV0RVPfJKg/EiV43qIgBvaS6Gh75aobmgEKxqCyt+kOtWM2k4kT7gMuf/goSbaMMJkN+M9MkKYmDAyP5Nsk8ViOOfrcFhh3DFnpNExp5hc97odStXFA5ARlCS/krlvs0PZb/opyaVzLk3qm0mruMNQqS8De9ebw==
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=tIqBzSuJ/XN3+20akguQcfadUFZOlGGGnySlPyMwy4g=;
 b=ypad468D1fBrDtuea59G688umcvfh8R5eBGu96zDnWPzSB2HtSbBFg18wniKr5dmFjBEcxkX1S+sHuIbPvKdqvk5CvSR6RnT7e+Dg1QwGGsmMVR7LG2OXKtyAA7V5XzXawZQ+DJYUarhqOnwgcQZZExtbC45iZkts/BSv+NDUdw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v4 12/20] xen/sysctl: introduce CONFIG_PM_STATS
Date: Wed, 28 May 2025 17:17:00 +0800
Message-ID: <20250528091708.390767-13-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F3C:EE_|PH0PR12MB8049:EE_
X-MS-Office365-Filtering-Correlation-Id: 45cf8487-88cb-4750-064e-08dd9dc8924e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Lr1nGnRiOflKVtTZ+kiT7WNfvWqcNnrUHsYYZxPWIFZ+kJydpT7gEsH+xhls?=
 =?us-ascii?Q?4yP8Beq8O+COtHsMw1OhtgFO7FztxZe6/QAIPfyPAkOnB8vidOX17+sPZXd/?=
 =?us-ascii?Q?8lh3h3m5QGoQXp+77zD3RvtXYj0mPUJEXh6OuIUMbGSohm7+xSNTLtveCGsU?=
 =?us-ascii?Q?1vtouPAp3XQxbvYxy7UmoA4Rns3UOwgN+vLoG11VA2S++MQeqoIF98N3MlkU?=
 =?us-ascii?Q?MZV8Okiz/iEXQhwxN9/Fg35zLr6hYKnddyghwUqi8WuvKUYz4EuTkkyfO/vU?=
 =?us-ascii?Q?TnydtY7j+p+b3w7XnPfKBPMs/OWdVCei99Ud56H9j1+wWDnq6+b6chbv9Tsi?=
 =?us-ascii?Q?FV5OxmSGoOuPdY587fXksLGWp/EzHAIGsefAN/ShVuCkf/jGo5ag7x9dhj9X?=
 =?us-ascii?Q?LVPPaDf/9CIJE1SvIBMNC3S6iEXPihIk5DWadgMM1yvbkCkvxDNsULkivYK0?=
 =?us-ascii?Q?WAZ/J4nvW+kXTGHYiXWhtxmYgxR++jBu9eSwKEFL+TahG3w2GmwHsc6/seH5?=
 =?us-ascii?Q?Kf9dfcM4buYZpv6iR8chwcbLpjFy3M4dwFd4m1okLXjc52ReJxHJFFY1K4Uv?=
 =?us-ascii?Q?fzux36tu1vAMxZVEcb/6Krq2xyaT5Pwzznjr2XOaef/Rc3S3ee+9YsPPnJqn?=
 =?us-ascii?Q?UW7ph+MmSLGIaJgIbTj/b5kAk4P2hrm+L9kumwI+Nc8QDZtKO+NvntLhvR1V?=
 =?us-ascii?Q?qI5gx/akn4xB5Cq/87gquN2Pk+Ot02tnixBzfpoDARGDrO8L/wLKb/98b9s7?=
 =?us-ascii?Q?mKd+94oPHAz0IraM7vXZZR9cGkCZJlmmmmLLOOZCFk7CUwuZgVca+mSshmF3?=
 =?us-ascii?Q?2z+R2Ud3YTJ8Jd4u9vDWAi9+RW1gXl7XZWpfQxxdamnF8Fr24NHcEk+xq9Qt?=
 =?us-ascii?Q?dJzyo3Zw1FAcLiqoTKUNMhaMvgVBHV+s6HitViSccJpWBeO37BK2K1p7kTNB?=
 =?us-ascii?Q?BSbXytbgaP+Z/qLHRRWuJfdBh/Mq5Pw4M5yZeZcfnypuDL2uikxckdTBK1ej?=
 =?us-ascii?Q?GfiBJasOzBTJ2/LDV5ix9kWT0GaNzvTeCXpr5CJ2t0usdSeYITxGRYgwOB5U?=
 =?us-ascii?Q?i+l+rYXGgpVYUpsp3W+CpbprXivmrMbaYIDbEKNFtvSBegswbb5JvEHtncX3?=
 =?us-ascii?Q?5nY/b7wmi/+FFgEk+ZMjK2xq0uH2HWq1fC1KeBmFCDteEqd9f8JYRjiGkfjj?=
 =?us-ascii?Q?aMt9ofjfRCmcxD39eLRRq1lZ8yJpr76Qm2KI9ct7ytY0mqu8NqZ1y1GyHPSZ?=
 =?us-ascii?Q?eBrVR0Ro488lfYq3PR6DIO9HNLQDXxQm1En8NGVW9WhHoPLiSCfUCZiFKfDb?=
 =?us-ascii?Q?fjbKiV4Sg1o/nKrJ/xOI+ci+APUOXklP1kE0K4TRWsa1eyEvbmul3Ri4DFag?=
 =?us-ascii?Q?tF0641vYdG/euZ6no2MU3gD6ceN/Ar1jYf3sWPscTH3sNcKrNLNPHLTCwrT6?=
 =?us-ascii?Q?gou2dpTg01x7bQ8+vdIbcsk1DvhE2d8IYiJ/0m0qdHn49bxrvCmyF3PjfH50?=
 =?us-ascii?Q?vsmLtDBHthKBIePpl9hLQrpiYi+om0GJWxoF?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:12.9439
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 45cf8487-88cb-4750-064e-08dd9dc8924e
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F3C.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8049

We introduce a new Kconfig CONFIG_PM_STATS for wrapping all operations
regarding performance management statistics.
The major codes reside in xen/drivers/acpi/pmstat.c, including the
pm-statistic-related sysctl op: do_get_pm_info().
CONFIG_PM_STATS also shall depend on CONFIG_SYSCTL

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
v1 -> v2:
- rename to CONFIG_PM_STATS
- fix indention and stray semicolon
- make code movements into a new commit
- No need to wrap inline functions and declarations
---
v2 -> v3:
- sepearte functions related to do_pm_op() into a new commit
- both braces shall be moved to the line with the closing parenthesis
---
v3 -> v4:
- be consistent with the comment on the #endif
---
 xen/arch/x86/acpi/cpu_idle.c              |  2 ++
 xen/common/Kconfig                        |  8 ++++++++
 xen/common/sysctl.c                       |  2 +-
 xen/drivers/acpi/Makefile                 |  2 +-
 xen/include/acpi/cpufreq/processor_perf.h | 10 ++++++++++
 5 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 1dbf15b01e..974d81b4d6 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -1493,6 +1493,7 @@ static void amd_cpuidle_init(struct acpi_processor_power *power)
         vendor_override = -1;
 }
 
+#ifdef CONFIG_PM_STATS
 uint32_t pmstat_get_cx_nr(unsigned int cpu)
 {
     return processor_powers[cpu] ? processor_powers[cpu]->count : 0;
@@ -1612,6 +1613,7 @@ int pmstat_reset_cx_stat(unsigned int cpu)
 {
     return 0;
 }
+#endif /* CONFIG_PM_STATS */
 
 void cpuidle_disable_deep_cstate(void)
 {
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 712c29b1a0..9bf632973e 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -598,4 +598,12 @@ config PM_OP
 	help
 	  This option shall enable userspace performance management control
 	  to do power/performance analyzing and tuning.
+
+config PM_STATS
+	bool "Enable Performance Management Statistics"
+	depends on ACPI && HAS_CPUFREQ && SYSCTL
+	default y
+	help
+	  Enable collection of performance management statistics to aid in
+	  analyzing and tuning power/performance characteristics of the system
 endmenu
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index daf57fbe56..5207664252 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -170,7 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         op->u.availheap.avail_bytes <<= PAGE_SHIFT;
         break;
 
-#if defined (CONFIG_ACPI) && defined (CONFIG_HAS_CPUFREQ)
+#ifdef CONFIG_PM_STATS
     case XEN_SYSCTL_get_pmstat:
         ret = do_get_pm_info(&op->u.get_pmstat);
         break;
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index 1d811a51a7..477408afbe 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -5,7 +5,7 @@ obj-$(CONFIG_X86) += apei/
 obj-bin-y += tables.init.o
 obj-$(CONFIG_ACPI_NUMA) += numa.o
 obj-y += osl.o
-obj-$(CONFIG_HAS_CPUFREQ) += pmstat.o
+obj-$(CONFIG_PM_STATS) += pmstat.o
 obj-$(CONFIG_PM_OP) += pm-op.o
 
 obj-$(CONFIG_X86) += hwregs.o
diff --git a/xen/include/acpi/cpufreq/processor_perf.h b/xen/include/acpi/cpufreq/processor_perf.h
index 6de43f8602..a9a3b7a372 100644
--- a/xen/include/acpi/cpufreq/processor_perf.h
+++ b/xen/include/acpi/cpufreq/processor_perf.h
@@ -9,9 +9,19 @@
 
 unsigned int powernow_register_driver(void);
 unsigned int get_measured_perf(unsigned int cpu, unsigned int flag);
+#ifdef CONFIG_PM_STATS
 void cpufreq_statistic_update(unsigned int cpu, uint8_t from, uint8_t to);
 int  cpufreq_statistic_init(unsigned int cpu);
 void cpufreq_statistic_exit(unsigned int cpu);
+#else
+static inline void cpufreq_statistic_update(unsigned int cpu, uint8_t from,
+                                            uint8_t to) {}
+static inline int cpufreq_statistic_init(unsigned int cpu)
+{
+    return 0;
+}
+static inline void cpufreq_statistic_exit(unsigned int cpu) {}
+#endif /* CONFIG_PM_STATS */
 
 int  cpufreq_limit_change(unsigned int cpu);
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:21:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:21:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999153.1379906 (Exim 4.92)
	(envelope-from )
	id 1uKCyH-00012h-2C; Wed, 28 May 2025 09:21:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999153.1379906; Wed, 28 May 2025 09:21: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 1uKCyG-00012X-VS; Wed, 28 May 2025 09:21:12 +0000
Received: by outflank-mailman (input) for mailman id 999153;
 Wed, 28 May 2025 09:21:11 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvt-0001jE-VA
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:45 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20620.outbound.protection.outlook.com
 [2a01:111:f403:2412::620])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c091df84-3ba4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 11:18:44 +0200 (CEST)
Received: from SN7P220CA0009.NAMP220.PROD.OUTLOOK.COM (2603:10b6:806:123::14)
 by CY3PR12MB9553.namprd12.prod.outlook.com (2603:10b6:930:109::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.24; Wed, 28 May
 2025 09:18:39 +0000
Received: from SN1PEPF00036F3D.namprd05.prod.outlook.com
 (2603:10b6:806:123:cafe::bf) by SN7P220CA0009.outlook.office365.com
 (2603:10b6:806:123::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.27 via Frontend Transport; Wed,
 28 May 2025 09:18:39 +0000
Received: from SATLEXMB04.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_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:37 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:18: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" 
X-Inumbo-ID: c091df84-3ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Q50e1AzrIjvo3HCLlv0fr+21eXnJqcm6mNwEEMg2xlgMjzzj89BVtoOBpXt2oK4qkIpa2wFrE/ivYsKpPz7F058rsEkmhSIs4pjEVfqtf0RP3IBqKn89plRm7LXdZxJJ9uw4X3wJrVECfUXbFxyNPEgh10PgU8RlZWvHKwHlr9UKu2seNoBEfWjM1eG6PptCDlN38VpPzGu84HI4YGX82eGJOa3DhrAbhgY9STHtxAUdYkcwsZ1JW3kDh/Mccbq2N+uhYLp4qqS6CjfFUiIH+R7qi8V+WNhO5Qep+KFUFjNHqzz4v5z6vCOGB5PP/LoFtKzbekbfFFHwCSCkk4c01g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9OgIGJyIT/gZNe8sCFDPW5ddcNiwIXM6H4cqzDnIpR8=;
 b=J5LOtIPiWDsM+Pk9gFWLfe7ewMFgFc8WaN2qYq8F820hcfCFC8iHWRnf1Jx22FXEzQJrJ5mY2MA1kptDlwnBc3K88fLOR7xayrTS/v3zvmwboEODFbk6qEyMOm3MsQ+VctL2Ok0aflDILwqb45ZpSgitwocmfAf2MbN5f+Ffp6Ebe1tQaM4QfkZlLq2tYU9lAbsxRohS8suMPOSh8BvZ4xUuGqiQv9FlXFmuIK81Zu3aw4tes4Pl7+oWsAE/sIfATNyKTte20/P/BnKlOpCwYRCP19uyYON8I0lvJdLoAk+Ez8M3UKYm9ZkduzA05UMj51tZ/1c5SShXN8BACQih4w==
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=9OgIGJyIT/gZNe8sCFDPW5ddcNiwIXM6H4cqzDnIpR8=;
 b=rET9iuTxcodOnYBSNkIWLFfQBnc7VmKaa7dpSyRQmUQka5prBz97JH+NIEQ+T2FjWde1XqAZd4iJ3a0h4PKj8ny3xZMlj0vsV1pGBqRBZm+JagvbIHiMqBSvx44x1zNNrpJcZYC/0GHbIsJzf+xPmIh/NaVpAVklTP1cOPxCkZs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Stefano Stabellini , "Jan
 Beulich" , Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini ,
	Sergiy Kibrik , Penny Zheng 
Subject: [PATCH v4 20/20] xen/sysctl: wrap around sysctl hypercall
Date: Wed, 28 May 2025 17:17:08 +0800
Message-ID: <20250528091708.390767-21-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F3D:EE_|CY3PR12MB9553:EE_
X-MS-Office365-Filtering-Correlation-Id: e57dbc44-e75f-4220-35c5-08dd9dc8a0e7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?bTbkueuAhXjEcqwdaTjt461Fpz1wE8rmzHQLjXzDhL/YJgsJBI7gqMRi8cag?=
 =?us-ascii?Q?Kx5Jel6Alwp7t/YyjZswjXhINCFGl5RmCzWFlXUO23OJF29bEo7mLIgcdMQD?=
 =?us-ascii?Q?gqGcCXWR+n1PVScx8kpgrebUCzH/8bFlsWVg5hDhzt9KnbnCYZWaXqxEFmrQ?=
 =?us-ascii?Q?rQyolkwCK3vJS2Xc54vjM+LWzptvQphzTl/5VV7/Va4gXuljZtcvtFms3rMN?=
 =?us-ascii?Q?HMgiNpHArJbV+gX9+aqurf0GWdFIDcz/VYpl69Oox3FRWouisT0tO3iDs+EC?=
 =?us-ascii?Q?RgqhIOxaERY4FTKVeyft40rajyrqPW+UPixN10/3mqeoxBNM9ens5bYGwM9n?=
 =?us-ascii?Q?sRR77/bsOSvzscsLbnxy7kB/nO8LNgUko0/p8arR0UkbnIUHl2z90f3tJLkg?=
 =?us-ascii?Q?UKn/RPludy3Zq8MJ4m7FU9pPrYzqcByPKYGRhnzpoG0hHns+imEJF5a5Ai2s?=
 =?us-ascii?Q?ujTyA3IvmZYonDznLkIeXHoDv7mstzF+kS2vJatulqZHE3yYWvMhGQ3z0fs3?=
 =?us-ascii?Q?oh8hwGjWSlvGPHRLly2jFjx/k81O6+SwpVu2YrGLHniSoMwTNxWtB10uSN3d?=
 =?us-ascii?Q?uL7jGnvP93Q/6fmIn+a+lyRmF/pkHeHq1fxOcEco/djk8Bq/NRdy5oRDTM1D?=
 =?us-ascii?Q?doiZFkB6GHLnaukloNAUQlCz0uM9INirscl7gSUsceCUVga6om7ItcEI9LQD?=
 =?us-ascii?Q?qv9wSpxrO5cQ3rpT4bp38h4pKozvZP+mGnEC5uDsxVc7HR/f6FQOe8TeRDHM?=
 =?us-ascii?Q?3U/vDcx/xxaiRQjwOTtKZtjBOnwOOIgijKSQ3Bf7Vc116HwCDQ2pttMZPbNf?=
 =?us-ascii?Q?4gHZNHOG1d3byincY5CEuK38cZECNV49hgzcR1KfG/3+4HlirVd4ug9fUCfk?=
 =?us-ascii?Q?sur+VQd/iom2mSAOzC8Sy2uwkxjSfjBNfT2ryXPSY4VznQY/mXFzWEyfO/ba?=
 =?us-ascii?Q?z6CFQ498e6OH9dEZkEdiTaVdOq2NYBkt72MzlmyALIrcEBphdS4igzjsyh55?=
 =?us-ascii?Q?Zx7QmJXLddunD8/rQIfguVo6aVUEC39G5pGxcLvELwMevhBZTCImc+GIM2gz?=
 =?us-ascii?Q?EG7bpJgxJcVstG7SsbSqt//KbYhMhUWtJoTbX7Da3+VQgmJWrGHj9xIXptpN?=
 =?us-ascii?Q?OmehUSQdZ9MRJQDDYaPEUegjnjgtSC6XGfYoDIbJsI75MYblrcEQv6dOLxPF?=
 =?us-ascii?Q?x69LcVEqTD0r/Bhm5I95w9tfEioI8n6rlvLRYj+L38zyC90kozCAtZeQBcC0?=
 =?us-ascii?Q?mNZBHR4J20/AVPWOFYsky3nvs733SS1BPq/1yLdsnvcHn12iiMqrIsHKgNdg?=
 =?us-ascii?Q?Agh9TJ3f6lkoOpzgqt7TDW6AzolFe2zLh+6vaj9PEXpH0l7lOD7ALxr26c01?=
 =?us-ascii?Q?mVTKIs01BeYX/eq2s2BtG9x3hrS8OZd0MIKQhWJVSLwptJV9+3794Tn0tTlJ?=
 =?us-ascii?Q?tAMg1xeiBIVwfKj2Mn2NGNe/jO1sWnMLWji63Gw04McWArZzc8q25LURRJv9?=
 =?us-ascii?Q?6Erf3jW50ozpuzGWDwEdKtb7F8qWQtLGmd4D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:37.4358
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e57dbc44-e75f-4220-35c5-08dd9dc8a0e7
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=[SATLEXMB04.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: CY3PR12MB9553

From: Stefano Stabellini 

Wrap sysctl hypercall def and sysctl.o with CONFIG_SYSCTL, and since
PV_SHIM_EXCLUSIVE needs sorting in the future, we move them out of
PV_SHIM_EXCLUSIVE condition at the same time.

We need to make SYSCTL with prompt back and state unsetting SYSCTL in
pvshim_defconfig to explicitly make it unavailable for PV shim.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Sergiy Kibrik 
Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v1 -> v2:
- remove all transient "#ifdef CONFIG_SYSCTL"-s in sysctl.c
---
v2 -> v3:
- move out of CONFIG_PV_SHIM_EXCLUSIVE condition
---
v3 -> v4:
- make SYSCTL with prompt
- state unsetting SYSCTL in pvshim_defconfig
---
 xen/arch/x86/configs/pvshim_defconfig | 1 +
 xen/common/Kconfig                    | 2 +-
 xen/common/Makefile                   | 2 +-
 xen/include/hypercall-defs.c          | 8 ++++++--
 4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/configs/pvshim_defconfig b/xen/arch/x86/configs/pvshim_defconfig
index 6f652e145e..7d0cd45493 100644
--- a/xen/arch/x86/configs/pvshim_defconfig
+++ b/xen/arch/x86/configs/pvshim_defconfig
@@ -31,3 +31,4 @@ CONFIG_EXPERT=y
 # HYPERV_HYPERV_GUEST is not set
 # CONFIG_HVM is not set
 # CONFIG_VGA is not set
+# CONFIG_SYSCTL is not set
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index e3b6fd6ec4..f85593a9db 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -585,7 +585,7 @@ menu "Supported hypercall interfaces"
 
 config SYSCTL
 	bool "Enable sysctl hypercall"
-	def_bool y
+	default y
 	help
 	  This option shall only be disabled on some dom0less systems,
 	  to reduce Xen footprint.
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..15ab048244 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -49,6 +49,7 @@ obj-y += spinlock.o
 obj-$(CONFIG_STACK_PROTECTOR) += stack-protector.o
 obj-y += stop_machine.o
 obj-y += symbols.o
+obj-$(CONFIG_SYSCTL) += sysctl.o
 obj-y += tasklet.o
 obj-y += time.o
 obj-y += timer.o
@@ -70,7 +71,6 @@ obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o
 ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
 obj-y += domctl.o
 obj-$(CONFIG_VM_EVENT) += monitor.o
-obj-y += sysctl.o
 endif
 
 extra-y := symbols-dummy.o
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 7720a29ade..c1081d87a2 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -194,8 +194,10 @@ kexec_op(unsigned long op, void *uarg)
 #ifdef CONFIG_IOREQ_SERVER
 dm_op(domid_t domid, unsigned int nr_bufs, xen_dm_op_buf_t *bufs)
 #endif
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_SYSCTL
 sysctl(xen_sysctl_t *u_sysctl)
+#endif
+#ifndef CONFIG_PV_SHIM_EXCLUSIVE
 domctl(xen_domctl_t *u_domctl)
 paging_domctl_cont(xen_domctl_t *u_domctl)
 platform_op(xen_platform_op_t *u_xenpf_op)
@@ -273,8 +275,10 @@ physdev_op                         compat   do       hvm      hvm      do_arm
 #ifdef CONFIG_HVM
 hvm_op                             do       do       do       do       do
 #endif
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_SYSCTL
 sysctl                             do       do       do       do       do
+#endif
+#ifndef CONFIG_PV_SHIM_EXCLUSIVE
 domctl                             do       do       do       do       do
 #endif
 #ifdef CONFIG_KEXEC
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:21:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:21:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999159.1379916 (Exim 4.92)
	(envelope-from )
	id 1uKCyK-0001N4-BL; Wed, 28 May 2025 09:21:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999159.1379916; Wed, 28 May 2025 09:21:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKCyK-0001Mu-7J; Wed, 28 May 2025 09:21:16 +0000
Received: by outflank-mailman (input) for mailman id 999159;
 Wed, 28 May 2025 09:21:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvi-0001jE-3Z
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:34 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20621.outbound.protection.outlook.com
 [2a01:111:f403:2418::621])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b9464088-3ba4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 11:18:32 +0200 (CEST)
Received: from SN7PR04CA0171.namprd04.prod.outlook.com (2603:10b6:806:125::26)
 by MN0PR12MB5715.namprd12.prod.outlook.com (2603:10b6:208:372::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.22; Wed, 28 May
 2025 09:18:28 +0000
Received: from SN1PEPF00036F40.namprd05.prod.outlook.com
 (2603:10b6:806:125:cafe::b2) by SN7PR04CA0171.outlook.office365.com
 (2603:10b6:806:125::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.24 via Frontend Transport; Wed,
 28 May 2025 09:18:27 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F40.mail.protection.outlook.com (10.167.248.24) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:27 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:18: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" 
X-Inumbo-ID: b9464088-3ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=RLtur3S3WV0wcqKvk+on1WNcVJcJulyyexWi9HxSpm25idw/bLwpg2gyResbvTw1s6QFf+cO2Sq+BfaZ019LyDI7ooxKYul1Qza08VLWPYJVctRcumPpvJJXgmSVuviGtJnredF1ibIk5UhmCZGtQEoYpFzQMLpA9FvtVEBVZjRuA4Z5QvdID/1/HKU32fzaiIim6Y1IFnk/w4ewOyaFx29bHLPSjN2nEefRwMod98iN79PqlhpAXLWodqjDG146nnlctHc/+PIL1dAbCZc/qxY0wkBG+vgPsUzGx2DxVePUMekbxqkvl/GmVOw9HQFTzRKeASXs3tUxD018cTLXDg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2b2CWzsDEAqRVTo0xhsHOqqreygQWWop6mCIRDuco4A=;
 b=NISe/asblfRxa9zlYK1+Sh1lsqldnM6u7MYZC7LzXTABWLcFoR3g6Vp/7VDlbbTimkw1vt7hZfyKE4N4KbM70f8uN6Hn4OQ8t7APCe5BWHCXK51HZE5BaiZoMUY2Kl3bkPznKtP6HDbp0qIiA0nLDeG2fpTX3z0YJUkYdTWaEzif3dMMh88ewYf49hBm92ZTrra3lmSDIt73zZ/03etpAntul5dLg6kKML7knGEIRJ/s+PV1NgIl7lJTdmkYKmBcuS52Wr6hXNgRpjmE0VA8uq6Va5fmqrUWMvXyATJQ6EZhf4n5mGVz24JFwTlu5uS65nlDuKPkVz3QqZSX4C5T/w==
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=2b2CWzsDEAqRVTo0xhsHOqqreygQWWop6mCIRDuco4A=;
 b=W6IdlsFOUAtA6zoA70Pa9U5GJywONShbMXHvGeFso/b0QKSz/6pttoNwDH8O58JKjq/bRCVkQRcl7CkFIdNEoGRdl8xyDLsLaTBW+2+bzjO6UcRhlvX6h0SAIqXE9y78y5ipf1XTIj/9ME9y5B1C2SjlP3PghvsBONpVhV6UCXc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v4 17/20] xen/sysctl: make CONFIG_COVERAGE depend on CONFIG_SYSCTL
Date: Wed, 28 May 2025 17:17:05 +0800
Message-ID: <20250528091708.390767-18-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F40:EE_|MN0PR12MB5715:EE_
X-MS-Office365-Filtering-Correlation-Id: bb4e859a-66eb-4e93-5f21-08dd9dc89b1c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Me2XFMA6aVSso6CoXpMa+edIQWr/OzPM7b2Qe5ywoDXC1ssFTynUpqkYcip1?=
 =?us-ascii?Q?dnb8uer+vZyo99Pjr9sUfkqXUxzqzMJoT7rS9R/8lN5BmBe62ota6eka9uTy?=
 =?us-ascii?Q?/HYrgJE4uzeKAqcwvOniL9XS1yRCakiYKB1rhO/W0zHuILxybZeRX+IZjGJc?=
 =?us-ascii?Q?xB2lhFqh1w46ZOFvpYS11hUiofTVz/zOhxylwCnuj/VVjNG4S82xDIPGNuJG?=
 =?us-ascii?Q?j2IUKzBZffKtVaJadKhO3xOa8VGMRoTRjvM/dlnOX0DQtTbW7CxcO9wCdINN?=
 =?us-ascii?Q?NTKsMoVD/j/UWXAQ90dZQb/lHTqH7hOlRNITYny+U3/1qMXOqZ90WqYdIbbN?=
 =?us-ascii?Q?gVNK5Cku3RHOZVloU877v0Cw563/xd7r3IsnpgtkOw/sbdYZXCCKr/8/+o6z?=
 =?us-ascii?Q?3ZE1+4StmePXcPeWzBUNsbbhrYrtf9BhxmWPnluMjWzAjgajH9NM9IyyroXT?=
 =?us-ascii?Q?5YT3orB0SfydaDCPlegYWtsS2JZ+jBA1QX0TztTO6XjDQZbiuEsBSl8x6Vy6?=
 =?us-ascii?Q?RY7nwO04JdZq/NP+vGh7uGyFehq4UyNfkDEjF6GqTSkU6ykfFGpfUeBYCygw?=
 =?us-ascii?Q?RvXRmbIzwaol2THqysWmCYyQQKJZsB7LQ6jGhgmm2z38QnrTSymi7nx2WvB6?=
 =?us-ascii?Q?KP0/it+C87ocF8U0slyJuYDsgV/rzaccTQ5A1yW5nmu9KUXXW6Ip+WDElsvq?=
 =?us-ascii?Q?GQYXyYgSAJsy/VSGgNYj2lzdV8Ad3/USQPEXptHKNhxnT5NLT/OyXsd3+vBy?=
 =?us-ascii?Q?eRSiqSiEbKUIik1Y8C+cDiIO8k7WbexWnGYvXVOucYR4NKSkEaQZk8pr2y8s?=
 =?us-ascii?Q?rJxGL05aFOL9sa9IWvajScaojSDETfrQziNK/BAJKlTBe42zaCF0pfdHsgo+?=
 =?us-ascii?Q?a8LHMqTS281hyGSJXkyaNafYOxy8k3mSf+4HVd+cHO11YxWvinEmdsYhgpsv?=
 =?us-ascii?Q?UmPORGqm7EsrVS119bgjJK1iS6d1PEq8MuWjrRRwe1oU89hnI8X7ZXBS3Ycz?=
 =?us-ascii?Q?QxAeYN6L6Tc7th7W9uCZzHaY1U64Hoqxh7hlVaBdUf4wdulBjSLFf+XVkpxD?=
 =?us-ascii?Q?tvrAqEpW2sV3pGKZcBWi2oLed94TCeURkHDbRyyUdK93c88yTo4fX0Hgero+?=
 =?us-ascii?Q?xyLYdEw8r36fW9ZrXbN94VjLFxf78E1PxFNoBPWEBNwoZOm0bIMC1W4FaS04?=
 =?us-ascii?Q?GXrceRR/hVfhKNjFqw4/xe2YVb1UIw/8AYZU7RY88SEXZxd7Erb03TnWGpE7?=
 =?us-ascii?Q?25vWzxEYzLyqJLCUHiTeUHAK+aJv8w5/mt2QdaH6rOhgJ/h32aJNLSV+Vnc1?=
 =?us-ascii?Q?T/IPlGY+qpFN7qy6DSKTxlANB7RLCTHmAIvGeMexKRqL6fmtwFNYKubsQT2v?=
 =?us-ascii?Q?jaUKBvOEUDPorYEUsHr+kVqlWLSTK3gT+wAD5V0nqhr+1t4X27KydL3WSOCk?=
 =?us-ascii?Q?vbqvbekUouclxmEfSCCxcGACyU21oox7Y24wdN+Zd8rSnMn1432Qeyp568kh?=
 =?us-ascii?Q?EF9vWwVYYAyfBKIHfGrXQvBQkM+/6iwOhFcJ?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:27.7183
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bb4e859a-66eb-4e93-5f21-08dd9dc89b1c
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F40.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5715

All coverage-related op shall be wrapped around with CONFIG_SYSCTL,
so we shall make CONFIG_COVERAGE depend on CONFIG_SYSCTL.

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v1 -> v2:
- commit message refactor
---
v3 -> v4:
- commit message refactor
---
 xen/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index d14093017e..c4198f0ac8 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -37,7 +37,7 @@ config SELF_TESTS
 
 config COVERAGE
 	bool "Code coverage support"
-	depends on !LIVEPATCH
+	depends on !LIVEPATCH && SYSCTL
 	select SUPPRESS_DUPLICATE_SYMBOL_WARNINGS if !ENFORCE_UNIQUE_SYMBOLS
 	help
 	  Enable code coverage support.
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:21:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:21:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999173.1379925 (Exim 4.92)
	(envelope-from )
	id 1uKCyY-0002SG-RT; Wed, 28 May 2025 09:21:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999173.1379925; Wed, 28 May 2025 09:21: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 1uKCyY-0002S9-OS; Wed, 28 May 2025 09:21:30 +0000
Received: by outflank-mailman (input) for mailman id 999173;
 Wed, 28 May 2025 09:21:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvO-0000yL-9J
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:14 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20628.outbound.protection.outlook.com
 [2a01:111:f403:2407::628])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ace5f501-3ba4-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:18:12 +0200 (CEST)
Received: from SN7PR18CA0011.namprd18.prod.outlook.com (2603:10b6:806:f3::19)
 by SA1PR12MB6845.namprd12.prod.outlook.com (2603:10b6:806:25c::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Wed, 28 May
 2025 09:18:07 +0000
Received: from SN1PEPF00036F41.namprd05.prod.outlook.com
 (2603:10b6:806:f3:cafe::39) by SN7PR18CA0011.outlook.office365.com
 (2603:10b6:806:f3::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.32 via Frontend Transport; Wed,
 28 May 2025 09:18:07 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F41.mail.protection.outlook.com (10.167.248.25) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:07 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:18: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" 
X-Inumbo-ID: ace5f501-3ba4-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FW+Sn6Qsmmzm5l9wGcSElkVrbgCfddXKslUdSX8xIplM8crnXGOzbwBRrNoPxlpVjX6QP0GKfx8ywr85ruYV6HnpPDNQ832ppjBQmKm2v+PWTAYtOSW73N5kb4jLt44cJOM6WlC1oNxDuUrBOiDnpbPnBRUGwJ2/YHF2axg0loMrjFJSbU/tYFoyOcfPk53SXdAkIrR96q9uqnpiYrc4KpTKw19wjg5UACK3VrwngRXVPOF8GdUZ79L+DKHR7R9J6UPbYMWkwJqqwwL0YeXfF/zE6w6rWQGBTtA32al4Dh2AFwA473zlSK9L3oGQUlU/U2SRp8UidAa5Cs4uphbPGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6PNM5kmGchxaBPy9UTeIPhmjlaI6cmNBtQ+7yjRXB+Y=;
 b=UlZio1P/jjlObvX7fsIr1uiCHol1Vcf5A4ptTAXexd/qiibkn6tXIcf+FEz+TBFStSE3pVc5UedS58Yw+1gGjA24+rap/LYWSIwPoKrT+Ew6PtgUoFsincOqUT8HsosccOw0Xmm7SFNaHgX2N9ScoAxYD9wyrs8QbJlYbknEJARCx+a1q1MSlx1Nm5gJQseM0CYIpvHgeTBqv7PYZgilvr24+V4/Poy3kgBVIg0MlWUkoeDl08O2nJk+m3M6gKUY0cwMjT8m0+VscZAQNDaXXeDpqohjmC73PnLSRFMwfeh5hiVIZz7fS1nohkqbc31YjOm53w6GRUK4qn+Tg2VmYQ==
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=6PNM5kmGchxaBPy9UTeIPhmjlaI6cmNBtQ+7yjRXB+Y=;
 b=dV26dEczxQnKEcq4MhFBfZoJikIkSxcK4u9I4Xghq5Hy+Pi6zdON8GqeB4Gh0Suey57JZt5Zis4vSF1nVuNWEw/NjyiYdQaS5tFacybCwPYmVIqu9cLYLANB10TnyVTCQpdajvQ9mZHtImKpPwmxCdmnTBn2YtSu2hTQUW2w1SM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v4 10/20] xen/sysctl: wrap around XEN_SYSCTL_lockprof_op
Date: Wed, 28 May 2025 17:16:58 +0800
Message-ID: <20250528091708.390767-11-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F41:EE_|SA1PR12MB6845:EE_
X-MS-Office365-Filtering-Correlation-Id: 50c9b3e5-0fb3-43e3-5069-08dd9dc88ec7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?AvVEUYrLCpXVU7eof8HpKhyFoej6DzYJTNnic3tefaw4wQNUESW5yq/89hQR?=
 =?us-ascii?Q?2EkXxElq7H0PMeTXmWkpkG7qLTSSQEJscjdiVL5KPgyu87r0Hg/xD+V0dw5/?=
 =?us-ascii?Q?o7ITDifYwRD/5VB0Hr4QYytwmdZ7KUARg+Dnwj9FuvHSqpsROPshUf/AlqrL?=
 =?us-ascii?Q?bTaCye0DWsU1VE5a5GtEAxSQxTSdr0jiTmY7ZCFUILHaL2x3vW8pAbPYXXPk?=
 =?us-ascii?Q?wqooN4o271utJGQO8S8xMlt5vCwuYaCvASmXBA1djVTDgyk8th32OZpG8Gb+?=
 =?us-ascii?Q?e/0PAaAr3TlAzP0g0JpsR1fDuQru04xRunlyQHzgwodfwGX4EvQhjit8dZum?=
 =?us-ascii?Q?fRXLpxSzucEaaqLfb2zZkYporDNwDCkolWp4moulX6NAh4FyIbhgJpWe8How?=
 =?us-ascii?Q?HJCgCILwhiUBndEBE+RRzoqTxg/ajS9OjTwr41ci834BpIk6GGa6peiFxwep?=
 =?us-ascii?Q?3WAd5eoapwksU/sIuuUnnGITJlY+QppcuW+6SFKA8yWiagShlalrdX6L522P?=
 =?us-ascii?Q?QGoORhohIpEsaQP6/LN4r9CDzFwiqGO7rWmJs34cY3h294yeHFVxfqud0ycn?=
 =?us-ascii?Q?tjZ67XjRMR0ajxu80ZXPPMMdBkTLUcX+PCrJBEjNlle6YnHe6+uJw7wdU7EH?=
 =?us-ascii?Q?3otbcMsLMnZpcsPBr3T+q+XGbzBPcIAE76O3ji7aI2PMQL7vYA29k76dio/u?=
 =?us-ascii?Q?f3EfWgGmBjggqFCDZnyhnQ+yYwTLdecgXW2vX04MiHuXFZNoCMj8rAtFHr+T?=
 =?us-ascii?Q?YF+4Q9vQ7nF58VQdsYsJ7aCImSc/QZGctppcjCQf6nVX0eix1JiEKeBxP2ln?=
 =?us-ascii?Q?ruBbi6dgoWAgPe9bW3rWgZQ4APxcoqTu01+XpvHcjX7TkR7KCwHUcBjMsl7i?=
 =?us-ascii?Q?IVk+0knZVyiTd0SgFm7LhS3eSDrfjgHY+kL+t+GSB/eeF1BW6pCtm6Dx+632?=
 =?us-ascii?Q?Z3lJepqiYJOkJxriqjhYv6Ds0XV4Bwl8mXPyoS1ve7AYgpHgKD6mxxLpOCLG?=
 =?us-ascii?Q?Yik5bK7dmlOuBBJpkG08GKxNoahy39LbspZQGeJLNmpdGu9X+IX4hy44zFfG?=
 =?us-ascii?Q?JlrcKuL35QDmvUPb0K81NtsRjQb1EO2vqaKDAXMt88pSaYaK2UvwPcDU9xc2?=
 =?us-ascii?Q?MrxCLs1JWt5iVTf3pf+kbq0BQDO/z89h/rEaWMGdSdYulSWTq/QCUMGTKDQT?=
 =?us-ascii?Q?us60T0/O1gzfR+KCQ0IaOQaU08p49TWZHN9TQ1T1mQlIx3oWB1qR49ubCRcY?=
 =?us-ascii?Q?deq4QbM+AThTTuY09u3gNG0mayrhsJKPhuSzWU67FVD+4gF+viQMUdBVau4K?=
 =?us-ascii?Q?Q+WEo82q7VGzUCaeJ0hOjk3opIDQ7yl7JuAtcGFbEr6VXxYmmqg79wDGDhf1?=
 =?us-ascii?Q?Su+VNwSzn2EXEF/0iF8lWjlvb6GEf2N0ciArxhC5Dc01ASN7E51UsKOaR4B+?=
 =?us-ascii?Q?vxduGW9mUN6HLk9erkRhlHMIru3GpSqNm5bEHbbPA7CSCXBzSmXhv+xvWYp5?=
 =?us-ascii?Q?reee1ELt1Vy/TwpOkDtTKeXxbe43aVrH8lae?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:07.0280
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 50c9b3e5-0fb3-43e3-5069-08dd9dc88ec7
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F41.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6845

The following function is only to serve spinlock profiling via
XEN_SYSCTL_lockprof_op, so it shall be wrapped:
- spinlock_profile_control()

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v2 -> v3:
- add the blank line
---
v3 -> v4:
- removw transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/spinlock.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 38caa10a2e..0389293b09 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -690,6 +690,7 @@ void cf_check spinlock_profile_reset(unsigned char key)
     spinlock_profile_iterate(spinlock_profile_reset_elem, NULL);
 }
 
+#ifdef CONFIG_SYSCTL
 typedef struct {
     struct xen_sysctl_lockprof_op *pc;
     int                      rc;
@@ -749,6 +750,7 @@ int spinlock_profile_control(struct xen_sysctl_lockprof_op *pc)
 
     return rc;
 }
+#endif /* CONFIG_SYSCTL */
 
 void _lock_profile_register_struct(
     int32_t type, struct lock_profile_qhead *qhead, int32_t idx)
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:21:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:21:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999182.1379936 (Exim 4.92)
	(envelope-from )
	id 1uKCyd-0002xa-4Y; Wed, 28 May 2025 09:21:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999182.1379936; Wed, 28 May 2025 09: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 1uKCyd-0002xT-0W; Wed, 28 May 2025 09:21:35 +0000
Received: by outflank-mailman (input) for mailman id 999182;
 Wed, 28 May 2025 09:21:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvX-0000yL-BD
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:23 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2414::62d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id afb24bc7-3ba4-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:18:16 +0200 (CEST)
Received: from MW4PR04CA0073.namprd04.prod.outlook.com (2603:10b6:303:6b::18)
 by DS4PR12MB9611.namprd12.prod.outlook.com (2603:10b6:8:277::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Wed, 28 May
 2025 09:18:10 +0000
Received: from SN1PEPF00036F3F.namprd05.prod.outlook.com
 (2603:10b6:303:6b:cafe::79) by MW4PR04CA0073.outlook.office365.com
 (2603:10b6:303:6b::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Wed,
 28 May 2025 09:18:10 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F3F.mail.protection.outlook.com (10.167.248.23) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:09 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:18: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" 
X-Inumbo-ID: afb24bc7-3ba4-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ROPC4IOnguJsLeDd5VT2sFrGa7reUTPiYywNR0hdRDi7jJ8phzmEyXxY4hriKEm3Ofh5o1ow+kSiigv+r1dZxhvCZUu2ZFkus8otGl/PmSMOm4ZaW0YLBymRJ4O8+6Au31HaXM4xzZJ0ph9aiA5eocjMgyWG8Ucay31z/3X2hL/RqIUr1dJQkcvhO8B8wVzHtfMrj/uoiAiS4UsuPUOdxceWHBEkm1R2L/D8o6TofNGGbPJ0u2pvPesW6Ss/XcybuWw9f8JyRnDxiDe95PokUPcq4hjM1ni/4juurbMNaHQW2Qd5zH80XgYAej6GxTUItYrkI9ZJM+mosJUAoQN7dw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wH1LeeUj74zVDul7zCADDjPOAKRJmw7rKR7R0MHgDlg=;
 b=JqTLogGPNwqD+U7jcRKMRZlD0PMWVoGsSQLFJ4UEDkYAYcrnLnVguh8hyByYOyT/zuW7QTgJpK6kp1ns/82IOP69VOuHY3uELb+KIIVtqBf57LzfLGYzMFPeJDtSvAaXu/tjXxSJ2HJqNFliJ4V23ccxnjInVZ4fVx6+t1YLJ6NN+9uQSzYOni63aoXfu7jHi3NNa1drl91lWLnXSRV0aXC1negc9wOIvAQ2CSedOuBiIncFtKslFx55QnHZJmPhKJhTwAQBPM0b0Rbi3IVGi6cjVZBM2mvMwU5dVdPbYe8GuQeIZdCpG14SXaocHY8AfBuQLSSJrXiagDwjv8Tmyw==
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=wH1LeeUj74zVDul7zCADDjPOAKRJmw7rKR7R0MHgDlg=;
 b=piguZJfRVjPSr5kZ5SQIqiWqZ2v9V9x32B+jTZ6TLbCnhmxmPthtM32iEiZsHOMPQEyNcUkThTDLp6DOHuA9Lck0vW2iRGKXKz9/t7jAi0saBT7oEn1nlIcLAY/1Yz5NHhY8a5/KEB1iwQpLhNqbr9mJQHIT02wtzxHtTnEvWeQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini 
Subject: [PATCH v4 11/20] xen/pmstat: introduce CONFIG_PM_OP
Date: Wed, 28 May 2025 17:16:59 +0800
Message-ID: <20250528091708.390767-12-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F3F:EE_|DS4PR12MB9611:EE_
X-MS-Office365-Filtering-Correlation-Id: 28468554-2eb2-45a1-0f40-08dd9dc89089
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?djhzpybgUPM9devfRrxxtXo+aUwb+Z5rGPRPj9p5tSNwOjMThgxakT56VFZ8?=
 =?us-ascii?Q?PnPZemYJfGLKBYBaKH98xmi114xx6ushN5AJsT9hsU5leD/MLKP7jpdNbRXC?=
 =?us-ascii?Q?QTREKeXXMa4SVd39zRaG6GEWAZQ6gZMBiBleoQe9kycglftuiYeRlLsTd5UF?=
 =?us-ascii?Q?3/5EmVBJwLhp+YQ9cBzD1m6z53VEx0FGz198THgK5ZwHqmcUEu6/EJdg49so?=
 =?us-ascii?Q?8AAu73moNrq3fw16BYBRNo28Tn3mSf/FLEvRzNTCWIyRNL154aSLCSJ06b5y?=
 =?us-ascii?Q?+7BQ8eTHdzQIpVrNm5M6zbPa+DJhrn6Aj1zR3AcbhXb8cSpyYFzOtomBLfi6?=
 =?us-ascii?Q?8+jS/NyJo5GcdxuInoRKMRelBklvwe7bmCviXpFGdFssJoEq97y7GVJhMiS0?=
 =?us-ascii?Q?crwLGjfcLsfSwCcvWxYfgt1MQF+XrhH9SBSxUqa6QtW+TEO5GBb5qxVKXLB9?=
 =?us-ascii?Q?TTZeR9DPldqcLewomicIjsbgvBuG7kRumbdHTLEKjN67YH8oZTJXDaO20h6z?=
 =?us-ascii?Q?dnwvx/czyhnYzqIeHmEz9O4SgmfwM5KL+HfHe9FH8Bni5+pINfbXC69nJ5MT?=
 =?us-ascii?Q?96byStK34L1m0d2jVhwTFcGxy2HTMegJ6sbtWE7vQUwCUSYhUGpxx0kMsHXS?=
 =?us-ascii?Q?TfBLtHncU4VVkJdL3Sa9I60geA496PW6aovSlIYnz1TKEifvPvS+QLXmIQCs?=
 =?us-ascii?Q?UiVsGzWoDg6lANuHh+1Q4M9+rZvxfe3XrSJJwFAp+tRMDmEvpK/ll4/2UmV2?=
 =?us-ascii?Q?IXsiY/yIOlx+QK5xXgwGpgX2B6Iae5O2yG9gUNW5AHiG4hwZ3XPmrb5a9gXZ?=
 =?us-ascii?Q?fhRhdbSF7sdzP+8T+ccN+Ze9pV75F5VpoAIsX+HN/pCxIMtko66BKthmNefY?=
 =?us-ascii?Q?NVpCuZJRwRQDw27qnyLfU6Qky4avkw65WmusZsoJyP4+ykXhVof5xpEg8iso?=
 =?us-ascii?Q?mazPMnwbUbkPkB974zmG2B6JUOcKm4HtHvziebqWk2MRio0eb6HDLq2UBH8n?=
 =?us-ascii?Q?Yto4QxBR3S6pP91Jl1b2u6E90u47l0+pcpHzny+5BstUjZKhr7XNv0eotrSF?=
 =?us-ascii?Q?42II9bRCDmA8O0NpgOPbxE7Zfl73BLKw8X6h2bMNiaW+hl55836Jus/BHhJ3?=
 =?us-ascii?Q?drsavQBTTt9Gts/hBiy3yeD82vMAShUhK2nMNkc2K7h4VPT7dsSPgFc5mdjQ?=
 =?us-ascii?Q?elAhnObpTR4Fh5iqpX3+qJdiHsuSB/ZWJYAG/AR3XF2AZ8QUpxnWMfZwPjJQ?=
 =?us-ascii?Q?xJeGZdYWF6aEDJqimsXFr97mCx0hP8ubtTZ97rPypMdDaXH84wOeohyhGIGN?=
 =?us-ascii?Q?E8CGUQQOf7vlF/sQjb/myLgPqEWkKRYIZ0BFzsWTT84AhHsBNeGRmIAGSjd5?=
 =?us-ascii?Q?tn8Vqg7T3ctp89jpCmtLKpcm61ZWTuYOr6lbo9dGF7yLPy71iHGVhJs7WqN1?=
 =?us-ascii?Q?ihs8MQhWkBPhpB6mAicQg10Db9WLHt8ch9p3n2agu3xWcRyiyMlrod4FHUr2?=
 =?us-ascii?Q?Hlny5UnbpX2aUjAPb3CeVNHbPdYmLdupBaJ/?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:09.9755
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 28468554-2eb2-45a1-0f40-08dd9dc89089
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F3F.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB9611

We move the following functions into a new file drivers/acpi/pm-op.c, as
they are all more fitting in performance controling and only called by
do_pm_op():
 - get_cpufreq_para()
 - set_cpufreq_para()
 - set_cpufreq_gov()
 - set_cpufreq_cppc()
 - cpufreq_driver_getavg()
 - cpufreq_update_turbo()
 - cpufreq_get_turbo_status()
We introduce a new Kconfig CONFIG_PM_OP to wrap the new file.

Also, although the following helpers are only called by do_pm_op(), they have
dependency on local variable, we wrap them with CONFIG_PM_OP in place:
 - write_userspace_scaling_setspeed()
 - write_ondemand_sampling_rate()
 - write_ondemand_up_threshold()
 - get_cpufreq_ondemand_para()
 - cpufreq_driver.update()
 - get_hwp_para()
Various style corrections shall be applied at the same time while moving these
functions, including:
 - add extra space before and after bracket of if() and switch()
 - fix indentation
 - drop all the unnecessary inner figure braces

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
v2 -> v3
- new commit
---
v3 -> v4:
- rename the file to pm-op.c
- drop all the unnecessary inner figure braces
- be consistent with the comment on the #endif
---
 xen/arch/x86/acpi/cpufreq/hwp.c              |   6 +
 xen/arch/x86/acpi/cpufreq/powernow.c         |   4 +
 xen/common/Kconfig                           |   7 +
 xen/common/sysctl.c                          |   2 +
 xen/drivers/acpi/Makefile                    |   1 +
 xen/drivers/acpi/pm-op.c                     | 397 +++++++++++++++++++
 xen/drivers/acpi/pmstat.c                    | 357 -----------------
 xen/drivers/cpufreq/cpufreq_misc_governors.c |   2 +
 xen/drivers/cpufreq/cpufreq_ondemand.c       |   2 +
 xen/drivers/cpufreq/utility.c                |  41 --
 xen/include/acpi/cpufreq/cpufreq.h           |   3 -
 11 files changed, 421 insertions(+), 401 deletions(-)
 create mode 100644 xen/drivers/acpi/pm-op.c

diff --git a/xen/arch/x86/acpi/cpufreq/hwp.c b/xen/arch/x86/acpi/cpufreq/hwp.c
index d5fa3d47ca..e4c09244ab 100644
--- a/xen/arch/x86/acpi/cpufreq/hwp.c
+++ b/xen/arch/x86/acpi/cpufreq/hwp.c
@@ -466,6 +466,7 @@ static int cf_check hwp_cpufreq_cpu_exit(struct cpufreq_policy *policy)
     return 0;
 }
 
+#ifdef CONFIG_PM_OP
 /*
  * The SDM reads like turbo should be disabled with MSR_IA32_PERF_CTL and
  * PERF_CTL_TURBO_DISENGAGE, but that does not seem to actually work, at least
@@ -508,6 +509,7 @@ static int cf_check hwp_cpufreq_update(unsigned int cpu, struct cpufreq_policy *
 
     return per_cpu(hwp_drv_data, cpu)->ret;
 }
+#endif /* CONFIG_PM_OP */
 
 static const struct cpufreq_driver __initconst_cf_clobber
 hwp_cpufreq_driver = {
@@ -516,9 +518,12 @@ hwp_cpufreq_driver = {
     .target = hwp_cpufreq_target,
     .init   = hwp_cpufreq_cpu_init,
     .exit   = hwp_cpufreq_cpu_exit,
+#ifdef CONFIG_PM_OP
     .update = hwp_cpufreq_update,
+#endif
 };
 
+#ifdef CONFIG_PM_OP
 int get_hwp_para(unsigned int cpu,
                  struct xen_cppc_para *cppc_para)
 {
@@ -639,6 +644,7 @@ int set_hwp_para(struct cpufreq_policy *policy,
 
     return hwp_cpufreq_target(policy, 0, 0);
 }
+#endif /* CONFIG_PM_OP */
 
 int __init hwp_register_driver(void)
 {
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c b/xen/arch/x86/acpi/cpufreq/powernow.c
index 69364e1855..12fca45b45 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -49,6 +49,7 @@ static void cf_check transition_pstate(void *pstate)
     wrmsrl(MSR_PSTATE_CTRL, *(unsigned int *)pstate);
 }
 
+#ifdef CONFIG_PM_OP
 static void cf_check update_cpb(void *data)
 {
     struct cpufreq_policy *policy = data;
@@ -77,6 +78,7 @@ static int cf_check powernow_cpufreq_update(
 
     return 0;
 }
+#endif /* CONFIG_PM_OP */
 
 static int cf_check powernow_cpufreq_target(
     struct cpufreq_policy *policy,
@@ -324,7 +326,9 @@ powernow_cpufreq_driver = {
     .target = powernow_cpufreq_target,
     .init   = powernow_cpufreq_cpu_init,
     .exit   = powernow_cpufreq_cpu_exit,
+#ifdef CONFIG_PM_OP
     .update = powernow_cpufreq_update
+#endif
 };
 
 unsigned int __init powernow_register_driver(void)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index d84906df24..712c29b1a0 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -591,4 +591,11 @@ config SYSCTL
 	  to reduce Xen footprint.
 endmenu
 
+config PM_OP
+	bool "Enable Performance Management Operation"
+	depends on ACPI && HAS_CPUFREQ && SYSCTL
+	default y
+	help
+	  This option shall enable userspace performance management control
+	  to do power/performance analyzing and tuning.
 endmenu
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index c2d99ae12e..daf57fbe56 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -174,7 +174,9 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
     case XEN_SYSCTL_get_pmstat:
         ret = do_get_pm_info(&op->u.get_pmstat);
         break;
+#endif
 
+#ifdef CONFIG_PM_OP
     case XEN_SYSCTL_pm_op:
         ret = do_pm_op(&op->u.pm_op);
         if ( ret == -EAGAIN )
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index 2fc5230253..1d811a51a7 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -6,6 +6,7 @@ obj-bin-y += tables.init.o
 obj-$(CONFIG_ACPI_NUMA) += numa.o
 obj-y += osl.o
 obj-$(CONFIG_HAS_CPUFREQ) += pmstat.o
+obj-$(CONFIG_PM_OP) += pm-op.o
 
 obj-$(CONFIG_X86) += hwregs.o
 obj-$(CONFIG_X86) += reboot.o
diff --git a/xen/drivers/acpi/pm-op.c b/xen/drivers/acpi/pm-op.c
new file mode 100644
index 0000000000..b6c590967e
--- /dev/null
+++ b/xen/drivers/acpi/pm-op.c
@@ -0,0 +1,397 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/*
+ * 1. Get PM parameter
+ * 2. Provide user PM control
+ */
+static int cpufreq_update_turbo(unsigned int cpu, int new_state)
+{
+    struct cpufreq_policy *policy;
+    int curr_state;
+    int ret = 0;
+
+    if ( new_state != CPUFREQ_TURBO_ENABLED &&
+         new_state != CPUFREQ_TURBO_DISABLED )
+        return -EINVAL;
+
+    policy = per_cpu(cpufreq_cpu_policy, cpu);
+    if ( !policy )
+        return -EACCES;
+
+    if ( policy->turbo == CPUFREQ_TURBO_UNSUPPORTED )
+        return -EOPNOTSUPP;
+
+    curr_state = policy->turbo;
+    if ( curr_state == new_state )
+        return 0;
+
+    policy->turbo = new_state;
+    if ( cpufreq_driver.update )
+    {
+        ret = alternative_call(cpufreq_driver.update, cpu, policy);
+        if ( ret )
+            policy->turbo = curr_state;
+    }
+
+    return ret;
+}
+
+static int cpufreq_get_turbo_status(unsigned int cpu)
+{
+    struct cpufreq_policy *policy;
+
+    policy = per_cpu(cpufreq_cpu_policy, cpu);
+    return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
+}
+
+static int read_scaling_available_governors(char *scaling_available_governors,
+                                            unsigned int size)
+{
+    unsigned int i = 0;
+    struct cpufreq_governor *t;
+
+    if ( !scaling_available_governors )
+        return -EINVAL;
+
+    list_for_each_entry(t, &cpufreq_governor_list, governor_list)
+    {
+        i += scnprintf(&scaling_available_governors[i],
+                       CPUFREQ_NAME_LEN, "%s ", t->name);
+        if ( i > size )
+            return -EINVAL;
+    }
+    scaling_available_governors[i-1] = '\0';
+
+    return 0;
+}
+
+static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
+{
+    uint32_t ret = 0;
+    const struct processor_pminfo *pmpt;
+    struct cpufreq_policy *policy;
+    uint32_t gov_num = 0;
+    uint32_t *data;
+    char     *scaling_available_governors;
+    struct list_head *pos;
+    unsigned int cpu, i = 0;
+
+    pmpt = processor_pminfo[op->cpuid];
+    policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
+
+    if ( !pmpt || !pmpt->perf.states ||
+         !policy || !policy->governor )
+        return -EINVAL;
+
+    list_for_each(pos, &cpufreq_governor_list)
+        gov_num++;
+
+    if ( (op->u.get_para.cpu_num  != cpumask_weight(policy->cpus)) ||
+         (op->u.get_para.freq_num != pmpt->perf.state_count)    ||
+         (op->u.get_para.gov_num  != gov_num) )
+    {
+        op->u.get_para.cpu_num =  cpumask_weight(policy->cpus);
+        op->u.get_para.freq_num = pmpt->perf.state_count;
+        op->u.get_para.gov_num  = gov_num;
+        return -EAGAIN;
+    }
+
+    if ( !(data = xzalloc_array(uint32_t,
+                                max(op->u.get_para.cpu_num,
+                                    op->u.get_para.freq_num))) )
+        return -ENOMEM;
+
+    for_each_cpu(cpu, policy->cpus)
+        data[i++] = cpu;
+    ret = copy_to_guest(op->u.get_para.affected_cpus,
+                        data, op->u.get_para.cpu_num);
+
+    for ( i = 0; i < op->u.get_para.freq_num; i++ )
+        data[i] = pmpt->perf.states[i].core_frequency * 1000;
+    ret += copy_to_guest(op->u.get_para.scaling_available_frequencies,
+                         data, op->u.get_para.freq_num);
+
+    xfree(data);
+    if ( ret )
+        return -EFAULT;
+
+    op->u.get_para.cpuinfo_cur_freq =
+        cpufreq_driver.get ? alternative_call(cpufreq_driver.get, op->cpuid)
+                           : policy->cur;
+    op->u.get_para.cpuinfo_max_freq = policy->cpuinfo.max_freq;
+    op->u.get_para.cpuinfo_min_freq = policy->cpuinfo.min_freq;
+    op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid);
+
+    if ( cpufreq_driver.name[0] )
+        strlcpy(op->u.get_para.scaling_driver,
+                cpufreq_driver.name, CPUFREQ_NAME_LEN);
+    else
+        strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
+
+    if ( IS_ENABLED(CONFIG_INTEL) &&
+         !strncmp(op->u.get_para.scaling_driver, XEN_HWP_DRIVER_NAME,
+                  CPUFREQ_NAME_LEN) )
+        ret = get_hwp_para(policy->cpu, &op->u.get_para.u.cppc_para);
+    else
+    {
+        if ( !(scaling_available_governors =
+               xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) )
+            return -ENOMEM;
+        if ( (ret = read_scaling_available_governors(
+                        scaling_available_governors,
+                        (gov_num * CPUFREQ_NAME_LEN *
+                         sizeof(*scaling_available_governors)))) )
+        {
+            xfree(scaling_available_governors);
+            return ret;
+        }
+        ret = copy_to_guest(op->u.get_para.scaling_available_governors,
+                            scaling_available_governors,
+                            gov_num * CPUFREQ_NAME_LEN);
+        xfree(scaling_available_governors);
+        if ( ret )
+            return -EFAULT;
+
+        op->u.get_para.u.s.scaling_cur_freq = policy->cur;
+        op->u.get_para.u.s.scaling_max_freq = policy->max;
+        op->u.get_para.u.s.scaling_min_freq = policy->min;
+
+        if ( policy->governor->name[0] )
+            strlcpy(op->u.get_para.u.s.scaling_governor,
+                    policy->governor->name, CPUFREQ_NAME_LEN);
+        else
+            strlcpy(op->u.get_para.u.s.scaling_governor, "Unknown",
+                    CPUFREQ_NAME_LEN);
+
+        /* governor specific para */
+        if ( !strncasecmp(op->u.get_para.u.s.scaling_governor,
+                          "userspace", CPUFREQ_NAME_LEN) )
+            op->u.get_para.u.s.u.userspace.scaling_setspeed = policy->cur;
+
+        if ( !strncasecmp(op->u.get_para.u.s.scaling_governor,
+                          "ondemand", CPUFREQ_NAME_LEN) )
+            ret = get_cpufreq_ondemand_para(
+                &op->u.get_para.u.s.u.ondemand.sampling_rate_max,
+                &op->u.get_para.u.s.u.ondemand.sampling_rate_min,
+                &op->u.get_para.u.s.u.ondemand.sampling_rate,
+                &op->u.get_para.u.s.u.ondemand.up_threshold);
+    }
+
+    return ret;
+}
+
+static int set_cpufreq_gov(struct xen_sysctl_pm_op *op)
+{
+    struct cpufreq_policy new_policy, *old_policy;
+
+    old_policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
+    if ( !old_policy )
+        return -EINVAL;
+
+    memcpy(&new_policy, old_policy, sizeof(struct cpufreq_policy));
+
+    new_policy.governor = __find_governor(op->u.set_gov.scaling_governor);
+    if ( new_policy.governor == NULL )
+        return -EINVAL;
+
+    return __cpufreq_set_policy(old_policy, &new_policy);
+}
+
+static int set_cpufreq_para(struct xen_sysctl_pm_op *op)
+{
+    int ret = 0;
+    struct cpufreq_policy *policy;
+
+    policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
+
+    if ( !policy || !policy->governor )
+        return -EINVAL;
+
+    if ( hwp_active() )
+        return -EOPNOTSUPP;
+
+    switch( op->u.set_para.ctrl_type )
+    {
+    case SCALING_MAX_FREQ:
+    {
+        struct cpufreq_policy new_policy;
+
+        memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
+        new_policy.max = op->u.set_para.ctrl_value;
+        ret = __cpufreq_set_policy(policy, &new_policy);
+
+        break;
+    }
+
+    case SCALING_MIN_FREQ:
+    {
+        struct cpufreq_policy new_policy;
+
+        memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
+        new_policy.min = op->u.set_para.ctrl_value;
+        ret = __cpufreq_set_policy(policy, &new_policy);
+
+        break;
+    }
+
+    case SCALING_SETSPEED:
+    {
+        unsigned int freq =op->u.set_para.ctrl_value;
+
+        if ( !strncasecmp(policy->governor->name,
+                          "userspace", CPUFREQ_NAME_LEN) )
+            ret = write_userspace_scaling_setspeed(op->cpuid, freq);
+        else
+            ret = -EINVAL;
+
+        break;
+    }
+
+    case SAMPLING_RATE:
+    {
+        unsigned int sampling_rate = op->u.set_para.ctrl_value;
+
+        if ( !strncasecmp(policy->governor->name,
+                          "ondemand", CPUFREQ_NAME_LEN) )
+            ret = write_ondemand_sampling_rate(sampling_rate);
+        else
+            ret = -EINVAL;
+
+        break;
+    }
+
+    case UP_THRESHOLD:
+    {
+        unsigned int up_threshold = op->u.set_para.ctrl_value;
+
+        if ( !strncasecmp(policy->governor->name,
+                          "ondemand", CPUFREQ_NAME_LEN) )
+            ret = write_ondemand_up_threshold(up_threshold);
+        else
+            ret = -EINVAL;
+
+        break;
+    }
+
+    default:
+        ret = -EINVAL;
+        break;
+    }
+
+    return ret;
+}
+
+static int set_cpufreq_cppc(struct xen_sysctl_pm_op *op)
+{
+    struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
+
+    if ( !policy || !policy->governor )
+        return -ENOENT;
+
+    if ( !hwp_active() )
+        return -EOPNOTSUPP;
+
+    return set_hwp_para(policy, &op->u.set_cppc);
+}
+
+int do_pm_op(struct xen_sysctl_pm_op *op)
+{
+    int ret = 0;
+    const struct processor_pminfo *pmpt;
+
+    switch ( op->cmd )
+    {
+    case XEN_SYSCTL_pm_op_set_sched_opt_smt:
+    {
+        uint32_t saved_value = sched_smt_power_savings;
+
+        if ( op->cpuid != 0 )
+            return -EINVAL;
+        sched_smt_power_savings = !!op->u.set_sched_opt_smt;
+        op->u.set_sched_opt_smt = saved_value;
+        return 0;
+    }
+
+    case XEN_SYSCTL_pm_op_get_max_cstate:
+        BUILD_BUG_ON(XEN_SYSCTL_CX_UNLIMITED != UINT_MAX);
+        if ( op->cpuid == 0 )
+            op->u.get_max_cstate = acpi_get_cstate_limit();
+        else if ( op->cpuid == 1 )
+            op->u.get_max_cstate = acpi_get_csubstate_limit();
+        else
+            ret = -EINVAL;
+        return ret;
+
+    case XEN_SYSCTL_pm_op_set_max_cstate:
+        if ( op->cpuid == 0 )
+            acpi_set_cstate_limit(op->u.set_max_cstate);
+        else if ( op->cpuid == 1 )
+            acpi_set_csubstate_limit(op->u.set_max_cstate);
+        else
+            ret = -EINVAL;
+        return ret;
+    }
+
+    if ( op->cpuid >= nr_cpu_ids || !cpu_online(op->cpuid) )
+        return -EINVAL;
+    pmpt = processor_pminfo[op->cpuid];
+
+    switch ( op->cmd & PM_PARA_CATEGORY_MASK )
+    {
+    case CPUFREQ_PARA:
+        if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
+            return -ENODEV;
+        if ( !pmpt || !(pmpt->perf.init & XEN_PX_INIT) )
+            return -EINVAL;
+        break;
+    }
+
+    switch ( op->cmd )
+    {
+    case GET_CPUFREQ_PARA:
+        ret = get_cpufreq_para(op);
+        break;
+
+    case SET_CPUFREQ_GOV:
+        ret = set_cpufreq_gov(op);
+        break;
+
+    case SET_CPUFREQ_PARA:
+        ret = set_cpufreq_para(op);
+        break;
+
+    case SET_CPUFREQ_CPPC:
+        ret = set_cpufreq_cppc(op);
+        break;
+
+    case GET_CPUFREQ_AVGFREQ:
+        op->u.get_avgfreq = cpufreq_driver_getavg(op->cpuid, USR_GETAVG);
+        break;
+
+    case XEN_SYSCTL_pm_op_enable_turbo:
+        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
+        break;
+
+    case XEN_SYSCTL_pm_op_disable_turbo:
+        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
+        break;
+
+    default:
+        printk("not defined sub-hypercall @ do_pm_op\n");
+        ret = -ENOSYS;
+        break;
+    }
+
+    return ret;
+}
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index abfdc45cc2..61b60e59a2 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -330,360 +330,3 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
 
     return ret;
 }
-
-/*
- * 1. Get PM parameter
- * 2. Provide user PM control
- */
-static int read_scaling_available_governors(char *scaling_available_governors,
-                                            unsigned int size)
-{
-    unsigned int i = 0;
-    struct cpufreq_governor *t;
-
-    if ( !scaling_available_governors )
-        return -EINVAL;
-
-    list_for_each_entry(t, &cpufreq_governor_list, governor_list)
-    {
-        i += scnprintf(&scaling_available_governors[i],
-                       CPUFREQ_NAME_LEN, "%s ", t->name);
-        if ( i > size )
-            return -EINVAL;
-    }
-    scaling_available_governors[i-1] = '\0';
-
-    return 0;
-}
-
-static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
-{
-    uint32_t ret = 0;
-    const struct processor_pminfo *pmpt;
-    struct cpufreq_policy *policy;
-    uint32_t gov_num = 0;
-    uint32_t *data;
-    char     *scaling_available_governors;
-    struct list_head *pos;
-    unsigned int cpu, i = 0;
-
-    pmpt = processor_pminfo[op->cpuid];
-    policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
-
-    if ( !pmpt || !pmpt->perf.states ||
-         !policy || !policy->governor )
-        return -EINVAL;
-
-    list_for_each(pos, &cpufreq_governor_list)
-        gov_num++;
-
-    if ( (op->u.get_para.cpu_num  != cpumask_weight(policy->cpus)) ||
-         (op->u.get_para.freq_num != pmpt->perf.state_count)    ||
-         (op->u.get_para.gov_num  != gov_num) )
-    {
-        op->u.get_para.cpu_num =  cpumask_weight(policy->cpus);
-        op->u.get_para.freq_num = pmpt->perf.state_count;
-        op->u.get_para.gov_num  = gov_num;
-        return -EAGAIN;
-    }
-
-    if ( !(data = xzalloc_array(uint32_t,
-                                max(op->u.get_para.cpu_num,
-                                    op->u.get_para.freq_num))) )
-        return -ENOMEM;
-
-    for_each_cpu(cpu, policy->cpus)
-        data[i++] = cpu;
-    ret = copy_to_guest(op->u.get_para.affected_cpus,
-                        data, op->u.get_para.cpu_num);
-
-    for ( i = 0; i < op->u.get_para.freq_num; i++ )
-        data[i] = pmpt->perf.states[i].core_frequency * 1000;
-    ret += copy_to_guest(op->u.get_para.scaling_available_frequencies,
-                         data, op->u.get_para.freq_num);
-
-    xfree(data);
-    if ( ret )
-        return -EFAULT;
-
-    op->u.get_para.cpuinfo_cur_freq =
-        cpufreq_driver.get ? alternative_call(cpufreq_driver.get, op->cpuid)
-                           : policy->cur;
-    op->u.get_para.cpuinfo_max_freq = policy->cpuinfo.max_freq;
-    op->u.get_para.cpuinfo_min_freq = policy->cpuinfo.min_freq;
-    op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid);
-
-    if ( cpufreq_driver.name[0] )
-        strlcpy(op->u.get_para.scaling_driver,
-            cpufreq_driver.name, CPUFREQ_NAME_LEN);
-    else
-        strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
-
-    if ( IS_ENABLED(CONFIG_INTEL) &&
-         !strncmp(op->u.get_para.scaling_driver, XEN_HWP_DRIVER_NAME,
-                  CPUFREQ_NAME_LEN) )
-        ret = get_hwp_para(policy->cpu, &op->u.get_para.u.cppc_para);
-    else
-    {
-        if ( !(scaling_available_governors =
-               xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) )
-            return -ENOMEM;
-        if ( (ret = read_scaling_available_governors(
-                        scaling_available_governors,
-                        (gov_num * CPUFREQ_NAME_LEN *
-                         sizeof(*scaling_available_governors)))) )
-        {
-            xfree(scaling_available_governors);
-            return ret;
-        }
-        ret = copy_to_guest(op->u.get_para.scaling_available_governors,
-                            scaling_available_governors,
-                            gov_num * CPUFREQ_NAME_LEN);
-        xfree(scaling_available_governors);
-        if ( ret )
-            return -EFAULT;
-
-        op->u.get_para.u.s.scaling_cur_freq = policy->cur;
-        op->u.get_para.u.s.scaling_max_freq = policy->max;
-        op->u.get_para.u.s.scaling_min_freq = policy->min;
-
-        if ( policy->governor->name[0] )
-            strlcpy(op->u.get_para.u.s.scaling_governor,
-                policy->governor->name, CPUFREQ_NAME_LEN);
-        else
-            strlcpy(op->u.get_para.u.s.scaling_governor, "Unknown",
-                    CPUFREQ_NAME_LEN);
-
-        /* governor specific para */
-        if ( !strncasecmp(op->u.get_para.u.s.scaling_governor,
-                          "userspace", CPUFREQ_NAME_LEN) )
-            op->u.get_para.u.s.u.userspace.scaling_setspeed = policy->cur;
-
-        if ( !strncasecmp(op->u.get_para.u.s.scaling_governor,
-                          "ondemand", CPUFREQ_NAME_LEN) )
-            ret = get_cpufreq_ondemand_para(
-                &op->u.get_para.u.s.u.ondemand.sampling_rate_max,
-                &op->u.get_para.u.s.u.ondemand.sampling_rate_min,
-                &op->u.get_para.u.s.u.ondemand.sampling_rate,
-                &op->u.get_para.u.s.u.ondemand.up_threshold);
-    }
-
-    return ret;
-}
-
-static int set_cpufreq_gov(struct xen_sysctl_pm_op *op)
-{
-    struct cpufreq_policy new_policy, *old_policy;
-
-    old_policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
-    if ( !old_policy )
-        return -EINVAL;
-
-    memcpy(&new_policy, old_policy, sizeof(struct cpufreq_policy));
-
-    new_policy.governor = __find_governor(op->u.set_gov.scaling_governor);
-    if (new_policy.governor == NULL)
-        return -EINVAL;
-
-    return __cpufreq_set_policy(old_policy, &new_policy);
-}
-
-static int set_cpufreq_para(struct xen_sysctl_pm_op *op)
-{
-    int ret = 0;
-    struct cpufreq_policy *policy;
-
-    policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
-
-    if ( !policy || !policy->governor )
-        return -EINVAL;
-
-    if ( hwp_active() )
-        return -EOPNOTSUPP;
-
-    switch(op->u.set_para.ctrl_type)
-    {
-    case SCALING_MAX_FREQ:
-    {
-        struct cpufreq_policy new_policy;
-
-        memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
-        new_policy.max = op->u.set_para.ctrl_value;
-        ret = __cpufreq_set_policy(policy, &new_policy);
-
-        break;
-    }
-
-    case SCALING_MIN_FREQ:
-    {
-        struct cpufreq_policy new_policy;
-
-        memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
-        new_policy.min = op->u.set_para.ctrl_value;
-        ret = __cpufreq_set_policy(policy, &new_policy);
-
-        break;
-    }
-
-    case SCALING_SETSPEED:
-    {
-        unsigned int freq =op->u.set_para.ctrl_value;
-
-        if ( !strncasecmp(policy->governor->name,
-                          "userspace", CPUFREQ_NAME_LEN) )
-            ret = write_userspace_scaling_setspeed(op->cpuid, freq);
-        else
-            ret = -EINVAL;
-
-        break;
-    }
-
-    case SAMPLING_RATE:
-    {
-        unsigned int sampling_rate = op->u.set_para.ctrl_value;
-
-        if ( !strncasecmp(policy->governor->name,
-                          "ondemand", CPUFREQ_NAME_LEN) )
-            ret = write_ondemand_sampling_rate(sampling_rate);
-        else
-            ret = -EINVAL;
-
-        break;
-    }
-
-    case UP_THRESHOLD:
-    {
-        unsigned int up_threshold = op->u.set_para.ctrl_value;
-
-        if ( !strncasecmp(policy->governor->name,
-                          "ondemand", CPUFREQ_NAME_LEN) )
-            ret = write_ondemand_up_threshold(up_threshold);
-        else
-            ret = -EINVAL;
-
-        break;
-    }
-
-    default:
-        ret = -EINVAL;
-        break;
-    }
-
-    return ret;
-}
-
-static int set_cpufreq_cppc(struct xen_sysctl_pm_op *op)
-{
-    struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_policy, op->cpuid);
-
-    if ( !policy || !policy->governor )
-        return -ENOENT;
-
-    if ( !hwp_active() )
-        return -EOPNOTSUPP;
-
-    return set_hwp_para(policy, &op->u.set_cppc);
-}
-
-int do_pm_op(struct xen_sysctl_pm_op *op)
-{
-    int ret = 0;
-    const struct processor_pminfo *pmpt;
-
-    switch ( op->cmd )
-    {
-    case XEN_SYSCTL_pm_op_set_sched_opt_smt:
-    {
-        uint32_t saved_value = sched_smt_power_savings;
-
-        if ( op->cpuid != 0 )
-            return -EINVAL;
-        sched_smt_power_savings = !!op->u.set_sched_opt_smt;
-        op->u.set_sched_opt_smt = saved_value;
-        return 0;
-    }
-
-    case XEN_SYSCTL_pm_op_get_max_cstate:
-        BUILD_BUG_ON(XEN_SYSCTL_CX_UNLIMITED != UINT_MAX);
-        if ( op->cpuid == 0 )
-            op->u.get_max_cstate = acpi_get_cstate_limit();
-        else if ( op->cpuid == 1 )
-            op->u.get_max_cstate = acpi_get_csubstate_limit();
-        else
-            ret = -EINVAL;
-        return ret;
-
-    case XEN_SYSCTL_pm_op_set_max_cstate:
-        if ( op->cpuid == 0 )
-            acpi_set_cstate_limit(op->u.set_max_cstate);
-        else if ( op->cpuid == 1 )
-            acpi_set_csubstate_limit(op->u.set_max_cstate);
-        else
-            ret = -EINVAL;
-        return ret;
-    }
-
-    if ( op->cpuid >= nr_cpu_ids || !cpu_online(op->cpuid) )
-        return -EINVAL;
-    pmpt = processor_pminfo[op->cpuid];
-
-    switch ( op->cmd & PM_PARA_CATEGORY_MASK )
-    {
-    case CPUFREQ_PARA:
-        if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
-            return -ENODEV;
-        if ( !pmpt || !(pmpt->perf.init & XEN_PX_INIT) )
-            return -EINVAL;
-        break;
-    }
-
-    switch ( op->cmd )
-    {
-    case GET_CPUFREQ_PARA:
-    {
-        ret = get_cpufreq_para(op);
-        break;
-    }
-
-    case SET_CPUFREQ_GOV:
-    {
-        ret = set_cpufreq_gov(op);
-        break;
-    }
-
-    case SET_CPUFREQ_PARA:
-    {
-        ret = set_cpufreq_para(op);
-        break;
-    }
-
-    case SET_CPUFREQ_CPPC:
-        ret = set_cpufreq_cppc(op);
-        break;
-
-    case GET_CPUFREQ_AVGFREQ:
-    {
-        op->u.get_avgfreq = cpufreq_driver_getavg(op->cpuid, USR_GETAVG);
-        break;
-    }
-
-    case XEN_SYSCTL_pm_op_enable_turbo:
-    {
-        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
-        break;
-    }
-
-    case XEN_SYSCTL_pm_op_disable_turbo:
-    {
-        ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
-        break;
-    }
-
-    default:
-        printk("not defined sub-hypercall @ do_pm_op\n");
-        ret = -ENOSYS;
-        break;
-    }
-
-    return ret;
-}
diff --git a/xen/drivers/cpufreq/cpufreq_misc_governors.c b/xen/drivers/cpufreq/cpufreq_misc_governors.c
index 0327fad23b..e5cb9ab02f 100644
--- a/xen/drivers/cpufreq/cpufreq_misc_governors.c
+++ b/xen/drivers/cpufreq/cpufreq_misc_governors.c
@@ -64,6 +64,7 @@ static int cf_check cpufreq_governor_userspace(
     return ret;
 }
 
+#ifdef CONFIG_PM_OP
 int write_userspace_scaling_setspeed(unsigned int cpu, unsigned int freq)
 {
     struct cpufreq_policy *policy;
@@ -80,6 +81,7 @@ int write_userspace_scaling_setspeed(unsigned int cpu, unsigned int freq)
 
     return __cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L);
 }
+#endif /* CONFIG_PM_OP */
 
 static bool __init cf_check
 cpufreq_userspace_handle_option(const char *name, const char *val)
diff --git a/xen/drivers/cpufreq/cpufreq_ondemand.c b/xen/drivers/cpufreq/cpufreq_ondemand.c
index 06cfc88d30..0126a3f5d9 100644
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
@@ -57,6 +57,7 @@ static struct dbs_tuners {
 
 static DEFINE_PER_CPU(struct timer, dbs_timer);
 
+#ifdef CONFIG_PM_OP
 int write_ondemand_sampling_rate(unsigned int sampling_rate)
 {
     if ( (sampling_rate > MAX_SAMPLING_RATE / MICROSECS(1)) ||
@@ -93,6 +94,7 @@ int get_cpufreq_ondemand_para(uint32_t *sampling_rate_max,
 
     return 0;
 }
+#endif /* CONFIG_PM_OP */
 
 static void dbs_check_cpu(struct cpu_dbs_info_s *this_dbs_info)
 {
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index 723045b240..987c3b5929 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -224,47 +224,6 @@ int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag)
     return policy->cur;
 }
 
-int cpufreq_update_turbo(unsigned int cpu, int new_state)
-{
-    struct cpufreq_policy *policy;
-    int curr_state;
-    int ret = 0;
-
-    if (new_state != CPUFREQ_TURBO_ENABLED &&
-        new_state != CPUFREQ_TURBO_DISABLED)
-        return -EINVAL;
-
-    policy = per_cpu(cpufreq_cpu_policy, cpu);
-    if (!policy)
-        return -EACCES;
-
-    if (policy->turbo == CPUFREQ_TURBO_UNSUPPORTED)
-        return -EOPNOTSUPP;
-
-    curr_state = policy->turbo;
-    if (curr_state == new_state)
-        return 0;
-
-    policy->turbo = new_state;
-    if (cpufreq_driver.update)
-    {
-        ret = alternative_call(cpufreq_driver.update, cpu, policy);
-        if (ret)
-            policy->turbo = curr_state;
-    }
-
-    return ret;
-}
-
-
-int cpufreq_get_turbo_status(unsigned int cpu)
-{
-    struct cpufreq_policy *policy;
-
-    policy = per_cpu(cpufreq_cpu_policy, cpu);
-    return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
-}
-
 /*********************************************************************
  *                 POLICY                                            *
  *********************************************************************/
diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h
index 241117a9af..0742aa9f44 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -143,9 +143,6 @@ extern int cpufreq_driver_getavg(unsigned int cpu, unsigned int flag);
 #define CPUFREQ_TURBO_UNSUPPORTED   0
 #define CPUFREQ_TURBO_ENABLED       1
 
-int cpufreq_update_turbo(unsigned int cpu, int new_state);
-int cpufreq_get_turbo_status(unsigned int cpu);
-
 static inline int
 __cpufreq_governor(struct cpufreq_policy *policy, unsigned int event)
 {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:21:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:21:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999193.1379945 (Exim 4.92)
	(envelope-from )
	id 1uKCyl-0003ZU-E7; Wed, 28 May 2025 09:21:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999193.1379945; Wed, 28 May 2025 09:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKCyl-0003Yt-Ax; Wed, 28 May 2025 09:21:43 +0000
Received: by outflank-mailman (input) for mailman id 999193;
 Wed, 28 May 2025 09:21:42 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvg-0000yL-CE
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:32 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2416::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b62d924a-3ba4-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 11:18:28 +0200 (CEST)
Received: from SN6PR04CA0076.namprd04.prod.outlook.com (2603:10b6:805:f2::17)
 by MW6PR12MB8959.namprd12.prod.outlook.com (2603:10b6:303:23c::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Wed, 28 May
 2025 09:18:21 +0000
Received: from SN1PEPF00036F43.namprd05.prod.outlook.com
 (2603:10b6:805:f2:cafe::fe) by SN6PR04CA0076.outlook.office365.com
 (2603:10b6:805:f2::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Wed,
 28 May 2025 09:18:21 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F43.mail.protection.outlook.com (10.167.248.27) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:20 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:18:17 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: b62d924a-3ba4-11f0-a2fe-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=P5et037tC/7RRkvqF5EO4oFP4+xDatJeafXkC0kxlTH2/kNvh+QJJjvPg7jbvsrCUlOKEa0PcdqcerT+Ty69KoVBrhSdu3GTQ8rsFZ4292tWCjZA8+lsoEi7UlqoPYL0ZhLZbJ2AYEMxmiHmIGJXphmLt/IGs5V31ojMjWQZICQISmFGenLlv21YyRTdbVL7aW0kyPz43gAtQFuhy4eZiygaJkYqvUCqWfwtYignOWdX9eIKEG7MD5Sb9zkxisUenNx2XnR6Frv3gH5VUBDQx6wGvRXLLNk2TDJrhJZsyUSfy0aFHt+aJw61C3gzENHovpIAoaesoGPcWzDnZuTpcw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WvykzEStZK73rMFsbUxdbGQm1JqJFz8VY0tKPFQ221s=;
 b=tNWVTjPgU8otA5+X2P4AmAKvWWie5d6r+oQC2JP+DiESyEJHt1UXsAfoRSqz1NxrQHb+QTHx1x51olnMBmf4tKdEas0XHOxcHQcamZNZhiA1gxCB15W9Vngt5oSCq08eIniR+NcBxDfZX/jPce797RgITh2B1q03DcYvWIPKiF1QjOqxWihDHA5KKGrVEeikqVVdZ+uL43LjjvyG46Th1Tw6LpBVeI9W4AKomMUHU7EZSVrLGCMTePRYXKWrBP+B2k0AkqWSmKSik3uZgMn/ZWRHeDdtQLhJAUlb/8ByBGzY0T+xVah1v1lzw/g7vAEkydScNhg0O4DYZ3SKI07CTQ==
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=WvykzEStZK73rMFsbUxdbGQm1JqJFz8VY0tKPFQ221s=;
 b=o1W3UDU1+1YlwdjEt9N/iSKcMwD3Sm2duEYFDUTynXsKpAPiNwqilbdomXoOWwBRHe5vjXAAz8GYLCzue5Uu1JnHRIH1TIyIJG6h0NWDxvp/5hPw7Q/LtDzxixtEOQavY6wu5WXvDGZRIgzOm6xiQV4V5euQXXvgeQInBuq3iFs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: , 
CC: , Penny Zheng , Nathan Studer
	, Stewart Hildebrand , "Dario
 Faggioli" , Juergen Gross , George
 Dunlap , "Daniel P. Smith"
	, Stefano Stabellini 
Subject: [PATCH v4 15/20] xen/sysctl: wrap around XEN_SYSCTL_scheduler_op
Date: Wed, 28 May 2025 17:17:03 +0800
Message-ID: <20250528091708.390767-16-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F43:EE_|MW6PR12MB8959:EE_
X-MS-Office365-Filtering-Correlation-Id: ef92bdba-e0bc-4ef3-72b6-08dd9dc896e3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?KCkgcrT1/Vgo8B+EV7PAS1Gi1fElV+NibqnKK6/C/w9D51fidC+DWiKBL8Ri?=
 =?us-ascii?Q?ZaYrIE3qqyyBgOIrL0xSYJWx515/qcB+0nq4h5K75HcgwbAkdqc1fjcIJN5p?=
 =?us-ascii?Q?e/Az8xJFHhzEokHoZ/s6w8xM70zQ9YIdcb4dkRXC62YZXHkqLKqbBo5f6KLZ?=
 =?us-ascii?Q?tOzmA4MKnXYGjbzEzP9gb/eo9r2JHruXj/aFAe5tYlw0FEpwvbjItf0ukWud?=
 =?us-ascii?Q?YbxL6GfNQQB1BtGMDAKGXltY0lt3k0WVKOMbypGVRtyw57eg25nm6+Kh0o5j?=
 =?us-ascii?Q?FZgjsb2855L0YfNPinPhL3pvC19mZgRavsKGC8jug90vUYC1Dxc5a9k9lZpC?=
 =?us-ascii?Q?92t77YT1+Mg73bR3CCrOg6nYGtz5WlxWSQYorY7Gl7a1cSYtLnxjyvvSkv8K?=
 =?us-ascii?Q?axaw3XdJh0hUgHkh0nqQpThbb3wMdBvFgLTh56bWyFRD14zjuRgGWVfjr/e0?=
 =?us-ascii?Q?0J2sSKpr0NQUrOpnAHEB0z128TsWfM41W60QxoHogcPv5bdVWlJG/xFelheO?=
 =?us-ascii?Q?9f7fbc8B6hPh1eDPArsuOt3Oi62sQ6xNnndLbQTyX0khdoIDh9i0wZtNe0PL?=
 =?us-ascii?Q?G9IvZ3RGjwKSz28r2hgkOqNNZE1ejzekTUXIZQVLcKiimEdaUW12vJ3JseA3?=
 =?us-ascii?Q?f2r7k3VoVYzPaDEmz0BUlUGC6JSgz92DW7CnQqfUm26jigczFiepeHJ6q+LV?=
 =?us-ascii?Q?Y0OMVqwH12WiDaY196gGA1YBT82m/uF5roaSJpak9sOZkzOXA70IAMg9cwtj?=
 =?us-ascii?Q?/rIGEyBuUJEh+tcV5ANyr0MECOKU0SufAJ6BzjBMBwYcccx0GNEk2ljN/nuD?=
 =?us-ascii?Q?cR3xsaLxS+csoivUhjXXHdka+TfVinBNeFwkoTYMhZ21zslSs9Jh1d6rbY02?=
 =?us-ascii?Q?mMEoDxbhS0gTfT9cauXn2XxoifX+TM1OCQf4vIUgXvBegQtu/qylgobg26pC?=
 =?us-ascii?Q?YwhkKpNdz1/Otshau3CMmT0poSA0uYoIm/UaR+pkOu+vYV3l7kkZWPyU6O5t?=
 =?us-ascii?Q?sJ8toPDNs2p0WkvIfCvJrBROjyEj3Ln1nSfsYM29QRnZmKmvMVQXCNfH2yke?=
 =?us-ascii?Q?h3TPfoz3q02KUU/x7n0h0qO9znLfdFdG6TkW+GI76cNPO74Sltj7jzS9rr+F?=
 =?us-ascii?Q?H4u+Xbm1p5yeR2TEAPORPRMUfl52cwK0lYrHOui6nvMgoQ7p1+iqPA+NbyeY?=
 =?us-ascii?Q?P+8clT7YiGdhRYdT5g0nOOkdy7eJ4LJgNxjhEa7w1K/YS2kgvgfN5Rinrpd8?=
 =?us-ascii?Q?jQd4jJonNvyZgL8FszX/wesvUOnfg0DYxOm0UYgbEwXdZjBdCbPVLGhbPyEI?=
 =?us-ascii?Q?NV0+4YMrdNfVwMmF6kflsdB0giOjlIgU3irn2caby4BEtChkyOJOxnJh34s0?=
 =?us-ascii?Q?1RX3cBJ//MuPYApbFD0/JdSLJuS8SVEh3H7bWXkOP2zBqOUz7T++rqo7JG2y?=
 =?us-ascii?Q?RMDyp5DSMaGqD1iv4TLsJBASnCmAI8SOEChnbpJhRRBK4PBrqqWS0CxhPvjd?=
 =?us-ascii?Q?B2Ziz8PikSeNx8X5driIOyrKQ/wsq6T5xwmg?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:20.6324
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ef92bdba-e0bc-4ef3-72b6-08dd9dc896e3
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F43.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8959

Function sched_adjust_global is designed for XEN_SYSCTL_scheduler_op, so
itself and its calling flow, like .adjust_global, shall all be wrapped.

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
Acked-by: Stewart Hildebrand  #a653
---
v1 -> v2:
- no need to wrap declarations
- add transient #ifdef in sysctl.c for correct compilation
---
v2 -> v3:
- move #endif up ahead of the blank line
---
v3 -> v4:
- remove transient "#ifdef CONFIG_SYSCTL"
---
 xen/common/sched/arinc653.c | 6 ++++++
 xen/common/sched/core.c     | 2 ++
 xen/common/sched/credit.c   | 4 ++++
 xen/common/sched/credit2.c  | 4 ++++
 xen/common/sched/private.h  | 4 ++++
 xen/include/xsm/xsm.h       | 4 ++++
 xen/xsm/dummy.c             | 2 ++
 xen/xsm/flask/hooks.c       | 4 ++++
 8 files changed, 30 insertions(+)

diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
index 432ccfe662..3c014c9934 100644
--- a/xen/common/sched/arinc653.c
+++ b/xen/common/sched/arinc653.c
@@ -220,6 +220,7 @@ static void update_schedule_units(const struct scheduler *ops)
                       SCHED_PRIV(ops)->schedule[i].unit_id);
 }
 
+#ifdef CONFIG_SYSCTL
 /**
  * This function is called by the adjust_global scheduler hook to put
  * in place a new ARINC653 schedule.
@@ -334,6 +335,7 @@ arinc653_sched_get(
 
     return 0;
 }
+#endif /* CONFIG_SYSCTL */
 
 /**************************************************************************
  * Scheduler callback functions                                           *
@@ -653,6 +655,7 @@ a653_switch_sched(struct scheduler *new_ops, unsigned int cpu,
     return &sr->_lock;
 }
 
+#ifdef CONFIG_SYSCTL
 /**
  * Xen scheduler callback function to perform a global (not domain-specific)
  * adjustment. It is used by the ARINC 653 scheduler to put in place a new
@@ -692,6 +695,7 @@ a653sched_adjust_global(const struct scheduler *ops,
 
     return rc;
 }
+#endif /* CONFIG_SYSCTL */
 
 /**
  * This structure defines our scheduler for Xen.
@@ -726,7 +730,9 @@ static const struct scheduler sched_arinc653_def = {
     .switch_sched   = a653_switch_sched,
 
     .adjust         = NULL,
+#ifdef CONFIG_SYSCTL
     .adjust_global  = a653sched_adjust_global,
+#endif
 
     .dump_settings  = NULL,
     .dump_cpu_state = NULL,
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 13fdf57e57..ea95dea65a 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2112,6 +2112,7 @@ long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
     return ret;
 }
 
+#ifdef CONFIG_SYSCTL
 long sched_adjust_global(struct xen_sysctl_scheduler_op *op)
 {
     struct cpupool *pool;
@@ -2140,6 +2141,7 @@ long sched_adjust_global(struct xen_sysctl_scheduler_op *op)
 
     return rc;
 }
+#endif /* CONFIG_SYSCTL */
 
 static void vcpu_periodic_timer_work_locked(struct vcpu *v)
 {
diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
index a6bb321e7d..6dcf6b2c8b 100644
--- a/xen/common/sched/credit.c
+++ b/xen/common/sched/credit.c
@@ -1256,6 +1256,7 @@ __csched_set_tslice(struct csched_private *prv, unsigned int timeslice_ms)
     prv->credit = prv->credits_per_tslice * prv->ncpus;
 }
 
+#ifdef CONFIG_SYSCTL
 static int cf_check
 csched_sys_cntl(const struct scheduler *ops,
                         struct xen_sysctl_scheduler_op *sc)
@@ -1298,6 +1299,7 @@ csched_sys_cntl(const struct scheduler *ops,
     out:
     return rc;
 }
+#endif /* CONFIG_SYSCTL */
 
 static void *cf_check
 csched_alloc_domdata(const struct scheduler *ops, struct domain *dom)
@@ -2288,7 +2290,9 @@ static const struct scheduler sched_credit_def = {
 
     .adjust         = csched_dom_cntl,
     .adjust_affinity= csched_aff_cntl,
+#ifdef CONFIG_SYSCTL
     .adjust_global  = csched_sys_cntl,
+#endif
 
     .pick_resource  = csched_res_pick,
     .do_schedule    = csched_schedule,
diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 0a83f23725..0b3b61df57 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -3131,6 +3131,7 @@ csched2_aff_cntl(const struct scheduler *ops, struct sched_unit *unit,
         __clear_bit(__CSFLAG_pinned, &svc->flags);
 }
 
+#ifdef CONFIG_SYSCTL
 static int cf_check csched2_sys_cntl(
     const struct scheduler *ops, struct xen_sysctl_scheduler_op *sc)
 {
@@ -3162,6 +3163,7 @@ static int cf_check csched2_sys_cntl(
 
     return 0;
 }
+#endif /* CONFIG_SYSCTL */
 
 static void *cf_check
 csched2_alloc_domdata(const struct scheduler *ops, struct domain *dom)
@@ -4232,7 +4234,9 @@ static const struct scheduler sched_credit2_def = {
 
     .adjust         = csched2_dom_cntl,
     .adjust_affinity= csched2_aff_cntl,
+#ifdef CONFIG_SYSCTL
     .adjust_global  = csched2_sys_cntl,
+#endif
 
     .pick_resource  = csched2_res_pick,
     .migrate        = csched2_unit_migrate,
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index c0e7c96d24..d6884550cd 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -356,8 +356,10 @@ struct scheduler {
                                     struct sched_unit *unit,
                                     const struct cpumask *hard,
                                     const struct cpumask *soft);
+#ifdef CONFIG_SYSCTL
     int          (*adjust_global)  (const struct scheduler *ops,
                                     struct xen_sysctl_scheduler_op *sc);
+#endif
     void         (*dump_settings)  (const struct scheduler *ops);
     void         (*dump_cpu_state) (const struct scheduler *ops, int cpu);
     void         (*move_timers)    (const struct scheduler *ops,
@@ -510,11 +512,13 @@ static inline int sched_adjust_dom(const struct scheduler *s, struct domain *d,
     return s->adjust ? s->adjust(s, d, op) : 0;
 }
 
+#ifdef CONFIG_SYSCTL
 static inline int sched_adjust_cpupool(const struct scheduler *s,
                                        struct xen_sysctl_scheduler_op *op)
 {
     return s->adjust_global ? s->adjust_global(s, op) : 0;
 }
+#endif
 
 static inline void sched_move_timers(const struct scheduler *s,
                                      struct sched_resource *sr)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 5ac99904c4..6e1789c314 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -57,7 +57,9 @@ struct xsm_ops {
     int (*domain_create)(struct domain *d, uint32_t ssidref);
     int (*getdomaininfo)(struct domain *d);
     int (*domctl_scheduler_op)(struct domain *d, int op);
+#ifdef CONFIG_SYSCTL
     int (*sysctl_scheduler_op)(int op);
+#endif
     int (*set_target)(struct domain *d, struct domain *e);
     int (*domctl)(struct domain *d, unsigned int cmd, uint32_t ssidref);
     int (*sysctl)(int cmd);
@@ -244,10 +246,12 @@ static inline int xsm_domctl_scheduler_op(
     return alternative_call(xsm_ops.domctl_scheduler_op, d, cmd);
 }
 
+#ifdef CONFIG_SYSCTL
 static inline int xsm_sysctl_scheduler_op(xsm_default_t def, int cmd)
 {
     return alternative_call(xsm_ops.sysctl_scheduler_op, cmd);
 }
+#endif
 
 static inline int xsm_set_target(
     xsm_default_t def, struct domain *d, struct domain *e)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index d46413ad8c..8d44f5bfb6 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -19,7 +19,9 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .domain_create                 = xsm_domain_create,
     .getdomaininfo                 = xsm_getdomaininfo,
     .domctl_scheduler_op           = xsm_domctl_scheduler_op,
+#ifdef CONFIG_SYSCTL
     .sysctl_scheduler_op           = xsm_sysctl_scheduler_op,
+#endif
     .set_target                    = xsm_set_target,
     .domctl                        = xsm_domctl,
 #ifdef CONFIG_SYSCTL
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 45c12aa662..a7cb33a718 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -626,6 +626,7 @@ static int cf_check flask_domctl_scheduler_op(struct domain *d, int op)
     }
 }
 
+#ifdef CONFIG_SYSCTL
 static int cf_check flask_sysctl_scheduler_op(int op)
 {
     switch ( op )
@@ -640,6 +641,7 @@ static int cf_check flask_sysctl_scheduler_op(int op)
         return avc_unknown_permission("sysctl_scheduler_op", op);
     }
 }
+#endif /* CONFIG_SYSCTL */
 
 static int cf_check flask_set_target(struct domain *d, struct domain *t)
 {
@@ -1887,7 +1889,9 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .domain_create = flask_domain_create,
     .getdomaininfo = flask_getdomaininfo,
     .domctl_scheduler_op = flask_domctl_scheduler_op,
+#ifdef CONFIG_SYSCTL
     .sysctl_scheduler_op = flask_sysctl_scheduler_op,
+#endif
     .set_target = flask_set_target,
     .domctl = flask_domctl,
 #ifdef CONFIG_SYSCTL
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:21:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:21:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999207.1379956 (Exim 4.92)
	(envelope-from )
	id 1uKCyy-0004Sm-N4; Wed, 28 May 2025 09:21:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999207.1379956; Wed, 28 May 2025 09:21: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 1uKCyy-0004Sb-JY; Wed, 28 May 2025 09:21:56 +0000
Received: by outflank-mailman (input) for mailman id 999207;
 Wed, 28 May 2025 09:21:55 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKCvk-0001jE-Lp
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:18:36 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2062d.outbound.protection.outlook.com
 [2a01:111:f403:2416::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ba54bcb0-3ba4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 11:18:35 +0200 (CEST)
Received: from SN7PR04CA0171.namprd04.prod.outlook.com (2603:10b6:806:125::26)
 by IA0PPF002462CFE.namprd12.prod.outlook.com
 (2603:10b6:20f:fc04::bc4) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.34; Wed, 28 May
 2025 09:18:30 +0000
Received: from SN1PEPF00036F40.namprd05.prod.outlook.com
 (2603:10b6:806:125:cafe::64) by SN7PR04CA0171.outlook.office365.com
 (2603:10b6:806:125::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.24 via Frontend Transport; Wed,
 28 May 2025 09:18:30 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF00036F40.mail.protection.outlook.com (10.167.248.24) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Wed, 28 May 2025 09:18:30 +0000
Received: from penny-System-Product-Name.amd.com (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.39; Wed, 28 May 2025 04:18: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" 
X-Inumbo-ID: ba54bcb0-3ba4-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=AjuELbdaXhMWVxsUtaaXb6HSARbxXtQK5BDHkdG1PybExbzXydwlefr2wYOKfhfVoidz3LEtJBxEEj07MjCEWLEeHwmc/Futy9xknwFnjYuR7xLqvZO+3jNqCtbI178/XrDoC3hn27b9dtJ2mMiMLr/N6GAlUoSj20h5borO2Oy0fI7MXN/0EftSSunNHjClGo1w88xLvzLL6nFw/DPqr4MPdoxQ6SHmOt71tqw84Saz1SPMycNJlGzLhZVuyqg8STVwoy9fF80Vs3lWOds8lVnzjNX507toYMuRY+mCQMKknXwtTHvqecFrokwTnGSNkvjszcW4XVfAVkas7RVn9Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gOftosmSTRdHCsGYzRWYjX+g0KG6mzuEbqn5MK0YPV0=;
 b=vG7J7SnWDYB5Y1g8wLRe0pWwTTb3jTgfjZoonwUcQKK8NCvFvnZU28KTTLB0nw07dZJB2JapfuZpyqwqhWBLKX3ZRRqxG3H6CeHc1rxhd/hdn6W+pWY+rCqWyPdX6mjrkJIz9NCZLphB9GGJYm2Q6d/TbaL9Ciy9Yrphh4qlJfFmXam+WAnxstyCSPaktPIvU8ULPyYsMmdI/XW4RLexwBqPF1uUDQvhR4bxmG/iNpS7j+tJuk4sNVqocgLqpvOZKebUrleBWW/MAYUwvLFEpfDTGct/SQa//qyyvw9+VZvsNx/Jr40SeBlV+VKbG5Ql4pGq114HNya7Qf+zmaCtOg==
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=gOftosmSTRdHCsGYzRWYjX+g0KG6mzuEbqn5MK0YPV0=;
 b=ySbxMAlrwrsP2rURHoE7A3ucJeJkTG/pL1I0WEIWZj+cvlIjrVZtznO+41ITH0gWHR5s7N95WPCzpcNpl9tW1X+bKyFybj8szAzrp79gcOk7Z6175ZOLdVj8av+oN2iopYTspFU5EopyJHQLr7flXm8MHBNknfDIjJCMQt+dDRQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Penny Zheng 
To: 
CC: , Penny Zheng , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini 
Subject: [PATCH v4 18/20] xen/sysctl: make CONFIG_LIVEPATCH depend on CONFIG_SYSCTL
Date: Wed, 28 May 2025 17:17:06 +0800
Message-ID: <20250528091708.390767-19-Penny.Zheng@amd.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528091708.390767-1-Penny.Zheng@amd.com>
References: <20250528091708.390767-1-Penny.Zheng@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F40:EE_|IA0PPF002462CFE:EE_
X-MS-Office365-Filtering-Correlation-Id: b078c20c-e79b-4a94-1842-08dd9dc89c8f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Wpeo6lyzhNUFuzEHr8kFXHf2zVTG9Z7ZasZHdfWLMjE1huzNK0UcrPNqvx6D?=
 =?us-ascii?Q?LbHICavaN1KdluO8gt085nBdSwBBtJ/oKLiYe5pH9cQZ2GymuV+nnWI/5XIS?=
 =?us-ascii?Q?UbxG3cEvV6/dKw0v2ZiHuJhKbIaoKIfRc9HOrx6BsQBpz5EqVPkOt1HL4xLI?=
 =?us-ascii?Q?7y/d4DosvrjhZPDgeu+6HWR9T7EqNGb/3iocm5Ewg//m0MTwH+AuP0YOtbMo?=
 =?us-ascii?Q?vGEyMtXI9LpaVCU/DoZRgl8CArueid4R3XTMdsdVk2BkLthe934i/cKYvi/2?=
 =?us-ascii?Q?Qpd6XSeiv9SpzFL7ha1ov21nV3y+p2Hpr3Oa/31jsQQrQ2Be0eBTDbhbEV1g?=
 =?us-ascii?Q?MW0dXnUUH1MoAH0CP6CaqvoIBsZ6TlULGW3p8kO+63bFSmVNBbQcr79w/QMN?=
 =?us-ascii?Q?IxOot0sr8/OA/GPkjO+N9W+9viDP6Ok8jDyFfIREhrHi9zPz9s3CgH/eswXM?=
 =?us-ascii?Q?m30gNGJN+/xSP4wsziceHt69Shp0QuzWXXYGMM9zSJyA1sLMFOyQYMQ9IpbY?=
 =?us-ascii?Q?mLWb9yDTms3Azn9KwY/S0nKDcVOsyTWYfex8+9JLPkEZmsPFGOKeSzTf28M6?=
 =?us-ascii?Q?mBdOmac6/KUDvNdLrihvWvaTgGINTyUThugK70SsLUaCiquCZIp5xd6iGaXV?=
 =?us-ascii?Q?SB43mIkyHrB1O8dtdbLrkbuW/q+2U8RtZIzPjj6TU/zNipJ9Jh+pBkmv7rH1?=
 =?us-ascii?Q?s8esKLFlHq2R6TRvc5tmg5CnVK9Py7is5JyLcjpHG/DPnuMg0Ld0/2dLKPVP?=
 =?us-ascii?Q?zeY7gp/D/XxAVVrtL8+I8stwX2u4cfwhN3VSda3gne7+MlOH5FbwzM3Aw24/?=
 =?us-ascii?Q?YbzV5mNTgiZoHak9qMBuackOkM+KhSC83YaeoAOHoVdxHktSWqcyb93Szknm?=
 =?us-ascii?Q?S3l99LrSJDiyY0BJKs70vcKRDYoCvHlCpDv/zYvBDqgzCDrC7N9pXy6msVFB?=
 =?us-ascii?Q?8H2O2hLePvMjrk/Kxb7I7rUWtO09+oosPZzLxora3MDck5qM6H0g4bvcWBnx?=
 =?us-ascii?Q?S+7WrWsQNOSNcPcou5vx6gSRRFY+iQY4UHXA03QQLoUqKaMliNoS35HlZNzO?=
 =?us-ascii?Q?s3FA4OK9RHbfgR5ceL2UH5uwoAC/LoR3gB7vfD7i62+Xu7aZuVw5nwNO+ocS?=
 =?us-ascii?Q?DDBLrn3T0GeQovTplNyKwD8lONpm9nZMVzWrTLS+XD37nGp2VRZBDpfI7Mz8?=
 =?us-ascii?Q?DXIw8ossZzKK7NprTWnLAQTKmIcHTJY7dhiTaSJu8hA66Q5wBTDOyhtwc2pT?=
 =?us-ascii?Q?zX0diDLyBKj/sWbpMVyp1kQMjGsC8b0cwK+2W2rrfhVi4pff4XlHVBvd6SpC?=
 =?us-ascii?Q?yQ2HSErdlnhEHQazJBs1ExbdGXdzRuX6I9b85dLe/9hgDWXsWEjNPF+/nwBX?=
 =?us-ascii?Q?dzqhDKsMdPN6lWintESM0l8cuCYvrDU0FaacLd71I/Dnh+MS0BbGHDOZUkLA?=
 =?us-ascii?Q?mePuu/TnWm3ZTHf18gGeL2jEACH3zQ5W7uBWW4DpYMSOj91Cmz1FXlnVEmsS?=
 =?us-ascii?Q?EnsvW6lvLi7wU3/VQUXYtJi6ikLEOlqAHvn6?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2025 09:18:30.1464
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b078c20c-e79b-4a94-1842-08dd9dc89c8f
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F40.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF002462CFE

LIVEPATCH mechanism relies on LIVEPATCH_SYSCTL hypercall, so CONFIG_LIVEPATCH
shall depend on CONFIG_SYSCTL

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v1 -> v2:
- commit message refactor
---
 xen/common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 9bf632973e..e3b6fd6ec4 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -455,7 +455,7 @@ config CRYPTO
 config LIVEPATCH
 	bool "Live patching support"
 	default X86
-	depends on "$(XEN_HAS_BUILD_ID)" = "y"
+	depends on "$(XEN_HAS_BUILD_ID)" = "y" && SYSCTL
 	select CC_SPLIT_SECTIONS
 	help
 	  Allows a running Xen hypervisor to be dynamically patched using
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 09:45:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 09:45:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999292.1379966 (Exim 4.92)
	(envelope-from )
	id 1uKDLg-0002na-A5; Wed, 28 May 2025 09:45:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999292.1379966; Wed, 28 May 2025 09: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 1uKDLg-0002nT-6R; Wed, 28 May 2025 09:45:24 +0000
Received: by outflank-mailman (input) for mailman id 999292;
 Wed, 28 May 2025 09:45:22 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uKDLe-0002nN-Oj
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 09:45:22 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uKDLd-006dLC-2x;
 Wed, 28 May 2025 09:45:21 +0000
Received: from [2a01:e0a:1da:8420:b77:bd5:6e45:7633] (helo=l14)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1uKDLe-000wwE-0G;
 Wed, 28 May 2025 09:45:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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=3XSUshn+9ysuFhv88HRysdEbfKWggC5ZCgqhf2qipe4=; b=dxMst8uyCkARcR48zfhM7hefr4
	kJ90i9e1wZr1V0hCr/O8MXaR9jFcuOl/Va9bgp8u0DSba3tr+++cNWTe3elFgnoFufoQ4E3e9m90/
	bytaKGEKR9yck5d6HkaMmQ+TZOta6Ces0+hFD287bZab/1I4xbfevxLTOFcn0qGwQy48=;
Date: Wed, 28 May 2025 11:45:19 +0200
From: Anthony PERARD 
To: Andrew Cooper 
Cc: Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	Xen-devel ,
	Stefano Stabellini ,
	Michal Orzel 
Subject: Re: [PATCH 2/3] CI: Use bash arrays to simplfy dom0 rootfs
 construction
Message-ID: 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
 <20250522173640.575452-3-andrew.cooper3@citrix.com>
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, May 27, 2025 at 04:24:57PM +0100, Andrew Cooper wrote:
> On 27/05/2025 4:19 pm, Marek Marczykowski-Grecki wrote:
> > On Tue, May 27, 2025 at 04:01:34PM +0200, Anthony PERARD wrote:
> >> On Thu, May 22, 2025 at 06:36:39PM +0100, Andrew Cooper wrote:
> >>> For Qubes, this requires switching from sh to bash.
> >>>
> >>> This reduces the number of times the target filename needs to be written to 1.
> >>>
> >>> Expand the comment to explain the concatination constraints.
> >> Isn't the correct spelling "concatenation"? Same for the two comments.
> >>
> >>> No functional change.
> >>>
> >>> Signed-off-by: Andrew Cooper 
> >>> ---
> >>> I would like to find a slightly nicer way of conditional parts, but nothing
> >>> comes to mind.
> >> Well, one way I can think of is having a new variable which can carry
> >> the rootfs part associated with a particular test, then that variable
> >> can be updated at the time we configure for that test. Something like:
> >>
> >> # init
> >> declare -a append_rootfs_part
> >> # or append_rootfs_part=() is probably fine too.
> >>
> >> case $test in
> >>   argo)
> >>     append_rootfs_part+=(argo.cpio.gz)
> >>     # ... other test configuration
> >>     ;;
> >> esac
> >>
> >> # Dom0 rootfs
> >> parts=(
> >>     rootfs.cpio.gz
> >>     xen-tools.cpio.gz
> >>     "${append_rootfs_part[@]}"
> >> )
> >>
> >> And that should works fine, even if there isn't any extra rootfs part.
> > That would work for compressed parts, but not for uncompressed - which
> > need to come before all compressed. But maybe there could be two arrays
> > - one for uncompressed and another for compressed? Then, each could be
> > extended anywhere, without messing the order.

You could use "${append_rootfs_part:#*.gz}" and
"${(M)append_rootfs_part:#*.gz}" to grab the uncompressed part then the
compressed part... on zsh :-). But something similar could be codded in
bash. But I guess two variables will be more acceptable.

> Hmm, two might work, but they surely need to not be quoted when forming
> parts=(), or having multiple entries will go wrong on the eventual cat
> command line.

The double quote are needed! Well not really because it's very unlikely
that there's going to be blanked characters in paths to parts.

Maybe this will help understand how "${var[@]}" is expended into
multiple arguments:

# Testing with just for loop, also show the difference between
#  "${v[@]}" and "${v[*]}":

$ parts=(one two)
$ for i in "${parts[@]}"; do echo "- $i"; done
- one
- two
$ for i in "${parts[*]}"; do echo "- $i"; done
- one two
$ extra=("first extra" "second extra")
$ for i in "${extra[@]}"; do echo "- $i"; done
- first extra
- second extra
$ parts=(one "${extra[@]}" two)
$ for i in "${parts[@]}"; do echo "- $i"; done
- one
- first extra
- second extra
- two

# And now with function

$ print_array(){ for i in "$@"; do echo "- $i"; done; }
$ print_array "${parts[@]}"
- one
- first extra
- second extra
- two
$ print_array ${parts[@]}
- one
- first
- extra
- second
- extra
- two

Cheers,

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Wed May 28 10:56:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 10:56:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999320.1379996 (Exim 4.92)
	(envelope-from )
	id 1uKERv-0007ui-IW; Wed, 28 May 2025 10:55:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999320.1379996; Wed, 28 May 2025 10:55:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKERv-0007ub-Fm; Wed, 28 May 2025 10:55:55 +0000
Received: by outflank-mailman (input) for mailman id 999320;
 Wed, 28 May 2025 10:55:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKERu-0007uV-Cd
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 10:55:54 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5272bc62-3bb2-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 12:55:52 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad8a6cda6a4so48417666b.0
 for ; Wed, 28 May 2025 03:55:52 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad8a1b5ac15sm86980166b.163.2025.05.28.03.55.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 28 May 2025 03: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" 
X-Inumbo-ID: 5272bc62-3bb2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748429752; x=1749034552; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=Fi9t1orpgh2KSjxX3Nz+ieDaTQtV+mi94T2C3dVSgKc=;
        b=FCctOy7YJLr69JpVNeKXSjI0UxPEotfjBX0PiXtlufCDqdFM+9nolG68pOX94V8S4/
         mO/bEs7ntC3uypmDrpp13VGyD0em571RCIFbdTMMI3gyCEeE/z0H6v2/bWG/cJaDEQgd
         INNPvYcWOkRHFANI6j1kABNdNUrfm2KoH7SN0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748429752; x=1749034552;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Fi9t1orpgh2KSjxX3Nz+ieDaTQtV+mi94T2C3dVSgKc=;
        b=GXzK6oF4lxiaQC4pRS9CRjeL4e9LnwvnwIsUrTj42+6HMqYQFWfbvPDADzqEzetT/u
         wyF4aHSgkSqvSgnO9Z48W5Jl68zv4fHL8eNSQBP7ADV+Q92sYTuJRTQnQYqwK9BqW6X1
         JvzHiHtciTaI0eNpbjov/S1q2hQ6nC9d8v9iG5c9fR/B14PsBvtWI8vqXJ6jFaPFbIb/
         zkRLzcgy2UFa9XoH84BIox2MSNMsAzHv/tTIHwtKhBIpBC2JXxXbT3kqkd8jh6aiZubr
         tp3JpGhpgjFhNw55BTgAFl9x4bQ9/vOmDN9WWFLZWVJK3w/pKO5196wvwD9Kgi8IWp9k
         gJFw==
X-Forwarded-Encrypted: i=1; AJvYcCWK7+pNpYTknHgakd1QsWRBz3uqhivY5bloWAL7iV/rdRgRdZauSibjdCbIPDKheKd+Guul/0837QE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy1azsJYfE7MxXTbXIAHN0BYJAh0OMcsFg/2QKTRq39dzjt7EXH
	vbYPz/hF9HFerMdhDCnWPsA+CiintR37W8WTIcrz4Xho94NGg6QgZyFgIWMDfclSMKg=
X-Gm-Gg: ASbGncv8BvBzmrPmYUOqj/PCIyBRnBAet2AUuiSKcwSe2nEPQUk0nZwo7WaWbE5Sf5+
	g6MYX2dlrDoQjkYMW/fVVkSRjz4mpejzYTFFGnKrnS4BgNHOYJEPPPU0Z2RRar1T1CPRuVrGnTi
	KuF0iqk38YfrR8ytKT0AP4a0qZW8CgOzHE7Rjjj3CLzZxGPsCNtqt1SbYHCinamFzz1M8wbUguy
	8RsPWUw9Bpow35k0h5EfDrSxCvDH2OXY0WhlD/NhOruSc4XkJM1lgXFwOu5yPngqGJz2GIlxWsQ
	4meUELQBiQ2rr7Zty+maVW/F+Vf6i24Woav2TtavnH9XR+FWCavoZtU8FPkhYOXxC1KSJbKurCS
	E3V+FAoWDRz9eBNiv
X-Google-Smtp-Source: AGHT+IHVxFMaM/0qWNyOTRwCfUg3yzD4Yi0+BSa0Gks2boxk7fR8Nj8dOcMduGYSqZhkxY+aTmdj4g==
X-Received: by 2002:a17:906:794c:b0:ad5:a122:c020 with SMTP id a640c23a62f3a-ad8988b2e36mr386499166b.16.1748429751624;
        Wed, 28 May 2025 03:55:51 -0700 (PDT)
Message-ID: <598650c5-386c-4384-9642-1cb77fb1d32c@citrix.com>
Date: Wed, 28 May 2025 11:55:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/ACPI: move scheduler enable/disable calls out of
 freeze/thaw_domains
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mykola Kvach , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <974033e9ff0df3ce8a74efaa33f1cee1dcbdb030.1748340071.git.mykola_kvach@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: <974033e9ff0df3ce8a74efaa33f1cee1dcbdb030.1748340071.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 27/05/2025 11:04 am, Mykola Kvach wrote:
> From: Mykola Kvach 
>
> The scheduler_disable and scheduler_enable calls have been removed
> from freeze_domains and thaw_domains, respectively, and relocated
> to their usage context in enter_state. This change addresses
> the concern about misleading function semantics, as the scheduler
> operations are not directly related to the domain pausing/resuming
> implied by the freeze/thaw naming.
>
> Suggested-by: Jan Beulich 
> Signed-off-by: Mykola Kvach 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Wed May 28 11:00:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 11:00:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999327.1380006 (Exim 4.92)
	(envelope-from )
	id 1uKEWQ-0000zk-3V; Wed, 28 May 2025 11:00:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999327.1380006; Wed, 28 May 2025 11:00: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 1uKEWQ-0000zd-06; Wed, 28 May 2025 11:00:34 +0000
Received: by outflank-mailman (input) for mailman id 999327;
 Wed, 28 May 2025 11:00:32 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKEWO-0000zJ-FY
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 11:00:32 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f39f36ac-3bb2-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 13:00:22 +0200 (CEST)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-604533a2f62so6895182a12.3
 for ; Wed, 28 May 2025 04:00:22 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6051d60757dsm614036a12.33.2025.05.28.04.00.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 28 May 2025 04:00: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" 
X-Inumbo-ID: f39f36ac-3bb2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748430022; x=1749034822; darn=lists.xenproject.org;
        h=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;
        bh=zrIui1xyOj3oWDyzMJJM17bDTYJKTOACDfiBDPls5Cs=;
        b=gl+WsSRjJETGDxK+wXea/WD/LhNwrthcMPnrYCrl3KUZgT3WeZ2WhgaRe0+aE5k+j0
         dCdaZF5BuPxIPs+4pFWi6HvbTxtnvmO8ShcJKwq/z45nHGf29j6iX4BXX2Iv1L9bAO+R
         lqdWq/SE+lgZoCjPZAf8FNId2WMvqO4FWeHb51cDd3UtpVQsbFZ+cWnR+3uhVOuYoQD0
         usI3+E3zmz7r8Lc1x5YLUJabMJlX7rhEaJUH3P+N+a45Spi5LGYOnt4YUQz/B4J/bWqo
         c/bqADj52MQx57HaJvH6uaUjLW1mXeI0LLY6BwTbuPNz03Ibr+oT/HoCOU3PBb2LVZdn
         4QXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748430022; x=1749034822;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=zrIui1xyOj3oWDyzMJJM17bDTYJKTOACDfiBDPls5Cs=;
        b=Q4djKwKpgc4hjQyD1ZTqE5k0n8ARy719+PGkRYyhJ6/5MhFUGvd+5Xg0vSrk08Dlmw
         9hx5YNs+62O6cC6Tz94T2EoUWn7VWpThsbRud0zp2W+x9eTAGYOvIgRF8dwjjeplq0A0
         DCvicHFN0lN5odDXEm41TrMMpJD0KExT0oRQjdbAfFqHXyTEIOwztJD8tLYVGeaJOwDD
         rbGda+RZz4A9xsnprvdkC/K/HelCRdTmEunlHO6QO2789RKJappMtiXjKdXExroT5XxT
         nJyLKZtJmR5S8yzUxkOIsFaa3+VhOd+lGABYXoMJJw6KO0kin28g4HfaUaJlYzjtNmqz
         Nzfw==
X-Forwarded-Encrypted: i=1; AJvYcCUeUnXgk4+DXpgSguBbeRUuq6YL4mYDAHkd8UVLQWAuS8mR5dV5A9ilIMHE9gmIzDHofrDCEGPWA7I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyIA2MbB2oM38vv/r4hF+L97pKskIOpbTIPcBX12RVyBbgJabTG
	e4K8QAiDeD39fLQ0prxLxPqJnB0opkgcGt5MN//97jy6S2xWtf/s3ARh
X-Gm-Gg: ASbGncvwxmxbTkXkXZKEhwAiD3UF0OJl/JVT3cSeyILacZxeXvfWFvLbw3MUk0EZsEe
	N78AdSxcm2k7tNxXjeeR4wLYTTJIAeEnOsZIhqtvn4zkE84hcZMigKediYaQYZwybLgH0XKa+ZP
	toIL6xl6ZNhXIwL8i1x0RfzC2vjPg8WxlGK5L1qXID06YatbjYoZEkou8dRwsAgxZ8XoiVHAqGP
	29IuAyYl7OB2Orq80gEPBZ2ogwQAmgP8Rfbv5EpfoNc1nDmSFhb6EgO46SBfx90a1y8rahL8nN8
	jAsryy5tBcjd5pCTXASfJlAhvRudj4TPAMjhnbhLziKHhima/v0SGtxuYKlI4xI+iKFbFvZqzQL
	8rpmFCiGJUs7tk30TpjB1DAjB
X-Google-Smtp-Source: AGHT+IFj/IC6PdCL2eW9+vTEGUGDPwKWZ+35bHQ+9ap2wYSAyoN4F6it1clVaplAsl8JvDQCXppM2Q==
X-Received: by 2002:a05:6402:27ca:b0:604:e33f:e5cd with SMTP id 4fb4d7f45d1cf-604e33fe8c6mr7137358a12.19.1748430021808;
        Wed, 28 May 2025 04:00:21 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------IMmpqwr2iqJljvYIfrvMUm4s"
Message-ID: 
Date: Wed, 28 May 2025 13:00:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 11/14] xen/riscv: implementation of aplic and imsic
 operations
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Romain Caritey , xen-devel@lists.xenproject.org
References: 
 <33f0952f0d05e4fe8fff926df31987e006c6eacf.1747843009.git.oleksii.kurochko@gmail.com>
 <26893680-4467-4e42-89e5-b9020529f03d@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <26893680-4467-4e42-89e5-b9020529f03d@suse.com>

This is a multi-part message in MIME format.
--------------IMmpqwr2iqJljvYIfrvMUm4s
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/22/25 5:55 PM, Jan Beulich wrote:
> On 21.05.2025 18:03, Oleksii Kurochko wrote:
>> +static void 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;
> Nit: Comma vs blank placement.
>
>> +    const struct imsic_config *imsic = aplic.imsic_cfg;
>> +
>> +    /*
>> +     * TODO: Currently, APLIC is supported only with MSI interrupts.
>> +     *       If APLIC without MSI interrupts is required in the future,
>> +     *       this function will need to be updated accordingly.
>> +     */
>> +    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
>> +
>> +    ASSERT(!cpumask_empty(mask));
>> +
>> +    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;
>> +    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);
> Nit: Line length.
>
> I'm also puzzled by the various uses of IMSIC_MMIO_PAGE_SHIFT. Why do you
> subtract double the value when calculating hhxs, just to add the value
> back in here? There's no other usee of the variable afaics.

To follow AIA spec:
   MSI_address = ((Base_PPN | (group_index << (HHXS + 12)) | (hart_index << LHXS) | guest_index) << 12)
   Represented in the terms of Section 3.6, HHXW = j, LHXW = k, HHXS = E - 24, LHXS = D - 12, Base PPN = B >> 12.

Specifically, in this case it is possible to calculate as hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT,
and then drop "+ IMSIC_MMIO_PAGE_SHIFT" in (hhxs + IMSIC_MMIO_PAGE_SHIFT), but then it could be harder to
understand a formula when you look into AIA spec and then what is in code.

Also, possible one day hhxs will be used somewhere else, for example, to verify target base physical PPN as Linux
kernel does:
	tppn = msg_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;

	/* Compute target HART Base PPN */
	tbppn = tppn;
	tbppn &= ~APLIC_xMSICFGADDR_PPN_HART(mc->lhxs);
	tbppn &= ~APLIC_xMSICFGADDR_PPN_LHX(mc->lhxw, mc->lhxs);
	tbppn &= ~APLIC_xMSICFGADDR_PPN_HHX(mc->hhxw, mc->hhxs);
	WARN_ON(tbppn != mc->base_ppn);

	/* Compute target group and hart indexes */
	group_index = (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(mc->hhxs)) &
		     APLIC_xMSICFGADDR_PPN_HHX_MASK(mc->hhxw);
         ...

At the moment, I can add the comment above hhxs (and/or group_index) that it is calculated in this way and
isn't simplified to "hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2" to follow a formula
from AIA spec.

~ Oleksii

--------------IMmpqwr2iqJljvYIfrvMUm4s
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/22/25 5:55 PM, Jan Beulich wrote:
    
    
    
    
    
      
    On 21.05.2025 18:03, Oleksii Kurochko wrote:

    +static void 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;

    Nit: Comma vs blank placement.


    +    const struct imsic_config *imsic = aplic.imsic_cfg;
+
+    /*
+     * TODO: Currently, APLIC is supported only with MSI interrupts.
+     *       If APLIC without MSI interrupts is required in the future,
+     *       this function will need to be updated accordingly.
+     */
+    ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM);
+
+    ASSERT(!cpumask_empty(mask));
+
+    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;
+    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);

    Nit: Line length.

I'm also puzzled by the various uses of IMSIC_MMIO_PAGE_SHIFT. Why do you
subtract double the value when calculating hhxs, just to add the value
back in here? There's no other usee of the variable afaics.
    
    
    
    
    To follow AIA spec:
  MSI_address = ((Base_PPN | (group_index << (HHXS + 12)) | (hart_index << LHXS) | guest_index) << 12)
  Represented in the terms of Section 3.6, HHXW = j, LHXW = k, HHXS = E - 24, LHXS = D - 12, Base PPN = B >> 12.

Specifically, in this case it is possible to calculate as hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT,
and then drop "+ IMSIC_MMIO_PAGE_SHIFT" in (hhxs + IMSIC_MMIO_PAGE_SHIFT), but then it could be harder to
understand a formula when you look into AIA spec and then what is in code.

Also, possible one day hhxs will be used somewhere else, for example, to verify target base physical PPN as Linux
kernel does:
	tppn = msg_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;

	/* Compute target HART Base PPN */
	tbppn = tppn;
	tbppn &= ~APLIC_xMSICFGADDR_PPN_HART(mc->lhxs);
	tbppn &= ~APLIC_xMSICFGADDR_PPN_LHX(mc->lhxw, mc->lhxs);
	tbppn &= ~APLIC_xMSICFGADDR_PPN_HHX(mc->hhxw, mc->hhxs);
	WARN_ON(tbppn != mc->base_ppn);

	/* Compute target group and hart indexes */
	group_index = (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(mc->hhxs)) &
		     APLIC_xMSICFGADDR_PPN_HHX_MASK(mc->hhxw);
        ...

At the moment, I can add the comment above hhxs (and/or group_index) that it is calculated in this way and
isn't simplified to "hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2" to follow a formula
from AIA spec.

~ Oleksii


    
  


--------------IMmpqwr2iqJljvYIfrvMUm4s--


From xen-devel-bounces@lists.xenproject.org Wed May 28 11:24:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 11:24:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999340.1380032 (Exim 4.92)
	(envelope-from )
	id 1uKEth-0004fB-R7; Wed, 28 May 2025 11:24:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999340.1380032; Wed, 28 May 2025 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 1uKEth-0004f4-Nx; Wed, 28 May 2025 11:24:37 +0000
Received: by outflank-mailman (input) for mailman id 999340;
 Wed, 28 May 2025 11:24:36 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKEtg-0004ey-6V
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 11:24:36 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 525e91c1-3bb6-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 13:24:30 +0200 (CEST)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-604bf67b515so5234463a12.0
 for ; Wed, 28 May 2025 04:24:30 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6051d79ecc2sm630790a12.72.2025.05.28.04.24.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 28 May 2025 04:24: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" 
X-Inumbo-ID: 525e91c1-3bb6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748431469; x=1749036269; darn=lists.xenproject.org;
        h=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;
        bh=6UYj72m+Tuuzp/nNHOvzVSeNM3/v1yE1vFpw1udpOJ8=;
        b=Jrb3FDiShkYIa6LUQLYPas3pSV6qcFNmP6g/RC+1w09u+Ua+P7HjF7AvvAaWZbkvUI
         BtI1fBSNEFF7tknwbI7dbslbUogJeQ+xojuIIw9V4ejYnuZpMkAevqJZJGXcMKOcoaB9
         XZxIxSPY0HQ17kpkpzfDeuLQa7TIhVAko3AD4kFNA6UBYseBe2Bw0h8UF1dfnwZEOeZs
         dIsjZaZaJpBoDkLVSIXz9WFbZ1itwyaebjwS6gZQu1lyX6vIWFxaYq7/lu5YMCa755pd
         CqmAspFo9Tpcwpq3UaD5Gx3UNDBAFGUhKZprMzz1otpRQbCz3ym7ptiAVIzyKVrSTjFJ
         IibQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748431469; x=1749036269;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=6UYj72m+Tuuzp/nNHOvzVSeNM3/v1yE1vFpw1udpOJ8=;
        b=OQXHMMis1U6jU132oLBGsdbjjs0jkWEzEs7VzDPewLtgTdpHarlm94XES9YucVODEU
         lKEPG6zltT04WNzbFXdaop7o8YvtTxjc9nI/ovi3acq6KuMxqEB+BzO3UULWblfvgb9e
         /y6pdEFdTJXxIocZ9cOiE3s4ZzCDhqdTVcKPIq7sKvwUiGOBy17XoOTzGFjDvewbCRDY
         E6jEkO+xN5z1aKlPUM9fPNl7yxX3N98Rjj9K+OmflUvOmV7s5/YXyPGkKI7IXszoVbCq
         eH0os3NM6JtbZFmwUkS6w8/Gc93AFhkXBnVQB91z8EhkELAdAmswmVio0ayHWB3t45l7
         F/4Q==
X-Gm-Message-State: AOJu0Yy4peeepGPTlQnJ7rVrZfyiziN4egCx6+xymoM9WgHtIOWyV6lb
	bow5wPhG0m2D9abGjLYZqGxu2jrYgrNSKyblbALtThMwkfQE0YKj5eGTj7G9zg==
X-Gm-Gg: ASbGncudHSADv17Qi0F6ESmUaE8nYSto1JFbRVkFTwAmOaiDoflofdPtC3CR4yDYm8y
	wAjk8eFaE+juvfogGLk3rKWmC9qFtuqvcx4HdKhziiTqON+oeTT+nR2jZw9ZA7ylg6i0Vr2+cLY
	G3gzxZqZHPjjyDgnBay8BEysxaPBXxD2MKuY+tJlEVBvoD87XTWIjjzXUbAgfNNLuEJFDc9eAey
	QcoLLqenIGXVW2TqUOGMySxF7eNY2bNCKebJZpDOqopN5qAc54WRxQDjQDEg5xZGyOdMKRN7jQ6
	kTjArhkwJl68u+dORV3ZZXcyCTLuN9owVuhSrM6pTCcy/V4uNNUnWeI1ksp06Rq/3RxGXWIuSp4
	N14teQ6EkDVrrSmKRqt7q5BSl
X-Google-Smtp-Source: AGHT+IG8FZWq4454WCOeiHFVc3gf7OCMcNsRZCgkC7DVLuZezpYzOmk1oUFNTMGeGg0DV/nU/Lv5EA==
X-Received: by 2002:a05:6402:35c6:b0:602:29e0:5e24 with SMTP id 4fb4d7f45d1cf-602d7c98073mr13173091a12.0.1748431469448;
        Wed, 28 May 2025 04:24:29 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------rsutJmwHO93pmXm4UdSR3QCs"
Message-ID: <925e0d63-2960-47a4-9b25-3ff053e36434@gmail.com>
Date: Wed, 28 May 2025 13:24:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4][PART 1 4/4] CHANGELOG: Mention Xen suspend/resume to
 RAM feature on arm64
To: Mykola Kvach 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach ,
 Community Manager 
References: 
 <1035d97375bad4b3e6f86e78cbe4e46abdbc2de9.1748337249.git.mykola_kvach@epam.com>
 <87034726-3a26-4146-ad05-655058b9eba9@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------rsutJmwHO93pmXm4UdSR3QCs
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 5/27/25 6:05 PM, Mykola Kvach wrote:
> Hi, @Oleksii Kurochko
>
> On Tue, May 27, 2025 at 6:38 PM Oleksii Kurochko
>  wrote:
>> Hello Mykola,
>>
>> On 5/27/25 11:18 AM, Mykola Kvach wrote:
>>
>> From: Mykola Kvach
>>
>> Signed-off-by: Mykola Kvach
>> ---
>>   CHANGELOG.md | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>> index ec452027f5..fc89ed6e09 100644
>> --- a/CHANGELOG.md
>> +++ b/CHANGELOG.md
>> @@ -26,6 +26,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>
>>    - On Arm:
>>       - Ability to enable stack protector
>> +    - Support guest suspend/resume to/from RAM
>>
>>   ### Removed
>>    - On x86:
>>
>> According to your commit message, suspend/resume will only work for Arm64.
>> I think it would be good to mention that in the CHANGELOG.md as well.
> Thank you for pointing that out — in this case, I forgot to drop
> "arm64" from the commit message.

Then it makes sense to me to drop it in next patch series version.

> For non-hardware domain guests, suspend/resume support is available
> for both ARM32 and ARM64.
> When PSCI SYSTEM_SUSPEND is triggered from the hardware domain, the
> system ultimately uses
> Host PSCI — that is, a full system suspend is performed.

Thanks for clarification.

>
>> Also, this implementation adds suspend/resume support via vPSCI, which
>> I believe is also worth noting in the CHANGELOG.md.
> You're right — in this context, "guest suspend/resume" refers to
> handling via the virtual PSCI (vPSCI) interface.
> When regular PSCI is used, it's typically referred to as Host PSCI.
> That sentence could probably be rephrased for better clarity. Thank you.

It would be nice.

Thanks.

~ Oleksii

--------------rsutJmwHO93pmXm4UdSR3QCs
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    

    
    
    
    
    On 5/27/25 6:05 PM, Mykola Kvach wrote:
    
    
    
    
    
      
    Hi, @Oleksii Kurochko

On Tue, May 27, 2025 at 6:38 PM Oleksii Kurochko
<oleksii.kurochko@gmail.com> wrote:

    
      
    
        
    Hello Mykola,

On 5/27/25 11:18 AM, Mykola Kvach wrote:

From: Mykola Kvach <mykola_kvach@epam.com>

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
 CHANGELOG.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index ec452027f5..fc89ed6e09 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -26,6 +26,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)

  - On Arm:
     - Ability to enable stack protector
+    - Support guest suspend/resume to/from RAM

 ### Removed
  - On x86:

According to your commit message, suspend/resume will only work for Arm64.
I think it would be good to mention that in the CHANGELOG.md as well.

    
      
    
      
    Thank you for pointing that out — in this case, I forgot to drop
"arm64" from the commit message.
    
    
    
    
    Then it makes sense to me to drop it in next patch series version.


    
    
    
      
    For non-hardware domain guests, suspend/resume support is available
for both ARM32 and ARM64.
When PSCI SYSTEM_SUSPEND is triggered from the hardware domain, the
system ultimately uses
Host PSCI — that is, a full system suspend is performed.
    
    
    
    
    Thanks for clarification.


    
    
    
      
    

    
      
    
        
    Also, this implementation adds suspend/resume support via vPSCI, which
I believe is also worth noting in the CHANGELOG.md.

    
      
    
      
    You're right — in this context, "guest suspend/resume" refers to
handling via the virtual PSCI (vPSCI) interface.
When regular PSCI is used, it's typically referred to as Host PSCI.
That sentence could probably be rephrased for better clarity. Thank you.
    
    
    
    
    It would be nice.

Thanks.
    
    
    ~ Oleksii
    
  


--------------rsutJmwHO93pmXm4UdSR3QCs--


From xen-devel-bounces@lists.xenproject.org Wed May 28 12:12:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 12:12:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999368.1380041 (Exim 4.92)
	(envelope-from )
	id 1uKFe8-0003Pk-C6; Wed, 28 May 2025 12:12:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999368.1380041; Wed, 28 May 2025 12: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 1uKFe8-0003Pd-9A; Wed, 28 May 2025 12:12:36 +0000
Received: by outflank-mailman (input) for mailman id 999368;
 Wed, 28 May 2025 12:12:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKFe6-0003PX-EV
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 12:12:34 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 08e135fa-3bbd-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 14:12:33 +0200 (CEST)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-ad69e4f2100so662221966b.2
 for ; Wed, 28 May 2025 05:12:33 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad8a19ad3f2sm96862666b.36.2025.05.28.05.12.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 28 May 2025 05:12:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 08e135fa-3bbd-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748434353; x=1749039153; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=/8XPbmZZrPbEhugF2Ma/nX1LS00H4PPsJY3H+d7TJ+0=;
        b=ocJAvFYTkm+rEGLpRXmANjSYBpBdBNEOguQufE9Epa53JuGQ98lSNhfZ3QTmCGIFDS
         F21jCpQJqcVZSEyQXujs6SMKKbjwkhT6IwcnJkDQTwWaEWRwXiYBtCFz1gFJwez/WFJ8
         hzqD3SA9kWbNZwv/Q/IqpkldO19YnQwyl8+gQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748434353; x=1749039153;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/8XPbmZZrPbEhugF2Ma/nX1LS00H4PPsJY3H+d7TJ+0=;
        b=kWM0VxBfFdu7T8TcJpFIYouGnKSIx2I5flFkNaWKgDC7ejjMoKRAJ+uTwXEVQpRS/r
         9lUlzcbQWBSUtHecJ+PJIO2IdFjP+6q9U+aCXSK0U7AInJHWH+wjEdrJdZZnT3VzOFAx
         B3uTQl3WGfSGHtvKJJBrEVyrjkPRMCRZTXRCt5fKXlqLoFGV2b5opfwf0egMIddJXSny
         LTEjPC17Y6IVH1YvHDPyAJzJ0BPvsmnNl2cgI5ZjGq8BE6qx0r0nKsiWNXi0qRaz1DZ2
         PK93tnEARtPQM5nmPdBCgMOEmkdJcOIi4AWUky0V3V/LamXLRpRxhufGJ9PmDxo0gSEt
         mw8w==
X-Forwarded-Encrypted: i=1; AJvYcCXT4ECG6JqlYWTG9z4utYZnwBfoQN5vDYaRnmN4B4OaGKSsM+xUDpdYbjeAiV4YJYjIWsMwlI/YAFQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyndoGuPffWUhRywAVZ42qePVbIB1xYuC+ALo5+oTL3SH9lNTOX
	QZ0ky8pb+beaLjVBe4OR6mwfwTymmrIleZaTvurhc1RjpWZUo1DSKMqte7Ez0tv7cyvbtkAdpJt
	LhhX0
X-Gm-Gg: ASbGncsbQ6vur79S6PYIrKrre/3RxcYa1trXVMBSI7qxRm0QOXDUE7pbuBIXzoKW4Dc
	2NeXedJIgpvsXjewIf7chFXs2NxyhaW0DAO23FY6XdT6YGqec/vCSJvT84yol19Kb66mDoC3Mfr
	pMzBwUxg20t1dbOHTmAWCdOGyJ7X/0wVwzfOiCePYkm/wyzIsyc3ebXAgJcyoc48evRapc8snIp
	ghxeIwNko8SeQxRLL9LfYRTiVw22G4oGTz+TNSOx2PyjyrxDxKe9l7Xkb2CWQ1auqimYjJBa/D3
	lyDsiR2iHdckoD1vpt9Gku0uPGf4BABvAXgrIrIdZ+Vr+cfBO68o/4Rrp6grqLUlTAUFNhUM3DW
	rJrs6maVIOc5MPwIb
X-Google-Smtp-Source: AGHT+IEdc0v/AGFEEUbRTlAW4HFOAAsCdXi3mJmhev9JryzswbNtSpC5Vrx4BK+aSwaTPTJiRRHkXA==
X-Received: by 2002:a17:907:7e8c:b0:ad2:3577:38fb with SMTP id a640c23a62f3a-ad85b1ce89emr1474791466b.30.1748434352748;
        Wed, 28 May 2025 05:12:32 -0700 (PDT)
Message-ID: <2fbcfbee-1ae6-47b9-b6e3-32d3330f2d02@citrix.com>
Date: Wed, 28 May 2025 13:12:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/3] CI: Use bash arrays to simplfy dom0 rootfs
 construction
To: Anthony PERARD 
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 , Xen-devel
 , Stefano Stabellini
 , Michal Orzel 
References: <20250522173640.575452-1-andrew.cooper3@citrix.com>
 <20250522173640.575452-3-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

On 28/05/2025 10:45 am, Anthony PERARD wrote:
> On Tue, May 27, 2025 at 04:24:57PM +0100, Andrew Cooper wrote:
>> On 27/05/2025 4:19 pm, Marek Marczykowski-Górecki wrote:
>>> On Tue, May 27, 2025 at 04:01:34PM +0200, Anthony PERARD wrote:
>>>> On Thu, May 22, 2025 at 06:36:39PM +0100, Andrew Cooper wrote:
>>>>> For Qubes, this requires switching from sh to bash.
>>>>>
>>>>> This reduces the number of times the target filename needs to be written to 1.
>>>>>
>>>>> Expand the comment to explain the concatination constraints.
>>>> Isn't the correct spelling "concatenation"? Same for the two comments.
>>>>
>>>>> No functional change.
>>>>>
>>>>> Signed-off-by: Andrew Cooper 
>>>>> ---
>>>>> I would like to find a slightly nicer way of conditional parts, but nothing
>>>>> comes to mind.
>>>> Well, one way I can think of is having a new variable which can carry
>>>> the rootfs part associated with a particular test, then that variable
>>>> can be updated at the time we configure for that test. Something like:
>>>>
>>>> # init
>>>> declare -a append_rootfs_part
>>>> # or append_rootfs_part=() is probably fine too.
>>>>
>>>> case $test in
>>>>   argo)
>>>>     append_rootfs_part+=(argo.cpio.gz)
>>>>     # ... other test configuration
>>>>     ;;
>>>> esac
>>>>
>>>> # Dom0 rootfs
>>>> parts=(
>>>>     rootfs.cpio.gz
>>>>     xen-tools.cpio.gz
>>>>     "${append_rootfs_part[@]}"
>>>> )
>>>>
>>>> And that should works fine, even if there isn't any extra rootfs part.
>>> That would work for compressed parts, but not for uncompressed - which
>>> need to come before all compressed. But maybe there could be two arrays
>>> - one for uncompressed and another for compressed? Then, each could be
>>> extended anywhere, without messing the order.
> You could use "${append_rootfs_part:#*.gz}" and
> "${(M)append_rootfs_part:#*.gz}" to grab the uncompressed part then the
> compressed part... on zsh :-). But something similar could be codded in
> bash. But I guess two variables will be more acceptable.

I believe there's a restriction that only one type of compression can be
used, but I don't particularly fancy tying it to gz specifically.

Something else to look at in some copious free time is .xz or so.  For
test-artefacts its surely a size win, but whether it's better overall
depends on whether using xz in this script doesn't undo the
optimisations we've been trying.  Once this series is in, we're down to
a handful of tiny text files, so I expect it to be in the noise.

>> Hmm, two might work, but they surely need to not be quoted when forming
>> parts=(), or having multiple entries will go wrong on the eventual cat
>> command line.
> The double quote are needed!

Yes, sorry.  That was a stupid suggestion of mine.  I really ought to
know how "$@" works by now...

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 28 12:43:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 12:43:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999387.1380080 (Exim 4.92)
	(envelope-from )
	id 1uKG7u-0007rV-So; Wed, 28 May 2025 12:43:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999387.1380080; Wed, 28 May 2025 12:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKG7u-0007rO-PC; Wed, 28 May 2025 12:43:22 +0000
Received: by outflank-mailman (input) for mailman id 999387;
 Wed, 28 May 2025 12:43:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKG7t-0007rI-Bi
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 12:43:21 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 547230fb-3bc1-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 14:43:18 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a36748920cso4444282f8f.2
 for ; Wed, 28 May 2025 05:43:18 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4eac8add9sm1425478f8f.54.2025.05.28.05.43.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 28 May 2025 05:43: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" 
X-Inumbo-ID: 547230fb-3bc1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748436197; x=1749040997; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=pX4ELTjmdVJZArYklMOfTspu4AXysMbYaSBdySkQWQ4=;
        b=Si7nQv7vh5IfPPbsixnWKwxihs0OQwCptVXfjeJ2K7iniyrOrd+s8ntkdMVZaZuL4w
         ptNgOhMUzDcCH7YKJXqO9jSM/QxLsdf2H/E5zAkh1IN4JQ+YwrQrlpQ/0Xlra9l0Prv+
         55HzRZLolqWVj/C1QFa5MtWrVDKG/2yoEaKRQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748436197; x=1749040997;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=pX4ELTjmdVJZArYklMOfTspu4AXysMbYaSBdySkQWQ4=;
        b=R1SyOKI4+Rm3akW3hm0YNAWgHEmA8Ik+fVo17IyNbTjV3oFzMel7vrPktHfSAqc0VC
         4zNJcrp9Ujvj1Lx9xScwJrJ44oE3ncWFJwR9lO+wV44jsL5syThj0YcfyczLHzueC5W4
         bjegvSLbXSckbnysrS8qEYgOmvDpzwwELIS3DL1EmrDkb13ddMQIvEQkxWMSSAjLbzHB
         KM9c/smIy4vNQUvpdje2WFbg1f4i4oE47yWF+V2jp/6GpbSFN669LG5jwLNdIpuetheS
         /oZaURNdJ+JebOnCY7j1uNxL1vTmqewNoQlzfS2jLLd0iVojzq0V9Ww4tYN4DIT1zqJw
         P16g==
X-Gm-Message-State: AOJu0YwDMWfCuRQ+gl7Ug3Lm+aCJxiVLIw8CW5eC6uOhrbDt+Ug/xW9O
	nEixwwy7PyFSNUZbN0EOug2IaTKb16EGbR/ynDfskJ/S8GUZiWbYIlKvmHBvys7UB9WWwKTYNhF
	wq8A4
X-Gm-Gg: ASbGncsEY1WOxxJW3okJfoRcZDliO+6Io5VXwQfPSmbblhGC380zeW11bb1u2OzEqsH
	AcBNIvObQJ595nBaKs1S51AntkVK8XTCEf9fb1imEpigfhHpUJrSahpbMaTdVpaiTtYc1OJ4KxN
	st08VXHhwAd6SwOJlYilEM/J7cgLw/VtbmIyWuv5C2rHXySknfHnw5NI6qm+itkiBDqolE2Xbq/
	2/VkDsVQdveLYrsD/jDVw9oFOqcWb9VTB0XiG4dvHkbFbnNw34htvI339JSSTuaWTGLSSUUMHCx
	L3Fkbv1XJtUI1PgSSgSDMgU2mM7T3Id0MloSYo+OY6f1jBhAsMmCX825AN2PDbv6WPqlGrvjhH7
	q9Qq1lW0ICh72Yu/Eo4k=
X-Google-Smtp-Source: AGHT+IFxM3bDc6pw4d1XxuWmrPIeHwgqP9xevxYDTLqgxdUeolwPkjhd6uIAzsFJ2UlXtUy8zOAVaw==
X-Received: by 2002:a05:6000:40c7:b0:3a4:eda1:f675 with SMTP id ffacd0b85a97d-3a4eda1f716mr372646f8f.29.1748436197546;
        Wed, 28 May 2025 05:43:17 -0700 (PDT)
Date: Wed, 28 May 2025 14:43:16 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, Jan Beulich 
Subject: Re: [PATCH] x86/traps: Trim includes
Message-ID: 
References: <20250527150911.59744-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: <20250527150911.59744-1-andrew.cooper3@citrix.com>

On Tue, May 27, 2025 at 04:09:11PM +0100, Andrew Cooper wrote:
> None of these are used by traps.c today.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Roger Pau Monné 

> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 
> 
> I'm experimenting with include-what-you-use but it's not the most
> ergonomic of tools to use.

Does include-what-you-use take into account #ifdef sections?  I'm
wondering whether non-default Kconfig could require extra headers that
are not accounted for the tool?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 28 12:44:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 12:44:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999393.1380089 (Exim 4.92)
	(envelope-from )
	id 1uKG8a-0008I9-3Q; Wed, 28 May 2025 12:44:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999393.1380089; Wed, 28 May 2025 12:44: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 1uKG8a-0008I2-0U; Wed, 28 May 2025 12:44:04 +0000
Received: by outflank-mailman (input) for mailman id 999393;
 Wed, 28 May 2025 12:44:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKG8Y-0007rI-2W
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 12:44:02 +0000
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com
 [2a00:1450:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6dc4ddf2-3bc1-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 14:44:00 +0200 (CEST)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3a36efcadb8so4216364f8f.0
 for ; Wed, 28 May 2025 05:44:00 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4eac8a9aasm1415552f8f.51.2025.05.28.05.43.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 28 May 2025 05:43:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 6dc4ddf2-3bc1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748436240; x=1749041040; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=YCcVGjyu2hkgj2qT0Rfij8sRp8sN0oQaMCH5Sad8ZL4=;
        b=ijmBCbtPkR2JQK4umkGBkG25cHCfSFeHjCqkSXUh/n+52PgxbAufVaQxbcgqmmVCbx
         l2U9wkUBMVtZfmUn3YnO77ALlOy6SVsJ0cGVY3flFM2Z5F/Pm01zX1GNusxlyEencapM
         1updpHFCGhyUi+YQaoaOZaBubs7Y3zfHRQUKw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748436240; x=1749041040;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=YCcVGjyu2hkgj2qT0Rfij8sRp8sN0oQaMCH5Sad8ZL4=;
        b=wAZ2nDAbVnKNGvMDqFTPWyc9hfrreDMFEGM4bZS/Q80yWFLtgtwF9WCHS8uBDaPUbT
         XC/9Om/+23Zlq2ihhTJIqY0UhuF7uVTCEqcaZzQ1Gd3vRIxJQp6gVct4d7NIc3B/JMQ3
         apdO6AbjCM1DoRrXCkjhFJ8x8xxQj9MT88+afLYv/iSG8ThXHltDfEO/Q0zVx5t7DHaO
         jSqrZYJElSY5z6DlkbcWLqCAxlnIddC2JSXL/4ltWqdhFh3VmvJfr+nYrWf0ezp/QKT/
         09IoAfHCqHqPwGXK5ObzVRd/LM483w9jWZc7OVIMqlJHUiSiawmKWgd3Xd7V5FQRUsi2
         imxw==
X-Gm-Message-State: AOJu0YxWNVVW2jbz/QHQSkGX1iTkwjugh2kpArXyxpJCZCqS+5kHq4ii
	67Xm79Cr/0Dr8QbqoKCVIkt4BP+cTgomv4fhw8ZPqs9je6lAR3ouMw9OXH89TP0BONgVIuFNQOQ
	MxtPw
X-Gm-Gg: ASbGncvq4zzFj9AdZEinaHfnSeeCx8m8jCM4b6Daz+mY6TABAMAXjgOZewOd46liD9F
	pxmE8gV75lsyxhmi9L9Vvx1ANmgadWwJPgbyqaTufIYeu+NAPmBr6LV2sKUFMx6dpNrXmyK9gAM
	eDJOZT7q8fo9tyu6GsxjYnz8CDKu2Hd1sSGTcEu10L9KsRVdlKdvm0IANvqXJBHHyaiDY3zXv9M
	9EktoPcHEczcWHaY7BnKn3duhjUrPtr1BcV36LjqcY7vRXkbfaPUtKm5CPUnd6Wfr+1RIe1N5c7
	rHxL9O+Mi2Fp3L0Rd2sScImn16IsY40746mRrabS1CmEoTQ8/tiATZQmWZM/MNRV4bAEP2ElRhR
	KuAn0i+CQZNwLjy2WP9stpbnSaYo1DA==
X-Google-Smtp-Source: AGHT+IF3p64LET0E4jjy8R/Zf7crxwxhF59fdEhskipX1i8Dh2+VwC0+vMeG/D3GogFIGIuY+jTlXw==
X-Received: by 2002:a05:6000:2288:b0:3a1:6e2b:85fa with SMTP id ffacd0b85a97d-3a4cb45e37amr14398161f8f.31.1748436240133;
        Wed, 28 May 2025 05:44:00 -0700 (PDT)
Date: Wed, 28 May 2025 14:43:58 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, Jan Beulich 
Subject: Re: [PATCH] x86/setup: Trim includes
Message-ID: 
References: <20250527151302.63291-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: <20250527151302.63291-1-andrew.cooper3@citrix.com>

On Tue, May 27, 2025 at 04:13:02PM +0100, Andrew Cooper wrote:
> None of these are used by setup.c today.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Roger Pau Monné 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed May 28 13:03:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 13:03:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999410.1380099 (Exim 4.92)
	(envelope-from )
	id 1uKGR8-0002zz-IR; Wed, 28 May 2025 13:03:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999410.1380099; Wed, 28 May 2025 13: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 1uKGR8-0002zs-Fw; Wed, 28 May 2025 13:03:14 +0000
Received: by outflank-mailman (input) for mailman id 999410;
 Wed, 28 May 2025 13:03:13 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKGR7-0002zm-Ns
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 13:03:13 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1bc8477b-3bc4-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 15:03:11 +0200 (CEST)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-ad8a6c202ffso70637066b.3
 for ; Wed, 28 May 2025 06:03:11 -0700 (PDT)
Received: from [192.168.1.183] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad8a19adc74sm104061566b.32.2025.05.28.06.02.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 28 May 2025 06:02: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" 
X-Inumbo-ID: 1bc8477b-3bc4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748437391; x=1749042191; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=pNvINVs7gmZNYXmnuabnAH7O2eXk3CaMnroHsqWYhpo=;
        b=cFw+jN1oXnht8kEjkYbXO8sTem/f5dd+DtIzChE9E4AhImWCohusAHw4c90/VJJ5VT
         9j9hOJ1UPwA8Mc/S4o7OgvENb0D98OGATzIuWSKST/FSwsHQf3g5S4VXvq+PI1n9lNGA
         r1qlwsgc8/Opmow5NTY8LBnrKqh4uQ6Luu0Fw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748437391; x=1749042191;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pNvINVs7gmZNYXmnuabnAH7O2eXk3CaMnroHsqWYhpo=;
        b=B5hod+QFxYcAMK751+zaK70JarlgyshlzS4wMJ+oM3waVQN4iuHLTYYLGfwHn4mTOi
         ZdPNBH1OAtENmaqJVTUDpjiKdG2SYIanhYxK4R+B6JfPwbiL0qJQcaSH3xoy3ts2K0pr
         k7KNYzpgnsQrOSRvEFi5WgtAeLbvuuqWAQKEi3eoqadRsan5SxQRCIyrkkkiPFG592Va
         b0G9644BpOrRM32xHPwLY2Lt5+C/R8Fx0J44+yP2mtk5Ig3wHPSoL7iTpiNoiEs1sn6Z
         XxWfYqhHpt8qZlSAJOyJWC9w1TRsbnGbWWdpfgSqpSi40vGcpAtPr2dcaEOCM4A2GUE/
         OfHA==
X-Gm-Message-State: AOJu0YyBIJbi2Gm/G75wulg2SDTWgOuqxkF1o1C/VQp+sJLAJP7hErYo
	3HMw26lnU+EpgYsvuCnpOcnM+5+O9SbFu9bi78CwYkb5r/K+ar0pOQHZacvP4+H90vSMIcAmDe3
	2WjFV
X-Gm-Gg: ASbGnctHwNd8SHv2mhh8TsGcIIQNM09cBtzjmRfRu6BCQAOa0AV8YFdNLuCEFqXeLxv
	QrTVY9uLAykXQOAQLp7CvHJir5HgQqk0fI1gFZpB6KCnoqxjR8OZZFDqFB5x0h9LOZdsvTT3Di7
	hJ9xcRIQK1VWnO23pxqe4hL9VrUFJdOKCz58W3CWzoKXLaSsiki/rC04masFrk89dKZZO1Nk+QD
	oYCs9m/yEeAqxOoMgayDfhIJvvTmy+PDlNa1kvFnVMnxrH+03kuRUbmCqIWCNJNGh3ve8FurDjV
	Pthp0WhbVpBJnQc9rTD1FwnCYlO+JCX+lRVJu/x2RuYh6/koa3KT4o4IMENU08TN2oF6bet0MFP
	ctARbrIuxUPrw3z6QBR5Qccihg9s=
X-Google-Smtp-Source: AGHT+IFScGN7b8CVhZBRudIk1LkuVL0EN+28rGkY7rBVlk8sC6T31+PZ34klmcF4M0ms7DF4XnnKoQ==
X-Received: by 2002:a17:907:2d23:b0:ad8:a935:b906 with SMTP id a640c23a62f3a-ad8a935c9a9mr71523566b.0.1748437376316;
        Wed, 28 May 2025 06:02:56 -0700 (PDT)
Message-ID: <0c68b3ed-9dc8-4802-8889-9971d8c45e0a@citrix.com>
Date: Wed, 28 May 2025 14:02:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/traps: Trim includes
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Jan Beulich 
References: <20250527150911.59744-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

On 28/05/2025 1:43 pm, Roger Pau Monné wrote:
> On Tue, May 27, 2025 at 04:09:11PM +0100, Andrew Cooper wrote:
>> None of these are used by traps.c today.
>>
>> Signed-off-by: Andrew Cooper 
> Acked-by: Roger Pau Monné 

Thanks.

>> ---
>> CC: Jan Beulich 
>> CC: Roger Pau Monné 
>>
>> I'm experimenting with include-what-you-use but it's not the most
>> ergonomic of tools to use.
> Does include-what-you-use take into account #ifdef sections?  I'm
> wondering whether non-default Kconfig could require extra headers that
> are not accounted for the tool?

Testing suggests that it does a normal preprocessor pass first.

Given:

    #include 

    #if 0
    void *ptr = NULL;
    #endif

the report suggests:

arch/x86/iwyu.c should add these lines:

arch/x86/iwyu.c should remove these lines:
- #include   // lines 1-1

The full include-list for arch/x86/iwyu.c:
---


and does not make the recommendation to include  to get NULL.


For traps.c,

grep -e '#ifdef' -e '#.*defined(' -e "IS_ENABLED" arch/x86/traps.c
#ifdef NDEBUG
#ifdef CONFIG_PV32
#ifdef CONFIG_HVM
#ifdef CONFIG_XEN_SHSTK
#if !defined(CONFIG_FRAME_POINTER)
    if ( IS_ENABLED(CONFIG_XEN_SHSTK) )
    if ( IS_ENABLED(CONFIG_DEBUG) && print )
#ifdef CONFIG_PV
#ifdef CONFIG_PV
#ifdef CONFIG_PV
#ifdef CONFIG_PV
        if ( IS_ENABLED(CONFIG_PV) && ret == EXCRET_fault_fixed )
#ifdef CONFIG_PV
#ifdef CONFIG_PV
#ifdef CONFIG_PV
#ifdef CONFIG_DEBUG

and each of HVM, PV and PV32 and XEN_SHSTK are active in the analysis I did.

NDEBUG, CONFIG_DEBUG and CONFIG_FRAME_POINTER aren't doing anything
interesting here.

So I think this patch for traps.c is accurate.

setup.c is far less certain, and I'll need to do some more analysis
before committing that.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed May 28 20:38:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 20:38:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999501.1380138 (Exim 4.92)
	(envelope-from )
	id 1uKNXZ-00047x-FM; Wed, 28 May 2025 20:38:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999501.1380138; Wed, 28 May 2025 20: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 1uKNXZ-00047p-9s; Wed, 28 May 2025 20:38:21 +0000
Received: by outflank-mailman (input) for mailman id 999501;
 Wed, 28 May 2025 20:38:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKNXY-00047j-2F
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 20:38:20 +0000
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
 [2a00:1450:4864:20::131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id afc55694-3c03-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 22:38:18 +0200 (CEST)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-55324587a53so1663133e87.0
 for ; Wed, 28 May 2025 13:38:18 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5533791d047sm1740e87.197.2025.05.28.13.38.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 28 May 2025 13:38: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" 
X-Inumbo-ID: afc55694-3c03-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748464697; x=1749069497; darn=lists.xenproject.org;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :message-id:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IM6C0g8568ddrCVZ/V5BXpWwYkuvhDd1PiVlUhhZSjM=;
        b=PvHUkSVyBKas6oSIqXNNuhHFRonlPXt1/VLtl7ygl72FE5NJn8Owofzd0AFnSOgZl4
         PS9gYJLvAezqCJUFhwAAM/dd1iqnVx1ZSzy3sv+VBMSSyGdqRoAdRzE5WfVPEGh7WZhW
         SgLJ7ZH3nGJKe07nh7TUQTJjjmH1ARzFsdU0Ppu1n5yGw4FAr7evsBJLV+5bZcagsWNq
         NVL4wc5b2qKgh+JjiItGuNwA7ew21vY3TqgeNirbFRgv6I63VX2JSdaAC1OyRbDHPGnV
         PgRG3GGgh1tR8xEjWJ5zooSNs0HXN+Nx1/YoYPR/hd6541WLV6UfjzJoyDKQQ1x4z1iI
         W4Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748464697; x=1749069497;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=IM6C0g8568ddrCVZ/V5BXpWwYkuvhDd1PiVlUhhZSjM=;
        b=VvHw7rm3L59jtjAcXeNdIR92ehY3IbrdW5nF6+apnYVsUF8ipnx/GyMjr7nLntXtpG
         ZNanZ117WlaFsn/NcjkwETSLmdVc44+Q0eIoIe+4JeX138lvBuU3PLCZoHyhYrtHKVLB
         gyxJPT33Ps+u8NU4RSJ2j5C/9+iHLk3lbGHLa3L+7WutfCwQOONg2mqXOnVBeA1aRQUA
         VZr3XXoA+s1W/u2+6/6Gp7AeXX335YCZENuXt3swPJ+e8meUHsrJ5yqY1oFtrRtqnOs4
         pmJyg2ipfrNUNGo3xHrKMwcjrZ4Vpbt0FnA1prM4LzdgvyA9fWLgWl7gfUbzomoe99Rg
         ZG/g==
X-Gm-Message-State: AOJu0YwhAcGuvl18fZH74IZ7+phb+VCU8f+znWexSX5zCLcm+Q5+p8nv
	MbjpOHW3ByDO0qoxu9uKkTyuvWzBEE/L5c3iHKveIZ/v3rpmyd42OSZj
X-Gm-Gg: ASbGncuTktUSdG4gk4nCRH2ehPAI7jrMeeGDlTSzSKu674MX2+lT1MsR++/rcD1tzR9
	Dpq1OvtJP1qNfp0Sig7KMGuEWcY7ysVk0t/cjq7sAxUFKXU+TRrfutwOQpvx+1fbEafQr5dJnjX
	NvW1hrDFN/XVBLZueuhIi+11oDb19ujmr2Bqfx6dHh4++95FjN/O7erp9nCYenfjiA+rt3qmHcf
	WWesJALeDTPKqkG2r2gn3/bscWGDd+XX4WUoPtimUBBVGQBFI/o0A6FQIU3PdiSvB4UTPOZ14AX
	XiW73fibC54sMxTDLFSxuj5SzJlssd3PtTXtptLRJuQ3fAOIpveSw+HNznM+UKQQKXOHD8J8d84
	uYHNmaB0VWEB6yMjkWCBGn/UJiy9nfloQrg==
X-Google-Smtp-Source: AGHT+IG4IuOuhAAQIBDnnEKwddgoNJS5TMmg7k7sW9aD+tcdmwGinsQ0LbC2A3ei5TR0A6rGnOOJxg==
X-Received: by 2002:a05:6512:3092:b0:553:2782:ac6d with SMTP id 2adb3069b0e04-55335b1e536mr345229e87.15.1748464697146;
        Wed, 28 May 2025 13:38:17 -0700 (PDT)
Date: Wed, 28 May 2025 22:38:15 +0200
From: "Edgar E. Iglesias" 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org,
	bertrand.marquis@arm.com, michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com, edgar.iglesias@amd.com
Subject: Re: [PATCH v1 0/3] xen/arm: Add option to optionally disable
 trapping on unmapped mmio
Message-ID: 
References: <20250527195616.874614-1-edgar.iglesias@gmail.com>
 <2eac2199-f3e2-4fa8-b6e3-f6cbf999d436@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2eac2199-f3e2-4fa8-b6e3-f6cbf999d436@citrix.com>
User-Agent: Mutt/2.2.14+84 (2efcabc4) (2025-03-23)

On Tue, May 27, 2025 at 09:03:11PM +0100, Andrew Cooper wrote:
> On 27/05/2025 8:56 pm, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias" 
> >
> > This follows up on the virtio-pci discussion and adds a per-domain
> > option to select the behaviour of accesses to unmapped mmio ranges.
> > The new option is trap-unmapped-mmio. For dom0less I negated it to
> > be able to use a boolean prop and keep existing behaviour, i.e
> > trap-unmapped-mmio-disabled.
> >
> > I'm happy with any name though so if you have better ideas please
> > suggest them!
> >
> > For the domain config i followed the example of x86 flags
> > and XEN_X86_MSR_RELXED, creating a flags field for ARM.
> >
> > Thanks,
> > Edgar
> 
> I think this should be common, rather than ARM specific.
> 
> Traditionally on x86, access to unimplemented address space was ignored
> (write discard, read ~0), but these days you do get a machine check on
> certain ranges, which is for all intents and purposes the same as a data
> abort.
> 
> So even if x86 requires it to be false in the short term, I think the
> control ought to be common, so x86 and others can opt in at a later point.

We can do that, we'd need to have different default values though since
x86 wants default false and ARM default true.

> 
> I don't have a good suggestion for the name, but it's not really about
> MMIO space; it's about address space generally.

What about trap-unmapped-access ?

Cheers,
Edgar


From xen-devel-bounces@lists.xenproject.org Wed May 28 21:02:00 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 21:02:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999516.1380147 (Exim 4.92)
	(envelope-from )
	id 1uKNuN-00085H-AK; Wed, 28 May 2025 21:01:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999516.1380147; Wed, 28 May 2025 21:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKNuN-00085A-7m; Wed, 28 May 2025 21:01:55 +0000
Received: by outflank-mailman (input) for mailman id 999516;
 Wed, 28 May 2025 21:01:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKNuL-000854-KY
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 21:01:54 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fa5d7fad-3c06-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 23:01: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" 
X-Inumbo-ID: fa5d7fad-3c06-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748466111; x=1748725311;
	bh=VGRa4NemlQLo9DcwpzLy2eNoBIZSx8+eUmMrQUjhwCQ=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=EUeetRkYA17scbZDQP5+3D6+RlS3Dz9lIzMjKGu2HodpbXnJ/Ata/dCMJ/g331jFa
	 OkVGuCdUVauiBsOf1yEASVGKDTo92a2WdhiVWlntFDKIuP/35nEXSusYYrJ4sPNhYP
	 5Qmhjxz+gX+Os2P7D0zXYev9hPeYwmJFpbZljd6LABNLJ1v7/b3kTarlSu6xSk/x8e
	 hn9KgYabl+oKoZoBjzhTNBKfmzS/5CC5q8nqsfpj4e5nJ45+amDuOL+TaI0GdMhQ+7
	 fYYJOr6Gs+5BdklptDKTLq04HEaUUar1a7a6hczSUa6dOGVDpKzrw8UXG6196ZXT/c
	 q0RXCLDxIC5QA==
Date: Wed, 28 May 2025 21:01:45 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3 0/2] xen/domain: updates to hardware emulation flags
Message-ID: <20250528210139.2572609-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 0949bbcdbe54d322368dd08447a3a908ddfedc0e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Patch 1 introduces emulation_flags in common domain struct for enabling dom=
ain
emulation features on non-x86 platforms.

Patch 2 rewrites emulation_flags_ok() on x86 with a goal of improving
readability and maintainability of the code.

Originally, the code was part of [1], part of NS16550 emulator v3 series.

[1] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-6-c5d36b3=
1d66c@ford.com/
[2] Link to v2: https://lore.kernel.org/xen-devel/20250516022855.1146121-1-=
dmukhin@ford.com/
[3] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1841708353

Denis Mukhin (2):
  xen/domain: introduce common hardware emulation flags
  xen/domain: rewrite emulation_flags_ok()

 xen/arch/x86/domain.c             | 94 ++++++++++++++++++++++++-------
 xen/arch/x86/domctl.c             |  2 +-
 xen/arch/x86/include/asm/domain.h | 25 ++++----
 xen/common/keyhandler.c           |  1 +
 xen/include/xen/sched.h           |  2 +
 5 files changed, 90 insertions(+), 34 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 28 21:02:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 21:02:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999518.1380158 (Exim 4.92)
	(envelope-from )
	id 1uKNuT-0008K4-Hz; Wed, 28 May 2025 21:02:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999518.1380158; Wed, 28 May 2025 21: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 1uKNuT-0008Jx-F2; Wed, 28 May 2025 21:02:01 +0000
Received: by outflank-mailman (input) for mailman id 999518;
 Wed, 28 May 2025 21:02:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKNuS-00084W-2O
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 21:02:00 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fe35b395-3c06-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 23:01: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" 
X-Inumbo-ID: fe35b395-3c06-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748466116; x=1748725316;
	bh=VGh7he7VOfbBFGuzvZwDtrPaGmx+HSsjbJ+lrhUlYfI=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=hOux6fMHu0DaWEPsVPcql5Wr9lCm6xem2o2L7o6E98aWhPRnqo9RQq+jislEjx9/h
	 SZW/bmtblBcyFBBj2FDfIPZPM7Bnt07HRLFpUnKQtdP1fhZTsrQsxfoAqY0dG34ew7
	 8acVI6dhEO8Xea4oqYUpdGWVbBW9RNlrX9T/zJfxiCdn3YLnqOM3b9+H+Kn0oxlKJZ
	 qn9fYE//SmpqA2vZ9QeP/NjSCvoasAbNYBJyr2yhz5+Q7iCFSieqlnoi7KX7KVhl+q
	 SUumanzFa9F+HxEtr4Fv2rIGSmDmjciL4jsXPaz1EV2gX2RBw01TZ+0eGSYwDqIXsL
	 UNE8m6OU9l9tw==
Date: Wed, 28 May 2025 21:01:51 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, Denis Mukhin 
Subject: [PATCH v3 1/2] xen/domain: introduce common hardware emulation flags
Message-ID: <20250528210139.2572609-2-dmukhin@ford.com>
In-Reply-To: <20250528210139.2572609-1-dmukhin@ford.com>
References: <20250528210139.2572609-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 6356eeb238f19e598dba3aec3cfe5d8e58448608
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

From: Denis Mukhin 

Add common emulation_flags for configuring domain emulation features.

Print d->emulation_flags from 'q' keyhandler for better traceability while
debugging.

Signed-off-by: Denis Mukhin 
---
Changes since v2:
- move emulation_flags to common domain struct
---
 xen/arch/x86/domain.c             |  2 +-
 xen/arch/x86/domctl.c             |  2 +-
 xen/arch/x86/include/asm/domain.h | 25 +++++++++++--------------
 xen/common/keyhandler.c           |  1 +
 xen/include/xen/sched.h           |  2 ++
 5 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7536b6c871..0363ccb384 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -831,7 +831,7 @@ int arch_domain_create(struct domain *d,
                emflags);
         return -EOPNOTSUPP;
     }
-    d->arch.emulation_flags =3D emflags;
+    d->emulation_flags =3D emflags;
=20
 #ifdef CONFIG_PV32
     HYPERVISOR_COMPAT_VIRT_START(d) =3D
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 3044f706de..37d848f683 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -144,7 +144,7 @@ void arch_get_domain_info(const struct domain *d,
     if ( paging_mode_hap(d) )
         info->flags |=3D XEN_DOMINF_hap;
=20
-    info->arch_config.emulation_flags =3D d->arch.emulation_flags;
+    info->arch_config.emulation_flags =3D d->emulation_flags;
     info->gpaddr_bits =3D hap_paddr_bits;
 }
=20
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/d=
omain.h
index 8c0dea12a5..eafd5cfc90 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -455,9 +455,6 @@ struct arch_domain
=20
     /* Don't unconditionally inject #GP for unhandled MSRs. */
     bool msr_relaxed;
-
-    /* Emulated devices enabled bitmap. */
-    uint32_t emulation_flags;
 } __cacheline_aligned;
=20
 #ifdef CONFIG_HVM
@@ -494,17 +491,17 @@ struct arch_domain
                                  X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
                                  X86_EMU_VPCI)
=20
-#define has_vlapic(d)      (!!((d)->arch.emulation_flags & X86_EMU_LAPIC))
-#define has_vhpet(d)       (!!((d)->arch.emulation_flags & X86_EMU_HPET))
-#define has_vpm(d)         (!!((d)->arch.emulation_flags & X86_EMU_PM))
-#define has_vrtc(d)        (!!((d)->arch.emulation_flags & X86_EMU_RTC))
-#define has_vioapic(d)     (!!((d)->arch.emulation_flags & X86_EMU_IOAPIC)=
)
-#define has_vpic(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIC))
-#define has_vvga(d)        (!!((d)->arch.emulation_flags & X86_EMU_VGA))
-#define has_viommu(d)      (!!((d)->arch.emulation_flags & X86_EMU_IOMMU))
-#define has_vpit(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIT))
-#define has_pirq(d)        (!!((d)->arch.emulation_flags & X86_EMU_USE_PIR=
Q))
-#define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
+#define has_vlapic(d)      (!!((d)->emulation_flags & X86_EMU_LAPIC))
+#define has_vhpet(d)       (!!((d)->emulation_flags & X86_EMU_HPET))
+#define has_vpm(d)         (!!((d)->emulation_flags & X86_EMU_PM))
+#define has_vrtc(d)        (!!((d)->emulation_flags & X86_EMU_RTC))
+#define has_vioapic(d)     (!!((d)->emulation_flags & X86_EMU_IOAPIC))
+#define has_vpic(d)        (!!((d)->emulation_flags & X86_EMU_PIC))
+#define has_vvga(d)        (!!((d)->emulation_flags & X86_EMU_VGA))
+#define has_viommu(d)      (!!((d)->emulation_flags & X86_EMU_IOMMU))
+#define has_vpit(d)        (!!((d)->emulation_flags & X86_EMU_PIT))
+#define has_pirq(d)        (!!((d)->emulation_flags & X86_EMU_USE_PIRQ))
+#define has_vpci(d)        (!!((d)->emulation_flags & X86_EMU_VPCI))
=20
 #define gdt_ldt_pt_idx(v) \
       ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 0bb842ec00..cd731452ba 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -306,6 +306,7 @@ static void cf_check dump_domains(unsigned char key)
             if ( test_bit(i, &d->watchdog_inuse_map) )
                 printk("    watchdog %d expires in %d seconds\n",
                        i, (u32)((d->watchdog_timer[i].expires - NOW()) >> =
30));
+        printk("    emulation_flags %#x\n", d->emulation_flags);
=20
         arch_dump_domain_info(d);
=20
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 559d201e0c..dc4f917664 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -651,6 +651,8 @@ struct domain
     unsigned int num_llc_colors;
     const unsigned int *llc_colors;
 #endif
+
+    uint32_t emulation_flags;
 } __aligned(PAGE_SIZE);
=20
 static inline struct page_list_head *page_to_list(
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 28 21:02:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 21:02:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999520.1380168 (Exim 4.92)
	(envelope-from )
	id 1uKNud-0000D3-OI; Wed, 28 May 2025 21:02:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999520.1380168; Wed, 28 May 2025 21:02: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 1uKNud-0000Cu-Lf; Wed, 28 May 2025 21:02:11 +0000
Received: by outflank-mailman (input) for mailman id 999520;
 Wed, 28 May 2025 21:02:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKNuc-00084W-7Z
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 21:02:10 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 04508caa-3c07-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 23:02:08 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 04508caa-3c07-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=mcoua5s7i5erhbt667iysmxily.protonmail; t=1748466127; x=1748725327;
	bh=cHHOdTy5EFK7A79iLpnssX6DJ9sNyVrgM7kUXje4urU=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=IKYQWgL5IinOPg1cyM6xmwl0wCFwnwJXDqRYINthCQvgpKqieO1RYM2LxKdK3eDoG
	 GJw1urJHwKeAzp3P6NtoiaJf2yQLQmpwoLLBQyh0ddKCUOAomckQY9W6boBZxQaRUg
	 Gg8f2ekjoFEZzFnjOHnKS4X1+OrSl2CbIvG636+O4jAK64IKgN/pwejnvA4ZZDzsOD
	 bi2B06opgiOQDEPXl7E+oEdsNmRN07/GGUNBB7/H625CUxWQkNcWhz/hHGYeOEmw/t
	 HrD2550hnTqcFrd01gU+qiy23Gh1SV5gmmLvLloVFpsobdYGY6ejefu3bT3ORp24m4
	 yTKFw/bLVxeAw==
Date: Wed, 28 May 2025 21:02:00 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, Denis Mukhin 
Subject: [PATCH v3 2/2] xen/domain: rewrite emulation_flags_ok()
Message-ID: <20250528210139.2572609-3-dmukhin@ford.com>
In-Reply-To: <20250528210139.2572609-1-dmukhin@ford.com>
References: <20250528210139.2572609-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 3a13f18873a69d6870930b100f72de79d5936e4c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

From: Denis Mukhin 

Rewrite emulation_flags_ok() to simplify future modifications.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v2:
- addressed review feedback
- added some explanatory comments for emulation_flags_ok()
---
 xen/arch/x86/domain.c | 92 ++++++++++++++++++++++++++++++++++---------
 1 file changed, 74 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0363ccb384..1d41d26c4d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -743,32 +743,88 @@ int arch_sanitise_domain_config(struct xen_domctl_cre=
atedomain *config)
     return 0;
 }
=20
+/*
+ * Verify that the domain's emulation flags resolve to a supported configu=
ration.
+ *
+ * This ensures we only allow a known, safe subset of emulation combinatio=
ns
+ * (for both functionality and security). Arbitrary mixes are likely to ca=
use
+ * errors (e.g., null pointer dereferences).
+ *
+ * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XX=
X
+ * symbols.
+ */
 static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
 {
+    enum {
+        CAP_PV          =3D BIT(0, U),
+        CAP_HVM         =3D BIT(1, U),
+        CAP_HWDOM       =3D BIT(2, U),
+        CAP_DOMU        =3D BIT(3, U),
+    };
+    static const struct {
+        unsigned int caps;
+        uint32_t min;
+        uint32_t opt;
+    } configs[] =3D {
+#ifdef CONFIG_PV
+        /* PV */
+        {
+            .caps   =3D CAP_PV | CAP_DOMU,
+            .min    =3D 0,
+            .opt    =3D 0,
+        },
+
+        /* PV (likely dom0) */
+        {
+            .caps   =3D CAP_PV | CAP_HWDOM,
+            .min    =3D X86_EMU_PIT,
+            .opt    =3D 0,
+        },
+#endif /* #ifdef CONFIG_PV */
+
+#ifdef CONFIG_HVM
+        /* PVH dom0/domU or HVM domU */
+        {
+            .caps   =3D CAP_HVM | CAP_HWDOM,
+            .min    =3D X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
+            .opt    =3D 0,
+        },
+
+
+        /* HVM domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
+            /* HVM PIRQ feature is user-selectable. */
+            .opt    =3D X86_EMU_USE_PIRQ,
+        },
+
+        /* PVH */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_LAPIC,
+            .opt    =3D 0,
+        },
+#endif /* #ifdef CONFIG_HVM */
+    };
+    unsigned int i, caps =3D is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU;
+
+    if ( is_pv_domain(d) )
+        caps |=3D CAP_PV;
+    else if ( is_hvm_domain(d) )
+        caps |=3D CAP_HVM;
+
 #ifdef CONFIG_HVM
     /* This doesn't catch !CONFIG_HVM case but it is better than nothing *=
/
     BUILD_BUG_ON(X86_EMU_ALL !=3D XEN_X86_EMU_ALL);
 #endif
=20
-    if ( is_hvm_domain(d) )
-    {
-        if ( is_hardware_domain(d) &&
-             emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) =
)
-            return false;
-        if ( !is_hardware_domain(d) &&
-             /* HVM PIRQ feature is user-selectable. */
-             (emflags & ~X86_EMU_USE_PIRQ) !=3D
-             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
-             emflags !=3D X86_EMU_LAPIC )
-            return false;
-    }
-    else if ( emflags !=3D 0 && emflags !=3D X86_EMU_PIT )
-    {
-        /* PV or classic PVH. */
-        return false;
-    }
+    for ( i =3D 0; i < ARRAY_SIZE(configs); i++ )
+        if ( caps =3D=3D configs[i].caps &&
+             (emflags & ~configs[i].opt) =3D=3D configs[i].min )
+            return true;
=20
-    return true;
+    return false;
 }
=20
 void __init arch_init_idle_domain(struct domain *d)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 28 21:10:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 21:10:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999544.1380194 (Exim 4.92)
	(envelope-from )
	id 1uKO31-0002Yc-69; Wed, 28 May 2025 21:10:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999544.1380194; Wed, 28 May 2025 21: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 1uKO31-0002Wx-1l; Wed, 28 May 2025 21:10:51 +0000
Received: by outflank-mailman (input) for mailman id 999544;
 Wed, 28 May 2025 21:10:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKO2z-0002GV-UN
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 21:10:49 +0000
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [2a00:1450:4864:20::332])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3a06207b-3c08-11f0-b894-0df219b8e170;
 Wed, 28 May 2025 23:10:48 +0200 (CEST)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43cfa7e7f54so2253915e9.1
 for ; Wed, 28 May 2025 14:10:48 -0700 (PDT)
Received: from localhost.localdomain ([91.85.47.110])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4ef4f3aa3sm143910f8f.84.2025.05.28.14.10.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 28 May 2025 14:10: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" 
X-Inumbo-ID: 3a06207b-3c08-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748466647; x=1749071447; 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;
        bh=4epTKamhANvL6RVYcC/CjM64YkIz4kbtxUbryvO3zZs=;
        b=fm/GS5bnMYEjY7x0F1LpGU0+wAz7QJt/ZYpcLZnAn78W8Io7gfZJs5G9wTjp8gUr2O
         KrHZ7Le15NgnLdDDkOa5ZWtwrF+uK2VgD9+3bjXGmdcPyhiWcq/4R8TeFpRH3MJ/oidp
         3faBTBlCMpewlWJh2aQA6Ln1J6RD7wiC/P2xBO65CyVK/6Vx/qXVV4LGW+NeG6dicvQD
         SgCKgUr/+TBfY7hq8CowkD8E6yWISo5NAI39SJAZMiTP+zqcM64X2oq+jZiPGQSyzQUl
         OdDL5oQ1Wj5/bAbgQ9Y5VHnpzKQT1LxujYq44HDXGCKfj522vVO2RCDbJQYwk1n5k0/M
         VHKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748466647; x=1749071447;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=4epTKamhANvL6RVYcC/CjM64YkIz4kbtxUbryvO3zZs=;
        b=eGMWyX+xgVvePBOeTOr9xpVp/azqItQ22LP2ppQbyd2ONYiXwehuMrCYy5iaxi0ieI
         I40lqj+JdWRJnwvDuEwZ8B/2bLrhLqo17wYKJhfQ6k671zgpjG40nBdhiJEUmXFnvpL6
         4sWohQC5fWpJNSV8zCwHzLJaOf4VC6pjLkmIZ3V5iaUjcUawSNf5LK4priZLktrVpOm5
         x0TktxXb9/Ed3EYRy5FaDRFudd2x/toy/ERTyvaxocJLaH1ibfFTs/pXadkIKfxS/UcE
         eFlUAWGQKJmv9aedooMLumBSHe0Zngz5Cqf+Bf/C/5ssXX/HTTTLZQCzf6Qgo6ngYTGG
         ZuEA==
X-Gm-Message-State: AOJu0YwP63baVrO4iRXmvbXjqfnId4pYzEKr643u3reGAJTeBg8X/wkg
	7jyj51uPhvsLpjFaQA4vGgaXHCtZy9aO1rMbxYuna45EvnTu1sSJ7IukGITCtqRs
X-Gm-Gg: ASbGncvbn4LXUaSwiBukB47lMC0T811nBBGNroSme1xx6BY8xZCkqCd79svLaJ/rgG3
	vCoUHKW40ynqs2SMCLQcjRmT+flSKqMt+ISWYcXgV+gYDGXi/8QzPEn8wcdVg+p0yiMjyA/lLhH
	lqmLsVF0d/llOxAXHmuFY7Jt+QcQWaip9CsnzhsoryJo5S2483F7i40EW8ll6z5FY+R+jsWrSI9
	iiY33VYew/5dWbuJQk6aCFw90r5iyv2rr2EoKzmi6HOjHF/IJRowuXIDSyLT8BU2zeBdP8DkKYE
	X4izr65GcBiXezRilYplMkhgjbMiVeiEJ12kP1SC0rZ1d2dmlz8sb1N5+RvCJey3RUvVJny5+4A
	=
X-Google-Smtp-Source: AGHT+IHw+zffAXb/eGgelm9DAO/R8knFcy8nLEOmBm5+FANsVmbFgUrUKmzmAv/KL7fc4Yc7OSddgQ==
X-Received: by 2002:a05:600c:1e1c:b0:450:cabc:a6c6 with SMTP id 5b1f17b1804b1-450ce88131amr10823245e9.15.1748466646911;
        Wed, 28 May 2025 14:10:46 -0700 (PDT)
From: Christopher Clark 
To: xen-devel@lists.xenproject.org
Cc: Daniel Smith ,
	Rich Persaud ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 2/3] MAINTAINERS: add link and keyword statements for Argo section
Date: Wed, 28 May 2025 22:10:39 +0100
Message-Id: <20250528211040.10562-2-christopher.w.clark@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528211040.10562-1-christopher.w.clark@gmail.com>
References: <20250528211040.10562-1-christopher.w.clark@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add link to Argo documentation and to ensure that Argo maintainers and
reviewers are included in developments involving Argo, add keyword
expressions for Argo.

Signed-off-by: Christopher Clark 
---
 MAINTAINERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c11b82eca9..697f383505 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -223,9 +223,12 @@ F:	tools/libacpi/
 ARGO
 M:	Christopher Clark 
 S:	Maintained
+W:	https://wiki.xenproject.org/wiki/Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen
 F:	xen/include/public/argo.h
 F:	xen/include/xen/argo.h
 F:	xen/common/argo.c
+K:	\b(argo|Argo|ARGO)\b
+K:	(?i)argo[_-].*
 
 ARINC653 SCHEDULER
 M:	Nathan Studer 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 21:10:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 21:10:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999542.1380178 (Exim 4.92)
	(envelope-from )
	id 1uKO2z-0002Ev-HD; Wed, 28 May 2025 21:10:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999542.1380178; Wed, 28 May 2025 21:10: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 1uKO2z-0002Eo-EU; Wed, 28 May 2025 21:10:49 +0000
Received: by outflank-mailman (input) for mailman id 999542;
 Wed, 28 May 2025 21:10:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKO2y-0002Ed-GK
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 21:10:48 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 399f1543-3c08-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 23:10:47 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a4d33f971aso189658f8f.1
 for ; Wed, 28 May 2025 14:10:47 -0700 (PDT)
Received: from localhost.localdomain ([91.85.47.110])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4ef4f3aa3sm143910f8f.84.2025.05.28.14.10.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 28 May 2025 14:10: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" 
X-Inumbo-ID: 399f1543-3c08-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748466646; x=1749071446; 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;
        bh=877Qh42+jkY8cdr8W69/LgWDAPp4oF1qwK/ps88nv2w=;
        b=H87x3MLGiVJ6vkmNoLWaNukYD9g1oGiLPVvBk3YrV+lkmRqARUgEDQrZ1AvOyGFPUG
         nCESBbFXWYA0I9mMCLY1xOkxTxVKgdAjmsZzP2pazq1iQieL/9AS4eW6ogi/2jlDtTdm
         UtaKOB2Sd5bjWhPabqkobxSKoNY7meSk6OfG+ei8VKlzaCL5DUcsmMCoLLB0KpzJ3WTu
         P4o6Xesd/cugQFjeMMDFI+qRzdGNRe1YUbHAPaAsoxk6+d1XrBKUIzXz8y7E5MrGfT8+
         coF+rII1OQwaXWmh/aE/Kkt+iMa/yNsogrgxUCj76lK7S89+cqbHBFk9GWsV1QCLNTpa
         8wLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748466646; x=1749071446;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=877Qh42+jkY8cdr8W69/LgWDAPp4oF1qwK/ps88nv2w=;
        b=iNSXimvypDrhBHP0wA/aPZBVfBQTeODWcsiUmXw/uR+ocKdO2wD9sZLOhjUqrZB3n3
         rD1zQZ3/IF/qhupIRuLW0p4+1yQFEMPMB8+J4BTV240NT5TGMCTGH8msrJdeB1jQmXFS
         M4cX6veWbAZWYRIWFw0iIsEuhVAlRDK/PJViixH/EpkJ856s3m2sbY/+zk7ZhWmpog97
         CULB+ZDEBTxC0FF4Mzp82xdcAJkDw3uZzY8BDkRGJpeWgLfj/giKPEKuUGoh0ReUJVeU
         Oj1S0Mv/+RFDLHnPllspJ0ckhkMwf2bK640UAxVUmBvhvt+jtXqJKPA1xy2WpmlPDQWn
         6S7g==
X-Gm-Message-State: AOJu0Yxw9MAboMCkKJiS7CPpnC6ECvYWbY1LRhuI1P6gVwzsOKTiYL+r
	I92dnzy1vKZFn48qhRxiWSHsRP8wdXGEVWc6VioIXwczDI0k6gD2aPZgd1embMyJ
X-Gm-Gg: ASbGncs8z99RwA0ZQiTQ+dSUfqvyqH3vSCXiQt1r3dC6V0Q6fcCc1DFYc2YVoETam09
	yq19hXH9X+APCarXRV7Aykq65A5f5n9sIwTp763Q5y+9US+fVAq6uIKp4r1+JSRt4NFeNJO2ijR
	EU40Invu5pCmZODiZqMPY85pFsNhRO1IjHCIZRycie7YCyN97Genz4pL/0PQfSG/RGPX7Uw4w6J
	Nd2K3GJ2+qaJ8QoCfLG6UsiYC3+yS2ZjBcy4X3usNUZGdbj8ig0f+CS/Y2cICcIWxrX3xjy7BwU
	IbEtCcl8fq4UHVJeImgsd3SuviYsL7BXGimJdzB9rftKLWU/UifBjy/7RczELvr0mQUn6jmlnRU
	=
X-Google-Smtp-Source: AGHT+IEa+KeeVvXp6y4yzu1dcnTwLRlFU8CuyiBUzB06cq2FylipqWQgJDokiKcATuCO/eyo3T5MhA==
X-Received: by 2002:a05:6000:1a8e:b0:3a4:d367:c5aa with SMTP id ffacd0b85a97d-3a4e943c65dmr3436178f8f.20.1748466646138;
        Wed, 28 May 2025 14:10:46 -0700 (PDT)
From: Christopher Clark 
To: xen-devel@lists.xenproject.org
Cc: Daniel Smith ,
	Rich Persaud ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 1/3] docs: add documentation for Argo as a feature
Date: Wed, 28 May 2025 22:10:38 +0100
Message-Id: <20250528211040.10562-1-christopher.w.clark@gmail.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Adds approachable documentation describing system components and
introduces the support statement for feature status.

Signed-off-by: Christopher Clark 
---
 docs/features/argo-feature.pandoc | 99 +++++++++++++++++++++++++++++++
 1 file changed, 99 insertions(+)
 create mode 100644 docs/features/argo-feature.pandoc

diff --git a/docs/features/argo-feature.pandoc b/docs/features/argo-feature.pandoc
new file mode 100644
index 0000000000..b6a10be78a
--- /dev/null
+++ b/docs/features/argo-feature.pandoc
@@ -0,0 +1,99 @@
+% Argo interdomain communication
+% Revision 1
+
+\clearpage
+
+# Basics
+
+---------------- ----------------------------------------------------
+         Status: **Tech Preview**
+
+  Architectures: x86, ARM
+
+   Component(s): Hypervisor, guest
+---------------- ----------------------------------------------------
+
+# Overview
+
+Argo is a lightweight data transport for communication between virtual
+machines, with a simple hypervisor interface that is accessible for
+building embedded systems and designed to work with familiar primitives
+within guest OS kernels. It supports policy control over communication
+and isolation between VMs.
+
+# User details
+
+Argo is present in Xen, included since Xen 4.12. A Linux device driver
+and userspace library are available and Argo is regularly tested in the
+Xen Continuous Integration system.
+
+To configure a Xen system to enable Argo:
+
+* ensure that Argo is enabled in the hypervisor with KConfig option
+
+* enable Argo on the Xen hypervisor command line
+
+* load the Argo guest kernel device driver
+
+* ensure that the Argo guest libraries are installed
+
+The guest userspace libraries support software designed for Argo
+interfaces and also enables software designed for networks to
+communicate between VMs by Argo.  This allows platform software to be
+plumbed easily between virtual machines, without requiring networking
+and with system policy controls over this communication.
+
+# Technical details
+
+## Argo components
+
+* Xen: Argo in the hypervisor provides communication between virtual
+  machines.
+
+* Guest kernel: driver provides interfaces for data transport for use
+  within the kernel, and implements familiar abstractions for
+  networking software.
+
+* Guest libraries: provide application-level support for interdomain
+  communication.
+
+## Argo implementation within Xen
+
+See the public Xen headers for the primary interface documentation.
+
+# Limitations
+
+Argo has been developed and tested on x86 and ARM architectures.
+
+# Testing
+
+The Argo test developed for the Xen Test Framework provides coverage of
+the hypercall operations.
+
+The Xen Project CI provides system test coverage of an Argo-enabled Xen
+system with Linux.
+
+# Areas for improvement
+
+## Argo and VirtIO
+
+References to design documentation for the development of an Argo
+transport for VirtIO are available via:
+https://wiki.xenproject.org/wiki/Virtio_On_Xen
+
+# Known issues
+
+* For development: sysctl/domctls for toolstack to control per-VM access
+  to Argo
+
+# References
+
+See the ARGO section of the Xen MAINTAINERS document for web reference.
+
+# History
+
+------------------------------------------------------------------------
+Date       Revision Version   Notes
+---------- -------- --------- ------------------------------------------
+2025-05-28 1        Xen 4.12+ Feature included in Xen 4.12.
+---------- -------- --------- ------------------------------------------
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 21:10:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 21:10:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999543.1380188 (Exim 4.92)
	(envelope-from )
	id 1uKO30-0002Sa-O0; Wed, 28 May 2025 21:10:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999543.1380188; Wed, 28 May 2025 21:10: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 1uKO30-0002ST-Ks; Wed, 28 May 2025 21:10:50 +0000
Received: by outflank-mailman (input) for mailman id 999543;
 Wed, 28 May 2025 21:10:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKO2z-0002Ed-4A
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 21:10:49 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3a4dbba0-3c08-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 23:10:48 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43cfe574976so2660805e9.1
 for ; Wed, 28 May 2025 14:10:48 -0700 (PDT)
Received: from localhost.localdomain ([91.85.47.110])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4ef4f3aa3sm143910f8f.84.2025.05.28.14.10.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 28 May 2025 14:10:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3a4dbba0-3c08-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748466648; x=1749071448; 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;
        bh=Um4ciM1wf1r76488WPuGgT39VPFGzNQdLwM37kOyYP0=;
        b=arR5c779zr0WoC4C5PSj49InW7sWWO5pLHh1gcgB9ZjLJFZYoquyZ/ybnttWteXlBC
         iLRf84vZhhtfgznvu8GqAlArdJ9CZQryYDrxuJzYvghlGtFf/hHC1tDwbrTYb+OSUMNE
         rpxGRV2ABbXsccXsXVtqg3pECc7VmpjlCwz7nuT2AzZW3fHpugmV94Kp47xOhgFf6VwA
         hlsmhVX0/902/F3S2LB4pQM7jLOuKGxBU0pluqetEgxUEPyMW/7VKJpuGiKeAOfmjVWq
         c1JzczC29pfvKIHTlxzkXDQ+n6T9ab3mA3aGY6Bo2EE0zRaGabAjJI6aQAxgmokNO29S
         /VKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748466648; x=1749071448;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Um4ciM1wf1r76488WPuGgT39VPFGzNQdLwM37kOyYP0=;
        b=bHfkyI0ytT1WE3QJR8XC/HKFH/9YZKVfiODAAfDXn/78P6TVajjcdIhBp3sBnmf5Yx
         eLZIbkguktjgfgXJ/RlI2u67BTKj/Mr9kzyFP0+IabJ4sI0ozh610ZcMSS5Eb9VYWF3Q
         3UtEXVSnvzBkNKqg6tufVFUZHGgf1aKcmzlVRGf1hhLP1SVn+2X1s90n4MnLTcqf51oF
         ya62PAHOfe3Ct8pR/zoUn74ySnpGdq8mW7InEtOz9rLpHj/9vZQXfrqtMlPEGrUh+Ncb
         I8gcXhBvyylVLZDfG2wrNh5JhjBkCmVUU3dqUM3455JSi5CcgKfXkC1WBUEKKnPIkf6A
         tNHA==
X-Gm-Message-State: AOJu0YyKi6eOUDuMwnvxRLDaI2H3wWVbcC1mi8l9AhcN1tbAcn+16c5q
	02hsg987jGvoqQd4l/+4OH/WwkLy9tM6bG49BynO2XrGF0C1opKaF5fOljRtKhTk
X-Gm-Gg: ASbGnctgglA9Zke6wgoO4x+FNG9KiWMmen8i9l3AAWQoR1LW5vhRu9Mvvqr+ikw8Z7D
	FDrefLA4KghMiYaPJzYh7ImO4Q5+8nIAYn+XJaxI2vG7tbr2jpETXl2b9VDB8SzvRu0InKv/uAc
	wVk/i17EF8rsjFD7lG5DD3g/xaJ1Vv5NHqRE4UTMvzSgrQYehiD4s/odtUOPtR9G3g+LUYxOxte
	fJ9TFOBAM92z6xcwuGnrZJNF27PgYJhtZyNHu5uEfVBCpxPU9mCKve9nO+3u4L9nzpKT/ON9oj5
	btjQV959UW8UphmQKyyo4gEAVXJ2+2yi+hZ/Km5F82lecKTxsR1alngTV59f7YBc1YpVZ0WKyvX
	gtYQbfRsesw==
X-Google-Smtp-Source: AGHT+IF9hzN6IK9LWGC+wpyAGZqQfpFsDmwbmCvMJE+fk98v3fGV1lMGmW8S1N4hQg9DHNmxk/pUMQ==
X-Received: by 2002:a05:600c:a00e:b0:43c:fe90:1279 with SMTP id 5b1f17b1804b1-45077d424bbmr35272415e9.21.1748466647598;
        Wed, 28 May 2025 14:10:47 -0700 (PDT)
From: Christopher Clark 
To: xen-devel@lists.xenproject.org
Cc: Daniel Smith ,
	Rich Persaud ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 3/3] MAINTAINERS: add a reviewer for Argo
Date: Wed, 28 May 2025 22:10:40 +0100
Message-Id: <20250528211040.10562-3-christopher.w.clark@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250528211040.10562-1-christopher.w.clark@gmail.com>
References: <20250528211040.10562-1-christopher.w.clark@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Adding Daniel P. Smith as reviewer for the Argo subsystem.

Signed-off-by: Christopher Clark 
Acked-by: Stefano Stabellini 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 697f383505..6b129704fc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -222,6 +222,7 @@ F:	tools/libacpi/
 
 ARGO
 M:	Christopher Clark 
+R:	Daniel P. Smith 
 S:	Maintained
 W:	https://wiki.xenproject.org/wiki/Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen
 F:	xen/include/public/argo.h
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed May 28 21:17:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 21:17:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999571.1380208 (Exim 4.92)
	(envelope-from )
	id 1uKO9e-0003wx-Qs; Wed, 28 May 2025 21:17:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999571.1380208; Wed, 28 May 2025 21:17:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKO9e-0003wq-Nj; Wed, 28 May 2025 21:17:42 +0000
Received: by outflank-mailman (input) for mailman id 999571;
 Wed, 28 May 2025 21:17:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKO9d-0003wk-Fn
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 21:17:41 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2f6541a0-3c09-11f0-a2fe-13f23c93f187;
 Wed, 28 May 2025 23:17: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" 
X-Inumbo-ID: 2f6541a0-3c09-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748467058; x=1748726258;
	bh=ErLwzxBQTVyhRVaY+zSrGgzb0yQIjH/IbyQk7822lpQ=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=jx3bDu99x5SbC2Nrqya8eEeb/8JHK35/mETXnb5OC7Yd4tLTGaGzIJ7TZHqgc6Ldx
	 4X+wKugsQ9F4CpR778NnpDLqqZ7/R4aHgnNXbxHrCy2q3RdgSE4whiXvZSJK15Ww8g
	 ZnH9gcSD9AN8IimQ/Gc4xRUKla+xYUVeENJeJG53Fbj1vM+POZDc+gHwJvB/V0fm34
	 RXUaCLO+F12pY5ICmLBLsbmBoavmdFsrwcb2/Wlx2v4GNjY/N6glMhNTn2OAz2sbJS
	 F0zWUu6FZ0QRQwHYwvdRtxF8/T0DbFIpTDZCxoO6m205Xp361+ZtQ/3CdJ4WtGAX0f
	 Po7UEuaMFuhxw==
Date: Wed, 28 May 2025 21:17:33 +0000
To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v2 1/2] xen/domain: introduce non-x86 hardware emulation flags
Message-ID: 
In-Reply-To: 
References: <20250516022855.1146121-1-dmukhin@ford.com> <20250516022855.1146121-2-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 9b1149ee8da47a38f89914f1a9e437722ee6e8be
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 21, 2025 at 04:05:04PM +0200, Roger Pau Monn=C3=A9 wrote:
> On Fri, May 16, 2025 at 02:29:09AM +0000, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > Define per-architecture emulation_flags for configuring domain emulatio=
n
> > features.
> >
> > Print d->arch.emulation_flags from 'q' keyhandler for better traceabili=
ty
> > while debugging.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v1:
> > - dropped comments
> > ---
> >  xen/arch/arm/include/asm/domain.h   | 1 +
> >  xen/arch/ppc/include/asm/domain.h   | 1 +
> >  xen/arch/riscv/include/asm/domain.h | 1 +
> >  xen/common/keyhandler.c             | 1 +
> >  4 files changed, 4 insertions(+)
> >
> > diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/a=
sm/domain.h
> > index a3487ca713..70e6e7d49b 100644
> > --- a/xen/arch/arm/include/asm/domain.h
> > +++ b/xen/arch/arm/include/asm/domain.h
> > @@ -121,6 +121,7 @@ struct arch_domain
> >      void *tee;
> >  #endif
> >
> > +    uint32_t emulation_flags;
> >  }  __cacheline_aligned;
> >
> >  struct arch_vcpu
> > diff --git a/xen/arch/ppc/include/asm/domain.h b/xen/arch/ppc/include/a=
sm/domain.h
> > index 3a447272c6..001116a0ab 100644
> > --- a/xen/arch/ppc/include/asm/domain.h
> > +++ b/xen/arch/ppc/include/asm/domain.h
> > @@ -21,6 +21,7 @@ struct arch_vcpu {
> >
> >  struct arch_domain {
> >      struct hvm_domain hvm;
> > +    uint32_t emulation_flags;
> >  };
> >
> >  #include 
> > diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/inclu=
de/asm/domain.h
> > index c3d965a559..7bc242da55 100644
> > --- a/xen/arch/riscv/include/asm/domain.h
> > +++ b/xen/arch/riscv/include/asm/domain.h
> > @@ -18,6 +18,7 @@ struct arch_vcpu {
> >
> >  struct arch_domain {
> >      struct hvm_domain hvm;
> > +    uint32_t emulation_flags;
> >  };
> >
> >  #include 
> > diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> > index 0bb842ec00..73f5134b68 100644
> > --- a/xen/common/keyhandler.c
> > +++ b/xen/common/keyhandler.c
> > @@ -306,6 +306,7 @@ static void cf_check dump_domains(unsigned char key=
)
> >              if ( test_bit(i, &d->watchdog_inuse_map) )
> >                  printk("    watchdog %d expires in %d seconds\n",
> >                         i, (u32)((d->watchdog_timer[i].expires - NOW())=
 >> 30));
> > +        printk("    emulation_flags %#x\n", d->arch.emulation_flags);
> >
> >          arch_dump_domain_info(d);
>=20
> Hello,
>=20
> I think it might be easier to print emulation_flags in
> arch_dump_domain_info(), ideally it would be helpful if this could be
> printed in a user friendly way apart from the raw dump:
>=20
> printk("    emulation_flags:%s%s... (%#x)\n",
>        !d->arch.emulation_flags ? " none" : "",
>        has_vlapic(d) ? " lapic" : "", ...
>        d->arch.emulation_flags);

I moved emulation_flags to the common domain struct in v3 and I kept the
emulation_flags flags printout here in common dump_domains().

I will plumb the human-readable printout for x86 flags in the follow on pat=
ch.

>=20
> Regards, Roger.



From xen-devel-bounces@lists.xenproject.org Wed May 28 22:50:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 22:50:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999589.1380218 (Exim 4.92)
	(envelope-from )
	id 1uKPbk-0007QI-3D; Wed, 28 May 2025 22:50:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999589.1380218; Wed, 28 May 2025 22:50:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKPbk-0007QB-00; Wed, 28 May 2025 22:50:48 +0000
Received: by outflank-mailman (input) for mailman id 999589;
 Wed, 28 May 2025 22:50:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKPbh-0007Q4-Uz
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 22:50:47 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2fd31b43-3c16-11f0-a2fe-13f23c93f187;
 Thu, 29 May 2025 00:50: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" 
X-Inumbo-ID: 2fd31b43-3c16-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=gozt5ty2srbr7iekbeybklhxbm.protonmail; t=1748472642; x=1748731842;
	bh=4xf+LmT6akS66VcEUq/njEr17pXZWyC9MUI/+pKOsyc=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=Jp6+C5xbxbF3M7tuDsOIbpJTi5g2QgBJ5ajogEy2HCsayykROZZVpZ3NdpKCPBf2C
	 gNjkIaSUZ8g18aqUm8lli2GNa5XbIEdrjwV2rMh9ieM73VvXeeNn3gC+Pyv8phIKSo
	 qyuOIeujaGFTnewTiTEROHr8zZ4Cd/4FFTO+RrXOT9RIGmJH0CdGuamAdHcY3Cs7ad
	 ji4BAccPlOHAGXVD6uEY6GGtxuvAZeajrdKFf8dGKdvcPPGI6jT7KDMauykuf5liOp
	 cnCHTTL09eakicdsorBjvc2uEkwpnQLOyBuebMnOwH7rn/TE1xHEhFOn+x9aitmyX6
	 oNv+4OzF2Uyow==
Date: Wed, 28 May 2025 22:50:36 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com
Subject: [PATCH v9 0/3] xen/domain: domain ID allocation
Message-ID: <20250528225030.2652166-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: f7bbdb93da407e5db9459fb89a33de37dce30cca
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The patch series adds new library calls for allocating domain IDs.

Patch 1 introduces new domid_{alloc,free} calls.
Patch 2 adjusts hardware domain ID treatment on Arm.
Patch 3 is an RFC: introduces new CONFIG_MAX_DOMID parameter to limit the
number of user domains during run-time.

Link to v8: https://lore.kernel.org/xen-devel/20250521000024.2944685-1-dmuk=
hin@ford.com/
Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1=
841666928

Denis Mukhin (3):
  xen/domain: unify domain ID allocation
  xen/domain: adjust domain ID allocation for Arm
  xen/domain: introduce CONFIG_MAX_DOMID

 xen/arch/arm/domain_build.c             | 17 +++++--
 xen/arch/x86/cpu/mcheck/mce.c           |  2 +-
 xen/arch/x86/cpu/vpmu.c                 |  2 +-
 xen/arch/x86/setup.c                    | 11 +++--
 xen/common/Kconfig                      |  8 ++++
 xen/common/device-tree/dom0less-build.c | 17 ++++---
 xen/common/domain.c                     | 62 +++++++++++++++++++++++--
 xen/common/domctl.c                     | 42 ++---------------
 xen/common/sched/core.c                 |  4 +-
 xen/drivers/passthrough/vtd/iommu.c     |  2 +-
 xen/include/xen/domain.h                |  3 ++
 11 files changed, 107 insertions(+), 63 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 28 22:50:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 22:50:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999590.1380227 (Exim 4.92)
	(envelope-from )
	id 1uKPbp-0007ec-9k; Wed, 28 May 2025 22:50:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999590.1380227; Wed, 28 May 2025 22:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKPbp-0007eV-73; Wed, 28 May 2025 22:50:53 +0000
Received: by outflank-mailman (input) for mailman id 999590;
 Wed, 28 May 2025 22:50:52 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKPbo-0007Q4-Ag
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 22:50:52 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 343bcc51-3c16-11f0-a2fe-13f23c93f187;
 Thu, 29 May 2025 00:50:51 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 343bcc51-3c16-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748472650; x=1748731850;
	bh=OmwWZUMOFbeDlcERUII2QytwMkWMS1f8cvzQGoMCA6c=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=dmBySYL2pYDEf0Lr7NuwQDbUYpPfJcJw87u+62oNsbw9s0QwkYEeehE+CItGOwsp0
	 BI56mrI6rMbquwzubxhkcB0VprWnHDDq7e8CarAnaHP5OtPFJPQz61vdzpjnTsb21D
	 H9lqdhEEJTyotf7AcQoNHrVZneK1O2YGKhGBEqrZcU1w+Vsed2Ak+mlvwoUnXz/vmU
	 tTxTg6T/Gx7IThwnJwAd6CP7MrvzS4086H4B+AfHYOqSI53TPWGoa5Q3RICaiWhu5X
	 RZc+RmgAK/dOt+8FGWMWPouVQSzgZcR/FOIrdlY08HEnKOe79ny8/8Xadx6pXPiCas
	 +8unizC47uBYA==
Date: Wed, 28 May 2025 22:50:45 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, Denis Mukhin 
Subject: [PATCH v9 1/3] xen/domain: unify domain ID allocation
Message-ID: <20250528225030.2652166-2-dmukhin@ford.com>
In-Reply-To: <20250528225030.2652166-1-dmukhin@ford.com>
References: <20250528225030.2652166-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: d78e53a68a44557a4dda5353d3ec2dfd93671e7c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

From: Denis Mukhin 

Currently, hypervisor code has two different domain ID allocation
implementations:

  (a) Sequential IDs allocation in dom0less Arm code based on max_init_domi=
d;

  (b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
      max_init_domid (both Arm and x86).

The domain ID allocation covers dom0 or late hwdom, predefined domains,
post-boot domains, excluding Xen system domains (domid >=3D
DOMID_FIRST_RESERVED).

It makes sense to have a common helper code for such task across architectu=
res
(Arm and x86) and between dom0less / toolstack domU allocation.

Wrap the domain ID allocation as an arch-independent function domid_alloc()=
 in
common/domain.c based on the bitmap.

Allocation algorithm:
- If an explicit domain ID is provided, verify its availability and use it =
if
  ID is not used;
- If DOMID_INVALID is provided, search the range [0..DOMID_FIRST_RESERVED-1=
],
  starting from the last used ID and wrapping around as needed. It guarante=
es
  that two consecutive calls will never return the same ID. ID#0 is exclude=
d
  to account for late hwdom case.

Also, remove is_free_domid() helper as it is not needed now.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v8:
- skip ID #0 in domid_alloc() to account for late hwdom
---
 xen/arch/arm/domain_build.c             | 17 +++++---
 xen/arch/x86/setup.c                    | 11 +++--
 xen/common/device-tree/dom0less-build.c | 10 +++--
 xen/common/domain.c                     | 54 +++++++++++++++++++++++++
 xen/common/domctl.c                     | 42 +++----------------
 xen/include/xen/domain.h                |  3 ++
 6 files changed, 87 insertions(+), 50 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..e9d563c269 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2010,6 +2010,7 @@ void __init create_dom0(void)
         .grant_opts =3D XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
     };
     unsigned int flags =3D CDF_privileged | CDF_hardware;
+    domid_t domid;
     int rc;
=20
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
@@ -2034,19 +2035,25 @@ void __init create_dom0(void)
     if ( !llc_coloring_enabled )
         flags |=3D CDF_directmap;
=20
-    dom0 =3D domain_create(0, &dom0_cfg, flags);
+    domid =3D domid_alloc(0);
+    if ( domid =3D=3D DOMID_INVALID )
+        panic("Error allocating domain ID 0\n");
+
+    dom0 =3D domain_create(domid, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
-        panic("Error creating domain 0 (rc =3D %ld)\n", PTR_ERR(dom0));
+        panic("Error creating domain %d (rc =3D %ld)\n", domid, PTR_ERR(do=
m0));
=20
     if ( llc_coloring_enabled && (rc =3D dom0_set_llc_colors(dom0)) )
-        panic("Error initializing LLC coloring for domain 0 (rc =3D %d)\n"=
, rc);
+        panic("Error initializing LLC coloring for domain %pd (rc =3D %d)\=
n",
+              dom0, rc);
=20
     if ( alloc_dom0_vcpu0(dom0) =3D=3D NULL )
-        panic("Error creating domain 0 vcpu0\n");
+        panic("Error creating domain %pdv0\n", dom0);
=20
     rc =3D construct_dom0(dom0);
     if ( rc )
-        panic("Could not set up DOM0 guest OS (rc =3D %d)\n", rc);
+        panic("Could not set up guest OS for domain %pd (rc =3D %d)\n",
+              dom0, rc);
=20
     set_xs_domain(dom0);
 }
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1f5cb67bd0..b36ce4491b 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1031,8 +1031,11 @@ static struct domain *__init create_dom0(struct boot=
_info *bi)
     if ( iommu_enabled )
         dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu;
=20
-    /* Create initial domain.  Not d0 for pvshim. */
-    bd->domid =3D get_initial_domain_id();
+    /* Allocate initial domain ID. Not d0 for pvshim. */
+    bd->domid =3D domid_alloc(get_initial_domain_id());
+    if ( bd->domid =3D=3D DOMID_INVALID )
+        panic("Error allocating domain ID %d\n", get_initial_domain_id());
+
     d =3D domain_create(bd->domid, &dom0_cfg,
                       pv_shim ? 0 : CDF_privileged | CDF_hardware);
     if ( IS_ERR(d) )
@@ -1064,7 +1067,7 @@ static struct domain *__init create_dom0(struct boot_=
info *bi)
=20
         if ( (strlen(acpi_param) =3D=3D 0) && acpi_disabled )
         {
-            printk("ACPI is disabled, notifying Domain 0 (acpi=3Doff)\n");
+            printk("ACPI is disabled, notifying domain %pd (acpi=3Doff)\n"=
, d);
             safe_strcpy(acpi_param, "off");
         }
=20
@@ -1079,7 +1082,7 @@ static struct domain *__init create_dom0(struct boot_=
info *bi)
=20
     bd->d =3D d;
     if ( construct_dom0(bd) !=3D 0 )
-        panic("Could not construct domain 0\n");
+        panic("Could not construct domain %pd\n", d);
=20
     bd->cmdline =3D NULL;
     xfree(cmdline);
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index 39cb2cd5c7..a509f8fecd 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -850,15 +850,13 @@ void __init create_domUs(void)
         struct xen_domctl_createdomain d_cfg =3D {0};
         unsigned int flags =3D 0U;
         bool has_dtb =3D false;
+        domid_t domid;
         uint32_t val;
         int rc;
=20
         if ( !dt_device_is_compatible(node, "xen,domain") )
             continue;
=20
-        if ( (max_init_domid + 1) >=3D DOMID_FIRST_RESERVED )
-            panic("No more domain IDs available\n");
-
         d_cfg.max_evtchn_port =3D 1023;
         d_cfg.max_grant_frames =3D -1;
         d_cfg.max_maptrack_frames =3D -1;
@@ -981,7 +979,11 @@ void __init create_domUs(void)
          * very important to use the pre-increment operator to call
          * domain_create() with a domid > 0. (domid =3D=3D 0 is reserved f=
or Dom0)
          */
-        d =3D domain_create(++max_init_domid, &d_cfg, flags);
+        domid =3D domid_alloc(++max_init_domid);
+        if ( domid =3D=3D DOMID_INVALID )
+            panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
+
+        d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
             panic("Error creating domain %s (rc =3D %ld)\n",
                   dt_node_name(node), PTR_ERR(d));
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..ae0c44fcbb 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -66,6 +66,10 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
 static struct domain *domain_hash[DOMAIN_HASH_SIZE];
 struct domain *domain_list;
=20
+/* Non-system domain ID allocator. */
+static DEFINE_SPINLOCK(domid_lock);
+static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
+
 /*
  * Insert a domain into the domlist/hash.  This allows the domain to be lo=
oked
  * up by domid, and therefore to be the subject of hypercalls/etc.
@@ -1449,6 +1453,8 @@ void domain_destroy(struct domain *d)
=20
     TRACE_TIME(TRC_DOM0_DOM_REM, d->domain_id);
=20
+    domid_free(d->domain_id);
+
     /* Remove from the domlist/hash. */
     domlist_remove(d);
=20
@@ -2405,6 +2411,54 @@ domid_t get_initial_domain_id(void)
     return hardware_domid;
 }
=20
+domid_t domid_alloc(domid_t domid)
+{
+    spin_lock(&domid_lock);
+
+    if ( domid < DOMID_FIRST_RESERVED )
+    {
+        if ( __test_and_set_bit(domid, domid_bitmap) )
+            domid =3D DOMID_INVALID;
+    }
+    else
+    {
+        static domid_t domid_last;
+        /* NB: account for late hwdom case, skip ID#0 */
+        const domid_t reserved_domid =3D 0;
+        const bool reserved =3D __test_and_set_bit(reserved_domid, domid_b=
itmap);
+
+        domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED,
+                                   domid_last);
+
+        if ( domid =3D=3D DOMID_FIRST_RESERVED )
+            domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVE=
D, 0);
+
+        if ( domid =3D=3D DOMID_FIRST_RESERVED )
+        {
+            domid =3D DOMID_INVALID;
+        }
+        else
+        {
+            __set_bit(domid, domid_bitmap);
+            domid_last =3D domid;
+        }
+
+        if ( !reserved )
+            __clear_bit(reserved_domid, domid_bitmap);
+    }
+
+    spin_unlock(&domid_lock);
+
+    return domid;
+}
+
+void domid_free(domid_t domid)
+{
+    spin_lock(&domid_lock);
+    __clear_bit(domid, domid_bitmap);
+    spin_unlock(&domid_lock);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index bfe2e1f9f0..8ef0c147c9 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -49,20 +49,6 @@ static int xenctl_bitmap_to_nodemask(nodemask_t *nodemas=
k,
                                    MAX_NUMNODES);
 }
=20
-static inline int is_free_domid(domid_t dom)
-{
-    struct domain *d;
-
-    if ( dom >=3D DOMID_FIRST_RESERVED )
-        return 0;
-
-    if ( (d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL )
-        return 1;
-
-    rcu_unlock_domain(d);
-    return 0;
-}
-
 void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info=
)
 {
     struct vcpu *v;
@@ -421,36 +407,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u=
_domctl)
=20
     case XEN_DOMCTL_createdomain:
     {
-        domid_t        dom;
-        static domid_t rover =3D 0;
+        domid_t domid =3D domid_alloc(op->domain);
=20
-        dom =3D op->domain;
-        if ( (dom > 0) && (dom < DOMID_FIRST_RESERVED) )
+        if ( domid =3D=3D DOMID_INVALID )
         {
             ret =3D -EEXIST;
-            if ( !is_free_domid(dom) )
-                break;
-        }
-        else
-        {
-            for ( dom =3D rover + 1; dom !=3D rover; dom++ )
-            {
-                if ( dom =3D=3D DOMID_FIRST_RESERVED )
-                    dom =3D 1;
-                if ( is_free_domid(dom) )
-                    break;
-            }
-
-            ret =3D -ENOMEM;
-            if ( dom =3D=3D rover )
-                break;
-
-            rover =3D dom;
+            break;
         }
=20
-        d =3D domain_create(dom, &op->u.createdomain, false);
+        d =3D domain_create(domid, &op->u.createdomain, false);
         if ( IS_ERR(d) )
         {
+            domid_free(domid);
             ret =3D PTR_ERR(d);
             d =3D NULL;
             break;
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index e10baf2615..8aab05ae93 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -38,6 +38,9 @@ void arch_get_domain_info(const struct domain *d,
=20
 domid_t get_initial_domain_id(void);
=20
+domid_t domid_alloc(domid_t domid);
+void domid_free(domid_t domid);
+
 /* CDF_* constant. Internal flags for domain creation. */
 /* Is this a privileged domain? */
 #define CDF_privileged           (1U << 0)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 28 22:50:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 22:50:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999591.1380238 (Exim 4.92)
	(envelope-from )
	id 1uKPbv-0007vh-Hp; Wed, 28 May 2025 22:50:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999591.1380238; Wed, 28 May 2025 22: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 1uKPbv-0007vW-Ev; Wed, 28 May 2025 22:50:59 +0000
Received: by outflank-mailman (input) for mailman id 999591;
 Wed, 28 May 2025 22:50:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKPbt-0007tz-TH
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 22:50:58 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 36b00870-3c16-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 00:50: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" 
X-Inumbo-ID: 36b00870-3c16-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=gdfsaiyzcbfupgnn6juwp67waq.protonmail; t=1748472653; x=1748731853;
	bh=Z/JvWCVHhSekNxhXX77FDFM+KKfoHa1i5v/UEaZpFV8=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=WZhRxnd2uCWaEjqQDes08jEY7QTgCEx/3Zilfdd82dVWX+nI8Em+zEyjXo3VqeyHP
	 TQemV8S9QAa/RKW3KqBpx/FXoBBKyjoSDwnGipsN5XmexL/HL+JrcKsPwBa0Y6rMoY
	 iiS6CNn66D/suV/KgtyXtJDeF8QrsYzND6wpBx6CDXCqoqGMpivw3ghBmaTfuMwd3t
	 itW4J9s2ASp69M6UhucXG/L5WZHiK0VgPtvIaAA01yp2uly/EjukSfTq/KMhw5BrJW
	 5E+1oaUbu1p9INLERPYFB32ZZyBO1y38reohsJu0a4hMortyZB8sQ3znoupiVVOIif
	 5wz0z4hIN308w==
Date: Wed, 28 May 2025 22:50:49 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, Denis Mukhin 
Subject: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
Message-ID: <20250528225030.2652166-3-dmukhin@ford.com>
In-Reply-To: <20250528225030.2652166-1-dmukhin@ford.com>
References: <20250528225030.2652166-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 98d2e0e7e4c3aa440e1df941fd653d8272b356b0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

From: Denis Mukhin 

Remove the hardcoded domain ID 0 allocation for hardware domain and replace=
 it
with a call to get_initial_domain_id() (returns the value of hardware_domid=
 on
Arm).

Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_domain_id=
()
ID is skipped during domain ID allocation to cover domU case in dom0less
configuration. That also fixes a potential issue with re-using ID#0 for dom=
Us
when get_initial_domain_id() returns non-zero.

Signed-off-by: Denis Mukhin 
---
Changes since v8:
- rebased=20
---
 xen/arch/arm/domain_build.c             | 4 ++--
 xen/common/device-tree/dom0less-build.c | 9 +++------
 xen/common/domain.c                     | 4 ++--
 3 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e9d563c269..0ad80b020a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2035,9 +2035,9 @@ void __init create_dom0(void)
     if ( !llc_coloring_enabled )
         flags |=3D CDF_directmap;
=20
-    domid =3D domid_alloc(0);
+    domid =3D domid_alloc(get_initial_domain_id());
     if ( domid =3D=3D DOMID_INVALID )
-        panic("Error allocating domain ID 0\n");
+        panic("Error allocating domain ID %d\n", get_initial_domain_id());
=20
     dom0 =3D domain_create(domid, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index a509f8fecd..9a6015f4ce 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -974,14 +974,11 @@ void __init create_domUs(void)
=20
         arch_create_domUs(node, &d_cfg, flags);
=20
-        /*
-         * The variable max_init_domid is initialized with zero, so here i=
t's
-         * very important to use the pre-increment operator to call
-         * domain_create() with a domid > 0. (domid =3D=3D 0 is reserved f=
or Dom0)
-         */
-        domid =3D domid_alloc(++max_init_domid);
+        domid =3D domid_alloc(DOMID_INVALID);
         if ( domid =3D=3D DOMID_INVALID )
             panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
+        if ( max_init_domid < domid )
+            max_init_domid =3D domid;
=20
         d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
diff --git a/xen/common/domain.c b/xen/common/domain.c
index ae0c44fcbb..129b4fcb37 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2423,8 +2423,8 @@ domid_t domid_alloc(domid_t domid)
     else
     {
         static domid_t domid_last;
-        /* NB: account for late hwdom case, skip ID#0 */
-        const domid_t reserved_domid =3D 0;
+        /* NB: account for late hwdom case */
+        const domid_t reserved_domid =3D get_initial_domain_id();
         const bool reserved =3D __test_and_set_bit(reserved_domid, domid_b=
itmap);
=20
         domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED,
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Wed May 28 22:51:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 28 May 2025 22:51:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999592.1380249 (Exim 4.92)
	(envelope-from )
	id 1uKPc4-0008Ll-06; Wed, 28 May 2025 22:51:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999592.1380249; Wed, 28 May 2025 22:51: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 1uKPc3-0008LD-Qz; Wed, 28 May 2025 22:51:07 +0000
Received: by outflank-mailman (input) for mailman id 999592;
 Wed, 28 May 2025 22:51:06 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKPc2-0007tz-Sh
 for xen-devel@lists.xenproject.org; Wed, 28 May 2025 22:51:06 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3c9addbd-3c16-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 00:51: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" 
X-Inumbo-ID: 3c9addbd-3c16-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=jyuo52idjzhdljhmxbj2pkmvci.protonmail; t=1748472664; x=1748731864;
	bh=Ism5zqoyp25HVyCSFsCPOuacHsymbgmA3mLoHwRNEeM=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=jQyjBnmrG0SwnHJiPVn01yU/w6/KmTNZhPWxjXe+6mxxwwmwVjmsauPv3GKoNPq68
	 n2RNpR2zGz/EOYo1tsugZOH04/IaJ4bErWIU9BqsM+np8YPbP7MJaDegUxvYAEUYIb
	 BnSr3q7O3u+UKCEPSTE6p47IlSrJffXWWbvIpUV6495pPvc/5E38/2RkPUanRXLJ3L
	 gA8+mhghVA4ClK1SPJwdnCvVnuxWdwdGuVnCUwdrSLLZcuwa/GN8KYIrhgeKk7zoZN
	 H7wu0OBUEZSRwqw8Hg0HCM5AgF+crFY7zmAnsVxFlsrMPAFVBqjY9q4wNDUb4c2NXN
	 xfFu4yc0ZchEw==
Date: Wed, 28 May 2025 22:50:57 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, dmukhin@ford.com, Denis Mukhin 
Subject: [PATCH v9 3/3] xen/domain: introduce CONFIG_MAX_DOMID
Message-ID: <20250528225030.2652166-4-dmukhin@ford.com>
In-Reply-To: <20250528225030.2652166-1-dmukhin@ford.com>
References: <20250528225030.2652166-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 14520f3a02d52d3de6bc444d5f814acc9862d8fa
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

From: Denis Mukhin 

Embedded deployments of Xen do not need to have support for more than dozen=
 of
domains.

Introduce build-time configuration option to limit the number of domains du=
ring
run-time.

Suggested-by: Julien Grall 
Signed-off-by: Denis Mukhin 
---
Changes since v8:
- dropped hunk w/ compile-time check for DOMID_FIRST_RESERVED
- updated CONFIG_MAX_DOMID explanation
- dropped public header file changes
---
 xen/arch/x86/cpu/mcheck/mce.c       |  2 +-
 xen/arch/x86/cpu/vpmu.c             |  2 +-
 xen/common/Kconfig                  |  8 ++++++++
 xen/common/domain.c                 | 20 +++++++++++---------
 xen/common/sched/core.c             |  4 ++--
 xen/drivers/passthrough/vtd/iommu.c |  2 +-
 6 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 1c348e557d..ee8ddd33b0 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1493,7 +1493,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc=
)
             d =3D rcu_lock_domain_by_any_id(mc_msrinject->mcinj_domid);
             if ( d =3D=3D NULL )
             {
-                if ( mc_msrinject->mcinj_domid >=3D DOMID_FIRST_RESERVED )
+                if ( mc_msrinject->mcinj_domid >=3D CONFIG_MAX_DOMID )
                     return x86_mcerr("do_mca inject: incompatible flag "
                                      "MC_MSRINJ_F_GPADDR with domain %d",
                                      -EINVAL, domid);
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index c28192ea26..67d423e088 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -174,7 +174,7 @@ void vpmu_do_interrupt(void)
      * in XENPMU_MODE_ALL, for everyone.
      */
     if ( (vpmu_mode & XENPMU_MODE_ALL) ||
-         (sampled->domain->domain_id >=3D DOMID_FIRST_RESERVED) )
+         (sampled->domain->domain_id >=3D CONFIG_MAX_DOMID) )
     {
         sampling =3D choose_hwdom_vcpu();
         if ( !sampling )
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 3d66d09397..ef083856b8 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -579,4 +579,12 @@ config BUDDY_ALLOCATOR_SIZE
 =09  Amount of memory reserved for the buddy allocator to serve Xen heap,
 =09  working alongside the colored one.
=20
+config MAX_DOMID
+=09int "Maximum domain ID"
+=09range 1 32752
+=09default 32752
+=09help
+=09  Specifies the maximum domain ID (dom0 or late hwdom, predefined
+=09  domains, post-boot domains, excluding Xen system domains).
+
 endmenu
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 129b4fcb37..87e5be35e5 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -68,7 +68,7 @@ struct domain *domain_list;
=20
 /* Non-system domain ID allocator. */
 static DEFINE_SPINLOCK(domid_lock);
-static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
+static DECLARE_BITMAP(domid_bitmap, CONFIG_MAX_DOMID);
=20
 /*
  * Insert a domain into the domlist/hash.  This allows the domain to be lo=
oked
@@ -154,7 +154,7 @@ int domain_init_states(void)
     ASSERT(rw_is_write_locked_by_me(¤t->domain->event_lock));
=20
     dom_state_changed =3D xvzalloc_array(unsigned long,
-                                       BITS_TO_LONGS(DOMID_FIRST_RESERVED)=
);
+                                       BITS_TO_LONGS(CONFIG_MAX_DOMID));
     if ( !dom_state_changed )
         return -ENOMEM;
=20
@@ -234,7 +234,7 @@ int get_domain_state(struct xen_domctl_get_domain_state=
 *info, struct domain *d,
     while ( dom_state_changed )
     {
         dom =3D find_first_bit(dom_state_changed, DOMID_MASK + 1);
-        if ( dom >=3D DOMID_FIRST_RESERVED )
+        if ( dom >=3D CONFIG_MAX_DOMID )
             break;
         if ( test_and_clear_bit(dom, dom_state_changed) )
         {
@@ -823,7 +823,7 @@ struct domain *domain_create(domid_t domid,
     /* Sort out our idea of is_hardware_domain(). */
     if ( (flags & CDF_hardware) || domid =3D=3D hardware_domid )
     {
-        if ( hardware_domid < 0 || hardware_domid >=3D DOMID_FIRST_RESERVE=
D )
+        if ( hardware_domid < 0 || hardware_domid >=3D CONFIG_MAX_DOMID )
             panic("The value of hardware_dom must be a valid domain ID\n")=
;
=20
         /* late_hwdom is only allowed for dom0. */
@@ -2413,9 +2413,11 @@ domid_t get_initial_domain_id(void)
=20
 domid_t domid_alloc(domid_t domid)
 {
+    BUILD_BUG_ON(DOMID_FIRST_RESERVED < CONFIG_MAX_DOMID);
+
     spin_lock(&domid_lock);
=20
-    if ( domid < DOMID_FIRST_RESERVED )
+    if ( domid < CONFIG_MAX_DOMID )
     {
         if ( __test_and_set_bit(domid, domid_bitmap) )
             domid =3D DOMID_INVALID;
@@ -2427,13 +2429,13 @@ domid_t domid_alloc(domid_t domid)
         const domid_t reserved_domid =3D get_initial_domain_id();
         const bool reserved =3D __test_and_set_bit(reserved_domid, domid_b=
itmap);
=20
-        domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED,
+        domid =3D find_next_zero_bit(domid_bitmap, CONFIG_MAX_DOMID,
                                    domid_last);
=20
-        if ( domid =3D=3D DOMID_FIRST_RESERVED )
-            domid =3D find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVE=
D, 0);
+        if ( domid =3D=3D CONFIG_MAX_DOMID )
+            domid =3D find_next_zero_bit(domid_bitmap, CONFIG_MAX_DOMID, 0=
);
=20
-        if ( domid =3D=3D DOMID_FIRST_RESERVED )
+        if ( domid =3D=3D CONFIG_MAX_DOMID )
         {
             domid =3D DOMID_INVALID;
         }
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 9043414290..f1bfb6f6a2 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -867,7 +867,7 @@ int sched_init_domain(struct domain *d, unsigned int po=
olid)
     int ret;
=20
     ASSERT(d->cpupool =3D=3D NULL);
-    ASSERT(d->domain_id < DOMID_FIRST_RESERVED);
+    ASSERT(d->domain_id < CONFIG_MAX_DOMID);
=20
     if ( (ret =3D cpupool_add_domain(d, poolid)) )
         return ret;
@@ -891,7 +891,7 @@ int sched_init_domain(struct domain *d, unsigned int po=
olid)
=20
 void sched_destroy_domain(struct domain *d)
 {
-    ASSERT(d->domain_id < DOMID_FIRST_RESERVED);
+    ASSERT(d->domain_id < CONFIG_MAX_DOMID);
=20
     if ( d->cpupool )
     {
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/=
vtd/iommu.c
index c55f02c97e..5df85ca629 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1509,7 +1509,7 @@ int domain_context_mapping_one(
=20
         prev_did =3D context_domain_id(lctxt);
         domid =3D did_to_domain_id(iommu, prev_did);
-        if ( domid < DOMID_FIRST_RESERVED )
+        if ( domid < CONFIG_MAX_DOMID )
             prev_dom =3D rcu_lock_domain_by_id(domid);
         else if ( pdev ? domid =3D=3D pdev->arch.pseudo_domid : domid > DO=
MID_MASK )
             prev_dom =3D rcu_lock_domain(dom_io);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Thu May 29 00:09:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 00:09:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999630.1380268 (Exim 4.92)
	(envelope-from )
	id 1uKQpf-0001Qv-LA; Thu, 29 May 2025 00:09:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999630.1380268; Thu, 29 May 2025 00: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 1uKQpf-0001Qo-ID; Thu, 29 May 2025 00:09:15 +0000
Received: by outflank-mailman (input) for mailman id 999630;
 Thu, 29 May 2025 00:09:14 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKQpe-0001DA-QT
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 00:09:14 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 273fd3e3-3c21-11f0-a2fe-13f23c93f187;
 Thu, 29 May 2025 02:09: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" 
X-Inumbo-ID: 273fd3e3-3c21-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748477353; x=1748736553;
	bh=tw28fhlor8Serb03KD5cH3qsKtDV4rrkKaWcHlVWAj0=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=gDeEiyvYljBZPniWbtkOUGUVP1oVbGUWyPOGYp0yoHc8kS69Qx5eK1XbBP+E/HnPz
	 dXdtG1EgpdO7ak6oX1KqMQO5ssw1+ZOEfuRSYSevRMUu2zKbAtOiZwm8im3AhFrhXN
	 fqiMIhV7wZ4KUNKZf8Hly6jPwOMy34LXDWH3tN0hIKbahkVvett8c8VWqKiBPAz6hF
	 HUGjGzqx0DIy1GUKwTvY1gqhgsNbGt7TFlJpMmqrbvEwz4aJguCM0TB695O4v9GxeR
	 hgJMBGhUOjCVZcv4Dk89GnTnRuvj3JyT/zN7doafCKfK1r/zAYk+6NJjb51vMp991b
	 L10WTihycEjAQ==
Date: Thu, 29 May 2025 00:09:07 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, Denis Mukhin 
Subject: [PATCH v4 1/4] xen/console: rename switch_serial_input() to console_switch_input()
Message-ID: <20250529000848.2675903-2-dmukhin@ford.com>
In-Reply-To: <20250529000848.2675903-1-dmukhin@ford.com>
References: <20250529000848.2675903-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: f34a96e7af543bd1c1a2afc5a551ab2565a02b8b
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

From: Denis Mukhin 

Update the function name as per naming notation in the console driver.

No functional change.

Signed-off-by: Denis Mukhin 
Acked-by: Jan Beulich 
---
Changes since v3:
- added A-b
---
 xen/drivers/char/console.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c15987f5bb..30701ae0b0 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -523,7 +523,7 @@ void console_put_domain(struct domain *d)
         rcu_unlock_domain(d);
 }
=20
-static void switch_serial_input(void)
+static void console_switch_input(void)
 {
     unsigned int next_rx =3D console_rx;
=20
@@ -617,7 +617,7 @@ static void cf_check serial_rx(char c)
         /* We eat CTRL- in groups of 3 to switch console inpu=
t. */
         if ( ++switch_code_count =3D=3D 3 )
         {
-            switch_serial_input();
+            console_switch_input();
             switch_code_count =3D 0;
         }
         return;
@@ -1171,7 +1171,7 @@ void __init console_endboot(void)
                             "toggle host/guest log level adjustment", 0);
=20
     /* Serial input is directed to DOM0 by default. */
-    switch_serial_input();
+    console_switch_input();
 }
=20
 int __init console_has(const char *device)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Thu May 29 00:09:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 00:09:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999629.1380257 (Exim 4.92)
	(envelope-from )
	id 1uKQpe-0001DN-Ea; Thu, 29 May 2025 00:09:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999629.1380257; Thu, 29 May 2025 00: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 1uKQpe-0001DG-C2; Thu, 29 May 2025 00:09:14 +0000
Received: by outflank-mailman (input) for mailman id 999629;
 Thu, 29 May 2025 00:09:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKQpb-0001DA-S6
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 00:09:12 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 24946ce1-3c21-11f0-a2fe-13f23c93f187;
 Thu, 29 May 2025 02:09: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" 
X-Inumbo-ID: 24946ce1-3c21-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748477348; x=1748736548;
	bh=fXnq4428mtXJJTvN8RDXljIOFAvdt9NLb3tDvOQykf0=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=PXNCM5xrL0ef41Ny2K/+880cFfsVjGHJ/YgzqYeWcuorLbRJegKISxrlDoztqEtEA
	 +Ibbsg8bsg69gMjn5QiH39jGguZ/ttyRAaIfYO2LOKIpRd8Hwr2JaatoBuPjC2z2g2
	 rA0TatyL1MSOP3Uk09fE93WCJJtGTgE48bPOCezfG48awTalH3tGe/rdsrAIGliFdX
	 59OIWR5BkF40fGmdlNb1s0dMfK978p7mdSn53JLbcCW3BDdsYjH1WRvnB0iGXl07nk
	 wR+ynxZFv/STZYfsMSLsvHlT5IZCC7BS8SMdW6xjjcQ16KtSaT2cjSO7VhcktbYrdy
	 x0L9rIPhQnDeQ==
Date: Thu, 29 May 2025 00:08:58 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v4 0/4] xen/console: cleanup console input switch logic
Message-ID: <20250529000848.2675903-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: ccd94a3d72fd7dc839ba735fa2e7b99fb260556b
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The patch series originates from the NS16550 UART emulator series [1] (x86)
which requires ability to switch physical console input to a PVH/HVM domain
with an emulated UART.

Currently, on x86, console input can be rotated in round-robin manner only
between dom0, PV shim, and Xen itself. On Arm the input rotation can includ=
e
domUs with vpl011.

The main idea of this series is introducing a per-domain permission flag th=
at
is set during domain initialization and used by the console driver to switc=
h
the input across permitted domains.

Patch 1 performs rename of switch_serial_input() to fit the console driver
notation.

Patch 2 introduces a new domain permission flag to mark ownership of the
console input for the console driver.

Patch 3 cleans up the console input switch logic by removing dependency
on max_init_domid. Depends on patches 1, 2 and [2].

Patch 4 performs rename of console_rx to console_domid to match the usage
of the symbol in the code.

[1] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b3=
1d66c@ford.com/
[2] https://lore.kernel.org/xen-devel/20250528225030.2652166-1-dmukhin@ford=
.com/
[3] Link to v3: https://lore.kernel.org/xen-devel/20250519201211.1366244-1-=
dmukhin@ford.com/
[4] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1841674752

Denis Mukhin (4):
  xen/console: rename switch_serial_input() to console_switch_input()
  xen/console: introduce console input permission
  xen/console: remove max_init_domid dependency
  xen/console: rename console_rx to console_domid

 xen/arch/arm/include/asm/setup.h        |  2 -
 xen/arch/arm/setup.c                    |  2 -
 xen/arch/arm/vpl011.c                   |  2 +
 xen/arch/ppc/include/asm/setup.h        |  2 -
 xen/arch/riscv/include/asm/setup.h      |  2 -
 xen/arch/x86/include/asm/setup.h        |  2 -
 xen/arch/x86/pv/shim.c                  |  2 +
 xen/common/device-tree/dom0less-build.c |  2 -
 xen/common/domain.c                     | 31 ++++++++
 xen/drivers/char/console.c              | 96 +++++++++++--------------
 xen/include/xen/domain.h                |  1 +
 xen/include/xen/sched.h                 |  8 ++-
 12 files changed, 85 insertions(+), 67 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Thu May 29 00:09:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 00:09:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999631.1380278 (Exim 4.92)
	(envelope-from )
	id 1uKQpp-0001la-S5; Thu, 29 May 2025 00:09:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999631.1380278; Thu, 29 May 2025 00:09: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 1uKQpp-0001lO-PB; Thu, 29 May 2025 00:09:25 +0000
Received: by outflank-mailman (input) for mailman id 999631;
 Thu, 29 May 2025 00:09:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKQpo-0001jK-8V
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 00:09:24 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2c133c1b-3c21-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 02:09: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" 
X-Inumbo-ID: 2c133c1b-3c21-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=lap6eqxgx5h6fdnttjh5rukxzq.protonmail; t=1748477361; x=1748736561;
	bh=jzf21RiTT8DiWXO5zvxTBJmuSMKUTUDtUbb819XfgDE=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=BI6RG6gEcstpbcW2FLgfjj6FS6OhGEj+yoC8+SRVydf78gd6xTN88jiH5sOF7/FWX
	 3RZEfgYrwEh7C2ONW11Dj5hnKtf7qrOly0cNA6/1PHJSXmxpfcMouLTafbGwInD5CX
	 2kMbFKF2wU9OBra8ogt+jTwAAhFEKUcq9Fiq0hszhdMsT6e72438Nssy99NG0cERGU
	 lVAE3sraU2urqsfLMeE8Qrnz7cKlvt9Io+DAR8z4XUwGEgc6wq1AynynOl8OL/O68i
	 7Cl4i3l0ZEU5Fb243jhYFD0xIoI5ZB4sKcNSrpG1aBmbWRdwKcVi1mnrRRgiQIA62z
	 ErDh+IHKz3eSg==
Date: Thu, 29 May 2025 00:09:16 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, Denis Mukhin 
Subject: [PATCH v4 2/4] xen/console: introduce console input permission
Message-ID: <20250529000848.2675903-3-dmukhin@ford.com>
In-Reply-To: <20250529000848.2675903-1-dmukhin@ford.com>
References: <20250529000848.2675903-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 76aefcade98c859c86de15b7c2dd774b89ef8e98
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

From: Denis Mukhin 

Add new flag to domain structure for marking permission to intercept
the physical console input by the domain.

Update console input switch logic accordingly.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v3:
- rebased
---
 xen/arch/arm/vpl011.c      |  2 ++
 xen/arch/x86/pv/shim.c     |  2 ++
 xen/common/domain.c        |  2 ++
 xen/drivers/char/console.c | 18 +++++++++++++++++-
 xen/include/xen/sched.h    |  8 +++++++-
 5 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 66047bf33c..147958eee8 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -737,6 +737,8 @@ int domain_vpl011_init(struct domain *d, struct vpl011_=
init_info *info)
     register_mmio_handler(d, &vpl011_mmio_handler,
                           vpl011->base_addr, GUEST_PL011_SIZE, NULL);
=20
+    d->console.input_allowed =3D true;
+
     return 0;
=20
 out1:
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index c506cc0bec..bc2a7dd5fa 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -238,6 +238,8 @@ void __init pv_shim_setup_dom(struct domain *d, l4_pgen=
try_t *l4start,
      * guest from depleting the shim memory pool.
      */
     d->max_pages =3D domain_tot_pages(d);
+
+    d->console.input_allowed =3D true;
 }
=20
 static void write_start_info(struct domain *d)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 87e5be35e5..9bc66d80c4 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -835,6 +835,8 @@ struct domain *domain_create(domid_t domid,
         flags |=3D CDF_hardware;
         if ( old_hwdom )
             old_hwdom->cdf &=3D ~CDF_hardware;
+
+        d->console.input_allowed =3D true;
     }
=20
     /* Holding CDF_* internal flags. */
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 30701ae0b0..8a0bcff78f 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -512,9 +512,21 @@ static unsigned int __read_mostly console_rx =3D 0;
=20
 struct domain *console_get_domain(void)
 {
+    struct domain *d;
+
     if ( console_rx =3D=3D 0 )
             return NULL;
-    return rcu_lock_domain_by_id(console_rx - 1);
+
+    d =3D rcu_lock_domain_by_id(console_rx - 1);
+    if ( !d )
+        return NULL;
+
+    if ( d->console.input_allowed )
+        return d;
+
+    rcu_unlock_domain(d);
+
+    return NULL;
 }
=20
 void console_put_domain(struct domain *d)
@@ -551,6 +563,10 @@ static void console_switch_input(void)
         if ( d )
         {
             rcu_unlock_domain(d);
+
+            if ( !d->console.input_allowed )
+                break;
+
             console_rx =3D next_rx;
             printk("*** Serial input to DOM%u", domid);
             break;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 559d201e0c..e91c99a8f3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -512,7 +512,7 @@ struct domain
     bool             auto_node_affinity;
     /* Is this guest fully privileged (aka dom0)? */
     bool             is_privileged;
-    /* Can this guest access the Xen console? */
+    /* XSM: permission to use HYPERCALL_console_io hypercall */
     bool             is_console;
     /* Is this guest being debugged by dom0? */
     bool             debugger_attached;
@@ -651,6 +651,12 @@ struct domain
     unsigned int num_llc_colors;
     const unsigned int *llc_colors;
 #endif
+
+    /* Console settings. */
+    struct {
+        /* Permission to take ownership of the physical console input. */
+        bool input_allowed;
+    } console;
 } __aligned(PAGE_SIZE);
=20
 static inline struct page_list_head *page_to_list(
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Thu May 29 00:09:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 00:09:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999635.1380288 (Exim 4.92)
	(envelope-from )
	id 1uKQpz-0002EB-31; Thu, 29 May 2025 00:09:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999635.1380288; Thu, 29 May 2025 00:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKQpy-0002E0-Vs; Thu, 29 May 2025 00:09:34 +0000
Received: by outflank-mailman (input) for mailman id 999635;
 Thu, 29 May 2025 00:09:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKQpx-0001jK-No
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 00:09:33 +0000
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 320ad958-3c21-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 02:09: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" 
X-Inumbo-ID: 320ad958-3c21-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748477371; x=1748736571;
	bh=0skLNgJFjNJh5aiOVY4PUtt+98l4mBcX8VEDioGrAkY=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=kW0Y1HwSg4EyuYdrjhcKmBHgshW3wy/8GGay0okocuyMibHC9TFAT/knQlLP3pRpD
	 SlUux3jcm4I6C7Fz2QEKQdmsdncMmjA/VdB/XeQLngixhc/quEQ49fRVaMK9wAw1Wa
	 va9tKl8FpdddygOoW/2uYEZuagVYWtiiPKKB3ca56Vue15xn9AUmyZrvyrWTAajFdW
	 5ofIqtNv9C5++wM1C1IuWH+sUuTx6WX8q6ivJ01/16FOFFMibt6EdPOave3i2vLqWv
	 w9EoiD0fFZ/lUjZQm5gVxuigcQLjOPDNAgVynvYP4SJHcIDSXd+S7IP97Vh7+KPVlO
	 wGHbU9QcV77gQ==
Date: Thu, 29 May 2025 00:09:25 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, Denis Mukhin 
Subject: [PATCH v4 3/4] xen/console: remove max_init_domid dependency
Message-ID: <20250529000848.2675903-4-dmukhin@ford.com>
In-Reply-To: <20250529000848.2675903-1-dmukhin@ford.com>
References: <20250529000848.2675903-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 1405eefedef24d684aff73550bf670c2c67bffbe
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

From: Denis Mukhin 

The physical console input rotation depends on max_init_domid symbol, which=
 is
managed differently across architectures.

Instead of trying to manage max_init_domid in the arch-common code the cons=
ole
input rotation code can be reworked by removing dependency on max_init_domi=
d
entirely.

To do that, introduce domid_find_with_input_allowed() in arch-independent
location to find the ID of the next possible console owner domain. The IDs
are rotated across non-system domain IDs and DOMID_XEN.

Also, introduce helper console_set_domid() for updating identifier of the
current console input owner (points to Xen or domain).

Use domid_find_with_input_allowed() and console_set_domid() in
console_switch_input().

Remove uses of max_init_domid in the code.

Signed-off-by: Denis Mukhin 
---
Changes since v3:
- switched to RCU lock in domid_find_with_input_allowed()
---
 xen/arch/arm/include/asm/setup.h        |  2 -
 xen/arch/arm/setup.c                    |  2 -
 xen/arch/ppc/include/asm/setup.h        |  2 -
 xen/arch/riscv/include/asm/setup.h      |  2 -
 xen/arch/x86/include/asm/setup.h        |  2 -
 xen/common/device-tree/dom0less-build.c |  2 -
 xen/common/domain.c                     | 29 ++++++++
 xen/drivers/char/console.c              | 90 +++++++++----------------
 xen/include/xen/domain.h                |  1 +
 9 files changed, 61 insertions(+), 71 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/se=
tup.h
index 6cf272c160..f107e8eebb 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -25,8 +25,6 @@ struct map_range_data
     struct rangeset *irq_ranges;
 };
=20
-extern domid_t max_init_domid;
-
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
=20
 size_t estimate_efi_size(unsigned int mem_nr_banks);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 10b46d0684..53e2f8b537 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -61,8 +61,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
 bool __read_mostly acpi_disabled;
 #endif
=20
-domid_t __read_mostly max_init_domid;
-
 static __used void init_done(void)
 {
     int rc;
diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/se=
tup.h
index e4f64879b6..956fa6985a 100644
--- a/xen/arch/ppc/include/asm/setup.h
+++ b/xen/arch/ppc/include/asm/setup.h
@@ -1,6 +1,4 @@
 #ifndef __ASM_PPC_SETUP_H__
 #define __ASM_PPC_SETUP_H__
=20
-#define max_init_domid (0)
-
 #endif /* __ASM_PPC_SETUP_H__ */
diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/as=
m/setup.h
index c9d69cdf51..d1fc64b673 100644
--- a/xen/arch/riscv/include/asm/setup.h
+++ b/xen/arch/riscv/include/asm/setup.h
@@ -5,8 +5,6 @@
=20
 #include 
=20
-#define max_init_domid (0)
-
 void setup_mm(void);
=20
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/se=
tup.h
index ac34c69855..b67de8577f 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -69,6 +69,4 @@ extern bool opt_dom0_verbose;
 extern bool opt_dom0_cpuid_faulting;
 extern bool opt_dom0_msr_relaxed;
=20
-#define max_init_domid (0)
-
 #endif
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index 9a6015f4ce..703f20faed 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -977,8 +977,6 @@ void __init create_domUs(void)
         domid =3D domid_alloc(DOMID_INVALID);
         if ( domid =3D=3D DOMID_INVALID )
             panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
-        if ( max_init_domid < domid )
-            max_init_domid =3D domid;
=20
         d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 9bc66d80c4..704e0907e9 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2463,6 +2463,35 @@ void domid_free(domid_t domid)
     spin_unlock(&domid_lock);
 }
=20
+/*
+ * Find the ID of the next possible console owner domain.
+ *
+ * @return Domain ID: DOMID_XEN or non-system domain IDs within
+ * the range of [0..DOMID_FIRST_RESERVED-1].
+ */
+domid_t domid_find_with_input_allowed(domid_t hint)
+{
+    const struct domain *d;
+    domid_t domid =3D DOMID_XEN;
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for ( d =3D rcu_dereference(domain_list);
+          d && d->domain_id < DOMID_FIRST_RESERVED;
+          d =3D rcu_dereference(d->next_in_list) )
+    {
+        if ( d->console.input_allowed )
+        {
+            domid =3D d->domain_id;
+            break;
+        }
+    }
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    return domid;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a0bcff78f..37289d5558 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -498,26 +498,17 @@ static void cf_check conring_dump_keyhandler(unsigned=
 char key)
=20
 /*
  * CTRL- changes input direction, rotating among Xen, Dom0,
- * and the DomUs started from Xen at boot.
+ * and the DomUs.
  */
 #define switch_code (opt_conswitch[0]-'a'+1)
-/*
- * console_rx=3D0 =3D> input to xen
- * console_rx=3D1 =3D> input to dom0 (or the sole shim domain)
- * console_rx=3DN =3D> input to dom(N-1)
- */
-static unsigned int __read_mostly console_rx =3D 0;
=20
-#define max_console_rx (max_init_domid + 1)
+/* Console owner domain identifier. */
+static domid_t __read_mostly console_rx =3D DOMID_XEN;
=20
 struct domain *console_get_domain(void)
 {
-    struct domain *d;
+    struct domain *d =3D rcu_lock_domain_by_id(console_rx);
=20
-    if ( console_rx =3D=3D 0 )
-            return NULL;
-
-    d =3D rcu_lock_domain_by_id(console_rx - 1);
     if ( !d )
         return NULL;
=20
@@ -535,43 +526,14 @@ void console_put_domain(struct domain *d)
         rcu_unlock_domain(d);
 }
=20
-static void console_switch_input(void)
+static void console_set_domid(domid_t domid)
 {
-    unsigned int next_rx =3D console_rx;
+    if ( domid =3D=3D DOMID_XEN )
+        printk("*** Serial input to Xen");
+    else
+        printk("*** Serial input to DOM%u", domid);
=20
-    /*
-     * Rotate among Xen, dom0 and boot-time created domUs while skipping
-     * switching serial input to non existing domains.
-     */
-    for ( ; ; )
-    {
-        domid_t domid;
-        struct domain *d;
-
-        if ( next_rx++ >=3D max_console_rx )
-        {
-            console_rx =3D 0;
-            printk("*** Serial input to Xen");
-            break;
-        }
-
-        if ( consoled_is_enabled() && next_rx =3D=3D 1 )
-            domid =3D get_initial_domain_id();
-        else
-            domid =3D next_rx - 1;
-        d =3D rcu_lock_domain_by_id(domid);
-        if ( d )
-        {
-            rcu_unlock_domain(d);
-
-            if ( !d->console.input_allowed )
-                break;
-
-            console_rx =3D next_rx;
-            printk("*** Serial input to DOM%u", domid);
-            break;
-        }
-    }
+    console_rx =3D domid;
=20
     if ( switch_code )
         printk(" (type 'CTRL-%c' three times to switch input)",
@@ -579,12 +541,30 @@ static void console_switch_input(void)
     printk("\n");
 }
=20
+/*
+ * Switch console focus.
+ * Rotates input focus among Xen and domains with console input permission=
.
+ */
+static void console_switch_input(void)
+{
+    domid_t hint;
+
+    if ( console_rx =3D=3D DOMID_XEN )
+        hint =3D get_initial_domain_id();
+    else
+        hint =3D console_rx + 1;
+
+    hint =3D domid_find_with_input_allowed(hint);
+
+    console_set_domid(hint);
+}
+
 static void __serial_rx(char c)
 {
     struct domain *d;
     int rc =3D 0;
=20
-    if ( console_rx =3D=3D 0 )
+    if ( console_rx =3D=3D DOMID_XEN )
         return handle_keypress(c, false);
=20
     d =3D console_get_domain();
@@ -1169,14 +1149,6 @@ void __init console_endboot(void)
=20
     video_endboot();
=20
-    /*
-     * If user specifies so, we fool the switch routine to redirect input
-     * straight back to Xen. I use this convoluted method so we still prin=
t
-     * a useful 'how to switch' message.
-     */
-    if ( opt_conswitch[1] =3D=3D 'x' )
-        console_rx =3D max_console_rx;
-
     register_keyhandler('w', conring_dump_keyhandler,
                         "synchronously dump console ring buffer (dmesg)", =
0);
     register_irq_keyhandler('+', &do_inc_thresh,
@@ -1186,8 +1158,8 @@ void __init console_endboot(void)
     register_irq_keyhandler('G', &do_toggle_guest,
                             "toggle host/guest log level adjustment", 0);
=20
-    /* Serial input is directed to DOM0 by default. */
-    console_switch_input();
+    if ( opt_conswitch[1] !=3D 'x' )
+        (void)console_set_domid(get_initial_domain_id());
 }
=20
 int __init console_has(const char *device)
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 8aab05ae93..a88eb34f3f 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -36,6 +36,7 @@ void getdomaininfo(struct domain *d, struct xen_domctl_ge=
tdomaininfo *info);
 void arch_get_domain_info(const struct domain *d,
                           struct xen_domctl_getdomaininfo *info);
=20
+domid_t domid_find_with_input_allowed(domid_t hint);
 domid_t get_initial_domain_id(void);
=20
 domid_t domid_alloc(domid_t domid);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Thu May 29 00:09:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 00:09:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999641.1380298 (Exim 4.92)
	(envelope-from )
	id 1uKQq8-0002kw-Es; Thu, 29 May 2025 00:09:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999641.1380298; Thu, 29 May 2025 00:09: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 1uKQq8-0002kp-BW; Thu, 29 May 2025 00:09:44 +0000
Received: by outflank-mailman (input) for mailman id 999641;
 Thu, 29 May 2025 00:09:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKQq7-0001DA-3I
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 00:09:43 +0000
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch
 [79.135.106.29]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 37f7b94e-3c21-11f0-a2fe-13f23c93f187;
 Thu, 29 May 2025 02:09: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" 
X-Inumbo-ID: 37f7b94e-3c21-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=ghqaxxcv45cl7fyiznlbczu2yy.protonmail; t=1748477380; x=1748736580;
	bh=JV3YAPhRyMLPMXyY36U8GAXKlkqRXgyfF9gHz3Sj7r8=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=JkdCKkwAap68hjfQUGsajp7vqjGabcQCW2ufFZX7tEvrwejogKRPzad3cJp2viM3o
	 g4Jbv1wTU9sxneHrALz9Xwwx1VCp6MXLoy6s9BSUhCiqLNN1etiOdi+ZEzlNNQlEvb
	 Rv6aeDf+J7/t26GU1vuSpwldKI+TjXK2Y9VQ1HaU9hbWusTmFgR1iBda8fbvd0o4Dn
	 724PuqWNQindRpgHrEddrTexKhNVPOK360GIgS4Gn3O/uFa4emeMfOC8r/NYttLbLK
	 IkM5aAaHQ3ImPvSFBIVMZ8zmAKwg3KRHmIV7JMj2GjNioKJan1+vi5+WkHCTpnT7ws
	 XamyBnW1T0sng==
Date: Thu, 29 May 2025 00:09:34 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com, Denis Mukhin 
Subject: [PATCH v4 4/4] xen/console: rename console_rx to console_domid
Message-ID: <20250529000848.2675903-5-dmukhin@ford.com>
In-Reply-To: <20250529000848.2675903-1-dmukhin@ford.com>
References: <20250529000848.2675903-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: a91093b0d86f4203b791c35811867f46e38c951d
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

From: Denis Mukhin 

Update the symbol name to match the code better.

No functional change.

Signed-off-by: Denis Mukhin 
---
Changes since v3:
- rebased
---
 xen/drivers/char/console.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 37289d5558..5797f29d31 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -503,11 +503,11 @@ static void cf_check conring_dump_keyhandler(unsigned=
 char key)
 #define switch_code (opt_conswitch[0]-'a'+1)
=20
 /* Console owner domain identifier. */
-static domid_t __read_mostly console_rx =3D DOMID_XEN;
+static domid_t __read_mostly console_domid =3D DOMID_XEN;
=20
 struct domain *console_get_domain(void)
 {
-    struct domain *d =3D rcu_lock_domain_by_id(console_rx);
+    struct domain *d =3D rcu_lock_domain_by_id(console_domid);
=20
     if ( !d )
         return NULL;
@@ -533,7 +533,7 @@ static void console_set_domid(domid_t domid)
     else
         printk("*** Serial input to DOM%u", domid);
=20
-    console_rx =3D domid;
+    console_domid =3D domid;
=20
     if ( switch_code )
         printk(" (type 'CTRL-%c' three times to switch input)",
@@ -549,10 +549,10 @@ static void console_switch_input(void)
 {
     domid_t hint;
=20
-    if ( console_rx =3D=3D DOMID_XEN )
+    if ( console_domid =3D=3D DOMID_XEN )
         hint =3D get_initial_domain_id();
     else
-        hint =3D console_rx + 1;
+        hint =3D console_domid + 1;
=20
     hint =3D domid_find_with_input_allowed(hint);
=20
@@ -564,7 +564,7 @@ static void __serial_rx(char c)
     struct domain *d;
     int rc =3D 0;
=20
-    if ( console_rx =3D=3D DOMID_XEN )
+    if ( console_domid =3D=3D DOMID_XEN )
         return handle_keypress(c, false);
=20
     d =3D console_get_domain();
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Thu May 29 00:35:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 00:35:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999675.1380308 (Exim 4.92)
	(envelope-from )
	id 1uKREX-00076I-FI; Thu, 29 May 2025 00:34:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999675.1380308; Thu, 29 May 2025 00:34: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 1uKREX-00076B-CI; Thu, 29 May 2025 00:34:57 +0000
Received: by outflank-mailman (input) for mailman id 999675;
 Thu, 29 May 2025 00:34:57 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKREW-00075g-Ve
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 00:34:56 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bdc65578-3c24-11f0-a2fe-13f23c93f187;
 Thu, 29 May 2025 02:34:55 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 0BE484AC60;
 Thu, 29 May 2025 00:34:54 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92E8FC4CEE3;
 Thu, 29 May 2025 00:34: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" 
X-Inumbo-ID: bdc65578-3c24-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748478893;
	bh=9E+tUPglm98TAeqlfezwhuChyuy9OI2l/1fAH1GgeEY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=oPvmCondM85/MIBwtUCPaj1cvHy9qcoQ3+FO1k6VQihHayACPYmZ65EG9un2c4j0T
	 Qs3EnCP4duti8ERHnmfA4TLh51HT2iNBRm6szkQuqQpBDi9u/lHJ+3Gvmi8SYuGJvR
	 pn9kmsM5p7W1KRg7ranriQc2w+3/8e05MuIRPSdds1NsJRNo9vnLnpeQ70ZgQLizag
	 H2sCxYEA7qIY2d9anTWdd9mUqgiGgR4wUYXeTRxPt/Yb0uxkz88ifkj9pmhDK0AZBU
	 c6ZgafPp2aNcPzpjadfIHgsi7+ofnVtZqN7jJVSg8E6R/c89MHUtRqjB4ojUeDUiXp
	 L7dcnmoNFiQSQ==
Date: Wed, 28 May 2025 17:34:51 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "Edgar E. Iglesias" 
cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, 
    bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, 
    edgar.iglesias@amd.com, Anthony PERARD , 
    Juergen Gross 
Subject: Re: [PATCH v1 1/3] xen/arm: Add a way to disable traps on unmapped
 MMIO
In-Reply-To: <20250527195616.874614-2-edgar.iglesias@gmail.com>
Message-ID: 
References: <20250527195616.874614-1-edgar.iglesias@gmail.com> <20250527195616.874614-2-edgar.iglesias@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 27 May 2025, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Add a per-domain way to optionally disable traps on unmapped MMIO.
> 
> Signed-off-by: Edgar E. Iglesias 

The ARM changes look OK; I'll ack the next version when the option
becomes arch common as Andrew suggested


> ---
>  tools/libs/light/libxl_arm.c      |  3 +++
>  xen/arch/arm/dom0less-build.c     |  3 +++
>  xen/arch/arm/domain.c             |  2 ++
>  xen/arch/arm/domain_build.c       |  3 +++
>  xen/arch/arm/include/asm/domain.h |  2 ++
>  xen/arch/arm/io.c                 | 33 +++++++++++++++++++++++++++++--
>  xen/include/public/arch-arm.h     |  9 +++++++++
>  7 files changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index 75c811053c..40cd005619 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -233,6 +233,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>          config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
>      }
>  
> +    /* Trap accesses to unmapped MMIO. */
> +    config->arch.flags = XEN_ARM_TRAP_UNMAPPED_MMIO;
> +
>      return 0;
>  }
>  
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index a49764f0ad..e5e13e07d0 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -343,6 +343,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
>          panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
>  #endif
>      }
> +
> +    /* Trap accesses to unmapped MMIO. */
> +    d_cfg->arch.flags = XEN_ARM_TRAP_UNMAPPED_MMIO;
>  }
>  
>  int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 45aeb8bddc..54c6ae7678 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -714,6 +714,8 @@ int arch_domain_create(struct domain *d,
>      ioreq_domain_init(d);
>  #endif
>  
> +    d->arch.trap_unmapped_mmio = config->arch.flags & XEN_ARM_TRAP_UNMAPPED_MMIO;
> +
>      /* p2m_init relies on some value initialized by the IOMMU subsystem */
>      if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 )
>          goto fail;
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index b189a7cfae..c3c8212260 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2018,6 +2018,9 @@ void __init create_dom0(void)
>      dom0_cfg.arch.tee_type = tee_get_type();
>      dom0_cfg.max_vcpus = dom0_max_vcpus();
>  
> +    /* Dom0 always traps on unmapped MMIO.  */
> +    dom0_cfg.arch.flags |= XEN_ARM_TRAP_UNMAPPED_MMIO;
> +
>      if ( iommu_enabled )
>          dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
>  
> diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
> index a3487ca713..4d1a180ce2 100644
> --- a/xen/arch/arm/include/asm/domain.h
> +++ b/xen/arch/arm/include/asm/domain.h
> @@ -121,6 +121,8 @@ struct arch_domain
>      void *tee;
>  #endif
>  
> +    bool trap_unmapped_mmio;
> +
>  }  __cacheline_aligned;
>  
>  struct arch_vcpu
> diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> index 5a4b0e8f25..11ffa48969 100644
> --- a/xen/arch/arm/io.c
> +++ b/xen/arch/arm/io.c
> @@ -21,6 +21,32 @@
>  
>  #include "decode.h"
>  
> +/* Handler for unmapped ranges. Writes ignored, reads return all ones.  */
> +static int unmapped_read(struct vcpu *v, mmio_info_t *info, register_t *r,
> +                         void *priv)
> +{
> +    uint64_t mask = GENMASK_ULL((1U << info->dabt.size) * 8 - 1, 0);
> +
> +    /* Mask off upper bits.  */
> +    *r = UINT64_MAX & mask;
> +    return 1;
> +}
> +
> +static int unmapped_write(struct vcpu *v, mmio_info_t *info, register_t r,
> +                          void *priv)
> +{
> +    return 1;
> +}
> +
> +static const struct mmio_handler_ops unmapped_ops = {
> +    .read = unmapped_read,
> +    .write = unmapped_write
> +};
> +
> +static const struct mmio_handler unmapped_handler = {
> +    .ops = &unmapped_ops
> +};
> +
>  static enum io_state handle_read(const struct mmio_handler *handler,
>                                   struct vcpu *v,
>                                   mmio_info_t *info)
> @@ -178,8 +204,11 @@ enum io_state try_handle_mmio(struct cpu_user_regs *regs,
>          rc = try_fwd_ioserv(regs, v, info);
>          if ( rc == IO_HANDLED )
>              return handle_ioserv(regs, v);
> -
> -        return rc;
> +        else if ( rc == IO_UNHANDLED && !v->domain->arch.trap_unmapped_mmio ) {
> +            /* Fallback to the unmapped handler. */
> +            handler = &unmapped_handler;
> +        } else
> +            return rc;
>      }
>  
>      /*
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index e2412a1747..32b023504d 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -350,6 +350,15 @@ struct xen_arch_domainconfig {
>       *
>       */
>      uint32_t clock_frequency;
> +    /*
> +     * IN
> +     *
> +     * XEN_ARM_TRAP_UNMAPPED_MMIO enables trapping of memory accesses
> +     * into unmapped ranges. When disabled, Xen will handle the access
> +     * by reading 0xFFFFFFFF and ignoring writes.
> +     */
> +#define XEN_ARM_TRAP_UNMAPPED_MMIO (1U << 0)
> +    uint32_t flags;
>  };
>  #endif /* __XEN__ || __XEN_TOOLS__ */
>  
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Thu May 29 00:41:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 00:41:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999691.1380318 (Exim 4.92)
	(envelope-from )
	id 1uKRL3-0000Ja-49; Thu, 29 May 2025 00:41:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999691.1380318; Thu, 29 May 2025 00: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 1uKRL3-0000JT-1C; Thu, 29 May 2025 00:41:41 +0000
Received: by outflank-mailman (input) for mailman id 999691;
 Thu, 29 May 2025 00:41:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKRL2-0000JN-E4
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 00:41:40 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ada76993-3c25-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 02:41:38 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id A8E0D44ECF;
 Thu, 29 May 2025 00:41:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 664CBC4CEE3;
 Thu, 29 May 2025 00:41: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" 
X-Inumbo-ID: ada76993-3c25-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748479296;
	bh=ur7Sj8+z5iqkjlIcrw+vBOtDLzll8ASJfxE6g/Urfjg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=clfftEDFxTEd3qo+DVbp1lm+yrcewfjdWF8ZCWhc4l4/V60lM3jkI4TS5Hvi3MEpd
	 fkz/w3xwUCb3DhPFTKBvHZpslB4e+T0ZoPmLCMOhIVCCN1ZbQVIoejaqN0+tOmbiys
	 VCFe2o24wv43hUGyv9jwrh/fAfcwlmaLoUuQuoATNY2GmkFKde4OpivA73gUQFWIaZ
	 wHJ/8q8/YCRdtppypRkMKJsxrvIJAyyPn6xbWsvqcO0tEdTgIaOaKI9tcuEICWSNHn
	 oDJXvaI7xYBPZ5eIqMb3EBFS6YMJEbprUCaeebm4e+jmqccu9LUfJuBWOL/+VQVJJJ
	 GDu0r6aHTV4zA==
Date: Wed, 28 May 2025 17:41:34 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "Edgar E. Iglesias" 
cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, julien@xen.org, 
    bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, 
    edgar.iglesias@amd.com
Subject: Re: [PATCH v1 2/3] xen/arm: dom0less: Add
 trap-unmapped-mmio-disabled
In-Reply-To: <20250527195616.874614-3-edgar.iglesias@gmail.com>
Message-ID: 
References: <20250527195616.874614-1-edgar.iglesias@gmail.com> <20250527195616.874614-3-edgar.iglesias@gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 27 May 2025, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Add the trap-unmapped-mmio-disabled per-domain fdt property.
> 
> Signed-off-by: Edgar E. Iglesias 
> ---
>  docs/misc/arm/device-tree/booting.txt | 7 +++++++
>  xen/arch/arm/dom0less-build.c         | 3 ++-
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> index 59fa96a82e..75fbb245d1 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -225,6 +225,13 @@ with the following properties:
>      option is provided with a non zero value, but the platform doesn't support
>      SVE.
>  
> +- trap-unmapped-mmio-disabled
> +
> +    Optional. A boolean property that configures handling of accesses to
> +    unmapped MMIO ranges.
> +    If set, guest accesses will read 0xFFFFFFFF and writes ignored.
> +    If not set, guest accesses will trap.

I would prefer that we are consistent with the name of the parameter we
use in libxl and elsewhere so I would stick with trap-unmapped-mmio
without -disabled.

We can still default the property to "enabled" when absent. Although
this is not a common pattern for device tree, it happens and for
instance the property "status" works that way as it is implied to be
"enabled" when absent.


>  - xen,enhanced
>  
>      A string property. Possible property values are:
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index e5e13e07d0..cd1ef05d89 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -344,8 +344,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
>  #endif
>      }
>  
> -    /* Trap accesses to unmapped MMIO. */
>      d_cfg->arch.flags = XEN_ARM_TRAP_UNMAPPED_MMIO;
> +    if ( dt_property_read_bool(node, "trap-unmapped-mmio-disabled") )
> +        d_cfg->arch.flags &= ~XEN_ARM_TRAP_UNMAPPED_MMIO;
>  }
>  
>  int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Thu May 29 00:53:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 00:53:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999704.1380327 (Exim 4.92)
	(envelope-from )
	id 1uKRWF-00024u-2r; Thu, 29 May 2025 00:53:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999704.1380327; Thu, 29 May 2025 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 1uKRWF-00024n-06; Thu, 29 May 2025 00:53:15 +0000
Received: by outflank-mailman (input) for mailman id 999704;
 Thu, 29 May 2025 00:53:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKRWD-00024h-OA
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 00:53:13 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4b797c30-3c27-11f0-a2fe-13f23c93f187;
 Thu, 29 May 2025 02:53:12 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id CBAD561156;
 Thu, 29 May 2025 00:53:10 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16200C4CEE3;
 Thu, 29 May 2025 00:53: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" 
X-Inumbo-ID: 4b797c30-3c27-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748479990;
	bh=j2vHdOKvG0VoNEiSYcGyATAdAU6RLcTIQ9Q0Sw+TmPY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ODnIa/2xsCHocBoFqL1KgschvupxbJHrNb+x1+UK02nKUcEWJ85ah3QFgkCMx5bh2
	 BPVE3005vV8ZKhWHJJfhFcxQaDhfjQq+Mki/2Y3QcKXO5SxYp1noBAewGcAMagaCMh
	 jfLWOQxc3Wvs4F8aKqpGWzM5/7degC2OEk6KwjWWuVNDVAPgFZnhU5uHywESNAZUGH
	 N7WJCP9DlFHI+FccET18O6jg2cCJjprEcSJ+ycui5K82ekzZWIwXeL54wmRgcKXr1u
	 NFAMJ81x7RdXkK7iUSwTEMs/jJms8ePHoifkbYLx68MVOYPN7O+7q7bMVw/s+mu1P/
	 pJzIVvhFn4jdQ==
Date: Wed, 28 May 2025 17:53:07 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Mykyta Poturai 
cc: "xen-devel@lists.xenproject.org" , 
    Oleksandr Andrushchenko , 
    Julien Grall , Rahul Singh , 
    Stefano Stabellini , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Oleksandr Tyshchenko , 
    Stewart Hildebrand 
Subject: Re: [PATCH v11 3/7] xen/arm: smmuv2: Add PCI devices support for
 SMMUv2
In-Reply-To: <3e52fa21f988a38e06511b629f54e2f5e7e2a332.1748422217.git.mykyta_poturai@epam.com>
Message-ID: 
References:  <3e52fa21f988a38e06511b629f54e2f5e7e2a332.1748422217.git.mykyta_poturai@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 28 May 2025, Mykyta Poturai wrote:
> From: Oleksandr Andrushchenko 
> 
> Implement support for PCI devices in the SMMU driver. Make arm_smmu_master
> structure to hold a pointer to the device to allow it to hold PCI devices.
> Trigger iommu-map parsing when new PCI device is added. Add checks to
> assign/deassign functions to ensure PCI devices are handled correctly.
> Implement basic quarantining.
> 
> All pci devices are automatically assigned to hardware domain if it exists
> to ensure it can probe them.
> 
> TODO:
> Implement scratch page quarantining support.
> 
> Signed-off-by: Oleksandr Tyshchenko 
> Signed-off-by: Oleksandr Andrushchenko 
> Signed-off-by: Stewart Hildebrand 
> Signed-off-by: Mykyta Poturai 

Reviewed-by: Stefano Stabellini 


> ---
> v10-v11:
> * remove unused code
> * remove unnecessary blocks
> 
> v9->v10:
> * remove unused code
> * return on error in arm_smmu_dt_add_device_generic
> 
> v8->v9:
> * no change
> 
> v7->v8:
> * no change
> 
> v6->v7:
> * use d->pci_lock in arm_smmu_assign_dev()
> * remove !is_hardware_domain and pdev->domain == d checks in assign to
>   support future dom0less use case when dom0 is using vPCI
> * remove stale todo in dev_get_dev_node
> * don't print ""
> * remove redundant dt_device_is_protected check
> * remove assign/deassing prints
> * change assign logic to remove reassign reimplementation
> * check if pdev->domain exists before assigning to it
> * explain pdev->devfn check
> * make reassign check stricter and update comment
> 
> v5->v6:
> * check for hardware_domain == NULL (dom0less test case)
> * locking: assign pdev->domain before list_add()
> 
> v4->v5:
> * assign device to pdev->domain (usually dom0) by default in add_device() hook
> * deassign from hwdom
> * rebase on top of ("dynamic node programming using overlay dtbo") series
> * remove TODO in comment about device prints
> * add TODO regarding locking
> * fixup after dropping ("xen/arm: Move is_protected flag to struct device")
> 
> v3->v4:
> * add new device_is_protected check in add_device hook to match SMMUv3 and
>   IPMMU-VMSA drivers
> 
> v2->v3:
> * invoke iommu_add_pci_sideband_ids() from add_device hook
> 
> v1->v2:
> * ignore add_device/assign_device/reassign_device calls for phantom functions
>   (i.e. devfn != pdev->devfn)
> 
> downstream->v1:
> * wrap unused function in #ifdef 0
> * remove the remove_device() stub since it was submitted separately to the list
>   [XEN][PATCH v6 12/19] xen/smmu: Add remove_device callback for smmu_iommu ops
>   https://lists.xenproject.org/archives/html/xen-devel/2023-05/msg00204.html
> * arm_smmu_(de)assign_dev: return error instead of crashing system
> * update condition in arm_smmu_reassign_dev
> * style fixup
> * add && !is_hardware_domain(d) into condition in arm_smmu_assign_dev()
> 
> (cherry picked from commit 0c11a7f65f044c26d87d1e27ac6283ef1f9cfb7a from
>  the downstream branch spider-master from
>  https://github.com/xen-troops/xen.git)
> ---
>  xen/drivers/passthrough/arm/smmu.c | 246 +++++++++++++++++------------
>  1 file changed, 146 insertions(+), 100 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
> index 0f8d47dc98..307c2f6837 100644
> --- a/xen/drivers/passthrough/arm/smmu.c
> +++ b/xen/drivers/passthrough/arm/smmu.c
> @@ -120,11 +120,21 @@ enum irqreturn {
>  
>  typedef enum irqreturn irqreturn_t;
>  
> -/* Device logger functions
> - * TODO: Handle PCI
> - */
> -#define dev_print(dev, lvl, fmt, ...)						\
> -	 printk(lvl "smmu: %s: " fmt, dt_node_full_name(dev_to_dt(dev)), ## __VA_ARGS__)
> +/* Device logger functions */
> +#ifndef CONFIG_HAS_PCI
> +#define dev_print(dev, lvl, fmt, ...)    \
> +    printk(lvl "smmu: %s: " fmt, dev_name(dev), ## __VA_ARGS__)
> +#else
> +#define dev_print(dev, lvl, fmt, ...) ({                                \
> +    if ( !dev_is_pci((dev)) )                                           \
> +        printk(lvl "smmu: %s: " fmt, dev_name((dev)), ## __VA_ARGS__);  \
> +    else                                                                \
> +    {                                                                   \
> +        struct pci_dev *pdev = dev_to_pci((dev));                       \
> +        printk(lvl "smmu: %pp: " fmt, &pdev->sbdf, ## __VA_ARGS__);     \
> +    }                                                                   \
> +})
> +#endif
>  
>  #define dev_dbg(dev, fmt, ...) dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__)
>  #define dev_notice(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__)
> @@ -172,20 +182,6 @@ static void __iomem *devm_ioremap_resource(struct device *dev,
>  #define IOMMU_FAULT_READ	0
>  #define IOMMU_FAULT_WRITE	1
>  
> -/*
> - * Xen: PCI functions
> - * TODO: It should be implemented when PCI will be supported
> - */
> -#define to_pci_dev(dev)	(NULL)
> -static inline int pci_for_each_dma_alias(struct pci_dev *pdev,
> -					 int (*fn) (struct pci_dev *pdev,
> -						    u16 alias, void *data),
> -					 void *data)
> -{
> -	BUG();
> -	return 0;
> -}
> -
>  /* Xen: misc */
>  #define PHYS_MASK_SHIFT		PADDR_BITS
>  
> @@ -619,7 +615,7 @@ struct arm_smmu_master_cfg {
>  	for (i = 0; idx = (cfg)->smendx[i], (i) < (num); ++(i))
>  
>  struct arm_smmu_master {
> -	struct device_node		*of_node;
> +	struct device			*dev;
>  	struct rb_node			node;
>  	struct arm_smmu_master_cfg	cfg;
>  };
> @@ -711,7 +707,7 @@ arm_smmu_get_fwspec(struct arm_smmu_master_cfg *cfg)
>  {
>  	struct arm_smmu_master *master = container_of(cfg,
>  			                                      struct arm_smmu_master, cfg);
> -	return dev_iommu_fwspec_get(&master->of_node->dev);
> +	return dev_iommu_fwspec_get(master->dev);
>  }
>  
>  static void parse_driver_options(struct arm_smmu_device *smmu)
> @@ -730,21 +726,11 @@ static void parse_driver_options(struct arm_smmu_device *smmu)
>  
>  static struct device_node *dev_get_dev_node(struct device *dev)
>  {
> -#if 0 /* Xen: TODO: Add support for PCI */
> -	if (dev_is_pci(dev)) {
> -		struct pci_bus *bus = to_pci_dev(dev)->bus;
> -
> -		while (!pci_is_root_bus(bus))
> -			bus = bus->parent;
> -		return bus->bridge->parent->of_node;
> -	}
> -#endif
> -
>  	return dev->of_node;
>  }
>  
>  static struct arm_smmu_master *find_smmu_master(struct arm_smmu_device *smmu,
> -						struct device_node *dev_node)
> +						struct device *dev)
>  {
>  	struct rb_node *node = smmu->masters.rb_node;
>  
> @@ -753,9 +739,9 @@ static struct arm_smmu_master *find_smmu_master(struct arm_smmu_device *smmu,
>  
>  		master = container_of(node, struct arm_smmu_master, node);
>  
> -		if (dev_node < master->of_node)
> +		if (dev < master->dev)
>  			node = node->rb_left;
> -		else if (dev_node > master->of_node)
> +		else if (dev > master->dev)
>  			node = node->rb_right;
>  		else
>  			return master;
> @@ -790,9 +776,9 @@ static int insert_smmu_master(struct arm_smmu_device *smmu,
>  			= container_of(*new, struct arm_smmu_master, node);
>  
>  		parent = *new;
> -		if (master->of_node < this->of_node)
> +		if (master->dev < this->dev)
>  			new = &((*new)->rb_left);
> -		else if (master->of_node > this->of_node)
> +		else if (master->dev > this->dev)
>  			new = &((*new)->rb_right);
>  		else
>  			return -EEXIST;
> @@ -824,28 +810,30 @@ static int arm_smmu_dt_add_device_legacy(struct arm_smmu_device *smmu,
>  	struct arm_smmu_master *master;
>  	struct device_node *dev_node = dev_get_dev_node(dev);
>  
> -	master = find_smmu_master(smmu, dev_node);
> +	master = find_smmu_master(smmu, dev);
>  	if (master) {
>  		dev_err(dev,
> -			"rejecting multiple registrations for master device %s\n",
> -			dev_node->name);
> +			"rejecting multiple registrations for master device\n");
>  		return -EBUSY;
>  	}
>  
>  	master = devm_kzalloc(dev, sizeof(*master), GFP_KERNEL);
>  	if (!master)
>  		return -ENOMEM;
> -	master->of_node = dev_node;
> +	master->dev = dev;
>  
> -	/* Xen: Let Xen know that the device is protected by an SMMU */
> -	dt_device_set_protected(dev_node);
> +	if ( !dev_is_pci(dev) )
> +	{
> +		/* Xen: Let Xen know that the device is protected by an SMMU */
> +		dt_device_set_protected(dev_node);
> +	}
>  
>  	for (i = 0; i < fwspec->num_ids; ++i) {
>  		if (!(smmu->features & ARM_SMMU_FEAT_STREAM_MATCH) &&
>  		     (fwspec->ids[i] >= smmu->num_mapping_groups)) {
>  			dev_err(dev,
> -				"stream ID for master device %s greater than maximum allowed (%d)\n",
> -				dev_node->name, smmu->num_mapping_groups);
> +				"SMMU stream ID %d is greater than maximum allowed (%d)\n",
> +				fwspec->ids[i], smmu->num_mapping_groups);
>  			return -ERANGE;
>  		}
>  		master->cfg.smendx[i] = INVALID_SMENDX;
> @@ -860,7 +848,7 @@ static int arm_smmu_dt_remove_device_legacy(struct arm_smmu_device *smmu,
>  	struct device_node *dev_node = dev_get_dev_node(dev);
>  	int ret;
>  
> -	master = find_smmu_master(smmu, dev_node);
> +	master = find_smmu_master(smmu, dev);
>  	if (master == NULL) {
>  		dev_err(dev,
>  			"No registrations found for master device %s\n",
> @@ -872,8 +860,9 @@ static int arm_smmu_dt_remove_device_legacy(struct arm_smmu_device *smmu,
>  	if (ret)
>  		return ret;
>  
> -	/* Protected by dt_host_lock and dtdevs_lock as caller holds these locks. */
> -	dev_node->is_protected = false;
> +	if ( !dev_is_pci(dev) )
> +		/* Protected by dt_host_lock and dtdevs_lock as caller holds these locks. */
> +		dev_node->is_protected = false;
>  
>  	kfree(master);
>  	return 0;
> @@ -902,6 +891,12 @@ static int register_smmu_master(struct arm_smmu_device *smmu,
>  					     fwspec);
>  }
>  
> +/* Forward declaration */
> +static int arm_smmu_assign_dev(struct domain *d, u8 devfn,
> +			       struct device *dev, u32 flag);
> +static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn,
> +				 struct device *dev);
> +
>  /*
>   * The driver which supports generic IOMMU DT bindings must have this
>   * callback implemented.
> @@ -926,6 +921,25 @@ static int arm_smmu_dt_add_device_generic(u8 devfn, struct device *dev)
>  {
>  	struct arm_smmu_device *smmu;
>  	struct iommu_fwspec *fwspec;
> +	int ret;
> +
> +#ifdef CONFIG_HAS_PCI
> +	if ( dev_is_pci(dev) )
> +	{
> +		struct pci_dev *pdev = dev_to_pci(dev);
> +		int ret;
> +
> +		/* Ignore calls for phantom functions */
> +		if ( devfn != pdev->devfn )
> +			return 0;
> +
> +		ret = iommu_add_pci_sideband_ids(pdev);
> +		if ( ret < 0 ) {
> +			iommu_fwspec_free(dev);
> +			return ret;
> +		}
> +	}
> +#endif
>  
>  	fwspec = dev_iommu_fwspec_get(dev);
>  	if (fwspec == NULL)
> @@ -935,7 +949,25 @@ static int arm_smmu_dt_add_device_generic(u8 devfn, struct device *dev)
>  	if (smmu == NULL)
>  		return -ENXIO;
>  
> -	return arm_smmu_dt_add_device_legacy(smmu, dev, fwspec);
> +	ret = arm_smmu_dt_add_device_legacy(smmu, dev, fwspec);
> +	if ( ret )
> +		return ret;
> +
> +#ifdef CONFIG_HAS_PCI
> +	if ( dev_is_pci(dev) )
> +	{
> +		struct pci_dev *pdev = dev_to_pci(dev);
> +
> +		/*
> +		 * During PHYSDEVOP_pci_device_add, Xen does not assign the
> +		 * device, so we must do it here.
> +		 */
> +		if ( pdev->domain )
> +			ret = arm_smmu_assign_dev(pdev->domain, devfn, dev, 0);
> +	}
> +#endif
> +
> +	return ret;
>  }
>  
>  static int arm_smmu_dt_xlate_generic(struct device *dev,
> @@ -958,11 +990,10 @@ static struct arm_smmu_device *find_smmu_for_device(struct device *dev)
>  {
>  	struct arm_smmu_device *smmu;
>  	struct arm_smmu_master *master = NULL;
> -	struct device_node *dev_node = dev_get_dev_node(dev);
>  
>  	spin_lock(&arm_smmu_devices_lock);
>  	list_for_each_entry(smmu, &arm_smmu_devices, list) {
> -		master = find_smmu_master(smmu, dev_node);
> +		master = find_smmu_master(smmu, dev);
>  		if (master)
>  			break;
>  	}
> @@ -2054,65 +2085,26 @@ static bool arm_smmu_capable(enum iommu_cap cap)
>  }
>  #endif
>  
> -static int __arm_smmu_get_pci_sid(struct pci_dev *pdev, u16 alias, void *data)
> -{
> -	*((u16 *)data) = alias;
> -	return 0; /* Continue walking */
> -}
> -
> -static void __arm_smmu_release_pci_iommudata(void *data)
> -{
> -	kfree(data);
> -}
> -
>  static int arm_smmu_add_device(struct device *dev)
>  {
>  	struct arm_smmu_device *smmu;
> +	struct arm_smmu_master *master;
>  	struct arm_smmu_master_cfg *cfg;
>  	struct iommu_group *group;
>  	void (*releasefn)(void *data) = NULL;
> -	int ret;
>  
>  	smmu = find_smmu_for_device(dev);
>  	if (!smmu)
>  		return -ENODEV;
>  
> -	if (dev_is_pci(dev)) {
> -		struct pci_dev *pdev = to_pci_dev(dev);
> -		struct iommu_fwspec *fwspec;
> -
> -		cfg = kzalloc(sizeof(*cfg), GFP_KERNEL);
> -		if (!cfg) {
> -			return -ENOMEM;
> -		}
> -
> -		ret = iommu_fwspec_init(dev, smmu->dev);
> -		if (ret) {
> -			kfree(cfg);
> -			return ret;
> -		}
> -		fwspec = dev_iommu_fwspec_get(dev);
> -
> -		/*
> -		 * Assume Stream ID == Requester ID for now.
> -		 * We need a way to describe the ID mappings in FDT.
> -		 */
> -		pci_for_each_dma_alias(pdev, __arm_smmu_get_pci_sid,
> -				       &fwspec->ids[0]);
> -		releasefn = __arm_smmu_release_pci_iommudata;
> -		cfg->smmu = smmu;
> -	} else {
> -		struct arm_smmu_master *master;
> -
> -		master = find_smmu_master(smmu, dev->of_node);
> -		if (!master) {
> -			return -ENODEV;
> -		}
> -
> -		cfg = &master->cfg;
> -		cfg->smmu = smmu;
> +	master = find_smmu_master(smmu, dev);
> +	if (!master) {
> +		return -ENODEV;
>  	}
>  
> +	cfg = &master->cfg;
> +	cfg->smmu = smmu;
> +
>  	group = iommu_group_alloc();
>  	if (IS_ERR(group)) {
>  		dev_err(dev, "Failed to allocate IOMMU group\n");
> @@ -2772,6 +2764,42 @@ static int arm_smmu_assign_dev(struct domain *d, u8 devfn,
>  			return -ENOMEM;
>  	}
>  
> +#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());
> +
> +		write_lock(&pdev->domain->pci_lock);
> +		list_del(&pdev->domain_list);
> +		write_unlock(&pdev->domain->pci_lock);
> +
> +		pdev->domain = d;
> +
> +		write_lock(&d->pci_lock);
> +		list_add(&pdev->domain_list, &d->pdev_list);
> +		write_unlock(&d->pci_lock);
> +
> +		/* dom_io is used as a sentinel for quarantined devices */
> +		if ( d == dom_io )
> +		{
> +			struct iommu_domain *domain = dev_iommu_domain(dev);
> +			if ( !iommu_quarantine )
> +				return 0;
> +
> +			if ( domain && domain->priv )
> +				arm_smmu_deassign_dev(domain->priv->cfg.domain, devfn, dev);
> +
> +			return 0;
> +		}
> +	}
> +#endif
> +
>  	if (!dev_iommu_group(dev)) {
>  		ret = arm_smmu_add_device(dev);
>  		if (ret)
> @@ -2821,11 +2849,27 @@ out:
>  	return ret;
>  }
>  
> -static int arm_smmu_deassign_dev(struct domain *d, struct device *dev)
> +static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn,
> +				 struct device *dev)
>  {
>  	struct iommu_domain *domain = dev_iommu_domain(dev);
>  	struct arm_smmu_xen_domain *xen_domain;
>  
> +#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;
> +
> +		/* dom_io is used as a sentinel for quarantined devices */
> +		if ( d == dom_io )
> +			return 0;
> +	}
> +#endif
> +
>  	xen_domain = dom_iommu(d)->arch.priv;
>  
>  	if (!domain || domain->priv->cfg.domain != d) {
> @@ -2852,14 +2896,16 @@ static int arm_smmu_reassign_dev(struct domain *s, struct domain *t,
>  {
>  	int ret = 0;
>  
> -	/* Don't allow remapping on other domain than hwdom */
> -	if ( t && !is_hardware_domain(t) )
> +	/* Don't allow remapping on other domain than hwdom
> +	 * or dom_io for PCI devices
> +	 */
> +	if ( t && !is_hardware_domain(t) && (t != dom_io || !dev_is_pci(dev)) )
>  		return -EPERM;
>  
>  	if (t == s)
>  		return 0;
>  
> -	ret = arm_smmu_deassign_dev(s, dev);
> +	ret = arm_smmu_deassign_dev(s, devfn, dev);
>  	if (ret)
>  		return ret;
>  
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Thu May 29 00:56:38 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 00:56:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999716.1380338 (Exim 4.92)
	(envelope-from )
	id 1uKRZV-0002jR-Kt; Thu, 29 May 2025 00:56:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999716.1380338; Thu, 29 May 2025 00: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 1uKRZV-0002jK-Hy; Thu, 29 May 2025 00:56:37 +0000
Received: by outflank-mailman (input) for mailman id 999716;
 Thu, 29 May 2025 00:56:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKRZT-0002jE-ML
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 00:56:35 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c416b1d6-3c27-11f0-a2fe-13f23c93f187;
 Thu, 29 May 2025 02:56:34 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 9064161156;
 Thu, 29 May 2025 00:56:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4E58C4CEE3;
 Thu, 29 May 2025 00:56: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" 
X-Inumbo-ID: c416b1d6-3c27-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748480192;
	bh=eSvJ8OvpRSN/6GQMDPLNC/VPWLQ5QtM8LCKx0TjKUaY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ItuXGeKn7CDWmoWQwRDEPaYsbcaxxfx2ynLmB8ep0nWFjQE324AU39/rfJJqzk9g2
	 Y7b59VyhSWgmVaQ+iNKOdhy5VkHNdwa2BDJxiaP9ZJs6H0ZjYA0GLACT167xcRmW3n
	 GN/LTJSUOKuu0JX+TSgJFlKuVG2bao4UUEJdG20/txEOFma56GHtxSzGYomekotUlI
	 0CWQlpHNlQzd2U977oKPTuzoEHtXJfIDdvsjLW5NtomaHtYn3O3EzzIm3cc1wAgjGi
	 w7sSqGWLhPZEocC3erttQ2mqyYr2HP4cWl6Fj9BKHT6obdTsMT0Rgbk0W4czPPLQGh
	 l4pFUnrF98f+g==
Date: Wed, 28 May 2025 17:56:30 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Mykyta Poturai 
cc: "xen-devel@lists.xenproject.org" , 
    Rahul Singh , 
    Bertrand Marquis , 
    Stefano Stabellini , Julien Grall , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Stewart Hildebrand 
Subject: Re: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for
 SMMUv3
In-Reply-To: <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
Message-ID: 
References:  <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 28 May 2025, Mykyta Poturai wrote:
> From: Rahul Singh 
> 
> Implement support for PCI devices in the SMMU driver. Trigger iommu-map
> parsing when new PCI device is added. Add checks to assign/deassign
> functions to ensure PCI devices are handled correctly. Implement basic
> quarantining.
> 
> All pci devices are automatically assigned to hardware domain if it exists
> to ensure it can probe them.
> 
> TODO:
> Implement scratch page quarantining support.
> 
> Signed-off-by: Rahul Singh 
> Signed-off-by: Stewart Hildebrand 
> Signed-off-by: Mykyta Poturai 

Reviewed-by: Stefano Stabellini 


> ---
> v10->v11:
> * no changes
> 
> v9->v10:
> * return if iommu_add_pci_sidband_ids fails
> 
> v8->v9:
> * no change
> 
> v7->v8:
> * no change
> 
> v6->v7:
> * address TODO: use d->pci_lock in arm_smmu_assign_dev()
> * remove !is_hardware_domain and pdev->domain == d checks in assign to
>   support future dom0less use case when dom0 is using vPCI
> * check if pdev->domain exists before assigning to it
> * don't print ""
> * change assign logic to remove reassign reimplementation
> * explain pdev->devfn check
> * make reassign check stricter and update comment
> 
> v5->v6:
> * check for hardware_domain == NULL (dom0less test case)
> * locking: assign pdev->domain before list_add()
> 
> v4->v5:
> * deassign from hwdom
> * add TODO regarding locking
> * fixup after dropping ("xen/arm: Move is_protected flag to struct device")
> 
> v3->v4:
> * no change
> 
> v2->v3:
> * rebase
> * invoke iommu_add_pci_sideband_ids() from add_device hook
> 
> v1->v2:
> * ignore add_device/assign_device/reassign_device calls for phantom functions
>   (i.e. devfn != pdev->devfn)
> 
> downstream->v1:
> * rebase
> * move 2 replacements of s/dt_device_set_protected(dev_to_dt(dev))/device_set_protected(dev)/
>   from this commit to ("xen/arm: Move is_protected flag to struct device")
>   so as to not break ability to bisect
> * adjust patch title (remove stray space)
> * arm_smmu_(de)assign_dev: return error instead of crashing system
> * remove arm_smmu_remove_device() stub
> * update condition in arm_smmu_reassign_dev
> * style fixup
> 
> (cherry picked from commit 7ed6c3ab250d899fe6e893a514278e406a2893e8 from
>  the downstream branch poc/pci-passthrough from
>  https://gitlab.com/xen-project/people/bmarquis/xen-arm-poc.git)
> ---
>  xen/drivers/passthrough/arm/smmu-v3.c | 119 +++++++++++++++++++++++---
>  1 file changed, 108 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c
> index df16235057..a3bbfda993 100644
> --- a/xen/drivers/passthrough/arm/smmu-v3.c
> +++ b/xen/drivers/passthrough/arm/smmu-v3.c
> @@ -1469,14 +1469,37 @@ static bool arm_smmu_sid_in_range(struct arm_smmu_device *smmu, u32 sid)
>  }
>  /* Forward declaration */
>  static struct arm_smmu_device *arm_smmu_get_by_dev(const struct device *dev);
> +static int arm_smmu_assign_dev(struct domain *d, u8 devfn, struct device *dev,
> +			       u32 flag);
> +static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn,
> +				 struct device *dev);
>  
>  static int arm_smmu_add_device(u8 devfn, struct device *dev)
>  {
>  	int i, ret;
>  	struct arm_smmu_device *smmu;
>  	struct arm_smmu_master *master;
> -	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> +	struct iommu_fwspec *fwspec;
> +
> +#ifdef CONFIG_HAS_PCI
> +	if ( dev_is_pci(dev) )
> +	{
> +		struct pci_dev *pdev = dev_to_pci(dev);
> +		int ret;
> +				
> +		/* Ignore calls for phantom functions */
> +		if ( devfn != pdev->devfn )
> +			return 0;
> +
> +		ret = iommu_add_pci_sideband_ids(pdev);
> +		if ( ret < 0 ) {
> +			iommu_fwspec_free(dev);
> +			return ret;
> +		}
> +	}
> +#endif
>  
> +	fwspec = dev_iommu_fwspec_get(dev);
>  	if (!fwspec)
>  		return -ENODEV;
>  
> @@ -1521,17 +1544,38 @@ static int arm_smmu_add_device(u8 devfn, struct device *dev)
>  	 */
>  	arm_smmu_enable_pasid(master);
>  
> -	if (dt_device_is_protected(dev_to_dt(dev))) {
> -		dev_err(dev, "Already added to SMMUv3\n");
> -		return -EEXIST;
> -	}
> +	if ( !dev_is_pci(dev) )
> +	{
> +		if (dt_device_is_protected(dev_to_dt(dev))) {
> +			dev_err(dev, "Already added to SMMUv3\n");
> +			return -EEXIST;
> +		}
>  
> -	/* Let Xen know that the master device is protected by an IOMMU. */
> -	dt_device_set_protected(dev_to_dt(dev));
> +		/* Let Xen know that the master device is protected by an IOMMU. */
> +		dt_device_set_protected(dev_to_dt(dev));
> +	}
>  
>  	dev_info(dev, "Added master device (SMMUv3 %s StreamIds %u)\n",
>  			dev_name(fwspec->iommu_dev), fwspec->num_ids);
>  
> +#ifdef CONFIG_HAS_PCI
> +	if ( dev_is_pci(dev) )
> +	{
> +		struct pci_dev *pdev = dev_to_pci(dev);
> +
> +		/*
> +		 * During PHYSDEVOP_pci_device_add, Xen does not assign the
> +		 * device, so we must do it here.
> +		 */
> +		if ( pdev->domain )
> +		{
> +			ret = arm_smmu_assign_dev(pdev->domain, devfn, dev, 0);
> +			if (ret)
> +				goto err_free_master;
> +		}
> +	}
> +#endif
> +
>  	return 0;
>  
>  err_free_master:
> @@ -2624,6 +2668,42 @@ static int arm_smmu_assign_dev(struct domain *d, u8 devfn,
>  	struct arm_smmu_domain *smmu_domain;
>  	struct arm_smmu_xen_domain *xen_domain = dom_iommu(d)->arch.priv;
>  
> +#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());
> +
> +		write_lock(&pdev->domain->pci_lock);
> +		list_del(&pdev->domain_list);
> +		write_unlock(&pdev->domain->pci_lock);
> +
> +		pdev->domain = d;
> +
> +		write_lock(&d->pci_lock);
> +		list_add(&pdev->domain_list, &d->pdev_list);
> +		write_unlock(&d->pci_lock);
> +
> +		/* dom_io is used as a sentinel for quarantined devices */
> +		if ( d == dom_io )
> +		{
> +			struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> +			if ( !iommu_quarantine )
> +				return 0;
> +
> +			if ( master && master->domain )
> +				arm_smmu_deassign_dev(master->domain->d, devfn, dev);
> +
> +			return 0;
> +		}
> +	}
> +#endif
> +
>  	spin_lock(&xen_domain->lock);
>  
>  	/*
> @@ -2657,7 +2737,7 @@ out:
>  	return ret;
>  }
>  
> -static int arm_smmu_deassign_dev(struct domain *d, struct device *dev)
> +static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn, struct device *dev)
>  {
>  	struct iommu_domain *io_domain = arm_smmu_get_domain(d, dev);
>  	struct arm_smmu_xen_domain *xen_domain = dom_iommu(d)->arch.priv;
> @@ -2669,6 +2749,21 @@ static int arm_smmu_deassign_dev(struct domain *d, struct device *dev)
>  		return -ESRCH;
>  	}
>  
> +#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;
> +
> +		/* dom_io is used as a sentinel for quarantined devices */
> +		if ( d == dom_io )
> +			return 0;
> +	}
> +#endif
> +
>  	spin_lock(&xen_domain->lock);
>  
>  	arm_smmu_detach_dev(master);
> @@ -2687,14 +2782,16 @@ static int arm_smmu_reassign_dev(struct domain *s, struct domain *t,
>  {
>  	int ret = 0;
>  
> -	/* Don't allow remapping on other domain than hwdom */
> -	if ( t && !is_hardware_domain(t) )
> +	/* Don't allow remapping on other domain than hwdom
> +	 * or dom_io for PCI devices
> +	 */
> +	if ( t && !is_hardware_domain(t) && (t != dom_io || !dev_is_pci(dev)) )
>  		return -EPERM;
>  
>  	if (t == s)
>  		return 0;
>  
> -	ret = arm_smmu_deassign_dev(s, dev);
> +	ret = arm_smmu_deassign_dev(s, devfn, dev);
>  	if (ret)
>  		return ret;
>  
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Thu May 29 01:14:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 01:14:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999729.1380348 (Exim 4.92)
	(envelope-from )
	id 1uKRr0-0005FZ-05; Thu, 29 May 2025 01:14:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999729.1380348; Thu, 29 May 2025 01:14: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 1uKRqz-0005FS-T0; Thu, 29 May 2025 01:14:41 +0000
Received: by outflank-mailman (input) for mailman id 999729;
 Thu, 29 May 2025 01:14:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKRqy-0005FE-6j
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 01:14:40 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 498dfe4d-3c2a-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 03:14:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 3CACF61156;
 Thu, 29 May 2025 01:14:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2546BC4CEE3;
 Thu, 29 May 2025 01:14: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" 
X-Inumbo-ID: 498dfe4d-3c2a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748481275;
	bh=rwadL/Wng9tKc3eHnmDgJKY6hwQqIw2Szk/Qzw3gv6Y=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=DoUuRF5KegDJwab28HbXG/Fl2EdUDQjJTFTK3KNKM9/WGLgXGk5RY/i0u/xVZowSp
	 H/93MyyjIVRc/HWMfJm2LVXgqvm5UpFYfAvc/aEdrXreafbCef0AkVre+9SbBBjXSy
	 0POLkbXY6PBJByB+MGPz1WAB84Qs8eLGjE6CNcef9AR3jtrFTkyXirN8UK6aJDV9XU
	 2w4NKIq+ijwVcdVDXDq9XisgFH14vRxkZ84/Giet2y5g0nVPsZ8prw7AmVuiGYr0/A
	 yCenp02GqgUEfac/LBaCXY8BomvfbuQ3FEoR17boRBAL0mPJtamWZqZ6lPRpquLF0Y
	 Ug33zawTkXTEA==
Date: Wed, 28 May 2025 18:14:32 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Mykyta Poturai 
cc: "xen-devel@lists.xenproject.org" , 
    Oleksandr Andrushchenko , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    Bertrand Marquis , 
    Volodymyr Babchuk 
Subject: Re: [PATCH v5 4/4] xen/arm: add support for R-Car Gen4 PCI host
 controller
In-Reply-To: <06f5972dda6a8132be8eab5ad1b8586ff3c5aaf3.1747820844.git.mykyta_poturai@epam.com>
Message-ID: 
References:  <06f5972dda6a8132be8eab5ad1b8586ff3c5aaf3.1747820844.git.mykyta_poturai@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 21 May 2025, Mykyta Poturai wrote:
> From: Oleksandr Andrushchenko 
> 
> Add support for Renesas R-Car Gen4 PCI host controller, specifically
> targeting the S4 and V4H SoCs. The implementation includes configuration
> read/write operations for both root and child buses. For accessing the
> child bus, iATU is used for address translation.
> 
> The host controller needs to be initialized by Dom0 first to be properly
> handled by Xen. Xen itself only handles the runtime configuration of
> the iATU for accessing different child devices.
> 
> iATU programming is done similarly to Linux, where only window 0 is used
> for dynamic configuration, and it is reconfigured for every config space
> read/write.
> 
> Code common to all DesignWare PCI host controllers is located in a
> separate file to allow for easy reuse in other DesignWare-based PCI
> host controllers.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> Signed-off-by: Mykyta Poturai 

Acked-by: Stefano Stabellini 


> ---
> v4->v5:
> * update license identifiers
> * improve error checking
> * use XENLOG_G_* where needed
> * make macro defs more robust and minor style fixes
> * add MAINTANERS entry
> 
> v3->v4:
> * no changes
> 
> v2->v3:
> * move priv allocation to dw_pcie_host_probe
> 
> v1->v2:
> * move designware code in a separate file
> ---
>  MAINTAINERS                       |   6 +
>  xen/arch/arm/pci/Makefile         |   2 +
>  xen/arch/arm/pci/pci-designware.c | 416 ++++++++++++++++++++++++++++++
>  xen/arch/arm/pci/pci-designware.h |  90 +++++++
>  xen/arch/arm/pci/pci-host-rcar4.c |  94 +++++++
>  5 files changed, 608 insertions(+)
>  create mode 100644 xen/arch/arm/pci/pci-designware.c
>  create mode 100644 xen/arch/arm/pci/pci-designware.h
>  create mode 100644 xen/arch/arm/pci/pci-host-rcar4.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c11b82eca9..dc1291e2b0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -476,6 +476,12 @@ M:	Anthony Perard 
>  S:	Supported
>  T:	git https://xenbits.xenproject.org/git-http/qemu-xen.git
>  
> +RCAR PCI
> +M:	Mykyta Poturai 
> +S:	Supported
> +F:	xen/arch/arm/pci/pci-host-rcar4.c
> +F:	xen/arch/arm/pci/pci-designware*
> +
>  REMUS
>  S:	Orphan
>  F:	docs/README.remus
> diff --git a/xen/arch/arm/pci/Makefile b/xen/arch/arm/pci/Makefile
> index 1d045ade01..ca6135e282 100644
> --- a/xen/arch/arm/pci/Makefile
> +++ b/xen/arch/arm/pci/Makefile
> @@ -4,3 +4,5 @@ obj-y += pci-host-generic.o
>  obj-y += pci-host-common.o
>  obj-y += ecam.o
>  obj-y += pci-host-zynqmp.o
> +obj-y += pci-designware.o
> +obj-y += pci-host-rcar4.o
> diff --git a/xen/arch/arm/pci/pci-designware.c b/xen/arch/arm/pci/pci-designware.c
> new file mode 100644
> index 0000000000..fc8c6724f2
> --- /dev/null
> +++ b/xen/arch/arm/pci/pci-designware.c
> @@ -0,0 +1,416 @@
> +/* SPDX-License-Identifier: GPL-2.0-only
> + *
> + * Based on Linux drivers/pci/controller/pci-host-common.c
> + * Based on Linux drivers/pci/controller/pci-host-generic.c
> + * Based on Linux drivers/pci/controller/dwc/pcie-designware.c
> + * Based on xen/arch/arm/pci/pci-host-generic.c
> + *
> + */
> +
> +#include 
> +#include 
> +
> +#include "pci-designware.h"
> +/**
> + * upper_32_bits - return bits 32-63 of a number
> + * @n: the number we're accessing
> + *
> + * A basic shift-right of a 64- or 32-bit quantity.  Use this to suppress
> + * the "right shift count >= width of type" warning when that quantity is
> + * 32-bits.
> + */
> +#define upper_32_bits(n) ((uint32_t)(((n) >> 16) >> 16))
> +
> +/**
> + * lower_32_bits - return bits 0-31 of a number
> + * @n: the number we're accessing
> + */
> +#define lower_32_bits(n) ((uint32_t)((n) & 0xffffffffU))
> +
> +static int dw_pcie_read(void __iomem *addr, int len, uint32_t *val)
> +{
> +    if ( !IS_ALIGNED((uintptr_t)addr, len) )
> +    {
> +        *val = 0;
> +        return -EFAULT;
> +    }
> +
> +    switch ( len )
> +    {
> +    case 1:
> +        *val = readb(addr);
> +        break;
> +    case 2:
> +        *val = readw(addr);
> +        break;
> +    case 4:
> +        *val = readl(addr);
> +        break;
> +    default:
> +        ASSERT_UNREACHABLE();
> +    }
> +
> +    return 0;
> +}
> +
> +static int dw_pcie_write(void __iomem *addr, int len, uint32_t val)
> +{
> +    if ( !IS_ALIGNED((uintptr_t)addr, len) )
> +        return -EFAULT;
> +
> +    switch ( len )
> +    {
> +    case 1:
> +        writeb(val, addr);
> +        break;
> +    case 2:
> +        writew(val, addr);
> +        break;
> +    case 4:
> +        writel(val, addr);
> +        break;
> +    default:
> +        ASSERT_UNREACHABLE();
> +    }
> +
> +    return 0;
> +}
> +
> +static uint32_t dw_pcie_read_dbi(struct pci_host_bridge *bridge, uint32_t reg,
> +                                 size_t size)
> +{
> +    void __iomem *addr = bridge->cfg->win + reg;
> +    uint32_t val;
> +    int ret;
> +
> +    ret = dw_pcie_read(addr, size, &val);
> +    if ( ret )
> +        printk(XENLOG_G_ERR "Read DBI address failed\n");
> +
> +    return val;
> +}
> +
> +static void dw_pcie_write_dbi(struct pci_host_bridge *bridge, uint32_t reg,
> +                              size_t size, uint32_t val)
> +{
> +    void __iomem *addr = bridge->cfg->win + reg;
> +    int ret;
> +
> +    ret = dw_pcie_write(addr, size, val);
> +    if ( ret )
> +        printk(XENLOG_G_ERR "Write DBI address failed\n");
> +}
> +
> +static uint32_t dw_pcie_readl_dbi(struct pci_host_bridge *bridge, uint32_t reg)
> +{
> +    return dw_pcie_read_dbi(bridge, reg, sizeof(uint32_t));
> +}
> +
> +static void dw_pcie_writel_dbi(struct pci_host_bridge *pci, uint32_t reg,
> +                               uint32_t val)
> +{
> +    dw_pcie_write_dbi(pci, reg, sizeof(uint32_t), val);
> +}
> +
> +static void dw_pcie_read_iatu_unroll_enabled(struct pci_host_bridge *bridge)
> +{
> +    struct dw_pcie_priv *priv = bridge->priv;
> +    uint32_t val;
> +
> +    val = dw_pcie_readl_dbi(bridge, PCIE_ATU_VIEWPORT);
> +    if ( val == 0xffffffffU )
> +        priv->iatu_unroll_enabled = true;
> +
> +    printk(XENLOG_G_DEBUG "%s iATU unroll: %sabled\n",
> +           dt_node_full_name(bridge->dt_node),
> +           priv->iatu_unroll_enabled ? "en" : "dis");
> +}
> +
> +static uint32_t dw_pcie_readl_atu(struct pci_host_bridge *pci, uint32_t reg)
> +{
> +    struct dw_pcie_priv *priv = pci->priv;
> +    int ret;
> +    uint32_t val;
> +
> +    ret = dw_pcie_read(priv->atu_base + reg, 4, &val);
> +    if ( ret )
> +        printk(XENLOG_G_ERR "Read ATU address failed\n");
> +
> +    return val;
> +}
> +
> +static void dw_pcie_writel_atu(struct pci_host_bridge *pci, uint32_t reg,
> +                               uint32_t val)
> +{
> +    struct dw_pcie_priv *priv = pci->priv;
> +    int ret;
> +
> +    ret = dw_pcie_write(priv->atu_base + reg, 4, val);
> +    if ( ret )
> +        printk(XENLOG_G_ERR "Write ATU address failed\n");
> +}
> +
> +static uint32_t dw_pcie_readl_ob_unroll(struct pci_host_bridge *pci,
> +                                        uint32_t index, uint32_t reg)
> +{
> +    uint32_t offset = PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
> +
> +    return dw_pcie_readl_atu(pci, offset + reg);
> +}
> +
> +static void dw_pcie_writel_ob_unroll(struct pci_host_bridge *pci,
> +                                     uint32_t index, uint32_t reg, uint32_t val)
> +{
> +    uint32_t offset = PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
> +
> +    dw_pcie_writel_atu(pci, offset + reg, val);
> +}
> +
> +static uint32_t dw_pcie_enable_ecrc(uint32_t val)
> +{
> +    ASSERT_UNREACHABLE();
> +    return 0;
> +}
> +
> +static int dw_pcie_prog_outbound_atu_unroll(struct pci_host_bridge *pci,
> +                                            uint8_t func_no, int index,
> +                                            int type, uint64_t cpu_addr,
> +                                            uint64_t pci_addr, uint64_t size)
> +{
> +    struct dw_pcie_priv *priv = pci->priv;
> +    uint32_t retries, val;
> +    uint64_t limit_addr = cpu_addr + size - 1;
> +
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_BASE,
> +                             lower_32_bits(cpu_addr));
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_BASE,
> +                             upper_32_bits(cpu_addr));
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_LIMIT,
> +                             lower_32_bits(limit_addr));
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_LIMIT,
> +                             upper_32_bits(limit_addr));
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_TARGET,
> +                             lower_32_bits(pci_addr));
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
> +                             upper_32_bits(pci_addr));
> +    val = type | PCIE_ATU_FUNC_NUM(func_no);
> +    val = upper_32_bits(size - 1) ? val | PCIE_ATU_INCREASE_REGION_SIZE : val;
> +    if ( priv->version == 0x490A )
> +        val = dw_pcie_enable_ecrc(val);
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1, val);
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
> +                             PCIE_ATU_ENABLE);
> +
> +    /*
> +     * Make sure ATU enable takes effect before any subsequent config
> +     * and I/O accesses.
> +     */
> +    for ( retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++ )
> +    {
> +        val = dw_pcie_readl_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2);
> +        if ( val & PCIE_ATU_ENABLE )
> +            return 0;
> +
> +        mdelay(LINK_WAIT_IATU);
> +    }
> +    printk(XENLOG_G_ERR "Outbound iATU is not being enabled\n");
> +
> +    return -ENXIO;
> +}
> +
> +static int __dw_pcie_prog_outbound_atu(struct pci_host_bridge *pci,
> +                                       uint8_t func_no, int index, int type,
> +                                       uint64_t cpu_addr, uint64_t pci_addr,
> +                                       uint64_t size)
> +{
> +    struct dw_pcie_priv *priv = pci->priv;
> +    uint32_t retries, val;
> +
> +    if ( priv->iatu_unroll_enabled )
> +        return dw_pcie_prog_outbound_atu_unroll(pci, func_no, index, type,
> +                                                cpu_addr, pci_addr, size);
> +
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT,
> +                       PCIE_ATU_REGION_OUTBOUND | index);
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_BASE, lower_32_bits(cpu_addr));
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_BASE, upper_32_bits(cpu_addr));
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_LIMIT, lower_32_bits(cpu_addr + size - 1));
> +    if ( priv->version >= 0x460A )
> +        dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_LIMIT,
> +                           upper_32_bits(cpu_addr + size - 1));
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_TARGET, lower_32_bits(pci_addr));
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET, upper_32_bits(pci_addr));
> +    val = type | PCIE_ATU_FUNC_NUM(func_no);
> +    val = ((upper_32_bits(size - 1)) && (priv->version >= 0x460A))
> +              ? val | PCIE_ATU_INCREASE_REGION_SIZE
> +              : val;
> +    if ( priv->version == 0x490A )
> +        val = dw_pcie_enable_ecrc(val);
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, val);
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE);
> +
> +    /*
> +     * Make sure ATU enable takes effect before any subsequent config
> +     * and I/O accesses.
> +     */
> +    for ( retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++ )
> +    {
> +        val = dw_pcie_readl_dbi(pci, PCIE_ATU_CR2);
> +        if ( val & PCIE_ATU_ENABLE )
> +            return 0;
> +
> +        mdelay(LINK_WAIT_IATU);
> +    }
> +    printk(XENLOG_G_ERR "Outbound iATU is not being enabled\n");
> +
> +    return -ENXIO;
> +}
> +
> +static int dw_pcie_prog_outbound_atu(struct pci_host_bridge *pci, int index,
> +                                     int type, uint64_t cpu_addr,
> +                                     uint64_t pci_addr, uint64_t size)
> +{
> +    return __dw_pcie_prog_outbound_atu(pci, 0, index, type, cpu_addr, pci_addr,
> +                                       size);
> +}
> +
> +void dw_pcie_set_version(struct pci_host_bridge *bridge, unsigned int version)
> +{
> +    struct dw_pcie_priv *priv = bridge->priv;
> +
> +    priv->version = version;
> +}
> +
> +void __iomem *dw_pcie_child_map_bus(struct pci_host_bridge *bridge,
> +                                    pci_sbdf_t sbdf, uint32_t where)
> +{
> +    uint32_t busdev;
> +    int ret;
> +
> +    busdev = PCIE_ATU_BUS(sbdf.bus) | PCIE_ATU_DEV(PCI_SLOT(sbdf.devfn)) |
> +             PCIE_ATU_FUNC(PCI_FUNC(sbdf.devfn));
> +
> +    /* FIXME: Parent is the root bus, so use PCIE_ATU_TYPE_CFG0. */
> +    ret = dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
> +                                    PCIE_ATU_TYPE_CFG0,
> +                                    bridge->child_cfg->phys_addr, busdev,
> +                                    bridge->child_cfg->size);
> +    if ( ret )
> +        return 0;
> +
> +    return bridge->child_cfg->win + where;
> +}
> +
> +int dw_pcie_child_config_read(struct pci_host_bridge *bridge, pci_sbdf_t sbdf,
> +                              uint32_t reg, uint32_t len, uint32_t *value)
> +{
> +    struct dw_pcie_priv *priv = bridge->priv;
> +    int ret;
> +
> +    /*
> +     * FIXME: we cannot read iATU settings at the early initialization
> +     * (probe) as the host's HW is not yet initialized at that phase.
> +     * This read operation is the very first thing Domain-0 will do
> +     * during its initialization, so take this opportunity and read
> +     * iATU setting now.
> +     */
> +    if ( unlikely(!priv->iatu_unroll_initilized) )
> +    {
> +        dw_pcie_read_iatu_unroll_enabled(bridge);
> +        priv->iatu_unroll_initilized = true;
> +    }
> +
> +    ret = pci_generic_config_read(bridge, sbdf, reg, len, value);
> +    if ( !ret && (priv->num_viewport <= 2) )
> +        ret = dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
> +                                        PCIE_ATU_TYPE_IO,
> +                                        bridge->child_cfg->phys_addr, 0,
> +                                        bridge->child_cfg->size);
> +
> +    return ret;
> +}
> +
> +int dw_pcie_child_config_write(struct pci_host_bridge *bridge, pci_sbdf_t sbdf,
> +                               uint32_t reg, uint32_t len, uint32_t value)
> +{
> +    struct dw_pcie_priv *priv = bridge->priv;
> +    int ret;
> +
> +    ret = pci_generic_config_write(bridge, sbdf, reg, len, value);
> +    if ( !ret && (priv->num_viewport <= 2) )
> +        ret = dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
> +                                        PCIE_ATU_TYPE_IO,
> +                                        bridge->child_cfg->phys_addr, 0,
> +                                        bridge->child_cfg->size);
> +    return ret;
> +}
> +
> +bool __init dw_pcie_child_need_p2m_hwdom_mapping(struct domain *d,
> +                                                 struct pci_host_bridge *bridge,
> +                                                 uint64_t addr)
> +{
> +    struct pci_config_window *cfg = bridge->child_cfg;
> +
> +    /*
> +     * We do not want ECAM address space to be mapped in Domain-0's p2m,
> +     * so we can trap access to it.
> +     */
> +    return cfg->phys_addr != addr;
> +}
> +
> +struct pci_host_bridge *__init
> +dw_pcie_host_probe(struct dt_device_node *dev, const void *data,
> +                   const struct pci_ecam_ops *ops,
> +                   const struct pci_ecam_ops *child_ops)
> +{
> +    struct pci_host_bridge *bridge;
> +    struct dw_pcie_priv *priv;
> +
> +    paddr_t atu_phys_addr;
> +    paddr_t atu_size;
> +    int atu_idx, ret;
> +
> +    bridge = pci_host_common_probe(dev, ops, child_ops);
> +    if ( IS_ERR(bridge) )
> +        return bridge;
> +
> +    priv = xzalloc(struct dw_pcie_priv);
> +    if ( !priv )
> +        return ERR_PTR(-ENOMEM);
> +
> +    bridge->priv = priv;
> +
> +    atu_idx = dt_property_match_string(dev, "reg-names", "atu");
> +    if ( atu_idx < 0 )
> +    {
> +        printk(XENLOG_ERR "Cannot find \"atu\" range index in device tree\n");
> +        return ERR_PTR(atu_idx);
> +    }
> +    ret = dt_device_get_address(dev, atu_idx, &atu_phys_addr, &atu_size);
> +    if ( ret )
> +    {
> +        printk(XENLOG_ERR "Cannot find \"atu\" range in device tree\n");
> +        return ERR_PTR(ret);
> +    }
> +    printk("iATU at [mem 0x%" PRIpaddr "-0x%" PRIpaddr "]\n", atu_phys_addr,
> +           atu_phys_addr + atu_size - 1);
> +    priv->atu_base = ioremap_nocache(atu_phys_addr, atu_size);
> +    if ( !priv->atu_base )
> +    {
> +        printk(XENLOG_ERR "iATU ioremap failed\n");
> +        return ERR_PTR(ENXIO);
> +    }
> +
> +    if ( !dt_property_read_u32(dev, "num-viewport", &priv->num_viewport) )
> +        priv->num_viewport = 2;
> +
> +    /*
> +     * FIXME: we cannot read iATU unroll enable now as the host bridge's
> +     * HW is not yet initialized by Domain-0: leave it for later.
> +     */
> +
> +    printk(XENLOG_INFO "%s number of view ports: %d\n", dt_node_full_name(dev),
> +           priv->num_viewport);
> +
> +    return bridge;
> +}
> diff --git a/xen/arch/arm/pci/pci-designware.h b/xen/arch/arm/pci/pci-designware.h
> new file mode 100644
> index 0000000000..df4a9afe75
> --- /dev/null
> +++ b/xen/arch/arm/pci/pci-designware.h
> @@ -0,0 +1,90 @@
> +/* SPDX-License-Identifier: GPL-2.0-only
> + *
> + * Based on Linux drivers/pci/controller/pci-host-common.c
> + * Based on Linux drivers/pci/controller/pci-host-generic.c
> + * Based on Linux drivers/pci/controller/dwc/pcie-designware.c
> + * Based on xen/arch/arm/pci/pci-host-generic.c
> + */
> +
> +#include 
> +#include 
> +
> +#ifndef __PCI_DESIGNWARE_H__
> +#define __PCI_DESIGNWARE_H__
> +
> +
> +#define PCIE_ATU_VIEWPORT               0x900
> +#define PCIE_ATU_REGION_OUTBOUND        0
> +#define PCIE_ATU_CR1                    0x904
> +#define PCIE_ATU_INCREASE_REGION_SIZE   BIT(13, UL)
> +#define PCIE_ATU_CR2                    0x908
> +#define PCIE_ATU_ENABLE                 BIT(31, UL)
> +#define PCIE_ATU_LOWER_BASE             0x90C
> +#define PCIE_ATU_UPPER_BASE             0x910
> +#define PCIE_ATU_LIMIT                  0x914
> +#define PCIE_ATU_LOWER_TARGET           0x918
> +#define PCIE_ATU_UPPER_TARGET           0x91C
> +#define PCIE_ATU_UPPER_LIMIT            0x924
> +
> +#define PCIE_ATU_REGION_INDEX1  0x1
> +#define PCIE_ATU_TYPE_IO        0x2
> +#define PCIE_ATU_TYPE_CFG0      0x4
> +
> +#define FIELD_PREP(_mask, _val) \
> +    (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask))
> +
> +#define PCIE_ATU_BUS(x)         FIELD_PREP(GENMASK(31, 24), (x))
> +#define PCIE_ATU_DEV(x)         FIELD_PREP(GENMASK(23, 19), (x))
> +#define PCIE_ATU_FUNC(x)        FIELD_PREP(GENMASK(18, 16), (x))
> +
> +/* Register address builder */
> +#define PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(region) \
> +    ((region) << 9)
> +
> +/*
> + * iATU Unroll-specific register definitions
> + * From 4.80 core version the address translation will be made by unroll
> + */
> +#define PCIE_ATU_UNR_REGION_CTRL1       0x00
> +#define PCIE_ATU_UNR_REGION_CTRL2       0x04
> +#define PCIE_ATU_UNR_LOWER_BASE         0x08
> +#define PCIE_ATU_UNR_UPPER_BASE         0x0C
> +#define PCIE_ATU_UNR_LOWER_LIMIT        0x10
> +#define PCIE_ATU_UNR_LOWER_TARGET       0x14
> +#define PCIE_ATU_UNR_UPPER_TARGET       0x18
> +#define PCIE_ATU_UNR_UPPER_LIMIT        0x20
> +
> +#define PCIE_ATU_FUNC_NUM(pf)           ((pf) << 20)
> +
> +/* Parameters for the waiting for iATU enabled routine */
> +#define LINK_WAIT_MAX_IATU_RETRIES      5
> +#define LINK_WAIT_IATU                  9
> +
> +struct dw_pcie_priv {
> +    uint32_t num_viewport;
> +    bool iatu_unroll_initilized;
> +    bool iatu_unroll_enabled;
> +    void __iomem *atu_base;
> +    unsigned int version;
> +};
> +
> +void dw_pcie_set_version(struct pci_host_bridge *bridge, unsigned int version);
> +
> +void __iomem *dw_pcie_child_map_bus(struct pci_host_bridge *bridge,
> +                                    pci_sbdf_t sbdf, uint32_t where);
> +
> +int dw_pcie_child_config_read(struct pci_host_bridge *bridge, pci_sbdf_t sbdf,
> +                              uint32_t reg, uint32_t len, uint32_t *value);
> +
> +int dw_pcie_child_config_write(struct pci_host_bridge *bridge, pci_sbdf_t sbdf,
> +                               uint32_t reg, uint32_t len, uint32_t value);
> +
> +bool __init dw_pcie_child_need_p2m_hwdom_mapping(struct domain *d,
> +                                                 struct pci_host_bridge *bridge,
> +                                                 uint64_t addr);
> +
> +struct pci_host_bridge *__init
> +dw_pcie_host_probe(struct dt_device_node *dev, const void *data,
> +                   const struct pci_ecam_ops *ops,
> +                   const struct pci_ecam_ops *child_ops);
> +#endif /* __PCI_DESIGNWARE_H__ */
> diff --git a/xen/arch/arm/pci/pci-host-rcar4.c b/xen/arch/arm/pci/pci-host-rcar4.c
> new file mode 100644
> index 0000000000..62d2130a63
> --- /dev/null
> +++ b/xen/arch/arm/pci/pci-host-rcar4.c
> @@ -0,0 +1,94 @@
> +/* SPDX-License-Identifier: GPL-2.0-only
> + *
> + * Based on Linux drivers/pci/controller/pci-host-common.c
> + * Based on Linux drivers/pci/controller/pci-host-generic.c
> + * Based on xen/arch/arm/pci/pci-host-generic.c
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "pci-designware.h"
> +
> +#define RCAR4_DWC_VERSION       0x520A
> +
> +/*
> + * PCI host bridges often have different ways to access the root and child
> + * bus config spaces:
> + *   "dbi"   : the aperture where root port's own configuration registers
> + *             are available.
> + *   "config": child's configuration space
> + *   "atu"   : iATU registers for DWC version 4.80 or later
> + */
> +static int __init rcar4_cfg_reg_index(struct dt_device_node *np)
> +{
> +    return dt_property_match_string(np, "reg-names", "dbi");
> +}
> +
> +static int __init rcar4_child_cfg_reg_index(struct dt_device_node *np)
> +{
> +    return dt_property_match_string(np, "reg-names", "config");
> +}
> +
> +/* ECAM ops */
> +const struct pci_ecam_ops rcar4_pcie_ops = {
> +    .bus_shift  = 20,
> +    .cfg_reg_index = rcar4_cfg_reg_index,
> +    .pci_ops    = {
> +        .map_bus                = pci_ecam_map_bus,
> +        .read                   = pci_generic_config_read,
> +        .write                  = pci_generic_config_write,
> +        .need_p2m_hwdom_mapping = pci_ecam_need_p2m_hwdom_mapping,
> +        .init_bus_range         = pci_generic_init_bus_range,
> +    }
> +};
> +
> +const struct pci_ecam_ops rcar4_pcie_child_ops = {
> +    .bus_shift  = 20,
> +    .cfg_reg_index = rcar4_child_cfg_reg_index,
> +    .pci_ops    = {
> +        .map_bus                = dw_pcie_child_map_bus,
> +        .read                   = dw_pcie_child_config_read,
> +        .write                  = dw_pcie_child_config_write,
> +        .need_p2m_hwdom_mapping = dw_pcie_child_need_p2m_hwdom_mapping,
> +        .init_bus_range         = pci_generic_init_bus_range_child,
> +    }
> +};
> +
> +static const struct dt_device_match __initconstrel rcar4_pcie_dt_match[] = {
> +    { .compatible = "renesas,r8a779f0-pcie" },
> +    { .compatible = "renesas,r8a779g0-pcie" },
> +    {},
> +};
> +
> +static int __init pci_host_rcar4_probe(struct dt_device_node *dev,
> +                                       const void *data)
> +{
> +    struct pci_host_bridge *bridge;
> +
> +    bridge = dw_pcie_host_probe(dev, data, &rcar4_pcie_ops,
> +                                &rcar4_pcie_child_ops);
> +
> +    dw_pcie_set_version(bridge, RCAR4_DWC_VERSION);
> +
> +    return 0;
> +}
> +
> +DT_DEVICE_START(pci_gen, "PCI HOST R-CAR GEN4", DEVICE_PCI_HOSTBRIDGE)
> +.dt_match = rcar4_pcie_dt_match,
> +.init = pci_host_rcar4_probe,
> +DT_DEVICE_END
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Thu May 29 01:18:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 01:18:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999741.1380357 (Exim 4.92)
	(envelope-from )
	id 1uKRuL-0005xR-Iy; Thu, 29 May 2025 01:18:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999741.1380357; Thu, 29 May 2025 01:18:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKRuL-0005xK-F6; Thu, 29 May 2025 01:18:09 +0000
Received: by outflank-mailman (input) for mailman id 999741;
 Thu, 29 May 2025 01:18:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKRuK-0005xC-Rn
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 01:18:08 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c62a66c4-3c2a-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 03:18:06 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 86729A4FAC9;
 Thu, 29 May 2025 01:18:05 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF6E9C4CEE3;
 Thu, 29 May 2025 01:18: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" 
X-Inumbo-ID: c62a66c4-3c2a-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748481485;
	bh=57RV3E5A42JGW6ivfifoP2OnwOh3Jp0JTfPxBr5ZSVQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=eHYLX4LY67IpYVn3fG7Wfmn0mbO/0Y53eD2GwZ9vlVqCU/v61DlzalPMkSwQGUMGk
	 neFtVuy/YO//zajbCA8rBMLIdCBJ/1yus1KPIvTJPrkRwab8gLGm8nX6C6M3bF6ONl
	 EtsyZ7UWmB5CP+pA5KhFhzYRyUGxD59ZPLKQWqoK/FxG4GQKQB/zhS4LZ8BQp76ur3
	 MvfbIQcM6cRo6/q/3Zcr6zB2zZl9dFphLTO3UfceqEKKVCMpAivcbi5SRBDo01ivZo
	 hgejAnjb/qvveATUdkClg0khUxAIE0avmEvio9s4Jgf4bVqtBBX8v9q/2iG65iF1QF
	 mBOGlFNl5hjgg==
Date: Wed, 28 May 2025 18:18:02 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Michal Orzel 
cc: xen-devel@lists.xenproject.org, 
    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] device-tree: Move Arm's static-evtchn feature to
 common
In-Reply-To: <20250527082117.120214-1-michal.orzel@amd.com>
Message-ID: 
References: <20250527082117.120214-1-michal.orzel@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 27 May 2025, Michal Orzel wrote:
> There's nothing Arm specific about this feature. Move it to common as
> part of a larger activity to commonalize device tree related features.
> For now, select it only for ARM until others (e.g. RISC-V) verify it
> works for them too.
> 
> Signed-off-by: Michal Orzel 

Reviewed-by: Stefano Stabellini 


> ---
> Other candidates: static memory, shared memory
> ---
>  xen/arch/arm/Kconfig                                      | 8 --------
>  xen/arch/arm/Makefile                                     | 1 -
>  xen/arch/arm/setup.c                                      | 2 +-
>  xen/common/Kconfig                                        | 8 ++++++++
>  xen/common/device-tree/Makefile                           | 1 +
>  xen/{arch/arm => common/device-tree}/static-evtchn.c      | 3 +--
>  xen/{arch/arm/include/asm => include/xen}/static-evtchn.h | 6 +++---
>  7 files changed, 14 insertions(+), 15 deletions(-)
>  rename xen/{arch/arm => common/device-tree}/static-evtchn.c (99%)
>  rename xen/{arch/arm/include/asm => include/xen}/static-evtchn.h (77%)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index a5aad97a688e..57919d8b3ac8 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -253,14 +253,6 @@ config STATIC_SHM
>  	help
>  	  This option enables statically shared memory on a dom0less system.
>  
> -config STATIC_EVTCHN
> -	bool "Static event channel support on a dom0less system"
> -	depends on DOM0LESS_BOOT
> -	default y
> -	help
> -	  This option enables establishing static event channel communication
> -	  between domains on a dom0less system (domU-domU as well as domU-dom0).
> -
>  config PARTIAL_EMULATION
>  	bool "Enable partial emulation of system/coprocessor registers"
>  	default y
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 129a109d6ec5..eeeac4e653ec 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -51,7 +51,6 @@ obj-y += setup.o
>  obj-y += shutdown.o
>  obj-y += smp.o
>  obj-y += smpboot.o
> -obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
>  obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
>  obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
>  obj-y += sysctl.o
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 10b46d068405..734e23da4408 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -39,7 +40,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 3d66d0939738..0951d4c2f286 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -162,6 +162,14 @@ config STATIC_MEMORY
>  
>  	  If unsure, say N.
>  
> +config STATIC_EVTCHN
> +	bool "Static event channel support on a dom0less system"
> +	depends on DOM0LESS_BOOT && ARM
> +	default y
> +	help
> +	  This option enables establishing static event channel communication
> +	  between domains on a dom0less system (domU-domU as well as domU-dom0).
> +
>  menu "Speculative hardening"
>  
>  config INDIRECT_THUNK
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 831b91399b74..2df7eb27222e 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.o
>  obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
>  obj-y += intc.o
>  obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
> +obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
> diff --git a/xen/arch/arm/static-evtchn.c b/xen/common/device-tree/static-evtchn.c
> similarity index 99%
> rename from xen/arch/arm/static-evtchn.c
> rename to xen/common/device-tree/static-evtchn.c
> index 49db08d5c6fc..8b82e6b3d8a6 100644
> --- a/xen/arch/arm/static-evtchn.c
> +++ b/xen/common/device-tree/static-evtchn.c
> @@ -1,8 +1,7 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
>  #include 
> -
> -#include 
> +#include 
>  
>  #define STATIC_EVTCHN_NODE_SIZE_CELLS 2
>  
> diff --git a/xen/arch/arm/include/asm/static-evtchn.h b/xen/include/xen/static-evtchn.h
> similarity index 77%
> rename from xen/arch/arm/include/asm/static-evtchn.h
> rename to xen/include/xen/static-evtchn.h
> index f964522f6a62..31ae92741aad 100644
> --- a/xen/arch/arm/include/asm/static-evtchn.h
> +++ b/xen/include/xen/static-evtchn.h
> @@ -1,7 +1,7 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
> -#ifndef __ASM_STATIC_EVTCHN_H_
> -#define __ASM_STATIC_EVTCHN_H_
> +#ifndef XEN_STATIC_EVTCHN_H
> +#define XEN_STATIC_EVTCHN_H
>  
>  #ifdef CONFIG_STATIC_EVTCHN
>  
> @@ -13,7 +13,7 @@ static inline void alloc_static_evtchn(void) {};
>  
>  #endif /* CONFIG_STATIC_EVTCHN */
>  
> -#endif /* __ASM_STATIC_EVTCHN_H_ */
> +#endif /* XEN_STATIC_EVTCHN_H */
>  
>  /*
>   * Local variables:
> -- 
> 2.25.1
> 


From xen-devel-bounces@lists.xenproject.org Thu May 29 02:10:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 02:10:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999755.1380367 (Exim 4.92)
	(envelope-from )
	id 1uKSj8-0005NM-43; Thu, 29 May 2025 02:10:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999755.1380367; Thu, 29 May 2025 02:10: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 1uKSj8-0005NF-1D; Thu, 29 May 2025 02:10:38 +0000
Received: by outflank-mailman (input) for mailman id 999755;
 Thu, 29 May 2025 02:10:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKSj7-0005N9-2q
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 02:10:37 +0000
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com
 [2607:f8b0:4864:20::b2b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1b60cbf4-3c32-11f0-a2fe-13f23c93f187;
 Thu, 29 May 2025 04:10:36 +0200 (CEST)
Received: by mail-yb1-xb2b.google.com with SMTP id
 3f1490d57ef6-e7311e66a8eso346943276.2
 for ; Wed, 28 May 2025 19:10:35 -0700 (PDT)
Received: from [10.138.10.6] ([45.134.140.51])
 by smtp.gmail.com with ESMTPSA id
 3f1490d57ef6-e7f733cd118sm89161276.20.2025.05.28.19.10.33
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 28 May 2025 19:10: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" 
X-Inumbo-ID: 1b60cbf4-3c32-11f0-a2fe-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748484635; x=1749089435; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=xgsYsWRQrwJopPuRltx1kxVmUJMAjcKC6cuG4q9IS8A=;
        b=Fl7yV22OQMRzVbhDWj1TIJRiLWXihE19NhGpqW/zWMxoxcBPluUseM7wB0jcQj26FO
         hY1NktQgXmCL4yh8KGS5s3bZ5ZeqHGYIRlvdQii5tv9kDGwtA+Sq2p/3GqZQDkB+1Neu
         6YcKajfc4OkbpBaPOn8bi+X8ZwT1TaUgsS8pnxTxY+rn30Je/DQPbeHpXWScwM7F+oRO
         pGZUlGZQqEX8QD5JFdrC4kUMoAB0d78gBEJz+2S+yK/vjFzCOAadWd+Ejhymm65uxd3s
         Vltt7iKIJamFwktGj7ytQ4Ng6uT1cQq2MhmVfOv8b94z5dKmMgg+xTzAad/HD5T3IYvs
         OS3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748484635; x=1749089435;
        h=in-reply-to:autocrypt:from:content-language:references:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=xgsYsWRQrwJopPuRltx1kxVmUJMAjcKC6cuG4q9IS8A=;
        b=lyB7OSw6/YwBdZQHIN7IqXhD8Ctvq9G8WiHHkvDaYmyz+DjhyGOkkBUJF4mda1S7q6
         CVFphI3XXsPMxNp28/SAxnJ4SpJUJVgfpbEv3Z1TEPh8ZxuGwT3p4wbcyM3Ok9ngPw7B
         wEqpbfo/qFeeML/rXbJxc+0w7Z4S7s9O2WAF9xKWYHeu9emoC8PoO8Zy1ANEZ6SLIiDi
         Rp1NRusPpE/qjx0COnmtC6yJJ8Chhooq25U9YzSmBYT/JNgefdV1e5mocgcb8vADeYKt
         9F5b7ct11+eKVy4WFApimvX6T5owrpU3T7h2EuohmhgwjvaGrGFxw0xilJE4FGZJClxy
         1Glg==
X-Gm-Message-State: AOJu0Yz1HAynT+fdda5QB3VIsUGUQ/jbAdthOwGi8775Q1MqqlNwkIxK
	Wq9VS4yEYUFs0Tqm38qr9q58YNPi/GwoGxuAKf8NI5I5byBIL5XhoK1+1gBkFw==
X-Gm-Gg: ASbGncuF/9DScUfM6VbVwRfbJKmx+5G6bc/Zrb3NDYcvfN7NQYkhpvHceXb3xEITa6L
	TfZv/bqbY7OTsyA6ZEDCS/wERseeGTeX2ajt5lV6vzM3dZk9nQjSid9MXWho/EMvTi7NBEcOkuG
	TsVYkuVcZ5NEvYtV2wTj8hAcrpHtMnO3Uo+URvvsGMKDZGdNBnQnSxW0c5yoRHE7E2TkT3BG731
	0F57Z2DAvwKz8j0JdYpCVB146y6qsuvjH1AyUM4ksiUgemi0b7uDpRTgAPiPD3XakPSMCWike8w
	vuEnCNUX5UoRN4jUDPz0o7yhbhwovgZCLjTZnq+hbDvKw+1wZl4TvD37FYhghP8FkQ==
X-Google-Smtp-Source: AGHT+IEdjKb5kNCKpmLykW+YcuFBHmSlrj+2iUW17oZ3RLZQSNY2Kfd5bbcmg3KsN+/uX17LLaPXkQ==
X-Received: by 2002:a05:6902:26c6:b0:e7f:6815:ce6f with SMTP id 3f1490d57ef6-e7f6815d071mr4368210276.23.1748484634644;
        Wed, 28 May 2025 19:10:34 -0700 (PDT)
Message-ID: <9bfc305b-602e-4c96-bd7a-763075e506d7@gmail.com>
Date: Wed, 28 May 2025 22:10:25 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for
 SMMUv3
To: xen-devel@lists.xenproject.org
References: 
 <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
Content-Language: en-US
From: Demi Marie Obenour 
Autocrypt: addr=demiobenour@gmail.com; keydata=
 xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd
 aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV
 Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT
 DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx
 wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR
 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl
 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2
 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N
 m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll
 IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE
 EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q
 AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS
 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz
 PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+
 VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR
 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a
 EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP
 tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny
 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ
 itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x
 Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/
 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv
 VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M
 kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO
 txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ
 riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN
 fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6
 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
 rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj
 kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46
 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b
 oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj
 gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr
 RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2
 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM
 OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
 Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5
 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO
 vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8
 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E
 +MYSfkEjBz0E8CLOcAw7JIwAaeBT
In-Reply-To: <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------30Z0W7Agk2Wso9aKLRElgnv0"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------30Z0W7Agk2Wso9aKLRElgnv0
Content-Type: multipart/mixed; boundary="------------0l4RY8JtTNNb7Wd8Ftdwk5Wj";
 protected-headers="v1"
From: Demi Marie Obenour 
To: xen-devel@lists.xenproject.org
Message-ID: <9bfc305b-602e-4c96-bd7a-763075e506d7@gmail.com>
Subject: Re: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for
 SMMUv3
References: 
 <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
In-Reply-To: <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>

--------------0l4RY8JtTNNb7Wd8Ftdwk5Wj
Content-Type: multipart/mixed; boundary="------------kRvswQJg6E2amMnsYZlCweiI"

--------------kRvswQJg6E2amMnsYZlCweiI
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/28/25 05:12, Mykyta Poturai wrote:
> From: Rahul Singh 
>=20
> Implement support for PCI devices in the SMMU driver. Trigger iommu-map=

> parsing when new PCI device is added. Add checks to assign/deassign
> functions to ensure PCI devices are handled correctly. Implement basic
> quarantining.
>=20
> All pci devices are automatically assigned to hardware domain if it exi=
sts
> to ensure it can probe them.
This is only safe for devices present at boot time.  It=E2=80=99s not saf=
e for
hotplugged devices, which should be quarantined.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
--------------kRvswQJg6E2amMnsYZlCweiI
Content-Type: application/pgp-keys; name="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB288B55FFF9C22C1.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49y
B+l2nipdaq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYf
bWpr/si88QKgyGSVZ7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/
UorR+FaSuVwT7rqzGrTlscnTDlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7M
MPCJwI8JpPlBedRpe9tfVyfu3euTPLPxwcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9H
zx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR6h3nBc3eyuZ+q62HS1pJ5EvU
T1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl5FMWo8TCniHynNXs
BtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2Bkg1b//r
6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C
9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nS
m9BBff0Nm0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQAB
zTxEZW1pIE9iZW5vdXIgKElUTCBFbWFpbCBLZXkpIDxhdGhlbmFAaW52aXNpYmxl
dGhpbmdzbGFiLmNvbT7CwY4EEwEIADgWIQR2h02fEza6IlkHHHGyiLVf/5wiwQUC
X6YJvQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCyiLVf/5wiwWRhD/0Y
R+YYC5Kduv/2LBgQJIygMsFiRHbR4+tWXuTFqgrxxFSlMktZ6gQrQCWe38WnOXkB
oY6n/5lSJdfnuGd2UagZ/9dkaGMUkqt+5WshLFly4BnP7pSsWReKgMP7etRTwn3S
zk1OwFx2lzY1EnnconPLfPBc6rWG2moA6l0WX+3WNR1B1ndqpl2hPSjT2jUCBWDV
rGOUSX7r5f1WgtBeNYnEXPBCUUM51pFGESmfHIXQrqFDA7nBNiIVFDJTmQzuEqIy
Jl67pKNgooij5mKzRhFKHfjLRAH4mmWZlB9UjDStAfFBAoDFHwd1HL5VQCNQdqEc
/9lZDApqWuCPadZN+pGouqLysesIYsNxUhJ7dtWOWHl0vs7/3qkWmWun/2uOJMQh
ra2u8nA9g91FbOobWqjrDd6x3ZJoGQf4zLqjmn/P514gb697788e573WN/MpQ5XI
Fl7aM2d6/GJiq6LC9T2gSUW4rbPBiqOCeiUx7Kd/sVm41p9TOA7fEG4bYddCfDsN
xaQJH6VRK3NOuBUGeL+iQEVF5Xs6Yp+U+jwvv2M5Lel3EqAYo5xXTx4ls0xaxDCu
fudcAh8CMMqx3fguSb7Mi31WlnZpk0fDuWQVNKyDP7lYpwc4nCCGNKCj622ZSocH
AcQmX28L8pJdLYacv9pU3jPy4fHcQYvmTavTqowGnM08RGVtaSBNYXJpZSBPYmVu
b3VyIChsb3ZlciBvZiBjb2RpbmcpIDxkZW1pb2Jlbm91ckBnbWFpbC5jb20+wsF4
BBMBAgAiBQJafgNKAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyiLVf
/5wiwYa/EACv8a2+MMou9cSCNoZBQaU+fTmyzft9hUE+0d5W2UY1RY3OsjFIzm9R
/4SVccfsqOYLEo+S0vQMIIIqFEq3FCpXXwPzyimotps05VA8U3Bd7yseojFygOgK
sAMOAee2RCaDDOnoJue01dfZMzzHPO/TVdp3OvnpWipfv5G1Xg96rwbhMLE3tg6N
xwAHa31Bv4/Xq8CJOoIWvx6fcmZQpz01/lSvsYn0KrfEbTKkuUf0vM9JrCTCP2oz
VNN5BYzqaq2M4r+jmSyeXLim922VOWqGkUEQ85BSEemqrRS06IU6NtEMsF8EWt/b
hWjk/9GDKTcnpdJHTrMxTspExBiNrvpI2t+YPU5B/dJJAUxvmhFrbSIbdB8umBZs
I3AMYrEmpAbh5x7jEjoskUC7uN3o9vpg1oCLS2ePDLtAtyBtbHnkA4xGD7ar8mem
xpH9lY/i+sC6CyyIUWcUDnnagKyJP0m9ks0GLsTeOCA0bft2XA6rD6aaCnMUsndT
ctrab42CV5XypjmC4U1rPJ8JQJUh1/3P48/8sMH+3krxpJ06KNWNFaUbaMTGiltZ
7x9DngklSYrX0T+2G4kVXNmjaljwkoLahwLla2gUWwBSyofXdqyhQdwZsp01KXNQ
UCyT/Pg+aDcm/E7OMV3d4lf7g/CSxiX2GSEe6BlhSz+Lmd7ZJ3g32M1ARGVtaSBN
YXJpZSBPYmVub3VyIChJVEwgRW1haWwgS2V5KSA8ZGVtaUBpbnZpc2libGV0aGlu
Z3NsYWIuY29tPsLBjgQTAQgAOBYhBHaHTZ8TNroiWQcccbKItV//nCLBBQJgOEV+
AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJELKItV//nCLBKwoP/1WSnFdv
SAD0g7fD0WlF+oi7ISFT7oqJnchFLOwVHK4Jg0e4hGn1ekWsF3Ha5tFLh4V/7UUu
obYJpTfBAA2CckspYBqLtKGjFxcaqjjpO1I2W/jeNELVtSYuCOZICjdNGw2Hl9yH
KRZiBkqc9u8lQcHDZKq4LIpVJj6ZQV/nxttDX90ax2No1nLLQXFbr5wb465LAPpU
lXwunYDij7xJGye+VUASQh9datye6orZYuJvNo8Tr3mAQxxkfR46LzWgxFCPEAZJ
5P56Nc0IMHdJZj0Uc9+1jxERhOGppp5jlLgYGK7faGB/jTV6LaRQ4Ad+xiqokDWp
mUOZsmA+bMbtPfYjDZBz5mlyHcIRKIFpE1l3Y8F7PhJuzzMUKkJi90CYakCV4x/a
Zs4pzk5E96c2VQx01RIEJ7fzHF7lwFdtfTS4YsLtAbQFsKayqwkGcVv2B1AHeqdo
TMX+cgDvjd1ZganGlWA8Sv9RkNSMchn1hMuTwERTyFTr2dKPnQdA1F480+jUap41
ClXgn227WkCIMrNhQGNyJsnwyzi5wS8rBVRQ3BOTMyvGM07j3axUOYaejEpg7wKi
wTPZGLGH1sz5GljD/916v5+v2xLbOo5606j9dWf5/tAhbPuqrQgWv41wuKDi+dDD
EKkODF7DHes8No+QcHTDyETMn1RYm7t0RKR4zsFNBFp+A0oBEAC9ynZI9LU+uJkM
eEJeJyQ/8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd
8xD57ue0eB47bcJvVqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPp
I4gfUbVEIEQuqdqQyO4GAe+MkD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalq
l1/iSyv1WYeC1OAs+2BLOAT2NEggSiVOtxEfgewsQtCWi8H1SoirakIfo45Hz0tk
/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJriwoaRIS8N2C8/nEM53jb1sH
0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcNfRAIUrNlatj9Txwi
vQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6dCxN0GNA
ORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA
rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog
2LNtcyCjkTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZA
grrnNz0iZG2DVx46x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJ
ELKItV//nCLBwNIP/AiIHE8boIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwj
jVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGjgn0TPtsGzelyQHipaUzEyrsceUGWYoKX
YyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8frRHnJdBcjf112PzQSdKC6kqU0
Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2E0rW4tBtDAn2HkT9
uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHMOBvy3Ehz
fAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o
Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVss
Z/rYZ9+51yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aW
emLLszcYz/u3XnbOvUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPt
hZlDnTnOT+C+OTsh8+m5tos8HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj
6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E+MYSfkEjBz0E8CLOcAw7JIwAaeBTzsFN
BGbyLVgBEACqClxh50hmBepTSVlan6EBq3OAoxhrAhWZYEwN78k+ENhK68KhqC5R
IsHzlL7QHW1gmfVBQZ63GnWiraM6wOJqFTL4ZWvRslga9u28FJ5XyK860mZLgYhK
9BzoUk4s+dat9jVUbq6LpQ1Ot5I9vrdzo2p1jtQ8h9WCIiFxSYy8s8pZ3hHh5T64
GIj1m/kY7lG3VIdUgoNiREGf/iOMjUFjwwE9ZoJ26j9p7p1U+TkKeF6wgswEB1T3
J8KCAtvmRtqJDq558IU5jhg5fgN+xHB8cgvUWulgK9FIF9oFxcuxtaf/juhHWKMO
RtL0bHfNdXoBdpUDZE+mLBUAxF6KSsRrvx6AQyJs7VjgXJDtQVWvH0PUmTrEswgb
49nNU+dLLZQAZagxqnZ9Dp5l6GqaGZCHERJcLmdY/EmMzSf5YazJ6c0vO8rdW27M
kn73qcWAplQn5mOXaqbfzWkAUPyUXppuRHfrjxTDz3GyJJVOeMmMrTxH4uCaGpOX
Z8tN6829J1roGw4oKDRUQsaBAeEDqizXMPRc+6U9vI5FXzbAsb+8lKW65G7JWHym
YPOGUt2hK4DdTA1PmVo0DxH00eWWeKxqvmGyX+Dhcg+5e191rPsMRGsDlH6KihI6
+3JIuc0y6ngdjcp6aalbuvPIGFrCRx3tnRtNc7He6cBWQoH9RPwluwARAQABwsOs
BBgBCgAgFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmbyLVgCGwICQAkQsoi1X/+c
IsHBdCAEGQEKAB0WIQSilC2pUlbVp66j3+yzNoc6synyUwUCZvItWAAKCRCzNoc6
synyU85gD/0T1QDtPhovkGwoqv4jUbEMMvpeYQf+oWgm/TjWPeLwdjl7AtY0G9Ml
ZoyGniYkoHi37Gnn/ShLT3B5vtyI58ap2+SSa8SnGftdAKRLiWFWCiAEklm9FRk8
N3hwxhmSFF1KR/AIDS4g+HIsZn7YEMubBSgLlZZ9zHl4O4vwuXlREBEW97iL/FSt
VownU2V39t7PtFvGZNk+DJH7eLO3jmNRYB0PL4JOyyda3NH/J92iwrFmjFWWmmWb
/Xz8l9DIs+Z59pRCVTTwbBEZhcUc7rVMCcIYL+q1WxBG2e6lMn15OQJ5WfiE6E0I
sGirAEDnXWx92JNGx5l+mMpdpsWhBZ5iGTtttZesibNkQfd48/eCgFi4cxJUC4PT
UQwfD9AMgzwSTGJrkI5XGy+XqxwOjL8UA0iIrtTpMh49zw46uV6kwFQCgkf32jZM
OLwLTNSzclbnA7GRd8tKwezQ/XqeK3dal2n+cOr+o+Eka7yGmGWNUqFbIe8cjj9T
JeF3mgOCmZOwMI+wIcQYRSf+e5VTMO6TNWH5BI3vqeHSt7HkYuPlHT0pGum88d4a
pWqhulH4rUhEMtirX1hYx8Q4HlUOQqLtxzmwOYWkhl1C+yPObAvUDNiHCLf9w28n
uihgEkzHt9J4VKYulyJM9fe3ENcyU6rpXD7iANQqcr87ogKXFxknZ97uEACvSucc
RbnnAgRqZ7GDzgoBerJ2zrmhLkeREZ08iz1zze1JgyW3HEwdr2UbyAuqvSADCSUU
GN0vtQHsPzWl8onRc7lOPqPDF8OO+UfN9NAfA4wl3QyChD1GXl9rwKQOkbvdlYFV
UFx9u86LNi4ssTmU8p9NtHIGpz1SYMVYNoYy9NU7EVqypGMguDCL7gJt6GUmA0sw
p+YCroXiwL2BJ7RwRqTpgQuFL1gShkA17D5jK4mDPEetq1d8kz9rQYvAR/sTKBsR
ImC3xSfn8zpWoNTTB6lnwyP5Ng1bu6esS7+SpYprFTe7ZqGZF6xhvBPf1Ldi9UAm
U2xPN1/eeWxEa2kusidmFKPmN8lcT4miiAvwGxEnY7Oww9CgZlUB+LP4dl5VPjEt
sFeAhrgxLdpVTjPRRwTd9VQF3/XYl83j5wySIQKIPXgT3sG3ngAhDhC8I8GpM36r
8WJJ3x2yVzyJUbBPO0GBhWE2xPNIfhxVoU4cGGhpFqz7dPKSTRDGq++MrFgKKGpI
ZwT3CPTSSKc7ySndEXWkOYArDIdtyxdE1p5/c3aoz4utzUU7NDHQ+vVIwlnZSMiZ
jek2IJP3SZ+COOIHCVxpUaZ4lnzWT4eDqABhMLpIzw6NmGfg+kLBJhouqz81WITr
EtJuZYM5blWncBOJCoWMnBEcTEo/viU3GgcVRw=3D=3D
=3Dx94R
-----END PGP PUBLIC KEY BLOCK-----

--------------kRvswQJg6E2amMnsYZlCweiI--

--------------0l4RY8JtTNNb7Wd8Ftdwk5Wj--

--------------30Z0W7Agk2Wso9aKLRElgnv0
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmg3whIACgkQszaHOrMp
8lMnCg//YlJW3y2omMJfX6oz81u0WevDNEhmM3S1cvbyyHZDyPRQMtjLsI0Clw22
ROlqUbiZeYh09gaSdrIDL4rVMKQoNvqzUtax+0zFiuKvmmvsFEOUEzZXlLuydTZv
70LZBiV9N+KxhRGRDMF3SSvTXBThOF57Yump1/WMiAneGHKwBI23SypbYgpo2I7a
g1gRAotMsB6iKDGZzZRb926GdCv+j3RPRkvFAnHMCr81Srb3IGeIKZR68feSUMbh
8e1JxNU70qrZO4YKWhurb6wag8U9JPPzmd9dZl5aN4kteJkyMliHd4CLn37rQiyL
ljJcuD3T9UtiITZPK5AacKuEEXZsM5VJUMXGjfA0aeAuyvbiFyEw/kW6OctjTIhY
d7AeKjOQUAyr9djEXY/ugTs42hgp0DC00XRdKa1YqcfbD0LuQJ3ZiD6BsfVu6n7M
dC/68/WkZd5Pa0VRk3prufJCLj9mdqj73KkqP4djWElOrhHfkLjiP3oHbrCEHvfn
FZm/wOCwE7YLyMNyi8FPbi42d0nlxrEuwohhsl7tQuqKR/jp7EhT5n+Jv181LGVX
0/xNnAOp+g9HW9FBMYfZknN1xgqmfef3GrpfLtGIit9nVh/SDvExrh00NW3RtQgk
49Jl8jt+Yz6nkSPkxDIjXv+hvspD86R0I4gOeEzeAt148CDtbXQ=
=kqGl
-----END PGP SIGNATURE-----

--------------30Z0W7Agk2Wso9aKLRElgnv0--


From xen-devel-bounces@lists.xenproject.org Thu May 29 07:49:01 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 07:49:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999831.1380378 (Exim 4.92)
	(envelope-from )
	id 1uKY0N-0000Mv-LM; Thu, 29 May 2025 07:48:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999831.1380378; Thu, 29 May 2025 07: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 1uKY0N-0000Mo-IS; Thu, 29 May 2025 07:48:47 +0000
Received: by outflank-mailman (input) for mailman id 999831;
 Thu, 29 May 2025 07:48:46 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uKY0L-0000Mi-UO
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 07:48:45 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uKY0L-008FOg-0i;
 Thu, 29 May 2025 07:48:45 +0000
Received: from [2a02:8012:3a1:0:d557:39f4:e427:823c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uKY0L-00CP5B-0t;
 Thu, 29 May 2025 07:48: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=FN7tu5y7Uvq8o9wCUDBTl/GSeaIdeAgpGe0geFfmOTk=; b=GqBwBi7fflLoYPalsHGEorR4gN
	xqQOVwiuFtDhzM9EN+5f28fsbtdm2M/a1ipK+kLUVEdujfCX2/KyjSum+PWQ8KoSwx3SJ+C9pmNjY
	g3GCc+ITdX+wCAyrnXmy9+Hn5Q2mlrpb8OWuw0HN9WH37kjbP+0RCDdxuJTi4GevC9Hw=;
Message-ID: <357b1e9a-fdfc-4895-9f75-7b0256a57032@xen.org>
Date: Thu, 29 May 2025 08:48:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 4/4] xen/arm: add support for R-Car Gen4 PCI host
 controller
To: Mykyta Poturai ,
 "xen-devel@lists.xenproject.org" 
Cc: Oleksandr Andrushchenko ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: 
 <06f5972dda6a8132be8eab5ad1b8586ff3c5aaf3.1747820844.git.mykyta_poturai@epam.com>
Content-Language: en-GB
From: Julien Grall 
In-Reply-To: <06f5972dda6a8132be8eab5ad1b8586ff3c5aaf3.1747820844.git.mykyta_poturai@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 21/05/2025 13:21, Mykyta Poturai wrote:
> From: Oleksandr Andrushchenko 
> 
> Add support for Renesas R-Car Gen4 PCI host controller, specifically
> targeting the S4 and V4H SoCs. The implementation includes configuration
> read/write operations for both root and child buses. For accessing the
> child bus, iATU is used for address translation.
> 
> The host controller needs to be initialized by Dom0 first to be properly
> handled by Xen. Xen itself only handles the runtime configuration of
> the iATU for accessing different child devices.
> 
> iATU programming is done similarly to Linux, where only window 0 is used
> for dynamic configuration, and it is reconfigured for every config space
> read/write.
> 
> Code common to all DesignWare PCI host controllers is located in a
> separate file to allow for easy reuse in other DesignWare-based PCI
> host controllers.

Given this...

> 
> Signed-off-by: Oleksandr Andrushchenko 
> Signed-off-by: Mykyta Poturai 
> ---
> v4->v5:
> * update license identifiers
> * improve error checking
> * use XENLOG_G_* where needed
> * make macro defs more robust and minor style fixes
> * add MAINTANERS entry
> 
> v3->v4:
> * no changes
> 
> v2->v3:
> * move priv allocation to dw_pcie_host_probe
> 
> v1->v2:
> * move designware code in a separate file
> ---
>   MAINTAINERS                       |   6 +
>   xen/arch/arm/pci/Makefile         |   2 +
>   xen/arch/arm/pci/pci-designware.c | 416 ++++++++++++++++++++++++++++++
>   xen/arch/arm/pci/pci-designware.h |  90 +++++++
>   xen/arch/arm/pci/pci-host-rcar4.c |  94 +++++++
>   5 files changed, 608 insertions(+)
>   create mode 100644 xen/arch/arm/pci/pci-designware.c
>   create mode 100644 xen/arch/arm/pci/pci-designware.h
>   create mode 100644 xen/arch/arm/pci/pci-host-rcar4.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c11b82eca9..dc1291e2b0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -476,6 +476,12 @@ M:	Anthony Perard 
>   S:	Supported
>   T:	git https://xenbits.xenproject.org/git-http/qemu-xen.git
>   
> +RCAR PCI
> +M:	Mykyta Poturai 
> +S:	Supported
> +F:	xen/arch/arm/pci/pci-host-rcar4.c
> +F:	xen/arch/arm/pci/pci-designware*

... I don't think pci-designware should be under the category "RCAR 
PCI". It should go under ARM.

> +
>   REMUS
>   S:	Orphan
>   F:	docs/README.remus
> diff --git a/xen/arch/arm/pci/Makefile b/xen/arch/arm/pci/Makefile
> index 1d045ade01..ca6135e282 100644
> --- a/xen/arch/arm/pci/Makefile
> +++ b/xen/arch/arm/pci/Makefile
> @@ -4,3 +4,5 @@ obj-y += pci-host-generic.o
>   obj-y += pci-host-common.o
>   obj-y += ecam.o
>   obj-y += pci-host-zynqmp.o
> +obj-y += pci-designware.o
> +obj-y += pci-host-rcar4.o
> diff --git a/xen/arch/arm/pci/pci-designware.c b/xen/arch/arm/pci/pci-designware.c
> new file mode 100644
> index 0000000000..fc8c6724f2
> --- /dev/null
> +++ b/xen/arch/arm/pci/pci-designware.c
> @@ -0,0 +1,416 @@
> +/* SPDX-License-Identifier: GPL-2.0-only
> + *
> + * Based on Linux drivers/pci/controller/pci-host-common.c
> + * Based on Linux drivers/pci/controller/pci-host-generic.c
> + * Based on Linux drivers/pci/controller/dwc/pcie-designware.c
> + * Based on xen/arch/arm/pci/pci-host-generic.c
> + *
> + */
> +
> +#include 
> +#include 
> +
> +#include "pci-designware.h"
> +/**
> + * upper_32_bits - return bits 32-63 of a number
> + * @n: the number we're accessing
> + *
> + * A basic shift-right of a 64- or 32-bit quantity.  Use this to suppress
> + * the "right shift count >= width of type" warning when that quantity is
> + * 32-bits.
> + */
> +#define upper_32_bits(n) ((uint32_t)(((n) >> 16) >> 16))
> +
> +/**
> + * lower_32_bits - return bits 0-31 of a number
> + * @n: the number we're accessing
> + */
> +#define lower_32_bits(n) ((uint32_t)((n) & 0xffffffffU))
> +
> +static int dw_pcie_read(void __iomem *addr, int len, uint32_t *val)

As you switched to Xen coding style below: unlike Linux, we prefer using 
"unsigned int" when a value is not be signed.

 > +{> +    if ( !IS_ALIGNED((uintptr_t)addr, len) )
> +    {
> +        *val = 0;
> +        return -EFAULT;
> +    }
> +
> +    switch ( len )
> +    {
> +    case 1:
> +        *val = readb(addr);
> +        break;
> +    case 2:
> +        *val = readw(addr);
> +        break;
> +    case 4:
> +        *val = readl(addr);
> +        break;
> +    default:
> +        ASSERT_UNREACHABLE();
> +    }
> +
> +    return 0;
> +}
> +
> +static int dw_pcie_write(void __iomem *addr, int len, uint32_t val)
> +{
> +    if ( !IS_ALIGNED((uintptr_t)addr, len) )
> +        return -EFAULT;
> +
> +    switch ( len )
> +    {
> +    case 1:
> +        writeb(val, addr);
> +        break;
> +    case 2:
> +        writew(val, addr);
> +        break;
> +    case 4:
> +        writel(val, addr);
> +        break;
> +    default:
> +        ASSERT_UNREACHABLE();
> +    }
> +
> +    return 0;
> +}
> +
> +static uint32_t dw_pcie_read_dbi(struct pci_host_bridge *bridge, uint32_t reg,
> +                                 size_t size)
> +{
> +    void __iomem *addr = bridge->cfg->win + reg;
> +    uint32_t val;
> +    int ret;
> +
> +    ret = dw_pcie_read(addr, size, &val);
> +    if ( ret )
> +        printk(XENLOG_G_ERR "Read DBI address failed\n");
> +
> +    return val;
> +}
> +
> +static void dw_pcie_write_dbi(struct pci_host_bridge *bridge, uint32_t reg,
> +                              size_t size, uint32_t val)
> +{
> +    void __iomem *addr = bridge->cfg->win + reg;
> +    int ret;
> +
> +    ret = dw_pcie_write(addr, size, val);
> +    if ( ret )
> +        printk(XENLOG_G_ERR "Write DBI address failed\n");
> +}
> +
> +static uint32_t dw_pcie_readl_dbi(struct pci_host_bridge *bridge, uint32_t reg)
> +{
> +    return dw_pcie_read_dbi(bridge, reg, sizeof(uint32_t));
> +}
> +
> +static void dw_pcie_writel_dbi(struct pci_host_bridge *pci, uint32_t reg,
> +                               uint32_t val)
> +{
> +    dw_pcie_write_dbi(pci, reg, sizeof(uint32_t), val);
> +}
> +
> +static void dw_pcie_read_iatu_unroll_enabled(struct pci_host_bridge *bridge)
> +{
> +    struct dw_pcie_priv *priv = bridge->priv;
> +    uint32_t val;
> +
> +    val = dw_pcie_readl_dbi(bridge, PCIE_ATU_VIEWPORT);
> +    if ( val == 0xffffffffU )
> +        priv->iatu_unroll_enabled = true;
> +
> +    printk(XENLOG_G_DEBUG "%s iATU unroll: %sabled\n",
> +           dt_node_full_name(bridge->dt_node),
> +           priv->iatu_unroll_enabled ? "en" : "dis");
> +}
> +
> +static uint32_t dw_pcie_readl_atu(struct pci_host_bridge *pci, uint32_t reg)
> +{
> +    struct dw_pcie_priv *priv = pci->priv;
> +    int ret;
> +    uint32_t val;
> +
> +    ret = dw_pcie_read(priv->atu_base + reg, 4, &val);
> +    if ( ret )
> +        printk(XENLOG_G_ERR "Read ATU address failed\n");

I think it would be helpful to print the register. Same ...

> +
> +    return val;
> +}
> +
> +static void dw_pcie_writel_atu(struct pci_host_bridge *pci, uint32_t reg,
> +                               uint32_t val)
> +{
> +    struct dw_pcie_priv *priv = pci->priv;
> +    int ret;
> +
> +    ret = dw_pcie_write(priv->atu_base + reg, 4, val);
> +    if ( ret )
> +        printk(XENLOG_G_ERR "Write ATU address failed\n");

... here.

> +}
> +
> +static uint32_t dw_pcie_readl_ob_unroll(struct pci_host_bridge *pci,
> +                                        uint32_t index, uint32_t reg)
> +{
> +    uint32_t offset = PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
> +
> +    return dw_pcie_readl_atu(pci, offset + reg);
> +}
> +
> +static void dw_pcie_writel_ob_unroll(struct pci_host_bridge *pci,
> +                                     uint32_t index, uint32_t reg, uint32_t val)
> +{
> +    uint32_t offset = PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
> +
> +    dw_pcie_writel_atu(pci, offset + reg, val);
> +}
> +
> +static uint32_t dw_pcie_enable_ecrc(uint32_t val)
> +{
> +    ASSERT_UNREACHABLE();

Can you add a comment explaning why this function is not supposed to be 
called? And if we trigger it, then what does it mean?

> +    return 0;
> +}
 > +> +static int dw_pcie_prog_outbound_atu_unroll(struct 
pci_host_bridge *pci,
> +                                            uint8_t func_no, int index,
> +                                            int type, uint64_t cpu_addr,
> +                                            uint64_t pci_addr, uint64_t size)
> +{
> +    struct dw_pcie_priv *priv = pci->priv;
> +    uint32_t retries, val;
> +    uint64_t limit_addr = cpu_addr + size - 1;
> +
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_BASE,
> +                             lower_32_bits(cpu_addr));
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_BASE,
> +                             upper_32_bits(cpu_addr));
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_LIMIT,
> +                             lower_32_bits(limit_addr));
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_LIMIT,
> +                             upper_32_bits(limit_addr));
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_TARGET,
> +                             lower_32_bits(pci_addr));
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
> +                             upper_32_bits(pci_addr));
> +    val = type | PCIE_ATU_FUNC_NUM(func_no);
> +    val = upper_32_bits(size - 1) ? val | PCIE_ATU_INCREASE_REGION_SIZE : val;
> +    if ( priv->version == 0x490A )
> +        val = dw_pcie_enable_ecrc(val);
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1, val);
> +    dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
> +                             PCIE_ATU_ENABLE);
> +
> +    /*
> +     * Make sure ATU enable takes effect before any subsequent config
> +     * and I/O accesses.
> +     */
> +    for ( retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++ )
> +    {
> +        val = dw_pcie_readl_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2);
> +        if ( val & PCIE_ATU_ENABLE )
> +            return 0;
> +
> +        mdelay(LINK_WAIT_IATU);
> +    }
> +    printk(XENLOG_G_ERR "Outbound iATU is not being enabled\n");
> +
> +    return -ENXIO;
> +}
> +
> +static int __dw_pcie_prog_outbound_atu(struct pci_host_bridge *pci,
> +                                       uint8_t func_no, int index, int type,
> +                                       uint64_t cpu_addr, uint64_t pci_addr,
> +                                       uint64_t size)
> +{
> +    struct dw_pcie_priv *priv = pci->priv;
> +    uint32_t retries, val;
> +
> +    if ( priv->iatu_unroll_enabled )
> +        return dw_pcie_prog_outbound_atu_unroll(pci, func_no, index, type,
> +                                                cpu_addr, pci_addr, size);
> +
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT,
> +                       PCIE_ATU_REGION_OUTBOUND | index);
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_BASE, lower_32_bits(cpu_addr));
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_BASE, upper_32_bits(cpu_addr));
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_LIMIT, lower_32_bits(cpu_addr + size - 1));
> +    if ( priv->version >= 0x460A )
> +        dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_LIMIT,
> +                           upper_32_bits(cpu_addr + size - 1));
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_TARGET, lower_32_bits(pci_addr));
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET, upper_32_bits(pci_addr));
> +    val = type | PCIE_ATU_FUNC_NUM(func_no);
> +    val = ((upper_32_bits(size - 1)) && (priv->version >= 0x460A))
> +              ? val | PCIE_ATU_INCREASE_REGION_SIZE
> +              : val;
> +    if ( priv->version == 0x490A )
> +        val = dw_pcie_enable_ecrc(val);
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, val);
> +    dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE);
> +
> +    /*
> +     * Make sure ATU enable takes effect before any subsequent config
> +     * and I/O accesses.
> +     */
> +    for ( retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++ )
> +    {
> +        val = dw_pcie_readl_dbi(pci, PCIE_ATU_CR2);
> +        if ( val & PCIE_ATU_ENABLE )
> +            return 0;
> +
> +        mdelay(LINK_WAIT_IATU);
> +    }
> +    printk(XENLOG_G_ERR "Outbound iATU is not being enabled\n");
> +
> +    return -ENXIO;
> +}
> +
> +static int dw_pcie_prog_outbound_atu(struct pci_host_bridge *pci, int index,
> +                                     int type, uint64_t cpu_addr,
> +                                     uint64_t pci_addr, uint64_t size)
> +{
> +    return __dw_pcie_prog_outbound_atu(pci, 0, index, type, cpu_addr, pci_addr,
> +                                       size);
> +}
> +
> +void dw_pcie_set_version(struct pci_host_bridge *bridge, unsigned int version)
> +{
> +    struct dw_pcie_priv *priv = bridge->priv;
> +
> +    priv->version = version;
> +}
> +
> +void __iomem *dw_pcie_child_map_bus(struct pci_host_bridge *bridge,
> +                                    pci_sbdf_t sbdf, uint32_t where)
> +{
> +    uint32_t busdev;
> +    int ret;
> +
> +    busdev = PCIE_ATU_BUS(sbdf.bus) | PCIE_ATU_DEV(PCI_SLOT(sbdf.devfn)) |
> +             PCIE_ATU_FUNC(PCI_FUNC(sbdf.devfn));
> +
> +    /* FIXME: Parent is the root bus, so use PCIE_ATU_TYPE_CFG0. */
> +    ret = dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
> +                                    PCIE_ATU_TYPE_CFG0,
> +                                    bridge->child_cfg->phys_addr, busdev,
> +                                    bridge->child_cfg->size);
> +    if ( ret )
> +        return 0;
> +
> +    return bridge->child_cfg->win + where;
> +}
> +
> +int dw_pcie_child_config_read(struct pci_host_bridge *bridge, pci_sbdf_t sbdf,
> +                              uint32_t reg, uint32_t len, uint32_t *value)
> +{
> +    struct dw_pcie_priv *priv = bridge->priv;
> +    int ret;
> +
> +    /*
> +     * FIXME: we cannot read iATU settings at the early initialization
> +     * (probe) as the host's HW is not yet initialized at that phase.
> +     * This read operation is the very first thing Domain-0 will do
> +     * during its initialization, so take this opportunity and read
> +     * iATU setting now.
> +     */
> +    if ( unlikely(!priv->iatu_unroll_initilized) )
> +    {
> +        dw_pcie_read_iatu_unroll_enabled(bridge);
> +        priv->iatu_unroll_initilized = true;
> +    }
> +
> +    ret = pci_generic_config_read(bridge, sbdf, reg, len, value);
> +    if ( !ret && (priv->num_viewport <= 2) )
> +        ret = dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
> +                                        PCIE_ATU_TYPE_IO,
> +                                        bridge->child_cfg->phys_addr, 0,
> +                                        bridge->child_cfg->size);
> +
> +    return ret;
> +}
> +
> +int dw_pcie_child_config_write(struct pci_host_bridge *bridge, pci_sbdf_t sbdf,
> +                               uint32_t reg, uint32_t len, uint32_t value)
> +{
> +    struct dw_pcie_priv *priv = bridge->priv;
> +    int ret;
> +
> +    ret = pci_generic_config_write(bridge, sbdf, reg, len, value);
> +    if ( !ret && (priv->num_viewport <= 2) )
> +        ret = dw_pcie_prog_outbound_atu(bridge, PCIE_ATU_REGION_INDEX1,
> +                                        PCIE_ATU_TYPE_IO,
> +                                        bridge->child_cfg->phys_addr, 0,
> +                                        bridge->child_cfg->size);
> +    return ret;
> +}
> +
> +bool __init dw_pcie_child_need_p2m_hwdom_mapping(struct domain *d,
> +                                                 struct pci_host_bridge *bridge,
> +                                                 uint64_t addr)
> +{
> +    struct pci_config_window *cfg = bridge->child_cfg;
> +
> +    /*
> +     * We do not want ECAM address space to be mapped in Domain-0's p2m,
> +     * so we can trap access to it.
> +     */
> +    return cfg->phys_addr != addr;
> +}
> +
> +struct pci_host_bridge *__init
> +dw_pcie_host_probe(struct dt_device_node *dev, const void *data,
> +                   const struct pci_ecam_ops *ops,
> +                   const struct pci_ecam_ops *child_ops)
> +{
> +    struct pci_host_bridge *bridge;
> +    struct dw_pcie_priv *priv;
> +
> +    paddr_t atu_phys_addr;
> +    paddr_t atu_size;
> +    int atu_idx, ret;
> +
> +    bridge = pci_host_common_probe(dev, ops, child_ops);
> +    if ( IS_ERR(bridge) )
> +        return bridge;
> +
> +    priv = xzalloc(struct dw_pcie_priv);
> +    if ( !priv )
> +        return ERR_PTR(-ENOMEM);
> +
> +    bridge->priv = priv;
> +
> +    atu_idx = dt_property_match_string(dev, "reg-names", "atu");
> +    if ( atu_idx < 0 )
> +    {
> +        printk(XENLOG_ERR "Cannot find \"atu\" range index in device tree\n");
> +        return ERR_PTR(atu_idx);
> +    }
> +    ret = dt_device_get_address(dev, atu_idx, &atu_phys_addr, &atu_size);
> +    if ( ret )
> +    {
> +        printk(XENLOG_ERR "Cannot find \"atu\" range in device tree\n");
> +        return ERR_PTR(ret);
> +    }
> +    printk("iATU at [mem 0x%" PRIpaddr "-0x%" PRIpaddr "]\n", atu_phys_addr,
> +           atu_phys_addr + atu_size - 1);
> +    priv->atu_base = ioremap_nocache(atu_phys_addr, atu_size);
> +    if ( !priv->atu_base )
> +    {
> +        printk(XENLOG_ERR "iATU ioremap failed\n");
> +        return ERR_PTR(ENXIO);
> +    }
> +
> +    if ( !dt_property_read_u32(dev, "num-viewport", &priv->num_viewport) )
> +        priv->num_viewport = 2;
> +
> +    /*
> +     * FIXME: we cannot read iATU unroll enable now as the host bridge's
> +     * HW is not yet initialized by Domain-0: leave it for later.
> +     */
> +
> +    printk(XENLOG_INFO "%s number of view ports: %d\n", dt_node_full_name(dev),
> +           priv->num_viewport);
> +
> +    return bridge;
> +}
> diff --git a/xen/arch/arm/pci/pci-designware.h b/xen/arch/arm/pci/pci-designware.h
> new file mode 100644
> index 0000000000..df4a9afe75
> --- /dev/null
> +++ b/xen/arch/arm/pci/pci-designware.h
> @@ -0,0 +1,90 @@
> +/* SPDX-License-Identifier: GPL-2.0-only
> + *
> + * Based on Linux drivers/pci/controller/pci-host-common.c
> + * Based on Linux drivers/pci/controller/pci-host-generic.c
> + * Based on Linux drivers/pci/controller/dwc/pcie-designware.c
> + * Based on xen/arch/arm/pci/pci-host-generic.c
> + */
> +
> +#include 
> +#include 
> +
> +#ifndef __PCI_DESIGNWARE_H__
> +#define __PCI_DESIGNWARE_H__
> +
> +
> +#define PCIE_ATU_VIEWPORT               0x900
> +#define PCIE_ATU_REGION_OUTBOUND        0
> +#define PCIE_ATU_CR1                    0x904
> +#define PCIE_ATU_INCREASE_REGION_SIZE   BIT(13, UL)
> +#define PCIE_ATU_CR2                    0x908
> +#define PCIE_ATU_ENABLE                 BIT(31, UL)
> +#define PCIE_ATU_LOWER_BASE             0x90C
> +#define PCIE_ATU_UPPER_BASE             0x910
> +#define PCIE_ATU_LIMIT                  0x914
> +#define PCIE_ATU_LOWER_TARGET           0x918
> +#define PCIE_ATU_UPPER_TARGET           0x91C
> +#define PCIE_ATU_UPPER_LIMIT            0x924
> +
> +#define PCIE_ATU_REGION_INDEX1  0x1
> +#define PCIE_ATU_TYPE_IO        0x2
> +#define PCIE_ATU_TYPE_CFG0      0x4
> +
> +#define FIELD_PREP(_mask, _val) \
> +    (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask))
> +
> +#define PCIE_ATU_BUS(x)         FIELD_PREP(GENMASK(31, 24), (x))
> +#define PCIE_ATU_DEV(x)         FIELD_PREP(GENMASK(23, 19), (x))
> +#define PCIE_ATU_FUNC(x)        FIELD_PREP(GENMASK(18, 16), (x))
> +
> +/* Register address builder */
> +#define PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(region) \
> +    ((region) << 9)
> +
> +/*
> + * iATU Unroll-specific register definitions
> + * From 4.80 core version the address translation will be made by unroll
> + */
> +#define PCIE_ATU_UNR_REGION_CTRL1       0x00
> +#define PCIE_ATU_UNR_REGION_CTRL2       0x04
> +#define PCIE_ATU_UNR_LOWER_BASE         0x08
> +#define PCIE_ATU_UNR_UPPER_BASE         0x0C
> +#define PCIE_ATU_UNR_LOWER_LIMIT        0x10
> +#define PCIE_ATU_UNR_LOWER_TARGET       0x14
> +#define PCIE_ATU_UNR_UPPER_TARGET       0x18
> +#define PCIE_ATU_UNR_UPPER_LIMIT        0x20
> +
> +#define PCIE_ATU_FUNC_NUM(pf)           ((pf) << 20)
> +
> +/* Parameters for the waiting for iATU enabled routine */
> +#define LINK_WAIT_MAX_IATU_RETRIES      5
> +#define LINK_WAIT_IATU                  9

It would be helpful to either rename or add a comment explaining the 
unit. I also noticed, that Linux wait up to 10ms. Can you explain why 
Xen only need 9?

> +
> +struct dw_pcie_priv {
> +    uint32_t num_viewport;
> +    bool iatu_unroll_initilized;
> +    bool iatu_unroll_enabled;
> +    void __iomem *atu_base;
> +    unsigned int version;
> +};
> +
> +void dw_pcie_set_version(struct pci_host_bridge *bridge, unsigned int version);
> +
> +void __iomem *dw_pcie_child_map_bus(struct pci_host_bridge *bridge,
> +                                    pci_sbdf_t sbdf, uint32_t where);
> +
> +int dw_pcie_child_config_read(struct pci_host_bridge *bridge, pci_sbdf_t sbdf,
> +                              uint32_t reg, uint32_t len, uint32_t *value);
> +
> +int dw_pcie_child_config_write(struct pci_host_bridge *bridge, pci_sbdf_t sbdf,
> +                               uint32_t reg, uint32_t len, uint32_t value);
> +
> +bool __init dw_pcie_child_need_p2m_hwdom_mapping(struct domain *d,
> +                                                 struct pci_host_bridge *bridge,
> +                                                 uint64_t addr);
> +
> +struct pci_host_bridge *__init
> +dw_pcie_host_probe(struct dt_device_node *dev, const void *data,
> +                   const struct pci_ecam_ops *ops,
> +                   const struct pci_ecam_ops *child_ops);
> +#endif /* __PCI_DESIGNWARE_H__ */
> diff --git a/xen/arch/arm/pci/pci-host-rcar4.c b/xen/arch/arm/pci/pci-host-rcar4.c
> new file mode 100644
> index 0000000000..62d2130a63
> --- /dev/null
> +++ b/xen/arch/arm/pci/pci-host-rcar4.c
> @@ -0,0 +1,94 @@
> +/* SPDX-License-Identifier: GPL-2.0-only
> + *
> + * Based on Linux drivers/pci/controller/pci-host-common.c
> + * Based on Linux drivers/pci/controller/pci-host-generic.c
> + * Based on xen/arch/arm/pci/pci-host-generic.c
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "pci-designware.h"
> +
> +#define RCAR4_DWC_VERSION       0x520A
> +
> +/*
> + * PCI host bridges often have different ways to access the root and child
> + * bus config spaces:
> + *   "dbi"   : the aperture where root port's own configuration registers
> + *             are available.
> + *   "config": child's configuration space
> + *   "atu"   : iATU registers for DWC version 4.80 or later
> + */
> +static int __init rcar4_cfg_reg_index(struct dt_device_node *np)
> +{
> +    return dt_property_match_string(np, "reg-names", "dbi");
> +}
> +
> +static int __init rcar4_child_cfg_reg_index(struct dt_device_node *np)
> +{
> +    return dt_property_match_string(np, "reg-names", "config");
> +}
> +
> +/* ECAM ops */
> +const struct pci_ecam_ops rcar4_pcie_ops = {
> +    .bus_shift  = 20,
> +    .cfg_reg_index = rcar4_cfg_reg_index,
> +    .pci_ops    = {
> +        .map_bus                = pci_ecam_map_bus,
> +        .read                   = pci_generic_config_read,
> +        .write                  = pci_generic_config_write,
> +        .need_p2m_hwdom_mapping = pci_ecam_need_p2m_hwdom_mapping,
> +        .init_bus_range         = pci_generic_init_bus_range,
> +    }
> +};
> +
> +const struct pci_ecam_ops rcar4_pcie_child_ops = {
> +    .bus_shift  = 20,
> +    .cfg_reg_index = rcar4_child_cfg_reg_index,
> +    .pci_ops    = {
> +        .map_bus                = dw_pcie_child_map_bus,
> +        .read                   = dw_pcie_child_config_read,
> +        .write                  = dw_pcie_child_config_write,
> +        .need_p2m_hwdom_mapping = dw_pcie_child_need_p2m_hwdom_mapping,
> +        .init_bus_range         = pci_generic_init_bus_range_child,
> +    }
> +};
> +
> +static const struct dt_device_match __initconstrel rcar4_pcie_dt_match[] = {
> +    { .compatible = "renesas,r8a779f0-pcie" },
> +    { .compatible = "renesas,r8a779g0-pcie" },
> +    {},
> +};
> +
> +static int __init pci_host_rcar4_probe(struct dt_device_node *dev,
> +                                       const void *data)
> +{
> +    struct pci_host_bridge *bridge;
> +
> +    bridge = dw_pcie_host_probe(dev, data, &rcar4_pcie_ops,
> +                                &rcar4_pcie_child_ops);
> +
> +    dw_pcie_set_version(bridge, RCAR4_DWC_VERSION);
> +
> +    return 0;
> +}
> +
> +DT_DEVICE_START(pci_gen, "PCI HOST R-CAR GEN4", DEVICE_PCI_HOSTBRIDGE)
> +.dt_match = rcar4_pcie_dt_match,
> +.init = pci_host_rcar4_probe,
> +DT_DEVICE_END
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu May 29 07:55:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 07:55:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999843.1380388 (Exim 4.92)
	(envelope-from )
	id 1uKY7D-00022e-Ey; Thu, 29 May 2025 07:55:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999843.1380388; Thu, 29 May 2025 07: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 1uKY7D-00022X-Br; Thu, 29 May 2025 07:55:51 +0000
Received: by outflank-mailman (input) for mailman id 999843;
 Thu, 29 May 2025 07:55:50 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uKY7C-00022R-0H
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 07:55:50 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uKY7B-008FYH-25;
 Thu, 29 May 2025 07:55:49 +0000
Received: from [2a02:8012:3a1:0:d557:39f4:e427:823c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uKY7B-00Ca1m-30;
 Thu, 29 May 2025 07:55: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=odKWaFvbxRa79gD5yB/W95dlKYKe5DlqFo+KR29Hd6Q=; b=u2H4l3q/metZ5lJ/1NDd/41BF2
	FzHlhWlHiOAJiVo69N6OksI5k9P5/ICutSIkFG/3iiKnwRjEotg/WqjEM41xZ1ch7CuSsJC3gDV8Q
	aTPokAe/obVuSepFLP10EfovbmAXJ6D8+xginVtlZgJEv/bitMs72Acvy8m3VTM86xJE=;
Message-ID: 
Date: Thu, 29 May 2025 08:55:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v11 4/7] xen/arm: smmuv3: Add PCI devices support for
 SMMUv3
Content-Language: en-GB
To: Mykyta Poturai ,
 "xen-devel@lists.xenproject.org" 
Cc: Rahul Singh ,
 Bertrand Marquis ,
 Stefano Stabellini ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Stewart Hildebrand 
References: 
 <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
From: Julien Grall 
In-Reply-To: <71741747bdc0cfcacbe86e66ddd6239ea2f5a3af.1748422217.git.mykyta_poturai@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mykyta,

I have only skimmed through the patch. But there is something that
caught my eye in both this patch and the one for the SMMUv2.

On 28/05/2025 10:12, Mykyta Poturai wrote:
> +		/* dom_io is used as a sentinel for quarantined devices */
> +		if ( d == dom_io )
> +		{
> +			struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> +			if ( !iommu_quarantine )
> +				return 0;
> +
> +			if ( master && master->domain )
> +				arm_smmu_deassign_dev(master->domain->d, devfn, dev);

arm_smmu_deassign_dev() can return an error. Can you explain why this is 
fine to ignore it?

> +
> +			return 0;
> +		}
> +	}
> +#endif
> +

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu May 29 09:45:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 09:45:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999875.1380397 (Exim 4.92)
	(envelope-from )
	id 1uKZpZ-0006j0-3t; Thu, 29 May 2025 09:45:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999875.1380397; Thu, 29 May 2025 09: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 1uKZpZ-0006it-12; Thu, 29 May 2025 09:45:45 +0000
Received: by outflank-mailman (input) for mailman id 999875;
 Thu, 29 May 2025 09:45:44 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uKZpY-0006in-9u
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 09:45:44 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uKZpX-008I6a-2c;
 Thu, 29 May 2025 09:45:43 +0000
Received: from [15.248.2.29] (helo=[10.24.66.169])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uKZpX-00DLvz-38;
 Thu, 29 May 2025 09:45: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=bu0EMmDw62rpTw0T0X24ByG0s+PYpG0rA6O8AB6YMec=; b=pPsf6HDromaCv99r2nW57Ntwxw
	JsXICGI/+9DwWrJGpvBsGYdYYWafM3Zp3kBDHICM/aG7IPDZVuXBOu8ztEIwC7OoF5z0AM8V48rUy
	kZwhwEs0juhFj7WZ8l7i/rfZZyBxem0oRvvsEHX8x5tUP/2lELehbW9MtBPU5gVLxcjk=;
Message-ID: 
Date: Thu, 29 May 2025 10:45:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 3/6] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250523065406.3795420-1-luca.fancellu@arm.com>
 <20250523065406.3795420-4-luca.fancellu@arm.com>
From: Julien Grall 
In-Reply-To: <20250523065406.3795420-4-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Luca,

On 23/05/2025 07:54, Luca Fancellu wrote:
>   /*
>    * Macro to prepare and set a EL2 MPU memory region.
>    * We will also create an according MPU memory region entry, which
> @@ -59,6 +79,24 @@
>       dsb   sy
>       isb
>   
> +    /* Load pair into xen_mpumap and invalidate cache */

AFAICT, you don't invalidate the cache below. What did I miss?

The rest of the patch LGTM.

> +    adr_l \base, xen_mpumap
> +    add   \base, \base, \sel, LSL #XEN_MPUMAP_ENTRY_SHIFT
> +    store_pair \prbar, \prlar, \base
> +
> +    /* Set/clear xen_mpumap_mask bitmap */
> +    tst   \prlar, #PRLAR_ELx_EN
> +    bne   2f
> +    /* Region is disabled, clear the bit in the bitmap */
> +    bitmap_clear_bit xen_mpumap_mask, \sel, \base, \limit, \prbar, \prlar
> +    b     3f
> +
> +2:
> +    /* Region is enabled, set the bit in the bitmap */
> +    bitmap_set_bit xen_mpumap_mask, \sel, \base, \limit, \prbar, \prlar
> +
> +3:
> +
>       add   \sel, \sel, #1

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu May 29 09:52:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 09:52:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999883.1380407 (Exim 4.92)
	(envelope-from )
	id 1uKZwO-0008Iv-PL; Thu, 29 May 2025 09:52:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999883.1380407; Thu, 29 May 2025 09:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKZwO-0008Io-MO; Thu, 29 May 2025 09:52:48 +0000
Received: by outflank-mailman (input) for mailman id 999883;
 Thu, 29 May 2025 09:52:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKZwN-0008Id-FB
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 09:52:47 +0000
Received: from AM0PR02CU008.outbound.protection.outlook.com
 (mail-westeuropeazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c201::7])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ab709c91-3c72-11f0-a2ff-13f23c93f187;
 Thu, 29 May 2025 11:52:45 +0200 (CEST)
Received: from AM9P193CA0012.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:21e::17)
 by AS8PR08MB9313.eurprd08.prod.outlook.com (2603:10a6:20b:5a4::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Thu, 29 May
 2025 09:52:43 +0000
Received: from AMS0EPF000001AB.eurprd05.prod.outlook.com
 (2603:10a6:20b:21e:cafe::c0) by AM9P193CA0012.outlook.office365.com
 (2603:10a6:20b:21e::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.19 via Frontend Transport; Thu,
 29 May 2025 09:52:43 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF000001AB.mail.protection.outlook.com (10.167.16.151) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
 via Frontend Transport; Thu, 29 May 2025 09:52:41 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com (2603:10a6:5:1c::25) by
 VI0PR08MB10655.eurprd08.prod.outlook.com (2603:10a6:800:209::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.24; Thu, 29 May
 2025 09:52:09 +0000
Received: from DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668]) by DB7PR08MB2987.eurprd08.prod.outlook.com
 ([fe80::d53f:b16d:70a5:8668%2]) with mapi id 15.20.8769.025; Thu, 29 May 2025
 09:52: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" 
X-Inumbo-ID: ab709c91-3c72-11f0-a2ff-13f23c93f187
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=phW8nnMLwwmmnsKZdWj5ZZy6SC5/ZciAQOwVEupb3do/pBlm8twgxJTBgsQ5siABaMhqRfC5F2MuRxOixlmIh3Ba54FbOIroxIgvSk1+Ixli88eUDXmZSj5k7DuMDtGpvkY0DWbTPgVYm5kkBRbPEUytzY4c5fsl0AegeIC1HAmurBw7Z443/AmwK8qQ/mt96CxGVhuH3KNXGb+X3LLoIS4Uv2bhXkxv7f2auGXy6oJWqPDCuP46NvtBdl3mUA2yd8DIADPrDD6y6lsj5+yk9hz5EadN7XOXndczIrhDMYpmISWxqTUAYdvjL9E/6sXgcOGBIuAHX1w8Tp0SZ4HhxA==
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=A4Wqg/9BaQM7DwHOXybQRwdg93j8pb3GCJXjudbx8j8=;
 b=Bf5rVk5wxT+ZX3k5K47bw5S14DR7jB/dANA7NByLbnxxc7B5it5LeP+tVCtjDBjKYCmjOgbcUInCBeXjTmgcxf0zlk9dYfjYjm4vVKkAHKnwdecxgAr2ppYmHdyVMvEO8+9p9ineIH15HnNWAgLMICX9WaZgavEP58c827yFYszbG0/P6NNrfVK2csys98xVaHE4ikI5mAmJBoS8WqiVFIjPNZVucOIjFst8Kv4ENPALXwexdg2nvW0r9oRCR/jVMhRH9beRQIzF7UzWGC/Di9TA9nEWhru35qkLTsgZTmSzA6NuEFZuqNJ039uv+3qlW1Qk+2sI3LFTj1dqFX/04g==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=xen.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=A4Wqg/9BaQM7DwHOXybQRwdg93j8pb3GCJXjudbx8j8=;
 b=Y1kt8beJfYqGGZU0DoJoj9A49jx5acJFH5tfk/lv8Cim8fpZyf/qoH+oTe1ug2HCn0w2TgptaRAiqJ91hiys2LM9OhgZs5jz3/lmfZRzfKpP0t9L08xaE1PH9jlJxjhc+NFeRZT84DQO50quCQnrNhYP1VpBxK0IMxjwX4ejes8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DKvB2UfDMjycxSEDZst/oPdo9BejQ7hv+Ar8XtlEUIAhwGG7118not03oVLjphoOouVJZCm4N4Bp2dsbpvbgxvxVCNw2fsubbZu5IjMMDOhdvtxy9E5MMLFuu/C9tYL+ROgfJXsfZa/Wp1PyWQDajbf5KyykOlFgdVQ+0hHvh6rt8H15ySKvegnCyK1JFgnbbR4Y1RwW+Ryu+Kbh+D4Ll9Ggamv9dNTZ8abimxq4TM2ofEcuWlSDKEsttJYQUXVXTx9858Tpenoke43wNU979LGcYbuGuNnp50HPFB9PKTVbWDoNwwhphP/I6NGlJAOtQ6oF5qCD4JhI3jS2KsRIHw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=A4Wqg/9BaQM7DwHOXybQRwdg93j8pb3GCJXjudbx8j8=;
 b=TunxOZxe5w8oXKYwyk/bTWuC15BekOYd4z/IdtDFGzsBt7e49T4v0UwCS6OhjM+9ZINjxg3Wvazu5Au29VPtLnpkIUiCL94LUDwSnKIhYo/SjPU757XxuwHrx4Ci+360fvbQLSKll0S7+eg2bDff5OgSENZBNauiXzCAb5xsU+cwJwFPXt8BBzBkpcHDcia96EhgCGnhO79fMwpkRU8CKF4VkwqI0JmFdFc2C7wNZI+75LNYuEzHKxEfW0CDhKG31QWnQAUh48zdocKonoq29Etzq09YtR0BKzF62B7P6TMc1j4kf7X+BAHyt0Jc18FcLPk7T9K8Z8f6MaM7GUd1HQ==
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=A4Wqg/9BaQM7DwHOXybQRwdg93j8pb3GCJXjudbx8j8=;
 b=Y1kt8beJfYqGGZU0DoJoj9A49jx5acJFH5tfk/lv8Cim8fpZyf/qoH+oTe1ug2HCn0w2TgptaRAiqJ91hiys2LM9OhgZs5jz3/lmfZRzfKpP0t9L08xaE1PH9jlJxjhc+NFeRZT84DQO50quCQnrNhYP1VpBxK0IMxjwX4ejes8=
From: Luca Fancellu 
To: Julien Grall 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: Re: [PATCH v6 3/6] arm/mpu: Provide and populate MPU C data
 structures
Thread-Topic: [PATCH v6 3/6] arm/mpu: Provide and populate MPU C data
 structures
Thread-Index: AQHby6+RibcK1nTrN0C974oHFjnUh7PpZYGAgAABq4A=
Date: Thu, 29 May 2025 09:52:09 +0000
Message-ID: <4546F0C7-28B8-41F9-9442-0CC2E4F42B78@arm.com>
References: <20250523065406.3795420-1-luca.fancellu@arm.com>
 <20250523065406.3795420-4-luca.fancellu@arm.com>
 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB7PR08MB2987:EE_|VI0PR08MB10655:EE_|AMS0EPF000001AB:EE_|AS8PR08MB9313:EE_
X-MS-Office365-Filtering-Correlation-Id: 09460527-9931-4e19-b375-08dd9e968ddd
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|376014|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?dRuS/gYKRH8v2MphLwjMlIYLj/T8zmLSZmKXhfMQ1nhirIhi9kVfPUD4IF3a?=
 =?us-ascii?Q?mGvcXzISyRzBko3GEyrVhDuSoeZnmeeobKMz69xZ30B4HstH7tR+YoF0pMZm?=
 =?us-ascii?Q?Cu2zh/IzFk9Gr4v0uVc7Ieuh1X0zh2c26EzfQRArmPjnG2eg6qfKXuXpsW9o?=
 =?us-ascii?Q?HwSSu2MVMYxGulb/uS0KuW3+zPHNJuEAbiWp/VDstEGhn/JTehYSVQqxgniM?=
 =?us-ascii?Q?r+Pkhy1z0rqw1GlJiZ+pxmasC/zTSU5ygJsL1OuG2bub5VCEndTay2M2phJ0?=
 =?us-ascii?Q?DzRBDfJ+a3G03iAdeYU4qsAVqQqcQxRlaAeZfMOQW6wrh+8iBKJxu21xsQTX?=
 =?us-ascii?Q?FLdj/0K34t0zHF2r6ScC0wNT17ycB0Sm2U3sFmZ7uTfR4XqYPoFcz/IK8H9P?=
 =?us-ascii?Q?fqMPZrga3nL/JXvPCJpWU50uEvR7ynys2zY5la47CDYpyjT0pzhPvXKRantN?=
 =?us-ascii?Q?q7yBHjsr6gm9mAtrybnA8ytAGmYF0hJyz9AExDH+q1QtegiyedZuB19x1mSK?=
 =?us-ascii?Q?qlzN9dSOyTUd0QLGAJoysaaPMIXZygEgchL4OuQX+bgUlcHt39KFsfY1RjTE?=
 =?us-ascii?Q?OAxBzxYQzxmU3L0gegzC6ke1DLrtevTDlPk8Ha39X4PnpO9nRGgV+EVWC8vJ?=
 =?us-ascii?Q?/IXL6pvCfbKEQszDT9yuxQ/bqkJNN9uW1LfWvavzBRUaLPdhsc5f32MZ+VaK?=
 =?us-ascii?Q?SV430mLCl0WdXZfIRLINK+k3M8v6Z1Kf0GDavY1rZqZJEXE0IsGwZ0brxhyU?=
 =?us-ascii?Q?W/ZBZDTpApPsdR0HugGaqnqeCJK/qdoGohA6D9pogh0TGlNO+2DjiTtFfbYX?=
 =?us-ascii?Q?wMa3GfzXwd+voApR5SeM/x5Hwdzmok/lHSBgKGqffk3WwQQOilnD3CiMASXA?=
 =?us-ascii?Q?IdZTK/E/WxMIVaEceKBZnOSaemY7wcQjhRHepEJ1bH8ytTmOwYCoK/BzTNSJ?=
 =?us-ascii?Q?KC5NE0iP54MRFUmMSI6zk6pFoukJCrNCytpHs76cvUQdMpkZooKzNqkOPOj/?=
 =?us-ascii?Q?7FIcX4V23a9ZnBcqv3bELfQyZ8SKF40nfjbZBJ7Qm4i53FG9zIAYQQXmLVrZ?=
 =?us-ascii?Q?cDVu1yNnYXy1IUw7VShXEO79QMajIWGaKnXZLt2dXqxXkjXZs+0r4FFHz13I?=
 =?us-ascii?Q?elyzkXEdiiPmLKdUiQ1TjvF4SfoM9tJ9fGdCr5JI75zcY77xwjwNW70j8PAU?=
 =?us-ascii?Q?Bvd/Hi0OykN9M06fgDGFh6z6ilPauAzrttJS9qg4m8gpqOl5Ty+iHlvCUVYa?=
 =?us-ascii?Q?ayKMGfVWl+1bQzChp/KOrgYNJkwZW9X0XLMTtjOoSj6pDgLPpr+LijEcEmj5?=
 =?us-ascii?Q?dkOlRDXwUvkrdo1w1KDTHTlRp5ZWdh1XPMas3fdGLXOeUM/Le8WwKF5TkT4H?=
 =?us-ascii?Q?3sbeLd8x3HshYkpB4EuGbHEkLspabzolNbe1pSlHuCZxv/LOclIi//IIWTG4?=
 =?us-ascii?Q?duR8HV/YJlDbePUmm7dLSzfWiLjA2SUk9EIS6qmxjezIh0roloLh9oNb7Kuk?=
 =?us-ascii?Q?/P+GqGFPYLOvLys=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB2987.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0F3EF0DD168EA84988F9AEA3F867B8D5@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10655
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF000001AB.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	31914c95-a6fb-4a28-7603-08dd9e967a80
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|14060799003|82310400026|36860700013|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?vcbQWpM4+xDjGisOPTop8BpkDaf0zfrbRiLd9VLh5JsdAYMf130zmuJ0wtIy?=
 =?us-ascii?Q?DZlAGfpIm/vph+EYZyFBhw/hOQcELGAU++tcsG4KAwq8Vyxh+RwLhvwSqmeM?=
 =?us-ascii?Q?iOQ77LZwzp7z0YTPB4l9YZyGGfZU2kBNLCIWx3NbZGaBdzklQ1L2f/aJVl/I?=
 =?us-ascii?Q?INTXZaqB0aWzAUq6I57g1T8cLbVhNh42U2TA8bDQM338rTzroIU5uUhTfxot?=
 =?us-ascii?Q?3qARhSoAB0aGczY6CWHEFpdWI4IbdtLtKOunbeA1ITj3va8fbkWe2xizvbWJ?=
 =?us-ascii?Q?+C4LbMNZ+nFiwnxYqgLB83Xm8jUYZvWoBVGMUxR7M1IxX/84zUw03FUDcUN4?=
 =?us-ascii?Q?oLfdd/xXYlC+h+o7rkn7mVzQQF4MN9ssBXCtHpKs2IZN7ViXZdaNSiw03xa3?=
 =?us-ascii?Q?va6cXW9sb3VKpWBRAwrK0KFcv7wNc/xYgL1y+KAvECTIMDlv04BQdK8yt3GT?=
 =?us-ascii?Q?ZuG19vWVSNUG5rrsCLhhO934bTlVVklzyaBDIDolPBcsb/LKc6efe/Rxb809?=
 =?us-ascii?Q?T9BityzNux4sTsKa+6XXBCNXvsqvkZi54UG1gU8hLJzCBLa46eFIKrODhKEn?=
 =?us-ascii?Q?zd2yTav/1f/8ktSPw35noR5kbVe+3s3XChLRbabV4YKepWSviX+zvmBMB3OE?=
 =?us-ascii?Q?ME2xLbIdDPxRlPVXrcQO0p1egaYQhLGK+A8D/ZNR98aqFjh1sjF3uf+Rm7Oa?=
 =?us-ascii?Q?yhYITPUF4dyy3LZVBcUvUI4xqSFzmlAHcOa9T18ECERoR6LWpx1oeO/qPKR6?=
 =?us-ascii?Q?7OFEhB0fk9Cdym0KNSDXg+4F8rV8R1MuAagB08U6DhTVn1fHqk2nZ4oNNV/W?=
 =?us-ascii?Q?CIemYvOeh31Wk1NOjwVzlNWHiEyF48w1uGsagOx9+1MSoTu8yfUHZdHGqpK4?=
 =?us-ascii?Q?wwKWJuy35WuFXv7m2Iu3DYLeUNNWVkeP2JAi5et8Z0rs4bckP88TtC1PemzG?=
 =?us-ascii?Q?j18A6lNEdlgNkGwGTe85/95ofCKvtQ8OzaGeNOUimZJj8bqalXu2gu2ISavC?=
 =?us-ascii?Q?DSUJW+flinYkifqXJrTyIDRkt0lNk+DJMK2piusoOnvLm7XqepGEEJgQ5Xe7?=
 =?us-ascii?Q?7e9k2f0BvPx0IE1XZLuGuiirG/YRMkeGv9scmL/KjM+WAKh/GbE+ikThEqb5?=
 =?us-ascii?Q?lDvw0VZEpkBxRkFiQnJBahTuHsdcVypSi2F3EfN6wqWftpzgQgMajLEo8voL?=
 =?us-ascii?Q?swh+OIg4nlwP/vUc6PcA+tKbyu7rrZyjgERVq2Gq5tdqwHvXwzAsRjx3LtAt?=
 =?us-ascii?Q?+Amuzcvz8K3bNsCthmawAcIRQr9m3B6XmCAg6Zna4eHwvniE9oDLzCkF8H5V?=
 =?us-ascii?Q?nV8/dD1YP5LNEC7zIev3OJ0/27KEArCP3itjGWBcjToudskPeK/ubDYHfRDF?=
 =?us-ascii?Q?ZMlEkPIiimKSmpQTmA7+Tl+SFduae7uUvOO0s6V3genGTIb/8it6fGmfQpjg?=
 =?us-ascii?Q?w7K0TZIyXJ30gL+hVsVBw+pfzLJ2v3s1pJkfBroRKrqY8lNgqeBTJA8EwT/9?=
 =?us-ascii?Q?fr3kuuBuE2freu12wFryt48I2lQdwduO9FFw?=
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)(14060799003)(82310400026)(36860700013)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2025 09:52:41.7996
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 09460527-9931-4e19-b375-08dd9e968ddd
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:
	AMS0EPF000001AB.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9313

Hi Julien,

> On 29 May 2025, at 10:45, Julien Grall  wrote:
>=20
> Hi Luca,
>=20
> On 23/05/2025 07:54, Luca Fancellu wrote:
>>  /*
>>   * Macro to prepare and set a EL2 MPU memory region.
>>   * We will also create an according MPU memory region entry, which
>> @@ -59,6 +79,24 @@
>>      dsb   sy
>>      isb
>>  +    /* Load pair into xen_mpumap and invalidate cache */
>=20
> AFAICT, you don't invalidate the cache below. What did I miss?

oh right I forgot to update this comment, Should I respin the serie or coul=
d it be addressed
on commit?

I would amend the comment as:
/* Load pair into xen_mpumap */

Cheers,
Luca



From xen-devel-bounces@lists.xenproject.org Thu May 29 09:54:37 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 09:54:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999893.1380417 (Exim 4.92)
	(envelope-from )
	id 1uKZy8-0000Po-70; Thu, 29 May 2025 09:54:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999893.1380417; Thu, 29 May 2025 09:54:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKZy8-0000Ph-4X; Thu, 29 May 2025 09:54:36 +0000
Received: by outflank-mailman (input) for mailman id 999893;
 Thu, 29 May 2025 09:54:35 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uKZy7-0000PZ-CB
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 09:54:35 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uKZy6-008IFD-37;
 Thu, 29 May 2025 09:54:34 +0000
Received: from [15.248.2.29] (helo=[10.24.66.169])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uKZy7-00DNDg-0W;
 Thu, 29 May 2025 09:54: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=32VvbTDuRLJieKAUMdskwK5ALoQdNBNOc76OAoZ/gzQ=; b=Uuc3sdQwg+LG1XErySXKh20XV7
	TrWXEc9NbRGjMWW8Z7Cu2qvEaOI2cwbTXylNgRKA03GYtMRQSElhxd2XFpnn99K8qUuSODtqF3Shm
	BLH7fRAtRbyU8HqZnT9OdMCyVkIKhUub2VV5i96gfrP737syDsni3dfUvkOlk9Ep6VEg=;
Message-ID: 
Date: Thu, 29 May 2025 10:54:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 3/6] arm/mpu: Provide and populate MPU C data
 structures
Content-Language: en-GB
To: Luca Fancellu 
Cc: "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20250523065406.3795420-1-luca.fancellu@arm.com>
 <20250523065406.3795420-4-luca.fancellu@arm.com>
 
 <4546F0C7-28B8-41F9-9442-0CC2E4F42B78@arm.com>
From: Julien Grall 
In-Reply-To: <4546F0C7-28B8-41F9-9442-0CC2E4F42B78@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 29/05/2025 10:52, Luca Fancellu wrote:
>> On 29 May 2025, at 10:45, Julien Grall  wrote:
>> On 23/05/2025 07:54, Luca Fancellu wrote:
>>>   /*
>>>    * Macro to prepare and set a EL2 MPU memory region.
>>>    * We will also create an according MPU memory region entry, which
>>> @@ -59,6 +79,24 @@
>>>       dsb   sy
>>>       isb
>>>   +    /* Load pair into xen_mpumap and invalidate cache */
>>
>> AFAICT, you don't invalidate the cache below. What did I miss?
> 
> oh right I forgot to update this comment, Should I respin the serie or could it be addressed
> on commit?
> 
> I would amend the comment as:
> /* Load pair into xen_mpumap */

It can be done on commit.

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu May 29 15:31:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 15:31:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.999980.1380428 (Exim 4.92)
	(envelope-from )
	id 1uKfDj-00046R-Je; Thu, 29 May 2025 15:31:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 999980.1380428; Thu, 29 May 2025 15:31: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 1uKfDj-00046K-FX; Thu, 29 May 2025 15:31:03 +0000
Received: by outflank-mailman (input) for mailman id 999980;
 Thu, 29 May 2025 15:31:02 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKfDi-00046E-Ma
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 15:31:02 +0000
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
 [2a00:1450:4864:20::131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ed15cdf7-3ca1-11f0-a2ff-13f23c93f187;
 Thu, 29 May 2025 17:31:01 +0200 (CEST)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-54d98aa5981so1435036e87.0
 for ; Thu, 29 May 2025 08:31:01 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5533787d384sm362216e87.20.2025.05.29.08.30.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 29 May 2025 08:30: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" 
X-Inumbo-ID: ed15cdf7-3ca1-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748532661; x=1749137461; darn=lists.xenproject.org;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :message-id:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=m2Hw1o5oXO+csszFqpu9DCtn6QhiUeBloK/Zz6pQIH0=;
        b=VGrc54iiucPmce7HyxhD8x+urkaduS8qTJl6zeB1cMNGqmldjhukTRRMSyg18LnZTi
         bBFXvAdGs8bhIqGo9t0PJyP7VRSklbb0VIM6n23djB9kVxjWlFh5//2MMhEelCcRlVlk
         AJ1DflMhfpnMJNYGuXYtg4ekGhwNiX6QOmKPx7Re7X2RlM2uZMQySaD9jH0SbBXPVpL9
         +wZkrDEhWHTm8gvOho++HC6JR8PdsRwL4hcOY2gq5GvTEYRydZ9LBlfcFm3rbUgmjbjo
         obKiRzJK7lg0MTkuYRMj7OWxN7w3tAzx2Z091fIqSjeJowDgJQ6+01TmLRkpmUxQuqtw
         zomw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748532661; x=1749137461;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=m2Hw1o5oXO+csszFqpu9DCtn6QhiUeBloK/Zz6pQIH0=;
        b=TjR94jfzlgB0hu3vKcEQwlpC80UKHQTGJ6wJFi9BpSrq9mGJ1kTEn6xBK5EkAitBxh
         v2GHCL22rTGG4Igx/RQyYPfn+pzLMiGKu07qf9NsFarwtF3LF6Q2UFcy0fghC+50qRLg
         taoPICVIgv+18UqR495272+a/xDXu3wr+XHW6pYgtyRBauUy/0kE4UTDyK/d57I5pVQB
         EW9D+J6TRaj235xaY6tH7j/byybyPoT/thK1LNpHfWhZMk2w+7qo3mFaoIqVzzTYdPr8
         SilaJsWhErPKQXFcLwGYWkE8y3RAT4V1n7iD0tURKSfXHkuGlwU+t2ZLK/Z3iBy/dyiJ
         4EQw==
X-Gm-Message-State: AOJu0Yy7/NLGjbeGlepVcggZf/Hh7bXMWHMh7Or4p+t04iOTaNe/Vn6Y
	JDgY8c5MMw2BoFbjkVGqHRVEDYTvuIgl+GSkJGzdHsrcjE5GQwuwzDc3
X-Gm-Gg: ASbGncsaRUKZa/u+tLbkBegW9zSn8cvwdy1C9TqjowTfv6oDfE+crxjX4kJoS8qwkh6
	3/X5ukjBNEMnJe31nQQEtZHINmLz++HLSCfyLHQJ+WB9j/XNDStVyw/FZi9jtgce6SKGrhUNDAC
	y5E0iY67roxgRAOcMddkQBBIDyAii9YgKSYvU0rEcR0BuTRKGSNurErhE9CDCDTf64ELCMZXwID
	2SCdf/Ymgid/1kcY1+ZEGTA6iwii7BCceBUr5S+XkRsXZZihh11jB4zXkPwkuPayP2a4kTXcjES
	Y1hBENhClLaA5CeD2y9vLBV/OBKe9s/OeH+wvjzcvyCV1sYaf+PZ0fNcveMlNKP1TJb4TkueFpa
	PsA/7HfZaZxcbhnzgO8+rpsA=
X-Google-Smtp-Source: AGHT+IHwhgWV8yooYfRGYeVXg19yB+ewGgamqw4ZeWf19XrxeCPjfDUQc4P8ITQrx5SyHIXpj22pSQ==
X-Received: by 2002:ac2:51c8:0:b0:553:29a6:339d with SMTP id 2adb3069b0e04-55329a6350dmr4021604e87.8.1748532660200;
        Thu, 29 May 2025 08:31:00 -0700 (PDT)
Date: Thu, 29 May 2025 17:30:58 +0200
From: "Edgar E. Iglesias" 
To: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org, julien@xen.org,
	bertrand.marquis@arm.com, michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com, edgar.iglesias@amd.com
Subject: Re: [PATCH v1 2/3] xen/arm: dom0less: Add trap-unmapped-mmio-disabled
Message-ID: 
References: <20250527195616.874614-1-edgar.iglesias@gmail.com>
 <20250527195616.874614-3-edgar.iglesias@gmail.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/2.2.14+84 (2efcabc4) (2025-03-23)

On Wed, May 28, 2025 at 05:41:34PM -0700, Stefano Stabellini wrote:
> On Tue, 27 May 2025, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias" 
> > 
> > Add the trap-unmapped-mmio-disabled per-domain fdt property.
> > 
> > Signed-off-by: Edgar E. Iglesias 
> > ---
> >  docs/misc/arm/device-tree/booting.txt | 7 +++++++
> >  xen/arch/arm/dom0less-build.c         | 3 ++-
> >  2 files changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> > index 59fa96a82e..75fbb245d1 100644
> > --- a/docs/misc/arm/device-tree/booting.txt
> > +++ b/docs/misc/arm/device-tree/booting.txt
> > @@ -225,6 +225,13 @@ with the following properties:
> >      option is provided with a non zero value, but the platform doesn't support
> >      SVE.
> >  
> > +- trap-unmapped-mmio-disabled
> > +
> > +    Optional. A boolean property that configures handling of accesses to
> > +    unmapped MMIO ranges.
> > +    If set, guest accesses will read 0xFFFFFFFF and writes ignored.
> > +    If not set, guest accesses will trap.
> 
> I would prefer that we are consistent with the name of the parameter we
> use in libxl and elsewhere so I would stick with trap-unmapped-mmio
> without -disabled.
> 
> We can still default the property to "enabled" when absent. Although
> this is not a common pattern for device tree, it happens and for
> instance the property "status" works that way as it is implied to be
> "enabled" when absent.


Sounds good Stefano,

Boolean DT props have no values so we can't have a default of true since
there wouldn't be a way of setting it to false.
But we can make trap-unmapped-acceses an integer. E.g:

trap-unmapped-acceses = <0>; // Disabled
trap-unmapped-acceses = <1>; // Enabled
// trap-unmapped-acceses not present defaults to Enabled.

I've done this latter for v2, avoiding the -disable suffix.

Cheers,
Edgar


> 
> 
> >  - xen,enhanced
> >  
> >      A string property. Possible property values are:
> > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> > index e5e13e07d0..cd1ef05d89 100644
> > --- a/xen/arch/arm/dom0less-build.c
> > +++ b/xen/arch/arm/dom0less-build.c
> > @@ -344,8 +344,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
> >  #endif
> >      }
> >  
> > -    /* Trap accesses to unmapped MMIO. */
> >      d_cfg->arch.flags = XEN_ARM_TRAP_UNMAPPED_MMIO;
> > +    if ( dt_property_read_bool(node, "trap-unmapped-mmio-disabled") )
> > +        d_cfg->arch.flags &= ~XEN_ARM_TRAP_UNMAPPED_MMIO;
> >  }
> >  
> >  int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
> > -- 
> > 2.43.0
> > 


From xen-devel-bounces@lists.xenproject.org Thu May 29 15:50:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 15:50:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000009.1380437 (Exim 4.92)
	(envelope-from )
	id 1uKfWY-0006oi-1o; Thu, 29 May 2025 15:50:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000009.1380437; Thu, 29 May 2025 15:50: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 1uKfWX-0006ob-VV; Thu, 29 May 2025 15:50:29 +0000
Received: by outflank-mailman (input) for mailman id 1000009;
 Thu, 29 May 2025 15:50:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKfWW-0006oV-Jv
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 15:50:28 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a4223cd2-3ca4-11f0-a2ff-13f23c93f187;
 Thu, 29 May 2025 17:50:27 +0200 (CEST)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-553241d30b3so1224765e87.3
 for ; Thu, 29 May 2025 08:50:27 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553379374f4sm362882e87.215.2025.05.29.08.50.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 29 May 2025 08: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" 
X-Inumbo-ID: a4223cd2-3ca4-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748533827; x=1749138627; 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;
        bh=B4QRnVWhmsvxyrEb6IihLA1iLdgt/uebugKpxTMpdtA=;
        b=KsBJcrhKNswF7EmSzspN8gRSEPuG6nBFgNZkdmzuVvQOnYGLqgthhTVaykmDg3BeZ2
         K9bun43tKV7TUFh+VhypCaHGV54MNqeeFhAABGb6xEfkzkcDFvxNqhLu1Iq1QQnqLmka
         wJo2XAVW7cfbuFhQgNJ94VnM6Gj4vEyYC9ct4OaBHx4+IMQ9D0VhY7oesSYziHGkIFQm
         1pxd+7jSYcvwXKIJtP1kS5FPq5wpbBLUMUZEAiI3UckhJPyT/azNkKWgkvT4UfxINsT3
         98ydMqOKUod/PQRvWyYozKrYndFEU/AOKDkzCR55t8rYSDA5QUHUGMye5c0ixRcctWUF
         NLKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748533827; x=1749138627;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=B4QRnVWhmsvxyrEb6IihLA1iLdgt/uebugKpxTMpdtA=;
        b=fklrXpqR8w5Q9/kEbDMx3/LE6XUJEO7xgpPqh2yo0VsCFzrcpfklcWlAR510C2nkW0
         YJg0ckYUHCE02Cg5gd4PzLI2wueW9UsmPIacx1rO1Utac3VucBa5JSMSKoszvxLFCRYn
         kSmD4jDDeFuYhL3xQuene9IqZYbw7soRomT2f/pf4blsbVarYxxhGR0Cru5l3xMs4nmk
         8R6FItPJyGxVQrrawA/8ew6adP4hj6Ez3CyY9sTcp78q8gHflPszHKpyJuJ22lgGyzsv
         7d5hsxflvFMeNWuV503eKpAEv/8evoo48DgZ23Oyj+aAPfZR0LWM1MYSKTtE0KJSF4vg
         tSLw==
X-Gm-Message-State: AOJu0YwEIizbnrFb4v7/k7x0tp99awAMeTJ1MpE5NHeMBTPwhyrICurA
	HpyzjQ6JtFBSaNL1rQH3PcYj98/Ee+aMTfykIhKNUtaiTIQncMQLXbS2ebsjQFpvbPQ=
X-Gm-Gg: ASbGncu7f3oXXYtZHu88RGoYQq+QLkf7uz/IOUFrp8DmdtRnx9fd4jVh1lxuu7FgMP5
	9J1sQGMmLkhNSf9e2PZrcnz2EJ4ABT+BmWcPPeDcdPm1qf0lfG+qPqdY+y5HM8uixpizlz/Lylr
	VrEgUFsaP5K7nAYuxjpXV424qYl8s4b5MD2Kc34MTTtFSNfJWTBR5u0gu7NbEFnOkLcX3qm8frf
	YvJr0ZNPGY82xycrUiZXYEeQcZmvB+Y1jFgv64oYy7+U8JVcHmRd0wMEhePRIK6uIW8rFXmoDrN
	3Jyxe30T213Xk/uWa+KbSYZS2GNNVSx3L0zGmxhTMb27q1cHmYKexQwj0hD++CZkEyjlOwXm6d1
	/fne6fYPnTJqkD2ypZSv69oU=
X-Google-Smtp-Source: AGHT+IF5Qx85RdNADkm5W+0XahZ0HpGgfoK4VXMiel5mP0+oeVflp0Zg4giCcwQ6EmWZiVSfk7dOwQ==
X-Received: by 2002:a05:6512:3d24:b0:553:390a:e1d3 with SMTP id 2adb3069b0e04-553390ae2e1mr865638e87.48.1748533826455;
        Thu, 29 May 2025 08:50:26 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com
Subject: [PATCH v2 0/3] xen/arm: Add option to optionally disable trapping on unmapped acceses
Date: Thu, 29 May 2025 17:50:20 +0200
Message-ID: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

This follows up on the virtio-pci discussion and adds a per-domain
option to select the behaviour of accesses to unmapped address ranges.
The new option is trap_unmapped_accesses, it's general but for now
only implemented for ARM.

I'm happy with any name, so if you have better ideas please suggest them!

Thanks,
Edgar

ChangeLog:

v1 -> v2:
* Rename trap_unmapped_mmio to trap_unmapped_accesses
* Generalize to allow other archs to later support this option
* Change dom0less DT binding from boolean to integer
* Remove changes to autogenerated go bindings

Edgar E. Iglesias (3):
  xen/arm: Add way to disable traps on accesses to unmapped addresses
  xen/arm: dom0less: Add trap-unmapped-accesses
  tools/arm: Add the trap_unmapped_accesses xl config option

 docs/man/xl.cfg.5.pod.in              |  8 ++++++
 docs/misc/arm/device-tree/booting.txt |  9 +++++++
 tools/libs/light/libxl_arm.c          |  3 +++
 tools/libs/light/libxl_create.c       |  3 +++
 tools/libs/light/libxl_types.idl      |  1 +
 tools/libs/light/libxl_x86.c          |  6 +++++
 tools/xl/xl_parse.c                   |  3 +++
 xen/arch/arm/dom0less-build.c         | 10 ++++++++
 xen/arch/arm/domain.c                 |  3 ++-
 xen/arch/arm/domain_build.c           |  3 ++-
 xen/arch/arm/io.c                     | 36 +++++++++++++++++++++++++--
 xen/common/domain.c                   |  3 ++-
 xen/include/public/domctl.h           |  4 ++-
 13 files changed, 86 insertions(+), 6 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu May 29 15:50:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 15:50:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000010.1380449 (Exim 4.92)
	(envelope-from )
	id 1uKfWa-00072T-Aj; Thu, 29 May 2025 15:50:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000010.1380449; Thu, 29 May 2025 15:50: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 1uKfWa-00072M-64; Thu, 29 May 2025 15:50:32 +0000
Received: by outflank-mailman (input) for mailman id 1000010;
 Thu, 29 May 2025 15:50:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKfWY-0006oV-7v
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 15:50:30 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a55c7f23-3ca4-11f0-a2ff-13f23c93f187;
 Thu, 29 May 2025 17:50:29 +0200 (CEST)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-553280c345cso1424160e87.0
 for ; Thu, 29 May 2025 08:50:29 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32a85bd29a2sm2999991fa.105.2025.05.29.08.50.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 29 May 2025 08:50: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" 
X-Inumbo-ID: a55c7f23-3ca4-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748533828; x=1749138628; 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;
        bh=VbUTwQzmmaewl5uonTpiY2JHveYiify6lhAK/r8MJhY=;
        b=NIyUr3hApuoG9OW/Ee9j8PxmzIQZmPpJIc8sFX6zKW7WdYtMn85jpX5udTJiZQfUy9
         gP/7lkRMdZoOJGWOBz9tAnc+B7In4Uq6jXUyv+OT/UWgVN4QJ7mcZNLBGvWx7ZaHwXdz
         89QB2JQqYPNvNCvvVmSEAD3xnKJoA42XHOXK5AtX3uOsYyYtRqHvXLefdaBjayXMBnxU
         wEXY9R/zyNYLMCwKYz5jkWWAD+yTL3krALxLzatbiR+5VqxaKEFCvZxSb24HvGpExp6w
         B/0ITfuydYKESfjSHr1WM+GFZncsaVDb94bSYb7L+MsqzaYHm+IAkN1B4qfhEbVy5yOH
         Xnlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748533828; x=1749138628;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=VbUTwQzmmaewl5uonTpiY2JHveYiify6lhAK/r8MJhY=;
        b=f+Rz1B7f1QwX1eBaTzaGepFRgc+yWiH+y+BieZlmnvutXZtYDsfWy+JUUGSRbq4tbh
         6Ys2Dqi7UiO+STaQQmB/v9OGvGybphH7y2JJP/X7ZOey5L8xN7VsVjzys76LU7YksZAK
         DD+HQZ94SRSSRxEG3M5rzxCWAAvk0aDnplve75bwlMYkjunOr3dkNGGS6w6lIAUJMAVU
         FcD869fcYrEv5JRcawEHjgD2Xo95YwdFzCaBYjtbRVM3/+IMMLyeoslDmUlm3xHfeRCw
         TTkX38HQEIq9iTWOgMe/cG70e+Q5yGsKjzBVr8nedRgxh1ZucWRsHcjRyJLQwEKCcLyw
         VrUw==
X-Gm-Message-State: AOJu0YzY6eZyxETsBK42fNVedSS4+G+6WDowy57wh3rDnMpCWzUHRWFa
	IAhKrZupsDk14uB+npTPK56HgWOYKDFY6fJYLLumnGKN6WOIfl8ZDmfFJLZwDxX+Prc=
X-Gm-Gg: ASbGncvut19UwwSCYl9vD9uZ7zsvh+OC7wCNSBCz9ioOIFF8t8gJoDiCGKeQDbzx7rA
	aCOhimfqZ5sFiP9H5rdNjM12PFTIm6Et52nMp9pxVEg9oh2tnfQylPWbMqGtzr2HAZ6xplXA9i9
	CffCnL40rAU4gue9fl0wuOXap86nMVs3zYY+HR3luw54ATceZcd7dDp0yL580HjoVzxNz5COxR7
	bjjFaXKwvwSiKfphwVS22tt70ov2r/Mkl9bo4p3P3v6ZKDMc7XHiTZhbXcX3b+8NqBAInz+Y6tU
	PiaZAMDWSZWKx2F7KV3fjm/Y5rKsWj34ZF8jY1ndHumEeOGkz7eI8/BgmDDIVEu9GncecHXM1tD
	/aUsAl9WbMT9VyGFIkAdIuFvlBJgvt0dEKQ==
X-Google-Smtp-Source: AGHT+IFscQ5zcDBfHcEEPM38Enf5fSV1b5NR14i4xCcjg/PtOY1YU11OlIFSUtrqUXzo2hAB0uU6BQ==
X-Received: by 2002:a2e:a545:0:b0:32a:749a:14d4 with SMTP id 38308e7fff4ca-32a8cd46753mr1204501fa.12.1748533828080;
        Thu, 29 May 2025 08:50:28 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com,
	Anthony PERARD ,
	Juergen Gross ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 1/3] xen/arm: Add way to disable traps on accesses to unmapped addresses
Date: Thu, 29 May 2025 17:50:21 +0200
Message-ID: <20250529155024.1284227-2-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
References: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Add a per-domain way to optionally disable traps for accesses
to unmapped addresses.

The domain flag is general but it's only implemented for ARM for now.

Signed-off-by: Edgar E. Iglesias 
---
 tools/libs/light/libxl_arm.c  |  3 +++
 xen/arch/arm/dom0less-build.c |  3 +++
 xen/arch/arm/domain.c         |  3 ++-
 xen/arch/arm/domain_build.c   |  3 ++-
 xen/arch/arm/io.c             | 36 +++++++++++++++++++++++++++++++++--
 xen/common/domain.c           |  3 ++-
 xen/include/public/domctl.h   |  4 +++-
 7 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 75c811053c..9530996e72 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -233,6 +233,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
     }
 
+    /* Trap accesses to unmapped areas. */
+    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+
     return 0;
 }
 
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a49764f0ad..a4e0a33632 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -343,6 +343,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
         panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
 #endif
     }
+
+    /* Trap accesses to unmapped areas. */
+    d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
 }
 
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 45aeb8bddc..be58a23dd7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -612,7 +612,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
     unsigned int max_vcpus;
     unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
     unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu |
-                                   XEN_DOMCTL_CDF_xs_domain );
+                                   XEN_DOMCTL_CDF_xs_domain |
+                                   XEN_DOMCTL_CDF_trap_unmapped_accesses );
     unsigned int sve_vl_bits = sve_decode_vl(config->arch.sve_vl);
 
     if ( (config->flags & ~flags_optional) != flags_required )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..7ff9c1b584 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2003,7 +2003,8 @@ void __init create_dom0(void)
 {
     struct domain *dom0;
     struct xen_domctl_createdomain dom0_cfg = {
-        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
+        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
+                 XEN_DOMCTL_CDF_trap_unmapped_accesses,
         .max_evtchn_port = -1,
         .max_grant_frames = gnttab_dom0_frames(),
         .max_maptrack_frames = -1,
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 5a4b0e8f25..adfc822e7e 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -21,6 +21,32 @@
 
 #include "decode.h"
 
+/* Handler for unmapped ranges. Writes ignored, reads return all ones.  */
+static int unmapped_read(struct vcpu *v, mmio_info_t *info, register_t *r,
+                         void *priv)
+{
+    uint64_t mask = GENMASK_ULL((1U << info->dabt.size) * 8 - 1, 0);
+
+    /* Mask off upper bits.  */
+    *r = UINT64_MAX & mask;
+    return 1;
+}
+
+static int unmapped_write(struct vcpu *v, mmio_info_t *info, register_t r,
+                          void *priv)
+{
+    return 1;
+}
+
+static const struct mmio_handler_ops unmapped_ops = {
+    .read = unmapped_read,
+    .write = unmapped_write
+};
+
+static const struct mmio_handler unmapped_handler = {
+    .ops = &unmapped_ops
+};
+
 static enum io_state handle_read(const struct mmio_handler *handler,
                                  struct vcpu *v,
                                  mmio_info_t *info)
@@ -175,11 +201,17 @@ enum io_state try_handle_mmio(struct cpu_user_regs *regs,
     handler = find_mmio_handler(v->domain, info->gpa);
     if ( !handler )
     {
+        bool trap_unmapped = v->domain->options &
+                                         XEN_DOMCTL_CDF_trap_unmapped_accesses;
         rc = try_fwd_ioserv(regs, v, info);
         if ( rc == IO_HANDLED )
             return handle_ioserv(regs, v);
-
-        return rc;
+        else if ( rc == IO_UNHANDLED && !trap_unmapped )
+        {
+            /* Fallback to the unmapped handler. */
+            handler = &unmapped_handler;
+        } else
+            return rc;
     }
 
     /*
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..ac4f58f638 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -721,7 +721,8 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
          ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
            XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
            XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu |
-           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) )
+           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu |
+           XEN_DOMCTL_CDF_trap_unmapped_accesses) )
     {
         dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
         return -EINVAL;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5b2063eed9..be19ab5e26 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -66,9 +66,11 @@ struct xen_domctl_createdomain {
 #define XEN_DOMCTL_CDF_nested_virt    (1U << _XEN_DOMCTL_CDF_nested_virt)
 /* Should we expose the vPMU to the guest? */
 #define XEN_DOMCTL_CDF_vpmu           (1U << 7)
+/* Should we trap guest accesses to unmapped addresses? */
+#define XEN_DOMCTL_CDF_trap_unmapped_accesses  (1U << 8)
 
 /* Max XEN_DOMCTL_CDF_* constant.  Used for ABI checking. */
-#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_vpmu
+#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_trap_unmapped_accesses
 
     uint32_t flags;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu May 29 15:50:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 15:50:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000011.1380454 (Exim 4.92)
	(envelope-from )
	id 1uKfWa-00075m-LJ; Thu, 29 May 2025 15:50:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000011.1380454; Thu, 29 May 2025 15:50: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 1uKfWa-00075d-E2; Thu, 29 May 2025 15:50:32 +0000
Received: by outflank-mailman (input) for mailman id 1000011;
 Thu, 29 May 2025 15:50:31 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKfWZ-0006oV-Jv
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 15:50:31 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a643580c-3ca4-11f0-a2ff-13f23c93f187;
 Thu, 29 May 2025 17:50:31 +0200 (CEST)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-553280c345cso1424197e87.0
 for ; Thu, 29 May 2025 08:50:31 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-55337937bf7sm359434e87.254.2025.05.29.08.50.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 29 May 2025 08:50: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" 
X-Inumbo-ID: a643580c-3ca4-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748533830; x=1749138630; 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;
        bh=m/ZAsDiyBEUJhyA3+Rgv4QwvFmR3/7Sm2UmwbErJIko=;
        b=Zt6B2JIRDMTTvW9FJqUXW/eeE5VCTF/OIo3XXoDoMLcMY6IUzOXhHOFBHSMgk4XF2K
         qgGs4cKnEvCtXPB9VQb0Nz3dqoONHNI+PWA7sm2JpxZbEsfm/8zUWWnzA1hMWwZTBd2W
         A61mJI7K8CnNfWGludJxAulzCQ4eWb7FAxWMW0GeAkJdw8jHvHtMRB5B/48NlYyWYOAw
         m3zRiu6RbYOUKkSE3xItT4j9vtdf+5gMDtCSKZ41fBRHb5kLdRS76mN7LRuQV8cKkaM6
         jCV5vzAZpz1LQBeOIazrXjrXvRP0P+lZturKAoj0W0vet7ObL6CzKnl9Umvglp3+86/R
         ZXrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748533830; x=1749138630;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=m/ZAsDiyBEUJhyA3+Rgv4QwvFmR3/7Sm2UmwbErJIko=;
        b=A3zpQTpq69Hg1HRawq5YOatyxB68KciC0fn14RixE171zGzr5DiRo4utvtKFT1hyG3
         NsCcxIVbO0ugXWaP45qnvlxt4MUKlQWwPx++iHpb75S9fivYLqB6hUznLz7KKsHoxU23
         9wZbEqfZhBCVqv/j0wkisGlt4u5rOI+OY8gchd7G7930XfqDbEu9ra7Ydq9AQ0vbMViQ
         4ZYiCx2FUxGMEuJsjJvSQBpUfw1P+aMRGTCgEq+YNX9c3eMLd4Oz/ue/0e8eIYCk4/tE
         xOo8YiggyyIPA96GblYOfg+90hT1f7roVLpr6XxsoZQqJS+R9iCMCY8uZxSeXFjdx3Eh
         etqA==
X-Gm-Message-State: AOJu0Ywe+O6u1zoeET32AC2UuIoSRmZBBjsD2Xyj84eGFx4jVuS3GgB3
	TwiTXzzfb3QvLd98/PGy1BkN23nJLt8dEO45w3CpZ4yboUVWNTV+ryQa80KX7Q6ze70=
X-Gm-Gg: ASbGnctv4W8t/LaTjhqOoP7rq/Jr4Y3vDNu2odRxTmHjABjI9UN3OopxspkOlwAp7Jj
	VmuRztCHCh9U9kPt+6nPWnix54cb8/mUFa/3ATYuMjCCgPdvUpDYlBVF8Fnscz/MUutQVAIVUB0
	89RHGoJBSaKxPaXgY22GRHxbKlDeDaMhqk5CGba7Gdgssu58ZUvMFp2scaDnZzMxtSBzcI1AGVd
	Uk/AgojGYtFtwgagn+UBdFxap+gh7sgpjl4O8atEAPc4ytIIL2HHAbU7AS/UI9HcVa1vr2sL00K
	klO85RMDuiLY+/b0iyNF9lMZz0GzCQp0c4l/JDLQEYkPlKjiWW1Pja2bqh/dAWnE6RuXoIumN5e
	8lLpWn/b5JylprL/452k17es=
X-Google-Smtp-Source: AGHT+IGa2r4D/VITSjdFBTxYkg6da0wYsZ2CMlkEQD6cZ8UUgLv8rIZMzxdmwr9D4pjVitwMZiA4/w==
X-Received: by 2002:a05:6512:630f:b0:553:2357:2890 with SMTP id 2adb3069b0e04-55323572a08mr5344205e87.45.1748533830134;
        Thu, 29 May 2025 08:50:30 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com
Subject: [PATCH v2 2/3] xen/arm: dom0less: Add trap-unmapped-accesses
Date: Thu, 29 May 2025 17:50:22 +0200
Message-ID: <20250529155024.1284227-3-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
References: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Add the trap-unmapped-accesses per-domain fdt property.

Signed-off-by: Edgar E. Iglesias 
---
 docs/misc/arm/device-tree/booting.txt | 9 +++++++++
 xen/arch/arm/dom0less-build.c         | 9 ++++++++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index 59fa96a82e..8a5c40ddf3 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -225,6 +225,15 @@ with the following properties:
     option is provided with a non zero value, but the platform doesn't support
     SVE.
 
+- trap-unmapped-accesses
+
+    Optional. An integer that configures handling of accesses to unmapped
+    address ranges.
+    If set to 0, guest accesses will read 0xFFFFFFFF and writes will be ignored.
+    If set to 1, guest accesses will trap.
+
+    This option is only implemented for ARM where the default is 1.
+
 - xen,enhanced
 
     A string property. Possible property values are:
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a4e0a33632..69324aa597 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -344,8 +344,15 @@ void __init arch_create_domUs(struct dt_device_node *node,
 #endif
     }
 
-    /* Trap accesses to unmapped areas. */
+    /* Trap unmapped accesses by default. */
     d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+    if ( dt_property_read_u32(node, "trap-unmapped-accesses", &val) )
+    {
+        if ( val > 1 )
+            panic("trap-unmapped-accesses: supported values are 0 or 1");
+        if ( !val )
+            d_cfg->flags &= ~XEN_DOMCTL_CDF_trap_unmapped_accesses;
+    }
 }
 
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu May 29 15:50:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 15:50:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000012.1380468 (Exim 4.92)
	(envelope-from )
	id 1uKfWd-0007Wv-VX; Thu, 29 May 2025 15:50:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000012.1380468; Thu, 29 May 2025 15:50:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKfWd-0007Wm-Rm; Thu, 29 May 2025 15:50:35 +0000
Received: by outflank-mailman (input) for mailman id 1000012;
 Thu, 29 May 2025 15:50:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKfWc-0007Vh-Vn
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 15:50:34 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a769275d-3ca4-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 17:50:33 +0200 (CEST)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-5532e0ad84aso1333445e87.2
 for ; Thu, 29 May 2025 08:50:33 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5533791ca53sm359962e87.162.2025.05.29.08.50.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 29 May 2025 08:50:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a769275d-3ca4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748533832; x=1749138632; 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;
        bh=tqOCJb7GRiVBBvisLzyRysHis/O4eLeaHxcKgZ0AZIA=;
        b=ko59lp1pcADCPjyIonyrKJ00bHjveyoXr/Sqr1y1XfXkLq9EBudYMP1StzXa12EYc5
         Of+4BJc2ERzsgtFNZYpEZyAw3xqQP9aivvLMUMVg05u72Za1EAZW5bWkcXYJjLM0h0pp
         gvcRRveo9rrQPsgrzrXUJDHsn0oJKlAcNGpluPY3WbTWVw1b3j+dpuI8A1Nw9yMn2Bto
         0ytiC4rIzzNclMOpuozw7OSChGgTtNpOvGODwfAZcGeu8gCHg9w9MVab8SLH1Cb4LoTz
         rVT6qM3XYeEge1Dvtd5NADx4ZfTd8PcBRG0GlZpYXxRnJaBnp9I/WvTBNvmlHE8bp58E
         AM8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748533832; x=1749138632;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=tqOCJb7GRiVBBvisLzyRysHis/O4eLeaHxcKgZ0AZIA=;
        b=ZClrXo3uedd71c1RAkTBj1C8rbB39DjWGMyyVLjn//R/c+mCEHm78YujDBef3GwyIt
         VzXvNBL3swwivVhkspqLeVd+jJl8PRllsG2doB5PJA2vpmHxQkyVFXWKSi5r/LZZ1veI
         GpNPxCwCENHG2wXwOBcbjM4Yl/NlBKwXfBDZJtgirtGhnqqRBAfWFIGuR7bPPnMfrB2y
         6gNCmFSTCZlKbjsgwrshKZUEF+ioBliTpiHeXXms/7FFt+S1U7+6t61aXTF27H7q+hZs
         PYZ0j3JwolYDUMAUM55inrjfVfIU0qfJ2hcb13Muv/MDf9lrFwRYqp9SsLGz2UWic6R3
         jb0A==
X-Gm-Message-State: AOJu0YzTOM+74bpKaJtjS5tSQ/7tJdixrP8fjQt93YW8Yxe61vLsH1Kr
	UfGG9K03sQ4pZfL7xcAdQj3ZMXmABt++5AHF/jC9zcWM2RePQhEUh0+DVkx+NfvERzU=
X-Gm-Gg: ASbGnctlWnOlYD+QK4LQG1d+M/4UcG5Rkz6D9pjev3bgqVhLmbwDjvkN5F3wEX68AWo
	WzhjvUm2RHskmIb3sKGM0qgVx+XC1LWQkuhtt1XgBxxgzIZ1RfW/NdXcjTwrAd0+n1BOGOwl4oh
	xfv9G8LuFH6UwJXDbQwXxyfRasK2Mj/bGIqNE8Zd7y8MBNFYDrCpF0eUooZP1k41CypevzZsKZo
	oi66NjixOnqKgfcSklvsuKmhhL8hT66WsVaS9mLMKp8zzB7T9/QWg2SbwAAyQD+S/WjZGoEX4OH
	X0MZJQOsIOSsyHXvTUTasPQB20o3ljPKMRgWp5C0zY906ghS0MXsj2Ji8xmtBJf8b4TSqnR3xSW
	uKK/4OazD78UeWjIY/6G8mWc=
X-Google-Smtp-Source: AGHT+IGPSue7MKunY2H9Ufyk2OZJ0tuTN/kpP94dQEQDIdlzvOjh5NgxGK1YbNNMufi/pOt/OJ3gWw==
X-Received: by 2002:a05:6512:3193:b0:553:388a:e794 with SMTP id 2adb3069b0e04-553388ae8f6mr1069086e87.17.1748533831821;
        Thu, 29 May 2025 08:50:31 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com,
	Anthony PERARD ,
	Juergen Gross 
Subject: [PATCH v2 3/3] tools/arm: Add the trap_unmapped_accesses xl config option
Date: Thu, 29 May 2025 17:50:23 +0200
Message-ID: <20250529155024.1284227-4-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
References: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Signed-off-by: Edgar E. Iglesias 
---
 docs/man/xl.cfg.5.pod.in         | 8 ++++++++
 tools/libs/light/libxl_arm.c     | 6 +++---
 tools/libs/light/libxl_create.c  | 3 +++
 tools/libs/light/libxl_types.idl | 1 +
 tools/libs/light/libxl_x86.c     | 6 ++++++
 tools/xl/xl_parse.c              | 3 +++
 6 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 7339c44efd..55e9cb5bd9 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3089,6 +3089,14 @@ will be used for the domain. Otherwise, the value specified by the `nr_spis`
 parameter will be used. The number of SPIs should match the highest interrupt
 ID that will be assigned to the domain.
 
+=item B
+
+An Optional boolean parameter that configures handling of accesses to unmapped
+address ranges. If enabled, guest accesses will trap. If disabled, guest
+accesses will read 0xFFFFFFFF and writes will be ignored.
+
+This option is only implemented for ARM where the default is enabled.
+
 =back
 
 =head3 x86
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 9530996e72..afc62a5299 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -233,9 +233,6 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
     }
 
-    /* Trap accesses to unmapped areas. */
-    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
-
     return 0;
 }
 
@@ -1714,6 +1711,9 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
     /* ACPI is disabled by default */
     libxl_defbool_setdefault(&b_info->acpi, false);
 
+    /* Trapping of unmapped accesses enabled by default.  */
+    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, true);
+
     /* Sanitise SVE parameter */
     if (b_info->arch_arm.sve_vl) {
         unsigned int max_sve_vl =
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index e03599ea99..38770eea5b 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -667,6 +667,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
         if (libxl_defbool_val(b_info->vpmu))
             create.flags |= XEN_DOMCTL_CDF_vpmu;
 
+        if (libxl_defbool_val(b_info->trap_unmapped_accesses))
+            create.flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+
         assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
         LOG(DETAIL, "passthrough: %s",
             libxl_passthrough_to_string(info->passthrough));
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 9bb2969931..e33785c661 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -736,6 +736,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("vmtrace_buf_kb", integer),
 
     ("vpmu", libxl_defbool),
+    ("trap_unmapped_accesses", libxl_defbool),
 
     ], dir=DIR_IN,
        copy_deprecated_fn="libxl__domain_build_info_copy_deprecated",
diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
index 0b1c2d3a96..a9d470c9f6 100644
--- a/tools/libs/light/libxl_x86.c
+++ b/tools/libs/light/libxl_x86.c
@@ -26,6 +26,11 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
     if (libxl_defbool_val(d_config->b_info.arch_x86.msr_relaxed))
         config->arch.misc_flags |= XEN_X86_MSR_RELAXED;
 
+    if (libxl_defbool_val(d_config->b_info.trap_unmapped_accesses)) {
+            LOG(ERROR, "trap_unmapped_accesses is not supported on x86\n");
+            return ERROR_FAIL;
+    }
+
     return 0;
 }
 
@@ -813,6 +818,7 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
 {
     libxl_defbool_setdefault(&b_info->acpi, true);
     libxl_defbool_setdefault(&b_info->arch_x86.msr_relaxed, false);
+    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, false);
 
     /*
      * The config parameter "altp2m" replaces the parameter "altp2mhvm".
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 089a88935a..40da75ef74 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2975,6 +2975,9 @@ skip_usbdev:
     if (!xlu_cfg_get_long (config, "nr_spis", &l, 0))
         b_info->arch_arm.nr_spis = l;
 
+    xlu_cfg_get_defbool(config, "trap_unmapped_accesses",
+                        &b_info->trap_unmapped_accesses, 0);
+
     parse_vkb_list(config, d_config);
 
     d_config->virtios = NULL;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu May 29 15:59:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 15:59:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000038.1380479 (Exim 4.92)
	(envelope-from )
	id 1uKffC-0000dQ-Qd; Thu, 29 May 2025 15:59:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000038.1380479; Thu, 29 May 2025 15:59: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 1uKffC-0000dJ-Mm; Thu, 29 May 2025 15:59:26 +0000
Received: by outflank-mailman (input) for mailman id 1000038;
 Thu, 29 May 2025 15:59:24 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uKffA-0000dD-S9
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 15:59:24 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uKffA-008P7g-0O;
 Thu, 29 May 2025 15:59:24 +0000
Received: from [15.248.2.29] (helo=[10.24.66.169])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uKffA-00F2eO-14;
 Thu, 29 May 2025 15:59: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=mE9O3jWM2USdWBRTBziuxdzcKSsudKHadfdNM/6nhoE=; b=Ob9jKw20RcUvwYM/N0xct+O5+Y
	h8XxBOLzXTaxT/8kKoRnIRKxSBEEW0YM9/OPJidGkuDM6i21spT9zucUg+MoLf70WuxQw8BvVbpry
	ntoS9RZ481npjOzYTmgNs7o70gXUPMr2Ge8CsPzan4XZdrwMiRP0Tc5RxNE89ZN7d1f8=;
Message-ID: 
Date: Thu, 29 May 2025 16:59:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] xen/arm: Add way to disable traps on accesses to
 unmapped addresses
Content-Language: en-GB
To: "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, bertrand.marquis@arm.com, michal.orzel@amd.com,
 Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com,
 edgar.iglesias@amd.com, Anthony PERARD ,
 Juergen Gross , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
 <20250529155024.1284227-2-edgar.iglesias@gmail.com>
From: Julien Grall 
In-Reply-To: <20250529155024.1284227-2-edgar.iglesias@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Edgar,

On 29/05/2025 16:50, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Add a per-domain way to optionally disable traps for accesses
> to unmapped addresses.
> 
> The domain flag is general but it's only implemented for ARM for now.
> 
> Signed-off-by: Edgar E. Iglesias 
> ---
>   tools/libs/light/libxl_arm.c  |  3 +++
>   xen/arch/arm/dom0less-build.c |  3 +++
>   xen/arch/arm/domain.c         |  3 ++-
>   xen/arch/arm/domain_build.c   |  3 ++-
>   xen/arch/arm/io.c             | 36 +++++++++++++++++++++++++++++++++--
>   xen/common/domain.c           |  3 ++-
>   xen/include/public/domctl.h   |  4 +++-

Looking at the changelog, I saw you removed the go bindings (although, 
they were in patch 3). But I don't quite understand why.

Also, I think you need to update the OCaml bindings.


>   7 files changed, 49 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index 75c811053c..9530996e72 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -233,6 +233,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>           config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
>       }
>   
> +    /* Trap accesses to unmapped areas. */
> +    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> +
>       return 0;
>   }
>   
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index a49764f0ad..a4e0a33632 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -343,6 +343,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
>           panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
>   #endif
>       }
> +
> +    /* Trap accesses to unmapped areas. */
> +    d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
>   }
>   
>   int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 45aeb8bddc..be58a23dd7 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -612,7 +612,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>       unsigned int max_vcpus;
>       unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
>       unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu |
> -                                   XEN_DOMCTL_CDF_xs_domain );
> +                                   XEN_DOMCTL_CDF_xs_domain |
> +                                   XEN_DOMCTL_CDF_trap_unmapped_accesses );
>       unsigned int sve_vl_bits = sve_decode_vl(config->arch.sve_vl);
>   
>       if ( (config->flags & ~flags_optional) != flags_required )
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index b189a7cfae..7ff9c1b584 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2003,7 +2003,8 @@ void __init create_dom0(void)
>   {
>       struct domain *dom0;
>       struct xen_domctl_createdomain dom0_cfg = {
> -        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
> +        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
> +                 XEN_DOMCTL_CDF_trap_unmapped_accesses,
>           .max_evtchn_port = -1,
>           .max_grant_frames = gnttab_dom0_frames(),
>           .max_maptrack_frames = -1,
> diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> index 5a4b0e8f25..adfc822e7e 100644
> --- a/xen/arch/arm/io.c
> +++ b/xen/arch/arm/io.c
> @@ -21,6 +21,32 @@
>   
>   #include "decode.h"
>   
> +/* Handler for unmapped ranges. Writes ignored, reads return all ones.  */
> +static int unmapped_read(struct vcpu *v, mmio_info_t *info, register_t *r,
> +                         void *priv)
> +{
> +    uint64_t mask = GENMASK_ULL((1U << info->dabt.size) * 8 - 1, 0);

NIT: Looking at the other part of io.c, we are using GENMASK. Any reason 
to not use the same?

> +
> +    /* Mask off upper bits.  */
> +    *r = UINT64_MAX & mask;
> +    return 1;
> +}
> +
> +static int unmapped_write(struct vcpu *v, mmio_info_t *info, register_t r,
> +                          void *priv)
> +{
> +    return 1;
> +}
> +
> +static const struct mmio_handler_ops unmapped_ops = {
> +    .read = unmapped_read,
> +    .write = unmapped_write
> +};
> +
> +static const struct mmio_handler unmapped_handler = {
> +    .ops = &unmapped_ops
> +};
> +
>   static enum io_state handle_read(const struct mmio_handler *handler,
>                                    struct vcpu *v,
>                                    mmio_info_t *info)
> @@ -175,11 +201,17 @@ enum io_state try_handle_mmio(struct cpu_user_regs *regs,
>       handler = find_mmio_handler(v->domain, info->gpa);
>       if ( !handler )
>       {
> +        bool trap_unmapped = v->domain->options &
> +                                         XEN_DOMCTL_CDF_trap_unmapped_accesses;
>           rc = try_fwd_ioserv(regs, v, info);
>           if ( rc == IO_HANDLED )
>               return handle_ioserv(regs, v);
> -
> -        return rc;
> +        else if ( rc == IO_UNHANDLED && !trap_unmapped )
> +        {
> +            /* Fallback to the unmapped handler. */
> +            handler = &unmapped_handler;
> +        } else

Style:

else if ( ... )
{
}
else
{
}

> +            return rc;
>       }
>   
>       /*
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index abf1969e60..ac4f58f638 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -721,7 +721,8 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
>            ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
>              XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
>              XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu |
> -           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) )
> +           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu |
> +           XEN_DOMCTL_CDF_trap_unmapped_accesses) )
>       {
>           dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
>           return -EINVAL;
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 5b2063eed9..be19ab5e26 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -66,9 +66,11 @@ struct xen_domctl_createdomain {
>   #define XEN_DOMCTL_CDF_nested_virt    (1U << _XEN_DOMCTL_CDF_nested_virt)
>   /* Should we expose the vPMU to the guest? */
>   #define XEN_DOMCTL_CDF_vpmu           (1U << 7)
> +/* Should we trap guest accesses to unmapped addresses? */
> +#define XEN_DOMCTL_CDF_trap_unmapped_accesses  (1U << 8)
>   
>   /* Max XEN_DOMCTL_CDF_* constant.  Used for ABI checking. */
> -#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_vpmu
> +#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_trap_unmapped_accesses
>   
>       uint32_t flags;
>   

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu May 29 16:03:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 16:03:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000052.1380488 (Exim 4.92)
	(envelope-from )
	id 1uKfiu-000304-8G; Thu, 29 May 2025 16:03:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000052.1380488; Thu, 29 May 2025 16: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 1uKfiu-0002zx-4u; Thu, 29 May 2025 16:03:16 +0000
Received: by outflank-mailman (input) for mailman id 1000052;
 Thu, 29 May 2025 16:03:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uKfis-0002zr-M5
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 16:03:14 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uKfis-008PjO-0V;
 Thu, 29 May 2025 16:03:14 +0000
Received: from [15.248.2.29] (helo=[10.24.66.169])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uKfis-00F5mZ-1L;
 Thu, 29 May 2025 16:03: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=zkH6wO2Jc9ucDpPtbdQM1mfSYmuHc5XcJF5Rb0Oq8dE=; b=wk0ccfAqJ0ST5arbyLOmAC5hAG
	rA0CgdTdMNzNrX/0tZ6kg0JYolpwro/nvfhz7i7F/HIQKb4C5Uh5BaZpOGpzbf2Js+o+fnPRD46kb
	oiyxbF7AugA/FQBAw4xK3CTpP8C4I8uID0jWfsXSVxWZdMD5Hpc+20N46AzB6ctXNEuQ=;
Message-ID: <8c93db26-fd37-4e37-9822-54986e5ee3cc@xen.org>
Date: Thu, 29 May 2025 17:03:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] xen/arm: dom0less: Add trap-unmapped-accesses
Content-Language: en-GB
To: "Edgar E. Iglesias" ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, bertrand.marquis@arm.com, michal.orzel@amd.com,
 Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com, edgar.iglesias@amd.com
References: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
 <20250529155024.1284227-3-edgar.iglesias@gmail.com>
From: Julien Grall 
In-Reply-To: <20250529155024.1284227-3-edgar.iglesias@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Edgar,

On 29/05/2025 16:50, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Add the trap-unmapped-accesses per-domain fdt property.
> 
> Signed-off-by: Edgar E. Iglesias 
> ---
>   docs/misc/arm/device-tree/booting.txt | 9 +++++++++
>   xen/arch/arm/dom0less-build.c         | 9 ++++++++-
>   2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> index 59fa96a82e..8a5c40ddf3 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -225,6 +225,15 @@ with the following properties:
>       option is provided with a non zero value, but the platform doesn't support
>       SVE.
>   
> +- trap-unmapped-accesses
> +
> +    Optional. An integer that configures handling of accesses to unmapped
> +    address ranges.
> +    If set to 0, guest accesses will read 0xFFFFFFFF and writes will be ignored.

Looking at the code, if I am not mistaken, it will only return this 
value for 32-bit. For 64-bit there will be a few Fs more and for less 
there will be less. So I think this needs to be reworded.

The rest looks good to me.

> +
> +    This option is only implemented for ARM where the default is 1.
> +
>   - xen,enhanced
>   
>       A string property. Possible property values are:
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index a4e0a33632..69324aa597 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -344,8 +344,15 @@ void __init arch_create_domUs(struct dt_device_node *node,
>   #endif
>       }
>   
> -    /* Trap accesses to unmapped areas. */
> +    /* Trap unmapped accesses by default. */
>       d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> +    if ( dt_property_read_u32(node, "trap-unmapped-accesses", &val) )
> +    {
> +        if ( val > 1 )
> +            panic("trap-unmapped-accesses: supported values are 0 or 1");
> +        if ( !val )
> +            d_cfg->flags &= ~XEN_DOMCTL_CDF_trap_unmapped_accesses;
> +    }
>   }
>   
>   int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Thu May 29 16:24:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 16:24:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000065.1380497 (Exim 4.92)
	(envelope-from )
	id 1uKg2z-0006GJ-Qe; Thu, 29 May 2025 16:24:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000065.1380497; Thu, 29 May 2025 16:24: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 1uKg2z-0006GC-OC; Thu, 29 May 2025 16:24:01 +0000
Received: by outflank-mailman (input) for mailman id 1000065;
 Thu, 29 May 2025 16:24:01 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKg2z-0006G6-7X
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 16:24:01 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5384f927-3ca9-11f0-a2ff-13f23c93f187;
 Thu, 29 May 2025 18:23:59 +0200 (CEST)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-55320ddb9edso1213455e87.1
 for ; Thu, 29 May 2025 09:23:59 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32a85b35a9csm3164641fa.31.2025.05.29.09.23.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 29 May 2025 09: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" 
X-Inumbo-ID: 5384f927-3ca9-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748535839; x=1749140639; darn=lists.xenproject.org;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :message-id:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uKVZ8hM5JL9F4sY2jyOFCDZ+62Qu1GrwyfvDaA5kM10=;
        b=JYvUh0/Q9WhpntmupqRU6ONlrBaA5pWoMH21YROGrc7S2gVHC/5hzGeuCaXhGpYnZg
         hfFz1pxU94frO8EsS4t42j9mVZVJ663TTfRvTWG6Mmdv8KKKb60zDIYpRvJlapzsCC4X
         nghFJCrgd1kl7XRhK/gPOZZP/rmSjvGreMNI7FgxgHt30FmwLduk3BZlol+YQ+oDHhe4
         7uUalDGZ5WWXnZIj78xsolmcwV3+Upj6O7IilnoHhB4y2lalXJ9C6zJuZwaCT6uU2onS
         7tflxaQ/wEO8tfxX7d4dZVYCK0bF3Q6v2qynM9zEl5JqGCx0qrTQT3pss0I2brGHECM1
         SJ6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748535839; x=1749140639;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=uKVZ8hM5JL9F4sY2jyOFCDZ+62Qu1GrwyfvDaA5kM10=;
        b=Uf7I1lVbmiZdUNIVXqtJbZNQYeK5p58AWm2sNEZUmWSG/n8j+iq/TbXQ8EhMz91X7S
         vqy4RDU3SWU0INxmTTwpxEsBSf7mIJ0hdBVrvJssTxx7+Q580TPWAlG5HL0tjb+5UUMM
         umGTlrBL7aufGTopoMFopyam8dRN6UOTdl8JZM6VZFQIzzYSOm+iLbSL3loxxqQCIbkC
         Nw3OFfbHBGbioqVHYUEgGdK/m5Vahrcphr6XWESvL0o91NqARSG1Rg5vFF0IiAKXJD3D
         Ownc16W690F2nzJzCCzMXtArDHYn5UdpMvEtNCk0Kjh3SAZhUl+8zuG+twZgJlI1+Fwi
         oHxA==
X-Gm-Message-State: AOJu0Yw69uP5Kx2Iz9ZP3xCl3Dxq0/jtpbreJ1w4ZRmnZE3UFjT6BcSc
	DAWHJFfHnxDWpSDfCDif8wIJAKVWbLAe2vPqHQATMLvPEt3izlikChQ+
X-Gm-Gg: ASbGncutCPUMxtpt8Aaen7g0yBq9Z+16xGgm9IteTS+2NJIfvs0MEfUUI2clNpF1LMB
	n5AXz6xGvyzpFu7pJeUobOGUnS222/KQIh51h4/a4+pyMBM5cjiZp80kki37B0Rv6fzjbOu2eNs
	ktyuAnpVvhY2KPoC8aHIiyOYW09Jn4ph6xA3tsl1xz99z5kpEwl00QlcrGSQee/fEeSm/iZQZW2
	BBO1GcmdkEa/jnmzwE0HdoW17VSIbmeDrsOjce9ZR8qq/4r4A5J5gItox8/GZ1XVQvib9BRPw+A
	Hrkem34OJ0323l5+z8Uq+hlyDl4ztBCZwxW0z8V3PAc8BFhvb2NhdUfc6iUAeqI/RXSSlLuG7xF
	it5Wm1PPJtvzUO/PQ/e08d08=
X-Google-Smtp-Source: AGHT+IH5310xo/6BN95Ny48JOPY+x8KYx47NMZ1mnhTFARZ7rLFIQvy0ro3E7hNYDXsjgLGmC8lDWQ==
X-Received: by 2002:a2e:ad90:0:b0:32a:8035:3f64 with SMTP id 38308e7fff4ca-32a8ce40d86mr2530711fa.33.1748535838995;
        Thu, 29 May 2025 09:23:58 -0700 (PDT)
Date: Thu, 29 May 2025 18:23:58 +0200
From: "Edgar E. Iglesias" 
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
	bertrand.marquis@arm.com, michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com,
	edgar.iglesias@amd.com, Anthony PERARD ,
	Juergen Gross , Jan Beulich ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Subject: Re: [PATCH v2 1/3] xen/arm: Add way to disable traps on accesses to
 unmapped addresses
Message-ID: 
References: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
 <20250529155024.1284227-2-edgar.iglesias@gmail.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/2.2.14+84 (2efcabc4) (2025-03-23)

On Thu, May 29, 2025 at 04:59:21PM +0100, Julien Grall wrote:
> Hi Edgar,

Hi Julien,


> 
> On 29/05/2025 16:50, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias" 
> > 
> > Add a per-domain way to optionally disable traps for accesses
> > to unmapped addresses.
> > 
> > The domain flag is general but it's only implemented for ARM for now.
> > 
> > Signed-off-by: Edgar E. Iglesias 
> > ---
> >   tools/libs/light/libxl_arm.c  |  3 +++
> >   xen/arch/arm/dom0less-build.c |  3 +++
> >   xen/arch/arm/domain.c         |  3 ++-
> >   xen/arch/arm/domain_build.c   |  3 ++-
> >   xen/arch/arm/io.c             | 36 +++++++++++++++++++++++++++++++++--
> >   xen/common/domain.c           |  3 ++-
> >   xen/include/public/domctl.h   |  4 +++-
> 
> Looking at the changelog, I saw you removed the go bindings (although, they
> were in patch 3). But I don't quite understand why.

I got a little confused. The file tools/golang/xenlight/helpers.gen.go
has the following at the top:
// Code generated by gengotypes.py. DO NOT EDIT.
// source: libxl_types.idl


So I got the impression that we shouldn't be editing it.
Should I edit it manually? Or should I try to rerun gengotypes.py
to generate these bindings?


> 
> Also, I think you need to update the OCaml bindings.

I see, I'll have a look.

> 
> 
> >   7 files changed, 49 insertions(+), 6 deletions(-)
> > 
> > diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> > index 75c811053c..9530996e72 100644
> > --- a/tools/libs/light/libxl_arm.c
> > +++ b/tools/libs/light/libxl_arm.c
> > @@ -233,6 +233,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> >           config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
> >       }
> > +    /* Trap accesses to unmapped areas. */
> > +    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> > +
> >       return 0;
> >   }
> > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> > index a49764f0ad..a4e0a33632 100644
> > --- a/xen/arch/arm/dom0less-build.c
> > +++ b/xen/arch/arm/dom0less-build.c
> > @@ -343,6 +343,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
> >           panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
> >   #endif
> >       }
> > +
> > +    /* Trap accesses to unmapped areas. */
> > +    d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> >   }
> >   int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 45aeb8bddc..be58a23dd7 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -612,7 +612,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
> >       unsigned int max_vcpus;
> >       unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
> >       unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu |
> > -                                   XEN_DOMCTL_CDF_xs_domain );
> > +                                   XEN_DOMCTL_CDF_xs_domain |
> > +                                   XEN_DOMCTL_CDF_trap_unmapped_accesses );
> >       unsigned int sve_vl_bits = sve_decode_vl(config->arch.sve_vl);
> >       if ( (config->flags & ~flags_optional) != flags_required )
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index b189a7cfae..7ff9c1b584 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2003,7 +2003,8 @@ void __init create_dom0(void)
> >   {
> >       struct domain *dom0;
> >       struct xen_domctl_createdomain dom0_cfg = {
> > -        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
> > +        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
> > +                 XEN_DOMCTL_CDF_trap_unmapped_accesses,
> >           .max_evtchn_port = -1,
> >           .max_grant_frames = gnttab_dom0_frames(),
> >           .max_maptrack_frames = -1,
> > diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> > index 5a4b0e8f25..adfc822e7e 100644
> > --- a/xen/arch/arm/io.c
> > +++ b/xen/arch/arm/io.c
> > @@ -21,6 +21,32 @@
> >   #include "decode.h"
> > +/* Handler for unmapped ranges. Writes ignored, reads return all ones.  */
> > +static int unmapped_read(struct vcpu *v, mmio_info_t *info, register_t *r,
> > +                         void *priv)
> > +{
> > +    uint64_t mask = GENMASK_ULL((1U << info->dabt.size) * 8 - 1, 0);
> 
> NIT: Looking at the other part of io.c, we are using GENMASK. Any reason to
> not use the same?

Looking closer at it now and no, there's no good reason. I'll change
to GENMASK in v3.


> 
> > +
> > +    /* Mask off upper bits.  */
> > +    *r = UINT64_MAX & mask;
> > +    return 1;
> > +}
> > +
> > +static int unmapped_write(struct vcpu *v, mmio_info_t *info, register_t r,
> > +                          void *priv)
> > +{
> > +    return 1;
> > +}
> > +
> > +static const struct mmio_handler_ops unmapped_ops = {
> > +    .read = unmapped_read,
> > +    .write = unmapped_write
> > +};
> > +
> > +static const struct mmio_handler unmapped_handler = {
> > +    .ops = &unmapped_ops
> > +};
> > +
> >   static enum io_state handle_read(const struct mmio_handler *handler,
> >                                    struct vcpu *v,
> >                                    mmio_info_t *info)
> > @@ -175,11 +201,17 @@ enum io_state try_handle_mmio(struct cpu_user_regs *regs,
> >       handler = find_mmio_handler(v->domain, info->gpa);
> >       if ( !handler )
> >       {
> > +        bool trap_unmapped = v->domain->options &
> > +                                         XEN_DOMCTL_CDF_trap_unmapped_accesses;
> >           rc = try_fwd_ioserv(regs, v, info);
> >           if ( rc == IO_HANDLED )
> >               return handle_ioserv(regs, v);
> > -
> > -        return rc;
> > +        else if ( rc == IO_UNHANDLED && !trap_unmapped )
> > +        {
> > +            /* Fallback to the unmapped handler. */
> > +            handler = &unmapped_handler;
> > +        } else
> 
> Style:
> 
> else if ( ... )
> {
> }
> else
> {
> }

Will fix for v3.

Thanks,
Edgar


> 
> > +            return rc;
> >       }
> >       /*
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index abf1969e60..ac4f58f638 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -721,7 +721,8 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
> >            ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
> >              XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
> >              XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu |
> > -           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) )
> > +           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu |
> > +           XEN_DOMCTL_CDF_trap_unmapped_accesses) )
> >       {
> >           dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
> >           return -EINVAL;
> > diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> > index 5b2063eed9..be19ab5e26 100644
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -66,9 +66,11 @@ struct xen_domctl_createdomain {
> >   #define XEN_DOMCTL_CDF_nested_virt    (1U << _XEN_DOMCTL_CDF_nested_virt)
> >   /* Should we expose the vPMU to the guest? */
> >   #define XEN_DOMCTL_CDF_vpmu           (1U << 7)
> > +/* Should we trap guest accesses to unmapped addresses? */
> > +#define XEN_DOMCTL_CDF_trap_unmapped_accesses  (1U << 8)
> >   /* Max XEN_DOMCTL_CDF_* constant.  Used for ABI checking. */
> > -#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_vpmu
> > +#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_trap_unmapped_accesses
> >       uint32_t flags;
> 
> -- 
> Julien Grall
> 


From xen-devel-bounces@lists.xenproject.org Thu May 29 16:30:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 16:30:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000076.1380508 (Exim 4.92)
	(envelope-from )
	id 1uKg9G-0007sQ-JT; Thu, 29 May 2025 16:30:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000076.1380508; Thu, 29 May 2025 16:30: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 1uKg9G-0007sJ-Fe; Thu, 29 May 2025 16:30:30 +0000
Received: by outflank-mailman (input) for mailman id 1000076;
 Thu, 29 May 2025 16:30:29 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKg9F-0007sD-RH
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 16:30:29 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3aec8f13-3caa-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 18:30:28 +0200 (CEST)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-5532a30ac41so1321759e87.0
 for ; Thu, 29 May 2025 09:30:28 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5533793780asm374527e87.222.2025.05.29.09.30.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 29 May 2025 09:30: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" 
X-Inumbo-ID: 3aec8f13-3caa-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748536227; x=1749141027; darn=lists.xenproject.org;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :message-id:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KDfozTeTL73IOCurOX4vdAd5idolzSMAe8Z1aI0ghlQ=;
        b=B2fVjJeW/l3jo/q2O29R+0wR0iUe53yQZrY1R9VvPCvdt4AKllty6U1WuuaFxeIGSH
         p2GflMUdsn0hJDtTE7FAdMexq3HAKkDXBL9WpzfkwcYFVOM+09WuQ2QbzukeJBu2q6fB
         MNZFBIMYC+/2nzxJ+id80o8FTVhnPj1S2I3INQzdMhX7jJEHUt37R9vEQNWWBf03DUVw
         dPBvYNfsvChJ/3IirinANkagQZ57ms525/TDKBGyikmzaVbKm2H+2dRnTYiqdm+y0I5W
         +2Goym5MMFUzKwZmahzWSc2RnT2g4oHrPZ4k3A3+Vrxl+oh7Pcn3crJOAQ6W+6K0E/li
         o13Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748536227; x=1749141027;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=KDfozTeTL73IOCurOX4vdAd5idolzSMAe8Z1aI0ghlQ=;
        b=CXFze0PLv0F4JspnTB6MALNh/Zrg2GcHL3Y7e2VlWTmTj41RfhArMTL2Z0g7VC72wd
         vfjARo1jQqgVaKZZ6quqsufsdAsizroqlsA1CpqWCJ3hzfsgwIYJj3tQ6Qar7LFwEyIH
         7PQs5oeHi0Sf4eCqDAOWTjOqEMxOD13UxDdpjEmZErTPcURbcgMNOUjrSBH5hUdPhrrA
         GU7QhhZ/OHdjQRs4OA7NS8DuNty4URJzgY2mk4mmJwnwxlWflWXyxblaF7iJJaWb27EE
         5nhmqB7fvGpPUh8r6zvzN5fJZAWWonimMfCKvdGR2I4K87gWMOvEScRJLiJUQAeMPJFe
         ywew==
X-Gm-Message-State: AOJu0Yxmgq1bWckH1q7g4X479R8rFt7vsYseDn+//89Mnd8YuJGAI2tA
	xAuHqmuZ6w7r2Ye5m0b2Bsm3cpRk5OyBZawMJ6B2/RJ42rl8Ta3X/G0oDCsoZ2Ixkrs=
X-Gm-Gg: ASbGncvICAlC0vJd8DPjJPfLIKYzYI9NztueyZIMVP9dD+pQymFqtbVCtccHvU2YE1T
	sdnukOBJA9Ulbbo7G3MwD1AJ0l8HdBrFjHHKJzVtp7BdgWdS2/NjWY+gKYB5bsXmUljg9nTdw1O
	+8wlYu/7HAbaI4KbhktPcew5kV/MpCK2RdJf+lk+tcGoWQseeJWJeyHQA5wa2dw4rva+ePzYXUs
	vLC6G9UQWTkwt5jbC2mYltMP0koybfNVNH1LCnX7Tjh+MTPop6rMqa+szJPUQpmq5hOqPiUKHD5
	AMsHLpQ7GIefrsX+ntLJcH3A3B8JY+yljqEYQzsvjvAk/Gfb3ROa95xv5cd4UAmmM/vRaifFBg4
	rOgx7iDgU6lyB0RMjboWOFtY=
X-Google-Smtp-Source: AGHT+IGJGN4c8AQTzHLXkBWn5FEEMG/Oajv6MWTcgOJCzLoCOGI15v0yQfTSs5AcpIH1RwvRxhCsRA==
X-Received: by 2002:a05:6512:3a86:b0:54f:c58a:f777 with SMTP id 2adb3069b0e04-5533b9098b7mr34372e87.34.1748536227236;
        Thu, 29 May 2025 09:30:27 -0700 (PDT)
Date: Thu, 29 May 2025 18:30:26 +0200
From: "Edgar E. Iglesias" 
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
	bertrand.marquis@arm.com, michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com, andrew.cooper3@citrix.com,
	edgar.iglesias@amd.com
Subject: Re: [PATCH v2 2/3] xen/arm: dom0less: Add trap-unmapped-accesses
Message-ID: 
References: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
 <20250529155024.1284227-3-edgar.iglesias@gmail.com>
 <8c93db26-fd37-4e37-9822-54986e5ee3cc@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8c93db26-fd37-4e37-9822-54986e5ee3cc@xen.org>
User-Agent: Mutt/2.2.14+84 (2efcabc4) (2025-03-23)

On Thu, May 29, 2025 at 05:03:12PM +0100, Julien Grall wrote:
> Hi Edgar,
> 
> On 29/05/2025 16:50, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias" 
> > 
> > Add the trap-unmapped-accesses per-domain fdt property.
> > 
> > Signed-off-by: Edgar E. Iglesias 
> > ---
> >   docs/misc/arm/device-tree/booting.txt | 9 +++++++++
> >   xen/arch/arm/dom0less-build.c         | 9 ++++++++-
> >   2 files changed, 17 insertions(+), 1 deletion(-)
> > 
> > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> > index 59fa96a82e..8a5c40ddf3 100644
> > --- a/docs/misc/arm/device-tree/booting.txt
> > +++ b/docs/misc/arm/device-tree/booting.txt
> > @@ -225,6 +225,15 @@ with the following properties:
> >       option is provided with a non zero value, but the platform doesn't support
> >       SVE.
> > +- trap-unmapped-accesses
> > +
> > +    Optional. An integer that configures handling of accesses to unmapped
> > +    address ranges.
> > +    If set to 0, guest accesses will read 0xFFFFFFFF and writes will be ignored.
> 
> Looking at the code, if I am not mistaken, it will only return this value
> for 32-bit. For 64-bit there will be a few Fs more and for less there will
> be less. So I think this needs to be reworded.
> 
> The rest looks good to me.

Thanks, in v3 I'll change it to:
    If set to 0, guest accesses will read all bits as ones, e.g 0xFFFFFFFF
    for a 32bit access and writes will be ignored.

Cheers,
Edgar

> 
> > +
> > +    This option is only implemented for ARM where the default is 1.
> > +
> >   - xen,enhanced
> >       A string property. Possible property values are:
> > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> > index a4e0a33632..69324aa597 100644
> > --- a/xen/arch/arm/dom0less-build.c
> > +++ b/xen/arch/arm/dom0less-build.c
> > @@ -344,8 +344,15 @@ void __init arch_create_domUs(struct dt_device_node *node,
> >   #endif
> >       }
> > -    /* Trap accesses to unmapped areas. */
> > +    /* Trap unmapped accesses by default. */
> >       d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
> > +    if ( dt_property_read_u32(node, "trap-unmapped-accesses", &val) )
> > +    {
> > +        if ( val > 1 )
> > +            panic("trap-unmapped-accesses: supported values are 0 or 1");
> > +        if ( !val )
> > +            d_cfg->flags &= ~XEN_DOMCTL_CDF_trap_unmapped_accesses;
> > +    }
> >   }
> >   int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
> 
> Cheers,
> 
> -- 
> Julien Grall
> 


From xen-devel-bounces@lists.xenproject.org Thu May 29 18:57:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 18:57:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000116.1380518 (Exim 4.92)
	(envelope-from )
	id 1uKiRV-0007wy-6i; Thu, 29 May 2025 18:57:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000116.1380518; Thu, 29 May 2025 18: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 1uKiRV-0007wr-43; Thu, 29 May 2025 18:57:29 +0000
Received: by outflank-mailman (input) for mailman id 1000116;
 Thu, 29 May 2025 18:57:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKiRU-0007wl-8s
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 18:57:28 +0000
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com
 [2a00:1450:4864:20::235])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c3273c5c-3cbe-11f0-a2ff-13f23c93f187;
 Thu, 29 May 2025 20:57:26 +0200 (CEST)
Received: by mail-lj1-x235.google.com with SMTP id
 38308e7fff4ca-32a826ad3e0so11422881fa.2
 for ; Thu, 29 May 2025 11:57:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: c3273c5c-3cbe-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748545046; x=1749149846; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NW4xpPXELzmdxCP+iBWtcqsDHbMdMe39tFOYLXEyrro=;
        b=RZbX+iMm5e44XTIUZu0MfICVH8HN8kSu+cD0MVkb2JnqsT0oUr2kEnb/WHcRQbRKQ5
         u9iq4vw0ubwDX0pAyMAxW46zp5UvT6CcDqkYKUqnoNzyTQl3Hbe6AGaDZkQDtp94wdd5
         hdJkyOfWGsxRZA1ZNvtsiWCYY9j4h3BFGdzfsbgtb65IeBz8AQeAk+HyS9AtZaaz7gjl
         VLp4IpnBlJ9osdOP0UjtJerTm4WiF11K69fdbQR3lnt8O8zkoG6Kn88U0EN95jAOOd9K
         oe0OjK3uaYMxy/uQUtTnfhpv5dv2aPXMXte7rxivBO0C64MVMM57KLcLyCF43tWeZsuc
         Dk/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748545046; x=1749149846;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=NW4xpPXELzmdxCP+iBWtcqsDHbMdMe39tFOYLXEyrro=;
        b=RZvRNAnhSuTwP34xlcWNeY+RMt/LiYqRyI6LmG6foVNZwhmoR/5oob7CxTuON2VScN
         Z0HHQufceTmUrecdeorM3HwcQigKjNW6pTMHbnKr1BURgrb/CEAG8PFH18uTFNMGvgkc
         Erz/cMGsPGTJzu+sUL8ILbv8KXQiYbExdCozgI8y+pGeNkTlhRJ0CS4yCJi+XpGpiYd8
         GCCaUg5alleGhIhd8thsvyRSYJFlWuTFeMo7zwJXFXXTVl8uO91nKug/HEB2FA+o7aRc
         PkGfGaRMrDHKvXDaTAS+Vdd513lUPadhIRS+ffHU52JVg1KNrFGPGHI5Lc53EXh11GSs
         b2HA==
X-Gm-Message-State: AOJu0YzhWPM5QiK491bklcKSo041Th6QJTn6YL5QLLN/36KaqCcIKvpY
	LIAAH6H3y0YTsH6wEMHSVLaO+o4LNZ779+wWq1WHNPYccBe1hhKtUvcko7PeQ6+lq37WLFNLNkm
	t/2P6NwRh+Tzfyo3HIA4N5sRwBcEO9TscXp4jYAQ=
X-Gm-Gg: ASbGncuJ9fuZwVyFEZpUbCN/lEohRhso+tXN8NROEajd2rOb2CEouF4wQaR59V9xpwd
	UqZxWmqQOBXjk8BE40/7KvuR4Ne+hTTL4Z7H7SZ6LEQuRw+uuiBlPX9rahybSH0G9RzP2+Z/k9L
	sIVfqEGZzEnsg+sYy6lmd1Vqys8sSQs48=
X-Google-Smtp-Source: AGHT+IHuJsq7GWOtAxoc6p/4TRtHsg2IE99I54Xa9oWDlkq55Izgz7bUw1h2fXGehf/rCO0jUxi6ptMr0jjPx9w5kyc=
X-Received: by 2002:a05:6512:1052:b0:545:225d:6463 with SMTP id
 2adb3069b0e04-5533b930c42mr216682e87.42.1748545045378; Thu, 29 May 2025
 11:57:25 -0700 (PDT)
MIME-Version: 1.0
References:  <1a8313537603bee36636b0fcd2fdc2f76a2374fb.1748337249.git.mykola_kvach@epam.com>
In-Reply-To: <1a8313537603bee36636b0fcd2fdc2f76a2374fb.1748337249.git.mykola_kvach@epam.com>
From: Mykola Kvach 
Date: Thu, 29 May 2025 21:57:14 +0300
X-Gm-Features: AX0GCFva9bj4yTd7bnvXhf1-6-VxY2E0TII6YMtREuzeLjHOFu83BVF4tKdmSuE
Message-ID: 
Subject: Re: [PATCH v4][PART 1 2/4] xen/arm: Implement PSCI SYSTEM_SUSPEND
 call for guests
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach , Stefano Stabellini , 
	Julien Grall , Bertrand Marquis , 
	Michal Orzel , Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 27, 2025 at 12:19=E2=80=AFPM Mykola Kvach  wrote:
>
> From: Mykola Kvach 
>
> This patch adds support for the PSCI SYSTEM_SUSPEND function in the vPSCI
> (virtual PSCI) interface, allowing guests to request suspend via the PSCI
> v1.0 SYSTEM_SUSPEND call (both 32-bit and 64-bit variants).
>
> The implementation:
> - Adds SYSTEM_SUSPEND function IDs to PSCI definitions
> - Implements trapping and handling of SYSTEM_SUSPEND in vPSCI
> - Allows only non-hardware domains to invoke SYSTEM_SUSPEND; for the
>   hardware domain, PSCI_NOT_SUPPORTED is returned to avoid halting the
>   system in hwdom_shutdown() called from domain_shutdown
> - Ensures all secondary VCPUs of the calling domain are offline before
>   allowing suspend due to PSCI spec
> - Treats suspend as a "standby" operation: the domain is shut down with
>   SHUTDOWN_suspend, and resumes execution at the instruction following
>   the call
>
> Usage:
>
> For Linux-based guests, suspend can be initiated with:
>     echo mem > /sys/power/state
> or via:
>     systemctl suspend
>
> Resuming the guest is performed from control domain using:
>       xl resume 
>
> Signed-off-by: Mykola Kvach 
> ---
> Changes in V3:
> Dropped all domain flags and related code (which touched common functions=
 like
> vcpu_unblock), keeping only the necessary changes for Xen suspend/resume,=
 i.e.
> suspend/resume is now fully supported only for the hardware domain.
> Proper support for domU suspend/resume will be added in a future patch.
> This patch does not yet include VCPU context reset or domain context
> restoration in VCPU.
>
> Changes in V4:
> Dropped all changes related to watchdog, domain is marked as shutting
> down in domain_shutdown and watchdog timeout handler won't trigger
> because of it.
>
> Previous versions included code to manage Xen watchdog timers during susp=
end,
> but this was removed. When a guest OS starts the Xen watchdog (either via=
 the
> kernel driver or xenwatchdogd), it is responsible for managing that state
> across suspend/resume. On Linux, the Xen kernel driver properly stops the
> watchdog during suspend. However, when xenwatchdogd is used instead, susp=
end
> handling is incomplete, potentially leading to watchdog-triggered resets =
on
> resume. Xen leaves watchdog handling to the guest OS and its services.
>
> Dropped all changes related to VCPU context, because instead domain_shutd=
own
> is used, so we don't need any extra changes for suspending domain.
> ---
>  xen/arch/arm/include/asm/perfc_defn.h |  1 +
>  xen/arch/arm/include/asm/psci.h       |  2 +
>  xen/arch/arm/vpsci.c                  | 64 +++++++++++++++++++++++++++
>  3 files changed, 67 insertions(+)
>
> diff --git a/xen/arch/arm/include/asm/perfc_defn.h b/xen/arch/arm/include=
/asm/perfc_defn.h
> index effd25b69e..8dfcac7e3b 100644
> --- a/xen/arch/arm/include/asm/perfc_defn.h
> +++ b/xen/arch/arm/include/asm/perfc_defn.h
> @@ -33,6 +33,7 @@ PERFCOUNTER(vpsci_system_reset,        "vpsci: system_r=
eset")
>  PERFCOUNTER(vpsci_cpu_suspend,         "vpsci: cpu_suspend")
>  PERFCOUNTER(vpsci_cpu_affinity_info,   "vpsci: cpu_affinity_info")
>  PERFCOUNTER(vpsci_features,            "vpsci: features")
> +PERFCOUNTER(vpsci_system_suspend,      "vpsci: system_suspend")
>
>  PERFCOUNTER(vcpu_kick,                 "vcpu: notify other vcpu")
>
> diff --git a/xen/arch/arm/include/asm/psci.h b/xen/arch/arm/include/asm/p=
sci.h
> index 4780972621..48a93e6b79 100644
> --- a/xen/arch/arm/include/asm/psci.h
> +++ b/xen/arch/arm/include/asm/psci.h
> @@ -47,10 +47,12 @@ void call_psci_system_reset(void);
>  #define PSCI_0_2_FN32_SYSTEM_OFF          PSCI_0_2_FN32(8)
>  #define PSCI_0_2_FN32_SYSTEM_RESET        PSCI_0_2_FN32(9)
>  #define PSCI_1_0_FN32_PSCI_FEATURES       PSCI_0_2_FN32(10)
> +#define PSCI_1_0_FN32_SYSTEM_SUSPEND      PSCI_0_2_FN32(14)
>
>  #define PSCI_0_2_FN64_CPU_SUSPEND         PSCI_0_2_FN64(1)
>  #define PSCI_0_2_FN64_CPU_ON              PSCI_0_2_FN64(3)
>  #define PSCI_0_2_FN64_AFFINITY_INFO       PSCI_0_2_FN64(4)
> +#define PSCI_1_0_FN64_SYSTEM_SUSPEND      PSCI_0_2_FN64(14)
>
>  /* PSCI v0.2 affinity level state returned by AFFINITY_INFO */
>  #define PSCI_0_2_AFFINITY_LEVEL_ON      0
> diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> index d1615be8a6..866bd3128b 100644
> --- a/xen/arch/arm/vpsci.c
> +++ b/xen/arch/arm/vpsci.c
> @@ -197,6 +197,57 @@ static void do_psci_0_2_system_reset(void)
>      domain_shutdown(d,SHUTDOWN_reboot);
>  }
>
> +static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t =
cid)
> +{
> +    struct vcpu *v;
> +    struct domain *d =3D current->domain;
> +
> +    /* Drop this check once SYSTEM_SUSPEND is supported in hardware doma=
in */
> +    if ( is_hardware_domain(d) )
> +        return PSCI_NOT_SUPPORTED;
> +
> +    /* Ensure that all CPUs other than the calling one are offline */
> +    for_each_vcpu ( d, v )
> +    {
> +        if ( v !=3D current && is_vcpu_online(v) )
> +            return PSCI_DENIED;
> +    }
> +
> +    /*
> +     * System suspend requests are treated as performing standby
> +     * as this simplifies Xen implementation.
> +     *
> +     * Arm Power State Coordination Interface (DEN0022F.b)
> +     *
> +     * 5.20.2 Caller responsibilities
> +     * The call is equivalent to using the CPU_SUSPEND call for the deep=
est
> +     * possible platform powerdown state. Consequently, the caller must =
observe
> +     * all the rules described for CPU_SUSPEND. See section 5.4.
> +     *
> +     * 5.4.5 Caller responsibilities
> +     * The caller must not assume that a powerdown request will return u=
sing
> +     * the specified entry point address. The powerdown request might no=
t
> +     * complete due, for example, to pending interrupts. It is also poss=
ible
> +     * that, because of coordination with other cores, the actual state =
entered
> +     * is shallower than the one requested. Because of this it is possib=
le for
> +     * an implementation to downgrade the powerdown state request to a s=
tandby
> +     * state. In the case of a downgrade to standby, the implementation =
returns
> +     * at the instruction following the PSCI call, at the Exception leve=
l of
> +     * the caller, instead of returning by the specified entry point add=
ress.
> +     * The return code in this case is SUCCESS. In the case of an early =
return
> +     * due to a pending wakeup event, the implementation can return at t=
he next
> +     * instruction, with a return code of SUCCESS, or resume at the spec=
ified
> +     * entry point address.
> +     *
> +     * 5.4.9 Implementation responsibilities: State on return
> +     * When returning from a standby state, the caller must observe no c=
hange in
> +     * core state, other than any timer changes expected because of the =
time
> +     * spent in the state, and changes in the CPU interface because of t=
he
> +     * wakeup reason.
> +     */
> +    return domain_shutdown(d, SHUTDOWN_suspend) ? PSCI_DENIED : PSCI_SUC=
CESS;
> +}
> +
>  static int32_t do_psci_1_0_features(uint32_t psci_func_id)
>  {
>      /* /!\ Ordered by function ID and not name */
> @@ -214,6 +265,8 @@ static int32_t do_psci_1_0_features(uint32_t psci_fun=
c_id)
>      case PSCI_0_2_FN32_SYSTEM_OFF:
>      case PSCI_0_2_FN32_SYSTEM_RESET:
>      case PSCI_1_0_FN32_PSCI_FEATURES:
> +    case PSCI_1_0_FN32_SYSTEM_SUSPEND:
> +    case PSCI_1_0_FN64_SYSTEM_SUSPEND:
>      case ARM_SMCCC_VERSION_FID:
>          return 0;
>      default:
> @@ -344,6 +397,17 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, u=
int32_t fid)
>          return true;
>      }
>
> +    case PSCI_1_0_FN32_SYSTEM_SUSPEND:
> +    case PSCI_1_0_FN64_SYSTEM_SUSPEND:

note to self: update VPSCI_NR_FUNCS

> +    {
> +        register_t epoint =3D PSCI_ARG(regs,1);
> +        register_t cid =3D PSCI_ARG(regs,2);
> +
> +        perfc_incr(vpsci_system_suspend);
> +        PSCI_SET_RESULT(regs, do_psci_1_0_system_suspend(epoint, cid));
> +        return true;
> +    }
> +
>      default:
>          return false;
>      }
> --
> 2.48.1
>


From xen-devel-bounces@lists.xenproject.org Thu May 29 19:40:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 19:40:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000139.1380527 (Exim 4.92)
	(envelope-from )
	id 1uKj7T-0005WI-8h; Thu, 29 May 2025 19:40:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000139.1380527; Thu, 29 May 2025 19: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 1uKj7T-0005WB-61; Thu, 29 May 2025 19:40:51 +0000
Received: by outflank-mailman (input) for mailman id 1000139;
 Thu, 29 May 2025 19:40:50 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKj7R-0005W5-Vg
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 19:40:49 +0000
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [2a00:1450:4864:20::22c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d147ba59-3cc4-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 21:40:47 +0200 (CEST)
Received: by mail-lj1-x22c.google.com with SMTP id
 38308e7fff4ca-30effbfaf4aso12998161fa.3
 for ; Thu, 29 May 2025 12:40:47 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553378a1398sm433047e87.98.2025.05.29.12.40.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 29 May 2025 12:40: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" 
X-Inumbo-ID: d147ba59-3cc4-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748547646; x=1749152446; 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;
        bh=rpKd/J42XS/n8Ajsm4bUqkcbcsL2h/dueOBmKWGHbwE=;
        b=SWD7xHGDDcudKxZI3iOGEVCx945Z/xu6Bew6rCnZYYwxLNmdd5Hu/dIamyPua6x73u
         quKM80cfbSiyDkCg/fN6Hm990QgAVZJyMADi7SA0EPDdogfBq4TXs/qpeWwAw0V+SgOH
         4sbX8nPRz2Cz/wPCRTFg8jeZ/gkDFmf8m3rVcYLHj6xJNVm+9RQ2du01CdlVH145qFcW
         VxOTYdu7K+TxHLt5Tb9kqz4VHdh3420a0oZ9m2OkYrXXVgtvJFNqgUkmif0wtIsvuIS/
         628hDina6ZrCVc1BJh0us8DiQVFVGVWrTy/gNc5nrYVCMD98oDELRAZ0CghQBvCpzAob
         i3Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748547646; x=1749152446;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=rpKd/J42XS/n8Ajsm4bUqkcbcsL2h/dueOBmKWGHbwE=;
        b=qMUlT7QA248XEPBKub8ujFVqSoPg7ueLPUR7KWHX3ILrQ1H3ikBctuXwLbjEUsnYWe
         6k8snW2RBJNk5T2z3wQoPRD8+jEET8F1I+qcljk3seyI5U6Y/AKu64tTdiEQAGLGVdTT
         dOoltOnvnih2B5O6guGQ28C2mzeGHbPH+QsM/AtqUOyYMlvpGDZrnFAPTcR0ArAXLv4y
         l3i3pZVW2KY/2eyO6DhlepEF6ThY0KPMGeZ8EgtuPa7K/7Tr12PeHxhAj8B50d/BF81u
         wTTTOEVF/Guv1AKzRKE7J/H7xddoz26K8/Hb5N4PrtgwCF85JZMLkysc/M7K5q+b1nR/
         Wxuw==
X-Gm-Message-State: AOJu0YykYV3fZgWs2BpLjzhkKRqb7YFTDRvDNodB3YFA9xrTVGb4mvpg
	S8V30oPwp0g1KQfWY4rhp6JZlsrCLHUgmsMOvJwrvM9G3JCkb79lKDu++bdxkHKN
X-Gm-Gg: ASbGncst82uCnEwNKWcWKNnaCweJVnoRGIvZY/CokQu5e1OJfm8zDVKDU3VYZqrt7fc
	kWvsezcKxCB2ja+trqlKryC4D6GPc1jsqWm9hINEvlfciHb1uZ/mnhxPEKfBgRwnKVbLHmd3zOl
	pJjwq62m4FmV2+ad23To3Ih+FQQUpY54oK6pHIystta+qxmweD8yZKgbLBOnKLj/mJ4oPiOSbRZ
	tms5b3NgfV7nXXojHHV8nP/IADsixrW4wo8KoJMVMv/qERkiZCRjBk/CvkGlckUiLeSQVu1gDBu
	MZ5+jS6fwbu8VwseG6xIniYFH4XrgxwN7PWRuSNnSlqPknyeyGh4qw6IDw945vHIcLfSNDiPwB0
	O1jOF1Vi0hm6lCCGtT8gaA0a7dA==
X-Google-Smtp-Source: AGHT+IEAECnoaJVS2jk6rYeKh4G20H5DMO/k5s88BJYeCj5x0g6xbdS1jOMgrqDXTC8ZxtrC2y2CRA==
X-Received: by 2002:a05:6512:6d1:b0:553:263d:ab90 with SMTP id 2adb3069b0e04-5533b8f3ebamr267163e87.18.1748547646196;
        Thu, 29 May 2025 12:40:46 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH] xen/arm: vpsci: Fix typo in comment (SCCC changed to SSSC)
Date: Thu, 29 May 2025 22:40:25 +0300
Message-ID: <3881310bb93e20fd7d28d067e11ec9d19b68c60c.1748547428.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

Corrected a typo in a comment within vpsci.c:
  replaced "SCCC_SMCCC_*_REVISION" with the correct "SSSC_SMCCC_*_REVISION".

This change improves clarity but does not affect functionality.

Signed-off-by: Mykola Kvach 
---
 xen/arch/arm/vpsci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index d1615be8a6..7ba9ccd94b 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -268,7 +268,7 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
 {
     /*
      * /!\ VPSCI_NR_FUNCS (in asm/vpsci.h) should be updated when
-     * adding/removing a function. SCCC_SMCCC_*_REVISION should be
+     * adding/removing a function. SSSC_SMCCC_*_REVISION should be
      * updated once per release.
      */
     switch ( fid )
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Thu May 29 20:31:56 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 20:31:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000159.1380541 (Exim 4.92)
	(envelope-from )
	id 1uKjuf-0003NO-Vh; Thu, 29 May 2025 20:31:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000159.1380541; Thu, 29 May 2025 20: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 1uKjuf-0003NH-T8; Thu, 29 May 2025 20:31:41 +0000
Received: by outflank-mailman (input) for mailman id 1000159;
 Thu, 29 May 2025 20:31:40 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKjud-0003NB-S6
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 20:31:40 +0000
Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com
 [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e82599ca-3ccb-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 22:31:33 +0200 (CEST)
Received: by mx.zohomail.com with SMTPS id 1748550681506698.3450845038698;
 Thu, 29 May 2025 13:31: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" 
X-Inumbo-ID: e82599ca-3ccb-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; t=1748550684; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=F+a4llEx6qZnzDpeyqH+j92l70dBAfCcMsWt5J2PXCPXUQNOK3jbc6E48LtN6Vs4I0Ok9pGibRALjXUqHvgP3WGWuOiMYG1+vQsanag2xJC+nY5WMTObYN8DpR+LAT/oSnMKRJBRduyGwYw5yu1qMmdGfmE/t75uZoloaQI70nU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1748550684; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=NCDkM2xGyyPiLYig9bGe+zK5Ck8oQD1UXd2P5BAUWd8=; 
	b=JJEouIssOM/TP9FKNGG4abUMNBXAwsorCubjg3EpvH2oESpHNBF0EdlJ/vyqToG456BcPLBs9mWDzANblBco3OxPub5VGIDzLRKgKgrk1SuCQyMeQEz02ZbwGYWTU/MfQdnzqVELil5MuRUncAdZ4TdGWjEauVjWrCAHvj6fcvM=
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=1748550684;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=NCDkM2xGyyPiLYig9bGe+zK5Ck8oQD1UXd2P5BAUWd8=;
	b=vGyrGcYvIl5JiNW2VJRRc/8VQBSXE7vArZV/dXtAar5K7Ctx2Nax0UeHZWZ9ZHsN
	Ehdl/Bqpw9kl49p/6v1kCv/GM1HXDTIO+Z7XMoxY2MB2+BnEHEVxJdXMdyDlqtzMofO
	M58xWY5dZvF/V5RUf1WfCuf/+O0lDJ07CUZ8ZB0U=
Message-ID: 
Date: Thu, 29 May 2025 16:31:19 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/3] MAINTAINERS: add a reviewer for Argo
Content-Language: en-US
To: Christopher Clark ,
 xen-devel@lists.xenproject.org
Cc: Rich Persaud ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: <20250528211040.10562-1-christopher.w.clark@gmail.com>
 <20250528211040.10562-3-christopher.w.clark@gmail.com>
From: "Daniel P. Smith" 
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: <20250528211040.10562-3-christopher.w.clark@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 5/28/25 17:10, Christopher Clark wrote:
> Adding Daniel P. Smith as reviewer for the Argo subsystem.
> 
> Signed-off-by: Christopher Clark 
> Acked-by: Stefano Stabellini 
> ---
>   MAINTAINERS | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 697f383505..6b129704fc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -222,6 +222,7 @@ F:	tools/libacpi/
>   
>   ARGO
>   M:	Christopher Clark 
> +R:	Daniel P. Smith 
>   S:	Maintained
>   W:	https://wiki.xenproject.org/wiki/Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen
>   F:	xen/include/public/argo.h

Acked-by: Daniel P. Smith 


From xen-devel-bounces@lists.xenproject.org Thu May 29 21:46:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 21:46:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000196.1380556 (Exim 4.92)
	(envelope-from )
	id 1uKl4Z-0003HW-7q; Thu, 29 May 2025 21:45:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000196.1380556; Thu, 29 May 2025 21: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 1uKl4Z-0003HP-4q; Thu, 29 May 2025 21:45:59 +0000
Received: by outflank-mailman (input) for mailman id 1000196;
 Thu, 29 May 2025 21:45:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKl4Y-0003HJ-8v
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 21:45:58 +0000
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [2a00:1450:4864:20::132])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c9c7691-3cd6-11f0-b894-0df219b8e170;
 Thu, 29 May 2025 23:45:55 +0200 (CEST)
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-55324062ea8so1957860e87.3
 for ; Thu, 29 May 2025 14:45: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" 
X-Inumbo-ID: 4c9c7691-3cd6-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748555155; x=1749159955; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=ed10ZYXxBQhdz3iy3aGPB5wBv0Q403cPvua9xeow1K8=;
        b=BnsQ2ul3bNGXJwT1sK4jhzFMws4GHTuDLXcFMUZVinJweND11l5rjY3ENEG/68vZy+
         iVLg781Am1FK0DvBLn/Rmx2OAPAdkQspDjq4nmrYZ9DmJaSHrQbc0AKY5efTdr45qQCV
         JYeWVCC7PyEE/A5gVWjOHoiQm0trtR3lEAoht6kmx2ffovH7DhRH0MLpMmaTzrDCUYm0
         XZngqLpveRhyXuhNNO1L8XE3tyNe6EVNBwOexNSoO25HYkmaGpVTQtIi+k3ewdzb4oEl
         /r0yU5qqS4wKHaIJdv4LZ/XyiIlRj7RWElzgWEZXCDtJsPkO+MgixrYc4TZ+obHAOceM
         bGpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748555155; x=1749159955;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ed10ZYXxBQhdz3iy3aGPB5wBv0Q403cPvua9xeow1K8=;
        b=lb4wHbCAhnpQ2aErT/jxX0OFcvywp28NLGo9vIoxgozc/CaGBFO5gachgozui3nfSi
         Xi3L5mY3sYV3mtwtK2pD1wkoIg/qsn8jLFpL4HUtn3PqI/CuEiOQkT0flsWaRhAm0QX8
         Glxkm3sE2AuQ/XA4Q4OiL/zwO/L3NBv2Kyu2H6As+gOwng9gALucKRG4ozzbZIkK4dhE
         L8ihG2mpvR7JO0GG6JL+b+m41m5FL7eeOwxDdnFyRknHX+xGmSdyy43xKoUmeC/qcixs
         QpDXtLo0Ggl58FOdC5r6Nh2toeoMMmPtcvZrK/i2dIl/BBERXUfJBjP4GLiL2HmfXuiA
         K1xA==
X-Gm-Message-State: AOJu0Yxsq/rrd3iRkPl3jKbYMg6foFvn1bEZ/HDv9qzAbfF9tivkAjOq
	WSEjPuEm2UOTQJqk24xQl4oqAqi7oXsH9W5ta4IfUlEIiKtF31MX3pyznbyno0T1KhJuNjnAa3s
	jHHWKIIr6pJK+to/vbIoFqk+y7lbFSC8=
X-Gm-Gg: ASbGncuCrynkvtjBWXQjjZlaUmVpZeFMNsmedXFgo1/meWBa7iFAm5aHDDc+sflf2u8
	XJBwWpdLnmpV0iICVwtdAQmOS8kM4x955gIamw85cmkchKN96C7rMtJ4Rz5VDE11vovGkravyMn
	vyJ7N1mVq3+bzGGDcEPEzBoU2bl7loQLqnfMl1MysdowSdcxAVD0yU
X-Google-Smtp-Source: AGHT+IGiGTse/2m4bSgjP3dTLobbU3wzhbHi+Cq4cOniLY0tIUbLdWS0TAlE7Y9m20BiUuWvQgXIgJeeTFhVlhslgHw=
X-Received: by 2002:a05:6512:e94:b0:553:24b7:2f6f with SMTP id
 2adb3069b0e04-5533b93bb29mr397129e87.51.1748555154443; Thu, 29 May 2025
 14:45:54 -0700 (PDT)
MIME-Version: 1.0
References: <20250521211742.2997890-1-dmukhin@ford.com> <20250521211742.2997890-2-dmukhin@ford.com>
In-Reply-To: <20250521211742.2997890-2-dmukhin@ford.com>
From: Christopher Clark 
Date: Thu, 29 May 2025 22:45:43 +0100
X-Gm-Features: AX0GCFs907I7J5pfgAsS8eUeLyhuPaPHlHoZDLkMSMU7B9zKI6GiUa9YFb6KEok
Message-ID: 
Subject: Re: [XTF PATCH v2 1/2] tests/argo: Add argo test suite
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
	dpsmith@apertussolutions.com, michal.orzel@amd.com, persaur@gmail.com, 
	dmukhin@ford.com, Christopher Clark 
Content-Type: multipart/alternative; boundary="000000000000d9d4c606364d3838"

--000000000000d9d4c606364d3838
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 21, 2025 at 10:18=E2=80=AFPM  wrote:

> From: Christopher Clark 
>
> From: Christopher Clark 
>
> Simple test cases for the four Argo operations, register, unregister,
> sendv and notify exercised with a single test domain.
> Add infrastructure to access Argo: a 5-argument hypercall, number 39.
>
> Signed-off-by: Christopher Clark 
> Signed-off-by: Denis Mukhin 
>

Reviewed-by: Christopher Clark 
Tested-by: Christopher Clark 

Thanks for working to advance this - sorry for the slow response.

Christopher


> ---
> Original XTF argo test:
>
> https://github.com/dozylynx/meta-argo/blob/master/recipes-extended/xen/xt=
f/0001-Add-Argo-test.patch
> ---
>  docs/all-tests.dox      |   2 +
>  include/xen/argo.h      | 259 +++++++++++++++++++++++++++++
>  include/xtf/hypercall.h |   1 +
>  include/xtf/numbers.h   |   5 +
>  tests/argo/Makefile     |   9 +
>  tests/argo/main.c       | 353 ++++++++++++++++++++++++++++++++++++++++
>  6 files changed, 629 insertions(+)
>  create mode 100644 include/xen/argo.h
>  create mode 100644 tests/argo/Makefile
>  create mode 100644 tests/argo/main.c
>
> diff --git a/docs/all-tests.dox b/docs/all-tests.dox
> index 566762c..1a7b4b7 100644
> --- a/docs/all-tests.dox
> +++ b/docs/all-tests.dox
> @@ -178,6 +178,8 @@ states.
>
>  @section index-utility Utilities
>
> +@subpage test-argo - Argo functionality test
> +
>  @subpage test-cpuid - Print CPUID information.
>
>  @subpage test-fep - Test availability of HVM Forced Emulation Prefix.
> diff --git a/include/xen/argo.h b/include/xen/argo.h
> new file mode 100644
> index 0000000..5ae2def
> --- /dev/null
> +++ b/include/xen/argo.h
> @@ -0,0 +1,259 @@
>
> +/***********************************************************************=
*******
> + * Argo : Hypervisor-Mediated data eXchange
> + *
> + * Derived from v4v, the version 2 of v2v.
> + *
> + * Copyright (c) 2010, Citrix Systems
> + * Copyright (c) 2018-2019, BAE Systems
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining
> a copy
> + * of this software and associated documentation files (the "Software"),
> to
> + * deal in the Software without restriction, including without limitatio=
n
> the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense,
> and/or
> + * sell copies of the Software, and to permit persons to whom the
> Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
> SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + */
> +
> +#ifndef __XEN_PUBLIC_ARGO_H__
> +#define __XEN_PUBLIC_ARGO_H__
> +
> +#define XEN_ARGO_DOMID_ANY       DOMID_INVALID
> +
> +/* The maximum size of an Argo ring is defined to be: 16MB (0x1000000
> bytes). */
> +#define XEN_ARGO_MAX_RING_SIZE  (0x1000000ULL)
> +
> +/* Fixed-width type for "argo port" number. Nothing to do with evtchns. =
*/
> +typedef uint32_t xen_argo_port_t;
> +
> +/* gfn type: 64-bit fixed-width on all architectures */
> +typedef uint64_t xen_argo_gfn_t;
> +
> +/*
> + * XEN_ARGO_MAXIOV : maximum number of iovs accepted in a single sendv.
> + * Caution is required if this value is increased: this determines the
> size of
> + * an array of xen_argo_iov_t structs on the hypervisor stack, so could
> cause
> + * stack overflow if the value is too large.
> + * The Linux Argo driver never passes more than two iovs.
> +*/
> +#define XEN_ARGO_MAXIOV          8U
> +
> +typedef struct xen_argo_iov
> +{
> +    unsigned long iov_hnd;
> +    uint32_t iov_len;
> +    uint32_t pad;
> +} xen_argo_iov_t;
> +
> +typedef struct xen_argo_addr
> +{
> +    xen_argo_port_t aport;
> +    domid_t domain_id;
> +    uint16_t pad;
> +} xen_argo_addr_t;
> +
> +typedef struct xen_argo_send_addr
> +{
> +    struct xen_argo_addr src;
> +    struct xen_argo_addr dst;
> +} xen_argo_send_addr_t;
> +
> +typedef struct xen_argo_ring
> +{
> +    /* Guests should use atomic operations to access rx_ptr */
> +    uint32_t rx_ptr;
> +    /* Guests should use atomic operations to access tx_ptr */
> +    uint32_t tx_ptr;
> +    /*
> +     * Header space reserved for later use. Align the start of the ring
> to a
> +     * multiple of the message slot size.
> +     */
> +    uint8_t reserved[56];
> +    uint8_t ring[];
> +} xen_argo_ring_t;
> +
> +typedef struct xen_argo_register_ring
> +{
> +    xen_argo_port_t aport;
> +    domid_t partner_id;
> +    uint16_t pad;
> +    uint32_t len;
> +} xen_argo_register_ring_t;
> +
> +typedef struct xen_argo_unregister_ring
> +{
> +    xen_argo_port_t aport;
> +    domid_t partner_id;
> +    uint16_t pad;
> +} xen_argo_unregister_ring_t;
> +
> +/* Messages on the ring are padded to a multiple of this size. */
> +#define XEN_ARGO_MSG_SLOT_SIZE 0x10
> +
> +/*
> + * Notify flags
> + */
> +/* Ring exists */
> +#define XEN_ARGO_RING_EXISTS            (1U << 0)
> +/* Ring is shared, not unicast */
> +#define XEN_ARGO_RING_SHARED            (1U << 1)
> +/* Ring is empty */
> +#define XEN_ARGO_RING_EMPTY             (1U << 2)
> +/* Sufficient space to queue space_required bytes might exist */
> +#define XEN_ARGO_RING_SUFFICIENT        (1U << 3)
> +/* Insufficient ring size for space_required bytes */
> +#define XEN_ARGO_RING_EMSGSIZE          (1U << 4)
> +/* Too many domains waiting for available space signals for this ring */
> +#define XEN_ARGO_RING_EBUSY             (1U << 5)
> +
> +typedef struct xen_argo_ring_data_ent
> +{
> +    struct xen_argo_addr ring;
> +    uint16_t flags;
> +    uint16_t pad;
> +    uint32_t space_required;
> +    uint32_t max_message_size;
> +} xen_argo_ring_data_ent_t;
> +
> +typedef struct xen_argo_ring_data
> +{
> +    uint32_t nent;
> +    uint32_t pad;
> +
> +    /*
> +     * The Xen headers have:
> +     *   struct xen_argo_ring_data_ent data[];
> +     * here.  It's useful for the hypervisor side of the interface, but
> really
> +     * not for the client side.
> +     */
> +} xen_argo_ring_data_t;
> +
> +struct xen_argo_ring_message_header
> +{
> +    uint32_t len;
> +    struct xen_argo_addr source;
> +    uint32_t message_type;
> +    uint8_t data[];
> +};
> +
> +/*
> + * Hypercall operations
> + */
> +
> +/*
> + * XEN_ARGO_OP_register_ring
> + *
> + * Register a ring using the guest-supplied memory pages.
> + * Also used to reregister an existing ring (eg. after resume from
> hibernate).
> + *
> + * The first argument struct indicates the port number for the ring to
> register
> + * and the partner domain, if any, that is to be allowed to send to the
> ring.
> + * A wildcard (XEN_ARGO_DOMID_ANY) may be supplied instead of a partner
> domid,
> + * and if the hypervisor has wildcard sender rings enabled, this will
> allow
> + * any domain (XSM notwithstanding) to send to the ring.
> + *
> + * The second argument is an array of guest frame numbers and the third
> argument
> + * indicates the size of the array. This operation only supports 4K-size=
d
> pages.
> + *
> + * arg1: XEN_GUEST_HANDLE(xen_argo_register_ring_t)
> + * arg2: XEN_GUEST_HANDLE(xen_argo_gfn_t)
> + * arg3: unsigned long npages
> + * arg4: unsigned long flags (32-bit value)
> + */
> +#define XEN_ARGO_OP_register_ring     1
> +
> +/* Register op flags */
> +/*
> + * Fail exist:
> + * If set, reject attempts to (re)register an existing established ring.
> + * If clear, reregistration occurs if the ring exists, with the new ring
> + * taking the place of the old, preserving tx_ptr if it remains valid.
> + */
> +#define XEN_ARGO_REGISTER_FLAG_FAIL_EXIST  0x1
> +
> +#ifdef __XEN__
> +/* Mask for all defined flags. */
> +#define XEN_ARGO_REGISTER_FLAG_MASK XEN_ARGO_REGISTER_FLAG_FAIL_EXIST
> +#endif
> +
> +/*
> + * XEN_ARGO_OP_unregister_ring
> + *
> + * Unregister a previously-registered ring, ending communication.
> + *
> + * arg1: XEN_GUEST_HANDLE(xen_argo_unregister_ring_t)
> + * arg2: NULL
> + * arg3: 0 (ZERO)
> + * arg4: 0 (ZERO)
> + */
> +#define XEN_ARGO_OP_unregister_ring     2
> +
> +/*
> + * XEN_ARGO_OP_sendv
> + *
> + * Send a list of buffers contained in iovs.
> + *
> + * The send address struct specifies the source and destination addresse=
s
> + * for the message being sent, which are used to find the destination
> ring:
> + * Xen first looks for a most-specific match with a registered ring with
> + *  (id.addr =3D=3D dst) and (id.partner =3D=3D sending_domain) ;
> + * if that fails, it then looks for a wildcard match (aka multicast
> receiver)
> + * where (id.addr =3D=3D dst) and (id.partner =3D=3D DOMID_ANY).
> + *
> + * For each iov entry, send iov_len bytes from iov_base to the
> destination ring.
> + * If insufficient space exists in the destination ring, it will return
> -EAGAIN
> + * and Xen will notify the caller when sufficient space becomes availabl=
e.
> + *
> + * The message type is a 32-bit data field available to communicate
> message
> + * context data (eg. kernel-to-kernel, rather than application layer).
> + *
> + * arg1: XEN_GUEST_HANDLE(xen_argo_send_addr_t) source and dest addresse=
s
> + * arg2: XEN_GUEST_HANDLE(xen_argo_iov_t) iovs
> + * arg3: unsigned long niov
> + * arg4: unsigned long message type (32-bit value)
> + */
> +#define XEN_ARGO_OP_sendv               3
> +
> +/*
> + * XEN_ARGO_OP_notify
> + *
> + * Asks Xen for information about other rings in the system.
> + *
> + * ent->ring is the xen_argo_addr_t of the ring you want information on.
> + * Uses the same ring matching rules as XEN_ARGO_OP_sendv.
> + *
> + * ent->space_required : if this field is not null then Xen will check
> + * that there is space in the destination ring for this many bytes of
> payload.
> + * If the ring is too small for the requested space_required, it will se=
t
> the
> + * XEN_ARGO_RING_EMSGSIZE flag on return.
> + * If sufficient space is available, it will set XEN_ARGO_RING_SUFFICIEN=
T
> + * and CANCEL any pending notification for that ent->ring; otherwise it
> + * will schedule a notification event and the flag will not be set.
> + *
> + * These flags are set by Xen when notify replies:
> + * XEN_ARGO_RING_EXISTS     ring exists
> + * XEN_ARGO_RING_SHARED     ring is registered for wildcard partner
> + * XEN_ARGO_RING_EMPTY      ring is empty
> + * XEN_ARGO_RING_SUFFICIENT sufficient space for space_required is there
> + * XEN_ARGO_RING_EMSGSIZE   space_required is too large for the ring siz=
e
> + * XEN_ARGO_RING_EBUSY      too many domains waiting for available space
> signals
> + *
> + * arg1: XEN_GUEST_HANDLE(xen_argo_ring_data_t) ring_data (may be NULL)
> + * arg2: NULL
> + * arg3: 0 (ZERO)
> + * arg4: 0 (ZERO)
> + */
> +#define XEN_ARGO_OP_notify              4
> +
> +#endif
> diff --git a/include/xtf/hypercall.h b/include/xtf/hypercall.h
> index 0d33807..17975ba 100644
> --- a/include/xtf/hypercall.h
> +++ b/include/xtf/hypercall.h
> @@ -33,6 +33,7 @@
>  extern uint8_t hypercall_page[PAGE_SIZE];
>
>  /* All Xen ABI for includers convenience .*/
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/include/xtf/numbers.h b/include/xtf/numbers.h
> index f5c73b7..b0b2c1b 100644
> --- a/include/xtf/numbers.h
> +++ b/include/xtf/numbers.h
> @@ -52,6 +52,11 @@
>   */
>  #define _u(v) ((unsigned long)(v))
>
> +/**
> + * Round up a number to the next integer
> + */
> +#define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))
> +
>  #endif /* !__ASSEMBLY__ */
>  #endif /* XTF_NUMBERS_H */
>
> diff --git a/tests/argo/Makefile b/tests/argo/Makefile
> new file mode 100644
> index 0000000..c6b3113
> --- /dev/null
> +++ b/tests/argo/Makefile
> @@ -0,0 +1,9 @@
> +include $(ROOT)/build/common.mk
> +
> +NAME      :=3D argo
> +CATEGORY  :=3D in-development
> +TEST-ENVS :=3D $(ALL_ENVIRONMENTS)
> +
> +obj-perenv +=3D main.o
> +
> +include $(ROOT)/build/gen.mk
> diff --git a/tests/argo/main.c b/tests/argo/main.c
> new file mode 100644
> index 0000000..fa54aed
> --- /dev/null
> +++ b/tests/argo/main.c
> @@ -0,0 +1,353 @@
> +/**
> + * @file tests/argo/main.c
> + * @ref test-argo
> + *
> + * @page test-argo argo
> + *
> + * @todo Docs for test-argo
> + *
> + * @see tests/argo/main.c
> + */
> +#include 
> +
> +const char test_title[] =3D "Argo hypercall test";
> +
> +/*
> + * The current Linux Argo driver has a default ring size of 32 4k pages,
> + * so follow that for the test ring size.
> + */
> +static uint8_t ring_buffer[32 * PAGE_SIZE] __page_aligned_bss;
> +#define TEST_RING_NPAGES (sizeof(ring_buffer) / PAGE_SIZE)
> +
> +static int probe_for_argo(domid_t own_domid)
> +{
> +    /* Attempt an Argo call to register a ring with invalid arguments */
> +    xen_argo_register_ring_t reg =3D {
> +        .aport      =3D 1,
> +        .partner_id =3D own_domid,
> +        .len        =3D 1, /* A 1-byte ring is never allowed */
> +    };
> +    int rc =3D hypercall_argo_op(XEN_ARGO_OP_register_ring, ®, NULL, =
0,
> 0);
> +
> +    switch ( rc )
> +    {
> +    case -EINVAL: /* This is the response we are looking for */
> +        return 0;
> +
> +        /* All below here are test exit conditions */
> +    case -ENOSYS:
> +        xtf_skip("Skip: Argo support has not been enabled in this
> hypervisor\n");
> +        break;
> +    case -EOPNOTSUPP:
> +        xtf_skip("Skip: Argo is not enabled at runtime for this
> hypervisor\n");
> +        break;
> +    case -ENODEV:
> +        xtf_skip("Skip: Argo is not enabled for this domain\n");
> +        break;
> +
> +    case -EPERM:
> +        xtf_failure("Fail: ring registration by this domain is not
> permitted\n");
> +        break;
> +    case 0:
> +        xtf_failure("Fail: an invalid ring register op was not
> rejected\n");
> +        break;
> +    default:
> +        xtf_failure("Fail: unknown error %d for invalid ring
> registration\n", rc);
> +        break;
> +    }
> +
> +    return -1;
> +}
> +
> +/* notify: asks Xen for information about rings */
> +static int
> +test_notify_for_one_ring(domid_t query_domid, xen_argo_port_t query_port=
,
> +                         bool exists)
> +{
> +    struct {
> +        xen_argo_ring_data_t data;
> +        xen_argo_ring_data_ent_t ents[1];
> +    } notify =3D {
> +        .data =3D {
> +            .nent =3D ARRAY_SIZE(notify.ents),
> +        },
> +        .ents =3D {
> +            {
> +                .ring =3D {
> +                    .domain_id =3D query_domid,
> +                    .aport     =3D query_port,
> +                },
> +            },
> +        },
> +    };
> +    int rc =3D hypercall_argo_op(XEN_ARGO_OP_notify, ¬ify, NULL, 0, 0=
);
> +
> +    if ( rc )
> +    {
> +        xtf_failure("Fail: Unexpected error code %d in notify test\n",
> rc);
> +        return -1;
> +    }
> +
> +    if ( !exists )
> +    {
> +        /* No currently-defined flags should be set for a non-existent
> ring */
> +        if ( notify.ents[0].flags )
> +        {
> +            xtf_failure("Fail: Non-existent ring reported as existing\n"=
);
> +            return -1;
> +        }
> +    }
> +    else
> +    {
> +        if ( !(notify.ents[0].flags & XEN_ARGO_RING_EXISTS) )
> +        {
> +            xtf_failure("Fail: Ring not reported as existing\n");
> +            return -1;
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/* See the Argo Linux device driver for similar use of these macros */
> +#define XEN_ARGO_ROUNDUP(x) roundup((x), XEN_ARGO_MSG_SLOT_SIZE)
> +#define ARGO_RING_OVERHEAD 80
> +#define TEST_RING_SIZE(npages)                                      \
> +    (XEN_ARGO_ROUNDUP((((PAGE_SIZE)*npages) - ARGO_RING_OVERHEAD)))
> +
> +static int
> +test_register_ring(domid_t own_domid, xen_argo_port_t aport)
> +{
> +    unsigned int i;
> +    xen_argo_register_ring_t reg =3D {
> +        .aport      =3D aport,
> +        .partner_id =3D own_domid,
> +        .len        =3D TEST_RING_SIZE(TEST_RING_NPAGES),
> +    };
> +    xen_argo_gfn_t gfns[TEST_RING_NPAGES];
> +
> +    for ( i =3D 0; i < TEST_RING_NPAGES; i++ )
> +        gfns[i] =3D virt_to_gfn(ring_buffer + (i * PAGE_SIZE));
> +
> +    int rc =3D hypercall_argo_op(XEN_ARGO_OP_register_ring, ®, &gfns,
> +                               TEST_RING_NPAGES,
> XEN_ARGO_REGISTER_FLAG_FAIL_EXIST);
> +    switch ( rc )
> +    {
> +    case 0:
> +        return 0;
> +
> +    case -ENODEV:
> +        xtf_failure("Fail: Argo is not enabled for this domain\n");
> +        break;
> +    case -EFAULT:
> +        xtf_failure("Fail: Memory fault performing register ring test\n"=
);
> +        break;
> +    default:
> +        xtf_failure("Fail: Unexpected error code %d in register ring
> test\n", rc);
> +        break;
> +    }
> +    return -1;
> +}
> +
> +static int
> +test_unregister_ring(domid_t partner_domid, xen_argo_port_t aport,
> +                     bool exists)
> +{
> +    xen_argo_register_ring_t unreg =3D {
> +        .aport      =3D aport,
> +        .partner_id =3D partner_domid,
> +    };
> +    int rc =3D hypercall_argo_op(XEN_ARGO_OP_unregister_ring, &unreg, NU=
LL,
> 0, 0);
> +
> +    switch ( rc )
> +    {
> +    case 0:
> +        if ( exists )
> +            return 0;
> +        xtf_failure("Fail: unexpected success unregistering non-existent
> ring\n");
> +        return -1;
> +
> +    case -ENOENT:
> +        if ( !exists )
> +            return 0;
> +        xtf_failure("Fail: unexpected ring not found when unregistering
> \n");
> +        return -1;
> +
> +    default:
> +        xtf_failure("Fail: Unexpected error code %d in unregister ring
> test\n", rc);
> +        break;
> +    }
> +    return -1;
> +}
> +
> +static int
> +test_sendv(domid_t src_domid, xen_argo_port_t src_aport,
> +           domid_t dst_domid, xen_argo_port_t dst_aport,
> +           const char *msg_text, size_t msg_len, unsigned int msg_type)
> +{
> +    xen_argo_send_addr_t send_addr =3D {
> +        .src =3D {
> +            .domain_id =3D src_domid,
> +            .aport     =3D src_aport,
> +        },
> +        .dst =3D {
> +            .domain_id =3D dst_domid,
> +            .aport     =3D dst_aport,
> +        },
> +    };
> +    xen_argo_iov_t iovs[] =3D {
> +        {
> +            .iov_hnd =3D _u(msg_text),
> +            .iov_len =3D msg_len,
> +        },
> +    };
> +    int rc =3D hypercall_argo_op(XEN_ARGO_OP_sendv, &send_addr,
> +                               iovs, ARRAY_SIZE(iovs), msg_type);
> +
> +    if ( rc < 0 )
> +    {
> +        xtf_failure("Fail: Unexpected error code %d in sendv test\n", rc=
);
> +        return -1;
> +    }
> +
> +    if ( (size_t)rc !=3D msg_len )
> +    {
> +        xtf_failure("Fail: Unexpected message size %d written in sendv
> test\n", rc);
> +        return -1;
> +    }
> +
> +    return 0;
> +}
> +
> +static int
> +inspect_ring_after_first_single_sendv(domid_t src_domid,
> +                                      xen_argo_port_t src_aport,
> +                                      const char *sent_msg,
> +                                      unsigned int sent_msg_len,
> +                                      unsigned int sent_msg_type)
> +{
> +    int rc =3D 0;
> +    xen_argo_ring_t *ringp =3D (xen_argo_ring_t *)ring_buffer;
> +    struct xen_argo_ring_message_header *msg_hdr;
> +    unsigned int sent_length;
> +
> +    if ( ringp->rx_ptr !=3D 0 )
> +    {
> +        xtf_failure("Fail: receive pointer non-zero after sendv: %u\n",
> +                    ringp->rx_ptr);
> +        rc =3D -1;
> +    }
> +
> +    if ( ringp->tx_ptr !=3D XEN_ARGO_ROUNDUP(
> +             sizeof(struct xen_argo_ring_message_header) + sent_msg_len)=
 )
> +    {
> +        xtf_failure("Fail: transmit pointer incorrect after sendv: %u\n"=
,
> +                    ringp->rx_ptr);
> +        rc =3D -1;
> +    }
> +
> +    msg_hdr =3D (struct xen_argo_ring_message_header *)&(ringp->ring);
> +
> +    if ( msg_hdr->source.domain_id !=3D src_domid )
> +    {
> +        xtf_failure("Fail: source domain id incorrect: %u, expected %u\n=
",
> +                    msg_hdr->source.domain_id, src_domid);
> +        rc =3D -1;
> +    }
> +
> +    if ( msg_hdr->source.aport !=3D src_aport )
> +    {
> +        xtf_failure("Fail: source domain port incorrect: %u, expected
> %u\n",
> +                    msg_hdr->source.domain_id, src_aport);
> +        rc =3D -1;
> +    }
> +
> +    if ( msg_hdr->source.pad !=3D 0 )
> +    {
> +        xtf_failure("Fail: source padding incorrect: %u, expected zero\n=
",
> +                    msg_hdr->source.pad);
> +        rc =3D -1;
> +    }
> +
> +    if ( sent_msg_type !=3D msg_hdr->message_type )
> +    {
> +        xtf_failure("Fail: message type incorrect: %u sent, %u
> received\n",
> +                    sent_msg_type, msg_hdr->message_type);
> +        rc =3D -1;
> +    }
> +
> +    sent_length =3D sent_msg_len + sizeof(struct
> xen_argo_ring_message_header);
> +    if ( sent_length !=3D msg_hdr->len )
> +    {
> +        xtf_failure("Fail: received message length incorrect: "
> +                    "%u sent is %u with header added, %u received\n",
> +                    sent_msg_len, sent_length, msg_hdr->len);
> +        rc =3D -1;
> +    }
> +
> +    if ( strncmp((const char *)msg_hdr->data, sent_msg, sent_msg_len) )
> +    {
> +        xtf_failure("Fail: sent message got mangled\n");
> +        rc =3D -1;
> +    }
> +
> +    return rc;
> +}
> +
> +static void clear_test_ring(void)
> +{
> +    memset(ring_buffer, 0, sizeof(ring_buffer));
> +}
> +
> +void test_main(void)
> +{
> +    int own_domid;
> +    xen_argo_port_t test_aport =3D 1;
> +    const char simple_text[] =3D "a simple thing to send\n";
> +    const unsigned int msg_type =3D 0x12345678;
> +
> +    own_domid =3D xtf_get_domid();
> +    if ( own_domid < 0 )
> +        return xtf_error("Error: could not determine domid of the test
> domain\n");
> +
> +    /* First test validates for Argo availability to gate further testin=
g
> */
> +    if ( probe_for_argo(own_domid) )
> +        return;
> +
> +    if ( test_notify_for_one_ring(own_domid, test_aport, false) ||
> +         test_unregister_ring(own_domid, test_aport, false) )
> +        return;
> +
> +    clear_test_ring();
> +
> +    if ( test_register_ring(own_domid, test_aport) ||
> +         test_notify_for_one_ring(own_domid, test_aport, true) ||
> +         test_unregister_ring(own_domid, test_aport, true) ||
> +         test_notify_for_one_ring(own_domid, test_aport, false) ||
> +         test_unregister_ring(own_domid, test_aport, false) )
> +        return;
> +
> +    clear_test_ring();
> +
> +    if ( test_register_ring(own_domid, test_aport) ||
> +         test_sendv(own_domid, test_aport, own_domid, test_aport,
> +                    simple_text, strlen(simple_text), msg_type) ||
> +         inspect_ring_after_first_single_sendv(
> +             own_domid, test_aport, simple_text, strlen(simple_text),
> msg_type) ||
> +         test_notify_for_one_ring(own_domid, test_aport, true) ||
> +         test_unregister_ring(own_domid, test_aport, true) ||
> +         test_unregister_ring(own_domid, test_aport, false) )
> +        return;
> +
> +    xtf_success(NULL);
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> --
> 2.34.1
>
>
>

--000000000000d9d4c606364d3838
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    On Wed, May 21, 2025 at 10:18=E2=80=AFPM =
<dmkhn@proton.me> wrote:
    =

    From: Christopher Clark <christopher.w.clark@gmail.com>
    

    
From: Christopher Clark <    christopher.w.clark@gmail.com>
    

    
Simple test cases for the four Argo operations, register, unregister,
    
sendv and notify exercised with a single test domain.
    
Add infrastructure to access Argo: a 5-argument hypercall, number 39.
    

    
Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com><=
br>
Signed-off-by: Denis Mukhin <dmukhin@ford.com>

    Re=
viewed-by: Christopher Clark <christopher.w.clark@gmail.com>
    Tested-by: Christopher Clar=
k <christopher.w.clark@=
gmail.com>

    Thanks for working to advance this - sorry for the=
 slow response.

    Christopher
    =C2=A0
    
---
    
Original XTF argo test:
    
=C2=A0 https://github.com/dozylynx/meta-argo/blob/master/recipes-extended/xe=
n/xtf/0001-Add-Argo-test.patch
    
---
    
=C2=A0docs/all-tests.dox=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A02 +
    
=C2=A0include/xen/argo.h=C2=A0 =C2=A0 =C2=A0 | 259 ++++++++++++++++++++++++=
+++++
    
=C2=A0include/xtf/hypercall.h |=C2=A0 =C2=A01 +
    
=C2=A0include/xtf/numbers.h=C2=A0 =C2=A0|=C2=A0 =C2=A05 +
    
=C2=A0tests/argo/Makefile=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A09 +
    
=C2=A0tests/argo/main.c=C2=A0 =C2=A0 =C2=A0 =C2=A0| 353 +++++++++++++++++++=
+++++++++++++++++++++
    
=C2=A06 files changed, 629 insertions(+)
    
=C2=A0create mode 100644 include/xen/argo.h
    
=C2=A0create mode 100644 tests/argo/Makefile
    
=C2=A0create mode 100644 tests/argo/main.c
    

    
diff --git a/docs/all-tests.dox b/docs/all-tests.dox
    
index 566762c..1a7b4b7 100644
    
--- a/docs/all-tests.dox
    
+++ b/docs/all-tests.dox
    
@@ -178,6 +178,8 @@ states.
    

    
=C2=A0@section index-utility Utilities
    

    
+@subpage test-argo - Argo functionality test
    
+
    
=C2=A0@subpage test-cpuid - Print CPUID information.
    

    
=C2=A0@subpage test-fep - Test availability of HVM Forced Emulation Prefix.=

    
diff --git a/include/xen/argo.h b/include/xen/argo.h
    
new file mode 100644
    
index 0000000..5ae2def
    
--- /dev/null
    
+++ b/include/xen/argo.h
    
@@ -0,0 +1,259 @@
    
+/*************************************************************************=
*****
    
+ * Argo : Hypervisor-Mediated data eXchange
    
+ *
    
+ * Derived from v4v, the version 2 of v2v.
    
+ *
    
+ * Copyright (c) 2010, Citrix Systems
    
+ * Copyright (c) 2018-2019, BAE Systems
    
+ *
    
+ * Permission is hereby granted, free of charge, to any person obtaining a=
 copy
    
+ * of this software and associated documentation files (the "Software=
"), to
    
+ * deal in the Software without restriction, including without limitation =
the
    
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, an=
d/or
    
+ * sell copies of the Software, and to permit persons to whom the Software=
 is
    
+ * furnished to do so, subject to the following conditions:
    
+ *
    
+ * The above copyright notice and this permission notice shall be included=
 in
    
+ * all copies or substantial portions of the Software.
    
+ *
    
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIN=
D, EXPRESS OR
    
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY=
,
    
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL=
 THE
    
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER<=
br>
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING=

    
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
    
+ * DEALINGS IN THE SOFTWARE.
    
+ *
    
+ */
    
+
    
+#ifndef __XEN_PUBLIC_ARGO_H__
    
+#define __XEN_PUBLIC_ARGO_H__
    
+
    
+#define XEN_ARGO_DOMID_ANY=C2=A0 =C2=A0 =C2=A0 =C2=A0DOMID_INVALID
    
+
    
+/* The maximum size of an Argo ring is defined to be: 16MB (0x1000000 byte=
s). */
    
+#define XEN_ARGO_MAX_RING_SIZE=C2=A0 (0x1000000ULL)
    
+
    
+/* Fixed-width type for "argo port" number. Nothing to do with e=
vtchns. */
    
+typedef uint32_t xen_argo_port_t;
    
+
    
+/* gfn type: 64-bit fixed-width on all architectures */
    
+typedef uint64_t xen_argo_gfn_t;
    
+
    
+/*
    
+ * XEN_ARGO_MAXIOV : maximum number of iovs accepted in a single sendv.
+ * Caution is required if this value is increased: this determines the siz=
e of
    
+ * an array of xen_argo_iov_t structs on the hypervisor stack, so could ca=
use
    
+ * stack overflow if the value is too large.
    
+ * The Linux Argo driver never passes more than two iovs.
    
+*/
    
+#define XEN_ARGO_MAXIOV=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8U
    
+
    
+typedef struct xen_argo_iov
    
+{
    
+=C2=A0 =C2=A0 unsigned long iov_hnd;
    
+=C2=A0 =C2=A0 uint32_t iov_len;
    
+=C2=A0 =C2=A0 uint32_t pad;
    
+} xen_argo_iov_t;
    
+
    
+typedef struct xen_argo_addr
    
+{
    
+=C2=A0 =C2=A0 xen_argo_port_t aport;
    
+=C2=A0 =C2=A0 domid_t domain_id;
    
+=C2=A0 =C2=A0 uint16_t pad;
    
+} xen_argo_addr_t;
    
+
    
+typedef struct xen_argo_send_addr
    
+{
    
+=C2=A0 =C2=A0 struct xen_argo_addr src;
    
+=C2=A0 =C2=A0 struct xen_argo_addr dst;
    
+} xen_argo_send_addr_t;
    
+
    
+typedef struct xen_argo_ring
    
+{
    
+=C2=A0 =C2=A0 /* Guests should use atomic operations to access rx_ptr */
+=C2=A0 =C2=A0 uint32_t rx_ptr;
    
+=C2=A0 =C2=A0 /* Guests should use atomic operations to access tx_ptr */
+=C2=A0 =C2=A0 uint32_t tx_ptr;
    
+=C2=A0 =C2=A0 /*
    
+=C2=A0 =C2=A0 =C2=A0* Header space reserved for later use. Align the start=
 of the ring to a
    
+=C2=A0 =C2=A0 =C2=A0* multiple of the message slot size.
    
+=C2=A0 =C2=A0 =C2=A0*/
    
+=C2=A0 =C2=A0 uint8_t reserved[56];
    
+=C2=A0 =C2=A0 uint8_t ring[];
    
+} xen_argo_ring_t;
    
+
    
+typedef struct xen_argo_register_ring
    
+{
    
+=C2=A0 =C2=A0 xen_argo_port_t aport;
    
+=C2=A0 =C2=A0 domid_t partner_id;
    
+=C2=A0 =C2=A0 uint16_t pad;
    
+=C2=A0 =C2=A0 uint32_t len;
    
+} xen_argo_register_ring_t;
    
+
    
+typedef struct xen_argo_unregister_ring
    
+{
    
+=C2=A0 =C2=A0 xen_argo_port_t aport;
    
+=C2=A0 =C2=A0 domid_t partner_id;
    
+=C2=A0 =C2=A0 uint16_t pad;
    
+} xen_argo_unregister_ring_t;
    
+
    
+/* Messages on the ring are padded to a multiple of this size. */
    
+#define XEN_ARGO_MSG_SLOT_SIZE 0x10
    
+
    
+/*
    
+ * Notify flags
    
+ */
    
+/* Ring exists */
    
+#define XEN_ARGO_RING_EXISTS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (1U =
<< 0)
    
+/* Ring is shared, not unicast */
    
+#define XEN_ARGO_RING_SHARED=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (1U =
<< 1)
    
+/* Ring is empty */
    
+#define XEN_ARGO_RING_EMPTY=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0(1U << 2)
    
+/* Sufficient space to queue space_required bytes might exist */
    
+#define XEN_ARGO_RING_SUFFICIENT=C2=A0 =C2=A0 =C2=A0 =C2=A0 (1U << 3=
)
    
+/* Insufficient ring size for space_required bytes */
    
+#define XEN_ARGO_RING_EMSGSIZE=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (1U <&=
lt; 4)
    
+/* Too many domains waiting for available space signals for this ring */
+#define XEN_ARGO_RING_EBUSY=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0(1U << 5)
    
+
    
+typedef struct xen_argo_ring_data_ent
    
+{
    
+=C2=A0 =C2=A0 struct xen_argo_addr ring;
    
+=C2=A0 =C2=A0 uint16_t flags;
    
+=C2=A0 =C2=A0 uint16_t pad;
    
+=C2=A0 =C2=A0 uint32_t space_required;
    
+=C2=A0 =C2=A0 uint32_t max_message_size;
    
+} xen_argo_ring_data_ent_t;
    
+
    
+typedef struct xen_argo_ring_data
    
+{
    
+=C2=A0 =C2=A0 uint32_t nent;
    
+=C2=A0 =C2=A0 uint32_t pad;
    
+
    
+=C2=A0 =C2=A0 /*
    
+=C2=A0 =C2=A0 =C2=A0* The Xen headers have:
    
+=C2=A0 =C2=A0 =C2=A0*=C2=A0 =C2=A0struct xen_argo_ring_data_ent data[];
+=C2=A0 =C2=A0 =C2=A0* here.=C2=A0 It's useful for the hypervisor side =
of the interface, but really
    
+=C2=A0 =C2=A0 =C2=A0* not for the client side.
    
+=C2=A0 =C2=A0 =C2=A0*/
    
+} xen_argo_ring_data_t;
    
+
    
+struct xen_argo_ring_message_header
    
+{
    
+=C2=A0 =C2=A0 uint32_t len;
    
+=C2=A0 =C2=A0 struct xen_argo_addr source;
    
+=C2=A0 =C2=A0 uint32_t message_type;
    
+=C2=A0 =C2=A0 uint8_t data[];
    
+};
    
+
    
+/*
    
+ * Hypercall operations
    
+ */
    
+
    
+/*
    
+ * XEN_ARGO_OP_register_ring
    
+ *
    
+ * Register a ring using the guest-supplied memory pages.
    
+ * Also used to reregister an existing ring (eg. after resume from hiberna=
te).
    
+ *
    
+ * The first argument struct indicates the port number for the ring to reg=
ister
    
+ * and the partner domain, if any, that is to be allowed to send to the ri=
ng.
    
+ * A wildcard (XEN_ARGO_DOMID_ANY) may be supplied instead of a partner do=
mid,
    
+ * and if the hypervisor has wildcard sender rings enabled, this will allo=
w
    
+ * any domain (XSM notwithstanding) to send to the ring.
    
+ *
    
+ * The second argument is an array of guest frame numbers and the third ar=
gument
    
+ * indicates the size of the array. This operation only supports 4K-sized =
pages.
    
+ *
    
+ * arg1: XEN_GUEST_HANDLE(xen_argo_register_ring_t)
    
+ * arg2: XEN_GUEST_HANDLE(xen_argo_gfn_t)
    
+ * arg3: unsigned long npages
    
+ * arg4: unsigned long flags (32-bit value)
    
+ */
    
+#define XEN_ARGO_OP_register_ring=C2=A0 =C2=A0 =C2=A01
    
+
    
+/* Register op flags */
    
+/*
    
+ * Fail exist:
    
+ * If set, reject attempts to (re)register an existing established ring.
+ * If clear, reregistration occurs if the ring exists, with the new ring
+ * taking the place of the old, preserving tx_ptr if it remains valid.
    
+ */
    
+#define XEN_ARGO_REGISTER_FLAG_FAIL_EXIST=C2=A0 0x1
    
+
    
+#ifdef __XEN__
    
+/* Mask for all defined flags. */
    
+#define XEN_ARGO_REGISTER_FLAG_MASK XEN_ARGO_REGISTER_FLAG_FAIL_EXIST
    
+#endif
    
+
    
+/*
    
+ * XEN_ARGO_OP_unregister_ring
    
+ *
    
+ * Unregister a previously-registered ring, ending communication.
    
+ *
    
+ * arg1: XEN_GUEST_HANDLE(xen_argo_unregister_ring_t)
    
+ * arg2: NULL
    
+ * arg3: 0 (ZERO)
    
+ * arg4: 0 (ZERO)
    
+ */
    
+#define XEN_ARGO_OP_unregister_ring=C2=A0 =C2=A0 =C2=A02
    
+
    
+/*
    
+ * XEN_ARGO_OP_sendv
    
+ *
    
+ * Send a list of buffers contained in iovs.
    
+ *
    
+ * The send address struct specifies the source and destination addresses<=
br>
+ * for the message being sent, which are used to find the destination ring=
:
    
+ * Xen first looks for a most-specific match with a registered ring with
+ *=C2=A0 (id.addr =3D=3D dst) and (id.partner =3D=3D sending_domain) ;
    
+ * if that fails, it then looks for a wildcard match (aka multicast receiv=
er)
    
+ * where (id.addr =3D=3D dst) and (id.partner =3D=3D DOMID_ANY).
    
+ *
    
+ * For each iov entry, send iov_len bytes from iov_base to the destination=
 ring.
    
+ * If insufficient space exists in the destination ring, it will return -E=
AGAIN
    
+ * and Xen will notify the caller when sufficient space becomes available.=

    
+ *
    
+ * The message type is a 32-bit data field available to communicate messag=
e
    
+ * context data (eg. kernel-to-kernel, rather than application layer).
    
+ *
    
+ * arg1: XEN_GUEST_HANDLE(xen_argo_send_addr_t) source and dest addresses<=
br>
+ * arg2: XEN_GUEST_HANDLE(xen_argo_iov_t) iovs
    
+ * arg3: unsigned long niov
    
+ * arg4: unsigned long message type (32-bit value)
    
+ */
    
+#define XEN_ARGO_OP_sendv=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A03
    
+
    
+/*
    
+ * XEN_ARGO_OP_notify
    
+ *
    
+ * Asks Xen for information about other rings in the system.
    
+ *
    
+ * ent->ring is the xen_argo_addr_t of the ring you want information on=
.
    
+ * Uses the same ring matching rules as XEN_ARGO_OP_sendv.
    
+ *
    
+ * ent->space_required : if this field is not null then Xen will check<=
br>
+ * that there is space in the destination ring for this many bytes of payl=
oad.
    
+ * If the ring is too small for the requested space_required, it will set =
the
    
+ * XEN_ARGO_RING_EMSGSIZE flag on return.
    
+ * If sufficient space is available, it will set XEN_ARGO_RING_SUFFICIENT<=
br>
+ * and CANCEL any pending notification for that ent->ring; otherwise it=

    
+ * will schedule a notification event and the flag will not be set.
    
+ *
    
+ * These flags are set by Xen when notify replies:
    
+ * XEN_ARGO_RING_EXISTS=C2=A0 =C2=A0 =C2=A0ring exists
    
+ * XEN_ARGO_RING_SHARED=C2=A0 =C2=A0 =C2=A0ring is registered for wildcard=
 partner
    
+ * XEN_ARGO_RING_EMPTY=C2=A0 =C2=A0 =C2=A0 ring is empty
    
+ * XEN_ARGO_RING_SUFFICIENT sufficient space for space_required is there
+ * XEN_ARGO_RING_EMSGSIZE=C2=A0 =C2=A0space_required is too large for the =
ring size
    
+ * XEN_ARGO_RING_EBUSY=C2=A0 =C2=A0 =C2=A0 too many domains waiting for av=
ailable space signals
    
+ *
    
+ * arg1: XEN_GUEST_HANDLE(xen_argo_ring_data_t) ring_data (may be NULL)
+ * arg2: NULL
    
+ * arg3: 0 (ZERO)
    
+ * arg4: 0 (ZERO)
    
+ */
    
+#define XEN_ARGO_OP_notify=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 4
    
+
    
+#endif
    
diff --git a/include/xtf/hypercall.h b/include/xtf/hypercall.h
    
index 0d33807..17975ba 100644
    
--- a/include/xtf/hypercall.h
    
+++ b/include/xtf/hypercall.h
    
@@ -33,6 +33,7 @@
    
=C2=A0extern uint8_t hypercall_page[PAGE_SIZE];
    

    
=C2=A0/* All Xen ABI for includers convenience .*/
    
+#include <xen/argo.h>
    
=C2=A0#include <xen/callback.h>
    
=C2=A0#include <xen/elfnote.h>
    
=C2=A0#include <xen/errno.h>
    
diff --git a/include/xtf/numbers.h b/include/xtf/numbers.h
    
index f5c73b7..b0b2c1b 100644
    
--- a/include/xtf/numbers.h
    
+++ b/include/xtf/numbers.h
    
@@ -52,6 +52,11 @@
    
=C2=A0 */
    
=C2=A0#define _u(v) ((unsigned long)(v))
    

    
+/**
    
+ * Round up a number to the next integer
    
+ */
    
+#define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))
    
+
    
=C2=A0#endif /* !__ASSEMBLY__ */
    
=C2=A0#endif /* XTF_NUMBERS_H */
    

    
diff --git a/tests/argo/Makefile b/tests/argo/Makefile
    
new file mode 100644
    
index 0000000..c6b3113
    
--- /dev/null
    
+++ b/tests/argo/Makefile
    
@@ -0,0 +1,9 @@
    
+include $(ROOT)/build/common.mk
    
+
    
+NAME=C2=A0 =C2=A0 =C2=A0 :=3D argo
    
+CATEGORY=C2=A0 :=3D in-development
    
+TEST-ENVS :=3D $(ALL_ENVIRONMENTS)
    
+
    
+obj-perenv +=3D main.o
    
+
    
+include $(ROOT)/build/gen.mk
    
diff --git a/tests/argo/main.c b/tests/argo/main.c
    
new file mode 100644
    
index 0000000..fa54aed
    
--- /dev/null
    
+++ b/tests/argo/main.c
    
@@ -0,0 +1,353 @@
    
+/**
    
+ * @file tests/argo/main.c
    
+ * @ref test-argo
    
+ *
    
+ * @page test-argo argo
    
+ *
    
+ * @todo Docs for test-argo
    
+ *
    
+ * @see tests/argo/main.c
    
+ */
    
+#include <xtf.h>
    
+
    
+const char test_title[] =3D "Argo hypercall test";
    
+
    
+/*
    
+ * The current Linux Argo driver has a default ring size of 32 4k pages,
+ * so follow that for the test ring size.
    
+ */
    
+static uint8_t ring_buffer[32 * PAGE_SIZE] __page_aligned_bss;
    
+#define TEST_RING_NPAGES (sizeof(ring_buffer) / PAGE_SIZE)
    
+
    
+static int probe_for_argo(domid_t own_domid)
    
+{
    
+=C2=A0 =C2=A0 /* Attempt an Argo call to register a ring with invalid argu=
ments */
    
+=C2=A0 =C2=A0 xen_argo_register_ring_t reg =3D {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .aport=C2=A0 =C2=A0 =C2=A0 =3D 1,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .partner_id =3D own_domid,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .len=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 1, /* A 1-=
byte ring is never allowed */
    
+=C2=A0 =C2=A0 };
    
+=C2=A0 =C2=A0 int rc =3D hypercall_argo_op(XEN_ARGO_OP_register_ring, &=
;reg, NULL, 0, 0);
    
+
    
+=C2=A0 =C2=A0 switch ( rc )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 case -EINVAL: /* This is the response we are looking for */<=
br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;
    
+
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* All below here are test exit conditions */<=
br>
+=C2=A0 =C2=A0 case -ENOSYS:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_skip("Skip: Argo support has not been=
 enabled in this hypervisor\n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
    
+=C2=A0 =C2=A0 case -EOPNOTSUPP:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_skip("Skip: Argo is not enabled at ru=
ntime for this hypervisor\n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
    
+=C2=A0 =C2=A0 case -ENODEV:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_skip("Skip: Argo is not enabled for t=
his domain\n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
    
+
    
+=C2=A0 =C2=A0 case -EPERM:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: ring registration by t=
his domain is not permitted\n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
    
+=C2=A0 =C2=A0 case 0:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: an invalid ring regist=
er op was not rejected\n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
    
+=C2=A0 =C2=A0 default:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: unknown error %d for i=
nvalid ring registration\n", rc);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 return -1;
    
+}
    
+
    
+/* notify: asks Xen for information about rings */
    
+static int
    
+test_notify_for_one_ring(domid_t query_domid, xen_argo_port_t query_port,<=
br>
+=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=A0bool exists)
    
+{
    
+=C2=A0 =C2=A0 struct {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xen_argo_ring_data_t data;
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xen_argo_ring_data_ent_t ents[1];
    
+=C2=A0 =C2=A0 } notify =3D {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .data =3D {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .nent =3D ARRAY_SIZE(notify.ents=
),
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .ents =3D {
    
+=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 .ring =3D {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .dom=
ain_id =3D query_domid,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .apo=
rt=C2=A0 =C2=A0 =C2=A0=3D query_port,
    
+=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 =C2=A0 int rc =3D hypercall_argo_op(XEN_ARGO_OP_notify, &notify=
, NULL, 0, 0);
    
+
    
+=C2=A0 =C2=A0 if ( rc )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: Unexpected error code =
%d in notify test\n", rc);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return -1;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 if ( !exists )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* No currently-defined flags should be set fo=
r a non-existent ring */
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( notify.ents[0].flags )
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: Non-exis=
tent ring reported as existing\n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -1;
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
    
+=C2=A0 =C2=A0 }
    
+=C2=A0 =C2=A0 else
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( !(notify.ents[0].flags & XEN_ARGO_RIN=
G_EXISTS) )
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: Ring not=
 reported as existing\n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -1;
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 return 0;
    
+}
    
+
    
+/* See the Argo Linux device driver for similar use of these macros */
    
+#define XEN_ARGO_ROUNDUP(x) roundup((x), XEN_ARGO_MSG_SLOT_SIZE)
    
+#define ARGO_RING_OVERHEAD 80
    
+#define TEST_RING_SIZE(npages)=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 (XEN_ARGO_ROUNDUP((((PAGE_SIZE)*npages) - ARGO_RING_OVERHEAD=
)))
    
+
    
+static int
    
+test_register_ring(domid_t own_domid, xen_argo_port_t aport)
    
+{
    
+=C2=A0 =C2=A0 unsigned int i;
    
+=C2=A0 =C2=A0 xen_argo_register_ring_t reg =3D {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .aport=C2=A0 =C2=A0 =C2=A0 =3D aport,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .partner_id =3D own_domid,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .len=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D TEST_RING_=
SIZE(TEST_RING_NPAGES),
    
+=C2=A0 =C2=A0 };
    
+=C2=A0 =C2=A0 xen_argo_gfn_t gfns[TEST_RING_NPAGES];
    
+
    
+=C2=A0 =C2=A0 for ( i =3D 0; i < TEST_RING_NPAGES; i++ )
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 gfns[i] =3D virt_to_gfn(ring_buffer + (i * PAG=
E_SIZE));
    
+
    
+=C2=A0 =C2=A0 int rc =3D hypercall_argo_op(XEN_ARGO_OP_register_ring, &=
;reg, &gfns,
    
+=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=A0TEST_RING_NPAGES, XEN_ARGO_REGISTER_F=
LAG_FAIL_EXIST);
    
+=C2=A0 =C2=A0 switch ( rc )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 case 0:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;
    
+
    
+=C2=A0 =C2=A0 case -ENODEV:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: Argo is not enabled fo=
r this domain\n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
    
+=C2=A0 =C2=A0 case -EFAULT:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: Memory fault performin=
g register ring test\n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
    
+=C2=A0 =C2=A0 default:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: Unexpected error code =
%d in register ring test\n", rc);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
    
+=C2=A0 =C2=A0 }
    
+=C2=A0 =C2=A0 return -1;
    
+}
    
+
    
+static int
    
+test_unregister_ring(domid_t partner_domid, xen_argo_port_t aport,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0bool exists)
    
+{
    
+=C2=A0 =C2=A0 xen_argo_register_ring_t unreg =3D {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .aport=C2=A0 =C2=A0 =C2=A0 =3D aport,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .partner_id =3D partner_domid,
    
+=C2=A0 =C2=A0 };
    
+=C2=A0 =C2=A0 int rc =3D hypercall_argo_op(XEN_ARGO_OP_unregister_ring, &a=
mp;unreg, NULL, 0, 0);
    
+
    
+=C2=A0 =C2=A0 switch ( rc )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 case 0:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( exists )
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: unexpected success unr=
egistering non-existent ring\n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return -1;
    
+
    
+=C2=A0 =C2=A0 case -ENOENT:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( !exists )
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: unexpected ring not fo=
und when unregistering \n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return -1;
    
+
    
+=C2=A0 =C2=A0 default:
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: Unexpected error code =
%d in unregister ring test\n", rc);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
    
+=C2=A0 =C2=A0 }
    
+=C2=A0 =C2=A0 return -1;
    
+}
    
+
    
+static int
    
+test_sendv(domid_t src_domid, xen_argo_port_t src_aport,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0domid_t dst_domid, xen_argo_port_=
t dst_aport,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0const char *msg_text, size_t msg_=
len, unsigned int msg_type)
    
+{
    
+=C2=A0 =C2=A0 xen_argo_send_addr_t send_addr =3D {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .src =3D {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .domain_id =3D src_domid,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .aport=C2=A0 =C2=A0 =C2=A0=3D sr=
c_aport,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 .dst =3D {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .domain_id =3D dst_domid,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .aport=C2=A0 =C2=A0 =C2=A0=3D ds=
t_aport,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
    
+=C2=A0 =C2=A0 };
    
+=C2=A0 =C2=A0 xen_argo_iov_t iovs[] =3D {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .iov_hnd =3D _u(msg_text),
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .iov_len =3D msg_len,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
    
+=C2=A0 =C2=A0 };
    
+=C2=A0 =C2=A0 int rc =3D hypercall_argo_op(XEN_ARGO_OP_sendv, &send_ad=
dr,
    
+=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=A0iovs, ARRAY_SIZE(iovs), msg_type);
+
    
+=C2=A0 =C2=A0 if ( rc < 0 )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: Unexpected error code =
%d in sendv test\n", rc);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return -1;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 if ( (size_t)rc !=3D msg_len )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: Unexpected message siz=
e %d written in sendv test\n", rc);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return -1;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 return 0;
    
+}
    
+
    
+static int
    
+inspect_ring_after_first_single_sendv(domid_t src_domid,
    
+=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 xen_argo_port_t=
 src_aport,
    
+=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 const char *sen=
t_msg,
    
+=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 unsigned int se=
nt_msg_len,
    
+=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 unsigned int se=
nt_msg_type)
    
+{
    
+=C2=A0 =C2=A0 int rc =3D 0;
    
+=C2=A0 =C2=A0 xen_argo_ring_t *ringp =3D (xen_argo_ring_t *)ring_buffer;
+=C2=A0 =C2=A0 struct xen_argo_ring_message_header *msg_hdr;
    
+=C2=A0 =C2=A0 unsigned int sent_length;
    
+
    
+=C2=A0 =C2=A0 if ( ringp->rx_ptr !=3D 0 )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: receive pointer non-ze=
ro after sendv: %u\n",
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ring=
p->rx_ptr);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D -1;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 if ( ringp->tx_ptr !=3D XEN_ARGO_ROUNDUP(
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sizeof(struct xen_argo_rin=
g_message_header) + sent_msg_len) )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: transmit pointer incor=
rect after sendv: %u\n",
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ring=
p->rx_ptr);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D -1;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 msg_hdr =3D (struct xen_argo_ring_message_header *)&(rin=
gp->ring);
    
+
    
+=C2=A0 =C2=A0 if ( msg_hdr->source.domain_id !=3D src_domid )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: source domain id incor=
rect: %u, expected %u\n",
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 msg_=
hdr->source.domain_id, src_domid);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D -1;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 if ( msg_hdr->source.aport !=3D src_aport )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: source domain port inc=
orrect: %u, expected %u\n",
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 msg_=
hdr->source.domain_id, src_aport);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D -1;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 if ( msg_hdr->source.pad !=3D 0 )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: source padding incorre=
ct: %u, expected zero\n",
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 msg_=
hdr->source.pad);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D -1;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 if ( sent_msg_type !=3D msg_hdr->message_type )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: message type incorrect=
: %u sent, %u received\n",
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sent=
_msg_type, msg_hdr->message_type);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D -1;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 sent_length =3D sent_msg_len + sizeof(struct xen_argo_ring_m=
essage_header);
    
+=C2=A0 =C2=A0 if ( sent_length !=3D msg_hdr->len )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: received message lengt=
h incorrect: "
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &quo=
t;%u sent is %u with header added, %u received\n",
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sent=
_msg_len, sent_length, msg_hdr->len);
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D -1;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 if ( strncmp((const char *)msg_hdr->data, sent_msg, sent_=
msg_len) )
    
+=C2=A0 =C2=A0 {
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 xtf_failure("Fail: sent message got mangl=
ed\n");
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D -1;
    
+=C2=A0 =C2=A0 }
    
+
    
+=C2=A0 =C2=A0 return rc;
    
+}
    
+
    
+static void clear_test_ring(void)
    
+{
    
+=C2=A0 =C2=A0 memset(ring_buffer, 0, sizeof(ring_buffer));
    
+}
    
+
    
+void test_main(void)
    
+{
    
+=C2=A0 =C2=A0 int own_domid;
    
+=C2=A0 =C2=A0 xen_argo_port_t test_aport =3D 1;
    
+=C2=A0 =C2=A0 const char simple_text[] =3D "a simple thing to send\n&=
quot;;
    
+=C2=A0 =C2=A0 const unsigned int msg_type =3D 0x12345678;
    
+
    
+=C2=A0 =C2=A0 own_domid =3D xtf_get_domid();
    
+=C2=A0 =C2=A0 if ( own_domid < 0 )
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return xtf_error("Error: could not determ=
ine domid of the test domain\n");
    
+
    
+=C2=A0 =C2=A0 /* First test validates for Argo availability to gate furthe=
r testing */
    
+=C2=A0 =C2=A0 if ( probe_for_argo(own_domid) )
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
    
+
    
+=C2=A0 =C2=A0 if ( test_notify_for_one_ring(own_domid, test_aport, false) =
||
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0test_unregister_ring(own_domid, test_apo=
rt, false) )
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
    
+
    
+=C2=A0 =C2=A0 clear_test_ring();
    
+
    
+=C2=A0 =C2=A0 if ( test_register_ring(own_domid, test_aport) ||
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0test_notify_for_one_ring(own_domid, test=
_aport, true) ||
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0test_unregister_ring(own_domid, test_apo=
rt, true) ||
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0test_notify_for_one_ring(own_domid, test=
_aport, false) ||
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0test_unregister_ring(own_domid, test_apo=
rt, false) )
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
    
+
    
+=C2=A0 =C2=A0 clear_test_ring();
    
+
    
+=C2=A0 =C2=A0 if ( test_register_ring(own_domid, test_aport) ||
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0test_sendv(own_domid, test_aport, own_do=
mid, test_aport,
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 simp=
le_text, strlen(simple_text), msg_type) ||
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inspect_ring_after_first_single_sendv(
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0own_domid, test_aport, sim=
ple_text, strlen(simple_text), msg_type) ||
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0test_notify_for_one_ring(own_domid, test=
_aport, true) ||
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0test_unregister_ring(own_domid, test_apo=
rt, true) ||
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0test_unregister_ring(own_domid, test_apo=
rt, false) )
    
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
    
+
    
+=C2=A0 =C2=A0 xtf_success(NULL);
    
+}
    
+
    
+/*
    
+ * Local variables:
    
+ * mode: C
    
+ * c-file-style: "BSD"
    
+ * c-basic-offset: 4
    
+ * tab-width: 4
    
+ * indent-tabs-mode: nil
    
+ * End:
    
+ */
    
-- 
    
2.34.1
    

    

    

    

--000000000000d9d4c606364d3838--


From xen-devel-bounces@lists.xenproject.org Thu May 29 22:41:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 22:41:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000227.1380565 (Exim 4.92)
	(envelope-from )
	id 1uKlvl-0001vC-0Z; Thu, 29 May 2025 22:40:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000227.1380565; Thu, 29 May 2025 22: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 1uKlvk-0001v5-UA; Thu, 29 May 2025 22:40:56 +0000
Received: by outflank-mailman (input) for mailman id 1000227;
 Thu, 29 May 2025 22:40:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKlvk-0001uz-8u
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 22:40:56 +0000
Received: from mail137-30.atl71.mandrillapp.com
 (mail137-30.atl71.mandrillapp.com [198.2.137.30])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f77efc91-3cdd-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 00:40:49 +0200 (CEST)
Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail137-30.atl71.mandrillapp.com (Mailchimp) with ESMTP id
 4b7hCz75fPzMQxc7s
 for ; Thu, 29 May 2025 22:40:47 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 f5d62f09982d4a5090cf9d96bbfa4bae; Thu, 29 May 2025 22:40: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" 
X-Inumbo-ID: f77efc91-3cdd-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1748558448; x=1748828448;
	bh=Y53hueVrFDexdKiEqYRowA2tjeyA5Izf+Dp0bUmOPKk=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=nKHLE82LdqKY75Z8gKUJtJXHuGXQLNf5db0Gdi3tsZtG1SjH4epoAWpsKo2m4YEVU
	 IEg63BYnl10BPiJio2lCzU0/YEYtLApYuIXJfre8ArLrbn7OLvRrqGrL7bBh9I8Jq1
	 bvwRJy5koInppEcin5fLUeEbFq9aDZJ5TDsaiNnk+KRjJ4qGl12OMmxD1SKP1cOL8+
	 HeTsT/MM3r8UW/Prl+d9kdtMMeHHsHBdrROLY+P5Ao9vIfp7OvlFLeSXf6/kB9Qh5q
	 pt3PIti+5pCLE8xgRxG/cmd+4QQOfLgXagbOYp9GwgAgpdUgwfSIp0+Xv+yUFUbmbT
	 pMXVNTAJayM5A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1748558448; x=1748818948; i=teddy.astie@vates.tech;
	bh=Y53hueVrFDexdKiEqYRowA2tjeyA5Izf+Dp0bUmOPKk=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=Tuq0BTu4afXaFsfdY0dFFeyHUS+lafUc4A9VysZku/KQSbliymGCuQ4i2ijxIn6tT
	 5QHrQ28Sb1mZfYPDoImeq/hCYpPnlZeqQGJ5dZfp88HMiNMQRdZiDWMFhATgv9giw8
	 roJlAM8s6FYg+jlcEZ4jYVggOCcM5txzebH9Y/Yqk/Ifaw35Zmnl44Dg6kb3GAwQVL
	 yzzV6uDRg+/9r/N6eswVJ9Q6uBCY8EdPPSMhJBD7moDnDGEfn6NkM75Tyzla3PTEJi
	 1cwHGCYZsPvqBZZ8s3quqoDsKUKMGqXo9+8qAX7t2agUPkuhzZcouHsHoGhnX/DFE4
	 2v6DPt1XgN6fA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v3=201/3]=20docs:=20add=20documentation=20for=20Argo=20as=20a=20feature?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1748558445858
Message-Id: 
To: "Christopher Clark" , xen-devel@lists.xenproject.org
Cc: "Daniel Smith" , "Rich Persaud" , "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" 
References: <20250528211040.10562-1-christopher.w.clark@gmail.com>
In-Reply-To: <20250528211040.10562-1-christopher.w.clark@gmail.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.f5d62f09982d4a5090cf9d96bbfa4bae?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250529:md
Date: Thu, 29 May 2025 22:40:47 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello Christopher,

Le 28/05/2025 =C3=A0 23:13, Christopher Clark a =C3=A9crit=C2=A0:
> Adds approachable documentation describing system components and
> introduces the support statement for feature status.
> 
> Signed-off-by: Christopher Clark 
> ---
>   docs/features/argo-feature.pandoc | 99 +++++++++++++++++++++++++++++++
>   1 file changed, 99 insertions(+)
>   create mode 100644 docs/features/argo-feature.pandoc
> 
> diff --git a/docs/features/argo-feature.pandoc b/docs/features/argo-featu=
re.pandoc
> new file mode 100644
> index 0000000000..b6a10be78a
> --- /dev/null
> +++ b/docs/features/argo-feature.pandoc
> @@ -0,0 +1,99 @@
> +% Argo interdomain communication
> +% Revision 1
> +
> +\clearpage
> +
> +# Basics
> +
> +---------------- ----------------------------------------------------
> +         Status: **Tech Preview**
> +
> +  Architectures: x86, ARM
> +
> +   Component(s): Hypervisor, guest
> +---------------- ----------------------------------------------------
> +
> +# Overview
> +
> +Argo is a lightweight data transport for communication between virtual
> +machines, with a simple hypervisor interface that is accessible for
> +building embedded systems and designed to work with familiar primitives
> +within guest OS kernels. It supports policy control over communication
> +and isolation between VMs.
> +
> +# User details
> +
> +Argo is present in Xen, included since Xen 4.12. A Linux device driver
> +and userspace library are available and Argo is regularly tested in the
> +Xen Continuous Integration system.
> +

Not really related to the documentation itself, but it would be 
preferable to have the Linux driver upstreamed such as this sentence 
sounds more as "it is supported" rather than "it's possible to make it 
work".

It would also make Argo easier to integrate in Xen-based projects.

> +To configure a Xen system to enable Argo:
> +
> +* ensure that Argo is enabled in the hypervisor with KConfig option
> +
> +* enable Argo on the Xen hypervisor command line
> +
> +* load the Argo guest kernel device driver
> +
> +* ensure that the Argo guest libraries are installed
> +
> +The guest userspace libraries support software designed for Argo
> +interfaces and also enables software designed for networks to
> +communicate between VMs by Argo.  This allows platform software to be
> +plumbed easily between virtual machines, without requiring networking
> +and with system policy controls over this communication.
> +
> +# Technical details
> +
> +## Argo components
> +
> +* Xen: Argo in the hypervisor provides communication between virtual
> +  machines.
> +
> +* Guest kernel: driver provides interfaces for data transport for use
> +  within the kernel, and implements familiar abstractions for
> +  networking software.
> +
> +* Guest libraries: provide application-level support for interdomain
> +  communication.
> +

That sounds a bit confusing to me, the guest kernel provides familiar 
abstractions for networking software (I hear through that something like 
sockets), yet we still have guest libraries for application-level support.

I think the guest libraries provide a shim for some of the argo-specific 
aspects (like ioctls and sockaddr_argo related bits); while the 
interface is more unix-oriented with regular sockets operations 
(sendmsg, ...).

> +## Argo implementation within Xen
> +
> +See the public Xen headers for the primary interface documentation.
> +

There is the design document in docs/designs/argo.pandoc that explains 
the inner design inside Xen. I think the public headers are more for 
guest consumption.

As this document also targets guest developers, it would be great to 
have some guidance (e.g a docs document) on how a guest should implement 
argo support.

> +# Limitations
> +
> +Argo has been developed and tested on x86 and ARM architectures.
> +
> +# Testing
> +
> +The Argo test developed for the Xen Test Framework provides coverage of
> +the hypercall operations.
> +
> +The Xen Project CI provides system test coverage of an Argo-enabled Xen
> +system with Linux.
> +
> +# Areas for improvement
> +
> +## Argo and VirtIO
> +
> +References to design documentation for the development of an Argo
> +transport for VirtIO are available via:
> +https://wiki.xenproject.org/wiki/Virtio_On_Xen
> +

Are there news regarding this ?

There is work done on virtio-msg [1], which looks fairly similar to 
virtio-argo (or at least, virtio-msg could work with Argo in a similar 
fashion to what's described on the virtio-argo design).

[1] https://linaro.atlassian.net/wiki/spaces/HVAC/overview

> +# Known issues
> +
> +* For development: sysctl/domctls for toolstack to control per-VM access
> +  to Argo
> +

Is it regarding disabling the argo on a per-guest basis, or regarding if 
a specific VM can communicate with another VM ? i.e can the toolstack 
decide to prevent 2 guest from communicating ?

IIRC, in Argo, a guest on his own can decide who can communicate with 
him using separate registered rings. But I am not sure if there is more 
on that regard.

> +# References
> +
> +See the ARGO section of the Xen MAINTAINERS document for web reference.
> +
> +# History
> +
> +------------------------------------------------------------------------
> +Date       Revision Version   Notes
> +---------- -------- --------- ------------------------------------------
> +2025-05-28 1        Xen 4.12+ Feature included in Xen 4.12.
> +---------- -------- --------- ------------------------------------------

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Thu May 29 23:10:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 23:10:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000235.1380576 (Exim 4.92)
	(envelope-from )
	id 1uKmNs-0004m9-6y; Thu, 29 May 2025 23:10:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000235.1380576; Thu, 29 May 2025 23: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 1uKmNs-0004m2-4H; Thu, 29 May 2025 23:10:00 +0000
Received: by outflank-mailman (input) for mailman id 1000235;
 Thu, 29 May 2025 23:09:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKmNq-0004lw-A1
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 23:09:58 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 08eefaef-3ce2-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 01:09:56 +0200 (CEST)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-32923999549so12733281fa.2
 for ; Thu, 29 May 2025 16:09:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 08eefaef-3ce2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748560195; x=1749164995; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=pjTGqoRj94PC8pzd3IIf1OitKHN6xY8jwMkO8kw9Yh0=;
        b=YF7PHBE+yKNSFGDyfy7FRuGnR3zDUrnPIcyN29pRm2BcqrNJyAdHxm31QsH8wmwPQy
         uPJbXwxrwaX75CVVIP3C1Hj/LWPCjZDX/7B4WIRf4Xj7F55KUJZQtFK6BNC5NUsTCraT
         wIl/HjmBF/vfRQSTuFL8gc0o42uhnZXmDMcCLaGwQBqLFHnjdiROJyGt8H0ueZEWrnP/
         etPdLOEOKB/UA+mqDslXc3lCY/MAmw/PGtMLtF51LlElGJY5aYnFjgNEQXZotOPYJtap
         cWR7WI8z2EhyVQ6Ftp8Pw31xmZueLLM7/+e4X9q5QXNt/8+P/K/fJJybvcG9uewMqdMb
         E3cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748560195; x=1749164995;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=pjTGqoRj94PC8pzd3IIf1OitKHN6xY8jwMkO8kw9Yh0=;
        b=bctOunfZgWiBrjDLJ4q8yxwPp5K8JhU0RBojSk6/1C0DiY/j7Wz8vRFWSc910ovry+
         TFlP+rWNfXDkmJ2Y4y8aQqoqLwg/Opy/RxIlzAj1n+B4oAeCWEJVLfFkQGvuh4j3g3au
         xaOUGeWXmGBQ0kJ0uhfpLHDfPCKFfwLkJWvr9AyehywWRbmczYREs8OShFGN1N6qs6wn
         l5jD358c5bDrYxSNpL4HNV0CslgPhAP8eMkeUx7/UCeyF0P3qej2XXwGswSZpsoHWxSv
         /9QcGBnQ6YIZLnhFUvjkPuHbGrA1GizG3KLofF0GsQQvKdt4swL+UQkvRWHOiti4jW2+
         WqfQ==
X-Gm-Message-State: AOJu0YyMrpwxEV5eyQgxMbPvr8sPvI0tnvcPskrOl1pAj8C7DQK+UNnf
	zWNAnesCE4VsB/qOVPBJ/z97KQnq7D/JI7ZFrI76c5eegSIJTALBpSP5SyUOKtX3Xie5VJblcXv
	kx3H000sCgM9Xcr4umkUoO42xB9h5nvA=
X-Gm-Gg: ASbGncsQpAmIugdaFWVFs4HKYdvIAUvHO6nbxeoivWYYmWhhHTosYjBnvQqelqD0Hwc
	GYwTx/V6TGJZT8E7P/JaYvbSg32YuRKSDOQmnLvJ4ch8O5ZJmOvH52zxgwIBTpSXivLdO2NM6bS
	hWYBLAnzHKOItdiTlajNeWGhVNrqKo1//k0/HEXnAPcw==
X-Google-Smtp-Source: AGHT+IFJCxmqslJx8E6DJPgHojK4mbvM7D3ysBo1BmnswaJU/UloGUAjnsD4/SESm2dwNrcJR2HA0eGuBkQWNm7PW1k=
X-Received: by 2002:a05:651c:b2c:b0:327:fec0:b85d with SMTP id
 38308e7fff4ca-32a8cda6f69mr6176341fa.21.1748560195012; Thu, 29 May 2025
 16:09:55 -0700 (PDT)
MIME-Version: 1.0
References: <20250520141027.120958-1-andrew.cooper3@citrix.com>
  <0a2a1ff2-d2fa-4331-acad-0e825421e95e@citrix.com>
In-Reply-To: <0a2a1ff2-d2fa-4331-acad-0e825421e95e@citrix.com>
From: Christopher Clark 
Date: Fri, 30 May 2025 00:09:43 +0100
X-Gm-Features: AX0GCFvOYY8nwxuVSlzd5U_xW-Ex1kQ2SYwJWmqfsXQ-YsyE1GvMF-vQOOSOY7c
Message-ID: 
Subject: Re: [PATCH] xen/argo: Command line handling improvements
To: Andrew Cooper 
Cc: Xen-devel , 
	"Daniel P . Smith" , Denis Mukhin 
Content-Type: multipart/alternative; boundary="0000000000004acbb106364e6552"

--0000000000004acbb106364e6552
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 21, 2025 at 9:43=E2=80=AFPM Andrew Cooper 
wrote:

> On 21/05/2025 2:01 am, Christopher Clark wrote:
> > On Tue, May 20, 2025 at 3:10=E2=80=AFPM Andrew Cooper
> >  wrote:
> >
> >     Treat "argo" on the command line as a positive boolean, rather
> >     than requiring
> >     the user to pass "argo=3D1/on/enable/true".
>

I have tested that this patch does change the command line behaviour as
described, and doesn't prevent the existing valid options from parsing and
acting as they currently do, to enable and disable the subsystem, so that
is positive. I do have significant reservations stated below, however.


> >
> >     Move both opt_argo* variables into __ro_after_init.  They're set
> >     during
> >     command line parsing and never modified thereafter.
>

I haven't directly tested this aspect of the patch.


> >
> >
> > Instead of binding to static values set at boot, would
> > boolean_runtime_param be acceptable?
>
> No, for several reasons.
>

Thanks for the reply, your perspective is helpful.


>
> Sure, you could dynamically turn it on, but existing domains can't use
> it because argo_init() wasn't called on them.  Now consider what happens
> when dynamically turning it off behind the back of a domain which was
> using it.
>

> All the existing runtime controls are for properties that are not
> visible to guests.  Adding opt_argo to this list would create a lot of
> carnage.
>

OK, your aversion to it is clear and I'm not pushing to make that change.


>
> (Like almost everything else in Xen), Argo is entirely broken with
> respect to enumeration and controls.  And while this isn't your fault
> for having copied the status quo, it is still a problem needing fixing.
>
> Argo's availability needs advertising to the toolstack like all other
> features, and the toolstack needs to be able to choose the Argo settings
> on a per-VM basis.  Like everything else about VMs, the Argo-ness must
> be invariant for the lifetime of the domain.


> This means changes to sysctls/domctls, which IMO are prerequisites for
> Argo to move from Tech Preview to Supported.  In a world where such
> controls existed, the argo cmdline option would really only be for
> someone trying to disable Argo globally.
>

The above is why I'd prefer not to apply this patch: at the moment, the
population of Argo developers and system integrators do not create or use
bootloader configuration files with the single "argo" keyword on the Xen
command line. (They use "argo=3D1" or similar instead.)

Once a change such as this is merged, then there is a new behaviour that is
made available, and a new expectation created not to change the behaviour
of the standalone command line option (ie. "argo").

I'd like to retain using the standalone argo keyword for when the only boot
option that is necessary is just a simple on or off. At the moment, that's
not the case: the suboption ("mac-permissive=3D1") is valid to either inclu=
de
or omit, and there is work to do in order to enable retiring it - and
hopefully it will enable behaviour similar to the wider connectivity of
that option by default, which will not be the case for a system with "argo"
on the command line if just this current patch is applied.


>
> This particular patch comes simply from me trying to experiment with
> Argo to sort out the XTF test, and deciding that the behaviour was
> objectionable enough that I'd improve it.
>

I agree with the end goal; but don't think this is the right next step to
get there, and I don't think the existing situation is sufficiently
objectionable to make this change this way.

Christopher



>
> ~Andrew
>

--0000000000004acbb106364e6552
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    On Wed, May 21, 2025 at 9:43=E2=80=AFPM A=
ndrew Cooper <andrew.cooper=
3@citrix.com> wrote:
    On 21/05/2025 2:01=
 am, Christopher Clark wrote:
    
> On Tue, May 20, 2025 at 3:10=E2=80=AFPM Andrew Cooper
    
> <and=
rew.cooper3@citrix.com> wrote:
    
>
    
>=C2=A0 =C2=A0 =C2=A0Treat "argo" on the command line as a pos=
itive boolean, rather
    
>=C2=A0 =C2=A0 =C2=A0than requiring
    
>=C2=A0 =C2=A0 =C2=A0the user to pass "argo=3D1/on/enable/true"=
;.

    I have tested that this patch does c=
hange the command line behaviour as described, and doesn't prevent the =
existing valid options from parsing and acting as they currently do, to ena=
ble and disable the subsystem, so that is positive. I do have significant r=
eservations stated below, however.
    =C2=A0
    
>
    
>=C2=A0 =C2=A0 =C2=A0Move both opt_argo* variables into __ro_after_init.=
=C2=A0 They're set
    
>=C2=A0 =C2=A0 =C2=A0during
    
>=C2=A0 =C2=A0 =C2=A0command line parsing and never modified thereafter.=


    I haven't directly tested this asp=
ect of the patch.
    =C2=A0
    
>
    
>
    
> Instead of binding to static values set at boot, would
    
> boolean_runtime_param be acceptable?
    

    
No, for several reasons.

    Thanks for the=
 reply, your perspective is helpful.
    =C2=A0
    

    
Sure, you could dynamically turn it on, but existing domains can't use<=
br>
it because argo_init() wasn't called on them.=C2=A0 Now consider what h=
appens
    
when dynamically turning it off behind the back of a domain which was
    
using it.

    
All the existing runtime controls are for properties that are not
    
visible to guests.=C2=A0 Adding opt_argo to this list would create a lot of=

    
carnage.

    OK, your aversion to it is cle=
ar and I'm not pushing to make that change.
    =C2=A0

    
(Like almost everything else in Xen), Argo is entirely broken with
    
respect to enumeration and controls.=C2=A0 And while this isn't your fa=
ult
    
for having copied the status quo, it is still a problem needing fixing.
    

    
Argo's availability needs advertising to the toolstack like all other
features, and the toolstack needs to be able to choose the Argo settings
on a per-VM basis.=C2=A0 Like everything else about VMs, the Argo-ness must=

    
be invariant for the lifetime of the domain.
    

    
This means changes to sysctls/domctls, which IMO are prerequisites for
    
Argo to move from Tech Preview to Supported.=C2=A0 In a world where such
controls existed, the argo cmdline option would really only be for
    
someone trying to disable Argo globally.

    The=C2=A0above is why I'd prefer not to apply this patch: at the mome=
nt, the population of Argo developers and system integrators do not create =
or use bootloader configuration files with the single "argo" keyw=
ord on the Xen command line. (They use "argo=3D1" or similar inst=
ead.)

    Once a change such as this is merged, then t=
here is a new behaviour that is made available, and a new expectation creat=
ed not to change the behaviour of the standalone command line option (ie. &=
quot;argo").

    I'd like to retain using the=
 standalone argo keyword for when the only boot option that is necessary is=
 just a simple on or off. At the moment, that's not the case: the subop=
tion ("mac-permissive=3D1") is valid to either include or omit, a=
nd there is work to do in order to=C2=A0enable retiring it - and hopefully =
it will enable behaviour similar to the wider connectivity of that option b=
y default, which will not be the case for a system with "argo" on=
 the command line if just this current patch is applied.
    =C2=A0
    

    
This particular patch comes simply from me trying to experiment with
    
Argo to sort out the XTF test, and deciding that the behaviour was
    
objectionable enough that I'd improve it.

    I agree with the end goal; but don't think this is the right nex=
t step to get there, and I don't think the existing situation is suffic=
iently objectionable to make this change this way.

    Christopher

    =C2=A0
    

    
~Andrew
    

    

--0000000000004acbb106364e6552--


From xen-devel-bounces@lists.xenproject.org Thu May 29 23:23:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 23:23:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000247.1380586 (Exim 4.92)
	(envelope-from )
	id 1uKmaV-0007Q9-9h; Thu, 29 May 2025 23:23:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000247.1380586; Thu, 29 May 2025 23: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 1uKmaV-0007Q2-6r; Thu, 29 May 2025 23:23:03 +0000
Received: by outflank-mailman (input) for mailman id 1000247;
 Thu, 29 May 2025 23:23:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKmaT-0007Pu-91
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 23:23:01 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d600d084-3ce3-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 01:22:50 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id BB1794ACCF;
 Thu, 29 May 2025 23:22:48 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 622DAC4CEEB;
 Thu, 29 May 2025 23: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" 
X-Inumbo-ID: d600d084-3ce3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748560968;
	bh=ae/9YhRWjVTNXpnYDKCwWz8NiJ2GS09KOAWo/M7aoRU=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=mnG1KlCxNyWiaXzSHzULKuC+WyY07B6DrkvrbfvACsJXmtqU6bEjPexWzp9bkIhtf
	 UXRd5G4LHGhTaqix2dl0/FN0b2Mnx/Clqgu9B/ngqMTl3YeXtbEW+jvJutnwLC5psL
	 7xDuvJ64ayj8omPltVj8JAOXB6oScYSXiXAL+LCAkfn6Sz+mGyZlb0wfIFd4+BTYAY
	 LVO/niTh0bXdEQx15ypEuqoX3BsJN0idNBiXCibZp5pjEyrUNd4qcpp2H5PBKNZW+A
	 hTsb2l6fJCh+2TTg1nPb69SURT3d1+5hbftEhKSDnOfhN/crNhTzDGZCPn/2vvSvII
	 DQsQBxKbadBRg==
Date: Thu, 29 May 2025 16:22:45 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Penny Zheng 
cc: xen-devel@lists.xenproject.org, ray.huang@amd.com, 
    Jan Beulich , Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Anthony PERARD , 
    Michal Orzel , Julien Grall , 
    Stefano Stabellini 
Subject: Re: [PATCH v4 03/20] xen/x86: remove "depends on
 !PV_SHIM_EXCLUSIVE"
In-Reply-To: <20250528091708.390767-4-Penny.Zheng@amd.com>
Message-ID: 
References: <20250528091708.390767-1-Penny.Zheng@amd.com> <20250528091708.390767-4-Penny.Zheng@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 27 May 2025, Penny Zheng wrote:
> Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally
> equivalent "if !...") in Kconfig file, since negative dependancy will badly
> affect allyesconfig. To make sure unchanging produced config file based
> on "pvshim_defconfig", we shall explicitly state according Kconfig is not set
> 
> Add "default y" for SHADOW_PAGING and TBOOT, otherwise we will have unset
> values when running make defconfig based on "x86_64_defconfig".
> 
> Signed-off-by: Penny Zheng 

Reviewed-by: Stefano Stabellini 


> ---
> v2 -> v3:
> - remove comment for PV_SHIM_EXCLUSIVE
> ---
> v3 -> v4:
> - explicitly state "CONFIG_xxx is not set" in "pvshim_defconfig"
> - Add "default y" for SHADOW_PAGING and TBOOT
> - refactor commit message
> ---
>  xen/arch/x86/Kconfig                  | 6 ++----
>  xen/arch/x86/configs/pvshim_defconfig | 5 +++++
>  xen/arch/x86/hvm/Kconfig              | 1 -
>  xen/drivers/video/Kconfig             | 4 ++--
>  4 files changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 7afe879710..8c8e661d53 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -143,7 +143,7 @@ config XEN_IBT
>  
>  config SHADOW_PAGING
>  	bool "Shadow Paging"
> -	default !PV_SHIM_EXCLUSIVE
> +	default y
>  	depends on PV || HVM
>  	help
>  
> @@ -175,7 +175,7 @@ config BIGMEM
>  config TBOOT
>  	bool "Xen tboot support (UNSUPPORTED)"
>  	depends on INTEL && UNSUPPORTED
> -	default !PV_SHIM_EXCLUSIVE
> +	default y
>  	select CRYPTO
>  	help
>  	  Allows support for Trusted Boot using the Intel(R) Trusted Execution
> @@ -288,7 +288,6 @@ config PV_SHIM_EXCLUSIVE
>  
>  	  If unsure, say N.
>  
> -if !PV_SHIM_EXCLUSIVE
>  
>  config HYPERV_GUEST
>  	bool "Hyper-V Guest"
> @@ -298,7 +297,6 @@ config HYPERV_GUEST
>  
>  	  If unsure, say N.
>  
> -endif
>  
>  config REQUIRE_NX
>  	bool "Require NX (No eXecute) support"
> diff --git a/xen/arch/x86/configs/pvshim_defconfig b/xen/arch/x86/configs/pvshim_defconfig
> index 2ad27f898e..6f652e145e 100644
> --- a/xen/arch/x86/configs/pvshim_defconfig
> +++ b/xen/arch/x86/configs/pvshim_defconfig
> @@ -26,3 +26,8 @@ CONFIG_EXPERT=y
>  # CONFIG_INTEL_IOMMU is not set
>  # CONFIG_DEBUG is not set
>  # CONFIG_GDBSX is not set
> +# CONFIG_SHADOW_PAGING is not set
> +# CONFIG_TBOOT is not set
> +# HYPERV_HYPERV_GUEST is not set
> +# CONFIG_HVM is not set
> +# CONFIG_VGA is not set
> diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
> index 2def0f98e2..b903764bda 100644
> --- a/xen/arch/x86/hvm/Kconfig
> +++ b/xen/arch/x86/hvm/Kconfig
> @@ -1,6 +1,5 @@
>  menuconfig HVM
>  	bool "HVM support"
> -	depends on !PV_SHIM_EXCLUSIVE
>  	default !PV_SHIM
>  	select COMPAT
>  	select IOREQ_SERVER
> diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
> index 245030beea..66ee1e7c9c 100644
> --- a/xen/drivers/video/Kconfig
> +++ b/xen/drivers/video/Kconfig
> @@ -3,10 +3,10 @@ config VIDEO
>  	bool
>  
>  config VGA
> -	bool "VGA support" if !PV_SHIM_EXCLUSIVE
> +	bool "VGA support"
>  	select VIDEO
>  	depends on X86
> -	default y if !PV_SHIM_EXCLUSIVE
> +	default y
>  	help
>  	  Enable VGA output for the Xen hypervisor.
>  
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Thu May 29 23:36:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 23:36:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000261.1380595 (Exim 4.92)
	(envelope-from )
	id 1uKmnL-0000kn-H5; Thu, 29 May 2025 23:36:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000261.1380595; Thu, 29 May 2025 23:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKmnL-0000kg-E4; Thu, 29 May 2025 23:36:19 +0000
Received: by outflank-mailman (input) for mailman id 1000261;
 Thu, 29 May 2025 23:36:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKmnK-0000ka-VL
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 23:36:18 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b518cad6-3ce5-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 01:36:13 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id ABAB5614BA;
 Thu, 29 May 2025 23:36:12 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F465C4CEEE;
 Thu, 29 May 2025 23:36: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" 
X-Inumbo-ID: b518cad6-3ce5-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748561772;
	bh=X+RXe1a1/XeaL0wDzjF38o/ft4ck/X3z761JJ7tOUjM=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=MTip0EQkRwOT8K4w2HFACLXCclt7GsgCE+LETy/Kq3uFFtk3NcU0VSZqayS5ds50i
	 5sVpD1l4bzLEldyG/f6SECqf2AHpG7SvzmjXeWkvnLgzU6ASUjKWlxs613nD0oRdqt
	 lzaDbOIVZL+B5skEbfBDZ58/ju2G4QGh7y2iJC0RVQEkXuqfhwti1g6gRG6CnPJhd5
	 9P6AqQJ2zgYmqaYrbZUpBRty/99rHEfmE14AJbaMkwCYv2BZ50dfp6BbiREop0eYfL
	 rLaMrkeTjSOVVusd++sb8Guw68j+nehoPOhQ57mRON5F72r7ORyLythFhbtroeXu8j
	 HT94p7TsQyBoQ==
Date: Thu, 29 May 2025 16:36:09 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Denis Mukhin 
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com
Subject: Re: [PATCH v3 1/2] xen/domain: introduce common hardware emulation
 flags
In-Reply-To: <20250528210139.2572609-2-dmukhin@ford.com>
Message-ID: 
References: <20250528210139.2572609-1-dmukhin@ford.com> <20250528210139.2572609-2-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 28 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> Add common emulation_flags for configuring domain emulation features.
> 
> Print d->emulation_flags from 'q' keyhandler for better traceability while
> debugging.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v2:
> - move emulation_flags to common domain struct
> ---
>  xen/arch/x86/domain.c             |  2 +-
>  xen/arch/x86/domctl.c             |  2 +-
>  xen/arch/x86/include/asm/domain.h | 25 +++++++++++--------------
>  xen/common/keyhandler.c           |  1 +
>  xen/include/xen/sched.h           |  2 ++
>  5 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 7536b6c871..0363ccb384 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -831,7 +831,7 @@ int arch_domain_create(struct domain *d,
>                 emflags);
>          return -EOPNOTSUPP;
>      }
> -    d->arch.emulation_flags = emflags;
> +    d->emulation_flags = emflags;
>  
>  #ifdef CONFIG_PV32
>      HYPERVISOR_COMPAT_VIRT_START(d) =
> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index 3044f706de..37d848f683 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -144,7 +144,7 @@ void arch_get_domain_info(const struct domain *d,
>      if ( paging_mode_hap(d) )
>          info->flags |= XEN_DOMINF_hap;
>  
> -    info->arch_config.emulation_flags = d->arch.emulation_flags;
> +    info->arch_config.emulation_flags = d->emulation_flags;
>      info->gpaddr_bits = hap_paddr_bits;
>  }
>  
> diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
> index 8c0dea12a5..eafd5cfc90 100644
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -455,9 +455,6 @@ struct arch_domain
>  
>      /* Don't unconditionally inject #GP for unhandled MSRs. */
>      bool msr_relaxed;
> -
> -    /* Emulated devices enabled bitmap. */
> -    uint32_t emulation_flags;
>  } __cacheline_aligned;
>  
>  #ifdef CONFIG_HVM
> @@ -494,17 +491,17 @@ struct arch_domain
>                                   X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
>                                   X86_EMU_VPCI)
>  
> -#define has_vlapic(d)      (!!((d)->arch.emulation_flags & X86_EMU_LAPIC))
> -#define has_vhpet(d)       (!!((d)->arch.emulation_flags & X86_EMU_HPET))
> -#define has_vpm(d)         (!!((d)->arch.emulation_flags & X86_EMU_PM))
> -#define has_vrtc(d)        (!!((d)->arch.emulation_flags & X86_EMU_RTC))
> -#define has_vioapic(d)     (!!((d)->arch.emulation_flags & X86_EMU_IOAPIC))
> -#define has_vpic(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIC))
> -#define has_vvga(d)        (!!((d)->arch.emulation_flags & X86_EMU_VGA))
> -#define has_viommu(d)      (!!((d)->arch.emulation_flags & X86_EMU_IOMMU))
> -#define has_vpit(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIT))
> -#define has_pirq(d)        (!!((d)->arch.emulation_flags & X86_EMU_USE_PIRQ))
> -#define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
> +#define has_vlapic(d)      (!!((d)->emulation_flags & X86_EMU_LAPIC))
> +#define has_vhpet(d)       (!!((d)->emulation_flags & X86_EMU_HPET))
> +#define has_vpm(d)         (!!((d)->emulation_flags & X86_EMU_PM))
> +#define has_vrtc(d)        (!!((d)->emulation_flags & X86_EMU_RTC))
> +#define has_vioapic(d)     (!!((d)->emulation_flags & X86_EMU_IOAPIC))
> +#define has_vpic(d)        (!!((d)->emulation_flags & X86_EMU_PIC))
> +#define has_vvga(d)        (!!((d)->emulation_flags & X86_EMU_VGA))
> +#define has_viommu(d)      (!!((d)->emulation_flags & X86_EMU_IOMMU))
> +#define has_vpit(d)        (!!((d)->emulation_flags & X86_EMU_PIT))
> +#define has_pirq(d)        (!!((d)->emulation_flags & X86_EMU_USE_PIRQ))
> +#define has_vpci(d)        (!!((d)->emulation_flags & X86_EMU_VPCI))
>  
>  #define gdt_ldt_pt_idx(v) \
>        ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> index 0bb842ec00..cd731452ba 100644
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -306,6 +306,7 @@ static void cf_check dump_domains(unsigned char key)
>              if ( test_bit(i, &d->watchdog_inuse_map) )
>                  printk("    watchdog %d expires in %d seconds\n",
>                         i, (u32)((d->watchdog_timer[i].expires - NOW()) >> 30));
> +        printk("    emulation_flags %#x\n", d->emulation_flags);
>  
>          arch_dump_domain_info(d);
>  
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 559d201e0c..dc4f917664 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -651,6 +651,8 @@ struct domain
>      unsigned int num_llc_colors;
>      const unsigned int *llc_colors;
>  #endif
> +
> +    uint32_t emulation_flags;

I think it is a good idea to move emulation_flags to common and I think
we can make use of them on ARM too because we have a choice of emulators
on ARM as well (pl011, gicv2, gicv3, etc.). I think it makes sense to
move at least kinfo->arch.vpl011 to be an emulation_flags instead.

I was going to ask to add an #ifdef CONFIG_X86 around the
emulation_flags field as it is currently still unused on other
architectures, but then it would break the compilation of keyhandler.c.

So maybe it is OK this way.

Reviewed-by: Stefano Stabellini 


>  } __aligned(PAGE_SIZE);
>  
>  static inline struct page_list_head *page_to_list(
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Thu May 29 23:47:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 23:47:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000269.1380606 (Exim 4.92)
	(envelope-from )
	id 1uKmy6-0002Py-Fi; Thu, 29 May 2025 23:47:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000269.1380606; Thu, 29 May 2025 23: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 1uKmy6-0002Pr-Cd; Thu, 29 May 2025 23:47:26 +0000
Received: by outflank-mailman (input) for mailman id 1000269;
 Thu, 29 May 2025 23:47:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKmy5-0002Pl-GB
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 23:47:25 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 44077036-3ce7-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 01:47:23 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 2595CA4FD13;
 Thu, 29 May 2025 23:47:22 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 571C3C4CEE7;
 Thu, 29 May 2025 23:47: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" 
X-Inumbo-ID: 44077036-3ce7-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748562441;
	bh=VmHBNTzEsGFZH1JVr/mkgcHBWzzB4z5CYt3fb/dtee4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Dva+GxYFJpBYeGbRS3MiFVm/+j0HivfeBbqMzb4wDBijk2BPwk8HegZoLyluMyEZl
	 ILXzXUcJIhh6u0t+ObzDBr3dpyXZVLP0QUQLneZrpdnkSR2qv6xV367KKgNmuQ9ung
	 +P8pDlPzPcmqeaFb2J7xrg3A14zTehS/ETn5fBbdqwNZt6gn5VBjrsOxkbbG60o6nz
	 cLzaz3UcaulbSnkjoXATG01yg85vo77E1k+fYioezqJ1kXyuCWs1w/YzjNlgDoPFaC
	 oMLTP7eVmf65uMOpUB3oXjJGZzDJ2B8RhcDYMfy9pOLjFkTwbhTi5sk7YaW52jnqKl
	 TH1DS6RXPtF1A==
Date: Thu, 29 May 2025 16:47:18 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Denis Mukhin 
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com
Subject: Re: [PATCH v3 2/2] xen/domain: rewrite emulation_flags_ok()
In-Reply-To: <20250528210139.2572609-3-dmukhin@ford.com>
Message-ID: 
References: <20250528210139.2572609-1-dmukhin@ford.com> <20250528210139.2572609-3-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 28 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> From: Denis Mukhin 
> 
> Rewrite emulation_flags_ok() to simplify future modifications.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v2:
> - addressed review feedback
> - added some explanatory comments for emulation_flags_ok()
> ---
>  xen/arch/x86/domain.c | 92 ++++++++++++++++++++++++++++++++++---------
>  1 file changed, 74 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 0363ccb384..1d41d26c4d 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -743,32 +743,88 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>      return 0;
>  }
>  
> +/*
> + * Verify that the domain's emulation flags resolve to a supported configuration.
> + *
> + * This ensures we only allow a known, safe subset of emulation combinations
> + * (for both functionality and security). Arbitrary mixes are likely to cause
> + * errors (e.g., null pointer dereferences).
> + *
> + * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XXX
> + * symbols.
> + */
>  static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
>  {
> +    enum {
> +        CAP_PV          = BIT(0, U),
> +        CAP_HVM         = BIT(1, U),
> +        CAP_HWDOM       = BIT(2, U),
> +        CAP_DOMU        = BIT(3, U),
> +    };
> +    static const struct {
> +        unsigned int caps;
> +        uint32_t min;
> +        uint32_t opt;
> +    } configs[] = {
> +#ifdef CONFIG_PV
> +        /* PV */
> +        {
> +            .caps   = CAP_PV | CAP_DOMU,
> +            .min    = 0,
> +            .opt    = 0,
> +        },
> +
> +        /* PV (likely dom0) */
> +        {
> +            .caps   = CAP_PV | CAP_HWDOM,
> +            .min    = X86_EMU_PIT,
> +            .opt    = 0,
> +        },
> +#endif /* #ifdef CONFIG_PV */
> +
> +#ifdef CONFIG_HVM
> +        /* PVH dom0/domU or HVM domU */
> +        {
> +            .caps   = CAP_HVM | CAP_HWDOM,
> +            .min    = X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
> +            .opt    = 0,
> +        },
> +
> +

NIT: double \n

I checked carefully and the new semantic matches the old one with the
extra clarification that X86_EMU_PIT is only for hwdom.

Reviewed-by: Stefano Stabellini 


> +        /* HVM domU */
> +        {
> +            .caps   = CAP_HVM | CAP_DOMU,
> +            .min    = X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
> +            /* HVM PIRQ feature is user-selectable. */
> +            .opt    = X86_EMU_USE_PIRQ,
> +        },
> +
> +        /* PVH */
> +        {
> +            .caps   = CAP_HVM | CAP_DOMU,
> +            .min    = X86_EMU_LAPIC,
> +            .opt    = 0,
> +        },
> +#endif /* #ifdef CONFIG_HVM */
> +    };
> +    unsigned int i, caps = is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU;
> +
> +    if ( is_pv_domain(d) )
> +        caps |= CAP_PV;
> +    else if ( is_hvm_domain(d) )
> +        caps |= CAP_HVM;
> +
>  #ifdef CONFIG_HVM
>      /* This doesn't catch !CONFIG_HVM case but it is better than nothing */
>      BUILD_BUG_ON(X86_EMU_ALL != XEN_X86_EMU_ALL);
>  #endif
>  
> -    if ( is_hvm_domain(d) )
> -    {
> -        if ( is_hardware_domain(d) &&
> -             emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
> -            return false;
> -        if ( !is_hardware_domain(d) &&
> -             /* HVM PIRQ feature is user-selectable. */
> -             (emflags & ~X86_EMU_USE_PIRQ) !=
> -             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
> -             emflags != X86_EMU_LAPIC )
> -            return false;
> -    }
> -    else if ( emflags != 0 && emflags != X86_EMU_PIT )
> -    {
> -        /* PV or classic PVH. */
> -        return false;
> -    }
> +    for ( i = 0; i < ARRAY_SIZE(configs); i++ )
> +        if ( caps == configs[i].caps &&
> +             (emflags & ~configs[i].opt) == configs[i].min )
> +            return true;
>  
> -    return true;
> +    return false;
>  }
>  
>  void __init arch_init_idle_domain(struct domain *d)
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Thu May 29 23:55:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 29 May 2025 23:55:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000294.1380616 (Exim 4.92)
	(envelope-from )
	id 1uKn5N-00047j-55; Thu, 29 May 2025 23:54:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000294.1380616; Thu, 29 May 2025 23:54: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 1uKn5N-00047c-28; Thu, 29 May 2025 23:54:57 +0000
Received: by outflank-mailman (input) for mailman id 1000294;
 Thu, 29 May 2025 23:54:55 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKn5L-00047Q-DM
 for xen-devel@lists.xenproject.org; Thu, 29 May 2025 23:54:55 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4fb354a0-3ce8-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 01:54:52 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 27238A4FD0C;
 Thu, 29 May 2025 23:54:51 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98152C4CEE7;
 Thu, 29 May 2025 23:54: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" 
X-Inumbo-ID: 4fb354a0-3ce8-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748562890;
	bh=4BfsZ3augz5y7Ho+0ck+rFebHZj3y+T9LF9klbGr5jo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Io9sFGDhUqk1Y9zHHrRrFC+BpvreBrn69FuODJCWhoXcwk++z5PEF86+K8W+/LgS0
	 R/Tv/5EFHhoNPKiCihICQRGR7ryQ6to8lMbRqxZd507dJxJurfo0FxG3y2wrqVrXhy
	 WE5LIJg7xA2/UE3hnDQuhT2eFWrwABbKSW15xF7VGtzNAT5vNHt7hZvqIbvJGl5OF0
	 JTIIhlitTtKg5pXbP5EJT0KUJzlXnQMAzjQ9OA4fegHByg3gCV6lhgmmdif6jvbfGr
	 hWT8a4vvkLmSR1056XN2OU/EYPCaxVlyyHm9JH4x234m4vF+YyLczTTRCI9UeFV9bq
	 HK0ZoBFo2oEag==
Date: Thu, 29 May 2025 16:54:47 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Denis Mukhin 
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, 
    dmukhin@ford.com
Subject: Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
In-Reply-To: <20250528225030.2652166-3-dmukhin@ford.com>
Message-ID: 
References: <20250528225030.2652166-1-dmukhin@ford.com> <20250528225030.2652166-3-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 28 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> From: Denis Mukhin 
> 
> Remove the hardcoded domain ID 0 allocation for hardware domain and replace it
> with a call to get_initial_domain_id() (returns the value of hardware_domid on
> Arm).
> 
> Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_domain_id()
> ID is skipped during domain ID allocation to cover domU case in dom0less
> configuration. That also fixes a potential issue with re-using ID#0 for domUs
> when get_initial_domain_id() returns non-zero.

It looks like this sentence should be removed from the commit message as
not valid anymore.

Aside from that, the code changes below as clear.

Reviewed-by: Stefano Stabellini 


> Signed-off-by: Denis Mukhin 
> ---
> Changes since v8:
> - rebased 
> ---
>  xen/arch/arm/domain_build.c             | 4 ++--
>  xen/common/device-tree/dom0less-build.c | 9 +++------
>  xen/common/domain.c                     | 4 ++--
>  3 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index e9d563c269..0ad80b020a 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2035,9 +2035,9 @@ void __init create_dom0(void)
>      if ( !llc_coloring_enabled )
>          flags |= CDF_directmap;
>  
> -    domid = domid_alloc(0);
> +    domid = domid_alloc(get_initial_domain_id());
>      if ( domid == DOMID_INVALID )
> -        panic("Error allocating domain ID 0\n");
> +        panic("Error allocating domain ID %d\n", get_initial_domain_id());
>  
>      dom0 = domain_create(domid, &dom0_cfg, flags);
>      if ( IS_ERR(dom0) )
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index a509f8fecd..9a6015f4ce 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -974,14 +974,11 @@ void __init create_domUs(void)
>  
>          arch_create_domUs(node, &d_cfg, flags);
>  
> -        /*
> -         * The variable max_init_domid is initialized with zero, so here it's
> -         * very important to use the pre-increment operator to call
> -         * domain_create() with a domid > 0. (domid == 0 is reserved for Dom0)
> -         */
> -        domid = domid_alloc(++max_init_domid);
> +        domid = domid_alloc(DOMID_INVALID);
>          if ( domid == DOMID_INVALID )
>              panic("Error allocating ID for domain %s\n", dt_node_name(node));
> +        if ( max_init_domid < domid )
> +            max_init_domid = domid;
>  
>          d = domain_create(domid, &d_cfg, flags);
>          if ( IS_ERR(d) )
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index ae0c44fcbb..129b4fcb37 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -2423,8 +2423,8 @@ domid_t domid_alloc(domid_t domid)
>      else
>      {
>          static domid_t domid_last;
> -        /* NB: account for late hwdom case, skip ID#0 */
> -        const domid_t reserved_domid = 0;
> +        /* NB: account for late hwdom case */
> +        const domid_t reserved_domid = get_initial_domain_id();
>          const bool reserved = __test_and_set_bit(reserved_domid, domid_bitmap);
>  
>          domid = find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED,
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri May 30 00:04:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 00:04:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000302.1380627 (Exim 4.92)
	(envelope-from )
	id 1uKnEa-0006TD-Rm; Fri, 30 May 2025 00:04:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000302.1380627; Fri, 30 May 2025 00: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 1uKnEa-0006T6-Nb; Fri, 30 May 2025 00:04:28 +0000
Received: by outflank-mailman (input) for mailman id 1000302;
 Fri, 30 May 2025 00:04:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKnEY-0006T0-Lb
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 00:04:26 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a5493447-3ce9-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 02:04:25 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 2ACCFA4FD1B;
 Fri, 30 May 2025 00:04:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78672C4CEE7;
 Fri, 30 May 2025 00:04: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" 
X-Inumbo-ID: a5493447-3ce9-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748563463;
	bh=1mwVF/KHkOBDkqMACEeZBs5U8mShfF4X6FVzllWHmoc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=tcTiZmKTfCZl8s/kKPuT8aPF6lwPFyFvGjyR58A6FMhUDJ9lMr9LT3i5Z+2Lw/UWg
	 /AtScMtNn3juBBlmYnETt3c0y0rqXvPl0J90UIVy6KEnX2HDjFFV9i4mWtAcxDE6bQ
	 4IsbNNVjQnoxDcjvMHiSojEkR4sGK/0q3/YgrB6lpVoCRoFPBtqOJ2R0SM4Ga5Cs/z
	 4UesfI7ZpPhPcT7cm/EGrqpKL6Rxyv6TQlEzS80ltzXr+cCEhRJ0qaibE0zombAFqJ
	 vZr0fJ3SDriat7F9bnhStb4gyE0rwjpHPfXFrZipNOzUpPOzs2+ZyVwoWPoxoLqdmT
	 PU4j3Jlip1/DA==
Date: Thu, 29 May 2025 17:04:20 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Denis Mukhin 
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    roger.pau@citrix.com, sstabellini@kernel.org, teddy.astie@vates.tech, 
    dmukhin@ford.com
Subject: Re: [PATCH v9 3/3] xen/domain: introduce CONFIG_MAX_DOMID
In-Reply-To: <20250528225030.2652166-4-dmukhin@ford.com>
Message-ID: 
References: <20250528225030.2652166-1-dmukhin@ford.com> <20250528225030.2652166-4-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 28 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> From: Denis Mukhin 
> 
> Embedded deployments of Xen do not need to have support for more than dozen of
> domains.
> 
> Introduce build-time configuration option to limit the number of domains during
> run-time.
> 
> Suggested-by: Julien Grall 
> Signed-off-by: Denis Mukhin 

There is one DOMID_FIRST_RESERVED check in xen/arch/arm/tee/ffa.c that
should be changed too


> ---
> Changes since v8:
> - dropped hunk w/ compile-time check for DOMID_FIRST_RESERVED
> - updated CONFIG_MAX_DOMID explanation
> - dropped public header file changes
> ---
>  xen/arch/x86/cpu/mcheck/mce.c       |  2 +-
>  xen/arch/x86/cpu/vpmu.c             |  2 +-
>  xen/common/Kconfig                  |  8 ++++++++
>  xen/common/domain.c                 | 20 +++++++++++---------
>  xen/common/sched/core.c             |  4 ++--
>  xen/drivers/passthrough/vtd/iommu.c |  2 +-
>  6 files changed, 24 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
> index 1c348e557d..ee8ddd33b0 100644
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -1493,7 +1493,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
>              d = rcu_lock_domain_by_any_id(mc_msrinject->mcinj_domid);
>              if ( d == NULL )
>              {
> -                if ( mc_msrinject->mcinj_domid >= DOMID_FIRST_RESERVED )
> +                if ( mc_msrinject->mcinj_domid >= CONFIG_MAX_DOMID )
>                      return x86_mcerr("do_mca inject: incompatible flag "
>                                       "MC_MSRINJ_F_GPADDR with domain %d",
>                                       -EINVAL, domid);
> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
> index c28192ea26..67d423e088 100644
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -174,7 +174,7 @@ void vpmu_do_interrupt(void)
>       * in XENPMU_MODE_ALL, for everyone.
>       */
>      if ( (vpmu_mode & XENPMU_MODE_ALL) ||
> -         (sampled->domain->domain_id >= DOMID_FIRST_RESERVED) )
> +         (sampled->domain->domain_id >= CONFIG_MAX_DOMID) )
>      {
>          sampling = choose_hwdom_vcpu();
>          if ( !sampling )
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 3d66d09397..ef083856b8 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -579,4 +579,12 @@ config BUDDY_ALLOCATOR_SIZE
>  	  Amount of memory reserved for the buddy allocator to serve Xen heap,
>  	  working alongside the colored one.
>  
> +config MAX_DOMID
> +	int "Maximum domain ID"
> +	range 1 32752
> +	default 32752
> +	help
> +	  Specifies the maximum domain ID (dom0 or late hwdom, predefined
> +	  domains, post-boot domains, excluding Xen system domains).

Written like this it would seem that the maximum domain ID is usable,
e.g. that 32752 is a valid domid number. Actually 32752 is 0x7ff0 which
is DOMID_FIRST_RESERVED == DOMID_SELF and cannot be used.

I think we should change the description:


Specifies the maximum domain ID (dom0 or late hwdom, predefined domains,
post-boot domains, excluding Xen system domains). This value indicates
the first domain ID that is out of bounds and cannot be used for domain
allocation.



>  endmenu
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 129b4fcb37..87e5be35e5 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -68,7 +68,7 @@ struct domain *domain_list;
>  
>  /* Non-system domain ID allocator. */
>  static DEFINE_SPINLOCK(domid_lock);
> -static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
> +static DECLARE_BITMAP(domid_bitmap, CONFIG_MAX_DOMID);
>  
>  /*
>   * Insert a domain into the domlist/hash.  This allows the domain to be looked
> @@ -154,7 +154,7 @@ int domain_init_states(void)
>      ASSERT(rw_is_write_locked_by_me(¤t->domain->event_lock));
>  
>      dom_state_changed = xvzalloc_array(unsigned long,
> -                                       BITS_TO_LONGS(DOMID_FIRST_RESERVED));
> +                                       BITS_TO_LONGS(CONFIG_MAX_DOMID));
>      if ( !dom_state_changed )
>          return -ENOMEM;
>  
> @@ -234,7 +234,7 @@ int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
>      while ( dom_state_changed )
>      {
>          dom = find_first_bit(dom_state_changed, DOMID_MASK + 1);
> -        if ( dom >= DOMID_FIRST_RESERVED )
> +        if ( dom >= CONFIG_MAX_DOMID )
>              break;
>          if ( test_and_clear_bit(dom, dom_state_changed) )
>          {
> @@ -823,7 +823,7 @@ struct domain *domain_create(domid_t domid,
>      /* Sort out our idea of is_hardware_domain(). */
>      if ( (flags & CDF_hardware) || domid == hardware_domid )
>      {
> -        if ( hardware_domid < 0 || hardware_domid >= DOMID_FIRST_RESERVED )
> +        if ( hardware_domid < 0 || hardware_domid >= CONFIG_MAX_DOMID )
>              panic("The value of hardware_dom must be a valid domain ID\n");
>  
>          /* late_hwdom is only allowed for dom0. */
> @@ -2413,9 +2413,11 @@ domid_t get_initial_domain_id(void)
>  
>  domid_t domid_alloc(domid_t domid)
>  {
> +    BUILD_BUG_ON(DOMID_FIRST_RESERVED < CONFIG_MAX_DOMID);
> +
>      spin_lock(&domid_lock);
>  
> -    if ( domid < DOMID_FIRST_RESERVED )
> +    if ( domid < CONFIG_MAX_DOMID )
>      {
>          if ( __test_and_set_bit(domid, domid_bitmap) )
>              domid = DOMID_INVALID;
> @@ -2427,13 +2429,13 @@ domid_t domid_alloc(domid_t domid)
>          const domid_t reserved_domid = get_initial_domain_id();
>          const bool reserved = __test_and_set_bit(reserved_domid, domid_bitmap);
>  
> -        domid = find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED,
> +        domid = find_next_zero_bit(domid_bitmap, CONFIG_MAX_DOMID,
>                                     domid_last);
>  
> -        if ( domid == DOMID_FIRST_RESERVED )
> -            domid = find_next_zero_bit(domid_bitmap, DOMID_FIRST_RESERVED, 0);
> +        if ( domid == CONFIG_MAX_DOMID )
> +            domid = find_next_zero_bit(domid_bitmap, CONFIG_MAX_DOMID, 0);
>  
> -        if ( domid == DOMID_FIRST_RESERVED )
> +        if ( domid == CONFIG_MAX_DOMID )
>          {
>              domid = DOMID_INVALID;
>          }
> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
> index 9043414290..f1bfb6f6a2 100644
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -867,7 +867,7 @@ int sched_init_domain(struct domain *d, unsigned int poolid)
>      int ret;
>  
>      ASSERT(d->cpupool == NULL);
> -    ASSERT(d->domain_id < DOMID_FIRST_RESERVED);
> +    ASSERT(d->domain_id < CONFIG_MAX_DOMID);
>  
>      if ( (ret = cpupool_add_domain(d, poolid)) )
>          return ret;
> @@ -891,7 +891,7 @@ int sched_init_domain(struct domain *d, unsigned int poolid)
>  
>  void sched_destroy_domain(struct domain *d)
>  {
> -    ASSERT(d->domain_id < DOMID_FIRST_RESERVED);
> +    ASSERT(d->domain_id < CONFIG_MAX_DOMID);
>  
>      if ( d->cpupool )
>      {
> diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index c55f02c97e..5df85ca629 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1509,7 +1509,7 @@ int domain_context_mapping_one(
>  
>          prev_did = context_domain_id(lctxt);
>          domid = did_to_domain_id(iommu, prev_did);
> -        if ( domid < DOMID_FIRST_RESERVED )
> +        if ( domid < CONFIG_MAX_DOMID )
>              prev_dom = rcu_lock_domain_by_id(domid);
>          else if ( pdev ? domid == pdev->arch.pseudo_domid : domid > DOMID_MASK )
>              prev_dom = rcu_lock_domain(dom_io);
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri May 30 00:31:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 00:31:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000325.1380636 (Exim 4.92)
	(envelope-from )
	id 1uKnea-00027z-16; Fri, 30 May 2025 00:31:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000325.1380636; Fri, 30 May 2025 00:31: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 1uKneZ-00027s-T9; Fri, 30 May 2025 00:31:19 +0000
Received: by outflank-mailman (input) for mailman id 1000325;
 Fri, 30 May 2025 00:31:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKneZ-00027m-61
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 00:31:19 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 66165a4a-3ced-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 02:31:17 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 0ED035C5C5C;
 Fri, 30 May 2025 00:28:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8905C4CEE7;
 Fri, 30 May 2025 00:31: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" 
X-Inumbo-ID: 66165a4a-3ced-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748565074;
	bh=gXMZ2q5QGavScEzwe/E57YBvwBVge8+b+q0afY1rlwY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=GIjwvwzuBGUwlzhZK50sMeRUB29xXX5ccbX63mGV1faOf/oMTBEzCIVTkswNLvpmt
	 Zy6q7f7o3ud3VIzmREPLx9t0UotemhoBhq7EoFyNiXg7R777F/2E7sBf/Pdscu0Fbh
	 D3JUPuBfJWQFLuUPjM3z6utqKVPwFIXUBXIVjl5WNR3FgPM79f/9SzHXZ5Odzho6rY
	 Y1BWUZTtLJ4X9TVwNoKVjQUho3LSjecT7dv9xNWbSlYew50IEcNclOo/fgVTewdpK2
	 buIJtDBLkIuTZzLaFDwMgjfj31Q7kpNC3BJOwmgObV1Mlobmt4zjBU1NLtMoMJSM7Q
	 e+uu31JuJ5frQ==
Date: Thu, 29 May 2025 17:31:11 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Stewart Hildebrand 
cc: xen-devel@lists.xenproject.org, Anthony PERARD , 
    Juergen Gross 
Subject: Re: [PATCH v2 6/6] tools/arm: exclude iomem from domU extended
 regions
In-Reply-To: <20250508132040.532898-7-stewart.hildebrand@amd.com>
Message-ID: 
References: <20250508132040.532898-1-stewart.hildebrand@amd.com> <20250508132040.532898-7-stewart.hildebrand@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 8 May 2025, Stewart Hildebrand wrote:
> When a device is passed through to a xl domU, the iomem ranges may
> overlap with the extended regions. Remove iomem from extended regions.
> 
> Signed-off-by: Stewart Hildebrand 

Reviewed-by: Stefano Stabellini 


> ---
> Not sure if we need a Fixes: tag, but if we do:
> Fixes: 57f87857dc2d ("libxl/arm: Add handling of extended regions for DomU")
> 
> v1->v2:
> * no change
> ---
>  tools/libs/light/libxl_arm.c | 118 +++++++++++++++++++++++++++++------
>  1 file changed, 99 insertions(+), 19 deletions(-)
> 
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index 75c811053c7c..8ae16a1726fc 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -798,6 +798,8 @@ static int make_timer_node(libxl__gc *gc, void *fdt,
>      return 0;
>  }
>  
> +#define MAX_NR_EXT_REGIONS   256
> +
>  static int make_hypervisor_node(libxl__gc *gc, void *fdt,
>                                  const libxl_version_info *vers)
>  {
> @@ -821,7 +823,7 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
>       */
>      res = fdt_property_reg_placeholder(gc, fdt, GUEST_ROOT_ADDRESS_CELLS,
>                                         GUEST_ROOT_SIZE_CELLS,
> -                                       GUEST_RAM_BANKS + 1);
> +                                       MAX_NR_EXT_REGIONS + 1);
>      if (res) return res;
>  
>      /*
> @@ -1517,17 +1519,29 @@ static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname,
>  
>  #define EXT_REGION_MIN_SIZE   xen_mk_ullong(0x0004000000) /* 64MB */
>  
> -static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
> +static int compare_iomem(const void *a, const void *b)
> +{
> +    const libxl_iomem_range *x = a, *y = b;
> +
> +    if (x->gfn < y->gfn)
> +        return -1;
> +    if (x->gfn > y->gfn)
> +        return 1;
> +    return 0;
> +}
> +
> +static int finalize_hypervisor_node(libxl__gc *gc,
> +                                    libxl_domain_build_info *b_info,
> +                                    struct xc_dom_image *dom)
>  {
>      void *fdt = dom->devicetree_blob;
> -    uint64_t region_size[GUEST_RAM_BANKS] = {0}, region_base[GUEST_RAM_BANKS],
> -        bankend[GUEST_RAM_BANKS];
> +    uint64_t region_base[MAX_NR_EXT_REGIONS], region_size[MAX_NR_EXT_REGIONS];
>      uint32_t regs[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) *
> -                  (GUEST_RAM_BANKS + 1)];
> +                  (MAX_NR_EXT_REGIONS + 1)];
>      be32 *cells = ®s[0];
>      const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
>      const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
> -    unsigned int i, len, nr_regions = 0;
> +    unsigned int i, j, len, nr_regions = 0;
>      libxl_dominfo info;
>      int offset, rc;
>  
> @@ -1542,20 +1556,90 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
>      if (info.gpaddr_bits > 64)
>          return ERROR_INVAL;
>  
> +    qsort(b_info->iomem, b_info->num_iomem, sizeof(libxl_iomem_range),
> +          compare_iomem);
> +
>      /*
>       * Try to allocate separate 2MB-aligned extended regions from the first
>       * and second RAM banks taking into the account the maximum supported
>       * guest physical address space size and the amount of memory assigned
>       * to the guest.
>       */
> -    for (i = 0; i < GUEST_RAM_BANKS; i++) {
> -        region_base[i] = bankbase[i] +
> +    for (i = 0; i < GUEST_RAM_BANKS && nr_regions < MAX_NR_EXT_REGIONS; i++) {
> +        struct {
> +            uint64_t start;
> +            uint64_t end; /* inclusive */
> +        } unallocated;
> +        uint64_t size = 0;
> +
> +        unallocated.start = bankbase[i] +
>              ALIGN_UP_TO_2MB((uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT);
>  
> -        bankend[i] = ~0ULL >> (64 - info.gpaddr_bits);
> -        bankend[i] = min(bankend[i], bankbase[i] + banksize[i] - 1);
> -        if (bankend[i] > region_base[i])
> -            region_size[i] = bankend[i] - region_base[i] + 1;
> +        unallocated.end = ~0ULL >> (64 - info.gpaddr_bits);
> +        unallocated.end = min(unallocated.end, bankbase[i] + banksize[i] - 1);
> +
> +        if (unallocated.end > unallocated.start)
> +            size = unallocated.end - unallocated.start + 1;
> +
> +        if (size < EXT_REGION_MIN_SIZE)
> +            continue;
> +
> +        /* Exclude iomem */
> +        for (j = 0; j < b_info->num_iomem && nr_regions < MAX_NR_EXT_REGIONS;
> +             j++) {
> +            struct {
> +                uint64_t start;
> +                uint64_t end; /* inclusive */
> +            } iomem;
> +
> +            iomem.start = b_info->iomem[j].gfn << XC_PAGE_SHIFT;
> +            iomem.end = ((b_info->iomem[j].gfn + b_info->iomem[j].number)
> +                         << XC_PAGE_SHIFT) - 1;
> +
> +            if (iomem.end >= unallocated.start
> +                && iomem.start <= unallocated.end) {
> +
> +                if (iomem.start <= unallocated.start) {
> +                    unallocated.start = iomem.end + 1;
> +
> +                    if (iomem.end >= unallocated.end)
> +                        /* Complete overlap, discard unallocated region */
> +                        break;
> +
> +                    /* Beginning overlap */
> +                    continue;
> +                }
> +
> +                if (iomem.start > unallocated.start) {
> +                    assert(unallocated.end > unallocated.start);
> +                    size = iomem.start - unallocated.start;
> +
> +                    if (size >= EXT_REGION_MIN_SIZE) {
> +                        region_base[nr_regions] = unallocated.start;
> +                        region_size[nr_regions] = size;
> +                        nr_regions++;
> +                    }
> +
> +                    unallocated.start = iomem.end + 1;
> +
> +                    if (iomem.end >= unallocated.end)
> +                        /* End overlap, discard remaining unallocated region */
> +                        break;
> +                }
> +            }
> +        }
> +
> +        if (unallocated.end > unallocated.start
> +            && nr_regions < MAX_NR_EXT_REGIONS)
> +        {
> +            size = unallocated.end - unallocated.start + 1;
> +
> +            if (size >= EXT_REGION_MIN_SIZE) {
> +                region_base[nr_regions] = unallocated.start;
> +                region_size[nr_regions] = size;
> +                nr_regions++;
> +            }
> +        }
>      }
>  
>      /*
> @@ -1565,16 +1649,12 @@ static int finalize_hypervisor_node(libxl__gc *gc, struct xc_dom_image *dom)
>      set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
>                GUEST_GNTTAB_BASE, GUEST_GNTTAB_SIZE);
>  
> -    for (i = 0; i < GUEST_RAM_BANKS; i++) {
> -        if (region_size[i] < EXT_REGION_MIN_SIZE)
> -            continue;
> -
> +    for (i = 0; i < nr_regions; i++) {
>          LOG(DEBUG, "Extended region %u: %#"PRIx64"->%#"PRIx64"",
> -            nr_regions, region_base[i], region_base[i] + region_size[i]);
> +            i, region_base[i], region_base[i] + region_size[i]);
>  
>          set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
>                    region_base[i], region_size[i]);
> -        nr_regions++;
>      }
>  
>      if (!nr_regions)
> @@ -1626,7 +1706,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
>  
>      }
>  
> -    res = finalize_hypervisor_node(gc, dom);
> +    res = finalize_hypervisor_node(gc, &d_config->b_info, dom);
>      if (res)
>          return res;
>  
> -- 
> 2.49.0
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri May 30 00:58:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 00:58:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000334.1380647 (Exim 4.92)
	(envelope-from )
	id 1uKo4X-00054U-2D; Fri, 30 May 2025 00:58:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000334.1380647; Fri, 30 May 2025 00:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKo4W-00054N-Tx; Fri, 30 May 2025 00:58:08 +0000
Received: by outflank-mailman (input) for mailman id 1000334;
 Fri, 30 May 2025 00:58:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKo4V-00054H-MG
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 00:58:07 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 24a8c7ac-3cf1-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 02:58:05 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 3713560010;
 Fri, 30 May 2025 00:58:04 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5651C4CEE7;
 Fri, 30 May 2025 00:58: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" 
X-Inumbo-ID: 24a8c7ac-3cf1-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748566683;
	bh=sjXzh/yTT6qQS9h48xgcDoW1vrlKnZoqiUhBQkmDgWQ=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=PFTPYANfcAGwDC8jg5EeSQNPSpPW1jLSJnc63g4Yfmo83pt9vQ4zVjiAet3je+Ucx
	 9vKfFap4ldxZ2du/JnEwj/5zEBdrEj3IsT7yJ59pOpahG7IeBwWcYJLxmuz4/ZwVIs
	 S+VpTfDp4pdkV/znEKTkMJclQpWPRTKT7k1Aqw6Jpl/Q6CMo7EyOHMOBUmNkBc6W89
	 zXAQ7B0/4ho7goT8KQkUWldaq13HoaEhatuW+OXD2ZJ4IQXrOVQopXZmyD68++bqO5
	 7g4sbYy3hfOeIsYi6mcpoCNJrEameAItwIQhefMUCh5xfJLYS5tOuFd5FsaWRWL0lq
	 nnQq76wu4RWcQ==
Date: Thu, 29 May 2025 17:58:00 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Denis Mukhin 
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com
Subject: Re: [PATCH v4 2/4] xen/console: introduce console input permission
In-Reply-To: <20250529000848.2675903-3-dmukhin@ford.com>
Message-ID: 
References: <20250529000848.2675903-1-dmukhin@ford.com> <20250529000848.2675903-3-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 29 May 2025, dmkhn@proton.me wrote:
> Add new flag to domain structure for marking permission to intercept
> the physical console input by the domain.
> 
> Update console input switch logic accordingly.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v3:
> - rebased
> ---
>  xen/arch/arm/vpl011.c      |  2 ++
>  xen/arch/x86/pv/shim.c     |  2 ++
>  xen/common/domain.c        |  2 ++
>  xen/drivers/char/console.c | 18 +++++++++++++++++-
>  xen/include/xen/sched.h    |  8 +++++++-
>  5 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 66047bf33c..147958eee8 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -737,6 +737,8 @@ int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
>      register_mmio_handler(d, &vpl011_mmio_handler,
>                            vpl011->base_addr, GUEST_PL011_SIZE, NULL);
>  
> +    d->console.input_allowed = true;

This should be set only when backend_in_domain = false.


>      return 0;
>  
>  out1:
> diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
> index c506cc0bec..bc2a7dd5fa 100644
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -238,6 +238,8 @@ void __init pv_shim_setup_dom(struct domain *d, l4_pgentry_t *l4start,
>       * guest from depleting the shim memory pool.
>       */
>      d->max_pages = domain_tot_pages(d);
> +
> +    d->console.input_allowed = true;
>  }
>  
>  static void write_start_info(struct domain *d)
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 87e5be35e5..9bc66d80c4 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -835,6 +835,8 @@ struct domain *domain_create(domid_t domid,
>          flags |= CDF_hardware;
>          if ( old_hwdom )
>              old_hwdom->cdf &= ~CDF_hardware;
> +
> +        d->console.input_allowed = true;
>      }
>  
>      /* Holding CDF_* internal flags. */
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 30701ae0b0..8a0bcff78f 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -512,9 +512,21 @@ static unsigned int __read_mostly console_rx = 0;
>  
>  struct domain *console_get_domain(void)
>  {
> +    struct domain *d;
> +
>      if ( console_rx == 0 )
>              return NULL;
> -    return rcu_lock_domain_by_id(console_rx - 1);
> +
> +    d = rcu_lock_domain_by_id(console_rx - 1);
> +    if ( !d )
> +        return NULL;
> +
> +    if ( d->console.input_allowed )
> +        return d;
> +
> +    rcu_unlock_domain(d);
> +
> +    return NULL;

The original idea was to skip over domains that cannot have any input so
I don't think we should get in this situation. We could even have an
assert.


>  }
>  
>  void console_put_domain(struct domain *d)
> @@ -551,6 +563,10 @@ static void console_switch_input(void)
>          if ( d )
>          {
>              rcu_unlock_domain(d);
> +
> +            if ( !d->console.input_allowed )
> +                break;

shouldn't this be continue instead of break?


>              console_rx = next_rx;
>              printk("*** Serial input to DOM%u", domid);
>              break;
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 559d201e0c..e91c99a8f3 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -512,7 +512,7 @@ struct domain
>      bool             auto_node_affinity;
>      /* Is this guest fully privileged (aka dom0)? */
>      bool             is_privileged;
> -    /* Can this guest access the Xen console? */
> +    /* XSM: permission to use HYPERCALL_console_io hypercall */
>      bool             is_console;

While I am in favor of this direction and we certainly need a better way
to distinguish domains that can use HYPERCALL_console_io hypercall from
others, could we simplify this and just assume that "is_console" implies
input_allowed and also set is_console = true in all the same places you
are setting input_allowed = true in this patch?

For clarity, I am suggesting:
- do not add input_allowed
- set is_console = true in domain_vpl011_init, pv_shim_setup_dom, etc.

The only side effect is that we would allow domains with vpl011 to also
use console hypercalls but I don't think there is any harm in that?

I don't feel strongly about this, I am just trying to find ways to make
things simple. I apologize if it was already discussed during review of
one of the previous versions.

I am also OK with this approach.


>      /* Is this guest being debugged by dom0? */
>      bool             debugger_attached;
> @@ -651,6 +651,12 @@ struct domain
>      unsigned int num_llc_colors;
>      const unsigned int *llc_colors;
>  #endif
> +
> +    /* Console settings. */
> +    struct {
> +        /* Permission to take ownership of the physical console input. */
> +        bool input_allowed;
> +    } console;
>  } __aligned(PAGE_SIZE);
>  
>  static inline struct page_list_head *page_to_list(
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri May 30 00:58:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 00:58:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000336.1380656 (Exim 4.92)
	(envelope-from )
	id 1uKo4t-0005Qc-9A; Fri, 30 May 2025 00:58:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000336.1380656; Fri, 30 May 2025 00: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 1uKo4t-0005Py-5T; Fri, 30 May 2025 00:58:31 +0000
Received: by outflank-mailman (input) for mailman id 1000336;
 Fri, 30 May 2025 00:58:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKo4r-00054H-OT
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 00:58:29 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org
 [2600:3c0a:e001:78e:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 30d3330f-3cf1-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 02:58:26 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 97763441EA;
 Fri, 30 May 2025 00:58:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25DA2C4CEE7;
 Fri, 30 May 2025 00:58: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" 
X-Inumbo-ID: 30d3330f-3cf1-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748566704;
	bh=zR4BaCfK1JeMkc6GTTMrN9JPYU0BYycBOzmB50UT4Rw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ZuRWazspQiwWekoqenx+67bg1gjb+hroqikxGogGxBNR7lxbhUS8kyIBv+na0dOSz
	 p3UuE2oOsxIYPBgBZnYZGpIl/ylN7rO0FHueuX9W8Y3wD45Mr8oOC6zb9iTAmw00M+
	 ZQ5rGlhJNVxHgz9H1sXmfz5l6fYjOifkAwGLsXzjrVDZBWSJ5Dn2+nwPzXS5J+kNjQ
	 R2cqoTjAw0iX7DJubGE6Bgv9Aod3hfRvP1t5iYsAAFHTiH2R9RxbMAomliqdBnwmT6
	 SrySb0A7LJbIuMqwMl4pOSUj+VeBYObqVcT+Yyu7r6SmYSSLlNAv1mfKLTh0s5kwDe
	 gJ35jxIVRChsg==
Date: Thu, 29 May 2025 17:58:20 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Denis Mukhin 
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, 
    dmukhin@ford.com
Subject: Re: [PATCH v4 3/4] xen/console: remove max_init_domid dependency
In-Reply-To: <20250529000848.2675903-4-dmukhin@ford.com>
Message-ID: 
References: <20250529000848.2675903-1-dmukhin@ford.com> <20250529000848.2675903-4-dmukhin@ford.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 29 May 2025, dmkhn@proton.me wrote:
> From: Denis Mukhin 
> 
> From: Denis Mukhin 
> 
> The physical console input rotation depends on max_init_domid symbol, which is
> managed differently across architectures.
> 
> Instead of trying to manage max_init_domid in the arch-common code the console
> input rotation code can be reworked by removing dependency on max_init_domid
> entirely.
> 
> To do that, introduce domid_find_with_input_allowed() in arch-independent
> location to find the ID of the next possible console owner domain. The IDs
> are rotated across non-system domain IDs and DOMID_XEN.
> 
> Also, introduce helper console_set_domid() for updating identifier of the
> current console input owner (points to Xen or domain).
> 
> Use domid_find_with_input_allowed() and console_set_domid() in
> console_switch_input().
> 
> Remove uses of max_init_domid in the code.
> 
> Signed-off-by: Denis Mukhin 
> ---
> Changes since v3:
> - switched to RCU lock in domid_find_with_input_allowed()
> ---
>  xen/arch/arm/include/asm/setup.h        |  2 -
>  xen/arch/arm/setup.c                    |  2 -
>  xen/arch/ppc/include/asm/setup.h        |  2 -
>  xen/arch/riscv/include/asm/setup.h      |  2 -
>  xen/arch/x86/include/asm/setup.h        |  2 -
>  xen/common/device-tree/dom0less-build.c |  2 -
>  xen/common/domain.c                     | 29 ++++++++
>  xen/drivers/char/console.c              | 90 +++++++++----------------
>  xen/include/xen/domain.h                |  1 +
>  9 files changed, 61 insertions(+), 71 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 6cf272c160..f107e8eebb 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -25,8 +25,6 @@ struct map_range_data
>      struct rangeset *irq_ranges;
>  };
>  
> -extern domid_t max_init_domid;
> -
>  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
>  
>  size_t estimate_efi_size(unsigned int mem_nr_banks);
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 10b46d0684..53e2f8b537 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -61,8 +61,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
>  bool __read_mostly acpi_disabled;
>  #endif
>  
> -domid_t __read_mostly max_init_domid;
> -
>  static __used void init_done(void)
>  {
>      int rc;
> diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h
> index e4f64879b6..956fa6985a 100644
> --- a/xen/arch/ppc/include/asm/setup.h
> +++ b/xen/arch/ppc/include/asm/setup.h
> @@ -1,6 +1,4 @@
>  #ifndef __ASM_PPC_SETUP_H__
>  #define __ASM_PPC_SETUP_H__
>  
> -#define max_init_domid (0)
> -
>  #endif /* __ASM_PPC_SETUP_H__ */
> diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h
> index c9d69cdf51..d1fc64b673 100644
> --- a/xen/arch/riscv/include/asm/setup.h
> +++ b/xen/arch/riscv/include/asm/setup.h
> @@ -5,8 +5,6 @@
>  
>  #include 
>  
> -#define max_init_domid (0)
> -
>  void setup_mm(void);
>  
>  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
> index ac34c69855..b67de8577f 100644
> --- a/xen/arch/x86/include/asm/setup.h
> +++ b/xen/arch/x86/include/asm/setup.h
> @@ -69,6 +69,4 @@ extern bool opt_dom0_verbose;
>  extern bool opt_dom0_cpuid_faulting;
>  extern bool opt_dom0_msr_relaxed;
>  
> -#define max_init_domid (0)
> -
>  #endif
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 9a6015f4ce..703f20faed 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -977,8 +977,6 @@ void __init create_domUs(void)
>          domid = domid_alloc(DOMID_INVALID);
>          if ( domid == DOMID_INVALID )
>              panic("Error allocating ID for domain %s\n", dt_node_name(node));
> -        if ( max_init_domid < domid )
> -            max_init_domid = domid;
>  
>          d = domain_create(domid, &d_cfg, flags);
>          if ( IS_ERR(d) )
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 9bc66d80c4..704e0907e9 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -2463,6 +2463,35 @@ void domid_free(domid_t domid)
>      spin_unlock(&domid_lock);
>  }
>  
> +/*
> + * Find the ID of the next possible console owner domain.
> + *
> + * @return Domain ID: DOMID_XEN or non-system domain IDs within
> + * the range of [0..DOMID_FIRST_RESERVED-1].
> + */
> +domid_t domid_find_with_input_allowed(domid_t hint)
> +{
> +    const struct domain *d;
> +    domid_t domid = DOMID_XEN;
> +
> +    rcu_read_lock(&domlist_read_lock);
> +
> +    for ( d = rcu_dereference(domain_list);
> +          d && d->domain_id < DOMID_FIRST_RESERVED;
> +          d = rcu_dereference(d->next_in_list) )
> +    {
> +        if ( d->console.input_allowed )
> +        {
> +            domid = d->domain_id;
> +            break;
> +        }
> +    }
> +
> +    rcu_read_unlock(&domlist_read_lock);

Doesn't this always return the first domid with input_allowed given that
hint is not used? It looks like it wouldn't work right...


> +    return domid;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 8a0bcff78f..37289d5558 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -498,26 +498,17 @@ static void cf_check conring_dump_keyhandler(unsigned char key)
>  
>  /*
>   * CTRL- changes input direction, rotating among Xen, Dom0,
> - * and the DomUs started from Xen at boot.
> + * and the DomUs.
>   */
>  #define switch_code (opt_conswitch[0]-'a'+1)
> -/*
> - * console_rx=0 => input to xen
> - * console_rx=1 => input to dom0 (or the sole shim domain)
> - * console_rx=N => input to dom(N-1)
> - */
> -static unsigned int __read_mostly console_rx = 0;
>  
> -#define max_console_rx (max_init_domid + 1)
> +/* Console owner domain identifier. */
> +static domid_t __read_mostly console_rx = DOMID_XEN;
>  
>  struct domain *console_get_domain(void)
>  {
> -    struct domain *d;
> +    struct domain *d = rcu_lock_domain_by_id(console_rx);
>  
> -    if ( console_rx == 0 )
> -            return NULL;
> -
> -    d = rcu_lock_domain_by_id(console_rx - 1);
>      if ( !d )
>          return NULL;
>  
> @@ -535,43 +526,14 @@ void console_put_domain(struct domain *d)
>          rcu_unlock_domain(d);
>  }
>  
> -static void console_switch_input(void)
> +static void console_set_domid(domid_t domid)
>  {
> -    unsigned int next_rx = console_rx;
> +    if ( domid == DOMID_XEN )
> +        printk("*** Serial input to Xen");
> +    else
> +        printk("*** Serial input to DOM%u", domid);
>  
> -    /*
> -     * Rotate among Xen, dom0 and boot-time created domUs while skipping
> -     * switching serial input to non existing domains.
> -     */
> -    for ( ; ; )
> -    {
> -        domid_t domid;
> -        struct domain *d;
> -
> -        if ( next_rx++ >= max_console_rx )
> -        {
> -            console_rx = 0;
> -            printk("*** Serial input to Xen");
> -            break;
> -        }
> -
> -        if ( consoled_is_enabled() && next_rx == 1 )
> -            domid = get_initial_domain_id();
> -        else
> -            domid = next_rx - 1;
> -        d = rcu_lock_domain_by_id(domid);
> -        if ( d )
> -        {
> -            rcu_unlock_domain(d);
> -
> -            if ( !d->console.input_allowed )
> -                break;
> -
> -            console_rx = next_rx;
> -            printk("*** Serial input to DOM%u", domid);
> -            break;
> -        }
> -    }
> +    console_rx = domid;
>  
>      if ( switch_code )
>          printk(" (type 'CTRL-%c' three times to switch input)",
> @@ -579,12 +541,30 @@ static void console_switch_input(void)
>      printk("\n");
>  }
>  
> +/*
> + * Switch console focus.
> + * Rotates input focus among Xen and domains with console input permission.
> + */
> +static void console_switch_input(void)
> +{
> +    domid_t hint;
> +
> +    if ( console_rx == DOMID_XEN )
> +        hint = get_initial_domain_id();
> +    else
> +        hint = console_rx + 1;
> +
> +    hint = domid_find_with_input_allowed(hint);
> +
> +    console_set_domid(hint);
> +}
> +
>  static void __serial_rx(char c)
>  {
>      struct domain *d;
>      int rc = 0;
>  
> -    if ( console_rx == 0 )
> +    if ( console_rx == DOMID_XEN )
>          return handle_keypress(c, false);
>  
>      d = console_get_domain();
> @@ -1169,14 +1149,6 @@ void __init console_endboot(void)
>  
>      video_endboot();
>  
> -    /*
> -     * If user specifies so, we fool the switch routine to redirect input
> -     * straight back to Xen. I use this convoluted method so we still print
> -     * a useful 'how to switch' message.
> -     */
> -    if ( opt_conswitch[1] == 'x' )
> -        console_rx = max_console_rx;
> -
>      register_keyhandler('w', conring_dump_keyhandler,
>                          "synchronously dump console ring buffer (dmesg)", 0);
>      register_irq_keyhandler('+', &do_inc_thresh,
> @@ -1186,8 +1158,8 @@ void __init console_endboot(void)
>      register_irq_keyhandler('G', &do_toggle_guest,
>                              "toggle host/guest log level adjustment", 0);
>  
> -    /* Serial input is directed to DOM0 by default. */
> -    console_switch_input();
> +    if ( opt_conswitch[1] != 'x' )
> +        (void)console_set_domid(get_initial_domain_id());

We should use domid_find_with_input_allowed instead of assuming
get_initial_domain_id() has input_allowed? 



>  }
>  
>  int __init console_has(const char *device)
> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> index 8aab05ae93..a88eb34f3f 100644
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -36,6 +36,7 @@ void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info);
>  void arch_get_domain_info(const struct domain *d,
>                            struct xen_domctl_getdomaininfo *info);
>  
> +domid_t domid_find_with_input_allowed(domid_t hint);
>  domid_t get_initial_domain_id(void);
>  
>  domid_t domid_alloc(domid_t domid);
> -- 
> 2.34.1
> 
> 


From xen-devel-bounces@lists.xenproject.org Fri May 30 01:17:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 01:17:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000361.1380666 (Exim 4.92)
	(envelope-from )
	id 1uKoMp-0007uM-L6; Fri, 30 May 2025 01:17:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000361.1380666; Fri, 30 May 2025 01:17: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 1uKoMp-0007uF-IG; Fri, 30 May 2025 01:17:03 +0000
Received: by outflank-mailman (input) for mailman id 1000361;
 Fri, 30 May 2025 01:17:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKoMm-0007u9-H7
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 01:17:01 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c131ec8d-3cf3-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 03:16: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" 
X-Inumbo-ID: c131ec8d-3cf3-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748567805; x=1748827005;
	bh=/Nug7TG9pX/iSMIVDWy4Lt3REu2beWw6Avvv457UtbE=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=HTD5Wf9nj5lW0IZPdzNbmWqVMjlafr3OkgP2K+ZJj2P1Rh4l4AXPoC73GmXnprxEm
	 Olrj2niWhhGatcWLvRbx65tX1vcNcfbNgtNEVlsL0d2XXU/ZnPBI3uBhCQQYjg5dW0
	 DB77C1E30S9qs8rbrhTHot9bzpI0UW+CpXfh6Qq83bICy5lsOdFA7no5GoAH2gjSLQ
	 a7RFprY/BKvIxnv4J/vpjAptrX7XzsVr8KSs2zZFhxIIdnRAVN227XIdrPcwSlpoj+
	 dE33PgFNl6zVsQV7U5MBWeysP5Y/AA1DG18nR+MvS9OVR7EvvxIrkzrnklwQmlyh8A
	 lnENfWhfjlHPw==
Date: Fri, 30 May 2025 01:16:41 +0000
To: Stefano Stabellini 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com
Subject: Re: [PATCH v4 3/4] xen/console: remove max_init_domid dependency
Message-ID: 
In-Reply-To: 
References: <20250529000848.2675903-1-dmukhin@ford.com> <20250529000848.2675903-4-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 00756799dff15edf3a78d3a53471a8340510000e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 29, 2025 at 05:58:20PM -0700, Stefano Stabellini wrote:
> On Thu, 29 May 2025, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > From: Denis Mukhin 
> >
> > The physical console input rotation depends on max_init_domid symbol, w=
hich is
> > managed differently across architectures.
> >
> > Instead of trying to manage max_init_domid in the arch-common code the =
console
> > input rotation code can be reworked by removing dependency on max_init_=
domid
> > entirely.
> >
> > To do that, introduce domid_find_with_input_allowed() in arch-independe=
nt
> > location to find the ID of the next possible console owner domain. The =
IDs
> > are rotated across non-system domain IDs and DOMID_XEN.
> >
> > Also, introduce helper console_set_domid() for updating identifier of t=
he
> > current console input owner (points to Xen or domain).
> >
> > Use domid_find_with_input_allowed() and console_set_domid() in
> > console_switch_input().
> >
> > Remove uses of max_init_domid in the code.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v3:
> > - switched to RCU lock in domid_find_with_input_allowed()
> > ---
> >  xen/arch/arm/include/asm/setup.h        |  2 -
> >  xen/arch/arm/setup.c                    |  2 -
> >  xen/arch/ppc/include/asm/setup.h        |  2 -
> >  xen/arch/riscv/include/asm/setup.h      |  2 -
> >  xen/arch/x86/include/asm/setup.h        |  2 -
> >  xen/common/device-tree/dom0less-build.c |  2 -
> >  xen/common/domain.c                     | 29 ++++++++
> >  xen/drivers/char/console.c              | 90 +++++++++----------------
> >  xen/include/xen/domain.h                |  1 +
> >  9 files changed, 61 insertions(+), 71 deletions(-)
> >
> > diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/as=
m/setup.h
> > index 6cf272c160..f107e8eebb 100644
> > --- a/xen/arch/arm/include/asm/setup.h
> > +++ b/xen/arch/arm/include/asm/setup.h
> > @@ -25,8 +25,6 @@ struct map_range_data
> >      struct rangeset *irq_ranges;
> >  };
> >
> > -extern domid_t max_init_domid;
> > -
> >  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> >
> >  size_t estimate_efi_size(unsigned int mem_nr_banks);
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 10b46d0684..53e2f8b537 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -61,8 +61,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
> >  bool __read_mostly acpi_disabled;
> >  #endif
> >
> > -domid_t __read_mostly max_init_domid;
> > -
> >  static __used void init_done(void)
> >  {
> >      int rc;
> > diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/as=
m/setup.h
> > index e4f64879b6..956fa6985a 100644
> > --- a/xen/arch/ppc/include/asm/setup.h
> > +++ b/xen/arch/ppc/include/asm/setup.h
> > @@ -1,6 +1,4 @@
> >  #ifndef __ASM_PPC_SETUP_H__
> >  #define __ASM_PPC_SETUP_H__
> >
> > -#define max_init_domid (0)
> > -
> >  #endif /* __ASM_PPC_SETUP_H__ */
> > diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/includ=
e/asm/setup.h
> > index c9d69cdf51..d1fc64b673 100644
> > --- a/xen/arch/riscv/include/asm/setup.h
> > +++ b/xen/arch/riscv/include/asm/setup.h
> > @@ -5,8 +5,6 @@
> >
> >  #include 
> >
> > -#define max_init_domid (0)
> > -
> >  void setup_mm(void);
> >
> >  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> > diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/as=
m/setup.h
> > index ac34c69855..b67de8577f 100644
> > --- a/xen/arch/x86/include/asm/setup.h
> > +++ b/xen/arch/x86/include/asm/setup.h
> > @@ -69,6 +69,4 @@ extern bool opt_dom0_verbose;
> >  extern bool opt_dom0_cpuid_faulting;
> >  extern bool opt_dom0_msr_relaxed;
> >
> > -#define max_init_domid (0)
> > -
> >  #endif
> > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/devic=
e-tree/dom0less-build.c
> > index 9a6015f4ce..703f20faed 100644
> > --- a/xen/common/device-tree/dom0less-build.c
> > +++ b/xen/common/device-tree/dom0less-build.c
> > @@ -977,8 +977,6 @@ void __init create_domUs(void)
> >          domid =3D domid_alloc(DOMID_INVALID);
> >          if ( domid =3D=3D DOMID_INVALID )
> >              panic("Error allocating ID for domain %s\n", dt_node_name(=
node));
> > -        if ( max_init_domid < domid )
> > -            max_init_domid =3D domid;
> >
> >          d =3D domain_create(domid, &d_cfg, flags);
> >          if ( IS_ERR(d) )
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 9bc66d80c4..704e0907e9 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -2463,6 +2463,35 @@ void domid_free(domid_t domid)
> >      spin_unlock(&domid_lock);
> >  }
> >
> > +/*
> > + * Find the ID of the next possible console owner domain.
> > + *
> > + * @return Domain ID: DOMID_XEN or non-system domain IDs within
> > + * the range of [0..DOMID_FIRST_RESERVED-1].
> > + */
> > +domid_t domid_find_with_input_allowed(domid_t hint)
> > +{
> > +    const struct domain *d;
> > +    domid_t domid =3D DOMID_XEN;
> > +
> > +    rcu_read_lock(&domlist_read_lock);
> > +
> > +    for ( d =3D rcu_dereference(domain_list);
> > +          d && d->domain_id < DOMID_FIRST_RESERVED;
> > +          d =3D rcu_dereference(d->next_in_list) )
> > +    {
> > +        if ( d->console.input_allowed )
> > +        {
> > +            domid =3D d->domain_id;
> > +            break;
> > +        }
> > +    }
> > +
> > +    rcu_read_unlock(&domlist_read_lock);
>=20
> Doesn't this always return the first domid with input_allowed given that
> hint is not used? It looks like it wouldn't work right...

Yes, that will not work.
Looks like I posted the series from the wrong local branch.
Will update.

Thanks!

>=20
>=20
> > +    return domid;
> > +}
> > +
> >  /*
> >   * Local variables:
> >   * mode: C
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 8a0bcff78f..37289d5558 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -498,26 +498,17 @@ static void cf_check conring_dump_keyhandler(unsi=
gned char key)
> >
> >  /*
> >   * CTRL- changes input direction, rotating among Xen, Dom=
0,
> > - * and the DomUs started from Xen at boot.
> > + * and the DomUs.
> >   */
> >  #define switch_code (opt_conswitch[0]-'a'+1)
> > -/*
> > - * console_rx=3D0 =3D> input to xen
> > - * console_rx=3D1 =3D> input to dom0 (or the sole shim domain)
> > - * console_rx=3DN =3D> input to dom(N-1)
> > - */
> > -static unsigned int __read_mostly console_rx =3D 0;
> >
> > -#define max_console_rx (max_init_domid + 1)
> > +/* Console owner domain identifier. */
> > +static domid_t __read_mostly console_rx =3D DOMID_XEN;
> >
> >  struct domain *console_get_domain(void)
> >  {
> > -    struct domain *d;
> > +    struct domain *d =3D rcu_lock_domain_by_id(console_rx);
> >
> > -    if ( console_rx =3D=3D 0 )
> > -            return NULL;
> > -
> > -    d =3D rcu_lock_domain_by_id(console_rx - 1);
> >      if ( !d )
> >          return NULL;
> >
> > @@ -535,43 +526,14 @@ void console_put_domain(struct domain *d)
> >          rcu_unlock_domain(d);
> >  }
> >
> > -static void console_switch_input(void)
> > +static void console_set_domid(domid_t domid)
> >  {
> > -    unsigned int next_rx =3D console_rx;
> > +    if ( domid =3D=3D DOMID_XEN )
> > +        printk("*** Serial input to Xen");
> > +    else
> > +        printk("*** Serial input to DOM%u", domid);
> >
> > -    /*
> > -     * Rotate among Xen, dom0 and boot-time created domUs while skippi=
ng
> > -     * switching serial input to non existing domains.
> > -     */
> > -    for ( ; ; )
> > -    {
> > -        domid_t domid;
> > -        struct domain *d;
> > -
> > -        if ( next_rx++ >=3D max_console_rx )
> > -        {
> > -            console_rx =3D 0;
> > -            printk("*** Serial input to Xen");
> > -            break;
> > -        }
> > -
> > -        if ( consoled_is_enabled() && next_rx =3D=3D 1 )
> > -            domid =3D get_initial_domain_id();
> > -        else
> > -            domid =3D next_rx - 1;
> > -        d =3D rcu_lock_domain_by_id(domid);
> > -        if ( d )
> > -        {
> > -            rcu_unlock_domain(d);
> > -
> > -            if ( !d->console.input_allowed )
> > -                break;
> > -
> > -            console_rx =3D next_rx;
> > -            printk("*** Serial input to DOM%u", domid);
> > -            break;
> > -        }
> > -    }
> > +    console_rx =3D domid;
> >
> >      if ( switch_code )
> >          printk(" (type 'CTRL-%c' three times to switch input)",
> > @@ -579,12 +541,30 @@ static void console_switch_input(void)
> >      printk("\n");
> >  }
> >
> > +/*
> > + * Switch console focus.
> > + * Rotates input focus among Xen and domains with console input permis=
sion.
> > + */
> > +static void console_switch_input(void)
> > +{
> > +    domid_t hint;
> > +
> > +    if ( console_rx =3D=3D DOMID_XEN )
> > +        hint =3D get_initial_domain_id();
> > +    else
> > +        hint =3D console_rx + 1;
> > +
> > +    hint =3D domid_find_with_input_allowed(hint);
> > +
> > +    console_set_domid(hint);
> > +}
> > +
> >  static void __serial_rx(char c)
> >  {
> >      struct domain *d;
> >      int rc =3D 0;
> >
> > -    if ( console_rx =3D=3D 0 )
> > +    if ( console_rx =3D=3D DOMID_XEN )
> >          return handle_keypress(c, false);
> >
> >      d =3D console_get_domain();
> > @@ -1169,14 +1149,6 @@ void __init console_endboot(void)
> >
> >      video_endboot();
> >
> > -    /*
> > -     * If user specifies so, we fool the switch routine to redirect in=
put
> > -     * straight back to Xen. I use this convoluted method so we still =
print
> > -     * a useful 'how to switch' message.
> > -     */
> > -    if ( opt_conswitch[1] =3D=3D 'x' )
> > -        console_rx =3D max_console_rx;
> > -
> >      register_keyhandler('w', conring_dump_keyhandler,
> >                          "synchronously dump console ring buffer (dmesg=
)", 0);
> >      register_irq_keyhandler('+', &do_inc_thresh,
> > @@ -1186,8 +1158,8 @@ void __init console_endboot(void)
> >      register_irq_keyhandler('G', &do_toggle_guest,
> >                              "toggle host/guest log level adjustment", =
0);
> >
> > -    /* Serial input is directed to DOM0 by default. */
> > -    console_switch_input();
> > +    if ( opt_conswitch[1] !=3D 'x' )
> > +        (void)console_set_domid(get_initial_domain_id());
>=20
> We should use domid_find_with_input_allowed instead of assuming
> get_initial_domain_id() has input_allowed?
>=20
>=20
>=20
> >  }
> >
> >  int __init console_has(const char *device)
> > diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> > index 8aab05ae93..a88eb34f3f 100644
> > --- a/xen/include/xen/domain.h
> > +++ b/xen/include/xen/domain.h
> > @@ -36,6 +36,7 @@ void getdomaininfo(struct domain *d, struct xen_domct=
l_getdomaininfo *info);
> >  void arch_get_domain_info(const struct domain *d,
> >                            struct xen_domctl_getdomaininfo *info);
> >
> > +domid_t domid_find_with_input_allowed(domid_t hint);
> >  domid_t get_initial_domain_id(void);
> >
> >  domid_t domid_alloc(domid_t domid);
> > --
> > 2.34.1
> >
> >
>=20



From xen-devel-bounces@lists.xenproject.org Fri May 30 01:36:59 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 01:36:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000370.1380676 (Exim 4.92)
	(envelope-from )
	id 1uKofv-0002EU-2y; Fri, 30 May 2025 01:36:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000370.1380676; Fri, 30 May 2025 01: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 1uKofu-0002EN-Vx; Fri, 30 May 2025 01:36:46 +0000
Received: by outflank-mailman (input) for mailman id 1000370;
 Fri, 30 May 2025 01:36:46 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uKofu-0002EH-Ep
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 01:36:46 +0000
Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch
 [109.224.244.18]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8a87df89-3cf6-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 03:36: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" 
X-Inumbo-ID: 8a87df89-3cf6-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748569001; x=1748828201;
	bh=CKaqFvWvPyKHuXOwCCyN16zZfzshLl5KYWefcBaou7E=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=limt1uXqh80fqMVmCPKqwiXdnaBVfPQMtlPRXwvbCKRaoZHMrHiY/Da8JUDHA11r5
	 gcVsHO7BgHoWU2YRytHilGQ7tuPSl7+m1s+IBrxs7zH+N+yuZ7DJu7WaSKJ6l2nLvI
	 P9lKdByX7BS+qLGIQLlkrbFR3PAdRPFj7jRWVmBRwIeuyjgyuxxWBolM97stXZg1VP
	 6MIb+7fEd7QGGzbRdZ7OLjfz3Z5sAtznuIjrlugqNkvWlEUnm7hoLYxnRrSEA/QLIc
	 W9E6xhx/kl5hbWNe9s8UOTRiQhr0AMGZhXXQlmBI9udqVXwoZStVfv60iXaAzeim0V
	 g45E+5X0CJSnA==
Date: Fri, 30 May 2025 01:36:35 +0000
To: Stefano Stabellini 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com
Subject: Re: [PATCH v4 2/4] xen/console: introduce console input permission
Message-ID: 
In-Reply-To: 
References: <20250529000848.2675903-1-dmukhin@ford.com> <20250529000848.2675903-3-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: d61b8b5b16409b258872f296506ff8cab64dd46f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 29, 2025 at 05:58:00PM -0700, Stefano Stabellini wrote:
> On Thu, 29 May 2025, dmkhn@proton.me wrote:
> > Add new flag to domain structure for marking permission to intercept
> > the physical console input by the domain.
> >
> > Update console input switch logic accordingly.
> >
> > No functional change intended.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v3:
> > - rebased
> > ---
> >  xen/arch/arm/vpl011.c      |  2 ++
> >  xen/arch/x86/pv/shim.c     |  2 ++
> >  xen/common/domain.c        |  2 ++
> >  xen/drivers/char/console.c | 18 +++++++++++++++++-
> >  xen/include/xen/sched.h    |  8 +++++++-
> >  5 files changed, 30 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index 66047bf33c..147958eee8 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -737,6 +737,8 @@ int domain_vpl011_init(struct domain *d, struct vpl=
011_init_info *info)
> >      register_mmio_handler(d, &vpl011_mmio_handler,
> >                            vpl011->base_addr, GUEST_PL011_SIZE, NULL);
> >
> > +    d->console.input_allowed =3D true;
>=20
> This should be set only when backend_in_domain =3D false.
>=20
>=20
> >      return 0;
> >
> >  out1:
> > diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
> > index c506cc0bec..bc2a7dd5fa 100644
> > --- a/xen/arch/x86/pv/shim.c
> > +++ b/xen/arch/x86/pv/shim.c
> > @@ -238,6 +238,8 @@ void __init pv_shim_setup_dom(struct domain *d, l4_=
pgentry_t *l4start,
> >       * guest from depleting the shim memory pool.
> >       */
> >      d->max_pages =3D domain_tot_pages(d);
> > +
> > +    d->console.input_allowed =3D true;
> >  }
> >
> >  static void write_start_info(struct domain *d)
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 87e5be35e5..9bc66d80c4 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -835,6 +835,8 @@ struct domain *domain_create(domid_t domid,
> >          flags |=3D CDF_hardware;
> >          if ( old_hwdom )
> >              old_hwdom->cdf &=3D ~CDF_hardware;
> > +
> > +        d->console.input_allowed =3D true;
> >      }
> >
> >      /* Holding CDF_* internal flags. */
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 30701ae0b0..8a0bcff78f 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -512,9 +512,21 @@ static unsigned int __read_mostly console_rx =3D 0=
;
> >
> >  struct domain *console_get_domain(void)
> >  {
> > +    struct domain *d;
> > +
> >      if ( console_rx =3D=3D 0 )
> >              return NULL;
> > -    return rcu_lock_domain_by_id(console_rx - 1);
> > +
> > +    d =3D rcu_lock_domain_by_id(console_rx - 1);
> > +    if ( !d )
> > +        return NULL;
> > +
> > +    if ( d->console.input_allowed )
> > +        return d;
> > +
> > +    rcu_unlock_domain(d);
> > +
> > +    return NULL;
>=20
> The original idea was to skip over domains that cannot have any input so
> I don't think we should get in this situation. We could even have an
> assert.
>=20
>=20
> >  }
> >
> >  void console_put_domain(struct domain *d)
> > @@ -551,6 +563,10 @@ static void console_switch_input(void)
> >          if ( d )
> >          {
> >              rcu_unlock_domain(d);
> > +
> > +            if ( !d->console.input_allowed )
> > +                break;
>=20
> shouldn't this be continue instead of break?
>=20
>=20
> >              console_rx =3D next_rx;
> >              printk("*** Serial input to DOM%u", domid);
> >              break;
> > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> > index 559d201e0c..e91c99a8f3 100644
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -512,7 +512,7 @@ struct domain
> >      bool             auto_node_affinity;
> >      /* Is this guest fully privileged (aka dom0)? */
> >      bool             is_privileged;
> > -    /* Can this guest access the Xen console? */
> > +    /* XSM: permission to use HYPERCALL_console_io hypercall */
> >      bool             is_console;
>=20
> While I am in favor of this direction and we certainly need a better way
> to distinguish domains that can use HYPERCALL_console_io hypercall from
> others, could we simplify this and just assume that "is_console" implies
> input_allowed and also set is_console =3D true in all the same places you
> are setting input_allowed =3D true in this patch?
>=20
> For clarity, I am suggesting:
> - do not add input_allowed
> - set is_console =3D true in domain_vpl011_init, pv_shim_setup_dom, etc.
>=20
> The only side effect is that we would allow domains with vpl011 to also
> use console hypercalls but I don't think there is any harm in that?
>=20
> I don't feel strongly about this, I am just trying to find ways to make
> things simple. I apologize if it was already discussed during review of
> one of the previous versions.

There was feedback on using is_console:

  https://lore.kernel.org/xen-devel/e899f63b-6182-4b53-9fb4-9a821e75648b@su=
se.com/

AFAIU, since XSM is the existing user of is_console, there should be a new
separate flag to avoid collision with the existing one.

>=20
> I am also OK with this approach.
>=20
>=20
> >      /* Is this guest being debugged by dom0? */
> >      bool             debugger_attached;
> > @@ -651,6 +651,12 @@ struct domain
> >      unsigned int num_llc_colors;
> >      const unsigned int *llc_colors;
> >  #endif
> > +
> > +    /* Console settings. */
> > +    struct {
> > +        /* Permission to take ownership of the physical console input.=
 */
> > +        bool input_allowed;
> > +    } console;
> >  } __aligned(PAGE_SIZE);
> >
> >  static inline struct page_list_head *page_to_list(
> > --
> > 2.34.1
> >
> >
>=20



From xen-devel-bounces@lists.xenproject.org Fri May 30 06:43:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 06:43:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000458.1380686 (Exim 4.92)
	(envelope-from )
	id 1uKtSQ-000399-GP; Fri, 30 May 2025 06:43:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000458.1380686; Fri, 30 May 2025 06:43: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 1uKtSQ-000392-DO; Fri, 30 May 2025 06:43:10 +0000
Received: by outflank-mailman (input) for mailman id 1000458;
 Fri, 30 May 2025 06:43:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKtSP-00038w-3w
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 06:43:09 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2009::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5710c887-3d21-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 08:43:06 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by DS7PR12MB6118.namprd12.prod.outlook.com (2603:10b6:8:9a::5) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8769.21; Fri, 30 May 2025 06:43:01 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.029; Fri, 30 May 2025
 06:43: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" 
X-Inumbo-ID: 5710c887-3d21-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nWmMYCVaXXPpEHwG7nrknN4zfbqsT5oqKpevNj6E4LPehEP9hJFjBk/mA4aDcssDe9GHS9TMUJ1ZUOqVuRzw5IpAwjVsdgJSJeJ253iFGqGRoEhSb3weWk1bzSWxFZkpL2koUBAdWMMrpcqsDcbMXwhuAq9TbQM3OHcqKxNwH3hy8VHhHIOu1TBRpPBhES2HKKCsQHhhffU67muo8zqKcp8N+Pg9+BOvqBJrtMazsrXrXV1Y7eJrrtTO5ZTKMPPF1Rft5uWK/l0GKvYknZn0zjx7AXU88v81r+YKycZ7jdJVBuDlKM7NPMUqFoBtYYDlgCiMdaESFiJN/4ofxWkg5Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FB3zugNpRFVBIAqtdCUbtKPwkQ1dbINzGX+e9fI+GlY=;
 b=QsbLG++FSJ0EFenfHz4LTk8siIv5l2eMTd9hcT67L6NcUp1Vz5bOEVR+NIpTa/WoFwkYVAfepnZpnKtgCe8RpCHzotPPBmhYx//cyMeSIagF/erHSXBjUo05bmfx75l1P+BK9xsatp+fhr5zeSVLf9epfns7xIv+IBd/l/YTqM+ScnBcMZIog5qA88MLxLxmtrEQ0nXv34pWbGH+ag99q7IprrDQbhaCdwT1yvSdOwg24mw3qcbdFCFghza0oEhv46YFxt3NreOQekkzVASdugMLm4KwB1YP1jAP65AelyM87Sd/1n0y0KSpWqAtiRxtp4fkGIJR7eNGL2H7UdXOeQ==
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=FB3zugNpRFVBIAqtdCUbtKPwkQ1dbINzGX+e9fI+GlY=;
 b=IWa0PTb6kuCv3EDJpClYunOsKPtL9Z55z9hpLS11wbxva6b9nKiBZZgQftbAcgTyPJe1R4Mx8MYnM1cJGt4Dh8Q4M0ZszOki4aTAgnweGfeDZSfRvP4iDL0FHvCBd0oPgikY9NVeZo+m6O444wu2125PwzhJyLJE8i2WQR8WCNE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <83cc8e35-b670-4a56-ab5d-5356a44394c2@amd.com>
Date: Fri, 30 May 2025 08:42:57 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: vpsci: Fix typo in comment (SCCC changed to
 SSSC)
To: Mykola Kvach , xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <3881310bb93e20fd7d28d067e11ec9d19b68c60c.1748547428.git.mykola_kvach@epam.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <3881310bb93e20fd7d28d067e11ec9d19b68c60c.1748547428.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR3P281CA0112.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:a3::15) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|DS7PR12MB6118:EE_
X-MS-Office365-Filtering-Correlation-Id: 971f084a-3df2-4cd6-0c1b-08dd9f4538d3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VS9uc1pNK2Z4dk9QbUloMmNucC90Vzc3aHF5NEVOdU9MMjdrRmg4eEhHUlJa?=
 =?utf-8?B?NHZML2Vya2QrMXlGd1E0NUo3dlNmMFFuYXhkdVdxTHRhUWFJMDRZQ3hqMmQ3?=
 =?utf-8?B?Y1FqZ0FMUW5pMW11dmt4amY5Q21DMXNwbFNPSkhHa001SDNpcTM4WU1leWo1?=
 =?utf-8?B?Snc0UUZVSVlKb2J6aFRYM2xCaWd1MXdpN0M0WWhhNHpLWStuaGtrNzFyOFZp?=
 =?utf-8?B?dHNvSHk5Mi9oaC9FbEk3YTBXYnFCZnVrUHkrNms3TXBYdlpMUWg4R3E4cHdK?=
 =?utf-8?B?ZGZFN3V1V1lsU096aVg4QUVrZFZpMVVsYTd4c2pDd093OVVLK0NtS1NhZ3B1?=
 =?utf-8?B?dE9KOGoyYUlyc3ZBbjE2NStOSlJBd3VPd2ptV0xkUlBzaEpTakVXRWI3RFJk?=
 =?utf-8?B?ZW8wd0VmYWpXakFJZ3Z0ZVcvYUNoSTVOakNUUzJmOFZnQ2dpMkNIZ1pFNlE4?=
 =?utf-8?B?VjFDNzE3dnZqdGdpWDdDK1g1VG1zc1VOU1VVOWpmdlFkZ1lGYklodmYySmFv?=
 =?utf-8?B?RnpHQXd2UDMxeUttRTlucnRZczB1bitQUHY3aFBlU0dYQ2lobTB0WXdaL3Zt?=
 =?utf-8?B?OGlGYmJBOGdvcGVEZUJzeTBYbHZROEl5NXFyZlk2dG8wVmF5c1JGc1YrVjFo?=
 =?utf-8?B?U2FNNG9JNC9ncDlkYmtYRVQ3bkpjWDdJOG1OSWovUWYrWW53OUhabVUzYXpN?=
 =?utf-8?B?USsrNTJwcWExWnMrd1R5Mk9XVXpzeDB6b2l2ZkpnekQ1WXQyMWZFOE9IS3cv?=
 =?utf-8?B?VWR6cnpwZ1d0cVpxMVhtQXFpbko4b2lZQmRxRTVLd3pjRE5GcnlUeDZ6amEy?=
 =?utf-8?B?ZzVYUHVWVWFVNFdEeHQvc29xeFdSQnhtZThNZ1VSVndtVWw1NHcyaWxGelJB?=
 =?utf-8?B?V0QwNXpIUUtnTUl5SlROc2J4Z3FBbzVsSy9nMXppazV0S3ZOVVNXWUtXQ09M?=
 =?utf-8?B?cFYzOHM3WFNxRmFqbTBmbTFDR3ZOMWFWWnFEZnUvM2dqYVNtRXdKVC9iVXpw?=
 =?utf-8?B?SWt1SUV4Y290UXR2azdCb21ESGlCeFJsZjJWMnV0K2dUU2I4dDZoRm53ckdT?=
 =?utf-8?B?M2hmY3dUR09sMEJWbVJreVJYTm42aDZOYmxJbkNMeXdqZVgvSzBHV09vTndI?=
 =?utf-8?B?TTg5MHRBRkZtWHpvRXRCWmdYWC9uK2k0OVpMQ2c3aEVZYWQ0K3kveTdscVF2?=
 =?utf-8?B?c0Q0b0tac3QyalcxUVlDK1drNDV6RUVBbXhtV28yRkhXamhnMzYzbUpTWmR4?=
 =?utf-8?B?NEdWSitKUHB2c3FJNnpZcXY2SHZIOXFOSHhxbmtOaEJqS3NraWFtMldBd1VR?=
 =?utf-8?B?dmZubWRXcFJZbWZady9BMlMwUlpEdG5pWjZ4M2Fpa1dEY25aVnE3K0FLbm1H?=
 =?utf-8?B?eXFxZWtVRlkrbzFyWWlzbVBqdVpsdnFkM3Z2TUlwTmhjcExkUkQyTmlEeXZF?=
 =?utf-8?B?UkZYK0dJL0k2VEVmUUdBUUovQ1hEb0REdGJlaDlFSUtUMkFWK1VBa3Z5RnB5?=
 =?utf-8?B?YjZ5dEJKWnRZU1IzZ2RLU0k5dEhEalRweUFLUk1kdEdJb01kcmE3Q29MNWwz?=
 =?utf-8?B?dWdpcnVlRE83RUpLTUtMMjhoRVhzRjF4Q1UxTVkxTG91cHBCUjNFUmRZM3o4?=
 =?utf-8?B?Si8rYXNRa2NWU1JmU0pqZGZvelZNVUVTeUFoMzJ5eHJpS2x2OXNwTnVTSGl3?=
 =?utf-8?B?YnBvdVArZzNJbEhZMW9kMFFWajVEK3hHRzdYSTg1TzRUNk42dnhUS2s5Qlc2?=
 =?utf-8?B?cTkzTVdUTHpBVmZFL3l3cm1YREFOZ0dCeTJHYTEwaWZLU0ZVZE03bENMQ2I3?=
 =?utf-8?B?aG5reWU3MENzMzdTVm9PVlN6L2hHaW5pOHJmOVRQZzRRd2J1c0JTZ1NGWno2?=
 =?utf-8?B?VU8wcGxrdTA2K2c3L2dqc3ZOeENza2xzL2x5NXFGUFlFbDlVNXVWZk5RS01E?=
 =?utf-8?Q?lT7en3nqWbM=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?c0dtTEJxNmtZZFhsSkdrRG8ySzh2cjdITEpnVUI2ZTFzVDJBblNQaXo1Z0NO?=
 =?utf-8?B?dDg2WUlPdktocmxPd1dEa3VlVWVHNWtlczgrUGdQb1JNYjkrMzlWRTNjL1lS?=
 =?utf-8?B?d1FhQTZRZzhFRHZWdXZOdE91b1NlQmxzbEwvM0cxTTlEY3luRWI4eFN3SlZW?=
 =?utf-8?B?djJ0bzVkVVlSZWVudlA1YU15L2xvejd5SXpWMkpWU1VvdXZmWkF2NklocmR3?=
 =?utf-8?B?b0FDdTNSUU5xMUtpM2VWaWVsVmZaT29kNk8zakhZU21CL1ZJb2NnVTlHQ05v?=
 =?utf-8?B?Y0VWT3V0RE5FdEVYWWV1cGhJWjV1YXJiTFlYR3ZOcjZvVUZiTE9pQm1NL0o5?=
 =?utf-8?B?NjIwYkNhUklCS2NneXc5N3VCNHdVdGQwWVJlRVFqOWpONGtDL1pxR0htM0hS?=
 =?utf-8?B?bGhpV0Y2ZWo3UzV2YnZtaUEzd1NUaldZZXh4Q2o1VHZDVzBtdDFCZWZiVkg1?=
 =?utf-8?B?TkhCLzVxdGkxZ3VIL2ovWFc0VWRCM2tsNlJDYnQ4QnRFeWFIbVQ2S2Q3VklH?=
 =?utf-8?B?WkVnL2xDcUR0YkR3M0YvMXpTSGtKWFFNTUd0WEVUT2c1aEdWYTc1VStvd3hC?=
 =?utf-8?B?d1N2VWpSYzFYYnZVak9DNDM4eTk0Y0FsUEpxaTI0Z1JnZHhTOG5nUDNqM05M?=
 =?utf-8?B?bUJESkRTTlFnekhNbjM3cyswMVRzNUtKOUtUS3ZVQUZLWVRYQ1pHcnlZUVJn?=
 =?utf-8?B?K21HMll2clhLWGR2VHhYc0p4NmZJYzEyeFNvWXpEajZCN0U3Y1RBUzN1ajFW?=
 =?utf-8?B?Y3hhUFRnb1U4KzJscUZ3VDRha3lKMVBzOUhKUDJZY0llb2hWbFdnOEdPOXRK?=
 =?utf-8?B?Q2FJN1EzR3QrbHRmTXpxSUhlSGMzdy9xVU82ZHluZEx5NElUbW14Y0cxZTlT?=
 =?utf-8?B?aWVWalhBT09uQ0lLZWhWT25rcnIyeHpGaitjdHp4N1BzditQcU0wRldkMGo5?=
 =?utf-8?B?K3l6RFBONHRFQjRndW9jYVVEeUIzemdYM1JMM3lGSnIxMVZ6a2R2TUtnVEJW?=
 =?utf-8?B?WVE0V0FFSXRyRkFsY2g3Q1pybFdObzVuVngyM2ZhYzBpa1A4a2hwbncvZTda?=
 =?utf-8?B?UWVYUlltRmpDTTlvcVVUbFB0NVZJSVlMUjYwVHZHVTRMcHFFdFZFdWJaanJZ?=
 =?utf-8?B?Q0NZM0lmYlJJWHNLM2pTOVJJV1ZIU09qV0VVQkdMQnV3VDByeWpnZ0JZSUpT?=
 =?utf-8?B?M2dTUnpGaURIdUpvT2c5alR6b2VHRUpsZFFtazZvMzU3K01aSFE4ak41cU8v?=
 =?utf-8?B?N3NkdWVibTR5RFRVL1hKL1RyMm9EdU9KSUJDRWlBQ0R6blNCZE5mT0VpSDZB?=
 =?utf-8?B?L3c0Y21VZ09XMjVzalRYaTYwT0RlNWFtTUF3UzAyc1JtNTlNekl4MWJNV3dE?=
 =?utf-8?B?cnJEc2lOMWZ6WllnZVpmYllhVjhxSXR3RjVyazlnM3RpNmNuQzIybDJNcTdt?=
 =?utf-8?B?Q1gyVkJ0a0xoekFUTEVnelp1M0JJY043NHZDd0FYQllUYU1jejFSMnFwY1NX?=
 =?utf-8?B?NVJHV1hMRzk1NllWclE2SXR5cVZiNSt3aEgxUEFEOGFhLzBiMWdnSHRNckY2?=
 =?utf-8?B?UlBEc0lCSmhMUzhMVllMOTI3Nk1YSCtwdmUyRVVNc0ljbTRUNWlIOEt5d3Ax?=
 =?utf-8?B?aTVPYytCbmhOc01NTkRhb1NQNTh6ZVlEem52aE5lT3J2TTNIMnpPbXg0SVdv?=
 =?utf-8?B?MFdwbmFPaTBvempPbzZ5ZUVQSUpVZzFtNEl4bllTSk1mTmUranlzYmhwUWtY?=
 =?utf-8?B?WkF0UTIzU2svLyt6MXdoN2o3ckdnSyszeG13clY0ZDZKODluNWh3SHJiYkkr?=
 =?utf-8?B?V3lrOVdmOUJveUZDaDJkZ1NnTFp1aFJCSmN2Rm5PcFh1NFdiL1lpVVQyWE82?=
 =?utf-8?B?MDIxcFpEb2FTbnFJQnFBSFE0K0pHMVNIUlRodFM1NEtiR1RuVWlLaFhkQUdJ?=
 =?utf-8?B?ZVRFQUNYL3E2d3pIQkxiTW5tb3p1VXpHVDh5cHRoZnJVZkhwWHQ2UWVxbEha?=
 =?utf-8?B?MmdUUkRPdWwrNTBRbDFBNDlBVllPUXBIVnk0MGp1bWxHUmlWUGc4dHhsa1pL?=
 =?utf-8?B?eXlxV1JhNnY3UFVwZnVkMi9OSnNmeW45d3FPVVBSWXpVaUhhaENnWVYzN2NS?=
 =?utf-8?Q?SHn8=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 971f084a-3df2-4cd6-0c1b-08dd9f4538d3
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 06:43:01.4570
 (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: HFd+/oHNoAA3BRvx8vZRatqmWYOCruvCoSveGWytVVlaEVyOLYSfejySyQLlH74C
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6118



On 29/05/2025 21:40, Mykola Kvach wrote:
> From: Mykola Kvach 
> 
> Corrected a typo in a comment within vpsci.c:
NIT: use imperative mood in commit msg

>   replaced "SCCC_SMCCC_*_REVISION" with the correct "SSSC_SMCCC_*_REVISION".
> 
> This change improves clarity but does not affect functionality.
> 
> Signed-off-by: Mykola Kvach 
Reviewed-by: Michal Orzel 

~Michal

> ---
>  xen/arch/arm/vpsci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> index d1615be8a6..7ba9ccd94b 100644
> --- a/xen/arch/arm/vpsci.c
> +++ b/xen/arch/arm/vpsci.c
> @@ -268,7 +268,7 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
>  {
>      /*
>       * /!\ VPSCI_NR_FUNCS (in asm/vpsci.h) should be updated when
> -     * adding/removing a function. SCCC_SMCCC_*_REVISION should be
> +     * adding/removing a function. SSSC_SMCCC_*_REVISION should be
>       * updated once per release.
>       */
>      switch ( fid )



From xen-devel-bounces@lists.xenproject.org Fri May 30 07:43:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 07:43:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000484.1380728 (Exim 4.92)
	(envelope-from )
	id 1uKuOn-0002RM-Ax; Fri, 30 May 2025 07:43:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000484.1380728; Fri, 30 May 2025 07: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 1uKuOn-0002RF-7z; Fri, 30 May 2025 07:43:29 +0000
Received: by outflank-mailman (input) for mailman id 1000484;
 Fri, 30 May 2025 07:43:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKuOl-0002R9-Vo
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 07:43:28 +0000
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com
 [2a00:1450:4864:20::130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c50d8dcb-3d29-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 09:43:25 +0200 (CEST)
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-55220699ba8so2103914e87.2
 for ; Fri, 30 May 2025 00:43: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" 
X-Inumbo-ID: c50d8dcb-3d29-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748591005; x=1749195805; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=T+C2bkQuLVU4qaDIX7UgfRe3HQUfdHIw200e7iRp/4c=;
        b=MffKqcA6yYe8Tx4QuD8erHOoaeWuFip4mPCB1yb+wM+LFqy0Qwqg/2dVHESFr0DYKk
         j3F0SpbVcmYS+8N9EbTRDz/jADagBjXH+TXydqmzHCtYyo0nn1rCc8i/c+72Bqw4BsPK
         1vKSc3br/xMoAlb+xeOBN/R0FPx++MJ7zUIj0Wt3P5T64EhTft2udvFZioZAYK5iakIg
         Db8aKOUsutp30dUb8F1mHbUBVBp+rD1Pe9O+F9UnyZCnBzVnlby05M0fFceqXOh+eMPY
         6e3Tp1+ls/dKrizURnUG3fTJIMuZgItdWxnCWBCPEXacO8X5LAQImBKrHunBzbtXhmC3
         niSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748591005; x=1749195805;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=T+C2bkQuLVU4qaDIX7UgfRe3HQUfdHIw200e7iRp/4c=;
        b=E5LUaOKXIdys7tzptBfh5faS7wIyyM9GmbrLUrl/FaNY97mXUz6o5KORKsNhIo8BdD
         BlMM+htPf7hEuD+KTqR6w31RPkIYw6MITKrbRLWT0kFf3Go87YgCCenX6VQHuD+Xth7F
         EB+BiOd9t8tKyjWQNZtDrfqkc9IiF2y2bZkB+WAJcGyVYOq2Ye1OWtdqkOyLGRm5uXSv
         TUSb/8Q2rdGMvShm2zPV5YIsYFHxsokSGLDB/HUjaiLFPcUJkMcU5kVYTAvi6XfSbGyd
         xjlgpRtldVJ+IIDs7PAs372ZF99MqNZq/AUX2cid5ybFflozT8hWiJOmpdLOqeedrWwR
         RodA==
X-Gm-Message-State: AOJu0Yx9JCqXQXBBFh8au05lOtsikCGdRb1X8Lg/4cEwbCHtXN4ouAaB
	JPpCoNGekI0q0+hjy+F4E9C21EuLe3zMBn6FLLj0Zapq5epGKCe5twX/PoDJHcLaAR64d9Mnsgm
	lkyjmhqcxyQrRgpGyexRjUYGvTh0twzI=
X-Gm-Gg: ASbGncuMzrAxqLRAoW3qMRl9CJmhd0/Nrshvn3zudJxrbWpUi+AkovDxxeuvI5S8XYl
	9HbU2n3BOyUSLkoh+aIKVYUO2NMAdBkUOn67aipb8TH7b10bR30+OkHil5eKMInUvEYsF7Ucr+R
	Ln1xaywFucLnYThM/8ME1F2Fomayv0tpYwtwvJl6++iSct8oHlw3y2
X-Google-Smtp-Source: AGHT+IE9Aa7XCPx9v6oxcRr5KKPvZnwwJJirlOQVJUUJ/7alcfD5AdvjTSY27+GPa5wrIkcRJSyzn5UHx1eWyQqWkKQ=
X-Received: by 2002:a05:6512:33cc:b0:553:3492:b708 with SMTP id
 2adb3069b0e04-5533d1ad693mr322241e87.49.1748591004883; Fri, 30 May 2025
 00:43:24 -0700 (PDT)
MIME-Version: 1.0
References: <3881310bb93e20fd7d28d067e11ec9d19b68c60c.1748547428.git.mykola_kvach@epam.com>
 <83cc8e35-b670-4a56-ab5d-5356a44394c2@amd.com>
In-Reply-To: <83cc8e35-b670-4a56-ab5d-5356a44394c2@amd.com>
From: Mykola Kvach 
Date: Fri, 30 May 2025 10:43:13 +0300
X-Gm-Features: AX0GCFvXcxOld-LvO942St-rJOEomcC8QIdMx7s5uOmvQXYH_PnL8xjA4OBO4lU
Message-ID: 
Subject: Re: [PATCH] xen/arm: vpsci: Fix typo in comment (SCCC changed to SSSC)
To: "Orzel, Michal" 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach , 
	Stefano Stabellini , Julien Grall , 
	Bertrand Marquis , Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, @Michal Orzel

On Fri, May 30, 2025 at 9:43=E2=80=AFAM Orzel, Michal  wrote:
>
>
>
> On 29/05/2025 21:40, Mykola Kvach wrote:
> > From: Mykola Kvach 
> >
> > Corrected a typo in a comment within vpsci.c:
> NIT: use imperative mood in commit msg
Thank you for pointing that out. I=E2=80=99ll correct it.

>
> >   replaced "SCCC_SMCCC_*_REVISION" with the correct "SSSC_SMCCC_*_REVIS=
ION".
> >
> > This change improves clarity but does not affect functionality.
> >
> > Signed-off-by: Mykola Kvach 
> Reviewed-by: Michal Orzel 
>
> ~Michal
>
> > ---
> >  xen/arch/arm/vpsci.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> > index d1615be8a6..7ba9ccd94b 100644
> > --- a/xen/arch/arm/vpsci.c
> > +++ b/xen/arch/arm/vpsci.c
> > @@ -268,7 +268,7 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, =
uint32_t fid)
> >  {
> >      /*
> >       * /!\ VPSCI_NR_FUNCS (in asm/vpsci.h) should be updated when
> > -     * adding/removing a function. SCCC_SMCCC_*_REVISION should be
> > +     * adding/removing a function. SSSC_SMCCC_*_REVISION should be
> >       * updated once per release.
> >       */
> >      switch ( fid )
>

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Fri May 30 08:18:24 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 08:18:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000566.1380786 (Exim 4.92)
	(envelope-from )
	id 1uKuwS-0008RA-Ft; Fri, 30 May 2025 08:18:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000566.1380786; Fri, 30 May 2025 08:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKuwS-0008R3-DI; Fri, 30 May 2025 08:18:16 +0000
Received: by outflank-mailman (input) for mailman id 1000566;
 Fri, 30 May 2025 08:18:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKuwR-0008Qx-GL
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 08:18:15 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20619.outbound.protection.outlook.com
 [2a01:111:f403:2009::619])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9ebe99da-3d2e-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 10:18:10 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CY1PR12MB9584.namprd12.prod.outlook.com (2603:10b6:930:fe::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Fri, 30 May
 2025 08:18:05 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.029; Fri, 30 May 2025
 08: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" 
X-Inumbo-ID: 9ebe99da-3d2e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OHDplm62WNdoN4Z9A9cLq7T70xwhcx6Usf/YuALWaUE2bYgJzjDQg5zAHkRHExTStrg/XK4z1KPwo3j6BInzKf+jVLA6C6dmxFEGec53NQqf6cCk6BpSFj5ivo3g3CEMbcQt81AadElUy+iFQBifSwl/gPJwi8AAnbV5AYN7FSeYnG9l8go85IHFiqFSMb8JouzmxMXUZjfJ5taa9w1rMoAQe04tpIZeRuIBks1aeSIRADuQmpHbo6nm1HsR/Cs4Vo/DUpi0hqVtRMzBXrT2dBMAtoe/jXMuflhT7RCrb4NFrDeL2NjfB78Cs6tGYK3Gig7W93r/BKKdzzhYQzCPsQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JhPx/AGVqxZhCRAMMu42SXVL5byD/L6962a20PXDjy8=;
 b=bpkWJR13BaJSoUX9E738LplMN0WyHIUsyEE+ShaG40NVGCbYhzABVWIo4+fLTc73OtIW7RkQ690ZkxdJGBFCVVxy41uNWQXQghvCuGvylm1q+2yyM99F9JRSen+PoNdmcBxzq2eH0lGnjHCCX0p0Ewfs+oGm4Bezat4H6OxkndoJwSSB7pnKeYqcHCWwOa2i9W5nXJiMbb5LN/xgFMdhDVpbeunmIDLTqhi8VNRpjcuja2oRkxFUSbElnTUjdpMpnCmL6ZXZ9BeleTKaM2rtN8K8jsBXXSxDzcp5lMTq1UNR81BLZTwhKT1FbzKAsmV8ftNXUEXF/MYyNTXHUlWF4A==
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=JhPx/AGVqxZhCRAMMu42SXVL5byD/L6962a20PXDjy8=;
 b=i8ZC+KfJsK5i+1B0SKc1flmZJG6mq22QH5WW5dTXGfArs5iaEjZxizGhzN3vZcsxiVnEwUTUxZs+BDnO8pyYMduV6cBQGO990yDU2yOzPXsrx7vhDUrDa0X83jkcF937drxviYROQDOdNWlXPZcwb+an4IqDLRGDIg2OI7NBFEE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <01bb344a-6ff4-4a1b-8251-0451773dc275@amd.com>
Date: Fri, 30 May 2025 10:18:01 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: vpsci: Fix typo in comment (SCCC changed to
 SSSC)
To: Mykola Kvach 
Cc: xen-devel@lists.xenproject.org, Mykola Kvach ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <3881310bb93e20fd7d28d067e11ec9d19b68c60c.1748547428.git.mykola_kvach@epam.com>
 <83cc8e35-b670-4a56-ab5d-5356a44394c2@amd.com>
 
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P265CA0323.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:390::11) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CY1PR12MB9584:EE_
X-MS-Office365-Filtering-Correlation-Id: f3724e6f-11d3-4199-7d24-08dd9f5280b9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?S0NrTEhxVnBKcXdhT2UxcktMeHdSakxaUHN5aHRyWW9qZzFnaDkyR09DK0xo?=
 =?utf-8?B?bC9lVmJvRGgxeXlvNzg2aUJIVTkyS3Y4dGpNTmM2d09lUTZiNlEwWlFYbm9l?=
 =?utf-8?B?R3B1MXBVdGxLTE1MaDlpRitjK1NWYjBQY3NUbWNvcmMyN0ovaGU4NWxvTmZa?=
 =?utf-8?B?Mm1Xb1JUblF3d20vVTl6K01zWHAwNUtHRDgwczJVUkFYcDZhVC9RcUt2L1dn?=
 =?utf-8?B?bWhkRzJUKy8raGhBZ3hBQmF1WlI5ZE9UelFpb1dNSE1sNHNtOFhSNnpxVDVZ?=
 =?utf-8?B?cFFjbDMraGFFWGQ4R1VEbnBydGZLcFphSGhrK3pIWU9HYnl1dXNrZFpOYzJE?=
 =?utf-8?B?UTZIOHc3Y09Xak1sUkxzOXlzSS9jdit0VnRSRDY4dnc0dUFFNStVMlhHTnZ4?=
 =?utf-8?B?MFRkb0UvUkFDY1dSTE1oaHJjK21vMURSblVpYytWYStDYUpQejBST09nZWNR?=
 =?utf-8?B?eTBnYU5jeVFaVWdlZ0NPNWtTbUE3VTY3K3RyOHVrc2ZSd3dqUkVBZThCRGgx?=
 =?utf-8?B?TWxRUmV0VWk5dkF6dXFEMDNSTmZQc3dBS0VCVXZ3MlJLYUhJS2NWZWhTV1l1?=
 =?utf-8?B?ZGtvWXp5UG11YTZNSnFiM0QwUlgzNWkwNEYxeml5NExYMVZ2Wnh6TXZiRWtu?=
 =?utf-8?B?QnZ1elYrbEZzTnE3empEUktOTCsydDJTUlo3Z2FNWkpzcE90M0t1YytONEJN?=
 =?utf-8?B?UkVWLzdLMERyR0xueEZwaTIzMTlZUEhtREZ1VXJKblA4SWlxby9lN3BEL1NQ?=
 =?utf-8?B?YU5GVWxzaWVpcWVCSWFqSjU4UC9PbWxSbW4vT0psTHpmMzNzYVVGYndjZkNy?=
 =?utf-8?B?YXd2bzN1S0d2SnFCNVVCQVQzekVzM0VZanRYSU9DOXdWZVVmQkkzS1dLMDVR?=
 =?utf-8?B?TmJGSDB4dVFOV0M3MWlDb2tlbit6RUJqT0NTeWpRWm1MSmQ5QU5lUEMwaWhF?=
 =?utf-8?B?b0ZQRmJ0NTFtRGgydlFKQXhQQVZ1cE9iZ1JZLzJVREppa20xTHlrTjNodDJ0?=
 =?utf-8?B?cThNVFFTN1JCOUxPS0dQNm9VZmFKbHQ0MlBmN2F0dkY1UnlnOVluWGdJZ1lj?=
 =?utf-8?B?cTRCU1diT0wrd1JuaGZ6MGFLV2txRndueC9saVNTMlRzM2tzbk9IdTh4dGRC?=
 =?utf-8?B?RlEzQWZaNUM0SnFoeU5QRzJnc3I4eHppMHMwRTlKdVJ0R1l3Z09lQVhaL2lo?=
 =?utf-8?B?UjQ1M2UvUlUwY1RrdUJEdmlJV0Q1dmF0ajJJNmtKY2oraTBKR1BnUGlKTTdD?=
 =?utf-8?B?UDNMSFZmblhWM3RGMk01YnFOUkJsKy90K1dUeHVhS00xMFBoaDl5b28yZXJB?=
 =?utf-8?B?QjZBc3U2Y0lMaDFNSS9pOTJXRzA2OC9TY3lBeE9EenVxWGNJT0pYRkRJS3I2?=
 =?utf-8?B?SXkvRWk0WXAvVWdIUnZiYjV4Ym80Q0hiUENRUUExajNWZzRyc1o4YktvYXJ5?=
 =?utf-8?B?MElKS3JFaENCR0Mydlh4bmhLLzcwTnhielJKcjBTdFNtcDBxWTFIYW5xSVF4?=
 =?utf-8?B?cW02OHVxbUN0TUxCMWFSV3Era0p3cngrYTlTMWZQM2NkalpMNXZpRkhrTTdk?=
 =?utf-8?B?Z2p6Vy9lSTd2Szd4M0p5WmR4SlNFeUIzTjRrMXJ2bkw4UnpVR1NYVFBrR3Zx?=
 =?utf-8?B?Q1RRbUZkMVpKYkgrM1ZMSThxb1dlamJURzJndEhBaTJIUzA2ZzRXYTJWdC81?=
 =?utf-8?B?ZmdkU3JrM09NMGpCM2dpNEcvYm82ZzM4WkoveDNIUlhOK3VaQjA1SXdhRUhr?=
 =?utf-8?B?QlpHKzRTTjJYdWRLY1VmUzN1bm1vODQvNkJ0Zm5aeTgyTzYvN0VYUm5PTHVC?=
 =?utf-8?B?TmlvV1pBdWhMMU0rdGJxSnJtclpGcVpqTkxCbTJ1SS9rSExoSVJHQ1N4Qjd5?=
 =?utf-8?B?cGdIOXBINFpmM3ZZUzdHRjN1Q1pLR1RXVUY5UVI2QkhSR0NZMGIyS2UwaHht?=
 =?utf-8?Q?maQzzos+0jI=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?aHRzZTIzUktKdG4rYmxwOU5OcG5CNDU4SXh4SnBaN21IRGVqNmtaSEJCU3d5?=
 =?utf-8?B?WjEvVEFrbWlwdlhhVXY5ZEZpL1g4WGFoeWZrOGRXaktTZlNBTzU4Y0tWYndL?=
 =?utf-8?B?Y2xTaXFpdWhYay9oNmY2OEZHb3N3U3lNbjhnaFhHdFZkZkZTMnJ4cDIwdThm?=
 =?utf-8?B?dU5IVXI0RVovRGZrajlxTVBmd1g0SzlZbnEvckhQUUI1blJlVmg5SjJJbmJn?=
 =?utf-8?B?YUxKSVpjblRyY1FDMTlqT3BNYWl1ZStmYjZ2SGNRNzNsTDBjUCtpMzA5QVk4?=
 =?utf-8?B?QnRva3BURTFIc0ZqNDNoOVZsWm02TDdQczlRVVJxZVdxdzJwM2M1a042Y3RT?=
 =?utf-8?B?ZVh6cDJHMkpOR2ZBTDRVZDY5MkRWUERITzVOcjhvTkhBMjN3ODVDVmc0VlJF?=
 =?utf-8?B?Ui9wQWNOMFdRdDFZMkY4VTBiT3JEVmw4RVJia2o2bGlGd0h0eTZYUmRNVFMr?=
 =?utf-8?B?akNKcmRlbUp3bFZkVWRlQzNzc3ovakQ1MFo5L0lSdk9TUFRseVpSR3VibWZ2?=
 =?utf-8?B?RThFZEwrTUxoaXg1V2IvZmRsd3VNY01INVRic1Zra0xNZjZ3eG9zdGNzWW9L?=
 =?utf-8?B?dWRxSFNpYksvOGNSK3FBSWt4S3Y3RHVkUFI3dm1xdHRCcy9TZUh3c0w4QS94?=
 =?utf-8?B?ay9ZS09tOUlWVUJHOFlzZ0wzeUp5dU96RU5RdDJ1U3JJVlo0aVpGK0dqWWZI?=
 =?utf-8?B?aGM0TDJOdThkQVpUNnJ6cEIrZkhwZTNpZFJlcGZVUGxXa1RzQjkvaFpnL1Av?=
 =?utf-8?B?Qzk5TlJDK0pvZGJnVjFxMjZzMFdVUEFoS3llYlY1cXBOZGlNZ3l0Mkg1dGNa?=
 =?utf-8?B?Q09BU1ZjUVJ0a1hzZEQxaFlCa25TamNHSXZVUW8yWnJqV3d6aVhWVjMzZk9B?=
 =?utf-8?B?RU5xTUhlcUxYWUkybm1WeTUwamxpRWNueFR1cjNoS2c4Z1hDajBRSExqYVB0?=
 =?utf-8?B?aUhkT0hjbDlEbG84eVBaalJ1OTcrTkc0eHYzOTBXY3FUMllXajI0cUt0OFB6?=
 =?utf-8?B?eUs3Tmkyb1BHak1UN1VqVFNaQ0Fkcnk5MS9LN29YREtDTGtiN2JVU1BsVzBm?=
 =?utf-8?B?MUJrQW1ndmZDSlFqU0Nad0lrU2szUDdGbTJ3WDZReGNoNFA5NkEzakhmODBO?=
 =?utf-8?B?c0plbmk2Z1VqbW5RTXZoNUNKMkU3Nm5sdHdzOXFWeDFSSGVHUlEyUzFXdnR2?=
 =?utf-8?B?eFRlS1UxQ1Zjc0pxaGRzMXI1U0VhOGlCS3pIMXdTVkZGaVZhdkIzWFByUjBp?=
 =?utf-8?B?dVVmV29hSElUMDJWUjI5L0ZPNDdsenM1UmFBRFZWd0I2YUk1RzJ6WGVwNXBv?=
 =?utf-8?B?L2p5QWJzMzF1UUZYZWNXWWJra0h0ektuM0g0WlRxQUo5ZEM3WDNmRys3QUp0?=
 =?utf-8?B?cDZCQ0NzYzNtS3MyZy9LOGhYb0tPNVdDUFRVRHMvWVVkWmlXL0gwdng3QnlC?=
 =?utf-8?B?OEllUzFoRXNiSDA5VGdqakpCZ1hsVzJqSHhhQjdkRGRnOUk0TmxiRmxZaHRy?=
 =?utf-8?B?VFZDV0R0UlA5NHdldkRYMzhiSjNtVWxSUWljTGZYRzJIdG5YV0lhYjlwNzNC?=
 =?utf-8?B?cFVpVE1CUXFKR1JwYlY1dEVZclI4OXR4ZnRZcWtmMi9GZVE5bnpWbGlySmlU?=
 =?utf-8?B?VjBvZjFxeG9EdTh6Uzl1MlFuL3Vsd1lidTVGTnVoTldNcEhVRWw5czNqQ2Zu?=
 =?utf-8?B?NGJ3S0xKQmIxdVJaeGNNcXN6YnJ1K3VQUmlmT1dUaUpKOVlOZ0ZicncraUtk?=
 =?utf-8?B?dVI4ZU9Gc2ZoYlltSm94RjJXN08wd0JUbFMyWStuZUFlZkYwWWlNcHdtamVT?=
 =?utf-8?B?WGpEN2NIbjRZTU4reXhrbHA3c0FnYW0xZGk0dXgyNVVwZHpkYnQ3UGlua2hx?=
 =?utf-8?B?SGpEaHl6TGNaditCcTVsOENZb3cvRnJvTE0yaUhqUmZzSlluV1NCTnREQWZZ?=
 =?utf-8?B?ODU0MGx1Vms0SjAvWE83RVZSaWZjWXAyOFJUZ05RYytFb2c4S2JqN0hqV01r?=
 =?utf-8?B?NEhkcTdLN08yUG5HUExoYkdKMWFTdkNGc2psbE5jTUNHK3g3Tk5lbllERE5l?=
 =?utf-8?B?TGJPN01FckNYbzc3SGRmeW5nVzNiUk9PenYxMmxLZTVxVkFaVm5jRmtER2NP?=
 =?utf-8?Q?39Xc=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f3724e6f-11d3-4199-7d24-08dd9f5280b9
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:18:05.4245
 (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: S/M2WYC78arD3P8z3u9xycEMBiQVPCYwnovpzrVHnGOlFnC4c7zd7ldGpPxwBl5M
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR12MB9584



On 30/05/2025 09:43, Mykola Kvach wrote:
> Hi, @Michal Orzel
> 
> On Fri, May 30, 2025 at 9:43 AM Orzel, Michal  wrote:
>>
>>
>>
>> On 29/05/2025 21:40, Mykola Kvach wrote:
>>> From: Mykola Kvach 
>>>
>>> Corrected a typo in a comment within vpsci.c:
>> NIT: use imperative mood in commit msg
> Thank you for pointing that out. I’ll correct it.
No need. The patch is already committed. This was a NIT for the future.

~Michal



From xen-devel-bounces@lists.xenproject.org Fri May 30 08:45:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 08:45:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000573.1380796 (Exim 4.92)
	(envelope-from )
	id 1uKvMk-000442-FP; Fri, 30 May 2025 08:45:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000573.1380796; Fri, 30 May 2025 08:45: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 1uKvMk-00043v-CA; Fri, 30 May 2025 08:45:26 +0000
Received: by outflank-mailman (input) for mailman id 1000573;
 Fri, 30 May 2025 08:45:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKvMj-00043p-G5
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 08:45:25 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20615.outbound.protection.outlook.com
 [2a01:111:f403:2409::615])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6cf83f8d-3d32-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 10:45:23 +0200 (CEST)
Received: from CH3PR12MB8658.namprd12.prod.outlook.com (2603:10b6:610:175::8)
 by SA3PR12MB9131.namprd12.prod.outlook.com (2603:10b6:806:395::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.31; Fri, 30 May
 2025 08:45:19 +0000
Received: from CH3PR12MB8658.namprd12.prod.outlook.com
 ([fe80::d5cc:cc84:5e00:2f42]) by CH3PR12MB8658.namprd12.prod.outlook.com
 ([fe80::d5cc:cc84:5e00:2f42%7]) with mapi id 15.20.8769.022; Fri, 30 May 2025
 08:45: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" 
X-Inumbo-ID: 6cf83f8d-3d32-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=G65CawLKlkmTAWs4ATPRuktivlLtj6UIXy7rGJ1eWNBfi1u7YPLZ6NpOBg7PtKjux095x/2w/6iQPoUwD8EDg1YXvjFK9eT3XctsyTeFPwctcSW8EsjFS0obPtYnDayHJZZIqMOJ5I7IgZ6BIlCPEmHTL4tAQlvozgMiMt6WHIdr5KJwjZ+efiaZmltoKVoyT96oSVBK2n10TGjxg1KmGpIeDcPKheMO2Y0Sn20LOSMzSpwsYdOvaXuswndTy85bfFiUPz+JwMVY7ogYMSdxnJ70eULgZoC5hYRwNVynoKvsfoWsgAIybSTfg8qWLsJsGAD2TqMQedzWwuYOHwU9vQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PMP7gSJSsWqHr1SBIYZPTVQ/6RbTbRWAcWpitNSmsIQ=;
 b=uT1bg+cxOEadHOOonlS0Qgaqyn/atXL/rOez94sOiveCGx9K4Hb94JPJ2kRuZN0pxsrwDGzNLrCTsvIGZLrPbSPwRcqCfPLkrPcR1XMoX4F0uPFtBK8auIV8tiHffseylYqukwe+dLlURWmf2c5gbsv6piLmAFbVnO8LgZWvphjM6lZA8cy7VSz7zVEQNuMDZKoPMaYIgwCsv31+uT64SVbkKluPEdT4rCK6PmQTGhSAZCJxbw9iLC2+V3bd9QdUqsezf6aVIo4TPdCvT+FUwRMmuOpAsQ7GPeNdwdMmZYijE/QGx12G6Mdy2QNLgHZG8PIKe5GpJxZ2GNTZ7L3cpw==
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=PMP7gSJSsWqHr1SBIYZPTVQ/6RbTbRWAcWpitNSmsIQ=;
 b=NUyr/C871gFE0aK10Di/yrataN5P3Al7IoZjBthOYP9ubgF+xcDExbTr/jgSdKC5N7fuxS9Nbe1vaMhq4RmDap2v7YxcH5Y/FDstnBX0pWsoyhaNjfsOB3m19c+uxb5bCiqL1w77gKvjRIQGo3vVSBqoaUYE7Vvi463ixUH/rxw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: 
Date: Fri, 30 May 2025 14:15:08 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/13] sched/wait: Add a waitqueue helper for fully
 exclusive priority waiters
To: Sean Christopherson ,
 "K. Y. Srinivasan" ,
 Haiyang Zhang , Wei Liu ,
 Dexuan Cui , Juergen Gross ,
 Stefano Stabellini ,
 Paolo Bonzini , Ingo Molnar ,
 Peter Zijlstra , Juri Lelli ,
 Vincent Guittot , Shuah Khan ,
 Marc Zyngier , Oliver Upton 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
 xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
 kvmarm@lists.linux.dev, David Matlack 
References: <20250522235223.3178519-1-seanjc@google.com>
 <20250522235223.3178519-9-seanjc@google.com>
Content-Language: en-US
From: K Prateek Nayak 
In-Reply-To: <20250522235223.3178519-9-seanjc@google.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: BMXPR01CA0078.INDPRD01.PROD.OUTLOOK.COM
 (2603:1096:b00:54::18) To CH3PR12MB8658.namprd12.prod.outlook.com
 (2603:10b6:610:175::8)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PR12MB8658:EE_|SA3PR12MB9131:EE_
X-MS-Office365-Filtering-Correlation-Id: 56852ec3-8af5-467f-d3cf-08dd9f564e76
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|7416014|376014|366016|921020|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?czMzbnZMVzJMaW9pRHBmRUU0QnN5Nm5XcWFSS0pFeDVDcWZjbSsvbGhURUlO?=
 =?utf-8?B?RWdySEI2UUpOMS92RzNRU1lVU1JxOW9GcDh2anZsUWo4SE0vQ3NUMWUwR0da?=
 =?utf-8?B?dXRvYWFyZ1cvMDJ1VUpqR2NSSFd0TmlHZlA0TW5renhqUlU3Q1ZBb24raUQ2?=
 =?utf-8?B?NnFBRWQ4cEFQYVFNdnp4STVBZ2Y0MnUyRVJCaG9zOFFPVlMrN3FhNjhZU2s4?=
 =?utf-8?B?ZGpQdkFlRzhVdnY1R2poMlBqODR1Z0RxbXJrQjFvVUIrQXpPWDJTN3pUNVVv?=
 =?utf-8?B?UjBNRXcrS0tXY2VDdS9GcnJxZGV5MExuS2RRT1ZCVHhPckkwT2QvRHlIalJ5?=
 =?utf-8?B?SG1EdmFyUkNrT1FOMytmN1kyY3QwWXJvbXZ3cE5tYTNWWkY0dHdUc1dRaFRI?=
 =?utf-8?B?VmlIZzZLRitCWFVOOXp3akIvd29CZnZHazFxMENOSm1yUWtsb1hIdWVKVjlo?=
 =?utf-8?B?TFp5U0lMVFFsOXdVMWNHRDVlSkJxTFhRR2M4VUxzWjJXb3pvTkJmY2h5NFVl?=
 =?utf-8?B?eUZtT2twaXhOVW5CeUpTT1pXbXo2dUFHa0VRcWxsc1RCSHlBYXcxWVh1QmtC?=
 =?utf-8?B?blEvbVlrUjdRYWVsdnV1L3hWdzZ3bTJRdGgwYitwRHlQS2htK1hSK1BONFNm?=
 =?utf-8?B?VEoxaXRmVFZBSEswdjJEYnppaS9hZFRnUFppU3lWMDNGRVB4TUE0N2dQMWVj?=
 =?utf-8?B?NzJGaFpMaXAxWUVkL2p0a0NtLzFFc3o4SGFzK09vUlpVMElFUGx0eURUcjZW?=
 =?utf-8?B?a0ZuMXRTRUJ0aEEvYUJhMnpld0xEbmZSdGpRQVZWR0JuNUZkUkUxUVRBWUhK?=
 =?utf-8?B?NUtSMkdIV285OVdjMjAxUit1c2NydkJkcTlPUjBPYndZTkh1cHFMWjFRcFcr?=
 =?utf-8?B?V1JmR2l1QWF0WGkva2U1K0ZLQlBpelpLYU1NYlBoVzJ1VERGbzhhOEpPTFVn?=
 =?utf-8?B?ZFV5eDcwcWh2Y1VxRDZqc0ROZDEzWEJNWUREc3hSME5PMkdDRjVHdzdjZGRl?=
 =?utf-8?B?Rk1TNGFhbm1BZGloK1FNbld3RUFBcHNjTjFEeXZhZithb1NxTlpxK1hCUTJR?=
 =?utf-8?B?YUR3OXh6MHFjazZCZURoRzljNjliajBzQnpDL0NydFpVR2l4aS9VUmZGNEg4?=
 =?utf-8?B?b3I0b1hWS3lSL0RYYUlVMHZHMERNbGl0VFNiVHhSSjFqVmtOMS9pbDI4TlpP?=
 =?utf-8?B?YTJpQ2tlQVAxSlFGV2diYjVPQW5JK2JrNFlCQWQxa0VwMVZWOWtZT000TzBx?=
 =?utf-8?B?YkYra0RiZndsTVVodWQyTjBrVFBxVUkwd016bVlUYzkxQ29RSW9mV3pTdDRX?=
 =?utf-8?B?WVVnczJWRE96OU1XVW9tVzdVYTNuRDk4Tjc4eCt2emdVT2k0bkdzL3pwZisz?=
 =?utf-8?B?MUhTeWdqYStqTERPaU1zaVI3ZXNLZEJHd05PSGtzZzllYnFqS2Z3QU5sMnBl?=
 =?utf-8?B?ZEorSnpTbzVqaWVxSWM0bkQxSWRza1hvVWtuM04vUHlXNk81Szl4cFY3Y3lj?=
 =?utf-8?B?RlhVNm9PNDZYSE5PMzJzMS96QXFKeXhrR3hNS3ltMHhIMi90eG9FTUVZUG5T?=
 =?utf-8?B?VUNWRTVudlFZakJGOXRhdzIwYmw0ejVkTjN3NyttYS9Bc0hDMW5QU2x6VGQ3?=
 =?utf-8?B?Zlc2TGtJdmVGK3VPYmJtc3N2Y2VXS3dFekJCd3hhK0JQQ05jS2hoL28vYU5i?=
 =?utf-8?B?dVp6MUw1L3dwRDdQSlJmT3F2YzJ2STZZc05PaFNRYWV0WHEwOWNVSkRVWGdJ?=
 =?utf-8?B?SmNERHhkdzlQQVZWQkVTaitYZmYzRFVkeE15ZWJOQWkyeHNSSDhCZGNCbHJr?=
 =?utf-8?B?QmxhMHJVUnM2Tkx1bWtOWFBlcDdWMkYvTXZVTFZBZ2I0S0RPdlppSXlUR1d3?=
 =?utf-8?B?VkFZZ2dVblk3cENHSFlMc21aWmEwSWJTTzZwbVFwS09yWEMwV3U2N1kxY3gv?=
 =?utf-8?B?WFc4czJuT0hzaWswMWpTRkVWRFl5b01ZYUJOQTJvUDJOa1FPemsreXk2Zm5O?=
 =?utf-8?B?aFJIQm5aVk1BPT0=?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR12MB8658.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(921020)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?OFFLTUJhT0ZBbWhyV1UwWHRPWTZMY0RIb0IveWlPR2hKWmxINDNtbCtoZk9t?=
 =?utf-8?B?Wm91c280bTdtL2M2bnNtc1JhRURxd3FpSDVPU2ZuMUJPM254QlJxOUIwSEVj?=
 =?utf-8?B?amlIRDhPWHlRUTJQSnRkOWZac2FqS3VXNGJuUE1tcXRHejk3MlUwUSttL1ZP?=
 =?utf-8?B?a2FPbG9CZTRLaDFLUXNDN2FBNWk1UXdkbWZRUEdYenFYSnA1c0VQNkNTbllX?=
 =?utf-8?B?SktldDdFeGc1QVdzeXA0TzZ6clI3L1VXSGpZdjZQVHdJTHpUQjNKMUhsRVRo?=
 =?utf-8?B?SE54V0twRzRSOFJ1Z1VpVlYxdDI2L0FOcVFvMXVHbTlhK081MlVRenZkNFYy?=
 =?utf-8?B?MHVuNWhzdzVPN0YrVERBMlFZUDErN2xoaGEzcGh3Uko5UGc0RUMreW1uN0F3?=
 =?utf-8?B?MFdjR25adUt0R2U2OTJrM3ZtSVpNSzRTMWJCTzliazFtT0V0KzNXOWZkRHlz?=
 =?utf-8?B?WTNjUlNqT2lsRGVwcEg5Q29MVDcxY3R4bFg3cG1ZZnI3VGNmeUI1WHd4Nk5F?=
 =?utf-8?B?YWY0bWY3RndYMmw3SDFtbTJlbURhWU1aOEQ3eWpqM2VMVVExMEh1RmlHT0JH?=
 =?utf-8?B?QlU3ekFhaHpxNm5RTkJmdDZVY1pUNTJDb3dZUkRvdkhpYnZzd0lmRE9Tc1ph?=
 =?utf-8?B?VTJyUnE5YlcwTmVQM1l1L0NzUFU3aGd6R3N3Y1RiSGxKL0djVzVvT29pdVF5?=
 =?utf-8?B?aFA1RldBMmdBUWg2MmVkdDN3aG0vN2Zzc1hMeWxJUlhWLzdCNlZGTTdmZWh0?=
 =?utf-8?B?WnF4MmFXS0NyOUhtUWl1SUVySEdVWEZtZHUvOFcvMk9wSDV2UE9YYlJGWDFk?=
 =?utf-8?B?Y29kaUtYVnlUSmd1NEF4KzZvbExRWU4ycUVDZXdMeWIvUTVKNE5QcXRwSUYv?=
 =?utf-8?B?Z1hhTHV1eTB2Z0hHVlk4clgwYkwzR3RJL2xkdE1GQ1NMdTF1T011OTR2ekJT?=
 =?utf-8?B?K0U3MEQwNWhIc0ZRdHhJT2dwMC9SdlpaV21zakpDU3lScmZJWWJYYTgwYWxY?=
 =?utf-8?B?RmJXeHhHNXJCVWtyWW12UWswWW45VTVQSkRQTTBZV3ptTXlmMnc1SHNYOURv?=
 =?utf-8?B?MjJrekFOT2pKSlZPK0h5d3F5Unh1aERrc1RIZzFzSVpDeWtTaGJxVGV4d2Ji?=
 =?utf-8?B?MDVPbTVNTE5TUUFMSHlpaWtJdTdMMlRPQnNJMXA5VGJZVUlxRExCZmhCZGFU?=
 =?utf-8?B?TDVVZncyWGlzVXlkbDJ4VUNMSUpBMTMva1BMTEdTOEgraWRLQ1lLcWpMb052?=
 =?utf-8?B?MnNkUFRiU1BHOEoxU2FCendTMDFOcWVaemF5U2RoYjMwMThhUnZ1QjBIdUdC?=
 =?utf-8?B?NE1yOHUzL2loVUpoN24zMjJyeDRwR0xWTisxaERrZHczak5Ja01lckRlUnFt?=
 =?utf-8?B?Skh3OFM5ODRURWI4YlcvOXJjZy9oRjdFR1dxNmY3OHJSa05wUWhsRHJPQTZ6?=
 =?utf-8?B?RXFRSHYzNGV6bW8vbFlaQlArS1pFenJUdWc4QmhlSllmdU50R2QvVDE2Mnl3?=
 =?utf-8?B?RzR6ZDhLNXl6dXdkbWNGME9Sb0wvWE83LzlVRmRtRC85b1FQY2VKK29mWGFa?=
 =?utf-8?B?SXQwSjNrZmVEbVpIS3F1T0pmYWNDbmJoNGUrQmZSbm5sMjEwU0crN24wQzBK?=
 =?utf-8?B?TGxQWktGVTlOQURpdEh0Um5iWWJvUi9Ud2tYVEVmanc3KzJaVVhqMFBxTS9Q?=
 =?utf-8?B?QW1RYlBvbk1lV1pzMEY2UHhnSlRrUUk3cklYNjBnUlFEZXNzUExwRXYwNGdB?=
 =?utf-8?B?cy93QWYrdlBzd3VBZWJkUXBMcGhtS3d3c3kzYlRpZDVldytXNllMRkM3dngv?=
 =?utf-8?B?bE5Hb0l5V3Q3S0pyLzNENnBqUkEyemlqLytUdjRDbWVYazQ2RlJlRmRYdlFi?=
 =?utf-8?B?clFPMkNSbHNKbTVYNWZ0eTFkQ2htZEw5L1lmTURsNzhOVlJJMUdoT1pVcjB0?=
 =?utf-8?B?cUFhTWtoUGcwY0FPZEQxT3F1ZWVCNnE5bHl6eXdQbHdtd2M3Ukx3YW9mNGZH?=
 =?utf-8?B?d0tQU3RhZ3AycDRMRWp0cmFwK1JXWFpZUlhJSURBM0pEQTV2Q2JoKzRqYTdZ?=
 =?utf-8?B?ZVdEM09yOVhHNnlaVEx4MjNkK0ZMM1pSdnRUVVNia0cyaW0vSVlLMVNia1dO?=
 =?utf-8?Q?vH5FtqQfxQ9V8Ov0mSYkhqVy6?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 56852ec3-8af5-467f-d3cf-08dd9f564e76
X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB8658.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:45:19.2735
 (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: N6n2535z9vp3dMWkFTucuYD+obMnbYTuQ9MZFLHZeIIwDp6qO9dfg2n0euE1pQuMpyqqdvIwY5EZpIJrUzT/2w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB9131

Hello Sean,

On 5/23/2025 5:22 AM, Sean Christopherson wrote:
> Add a waitqueue helper to add a priority waiter that requires exclusive
> wakeups, i.e. that requires that it be the _only_ priority waiter.  The
> API will be used by KVM to ensure that at most one of KVM's irqfds is
> bound to a single eventfd (across the entire kernel).
> 
> Open code the helper instead of using __add_wait_queue() so that the
> common path doesn't need to "handle" impossible failures.
> 
> Cc: K Prateek Nayak 

Feel free to include:

Reviewed-by: K Prateek Nayak 

-- 
Thanks and Regards,
Prateek

> Signed-off-by: Sean Christopherson 
> ---
>   include/linux/wait.h |  2 ++
>   kernel/sched/wait.c  | 18 ++++++++++++++++++
>   2 files changed, 20 insertions(+)
> [..snip..]



From xen-devel-bounces@lists.xenproject.org Fri May 30 08:48:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 08:48:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000578.1380807 (Exim 4.92)
	(envelope-from )
	id 1uKvPb-0004aS-U2; Fri, 30 May 2025 08:48:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000578.1380807; Fri, 30 May 2025 08: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 1uKvPb-0004aL-PR; Fri, 30 May 2025 08:48:23 +0000
Received: by outflank-mailman (input) for mailman id 1000578;
 Fri, 30 May 2025 08:48:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKvPa-0004aF-4o
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 08:48:22 +0000
Received: from mail145-2.atl61.mandrillapp.com
 (mail145-2.atl61.mandrillapp.com [198.2.145.2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d622315a-3d32-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 10:48:20 +0200 (CEST)
Received: from pmta06.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail145-2.atl61.mandrillapp.com (Mailchimp) with ESMTP id 4b7xhz12sHzQXk4xN
 for ; Fri, 30 May 2025 08:48:19 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 2d2857a00af54ff682a29e4086620663; Fri, 30 May 2025 08:48: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" 
X-Inumbo-ID: d622315a-3d32-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1748594899; x=1748864899;
	bh=CINTqxmjCzUBSSvhqj+l0XHTYM1/Zj7I0ZRwoJo+6LY=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=TDXQJ2YhTyJEFWE0HIvs44Zts+3qw96zYysE7rf+Bmw0WdgyBaV/d8DX97qJUB5j2
	 YyIQ+igkTjYRo7o5hiFAT1r4zh2NvZYyXr9FJNZ7OOlLugzm0tqBB8tM6MMU/qZ+s4
	 BOfX8L6bv7lsn99QcnLPhqGa7zQ/91SAGCWJFMgz0cSXK9V22rgx18CmwoE+xsGM+Y
	 k8GBQVJ9ZwlepFvsZVcd02t9n1ZwFUkcYoN46dcPeiqQGhgIGQjJ+pmB6+MGTyschD
	 tRZJeNaxaOkQZJPQ12l3rkb3dTVIUU0WqciRYdZAHNPaMEYkSFk6d8cGjG9Mp5jmxo
	 3jnpptnN+R3sA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1748594899; x=1748855399; i=teddy.astie@vates.tech;
	bh=CINTqxmjCzUBSSvhqj+l0XHTYM1/Zj7I0ZRwoJo+6LY=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=d752I994NA1n97Q5ztHwhVlFnBm4PCqoS9bVzT7jYrdClGhZJA3st/SGcg498VySW
	 rg8zOUdNR1q+ME8b26lZ85lugdhRmvIqmRto12cfOrqXhl+voY/8B0H5nmQ+GVUbTz
	 5AbnNoJPFk34HcoZ+1dqgYdHnqXe1X4gJKCVAMCtKEDtWWTMBvmWc+TIBSCYJWtCEr
	 ukwBvAAso2Eg1I5l9N1CtceUoivvahTnRlqv/T3CjsZAAk+g8tx4e5Dmlr17NE3Zuh
	 /DLwYo1qEthe8QTN0Zvtfde+VcUjlTyKqkP+xa1I/pZ8dJr+fKpO+R4bKWEo+Wzif9
	 ghtFKoRPfwh1g==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[PATCH]=20vmx:=20Introduce=20vcpu=20single=20context=20VPID=20invalidation?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1748594898078
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Message-Id: <83d0e7dfc076e9453fb6537e5948c03d90e947da.1748594036.git.teddy.astie@vates.tech>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.2d2857a00af54ff682a29e4086620663?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250530:md
Date: Fri, 30 May 2025 08:48:19 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Introduce vpid_sync_vcpu_context to do a single-context invalidation
on the vpid attached to the vcpu as a alternative to per-gva and all-contexts
invlidations.

Signed-off-by: Teddy Astie 
---
Extracted from SEV series.
This will be used for instance in fixed-ASID patches (in SEV series).
---
 xen/arch/x86/include/asm/hvm/vmx/vmx.h | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index d85b52b9d5..1269c318dc 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -451,6 +451,23 @@ static inline void ept_sync_all(void)
 
 void ept_sync_domain(struct p2m_domain *p2m);
 
+static inline void vpid_sync_vcpu_context(struct vcpu *v)
+{
+    int type = INVVPID_SINGLE_CONTEXT;
+
+    /*
+     * If single context invalidation is not supported, we escalate to
+     * use all context invalidation.
+     */
+    if ( likely(cpu_has_vmx_vpid_invvpid_single_context) )
+        goto execute_invvpid;
+
+    type = INVVPID_ALL_CONTEXT;
+
+execute_invvpid:
+    __invvpid(type, v->arch.hvm.n1asid.asid, 0);
+}
+
 static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva)
 {
     int type = INVVPID_INDIVIDUAL_ADDR;
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 30 08:49:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 08:49:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000590.1380815 (Exim 4.92)
	(envelope-from )
	id 1uKvQh-0005Af-93; Fri, 30 May 2025 08:49:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000590.1380815; Fri, 30 May 2025 08:49: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 1uKvQh-0005AY-6U; Fri, 30 May 2025 08:49:31 +0000
Received: by outflank-mailman (input) for mailman id 1000590;
 Fri, 30 May 2025 08:49:30 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKvQg-0005AQ-LM
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 08:49:30 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20626.outbound.protection.outlook.com
 [2a01:111:f403:2408::626])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ff5cccde-3d32-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 10:49:29 +0200 (CEST)
Received: from CH3PR12MB8658.namprd12.prod.outlook.com (2603:10b6:610:175::8)
 by SA3PR12MB9131.namprd12.prod.outlook.com (2603:10b6:806:395::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.31; Fri, 30 May
 2025 08:49:25 +0000
Received: from CH3PR12MB8658.namprd12.prod.outlook.com
 ([fe80::d5cc:cc84:5e00:2f42]) by CH3PR12MB8658.namprd12.prod.outlook.com
 ([fe80::d5cc:cc84:5e00:2f42%7]) with mapi id 15.20.8769.022; Fri, 30 May 2025
 08:49: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" 
X-Inumbo-ID: ff5cccde-3d32-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NTxY4pKi0PXCG9Z80FXAElglz+qjmwVw4GeV7mY5QduQHyQ6E1lJMsy4hhBHtVOD25twEWjOgOpxKlpmCuqCOmMUVNRc1DRCAq2I/I8U1X/PjVk98yO7U7iCIgFQX4y8kg/noIFCPR0cLg7JXzbX1GFkg5sVCljbKr1xYSNhMjV8wAZSg0sCYcqiCc206Iw0j4jemM5CiXF8JgbNa+AmqIelTfpIbqmMIOYrITCMEIOfXUgO3yXybhZCg/FW1/JDSCN2Ls9hcMl6NQsmoGu/2HlW05wSu6Uhj2/vyaWMkceAvoAgugqESCeTV57jwn1KWvWYSyEVUM/JwMmHF5TaOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=G6CORtijIU0rbtjzNzihjEFoP6F4ecd6+LLcqcA8XXE=;
 b=lPmhb46x5k7lv07lelREonM9Bh0svJUTs+02sdqSymdFTk0weOvGwn6q4KDNXCs3WgQNf+dOMdtvTyg85sTnLfIRJIJ5hOmHtaiFs+nm9sWYMKQ220bTGYiNydHtXulyd9sV16JdrMXzu2nEMk8Rae/n+Nyq3PpbYpX88x6pQ/IMlIXa3VBr47xm0Opc4HW14Eo4qq0pEEZ6VO70UmALer71SONfKtZM8Sn0SSZvzrxhpGA4KNU7wd79tY6AoKscnwK+/HctK3kqpElQTxVP9IdKMw2/a2Wf9Y1NWz1ePWTbzDMT/XM5LU3ffCLTy5zhGdJv3YvtBiEXVUu6mR+hHA==
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=G6CORtijIU0rbtjzNzihjEFoP6F4ecd6+LLcqcA8XXE=;
 b=dmlo2vsqXOP+USkEaGTdcqUN7QwsjdwvbXCQ453ssXk3hySwXimAGQWkfX4PNEew5qrtkbPNil1G1o3YIRSLh03sXdvwHQXahRMePyscf84K/2geuD1LL7uG4qCqINLvVS9b1C/mH1+SrX3PLuhgGMSWuw35B8/1YLwscd0GO+4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <64902e02-0808-4e0b-94a4-c1a57441a8ee@amd.com>
Date: Fri, 30 May 2025 14:19:13 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 00/13] KVM: Make irqfd registration globally unique
To: Sean Christopherson ,
 "K. Y. Srinivasan" ,
 Haiyang Zhang , Wei Liu ,
 Dexuan Cui , Juergen Gross ,
 Stefano Stabellini ,
 Paolo Bonzini , Ingo Molnar ,
 Peter Zijlstra , Juri Lelli ,
 Vincent Guittot , Shuah Khan ,
 Marc Zyngier , Oliver Upton 
Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
 xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
 linux-kselftest@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
 kvmarm@lists.linux.dev, David Matlack 
References: <20250522235223.3178519-1-seanjc@google.com>
Content-Language: en-US
From: K Prateek Nayak 
In-Reply-To: <20250522235223.3178519-1-seanjc@google.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: PN4PR01CA0089.INDPRD01.PROD.OUTLOOK.COM
 (2603:1096:c01:2ae::7) To CH3PR12MB8658.namprd12.prod.outlook.com
 (2603:10b6:610:175::8)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PR12MB8658:EE_|SA3PR12MB9131:EE_
X-MS-Office365-Filtering-Correlation-Id: 6a6bf19a-9db7-46db-9d5e-08dd9f56e0ea
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|7416014|376014|366016|921020;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MW5YZGluMENXUCtWc2RYL0JCTklkUFRnWDlhMGVCaU1PQjJjVWpyMGJxKzAr?=
 =?utf-8?B?MW91VElxUzQ5dXdkYjVVWHY4TmR2OExhR1ZFU01PQ2lVTGNma2p1TmRiRGJy?=
 =?utf-8?B?ZjNUYncyZmkya3RPTmd2YXlBZWZvSmRvRGhMMFJoaXpFTDcrVEVpeitpclhw?=
 =?utf-8?B?SnZOZitvdzgzbXoyQTlWUjZReldiWXNDbk1FTXUyaHVlQUZWcUUxbzN1R2hn?=
 =?utf-8?B?Y092ZFREVkllZnhrTVQyMzE0Y3kvWlRNcWF0aHJudXkxNUVRZjBwRDZvVDEx?=
 =?utf-8?B?dms2bWZoU2ZOWisvK0VmL0kyZHFyNjkwV08rcGVMdHVuaTljYnZiYyszdWV1?=
 =?utf-8?B?U2FUVWZPN0k5bmRSNHhhZGdsYXkyTUlRT1VYSzJMTmUwTkZ5c05uNHNTbzls?=
 =?utf-8?B?MW5pY0RneDhSNUNaWkl4c0FGMzBjbVVMVmkvKzA4VE5RdFhKL1lUYzlvNUhN?=
 =?utf-8?B?Ulg1RFFJbHhOaWNpUEhLbDVpVmp3T25tUWFKdUlTS1AzTWhIald6VDYyMnRp?=
 =?utf-8?B?dzJQTk5jSVJ3bi9XZ2Z4cEkwYUp2Qm9UcFNuN2RrY1o5ZWczdkhiWk9MdzhZ?=
 =?utf-8?B?T1pXc0plQjFiKzNDZU9KRVp1STIvb0tzdVZLQjRVTzg0TlYzaDNaZ2dLK1Za?=
 =?utf-8?B?aVJ2THpNVml2MjZsSERyNHA0UFhyTmZmMEFYbHFpM3EvZTBRTXYvZnVkL05Y?=
 =?utf-8?B?RW50MEsxWUFDckovR0R5NEZJdXJrZXJabWpGZnRvdFg5cmR6aFBaN2pnNU1T?=
 =?utf-8?B?aHo3dmdRQklVVGhqQXZVNWNxdTZsbEppaTdvOFhDSHZ6eE9wUnpVblNMakdC?=
 =?utf-8?B?K0JwOU5wZkdnVXRsVnMwNzBIam1YTXFWZUF2NEtyckhjQ3I0K1VOQ0RwNUZW?=
 =?utf-8?B?amFXRzRHUC81QXZvZTdMeE8zeGhrMWkrbmpjR281VldkMHJzWEdYT1g5OUc2?=
 =?utf-8?B?TUxDeDdJK0UvWit4YnNBMUdPdW5ua0JvS3VsQmxaYS9MVkNsd2lqZCtuNWt4?=
 =?utf-8?B?OXltY2ZvM3ZPbVhLRFhabW5RYS9DT3NyaERIRS8xUFBWL284T1ZYeWFLWTQ4?=
 =?utf-8?B?bVhHU0lPQXhzdjB4T1ZOOVdZOGR6R2gzV0p6ZVpHZ29IU2pjMElIeDlwWmdH?=
 =?utf-8?B?QjFaUTkrdG1SNGMwK1VPaHRlcThHbCtLYXdQWmFkUmlyUGxRemVVWjdQYzM2?=
 =?utf-8?B?Q2pZY1M0VDhFb0pSb0VVTlBLTjdHVjJ4YzFrRDdEeDB6M0ljQWc0cXlYTzc0?=
 =?utf-8?B?ZThjaVE2TGtYeVEwc0pMOTVGa000R3orRm9nbzVZdkdzOEoyWUdmVmx2UTIz?=
 =?utf-8?B?TER3bSs2ODQvRnhEam5BRFNEU05ZZzEzQmdvdmQ1bzlWVlFEWTk0WTZ4SjBJ?=
 =?utf-8?B?Zk85OUt3dC9KVXVmaDl1Y0g5TnRaQXdST1IveW96TU9iMU5uM2tMQ1RPMzJE?=
 =?utf-8?B?STBXS2pJT3JueGNzSENOdjcxOUtqcXVPYjR1aDN1Z1A1bDEzeGdWK3k0cGtY?=
 =?utf-8?B?KzVvU0t6KzZYdzMxSSs0eVZGRWpKTTYrTDlKWUNmZzJMd3Q0eW0zNmh0NGUx?=
 =?utf-8?B?cERERnJtYzlYaUVIcWUxRW4vbDNQZjd6SVJ2RkY3WWZnQUdkTmRXeUhPNHJH?=
 =?utf-8?B?bTRxeWdreHlCWjlWcksrSjRObWJVN1hQM0lYN2dCSnJtVXNGZ3NZVXJITVdq?=
 =?utf-8?B?czJRNG5qcmp5a3k1bnNRVU5XRkkzdUVEVXZtWTVNajhQOXF0a2RtQW9PTVJw?=
 =?utf-8?B?eUFzeXVjN2QwVzRNWTF3clZVK0pZZTZmWjk3amJDTGlVU3BmVTZMeVdmbEZz?=
 =?utf-8?B?RnhOdGlTZm1NMThsTjFUS1kyTFprcVF0Slp4K3BXNDFNOHJQUk1yS2FCa0oy?=
 =?utf-8?B?OGN5Rzl0Qkw0YjFlL3AraTMxK1ZjY1BnTzZZajJIQjFQWk1ha3hiNitHeXJF?=
 =?utf-8?B?a1BVTStodlQ2Y1p0N0lWakcwcjRsR3R5SjNEZ21ZTFB0WnFnQkhjQUJVYXc5?=
 =?utf-8?B?NjNGeDRtcVNRPT0=?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR12MB8658.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(921020);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bSsrQ3ZVWlB3cTVTR3R5ZXpmK21tVmJ4U0lBNTdQYTlRaUR5di9GSm5ySmJO?=
 =?utf-8?B?WkhaZnZnUS82TTRuRTcrN1lTcGxiUjk1VzBIc2JzaFBUM1lTSThxcU02NmN3?=
 =?utf-8?B?endkSDQwNXBUMzBaMjE4ZXc3YnZlMWN6Ym5UMlcwOVlHUE0vK2lSQW0zUlR4?=
 =?utf-8?B?RDA3Vnk1RzErMHNkck1va3l4NVRHSmdMMmNpUFVpRFk2bis5R0RrSWc5VEEw?=
 =?utf-8?B?bWJXTGpmQVdCUkhBL1BvZ3BnU0pMaFpDTSs1N0lOOVM4OW1PQzV6NWRaUXBY?=
 =?utf-8?B?RnZaSzZKaXpsa1Z0ZGVwa3ZteW9QeTN1bmEweVRseXpVZzZTV0hlVkNvbDZM?=
 =?utf-8?B?MHA1ZWt0ellhUzBNTlFHRStmMHkwS2s5dmNlZFgyVG5TaUkxYzZtOG4xOHR0?=
 =?utf-8?B?UXBBcHhsSXRLT1NQUkFFWElkVWRzZUNHS1h4WExrbk1KTi9yTVBFUUNWdnk4?=
 =?utf-8?B?UEJDZG1TVWxsTFIxSFJiUTBlUFEwckZLcm9sMEZhNGdEdG9TdTlJbFMyQVRI?=
 =?utf-8?B?T2hYMmNMSk9kalVUaTN1RDNZcm55TGNRNTFQb3BsWUNnMDZqbUhyNERqSHJ3?=
 =?utf-8?B?NnY3K1RXcFY3R0lhcHRobnBWYWVvcm5lOWNQNDV4R285cFlRN1RrNzRRWm96?=
 =?utf-8?B?dnJlelBGeExBdUJqcXBmNStodzkzMHArdjJ0ZHRhN2xMMjk5OTNqVVZYZC9V?=
 =?utf-8?B?a3BzNXFvZUE4YnRmTzhvb3BHb01SVGZ1bjVoRUVXRmtudHhiK0NodkI1c1hh?=
 =?utf-8?B?MXY4empWbEVKelBmR3lXMkFxZ09HSXlxc29DK3QxWFNWbzczOENJbW1nN2JR?=
 =?utf-8?B?ODA4RVkxUE5QNm9KeFpQSTFtVXk0VXpiUk42RmpEejN2U1FYbXlVdkhXZWFK?=
 =?utf-8?B?NGN4S1BTc2hWb1RodmtjT1J2TDlHMDI3M3doOTdaNkVURkg3bGRGckcwa1VM?=
 =?utf-8?B?bGhDT2h6RnpsNnA4OW1HcHl5bW5KSEpBbkFranEwZk1ISTkybDk4QVpQYjBT?=
 =?utf-8?B?TlUvQkowM3ZUQU8xZEVXWG1yTlVycVFKaVE3VEF4NDFiQzdGbTdnTWJlNWRS?=
 =?utf-8?B?OUoxVWdBQi9pcE80L3QxQlVORG5yMjdUdTc2TWkyWVZMUEJWYVRrbnlWQWlO?=
 =?utf-8?B?RmU4Q2FOR0dBUU5VSEs5RHZ6WTUwN1JUYlN6VXlWR2FGOEtQV3RRUXNMT09J?=
 =?utf-8?B?a0htTHZZblk0dlVISVh0OUlEWnhLNFQ3eittTzVTaEM2NDZ2N2dVUjI1SFY2?=
 =?utf-8?B?WEQxZExUcmp2SEJHVFlrQTdTUTdIcnlQQTlYU3UrNjAxTlJBRzhkdVdMV3NC?=
 =?utf-8?B?aGtEZExpc0Y5a2pBeWxTUWlkSFQ0Tlp6dWJsYW0xWE8vMHVYM3haRnlGZ3p5?=
 =?utf-8?B?V09YVlhqd3h4RUV5dFhuazQzVFMzWWVCV1FTbmZJVGNXaG9LUkwyWXRYdjRx?=
 =?utf-8?B?NkJoamRBUkJYTEhGT0d2bXM1S05xUnJPQUdESlNSa2w1aWh1SGxvOGxkT0Fx?=
 =?utf-8?B?a0prS0tsN2xrTjFOQXB3QmM0ZnE2dkdBWEVUdEM2cUZVcy96RjdWOGpUVU5U?=
 =?utf-8?B?UCtwTUZOQVBQWnZockhOZVlHMkNSTjU2Y1pNU1dZREViWGdQemNXR21ud3I5?=
 =?utf-8?B?WjR3OXZTWWh1TGNzUHRacmxhcmQ0UVczbU0zWU5FQ2cySGVnREZIMFdrd2Zs?=
 =?utf-8?B?bVY4SDNQRFBvSWxGZWp0UnA2NFBaM3VtMGt0NStsMDFadVVhemx5N2Z6eXc5?=
 =?utf-8?B?eWR5dHZrUjB2bkk3V0I1YXpMT3p4SjFVYWFGNDdWbTBjdnlvSUxkWVZ5bWhu?=
 =?utf-8?B?ZzNBYjd6WVBXbVFQT0p3anNQM0hYWExSRzAyRCtxcUt4OFBWZGRWaUZHRFE5?=
 =?utf-8?B?TVcrQi9UV0JNV0JWeS95TkxiUWFjM202R05hUzBLVS9WdzdUanpOa1JoRnhQ?=
 =?utf-8?B?UFNMVlZodXlnaGN0Qmp6YnBMUkFQUzFvL3RkcUJoc1dpczFhUSsrQyt6MG83?=
 =?utf-8?B?RExubkxnZXkyTitQVW95OElTOVo5TExRYWwyUS9oRUNqTy9VU2pOYnpKMVdn?=
 =?utf-8?B?dnNTTkhVVTRWTEFQbURNQkRERjlzTUw3OWJpcXNqTkpJTC95QVl4YlpYK3dU?=
 =?utf-8?Q?9dn6+JucxyO3C4WozczQYgfko?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a6bf19a-9db7-46db-9d5e-08dd9f56e0ea
X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB8658.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:49:24.9920
 (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: vqI1Dn0cGj2uuzh7d8h6/mpPYxVhKsf//t3lftjpILfrQz/TVmQvn/3J/tl+VXOb9lRLfgpyfRloQjdRJ8eHNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB9131

Hello Sean,

On 5/23/2025 5:22 AM, Sean Christopherson wrote:
> Non-KVM folks,
> 
> I am hoping to route this through the KVM tree (6.17 or later), as the non-KVM
> changes should be glorified nops.  Please holler if you object to that idea.

I've tested this series with the selftests and also ran KVM unit test
on top of the specified base and didn't see anything unexpected. Feel
free to include:

Tested-by: K Prateek Nayak 

-- 
Thanks and Regards,
Prateek




From xen-devel-bounces@lists.xenproject.org Fri May 30 08:53:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 08:53:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000599.1380826 (Exim 4.92)
	(envelope-from )
	id 1uKvUm-0006v5-Q8; Fri, 30 May 2025 08:53:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000599.1380826; Fri, 30 May 2025 08:53: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 1uKvUm-0006uy-N5; Fri, 30 May 2025 08:53:44 +0000
Received: by outflank-mailman (input) for mailman id 1000599;
 Fri, 30 May 2025 08:53:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKvUl-0006uq-KI
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 08:53:44 +0000
Received: from mail145-2.atl61.mandrillapp.com
 (mail145-2.atl61.mandrillapp.com [198.2.145.2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 95e4fc80-3d33-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 10:53:42 +0200 (CEST)
Received: from pmta06.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail145-2.atl61.mandrillapp.com (Mailchimp) with ESMTP id 4b7xq901nGzQXk4xS
 for ; Fri, 30 May 2025 08:53:41 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 c7effae4a453497d94d501d7ca116e40; Fri, 30 May 2025 08:53: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" 
X-Inumbo-ID: 95e4fc80-3d33-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1748595221; x=1748865221;
	bh=sAnn1vNOxgAZHvWSPOmwAF0lrB3bmqpJkYpIh4BgxHg=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=aa55YgKyKTuO9b/1CN0y7Ty/VtKBY6jN6aXmoHp+sLYeWOEZYGnXUPq9E94hIzdNE
	 KEDSK+vuu0uQizsjKAVbVBUOLOO4lBNKnriKeP8G73qlpgt5izf7AgxqkmNrtGYRks
	 mSPoxoj0y+f8Uob6/dKygBdOPpclFNLXPEpkhNiaya0MdhgksaZ2tXbEYbm3TwA3SN
	 lwq1BT99Yh5sBhMqaNe3RdM8OGdCTIISRJ4FdAD0rliBoZu6NhIk/2wRCBti4AS0sQ
	 FFVKVeZpD6DxJLZjCMdwh5RueqlsnsizXQclWR4uNEwmtlrEa4tG/1uUlWtS7+BI/j
	 JuBUPz6a6ptLw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1748595221; x=1748855721; i=teddy.astie@vates.tech;
	bh=sAnn1vNOxgAZHvWSPOmwAF0lrB3bmqpJkYpIh4BgxHg=;
	h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version:
	 Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From;
	b=f04HdV0wylu7YsOZzrHbXhnP6Wa4+Ov7V8WBThRG5tQ1Yq3t15FKPM3TEUAfG5YJe
	 h73lcqnl4/Q+dxw4FXVH3NBtRh7gGF78ujyHP62xUWbAfvvSD3TBPjJkH0xLZvSvoT
	 NjpFU/9yTYU2oN2n+Nd4DemaHB2Vpm8C6n1fjAJQdBQtEvWwz3WYHq647W1KVXllvu
	 VG7QoywdF55vk8Ws9Sgl+p6cna/pBZ5/L0YeJ+qoctPJDtsXLzntxuQ6zCMKlkYira
	 KTrTeFnvMf04P0V8FZQPA++VYLxal5oP0C7nTLJABvzK8t5RhWJRBw/a17LIN9yEnB
	 Kec17nTvJNDlw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?[PATCH]=20x86/svm:=20Move=20svm=5Fdomain=20structure=20to=20svm.h?=
X-Mailer: git-send-email 2.49.0
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1748595219846
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Message-Id: 
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.c7effae4a453497d94d501d7ca116e40?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250530:md
Date: Fri, 30 May 2025 08:53:40 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

struct svm_domain was in vmcb.h which is meant for VMCB specific operations and
constants, move it to svm.h where it belongs.

Signed-off-by: Teddy Astie 
---
 xen/arch/x86/include/asm/hvm/domain.h   |  1 +
 xen/arch/x86/include/asm/hvm/svm/svm.h  | 11 +++++++++++
 xen/arch/x86/include/asm/hvm/svm/vmcb.h | 11 -----------
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/asm/hvm/domain.h
index 333501d5f2..2608bcfad2 100644
--- a/xen/arch/x86/include/asm/hvm/domain.h
+++ b/xen/arch/x86/include/asm/hvm/domain.h
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_MEM_SHARING
 struct mem_sharing_domain
diff --git a/xen/arch/x86/include/asm/hvm/svm/svm.h b/xen/arch/x86/include/asm/hvm/svm/svm.h
index 4eeeb25da9..32f6e48e30 100644
--- a/xen/arch/x86/include/asm/hvm/svm/svm.h
+++ b/xen/arch/x86/include/asm/hvm/svm/svm.h
@@ -21,6 +21,17 @@ bool svm_load_segs(unsigned int ldt_ents, unsigned long ldt_base,
                    unsigned long fs_base, unsigned long gs_base,
                    unsigned long gs_shadow);
 
+struct svm_domain {
+    /* OSVW MSRs */
+    union {
+        uint64_t raw[2];
+        struct {
+            uint64_t length;
+            uint64_t status;
+        };
+    } osvw;
+};
+
 extern u32 svm_feature_flags;
 
 #define SVM_FEATURE_NPT            0 /* Nested page table support */
diff --git a/xen/arch/x86/include/asm/hvm/svm/vmcb.h b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
index 28f715e376..3d871b6135 100644
--- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h
+++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
@@ -548,17 +548,6 @@ struct vmcb_struct {
     u64 res18[291];
 };
 
-struct svm_domain {
-    /* OSVW MSRs */
-    union {
-        uint64_t raw[2];
-        struct {
-            uint64_t length;
-            uint64_t status;
-        };
-    } osvw;
-};
-
 /*
  * VMRUN doesn't switch fs/gs/tr/ldtr and SHADOWGS/SYSCALL/SYSENTER state.
  * Therefore, guest state is in the hardware registers when servicing a
-- 
2.49.0



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Fri May 30 09:01:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 09:01:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000607.1380837 (Exim 4.92)
	(envelope-from )
	id 1uKvcG-0000Df-Ic; Fri, 30 May 2025 09:01:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000607.1380837; Fri, 30 May 2025 09: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 1uKvcG-0000DY-DH; Fri, 30 May 2025 09:01:28 +0000
Received: by outflank-mailman (input) for mailman id 1000607;
 Fri, 30 May 2025 09:01:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uKvcE-0000DS-Md
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 09:01:26 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uKvcE-009zfC-06;
 Fri, 30 May 2025 09:01:26 +0000
Received: from [15.248.2.232] (helo=[10.24.67.152])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uKvcE-00ErW2-0o;
 Fri, 30 May 2025 09:01: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=WPUUA+yYZFe02ovXhflROyYZ5o2AFhC1iGttM5xBO9A=; b=g0kBMOpzxRbQVcm9iP/afnrJeT
	Nzf23d6PbCon3+R9gxNoZH5UvCNeoJeDC5aaeayAjc29K4avjd0wYPgmyJm2gGn251bepOKlB/oQz
	711eleeA5UXbAeX3Lju7CQ+ppOtnr7+lHkQ0PsZZep4mg0MO6oK9q3shq+gDPBT/UCI4=;
Message-ID: <36dc6b2a-6dd0-4176-9f7e-a021a2427ed2@xen.org>
Date: Fri, 30 May 2025 10:01:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] xen/arm: Add way to disable traps on accesses to
 unmapped addresses
Content-Language: en-GB
To: "Edgar E. Iglesias" 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
 bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com,
 andrew.cooper3@citrix.com, edgar.iglesias@amd.com,
 Anthony PERARD , Juergen Gross ,
 Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
 <20250529155024.1284227-2-edgar.iglesias@gmail.com>
  
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 29/05/2025 17:23, Edgar E. Iglesias wrote:
> On Thu, May 29, 2025 at 04:59:21PM +0100, Julien Grall wrote:
>> Hi Edgar,
> 
> Hi Julien,
> 
> 
>>
>> On 29/05/2025 16:50, Edgar E. Iglesias wrote:
>>> From: "Edgar E. Iglesias" 
>>>
>>> Add a per-domain way to optionally disable traps for accesses
>>> to unmapped addresses.
>>>
>>> The domain flag is general but it's only implemented for ARM for now.
>>>
>>> Signed-off-by: Edgar E. Iglesias 
>>> ---
>>>    tools/libs/light/libxl_arm.c  |  3 +++
>>>    xen/arch/arm/dom0less-build.c |  3 +++
>>>    xen/arch/arm/domain.c         |  3 ++-
>>>    xen/arch/arm/domain_build.c   |  3 ++-
>>>    xen/arch/arm/io.c             | 36 +++++++++++++++++++++++++++++++++--
>>>    xen/common/domain.c           |  3 ++-
>>>    xen/include/public/domctl.h   |  4 +++-
>>
>> Looking at the changelog, I saw you removed the go bindings (although, they
>> were in patch 3). But I don't quite understand why.
> 
> I got a little confused. The file tools/golang/xenlight/helpers.gen.go
> has the following at the top:
> // Code generated by gengotypes.py. DO NOT EDIT.
> // source: libxl_types.idl
> 
> 
> So I got the impression that we shouldn't be editing it.
> Should I edit it manually? Or should I try to rerun gengotypes.py
> to generate these bindings?

As the file is checked in, I think we expect the developper to rerun 
gengotypes.py. Anthony, can you confirm?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri May 30 09:23:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 09:23:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000624.1380845 (Exim 4.92)
	(envelope-from )
	id 1uKvxY-0003On-7l; Fri, 30 May 2025 09:23:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000624.1380845; Fri, 30 May 2025 09:23:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKvxY-0003Og-4q; Fri, 30 May 2025 09:23:28 +0000
Received: by outflank-mailman (input) for mailman id 1000624;
 Fri, 30 May 2025 09:23:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKvxW-0003Oa-34
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 09:23:26 +0000
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com
 [2a00:1450:4864:20::335])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bcd1a597-3d37-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 11:23:25 +0200 (CEST)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-450cfb790f7so11948315e9.0
 for ; Fri, 30 May 2025 02:23:25 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4efe6cd15sm4345971f8f.39.2025.05.30.02.23.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 02: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" 
X-Inumbo-ID: bcd1a597-3d37-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748597004; x=1749201804; 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;
        bh=WEyEGMyU1pvXuoFS2NLAkTcr5cnDP17ya1O8uwS+6BM=;
        b=ThIhUO4SPwosRtQt7XizkK4FyTjjz/AtEUQgZLJx6Gr0bKEEsdJTn0CRBDa10kEWQ9
         6BnnI78kqBIB46NLkDKog89Fba7JI99OA/VEMmqtmS5sn9xB6SRijN98ztAyixF3jXSc
         33SS/p49CQP8KGN8fgKCv1rDYPTs9sNgztSm4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748597004; x=1749201804;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=WEyEGMyU1pvXuoFS2NLAkTcr5cnDP17ya1O8uwS+6BM=;
        b=xErd3IZREKP+D1RfEhWeK7QKNK+0pap/JpEXLu7woY3C7rL6yTeayUe9aTgcubL9Du
         nUsXstEW555ZGiqOtV+luwuRRls00p91twmBLPViTIzQv00e3rg9n4SOucgeP1xNa5rR
         4gn92JlCreXm0N6g0aw4lzrfc7EeMjNyod+eascbhIY86M1zzJQ+MrFW8RXqZXTHZyhf
         LJqdvRdn5p5xp/UxZCKNfDP97dKleYPTZ6U6cIBj4FHYAGagBPWOFSVYMX5xL1YpiMIb
         vxlV5Y63qzCng0tkWKHFgv0lpv1Y8RBn15FFaxHcGoI5iPT+8NZxX/R5B9Nd+Lg3WmM3
         uGaA==
X-Gm-Message-State: AOJu0Yxqka6iOuDX3y7R5DZdBMSMGaLiPMrHmDBUl8Nop+Fg2U+hFKdn
	FL6B+0h5oCIGNs7qhiHIXX3jv2slH4GT/vkZ1B0Ff+hxs4swM9cQXvGIE+FxUjgALC7sggNuoPd
	Ie2Mv
X-Gm-Gg: ASbGncuDJjHY0p7LP2YFlaYB9TForeNOBVyowat3o5Xxq69VUBnL1rUmud5lpijxi6G
	j4XgmAS5u7ayONBulHi1CjHhhLxbLWCVDXVDypqH2T61+ohuIHc1d70LNH/xH4D3oxJd+tZYyK9
	Gb7E9WjzLGqkH5FkbUs9vFGcRj+NRDxm6XUhfQlmAOTsMai+OA9q9kCuIVSSgCGuSbWkrhMQin0
	sHRcWtW52Q5pHYpdVMak56G7sgz+dkRD8kMNmY34IE/pGoA/2ZZSCDQyV+6s+jLIaygdUPu5rZm
	nR8SGqmyiZNHXiUNdt1hZHDOG+D4b9yoPT3q1zLH9WLlEybXwTG9yK79+zFMNhQARO+PSwxxZ4W
	DuWCx2ojji9ktH2fvVXLboFzeCiyYGe533lk8G22qzCCB2A==
X-Google-Smtp-Source: AGHT+IHsEBqNWRBAtMOi32FFf9P3D4/B+kWwKCwn6A0IAy6z9oHMOK8QPwctqWnBVpkTglXHIaRl4A==
X-Received: by 2002:a05:600c:871b:b0:43c:efed:733e with SMTP id 5b1f17b1804b1-450d65306dfmr23751465e9.14.1748597004041;
        Fri, 30 May 2025 02:23:24 -0700 (PDT)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Anthoine Bourgeois 
Subject: [PATCH] x86/hvmloader: don't set xenpci MMIO BAR as UC in MTRR
Date: Fri, 30 May 2025 11:23:14 +0200
Message-ID: <20250530092314.27306-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
have the functionality of a traditional PCI device.  The exposed MIO BAR is
used by some guests (including Linux) as a safe place to map foreign
memory, including the grant table itself.

Traditionally BARs from devices have the uncacheable (UC) cache attribute
from the MTRR, to ensure correct functionality of such devices.  hvmloader
mimics this behaviour and sets the MTRR attributes of both the low and high
PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.

This however causes performance issues for the users of the Xen PCI device
BAR, as for the purposes of mapping remote memory there's no need to use
the UC attribute.  On Intel systems this is worked around by using iPAT,
that allows the hypervisor to force the effective cache attribute of a p2m
entry regardless of the guest PAT value.  AMD however doesn't have an
equivalent of iPAT, and guest PAT values are always considered.

Linux commit:

41925b105e34 xen: replace xen_remap() with memremap()

Attempted to mitigate this by forcing mappings of the grant-table to use
the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
into account to calculate which PAT type to use, and seeing the MTRR cache
attribute for the region being UC the PAT also ends up as UC, regardless of
the caller having requested WB.

As a workaround to allow current Linux to map the grant-table as WB using
memremap() special case the Xen PCI device BAR in hvmloader and don't set
its cache attribute as UC.  Such workaround in hvmloader should also be
paired with a fix for Linux so it attempts to change the MTRR of the Xen
PCI device BAR to WB by itself.

Overall, the long term solution would be to provide the guest with a safe
range in the guest physical address space where mappings to foreign pages
can be created.

Some vif throughput performance figures provided by Anthoine from a 8
vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:

Without this patch:
vm -> dom0: 1.1Gb/s
vm -> vm:   5.0Gb/s

With the patch:
vm -> dom0: 4.5Gb/s
vm -> vm:   7.0Gb/s

Reported-by: Anthoine Bourgeois 
Signed-off-by: Roger Pau Monné 
---
I don't think the ACPI tables builder consume the PCI window size
information, I'm not seeing any consumer of the acpi_info->pci_{min,len}
fields, yet I've keep them covering the xenpci device BAR, hence the
adjustment to hvmloader_acpi_build_tables() part of this patch.
---
 tools/firmware/hvmloader/config.h |  2 +-
 tools/firmware/hvmloader/pci.c    | 40 +++++++++++++++++++++++++++++--
 tools/firmware/hvmloader/util.c   |  2 +-
 3 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index 6e1da137d779..c159db30eea9 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -58,7 +58,7 @@ extern uint32_t *cpu_to_apicid;
 #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
 
 extern uint32_t pci_mem_start;
-extern const uint32_t pci_mem_end;
+extern uint32_t pci_mem_end;
 extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
 
 extern bool acpi_enabled;
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index c3c61ca060a6..7c339cb8b9f7 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -30,7 +30,7 @@
 #include 
 
 uint32_t pci_mem_start = HVM_BELOW_4G_MMIO_START;
-const uint32_t pci_mem_end = RESERVED_MEMBASE;
+uint32_t pci_mem_end = RESERVED_MEMBASE;
 uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
 
 /*
@@ -281,6 +281,42 @@ void pci_setup(void)
             if ( bar_sz == 0 )
                 continue;
 
+            if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
+                   PCI_BASE_ADDRESS_SPACE_MEMORY) &&
+                 vendor_id == 0x5853 &&
+                 (device_id == 0x0001 || device_id == 0x0002) )
+            {
+                if ( is_64bar )
+                {
+                     printf("xenpci dev %02x:%x unexpected MMIO 64bit BAR%u\n",
+                            devfn >> 3, devfn & 7, bar);
+                     continue;
+                }
+
+                if ( bar_sz > pci_mem_end ||
+                     ((pci_mem_end - bar_sz) & ~(bar_sz - 1)) < pci_mem_start )
+                {
+                     printf("xenpci dev %02x:%x BAR%u size %llx overflows low PCI hole\n",
+                            devfn >> 3, devfn & 7, bar, bar_sz);
+                     continue;
+                }
+
+                /* Put unconditionally at the end of the low PCI MMIO hole. */
+                pci_mem_end -= bar_sz;
+                pci_mem_end &= ~(bar_sz - 1);
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+                bar_data |= pci_mem_end;
+                pci_writel(devfn, bar_reg, bar_data);
+                pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY;
+
+                /* Prefix BAR address with a 0 to match format used below. */
+                printf("pci dev %02x:%x bar %02x size "PRIllx": 0%08x\n",
+                       devfn >> 3, devfn & 7, bar_reg,
+                       PRIllx_arg(bar_sz), bar_data);
+
+                continue;
+            }
+
             for ( i = 0; i < nr_bars; i++ )
                 if ( bars[i].bar_sz < bar_sz )
                     break;
@@ -320,7 +356,7 @@ void pci_setup(void)
         }
 
         /* Enable bus master for this function later */
-        pci_devfn_decode_type[devfn] = PCI_COMMAND_MASTER;
+        pci_devfn_decode_type[devfn] |= PCI_COMMAND_MASTER;
     }
 
     if ( mmio_hole_size )
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 2d07ce129013..fd107818da35 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -874,7 +874,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
         config->table_flags |= ACPI_HAS_HPET;
 
     config->pci_start = pci_mem_start;
-    config->pci_len = pci_mem_end - pci_mem_start;
+    config->pci_len = RESERVED_MEMBASE - pci_mem_start;
     if ( pci_hi_mem_end > pci_hi_mem_start )
     {
         config->pci_hi_start = pci_hi_mem_start;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 10:25:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 10:25:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000664.1380855 (Exim 4.92)
	(envelope-from )
	id 1uKwv4-0002eL-GZ; Fri, 30 May 2025 10:24:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000664.1380855; Fri, 30 May 2025 10: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 1uKwv4-0002eE-E2; Fri, 30 May 2025 10:24:58 +0000
Received: by outflank-mailman (input) for mailman id 1000664;
 Fri, 30 May 2025 10:24:57 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKwv3-0002e8-5D
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 10:24:57 +0000
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [2a00:1450:4864:20::432])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5441fe79-3d40-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 12:24:55 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a37ed01aa0so1540563f8f.2
 for ; Fri, 30 May 2025 03:24:55 -0700 (PDT)
Received: from gmail.com (163.red-2-139-141.dynamicip.rima-tde.net.
 [2.139.141.163]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d8000e9asm13960185e9.21.2025.05.30.03.24.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 03: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" 
X-Inumbo-ID: 5441fe79-3d40-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748600694; x=1749205494; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=1X9rxMVPFyCu2AkEbqxPhYR/MPNJ6FHvSsL1T/B5CtY=;
        b=U6BRp0P2XYX88lTtyl/weXwAJL66Go//YjpEFN3Ux35bvWnN09u2x8l/ydl2gt+BjG
         j8FO1Q28yi9yZcZJ28MK7NXV3WwLKjUFWYy/G0RfQfbHp7h4Xgz9EDYmyJ+gzNZStM9n
         9JRpaW6fB22RzuB4ef0ryc/kdeptrb4qm3ScYmvGkNz/EHvOWfPx8ebza6ff2AHfPI/D
         czb+TvQatgDZwgVK6GEBmOnxc6W9bcXvCLq9tyH6RautMNGVYjjEUGjcdjZDN7XpHBqe
         JSGhUjhz3UvAsFClp/Lf/8ZTpL6YkPjjuJ0oxPHehQc1X52Hb2OH0+bMjLMY0HLWn5DZ
         9PFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748600694; x=1749205494;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=1X9rxMVPFyCu2AkEbqxPhYR/MPNJ6FHvSsL1T/B5CtY=;
        b=ClumSizS/J4EIuIda6EqomZvu8AhxJuVbNyADIGExuFZYYcGcen11j/N2rGGbqE+MZ
         Pi9XHEU4XxNyGXaDrIh2fiQ67OHqhaZ74UeqS4Btmed65XJ6iBVf+S/4uygoTNlm34v+
         SqFka2TWpIrBN0359xTkU6XalBDSpee1HKBhu9K6QpaEy5nPs5HXTx560l4P4F1MmVmr
         7EHzaJUI6eLCDFA9UDmMkY3MqTheVYNJuAS/yTgGH44yep4x+EAoYAJqCHvLp1MCUCAF
         Kdg6RJQNIAs+SeQYRVJKKOZAmiBo57qyoRH53O/q7CgzbQXL3Oaa4Ww7TucsAY3ilTIz
         pvfg==
X-Gm-Message-State: AOJu0YzwW3B0dZq+kIdeXnuqX6ydfbZVDKGwSVcZAmALQB/mg6zO+tRt
	bjK0UXY7XuH3UVFa0CnbWeQCA8kQ3R5oocGhd5lbrWz09y+Uw0yWt7gaJDWZHKF5tKDw1A==
X-Gm-Gg: ASbGncuEbB+4yLcCWV1g9myEue1ftldbSuDOGnwvoL4q1R6fxMoXLWL5C6kHrzVSlnm
	euAajoYN2AaXBpwVbgQnhN9AL7mlFNcBY+4LwVmdmVW1y0YnJ28NdUG9eY+xzmh+xaL3z/yPAaH
	EYAD0uBeS5lsb8/tpG/c1bHxF9a4qQMRvvy5eU44O/84pUYGLuRuFQPTQeejhQ6K0vmBxtaaU6n
	HvQUy2czvzUSVCRhq1ebL7NwA+LwaEdbn3Vijqs17QU4Mtz4c9Ze3noPZxG/gsz/JnNSolQakMz
	yyqSAI9OvG+/bTD0urLXuqwFXnkUKFQmqFBxhdeJbcyg/TGb//nLzUPbJoMyQTaVry0ittst6Uh
	MC9LJl9ODW785tT0N7k5qRr5z28iH
X-Google-Smtp-Source: AGHT+IGobE8D9Toxi9X3qI1AGxlvvF1VmPQsB6OvKbpf/Cc/KmYOzBV7OSdW4Xs6nYrVMftQmKYVyw==
X-Received: by 2002:a05:600c:8207:b0:43c:fa24:873e with SMTP id 5b1f17b1804b1-450d652794amr27149965e9.13.1748600684043;
        Fri, 30 May 2025 03:24:44 -0700 (PDT)
Date: Fri, 30 May 2025 12:24:42 +0200
From: Anthoine Bourgeois 
To: Roger Pau Monne 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	Anthoine Bourgeois 
Subject: Re: [PATCH] x86/hvmloader: don't set xenpci MMIO BAR as UC in MTRR
Message-ID: 
References: <20250530092314.27306-1-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250530092314.27306-1-roger.pau@citrix.com>

On Fri, May 30, 2025 at 11:23:14AM +0200, Roger Pau Monne wrote:
>The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
>have the functionality of a traditional PCI device.  The exposed MIO BAR is
>used by some guests (including Linux) as a safe place to map foreign
>memory, including the grant table itself.
>
>Traditionally BARs from devices have the uncacheable (UC) cache attribute
>from the MTRR, to ensure correct functionality of such devices.  hvmloader
>mimics this behaviour and sets the MTRR attributes of both the low and high
>PCI MMIO windows (where BARs of PCI devices reside) as UC in MTRR.
>
>This however causes performance issues for the users of the Xen PCI device
>BAR, as for the purposes of mapping remote memory there's no need to use
>the UC attribute.  On Intel systems this is worked around by using iPAT,
>that allows the hypervisor to force the effective cache attribute of a p2m
>entry regardless of the guest PAT value.  AMD however doesn't have an
>equivalent of iPAT, and guest PAT values are always considered.
>
>Linux commit:
>
>41925b105e34 xen: replace xen_remap() with memremap()
>
>Attempted to mitigate this by forcing mappings of the grant-table to use
>the write-back (WB) cache attribute.  However Linux memremap() takes MTRRs
>into account to calculate which PAT type to use, and seeing the MTRR cache
>attribute for the region being UC the PAT also ends up as UC, regardless of
>the caller having requested WB.
>
>As a workaround to allow current Linux to map the grant-table as WB using
>memremap() special case the Xen PCI device BAR in hvmloader and don't set
>its cache attribute as UC.  Such workaround in hvmloader should also be
>paired with a fix for Linux so it attempts to change the MTRR of the Xen
>PCI device BAR to WB by itself.
>
>Overall, the long term solution would be to provide the guest with a safe
>range in the guest physical address space where mappings to foreign pages
>can be created.
>
>Some vif throughput performance figures provided by Anthoine from a 8
>vCPUs, 4GB of RAM HVM guest(s) running on AMD hardware:
>
>Without this patch:
>vm -> dom0: 1.1Gb/s
>vm -> vm:   5.0Gb/s
>
>With the patch:
>vm -> dom0: 4.5Gb/s
>vm -> vm:   7.0Gb/s
>
>Reported-by: Anthoine Bourgeois 
>Signed-off-by: Roger Pau Monn 

Also
Tested-by: Anthoine Bourgeois 


From xen-devel-bounces@lists.xenproject.org Fri May 30 10:43:23 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 10:43:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000672.1380866 (Exim 4.92)
	(envelope-from )
	id 1uKxCm-0005Kn-Vt; Fri, 30 May 2025 10:43:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000672.1380866; Fri, 30 May 2025 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 1uKxCm-0005Kg-SQ; Fri, 30 May 2025 10:43:16 +0000
Received: by outflank-mailman (input) for mailman id 1000672;
 Fri, 30 May 2025 10:43:15 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKxCl-0005Ka-Qo
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 10:43:15 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e1200739-3d42-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 12:43:10 +0200 (CEST)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a376ba6f08so1124163f8f.1
 for ; Fri, 30 May 2025 03:43:10 -0700 (PDT)
Received: from localhost.localdomain (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4efe73eadsm4392675f8f.41.2025.05.30.03.43.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 03: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" 
X-Inumbo-ID: e1200739-3d42-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748601789; x=1749206589; 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;
        bh=FcIkInxbMiL4bR2A67xJ46+UWHa19mS6X2LgqbhTGfg=;
        b=Gh7rWU3E57om5LihnXotz2jf0wz33ZnZj+asFBwOLs1JOWDEu5XnGG2dX/RYGoKuEV
         qPCeybwMFTP5cRxERgtYAe5xdiNyGK+0Ls8yDHknv+dr7I9YhnATg606yhRcxWsbQye7
         JWYuq+ErHqVSRZ4lu3dNTwPlC4YJD5AYAVG8s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748601789; x=1749206589;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=FcIkInxbMiL4bR2A67xJ46+UWHa19mS6X2LgqbhTGfg=;
        b=e22ly3ukgAjyx0hCWMfEOXIJeChF7u0MescpqXCE3BZaOxp5XhIJs1Yw6k/2mzuveZ
         r7fgsYYH0W0Ea/V0CW/4ZGpgpBhScB7qXCep6XXOWZWDkXaH2bbN0x7X7KprMIeS5SA9
         EwMdhqfzqHowV5RitG80evC6XHJ7Mi1TRi8sd+3okFIKVYQakaVXYwyiDvkbzOpOxoHx
         9z3f4UeGKgXMYoAphWExEIcb7GMFCodBAsi2P7/nIrHWo37HLtC+8C4oKpCKDMvVck/R
         8f0zawPKm0Yh9PLGY1/asqvE3o7CGO4VwHFcND+WYarmf1sr48s/QRY8Ygx9qbR2toxb
         RyPA==
X-Gm-Message-State: AOJu0YxUzTxPTWAF5QUs58F3y9esL1ShMPT2T37eIENM5VkMKYmRIB8c
	LDpN4qfZb5Sq20utOivzTO2kpX+32uraRjpSfu0cPs5n0PJTbqaYDRD/8b7AApCpqwST7ZAzyxf
	9tkQa
X-Gm-Gg: ASbGncseRYfiZ6BDLet1ZlBW8x5OYzELp9dUg7XLF+2lPGs/8c4gWR7LGLm/zxxHpX3
	eCr5Q8Rnd8+HUllB5uPRNzZavRHX+SppQoeop/xVdmZlMRR051ig51EAlmizH+igulI0x1EftjJ
	cY2tVAOFv8dCPqCAfIcA0FjNfYAg7IxxNUd4Bs78bkM4CsQvGhVtGZRZ/6n4vWdDkdxUg+2x8Fp
	BmbJle45waBF/WF+p6VIgZrYPCJdqOkZSO/SWrw5BaRQksDfmTm7CQv/c/3GSkLNDPOr14LqmFm
	pS4h3gfhW+jJ6AULUP4Xm+NoREBSCoeK+Htbkfe2GLax/1Qbcah2qa5G7e5IlY5QtRdmMixN9EV
	ZBu73TgV52O44Ywxq8vzqY/61ML0+BJsNNFg=
X-Google-Smtp-Source: AGHT+IGDYISf3/g51HqL2cpRRBysUFU8zZ+xhWlbQGaunBxzVmrsq5xsbMaHdjAaM52c+P0Tiszy4A==
X-Received: by 2002:a5d:58dc:0:b0:3a4:f7db:6ff7 with SMTP id ffacd0b85a97d-3a4f7db764cmr1630713f8f.52.1748601789617;
        Fri, 30 May 2025 03:43:09 -0700 (PDT)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD 
Subject: [PATCH] tools/tests: Add install target for vPCI
Date: Fri, 30 May 2025 11:43:07 +0100
Message-Id: <20250530104307.2550886-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

This lets it run automagically in CI.

Signed-off-by: Andrew Cooper 
---
CC: Roger Pau Monné 
CC: Anthony PERARD 
---
 tools/tests/vpci/Makefile | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
index 62f21f341a01..9450f7593a41 100644
--- a/tools/tests/vpci/Makefile
+++ b/tools/tests/vpci/Makefile
@@ -21,7 +21,13 @@ clean:
 distclean: clean
 
 .PHONY: install
-install:
+install: all
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests
+	$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC)/tests
+
+.PHONY: uninstall
+uninstall:
+	$(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$(TARGET)
 
 vpci.c: $(XEN_ROOT)/xen/drivers/vpci/vpci.c
 	# Remove includes and add the test harness header
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri May 30 10:57:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 10:57:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000679.1380877 (Exim 4.92)
	(envelope-from )
	id 1uKxQR-00073i-5Q; Fri, 30 May 2025 10:57:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000679.1380877; Fri, 30 May 2025 10:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKxQR-00073b-18; Fri, 30 May 2025 10:57:23 +0000
Received: by outflank-mailman (input) for mailman id 1000679;
 Fri, 30 May 2025 10:57:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKxQP-00073V-Rd
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 10:57:21 +0000
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [2a00:1450:4864:20::42e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dbbffcb7-3d44-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 12:57:20 +0200 (CEST)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3a36e090102so1048657f8f.2
 for ; Fri, 30 May 2025 03:57:20 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 ffacd0b85a97d-3a4f009fb0bsm4413236f8f.87.2025.05.30.03.57.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 03:57:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: dbbffcb7-3d44-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748602640; x=1749207440; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=gzN+d5AU9IFXMQNv/t5MKT0mQGD5TeEy64oR1pM3fgw=;
        b=Cmo789i2WGZYzMuUIVzEwbsxKxXm76p3cNrlFlUi8Uc3SL8jNXEbjO04ldT5tDslnm
         Y0WMvtq3BB73iLnUlKZ0lr166/ew+pGs0phesdUSLp0hFFpmSBvWbM4KLzLX+zqsR+wl
         A4/NPb8zrd25jlPh7RQ4cLUbxU91JsgNdrMYU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748602640; x=1749207440;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=gzN+d5AU9IFXMQNv/t5MKT0mQGD5TeEy64oR1pM3fgw=;
        b=muP/bVrv9inPSElkk6fa0BBloBa5709z42LcEVghKxBQDDN+eCxZnSqEV6x9XjzuQR
         s7FX/DfrcS5oeCxmy0039IrhUfEsHPpgAkERyzkR2m0l72+2WQufTGXB/CIoKirBxtQ8
         Qc1Pa8FhaNoko0HnLRnA66i8ImLVnbQaulDngG0B4pxVwUBjdhCNwmdmloclh7SYygcE
         VqIvYCwkxoi9dlqKkzKhGQ92h9+8fE/WiJAtTBVwpaSz3vNZLVliUclZANDIvd6Ue0lZ
         kJblER3afNzuQxWIFlN64CMBG7Q+kELXnH+8cyqfs/bYirvnTbPYb8w28RJgnRa9zhEg
         WKww==
X-Gm-Message-State: AOJu0Yx/nIl+fV38h/kn0poO9tTCa3rde45+Dz0oJtcj0HQf+GEVjEGE
	ZnOrt7/qDZDwPiOEiCjcNkzV8luLOcgQq/gGgXO6j480vbB+yZJmXkkQA5OcHDX8xAgMvqxlG33
	vyumk
X-Gm-Gg: ASbGncue2obuzasMAHxZbLOEkKtk1pw/v48JZ+ZCXhrfevadRVvRxF16Xt0WqWKyjFF
	Sj49MkT2tCKFGM7KxQqjq24vTHv18dRAXCIVAiJ8bBZ5eYARdSf5mYFg+PlDNCNNLhlYJeiVBpD
	+VzRcM9e60fxoYBYIXWxnHaiQc32v7uvyzqn0ejlHefeyrXKoIMrjBkjM+gJgBbSW1/LxmQ6kCe
	Y9Gkvh4TRTxcI/9gs2ykZbQAxnO6jf2XlISaxgaEj0cbjrAfrzV7KsiQ0E0Mc2Vb4kZainroAD/
	JazeDhtX0c5zw0seQW0+GVUoQIxTwUK6FDub48n10Ghv+Sl4Fv+m5bQ/eGmqaWiipEJz0+tUpdo
	HXqJq32ycxyJy8AMze6e1mfgD
X-Google-Smtp-Source: AGHT+IGqSNWBsnNZ3udp21KJx5cyEybnV4xZBXKiF2m72zkF9RHvPhyeEEjR36+d6qT8tXq4APJ7bw==
X-Received: by 2002:a05:6000:2c12:b0:3a4:e4ee:4ca9 with SMTP id ffacd0b85a97d-3a4f7a1ccb3mr2244494f8f.23.1748602639725;
        Fri, 30 May 2025 03:57:19 -0700 (PDT)
Date: Fri, 30 May 2025 12:57:18 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD 
Subject: Re: [PATCH] tools/tests: Add install target for vPCI
Message-ID: 
References: <20250530104307.2550886-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: <20250530104307.2550886-1-andrew.cooper3@citrix.com>

On Fri, May 30, 2025 at 11:43:07AM +0100, Andrew Cooper wrote:
> This lets it run automagically in CI.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Roger Pau Monné 

I had sent something similar long time ago:

https://lore.kernel.org/xen-devel/20230313121226.86557-1-roger.pau@citrix.com/

But got no reviews.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 30 12:03:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:03:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000713.1380932 (Exim 4.92)
	(envelope-from )
	id 1uKySK-00087A-8A; Fri, 30 May 2025 12:03:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000713.1380932; Fri, 30 May 2025 12:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKySK-000866-2Q; Fri, 30 May 2025 12:03:24 +0000
Received: by outflank-mailman (input) for mailman id 1000713;
 Fri, 30 May 2025 12:03:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySH-00076q-SG
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:21 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2412::61c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 14673029-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:21 +0200 (CEST)
Received: from MW4P222CA0028.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::33)
 by MN0PR12MB5810.namprd12.prod.outlook.com (2603:10b6:208:376::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Fri, 30 May
 2025 12:03:17 +0000
Received: from CH2PEPF00000143.namprd02.prod.outlook.com
 (2603:10b6:303:114:cafe::57) by MW4P222CA0028.outlook.office365.com
 (2603:10b6:303:114::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Fri,
 30 May 2025 12:03:16 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000143.mail.protection.outlook.com (10.167.244.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:16 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 14673029-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UrAflS6M7rXsLjmUvpnGe6cZBX6i09cxKrt8Cp8BmyNjdXLasPOTMGvFnnAym++Pykc404PHW6U/BLT9n8qO1eD193oCkAI8QNfpRD9A3+GCv+9tPfjSUM/Wq35RCO4C1bW3xSzGJTPaYayQqAt76INHU3pOPqIQ9GiH9xlmoLPHpcmUcDuZvCvzH0k9J3NJM0+xm335GZ9BlI8tSDi4EM3OLMS6Qc42N8l1A4a3dbhwYEKWilTmbCBgqTld0pTiAP5AW3NkeneR7tJyQlopmr3vN87LV+UouJrxbEKweT4Rdo4njEO6RwEDU7TG0jNibNv4xMu3BtZDrkDigX93ww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CB6uSAbe+0xw4xE8YOobIV7kviFvgyyKz9p/QbVCOyc=;
 b=j51PQMdVuI2uHeHKp5V1YAoNHUBq9AuGVn8n7GBnXjrVVNoo+TgExz4AYC69SWoGDmgWYjEATfVEIRwL9d0krLm5wXbGIWUxIQbFFXNLvcQOdLPSVxnFB20V65l7ZdmKP9R4LM90I7txjXzBFuVimJmC6ppm1rdTyOGBmaG9SVDt03EaD2E2FOgpxVoKbK2dijiX1qLI+93XXbsbpQ6pEiIERxa/SJjXI7OMxIwjhP7xtZRdrGswEkpZfcy4l4NbpppXOmNQQbOtKVuzKyMH74Te3rP0dkNfPuSJNuAq3Wxzh1vhKc/jrzjjws6xOU83MchpE3RQMKQd/a19LJedGA==
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=CB6uSAbe+0xw4xE8YOobIV7kviFvgyyKz9p/QbVCOyc=;
 b=2kGgJxFG6CYcegwJ9h1zp3X11/+JAmtA4LP/grKbQ4wK4qD+007gfMBI1g8Vi/p/pE2w5gphvICuMcDaQ7P2RVz72oZi87Coy2cXDftV3khP59j02qPY7y9a8hXwZqSu0r4d5XfIeve6RRZnQq1752MYxeGwEwaWDwL3g0i0QPQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , "Daniel P. Smith"
	
Subject: [PATCH 05/19] arm: Remove dependencies with membank(s) definitions from setup.h
Date: Fri, 30 May 2025 14:02:13 +0200
Message-ID: <20250530120242.39398-6-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000143:EE_|MN0PR12MB5810:EE_
X-MS-Office365-Filtering-Correlation-Id: 524d2aa7-efad-4b14-274f-08dd9f71f632
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Bae3R9cVDxLgMYyelWZPlaFhIZ6LzxqbpiOur0bJ5iDAPjTKKHCRVl7olOaI?=
 =?us-ascii?Q?5bgakf4vF+c9dqnaYNcpTftx7+NL+H7E0+feKGugf9hzfKQ9PYGd/BVAvinX?=
 =?us-ascii?Q?hWxj6NUZkU1Y5186sRbGB3oWbGq60qKUKXRgUAdDYZRIROMuA2FV1RsLWnt0?=
 =?us-ascii?Q?QIIlJVyIcxBkLx4Ok4L83GB70gPOrmicu5a7XWzANcQZBpIY7GXJygssojGT?=
 =?us-ascii?Q?71ihAysAwfAuT49lmoosoMA4y6oed5QikfezQCZF7whBftpOUwdeHKRfBhYI?=
 =?us-ascii?Q?3VNxZKMgdFakxI9+RWe2obCoZ/RqMp1YhnRUc8EhoWRNu1Z1Zr8fZFm06/IF?=
 =?us-ascii?Q?XC/cnwr+CUX7DVm9gABYKnNMa9oWz48ESfOx/PLeNx1iqfZxC6Lz9WJROhCK?=
 =?us-ascii?Q?X0zE+Z3Ow/FTASBnsg0AK6KpSYN9Kjuz4/FM7ZPi5V0kfqskYygPnkZZ90ft?=
 =?us-ascii?Q?EjRviZOs9Y2lEeTjw6r59kR8clkxLLgCWm7NQk0fymvlQmMszBT4WGOHXrNo?=
 =?us-ascii?Q?56tN5WipHlPtA6MlygF4mMjT7HDNjPCWNU1j79w8mGD1TA/qkWnBLv5guZSN?=
 =?us-ascii?Q?M+sIDQXdaFVIY7UPPEYZV3tAm4jl3KoO99461baJ6Rzi94Bp2vekywlQ8SCy?=
 =?us-ascii?Q?MwQrBF1n9YhcVZ4IM0B0scdAae63wQNaZlfXb+LoqfEfWvw+QtRv7zQv6CjM?=
 =?us-ascii?Q?xqhrm3KPV/ZhN9BJDSiZC3HY/1IweU3/sX1auF5AkVlv8pl+eHiPWW0WS6Zl?=
 =?us-ascii?Q?6o2VZXsBDjShRrUWZ1JiYWTXTjn3bgS2VgQDuVWaMtvsXlY6NHFbGTRXYZy5?=
 =?us-ascii?Q?G6M+e+kmvMgNNh9c+O10kliNJ7eZ30P6VY2DvMpLKCJCDSoewnQ2uRG1K/YY?=
 =?us-ascii?Q?4IMKXNgz6vBiDhH9lIO4aoCl1/IMb/3kxjTvJ3yC0OJRtda9/oaZcMoJE1uO?=
 =?us-ascii?Q?sFPAyfR5T12ZAGjBHo5awfA001K4dd4Rd659+l2x+H88MIKyWDbg/eWHDg6z?=
 =?us-ascii?Q?Xuot+RnkOF3FHLsBirItSeQucU7slbE6SLA6SKRgWmuFHBlDFnRtw55MVe4f?=
 =?us-ascii?Q?a2Ps10vB3UZKQCK2Ws+s5jIJF/tXx0o6TvsA0O91Cpn8D4WBeY/XkCsn+pr1?=
 =?us-ascii?Q?qEs7nIhIYFx7pWoZf+RFS/tsNZFC1ILtQiJJZ8EjqBdJz97kpzcooO5sGQxf?=
 =?us-ascii?Q?wTl0vqkSwdSILuWsgOSLdEHHWwGacx6429lTCkNoqPxudE6/dEfxcvrHTjeZ?=
 =?us-ascii?Q?w3udC8UM0h0TQGrTaUW3XEklChlEW1FKa11cBYVkGKdMRecM8cFe99pRJKpu?=
 =?us-ascii?Q?oSN5BHDm4kyJ7WoJ/huB83+rvK9fzwzOZ8xgYk9kDKGYdPht1vjcxXSW8drE?=
 =?us-ascii?Q?Yf3iOuIm3953NYpwKno2ejRca8J0uri8cnkLZ1+XBM3pOfIhn773roRM/9qW?=
 =?us-ascii?Q?qaT4ufumC1DXKg2Ba1h0K0//d4brYgPR3XIiV89NoTO3cyvYf1ewz+5a0Ar8?=
 =?us-ascii?Q?EqxG44R+sWQZ+EtIhz1QPMLemk9VLpoOb9Cj?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:16.6504
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 524d2aa7-efad-4b14-274f-08dd9f71f632
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000143.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5810

... as they can be forward-declared changing arrays for pointers in the function
declarations.

No functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/arm/include/asm/setup.h | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 6cf272c160..0f9e531a34 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -3,7 +3,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #if defined(CONFIG_MMU)
@@ -14,6 +13,9 @@
 
 #define MAX_FDT_SIZE SZ_2M
 
+struct membank;
+struct membanks;
+
 struct map_range_data
 {
     struct domain *d;
@@ -32,13 +34,13 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
 size_t estimate_efi_size(unsigned int mem_nr_banks);
 
 void acpi_create_efi_system_table(struct domain *d,
-                                  struct membank tbl_add[]);
+                                  struct membank *tbl_add);
 
 void acpi_create_efi_mmap_table(struct domain *d,
                                 const struct membanks *mem,
-                                struct membank tbl_add[]);
+                                struct membank *tbl_add);
 
-int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]);
+int acpi_make_efi_nodes(void *fdt, struct membank *tbl_add);
 
 void create_dom0(void);
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:03:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:03:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000709.1380896 (Exim 4.92)
	(envelope-from )
	id 1uKySE-0007Kj-5O; Fri, 30 May 2025 12:03:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000709.1380896; Fri, 30 May 2025 12:03: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 1uKySE-0007Kb-2k; Fri, 30 May 2025 12:03:18 +0000
Received: by outflank-mailman (input) for mailman id 1000709;
 Fri, 30 May 2025 12:03:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySC-00076q-SS
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:16 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20612.outbound.protection.outlook.com
 [2a01:111:f403:2415::612])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 110c29ae-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:16 +0200 (CEST)
Received: from MW4P222CA0020.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::25)
 by IA1PR12MB6284.namprd12.prod.outlook.com (2603:10b6:208:3e4::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Fri, 30 May
 2025 12:03:12 +0000
Received: from CH2PEPF00000143.namprd02.prod.outlook.com
 (2603:10b6:303:114:cafe::22) by MW4P222CA0020.outlook.office365.com
 (2603:10b6:303:114::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Fri,
 30 May 2025 12:03:12 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000143.mail.protection.outlook.com (10.167.244.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:11 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03:08 -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" 
X-Inumbo-ID: 110c29ae-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GElndKOkiJUAUW/w1FNZ82qllyMNIKHwCZ2eAoLTdN9/qNzHTunAr8MpDFSEeaGW4wZ4JpZeISFTy0mA6LaHYbbXXUQoiiXSVjfoacPvLS5fC5h9c4WMn8Z6+UmFE/IsUilpMG9jt5uuswQsA7Uc6D/5XzVTwmizHaPCpt7/ocJBqgpM99XwWNy8tBkOC6AgB671qITGOURF0MLi7H1ItFfBgEOm4kBAhlQjCtdhCdlvmIHzLqYgOWBifeK1qP8OGxdN0qfG5qUwHlotnDpKmrroTp4cNBx/5zxQAq0uVUsxeKqTGsAA2ofzU9wvf8Accdn6IeRolvZpjC0836RwKg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7W+IdG09q2V5cYYJHkwKMYlqTJGKHIna1geSKV6F7AA=;
 b=GLS/xmZdvkTdoz+qKAUeT+Vf0kiFv7EmuMgXOO4LEngiJbyQDP9j1hYZrErCafuRv3b0VpgLwgoCNoSChoHjkdhvCuBoCbFrQkA4/IxcW5H2TReGHVLi88b5ZWBYKKNskd3KN2VlKw+pO6Hz+yu0ixqZC6dWYKuC6eBgWwNd9f2LpYDqzMJL7vHnXxdUKEooiAXx2aUJE2/kOA/+AP0NDODx1JGimPoMzcqFnDRudVlpmGCSGBPGIvYwvY96t6R1X2BKUOPoYaf+WMCOOSc4nnp08oNahc3QCupGkCbzw3rTTJf2Rxl7/1KZMSx7vrPJFxAEPSpSg/psecuDqbmHzw==
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=7W+IdG09q2V5cYYJHkwKMYlqTJGKHIna1geSKV6F7AA=;
 b=e48aPTwUY+D4EjXB9BApGt6oqm47vsWjhydVbHcVcFxIALuNqhFjzaxsPS98yIIhyyYxR7Bt7llTtKah25y0EOiBQDdq+c0lIRIDarXx5YUT1Wjy/MZbn8hB/tOk48SOzOx3GtAef9ry4giI87ZAeEqjUsF6WLGWoeDNhpLZi+Y=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Daniel P.
 Smith" 
Subject: [PATCH 02/19] x86: Add missing pci_dev forward declaration in asm/pci.h
Date: Fri, 30 May 2025 14:02:10 +0200
Message-ID: <20250530120242.39398-3-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000143:EE_|IA1PR12MB6284:EE_
X-MS-Office365-Filtering-Correlation-Id: bed11e48-bb67-4927-65ab-08dd9f71f34e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?UKIMEIcjSWF/2ZKSXm0OXI7R9bWaB5oopy71E8ISHADMJmCf/5FEvCjyJBEA?=
 =?us-ascii?Q?Ii011HVmJWZHKbSvZKGPF6e/fSomdvyYS8Ro4eeYyc3ImvAXUuAvKpgnrEIw?=
 =?us-ascii?Q?N4OauvoFQbuatXpRpGdlJ0nnOtbC1CLlx7hwgsjoPFsHbT6nKQVtFKB9yQS5?=
 =?us-ascii?Q?nY4DPh+Rht9b1VgNWJck9hLGNM2Aqdxt1VNcp+/4hE5GvpzRfB2jEZ3Ff7Of?=
 =?us-ascii?Q?zy+MgzQyn4MT3szx1l/7KE9Cx6ugMZw8bwFoYijvCabo+bTKsJijEFZgk/jN?=
 =?us-ascii?Q?vOjaFfM8YIgJWzmzSobFRSv6Sx3YRFyhvVKN4V1jmgAJMzVVDevq2GLazDui?=
 =?us-ascii?Q?/+vOcHsB/0zPLIKmqqWbuqnpNS6H2QPEk85iN5Fkw2KAjbp8/GUo0q0AboTJ?=
 =?us-ascii?Q?uR71DSx5AyvHvXGGYogKVFU0iCyS5sPmQWXytqmzoGzyX5KYzGnykGy+amTB?=
 =?us-ascii?Q?vvGXA/47H9NARbzuSthiAmXiZ35Ub+TDBQOQIq/hOiPH0fxt5J2a2KgxY7qz?=
 =?us-ascii?Q?89aRFl5IVY+EQtAqR0n6xNE81J500+K2fr33hbHeO+D2GNIUMaVbVfYDoNC/?=
 =?us-ascii?Q?qRvW59v10ftqKBTUn2dILXuCH8deV5XStb6ovXRaJCXzXdKn0z6XO4w9d8wu?=
 =?us-ascii?Q?NsMqquXzDUzA0sd2hf8Pb8KfhuxVR1gO2FNtFfKMXH24aKtCYomGig45K6ds?=
 =?us-ascii?Q?lvF0moSOrOLURe5W6yCuwEonHBqqtiiFgS4VOA3W007h5V9SqfiYr6PEW59J?=
 =?us-ascii?Q?xxecOCCOtP0Yah7BMdTA0X4AQRAavms77OwSz+lPFtnHbkEdIdf2JwUxx97f?=
 =?us-ascii?Q?ZHS0+DcPtOSsjKbiEXOom6kXphbl7WqJBrc7zjwxGIOhA3I25+Ci5BHBo/JH?=
 =?us-ascii?Q?bkqN2bf5a6OxjNSlZVbGkVVP8yJkpMzhBb7zPKud7MpsIfBBOop1OKxa/tk3?=
 =?us-ascii?Q?IOCuzs3z/Y5s/LSPuVGNknw8vErH3L6Chw4oufe65dAwVrXitHagkYNhsAtl?=
 =?us-ascii?Q?3gj94QzNHtkRHp/O44M5N/vZiiv4fhoFk48J/IU70S4+iTp/TxoHSPVmBFao?=
 =?us-ascii?Q?mFqA8q0P0xNFE5L7L5GF41rTi4Sf54RFwBo7vJXZdcSVdm/pNarvm75AkcUA?=
 =?us-ascii?Q?/bBsN/2+ECLb2FGcgOcAa247KiyginBDhU6XaxTtj7KMQqswDExbfg8A38Pr?=
 =?us-ascii?Q?md4smBEh/Rqmwi48+iOTROrXwpjMqmXMj9bsm4iF0AIOslXLKzQGflN1RcUo?=
 =?us-ascii?Q?IlYW6fZBMLmMUyxzJq1uan02CgImkzkcKltJHhDXygNFqwO7PJbSjMIgshM5?=
 =?us-ascii?Q?lxWPfDc7KNNEs/0bfydVe/bs6xc4c6hyQfur3xD7Nyq8qA4Tl1o0hZT8B20G?=
 =?us-ascii?Q?cJnw7cNOYvQSfkp8aZnmjsDkoKwpli93Tb129rCVSVQniGOxGfpDZ5AcLrtK?=
 =?us-ascii?Q?WSwS/v+NKYfT4UiqKx+eXcr72fqlaKJYRGI27R0CpmdsRHiOIEkozJmhf5zr?=
 =?us-ascii?Q?OowJcdYeuS+bPHN7AjNiL6fcmI6STeTWe2DI?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:11.8064
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bed11e48-bb67-4927-65ab-08dd9f71f34e
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000143.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6284

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/x86/include/asm/pci.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h
index bed99437cc..2e67cba8b9 100644
--- a/xen/arch/x86/include/asm/pci.h
+++ b/xen/arch/x86/include/asm/pci.h
@@ -13,6 +13,8 @@
                         || (id) == 0x01128086 || (id) == 0x01228086 \
                         || (id) == 0x010A8086 )
 
+struct pci_dev;
+
 struct arch_pci_dev {
     vmask_t used_vectors;
     /*
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:03:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:03:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000708.1380885 (Exim 4.92)
	(envelope-from )
	id 1uKySC-000776-V5; Fri, 30 May 2025 12:03:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000708.1380885; Fri, 30 May 2025 12: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 1uKySC-00076y-SY; Fri, 30 May 2025 12:03:16 +0000
Received: by outflank-mailman (input) for mailman id 1000708;
 Fri, 30 May 2025 12:03:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySB-00076q-LY
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:15 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20631.outbound.protection.outlook.com
 [2a01:111:f403:2009::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0ffb330b-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:13 +0200 (CEST)
Received: from MW4P222CA0029.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::34)
 by PH7PR12MB5974.namprd12.prod.outlook.com (2603:10b6:510:1d9::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Fri, 30 May
 2025 12:03:08 +0000
Received: from CH2PEPF00000143.namprd02.prod.outlook.com
 (2603:10b6:303:114:cafe::83) by MW4P222CA0029.outlook.office365.com
 (2603:10b6:303:114::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.24 via Frontend Transport; Fri,
 30 May 2025 12:03:08 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000143.mail.protection.outlook.com (10.167.244.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:07 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 0ffb330b-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XKSUDbankdwbxbUtxMYy/N1d7WFaAWeNc8UD8nPeQ5ET7cyVX4QmTraNQgc02KeAK5J9rJHXjBNKER5jtDpqAGKb2kI4pyE2jwTxxrktzOycKuFV2gMLceXgh5HWkG9ddRTKgiXLRzrtaJZ3EY4fkRYr74aaLasyna6BaLyvF8y2wbAP/sgbGrJ0kyoq+p4B8eM97Vgh6rMqtE8KAVwzqXLQ9twGR29yknxhgRATwuD1Qx5G9ctCBdxXLMhlyyQRIfH/oQinUUtcps5W8uUMiIw9mP4ArciLEDMmFqQm+fIVis9de/wgDsoQJdAx0q53VqILDyLRK4nivNCwUUL5uA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RDnxDduMjMbUnEln534OSW3kiycNznllTRrJRof/5zY=;
 b=ZuJhhB1W4oDpbmA0KDn7EXfnfB20RwbLBk+MjAYyc0VXhgJqLgNVEBnlAsV85AJsyaloBW5rCwdkqNaOyHUBAzSPA0PLHOD/cHY8hiFfL5qv3n9lVDLhwef6NrDiZuqoJtofx6lLjuy65YfheGlKDC9ByMdCllRwTqZN7MRYZn+/7Vlc6Og2KF/E2QOHYRlwP6xvfT3IJgHnEZ8H6potnei1c6hbKbOpUR8a97rYLaX1ZNM1Zm4+9/y8Z/V9caGS/bkkiEqjq5Z1zbpx8c3eyxEtkibzQJNgYGcgXXyHjt1g/bFz8ACCQqheteu4iL6fDODLkCNZEuw8VdZeB6K3jw==
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=RDnxDduMjMbUnEln534OSW3kiycNznllTRrJRof/5zY=;
 b=Q5c4T7/my5xPCBBtvWafUux42Q7oP4cIasoyZjnCVV5BKD2tU5trpOOrhxabkroH+8RKSqSaSYks4yqrTlSDl10s68Fwkm2vGH18kLOXUM6KlAgAya8HGFeQY+edlP99+2RwCzcLqNbYHHalGuLMc5GsR5iDIr1DI92A6KECJyY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Jan Beulich
	, Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, Anthony PERARD ,
	Volodymyr Babchuk , "Daniel P. Smith"
	
Subject: [PATCH 00/19] Allow x86 to unflatten DTs
Date: Fri, 30 May 2025 14:02:08 +0200
Message-ID: <20250530120242.39398-1-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000143:EE_|PH7PR12MB5974:EE_
X-MS-Office365-Filtering-Correlation-Id: e0891c8d-3c7f-4222-7a5d-08dd9f71f08f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|36860700013|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?7223QPG+jhcAxCLrpWSPO0PStKjEApex6jYj/pP6U30Wi6UA52oVN8hSlKyS?=
 =?us-ascii?Q?2qHiAif6QgNX64P+xbPSJDvOWmfY4X2wLs1xG/conux+citrTWudZT3jsccu?=
 =?us-ascii?Q?G7QB2QulfaBUYgmYei/D86SEtstwo7Dw2AcX1JfIBihlpm65Ph1vOb1T76AS?=
 =?us-ascii?Q?IV2dSe3R9ZvGc/qNq2xiOZTnloK136Dz0cZXD4vieCt+jW+i2EIaZrKw+lcc?=
 =?us-ascii?Q?xSaJz26XMwJ5eeE1gN7s6cQFEqjhg2+WGNKvmFxHjL8lZzF1nc4OP/pYqIqL?=
 =?us-ascii?Q?qBsiJyCrFstfWAlIwnl5EhBTvdjf6vrGmyUbM3OdTUw/h52BwKFj38L9okWT?=
 =?us-ascii?Q?u3PkaQ/EI8V6eycAHnnF0AA7sX08c3iR+18iXInKCR0ZpwM3BhS+aBosVb6v?=
 =?us-ascii?Q?DCzu42U12n67zowuIg6RObNBvIvtIaq6+Mjvb5Vod50/5Ji9hnWz6ExO+Siy?=
 =?us-ascii?Q?PPXbhO+z3fJit24I7ztknnrjG5TpvHPQJoGADd4Mfp9Rqtz0w6a7FvX0LgsZ?=
 =?us-ascii?Q?SgAnXDmEQAaO3YIBux8Oi1DPNe+HawnLRZonb7gnuedaIpddJ3UQcIWO2HDX?=
 =?us-ascii?Q?oNefCpuKBu0lps0hhsHF0TPhYCrp/eGaZHkH6NVVdP72ZDV7+Zv1ny6ra31H?=
 =?us-ascii?Q?e+9gyaVP4LBhPBjiTOzzIT5gFGPLz/NZ4hntOinz8n+ZT70t0tlnf8TMXELK?=
 =?us-ascii?Q?2se/Vavu+8YtVz8FTaAy1p8CyvGuC+b6FvEwl1f+w+TLteufFeAzVrfNVsB7?=
 =?us-ascii?Q?+zAPOT0WpJ5kAR5ocsrLYhwaqD5zDsHaPoFZfF9C2qgJwmnVIdOpyYc6XHmt?=
 =?us-ascii?Q?zavINH1unD5ykSKSuy41skczysK/ddFBVPtG7fNbc7aJmeP1uSr5O1mxvNK0?=
 =?us-ascii?Q?JgbnDJqyOfrMWAbAaFB2YT2ao5y5FnosbWkFJYld7A1Z8+QEnCNp55f8jjrJ?=
 =?us-ascii?Q?+QvDJxTLHDruJ/9jm0rn/T4mVLRKeLka5KacgWhf4kOxan9H/XXhhulyrYrK?=
 =?us-ascii?Q?BzFiFEJuCT3v7wCwJ9fJkkBRLnkYTgO7wW+ZyGSK4UaFHDD6CJTBROFGuWXa?=
 =?us-ascii?Q?PrOUIT+LP4dTqWl8hD6ib2ZLaDkCa+PkMxILU2XyR3G7xU6tbpQdpp7MPFYx?=
 =?us-ascii?Q?nB5aXPeLLNsQ46y4F/xPwVzyykYOMNaICrcLgqGBp/c50HSLtB0z4V+DsdUU?=
 =?us-ascii?Q?nSFfiVLMeYyE16rHvrj8DOYgFP/3ukG+DZdwXFC4UTmbjK+C1/B2tkzJWzB5?=
 =?us-ascii?Q?r/DMd7qm8rE49aB8cQeNaCN1z3ZRw2gwUsnPpDqs7L6EbA54SqR4oT+LwQ+M?=
 =?us-ascii?Q?jpCRNJF1DwYLUHp9xpbv6S7IJv9V++xJ/Dz2pb6ElgH/IGXqOv9iDu67/HF2?=
 =?us-ascii?Q?GtJol8561DXYsbMk1MlDh3MmHNPgtgyhtPUL7BFFqjyKW3NOZDLIlZV3P2R7?=
 =?us-ascii?Q?efkceVizGOVdJluFyrBApgD1JbGuUiTHYl+QGoyBCddqJCYMtu+tvQ=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:07.1977
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e0891c8d-3c7f-4222-7a5d-08dd9f71f08f
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000143.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5974

This is the aftermath of this discussion:

  https://lore.kernel.org/xen-devel/DA1WWRUQLCAG.ZTVR1HXJ85V0@amd.com/https://lore.kernel.org/xen-devel/DA1WWRUQLCAG.ZTVR1HXJ85V0@amd.com/

It's a first round of cleanup and preparation to have a much easier time
later when integrating dom0less boot into hyperlaunch.

The refactor on device-tree/ is _fine_ by I'm open to other suggestions
to achieve the same thing. In particular, after this series x86 can
unflatten the DT host device tree when it has CONFIG_DOM0LESS_BOOT set,
which enables the builder to use factored-out functions from
dom0less-build.c (not done here).

The diffstat is deceptive because I renamed a large file and then
created a new file with the same name. There aren't that many LoC
changes.

I wrote it as a series to keep things focused, but there's a number of
independent chunks.

  * Patches 1 to 7 are strict (hopefully) uncontroversial cleanups.

  * Patches 8 and 9 add minor missing bits to bootmodule needed by x86.

  * Patches 10 and 11 are BIG, but trivial. They are strict renames of
    boot_module to bootmodule, and equally trivial adjustments to the 
    fields (e.g: s/kernel/kernel_bootmodule or s/relocated/arch.relocated/)

  * Patches 12 to 16 try to put some order inside device-tree/. Despite
    their diffstat it's all code motion without functional changes.

  * Patch 17 is the cornerstone of allowing x86 to unflatten DTs,
    otherwise there's the world's entire supply of compile time errors
    due to x86 assuming device_t to be pci_dev.

  * Patches 18 and 19 are inconsequential here, but enables future
    patches in this direction to be gated by a selectable option in
    Kconfig. i.e: it would replace the current CONFIG_DOMAIN_BUILDER in
    the hyperlaunch series. In time, we'll want to rename it to
    CONFIG_MULTIDOMAIN_BUILDER, or CONFIG_PREDOMAINS, or something along
    those lines. For the time being CONFIG_BOOT_DOM0LESS can mean
    CONFIG_BOOT_HYPERLAUNCH on x86 without much of value being lost.

I'd like to re-touch the dom0less help message, as it's written very
confusingly, but I'll leave that for later series.

Alejandro Vallejo (19):
  licence: Add missing SPDX line to bootfdt.h
  x86: Add missing pci_dev forward declaration in asm/pci.h
  riscv: Add missing forward declaration to intc.h
  xen: Add missing forward declaration to  btcpupools_get_domain_pool_id
  arm: Remove dependencies with membank(s) definitions from setup.h
  xen: Clean up asm-generic/device.h
  arm/gnttab: Break cycle between asm/grant_table.h and
    xen/grant_table.h
  xen/dt: Add BOOTMOD_MICROCODE
  x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN
  x86: Replace boot_module with bootmodule
  x86: Replace boot_domain with kernel_info
  xen/dt: Move bootfdt functions to xen/bootfdt.h
  xen/dt: Move bootinfo functions to a new bootinfo.h
  xen/dt: Rename bootfdt.c -> bootinfo-fdt.c
  xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c
  xen/dt: Extract helper to map nodes to module kinds
  xen/dt: ifdef out DEV_DT-related bits from device_tree.{c,h}
  xen/dt: Allow CONFIG_DOM0LESS_BOOT to include device-tree/
  kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT

 xen/arch/arm/domain_build.c             |   2 +-
 xen/arch/arm/include/asm/grant_table.h  |   1 -
 xen/arch/arm/include/asm/setup.h        |  16 +-
 xen/arch/arm/mmu/mm.c                   |   1 +
 xen/arch/riscv/aplic.c                  |   3 +-
 xen/arch/riscv/include/asm/intc.h       |   2 +
 xen/arch/riscv/mm.c                     |   2 +-
 xen/arch/riscv/setup.c                  |   2 +-
 xen/arch/x86/Kconfig                    |   1 +
 xen/arch/x86/cpu/microcode/core.c       |   9 +-
 xen/arch/x86/dom0_build.c               |   2 +-
 xen/arch/x86/hvm/dom0_build.c           |  16 +-
 xen/arch/x86/include/asm/boot-domain.h  |  33 --
 xen/arch/x86/include/asm/bootfdt.h      |  52 ++
 xen/arch/x86/include/asm/bootinfo.h     |  63 +--
 xen/arch/x86/include/asm/dom0_build.h   |   6 +-
 xen/arch/x86/include/asm/kernel.h       |  20 +
 xen/arch/x86/include/asm/pci.h          |   2 +
 xen/arch/x86/include/asm/setup.h        |  10 +-
 xen/arch/x86/pv/dom0_build.c            |  12 +-
 xen/arch/x86/setup.c                    |  69 +--
 xen/common/Kconfig                      |   9 +-
 xen/common/Makefile                     |   2 +-
 xen/common/device-tree/Makefile         |   9 +-
 xen/common/device-tree/bootfdt.c        | 624 ++----------------------
 xen/common/device-tree/bootinfo-fdt.c   | 554 +++++++++++++++++++++
 xen/common/device-tree/bootinfo.c       |   3 +-
 xen/common/device-tree/device-tree.c    |   2 +
 xen/common/device-tree/dom0less-build.c |   2 +-
 xen/common/device-tree/domain-build.c   |   2 +-
 xen/common/device-tree/kernel.c         |   2 +-
 xen/include/asm-generic/device.h        |  18 +-
 xen/include/xen/bootfdt.h               | 272 +++--------
 xen/include/xen/bootinfo.h              | 212 ++++++++
 xen/include/xen/device_tree.h           |  38 +-
 xen/include/xen/fdt-domain-build.h      |   2 +-
 xen/include/xen/fdt-kernel.h            |   4 +-
 xen/include/xen/grant_table.h           |   2 +-
 xen/include/xen/sched.h                 |   8 +-
 xen/xsm/xsm_policy.c                    |   4 +-
 40 files changed, 1071 insertions(+), 1022 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/boot-domain.h
 create mode 100644 xen/arch/x86/include/asm/bootfdt.h
 create mode 100644 xen/arch/x86/include/asm/kernel.h
 create mode 100644 xen/common/device-tree/bootinfo-fdt.c
 create mode 100644 xen/include/xen/bootinfo.h

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:03:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:03:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000712.1380926 (Exim 4.92)
	(envelope-from )
	id 1uKySJ-00083k-Tj; Fri, 30 May 2025 12:03:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000712.1380926; Fri, 30 May 2025 12: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 1uKySJ-00083b-QT; Fri, 30 May 2025 12:03:23 +0000
Received: by outflank-mailman (input) for mailman id 1000712;
 Fri, 30 May 2025 12:03:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySH-0007de-SC
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:21 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20613.outbound.protection.outlook.com
 [2a01:111:f403:2407::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1088ca3f-3d4e-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 14:03:15 +0200 (CEST)
Received: from CH0PR04CA0058.namprd04.prod.outlook.com (2603:10b6:610:77::33)
 by BY5PR12MB4226.namprd12.prod.outlook.com (2603:10b6:a03:203::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.30; Fri, 30 May
 2025 12:03:12 +0000
Received: from CH2PEPF00000145.namprd02.prod.outlook.com
 (2603:10b6:610:77:cafe::c9) by CH0PR04CA0058.outlook.office365.com
 (2603:10b6:610:77::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Fri,
 30 May 2025 12:03:11 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000145.mail.protection.outlook.com (10.167.244.102) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:11 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 1088ca3f-3d4e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=R9fILf8M2WvUdjS8LUbLf+SMstpv1/TRiUDL6C93fcjdmMXw5GzsazJdL8RJ6OtWEzgwY8V7qpU2sc6SYQ+7T8sa0DYjpS7pEQzU7+CCA+JVfMF4EVN74cZ39bsSXMt7N2oFetu0OteXin5FtDUyOq0YatiYnNF5KfIOLSdBGMAtyeDYoBzKxjOOcYpaFWJK1Zkdf1EyzyqiWwFVS4dmt7c/TYH3cepJjM1qzhBZEPnNfOf8/QIDEDahxoa0KUm+fwlHMf9D6sTfWpE74MH8xcxx0Sjiq/18pd+1vWT18d/0eJf1VNSaHmrPwaSNuTLBg98j1H2WX08Bfm1P6uemUw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=R/xCzdlcj7D1GVkyCv6SYm+nmyW2Z3DgicYLAF7U5oA=;
 b=Kg68PhFHHQrDGi8f1LoC/72ywUP9pDxsvfYvSKOrdXHZ4ShIeLUKwqvvdDy5UEqgsiLFEw0k3bt+3EFmJfTFEcEiZiesNfGMmFbZBXx33Xh1L3GD2duZU0lq3vOfNoZdpwtB0fUmIniQ5mm6WGo4UJPWOI71qKjIi0WBhyjUTKPwPgzMDjd7FTkXdzyFMPM2KoXnSPuLk39Vw+MEf4ZqzkOysqod5MNZ7Pkxf+k395FEJ8/xb69NNVxSyoAb/KFC7/pbGlXNZXm4mny8nyDyIexS5tPRlddAxjfTg94eHVJ7ocRRHYjlATYBsi4EhAcccaPNfP+yeQuyBBJv3SzC6w==
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=R/xCzdlcj7D1GVkyCv6SYm+nmyW2Z3DgicYLAF7U5oA=;
 b=o6Gb8rYw3IHwnCLUx01SBCN7ZtrBjSctURWLH5NaLKVGpRhY4KBIMpzMp/kV/7R/75gVLpBQixuvL5BGZ21UCprA9YVMzl14Toz9Idq8mlKFWnDhl+El+at1zWcFog7C+mWyTGHI8eNaQR7TShFfQrbaP7MOZRjp/+HonpHt0qM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH 01/19] licence: Add missing SPDX line to bootfdt.h
Date: Fri, 30 May 2025 14:02:09 +0200
Message-ID: <20250530120242.39398-2-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000145:EE_|BY5PR12MB4226:EE_
X-MS-Office365-Filtering-Correlation-Id: 2ecac68e-9117-4176-cc4b-08dd9f71f33a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?2lnKy2gPzt/cWyMX9RTH8PfSz3g4MPpyFPd3+BIcmrdqUmnn4ZI6YKuBHAD8?=
 =?us-ascii?Q?/+VIkuFfR6UIN/+r3Ydt4kLWh6fbjveaUleGGoiKzOET0yESLRrmfRMRq0I9?=
 =?us-ascii?Q?H7TwyqKMkNN2CNjMJWg+NI/O5bdIE+SeJW6IUQ6qDR5Z4U0q+n9dnI3HX52y?=
 =?us-ascii?Q?rSEoosCBw9B9qbOrbxCW8qjUnaZDRMBtUROhFY27iA6KeskqgYE1vB5Mfx+E?=
 =?us-ascii?Q?eVz9D0tjBmYnHZw92lswBB0t8sqrmxrt7K9V6FVtjnJOp6gSMEozme0eAS+5?=
 =?us-ascii?Q?8LcBX7ij099yj2ohbVdqUtSzS5SGRH39TXAzFMunvsXrSBZQ6RoBsGeKb9KE?=
 =?us-ascii?Q?OG0pWQX0vBV45Dm2LxIUL0GgLq8K1nFN/4kbjz9Aa63ESSxBANPUJSpgFeLo?=
 =?us-ascii?Q?ULFUFE7twZC7ThOQ7uIHCw45KEU4Rs+YiBYfMYlQkwlemsiuNZ1Slk6S3yFF?=
 =?us-ascii?Q?ulrU4XeWB9liUO//75vPnwalozchmTKSLAjLqoYLiXFVsSot1rh+blCn7Pm2?=
 =?us-ascii?Q?BPDljhWpIbxS+stwYM7rAHBSXJKbH30ohWoUlLCYPNfDi9uDj2r6Qu4nmnZz?=
 =?us-ascii?Q?s6B6TBjnS6qOdjnqiDQQVzQk6mseAjjGSxS/ET0RX+hPvxmutR5ePA3CwObW?=
 =?us-ascii?Q?YhLdrSLuebI76bbsHX8dMswPWLiKExe2p518uTNwp6AK18YJvmQQkm8b7xJ6?=
 =?us-ascii?Q?Ha6ngNIfgvp32daoiJi1+Y89y+AGblSlZ5emCotKnTJsS29QUIrJpKWPBeIt?=
 =?us-ascii?Q?KwILVfiQ0T8x7FO9oAg0+qdNNnzG/SlY9ElJNXxawarS+I+0lsfeUNF+ILi5?=
 =?us-ascii?Q?kj7xLJ4G4BnSCo04frq9dGAwnATV/0LRavbEeVxQez0zFzHjkXcIIWgubu5S?=
 =?us-ascii?Q?jgJ2fzF63BRqM6MPT/sSfkd4gmsLecwCB1wOROA43a7k8IX/tWEAzGpa/R3p?=
 =?us-ascii?Q?SyuMF6NQUyOb+d6oalWkYGiahucoAlYH2F8YuitX5dzKl0qBOw6eNB18v+gv?=
 =?us-ascii?Q?ucJwsxMg8ELdsU8o6DEgwp5d3/7SuQ1DKvT5VY2ft9Eyaw/ZZ+m5HkHVVhzP?=
 =?us-ascii?Q?vK4YDBOVvxLQP9I5jGCaUJw9NpLLbxPZmbLDcE2EJf7nsG0IZSXNay4pIuVg?=
 =?us-ascii?Q?rCtpwkCh17FpXMQbjlrgZSvpccWXvYIDvjSLTU/6wAakfl4tcf+TaEFGKiyK?=
 =?us-ascii?Q?3tsCKTZglU0xmsjejEIC1Oh/ZpKUHK7U2ndNNRW0jiE5WsQqNRoI6GpyKwTM?=
 =?us-ascii?Q?eeH8xHIxvajotWE8Jh4j78Ua/IoyWMDqmNsLf6HTUN152E+Fj/G+IaGPe5Y7?=
 =?us-ascii?Q?qRvdXIAm7L+CUquVyaUFGVrHCHaB09N34AWtg14pM7IqI+9E1aU2VESUGWZH?=
 =?us-ascii?Q?T67MvbMYgQBZ26YI+9OqKCRLnk57YUVjxKhrGV5xD5FhIAtq18K7HGWGXoAe?=
 =?us-ascii?Q?2sPXbdv8IghOw+GnQNXOWU0KMe6b/jVhVZpHUPFUpVULkj6JiopljJ6VGhhe?=
 =?us-ascii?Q?//H257qXUS/gCNPp3WfWF0JLjyylIZJNy+Tx?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:11.6781
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ecac68e-9117-4176-cc4b-08dd9f71f33a
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000145.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4226

Signed-off-by: Alejandro Vallejo 
---
 xen/include/xen/bootfdt.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 80a90e53c0..847f019559 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 #ifndef XEN_BOOTFDT_H
 #define XEN_BOOTFDT_H
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:03:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:03:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000711.1380916 (Exim 4.92)
	(envelope-from )
	id 1uKySI-0007p1-Mn; Fri, 30 May 2025 12:03:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000711.1380916; Fri, 30 May 2025 12: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 1uKySI-0007os-JQ; Fri, 30 May 2025 12:03:22 +0000
Received: by outflank-mailman (input) for mailman id 1000711;
 Fri, 30 May 2025 12:03:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySG-00076q-SG
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:20 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20622.outbound.protection.outlook.com
 [2a01:111:f403:2416::622])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 12ae4513-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:19 +0200 (CEST)
Received: from MW4P222CA0029.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::34)
 by LV3PR12MB9356.namprd12.prod.outlook.com (2603:10b6:408:20c::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Fri, 30 May
 2025 12:03:13 +0000
Received: from CH2PEPF00000143.namprd02.prod.outlook.com
 (2603:10b6:303:114:cafe::24) by MW4P222CA0029.outlook.office365.com
 (2603:10b6:303:114::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.24 via Frontend Transport; Fri,
 30 May 2025 12:03:13 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000143.mail.protection.outlook.com (10.167.244.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:12 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 12ae4513-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fH8lY6rYFICPAh85Yv7hUKk3kAZcmTlsdQ+W71qL5/ZaClYMcGQk3fg9IpS/YDrElNOYCJBSqmJIPWR9mPx7mpK4q1ngIMrz5c5TQneB0s2xKpwIv7QDl5wbySNJv1tjezVP7wWLvGF7nTGvs5YxgTrwjiwT5y4+TFHCy2KOvo3KPrlnvkWEyltsFJSzCbzCw/OdZgubu70lRwVLc/F23qrAAKcPPR2eXdOkviNqLz2K92d25peSNyp1OkYIgcINTc5MnXyK4v9geWEiwGb3pV/WFFIEdSnpcCVgGHgcdgj5wT6QytOQNjxgoPhnpfYkCrc4NpQiCU8Kn67zB3fL1g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dZlp56kikAIJRuj8HFFgKTWb6tROZzbFa119RYv3t1Q=;
 b=qiUZ6R3LgWKVsWjeU9ClafXqzE4Y8PxzsD3M5dn8UPn/2KCrzH5VS8Pd301kDPPoCKAWOwEkLcuCRbclTiUTo55yPkZLy9S87bSRswXgeMms36B2Voz/meEtiNWXOpqbz9tcnWPZ+h+1cWHcyVv8jQ6IPW+UE0GP7tCZlVJ5iNSOIOplZ48J0BVvldexhFzuuDsSpcVCsfjZDulCHvLB4gElGNjupPspc3iKNG/PGrRVZWLKmqyALfL/4Ve23eas3KH/v1vEAzrasrTCvRuZKYFe2C28gOTiW9mH24ypxF9Xg1wC0JOuVTNtf9PDh4KXV2ReKOfghl2rtBU+7fzv8g==
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=dZlp56kikAIJRuj8HFFgKTWb6tROZzbFa119RYv3t1Q=;
 b=ADP7h97ZDIjHxhQd7T9mZy3hG5BUX7rcv4zZPWbONiRpsohQWDs2Qik4wV4E8CFTtlSoRHHDixo2ZCKc27DZ07Mx/KVQZGawfZ9yPXDRiKuQysfv34tIDw94JmPlT9l0IrmiVvXJRBDCqNEVmpVlTUHlC9CZzLTubwgJAS6+To4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, Andrew Cooper ,
	Anthony PERARD , Michal Orzel
	, Jan Beulich , Julien Grall
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Stefano Stabellini" ,
	"Daniel P. Smith" 
Subject: [PATCH 03/19] riscv: Add missing forward declaration to intc.h
Date: Fri, 30 May 2025 14:02:11 +0200
Message-ID: <20250530120242.39398-4-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000143:EE_|LV3PR12MB9356:EE_
X-MS-Office365-Filtering-Correlation-Id: d6bab5d2-4c1e-4f26-a752-08dd9f71f3f5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|7416014|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Uj2c/2s2+tSabQ6W/4uczojidzm8/lv83VbTkb3tzP1hCfWpuCt0i1bPvXB7?=
 =?us-ascii?Q?184u0CGn+g/dTbZnU0aY1GexqTVD3tXhUTIdGPyna5bN+9pQCezBwtYQ0sJJ?=
 =?us-ascii?Q?lK/ZARmUBCrXtK/xIL0NltmtA7vlQz66kZNXR0hUvX9CbyfVwNOFHnsg8JVE?=
 =?us-ascii?Q?p2SIC0gL78WKuIpGZjMrgjx+ZW+7MiXVxr9i7kJV147fvYSxfz9hZu7oV6zz?=
 =?us-ascii?Q?85MpMMA+i7JQTaZyL5X+N9busyTpy1WSLQZlEOkV+psPK6AMtj+377l+miYx?=
 =?us-ascii?Q?mER/+g4GHoBpeW3oyFb5nLa5GZLua5P5Gkiz/U4aw8LyKn2m/oMzGH8KlBdw?=
 =?us-ascii?Q?j7pKrgNe47HYVCMMzjkG+kFrCSPj6gHgGDK706Ozlv6Gkcwian/z9mhIRIno?=
 =?us-ascii?Q?5JZxqy+A/rFMmG5a4a1ds6genbGcy0ScrEMq0gmR5+n2eiBoRolj0lVsERFV?=
 =?us-ascii?Q?CbYfoKCcW0CUc9RvcJ69ikKunkjiydvSKPDHo1CDIMCXfWF7S0F7i3b8JU5G?=
 =?us-ascii?Q?r8fSjOPgmqzJ0N3kTytDfSy3MWjpbS+4CtAZE3iWG3K87BkK919uqGtVxzwU?=
 =?us-ascii?Q?egBBOMfbBVoFaFTnTPwjU0dfG2TYN99bgDTj99mygsbD1vhXd/V33VYlf5Xg?=
 =?us-ascii?Q?m9P5cXqVlTQvwOouNS0eYcVKFcFLugMd1Vn59Uo5XUM3oggNZV01y60wNcJW?=
 =?us-ascii?Q?o9U4JBfI3+hu8ZMTX5BKcr9NxYe6k9tSy9m0ttlWUAhhW4don2GL9UKtXOya?=
 =?us-ascii?Q?HLgQznxaAUWLVAw4NcboBlNirZ93JGxDKvYSiRzOv5KHfQQx0aJORLROAE31?=
 =?us-ascii?Q?CxmwJxH6l2sBZfkDmnu4nhPmsUEsdGnsz2ySf1+DueA+L6uHCDTnSeKi5/70?=
 =?us-ascii?Q?nzFuZyec355/EH1Z9CznmGD41lO/5CLIq/pvbixYGkYstSnjv2It2rswouxW?=
 =?us-ascii?Q?MGiiQp19qL8a3aaIsFQQwmUJ/tTSWCIoBXvwB3mw96nepooEblFqx1+mQlym?=
 =?us-ascii?Q?4jqEyR8oOt3QcQs6LlOWvOY7npZ+qR/WE5Lex57SvoE2bugHxLgZPKUK6V6z?=
 =?us-ascii?Q?X/iNqAgns58fKM+/Hr5ccgWD7NDqV7U89ikfS0U1CEyRJUfAiF4PBP389HWp?=
 =?us-ascii?Q?QAswLonkfdI8sIDOw3x6liCSkKHqbcdiGE03LkXRpazeJbojuykxOMpZCV/y?=
 =?us-ascii?Q?ljb9EVGXCAUqGHqZdv8LMLTHzs211m/T8cOf3LD84lfviJW93qQoJgf4l3XQ?=
 =?us-ascii?Q?/0VO6eMPeNUWIeBjXf580I01CYcE9RTvkUDZFatLQJBiQwwvtXAi7qsIHee9?=
 =?us-ascii?Q?6MQN07Vw8ZV6W0KDN3aRxiCnccvscyIMaR7T3nTtj6LfOj1IVqC86e2LSQVy?=
 =?us-ascii?Q?YEs93B7GAwupI1oz7L56QSSKeutEuWlAsOD5VzToLwB4aar+019mYKBmPmSW?=
 =?us-ascii?Q?AuxTMxW22/DS7Ks45jbEOhfMRSFvyQBHzGMUVpxhEmIyOHDEFjdAB0cwmoeG?=
 =?us-ascii?Q?QFym96r/MSUSKp16OkMT6QqEWdWA4Gs9NqJf?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(7416014)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:12.9022
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d6bab5d2-4c1e-4f26-a752-08dd9f71f3f5
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000143.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9356

Very much not a functional change

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/riscv/include/asm/intc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 52ba196d87..81f74736ba 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -8,6 +8,8 @@
 #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
 #define ASM__RISCV__INTERRUPT_CONTOLLER_H
 
+struct dt_device_node;
+
 enum intc_version {
     INTC_APLIC,
 };
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:03:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:03:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000710.1380905 (Exim 4.92)
	(envelope-from )
	id 1uKySH-0007a4-BY; Fri, 30 May 2025 12:03:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000710.1380905; Fri, 30 May 2025 12:03: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 1uKySH-0007Zt-90; Fri, 30 May 2025 12:03:21 +0000
Received: by outflank-mailman (input) for mailman id 1000710;
 Fri, 30 May 2025 12:03:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySF-00076q-S5
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:19 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20607.outbound.protection.outlook.com
 [2a01:111:f403:2409::607])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 12d8a7b5-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:19 +0200 (CEST)
Received: from MW4P222CA0030.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::35)
 by SJ2PR12MB8875.namprd12.prod.outlook.com (2603:10b6:a03:543::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Fri, 30 May
 2025 12:03:15 +0000
Received: from CH2PEPF00000143.namprd02.prod.outlook.com
 (2603:10b6:303:114:cafe::b7) by MW4P222CA0030.outlook.office365.com
 (2603:10b6:303:114::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Fri,
 30 May 2025 12:03:15 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000143.mail.protection.outlook.com (10.167.244.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:14 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 12d8a7b5-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vgNdOYn6LZppeW60AoHaZawC9zMx/TBsYCkwDmCWFIwHfNgNTSk0qkHDC2TRrIY6MqF9hUvp21lGjr8C45/pP1OfPNZ2McUQ+7syqFgZvRqSbb/CtJ4ihjvTqX5EA+2+iWhDAx2JHhYWNZ++i+ZenI/YbnUwnMCQB6JaeYHaUvSRUH528EXsJV4ZEbpxm3ooezBlvXUzLf5aGzm/Z5CcXa6wpFFhDhYm4cnkhSz0Bmb2oM+WSPUJX7Vj5cT9CIrrJQ/kkAYN6qgN0Df0PjiwZ8VFyM20XOjXDRQ4aQTNEadQVcTLKjfbf4Y1pB9n9U3H4SFqoa/XthtVnIxuVHp1mQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vXe5G9Iqi22LTrUnfwfBy2xZ8mkimgLDxsX5KClv5aA=;
 b=sMeTs7B++1zOODlgyRPXuiY4Ic6+NnmMJYJWsYcRG1R2RhJu7YmAqcskRhXjbDLc9hcTTNY70Ge3NUUeM1i5ibbaj8lPNU48CT2wZ3U8/sKu+mBmEPRWPJHRuLQVYLU+ubVvKkook7sSs806xGaf29nIkTKuf+PFXjA8M5YoKeuhwDK17oDhGDP+2gqcmr+H5iAO2BHwXVMshtnp9tIkntsaVDyesVeKfDUgxxdbU/GKeCsWwucyzw2z8TL6/tG7J7/kpu8AXH5ekZDMhqpbgOuh3t8xzWkkixUcuWrlNgNWEi/5IyXYERGybyFk6tmvzfwR9IbP9/KI5sReI9UARg==
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=vXe5G9Iqi22LTrUnfwfBy2xZ8mkimgLDxsX5KClv5aA=;
 b=JVrQATxBKDlNkVzgQuRS9caoou9sEvDf0glsQJH0iN9Ux5BLI6KmDWocEqbphrSSGqgi0DV3lLkxcskERrFSfek9FGagIhTajRP57oVfjA78+QTW/a9qyz9i9xQwEBBqJRinOgx9Rox8Bda/rdMFzKLs9GesEWoqGpsxgnX+Yhg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini , "Daniel
 P. Smith" 
Subject: [PATCH 04/19] xen: Add missing forward declaration to  btcpupools_get_domain_pool_id
Date: Fri, 30 May 2025 14:02:12 +0200
Message-ID: <20250530120242.39398-5-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000143:EE_|SJ2PR12MB8875:EE_
X-MS-Office365-Filtering-Correlation-Id: 1838771b-1bce-4689-5d99-08dd9f71f52b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?ujbPSl9VUQxCXANEnhkT8ggAjjklNJZuqYZmdBWQ2NwEzvbJK+61t6l9qN/Y?=
 =?us-ascii?Q?YuneEeipx/SIn587HQVZRQD2v3URS4PILJGmwmXi2AcbGspCc1T27qu1cg6s?=
 =?us-ascii?Q?4utwWpkmLyYMgoYgK0ve9fLOhiR4qd9xUnIZp8RA45ptRLpJbgtCgZk+TfSi?=
 =?us-ascii?Q?TEPo63Zhf1pME1dO7vOQqRXhe0dzflmuq1fFaV1fakf+zyUHV+TnNrAPKsP4?=
 =?us-ascii?Q?o3Wq56+fnbmjgMv0BqBlJb9wd67J01cQ11JdiBKhuCpS5nPOdj/0+tbdygcr?=
 =?us-ascii?Q?03L7eO7aop2gnei/AntGzqcQaZkZF5/SXRe0WClhGWVuG8V43Nu+MnnMPQEL?=
 =?us-ascii?Q?ytdEMr0EdqL743jYPPRWNpBSwaoNkf+UGTrlOPrD6A+4QUd+MWKqREN1ROpd?=
 =?us-ascii?Q?0IGSBjHX/CI3J6VMw5dM25PMKt1RmoMe5aKXxqGrWoXp+IjFxAU3SHyOzJD8?=
 =?us-ascii?Q?F/Y3XhERrk32/tNN6fU1pV98ifQlVEQHkZ0TDcTmVOFy2kMaFrSksSgNId36?=
 =?us-ascii?Q?C6s9lFKvO8vDrMLwpoq2JwxcobcG6o0LNOjVYpNGQJo5C57M1FTMbfSL0FnB?=
 =?us-ascii?Q?aJvQhOe0/tqSWTtTMbG014yDMWpT5OuG+xDPL9wmowNJYAreZinHnDcho10S?=
 =?us-ascii?Q?INchhTE+J5Y5Md/IurI4ztZQfEteQSO20EOu26q651QBY6VUsFTUAVat0+1a?=
 =?us-ascii?Q?yax7ckmm7nzaz81CwPwejbZ7e5ScUtelRC64WYY/aIVQy+1Sh1dMwfsYR5XU?=
 =?us-ascii?Q?EDWjzydYtawl71qaAaUmnhl99rwOzltDrTEZUmQ0G4fsYWQqt2B2RIiTutSz?=
 =?us-ascii?Q?sCXB0CXvIgsEp88337c5AytnhuObgwZXiO5pT34qgqzEE0jXt8HiSvPlgcpi?=
 =?us-ascii?Q?MS7YS9f1PIoheg2fWNRfFVWyKWMt9REdnpqwPSx/cubOz3iYHfaakOzV0utE?=
 =?us-ascii?Q?mOT+Hw33MialGYA2E4TWJ+n9VuOyi0M1zuvZBGAyIZoj76o4s29/gZoUtxxV?=
 =?us-ascii?Q?cvtxTXMsJ2zdECokV+7Db4s0W0WNEaJK8NIIq2LxACLeH0m7EJqgn+ujWNfM?=
 =?us-ascii?Q?RHv89/yAJ2swf3z9FEqIgxXw9VklPg4g1rYH6neBWxiKImMx9wWAxb7b6OPU?=
 =?us-ascii?Q?jrRymDJQpxoSxs0c7Qx41PMrYhXVonmL8fLo4qVmsJCLOxixj218pkvG0ExI?=
 =?us-ascii?Q?fIutC56DCqk4/7eGJMentHOUHdKhifxZM8pFqhWhvEuwqijgvf8n7lFH6aVP?=
 =?us-ascii?Q?Mw/B7/xaxzbJqBd7CuzL9bT/L+QvJfpt/ZTbDsCF5WZmthQFPAO4I3bCXYYX?=
 =?us-ascii?Q?xHM1sxpHxum9QHPpxoapqB7vPAYs3W2grZQQrqzDzOwJ3dcKRj/qsNSXtuDb?=
 =?us-ascii?Q?oW2ZULywzbbX5UMhWBdHqT4Y7+Vqh+I+1f2i+28mLjDOL2N+N7zl09Ii5k9N?=
 =?us-ascii?Q?XwJbxnNea3YUN6OY0ZVuDiy5FslUsu1QmYKuNgtG6nWMRrsOA6JIHDVtYqud?=
 =?us-ascii?Q?6asq12L0vr0UjXzXrLwzMGjNeFJAO7mTJ0TH?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:14.9312
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1838771b-1bce-4689-5d99-08dd9f71f52b
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000143.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8875

And remove the ifdef guard, as it's inconsequential.

Signed-off-by: Alejandro Vallejo 
---
 xen/include/xen/sched.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 559d201e0c..b5a6a22c7f 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1291,15 +1291,15 @@ static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
 {
     return 0;
 }
-#ifdef CONFIG_HAS_DEVICE_TREE
+
+struct dt_device_node;
+
 static inline int
 btcpupools_get_domain_pool_id(const struct dt_device_node *node)
 {
     return 0;
 }
-#endif
-
-#endif
+#endif /* !CONFIG_BOOT_TIME_CPUPOOLS */
 
 #endif /* __SCHED_H__ */
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:03:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:03:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000715.1380946 (Exim 4.92)
	(envelope-from )
	id 1uKySN-00009P-Hq; Fri, 30 May 2025 12:03:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000715.1380946; Fri, 30 May 2025 12: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 1uKySN-000098-DR; Fri, 30 May 2025 12:03:27 +0000
Received: by outflank-mailman (input) for mailman id 1000715;
 Fri, 30 May 2025 12:03:26 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySL-00076q-VE
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:25 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20603.outbound.protection.outlook.com
 [2a01:111:f403:2418::603])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 16949eaa-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:25 +0200 (CEST)
Received: from MW4P222CA0014.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::19)
 by IA1PR12MB6163.namprd12.prod.outlook.com (2603:10b6:208:3e9::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Fri, 30 May
 2025 12:03:20 +0000
Received: from CH2PEPF00000143.namprd02.prod.outlook.com
 (2603:10b6:303:114:cafe::7e) by MW4P222CA0014.outlook.office365.com
 (2603:10b6:303:114::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Fri,
 30 May 2025 12:03:20 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000143.mail.protection.outlook.com (10.167.244.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:19 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03:16 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 16949eaa-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XScqiqPgssSj1MjcUsiWEqanqpx+mIg040FX0yu762svZwmjhpwUsUItA2g0a8IS5sevXd3Es/+352JMcNm953ULhy+WcEDn56CN4Lw0Td9sTOv/dPXWiMx39Zb3fQHrEJrKOj/woUC31olG6roTTMqTo1pm9UqAHhkJW6QfU5VH6n/O8VXy0FeoyXviNV2XzlGX2P1o3ToON4qed0jrs2Ajk8ycFg1aHAKbClJWaovSJNCXhWF2Dlnvsi1ouT9i6AA0z03UbIBEWPNtpDBqnBnNdWgL3SXzJGCC4tvQG9IlpRLlQ4OYwzVmKoyK/E+atUTgjCDXXjt10NmjnYvDYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GVbXefuGXvR0oYEIOeTnmJPdVj5num7GvQxtWu/G3Ng=;
 b=palHz8Q83K4QIIKYpmfjZeLTmZ5DLGRWLJjoiVonY717hbaeghr16Pxnb8D1K6PyMFGBFOIXsXt/Y3Yf2vgegrGZnEkh83lTUovLd0gFlnsDUWgI/CRQg6L8k+TxpNRzxjoVIZmkyMnkDaI/CHNo04QaKevrd/AMz6mkqqvbv8bylnCMsKLERi+SzgIY+BJUMsgLVC5dMeOMEV8s3O8PB1Doc1S/3ssvcJXfdUiPpweQm0hfPUli8RZaP9B17H2hgMypLyYsNjOI32zx3h9cMTWFxgIGd7soT71h46EY+p+zgWUKpzTdqJuQDKgvxW8xzmfmap+DGnrkYdfTugaBUA==
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=GVbXefuGXvR0oYEIOeTnmJPdVj5num7GvQxtWu/G3Ng=;
 b=QSsqKRITfgVSU3lkZ6WMcdOacxpN6ZzQoHNEWAgZMKbBwI0z3f/mkTvgsH7yfu5VoACN8XSo10FP1209eeR3mHrqqoeNxeFcNLUPopyXWX1WYoHwVDBD5E5BXDnFXoRJboeE1ckIurIqSKTQQxl5n/u1zuEQKR/aa1sV/afuW3s=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Alistair Francis
	, Bob Eshleman , "Connor
 Davis" , Oleksii Kurochko
	, Andrew Cooper ,
	Anthony PERARD , Michal Orzel
	, Jan Beulich , Julien Grall
	, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Stefano Stabellini" ,
	"Daniel P. Smith" 
Subject: [PATCH 06/19] xen: Clean up asm-generic/device.h
Date: Fri, 30 May 2025 14:02:14 +0200
Message-ID: <20250530120242.39398-7-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000143:EE_|IA1PR12MB6163:EE_
X-MS-Office365-Filtering-Correlation-Id: 77bb117a-b1af-4175-f686-08dd9f71f81f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014|7416014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?IZYyICNHHP043awSqAUNCWg7LCG16YO4T4x32Az6z1r0XSt0SVd1ksfEY2tS?=
 =?us-ascii?Q?VdTqG8JB0QEC8HcY4K++Jq9X5pmZuAtAxPjXvKhmiwso+uimstwZwY06d3iS?=
 =?us-ascii?Q?v52my8eEVQUZbCkf4TU0ZA4+mrVG2tXI8/iBkp6PoUSS5GWO/p15JgOjy9HY?=
 =?us-ascii?Q?SzzJ/43uZFRjG3H1R4ayfNzbZmN2LhPcaTG+rIlc6ATzWGRyZNXTsDaGvC9N?=
 =?us-ascii?Q?xS5CFkBHqWwpxhFgaCfOJr13QjiJvzrJ9aDwk2iO4o3xfLjcKOzHMeSgdCQH?=
 =?us-ascii?Q?hq1GSFIxmdsm9ycBKKi2euGtIYVtkagN8jXs4QuJ2mEAtA2Lz6ejzmhbd7Q5?=
 =?us-ascii?Q?7Eanzz+JEDNqBc159O2DNOPVGx461mAgjaEJCuD7HZfMVVUVlQZDssubwfv5?=
 =?us-ascii?Q?cAVoXRAQAKMXqLoIowyHNQ9dtuEHvoRaGdNgfhSVYYLcraIwkRmxXUKIY5Vb?=
 =?us-ascii?Q?n1lSzhXxzmJsf1IvHOdqqEZ36RXZglooE6XSIzdKxIeyxaH/o9F1Igx9AqSd?=
 =?us-ascii?Q?xqWLFpsPzQvruCwloU6DZfmoTwlrcmK6M1C8Tm5DRV/272USBvQ6Yh5LBtQq?=
 =?us-ascii?Q?7hqgojOp+Md8UWN8lWrHwn5b2rH/Zw4Dxf+Gl4EgwXwRuLpmTl/cxEBJIPAK?=
 =?us-ascii?Q?hH6EQ6vODycTLCeEBOvZMT3gpIvSB1v+rg4hZAWxURY2rTv6LZTSRvXaF8QN?=
 =?us-ascii?Q?nzayq+k5ds8OQD23kOlrqJRD7p2eSXXBi80PvNfZkJRgHoJX0NUyjKiUQvpH?=
 =?us-ascii?Q?w2E4dFcaQeDvatXuSRv0BDTEEG6kieH28zEgzetBDzf3U9p/673e/N+sOYvk?=
 =?us-ascii?Q?lSdtsSgonz/APOW3YOae0iVcAfR5JdXxr4o+Vl/FbNSTbInHLl+v9tCDYkNM?=
 =?us-ascii?Q?chdudvlhK3R7WiGdH6LCHQmgceEzK2aGn87Hz2izlRgVdTimY878C/ndKzbr?=
 =?us-ascii?Q?6/Dc2pYcVb8sDFnfmr/u9M4wsbQLNBiWZYOao+crZpP0g/E37kT2G5Pz+WXa?=
 =?us-ascii?Q?Qymozz83OjCykR4bh75co3dsdBOIbLZv6l8kf7XLpWlqWS6oJ36sbcnp+Vfy?=
 =?us-ascii?Q?DMVEAc/dd6RBG8YZf2LbE5UjoLXyJLNxdEZVlg5xB6AJc4dCZw9e0ZAm3y/4?=
 =?us-ascii?Q?fcnvEMV8qq4JXyDDnlGdG0Bcj3FEt7AQiNWa1Y6HNZK2AEDz1WNeZYhwvfAi?=
 =?us-ascii?Q?InbX0ySPNpsvrgSxENRmpUQdL4qIzgMyllLaVQU7BekewRqsamAQnoSRaB85?=
 =?us-ascii?Q?0UbbkDxcQNoOdlpLM8h0nAJkRDHxbX5F3k74+Gky58SIdslYYRdYxMoIpnC7?=
 =?us-ascii?Q?dSKGZuzn9/BrYnGzoH3uxWN00LngL2VtD+F0ZDoTbYyRc0zShRM0llq7IWw4?=
 =?us-ascii?Q?F7XlJqRgkfHlBq5iBFpFgPz39CikQtcSXgr7tMjRaZMJL7vHdw1rFy3L9n3m?=
 =?us-ascii?Q?te7dhbtcI4jJQr04aDKwMpeeIkZIzSGNZvZMCkvumPL6028gRwWZZT4mgsci?=
 =?us-ascii?Q?FrSsAwBsQA5jOZ2YNQZaTL5rZcRsipG+YejQ?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014)(7416014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:19.8897
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 77bb117a-b1af-4175-f686-08dd9f71f81f
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000143.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6163

There's some pretense this header may be used without
CONFIG_HAS_DEVICE_TREE, but that's just wishful thinking. Only x86 lacks
that option, and it fully overrides this header, typedeffing struct
pci_dev to be device_t.

Furthermore there's an include for xen/device_tree.h halfway through the
header, but that header already includes asm/device.h, creating a cycle.

Clean up the header removing ifdef guards, merging the typedef onto the
struct definition for device_t and removing the spurious include.

The only affected file is aplic.c, in riscv, which is forced now to
include device_tree.h directly.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/riscv/aplic.c           |  3 ++-
 xen/include/asm-generic/device.h | 18 ++----------------
 2 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index caba8f8993..90bf222eeb 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,12 +9,13 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-#include 
 #include 
 
 static struct intc_info __ro_after_init aplic_info = {
diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/device.h
index 1acd1ba1d8..d485fb97dc 100644
--- a/xen/include/asm-generic/device.h
+++ b/xen/include/asm-generic/device.h
@@ -6,9 +6,7 @@
 
 enum device_type
 {
-#ifdef CONFIG_HAS_DEVICE_TREE
     DEV_DT,
-#endif
     DEV_PCI
 };
 
@@ -23,23 +21,15 @@ enum device_class
 };
 
 /* struct device - The basic device structure */
-struct device
+typedef struct device
 {
     enum device_type type;
-#ifdef CONFIG_HAS_DEVICE_TREE
     struct dt_device_node *of_node; /* Used by drivers imported from Linux */
-#endif
 #ifdef CONFIG_HAS_PASSTHROUGH
     void *iommu; /* IOMMU private data */;
     struct iommu_fwspec *iommu_fwspec; /* per-device IOMMU instance data */
 #endif
-};
-
-typedef struct device device_t;
-
-#ifdef CONFIG_HAS_DEVICE_TREE
-
-#include 
+} device_t;
 
 #define dev_is_dt(dev)  ((dev)->type == DEV_DT)
 
@@ -87,10 +77,6 @@ struct device_desc {
     int (*init)(struct dt_device_node *dev, const void *data);
 };
 
-#else /* !CONFIG_HAS_DEVICE_TREE */
-#define dev_is_dt(dev) ((void)(dev), false)
-#endif /* CONFIG_HAS_DEVICE_TREE */
-
 #define dev_is_pci(dev) ((dev)->type == DEV_PCI)
 
 #ifdef CONFIG_ACPI
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:03:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:03:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000716.1380956 (Exim 4.92)
	(envelope-from )
	id 1uKySO-0000Qs-VB; Fri, 30 May 2025 12:03:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000716.1380956; Fri, 30 May 2025 12:03: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 1uKySO-0000QZ-RL; Fri, 30 May 2025 12:03:28 +0000
Received: by outflank-mailman (input) for mailman id 1000716;
 Fri, 30 May 2025 12:03:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySN-0007de-OM
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:27 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20628.outbound.protection.outlook.com
 [2a01:111:f403:2414::628])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 16b3cc15-3d4e-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 14:03:26 +0200 (CEST)
Received: from CH0PR13CA0024.namprd13.prod.outlook.com (2603:10b6:610:b1::29)
 by CH0PR12MB8577.namprd12.prod.outlook.com (2603:10b6:610:18b::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Fri, 30 May
 2025 12:03:21 +0000
Received: from CH2PEPF00000147.namprd02.prod.outlook.com
 (2603:10b6:610:b1:cafe::31) by CH0PR13CA0024.outlook.office365.com
 (2603:10b6:610:b1::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.16 via Frontend Transport; Fri,
 30 May 2025 12:03:21 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000147.mail.protection.outlook.com (10.167.244.104) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:21 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 16b3cc15-3d4e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=spQ+SFUEjc/XLWnGN7A/NOVBa+tWMrXV56fdBhrRmN2Nb7mfPEUieYyz8mqUJwefoT0Gq8eegDRWZToVAa27krpMdphCFj1+jAboefYgqYhh4ViGLR9XWRbebPOoI3C2X41rwPmP0XiQsjH/LN4ghmi2zaHtvicC9DFP1VeZYWg7MrYHt6ru2nHwYTAqBbmZ2uPejr8d0JvSenGwsw7y8OLjx5VG3kSrut5RSvO3O8ExNicQhZg94Yi0Ft/q3VJ7f/vpKrzC4Ll+OyDzaJk+0HLuqlL65qmwc1KYEOZnhdzwfRh7Xf1G+9ylBVGUuksy4ZgxTyhVun+7MhBe3XBytg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=F1Gy7METHvl4e1uTjxJqux8z1qxe5mj2zTQSv1Qz68k=;
 b=N1Ri+yY7/uYypJYSLJ0aD76q0Z8Ri/QsFa0oEFEzf3JMaasncxZy1gLes86Fo+awHr2OefwuRmyELcvDxS5WVelMMFp93Uho3TdYLbvGkWerNn11QF2CooEGoBuoPyaDfkjPEphbU4hQhGsqEhNH7vmWofAvLllpPI0Q+BsreaCJi9qOjGvFRRR3ZZenKjGNk+qBzaaLXrkIXy9wv9bucF3Y+JpkodroI5Nfvluq4M/XRWcypG3V2nbMso136vzFAY9krj//SyC0ltA9FBKd25Zuj+dbmgD9HI2CVVxAY6v+c2lcvjDJ6fqNyXuNDQmCWYyUChavrypsgAd0BRQ+6A==
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=F1Gy7METHvl4e1uTjxJqux8z1qxe5mj2zTQSv1Qz68k=;
 b=rAQSh6/hGyJznONHSs1J8GhpnXdVBV+7k/86IARJoXm4D1xuO3RFVk5R/VLD38s4hXCSv6iyMnYeAlNNWj9lHp9e55NpvXJeyVCtU4x679mw2HXxLRjhfAUZXvE8ON9Qfpj2cki9lZMHiIaNXWwzO5uyqWSZ8BOHmSfdn4fa/n8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, "Daniel P. Smith" 
Subject: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h and xen/grant_table.h
Date: Fri, 30 May 2025 14:02:15 +0200
Message-ID: <20250530120242.39398-8-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000147:EE_|CH0PR12MB8577:EE_
X-MS-Office365-Filtering-Correlation-Id: 8489f693-9131-425a-b1ac-08dd9f71f8fb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|7416014|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?o2JsOOhez/oKkVMoS9RmaG1Hk/El9ditQkPukm914PQjj/gxTnGOTMQOq2Hl?=
 =?us-ascii?Q?aL1CrL9ojTOV67rD/0MXXdzp6BPjaV53yNnJ3vOEbZ4WKYa6V180Xm063mzl?=
 =?us-ascii?Q?G6T/O+wfNMmIKJDI3QOw6kF2iLS1IlkN/7JvK8W3ygkGrWtu8t9Ggo9n+GeM?=
 =?us-ascii?Q?OQRqEyDB3WYl+qtEuYSzi05qciDrJVR2OPIjLSaYtMDW2Ok/GpTotxk3L78t?=
 =?us-ascii?Q?Zdw5hfoYp/Gb38M98v2XHu4iGs4uXES44uE+4Avrxtq8ldStrSaoUt7MCDO9?=
 =?us-ascii?Q?iIT97ofrDrwLIG7vgh2bzPHQ65etMRRt2GIJH4CkW3MGUO7DMun7VGmSrCh6?=
 =?us-ascii?Q?Sh1zTO++U1TToKimqkqmV6rjdpXv74a2McBBSVKDKlyh+mHOEsd5G5Esoong?=
 =?us-ascii?Q?ZZSljjLfwUvM7RTrcgnwUaEE8NEKaV2S4y/Uo9n+q30930LjWFJ36x28t3ug?=
 =?us-ascii?Q?z9r2XkVJw9Zil6mv01MKlz+vzLPCjEL1y+6nxww182yjWJd7rEUuW0+7AqY8?=
 =?us-ascii?Q?6F9SVVwvYfJIKi9c45/0csbT7ib7Vlc+rfKkqKD8N25+/CmYvvK3hRpBBE4t?=
 =?us-ascii?Q?/Oc421fc1IZPpaVubfoROSMHsEKWnuiSKHcl+8AiQqFCEVXNMnk0nXH2p0oY?=
 =?us-ascii?Q?XQoRQ900atIyzYpVxUih2fRjYadTMcqy42Ru4YuSpq5O+AVGCaKNJ04oqdyf?=
 =?us-ascii?Q?qgfzGs5ywZdmFjC6ZyG2nOlv0Mrtyw40vtjzvCGsXAo8NtJa+NF3LtSgvdG4?=
 =?us-ascii?Q?eGJc3OokcgMOQ5OjyISOdktTTXMQlYPwYuXUA1DZIED+YkNm6p980mTbEU/+?=
 =?us-ascii?Q?IHBOLUXhX1FzvUUy5tOkZFYYQXOxwiG78XlfkoI69CkQNF6vYTEKTy2i6ZXq?=
 =?us-ascii?Q?OTlySkx8zB+CHah6qoVca49L8B6uPc9hqLWuTIYAUgbNPyhFndX5u32VHpB3?=
 =?us-ascii?Q?aNe7XIJuGjStIVyOLwYR0nabF322J9KRyJ2b0Ryt7nDUt/CI7uRXsx+JIB9z?=
 =?us-ascii?Q?RbPdVWenFJfcBCvaVbvezQc13PPoBp4dF3pspjjoRRDF27eC5rFKAOst1I0P?=
 =?us-ascii?Q?fmoZ1yQa/9vRhEW/dUWg0e+lgUnifU9e0idUU36YogeaWAAiWuVg8btbkmli?=
 =?us-ascii?Q?SQ7bJXZjvFoojvOkfSI4dfWX2W9hxsqyQ8ipy5qfSQ1i0OzjvJ1aT24Q+EAd?=
 =?us-ascii?Q?Urt0xdgwPN87HOe94SNFZwvDJtV/7Q5+6PGbF3g1+rknASNYFaErT8pccLiF?=
 =?us-ascii?Q?xOo4JyfZUkSckD1Dnf9Bt30M8p9sAC89LeJ9gWnhZJNbi00+NBVDUSVrjCFm?=
 =?us-ascii?Q?wNvCPdRszAwzd+AY28G7cdaUMDmNt8OgF9/RiIal7K0AMuh/o/h9sH5q3stk?=
 =?us-ascii?Q?Q6fcC5KTZU9UWFLmaECO+3VZ7GClfGnnFNs63kIB3UchYGs8CD9jwJ6nrPP8?=
 =?us-ascii?Q?lWlA7s8fUuyAzFuM30h50Yut7BFkwxevB7d3pCR9Z4hhm2jlYYc+oHsX7hBQ?=
 =?us-ascii?Q?C5Ui2qqZKDvJMxVRJXRx3uIjWW/gUSnzrYzB?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(7416014)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:21.3308
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8489f693-9131-425a-b1ac-08dd9f71f8fb
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000147.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR12MB8577

xen/grant_table is meant to pull asm/grant_table, when it exists.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/arm/domain_build.c            | 1 -
 xen/arch/arm/include/asm/grant_table.h | 1 -
 xen/include/xen/grant_table.h          | 2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..11cc03e5db 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -37,7 +37,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 static unsigned int __initdata opt_dom0_max_vcpus;
diff --git a/xen/arch/arm/include/asm/grant_table.h b/xen/arch/arm/include/asm/grant_table.h
index c5d87b60c4..c47058a3a0 100644
--- a/xen/arch/arm/include/asm/grant_table.h
+++ b/xen/arch/arm/include/asm/grant_table.h
@@ -1,7 +1,6 @@
 #ifndef __ASM_GRANT_TABLE_H__
 #define __ASM_GRANT_TABLE_H__
 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 297d7669e9..491cd6c539 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-#ifdef CONFIG_GRANT_TABLE
+#if __has_include("asm/grant_table.h")
 #include 
 #endif
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:03:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:03:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000720.1380966 (Exim 4.92)
	(envelope-from )
	id 1uKySW-0000yJ-AK; Fri, 30 May 2025 12:03:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000720.1380966; Fri, 30 May 2025 12: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 1uKySW-0000xs-5O; Fri, 30 May 2025 12:03:36 +0000
Received: by outflank-mailman (input) for mailman id 1000720;
 Fri, 30 May 2025 12:03:34 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySU-0007de-BV
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:34 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20607.outbound.protection.outlook.com
 [2a01:111:f403:2417::607])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1aa9b876-3d4e-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 14:03:32 +0200 (CEST)
Received: from CH2PR18CA0049.namprd18.prod.outlook.com (2603:10b6:610:55::29)
 by IA1PR12MB8405.namprd12.prod.outlook.com (2603:10b6:208:3d8::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.30; Fri, 30 May
 2025 12:03:29 +0000
Received: from CH2PEPF00000148.namprd02.prod.outlook.com
 (2603:10b6:610:55:cafe::4b) by CH2PR18CA0049.outlook.office365.com
 (2603:10b6:610:55::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Fri,
 30 May 2025 12:03:29 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000148.mail.protection.outlook.com (10.167.244.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:28 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 1aa9b876-3d4e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HUMc0yrzeXwHBH61vHfMQ5Q+ysfQ94U6UMzf3sOLn36z9VP8Rl7pqqd/zJ5d3aRx0gM6o4zzvIz+jCOMc3R5ZJT6DPZmZ/CynugQ/FSbYSzH1EA3zi31VmM+HmXJgasMqb2OUogb3q9j7Iwa0ZxXG4zhsBm+cSHMq3vzseU/Z/iI1lmWBmGX15LSWwjXcRJQoGqQSQDrwFxfGYBN06BrwXEyLsrWn8GxatTbRsBuWBhvndCiVVUFsRf7U8HEEHb1YeVLH7RPUpfNm/s7ALgwAMuKNYSLig1PAoYZPzMJ00O8sc28QEr5IHQLRqjABcoEQ+DQmAUeAg6+CzSjKl8yHQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VHG82Ru0wjX5B6c2AZ+qjxP8hH7oJ3456oo5ASWGKik=;
 b=p464m4Ea6SthOxOi5RJ9Dy1WPFtwYtFHEpsRBO7/n4a65OmFSmRDhU+bj1q3RLBoij0bZkHVmc+8hK2//b7ZpWVwwrX20w3qWDPorinifU/HDovXlvdwBYKWJNTo6MefdN+N5x5gTRuejeBqLoHTN46l8HIFrMS0rNTDaor+jk9PhptBHGXQzWPoeQyKNvm17MqT7w9nwVMEdYqRZ3Q7cPfxH/eUyeIJzaETtCxTgsbSqv2AAh4cCJH8cfw6BzlCxYTOLpnUSgqxrTtfuDOpHRb6mSNV381W2G8szRwvycrboanWJzlsVF5FGHfH2r98iUdS8sj9ZNnR3ihNm6/zww==
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=VHG82Ru0wjX5B6c2AZ+qjxP8hH7oJ3456oo5ASWGKik=;
 b=x5XaskTSvbQH+5FjJDPK/Zm/AEOhwVOxX1x+jwmAMErex1K3IcRDgYug0zGMec6vlhAn5ENTrzXcEqrPSmoBEylwm84McEKFPEGtFdjwN7FMPkNdjpHhwCSLQyDxKAzp+qqD5OC12itliJD6q0MVg/Kgoar0BxkVlIa/z1ZIB5M=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini , "Daniel
 P. Smith" 
Subject: [PATCH 11/19] x86: Replace boot_domain with kernel_info
Date: Fri, 30 May 2025 14:02:19 +0200
Message-ID: <20250530120242.39398-12-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000148:EE_|IA1PR12MB8405:EE_
X-MS-Office365-Filtering-Correlation-Id: 4f13120f-844e-42ac-2272-08dd9f71fd59
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?m7957DLGvMpBROcHwnNt+Boc87FjbwJ+skBu+lJdv6FyfMmsxKRQYRLBrjlW?=
 =?us-ascii?Q?MwzL9bDpZDJun9ysMeHj6zYzxiE/PQsipH17rQEwUu1564pAG/TaN7ZLcMhD?=
 =?us-ascii?Q?Bd0x88OcX2kqI5AyR9cx8LWzmOye5t8/rZqdCOJOrHibOkyR/xWkztkInUYK?=
 =?us-ascii?Q?e/c++ZBAh4lHullkndrlPvUV2nAOuCijPHbE0PfHWp4CGCFLRXj3F66rkJjV?=
 =?us-ascii?Q?QABP7oucnLPWaclTObNDeLOgcBySgWnZHzXP2Q9608yaADWxaOiemld06QVx?=
 =?us-ascii?Q?6rGz7mCfJAn0kXVRIBFya/TqednhNeVQBtr6by7j1gM2/gE1eEl7Xc10coDu?=
 =?us-ascii?Q?nxY5F3tkxCrJeuumoPRhQRQ6CDGSXImYb2YnvrECLEgOCSql1rwNTuZDEhLd?=
 =?us-ascii?Q?Pic0+b0UCjOFe1F4GM0TOHo7x9Toa9NXJJKizaPWOuwu7VlFLdjxv819+YTv?=
 =?us-ascii?Q?3QrM6+Yv2xWgLYxzeN+9pAdYnGBd5wF5fWnf3ui4jH3GUlnIndfEzIlj/o14?=
 =?us-ascii?Q?fKejri0tuOGmf5dMN1aqRCahymnY0oygbC/nRBCznppy7YhwcerHsUe/xFlU?=
 =?us-ascii?Q?OSwhs6AkslJq983wcAEGC96B+KoU7L3u6NhspOQsdckYrpAaEZhgt3ipaRCZ?=
 =?us-ascii?Q?6BzyvjeuMIY2r1K3ebmSdPrzuDrt37JjXKcet5/HUwftElP7hFHz/CRjeYXa?=
 =?us-ascii?Q?R8NVAMnBZOWlREURcHDPug1Ro7uuSo8+FAPQkIcNv9FQJ2c6FX2oznl9/vkK?=
 =?us-ascii?Q?1MnSlZLRvWMPJLKjj/MFWnwPMCyDKz8HoF2nGke5Nwzt2lZRHuwrodSeVzjc?=
 =?us-ascii?Q?bB536Nsup8ek67y75f1kGMuI2Di6zOfxhtdp0yx9nzJCysfiS4Gjk1Gh5aGI?=
 =?us-ascii?Q?gxeWsE80gxIs7JF+QGmsDt9y23H2p9i4bxbrDBF4SKtUufAD1H5kWz+3oHcR?=
 =?us-ascii?Q?FQpYqcCJgtTtK808lyVrHq2ukQEmmOgSD7untMnqrkIzRPZjSa+kkmM48OoK?=
 =?us-ascii?Q?i4Qyi3xLvJSGoeApjqaVIqS8A+lJIOysoyJxSMmPwQA60YSaOGNgijzjt+Sd?=
 =?us-ascii?Q?8JcJSRGVkoESqWgzioavCQaOAJgWs3nAam2Wgxde7Wx+fJySiYP1ovFQAatY?=
 =?us-ascii?Q?elLoleBkuCsiUn7GTQHqXQo+1rl8bxb7MehkPRXvtO3cFU1WYag+Jgnlsrsg?=
 =?us-ascii?Q?wcFw9EEJ7y49L5aJnIzYrNWJIdqaANzcrOVnb9ts5FWfs3YRI8MF8+h2Tfx4?=
 =?us-ascii?Q?qQdgU5eDpbgLGA9PXRap5CYqIwtbSSGhxG2ztOWu2Sy5z2hW1H3mGDP0Du7s?=
 =?us-ascii?Q?m4/3n5yf37mjEIt7wJ8+4yn/Ofj4T6uur7AFPRRVmi/4cFC83YJfPBUzlKkl?=
 =?us-ascii?Q?pxue7vN2li27JvTigjWs3ea1n/jzVugSxVqo0dLv84YTdmaMn6G4WtsxEznf?=
 =?us-ascii?Q?LCBJOYdJo0d+pAIVr6uLFePZSBlseL0AndBIGUM5qdVBJMIILq8YAbMR8Q+P?=
 =?us-ascii?Q?M5zih2/1MQbk/SEDQJc8UZLmQegSLx4TMNMt?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:28.6538
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f13120f-844e-42ac-2272-08dd9f71fd59
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000148.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8405

kernel_info and boot_domain serve basically the same role. Unify them so
they can be used in common code for domain building purposes across all
architectures.

kernel_info has a lot of fields x86 doesn't care about, but riscv and
arm do. Hence rather than moving them to the arch-specific files, x86
is ifdeffed out of those so arm and riscv can still keep sharing the
definitions.

Also, deconstify module pointers inside kernel_info, because x86 relies
on mutating through them.

Signed-off-by: Alejandro Vallejo 
---
I'd be happier renaming struct kernel_info to struct bootdomain to clean
up the misnaming but I don't want to deal with the refactor in arm+riscv
right now. I've typedeffed it on x86 to bootdomain_t to reduce the diff
delta. (otherwise there's a lot of useless s/bd/ki/)

Some headers still use "struct kernel_info" in x86 to avoid extra includes.
Re-typedeffing only works from C11 onwards.

---
 xen/arch/x86/dom0_build.c              |  2 +-
 xen/arch/x86/hvm/dom0_build.c          | 10 ++++----
 xen/arch/x86/include/asm/boot-domain.h | 33 --------------------------
 xen/arch/x86/include/asm/bootinfo.h    |  7 ++++--
 xen/arch/x86/include/asm/dom0_build.h  |  6 ++---
 xen/arch/x86/include/asm/kernel.h      | 20 ++++++++++++++++
 xen/arch/x86/include/asm/setup.h       |  4 ++--
 xen/arch/x86/pv/dom0_build.c           |  8 +++----
 xen/arch/x86/setup.c                   | 26 ++++++++++----------
 xen/include/xen/fdt-kernel.h           |  2 +-
 10 files changed, 55 insertions(+), 63 deletions(-)
 delete mode 100644 xen/arch/x86/include/asm/boot-domain.h
 create mode 100644 xen/arch/x86/include/asm/kernel.h

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 0b467fd4a4..5bd4d39d10 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -615,7 +615,7 @@ int __init dom0_setup_permissions(struct domain *d)
     return rc;
 }
 
-int __init construct_dom0(const struct boot_domain *bd)
+int __init construct_dom0(const bootdomain_t *bd)
 {
     int rc;
     const struct domain *d = bd->d;
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 96410344a8..66d7046577 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -644,11 +644,11 @@ static bool __init check_and_adjust_load_address(
 }
 
 static int __init pvh_load_kernel(
-    const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
+    const bootdomain_t *bd, paddr_t *entry, paddr_t *start_info_addr)
 {
     struct domain *d = bd->d;
-    struct bootmodule *image = bd->kernel;
-    struct bootmodule *initrd = bd->module;
+    struct bootmodule *image = bd->kernel_bootmodule;
+    struct bootmodule *initrd = bd->initrd_bootmodule;
     void *image_base = bootstrap_map_bm(image);
     void *image_start = image_base + image->arch.headroom;
     unsigned long image_len = image->size;
@@ -1329,7 +1329,7 @@ static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
     }
 }
 
-int __init dom0_construct_pvh(const struct boot_domain *bd)
+int __init dom0_construct_pvh(const bootdomain_t *bd)
 {
     paddr_t entry, start_info;
     struct domain *d = bd->d;
@@ -1337,7 +1337,7 @@ int __init dom0_construct_pvh(const struct boot_domain *bd)
 
     printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id);
 
-    if ( bd->kernel == NULL )
+    if ( bd->kernel_bootmodule == NULL )
         panic("Missing kernel boot module for %pd construction\n", d);
 
     if ( is_hardware_domain(d) )
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
deleted file mode 100644
index 242e9c9c2b..0000000000
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * Copyright (c) 2024 Apertus Solutions, LLC
- * Author: Daniel P. Smith 
- * Copyright (c) 2024 Christopher Clark 
- */
-
-#ifndef __XEN_X86_BOOTDOMAIN_H__
-#define __XEN_X86_BOOTDOMAIN_H__
-
-#include 
-
-struct boot_domain {
-    domid_t domid;
-
-    struct bootmodule *kernel;
-    struct bootmodule *module;
-    const char *cmdline;
-
-    struct domain *d;
-};
-
-#endif
-
-/*
- * 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/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index f3210b7d6a..6b151c7759 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -9,10 +9,10 @@
 #define X86_BOOTINFO_H
 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 
 /* Max number of boot modules a bootloader can provide in addition to Xen */
 #define MAX_NR_BOOTMODS 63
@@ -20,6 +20,9 @@
 /* Max number of boot domains that Xen can construct */
 #define MAX_NR_BOOTDOMS 1
 
+/* kernel_info is a misnomer. It holds information for a to-be domain. */
+typedef struct kernel_info bootdomain_t;
+
 /*
  * Xen internal representation of information provided by the
  * bootloader/environment, or derived from the information.
@@ -34,7 +37,7 @@ struct boot_info {
 
     unsigned int nr_modules;
     struct bootmodule mods[MAX_NR_BOOTMODS + 1];
-    struct boot_domain domains[MAX_NR_BOOTDOMS];
+    bootdomain_t domains[MAX_NR_BOOTDOMS];
 };
 
 /*
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index ff021c24af..68dc5e487c 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -13,9 +13,9 @@ unsigned long dom0_compute_nr_pages(struct domain *d,
                                     unsigned long initrd_len);
 int dom0_setup_permissions(struct domain *d);
 
-struct boot_domain;
-int dom0_construct_pv(const struct boot_domain *bd);
-int dom0_construct_pvh(const struct boot_domain *bd);
+struct kernel_info;
+int dom0_construct_pv(const struct kernel_info *bd);
+int dom0_construct_pvh(const struct kernel_info *bd);
 
 unsigned long dom0_paging_pages(const struct domain *d,
                                 unsigned long nr_pages);
diff --git a/xen/arch/x86/include/asm/kernel.h b/xen/arch/x86/include/asm/kernel.h
new file mode 100644
index 0000000000..f945f0957b
--- /dev/null
+++ b/xen/arch/x86/include/asm/kernel.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ARCH_X86_KERNEL_H__
+#define __ARCH_X86_KERNEL_H__
+
+#include 
+
+typedef struct arch_kernel_info {
+    domid_t domid;
+} arch_bootdomain_t;
+
+#endif /* #__ARCH_X86_KERNEL_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index c7deaba109..2183036da3 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -26,8 +26,8 @@ void subarch_init_memory(void);
 
 void init_IRQ(void);
 
-struct boot_domain;
-int construct_dom0(const struct boot_domain *bd);
+struct kernel_info; /* bootdomain_t */
+int construct_dom0(const struct kernel_info *bd);
 
 void setup_io_bitmap(struct domain *d);
 
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e6c77413f5..2bb5d1bcdf 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -355,7 +355,7 @@ static struct page_info * __init alloc_chunk(struct domain *d,
     return page;
 }
 
-static int __init dom0_construct(const struct boot_domain *bd)
+static int __init dom0_construct(const bootdomain_t *bd)
 {
     unsigned int i;
     int rc, order, machine;
@@ -374,8 +374,8 @@ static int __init dom0_construct(const struct boot_domain *bd)
     struct domain *d = bd->d;
     struct vcpu *v = d->vcpu[0];
 
-    struct bootmodule *image = bd->kernel;
-    struct bootmodule *initrd = bd->module;
+    struct bootmodule *image = bd->kernel_bootmodule;
+    struct bootmodule *initrd = bd->initrd_bootmodule;
     void *image_base;
     unsigned long image_len;
     void *image_start;
@@ -1070,7 +1070,7 @@ out:
     return rc;
 }
 
-int __init dom0_construct_pv(const struct boot_domain *bd)
+int __init dom0_construct_pv(const bootdomain_t *bd)
 {
     unsigned long cr4 = read_cr4();
     int rc;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index a6b3dbfc8c..aa3d913191 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -297,7 +297,9 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
 struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
-    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
+    .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = {
+        .arch = { .domid = DOMID_INVALID }
+    }},
     .mods = { [0 ... MAX_NR_BOOTMODS] = { .kind = BOOTMOD_UNKNOWN } },
 };
 
@@ -982,10 +984,10 @@ static unsigned int __init copy_bios_e820(struct e820entry *map, unsigned int li
 }
 
 static size_t __init domain_cmdline_size(const struct boot_info *bi,
-                                         const struct boot_domain *bd)
+                                         const bootdomain_t *bd)
 {
     size_t s = bi->kextra ? strlen(bi->kextra) : 0;
-    const struct arch_bootmodule *abm = &bd->kernel->arch;
+    const struct arch_bootmodule *abm = &bd->kernel_bootmodule->arch;
 
     s += abm->cmdline_pa ? strlen(__va(abm->cmdline_pa)) : 0;
 
@@ -1017,7 +1019,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             .misc_flags = opt_dom0_msr_relaxed ? XEN_X86_MSR_RELAXED : 0,
         },
     };
-    struct boot_domain *bd = &bi->domains[0];
+    bootdomain_t *bd = &bi->domains[0];
     struct domain *d;
 
     if ( opt_dom0_pvh )
@@ -1034,11 +1036,11 @@ static struct domain *__init create_dom0(struct boot_info *bi)
         dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
 
     /* Create initial domain.  Not d0 for pvshim. */
-    bd->domid = get_initial_domain_id();
-    d = domain_create(bd->domid, &dom0_cfg,
+    bd->arch.domid = get_initial_domain_id();
+    d = domain_create(bd->arch.domid, &dom0_cfg,
                       pv_shim ? 0 : CDF_privileged | CDF_hardware);
     if ( IS_ERR(d) )
-        panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
+        panic("Error creating d%u: %ld\n", bd->arch.domid, PTR_ERR(d));
 
     init_dom0_cpuid_policy(d);
 
@@ -1051,9 +1053,9 @@ static struct domain *__init create_dom0(struct boot_info *bi)
         if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
             panic("Error allocating cmdline buffer for %pd\n", d);
 
-        if ( bd->kernel->arch.cmdline_pa )
+        if ( bd->kernel_bootmodule->arch.cmdline_pa )
             strlcpy(cmdline,
-                    cmdline_cook(__va(bd->kernel->arch.cmdline_pa),
+                    cmdline_cook(__va(bd->kernel_bootmodule->arch.cmdline_pa),
                                  bi->loader),
                     cmdline_size);
 
@@ -1076,7 +1078,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             strlcat(cmdline, " acpi=", cmdline_size);
             strlcat(cmdline, acpi_param, cmdline_size);
         }
-        bd->kernel->arch.cmdline_pa = 0;
+        bd->kernel_bootmodule->arch.cmdline_pa = 0;
         bd->cmdline = cmdline;
     }
 
@@ -1290,7 +1292,7 @@ void asmlinkage __init noreturn __start_xen(void)
 
     /* Dom0 kernel is always first */
     bi->mods[0].kind = BOOTMOD_KERNEL;
-    bi->domains[0].kernel = &bi->mods[0];
+    bi->domains[0].kernel_bootmodule = &bi->mods[0];
 
     if ( pvh_boot )
     {
@@ -2157,7 +2159,7 @@ void asmlinkage __init noreturn __start_xen(void)
     if ( initrdidx < MAX_NR_BOOTMODS )
     {
         bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
-        bi->domains[0].module = &bi->mods[initrdidx];
+        bi->domains[0].initrd_bootmodule = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
                    "Multiple initrd candidates, picking module #%u\n",
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 1939c3ebf7..2f0ee42ebc 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -34,7 +34,7 @@ struct kernel_info {
     paddr_t gnttab_size;
 
     /* boot blob load addresses */
-    const struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
+    struct bootmodule *kernel_bootmodule, *initrd_bootmodule, *dtb_bootmodule;
     const char* cmdline;
     paddr_t dtb_paddr;
     paddr_t initrd_paddr;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:03:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:03:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000721.1380972 (Exim 4.92)
	(envelope-from )
	id 1uKySW-00013H-Rg; Fri, 30 May 2025 12:03:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000721.1380972; Fri, 30 May 2025 12: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 1uKySW-00012X-Ja; Fri, 30 May 2025 12:03:36 +0000
Received: by outflank-mailman (input) for mailman id 1000721;
 Fri, 30 May 2025 12:03:35 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySV-0007de-Bf
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:35 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20606.outbound.protection.outlook.com
 [2a01:111:f403:200a::606])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1a69e3a3-3d4e-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 14:03:32 +0200 (CEST)
Received: from CH0PR04CA0117.namprd04.prod.outlook.com (2603:10b6:610:75::32)
 by MN6PR12MB8567.namprd12.prod.outlook.com (2603:10b6:208:478::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Fri, 30 May
 2025 12:03:26 +0000
Received: from CH2PEPF0000014A.namprd02.prod.outlook.com
 (2603:10b6:610:75:cafe::af) by CH0PR04CA0117.outlook.office365.com
 (2603:10b6:610:75::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.23 via Frontend Transport; Fri,
 30 May 2025 12:03:26 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF0000014A.mail.protection.outlook.com (10.167.244.107) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:26 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07: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" 
X-Inumbo-ID: 1a69e3a3-3d4e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=u/H+7viSBxzqz7JSl+9F+KzV5lmHin8gawlUW8YvDBI+86gd+OPFbnm3f68VANlb3PAYZ9GxgPblRt49hLKxIQVps89dTt1SVQIyOfL0JKLTjB0y9AvqHVE1COJG5BHmNuJJ6oudPnnUW4oovIEAHnHUMezrrOrr1nTEt2hlOl3FCqznDIKB78r9mYL5xMatMYwfeB8OXCYTQmhmzzkKLhtxLLbwc/Kg14VChAesS5D98wihN9E5kVDVDS/cuILWkSI18nQxct90QbKoTWOQ3URKPuwBB7KnysEnzhHEleZEb2WTsRBqnxt51DUNXwl8dtBOeG+OBcOCPPsOQt2rEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hIPhLoFawvGeIDDt6iVFMk37bF1y48jzP0Gaa6ODd+o=;
 b=si6Sh73J/k9KEeyBFjKDdJ4RffMAXAg3yCtzGioFYk4+FZcHXXsjFmiUvfkR+g1+FRkUA2k+anRpl/jfRkEuZpaCw6yeSbzZUsyYGyuorwWdN739h2IY5nCG7VwX1wfl+y1Axqxf6LlS3XoLaedxXsRtgfk7aHPBiG/1lRg73sc4uTV5iFCb6dAzGUwTLJUIE1v93IIjEf+xai8TiiK5Ojsoum9beL4etkj/AJDhDWdYDgMQXMuspbbQ0j5mxOfX1mozEAFIYlFDQBU6BNq4KWKvuSyhcJgvi2aOdPS06c6ZKSHjvBfdu0fvSO2jxISF2bmUD1IWnD2jOX3SkC6FYw==
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=hIPhLoFawvGeIDDt6iVFMk37bF1y48jzP0Gaa6ODd+o=;
 b=TcKQqk22Kzr2W7JKhhyvfxvLA3EABWVTlYRMEoyLq1yuqXN8glpDlTtQVOeQZAF+pBqGzmC2Ryo8TglQAd37oAU6nvjT2McKtbmT0Ht5GbCDsYbcvWj6fjjoTZAo9IWjFgfrgTJmA9CoOew5StfA9rLboh/62gYq5vJrzzV2F4k=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano
 Stabellini" , Julien Grall ,
	"Bertrand Marquis" , Michal Orzel
	, "Daniel P. Smith" 
Subject: [PATCH 10/19] x86: Replace boot_module with bootmodule
Date: Fri, 30 May 2025 14:02:18 +0200
Message-ID: <20250530120242.39398-11-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF0000014A:EE_|MN6PR12MB8567:EE_
X-MS-Office365-Filtering-Correlation-Id: 1458d993-2fdf-4d7a-4d74-08dd9f71fc1a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?FAYq855I6ECSQP7Itggoowy+mLSUPDj1VS9clrFgsLMGIjQ9l/vUgnS7UrFC?=
 =?us-ascii?Q?2weAGUpd0Htuvrl/Jwecr/bqbLSdukmtikr2oO1VYl2PW49spjEq/5ZDaEQK?=
 =?us-ascii?Q?TztZueLHFEBKotfIURjBiBiUs8pOaOuUQxQSMpzPEiM0GEPoxFvaXwHktnhE?=
 =?us-ascii?Q?0YMvi8o0MTt8Tx6tCitSQD+XYpnLTCiQACftgImIkk8+q4ofi6ZoBmNhxuzZ?=
 =?us-ascii?Q?dPp+sTJ/9dmNcSOByVy0lKGmWZsHLOF8tUawNkf73bWR+8uqko70qAPEr6kY?=
 =?us-ascii?Q?qdSpMO8n2xJgAHegF/E4akvZoSA+/V52PdHlHFl1dYKT9nW8QzFvyNg9iHTp?=
 =?us-ascii?Q?E+26HGlSUSlqeIx/cdCiDdJw3KhToWZkDT7OjKXg60whWpVzJU5hS9kFlobH?=
 =?us-ascii?Q?X++8eUozL5Xe1XPBXUfbxKV1GMV3XckrsElOceqJ8XfFZUbNvPdU2E3j0zcv?=
 =?us-ascii?Q?3Ub6zauGN58q4YdHgrpcSkVDvbad9LFFrMZ32F5QqbKR/ltGyIyr9cbiOSka?=
 =?us-ascii?Q?UouI8+fEFGbSMS5ofXV2nguChiPjnXEHaFx61xB5SkUV9NHf66TaaUuAVtZ4?=
 =?us-ascii?Q?muaMhMJlEARv+quL28rCLTfi0PwgLeVNO5OpolmPQdf5RSlEGQQ6Z1/7W3kN?=
 =?us-ascii?Q?Zsm98pqUTEavspfH7KclaPjQsUaBSmPxf1QDKQr3WeIpyJ/Flpy6jUelp/lb?=
 =?us-ascii?Q?cGyJI/9XAJiih8y3enaR/HYM3Gty4xYR9esYqrcRURTMFZyqk5G1LN4DjTbt?=
 =?us-ascii?Q?jjz6nI3Rm5xNIrRhzn8Ps3MoLUtMZgKqD7o5p08RwnaQfEvGF+TOBtOouwjU?=
 =?us-ascii?Q?CDwkNZw4I5KDoZvxXRrXOxOy7fj+vrN6MVKYzI9nRLahdKt35HPz5N4u4eDV?=
 =?us-ascii?Q?7LkpTyXMePC0G3cWDp+M0Yiqmy/C10wq3wN10u9uIkIhxx204wEPUY2XNkAs?=
 =?us-ascii?Q?OJQKSC6LpwOb4fdW2Fry3UaS6GuZ+A0f5o1OLjJolV56dJTOEcERSzV7t40B?=
 =?us-ascii?Q?GMMcQzs1bt7CQMqA0GbpttjNB/FF1UYh4nkRRrhn0zv074/8zhHlcA/1fsSi?=
 =?us-ascii?Q?NLnQ7IayV2XUtsx4grdpkVDN7P7S9+w8b4osh7JWbChb5zWJTsYwVcCzTJ2z?=
 =?us-ascii?Q?8fOSlBN6tIxZB4kpJF2Mu9hRnP9aWrW3j7CKZ8164IwtO9U6549P3d9EFEXp?=
 =?us-ascii?Q?rTee3tEiMVq7zYLRrG2KtGqx7bg/XWuwlBjS3Klzlg+2L/1qgWW8qqJ/rWqu?=
 =?us-ascii?Q?54ykJ4j0v63uN1R9/OqSiLPuwZ0RcxEJvO8mdG+c8bZfehs9J/CZs235LgF4?=
 =?us-ascii?Q?q/7oUm337lt2/NCVEWDTlDASaqcu71amZA7210sT66LKkV5rSMcQBFLfFHlX?=
 =?us-ascii?Q?I5maByn+HdjITm9wDao+bV+QflKcuvnDVtyr1WBpctC3PQMLZSnis1H0kOx0?=
 =?us-ascii?Q?eBY6LIcDmov9Shc9aDFVHneGA8SkTTwOh5DJvaTfAgS57HzozI8Aocp28AnA?=
 =?us-ascii?Q?F5QwocQRjCWTJ+28DvxJfbHUUxWDcR8DaNXQ?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:26.5635
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1458d993-2fdf-4d7a-4d74-08dd9f71fc1a
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF0000014A.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8567

These types resemble each other very closely in layout and intent, and
with "struct bootmodule" already in common code it makes perfect sense
to merge them. In order to do so, add an arch-specific area for
x86-specific tidbits.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/x86/cpu/microcode/core.c      |  9 ++--
 xen/arch/x86/hvm/dom0_build.c          | 10 ++---
 xen/arch/x86/include/asm/boot-domain.h |  4 +-
 xen/arch/x86/include/asm/bootfdt.h     | 52 +++++++++++++++++++++++
 xen/arch/x86/include/asm/bootinfo.h    | 58 +++-----------------------
 xen/arch/x86/include/asm/setup.h       |  6 +--
 xen/arch/x86/pv/dom0_build.c           |  8 ++--
 xen/arch/x86/setup.c                   | 52 ++++++++++++-----------
 xen/include/xen/bootfdt.h              |  9 ++++
 xen/xsm/xsm_policy.c                   |  4 +-
 10 files changed, 113 insertions(+), 99 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/bootfdt.h

diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 34a94cd25b..0111ef9156 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -760,12 +760,11 @@ static int __init early_microcode_load(struct boot_info *bi)
     {
         for ( idx = 0; idx < bi->nr_modules; ++idx )
         {
-            const struct boot_module *bm = &bi->mods[idx];
+            const struct bootmodule *bm = &bi->mods[idx];
             struct cpio_data cd;
 
             /* Search anything unclaimed or likely to be a CPIO archive. */
-            if ( bm->type != BOOTMOD_UNKNOWN &&
-                 bm->type != BOOTMOD_RAMDISK )
+            if ( bm->kind != BOOTMOD_UNKNOWN && bm->kind != BOOTMOD_RAMDISK )
                 continue;
 
             size = bm->size;
@@ -815,12 +814,12 @@ static int __init early_microcode_load(struct boot_info *bi)
             return -ENODEV;
         }
 
-        if ( bi->mods[idx].type != BOOTMOD_UNKNOWN )
+        if ( bi->mods[idx].kind != BOOTMOD_UNKNOWN )
         {
             printk(XENLOG_WARNING "Microcode: Chosen module %d already used\n", idx);
             return -ENODEV;
         }
-        bi->mods[idx].type = BOOTMOD_MICROCODE;
+        bi->mods[idx].kind = BOOTMOD_MICROCODE;
 
         size = bi->mods[idx].size;
         data = bootstrap_map_bm(&bi->mods[idx]);
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index a038e58c11..96410344a8 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -647,10 +647,10 @@ static int __init pvh_load_kernel(
     const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
 {
     struct domain *d = bd->d;
-    struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->module;
+    struct bootmodule *image = bd->kernel;
+    struct bootmodule *initrd = bd->module;
     void *image_base = bootstrap_map_bm(image);
-    void *image_start = image_base + image->headroom;
+    void *image_start = image_base + image->arch.headroom;
     unsigned long image_len = image->size;
     unsigned long initrd_len = initrd ? initrd->size : 0;
     size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0;
@@ -721,9 +721,9 @@ static int __init pvh_load_kernel(
     {
         size_t initrd_space = elf_round_up(&elf, initrd_len);
 
-        if ( initrd->cmdline_pa )
+        if ( initrd->arch.cmdline_pa )
         {
-            initrd_cmdline = __va(initrd->cmdline_pa);
+            initrd_cmdline = __va(initrd->arch.cmdline_pa);
             if ( !*initrd_cmdline )
                 initrd_cmdline = NULL;
         }
diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
index d7c6042e25..242e9c9c2b 100644
--- a/xen/arch/x86/include/asm/boot-domain.h
+++ b/xen/arch/x86/include/asm/boot-domain.h
@@ -13,8 +13,8 @@
 struct boot_domain {
     domid_t domid;
 
-    struct boot_module *kernel;
-    struct boot_module *module;
+    struct bootmodule *kernel;
+    struct bootmodule *module;
     const char *cmdline;
 
     struct domain *d;
diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
new file mode 100644
index 0000000000..c00de8c09b
--- /dev/null
+++ b/xen/arch/x86/include/asm/bootfdt.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ARCH_X86_BOOTFDT_H__
+#define __ARCH_X86_BOOTFDT_H__
+
+#include 
+
+struct arch_bootmodule
+{
+    /*
+     * Module State Flags:
+     *   relocated:   indicates module has been relocated in memory.
+     *   released:    indicates module's pages have been freed.
+     *   fdt_cmdline: indicates module's cmdline is in the FDT.
+     */
+    bool relocated:1;
+    bool released:1;
+    bool fdt_cmdline:1;
+
+    /*
+     * A boot module may need decompressing by Xen.  Headroom is an estimate of
+     * the additional space required to decompress the module.
+     *
+     * Headroom is accounted for at the start of the module.  Decompressing is
+     * done in-place with input=start, output=start-headroom, expecting the
+     * pointers to become equal (give or take some rounding) when decompression
+     * is complete.
+     *
+     * Memory layout at boot:
+     *
+     *               start ----+
+     *                         v
+     *   |<-----headroom------>|<------size------->|
+     *                         +-------------------+
+     *                         | Compressed Module |
+     *   +---------------------+-------------------+
+     *   |           Decompressed Module           |
+     *   +-----------------------------------------+
+     */
+    unsigned long headroom;
+    paddr_t cmdline_pa;
+};
+
+#endif /* __ARCH_X86_BOOTFDT_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 3afc214c17..f3210b7d6a 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -8,6 +8,7 @@
 #ifndef X86_BOOTINFO_H
 #define X86_BOOTINFO_H
 
+#include 
 #include 
 #include 
 #include 
@@ -19,55 +20,6 @@
 /* Max number of boot domains that Xen can construct */
 #define MAX_NR_BOOTDOMS 1
 
-/* Boot module binary type / purpose */
-enum bootmod_type {
-    BOOTMOD_UNKNOWN,
-    BOOTMOD_XEN,
-    BOOTMOD_KERNEL,
-    BOOTMOD_RAMDISK,
-    BOOTMOD_MICROCODE,
-    BOOTMOD_XSM_POLICY,
-};
-
-struct boot_module {
-    enum bootmod_type type;
-
-    /*
-     * Module State Flags:
-     *   relocated: indicates module has been relocated in memory.
-     *   released:  indicates module's pages have been freed.
-     */
-    bool relocated:1;
-    bool released:1;
-
-    /*
-     * A boot module may need decompressing by Xen.  Headroom is an estimate of
-     * the additional space required to decompress the module.
-     *
-     * Headroom is accounted for at the start of the module.  Decompressing is
-     * done in-place with input=start, output=start-headroom, expecting the
-     * pointers to become equal (give or take some rounding) when decompression
-     * is complete.
-     *
-     * Memory layout at boot:
-     *
-     *               start ----+
-     *                         v
-     *   |<-----headroom------>|<------size------->|
-     *                         +-------------------+
-     *                         | Compressed Module |
-     *   +---------------------+-------------------+
-     *   |           Decompressed Module           |
-     *   +-----------------------------------------+
-     */
-    unsigned long headroom;
-
-    paddr_t cmdline_pa;
-
-    paddr_t start;
-    size_t size;
-};
-
 /*
  * Xen internal representation of information provided by the
  * bootloader/environment, or derived from the information.
@@ -81,7 +33,7 @@ struct boot_info {
     size_t memmap_length;
 
     unsigned int nr_modules;
-    struct boot_module mods[MAX_NR_BOOTMODS + 1];
+    struct bootmodule mods[MAX_NR_BOOTMODS + 1];
     struct boot_domain domains[MAX_NR_BOOTDOMS];
 };
 
@@ -94,16 +46,16 @@ struct boot_info {
  *      Failure - a value greater than MAX_NR_BOOTMODS
  */
 static inline unsigned int __init next_boot_module_index(
-    const struct boot_info *bi, enum bootmod_type t, unsigned int start)
+    const struct boot_info *bi, bootmodule_kind k, unsigned int start)
 {
     unsigned int i;
 
-    if ( t == BOOTMOD_XEN )
+    if ( k == BOOTMOD_XEN )
         return bi->nr_modules;
 
     for ( i = start; i < bi->nr_modules; i++ )
     {
-        if ( bi->mods[i].type == t )
+        if ( bi->mods[i].kind == k )
             return i;
     }
 
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index ac34c69855..c7deaba109 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -36,11 +36,11 @@ extern struct boot_info xen_boot_info;
 unsigned long initial_images_nrpages(nodeid_t node);
 void free_boot_modules(void);
 
-struct boot_module;
-void *bootstrap_map_bm(const struct boot_module *bm);
+struct bootmodule;
+void *bootstrap_map_bm(const struct bootmodule *bm);
 void bootstrap_unmap(void);
 
-void release_boot_module(struct boot_module *bm);
+void release_boot_module(struct bootmodule *bm);
 
 struct rangeset;
 int remove_xen_ranges(struct rangeset *r);
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e1b78d47c2..e6c77413f5 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -374,8 +374,8 @@ static int __init dom0_construct(const struct boot_domain *bd)
     struct domain *d = bd->d;
     struct vcpu *v = d->vcpu[0];
 
-    struct boot_module *image = bd->kernel;
-    struct boot_module *initrd = bd->module;
+    struct bootmodule *image = bd->kernel;
+    struct bootmodule *initrd = bd->module;
     void *image_base;
     unsigned long image_len;
     void *image_start;
@@ -422,7 +422,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
 
     image_base = bootstrap_map_bm(image);
     image_len = image->size;
-    image_start = image_base + image->headroom;
+    image_start = image_base + image->arch.headroom;
 
     d->max_pages = ~0U;
 
@@ -659,7 +659,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
              * pages. Tell the boot_module handling that we've freed it, so the
              * memory is left alone.
              */
-            initrd->released = true;
+            initrd->arch.released = true;
         }
 
         iommu_memory_setup(d, "initrd", mfn_to_page(_mfn(initrd_mfn)),
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 5da9df33c9..a6b3dbfc8c 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -298,7 +298,7 @@ struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
     .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
-    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
+    .mods = { [0 ... MAX_NR_BOOTMODS] = { .kind = BOOTMOD_UNKNOWN } },
 };
 
 static struct boot_info *__init multiboot_fill_boot_info(
@@ -333,7 +333,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
      */
     for ( i = 0; i < MAX_NR_BOOTMODS && i < bi->nr_modules; i++ )
     {
-        bi->mods[i].cmdline_pa = mods[i].string;
+        bi->mods[i].arch.cmdline_pa = mods[i].string;
 
         if ( efi_enabled(EFI_LOADER) )
         {
@@ -356,7 +356,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
     }
 
     /* Variable 'i' should be one entry past the last module. */
-    bi->mods[i].type = BOOTMOD_XEN;
+    bi->mods[i].kind = BOOTMOD_XEN;
 
     return bi;
 }
@@ -381,13 +381,13 @@ unsigned long __init initial_images_nrpages(nodeid_t node)
     return nr;
 }
 
-void __init release_boot_module(struct boot_module *bm)
+void __init release_boot_module(struct bootmodule *bm)
 {
-    ASSERT(!bm->released);
+    ASSERT(!bm->arch.released);
 
     init_domheap_pages(bm->start, bm->start + PAGE_ALIGN(bm->size));
 
-    bm->released = true;
+    bm->arch.released = true;
 }
 
 void __init free_boot_modules(void)
@@ -397,7 +397,7 @@ void __init free_boot_modules(void)
 
     for ( i = 0; i < bi->nr_modules; ++i )
     {
-        if ( bi->mods[i].released )
+        if ( bi->mods[i].arch.released )
             continue;
 
         release_boot_module(&bi->mods[i]);
@@ -519,7 +519,7 @@ static void *__init bootstrap_map_addr(paddr_t start, paddr_t end)
     return ret;
 }
 
-void *__init bootstrap_map_bm(const struct boot_module *bm)
+void *__init bootstrap_map_bm(const struct bootmodule *bm)
 {
     return bootstrap_map_addr(bm->start, bm->start + bm->size);
 }
@@ -689,7 +689,7 @@ static void __init noinline move_xen(void)
 #undef BOOTSTRAP_MAP_LIMIT
 
 static uint64_t __init consider_modules(
-    uint64_t s, uint64_t e, uint32_t size, const struct boot_module *mods,
+    uint64_t s, uint64_t e, uint32_t size, const struct bootmodule mods[],
     unsigned int nr_mods, unsigned int this_mod)
 {
     unsigned int i;
@@ -985,8 +985,9 @@ static size_t __init domain_cmdline_size(const struct boot_info *bi,
                                          const struct boot_domain *bd)
 {
     size_t s = bi->kextra ? strlen(bi->kextra) : 0;
+    const struct arch_bootmodule *abm = &bd->kernel->arch;
 
-    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
+    s += abm->cmdline_pa ? strlen(__va(abm->cmdline_pa)) : 0;
 
     if ( s == 0 )
         return s;
@@ -1050,9 +1051,10 @@ static struct domain *__init create_dom0(struct boot_info *bi)
         if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
             panic("Error allocating cmdline buffer for %pd\n", d);
 
-        if ( bd->kernel->cmdline_pa )
+        if ( bd->kernel->arch.cmdline_pa )
             strlcpy(cmdline,
-                    cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
+                    cmdline_cook(__va(bd->kernel->arch.cmdline_pa),
+                                 bi->loader),
                     cmdline_size);
 
         if ( bi->kextra )
@@ -1074,7 +1076,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             strlcat(cmdline, " acpi=", cmdline_size);
             strlcat(cmdline, acpi_param, cmdline_size);
         }
-        bd->kernel->cmdline_pa = 0;
+        bd->kernel->arch.cmdline_pa = 0;
         bd->cmdline = cmdline;
     }
 
@@ -1287,7 +1289,7 @@ void asmlinkage __init noreturn __start_xen(void)
     }
 
     /* Dom0 kernel is always first */
-    bi->mods[0].type = BOOTMOD_KERNEL;
+    bi->mods[0].kind = BOOTMOD_KERNEL;
     bi->domains[0].kernel = &bi->mods[0];
 
     if ( pvh_boot )
@@ -1458,7 +1460,7 @@ void asmlinkage __init noreturn __start_xen(void)
 
     if ( xen_phys_start )
     {
-        struct boot_module *xen = &bi->mods[bi->nr_modules];
+        struct bootmodule *xen = &bi->mods[bi->nr_modules];
 
         relocated = true;
 
@@ -1471,7 +1473,7 @@ void asmlinkage __init noreturn __start_xen(void)
         xen->size  = __2M_rwdata_end - _stext;
     }
 
-    bi->mods[0].headroom =
+    bi->mods[0].arch.headroom =
         bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
     bootstrap_unmap();
 
@@ -1552,10 +1554,10 @@ void asmlinkage __init noreturn __start_xen(void)
         /* Is the region suitable for relocating the multiboot modules? */
         for ( j = bi->nr_modules - 1; j >= 0; j-- )
         {
-            struct boot_module *bm = &bi->mods[j];
-            unsigned long size = PAGE_ALIGN(bm->headroom + bm->size);
+            struct bootmodule *bm = &bi->mods[j];
+            unsigned long size = PAGE_ALIGN(bm->arch.headroom + bm->size);
 
-            if ( bm->relocated )
+            if ( bm->arch.relocated )
                 continue;
 
             /* Don't overlap with other modules (or Xen itself). */
@@ -1565,12 +1567,12 @@ void asmlinkage __init noreturn __start_xen(void)
             if ( highmem_start && end > highmem_start )
                 continue;
 
-            if ( s < end && (bm->headroom || (end - size) > bm->start) )
+            if ( s < end && (bm->arch.headroom || (end - size) > bm->start) )
             {
-                move_memory(end - size + bm->headroom, bm->start, bm->size);
+                move_memory(end - size + bm->arch.headroom, bm->start, bm->size);
                 bm->start = (end - size);
-                bm->size += bm->headroom;
-                bm->relocated = true;
+                bm->size += bm->arch.headroom;
+                bm->arch.relocated = true;
             }
         }
 
@@ -1596,7 +1598,7 @@ void asmlinkage __init noreturn __start_xen(void)
 #endif
     }
 
-    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
+    if ( bi->mods[0].arch.headroom && !bi->mods[0].arch.relocated )
         panic("Not enough memory to relocate the dom0 kernel image\n");
     for ( i = 0; i < bi->nr_modules; ++i )
     {
@@ -2154,7 +2156,7 @@ void asmlinkage __init noreturn __start_xen(void)
     initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
     if ( initrdidx < MAX_NR_BOOTMODS )
     {
-        bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
+        bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
         bi->domains[0].module = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index d503d1bd4b..fa65e8fcf4 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -7,6 +7,10 @@
 #include 
 #include 
 
+#if __has_include()
+#include 
+#endif
+
 #define MIN_FDT_ALIGN 8
 
 #define NR_MEM_BANKS 256
@@ -106,8 +110,13 @@ struct shared_meminfo {
 struct bootmodule {
     bootmodule_kind kind;
     bool domU;
+
     paddr_t start;
     paddr_t size;
+
+#if __has_include()
+    struct arch_bootmodule arch;
+#endif
 };
 
 /* DT_MAX_NAME is the node name max length according the DT spec */
diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
index 7f70d860bd..0c2cdea8ed 100644
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -40,7 +40,7 @@ int __init xsm_multiboot_policy_init(
 
     for_each_boot_module_by_type ( i, bi, BOOTMOD_UNKNOWN )
     {
-        struct boot_module *bm = &bi->mods[i];
+        struct bootmodule *bm = &bi->mods[i];
 
         _policy_start = bootstrap_map_bm(bm);
         _policy_len   = bm->size;
@@ -53,7 +53,7 @@ int __init xsm_multiboot_policy_init(
             printk("Policy len %#lx, start at %p.\n",
                    _policy_len,_policy_start);
 
-            bm->type = BOOTMOD_XSM_POLICY;
+            bm->kind = BOOTMOD_XSM;
             break;
 
         }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:06:16 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:06:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000741.1380985 (Exim 4.92)
	(envelope-from )
	id 1uKyV4-0003pA-Am; Fri, 30 May 2025 12:06:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000741.1380985; Fri, 30 May 2025 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 1uKyV4-0003p3-83; Fri, 30 May 2025 12:06:14 +0000
Received: by outflank-mailman (input) for mailman id 1000741;
 Fri, 30 May 2025 12:06:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKyV2-0003ov-OA
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:06:12 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20628.outbound.protection.outlook.com
 [2a01:111:f403:2412::628])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 78d311b6-3d4e-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 14:06:10 +0200 (CEST)
Received: from SJ0PR03CA0185.namprd03.prod.outlook.com (2603:10b6:a03:2ef::10)
 by IA0PR12MB7773.namprd12.prod.outlook.com (2603:10b6:208:431::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.22; Fri, 30 May
 2025 12:06:07 +0000
Received: from CO1PEPF000042A9.namprd03.prod.outlook.com
 (2603:10b6:a03:2ef:cafe::d8) by SJ0PR03CA0185.outlook.office365.com
 (2603:10b6:a03:2ef::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Fri,
 30 May 2025 12:06:06 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000042A9.mail.protection.outlook.com (10.167.243.38) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:06:05 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:06: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" 
X-Inumbo-ID: 78d311b6-3d4e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Rn8c/C33E3HQyMYIFe6Ed2YxxvIW4lmgwcx+tw/jN1u1CGtv7V8GumDAV2WAng6HMheL2exr4kSLFsj71vcVT43JQpgMgXTHOm0prLnnYnD8ofv8eHBZyC1MWMAfjUlbi5XY4bAbYnttHVZqp2WGBczH5DbFKRsqt6Hpzr+CgODCx2/hQhT7apTcyBUJ7Zbjt1KxNxZueTG0DI5dEW0/TxDy33ximUqQE7idlnu/L42N7M3WdX0ujA3+rJ6FSc80PGVlU6qcbt0d/sdz9IcE3HVOHB7NageYEv6qkeQpLRXGlypnd/Yczltggvp/NAEQj6mkz2x6h1f+9Zvl0o1vbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ocg88oX1BblcuPZqowSJkdIZmVKEQ9DR4WNp1Wf0MfQ=;
 b=UZLyjksUsCr7CLVKBk36Yt5G4zDnB6+9qmYNZ5GvUAPTIVAcLZhQOc8lDOGbBkNEsg8CW9/0vYEigXISYBjzLSlEqmtxi0cGFXRdASqgQRdRGnM8knR60tTai4F7Mt6eojzeOz5UoXHStXo16NBjo4D5QRrSyf3HNlNAdnXCVBkRwUOBllobwTiuVDn/nLDkwP9rcA+K+k6CRmhNtGaSJMLPlHSnaiFGyw731SupRjKpYUij5nimVXfxgYQQ8559gktyr3+KbOlE2QLlnC9STLM3DynffgRTAnflIZIZ+gaRvOY3SphEQjVDX0DlzW6U935KT0Gy0THV7K4/b6En+w==
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=Ocg88oX1BblcuPZqowSJkdIZmVKEQ9DR4WNp1Wf0MfQ=;
 b=Vozr5vmN4ZeueeJIXeBKTCCECjmNMSwYA6PPWgN80MrbgNM2tEuE8a6rJ6GufTh0RGeq6ZuNmbsNF82SvTJ6xtX6osz6VkLN3VYljm304KTyaULYlb0OdjwnpR4Dk8tZRG+ka6BJi4qdth3z3lROUU7C9p0q0XzmNf3ktNHRFLc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD
	, Michal Orzel , "Julien
 Grall" , Stefano Stabellini ,
	"Bertrand Marquis" , "Daniel P. Smith"
	
Subject: [PATCH 19/19] kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT
Date: Fri, 30 May 2025 14:05:25 +0200
Message-ID: <20250530120548.39550-1-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042A9:EE_|IA0PR12MB7773:EE_
X-MS-Office365-Filtering-Correlation-Id: 1c03a2cc-6085-464c-2c76-08dd9f725acc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?piimtZczPktlCGfXmQW52dwvGy0ZtGx4sj1qHbgkKMAPep0qq6DEjm2v2Tbm?=
 =?us-ascii?Q?YzLogKsuhHEhdaK0N4fvQfGPifsMjFkwmpKSr0wvCmICHAA+Ygy51ZIBGBIf?=
 =?us-ascii?Q?n6Q0E9kRCEp3KIvMRq4IuriA2+F48NrafgWUJzgZwyJl0Ly/eX4llkTMKBYr?=
 =?us-ascii?Q?AV7DRXmQHIAUKbrykC891opQnBvdGdMVeoLU3tvc9pknTvQJNSov0E1Q6Xzw?=
 =?us-ascii?Q?BmdhpcZBiJGOVDgh3/MQuphummMLXwjoFoHQXMyHlovAlwpSxRjjO7tM83l+?=
 =?us-ascii?Q?kZoNKvoRGWDPWUZ5vMnsI+MAadRWCM8X7HkB3u4urFF4TgDHkoocePPozIr/?=
 =?us-ascii?Q?weUMmy3dYsVdWziMMQIG0w5wS2inTGpmPTXsfusPVh2gQ1wUN/cUQVeOyKNG?=
 =?us-ascii?Q?NqKhuwbZtFtKBDzLe/Fg5HXs1y6oS7FAYHfZQYT7MAgNCpZWNa90VapJf+Kp?=
 =?us-ascii?Q?KYapQRhbFwz0KESudjaVH6WB4eGVIFqadNStyiHqxHjMdbUPksbgtzEV3aas?=
 =?us-ascii?Q?XvEH1GwYQ/kotezL9juFpu8O/GKiVPCk4o4B1i6I2muxenbi02AfF+3uj5Tk?=
 =?us-ascii?Q?xjr0eBox7Sjy1lamXHe9YL6oj1XTQdmyh7eEbIym5IApZQcdeYjnyOLg3nFk?=
 =?us-ascii?Q?tw0VnXpcfH2Z+U5Had+w05jIL/gjPUrceMr+eqAy9jeXoYKCnXJxKmRjgARd?=
 =?us-ascii?Q?/KdN2VxEm7ZffjGVeeAN7Ec1sUow8KW92DirAEdP5nhjAjeDBAwnGnKUarbp?=
 =?us-ascii?Q?AztaJukiVs0QLp0/Gi96EPl/dWsnXLlIrsOTMKJta8c3/FlAiQiLNYxPmj3n?=
 =?us-ascii?Q?1QkXw2DQRtZRkw45sxjGYDS3pcrSeKxSa6JXopSzjkRXju0n853GT4Jt/0//?=
 =?us-ascii?Q?k96R3o/1r3jn+MtsU+EkyLEQcP2UkSMzwsV/OiJGb5DQ6FIaXnYf78v7facK?=
 =?us-ascii?Q?u6lxtnZ3UvlvOl0npVrb2rIXYb8ZOYPVWeae1hkH5mf4A1cAuBWcY21U6GOl?=
 =?us-ascii?Q?1MJxNQeqQZ4IINd1joLWq3eP7iX/Kl0PlKjZILpVxhRcQ1Qaoinx9d9klBKo?=
 =?us-ascii?Q?85ac43Zi1GWeN6UtwGx1qMc/CCtmnRFyJlVLtpMcQ8b64oUdDWIaRi/a2qEl?=
 =?us-ascii?Q?iPUU33fozMM5FzT+hxb7JGaynGHy3iC5hY17/2DP0XKMoNphOv2RtTewnJ3x?=
 =?us-ascii?Q?RZlQlEvw8wBtz63TJE7C1/gTKBz021cfCOzmS1KcjTE4cAjYaLLaisiVStBF?=
 =?us-ascii?Q?V4D97wr2VoK6J7sfGhJQqIZcFfEVZ0jSiIEvyb6ZHmUzNqChctlhAvEYagqH?=
 =?us-ascii?Q?nozfNZv310xx3JBQgpcBQNILXhMyUoERvvX5vOIu2KirnvXR6cTqif4HOvnS?=
 =?us-ascii?Q?tBgTTxzFqDh/bN3Em4b32/BACo+TRVjyYrC4dt0fNCBleTZn3YSOCKqzj1y6?=
 =?us-ascii?Q?1SMkkVAUfX7+hSenRn5lOOlmoNzB9koWhiW4tsDyg2WifKSxfnWblIAIZhVQ?=
 =?us-ascii?Q?NJkT3EUAiV5FTefd97ktFd1Bgqi56TTaVIyd?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:06:05.3438
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c03a2cc-6085-464c-2c76-08dd9f725acc
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042A9.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7773

Without picking CONFIG_HAS_DEVICE_TREE.

In order to do that. Allow CONFIG_DOM0LESS_BOOT to take include a subset
of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
as that's tightly integrated still to the ARM way of building domains.

Requires "unsupported" for the time being until all required patches
make it through.

Only intended as a functional change for x86.

Signed-off-by: Alejandro Vallejo 
---
I'm compiling out dom0less-build.c because it relies heavily on
bootinfo. Initially x86 will keep its private builder even for
multidomain boots. And will do so until boot_info and bootinfo are
properly unified.

---
 xen/arch/x86/Kconfig            | 1 +
 xen/common/Kconfig              | 8 +++++---
 xen/common/device-tree/Makefile | 2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7afe879710..4344b4289c 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -18,6 +18,7 @@ config X86
 	select HAS_COMPAT
 	select HAS_CPUFREQ
 	select HAS_DIT
+	select HAS_DOM0LESS
 	select HAS_EHCI
 	select HAS_EX_TABLE
 	select HAS_FAST_MULTIPLY
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 353ccbd06f..6e66657550 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -13,15 +13,17 @@ config CORE_PARKING
 	depends on NR_CPUS > 1
 
 config DOM0LESS_BOOT
-	bool "Dom0less boot support" if EXPERT
+	bool "Dom0less boot support" if EXPERT && (!X86 || UNSUPPORTED)
 	select LIBFDT
-	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
-	default y
+	depends on HAS_DOM0LESS && (X86 || (HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS))
+	default y if !X86
 	help
 	  Dom0less boot support enables Xen to create and start domU guests during
 	  Xen boot without the need of a control domain (Dom0), which could be
 	  present anyway.
 
+	  If unsure on x86, say N.
+
 config DOMAIN_BUILD_HELPERS
 	bool
 
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 4c09e3fb2d..49d061733e 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -3,7 +3,7 @@ obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo-fdt.init.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo.init.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
-obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
+obj-$(filter-out $(CONFIG_X86),$(CONFIG_DOM0LESS_BOOT)) += dom0less-build.init.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:10:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:10:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000785.1381006 (Exim 4.92)
	(envelope-from )
	id 1uKyZZ-0005n6-7z; Fri, 30 May 2025 12:10:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000785.1381006; Fri, 30 May 2025 12:10: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 1uKyZZ-0005mx-3Y; Fri, 30 May 2025 12:10:53 +0000
Received: by outflank-mailman (input) for mailman id 1000785;
 Fri, 30 May 2025 12:10:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySj-00076q-3b
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:49 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20609.outbound.protection.outlook.com
 [2a01:111:f403:240a::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 21ae17a8-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:45 +0200 (CEST)
Received: from CH2PR15CA0017.namprd15.prod.outlook.com (2603:10b6:610:51::27)
 by PH7PR12MB5998.namprd12.prod.outlook.com (2603:10b6:510:1da::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Fri, 30 May
 2025 12:03:38 +0000
Received: from CH2PEPF00000146.namprd02.prod.outlook.com
 (2603:10b6:610:51:cafe::a9) by CH2PR15CA0017.outlook.office365.com
 (2603:10b6:610:51::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.27 via Frontend Transport; Fri,
 30 May 2025 12:03:38 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000146.mail.protection.outlook.com (10.167.244.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:38 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 21ae17a8-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=S+Tg5zBvbDHeHFt92o1fipbo6/XdcyoigoXuPNjs6yI0wbA8G2XC6HrBRxyUsv3RQIG6rBpDJvb9L3f328bUvNnzlW//ov2j3mIMzIV12o1kB2PhZm772YzIjyqGtIHbhmuy/GguGOegL78lTvURzDU/rpJZBLrRN8pctOGPM5iI2EWa1lfEn33WTCKoQ7ci864EZPJv6VFg1CSwDUiuWMakAdvvWSW0ZvcSc7SklYnbbnLkUFQaKkc1tJk3Ij6BQk48Ryqv9cc+5/9742hiyuuGtJTRx7kPlBbIcNp5VZ6paJJXPx3fT1LwIb6F5C2n0c9j91Pa+VYCXeu2hauTyg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=iFb4p1kDcRnAri++z0uQsOLZ3FGqifI7+PMLo97XTlo=;
 b=aRAeX7lmHv1rnK4AUGKRgrUJJaRnDB2ua3f9bglLc4KFjbY02XakreVtbfZ+Pqhkjgsfr/JPs/p1JnaimwjmBAhW+PsrMejKDfQT+M1rvh7f/cLYsQbwha5clWno4KVyjmttHk/I16szWGPWFO7JeCD78NYnsCvOzlpqyi04EehtYn7/9KFccX72uA2wM76w+RdDTV7zrAt6eAEI7JRy66Twvkf5GFUFWU9qkTpAF5UiVjK+lHNReI2tSyP1hLPTMtRd+vwUIZ7CFGVMUKYGZ4D07LP1oJetXvWIOWb7lHF8/JRkfH8BPm9E+H4ji4bsBuOckSTF+m/AmbyhlCu7iQ==
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=iFb4p1kDcRnAri++z0uQsOLZ3FGqifI7+PMLo97XTlo=;
 b=fkEmoMHEdD8bPR8Tm+aZxzxl7EuansOM47+zFnbXjFfU43BVCn2Ceh5nVFOUGrGBMMLdW8SsrHhsm28M8opwrKaPunXQ5JLLfLjFf0l4/NK5ycgeOHaXMyEHpb5kHCvCtLhKORKRDIVo1jqsz3sAQDrrLJy/NhJQ+U3G2IFpyFw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH 16/19] xen/dt: Extract helper to map nodes to module kinds
Date: Fri, 30 May 2025 14:02:24 +0200
Message-ID: <20250530120242.39398-17-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000146:EE_|PH7PR12MB5998:EE_
X-MS-Office365-Filtering-Correlation-Id: d690abd3-dfa5-47ff-1d66-08dd9f7202ee
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?sYsRH4V0DjcsSNik7Y0WgE2sz6POYt1d5P0IwZ79QBx0mUupSgB0fp6gmFSX?=
 =?us-ascii?Q?hGCMpfbJqqTbZxflt5tvsr4d7guZyUOasrBxiUlrRLZckJkaEUQsQ96yLN7Z?=
 =?us-ascii?Q?98y4qpGL1BlKHrUf5xGx85Mkhvw6dRBEh2CqCZAzCvOHSYrWtAhh42/Y6AHF?=
 =?us-ascii?Q?q/GdxZHipIDZBXgryltWPxgA8AXbw29h9swepMP8Yf42FPgLg5aI2yHh6BvG?=
 =?us-ascii?Q?8/nzIOQ1rtjlzQU77VS01hdNMUDsImWJ9/PfMhmpRVDWhtrnUXO+u9WK5tMn?=
 =?us-ascii?Q?D3vGqueBY8r7CLiE8Rlz/f897y1fYLue0d1JMyeLEx8N/u7PoLD9sDy9ARKn?=
 =?us-ascii?Q?PpMRE1e/qX227Mn7/mZyd3i5SiNIRsG10zt82l2cjfsk6Ns5cKgPg+PM2y4Y?=
 =?us-ascii?Q?0uuuzJiNXu7ZZz2ZmlB2Ky7h7AelfvxZf0GQfLOz7vfYtJE6eQPJAWe3S1x9?=
 =?us-ascii?Q?+eR5RZbB64wW1/busf/j4Nrc69E4SUvLZqL2MJJ836UcB9mFHlTx4ygbS7lC?=
 =?us-ascii?Q?/Snd/DKN643k21UpPxd1s7yKFCgr3fekHeTFMdm8I+LncvzjLVnZL6kQqsRs?=
 =?us-ascii?Q?uqhmYP0V8T9EHVcUnfh+cU3hN7La3FlAdkyVc+DE7YFdy0qmyKCOOaegonQ6?=
 =?us-ascii?Q?Tckd1DueGxGTeAbFxr/FPdLmhNu61evYVfJHX8mKCpoBAYgL41ff7tKyX1m5?=
 =?us-ascii?Q?4dUwUzVc8RHaG1JdfNBfJ5M9B83sMfqNsvBbO7PeCnPLT8JCqrPgsTfVEF1e?=
 =?us-ascii?Q?9cqkGB+qv+kFsLas1fcwzbDrDN4ZPA8WEp1rtCZ2nXEpd08ctwbhboV4Uz94?=
 =?us-ascii?Q?3vpT0ps2IQzjj6wsa9gObAwmpoCjeuz3Y9Efj+FSe/Whuyls/dA/C6ek1+2S?=
 =?us-ascii?Q?n134c4B9LxzUjhHq1Ui+oG7AevRGWxGYO4sLdEAvS8VyAS0csj4hQYPUA+Rr?=
 =?us-ascii?Q?WMbjlBSSC4MRttlYgRytNRiqRi0DIQeHsNDjs32mDM4BBXtMKangf8KG7LlR?=
 =?us-ascii?Q?DYPvrkkV6K46fOq1PCufaGxisI2zzZ+NhZLmwuhN5KL7S5bLk8pjKw6Z1zRI?=
 =?us-ascii?Q?aK4NA+6VUdsb66rOzTOVgk789rrJGI022qu6dvEmdtn/kzhoKDhexsWxCdME?=
 =?us-ascii?Q?YXyQHFOUDER0y953Ae1XyoYXZuP7dPa+zjvH7wG8VdhV+VkSLJ/bIO2YolSI?=
 =?us-ascii?Q?Fw2fZX4G6Tbc4Sa4X7i0H0tVonBAXXr8nCs+u+TLPvKnfqEVFpQsIcn2/mjM?=
 =?us-ascii?Q?MWg2AQeOjfDWMsw/rHGAAjhwQLi1Bx31KnVvnejIIQB81uijCSyoq+9sYmlI?=
 =?us-ascii?Q?q3MAnlj6kImeJJEVFfM3GzgoSI6aAYZ7OUYDroergF/RGNlgBNOTVKI5y+JG?=
 =?us-ascii?Q?Jb3XaUgLlnSFuvggpzx5yB4O5ZuczVEMBnj2CuRuKZaBcZ0jc1uYDcfUzj4A?=
 =?us-ascii?Q?HNrp+Cu9FnMq/4SVRKiIljzTpmTMZ+N+U5LS+n+1U4/5AtaPrLj3t+/rE+H0?=
 =?us-ascii?Q?AQa20KLQ4tilgrG4V2+42IksUtUch3q6hGMm?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:38.0193
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d690abd3-dfa5-47ff-1d66-08dd9f7202ee
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000146.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5998

This will be required later by x86 code in order to do early identification
of boot modules when booting off a DTB.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/common/device-tree/bootfdt.c      | 16 ++++++++++++++++
 xen/common/device-tree/bootinfo-fdt.c | 14 +-------------
 xen/include/xen/bootfdt.h             |  7 +++++++
 3 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 5decf17faf..2dda7a9d19 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -4,6 +4,22 @@
 #include 
 #include 
 
+bootmodule_kind __init fdt_node_to_kind(const void *fdt, int node)
+{
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
+        return BOOTMOD_KERNEL;
+    if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
+         fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
+        return BOOTMOD_RAMDISK;
+    if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
+        return BOOTMOD_XSM;
+    if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
+        return BOOTMOD_GUEST_DTB;
+
+    return BOOTMOD_UNKNOWN;
+}
+
 uint32_t __init device_tree_get_u32(const void *fdt, int node,
                                     const char *prop_name, uint32_t dflt)
 {
diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
index 736f877616..dc399bbf61 100644
--- a/xen/common/device-tree/bootinfo-fdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -239,19 +239,7 @@ static void __init process_multiboot_node(const void *fdt, int node,
 
     cell = (const __be32 *)prop->data;
     device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
-
-    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
-         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
-        kind = BOOTMOD_KERNEL;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
-              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
-        kind = BOOTMOD_RAMDISK;
-    else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
-        kind = BOOTMOD_XSM;
-    else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
-        kind = BOOTMOD_GUEST_DTB;
-    else
-        kind = BOOTMOD_UNKNOWN;
+    kind = fdt_node_to_kind(fdt, node);
 
     /**
      * Guess the kind of these first two unknowns respectively:
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 766956e102..7bc6209986 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -102,4 +102,11 @@ uint32_t device_tree_get_u32(const void *fdt, int node,
 void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
                          uint32_t size_cells, paddr_t *start, paddr_t *size);
 
+/*
+ * Probe an FDT node thought to be a boot module to identify its kind.
+ *
+ * If correctly identified, returns the detected kind, otherwise BOOTMOD_UNKNOWN
+ */
+bootmodule_kind fdt_node_to_kind(const void *fdt, int node);
+
 #endif /* XEN_BOOTFDT_H */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:10:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:10:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000787.1381016 (Exim 4.92)
	(envelope-from )
	id 1uKyZb-00063O-Dq; Fri, 30 May 2025 12:10:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000787.1381016; Fri, 30 May 2025 12:10: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 1uKyZb-00063H-AQ; Fri, 30 May 2025 12:10:55 +0000
Received: by outflank-mailman (input) for mailman id 1000787;
 Fri, 30 May 2025 12:10:54 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySZ-00076q-1i
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:39 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2060f.outbound.protection.outlook.com
 [2a01:111:f403:2009::60f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1df1280c-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:36 +0200 (CEST)
Received: from CH2PR18CA0050.namprd18.prod.outlook.com (2603:10b6:610:55::30)
 by IA1PR12MB6067.namprd12.prod.outlook.com (2603:10b6:208:3ed::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Fri, 30 May
 2025 12:03:33 +0000
Received: from CH2PEPF00000148.namprd02.prod.outlook.com
 (2603:10b6:610:55:cafe::cb) by CH2PR18CA0050.outlook.office365.com
 (2603:10b6:610:55::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.21 via Frontend Transport; Fri,
 30 May 2025 12:03:33 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000148.mail.protection.outlook.com (10.167.244.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:33 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 1df1280c-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=er4yNbrgfoIxWYUQu2GXltxuOcZFeF0f2pItFaP8Y4wG9kZwd+p16/QznjJp41jdOBGqVNfePj8o6QhbGyW38Xxl+P3KPHOupyj9mheWKxxrrHbZI+FjF3S5dkl9KiELnghHXHAqkUCeRCCvDPYuJ2hc5WZ16w/qki3daK78vTi/CssESsrQY09fnJiiGeI3fGW7BjPPEbig/Kc3QEYdOzjBG1eWgYp63FVEr8MyFvitU4CbH34POMt61j6yfUIW2odS9MlLVCcRSD9Klx3pnawS49NnKWpzcW6lgmsxj+C9rnMsiwcy8V2Fqnh52D8VGBf2olhvtcZpx5awlkpntQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hFTCTDGKnZMY9M9/WqL/G3QIpXNSv/jD/qzSC5480UI=;
 b=FUQR+dPAPFrL3o4L1G8r97NZJ1cxoOGrq2lp1O0RcqLnDIjGtSc/SV16gFXLejcRYhqX2De0nbx6cZGzCdp15pZonJfbdRRGB7cFJRHGFl6MhBrhQI9vzxdN9UbQqsIgYiSrS8YpKNKGzOrG6hnfuRD2oJ5YUfoZ09M6UG7Lx0jcwI0VIYr/jVTxanq/1z0AJUZjewgIeSto+vubiF6LuUdkCWEdVl+IJOU1nA7e5rAwMMCsrICY1m/Pyd0Q91nGcIYs0hELO2Y/Cflb75lSvY5dBmz16K6D/Fa6S9r57ESZ8QY0Ucub0zWRcseofoGhtX0A+8DNkVETwXsyj4/WeQ==
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=hFTCTDGKnZMY9M9/WqL/G3QIpXNSv/jD/qzSC5480UI=;
 b=0mGnLmoi7Unsl4pNtYxCYTHes9+Fi7v5Xm9Qzxj/drKyiRqX5L8/37ofuNMjsSXwqVAdTa0O9OyzXB8bb0FWDet7STLiU/XpztUJ46prxeTlJ0MZ+uqc0CGgmueYPJPMqk+mvPIfENzO7srOCCs7HpDfD5g2xiFVXVdl93c4gYA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , Andrew Cooper
	, Anthony PERARD , "Jan
 Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Alistair Francis , "Bob
 Eshleman" , Connor Davis ,
	Oleksii Kurochko , "Daniel P. Smith"
	
Subject: [PATCH 13/19] xen/dt: Move bootinfo functions to a new bootinfo.h
Date: Fri, 30 May 2025 14:02:21 +0200
Message-ID: <20250530120242.39398-14-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000148:EE_|IA1PR12MB6067:EE_
X-MS-Office365-Filtering-Correlation-Id: d93c18bb-7a32-4d36-a75c-08dd9f72001e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|7416014|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?jlK67OKg45TK2mQvrJH8pJFhxXTZyeEw9AfWajM0FmXZl8V8DN1ghJxFQQOv?=
 =?us-ascii?Q?Q90tR4ZZkdIoty5RyoxKXKdGGuNbYDqcqeIrhGdYnR2rIeQiAc1TSAYKheh2?=
 =?us-ascii?Q?8ehQky3kSvWzt6cTCX4b7CelS32r+UAarBGqg7K/oIm6Fbs2EAIT3Ei+P95j?=
 =?us-ascii?Q?XkXpr8pp3CRssD+FRFJwoMwa306Jk+KWFXIsi7P2rdg1G9nxIf4ashjpEfPr?=
 =?us-ascii?Q?9282YkwAc3cFqRIxrYBTpsbQfeUlcQydAoF/6GCnuCebl2sE5kFwPSlS+Iqq?=
 =?us-ascii?Q?tyt6kfDoqdiLZWPblSA5Pnr+7c8ajJLAaWzSl/Ix8rVE+z6fz14er6QtHc/9?=
 =?us-ascii?Q?UIolpsT6J726hqeMH8qTqJzwEvvLw9WUQgwyrI/2oVd95eK7o+p6I02oA4G2?=
 =?us-ascii?Q?YcvAKpJWqbifm75LJiba9fHfbW/zWm5WEnurxrHXpIDbGpAZm/pfxrlqNz2u?=
 =?us-ascii?Q?cLGab6d2TER91pcdyZILmKgJb8V2kpFJTVfVrf2UuwiiGQlJ2dp9q0rhO5nj?=
 =?us-ascii?Q?QVp091/IhkqcWTKd13n23T4ccZFr7sig8qdObnxYwRK+BO2Swp9sEy3f9i9m?=
 =?us-ascii?Q?9JzQ+7Pq2HmqT1eikr68m1AFdB9zL3UAJQ/VeQskWepfn9lSnmX2e3wMfwzY?=
 =?us-ascii?Q?JuRaZUNwAZWFOCQitNzaENJnU1YZ+Sr/am+oqXz3eoCcjkQDV2juNi6x1boH?=
 =?us-ascii?Q?WJXuCWGEdqGFKWyA5KtzgkFxcDdbRIKa3QWZhK2TT/WuLEW24IhEiqDkqv30?=
 =?us-ascii?Q?cHZvjpIXvh5LYBYM14yx7Ei6A2lhLbOSAoP7OMpsfJrx24MvXpof0VXMf8zC?=
 =?us-ascii?Q?NZK7Nz8amNNurtlwKjPyyHQF1nJ1FhXlriqFlR0rubEBtHorXjdwQ8vXZJOQ?=
 =?us-ascii?Q?WopYs1il3dbxZVjS3d2NtRCICGYLAn4NHh31SU6yG/WYDyicALVkbpxne4A0?=
 =?us-ascii?Q?yQUdJH35tQgjsV0CdJ9FjmpD0I4lPWaahdbH1VreTcWc1rtsMmlBrpcakQnB?=
 =?us-ascii?Q?B84/600R+0tX6jbK5BoTTzqGshNf/aAHcofSSFu94tH6CiU86i+ISusdp+V+?=
 =?us-ascii?Q?kM2+Rup94/0snwUSPLrdlLnzQgE5QalEeXVF10jjnIO8G9sbLArTjojKUlGh?=
 =?us-ascii?Q?desQN7CjVzweYes5Bg33UjNmfVaotTDR5QK9U8h4Sg+eMV8l33cHTz8KSgSF?=
 =?us-ascii?Q?sPVdM37021uccNW54qlxP3Vu3YoBzg1Zm4gsj/lz6S5VapWa7lcU664Q7Vsp?=
 =?us-ascii?Q?EfgBRfdtOXTk1Gt6qgTwFwtYnPTVm8+mdu3REb8QkZykPE6r4D21wASvYIaY?=
 =?us-ascii?Q?BIJm6tIKcbMXDDVcncJaA2VvEHNI+gMg3DVT7Grd5yJmJlcLbcW/tsAR0QlY?=
 =?us-ascii?Q?SnYzjmB+riawhvcdFxp8hVjA48DcJirSno3NsOKt87GJr5A8+1wqEpi7hkdh?=
 =?us-ascii?Q?JTDkIt728YCaPtWW2ktOa2OixRUc5rKITY3pBUiLcVXf3UqzL3CiLmjT2rPe?=
 =?us-ascii?Q?40jeyRF33msasmMoUhBtVvL2tCCst2ZRP0hb?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(7416014)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:33.2956
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d93c18bb-7a32-4d36-a75c-08dd9f72001e
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000148.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6067

Part of an unpicking process to extract bootfdt contents independent of
bootinfo to a separate file for x86 to take.

With this, bootfdt.h can be cleanly included from x86. A later patch
extracts the definitions so the functions may be called too.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/arm/domain_build.c             |   1 +
 xen/arch/arm/mmu/mm.c                   |   1 +
 xen/arch/riscv/mm.c                     |   2 +-
 xen/arch/riscv/setup.c                  |   2 +-
 xen/common/device-tree/bootfdt.c        |   1 +
 xen/common/device-tree/bootinfo.c       |   2 +-
 xen/common/device-tree/dom0less-build.c |   2 +-
 xen/common/device-tree/domain-build.c   |   2 +-
 xen/common/device-tree/kernel.c         |   2 +-
 xen/include/xen/bootfdt.h               | 206 -----------------------
 xen/include/xen/bootinfo.h              | 212 ++++++++++++++++++++++++
 xen/include/xen/device_tree.h           |   2 +-
 xen/include/xen/fdt-domain-build.h      |   2 +-
 xen/include/xen/fdt-kernel.h            |   2 +-
 14 files changed, 224 insertions(+), 215 deletions(-)
 create mode 100644 xen/include/xen/bootinfo.h

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 11cc03e5db..c53da76682 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c
index 9c50479c63..77f82757bb 100644
--- a/xen/arch/arm/mmu/mm.c
+++ b/xen/arch/arm/mmu/mm.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index d3ece9f132..040db73d00 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 4e416f6e44..0a2d0dc1eb 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -2,7 +2,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index 529c91e603..fb4ac06390 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 717cfa0962..69491bdb0b 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -10,7 +10,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
index 39cb2cd5c7..c798807560 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/domain-build.c b/xen/common/device-tree/domain-build.c
index 6b8b8d7cac..e5d34dd89d 100644
--- a/xen/common/device-tree/domain-build.c
+++ b/xen/common/device-tree/domain-build.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/device-tree/kernel.c b/xen/common/device-tree/kernel.c
index cb04cd9d50..d02440cc2d 100644
--- a/xen/common/device-tree/kernel.c
+++ b/xen/common/device-tree/kernel.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 079259c719..766956e102 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -4,9 +4,6 @@
 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 #if __has_include()
 #include 
@@ -14,15 +11,10 @@
 
 #define MIN_FDT_ALIGN 8
 
-#define NR_MEM_BANKS 256
-#define NR_SHMEM_BANKS 32
-
 /* Default #address and #size cells */
 #define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
 #define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
 
-#define MAX_MODULES 32 /* Current maximum useful modules */
-
 #define DEVICE_TREE_MAX_DEPTH 16
 
 /* Helper to read a big number; size is in cells (not bytes) */
@@ -75,77 +67,6 @@ typedef enum {
     BOOTMOD_UNKNOWN
 }  bootmodule_kind;
 
-enum membank_type {
-    /*
-     * The MEMBANK_DEFAULT type refers to either reserved memory for the
-     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
-     * the bank is in 'mem').
-     */
-    MEMBANK_DEFAULT,
-    /*
-     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
-     * bank is bound to a static Xen domain. It is only valid when the bank
-     * is in reserved_mem.
-     */
-    MEMBANK_STATIC_DOMAIN,
-    /*
-     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
-     * bank is reserved as static heap. It is only valid when the bank is
-     * in reserved_mem.
-     */
-    MEMBANK_STATIC_HEAP,
-    /*
-     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
-     * bank is from the FDT reserve map.
-     */
-    MEMBANK_FDT_RESVMEM,
-};
-
-enum region_type {
-    MEMORY,
-    RESERVED_MEMORY,
-    STATIC_SHARED_MEMORY
-};
-
-/* Indicates the maximum number of characters(\0 included) for shm_id */
-#define MAX_SHM_ID_LENGTH 16
-
-struct shmem_membank_extra {
-    char shm_id[MAX_SHM_ID_LENGTH];
-    unsigned int nr_shm_borrowers;
-};
-
-struct membank {
-    paddr_t start;
-    paddr_t size;
-    union {
-        enum membank_type type;
-#ifdef CONFIG_STATIC_SHM
-        struct shmem_membank_extra *shmem_extra;
-#endif
-    };
-};
-
-struct membanks {
-    __struct_group(membanks_hdr, common, ,
-        unsigned int nr_banks;
-        unsigned int max_banks;
-        enum region_type type;
-    );
-    struct membank bank[];
-};
-
-struct meminfo {
-    struct membanks_hdr common;
-    struct membank bank[NR_MEM_BANKS];
-};
-
-struct shared_meminfo {
-    struct membanks_hdr common;
-    struct membank bank[NR_SHMEM_BANKS];
-    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
-};
-
 /*
  * The domU flag is set for kernels and ramdisks of "xen,domain" nodes.
  * The purpose of the domU flag is to avoid getting confused in
@@ -165,133 +86,6 @@ struct bootmodule {
 #endif
 };
 
-/* DT_MAX_NAME is the node name max length according the DT spec */
-#define DT_MAX_NAME 41
-struct bootcmdline {
-    bootmodule_kind kind;
-    bool domU;
-    paddr_t start;
-    char dt_name[DT_MAX_NAME];
-    char cmdline[BOOTMOD_MAX_CMDLINE];
-};
-
-struct bootmodules {
-    int nr_mods;
-    struct bootmodule module[MAX_MODULES];
-};
-
-struct bootcmdlines {
-    unsigned int nr_mods;
-    struct bootcmdline cmdline[MAX_MODULES];
-};
-
-struct bootinfo {
-    struct meminfo mem;
-    /* The reserved regions are only used when booting using Device-Tree */
-    struct meminfo reserved_mem;
-    struct bootmodules modules;
-    struct bootcmdlines cmdlines;
-#ifdef CONFIG_ACPI
-    struct meminfo acpi;
-#endif
-#ifdef CONFIG_STATIC_SHM
-    struct shared_meminfo shmem;
-#endif
-};
-
-#ifdef CONFIG_ACPI
-#define BOOTINFO_ACPI_INIT                          \
-    .acpi.common.max_banks = NR_MEM_BANKS,          \
-    .acpi.common.type = MEMORY,
-#else
-#define BOOTINFO_ACPI_INIT
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-#define BOOTINFO_SHMEM_INIT                         \
-    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
-    .shmem.common.type = STATIC_SHARED_MEMORY,
-#else
-#define BOOTINFO_SHMEM_INIT
-#endif
-
-#define BOOTINFO_INIT                               \
-{                                                   \
-    .mem.common.max_banks = NR_MEM_BANKS,           \
-    .mem.common.type = MEMORY,                      \
-    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
-    .reserved_mem.common.type = RESERVED_MEMORY,    \
-    BOOTINFO_ACPI_INIT                              \
-    BOOTINFO_SHMEM_INIT                             \
-}
-
-extern struct bootinfo bootinfo;
-
-bool check_reserved_regions_overlap(paddr_t region_start,
-                                    paddr_t region_size,
-                                    bool allow_memreserve_overlap);
-
-struct bootmodule *add_boot_module(bootmodule_kind kind,
-                                   paddr_t start, paddr_t size, bool domU);
-struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
-struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
-                                                             paddr_t start);
-void add_boot_cmdline(const char *name, const char *cmdline,
-                      bootmodule_kind kind, paddr_t start, bool domU);
-struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
-struct bootcmdline * boot_cmdline_find_by_name(const char *name);
-const char *boot_module_kind_as_string(bootmodule_kind kind);
-
-void populate_boot_allocator(void);
-
-size_t boot_fdt_info(const void *fdt, paddr_t paddr);
-
-const char *boot_fdt_cmdline(const void *fdt);
-
-static inline struct membanks *bootinfo_get_reserved_mem(void)
-{
-    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
-}
-
-static inline struct membanks *bootinfo_get_mem(void)
-{
-    return container_of(&bootinfo.mem.common, struct membanks, common);
-}
-
-#ifdef CONFIG_ACPI
-static inline struct membanks *bootinfo_get_acpi(void)
-{
-    return container_of(&bootinfo.acpi.common, struct membanks, common);
-}
-#endif
-
-#ifdef CONFIG_STATIC_SHM
-static inline struct membanks *bootinfo_get_shmem(void)
-{
-    return container_of(&bootinfo.shmem.common, struct membanks, common);
-}
-
-static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
-{
-    return bootinfo.shmem.extra;
-}
-#endif
-
-static inline struct membanks *membanks_xzalloc(unsigned int nr,
-                                                enum region_type type)
-{
-    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
-
-    if ( !banks )
-        goto out;
-
-    banks->max_banks = nr;
-    banks->type = type;
-
- out:
-    return banks;
-}
-
 /*
  * Interpret the property `prop_name` of `node` as a u32.
  *
diff --git a/xen/include/xen/bootinfo.h b/xen/include/xen/bootinfo.h
new file mode 100644
index 0000000000..bf7516ec1f
--- /dev/null
+++ b/xen/include/xen/bootinfo.h
@@ -0,0 +1,212 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef XEN_BOOTINFO_H
+#define XEN_BOOTINFO_H
+
+#include 
+#include 
+#include 
+#include 
+
+#define NR_MEM_BANKS 256
+#define NR_SHMEM_BANKS 32
+
+#define MAX_MODULES 32 /* Current maximum useful modules */
+
+enum membank_type {
+    /*
+     * The MEMBANK_DEFAULT type refers to either reserved memory for the
+     * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
+     * the bank is in 'mem').
+     */
+    MEMBANK_DEFAULT,
+    /*
+     * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
+     * bank is bound to a static Xen domain. It is only valid when the bank
+     * is in reserved_mem.
+     */
+    MEMBANK_STATIC_DOMAIN,
+    /*
+     * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
+     * bank is reserved as static heap. It is only valid when the bank is
+     * in reserved_mem.
+     */
+    MEMBANK_STATIC_HEAP,
+    /*
+     * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
+     * bank is from the FDT reserve map.
+     */
+    MEMBANK_FDT_RESVMEM,
+};
+
+enum region_type {
+    MEMORY,
+    RESERVED_MEMORY,
+    STATIC_SHARED_MEMORY
+};
+
+/* Indicates the maximum number of characters(\0 included) for shm_id */
+#define MAX_SHM_ID_LENGTH 16
+
+struct shmem_membank_extra {
+    char shm_id[MAX_SHM_ID_LENGTH];
+    unsigned int nr_shm_borrowers;
+};
+
+struct membank {
+    paddr_t start;
+    paddr_t size;
+    union {
+        enum membank_type type;
+#ifdef CONFIG_STATIC_SHM
+        struct shmem_membank_extra *shmem_extra;
+#endif
+    };
+};
+
+struct membanks {
+    __struct_group(membanks_hdr, common, ,
+        unsigned int nr_banks;
+        unsigned int max_banks;
+        enum region_type type;
+    );
+    struct membank bank[];
+};
+
+struct meminfo {
+    struct membanks_hdr common;
+    struct membank bank[NR_MEM_BANKS];
+};
+
+struct shared_meminfo {
+    struct membanks_hdr common;
+    struct membank bank[NR_SHMEM_BANKS];
+    struct shmem_membank_extra extra[NR_SHMEM_BANKS];
+};
+
+/* DT_MAX_NAME is the node name max length according the DT spec */
+#define DT_MAX_NAME 41
+struct bootcmdline {
+    bootmodule_kind kind;
+    bool domU;
+    paddr_t start;
+    char dt_name[DT_MAX_NAME];
+    char cmdline[BOOTMOD_MAX_CMDLINE];
+};
+
+struct bootmodules {
+    int nr_mods;
+    struct bootmodule module[MAX_MODULES];
+};
+
+struct bootcmdlines {
+    unsigned int nr_mods;
+    struct bootcmdline cmdline[MAX_MODULES];
+};
+
+struct bootinfo {
+    struct meminfo mem;
+    /* The reserved regions are only used when booting using Device-Tree */
+    struct meminfo reserved_mem;
+    struct bootmodules modules;
+    struct bootcmdlines cmdlines;
+#ifdef CONFIG_ACPI
+    struct meminfo acpi;
+#endif
+#ifdef CONFIG_STATIC_SHM
+    struct shared_meminfo shmem;
+#endif
+};
+
+#ifdef CONFIG_ACPI
+#define BOOTINFO_ACPI_INIT                          \
+    .acpi.common.max_banks = NR_MEM_BANKS,          \
+    .acpi.common.type = MEMORY,
+#else
+#define BOOTINFO_ACPI_INIT
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+#define BOOTINFO_SHMEM_INIT                         \
+    .shmem.common.max_banks = NR_SHMEM_BANKS,       \
+    .shmem.common.type = STATIC_SHARED_MEMORY,
+#else
+#define BOOTINFO_SHMEM_INIT
+#endif
+
+#define BOOTINFO_INIT                               \
+{                                                   \
+    .mem.common.max_banks = NR_MEM_BANKS,           \
+    .mem.common.type = MEMORY,                      \
+    .reserved_mem.common.max_banks = NR_MEM_BANKS,  \
+    .reserved_mem.common.type = RESERVED_MEMORY,    \
+    BOOTINFO_ACPI_INIT                              \
+    BOOTINFO_SHMEM_INIT                             \
+}
+
+extern struct bootinfo bootinfo;
+
+bool check_reserved_regions_overlap(paddr_t region_start,
+                                    paddr_t region_size,
+                                    bool allow_memreserve_overlap);
+
+struct bootmodule *add_boot_module(bootmodule_kind kind,
+                                   paddr_t start, paddr_t size, bool domU);
+struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
+struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
+                                                             paddr_t start);
+void add_boot_cmdline(const char *name, const char *cmdline,
+                      bootmodule_kind kind, paddr_t start, bool domU);
+struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
+struct bootcmdline * boot_cmdline_find_by_name(const char *name);
+const char *boot_module_kind_as_string(bootmodule_kind kind);
+
+void populate_boot_allocator(void);
+
+size_t boot_fdt_info(const void *fdt, paddr_t paddr);
+const char *boot_fdt_cmdline(const void *fdt);
+
+static inline struct membanks *bootinfo_get_reserved_mem(void)
+{
+    return container_of(&bootinfo.reserved_mem.common, struct membanks, common);
+}
+
+static inline struct membanks *bootinfo_get_mem(void)
+{
+    return container_of(&bootinfo.mem.common, struct membanks, common);
+}
+
+#ifdef CONFIG_ACPI
+static inline struct membanks *bootinfo_get_acpi(void)
+{
+    return container_of(&bootinfo.acpi.common, struct membanks, common);
+}
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+static inline struct membanks *bootinfo_get_shmem(void)
+{
+    return container_of(&bootinfo.shmem.common, struct membanks, common);
+}
+
+static inline struct shmem_membank_extra *bootinfo_get_shmem_extra(void)
+{
+    return bootinfo.shmem.extra;
+}
+#endif
+
+static inline struct membanks *membanks_xzalloc(unsigned int nr,
+                                                enum region_type type)
+{
+    struct membanks *banks = xzalloc_flex_struct(struct membanks, bank, nr);
+
+    if ( !banks )
+        goto out;
+
+    banks->max_banks = nr;
+    banks->type = type;
+
+ out:
+    return banks;
+}
+
+#endif /* XEN_BOOTINFO_H */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 0a22b1ba1d..7d1c8bc305 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -10,7 +10,7 @@
 #ifndef __XEN_DEVICE_TREE_H__
 #define __XEN_DEVICE_TREE_H__
 
-#include 
+#include 
 #include 
 
 #include 
diff --git a/xen/include/xen/fdt-domain-build.h b/xen/include/xen/fdt-domain-build.h
index 45981dbec0..60565fdbf9 100644
--- a/xen/include/xen/fdt-domain-build.h
+++ b/xen/include/xen/fdt-domain-build.h
@@ -3,7 +3,7 @@
 #ifndef __XEN_FDT_DOMAIN_BUILD_H__
 #define __XEN_FDT_DOMAIN_BUILD_H__
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
index 2f0ee42ebc..cb7ddc9807 100644
--- a/xen/include/xen/fdt-kernel.h
+++ b/xen/include/xen/fdt-kernel.h
@@ -7,7 +7,7 @@
 #ifndef __XEN_FDT_KERNEL_H__
 #define __XEN_FDT_KERNEL_H__
 
-#include 
+#include 
 #include 
 #include 
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:10:55 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:10:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000782.1380995 (Exim 4.92)
	(envelope-from )
	id 1uKyZY-0005ZU-0B; Fri, 30 May 2025 12:10:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000782.1380995; Fri, 30 May 2025 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 1uKyZX-0005ZK-TZ; Fri, 30 May 2025 12:10:51 +0000
Received: by outflank-mailman (input) for mailman id 1000782;
 Fri, 30 May 2025 12:10:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySl-00076q-48
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:51 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20614.outbound.protection.outlook.com
 [2a01:111:f403:2414::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 255693a8-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:49 +0200 (CEST)
Received: from MW4P222CA0005.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::10)
 by CH2PR12MB4277.namprd12.prod.outlook.com (2603:10b6:610:ae::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.25; Fri, 30 May
 2025 12:03:44 +0000
Received: from CH2PEPF00000143.namprd02.prod.outlook.com
 (2603:10b6:303:114:cafe::31) by MW4P222CA0005.outlook.office365.com
 (2603:10b6:303:114::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.23 via Frontend Transport; Fri,
 30 May 2025 12:03:43 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000143.mail.protection.outlook.com (10.167.244.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:43 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 255693a8-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wP36aolhyGmqpJ4YuWFaqMUawDqSHTbmmlyVoB6H5kIGHTLzkH8plhbPeEkuyKvNFP+u+Kv1SK79VLyoah6OGGUttmBA1vysbCs/maEMOMtNXPbJN7MaFTjwTP9dc+ugrQB2grwXFT7or56G5p8xrB7e+33AKhkQ7ohmNocl28Xus8G1weYfZhXGnErZg0pOTAt5xoxHU4vFUXqt0Fj/Y/9nRjusL/nTQJ+IjW4a1XRoH9qWou4zm5mPsirGfN5akxgCE2ROFqVTYB0IxVmWr4/MINZ3oW3PI88lP+s0M9Lbr8pocKl7lWrH2YVdCBFMw/zCylbD/D6wPkXvf/jD5Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OqZEAX0EcN1gu3oWhJz9QmC1AjJaiddoYvKcz3dxWGQ=;
 b=opbZwWBHmXUmJATIxaxTfQy6BdviHTRgAkloYD+tiX37Z7b9ZGr0ZeSTmUw4+LRb9BGm5GOCGInN6wdC4vvULrwRhGmKKxvaVcstgInPYWSgV+VBw1F89ZxT9O31ofxlXOVKvsrPj+/mZ+Bm4f+GKYup2+UJ7C31R439gNkVR+nLR7V5dEpKsZgdigphaqZ4rccxgsd5G6msVlaFVIN5ZUR1cimPnt7fNa3EG6k+KCmc1M4Jj+5lLHzl4C0zGHS+cz2WTKUs4lFkAUFh3xvOYmD/b4SDuOKqoFGq9X+NVdUL8f8Ba7MKt0Mt+f5f2nm2aQDCL+4LiTlbb83L9hCmPA==
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=OqZEAX0EcN1gu3oWhJz9QmC1AjJaiddoYvKcz3dxWGQ=;
 b=Gfse2k53SRuzeV2cRsJfaYgj6lF0NzhdIM98D+JpoAUHd+pSFrlsvJKMVMQ7LImx/zFvWnTMO9XTHI4tk4UQrpO/yep1lN85sZn9wTEciBMi+b5QRGscSLLYdlxrM3Efb01Bl+dhxFXPFOhT/3jqpVUOWR7lQxmd/AIzt+6xibE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Andrew Cooper
	, Anthony PERARD ,
	Michal Orzel , Jan Beulich , "Julien
 Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	, Stefano Stabellini ,
	"Bertrand Marquis" , "Daniel P. Smith"
	
Subject: [PATCH 18/19] xen/dt: Allow CONFIG_DOM0LESS_BOOT to include device-tree/
Date: Fri, 30 May 2025 14:02:26 +0200
Message-ID: <20250530120242.39398-19-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000143:EE_|CH2PR12MB4277:EE_
X-MS-Office365-Filtering-Correlation-Id: f504fd1b-27da-498c-f6e9-08dd9f720606
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|36860700013|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Vuoeizq3qIVm6h0+s2fVwC7CZ7hrvIbZMQEIBU8OfKMKQyQ8DyN8WGFYRGMV?=
 =?us-ascii?Q?haCeZ+feA/zCinmELFoXKtY763ghJPjYIZJjGruQpNrAhpLoHYN4TRHRtHnD?=
 =?us-ascii?Q?6rl++SnFkyTedeYyyrC85+pR40pdjeO/XfxK42u9UoR0JmWJvfHtA+mRX9jm?=
 =?us-ascii?Q?GmP0tMeUIhyv4D3VPOJU7rkzV+cAe8JMwHxtl52CA1IY7UQwAIzG/ndbetjk?=
 =?us-ascii?Q?8+JuOn/PCMoEBM3utEG9oRCubek4U+Woj7aCYRYScUTWX0IKGGGUKEChy2LY?=
 =?us-ascii?Q?8GfaYE2VgGhiTQL27PjvdTRui/hxXUI+3lKKdO6OyVeyrdScP1FkbXh33N6B?=
 =?us-ascii?Q?RXTHfV/jNjHMJm8EOSpfl+tUUxoPrGXOZXGF8CBcPJ3rNbN9AtPwBsBCyFmq?=
 =?us-ascii?Q?0zsIrljQ1H0qRQvS9OaoPLFJpUxS4rh8t29HozaFpfwdEMXlTE3XjRGv6SJa?=
 =?us-ascii?Q?Ci6LqqWifI0zJzA1GPwPwTVEDhyhyB41xKtTQZGold9TxaELRPWXgxYUw2ua?=
 =?us-ascii?Q?CRr0B+hvZoH+3pfIEdl0X2FygzJEkt2ZKRB/eoEIYUilM7c1gJoM9EGFUs74?=
 =?us-ascii?Q?oWyIFBmfyYk/2PpQpQP+eFzElKifdPM+EEgXMuP85NUyAWY0kUcc0p8D2wu3?=
 =?us-ascii?Q?GC8+YZAIkwtT1eEv57efsD83tcgxfvaR56rrymF5VkipcHQqjJMGkamvg339?=
 =?us-ascii?Q?UeC45jXr2nd+bjYH9ZBUKus4FoTO90uQzZABe5WBVSXpEbZQ1qoJPi0+MiY5?=
 =?us-ascii?Q?aJ2i+H1/q2UJi8OtOugKjNqgqg0VZP6td/k2piHCL9N1iMP98b/KKIIpOMQp?=
 =?us-ascii?Q?13BWj+Su/NgU7pM3lL3IVOTcV1AHcwxDx7lSkZC1sfXCeOz5bLMNaOKDcPjs?=
 =?us-ascii?Q?cl87EIb0tiwJbV2ovnlkc3DxNYAyCeqtIAmtcBtuUtpvjN8Wfz4MrB62dxDI?=
 =?us-ascii?Q?tejne+sAm0hf4O7gGNERDZdaWW4v2Q1m+aAg4jpmmEuDozgM23XWIbQ234Uq?=
 =?us-ascii?Q?DOrYdqzkeBPdRAbf71uZJKGVzr5b4DXeRbhOsq41TzMhP4C6LhaxF6I13+V8?=
 =?us-ascii?Q?W1m2HJNqfRt9sluMODj9QI7u2ZiPwXE1T13f7Q72l5HBKaGfZhxOrnTj7LxY?=
 =?us-ascii?Q?2C0LPFnRBuYbp559DVPO8GN0YhxD0vK7QeHrJ8HqxQMiT75jDGEKkvG854Mb?=
 =?us-ascii?Q?FMvXZU3dDqFgLpkE/gs8vgyEYT4nOOOKTG7yC7JNUQWTaF+G8ACj7Q3EW5HT?=
 =?us-ascii?Q?nh5n3RVF5YQn4RhN7THwPixBeODWv1HK28JJ8becumWhj4xhWZr+M1ZInhJ9?=
 =?us-ascii?Q?3Dx/pkJ/ZTjfOyJyGSiE4zZn/BAX0uS2tRKq1WygJqTKzRWmZvNN2mIMx6rV?=
 =?us-ascii?Q?bWHrSFqTNuc/5VSTVg3o/enRLbmtuPhPZkZ4RgWvNZidXuE/MX5rhQEylat6?=
 =?us-ascii?Q?gIzjQ1NqkRFPczVSOLzPnOeV2cpMeweqbXHpsgX1lcYg10VSbOFaVckjjUx7?=
 =?us-ascii?Q?MksQvFyPefLey8hVnsdu5cq3SamvXPn+IzW5?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:43.2146
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f504fd1b-27da-498c-f6e9-08dd9f720606
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000143.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4277

... without CONFIG_HAS_DEVICE_TREE

Signed-off-by: Alejandro Vallejo 
---
 xen/common/Kconfig              | 1 +
 xen/common/Makefile             | 2 +-
 xen/common/device-tree/Makefile | 8 ++++----
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 0951d4c2f2..353ccbd06f 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -14,6 +14,7 @@ config CORE_PARKING
 
 config DOM0LESS_BOOT
 	bool "Dom0less boot support" if EXPERT
+	select LIBFDT
 	depends on HAS_DOM0LESS && HAS_DEVICE_TREE && DOMAIN_BUILD_HELPERS
 	default y
 	help
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 98f0873056..2717c81f9c 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,7 +8,7 @@ obj-y += cpu.o
 obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
 obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
-obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree/
+obj-$(firstword $(CONFIG_HAS_DEVICE_TREE) $(CONFIG_DOM0LESS_BOOT)) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
 obj-y += event_2l.o
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 922c5bba9b..4c09e3fb2d 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,10 +1,10 @@
 obj-y += bootfdt.init.o
-obj-y += bootinfo-fdt.init.o
-obj-y += bootinfo.init.o
-obj-y += device-tree.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo-fdt.init.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += bootinfo.init.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
 obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
-obj-y += intc.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += intc.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
 obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:11:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:11:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000797.1381025 (Exim 4.92)
	(envelope-from )
	id 1uKyZs-0006jr-Ou; Fri, 30 May 2025 12:11:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000797.1381025; Fri, 30 May 2025 12: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 1uKyZs-0006jh-Lx; Fri, 30 May 2025 12:11:12 +0000
Received: by outflank-mailman (input) for mailman id 1000797;
 Fri, 30 May 2025 12:11:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySS-00076q-0M
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:32 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2061d.outbound.protection.outlook.com
 [2a01:111:f403:2412::61d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 193936b2-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:30 +0200 (CEST)
Received: from CH0PR04CA0095.namprd04.prod.outlook.com (2603:10b6:610:75::10)
 by BY5PR12MB4180.namprd12.prod.outlook.com (2603:10b6:a03:213::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.25; Fri, 30 May
 2025 12:03:23 +0000
Received: from CH2PEPF0000014A.namprd02.prod.outlook.com
 (2603:10b6:610:75:cafe::ca) by CH0PR04CA0095.outlook.office365.com
 (2603:10b6:610:75::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Fri,
 30 May 2025 12:03:23 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF0000014A.mail.protection.outlook.com (10.167.244.107) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:22 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 193936b2-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WCZSPjqqpRWyN9AqgalFKOiDTrWOp9gdaU+mL0xcic30zYJAxgY1SDtslm1vOgBwwTTqe8McCjGuWaib6L3sogSHpcvnGwlz34rLSHWg2gNgBv3E4GI/xOqhY/Y/mGdfTe43w1EF2ejwudMJXf+wrhhlKBmVSW5cUNDy3lrGlIr2QOjhpp8YEblbekJASo2M6atZsGJnS5BPyina6DFOFItJLvqw8csQPEMUKlr/EwHeagKAqLjwcS1D3s5WPnjt9bkc2+J0cCmu6B43BnZzy7+mdW0CUZM5guslNgkTONYBTI7mG/rdtoZmofNvzc8cYKMF6a9XmBXYsDMdh0LG0Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lh7ewCrrIM0zkU9a/iiqTktsuVi4TxAGs/l1EJ0Ddg0=;
 b=Ph2+vlCWzso3pIY6FJ+HoxeDfCP1K1/v7ij2wEvs1SAPLPcOK7hLzD8Py4S1UVhmUd2YBaNiLsfqyyKKUYqxAgzBAfr1Mikwzhgyqqwq9CU5UcdeIz9HUk9giYPGuOTJcfw4XBhfNTBHkkLy7wvswwfJiyc4m4SPK8LFM6h++ZBfvjndJ/HP6+6aOrRunYZQWr/V5/cVAc/Q/0ZYKjlPBGALH4HKbrppP+rWru7T8CqWnELImKiNHYmNXr5r5iWnJdzg3skcI9M+2/49bHR36A+K7bzyMAJjkSsitPxlfBz0RYkZc9mr4anriTlxl3he1wXVJVR3QHPaYs0hvK0Pdg==
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=lh7ewCrrIM0zkU9a/iiqTktsuVi4TxAGs/l1EJ0Ddg0=;
 b=sYUruGK+bR0evDJhEaylVN28UR32S5Zm+sDPnWSGXaahDTFqNObpWMz8Ci4YleKEvKOSdVqIJfLrX2M/9h4hYP3BZTnVRxQ8digMvH4VGyVx1nZit/jOZFTq7Ow16Sqc8iqMrHqqQDRFewh6WoDAXTA3rPyfHKWojKzzb9nj1J4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH 08/19] xen/dt: Add BOOTMOD_MICROCODE
Date: Fri, 30 May 2025 14:02:16 +0200
Message-ID: <20250530120242.39398-9-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF0000014A:EE_|BY5PR12MB4180:EE_
X-MS-Office365-Filtering-Correlation-Id: 3be31408-4e36-45d6-c202-08dd9f71f9ef
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Zn8Ghrk/oI+ejLkPnT38dxN4FTvByaAlfvaW/6k+uJe7B20oc4Vy+oTWiUE1?=
 =?us-ascii?Q?AV+YPYoDLd0RpnPTFIl7vkLjTqUVns0n2eDd85RuQ/ApRHllaqPM0bDgswG9?=
 =?us-ascii?Q?HVVlI4x/bvltDNVfSqVZbe4LJxTWsZJEdPrtu6zagq/wzmDSTlQCnQoBtIbb?=
 =?us-ascii?Q?tZdfIMQvqXlsVOEx4bHfRZZk6mdBrr2paXH+1Zf/T3m3f29AgarHWpCX8WG2?=
 =?us-ascii?Q?aFXQva62v+5AWJSYiqGtt6L1sdyU/4n9i78mFFvU26DvHbRyuIXuKPQapSu+?=
 =?us-ascii?Q?0CrnBNlRfAlnATf4Cncl+SfPYxoMEFg9YyWMtk4YMQBCJj1ePd9WTJky/qwq?=
 =?us-ascii?Q?JYNkPtaUE5H2zzmhgucrdRqeTfA5ciUqpuDdFqYGxOFl2dnK/rVDYmXAW5dy?=
 =?us-ascii?Q?WuzVzUxL8f/8gGBcW3bcZWiGOc7Sb176aq2B20OTENJgWkahS57jc4+qpRWX?=
 =?us-ascii?Q?ZtOQPIcw1WrplCTRQCkGlAmNdd5am71LfGvfma4Dzqiagucy5LJ1O0JQVAWm?=
 =?us-ascii?Q?Ly/h/sLQYtK15WITjJ6yHhET7FV+5Zcf7cXOQ56xYcH9lYaC/cCa46VC0+eg?=
 =?us-ascii?Q?HHv2tAAsJYFtxV4DOPDnDQTSTKMeCb1IsyL3OlzZ7JRVnEJoVICwv5orguxZ?=
 =?us-ascii?Q?4VywKZSE7GVFGAN4diXxRJPeWTqU5D1J22wsKxi0CQvFfF/JyPfVrU/6mr9v?=
 =?us-ascii?Q?NvALq2Ux4FvHsmYLrxhaQlRjOvpETq19yMle37esAZqLnhcgadr+jpipmny6?=
 =?us-ascii?Q?REllA1j/lUiF9h+bgs1qS8q6lS04DAF4Q2BLeWyG7RtrnjKTm+kKPhAO6xZ8?=
 =?us-ascii?Q?0fJA6YP3RYhISYHjnw5ZmckljRczEQyKKrivXZ+swPiHgMxeG2V+RHDehPy7?=
 =?us-ascii?Q?UM1ZeXs+rqDYPfd9Rwyb2jQ9YF5i1RltljfyE6zvh2ccC3khXT0aVHU9Rk33?=
 =?us-ascii?Q?i2ShIs3rvKThJMBrUl64LAMeys5WDxjugtyX+cgGuIWkAKrpL6Big9lemFqO?=
 =?us-ascii?Q?B8KunivM0zyfCjah3cwO+vyA3kyNTRnYttqmjbGfOAwVMElZI827a8bXkdvl?=
 =?us-ascii?Q?8BHdZNYVsMijFkUEbnetvTy0a3x1z/ALaw/+ppGZbyH82s3pXbRSvU2nPqkb?=
 =?us-ascii?Q?lC6pxXvvfoQ5MW5G1jwRr1FkEfN1QnvE+omCtxCqQ+OnEGIgV0p3eRq0Eg7+?=
 =?us-ascii?Q?y/cGgd1cCSmUtMit9vMI2Yma7hAGe+DfyBL2RyvhVr0qn9IFpwNOBzD1Ehyb?=
 =?us-ascii?Q?AruwgZ7UijzR7SDqa8TLTkLNWSrlurPNzo2DCHyKEzE/D8ZWDbzPpHHYq6XD?=
 =?us-ascii?Q?/ThK/ztATCJ1rh9d5JuEw77sfvprA02fc84c5Ut5C962LgDG/jf5HyypQF7f?=
 =?us-ascii?Q?GbVLkWH9MB9JqbgWQIoQ4RJ7YEqcNcdvVZx9LahflkhtheSIw3Ekf8e86LU4?=
 =?us-ascii?Q?JXux6EaSEKaQl5aaoDRFe5IADaGLN1MSmXGJSw+jrm8ikACf3eklGb0gipy3?=
 =?us-ascii?Q?aQjMmgMwQ0CSZNniipICN3LREaYf1B97qc7J?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:22.9279
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3be31408-4e36-45d6-c202-08dd9f71f9ef
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF0000014A.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4180

In preparation for x86 to start using bootmodule instead of boot_module

Signed-off-by: Alejandro Vallejo 
---
 xen/common/device-tree/bootinfo.c | 1 +
 xen/include/xen/bootfdt.h         | 1 +
 2 files changed, 2 insertions(+)

diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 76d652c0de..717cfa0962 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -31,6 +31,7 @@ const char * __init boot_module_kind_as_string(bootmodule_kind kind)
     case BOOTMOD_RAMDISK: return "Ramdisk";
     case BOOTMOD_XSM:     return "XSM";
     case BOOTMOD_GUEST_DTB:     return "DTB";
+    case BOOTMOD_MICROCODE:     return "Microcode";
     case BOOTMOD_UNKNOWN: return "Unknown";
     default: BUG();
     }
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 847f019559..d503d1bd4b 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -21,6 +21,7 @@ typedef enum {
     BOOTMOD_RAMDISK,
     BOOTMOD_XSM,
     BOOTMOD_GUEST_DTB,
+    BOOTMOD_MICROCODE,
     BOOTMOD_UNKNOWN
 }  bootmodule_kind;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:11:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:11:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000816.1381036 (Exim 4.92)
	(envelope-from )
	id 1uKya6-0007QZ-0Y; Fri, 30 May 2025 12:11:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000816.1381036; Fri, 30 May 2025 12: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 1uKya5-0007QS-T5; Fri, 30 May 2025 12:11:25 +0000
Received: by outflank-mailman (input) for mailman id 1000816;
 Fri, 30 May 2025 12:11:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySh-0007de-Pa
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:47 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20617.outbound.protection.outlook.com
 [2a01:111:f403:2009::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 22f8a985-3d4e-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 14:03:46 +0200 (CEST)
Received: from CH2PR15CA0002.namprd15.prod.outlook.com (2603:10b6:610:51::12)
 by DS7PR12MB5885.namprd12.prod.outlook.com (2603:10b6:8:78::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.21; Fri, 30 May
 2025 12:03:39 +0000
Received: from CH2PEPF00000146.namprd02.prod.outlook.com
 (2603:10b6:610:51:cafe::93) by CH2PR15CA0002.outlook.office365.com
 (2603:10b6:610:51::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Fri,
 30 May 2025 12:03:39 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000146.mail.protection.outlook.com (10.167.244.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:39 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 22f8a985-3d4e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FApZYcNUFDbA8t5TTmmWAev4Z5M7nfjSK4QuSVIuvuG4V4aq9CF484LV6SH8tPTuaExtGKXgmu/1UcsdZMAUJsT49x2uKsclR6F0wPpUubzDMLPI6nrzy120N2pi8POam8tOlL3KoeSl5dYFxDgWvy2piaRUkmo1AFyuyFLtvsSxjC+DitH6Chmyq2MPHwqNhBKVDvIpzqnqFPx3ofD4IzoexHnebCnZeov5Jk1uq2GPuvcxl3IooBUIeK6tOSMsyTABFsIoC12oOJqqilyLHDO6EJnJmGbReQ+DEo3v2ITf7tGn43FUndO/ZbVoLm5+5OTOSlOCP98Gu4U3shcsiQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=brxUSyWoWAWqxgYUG8qaIMM7Yyx7/AEhfufohTwOIXw=;
 b=whoI4/Yktv7McRxiKSJWf7JOBZrcYRZefilaG2gVRQI41iz/DfG493r+cB0T7a+NCgn5nRxmC6xw+tFp8qBoGj1obcwk5ljW0XCEirEc6TRyI1lkhdXITElhvbAF6S9DNQWxORbPWJjJ2HDhxW47NDkdEuvbFnCfeM2tWfQWnAAWiCp3fdC8iEBNg9SQldBYTuvu/6XdbH2fQv4ismcgWGmxh8lFcNv2q+RpvggceKTwo7KpJdf1dUUwpjodFTF1qvTHcQCV1gjTgzyYuDbMKSD3Py2ZQivVYoEsXUJ7IRhaTRvg3ZM3Sx429RFH/kIUIoNecix/ZkChsk/kYmGt+g==
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=brxUSyWoWAWqxgYUG8qaIMM7Yyx7/AEhfufohTwOIXw=;
 b=DzZzlL7zUnuVTqSHzmw4DRKEzovfI8CEc7TbmadFxSpWDgItOKBpfiT0F22VQAYYGLVzTBAJrS07Ik9CpuK7y+ZUAVwU1n66FUOV0QBytnFpNSIe80LZfCLx61Ob6BfD8NWWHm/j4wf8w5KYjhMwsr6j/kGjwY2WnhORL1339OQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH 17/19] xen/dt: ifdef out DEV_DT-related bits from device_tree.{c,h}
Date: Fri, 30 May 2025 14:02:25 +0200
Message-ID: <20250530120242.39398-18-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000146:EE_|DS7PR12MB5885:EE_
X-MS-Office365-Filtering-Correlation-Id: 2118cca4-a710-451e-0921-08dd9f7203ed
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?sQVYap2R5s5FGKz4VYuN3+3p695tfy2wSxQ9jyCL/2G3YJQ0iWCdSMlC8UA5?=
 =?us-ascii?Q?4wI+bgKhcNZgiV3ZsqQ9hMdppi0FXoEetRY/8CvJJXze55ALraeNOibHn9wU?=
 =?us-ascii?Q?BLznXIdaMdYYjnQMbde9I3UC/WBFv5b9I2jXGksk0PTSKSZ+iWXf1nEy/0M8?=
 =?us-ascii?Q?YG4UlAWitYofLompjcX9POBEcI2gBETuwmHIerOWmx7XSZ3J6LxKNggdAz7H?=
 =?us-ascii?Q?2sGwNjkOncUbTXUN6T8QIyvyHoPV4HA+8H3nv0trA/MKTxOH3JnzTe8bY2iB?=
 =?us-ascii?Q?SXrXzMIu4X8de4Gx/0Te4QS3gAWQQu+RzMbIf3uQKbbqwHcW6jlDRfxElPZe?=
 =?us-ascii?Q?LApAPuJexW0RQRNZk776Ye1dtNBU98Yqln3Si6W2Yr7Oje/bDHnXiEXr+y1c?=
 =?us-ascii?Q?fPsafBqVRU6+nrMU/zOKezODI7jASA293435CRxKX0q/SlpoGjEF6TJ4zQ1b?=
 =?us-ascii?Q?I7/JR5N0YEB3rdojPT8YAu0eFonvW9OPo4vxHGT5AZmcU9IeT6QXWXNP+/rE?=
 =?us-ascii?Q?cFV3TSyBf0+HA+Bq7TK9HpKujjC3JrHTNgjArbOUCcnfhNLCbedWsK9sbv3h?=
 =?us-ascii?Q?FvHU23L1JNPFFQNLxG3w8kbi6tJULjXCW7F+vVqwXFelUR9Y4oVM+t8+upJW?=
 =?us-ascii?Q?WwL4eBJs88UAMbU6wO5acuu1s9VKtva5z+djbAap0jetIAECLWLRSXlxqNJs?=
 =?us-ascii?Q?QK52hwgQ6EZVTf+W94mMuWlofYMixj3BGF3HjtOBXu2WNPARxvoyBhxgM1XB?=
 =?us-ascii?Q?65t5GxtjkzqkPBrRZ6fEBKU4tSUMFWpPbyNaf1O3dRQUPLg3LQREg4z0/nsF?=
 =?us-ascii?Q?OvSkaS+5C84FaILBlI/bAoJVfYd9/mf/3GLyJ3aqIpAKnPqX1aTEEv4uNFUR?=
 =?us-ascii?Q?gggEJB0HTuAZBjP7nrB66nfSzrqJ1rJS26XA6TM+1KodJdknmd4cLp+LwpHf?=
 =?us-ascii?Q?G6VO4wJ5xf+hgOwxik56V7lzM1k0iW+AUFX1rqolTvYSXoPvWnKFCI4a1wuK?=
 =?us-ascii?Q?g+4++okKfucZxDjZT51rpnQpJEnOVGNM4QNYGUBFCYDm+Kdae/dsh5WFV5nx?=
 =?us-ascii?Q?KYqPLr11sNXtMZ1EwbDNjSKRgPyXLxOipIthxwSncYvx94+1OFrUN9I8gkLO?=
 =?us-ascii?Q?Rdih1Q2IVsKW6XGhvHitir63gWQ5hQvor41REb8rMF5oGJiu9ugyjhqd8Fck?=
 =?us-ascii?Q?zHPc8daXr60eacGmyDwhXN0vSNlGmMYilUDWTO9z6Apq+fyrxStlP50PEPnr?=
 =?us-ascii?Q?Pm6e9LN7hSw1XbdN8p9kXPWFPSD7YAtcvMKaI9KbwvpPPZAJJQkKP79N0TvV?=
 =?us-ascii?Q?VXkguQSlxfGPgRkLGqvnbcFbUOqyCFxLsgSXZJ+WIJfeEGD0HztVztWm92vc?=
 =?us-ascii?Q?6K9yZSBmlyqxiZcqh2hfddhc2V/bDVw6A24V1Z91wU2AnJWAwqF/BlU1Wdlr?=
 =?us-ascii?Q?AeU1FHgMntMUdnfUKQEk/jKAUqbJQWOXRfAE5zbUyDG7u/hSxXdnP0fJsrVK?=
 =?us-ascii?Q?xpfOj0N2pmYGBAQqrj6efpn+/70czmTk4sHm?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:39.6891
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2118cca4-a710-451e-0921-08dd9f7203ed
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000146.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5885

... which means, device-tree.c stops requiring strictly CONFIG_HAS_DEVICE_TREE
and may function without it.

Not a functional change on architectures that currently use these files,
as they already select CONFIG_HAS_DEVICE_TREE.

Signed-off-by: Alejandro Vallejo 
---
 xen/common/device-tree/device-tree.c | 2 ++
 xen/include/xen/device_tree.h        | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
index 886e6c7712..c8a9c0e46a 100644
--- a/xen/common/device-tree/device-tree.c
+++ b/xen/common/device-tree/device-tree.c
@@ -2028,9 +2028,11 @@ static unsigned long unflatten_dt_node(const void *fdt,
             ((char *)pp->value)[sz - 1] = 0;
             dt_dprintk("fixed up name for %s -> %s\n", pathp,
                        (char *)pp->value);
+#ifdef CONFIG_HAS_DEVICE_TREE
             /* Generic device initialization */
             np->dev.type = DEV_DT;
             np->dev.of_node = np;
+#endif /* CONFIG_HAS_DEVICE_TREE */
         }
     }
     if ( allnextpp )
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 7d1c8bc305..641f24518d 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -109,9 +109,12 @@ struct dt_device_node {
      */
     struct list_head domain_list;
 
+#ifdef CONFIG_HAS_DEVICE_TREE
     struct device dev;
+#endif /* CONFIG_HAS_DEVICE_TREE */
 };
 
+#ifdef CONFIG_HAS_DEVICE_TREE
 #define dt_to_dev(dt_node)  (&(dt_node)->dev)
 
 static inline struct dt_device_node *dev_to_dt(struct device *dev)
@@ -120,6 +123,7 @@ static inline struct dt_device_node *dev_to_dt(struct device *dev)
 
     return container_of(dev, struct dt_device_node, dev);
 }
+#endif /* CONFIG_HAS_DEVICE_TREE */
 
 #define MAX_PHANDLE_ARGS 16
 struct dt_phandle_args {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:11:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:11:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000819.1381046 (Exim 4.92)
	(envelope-from )
	id 1uKyaA-0007mO-6U; Fri, 30 May 2025 12:11:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000819.1381046; Fri, 30 May 2025 12:11: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 1uKyaA-0007mH-3K; Fri, 30 May 2025 12:11:30 +0000
Received: by outflank-mailman (input) for mailman id 1000819;
 Fri, 30 May 2025 12:11:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySU-00076q-0x
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:34 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20613.outbound.protection.outlook.com
 [2a01:111:f403:2415::613])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1af8e6d6-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:32 +0200 (CEST)
Received: from CH0PR13CA0003.namprd13.prod.outlook.com (2603:10b6:610:b1::8)
 by CYYPR12MB8701.namprd12.prod.outlook.com (2603:10b6:930:bf::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Fri, 30 May
 2025 12:03:25 +0000
Received: from CH2PEPF00000147.namprd02.prod.outlook.com
 (2603:10b6:610:b1:cafe::8a) by CH0PR13CA0003.outlook.office365.com
 (2603:10b6:610:b1::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Fri,
 30 May 2025 12:03:24 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000147.mail.protection.outlook.com (10.167.244.104) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:24 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03:22 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1af8e6d6-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=I2l1Toe2RZF/N4xhqBhqqgmVCR/CDiSq47ExVoV0yZ6FqpcOp+ZnfVNrTf0SiyVgriNpMhAXiWY/SW/92itvWGe8Uv4IFJ4yzN7nOJLUb5OpMR2BwbKeI5xnoRIRQosl2g4UtLesEFp5K8FFLIAAle9d274GYYcxlr4kXnrUMLCqotgmRKVYNBmISMcdihlozH6tsz4DCjjVj2xn1l/6jvZJ6lka090H763f8rUp2jKG/6kTDZLxV0dPr/PoY5PQwrTTRPamNoYJQ2cmMln5buu6UhaWbnViaGQcadgEQ80SbVni1ki96kXuODBQjLtEBIGZi6xOPtnLvzdvEiH5rQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KCNBXPXD2aKN1qe1F0kvtAXVlpJprW3tfZvK/Z8sjKc=;
 b=HPskpW0DkqHpsjORbSMq2hA2HisLfCY0GeoYgJyR44vpCyLnioHNiX9P74HxQ+nIsf2vK2LaDAqFSEIq6gHqq5lgQTpuBhHeaAwzN1qyccJGEQk8St7RE3AEbO77N4+ppHZbgghyo8uuVPgSuSdO4cW/X4Fzp5ignn5/lH1woJmHZwFBHe/nRsCSVjXsCVmwA8NGCdZTd1fYxX/JNM1VKk7vjP3rVoJVHYfD/ZGgWnzOJ5vq/1OxnyFiyOSQuLro70ubCIrogHIlMgWLQGnEI4eClPDVlRgILrfY+XQraXzLnbfJvWmfZlJKmGCj6J04ihSNsUMzjffskG8IEAP9IQ==
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=KCNBXPXD2aKN1qe1F0kvtAXVlpJprW3tfZvK/Z8sjKc=;
 b=UoIgWKwwOG5PfdoJN3/q0roPujJbKYCxiD1qKJgpNKgFlf8iar8hjlQQZWn08vhUaBPFiyEwCoqHrfDrxZQf7RjytVdEGlTdu9CAnwqsriGJBVz9yOhkInoX9mfqyfrmIT3kHLUXZ9BD4VDLaX1rp9jIdKYeHaXtuD7lLBQRdfM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Daniel P.
 Smith" 
Subject: [PATCH 09/19] x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN
Date: Fri, 30 May 2025 14:02:17 +0200
Message-ID: <20250530120242.39398-10-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000147:EE_|CYYPR12MB8701:EE_
X-MS-Office365-Filtering-Correlation-Id: 0594b330-22c6-49ee-0818-08dd9f71fac7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?BnlSpW3J1x67g0+/Ocgag8Jp9EC7m2MTi9LfIKWDldWK4SpHHlq9IMuPUZ3Y?=
 =?us-ascii?Q?by5Fb6kelrpa/HkhvSM5diIPzkOTs/tDR+maMvtlr3FXkKsZkbfxpk+q8HUq?=
 =?us-ascii?Q?H9V0xRO58oMG2TO0Fn7qrlvlkAW3MIF4KtuEZq0sNq4sorCABmjMXTN0+6hC?=
 =?us-ascii?Q?ngttbCYBghRkxGxrTeOAgNxNp8ovouSyg/KMsDDpuxVxx45IQqATLcQ+FWSn?=
 =?us-ascii?Q?v+2wG+C1BvuC1EBjJh5K+3gpWxoB9NwM/9w6xn9WC7qbOKERBCtqUF6EMnF9?=
 =?us-ascii?Q?KBwDo4LABhmDiZA4VhDyEwx+umufNCh4EAGxOR+WXvWTdcH9NUpy6oGGlZ0m?=
 =?us-ascii?Q?ftprhEQ6lfu9IKSIG7lZ9r86flVqlwS6id+wCLLGuRrYDpijis6LhBjJLm7L?=
 =?us-ascii?Q?dGqJSZsFT1ySf/fTE8EhSDJkXD9cgVjIiZdAQ4BwXA5DBLRBSVbQG24v7rDE?=
 =?us-ascii?Q?7pE/o0tm/9RA27uulJtlWiR6PA9KGiC0NIJFQiKuFHQEVhCWO0pGWrhPxvbA?=
 =?us-ascii?Q?MsUb+qvIZQCLlE0pXCr7wjIhRAz46tbiSpF52FMy36qTOYTYxnxrnNLCpoz+?=
 =?us-ascii?Q?FwZozNXBTxIEhYfHHiz07xWQE4C3Rg22c1WmW4DL66Ot1o518+oEYLucho8p?=
 =?us-ascii?Q?kZFUkY1eskfWe8h5S0TJI13UTBTvhoOIg6AaRVW8zjVNH1+vslNCcOb5iBoq?=
 =?us-ascii?Q?CsYEgc28PpFB0AGgUNIr5WouiCIe8XzdBfU2zylg86oFaUnzQZAuSXb+pM84?=
 =?us-ascii?Q?63A5eeT3tBN1cHIo7mfhuTJGgMn1t4XbTbH4itJXrSF90XEHNx+2dorgrQ9O?=
 =?us-ascii?Q?ZHTmw8n+32OH1+BJX3hyMdLzVy+38VmYvDN+DdYXdYLXIsKzBVlDp5BY+hmW?=
 =?us-ascii?Q?uMZaliWUSspB0nrdNczgl2pxDQN4mEu6sxO1sqSc//+/RNfY83CGlLnFUQU/?=
 =?us-ascii?Q?f6OmvRZav2X/CkMkb22UNXBboNVNodVY8uRiWXeW8cPQkFmEIpvHa74QErIq?=
 =?us-ascii?Q?z5cMuaUfaDMZ6LLDF5XYmZNF7XMNH84Pfn0Y5gK2UsAl2uPhQlXvnsMsdfD7?=
 =?us-ascii?Q?eVBUPjfx+5Iv7Q7J6iaIn6u5+mOA1Xw+WmXPQoQdcXX2NoZTidipmo/Vds/E?=
 =?us-ascii?Q?qzRBVNNgEhwX0dOgKLkCHKDnpc88SQuhBtSIrUaoWJ8KZiQ9nU3gRsgdjbLb?=
 =?us-ascii?Q?k1g0NXWKo1mv3T3w5U4toRzWZvvEOZ1RjJlsXmNUKTKZMEYc05EYfmJvz2eG?=
 =?us-ascii?Q?nXsLodKMpmhbfX9LqD7pP3qrZolbJRxejAh6q1ex3fYD8XZBnMe2LzBwUxmJ?=
 =?us-ascii?Q?B6lrjs4Xv1Rb6pqFQYQ8j8nT3n/sUc538SXhitXEdK2RA2oaN3Llwlvp0kTg?=
 =?us-ascii?Q?uVK50SJ3v2RiD4e12KXj0xkGJcVqZ5flyHL9V0ZZATeOuGpvPbj5I+tb3Hij?=
 =?us-ascii?Q?BIGNrT/4fz28fe/hRBBYkudliOFVyrw3CN1xmZNxBuM8Z7VdpKczf5r7zV4H?=
 =?us-ascii?Q?+ypylZltmgmZsL20QpGtZSIaLQppulBQSV/3?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:24.3319
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0594b330-22c6-49ee-0818-08dd9f71fac7
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000147.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8701

A later patch removes boot_module and replaces its uses with bootmodule.
The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
value, so it must be explicitly set in the static xen_boot_info.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/x86/setup.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1f5cb67bd0..5da9df33c9 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -298,6 +298,7 @@ struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
     .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
+    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
 };
 
 static struct boot_info *__init multiboot_fill_boot_info(
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:11:44 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:11:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000828.1381055 (Exim 4.92)
	(envelope-from )
	id 1uKyaO-0008RJ-EZ; Fri, 30 May 2025 12:11:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000828.1381055; Fri, 30 May 2025 12: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 1uKyaO-0008RA-AZ; Fri, 30 May 2025 12:11:44 +0000
Received: by outflank-mailman (input) for mailman id 1000828;
 Fri, 30 May 2025 12:11:43 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySX-00076q-1D
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:37 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20631.outbound.protection.outlook.com
 [2a01:111:f403:2412::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1ba186f5-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:34 +0200 (CEST)
Received: from CH2PR15CA0014.namprd15.prod.outlook.com (2603:10b6:610:51::24)
 by SJ1PR12MB6218.namprd12.prod.outlook.com (2603:10b6:a03:457::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.31; Fri, 30 May
 2025 12:03:30 +0000
Received: from CH2PEPF00000146.namprd02.prod.outlook.com
 (2603:10b6:610:51:cafe::41) by CH2PR15CA0014.outlook.office365.com
 (2603:10b6:610:51::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.26 via Frontend Transport; Fri,
 30 May 2025 12:03:30 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000146.mail.protection.outlook.com (10.167.244.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:30 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03:28 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 1ba186f5-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ax0ij0GS99gpbdJ7fP/qchacW2KBlX59oAms24xUH7g8qEssaOPpDyqPcepgfL/WecUu3ef4NIDiTO+V24lE4l7mic4+fNFgzj7Zp3wFSAX8nTfeD7hkgDV8QQlh/lPGtQHGUbYYPAhz1+g6S9s66IWb8eFw59eMOdFr2DuQfwz0Echvu/BPPdHCjhjAWxMgQHjvtZ+1JrysXFLNNiZngaRULlA688VTtPCwtqmOLnLMi1lj/LNNxd1L/O/wQL5Hef65qNnYryCsNZjicPk/ZagTMCU5t264PESX1fcAjqSGjh9eAr4Rg8JDEWI14ps9i9XvG2NpS9j8fmhSbCyNQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=34ICjvzD4lVMM+wfqkK97CeOJs6tTTN5/D+GOWUdGNA=;
 b=LuJV9+PW4UtMj6+NYATCeFq4Eo8MV1OARLUp1m2er3Fyi7BUZ+AwUQxr620s7F76CYjNTRfQ3axJulZVil2SQ1K1ovyAM+nUFRVAzr4BQ++miHtLH6c3rNKuQ/vYx5TBXLRC9xKSt7+CB8t8o55XXZ+jVl0+7f4hOV/9ypF34dsdz0aK6yqgZhynjoQEKirVdzYKifrysdhDDq9KBz2dPAc/pMQpO4a6flG5ZercZH47FDsjKjCAKdKznXGxiJaN+7asTQnrVwCbzzxyVDx4UYRIU9fdo5EcYDdGB4S6pp/X5yFMzW94+8FqT1jWe+1yrWEVFuKEOeplQLNqDUfF6g==
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=34ICjvzD4lVMM+wfqkK97CeOJs6tTTN5/D+GOWUdGNA=;
 b=TdaZqVmlpOFJTfDpR9WzjFHI9LcWIQdjZ0m3jaldiEWQ36MoM0Lt0N+B7od0kjTwfnoWjuCdHJZgY0ZUc63cJC8TMaADPlB0meN+r/MJwUMzfwv5CRvkaS1sgfUqv6mtFFemwm3ho8R5hIwOH0TIyDqfH6eVSrSTA77nkin/g3Q=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Volodymyr
 Babchuk" , "Daniel P. Smith"
	
Subject: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h
Date: Fri, 30 May 2025 14:02:20 +0200
Message-ID: <20250530120242.39398-13-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000146:EE_|SJ1PR12MB6218:EE_
X-MS-Office365-Filtering-Correlation-Id: 21c267a6-8ad8-42c8-24ff-08dd9f71fe6f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?KDW3QzWmpY5+XqfEVARsoPf11ub6wA4h8fgxT4Fi52m8y1TJpy+YcTE1q4RY?=
 =?us-ascii?Q?lMSwlzxbmF1/kXOyEg7vb1cLKIXiLFS8UBPSn3z46g+V/UBzDpJiuRtI+in+?=
 =?us-ascii?Q?sH8qSnwKIcvo4280RLEvhWoR/F0cRw2yXFEjRqg1zpcQBQA1nW2c2MM4QmLx?=
 =?us-ascii?Q?9eoGU4T2QBHGtVl0jLm8Jsy3ApF5pMGyaLyfOEhjXW3nW5bvubJagaFURUF1?=
 =?us-ascii?Q?ztICOE50xR8yRy4IVZiCNMl0V4viMkW/8Sx3eZBvDi6TMZQtzsqrMODL93KT?=
 =?us-ascii?Q?WwSf5AzSErSa7FASd7GU8mi5hvrIyIA0n6o3vqELnw1zQ/ra7I52j4YlYQl9?=
 =?us-ascii?Q?0FMIhS7Ae4THq/hxMPvmaZuFlI7mKnV9k+UXcwrHIFIDjLliMs/ZTVcZ3owu?=
 =?us-ascii?Q?tbYvkJB7NrTeyg4sHM0kM/vgHlxkzVkcxXad7wSyBk3BVSuWJ/lZNuKvX5ph?=
 =?us-ascii?Q?6BpNlwCsksmGppbpPZywemAIQg7kwnfmZ1sNr99jC9tc5+0BeaazkiO2mMZp?=
 =?us-ascii?Q?LppN4PDArFTBL1SDpj1CT4k3sftwHI0N7/g81Ufcj4Qx+kJL7sNY8a6ijLDT?=
 =?us-ascii?Q?Qf25X4u5zrtC/PsZtn+/c81U4ri0wmbl+RKqrM4IbrfjkUznYL3Lg1Mcmnc0?=
 =?us-ascii?Q?6lK4Y41ZMlu5Nx9y2Otm6o+5NhZyWK1SRVcF5+ITY1fs8uw3Nv0eMp4WxC59?=
 =?us-ascii?Q?CKd9Ax0mYqJr630GwsqHEuE7jp5yuxDt2W82/u8tj5JrXX7cDaGLzGqTPrc2?=
 =?us-ascii?Q?Wratskc2bz6/n5Q/pRC82XQXFdTmd0DcXUImYrzn0qx/41VTbsVMwCO0mHiz?=
 =?us-ascii?Q?rlJu8LZYF+kmB/boLr+YRQS/2DkXWzbLN9IAAdgdOl4ZNfEKHYsRzHNaqwlR?=
 =?us-ascii?Q?DUg1AT0hqeJQym3+FCnkHczy7uUVWE24v2453oX9o5yUcnFeumw6AFs/+u3D?=
 =?us-ascii?Q?BqGFYM2RKm+BdXgC6XNhMS+jHAnfquk6h+OIBJ6YmcNDMy4Xa8hJWSV7MyiV?=
 =?us-ascii?Q?Sq9999Fw1ri8dt3otZwosdDY/yCzhDfQbqknbRQwLaxUVBRwwfYL/QSDYncx?=
 =?us-ascii?Q?/YZgC6g8nPeMG/mB1rYL08hnSX6ihaZ5Bc4ZRd/CO/xto5wylfrRKBPs+A16?=
 =?us-ascii?Q?kd+NYEPALDl6lFEoqy+oFNRatA7zjfZGocllCl/QwyRKiq7wx6lSPUV7FS1J?=
 =?us-ascii?Q?Ua+w5cW/8AMSWAijqJxMU1NWhhUhubxJD+CQdm2WpJ5xoxAFZc7HCRqBPFEd?=
 =?us-ascii?Q?CsaWCtmVgDfRZMcjrNP1MEjzz6kpAyOgneoghedwyKP1PwyqUkINand/0bm3?=
 =?us-ascii?Q?Q9V5+S4Yee7oSpZ5QdbWrazOix0YtXlTXOFKyt5ak2JRgXhy6Ts/qoHii8NA?=
 =?us-ascii?Q?Vc/+2+ZWRsqEHaJ34RVggsvj1uuudawLzWrunSzZ+TApxSoYYXziSselXwlK?=
 =?us-ascii?Q?f5A4y/lf+2T+9/9EnK7QkS8vUTSpW6twCN0b4r0tAFhwz+jUnfoF9j5Z6Hap?=
 =?us-ascii?Q?WqyUgwD7rqsvy050lb6sW0aEbxG1KkO5f0vW?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:30.4748
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 21c267a6-8ad8-42c8-24ff-08dd9f71fe6f
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000146.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6218

Part of an unpicking process to extract bootfdt contents independent of bootinfo
to a separate file for x86 to take.

Move functions required for early FDT parsing from device_tree.h and arm's
setup.h onto bootfdt.h

Declaration motion only. Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/arch/arm/include/asm/setup.h |  6 ----
 xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h    | 34 +-----------------
 3 files changed, 63 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 0f9e531a34..32308837a9 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -55,12 +55,6 @@ void setup_mm(void);
 extern uint32_t hyp_traps_vector[];
 void init_traps(void);
 
-void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                         uint32_t size_cells, paddr_t *start, paddr_t *size);
-
-u32 device_tree_get_u32(const void *fdt, int node,
-                        const char *prop_name, u32 dflt);
-
 int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
                   struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
 
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index fa65e8fcf4..079259c719 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -2,6 +2,7 @@
 #ifndef XEN_BOOTFDT_H
 #define XEN_BOOTFDT_H
 
+#include 
 #include 
 #include 
 #include 
@@ -16,8 +17,53 @@
 #define NR_MEM_BANKS 256
 #define NR_SHMEM_BANKS 32
 
+/* Default #address and #size cells */
+#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
+#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
+
 #define MAX_MODULES 32 /* Current maximum useful modules */
 
+#define DEVICE_TREE_MAX_DEPTH 16
+
+/* Helper to read a big number; size is in cells (not bytes) */
+static inline u64 dt_read_number(const __be32 *cell, int size)
+{
+    u64 r = 0;
+
+    while ( size-- )
+        r = (r << 32) | be32_to_cpu(*(cell++));
+    return r;
+}
+
+static inline u64 dt_next_cell(int s, const __be32 **cellp)
+{
+    const __be32 *p = *cellp;
+
+    *cellp = p + s;
+    return dt_read_number(p, s);
+}
+
+typedef int (*device_tree_node_func)(const void *fdt,
+                                     int node, const char *name, int depth,
+                                     u32 address_cells, u32 size_cells,
+                                     void *data);
+
+/**
+ * device_tree_for_each_node - iterate over all device tree sub-nodes
+ * @fdt: flat device tree.
+ * @node: parent node to start the search from
+ * @func: function to call for each sub-node.
+ * @data: data to pass to @func.
+ *
+ * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
+ *
+ * Returns 0 if all nodes were iterated over successfully.  If @func
+ * returns a value different from 0, that value is returned immediately.
+ */
+int device_tree_for_each_node(const void *fdt, int node,
+                              device_tree_node_func func,
+                              void *data);
+
 typedef enum {
     BOOTMOD_XEN,
     BOOTMOD_FDT,
@@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
     return banks;
 }
 
+/*
+ * Interpret the property `prop_name` of `node` as a u32.
+ *
+ * Returns the property value on success; otherwise returns `dflt`.
+ */
+uint32_t device_tree_get_u32(const void *fdt, int node,
+                             const char *prop_name, uint32_t dflt);
+
+/*
+ * Interpret the property `prop_name` of `node` as a "reg".
+ *
+ * Returns outputs in `start` and `size`.
+ */
+void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                         uint32_t size_cells, paddr_t *start, paddr_t *size);
+
 #endif /* XEN_BOOTFDT_H */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6dc1fb5159..0a22b1ba1d 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -10,6 +10,7 @@
 #ifndef __XEN_DEVICE_TREE_H__
 #define __XEN_DEVICE_TREE_H__
 
+#include 
 #include 
 
 #include 
@@ -22,8 +23,6 @@
 #include 
 #include 
 
-#define DEVICE_TREE_MAX_DEPTH 16
-
 /*
  * Struct used for matching a device
  */
@@ -164,17 +163,8 @@ struct dt_raw_irq {
     u32 specifier[DT_MAX_IRQ_SPEC];
 };
 
-typedef int (*device_tree_node_func)(const void *fdt,
-                                     int node, const char *name, int depth,
-                                     u32 address_cells, u32 size_cells,
-                                     void *data);
-
 extern const void *device_tree_flattened;
 
-int device_tree_for_each_node(const void *fdt, int node,
-                              device_tree_node_func func,
-                              void *data);
-
 /**
  * dt_unflatten_host_device_tree - Unflatten the host device tree
  *
@@ -245,10 +235,6 @@ void intc_dt_preinit(void);
 #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
 #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
 
-/* Default #address and #size cells */
-#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
-#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
-
 #define dt_for_each_property_node(dn, pp)                   \
     for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
 
@@ -258,16 +244,6 @@ void intc_dt_preinit(void);
 #define dt_for_each_child_node(dt, dn)                      \
     for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
 
-/* Helper to read a big number; size is in cells (not bytes) */
-static inline u64 dt_read_number(const __be32 *cell, int size)
-{
-    u64 r = 0;
-
-    while ( size-- )
-        r = (r << 32) | be32_to_cpu(*(cell++));
-    return r;
-}
-
 /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
 static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
 {
@@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
     return (bytes / sizeof(u32));
 }
 
-static inline u64 dt_next_cell(int s, const __be32 **cellp)
-{
-    const __be32 *p = *cellp;
-
-    *cellp = p + s;
-    return dt_read_number(p, s);
-}
-
 static inline const char *dt_node_full_name(const struct dt_device_node *np)
 {
     return (np && np->full_name) ? np->full_name : "";
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:12:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:12:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000843.1381067 (Exim 4.92)
	(envelope-from )
	id 1uKyaf-0000iC-Qr; Fri, 30 May 2025 12:12:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000843.1381067; Fri, 30 May 2025 12:12: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 1uKyaf-0000h6-Mb; Fri, 30 May 2025 12:12:01 +0000
Received: by outflank-mailman (input) for mailman id 1000843;
 Fri, 30 May 2025 12:12:00 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySc-00076q-21
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:42 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20626.outbound.protection.outlook.com
 [2a01:111:f403:2416::626])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f0d2541-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:40 +0200 (CEST)
Received: from CH0PR04CA0104.namprd04.prod.outlook.com (2603:10b6:610:75::19)
 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.20.8769.26; Fri, 30 May
 2025 12:03:36 +0000
Received: from CH2PEPF0000014A.namprd02.prod.outlook.com
 (2603:10b6:610:75:cafe::f4) by CH0PR04CA0104.outlook.office365.com
 (2603:10b6:610:75::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Fri,
 30 May 2025 12:03:36 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF0000014A.mail.protection.outlook.com (10.167.244.107) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:36 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 1f0d2541-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EiWgRF++OSBMhis7czWdgjd2sNKcxVmoYLNx0l32yPhjGV5+y/9i9wo9JZdDFmQFzN/hsh6ldnI0UD5Xxubrb6hmvg8HsXG5C1NDiuP1amYe7G97jr0GDRD1VgN8tv0jlsKUQkAH08NqJvEp+70M5SFw9pGEv8cfdPALdxp8SniTksunDTvB4M1paHEPyUQSwtrUcwN53u1kgzZHB6tMwwC4RBR/TXXIDg1IAcWt0mjYMnNBV0+1vZr127yPYKz8lGM6MGkaGEFOEfUs7p0o3xFwjt15Y9q9sNnS1zdFX3CKo/euQ3D1WAmU+gS5gCdeW8opMjs2fGw84T4teYktGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QScSHMvynX6vj1N+8sVjrtazka+q1SLtfC56Og9Zthg=;
 b=RuL7uUi1mqqtOe+v30RgOf/l8SoQdZ8Hur5GaRCHv46H6WgwATatFEWdT+5KxDN3BlNWl9A2Peg9D1WfISwjBAzncjERC2YoNfHn/bRSUzDPmmaRZ5Lnnnwsrbeygd9gMhN1l/do6rGmZO4M23BdzsnzRRuxRgFJpv/ckjTiqofzSfDu826uYmam+NOvTIwbnQY93+RvvGd1F/+5OAkKoX7iBA3hK+QVdCY67ky9OPI2vnDfi+Vi5zSoVS5UoIqte6w5Lqrkt2G/tXDw4wlN/TmqNxJ7Y/0ubBzvXnc/v5xCWikQ151BFu5cUN9j7GGQo55eq9wIu/WjQsNCUIclWQ==
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=QScSHMvynX6vj1N+8sVjrtazka+q1SLtfC56Og9Zthg=;
 b=Lq3oEv9rbQN9s1HeQfPi2U4Fbgxf4GobU+Zv/El9i944nrXN+cb/nKLmBmyeT+wGFutxII8vzQJMPx2HCkjFF6A5bWV4ueWWPfVq6csBIZE6AYBQavtxygqgLUJZtC2Kbqf9Ab5+LZ83llIm8swaY+LQV3Kk3ekyhQL6MCJUnBY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH 15/19] xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c
Date: Fri, 30 May 2025 14:02:23 +0200
Message-ID: <20250530120242.39398-16-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF0000014A:EE_|CH1PR12MB9599:EE_
X-MS-Office365-Filtering-Correlation-Id: 489cc566-eb82-4b8b-223f-08dd9f7201fc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?WNxrTHOoblmj5TT4DE25dJO4q5DxYrM4mdDjCElQxop9yrfhxXF3EmBGvlfH?=
 =?us-ascii?Q?OvQtNZHZxW6U92y3UCVHv/zT3J2QXp62CFcMIcxG2bVeFV6prRBesClJz3do?=
 =?us-ascii?Q?u4duwG6wSTe7q2lSDYtqykp0Yfk8Ud/oabToOvx05xFH7B9F+qJikMQvS8Y4?=
 =?us-ascii?Q?qA137K/+1Pa5yRQYuJa8ga7eegdNrNtWH+7fzlyxUVRSn7y9s68mX5PTO0/H?=
 =?us-ascii?Q?AidlggPPxr+yzvNTOHfREncvxvDinTIK+QCPTgwbAuqN3XTPLvZIU3xAvXmx?=
 =?us-ascii?Q?cf4s8dKL+/e/285MJP8GtTu7pW4DVc6nmjBil41x9vya3GbpEyzt1exQRoJ1?=
 =?us-ascii?Q?847B4E+Jzo7Zps9BNwbR1v+zaTU834x1SnyiCEiXV+EktPHn6vSBVwdrl8Bp?=
 =?us-ascii?Q?oe4yLGJ5GMSx8IwpyLb1I1Jcilw1EEpsUqASZ1ea5QjlMVCZDhHujLM5ZGS5?=
 =?us-ascii?Q?qbFVOjJ5FNeOIamOoRSmYIVCXza3dKwXYm5MWLAJSHvS/ufjRbSGae/jjv2D?=
 =?us-ascii?Q?65h7kD5WoyVSa+Cik8AcIROd67D/mF90nvB1N0EfDiQS95L9iw2OA3pv0rJd?=
 =?us-ascii?Q?teE0gk/K8XSemdvrraU6Bi45asI9fXyKZNdYqsZ18G2Yqf7F52wFbT5zg5C/?=
 =?us-ascii?Q?p/jBnz6E3iFVrwAt9mxrB+CuThX/YRlDsWgSFSsoSLnabXXbrAC2DvkdTJqh?=
 =?us-ascii?Q?lj5X2W25Ya6lQOXldLTgV9a0sErShsjpn+hNVRNVtxdRH2fYoZFdr7Zh1+E7?=
 =?us-ascii?Q?COhmrSZgz6QOp3TGsMu0l/tCMSZ+YzOw+gKYTeJ5TuricSGUfrYv0XiRZFI1?=
 =?us-ascii?Q?xdMNHW4tjpwMdnA+ELqsLS7KVEWj40rBk1GCI3knRiCbGhTmdWI2VRwS5y5n?=
 =?us-ascii?Q?5cpfWQKYICQpDWD6sNRkc1CXCN2ZsG3difK6/Uo2Dw1fV/y5asLTw10K3ORM?=
 =?us-ascii?Q?jk4Nx7yXAZO5FzKhspnMaV+wlTvCvn6GwWAE0j32VhDnR9+w8WFGA++WkA/7?=
 =?us-ascii?Q?z0gNHtcuXnOtEg9SESfti/KxYJ+F3ZsEYRvNH5PwOFtVJZeJXgB6/N80ss1y?=
 =?us-ascii?Q?pQKfSqfyRnGqoBvisBfqmSNQ2w8K7MhZHH7zyvXBPvgQm9aEz2HKijflXBby?=
 =?us-ascii?Q?OHiFlsGLQDRFHAOv+tmK7j/eUsPouishNsx4DfDbY0ZTSPiF7iTeobMqjwkv?=
 =?us-ascii?Q?dRU3MyEM3nZfADgeduJnaOrh67JpT3oiGpqeiEOQcrucVNOs7MSHdX4SHx/c?=
 =?us-ascii?Q?OqoG2jf1JIeFkOfpAGo4CyF+v7LYs9P0T5lTT0eAYDpI2I2wAGihafC3LZGo?=
 =?us-ascii?Q?VOtkNKJOhv8G7/aZVzz6xikYyGIU+J2mlv8wnxXsn2all1SAJTjPOnTsEqoQ?=
 =?us-ascii?Q?IJanIp3cXiwAf7TAVEh5fYSL65NPc+bynkA2hdznjpPSXId6fhZij+0p4xeV?=
 =?us-ascii?Q?56TffGs48Hlkl+6E19V+GJlZ7Ujbz1T4hwPBC2lGu1he3fG9kxfAH7Ve4exz?=
 =?us-ascii?Q?gogaRszHyAMsRxltxXssAYBKYy+K95G2l46/?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:36.4320
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 489cc566-eb82-4b8b-223f-08dd9f7201fc
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF0000014A.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9599

... back into bootfdt.c

These will be required by x86 later on to detect modules in the early scan of
the FDT. They are independent of bootinfo, so it's cleaner for them to exist in
a separate file.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/common/device-tree/Makefile       |   1 +
 xen/common/device-tree/bootfdt.c      |  97 ++++++++++++++++++++++++
 xen/common/device-tree/bootinfo-fdt.c | 104 --------------------------
 3 files changed, 98 insertions(+), 104 deletions(-)
 create mode 100644 xen/common/device-tree/bootfdt.c

diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index bb6d5ddec5..922c5bba9b 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,3 +1,4 @@
+obj-y += bootfdt.init.o
 obj-y += bootinfo-fdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
new file mode 100644
index 0000000000..5decf17faf
--- /dev/null
+++ b/xen/common/device-tree/bootfdt.c
@@ -0,0 +1,97 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#include 
+#include 
+#include 
+#include 
+
+uint32_t __init device_tree_get_u32(const void *fdt, int node,
+                                    const char *prop_name, uint32_t dflt)
+{
+    const struct fdt_property *prop;
+
+    prop = fdt_get_property(fdt, node, prop_name, NULL);
+    if ( !prop || prop->len < sizeof(u32) )
+        return dflt;
+
+    return fdt32_to_cpu(*(uint32_t*)prop->data);
+}
+
+int __init device_tree_for_each_node(const void *fdt, int node,
+                                     device_tree_node_func func,
+                                     void *data)
+{
+    /*
+     * We only care about relative depth increments, assume depth of
+     * node is 0 for simplicity.
+     */
+    int depth = 0;
+    const int first_node = node;
+    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
+    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
+    int ret;
+
+    do {
+        const char *name = fdt_get_name(fdt, node, NULL);
+        u32 as, ss;
+
+        if ( depth >= DEVICE_TREE_MAX_DEPTH )
+        {
+            printk("Warning: device tree node `%s' is nested too deep\n",
+                   name);
+            continue;
+        }
+
+        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
+        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
+
+        address_cells[depth] = device_tree_get_u32(fdt, node,
+                                                   "#address-cells", as);
+        size_cells[depth] = device_tree_get_u32(fdt, node,
+                                                "#size-cells", ss);
+
+        /* skip the first node */
+        if ( node != first_node )
+        {
+            ret = func(fdt, node, name, depth, as, ss, data);
+            if ( ret != 0 )
+                return ret;
+        }
+
+        node = fdt_next_node(fdt, node, &depth);
+    } while ( node >= 0 && depth > 0 );
+
+    return 0;
+}
+
+void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+                                uint32_t size_cells, paddr_t *start,
+                                paddr_t *size)
+{
+    uint64_t dt_start, dt_size;
+
+    /*
+     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
+     * Thus, there is an implicit cast from uint64_t to paddr_t.
+     */
+    dt_start = dt_next_cell(address_cells, cell);
+    dt_size = dt_next_cell(size_cells, cell);
+
+    if ( dt_start != (paddr_t)dt_start )
+    {
+        printk("Physical address greater than max width supported\n");
+        WARN();
+    }
+
+    if ( dt_size != (paddr_t)dt_size )
+    {
+        printk("Physical size greater than max width supported\n");
+        WARN();
+    }
+
+    /*
+     * Xen will truncate the address/size if it is greater than the maximum
+     * supported width and it will give an appropriate warning.
+     */
+    *start = dt_start;
+    *size = dt_size;
+}
diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
index bb5f45771e..736f877616 100644
--- a/xen/common/device-tree/bootinfo-fdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -112,39 +112,6 @@ static bool __init device_tree_is_memory_node(const void *fdt, int node,
     return true;
 }
 
-void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-                                uint32_t size_cells, paddr_t *start,
-                                paddr_t *size)
-{
-    uint64_t dt_start, dt_size;
-
-    /*
-     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
-     * Thus, there is an implicit cast from uint64_t to paddr_t.
-     */
-    dt_start = dt_next_cell(address_cells, cell);
-    dt_size = dt_next_cell(size_cells, cell);
-
-    if ( dt_start != (paddr_t)dt_start )
-    {
-        printk("Physical address greater than max width supported\n");
-        WARN();
-    }
-
-    if ( dt_size != (paddr_t)dt_size )
-    {
-        printk("Physical size greater than max width supported\n");
-        WARN();
-    }
-
-    /*
-     * Xen will truncate the address/size if it is greater than the maximum
-     * supported width and it will give an appropriate warning.
-     */
-    *start = dt_start;
-    *size = dt_size;
-}
-
 static int __init device_tree_get_meminfo(const void *fdt, int node,
                                           const char *prop_name,
                                           u32 address_cells, u32 size_cells,
@@ -205,77 +172,6 @@ static int __init device_tree_get_meminfo(const void *fdt, int node,
     return 0;
 }
 
-u32 __init device_tree_get_u32(const void *fdt, int node,
-                               const char *prop_name, u32 dflt)
-{
-    const struct fdt_property *prop;
-
-    prop = fdt_get_property(fdt, node, prop_name, NULL);
-    if ( !prop || prop->len < sizeof(u32) )
-        return dflt;
-
-    return fdt32_to_cpu(*(uint32_t*)prop->data);
-}
-
-/**
- * device_tree_for_each_node - iterate over all device tree sub-nodes
- * @fdt: flat device tree.
- * @node: parent node to start the search from
- * @func: function to call for each sub-node.
- * @data: data to pass to @func.
- *
- * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
- *
- * Returns 0 if all nodes were iterated over successfully.  If @func
- * returns a value different from 0, that value is returned immediately.
- */
-int __init device_tree_for_each_node(const void *fdt, int node,
-                                     device_tree_node_func func,
-                                     void *data)
-{
-    /*
-     * We only care about relative depth increments, assume depth of
-     * node is 0 for simplicity.
-     */
-    int depth = 0;
-    const int first_node = node;
-    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
-    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
-    int ret;
-
-    do {
-        const char *name = fdt_get_name(fdt, node, NULL);
-        u32 as, ss;
-
-        if ( depth >= DEVICE_TREE_MAX_DEPTH )
-        {
-            printk("Warning: device tree node `%s' is nested too deep\n",
-                   name);
-            continue;
-        }
-
-        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
-        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
-
-        address_cells[depth] = device_tree_get_u32(fdt, node,
-                                                   "#address-cells", as);
-        size_cells[depth] = device_tree_get_u32(fdt, node,
-                                                "#size-cells", ss);
-
-        /* skip the first node */
-        if ( node != first_node )
-        {
-            ret = func(fdt, node, name, depth, as, ss, data);
-            if ( ret != 0 )
-                return ret;
-        }
-
-        node = fdt_next_node(fdt, node, &depth);
-    } while ( node >= 0 && depth > 0 );
-
-    return 0;
-}
-
 static int __init process_memory_node(const void *fdt, int node,
                                       const char *name, int depth,
                                       u32 address_cells, u32 size_cells,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:12:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:12:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000856.1381076 (Exim 4.92)
	(envelope-from )
	id 1uKybD-0001bm-1Z; Fri, 30 May 2025 12:12:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000856.1381076; Fri, 30 May 2025 12: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 1uKybC-0001ba-UP; Fri, 30 May 2025 12:12:34 +0000
Received: by outflank-mailman (input) for mailman id 1000856;
 Fri, 30 May 2025 12:12:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKySb-00076q-22
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:03:41 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20631.outbound.protection.outlook.com
 [2a01:111:f403:2415::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1f42e099-3d4e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:03:40 +0200 (CEST)
Received: from CH2PR15CA0016.namprd15.prod.outlook.com (2603:10b6:610:51::26)
 by DS0PR12MB6654.namprd12.prod.outlook.com (2603:10b6:8:d1::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.30; Fri, 30 May
 2025 12:03:34 +0000
Received: from CH2PEPF00000146.namprd02.prod.outlook.com
 (2603:10b6:610:51:cafe::45) by CH2PR15CA0016.outlook.office365.com
 (2603:10b6:610:51::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Fri,
 30 May 2025 12:03:34 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF00000146.mail.protection.outlook.com (10.167.244.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 12:03:34 +0000
Received: from xcbagarciav01.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 07:03: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" 
X-Inumbo-ID: 1f42e099-3d4e-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GgMvWIsYFBxbPAR2AGgEeM6EUFlqhhppH4RvMAPMyXPReX3so3pJRhOoSUzXvlkb7/dabFiTdfKc4F3o2uGsyUGpSK2c9dnrUf8D9BNTM2009yMii8woiPrXoHFHKnDwOQEE3OpRbDoR3zVgVvmkUbTGRmXUy1aqMKDDPLlnN1PM+KQ2EEd3TxHGeajgISkRyu4+b611Zt/3eRdciOZQQGKMcCeYuDqlbv/sIjvDte3my7DzokkVwDmlDbFDMUlhIis45UzCVzp0Egw2MIX/IXJ4u7S/itX29v8nce9CCWUkQ/9REOPHy/rlNqtTY7IOJqmTYWBHRmO42pdIVaO4Jw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=s1Ju23IR+EEatQtsIjEvwx3F7nbCca9u0WIiSRMIQpI=;
 b=iBtoQKLbsckEqlnmSeSENRypM6LzuLjD5ej+3RtzZ2qNPAZaUuf337RN8AmOLW36UDAWsaEvca73tTFep5EA1ApxXLeic6eq2pWQVEISGWCd2cUHGA7CLXqM5stQ+YdIdU4crUsD3P2eOawsdVTI1Fh+8a6oPaEYRyW5SYKMMzs54t+yv5odGXg2YANXaDEMSIPF6qSdCfZEsWLarHCbSorCd6milzLc+/5tUmLuit/0Bv/5IhcihMlAeHKPKMFMq5Lh5Y6vHR+EafciZDWwlpD6KYpyE7cys/wqrPtQ4T61yZ8J3sfXY/xI9VD2HJo31K4HhIrjDQX3/rrnOPptYw==
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=s1Ju23IR+EEatQtsIjEvwx3F7nbCca9u0WIiSRMIQpI=;
 b=iHCDJkqqctFW7iBVAICAqAuXAQaT6q8HtmRjeRohbdlIr9a9nRAt/SUJqaHR9Rrt5dCU/s7+TuuuuR2pBJKS4iqpxmY/i89YqYAHfsoW1egnqc631hxjvuaYlAh0UUnOOFnpVPVN8ASKaacSJLIdpRb0VGPVzdEXECB5O4ziarc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Alejandro Vallejo 
To: 
CC: Alejandro Vallejo , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , "Daniel P.
 Smith" 
Subject: [PATCH 14/19] xen/dt: Rename bootfdt.c -> bootinfo-fdt.c
Date: Fri, 30 May 2025 14:02:22 +0200
Message-ID: <20250530120242.39398-15-agarciav@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530120242.39398-1-agarciav@amd.com>
References: 
 <20250530120242.39398-1-agarciav@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000146:EE_|DS0PR12MB6654:EE_
X-MS-Office365-Filtering-Correlation-Id: 4578e73a-fc87-43d1-e15c-08dd9f720106
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?v7aJvLyyyzoqPZPJyAzmPebRpKbSIo6rYnkmFMJvZODz65JEk0H5K1+Og9/e?=
 =?us-ascii?Q?84gjSoJEHCAHU7TFM/X3tpBps0BZ5p8B8lGGbqbXcNgtUOFZZEddzgsoaTQz?=
 =?us-ascii?Q?SAA+8qdQX4NnqEhSWnCh7kdwT5CvqnU9yCaxzEChyMDIRy8ZvVis3qUpaOYN?=
 =?us-ascii?Q?KEoJwna+5CvE1Yj9zmVNnNVIq36UYIe19hQDYVWwmQosSb0pGp4B22ByceSF?=
 =?us-ascii?Q?6TU9E5Pc+nRzge1rZPcjaOb1Cd8dBi4LROcsj/JSH9oCeCMWdPyHdzJItcms?=
 =?us-ascii?Q?rc4rQXvQ5D323esfeg61maPvsxbhaEX0rfGfRqycIsKirkmrvYXqBoOOyq6y?=
 =?us-ascii?Q?SalvmOj8WsRTWnnur6aKLiUYUnabF+PWTSTQVcJ4p8maBQgJWocT46s2QDhf?=
 =?us-ascii?Q?+AYMbISQw4aSesbvoq1OWAPM1D188/aaONbp9y4Ds794Md/BAmJyCJ9WY69H?=
 =?us-ascii?Q?QQHlvh1JCiOt56spJX5yV00oLNaA4qvvrRRgt4GQaqEXeeDB8nu8LYAN0QOv?=
 =?us-ascii?Q?HZQLgfjhLyldkdzprS6CIxsqqbkh4KGTbSnEnB6gCEKcbB180S8L4eB9kSqW?=
 =?us-ascii?Q?kLA/FJJdVsfBq9uMmJsdINPfXfSm6b1RX6H75uAbX9PfVvzpr61N9FJpXjN9?=
 =?us-ascii?Q?5BGUIceSsvViEciFnvuElF1Jc1p0yvDBWc10G4gqKZy+buxFbXm6pFuRPZNf?=
 =?us-ascii?Q?emHU6Qeq/5ya0ZcqS3rd3cnDrLxJRHkGHFYIdnVc2mil7VvRdCXdXSv5F7b2?=
 =?us-ascii?Q?0B7AQG2pM3ta1vLJQBLYDli/ksX4btxkydAuH2C2Ho4nGEbaVm2S7mr16kG/?=
 =?us-ascii?Q?Pt33OacD3HznRB3Pq4s9j1+Vc3bcqIGK+Z/p0kVSHdcNWPsgNu+Dmal9/6y5?=
 =?us-ascii?Q?03DBTMuUhehx3Bq0tw1OVW0BK71EjDyKKuJArCiecKNPxY2N0bpAyAAwZsLI?=
 =?us-ascii?Q?HKNwMU6F4Vfg1/2SpA5EDyoudPcJZbsRax3Png7TKTwoHuXNpX5LpYHc2EjW?=
 =?us-ascii?Q?vXBsISdB9+HNwiFc4NKiw4v1zlJyCWYuHPoEkxvrglYoGdI49501MQ9lB7AV?=
 =?us-ascii?Q?gURpzoPgewBuviQ6NOGzR+u1rQc5TQZUUoHAaneSJRP/SqKZXSbizdOEno2B?=
 =?us-ascii?Q?lz8/QPQZysDGfuj1BHMxxqjb8uu/HTWZ1TPrqrKrRmRenuMz5mfRLRZDdrSG?=
 =?us-ascii?Q?7C13/dAVlziRfnYLdX7lx2lJUP+Y+NuHSgbKOVULS07DakHxjIuN2WEZgSp4?=
 =?us-ascii?Q?ovqVATzoJvYMgmcHBqKG2fso3b5tCn5qEuraswK3l5UCTobdgxL8JvgpQSYS?=
 =?us-ascii?Q?b/Hf8mLOb7eWUlRUEl9Y9GvIe1WRmZ9u/IFFNM5HNpmkqdcjNAq1ipnzID1k?=
 =?us-ascii?Q?qs5TODONFHHijThEXu49rFMSnKXEFCQ4U1B92RZsF7KOxmjLX12kJRIxHxr2?=
 =?us-ascii?Q?/elGKKWmZSFJ/rvVjSK45IoxdD7HNySruCFWuzYaPBGZsP7eTWCD7ls3saVq?=
 =?us-ascii?Q?y0GO1JYaEBe0D/ODLKDXjpm8IPs9CpBrROYT?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:03:34.8254
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4578e73a-fc87-43d1-e15c-08dd9f720106
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000146.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6654

This file will eventually contain bootfdt helpers that make heavy use of
bootinfo. To simplify git history do the rename here explicitly. A later
patch extracts bootinfo-independent helpers into bootfdt.c.

Doing so here would needlessly pollute the diffs.

Not a functional change.

Signed-off-by: Alejandro Vallejo 
---
 xen/common/device-tree/Makefile                      | 2 +-
 xen/common/device-tree/{bootfdt.c => bootinfo-fdt.c} | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename xen/common/device-tree/{bootfdt.c => bootinfo-fdt.c} (99%)

diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
index 57b9e6ca00..bb6d5ddec5 100644
--- a/xen/common/device-tree/Makefile
+++ b/xen/common/device-tree/Makefile
@@ -1,4 +1,4 @@
-obj-y += bootfdt.init.o
+obj-y += bootinfo-fdt.init.o
 obj-y += bootinfo.init.o
 obj-y += device-tree.o
 obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootinfo-fdt.c
similarity index 99%
rename from xen/common/device-tree/bootfdt.c
rename to xen/common/device-tree/bootinfo-fdt.c
index fb4ac06390..bb5f45771e 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 /*
- * Early Device Tree
+ * Early Device Tree with bootinfo hooks
  *
  * Copyright (C) 2012-2014 Citrix Systems, Inc.
  */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 12:30:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:30:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000904.1381085 (Exim 4.92)
	(envelope-from )
	id 1uKys3-0004x3-Ez; Fri, 30 May 2025 12:29:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000904.1381085; Fri, 30 May 2025 12: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 1uKys3-0004ww-CF; Fri, 30 May 2025 12:29:59 +0000
Received: by outflank-mailman (input) for mailman id 1000904;
 Fri, 30 May 2025 12:29:58 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKys1-0004wq-Tg
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:29:57 +0000
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [2a00:1450:4864:20::334])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c8fd4d4d-3d51-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 14:29:52 +0200 (CEST)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-441d437cfaaso13123875e9.1
 for ; Fri, 30 May 2025 05:29:52 -0700 (PDT)
Received: from [10.81.43.171] ([46.149.103.12])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d7fa27b4sm16904945e9.15.2025.05.30.05.29.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 30 May 2025 05:29: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" 
X-Inumbo-ID: c8fd4d4d-3d51-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748608192; x=1749212992; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=KsKJzvhM//UflZCltqZ6Kjnw2ewyvR2CQ3NOuVDUC0o=;
        b=ISIxKsRtnyYqhUTCz3Am0wT6AksA4bBc85kZ27RDSetOHWcmtl+xDQzuLee/Ei7/SJ
         sh9zlRNaTc3DMYLwkZF1bWC17MudWXFs3yO6yF1iURxj3XosvEU2alL7q16ysdp+umyu
         xwYTIG0ZOGJ9L5XNWwtRz1IqZub+LbPz8oCS0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748608192; x=1749212992;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KsKJzvhM//UflZCltqZ6Kjnw2ewyvR2CQ3NOuVDUC0o=;
        b=BobocoMQszegHMBrokiGHnf+l8FtGXnDeR3QBvCY7mJnprCuivWoVN8hivczCcw5bz
         QonrWuQui83NJMiEvfxkmdhYXahNGGCCRf2mANIYrKqwgbILJ0FWxgvsBv0AOtdwG721
         ITzFHli589DawpHWbhYp3TKWIZTXTbQOad8GrSuOy13tHx3WB4JUdD72ade0PK5jBjJV
         b2PfrzcLm8GlG0rFiU21FQvrMnuZOA3e+u2/dUAG8hmLyNZHytQK7W+WG8s/2iba+f5s
         p0zt/AGvf5W+J5MQ9SN7lITu4hoRo+xkpA6KNESLJ6lMp2pVIV+3avRI3EZZ+HTqBbKI
         37bw==
X-Gm-Message-State: AOJu0YwU8WbMcPdAvh0fsSS/yAdIzDUPGO+gFxe9rPiZMTnPLL5XLrqm
	RIZ/QN4bfPJbOwBJlqlFJGZkb/0rj/prYeFKM3Vkn0/clveWE3Pll6lUoAyqmYc1HBWsaUj1NM3
	gGtXG
X-Gm-Gg: ASbGnctIEqt64rKdJQ2q9gCihnLQ6aceeecaIV17AuwQxqvJLLG/Rk7JSwbcPUJ5SXI
	GbfJ89DQ/6xmlOM+TttAHTRUb7gWeFBnC0ZKV3PzpDPVNqNLteAuejaeAiiGXPprVJfWALYzKI7
	LfLiGKv/4UFTJoDs1qddpMW7emOu6K23PdtHQTgiMPeGuczpBx1hA7q26MkFDlT0C47pqPw3cGX
	0Q+DPk8RwkQ2vHZRNpgkNqorjoWfhE9N/5v2MsKVxzIRsOlKg/IfXxtgB0BtPfoyPME8VjaB+2T
	/ZSJzGjHng/zeBvlb76p6pD0iKrUTDG4+yNLIRMTs7B5VH5YLtIkmcxTgr6wT7M3F05PGcmA
X-Google-Smtp-Source: AGHT+IHVIrKusi8+f68N/v9+R2bB/ECAMIbGptcYrYY5QLoFcGgTiLHhbIuAfOz9Ql9nN7s6aQz2aw==
X-Received: by 2002:a05:600c:5250:b0:43c:fd27:a216 with SMTP id 5b1f17b1804b1-450d8875db2mr16855845e9.23.1748608191683;
        Fri, 30 May 2025 05:29:51 -0700 (PDT)
Message-ID: <2912f117-a898-41dd-9e1f-2723728a2237@citrix.com>
Date: Fri, 30 May 2025 13:29:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools/tests: Add install target for vPCI
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: Xen-devel ,
 Anthony PERARD 
References: <20250530104307.2550886-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

On 30/05/2025 11:57 am, Roger Pau Monné wrote:
> On Fri, May 30, 2025 at 11:43:07AM +0100, Andrew Cooper wrote:
>> This lets it run automagically in CI.
>>
>> Signed-off-by: Andrew Cooper 
> Acked-by: Roger Pau Monné 
>
> I had sent something similar long time ago:
>
> https://lore.kernel.org/xen-devel/20230313121226.86557-1-roger.pau@citrix.com/
>
> But got no reviews.
>
> Thanks, Roger.

Sorry, that fell through the cracks too.

What I'll do if you're happy is submit it as authored by you but with
this content (seeing as it's the one I've tested in the past week), and
A-by me.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 30 12:41:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 12:41:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000921.1381095 (Exim 4.92)
	(envelope-from )
	id 1uKz33-0000rs-H0; Fri, 30 May 2025 12:41:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000921.1381095; Fri, 30 May 2025 12:41:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKz33-0000rl-EU; Fri, 30 May 2025 12:41:21 +0000
Received: by outflank-mailman (input) for mailman id 1000921;
 Fri, 30 May 2025 12:41:20 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKz32-0000rf-MI
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 12:41:20 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20630.outbound.protection.outlook.com
 [2a01:111:f403:2009::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5d14176c-3d53-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 14:41:11 +0200 (CEST)
Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22)
 by CY8PR12MB7194.namprd12.prod.outlook.com (2603:10b6:930:5a::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.24; Fri, 30 May
 2025 12:41:06 +0000
Received: from BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13]) by BN9PR12MB5273.namprd12.prod.outlook.com
 ([fe80::cf66:58ab:47be:4b13%5]) with mapi id 15.20.8769.029; Fri, 30 May 2025
 12:41: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" 
X-Inumbo-ID: 5d14176c-3d53-11f0-a2ff-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=f4vyaBGoydFjwXvbyt1MU3L9/EiNk3CRuvudvvew2PZWubMjyoCeykiC7g6lEXKH7TZYEKWaft+eNq7QJ61FodVpf09BBuBDlSor1q1kYR/focL+SjEZVQs7mnzbOhNVeltmnVwatSZMuEb6DWiTah6T5CP41gob9QssFqpfCu4lRLl6FtfCfWSXUzQ2gfIWIJWomApjt1gvliI2IPLCfNeeiV5s5AttHRBQqnOos1Rcckittvg+E81zV323l+wLSvgWGh+MkxG4affAwOPLR1YEu+ejnUQbbw2GF8ud0ojgGH6FQ4ZYUyj2f6XrMCx0aEhYEg0wI/v+q8EWFYAv1A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JOjWkpKyeQG28wm9hNPROs5/ISGe6hlQtZIZIb3e0vA=;
 b=QUMYt7i2lv8glcNrOC4Pv+osOSgF/yZpmuNao3d9q9IJlV+0/vpAO7E5c7hiCDxmEoIP33jcfltG1Z5rSYmWiclf2LrHDUkekKZ8O6erKkB5IKQS2HU1v7vka9Z/Pq+wn0jl3VEFV2yGamQ2CjE3m1Uq/InoozF6fUk6wZDqjLaNVuQ0AatF04BibDYEPwESVIaY3THYl9+c2Ls2kdJ1c1KWmol6aWTx/WPlAKfv3dh4zZgndkx1Z8svFh7kkdiHVJ0wQpSKWTYtdK3kS2z6dT2AsHX4+R3eaw8x12MPAfK212pMOY1Oxvc4N7aLBkKPkwa93qTnLGyZXA8TIr4ykg==
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=JOjWkpKyeQG28wm9hNPROs5/ISGe6hlQtZIZIb3e0vA=;
 b=x7WayGYOcB8r1HRlD3DcMmGGQFXZG4aXKY7mhEE0Phq/XwluEmiT5TxwJqftGRSy7+gj2AG94BnA8f7qC5dw4edAt9yHUTvj58laDAgdPbCC8IOTNIU9q8/sJ29C49NqSW9b1BivctXCHExyHyTgr+pm4eFcmxAWLIitMsChoRA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <20505776-da44-4fab-bcb5-7114157d0bb0@amd.com>
Date: Fri, 30 May 2025 14:41:03 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 01/19] licence: Add missing SPDX line to bootfdt.h
To: Alejandro Vallejo , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 "Daniel P. Smith" 
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-2-agarciav@amd.com>
From: "Orzel, Michal" 
Content-Language: en-US
In-Reply-To: <20250530120242.39398-2-agarciav@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: FR4P281CA0187.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:ca::9) To BN9PR12MB5273.namprd12.prod.outlook.com
 (2603:10b6:408:11e::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN9PR12MB5273:EE_|CY8PR12MB7194:EE_
X-MS-Office365-Filtering-Correlation-Id: 2f8946a3-1070-4f60-8675-08dd9f773f11
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?YWNnOVJTa1RQd09TZ0QyRDRGemV3bkVXM2ZYbTZjM2Z6QWF3Uy9VTWhsTmFE?=
 =?utf-8?B?V3JqR25QZ0xHSGM1a0xZZWd3bVZOQXl3bENxRTZVbm5rUVlFVlVBaXNhem1i?=
 =?utf-8?B?N3BOOVdUQXdLVzgzYkE0S1BOTXNqVlJGSEFybVpWS1ErNk9PM21mN3FOVlZs?=
 =?utf-8?B?MVcxZFFJb09hbFhyVEFrdE5oNVJJMmcrMno1VzdMbC9sZS9VeWp0UEpDOUt2?=
 =?utf-8?B?WVhuOHE5TGpPWHlhZmQ5Yzg5d25sbmUxUU5Udk1IbGdoSjkrbmhGODAzakt0?=
 =?utf-8?B?L29pcGpLOG04Z01oZnRUc1RMU0RyRDUyL3VkSWg2NnVWMUpycCtXV052Y0da?=
 =?utf-8?B?bkkyWlcwT2RzWVR6YWdYZGdLQTVhSnozbUxLc0c2MWg1UDVoaXZnb0lPblJQ?=
 =?utf-8?B?ZHRuM1hidDkvWXZ0OEV6Z2FyL24vaStxenM3RnZnMks5NG5Ya3dFQWZ3aHBV?=
 =?utf-8?B?MGgxZWprTTQydFd1S1FEQXorSzdiOFo3VHIzMk9pSWlBS1ZXMzA3K0o3U0I3?=
 =?utf-8?B?QWJNTy9XdGJhbk03c1JYK2F6SHI5K2xERzJLaWlLcUl1MWNKclhpZGE5aXli?=
 =?utf-8?B?Z24zelE2YWdad1FIVTh2eEdsc0FtS0ZIZ1VqY3R4Z1QzZmJFT0pQTWVrd1V0?=
 =?utf-8?B?dFc0S2FweWNjODhYYjMwSStIS2lJMmVTQ1U4dnJzZFgreGtPM3ZEZ2plcmEw?=
 =?utf-8?B?M1cwalpzU1IzdlFweW04RGZpZCtGTjdkS0V3VXBZdFhZZ2ZhVXRKMy95UTd2?=
 =?utf-8?B?TmtsbEdILzVjMTNoM29HWEhZeWJ3Zk1lalJuRFpaeDNjVlp0blkrSWxoYUh0?=
 =?utf-8?B?Q3grQkJSU0JCcjJqd1U1emdLOFRGazY0Vzg4bnJtb2xoSkFIMG1KR2N1RldG?=
 =?utf-8?B?L3h2aHBleFBRYU9OT3ZKNUxsanZ0cVkzRVYxVlBLLzVla0xFWWxNQUFTbjhu?=
 =?utf-8?B?WmFrcUE1ODRWdmdMcGhBazRycGZ4eWNaY3U2SksyejZmdktvcC9xZzcxWkw1?=
 =?utf-8?B?REVXNzB1ZXlZUGV1NmRCSC9kdllzbWFwREhkaExWaW16TXNWcHVpclJzMjR5?=
 =?utf-8?B?TXZvNXlUOWFiUjZURjFjZFJzdERNWEJPZE9xbXFNYWhQVlVUTVdXaWlZVDAr?=
 =?utf-8?B?a0Fvc2l2ZDhVUFl0Z1ZrZTVGK1BZblp2aUNDY2h2REhBZ05ZQXNLWlFGcnJQ?=
 =?utf-8?B?QzVBbnNGM2lib2NzM05QQVZscWJubVpiUTd5Q3BTazR3RU9IT0N3MHBoRVNG?=
 =?utf-8?B?eVFLaldzYXN0UTVEMUsvOUJvdWNINnpQZW42azdIWG1oazhZMDdtK2FyVW83?=
 =?utf-8?B?bVRtaEoyZEswU1podG9nU2licWFudnpJVjRMaXg4ME9JaUplQU11dmR3ZTNP?=
 =?utf-8?B?QkVKeEhFVWtFSitPVWdRU2ZJNEJVNktLK0h6TklvNVNvQmx0Q09KYkRwWnF3?=
 =?utf-8?B?KzhmS1c2QXpGZ3c0clRtRUYvczF6aTZtMVp4VEZxV1VyN05FOFVkOHdibys1?=
 =?utf-8?B?d3h5MERiWUV3MHM0VWQ4WHVWcjg2aExBSHdPVkFrcVZUUEFxektZTnhoSjVM?=
 =?utf-8?B?Vm03RERoNVBkVDFXRHhCdHNRVk9wTElsRGROQ3dBdFRWMjZ1SHdMVllGT00y?=
 =?utf-8?B?bGMzSS9RazlxODJwd2ZSakV4MXlxNTBnZFF1WnF0UTJrSmw2Qm91c2s4bVZK?=
 =?utf-8?B?MitQN21oVGt6OHloZTBxa3pnV3lQb252UUw0NS8rc0tXL0VhY1hYK0dUcFRt?=
 =?utf-8?B?R2ZhYjFsa2p5Y2JST0U2K21vRDYxOGRhaWN2OVNnaW5LMzhVRHluOWZWd1ZO?=
 =?utf-8?B?N3ZleUVJWXB6b0FJWVVJcGtIWmtzSXIrWWlSbVI3TmVVY0M5RjFSY3cwSm16?=
 =?utf-8?B?QTBhZVpkVmRleEJTTlB4MUVKZUR3N3Z0ZGphaHlQQXgweXlkanltekJGUytD?=
 =?utf-8?Q?Xgp1YF0q0oM=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN9PR12MB5273.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?RHhGVk9MK2MzZWdVRmRoWTU3TmFqVXkvUlRCSjRER3dodHNwbEVva1h3UG5i?=
 =?utf-8?B?WnpPUFEvT2dDOWFQQWNZNDBTWEN3OWFUZVNSemdRTkh4ek5VNFFuQ2VSQXJ2?=
 =?utf-8?B?ZEJYL0JDOVBXSVNnWml3MEk4L2xQMEFKSlZqUVlnMElQKzZXMTNpY2JWODhR?=
 =?utf-8?B?RG9iNi9tQmhzVmEreWRFbGdqTEs3SzNjY2lmSG5hTmlYU2VDR0JjYnF3MXBC?=
 =?utf-8?B?Zis0Z2MxM1dGQThRWUdld1ArK2lFSVZUK21RQlVBcGoxRWZDT2psNm43ellm?=
 =?utf-8?B?cE9DOGJRYnpnWUVYMkN1MmExMDdhSmpJdlVWcVZqVjBjcnQ0aW9ESEFjS2VS?=
 =?utf-8?B?bU5MRXJYeTZQTFQwSnRWY2Y3dk1VRDJUU2l6MHpPMStXTVZUWDU2MVJmaUFH?=
 =?utf-8?B?S21xd3IrNnpyZXFOVXNpK0w1Q2NRcmp6MFhwSGpaOUw4bGxidnVleW03VmFw?=
 =?utf-8?B?Yk9qS0pYcncvdHVUWGJ1YUFsZWtiZyt1OHpkZ2NyQ2Fva3kzc2EzbmhvYmRN?=
 =?utf-8?B?d0pIbXhCQXhSb08wUGVmK0daaml5UzRlc3hScFFVUnhQL242ZjA5dk81T1Vn?=
 =?utf-8?B?dnJVZWJXck5oWjF4RWx1QVpZSitZdHJwTld5MjNMMzFYN0I5aVNuZjVWazJX?=
 =?utf-8?B?ejBhVytZUTBOWVVnQ1ZMUVlwa0xzMHBONVJZVTc4U3FOeVdyK2hRaVRsajBl?=
 =?utf-8?B?MERyOWxXbEczV0k5NzNrL3VWcE55WW00OTc0bmdRT2dzWWluVmF6bU9QTzlz?=
 =?utf-8?B?TVp6OXZkWHpYUDNaK1l1ZUY4WjZoMEtVNzhLYnEyeVJVekQzeVlGbkV4NmZY?=
 =?utf-8?B?YzI4SVhPdHdwUGlrUTQwT3hyRjk4M29pcjRxWTg4cWQ0YlFEL25haUVjN3pt?=
 =?utf-8?B?Tkl3MDlQWkozR0cwM0l3VmlYVFhtRjBWcGE1bUtsOFgwbGFNTWR1dGdCZG02?=
 =?utf-8?B?N1NBakNkc2d5Z0s3YWpIbmNFVXpBM3JUdjJCaWtZcmlzWWowNEhZR1hITjVZ?=
 =?utf-8?B?bWNHaVhUT1lEUWJJTEQweVlGZ3l0anAyUXFWMno0aklIQ1Y4Wmd3Rnl1Ungr?=
 =?utf-8?B?U2F6T0wwdHN5QXRaNEgxRGFkM2xFUGdjTnRoeDNOaUNEb01XcTlyaXdBSnlY?=
 =?utf-8?B?bmhFYVYxWWVGSGZEQXA0WVNvaDd5MGdKdDU3T0FlWDZZZ1BqNm4vUnNFWU1x?=
 =?utf-8?B?dk45N0xKOFVLREVyWGZtc01MR0ZReW10VnpHMEdXM3Z2bEZQWC9IbmlhN3E4?=
 =?utf-8?B?RWV4a2JZdmwrSTBrYTlRSzVZcjlkS2Fwd2tXcjBycG15RnF2UFdvVm1XR2xC?=
 =?utf-8?B?a2RoZjFOSm9qeEJLTWZrWGdBS3h2K2VvdjlVZmhVaXJjdUtmQk1KU3lNZnFk?=
 =?utf-8?B?djFhSERDUEIvMHNKTDVKNUU2RHJvbW40VHM3SEFUdk9XTkxWWEt2ZVpHdmhQ?=
 =?utf-8?B?UEcyY0xTV0RaVFJoWTVycEtPVzdBRFQxS1cva1RjV24yekFsYkNncTErVndU?=
 =?utf-8?B?WEN6NFFVRjRybHpNYXRkRWJSdE1iRU96YS9aWkRINnhrdkpsR210SEVlbWFO?=
 =?utf-8?B?YmE5azlna09BOXFta2hxSlZoSVB3U3VOZUFWbWxLTFkxUHlWN2JkQWRrSGpL?=
 =?utf-8?B?UGJFa1B4eXZocXBwc1Z1b2U3SjJSbDNGcXpLWUkvZ3JDOVVMOEFCOVU3R2U3?=
 =?utf-8?B?VXlNNnUvbXJBVGtsS21DQlZuYXkxUVBOeXhrcXNhd3hVMytFUDJScEd4VHJG?=
 =?utf-8?B?bGVEeXBBVEUxY0hsSGFTODMxanprYkFZSUlEb0NxV09yTVNTK3EyRTRTZUs3?=
 =?utf-8?B?c09sZld5WEVsTEZ0ZUFjR2F6ak5ubkhna3diLzI0WGRpTTBIQWc1MXJkT3A1?=
 =?utf-8?B?T3AvcmlySEFYOUpSK1FsdGdqMWZMMGhxZ3cvdzFiWGRSQ2RVMlI1TUFFVUF2?=
 =?utf-8?B?dFVlWU9jcVpNZ2taQ0R6cEp2UUc5NlhRcjVsTTFWU2FQNTI1eHRZOUFTSzlo?=
 =?utf-8?B?aHl5TTlFL1gvU0J4UEhkSUp1V2Q5aHQ3WnpWZEJOdHl6U0w3K0tJWE15c0Ns?=
 =?utf-8?B?YldONXMzdE5PVlRURzU1aG85eG9JWGhGTldOZ0p1b3RHdlJxTWs4SlJxMC9D?=
 =?utf-8?Q?oa3M=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2f8946a3-1070-4f60-8675-08dd9f773f11
X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 12:41:06.7054
 (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: H7T7yWUt4K9g7rbFyVnE13LzG/WLeDjh8Hdc6nkg6CXh2WK408i81IBaLpgY0Q4g
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7194



On 30/05/2025 14:02, Alejandro Vallejo wrote:
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/include/xen/bootfdt.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 80a90e53c0..847f019559 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -1,3 +1,4 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
>  #ifndef XEN_BOOTFDT_H
>  #define XEN_BOOTFDT_H
>  

Acked-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:18:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:18:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000931.1381126 (Exim 4.92)
	(envelope-from )
	id 1uKzd8-0000Kn-Hw; Fri, 30 May 2025 13:18:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000931.1381126; Fri, 30 May 2025 13:18: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 1uKzd8-0000Ke-Ej; Fri, 30 May 2025 13:18:38 +0000
Received: by outflank-mailman (input) for mailman id 1000931;
 Fri, 30 May 2025 13:18:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzd7-0008Jy-7W
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:18:37 +0000
Received: from 10.mo582.mail-out.ovh.net (10.mo582.mail-out.ovh.net
 [87.98.157.236]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 97d11f80-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:18:36 +0200 (CEST)
Received: from director7.ghost.mail-out.ovh.net (unknown [10.109.148.22])
 by mo582.mail-out.ovh.net (Postfix) with ESMTP id 4b83hr09ljz1gVw
 for ; Fri, 30 May 2025 13:18:35 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-595tn (unknown [10.110.101.93])
 by director7.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 1A05CC01C6;
 Fri, 30 May 2025 13:18:34 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.106])
 by ghost-submission-5b5ff79f4f-595tn with ESMTPSA
 id 1uY5MCqwOWhrxwAAeVbzSg
 (envelope-from ); Fri, 30 May 2025 13:18: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" 
X-Inumbo-ID: 97d11f80-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-106R0066e9729c4-54b1-40e5-9241-747dee88eacc,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 02/22] include/xen/slr-table.h: Secure Launch Resource Table definitions
Date: Fri, 30 May 2025 16:17:44 +0300
Message-ID: <49517f41e112720bdd2b76e8eb3d9b1064671f60.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12694239977603183772
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepjefgfeelteetueelfefgffehtdelkeegtddvtedukeduleelgfekgfetudegudelnecuffhomhgrihhnpehtrhgvnhgthhgsohhothdrohhrghenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekgedrvddvuddpfeejrdehledrudegvddruddtieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkedvmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=Jmq1hGKvknlCNJrEv6nB4vNlHz9UuOh2SDBrEluwy9Y=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611116; v=1;
 b=e26ZF95PgWF4+7aMi7/mBgm4xjARf2OhwuiuZQCep1WSMldNSh+xSIBqxfk2vdCHeCwQdV5P
 q/pLTgmRuG2BkTjF1ulrtzKDc8yL753BSY9n++z3MPzUUo5wgZSy4D1ZiwcXl8ivnEQywFLZ3Un
 Tbe4rzfuefjPyu8B/7PeyF1RTpteEi0Rwiax39JsgzLo+3ENTXP6C4JSB//k6TNrXB4AX4eCotp
 6Jv3fBZSRvOAegMNEMKEYuI/Xqad+iv6IMK3NvMuEeCQIb1PIvhIHyU709eRa8NBIqeL1t+pxno
 4G4jOK3bN4pe145Y4XAVyag2V/ngZCyyffehrMU68Ctpw==

The file provides constants, structures and several helper functions for
parsing SLRT.

The data described by the structures is passed to Xen by a bootloader
which initiated DRTM.

Signed-off-by: Daniel P. Smith 
Signed-off-by: Ross Philipson 
Signed-off-by: Sergii Dmytruk 
---
 xen/include/xen/slr-table.h | 276 ++++++++++++++++++++++++++++++++++++
 1 file changed, 276 insertions(+)
 create mode 100644 xen/include/xen/slr-table.h

diff --git a/xen/include/xen/slr-table.h b/xen/include/xen/slr-table.h
new file mode 100644
index 0000000000..fb36d06fa8
--- /dev/null
+++ b/xen/include/xen/slr-table.h
@@ -0,0 +1,276 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+/*
+ *  Copyright (c) 2025 Apertus Solutions, LLC
+ *  Copyright (c) 2025 Oracle and/or its affiliates.
+ *  Copyright (c) 2025 3mdeb Sp. z o.o
+ *
+ *  Secure Launch Resource Table definitions.  This table is passed to Xen by
+ *  a bootloader and contains information about pre-DRTM state necessary to
+ *  restore hardware configuration, where to find TPM event log, how to call
+ *  back into the bootloader (for EFI case) and what needs to be measured by
+ *  Xen.  In other words, this is similar to MBI in Multiboot Specification.
+ *
+ *  Specification:
+ *    https://trenchboot.org/specifications/Secure_Launch/
+ */
+
+#ifndef XEN_SLR_TABLE_H
+#define XEN_SLR_TABLE_H
+
+#include 
+
+#define UEFI_SLR_TABLE_GUID \
+    { 0x877a9b2aU, 0x0385, 0x45d1, { 0xa0, 0x34, 0x9d, 0xac, 0x9c, 0x9e, 0x56, 0x5f } }
+
+/* SLR table header values */
+#define SLR_TABLE_MAGIC         0x4452544d
+#define SLR_TABLE_REVISION      1
+
+/* Current revisions for the policy and UEFI config */
+#define SLR_POLICY_REVISION         1
+#define SLR_UEFI_CONFIG_REVISION    1
+
+/* SLR defined architectures */
+#define SLR_INTEL_TXT   1
+#define SLR_AMD_SKINIT  2
+
+/* SLR defined bootloaders */
+#define SLR_BOOTLOADER_INVALID  0
+#define SLR_BOOTLOADER_GRUB     1
+
+/* Log formats */
+#define SLR_DRTM_TPM12_LOG      1
+#define SLR_DRTM_TPM20_LOG      2
+
+/* DRTM Policy Entry Flags */
+#define SLR_POLICY_FLAG_MEASURED    0x1
+#define SLR_POLICY_IMPLICIT_SIZE    0x2
+
+/* Array Lengths */
+#define TPM_EVENT_INFO_LENGTH       32
+#define TXT_VARIABLE_MTRRS_LENGTH   32
+
+/* Tags */
+#define SLR_ENTRY_INVALID       0x0000
+#define SLR_ENTRY_DL_INFO       0x0001
+#define SLR_ENTRY_LOG_INFO      0x0002
+#define SLR_ENTRY_DRTM_POLICY   0x0003
+#define SLR_ENTRY_INTEL_INFO    0x0004
+#define SLR_ENTRY_AMD_INFO      0x0005
+#define SLR_ENTRY_ARM_INFO      0x0006
+#define SLR_ENTRY_UEFI_INFO     0x0007
+#define SLR_ENTRY_UEFI_CONFIG   0x0008
+#define SLR_ENTRY_END           0xffff
+
+/* Entity Types */
+#define SLR_ET_UNSPECIFIED        0x0000
+#define SLR_ET_SLRT               0x0001
+#define SLR_ET_BOOT_PARAMS        0x0002
+#define SLR_ET_SETUP_DATA         0x0003
+#define SLR_ET_CMDLINE            0x0004
+#define SLR_ET_UEFI_MEMMAP        0x0005
+#define SLR_ET_RAMDISK            0x0006
+#define SLR_ET_MULTIBOOT2_INFO    0x0007
+#define SLR_ET_MULTIBOOT2_MODULE  0x0008
+#define SLR_ET_TXT_OS2MLE         0x0010
+#define SLR_ET_UNUSED             0xffff
+
+/*
+ * Primary SLR Table Header
+ */
+struct slr_table
+{
+    uint32_t magic;
+    uint16_t revision;
+    uint16_t architecture;
+    uint32_t size;
+    uint32_t max_size;
+    /* entries[] */
+} __packed;
+
+/*
+ * Common SLRT Table Header
+ */
+struct slr_entry_hdr
+{
+    uint32_t tag;
+    uint32_t size;
+} __packed;
+
+/*
+ * Boot loader context
+ */
+struct slr_bl_context
+{
+    uint16_t bootloader;
+    uint16_t reserved[3];
+    uint64_t context;
+} __packed;
+
+/*
+ * Prototype of a function pointed to by slr_entry_dl_info::dl_handler.
+ */
+typedef void (*dl_handler_func)(struct slr_bl_context *bl_context);
+
+/*
+ * DRTM Dynamic Launch Configuration
+ */
+struct slr_entry_dl_info
+{
+    struct slr_entry_hdr hdr;
+    uint64_t dce_size;
+    uint64_t dce_base;
+    uint64_t dlme_size;
+    uint64_t dlme_base;
+    uint64_t dlme_entry;
+    struct slr_bl_context bl_context;
+    uint64_t dl_handler;
+} __packed;
+
+/*
+ * TPM Log Information
+ */
+struct slr_entry_log_info
+{
+    struct slr_entry_hdr hdr;
+    uint16_t format;
+    uint16_t reserved;
+    uint32_t size;
+    uint64_t addr;
+} __packed;
+
+/*
+ * DRTM Measurement Entry
+ */
+struct slr_policy_entry
+{
+    uint16_t pcr;
+    uint16_t entity_type;
+    uint16_t flags;
+    uint16_t reserved;
+    uint64_t size;
+    uint64_t entity;
+    char evt_info[TPM_EVENT_INFO_LENGTH];
+} __packed;
+
+/*
+ * DRTM Measurement Policy
+ */
+struct slr_entry_policy
+{
+    struct slr_entry_hdr hdr;
+    uint16_t reserved[2];
+    uint16_t revision;
+    uint16_t nr_entries;
+    struct slr_policy_entry policy_entries[];
+} __packed;
+
+/*
+ * Secure Launch defined MTRR saving structures
+ */
+struct slr_txt_mtrr_pair
+{
+    uint64_t mtrr_physbase;
+    uint64_t mtrr_physmask;
+} __packed;
+
+struct slr_txt_mtrr_state
+{
+    uint64_t default_mem_type;
+    uint64_t mtrr_vcnt;
+    struct slr_txt_mtrr_pair mtrr_pair[TXT_VARIABLE_MTRRS_LENGTH];
+} __packed;
+
+/*
+ * Intel TXT Info table
+ */
+struct slr_entry_intel_info
+{
+    struct slr_entry_hdr hdr;
+    uint64_t boot_params_base;
+    uint64_t txt_heap;
+    uint64_t saved_misc_enable_msr;
+    struct slr_txt_mtrr_state saved_bsp_mtrrs;
+} __packed;
+
+/*
+ * AMD SKINIT Info table
+ */
+struct slr_entry_amd_info
+{
+    struct slr_entry_hdr hdr;
+    uint64_t next;
+    uint32_t type;
+    uint32_t len;
+    uint64_t slrt_size;
+    uint64_t slrt_base;
+    uint64_t boot_params_base;
+    uint16_t psp_version;
+    uint16_t reserved[3];
+} __packed;
+
+/*
+ * UEFI config measurement entry
+ */
+struct slr_uefi_cfg_entry
+{
+    uint16_t pcr;
+    uint16_t reserved;
+    uint32_t size;
+    uint64_t cfg; /* address or value */
+    char evt_info[TPM_EVENT_INFO_LENGTH];
+} __packed;
+
+struct slr_entry_uefi_config
+{
+    struct slr_entry_hdr hdr;
+    uint16_t reserved[2];
+    uint16_t revision;
+    uint16_t nr_entries;
+    struct slr_uefi_cfg_entry uefi_cfg_entries[];
+} __packed;
+
+static inline const void *
+slr_end_of_entries(const struct slr_table *table)
+{
+    return (const void *)table + table->size;
+}
+
+static inline const struct slr_entry_hdr *
+slr_next_entry(const struct slr_table *table, const struct slr_entry_hdr *curr)
+{
+    const struct slr_entry_hdr *next = (void *)curr + curr->size;
+
+    if ( (void *)next + sizeof(*next) > slr_end_of_entries(table) )
+        return NULL;
+    if ( next->tag == SLR_ENTRY_END )
+        return NULL;
+    if ( (void *)next + next->size > slr_end_of_entries(table) )
+        return NULL;
+
+    return next;
+}
+
+static inline const struct slr_entry_hdr *
+slr_next_entry_by_tag(const struct slr_table *table,
+                      const struct slr_entry_hdr *entry,
+                      uint16_t tag)
+{
+    if ( !entry ) /* Start from the beginning */
+        entry = (void *)table + sizeof(*table);
+
+    for ( ; ; )
+    {
+        if ( entry->tag == tag )
+            return entry;
+
+        entry = slr_next_entry(table, entry);
+        if ( !entry )
+            return NULL;
+    }
+
+    return NULL;
+}
+
+#endif /* XEN_SLR_TABLE_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:18:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:18:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000932.1381135 (Exim 4.92)
	(envelope-from )
	id 1uKzdA-0000a3-ON; Fri, 30 May 2025 13:18:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000932.1381135; Fri, 30 May 2025 13:18: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 1uKzdA-0000Zw-Lg; Fri, 30 May 2025 13:18:40 +0000
Received: by outflank-mailman (input) for mailman id 1000932;
 Fri, 30 May 2025 13:18:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdA-0008Jy-3F
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:18:40 +0000
Received: from 10.mo575.mail-out.ovh.net (10.mo575.mail-out.ovh.net
 [46.105.79.203]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 998debce-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:18:39 +0200 (CEST)
Received: from director11.ghost.mail-out.ovh.net (unknown [10.109.148.22])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4b83ht5zchz289h
 for ; Fri, 30 May 2025 13:18:38 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-m2hqt (unknown [10.110.118.244])
 by director11.ghost.mail-out.ovh.net (Postfix) with ESMTPS id A20CDC61DA;
 Fri, 30 May 2025 13:18:37 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.101])
 by ghost-submission-5b5ff79f4f-m2hqt with ESMTPSA
 id 8EEPHi2wOWjlBgAAzgKK1w
 (envelope-from ); Fri, 30 May 2025 13:18: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" 
X-Inumbo-ID: 998debce-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-101G00483e32f39-353f-424e-a8fc-ffe6f4f47263,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
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 ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 03/22] x86/boot: add MLE header and Secure Launch entry point
Date: Fri, 30 May 2025 16:17:45 +0300
Message-ID: <916c87847457552583f1defb1aced37ea3ff58df.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12695084403030340764
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepkedugeefudeigeduieejleelkeefvddvhfehheevhfdukeejieefgedtudevhedtnecuffhomhgrihhnpehhvggrugdrshgsnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrddutddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheejhegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=REsQ4rGltjGtDGspVocQv2/Sf60+XBS+U8hI4FuZ0Cs=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611118; v=1;
 b=AJwlGqENjuhLsTTl6afFnjmyNEklFCTYMEsMItvkax4JAE++9kXAudWVUE0Lebmf1/Q1s0rS
 WheNkVDW2KggJSxITVxdTJWi2n27BBlyEQSqAhaoUu6t/iplLrw/lY3nhRpwBroHZ11kqBDa5IE
 lyNLfF4RMGmsosWhP2nkjIVmjxJAd8LmlYdn8M8HAz2zAXqDS6IHLBOJjiSkamNhjC09ZTp6tD0
 nm0Qt1yJ4o/tQMf9uPyhH3jBFlVivGM2j5EEvkQnRnjrEQILOxOaoaobsGn/kJTco71kouDgWaB
 zSJsx4SufdBqMVBfzVUn0miVYgdF5G2S2LPDGSWYFf2pw==

From: Kacper Stojek 

Signed-off-by: Kacper Stojek 
Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 docs/hypervisor-guide/x86/how-xen-boots.rst |  5 ++
 xen/arch/x86/boot/head.S                    | 53 +++++++++++++++++++++
 2 files changed, 58 insertions(+)

diff --git a/docs/hypervisor-guide/x86/how-xen-boots.rst b/docs/hypervisor-guide/x86/how-xen-boots.rst
index 8b3229005c..050fe9c61f 100644
--- a/docs/hypervisor-guide/x86/how-xen-boots.rst
+++ b/docs/hypervisor-guide/x86/how-xen-boots.rst
@@ -55,6 +55,11 @@ If ``CONFIG_PVH_GUEST`` was selected at build time, an Elf note is included
 which indicates the ability to use the PVH boot protocol, and registers
 ``__pvh_start`` as the entrypoint, entered in 32bit mode.
 
+A combination of Multiboot 2 and MLE headers is used to implement DRTM for
+legacy (BIOS) boot. The separate entry point is used mainly to differentiate
+from other kinds of boots. It moves a magic number to EAX before jumping into
+common startup code.
+
 
 xen.gz
 ~~~~~~
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 77bb7a9e21..a69107bd81 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -126,6 +127,25 @@ multiboot2_header:
         .size multiboot2_header, . - multiboot2_header
         .type multiboot2_header, @object
 
+        .balign 16
+mle_header:
+        .long   0x9082ac5a  /* UUID0 */
+        .long   0x74a7476f  /* UUID1 */
+        .long   0xa2555c0f  /* UUID2 */
+        .long   0x42b651cb  /* UUID3 */
+        .long   0x00000034  /* MLE header size */
+        .long   0x00020002  /* MLE version 2.2 */
+        .long   (slaunch_stub_entry - start)  /* Linear entry point of MLE (SINIT virt. address) */
+        .long   0x00000000  /* First valid page of MLE */
+        .long   0x00000000  /* Offset within binary of first byte of MLE */
+        .long   (_end - start)  /* Offset within binary of last byte + 1 of MLE */
+        .long   0x00000723  /* Bit vector of MLE-supported capabilities */
+        .long   0x00000000  /* Starting linear address of command line (unused) */
+        .long   0x00000000  /* Ending linear address of command line (unused) */
+
+        .size mle_header, .-mle_header
+        .type mle_header, @object
+
         .section .init.rodata, "a", @progbits
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
@@ -332,6 +352,38 @@ cs32_switch:
         /* Jump to earlier loaded address. */
         jmp     *%edi
 
+        /*
+         * Entry point for TrenchBoot Secure Launch on Intel TXT platforms.
+         *
+         * CPU is in 32b protected mode with paging disabled. On entry:
+         * - %ebx = %eip = MLE entry point,
+         * - stack pointer is undefined,
+         * - CS is flat 4GB code segment,
+         * - DS, ES, SS, FS and GS are undefined according to TXT SDG, but this
+         *   would make it impossible to initialize GDTR, because GDT base must
+         *   be relocated in the descriptor, which requires write access that
+         *   CS doesn't provide. Instead we have to assume that DS is set by
+         *   SINIT ACM as flat 4GB data segment.
+         *
+         * Additional restrictions:
+         * - some MSRs are partially cleared, among them IA32_MISC_ENABLE, so
+         *   some capabilities might be reported as disabled even if they are
+         *   supported by CPU
+         * - interrupts (including NMIs and SMIs) are disabled and must be
+         *   enabled later
+         * - trying to enter real mode results in reset
+         * - APs must be brought up by MONITOR or GETSEC[WAKEUP], depending on
+         *   which is supported by a given SINIT ACM
+         */
+slaunch_stub_entry:
+        /* Calculate the load base address. */
+        mov     %ebx, %esi
+        sub     $sym_offs(slaunch_stub_entry), %esi
+
+        /* Mark Secure Launch boot protocol and jump to common entry. */
+        mov     $SLAUNCH_BOOTLOADER_MAGIC, %eax
+        jmp     .Lset_stack
+
 #ifdef CONFIG_PVH_GUEST
 ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, .long sym_offs(__pvh_start))
 
@@ -371,6 +423,7 @@ __start:
         /* Restore the clobbered field. */
         mov     %edx, (%ebx)
 
+.Lset_stack:
         /* Set up stack. */
         lea     STACK_SIZE - CPUINFO_sizeof + sym_esi(cpu0_stack), %esp
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:18:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:18:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000929.1381106 (Exim 4.92)
	(envelope-from )
	id 1uKzd6-0008KG-1M; Fri, 30 May 2025 13:18:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000929.1381106; Fri, 30 May 2025 13:18: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 1uKzd5-0008K9-Us; Fri, 30 May 2025 13:18:35 +0000
Received: by outflank-mailman (input) for mailman id 1000929;
 Fri, 30 May 2025 13:18:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzd3-0008Jy-7C
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:18:34 +0000
Received: from 8.mo561.mail-out.ovh.net (8.mo561.mail-out.ovh.net
 [87.98.172.249]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 93fdcce9-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:18:30 +0200 (CEST)
Received: from director4.ghost.mail-out.ovh.net (unknown [10.108.25.52])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4b83hj3kqyz1kFf
 for ; Fri, 30 May 2025 13:18:29 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-2nxzt (unknown [10.110.113.210])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 5CC8AC571A;
 Fri, 30 May 2025 13:18:27 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.110])
 by ghost-submission-5b5ff79f4f-2nxzt with ESMTPSA
 id cVVzByOwOWjZ2QAADMzzjw
 (envelope-from ); Fri, 30 May 2025 13:18: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" 
X-Inumbo-ID: 93fdcce9-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-110S004b2589251-9822-4f6f-8629-ee3c86da3d3c,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Lukasz Hawrylko ,
	=?UTF-8?q?Mateusz=20M=C3=B3wka?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini ,
	Nicola Vetrini ,
	Doug Goldstein ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 00/22] x86: Trenchboot Secure Launch DRTM (Xen)
Date: Fri, 30 May 2025 16:17:42 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12692551124840527004
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -51
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpefhvfevufffkffogggtgfesthekredtredtjeenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeevueejleetieejveeuheetveefvdeileefvdffleelfeekhfehgfegudduiefhgfenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhtrhgvnhgthhgsohhothdrohhrghdpshhouhhrtggvfhhorhhgvgdrnhgvthdpkhgvrhhnvghlrdhorhhgnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduuddtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheeiudgmpdhmohguvgepshhmth
 hpohhuth
DKIM-Signature: a=rsa-sha256; bh=9Icdj8G3G4IrStgoJVn7lJvTKzaaMme79V+bkIE7hmI=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611109; v=1;
 b=S8s8IljRUcy9LDF9K1kKpVdaB9zT2A6Z+g6KVJJFFAzCBBIqhLvKzEcRZyJ4TvtJofS9EcCs
 Ipnb9ZDtcsFG36sPMrpl7gtowmoKli4hLWCn4rYhLbwtcqMJknWxXDhlNnUw1/kbi66NDvFdGQ6
 0wKeMVZy/4gfXz30YxYYIjSgE4SmYkJxDf0i9n3I5c/VykvY6QhskGkt324A2f8nJTclV456BsX
 y1/0Sn7rGE+21X3c/mDBd66zeOlR0vw6RJw3b3OhKEMyGhS7uYt4pxNJr7GmnEsepQoE5Bw1GbA
 zUvUgAcx0JQgnG6G1J9BluJ7/SOKRhiXsdPwXYyuvun6g==

The aim of the [TrenchBoot] project is to provide an implementation of
DRTM that is generic enough to cover various use cases:
 - Intel TXT and AMD SKINIT on x86 CPUs
 - legacy and UEFI boot
 - TPM1.2 and TPM2.0
 - (in the future) DRTM on Arm CPUs

DRTM is a version of a measured launch that starts on request rather
than at the start of a boot cycle.  One of its advantages is in not
including the firmware in the chain of trust.

Xen already supports DRTM via [tboot] which targets Intel TXT only.
tboot employs encapsulates some of the DRTM details within itself while
with TrenchBoot Xen (or Linux) is meant to be a self-contained payload
for a TrenchBoot-enabled bootloader (think GRUB).  The one exception is
that UEFI case requires calling back into bootloader to initiate DRTM,
which is necessary to give Xen a chance of querying all the information
it needs from the firmware before performing DRTM start.

>From reading the above tboot might seem like a more abstracted, but the
reality is that the payload needs to have DRTM-specific knowledge either
way.  TrenchBoot in principle allows coming up with independent
implementations of bootloaders and payloads that are compatible with
each other.

The "x86/boot: choose AP stack based on APIC ID" patch is shared with
[Parallelize AP bring-up] series which is required here because Intel
TXT always releases all APs simultaneously.  The rest of the patches are
unique.

This version of the patches corresponds to this branch:
    https://github.com/TrenchBoot/xen/compare/d7d55c27cc...aem-staging-2025-05-30-v3

-----

[TrenchBoot]: https://trenchboot.org/
[tboot]: https://sourceforge.net/p/tboot/wiki/Home/
[Parallelize AP bring-up]: https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/
[v1]: https://lore.kernel.org/xen-devel/cover.1745172094.git.sergii.dmytruk@3mdeb.com/
[v2]: https://lore.kernel.org/xen-devel/cover.1747155790.git.sergii.dmytruk@3mdeb.com/

-----

Changes in v3:
 - sorted `F:` entries in MAINTAINERS file
 - made sha1 implementation more similar to sha256
 - dropped unused parameter from xen/arch/x86/cpu/intel.c:intel_log_smx_txt()
 - updated header guards according to new style
 - xen/arch/x86/include/asm/intel-txt.h:
   + briefly explained what TXT is
   + renamed: NR_TXT_CONFIG_SIZE -> TXT_CONFIG_SPACE_SIZE
   + renamed: read_txt_reg() -> txt_read()
   + renamed: write_txt_reg() -> txt_write()
   + marked txt_reset() as noreturn and used unreacheable() instead of while(1)
   + explained a bit more about TXT Heap
 - xen/include/xen/slr-table.h:
   + briefly explained what SLRT is
   + fixed checks in slr_next_entry()
 - SPDX-License-Identifier: GPL-2.0 -> GPL-2.0-only
 - made more code const-correct
 - use arithmetic on pointers to `void` instead of pointers to `uint8_t`

Changes in [v2]:
 - using dashes instead of underscores in the names of new files
 - dropping of an extra sha256 implementation
 - rewriting sha1 implementation to be in line with already present
   sha256 implementation (simplifying it and getting rid of macros)
 - correct placement of new lines in Makefile
 - add header guards to all new files
 - use correct names for header guards in new files
 - update license of xen/include/xen/slr-table.h
 - changed fixmlehdr to search for header within 8 instead of 4 KiB file
   prefix
 - don't print DRTM-related capabilities when resuming from S3
 - forbade S3 in case of Secure Launch
 - fixed an issue with resuming from S3 caused by inappropriate use of
   __initdata
 - added a new section to MAINTAINERS
 - improved commit messages
 - fixed MISRA C violations:
   * shadowing of e820 global
   * missing U literal suffixes
   * use of ull literal suffix
   * excluded fixmlehdr from analysis (similar to other build tools)
   * use of 0 instead of NULL in one place
   * provided declarations for some definitions
   * marked asm-invoked functions with `asmlinkage`

-----

Kacper Stojek (2):
  x86/boot: add MLE header and Secure Launch entry point
  xen/arch/x86: reserve TXT memory during Slaunch

Krystian Hebel (7):
  x86/include/asm/intel-txt.h: constants and accessors for TXT registers
    and heap
  x86/boot/slaunch-early: early TXT checks and boot data retrieval
  x86/slaunch: restore boot MTRRs after Intel TXT DRTM
  xen/lib: add implementation of SHA-1
  x86/tpm.c: code for early hashing and extending PCRs (for TPM1.2)
  x86/boot: choose AP stack based on APIC ID
  x86/smpboot.c: TXT AP bringup

Michał Żygowski (2):
  x86/hvm: check for VMX in SMX if Slaunch is active
  x86/cpu: report SMX, TXT and SKINIT capabilities

Sergii Dmytruk (11):
  include/xen/slr-table.h: Secure Launch Resource Table definitions
  x86/boot/slaunch-early: implement early initialization
  x86/mtrr: expose functions for pausing caching
  x86/tpm.c: support extending PCRs of TPM2.0
  x86/tpm.c: implement event log for TPM2.0
  x86/slaunch: process DRTM policy
  x86/acpi: disallow S3 on Secure Launch boot
  x86/boot/slaunch-early: find MBI and SLRT on AMD
  x86/slaunch: support AMD SKINIT
  x86/slaunch: support EFI boot
  MAINTAINERS: add a section for TrenchBoot Slaunch

 .gitignore                                    |    1 +
 MAINTAINERS                                   |   15 +
 .../eclair_analysis/ECLAIR/out_of_scope.ecl   |    1 +
 docs/hypervisor-guide/x86/how-xen-boots.rst   |    7 +
 xen/arch/x86/Makefile                         |   12 +-
 xen/arch/x86/acpi/power.c                     |    8 +
 xen/arch/x86/boot/Makefile                    |   10 +-
 xen/arch/x86/boot/head.S                      |  250 ++++
 xen/arch/x86/boot/slaunch-early.c             |  105 ++
 xen/arch/x86/boot/trampoline.S                |   40 +-
 xen/arch/x86/boot/x86_64.S                    |   42 +-
 xen/arch/x86/cpu/amd.c                        |   16 +
 xen/arch/x86/cpu/cpu.h                        |    1 +
 xen/arch/x86/cpu/hygon.c                      |    1 +
 xen/arch/x86/cpu/intel.c                      |   46 +
 xen/arch/x86/cpu/mtrr/generic.c               |   51 +-
 xen/arch/x86/e820.c                           |    5 +
 xen/arch/x86/efi/efi-boot.h                   |   88 +-
 xen/arch/x86/efi/fixmlehdr.c                  |  127 ++
 xen/arch/x86/hvm/vmx/vmcs.c                   |    3 +-
 xen/arch/x86/include/asm/apicdef.h            |    4 +
 xen/arch/x86/include/asm/intel-txt.h          |  478 ++++++++
 xen/arch/x86/include/asm/mm.h                 |    3 +
 xen/arch/x86/include/asm/msr-index.h          |    3 +
 xen/arch/x86/include/asm/mtrr.h               |    8 +
 xen/arch/x86/include/asm/processor.h          |    1 +
 xen/arch/x86/include/asm/slaunch.h            |   98 ++
 xen/arch/x86/include/asm/tpm.h                |   19 +
 xen/arch/x86/intel-txt.c                      |  188 +++
 xen/arch/x86/setup.c                          |   32 +-
 xen/arch/x86/slaunch.c                        |  465 ++++++++
 xen/arch/x86/smpboot.c                        |   63 +
 xen/arch/x86/tboot.c                          |   20 +-
 xen/arch/x86/tpm.c                            | 1056 +++++++++++++++++
 xen/common/efi/boot.c                         |    4 +
 xen/common/efi/runtime.c                      |    1 +
 xen/include/xen/efi.h                         |    1 +
 xen/include/xen/sha1.h                        |   14 +
 xen/include/xen/slr-table.h                   |  276 +++++
 xen/lib/Makefile                              |    1 +
 xen/lib/sha1.c                                |  190 +++
 41 files changed, 3698 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/x86/boot/slaunch-early.c
 create mode 100644 xen/arch/x86/efi/fixmlehdr.c
 create mode 100644 xen/arch/x86/include/asm/intel-txt.h
 create mode 100644 xen/arch/x86/include/asm/slaunch.h
 create mode 100644 xen/arch/x86/include/asm/tpm.h
 create mode 100644 xen/arch/x86/intel-txt.c
 create mode 100644 xen/arch/x86/slaunch.c
 create mode 100644 xen/arch/x86/tpm.c
 create mode 100644 xen/include/xen/sha1.h
 create mode 100644 xen/include/xen/slr-table.h
 create mode 100644 xen/lib/sha1.c


base-commit: d7d55c27cc3253fb3634a0e468ef5df30487552b
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:18:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:18:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000930.1381112 (Exim 4.92)
	(envelope-from )
	id 1uKzd6-0008NQ-9T; Fri, 30 May 2025 13:18:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000930.1381112; Fri, 30 May 2025 13:18: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 1uKzd6-0008Md-4W; Fri, 30 May 2025 13:18:36 +0000
Received: by outflank-mailman (input) for mailman id 1000930;
 Fri, 30 May 2025 13:18:35 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzd4-0008Jy-Rh
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:18:34 +0000
Received: from 3.mo576.mail-out.ovh.net (3.mo576.mail-out.ovh.net
 [188.165.52.203]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9630bd2a-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:18:33 +0200 (CEST)
Received: from director1.ghost.mail-out.ovh.net (unknown [10.108.2.206])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4b83hn1Cptz31p0
 for ; Fri, 30 May 2025 13:18:33 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-dfc6s (unknown [10.111.182.37])
 by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 7AFD4C43FE;
 Fri, 30 May 2025 13:18:31 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.113])
 by ghost-submission-5b5ff79f4f-dfc6s with ESMTPSA
 id NlKHBCewOWhVigEAelGN8Q
 (envelope-from ); Fri, 30 May 2025 13:18: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" 
X-Inumbo-ID: 9630bd2a-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-113S00710e8f645-8c55-4142-8ae5-6e1c6e47b73d,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Lukasz Hawrylko ,
	=?UTF-8?q?Mateusz=20M=C3=B3wka?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 01/22] x86/include/asm/intel-txt.h: constants and accessors for TXT registers and heap
Date: Fri, 30 May 2025 16:17:43 +0300
Message-ID: <5da8e6c9fd2d986cd99be35774b850584e4a43ee.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12693395550816285852
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduvdculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepheevieeivdejkeehueetgeeivddvfeeiueetvedtfffgjeekffekveefudfgleeunecuffhomhgrihhnpehinhhtvghlrdgtohhmnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheejiegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=75kgFmRc/GJ3HdcYtM6U8h8g3LZajEoRkGd+0twV0e8=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611113; v=1;
 b=i5JJKazbMG38IlrUj/MuXJQvWOSDYDjr/lh9LoOanwsaUknGGW5bhsaaJlZv/+ggvvP0473p
 f7gq0XqJ8FjrhOD+qt5fX1Lpx4hSUCcuXhSQ6tKhjCVvtEnbJxG2TPsvjj4p5UFV+7Dn974+CFR
 YtaDJBVVQsedIyoa2yqeNZJ8IZYfZpwFl0Ela83itbte74cV+HFVA44Kijejqg753TPenLOmwAW
 T1l6tLnpNuRc9cthMkGZZJ1OzWwLUrQtZ4mM9tBbiBhvcEWvJ6Hj3YTpzdZCpkHgjAIPkegj9jn
 6mn2q3DLaxEqy3dSejjZnhkf0rbcTYBW9/NYxYFWOZFOA==

From: Krystian Hebel 

The file contains base address of TXT register spaces, offsets of
registers within them, error codes and inline functions for accessing
structures stored on TXT heap.

xen/arch/x86/tboot.c is updated to use definitions from this new header
instead of duplicating them.  The change in tboot_protect_mem_regions()
there is caused by going from NR_TXT_CONFIG_PAGES to
TXT_CONFIG_SPACE_SIZE which avoids multiplying number of pages by page
size on every use.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/include/asm/intel-txt.h | 297 +++++++++++++++++++++++++++
 xen/arch/x86/tboot.c                 |  20 +-
 2 files changed, 299 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/intel-txt.h

diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
new file mode 100644
index 0000000000..cc2d312f4d
--- /dev/null
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -0,0 +1,297 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Intel TXT is an implementation of DRTM in CPUs made by Intel (although CPU
+ * alone isn't enough, chipset must support TXT as well).
+ *
+ * Overview:
+ *   https://www.intel.com/content/www/us/en/support/articles/000025873/processors.html
+ * Software Development Guide (SDG):
+ *   https://www.intel.com/content/www/us/en/content-details/315168/
+ */
+
+#ifndef X86_INTEL_TXT_H
+#define X86_INTEL_TXT_H
+
+/*
+ * TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
+ */
+#define TXT_PUB_CONFIG_REGS_BASE        0xfed30000U
+#define TXT_PRIV_CONFIG_REGS_BASE       0xfed20000U
+
+/*
+ * The same set of registers is exposed twice (with different permissions) and
+ * they are allocated continuously with page alignment.
+ */
+#define TXT_CONFIG_SPACE_SIZE \
+    (TXT_PUB_CONFIG_REGS_BASE - TXT_PRIV_CONFIG_REGS_BASE)
+
+/* Offsets from pub/priv config space. */
+#define TXTCR_STS                       0x0000
+#define TXTCR_ESTS                      0x0008
+#define TXTCR_ERRORCODE                 0x0030
+#define TXTCR_CMD_RESET                 0x0038
+#define TXTCR_CMD_CLOSE_PRIVATE         0x0048
+#define TXTCR_DIDVID                    0x0110
+#define TXTCR_VER_EMIF                  0x0200
+#define TXTCR_CMD_UNLOCK_MEM_CONFIG     0x0218
+#define TXTCR_SINIT_BASE                0x0270
+#define TXTCR_SINIT_SIZE                0x0278
+#define TXTCR_MLE_JOIN                  0x0290
+#define TXTCR_HEAP_BASE                 0x0300
+#define TXTCR_HEAP_SIZE                 0x0308
+#define TXTCR_SCRATCHPAD                0x0378
+#define TXTCR_CMD_OPEN_LOCALITY1        0x0380
+#define TXTCR_CMD_CLOSE_LOCALITY1       0x0388
+#define TXTCR_CMD_OPEN_LOCALITY2        0x0390
+#define TXTCR_CMD_CLOSE_LOCALITY2       0x0398
+#define TXTCR_CMD_SECRETS               0x08e0
+#define TXTCR_CMD_NO_SECRETS            0x08e8
+#define TXTCR_E2STS                     0x08f0
+
+/*
+ * Secure Launch Defined Error Codes used in MLE-initiated TXT resets.
+ *
+ * TXT Specification
+ * Appendix I ACM Error Codes
+ */
+#define SLAUNCH_ERROR_GENERIC                0xc0008001U
+#define SLAUNCH_ERROR_TPM_INIT               0xc0008002U
+#define SLAUNCH_ERROR_TPM_INVALID_LOG20      0xc0008003U
+#define SLAUNCH_ERROR_TPM_LOGGING_FAILED     0xc0008004U
+#define SLAUNCH_ERROR_REGION_STRADDLE_4GB    0xc0008005U
+#define SLAUNCH_ERROR_TPM_EXTEND             0xc0008006U
+#define SLAUNCH_ERROR_MTRR_INV_VCNT          0xc0008007U
+#define SLAUNCH_ERROR_MTRR_INV_DEF_TYPE      0xc0008008U
+#define SLAUNCH_ERROR_MTRR_INV_BASE          0xc0008009U
+#define SLAUNCH_ERROR_MTRR_INV_MASK          0xc000800aU
+#define SLAUNCH_ERROR_MSR_INV_MISC_EN        0xc000800bU
+#define SLAUNCH_ERROR_INV_AP_INTERRUPT       0xc000800cU
+#define SLAUNCH_ERROR_INTEGER_OVERFLOW       0xc000800dU
+#define SLAUNCH_ERROR_HEAP_WALK              0xc000800eU
+#define SLAUNCH_ERROR_HEAP_MAP               0xc000800fU
+#define SLAUNCH_ERROR_REGION_ABOVE_4GB       0xc0008010U
+#define SLAUNCH_ERROR_HEAP_INVALID_DMAR      0xc0008011U
+#define SLAUNCH_ERROR_HEAP_DMAR_SIZE         0xc0008012U
+#define SLAUNCH_ERROR_HEAP_DMAR_MAP          0xc0008013U
+#define SLAUNCH_ERROR_HI_PMR_BASE            0xc0008014U
+#define SLAUNCH_ERROR_HI_PMR_SIZE            0xc0008015U
+#define SLAUNCH_ERROR_LO_PMR_BASE            0xc0008016U
+#define SLAUNCH_ERROR_LO_PMR_SIZE            0xc0008017U
+#define SLAUNCH_ERROR_LO_PMR_MLE             0xc0008018U
+#define SLAUNCH_ERROR_INITRD_TOO_BIG         0xc0008019U
+#define SLAUNCH_ERROR_HEAP_ZERO_OFFSET       0xc000801aU
+#define SLAUNCH_ERROR_WAKE_BLOCK_TOO_SMALL   0xc000801bU
+#define SLAUNCH_ERROR_MLE_BUFFER_OVERLAP     0xc000801cU
+#define SLAUNCH_ERROR_BUFFER_BEYOND_PMR      0xc000801dU
+#define SLAUNCH_ERROR_OS_SINIT_BAD_VERSION   0xc000801eU
+#define SLAUNCH_ERROR_EVENTLOG_MAP           0xc000801fU
+#define SLAUNCH_ERROR_TPM_NUMBER_ALGS        0xc0008020U
+#define SLAUNCH_ERROR_TPM_UNKNOWN_DIGEST     0xc0008021U
+#define SLAUNCH_ERROR_TPM_INVALID_EVENT      0xc0008022U
+
+#define SLAUNCH_BOOTLOADER_MAGIC             0x4c534254
+
+#ifndef __ASSEMBLY__
+
+/* Need to differentiate between pre- and post paging enabled. */
+#ifdef __EARLY_SLAUNCH__
+#include 
+#define _txt(x) _p(x)
+#else
+#include 
+#include    // __va()
+#define _txt(x) __va(x)
+#endif
+
+/*
+ * Always use private space as some of registers are either read-only or not
+ * present in public space.
+ */
+static inline uint64_t txt_read(unsigned int reg_no)
+{
+    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
+    return *reg;
+}
+
+static inline void txt_write(unsigned int reg_no, uint64_t val)
+{
+    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
+    *reg = val;
+}
+
+static inline void noreturn txt_reset(uint32_t error)
+{
+    txt_write(TXTCR_ERRORCODE, error);
+    txt_write(TXTCR_CMD_NO_SECRETS, 1);
+    txt_write(TXTCR_CMD_UNLOCK_MEM_CONFIG, 1);
+    /*
+     * This serves as TXT register barrier after writing to
+     * TXTCR_CMD_UNLOCK_MEM_CONFIG. Must be done to ensure that any future
+     * chipset operations see the write.
+     */
+    (void)txt_read(TXTCR_ESTS);
+    txt_write(TXTCR_CMD_RESET, 1);
+    unreachable();
+}
+
+/*
+ * Secure Launch defined OS/MLE TXT Heap table
+ */
+struct txt_os_mle_data {
+    uint32_t version;
+    uint32_t reserved;
+    uint64_t slrt;
+    uint64_t txt_info;
+    uint32_t ap_wake_block;
+    uint32_t ap_wake_block_size;
+    uint8_t mle_scratch[64];
+} __packed;
+
+/*
+ * TXT specification defined BIOS data TXT Heap table
+ */
+struct txt_bios_data {
+    uint32_t version; /* Currently 5 for TPM 1.2 and 6 for TPM 2.0 */
+    uint32_t bios_sinit_size;
+    uint64_t reserved1;
+    uint64_t reserved2;
+    uint32_t num_logical_procs;
+    /* Versions >= 3 && < 5 */
+    uint32_t sinit_flags;
+    /* Versions >= 5 with updates in version 6 */
+    uint32_t mle_flags;
+    /* Versions >= 4 */
+    /* Ext Data Elements */
+} __packed;
+
+/*
+ * TXT specification defined OS/SINIT TXT Heap table
+ */
+struct txt_os_sinit_data {
+    uint32_t version;       /* Currently 6 for TPM 1.2 and 7 for TPM 2.0 */
+    uint32_t flags;         /* Reserved in version 6 */
+    uint64_t mle_ptab;
+    uint64_t mle_size;
+    uint64_t mle_hdr_base;
+    uint64_t vtd_pmr_lo_base;
+    uint64_t vtd_pmr_lo_size;
+    uint64_t vtd_pmr_hi_base;
+    uint64_t vtd_pmr_hi_size;
+    uint64_t lcp_po_base;
+    uint64_t lcp_po_size;
+    uint32_t capabilities;
+    /* Version = 5 */
+    uint64_t efi_rsdt_ptr;  /* RSD*P* in versions >= 6 */
+    /* Versions >= 6 */
+    /* Ext Data Elements */
+} __packed;
+
+/*
+ * TXT specification defined SINIT/MLE TXT Heap table
+ */
+struct txt_sinit_mle_data {
+    uint32_t version;  /* Current values are 6 through 9 */
+    /* Versions <= 8, fields until lcp_policy_control must be 0 for >= 9 */
+    uint8_t bios_acm_id[20];
+    uint32_t edx_senter_flags;
+    uint64_t mseg_valid;
+    uint8_t sinit_hash[20];
+    uint8_t mle_hash[20];
+    uint8_t stm_hash[20];
+    uint8_t lcp_policy_hash[20];
+    uint32_t lcp_policy_control;
+    /* Versions >= 7 */
+    uint32_t rlp_wakeup_addr;
+    uint32_t reserved;
+    uint32_t num_of_sinit_mdrs;
+    uint32_t sinit_mdrs_table_offset;
+    uint32_t sinit_vtd_dmar_table_size;
+    uint32_t sinit_vtd_dmar_table_offset;
+    /* Versions >= 8 */
+    uint32_t processor_scrtm_status;
+    /* Versions >= 9 */
+    /* Ext Data Elements */
+} __packed;
+
+/*
+ * Functions to extract data from the Intel TXT Heap Memory.
+ *
+ * The layout of the heap is dictated by TXT. It's a set of variable-sized
+ * tables that appear in pre-defined order:
+ *
+ *   +------------------------------------+
+ *   | Size of Bios Data table (uint64_t) |
+ *   +------------------------------------+
+ *   | Bios Data table                    |
+ *   +------------------------------------+
+ *   | Size of OS MLE table (uint64_t)    |
+ *   +------------------------------------+
+ *   | OS MLE table                       |
+ *   +--------------------------------    +
+ *   | Size of OS SINIT table (uint64_t)  |
+ *   +------------------------------------+
+ *   | OS SINIT table                     |
+ *   +------------------------------------+
+ *   | Size of SINIT MLE table (uint64_t) |
+ *   +------------------------------------+
+ *   | SINIT MLE table                    |
+ *   +------------------------------------+
+ *
+ * NOTE: the table size fields include the 8 byte size field itself.
+ *
+ * NOTE: despite SDG mentioning 8-byte alignment, at least some BIOS ACM modules
+ *       were observed to violate this requirement for Bios Data table, so not
+ *       enforcing any alignment.
+ */
+static inline uint64_t txt_bios_data_size(const void *heap)
+{
+    return *(const uint64_t *)heap - sizeof(uint64_t);
+}
+
+static inline void *txt_bios_data_start(const void *heap)
+{
+    return (void *)heap + sizeof(uint64_t);
+}
+
+static inline uint64_t txt_os_mle_data_size(const void *heap)
+{
+    return *(const uint64_t *)(txt_bios_data_start(heap) +
+                               txt_bios_data_size(heap)) -
+           sizeof(uint64_t);
+}
+
+static inline void *txt_os_mle_data_start(const void *heap)
+{
+    return txt_bios_data_start(heap) + txt_bios_data_size(heap) +
+           sizeof(uint64_t);
+}
+
+static inline uint64_t txt_os_sinit_data_size(const void *heap)
+{
+    return *(const uint64_t *)(txt_os_mle_data_start(heap) +
+                               txt_os_mle_data_size(heap)) -
+           sizeof(uint64_t);
+}
+
+static inline void *txt_os_sinit_data_start(const void *heap)
+{
+    return txt_os_mle_data_start(heap) + txt_os_mle_data_size(heap) +
+           sizeof(uint64_t);
+}
+
+static inline uint64_t txt_sinit_mle_data_size(const void *heap)
+{
+    return *(const uint64_t *)(txt_os_sinit_data_start(heap) +
+                               txt_os_sinit_data_size(heap)) -
+           sizeof(uint64_t);
+}
+
+static inline void *txt_sinit_mle_data_start(const void *heap)
+{
+    return txt_os_sinit_data_start(heap) + txt_os_sinit_data_size(heap) +
+           sizeof(uint64_t);
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* X86_INTEL_TXT_H */
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index d5db60d335..8a573d8c79 100644
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -35,23 +36,6 @@ static uint64_t __initdata sinit_base, __initdata sinit_size;
 
 static bool __ro_after_init is_vtd;
 
-/*
- * TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
- */
-
-#define TXT_PUB_CONFIG_REGS_BASE       0xfed30000
-#define TXT_PRIV_CONFIG_REGS_BASE      0xfed20000
-
-/* # pages for each config regs space - used by fixmap */
-#define NR_TXT_CONFIG_PAGES     ((TXT_PUB_CONFIG_REGS_BASE -                \
-                                  TXT_PRIV_CONFIG_REGS_BASE) >> PAGE_SHIFT)
-
-/* offsets from pub/priv config space */
-#define TXTCR_SINIT_BASE            0x0270
-#define TXTCR_SINIT_SIZE            0x0278
-#define TXTCR_HEAP_BASE             0x0300
-#define TXTCR_HEAP_SIZE             0x0308
-
 #define SHA1_SIZE      20
 typedef uint8_t   sha1_hash_t[SHA1_SIZE];
 
@@ -409,7 +393,7 @@ int __init tboot_protect_mem_regions(void)
 
     /* TXT Private Space */
     rc = e820_change_range_type(&e820, TXT_PRIV_CONFIG_REGS_BASE,
-                 TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SIZE,
+                 TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_SIZE,
                  E820_RESERVED, E820_UNUSABLE);
     if ( !rc )
         return 0;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:18:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:18:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000934.1381146 (Exim 4.92)
	(envelope-from )
	id 1uKzdG-0000uI-2Q; Fri, 30 May 2025 13:18:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000934.1381146; Fri, 30 May 2025 13:18: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 1uKzdF-0000u4-Uz; Fri, 30 May 2025 13:18:45 +0000
Received: by outflank-mailman (input) for mailman id 1000934;
 Fri, 30 May 2025 13:18:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdE-0000ql-Fr
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:18:44 +0000
Received: from 3.mo575.mail-out.ovh.net (3.mo575.mail-out.ovh.net
 [46.105.58.60]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9b4d507d-3d58-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:18:42 +0200 (CEST)
Received: from director2.ghost.mail-out.ovh.net (unknown [10.108.2.206])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4b83hx5zZRz28B8
 for ; Fri, 30 May 2025 13:18:41 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-2djnr (unknown [10.111.174.16])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 9CD20C3BB2;
 Fri, 30 May 2025 13:18:40 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.107])
 by ghost-submission-5b5ff79f4f-2djnr with ESMTPSA
 id B0t9EzCwOWhgJgAAIK2ldA
 (envelope-from ); Fri, 30 May 2025 13:18: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" 
X-Inumbo-ID: 9b4d507d-3d58-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-107S001d1b71519-d27e-408c-8523-b9c0e2d47a6d,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 04/22] x86/boot/slaunch-early: implement early initialization
Date: Fri, 30 May 2025 16:17:46 +0300
Message-ID: <16a544876163afece619d50f80869aaacc9c797c.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12695928826315977884
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepffejgfduveektedugeeuiefhtdfhjefgieelkeeugfeggedtgeevheefheeffeeunecuffhomhgrihhnpegsrghsvgdrmhgrphdphhgvrggurdhssgenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekgedrvddvuddpfeejrdehledrudegvddruddtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehjeehmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=GvKdVlecLh2PmzTm3hSectebiIzksYZuaxKe05SsphE=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611121; v=1;
 b=YWF4HxQni853VwJ2/M7u7AJUwzUCW2rBUmmo7Iil0Sb4T6MHZdZcw+7Cdx9bGPsaHT9sRnBf
 iKX3omW9+HJ4/rCPVZdIcPc6in7tDPmWlRrzwDBjLRMJFGpU74UwIXTt4P5cUciJ+es+am0T0Rd
 JIDga3+IqfphDU98v6vXoNkMyi7E0pS+ioytkxiVt+gTga1fEcZE9zF+lyCgvBrR7NZy69qv5OD
 84hP29LLpnp69wfRFOGetK/fy0vAu0XW7VvDBE8dd3Dfx9Y2jTbHXRt1rJgHvjBKiBMOeitzg48
 I/QBz1ndITA+URa6BbRvKpdpDMTUMKZKEvCJACaq/n6rA==

Make head.S invoke a C function to retrieve MBI and SLRT addresses in a
platform-specific way.  This is also the place to perform sanity checks
of DRTM.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/Makefile                |  1 +
 xen/arch/x86/boot/Makefile           |  5 +++-
 xen/arch/x86/boot/head.S             | 43 ++++++++++++++++++++++++++++
 xen/arch/x86/boot/slaunch-early.c    | 41 ++++++++++++++++++++++++++
 xen/arch/x86/include/asm/intel-txt.h | 16 +++++++++++
 xen/arch/x86/include/asm/slaunch.h   | 26 +++++++++++++++++
 xen/arch/x86/slaunch.c               | 27 +++++++++++++++++
 7 files changed, 158 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/x86/boot/slaunch-early.c
 create mode 100644 xen/arch/x86/include/asm/slaunch.h
 create mode 100644 xen/arch/x86/slaunch.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index ce724a9daa..aa20eb42b5 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_COMPAT) += x86_64/physdev.o
 obj-$(CONFIG_X86_PSR) += psr.o
 obj-y += setup.o
 obj-y += shutdown.o
+obj-y += slaunch.o
 obj-y += smp.o
 obj-y += smpboot.o
 obj-y += spec_ctrl.o
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index ff0d61d7ac..5471b966dd 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -5,6 +5,7 @@ obj-bin-y += $(obj64)
 obj32 := cmdline.32.o
 obj32 += reloc.32.o
 obj32 += reloc-trampoline.32.o
+obj32 += slaunch-early.32.o
 
 obj64 := reloc-trampoline.o
 
@@ -28,6 +29,8 @@ $(obj32): XEN_CFLAGS := $(CFLAGS_x86_32) -fpic
 $(obj)/%.32.o: $(src)/%.c FORCE
 	$(call if_changed_rule,cc_o_c)
 
+$(obj)/slaunch-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
+
 orphan-handling-$(call ld-option,--orphan-handling=error) := --orphan-handling=error
 LDFLAGS_DIRECT-$(call ld-option,--warn-rwx-segments) := --no-warn-rwx-segments
 LDFLAGS_DIRECT += $(LDFLAGS_DIRECT-y)
@@ -81,7 +84,7 @@ cmd_combine = \
               --bin1      $(obj)/built-in-32.base.bin \
               --bin2      $(obj)/built-in-32.offset.bin \
               --map       $(obj)/built-in-32.base.map \
-              --exports   cmdline_parse_early,reloc,reloc_trampoline32 \
+              --exports   cmdline_parse_early,reloc,reloc_trampoline32,slaunch_early_init \
               --output    $@
 
 targets += built-in-32.S
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index a69107bd81..b4cf423c80 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -472,6 +472,10 @@ __start:
         /* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
         xor     %edx,%edx
 
+        /* Check for TrenchBoot slaunch bootloader. */
+        cmp     $SLAUNCH_BOOTLOADER_MAGIC, %eax
+        je      .Lslaunch_proto
+
         /* Check for Multiboot2 bootloader. */
         cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
         je      .Lmultiboot2_proto
@@ -487,6 +491,45 @@ __start:
         cmovnz  MB_mem_lower(%ebx),%edx
         jmp     trampoline_bios_setup
 
+.Lslaunch_proto:
+        /*
+         * Upon reaching here, CPU state mostly matches the one setup by the
+         * bootloader with ESP, ESI and EDX being clobbered above.
+         */
+
+        /* Save information that TrenchBoot slaunch was used. */
+        movb    $1, sym_esi(slaunch_active)
+
+        /*
+         * Prepare space for output parameter of slaunch_early_init(), which is
+         * a structure of two uint32_t fields.
+         */
+        sub     $8, %esp
+
+        push    %esp                             /* pointer to output structure */
+        lea     sym_offs(__2M_rwdata_end), %ecx  /* end of target image */
+        lea     sym_offs(_start), %edx           /* target base address */
+        mov     %esi, %eax                       /* load base address */
+        /*
+         * slaunch_early_init(load/eax, tgt/edx, tgt_end/ecx, ret/stk) using
+         * fastcall calling convention.
+         */
+        call    slaunch_early_init
+        add     $4, %esp                         /* pop the fourth parameter */
+
+        /* Move outputs of slaunch_early_init() from stack into registers. */
+        pop     %eax  /* physical MBI address */
+        pop     %edx  /* physical SLRT address */
+
+        /* Save physical address of SLRT for C code. */
+        mov     %edx, sym_esi(slaunch_slrt)
+
+        /* Store MBI address in EBX where MB2 code expects it. */
+        mov     %eax, %ebx
+
+        /* Move magic number expected by Multiboot 2 to EAX and fall through. */
+        movl    $MULTIBOOT2_BOOTLOADER_MAGIC, %eax
+
 .Lmultiboot2_proto:
         /* Skip Multiboot2 information fixed part. */
         lea     (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%ebx),%ecx
diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
new file mode 100644
index 0000000000..c9d364bcd5
--- /dev/null
+++ b/xen/arch/x86/boot/slaunch-early.c
@@ -0,0 +1,41 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+
+struct early_init_results
+{
+    uint32_t mbi_pa;
+    uint32_t slrt_pa;
+} __packed;
+
+void asmlinkage slaunch_early_init(uint32_t load_base_addr,
+                                   uint32_t tgt_base_addr,
+                                   uint32_t tgt_end_addr,
+                                   struct early_init_results *result)
+{
+    void *txt_heap;
+    const struct txt_os_mle_data *os_mle;
+    const struct slr_table *slrt;
+    const struct slr_entry_intel_info *intel_info;
+
+    txt_heap = txt_init();
+    os_mle = txt_os_mle_data_start(txt_heap);
+
+    result->slrt_pa = os_mle->slrt;
+    result->mbi_pa = 0;
+
+    slrt = (const struct slr_table *)(uintptr_t)os_mle->slrt;
+
+    intel_info = (const struct slr_entry_intel_info *)
+        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+    if ( intel_info == NULL || intel_info->hdr.size != sizeof(*intel_info) )
+        return;
+
+    result->mbi_pa = intel_info->boot_params_base;
+}
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index cc2d312f4d..7658457e9d 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -292,6 +292,22 @@ static inline void *txt_sinit_mle_data_start(const void *heap)
            sizeof(uint64_t);
 }
 
+static inline void *txt_init(void)
+{
+    void *txt_heap;
+
+    /* Clear the TXT error register for a clean start of the day. */
+    txt_write(TXTCR_ERRORCODE, 0);
+
+    txt_heap = _p(txt_read(TXTCR_HEAP_BASE));
+
+    if ( txt_os_mle_data_size(txt_heap) < sizeof(struct txt_os_mle_data) ||
+         txt_os_sinit_data_size(txt_heap) < sizeof(struct txt_os_sinit_data) )
+        txt_reset(SLAUNCH_ERROR_GENERIC);
+
+    return txt_heap;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* X86_INTEL_TXT_H */
diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
new file mode 100644
index 0000000000..df42defd92
--- /dev/null
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -0,0 +1,26 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#ifndef X86_SLAUNCH_H
+#define X86_SLAUNCH_H
+
+#include 
+
+/* Indicates an active Secure Launch boot. */
+extern bool slaunch_active;
+
+/*
+ * Holds physical address of SLRT.  Use slaunch_get_slrt() to access SLRT
+ * instead of mapping where this points to.
+ */
+extern uint32_t slaunch_slrt;
+
+/*
+ * Retrieves pointer to SLRT.  Checks table's validity and maps it as necessary.
+ */
+struct slr_table *slaunch_get_slrt(void);
+
+#endif /* X86_SLAUNCH_H */
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
new file mode 100644
index 0000000000..a3e6ab8d71
--- /dev/null
+++ b/xen/arch/x86/slaunch.c
@@ -0,0 +1,27 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * These variables are assigned to by the code near Xen's entry point.
+ *
+ * slaunch_active is not __initdata to allow checking for an active Secure
+ * Launch boot.
+ */
+bool slaunch_active;
+uint32_t __initdata slaunch_slrt; /* physical address */
+
+/* Using slaunch_active in head.S assumes it's a single byte in size, so enforce
+ * this assumption. */
+static void __maybe_unused compile_time_checks(void)
+{
+    BUILD_BUG_ON(sizeof(slaunch_active) != 1);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:18:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:18:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000936.1381155 (Exim 4.92)
	(envelope-from )
	id 1uKzdI-0001CW-E4; Fri, 30 May 2025 13:18:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000936.1381155; Fri, 30 May 2025 13: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 1uKzdI-0001CJ-Ad; Fri, 30 May 2025 13:18:48 +0000
Received: by outflank-mailman (input) for mailman id 1000936;
 Fri, 30 May 2025 13:18:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdG-0000ql-U2
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:18:46 +0000
Received: from 10.mo583.mail-out.ovh.net (10.mo583.mail-out.ovh.net
 [46.105.52.148]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9d18b53d-3d58-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:18:45 +0200 (CEST)
Received: from director5.ghost.mail-out.ovh.net (unknown [10.109.176.202])
 by mo583.mail-out.ovh.net (Postfix) with ESMTP id 4b83j06CYsz1kgY
 for ; Fri, 30 May 2025 13:18:44 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-r8s5j (unknown [10.110.168.204])
 by director5.ghost.mail-out.ovh.net (Postfix) with ESMTPS id B94B4100223;
 Fri, 30 May 2025 13:18:43 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.111])
 by ghost-submission-5b5ff79f4f-r8s5j with ESMTPSA
 id rs9PIzOwOWjQtgAAgydd6Q
 (envelope-from ); Fri, 30 May 2025 13:18: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" 
X-Inumbo-ID: 9d18b53d-3d58-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-111S0054675508b-6510-4009-9374-a7b742f4e717,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 05/22] x86/boot/slaunch-early: early TXT checks and boot data retrieval
Date: Fri, 30 May 2025 16:17:47 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12696773251544298652
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhephfehfeehudeileeikeffgfffgfefuddtveelvedvhfffgfelvdfgtddutdehfeeinecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduuddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekfegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=Ze8+L6G+0Rc7+4Bq+m7/6vFCoR62w3qclGgLacvIoZA=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611124; v=1;
 b=eHQo6MMWNilw9KMr/5ps9HwV90sMmmQb4iCsqFYY6RaZIbnl6BYqwYk2ch/L+oVHP4Cs+DGj
 BRDKLlcBdEXL0aviHBoLHwJ5XRo+yzbyPAMzQvYCcz1tTH9xMgOh5L0xB+OWP2A8pHAyCYKM4M9
 yEIJzoYaZWZH90ES0jz39TDIYF0uayV6RK2cU/oBe9o4DnAsvqvukBd4Jbtv0J9CijBkyNsqphN
 +uYQHoJE5TLiETBh3xa7cCZwUjKHdEAGfOk9yy5IdF0Y9tyEUj1dOpW4LlEAnS1yCeh8MrJkxDM
 N82/v94/hsyo4IMycSoccIQppINRE479nyELIOzOG3XjA==

From: Krystian Hebel 

The tests validate that important parts of memory are protected against
DMA attacks, including Xen and MBI. Modules can be tested later, when it
is possible to report issues to a user before invoking TXT reset.

TPM event log validation is temporarily disabled due to an issue with
its allocation by bootloader (GRUB) which will need to be modified to
address this. Ultimately event log will also have to be validated early
as it is used immediately after these tests to hold MBI measurements.
See larger comment in txt_verify_pmr_ranges().

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/boot/slaunch-early.c    |   6 ++
 xen/arch/x86/include/asm/intel-txt.h | 112 +++++++++++++++++++++++++++
 2 files changed, 118 insertions(+)

diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
index c9d364bcd5..662144e42f 100644
--- a/xen/arch/x86/boot/slaunch-early.c
+++ b/xen/arch/x86/boot/slaunch-early.c
@@ -22,10 +22,13 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
     void *txt_heap;
     const struct txt_os_mle_data *os_mle;
     const struct slr_table *slrt;
+    const struct txt_os_sinit_data *os_sinit;
     const struct slr_entry_intel_info *intel_info;
+    uint32_t size = tgt_end_addr - tgt_base_addr;
 
     txt_heap = txt_init();
     os_mle = txt_os_mle_data_start(txt_heap);
+    os_sinit = txt_os_sinit_data_start(txt_heap);
 
     result->slrt_pa = os_mle->slrt;
     result->mbi_pa = 0;
@@ -38,4 +41,7 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
         return;
 
     result->mbi_pa = intel_info->boot_params_base;
+
+    txt_verify_pmr_ranges(os_mle, os_sinit, intel_info,
+                          load_base_addr, tgt_base_addr, size);
 }
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 7658457e9d..122b4293ea 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -93,6 +93,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include 
+
 /* Need to differentiate between pre- and post paging enabled. */
 #ifdef __EARLY_SLAUNCH__
 #include 
@@ -308,6 +310,116 @@ static inline void *txt_init(void)
     return txt_heap;
 }
 
+static inline int is_in_pmr(const struct txt_os_sinit_data *os_sinit,
+                            uint64_t base, uint32_t size, int check_high)
+{
+    /* Check for size overflow. */
+    if ( base + size < base )
+        txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
+
+    /* Low range always starts at 0, so its size is also end address. */
+    if ( base >= os_sinit->vtd_pmr_lo_base &&
+         base + size <= os_sinit->vtd_pmr_lo_size )
+        return 1;
+
+    if ( check_high && os_sinit->vtd_pmr_hi_size != 0 )
+    {
+        if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <
+             os_sinit->vtd_pmr_hi_size )
+            txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
+        if ( base >= os_sinit->vtd_pmr_hi_base &&
+             base + size <= os_sinit->vtd_pmr_hi_base +
+                            os_sinit->vtd_pmr_hi_size )
+            return 1;
+    }
+
+    return 0;
+}
+
+static inline void txt_verify_pmr_ranges(
+    const struct txt_os_mle_data *os_mle,
+    const struct txt_os_sinit_data *os_sinit,
+    const struct slr_entry_intel_info *info,
+    uint32_t load_base_addr,
+    uint32_t tgt_base_addr,
+    uint32_t xen_size)
+{
+    int check_high_pmr = 0;
+
+    /* Verify the value of the low PMR base. It should always be 0. */
+    if ( os_sinit->vtd_pmr_lo_base != 0 )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_BASE);
+
+    /*
+     * Low PMR size should not be 0 on current platforms. There is an ongoing
+     * transition to TPR-based DMA protection instead of PMR-based; this is not
+     * yet supported by the code.
+     */
+    if ( os_sinit->vtd_pmr_lo_size == 0 )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_SIZE);
+
+    /* Check if regions overlap. Treat regions with no hole between as error. */
+    if ( os_sinit->vtd_pmr_hi_size != 0 &&
+         os_sinit->vtd_pmr_hi_base <= os_sinit->vtd_pmr_lo_size )
+        txt_reset(SLAUNCH_ERROR_HI_PMR_BASE);
+
+    /* All regions accessed by 32b code must be below 4G. */
+    if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <=
+         0x100000000ULL )
+        check_high_pmr = 1;
+
+    /*
+     * ACM checks that TXT heap and MLE memory is protected against DMA. We have
+     * to check if MBI and whole Xen memory is protected. The latter is done in
+     * case bootloader failed to set whole image as MLE and to make sure that
+     * both pre- and post-relocation code is protected.
+     */
+
+    /* Check if all of Xen before relocation is covered by PMR. */
+    if ( !is_in_pmr(os_sinit, load_base_addr, xen_size, check_high_pmr) )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
+
+    /* Check if all of Xen after relocation is covered by PMR. */
+    if ( load_base_addr != tgt_base_addr &&
+         !is_in_pmr(os_sinit, tgt_base_addr, xen_size, check_high_pmr) )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
+
+    /*
+     * If present, check that MBI is covered by PMR. MBI starts with 'uint32_t
+     * total_size'.
+     */
+    if ( info->boot_params_base != 0 &&
+         !is_in_pmr(os_sinit, info->boot_params_base,
+                    *(uint32_t *)(uintptr_t)info->boot_params_base,
+                    check_high_pmr) )
+        txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
+
+    /* Check if TPM event log (if present) is covered by PMR. */
+    /*
+     * FIXME: currently commented out as GRUB allocates it in a hole between
+     * PMR and reserved RAM, due to 2MB resolution of PMR. There are no other
+     * easy-to-use DMA protection mechanisms that would allow to protect that
+     * part of memory. TPR (TXT DMA Protection Range) gives 1MB resolution, but
+     * it still wouldn't be enough.
+     *
+     * One possible solution would be for GRUB to allocate log at lower address,
+     * but this would further increase memory space fragmentation. Another
+     * option is to align PMR up instead of down, making PMR cover part of
+     * reserved region, but it is unclear what the consequences may be.
+     *
+     * In tboot this issue was resolved by reserving leftover chunks of memory
+     * in e820 and/or UEFI memory map. This is also a valid solution, but would
+     * require more changes to GRUB than the ones listed above, as event log is
+     * allocated much earlier than PMRs.
+     */
+    /*
+    if ( os_mle->evtlog_addr != 0 && os_mle->evtlog_size != 0 &&
+         !is_in_pmr(os_sinit, os_mle->evtlog_addr, os_mle->evtlog_size,
+                    check_high_pmr) )
+        txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
+    */
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* X86_INTEL_TXT_H */
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:18:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:18:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000937.1381166 (Exim 4.92)
	(envelope-from )
	id 1uKzdK-0001V4-Np; Fri, 30 May 2025 13:18:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000937.1381166; Fri, 30 May 2025 13:18: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 1uKzdK-0001Us-Jg; Fri, 30 May 2025 13:18:50 +0000
Received: by outflank-mailman (input) for mailman id 1000937;
 Fri, 30 May 2025 13:18:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdI-0008Jy-UG
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:18:49 +0000
Received: from 4.mo576.mail-out.ovh.net (4.mo576.mail-out.ovh.net
 [46.105.42.102]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9eb32284-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:18:48 +0200 (CEST)
Received: from director1.ghost.mail-out.ovh.net (unknown [10.108.25.252])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4b83j33X41z32V2
 for ; Fri, 30 May 2025 13:18:47 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-r8cb6 (unknown [10.110.118.183])
 by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id BDA71C4523;
 Fri, 30 May 2025 13:18:46 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.114])
 by ghost-submission-5b5ff79f4f-r8cb6 with ESMTPSA
 id HZerJTawOWi91goAdfCxkA
 (envelope-from ); Fri, 30 May 2025 13:18: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" 
X-Inumbo-ID: 9eb32284-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-114S008955e152b-4069-4f80-bee0-b9936b0ef95e,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 06/22] xen/arch/x86: reserve TXT memory during Slaunch
Date: Fri, 30 May 2025 16:17:48 +0300
Message-ID: <8d5ba2e7a0a8bd05bb9cdb89db3f15b831f7f4f7.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12697617674837472412
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduvdculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeegkeffieeitdevkefhudegffevieeggfelgedvgeehffdtteehfeeuleeiudekvdenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekgedrvddvuddpfeejrdehledrudegvddruddugeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehjeeimgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=Nf38lpeiCUvbLLteadUfdEVFOEAXLH0XFiAoqTSi818=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611127; v=1;
 b=dzUMtDoyKOU0Pn3wBrv6GNv6AvXgVZcONN70y/Fa52eEaV8APHKYIBZfRZ5P5cSR3XvmduBS
 FkRC7++v+5Q8edt/dfGfWy+TmCGS7wjH1RcLEpwFm1ib3WiLd70b+8cuYs2NitINj4DNfdhsdhM
 DX8PLEX0saHV9VEYrQFATBYf8j90PIRCq9f3Yo0ETW8HOKYk7XqTPXBduea4oFbT9x9iAEVxqop
 zQuv4MaDyjxzoFKIBh08xbe3i6gRfALEvPjejUfi3K2UGG8r60AB28d3KrDuAALMcFFrgoWvxa0
 EWBbjQTNdb0eGBFaT1VCV0f9tqtTEQMwNzmLYNsKxkB/w==

From: Kacper Stojek 

TXT heap, SINIT and TXT private space are marked as reserved or unused
in e820 to protect from unintended uses.

Signed-off-by: Kacper Stojek 
Signed-off-by: Krystian Hebel 
Signed-off-by: Michał Żygowski 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/Makefile                |   1 +
 xen/arch/x86/include/asm/intel-txt.h |   6 ++
 xen/arch/x86/include/asm/mm.h        |   3 +
 xen/arch/x86/include/asm/slaunch.h   |  44 +++++++++++
 xen/arch/x86/intel-txt.c             | 113 +++++++++++++++++++++++++++
 xen/arch/x86/setup.c                 |  10 ++-
 xen/arch/x86/slaunch.c               |  98 ++++++++++++++++++++++-
 7 files changed, 271 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/x86/intel-txt.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index aa20eb42b5..5788898166 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_GDBSX) += gdbsx.o
 obj-y += hypercall.o
 obj-y += i387.o
 obj-y += i8259.o
+obj-y += intel-txt.o
 obj-y += io_apic.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-y += msi.o
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 122b4293ea..ad3c41d86c 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -420,6 +420,12 @@ static inline void txt_verify_pmr_ranges(
     */
 }
 
+/* Prepares for accesses to TXT-specific memory. */
+void txt_map_mem_regions(void);
+
+/* Marks TXT-specific memory as used to avoid its corruption. */
+void txt_reserve_mem_regions(void);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* X86_INTEL_TXT_H */
diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index d6e80db71c..91fa95cd90 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -106,6 +106,9 @@
 #define _PGC_need_scrub   _PGC_allocated
 #define PGC_need_scrub    PGC_allocated
 
+/* How much of the directmap is prebuilt at compile time. */
+#define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT)
+
 #ifndef CONFIG_BIGMEM
 /*
  * This definition is solely for the use in struct page_info (and
diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
index df42defd92..7891d60035 100644
--- a/xen/arch/x86/include/asm/slaunch.h
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -7,6 +7,7 @@
 #ifndef X86_SLAUNCH_H
 #define X86_SLAUNCH_H
 
+#include 
 #include 
 
 /* Indicates an active Secure Launch boot. */
@@ -18,9 +19,52 @@ extern bool slaunch_active;
  */
 extern uint32_t slaunch_slrt;
 
+/*
+ * evt_log is assigned a physical address and the caller must map it to
+ * virtual, if needed.
+ */
+static inline void find_evt_log(const struct slr_table *slrt, void **evt_log,
+                                uint32_t *evt_log_size)
+{
+    const struct slr_entry_log_info *log_info;
+
+    log_info = (const struct slr_entry_log_info *)
+        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_LOG_INFO);
+    if ( log_info != NULL )
+    {
+        *evt_log = _p(log_info->addr);
+        *evt_log_size = log_info->size;
+    }
+    else
+    {
+        *evt_log = NULL;
+        *evt_log_size = 0;
+    }
+}
+
 /*
  * Retrieves pointer to SLRT.  Checks table's validity and maps it as necessary.
  */
 struct slr_table *slaunch_get_slrt(void);
 
+/*
+ * Prepares for accesses to essential data structures setup by boot environment.
+ */
+void slaunch_map_mem_regions(void);
+
+/* Marks regions of memory as used to avoid their corruption. */
+void slaunch_reserve_mem_regions(void);
+
+/*
+ * This helper function is used to map memory using L2 page tables by aligning
+ * mapped regions to 2MB. This way page allocator (which at this point isn't
+ * yet initialized) isn't needed for creating new L1 mappings. The function
+ * also checks and skips memory already mapped by the prebuilt tables.
+ *
+ * There is no unmap_l2() because the function is meant to be used by the code
+ * that accesses DRTM-related memory soon after which Xen rebuilds memory maps,
+ * effectively dropping all existing mappings.
+ */
+int slaunch_map_l2(unsigned long paddr, unsigned long size);
+
 #endif /* X86_SLAUNCH_H */
diff --git a/xen/arch/x86/intel-txt.c b/xen/arch/x86/intel-txt.c
new file mode 100644
index 0000000000..163383b262
--- /dev/null
+++ b/xen/arch/x86/intel-txt.c
@@ -0,0 +1,113 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static uint64_t __initdata txt_heap_base, txt_heap_size;
+
+void __init txt_map_mem_regions(void)
+{
+    int rc;
+
+    rc = slaunch_map_l2(TXT_PRIV_CONFIG_REGS_BASE, TXT_CONFIG_SPACE_SIZE);
+    BUG_ON(rc != 0);
+
+    txt_heap_base = txt_read(TXTCR_HEAP_BASE);
+    BUG_ON(txt_heap_base == 0);
+
+    txt_heap_size = txt_read(TXTCR_HEAP_SIZE);
+    BUG_ON(txt_heap_size == 0);
+
+    rc = slaunch_map_l2(txt_heap_base, txt_heap_size);
+    BUG_ON(rc != 0);
+}
+
+/* Mark RAM region as RESERVED if it isn't marked that way already. */
+static int __init mark_ram_as(struct e820map *map, uint64_t start,
+                              uint64_t end, uint32_t type)
+{
+    unsigned int i;
+    uint32_t from_type = E820_RAM;
+
+    for ( i = 0; i < map->nr_map; i++ )
+    {
+        uint64_t rs = map->map[i].addr;
+        uint64_t re = rs + map->map[i].size;
+
+        /* The entry includes the range. */
+        if ( start >= rs && end <= re )
+            break;
+
+        /* The entry intersects the range. */
+        if ( end > rs && start < re )
+        {
+            /* Fatal failure. */
+            return 0;
+        }
+    }
+
+    /*
+     * If the range is not included by any entry and no entry intersects it,
+     * then it's not listed in the memory map.  Consider this case as a success
+     * since we're only preventing RAM from being used and unlisted range should
+     * not be used.
+     */
+    if ( i == map->nr_map )
+        return 1;
+
+    /*
+     * e820_change_range_type() fails if the range is already marked with the
+     * desired type.  Don't consider it an error if firmware has done it for us.
+     */
+    if ( map->map[i].type == type )
+        return 1;
+
+    /* E820_ACPI or E820_NVS are really unexpected, but others are fine. */
+    if ( map->map[i].type == E820_RESERVED ||
+         map->map[i].type == E820_UNUSABLE )
+        from_type = map->map[i].type;
+
+    return e820_change_range_type(map, start, end, from_type, type);
+}
+
+void __init txt_reserve_mem_regions(void)
+{
+    int rc;
+    uint64_t sinit_base, sinit_size;
+
+    /* TXT Heap */
+    BUG_ON(txt_heap_base == 0);
+    printk("SLAUNCH: reserving TXT heap (%#lx - %#lx)\n", txt_heap_base,
+           txt_heap_base + txt_heap_size);
+    rc = mark_ram_as(&e820_raw, txt_heap_base, txt_heap_base + txt_heap_size,
+                     E820_RESERVED);
+    BUG_ON(rc == 0);
+
+    sinit_base = txt_read(TXTCR_SINIT_BASE);
+    BUG_ON(sinit_base == 0);
+
+    sinit_size = txt_read(TXTCR_SINIT_SIZE);
+    BUG_ON(sinit_size == 0);
+
+    /* SINIT */
+    printk("SLAUNCH: reserving SINIT memory (%#lx - %#lx)\n", sinit_base,
+           sinit_base + sinit_size);
+    rc = mark_ram_as(&e820_raw, sinit_base, sinit_base + sinit_size,
+                     E820_RESERVED);
+    BUG_ON(rc == 0);
+
+    /* TXT Private Space */
+    rc = mark_ram_as(&e820_raw, TXT_PRIV_CONFIG_REGS_BASE,
+                     TXT_PRIV_CONFIG_REGS_BASE + TXT_CONFIG_SPACE_SIZE,
+                     E820_UNUSABLE);
+    BUG_ON(rc == 0);
+}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1f5cb67bd0..e4638acd12 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1087,9 +1088,6 @@ static struct domain *__init create_dom0(struct boot_info *bi)
     return d;
 }
 
-/* How much of the directmap is prebuilt at compile time. */
-#define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT)
-
 void asmlinkage __init noreturn __start_xen(void)
 {
     const char *memmap_type = NULL;
@@ -1425,6 +1423,12 @@ void asmlinkage __init noreturn __start_xen(void)
 #endif
     }
 
+    if ( slaunch_active )
+    {
+        slaunch_map_mem_regions();
+        slaunch_reserve_mem_regions();
+    }
+
     /* Sanitise the raw E820 map to produce a final clean version. */
     max_page = raw_max_page = init_e820(memmap_type, &e820_raw);
 
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index a3e6ab8d71..ac3b43942b 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -7,14 +7,18 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 
 /*
  * These variables are assigned to by the code near Xen's entry point.
  *
  * slaunch_active is not __initdata to allow checking for an active Secure
- * Launch boot.
+ * Launch boot at any point.
  */
 bool slaunch_active;
 uint32_t __initdata slaunch_slrt; /* physical address */
@@ -25,3 +29,95 @@ static void __maybe_unused compile_time_checks(void)
 {
     BUILD_BUG_ON(sizeof(slaunch_active) != 1);
 }
+
+struct slr_table *__init slaunch_get_slrt(void)
+{
+    static struct slr_table *slrt;
+
+    if (slrt == NULL) {
+        int rc;
+
+        slrt = __va(slaunch_slrt);
+
+        rc = slaunch_map_l2(slaunch_slrt, PAGE_SIZE);
+        BUG_ON(rc != 0);
+
+        if ( slrt->magic != SLR_TABLE_MAGIC )
+            panic("SLRT has invalid magic value: %#08x!\n", slrt->magic);
+        /* XXX: are newer revisions allowed? */
+        if ( slrt->revision != SLR_TABLE_REVISION )
+            panic("SLRT is of unsupported revision: %#04x!\n", slrt->revision);
+        if ( slrt->architecture != SLR_INTEL_TXT )
+            panic("SLRT is for unexpected architecture: %#04x!\n",
+                  slrt->architecture);
+        if ( slrt->size > slrt->max_size )
+            panic("SLRT is larger than its max size: %#08x > %#08x!\n",
+                  slrt->size, slrt->max_size);
+
+        if ( slrt->size > PAGE_SIZE )
+        {
+            rc = slaunch_map_l2(slaunch_slrt, slrt->size);
+            BUG_ON(rc != 0);
+        }
+    }
+
+    return slrt;
+}
+
+void __init slaunch_map_mem_regions(void)
+{
+    void *evt_log_addr;
+    uint32_t evt_log_size;
+
+    /* Vendor-specific part. */
+    txt_map_mem_regions();
+
+    find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
+    if ( evt_log_addr != NULL )
+    {
+        int rc = slaunch_map_l2((uintptr_t)evt_log_addr, evt_log_size);
+        BUG_ON(rc != 0);
+    }
+}
+
+void __init slaunch_reserve_mem_regions(void)
+{
+    int rc;
+
+    void *evt_log_addr;
+    uint32_t evt_log_size;
+
+    /* Vendor-specific part. */
+    txt_reserve_mem_regions();
+
+    find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
+    if ( evt_log_addr != NULL )
+    {
+        printk("SLAUNCH: reserving event log (%#lx - %#lx)\n",
+               (uint64_t)evt_log_addr,
+               (uint64_t)evt_log_addr + evt_log_size);
+        rc = reserve_e820_ram(&e820_raw, (uint64_t)evt_log_addr,
+                              (uint64_t)evt_log_addr + evt_log_size);
+        BUG_ON(rc == 0);
+    }
+}
+
+int __init slaunch_map_l2(unsigned long paddr, unsigned long size)
+{
+    unsigned long aligned_paddr = paddr & ~((1ULL << L2_PAGETABLE_SHIFT) - 1);
+    unsigned long pages = ((paddr + size) - aligned_paddr);
+    pages = ROUNDUP(pages, 1ULL << L2_PAGETABLE_SHIFT) >> PAGE_SHIFT;
+
+    if ( aligned_paddr + pages * PAGE_SIZE <= PREBUILT_MAP_LIMIT )
+        return 0;
+
+    if ( aligned_paddr < PREBUILT_MAP_LIMIT )
+    {
+        pages -= (PREBUILT_MAP_LIMIT - aligned_paddr) >> PAGE_SHIFT;
+        aligned_paddr = PREBUILT_MAP_LIMIT;
+    }
+
+    return map_pages_to_xen((uintptr_t)__va(aligned_paddr),
+                            maddr_to_mfn(aligned_paddr),
+                            pages, PAGE_HYPERVISOR);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:18:53 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:18:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000939.1381175 (Exim 4.92)
	(envelope-from )
	id 1uKzdM-0001o3-UB; Fri, 30 May 2025 13:18:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000939.1381175; Fri, 30 May 2025 13:18: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 1uKzdM-0001nr-R6; Fri, 30 May 2025 13:18:52 +0000
Received: by outflank-mailman (input) for mailman id 1000939;
 Fri, 30 May 2025 13:18:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdL-0008Jy-RY
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:18:51 +0000
Received: from 17.mo561.mail-out.ovh.net (17.mo561.mail-out.ovh.net
 [87.98.178.58]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a0779712-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:18:50 +0200 (CEST)
Received: from director9.ghost.mail-out.ovh.net (unknown [10.108.25.252])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4b83j623d7z1TGn
 for ; Fri, 30 May 2025 13:18:50 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-kbk5q (unknown [10.110.164.164])
 by director9.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 8FAE58498F;
 Fri, 30 May 2025 13:18:49 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.96])
 by ghost-submission-5b5ff79f4f-kbk5q with ESMTPSA
 id Gn6JDjmwOWg+tAAARlXHSA
 (envelope-from ); Fri, 30 May 2025 13:18: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" 
X-Inumbo-ID: a0779712-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-96R001935d236c-c23a-46fa-83b9-c100e535bc6e,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 07/22] x86/mtrr: expose functions for pausing caching
Date: Fri, 30 May 2025 16:17:49 +0300
Message-ID: <8d6e871f055c2456ab194e49bd470eafd04e454e.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12698462102722688156
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhephfehfeehudeileeikeffgfffgfefuddtveelvedvhfffgfelvdfgtddutdehfeeinecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdelieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehiedumgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=p5/X8odYi3YN7N37QJCMftuc5hqSiV9vDM1ybqq3iiI=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611130; v=1;
 b=Aiqs0UheTfDL8AWg3gjFuTcW2oP2wzTA8ZmsvhoLDGbS1fV9zG+lGtq6QSzMu1DqiYV/1dh6
 xwdDJJJ01w+6RDY+TPEb7KxNczTJvKigPVqC5Jnvoo6SWzN31hY8pYux59K1BMRjpQKImuGQhNK
 4LxoTe+3dTFlwhrgjBCwRqgxb+X2gnCj/k2cXWD2t3P8HuE/IE+0G8SKuQRo3DIBZYMmY3BheuB
 2wjeGk88cIRKdXiyQuGuQf5+THQBQx44Hjb30r7feVHX4lSl18WybfveM6RuqDFjcoYSoZlubDf
 UesS9HFaE2w+CdB4T/LIC+lzP8JCcaVlFFOkvXmARcu6A==

This allows the functionality to be reused by other units that need to
update MTRRs.

This also gets rid of a static variable.

Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/cpu/mtrr/generic.c | 51 ++++++++++++++++-----------------
 xen/arch/x86/include/asm/mtrr.h |  8 ++++++
 2 files changed, 33 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index c587e9140e..2a8dd1d8ff 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -396,9 +396,7 @@ static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
 	return changed;
 }
 
-static uint64_t deftype;
-
-static unsigned long set_mtrr_state(void)
+static unsigned long set_mtrr_state(uint64_t *deftype)
 /*  [SUMMARY] Set the MTRR state for this CPU.
      The MTRR state information to read.
      Some relevant CPU context.
@@ -416,14 +414,12 @@ static unsigned long set_mtrr_state(void)
 	if (mtrr_state.have_fixed && set_fixed_ranges(mtrr_state.fixed_ranges))
 		change_mask |= MTRR_CHANGE_MASK_FIXED;
 
-	/*  Set_mtrr_restore restores the old value of MTRRdefType,
-	   so to set it we fiddle with the saved value  */
-	if ((deftype & 0xff) != mtrr_state.def_type
-	    || MASK_EXTR(deftype, MTRRdefType_E) != mtrr_state.enabled
-	    || MASK_EXTR(deftype, MTRRdefType_FE) != mtrr_state.fixed_enabled) {
-		deftype = (deftype & ~0xcff) | mtrr_state.def_type |
-		          MASK_INSR(mtrr_state.enabled, MTRRdefType_E) |
-		          MASK_INSR(mtrr_state.fixed_enabled, MTRRdefType_FE);
+	if ((*deftype & 0xff) != mtrr_state.def_type
+	    || MASK_EXTR(*deftype, MTRRdefType_E) != mtrr_state.enabled
+	    || MASK_EXTR(*deftype, MTRRdefType_FE) != mtrr_state.fixed_enabled) {
+		*deftype = (*deftype & ~0xcff) | mtrr_state.def_type |
+		           MASK_INSR(mtrr_state.enabled, MTRRdefType_E) |
+		           MASK_INSR(mtrr_state.fixed_enabled, MTRRdefType_FE);
 		change_mask |= MTRR_CHANGE_MASK_DEFTYPE;
 	}
 
@@ -440,9 +436,10 @@ static DEFINE_SPINLOCK(set_atomicity_lock);
  * has been called.
  */
 
-static bool prepare_set(void)
+struct mtrr_pausing_state mtrr_pause_caching(void)
 {
 	unsigned long cr4;
+	struct mtrr_pausing_state state;
 
 	/*  Note that this is not ideal, since the cache is only flushed/disabled
 	   for this CPU while the MTRRs are changed, but changing this requires
@@ -462,7 +459,9 @@ static bool prepare_set(void)
 	alternative("wbinvd", "", X86_FEATURE_XEN_SELFSNOOP);
 
 	cr4 = read_cr4();
-	if (cr4 & X86_CR4_PGE)
+	state.pge = cr4 & X86_CR4_PGE;
+
+	if (state.pge)
 		write_cr4(cr4 & ~X86_CR4_PGE);
 	else if (use_invpcid)
 		invpcid_flush_all();
@@ -470,27 +469,27 @@ static bool prepare_set(void)
 		write_cr3(read_cr3());
 
 	/*  Save MTRR state */
-	rdmsrl(MSR_MTRRdefType, deftype);
+	rdmsrl(MSR_MTRRdefType, state.def_type);
 
 	/*  Disable MTRRs, and set the default type to uncached  */
-	mtrr_wrmsr(MSR_MTRRdefType, deftype & ~0xcff);
+	mtrr_wrmsr(MSR_MTRRdefType, state.def_type & ~0xcff);
 
 	/* Again, only flush caches if we have to. */
 	alternative("wbinvd", "", X86_FEATURE_XEN_SELFSNOOP);
 
-	return cr4 & X86_CR4_PGE;
+	return state;
 }
 
-static void post_set(bool pge)
+void mtrr_resume_caching(struct mtrr_pausing_state state)
 {
 	/* Intel (P6) standard MTRRs */
-	mtrr_wrmsr(MSR_MTRRdefType, deftype);
+	mtrr_wrmsr(MSR_MTRRdefType, state.def_type);
 
 	/*  Enable caches  */
 	write_cr0(read_cr0() & ~X86_CR0_CD);
 
 	/*  Reenable CR4.PGE (also flushes the TLB) */
-	if (pge)
+	if (state.pge)
 		write_cr4(read_cr4() | X86_CR4_PGE);
 	else if (use_invpcid)
 		invpcid_flush_all();
@@ -504,15 +503,15 @@ void mtrr_set_all(void)
 {
 	unsigned long mask, count;
 	unsigned long flags;
-	bool pge;
+	struct mtrr_pausing_state pausing_state;
 
 	local_irq_save(flags);
-	pge = prepare_set();
+	pausing_state = mtrr_pause_caching();
 
 	/* Actually set the state */
-	mask = set_mtrr_state();
+	mask = set_mtrr_state(&pausing_state.def_type);
 
-	post_set(pge);
+	mtrr_resume_caching(pausing_state);
 	local_irq_restore(flags);
 
 	/*  Use the atomic bitops to update the global mask  */
@@ -537,12 +536,12 @@ void mtrr_set(
 {
 	unsigned long flags;
 	struct mtrr_var_range *vr;
-	bool pge;
+	struct mtrr_pausing_state pausing_state;
 
 	vr = &mtrr_state.var_ranges[reg];
 
 	local_irq_save(flags);
-	pge = prepare_set();
+	pausing_state = mtrr_pause_caching();
 
 	if (size == 0) {
 		/* The invalid bit is kept in the mask, so we simply clear the
@@ -563,7 +562,7 @@ void mtrr_set(
 		mtrr_wrmsr(MSR_IA32_MTRR_PHYSMASK(reg), vr->mask);
 	}
 
-	post_set(pge);
+	mtrr_resume_caching(pausing_state);
 	local_irq_restore(flags);
 }
 
diff --git a/xen/arch/x86/include/asm/mtrr.h b/xen/arch/x86/include/asm/mtrr.h
index 25d442659d..82ea427ba0 100644
--- a/xen/arch/x86/include/asm/mtrr.h
+++ b/xen/arch/x86/include/asm/mtrr.h
@@ -66,6 +66,14 @@ extern uint8_t pat_type_2_pte_flags(uint8_t pat_type);
 extern void mtrr_aps_sync_begin(void);
 extern void mtrr_aps_sync_end(void);
 
+struct mtrr_pausing_state {
+	bool pge;
+	uint64_t def_type;
+};
+
+extern struct mtrr_pausing_state mtrr_pause_caching(void);
+extern void mtrr_resume_caching(struct mtrr_pausing_state state);
+
 extern bool mtrr_var_range_msr_set(struct domain *d, struct mtrr_state *m,
                                    uint32_t msr, uint64_t msr_content);
 extern bool mtrr_fix_range_msr_set(struct domain *d, struct mtrr_state *m,
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:19:20 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:19:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000951.1381186 (Exim 4.92)
	(envelope-from )
	id 1uKzdo-0003cu-BB; Fri, 30 May 2025 13:19:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000951.1381186; Fri, 30 May 2025 13:19: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 1uKzdo-0003cn-7d; Fri, 30 May 2025 13:19:20 +0000
Received: by outflank-mailman (input) for mailman id 1000951;
 Fri, 30 May 2025 13:19:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdn-0003ZU-26
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:19 +0000
Received: from 10.mo582.mail-out.ovh.net (10.mo582.mail-out.ovh.net
 [87.98.157.236]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a4170f4e-3d58-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:18:56 +0200 (CEST)
Received: from director8.ghost.mail-out.ovh.net (unknown [10.109.140.35])
 by mo582.mail-out.ovh.net (Postfix) with ESMTP id 4b83jD4Vjdz1SmT
 for ; Fri, 30 May 2025 13:18:56 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-9nq6m (unknown [10.108.42.28])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 66338C0276;
 Fri, 30 May 2025 13:18:55 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.110])
 by ghost-submission-5b5ff79f4f-9nq6m with ESMTPSA
 id w09eBz+wOWgo8QAAj53byA
 (envelope-from ); Fri, 30 May 2025 13:18: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" 
X-Inumbo-ID: a4170f4e-3d58-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-110S004e213af52-45b3-49a3-b1b6-7b97c322dceb,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
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 ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 09/22] xen/lib: add implementation of SHA-1
Date: Fri, 30 May 2025 16:17:51 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12700150950728086684
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -110
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculddquddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvedvgfeukeehhfevuddvheetudekkefggfeiveehvefhgfehgfffhffgvefhudejnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpnhhishhtrdhgohhvnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduuddtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekvdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=K3Dew7MrO0ilxuikP+BcmF7QZioZCbjXXYgwGcnqPdk=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611136; v=1;
 b=PdZw+hQFIYx7PC+k/ctBqeINiD2mnpzbA1VGm6XEnnkFD1DSWdx+OLK7cPak4cye9xCHjy6V
 +6XvolUAOl1tfjKtITbQ2b3cfdvd9AnrfqF33F9jLU0tIbi6h3Rk4GhgD6fm0fp7/JTyp+/2HfR
 PCRXJPFAda9x0wOGO9NbWogP6WhKUep0f6FClfzLLizSiE0ymMy61DOFpdQXsR/zN/K7sg2aJec
 o3ZKpREmvB51N3TfXQLA0AiF6LZWc4f2wCUYd6lFYGhABQQ9y3FwnlbL51oeIDHy9Rc43FMPc1n
 GAAvjH9rHZYB0o92fMSWA5duwB7oPMbDAckHVz/RXnZXg==

From: Krystian Hebel 

The code comes from [1] and is licensed under GPL-2.0 license.
The initial version was a combination of:
 - include/crypto/sha1.h
 - include/crypto/sha1_base.h
 - lib/crypto/sha1.c
 - crypto/sha1_generic.c

Changes:
 - includes, formatting, naming
 - renames and splicing of some trivial functions that are called once
 - dropping of `int` return values (only zero was ever returned)
 - getting rid of references to `struct shash_desc`
 - getting rid of macros
 - getting rid of unnecessary function pointers
 - removing workaround for some old version of GCC

[1]: https://github.com/torvalds/linux/tree/afdab700f65e14070d8ab92175544b1c62b8bf03

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/include/xen/sha1.h |  14 +++
 xen/lib/Makefile       |   1 +
 xen/lib/sha1.c         | 190 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 205 insertions(+)
 create mode 100644 xen/include/xen/sha1.h
 create mode 100644 xen/lib/sha1.c

diff --git a/xen/include/xen/sha1.h b/xen/include/xen/sha1.h
new file mode 100644
index 0000000000..909ca25a50
--- /dev/null
+++ b/xen/include/xen/sha1.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * SHA1: https://csrc.nist.gov/pubs/fips/180-4/upd1/final
+ */
+#ifndef XEN_SHA1_H
+#define XEN_SHA1_H
+
+#include 
+
+#define SHA1_DIGEST_SIZE  20
+
+void sha1_hash(uint8_t digest[SHA1_DIGEST_SIZE], const void *msg, size_t len);
+
+#endif /* XEN_SHA1_H */
diff --git a/xen/lib/Makefile b/xen/lib/Makefile
index 5ccb1e5241..fd4b9ece63 100644
--- a/xen/lib/Makefile
+++ b/xen/lib/Makefile
@@ -17,6 +17,7 @@ lib-y += memset.o
 lib-y += muldiv64.o
 lib-y += parse-size.o
 lib-y += rbtree.o
+lib-$(CONFIG_X86) += sha1.o
 lib-$(CONFIG_X86) += sha2-256.o
 lib-y += sort.o
 lib-y += strcasecmp.o
diff --git a/xen/lib/sha1.c b/xen/lib/sha1.c
new file mode 100644
index 0000000000..c25f0b9309
--- /dev/null
+++ b/xen/lib/sha1.c
@@ -0,0 +1,190 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * SHA1 routine optimized to do word accesses rather than byte accesses,
+ * and to avoid unnecessary copies into the context array.
+ *
+ * This was based on the git SHA1 implementation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SHA1_BLOCK_SIZE         64
+#define SHA1_WORKSPACE_WORDS    16
+#define SHA1_WORKSPACE_MASK     (SHA1_WORKSPACE_WORDS - 1)
+
+struct sha1_state {
+    uint64_t count;
+    uint32_t state[SHA1_DIGEST_SIZE / 4];
+    uint8_t buffer[SHA1_BLOCK_SIZE];
+};
+
+/* This "rolls" over the 512-bit array named w */
+#define W(i) w[(i) & SHA1_WORKSPACE_MASK]
+
+static uint32_t blend(const uint32_t w[SHA1_WORKSPACE_WORDS], size_t i)
+{
+    return rol32(W(i + 13) ^ W(i + 8) ^ W(i + 2) ^ W(i), 1);
+}
+
+/**
+ * sha1_transform - single block SHA1 transform
+ *
+ * @digest: 160 bit digest to update
+ * @data:   512 bits of data to hash
+ *
+ * This function executes SHA-1's internal compression function.  It updates the
+ * 160-bit internal state (@digest) with a single 512-bit data block (@data).
+ */
+static void sha1_transform(uint32_t *digest, const uint8_t *data)
+{
+    uint32_t a, b, c, d, e, t;
+    uint32_t w[SHA1_WORKSPACE_WORDS];
+    unsigned int i = 0;
+
+    a = digest[0];
+    b = digest[1];
+    c = digest[2];
+    d = digest[3];
+    e = digest[4];
+
+    /* Round 1 - iterations 0-16 take their input from 'data' */
+    for ( ; i < 16; ++i )
+    {
+        t = get_unaligned_be32((uint32_t *)data + i);
+        W(i) = t;
+        e += t + rol32(a, 5) + (((c ^ d) & b) ^ d) + 0x5a827999U;
+        b = ror32(b, 2);
+        t = e; e = d; d = c; c = b; b = a; a = t;
+    }
+
+    /* Round 1 - tail. Input from 512-bit mixing array */
+    for ( ; i < 20; ++i )
+    {
+        t = blend(w, i);
+        W(i) = t;
+        e += t + rol32(a, 5) + (((c ^ d) & b) ^ d) + 0x5a827999U;
+        b = ror32(b, 2);
+        t = e; e = d; d = c; c = b; b = a; a = t;
+    }
+
+    /* Round 2 */
+    for ( ; i < 40; ++i )
+    {
+        t = blend(w, i);
+        W(i) = t;
+        e += t + rol32(a, 5) + (b ^ c ^ d) + 0x6ed9eba1U;
+        b = ror32(b, 2);
+        t = e; e = d; d = c; c = b; b = a; a = t;
+    }
+
+    /* Round 3 */
+    for ( ; i < 60; ++i )
+    {
+        t = blend(w, i);
+        W(i) = t;
+        e += t + rol32(a, 5) + ((b & c) + (d & (b ^ c))) + 0x8f1bbcdcU;
+        b = ror32(b, 2);
+        t = e; e = d; d = c; c = b; b = a; a = t;
+    }
+
+    /* Round 4 */
+    for ( ; i < 80; ++i )
+    {
+        t = blend(w, i);
+        W(i) = t;
+        e += t + rol32(a, 5) + (b ^ c ^ d) + 0xca62c1d6U;
+        b = ror32(b, 2);
+        t = e; e = d; d = c; c = b; b = a; a = t;
+    }
+
+    digest[0] += a;
+    digest[1] += b;
+    digest[2] += c;
+    digest[3] += d;
+    digest[4] += e;
+}
+
+static void sha1_init(struct sha1_state *sctx)
+{
+    sctx->state[0] = 0x67452301UL;
+    sctx->state[1] = 0xefcdab89UL;
+    sctx->state[2] = 0x98badcfeUL;
+    sctx->state[3] = 0x10325476UL;
+    sctx->state[4] = 0xc3d2e1f0UL;
+    sctx->count = 0;
+}
+
+static void sha1_update(struct sha1_state *sctx, const uint8_t *msg, size_t len)
+{
+    unsigned int partial = sctx->count % SHA1_BLOCK_SIZE;
+
+    sctx->count += len;
+
+    if ( (partial + len) >= SHA1_BLOCK_SIZE )
+    {
+        if ( partial )
+        {
+            unsigned int rem = SHA1_BLOCK_SIZE - partial;
+
+            /* Fill the partial block. */
+            memcpy(sctx->buffer + partial, msg, rem);
+            msg += rem;
+            len -= rem;
+
+            sha1_transform(sctx->state, sctx->buffer);
+        }
+
+        for ( ; len >= SHA1_BLOCK_SIZE; len -= SHA1_BLOCK_SIZE )
+        {
+            sha1_transform(sctx->state, msg);
+            msg += SHA1_BLOCK_SIZE;
+        }
+        partial = 0;
+    }
+
+    /* Remaining data becomes partial. */
+    memcpy(sctx->buffer + partial, msg, len);
+}
+
+static void sha1_final(struct sha1_state *sctx, uint8_t out[SHA1_DIGEST_SIZE])
+{
+    const int bit_offset = SHA1_BLOCK_SIZE - sizeof(__be64);
+    unsigned int partial = sctx->count % SHA1_BLOCK_SIZE;
+
+    __be32 *digest = (__be32 *)out;
+    unsigned int i;
+
+    /* Start padding */
+    sctx->buffer[partial++] = 0x80;
+
+    if ( partial > bit_offset )
+    {
+        /* Need one extra block, so properly pad this one with zeroes */
+        memset(sctx->buffer + partial, 0x0, SHA1_BLOCK_SIZE - partial);
+        sha1_transform(sctx->state, sctx->buffer);
+        partial = 0;
+    }
+    /* Pad up to the location of the bit count */
+    memset(sctx->buffer + partial, 0x0, bit_offset - partial);
+
+    /* Append the bit count */
+    put_unaligned_be64(sctx->count << 3, &sctx->buffer[bit_offset]);
+    sha1_transform(sctx->state, sctx->buffer);
+
+    /* Store state in digest */
+    for ( i = 0; i < SHA1_DIGEST_SIZE / sizeof(__be32); i++ )
+        put_unaligned_be32(sctx->state[i], &digest[i]);
+}
+
+void sha1_hash(uint8_t digest[SHA1_DIGEST_SIZE], const void *msg, size_t len)
+{
+    struct sha1_state sctx;
+
+    sha1_init(&sctx);
+    sha1_update(&sctx, msg, len);
+    sha1_final(&sctx, digest);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:19:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:19:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000952.1381196 (Exim 4.92)
	(envelope-from )
	id 1uKzdp-0003sX-HG; Fri, 30 May 2025 13:19:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000952.1381196; Fri, 30 May 2025 13:19: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 1uKzdp-0003sM-EF; Fri, 30 May 2025 13:19:21 +0000
Received: by outflank-mailman (input) for mailman id 1000952;
 Fri, 30 May 2025 13:19:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdo-0003ZU-28
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:20 +0000
Received: from 2.mo582.mail-out.ovh.net (2.mo582.mail-out.ovh.net
 [46.105.76.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id acbbac5f-3d58-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:19:11 +0200 (CEST)
Received: from director8.ghost.mail-out.ovh.net (unknown [10.109.176.180])
 by mo582.mail-out.ovh.net (Postfix) with ESMTP id 4b83jW1B83z1YBR
 for ; Fri, 30 May 2025 13:19:11 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-sqt8x (unknown [10.108.42.198])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 7555FC0286;
 Fri, 30 May 2025 13:19:10 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.110])
 by ghost-submission-5b5ff79f4f-sqt8x with ESMTPSA
 id +3vSCk6wOWjKxgAAsdTabg
 (envelope-from ); Fri, 30 May 2025 13:19: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" 
X-Inumbo-ID: acbbac5f-3d58-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-110S004aa21ae74-13c6-44dd-aa83-995d3ec55e96,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 14/22] x86/boot: choose AP stack based on APIC ID
Date: Fri, 30 May 2025 16:17:56 +0300
Message-ID: <16a5438f73a026d4db1a5340f599d4839c74fcc6.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12704373077045261468
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepveelieehudellefgleegieevteegudfhhefffefghfeltdevhfelvdfgkeefhfeunecuffhomhgrihhnpehhvggrugdrshgspdhtrhgrmhhpohhlihhnvgdrshgspdigkeeipgeigedrshgsnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduuddtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekvdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=ez/L2d75KfUHpHUpt0ebohb99nk9msXfBgDhtfciYEI=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611151; v=1;
 b=fi1gQgNbRQp0Yg5FRfZNGxUVBwnr6X0Ko8aZAbamWXVf53GH80iAa1FSdeDs3hGeZZtA2Xqf
 AKTBKxOEnQ+BppxveurAbKecRBTlhfAwskWw5MKwiwx1lKfBmVVu7jL8dvKB0kBpxes1TlhwMHw
 BTN4lfsJO+/8z28AfZguSZX7FYNKKvzOWmzgojHVDsKCcP3e1IpgzckxYR2vE6lnb1Fjg++XMTh
 /XZHFlekMFJxskCLj2QlHAt63YEV56osLIQoWRXDBFsKI2hIF+SEhFtuN0Egyws0ylrBeP6D0IX
 VwGJb2KBdWChpiDnooCKYFV4vO1UeuXMZppTKlFFo4NFQ==

From: Krystian Hebel 

This is made as the first step of making parallel AP bring-up possible.
It should be enough for pre-C code.

Parallel AP bring-up is necessary because TXT by design releases all APs
at once. In addition to that it reduces number of IPIs (and more
importantly, delays between them) required to start all logical
processors. This results in significant reduction of boot time, even
when DRTM is not used, with performance gain growing with the number of
logical CPUs.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/boot/head.S             |  1 +
 xen/arch/x86/boot/trampoline.S       | 21 +++++++++++++++++++++
 xen/arch/x86/boot/x86_64.S           | 28 +++++++++++++++++++++++++++-
 xen/arch/x86/include/asm/apicdef.h   |  4 ++++
 xen/arch/x86/include/asm/msr-index.h |  3 +++
 xen/arch/x86/setup.c                 |  7 +++++++
 6 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 9a272155e9..7376fa85d5 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index a92e399fbe..ed593acc46 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -71,6 +71,27 @@ trampoline_protmode_entry:
         mov     $X86_CR4_PAE,%ecx
         mov     %ecx,%cr4
 
+        /*
+         * Get APIC ID while we're in non-paged mode. Start by checking if
+         * x2APIC is enabled.
+         */
+        mov     $MSR_APIC_BASE, %ecx
+        rdmsr
+        test    $APIC_BASE_EXTD, %eax
+        jnz     .Lx2apic
+
+        /* Not x2APIC, read from MMIO */
+        and     $APIC_BASE_ADDR_MASK, %eax
+        mov     APIC_ID(%eax), %esp
+        shr     $24, %esp
+        jmp     1f
+
+.Lx2apic:
+        mov     $(MSR_X2APIC_FIRST + (APIC_ID >> MSR_X2APIC_SHIFT)), %ecx
+        rdmsr
+        mov     %eax, %esp
+1:
+
         /* Load pagetable base register. */
         mov     $sym_offs(idle_pg_table),%eax
         add     bootsym_rel(trampoline_xen_phys_start,4,%eax)
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 08ae97e261..ac33576d8f 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -15,7 +15,33 @@ ENTRY(__high_start)
         mov     $XEN_MINIMAL_CR4,%rcx
         mov     %rcx,%cr4
 
-        mov     stack_start(%rip),%rsp
+        test    %ebx,%ebx
+        cmovz   stack_start(%rip), %rsp
+        jz      .L_stack_set
+
+        /* APs only: get stack base from APIC ID saved in %esp. */
+        mov     $-1, %rax
+        lea     x86_cpu_to_apicid(%rip), %rcx
+1:
+        add     $1, %rax
+        cmp     $NR_CPUS, %eax
+        jb      2f
+        hlt
+2:
+        cmp     %esp, (%rcx, %rax, 4)
+        jne     1b
+
+        /* %eax is now Xen CPU index. */
+        lea     stack_base(%rip), %rcx
+        mov     (%rcx, %rax, 8), %rsp
+
+        test    %rsp,%rsp
+        jnz     1f
+        hlt
+1:
+        add     $(STACK_SIZE - CPUINFO_sizeof), %rsp
+
+.L_stack_set:
 
         /* Reset EFLAGS (subsumes CLI and CLD). */
         pushq   $0
diff --git a/xen/arch/x86/include/asm/apicdef.h b/xen/arch/x86/include/asm/apicdef.h
index 63dab01dde..e093a2aa3c 100644
--- a/xen/arch/x86/include/asm/apicdef.h
+++ b/xen/arch/x86/include/asm/apicdef.h
@@ -121,6 +121,10 @@
 
 #define MAX_IO_APICS 128
 
+#ifndef __ASSEMBLY__
+
 extern bool x2apic_enabled;
 
+#endif /* !__ASSEMBLY__ */
+
 #endif
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 6f2c3147e3..73be38da17 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -172,6 +172,9 @@
 #define MSR_X2APIC_FIRST                    0x00000800
 #define MSR_X2APIC_LAST                     0x000008ff
 
+/* MSR offset can be obtained by shifting MMIO offset this number of bits to the right. */
+#define MSR_X2APIC_SHIFT                    4
+
 #define MSR_X2APIC_TPR                      0x00000808
 #define MSR_X2APIC_PPR                      0x0000080a
 #define MSR_X2APIC_EOI                      0x0000080b
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e4638acd12..87e4693a11 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -2097,6 +2097,7 @@ void asmlinkage __init noreturn __start_xen(void)
      */
     if ( !pv_shim )
     {
+        /* Separate loop to make parallel AP bringup possible. */
         for_each_present_cpu ( i )
         {
             /* Set up cpu_to_node[]. */
@@ -2104,6 +2105,12 @@ void asmlinkage __init noreturn __start_xen(void)
             /* Set up node_to_cpumask based on cpu_to_node[]. */
             numa_add_cpu(i);
 
+            if ( stack_base[i] == NULL )
+                stack_base[i] = cpu_alloc_stack(i);
+        }
+
+        for_each_present_cpu ( i )
+        {
             if ( (park_offline_cpus || num_online_cpus() < max_cpus) &&
                  !cpu_online(i) )
             {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:19:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:19:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000953.1381206 (Exim 4.92)
	(envelope-from )
	id 1uKzdq-00048k-Nm; Fri, 30 May 2025 13:19:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000953.1381206; Fri, 30 May 2025 13:19:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKzdq-00048X-Kk; Fri, 30 May 2025 13:19:22 +0000
Received: by outflank-mailman (input) for mailman id 1000953;
 Fri, 30 May 2025 13:19:21 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdp-0003ZU-28
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:21 +0000
Received: from 11.mo581.mail-out.ovh.net (11.mo581.mail-out.ovh.net
 [87.98.173.157]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aec1e352-3d58-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:19:14 +0200 (CEST)
Received: from director8.ghost.mail-out.ovh.net (unknown [10.109.176.180])
 by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4b83jZ30WQz1Yxh
 for ; Fri, 30 May 2025 13:19:14 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-5d8n2 (unknown [10.111.174.164])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 39E9EC024C;
 Fri, 30 May 2025 13:19:13 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.111])
 by ghost-submission-5b5ff79f4f-5d8n2 with ESMTPSA
 id pQ4+OFCwOWjaBgAA4lxFtg
 (envelope-from ); Fri, 30 May 2025 13:19: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" 
X-Inumbo-ID: aec1e352-3d58-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-111S0054b49fc25-ab36-4bb2-9224-4168f55b003f,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 15/22] x86/smpboot.c: TXT AP bringup
Date: Fri, 30 May 2025 16:17:57 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12705217499186640028
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepgeeguedvvdettdetvedujeejiedtfefhteekgeegffffleefiedvffduledtiefhnecuffhomhgrihhnpehtrhgrmhhpohhlihhnvgdrshgsnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduuddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekudgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=gr1rPrDMI12BQGKfWWI47H6s2RO9Y2JqlRCdgepLO2s=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611154; v=1;
 b=Vxf6RhrwCxqkvQJezXfDi2WLBdjKF6Twig33138h07zBOd5pvSHlqX3Fx6o+3aiUz3pe2lKs
 hAzCw74Gd9pI83+NTYGfqnTHm4D4BymoNxlep9zsdNXq7p4E+Ju6eYBuJJqdZCtL3lgzpfaZF0g
 9hRMn9rlql/gx+HxQXyn3qzCIiIeNZC2BJ4tP2C6KT0m6BNWJvQ7hY/bkqgNDowuSTrx9A4mbfS
 bZt8VHBB++H75Xttax3p+88L/IturEkeut4bwmm6vLOpgqK6PAvaa5z+t6lzo0ylnQxxvLi/npz
 MREedbh55kw5YYFb/nFrPQAMfF2qT0439iIkrisfGBoRg==

From: Krystian Hebel 

On Intel TXT, APs are started in one of two ways, depending on ACM
which reports it in its information table. In both cases, all APs are
started simultaneously after BSP requests them to do so. Two possible
ways are:
- GETSEC[WAKEUP] instruction,
- MONITOR address.

GETSEC[WAKEUP] requires versions >= 7 of SINIT to MLE Data, but there is
no clear mapping of that version with regard to processor family and
it's not known which CPUs actually use it. It could have been designed
for TXT support on CPUs that lack MONITOR/MWAIT, because GETSEC[WAKEUP]
seems to be more complicated, in software and hardware alike.

This patch implements only MONITOR approach, GETSEC[WAKEUP] support will
be added later once more details and means of testing are available and
if there is a practical need for it.

With this patch, every AP goes through assembly part, and only when in
start_secondary() in C they re-enter MONITOR/MWAIT iff they are not the
AP that was asked to boot. The same address is reused for simplicity,
and on next wakeup call APs don't have to go through assembly part
again (GDT, paging, stack setting).

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/boot/trampoline.S       | 19 ++++++++-
 xen/arch/x86/include/asm/intel-txt.h |  6 +++
 xen/arch/x86/include/asm/processor.h |  1 +
 xen/arch/x86/smpboot.c               | 63 ++++++++++++++++++++++++++++
 4 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index ed593acc46..8cd9881828 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -58,6 +58,16 @@ GLOBAL(entry_SIPI16)
         ljmpl   $BOOT_CS32,$bootsym_rel(trampoline_protmode_entry,6)
 
         .code32
+GLOBAL(txt_ap_entry)
+        /*
+         * APs enter here in protected mode without paging. GDT is set in JOIN
+         * structure, it points to trampoline_gdt. Interrupts are disabled by
+         * TXT (including NMI and SMI), so IDT doesn't matter at this point.
+         * The only missing point is telling that we are AP by saving non-zero
+         * value in EBX.
+         */
+        mov     $1, %ebx
+
 trampoline_protmode_entry:
         /* Set up a few descriptors: on entry only CS is guaranteed good. */
         mov     $BOOT_DS,%eax
@@ -143,7 +153,7 @@ start64:
         .word   0
 idt_48: .word   0, 0, 0 # base = limit = 0
 
-trampoline_gdt:
+GLOBAL(trampoline_gdt)
         .word   0                  /* 0x0000: unused (reused for GDTR) */
 gdt_48:
         .word   .Ltrampoline_gdt_end - trampoline_gdt - 1
@@ -154,6 +164,13 @@ gdt_48:
         .quad   0x00cf93000000ffff /* 0x0018: ring 0 data */
         .quad   0x00009b000000ffff /* 0x0020: real-mode code @ BOOT_TRAMPOLINE */
         .quad   0x000093000000ffff /* 0x0028: real-mode data @ BOOT_TRAMPOLINE */
+        /*
+         * Intel TXT requires these two in exact order. This isn't compatible
+         * with order required by syscall, so we have duplicated entries...
+         * If order ever changes, update selector numbers in asm/intel-txt.h.
+         */
+        .quad   0x00cf9b000000ffff /* 0x0030: ring 0 code, 32-bit mode */
+        .quad   0x00cf93000000ffff /* 0x0038: ring 0 data */
 .Ltrampoline_gdt_end:
 
         /* Relocations for trampoline Real Mode segments. */
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index de7f23d4ff..c032ebb2e1 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -91,6 +91,9 @@
 
 #define SLAUNCH_BOOTLOADER_MAGIC             0x4c534254
 
+#define TXT_AP_BOOT_CS                  0x0030
+#define TXT_AP_BOOT_DS                  0x0038
+
 #ifndef __ASSEMBLY__
 
 #include 
@@ -105,6 +108,9 @@
 #define _txt(x) __va(x)
 #endif
 
+extern char txt_ap_entry[];
+extern uint32_t trampoline_gdt[];
+
 /*
  * Always use private space as some of registers are either read-only or not
  * present in public space.
diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index 96b9bf5f5e..20c85eb2f3 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -466,6 +466,7 @@ void set_in_pb_opt_ctrl(uint32_t mask, uint32_t val);
 enum ap_boot_method {
     AP_BOOT_NORMAL,
     AP_BOOT_SKINIT,
+    AP_BOOT_TXT,
 };
 extern enum ap_boot_method ap_boot_method;
 
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index a90caf45a5..74a7cbe23b 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -321,6 +323,29 @@ void asmlinkage start_secondary(void)
     struct cpu_info *info = get_cpu_info();
     unsigned int cpu = smp_processor_id();
 
+    if ( ap_boot_method == AP_BOOT_TXT ) {
+        uint64_t misc_enable;
+        uint32_t my_apicid;
+        struct txt_sinit_mle_data *sinit_mle =
+              txt_sinit_mle_data_start(__va(txt_read(TXTCR_HEAP_BASE)));
+
+        /* TXT released us with MONITOR disabled in IA32_MISC_ENABLE. */
+        rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
+        wrmsrl(MSR_IA32_MISC_ENABLE,
+               misc_enable | MSR_IA32_MISC_ENABLE_MONITOR_ENABLE);
+
+        /* get_apic_id() reads from x2APIC if it thinks it is enabled. */
+        x2apic_ap_setup();
+        my_apicid = get_apic_id();
+
+        while ( my_apicid != x86_cpu_to_apicid[cpu] ) {
+            asm volatile ("monitor; xor %0,%0; mwait"
+                          :: "a"(__va(sinit_mle->rlp_wakeup_addr)), "c"(0),
+                          "d"(0) : "memory");
+            cpu = smp_processor_id();
+        }
+    }
+
     /* Critical region without IDT or TSS.  Any fault is deadly! */
 
     set_current(idle_vcpu[cpu]);
@@ -418,6 +443,28 @@ void asmlinkage start_secondary(void)
     startup_cpu_idle_loop();
 }
 
+static int wake_aps_in_txt(void)
+{
+    struct txt_sinit_mle_data *sinit_mle =
+              txt_sinit_mle_data_start(__va(txt_read(TXTCR_HEAP_BASE)));
+    uint32_t *wakeup_addr = __va(sinit_mle->rlp_wakeup_addr);
+
+    uint32_t join[4] = {
+        trampoline_gdt[1],               /* GDT limit */
+        bootsym_phys(trampoline_gdt),    /* GDT base */
+        TXT_AP_BOOT_CS,                  /* CS selector, DS = CS+8 */
+        bootsym_phys(txt_ap_entry)       /* EIP */
+    };
+
+    txt_write(TXTCR_MLE_JOIN, __pa(join));
+
+    smp_mb();
+
+    *wakeup_addr = 1;
+
+    return 0;
+}
+
 static int wakeup_secondary_cpu(int phys_apicid, unsigned long start_eip)
 {
     unsigned long send_status = 0, accept_status = 0;
@@ -440,6 +487,9 @@ static int wakeup_secondary_cpu(int phys_apicid, unsigned long start_eip)
     if ( tboot_in_measured_env() && !tboot_wake_ap(phys_apicid, start_eip) )
         return 0;
 
+    if ( ap_boot_method == AP_BOOT_TXT )
+        return wake_aps_in_txt();
+
     /*
      * Be paranoid about clearing APIC errors.
      */
@@ -1147,6 +1197,13 @@ static struct notifier_block cpu_smpboot_nfb = {
 
 void __init smp_prepare_cpus(void)
 {
+    /*
+     * If the platform is performing a Secure Launch via TXT, secondary
+     * CPUs (APs) will need to be woken up in a TXT-specific way.
+     */
+    if ( slaunch_active && boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+        ap_boot_method = AP_BOOT_TXT;
+
     register_cpu_notifier(&cpu_smpboot_nfb);
 
     mtrr_aps_sync_begin();
@@ -1424,6 +1481,12 @@ void __init smp_cpus_done(void)
 
     mtrr_save_state();
     mtrr_aps_sync_end();
+
+    /*
+     * After the initial startup the DRTM-specific method for booting APs
+     * should not longer be used unless DRTM sequence is started again.
+     */
+    ap_boot_method = AP_BOOT_NORMAL;
 }
 
 void __init smp_intr_init(void)
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:19:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:19:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000958.1381216 (Exim 4.92)
	(envelope-from )
	id 1uKzdu-0004Sx-3p; Fri, 30 May 2025 13:19:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000958.1381216; Fri, 30 May 2025 13:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKzdu-0004Sk-0k; Fri, 30 May 2025 13:19:26 +0000
Received: by outflank-mailman (input) for mailman id 1000958;
 Fri, 30 May 2025 13:19:25 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdt-0003ZU-2W
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:25 +0000
Received: from 7.mo583.mail-out.ovh.net (7.mo583.mail-out.ovh.net
 [178.32.124.100]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a7afecb9-3d58-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:19:03 +0200 (CEST)
Received: from director4.ghost.mail-out.ovh.net (unknown [10.109.140.215])
 by mo583.mail-out.ovh.net (Postfix) with ESMTP id 4b83jL3gKkz1kgt
 for ; Fri, 30 May 2025 13:19:02 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-hvgnt (unknown [10.111.174.63])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 8B287C571F;
 Fri, 30 May 2025 13:19:01 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.102])
 by ghost-submission-5b5ff79f4f-hvgnt with ESMTPSA
 id KNMyDUWwOWi4BgAANXmUfQ
 (envelope-from ); Fri, 30 May 2025 13:19: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" 
X-Inumbo-ID: a7afecb9-3d58-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-102R0041e3c7755-c10f-46ce-aaa4-685e3d70a9d1,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 11/22] x86/tpm.c: support extending PCRs of TPM2.0
Date: Fri, 30 May 2025 16:17:53 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12701839800321160348
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepvdfhhedukefhveeifefffedvfeejgeegkeeuhfegheejhefgieeikeejleeihfffnecuffhomhgrihhnpehuphgurghtvggptgdruggrthgrpdhfihhnihhshhgptgdruggrthgrnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekfegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=vbZBG6/p+HYIHnA6JUFYr41EnuLF4cyFkDoUUxgDG/o=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611142; v=1;
 b=WffUb+f30ijaMQ62rKcvtD+Dk7yHxQDQsJuWrkyXV53kLPoCi4qPkRTzG24TXakjvoGEtC5Y
 1+ud9PwQsPkczhAcrkJ7lN4SH6RWwnTlD5Y3M+lXSTjo51sRAU2wswbl8pAIXquXkqMWjE5qpm0
 3gza46lK3AObNHXNReSmKdrC8WA/9GKjZVts3VYScuSHWzA+4CYcPUvf5B+xGrumuhzenlbXlnH
 qlZ/2nYJXoFN5HboGIK3/cDtv1+hiHHmiIXd9fCcsw+zHY9c1u/Q3Tj2TfV0kK/L+2rohhGr4Vm
 yRl11Bulo6we2us6yVoFiOFs3tpx6oqHr7lCpI4vMo3NQ==

SHA1 and SHA256 are hard-coded here, but their support by the TPM is
checked.  Addition of event log for TPM2.0 will generalize the code
further.

Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/tpm.c | 464 +++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 452 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
index 7fb19ce4fa..ed49fe3ccf 100644
--- a/xen/arch/x86/tpm.c
+++ b/xen/arch/x86/tpm.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,15 @@ struct slr_table *slaunch_get_slrt(void)
  * other part of Xen.  Providing implementation of builtin functions in this
  * case is necessary if compiler chooses to not use an inline builtin.
  */
+void *(memset)(void *s, int c, size_t n)
+{
+    uint8_t *d = s;
+
+    while ( n-- )
+        *d++ = c;
+
+    return s;
+}
 void *(memcpy)(void *dest, const void *src, size_t n)
 {
     const uint8_t *s = src;
@@ -146,14 +156,15 @@ static inline bool is_tpm12(void)
             (tis_read32(TPM_STS_(0)) & TPM_FAMILY_MASK) == 0);
 }
 
-/****************************** TPM1.2 specific *******************************/
-#define TPM_ORD_Extend              0x00000014
-#define TPM_ORD_SHA1Start           0x000000A0
-#define TPM_ORD_SHA1Update          0x000000A1
-#define TPM_ORD_SHA1CompleteExtend  0x000000A3
+/****************************** TPM1.2 & TPM2.0 *******************************/
 
-#define TPM_TAG_RQU_COMMAND         0x00C1
-#define TPM_TAG_RSP_COMMAND         0x00C4
+/*
+ * TPM1.2 is required to support commands of up to 1101 bytes, vendors rarely
+ * go above that. Limit maximum size of block of data to be hashed to 1024.
+ *
+ * TPM2.0 should support hashing of at least 1024 bytes.
+ */
+#define MAX_HASH_BLOCK      1024
 
 /* All fields of following structs are big endian. */
 struct tpm_cmd_hdr {
@@ -168,6 +179,17 @@ struct tpm_rsp_hdr {
     uint32_t    returnCode;
 } __packed;
 
+/****************************** TPM1.2 specific *******************************/
+
+#define TPM_ORD_Extend              0x00000014
+#define TPM_ORD_SHA1Start           0x000000A0
+#define TPM_ORD_SHA1Update          0x000000A1
+#define TPM_ORD_SHA1CompleteExtend  0x000000A3
+
+#define TPM_TAG_RQU_COMMAND         0x00C1
+#define TPM_TAG_RSP_COMMAND         0x00C4
+
+/* All fields of following structs are big endian. */
 struct extend_cmd {
     struct tpm_cmd_hdr h;
     uint32_t pcrNum;
@@ -233,11 +255,6 @@ struct txt_ev_log_container_12 {
 };
 
 #ifdef __EARLY_SLAUNCH__
-/*
- * TPM1.2 is required to support commands of up to 1101 bytes, vendors rarely
- * go above that. Limit maximum size of block of data to be hashed to 1024.
- */
-#define MAX_HASH_BLOCK      1024
 #define CMD_RSP_BUF_SIZE    (sizeof(struct sha1_update_cmd) + MAX_HASH_BLOCK)
 
 union cmd_rsp {
@@ -393,6 +410,400 @@ static void *create_log_event12(struct txt_ev_log_container_12 *evt_log,
 
 /************************** end of TPM1.2 specific ****************************/
 
+/****************************** TPM2.0 specific *******************************/
+
+/*
+ * These constants are for TPM2.0 but don't have a distinct prefix to match
+ * names in the specification.
+ */
+
+#define TPM_HT_PCR   0x00
+
+#define TPM_RH_NULL  0x40000007
+#define TPM_RS_PW    0x40000009
+
+#define HR_SHIFT     24
+#define HR_PCR       (TPM_HT_PCR << HR_SHIFT)
+
+#define TPM_ST_NO_SESSIONS  0x8001
+#define TPM_ST_SESSIONS     0x8002
+
+#define TPM_ALG_SHA1        0x0004
+#define TPM_ALG_SHA256      0x000b
+#define TPM_ALG_NULL        0x0010
+
+#define TPM2_PCR_Extend                 0x00000182
+#define TPM2_PCR_HashSequenceStart      0x00000186
+#define TPM2_PCR_SequenceUpdate         0x0000015C
+#define TPM2_PCR_EventSequenceComplete  0x00000185
+
+#define PUT_BYTES(p, bytes, size)  do {  \
+        memcpy((p), (bytes), (size));    \
+        (p) += (size);                   \
+    } while ( 0 )
+
+#define PUT_16BIT(p, data) do {          \
+        *(uint16_t *)(p) = swap16(data); \
+        (p) += 2;                        \
+    } while ( 0 )
+
+/* All fields of following structs are big endian. */
+struct tpm2_session_header {
+    uint32_t handle;
+    uint16_t nonceSize;
+    uint8_t nonce[0];
+    uint8_t attrs;
+    uint16_t hmacSize;
+    uint8_t hmac[0];
+} __packed;
+
+struct tpm2_extend_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrHandle;
+    uint32_t sessionHdrSize;
+    struct tpm2_session_header pcrSession;
+    uint32_t hashCount;
+    uint8_t hashes[0];
+} __packed;
+
+struct tpm2_extend_rsp {
+    struct tpm_rsp_hdr h;
+} __packed;
+
+struct tpm2_sequence_start_cmd {
+    struct tpm_cmd_hdr h;
+    uint16_t hmacSize;
+    uint8_t hmac[0];
+    uint16_t hashAlg;
+} __packed;
+
+struct tpm2_sequence_start_rsp {
+    struct tpm_rsp_hdr h;
+    uint32_t sequenceHandle;
+} __packed;
+
+struct tpm2_sequence_update_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t sequenceHandle;
+    uint32_t sessionHdrSize;
+    struct tpm2_session_header session;
+    uint16_t dataSize;
+    uint8_t data[0];
+} __packed;
+
+struct tpm2_sequence_update_rsp {
+    struct tpm_rsp_hdr h;
+} __packed;
+
+struct tpm2_sequence_complete_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrHandle;
+    uint32_t sequenceHandle;
+    uint32_t sessionHdrSize;
+    struct tpm2_session_header pcrSession;
+    struct tpm2_session_header sequenceSession;
+    uint16_t dataSize;
+    uint8_t data[0];
+} __packed;
+
+struct tpm2_sequence_complete_rsp {
+    struct tpm_rsp_hdr h;
+    uint32_t paramSize;
+    uint32_t hashCount;
+    uint8_t hashes[0];
+    /*
+     * Each hash is represented as:
+     * struct {
+     *     uint16_t hashAlg;
+     *     uint8_t hash[size of hashAlg];
+     * };
+     */
+} __packed;
+
+/*
+ * These two structure are for convenience, they don't correspond to anything in
+ * any spec.
+ */
+struct tpm2_log_hash {
+    uint16_t alg;  /* TPM_ALG_* */
+    uint16_t size;
+    uint8_t *data; /* Non-owning reference to a buffer inside log entry. */
+};
+/* Should be more than enough for now and awhile in the future. */
+#define MAX_HASH_COUNT 8
+struct tpm2_log_hashes {
+    uint32_t count;
+    struct tpm2_log_hash hashes[MAX_HASH_COUNT];
+};
+
+#ifdef __EARLY_SLAUNCH__
+
+union tpm2_cmd_rsp {
+    uint8_t b[sizeof(struct tpm2_sequence_update_cmd) + MAX_HASH_BLOCK];
+    struct tpm_cmd_hdr c;
+    struct tpm_rsp_hdr r;
+    struct tpm2_sequence_start_cmd start_c;
+    struct tpm2_sequence_start_rsp start_r;
+    struct tpm2_sequence_update_cmd update_c;
+    struct tpm2_sequence_update_rsp update_r;
+    struct tpm2_sequence_complete_cmd finish_c;
+    struct tpm2_sequence_complete_rsp finish_r;
+};
+
+static uint32_t tpm2_hash_extend(unsigned loc, const uint8_t *buf,
+                                 unsigned size, unsigned pcr,
+                                 struct tpm2_log_hashes *log_hashes)
+{
+    uint32_t seq_handle;
+    unsigned max_bytes = MAX_HASH_BLOCK;
+
+    union tpm2_cmd_rsp cmd_rsp;
+    unsigned o_size;
+    unsigned i;
+    uint8_t *p;
+    uint32_t rc;
+
+    cmd_rsp.start_c = (struct tpm2_sequence_start_cmd) {
+        .h.tag = swap16(TPM_ST_NO_SESSIONS),
+        .h.paramSize = swap32(sizeof(cmd_rsp.start_c)),
+        .h.ordinal = swap32(TPM2_PCR_HashSequenceStart),
+        .hashAlg = swap16(TPM_ALG_NULL), /* Compute all supported hashes. */
+    };
+
+    request_locality(loc);
+
+    o_size = sizeof(cmd_rsp);
+    send_cmd(loc, cmd_rsp.b, swap32(cmd_rsp.c.paramSize), &o_size);
+
+    if ( cmd_rsp.r.tag == swap16(TPM_ST_NO_SESSIONS) &&
+         cmd_rsp.r.paramSize == swap32(10) )
+    {
+        rc = swap32(cmd_rsp.r.returnCode);
+        if ( rc != 0 )
+            goto error;
+    }
+
+    seq_handle = swap32(cmd_rsp.start_r.sequenceHandle);
+
+    while ( size > 64 )
+    {
+        if ( size < max_bytes )
+            max_bytes = size & ~(64 - 1);
+
+        cmd_rsp.update_c = (struct tpm2_sequence_update_cmd) {
+            .h.tag = swap16(TPM_ST_SESSIONS),
+            .h.paramSize = swap32(sizeof(cmd_rsp.update_c) + max_bytes),
+            .h.ordinal = swap32(TPM2_PCR_SequenceUpdate),
+            .sequenceHandle = swap32(seq_handle),
+            .sessionHdrSize = swap32(sizeof(struct tpm2_session_header)),
+            .session.handle = swap32(TPM_RS_PW),
+            .dataSize = swap16(max_bytes),
+        };
+
+        memcpy(cmd_rsp.update_c.data, buf, max_bytes);
+
+        o_size = sizeof(cmd_rsp);
+        send_cmd(loc, cmd_rsp.b, swap32(cmd_rsp.c.paramSize), &o_size);
+
+        if ( cmd_rsp.r.tag == swap16(TPM_ST_NO_SESSIONS) &&
+             cmd_rsp.r.paramSize == swap32(10) )
+        {
+            rc = swap32(cmd_rsp.r.returnCode);
+            if ( rc != 0 )
+                goto error;
+        }
+
+        size -= max_bytes;
+        buf += max_bytes;
+    }
+
+    cmd_rsp.finish_c = (struct tpm2_sequence_complete_cmd) {
+        .h.tag = swap16(TPM_ST_SESSIONS),
+        .h.paramSize = swap32(sizeof(cmd_rsp.finish_c) + size),
+        .h.ordinal = swap32(TPM2_PCR_EventSequenceComplete),
+        .pcrHandle = swap32(HR_PCR + pcr),
+        .sequenceHandle = swap32(seq_handle),
+        .sessionHdrSize = swap32(sizeof(struct tpm2_session_header)*2),
+        .pcrSession.handle = swap32(TPM_RS_PW),
+        .sequenceSession.handle = swap32(TPM_RS_PW),
+        .dataSize = swap16(size),
+    };
+
+    memcpy(cmd_rsp.finish_c.data, buf, size);
+
+    o_size = sizeof(cmd_rsp);
+    send_cmd(loc, cmd_rsp.b, swap32(cmd_rsp.c.paramSize), &o_size);
+
+    if ( cmd_rsp.r.tag == swap16(TPM_ST_NO_SESSIONS) &&
+         cmd_rsp.r.paramSize == swap32(10) )
+    {
+        rc = swap32(cmd_rsp.r.returnCode);
+        if ( rc != 0 )
+            goto error;
+    }
+
+    p = cmd_rsp.finish_r.hashes;
+    for ( i = 0; i < swap32(cmd_rsp.finish_r.hashCount); ++i )
+    {
+        unsigned j;
+        uint16_t hash_type;
+
+        hash_type = swap16(*(uint16_t *)p);
+        p += sizeof(uint16_t);
+
+        for ( j = 0; j < log_hashes->count; ++j )
+        {
+            struct tpm2_log_hash *hash = &log_hashes->hashes[j];
+            if ( hash->alg == hash_type )
+            {
+                memcpy(hash->data, p, hash->size);
+                p += hash->size;
+                break;
+            }
+        }
+
+        if ( j == log_hashes->count )
+            /* Can't continue parsing without knowing hash size. */
+            break;
+    }
+
+    rc = 0;
+
+error:
+    relinquish_locality(loc);
+    return rc;
+}
+
+#else
+
+union tpm2_cmd_rsp {
+    /* Enough space for multiple hashes. */
+    uint8_t b[sizeof(struct tpm2_extend_cmd) + 1024];
+    struct tpm_cmd_hdr c;
+    struct tpm_rsp_hdr r;
+    struct tpm2_extend_cmd extend_c;
+    struct tpm2_extend_rsp extend_r;
+};
+
+static uint32_t tpm20_pcr_extend(unsigned loc, uint32_t pcr_handle,
+                                 const struct tpm2_log_hashes *log_hashes)
+{
+    union tpm2_cmd_rsp cmd_rsp;
+    unsigned o_size;
+    unsigned i;
+    uint8_t *p;
+
+    cmd_rsp.extend_c = (struct tpm2_extend_cmd) {
+        .h.tag = swap16(TPM_ST_SESSIONS),
+        .h.ordinal = swap32(TPM2_PCR_Extend),
+        .pcrHandle = swap32(pcr_handle),
+        .sessionHdrSize = swap32(sizeof(struct tpm2_session_header)),
+        .pcrSession.handle = swap32(TPM_RS_PW),
+        .hashCount = swap32(log_hashes->count),
+    };
+
+    p = cmd_rsp.extend_c.hashes;
+    for ( i = 0; i < log_hashes->count; ++i )
+    {
+        const struct tpm2_log_hash *hash = &log_hashes->hashes[i];
+
+        if ( p + sizeof(uint16_t) + hash->size > &cmd_rsp.b[sizeof(cmd_rsp)] )
+        {
+            printk(XENLOG_ERR "Hit TPM message size implementation limit: %ld\n",
+                   sizeof(cmd_rsp));
+            return -1;
+        }
+
+        *(uint16_t *)p = swap16(hash->alg);
+        p += sizeof(uint16_t);
+
+        memcpy(p, hash->data, hash->size);
+        p += hash->size;
+    }
+
+    /* Fill in command size (size of the whole buffer). */
+    cmd_rsp.extend_c.h.paramSize = swap32(sizeof(cmd_rsp.extend_c) +
+                                          (p - cmd_rsp.extend_c.hashes)),
+
+    o_size = sizeof(cmd_rsp);
+    send_cmd(loc, cmd_rsp.b, swap32(cmd_rsp.c.paramSize), &o_size);
+
+    return swap32(cmd_rsp.r.returnCode);
+}
+
+static bool tpm_supports_hash(unsigned loc, const struct tpm2_log_hash *hash)
+{
+    uint32_t rc;
+    struct tpm2_log_hashes hashes = {
+        .count = 1,
+        .hashes[0] = *hash,
+    };
+
+    /*
+     * This is a valid way of checking hash support, using it to not implement
+     * TPM2_GetCapability().
+     */
+    rc = tpm20_pcr_extend(loc, /*pcr_handle=*/TPM_RH_NULL, &hashes);
+
+    return rc == 0;
+}
+
+static uint32_t tpm2_hash_extend(unsigned loc, const uint8_t *buf,
+                                 unsigned size, unsigned pcr,
+                                 const struct tpm2_log_hashes *log_hashes)
+{
+    uint32_t rc;
+    unsigned i;
+    struct tpm2_log_hashes supported_hashes = {0};
+
+    request_locality(loc);
+
+    for ( i = 0; i < log_hashes->count; ++i )
+    {
+        const struct tpm2_log_hash *hash = &log_hashes->hashes[i];
+        if ( !tpm_supports_hash(loc, hash) )
+        {
+            printk(XENLOG_WARNING "Skipped hash unsupported by TPM: %d\n",
+                   hash->alg);
+            continue;
+        }
+
+        if ( hash->alg == TPM_ALG_SHA1 )
+        {
+            sha1_hash(hash->data, buf, size);
+        }
+        else if ( hash->alg == TPM_ALG_SHA256 )
+        {
+            sha2_256_digest(hash->data, buf, size);
+        }
+        else
+        {
+            /* This is called "OneDigest" in TXT Software Development Guide. */
+            memset(hash->data, 0, size);
+            hash->data[0] = 1;
+        }
+
+        if ( supported_hashes.count == MAX_HASH_COUNT )
+        {
+            printk(XENLOG_ERR "Hit hash count implementation limit: %d\n",
+                   MAX_HASH_COUNT);
+            return -1;
+        }
+
+        supported_hashes.hashes[supported_hashes.count] = *hash;
+        ++supported_hashes.count;
+    }
+
+    rc = tpm20_pcr_extend(loc, HR_PCR + pcr, &supported_hashes);
+    relinquish_locality(loc);
+
+    return rc;
+}
+
+#endif /* __EARLY_SLAUNCH__ */
+
+/************************** end of TPM2.0 specific ****************************/
+
 void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
                      unsigned size, uint32_t type, const uint8_t *log_data,
                      unsigned log_data_size)
@@ -419,6 +830,35 @@ void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
         {
 #ifndef __EARLY_SLAUNCH__
             printk(XENLOG_ERR "Extending PCR%u failed\n", pcr);
+#endif
+        }
+    } else {
+        uint8_t sha1_digest[SHA1_DIGEST_SIZE];
+        uint8_t sha256_digest[SHA2_256_DIGEST_SIZE];
+        uint32_t rc;
+
+        struct tpm2_log_hashes log_hashes = {
+            .count = 2,
+            .hashes = {
+                {
+                    .alg = TPM_ALG_SHA1,
+                    .size = SHA1_DIGEST_SIZE,
+                    .data = sha1_digest,
+                },
+                {
+                    .alg = TPM_ALG_SHA256,
+                    .size = SHA2_256_DIGEST_SIZE,
+                    .data = sha256_digest,
+                },
+            },
+        };
+
+        rc = tpm2_hash_extend(loc, buf, size, pcr, &log_hashes);
+        if ( rc != 0 )
+        {
+#ifndef __EARLY_SLAUNCH__
+            printk(XENLOG_ERR "Extending PCR%u failed with TPM error: 0x%08x\n",
+                   pcr, rc);
 #endif
         }
     }
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:20:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:20:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000977.1381232 (Exim 4.92)
	(envelope-from )
	id 1uKzfF-00074r-Qn; Fri, 30 May 2025 13:20:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000977.1381232; Fri, 30 May 2025 13:20: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 1uKzfF-00073z-IF; Fri, 30 May 2025 13:20:49 +0000
Received: by outflank-mailman (input) for mailman id 1000977;
 Fri, 30 May 2025 13:20:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdh-0008Jy-Jl
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:13 +0000
Received: from 3.mo583.mail-out.ovh.net (3.mo583.mail-out.ovh.net
 [46.105.40.108]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ab069374-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:19:08 +0200 (CEST)
Received: from director4.ghost.mail-out.ovh.net (unknown [10.109.140.215])
 by mo583.mail-out.ovh.net (Postfix) with ESMTP id 4b83jS26Cjz1gpb
 for ; Fri, 30 May 2025 13:19:08 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-sqj9x (unknown [10.110.113.35])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 70D72C5715;
 Fri, 30 May 2025 13:19:07 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.106])
 by ghost-submission-5b5ff79f4f-sqj9x with ESMTPSA
 id bshXCkuwOWj6JQAAPescrA
 (envelope-from ); Fri, 30 May 2025 13: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" 
X-Inumbo-ID: ab069374-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-106R006d10a0eb1-598f-4895-b746-f3445aee3969,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 13/22] x86/tpm.c: implement event log for TPM2.0
Date: Fri, 30 May 2025 16:17:55 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12703528653124908188
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhephfehfeehudeileeikeffgfffgfefuddtveelvedvhfffgfelvdfgtddutdehfeeinecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrddutdeinecuvehluhhsthgvrhfuihiivgepvdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekfegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=ixLmPLThAstC9HSOCxNeT4qjU8C58Im4iR2Vxsanw3Y=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611148; v=1;
 b=EPtTXt3tCy4mxfiCGuAMAj/aTQ5IkWPMwhIJJPJEuc+aoZA25rC0B9UjsKHZ4H5FAr4M+Z30
 ufBRDnzwI781Wrnxfq6RhusSEsHWNUbaTH70b2RCXYfFs29V4RGtsNYOoHDwrx0olgZvBWaK8EE
 oP5lwrUTA3HnNPlpso5LN40kYO+aZH44Ess7BAtssJ1zCtVF6d3hZMpARDQePM48Lqx4uNeOAdx
 welO+/pnPQGkZmhUvj9s5JjmOnebt3WqpFF8g+/mOfpKwzYDOMpJWJCa3gnhI7orSNogV9SGOXY
 p6mECGTHhS5Uuxodpg9XTa3xm0sGFjOmyenoPYz9oSMAQ==

Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/include/asm/intel-txt.h |  33 ++++++
 xen/arch/x86/tpm.c                   | 169 ++++++++++++++++++++++-----
 2 files changed, 175 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 0b0bdc1bb2..de7f23d4ff 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -215,6 +215,39 @@ struct txt_sinit_mle_data {
     /* Ext Data Elements */
 } __packed;
 
+/* Types of extended data. */
+#define TXT_HEAP_EXTDATA_TYPE_END                    0
+#define TXT_HEAP_EXTDATA_TYPE_BIOS_SPEC_VER          1
+#define TXT_HEAP_EXTDATA_TYPE_ACM                    2
+#define TXT_HEAP_EXTDATA_TYPE_STM                    3
+#define TXT_HEAP_EXTDATA_TYPE_CUSTOM                 4
+#define TXT_HEAP_EXTDATA_TYPE_MADT                   6
+#define TXT_HEAP_EXTDATA_TYPE_EVENT_LOG_POINTER2_1   8
+#define TXT_HEAP_EXTDATA_TYPE_MCFG                   9
+#define TXT_HEAP_EXTDATA_TYPE_TPR_REQ               13
+#define TXT_HEAP_EXTDATA_TYPE_DTPR                  14
+#define TXT_HEAP_EXTDATA_TYPE_CEDT                  15
+
+/*
+ * Self-describing data structure that is used for extensions to TXT heap
+ * tables.
+ */
+struct txt_ext_data_element {
+    uint32_t type;   /* One of TXT_HEAP_EXTDATA_TYPE_*. */
+    uint32_t size;
+    uint8_t data[0]; /* size bytes. */
+} __packed;
+
+/*
+ * Extended data describing TPM 2.0 log.
+ */
+struct heap_event_log_pointer_element2_1 {
+    uint64_t physical_address;
+    uint32_t allocated_event_container_size;
+    uint32_t first_record_offset;
+    uint32_t next_record_offset;
+} __packed;
+
 /*
  * Functions to extract data from the Intel TXT Heap Memory.
  *
diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
index ed49fe3ccf..3c145fd3cc 100644
--- a/xen/arch/x86/tpm.c
+++ b/xen/arch/x86/tpm.c
@@ -536,6 +536,44 @@ struct tpm2_log_hashes {
     struct tpm2_log_hash hashes[MAX_HASH_COUNT];
 };
 
+struct tpm2_pcr_event_header {
+    uint32_t pcrIndex;
+    uint32_t eventType;
+    uint32_t digestCount;
+    uint8_t digests[0];
+    /*
+     * Each hash is represented as:
+     * struct {
+     *     uint16_t hashAlg;
+     *     uint8_t hash[size of hashAlg];
+     * };
+     */
+    /* uint32_t eventSize; */
+    /* uint8_t event[0]; */
+} __packed;
+
+struct tpm2_digest_sizes {
+    uint16_t algId;
+    uint16_t digestSize;
+} __packed;
+
+struct tpm2_spec_id_event {
+    uint32_t pcrIndex;
+    uint32_t eventType;
+    uint8_t digest[20];
+    uint32_t eventSize;
+    uint8_t signature[16];
+    uint32_t platformClass;
+    uint8_t specVersionMinor;
+    uint8_t specVersionMajor;
+    uint8_t specErrata;
+    uint8_t uintnSize;
+    uint32_t digestCount;
+    struct tpm2_digest_sizes digestSizes[0]; /* variable number of members */
+    /* uint8_t vendorInfoSize; */
+    /* uint8_t vendorInfo[vendorInfoSize]; */
+} __packed;
+
 #ifdef __EARLY_SLAUNCH__
 
 union tpm2_cmd_rsp {
@@ -769,19 +807,11 @@ static uint32_t tpm2_hash_extend(unsigned loc, const uint8_t *buf,
         }
 
         if ( hash->alg == TPM_ALG_SHA1 )
-        {
             sha1_hash(hash->data, buf, size);
-        }
         else if ( hash->alg == TPM_ALG_SHA256 )
-        {
             sha2_256_digest(hash->data, buf, size);
-        }
         else
-        {
-            /* This is called "OneDigest" in TXT Software Development Guide. */
-            memset(hash->data, 0, size);
-            hash->data[0] = 1;
-        }
+            /* create_log_event20() took care of initializing the digest. */;
 
         if ( supported_hashes.count == MAX_HASH_COUNT )
         {
@@ -802,6 +832,102 @@ static uint32_t tpm2_hash_extend(unsigned loc, const uint8_t *buf,
 
 #endif /* __EARLY_SLAUNCH__ */
 
+static struct heap_event_log_pointer_element2_1 *find_evt_log_ext_data(void)
+{
+    struct txt_os_sinit_data *os_sinit;
+    struct txt_ext_data_element *ext_data;
+
+    os_sinit = txt_os_sinit_data_start(__va(txt_read(TXTCR_HEAP_BASE)));
+    ext_data = (void *)((uint8_t *)os_sinit + sizeof(*os_sinit));
+
+    /*
+     * Find TXT_HEAP_EXTDATA_TYPE_EVENT_LOG_POINTER2_1 which is necessary to
+     * know where to put the next entry.
+     */
+    while ( ext_data->type != TXT_HEAP_EXTDATA_TYPE_END )
+    {
+        if ( ext_data->type == TXT_HEAP_EXTDATA_TYPE_EVENT_LOG_POINTER2_1 )
+            break;
+        ext_data = (void *)&ext_data->data[ext_data->size];
+    }
+
+    if ( ext_data->type == TXT_HEAP_EXTDATA_TYPE_END )
+        return NULL;
+
+    return (void *)&ext_data->data[0];
+}
+
+static struct tpm2_log_hashes
+create_log_event20(struct tpm2_spec_id_event *evt_log, uint32_t evt_log_size,
+                   uint32_t pcr, uint32_t type, const uint8_t *data,
+                   unsigned data_size)
+{
+    struct tpm2_log_hashes log_hashes = {0};
+
+    struct heap_event_log_pointer_element2_1 *log_ext_data;
+    struct tpm2_pcr_event_header *new_entry;
+    uint32_t entry_size;
+    unsigned i;
+    uint8_t *p;
+
+    log_ext_data = find_evt_log_ext_data();
+    if ( log_ext_data == NULL )
+        return log_hashes;
+
+    entry_size = sizeof(*new_entry);
+    for ( i = 0; i < evt_log->digestCount; ++i )
+    {
+        entry_size += sizeof(uint16_t); /* hash type */
+        entry_size += evt_log->digestSizes[i].digestSize;
+    }
+    entry_size += sizeof(uint32_t); /* data size field */
+    entry_size += data_size;
+
+    /*
+     * Check if there is enough space left for new entry.
+     * Note: it is possible to introduce a gap in event log if entry with big
+     * data_size is followed by another entry with smaller data. Maybe we should
+     * cap the event log size in such case?
+     */
+    if ( log_ext_data->next_record_offset + entry_size > evt_log_size )
+        return log_hashes;
+
+    new_entry = (void *)((uint8_t *)evt_log + log_ext_data->next_record_offset);
+    log_ext_data->next_record_offset += entry_size;
+
+    new_entry->pcrIndex = pcr;
+    new_entry->eventType = type;
+    new_entry->digestCount = evt_log->digestCount;
+
+    p = &new_entry->digests[0];
+    for ( i = 0; i < evt_log->digestCount; ++i )
+    {
+        uint16_t alg = evt_log->digestSizes[i].algId;
+        uint16_t size = evt_log->digestSizes[i].digestSize;
+
+        *(uint16_t *)p = alg;
+        p += sizeof(uint16_t);
+
+        log_hashes.hashes[i].alg = alg;
+        log_hashes.hashes[i].size = size;
+        log_hashes.hashes[i].data = p;
+        p += size;
+
+        /* This is called "OneDigest" in TXT Software Development Guide. */
+        memset(log_hashes.hashes[i].data, 0, size);
+        log_hashes.hashes[i].data[0] = 1;
+    }
+    log_hashes.count = evt_log->digestCount;
+
+    *(uint32_t *)p = data_size;
+    p += sizeof(uint32_t);
+
+    if ( data && data_size > 0 )
+        memcpy(p, data, data_size);
+
+    return log_hashes;
+}
+
 /************************** end of TPM2.0 specific ****************************/
 
 void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
@@ -832,26 +958,15 @@ void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
             printk(XENLOG_ERR "Extending PCR%u failed\n", pcr);
 #endif
         }
-    } else {
-        uint8_t sha1_digest[SHA1_DIGEST_SIZE];
-        uint8_t sha256_digest[SHA2_256_DIGEST_SIZE];
+    }
+    else
+    {
         uint32_t rc;
 
-        struct tpm2_log_hashes log_hashes = {
-            .count = 2,
-            .hashes = {
-                {
-                    .alg = TPM_ALG_SHA1,
-                    .size = SHA1_DIGEST_SIZE,
-                    .data = sha1_digest,
-                },
-                {
-                    .alg = TPM_ALG_SHA256,
-                    .size = SHA2_256_DIGEST_SIZE,
-                    .data = sha256_digest,
-                },
-            },
-        };
+        struct tpm2_spec_id_event *evt_log = evt_log_addr;
+        struct tpm2_log_hashes log_hashes =
+            create_log_event20(evt_log, evt_log_size, pcr, type, log_data,
+                               log_data_size);
 
         rc = tpm2_hash_extend(loc, buf, size, pcr, &log_hashes);
         if ( rc != 0 )
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:20:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:20:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000975.1381227 (Exim 4.92)
	(envelope-from )
	id 1uKzfF-000730-GY; Fri, 30 May 2025 13:20:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000975.1381227; Fri, 30 May 2025 13:20: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 1uKzfF-00071l-BQ; Fri, 30 May 2025 13:20:49 +0000
Received: by outflank-mailman (input) for mailman id 1000975;
 Fri, 30 May 2025 13:20:48 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdO-0008Jy-S3
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:18:54 +0000
Received: from 7.mo582.mail-out.ovh.net (7.mo582.mail-out.ovh.net
 [46.105.59.196]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a217e06e-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:18:53 +0200 (CEST)
Received: from director6.ghost.mail-out.ovh.net (unknown [10.109.140.39])
 by mo582.mail-out.ovh.net (Postfix) with ESMTP id 4b83j91wPNz1V3B
 for ; Fri, 30 May 2025 13:18:53 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-jf7jg (unknown [10.110.96.35])
 by director6.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 2563980257;
 Fri, 30 May 2025 13:18:52 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.106])
 by ghost-submission-5b5ff79f4f-jf7jg with ESMTPSA
 id W9soOzuwOWg3twAAMsIQHg
 (envelope-from ); Fri, 30 May 2025 13:18: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" 
X-Inumbo-ID: a217e06e-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-106R00679701ec5-0cea-4536-851d-f45d9eef6760,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 08/22] x86/slaunch: restore boot MTRRs after Intel TXT DRTM
Date: Fri, 30 May 2025 16:17:50 +0300
Message-ID: <5b6b9bf165a4fd9444dc53848fb8faa2cea30781.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12699306524953392284
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeegkeffieeitdevkefhudegffevieeggfelgedvgeehffdtteehfeeuleeiudekvdenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekgedrvddvuddpfeejrdehledrudegvddruddtieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkedvmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=wR1hVbpxxN9SQ0YmcXd59qUIZ1ZgOyrRB96NJpE74ts=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611133; v=1;
 b=PMvC/81ouczRL8OJeS1H4LvnV8SeaCAuNjd/xU5Yh7XEGSmZGOqtbxQJQGVoekhjaZjNWsy7
 ywWqXeVEcu/tPro4xHpuUGEuwoHsS1fhuEISU57LwjwhqiyHLhphw8w4nmQtFsWoFXArUajhx24
 vs6W6srHf1ZXBrCW7r5IqpJjdjyBGF0jDTa8qu+HDMSGyKj/+mFwwGDN/tx5mVa7/YGNOfWboPK
 gWLFyZ0/CENTGXGeGRpPVZbN8mw9lXP/S5OQHLrB7slBtHqPXCp+FgeJYh4AK0QSdOJc99osmah
 z2yWgMo/vIjX3KFbAdqV0r9dPcgbjAfNRiZNl3jNev+nQ==

From: Krystian Hebel 

In preparation for TXT SENTER call, GRUB had to modify MTRR settings
to be UC for everything except SINIT ACM. Old values are restored
from SLRT where they were saved by the bootloader.

Signed-off-by: Krystian Hebel 
Signed-off-by: Michał Żygowski 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/e820.c                  |  5 ++
 xen/arch/x86/include/asm/intel-txt.h |  3 ++
 xen/arch/x86/intel-txt.c             | 75 ++++++++++++++++++++++++++++
 3 files changed, 83 insertions(+)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index ca577c0bde..60f00e5259 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /*
  * opt_mem: Limit maximum address of physical RAM.
@@ -442,6 +444,9 @@ static uint64_t __init mtrr_top_of_ram(void)
     ASSERT(paddr_bits);
     addr_mask = ((1ULL << paddr_bits) - 1) & PAGE_MASK;
 
+    if ( slaunch_active )
+        txt_restore_mtrrs(e820_verbose);
+
     rdmsrl(MSR_MTRRcap, mtrr_cap);
     rdmsrl(MSR_MTRRdefType, mtrr_def);
 
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index ad3c41d86c..0b0bdc1bb2 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -426,6 +426,9 @@ void txt_map_mem_regions(void);
 /* Marks TXT-specific memory as used to avoid its corruption. */
 void txt_reserve_mem_regions(void);
 
+/* Restores original MTRR values saved by a bootloader before starting DRTM. */
+void txt_restore_mtrrs(bool e820_verbose);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* X86_INTEL_TXT_H */
diff --git a/xen/arch/x86/intel-txt.c b/xen/arch/x86/intel-txt.c
index 163383b262..0c14d84486 100644
--- a/xen/arch/x86/intel-txt.c
+++ b/xen/arch/x86/intel-txt.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 static uint64_t __initdata txt_heap_base, txt_heap_size;
@@ -111,3 +113,76 @@ void __init txt_reserve_mem_regions(void)
                      E820_UNUSABLE);
     BUG_ON(rc == 0);
 }
+
+void __init txt_restore_mtrrs(bool e820_verbose)
+{
+    struct slr_entry_intel_info *intel_info;
+    uint64_t mtrr_cap, mtrr_def, base, mask;
+    unsigned int i;
+    uint64_t def_type;
+    struct mtrr_pausing_state pausing_state;
+
+    rdmsrl(MSR_MTRRcap, mtrr_cap);
+    rdmsrl(MSR_MTRRdefType, mtrr_def);
+
+    if ( e820_verbose )
+    {
+        printk("MTRRs set previously for SINIT ACM:\n");
+        printk(" MTRR cap: %"PRIx64" type: %"PRIx64"\n", mtrr_cap, mtrr_def);
+
+        for ( i = 0; i < (uint8_t)mtrr_cap; i++ )
+        {
+            rdmsrl(MSR_IA32_MTRR_PHYSBASE(i), base);
+            rdmsrl(MSR_IA32_MTRR_PHYSMASK(i), mask);
+
+            printk(" MTRR[%d]: base %"PRIx64" mask %"PRIx64"\n",
+                   i, base, mask);
+        }
+    }
+
+    intel_info = (struct slr_entry_intel_info *)
+        slr_next_entry_by_tag(slaunch_get_slrt(), NULL, SLR_ENTRY_INTEL_INFO);
+
+    if ( (mtrr_cap & 0xFF) != intel_info->saved_bsp_mtrrs.mtrr_vcnt )
+    {
+        printk("Bootloader saved %ld MTRR values, but there should be %ld\n",
+               intel_info->saved_bsp_mtrrs.mtrr_vcnt, mtrr_cap & 0xFF);
+        /* Choose the smaller one to be on the safe side. */
+        mtrr_cap = (mtrr_cap & 0xFF) > intel_info->saved_bsp_mtrrs.mtrr_vcnt ?
+                   intel_info->saved_bsp_mtrrs.mtrr_vcnt : mtrr_cap;
+    }
+
+    def_type = intel_info->saved_bsp_mtrrs.default_mem_type;
+    pausing_state = mtrr_pause_caching();
+
+    for ( i = 0; i < (uint8_t)mtrr_cap; i++ )
+    {
+        base = intel_info->saved_bsp_mtrrs.mtrr_pair[i].mtrr_physbase;
+        mask = intel_info->saved_bsp_mtrrs.mtrr_pair[i].mtrr_physmask;
+        wrmsrl(MSR_IA32_MTRR_PHYSBASE(i), base);
+        wrmsrl(MSR_IA32_MTRR_PHYSMASK(i), mask);
+    }
+
+    pausing_state.def_type = def_type;
+    mtrr_resume_caching(pausing_state);
+
+    if ( e820_verbose )
+    {
+        printk("Restored MTRRs:\n"); /* Printed by caller, mtrr_top_of_ram(). */
+
+        /* If MTRRs are not enabled or WB is not a default type, MTRRs won't be printed */
+        if ( !test_bit(11, &def_type) || ((uint8_t)def_type == X86_MT_WB) )
+        {
+            for ( i = 0; i < (uint8_t)mtrr_cap; i++ )
+            {
+                rdmsrl(MSR_IA32_MTRR_PHYSBASE(i), base);
+                rdmsrl(MSR_IA32_MTRR_PHYSMASK(i), mask);
+                printk(" MTRR[%d]: base %"PRIx64" mask %"PRIx64"\n",
+                       i, base, mask);
+            }
+        }
+    }
+
+    /* Restore IA32_MISC_ENABLES */
+    wrmsrl(MSR_IA32_MISC_ENABLE, intel_info->saved_misc_enable_msr);
+}
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:20:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:20:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000979.1381245 (Exim 4.92)
	(envelope-from )
	id 1uKzfH-0007X9-3s; Fri, 30 May 2025 13:20:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000979.1381245; Fri, 30 May 2025 13:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKzfH-0007X2-0X; Fri, 30 May 2025 13:20:51 +0000
Received: by outflank-mailman (input) for mailman id 1000979;
 Fri, 30 May 2025 13:20:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKze7-0003ZU-3j
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:39 +0000
Received: from 4.mo576.mail-out.ovh.net (4.mo576.mail-out.ovh.net
 [46.105.42.102]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id baae0b70-3d58-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:19:34 +0200 (CEST)
Received: from director3.ghost.mail-out.ovh.net (unknown [10.108.9.150])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4b83jy44vXz33bG
 for ; Fri, 30 May 2025 13:19:34 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-7mj9p (unknown [10.110.178.161])
 by director3.ghost.mail-out.ovh.net (Postfix) with ESMTPS id C68EDC3334;
 Fri, 30 May 2025 13:19:33 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.98])
 by ghost-submission-5b5ff79f4f-7mj9p with ESMTPSA
 id 3lLgJWWwOWhE4wAAMDjBXw
 (envelope-from ); Fri, 30 May 2025 13:19: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" 
X-Inumbo-ID: baae0b70-3d58-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-98R0024bd3e58b-6ef2-461f-a919-a86e5b2b2194,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 21/22] x86/cpu: report SMX, TXT and SKINIT capabilities
Date: Fri, 30 May 2025 16:18:03 +0300
Message-ID: <6fb0f217027fc323d3c23e94bb99bc56e06f9763.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12710847002492581020
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduvdculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeegkeffieeitdevkefhudegffevieeggfelgedvgeehffdtteehfeeuleeiudekvdenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekgedrvddvuddpfeejrdehledrudegvddrleeknecuvehluhhsthgvrhfuihiivgepgeenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheejiegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=ms5Oz9mARFyw7F3TkgqehvFJRD2s1RQlx2UtDwBUcCc=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611174; v=1;
 b=C6XLwEEbnykxW5WCFW8jHLZp64xfpb5SRpRsUQdRMVjN7TEmRlNs7QoW1amRsHyG+KqO7z3+
 oAXEKrwNcCfSw7IPy9V4jWynYKJ1FaJghakTlgHaxZiQaVIZw77iZMv2SXQVdrUZ24esqF2TBoB
 gfOUHnlIIbWihbhi80t+CODpnGw1dIV+b9GRnAlvHRXEeoduVU/MqBtXIWil2F5GcP+OkyQIt4t
 CwbeliALJ8PQFIUwWNeGRLzuNQygt9L40ou5byjwcpQqPHgq1/YuoaCHWoRMBA5IKrErppAYUPc
 zU8mMFm75oMVQ9XhinXvi0aPSsDbnH42lis7PmUMrV2yA==

From: Michał Żygowski 

Report TXT capabilities so that dom0 can query the Intel TXT or AMD
SKINIT support information using xl dmesg.

Signed-off-by: Michał Żygowski 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/cpu/amd.c               | 16 ++++++++++
 xen/arch/x86/cpu/cpu.h               |  1 +
 xen/arch/x86/cpu/hygon.c             |  1 +
 xen/arch/x86/cpu/intel.c             | 46 ++++++++++++++++++++++++++++
 xen/arch/x86/include/asm/intel-txt.h |  5 +++
 5 files changed, 69 insertions(+)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 27ae167808..e630a0bb2a 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -688,6 +688,21 @@ void amd_log_freq(const struct cpuinfo_x86 *c)
 #undef FREQ
 }
 
+void amd_log_skinit(const struct cpuinfo_x86 *c)
+{
+    /*
+     * Run only on BSP and not during resume to report the capability only once.
+     */
+    if ( system_state != SYS_STATE_resume && smp_processor_id() )
+        return;
+
+    printk("CPU: SKINIT capability ");
+    if ( !test_bit(X86_FEATURE_SKINIT, &boot_cpu_data.x86_capability) )
+        printk("not supported\n");
+    else
+        printk("supported\n");
+}
+
 void cf_check early_init_amd(struct cpuinfo_x86 *c)
 {
 	if (c == &boot_cpu_data)
@@ -1337,6 +1352,7 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
 	check_syscfg_dram_mod_en();
 
 	amd_log_freq(c);
+	amd_log_skinit(c);
 }
 
 const struct cpu_dev __initconst_cf_clobber amd_cpu_dev = {
diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h
index cbb434f3a2..94132394aa 100644
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -24,6 +24,7 @@ extern bool detect_extended_topology(struct cpuinfo_x86 *c);
 
 void cf_check early_init_amd(struct cpuinfo_x86 *c);
 void amd_log_freq(const struct cpuinfo_x86 *c);
+void amd_log_skinit(const struct cpuinfo_x86 *c);
 void amd_init_lfence(struct cpuinfo_x86 *c);
 void amd_init_ssbd(const struct cpuinfo_x86 *c);
 void amd_init_spectral_chicken(void);
diff --git a/xen/arch/x86/cpu/hygon.c b/xen/arch/x86/cpu/hygon.c
index f7508cc8fc..6ebb8b5fab 100644
--- a/xen/arch/x86/cpu/hygon.c
+++ b/xen/arch/x86/cpu/hygon.c
@@ -85,6 +85,7 @@ static void cf_check init_hygon(struct cpuinfo_x86 *c)
 	}
 
 	amd_log_freq(c);
+	amd_log_skinit(c);
 }
 
 const struct cpu_dev __initconst_cf_clobber hygon_cpu_dev = {
diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index ef9368167a..ed9cdd064f 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cpu.h"
 
@@ -633,6 +634,49 @@ static void init_intel_perf(struct cpuinfo_x86 *c)
     }
 }
 
+/*
+ * Print out the SMX and TXT capabilties, so that dom0 can determine if the
+ * system is DRTM-capable.
+ */
+static void intel_log_smx_txt(void)
+{
+    unsigned long cr4_val, getsec_caps;
+
+    /*
+     * Run only on BSP and not during resume to report the capability only once.
+     */
+    if ( system_state != SYS_STATE_resume && smp_processor_id() )
+        return;
+
+    printk("CPU: SMX capability ");
+    if ( !test_bit(X86_FEATURE_SMX, &boot_cpu_data.x86_capability) )
+    {
+        printk("not supported\n");
+        return;
+    }
+    printk("supported\n");
+
+    /* Can't run GETSEC without VMX and SMX */
+    if ( !test_bit(X86_FEATURE_VMX, &boot_cpu_data.x86_capability) )
+        return;
+
+    cr4_val = read_cr4();
+    if ( !(cr4_val & X86_CR4_SMXE) )
+        write_cr4(cr4_val | X86_CR4_SMXE);
+
+    asm volatile ("getsec\n"
+        : "=a" (getsec_caps)
+        : "a" (GETSEC_CAPABILITIES), "b" (0) :);
+
+    if ( getsec_caps & GETSEC_CAP_TXT_CHIPSET )
+        printk("Chipset supports TXT\n");
+    else
+        printk("Chipset does not support TXT\n");
+
+    if ( !(cr4_val & X86_CR4_SMXE) )
+        write_cr4(cr4_val & ~X86_CR4_SMXE);
+}
+
 static void cf_check init_intel(struct cpuinfo_x86 *c)
 {
 	/* Detect the extended topology information if available */
@@ -647,6 +691,8 @@ static void cf_check init_intel(struct cpuinfo_x86 *c)
 		detect_ht(c);
 	}
 
+	intel_log_smx_txt();
+
 	/* Work around errata */
 	Intel_errata_workarounds(c);
 
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index c032ebb2e1..af388ade02 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -94,6 +94,11 @@
 #define TXT_AP_BOOT_CS                  0x0030
 #define TXT_AP_BOOT_DS                  0x0038
 
+/* EAX value for GETSEC leaf functions. Intel SDM: GETSEC[CAPABILITIES] */
+#define GETSEC_CAPABILITIES             0
+/* Intel SDM: GETSEC Capability Result Encoding */
+#define GETSEC_CAP_TXT_CHIPSET          1
+
 #ifndef __ASSEMBLY__
 
 #include 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:20:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:20:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000982.1381249 (Exim 4.92)
	(envelope-from )
	id 1uKzfH-0007aC-Ct; Fri, 30 May 2025 13:20:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000982.1381249; Fri, 30 May 2025 13:20:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKzfH-0007YY-7X; Fri, 30 May 2025 13:20:51 +0000
Received: by outflank-mailman (input) for mailman id 1000982;
 Fri, 30 May 2025 13:20:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdc-0008Jy-JQ
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:08 +0000
Received: from 9.mo561.mail-out.ovh.net (9.mo561.mail-out.ovh.net
 [87.98.184.141]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a932ea8e-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:19:05 +0200 (CEST)
Received: from director5.ghost.mail-out.ovh.net (unknown [10.109.176.180])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4b83jP1cy2z1YFn
 for ; Fri, 30 May 2025 13:19:05 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-sqk4q (unknown [10.110.168.56])
 by director5.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 77CA610022F;
 Fri, 30 May 2025 13:19:04 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.103])
 by ghost-submission-5b5ff79f4f-sqk4q with ESMTPSA
 id nUD9EEiwOWgXJgAAZ+UDpg
 (envelope-from ); Fri, 30 May 2025 13:19: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" 
X-Inumbo-ID: a932ea8e-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-103G005baab5605-d08e-4e2c-a3be-21458a63de71,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 12/22] x86/hvm: check for VMX in SMX if Slaunch is active
Date: Fri, 30 May 2025 16:17:54 +0300
Message-ID: <25de2a5ba43629cca33b96d20c77f19d64096242.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12702684225100625052
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepufgvrhhgihhiucffmhihthhruhhkuceoshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmqeenucggtffrrghtthgvrhhnpeegkeffieeitdevkefhudegffevieeggfelgedvgeehffdtteehfeeuleeiudekvdenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekgedrvddvuddpfeejrdehledrudegvddruddtfeenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehiedumgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=obSSiy8YAHm2T2PniWDCTzac2MGgksM6oibQ6iXFGMY=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611145; v=1;
 b=KnQZv8WLUXETTFEQ2abZsscZIgP0ZcCLoZ2Bli4n4ItYmqdUYAtfwWaFuD8LUXd+noBHCgch
 ZZnTJEE8g0D8K29rvNOxbSAzyr3kRiv8PID4qEs+3GTNPyAYFM1Pf/nZVli6T9LcrzU8Dwf0Rtg
 DlUBSumOo/9zXJ8O5w1ZkDLOE37hDXDHwF1I9hjnyJFWKXEKX2p3UHGlnQpKPMENCZauT/vVVvo
 ipWZ5JZejWAaGhDPRe1wKMSXt6Mh5N4XNaT904xvPmLc7Cz+SATbivuvVoouG/pDWKmyn+jmhG1
 muOgvoW7wFNDPiui0pgyw2jDMDUWfcWS6mtJJE8mMYCFw==

From: Michał Żygowski 

Check whther IA32_FEATURE_CONTROL has the proper bits enabled to run
VMX in SMX when slaunch is active.

Signed-off-by: Michał Żygowski 
---
 xen/arch/x86/hvm/vmx/vmcs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 57d49364db..835a6be75a 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -724,7 +725,7 @@ static int _vmx_cpu_up(bool bsp)
     bios_locked = !!(eax & IA32_FEATURE_CONTROL_LOCK);
     if ( bios_locked )
     {
-        if ( !(eax & (tboot_in_measured_env()
+        if ( !(eax & (tboot_in_measured_env() || slaunch_active
                       ? IA32_FEATURE_CONTROL_ENABLE_VMXON_INSIDE_SMX
                       : IA32_FEATURE_CONTROL_ENABLE_VMXON_OUTSIDE_SMX)) )
         {
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:21:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:21:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1000995.1381266 (Exim 4.92)
	(envelope-from )
	id 1uKzfb-0000Ww-KT; Fri, 30 May 2025 13:21:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1000995.1381266; Fri, 30 May 2025 13: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 1uKzfb-0000Wn-HB; Fri, 30 May 2025 13:21:11 +0000
Received: by outflank-mailman (input) for mailman id 1000995;
 Fri, 30 May 2025 13:21:10 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzds-0008Jy-Lg
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:24 +0000
Received: from 5.mo561.mail-out.ovh.net (5.mo561.mail-out.ovh.net
 [87.98.178.36]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b0b6fdb1-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:19:18 +0200 (CEST)
Received: from director7.ghost.mail-out.ovh.net (unknown [10.108.25.131])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4b83jd4fctz1fvP
 for ; Fri, 30 May 2025 13:19:17 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-ptgrr (unknown [10.108.54.144])
 by director7.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 80185C06D1;
 Fri, 30 May 2025 13:19:16 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.113])
 by ghost-submission-5b5ff79f4f-ptgrr with ESMTPSA
 id xqfoDFSwOWio8AAA2loDpw
 (envelope-from ); Fri, 30 May 2025 13:19: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" 
X-Inumbo-ID: b0b6fdb1-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-113S0074fb95b9e-83ce-4588-b545-b055bf4ee8c1,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	Ross Philipson ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 16/22] x86/slaunch: process DRTM policy
Date: Fri, 30 May 2025 16:17:58 +0300
Message-ID: <8cce3c111a2dceaf4fcf33f8f8d5632a321dfacd.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12706061926178534556
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhephfehfeehudeileeikeffgfffgfefuddtveelvedvhfffgfelvdfgtddutdehfeeinecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduudefnecuvehluhhsthgvrhfuihiivgepfeenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheeiudgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=m5usq3QTRGIaGl8YW2FD4N9j9KXlGN9QTdRCtYRkM1M=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611157; v=1;
 b=E5NhPU9p90IfaVvoT6SCTtwm+E5O7xwUynvNJGN/aTYeDda9yZuC1frlOZ4jK62wXEFs043A
 Q+3NN+066PwwZGBFGvqKJHFfRouBIZFmE8mqi3CWY5qZyaxQCR2R1+b0zxJaGGZ4FPFdtkMLa/E
 dmiV+CjH12++6/sy39BzRxehL7w2ePC8lBtRgc5l9CEmCXzNQhHyMFP9Rgt4WRagUMYDPjLqVze
 SM7qQ1H05Ysl0rwM8a04FCtpASNORnBo5wVkQK0xQWVTVlCe/h2wSKajQVJCtnt59J80Y5GXkgq
 QybDRXXD2/WYM77ZNtCt2CokZOP017ej0GRTUTKSXTuYA==

Go through entires in the DRTM policy of SLRT to hash and extend data
that they describe into corresponding PCRs.

Addresses are being zeroed on measuring platform-specific data to
prevent measurements from changing when the only thing that has changed
is an address.  Addresses can vary due to bootloader, firmware or user
doing something differently or just if GRUB gets bigger in size due to
inclusion of more modules and ends up offsetting newly allocated memory.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/include/asm/slaunch.h |  14 ++
 xen/arch/x86/setup.c               |  15 ++
 xen/arch/x86/slaunch.c             | 213 +++++++++++++++++++++++++++++
 3 files changed, 242 insertions(+)

diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
index 3b38045864..62ba41d56e 100644
--- a/xen/arch/x86/include/asm/slaunch.h
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -24,6 +24,8 @@
 #define DLE_EVTYPE_SLAUNCH_START   (DLE_EVTYPE_BASE + 0x103)
 #define DLE_EVTYPE_SLAUNCH_END     (DLE_EVTYPE_BASE + 0x104)
 
+struct boot_info;
+
 /* Indicates an active Secure Launch boot. */
 extern bool slaunch_active;
 
@@ -69,6 +71,18 @@ void slaunch_map_mem_regions(void);
 /* Marks regions of memory as used to avoid their corruption. */
 void slaunch_reserve_mem_regions(void);
 
+/* Measures essential parts of SLR table before making use of them. */
+void slaunch_measure_slrt(void);
+
+/*
+ * Takes measurements of DRTM policy entries except for MBI and SLRT which
+ * should have been measured by the time this is called. Also performs sanity
+ * checks of the policy and panics on failure. In particular, the function
+ * verifies that DRTM is consistent with modules obtained from MultibootInfo
+ * (MBI) and written to struct boot_info in setup.c.
+ */
+void slaunch_process_drtm_policy(const struct boot_info *bi);
+
 /*
  * This helper function is used to map memory using L2 page tables by aligning
  * mapped regions to 2MB. This way page allocator (which at this point isn't
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 87e4693a11..063ac49b8a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1426,6 +1426,13 @@ void asmlinkage __init noreturn __start_xen(void)
     if ( slaunch_active )
     {
         slaunch_map_mem_regions();
+
+        /*
+         * SLRT needs to be measured here because it is used by init_e820(), the
+         * rest is measured slightly below by slaunch_process_drtm_policy().
+         */
+        slaunch_measure_slrt();
+
         slaunch_reserve_mem_regions();
     }
 
@@ -1447,6 +1454,14 @@ void asmlinkage __init noreturn __start_xen(void)
     /* Create a temporary copy of the E820 map. */
     memcpy(&boot_e820, &e820, sizeof(e820));
 
+    /*
+     * Process all yet unmeasured DRTM entries after E820 initialization to not
+     * do this while memory is uncached (too slow). This must also happen before
+     * modules are relocated or used.
+     */
+    if ( slaunch_active )
+        slaunch_process_drtm_policy(bi);
+
     /* Early kexec reservation (explicit static start address). */
     nr_pages = 0;
     for ( i = 0; i < e820.nr_map; i++ )
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index 5f91fe5ad0..2390d0a3f3 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -9,9 +9,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -107,6 +109,217 @@ void __init slaunch_reserve_mem_regions(void)
     }
 }
 
+void __init slaunch_measure_slrt(void)
+{
+    struct slr_table *slrt = slaunch_get_slrt();
+
+    if ( slrt->revision == 1 )
+    {
+        /*
+         * In revision one of the SLRT, only platform-specific info table is
+         * measured.
+         */
+        struct slr_entry_intel_info tmp;
+        struct slr_entry_intel_info *entry;
+
+        entry = (struct slr_entry_intel_info *)
+            slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+        if ( entry == NULL )
+            panic("SLRT is missing Intel-specific information!\n");
+
+        tmp = *entry;
+        tmp.boot_params_base = 0;
+        tmp.txt_heap = 0;
+
+        tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
+                        sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+    }
+    else
+    {
+        /*
+         * slaunch_get_slrt() checks that the revision is valid, so we must not get
+         * here unless the code is wrong.
+         */
+        panic("Unhandled SLRT revision: %d!\n", slrt->revision);
+    }
+}
+
+static const struct slr_entry_policy *__init
+slr_get_policy(const struct slr_table *slrt)
+{
+    struct slr_entry_policy *policy;
+
+    policy = (struct slr_entry_policy *)
+        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DRTM_POLICY);
+    if (policy == NULL)
+        panic("SLRT is missing DRTM policy!\n");
+
+    /* XXX: are newer revisions allowed? */
+    if ( policy->revision != SLR_POLICY_REVISION )
+        panic("DRTM policy in SLRT is of unsupported revision: %#04x!\n",
+              slrt->revision);
+
+    return policy;
+}
+
+static void __init
+check_slrt_policy_entry(struct slr_policy_entry *policy_entry,
+                        int idx,
+                        const struct slr_table *slrt)
+{
+    if ( policy_entry->entity_type != SLR_ET_SLRT )
+        panic("Expected DRTM policy entry #%d to describe SLRT, got %#04x!\n",
+              idx, policy_entry->entity_type);
+    if ( policy_entry->pcr != DRTM_DATA_PCR )
+        panic("SLRT was measured to PCR-%d instead of PCR-%d!\n", DRTM_DATA_PCR,
+              policy_entry->pcr);
+    if ( policy_entry->entity != (uint64_t)__pa(slrt) )
+        panic("SLRT address (%#08lx) differs from its DRTM entry (%#08lx)\n",
+              __pa(slrt), policy_entry->entity);
+}
+
+/* Returns number of policy entries that were already measured. */
+static unsigned int __init
+check_drtm_policy(const struct slr_table *slrt,
+                  const struct slr_entry_policy *policy,
+                  struct slr_policy_entry *policy_entry,
+                  const struct boot_info *bi)
+{
+    uint32_t i;
+    uint32_t num_mod_entries;
+
+    if ( policy->nr_entries < 2 )
+        panic("DRTM policy in SLRT contains less than 2 entries (%d)!\n",
+              policy->nr_entries);
+
+    /*
+     * MBI policy entry must be the first one, so that measuring order matches
+     * policy order.
+     */
+    if ( policy_entry[0].entity_type != SLR_ET_MULTIBOOT2_INFO )
+        panic("First entry of DRTM policy in SLRT is not MBI: %#04x!\n",
+              policy_entry[0].entity_type);
+    if ( policy_entry[0].pcr != DRTM_DATA_PCR )
+        panic("MBI was measured to %d instead of %d PCR!\n", DRTM_DATA_PCR,
+              policy_entry[0].pcr);
+
+    /* SLRT policy entry must be the second one. */
+    check_slrt_policy_entry(&policy_entry[1], 1, slrt);
+
+    for ( i = 0; i < bi->nr_modules; i++ )
+    {
+        uint16_t j;
+        const struct boot_module *mod = &bi->mods[i];
+
+        if (mod->relocated || mod->released)
+        {
+            panic("Multiboot module \"%s\" (at %d) was consumed before measurement\n",
+                  (const char *)__va(mod->cmdline_pa), i);
+        }
+
+        for ( j = 2; j < policy->nr_entries; j++ )
+        {
+            if ( policy_entry[j].entity_type != SLR_ET_MULTIBOOT2_MODULE )
+                continue;
+
+            if ( policy_entry[j].entity == mod->start &&
+                 policy_entry[j].size == mod->size )
+                break;
+        }
+
+        if ( j >= policy->nr_entries )
+        {
+            panic("Couldn't find Multiboot module \"%s\" (at %d) in DRTM of Secure Launch\n",
+                  (const char *)__va(mod->cmdline_pa), i);
+        }
+    }
+
+    num_mod_entries = 0;
+    for ( i = 0; i < policy->nr_entries; i++ )
+    {
+        if ( policy_entry[i].entity_type == SLR_ET_MULTIBOOT2_MODULE )
+            num_mod_entries++;
+    }
+
+    if ( bi->nr_modules != num_mod_entries )
+    {
+        panic("Unexpected number of Multiboot modules: %d instead of %d\n",
+              (int)bi->nr_modules, (int)num_mod_entries);
+    }
+
+    /*
+     * MBI was measured in tpm_extend_mbi().
+     * SLRT was measured in tpm_measure_slrt().
+     */
+    return 2;
+}
+
+void __init slaunch_process_drtm_policy(const struct boot_info *bi)
+{
+    const struct slr_table *slrt;
+    const struct slr_entry_policy *policy;
+    struct slr_policy_entry *policy_entry;
+    uint16_t i;
+    unsigned int measured;
+
+    slrt = slaunch_get_slrt();
+
+    policy = slr_get_policy(slrt);
+    policy_entry = (void *)policy + sizeof(*policy);
+
+    measured = check_drtm_policy(slrt, policy, policy_entry, bi);
+    for ( i = 0; i < measured; i++ )
+        policy_entry[i].flags |= SLR_POLICY_FLAG_MEASURED;
+
+    for ( i = measured; i < policy->nr_entries; i++ )
+    {
+        int rc;
+        uint64_t start = policy_entry[i].entity;
+        uint64_t size = policy_entry[i].size;
+
+        /* No already measured entries are expected here. */
+        if ( policy_entry[i].flags & SLR_POLICY_FLAG_MEASURED )
+            panic("DRTM entry at %d was measured out of order!\n", i);
+
+        switch ( policy_entry[i].entity_type )
+        {
+        case SLR_ET_MULTIBOOT2_INFO:
+            panic("Duplicated MBI entry in DRTM of Secure Launch at %d\n", i);
+        case SLR_ET_SLRT:
+            panic("Duplicated SLRT entry in DRTM of Secure Launch at %d\n", i);
+
+        case SLR_ET_UNSPECIFIED:
+        case SLR_ET_BOOT_PARAMS:
+        case SLR_ET_SETUP_DATA:
+        case SLR_ET_CMDLINE:
+        case SLR_ET_UEFI_MEMMAP:
+        case SLR_ET_RAMDISK:
+        case SLR_ET_MULTIBOOT2_MODULE:
+        case SLR_ET_TXT_OS2MLE:
+            /* Measure this entry below. */
+            break;
+
+        case SLR_ET_UNUSED:
+            /* Skip this entry. */
+            continue;
+        }
+
+        if ( policy_entry[i].flags & SLR_POLICY_IMPLICIT_SIZE )
+            panic("Unexpected implicitly-sized DRTM entry of Secure Launch at %d (type %d, info: %s)\n",
+                  i, policy_entry[i].entity_type, policy_entry[i].evt_info);
+
+        rc = slaunch_map_l2(start, size);
+        BUG_ON(rc != 0);
+
+        tpm_hash_extend(DRTM_LOC, policy_entry[i].pcr, __va(start), size,
+                        DLE_EVTYPE_SLAUNCH, (uint8_t *)policy_entry[i].evt_info,
+                        strnlen(policy_entry[i].evt_info,
+                                TPM_EVENT_INFO_LENGTH));
+
+        policy_entry[i].flags |= SLR_POLICY_FLAG_MEASURED;
+    }
+}
+
 int __init slaunch_map_l2(unsigned long paddr, unsigned long size)
 {
     unsigned long aligned_paddr = paddr & ~((1ULL << L2_PAGETABLE_SHIFT) - 1);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:21:36 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:21:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001009.1381277 (Exim 4.92)
	(envelope-from )
	id 1uKzfz-0001TN-Tt; Fri, 30 May 2025 13:21:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001009.1381277; Fri, 30 May 2025 13: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 1uKzfz-0001TG-Ph; Fri, 30 May 2025 13:21:35 +0000
Received: by outflank-mailman (input) for mailman id 1001009;
 Fri, 30 May 2025 13:21:34 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdU-0008Jy-Pt
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:00 +0000
Received: from 2.mo576.mail-out.ovh.net (2.mo576.mail-out.ovh.net
 [178.33.251.80]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a5afd443-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:18:59 +0200 (CEST)
Received: from director4.ghost.mail-out.ovh.net (unknown [10.108.25.63])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4b83jH2PX6z32tv
 for ; Fri, 30 May 2025 13:18:59 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-d5dtf (unknown [10.110.188.251])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id A0261C5715;
 Fri, 30 May 2025 13:18:58 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.104])
 by ghost-submission-5b5ff79f4f-d5dtf with ESMTPSA
 id TDFDHkKwOWiVuB4AAS47Dg
 (envelope-from ); Fri, 30 May 2025 13:18: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" 
X-Inumbo-ID: a5afd443-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-104R0052f59d384-b7d7-485b-afb3-3b2b0e54e04f,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 10/22] x86/tpm.c: code for early hashing and extending PCRs (for TPM1.2)
Date: Fri, 30 May 2025 16:17:52 +0300
Message-ID: <0c249037eeda4809b565a55c6473bb21cdd0304e.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12700995376294179996
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduvdculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepffejgfduveektedugeeuiefhtdfhjefgieelkeeugfeggedtgeevheefheeffeeunecuffhomhgrihhnpegsrghsvgdrmhgrphdphhgvrggurdhssgenucfkphepuddvjedrtddrtddruddpudejiedrudduuddrudekgedrvddvuddpfeejrdehledrudegvddruddtgeenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehjeeimgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=0x2mnB2zALc+h57HnIXgGV7sg4jfhRh/4OId+n19BXc=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611139; v=1;
 b=LGc4CPtqUYlE2GZ7PtzAKsBx9oPJ8gHPfOTF9bvdEerNr6uutmqXG8r7pRyoR9xwuip2fVsr
 Cr+E1n4YUiXtoMxb/LXeW4f/PXOgDvwNT0I+hVpRT4I50mMEl340XR4hJWmJ+tJgcecvbrl5GF+
 gVAbloSdUolRtKC8fWC50Rqz+GY6dFaKluWhFJrRqQOs4+M3vUn/0kVSPLhRDNqJ7GBqKYmDi8j
 BPtRw9jgwOAsiqvZ2tS6IU3uZS/9EfOPvAY35Hka6oxmkGSYoguuUBM2azQN5X1Yb1vdUxuTRUP
 wpefD5BZj7i5SeMc/ETKckDRRdAtXB6Npb2A90cDeCunA==

From: Krystian Hebel 

This file is built twice: for early 32b mode without paging to measure
MBI and for 64b code to measure dom0 kernel and initramfs. Since MBI
is small, the first case uses TPM to do the hashing. Kernel and
initramfs on the other hand are too big, sending them to the TPM would
take multiple minutes.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/Makefile              |   1 +
 xen/arch/x86/boot/Makefile         |   7 +-
 xen/arch/x86/boot/head.S           |   3 +
 xen/arch/x86/include/asm/slaunch.h |  14 +
 xen/arch/x86/include/asm/tpm.h     |  19 ++
 xen/arch/x86/slaunch.c             |   7 +-
 xen/arch/x86/tpm.c                 | 437 +++++++++++++++++++++++++++++
 7 files changed, 486 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/tpm.h
 create mode 100644 xen/arch/x86/tpm.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 5788898166..2d008a5f52 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -66,6 +66,7 @@ obj-y += spec_ctrl.o
 obj-y += srat.o
 obj-y += string.o
 obj-y += time.o
+obj-y += tpm.o
 obj-y += traps-setup.o
 obj-y += traps.o
 obj-$(CONFIG_INTEL) += tsx.o
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5471b966dd..55fbe155b6 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -6,6 +6,7 @@ obj32 := cmdline.32.o
 obj32 += reloc.32.o
 obj32 += reloc-trampoline.32.o
 obj32 += slaunch-early.32.o
+obj32 += tpm-early.32.o
 
 obj64 := reloc-trampoline.o
 
@@ -31,6 +32,10 @@ $(obj)/%.32.o: $(src)/%.c FORCE
 
 $(obj)/slaunch-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
 
+$(obj)/tpm-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
+$(obj)/tpm-early.32.o: $(src)/../tpm.c FORCE
+	$(call if_changed_rule,cc_o_c)
+
 orphan-handling-$(call ld-option,--orphan-handling=error) := --orphan-handling=error
 LDFLAGS_DIRECT-$(call ld-option,--warn-rwx-segments) := --no-warn-rwx-segments
 LDFLAGS_DIRECT += $(LDFLAGS_DIRECT-y)
@@ -84,7 +89,7 @@ cmd_combine = \
               --bin1      $(obj)/built-in-32.base.bin \
               --bin2      $(obj)/built-in-32.offset.bin \
               --map       $(obj)/built-in-32.base.map \
-              --exports   cmdline_parse_early,reloc,reloc_trampoline32,slaunch_early_init \
+              --exports   cmdline_parse_early,reloc,reloc_trampoline32,slaunch_early_init,tpm_extend_mbi \
               --output    $@
 
 targets += built-in-32.S
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index b4cf423c80..9a272155e9 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -527,6 +527,9 @@ __start:
         /* Store MBI address in EBX where MB2 code expects it. */
         mov     %eax, %ebx
 
+        /* tpm_extend_mbi(mbi/eax, slrt/edx) using fastcall. */
+        call    tpm_extend_mbi
+
         /* Move magic number expected by Multiboot 2 to EAX and fall through. */
         movl    $MULTIBOOT2_BOOTLOADER_MAGIC, %eax
 
diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
index 7891d60035..3b38045864 100644
--- a/xen/arch/x86/include/asm/slaunch.h
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -10,6 +10,20 @@
 #include 
 #include 
 
+#define DRTM_LOC                   2
+#define DRTM_CODE_PCR              17
+#define DRTM_DATA_PCR              18
+
+/*
+ * Secure Launch event log entry types. The TXT specification defines the base
+ * event value as 0x400 for DRTM values, use it regardless of the DRTM for
+ * consistency.
+ */
+#define DLE_EVTYPE_BASE            0x400
+#define DLE_EVTYPE_SLAUNCH         (DLE_EVTYPE_BASE + 0x102)
+#define DLE_EVTYPE_SLAUNCH_START   (DLE_EVTYPE_BASE + 0x103)
+#define DLE_EVTYPE_SLAUNCH_END     (DLE_EVTYPE_BASE + 0x104)
+
 /* Indicates an active Secure Launch boot. */
 extern bool slaunch_active;
 
diff --git a/xen/arch/x86/include/asm/tpm.h b/xen/arch/x86/include/asm/tpm.h
new file mode 100644
index 0000000000..d1e791fc69
--- /dev/null
+++ b/xen/arch/x86/include/asm/tpm.h
@@ -0,0 +1,19 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#ifndef X86_TPM_H
+#define X86_TPM_H
+
+#include 
+
+#define TPM_TIS_BASE  0xfed40000U
+#define TPM_TIS_SIZE  0x00010000U
+
+void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
+                     unsigned size, uint32_t type, const uint8_t *log_data,
+                     unsigned log_data_size);
+
+#endif /* X86_TPM_H */
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index ac3b43942b..5f91fe5ad0 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * These variables are assigned to by the code near Xen's entry point.
@@ -66,16 +67,20 @@ struct slr_table *__init slaunch_get_slrt(void)
 
 void __init slaunch_map_mem_regions(void)
 {
+    int rc;
     void *evt_log_addr;
     uint32_t evt_log_size;
 
+    rc = slaunch_map_l2(TPM_TIS_BASE, TPM_TIS_SIZE);
+    BUG_ON(rc != 0);
+
     /* Vendor-specific part. */
     txt_map_mem_regions();
 
     find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
     if ( evt_log_addr != NULL )
     {
-        int rc = slaunch_map_l2((uintptr_t)evt_log_addr, evt_log_size);
+        rc = slaunch_map_l2((uintptr_t)evt_log_addr, evt_log_size);
         BUG_ON(rc != 0);
     }
 }
diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
new file mode 100644
index 0000000000..7fb19ce4fa
--- /dev/null
+++ b/xen/arch/x86/tpm.c
@@ -0,0 +1,437 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * Copyright (c) 2022-2025 3mdeb Sp. z o.o. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef __EARLY_SLAUNCH__
+
+#ifdef __va
+#error "__va defined in non-paged mode!"
+#endif
+
+#define __va(x)     _p(x)
+
+/* Implementation of slaunch_get_slrt() for early TPM code. */
+static uint32_t slrt_location;
+struct slr_table *slaunch_get_slrt(void)
+{
+    return __va(slrt_location);
+}
+
+/*
+ * The code is being compiled as a standalone binary without linking to any
+ * other part of Xen.  Providing implementation of builtin functions in this
+ * case is necessary if compiler chooses to not use an inline builtin.
+ */
+void *(memcpy)(void *dest, const void *src, size_t n)
+{
+    const uint8_t *s = src;
+    uint8_t *d = dest;
+
+    while ( n-- )
+        *d++ = *s++;
+
+    return dest;
+}
+
+#else   /* __EARLY_SLAUNCH__ */
+
+#include 
+#include 
+
+#endif  /* __EARLY_SLAUNCH__ */
+
+#define TPM_LOC_REG(loc, reg)   (0x1000 * (loc) + (reg))
+
+#define TPM_ACCESS_(x)          TPM_LOC_REG(x, 0x00)
+#define ACCESS_REQUEST_USE       (1 << 1)
+#define ACCESS_ACTIVE_LOCALITY   (1 << 5)
+#define TPM_INTF_CAPABILITY_(x) TPM_LOC_REG(x, 0x14)
+#define INTF_VERSION_MASK        0x70000000
+#define TPM_STS_(x)             TPM_LOC_REG(x, 0x18)
+#define TPM_FAMILY_MASK          0x0C000000
+#define STS_DATA_AVAIL           (1 << 4)
+#define STS_TPM_GO               (1 << 5)
+#define STS_COMMAND_READY        (1 << 6)
+#define STS_VALID                (1 << 7)
+#define TPM_DATA_FIFO_(x)       TPM_LOC_REG(x, 0x24)
+
+#define swap16(x)       __builtin_bswap16(x)
+#define swap32(x)       __builtin_bswap32(x)
+
+static inline volatile uint32_t tis_read32(unsigned reg)
+{
+    return *(volatile uint32_t *)__va(TPM_TIS_BASE + reg);
+}
+
+static inline volatile uint8_t tis_read8(unsigned reg)
+{
+    return *(volatile uint8_t *)__va(TPM_TIS_BASE + reg);
+}
+
+static inline void tis_write8(unsigned reg, uint8_t val)
+{
+    *(volatile uint8_t *)__va(TPM_TIS_BASE + reg) = val;
+}
+
+static inline void request_locality(unsigned loc)
+{
+    tis_write8(TPM_ACCESS_(loc), ACCESS_REQUEST_USE);
+    /* Check that locality was actually activated. */
+    while ( (tis_read8(TPM_ACCESS_(loc)) & ACCESS_ACTIVE_LOCALITY) == 0 );
+}
+
+static inline void relinquish_locality(unsigned loc)
+{
+    tis_write8(TPM_ACCESS_(loc), ACCESS_ACTIVE_LOCALITY);
+}
+
+static void send_cmd(unsigned loc, uint8_t *buf, unsigned i_size,
+                     unsigned *o_size)
+{
+    /*
+     * Value of "data available" bit counts only when "valid" field is set as
+     * well.
+     */
+    const unsigned data_avail = STS_VALID | STS_DATA_AVAIL;
+
+    unsigned i;
+
+    /* Make sure TPM can accept a command. */
+    if ( (tis_read8(TPM_STS_(loc)) & STS_COMMAND_READY) == 0 )
+    {
+        /* Abort current command. */
+        tis_write8(TPM_STS_(loc), STS_COMMAND_READY);
+        /* Wait until TPM is ready for a new one. */
+        while ( (tis_read8(TPM_STS_(loc)) & STS_COMMAND_READY) == 0 );
+    }
+
+    for ( i = 0; i < i_size; i++ )
+        tis_write8(TPM_DATA_FIFO_(loc), buf[i]);
+
+    tis_write8(TPM_STS_(loc), STS_TPM_GO);
+
+    /* Wait for the first byte of response. */
+    while ( (tis_read8(TPM_STS_(loc)) & data_avail) != data_avail);
+
+    for ( i = 0; i < *o_size && tis_read8(TPM_STS_(loc)) & data_avail; i++ )
+        buf[i] = tis_read8(TPM_DATA_FIFO_(loc));
+
+    if ( i < *o_size )
+        *o_size = i;
+
+    tis_write8(TPM_STS_(loc), STS_COMMAND_READY);
+}
+
+static inline bool is_tpm12(void)
+{
+    /*
+     * If one of these conditions is true:
+     *  - INTF_CAPABILITY_x.interfaceVersion is 0 (TIS <= 1.21)
+     *  - INTF_CAPABILITY_x.interfaceVersion is 2 (TIS == 1.3)
+     *  - STS_x.tpmFamily is 0
+     * we're dealing with TPM1.2.
+     */
+    uint32_t intf_version = tis_read32(TPM_INTF_CAPABILITY_(0))
+                          & INTF_VERSION_MASK;
+    return (intf_version == 0x00000000 || intf_version == 0x20000000 ||
+            (tis_read32(TPM_STS_(0)) & TPM_FAMILY_MASK) == 0);
+}
+
+/****************************** TPM1.2 specific *******************************/
+#define TPM_ORD_Extend              0x00000014
+#define TPM_ORD_SHA1Start           0x000000A0
+#define TPM_ORD_SHA1Update          0x000000A1
+#define TPM_ORD_SHA1CompleteExtend  0x000000A3
+
+#define TPM_TAG_RQU_COMMAND         0x00C1
+#define TPM_TAG_RSP_COMMAND         0x00C4
+
+/* All fields of following structs are big endian. */
+struct tpm_cmd_hdr {
+    uint16_t    tag;
+    uint32_t    paramSize;
+    uint32_t    ordinal;
+} __packed;
+
+struct tpm_rsp_hdr {
+    uint16_t    tag;
+    uint32_t    paramSize;
+    uint32_t    returnCode;
+} __packed;
+
+struct extend_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrNum;
+    uint8_t inDigest[SHA1_DIGEST_SIZE];
+} __packed;
+
+struct extend_rsp {
+    struct tpm_rsp_hdr h;
+    uint8_t outDigest[SHA1_DIGEST_SIZE];
+} __packed;
+
+struct sha1_start_cmd {
+    struct tpm_cmd_hdr h;
+} __packed;
+
+struct sha1_start_rsp {
+    struct tpm_rsp_hdr h;
+    uint32_t maxNumBytes;
+} __packed;
+
+struct sha1_update_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t numBytes;          /* Must be a multiple of 64 */
+    uint8_t hashData[];
+} __packed;
+
+struct sha1_update_rsp {
+    struct tpm_rsp_hdr h;
+} __packed;
+
+struct sha1_complete_extend_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrNum;
+    uint32_t hashDataSize;      /* 0-64, inclusive */
+    uint8_t hashData[];
+} __packed;
+
+struct sha1_complete_extend_rsp {
+    struct tpm_rsp_hdr h;
+    uint8_t hashValue[SHA1_DIGEST_SIZE];
+    uint8_t outDigest[SHA1_DIGEST_SIZE];
+} __packed;
+
+struct TPM12_PCREvent {
+    uint32_t PCRIndex;
+    uint32_t Type;
+    uint8_t Digest[SHA1_DIGEST_SIZE];
+    uint32_t Size;
+    uint8_t Data[];
+};
+
+struct txt_ev_log_container_12 {
+    char        Signature[20];      /* "TXT Event Container", null-terminated */
+    uint8_t     Reserved[12];
+    uint8_t     ContainerVerMajor;
+    uint8_t     ContainerVerMinor;
+    uint8_t     PCREventVerMajor;
+    uint8_t     PCREventVerMinor;
+    uint32_t    ContainerSize;      /* Allocated size */
+    uint32_t    PCREventsOffset;
+    uint32_t    NextEventOffset;
+    struct TPM12_PCREvent   PCREvents[];
+};
+
+#ifdef __EARLY_SLAUNCH__
+/*
+ * TPM1.2 is required to support commands of up to 1101 bytes, vendors rarely
+ * go above that. Limit maximum size of block of data to be hashed to 1024.
+ */
+#define MAX_HASH_BLOCK      1024
+#define CMD_RSP_BUF_SIZE    (sizeof(struct sha1_update_cmd) + MAX_HASH_BLOCK)
+
+union cmd_rsp {
+    struct sha1_start_cmd start_c;
+    struct sha1_start_rsp start_r;
+    struct sha1_update_cmd update_c;
+    struct sha1_update_rsp update_r;
+    struct sha1_complete_extend_cmd finish_c;
+    struct sha1_complete_extend_rsp finish_r;
+    uint8_t buf[CMD_RSP_BUF_SIZE];
+};
+
+/* Returns true on success. */
+static bool tpm12_hash_extend(unsigned loc, const uint8_t *buf, unsigned size,
+                              unsigned pcr, uint8_t *out_digest)
+{
+    union cmd_rsp cmd_rsp;
+    unsigned max_bytes = MAX_HASH_BLOCK;
+    unsigned o_size = sizeof(cmd_rsp);
+    bool success = false;
+
+    request_locality(loc);
+
+    cmd_rsp.start_c = (struct sha1_start_cmd) {
+        .h.tag = swap16(TPM_TAG_RQU_COMMAND),
+        .h.paramSize = swap32(sizeof(struct sha1_start_cmd)),
+        .h.ordinal = swap32(TPM_ORD_SHA1Start),
+    };
+
+    send_cmd(loc, cmd_rsp.buf, sizeof(struct sha1_start_cmd), &o_size);
+    if ( o_size < sizeof(struct sha1_start_rsp) )
+        goto error;
+
+    if ( max_bytes > swap32(cmd_rsp.start_r.maxNumBytes) )
+        max_bytes = swap32(cmd_rsp.start_r.maxNumBytes);
+
+    while ( size > 64 )
+    {
+        if ( size < max_bytes )
+            max_bytes = size & ~(64 - 1);
+
+        o_size = sizeof(cmd_rsp);
+
+        cmd_rsp.update_c = (struct sha1_update_cmd){
+            .h.tag = swap16(TPM_TAG_RQU_COMMAND),
+            .h.paramSize = swap32(sizeof(struct sha1_update_cmd) + max_bytes),
+            .h.ordinal = swap32(TPM_ORD_SHA1Update),
+            .numBytes = swap32(max_bytes),
+        };
+        memcpy(cmd_rsp.update_c.hashData, buf, max_bytes);
+
+        send_cmd(loc, cmd_rsp.buf, sizeof(struct sha1_update_cmd) + max_bytes,
+                 &o_size);
+        if ( o_size < sizeof(struct sha1_update_rsp) )
+            goto error;
+
+        size -= max_bytes;
+        buf += max_bytes;
+    }
+
+    o_size = sizeof(cmd_rsp);
+
+    cmd_rsp.finish_c = (struct sha1_complete_extend_cmd) {
+        .h.tag = swap16(TPM_TAG_RQU_COMMAND),
+        .h.paramSize = swap32(sizeof(struct sha1_complete_extend_cmd) + size),
+        .h.ordinal = swap32(TPM_ORD_SHA1CompleteExtend),
+        .pcrNum = swap32(pcr),
+        .hashDataSize = swap32(size),
+    };
+    memcpy(cmd_rsp.finish_c.hashData, buf, size);
+
+    send_cmd(loc, cmd_rsp.buf, sizeof(struct sha1_complete_extend_cmd) + size,
+             &o_size);
+    if ( o_size < sizeof(struct sha1_complete_extend_rsp) )
+        goto error;
+
+    if ( out_digest != NULL )
+        memcpy(out_digest, cmd_rsp.finish_r.hashValue, SHA1_DIGEST_SIZE);
+
+    success = true;
+
+error:
+    relinquish_locality(loc);
+    return success;
+}
+
+#else
+
+union cmd_rsp {
+    struct extend_cmd extend_c;
+    struct extend_rsp extend_r;
+};
+
+/* Returns true on success. */
+static bool tpm12_hash_extend(unsigned loc, const uint8_t *buf, unsigned size,
+                              unsigned pcr, uint8_t *out_digest)
+{
+    union cmd_rsp cmd_rsp;
+    unsigned o_size = sizeof(cmd_rsp);
+
+    sha1_hash(out_digest, buf, size);
+
+    request_locality(loc);
+
+    cmd_rsp.extend_c = (struct extend_cmd) {
+        .h.tag = swap16(TPM_TAG_RQU_COMMAND),
+        .h.paramSize = swap32(sizeof(struct extend_cmd)),
+        .h.ordinal = swap32(TPM_ORD_Extend),
+        .pcrNum = swap32(pcr),
+    };
+
+    memcpy(cmd_rsp.extend_c.inDigest, out_digest, SHA1_DIGEST_SIZE);
+
+    send_cmd(loc, (uint8_t *)&cmd_rsp, sizeof(struct extend_cmd), &o_size);
+
+    relinquish_locality(loc);
+
+    return (o_size >= sizeof(struct extend_rsp));
+}
+
+#endif /* __EARLY_SLAUNCH__ */
+
+static void *create_log_event12(struct txt_ev_log_container_12 *evt_log,
+                                uint32_t evt_log_size, uint32_t pcr,
+                                uint32_t type, const uint8_t *data,
+                                unsigned data_size)
+{
+    struct TPM12_PCREvent *new_entry;
+
+    new_entry = (void *)(((uint8_t *)evt_log) + evt_log->NextEventOffset);
+
+    /*
+     * Check if there is enough space left for new entry.
+     * Note: it is possible to introduce a gap in event log if entry with big
+     * data_size is followed by another entry with smaller data. Maybe we should
+     * cap the event log size in such case?
+     */
+    if ( evt_log->NextEventOffset + sizeof(struct TPM12_PCREvent) + data_size
+         > evt_log_size )
+        return NULL;
+
+    evt_log->NextEventOffset += sizeof(struct TPM12_PCREvent) + data_size;
+
+    new_entry->PCRIndex = pcr;
+    new_entry->Type = type;
+    new_entry->Size = data_size;
+
+    if ( data && data_size > 0 )
+        memcpy(new_entry->Data, data, data_size);
+
+    return new_entry->Digest;
+}
+
+/************************** end of TPM1.2 specific ****************************/
+
+void tpm_hash_extend(unsigned loc, unsigned pcr, const uint8_t *buf,
+                     unsigned size, uint32_t type, const uint8_t *log_data,
+                     unsigned log_data_size)
+{
+    void *evt_log_addr;
+    uint32_t evt_log_size;
+
+    find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
+    evt_log_addr = __va((uintptr_t)evt_log_addr);
+
+    if ( is_tpm12() )
+    {
+        uint8_t sha1_digest[SHA1_DIGEST_SIZE];
+
+        struct txt_ev_log_container_12 *evt_log = evt_log_addr;
+        void *entry_digest = create_log_event12(evt_log, evt_log_size, pcr,
+                                                type, log_data, log_data_size);
+
+        /* We still need to write computed hash somewhere. */
+        if ( entry_digest == NULL )
+            entry_digest = sha1_digest;
+
+        if ( !tpm12_hash_extend(loc, buf, size, pcr, entry_digest) )
+        {
+#ifndef __EARLY_SLAUNCH__
+            printk(XENLOG_ERR "Extending PCR%u failed\n", pcr);
+#endif
+        }
+    }
+}
+
+#ifdef __EARLY_SLAUNCH__
+void asmlinkage tpm_extend_mbi(uint32_t *mbi, uint32_t slrt_pa)
+{
+    /* Need this to implement slaunch_get_slrt() for early TPM code. */
+    slrt_location = slrt_pa;
+
+    /* MBI starts with uint32_t total_size. */
+    tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)mbi, *mbi,
+                    DLE_EVTYPE_SLAUNCH, NULL, 0);
+}
+#endif
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:21:41 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:21:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001013.1381286 (Exim 4.92)
	(envelope-from )
	id 1uKzg5-0001q7-9o; Fri, 30 May 2025 13:21:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001013.1381286; Fri, 30 May 2025 13: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 1uKzg5-0001px-6k; Fri, 30 May 2025 13:21:41 +0000
Received: by outflank-mailman (input) for mailman id 1001013;
 Fri, 30 May 2025 13:21:40 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKze1-0008Jy-F1
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:33 +0000
Received: from 7.mo575.mail-out.ovh.net (7.mo575.mail-out.ovh.net
 [46.105.63.230]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b91584a4-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:19:32 +0200 (CEST)
Received: from director10.ghost.mail-out.ovh.net (unknown [10.108.2.235])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4b83jv5LP9z264Q
 for ; Fri, 30 May 2025 13:19:31 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-nc6qk (unknown [10.110.188.144])
 by director10.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 79E51C4832;
 Fri, 30 May 2025 13:19:29 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.100])
 by ghost-submission-5b5ff79f4f-nc6qk with ESMTPSA
 id nnzwCmGwOWjeQzsACj9Bag
 (envelope-from ); Fri, 30 May 2025 13:19: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" 
X-Inumbo-ID: b91584a4-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-100R003bd8ebc15-fda5-48b5-885e-5e7d68c13e5c,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
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 ,
	Nicola Vetrini ,
	Doug Goldstein ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 20/22] x86/slaunch: support EFI boot
Date: Fri, 30 May 2025 16:18:02 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12710002576057283740
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepleelkeekhfeikeeifeekgfethfdvheekfedvffetfefgveelleekkedvgeekuddvnecuffhomhgrihhnpehhvggrugdrshgspdigkeeipgeigedrshgsnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrddutddtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheejhegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=Drr6FWlQScmF8BWhc//AZ198parzbtjMM3aMJ+vfK8U=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611171; v=1;
 b=dmbjUHDx3MRM9pDuWhCkzBUZKK+IgSP1BCpk7hMPevMMYhgXmrGgQ77SrpvMRpf+fyw0pqzS
 g5SViFyNQkVWI9/yz16arc2X6q3Up1U7NjGS4pn7WTVY85qJ3cbWhFY4i2PtAuNGdocc2n4PRrS
 g28ZM+4mD8WBT13kY4mY515za9+i17OniNy7dhAGFOSBXGOxotrAzVem/lq658kws03kTQvn+CB
 5YJXgXqPyemtyX76zJr401uvo8Di9Xx6pYl+QKHwK5DFuT6+VZnzlUQLJvH85oyru+j+K4dH8vR
 SNlqhgpwZB0RDQyjy+IA1JBbq1qpDg0QWwEO4KhVABvVA==

When running on an EFI-enabled system, Xen needs to have access to Boot
Services in order to initialize itself properly and reach a state in
which a dom0 kernel can operate without issues.

This means that DRTM must be started in the middle of Xen's
initialization process.  This effect is achieved via a callback into
a TrenchBoot-enabled bootloader (GRUB) which is responsible for
initiating DRTM and continuing Xen's initialization process.  The latter
is done by branching in Slaunch entry point on a flag to switch back
into long mode before calling the same function which Xen would execute
as the next step without DRTM.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 .gitignore                                    |   1 +
 .../eclair_analysis/ECLAIR/out_of_scope.ecl   |   1 +
 docs/hypervisor-guide/x86/how-xen-boots.rst   |  10 +-
 xen/arch/x86/Makefile                         |   9 +-
 xen/arch/x86/boot/head.S                      | 124 +++++++++++++++++
 xen/arch/x86/boot/x86_64.S                    |  14 +-
 xen/arch/x86/efi/efi-boot.h                   |  88 +++++++++++-
 xen/arch/x86/efi/fixmlehdr.c                  | 127 ++++++++++++++++++
 xen/arch/x86/slaunch.c                        |  74 +++++++++-
 xen/common/efi/boot.c                         |   4 +
 xen/common/efi/runtime.c                      |   1 +
 xen/include/xen/efi.h                         |   1 +
 12 files changed, 441 insertions(+), 13 deletions(-)
 create mode 100644 xen/arch/x86/efi/fixmlehdr.c

diff --git a/.gitignore b/.gitignore
index 4a4e206804..707e839ea8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -200,6 +200,7 @@ xen/.xen.elf32
 xen/System.map
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
+xen/arch/x86/efi/fixmlehdr
 xen/arch/x86/efi/mkreloc
 xen/arch/x86/include/asm/asm-macros.h
 xen/arch/*/xen.lds
diff --git a/automation/eclair_analysis/ECLAIR/out_of_scope.ecl b/automation/eclair_analysis/ECLAIR/out_of_scope.ecl
index 9bcec4c69d..a09cf5442c 100644
--- a/automation/eclair_analysis/ECLAIR/out_of_scope.ecl
+++ b/automation/eclair_analysis/ECLAIR/out_of_scope.ecl
@@ -19,6 +19,7 @@
 
 -doc_begin="Build tools are out of scope."
 -file_tag+={out_of_scope_tools,"^xen/tools/.*$"}
+-file_tag+={out_of_scope_tools,"^xen/arch/x86/efi/fixmlehdr\\.c$"}
 -file_tag+={out_of_scope_tools,"^xen/arch/x86/efi/mkreloc\\.c$"}
 -file_tag+={out_of_scope_tools,"^xen/arch/x86/boot/mkelf32\\.c$"}
 -doc_end
diff --git a/docs/hypervisor-guide/x86/how-xen-boots.rst b/docs/hypervisor-guide/x86/how-xen-boots.rst
index 050fe9c61f..63f81a8198 100644
--- a/docs/hypervisor-guide/x86/how-xen-boots.rst
+++ b/docs/hypervisor-guide/x86/how-xen-boots.rst
@@ -55,10 +55,12 @@ If ``CONFIG_PVH_GUEST`` was selected at build time, an Elf note is included
 which indicates the ability to use the PVH boot protocol, and registers
 ``__pvh_start`` as the entrypoint, entered in 32bit mode.
 
-A combination of Multiboot 2 and MLE headers is used to implement DRTM for
-legacy (BIOS) boot. The separate entry point is used mainly to differentiate
-from other kinds of boots. It moves a magic number to EAX before jumping into
-common startup code.
+A combination of Multiboot 2 and MLE headers is used to implement DRTM. The
+separate entry point is used mainly to differentiate from other kinds of boots.
+For a legacy (BIOS) boot, it moves a magic number to EAX before jumping into
+common startup code.  For a EFI boot, it resumes execution of Xen.efi which was
+paused by handing control to a part of a bootloader responsible for initiating
+DRTM sequence.
 
 
 xen.gz
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 2d008a5f52..aab98c003f 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -89,6 +89,7 @@ extra-y += xen.lds
 
 hostprogs-y += boot/mkelf32
 hostprogs-y += efi/mkreloc
+hostprogs-y += efi/fixmlehdr
 
 $(obj)/efi/mkreloc: HOSTCFLAGS += -I$(srctree)/include
 
@@ -140,6 +141,10 @@ $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
 
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
 
+ifeq ($(XEN_BUILD_EFI),y)
+XEN_AFLAGS += -DXEN_BUILD_EFI
+endif
+
 $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
 	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
 	    $(objtree)/common/symbols-dummy.o -o $(dot-target).0
@@ -209,7 +214,7 @@ note_file_option ?= $(note_file)
 
 extra-$(XEN_BUILD_PE) += efi.lds
 ifeq ($(XEN_BUILD_PE),y)
-$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
+$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc $(obj)/efi/fixmlehdr
 ifeq ($(CONFIG_DEBUG_INFO),y)
 	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
 endif
@@ -236,6 +241,8 @@ endif
 	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
 	      $(dot-target).1r.o $(dot-target).1s.o $(orphan-handling-y) \
 	      $(note_file_option) -o $@
+	# take image offset into account
+	$(obj)/efi/fixmlehdr $@ $(XEN_IMG_OFFSET)
 	$(NM) -pa --format=sysv $@ \
 		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
 		> $@.map
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 66e1a21033..5ec2a272a9 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -397,6 +397,12 @@ slaunch_stub_entry:
         mov     %ebx, %esi
         sub     $sym_offs(slaunch_stub_entry), %esi
 
+#ifdef XEN_BUILD_EFI
+        /* If the flag is already set, then Xen should continue execution. */
+        cmpb    $0, sym_esi(slaunch_active)
+        jne     slaunch_efi_jumpback
+#endif
+
         /* On AMD, %ebp holds the base address of SLB, save it for later. */
         mov     %ebp, %ebx
 
@@ -836,6 +842,124 @@ trampoline_setup:
         /* Jump into the relocated trampoline. */
         lret
 
+#ifdef XEN_BUILD_EFI
+
+        /*
+         * The state matches that of slaunch_stub_entry above, but with %esi
+         * already initialized.
+         */
+slaunch_efi_jumpback:
+        lea     STACK_SIZE - CPUINFO_sizeof + sym_esi(cpu0_stack), %esp
+
+        /* Prepare gdt and segments. */
+        add     %esi, sym_esi(gdt_boot_base)
+        lgdt    sym_esi(gdt_boot_descr)
+
+        mov     $BOOT_DS, %ecx
+        mov     %ecx, %ds
+        mov     %ecx, %es
+        mov     %ecx, %ss
+
+        push    $BOOT_CS32
+        lea     sym_esi(.Lgdt_is_set),%edx
+        push    %edx
+        lret
+.Lgdt_is_set:
+
+        /*
+         * Stash TSC as above because it was zeroed on jumping into bootloader
+         * to not interfere with measurements.
+         */
+        rdtsc
+        mov     %eax,     sym_esi(boot_tsc_stamp)
+        mov     %edx, 4 + sym_esi(boot_tsc_stamp)
+
+        /*
+         * Clear the pagetables before the use. We are loaded below 4GiB and
+         * this avoids the need for writing to higher dword of each entry.
+         * Additionally, this ensures those dwords are actually zero and the
+         * mappings aren't manipulated from outside.
+         */
+        lea     sym_esi(bootmap_start), %edi
+        lea     sym_esi(bootmap_end), %ecx
+        sub     %edi, %ecx
+        xor     %eax, %eax
+        shr     $2, %ecx
+        rep stosl
+
+        /* 1x L1 page, 512 entries mapping total of 2M. */
+        lea     sym_esi(l1_bootmap), %edi
+        mov     $512, %ecx
+        mov     $(__PAGE_HYPERVISOR + 512 * PAGE_SIZE), %edx
+.Lfill_l1_identmap:
+        sub     $PAGE_SIZE, %edx
+        /* Loop runs for ecx=[512..1] for entries [511..0], hence -8. */
+        mov     %edx, -8(%edi,%ecx,8)
+        loop    .Lfill_l1_identmap
+
+        /* 4x L2 pages, each page mapping 1G of RAM. */
+        lea     sym_esi(l2_bootmap), %edi
+        /* 1st entry points to L1. */
+        lea     (sym_offs(l1_bootmap) + __PAGE_HYPERVISOR)(%esi), %edx
+        mov     %edx, (%edi)
+        /* Other entries are 2MB pages. */
+        mov     $(4 * 512 - 1), %ecx
+        /*
+         * Value below should be 4GB + flags, which wouldn't fit in 32b
+         * register. To avoid warning from the assembler, 4GB is skipped here.
+         * Substitution in first iteration makes the value roll over and point
+         * to 4GB - 2MB + flags.
+         */
+        mov     $(_PAGE_PSE + __PAGE_HYPERVISOR), %edx
+.Lfill_l2_identmap:
+        sub     $(1 << L2_PAGETABLE_SHIFT), %edx
+        /* Loop runs for ecx=[2047..1] for entries [2047..1]. */
+        mov     %edx, (%edi,%ecx,8)
+        loop    .Lfill_l2_identmap
+
+        /* 1x L3 page, mapping the 4x L2 pages. */
+        lea     sym_esi(l3_bootmap), %edi
+        mov     $4, %ecx
+        lea     (sym_offs(l2_bootmap) + 4 * PAGE_SIZE + __PAGE_HYPERVISOR)(%esi), %edx
+.Lfill_l3_identmap:
+        sub     $PAGE_SIZE, %edx
+        /* Loop runs for ecx=[4..1] for entries [3..0], hence -8. */
+        mov     %edx, -8(%edi,%ecx,8)
+        loop    .Lfill_l3_identmap
+
+        /* 1x L4 page, mapping the L3 page. */
+        lea     (sym_offs(l3_bootmap) + __PAGE_HYPERVISOR)(%esi), %edx
+        mov     %edx, sym_esi(l4_bootmap)
+
+        /* Restore CR4, PAE must be enabled before IA-32e mode */
+        mov     %cr4, %ecx
+        or      $X86_CR4_PAE, %ecx
+        mov     %ecx, %cr4
+
+        /* Load PML4 table location into PT base register */
+        lea     sym_esi(l4_bootmap), %eax
+        mov     %eax, %cr3
+
+        /* Enable IA-32e mode and paging */
+        mov     $MSR_EFER, %ecx
+        rdmsr
+        or      $EFER_LME >> 8, %ah
+        wrmsr
+
+        mov     %cr0, %eax
+        or      $X86_CR0_PG | X86_CR0_NE | X86_CR0_TS | X86_CR0_MP, %eax
+        mov     %eax, %cr0
+
+        /* Now in IA-32e compatibility mode, use lret to jump to 64b mode */
+        lea     sym_esi(start_xen_from_efi), %ecx
+        push    $BOOT_CS64
+        push    %ecx
+        lret
+
+.global start_xen_from_efi
+
+#endif /* XEN_BUILD_EFI */
+
 ENTRY(trampoline_start)
 #include "trampoline.S"
 ENTRY(trampoline_end)
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index ac33576d8f..67896f5fe5 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -221,14 +221,22 @@ GLOBAL(__page_tables_end)
 /* Init pagetables. Enough page directories to map into 4GB. */
         .section .init.data, "aw", @progbits
 
-DATA_LOCAL(l1_bootmap, PAGE_SIZE)
+bootmap_start:
+
+DATA_LOCAL(l1_bootmap, PAGE_SIZE) /* 1x L1 page, mapping 2M of RAM. */
         .fill L1_PAGETABLE_ENTRIES, 8, 0
 END(l1_bootmap)
 
-DATA(l2_bootmap, PAGE_SIZE)
+DATA(l2_bootmap, PAGE_SIZE) /* 4x L2 pages, each mapping 1G of RAM. */
         .fill 4 * L2_PAGETABLE_ENTRIES, 8, 0
 END(l2_bootmap)
 
-DATA(l3_bootmap, PAGE_SIZE)
+DATA(l3_bootmap, PAGE_SIZE) /* 1x L3 page, mapping the 4x L2 pages. */
         .fill L3_PAGETABLE_ENTRIES, 8, 0
 END(l3_bootmap)
+
+DATA_LOCAL(l4_bootmap, PAGE_SIZE) /* 1x L4 page, mapping the L3 page. */
+        .fill L4_PAGETABLE_ENTRIES, 8, 0
+END(l4_bootmap)
+
+bootmap_end:
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 0ecf4ca53f..7533e2f12a 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -9,6 +9,12 @@
 
 #include 
 
+/*
+ * Tell  to access TXT registers without address translation
+ * which has not yet been set up.
+ */
+#define __EARLY_SLAUNCH__
+
 #include 
 #include 
 #include 
@@ -17,8 +23,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 static struct file __initdata ucode;
+static uint64_t __initdata xen_image_size;
 static multiboot_info_t __initdata mbi = {
     .flags = MBI_MODULES | MBI_LOADERNAME
 };
@@ -234,10 +243,29 @@ static void __init efi_arch_pre_exit_boot(void)
     }
 }
 
-static void __init noreturn efi_arch_post_exit_boot(void)
+void __init asmlinkage noreturn start_xen_from_efi(void)
 {
     u64 cr4 = XEN_MINIMAL_CR4 & ~X86_CR4_PGE, efer;
 
+    if ( slaunch_active )
+    {
+        struct slr_table *slrt = (struct slr_table *)efi.slr;
+        struct slr_entry_intel_info *intel_info;
+
+        intel_info = (struct slr_entry_intel_info *)
+            slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+        if ( intel_info != NULL )
+        {
+            void *txt_heap = txt_init();
+            struct txt_os_mle_data *os_mle = txt_os_mle_data_start(txt_heap);
+            struct txt_os_sinit_data *os_sinit =
+                txt_os_sinit_data_start(txt_heap);
+
+            txt_verify_pmr_ranges(os_mle, os_sinit, intel_info, xen_phys_start,
+                                  xen_phys_start, xen_image_size);
+        }
+    }
+
     efi_arch_relocate_image(__XEN_VIRT_START - xen_phys_start);
     memcpy(_p(trampoline_phys), trampoline_start, cfg.size);
 
@@ -283,6 +311,63 @@ static void __init noreturn efi_arch_post_exit_boot(void)
     unreachable();
 }
 
+static void __init attempt_secure_launch(void)
+{
+    struct slr_table *slrt;
+    struct slr_entry_dl_info *dlinfo;
+    dl_handler_func handler_callback;
+
+    /* The presence of this table indicates a Secure Launch boot. */
+    slrt = (struct slr_table *)efi.slr;
+    if ( efi.slr == EFI_INVALID_TABLE_ADDR || slrt->magic != SLR_TABLE_MAGIC ||
+         slrt->revision != SLR_TABLE_REVISION )
+        return;
+
+    /* Avoid calls into firmware after DRTM. */
+    __clear_bit(EFI_RS, &efi_flags);
+
+    /*
+     * Make measurements less sensitive to hardware-specific details.
+     *
+     * Intentionally leaving efi_ct and efi_num_ct intact.
+     */
+    efi_ih = NULL;
+    efi_bs = NULL;
+    efi_bs_revision = 0;
+    efi_rs = NULL;
+    efi_version = 0;
+    efi_fw_vendor = NULL;
+    efi_fw_revision = 0;
+    StdOut = NULL;
+    StdErr = NULL;
+    boot_tsc_stamp = 0;
+
+    slaunch_active = true;
+    slaunch_slrt = efi.slr;
+
+    /* Jump through DL stub to initiate Secure Launch. */
+    dlinfo = (struct slr_entry_dl_info *)
+        slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO);
+
+    handler_callback = (dl_handler_func)dlinfo->dl_handler;
+    handler_callback(&dlinfo->bl_context);
+
+    unreachable();
+}
+
+static void __init noreturn efi_arch_post_exit_boot(void)
+{
+    /*
+     * If Secure Launch happens, attempt_secure_launch() doesn't return and
+     * start_xen_from_efi() is invoked after DRTM has been initiated.
+     * Otherwise, attempt_secure_launch() returns and execution continues as
+     * usual.
+     */
+    attempt_secure_launch();
+
+    start_xen_from_efi();
+}
+
 static void __init efi_arch_cfg_file_early(const EFI_LOADED_IMAGE *image,
                                            EFI_FILE_HANDLE dir_handle,
                                            const char *section)
@@ -779,6 +864,7 @@ static void __init efi_arch_halt(void)
 static void __init efi_arch_load_addr_check(const EFI_LOADED_IMAGE *loaded_image)
 {
     xen_phys_start = (UINTN)loaded_image->ImageBase;
+    xen_image_size = loaded_image->ImageSize;
     if ( (xen_phys_start + loaded_image->ImageSize - 1) >> 32 )
         blexit(L"Xen must be loaded below 4Gb.");
     if ( xen_phys_start & ((1 << L2_PAGETABLE_SHIFT) - 1) )
diff --git a/xen/arch/x86/efi/fixmlehdr.c b/xen/arch/x86/efi/fixmlehdr.c
new file mode 100644
index 0000000000..60a91c6b73
--- /dev/null
+++ b/xen/arch/x86/efi/fixmlehdr.c
@@ -0,0 +1,127 @@
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Depending on the toolchain and its configuration the header can end up quite
+ * far from the start of the file.
+ */
+#define PREFIX_SIZE (8*1024)
+
+struct mle_header
+{
+    uint8_t uuid[16];
+    uint32_t header_len;
+    uint32_t version;
+    uint32_t entry_point;
+    uint32_t first_valid_page;
+    uint32_t mle_start;
+    uint32_t mle_end;
+    uint32_t capabilities;
+    uint32_t cmdline_start;
+    uint32_t cmdline_end;
+} __attribute__ ((packed));
+
+static const uint8_t MLE_HEADER_UUID[] = {
+    0x5a, 0xac, 0x82, 0x90, 0x6f, 0x47, 0xa7, 0x74,
+    0x0f, 0x5c, 0x55, 0xa2, 0xcb, 0x51, 0xb6, 0x42
+};
+
+int main(int argc, char *argv[])
+{
+    FILE *fp;
+    struct mle_header header;
+    int i;
+    char *end_ptr;
+    long long correction;
+    const char *file_path;
+
+    if ( argc != 3 )
+    {
+        fprintf(stderr, "Usage: %s  \n", argv[0]);
+        return 1;
+    }
+
+    correction = strtoll(argv[2], &end_ptr, 0);
+    if ( *end_ptr != '\0' )
+    {
+        fprintf(stderr, "Failed to parse '%s' as a number\n", argv[2]);
+        return 1;
+    }
+    if ( correction < INT32_MIN  )
+    {
+        fprintf(stderr, "Correction '%s' is too small\n", argv[2]);
+        return 1;
+    }
+    if ( correction > INT32_MAX  )
+    {
+        fprintf(stderr, "Correction '%s' is too large\n", argv[2]);
+        return 1;
+    }
+
+    file_path = argv[1];
+
+    fp = fopen(file_path, "r+");
+    if ( fp == NULL )
+    {
+        fprintf(stderr, "Failed to open %s\n", file_path);
+        return 1;
+    }
+
+    for ( i = 0; i < PREFIX_SIZE; i += 16 )
+    {
+        uint8_t bytes[16];
+
+        if ( fread(bytes, sizeof(bytes), 1, fp) != 1 )
+        {
+            fprintf(stderr, "Failed to find MLE header in %s\n", file_path);
+            goto fail;
+        }
+
+        if ( memcmp(bytes, MLE_HEADER_UUID, 16) == 0 )
+        {
+            break;
+        }
+    }
+
+    if ( i >= PREFIX_SIZE )
+    {
+        fprintf(stderr, "Failed to find MLE header in %s\n", file_path);
+        goto fail;
+    }
+
+    if ( fseek(fp, -16, SEEK_CUR) )
+    {
+        fprintf(stderr, "Failed to seek back to MLE header in %s\n", file_path);
+        goto fail;
+    }
+
+    if ( fread(&header, sizeof(header), 1, fp) != 1 )
+    {
+        fprintf(stderr, "Failed to read MLE header from %s\n", file_path);
+        goto fail;
+    }
+
+    if ( fseek(fp, -(int)sizeof(header), SEEK_CUR) )
+    {
+        fprintf(stderr, "Failed to seek back again to MLE header in %s\n",
+                file_path);
+        goto fail;
+    }
+
+    header.entry_point += correction;
+
+    if ( fwrite(&header, sizeof(header), 1, fp) != 1 )
+    {
+        fprintf(stderr, "Failed to write MLE header in %s\n", file_path);
+        goto fail;
+    }
+
+    fclose(fp);
+    return 0;
+
+fail:
+    fclose(fp);
+    return 1;
+}
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index 58a0de910d..89e78f498d 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -245,10 +246,23 @@ check_drtm_policy(const struct slr_table *slrt,
 {
     uint32_t i;
     uint32_t num_mod_entries;
+    int min_entries;
 
-    if ( policy->nr_entries < 2 )
-        panic("DRTM policy in SLRT contains less than 2 entries (%d)!\n",
-              policy->nr_entries);
+    min_entries = efi_enabled(EFI_BOOT) ? 1 : 2;
+    if ( policy->nr_entries < min_entries )
+    {
+        panic("DRTM policy in SLRT contains less than %d entries (%d)!\n",
+              min_entries, policy->nr_entries);
+    }
+
+    if ( efi_enabled(EFI_BOOT) )
+    {
+        check_slrt_policy_entry(&policy_entry[0], 0, slrt);
+        /* SLRT was measured in tpm_measure_slrt(). */
+        return 1;
+    }
+
+    /* This must be legacy MultiBoot2 boot. */
 
     /*
      * MBI policy entry must be the first one, so that measuring order matches
@@ -317,6 +331,7 @@ void __init slaunch_process_drtm_policy(const struct boot_info *bi)
     const struct slr_table *slrt;
     const struct slr_entry_policy *policy;
     struct slr_policy_entry *policy_entry;
+    int rc;
     uint16_t i;
     unsigned int measured;
 
@@ -331,7 +346,6 @@ void __init slaunch_process_drtm_policy(const struct boot_info *bi)
 
     for ( i = measured; i < policy->nr_entries; i++ )
     {
-        int rc;
         uint64_t start = policy_entry[i].entity;
         uint64_t size = policy_entry[i].size;
 
@@ -376,6 +390,58 @@ void __init slaunch_process_drtm_policy(const struct boot_info *bi)
 
         policy_entry[i].flags |= SLR_POLICY_FLAG_MEASURED;
     }
+
+    /*
+     * On x86 EFI platforms Xen reads its command-line options and kernel/initrd
+     * from configuration files (several can be chained). Bootloader can't know
+     * contents of the configuration beforehand without parsing it, so there
+     * will be no corresponding policy entries. Instead, measure command-line
+     * and all modules here.
+     */
+    if ( efi_enabled(EFI_BOOT) )
+    {
+#define LOG_DATA(str) (uint8_t *)(str), (sizeof(str) - 1)
+
+        tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR,
+                        (const uint8_t *)bi->cmdline, strlen(bi->cmdline),
+                        DLE_EVTYPE_SLAUNCH, LOG_DATA("Xen's command line"));
+
+        for ( i = 0; i < bi->nr_modules; i++ )
+        {
+            const struct boot_module *mod = &bi->mods[i];
+
+            paddr_t string = mod->cmdline_pa;
+            paddr_t start = mod->start;
+            size_t size = mod->size;
+
+            if ( mod->relocated || mod->released )
+            {
+                panic("A module \"%s\" (#%d) was consumed before measurement\n",
+                      (const char *)__va(string), i);
+            }
+
+            /*
+             * Measuring module's name separately because module's command-line
+             * parameters are appended to its name when present.
+             *
+             * 2 MiB is minimally mapped size and it should more than suffice.
+             */
+            rc = slaunch_map_l2(string, 2 * 1024 * 1024);
+            BUG_ON(rc != 0);
+
+            tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR,
+                            __va(string), strlen(__va(string)),
+                            DLE_EVTYPE_SLAUNCH, LOG_DATA("MB module string"));
+
+            rc = slaunch_map_l2(start, size);
+            BUG_ON(rc != 0);
+
+            tpm_hash_extend(DRTM_LOC, DRTM_CODE_PCR, __va(start), size,
+                            DLE_EVTYPE_SLAUNCH, LOG_DATA("MB module"));
+        }
+
+#undef LOG_DATA
+    }
 }
 
 int __init slaunch_map_l2(unsigned long paddr, unsigned long size)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index e39fbc3529..35501ee4de 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -19,6 +19,7 @@
 #if EFI_PAGE_SIZE != PAGE_SIZE
 # error Cannot use xen/pfn.h here!
 #endif
+#include 
 #include 
 #include 
 #ifdef CONFIG_X86
@@ -1004,6 +1005,7 @@ static void __init efi_tables(void)
         static EFI_GUID __initdata mps_guid = MPS_TABLE_GUID;
         static EFI_GUID __initdata smbios_guid = SMBIOS_TABLE_GUID;
         static EFI_GUID __initdata smbios3_guid = SMBIOS3_TABLE_GUID;
+        static EFI_GUID __initdata slr_guid = UEFI_SLR_TABLE_GUID;
 
         if ( match_guid(&acpi2_guid, &efi_ct[i].VendorGuid) )
             efi.acpi20 = (unsigned long)efi_ct[i].VendorTable;
@@ -1015,6 +1017,8 @@ static void __init efi_tables(void)
             efi.smbios = (unsigned long)efi_ct[i].VendorTable;
         if ( match_guid(&smbios3_guid, &efi_ct[i].VendorGuid) )
             efi.smbios3 = (unsigned long)efi_ct[i].VendorTable;
+        if ( match_guid(&slr_guid, &efi_ct[i].VendorGuid) )
+            efi.slr = (unsigned long)efi_ct[i].VendorTable;
         if ( match_guid(&esrt_guid, &efi_ct[i].VendorGuid) )
             esrt = (UINTN)efi_ct[i].VendorTable;
     }
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 7e1fce291d..e1b339f162 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -70,6 +70,7 @@ struct efi __read_mostly efi = {
 	.mps    = EFI_INVALID_TABLE_ADDR,
 	.smbios = EFI_INVALID_TABLE_ADDR,
 	.smbios3 = EFI_INVALID_TABLE_ADDR,
+	.slr    = EFI_INVALID_TABLE_ADDR,
 };
 
 const struct efi_pci_rom *__read_mostly efi_pci_roms;
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 160804e294..614dfce66a 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -19,6 +19,7 @@ struct efi {
     unsigned long acpi20;       /* ACPI table (ACPI 2.0) */
     unsigned long smbios;       /* SM BIOS table */
     unsigned long smbios3;      /* SMBIOS v3 table */
+    unsigned long slr;          /* SLR table */
 };
 
 extern struct efi efi;
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:21:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:21:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001022.1381296 (Exim 4.92)
	(envelope-from )
	id 1uKzgK-0002Pd-Ha; Fri, 30 May 2025 13:21:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001022.1381296; Fri, 30 May 2025 13:21: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 1uKzgK-0002PW-EI; Fri, 30 May 2025 13:21:56 +0000
Received: by outflank-mailman (input) for mailman id 1001022;
 Fri, 30 May 2025 13:21:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdu-0008Jy-Lm
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:26 +0000
Received: from 5.mo583.mail-out.ovh.net (5.mo583.mail-out.ovh.net
 [87.98.173.103]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b3afa57d-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:19:23 +0200 (CEST)
Received: from director4.ghost.mail-out.ovh.net (unknown [10.108.25.4])
 by mo583.mail-out.ovh.net (Postfix) with ESMTP id 4b83jk5Jg2z1kgy
 for ; Fri, 30 May 2025 13:19:22 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-7mj9p (unknown [10.110.168.40])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 0E7EFC57BA;
 Fri, 30 May 2025 13:19:21 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.104])
 by ghost-submission-5b5ff79f4f-7mj9p with ESMTPSA
 id lFyANFmwOWgz4wAAMDjBXw
 (envelope-from ); Fri, 30 May 2025 13:19: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" 
X-Inumbo-ID: b3afa57d-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-104R00545eb1c88-6e30-4b42-870d-eb4a1160ce4c,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 18/22] x86/boot/slaunch-early: find MBI and SLRT on AMD
Date: Fri, 30 May 2025 16:18:00 +0300
Message-ID: <7272ac988ae672f0a05486775e805a9513e86950.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12707469300486354076
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhepkedugeefudeigeduieejleelkeefvddvhfehheevhfdukeejieefgedtudevhedtnecuffhomhgrihhnpehhvggrugdrshgsnecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrddutdegnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekfegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=6b/MBAdcX7V7P2Nt96V761xn41jitI/g+aKn4sKLesI=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611162; v=1;
 b=RLVB/6EW7AX63X7XuboL0LJKFS1pB903Pl9pBA8I+sF6xEp+DiyWfHfvyC28iGPCi9fXbnNN
 dPlLSd5sfq7yAmN/Nan4hJvHqsa/Pk1vGJAtYyf5EkoQ5xI7wGsTCKUwGcuy5Ic0VH2PwOYsDwe
 +JoaPDGFketeAwhzz15C04F5uyP3q8jsxBrr0xqtWQNDMEzVCAKBq4N9ZVJcolGKzvwTq1qDSR/
 JfpsOLV1YhXJ3dwlw97i+yH09bkHxmuqFLhV4iC+2Gy8wiRO9/f0uF0JAHb6h9MrKgGaarSyp6v
 JC0TN191+SlBGDM5dHDW+1bC6q7regUIvkGz3hK/9RrGw==

Use slr_entry_amd_info::boot_params_base on AMD with SKINIT to get MBI
location.

Another thing of interest is the location of SLRT which is bootloader's
data after SKL.

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/boot/head.S          | 38 ++++++++++++++++----
 xen/arch/x86/boot/slaunch-early.c | 58 +++++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 7376fa85d5..66e1a21033 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -354,10 +354,12 @@ cs32_switch:
         jmp     *%edi
 
         /*
-         * Entry point for TrenchBoot Secure Launch on Intel TXT platforms.
+         * Entry point for TrenchBoot Secure Launch, common for Intel TXT and
+         * AMD Secure Startup, but state is slightly different.
          *
+         * On Intel:
          * CPU is in 32b protected mode with paging disabled. On entry:
-         * - %ebx = %eip = MLE entry point,
+         * - %ebx = %eip = this entry point,
          * - stack pointer is undefined,
          * - CS is flat 4GB code segment,
          * - DS, ES, SS, FS and GS are undefined according to TXT SDG, but this
@@ -375,13 +377,34 @@ cs32_switch:
          * - trying to enter real mode results in reset
          * - APs must be brought up by MONITOR or GETSEC[WAKEUP], depending on
          *   which is supported by a given SINIT ACM
+         *
+         * On AMD (as implemented by TrenchBoot's SKL):
+         * CPU is in 32b protected mode with paging disabled. On entry:
+         * - %ebx = %eip = this entry point,
+         * - %ebp holds base address of SKL
+         * - stack pointer is treated as undefined for parity with TXT,
+         * - CS is flat 4GB code segment,
+         * - DS, ES, SS are flat 4GB data segments, but treated as undefined for
+         *   parity with TXT.
+         *
+         * Additional restrictions:
+         * - interrupts (including NMIs and SMIs) are disabled and must be
+         *   enabled later
+         * - APs must be brought up by SIPI without an INIT
          */
 slaunch_stub_entry:
         /* Calculate the load base address. */
         mov     %ebx, %esi
         sub     $sym_offs(slaunch_stub_entry), %esi
 
-        /* Mark Secure Launch boot protocol and jump to common entry. */
+        /* On AMD, %ebp holds the base address of SLB, save it for later. */
+        mov     %ebp, %ebx
+
+        /*
+         * Mark Secure Launch boot protocol and jump to common entry. Note that
+         * all general purpose registers except %ebx and %esi are clobbered
+         * between here and .Lslaunch_proto.
+         */
         mov     $SLAUNCH_BOOTLOADER_MAGIC, %eax
         jmp     .Lset_stack
 
@@ -508,15 +531,18 @@ __start:
         sub     $8, %esp
 
         push    %esp                             /* pointer to output structure */
+        push    %ebx                             /* Slaunch parameter on AMD */
         lea     sym_offs(__2M_rwdata_end), %ecx  /* end of target image */
         lea     sym_offs(_start), %edx           /* target base address */
         mov     %esi, %eax                       /* load base address */
         /*
-         * slaunch_early_init(load/eax, tgt/edx, tgt_end/ecx, ret/stk) using
-         * fastcall calling convention.
+         * slaunch_early_init(load/eax, tgt/edx, tgt_end/ecx,
+         *                     slaunch/stk, ret/stk)
+         *
+         * Uses fastcall calling convention.
          */
         call    slaunch_early_init
-        add     $4, %esp                         /* pop the fourth parameter */
+        add     $8, %esp                         /* pop last two parameters */
 
         /* Move outputs of slaunch_early_init() from stack into registers. */
         pop     %eax  /* physical MBI address */
diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
index 662144e42f..ac4c294e61 100644
--- a/xen/arch/x86/boot/slaunch-early.c
+++ b/xen/arch/x86/boot/slaunch-early.c
@@ -7,6 +7,20 @@
 #include 
 #include 
 #include 
+#include 
+
+/*
+ * The AMD-defined structure layout for the SLB. The last two fields are
+ * SL-specific.
+ */
+struct skinit_sl_header
+{
+    uint16_t skl_entry_point;
+    uint16_t length;
+    uint8_t reserved[62];
+    uint16_t skl_info_offset;
+    uint16_t bootloader_data_offset;
+} __packed;
 
 struct early_init_results
 {
@@ -14,9 +28,25 @@ struct early_init_results
     uint32_t slrt_pa;
 } __packed;
 
+static bool is_intel_cpu(void)
+{
+    /*
+     * asm/processor.h can't be included in early code, which means neither
+     * cpuid() function nor boot_cpu_data can be used here.
+     */
+    uint32_t eax, ebx, ecx, edx;
+    asm volatile ( "cpuid"
+          : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
+          : "0" (0), "c" (0) );
+    return ebx == X86_VENDOR_INTEL_EBX
+        && ecx == X86_VENDOR_INTEL_ECX
+        && edx == X86_VENDOR_INTEL_EDX;
+}
+
 void asmlinkage slaunch_early_init(uint32_t load_base_addr,
                                    uint32_t tgt_base_addr,
                                    uint32_t tgt_end_addr,
+                                   uint32_t slaunch_param,
                                    struct early_init_results *result)
 {
     void *txt_heap;
@@ -26,6 +56,34 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
     const struct slr_entry_intel_info *intel_info;
     uint32_t size = tgt_end_addr - tgt_base_addr;
 
+    if ( !is_intel_cpu() )
+    {
+        /*
+         * Not an Intel CPU. Currently the only other option is AMD with SKINIT
+         * and secure-kernel-loader (SKL).
+         */
+        const struct slr_entry_amd_info *amd_info;
+        const struct skinit_sl_header *sl_header = (void *)slaunch_param;
+
+        /*
+         * slaunch_param holds a physical address of SLB.
+         * Bootloader's data is SLRT.
+         */
+        result->slrt_pa = slaunch_param + sl_header->bootloader_data_offset;
+        result->mbi_pa = 0;
+
+        slrt = (struct slr_table *)(uintptr_t)result->slrt_pa;
+
+        amd_info = (const struct slr_entry_amd_info *)
+            slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_AMD_INFO);
+        /* Basic checks only, SKL checked and consumed the rest. */
+        if ( amd_info == NULL || amd_info->hdr.size != sizeof(*amd_info) )
+            return;
+
+        result->mbi_pa = amd_info->boot_params_base;
+        return;
+    }
+
     txt_heap = txt_init();
     os_mle = txt_os_mle_data_start(txt_heap);
     os_sinit = txt_os_sinit_data_start(txt_heap);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:22:03 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:22:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001025.1381306 (Exim 4.92)
	(envelope-from )
	id 1uKzgR-0002yT-Sr; Fri, 30 May 2025 13:22:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001025.1381306; Fri, 30 May 2025 13:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uKzgR-0002yM-Q0; Fri, 30 May 2025 13:22:03 +0000
Received: by outflank-mailman (input) for mailman id 1001025;
 Fri, 30 May 2025 13:22:02 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKze9-0003ZU-3n
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:41 +0000
Received: from 13.mo583.mail-out.ovh.net (13.mo583.mail-out.ovh.net
 [87.98.182.191]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bca85697-3d58-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:19:38 +0200 (CEST)
Received: from director11.ghost.mail-out.ovh.net (unknown [10.108.17.88])
 by mo583.mail-out.ovh.net (Postfix) with ESMTP id 4b83k15sPTz1khX
 for ; Fri, 30 May 2025 13:19:37 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-nz9zm (unknown [10.108.42.21])
 by director11.ghost.mail-out.ovh.net (Postfix) with ESMTPS id BCE5DC2659;
 Fri, 30 May 2025 13:19:36 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.95])
 by ghost-submission-5b5ff79f4f-nz9zm with ESMTPSA
 id w/UMHGiwOWi8HAgAWBo3Rw
 (envelope-from ); Fri, 30 May 2025 13:19: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" 
X-Inumbo-ID: bca85697-3d58-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-95G001fe63952f-1568-4af4-bba7-78aaf58620e7,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
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 ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 22/22] MAINTAINERS: add a section for TrenchBoot Slaunch
Date: Fri, 30 May 2025 16:18:04 +0300
Message-ID: <113264e01d44acfe2af59cf220fe7124ab49b9e4.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12711691424670921884
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhephfehfeehudeileeikeffgfffgfefuddtveelvedvhfffgfelvdfgtddutdehfeeinecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdelheenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshgvrhhgihhirdgumhihthhruhhkseefmhguvggsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdfovfetjfhoshhtpehmohehkeefmgdpmhhouggvpehsmhhtphhouhht
DKIM-Signature: a=rsa-sha256; bh=lkr/y2WetCt+mF/LprSnrtNgrDqTmRaZK+50RlJ14fY=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611177; v=1;
 b=Qj8nEN04nWAX/lCMM0PYYSItWTnqFv6X+uS/dBFXXu+N/lXoWi849ayCOI8STFzhUPkuiMdh
 HmcifkPc0oUzP6THKQsImSddJ3BbAjivl3bBYqP6KF/LRFKx3aCPa/NzB47Qcg1MKY9OIXhLmwb
 usHB+fQu8X5iAjcT4iYyVkmjCnlMkkuNForfsFnQhZiiRKe/Ny2qY7t93EEreTWJv/wgDolFMAx
 PvPxy2PIG4Y11Ru1hqiME1Vmhxi3e+gtdCPv8Gpdl8ug0Q26O4vKNxgs56C7BUF0A7pHosEjs7I
 BLHtDd7vESx5b5uG9dPKOPilSMPao7W8jIjw4y/PKS06g==

Signed-off-by: Sergii Dmytruk 
---
 MAINTAINERS | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c11b82eca9..5b1e67401a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -542,6 +542,21 @@ F:	*/configure
 F:	*/*.ac
 F:	tools/
 
+TRENCHBOOT SECURE LAUNCH
+M:	Daniel P. Smith 
+R:	Ross Philipson 
+R:	Sergii Dmytruk 
+S:	Supported
+F:	xen/arch/x86/boot/slaunch-early.c
+F:	xen/arch/x86/efi/fixmlehdr.c
+F:	xen/arch/x86/include/asm/intel-txt.h
+F:	xen/arch/x86/include/asm/slaunch.h
+F:	xen/arch/x86/include/asm/tpm.h
+F:	xen/arch/x86/intel-txt.c
+F:	xen/arch/x86/slaunch.c
+F:	xen/arch/x86/tpm.c
+F:	xen/include/xen/slr-table.h
+
 VM EVENT, MEM ACCESS and MONITOR
 M:	Tamas K Lengyel 
 R:	Alexandru Isaila 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:23:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:23:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001065.1381321 (Exim 4.92)
	(envelope-from )
	id 1uKzhg-0004f5-Eg; Fri, 30 May 2025 13:23:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001065.1381321; Fri, 30 May 2025 13:23: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 1uKzhg-0004e0-9g; Fri, 30 May 2025 13:23:20 +0000
Received: by outflank-mailman (input) for mailman id 1001065;
 Fri, 30 May 2025 13:23:19 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKze4-0003ZU-3h
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:36 +0000
Received: from 2.mo582.mail-out.ovh.net (2.mo582.mail-out.ovh.net
 [46.105.76.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b64ceedc-3d58-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:19:27 +0200 (CEST)
Received: from director3.ghost.mail-out.ovh.net (unknown [10.109.148.49])
 by mo582.mail-out.ovh.net (Postfix) with ESMTP id 4b83jq0y11z1dJf
 for ; Fri, 30 May 2025 13:19:27 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-xc6mh (unknown [10.110.168.219])
 by director3.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 1E5BEC3326;
 Fri, 30 May 2025 13:19:24 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.105])
 by ghost-submission-5b5ff79f4f-xc6mh with ESMTPSA
 id fw8bLlywOWiZtgAAiTdl2Q
 (envelope-from ); Fri, 30 May 2025 13:19: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" 
X-Inumbo-ID: b64ceedc-3d58-11f0-b894-0df219b8e170
Authentication-Results:garm.ovh; auth=pass (GARM-105G0063501688f-cd43-4a5e-8213-abcfdd892099,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	"Daniel P. Smith" ,
	Ross Philipson ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 19/22] x86/slaunch: support AMD SKINIT
Date: Fri, 30 May 2025 16:18:01 +0300
Message-ID: <20c2380bd920fea3009f6e5ae2d3011b0a3fe431.1748611041.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12708876676210341020
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhephfehfeehudeileeikeffgfffgfefuddtveelvedvhfffgfelvdfgtddutdehfeeinecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrddutdehnecuvehluhhsthgvrhfuihiivgepgeenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheekvdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=wzJGPzWI7lL37VfLBh9g3OqTx3SpBQMv+io19vUhKSI=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611167; v=1;
 b=P1yuXhTV2FhzHLEx6qizEKIvBbFXbXU4JRWkbqxJS/2eGtvmfU26yFqGaPeyj610TYhb7s+m
 PmsQhcwSeVILCgvJCBSqDPy8dGGwJHBMAfXvzzaFpuXMmXkKbiDXchthBgvant6fxQFncNRPxh0
 T5cKJP8sJrYArt0u7/ic6a6ycwsGSM18LBoEQbwn/GfhKdcNkrASz5HPyC8cL4FPbLg1KcLIb2S
 FTPAppTrI5jjrWmsJpogzKzS3+B05KQEFAFGeyMeINre6lPOtLNZNqpw1T4UDmuLEXWZN/37duy
 xpakrVFG70Qw0cTC7N1/rabPQMDshFS9JLzB3/iK42FLA==

This mostly involves not running Intel-specific code when on AMD.

There are only a few new AMD-specific implementation details:
 - finding SLB start and size and then mapping and reserving it in e820
 - managing offset for adding the next TPM log entry (TXT-compatible
   data prepared by SKL is stored inside of vendor data field within TCG
   header)

Signed-off-by: Krystian Hebel 
Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/e820.c    |  2 +-
 xen/arch/x86/slaunch.c | 90 ++++++++++++++++++++++++++++++++++--------
 xen/arch/x86/tpm.c     | 68 ++++++++++++++++++++++++++++++-
 3 files changed, 141 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index 60f00e5259..cf13ab269a 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -444,7 +444,7 @@ static uint64_t __init mtrr_top_of_ram(void)
     ASSERT(paddr_bits);
     addr_mask = ((1ULL << paddr_bits) - 1) & PAGE_MASK;
 
-    if ( slaunch_active )
+    if ( slaunch_active && boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
         txt_restore_mtrrs(e820_verbose);
 
     rdmsrl(MSR_MTRRcap, mtrr_cap);
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index 2390d0a3f3..58a0de910d 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -17,6 +17,10 @@
 #include 
 #include 
 
+/* SLB is 64k, 64k-aligned */
+#define SKINIT_SLB_SIZE   0x10000
+#define SKINIT_SLB_ALIGN  0x10000
+
 /*
  * These variables are assigned to by the code near Xen's entry point.
  *
@@ -39,6 +43,8 @@ struct slr_table *__init slaunch_get_slrt(void)
 
     if (slrt == NULL) {
         int rc;
+        bool intel_cpu = (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL);
+        uint16_t slrt_architecture = intel_cpu ? SLR_INTEL_TXT : SLR_AMD_SKINIT;
 
         slrt = __va(slaunch_slrt);
 
@@ -50,9 +56,9 @@ struct slr_table *__init slaunch_get_slrt(void)
         /* XXX: are newer revisions allowed? */
         if ( slrt->revision != SLR_TABLE_REVISION )
             panic("SLRT is of unsupported revision: %#04x!\n", slrt->revision);
-        if ( slrt->architecture != SLR_INTEL_TXT )
-            panic("SLRT is for unexpected architecture: %#04x!\n",
-                  slrt->architecture);
+        if ( slrt->architecture != slrt_architecture )
+            panic("SLRT is for unexpected architecture: %#04x != %#04x!\n",
+                  slrt->architecture, slrt_architecture);
         if ( slrt->size > slrt->max_size )
             panic("SLRT is larger than its max size: %#08x > %#08x!\n",
                   slrt->size, slrt->max_size);
@@ -67,6 +73,23 @@ struct slr_table *__init slaunch_get_slrt(void)
     return slrt;
 }
 
+static uint32_t __init get_slb_start(void)
+{
+    /*
+     * The runtime computation relies on size being a power of 2 and equal to
+     * alignment. Make sure these assumptions hold.
+     */
+    BUILD_BUG_ON(SKINIT_SLB_SIZE != SKINIT_SLB_ALIGN);
+    BUILD_BUG_ON(SKINIT_SLB_SIZE == 0);
+    BUILD_BUG_ON((SKINIT_SLB_SIZE & (SKINIT_SLB_SIZE - 1)) != 0);
+
+    /*
+     * Rounding any address within SLB down to alignment gives SLB base and
+     * SLRT is inside SLB on AMD.
+     */
+    return slaunch_slrt & ~(SKINIT_SLB_SIZE - 1);
+}
+
 void __init slaunch_map_mem_regions(void)
 {
     int rc;
@@ -77,7 +100,10 @@ void __init slaunch_map_mem_regions(void)
     BUG_ON(rc != 0);
 
     /* Vendor-specific part. */
-    txt_map_mem_regions();
+    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+        txt_map_mem_regions();
+    else if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+        slaunch_map_l2(get_slb_start(), SKINIT_SLB_SIZE);
 
     find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
     if ( evt_log_addr != NULL )
@@ -95,7 +121,18 @@ void __init slaunch_reserve_mem_regions(void)
     uint32_t evt_log_size;
 
     /* Vendor-specific part. */
-    txt_reserve_mem_regions();
+    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+    {
+        txt_reserve_mem_regions();
+    }
+    else if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+    {
+        uint64_t slb_start = get_slb_start();
+        uint64_t slb_end = slb_start + SKINIT_SLB_SIZE;
+        printk("SLAUNCH: reserving SLB (%#lx - %#lx)\n", slb_start, slb_end);
+        rc = reserve_e820_ram(&e820_raw, slb_start, slb_end);
+        BUG_ON(rc == 0);
+    }
 
     find_evt_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
     if ( evt_log_addr != NULL )
@@ -119,20 +156,41 @@ void __init slaunch_measure_slrt(void)
          * In revision one of the SLRT, only platform-specific info table is
          * measured.
          */
-        struct slr_entry_intel_info tmp;
-        struct slr_entry_intel_info *entry;
+        if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+        {
+            struct slr_entry_intel_info tmp;
+            struct slr_entry_intel_info *entry;
+
+            entry = (struct slr_entry_intel_info *)
+                slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+            if ( entry == NULL )
+                panic("SLRT is missing Intel-specific information!\n");
 
-        entry = (struct slr_entry_intel_info *)
-            slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
-        if ( entry == NULL )
-            panic("SLRT is missing Intel-specific information!\n");
+            tmp = *entry;
+            tmp.boot_params_base = 0;
+            tmp.txt_heap = 0;
 
-        tmp = *entry;
-        tmp.boot_params_base = 0;
-        tmp.txt_heap = 0;
+            tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
+                            sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+        }
+        else if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+        {
+            struct slr_entry_amd_info tmp;
+            struct slr_entry_amd_info *entry;
+
+            entry = (struct slr_entry_amd_info *)
+                slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_AMD_INFO);
+            if ( entry == NULL )
+                panic("SLRT is missing AMD-specific information!\n");
 
-        tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
-                        sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+            tmp = *entry;
+            tmp.next = 0;
+            tmp.slrt_base = 0;
+            tmp.boot_params_base = 0;
+
+            tpm_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
+                            sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+        }
     }
     else
     {
diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
index 3c145fd3cc..77f910a8c9 100644
--- a/xen/arch/x86/tpm.c
+++ b/xen/arch/x86/tpm.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef __EARLY_SLAUNCH__
 
@@ -52,11 +53,31 @@ void *(memcpy)(void *dest, const void *src, size_t n)
     return dest;
 }
 
+static bool is_amd_cpu(void)
+{
+    /*
+     * asm/processor.h can't be included in early code, which means neither
+     * cpuid() function nor boot_cpu_data can be used here.
+     */
+    uint32_t eax, ebx, ecx, edx;
+    asm volatile ( "cpuid"
+          : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
+          : "0" (0), "c" (0) );
+    return ebx == X86_VENDOR_AMD_EBX
+        && ecx == X86_VENDOR_AMD_ECX
+        && edx == X86_VENDOR_AMD_EDX;
+}
+
 #else   /* __EARLY_SLAUNCH__ */
 
 #include 
 #include 
 
+static bool is_amd_cpu(void)
+{
+    return boot_cpu_data.x86_vendor == X86_VENDOR_AMD;
+}
+
 #endif  /* __EARLY_SLAUNCH__ */
 
 #define TPM_LOC_REG(loc, reg)   (0x1000 * (loc) + (reg))
@@ -241,6 +262,21 @@ struct TPM12_PCREvent {
     uint8_t Data[];
 };
 
+struct tpm1_spec_id_event {
+    uint32_t pcrIndex;
+    uint32_t eventType;
+    uint8_t digest[20];
+    uint32_t eventSize;
+    uint8_t signature[16];
+    uint32_t platformClass;
+    uint8_t specVersionMinor;
+    uint8_t specVersionMajor;
+    uint8_t specErrata;
+    uint8_t uintnSize;
+    uint8_t vendorInfoSize;
+    uint8_t vendorInfo[0];  /* variable number of members */
+} __packed;
+
 struct txt_ev_log_container_12 {
     char        Signature[20];      /* "TXT Event Container", null-terminated */
     uint8_t     Reserved[12];
@@ -384,6 +420,16 @@ static void *create_log_event12(struct txt_ev_log_container_12 *evt_log,
 {
     struct TPM12_PCREvent *new_entry;
 
+    if ( is_amd_cpu() )
+    {
+        /*
+         * On AMD, TXT-compatible structure is stored as vendor data of
+         * TCG-defined event log header.
+         */
+        struct tpm1_spec_id_event *spec_id = (void *)evt_log;
+        evt_log = (struct txt_ev_log_container_12 *)&spec_id->vendorInfo[0];
+    }
+
     new_entry = (void *)(((uint8_t *)evt_log) + evt_log->NextEventOffset);
 
     /*
@@ -832,11 +878,29 @@ static uint32_t tpm2_hash_extend(unsigned loc, const uint8_t *buf,
 
 #endif /* __EARLY_SLAUNCH__ */
 
-static struct heap_event_log_pointer_element2_1 *find_evt_log_ext_data(void)
+static struct heap_event_log_pointer_element2_1 *
+find_evt_log_ext_data(struct tpm2_spec_id_event *evt_log)
 {
     struct txt_os_sinit_data *os_sinit;
     struct txt_ext_data_element *ext_data;
 
+    if ( is_amd_cpu() )
+    {
+        /*
+         * Event log pointer is defined by TXT specification, but
+         * secure-kernel-loader provides a compatible structure in vendor data
+         * of the log.
+         */
+        const uint8_t *data_size =
+            (void *)&evt_log->digestSizes[evt_log->digestCount];
+
+        if ( *data_size != sizeof(struct heap_event_log_pointer_element2_1) )
+            return NULL;
+
+        /* Vendor data directly follows one-byte size. */
+        return (void *)(data_size + 1);
+    }
+
     os_sinit = txt_os_sinit_data_start(__va(txt_read(TXTCR_HEAP_BASE)));
     ext_data = (void *)((uint8_t *)os_sinit + sizeof(*os_sinit));
 
@@ -870,7 +934,7 @@ create_log_event20(struct tpm2_spec_id_event *evt_log, uint32_t evt_log_size,
     unsigned i;
     uint8_t *p;
 
-    log_ext_data = find_evt_log_ext_data();
+    log_ext_data = find_evt_log_ext_data(evt_log);
     if ( log_ext_data == NULL )
         return log_hashes;
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:23:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:23:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001061.1381316 (Exim 4.92)
	(envelope-from )
	id 1uKzhg-0004cE-6U; Fri, 30 May 2025 13:23:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001061.1381316; Fri, 30 May 2025 13:23: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 1uKzhg-0004c7-3g; Fri, 30 May 2025 13:23:20 +0000
Received: by outflank-mailman (input) for mailman id 1001061;
 Fri, 30 May 2025 13:23:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uKzdt-0008Jy-Lj
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:19:25 +0000
Received: from 14.mo550.mail-out.ovh.net (14.mo550.mail-out.ovh.net
 [178.32.97.215]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b22512b8-3d58-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:19:20 +0200 (CEST)
Received: from director7.ghost.mail-out.ovh.net (unknown [10.109.148.49])
 by mo550.mail-out.ovh.net (Postfix) with ESMTP id 4b83jh1WJ5z1lvF
 for ; Fri, 30 May 2025 13:19:20 +0000 (UTC)
Received: from ghost-submission-5b5ff79f4f-595tn (unknown [10.110.113.13])
 by director7.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 8AD7EC06E0;
 Fri, 30 May 2025 13:19:19 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.114])
 by ghost-submission-5b5ff79f4f-595tn with ESMTPSA
 id TNHOGFewOWjNxwAAeVbzSg
 (envelope-from ); Fri, 30 May 2025 13:19: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" 
X-Inumbo-ID: b22512b8-3d58-11f0-a2ff-13f23c93f187
Authentication-Results:garm.ovh; auth=pass (GARM-114S00895dc382f-a550-4f6b-b404-f0cac4229ca3,
                    A4E380CC922F0B59227EC5DCC46884561651840B) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.184.221
From: Sergii Dmytruk 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v3 17/22] x86/acpi: disallow S3 on Secure Launch boot
Date: Fri, 30 May 2025 16:17:59 +0300
Message-ID: 
X-Mailer: git-send-email 2.49.0
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12706906350127527068
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvleduudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefuvghrghhiihcuffhmhihtrhhukhcuoehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomheqnecuggftrfgrthhtvghrnhephfehfeehudeileeikeffgfffgfefuddtveelvedvhfffgfelvdfgtddutdehfeeinecukfhppeduvdejrddtrddtrddupddujeeirdduuddurddukeegrddvvddupdefjedrheelrddugedvrdduudegnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehsvghrghhiihdrughmhihtrhhukhesfehmuggvsgdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdpoffvtefjohhsthepmhhoheehtdgmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=GDql3BTKkItj9wJ+5Y5x33V6WArPQmOVJIP++1bnZvg=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1748611160; v=1;
 b=VisO5To8RRu8TC0ZFsf9Gfi3F2pq+oFPXbyOfsoWBWec/iz+gmWk7FcqiZOMnht0TmDHwhsM
 7q2T2kZdE6di2acc+rnLeFMqRDkERQkYfH4TXf2qgTCHjlVc+DlnGrMrMYxhVpuPAVguxXVr1KN
 CjWepru+WVBQx7iYx0gH0pgSkbmPCYs7Z7ctKQAGTw4ecgA/rmdty8DXK+BRufHQi4G6q0zHPmD
 30mYab7ia4SbIesn6X/Dv8A0V3CJXc+h+oOUVbNFaD1yGMnZqKt9/TRdY60507zBLPEuOhMtxMs
 QAGODC0YsBg2Fyhh7oqap0w91NxL5DYa1zU/54bEM4AhA==

Secure Launch won't initiate DRTM on S3 resume (the code for starting
DRTM is not part of Xen), so abort a request to perform S3 suspend to
not lose the state of DRTM PCRs.

Signed-off-by: Sergii Dmytruk 
---
 xen/arch/x86/acpi/power.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 448aa9f3a7..6a53c6718c 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -356,6 +357,13 @@ int acpi_enter_sleep(const struct xenpf_enter_acpi_sleep *sleep)
            PAGE_SIZE - acpi_sinfo.vector_width / 8)) )
         return -EOPNOTSUPP;
 
+    /* Secure Launch won't initiate DRTM on S3 resume, so abort S3 suspend. */
+    if ( sleep->sleep_state == ACPI_STATE_S3 && slaunch_active )
+    {
+        printk(XENLOG_INFO "SLAUNCH: refusing switching into ACPI S3 state.\n");
+        return -EPERM;
+    }
+
     if ( sleep->flags & XENPF_ACPI_SLEEP_EXTENDED )
     {
         if ( !acpi_sinfo.sleep_control.address ||
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:47:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:47:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001141.1381336 (Exim 4.92)
	(envelope-from )
	id 1uL054-0003JU-8g; Fri, 30 May 2025 13:47:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001141.1381336; Fri, 30 May 2025 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 1uL054-0003JN-5G; Fri, 30 May 2025 13:47:30 +0000
Received: by outflank-mailman (input) for mailman id 1001141;
 Fri, 30 May 2025 13:47:28 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL052-0003C4-6X
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:47:28 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on2060b.outbound.protection.outlook.com
 [2a01:111:f403:2412::60b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9a2d703f-3d5c-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:47:19 +0200 (CEST)
Received: from SA1PR04CA0001.namprd04.prod.outlook.com (2603:10b6:806:2ce::8)
 by DS0PR12MB7996.namprd12.prod.outlook.com (2603:10b6:8:14f::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.33; Fri, 30 May
 2025 13:47:15 +0000
Received: from SA2PEPF00003F63.namprd04.prod.outlook.com
 (2603:10b6:806:2ce:cafe::ca) by SA1PR04CA0001.outlook.office365.com
 (2603:10b6:806:2ce::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8746.31 via Frontend Transport; Fri,
 30 May 2025 13:47:14 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00003F63.mail.protection.outlook.com (10.167.248.38) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 13:47:14 +0000
Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 08:47: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" 
X-Inumbo-ID: 9a2d703f-3d5c-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nbsyxJ6az0do8uNT1sxfVt9i4wib7nGWKBgUqvLdA+hJsubhDIDqf/3WuQmJlbin8ctUDeKn8v8hHbPK4Zq65OzCFavV/A1VqqzS7vQ2FljL9sdoUjUoNLkABF4QyB4KaKxJZAHN5p1gURMb16yD9OuphTZQ4HxWxDy5HEv5OjJ01V9lq28vq9ZZ7lHhl41KUQlI+BF4oguLYqq8hf5kOVFHjy3iVYoSJyCXmrBrJrLxdMtBnpMdwVA8lLiNgkwBVCnABmv5snDTBjRbEyvQpP0IXDMZf+/mMyCGpB+JXAJOB2r/uy+Brpo4PnboxNiJqNMjeJzZU8tdxZ+VRxSwPw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tvOIrJV1fjk5IvQMmXUd+maoM+MrcX4tQfw9ZQA5QzQ=;
 b=PX6ExR8TQiuh4khVdvj/lC8ulU++2qHJuyD4QlWR+A1+pncyJ40mQVh6Z6y5yOIC4ngTq3QDm+yRWbKpJbj+wsyId5ozMV1aZ6+1vwKHXWs/gwqQUe3vG2pG7FJWjYZp0WaD8ZTNJOtHI175xXbXjhNsNtiUpLuo8p9zuhSdI+NFJb07JpxfK+822DWslrZPQ12hIvQGG1Gl6UahclB2x88IaPjQQa57RHNY72/BcnjLZkM70x4B3ddTJ7G33ad6TBgWSmXq3CkJl3xfL9gtIHs2WrRUiEQj5wtTYPKF9iUAR6CDiX5Z9zR0wIjwUNfo4yv5a80cxQLWAfHMs8FWUQ==
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=tvOIrJV1fjk5IvQMmXUd+maoM+MrcX4tQfw9ZQA5QzQ=;
 b=KBd17xQkaPtUcXqDgHQCsPCg9BoGXowtGbNl89Iv/0vpIdp+LNy/iZWynBOIqCFETv6fKtRyWOo1kYYJvXSeP8TmgACQ+UCxEQJTYrx5+KLwECfgttZDBdP2x7gmQgYqR+fuoSW8XJjqkkNACIgk1x4+dizmexRWOsb0AVsLfxU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Date: Fri, 30 May 2025 15:47:12 +0200
From: "Edgar E. Iglesias" 
To: Julien Grall 
CC: "Edgar E. Iglesias" ,
	, ,
	, ,
	, , Anthony PERARD
	, Juergen Gross , Jan Beulich
	, Roger Pau =?iso-8859-1?Q?Monn=E9?=
	
Subject: Re: [PATCH v2 1/3] xen/arm: Add way to disable traps on accesses to
 unmapped addresses
Message-ID: 
References: <20250529155024.1284227-1-edgar.iglesias@gmail.com>
 <20250529155024.1284227-2-edgar.iglesias@gmail.com>
 
 
 <36dc6b2a-6dd0-4176-9f7e-a021a2427ed2@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <36dc6b2a-6dd0-4176-9f7e-a021a2427ed2@xen.org>
User-Agent: Mutt/2.2.14+84 (2efcabc4) (2025-03-23)
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00003F63:EE_|DS0PR12MB7996:EE_
X-MS-Office365-Filtering-Correlation-Id: 4a7b8e3f-6305-44af-3b67-08dd9f807bfb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|7416014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?kET3Knund1P/qHG3aUFg4UJlKBYC3jW7OVOfoS9fEs7PTTF/AAfLKxJutGTW?=
 =?us-ascii?Q?5cW449oDqrGOTU8KKAu6nvRZFoPoZI/EVOXMOFtuUz3TQYnFXIZMFo/qDMYn?=
 =?us-ascii?Q?CZi2aWDGZVdcr16zLyekeuYm9QTsmhp8quArlyXn8twvG/nCijTavuCSf+34?=
 =?us-ascii?Q?HX5hugQmzFxA0B6qzA3GNgcoDnie7WFmFFL9Hlx+fCwSo98B56JFV6HP55dC?=
 =?us-ascii?Q?kYoPWvVTaaUL7W5tkzahueiGSq2PYb1nMl9ZDRNt6JtH3cw+drqsRmCWlW6Y?=
 =?us-ascii?Q?cp9i0T6mEe1503NOG7Afu3zcBRTt6ubkijc0mNzK/Cl2VnFzIrAkJJKI0HmE?=
 =?us-ascii?Q?YPhqY7I4JPlJfqthum/ai4QzuTME1j/JE2plZH/6+MwhaA/IRCN1qlVyckWV?=
 =?us-ascii?Q?zPK5iLL39OTCK7NaOB9Dti6t+aWdZgkPx050iK2ZkeMTVbptHSk33B77rs6x?=
 =?us-ascii?Q?FwMETWS/111FM9Hw8rbaM5g2v8hJVlis8a1BG2yoNzmHG8mRKDM+z2UctIju?=
 =?us-ascii?Q?WOU9zZVYojWZQpzVAl2TDGqZ9GpMSTuxhD4QS10kVuztXd7Hahi4YMnoaKMD?=
 =?us-ascii?Q?eJo+5iwq+IehfMqetJNok2c6/Vr6A/L38uTdKKJ+hkTbJv6TzwIzZrpztO4Z?=
 =?us-ascii?Q?cIx1E7/pshzcHUtscJ17VNO+UzI9S47eDI5KRFZpgkt2GOwzJxoodKuSv6DH?=
 =?us-ascii?Q?p7mBHwWB6GrO2hguRIzTxYAWNMo6Q+umvfpTnq4ZrFyVKdY2dagc6Ad4ExAG?=
 =?us-ascii?Q?b9cLV1ZzYmtUleKSnoEyOzk9RcztpwmE9EoNeo/cRDcG+qO03Nxd2w5L4E29?=
 =?us-ascii?Q?p+pXCSUpk9Hq9bZxncoCm7hQc2uNm4vwuOigwTYgcs2Krqg6ccUUGTyX+xsU?=
 =?us-ascii?Q?4i9J8T1WZ+uotoKwvdXeqGaUZ8GlEsJnf/4sx89F5ZVrWDBMcIdxDmtADaQX?=
 =?us-ascii?Q?Xebcdp8dekTprIiQy/JwgZj3jpJZvV1InHquKg1bSXwIYRLzReAB04RUl40m?=
 =?us-ascii?Q?7yUBB3ezdlgQTeFeKSE9B7esADbfYyw7MuT/gXXF8e1DFaZvKP15gpSKGmeI?=
 =?us-ascii?Q?4Bt8w3cJS9+WrVGTl5XOompvNVv8ZR+k66wddxV8oG+UTbp4rRd9EYE+JT3C?=
 =?us-ascii?Q?p/zRaqtS8qc5Chkpjy/+ueeWd/cJE/SmHebTnxmoRU1LFq5lR4vaGPxNzctW?=
 =?us-ascii?Q?A1TGI9ZDdFn/X9mzMimSRItbyf7sdo1hEi9buL7vgaoDh4/Mi5BtYDqmEB2O?=
 =?us-ascii?Q?WabbK/KImtazylUSSTQoWQiQxV9IzpdVTi+it8rve4/BTZ7wsoe3uQfFQWe3?=
 =?us-ascii?Q?8fNivzOWlheGxAr4EL6MNHDjKuHpbeesYqsX369e3WWO4JYGor9/gGwCH2RJ?=
 =?us-ascii?Q?Nt+9ZE2ezLhRLj93eNi7m1PKFIzxPsEWufBQlAnmuty4bez9glQdIUEl1As8?=
 =?us-ascii?Q?SY9Rv33QNQJIir0iRwFJkVVFAfNMgPj2loJfqsMoPubHjUP6ZiVilWZDT7/l?=
 =?us-ascii?Q?ZAVYqz0Wl+rWzsSNk6Lr6wEjeXbOhMVAOab9?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 13:47:14.0448
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a7b8e3f-6305-44af-3b67-08dd9f807bfb
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF00003F63.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7996

On Fri, May 30, 2025 at 10:01:23AM +0100, Julien Grall wrote:
> 
> 
> On 29/05/2025 17:23, Edgar E. Iglesias wrote:
> > On Thu, May 29, 2025 at 04:59:21PM +0100, Julien Grall wrote:
> > > Hi Edgar,
> > 
> > Hi Julien,
> > 
> > 
> > > 
> > > On 29/05/2025 16:50, Edgar E. Iglesias wrote:
> > > > From: "Edgar E. Iglesias" 
> > > > 
> > > > Add a per-domain way to optionally disable traps for accesses
> > > > to unmapped addresses.
> > > > 
> > > > The domain flag is general but it's only implemented for ARM for now.
> > > > 
> > > > Signed-off-by: Edgar E. Iglesias 
> > > > ---
> > > >    tools/libs/light/libxl_arm.c  |  3 +++
> > > >    xen/arch/arm/dom0less-build.c |  3 +++
> > > >    xen/arch/arm/domain.c         |  3 ++-
> > > >    xen/arch/arm/domain_build.c   |  3 ++-
> > > >    xen/arch/arm/io.c             | 36 +++++++++++++++++++++++++++++++++--
> > > >    xen/common/domain.c           |  3 ++-
> > > >    xen/include/public/domctl.h   |  4 +++-
> > > 
> > > Looking at the changelog, I saw you removed the go bindings (although, they
> > > were in patch 3). But I don't quite understand why.
> > 
> > I got a little confused. The file tools/golang/xenlight/helpers.gen.go
> > has the following at the top:
> > // Code generated by gengotypes.py. DO NOT EDIT.
> > // source: libxl_types.idl
> > 
> > 
> > So I got the impression that we shouldn't be editing it.
> > Should I edit it manually? Or should I try to rerun gengotypes.py
> > to generate these bindings?
> 
> As the file is checked in, I think we expect the developper to rerun
> gengotypes.py. Anthony, can you confirm?
>

Thanks, I've included a regeneration of the bindings in v3. If it for
some reason is not needed we can drop it.

Cheers,
Edgar


From xen-devel-bounces@lists.xenproject.org Fri May 30 13:47:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:47:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001143.1381346 (Exim 4.92)
	(envelope-from )
	id 1uL05J-0003fM-Kj; Fri, 30 May 2025 13:47:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001143.1381346; Fri, 30 May 2025 13:47: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 1uL05J-0003fF-Hj; Fri, 30 May 2025 13:47:45 +0000
Received: by outflank-mailman (input) for mailman id 1001143;
 Fri, 30 May 2025 13:47:44 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL05I-0003C4-N2
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:47:44 +0000
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [2a00:1450:4864:20::12e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a8c9e97f-3d5c-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:47:42 +0200 (CEST)
Received: by mail-lf1-x12e.google.com with SMTP id
 2adb3069b0e04-55220699ba8so2574905e87.2
 for ; Fri, 30 May 2025 06:47:42 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-55337937969sm705640e87.250.2025.05.30.06.47.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 06:47: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" 
X-Inumbo-ID: a8c9e97f-3d5c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748612862; x=1749217662; 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;
        bh=oVgh0SoUJST6Z4C5PYzlBQVTsTLNYMSpbmKjhpZjOQk=;
        b=EuiocdVm46LDh8aV5fAzLUZ1sBdZwNbewSyheBJad/F0q5j64uUX8ML+p94N1wUJ7c
         SpJpMIQqRRhVFtGRvkygZ4Gdc5gVNhH2RABJ/KfkTabgAIxM97C3x1eu4fbP8GmvDDIg
         X+HwoQVdQmtgMoibIdZ08UETXaZ8J6ry8HJEGS0yj5MTS8/tW2jbf/h0vrsjFkq+pqGH
         8zzMVzVpzNLsd+tKcEIiMrrrVKtuy+E9JYgxLm3JhJ5FxzSOC3ABmIN38mPVHm313XP4
         OcVkmrVn+CkRosks9+qFhGFePRUuI7/2UaZpZyfJvXjZVGkuDLdFTsiXhtH82JC3U/+c
         zSgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748612862; x=1749217662;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=oVgh0SoUJST6Z4C5PYzlBQVTsTLNYMSpbmKjhpZjOQk=;
        b=ffxPmN+oQ9Y9mO/9CTONpzZgN89YtdQrxj3PhPT0WM27x7vSUOhyRPLSw17vuF0EIw
         tOKTIOEHgxk58c/cFQw40CXZ3paS+aI95sirz1kO7dSxi5vzDsJ648/LIyyBnCtwvpEH
         sd0C2NYu5Gnx1sIF9/kq7qnnN0Ngcr9pXx3dR/d3GnpNIMB6k0po9/nGFI8JgGLKvq79
         Kxfe9i1GvceQwoIOg3oZW3MLvrkIOXS55LOVVOUVBGXzBN65P3sY7EwAZ0//I3HLiVfP
         Okn/r+rIyWxJ6tglr/P7+4REgpqaxREZhLA983SafOvrqd0223wszgmQ/yeS0eohwa5b
         cZfA==
X-Gm-Message-State: AOJu0YxMwsWSjQaQossP0YOoTESJA0bIPSnf0AJBmR5P1AnafjiCKFP/
	hcvT8fDcOhkoR+slDBk1sCp3I/Jdkd2i4lNEpZkjI6D7QFVJN31kH7mkh2EeLhQSfa0=
X-Gm-Gg: ASbGncvfjxfIJilgEXT6LWq3mOxyhlZvIovOozMxhMY8dS5e7ddxrEGzqVlALFDG86g
	ljqeQZtH7yfgGxG6nwdLsMhZifErQG7mDmn/7ED0zbh0W4YrlCsvxhE/QP1l+WuT9QJTGQyJbkB
	S5R6LgbQVRaGQX77zFjK5y8hVEHtEJSDxiIe7apqGeG5/C+YXYfY68Z5j8TsCSFewRtYZLGQtFE
	+sMZQ6vuRc8UQK+cEhRKyqYQ7lVraHVOEXHfUsjDGMsZ7HXXpwtwNtTqeUdyvX3fcI9WLNyoHj9
	47YZd26mVhijEZFwn3OdC6aQDJRHCEQ9ihC8iX30xMYcvSqHUuelRwiG7xpXtDsnK5LPP20IlvJ
	tJQNc3SS2gwdZaVTIl1+M+4VcBOpTdUmC2A==
X-Google-Smtp-Source: AGHT+IFUW6B/AUa55ZywDEqLJ2dAxoQUeFzy75qIGV0ozfBH88f6kccQ7rcy/j/8EsPHaab6CP2w2Q==
X-Received: by 2002:a05:6512:31cd:b0:553:297b:3d4e with SMTP id 2adb3069b0e04-5533d1b80f9mr792609e87.52.1748612861562;
        Fri, 30 May 2025 06:47:41 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com,
	Anthony PERARD ,
	Juergen Gross ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v3 1/5] xen/arm: Add way to disable traps on accesses to unmapped addresses
Date: Fri, 30 May 2025 15:45:55 +0200
Message-ID: <20250530134559.1434255-2-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Add a per-domain way to optionally disable traps for accesses
to unmapped addresses.

The domain flag is general but it's only implemented for ARM for now.

Signed-off-by: Edgar E. Iglesias 
---
 tools/libs/light/libxl_arm.c  |  3 +++
 xen/arch/arm/dom0less-build.c |  3 +++
 xen/arch/arm/domain.c         |  3 ++-
 xen/arch/arm/domain_build.c   |  3 ++-
 xen/arch/arm/io.c             | 37 +++++++++++++++++++++++++++++++++--
 xen/common/domain.c           |  3 ++-
 xen/include/public/domctl.h   |  4 +++-
 7 files changed, 50 insertions(+), 6 deletions(-)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 75c811053c..9530996e72 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -233,6 +233,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
     }
 
+    /* Trap accesses to unmapped areas. */
+    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+
     return 0;
 }
 
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a49764f0ad..a4e0a33632 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -343,6 +343,9 @@ void __init arch_create_domUs(struct dt_device_node *node,
         panic("'sve' property found, but CONFIG_ARM64_SVE not selected\n");
 #endif
     }
+
+    /* Trap accesses to unmapped areas. */
+    d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
 }
 
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 45aeb8bddc..be58a23dd7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -612,7 +612,8 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
     unsigned int max_vcpus;
     unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
     unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu |
-                                   XEN_DOMCTL_CDF_xs_domain );
+                                   XEN_DOMCTL_CDF_xs_domain |
+                                   XEN_DOMCTL_CDF_trap_unmapped_accesses );
     unsigned int sve_vl_bits = sve_decode_vl(config->arch.sve_vl);
 
     if ( (config->flags & ~flags_optional) != flags_required )
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b189a7cfae..7ff9c1b584 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2003,7 +2003,8 @@ void __init create_dom0(void)
 {
     struct domain *dom0;
     struct xen_domctl_createdomain dom0_cfg = {
-        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
+        .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
+                 XEN_DOMCTL_CDF_trap_unmapped_accesses,
         .max_evtchn_port = -1,
         .max_grant_frames = gnttab_dom0_frames(),
         .max_maptrack_frames = -1,
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 5a4b0e8f25..e599bbe043 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -21,6 +21,32 @@
 
 #include "decode.h"
 
+/* Handler for unmapped ranges. Writes ignored, reads return all ones.  */
+static int unmapped_read(struct vcpu *v, mmio_info_t *info, register_t *r,
+                         void *priv)
+{
+    uint64_t mask = GENMASK((1U << info->dabt.size) * 8 - 1, 0);
+
+    /* Mask off upper bits.  */
+    *r = UINT64_MAX & mask;
+    return 1;
+}
+
+static int unmapped_write(struct vcpu *v, mmio_info_t *info, register_t r,
+                          void *priv)
+{
+    return 1;
+}
+
+static const struct mmio_handler_ops unmapped_ops = {
+    .read = unmapped_read,
+    .write = unmapped_write
+};
+
+static const struct mmio_handler unmapped_handler = {
+    .ops = &unmapped_ops
+};
+
 static enum io_state handle_read(const struct mmio_handler *handler,
                                  struct vcpu *v,
                                  mmio_info_t *info)
@@ -175,11 +201,18 @@ enum io_state try_handle_mmio(struct cpu_user_regs *regs,
     handler = find_mmio_handler(v->domain, info->gpa);
     if ( !handler )
     {
+        bool trap_unmapped = v->domain->options &
+                                         XEN_DOMCTL_CDF_trap_unmapped_accesses;
         rc = try_fwd_ioserv(regs, v, info);
         if ( rc == IO_HANDLED )
             return handle_ioserv(regs, v);
-
-        return rc;
+        else if ( rc == IO_UNHANDLED && !trap_unmapped )
+        {
+            /* Fallback to the unmapped handler. */
+            handler = &unmapped_handler;
+        } else {
+            return rc;
+        }
     }
 
     /*
diff --git a/xen/common/domain.c b/xen/common/domain.c
index abf1969e60..ac4f58f638 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -721,7 +721,8 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config)
          ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
            XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
            XEN_DOMCTL_CDF_xs_domain | XEN_DOMCTL_CDF_iommu |
-           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu) )
+           XEN_DOMCTL_CDF_nested_virt | XEN_DOMCTL_CDF_vpmu |
+           XEN_DOMCTL_CDF_trap_unmapped_accesses) )
     {
         dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
         return -EINVAL;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5b2063eed9..be19ab5e26 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -66,9 +66,11 @@ struct xen_domctl_createdomain {
 #define XEN_DOMCTL_CDF_nested_virt    (1U << _XEN_DOMCTL_CDF_nested_virt)
 /* Should we expose the vPMU to the guest? */
 #define XEN_DOMCTL_CDF_vpmu           (1U << 7)
+/* Should we trap guest accesses to unmapped addresses? */
+#define XEN_DOMCTL_CDF_trap_unmapped_accesses  (1U << 8)
 
 /* Max XEN_DOMCTL_CDF_* constant.  Used for ABI checking. */
-#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_vpmu
+#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_trap_unmapped_accesses
 
     uint32_t flags;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:47:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:47:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001144.1381356 (Exim 4.92)
	(envelope-from )
	id 1uL05K-0003v7-Rz; Fri, 30 May 2025 13:47:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001144.1381356; Fri, 30 May 2025 13:47: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 1uL05K-0003ux-P5; Fri, 30 May 2025 13:47:46 +0000
Received: by outflank-mailman (input) for mailman id 1001144;
 Fri, 30 May 2025 13:47:45 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL05J-0003es-7k
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:47:45 +0000
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com
 [2a00:1450:4864:20::12c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a9b5a3ba-3d5c-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:47:44 +0200 (CEST)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-54e816aeca6so2724182e87.2
 for ; Fri, 30 May 2025 06:47:44 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5533787d2bdsm699791e87.17.2025.05.30.06.47.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 06:47: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" 
X-Inumbo-ID: a9b5a3ba-3d5c-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748612863; x=1749217663; 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;
        bh=XNe9ZmmTuaxvmRoPZ49IX9TgiJHW6RloMcao0C5Z1eg=;
        b=dmhP2rXEgnVN7Fsj2ZDLxyb7zdf1L9YrSQE5o8vixQtL1f+agOjF768xZu5kAt8TGt
         nYtPaIhPyGaprEE3EfzjSabp/qbCrAPMTg6IaN3JETv82+k9f9Ev/aAxJw7jsh9zfNgB
         59MGShlJg+Nxns9kiwrp6gEqNWony1A6C4x3rM3tZEhG2JGZ6TN/GzR0DG0A04KdmlXh
         dCnqzcY4+/AqSBGY1MPPzPRpu6afECgEnnZkcyxxiGg3d5bY1Z3nMPI+psVZCUMfAT+v
         xc6+nSaK2ajh5xpQYavVbz8yqWHVDF4DjG1bHSrvWELnAkZZCLShhKgePuuIFComk583
         YQKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748612863; x=1749217663;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=XNe9ZmmTuaxvmRoPZ49IX9TgiJHW6RloMcao0C5Z1eg=;
        b=iwM0Ut+SP0TTu384FpfPXXIn/P0Ibf4Vvv4l/Hkix8x+mj4WgXjhCpvHBr6U7jTiDK
         P11x7l0sPk92yvjfhFq9DVeBt+6h5HL0FASQsw7hMNWin+Y0igJddMeRNWdVKHakgzfa
         95Xf+aD8j0hgGyalZ2Q5aGOhPtyWTU63+Q8sEcYiM9cRN+6FCoQ5cAWNNG1fKNtqcgk4
         pCO6lQuoYkwvJqZJSEbyh/P3ZcbbExkZF2O97c74E5WERbh+b4Ml3ukpUMGDqeuv0FrY
         kZofu8JfGRylBIiRyADKvQRLpKkw5BrH3E7qtBtdB25CiSryPZtMM63gva6SNrYAXZIb
         sLVQ==
X-Gm-Message-State: AOJu0YxqkzpsIXJ8+zz3V4EaD5f9l7WA/WdHTDbmmpwexxafvFZLGHtd
	sZ91nz+wTZBCOd5jUv5E6PzALvifCdMkJf+RRv4hvofXYtmM/FK1Pt06BRqynAvmkhg=
X-Gm-Gg: ASbGnctH1VkBRZPnGp5yFpHD+01fTqsJtj0o5u+fWNNs3BJpcmIlkaN493JgrT8dErY
	4o4Qif5yYIHYsVQe6ok0zGRHEkD5LKBPi8oleM8HtWTbP6XcYks0mhKlVftYVFIERU/ipnLB3Wm
	SHOJISOshEP839Gv/CBl2hEmkUitLAmwdJTER0p56PvIL+KYLYI2/zKfhV+bho+Fsmt8NGIymo3
	IpwEvLqHUYOE7N7DJJnzOE8D9EmUS/rNew3SmNqIaCiJZXm6pbGD69ZPQZj9sMUm99g4xdfLoPo
	x7tpY65L+PdFvvt9ZAoYzJ6XBAQ/yiIWgwtmD4VL7aGyfSTGUJRrfalv2+fxmJ2x/PqLApt3q+f
	B/PxziTyDVhaY8vOsT12OZFiNyElWkOhd7A==
X-Google-Smtp-Source: AGHT+IGXExmgR5lVqdOZBa0GhHJkmv3bhJquOjOTf0mlELCJBIQfmPSRvw2cRb/63yw5Mpo3FFMfAg==
X-Received: by 2002:a05:6512:2389:b0:553:3178:2927 with SMTP id 2adb3069b0e04-5533b8f3d7emr1492743e87.16.1748612863072;
        Fri, 30 May 2025 06:47:43 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com
Subject: [PATCH v3 2/5] xen/arm: dom0less: Add trap-unmapped-accesses
Date: Fri, 30 May 2025 15:45:56 +0200
Message-ID: <20250530134559.1434255-3-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Add the trap-unmapped-accesses per-domain fdt property.

Signed-off-by: Edgar E. Iglesias 
---
 docs/misc/arm/device-tree/booting.txt | 10 ++++++++++
 xen/arch/arm/dom0less-build.c         |  9 ++++++++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index 59fa96a82e..9add6440de 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -225,6 +225,16 @@ with the following properties:
     option is provided with a non zero value, but the platform doesn't support
     SVE.
 
+- trap-unmapped-accesses
+
+    Optional. An integer that configures handling of accesses to unmapped
+    address ranges.
+    If set to 0, guest accesses will read all bits as ones, e.g 0xFFFFFFFF
+    for a 32bit access and writes will be ignored.
+    If set to 1, guest accesses will trap.
+
+    This option is only implemented for ARM where the default is 1.
+
 - xen,enhanced
 
     A string property. Possible property values are:
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index a4e0a33632..69324aa597 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -344,8 +344,15 @@ void __init arch_create_domUs(struct dt_device_node *node,
 #endif
     }
 
-    /* Trap accesses to unmapped areas. */
+    /* Trap unmapped accesses by default. */
     d_cfg->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+    if ( dt_property_read_u32(node, "trap-unmapped-accesses", &val) )
+    {
+        if ( val > 1 )
+            panic("trap-unmapped-accesses: supported values are 0 or 1");
+        if ( !val )
+            d_cfg->flags &= ~XEN_DOMCTL_CDF_trap_unmapped_accesses;
+    }
 }
 
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:47:47 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:47:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001145.1381362 (Exim 4.92)
	(envelope-from )
	id 1uL05L-0003ye-6V; Fri, 30 May 2025 13:47:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001145.1381362; Fri, 30 May 2025 13:47: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 1uL05L-0003xe-0h; Fri, 30 May 2025 13:47:47 +0000
Received: by outflank-mailman (input) for mailman id 1001145;
 Fri, 30 May 2025 13:47:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL05J-0003C4-Ps
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:47:45 +0000
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [2a00:1450:4864:20::12d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a7e9374f-3d5c-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:47:41 +0200 (CEST)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-55324e35f49so2510636e87.3
 for ; Fri, 30 May 2025 06:47:41 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5533791cd9dsm706190e87.172.2025.05.30.06.47.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 06: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" 
X-Inumbo-ID: a7e9374f-3d5c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748612860; x=1749217660; 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;
        bh=cQ33hGWLZLWP4KAff3z9IviW+6yw08j6ihjaF/OCFuM=;
        b=D8zrcIEkYBOLedg4ORRREf0GXdoIIp6CIA1ZGkHEmshTBdEmpycKLR1Jj2cWnuHofm
         f9MLBAiTDbVGXVQOV+6adBvvXSXS5G8+9bnrbLrF+jbeFYT1xd/xVpfnKs0a1NdO/3uH
         8TTpOLgO85ut4gcF6xVJsGSzqWUPBj47yBSF/gh7tURxW1mtgK+rxz62aaFQ2gjExIKe
         SN+QFX1xLBrYhTFp52+cIktioMf+b7/cd/uIkNR+FKKPzPRIumGfHhK3vV2rFL5h07cB
         r++6wbVIAHpDEPUX6gJz2apptZcWHOIk8LEn6wQtjbFmnG/1Tw291eh5RTm8MiZiX9+A
         tXUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748612860; x=1749217660;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=cQ33hGWLZLWP4KAff3z9IviW+6yw08j6ihjaF/OCFuM=;
        b=uRfcJpieraDDbR2c3H26II98+ogaKszac6BV52cgNM26QAoVHLUoSGLj66FsCACWaV
         4XQpdErVEndkuw4eMJL3/0m511KdJr22HzVtIvxHAR/Dbdyw2DDAsyD5ELq8bKtFNCyc
         7CtH1tshJPz/K+WjiM2RESK9Egoy6tv4mhaMMl6Ig7xs7AbqVhSX61HTzq6HixPGiUeb
         4n61D0m42JPB6zcmblxwWcVuLnvbx78zSZLjVUfLLZt6h+fFVJZbMVGnN/bMciPM7Lld
         yg8kS4uA3Pr1f8x1a72bCvXmJNL4RoLFueWq88C/7nzKGr04I1rDh+CqFDLLua1iZvBw
         ydLg==
X-Gm-Message-State: AOJu0YxUuVwh52kfZ+hykzsIza0CHkpXBXHZB3aZfipdRh2SzifuY7eu
	rYBnaiUQZrkiAgUgcEUasF72MejZ+079AmLq8gyw72B7h3ALrbyWnbpOmeyhSzF7Zes=
X-Gm-Gg: ASbGncvPCFZWCIRAXKA06nI9fOj/qjy54pDA3QbjEbTiJhrz/9A2x4cZNPmmMhV57Lf
	GZF3Ju5mhOSqRGKYR1z+BOtCPtDU4+Oi/qOHp3b8rw4q/8MWHDljdMCsF73CHlhdZNXJLsUzKcX
	wFRU1mpaOO6JshwFtXERKaBZx5k5nniK36b2rQhrMeiZtx0YoMaZPSYllGHiNIOfSp1AzB0AGe7
	zweUyI7l5O1Xl2ZpD+U0yQbVx+KFquiO1hbXOjNNruqixFkMedPsiaIZmwX2u09rz9TwUDJuY08
	r356jrhkdAJ0wo1WDdsLMVrxeo2RYSirrPpgtuS/NnfFvkfF1sojFeSZGJoufU55tchz2ijPdXY
	Txf8+17ES315pTOe721w2y+HR/t9qj5A1Og==
X-Google-Smtp-Source: AGHT+IGv0UYzyrSEZY7vl1tJtk4r9JxlZ5FLdn1FwjHgg7Cc70ALCFd1xeT25r8fWb9UrhywYyTF5Q==
X-Received: by 2002:a05:6512:138d:b0:549:8b24:989d with SMTP id 2adb3069b0e04-5533b8511demr1266844e87.0.1748612860050;
        Fri, 30 May 2025 06:47:40 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com
Subject: [PATCH v3 0/5] xen/arm: Add option to optionally disable trapping on unmapped acceses
Date: Fri, 30 May 2025 15:45:54 +0200
Message-ID: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

This follows up on the virtio-pci discussion and adds a per-domain
option to select the behaviour of accesses to unmapped address ranges.
The new option is trap_unmapped_accesses, it's general but for now
only implemented for ARM.

I'm happy with any name, so if you have better ideas please suggest them!

I've included regenerated golang bindings as a separate patch.
We can drop it if it's not needed.

Thanks,
Edgar

ChangeLog:

v2 -> v3:
* Reword descriptions to clarify reads of all bits as ones.
* Use GENMASK as GENMASK_ULL not needed
* Style fix in if/else
* Regenerate golang bindings
* Update ocaml bindings

v1 -> v2:
* Rename trap_unmapped_mmio to trap_unmapped_accesses
* Generalize to allow other archs to later support this option
* Change dom0less DT binding from boolean to integer
* Remove changes to autogenerated go bindings

Edgar E. Iglesias (5):
  xen/arm: Add way to disable traps on accesses to unmapped addresses
  xen/arm: dom0less: Add trap-unmapped-accesses
  tools/arm: Add the trap_unmapped_accesses xl config option
  tools/ocaml: Update bindings for CDF_TRAP_UNMAPPED_ACCESSES
  tools/golang: Regenerate bindings for trap_unmapped_accesses

 docs/man/xl.cfg.5.pod.in              |  9 +++++++
 docs/misc/arm/device-tree/booting.txt | 10 ++++++++
 tools/golang/xenlight/helpers.gen.go  |  6 +++++
 tools/golang/xenlight/types.gen.go    |  1 +
 tools/libs/light/libxl_arm.c          |  3 +++
 tools/libs/light/libxl_create.c       |  3 +++
 tools/libs/light/libxl_types.idl      |  1 +
 tools/libs/light/libxl_x86.c          |  6 +++++
 tools/ocaml/libs/xc/xenctrl.ml        |  1 +
 tools/ocaml/libs/xc/xenctrl.mli       |  1 +
 tools/xl/xl_parse.c                   |  3 +++
 xen/arch/arm/dom0less-build.c         | 10 ++++++++
 xen/arch/arm/domain.c                 |  3 ++-
 xen/arch/arm/domain_build.c           |  3 ++-
 xen/arch/arm/io.c                     | 37 +++++++++++++++++++++++++--
 xen/common/domain.c                   |  3 ++-
 xen/include/public/domctl.h           |  4 ++-
 17 files changed, 98 insertions(+), 6 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:47:49 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:47:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001146.1381376 (Exim 4.92)
	(envelope-from )
	id 1uL05N-0004Qz-Bi; Fri, 30 May 2025 13:47:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001146.1381376; Fri, 30 May 2025 13:47: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 1uL05N-0004QH-7o; Fri, 30 May 2025 13:47:49 +0000
Received: by outflank-mailman (input) for mailman id 1001146;
 Fri, 30 May 2025 13:47:47 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL05L-0003C4-HJ
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:47:47 +0000
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [2a00:1450:4864:20::12a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aabb3907-3d5c-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:47:46 +0200 (CEST)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-54b10594812so2572224e87.1
 for ; Fri, 30 May 2025 06:47:46 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5533787d3e9sm711456e87.21.2025.05.30.06.47.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 06:47: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" 
X-Inumbo-ID: aabb3907-3d5c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748612865; x=1749217665; 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;
        bh=GTWMILHL3EAwB0ODltLM9oaziA5R/C4tb16Ifl8XTJg=;
        b=ndJt+wZJfHvN9He7xFzs6ntu9t206LWGn8NdbM8a1TG+avL5slVHNxdWsBEYLcToFW
         V9ugXKKjouWYDIrte4CevkQj+QpDRa4mNQZeV3SL6GzUv59KUDChn7oQY2ECKM8QmEmF
         IFWYLlIahOaj4Mw3aSYmbN/Dke91VR9GGjl37LMpEoZWbrFWJYcp2MV17VW2wva/+UXZ
         3Axy/a8Y3UactNm3Z/i+V15tyl8mYychF7IxXQVNofjF8gpo6Kh8ibXtDntz6Ij11din
         AENhwigQ+/qSEy+9v78V6aGzaBS1ET9yXecffgmzShMJtu9HwXTteITKZzI5eRIhwbPn
         U/rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748612865; x=1749217665;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GTWMILHL3EAwB0ODltLM9oaziA5R/C4tb16Ifl8XTJg=;
        b=DXWz4ao4EglxGGAhZQXhMQdPE3u6J6jQGjpJbiiUQ7DpHvdNkL22Xci2Ibp+TgpH6v
         5PDP1x/wQ2U+F6x64iMa7Tv/thklT6+j4W8YIsNc1+kfZ6dkSX++X5n3t+lPIwWUGlXe
         +9SF/9XzfmQWnyU2eF1zcp3F4bLMBJdmgORrOoWD3diSwFtgo3uQKQr2zWMNAxAwsolJ
         5eGof+RxvhSxPsanaP9r4sbWym6bxysS7muf94sUp5qth2RedY89EAwvW2bDAzJa6qlC
         LmnbY5Kxyj/NFdadMJGgIB070LyYzXaFVbNxDMdxYwnTHLGlQs5sgJQWxPSEphSfl1Ea
         D4Eg==
X-Gm-Message-State: AOJu0YxAU5dQgHfx2+882aNJ5UOY1ZHAHCh1L0x/xcsmwNlxeG7YsgXK
	NTTi2eggSY8hD4nloaDFM7rrCCdRvt//8a991KYjU0x1IExktymx2Vv+Zs/AdhaZlfE=
X-Gm-Gg: ASbGncszTb3eb23dhnl8T4066bheeXk4PU/ag3mmbdZywVH3MbL+u2SGYVmmP0oahFA
	fico06yXY+q+PaeEAabtS3/I551w6QqnvsTbh6mISw6ON3VSNQ/q0F7HB6Sn+nIHX2MWvkzU7Jz
	GjZMuJCytLlrPv4VlcPPskqu34uEzrhNN7t3qdIm/65plG3R82aeBs7a2EBkebpB9CS3Tk0loT6
	brstYfr5cAuucJFva8vHVYPu067vqcj8xSuqB6EF2qvzcu7GiAfUXix3dsXEUMEukRlraAbaT9s
	N+RisbfLkLhkLRcmVFMaoXqa9KLKCh/qxPAfXd4OxhY5QGvJXkmx19NK/xhEua6g/fIaFZAWXUP
	jn9onHqoFaf1ES1qTwsMXtUw=
X-Google-Smtp-Source: AGHT+IEZmxUSOBDe6/urRoNjrpd4T09riYBv/prcyno4acPjUc1Uc1flr/Q4ypXAzcpkfPnwwEjGVg==
X-Received: by 2002:a05:6512:e97:b0:553:2b9a:3c52 with SMTP id 2adb3069b0e04-5533b8f5bfcmr1214602e87.20.1748612864767;
        Fri, 30 May 2025 06:47:44 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com,
	Anthony PERARD ,
	Juergen Gross 
Subject: [PATCH v3 3/5] tools/arm: Add the trap_unmapped_accesses xl config option
Date: Fri, 30 May 2025 15:45:57 +0200
Message-ID: <20250530134559.1434255-4-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Signed-off-by: Edgar E. Iglesias 
---
 docs/man/xl.cfg.5.pod.in         | 9 +++++++++
 tools/libs/light/libxl_arm.c     | 6 +++---
 tools/libs/light/libxl_create.c  | 3 +++
 tools/libs/light/libxl_types.idl | 1 +
 tools/libs/light/libxl_x86.c     | 6 ++++++
 tools/xl/xl_parse.c              | 3 +++
 6 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 7339c44efd..6c303e8efa 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3089,6 +3089,15 @@ will be used for the domain. Otherwise, the value specified by the `nr_spis`
 parameter will be used. The number of SPIs should match the highest interrupt
 ID that will be assigned to the domain.
 
+=item B
+
+An Optional boolean parameter that configures handling of accesses to unmapped
+address ranges. If enabled, guest accesses will trap. If disabled, guest
+accesses will read all bits as ones, e.g 0xFFFFFFFF for a 32bit access and
+writes will be ignored.
+
+This option is only implemented for ARM where the default is enabled.
+
 =back
 
 =head3 x86
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 9530996e72..afc62a5299 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -233,9 +233,6 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
         config->arch.sve_vl = d_config->b_info.arch_arm.sve_vl / 128U;
     }
 
-    /* Trap accesses to unmapped areas. */
-    config->flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
-
     return 0;
 }
 
@@ -1714,6 +1711,9 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
     /* ACPI is disabled by default */
     libxl_defbool_setdefault(&b_info->acpi, false);
 
+    /* Trapping of unmapped accesses enabled by default.  */
+    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, true);
+
     /* Sanitise SVE parameter */
     if (b_info->arch_arm.sve_vl) {
         unsigned int max_sve_vl =
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index e03599ea99..38770eea5b 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -667,6 +667,9 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
         if (libxl_defbool_val(b_info->vpmu))
             create.flags |= XEN_DOMCTL_CDF_vpmu;
 
+        if (libxl_defbool_val(b_info->trap_unmapped_accesses))
+            create.flags |= XEN_DOMCTL_CDF_trap_unmapped_accesses;
+
         assert(info->passthrough != LIBXL_PASSTHROUGH_DEFAULT);
         LOG(DETAIL, "passthrough: %s",
             libxl_passthrough_to_string(info->passthrough));
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 9bb2969931..e33785c661 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -736,6 +736,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("vmtrace_buf_kb", integer),
 
     ("vpmu", libxl_defbool),
+    ("trap_unmapped_accesses", libxl_defbool),
 
     ], dir=DIR_IN,
        copy_deprecated_fn="libxl__domain_build_info_copy_deprecated",
diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
index 0b1c2d3a96..a9d470c9f6 100644
--- a/tools/libs/light/libxl_x86.c
+++ b/tools/libs/light/libxl_x86.c
@@ -26,6 +26,11 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
     if (libxl_defbool_val(d_config->b_info.arch_x86.msr_relaxed))
         config->arch.misc_flags |= XEN_X86_MSR_RELAXED;
 
+    if (libxl_defbool_val(d_config->b_info.trap_unmapped_accesses)) {
+            LOG(ERROR, "trap_unmapped_accesses is not supported on x86\n");
+            return ERROR_FAIL;
+    }
+
     return 0;
 }
 
@@ -813,6 +818,7 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
 {
     libxl_defbool_setdefault(&b_info->acpi, true);
     libxl_defbool_setdefault(&b_info->arch_x86.msr_relaxed, false);
+    libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, false);
 
     /*
      * The config parameter "altp2m" replaces the parameter "altp2mhvm".
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 089a88935a..40da75ef74 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2975,6 +2975,9 @@ skip_usbdev:
     if (!xlu_cfg_get_long (config, "nr_spis", &l, 0))
         b_info->arch_arm.nr_spis = l;
 
+    xlu_cfg_get_defbool(config, "trap_unmapped_accesses",
+                        &b_info->trap_unmapped_accesses, 0);
+
     parse_vkb_list(config, d_config);
 
     d_config->virtios = NULL;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:47:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:47:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001148.1381386 (Exim 4.92)
	(envelope-from )
	id 1uL05O-0004i0-Nn; Fri, 30 May 2025 13:47:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001148.1381386; Fri, 30 May 2025 13:47:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL05O-0004hr-JN; Fri, 30 May 2025 13:47:50 +0000
Received: by outflank-mailman (input) for mailman id 1001148;
 Fri, 30 May 2025 13:47:49 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL05N-0003C4-7O
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:47:49 +0000
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com
 [2a00:1450:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id abb7e610-3d5c-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:47:47 +0200 (CEST)
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-55329bd977aso3135453e87.1
 for ; Fri, 30 May 2025 06:47:47 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553379377f4sm704030e87.229.2025.05.30.06.47.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 06:47: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" 
X-Inumbo-ID: abb7e610-3d5c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748612867; x=1749217667; 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;
        bh=DTn2B6C64BsBJ/wVOSgKG1LWM5jCpfJNwTLjcuvqmOQ=;
        b=ScM8O9K8T/ci+/XcGO/l2gm7WNk3B+LNbM1GVSCk21wn12x5W+1VZ2x+jFN/5eTkd9
         WMkakPrf5/IhP6I4dbmIaLQwiD5y0JMvV0+8796VAaVVdyudUANuH7x6f3c60npWPxkv
         GDjlx7PtHWYzVUZJqHBJTCexH3fHpRQ/LQ4mK3vk7+h7wW7coi0aARpL8K/XCmrUyUqu
         rH4Sw7xqWysGy9U7RPR3T8kvrkf5FqBA8xSpw/h6IgPXSvZ/I2Z/h+/HJrzY1sXITEAd
         0dLkgNj8e6cyHAAqSPpBgv6kS2OxgZ38YP+yxAd+3eJfP7wvB9ZKbq/Zn4PnxSfPlC9a
         ApDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748612867; x=1749217667;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=DTn2B6C64BsBJ/wVOSgKG1LWM5jCpfJNwTLjcuvqmOQ=;
        b=QQRO3KkK+KRT+lyUsyAZ+5ha5ugfQxz7IdAz7hhFpoIMJ0+skSmke8ea183uvpDxIw
         UtpeveEU4xIR2dlpRBXx44JZm2Al3+Jrrz4iZ4v+PFM1LYdUi2Dz/bO97/xySjWqXRxs
         78bCnVZtO1rV2lJc1IZYJJUtNz0dxoVIc5vY0AsfBX3p0Y8vX4MdlvHyCtpyN+LvE4QT
         94J3pdhoEMJgSPJufQgXjx5ipOYbieun5RoetUe8NWCUk8k/qSUqeTX0rvGhBtkwnKQz
         p338tU+psVx43V+io92D9zdCTlAA2bZJX12GFeFejpwJhbuiJ5QGXPs2f4OOrKcNxGNI
         WnFA==
X-Gm-Message-State: AOJu0YxYSRnH/65eddsK4y1MuaLz56j3ltACCMcpgEcK/W7B8ULCTcad
	p3g5O7rnRgyASraX2qq6MjLlIywy3cTTPH5cR6G8+5e6Y1mDtO7zYmXleos0vB16JYE=
X-Gm-Gg: ASbGnctQvhBn5POZu2GnV5rVtF3+2lV8+9mMCrHTnodCjfRa47mt5qdebb6kWmPpjcB
	7Uj2E3oGbmz5f55wSuS9oiqaRvvutV7c6yeXn0JLXjOEUvFG3uzcusbHTuUc/h2ggOv+rFa7yNu
	gRsqy5Ljjc/cnt2dYY7ZV26TAW+jSolZ4o8PKLLD9MKueFT+ZudvqpDpNfa3Ffz9iXT9e+Cfk6A
	/+UWUEufiM4RDQa+nwkDOWNtcQ2e0QAZUAXfL7XKvJTI3rPpa9h0owtWKR876IwwbH+2hmy/xgx
	uLmH/cxR1hGlCctikYbsQs1USNgcUld8/Ynh4icskpssiaPVQLI/ZHVZ2uKPHDHm80wfJJ/To+L
	khSm9VgEzLR3vf/WlwjtssJ8=
X-Google-Smtp-Source: AGHT+IGUw3jW13S4FcruO1tndtUR81rZvgF2eSy5dew8CqP2bKabLRGvtqDzU42K8uYU8DePLFyswA==
X-Received: by 2002:a05:6512:2208:b0:553:243c:c1d3 with SMTP id 2adb3069b0e04-55335b3bfafmr2570125e87.18.1748612866446;
        Fri, 30 May 2025 06:47:46 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com,
	Christian Lindig ,
	David Scott ,
	Anthony PERARD 
Subject: [PATCH v3 4/5] tools/ocaml: Update bindings for CDF_TRAP_UNMAPPED_ACCESSES
Date: Fri, 30 May 2025 15:45:58 +0200
Message-ID: <20250530134559.1434255-5-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Signed-off-by: Edgar E. Iglesias 
---
 tools/ocaml/libs/xc/xenctrl.ml  | 1 +
 tools/ocaml/libs/xc/xenctrl.mli | 1 +
 2 files changed, 2 insertions(+)

diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 2690f9a923..7e1aabad6c 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -70,6 +70,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_TRAP_UNMAPPED_ACCESSES
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index febbe1f6ae..f44dba61ae 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -63,6 +63,7 @@ type domain_create_flag =
   | CDF_IOMMU
   | CDF_NESTED_VIRT
   | CDF_VPMU
+  | CDF_TRAP_UNMAPPED_ACCESSES
 
 type domain_create_iommu_opts =
   | IOMMU_NO_SHAREPT
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:47:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:47:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001150.1381395 (Exim 4.92)
	(envelope-from )
	id 1uL05Q-00050G-1v; Fri, 30 May 2025 13:47:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001150.1381395; Fri, 30 May 2025 13:47:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL05P-0004zU-U8; Fri, 30 May 2025 13:47:51 +0000
Received: by outflank-mailman (input) for mailman id 1001150;
 Fri, 30 May 2025 13:47:50 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL05O-0003es-N2
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:47:50 +0000
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com
 [2a00:1450:4864:20::12c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id acf3b013-3d5c-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 15:47:49 +0200 (CEST)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-54d6f933152so3098325e87.1
 for ; Fri, 30 May 2025 06:47:49 -0700 (PDT)
Received: from gmail.com (213-67-3-247-no600.tbcn.telia.com. [213.67.3.247])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-553378a1289sm709009e87.91.2025.05.30.06.47.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 06:47: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" 
X-Inumbo-ID: acf3b013-3d5c-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748612868; x=1749217668; 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;
        bh=vQZpCaGwN67bAjam9mj+oezbvKc88yCztRac3tGbr1g=;
        b=HDii7KYGqw9Rc5nHuCNKq4JkNVz+3iaq67aZDddv6lYIdQwPGMamQsynMKo/N1RH6K
         wlc9ppawY1PETmWXG90VgkKkVaDLxu4/SxyTzzzlS8XeeuBHAThAuT9oml53+dCYBCRH
         yFLI8MiIY0VLaR0XD0v10BnU91nNZthvKyMJxbARiMonPputxP1x0IKDfa2jJawXt+9E
         joYslhLwkukLA18HbFDs1KMh+gE/A3RP0rjv24cp8zV4OnY8GtO+Fo8m/MGV0LHEp904
         d+JvuIr2KJNYNqBOetbJp2hrwueJPZO5OgJr4kASLv36nPB8VdXCIt+ApJNVF9MO70N0
         4gnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748612868; x=1749217668;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=vQZpCaGwN67bAjam9mj+oezbvKc88yCztRac3tGbr1g=;
        b=kytHy8OET73HtvLcD9QSrXf5UpNZojDkhvhfwMLsp5UcbXppZdGA0YIS+26gc+tbn+
         eklOhRb+ABRcSQ1FLaC5BA+5HSN6tPjhfKqzByLn+O9kdLSjQThw3EMe4iHaxS4mF/B3
         ac8ZJ7LJuw2FOpK3zy8tZOvk3e43otx1BMHZoQBKkHm0pcY6+QdMJYUhfiylDVBPalyb
         4ofoVagQeMs/GwwyRW90sZSFHqBqAUnxgnPc89SYEMmbbMs1M+1DI8mIUuBTeNYxZqjD
         m8g6UpxRHtDmVUzL0S1w9VKGwgln5NLT0hDT2za5YNragu3Wb7alZudvdfU7eG+MP0rh
         p3nA==
X-Gm-Message-State: AOJu0YwKJcUcLK+YKnVR8xRac2SLJ4zwL7dFBW3HiymcOqB6kVDjsBWF
	So5DBXlqwnnYX2Ehgr01UVEl32A0KxWk6JFg9LTysicWYenyVHrLMqrNqkz4q4iSf4Y=
X-Gm-Gg: ASbGncuEQ4uk7WWxkLwIMYciKKV6QlCeRY0YANaCY4exJIZvIsG1We/3oB0KDKH0USD
	tEO2UM1kwTh9Km0rKmiCrmRXHzZIYvFWOHowm6utMUFPpW+LuYLvHf2cCw4cPB24eON+HGb6ut9
	St7Jldartp74/Z2FPhrzDG5JKpDZDE301BYRmpCEyjIhQA7vO0koPyDLxspsTmM9Aq+bflEn35O
	zjJaKB8/2MA/0dVPi8pGzJJlAGDA7L4sJFnBVRb6VjH18y8uGbSFD9N9Qd2qDO6j31kHCF6Wl3y
	K9HrABd52upzY/ql17oCVjV2ZtNaiWWDgqzwxbDwA7p8OhCUs8FPggSVErMyOMDe7gC/vfJy3Vw
	U6aL2g5KrQntY1AszVwO6dAc=
X-Google-Smtp-Source: AGHT+IGVA5bzYPh2ADeFZH8z6EWHptuztxYvga4b8OcKYgpiNbmuvFvfvnJ6lIkQYGjdJf5MOmgj6Q==
X-Received: by 2002:a05:6512:3d88:b0:553:202e:a41c with SMTP id 2adb3069b0e04-5533d1aba19mr871799e87.28.1748612868136;
        Fri, 30 May 2025 06:47:48 -0700 (PDT)
From: "Edgar E. Iglesias" 
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,
	edgar.iglesias@amd.com,
	Nick Rosbrook ,
	George Dunlap ,
	Anthony PERARD 
Subject: [PATCH v3 5/5] tools/golang: Regenerate bindings for trap_unmapped_accesses
Date: Fri, 30 May 2025 15:45:59 +0200
Message-ID: <20250530134559.1434255-6-edgar.iglesias@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: "Edgar E. Iglesias" 

Signed-off-by: Edgar E. Iglesias 
---
 tools/golang/xenlight/helpers.gen.go | 6 ++++++
 tools/golang/xenlight/types.gen.go   | 1 +
 2 files changed, 7 insertions(+)

diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
index 90846ea8e8..191be87297 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -1170,6 +1170,9 @@ x.Altp2M = Altp2MMode(xc.altp2m)
 x.VmtraceBufKb = int(xc.vmtrace_buf_kb)
 if err := x.Vpmu.fromC(&xc.vpmu);err != nil {
 return fmt.Errorf("converting field Vpmu: %v", err)
+}
+if err := x.TrapUnmappedAccesses.fromC(&xc.trap_unmapped_accesses);err != nil {
+return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err)
 }
 
  return nil}
@@ -1695,6 +1698,9 @@ xc.altp2m = C.libxl_altp2m_mode(x.Altp2M)
 xc.vmtrace_buf_kb = C.int(x.VmtraceBufKb)
 if err := x.Vpmu.toC(&xc.vpmu); err != nil {
 return fmt.Errorf("converting field Vpmu: %v", err)
+}
+if err := x.TrapUnmappedAccesses.toC(&xc.trap_unmapped_accesses); err != nil {
+return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err)
 }
 
  return nil
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
index e7667f1ce3..656933c6c9 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -606,6 +606,7 @@ MsrRelaxed Defbool
 Altp2M Altp2MMode
 VmtraceBufKb int
 Vpmu Defbool
+TrapUnmappedAccesses Defbool
 }
 
 type DomainBuildInfoTypeUnion interface {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 13:50:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 13:50:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001172.1381406 (Exim 4.92)
	(envelope-from )
	id 1uL07f-0008Lk-FT; Fri, 30 May 2025 13:50:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001172.1381406; Fri, 30 May 2025 13: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 1uL07f-0008Ld-Bj; Fri, 30 May 2025 13:50:11 +0000
Received: by outflank-mailman (input) for mailman id 1001172;
 Fri, 30 May 2025 13:50:10 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL07d-0007IR-TZ
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 13:50:09 +0000
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [2a00:1450:4864:20::432])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fda4923a-3d5c-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 15:50:05 +0200 (CEST)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3a374f727dbso1706809f8f.0
 for ; Fri, 30 May 2025 06:50:05 -0700 (PDT)
Received: from smtpclient.apple ([46.149.103.8])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4efe7414fsm4942617f8f.55.2025.05.30.06.50.03
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 30 May 2025 06:50:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fda4923a-3d5c-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1748613004; x=1749217804; darn=lists.xenproject.org;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qK2Ed9z4bG2W4/4I+bv1c1mEUgT6EAD8q9y3gJhg3uk=;
        b=HtT/+e01DkMyjWJV5Fc3AvcrFXkcgm5g5MUNCrU2EXqIUB4OtlSzN8fpYOaJck5pal
         wZDcIBpnr5GS+TTKAjbC5p5h1rltku9zomOK7helAO4cQIFcH91nk8rvhn0/xP5KPVdO
         +u0rVvU1XThara5+/g6AKDJhg9vyzvMyY7Mfg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748613004; x=1749217804;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=qK2Ed9z4bG2W4/4I+bv1c1mEUgT6EAD8q9y3gJhg3uk=;
        b=M4r0UtsuEETc8P3RCsA9IVWLl9H/bN0m/0zjbu2VP5ah5QpKMs0nfmBysv6OXJBITZ
         BEODCoDHdYbDk2EamrqyIFVvOH7Kh/FYDoJkybGHtopclKmC4K4ZaERMqusNJUlvSpWa
         sXGzOt/qplVuWJRSDyZszZj61RHKQQYdLXH4NSkPb6lOLLQtzHvN+3m1wAERTeb9vnMZ
         34y40pObUxdUrgOkF3LGAWwtx3r/ZatmHW3CvNbiPeQvfEPr9sBm82N6q0cMOV5srYV/
         cnI55kVGSaF+9jvuACVvLgClxpaRqeEL/4OukZT02+aqJI3Yw0iWVtNnA8Pchi6woAnr
         IZEQ==
X-Gm-Message-State: AOJu0YwZhZ67SB/mS4tooP2+WHsEkA1oMyWbWXx/fbT/WxhkMuFd2hds
	XY99p6fdqMP1qbCHSt0XdA9K/d88vqyxcC5fJDOYKR31XMO6LqH0gMee+eJRnnTw2TY=
X-Gm-Gg: ASbGncuKiKpiLe2hAgHfDb+S/J2aNJviaJJEqWAdUI12gs2Dcef35XAticUVHz9dCBW
	tzJRbnBADLMl4U/4EF+UKc3gWYpjWzk8XwFmI/XnRNBkOhx6BbjRsc5qEdLi+79kWonPnGRb1T8
	sUkYalq8D4GIpSDbE6q1bC3zJFEfKxnjpwUH85uSRlKax/VEq3Dxj5GRlgwcuRAvyb7d2gBLDQo
	zjl1Mr8CWhWAfumng+47RyEjQrVcDgSguuiroOJN3i+VL6sOL3c27X6P2VKem/ZU/7u6CqJWw29
	kGVYJpRCpxHqp1mM6tTv3Gs0JdARLHRkTjm53W3mRa0dtECSZX13fhxtS+L/okQAvBW625QfPph
	pQWCl
X-Google-Smtp-Source: AGHT+IE6xYFq0XqIerB02BuRQHWvWMJpmkmW6VZv6rhSrvuu1GkD/0S/MLnm/GJOHZc5Rf5xm2MFvw==
X-Received: by 2002:a5d:588d:0:b0:3a4:e6c6:b8bf with SMTP id ffacd0b85a97d-3a4f89df3cdmr1913053f8f.52.1748613004559;
        Fri, 30 May 2025 06:50:04 -0700 (PDT)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: [PATCH v3 4/5] tools/ocaml: Update bindings for
 CDF_TRAP_UNMAPPED_ACCESSES
From: Christian Lindig 
In-Reply-To: <20250530134559.1434255-5-edgar.iglesias@gmail.com>
Date: Fri, 30 May 2025 14:49:53 +0100
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,
 edgar.iglesias@amd.com,
 Christian Lindig ,
 David Scott ,
 Anthony PERARD 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20250530134559.1434255-1-edgar.iglesias@gmail.com>
 <20250530134559.1434255-5-edgar.iglesias@gmail.com>
To: "Edgar E. Iglesias" 
X-Mailer: Apple Mail (2.3826.500.181.1.5)

Acked-by: Christian Lindig 

> On 30 May 2025, at 14:45, Edgar E. Iglesias  =
wrote:
>=20
> From: "Edgar E. Iglesias" 
>=20
> Signed-off-by: Edgar E. Iglesias 
> ---
> tools/ocaml/libs/xc/xenctrl.ml  | 1 +
> tools/ocaml/libs/xc/xenctrl.mli | 1 +
> 2 files changed, 2 insertions(+)
>=20
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml =
b/tools/ocaml/libs/xc/xenctrl.ml
> index 2690f9a923..7e1aabad6c 100644
> --- a/tools/ocaml/libs/xc/xenctrl.ml
> +++ b/tools/ocaml/libs/xc/xenctrl.ml
> @@ -70,6 +70,7 @@ type domain_create_flag =3D
>   | CDF_IOMMU
>   | CDF_NESTED_VIRT
>   | CDF_VPMU
> +  | CDF_TRAP_UNMAPPED_ACCESSES
>=20
> type domain_create_iommu_opts =3D
>   | IOMMU_NO_SHAREPT
> diff --git a/tools/ocaml/libs/xc/xenctrl.mli =
b/tools/ocaml/libs/xc/xenctrl.mli
> index febbe1f6ae..f44dba61ae 100644
> --- a/tools/ocaml/libs/xc/xenctrl.mli
> +++ b/tools/ocaml/libs/xc/xenctrl.mli
> @@ -63,6 +63,7 @@ type domain_create_flag =3D
>   | CDF_IOMMU
>   | CDF_NESTED_VIRT
>   | CDF_VPMU
> +  | CDF_TRAP_UNMAPPED_ACCESSES
>=20
> type domain_create_iommu_opts =3D
>   | IOMMU_NO_SHAREPT
> --=20
> 2.43.0
>=20



From xen-devel-bounces@lists.xenproject.org Fri May 30 14:03:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:03:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001218.1381417 (Exim 4.92)
	(envelope-from )
	id 1uL0KX-0005FQ-HR; Fri, 30 May 2025 14:03:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001218.1381417; Fri, 30 May 2025 14:03: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 1uL0KX-0005FJ-DB; Fri, 30 May 2025 14:03:29 +0000
Received: by outflank-mailman (input) for mailman id 1001218;
 Fri, 30 May 2025 14:03:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL0KW-0005FC-2G
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:03:28 +0000
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com
 [2a00:1450:4864:20::429])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dbad9021-3d5e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 16:03:27 +0200 (CEST)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-3a4c6c0a9c7so1366308f8f.3
 for ; Fri, 30 May 2025 07:03:27 -0700 (PDT)
Received: from localhost (112.pool92-178-7.dynamic.orange.es. [92.178.7.112])
 by smtp.gmail.com with UTF8SMTPSA id
 5b1f17b1804b1-450d8012b09sm18715585e9.37.2025.05.30.07.03.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 07: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" 
X-Inumbo-ID: dbad9021-3d5e-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748613806; x=1749218606; darn=lists.xenproject.org;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date:from:to
         :cc:subject:date:message-id:reply-to;
        bh=pwoWV4YWQnhRonAsr2ZbQBGENx07n89BubpTlvVFG/0=;
        b=Cvjjwkh7v7Fkng0IoPR1ZmnKYRgjbonvjl2Eh7OP1KCRfN46ZE7Ax5+OSr5oRqwIkj
         nzC5lRvzFlFdhz6xUUxMrUJMNYpHOnmAcXAdb7oanpfJGD8BBfsO5kkY3Khq6nKWz12D
         tYQ+rMUbUI0lnYWxKCsA3YFJodTgt4wtPwpQk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748613806; x=1749218606;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=pwoWV4YWQnhRonAsr2ZbQBGENx07n89BubpTlvVFG/0=;
        b=tnFBVT8N5jmNxPUG3y5VCxdsv2I4FjmEm/QygXDxgpa9ET9U8NyM/p6kIJDzrjQwTL
         fam0IqbyxJObjG52Hq9t0vWF9mfzqsuQjtbezwCFVVEa/lstpi6VhwJi7zRS7ZPiWNPe
         UMV+xQ/VZQWOwIfY1De6NHKwH3uyUR+SSfJbpfiQobOm291j6jtc3g6Jy8lc25gZkYxf
         VLK2RKmAYRpmIdKYWP3yNYMkqHMWk4l62Iet6agFXkItnHHfNn+ypxBHRwTIZfzrl34k
         kUiRp7wH9lNOuCuXQvFAeNWzFDUVrqPq/5oHGrqA1/NLVNVk9/J+9LwnTfVsrvMHSpxS
         Zfdw==
X-Gm-Message-State: AOJu0Yya9R0QGyNowuYxeMJIgtn6PMXi8BBXRMp/0UphYRTz//8kOobw
	AgQHj5UjOTmHgxwQ6cyNxl3xbKUdAJINaD4e6q/oZh3YnOXfT40U2R4UVS7yb6xkhX2aHJCI3oj
	XjKpO
X-Gm-Gg: ASbGncvgrraQGWLK+zkAkofl8mDxI2K9OwTxx5oPxD4lPungWsID7LSzfPSRKcxVUSE
	wKjpZdXz5BT2ejSOHPy+Fw3AZIxOjcSjfd4muJUjGVlHlyrmObQjWitfjXweHGgGpa3DpTgcEk6
	t6dwgBl4l0qZGmFCIrRZVHOvdGYWgh/VoadDE+ZLFQ9HhOiF1KuajZ06Mt9GvBdMh0LrbPJwDNG
	OVKvA2DkEgklnjUdqEaZJo0DCVN8w6is1LNq9ZpxmSoo5zbIErF8QQf68J/aUU8kJtTA7acRu8v
	80h9syF+xyFZet20r9t+hubGG1Ein+jRI6/FniK0w8ArQQC/WPPUQwx0WRAmL9n34294mkh9DlA
	mQcVbdEpIbftniLzs7gHBlZC7
X-Google-Smtp-Source: AGHT+IFT7L+seHHQAf7Y5KFqVx7ZUGM54eSERjkDhRBxFY8sP+0s25jQ8CrpWtr6ui5qZw0emV8zIw==
X-Received: by 2002:a05:6000:2886:b0:3a4:f722:f98d with SMTP id ffacd0b85a97d-3a4f89e8f63mr2027206f8f.51.1748613795492;
        Fri, 30 May 2025 07:03:15 -0700 (PDT)
Date: Fri, 30 May 2025 16:03:14 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD 
Subject: Re: [PATCH] tools/tests: Add install target for vPCI
Message-ID: 
References: <20250530104307.2550886-1-andrew.cooper3@citrix.com>
 
 <2912f117-a898-41dd-9e1f-2723728a2237@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2912f117-a898-41dd-9e1f-2723728a2237@citrix.com>

On Fri, May 30, 2025 at 01:29:49PM +0100, Andrew Cooper wrote:
> On 30/05/2025 11:57 am, Roger Pau Monné wrote:
> > On Fri, May 30, 2025 at 11:43:07AM +0100, Andrew Cooper wrote:
> >> This lets it run automagically in CI.
> >>
> >> Signed-off-by: Andrew Cooper 
> > Acked-by: Roger Pau Monné 
> >
> > I had sent something similar long time ago:
> >
> > https://lore.kernel.org/xen-devel/20230313121226.86557-1-roger.pau@citrix.com/
> >
> > But got no reviews.
> >
> > Thanks, Roger.
> 
> Sorry, that fell through the cracks too.
> 
> What I'll do if you're happy is submit it as authored by you but with
> this content (seeing as it's the one I've tested in the past week), and
> A-by me.

Oh, no worries about authorship, you can just commit this one really.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri May 30 14:05:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:05:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001224.1381426 (Exim 4.92)
	(envelope-from )
	id 1uL0M9-00064z-QO; Fri, 30 May 2025 14:05:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001224.1381426; Fri, 30 May 2025 14: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 1uL0M9-00064s-NF; Fri, 30 May 2025 14:05:09 +0000
Received: by outflank-mailman (input) for mailman id 1001224;
 Fri, 30 May 2025 14:05:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL0M7-00064k-V4
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:05:07 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 166495fb-3d5f-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 16:05:06 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 82C55169C;
 Fri, 30 May 2025 07:04:48 -0700 (PDT)
Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com
 [10.1.196.27])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D6E5D3F673;
 Fri, 30 May 2025 07: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" 
X-Inumbo-ID: 166495fb-3d5f-11f0-a2ff-13f23c93f187
From: Ryan Roberts 
To: Catalin Marinas ,
	Will Deacon ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	"David S. Miller" ,
	Andreas Larsson ,
	Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Boris Ostrovsky ,
	"Aneesh Kumar K.V" ,
	Andrew Morton ,
	Peter Zijlstra ,
	Arnd Bergmann ,
	David Hildenbrand ,
	Lorenzo Stoakes ,
	"Liam R. Howlett" ,
	Vlastimil Babka ,
	Mike Rapoport ,
	Suren Baghdasaryan ,
	Michal Hocko ,
	Alexei Starovoitov ,
	Andrey Ryabinin 
Cc: Ryan Roberts ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	virtualization@lists.linux.dev,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org
Subject: [RFC PATCH v1 0/6] Lazy mmu mode fixes and improvements
Date: Fri, 30 May 2025 15:04:38 +0100
Message-ID: <20250530140446.2387131-1-ryan.roberts@arm.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi All,

I recently added support for lazy mmu mode on arm64. The series is now in
Linus's tree so should be in v6.16-rc1. But during testing in linux-next we
found some ugly corners (unexpected nesting). I was able to fix those issues by
making the arm64 implementation more permissive (like the other arches). But
this is quite fragile IMHO. So I'd rather fix the root cause and ensure that
lazy mmu mode never nests, and more importantly, that code never makes pgtable
modifications expecting them to be immediate, not knowing that it's actually in
lazy mmu mode so the changes get deferred.

The first 2 patches are unrelated, very obvious bug fixes. They don't affect
arm64 because arm64 only uses lazy mmu for kernel mappings. But I noticed them
during code review and think they should be fixed.

The next 3 patches are aimed at solving the nesting issue.

And the final patch is reverting the "permissive" fix I did for arm64, which is
no longer needed after the previous 3 patches.

I've labelled this RFC for now because it depends on the arm64 lazy mmu patches
in Linus's master, so it won't apply to mm-unstable. But I'm keen to get review
and siince I'm touching various arches and modifying some core mm stuff, I
thought that might take a while so thought I'd beat the rush and get a first
version out early.

I've build-tested all the affected arches. And I've run mm selftests for the
arm64 build, with no issues (with DEBUG_PAGEALLOC and KFENCE enabled).

Applies against Linus's master branch (f66bc387efbe).

Thanks,
Ryan


Ryan Roberts (6):
  fs/proc/task_mmu: Fix pte update and tlb maintenance ordering in
    pagemap_scan_pmd_entry()
  mm: Fix pte update and tlb maintenance ordering in
    migrate_vma_collect_pmd()
  mm: Avoid calling page allocator from apply_to_page_range()
  mm: Introduce arch_in_lazy_mmu_mode()
  mm: Avoid calling page allocator while in lazy mmu mode
  Revert "arm64/mm: Permit lazy_mmu_mode to be nested"

 arch/arm64/include/asm/pgtable.h              | 22 ++++----
 .../include/asm/book3s/64/tlbflush-hash.h     | 15 ++++++
 arch/sparc/include/asm/tlbflush_64.h          |  1 +
 arch/sparc/mm/tlb.c                           | 12 +++++
 arch/x86/include/asm/paravirt.h               |  5 ++
 arch/x86/include/asm/paravirt_types.h         |  1 +
 arch/x86/kernel/paravirt.c                    |  6 +++
 arch/x86/xen/mmu_pv.c                         |  6 +++
 fs/proc/task_mmu.c                            |  3 +-
 include/asm-generic/tlb.h                     |  2 +
 include/linux/mm.h                            |  6 +++
 include/linux/pgtable.h                       |  1 +
 kernel/bpf/arena.c                            |  6 +--
 mm/kasan/shadow.c                             |  2 +-
 mm/memory.c                                   | 54 ++++++++++++++-----
 mm/migrate_device.c                           |  3 +-
 mm/mmu_gather.c                               | 15 ++++++
 17 files changed, 128 insertions(+), 32 deletions(-)

--
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 14:05:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:05:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001225.1381437 (Exim 4.92)
	(envelope-from )
	id 1uL0MD-0006KR-19; Fri, 30 May 2025 14:05:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001225.1381437; Fri, 30 May 2025 14:05: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 1uL0MC-0006KK-Tk; Fri, 30 May 2025 14:05:12 +0000
Received: by outflank-mailman (input) for mailman id 1001225;
 Fri, 30 May 2025 14:05:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL0MB-00064k-Ho
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:05:11 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 1977ee42-3d5f-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 16:05:10 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C1E0E16F8;
 Fri, 30 May 2025 07:04:53 -0700 (PDT)
Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com
 [10.1.196.27])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3973B3F673;
 Fri, 30 May 2025 07:05: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" 
X-Inumbo-ID: 1977ee42-3d5f-11f0-a2ff-13f23c93f187
From: Ryan Roberts 
To: Catalin Marinas ,
	Will Deacon ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	"David S. Miller" ,
	Andreas Larsson ,
	Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Boris Ostrovsky ,
	"Aneesh Kumar K.V" ,
	Andrew Morton ,
	Peter Zijlstra ,
	Arnd Bergmann ,
	David Hildenbrand ,
	Lorenzo Stoakes ,
	"Liam R. Howlett" ,
	Vlastimil Babka ,
	Mike Rapoport ,
	Suren Baghdasaryan ,
	Michal Hocko ,
	Alexei Starovoitov ,
	Andrey Ryabinin 
Cc: Ryan Roberts ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	virtualization@lists.linux.dev,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org
Subject: [RFC PATCH v1 1/6] fs/proc/task_mmu: Fix pte update and tlb maintenance ordering in pagemap_scan_pmd_entry()
Date: Fri, 30 May 2025 15:04:39 +0100
Message-ID: <20250530140446.2387131-2-ryan.roberts@arm.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530140446.2387131-1-ryan.roberts@arm.com>
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

pagemap_scan_pmd_entry() was previously modifying ptes while in lazy mmu
mode, then performing tlb maintenance for the modified ptes, then
leaving lazy mmu mode. But any pte modifications during lazy mmu mode
may be deferred until arch_leave_lazy_mmu_mode(), inverting the required
ordering between pte modificaiton and tlb maintenance.

Let's fix that by leaving mmu mode, forcing all the pte updates to be
actioned, before doing the tlb maintenance.

This is a theorectical bug discovered during code review.

Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs")
Signed-off-by: Ryan Roberts 
---
 fs/proc/task_mmu.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 994cde10e3f4..361f3ffd9a0c 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -2557,10 +2557,9 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
 	}
 
 flush_and_return:
+	arch_leave_lazy_mmu_mode();
 	if (flush_end)
 		flush_tlb_range(vma, start, addr);
-
-	arch_leave_lazy_mmu_mode();
 	pte_unmap_unlock(start_pte, ptl);
 
 	cond_resched();
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 14:05:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:05:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001226.1381446 (Exim 4.92)
	(envelope-from )
	id 1uL0MI-0006ex-A2; Fri, 30 May 2025 14:05:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001226.1381446; Fri, 30 May 2025 14:05: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 1uL0MI-0006em-6m; Fri, 30 May 2025 14:05:18 +0000
Received: by outflank-mailman (input) for mailman id 1001226;
 Fri, 30 May 2025 14:05:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL0MG-00064k-QC
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:05:16 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 1c9df385-3d5f-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 16:05:16 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 23F3F2247;
 Fri, 30 May 2025 07:04:59 -0700 (PDT)
Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com
 [10.1.196.27])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8DD213F673;
 Fri, 30 May 2025 07:05: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" 
X-Inumbo-ID: 1c9df385-3d5f-11f0-a2ff-13f23c93f187
From: Ryan Roberts 
To: Catalin Marinas ,
	Will Deacon ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	"David S. Miller" ,
	Andreas Larsson ,
	Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Boris Ostrovsky ,
	"Aneesh Kumar K.V" ,
	Andrew Morton ,
	Peter Zijlstra ,
	Arnd Bergmann ,
	David Hildenbrand ,
	Lorenzo Stoakes ,
	"Liam R. Howlett" ,
	Vlastimil Babka ,
	Mike Rapoport ,
	Suren Baghdasaryan ,
	Michal Hocko ,
	Alexei Starovoitov ,
	Andrey Ryabinin 
Cc: Ryan Roberts ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	virtualization@lists.linux.dev,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org
Subject: [RFC PATCH v1 2/6] mm: Fix pte update and tlb maintenance ordering in migrate_vma_collect_pmd()
Date: Fri, 30 May 2025 15:04:40 +0100
Message-ID: <20250530140446.2387131-3-ryan.roberts@arm.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530140446.2387131-1-ryan.roberts@arm.com>
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

migrate_vma_collect_pmd() was previously modifying ptes while in lazy
mmu mode, then performing tlb maintenance for the modified ptes, then
leaving lazy mmu mode. But any pte modifications during lazy mmu mode
may be deferred until arch_leave_lazy_mmu_mode(), inverting the required
ordering between pte modificaiton and tlb maintenance.

Let's fix that by leaving mmu mode (forcing all the pte updates to be
actioned) before doing the tlb maintenance.

This is a theorectical bug discovered during code review.

Fixes: 60bae7370896 ("mm/migrate_device.c: flush TLB while holding PTL")
Signed-off-by: Ryan Roberts 
---
 mm/migrate_device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/migrate_device.c b/mm/migrate_device.c
index 3158afe7eb23..fc73a940c112 100644
--- a/mm/migrate_device.c
+++ b/mm/migrate_device.c
@@ -283,11 +283,12 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
 		migrate->src[migrate->npages++] = mpfn;
 	}
 
+	arch_leave_lazy_mmu_mode();
+
 	/* Only flush the TLB if we actually modified any entries */
 	if (unmapped)
 		flush_tlb_range(walk->vma, start, end);
 
-	arch_leave_lazy_mmu_mode();
 	pte_unmap_unlock(ptep - 1, ptl);
 
 	return 0;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 14:05:28 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:05:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001231.1381455 (Exim 4.92)
	(envelope-from )
	id 1uL0MS-00073x-HJ; Fri, 30 May 2025 14:05:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001231.1381455; Fri, 30 May 2025 14: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 1uL0MS-00073p-Ea; Fri, 30 May 2025 14:05:28 +0000
Received: by outflank-mailman (input) for mailman id 1001231;
 Fri, 30 May 2025 14:05:26 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL0MQ-0006to-NQ
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:05:26 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 1fcc3666-3d5f-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 16:05:21 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 777752681;
 Fri, 30 May 2025 07:05:04 -0700 (PDT)
Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com
 [10.1.196.27])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E2FA03F673;
 Fri, 30 May 2025 07: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" 
X-Inumbo-ID: 1fcc3666-3d5f-11f0-b894-0df219b8e170
From: Ryan Roberts 
To: Catalin Marinas ,
	Will Deacon ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	"David S. Miller" ,
	Andreas Larsson ,
	Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Boris Ostrovsky ,
	"Aneesh Kumar K.V" ,
	Andrew Morton ,
	Peter Zijlstra ,
	Arnd Bergmann ,
	David Hildenbrand ,
	Lorenzo Stoakes ,
	"Liam R. Howlett" ,
	Vlastimil Babka ,
	Mike Rapoport ,
	Suren Baghdasaryan ,
	Michal Hocko ,
	Alexei Starovoitov ,
	Andrey Ryabinin 
Cc: Ryan Roberts ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	virtualization@lists.linux.dev,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org
Subject: [RFC PATCH v1 3/6] mm: Avoid calling page allocator from apply_to_page_range()
Date: Fri, 30 May 2025 15:04:41 +0100
Message-ID: <20250530140446.2387131-4-ryan.roberts@arm.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530140446.2387131-1-ryan.roberts@arm.com>
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Lazy mmu mode applies to the current task and permits pte modifications
to be deferred and updated at a later time in a batch to improve
performance. apply_to_page_range() calls its callback in lazy mmu mode
and some of those callbacks call into the page allocator to either
allocate or free pages.

This is problematic with CONFIG_DEBUG_PAGEALLOC because
debug_pagealloc_[un]map_pages() calls the arch implementation of
__kernel_map_pages() which must modify the ptes for the linear map.

There are two possibilities at this point:

 - If the arch implementation modifies the ptes directly without first
   entering lazy mmu mode, the pte modifications may get deferred until
   the existing lazy mmu mode is exited. This could result in taking
   spurious faults for example.

 - If the arch implementation enters a nested lazy mmu mode before
   modification of the ptes (many arches use apply_to_page_range()),
   then the linear map updates will definitely be applied upon leaving
   the inner lazy mmu mode. But because lazy mmu mode does not support
   nesting, the remainder of the outer user is no longer in lazy mmu
   mode and the optimization opportunity is lost.

So let's just ensure that the page allocator is never called from within
lazy mmu mode. New "_nolazy" variants of apply_to_page_range() and
apply_to_existing_page_range() are introduced which don't enter lazy mmu
mode. Then users which need to call into the page allocator within their
callback are updated to use the _nolazy variants.

Signed-off-by: Ryan Roberts 
---
 include/linux/mm.h |  6 ++++++
 kernel/bpf/arena.c |  6 +++---
 mm/kasan/shadow.c  |  2 +-
 mm/memory.c        | 54 +++++++++++++++++++++++++++++++++++-----------
 4 files changed, 51 insertions(+), 17 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index e51dba8398f7..11cae6ce04ff 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -3743,9 +3743,15 @@ static inline bool gup_can_follow_protnone(struct vm_area_struct *vma,
 typedef int (*pte_fn_t)(pte_t *pte, unsigned long addr, void *data);
 extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
 			       unsigned long size, pte_fn_t fn, void *data);
+extern int apply_to_page_range_nolazy(struct mm_struct *mm,
+				      unsigned long address, unsigned long size,
+				      pte_fn_t fn, void *data);
 extern int apply_to_existing_page_range(struct mm_struct *mm,
 				   unsigned long address, unsigned long size,
 				   pte_fn_t fn, void *data);
+extern int apply_to_existing_page_range_nolazy(struct mm_struct *mm,
+				   unsigned long address, unsigned long size,
+				   pte_fn_t fn, void *data);
 
 #ifdef CONFIG_PAGE_POISONING
 extern void __kernel_poison_pages(struct page *page, int numpages);
diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
index 0d56cea71602..ca833cfeefb7 100644
--- a/kernel/bpf/arena.c
+++ b/kernel/bpf/arena.c
@@ -187,10 +187,10 @@ static void arena_map_free(struct bpf_map *map)
 	/*
 	 * free_vm_area() calls remove_vm_area() that calls free_unmap_vmap_area().
 	 * It unmaps everything from vmalloc area and clears pgtables.
-	 * Call apply_to_existing_page_range() first to find populated ptes and
-	 * free those pages.
+	 * Call apply_to_existing_page_range_nolazy() first to find populated
+	 * ptes and free those pages.
 	 */
-	apply_to_existing_page_range(&init_mm, bpf_arena_get_kern_vm_start(arena),
+	apply_to_existing_page_range_nolazy(&init_mm, bpf_arena_get_kern_vm_start(arena),
 				     KERN_VM_SZ - GUARD_SZ, existing_page_cb, NULL);
 	free_vm_area(arena->kern_vm);
 	range_tree_destroy(&arena->rt);
diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index d2c70cd2afb1..2325c5166c3a 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -590,7 +590,7 @@ void kasan_release_vmalloc(unsigned long start, unsigned long end,
 
 
 		if (flags & KASAN_VMALLOC_PAGE_RANGE)
-			apply_to_existing_page_range(&init_mm,
+			apply_to_existing_page_range_nolazy(&init_mm,
 					     (unsigned long)shadow_start,
 					     size, kasan_depopulate_vmalloc_pte,
 					     NULL);
diff --git a/mm/memory.c b/mm/memory.c
index 49199410805c..24436074ce48 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2913,7 +2913,7 @@ EXPORT_SYMBOL(vm_iomap_memory);
 static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 				     unsigned long addr, unsigned long end,
 				     pte_fn_t fn, void *data, bool create,
-				     pgtbl_mod_mask *mask)
+				     pgtbl_mod_mask *mask, bool lazy_mmu)
 {
 	pte_t *pte, *mapped_pte;
 	int err = 0;
@@ -2933,7 +2933,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 			return -EINVAL;
 	}
 
-	arch_enter_lazy_mmu_mode();
+	if (lazy_mmu)
+		arch_enter_lazy_mmu_mode();
 
 	if (fn) {
 		do {
@@ -2946,7 +2947,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 	}
 	*mask |= PGTBL_PTE_MODIFIED;
 
-	arch_leave_lazy_mmu_mode();
+	if (lazy_mmu)
+		arch_leave_lazy_mmu_mode();
 
 	if (mm != &init_mm)
 		pte_unmap_unlock(mapped_pte, ptl);
@@ -2956,7 +2958,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
 				     unsigned long addr, unsigned long end,
 				     pte_fn_t fn, void *data, bool create,
-				     pgtbl_mod_mask *mask)
+				     pgtbl_mod_mask *mask, bool lazy_mmu)
 {
 	pmd_t *pmd;
 	unsigned long next;
@@ -2983,7 +2985,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
 			pmd_clear_bad(pmd);
 		}
 		err = apply_to_pte_range(mm, pmd, addr, next,
-					 fn, data, create, mask);
+					 fn, data, create, mask, lazy_mmu);
 		if (err)
 			break;
 	} while (pmd++, addr = next, addr != end);
@@ -2994,7 +2996,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
 static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
 				     unsigned long addr, unsigned long end,
 				     pte_fn_t fn, void *data, bool create,
-				     pgtbl_mod_mask *mask)
+				     pgtbl_mod_mask *mask, bool lazy_mmu)
 {
 	pud_t *pud;
 	unsigned long next;
@@ -3019,7 +3021,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
 			pud_clear_bad(pud);
 		}
 		err = apply_to_pmd_range(mm, pud, addr, next,
-					 fn, data, create, mask);
+					 fn, data, create, mask, lazy_mmu);
 		if (err)
 			break;
 	} while (pud++, addr = next, addr != end);
@@ -3030,7 +3032,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
 static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd,
 				     unsigned long addr, unsigned long end,
 				     pte_fn_t fn, void *data, bool create,
-				     pgtbl_mod_mask *mask)
+				     pgtbl_mod_mask *mask, bool lazy_mmu)
 {
 	p4d_t *p4d;
 	unsigned long next;
@@ -3055,7 +3057,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd,
 			p4d_clear_bad(p4d);
 		}
 		err = apply_to_pud_range(mm, p4d, addr, next,
-					 fn, data, create, mask);
+					 fn, data, create, mask, lazy_mmu);
 		if (err)
 			break;
 	} while (p4d++, addr = next, addr != end);
@@ -3065,7 +3067,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd,
 
 static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr,
 				 unsigned long size, pte_fn_t fn,
-				 void *data, bool create)
+				 void *data, bool create, bool lazy_mmu)
 {
 	pgd_t *pgd;
 	unsigned long start = addr, next;
@@ -3091,7 +3093,7 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr,
 			pgd_clear_bad(pgd);
 		}
 		err = apply_to_p4d_range(mm, pgd, addr, next,
-					 fn, data, create, &mask);
+					 fn, data, create, &mask, lazy_mmu);
 		if (err)
 			break;
 	} while (pgd++, addr = next, addr != end);
@@ -3105,11 +3107,14 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr,
 /*
  * Scan a region of virtual memory, filling in page tables as necessary
  * and calling a provided function on each leaf page table.
+ *
+ * fn() is called in lazy mmu mode. As a result, the callback must be careful
+ * not to perform memory allocation.
  */
 int apply_to_page_range(struct mm_struct *mm, unsigned long addr,
 			unsigned long size, pte_fn_t fn, void *data)
 {
-	return __apply_to_page_range(mm, addr, size, fn, data, true);
+	return __apply_to_page_range(mm, addr, size, fn, data, true, true);
 }
 EXPORT_SYMBOL_GPL(apply_to_page_range);
 
@@ -3117,13 +3122,36 @@ EXPORT_SYMBOL_GPL(apply_to_page_range);
  * Scan a region of virtual memory, calling a provided function on
  * each leaf page table where it exists.
  *
+ * fn() is called in lazy mmu mode. As a result, the callback must be careful
+ * not to perform memory allocation.
+ *
  * Unlike apply_to_page_range, this does _not_ fill in page tables
  * where they are absent.
  */
 int apply_to_existing_page_range(struct mm_struct *mm, unsigned long addr,
 				 unsigned long size, pte_fn_t fn, void *data)
 {
-	return __apply_to_page_range(mm, addr, size, fn, data, false);
+	return __apply_to_page_range(mm, addr, size, fn, data, false, true);
+}
+
+/*
+ * As per apply_to_page_range() but fn() is not called in lazy mmu mode.
+ */
+int apply_to_page_range_nolazy(struct mm_struct *mm, unsigned long addr,
+			       unsigned long size, pte_fn_t fn, void *data)
+{
+	return __apply_to_page_range(mm, addr, size, fn, data, true, false);
+}
+
+/*
+ * As per apply_to_existing_page_range() but fn() is not called in lazy mmu
+ * mode.
+ */
+int apply_to_existing_page_range_nolazy(struct mm_struct *mm,
+					unsigned long addr, unsigned long size,
+					pte_fn_t fn, void *data)
+{
+	return __apply_to_page_range(mm, addr, size, fn, data, false, false);
 }
 
 /*
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 14:05:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:05:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001233.1381466 (Exim 4.92)
	(envelope-from )
	id 1uL0MT-0007KH-Pb; Fri, 30 May 2025 14:05:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001233.1381466; Fri, 30 May 2025 14:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL0MT-0007K6-M4; Fri, 30 May 2025 14:05:29 +0000
Received: by outflank-mailman (input) for mailman id 1001233;
 Fri, 30 May 2025 14:05:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL0MS-00064k-9M
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:05:28 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 22fc754e-3d5f-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 16:05:26 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CC0EB2682;
 Fri, 30 May 2025 07:05:09 -0700 (PDT)
Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com
 [10.1.196.27])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 42F963F673;
 Fri, 30 May 2025 07: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" 
X-Inumbo-ID: 22fc754e-3d5f-11f0-a2ff-13f23c93f187
From: Ryan Roberts 
To: Catalin Marinas ,
	Will Deacon ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	"David S. Miller" ,
	Andreas Larsson ,
	Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Boris Ostrovsky ,
	"Aneesh Kumar K.V" ,
	Andrew Morton ,
	Peter Zijlstra ,
	Arnd Bergmann ,
	David Hildenbrand ,
	Lorenzo Stoakes ,
	"Liam R. Howlett" ,
	Vlastimil Babka ,
	Mike Rapoport ,
	Suren Baghdasaryan ,
	Michal Hocko ,
	Alexei Starovoitov ,
	Andrey Ryabinin 
Cc: Ryan Roberts ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	virtualization@lists.linux.dev,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org
Subject: [RFC PATCH v1 4/6] mm: Introduce arch_in_lazy_mmu_mode()
Date: Fri, 30 May 2025 15:04:42 +0100
Message-ID: <20250530140446.2387131-5-ryan.roberts@arm.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530140446.2387131-1-ryan.roberts@arm.com>
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce new arch_in_lazy_mmu_mode() API, which returns true if the
calling context is currently in lazy mmu mode or false otherwise. Each
arch that supports lazy mmu mode must provide an implementation of this
API.

The API will shortly be used to prevent accidental lazy mmu mode nesting
when performing an allocation, and will additionally be used to ensure
pte modification vs tlb flushing order does not get inadvertantly
swapped.

Signed-off-by: Ryan Roberts 
---
 arch/arm64/include/asm/pgtable.h                  |  8 ++++++++
 .../powerpc/include/asm/book3s/64/tlbflush-hash.h | 15 +++++++++++++++
 arch/sparc/include/asm/tlbflush_64.h              |  1 +
 arch/sparc/mm/tlb.c                               | 12 ++++++++++++
 arch/x86/include/asm/paravirt.h                   |  5 +++++
 arch/x86/include/asm/paravirt_types.h             |  1 +
 arch/x86/kernel/paravirt.c                        |  6 ++++++
 arch/x86/xen/mmu_pv.c                             |  6 ++++++
 include/linux/pgtable.h                           |  1 +
 9 files changed, 55 insertions(+)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 5285757ee0c1..add75dee49f5 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -119,6 +119,14 @@ static inline void arch_leave_lazy_mmu_mode(void)
 	clear_thread_flag(TIF_LAZY_MMU);
 }
 
+static inline bool arch_in_lazy_mmu_mode(void)
+{
+	if (in_interrupt())
+		return false;
+
+	return test_thread_flag(TIF_LAZY_MMU);
+}
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 #define __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
 
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
index 146287d9580f..4123a9da32cc 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h
@@ -57,6 +57,21 @@ static inline void arch_leave_lazy_mmu_mode(void)
 
 #define arch_flush_lazy_mmu_mode()      do {} while (0)
 
+static inline bool arch_in_lazy_mmu_mode(void)
+{
+	struct ppc64_tlb_batch *batch;
+	bool active;
+
+	if (radix_enabled())
+		return false;
+
+	batch = get_cpu_ptr(&ppc64_tlb_batch);
+	active = batch->active;
+	put_cpu_ptr(&ppc64_tlb_batch);
+
+	return active;
+}
+
 extern void hash__tlbiel_all(unsigned int action);
 
 extern void flush_hash_page(unsigned long vpn, real_pte_t pte, int psize,
diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h
index 8b8cdaa69272..204bc957df9e 100644
--- a/arch/sparc/include/asm/tlbflush_64.h
+++ b/arch/sparc/include/asm/tlbflush_64.h
@@ -45,6 +45,7 @@ void flush_tlb_pending(void);
 void arch_enter_lazy_mmu_mode(void);
 void arch_leave_lazy_mmu_mode(void);
 #define arch_flush_lazy_mmu_mode()      do {} while (0)
+bool arch_in_lazy_mmu_mode(void);
 
 /* Local cpu only.  */
 void __flush_tlb_all(void);
diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c
index a35ddcca5e76..83ab4ba4f4fb 100644
--- a/arch/sparc/mm/tlb.c
+++ b/arch/sparc/mm/tlb.c
@@ -69,6 +69,18 @@ void arch_leave_lazy_mmu_mode(void)
 	preempt_enable();
 }
 
+bool arch_in_lazy_mmu_mode(void)
+{
+	struct tlb_batch *tb;
+	bool active;
+
+	tb = get_cpu_ptr(&tlb_batch);
+	active = tb->active;
+	put_cpu_ptr(&tlb_batch);
+
+	return active;
+}
+
 static void tlb_batch_add_one(struct mm_struct *mm, unsigned long vaddr,
 			      bool exec, unsigned int hugepage_shift)
 {
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index b5e59a7ba0d0..c7ea3ccb8a41 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -542,6 +542,11 @@ static inline void arch_flush_lazy_mmu_mode(void)
 	PVOP_VCALL0(mmu.lazy_mode.flush);
 }
 
+static inline bool arch_in_lazy_mmu_mode(void)
+{
+	return PVOP_CALL0(bool, mmu.lazy_mode.in);
+}
+
 static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
 				phys_addr_t phys, pgprot_t flags)
 {
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 37a8627d8277..41001ca9d010 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -46,6 +46,7 @@ struct pv_lazy_ops {
 	void (*enter)(void);
 	void (*leave)(void);
 	void (*flush)(void);
+	bool (*in)(void);
 } __no_randomize_layout;
 #endif
 
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index ab3e172dcc69..9af1a04a47fd 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -106,6 +106,11 @@ static noinstr void pv_native_set_debugreg(int regno, unsigned long val)
 {
 	native_set_debugreg(regno, val);
 }
+
+static noinstr bool paravirt_retfalse(void)
+{
+	return false;
+}
 #endif
 
 struct pv_info pv_info = {
@@ -228,6 +233,7 @@ struct paravirt_patch_template pv_ops = {
 		.enter		= paravirt_nop,
 		.leave		= paravirt_nop,
 		.flush		= paravirt_nop,
+		.in		= paravirt_retfalse,
 	},
 
 	.mmu.set_fixmap		= native_set_fixmap,
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 2a4a8deaf612..74f7a8537911 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2147,6 +2147,11 @@ static void xen_flush_lazy_mmu(void)
 	preempt_enable();
 }
 
+static bool xen_in_lazy_mmu(void)
+{
+	return xen_get_lazy_mode() == XEN_LAZY_MMU;
+}
+
 static void __init xen_post_allocator_init(void)
 {
 	pv_ops.mmu.set_pte = xen_set_pte;
@@ -2230,6 +2235,7 @@ static const typeof(pv_ops) xen_mmu_ops __initconst = {
 			.enter = xen_enter_lazy_mmu,
 			.leave = xen_leave_lazy_mmu,
 			.flush = xen_flush_lazy_mmu,
+			.in = xen_in_lazy_mmu,
 		},
 
 		.set_fixmap = xen_set_fixmap,
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index b50447ef1c92..580d9971f435 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -235,6 +235,7 @@ static inline int pmd_dirty(pmd_t pmd)
 #define arch_enter_lazy_mmu_mode()	do {} while (0)
 #define arch_leave_lazy_mmu_mode()	do {} while (0)
 #define arch_flush_lazy_mmu_mode()	do {} while (0)
+#define arch_in_lazy_mmu_mode()		false
 #endif
 
 #ifndef pte_batch_hint
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 14:05:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:05:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001238.1381476 (Exim 4.92)
	(envelope-from )
	id 1uL0MZ-0007rj-29; Fri, 30 May 2025 14:05:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001238.1381476; Fri, 30 May 2025 14: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 1uL0MY-0007rV-Vo; Fri, 30 May 2025 14:05:34 +0000
Received: by outflank-mailman (input) for mailman id 1001238;
 Fri, 30 May 2025 14:05:33 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL0MX-00064k-On
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:05:33 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 262c5a86-3d5f-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 16:05:32 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2A52826A4;
 Fri, 30 May 2025 07:05:15 -0700 (PDT)
Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com
 [10.1.196.27])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9729C3F673;
 Fri, 30 May 2025 07:05: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" 
X-Inumbo-ID: 262c5a86-3d5f-11f0-a2ff-13f23c93f187
From: Ryan Roberts 
To: Catalin Marinas ,
	Will Deacon ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	"David S. Miller" ,
	Andreas Larsson ,
	Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Boris Ostrovsky ,
	"Aneesh Kumar K.V" ,
	Andrew Morton ,
	Peter Zijlstra ,
	Arnd Bergmann ,
	David Hildenbrand ,
	Lorenzo Stoakes ,
	"Liam R. Howlett" ,
	Vlastimil Babka ,
	Mike Rapoport ,
	Suren Baghdasaryan ,
	Michal Hocko ,
	Alexei Starovoitov ,
	Andrey Ryabinin 
Cc: Ryan Roberts ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	virtualization@lists.linux.dev,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org
Subject: [RFC PATCH v1 5/6] mm: Avoid calling page allocator while in lazy mmu mode
Date: Fri, 30 May 2025 15:04:43 +0100
Message-ID: <20250530140446.2387131-6-ryan.roberts@arm.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530140446.2387131-1-ryan.roberts@arm.com>
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Lazy mmu mode applies to the current task and permits pte modifications
to be deferred and updated at a later time in a batch to improve
performance. tlb_next_batch() is called in lazy mmu mode as follows:

zap_pte_range
  arch_enter_lazy_mmu_mode
  do_zap_pte_range
    zap_present_ptes
      zap_present_folio_ptes
        __tlb_remove_folio_pages
          __tlb_remove_folio_pages_size
            tlb_next_batch
  arch_leave_lazy_mmu_mode

tlb_next_batch() may call into the page allocator which is problematic
with CONFIG_DEBUG_PAGEALLOC because debug_pagealloc_[un]map_pages()
calls the arch implementation of __kernel_map_pages() which must modify
the ptes for the linear map.

There are two possibilities at this point:

- If the arch implementation modifies the ptes directly without first
  entering lazy mmu mode, the pte modifications may get deferred until
  the existing lazy mmu mode is exited. This could result in taking
  spurious faults for example.

- If the arch implementation enters a nested lazy mmu mode before
  modification of the ptes (many arches use apply_to_page_range()),
  then the linear map updates will definitely be applied upon leaving
  the inner lazy mmu mode. But because lazy mmu mode does not support
  nesting, the remainder of the outer user is no longer in lazy mmu
  mode and the optimization opportunity is lost.

So let's just ensure that the page allocator is never called from within
lazy mmu mode. Use the new arch_in_lazy_mmu_mode() API to check if we
are in lazy mmu mode, and if so, when calling into the page allocator,
temporarily leave lazy mmu mode.

Given this new API we can also add VM_WARNings to check that we exit
lazy mmu mode when required to ensure the PTEs are actually updated
prior to tlb flushing.

Signed-off-by: Ryan Roberts 
---
 include/asm-generic/tlb.h |  2 ++
 mm/mmu_gather.c           | 15 +++++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 88a42973fa47..84fb269b78a5 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -469,6 +469,8 @@ tlb_update_vma_flags(struct mmu_gather *tlb, struct vm_area_struct *vma)
 
 static inline void tlb_flush_mmu_tlbonly(struct mmu_gather *tlb)
 {
+	VM_WARN_ON(arch_in_lazy_mmu_mode());
+
 	/*
 	 * Anything calling __tlb_adjust_range() also sets at least one of
 	 * these bits.
diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c
index db7ba4a725d6..0bd1e69b048b 100644
--- a/mm/mmu_gather.c
+++ b/mm/mmu_gather.c
@@ -18,6 +18,7 @@
 static bool tlb_next_batch(struct mmu_gather *tlb)
 {
 	struct mmu_gather_batch *batch;
+	bool lazy_mmu;
 
 	/* Limit batching if we have delayed rmaps pending */
 	if (tlb->delayed_rmap && tlb->active != &tlb->local)
@@ -32,7 +33,15 @@ static bool tlb_next_batch(struct mmu_gather *tlb)
 	if (tlb->batch_count == MAX_GATHER_BATCH_COUNT)
 		return false;
 
+	lazy_mmu = arch_in_lazy_mmu_mode();
+	if (lazy_mmu)
+		arch_leave_lazy_mmu_mode();
+
 	batch = (void *)__get_free_page(GFP_NOWAIT | __GFP_NOWARN);
+
+	if (lazy_mmu)
+		arch_enter_lazy_mmu_mode();
+
 	if (!batch)
 		return false;
 
@@ -145,6 +154,8 @@ static void tlb_batch_pages_flush(struct mmu_gather *tlb)
 {
 	struct mmu_gather_batch *batch;
 
+	VM_WARN_ON(arch_in_lazy_mmu_mode());
+
 	for (batch = &tlb->local; batch && batch->nr; batch = batch->next)
 		__tlb_batch_free_encoded_pages(batch);
 	tlb->active = &tlb->local;
@@ -154,6 +165,8 @@ static void tlb_batch_list_free(struct mmu_gather *tlb)
 {
 	struct mmu_gather_batch *batch, *next;
 
+	VM_WARN_ON(arch_in_lazy_mmu_mode());
+
 	for (batch = tlb->local.next; batch; batch = next) {
 		next = batch->next;
 		free_pages((unsigned long)batch, 0);
@@ -363,6 +376,8 @@ void tlb_remove_table(struct mmu_gather *tlb, void *table)
 {
 	struct mmu_table_batch **batch = &tlb->batch;
 
+	VM_WARN_ON(arch_in_lazy_mmu_mode());
+
 	if (*batch == NULL) {
 		*batch = (struct mmu_table_batch *)__get_free_page(GFP_NOWAIT | __GFP_NOWARN);
 		if (*batch == NULL) {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 14:11:29 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:11:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001273.1381486 (Exim 4.92)
	(envelope-from )
	id 1uL0SD-0003Pi-QM; Fri, 30 May 2025 14:11:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001273.1381486; Fri, 30 May 2025 14: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 1uL0SD-0003Pb-Mg; Fri, 30 May 2025 14:11:25 +0000
Received: by outflank-mailman (input) for mailman id 1001273;
 Fri, 30 May 2025 14:11:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL0Mc-00064k-8u
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:05:38 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 295b445d-3d5f-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 16:05:37 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8076E26AC;
 Fri, 30 May 2025 07:05:20 -0700 (PDT)
Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com
 [10.1.196.27])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EAB693F673;
 Fri, 30 May 2025 07:05: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" 
X-Inumbo-ID: 295b445d-3d5f-11f0-a2ff-13f23c93f187
From: Ryan Roberts 
To: Catalin Marinas ,
	Will Deacon ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	"David S. Miller" ,
	Andreas Larsson ,
	Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Boris Ostrovsky ,
	"Aneesh Kumar K.V" ,
	Andrew Morton ,
	Peter Zijlstra ,
	Arnd Bergmann ,
	David Hildenbrand ,
	Lorenzo Stoakes ,
	"Liam R. Howlett" ,
	Vlastimil Babka ,
	Mike Rapoport ,
	Suren Baghdasaryan ,
	Michal Hocko ,
	Alexei Starovoitov ,
	Andrey Ryabinin 
Cc: Ryan Roberts ,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	sparclinux@vger.kernel.org,
	virtualization@lists.linux.dev,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org
Subject: [RFC PATCH v1 6/6] Revert "arm64/mm: Permit lazy_mmu_mode to be nested"
Date: Fri, 30 May 2025 15:04:44 +0100
Message-ID: <20250530140446.2387131-7-ryan.roberts@arm.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20250530140446.2387131-1-ryan.roberts@arm.com>
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Commit 491344301b25 ("arm64/mm: Permit lazy_mmu_mode to be nested") made
the arm64 implementation of lazy_mmu_mode tolerant to nesting. But
subsequent commits have fixed the core code to ensure that lazy_mmu_mode
never gets nested (as originally intended). Therefore we can revert this
commit and reinstate the VM_WARN() if nesting is detected in future.

Signed-off-by: Ryan Roberts 
---
 arch/arm64/include/asm/pgtable.h | 14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index add75dee49f5..dcf0adbeb803 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -83,21 +83,11 @@ static inline void queue_pte_barriers(void)
 #define  __HAVE_ARCH_ENTER_LAZY_MMU_MODE
 static inline void arch_enter_lazy_mmu_mode(void)
 {
-	/*
-	 * lazy_mmu_mode is not supposed to permit nesting. But in practice this
-	 * does happen with CONFIG_DEBUG_PAGEALLOC, where a page allocation
-	 * inside a lazy_mmu_mode section (such as zap_pte_range()) will change
-	 * permissions on the linear map with apply_to_page_range(), which
-	 * re-enters lazy_mmu_mode. So we tolerate nesting in our
-	 * implementation. The first call to arch_leave_lazy_mmu_mode() will
-	 * flush and clear the flag such that the remainder of the work in the
-	 * outer nest behaves as if outside of lazy mmu mode. This is safe and
-	 * keeps tracking simple.
-	 */
-
 	if (in_interrupt())
 		return;
 
+	VM_WARN_ON(test_thread_flag(TIF_LAZY_MMU));
+
 	set_thread_flag(TIF_LAZY_MMU);
 }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri May 30 14:18:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:18:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001306.1381496 (Exim 4.92)
	(envelope-from )
	id 1uL0Ye-0005VQ-Do; Fri, 30 May 2025 14:18:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001306.1381496; Fri, 30 May 2025 14: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 1uL0Ye-0005VJ-BC; Fri, 30 May 2025 14:18:04 +0000
Received: by outflank-mailman (input) for mailman id 1001306;
 Fri, 30 May 2025 14:18:03 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL0Yd-0005VB-6L
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:18:03 +0000
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [2a00:1450:4864:20::32f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e5460a4b-3d60-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 16:18:02 +0200 (CEST)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-442fda876a6so17649285e9.0
 for ; Fri, 30 May 2025 07:18:02 -0700 (PDT)
Received: from [10.81.43.171] ([46.149.103.14])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a4f00a13fasm4944454f8f.98.2025.05.30.07.18.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 30 May 2025 07:18: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" 
X-Inumbo-ID: e5460a4b-3d60-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748614682; x=1749219482; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=boSpWoghs7SIdMQQNzZ87YDtcYUbCEVl0bHQdthmwck=;
        b=lrI8mvRVzQIZF3pY6zQT0BxMp3hond0IaOo+8dn8Ls/ixAJK0qhPYRrxxVnUM23lTP
         wzpWxKz3XFmIP+QlO9DIAo/n12aRHhEdS8TBMyO/wS3vlQkWksjWXwMnP5hA90mPqcqu
         7s0eKu9NIY+YsXfVDNCUFmC9IlyLTTak/pMlw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748614682; x=1749219482;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=boSpWoghs7SIdMQQNzZ87YDtcYUbCEVl0bHQdthmwck=;
        b=TiHX2wMI5/cbjLzRn25wZwl5DCjRPSPo6eUf2agd43eFbfLvcKr9gwW4Lm8fT4lPtK
         OsofDJFC26Rmz3a41GNweEPDwOCAzKUhKnsW/ziX0zD1QGxJ4xfDHMSJyEhneMkYitB1
         040GS5q6Wwtw5nXXj2P3KmgbTUef/V1PFTLXjN1Lb+S7FPPJc6U9undKh5xRzREP30gA
         pYzjaEDomp+FlzQECG/gYRxpdPJ3ql6oqSk8op/A7uDTeIksFVTzRoCf7NwhWkJ1x7oI
         YsIwxkaYL8paGWNLWbRLEIm7quhc8dlxoiwC0IRp/6/AL0bP8QVa0iWnrCcBf7+oYTJs
         s0VA==
X-Forwarded-Encrypted: i=1; AJvYcCVa4nSJR+/3TnKpgmYH1GQYg633dGb9YPjMYVTQLrUwjSZTA6FnbJ5g2eidEa+PN6f84maow4fFX9Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy0TyCxbkGK/lnePqKRXYZyyqxvmmMjmcbovWSGH3Odgsj1jqMA
	CJ7HHlmXubILfnmD/vsaOdqarpQHCigecRRIhAgx6paxRk1wbE86FZ815wnf5mSmVyE=
X-Gm-Gg: ASbGnctaSs+zsxNzzeTEYjUW7Y/i8Zak3X9H95zi5sYOutw5TIrvY5A/w8CC2dACNB8
	l8dvYxqM29jUp1X+A6tVZaWpqap+1/R+mSexkSemq1qS8AsG1jNAhG05Xzri4P57RAcA9QXJ2/U
	uLJyjbAGpqQQVkXlF97VfHbkgI9M/aKpEopNDuqOTRZjVKylfR30+FFWZpjrTPc+8QzCHOOh3Gl
	bg/DFkLb1fPx8aaVwIz8HMIW8YTqjG8dGI/91fypKO9FUk/Xsr6Gb+zxFqOipXbqKr+yi3stpV8
	I5Li56u2jsZdtC3xYfhn/HBLsTPd80Z5QfJrQyMVUc7j99FQ9wwmt3FEwtw7qg==
X-Google-Smtp-Source: AGHT+IHoDU4ef8LJNXOnC2LlSlPol9YfSgER98Baxq4tUSqzupxGj9MuqW2iobidjRxf/N9tQW2K/w==
X-Received: by 2002:a05:600c:1e06:b0:43d:aed:f7d0 with SMTP id 5b1f17b1804b1-450d655ffb7mr23737555e9.28.1748614681586;
        Fri, 30 May 2025 07:18:01 -0700 (PDT)
Message-ID: 
Date: Fri, 30 May 2025 15:18:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools: Add install/uninstall targets to
 tests/x86_emulator
To: Jan Beulich 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Anthony PERARD , Michal Orzel
 , Julien Grall ,
 Stefano Stabellini ,
 Xen-devel 
References: <20240516110710.3446-1-alejandro.vallejo@cloud.com>
 <724b77b5-3b78-436e-bd20-726c34bef03b@citrix.com>
 <847c263c-1fe1-4a68-9962-8d998a3c272d@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: <847c263c-1fe1-4a68-9962-8d998a3c272d@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21/05/2025 8:06 am, Jan Beulich wrote:
> On 20.05.2025 23:02, Andrew Cooper wrote:
>> On 16/05/2024 12:07 pm, Alejandro Vallejo wrote:
>>> Bring test_x86_emulator in line with other tests by adding
>>> install/uninstall rules.
>>>
>>> Signed-off-by: Alejandro Vallejo 
>>> ---
>>>  tools/tests/x86_emulator/Makefile | 11 +++++++++--
>>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile
>>> index 834b2112e7fe..30edf7e0185d 100644
>>> --- a/tools/tests/x86_emulator/Makefile
>>> +++ b/tools/tests/x86_emulator/Makefile
>>> @@ -269,8 +269,15 @@ clean:
>>>  .PHONY: distclean
>>>  distclean: clean
>>>  
>>> -.PHONY: install uninstall
>>> -install uninstall:
>>> +.PHONY: install
>>> +install: all
>>> +	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
>>> +	$(if $(TARGET-y),$(INSTALL_PROG) $(TARGET-y) $(DESTDIR)$(LIBEXEC_BIN))
>>> +
>>> +.PHONY: uninstall
>>> +uninstall:
>>> +	$(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/,$(TARGET-y))
>>> +
>>>  
>>>  .PHONY: run32 clean32
>>>  ifeq ($(XEN_COMPILE_ARCH),x86_64)
>> [starting a clean thread]
>>
>> x86_emulator is not special enough to behave differently to the rest of
>> tools/.
>>
>> Theoretical concerns over cross compiling test_x86_emulator for non-x86
>> can be fixed by whomever first wants to do this.
>>
>> The very real problem is that this doesn't run in x86 CI, because and
>> only because it doesn't have an install target.
> Well, I won't insist on any of the adjustments to be made that previously
> were discussed, yet I wonder: Elsewhere you complain (at times loudly)
> about (building up) technical debt.

Yes I do complain about technical debt a lot.

Technical debt is having a test and not running it.

>
> Further, without the compiler overridden to be the absolutely newest one
> available, coverage of such testing would be limited (especially if some
> of my work there would finally, in part after years, be unblocked). Yes,
> that's better than nothing, but still ...

Still what?  We literally have nothing, and this gets us something,
without interfering with anyone's pre-existing workflow.

Alpine Linux (the base of our GitlabCI testing) is prompt at keeping
it's GCC up to date.  (We're less prompt at staying on up-to-date
versions of Alpine, but that's on the todo list.)

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 30 14:20:54 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:20:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001317.1381506 (Exim 4.92)
	(envelope-from )
	id 1uL0bG-00078p-SF; Fri, 30 May 2025 14:20:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001317.1381506; Fri, 30 May 2025 14:20:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL0bG-00078i-Og; Fri, 30 May 2025 14:20:46 +0000
Received: by outflank-mailman (input) for mailman id 1001317;
 Fri, 30 May 2025 14:20:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL0bF-00076t-Pk
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:20:45 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 459e54d0-3d61-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 16:20:43 +0200 (CEST)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-ad8a8da2376so341731466b.3
 for ; Fri, 30 May 2025 07:20:43 -0700 (PDT)
Received: from [192.168.1.5] (user-109-243-64-38.play-internet.pl.
 [109.243.64.38]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ada5d84f9e0sm333813066b.85.2025.05.30.07.20.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 30 May 2025 07:20: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" 
X-Inumbo-ID: 459e54d0-3d61-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748614843; x=1749219643; darn=lists.xenproject.org;
        h=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;
        bh=uq4O2cXXlau/9IvM04wGVOB3qhjvpwF9KoVzci7dJDQ=;
        b=K+qdQD/nIWgA4eg8hmhNz0pQ005whmRG8XC+y2GWsogqsROe4bbqZ9DkK45Afm1/7J
         Cm418GL2DrIDg3GImn/Pl8/++0NRN23+6q5RFFNeR2n4jiIhf/xsc+MLg0yr8hZS3+kS
         vC3nVf8P6gONZWl/PC/+2XUkyqRVkeX3FQ4swkUYLVjz4cMOq/IpMTEM4UXa/aJePAKW
         3uesh6D1zenRFYdvwL8H+Vo4GqrMhc5OTwy4+Y5Sbd5vh+RMkhRz3M11LDnqM3oFBfIM
         NzmsZStaNgmZ+B2eA6y16sLFkHg2U/zfXy3tkgRuXtCzn2FJitCxz+9ZIZGiNL1Dgtgl
         gqPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748614843; x=1749219643;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=uq4O2cXXlau/9IvM04wGVOB3qhjvpwF9KoVzci7dJDQ=;
        b=eWIobekRZZHvP8U7nMZzRzX/ItaXpyYiYvO669ZMWbuVGQcIRpOJfnXS0ZMUBf5lOC
         IxboM3xAIkKHsx1kwmB4M/uxm4oXxy+q2jLB1xDJyE2Y2L77Cq0MMAIhAwN88WIlIibd
         YJGA1Rc2xkuPTOzi9ST6/xwteZY4Zj6STWSRVW926xkRfa9XtxLb/FJux7QwbSQi6iIM
         THHZHHTyM1J7pKh7elT+D4/lZYDXgeN5DZVslj/WEJDqsMTNQ1YDYq+gGEvwykaS1fMw
         2y/pPAVXC2Uqwo5A4co3dt1n4Es439pB7wkEt/+kqqmepwphwZ5b5yq3coSGc48uiND/
         /ZzA==
X-Forwarded-Encrypted: i=1; AJvYcCWhTozxFIhREj1R4AsDWiEqcw01npjRQElrFqB/NUKbEtDoRgM1+/uqovzCOOmW1nCVcviDCUjPbjc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwXDv4sry5xl1/N8GNpHK2wtWAfafzR2EnYc6B8hVtWmrBs0BMV
	dBDcWRTNcppDr7Y4FMRsvT6EHHSz+4R21piIGQsPMKngvRSrGLoxiHE7
X-Gm-Gg: ASbGncsx+N6go3FACYWfeJ4xzDaWCUklQ20sMWvAP+zVOY50IoF1INg73GYKiIZbkiR
	J3XLP80gGuxucPDP6Oc+l1Y0y5NG26gEujZ4PF+euPy2Cs6BacJj+//lyQDw+HOvTPWyNR7ZJ4N
	IFAkfgI/RhIYvM+L8zM+ty2+eA5ziXz2kCDiGx5QoQOnFfcM4SJtQ7vQNG5IBH0lofkcuYkM0UI
	W6TwJANMBnGbXrwdnCRKz5U47kXr/cvjBDBfox2XOsBw3XqEh1uENzyrxC5+iKUv/L7/UssgSfW
	q+qajz4h8PTrmhpF7YoKN9W/TfqkTHHvM2Nk036dVtlqh1RPc9MzELW+LarFLPaqEKB/H4m5DkH
	I5v00fnJjli0FUoHbRd0saZdV
X-Google-Smtp-Source: AGHT+IHp37/96/rFElV9XhGd7RdgorZr5kNAu/swdIYl5txI+Q+kKvbWyj/IxrtGNKH97CXN8THW2A==
X-Received: by 2002:a17:907:7285:b0:ad8:9c97:c2fa with SMTP id a640c23a62f3a-adb322455e1mr359983566b.4.1748614842921;
        Fri, 30 May 2025 07:20:42 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------JDxgvwVDw84ZwRGJfq1LHB0J"
Message-ID: <7ba71c82-1143-4793-afae-8ac3a8d0320b@gmail.com>
Date: Fri, 30 May 2025 16:20:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/14] xen/riscv: introduce support of Svpbmt extension
 and make it mandatory
To: Jan Beulich 
Cc: Doug Goldstein ,
 Stefano Stabellini ,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , xen-devel@lists.xenproject.org
References: 
 
 <3eaba65b-5b36-433c-afbc-ed17886916a9@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <3eaba65b-5b36-433c-afbc-ed17886916a9@suse.com>

This is a multi-part message in MIME format.
--------------JDxgvwVDw84ZwRGJfq1LHB0J
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 5/22/25 9:26 AM, Jan Beulich wrote:
> On 21.05.2025 18:03, Oleksii Kurochko wrote:
>> Svpbmt extension is necessary for chaning the memory type for a page contains
>> a combination of attributes that indicate the cacheability, idempotency,
>> and ordering properties for access to that page.
>>
>> As a part of the patch the following is introduced:
>> - Svpbmt memory type defintions: PTE_PBMT_{NOCACHE,IO}.
>> - PAGE_HYPERVISOR_{NOCACHE,WC}.
>> - RISCV_ISA_EXT_svpbmt and add a check in runtime that Svpbmt is
>>    supported by platform.
>> - Update riscv/booting.txt with information about Svpbmt.
>> - Update logic of pt_update_entry() to take into account PBMT bits.
>>
>> Use 'unsigned long' for pte_attr_t as PMBT bits are 61 and 62 and it doesn't
>> fit into 'unsigned int'. Also, update function prototypes which uses
>> 'unsigned int' for flags/attibutes.
>>
>> Enable Svpbmt for testing in QEMU as Svpmbt is now mandatory for
>> Xen work.
>>
>> Signed-off-by: Oleksii Kurochko
> Acked-by: Jan Beulich
>
Thanks.

I just noticed a minor typo (PMBT_{IO,NOCACHE}->PMBT_{IO,NOCACHE} in the changes:

xen$ git diff
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 81b91b63d8..4cb0179648 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -45,8 +45,8 @@
   *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
   *  11 - Rsvd   Reserved for future standard use
   */
-#define PTE_PMBT_NOCACHE            BIT(61, UL)
-#define PTE_PMBT_IO                 BIT(62, UL)
+#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)
@@ -59,12 +59,12 @@
  /*
   * PAGE_HYPERVISOR_NOCACHE is used for ioremap().
   *
- * Both PTE_PMBT_IO and PTE_PMBT_NOCACHE are non-cacheable, but the difference
+ * Both PTE_PBMT_IO and PTE_PBMT_NOCACHE are non-cacheable, but the difference
   * is that IO is non-idempotent and strongly ordered, which makes it a good
   * candidate for mapping IOMEM.
   */
-#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PMBT_IO)
-#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PMBT_NOCACHE)
+#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PBMT_IO)
+#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PBMT_NOCACHE)
  
  /*
   * The PTE format does not contain the following bits within itself;
@@ -77,7 +77,7 @@
  
  #define PTE_ACCESS_MASK (PTE_READABLE | PTE_WRITABLE | PTE_EXECUTABLE)
  
-#define PTE_PBMT_MASK   (PTE_PMBT_NOCACHE | PTE_PMBT_IO)
+#define PTE_PBMT_MASK   (PTE_PBMT_NOCACHE | PTE_PBMT_IO)
  
  /* Calculate the offsets into the pagetables for a given VA */
  #define pt_linear_offset(lvl, va)   ((va) >> XEN_PT_LEVEL_SHIFT(lvl))

I will send them as a part of v4. (if it can't
be done during commit)

~ Oleksii

--------------JDxgvwVDw84ZwRGJfq1LHB0J
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    

    
    
    
    
    On 5/22/25 9:26 AM, Jan Beulich wrote:
    
    
    
    
    
      
    On 21.05.2025 18:03, Oleksii Kurochko wrote:

    
      
    
        
    Svpbmt extension is necessary for chaning the memory type for a page contains
a combination of attributes that indicate the cacheability, idempotency,
and ordering properties for access to that page.

As a part of the patch the following is introduced:
- Svpbmt memory type defintions: PTE_PBMT_{NOCACHE,IO}.
- PAGE_HYPERVISOR_{NOCACHE,WC}.
- RISCV_ISA_EXT_svpbmt and add a check in runtime that Svpbmt is
  supported by platform.
- Update riscv/booting.txt with information about Svpbmt.
- Update logic of pt_update_entry() to take into account PBMT bits.

Use 'unsigned long' for pte_attr_t as PMBT bits are 61 and 62 and it doesn't
fit into 'unsigned int'. Also, update function prototypes which uses
'unsigned int' for flags/attibutes.

Enable Svpbmt for testing in QEMU as Svpmbt is now mandatory for
Xen work.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

    
      
    
      
    Acked-by: Jan Beulich <jbeulich@suse.com>


    
    
    
    
    Thanks.

I just noticed a minor typo (PMBT_{IO,NOCACHE}->PMBT_{IO,NOCACHE} in the changes:

xen$ git diff
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 81b91b63d8..4cb0179648 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -45,8 +45,8 @@
  *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
  *  11 - Rsvd   Reserved for future standard use
  */
-#define PTE_PMBT_NOCACHE            BIT(61, UL)
-#define PTE_PMBT_IO                 BIT(62, UL)
+#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)
@@ -59,12 +59,12 @@
 /*
  * PAGE_HYPERVISOR_NOCACHE is used for ioremap().
  *
- * Both PTE_PMBT_IO and PTE_PMBT_NOCACHE are non-cacheable, but the difference
+ * Both PTE_PBMT_IO and PTE_PBMT_NOCACHE are non-cacheable, but the difference
  * is that IO is non-idempotent and strongly ordered, which makes it a good
  * candidate for mapping IOMEM.
  */
-#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PMBT_IO)
-#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PMBT_NOCACHE)
+#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PBMT_IO)
+#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PBMT_NOCACHE)
 
 /*
  * The PTE format does not contain the following bits within itself;
@@ -77,7 +77,7 @@
 
 #define PTE_ACCESS_MASK (PTE_READABLE | PTE_WRITABLE | PTE_EXECUTABLE)
 
-#define PTE_PBMT_MASK   (PTE_PMBT_NOCACHE | PTE_PMBT_IO)
+#define PTE_PBMT_MASK   (PTE_PBMT_NOCACHE | PTE_PBMT_IO)
 
 /* Calculate the offsets into the pagetables for a given VA */
 #define pt_linear_offset(lvl, va)   ((va) >> XEN_PT_LEVEL_SHIFT(lvl))

I will send them as a part of v4. (if it can't
be done during commit)

~ Oleksii

    
  


--------------JDxgvwVDw84ZwRGJfq1LHB0J--


From xen-devel-bounces@lists.xenproject.org Fri May 30 14:37:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:37:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001330.1381516 (Exim 4.92)
	(envelope-from )
	id 1uL0ri-0003RS-5h; Fri, 30 May 2025 14:37:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001330.1381516; Fri, 30 May 2025 14:37: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 1uL0ri-0003RL-2X; Fri, 30 May 2025 14:37:46 +0000
Received: by outflank-mailman (input) for mailman id 1001330;
 Fri, 30 May 2025 14:37:44 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL0rg-0003RE-KM
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:37:44 +0000
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com
 [2a00:1450:4864:20::431])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a54ea5ea-3d63-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 16:37:43 +0200 (CEST)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3a363d15c64so1419021f8f.3
 for ; Fri, 30 May 2025 07:37:43 -0700 (PDT)
Received: from [10.81.43.171] ([46.149.103.15])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-450d800671csm19708385e9.30.2025.05.30.07.37.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 30 May 2025 07:37: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" 
X-Inumbo-ID: a54ea5ea-3d63-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1748615863; x=1749220663; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=4NVacMHC7XtpveJzs3ER6JEJKeVbCO25yrq7om+VxTQ=;
        b=rxx+6ncHIRcIw5fOjbFvLkG6odOFhq2eSpa5EI3mtFN8eGZ9V3IVNkg2gLaa/qGuSd
         9o7zUYB35OtOHA4PEIKwiMy0LH3anLkxncd6k/9B5HJmPay37JqoCCEKSYXZW71DqmkN
         Wpa+pBuwjlVDb6/ZRNsx0jUlDrhAq7z+XMXPU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748615863; x=1749220663;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4NVacMHC7XtpveJzs3ER6JEJKeVbCO25yrq7om+VxTQ=;
        b=K5N+ZdrW+9EinTW+Bn8qyJhI4+QLhc+Rk0XS1IzAxp+hp5OVu5CcgDXwoCZwXnotUA
         8ajl8BIoIrKQyYQj3iNN5/QnYreSD1nbtAOo+ZP6xw4LSSce3VHSxO9pucpwZEV1FGrt
         +TqMXR/PYnz4rmyA5Pxf+SeuqHZuxRsWJdp/oFBmcXhHOGq7ECwXk6DdC/NWr0hT6FBn
         9JKx1O2l2f8bX+1+t9ERpwnM/lsV++K3XJWogLBknshnfV8Oe4uRhAQ1kWVIjPXTQ7bI
         FdDvoF7IO5tlvj486Dg4iOGhOUJ+E0VoTvM5asXQssR+LsVlIOiXLjrwlSmYn7vlA9j0
         OC2Q==
X-Forwarded-Encrypted: i=1; AJvYcCX6b9VlyUqNzrUKYZNl0Xx+q5m5VsrMarjDFt+y5V+pJQhw0DVVVvMsLvzFZBVxPeNAfk0lKj2QKeU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwLtBBH1nE/zlgJPpyae2DhgJh3umGSW6wJIxjtkbPLwR0m76os
	j0nvCRL1SZirVKieGTBJ2lFvxxb3xplns+ZKP8AW9Nq1NLMl6AyKtLE6E8ppFGjjhsE=
X-Gm-Gg: ASbGnctY8Yj3zzWUsZgkZy/4h1OYlXuqbL0SMFjI6sAYMWLXiaI9O5jYgRpRfKkPaic
	fvSTG9B8IkPVJKOSQuSMZqd2id89y0jcp16PcDn7Aan2WgPvMFyMM3+D23i2LAAWFT2wzc2zq1H
	qB2qk62x6nRx4bkb/Hps/p9xp0Yxb3lKY+GxWWnSuXl4PZkF+4gPipXZf0vw2BXdfKtJc3A/Y56
	eSyo9dSLMfzLY+1YxVBHTk9Yr9CDJFnzAQrlxAxNibNe2iOciT0Ta7bZtOfF1P+XVM5bY8lS3kF
	3AKF3MYSwy97P/ynkDH1j5FQonOYtcT/Ld3h+pXYN8Gex8fxgC4JIvP9WJ+n0f6UhX0ZLgrw
X-Google-Smtp-Source: AGHT+IGhS9K7lReOHQKB4rKYAdvxg5bV8/hF2jakaiSIumrm9CclyME5tlf/79Ty8m+DMrwCNQngNw==
X-Received: by 2002:a05:6000:1a8f:b0:3a4:f786:acc8 with SMTP id ffacd0b85a97d-3a4f7a023admr2814064f8f.7.1748615862797;
        Fri, 30 May 2025 07:37:42 -0700 (PDT)
Message-ID: 
Date: Fri, 30 May 2025 15:37:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/svm: Move svm_domain structure to svm.h
To: Teddy Astie , xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
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

On 30/05/2025 9:53 am, Teddy Astie wrote:
> struct svm_domain was in vmcb.h which is meant for VMCB specific operations and
> constants, move it to svm.h where it belongs.
>
> Signed-off-by: Teddy Astie 
> ---
>  xen/arch/x86/include/asm/hvm/domain.h   |  1 +
>  xen/arch/x86/include/asm/hvm/svm/svm.h  | 11 +++++++++++
>  xen/arch/x86/include/asm/hvm/svm/vmcb.h | 11 -----------
>  3 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/asm/hvm/domain.h
> index 333501d5f2..2608bcfad2 100644
> --- a/xen/arch/x86/include/asm/hvm/domain.h
> +++ b/xen/arch/x86/include/asm/hvm/domain.h
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  

I agree the headers aren't laid out well, but this isn't great either.

You're now including svm.h in ~all translation units, because
~everything includes sched.h and sched.h includes these.

In some copious free time, what we need to do is split $foo-types.h out
of current headers so we can avoid including most of these headers in
most TUs in Xen.  But that's a huge effort.

>  #ifdef CONFIG_MEM_SHARING
>  struct mem_sharing_domain
> diff --git a/xen/arch/x86/include/asm/hvm/svm/svm.h b/xen/arch/x86/include/asm/hvm/svm/svm.h
> index 4eeeb25da9..32f6e48e30 100644
> --- a/xen/arch/x86/include/asm/hvm/svm/svm.h
> +++ b/xen/arch/x86/include/asm/hvm/svm/svm.h
> @@ -21,6 +21,17 @@ bool svm_load_segs(unsigned int ldt_ents, unsigned long ldt_base,
>                     unsigned long fs_base, unsigned long gs_base,
>                     unsigned long gs_shadow);
>  
> +struct svm_domain {
> +    /* OSVW MSRs */
> +    union {
> +        uint64_t raw[2];
> +        struct {
> +            uint64_t length;
> +            uint64_t status;
> +        };
> +    } osvw;
> +};
> +

Honestly, I'm tempted to just drop OSVW.

It's a legacy AMD facility which predates the Zen/EPYC days, which isn't
even available to guests (because it was broken when I came to do some
remedial fixes, and there's still been no work to put it into suitably
into the migrate stream).

Right now, I'm pretty confident that guests will uniformly get #GP
accessing the MSRs, and there's no way to configure visibility.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri May 30 14:54:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 14:54:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001342.1381525 (Exim 4.92)
	(envelope-from )
	id 1uL17Z-0008En-K5; Fri, 30 May 2025 14:54:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001342.1381525; Fri, 30 May 2025 14: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 1uL17Z-0008Eg-HO; Fri, 30 May 2025 14:54:09 +0000
Received: by outflank-mailman (input) for mailman id 1001342;
 Fri, 30 May 2025 14:48:18 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL11t-0006GC-T7
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 14:48:18 +0000
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com
 [205.220.177.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1ddeb4fe-3d65-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 16:48:16 +0200 (CEST)
Received: from pps.filterd (m0246631.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54UAt2Ya029174;
 Fri, 30 May 2025 14:47:20 GMT
Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta01.appoci.oracle.com [130.35.100.223])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46wjbcpcbe-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 30 May 2025 14:47:19 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 54UCxaij019186; Fri, 30 May 2025 14:47:19 GMT
Received: from nam12-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2072.outbound.protection.outlook.com [40.107.243.72])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 46u4jdce3x-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 30 May 2025 14:47:19 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
 by PH3PPFF6F8BBAB5.namprd10.prod.outlook.com (2603:10b6:518:1::7da) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.32; Fri, 30 May
 2025 14:47:16 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
 ([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.8746.030; Fri, 30 May 2025
 14:47: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" 
X-Inumbo-ID: 1ddeb4fe-3d65-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=corp-2025-04-25; bh=Y/QvbNlRztLrwVJRw4
	ySGtaqY6CZnBND7tiFkiatjrw=; b=XktmjtnnRkTTu6cNN5L2nMyunFhoXbJeKk
	1S4c9o+BoKbY3oPSCMgSn57iEuKGWzX5nknXIg9MPKJKyl4SIT2XCXsklsCh61cM
	OvRvwnNYvFMge4Ry2RkCVvymt4r2d26Qucu0RK6yzP4vvDJpJRnaYzZrqhW+URel
	fdhWG+q1prMhsQfTYYB76uJNFtYGqNK+wwJ3GbVuSoT+4qUDIvcUnzGhXiKIrOke
	hYTjZcSVZSYeyyrhF0G1OOd3toJ2bvACA8e6OJOSEiLIeAe4W9Q+pmnYQBPH6kzz
	q7ljhZk5uSpR9Dxg/WN7Rvk2qeLlqQs0hKkCGpF21w7ClnKGP5IA==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U7ODIx+R/nRpXzcsFGB5OGzGR4oohX/jMqSfUA1HFYxMN9T0q23tfB9c8zk3UWeo03YKapiSYBb1z/kToePqqKuLtuy/93niwkF/4Uu6qtwAVQ+/gduxdFgtoXQDMRdyJb35/lyCIFYmhBAKJYwL0KRYOyO7pU3aSpufBHNQzTEBck23d+/YN+GrMO6hiooxgGxJ9TkqSCSlZol2OzZtvZRWyCu+WSraZnM38mfK0Tyr8JLaBSGRhJEis9WcvI1F89UQQQtGyB7BJ7ZATzXESX+6pEu9lHZIp+mUH2/qTaL953/eV8os9vs4tTce4aQauzUog+8i9aQL40j4l+he0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Y/QvbNlRztLrwVJRw4ySGtaqY6CZnBND7tiFkiatjrw=;
 b=FYpXkDsHtUcKBGlXosDyWVyvTtpTjFbDDmZ/jjt2GpBi62PKAcI6YIujpNpfEcSxeenmxaIj/nrKDV74AeiGijL1vMOF1UdwZZch33Z5n0pPVhbfmicp7dZMeVXhqCMzD2r91rebKEUjRPBOrMmk/xoQFbVWaoGgP3yXkx5DHegTh1+aVSFnbhWbE2sOHiVxQ6WLS7diF7OjwzkU2SQZUKuOmeYlrcKFbIR2A0bCpszi98aTvUBe3UvmBcC0BOukr8uAJUW7kpPdBkWOvwxQWrmQYUkx51DXA0voKtYeDn3M966qzdXOtqYChZfn6lIIVKFw6PpcHvStOun4vLCtoQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Y/QvbNlRztLrwVJRw4ySGtaqY6CZnBND7tiFkiatjrw=;
 b=hm8VXsYbdpYqs2jWfqsQrkRfZfUl3QKg7DGGfNplhqObBD2e/RoSRo2eoPStyTYEO7eyJYcfag7YqTmCW8ZsGF96/WAPTFDg5/OgmLw6f11urfwew2ad6gbtumg59YQ6D3h89gAqfg6w9ZHqgZARA1rojVCuhWunMAuZQ9tqP58=
Date: Fri, 30 May 2025 15:47:12 +0100
From: Lorenzo Stoakes 
To: Ryan Roberts 
Cc: Catalin Marinas , Will Deacon ,
        Madhavan Srinivasan ,
        Michael Ellerman ,
        Nicholas Piggin ,
        Christophe Leroy ,
        "David S. Miller" ,
        Andreas Larsson , Juergen Gross ,
        Ajay Kaher ,
        Alexey Makhalov ,
        Thomas Gleixner , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        "H. Peter Anvin" ,
        Boris Ostrovsky ,
        "Aneesh Kumar K.V" ,
        Andrew Morton ,
        Peter Zijlstra , Arnd Bergmann ,
        David Hildenbrand ,
        "Liam R. Howlett" ,
        Vlastimil Babka , Mike Rapoport ,
        Suren Baghdasaryan , Michal Hocko ,
        Alexei Starovoitov ,
        Andrey Ryabinin ,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
        virtualization@lists.linux.dev, xen-devel@lists.xenproject.org,
        linux-mm@kvack.org, Jann Horn 
Subject: Re: [RFC PATCH v1 0/6] Lazy mmu mode fixes and improvements
Message-ID: <5b5d6352-9018-4658-b8fe-6eadaad46881@lucifer.local>
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250530140446.2387131-1-ryan.roberts@arm.com>
X-ClientProxiedBy: LO4P123CA0458.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:1aa::13) To DM4PR10MB8218.namprd10.prod.outlook.com
 (2603:10b6:8:1cc::16)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|PH3PPFF6F8BBAB5:EE_
X-MS-Office365-Filtering-Correlation-Id: 962566d2-3a42-40f2-d5b3-08dd9f88dee9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?DLGTfu3HT49n8mwVJV7dXPEjZ/IyVham/0OVA6vEuRGB0MFotU3JPOq1iKvH?=
 =?us-ascii?Q?ajZe43IsbzR69lpM8l25ZnRhN9GG8bb1DemrE7T1Rh7NSuvZEkdqXPWg0i6n?=
 =?us-ascii?Q?eHaRCz/J2B7MVHkONaSKaNA3y6OtMqvgLg/pt3qpPZtAOcPhrXtuIuliU2M5?=
 =?us-ascii?Q?XLlbAqycUthl9DNmik+zDuee/FwYeVB2tr4TE+5dsuhj61kjdEJtBD6sip0E?=
 =?us-ascii?Q?5w3YkOgZweqT7GAruGFzl+IudSQcb9P9THsSoZSH0wcAuJF+2DwxygiE54zK?=
 =?us-ascii?Q?zqSOJEoRvkgRUBIYjqAWeMmRnNj9GxNiV1N0k8PZYnCEDk+58wrsmjVwfsYW?=
 =?us-ascii?Q?VVcRP2CCZocpBC1RI/fGKlR6Iym4TMuYEYIpL7tNpZyx8TPiJhMupZ9TWeVl?=
 =?us-ascii?Q?jWVnVipKz618fNRmWNPbkKrHF+B8VnWvv59XfWj5b+IuIknee+KKza33BdXD?=
 =?us-ascii?Q?Hw74+ythuhdwtNsdz31iRwwKraZixhYVA+c8/uMUStQn7WndLZFMsiwxtAEx?=
 =?us-ascii?Q?EeMUGutBKpV2CIycCMO/RzHlfLSDaNS/prcKsQTcj1wpX3eizlCauaEgXbbU?=
 =?us-ascii?Q?1veCRrC1/Nwp0KigkyghczrmegfRA9AtyFSYI6seUMYgjiuKeoVyu5Zk/F9U?=
 =?us-ascii?Q?WkEXftAsS45IHnREyuJkZTbtsNBAFkWCMNP2GbQSdQYnct3ogp99RD62qNdR?=
 =?us-ascii?Q?1U0HuuUb5Sju6AYAlBcK8n+WahU6mtf5z84UXz7zdFWS3tupu5WwlauL166D?=
 =?us-ascii?Q?NKqDW9F1wcj2iILgdzRf578EVAmKKc6K3i7f/Y+0B6CIcTlZVEMXvGYhFzT+?=
 =?us-ascii?Q?7ZzNuvR2DToYUaWA5LpKm20cF5QxwGJsFrdUXKLIcs8YUf6xpiizjLjzJ6hY?=
 =?us-ascii?Q?nN4e7tlhz4ctbtNZCqqSXji9XDgE8MDMgK3WVfrghyNu7NOGc17c3eU6tYaI?=
 =?us-ascii?Q?A4MphqPhS1AV4loJCOijot3VcgNybgOoBi7Uh0Uyh8322TIZlsCZ2+EeOXLw?=
 =?us-ascii?Q?9YTsBmUNcI+Cq7iXW9mWoujdDX4HjkZiFu94VRBlMvJyCM3kzSI96Uu5thJL?=
 =?us-ascii?Q?oS5owQF8rP5uF64Qg3YrnvRdh8JqUodZ+Zax7/+6ZFZNtYADNI42r6nvbTRG?=
 =?us-ascii?Q?+x2pH7REKC0KhALVt+lM9TWhaqNM5Tk5f1Kho1nAxN1XznqUEPX7T1Wr9uvE?=
 =?us-ascii?Q?rs3uJqhLUdJTgAMK7mm0bawFZodBQ9c6PzR5X1skVyBIGZ6E0V/WIcFNF+1u?=
 =?us-ascii?Q?1Hxiqw7Bsnp8HvyHhud27UlFrMpROfQbIAVb8bKB1oVYDurFIiTPNth4dBWV?=
 =?us-ascii?Q?YAtX0vQ6h8wnNygG7uaznC2vtSxFTmeHUEq7uK3WYUpIbSWtSqHZ9DrCPjAr?=
 =?us-ascii?Q?TzVWELnhmb0EZIaKqV13SP+x8DrjMMvMLvTVGA5p0M71qMBSUQdLBAjcbGSS?=
 =?us-ascii?Q?+BdQ//Jl8f8=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?Q+JC66hvzFm6Uk2dih2OEVT1uhV8iZlD0VieGfm0aT0rBIgio3g0k0BxZbHE?=
 =?us-ascii?Q?xukbdz/ZM5NwjG0/vXHsHfQuWU7LYOEigPAHbaKXoC48vstfFG9ZLn8KNnMG?=
 =?us-ascii?Q?xyGByIQeTc0+BzCVDAhi8P9kdLF/n7nfIygd6r6BM+bdTPVHViJvuHEsJ60V?=
 =?us-ascii?Q?zN5XLtfWTk1RsARjtt6rAYMDMXD46tWQW86nl/aQIqJUunsEGeJBG4MAmlfB?=
 =?us-ascii?Q?wMwUOEXnbqeUFZIPG0lw70EDmmRVi7GI4aC9fKu62FfphgYnIxUg9T2XHlRZ?=
 =?us-ascii?Q?GPUTJ31Z9yFc7hXaW29qJYvRckuMbvCoJrHShNIBhjMmvgiJVaw3kwxFzxuB?=
 =?us-ascii?Q?NTjmNdYM7xUdIwTmuT2fz3FSUZiWYHw8mymiRPx5Xc9pfXciy8r5a3yi3JS4?=
 =?us-ascii?Q?fq+rskupKWvcjrQSkF5bqgK69uQNtxODiQ1szZ6BKUKYCOvU07PTmvChhuE/?=
 =?us-ascii?Q?fF5wbzZpWsbl0DM8iZBrAJUiEl7t3X6vDFbpaQb52lODAEcVOdnltwVAnjlU?=
 =?us-ascii?Q?SImXimXsMk2i2sEjYAkJGrCLoJspK0lc5lle3v7de/KrUfFNuY7gEPnqfqON?=
 =?us-ascii?Q?7wBDnUs0blbtakT1fv2iQgrVlbfCXOjKvHWY8F65A99T3hzID9eYErOpyTyt?=
 =?us-ascii?Q?TTrbT87qIqX8wjOT4Mz1BQ/DwdOMjw9RYUtJjgTqjd9yGnM7ZCCRy+C+YPMV?=
 =?us-ascii?Q?evliq17uxIz2SyyFLjaiSAsuI3+tR4TevOsXF51sEcUNxOwQ6oPy9jYS7ssG?=
 =?us-ascii?Q?mQoCuQR1jU16NM++SZVuud9rnbA5CqiXTia0x/NLuecGDeayZC9GCL33u9mK?=
 =?us-ascii?Q?YtDgnSE8bbTTr0NjNB1bEwnXzvGlVDaivspE4WbNj7NY/tzuJ/jX2lDPeIt6?=
 =?us-ascii?Q?KZSHk+d7JS7QorIHnD87n47Bq+AZtTNgCBM8m3d40rX1nUevjJeIE2AX7HtS?=
 =?us-ascii?Q?vpKt1SvMB/u6ASHfDkZhVIi/OHNry6tDeY37YhqNDd1xxP48VNRy9zqAYOg1?=
 =?us-ascii?Q?ycD0etQFkwrCsiPUZFSCUkpf31dy9gvOGX1hz2jrEZKdMWFqbLuzLh+FXGol?=
 =?us-ascii?Q?oshoXrEqlc63TdnTyXIlYmiBjDyPD+Q2LeUmu/UFpwIUnDcHd6kFRTo9hlaH?=
 =?us-ascii?Q?QFeiKcA132B3PP7EP1ln2N9d3Zq/WNJufaBye+qtAscvnbst2PjFRnjauCEt?=
 =?us-ascii?Q?rLDz6PK1dCNxE8L88gehXHvSPMKOqFopuFmKFN2m3W1vzpyDKpH/cnzaORn7?=
 =?us-ascii?Q?s591aKz30VtfoZHss1mMw4m6trFHlVMCQI+Dn4K+/Dx3U7qBdNlJir0qkmg5?=
 =?us-ascii?Q?UfJcva5UBsf1ZUo30U8nlWwwUytMFTKwpqeY02IHwKkhgbQxlKxcug75dxP8?=
 =?us-ascii?Q?ClLDbrz74go12AUMybxcZfKo/knfk4l3rgPFP+LFPUiQqudQI9MmEFkSrPXC?=
 =?us-ascii?Q?UZSaKUhwgFrnCkVVB0sRK8LaFZ7eG8NA06JLyPF5bCBiOktlkAlZ/hFbp7SI?=
 =?us-ascii?Q?OqNIwjGyZ6UZYB51WnXonRPHu4pZJeGJK4AFqZ6g52JK3HCxzdcI53il0BAx?=
 =?us-ascii?Q?u6EvvDZDdCl7LhFtvR63yXE/n/jtsmIe++gFb7LptEPVKArvBfDnxirk3Rus?=
 =?us-ascii?Q?3w=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	ObqvUQbqL1TwvmcNRbHTslwpFkt0+TOvMUVI/s4ygbk3inFVNK5jHdS01pPTZlOVhptIcmoPaqg5cKX2rXPPzpgYd0VOW8TVBr8SC7Z2aFHqJIl9vX2hHPTAkIJQA/QYt1qcvcZ8iIG8gVfdAdC9jJwnz77en/92YVe/cD+DpE6ngi2Dw+zJKL4M0syip7PCQVoJocT15zpK9C0iDWJxxMk4Dpu2tFt0tvgYCA6UTAzbj3V0y0Xa2Z9eXywlj9wbhRJo8xhhWxKRjVixhuK3IqFSG8F5md1BWGAXcJdg43Qx5g+NDoVMn2oADL8nnMHeBqZteOzpuo7K38LokuOFxouar+x16P+IWQjK9emrZfBwXe0q/SgJiO0ClC9HAsERIU05j86rm291gS2QeehgUvDe35tkl2g8LLz4vtTbglVHupW0t5DB7d3dzKadmdu1+Gmn15unfc9veMAnaJ+2vKOpFONIAdFZ+fLg8m3EOsdaJQbZQzxnhC0k4JiF2j2/HM4hpQg99xPWZfABMTa+S35Lis21TXm1OXtWc7gdZKlzTFeWY3uEL9GU3X3i+clvOOwKZVndjWbm1oFZqLOz0RJZFMfMGWcQhFN7mVkV7Tk=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 962566d2-3a42-40f2-d5b3-08dd9f88dee9
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 14:47:16.2589
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: paCbijAvqhoCcsUE4bx/XLCm21TtFmbcXyty7It48qaRkI8x9OkRvKDnxf4ULgv7XgPmx4YkQhn+tmxFQLGaTyfM7ZkMa5OllQcli09Dv7o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH3PPFF6F8BBAB5
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-05-30_05,2025-05-30_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 spamscore=0
 suspectscore=0 bulkscore=0 phishscore=0 mlxlogscore=999 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
 definitions=main-2505300129
X-Proofpoint-GUID: CAC20cpsWRupwdAhkQC36DRJpwiI6bc-
X-Proofpoint-ORIG-GUID: CAC20cpsWRupwdAhkQC36DRJpwiI6bc-
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDEyOSBTYWx0ZWRfX5bt/W3HQfBxj jR99AVdDh774mt+1De3uIlimIO6UUEtJSo7mQgI4LFDbcCUea8Xsi1dXbt/kNFcKmCwS804oUSA lcCCwpUa7HFoWPVNxbrsdT3GDPqvYZGr6WodjqgmuO6Ez/lDTS1fNI85/tC1ZW0emmJk8omNnXy
 Uv+5zu0uSeJ29JBlhNWy3QbZLKOugalA1J+d0XUdn8ZYGOKwtkBjCfTTEPAlnmppa2ggBLH+a8C cA6SSen2wDNN7LM9hk/xLfnfisGwiXEKf6WGzXH8sBD3XDbusxHYGLspQT7N0RyKouv+8wUlRVQ NhuEwz3qZkWRXDywc/oH/RlEv3KshBga4zmoDM8M7XwDKb37BVhil3n59gaZrp3i1IHRWnk1QG/
 Q2Jv633wTy+yDVt1H5jQzkmDtMl21iExwyImNY/1MzaNlVr2aE/EM/1wJKcvU78aS6Hz7MkG
X-Authority-Analysis: v=2.4 cv=c8qrQQ9l c=1 sm=1 tr=0 ts=6839c4f7 b=1 cx=c_pps a=zPCbziy225d3KhSqZt3L1A==:117 a=zPCbziy225d3KhSqZt3L1A==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=GoEa3M9JfhUA:10 a=VwQbUJbxAAAA:8 a=7CQSdrXTAAAA:8 a=KazR_yWdSLylfOF19RIA:9 a=CjuIK1q_8ugA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 cc=ntf awl=host:13206

+cc Jann who is a specialist in all things page table-y and especially scary
edge cases :)

On Fri, May 30, 2025 at 03:04:38PM +0100, Ryan Roberts wrote:
> Hi All,
>
> I recently added support for lazy mmu mode on arm64. The series is now in
> Linus's tree so should be in v6.16-rc1. But during testing in linux-next we
> found some ugly corners (unexpected nesting). I was able to fix those issues by
> making the arm64 implementation more permissive (like the other arches). But
> this is quite fragile IMHO. So I'd rather fix the root cause and ensure that
> lazy mmu mode never nests, and more importantly, that code never makes pgtable
> modifications expecting them to be immediate, not knowing that it's actually in
> lazy mmu mode so the changes get deferred.

When you say fragile, are you confident it _works_ but perhaps not quite as well
as you want? Or are you concerned this might be broken upstream in any way?

I am thinking specifically about the proposed use in Dev's new series [0] and
obviously hoping (and assuming in fact) that it's the former :)

[0]: https://lore.kernel.org/linux-mm/20250530090407.19237-1-dev.jain@arm.com/

>
> The first 2 patches are unrelated, very obvious bug fixes. They don't affect
> arm64 because arm64 only uses lazy mmu for kernel mappings. But I noticed them
> during code review and think they should be fixed.
>
> The next 3 patches are aimed at solving the nesting issue.
>
> And the final patch is reverting the "permissive" fix I did for arm64, which is
> no longer needed after the previous 3 patches.
>
> I've labelled this RFC for now because it depends on the arm64 lazy mmu patches
> in Linus's master, so it won't apply to mm-unstable. But I'm keen to get review
> and siince I'm touching various arches and modifying some core mm stuff, I
> thought that might take a while so thought I'd beat the rush and get a first
> version out early.
>
> I've build-tested all the affected arches. And I've run mm selftests for the
> arm64 build, with no issues (with DEBUG_PAGEALLOC and KFENCE enabled).
>
> Applies against Linus's master branch (f66bc387efbe).
>
> Thanks,
> Ryan
>
>
> Ryan Roberts (6):
>   fs/proc/task_mmu: Fix pte update and tlb maintenance ordering in
>     pagemap_scan_pmd_entry()
>   mm: Fix pte update and tlb maintenance ordering in
>     migrate_vma_collect_pmd()
>   mm: Avoid calling page allocator from apply_to_page_range()
>   mm: Introduce arch_in_lazy_mmu_mode()
>   mm: Avoid calling page allocator while in lazy mmu mode
>   Revert "arm64/mm: Permit lazy_mmu_mode to be nested"
>
>  arch/arm64/include/asm/pgtable.h              | 22 ++++----
>  .../include/asm/book3s/64/tlbflush-hash.h     | 15 ++++++
>  arch/sparc/include/asm/tlbflush_64.h          |  1 +
>  arch/sparc/mm/tlb.c                           | 12 +++++
>  arch/x86/include/asm/paravirt.h               |  5 ++
>  arch/x86/include/asm/paravirt_types.h         |  1 +
>  arch/x86/kernel/paravirt.c                    |  6 +++
>  arch/x86/xen/mmu_pv.c                         |  6 +++
>  fs/proc/task_mmu.c                            |  3 +-
>  include/asm-generic/tlb.h                     |  2 +
>  include/linux/mm.h                            |  6 +++
>  include/linux/pgtable.h                       |  1 +
>  kernel/bpf/arena.c                            |  6 +--
>  mm/kasan/shadow.c                             |  2 +-
>  mm/memory.c                                   | 54 ++++++++++++++-----
>  mm/migrate_device.c                           |  3 +-
>  mm/mmu_gather.c                               | 15 ++++++
>  17 files changed, 128 insertions(+), 32 deletions(-)
>
> --
> 2.43.0
>


From xen-devel-bounces@lists.xenproject.org Fri May 30 15:56:07 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 15:56:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001360.1381545 (Exim 4.92)
	(envelope-from )
	id 1uL25E-0001eb-1s; Fri, 30 May 2025 15:55:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001360.1381545; Fri, 30 May 2025 15:55:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL25D-0001eT-TT; Fri, 30 May 2025 15:55:47 +0000
Received: by outflank-mailman (input) for mailman id 1001360;
 Fri, 30 May 2025 15:55:47 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL25D-0001eN-2i
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 15:55:47 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 8b3b35dc-3d6e-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 17:55:44 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 09446169C;
 Fri, 30 May 2025 08:55:27 -0700 (PDT)
Received: from [10.57.95.14] (unknown [10.57.95.14])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BF2053F673;
 Fri, 30 May 2025 08:55:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8b3b35dc-3d6e-11f0-a2ff-13f23c93f187
Message-ID: 
Date: Fri, 30 May 2025 16:55:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v1 0/6] Lazy mmu mode fixes and improvements
Content-Language: en-GB
To: Lorenzo Stoakes 
Cc: Catalin Marinas , Will Deacon ,
 Madhavan Srinivasan ,
 Michael Ellerman , Nicholas Piggin ,
 Christophe Leroy ,
 "David S. Miller" ,
 Andreas Larsson , Juergen Gross ,
 Ajay Kaher ,
 Alexey Makhalov ,
 Thomas Gleixner , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky ,
 "Aneesh Kumar K.V" ,
 Andrew Morton ,
 Peter Zijlstra , Arnd Bergmann ,
 David Hildenbrand ,
 "Liam R. Howlett" , Vlastimil Babka
 , Mike Rapoport ,
 Suren Baghdasaryan , Michal Hocko ,
 Alexei Starovoitov , Andrey Ryabinin
 , linux-arm-kernel@lists.infradead.org,
 linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, virtualization@lists.linux.dev,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org,
 Jann Horn 
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
 <5b5d6352-9018-4658-b8fe-6eadaad46881@lucifer.local>
From: Ryan Roberts 
In-Reply-To: <5b5d6352-9018-4658-b8fe-6eadaad46881@lucifer.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30/05/2025 15:47, Lorenzo Stoakes wrote:
> +cc Jann who is a specialist in all things page table-y and especially scary
> edge cases :)
> 
> On Fri, May 30, 2025 at 03:04:38PM +0100, Ryan Roberts wrote:
>> Hi All,
>>
>> I recently added support for lazy mmu mode on arm64. The series is now in
>> Linus's tree so should be in v6.16-rc1. But during testing in linux-next we
>> found some ugly corners (unexpected nesting). I was able to fix those issues by
>> making the arm64 implementation more permissive (like the other arches). But
>> this is quite fragile IMHO. So I'd rather fix the root cause and ensure that
>> lazy mmu mode never nests, and more importantly, that code never makes pgtable
>> modifications expecting them to be immediate, not knowing that it's actually in
>> lazy mmu mode so the changes get deferred.
> 
> When you say fragile, are you confident it _works_ but perhaps not quite as well
> as you want? Or are you concerned this might be broken upstream in any way?

I'm confident that it _works_ for arm64 as it is, upstream. But if Dev's series
were to go in _without_ the lazy_mmu bracketting in some manner, then it would
be broken if the config includes CONFIG_DEBUG_PAGEALLOC.

There's a lot more explanation in the later patches as to how it can be broken,
but for arm64, the situation is currently like this, because our implementation
of __change_memory_common() uses apply_to_page_range() which implicitly starts
an inner lazy_mmu_mode. We enter multiple times, but we exit one the first call
to exit. Everything works correctly but it's not optimal because C is no longer
deferred:

arch_enter_lazy_mmu_mode()                        << outer lazy mmu region
  
  alloc_pages()
    debug_pagealloc_map_pages()
      __kernel_map_pages()
        __change_memory_common()
          arch_enter_lazy_mmu_mode()              << inner lazy mmu region
            
          arch_leave_lazy_mmu_mode()              << exit; complete A + B
    clear_page()
                    << no longer in lazy mode
arch_leave_lazy_mmu_mode()                        << nop

An alternative implementation would not add the nested lazy mmu mode, so we end
up with this:

arch_enter_lazy_mmu_mode()                        << outer lazy mmu region
  
  alloc_pages()
    debug_pagealloc_map_pages()
      __kernel_map_pages()
        __change_memory_common()
             << deferred due to lazy mmu
    clear_page()                                  << BANG! B has not be actioned
  
arch_leave_lazy_mmu_mode()

This is clearly a much worse outcome. It's not happening today but it could in
future. That's why I'm claiming it's fragile. It's much better (IMHO) to
disallow calling the page allocator when in lazy mmu mode.

I won't speak for other arches; there may be more or less potential impact for them.

> 
> I am thinking specifically about the proposed use in Dev's new series [0] and
> obviously hoping (and assuming in fact) that it's the former :)

Dev's changes aren't directly related to this, but if a version was accepted
that didn't include the lazy mmu mode, that would cause non-obvious issues.

Hope that helps?

Thanks,
Ryan

> 
> [0]: https://lore.kernel.org/linux-mm/20250530090407.19237-1-dev.jain@arm.com/
> 
>>
>> The first 2 patches are unrelated, very obvious bug fixes. They don't affect
>> arm64 because arm64 only uses lazy mmu for kernel mappings. But I noticed them
>> during code review and think they should be fixed.
>>
>> The next 3 patches are aimed at solving the nesting issue.
>>
>> And the final patch is reverting the "permissive" fix I did for arm64, which is
>> no longer needed after the previous 3 patches.
>>
>> I've labelled this RFC for now because it depends on the arm64 lazy mmu patches
>> in Linus's master, so it won't apply to mm-unstable. But I'm keen to get review
>> and siince I'm touching various arches and modifying some core mm stuff, I
>> thought that might take a while so thought I'd beat the rush and get a first
>> version out early.
>>
>> I've build-tested all the affected arches. And I've run mm selftests for the
>> arm64 build, with no issues (with DEBUG_PAGEALLOC and KFENCE enabled).
>>
>> Applies against Linus's master branch (f66bc387efbe).
>>
>> Thanks,
>> Ryan
>>
>>
>> Ryan Roberts (6):
>>   fs/proc/task_mmu: Fix pte update and tlb maintenance ordering in
>>     pagemap_scan_pmd_entry()
>>   mm: Fix pte update and tlb maintenance ordering in
>>     migrate_vma_collect_pmd()
>>   mm: Avoid calling page allocator from apply_to_page_range()
>>   mm: Introduce arch_in_lazy_mmu_mode()
>>   mm: Avoid calling page allocator while in lazy mmu mode
>>   Revert "arm64/mm: Permit lazy_mmu_mode to be nested"
>>
>>  arch/arm64/include/asm/pgtable.h              | 22 ++++----
>>  .../include/asm/book3s/64/tlbflush-hash.h     | 15 ++++++
>>  arch/sparc/include/asm/tlbflush_64.h          |  1 +
>>  arch/sparc/mm/tlb.c                           | 12 +++++
>>  arch/x86/include/asm/paravirt.h               |  5 ++
>>  arch/x86/include/asm/paravirt_types.h         |  1 +
>>  arch/x86/kernel/paravirt.c                    |  6 +++
>>  arch/x86/xen/mmu_pv.c                         |  6 +++
>>  fs/proc/task_mmu.c                            |  3 +-
>>  include/asm-generic/tlb.h                     |  2 +
>>  include/linux/mm.h                            |  6 +++
>>  include/linux/pgtable.h                       |  1 +
>>  kernel/bpf/arena.c                            |  6 +--
>>  mm/kasan/shadow.c                             |  2 +-
>>  mm/memory.c                                   | 54 ++++++++++++++-----
>>  mm/migrate_device.c                           |  3 +-
>>  mm/mmu_gather.c                               | 15 ++++++
>>  17 files changed, 128 insertions(+), 32 deletions(-)
>>
>> --
>> 2.43.0
>>



From xen-devel-bounces@lists.xenproject.org Fri May 30 16:27:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 16:27:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001394.1381553 (Exim 4.92)
	(envelope-from )
	id 1uL2Zp-0006eu-DD; Fri, 30 May 2025 16:27:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001394.1381553; Fri, 30 May 2025 16: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 1uL2Zp-0006en-Ak; Fri, 30 May 2025 16:27:25 +0000
Received: by outflank-mailman (input) for mailman id 1001394;
 Fri, 30 May 2025 16:27:24 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL2Zn-0006eg-WB
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 16:27:24 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f629518e-3d72-11f0-a2ff-13f23c93f187;
 Fri, 30 May 2025 18:27:23 +0200 (CEST)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-601a67c6e61so14a12.0
 for ; Fri, 30 May 2025 09: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" 
X-Inumbo-ID: f629518e-3d72-11f0-a2ff-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1748622441; x=1749227241; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Wb7EzNeuZNtT7LoNB6YIvTwNTIj8nYWDYSy4GeuX+MM=;
        b=LZeZCMMuYMlUod9vGbTfMi9+hQ8syFhA9I2Y1YZj/qe/J4kH39K4P6YiKTLHKEpgJX
         hz6dh1CSKhKmT0XxHTMGKaXCJ5LthCaSPbrUXjhuOnG9jkUX0/g9mJVZn87TkriCmFU8
         YInQVBHKb3F05g53+4nQbHX/EgNVMWIO95IACPJMTyNfLKznB4atEJ85F7EngADXczSr
         JBOlMBV/rOh0Od/gz1fbDTDKCYkm8L2Hmu0OjxMoD2aKB5eJwMJRblD2JUc+zD8srkMC
         coOBRiVE0QmFJFxjUWKZDhkaIWfS4aan8q8wy+FfAhmBE6EWeg0l1ANNQym0rsD95RHA
         mydQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748622441; x=1749227241;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Wb7EzNeuZNtT7LoNB6YIvTwNTIj8nYWDYSy4GeuX+MM=;
        b=wtnQBb7ciH8EACUiBnOip3Fy1YCeadxuoeoVFWKJiTi3u2KBx2Lx/syT6bOW9TFCuO
         9vlLy4k5EpAlR4biqNHQFBOOumyllG2UODJV9NaYborx2IM6VEI+eSTKheKzqi8zruiT
         dPoA0jLU+al7VMhuKCr59fOd0B4+G2Xu+Yhti2oLSS4wP3OIOCboAlibvWqV10ODcTFF
         D2e+MbTmEEqXbze0iRKUmJltyHK3aYmE1GGyTAYrz1RtgyfHZQwACXoO66LE5njd7zWQ
         a0VyvqEGkrxH043pRhq+VgJ9oNxUSqEKI7zoxCwT7aljLiMNXa29RF9Jz5It9E0mdVcd
         nkkg==
X-Forwarded-Encrypted: i=1; AJvYcCWRp+ymqzA1yYk7SZKjlj4uWgHwuy1mO2ycgvtGATnK5nzB5W5qpmKdJVi1KoXw+jhtqVYS896OO5A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwU8oxc/4C6d+ecNq7zlMIQy10beDpsHWIdoJLailR/voVchL5h
	IJt6GDFQkU9cDYQVwvN76ALl8d56PP116C4zbOHtA0UsaKxEE7Vo1FEJcrjvMWA4/09BhM5ldvF
	flqC/ZRm/1iMgRhcb+0ifU0RE+I7iw9x3RzNvzLAU
X-Gm-Gg: ASbGncsF8JL84kaYS/Y6GFKtU10gXAdDAiOhfrrFfk1aCf9WmKK4+1SWyKVNxfHZEeM
	yG6v4vFGyh2vb8xNTvrFo2XPZ5kxaIwGZONOpbQ50L+2CBygfPF+2wMSJTUXdZtnB2kU9qyjirP
	DTy96e6ssdyAjjxY5h1Rmi5QKC3vSAWV6f2zM96LFunE/d+V2MSkHTffFbFcxXp2uKrKdHtwE=
X-Google-Smtp-Source: AGHT+IFvo4UeYXqvvR6hGpmlYjccx/P9qAgBVyNpakUtwWnk/plyYyjpSLFfr/exrsOHq2DB2NbEp4NJnsA/fPm9vYQ=
X-Received: by 2002:a50:f608:0:b0:5e6:15d3:ffe7 with SMTP id
 4fb4d7f45d1cf-60577a55f40mr88916a12.7.1748622440589; Fri, 30 May 2025
 09:27:20 -0700 (PDT)
MIME-Version: 1.0
References: <20250530140446.2387131-1-ryan.roberts@arm.com> <20250530140446.2387131-2-ryan.roberts@arm.com>
In-Reply-To: <20250530140446.2387131-2-ryan.roberts@arm.com>
From: Jann Horn 
Date: Fri, 30 May 2025 18:26:44 +0200
X-Gm-Features: AX0GCFt5gaAeg9wlqckCjWiqvoyfvAtwj8XYq0jNIyzkBuWgoy0LcwI3HloBVMo
Message-ID: 
Subject: Re: [RFC PATCH v1 1/6] fs/proc/task_mmu: Fix pte update and tlb
 maintenance ordering in pagemap_scan_pmd_entry()
To: Ryan Roberts 
Cc: Catalin Marinas , Will Deacon , 
	Madhavan Srinivasan , Michael Ellerman , 
	Nicholas Piggin , Christophe Leroy , 
	"David S. Miller" , Andreas Larsson , 
	Juergen Gross , Ajay Kaher , 
	Alexey Makhalov , Thomas Gleixner , 
	Ingo Molnar , Borislav Petkov , 
	Dave Hansen , "H. Peter Anvin" , 
	Boris Ostrovsky , "Aneesh Kumar K.V" , 
	Andrew Morton , Peter Zijlstra , 
	Arnd Bergmann , David Hildenbrand , 
	Lorenzo Stoakes , "Liam R. Howlett" , 
	Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , 
	Michal Hocko , Alexei Starovoitov , 
	Andrey Ryabinin , linux-arm-kernel@lists.infradead.org, 
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	sparclinux@vger.kernel.org, virtualization@lists.linux.dev, 
	xen-devel@lists.xenproject.org, linux-mm@kvack.org, 
	Andy Lutomirski 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 30, 2025 at 4:04=E2=80=AFPM Ryan Roberts =
 wrote:
> pagemap_scan_pmd_entry() was previously modifying ptes while in lazy mmu
> mode, then performing tlb maintenance for the modified ptes, then
> leaving lazy mmu mode. But any pte modifications during lazy mmu mode
> may be deferred until arch_leave_lazy_mmu_mode(), inverting the required
> ordering between pte modificaiton and tlb maintenance.
>
> Let's fix that by leaving mmu mode, forcing all the pte updates to be
> actioned, before doing the tlb maintenance.
>
> This is a theorectical bug discovered during code review.
>
> Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and option=
ally clear info about PTEs")

Hmm... isn't lazy mmu mode supposed to also delay TLB flushes, and
preserve the ordering of PTE modifications and TLB flushes?

Looking at the existing implementations of lazy MMU:

 - In Xen PV implementation of lazy MMU, I see that TLB flush
hypercalls are delayed as well (xen_flush_tlb(),
xen_flush_tlb_one_user() and xen_flush_tlb_multi() all use
xen_mc_issue(XEN_LAZY_MMU) which delays issuing if lazymmu is active).
 - The sparc version also seems to delay TLB flushes, and sparc's
arch_leave_lazy_mmu_mode() seems to do TLB flushes via
flush_tlb_pending() if necessary.
 - powerpc's arch_leave_lazy_mmu_mode() also seems to do TLB flushes.

Am I missing something?

If arm64 requires different semantics compared to all existing
implementations and doesn't delay TLB flushes for lazy mmu mode, I
think the "Fixes" tag should point to your addition of lazy mmu
support for arm64.

> Signed-off-by: Ryan Roberts 
> ---
>  fs/proc/task_mmu.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 994cde10e3f4..361f3ffd9a0c 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -2557,10 +2557,9 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsi=
gned long start,
>         }
>
>  flush_and_return:
> +       arch_leave_lazy_mmu_mode();
>         if (flush_end)
>                 flush_tlb_range(vma, start, addr);
> -
> -       arch_leave_lazy_mmu_mode();

I think this ordering was probably intentional, because doing it this
way around allows Xen PV to avoid one more hypercall, because the TLB
flush can be batched together with the page table changes?


>         pte_unmap_unlock(start_pte, ptl);
>
>         cond_resched();
> --
> 2.43.0
>


From xen-devel-bounces@lists.xenproject.org Fri May 30 16:28:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 16:28:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001392.1381563 (Exim 4.92)
	(envelope-from )
	id 1uL2ao-0007D3-Qi; Fri, 30 May 2025 16:28:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001392.1381563; Fri, 30 May 2025 16:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL2ao-0007Cw-Nt; Fri, 30 May 2025 16:28:26 +0000
Received: by outflank-mailman (input) for mailman id 1001392;
 Fri, 30 May 2025 16:24:41 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL2XB-0006ap-1u
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 16:24:41 +0000
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com
 [205.220.177.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92bb5c27-3d72-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 18:24:35 +0200 (CEST)
Received: from pps.filterd (m0246631.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54UGN9np027654;
 Fri, 30 May 2025 16:23:36 GMT
Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta01.appoci.oracle.com [130.35.100.223])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46wjbcpjh6-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 30 May 2025 16:23:36 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 54UGE3kU019300; Fri, 30 May 2025 16:23:35 GMT
Received: from dm5pr21cu001.outbound.protection.outlook.com
 (mail-centralusazon11011016.outbound.protection.outlook.com [52.101.62.16])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 46u4jdg1uj-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 30 May 2025 16:23:35 +0000
Received: from PH0PR10MB5777.namprd10.prod.outlook.com (2603:10b6:510:128::16)
 by DM6PR10MB4218.namprd10.prod.outlook.com (2603:10b6:5:222::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.35; Fri, 30 May
 2025 16:23:32 +0000
Received: from PH0PR10MB5777.namprd10.prod.outlook.com
 ([fe80::75a8:21cc:f343:f68c]) by PH0PR10MB5777.namprd10.prod.outlook.com
 ([fe80::75a8:21cc:f343:f68c%6]) with mapi id 15.20.8746.035; Fri, 30 May 2025
 16:23: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" 
X-Inumbo-ID: 92bb5c27-3d72-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=corp-2025-04-25; bh=z3IMNQdsmC2DCOkbLy
	x7xZc2rQ1pHkFPsx8mRJLi9aQ=; b=Y9maxsATkcbroTC7Gs2beoJCLF7Q5vQT8t
	oy17r4F49Nr8Ki1PdboBXmXfZSUM0V/Z2ipSfoKmZc2jRLvcbAXR3jAMSaMq3qGV
	NH6UIgQA48LvblJE51LECKWW8cy7ffC+mbo678G+ubDwVl9/z0j2MDGEtX64txCG
	G9IkH/b2GDbWno2pgUD6LVZXJzLxJQ3YWxX1/HGXFRrYEkcrkQhyU1HY3r40cRMY
	Cl/i+hu6tGfYA9KZSbtApSDhyfQYLWGxi7WwPklPn+TcLqeJ8UWMoz6HDigToTnR
	sWhXAD8ujMZBEsINl1/h0ah0jJJJr3mqy5VP+c31KnPQuXeW/E4g==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IIP9nKk1pq26oj2y5bu4bwf7t1LccVLx+R1Ij+q8Q2/aj9wIUCGhCcEKBXyhVHgdn3BOTBm3gQCwsBRJ2hWcL0ChguN0M2EVqUpvk7120FdGOMhEgVaIISbFbFk+yuRQ1tWk/+gRjCW6aFkdVc3aW85JbOC1RifjZyjht1lypqVa127f8vSAI8hMENS6StG6FQue+hXf57Uj5/AgfNJyJoGVhpQQMRGJ/As5lpAmwiYFz9gglSVJl7PTpBrxfsYkBeHzhFs/++NhwW894n+fxOkaNkgYwWJ+A8KY5w+dXGyZOS+kqpZxXT3hqRdP7OktlRCfOo1NQ8/ssBGPzeFWNQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=z3IMNQdsmC2DCOkbLyx7xZc2rQ1pHkFPsx8mRJLi9aQ=;
 b=B05DTUNndrRC/znt9MkRGOhx/LJjPfABIjHA+o7uIe2T9KXcQflos/rNmHizW4YDj+puszCbmvuS7lhH5wG7veJTOj8TWpwMkV2CSltoubWVCeuvtwHdvIwlJ1vLf6nyFzwxf+Khbn3unjBiLM56dApgHyV7CC9b+x0qHehvLbEAPOTv4MCp2DFogOBo0veHVTomXZBGm/Jy/gOBEGzrKAehU0mdfLmau+kCGxaarpDygb22D3EigOtbOW/lvrxPFj4rCTRjMrt4ia6jzxdoPpZ/Mz8IQsjCHBG6Nrzw4APlgS+1kBi6haZ8it66rArcQBEDLtGlfjJyRGtiIL6ClA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=z3IMNQdsmC2DCOkbLyx7xZc2rQ1pHkFPsx8mRJLi9aQ=;
 b=oCyl+mXFmpvBmRnPZxUw2KzJBEl6GocTDSe3Y1VqRHhhvj3wiDWH9alaPuD6cj60ovuNd7UxVNLF1ccohtV9TG7zhHWzY9HRCr+11MQ57JDXq9coHNsasy7szPdtscEU6gMwDirFj2PrmgA+3muA84uZozqe0EjWRn5masqUlEg=
Date: Fri, 30 May 2025 12:23:19 -0400
From: "Liam R. Howlett" 
To: Ryan Roberts 
Cc: Catalin Marinas , Will Deacon ,
        Madhavan Srinivasan ,
        Michael Ellerman ,
        Nicholas Piggin ,
        Christophe Leroy ,
        "David S. Miller" ,
        Andreas Larsson , Juergen Gross ,
        Ajay Kaher ,
        Alexey Makhalov ,
        Thomas Gleixner , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        "H. Peter Anvin" ,
        Boris Ostrovsky ,
        "Aneesh Kumar K.V" ,
        Andrew Morton ,
        Peter Zijlstra , Arnd Bergmann ,
        David Hildenbrand ,
        Lorenzo Stoakes ,
        Vlastimil Babka , Mike Rapoport ,
        Suren Baghdasaryan , Michal Hocko ,
        Alexei Starovoitov ,
        Andrey Ryabinin ,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
        virtualization@lists.linux.dev, xen-devel@lists.xenproject.org,
        linux-mm@kvack.org
Subject: Re: [RFC PATCH v1 3/6] mm: Avoid calling page allocator from
 apply_to_page_range()
Message-ID: <6nf3cxwhij7jtfi2u6nmt4igezf754gmue5dfskn4jkfkxmjzr@7btdipzmzjuo>
Mail-Followup-To: "Liam R. Howlett" , 
	Ryan Roberts , Catalin Marinas , 
	Will Deacon , Madhavan Srinivasan , 
	Michael Ellerman , Nicholas Piggin , 
	Christophe Leroy , "David S. Miller" , 
	Andreas Larsson , Juergen Gross , 
	Ajay Kaher , Alexey Makhalov , 
	Thomas Gleixner , Ingo Molnar , Borislav Petkov , 
	Dave Hansen , "H. Peter Anvin" , 
	Boris Ostrovsky , "Aneesh Kumar K.V" , 
	Andrew Morton , Peter Zijlstra , 
	Arnd Bergmann , David Hildenbrand , 
	Lorenzo Stoakes , Vlastimil Babka , 
	Mike Rapoport , Suren Baghdasaryan , 
	Michal Hocko , Alexei Starovoitov , 
	Andrey Ryabinin , linux-arm-kernel@lists.infradead.org, 
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org, 
	virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mm@kvack.org
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
 <20250530140446.2387131-4-ryan.roberts@arm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250530140446.2387131-4-ryan.roberts@arm.com>
User-Agent: NeoMutt/20240425
X-ClientProxiedBy: YQBPR0101CA0057.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:c00:1::34) To PH0PR10MB5777.namprd10.prod.outlook.com
 (2603:10b6:510:128::16)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH0PR10MB5777:EE_|DM6PR10MB4218:EE_
X-MS-Office365-Filtering-Correlation-Id: 2be6b663-a884-4de3-d462-08dd9f9651b4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|1800799024|376014|7416014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?5HT7V/TJEwTo2zZW0rM9ZsHJfQTrhquflzi9GU9aGf1bUgCnGmDpC0UHzee8?=
 =?us-ascii?Q?pOM2WYan0fj2+qk9LPK0OfOeEUDrkmkC6XOW7D+NvjN0+sUp1q11nxzlYlWR?=
 =?us-ascii?Q?KlgLCsM6FYGDxGH6Je8s9CQUAJRGAiGnDKt/C9Ts7WKzeqdBV5PqbLSn5+wN?=
 =?us-ascii?Q?E77VM/DTfaQ4azHEJVyxBE4dx5G0UIBzscS/irKaZfJk6XCerh6NEc2CTt9u?=
 =?us-ascii?Q?8G7w4se68aakL58PA5cRfLyJ5i/6zmd5Q38HxDtY0Iq/G7dl0leqUfGCs537?=
 =?us-ascii?Q?MvU3eS0snhRQPRaPWYO56Izc56vBkAd9Es5Y1xLvJzkCqj6s9cu+uZVZfoA3?=
 =?us-ascii?Q?9a6YKRlpECqk0eLV++maFZ3pMMm0LQMACiLADW7PCrqpm4P/qvSRI9agUVcd?=
 =?us-ascii?Q?cQHF+WJRpMRBHrnj/p+vGjMas1Rp8qNe2z2r9YtiHPGYrD5+XyVDoP3P1qG6?=
 =?us-ascii?Q?/7ZBIScpzdttNg04Z0GfRGjBkyxOmtzos/LZalUndL9e1+ZeuEPW629NN05S?=
 =?us-ascii?Q?BoUy4g3UfcURMfvQAgHx3V3yCjiMMXpkaVdFQsgh1hXBw71tocPmAGtTq2Vg?=
 =?us-ascii?Q?WomDLf0wg0N7hA+hmMppfCE0mZuoP8m4lURcOteJOLBuIvnTWS95iqk8I5CE?=
 =?us-ascii?Q?QY/z/zgICyKwS3I6so1Y+Y9hqcyWq0WONxg7JhRLfkwPRpaO3YA4hqMeXH5c?=
 =?us-ascii?Q?4B8baik83sep1jvilJ08XoH8JGf4wQw+jglLOviI7P131fcb6gRl06DPMKu4?=
 =?us-ascii?Q?QJv6tkntdUJiWrg+r98N8uNge2i/cns23u3nwKVLRR9bqPdFgWftRUgiWAKP?=
 =?us-ascii?Q?0/GHDnMK82RRo8ZsG8fbEeHGgxHqIRKdqg2Pg34CeTqbPbhc3pyjORRuiXZ/?=
 =?us-ascii?Q?NPNVYFWTFOAOdF4yyR+dgLA0ry85yFj6Rr7Q04DY5T1pK29Pejr/9WI02wF0?=
 =?us-ascii?Q?o/eoosvcKZCo5iI3zeQ+znaII/LAf9geILgq6FrziZ+Kr84hc7JLekYX+ZJM?=
 =?us-ascii?Q?MPPrNtI0oEKvyluhw4P7oO64JMm8FZFzT6y05VVvjZ2NgM77/mFlns9thl2Z?=
 =?us-ascii?Q?4ERLwjlqFKdJDy9nrHn9p48l+Q5NkrN1fgyR6RCYBGcRBasfRpd+zzBr7wIR?=
 =?us-ascii?Q?MsdKtyFV9RcgFRw2P6DEyaKseiWw22AIA3EXfdd0clK7muvMG+vPWy8m6fMm?=
 =?us-ascii?Q?EZQqVzAnuc6THMieZoiHoOtQH56c+NHHxnrjO4aqu82xikd89vozRKsgVip3?=
 =?us-ascii?Q?SD1APnFBr56N4gLpDgq3n31pq3YiyPizlJ8wD9OkQAJJm07BQ7BLqj4hL9Sf?=
 =?us-ascii?Q?I8cMLfJ+LLnCe2vhunntRdu1xEdCP5nJ2JaKsa8XyA8C/6KoI6GxQekc47+b?=
 =?us-ascii?Q?L5HTpm9Hw8AEUKXZPkdXHd5s0v1jAW74PUjZ65L25A7Tgj4TPnPEUPbMQR5S?=
 =?us-ascii?Q?CkWU6TSOH0o=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR10MB5777.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?1hbAFM/AdoIhAGVP9GYa+QS4ch2Ju6Gzvz8mraHPe2WuiBRp+TRJL2r5tnNB?=
 =?us-ascii?Q?E1S68gKbzsMvaUrRGC5g9ftvF6uvzt4FW5b4frY6NxSL89U3/l0tgiKmJhRr?=
 =?us-ascii?Q?y1Nxi2ot1qqklzX51nto8pOHTkrgMCPK6ERHyx6MATtP8Bbn8Bn2vFri/g6m?=
 =?us-ascii?Q?q69vKgWMsgNLJCgBF+eIpwndG8suSQPwFHot13QHnheLfbjbqLHgkBMLuRmb?=
 =?us-ascii?Q?JGOigdDO54+oGI9PzWrHzOm6Xtu7WEpG/nb/F92h3DVevnFYuGKMmlJR9MvX?=
 =?us-ascii?Q?MKtJz4B96qEMKOZ8lHe4x1e7PUtjmjLFwFPDzLgIhmwz5BhnRuJT6otzwChy?=
 =?us-ascii?Q?CcVBJn35OYnU1VM5CxLWMnhTU4HTssG0KMHmrKyP4PUt6LwV68MisX8x+1F7?=
 =?us-ascii?Q?4ia8ABoABeygTq8XQZ83pbBNLIX1oeFU/O6U0+40m2eJuRW8be/9nb16cOWl?=
 =?us-ascii?Q?0MDiFMEG9MpXssFit/FSBZgq8qK6iWaG8JnG6knJbg1W4mxpqquOClOGPpB8?=
 =?us-ascii?Q?ogdRHTh/69guyjLnXeMRTlWMYAlnEgxM1yc3qJ4YAowtUIcCDi4qVMQkP7sw?=
 =?us-ascii?Q?RRcgDbQcZgtpMlOxjMRDE39dV6ZcAldz+MHxKNEM2aXDPDkHTv9wapWJRaed?=
 =?us-ascii?Q?GtFHFHCyxjiZO1ETSgclLjMWWQI5svITQ2KMpNqmiAi45UN7O3WHTTNPhmIb?=
 =?us-ascii?Q?VKR1Enu50KtHh6IWaUeMBkPFB7ap8CfAjspDqZ48RQ3rBdLjlvFXoKC3x/gW?=
 =?us-ascii?Q?2232Dd+IIc5jmxHrWE7+1P1LW+jYqqH9rTcOOzS5XR+794m5uZcgsAfxYXO3?=
 =?us-ascii?Q?+lDPBSmDIa2xvumyC0HroxeJRNdrPz41ZrKrCpWkjKuaa+rnfarGIWOVKWCL?=
 =?us-ascii?Q?7LsYMP41LQdORi2iWCVkvE65lwGLQqHZRtRXZPM5KqH4kBzEwk+ChkYFm25W?=
 =?us-ascii?Q?pL17Zfmww4gniRB1/ZxQsGGYy49iGoKi9OtOrF1IEF72pFS8hLXxrbmD70SJ?=
 =?us-ascii?Q?ofPKg6fr5ZsnCothc8x7CUn0/7X3QQhFGG0X7nqhceXlDpv6k0W1uB0RL+z5?=
 =?us-ascii?Q?x+CCh+SNo5aJVbqoM3F7Z1VPTYOPw/n/wel+7yTQGM7WFkqxw2rkBS10qr9z?=
 =?us-ascii?Q?cEIJW6kFrTbrBitzMFj4recrAG81JYUgXRGPD8XlS8VHsNw2EeFxnLs2a65N?=
 =?us-ascii?Q?Cw7teRvrPnAg1PvGI6eagtk0xSgOAI3fpgX5nGgGjZmwXzOyninjcpJ7oVSY?=
 =?us-ascii?Q?ijcdetf46ChCV6ck2RzcGRNngvKw1s2AThJlJwU2qkf7biQGWLrO6SxO5V/+?=
 =?us-ascii?Q?eb+78lRA/K9GVUic4FACiyQ5JAenUJA3dSfiPjlETsetARZtQgFcKa0GykLR?=
 =?us-ascii?Q?iPFtSNQ3eghjHXfAiYgv2xCKM5+D3irz/Gq8XPPHGOm0SCOVzDaDk7EyXE06?=
 =?us-ascii?Q?McCEJxjaXTyrg56VOkd+WaS42dQJ6DVZIR0hnzbpIkaDGHa+sFW8JgAWv3G1?=
 =?us-ascii?Q?qKjNdX/o6zk27hcm8Yun0ChCUYyq22PQNE0Zg0XIQk5h/AjBdpnJL+gTIuDB?=
 =?us-ascii?Q?/QtHwlH6Iu8bHBFosP7fiU6991tCnfdU54ArLkd0?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	KBKr0pL5HgZGkOok8B5HfawQ6ctregPXPVEk5dUOaZlbBoHbLKDlIqatRX9hNxA86sQ443J+gwMIpQM09SIopc+UIwBlBzaxkTX/wqZPVbjhOhvFgE5DSyiXSIPswdjsZIT84BiTaDO6mtMAhSpJ3ZOsKtsAwbYpFEWKT4DNYmvddeQqVW+QTtjz69vO9afq903t/GwjIxzP4WZgIp3QHr4hNXMJEjTmENMVMi5cVkOJ2g8CA3TApIvLgfUZe9rTWajc6s6NfuSRFCZmNAS3vTGlcvCLOJCxFtQGcPqs6ZNLoAvDtBMk3mV2oSRFu8pTaXz05CTkakQU5/U0M9aCie7zq7OSJQ0x6nqFn+WpwedhTEesCgB1dcN4tANh+Jzzp5JLkmaG+hYnLZvdZjCHsfDF7T4BMluhtnRqQUTxD3ACSm2KyWG+znLXggy8DvFN+xlZ1/qOTtpfP9bGPbLWf8VnpdNAVDxs1kVx1f84JuEnI3KkijXSddsj3CgjhpOMy6GigmL+en3khWFpN/QQh8Wsbt0d0QWxegs9n+4sN7qUSgWPxYWJhqMQnPcY3h8PcLAUvNtiPFcfkeRJ8Y2VkubUxi87tQ1hW3Dvtj9C7qQ=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2be6b663-a884-4de3-d462-08dd9f9651b4
X-MS-Exchange-CrossTenant-AuthSource: PH0PR10MB5777.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 16:23:32.3861
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 4LQLNejlDYm4KVGqjMxTNaABALov65WQAJAG4Yi73QiAYLLQ1CukZoXCPD5VgxF5S61Bi+QsjDfanrNCC/F19A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB4218
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-05-30_07,2025-05-30_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 spamscore=0
 suspectscore=0 bulkscore=0 phishscore=0 mlxlogscore=999 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
 definitions=main-2505300145
X-Proofpoint-GUID: 22ulwtNqNm5tFI6AH-5TBf-qOW4Gyq_x
X-Proofpoint-ORIG-GUID: 22ulwtNqNm5tFI6AH-5TBf-qOW4Gyq_x
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDE0MyBTYWx0ZWRfX4HMZDLoR8DfV 37lOwoY4qz3TImL0+3UMQmzbvqkiwq5AxIlp9er8pJBSalRprWhESbEn1Q/dsfxN2wyzlKcZQMl DJariRI9Que0+Neq4NitZOpM6qOteaqH01fdiaa0vN2S5S+APAf+ug5Y2dKVMgNJk24iv2mmKkJ
 Im9ghpzjm0tg/uacEIm7QHnDCpHutQnm37vEGNTivF7ketd1GoNwVETEXtUbavJms3IvxmEX/QA 1drbnuCa5/h286riEXFucRQZTLKF4VbaPjNbvuQq+WqXdQWbhv7HT++wXaD896ORBVP+q8vb9Ro 06xurYb3f+IT6GGx205Iidq0NJp7eJJnJvYZKYhbkR+sD1Oprl3h6TktY8TbTdZ8l4Anb7lmX8y
 mdGyGB3Mwm4vpebfzRh+Xl47IsBlta80tNNMbhAX9+S1fip5IncFZlczjgSuHnsAILEt/+fL
X-Authority-Analysis: v=2.4 cv=c8qrQQ9l c=1 sm=1 tr=0 ts=6839db88 b=1 cx=c_pps a=zPCbziy225d3KhSqZt3L1A==:117 a=zPCbziy225d3KhSqZt3L1A==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=GoEa3M9JfhUA:10 a=7CQSdrXTAAAA:8 a=BttKmYIqwxqZfdoHdj4A:9 a=CjuIK1q_8ugA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 cc=ntf awl=host:13206

* Ryan Roberts  [250530 10:05]:
> Lazy mmu mode applies to the current task and permits pte modifications
> to be deferred and updated at a later time in a batch to improve
> performance. apply_to_page_range() calls its callback in lazy mmu mode
> and some of those callbacks call into the page allocator to either
> allocate or free pages.
> 
> This is problematic with CONFIG_DEBUG_PAGEALLOC because
> debug_pagealloc_[un]map_pages() calls the arch implementation of
> __kernel_map_pages() which must modify the ptes for the linear map.
> 
> There are two possibilities at this point:
> 
>  - If the arch implementation modifies the ptes directly without first
>    entering lazy mmu mode, the pte modifications may get deferred until
>    the existing lazy mmu mode is exited. This could result in taking
>    spurious faults for example.
> 
>  - If the arch implementation enters a nested lazy mmu mode before
>    modification of the ptes (many arches use apply_to_page_range()),
>    then the linear map updates will definitely be applied upon leaving
>    the inner lazy mmu mode. But because lazy mmu mode does not support
>    nesting, the remainder of the outer user is no longer in lazy mmu
>    mode and the optimization opportunity is lost.
> 
> So let's just ensure that the page allocator is never called from within
> lazy mmu mode. New "_nolazy" variants of apply_to_page_range() and
> apply_to_existing_page_range() are introduced which don't enter lazy mmu
> mode. Then users which need to call into the page allocator within their
> callback are updated to use the _nolazy variants.
> 
> Signed-off-by: Ryan Roberts 
> ---
>  include/linux/mm.h |  6 ++++++
>  kernel/bpf/arena.c |  6 +++---
>  mm/kasan/shadow.c  |  2 +-
>  mm/memory.c        | 54 +++++++++++++++++++++++++++++++++++-----------
>  4 files changed, 51 insertions(+), 17 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index e51dba8398f7..11cae6ce04ff 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3743,9 +3743,15 @@ static inline bool gup_can_follow_protnone(struct vm_area_struct *vma,
>  typedef int (*pte_fn_t)(pte_t *pte, unsigned long addr, void *data);
>  extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
>  			       unsigned long size, pte_fn_t fn, void *data);
> +extern int apply_to_page_range_nolazy(struct mm_struct *mm,
> +				      unsigned long address, unsigned long size,
> +				      pte_fn_t fn, void *data);

We are removing externs as things are edited, so probably drop them
here.

>  extern int apply_to_existing_page_range(struct mm_struct *mm,
>  				   unsigned long address, unsigned long size,
>  				   pte_fn_t fn, void *data);
> +extern int apply_to_existing_page_range_nolazy(struct mm_struct *mm,
> +				   unsigned long address, unsigned long size,
> +				   pte_fn_t fn, void *data);
>  
>  #ifdef CONFIG_PAGE_POISONING
>  extern void __kernel_poison_pages(struct page *page, int numpages);
> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
> index 0d56cea71602..ca833cfeefb7 100644
> --- a/kernel/bpf/arena.c
> +++ b/kernel/bpf/arena.c
> @@ -187,10 +187,10 @@ static void arena_map_free(struct bpf_map *map)
>  	/*
>  	 * free_vm_area() calls remove_vm_area() that calls free_unmap_vmap_area().
>  	 * It unmaps everything from vmalloc area and clears pgtables.
> -	 * Call apply_to_existing_page_range() first to find populated ptes and
> -	 * free those pages.
> +	 * Call apply_to_existing_page_range_nolazy() first to find populated
> +	 * ptes and free those pages.
>  	 */
> -	apply_to_existing_page_range(&init_mm, bpf_arena_get_kern_vm_start(arena),
> +	apply_to_existing_page_range_nolazy(&init_mm, bpf_arena_get_kern_vm_start(arena),
>  				     KERN_VM_SZ - GUARD_SZ, existing_page_cb, NULL);
>  	free_vm_area(arena->kern_vm);
>  	range_tree_destroy(&arena->rt);
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index d2c70cd2afb1..2325c5166c3a 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -590,7 +590,7 @@ void kasan_release_vmalloc(unsigned long start, unsigned long end,
>  
>  
>  		if (flags & KASAN_VMALLOC_PAGE_RANGE)
> -			apply_to_existing_page_range(&init_mm,
> +			apply_to_existing_page_range_nolazy(&init_mm,
>  					     (unsigned long)shadow_start,
>  					     size, kasan_depopulate_vmalloc_pte,
>  					     NULL);
> diff --git a/mm/memory.c b/mm/memory.c
> index 49199410805c..24436074ce48 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2913,7 +2913,7 @@ EXPORT_SYMBOL(vm_iomap_memory);
>  static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  				     unsigned long addr, unsigned long end,
>  				     pte_fn_t fn, void *data, bool create,
> -				     pgtbl_mod_mask *mask)
> +				     pgtbl_mod_mask *mask, bool lazy_mmu)
>  {
>  	pte_t *pte, *mapped_pte;
>  	int err = 0;
> @@ -2933,7 +2933,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  			return -EINVAL;
>  	}
>  
> -	arch_enter_lazy_mmu_mode();
> +	if (lazy_mmu)
> +		arch_enter_lazy_mmu_mode();
>  
>  	if (fn) {
>  		do {
> @@ -2946,7 +2947,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  	}
>  	*mask |= PGTBL_PTE_MODIFIED;
>  
> -	arch_leave_lazy_mmu_mode();
> +	if (lazy_mmu)
> +		arch_leave_lazy_mmu_mode();
>  
>  	if (mm != &init_mm)
>  		pte_unmap_unlock(mapped_pte, ptl);
> @@ -2956,7 +2958,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
>  				     unsigned long addr, unsigned long end,
>  				     pte_fn_t fn, void *data, bool create,
> -				     pgtbl_mod_mask *mask)
> +				     pgtbl_mod_mask *mask, bool lazy_mmu)

I am having a hard time understanding why other lazy mmus were more
self-contained, but arm has added arguments to generic code?

>  {
>  	pmd_t *pmd;
>  	unsigned long next;
> @@ -2983,7 +2985,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
>  			pmd_clear_bad(pmd);
>  		}
>  		err = apply_to_pte_range(mm, pmd, addr, next,
> -					 fn, data, create, mask);
> +					 fn, data, create, mask, lazy_mmu);
>  		if (err)
>  			break;
>  	} while (pmd++, addr = next, addr != end);
> @@ -2994,7 +2996,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
>  static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
>  				     unsigned long addr, unsigned long end,
>  				     pte_fn_t fn, void *data, bool create,
> -				     pgtbl_mod_mask *mask)
> +				     pgtbl_mod_mask *mask, bool lazy_mmu)
>  {
>  	pud_t *pud;
>  	unsigned long next;
> @@ -3019,7 +3021,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
>  			pud_clear_bad(pud);
>  		}
>  		err = apply_to_pmd_range(mm, pud, addr, next,
> -					 fn, data, create, mask);
> +					 fn, data, create, mask, lazy_mmu);
>  		if (err)
>  			break;
>  	} while (pud++, addr = next, addr != end);
> @@ -3030,7 +3032,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
>  static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd,
>  				     unsigned long addr, unsigned long end,
>  				     pte_fn_t fn, void *data, bool create,
> -				     pgtbl_mod_mask *mask)
> +				     pgtbl_mod_mask *mask, bool lazy_mmu)
>  {
>  	p4d_t *p4d;
>  	unsigned long next;
> @@ -3055,7 +3057,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd,
>  			p4d_clear_bad(p4d);
>  		}
>  		err = apply_to_pud_range(mm, p4d, addr, next,
> -					 fn, data, create, mask);
> +					 fn, data, create, mask, lazy_mmu);
>  		if (err)
>  			break;
>  	} while (p4d++, addr = next, addr != end);
> @@ -3065,7 +3067,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd,
>  
>  static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr,
>  				 unsigned long size, pte_fn_t fn,
> -				 void *data, bool create)
> +				 void *data, bool create, bool lazy_mmu)
>  {
>  	pgd_t *pgd;
>  	unsigned long start = addr, next;
> @@ -3091,7 +3093,7 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr,
>  			pgd_clear_bad(pgd);
>  		}
>  		err = apply_to_p4d_range(mm, pgd, addr, next,
> -					 fn, data, create, &mask);
> +					 fn, data, create, &mask, lazy_mmu);

This is annoying.  We now have a bool, bool passed through with mask
inserted in the middle.

>  		if (err)
>  			break;
>  	} while (pgd++, addr = next, addr != end);
> @@ -3105,11 +3107,14 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr,
>  /*
>   * Scan a region of virtual memory, filling in page tables as necessary
>   * and calling a provided function on each leaf page table.
> + *
> + * fn() is called in lazy mmu mode. As a result, the callback must be careful
> + * not to perform memory allocation.
>   */
>  int apply_to_page_range(struct mm_struct *mm, unsigned long addr,
>  			unsigned long size, pte_fn_t fn, void *data)
>  {
> -	return __apply_to_page_range(mm, addr, size, fn, data, true);
> +	return __apply_to_page_range(mm, addr, size, fn, data, true, true);

Please add something here to tell me what false, true is.

>  }
>  EXPORT_SYMBOL_GPL(apply_to_page_range);
>  
> @@ -3117,13 +3122,36 @@ EXPORT_SYMBOL_GPL(apply_to_page_range);
>   * Scan a region of virtual memory, calling a provided function on
>   * each leaf page table where it exists.
>   *
> + * fn() is called in lazy mmu mode. As a result, the callback must be careful
> + * not to perform memory allocation.
> + *
>   * Unlike apply_to_page_range, this does _not_ fill in page tables
>   * where they are absent.
>   */
>  int apply_to_existing_page_range(struct mm_struct *mm, unsigned long addr,
>  				 unsigned long size, pte_fn_t fn, void *data)
>  {
> -	return __apply_to_page_range(mm, addr, size, fn, data, false);
> +	return __apply_to_page_range(mm, addr, size, fn, data, false, true);

every..

> +}
> +
> +/*
> + * As per apply_to_page_range() but fn() is not called in lazy mmu mode.
> + */
> +int apply_to_page_range_nolazy(struct mm_struct *mm, unsigned long addr,
> +			       unsigned long size, pte_fn_t fn, void *data)
> +{
> +	return __apply_to_page_range(mm, addr, size, fn, data, true, false);

one...

> +}
> +
> +/*
> + * As per apply_to_existing_page_range() but fn() is not called in lazy mmu
> + * mode.
> + */
> +int apply_to_existing_page_range_nolazy(struct mm_struct *mm,
> +					unsigned long addr, unsigned long size,
> +					pte_fn_t fn, void *data)
> +{
> +	return __apply_to_page_range(mm, addr, size, fn, data, false, false);

adds confusion :)


These wrappers are terrible for readability and annoying for argument
lists too.

Could we do something like the pgtbl_mod_mask or zap_details and pass
through a struct or one unsigned int for create and lazy_mmu?

At least we'd have better self-documenting code in the wrappers.. and if
we ever need a third boolean, we could avoid multiplying the wrappers
again.

WDYT?

Cheers,
Liam


From xen-devel-bounces@lists.xenproject.org Fri May 30 16:45:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 16:45:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001413.1381573 (Exim 4.92)
	(envelope-from )
	id 1uL2rb-000266-71; Fri, 30 May 2025 16:45:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001413.1381573; Fri, 30 May 2025 16:45:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL2rb-00025z-4b; Fri, 30 May 2025 16:45:47 +0000
Received: by outflank-mailman (input) for mailman id 1001413;
 Fri, 30 May 2025 16:45:45 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL2rZ-00025t-Pk
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 16:45:45 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 84799d89-3d75-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 18:45:39 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 366C71692;
 Fri, 30 May 2025 09:45:22 -0700 (PDT)
Received: from [10.57.95.14] (unknown [10.57.95.14])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CC2B43F673;
 Fri, 30 May 2025 09:45: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" 
X-Inumbo-ID: 84799d89-3d75-11f0-b894-0df219b8e170
Message-ID: 
Date: Fri, 30 May 2025 17:45:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v1 1/6] fs/proc/task_mmu: Fix pte update and tlb
 maintenance ordering in pagemap_scan_pmd_entry()
Content-Language: en-GB
To: Jann Horn 
Cc: Catalin Marinas , Will Deacon ,
 Madhavan Srinivasan ,
 Michael Ellerman , Nicholas Piggin ,
 Christophe Leroy ,
 "David S. Miller" ,
 Andreas Larsson , Juergen Gross ,
 Ajay Kaher ,
 Alexey Makhalov ,
 Thomas Gleixner , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky ,
 "Aneesh Kumar K.V" ,
 Andrew Morton ,
 Peter Zijlstra , Arnd Bergmann ,
 David Hildenbrand ,
 Lorenzo Stoakes ,
 "Liam R. Howlett" , Vlastimil Babka
 , Mike Rapoport ,
 Suren Baghdasaryan , Michal Hocko ,
 Alexei Starovoitov , Andrey Ryabinin
 , linux-arm-kernel@lists.infradead.org,
 linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, virtualization@lists.linux.dev,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org,
 Andy Lutomirski 
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
 <20250530140446.2387131-2-ryan.roberts@arm.com>
 
From: Ryan Roberts 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 30/05/2025 17:26, Jann Horn wrote:
> On Fri, May 30, 2025 at 4:04 PM Ryan Roberts  wrote:
>> pagemap_scan_pmd_entry() was previously modifying ptes while in lazy mmu
>> mode, then performing tlb maintenance for the modified ptes, then
>> leaving lazy mmu mode. But any pte modifications during lazy mmu mode
>> may be deferred until arch_leave_lazy_mmu_mode(), inverting the required
>> ordering between pte modificaiton and tlb maintenance.
>>
>> Let's fix that by leaving mmu mode, forcing all the pte updates to be
>> actioned, before doing the tlb maintenance.
>>
>> This is a theorectical bug discovered during code review.
>>
>> Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs")
> 
> Hmm... isn't lazy mmu mode supposed to also delay TLB flushes, and
> preserve the ordering of PTE modifications and TLB flushes?
> 
> Looking at the existing implementations of lazy MMU:
> 
>  - In Xen PV implementation of lazy MMU, I see that TLB flush
> hypercalls are delayed as well (xen_flush_tlb(),
> xen_flush_tlb_one_user() and xen_flush_tlb_multi() all use
> xen_mc_issue(XEN_LAZY_MMU) which delays issuing if lazymmu is active).
>  - The sparc version also seems to delay TLB flushes, and sparc's
> arch_leave_lazy_mmu_mode() seems to do TLB flushes via
> flush_tlb_pending() if necessary.
>  - powerpc's arch_leave_lazy_mmu_mode() also seems to do TLB flushes.
> 
> Am I missing something?

I doubt it. I suspect this was just my misunderstanding then. I hadn't
appreciated that lazy mmu is also guarranteed to maintain flush ordering; it's
chronically under-documented. Sorry for the noise here. On that basis, I expect
the first 2 patches can definitely be dropped.

> 
> If arm64 requires different semantics compared to all existing
> implementations and doesn't delay TLB flushes for lazy mmu mode, I
> think the "Fixes" tag should point to your addition of lazy mmu
> support for arm64.

arm64 doesn't require different semantics. arm64 is using lazy mmu in a very
limited manner and it can already tolerate the current code.

I just spotted this during code review and was trying to be a good citizen.
Thanks for setting me straight!

Thanks,
Ryan

> 
>> Signed-off-by: Ryan Roberts 
>> ---
>>  fs/proc/task_mmu.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> index 994cde10e3f4..361f3ffd9a0c 100644
>> --- a/fs/proc/task_mmu.c
>> +++ b/fs/proc/task_mmu.c
>> @@ -2557,10 +2557,9 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
>>         }
>>
>>  flush_and_return:
>> +       arch_leave_lazy_mmu_mode();
>>         if (flush_end)
>>                 flush_tlb_range(vma, start, addr);
>> -
>> -       arch_leave_lazy_mmu_mode();
> 
> I think this ordering was probably intentional, because doing it this
> way around allows Xen PV to avoid one more hypercall, because the TLB
> flush can be batched together with the page table changes?
> 
> 
>>         pte_unmap_unlock(start_pte, ptl);
>>
>>         cond_resched();
>> --
>> 2.43.0
>>



From xen-devel-bounces@lists.xenproject.org Fri May 30 16:48:45 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 16:48:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001425.1381584 (Exim 4.92)
	(envelope-from )
	id 1uL2uR-0002gK-OD; Fri, 30 May 2025 16:48:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001425.1381584; Fri, 30 May 2025 16:48: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 1uL2uR-0002gD-L5; Fri, 30 May 2025 16:48:43 +0000
Received: by outflank-mailman (input) for mailman id 1001425;
 Fri, 30 May 2025 16:48:42 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL2uQ-0002g7-9c
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 16:48:42 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f0746fdd-3d75-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 18:48:40 +0200 (CEST)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-6000791e832so101a12.1
 for ; Fri, 30 May 2025 09: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" 
X-Inumbo-ID: f0746fdd-3d75-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20230601; t=1748623720; x=1749228520; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SfmVEdWuub4CI3JVXdpcy9od0u589O5saOKcmY0n2jY=;
        b=UWf8PWu3O4kB9UlbrGO0Dhe/VbvBrlJoSkE9/7Rhvx6uZSg7YT5BaU6meohCeLn6Ha
         YR6s6J6hGhyC0HFMM6/Z+zV2QSG96l7jjwmV1p0oOggHcnsY0OLvMS9ToaJixZl1K/27
         dp53uXxatDz6iaz84B4ynhPjWCMopcIyz8RLFS+r4fiG+5V8FBMhytldS960j2C3ahvW
         l/HQE+z2OCto/46xrMNBWv21Rdt8opDmwxiqs6MZV827exRPO0WL+HHPv/W0soKSSAtX
         /7mUNwMzF07lI7/JNU5qWZOaJqMH7Mq7aAeJyOqmv1FYcGESL2VGU8r3ZcAMnOkbvMhO
         BL9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748623720; x=1749228520;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=SfmVEdWuub4CI3JVXdpcy9od0u589O5saOKcmY0n2jY=;
        b=m/nXcRNSPZFFD1bOfMftPFBNiLGnv+qUblnSTA12QhF19nxstJ2JICUt+HJqA28yyS
         9ZsN+dA2tyhBep1hccz33VVE5zQtkpJ/yAn9RElDDMDwJGsMN4I8AE24vnUQV0zFwrA0
         gYcxgRLhGcGTima0wSrCuHJImdIwPZ1c+clJGWCCOp/gbUYBRlz7bRBhupyzXTHeT+Wu
         yauMn2yZt10ts/HyW94rPj1zhD5pb8DDJlgTXhKpct22pUqU+wyRwCOPmu8j2NmucD66
         bUbhUpMN9cvrcoQnip9fjuiZ4/I0X0j3CxBtpstA4qrm1UT1MP2auK5KaJO14kHpBXz9
         j78g==
X-Forwarded-Encrypted: i=1; AJvYcCVggwFn0PeSE2Pev9Br7k5a8iptlbKMEc9K+4YHrEndPikVmusIT/TgtsbexpCXxZ0M6naeJ8VrqyM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwnEAmKz2uJz/egXlCeKD/j85oEFEZ/LGzj/m1lWuo6HSVzQzKy
	2SOmRQznUW1osBD/AIYhvjj32ZO3qYiMpbwBPhj34kcRxuAvS5mNt01ZQNuXGIQtgftGB64wHAU
	O8uQenceuYkLFJHO8AREa8CxyaB/3jhi2w0rf43mt
X-Gm-Gg: ASbGncsj/5ZXxzfMXxbTiBfjaCgBuUPcFObikr+bO9C/+BzEGEZWadsaIbYJanaAMFZ
	LlYAbGcy/rnQX/JCpxIn7Ch+EFXLm04KXykUUrESA9SYiSdJ+o6sZffaI4mi9Q4V9DE8zTXhzyw
	qldmveCLbu8DfjZpJiIq28xTYSz8mF++EONJpmZl7q+5jk7Xm2ztPvVQ1Anq3uHF2yJj8W+ZUUM
	wf9g5EBfQ==
X-Google-Smtp-Source: AGHT+IE4j04MEyqUQCgfbrapQs0vaUyWF/djR96KweNRHT1cvPKfDr7hIyG719V7LSGCiiciPXhWHE48ON6aHoH7Fnc=
X-Received: by 2002:a50:d781:0:b0:601:7b94:b80e with SMTP id
 4fb4d7f45d1cf-60577a3ffadmr87988a12.3.1748623719573; Fri, 30 May 2025
 09:48:39 -0700 (PDT)
MIME-Version: 1.0
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
 <20250530140446.2387131-2-ryan.roberts@arm.com> 
 
In-Reply-To: 
From: Jann Horn 
Date: Fri, 30 May 2025 18:48:03 +0200
X-Gm-Features: AX0GCFuAT1zEtvLEHv4Z2Un3xyWjY8-HX0RQ4IFigWsX-k02Th9HNwh8AhT-yZ8
Message-ID: 
Subject: Re: [RFC PATCH v1 1/6] fs/proc/task_mmu: Fix pte update and tlb
 maintenance ordering in pagemap_scan_pmd_entry()
To: Ryan Roberts 
Cc: Catalin Marinas , Will Deacon , 
	Madhavan Srinivasan , Michael Ellerman , 
	Nicholas Piggin , Christophe Leroy , 
	"David S. Miller" , Andreas Larsson , 
	Juergen Gross , Ajay Kaher , 
	Alexey Makhalov , Thomas Gleixner , 
	Ingo Molnar , Borislav Petkov , 
	Dave Hansen , "H. Peter Anvin" , 
	Boris Ostrovsky , "Aneesh Kumar K.V" , 
	Andrew Morton , Peter Zijlstra , 
	Arnd Bergmann , David Hildenbrand , 
	Lorenzo Stoakes , "Liam R. Howlett" , 
	Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , 
	Michal Hocko , Alexei Starovoitov , 
	Andrey Ryabinin , linux-arm-kernel@lists.infradead.org, 
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	sparclinux@vger.kernel.org, virtualization@lists.linux.dev, 
	xen-devel@lists.xenproject.org, linux-mm@kvack.org, 
	Andy Lutomirski 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 30, 2025 at 6:45=E2=80=AFPM Ryan Roberts =
 wrote:
> On 30/05/2025 17:26, Jann Horn wrote:
> > On Fri, May 30, 2025 at 4:04=E2=80=AFPM Ryan Roberts  wrote:
> >> pagemap_scan_pmd_entry() was previously modifying ptes while in lazy m=
mu
> >> mode, then performing tlb maintenance for the modified ptes, then
> >> leaving lazy mmu mode. But any pte modifications during lazy mmu mode
> >> may be deferred until arch_leave_lazy_mmu_mode(), inverting the requir=
ed
> >> ordering between pte modificaiton and tlb maintenance.
> >>
> >> Let's fix that by leaving mmu mode, forcing all the pte updates to be
> >> actioned, before doing the tlb maintenance.
> >>
> >> This is a theorectical bug discovered during code review.
> >>
> >> Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and opt=
ionally clear info about PTEs")
> >
> > Hmm... isn't lazy mmu mode supposed to also delay TLB flushes, and
> > preserve the ordering of PTE modifications and TLB flushes?
> >
> > Looking at the existing implementations of lazy MMU:
> >
> >  - In Xen PV implementation of lazy MMU, I see that TLB flush
> > hypercalls are delayed as well (xen_flush_tlb(),
> > xen_flush_tlb_one_user() and xen_flush_tlb_multi() all use
> > xen_mc_issue(XEN_LAZY_MMU) which delays issuing if lazymmu is active).
> >  - The sparc version also seems to delay TLB flushes, and sparc's
> > arch_leave_lazy_mmu_mode() seems to do TLB flushes via
> > flush_tlb_pending() if necessary.
> >  - powerpc's arch_leave_lazy_mmu_mode() also seems to do TLB flushes.
> >
> > Am I missing something?
>
> I doubt it. I suspect this was just my misunderstanding then. I hadn't
> appreciated that lazy mmu is also guarranteed to maintain flush ordering;=
 it's
> chronically under-documented. Sorry for the noise here. On that basis, I =
expect
> the first 2 patches can definitely be dropped.

Yeah looking at this code I agree that it could use significantly more
verbose comments on the API contract.


From xen-devel-bounces@lists.xenproject.org Fri May 30 16:50:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 16:50:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001432.1381594 (Exim 4.92)
	(envelope-from )
	id 1uL2wZ-0004GZ-3F; Fri, 30 May 2025 16:50:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001432.1381594; Fri, 30 May 2025 16:50: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 1uL2wY-0004GS-W1; Fri, 30 May 2025 16:50:54 +0000
Received: by outflank-mailman (input) for mailman id 1001432;
 Fri, 30 May 2025 16:50:54 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL2wX-0004F0-SF
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 16:50:53 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 3e93c5c0-3d76-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 18:50:51 +0200 (CEST)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 63DD81692;
 Fri, 30 May 2025 09:50:34 -0700 (PDT)
Received: from [10.57.95.14] (unknown [10.57.95.14])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4A56B3F673;
 Fri, 30 May 2025 09:50:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3e93c5c0-3d76-11f0-b894-0df219b8e170
Message-ID: 
Date: Fri, 30 May 2025 17:50:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v1 3/6] mm: Avoid calling page allocator from
 apply_to_page_range()
Content-Language: en-GB
To: "Liam R. Howlett" ,
 Catalin Marinas , Will Deacon ,
 Madhavan Srinivasan ,
 Michael Ellerman , Nicholas Piggin ,
 Christophe Leroy ,
 "David S. Miller" ,
 Andreas Larsson , Juergen Gross ,
 Ajay Kaher ,
 Alexey Makhalov ,
 Thomas Gleixner , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 "H. Peter Anvin" ,
 Boris Ostrovsky ,
 "Aneesh Kumar K.V" ,
 Andrew Morton ,
 Peter Zijlstra , Arnd Bergmann ,
 David Hildenbrand ,
 Lorenzo Stoakes ,
 Vlastimil Babka , Mike Rapoport ,
 Suren Baghdasaryan , Michal Hocko ,
 Alexei Starovoitov , Andrey Ryabinin
 , linux-arm-kernel@lists.infradead.org,
 linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
 sparclinux@vger.kernel.org, virtualization@lists.linux.dev,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
 <20250530140446.2387131-4-ryan.roberts@arm.com>
 <6nf3cxwhij7jtfi2u6nmt4igezf754gmue5dfskn4jkfkxmjzr@7btdipzmzjuo>
From: Ryan Roberts 
In-Reply-To: <6nf3cxwhij7jtfi2u6nmt4igezf754gmue5dfskn4jkfkxmjzr@7btdipzmzjuo>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30/05/2025 17:23, Liam R. Howlett wrote:
> * Ryan Roberts  [250530 10:05]:
>> Lazy mmu mode applies to the current task and permits pte modifications
>> to be deferred and updated at a later time in a batch to improve
>> performance. apply_to_page_range() calls its callback in lazy mmu mode
>> and some of those callbacks call into the page allocator to either
>> allocate or free pages.
>>
>> This is problematic with CONFIG_DEBUG_PAGEALLOC because
>> debug_pagealloc_[un]map_pages() calls the arch implementation of
>> __kernel_map_pages() which must modify the ptes for the linear map.
>>
>> There are two possibilities at this point:
>>
>>  - If the arch implementation modifies the ptes directly without first
>>    entering lazy mmu mode, the pte modifications may get deferred until
>>    the existing lazy mmu mode is exited. This could result in taking
>>    spurious faults for example.
>>
>>  - If the arch implementation enters a nested lazy mmu mode before
>>    modification of the ptes (many arches use apply_to_page_range()),
>>    then the linear map updates will definitely be applied upon leaving
>>    the inner lazy mmu mode. But because lazy mmu mode does not support
>>    nesting, the remainder of the outer user is no longer in lazy mmu
>>    mode and the optimization opportunity is lost.
>>
>> So let's just ensure that the page allocator is never called from within
>> lazy mmu mode. New "_nolazy" variants of apply_to_page_range() and
>> apply_to_existing_page_range() are introduced which don't enter lazy mmu
>> mode. Then users which need to call into the page allocator within their
>> callback are updated to use the _nolazy variants.
>>
>> Signed-off-by: Ryan Roberts 
>> ---
>>  include/linux/mm.h |  6 ++++++
>>  kernel/bpf/arena.c |  6 +++---
>>  mm/kasan/shadow.c  |  2 +-
>>  mm/memory.c        | 54 +++++++++++++++++++++++++++++++++++-----------
>>  4 files changed, 51 insertions(+), 17 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index e51dba8398f7..11cae6ce04ff 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -3743,9 +3743,15 @@ static inline bool gup_can_follow_protnone(struct vm_area_struct *vma,
>>  typedef int (*pte_fn_t)(pte_t *pte, unsigned long addr, void *data);
>>  extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
>>  			       unsigned long size, pte_fn_t fn, void *data);
>> +extern int apply_to_page_range_nolazy(struct mm_struct *mm,
>> +				      unsigned long address, unsigned long size,
>> +				      pte_fn_t fn, void *data);
> 
> We are removing externs as things are edited, so probably drop them
> here.

ACK

> 
>>  extern int apply_to_existing_page_range(struct mm_struct *mm,
>>  				   unsigned long address, unsigned long size,
>>  				   pte_fn_t fn, void *data);
>> +extern int apply_to_existing_page_range_nolazy(struct mm_struct *mm,
>> +				   unsigned long address, unsigned long size,
>> +				   pte_fn_t fn, void *data);
>>  
>>  #ifdef CONFIG_PAGE_POISONING
>>  extern void __kernel_poison_pages(struct page *page, int numpages);
>> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
>> index 0d56cea71602..ca833cfeefb7 100644
>> --- a/kernel/bpf/arena.c
>> +++ b/kernel/bpf/arena.c
>> @@ -187,10 +187,10 @@ static void arena_map_free(struct bpf_map *map)
>>  	/*
>>  	 * free_vm_area() calls remove_vm_area() that calls free_unmap_vmap_area().
>>  	 * It unmaps everything from vmalloc area and clears pgtables.
>> -	 * Call apply_to_existing_page_range() first to find populated ptes and
>> -	 * free those pages.
>> +	 * Call apply_to_existing_page_range_nolazy() first to find populated
>> +	 * ptes and free those pages.
>>  	 */
>> -	apply_to_existing_page_range(&init_mm, bpf_arena_get_kern_vm_start(arena),
>> +	apply_to_existing_page_range_nolazy(&init_mm, bpf_arena_get_kern_vm_start(arena),
>>  				     KERN_VM_SZ - GUARD_SZ, existing_page_cb, NULL);
>>  	free_vm_area(arena->kern_vm);
>>  	range_tree_destroy(&arena->rt);
>> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
>> index d2c70cd2afb1..2325c5166c3a 100644
>> --- a/mm/kasan/shadow.c
>> +++ b/mm/kasan/shadow.c
>> @@ -590,7 +590,7 @@ void kasan_release_vmalloc(unsigned long start, unsigned long end,
>>  
>>  
>>  		if (flags & KASAN_VMALLOC_PAGE_RANGE)
>> -			apply_to_existing_page_range(&init_mm,
>> +			apply_to_existing_page_range_nolazy(&init_mm,
>>  					     (unsigned long)shadow_start,
>>  					     size, kasan_depopulate_vmalloc_pte,
>>  					     NULL);
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 49199410805c..24436074ce48 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -2913,7 +2913,7 @@ EXPORT_SYMBOL(vm_iomap_memory);
>>  static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>>  				     unsigned long addr, unsigned long end,
>>  				     pte_fn_t fn, void *data, bool create,
>> -				     pgtbl_mod_mask *mask)
>> +				     pgtbl_mod_mask *mask, bool lazy_mmu)
>>  {
>>  	pte_t *pte, *mapped_pte;
>>  	int err = 0;
>> @@ -2933,7 +2933,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>>  			return -EINVAL;
>>  	}
>>  
>> -	arch_enter_lazy_mmu_mode();
>> +	if (lazy_mmu)
>> +		arch_enter_lazy_mmu_mode();
>>  
>>  	if (fn) {
>>  		do {
>> @@ -2946,7 +2947,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>>  	}
>>  	*mask |= PGTBL_PTE_MODIFIED;
>>  
>> -	arch_leave_lazy_mmu_mode();
>> +	if (lazy_mmu)
>> +		arch_leave_lazy_mmu_mode();
>>  
>>  	if (mm != &init_mm)
>>  		pte_unmap_unlock(mapped_pte, ptl);
>> @@ -2956,7 +2958,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>>  static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
>>  				     unsigned long addr, unsigned long end,
>>  				     pte_fn_t fn, void *data, bool create,
>> -				     pgtbl_mod_mask *mask)
>> +				     pgtbl_mod_mask *mask, bool lazy_mmu)
> 
> I am having a hard time understanding why other lazy mmus were more
> self-contained, but arm has added arguments to generic code?

They are not; as I explain in the cover letter, arm64 can work with the code as
it is today, but IMHO opinion it is very fragile and this is an attempt to
reduce the fragility (for all).

> 
>>  {
>>  	pmd_t *pmd;
>>  	unsigned long next;
>> @@ -2983,7 +2985,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
>>  			pmd_clear_bad(pmd);
>>  		}
>>  		err = apply_to_pte_range(mm, pmd, addr, next,
>> -					 fn, data, create, mask);
>> +					 fn, data, create, mask, lazy_mmu);
>>  		if (err)
>>  			break;
>>  	} while (pmd++, addr = next, addr != end);
>> @@ -2994,7 +2996,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
>>  static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
>>  				     unsigned long addr, unsigned long end,
>>  				     pte_fn_t fn, void *data, bool create,
>> -				     pgtbl_mod_mask *mask)
>> +				     pgtbl_mod_mask *mask, bool lazy_mmu)
>>  {
>>  	pud_t *pud;
>>  	unsigned long next;
>> @@ -3019,7 +3021,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
>>  			pud_clear_bad(pud);
>>  		}
>>  		err = apply_to_pmd_range(mm, pud, addr, next,
>> -					 fn, data, create, mask);
>> +					 fn, data, create, mask, lazy_mmu);
>>  		if (err)
>>  			break;
>>  	} while (pud++, addr = next, addr != end);
>> @@ -3030,7 +3032,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
>>  static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd,
>>  				     unsigned long addr, unsigned long end,
>>  				     pte_fn_t fn, void *data, bool create,
>> -				     pgtbl_mod_mask *mask)
>> +				     pgtbl_mod_mask *mask, bool lazy_mmu)
>>  {
>>  	p4d_t *p4d;
>>  	unsigned long next;
>> @@ -3055,7 +3057,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd,
>>  			p4d_clear_bad(p4d);
>>  		}
>>  		err = apply_to_pud_range(mm, p4d, addr, next,
>> -					 fn, data, create, mask);
>> +					 fn, data, create, mask, lazy_mmu);
>>  		if (err)
>>  			break;
>>  	} while (p4d++, addr = next, addr != end);
>> @@ -3065,7 +3067,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd,
>>  
>>  static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr,
>>  				 unsigned long size, pte_fn_t fn,
>> -				 void *data, bool create)
>> +				 void *data, bool create, bool lazy_mmu)
>>  {
>>  	pgd_t *pgd;
>>  	unsigned long start = addr, next;
>> @@ -3091,7 +3093,7 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr,
>>  			pgd_clear_bad(pgd);
>>  		}
>>  		err = apply_to_p4d_range(mm, pgd, addr, next,
>> -					 fn, data, create, &mask);
>> +					 fn, data, create, &mask, lazy_mmu);
> 
> This is annoying.  We now have a bool, bool passed through with mask
> inserted in the middle.
> 
>>  		if (err)
>>  			break;
>>  	} while (pgd++, addr = next, addr != end);
>> @@ -3105,11 +3107,14 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr,
>>  /*
>>   * Scan a region of virtual memory, filling in page tables as necessary
>>   * and calling a provided function on each leaf page table.
>> + *
>> + * fn() is called in lazy mmu mode. As a result, the callback must be careful
>> + * not to perform memory allocation.
>>   */
>>  int apply_to_page_range(struct mm_struct *mm, unsigned long addr,
>>  			unsigned long size, pte_fn_t fn, void *data)
>>  {
>> -	return __apply_to_page_range(mm, addr, size, fn, data, true);
>> +	return __apply_to_page_range(mm, addr, size, fn, data, true, true);
> 
> Please add something here to tell me what false, true is.
> 
>>  }
>>  EXPORT_SYMBOL_GPL(apply_to_page_range);
>>  
>> @@ -3117,13 +3122,36 @@ EXPORT_SYMBOL_GPL(apply_to_page_range);
>>   * Scan a region of virtual memory, calling a provided function on
>>   * each leaf page table where it exists.
>>   *
>> + * fn() is called in lazy mmu mode. As a result, the callback must be careful
>> + * not to perform memory allocation.
>> + *
>>   * Unlike apply_to_page_range, this does _not_ fill in page tables
>>   * where they are absent.
>>   */
>>  int apply_to_existing_page_range(struct mm_struct *mm, unsigned long addr,
>>  				 unsigned long size, pte_fn_t fn, void *data)
>>  {
>> -	return __apply_to_page_range(mm, addr, size, fn, data, false);
>> +	return __apply_to_page_range(mm, addr, size, fn, data, false, true);
> 
> every..
> 
>> +}
>> +
>> +/*
>> + * As per apply_to_page_range() but fn() is not called in lazy mmu mode.
>> + */
>> +int apply_to_page_range_nolazy(struct mm_struct *mm, unsigned long addr,
>> +			       unsigned long size, pte_fn_t fn, void *data)
>> +{
>> +	return __apply_to_page_range(mm, addr, size, fn, data, true, false);
> 
> one...
> 
>> +}
>> +
>> +/*
>> + * As per apply_to_existing_page_range() but fn() is not called in lazy mmu
>> + * mode.
>> + */
>> +int apply_to_existing_page_range_nolazy(struct mm_struct *mm,
>> +					unsigned long addr, unsigned long size,
>> +					pte_fn_t fn, void *data)
>> +{
>> +	return __apply_to_page_range(mm, addr, size, fn, data, false, false);
> 
> adds confusion :)
> 
> 
> These wrappers are terrible for readability and annoying for argument
> lists too.

Agreed.

> 
> Could we do something like the pgtbl_mod_mask or zap_details and pass
> through a struct or one unsigned int for create and lazy_mmu?

Or just create some enum flags?

> 
> At least we'd have better self-documenting code in the wrappers.. and if
> we ever need a third boolean, we could avoid multiplying the wrappers
> again.
> 
> WDYT?

I'm happy with either approach. I was expecting more constination about the idea
of being able to disable lazy mode though, so perhaps I'll wait and see if any
arrives. If it doesn't... flags?

> 
> Cheers,
> Liam



From xen-devel-bounces@lists.xenproject.org Fri May 30 18:07:32 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 18:07:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001449.1381604 (Exim 4.92)
	(envelope-from )
	id 1uL48X-0005vN-BW; Fri, 30 May 2025 18:07:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001449.1381604; Fri, 30 May 2025 18:07:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL48X-0005vG-85; Fri, 30 May 2025 18:07:21 +0000
Received: by outflank-mailman (input) for mailman id 1001449;
 Fri, 30 May 2025 18:07:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL48W-0005vA-33
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 18:07:20 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id eb759443-3d80-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 20:07:17 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 0477AA4FB9D;
 Fri, 30 May 2025 18:07:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5438EC4CEE9;
 Fri, 30 May 2025 18:07: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" 
X-Inumbo-ID: eb759443-3d80-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748628435;
	bh=grThaU0tdR0BfIndPr0yoi2ZxiaB/wYq8MtjT/SUfwg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=i+cf6AdGtcvE4+lVBjcGXiCxlgSWkfxLAgviMdLyP5mKbq5l8fz1CCHBrRHgSX4dU
	 2D5YyK0WO9uuSvHVlV7LphgzGLwVl84f+bMya18/YSi0E7IG6OxM8esSF+itV7iSdl
	 sIF/xoott3kQTRoNn9R3AYlJl7PppVJvAMPMzX0qbdCii9QpgZKggtAYDGZArQK4nF
	 9ouTk7OVeiGjiwDv6RwRPtkDFba5bUrZANzXsrkLoGZmUEoOJ2FqBjQ2ySCZCLGd79
	 m424tC70irmib4oN/3BCVdDZY1h+FTK01qX74gi28SH+/c0mGARlPrIiMt6XTl0+xK
	 iejOfh2y63s4A==
Date: Fri, 30 May 2025 11:07:12 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: dmkhn@proton.me
cc: Stefano Stabellini , 
    xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com
Subject: Re: [PATCH v4 2/4] xen/console: introduce console input permission
In-Reply-To: 
Message-ID: 
References: <20250529000848.2675903-1-dmukhin@ford.com> <20250529000848.2675903-3-dmukhin@ford.com>  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, dmkhn@proton.me wrote:
> On Thu, May 29, 2025 at 05:58:00PM -0700, Stefano Stabellini wrote:
> > On Thu, 29 May 2025, dmkhn@proton.me wrote:
> > > Add new flag to domain structure for marking permission to intercept
> > > the physical console input by the domain.
> > >
> > > Update console input switch logic accordingly.
> > >
> > > No functional change intended.
> > >
> > > Signed-off-by: Denis Mukhin 
> > > ---
> > > Changes since v3:
> > > - rebased
> > > ---
> > >  xen/arch/arm/vpl011.c      |  2 ++
> > >  xen/arch/x86/pv/shim.c     |  2 ++
> > >  xen/common/domain.c        |  2 ++
> > >  xen/drivers/char/console.c | 18 +++++++++++++++++-
> > >  xen/include/xen/sched.h    |  8 +++++++-
> > >  5 files changed, 30 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > > index 66047bf33c..147958eee8 100644
> > > --- a/xen/arch/arm/vpl011.c
> > > +++ b/xen/arch/arm/vpl011.c
> > > @@ -737,6 +737,8 @@ int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
> > >      register_mmio_handler(d, &vpl011_mmio_handler,
> > >                            vpl011->base_addr, GUEST_PL011_SIZE, NULL);
> > >
> > > +    d->console.input_allowed = true;
> > 
> > This should be set only when backend_in_domain = false.
> > 
> > 
> > >      return 0;
> > >
> > >  out1:
> > > diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
> > > index c506cc0bec..bc2a7dd5fa 100644
> > > --- a/xen/arch/x86/pv/shim.c
> > > +++ b/xen/arch/x86/pv/shim.c
> > > @@ -238,6 +238,8 @@ void __init pv_shim_setup_dom(struct domain *d, l4_pgentry_t *l4start,
> > >       * guest from depleting the shim memory pool.
> > >       */
> > >      d->max_pages = domain_tot_pages(d);
> > > +
> > > +    d->console.input_allowed = true;
> > >  }
> > >
> > >  static void write_start_info(struct domain *d)
> > > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > > index 87e5be35e5..9bc66d80c4 100644
> > > --- a/xen/common/domain.c
> > > +++ b/xen/common/domain.c
> > > @@ -835,6 +835,8 @@ struct domain *domain_create(domid_t domid,
> > >          flags |= CDF_hardware;
> > >          if ( old_hwdom )
> > >              old_hwdom->cdf &= ~CDF_hardware;
> > > +
> > > +        d->console.input_allowed = true;
> > >      }
> > >
> > >      /* Holding CDF_* internal flags. */
> > > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > > index 30701ae0b0..8a0bcff78f 100644
> > > --- a/xen/drivers/char/console.c
> > > +++ b/xen/drivers/char/console.c
> > > @@ -512,9 +512,21 @@ static unsigned int __read_mostly console_rx = 0;
> > >
> > >  struct domain *console_get_domain(void)
> > >  {
> > > +    struct domain *d;
> > > +
> > >      if ( console_rx == 0 )
> > >              return NULL;
> > > -    return rcu_lock_domain_by_id(console_rx - 1);
> > > +
> > > +    d = rcu_lock_domain_by_id(console_rx - 1);
> > > +    if ( !d )
> > > +        return NULL;
> > > +
> > > +    if ( d->console.input_allowed )
> > > +        return d;
> > > +
> > > +    rcu_unlock_domain(d);
> > > +
> > > +    return NULL;
> > 
> > The original idea was to skip over domains that cannot have any input so
> > I don't think we should get in this situation. We could even have an
> > assert.
> > 
> > 
> > >  }
> > >
> > >  void console_put_domain(struct domain *d)
> > > @@ -551,6 +563,10 @@ static void console_switch_input(void)
> > >          if ( d )
> > >          {
> > >              rcu_unlock_domain(d);
> > > +
> > > +            if ( !d->console.input_allowed )
> > > +                break;
> > 
> > shouldn't this be continue instead of break?
> > 
> > 
> > >              console_rx = next_rx;
> > >              printk("*** Serial input to DOM%u", domid);
> > >              break;
> > > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> > > index 559d201e0c..e91c99a8f3 100644
> > > --- a/xen/include/xen/sched.h
> > > +++ b/xen/include/xen/sched.h
> > > @@ -512,7 +512,7 @@ struct domain
> > >      bool             auto_node_affinity;
> > >      /* Is this guest fully privileged (aka dom0)? */
> > >      bool             is_privileged;
> > > -    /* Can this guest access the Xen console? */
> > > +    /* XSM: permission to use HYPERCALL_console_io hypercall */
> > >      bool             is_console;
> > 
> > While I am in favor of this direction and we certainly need a better way
> > to distinguish domains that can use HYPERCALL_console_io hypercall from
> > others, could we simplify this and just assume that "is_console" implies
> > input_allowed and also set is_console = true in all the same places you
> > are setting input_allowed = true in this patch?
> > 
> > For clarity, I am suggesting:
> > - do not add input_allowed
> > - set is_console = true in domain_vpl011_init, pv_shim_setup_dom, etc.
> > 
> > The only side effect is that we would allow domains with vpl011 to also
> > use console hypercalls but I don't think there is any harm in that?
> > 
> > I don't feel strongly about this, I am just trying to find ways to make
> > things simple. I apologize if it was already discussed during review of
> > one of the previous versions.
> 
> There was feedback on using is_console:
> 
>   https://lore.kernel.org/xen-devel/e899f63b-6182-4b53-9fb4-9a821e75648b@suse.com/
> 
> AFAIU, since XSM is the existing user of is_console, there should be a new
> separate flag to avoid collision with the existing one.

OK, I suspected as much. In that case, it is fine to continue with the
new flag.



From xen-devel-bounces@lists.xenproject.org Fri May 30 19:10:31 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 19:10:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001479.1381614 (Exim 4.92)
	(envelope-from )
	id 1uL57T-00066N-UB; Fri, 30 May 2025 19:10:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001479.1381614; Fri, 30 May 2025 19:10: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 1uL57T-00066F-QF; Fri, 30 May 2025 19:10:19 +0000
Received: by outflank-mailman (input) for mailman id 1001479;
 Fri, 30 May 2025 19:10:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL57S-000668-Nm
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 19:10:18 +0000
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com
 [205.220.165.32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b7b87d86-3d89-11f0-a300-13f23c93f187;
 Fri, 30 May 2025 21:10:16 +0200 (CEST)
Received: from pps.filterd (m0246629.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54UJ7Vkn026387;
 Fri, 30 May 2025 19:09:11 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46v3pdanjr-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 30 May 2025 19:09:10 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2)
 with ESMTP id 54UI6IRK023031; Fri, 30 May 2025 19:09:09 GMT
Received: from ch5pr02cu005.outbound.protection.outlook.com
 (mail-northcentralusazon11012031.outbound.protection.outlook.com
 [40.107.200.31])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 46u4jdcw05-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 30 May 2025 19:09:09 +0000
Received: from PH0PR10MB5777.namprd10.prod.outlook.com (2603:10b6:510:128::16)
 by SA1PR10MB7593.namprd10.prod.outlook.com (2603:10b6:806:385::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.40; Fri, 30 May
 2025 19:09:06 +0000
Received: from PH0PR10MB5777.namprd10.prod.outlook.com
 ([fe80::75a8:21cc:f343:f68c]) by PH0PR10MB5777.namprd10.prod.outlook.com
 ([fe80::75a8:21cc:f343:f68c%6]) with mapi id 15.20.8746.035; Fri, 30 May 2025
 19: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" 
X-Inumbo-ID: b7b87d86-3d89-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=corp-2025-04-25; bh=I+DxlQAbrpaOCVfQVy
	LgrK9X1SNPjzSzIGLlfFmHbLc=; b=bEl3DquRUZ4iOPho8YbFLUlX40U92QQyZi
	J84f5A9066yNxz9R9YKi67eBo7KrcfC3CvxOlO+O4UzSyyxu25IojqTXjokNMlkH
	o5UVmTvI6tXI7INYXNdjDndyXt4B3UzScVuA9lr3+RSUQBlSeY0BgVfdt9BAhuI8
	incx/SIVHhTHfXUQAVM0WZeugKPTO+vc4XoWfcbzkesMeHW0r6mjwzMsUsiKT9bj
	lwpb3MUg8gWQv6hObiDvuD5YXDeyISs/sAhMfePOf4En0Gn7Y7kJv6rEt4KGWLqE
	jNFptIaa18EYsw25jS3/5pnaRJRGXImwVir19iGxhyVWEdUTRjww==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fV83HSaVXL0nwGdOC7JLeoNVWKvDHT8TulziKNYJRcEwT67HYlN/96q0r75Pj/f+Kz2gEabRRXz6MDrJlowy0L22Qv0VQi/ep9nus/ctQ2M0/ZRb67FIZUdKo7Sa2/7IKv6toPu9UEGxBsUAAcZopTKBdwlZI1+ddFFncm3lMSipSfuDu7uSrPanTOy5xg2SYK+c/PUBaPS7Vz16Hz1Pp5w/+k1HejxV3b2Kc1YFhdYCSupzy26iUbmpIMj9pz4YvTS+MIEknrVAgILM6dL9+C2+Jq6pw9P7KZtGQnAHsv9S+o8u24HgdfBtGcpfAYaCaK8RGnUN2U0Dzva0waWziw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=I+DxlQAbrpaOCVfQVyLgrK9X1SNPjzSzIGLlfFmHbLc=;
 b=QWh4UjgstVjzu6qvtWYkgrFHzt8Qp7B4JQ02a4nX8jxzyyuK3XhFFMc1X+HIGnUmREP1jZiRQcklth4jpBuCT+4CGI9UnpY5Zpjq60w7vH4isKxyrJuj5mnvRC/AuzYgiYzRKZLTF7xL9ZGnRRNYbA3Wsc/U2cLcoDy163s3XaKkm28+zElgxA6BV5UdX2KQerRu7QJP9SnQt5oTql+FUI0Xxhk1BmCV3SPMcz9hbxVgYJo3DNdsDD5IAtw38vY8WSCNhNGSSzLlW80HLjCSsxT0SBiAAiedstaRlzrDbEyLfC2ZEM2thLBhqBYkA5RCtAPPPBbgNdqZ4FJDr8SbbQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=I+DxlQAbrpaOCVfQVyLgrK9X1SNPjzSzIGLlfFmHbLc=;
 b=MJHoueYr52bEQ2q3YLNjhCoqAXHl6fgHZ68oSWO7QV/bJ46G5Y+Yl90yAVtjnw0P3vwnvYEW/gF9h7zlgX0LHshKt3vDKz8VLYe1qAdPreIMlLRNLQxIjjCRrDL1D0U7YRc3vNgxyslMPFXRRhRC4msHFgzdpY89pQ4ets+h9uA=
Date: Fri, 30 May 2025 15:08:59 -0400
From: "Liam R. Howlett" 
To: Ryan Roberts 
Cc: Catalin Marinas , Will Deacon ,
        Madhavan Srinivasan ,
        Michael Ellerman ,
        Nicholas Piggin ,
        Christophe Leroy ,
        "David S. Miller" ,
        Andreas Larsson , Juergen Gross ,
        Ajay Kaher ,
        Alexey Makhalov ,
        Thomas Gleixner , Ingo Molnar ,
        Borislav Petkov ,
        Dave Hansen ,
        "H. Peter Anvin" ,
        Boris Ostrovsky ,
        "Aneesh Kumar K.V" ,
        Andrew Morton ,
        Peter Zijlstra , Arnd Bergmann ,
        David Hildenbrand ,
        Lorenzo Stoakes ,
        Vlastimil Babka , Mike Rapoport ,
        Suren Baghdasaryan , Michal Hocko ,
        Alexei Starovoitov ,
        Andrey Ryabinin ,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
        virtualization@lists.linux.dev, xen-devel@lists.xenproject.org,
        linux-mm@kvack.org
Subject: Re: [RFC PATCH v1 3/6] mm: Avoid calling page allocator from
 apply_to_page_range()
Message-ID: 
Mail-Followup-To: "Liam R. Howlett" , 
	Ryan Roberts , Catalin Marinas , 
	Will Deacon , Madhavan Srinivasan , 
	Michael Ellerman , Nicholas Piggin , 
	Christophe Leroy , "David S. Miller" , 
	Andreas Larsson , Juergen Gross , 
	Ajay Kaher , Alexey Makhalov , 
	Thomas Gleixner , Ingo Molnar , Borislav Petkov , 
	Dave Hansen , "H. Peter Anvin" , 
	Boris Ostrovsky , "Aneesh Kumar K.V" , 
	Andrew Morton , Peter Zijlstra , 
	Arnd Bergmann , David Hildenbrand , 
	Lorenzo Stoakes , Vlastimil Babka , 
	Mike Rapoport , Suren Baghdasaryan , 
	Michal Hocko , Alexei Starovoitov , 
	Andrey Ryabinin , linux-arm-kernel@lists.infradead.org, 
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org, 
	virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mm@kvack.org
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
 <20250530140446.2387131-4-ryan.roberts@arm.com>
 <6nf3cxwhij7jtfi2u6nmt4igezf754gmue5dfskn4jkfkxmjzr@7btdipzmzjuo>
 
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20240425
X-ClientProxiedBy: YQXP288CA0033.CANP288.PROD.OUTLOOK.COM
 (2603:10b6:c00:41::30) To PH0PR10MB5777.namprd10.prod.outlook.com
 (2603:10b6:510:128::16)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH0PR10MB5777:EE_|SA1PR10MB7593:EE_
X-MS-Office365-Filtering-Correlation-Id: 2e839227-86dd-4acf-0686-08dd9fad72bb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|7416014|376014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?kJfJ27FNTVe2elKeGPhwHyIB9h05nb+1Vq9VYumafk3WQiKzfWzXBoxfON2F?=
 =?us-ascii?Q?0FlC7c5Ar0S5XbmPYUMUyvXOAG4IuW0nXYul/sGj40PUOyR8+R86Ltpt7yDi?=
 =?us-ascii?Q?YZ58DTqJ6EMW+NSSuA+3zAwJVNScajb55/lViaP2kKZdMO5bkGnRVPVLgWC5?=
 =?us-ascii?Q?OmGGFCtXDD3AXoWzskoLu05yfZUJ4RHxiK83StuAGjeq5LbryQJogJ0wK3Vn?=
 =?us-ascii?Q?vEAzbuwFgEwZDHSz7Y1UXdPlp5FT71U8kcdRACjaJkdbwSieLLiyKyPGwMmA?=
 =?us-ascii?Q?1uzQF8U2nIRtabfqFJttRDYWO2UnwuEQHY2ZgkYDtwP3QUIW2rVNFYjTg362?=
 =?us-ascii?Q?Rt5drQjjDDy4XbZfQHfF6EG84dGMat2ls+ERAm+erO29TDmIPPQMlvXsLJ9n?=
 =?us-ascii?Q?kFwhU5MMxBh7srtBonXmcEmczw2+ldl96JAFBMAy/B8sRKUrRdP9Mj8PdqF5?=
 =?us-ascii?Q?Ch45xBA9bFM7KhNcN8+QiHun4DqGOSzzcO0ZPkwvZdgjFrfWQB6bZ6QANPw0?=
 =?us-ascii?Q?SkpzA29tjBhaVHFtOU41Tk4VSO4T2Dmh0L54Gpi8oJrnKWxED9rVJ5xXx6/o?=
 =?us-ascii?Q?Rv7GobdElxEig9BVUABsM8BWIO/h+lxnujuzKvVxulZd7U2FjNCRWNoRuUBp?=
 =?us-ascii?Q?C6lJLNRZIeOCJsAF8By1wkR6TZAlyTSSUcQwXfqHh9veAmh+Zz+vYI/ko8+C?=
 =?us-ascii?Q?VAxzPZ0J3ZZsbvkjBNTVzxTANfqjD+Aby6MJJhTqeBqYFh+Hs26G7Z1tdxG9?=
 =?us-ascii?Q?Bk0ncYW5s0fHomai3RV5rwDodiwu0it6ov7y9h2HXXlJbTTRFdWdmHVWZyoi?=
 =?us-ascii?Q?p2Rzt5U/r7+uZ8mRSYfyCh5awfIEtb5e4u/ZJQzNegmbFWJP7mBYc8MZ9WRR?=
 =?us-ascii?Q?T2LNAACoGdgZnrKoPHWL4f4Dv6IFbsp7l89y+EiQS4hd6AE9FKn649thwzsZ?=
 =?us-ascii?Q?29k5bXGAL46mVBm8SUCj2hGnhgw+Rlh/9/2f3sI2W/M6yqQS0l7Dt+nJzRV7?=
 =?us-ascii?Q?vVLiqjk4yBUkyxrDY+z5T1yniX1Ec52W4BtzmwBUbp4E+MsxPqetxO5jax2D?=
 =?us-ascii?Q?56JKPc1+IZBDhbGn0sdLzxbg/OeYWmYAmCuU8CTeklSO6edzAwF21YjIiceh?=
 =?us-ascii?Q?gSDtVJ1HQE61sHO4hJafudFT5BsugtXCmvPR2MvD70CrD82ohZSbngNweMzf?=
 =?us-ascii?Q?sDpQdAOzj6sJt2/K+yjrVlApUFMLCQp39XN6KTmIHuvEbr2NRypP03dIfsmn?=
 =?us-ascii?Q?ktnYKg8YlSDocA7ArIT7DYKsqN028+QVrM5uUz7LB9yvCeYk3kcel0/Unf92?=
 =?us-ascii?Q?BX7EhvnayfhBBCLFXvQ/kquGY+INF8jUnqTlrhxWaCzn16OKDYVCsibL3RAf?=
 =?us-ascii?Q?PiDKP+G1pnDTh5cAfokdyyxpsylxN0N4/dbqCXlmR5t/5p/FpRTJZtx+xSXP?=
 =?us-ascii?Q?BIPnk8Nus4M=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR10MB5777.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?zTYbfM0EgQQX8gpYimYG+IHwqtA03TxEjLVbg/rAsKOH5DybqwTUs8pub+q6?=
 =?us-ascii?Q?TUx5u4WASY8/YqrCbAl18nRZR1w3cWOu4H/nZfVFqY0zKyDJoNsy0QtvG9MX?=
 =?us-ascii?Q?GlfxOc64Oopo5fmVLnJtHAd55+i9cYv3WPqlZG8J00MMj3RI9ht4Vg8ynrCV?=
 =?us-ascii?Q?96s0W3FEa/nLsPc8hv7tdzcJQDHx4U5q7UAbaoSBhTJk1gY/1EwP9YugCjJQ?=
 =?us-ascii?Q?d58KNDMAWhN1j7Q8fIB5x9Rvm13VAZoSwhaFhwNFIBBFBbaM/cBL8hyKQGvE?=
 =?us-ascii?Q?loll5Cm7G28eNduVSvFvL+24+7RszRhxTOP6klaJdU3/XsYykUo/34CEK+M1?=
 =?us-ascii?Q?8QcHC+WA7rt7wcXvufFLe+cQQ7yPNAToTtxrcaAIL5QiLDD0n4yyUjQLk5jk?=
 =?us-ascii?Q?qE1A2iIAOQ+uV+2WnVFlWfVFzjAacP0Bc/kOJ+hcMoortaEEFdr3lTOIOBeO?=
 =?us-ascii?Q?vj5UIVHRsGOLtzsSJw9hAPXlqzi14Y4cqoAmb/9k71+LRxQg0GpLquReu9Sm?=
 =?us-ascii?Q?Wx85fCujj1C9ZfZLoiKm5aSR1fzvCUWnWMtrbVV6YSi5a6yALFFRRmsNn1o+?=
 =?us-ascii?Q?0VmWzwo7KbIfy1lvaVmFED0B7jRr60X0ms83Lu91ULW+xOM881l9yDrXGpc+?=
 =?us-ascii?Q?ZGhNwRR8aLeeVbRVlaUcTIipjFZ+485RlQ76i6/dwuzZv+9X2m9McYqekLNJ?=
 =?us-ascii?Q?18Ik3KB4HtRvJDC6AuhH/Xx9Our9leurZAQ0xMLhHAJzq7k+wpjdHctRLkVQ?=
 =?us-ascii?Q?VqlIzWB7FhWnk8lp6WtuHm5wA79aIe2241QWCFCYu/KuBblGP/TuBkxiZNu+?=
 =?us-ascii?Q?dKmkH8SFRcWM1esiyyp5QsmZJ7JUUP52dllfdr6/w9zpM8xbTkE/bCF6c1M+?=
 =?us-ascii?Q?6eg6jdT9ZBkTlhZy15ap9YzzAQxXzBhJhfXgSjaqVf3w5VPVv7NI9VfDNk78?=
 =?us-ascii?Q?AyVKrfmX3PQcSir1SKGOcXqmTTcGoknhubqqQqC7PLLGuP4AhRL0iiS9aU4Q?=
 =?us-ascii?Q?9byzPA1qqtBZckB1++ApodRrHfT94dPthF7ruoSMVE4V+A1gst7iym34NZ7f?=
 =?us-ascii?Q?TxGMcvEnA7SZBB72u57tXgfL9eHud35qGMF1JJVRMLTk0L8yoedzaBXR0nzq?=
 =?us-ascii?Q?jbNjDE/qD2HJb+daxdmFT8F5a6SxqA5RqQtW+82oAC35JcQH+0FngnYz60M7?=
 =?us-ascii?Q?IUwnKDjsi7c1aU5I7RE9OrQqjzVNsOaSNZUHqCrgYOotZTvt5qTMFlAw829R?=
 =?us-ascii?Q?+N0d5EMHN2CLIyUIrfKxsn86hUCWW1vE9v/uEmuI6zpIZDUvKSbKTIfoM/Vx?=
 =?us-ascii?Q?EqILs386Hlo3EudocuLPZbOupKnVxawG50hSQDDLRER+S2bvaCr8rgmPjTpN?=
 =?us-ascii?Q?6k4y62i6aF9KnP9Ty2KZy2AX7rAjKvjkbED91IeBHJXjFjuFXNVjnEMIYJen?=
 =?us-ascii?Q?s9f3cxuYaeMYxXFwUK+5PWU2Ucae3x+/IP4dK7WaIazL/dz6MSztuQ405mFV?=
 =?us-ascii?Q?3r3UPl41/H61SYNYaUmWXb69AJnjGGN3JlmAU7P++gXOBXepeLIKQO+fEdUN?=
 =?us-ascii?Q?L1Rk0Ewyg7Ooc+wg+gpXFxPxRR5Udo2kd9sJCUPq?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	sVOhol8w0ju45MVFlO9oaBViN5h1i1vgyURSUcj+8Uq8tfa3EGqFbqavu1BPB34DKpibb7W/p6MmBMSsJ8MC/mT/+ugUd80dJ12eO4g/L+KI0NkfGVc0yUk/81ez0HT5DpDRIgKZ6eJ7g0WY4gz2XKQw7E59ma9ZwgnfmAxGT3yuS2J5gN8YJl/sC1AwB6WFsCyNKMWYJq6CKkON+pRgICF+c/MmSzmThfbNI/ONi6yWMLz4Bse7D4CPcfUpaUxrytmamokB8oEovxEExkDgEeVb/E7MD7RHmmYaCAbLDXfknmrGulRjGTaiGf6+HtE24GO0LAZB4solVtSm+GS2l4ByDLcBl4wpabWA0zu4T5jvCUttEQabInBcynG8WqmJOd9sxcSHqfFZ4DXxi4fPm6eh2CKz7bE/t5aCIJXs7tEjZnBpadgRuu9RHd6c8KGqZPHICQEYY5tvsFo+Vm9mzzS2TNFIu4gjorWDwu2cgQ3/g3CgX1kxK9B2s2KP0fyUEt43XFbcdfkMlCngH9q5xWszSa7m3D3etIuwA3nDHUyHp82eJu8L7sY+rhXopcHhLnHOvd08SzjBHHpn9fRStTs83SwXqQA+ROikWPUkTO8=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e839227-86dd-4acf-0686-08dd9fad72bb
X-MS-Exchange-CrossTenant-AuthSource: PH0PR10MB5777.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 19:09:06.1273
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Hu2NOjsxXxo2oTSz1+Y81cGkmpy1+8BIh/ozIz51cIt6tohYaFvsh/6aCI1k8xVr5uKdfukIYc1VfjtTTAzP7Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR10MB7593
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
 definitions=2025-05-30_08,2025-05-30_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 mlxlogscore=631
 bulkscore=0 suspectscore=0 malwarescore=0 spamscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
 definitions=main-2505300170
X-Proofpoint-ORIG-GUID: nizOyBwxlJx-LsgCzOdBD7qM-5WR2XWe
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDE3MCBTYWx0ZWRfX/+5je1+eyY0p fCIECjqdNPoz7vevwpuWFWr1a/w1t04zXEqnMKnEAFmMugLmT2LEbbmEJiDe/IUu2THrQeZTE1k KM1pS38bPV588quwm5+isxAt/xruV6sHGkYQYwpvWfMnByrbC0ioyu+qAUiSoaRCLcHZ/fCopw3
 bmWekhCPXl/PI6VOS8oPWOqyRzRODnBcDoS24DK9lsm787TL9Y9opwOqwteEhFb4W6Ux+VlASvA vtaLL8n+09X/QQ9ngE7AaDrnQNPwPSExAcDjqwdxjP+T4ViYpkPs0APD8lI0rbVmFw++MGdC5rM c90Bu5SLtlrUs2JW1S+5ad5JEOxhHG4kXRRxYlbEY+rkrSrS3a3/G8NEoEpdskQWKMGg2Cl/k25
 ov2ha5l6ZXxScVKXR/Gm3hwoH1iyLqQkiyGMOU70+oZMOchAM80ejZu9YN4tptSF/G6eU4M8
X-Authority-Analysis: v=2.4 cv=UZNRSLSN c=1 sm=1 tr=0 ts=683a0256 b=1 cx=c_pps a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=GoEa3M9JfhUA:10 a=7CQSdrXTAAAA:8 a=qmk0JyoKvBD0N212XD8A:9 a=CjuIK1q_8ugA:10 a=zZCYzV9kfG8A:10 a=a-qgeE7W1pNrGK8U0ZQC:22 cc=ntf awl=host:14714
X-Proofpoint-GUID: nizOyBwxlJx-LsgCzOdBD7qM-5WR2XWe

* Ryan Roberts  [250530 12:50]:
...

> > 
> > 
> > These wrappers are terrible for readability and annoying for argument
> > lists too.
> 
> Agreed.
> 
> > 
> > Could we do something like the pgtbl_mod_mask or zap_details and pass
> > through a struct or one unsigned int for create and lazy_mmu?
> 
> Or just create some enum flags?
> 
> > 
> > At least we'd have better self-documenting code in the wrappers.. and if
> > we ever need a third boolean, we could avoid multiplying the wrappers
> > again.
> > 
> > WDYT?
> 
> I'm happy with either approach. I was expecting more constination about the idea
> of being able to disable lazy mode though, so perhaps I'll wait and see if any
> arrives. If it doesn't... flags?

Yes, that works as well.  Please use pmd_flags or anything more
descriptive than just 'flags' :)

I wonder which approach is best in asm instructions and self-documenting
code.

Regards,
Liam



From xen-devel-bounces@lists.xenproject.org Fri May 30 20:32:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 20:32:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001514.1381633 (Exim 4.92)
	(envelope-from )
	id 1uL6OX-0007VZ-Gs; Fri, 30 May 2025 20:32:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001514.1381633; Fri, 30 May 2025 20:32: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 1uL6OX-0007VS-Cy; Fri, 30 May 2025 20:32:01 +0000
Received: by outflank-mailman (input) for mailman id 1001514;
 Fri, 30 May 2025 20:32:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL6OW-0007VM-Ez
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 20:32:00 +0000
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
 [2a00:1450:4864:20::22a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2272a382-3d95-11f0-b894-0df219b8e170;
 Fri, 30 May 2025 22:31:58 +0200 (CEST)
Received: by mail-lj1-x22a.google.com with SMTP id
 38308e7fff4ca-32a6f5cb6f9so13239571fa.2
 for ; Fri, 30 May 2025 13:31:58 -0700 (PDT)
Received: from yp-VivoBook-ASUSLaptop-M1503QA-M1503QA.. ([95.67.15.120])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-32a85bd2d30sm7225011fa.98.2025.05.30.13.31.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 13:31:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 2272a382-3d95-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748637118; x=1749241918; 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;
        bh=vhJaJA/ACQH5wfV2evOmhTU2I88ao20gELtlbDGW3gM=;
        b=UNqvZaI4eqDptmowkQHh/xaPg0CadJaGJH309kaEInmSh69KroKKc20eu+Z1TQwXoD
         a89oogydYUsfyocyAjZ3gJcbQ6oRRpx1cRkrq/adYy+3mnbZgoX/QhLHG4t2pVR/0iXy
         znShZfdGqv4q6MYNLh8t6V2sIMbqgFpmcdCHyMzqxEsCmQm2x3X3Zd0tt1+veHORzg4d
         7LPgxZ9MXwHK5i2FjvzYce7OfLos0SrDt/BRv1WyOAf0jl/xVkqheI5+d2C09gC3XagM
         6scMSbURJP09ap6gTfM9gjlKqyMUmW97RfIHEseFz8w4CcuFtZ7uigx0CGkHu42EfRTE
         mphA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748637118; x=1749241918;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=vhJaJA/ACQH5wfV2evOmhTU2I88ao20gELtlbDGW3gM=;
        b=GvrHL60xGjVoycBbdR2uLwYtbwj25td+Va7gjsFxxLov0kjbSs4DZ5Za5MIGSDxbFD
         XYHb2GwEB1ciwV/Ga+e2EfzP8b3ntzlEwv0Ki4W21HsUfUa6EQMvpZPTDrXO1KUVHANz
         3oJdB7BF4QfImK+HyfEto5PqQjAjYLhoD5UCZ2WRkkGz0mNXMj3qOvO9fww+oemilCpk
         dPYHMPDnqhifr5dvxq0hde0YYmMhqIjdHaCKFmtiOr6LjAetMvV6uDSW+EfCQ404dbNz
         GT0jIHHsOJB++qCaohOGymfAbs8jL3fCXR7OakHhN+Q4MURDJHPdE47Dx3mn8yN+/8WI
         3Rgg==
X-Gm-Message-State: AOJu0YxupHFXpY7FmCqZTBbY1wdNSrDp8cVuN5xsjneUYElf29UmEdDw
	Kvw866MLH9urhBZPug8Oq1L/ywGPcSrud1ekrD+DzPpBlzXV3N3T5plQLVU2B5Ba
X-Gm-Gg: ASbGncs51xKWO/AcYz3Eh32EtMrnTg+TVakSJdKd0bztWx2YHvs1JANCNcAwh9XbkO+
	vwr/dSWgYiPc0xksLwFmF+C4Quk7E1OpnvCbepkG/wXnkZLwBvJYORdp2Cr33S9fS8xNSROtaZa
	4kjQVhuT4Ys6x86ESNAoq0xBoItkH3cTvciOIqCKBtj0rwHptiP9sA55ifnAlVSsBmZRG9Lu0i7
	GHifSzg5w+tTGtHE5l3DLbGR17LXB/gfUNi5OGMtD0AlzB/93wAdkgPRGKVKbEPr5W74u31fe3z
	HwjM6HEJU9hLw9kTFVayltPa/xc8hGv5RS+/9qAxShn8swzSKSsvL7CzyHvHkRQj7ETJ+sxY5CY
	zxmMR20QOerWqNAY=
X-Google-Smtp-Source: AGHT+IHwhHGkGKuTPHsPJ23ehLzxewRigP71Da4uqWvefQzcBRPBl3bVxD3yB3xgrTIHOh68+q0pGw==
X-Received: by 2002:a05:651c:542:b0:32a:5fe2:81b2 with SMTP id 38308e7fff4ca-32a8cda3365mr22074511fa.23.1748637117478;
        Fri, 30 May 2025 13:31:57 -0700 (PDT)
From: Mykola Kvach 
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH] xen/arm64: head: document missing input registers for MMU functions
Date: Fri, 30 May 2025 23:31:35 +0300
Message-ID: <9b1f50a40e3634f859ad8e7446c24e43caaa38eb.1748637004.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.48.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Mykola Kvach 

Add missing input register descriptions to enable_secondary_cpu_mm
and enable_boot_cpu_mm functions.

Specifically:
- x19 is used in enable_boot_cpu_mm as physical start address.
- x20 is used in both functions for physical offset passed to load_paddr.

This update improves code clarity and consistency in comments.

No functional changes are introduced by this patch.

Signed-off-by: Mykola Kvach 
---
 xen/arch/arm/arm64/mmu/head.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S
index 634156f83d..033b3a018a 100644
--- a/xen/arch/arm/arm64/mmu/head.S
+++ b/xen/arch/arm/arm64/mmu/head.S
@@ -313,6 +313,7 @@ END(enable_mmu)
  *
  * Inputs:
  *   lr : Virtual address to return to.
+ *   x20: phys offset (used by load_paddr)
  *
  * Clobbers x0 - x6
  */
@@ -337,6 +338,8 @@ END(enable_secondary_cpu_mm)
  *
  * Inputs:
  *   lr : Virtual address to return to.
+ *   x19: paddr(start) (used by remove_identity_mapping)
+ *   x20: phys offset (used by load_paddr)
  *
  * Clobbers x0 - x6
  */
-- 
2.48.1



From xen-devel-bounces@lists.xenproject.org Fri May 30 20:40:33 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 20:40:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001522.1381642 (Exim 4.92)
	(envelope-from )
	id 1uL6Wj-0000cS-7n; Fri, 30 May 2025 20:40:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001522.1381642; Fri, 30 May 2025 20: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 1uL6Wj-0000cL-4u; Fri, 30 May 2025 20:40:29 +0000
Received: by outflank-mailman (input) for mailman id 1001522;
 Fri, 30 May 2025 20:40:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uL6Wh-0000cF-OJ
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 20:40:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uL6Wg-00ADsf-1y;
 Fri, 30 May 2025 20:40:26 +0000
Received: from [2a02:8012:3a1:0:ec4a:d3ec:7374:b46c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uL6Wg-009lFW-2q;
 Fri, 30 May 2025 20:40:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
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:To:Subject:MIME-Version:Date:Message-ID;
	bh=BrKBbgwGEjuNACf2zpAcE9omA+b12A1mSbdhd8numiM=; b=qA2xQIXljkgVge/vAMQmpGekVi
	L9ur3+s/U7J2mArDJZ8oTYG6Lsd+lr3Kq1qPkQMh0U0VMTTjho69Kk6H3V/gvr/a7ptFvoaL08LM5
	C+MyXvBYUI9b4Cm9lM/UhrE7Xy/Su2qFOHJGBFL9vFBVNZ2yYWNvpXHuD4lMXtw8r1KY=;
Message-ID: <2d218180-4be4-4c3f-ab65-04a112141b0f@xen.org>
Date: Fri, 30 May 2025 21:40:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] BCM2711 reboot fix
Content-Language: en-GB
To: evgeny@contentwise.tech, xen-devel@lists.xenproject.org,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk , miro@contentwise.tech
References: <1748381372906.7.62038@webmail-backend-production-66cfbfc4bc-ddzt7>
From: Julien Grall 
In-Reply-To: <1748381372906.7.62038@webmail-backend-production-66cfbfc4bc-ddzt7>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Evgeny,

Thank you for the patch. Let me start with the process,
patches are submitted inline rather than in attachment.

git-send-email commmand can do that for you.

Now regarding the patch. I understand that newer kernel
will use the new compatible. But I would assume there is
still some device-tree out using the old property. So I
think Xen needs to check both compatible.

Lastly, for the future,when mentioning we commit, we tend to use a smaller
hash (12 digits) followed by the commit title. In your case,
it would be:

b334c1afad17 ("ARM: dts: bcm2711: Use proper compatible in PM/Watchdog 
node").

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri May 30 20:46:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 20:46:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001529.1381651 (Exim 4.92)
	(envelope-from )
	id 1uL6cA-0001KB-PN; Fri, 30 May 2025 20:46:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001529.1381651; Fri, 30 May 2025 20:46: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 1uL6cA-0001K4-MY; Fri, 30 May 2025 20:46:06 +0000
Received: by outflank-mailman (input) for mailman id 1001529;
 Fri, 30 May 2025 20:46:05 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uL6c9-0001Jy-9c
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 20:46:05 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uL6c8-00AE1N-2k;
 Fri, 30 May 2025 20:46:04 +0000
Received: from [2a02:8012:3a1:0:ec4a:d3ec:7374:b46c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uL6c9-009t2R-0L;
 Fri, 30 May 2025 20:46: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=B4TZgQrlu9nT4psl9N0o0ax6hckkptF0ookl5izPB34=; b=GOvJuNimeoisVWCUg5i3WJxtI2
	qL+0DZ6FT2RSomTXkFBjwvLk2WA6UkhFOVUGetUaIFKLI8VmqwiJcCFG9wdAn0J0OW/Z5VdJnlnp7
	5ODxwDGN2TKPaDGuJK3cEYwVZX4A9vSQHeNRs5m0kgNOJ/g3DIoXT3UGWAEZIw1nS5Ho=;
Message-ID: <2ee722ec-1ec8-4411-a2e7-bd6efe963c29@xen.org>
Date: Fri, 30 May 2025 21:46:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/6] xen/arm: ffa: Rework partinfo_get implementation
Content-Language: en-GB
To: Bertrand Marquis ,
 xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org, Volodymyr Babchuk
 , Stefano Stabellini ,
 Michal Orzel 
References: 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Bertrand,

On 22/05/2025 16:08, Bertrand Marquis wrote:
> This patch is in preparation for VM to VM support in order to do the
> changes on the SP handling part of partinfo_get before adding support
> for the VM part.
> 
> This patches is doing the following changes:
> - split partinfo_get into 3 functions to have the locking handling and
>    proper exit on error handled more clearly
> - add some potential overflow checks to validate the offset and sizes
>    passed by the VM on partinfo call.
> - Introduce a maximum number of SPs (for now set to 64) to prevent
>    holding the CPU for too long in case there would be a lot of
>    partitions in the secure world. The limit currently set is thought to
>    be realistic for most use cases as 64 secure partitions is a very high
>    number compared to current seen usage (more 3 or 4).
> - fix include ordering in ffa_private.h to be in alphabetic order
> 
> Signed-off-by: Bertrand Marquis 
> Reviewed-by: Jens Wiklander 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri May 30 21:01:04 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 21:01:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001536.1381662 (Exim 4.92)
	(envelope-from )
	id 1uL6qX-0004Ap-V6; Fri, 30 May 2025 21:00:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001536.1381662; Fri, 30 May 2025 21:00:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL6qX-0004Ai-S9; Fri, 30 May 2025 21:00:57 +0000
Received: by outflank-mailman (input) for mailman id 1001536;
 Fri, 30 May 2025 21:00:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uL6qW-0004Ac-Lw
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 21:00:56 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uL6qW-00AEUg-0d;
 Fri, 30 May 2025 21:00:56 +0000
Received: from [2a02:8012:3a1:0:ec4a:d3ec:7374:b46c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uL6qW-00A9nz-0s;
 Fri, 30 May 2025 21:00: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=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=tsFCzeJijD1OjBWGjnm40a6P1PZgr8TgAkuaou6vF0g=; b=pAEoxu/k/Ai55F+8xruEjP35hR
	zzNMqjhEzX7hCE5PmJ8UbmCJT/iTwOeQlgtQPYdbtaA3NhAK0eB8grAQn1UUSOn8Z6tolEhvLA7rB
	03HgCXG+vcv/AKt/drg7WkgvZLupMEgEJw/sF1/1E2ctVrl/eaRVlBb90Qu6vaeqPiLM=;
Message-ID: 
Date: Fri, 30 May 2025 22:00:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 3/6] xen/arm: ffa: Introduce VM to VM support
Content-Language: en-GB
To: Bertrand Marquis ,
 xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org, Volodymyr Babchuk
 , Stefano Stabellini ,
 Michal Orzel 
References: 
 <3405d6a545c5ad8fadf7b252c98ce4120fe63fd2.1747925287.git.bertrand.marquis@arm.com>
From: Julien Grall 
In-Reply-To: <3405d6a545c5ad8fadf7b252c98ce4120fe63fd2.1747925287.git.bertrand.marquis@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Bertrand,

On 22/05/2025 16:08, Bertrand Marquis wrote:
> diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_partinfo.c
> index dfa0b23eaf38..66ea1860e97a 100644
> --- a/xen/arch/arm/tee/ffa_partinfo.c
> +++ b/xen/arch/arm/tee/ffa_partinfo.c
> @@ -150,6 +150,67 @@ out:
>       return ret;
>   }
>   
> +static int32_t ffa_get_vm_partinfo(uint32_t *vm_count, void *dst_buf,
> +                                   void *end_buf, uint32_t dst_size)
> +{
> +    struct ffa_ctx *curr_ctx = current->domain->arch.tee;
> +    struct ffa_ctx *dest_ctx, *tmp;
> +    uint32_t count = 0;
> +
> +    /*
> +     * There could potentially be a lot of VMs in the system and we could
> +     * hold the CPU for long here.
> +     * Right now there is no solution in FF-A specification to split
> +     * the work in this case.
> +     * TODO: Check how we could delay the work or have preemption checks.
> +     */
> +    list_for_each_entry_safe(dest_ctx, tmp, &ffa_ctx_head, ctx_list)

Looking at this code again, I am a bit puzzled why we don't seem to take 
any lock and use list_for_each_entry_safe().

I was under the impression that list_for_each_entry_safe() is used if we
delete an entry within the loop. But it is not used to protect against a 
deletion from another core.

Did I misunderstand the logic? If not, we possibly want to use a 
readlock (over the existing spinlock).

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri May 30 21:01:57 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 21:01:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001546.1381672 (Exim 4.92)
	(envelope-from )
	id 1uL6rV-0004ua-Co; Fri, 30 May 2025 21:01:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001546.1381672; Fri, 30 May 2025 21:01: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 1uL6rV-0004uT-AA; Fri, 30 May 2025 21:01:57 +0000
Received: by outflank-mailman (input) for mailman id 1001546;
 Fri, 30 May 2025 21:01:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1uL6rU-0004uL-Jr
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 21:01:56 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1uL6rU-00AEVU-0F;
 Fri, 30 May 2025 21:01:56 +0000
Received: from [2a02:8012:3a1:0:ec4a:d3ec:7374:b46c]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1uL6rU-00AAk9-18;
 Fri, 30 May 2025 21:01: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=xV1o0ahY4mMCJOm8FNODcYJvVLrXhzUekqxeoUkjYVs=; b=yLWvWZlR2mn/UujNKdpp6e+Oa4
	jSbSilcntf6v5SU1L0qnBW7YGaTJfA1HLbbrGU8NbQY4yP8gIzrm42z89Qen9Vo43tv8FfTE9r7Bq
	2omVIlAkrOZFbRI6jMrEdFz0nXzEskDpkzeS8cGDSm+71W4h9RTyoLksE8S+JDWVWIgA=;
Message-ID: 
Date: Fri, 30 May 2025 22:01:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 4/6] xen/arm: ffa: Add buffer full notification support
Content-Language: en-GB
To: Bertrand Marquis ,
 xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org, Volodymyr Babchuk
 , Stefano Stabellini ,
 Michal Orzel 
References: 
 <7e206a2e4f093af965a134bda23e3c4104267826.1747925287.git.bertrand.marquis@arm.com>
From: Julien Grall 
In-Reply-To: <7e206a2e4f093af965a134bda23e3c4104267826.1747925287.git.bertrand.marquis@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Bertrand,

On 22/05/2025 16:08, Bertrand Marquis wrote:
> Add support to raise a Rx buffer full notification to a VM.
> This function will be used for indirect message support between VM and
> is only activated if CONFIG_FFA_VM_TO_VM is selected.
> 
> Even if there are 32 framework notifications possible, right now only
> one is defined so the implementation is simplified to only handle the
> buffer full notification using a boolean. If other framework
> notifications have to be supported one day, the design will have to be
> modified to handle it properly.
> 
> Signed-off-by: Bertrand Marquis 
> Reviewed-by: Jens Wiklander 

Acked-by: Julien Grall 

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri May 30 22:03:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 22:03:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001559.1381687 (Exim 4.92)
	(envelope-from )
	id 1uL7od-00049t-RU; Fri, 30 May 2025 22:03:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001559.1381687; Fri, 30 May 2025 22:03: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 1uL7od-00049M-NQ; Fri, 30 May 2025 22:03:03 +0000
Received: by outflank-mailman (input) for mailman id 1001559;
 Fri, 30 May 2025 22:03:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL7ob-00045N-U8
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 22:03:01 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d9ce75ef-3da1-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 00:03:00 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d9ce75ef-3da1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748642579; x=1748901779;
	bh=iPUmleCFsvrITwKm2hZTfj52siQkStuU3fBh5FtzFpc=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=eUFDMHsReAHhsVb6mEWAoGSwmOPhOxgbZ89bJKSB4rF/mPfbckPgIyxjx57KYs4SS
	 T9SFaEwO1FiCduOoF2Fa8Vy3wS/YHO7jEak7Hc5THR45LTF0FJUege01ypKJ6XwwcL
	 fyFMkxtrLzjZmhZSbQ7kfDcleOSauL+QDb3HBXFufHgMNWBmSsOUXt5mEIR/N9RyHW
	 6Ls4gxUHkkBiQlY/wLfHF3XO/szRL2rvM4P4DKAtuxpy2v0dbF0wL5HTI00cUEtmTt
	 tyLwXD0YuWXQ/PYZklOdG/hxy6YJazYxL2mBQWc/FOBCSEZNEzG/1AiLN8lytYD4g7
	 fbLrpEB+NGcSA==
Date: Fri, 30 May 2025 22:02:53 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v4 1/2] xen/domain: introduce common hardware emulation flags
Message-ID: <20250530220242.63175-2-dmukhin@ford.com>
In-Reply-To: <20250530220242.63175-1-dmukhin@ford.com>
References: <20250530220242.63175-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: eff43a14659db603409c559c1c83455b004d1ee7
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Add common emulation_flags for configuring domain emulation features.

Print d->emulation_flags from 'q' keyhandler for better traceability while
debugging.

Signed-off-by: Denis Mukhin 
Reviewed-by: Stefano Stabellini 
---
Changes since v3:
- added R-b
---
 xen/arch/x86/domain.c             |  2 +-
 xen/arch/x86/domctl.c             |  2 +-
 xen/arch/x86/include/asm/domain.h | 25 +++++++++++--------------
 xen/common/keyhandler.c           |  1 +
 xen/include/xen/sched.h           |  2 ++
 5 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7536b6c871..0363ccb384 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -831,7 +831,7 @@ int arch_domain_create(struct domain *d,
                emflags);
         return -EOPNOTSUPP;
     }
-    d->arch.emulation_flags =3D emflags;
+    d->emulation_flags =3D emflags;
=20
 #ifdef CONFIG_PV32
     HYPERVISOR_COMPAT_VIRT_START(d) =3D
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 3044f706de..37d848f683 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -144,7 +144,7 @@ void arch_get_domain_info(const struct domain *d,
     if ( paging_mode_hap(d) )
         info->flags |=3D XEN_DOMINF_hap;
=20
-    info->arch_config.emulation_flags =3D d->arch.emulation_flags;
+    info->arch_config.emulation_flags =3D d->emulation_flags;
     info->gpaddr_bits =3D hap_paddr_bits;
 }
=20
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/d=
omain.h
index 8c0dea12a5..eafd5cfc90 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -455,9 +455,6 @@ struct arch_domain
=20
     /* Don't unconditionally inject #GP for unhandled MSRs. */
     bool msr_relaxed;
-
-    /* Emulated devices enabled bitmap. */
-    uint32_t emulation_flags;
 } __cacheline_aligned;
=20
 #ifdef CONFIG_HVM
@@ -494,17 +491,17 @@ struct arch_domain
                                  X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
                                  X86_EMU_VPCI)
=20
-#define has_vlapic(d)      (!!((d)->arch.emulation_flags & X86_EMU_LAPIC))
-#define has_vhpet(d)       (!!((d)->arch.emulation_flags & X86_EMU_HPET))
-#define has_vpm(d)         (!!((d)->arch.emulation_flags & X86_EMU_PM))
-#define has_vrtc(d)        (!!((d)->arch.emulation_flags & X86_EMU_RTC))
-#define has_vioapic(d)     (!!((d)->arch.emulation_flags & X86_EMU_IOAPIC)=
)
-#define has_vpic(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIC))
-#define has_vvga(d)        (!!((d)->arch.emulation_flags & X86_EMU_VGA))
-#define has_viommu(d)      (!!((d)->arch.emulation_flags & X86_EMU_IOMMU))
-#define has_vpit(d)        (!!((d)->arch.emulation_flags & X86_EMU_PIT))
-#define has_pirq(d)        (!!((d)->arch.emulation_flags & X86_EMU_USE_PIR=
Q))
-#define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
+#define has_vlapic(d)      (!!((d)->emulation_flags & X86_EMU_LAPIC))
+#define has_vhpet(d)       (!!((d)->emulation_flags & X86_EMU_HPET))
+#define has_vpm(d)         (!!((d)->emulation_flags & X86_EMU_PM))
+#define has_vrtc(d)        (!!((d)->emulation_flags & X86_EMU_RTC))
+#define has_vioapic(d)     (!!((d)->emulation_flags & X86_EMU_IOAPIC))
+#define has_vpic(d)        (!!((d)->emulation_flags & X86_EMU_PIC))
+#define has_vvga(d)        (!!((d)->emulation_flags & X86_EMU_VGA))
+#define has_viommu(d)      (!!((d)->emulation_flags & X86_EMU_IOMMU))
+#define has_vpit(d)        (!!((d)->emulation_flags & X86_EMU_PIT))
+#define has_pirq(d)        (!!((d)->emulation_flags & X86_EMU_USE_PIRQ))
+#define has_vpci(d)        (!!((d)->emulation_flags & X86_EMU_VPCI))
=20
 #define gdt_ldt_pt_idx(v) \
       ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 0bb842ec00..cd731452ba 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -306,6 +306,7 @@ static void cf_check dump_domains(unsigned char key)
             if ( test_bit(i, &d->watchdog_inuse_map) )
                 printk("    watchdog %d expires in %d seconds\n",
                        i, (u32)((d->watchdog_timer[i].expires - NOW()) >> =
30));
+        printk("    emulation_flags %#x\n", d->emulation_flags);
=20
         arch_dump_domain_info(d);
=20
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 559d201e0c..dc4f917664 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -651,6 +651,8 @@ struct domain
     unsigned int num_llc_colors;
     const unsigned int *llc_colors;
 #endif
+
+    uint32_t emulation_flags;
 } __aligned(PAGE_SIZE);
=20
 static inline struct page_list_head *page_to_list(
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 30 22:03:12 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 22:03:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001558.1381681 (Exim 4.92)
	(envelope-from )
	id 1uL7od-00046w-Jw; Fri, 30 May 2025 22:03:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001558.1381681; Fri, 30 May 2025 22:03: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 1uL7od-00046p-HC; Fri, 30 May 2025 22:03:03 +0000
Received: by outflank-mailman (input) for mailman id 1001558;
 Fri, 30 May 2025 22:03:01 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL7oa-00045N-Ii
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 22:03:01 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d5574dfd-3da1-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 00:02:53 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d5574dfd-3da1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748642571; x=1748901771;
	bh=glH4XqxhewUB98TpoL3qF3CvZPVH4kQohk0QLoyW63o=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=YhKDr1Y6BIZaFGU1eF6k9x1mFKKTLH689Ksj7RQH+m7N1zUAREJRmsJllIgY9W9Lu
	 9p5BDEM118hTTPAte6HtlsVmKhgVo5d4PuUtzK3BVqnma3o9DFnaPwI7/ip8EmP9wR
	 KTr9ESXMdrnltcSJtRHFkLjyZFuOkWve3lNSGwCLjnQyaj9nOS3X84kIBCLLkshuWj
	 MWiPdBEf6zIUSjzPWvclIub02i50Su+uPkm32IvMfrWkpCOI/DiQ6tKNm3IqovBfZR
	 Nf6r9OW+Fu77H0pEt5Ux5QFeNIdC5PYXeSr+52aWCc2D6H0VqSrR7keDCdY1OKhiD7
	 62DUNYPD1WenQ==
Date: Fri, 30 May 2025 22:02:46 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v4 0/2] xen/domain: updates to hardware emulation flags
Message-ID: <20250530220242.63175-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 144328512307bc879ff491f1c005bcdbf1fe5f74
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Patch 1 introduces emulation_flags in common domain struct for enabling dom=
ain
emulation features on non-x86 platforms.

Patch 2 rewrites emulation_flags_ok() on x86 with a goal of improving
readability and maintainability of the code.

Originally, the code was part of [1], part of NS16550 emulator v3 series.

[1] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-6-c5d36b3=
1d66c@ford.com/
[2] Link to v3: https://lore.kernel.org/xen-devel/20250528210139.2572609-1-=
dmukhin@ford.com/
[3] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1845145225

Denis Mukhin (2):
  xen/domain: introduce common hardware emulation flags
  xen/domain: rewrite emulation_flags_ok()

 xen/arch/x86/domain.c             | 93 ++++++++++++++++++++++++-------
 xen/arch/x86/domctl.c             |  2 +-
 xen/arch/x86/include/asm/domain.h | 25 ++++-----
 xen/common/keyhandler.c           |  1 +
 xen/include/xen/sched.h           |  2 +
 5 files changed, 89 insertions(+), 34 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 30 22:03:14 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 22:03:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001560.1381702 (Exim 4.92)
	(envelope-from )
	id 1uL7oo-0004bp-1G; Fri, 30 May 2025 22:03:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001560.1381702; Fri, 30 May 2025 22: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 1uL7on-0004bi-Uy; Fri, 30 May 2025 22:03:13 +0000
Received: by outflank-mailman (input) for mailman id 1001560;
 Fri, 30 May 2025 22:03:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL7om-00045N-PW
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 22:03:12 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e04b8cd2-3da1-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 00:03: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" 
X-Inumbo-ID: e04b8cd2-3da1-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748642589; x=1748901789;
	bh=lvzmtCCCcksCmz9kq9pi9RVymGPi2OyYXRIhweotEv8=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=fR6w8N1HKxcVJMAPBIIdL/aeI4WDxd3zox1N1EakwHfcPQy9KdsIlEfbwEKyTsSiL
	 xWQkN7Mv8pLocFvmEuVZburobuvIsaHYJx4ASpoQDmSS3xO9K6/FkV3YJgpsRrK6nZ
	 wzGySljcV50sUpYqWdtXrKrjlyAPrAmpB6ZPRciHQBYEsvf17BXiv0YTsKlhk8PRu4
	 Ofy2+Z3urKeEOHVbetzAHFaxPntlEkCqVvAYYFBJ3ABBSpS+tkYTIse9/sToQaEDMA
	 AmQTYGPGWLSl34OnW037HnGIzBrn6rKrTlTDUGvmt3Eb3bKwwt18Z9Qt+vomDCoxpa
	 IUGVVpU162NZA==
Date: Fri, 30 May 2025 22:03:02 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v4 2/2] xen/domain: rewrite emulation_flags_ok()
Message-ID: <20250530220242.63175-3-dmukhin@ford.com>
In-Reply-To: <20250530220242.63175-1-dmukhin@ford.com>
References: <20250530220242.63175-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 7742bab0675a4ff62abe2d7cdc5efe5c8207149f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Rewrite emulation_flags_ok() to simplify future modifications.

No functional change intended.

Signed-off-by: Denis Mukhin 
Reviewed-by: Stefano Stabellini 
---
Changes since v3:
- added R-b
- fixed stray newline
---
 xen/arch/x86/domain.c | 91 ++++++++++++++++++++++++++++++++++---------
 1 file changed, 73 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0363ccb384..8d26887be2 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -743,32 +743,87 @@ int arch_sanitise_domain_config(struct xen_domctl_cre=
atedomain *config)
     return 0;
 }
=20
+/*
+ * Verify that the domain's emulation flags resolve to a supported configu=
ration.
+ *
+ * This ensures we only allow a known, safe subset of emulation combinatio=
ns
+ * (for both functionality and security). Arbitrary mixes are likely to ca=
use
+ * errors (e.g., null pointer dereferences).
+ *
+ * NB: use the internal X86_EMU_XXX symbols, not the public XEN_X86_EMU_XX=
X
+ * symbols.
+ */
 static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
 {
+    enum {
+        CAP_PV          =3D BIT(0, U),
+        CAP_HVM         =3D BIT(1, U),
+        CAP_HWDOM       =3D BIT(2, U),
+        CAP_DOMU        =3D BIT(3, U),
+    };
+    static const struct {
+        unsigned int caps;
+        uint32_t min;
+        uint32_t opt;
+    } configs[] =3D {
+#ifdef CONFIG_PV
+        /* PV */
+        {
+            .caps   =3D CAP_PV | CAP_DOMU,
+            .min    =3D 0,
+            .opt    =3D 0,
+        },
+
+        /* PV (likely dom0) */
+        {
+            .caps   =3D CAP_PV | CAP_HWDOM,
+            .min    =3D X86_EMU_PIT,
+            .opt    =3D 0,
+        },
+#endif /* #ifdef CONFIG_PV */
+
+#ifdef CONFIG_HVM
+        /* PVH dom0/domU or HVM domU */
+        {
+            .caps   =3D CAP_HVM | CAP_HWDOM,
+            .min    =3D X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
+            .opt    =3D 0,
+        },
+
+        /* HVM domU */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ),
+            /* HVM PIRQ feature is user-selectable. */
+            .opt    =3D X86_EMU_USE_PIRQ,
+        },
+
+        /* PVH */
+        {
+            .caps   =3D CAP_HVM | CAP_DOMU,
+            .min    =3D X86_EMU_LAPIC,
+            .opt    =3D 0,
+        },
+#endif /* #ifdef CONFIG_HVM */
+    };
+    unsigned int i, caps =3D is_hardware_domain(d) ? CAP_HWDOM : CAP_DOMU;
+
+    if ( is_pv_domain(d) )
+        caps |=3D CAP_PV;
+    else if ( is_hvm_domain(d) )
+        caps |=3D CAP_HVM;
+
 #ifdef CONFIG_HVM
     /* This doesn't catch !CONFIG_HVM case but it is better than nothing *=
/
     BUILD_BUG_ON(X86_EMU_ALL !=3D XEN_X86_EMU_ALL);
 #endif
=20
-    if ( is_hvm_domain(d) )
-    {
-        if ( is_hardware_domain(d) &&
-             emflags !=3D (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) =
)
-            return false;
-        if ( !is_hardware_domain(d) &&
-             /* HVM PIRQ feature is user-selectable. */
-             (emflags & ~X86_EMU_USE_PIRQ) !=3D
-             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
-             emflags !=3D X86_EMU_LAPIC )
-            return false;
-    }
-    else if ( emflags !=3D 0 && emflags !=3D X86_EMU_PIT )
-    {
-        /* PV or classic PVH. */
-        return false;
-    }
+    for ( i =3D 0; i < ARRAY_SIZE(configs); i++ )
+        if ( caps =3D=3D configs[i].caps &&
+             (emflags & ~configs[i].opt) =3D=3D configs[i].min )
+            return true;
=20
-    return true;
+    return false;
 }
=20
 void __init arch_init_idle_domain(struct domain *d)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 30 23:19:08 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 23:19:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001600.1381712 (Exim 4.92)
	(envelope-from )
	id 1uL906-0004sS-9I; Fri, 30 May 2025 23:18:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001600.1381712; Fri, 30 May 2025 23:18:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL906-0004sL-6H; Fri, 30 May 2025 23:18:58 +0000
Received: by outflank-mailman (input) for mailman id 1001600;
 Fri, 30 May 2025 23:18:56 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL903-0004sF-Op
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 23:18:56 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7397ca22-3dac-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 01:18:53 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7397ca22-3dac-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=y4v4klxpbrekxnqiutaanpovbi.protonmail; t=1748647131; x=1748906331;
	bh=BCjyQqmmXr9DrrX7yXZOHYjQ7dkkcp3YITAJ3p3dSvk=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=mgKNjI3mo4GeQ7yRVg5xOEwvH6HeCJj7CTC49bs2eUB0GOYCLE9CYFIJ6WLlTxMj+
	 7UoicfBwJRyZlcDQZXfsy2BCK6J7/tHTI6P3YRIkvosOMyigmVLJF75sdcCiUxirCz
	 NbWqhuEMaFD6fguuDU2eS4gZp0/Mw5O/CzAOKfyZf2MwBgye9SBN9rxCtsyYCkkzLg
	 3Y5XX1OCtABndbjyzD88vWIPGVG9tmEKpU42y7aajVVu3lmQqOLi4GSS06h8gQ49Xl
	 BQXp2lce+6kl3WXroODeBjUuQzdKCO/ndisJE9/CsJEzIS/TcJs8wN8HwcEfcj9cS3
	 mY1FnCh9mCiNw==
Date: Fri, 30 May 2025 23:18:46 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 0/4] xen/console: cleanup console input switch logic
Message-ID: <20250530231841.73386-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: c0b2d05618d0335d67c55fdda1874d0c513bd904
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The patch series originates from the NS16550 UART emulator series [1] (x86)
which requires ability to switch physical console input to a PVH/HVM domain
with an emulated UART.

Currently, on x86, console input can be rotated in round-robin manner only
between dom0, PV shim, and Xen itself. On Arm the input rotation can includ=
e
domUs with vpl011.

The main idea of this series is introducing a per-domain permission flag th=
at
is set during domain initialization and used by the console driver to switc=
h
the input across permitted domains.

Patch 1 performs rename of switch_serial_input() to fit the console driver
notation.

Patch 2 introduces a new domain permission flag to mark ownership of the
console input for the console driver.

Patch 3 cleans up the console input switch logic by removing dependency
on max_init_domid. Depends on patches 1, 2 and [2].

Patch 4 performs rename of console_rx to console_domid to match the usage
of the symbol in the code.

[1] https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b3=
1d66c@ford.com/
[2] https://lore.kernel.org/xen-devel/20250528225030.2652166-1-dmukhin@ford=
.com/
[3] Link to v4: https://lore.kernel.org/xen-devel/20250529000848.2675903-1-=
dmukhin@ford.com/
[4] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1845329909

Denis Mukhin (4):
  xen/console: rename switch_serial_input() to console_switch_input()
  xen/console: introduce console input permission
  xen/console: remove max_init_domid dependency
  xen/console: rename console_rx to console_domid

 xen/arch/arm/include/asm/setup.h        |  2 -
 xen/arch/arm/setup.c                    |  2 -
 xen/arch/arm/vpl011.c                   |  1 +
 xen/arch/ppc/include/asm/setup.h        |  2 -
 xen/arch/riscv/include/asm/setup.h      |  2 -
 xen/arch/x86/include/asm/setup.h        |  2 -
 xen/arch/x86/pv/shim.c                  |  2 +
 xen/common/device-tree/dom0less-build.c |  2 -
 xen/common/domain.c                     | 35 +++++++++
 xen/drivers/char/console.c              | 96 +++++++++++--------------
 xen/include/xen/domain.h                |  1 +
 xen/include/xen/sched.h                 |  8 ++-
 12 files changed, 88 insertions(+), 67 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 30 23:19:09 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 23:19:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001601.1381722 (Exim 4.92)
	(envelope-from )
	id 1uL90A-00056I-Fn; Fri, 30 May 2025 23:19:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001601.1381722; Fri, 30 May 2025 23:19: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 1uL90A-00056B-Cv; Fri, 30 May 2025 23:19:02 +0000
Received: by outflank-mailman (input) for mailman id 1001601;
 Fri, 30 May 2025 23:19:00 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL908-00055p-Nf
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 23:19:00 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 766d3ff1-3dac-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 01:18: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" 
X-Inumbo-ID: 766d3ff1-3dac-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=cjfyrptl4ng5he7ajhctxrmcyq.protonmail; t=1748647136; x=1748906336;
	bh=YSUOLXyrO7AC8+AnY9XmvmG3t0KDhdjWKnpe7lbTOKA=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=kejDclk7enbZKjSY8z9Q91xwWE4NvLpKUZo6SlEX1ReFBCVW2bgdaltNJTZ/ZQr7q
	 kWGVsl5Rwipa4SgDuUUXLK1VLg7ko5YifhPGo6lGAwYf4sv33+skz9sb0dTctZcKor
	 0za3beM3YWqGtGwBgOEDfgOSCLI0/qwwWMRKnHBjTcV+G88bN0OhucOHRCqm1/HzaX
	 djQEqRymApavtK5eKJxJj07+Hz4qgPdn2OdhJyVsa0/VfLuXbsA+ZvdkCOXDWHvd8n
	 pk5/gxUvpkI2lMJY2YGrsLP/+0olkesmxpi6qNTB9lSKGRXTnJ9M21yPZ2RKeBgXCB
	 4TpG7JHwkzSiQ==
Date: Fri, 30 May 2025 23:18:53 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 1/4] xen/console: rename switch_serial_input() to console_switch_input()
Message-ID: <20250530231841.73386-2-dmukhin@ford.com>
In-Reply-To: <20250530231841.73386-1-dmukhin@ford.com>
References: <20250530231841.73386-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 423c493d8e7f267520abe8c351b28d1eab06b8b7
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Update the function name as per naming notation in the console driver.

No functional change.

Signed-off-by: Denis Mukhin 
Acked-by: Jan Beulich 
---
Changes since v4:
- kept A-b
---
 xen/drivers/char/console.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c15987f5bb..30701ae0b0 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -523,7 +523,7 @@ void console_put_domain(struct domain *d)
         rcu_unlock_domain(d);
 }
=20
-static void switch_serial_input(void)
+static void console_switch_input(void)
 {
     unsigned int next_rx =3D console_rx;
=20
@@ -617,7 +617,7 @@ static void cf_check serial_rx(char c)
         /* We eat CTRL- in groups of 3 to switch console inpu=
t. */
         if ( ++switch_code_count =3D=3D 3 )
         {
-            switch_serial_input();
+            console_switch_input();
             switch_code_count =3D 0;
         }
         return;
@@ -1171,7 +1171,7 @@ void __init console_endboot(void)
                             "toggle host/guest log level adjustment", 0);
=20
     /* Serial input is directed to DOM0 by default. */
-    switch_serial_input();
+    console_switch_input();
 }
=20
 int __init console_has(const char *device)
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 30 23:19:13 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 23:19:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001602.1381732 (Exim 4.92)
	(envelope-from )
	id 1uL90L-0005PY-Mh; Fri, 30 May 2025 23:19:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001602.1381732; Fri, 30 May 2025 23:19: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 1uL90L-0005PP-Jn; Fri, 30 May 2025 23:19:13 +0000
Received: by outflank-mailman (input) for mailman id 1001602;
 Fri, 30 May 2025 23:19:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL90K-00055p-0H
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 23:19:12 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7dcf4de1-3dac-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 01:19: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" 
X-Inumbo-ID: 7dcf4de1-3dac-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748647149; x=1748906349;
	bh=YxCkgCQgEgcma2HR34BjqEKfMw9IKxiz4R9wP5xWv0o=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=jvxVPpgTZDTnOQSspE04WazOKRkEo3XQBj9exJwLKtc//Vs5ZjcrhqWKUgz+D1XIv
	 Qku+ZLkqzGcAa7ALMwXXlOrF8mYZXbZsdqT5CDbdCqXyO/Ix6djWRxihpP8Hu2AOVY
	 y9dcbu5WRhDf1C1+wgn2pj+gBHIUqV340O9aIGk0qzkvEPPCZG6dbvhn+z5Vn385wB
	 Uz732eqr6IOd3Q/puYzYE+MsWUoRge18cdOR+e2wAR+Fz7Tp8oEOyIhr3SY+JlzZCZ
	 bY+E/bWXEZ4vVp0b7pnmsc4ET+W/39Zmf2QAybrzhkEG6iq6viQQ8aCVOh+tv3LlKj
	 pF4fOIJLfANBA==
Date: Fri, 30 May 2025 23:19:01 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 2/4] xen/console: introduce console input permission
Message-ID: <20250530231841.73386-3-dmukhin@ford.com>
In-Reply-To: <20250530231841.73386-1-dmukhin@ford.com>
References: <20250530231841.73386-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 49605cb8c5e79f6a3a4f10e2aed5b7481a08333f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Add new flag to domain structure for marking permission to intercept
the physical console input by the domain.

Update console input switch logic accordingly.

No functional change intended.

Signed-off-by: Denis Mukhin 
---
Changes since v4:
- kept input_allowed as a separate flag
- updated logic for input_allowed in vpl011
- fixup for console_switch_input()
---
 xen/arch/arm/vpl011.c      |  1 +
 xen/arch/x86/pv/shim.c     |  2 ++
 xen/common/domain.c        |  2 ++
 xen/drivers/char/console.c | 18 +++++++++++++++++-
 xen/include/xen/sched.h    |  8 +++++++-
 5 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 66047bf33c..480fc664fc 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -713,6 +713,7 @@ int domain_vpl011_init(struct domain *d, struct vpl011_=
init_info *info)
     }
     else
     {
+        d->console.input_allowed =3D true;
         vpl011->backend_in_domain =3D false;
=20
         vpl011->backend.xen =3D xzalloc(struct vpl011_xen_backend);
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index c506cc0bec..bc2a7dd5fa 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -238,6 +238,8 @@ void __init pv_shim_setup_dom(struct domain *d, l4_pgen=
try_t *l4start,
      * guest from depleting the shim memory pool.
      */
     d->max_pages =3D domain_tot_pages(d);
+
+    d->console.input_allowed =3D true;
 }
=20
 static void write_start_info(struct domain *d)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 129b4fcb37..d75ece1b61 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -835,6 +835,8 @@ struct domain *domain_create(domid_t domid,
         flags |=3D CDF_hardware;
         if ( old_hwdom )
             old_hwdom->cdf &=3D ~CDF_hardware;
+
+        d->console.input_allowed =3D true;
     }
=20
     /* Holding CDF_* internal flags. */
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 30701ae0b0..9a9836ba91 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -512,9 +512,21 @@ static unsigned int __read_mostly console_rx =3D 0;
=20
 struct domain *console_get_domain(void)
 {
+    struct domain *d;
+
     if ( console_rx =3D=3D 0 )
             return NULL;
-    return rcu_lock_domain_by_id(console_rx - 1);
+
+    d =3D rcu_lock_domain_by_id(console_rx - 1);
+    if ( !d )
+        return NULL;
+
+    if ( d->console.input_allowed )
+        return d;
+
+    rcu_unlock_domain(d);
+
+    return NULL;
 }
=20
 void console_put_domain(struct domain *d)
@@ -551,6 +563,10 @@ static void console_switch_input(void)
         if ( d )
         {
             rcu_unlock_domain(d);
+
+            if ( !d->console.input_allowed )
+                continue;
+
             console_rx =3D next_rx;
             printk("*** Serial input to DOM%u", domid);
             break;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 559d201e0c..e91c99a8f3 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -512,7 +512,7 @@ struct domain
     bool             auto_node_affinity;
     /* Is this guest fully privileged (aka dom0)? */
     bool             is_privileged;
-    /* Can this guest access the Xen console? */
+    /* XSM: permission to use HYPERCALL_console_io hypercall */
     bool             is_console;
     /* Is this guest being debugged by dom0? */
     bool             debugger_attached;
@@ -651,6 +651,12 @@ struct domain
     unsigned int num_llc_colors;
     const unsigned int *llc_colors;
 #endif
+
+    /* Console settings. */
+    struct {
+        /* Permission to take ownership of the physical console input. */
+        bool input_allowed;
+    } console;
 } __aligned(PAGE_SIZE);
=20
 static inline struct page_list_head *page_to_list(
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 30 23:19:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 23:19:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001604.1381742 (Exim 4.92)
	(envelope-from )
	id 1uL90Q-0005lL-3Y; Fri, 30 May 2025 23:19:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001604.1381742; Fri, 30 May 2025 23:19: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 1uL90Q-0005lC-0D; Fri, 30 May 2025 23:19:18 +0000
Received: by outflank-mailman (input) for mailman id 1001604;
 Fri, 30 May 2025 23:19:15 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL90N-0004sF-QA
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 23:19:15 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 80794aae-3dac-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 01:19: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" 
X-Inumbo-ID: 80794aae-3dac-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=2tysv52janf43araxgasgfotju.protonmail; t=1748647153; x=1748906353;
	bh=crjmZsSfdJFF0uqEvmUIgryAsQp9BDRn+DHw+7/ubRI=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=hzAE7H/wWRRZMn/AZ9JU0vGUuQdn4cBq9DOQ3aRbI7L4TEY+hiy6KqpmOVbK5xniP
	 Gl1KXHwJSqU/XJVE51n/10McTZD7PYGLkEUnnVoI9umpfdbtgOiCD8pNIQO1r6Ey5T
	 cqZTWg/lGLTIxgDweeaaI9FjCqb1fBsDWBztuP2a5zIliMB9CEsA7FY6XtHZjJ1kCG
	 16eCHlSBhrjDgtVxX/SCVLbmt2oMDFuEeZvLwTEvj/XohXd9lsQsZ8O/Xr3njYX06p
	 yUPhY9KTkwy24pYu9E8zPjWROz85+XXCve47ANNJMh14yY2FwB/c7AXhkw3ngkUMA5
	 BTaHiQuUTqrkw==
Date: Fri, 30 May 2025 23:19:09 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 3/4] xen/console: remove max_init_domid dependency
Message-ID: <20250530231841.73386-4-dmukhin@ford.com>
In-Reply-To: <20250530231841.73386-1-dmukhin@ford.com>
References: <20250530231841.73386-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 42036b1625341995ac1242138504219f8b560777
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

The physical console input rotation depends on max_init_domid symbol, which=
 is
managed differently across architectures.

Instead of trying to manage max_init_domid in the arch-common code the cons=
ole
input rotation code can be reworked by removing dependency on max_init_domi=
d
entirely.

To do that, introduce domid_find_with_input_allowed() in arch-independent
location to find the ID of the next possible console owner domain. The IDs
are rotated across non-system domain IDs and DOMID_XEN.

Also, introduce helper console_set_domid() for updating identifier of the
current console input owner (points to Xen or domain).

Use domid_find_with_input_allowed() and console_set_domid() in
console_switch_input().

Remove uses of max_init_domid in the code.

Signed-off-by: Denis Mukhin 
---
Changes since v4:
- fixed domid_find_with_input_allowed()
- kept switching to get_initial_domain_id() in console_endboot()
---
 xen/arch/arm/include/asm/setup.h        |  2 -
 xen/arch/arm/setup.c                    |  2 -
 xen/arch/ppc/include/asm/setup.h        |  2 -
 xen/arch/riscv/include/asm/setup.h      |  2 -
 xen/arch/x86/include/asm/setup.h        |  2 -
 xen/common/device-tree/dom0less-build.c |  2 -
 xen/common/domain.c                     | 33 +++++++++
 xen/drivers/char/console.c              | 90 +++++++++----------------
 xen/include/xen/domain.h                |  1 +
 9 files changed, 65 insertions(+), 71 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/se=
tup.h
index 6cf272c160..f107e8eebb 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -25,8 +25,6 @@ struct map_range_data
     struct rangeset *irq_ranges;
 };
=20
-extern domid_t max_init_domid;
-
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
=20
 size_t estimate_efi_size(unsigned int mem_nr_banks);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 734e23da44..0a18d479f9 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -61,8 +61,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
 bool __read_mostly acpi_disabled;
 #endif
=20
-domid_t __read_mostly max_init_domid;
-
 static __used void init_done(void)
 {
     int rc;
diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/se=
tup.h
index e4f64879b6..956fa6985a 100644
--- a/xen/arch/ppc/include/asm/setup.h
+++ b/xen/arch/ppc/include/asm/setup.h
@@ -1,6 +1,4 @@
 #ifndef __ASM_PPC_SETUP_H__
 #define __ASM_PPC_SETUP_H__
=20
-#define max_init_domid (0)
-
 #endif /* __ASM_PPC_SETUP_H__ */
diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/as=
m/setup.h
index c9d69cdf51..d1fc64b673 100644
--- a/xen/arch/riscv/include/asm/setup.h
+++ b/xen/arch/riscv/include/asm/setup.h
@@ -5,8 +5,6 @@
=20
 #include 
=20
-#define max_init_domid (0)
-
 void setup_mm(void);
=20
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/se=
tup.h
index ac34c69855..b67de8577f 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -69,6 +69,4 @@ extern bool opt_dom0_verbose;
 extern bool opt_dom0_cpuid_faulting;
 extern bool opt_dom0_msr_relaxed;
=20
-#define max_init_domid (0)
-
 #endif
diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tr=
ee/dom0less-build.c
index 9a6015f4ce..703f20faed 100644
--- a/xen/common/device-tree/dom0less-build.c
+++ b/xen/common/device-tree/dom0less-build.c
@@ -977,8 +977,6 @@ void __init create_domUs(void)
         domid =3D domid_alloc(DOMID_INVALID);
         if ( domid =3D=3D DOMID_INVALID )
             panic("Error allocating ID for domain %s\n", dt_node_name(node=
));
-        if ( max_init_domid < domid )
-            max_init_domid =3D domid;
=20
         d =3D domain_create(domid, &d_cfg, flags);
         if ( IS_ERR(d) )
diff --git a/xen/common/domain.c b/xen/common/domain.c
index d75ece1b61..4a54bc27a3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2461,6 +2461,39 @@ void domid_free(domid_t domid)
     spin_unlock(&domid_lock);
 }
=20
+/*
+ * Find the ID of the next possible console owner domain.
+ *
+ * @return Domain ID: DOMID_XEN or non-system domain IDs within
+ * the range of [0..DOMID_FIRST_RESERVED-1].
+ */
+domid_t domid_find_with_input_allowed(domid_t hint)
+{
+    domid_t domid =3D DOMID_XEN;
+
+    if ( hint < DOMID_FIRST_RESERVED )
+    {
+        struct domain *d;
+
+        rcu_read_lock(&domlist_read_lock);
+
+        for ( d =3D domid_to_domain(hint);
+              d && get_domain(d) && d->domain_id < DOMID_FIRST_RESERVED;
+              d =3D rcu_dereference(d->next_in_list) )
+        {
+            if ( d->console.input_allowed )
+            {
+                domid =3D d->domain_id;
+                break;
+            }
+        }
+
+        rcu_read_unlock(&domlist_read_lock);
+    }
+
+    return domid;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9a9836ba91..37289d5558 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -498,26 +498,17 @@ static void cf_check conring_dump_keyhandler(unsigned=
 char key)
=20
 /*
  * CTRL- changes input direction, rotating among Xen, Dom0,
- * and the DomUs started from Xen at boot.
+ * and the DomUs.
  */
 #define switch_code (opt_conswitch[0]-'a'+1)
-/*
- * console_rx=3D0 =3D> input to xen
- * console_rx=3D1 =3D> input to dom0 (or the sole shim domain)
- * console_rx=3DN =3D> input to dom(N-1)
- */
-static unsigned int __read_mostly console_rx =3D 0;
=20
-#define max_console_rx (max_init_domid + 1)
+/* Console owner domain identifier. */
+static domid_t __read_mostly console_rx =3D DOMID_XEN;
=20
 struct domain *console_get_domain(void)
 {
-    struct domain *d;
+    struct domain *d =3D rcu_lock_domain_by_id(console_rx);
=20
-    if ( console_rx =3D=3D 0 )
-            return NULL;
-
-    d =3D rcu_lock_domain_by_id(console_rx - 1);
     if ( !d )
         return NULL;
=20
@@ -535,43 +526,14 @@ void console_put_domain(struct domain *d)
         rcu_unlock_domain(d);
 }
=20
-static void console_switch_input(void)
+static void console_set_domid(domid_t domid)
 {
-    unsigned int next_rx =3D console_rx;
+    if ( domid =3D=3D DOMID_XEN )
+        printk("*** Serial input to Xen");
+    else
+        printk("*** Serial input to DOM%u", domid);
=20
-    /*
-     * Rotate among Xen, dom0 and boot-time created domUs while skipping
-     * switching serial input to non existing domains.
-     */
-    for ( ; ; )
-    {
-        domid_t domid;
-        struct domain *d;
-
-        if ( next_rx++ >=3D max_console_rx )
-        {
-            console_rx =3D 0;
-            printk("*** Serial input to Xen");
-            break;
-        }
-
-        if ( consoled_is_enabled() && next_rx =3D=3D 1 )
-            domid =3D get_initial_domain_id();
-        else
-            domid =3D next_rx - 1;
-        d =3D rcu_lock_domain_by_id(domid);
-        if ( d )
-        {
-            rcu_unlock_domain(d);
-
-            if ( !d->console.input_allowed )
-                continue;
-
-            console_rx =3D next_rx;
-            printk("*** Serial input to DOM%u", domid);
-            break;
-        }
-    }
+    console_rx =3D domid;
=20
     if ( switch_code )
         printk(" (type 'CTRL-%c' three times to switch input)",
@@ -579,12 +541,30 @@ static void console_switch_input(void)
     printk("\n");
 }
=20
+/*
+ * Switch console focus.
+ * Rotates input focus among Xen and domains with console input permission=
.
+ */
+static void console_switch_input(void)
+{
+    domid_t hint;
+
+    if ( console_rx =3D=3D DOMID_XEN )
+        hint =3D get_initial_domain_id();
+    else
+        hint =3D console_rx + 1;
+
+    hint =3D domid_find_with_input_allowed(hint);
+
+    console_set_domid(hint);
+}
+
 static void __serial_rx(char c)
 {
     struct domain *d;
     int rc =3D 0;
=20
-    if ( console_rx =3D=3D 0 )
+    if ( console_rx =3D=3D DOMID_XEN )
         return handle_keypress(c, false);
=20
     d =3D console_get_domain();
@@ -1169,14 +1149,6 @@ void __init console_endboot(void)
=20
     video_endboot();
=20
-    /*
-     * If user specifies so, we fool the switch routine to redirect input
-     * straight back to Xen. I use this convoluted method so we still prin=
t
-     * a useful 'how to switch' message.
-     */
-    if ( opt_conswitch[1] =3D=3D 'x' )
-        console_rx =3D max_console_rx;
-
     register_keyhandler('w', conring_dump_keyhandler,
                         "synchronously dump console ring buffer (dmesg)", =
0);
     register_irq_keyhandler('+', &do_inc_thresh,
@@ -1186,8 +1158,8 @@ void __init console_endboot(void)
     register_irq_keyhandler('G', &do_toggle_guest,
                             "toggle host/guest log level adjustment", 0);
=20
-    /* Serial input is directed to DOM0 by default. */
-    console_switch_input();
+    if ( opt_conswitch[1] !=3D 'x' )
+        (void)console_set_domid(get_initial_domain_id());
 }
=20
 int __init console_has(const char *device)
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 8aab05ae93..a88eb34f3f 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -36,6 +36,7 @@ void getdomaininfo(struct domain *d, struct xen_domctl_ge=
tdomaininfo *info);
 void arch_get_domain_info(const struct domain *d,
                           struct xen_domctl_getdomaininfo *info);
=20
+domid_t domid_find_with_input_allowed(domid_t hint);
 domid_t get_initial_domain_id(void);
=20
 domid_t domid_alloc(domid_t domid);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 30 23:19:26 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 23:19:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001607.1381751 (Exim 4.92)
	(envelope-from )
	id 1uL90Y-0006Fu-Aw; Fri, 30 May 2025 23:19:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001607.1381751; Fri, 30 May 2025 23:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL90Y-0006Fi-7Y; Fri, 30 May 2025 23:19:26 +0000
Received: by outflank-mailman (input) for mailman id 1001607;
 Fri, 30 May 2025 23:19:24 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL90W-00055p-Py
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 23:19:24 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8587ab02-3dac-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 01:19: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" 
X-Inumbo-ID: 8587ab02-3dac-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=y532ikq7kra7dhltmtp4fdjura.protonmail; t=1748647162; x=1748906362;
	bh=jkfiK442l+6t8tHuxB/JprzcNDyu+sgNZHPHUFa9lYw=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=R4CYcQBGd3VSaCrwWVWPOPLq57+ERM5gNA0mkQ9VY3kwZwHblqr4CJbWs0ZtNQwqz
	 W67sifljb+rsmrA43DjzKs1D2sD8BauHo2lFx8eP/huaC/LbiHBrXdWJWJmnBXk+x+
	 KxR8ljbm9ehSJIvqqy58zginRx5T2FH0DgixNOQ/8/Ny6mbRIfPzcCzhPlLvMlPkaj
	 lA0RMC+dSlosbHblPyWOilSy9AFF7GiHdwfZfHO9VmWouj08bv/HllJEX+4HdlDQd1
	 CwP3pqX4kh+tkp0jPYzmR6uLkwinu2AcdcZpkn8rx9ruB7/o2tYMcvMez9zhXW4Old
	 EZ7gXcJQcgOiA==
Date: Fri, 30 May 2025 23:19:17 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 4/4] xen/console: rename console_rx to console_domid
Message-ID: <20250530231841.73386-5-dmukhin@ford.com>
In-Reply-To: <20250530231841.73386-1-dmukhin@ford.com>
References: <20250530231841.73386-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: a63e93d5e86d2fb5344c6fbbda1c4880a17b4a9b
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Update the symbol name to match the code better.

No functional change.

Signed-off-by: Denis Mukhin 
---
 xen/drivers/char/console.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 37289d5558..5797f29d31 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -503,11 +503,11 @@ static void cf_check conring_dump_keyhandler(unsigned=
 char key)
 #define switch_code (opt_conswitch[0]-'a'+1)
=20
 /* Console owner domain identifier. */
-static domid_t __read_mostly console_rx =3D DOMID_XEN;
+static domid_t __read_mostly console_domid =3D DOMID_XEN;
=20
 struct domain *console_get_domain(void)
 {
-    struct domain *d =3D rcu_lock_domain_by_id(console_rx);
+    struct domain *d =3D rcu_lock_domain_by_id(console_domid);
=20
     if ( !d )
         return NULL;
@@ -533,7 +533,7 @@ static void console_set_domid(domid_t domid)
     else
         printk("*** Serial input to DOM%u", domid);
=20
-    console_rx =3D domid;
+    console_domid =3D domid;
=20
     if ( switch_code )
         printk(" (type 'CTRL-%c' three times to switch input)",
@@ -549,10 +549,10 @@ static void console_switch_input(void)
 {
     domid_t hint;
=20
-    if ( console_rx =3D=3D DOMID_XEN )
+    if ( console_domid =3D=3D DOMID_XEN )
         hint =3D get_initial_domain_id();
     else
-        hint =3D console_rx + 1;
+        hint =3D console_domid + 1;
=20
     hint =3D domid_find_with_input_allowed(hint);
=20
@@ -564,7 +564,7 @@ static void __serial_rx(char c)
     struct domain *d;
     int rc =3D 0;
=20
-    if ( console_rx =3D=3D DOMID_XEN )
+    if ( console_domid =3D=3D DOMID_XEN )
         return handle_keypress(c, false);
=20
     d =3D console_get_domain();
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Fri May 30 23:29:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 23:29:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001639.1381762 (Exim 4.92)
	(envelope-from )
	id 1uL9A1-00006c-7U; Fri, 30 May 2025 23:29:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001639.1381762; Fri, 30 May 2025 23: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 1uL9A1-00006V-4m; Fri, 30 May 2025 23:29:13 +0000
Received: by outflank-mailman (input) for mailman id 1001639;
 Fri, 30 May 2025 23:29:12 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL9A0-00006P-Bw
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 23:29:12 +0000
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch
 [79.135.106.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e347000f-3dad-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 01:29: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" 
X-Inumbo-ID: e347000f-3dad-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748647749; x=1748906949;
	bh=FtPy38Dsm8VtkwD9F5AO0fkUKU8XO7MM0Yq6kWapgko=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=RaOhDx0oEvgCC8N+YJGDLdsYsmEJUIORIc+FdKA/tg9eww+kXjb75FJN29IIWqQCz
	 oavLwe//hP6matdqEq6J5lqzxvLbzPySp+O0IRbDMTTNRYjGI7A2xS7sikoOizkSuN
	 rdqYXLwzR2OY5YjliqBFltshb8weh+71XeearcDMos17c1fQLit8PQg+N9pEptzKqN
	 FGfubs6y5g/8zfGQIYwgWhxU2sJUVSRlFb+fzw5mb2d8eRimfjiv4RWS4/7XqOppwj
	 xLMUUE53xIQaqo5XcUuTFzhDMF3crkFTiElzCLcIRDh2gX3T5l0Z+5t6d9vU0BtbDh
	 M75qnZyE/KoVw==
Date: Fri, 30 May 2025 23:29:04 +0000
To: Stefano Stabellini 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com
Subject: Re: [PATCH v4 3/4] xen/console: remove max_init_domid dependency
Message-ID: 
In-Reply-To: 
References: <20250529000848.2675903-1-dmukhin@ford.com> <20250529000848.2675903-4-dmukhin@ford.com> 
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: b3c5669ff0dc80339fef03393ae1683e3d26ddaa
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 29, 2025 at 05:58:20PM -0700, Stefano Stabellini wrote:
> On Thu, 29 May 2025, dmkhn@proton.me wrote:
> > From: Denis Mukhin 
> >
> > From: Denis Mukhin 
> >
> > The physical console input rotation depends on max_init_domid symbol, w=
hich is
> > managed differently across architectures.
> >
> > Instead of trying to manage max_init_domid in the arch-common code the =
console
> > input rotation code can be reworked by removing dependency on max_init_=
domid
> > entirely.
> >
> > To do that, introduce domid_find_with_input_allowed() in arch-independe=
nt
> > location to find the ID of the next possible console owner domain. The =
IDs
> > are rotated across non-system domain IDs and DOMID_XEN.
> >
> > Also, introduce helper console_set_domid() for updating identifier of t=
he
> > current console input owner (points to Xen or domain).
> >
> > Use domid_find_with_input_allowed() and console_set_domid() in
> > console_switch_input().
> >
> > Remove uses of max_init_domid in the code.
> >
> > Signed-off-by: Denis Mukhin 
> > ---
> > Changes since v3:
> > - switched to RCU lock in domid_find_with_input_allowed()
> > ---
> >  xen/arch/arm/include/asm/setup.h        |  2 -
> >  xen/arch/arm/setup.c                    |  2 -
> >  xen/arch/ppc/include/asm/setup.h        |  2 -
> >  xen/arch/riscv/include/asm/setup.h      |  2 -
> >  xen/arch/x86/include/asm/setup.h        |  2 -
> >  xen/common/device-tree/dom0less-build.c |  2 -
> >  xen/common/domain.c                     | 29 ++++++++
> >  xen/drivers/char/console.c              | 90 +++++++++----------------
> >  xen/include/xen/domain.h                |  1 +
> >  9 files changed, 61 insertions(+), 71 deletions(-)
> >
> > diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/as=
m/setup.h
> > index 6cf272c160..f107e8eebb 100644
> > --- a/xen/arch/arm/include/asm/setup.h
> > +++ b/xen/arch/arm/include/asm/setup.h
> > @@ -25,8 +25,6 @@ struct map_range_data
> >      struct rangeset *irq_ranges;
> >  };
> >
> > -extern domid_t max_init_domid;
> > -
> >  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> >
> >  size_t estimate_efi_size(unsigned int mem_nr_banks);
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 10b46d0684..53e2f8b537 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -61,8 +61,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
> >  bool __read_mostly acpi_disabled;
> >  #endif
> >
> > -domid_t __read_mostly max_init_domid;
> > -
> >  static __used void init_done(void)
> >  {
> >      int rc;
> > diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/as=
m/setup.h
> > index e4f64879b6..956fa6985a 100644
> > --- a/xen/arch/ppc/include/asm/setup.h
> > +++ b/xen/arch/ppc/include/asm/setup.h
> > @@ -1,6 +1,4 @@
> >  #ifndef __ASM_PPC_SETUP_H__
> >  #define __ASM_PPC_SETUP_H__
> >
> > -#define max_init_domid (0)
> > -
> >  #endif /* __ASM_PPC_SETUP_H__ */
> > diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/includ=
e/asm/setup.h
> > index c9d69cdf51..d1fc64b673 100644
> > --- a/xen/arch/riscv/include/asm/setup.h
> > +++ b/xen/arch/riscv/include/asm/setup.h
> > @@ -5,8 +5,6 @@
> >
> >  #include 
> >
> > -#define max_init_domid (0)
> > -
> >  void setup_mm(void);
> >
> >  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> > diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/as=
m/setup.h
> > index ac34c69855..b67de8577f 100644
> > --- a/xen/arch/x86/include/asm/setup.h
> > +++ b/xen/arch/x86/include/asm/setup.h
> > @@ -69,6 +69,4 @@ extern bool opt_dom0_verbose;
> >  extern bool opt_dom0_cpuid_faulting;
> >  extern bool opt_dom0_msr_relaxed;
> >
> > -#define max_init_domid (0)
> > -
> >  #endif
> > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/devic=
e-tree/dom0less-build.c
> > index 9a6015f4ce..703f20faed 100644
> > --- a/xen/common/device-tree/dom0less-build.c
> > +++ b/xen/common/device-tree/dom0less-build.c
> > @@ -977,8 +977,6 @@ void __init create_domUs(void)
> >          domid =3D domid_alloc(DOMID_INVALID);
> >          if ( domid =3D=3D DOMID_INVALID )
> >              panic("Error allocating ID for domain %s\n", dt_node_name(=
node));
> > -        if ( max_init_domid < domid )
> > -            max_init_domid =3D domid;
> >
> >          d =3D domain_create(domid, &d_cfg, flags);
> >          if ( IS_ERR(d) )
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 9bc66d80c4..704e0907e9 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -2463,6 +2463,35 @@ void domid_free(domid_t domid)
> >      spin_unlock(&domid_lock);
> >  }
> >
> > +/*
> > + * Find the ID of the next possible console owner domain.
> > + *
> > + * @return Domain ID: DOMID_XEN or non-system domain IDs within
> > + * the range of [0..DOMID_FIRST_RESERVED-1].
> > + */
> > +domid_t domid_find_with_input_allowed(domid_t hint)
> > +{
> > +    const struct domain *d;
> > +    domid_t domid =3D DOMID_XEN;
> > +
> > +    rcu_read_lock(&domlist_read_lock);
> > +
> > +    for ( d =3D rcu_dereference(domain_list);
> > +          d && d->domain_id < DOMID_FIRST_RESERVED;
> > +          d =3D rcu_dereference(d->next_in_list) )
> > +    {
> > +        if ( d->console.input_allowed )
> > +        {
> > +            domid =3D d->domain_id;
> > +            break;
> > +        }
> > +    }
> > +
> > +    rcu_read_unlock(&domlist_read_lock);
>=20
> Doesn't this always return the first domid with input_allowed given that
> hint is not used? It looks like it wouldn't work right...
>=20
>=20
> > +    return domid;
> > +}
> > +
> >  /*
> >   * Local variables:
> >   * mode: C
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 8a0bcff78f..37289d5558 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -498,26 +498,17 @@ static void cf_check conring_dump_keyhandler(unsi=
gned char key)
> >
> >  /*
> >   * CTRL- changes input direction, rotating among Xen, Dom=
0,
> > - * and the DomUs started from Xen at boot.
> > + * and the DomUs.
> >   */
> >  #define switch_code (opt_conswitch[0]-'a'+1)
> > -/*
> > - * console_rx=3D0 =3D> input to xen
> > - * console_rx=3D1 =3D> input to dom0 (or the sole shim domain)
> > - * console_rx=3DN =3D> input to dom(N-1)
> > - */
> > -static unsigned int __read_mostly console_rx =3D 0;
> >
> > -#define max_console_rx (max_init_domid + 1)
> > +/* Console owner domain identifier. */
> > +static domid_t __read_mostly console_rx =3D DOMID_XEN;
> >
> >  struct domain *console_get_domain(void)
> >  {
> > -    struct domain *d;
> > +    struct domain *d =3D rcu_lock_domain_by_id(console_rx);
> >
> > -    if ( console_rx =3D=3D 0 )
> > -            return NULL;
> > -
> > -    d =3D rcu_lock_domain_by_id(console_rx - 1);
> >      if ( !d )
> >          return NULL;
> >
> > @@ -535,43 +526,14 @@ void console_put_domain(struct domain *d)
> >          rcu_unlock_domain(d);
> >  }
> >
> > -static void console_switch_input(void)
> > +static void console_set_domid(domid_t domid)
> >  {
> > -    unsigned int next_rx =3D console_rx;
> > +    if ( domid =3D=3D DOMID_XEN )
> > +        printk("*** Serial input to Xen");
> > +    else
> > +        printk("*** Serial input to DOM%u", domid);
> >
> > -    /*
> > -     * Rotate among Xen, dom0 and boot-time created domUs while skippi=
ng
> > -     * switching serial input to non existing domains.
> > -     */
> > -    for ( ; ; )
> > -    {
> > -        domid_t domid;
> > -        struct domain *d;
> > -
> > -        if ( next_rx++ >=3D max_console_rx )
> > -        {
> > -            console_rx =3D 0;
> > -            printk("*** Serial input to Xen");
> > -            break;
> > -        }
> > -
> > -        if ( consoled_is_enabled() && next_rx =3D=3D 1 )
> > -            domid =3D get_initial_domain_id();
> > -        else
> > -            domid =3D next_rx - 1;
> > -        d =3D rcu_lock_domain_by_id(domid);
> > -        if ( d )
> > -        {
> > -            rcu_unlock_domain(d);
> > -
> > -            if ( !d->console.input_allowed )
> > -                break;
> > -
> > -            console_rx =3D next_rx;
> > -            printk("*** Serial input to DOM%u", domid);
> > -            break;
> > -        }
> > -    }
> > +    console_rx =3D domid;
> >
> >      if ( switch_code )
> >          printk(" (type 'CTRL-%c' three times to switch input)",
> > @@ -579,12 +541,30 @@ static void console_switch_input(void)
> >      printk("\n");
> >  }
> >
> > +/*
> > + * Switch console focus.
> > + * Rotates input focus among Xen and domains with console input permis=
sion.
> > + */
> > +static void console_switch_input(void)
> > +{
> > +    domid_t hint;
> > +
> > +    if ( console_rx =3D=3D DOMID_XEN )
> > +        hint =3D get_initial_domain_id();
> > +    else
> > +        hint =3D console_rx + 1;
> > +
> > +    hint =3D domid_find_with_input_allowed(hint);
> > +
> > +    console_set_domid(hint);
> > +}
> > +
> >  static void __serial_rx(char c)
> >  {
> >      struct domain *d;
> >      int rc =3D 0;
> >
> > -    if ( console_rx =3D=3D 0 )
> > +    if ( console_rx =3D=3D DOMID_XEN )
> >          return handle_keypress(c, false);
> >
> >      d =3D console_get_domain();
> > @@ -1169,14 +1149,6 @@ void __init console_endboot(void)
> >
> >      video_endboot();
> >
> > -    /*
> > -     * If user specifies so, we fool the switch routine to redirect in=
put
> > -     * straight back to Xen. I use this convoluted method so we still =
print
> > -     * a useful 'how to switch' message.
> > -     */
> > -    if ( opt_conswitch[1] =3D=3D 'x' )
> > -        console_rx =3D max_console_rx;
> > -
> >      register_keyhandler('w', conring_dump_keyhandler,
> >                          "synchronously dump console ring buffer (dmesg=
)", 0);
> >      register_irq_keyhandler('+', &do_inc_thresh,
> > @@ -1186,8 +1158,8 @@ void __init console_endboot(void)
> >      register_irq_keyhandler('G', &do_toggle_guest,
> >                              "toggle host/guest log level adjustment", =
0);
> >
> > -    /* Serial input is directed to DOM0 by default. */
> > -    console_switch_input();
> > +    if ( opt_conswitch[1] !=3D 'x' )
> > +        (void)console_set_domid(get_initial_domain_id());
>=20
> We should use domid_find_with_input_allowed instead of assuming
> get_initial_domain_id() has input_allowed?

AFAIU, get_initial_domain_id() is not necessarily created by the time this =
code
is reached. In this case, relying on domid_find_with_input_allowed() will k=
eep
console focus in Xen, which will be a behavior change.

I kept this hunk as is in v5.

>=20
>=20
>=20
> >  }
> >
> >  int __init console_has(const char *device)
> > diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> > index 8aab05ae93..a88eb34f3f 100644
> > --- a/xen/include/xen/domain.h
> > +++ b/xen/include/xen/domain.h
> > @@ -36,6 +36,7 @@ void getdomaininfo(struct domain *d, struct xen_domct=
l_getdomaininfo *info);
> >  void arch_get_domain_info(const struct domain *d,
> >                            struct xen_domctl_getdomaininfo *info);
> >
> > +domid_t domid_find_with_input_allowed(domid_t hint);
> >  domid_t get_initial_domain_id(void);
> >
> >  domid_t domid_alloc(domid_t domid);
> > --
> > 2.34.1
> >
> >



From xen-devel-bounces@lists.xenproject.org Fri May 30 23:55:15 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 23:55:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001650.1381772 (Exim 4.92)
	(envelope-from )
	id 1uL9Z7-0003qt-UJ; Fri, 30 May 2025 23:55:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001650.1381772; Fri, 30 May 2025 23:55:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL9Z7-0003qm-QZ; Fri, 30 May 2025 23:55:09 +0000
Received: by outflank-mailman (input) for mailman id 1001650;
 Fri, 30 May 2025 23:55:09 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL9Z7-0003qg-2F
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 23:55:09 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20605.outbound.protection.outlook.com
 [2a01:111:f403:2409::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 81155297-3db1-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 01:55:03 +0200 (CEST)
Received: from CH0PR03CA0328.namprd03.prod.outlook.com (2603:10b6:610:118::14)
 by SJ0PR12MB7473.namprd12.prod.outlook.com (2603:10b6:a03:48d::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.30; Fri, 30 May
 2025 23:54:58 +0000
Received: from DS3PEPF000099D6.namprd04.prod.outlook.com
 (2603:10b6:610:118:cafe::e5) by CH0PR03CA0328.outlook.office365.com
 (2603:10b6:610:118::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.24 via Frontend Transport; Fri,
 30 May 2025 23:54:58 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS3PEPF000099D6.mail.protection.outlook.com (10.167.17.7) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 30 May 2025 23:54:57 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 18:54:56 -0500
Received: from [172.31.32.79] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 30 May 2025 18:54: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" 
X-Inumbo-ID: 81155297-3db1-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QlaO9sTsf3Qn595OA0MG9ZGbRg/3D8IuXDZ0Z5hsQlCyTOEeP2CmzMfpSgKB+E8V+kZiY8W7ULwvAsHVZ0EskMJBhmtsZUzWMRNoHNxsWIyC756Y4r7mIJD17Vx2gAAd6Jh1sTA4FYNWjbWOR1mtxhDnKsUp/ryPVMgayQP5So6SV4637CKDcSCeKtuVmuiWGlTT6Y3OsIV9jCuqJyWU3PEy8GvtWRsDUB318f9ZXDwm0sIbdn56tn2QtbWuPs6fIYudvNY5SJI1PyPs4m82kHvcyyaIG7AchkxtoKcB8RLUagfcqAdFtvYJ8mODl413nUIj5jiktp0cQF7KFx5fCw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=omHrdZsHmHfJKXsA9dMmnFTx4IsI+IuuaZBByPFTnFE=;
 b=KWmvzsb+Gmc07utLoBpsVk/MVlwihvhEnNP2lFgLdCLXuZmJAXavc0rpP2x5tfKg2/LjPJeDA/A2J+D8sJDU/GK2uZ9q0kOz95Nm0GF5MgrBytM/qcPf27XGpu+nDu2ncD+5+AJGa1iVzo4Whw8MsERKorWAfZ59btjXN++6u2BTl7Xu/rKUyj9Pw2/hCc+F8Cnr526KZM+ANnB1hVtj3q0DtSumZMVTwz1PxdJDd7KPUuFUA864gqcqIG0BWniHu3GI/oUf03h1ECPqE1QtFRr2udBlh/3CwvS5yH6EOIsRvQZZ6N/GIX7ESu1PS+mPljYIxa5F320LNo95Y7yebA==
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=omHrdZsHmHfJKXsA9dMmnFTx4IsI+IuuaZBByPFTnFE=;
 b=wCzwK3hJjfsSn2pOlGHvCGbMQ47DGUEITNlSQHh7pXJktfEUBa5FgFAV2qUASxL2VFOoeCvwlohABrdi/K+NW3w19aQ9L+VJc1qr5leqbYWlBtspDPWdm2/ge0BrRRlZuYCDKi8lhNjzmWtVcKC7O4ZDhzuoBy0DWttP5Ha+Juk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <9b5a1599-d8dc-423d-b144-90bfe33cdae9@amd.com>
Date: Fri, 30 May 2025 17:04:07 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in
 asm/pci.h
To: Alejandro Vallejo , 
CC: Jan Beulich , Andrew Cooper
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	, "Daniel P. Smith" 
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-3-agarciav@amd.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250530120242.39398-3-agarciav@amd.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF000099D6:EE_|SJ0PR12MB7473:EE_
X-MS-Office365-Filtering-Correlation-Id: 7c68f052-75f8-4dac-451a-08dd9fd561e9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?R1F1TTFpR1NtTEVTWVhXaGdjaFJydlcybnBsMVhySUZKQWIrZzBkUEhIajRC?=
 =?utf-8?B?K0RlZmUwSEUzbEUwekpPYW9XMWcvYjhrcWVRVkFReDRNM0JocnF0K1RTSFR4?=
 =?utf-8?B?RE5obkRzRzJDa1BxY1p2MTJiMEJxWGs0S2pWRUxGWUlXeDlnOHhIRzVPanY5?=
 =?utf-8?B?bHJxUGdPTnMwSEZ1SlZNbHdxYWF3bG9nOUcvQTFuendDSVpBZFhmRTJsK0pW?=
 =?utf-8?B?WHpVdzNQUHlsdkZmSnNkeXZuVnB1b0d3QTdSTGY4TVhLcGtnMDdRYzBXZmhU?=
 =?utf-8?B?SEtZSVZ5OEN5SjlRTnE2WGRzQ0tRWnhFZkt0b3BIUFRMY2VISWN1cS9TV212?=
 =?utf-8?B?bzNTWWlhbFA1RzlJamwzYndxL21KL000dWhyOTVsNlIyc3hGU056OHJVaDNs?=
 =?utf-8?B?TnNNUU80aHpmdFRxaEhJbFdwM1Fia3lpUUN4b1UwaHdMaS9IczlmWHRkUGl2?=
 =?utf-8?B?WTlhUVpXN1RZdTJOSTc0cVFnMVJOa2QvUjNqQllVR1g4SEVMUy8rWHJzWjds?=
 =?utf-8?B?aDRMbzlYMzB4YzB0a3J3Z3VjZUxZdTVwMnducmJrdWxQaUpkODhwR2ROVzBY?=
 =?utf-8?B?c2kwNTFWL0s2a0d5VzdPb3hGSE5KUW1qa3NMKzBmYkNFcDJOUy9SNE9VYktn?=
 =?utf-8?B?ckUwZG5VQTV1Wi8rb2hSaFloKzJkcWJQYnJtWjVBUmwvZWhuRnJWank1UWFh?=
 =?utf-8?B?dmdqd3l5UUg4Q3lZamRrdzFMdkJzcEFaR0dNTUNNSlVPOERsUzQ0ejlWZTYr?=
 =?utf-8?B?c1pPd3U3dG5pd0hGcW5QTjZXZWdJaTloUlFEbUJxU2xmRTN0YWRqclhDY3BL?=
 =?utf-8?B?QksvbjZzczJ1VHRmTnlvZVplVjhQTDhIZDZHTXZCSE0yeG10N2RzNE9ldjNs?=
 =?utf-8?B?ZmczOHRzZFIwdVlIMWM5ekJzYmVVMDZUYzk3V29PNjhiV0dDOXFlQWViRDE2?=
 =?utf-8?B?Z3NvUC9NSHJjc1RHejcwWlVPNHIyTXMydFRiSXp3YXA5YVg0NU5MQXlxdXJt?=
 =?utf-8?B?UHNVRndFREFQRnVVM25ua2MzYXZVSFdUdm5qTmkrQlRvclZwVkpyNDRjandF?=
 =?utf-8?B?cGxkVytzLy9yWXl5ajNUNXJLa2Y1WDYwWkxHdW9VekpYTHhwSVU4YWVZN1px?=
 =?utf-8?B?N1FMdURVajE2SGNiS3ZvYTFqVVNrSGIxMi85aTJiQlhPek02aW9KVjFsWVpG?=
 =?utf-8?B?QmZaZE1ZTFdRRkpQUE56YWViMTZZd3FEVGtXMEtleXM0ZTQ3RHlRVDhRaTdX?=
 =?utf-8?B?UlZwaU93UVkzQzdmdHJuSFA1aHRRdDdKclVRemFSeGt0WTJEUG9JdzBUS3V1?=
 =?utf-8?B?anZTNHVaYVNqYVdsNWlkRVpDZHZ3c1AwOXhVTWtkWi9QMmxkaWxGUnVON05H?=
 =?utf-8?B?Z0NKY0g1bHJYOU5aRmxQdGtpTU9BTi8rMVhTUkNNM1RzdHN0eUU2M0dQTG96?=
 =?utf-8?B?cGE5SVNKTEZlcktidlBJa1lIN2hucEpvcCsvQXBWQnROeGNKbldXTVkxWm4x?=
 =?utf-8?B?cE5zamRXeU8yTXJST3R2WEJMSzRHRlFQU0lyb2xpNlc0TmNwOGdaby91SFFZ?=
 =?utf-8?B?VHJxMW5WY3d0dEVhZThPYmxzNGFNN3ZwTXA0L0JXOW1vTVhIWit4S2tPNFRx?=
 =?utf-8?B?ZkVCRkdnL2tHbVpoKzJJZm8waUhaQTgvcW05dG1zS1pSZytOYVVOS2FWSVlZ?=
 =?utf-8?B?eVJHMWRIcys3YVlpTGVDc1ZXaFdQRkxPRjdRd0FiRGlCSzM5ZXRrR3BZdDMr?=
 =?utf-8?B?a2ltaTVITE9JUGU0WmRabndQcm12bWl2cExnOVNQaW00dkNaS2VSWlBBWXNx?=
 =?utf-8?B?dTdlcldZYkRmZW1qYnRYMDcyRWhMdXBDYVluczlOdU9NTnR5VXRERHVoSk9J?=
 =?utf-8?B?c2YwcS9iL2UxUUNhcWRIMFVhcWZydXBDZmo4NWRXNHBxcFJjSjlDcExxbC9S?=
 =?utf-8?B?RHJJOFpsM2FsSXl4OUI1eTZWUUwvRjB3QTUxdlNyWFoxZmh4dmQzNFhGU20r?=
 =?utf-8?B?cGFzeWRGdjVNZ0l2RGtFdWwvMTNUdEJRMU92WGRteEtDenltTEJLSHllVjVn?=
 =?utf-8?Q?UbbamL?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 23:54:57.5141
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c68f052-75f8-4dac-451a-08dd9fd561e9
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF000099D6.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB7473

On 2025-05-30 08:02, Alejandro Vallejo wrote:
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 

Some sort of reason would be good in the commit message.

"struct pci_dev is used in function prototypes within the header.  This 
is in preparation for including (transitively) in device tree"?

... I'm guessing that is why.  Stating  it would be better.

With a suitable reason:

Reviewed-by: Jason Andryuk 

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Fri May 30 23:55:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 30 May 2025 23:55:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001651.1381782 (Exim 4.92)
	(envelope-from )
	id 1uL9ZK-00048A-3y; Fri, 30 May 2025 23:55:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001651.1381782; Fri, 30 May 2025 23: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 1uL9ZK-000483-1A; Fri, 30 May 2025 23:55:22 +0000
Received: by outflank-mailman (input) for mailman id 1001651;
 Fri, 30 May 2025 23:55:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uL9ZJ-00046w-0W
 for xen-devel@lists.xenproject.org; Fri, 30 May 2025 23:55:21 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20624.outbound.protection.outlook.com
 [2a01:111:f403:2415::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 89f5fea4-3db1-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 01:55:18 +0200 (CEST)
Received: from SA1PR03CA0005.namprd03.prod.outlook.com (2603:10b6:806:2d3::6)
 by CH3PR12MB9022.namprd12.prod.outlook.com (2603:10b6:610:171::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Fri, 30 May
 2025 23:55:12 +0000
Received: from SN1PEPF000397B0.namprd05.prod.outlook.com
 (2603:10b6:806:2d3:cafe::2) by SA1PR03CA0005.outlook.office365.com
 (2603:10b6:806:2d3::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.24 via Frontend Transport; Fri,
 30 May 2025 23:55:12 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SN1PEPF000397B0.mail.protection.outlook.com (10.167.248.54) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Fri, 30 May 2025 23:55:11 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
 2025 18:55:10 -0500
Received: from [172.31.32.79] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 30 May 2025 18:55: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" 
X-Inumbo-ID: 89f5fea4-3db1-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=beSUZqRkHyGVhab6OBUexRP2NFCPbph2rbPzJNMAP3wZj4L6E/LDvHgWfvAv7YJx5+5eJp5Z28+bwDXjdg5biKF8qOZHd4Nh31VcYRD8k7/5RdHxWyiT0e8AM4Vt/KVWqr3k9jn02z9tneG0LK3c4zE6/zzktWfaVPuJNhDBiaq82k86P4uWo/2fS5FgI9+J+Hn9lTMEm6l5I6wU4BuXU4mGOWp+cc5ElgWTjs+b8DGkK3SFp1pM2pSfxmR/qri12WbB+HsrnZ8T3dRB6RnJqKap8BgPRmF5Bod6ajVBnTdsEXQc/U77d2kPeG6J+ezInNKF2h3+H5S3gVl9rBfbAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cSitg0yvv/akCMm3T4phuNb/n4z5QYfKBxzh90qkE5o=;
 b=nUSvW8NBqBZUMHvgOWpL83Lfe9mLybhV1leA19aplvWQ1izqnm40s+kndBnfHIiNv8td2OWLryYC/44JteyxOZThCuOBy1WSMNCg4QotT2nby+GPxtt+t2+UIqDr/rmwZ/lNe4658aIlUgC9qimPM5HjGVY3RTfUS0Dn6ZXximZCBrlsqFjGNXvxjx7wWgzxyNnBDc8ZZPk8+C30cnvnXG2bNT5E/QA0YsrSMTklkjRQIECd2jIHZqbo64lEf4lWYbgJGy9mWqZlnY9asGLfwLw3vcGgyhBR/unGkhPiXSt8ciopaqnBrAaqIcactAvpqy6L9ZrCPG0/pT/c/QybRA==
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=cSitg0yvv/akCMm3T4phuNb/n4z5QYfKBxzh90qkE5o=;
 b=WfHDmjAZLKE6QULTFu2uXTlhjb+KzllUBQJR3LWA4KnhS7fopWGbVGkPzQHn0CAWJgkBkCfYXktEV2PXLYaA+cVNHol6c5J/xMtG3Ii6VGfG0JNpD/aC1bE79DZJkeBqIb606PX1Z/S8f8C3rerNYU+6Z1oRB6YfGdCNJkV39fQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Fri, 30 May 2025 17:04:20 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h
 and xen/grant_table.h
To: Alejandro Vallejo , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Michal Orzel
	, Volodymyr Babchuk ,
	Andrew Cooper , Anthony PERARD
	, Jan Beulich ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith"
	
References: 
 <20250530120242.39398-1-agarciav@amd.com>
 <20250530120242.39398-8-agarciav@amd.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20250530120242.39398-8-agarciav@amd.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000397B0:EE_|CH3PR12MB9022:EE_
X-MS-Office365-Filtering-Correlation-Id: cfd670e9-0c32-49a6-2b70-08dd9fd56a22
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700013|7416014|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ZFZDSkNjVGYwRTQ2dnlaSEwyZTlTbjVGTWFGelVaR01jRlkwK01aUXRFaDl0?=
 =?utf-8?B?dkY3WVRoMWc1eVdnK0VjQW5LVjZqVFRSVE1xZUljZVpUUktCbXpyVXVVK3VQ?=
 =?utf-8?B?WUx0YUlpaHFMaTV1bjhSVy9hL041a2NLKzZBMEJmRy9ZRnp0dkpEYjhHZmo4?=
 =?utf-8?B?VVcrQ254bG1RSEV0bFJNeURxem5uYS9TeVM2ZEE4dVlLcGVnZDNkRUVrTXVT?=
 =?utf-8?B?ZGlVT0YxVUh1cTNnMC9ZT0E1WlZlS1M2UDBpRmc3VUIwWGM5dWFsK0ZPNlYy?=
 =?utf-8?B?RGhkdXp5OFBQb3lTQTY2R0RLUWdMWm83QlNXbXhaYWNtUDJSV3dHRFZwRExo?=
 =?utf-8?B?c1ZaZVViTHNkQnZ1ZXlSZUNwQ0FpRUtHdUtiRTdjS2dOamUzMGhaT3R2c0Vq?=
 =?utf-8?B?Zkc3UmM0MFJQcGRvb213aUVDdUNZVmxha2ZlNmoyTDZ6T2xoRlJjNjVvSGdD?=
 =?utf-8?B?SmtyMUJHc3FuUnpKRXExSnc3ci91dlV3UitvS3FCei9hTk1TNlRWWVRSVU9k?=
 =?utf-8?B?QUhmQ0d5OVJTNEhoa3hGbnBHNG42UFpvN3ZQK0NZYnV5MjlOTytLdDlmdWpG?=
 =?utf-8?B?bll4QndtekxwSzhGa2R2N00xdHdxdDR3eXdqM2p6Zkp2V2xJWkRNdlJ2bjJX?=
 =?utf-8?B?REIyNnRwTnBsRi9YOEw1Ly9adDluNHJRdkJ5bTJYcHNoUVFyQnZVODJsd1NO?=
 =?utf-8?B?WjF5V2I1eWJxRkpuL0V1WXVZVnhGanIyYWhObUF5UDZKMW5EMEJsK2tScDB6?=
 =?utf-8?B?MkhEVWF6Q09ZV2JVZEE5TTVnNStiOGs4OEgzUldDYThYaWwyZjlSL3FUNDNv?=
 =?utf-8?B?MFR0L1dhMVIxQlJob3B4T3ZDL3VkeXZzTkVmbnlpK0pqMjVjVXE5eXlZRjVQ?=
 =?utf-8?B?a0t5OXIzTm4ybFNmVXE5b0l3QUNmUkpQK2t3MWpJTERub0h5SkxzUW1GdEdT?=
 =?utf-8?B?WnBLVTNEV1o2NHhpY3lZVHlqdGpYQVYzZXl3Vlkrc1QzSlpMZjBITGs5emlL?=
 =?utf-8?B?MVNrclBBVFhFRDRTMjRxM1ZTVEZXN0Y0ZG5iKzlpdTF5U3BnVkMzQlgrMjI4?=
 =?utf-8?B?Ym5qWUg2c1B1MjRvTDRjZ01LY041S3RsODF5OGhsM3g3VHg5d2pxRVJYVkZU?=
 =?utf-8?B?QTZSWlNYLzIvLytPUENmTGMya1JxYm1jYW5DQXMvSFB5bDhvWUVZdFlnc1Bx?=
 =?utf-8?B?dVVHdWdYR2djcjZYRllTZVZHbkpUYjBhQlAyZWxNK2RoMHl6bzhWUmo5Rjhp?=
 =?utf-8?B?RzNrdFYraDRtaDhDSkhLS0NzNk95Wm9Vc2kxVFRVTFBta3Y5RG0rZHA0RTlm?=
 =?utf-8?B?TEdTQy9uMUNMdmZ6VW1xczc5RzlXbDl0ZGs2U3BDSllKZEhJckVxWlNNbTlS?=
 =?utf-8?B?cHVMSUZHcCtVMlV2SGsvVzMvVjhiWmhpMFlZcURaNTNyNkVMaGtOQ0Vnd1pw?=
 =?utf-8?B?cUdvU2RXd0RtcnhWN1NCTFN1VVZqRVJMdDFFdnJyT1NnMTZ6THBTZ3BqREpB?=
 =?utf-8?B?OHFvU0cySnMzdDFaTUtKU1JIamdDRktXemwxbnNFMWh3TXAyeFpMTE1rTFVT?=
 =?utf-8?B?bm9mT3ZnQTlKRUk2Z3ozZmdDRDQ1VTRwS1pGbkpZV1VYdlZpVk9WSGVqbmFy?=
 =?utf-8?B?VE5GMnhwRVpMQ3FFcUFvamQ4eG5mUDhyMldqRDF1eTBoMjFKeEJYRTYwQVo4?=
 =?utf-8?B?LzBkQ2hmeDdoRHk5Zy95U1VsNkI0Tm8rQnhpYVhKR2xIZUlvOStja0E4Z2Rh?=
 =?utf-8?B?bTlESCs4dEcrRmlpM2wySlRNQ25RNnZXMm5TM3pJZWUwc0hVdDhnQTNuaXJk?=
 =?utf-8?B?WmZaY2FlREYvdmU5UUFON2FnWDM0aVI3MkxEQWVmOStQVmpPazBHeWJ4RlY2?=
 =?utf-8?B?T1NES2hLb1BBcjlFTmpVVGxYS2tLV3N5NzRxOTdCMEw5aERSSkxCSmdFNkEv?=
 =?utf-8?B?dnllMHl5VUdPaVdaWExIem1kYURqek9mSWxSQzUrWExxOVZMZ3V4bGtLcnBD?=
 =?utf-8?B?WStqSkhxdjFGY3VSTDMyQWJVczEyaWI0YmZVZ0FlcVdPdkFUbGxLbzU4Nng4?=
 =?utf-8?Q?TrJ1iz?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:ErrorRetry;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(7416014)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 23:55:11.3219
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cfd670e9-0c32-49a6-2b70-08dd9fd56a22
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000397B0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9022

On 2025-05-30 08:02, Alejandro Vallejo wrote:
> xen/grant_table is meant to pull asm/grant_table, when it exists.
> 
> Signed-off-by: Alejandro Vallejo 

I think you can also remove this one:
xen/arch/arm/dom0less-build.c:#include 

With that,
Reviewed-by: Jason Andryuk 

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Sat May 31 00:04:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:04:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001668.1381792 (Exim 4.92)
	(envelope-from )
	id 1uL9iB-0006dW-6S; Sat, 31 May 2025 00:04:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001668.1381792; Sat, 31 May 2025 00:04: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 1uL9iB-0006dP-3V; Sat, 31 May 2025 00:04:31 +0000
Received: by outflank-mailman (input) for mailman id 1001668;
 Sat, 31 May 2025 00:04:29 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL9i8-0006dJ-UL
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:04:29 +0000
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch
 [109.224.244.17]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d0d5ea25-3db2-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 02:04: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" 
X-Inumbo-ID: d0d5ea25-3db2-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748649865; x=1748909065;
	bh=P0KFPXRNFha4C1g1/gQvujKgHbaoPQkoWI2mThU2DxU=;
	h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector:
	 List-Unsubscribe:List-Unsubscribe-Post;
	b=KIlvTV94IptGK8ZFb+yJyEQad1OInERune9k4HDk1zjxx+EksFunD9uKn2PPHNZec
	 VBDtWaIki95Wx8Z3oH077Jy6iWO999SUgQ/04fgo7SLSiknpFejpojIG9oSpboL0Lq
	 7wcYLRjiK4mOe/avB9MhAWZW/8AZzRKdonGlNIUefug/xxdBAdKc2acRewR9Ro/4Lc
	 giLjoL9stL8N7oLHJMRcE3Kn406X4pMXMX7O4QQFWaxigCcYVJgiUjEA5Hr90iFuJY
	 IBe6+mbRRGQJzqXz0GWjA3/kmqAh5KexN9ZKAS5DT6iVbFBzLSVOBrVxnb1GABLXKH
	 i1P8jnVX5fTGA==
Date: Sat, 31 May 2025 00:04:22 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 0/2] xen/console: updates to diagnostic messages prefixes
Message-ID: <20250531000417.81750-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 6370cce680691c3356ef66ddd19cff5dcbaf3a96
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Patch 1 is purely cosmetic change, adds a symbol for hypervisor's messages.

Patch 2 updates the logic how the domain prefix is formed.

[1] Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelin=
es/1845446760

Denis Mukhin (2):
  xen/console: introduce CONSOLE_PREFIX
  xen/console: unify printout behavior for UART emulators

 xen/arch/arm/vpl011.c      |  6 +++---
 xen/arch/arm/vuart.c       |  2 +-
 xen/arch/x86/hvm/hvm.c     |  2 +-
 xen/drivers/char/console.c | 32 +++++++++++++++++++++++++++-----
 4 files changed, 32 insertions(+), 10 deletions(-)

--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat May 31 00:04:35 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:04:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001669.1381802 (Exim 4.92)
	(envelope-from )
	id 1uL9iE-0006rf-D8; Sat, 31 May 2025 00:04:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001669.1381802; Sat, 31 May 2025 00:04:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uL9iE-0006rY-AU; Sat, 31 May 2025 00:04:34 +0000
Received: by outflank-mailman (input) for mailman id 1001669;
 Sat, 31 May 2025 00:04:33 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL9iD-0006rG-R0
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:04:33 +0000
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch
 [79.135.106.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d3d9a105-3db2-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 02:04: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" 
X-Inumbo-ID: d3d9a105-3db2-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748649870; x=1748909070;
	bh=QNtWtRFbL4X756RFISMxfDods+IHy+r3BttTuEdjCsg=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=QAsx8Eii+nMkyv+NMJfmJ9tXlHJxFESnipb/CZlaOY8CZPSVNiJcfinhbA4gmrKwL
	 jeoz3qI18DzteQFhIKQPQpg9U1U458XLk4n+dDR83TeVaht+5yqamXUwwxixP1eSfB
	 vxpQANc3Zw+5ZW1M4IKOdsFm9vTYY+0rB0nzQ/q27hadaMPOst3vG9uGps9Z42waRP
	 iAq5lmjjlzPW1W0n7kZn+GcIoIMSi5tG3HW789mQimxC6exX9zh25IdCs4OIQB/Iwn
	 kfMH89X8WrHPu4gyhLBoeyrsawicO84SwQBT1V5mM9mGYP1e5OQNGLrwwTlJm+tqku
	 EVyktucg/H3RQ==
Date: Sat, 31 May 2025 00:04:26 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 1/2] xen/console: introduce CONSOLE_PREFIX
Message-ID: <20250531000417.81750-2-dmukhin@ford.com>
In-Reply-To: <20250531000417.81750-1-dmukhin@ford.com>
References: <20250531000417.81750-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 79fdd7e190394e3e9e5e9c7af6db9aa47d177ddd
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

Add CONSOLE_PREFIX symbol to keep the prefix of the hypervisor's diagnostic
messages.

No functional change.

Signed-off-by: Denis Mukhin 
---
 xen/drivers/char/console.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index c15987f5bb..27e3f8d8c6 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -61,6 +61,9 @@ enum {
     CONSOLE_ALL             =3D CONSOLE_DEFAULT | CONSOLE_RING,
 };
=20
+/* Prefix for hypervisor's diagnostic console messages. */
+#define CONSOLE_PREFIX      "(XEN) "
+
 static void console_send(const char *str, size_t len, unsigned int flags);
=20
 /* console: comma-separated list of console outputs. */
@@ -998,7 +1001,7 @@ static void vprintk_common(const char *fmt, va_list ar=
gs, const char *prefix)
=20
 void vprintk(const char *fmt, va_list args)
 {
-    vprintk_common(fmt, args, "(XEN) ");
+    vprintk_common(fmt, args, CONSOLE_PREFIX);
 }
=20
 void printk(const char *fmt, ...)
@@ -1269,7 +1272,7 @@ int __printk_ratelimit(int ratelimit_ms, int ratelimi=
t_burst)
             snprintf(lost_str, sizeof(lost_str), "%d", lost);
             /* console_lock may already be acquired by printk(). */
             rspin_lock(&console_lock);
-            printk_start_of_line("(XEN) ");
+            printk_start_of_line(CONSOLE_PREFIX);
             __putstr("printk: ");
             __putstr(lost_str);
             __putstr(" messages suppressed.\n");
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat May 31 00:04:39 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:04:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001670.1381812 (Exim 4.92)
	(envelope-from )
	id 1uL9iJ-000792-Lq; Sat, 31 May 2025 00:04:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001670.1381812; Sat, 31 May 2025 00:04: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 1uL9iJ-00078n-IA; Sat, 31 May 2025 00:04:39 +0000
Received: by outflank-mailman (input) for mailman id 1001670;
 Sat, 31 May 2025 00:04:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uL9iI-0006dJ-4t
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:04:38 +0000
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch
 [109.224.244.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d602e921-3db2-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 02:04: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" 
X-Inumbo-ID: d602e921-3db2-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748649874; x=1748909074;
	bh=jLza7oYui7MAKA/WA30qHXm75fT4X1v0Cyk+pVm2zJU=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=TgwiE2gOORRE3AZ86dmeTGSzqDxX52EPna3pU5tF4pe5xfFeuqEMPFOjIfDPr/5BX
	 6ld41ApwGRL56ppkYXPQjcfb1BG2uz6v3dy1S8+Wb0AZ7vPnN7drQ/pCVw2EYQTznH
	 o+9aGSljhitjs7LqSvVc7WGl/mwkkaL2sM9HvDO0J0c2cAwe/RKJZ07wJA9y6IefJJ
	 2fSTRgjax7sUSfJ6soRsvHqJZJ6dFzSEQ1X0U9YALUkO9xcfdKoZqwUTNjCEjA69mF
	 tAUtyMcd6wYEVEFKucHxLZgigtgfdeS3CXbV2NuLZ3mi/RlU1bpTWJT6C1BCaqWg3J
	 JnGGnoejzfLFw==
Date: Sat, 31 May 2025 00:04:32 +0000
To: xen-devel@lists.xenproject.org
From: dmkhn@proton.me
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v1 2/2] xen/console: unify printout behavior for UART emulators
Message-ID: <20250531000417.81750-3-dmukhin@ford.com>
In-Reply-To: <20250531000417.81750-1-dmukhin@ford.com>
References: <20250531000417.81750-1-dmukhin@ford.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 7926c79b27fa54c5217a24e08014cab5f982e754
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Denis Mukhin 

If virtual UART from domain X prints on the physical console, the behavior =
is
updated to (see [1]):
- console focus in domain X: do not prefix messages;
- no console focus in domain X: prefix all messages with "(dX)".

Use guest_printk() in all current in-hypervisor UART emulators. That aligns
behavior with debug I/O port 0xe9 handler in x86 port and slightly improves=
 the
logging since guest_printk() already prints the domain ID. guest_printk() w=
as
modified to account for console focus ownership.

Modify guest_console_write() for hardware domain case by adding domain ID
to the message when hwdom does not have console focus.

[1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2412121655360.463=
523@ubuntu-linux-20-04-desktop/
Signed-off-by: Denis Mukhin 
---
 xen/arch/arm/vpl011.c      |  6 +++---
 xen/arch/arm/vuart.c       |  2 +-
 xen/arch/x86/hvm/hvm.c     |  2 +-
 xen/drivers/char/console.c | 25 ++++++++++++++++++++++---
 4 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 66047bf33c..6298e377b3 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -87,7 +87,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8=
_t data)
     {
         if ( intf->out_prod =3D=3D 1 )
         {
-            printk("%c", data);
+            guest_printk(d, "%c", data);
             intf->out_prod =3D 0;
         }
         else
@@ -95,7 +95,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8=
_t data)
             if ( data !=3D '\n' )
                 intf->out[intf->out_prod++] =3D '\n';
             intf->out[intf->out_prod++] =3D '\0';
-            printk("%s", intf->out);
+            guest_printk(d, "%s", intf->out);
             intf->out_prod =3D 0;
         }
     }
@@ -107,7 +107,7 @@ static void vpl011_write_data_xen(struct domain *d, uin=
t8_t data)
             if ( data !=3D '\n' )
                 intf->out[intf->out_prod++] =3D '\n';
             intf->out[intf->out_prod++] =3D '\0';
-            printk("DOM%u: %s", d->domain_id, intf->out);
+            guest_printk(d, "%s", intf->out);
             intf->out_prod =3D 0;
         }
     }
diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c
index bd2f425214..8c9f9e2182 100644
--- a/xen/arch/arm/vuart.c
+++ b/xen/arch/arm/vuart.c
@@ -89,7 +89,7 @@ static void vuart_print_char(struct vcpu *v, char c)
         if ( c !=3D '\n' )
             uart->buf[uart->idx++] =3D '\n';
         uart->buf[uart->idx] =3D '\0';
-        printk(XENLOG_G_DEBUG "DOM%u: %s", d->domain_id, uart->buf);
+        guest_printk(d, "%s", uart->buf);
         uart->idx =3D 0;
     }
     spin_unlock(&uart->lock);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4cb2e13046..8cc94bee81 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -577,7 +577,7 @@ static int cf_check hvm_print_line(
     if ( (cd->pbuf_idx =3D=3D (DOMAIN_PBUF_SIZE - 1)) || (c =3D=3D '\n') )
     {
         cd->pbuf[cd->pbuf_idx] =3D '\0';
-        guest_printk(cd, XENLOG_G_DEBUG "%s\n", cd->pbuf);
+        guest_printk(cd, "%s\n", cd->pbuf);
         cd->pbuf_idx =3D 0;
     }
     spin_unlock(&cd->pbuf_lock);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 27e3f8d8c6..16d6003a0f 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -724,7 +724,17 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM=
(char) buffer,
         if ( is_hardware_domain(cd) )
         {
             /* Use direct console output as it could be interactive */
+            char prefix[16] =3D "";
+            struct domain *consd;
+
+            consd =3D console_get_domain();
+            if ( consd !=3D cd )
+                snprintf(prefix, sizeof(prefix), "(d%d) ", cd->domain_id);
+            console_put_domain(consd);
+
             nrspin_lock_irq(&console_lock);
+            if ( prefix[0] !=3D '\0' )
+                console_send(prefix, strlen(prefix), flags);
             console_send(kbuf, kcount, flags);
             nrspin_unlock_irq(&console_lock);
         }
@@ -755,7 +765,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(=
char) buffer,
             else
             {
                 cd->pbuf[cd->pbuf_idx] =3D '\0';
-                guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
+                guest_printk(cd, "%s%s\n", cd->pbuf, kbuf);
                 cd->pbuf_idx =3D 0;
             }
             spin_unlock(&cd->pbuf_lock);
@@ -1013,12 +1023,21 @@ void printk(const char *fmt, ...)
     va_end(args);
 }
=20
+/*
+ * Print message from the guest on the diagnostic console.
+ * Prefixes all messages w/ "(dX)" if domain X does not own physical conso=
le
+ * focus.
+ */
 void guest_printk(const struct domain *d, const char *fmt, ...)
 {
     va_list args;
-    char prefix[16];
+    char prefix[16] =3D "";
+    struct domain *consd;
=20
-    snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
+    consd =3D console_get_domain();
+    if ( consd !=3D d )
+        snprintf(prefix, sizeof(prefix), "(d%d) ", d->domain_id);
+    console_put_domain(consd);
=20
     va_start(args, fmt);
     vprintk_common(fmt, args, prefix);
--=20
2.34.1




From xen-devel-bounces@lists.xenproject.org Sat May 31 00:36:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:36:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001705.1381822 (Exim 4.92)
	(envelope-from )
	id 1uLACZ-0003EN-3o; Sat, 31 May 2025 00:35:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001705.1381822; Sat, 31 May 2025 00:35: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 1uLACZ-0003EG-0t; Sat, 31 May 2025 00:35:55 +0000
Received: by outflank-mailman (input) for mailman id 1001705;
 Sat, 31 May 2025 00:35:53 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uLACW-0003EA-0C
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:35:53 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3141cc44-3db7-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 02:35: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" 
X-Inumbo-ID: 3141cc44-3db7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=pbmd52kys5g25bbf36orjl3s4i.protonmail; t=1748651745; x=1748910945;
	bh=o0KvuhmVnTSPDujnz7LCsj+x1vXQZJO4HgOSlrJh7aQ=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=lCStGrIa8vhmqQN4cLAJo5Th5GLGZCRRMOEMGWDBiKfk0tz49uaZmpzSUH7RgVkNh
	 fzYJj3k1f4MgLlSopja8MOYT2CNXZZUqy94g/M0Kon9K9y1d4YUzZMI7NBvSBn68uf
	 lGRe124IkpkA0jc6v4XtBglQz0NvewwKMLdrU/yTVRYhpeXwSstOzrK73Qnst/qLeT
	 zdKrO4sj5hJVdER2DQvSsC1mpz/c0WRm4P+fcN9uRZqeWv+HYpQK6RmINMPE4VDLlE
	 xo17ExuJBNCcksSnIgcTDFggG3EYdt2UIuaQV+QSlVm+AD6LyqrM3BB+Jta7wZ40a/
	 Pv0yUqghi7ISw==
Date: Sat, 31 May 2025 00:35:39 +0000
To: Alejandro Vallejo 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , "Daniel P. Smith" 
Subject: Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h
Message-ID: 
In-Reply-To: <20250530120242.39398-13-agarciav@amd.com>
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-13-agarciav@amd.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: e89c53fcdad1d076fe8dfc002626794684995d39
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, May 30, 2025 at 02:02:20PM +0200, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of b=
ootinfo
> to a separate file for x86 to take.
>=20
> Move functions required for early FDT parsing from device_tree.h and arm'=
s
> setup.h onto bootfdt.h
>=20
> Declaration motion only. Not a functional change.
>=20
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/arch/arm/include/asm/setup.h |  6 ----
>  xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
>  xen/include/xen/device_tree.h    | 34 +-----------------
>  3 files changed, 63 insertions(+), 39 deletions(-)
>=20
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/=
setup.h
> index 0f9e531a34..32308837a9 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -55,12 +55,6 @@ void setup_mm(void);
>  extern uint32_t hyp_traps_vector[];
>  void init_traps(void);
>=20
> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                         uint32_t size_cells, paddr_t *start, paddr_t *s=
ize);
> -
> -u32 device_tree_get_u32(const void *fdt, int node,
> -                        const char *prop_name, u32 dflt);
> -
>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type=
_t p2mt,
>                    struct rangeset *iomem_ranges, struct rangeset *irq_ra=
nges);
>=20
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index fa65e8fcf4..079259c719 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -2,6 +2,7 @@
>  #ifndef XEN_BOOTFDT_H
>  #define XEN_BOOTFDT_H
>=20
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -16,8 +17,53 @@
>  #define NR_MEM_BANKS 256
>  #define NR_SHMEM_BANKS 32
>=20
> +/* Default #address and #size cells */
> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> +
>  #define MAX_MODULES 32 /* Current maximum useful modules */
>=20
> +#define DEVICE_TREE_MAX_DEPTH 16
> +
> +/* Helper to read a big number; size is in cells (not bytes) */
> +static inline u64 dt_read_number(const __be32 *cell, int size)
> +{
> +    u64 r =3D 0;
> +
> +    while ( size-- )
> +        r =3D (r << 32) | be32_to_cpu(*(cell++));
> +    return r;
> +}
> +
> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> +{
> +    const __be32 *p =3D *cellp;
> +
> +    *cellp =3D p + s;
> +    return dt_read_number(p, s);
> +}
> +
> +typedef int (*device_tree_node_func)(const void *fdt,
> +                                     int node, const char *name, int dep=
th,
> +                                     u32 address_cells, u32 size_cells,
> +                                     void *data);
> +
> +/**
> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> + * @fdt: flat device tree.
> + * @node: parent node to start the search from
> + * @func: function to call for each sub-node.
> + * @data: data to pass to @func.
> + *
> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> + *
> + * Returns 0 if all nodes were iterated over successfully.  If @func
> + * returns a value different from 0, that value is returned immediately.
> + */
> +int device_tree_for_each_node(const void *fdt, int node,
> +                              device_tree_node_func func,
> +                              void *data);
> +
>  typedef enum {
>      BOOTMOD_XEN,
>      BOOTMOD_FDT,
> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsi=
gned int nr,
>      return banks;
>  }
>=20
> +/*
> + * Interpret the property `prop_name` of `node` as a u32.
> + *
> + * Returns the property value on success; otherwise returns `dflt`.
> + */
> +uint32_t device_tree_get_u32(const void *fdt, int node,
> +                             const char *prop_name, uint32_t dflt);

Suggest using `dt_` prefix (or any other good prefix) for all functions
in this header for consistency: e.g. there's dt_read_number() but also
device_tree_get_u32().

> +
> +/*
> + * Interpret the property `prop_name` of `node` as a "reg".
> + *
> + * Returns outputs in `start` and `size`.
> + */
> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                         uint32_t size_cells, paddr_t *start, paddr_t *s=
ize);
> +
>  #endif /* XEN_BOOTFDT_H */
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.=
h
> index 6dc1fb5159..0a22b1ba1d 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -10,6 +10,7 @@
>  #ifndef __XEN_DEVICE_TREE_H__
>  #define __XEN_DEVICE_TREE_H__
>=20
> +#include 
>  #include 
>=20
>  #include 
> @@ -22,8 +23,6 @@
>  #include 
>  #include 
>=20
> -#define DEVICE_TREE_MAX_DEPTH 16
> -
>  /*
>   * Struct used for matching a device
>   */
> @@ -164,17 +163,8 @@ struct dt_raw_irq {
>      u32 specifier[DT_MAX_IRQ_SPEC];
>  };
>=20
> -typedef int (*device_tree_node_func)(const void *fdt,
> -                                     int node, const char *name, int dep=
th,
> -                                     u32 address_cells, u32 size_cells,
> -                                     void *data);
> -
>  extern const void *device_tree_flattened;
>=20
> -int device_tree_for_each_node(const void *fdt, int node,
> -                              device_tree_node_func func,
> -                              void *data);
> -
>  /**
>   * dt_unflatten_host_device_tree - Unflatten the host device tree
>   *
> @@ -245,10 +235,6 @@ void intc_dt_preinit(void);
>  #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
>  #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
>=20
> -/* Default #address and #size cells */
> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> -
>  #define dt_for_each_property_node(dn, pp)                   \
>      for ( pp =3D (dn)->properties; (pp) !=3D NULL; pp =3D (pp)->next )
>=20
> @@ -258,16 +244,6 @@ void intc_dt_preinit(void);
>  #define dt_for_each_child_node(dt, dn)                      \
>      for ( dn =3D (dt)->child; (dn) !=3D NULL; dn =3D (dn)->sibling )
>=20
> -/* Helper to read a big number; size is in cells (not bytes) */
> -static inline u64 dt_read_number(const __be32 *cell, int size)
> -{
> -    u64 r =3D 0;
> -
> -    while ( size-- )
> -        r =3D (r << 32) | be32_to_cpu(*(cell++));
> -    return r;
> -}
> -
>  /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) =
*/
>  static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
>  {
> @@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
>      return (bytes / sizeof(u32));
>  }
>=20
> -static inline u64 dt_next_cell(int s, const __be32 **cellp)
> -{
> -    const __be32 *p =3D *cellp;
> -
> -    *cellp =3D p + s;
> -    return dt_read_number(p, s);
> -}
> -
>  static inline const char *dt_node_full_name(const struct dt_device_node =
*np)
>  {
>      return (np && np->full_name) ? np->full_name : "";
> --
> 2.43.0
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Sat May 31 00:39:51 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:39:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001712.1381831 (Exim 4.92)
	(envelope-from )
	id 1uLAGM-0003mk-Iy; Sat, 31 May 2025 00:39:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001712.1381831; Sat, 31 May 2025 00:39:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uLAGM-0003md-GC; Sat, 31 May 2025 00:39:50 +0000
Received: by outflank-mailman (input) for mailman id 1001712;
 Sat, 31 May 2025 00:39:48 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uLAGK-0003mH-QA
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:39:48 +0000
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c08c9394-3db7-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 02:39: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" 
X-Inumbo-ID: c08c9394-3db7-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me;
	s=protonmail; t=1748651986; x=1748911186;
	bh=sWU6u4ddiUwSPNUnlgP3++F+h+5dhxc6fyLc1W0nIOw=;
	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:List-Unsubscribe:List-Unsubscribe-Post;
	b=mZYsudnEucdICIA1zqF/GZ0m7pb6d++im/fCE9CKvDBlGogOaAOToS9HwCHpfkUpf
	 Q9thw1xjm53kv75vStZHjhmVcPVkw86u0L4KzsUdjvJQojLL3ICMB0GHQM6k8YR4oa
	 BEJRwHHyTgjDM+nh2h79iBICkPwDr8JjZrKIy0Jp0Om1+NOTeczQaa9tLF5H1++xAL
	 6A8rlZKHJf13h60e1RxSao6R2C6L+PjMgmgR2UpMXuXWkac91jHUvPTDUqVs4VMyYg
	 544AZhu0nCg76AyZYzy0nizKWIPtAuLeGoFHnoU09dDqllYwO1ahfLykIoXRoFRBGJ
	 sMc8tndCQ7RNQ==
Date: Sat, 31 May 2025 00:39:43 +0000
To: Alejandro Vallejo 
From: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Daniel P. Smith" 
Subject: Re: [PATCH 15/19] xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c
Message-ID: 
In-Reply-To: <20250530120242.39398-16-agarciav@amd.com>
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-16-agarciav@amd.com>
Feedback-ID: 123220910:user:proton
X-Pm-Message-ID: 78278d0f8258107d4d2c4498f91c765f42724dd7
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, May 30, 2025 at 02:02:23PM +0200, Alejandro Vallejo wrote:
> ... back into bootfdt.c
>=20
> These will be required by x86 later on to detect modules in the early sca=
n of
> the FDT. They are independent of bootinfo, so it's cleaner for them to ex=
ist in
> a separate file.
>=20
> Not a functional change.
>=20
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/common/device-tree/Makefile       |   1 +
>  xen/common/device-tree/bootfdt.c      |  97 ++++++++++++++++++++++++
>  xen/common/device-tree/bootinfo-fdt.c | 104 --------------------------
>  3 files changed, 98 insertions(+), 104 deletions(-)
>  create mode 100644 xen/common/device-tree/bootfdt.c
>=20
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Mak=
efile
> index bb6d5ddec5..922c5bba9b 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1,3 +1,4 @@
> +obj-y +=3D bootfdt.init.o
>  obj-y +=3D bootinfo-fdt.init.o
>  obj-y +=3D bootinfo.init.o
>  obj-y +=3D device-tree.o
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bo=
otfdt.c
> new file mode 100644
> index 0000000000..5decf17faf
> --- /dev/null
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -0,0 +1,97 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +uint32_t __init device_tree_get_u32(const void *fdt, int node,
> +                                    const char *prop_name, uint32_t dflt=
)
> +{
> +    const struct fdt_property *prop;
> +
> +    prop =3D fdt_get_property(fdt, node, prop_name, NULL);
> +    if ( !prop || prop->len < sizeof(u32) )
> +        return dflt;
> +
> +    return fdt32_to_cpu(*(uint32_t*)prop->data);
> +}
> +
> +int __init device_tree_for_each_node(const void *fdt, int node,
> +                                     device_tree_node_func func,
> +                                     void *data)
> +{
> +    /*
> +     * We only care about relative depth increments, assume depth of
> +     * node is 0 for simplicity.
> +     */
> +    int depth =3D 0;
> +    const int first_node =3D node;
> +    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
> +    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
> +    int ret;
> +
> +    do {
> +        const char *name =3D fdt_get_name(fdt, node, NULL);
> +        u32 as, ss;
> +
> +        if ( depth >=3D DEVICE_TREE_MAX_DEPTH )
> +        {
> +            printk("Warning: device tree node `%s' is nested too deep\n"=
,
> +                   name);

Use XENLOG_WARNING?

> +            continue;
> +        }
> +
> +        as =3D depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CE=
LLS_DEFAULT;
> +        ss =3D depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS=
_DEFAULT;
> +
> +        address_cells[depth] =3D device_tree_get_u32(fdt, node,
> +                                                   "#address-cells", as)=
;
> +        size_cells[depth] =3D device_tree_get_u32(fdt, node,
> +                                                "#size-cells", ss);
> +
> +        /* skip the first node */
> +        if ( node !=3D first_node )
> +        {
> +            ret =3D func(fdt, node, name, depth, as, ss, data);
> +            if ( ret !=3D 0 )
> +                return ret;
> +        }
> +
> +        node =3D fdt_next_node(fdt, node, &depth);
> +    } while ( node >=3D 0 && depth > 0 );
> +
> +    return 0;
> +}
> +
> +void __init device_tree_get_reg(const __be32 **cell, uint32_t address_ce=
lls,
> +                                uint32_t size_cells, paddr_t *start,
> +                                paddr_t *size)
> +{
> +    uint64_t dt_start, dt_size;
> +
> +    /*
> +     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-b=
it.
> +     * Thus, there is an implicit cast from uint64_t to paddr_t.
> +     */
> +    dt_start =3D dt_next_cell(address_cells, cell);
> +    dt_size =3D dt_next_cell(size_cells, cell);
> +
> +    if ( dt_start !=3D (paddr_t)dt_start )
> +    {
> +        printk("Physical address greater than max width supported\n");

I would add current and expected dt_start values to the printout.

> +        WARN();
> +    }
> +
> +    if ( dt_size !=3D (paddr_t)dt_size )
> +    {
> +        printk("Physical size greater than max width supported\n");
> +        WARN();
> +    }
> +
> +    /*
> +     * Xen will truncate the address/size if it is greater than the maxi=
mum
> +     * supported width and it will give an appropriate warning.
> +     */
> +    *start =3D dt_start;
> +    *size =3D dt_size;
> +}
> diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tr=
ee/bootinfo-fdt.c
> index bb5f45771e..736f877616 100644
> --- a/xen/common/device-tree/bootinfo-fdt.c
> +++ b/xen/common/device-tree/bootinfo-fdt.c
> @@ -112,39 +112,6 @@ static bool __init device_tree_is_memory_node(const =
void *fdt, int node,
>      return true;
>  }
>=20
> -void __init device_tree_get_reg(const __be32 **cell, uint32_t address_ce=
lls,
> -                                uint32_t size_cells, paddr_t *start,
> -                                paddr_t *size)
> -{
> -    uint64_t dt_start, dt_size;
> -
> -    /*
> -     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-b=
it.
> -     * Thus, there is an implicit cast from uint64_t to paddr_t.
> -     */
> -    dt_start =3D dt_next_cell(address_cells, cell);
> -    dt_size =3D dt_next_cell(size_cells, cell);
> -
> -    if ( dt_start !=3D (paddr_t)dt_start )
> -    {
> -        printk("Physical address greater than max width supported\n");
> -        WARN();
> -    }
> -
> -    if ( dt_size !=3D (paddr_t)dt_size )
> -    {
> -        printk("Physical size greater than max width supported\n");
> -        WARN();
> -    }
> -
> -    /*
> -     * Xen will truncate the address/size if it is greater than the maxi=
mum
> -     * supported width and it will give an appropriate warning.
> -     */
> -    *start =3D dt_start;
> -    *size =3D dt_size;
> -}
> -
>  static int __init device_tree_get_meminfo(const void *fdt, int node,
>                                            const char *prop_name,
>                                            u32 address_cells, u32 size_ce=
lls,
> @@ -205,77 +172,6 @@ static int __init device_tree_get_meminfo(const void=
 *fdt, int node,
>      return 0;
>  }
>=20
> -u32 __init device_tree_get_u32(const void *fdt, int node,
> -                               const char *prop_name, u32 dflt)
> -{
> -    const struct fdt_property *prop;
> -
> -    prop =3D fdt_get_property(fdt, node, prop_name, NULL);
> -    if ( !prop || prop->len < sizeof(u32) )
> -        return dflt;
> -
> -    return fdt32_to_cpu(*(uint32_t*)prop->data);
> -}
> -
> -/**
> - * device_tree_for_each_node - iterate over all device tree sub-nodes
> - * @fdt: flat device tree.
> - * @node: parent node to start the search from
> - * @func: function to call for each sub-node.
> - * @data: data to pass to @func.
> - *
> - * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> - *
> - * Returns 0 if all nodes were iterated over successfully.  If @func
> - * returns a value different from 0, that value is returned immediately.
> - */
> -int __init device_tree_for_each_node(const void *fdt, int node,
> -                                     device_tree_node_func func,
> -                                     void *data)
> -{
> -    /*
> -     * We only care about relative depth increments, assume depth of
> -     * node is 0 for simplicity.
> -     */
> -    int depth =3D 0;
> -    const int first_node =3D node;
> -    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
> -    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
> -    int ret;
> -
> -    do {
> -        const char *name =3D fdt_get_name(fdt, node, NULL);
> -        u32 as, ss;
> -
> -        if ( depth >=3D DEVICE_TREE_MAX_DEPTH )
> -        {
> -            printk("Warning: device tree node `%s' is nested too deep\n"=
,
> -                   name);
> -            continue;
> -        }
> -
> -        as =3D depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CE=
LLS_DEFAULT;
> -        ss =3D depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS=
_DEFAULT;
> -
> -        address_cells[depth] =3D device_tree_get_u32(fdt, node,
> -                                                   "#address-cells", as)=
;
> -        size_cells[depth] =3D device_tree_get_u32(fdt, node,
> -                                                "#size-cells", ss);
> -
> -        /* skip the first node */
> -        if ( node !=3D first_node )
> -        {
> -            ret =3D func(fdt, node, name, depth, as, ss, data);
> -            if ( ret !=3D 0 )
> -                return ret;
> -        }
> -
> -        node =3D fdt_next_node(fdt, node, &depth);
> -    } while ( node >=3D 0 && depth > 0 );
> -
> -    return 0;
> -}
> -
>  static int __init process_memory_node(const void *fdt, int node,
>                                        const char *name, int depth,
>                                        u32 address_cells, u32 size_cells,
> --
> 2.43.0
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Sat May 31 00:42:27 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:42:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001718.1381842 (Exim 4.92)
	(envelope-from )
	id 1uLAIp-0005Hg-0a; Sat, 31 May 2025 00:42:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001718.1381842; Sat, 31 May 2025 00: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 1uLAIo-0005HZ-Tn; Sat, 31 May 2025 00:42:22 +0000
Received: by outflank-mailman (input) for mailman id 1001718;
 Sat, 31 May 2025 00:42:21 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLAIn-0005HM-SV
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:42:21 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1bacf479-3db8-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 02:42:20 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 457975C633A;
 Sat, 31 May 2025 00:40:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id DFDB3C4CEE9;
 Sat, 31 May 2025 00:42: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" 
X-Inumbo-ID: 1bacf479-3db8-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748652137;
	bh=LRTXElYsQwjLTolW/oDfxCUppOOmBuJy7qxIUajToc0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=U15Fcmxmxhz84cdQXFtjFJo+IabyWBDXfH9nWeBqFhM0r162gU81FwpTosAz1uXzh
	 Y/pE1ZE7jNq0vqBWnSQxwTAgKME8bWI6gmDEu7nOtTI0ZQGLfsZdDMWrTLC5yQ6EPo
	 hDeeLTO4e0sJOZmZQZfItgE1s6UXqvEFMQGG1wYa6qIQeDLhuauqvE1V/rdhBrzD8K
	 TQwBRl4/UWN8Pi3ojENdYyVtGnXSz0glMq7AROHd55kNDkMa5jdsGYThPR9NMf+GUU
	 LSQvAVBh74tC9yDlPBxjrjCdKcMAWsZZoCY7MKio55YhVvV2anRYtoPS9py8ohP2Zc
	 LPlqQVrx4awtg==
Date: Fri, 30 May 2025 17:42:12 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, Jan Beulich , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 02/19] x86: Add missing pci_dev forward declaration in
 asm/pci.h
In-Reply-To: <20250530120242.39398-3-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-3-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/x86/include/asm/pci.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h
> index bed99437cc..2e67cba8b9 100644
> --- a/xen/arch/x86/include/asm/pci.h
> +++ b/xen/arch/x86/include/asm/pci.h
> @@ -13,6 +13,8 @@
>                          || (id) == 0x01128086 || (id) == 0x01228086 \
>                          || (id) == 0x010A8086 )
>  
> +struct pci_dev;
> +
>  struct arch_pci_dev {
>      vmask_t used_vectors;
>      /*
> -- 
> 2.43.0
> 
> 


From xen-devel-bounces@lists.xenproject.org Sat May 31 00:43:21 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:43:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001726.1381853 (Exim 4.92)
	(envelope-from )
	id 1uLAJl-0005mG-9f; Sat, 31 May 2025 00:43:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001726.1381853; Sat, 31 May 2025 00: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 1uLAJl-0005m9-5g; Sat, 31 May 2025 00:43:21 +0000
Received: by outflank-mailman (input) for mailman id 1001726;
 Sat, 31 May 2025 00:43:20 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLAJk-0005m1-BY
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:43:20 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3c1d1079-3db8-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 02:43:15 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id C4CA85C680E;
 Sat, 31 May 2025 00:40:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 992A3C4CEE9;
 Sat, 31 May 2025 00:43: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" 
X-Inumbo-ID: 3c1d1079-3db8-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748652193;
	bh=FaU9HWD89sdfcTJbsxzCp71UmwvKZJYlSV7gG1ejjrk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=RH8qyTPg2fOhc5uPcZl5e4YTnDKhJl5bY9MxbxFyNGTK3cL5QjPlfU7/+9wpX2xPk
	 zp1aF3C5ZAlvnu567L8lwB0o/hJWmDzsjpQllvN+VLg9c4YInsfvF0z7hF4l2moxOL
	 ui68YlBf3WbL0Xg3djAMdzz0ISkIsJJ67fIO1GOSRB2ce0dxycfV7k4bNHqyh35qQf
	 8QhCQJbbhGeEdH0ucwwruMo9ObZ+UDXe2WvZC1BUFKGWQnOUQFnyJaZY2x7ZYxo8ou
	 xmgVTYddI9qud1sVzQGMMUNzz/p2VvNouTJ/MzaHooAfbtrNcmAk1uibm2dt7Li4Qf
	 Lp9jonP+1KfjQ==
Date: Fri, 30 May 2025 17:43:10 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Alistair Francis , 
    Bob Eshleman , 
    Connor Davis , 
    Oleksii Kurochko , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 03/19] riscv: Add missing forward declaration to intc.h
In-Reply-To: <20250530120242.39398-4-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-4-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> Very much not a functional change
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/riscv/include/asm/intc.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
> index 52ba196d87..81f74736ba 100644
> --- a/xen/arch/riscv/include/asm/intc.h
> +++ b/xen/arch/riscv/include/asm/intc.h
> @@ -8,6 +8,8 @@
>  #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
>  #define ASM__RISCV__INTERRUPT_CONTOLLER_H
>  
> +struct dt_device_node;
> +
>  enum intc_version {
>      INTC_APLIC,
>  };
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat May 31 00:46:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:46:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001740.1381862 (Exim 4.92)
	(envelope-from )
	id 1uLAMS-0006ML-LR; Sat, 31 May 2025 00:46:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001740.1381862; Sat, 31 May 2025 00:46: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 1uLAMS-0006ME-IL; Sat, 31 May 2025 00:46:08 +0000
Received: by outflank-mailman (input) for mailman id 1001740;
 Sat, 31 May 2025 00:46:07 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLAMR-0006M8-Fy
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:46:07 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a252af35-3db8-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 02:46:06 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id D747249DED;
 Sat, 31 May 2025 00:46:04 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F063C4CEE9;
 Sat, 31 May 2025 00: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" 
X-Inumbo-ID: a252af35-3db8-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748652364;
	bh=TbgV/uLEazFwiiFQt4Y22FwHCaX7WaJCc8bDWGiJsiA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=p0HkwV9d7mMWafZsR6loRuPOpv4bssRdJJaRwM6C6AVNTqxBAZ23NPgdvg3tkp7Mt
	 wssywcQhGU00gHUEmUaX4lL36AIjMPrVySUqYcC7/v8hu51RjOgQ/r7sOUvP602Cce
	 Ts1LnS0SnQ0i25c+SJzhJpRQP4dgcrE7nmuPG/R+74Iu90h4U6YUGoU61gVAFuE6jP
	 x7JOZYijA0NiQDrfDjjhKVGTGWPW3EKExhvBRCFc59B2EQgE2f5oaHAybuLESydcl7
	 avvDqDMW4XEz86ZjF+5P/Mmy9qT2zBgLALaArSZcJCUQgV/HTtfq4KKSKYtTDhvdif
	 GPtPc/tz8dTMw==
Date: Fri, 30 May 2025 17:46:01 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
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 , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 04/19] xen: Add missing forward declaration to 
 btcpupools_get_domain_pool_id
In-Reply-To: <20250530120242.39398-5-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-5-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> And remove the ifdef guard, as it's inconsequential.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/include/xen/sched.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 559d201e0c..b5a6a22c7f 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1291,15 +1291,15 @@ static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
>  {
>      return 0;
>  }
> -#ifdef CONFIG_HAS_DEVICE_TREE
> +
> +struct dt_device_node;
> +
>  static inline int
>  btcpupools_get_domain_pool_id(const struct dt_device_node *node)
>  {
>      return 0;
>  }
> -#endif
> -
> -#endif
> +#endif /* !CONFIG_BOOT_TIME_CPUPOOLS */

Usually the commend would just be /* CONFIG_BOOT_TIME_CPUPOOLS */
without the !

Other than that:

Reviewed-by: Stefano Stabellini 


>  #endif /* __SCHED_H__ */
>  
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat May 31 00:51:18 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:51:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001754.1381873 (Exim 4.92)
	(envelope-from )
	id 1uLARO-00085B-CT; Sat, 31 May 2025 00:51:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001754.1381873; Sat, 31 May 2025 00:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uLARO-000854-8V; Sat, 31 May 2025 00:51:14 +0000
Received: by outflank-mailman (input) for mailman id 1001754;
 Sat, 31 May 2025 00:51:13 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLARN-00084y-4b
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:51:13 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 58994576-3db9-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 02:51:11 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id ACBAEA4FD0F;
 Sat, 31 May 2025 00:51:10 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54685C4CEEB;
 Sat, 31 May 2025 00: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" 
X-Inumbo-ID: 58994576-3db9-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748652670;
	bh=ThxAtKbtqDIjvDGzTLRBEX/C1do+gn6SW4S8jOtXEiI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=mLq+Y4G4mor9Ckij+8db7qyjtYVh6m2a10IsKYLydLQE6wFI4nLbAy3Tkr/IdRh8f
	 1C0499Nnh3fLWJhb5Qz6gYpyZap0xRYTOau2yzJA4HT/eqrPf2huAo6zYUPmFPc6q2
	 7NG46MRuZENHW20hpCvxlOnZmqMrBe4TiS8XBGQmHFXRdGUdevzRcHOVjbfnCX3Gtr
	 yCUGTdGIH3bzpHieR8FDw2zkG35Wp5ZYsPLfbREaM4+SzA6fRRGnih+8QOU9ezuvuB
	 mj3+Lfn/hZBKou1lZW7HPTigBCw+oXHChu1NJM5oMxLn4POilyQ8DRnr7gRX+QGbuf
	 S646qSeVI1HoA==
Date: Fri, 30 May 2025 17:51:07 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 05/19] arm: Remove dependencies with membank(s) definitions
 from setup.h
In-Reply-To: <20250530120242.39398-6-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-6-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-424954523-1748652669=:1147082"

  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-424954523-1748652669=:1147082
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> ... as they can be forward-declared changing arrays for pointers in the function
> declarations.
> 
> No functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/arch/arm/include/asm/setup.h | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 6cf272c160..0f9e531a34 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -3,7 +3,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 

This change breaks the build on ARM:

  CC      xsm/xsm_policy.o
xsm/xsm_policy.c: In function ‘xsm_dt_policy_init’:
xsm/xsm_policy.c:71:30: error: implicit declaration of function ‘boot_module_find_by_kind’ [-Werror=implicit-function-declaration]
   71 |     struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~
xsm/xsm_policy.c:71:30: error: nested extern declaration of ‘boot_module_find_by_kind’ [-Werror=nested-externs]
xsm/xsm_policy.c:71:55: error: ‘BOOTMOD_XSM’ undeclared (first use in this function)
   71 |     struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_XSM);
      |                                                       ^~~~~~~~~~~
xsm/xsm_policy.c:71:55: note: each undeclared identifier is reported only once for each function it appears in
xsm/xsm_policy.c:74:22: error: dereferencing pointer to incomplete type ‘struct bootmodule’
   74 |     if ( !mod || !mod->size )
      |                      ^~
cc1: all warnings being treated as errors
make[2]: *** [Rules.mk:249: xsm/xsm_policy.o] Error 1
make[1]: *** [build.mk:72: xsm] Error 2
make: *** [Makefile:619: xen] Error 2

The rest looks OK


>  #if defined(CONFIG_MMU)
> @@ -14,6 +13,9 @@
>  
>  #define MAX_FDT_SIZE SZ_2M
>  
> +struct membank;
> +struct membanks;
> +
>  struct map_range_data
>  {
>      struct domain *d;
> @@ -32,13 +34,13 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
>  size_t estimate_efi_size(unsigned int mem_nr_banks);
>  
>  void acpi_create_efi_system_table(struct domain *d,
> -                                  struct membank tbl_add[]);
> +                                  struct membank *tbl_add);
>  
>  void acpi_create_efi_mmap_table(struct domain *d,
>                                  const struct membanks *mem,
> -                                struct membank tbl_add[]);
> +                                struct membank *tbl_add);
>  
> -int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]);
> +int acpi_make_efi_nodes(void *fdt, struct membank *tbl_add);
>  
>  void create_dom0(void);
>  
> -- 
> 2.43.0
> 
--8323329-424954523-1748652669=:1147082--


From xen-devel-bounces@lists.xenproject.org Sat May 31 00:55:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:55:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001766.1381881 (Exim 4.92)
	(envelope-from )
	id 1uLAVe-0000HH-UJ; Sat, 31 May 2025 00:55:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001766.1381881; Sat, 31 May 2025 00:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uLAVe-0000HA-RL; Sat, 31 May 2025 00:55:38 +0000
Received: by outflank-mailman (input) for mailman id 1001766;
 Sat, 31 May 2025 00:55:37 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLAVd-0000H4-FB
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:55:37 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f07b0ee9-3db9-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 02:55:27 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id 704164A322;
 Sat, 31 May 2025 00:55:25 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 834EFC4CEEB;
 Sat, 31 May 2025 00:55: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" 
X-Inumbo-ID: f07b0ee9-3db9-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748652925;
	bh=AGzpspSlrGYs7O09bZXm7XNixHEROU6oB55p3C+UMSc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=iIj+ZRyLPZ0+U7svoGlZG2mIkaXp05agAhhbQX5dbFNztvXMivHWZ+UAK6JxJf3MW
	 s8XLVB6s0lIbBUWAVnTutYDVpuElTYy8rHC1FnhYhuCNCpu1evYyGeHTBW8fqZ2nRY
	 CuU2+YKFxZ978A8jYqmpn6UVimyvwTCNkVMPXDiauGhM6gZNG/slPVMufEeGLq7ZhM
	 4QJBUCW9nmvGNP/E9qcJ40wB285y0aoQy2GW/Xr7/6wdxkd3job6BEvFTqq/GZKePH
	 OODlJxbu2R8MKz4U4hBjNn2TUmNtQdjD5MIj/W+VFx8pHgEXQDigAzrhkIVqmFxEL6
	 NvKge+0EvJjiA==
Date: Fri, 30 May 2025 17:55:21 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Alistair Francis , 
    Bob Eshleman , 
    Connor Davis , 
    Oleksii Kurochko , 
    Andrew Cooper , 
    Anthony PERARD , 
    Michal Orzel , Jan Beulich , 
    Julien Grall , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 06/19] xen: Clean up asm-generic/device.h
In-Reply-To: <20250530120242.39398-7-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-7-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> There's some pretense this header may be used without
> CONFIG_HAS_DEVICE_TREE, but that's just wishful thinking. Only x86 lacks
> that option, and it fully overrides this header, typedeffing struct
> pci_dev to be device_t.
> 
> Furthermore there's an include for xen/device_tree.h halfway through the
> header, but that header already includes asm/device.h, creating a cycle.
> 
> Clean up the header removing ifdef guards, merging the typedef onto the
> struct definition for device_t and removing the spurious include.
> 
> The only affected file is aplic.c, in riscv, which is forced now to
> include device_tree.h directly.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/riscv/aplic.c           |  3 ++-
>  xen/include/asm-generic/device.h | 18 ++----------------
>  2 files changed, 4 insertions(+), 17 deletions(-)
> 
> diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
> index caba8f8993..90bf222eeb 100644
> --- a/xen/arch/riscv/aplic.c
> +++ b/xen/arch/riscv/aplic.c
> @@ -9,12 +9,13 @@
>   * Copyright (c) 2024-2025 Vates
>   */
>  
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  
>  static struct intc_info __ro_after_init aplic_info = {
> diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/device.h
> index 1acd1ba1d8..d485fb97dc 100644
> --- a/xen/include/asm-generic/device.h
> +++ b/xen/include/asm-generic/device.h
> @@ -6,9 +6,7 @@
>  
>  enum device_type
>  {
> -#ifdef CONFIG_HAS_DEVICE_TREE
>      DEV_DT,
> -#endif
>      DEV_PCI
>  };
>  
> @@ -23,23 +21,15 @@ enum device_class
>  };
>  
>  /* struct device - The basic device structure */
> -struct device
> +typedef struct device
>  {
>      enum device_type type;
> -#ifdef CONFIG_HAS_DEVICE_TREE
>      struct dt_device_node *of_node; /* Used by drivers imported from Linux */
> -#endif
>  #ifdef CONFIG_HAS_PASSTHROUGH
>      void *iommu; /* IOMMU private data */;
>      struct iommu_fwspec *iommu_fwspec; /* per-device IOMMU instance data */
>  #endif
> -};
> -
> -typedef struct device device_t;
> -
> -#ifdef CONFIG_HAS_DEVICE_TREE
> -
> -#include 
> +} device_t;
>  
>  #define dev_is_dt(dev)  ((dev)->type == DEV_DT)
>  
> @@ -87,10 +77,6 @@ struct device_desc {
>      int (*init)(struct dt_device_node *dev, const void *data);
>  };
>  
> -#else /* !CONFIG_HAS_DEVICE_TREE */
> -#define dev_is_dt(dev) ((void)(dev), false)
> -#endif /* CONFIG_HAS_DEVICE_TREE */
> -
>  #define dev_is_pci(dev) ((dev)->type == DEV_PCI)
>  
>  #ifdef CONFIG_ACPI
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat May 31 00:58:17 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:58:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001774.1381892 (Exim 4.92)
	(envelope-from )
	id 1uLAY9-0000o6-AB; Sat, 31 May 2025 00:58:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001774.1381892; Sat, 31 May 2025 00:58: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 1uLAY9-0000nz-7L; Sat, 31 May 2025 00:58:13 +0000
Received: by outflank-mailman (input) for mailman id 1001774;
 Sat, 31 May 2025 00:58:12 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLAY8-0000nt-2k
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:58:12 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4d85b2d7-3dba-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 02:58:02 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 9E306A4FD19;
 Sat, 31 May 2025 00:58:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2D67C4CEEB;
 Sat, 31 May 2025 00:57: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" 
X-Inumbo-ID: 4d85b2d7-3dba-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748653081;
	bh=7Y77Y3K31XRyBwUrA9A6ORjCGqsUpFz3lQ5Ki8YB1dw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=TlAyzxdArFFsiVGgATRFLZRK6E0ZcYv4/M+/VI09SAacosORxik+fucnQNYoXRkkF
	 KaO7gyZusi9lmnh7EWUKuR4Eungy2madiUsSwMm6udhSEhA0wscJhNiWM/LrztoOFM
	 ZUVer2ebu/U2MgyIYZMMx5ccP2AcsKdRL/hzWOWFzzESUR6h5wwaqDAuhKnt0XVk78
	 l2dYCg9jFuf7eQFcImFJokDKkKbdbS/TL0CGWQ1UasP/b9Q7wgKS2yGcnDTsXXtENp
	 9dXh4ejWhfDymQjl312yh/QLVOFi9FkQR1zGP/gM5rhQB+fLMM+VkFUcRvRu3IDVjp
	 Q2ajvWiD8dAVg==
Date: Fri, 30 May 2025 17:57:57 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jason Andryuk 
cc: Alejandro Vallejo , xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 07/19] arm/gnttab: Break cycle between asm/grant_table.h
 and xen/grant_table.h
In-Reply-To: 
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-8-agarciav@amd.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Jason Andryuk wrote:
> On 2025-05-30 08:02, Alejandro Vallejo wrote:
> > xen/grant_table is meant to pull asm/grant_table, when it exists.
> > 
> > Signed-off-by: Alejandro Vallejo 
> 
> I think you can also remove this one:
> xen/arch/arm/dom0less-build.c:#include 
> 
> With that,
> Reviewed-by: Jason Andryuk 


Acked-by: Stefano Stabellini 


From xen-devel-bounces@lists.xenproject.org Sat May 31 00:59:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 00:59:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001780.1381902 (Exim 4.92)
	(envelope-from )
	id 1uLAZX-0001Ke-JW; Sat, 31 May 2025 00:59:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001780.1381902; Sat, 31 May 2025 00:59: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 1uLAZX-0001KX-Gn; Sat, 31 May 2025 00:59:39 +0000
Received: by outflank-mailman (input) for mailman id 1001780;
 Sat, 31 May 2025 00:59:38 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLAZW-0001KR-Fl
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:59:38 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 85d4370c-3dba-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 02:59:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 05E61629C1;
 Sat, 31 May 2025 00:59:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id C48D6C4CEEB;
 Sat, 31 May 2025 00:59: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" 
X-Inumbo-ID: 85d4370c-3dba-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748653175;
	bh=0ZpLi4Pxse9sFpSqfvx2+Meg7GBM6i54hR/f9Rq7yhw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=YCLEWvTxRDu/LUH3zdw9Vrrg/50JZJcZsImpzPiyiv6tkbsp6PmThNyXtakMsXgdw
	 4dYs1MnJNW8GgLHG22us1COvQBWdqa7GSNRKvCVxnNZ66UQeFK4qxIaHVlVYapc5tl
	 Odq29w0ZvgiM13z836w7GppIiwtT+QAK1NCMU4YTRHvYIoiOkv4MtwtpG2EfSS+8v2
	 /RlZX3MTjJOTtx2jXNKQl1Qf4EV+mrE34Sq+6bLFDbmmVHAaVdC6613rklDrnR5E/m
	 03Db4EccwrDlw/yiyKNr4w9pFUEHbKDcCDmjOH2GHt/DsmTYeQo8BzjoSWURmE0zF6
	 cQ2UMG/95HcuQ==
Date: Fri, 30 May 2025 17:59:32 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 08/19] xen/dt: Add BOOTMOD_MICROCODE
In-Reply-To: <20250530120242.39398-9-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-9-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> In preparation for x86 to start using bootmodule instead of boot_module
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/common/device-tree/bootinfo.c | 1 +
>  xen/include/xen/bootfdt.h         | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
> index 76d652c0de..717cfa0962 100644
> --- a/xen/common/device-tree/bootinfo.c
> +++ b/xen/common/device-tree/bootinfo.c
> @@ -31,6 +31,7 @@ const char * __init boot_module_kind_as_string(bootmodule_kind kind)
>      case BOOTMOD_RAMDISK: return "Ramdisk";
>      case BOOTMOD_XSM:     return "XSM";
>      case BOOTMOD_GUEST_DTB:     return "DTB";
> +    case BOOTMOD_MICROCODE:     return "Microcode";
>      case BOOTMOD_UNKNOWN: return "Unknown";
>      default: BUG();
>      }
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 847f019559..d503d1bd4b 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -21,6 +21,7 @@ typedef enum {
>      BOOTMOD_RAMDISK,
>      BOOTMOD_XSM,
>      BOOTMOD_GUEST_DTB,
> +    BOOTMOD_MICROCODE,
>      BOOTMOD_UNKNOWN
>  }  bootmodule_kind;
>  
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat May 31 01:05:42 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 01:05:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001790.1381911 (Exim 4.92)
	(envelope-from )
	id 1uLAfK-0002Yu-5E; Sat, 31 May 2025 01:05:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001790.1381911; Sat, 31 May 2025 01: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 1uLAfK-0002Yn-2Q; Sat, 31 May 2025 01:05:38 +0000
Received: by outflank-mailman (input) for mailman id 1001790;
 Sat, 31 May 2025 01:05:37 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLAfI-0002Yh-Jg
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 01:05:37 +0000
Received: from mail137-30.atl71.mandrillapp.com
 (mail137-30.atl71.mandrillapp.com [198.2.137.30])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5ab61e7c-3dbb-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 03:05:34 +0200 (CEST)
Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail137-30.atl71.mandrillapp.com (Mailchimp) with ESMTP id
 4b8MNY0CRfzMQxcv7
 for ; Sat, 31 May 2025 01:05:33 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 36efcc3b3419410d97b76d54f7f62a87; Sat, 31 May 2025 01:05: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" 
X-Inumbo-ID: 5ab61e7c-3dbb-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1748653533; x=1748923533;
	bh=iJOS3XVceWrZrrVbRKdBo+cD1yHkTmRhyARazJoTzPs=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=mRZ1/95hQzLdsEAWkJZwpflihFija+Zi0JtMfvRBJM29AGAyIs5fRYVhZHmf/Nz+4
	 DcU31eb1dnISEsdhS6RpqNVu8aiw6Rn84Y7lFRRK8MUpyHd5Mh1yxYicjC6AzaOo2l
	 KvSien8lRWADYpfgSr37crevjXOX8yGqD3KP/KOLgpJ20Sy44bp695Y+lZQqInV/th
	 bMMlHQ0dISBQrOw6uI3uZHoPQonL77H9bW4FWXYiPK/+ymTdoB4ntb67cPTgFiOGv1
	 8btWL65DaytXfkB8n8HPppjen0JX50AO0uYla/yY0Q6uC4ZPexs8Ni3Ms+9TUtqbad
	 inS10odfJ1ygA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1748653533; x=1748914033; i=teddy.astie@vates.tech;
	bh=iJOS3XVceWrZrrVbRKdBo+cD1yHkTmRhyARazJoTzPs=;
	h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=jdVDY7D0bou0Q4DA4o0/atx/th1z0Jydq1mCiWppZrfNbupLRczsSXKGqTxVffyRC
	 B6B1p7gcHuNL64TNbW8p42sR7pf7pjQPwfSFfgeRHK/IBmXQSC5Vn53X3eg31ujp7K
	 +C+KaKQc4RHX9ZUBhQ6g7NrVKlWTLRHL6q4FZB11vNygMRotaZML/+Gv7tySCOik2Y
	 pPBc+Gor6S35eLe+ryvgc5B+1No4aX1omYZo4jRzvcoVPCfppdWo47A6z1wkkz1SuI
	 cUgxnMsWEuDTA2F1cKgv2DQoyOht8N7T+7Ep1SOXYmQqylD8icrWgFb+gog5SRfrQa
	 0v1CnfVzrMebA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v4=202/2]=20xen/domain:=20rewrite=20emulation=5Fflags=5Fok()?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1748653531438
Message-Id: 
To: dmkhn@proton.me, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com
References: <20250530220242.63175-1-dmukhin@ford.com> <20250530220242.63175-3-dmukhin@ford.com>
In-Reply-To: <20250530220242.63175-3-dmukhin@ford.com>
X-Native-Encoded: 1
X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.36efcc3b3419410d97b76d54f7f62a87?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20250531:md
Date: Sat, 31 May 2025 01:05:32 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

Le 31/05/2025 =C3=A0 00:05, dmkhn@proton.me a =C3=A9crit=C2=A0:
> +        /* PVH dom0/domU or HVM domU */

This one is actually PVH dom0.

> +        {
> +            .caps   =3D CAP_HVM | CAP_HWDOM,
> +            .min    =3D X86_EMU_LAPIC | X86_EMU_IOAPIC | X86_EMU_VPCI,
> +            .opt    =3D 0,
> +        },
> +
> +        /* HVM domU */
> +        {
> +            .caps   =3D CAP_HVM | CAP_DOMU,
> +            .min    =3D X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)=
,
> +            /* HVM PIRQ feature is user-selectable. */
> +            .opt    =3D X86_EMU_USE_PIRQ,
> +        },
> +
> +        /* PVH */

And this one being PVH domU.

> +        {
> +            .caps   =3D CAP_HVM | CAP_DOMU,
> +            .min    =3D X86_EMU_LAPIC,
> +            .opt    =3D 0,
> +        },

With that

Reviewed-by: Teddy Astie 

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Sat May 31 01:08:11 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 01:08:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001796.1381921 (Exim 4.92)
	(envelope-from )
	id 1uLAhl-000356-Ge; Sat, 31 May 2025 01:08:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001796.1381921; Sat, 31 May 2025 01: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 1uLAhl-00034z-Dw; Sat, 31 May 2025 01:08:09 +0000
Received: by outflank-mailman (input) for mailman id 1001796;
 Sat, 31 May 2025 01:08:08 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLAhj-00034t-VY
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 01:08:07 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b30adfa6-3dbb-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 03:08:02 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 7D17F629C1;
 Sat, 31 May 2025 01:08:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 478D9C4CEEB;
 Sat, 31 May 2025 01:08: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" 
X-Inumbo-ID: b30adfa6-3dbb-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748653681;
	bh=wvJ1e/lNv/4dB+Vpy2uuG4CqzZ7ePBOWv5u/o4IyD3U=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=O7kckEgDuKvVfKT0h0jJFgRQ0KTsQwidz0By0tQ5KkdA8tj5YgARi2gnJIb4DGm8I
	 HfPWEsI1uDbd8S1zOV51hS4Tjq5v+oUI+xKeRsRK10vmpaZNkh9N/kJVxsIRi21uX+
	 3GW1M2jbO1pH72exFp5pENqMyu91qP05UnkVN5XcSk+WOT0YOgQIKzrSnS0w4yD8fp
	 ++oVOcpHDtCR8M7zqLSigCH1tQxU4s7S8+ESp3ORzrv11eKWAWk6xZ1/DAcsl/Z9xd
	 Grs7g63x6ljrejOsJnPgdgnWMxYatRzVbsCn3Kfo0mZPjYXYlglPCFr0r6V2sH6XFB
	 Zc9vW6onKyzww==
Date: Fri, 30 May 2025 18:07:58 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, Jan Beulich , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 09/19] x86: Preinitialise all modules to be of kind
 BOOTMOD_UNKNOWN
In-Reply-To: <20250530120242.39398-10-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-10-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> A later patch removes boot_module and replaces its uses with bootmodule.
> The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
> value, so it must be explicitly set in the static xen_boot_info.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/x86/setup.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 1f5cb67bd0..5da9df33c9 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -298,6 +298,7 @@ struct boot_info __initdata xen_boot_info = {
>      .loader = "unknown",
>      .cmdline = "",
>      .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
> +    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
>  };
>  
>  static struct boot_info *__init multiboot_fill_boot_info(
> -- 
> 2.43.0
> 
> 


From xen-devel-bounces@lists.xenproject.org Sat May 31 01:15:46 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 01:15:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001805.1381933 (Exim 4.92)
	(envelope-from )
	id 1uLAp3-00055u-9X; Sat, 31 May 2025 01:15:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001805.1381933; Sat, 31 May 2025 01:15:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uLAp3-00055n-52; Sat, 31 May 2025 01:15:41 +0000
Received: by outflank-mailman (input) for mailman id 1001805;
 Sat, 31 May 2025 01:15:39 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLAp1-00055g-Ih
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 01:15:39 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c244cf69-3dbc-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 03:15:37 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id 0D449629C1;
 Sat, 31 May 2025 01:15:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41B15C4CEEB;
 Sat, 31 May 2025 01:15: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" 
X-Inumbo-ID: c244cf69-3dbc-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748654135;
	bh=jcdAsiCbQ3cf2MFF+M7HgfsH3we3p4nHID/5dy85cC8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=PJBUYh6KF4BZtUwIK38f1R1LDYna+CoNiJdHsxHT1MnaYQ3G2N8LTxsbMA4ZQt26F
	 N0B+UT+ScJV3iAAXu9wyssPUBerwS0VBuCCq35O2pYRz1sWUMMTXV8IhL7F3ahnwLa
	 kEIX4rzLKtN2pfcXN/SwV+G+Dk7LAJjbCykWFQkmV4X9IpjLWhon56Wv7ylTr9tCEZ
	 ZCJxd9u6PPHePXiWbhUNrfcc0N7LW0xQjRIicTR/J0Y6jEclubkwL9lL7yTt4aC5An
	 oLwm4vdUorTt2nRfa4jqXZH68aF8XiHdQCqK62nzqCTmhz7o4yI0RwQDSFH5tMrS9o
	 8uudJ9xVTaJ1Q==
Date: Fri, 30 May 2025 18:15:32 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, Jan Beulich , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 10/19] x86: Replace boot_module with bootmodule
In-Reply-To: <20250530120242.39398-11-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-11-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> These types resemble each other very closely in layout and intent, and
> with "struct bootmodule" already in common code it makes perfect sense
> to merge them. In order to do so, add an arch-specific area for
> x86-specific tidbits.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/arch/x86/cpu/microcode/core.c      |  9 ++--
>  xen/arch/x86/hvm/dom0_build.c          | 10 ++---
>  xen/arch/x86/include/asm/boot-domain.h |  4 +-
>  xen/arch/x86/include/asm/bootfdt.h     | 52 +++++++++++++++++++++++
>  xen/arch/x86/include/asm/bootinfo.h    | 58 +++-----------------------
>  xen/arch/x86/include/asm/setup.h       |  6 +--
>  xen/arch/x86/pv/dom0_build.c           |  8 ++--
>  xen/arch/x86/setup.c                   | 52 ++++++++++++-----------
>  xen/include/xen/bootfdt.h              |  9 ++++
>  xen/xsm/xsm_policy.c                   |  4 +-
>  10 files changed, 113 insertions(+), 99 deletions(-)
>  create mode 100644 xen/arch/x86/include/asm/bootfdt.h
> 
> diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
> index 34a94cd25b..0111ef9156 100644
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -760,12 +760,11 @@ static int __init early_microcode_load(struct boot_info *bi)
>      {
>          for ( idx = 0; idx < bi->nr_modules; ++idx )
>          {
> -            const struct boot_module *bm = &bi->mods[idx];
> +            const struct bootmodule *bm = &bi->mods[idx];
>              struct cpio_data cd;
>  
>              /* Search anything unclaimed or likely to be a CPIO archive. */
> -            if ( bm->type != BOOTMOD_UNKNOWN &&
> -                 bm->type != BOOTMOD_RAMDISK )
> +            if ( bm->kind != BOOTMOD_UNKNOWN && bm->kind != BOOTMOD_RAMDISK )
>                  continue;
>  
>              size = bm->size;
> @@ -815,12 +814,12 @@ static int __init early_microcode_load(struct boot_info *bi)
>              return -ENODEV;
>          }
>  
> -        if ( bi->mods[idx].type != BOOTMOD_UNKNOWN )
> +        if ( bi->mods[idx].kind != BOOTMOD_UNKNOWN )
>          {
>              printk(XENLOG_WARNING "Microcode: Chosen module %d already used\n", idx);
>              return -ENODEV;
>          }
> -        bi->mods[idx].type = BOOTMOD_MICROCODE;
> +        bi->mods[idx].kind = BOOTMOD_MICROCODE;
>  
>          size = bi->mods[idx].size;
>          data = bootstrap_map_bm(&bi->mods[idx]);
> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> index a038e58c11..96410344a8 100644
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -647,10 +647,10 @@ static int __init pvh_load_kernel(
>      const struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
>  {
>      struct domain *d = bd->d;
> -    struct boot_module *image = bd->kernel;
> -    struct boot_module *initrd = bd->module;
> +    struct bootmodule *image = bd->kernel;
> +    struct bootmodule *initrd = bd->module;
>      void *image_base = bootstrap_map_bm(image);
> -    void *image_start = image_base + image->headroom;
> +    void *image_start = image_base + image->arch.headroom;
>      unsigned long image_len = image->size;
>      unsigned long initrd_len = initrd ? initrd->size : 0;
>      size_t cmdline_len = bd->cmdline ? strlen(bd->cmdline) + 1 : 0;
> @@ -721,9 +721,9 @@ static int __init pvh_load_kernel(
>      {
>          size_t initrd_space = elf_round_up(&elf, initrd_len);
>  
> -        if ( initrd->cmdline_pa )
> +        if ( initrd->arch.cmdline_pa )
>          {
> -            initrd_cmdline = __va(initrd->cmdline_pa);
> +            initrd_cmdline = __va(initrd->arch.cmdline_pa);
>              if ( !*initrd_cmdline )
>                  initrd_cmdline = NULL;
>          }
> diff --git a/xen/arch/x86/include/asm/boot-domain.h b/xen/arch/x86/include/asm/boot-domain.h
> index d7c6042e25..242e9c9c2b 100644
> --- a/xen/arch/x86/include/asm/boot-domain.h
> +++ b/xen/arch/x86/include/asm/boot-domain.h
> @@ -13,8 +13,8 @@
>  struct boot_domain {
>      domid_t domid;
>  
> -    struct boot_module *kernel;
> -    struct boot_module *module;
> +    struct bootmodule *kernel;
> +    struct bootmodule *module;
>      const char *cmdline;
>  
>      struct domain *d;
> diff --git a/xen/arch/x86/include/asm/bootfdt.h b/xen/arch/x86/include/asm/bootfdt.h
> new file mode 100644
> index 0000000000..c00de8c09b
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/bootfdt.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ARCH_X86_BOOTFDT_H__
> +#define __ARCH_X86_BOOTFDT_H__

With the new convention this is just X86_BOOTFDT_H


> +#include 
> +
> +struct arch_bootmodule
> +{
> +    /*
> +     * Module State Flags:
> +     *   relocated:   indicates module has been relocated in memory.
> +     *   released:    indicates module's pages have been freed.
> +     *   fdt_cmdline: indicates module's cmdline is in the FDT.
> +     */
> +    bool relocated:1;
> +    bool released:1;
> +    bool fdt_cmdline:1;

This is not actually used or needed in this patch?


> +    /*
> +     * A boot module may need decompressing by Xen.  Headroom is an estimate of
> +     * the additional space required to decompress the module.
> +     *
> +     * Headroom is accounted for at the start of the module.  Decompressing is
> +     * done in-place with input=start, output=start-headroom, expecting the
> +     * pointers to become equal (give or take some rounding) when decompression
> +     * is complete.
> +     *
> +     * Memory layout at boot:
> +     *
> +     *               start ----+
> +     *                         v
> +     *   |<-----headroom------>|<------size------->|
> +     *                         +-------------------+
> +     *                         | Compressed Module |
> +     *   +---------------------+-------------------+
> +     *   |           Decompressed Module           |
> +     *   +-----------------------------------------+
> +     */
> +    unsigned long headroom;
> +    paddr_t cmdline_pa;
> +};
> +
> +#endif /* __ARCH_X86_BOOTFDT_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
> index 3afc214c17..f3210b7d6a 100644
> --- a/xen/arch/x86/include/asm/bootinfo.h
> +++ b/xen/arch/x86/include/asm/bootinfo.h
> @@ -8,6 +8,7 @@
>  #ifndef X86_BOOTINFO_H
>  #define X86_BOOTINFO_H
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -19,55 +20,6 @@
>  /* Max number of boot domains that Xen can construct */
>  #define MAX_NR_BOOTDOMS 1
>  
> -/* Boot module binary type / purpose */
> -enum bootmod_type {
> -    BOOTMOD_UNKNOWN,
> -    BOOTMOD_XEN,
> -    BOOTMOD_KERNEL,
> -    BOOTMOD_RAMDISK,
> -    BOOTMOD_MICROCODE,
> -    BOOTMOD_XSM_POLICY,
> -};
> -
> -struct boot_module {
> -    enum bootmod_type type;
> -
> -    /*
> -     * Module State Flags:
> -     *   relocated: indicates module has been relocated in memory.
> -     *   released:  indicates module's pages have been freed.
> -     */
> -    bool relocated:1;
> -    bool released:1;
> -
> -    /*
> -     * A boot module may need decompressing by Xen.  Headroom is an estimate of
> -     * the additional space required to decompress the module.
> -     *
> -     * Headroom is accounted for at the start of the module.  Decompressing is
> -     * done in-place with input=start, output=start-headroom, expecting the
> -     * pointers to become equal (give or take some rounding) when decompression
> -     * is complete.
> -     *
> -     * Memory layout at boot:
> -     *
> -     *               start ----+
> -     *                         v
> -     *   |<-----headroom------>|<------size------->|
> -     *                         +-------------------+
> -     *                         | Compressed Module |
> -     *   +---------------------+-------------------+
> -     *   |           Decompressed Module           |
> -     *   +-----------------------------------------+
> -     */
> -    unsigned long headroom;
> -
> -    paddr_t cmdline_pa;
> -
> -    paddr_t start;
> -    size_t size;
> -};
> -
>  /*
>   * Xen internal representation of information provided by the
>   * bootloader/environment, or derived from the information.
> @@ -81,7 +33,7 @@ struct boot_info {
>      size_t memmap_length;
>  
>      unsigned int nr_modules;
> -    struct boot_module mods[MAX_NR_BOOTMODS + 1];
> +    struct bootmodule mods[MAX_NR_BOOTMODS + 1];
>      struct boot_domain domains[MAX_NR_BOOTDOMS];
>  };
>  
> @@ -94,16 +46,16 @@ struct boot_info {
>   *      Failure - a value greater than MAX_NR_BOOTMODS
>   */
>  static inline unsigned int __init next_boot_module_index(
> -    const struct boot_info *bi, enum bootmod_type t, unsigned int start)
> +    const struct boot_info *bi, bootmodule_kind k, unsigned int start)
>  {
>      unsigned int i;
>  
> -    if ( t == BOOTMOD_XEN )
> +    if ( k == BOOTMOD_XEN )
>          return bi->nr_modules;
>  
>      for ( i = start; i < bi->nr_modules; i++ )
>      {
> -        if ( bi->mods[i].type == t )
> +        if ( bi->mods[i].kind == k )
>              return i;
>      }
>  
> diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
> index ac34c69855..c7deaba109 100644
> --- a/xen/arch/x86/include/asm/setup.h
> +++ b/xen/arch/x86/include/asm/setup.h
> @@ -36,11 +36,11 @@ extern struct boot_info xen_boot_info;
>  unsigned long initial_images_nrpages(nodeid_t node);
>  void free_boot_modules(void);
>  
> -struct boot_module;
> -void *bootstrap_map_bm(const struct boot_module *bm);
> +struct bootmodule;
> +void *bootstrap_map_bm(const struct bootmodule *bm);
>  void bootstrap_unmap(void);
>  
> -void release_boot_module(struct boot_module *bm);
> +void release_boot_module(struct bootmodule *bm);
>  
>  struct rangeset;
>  int remove_xen_ranges(struct rangeset *r);
> diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
> index e1b78d47c2..e6c77413f5 100644
> --- a/xen/arch/x86/pv/dom0_build.c
> +++ b/xen/arch/x86/pv/dom0_build.c
> @@ -374,8 +374,8 @@ static int __init dom0_construct(const struct boot_domain *bd)
>      struct domain *d = bd->d;
>      struct vcpu *v = d->vcpu[0];
>  
> -    struct boot_module *image = bd->kernel;
> -    struct boot_module *initrd = bd->module;
> +    struct bootmodule *image = bd->kernel;
> +    struct bootmodule *initrd = bd->module;
>      void *image_base;
>      unsigned long image_len;
>      void *image_start;
> @@ -422,7 +422,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
>  
>      image_base = bootstrap_map_bm(image);
>      image_len = image->size;
> -    image_start = image_base + image->headroom;
> +    image_start = image_base + image->arch.headroom;
>  
>      d->max_pages = ~0U;
>  
> @@ -659,7 +659,7 @@ static int __init dom0_construct(const struct boot_domain *bd)
>               * pages. Tell the boot_module handling that we've freed it, so the
>               * memory is left alone.
>               */
> -            initrd->released = true;
> +            initrd->arch.released = true;
>          }
>  
>          iommu_memory_setup(d, "initrd", mfn_to_page(_mfn(initrd_mfn)),
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 5da9df33c9..a6b3dbfc8c 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -298,7 +298,7 @@ struct boot_info __initdata xen_boot_info = {
>      .loader = "unknown",
>      .cmdline = "",
>      .domains = { [0 ... MAX_NR_BOOTDOMS - 1] = { .domid = DOMID_INVALID } },
> -    .mods = { [0 ... MAX_NR_BOOTMODS] = { .type = BOOTMOD_UNKNOWN } },
> +    .mods = { [0 ... MAX_NR_BOOTMODS] = { .kind = BOOTMOD_UNKNOWN } },
>  };
>  
>  static struct boot_info *__init multiboot_fill_boot_info(
> @@ -333,7 +333,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
>       */
>      for ( i = 0; i < MAX_NR_BOOTMODS && i < bi->nr_modules; i++ )
>      {
> -        bi->mods[i].cmdline_pa = mods[i].string;
> +        bi->mods[i].arch.cmdline_pa = mods[i].string;
>  
>          if ( efi_enabled(EFI_LOADER) )
>          {
> @@ -356,7 +356,7 @@ static struct boot_info *__init multiboot_fill_boot_info(
>      }
>  
>      /* Variable 'i' should be one entry past the last module. */
> -    bi->mods[i].type = BOOTMOD_XEN;
> +    bi->mods[i].kind = BOOTMOD_XEN;
>  
>      return bi;
>  }
> @@ -381,13 +381,13 @@ unsigned long __init initial_images_nrpages(nodeid_t node)
>      return nr;
>  }
>  
> -void __init release_boot_module(struct boot_module *bm)
> +void __init release_boot_module(struct bootmodule *bm)
>  {
> -    ASSERT(!bm->released);
> +    ASSERT(!bm->arch.released);
>  
>      init_domheap_pages(bm->start, bm->start + PAGE_ALIGN(bm->size));
>  
> -    bm->released = true;
> +    bm->arch.released = true;
>  }
>  
>  void __init free_boot_modules(void)
> @@ -397,7 +397,7 @@ void __init free_boot_modules(void)
>  
>      for ( i = 0; i < bi->nr_modules; ++i )
>      {
> -        if ( bi->mods[i].released )
> +        if ( bi->mods[i].arch.released )
>              continue;
>  
>          release_boot_module(&bi->mods[i]);
> @@ -519,7 +519,7 @@ static void *__init bootstrap_map_addr(paddr_t start, paddr_t end)
>      return ret;
>  }
>  
> -void *__init bootstrap_map_bm(const struct boot_module *bm)
> +void *__init bootstrap_map_bm(const struct bootmodule *bm)
>  {
>      return bootstrap_map_addr(bm->start, bm->start + bm->size);
>  }
> @@ -689,7 +689,7 @@ static void __init noinline move_xen(void)
>  #undef BOOTSTRAP_MAP_LIMIT
>  
>  static uint64_t __init consider_modules(
> -    uint64_t s, uint64_t e, uint32_t size, const struct boot_module *mods,
> +    uint64_t s, uint64_t e, uint32_t size, const struct bootmodule mods[],
>      unsigned int nr_mods, unsigned int this_mod)
>  {
>      unsigned int i;
> @@ -985,8 +985,9 @@ static size_t __init domain_cmdline_size(const struct boot_info *bi,
>                                           const struct boot_domain *bd)
>  {
>      size_t s = bi->kextra ? strlen(bi->kextra) : 0;
> +    const struct arch_bootmodule *abm = &bd->kernel->arch;
>  
> -    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
> +    s += abm->cmdline_pa ? strlen(__va(abm->cmdline_pa)) : 0;
>  
>      if ( s == 0 )
>          return s;
> @@ -1050,9 +1051,10 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>          if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
>              panic("Error allocating cmdline buffer for %pd\n", d);
>  
> -        if ( bd->kernel->cmdline_pa )
> +        if ( bd->kernel->arch.cmdline_pa )
>              strlcpy(cmdline,
> -                    cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
> +                    cmdline_cook(__va(bd->kernel->arch.cmdline_pa),
> +                                 bi->loader),
>                      cmdline_size);
>  
>          if ( bi->kextra )
> @@ -1074,7 +1076,7 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>              strlcat(cmdline, " acpi=", cmdline_size);
>              strlcat(cmdline, acpi_param, cmdline_size);
>          }
> -        bd->kernel->cmdline_pa = 0;
> +        bd->kernel->arch.cmdline_pa = 0;
>          bd->cmdline = cmdline;
>      }
>  
> @@ -1287,7 +1289,7 @@ void asmlinkage __init noreturn __start_xen(void)
>      }
>  
>      /* Dom0 kernel is always first */
> -    bi->mods[0].type = BOOTMOD_KERNEL;
> +    bi->mods[0].kind = BOOTMOD_KERNEL;
>      bi->domains[0].kernel = &bi->mods[0];
>  
>      if ( pvh_boot )
> @@ -1458,7 +1460,7 @@ void asmlinkage __init noreturn __start_xen(void)
>  
>      if ( xen_phys_start )
>      {
> -        struct boot_module *xen = &bi->mods[bi->nr_modules];
> +        struct bootmodule *xen = &bi->mods[bi->nr_modules];
>  
>          relocated = true;
>  
> @@ -1471,7 +1473,7 @@ void asmlinkage __init noreturn __start_xen(void)
>          xen->size  = __2M_rwdata_end - _stext;
>      }
>  
> -    bi->mods[0].headroom =
> +    bi->mods[0].arch.headroom =
>          bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
>      bootstrap_unmap();
>  
> @@ -1552,10 +1554,10 @@ void asmlinkage __init noreturn __start_xen(void)
>          /* Is the region suitable for relocating the multiboot modules? */
>          for ( j = bi->nr_modules - 1; j >= 0; j-- )
>          {
> -            struct boot_module *bm = &bi->mods[j];
> -            unsigned long size = PAGE_ALIGN(bm->headroom + bm->size);
> +            struct bootmodule *bm = &bi->mods[j];
> +            unsigned long size = PAGE_ALIGN(bm->arch.headroom + bm->size);
>  
> -            if ( bm->relocated )
> +            if ( bm->arch.relocated )
>                  continue;
>  
>              /* Don't overlap with other modules (or Xen itself). */
> @@ -1565,12 +1567,12 @@ void asmlinkage __init noreturn __start_xen(void)
>              if ( highmem_start && end > highmem_start )
>                  continue;
>  
> -            if ( s < end && (bm->headroom || (end - size) > bm->start) )
> +            if ( s < end && (bm->arch.headroom || (end - size) > bm->start) )
>              {
> -                move_memory(end - size + bm->headroom, bm->start, bm->size);
> +                move_memory(end - size + bm->arch.headroom, bm->start, bm->size);
>                  bm->start = (end - size);
> -                bm->size += bm->headroom;
> -                bm->relocated = true;
> +                bm->size += bm->arch.headroom;
> +                bm->arch.relocated = true;
>              }
>          }
>  
> @@ -1596,7 +1598,7 @@ void asmlinkage __init noreturn __start_xen(void)
>  #endif
>      }
>  
> -    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
> +    if ( bi->mods[0].arch.headroom && !bi->mods[0].arch.relocated )
>          panic("Not enough memory to relocate the dom0 kernel image\n");
>      for ( i = 0; i < bi->nr_modules; ++i )
>      {
> @@ -2154,7 +2156,7 @@ void asmlinkage __init noreturn __start_xen(void)
>      initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
>      if ( initrdidx < MAX_NR_BOOTMODS )
>      {
> -        bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
> +        bi->mods[initrdidx].kind = BOOTMOD_RAMDISK;
>          bi->domains[0].module = &bi->mods[initrdidx];
>          if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
>              printk(XENLOG_WARNING
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index d503d1bd4b..fa65e8fcf4 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -7,6 +7,10 @@
>  #include 
>  #include 
>  
> +#if __has_include()
> +#include 
> +#endif
> +
>  #define MIN_FDT_ALIGN 8
>  
>  #define NR_MEM_BANKS 256
> @@ -106,8 +110,13 @@ struct shared_meminfo {
>  struct bootmodule {
>      bootmodule_kind kind;
>      bool domU;
> +
>      paddr_t start;
>      paddr_t size;
> +
> +#if __has_include()
> +    struct arch_bootmodule arch;
> +#endif
>  };
>  
>  /* DT_MAX_NAME is the node name max length according the DT spec */
> diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
> index 7f70d860bd..0c2cdea8ed 100644
> --- a/xen/xsm/xsm_policy.c
> +++ b/xen/xsm/xsm_policy.c
> @@ -40,7 +40,7 @@ int __init xsm_multiboot_policy_init(
>  
>      for_each_boot_module_by_type ( i, bi, BOOTMOD_UNKNOWN )
>      {
> -        struct boot_module *bm = &bi->mods[i];
> +        struct bootmodule *bm = &bi->mods[i];
>  
>          _policy_start = bootstrap_map_bm(bm);
>          _policy_len   = bm->size;
> @@ -53,7 +53,7 @@ int __init xsm_multiboot_policy_init(
>              printk("Policy len %#lx, start at %p.\n",
>                     _policy_len,_policy_start);
>  
> -            bm->type = BOOTMOD_XSM_POLICY;
> +            bm->kind = BOOTMOD_XSM;
>              break;
>  
>          }
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat May 31 01:31:22 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 01:31:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001817.1381942 (Exim 4.92)
	(envelope-from )
	id 1uLB48-0008Uj-Lv; Sat, 31 May 2025 01:31:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001817.1381942; Sat, 31 May 2025 01: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 1uLB48-0008Uc-JK; Sat, 31 May 2025 01:31:16 +0000
Received: by outflank-mailman (input) for mailman id 1001817;
 Sat, 31 May 2025 01:31:16 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLB48-0008UV-6X
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 01:31:16 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org
 [2600:3c04:e001:324:0:1991:8:25])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eb8a871d-3dbe-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 03:31:06 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id A0030629C1;
 Sat, 31 May 2025 01:31:04 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id F39C9C4CEEB;
 Sat, 31 May 2025 01:31: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" 
X-Inumbo-ID: eb8a871d-3dbe-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748655064;
	bh=rv7lPS6+auAT5hK2K2IgNJt16xMYG8TE0eU6HMgZpNA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=PPkc23PWADq38BY4qX9q4w/6gPxGHDD5bTLImLKkkGqJzPvmTBtwITPlLn9+g7t7N
	 +0lQ8n7YdHVlDUnN/socawhM2o52he/9Ey4ytdfMQTlZ6cgIKk3p1SZMkWcHJAkiAc
	 9SdtQ/BUfjuL7GYdGh5Kskp/STcqlllbVVQlyYe2tOCbMkh0ozB7svGtm2pzzoOH7j
	 vnruOclQJ/gwZYuNVVrpWRlDuWvm9Z1QBx09l1AHyjRlCymAkHwZblprrIG23QiVdk
	 zCcuFXlWZfnBLPtfZQ9VPsjBTvRmKvbdUYOnqTaxweW+qZ8K0wD2tYQ2MuiwC8e43K
	 bcbJ4PCI9HFag==
Date: Fri, 30 May 2025 18:31:01 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h
In-Reply-To: <20250530120242.39398-13-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-13-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> to a separate file for x86 to take.
> 
> Move functions required for early FDT parsing from device_tree.h and arm's
> setup.h onto bootfdt.h
> 
> Declaration motion only. Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/arch/arm/include/asm/setup.h |  6 ----
>  xen/include/xen/bootfdt.h        | 62 ++++++++++++++++++++++++++++++++
>  xen/include/xen/device_tree.h    | 34 +-----------------
>  3 files changed, 63 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 0f9e531a34..32308837a9 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -55,12 +55,6 @@ void setup_mm(void);
>  extern uint32_t hyp_traps_vector[];
>  void init_traps(void);
>  
> -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> -
> -u32 device_tree_get_u32(const void *fdt, int node,
> -                        const char *prop_name, u32 dflt);
> -
>  int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
>                    struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
>  
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index fa65e8fcf4..079259c719 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -2,6 +2,7 @@
>  #ifndef XEN_BOOTFDT_H
>  #define XEN_BOOTFDT_H
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -16,8 +17,53 @@
>  #define NR_MEM_BANKS 256
>  #define NR_SHMEM_BANKS 32
>  
> +/* Default #address and #size cells */
> +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> +
>  #define MAX_MODULES 32 /* Current maximum useful modules */
>  
> +#define DEVICE_TREE_MAX_DEPTH 16
> +
> +/* Helper to read a big number; size is in cells (not bytes) */
> +static inline u64 dt_read_number(const __be32 *cell, int size)
> +{
> +    u64 r = 0;
> +
> +    while ( size-- )
> +        r = (r << 32) | be32_to_cpu(*(cell++));
> +    return r;
> +}
> +
> +static inline u64 dt_next_cell(int s, const __be32 **cellp)
> +{
> +    const __be32 *p = *cellp;
> +
> +    *cellp = p + s;
> +    return dt_read_number(p, s);
> +}
> +
> +typedef int (*device_tree_node_func)(const void *fdt,
> +                                     int node, const char *name, int depth,
> +                                     u32 address_cells, u32 size_cells,
> +                                     void *data);
> +
> +/**
> + * device_tree_for_each_node - iterate over all device tree sub-nodes
> + * @fdt: flat device tree.
> + * @node: parent node to start the search from
> + * @func: function to call for each sub-node.
> + * @data: data to pass to @func.
> + *
> + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> + *
> + * Returns 0 if all nodes were iterated over successfully.  If @func
> + * returns a value different from 0, that value is returned immediately.
> + */
> +int device_tree_for_each_node(const void *fdt, int node,
> +                              device_tree_node_func func,
> +                              void *data);
> +
>  typedef enum {
>      BOOTMOD_XEN,
>      BOOTMOD_FDT,
> @@ -246,4 +292,20 @@ static inline struct membanks *membanks_xzalloc(unsigned int nr,
>      return banks;
>  }
>  
> +/*
> + * Interpret the property `prop_name` of `node` as a u32.
> + *
> + * Returns the property value on success; otherwise returns `dflt`.
> + */
> +uint32_t device_tree_get_u32(const void *fdt, int node,
> +                             const char *prop_name, uint32_t dflt);

The u32->uint32_t change is fine by me but you also need to change the
implementation otherwise we are going to get a MISRA error declaration
!= definition.

I'll take this opportunity to suggest you scan this series through
MISRA.


> +/*
> + * Interpret the property `prop_name` of `node` as a "reg".
> + *
> + * Returns outputs in `start` and `size`.
> + */
> +void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                         uint32_t size_cells, paddr_t *start, paddr_t *size);
> +
>  #endif /* XEN_BOOTFDT_H */
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 6dc1fb5159..0a22b1ba1d 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -10,6 +10,7 @@
>  #ifndef __XEN_DEVICE_TREE_H__
>  #define __XEN_DEVICE_TREE_H__
>  
> +#include 
>  #include 
>  
>  #include 
> @@ -22,8 +23,6 @@
>  #include 
>  #include 
>  
> -#define DEVICE_TREE_MAX_DEPTH 16
> -
>  /*
>   * Struct used for matching a device
>   */
> @@ -164,17 +163,8 @@ struct dt_raw_irq {
>      u32 specifier[DT_MAX_IRQ_SPEC];
>  };
>  
> -typedef int (*device_tree_node_func)(const void *fdt,
> -                                     int node, const char *name, int depth,
> -                                     u32 address_cells, u32 size_cells,
> -                                     void *data);
> -
>  extern const void *device_tree_flattened;
>  
> -int device_tree_for_each_node(const void *fdt, int node,
> -                              device_tree_node_func func,
> -                              void *data);
> -
>  /**
>   * dt_unflatten_host_device_tree - Unflatten the host device tree
>   *
> @@ -245,10 +235,6 @@ void intc_dt_preinit(void);
>  #define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
>  #define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
>  
> -/* Default #address and #size cells */
> -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2
> -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1
> -
>  #define dt_for_each_property_node(dn, pp)                   \
>      for ( pp = (dn)->properties; (pp) != NULL; pp = (pp)->next )
>  
> @@ -258,16 +244,6 @@ void intc_dt_preinit(void);
>  #define dt_for_each_child_node(dt, dn)                      \
>      for ( dn = (dt)->child; (dn) != NULL; dn = (dn)->sibling )
>  
> -/* Helper to read a big number; size is in cells (not bytes) */
> -static inline u64 dt_read_number(const __be32 *cell, int size)
> -{
> -    u64 r = 0;
> -
> -    while ( size-- )
> -        r = (r << 32) | be32_to_cpu(*(cell++));
> -    return r;
> -}
> -
>  /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */
>  static inline paddr_t dt_read_paddr(const __be32 *cell, int size)
>  {
> @@ -307,14 +283,6 @@ static inline int dt_size_to_cells(int bytes)
>      return (bytes / sizeof(u32));
>  }
>  
> -static inline u64 dt_next_cell(int s, const __be32 **cellp)
> -{
> -    const __be32 *p = *cellp;
> -
> -    *cellp = p + s;
> -    return dt_read_number(p, s);
> -}
> -
>  static inline const char *dt_node_full_name(const struct dt_device_node *np)
>  {
>      return (np && np->full_name) ? np->full_name : "";
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat May 31 01:40:52 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 01:40:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001825.1381951 (Exim 4.92)
	(envelope-from )
	id 1uLBDG-0001m0-Hq; Sat, 31 May 2025 01:40:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001825.1381951; Sat, 31 May 2025 01: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 1uLBDG-0001lt-Ei; Sat, 31 May 2025 01:40:42 +0000
Received: by outflank-mailman (input) for mailman id 1001825;
 Sat, 31 May 2025 01:40:41 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLBDF-0001kU-E5
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 01:40:41 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4194fcfa-3dc0-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 03:40:40 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id A5E145C0FD5;
 Sat, 31 May 2025 01:38:21 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05D67C4CEEB;
 Sat, 31 May 2025 01:40: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" 
X-Inumbo-ID: 4194fcfa-3dc0-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748655638;
	bh=cP4o468SMUz9PkGeeZgcT/TphTTCv9bNJOcBT5Pvcak=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=FiHzGjxmqJMoZvX2mT5e6VF0CEwLToHHDVrj+qyLOWtCCBLw/XRuEhsSS2yNeVbni
	 2hZBCym+N3Qb9TuHjvMVOGUyiJiQbMU7mDxkxxLTogSj+sh0KeYclXg9UdZ3Mt0lUm
	 6BnB97Yb/1z900FUKcE/kJaAEiOWc2SUrBzB5H5s/L+d9FdK0aYfdBMp5TJQ8MkOhv
	 9GQHXxmx6uJZtnFbQ0yBa2pdyai0rTLA22wZ3Z2hxbi7IPOSPBmft8w4To5GmuqtuF
	 GkhOS75TDmR7Qhd9NjL9vb/cDbnqUdkWPqf0DJzD1RrH0st96sENNfbl36UyBJjebc
	 /+ewpIzV75dLg==
Date: Fri, 30 May 2025 18:40:34 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 12/19] xen/dt: Move bootfdt functions to xen/bootfdt.h
In-Reply-To: <20250530120242.39398-13-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-13-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-491752089-1748655625=:1147082"
Content-ID: 

  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-491752089-1748655625=:1147082
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of bootinfo
> to a separate file for x86 to take.
> 
> Move functions required for early FDT parsing from device_tree.h and arm's
> setup.h onto bootfdt.h
> 
> Declaration motion only. Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 

I get this build error:

  CC      common/sysctl.o
In file included from ./include/xen/fdt-kernel.h:11,
                 from ./arch/x86/include/asm/bootinfo.h:12,
                 from arch/x86/hvm/dom0_build.c:19:
./include/xen/device_tree.h:112:19: error: field ‘dev’ has incomplete type
  112 |     struct device dev;
      |                   ^~~
--8323329-491752089-1748655625=:1147082--


From xen-devel-bounces@lists.xenproject.org Sat May 31 01:42:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 01:42:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001831.1381963 (Exim 4.92)
	(envelope-from )
	id 1uLBF1-0002aR-TN; Sat, 31 May 2025 01:42:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001831.1381963; Sat, 31 May 2025 01:42: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 1uLBF1-0002aK-P9; Sat, 31 May 2025 01:42:31 +0000
Received: by outflank-mailman (input) for mailman id 1001831;
 Sat, 31 May 2025 01:42:31 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLBF1-0002aE-0G
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 01:42:31 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 828ac196-3dc0-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 03:42:28 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id BB35CA4FB3D;
 Sat, 31 May 2025 01:42:27 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54E03C4CEEB;
 Sat, 31 May 2025 01:42: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" 
X-Inumbo-ID: 828ac196-3dc0-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748655747;
	bh=u1dJsMgM3KzjGoDPaYsft6HHPcYrrWkYrCQihYWct6o=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=MCFTJC41QAeRleF4hecQmzxjGZzVsmfk7s8Q0hP0h45VCg1thdeuq7qrx9uCVPDV0
	 jpbiy4qFZxgKSYax9I1HVZAeQIolzws+R7cDd3XoWF8z1QoqYGR9mAvllDiSbG6JkC
	 BX/lcfINItwhr9WkQhGE2wLzK2hJKT67wTWrfD49DIf09dXX3N3mnbWvZ4j1J+wsaL
	 werGm8O4oa2ZyKXIueD+4in4uaPtuhWGj9LicPVLOu5b1spOYo4xJyT/oGxekG3eQO
	 38fB8aMqftnhnjMyGji0VB0yUQIi2H5Op1Qb/hrxc5OQsrVyknrY8siu5G67ZL4A73
	 Swnh0HDGcCmJw==
Date: Fri, 30 May 2025 18:42:23 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    Alistair Francis , 
    Bob Eshleman , 
    Connor Davis , 
    Oleksii Kurochko , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 13/19] xen/dt: Move bootinfo functions to a new
 bootinfo.h
In-Reply-To: <20250530120242.39398-14-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-14-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of
> bootinfo to a separate file for x86 to take.
> 
> With this, bootfdt.h can be cleanly included from x86. A later patch
> extracts the definitions so the functions may be called too.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/arch/arm/domain_build.c             |   1 +
>  xen/arch/arm/mmu/mm.c                   |   1 +
>  xen/arch/riscv/mm.c                     |   2 +-
>  xen/arch/riscv/setup.c                  |   2 +-
>  xen/common/device-tree/bootfdt.c        |   1 +
>  xen/common/device-tree/bootinfo.c       |   2 +-
>  xen/common/device-tree/dom0less-build.c |   2 +-
>  xen/common/device-tree/domain-build.c   |   2 +-
>  xen/common/device-tree/kernel.c         |   2 +-
>  xen/include/xen/bootfdt.h               | 206 -----------------------
>  xen/include/xen/bootinfo.h              | 212 ++++++++++++++++++++++++
>  xen/include/xen/device_tree.h           |   2 +-
>  xen/include/xen/fdt-domain-build.h      |   2 +-
>  xen/include/xen/fdt-kernel.h            |   2 +-
>  14 files changed, 224 insertions(+), 215 deletions(-)
>  create mode 100644 xen/include/xen/bootinfo.h
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 11cc03e5db..c53da76682 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1,5 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c
> index 9c50479c63..77f82757bb 100644
> --- a/xen/arch/arm/mmu/mm.c
> +++ b/xen/arch/arm/mmu/mm.c
> @@ -1,5 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-or-later */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
> index d3ece9f132..040db73d00 100644
> --- a/xen/arch/riscv/mm.c
> +++ b/xen/arch/riscv/mm.c
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
> index 4e416f6e44..0a2d0dc1eb 100644
> --- a/xen/arch/riscv/setup.c
> +++ b/xen/arch/riscv/setup.c
> @@ -2,7 +2,7 @@
>  
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
> index 529c91e603..fb4ac06390 100644
> --- a/xen/common/device-tree/bootfdt.c
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -6,6 +6,7 @@
>   */
>  
>  #include 

Is this kept on purpose?


> +#include 
>  #include 
>  #include 
>  #include 



From xen-devel-bounces@lists.xenproject.org Sat May 31 01:43:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 01:43:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001764.1381979 (Exim 4.92)
	(envelope-from )
	id 1uLBGP-0003AF-Ht; Sat, 31 May 2025 01:43:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001764.1381979; Sat, 31 May 2025 01: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 1uLBGP-000398-BW; Sat, 31 May 2025 01:43:57 +0000
Received: by outflank-mailman (input) for mailman id 1001764;
 Sat, 31 May 2025 00:54:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLAUt-0000GH-08
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:54:51 +0000
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com
 [2607:f8b0:4864:20::12a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id da31296d-3db9-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 02:54:49 +0200 (CEST)
Received: by mail-il1-x12a.google.com with SMTP id
 e9e14a558f8ab-3dc6c0b0a3fso672555ab.2
 for ; Fri, 30 May 2025 17:54:49 -0700 (PDT)
Received: from kf-m2g5 ([2607:fb91:729:c9c7:4a01:2714:55f9:a90c])
 by smtp.gmail.com with ESMTPSA id
 ca18e2360f4ac-86cf5ecf006sm83956839f.28.2025.05.30.17.54.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 17: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" 
X-Inumbo-ID: da31296d-3db9-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748652888; x=1749257688; darn=lists.xenproject.org;
        h=mime-version:references:in-reply-to:message-id:subject:cc:to:from
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=K5spsPu6UV7ElyfOSpiYDryfMs8xGGj7JCGQGjfOEpA=;
        b=hVdRYlRMJSoo3Jh0ia/PtFGxTdxfHifdIA8/tZrPxI/42zhc9pqoVN8XqDLY8wGwP9
         VYQRtuqiA0496gSNgeHGA7tQLLo9bo35U7fI5IT1wmi2v+yMHdbMU529RCLLpIIUYUy8
         QZKXEqW3WSwWFbG6iKiYCumvI1in4teyykiiW7InJqd4MKUvAG5cW2IqUADK304UA5Fi
         VV6FMFIOjHQe4Kf47VupnopY0AnN4tvX8cElzKUkhn0MybTTBWMt21CxENeEfyCEKNxy
         +53E6908iCGliZrnz2ljXoPcg560Vt3X38YKfxytfrp7eHJCXz98z1KsBzA/dtx+rZTZ
         1wXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748652888; x=1749257688;
        h=mime-version:references:in-reply-to:message-id:subject:cc:to:from
         :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=K5spsPu6UV7ElyfOSpiYDryfMs8xGGj7JCGQGjfOEpA=;
        b=qzdrbSJn0Vo4bT/Ma3SIah/q95jcNZgItA/F/wtM6RJEakFCD5ApVbvfQwKGjdo7A7
         PPX8/mOTX4kYNjn/nA+XRsyT1IHx3htdjy7y/pOvR2G+x89BTpu+rWeuO9YYTrdxvAky
         QKIAWC2ccM38KVzeO7QANZQY6L57eEaZacNM4flGrbn6Jx/1OBYb1DdnGWQDu/pQfEyZ
         O2VnRXD6zHbeyeco3KU0VoIzMIpXLbBsdY7Jp3hOUkkJ/fqAgsmEl9yatiVcuEKFbis4
         mBaQCGTIw/1i69mHfz6Mf6Mhx4hopv2aBpPuDxWkYdSdYp1wzcoj9UAWJh8NZlX1Wl2T
         XeKg==
X-Gm-Message-State: AOJu0Yx6+dW4AX0GxIILu/uY2sl+DuaHcvJpMHdCeKn/L/h3NNFWauhs
	Sh6YQxyezFywpv+p9abeqGSl2Hkyv2t7tgnJrvkxYWZW1ocXKoKbuHzy
X-Gm-Gg: ASbGnctajYOUH1iKBxpAEQ6934w9GbM61N+DzfMx8Synp/ADTpRaG9w/i1MChqA3csq
	I/QCLLx9ZxKIa9AHkscM0lXzo9gJAFvhtr1R1iSF758J+akIAuQqsRlhSVYzC0SBmQzhUbVQMUK
	aojWKb9q5dR+W75bnjoNN52Yr7gwnHeImycn/2bgmGHCC/Yt715tRsed8HaVkB3EtZ/6lzMeOlE
	PrVv4FcdJGsOQwLjTZy2L+1JOj0r21xkOaVg80YNgIahlT1N6rZrbcerl8njmJVJBC9QdzgaXiw
	neccmZd3qe2lP55NR2RtcmxuOaeCJCDsI6nhjVxgu9jQ9DzX
X-Google-Smtp-Source: AGHT+IFw3Vhx6o1QsLR5UHPH2Xom7iLgxpvrWujEYAlYSIWIbpk/xNl2WeC7eTmy4d9409yljloOSA==
X-Received: by 2002:a05:6602:2c87:b0:85a:fd80:df2b with SMTP id ca18e2360f4ac-86d026396f7mr141024039f.2.1748652887963;
        Fri, 30 May 2025 17:54:47 -0700 (PDT)
Date: Fri, 30 May 2025 19:54:38 -0500
From: Aaron Rainbolt 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org, dkiper@net-space.pl, phcoder@gmail.com
Subject: [PATCH v2 1/1] kern/xen: Add Xen command line parsing
Message-ID: <20250530195438.4d243157@kf-m2g5>
In-Reply-To: <20250530195306.41af4199@kf-m2g5>
References: <20250530195306.41af4199@kf-m2g5>
X-Mailer: Claws Mail 4.3.1 (GTK 3.24.41; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/XuEbgScqF3BIrX3JSBisdIA";
 protocol="application/pgp-signature"; micalg=pgp-sha512

--Sig_/XuEbgScqF3BIrX3JSBisdIA
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Xen traditionally allows customizing guest behavior by passing arguments
to the VM kernel via the kernel command line. This is no longer possible
when using GRUB with Xen, as the kernel command line is decided by the
GRUB configuration file within the guest, not data passed to the guest
by Xen.

To work around this limitation, enable GRUB to parse a command line
passed to it by Xen, and expose data from the command line to the GRUB
configuration as environment variables. These variables can be used in
the GRUB configuration for any desired purpose, such as extending the
kernel command line passed to the guest. The command line format is
inspired by the Linux kernel's command line format.

To reduce the risk of misuse, abuse, or accidents in production, the
command line will only be parsed if it consists entirely of 7-bit ASCII
characters, only alphabetical characters and underscores are permitted
in variable names, and all variable names must start with the string
"xen_grub_env_". This also allows room for expanding the command line
arguments accepted by GRUB in the future, in case additional APIs using
the Xen kernel command line need to be introduced.

Signed-off-by: Aaron Rainbolt 
---
 docs/grub.texi                |  50 +++++
 grub-core/Makefile.core.def   |   2 +
 grub-core/kern/i386/xen/pvh.c |  14 ++
 grub-core/kern/main.c         |  12 ++
 grub-core/kern/xen/cmdline.c  | 344 ++++++++++++++++++++++++++++++++++
 include/grub/xen.h            |   2 +
 6 files changed, 424 insertions(+)
 create mode 100644 grub-core/kern/xen/cmdline.c

diff --git a/docs/grub.texi b/docs/grub.texi
index 34b3484..ce82483 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3271,6 +3271,7 @@ GRUB.  Others may be used freely in GRUB configuratio=
n files.
 @menu
 * Special environment variables::
 * Environment block::
+* Passing environment variables through Xen::
 @end menu
=20
=20
@@ -3871,6 +3872,55 @@ using BIOS or EFI functions (no ATA, USB or IEEE1275=
).
 @command{grub-mkconfig} uses this facility to implement
 @samp{GRUB_SAVEDEFAULT} (@pxref{Simple configuration}).
=20
+@node Passing environment variables through Xen
+@section Passing environment variables through Xen
+
+If you are using a GRUB image as the kernel for a PV or PVH Xen virtual
+machine, you can pass environment variables from Xen's dom0 to the VM thro=
ugh
+the Xen-provided kernel command line. When combined with a properly config=
ured
+guest, this can be used to customize the guest's behavior on bootup via the
+VM's Xen configuration file.
+
+GRUB will parse the kernel command line passed to it by Xen during bootup.
+The command line will be split into space-delimited words. Single and
+double quotes may be used to quote words or portions of words that contain
+spaces. Arbitrary characters may be backslash-escaped to make them a liter=
al
+component of a word rather than being parsed as quotes or word separators.=
 The
+command line must consist entirely of printable 7-bit ASCII characters and
+spaces. If a non-printing ASCII character is found anywhere in the command
+line, the entire command line will be ignored by GRUB.
+
+Each word should be a variable assignment in the format ``variable'' or
+``variable=3Dvalue''. Variable names must contain only the characters A-Z,=
 a-z,
+and underscore (``_''). Variable names must begin with the string
+``xen_grub_env_''. Variable values can contain arbitrary printable 7-bit
+ASCII characters and space. If any variable contains an illegal name, that
+variable will be ignored.
+
+If a variable name and value are both specified, the variable will be set =
to
+the specified value. If only a variable name is specified, the variable's
+value will be set to ``1''.
+
+The following is a simple example of how to use this functionality to appe=
nd
+arbitrary variables to a guest's kernel command line:
+
+@example
+# In the Xen configuration file for the guest
+name =3D "linux_vm"
+type =3D "pvh"
+kernel =3D "/path/to/grub-i386-xen_pvh.bin"
+extra =3D "xen_grub_env_kernelappend=3D'loglevel=3D3'"
+memory =3D 1024
+disk =3D [ "file:/srv/vms/linux_vm.img,sda,w" ]
+
+# In the guest's GRUB configuration file
+menuentry "Linux VM with dom0-specified kernel parameters" @{
+    search --set=3Droot --label linux_vm --hint hd0,msdos1
+    linux /boot/vmlinuz root=3DLABEL=3Dlinux_vm $@{xen_grub_env_kernelappe=
nd@}
+    initrd /boot/initrd.img
+@}
+@end example
+
 @node Modules
 @chapter Modules
=20
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index f70e02e..79e681a 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -248,6 +248,7 @@ kernel =3D {
   xen =3D term/xen/console.c;
   xen =3D disk/xen/xendisk.c;
   xen =3D commands/boot.c;
+  xen =3D kern/xen/cmdline.c;
=20
   i386_xen_pvh =3D commands/boot.c;
   i386_xen_pvh =3D disk/xen/xendisk.c;
@@ -255,6 +256,7 @@ kernel =3D {
   i386_xen_pvh =3D kern/i386/xen/tsc.c;
   i386_xen_pvh =3D kern/i386/xen/pvh.c;
   i386_xen_pvh =3D kern/xen/init.c;
+  i386_xen_pvh =3D kern/xen/cmdline.c;
   i386_xen_pvh =3D term/xen/console.c;
=20
   ia64_efi =3D kern/ia64/efi/startup.S;
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
index 91fbca8..12df2d8 100644
--- a/grub-core/kern/i386/xen/pvh.c
+++ b/grub-core/kern/i386/xen/pvh.c
@@ -321,6 +321,8 @@ void
 grub_xen_setup_pvh (void)
 {
   grub_addr_t par;
+  const char *xen_cmdline;
+  int i;
=20
   grub_xen_cpuid_base ();
   grub_xen_setup_hypercall_page ();
@@ -352,6 +354,18 @@ grub_xen_setup_pvh (void)
   grub_xen_mm_init_regions ();
=20
   grub_rsdp_addr =3D pvh_start_info->rsdp_paddr;
+
+  xen_cmdline =3D (const char *) pvh_start_info->cmdline_paddr;
+  for (i =3D 0; i < MAX_GUEST_CMDLINE; i++)
+    {
+      if (xen_cmdline[i] =3D=3D '\0')
+        {
+          grub_strncpy ((char *) grub_xen_start_page_addr->cmd_line,
+			(char *) pvh_start_info->cmdline_paddr,
+			MAX_GUEST_CMDLINE);
+          break;
+        }
+    }
 }
=20
 grub_err_t
diff --git a/grub-core/kern/main.c b/grub-core/kern/main.c
index 143a232..f96b16f 100644
--- a/grub-core/kern/main.c
+++ b/grub-core/kern/main.c
@@ -40,6 +40,10 @@
 static bool cli_disabled =3D false;
 static bool cli_need_auth =3D false;
=20
+#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XEN_PVH)
+#include 
+#endif
+
 grub_addr_t
 grub_modules_get_end (void)
 {
@@ -351,6 +355,14 @@ grub_main (void)
   grub_env_export ("root");
   grub_env_export ("prefix");
=20
+  /*
+   * Parse command line parameters from Xen and export them as environment
+   * variables
+   */
+#if defined (GRUB_MACHINE_XEN) || defined (GRUB_MACHINE_XEN_PVH)
+  grub_parse_xen_cmdline ();
+#endif
+
   /* Reclaim space used for modules.  */
   reclaim_module_space ();
=20
diff --git a/grub-core/kern/xen/cmdline.c b/grub-core/kern/xen/cmdline.c
new file mode 100644
index 0000000..8d3422d
--- /dev/null
+++ b/grub-core/kern/xen/cmdline.c
@@ -0,0 +1,344 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2025  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+enum parse_flags
+{
+  PARSER_HIT_BACKSLASH =3D 0x1,
+  PARSER_IN_SINGLE_QUOTES =3D 0x2,
+  PARSER_IN_DOUBLE_QUOTES =3D 0x4,
+};
+
+#define PARSER_BASE_WORD_LEN 16
+
+static grub_size_t word_list_len;
+static char **word_list;
+static grub_size_t current_word_len;
+static grub_size_t current_word_pos;
+static char *current_word;
+static char current_char;
+
+static bool
+append_char_to_word (bool allow_null)
+{
+  /*
+   * Fail if the current char is outside of the range 0x20 to 0x7E. If
+   * allow_null is true, make an exception for 0x00. This is a safeguard
+   * against likely-invalid data.
+   */
+  if ( (!(current_char >=3D 0x20) || !(current_char <=3D 0x7E) )
+      && (current_char !=3D '\0' || allow_null =3D=3D false))
+    return false;
+
+  if (current_word_pos =3D=3D current_word_len)
+    {
+      current_word_len *=3D 2;
+      current_word =3D grub_realloc (current_word, current_word_len);
+      if (current_word =3D=3D NULL)
+        {
+          current_word_len /=3D 2;
+          return false;
+        }
+    }
+
+  current_word[current_word_pos] =3D current_char;
+  current_word_pos++;
+  return true;
+}
+
+static bool
+append_word_to_list (void)
+{
+  /* No-op on empty words. */
+  if (current_word_pos =3D=3D 0)
+    return true;
+
+  current_char =3D '\0';
+  if (append_char_to_word (true) =3D=3D false)
+    {
+      grub_error (GRUB_ERR_BUG,
+		  "couldn't append null terminator to word during Xen cmdline parsing");
+      grub_print_error ();
+      grub_exit ();
+    }
+
+  current_word_len =3D grub_strlen (current_word) + 1;
+  current_word =3D grub_realloc (current_word, current_word_len);
+  if (current_word =3D=3D NULL)
+    return false;
+  word_list_len++;
+  word_list =3D grub_realloc (word_list, word_list_len * sizeof (char *));
+  if (word_list =3D=3D NULL)
+    return false;
+  word_list[word_list_len - 1] =3D current_word;
+
+  current_word_len =3D PARSER_BASE_WORD_LEN;
+  current_word_pos =3D 0;
+  current_word =3D grub_malloc (current_word_len);
+  if (current_word =3D=3D NULL)
+    return false;
+
+  return true;
+}
+
+static bool
+check_key_is_safe (char *key, grub_size_t len)
+{
+  grub_size_t i;
+
+  for (i =3D 0; i < len; i++)
+  {
+    /*
+     * Ensure only a-z, A-Z, and _ are allowed.
+     */
+    if (! ( (key[i] >=3D 'A' && key[i] <=3D 'Z')
+          || (key[i] >=3D 'a' && key[i] <=3D 'z')
+          || (key[i] =3D=3D '_') ) )
+      return false;
+  }
+  return true;
+}
+
+void
+grub_parse_xen_cmdline (void)
+{
+  const char *cmdline =3D (const char *) grub_xen_start_page_addr->cmd_lin=
e;
+  bool cmdline_valid =3D false;
+  char **param_keys =3D NULL;
+  char **param_vals =3D NULL;
+  grub_size_t param_dict_len =3D 0;
+  grub_size_t param_dict_pos =3D 0;
+  enum parse_flags parse_flags =3D 0;
+  grub_size_t i =3D 0;
+
+  /*
+   * The following algorithm is used to parse the Xen command line:
+   *
+   * - The command line is split into space-separated words.
+   *   - Single and double quotes may be used to suppress the splitting
+   *     behavior of spaces.
+   *   - Double quotes are appended to the current word verbatim if they
+   *     appear within a single-quoted string portion, and vice versa.
+   *   - Backslashes may be used to cause the next character to be
+   *     appended to the current word verbatim. This is only useful when
+   *     used to escape quotes, spaces, and backslashes, but for simplicity
+   *     we allow backslash-escaping anything.
+   * - After splitting the command line into words, each word is checked to
+   *   see if it contains an equals sign.
+   *   - If it does, it is split on the equals sign into a key-value pair.=
 The
+   *     key is then treated as an variable name, and the value is treated=
 as
+   *     the variable's value.
+   *   - If it does not, the entire word is treated as a variable name. The
+   *     variable's value is implicitly considered to be `1`.
+   * - All variables detected on the command line are checked to see if th=
eir
+   *   names begin with the string `xen_grub_env_`. Variables that do not =
pass
+   *   this check are discarded, variables that do pass this check are
+   *   exported so they are available to the GRUB configuration.
+   */
+
+  current_word_len =3D PARSER_BASE_WORD_LEN;
+  current_word =3D grub_malloc (current_word_len);
+  if (current_word =3D=3D NULL)
+    goto cleanup;
+
+  for (i =3D 0; i < MAX_GUEST_CMDLINE; i++)
+    {
+      if (cmdline[i] =3D=3D '\0')
+        {
+          cmdline_valid =3D true;
+          break;
+        }
+    }
+
+  if (cmdline_valid =3D=3D false)
+    {
+      grub_error (GRUB_ERR_BAD_ARGUMENT,
+		  "Command line from Xen is not NUL-terminated");
+      grub_print_error ();
+      goto cleanup;
+    }
+
+  for (i =3D 0; i < grub_strlen (cmdline); i++)
+    {
+      current_char =3D cmdline[i];
+
+      /*
+       * If the previous character was a backslash, append the current
+       * character to the word verbatim
+       */
+      if (parse_flags & PARSER_HIT_BACKSLASH)
+        {
+          parse_flags ^=3D PARSER_HIT_BACKSLASH;
+          if (append_char_to_word (false) =3D=3D false)
+            goto cleanup;
+          continue;
+        }
+
+      switch (current_char)
+        {
+        case '\\':
+          /* Backslashes escape arbitrary characters. */
+          parse_flags ^=3D PARSER_HIT_BACKSLASH;
+          continue;
+
+        case '\'':
+          /*
+           * Single quotes suppress word splitting and double quoting until
+           * the next single quote is encountered.
+           */
+          if (parse_flags & PARSER_IN_DOUBLE_QUOTES)
+            {
+              if (append_char_to_word (false) =3D=3D false)
+                goto cleanup;
+              continue;
+            }
+
+          parse_flags ^=3D PARSER_IN_SINGLE_QUOTES;
+          continue;
+
+        case '"':
+          /*
+           * Double quotes suppress word splitting and single quoting until
+           * the next double quote is encountered.
+           */
+          if (parse_flags & PARSER_IN_SINGLE_QUOTES)
+            {
+              if (append_char_to_word (false) =3D=3D false)
+                goto cleanup;
+              continue;
+            }
+
+          parse_flags ^=3D PARSER_IN_DOUBLE_QUOTES;
+          continue;
+
+        case ' ':
+          /* Spaces separate words in the command line from each other. */
+          if (parse_flags & PARSER_IN_SINGLE_QUOTES
+              || parse_flags & PARSER_IN_DOUBLE_QUOTES)
+            {
+              if (append_char_to_word (false) =3D=3D false)
+                goto cleanup;
+              continue;
+            }
+
+          if (append_word_to_list () =3D=3D false)
+            goto cleanup;
+          continue;
+        }
+
+      if (append_char_to_word (false) =3D=3D false)
+        goto cleanup;
+    }
+
+  if (append_word_to_list () =3D=3D false)
+    goto cleanup;
+
+  param_keys =3D grub_malloc (word_list_len * sizeof (char *));
+  if (param_keys =3D=3D NULL)
+    goto cleanup;
+  param_vals =3D grub_malloc (word_list_len * sizeof (char *));
+  if (param_vals =3D=3D NULL)
+    goto cleanup;
+
+  for (i =3D 0; i < word_list_len; i++)
+    {
+      char *current_word_eq_ptr;
+
+      current_word =3D word_list[i];
+      current_word_len =3D grub_strlen (current_word) + 1;
+      current_word_eq_ptr =3D grub_strchr (current_word, '=3D');
+
+      if (current_word_eq_ptr)
+        {
+          grub_size_t eq_idx =3D (grub_size_t)(current_word_eq_ptr - curre=
nt_word);
+          grub_size_t pre_eq_len =3D current_word_len - (current_word_len =
- eq_idx);
+          grub_size_t post_eq_len =3D current_word_len - (eq_idx);
+
+          if (check_key_is_safe (current_word, pre_eq_len))
+            {
+              param_dict_pos =3D param_dict_len;
+              param_dict_len++;
+              param_keys[param_dict_pos] =3D grub_malloc (pre_eq_len + 1);
+              if (param_keys =3D=3D NULL)
+                goto cleanup;
+              param_vals[param_dict_pos] =3D grub_malloc (post_eq_len + 1);
+              if (param_vals =3D=3D NULL)
+                goto cleanup;
+
+              grub_strncpy (param_keys[param_dict_pos], current_word,
+			    pre_eq_len);
+              grub_strncpy (param_vals[param_dict_pos],
+			    current_word + pre_eq_len + 1, post_eq_len);
+              param_keys[param_dict_pos][pre_eq_len] =3D '\0';
+              param_vals[param_dict_pos][post_eq_len] =3D '\0';
+            }
+        }
+      else
+        {
+          if (check_key_is_safe (current_word, current_word_len - 1))
+            {
+              param_dict_pos =3D param_dict_len;
+              param_dict_len++;
+              param_keys[param_dict_pos] =3D grub_malloc (current_word_len=
);
+              if (param_keys =3D=3D NULL)
+                goto cleanup;
+              param_vals[param_dict_pos] =3D grub_malloc (2);
+              if (param_vals =3D=3D NULL)
+                goto cleanup;
+
+              grub_strncpy (param_keys[param_dict_pos], current_word,
+			    current_word_len);
+              grub_strcpy (param_vals[param_dict_pos], "1\0");
+            }
+        }
+    }
+
+  for (i =3D 0; i < param_dict_len; i++)
+    {
+      /*
+       * Find keys that start with "xen_grub_env_" and export them
+       * as environment variables.
+       */
+      if (grub_strlen (param_keys[i]) < (sizeof ("xen_grub_env_") - 1))
+        continue;
+      if (grub_strncmp (param_keys[i],
+			"xen_grub_env_",
+			sizeof ("xen_grub_env_") - 1) !=3D 0)
+        continue;
+      grub_env_set (param_keys[i], param_vals[i]);
+      grub_env_export (param_keys[i]);
+    }
+
+ cleanup:
+  for (i =3D 0; i < word_list_len; i++)
+    grub_free (word_list[i]);
+
+  for (i =3D 0; i < param_dict_len; i++)
+    {
+      grub_free (param_keys[i]);
+      grub_free (param_vals[i]);
+    }
+
+  grub_free (param_keys);
+  grub_free (param_vals);
+  grub_free (word_list);
+}
diff --git a/include/grub/xen.h b/include/grub/xen.h
index 91cb7cf..7f9efee 100644
--- a/include/grub/xen.h
+++ b/include/grub/xen.h
@@ -89,6 +89,8 @@ void grub_console_init (void);
 void grub_xendisk_fini (void);
 void grub_xendisk_init (void);
=20
+void grub_parse_xen_cmdline (void);
+
 #ifdef __x86_64__
 typedef grub_uint64_t grub_xen_mfn_t;
 #else
--=20
2.49.0


--Sig_/XuEbgScqF3BIrX3JSBisdIA
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEudh48PFXwyPDa0wGpwkWDXPHkQkFAmg6U04ACgkQpwkWDXPH
kQk6IQ/+L90FdpH/IgOu1TJZJiKkGfO2qfpIBfRgKoF8PT9DIhg1LF1Vl4LgXyWm
sQnQGoBuSLQJMeB6VpOaKmk2YM2EMHpqTWdb8uAXumNrMP1T/j3mh+NH3w/QOtqP
YgmwurY5lvt1Q/9GuJvtlbfJt+4JIxBsxxR+sCymT6mVZejfW/4o/o7rRSucKzKu
+EgSf3NiADA8WyZL3craUTvZM4jRscLMw/VbQ0GZaG/ygnzg3rBc5kO7tPJYG2yd
CpHdUNY1NDarrqFTRNnnZquxs4wr9VRylYSYEGx0p4griOtWXew4FFUtOh4cL4Sw
QvPN2Pb5WgdfIUpq+UDrNJECaWgkxQlRNu+KDN6DEgQ0r8lECjsAK+TzryEiXoIA
oBZpI66zpOVfnb8HQFQeI0woOHJ/0tmrh6ZWP2R8F2SMi4Y26rta0zvecZvcPENK
kbYLlSZsciwA6TbtRC26jPWR7a/+/bHLntWSvu82Pa84q1vccISoifY27M771g9x
01/Cs1OrfwkFeVaXZ1pZjrPIj//xATCUkzAWmS+yuuOrAY3+9bJ7+cJAPxJ+WVra
kHZmSr/TBAEiQJwqu3XI5VaB94lMR+fUgCSSHGDU7oKa+m5Sw4jNev/f2u1J3uOm
7JesK1ceBWc1oRQE2OjYFXRB+DQAxTgbODgMI0edAShIa5MeTbc=
=86HF
-----END PGP SIGNATURE-----

--Sig_/XuEbgScqF3BIrX3JSBisdIA--


From xen-devel-bounces@lists.xenproject.org Sat May 31 01:43:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 01:43:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001761.1381972 (Exim 4.92)
	(envelope-from )
	id 1uLBGP-00036o-72; Sat, 31 May 2025 01:43:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001761.1381972; Sat, 31 May 2025 01: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 1uLBGP-00036h-3q; Sat, 31 May 2025 01:43:57 +0000
Received: by outflank-mailman (input) for mailman id 1001761;
 Sat, 31 May 2025 00:53:19 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLATP-0000DF-3J
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 00:53:19 +0000
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com
 [2607:f8b0:4864:20::134])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a3a6cda4-3db9-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 02:53:18 +0200 (CEST)
Received: by mail-il1-x134.google.com with SMTP id
 e9e14a558f8ab-3db83492afaso876685ab.2
 for ; Fri, 30 May 2025 17:53:18 -0700 (PDT)
Received: from kf-m2g5 ([2607:fb91:729:c9c7:4a01:2714:55f9:a90c])
 by smtp.gmail.com with ESMTPSA id
 e9e14a558f8ab-3dd935288dbsm10137105ab.8.2025.05.30.17.53.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 30 May 2025 17:53: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" 
X-Inumbo-ID: a3a6cda4-3db9-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748652796; x=1749257596; darn=lists.xenproject.org;
        h=mime-version:message-id:subject:cc:to:from:date:from:to:cc:subject
         :date:message-id:reply-to;
        bh=BbI37kxQG7vp7V0ecTz+o356PMVwkE8qF6C+9oXMa5E=;
        b=l8pc1MCJM9+fVNrV+51VKmKzkPrr0GncAIIgXB3wvbnBuXmY9oZfyrZePZuQkVQUeD
         mTUdawm5xdKCFRsc7jyKNspaN3pbTCZQ2Btt5VT+v38lvfQ9adXdvUL/yd1U7uaTGEPe
         60zZM67Ae68l3l6MaPyR23e6W2PU9o0U/oUcXzFuazmiDby9p/lOJKXQupIo3GKLoyPh
         IvJSxVmB30RhlhwVyZJ6T247YUrE4vR3OH+zqEPn9h55drjUS6HmW60xU4v6Ze5emmxa
         tYp+4cHumw8VCyEqeoZEWRVF/bj3/4V7EG2h+SyWPIzbIv7dX7iHBRZwoLVT/d+sYyXJ
         v75w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748652796; x=1749257596;
        h=mime-version:message-id:subject:cc:to:from:date:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=BbI37kxQG7vp7V0ecTz+o356PMVwkE8qF6C+9oXMa5E=;
        b=xBgVpPOLQkdc8oPD15mTrtV0ciaKVmbHTuMJCMxiQP3jxthCaK4oqw7h/34rq5yque
         j9X82YgzGr7lnq2lTydln7ccLSFkP/awV58LcV2oX8ai7afPjBYewR/Bws4GREMQSfB8
         qjjxF3A45ZCsZZFWuZKxA7w0X0l4ZPMwYC6VViFl2yQTkFEjUeoCEjzMOXy5djwmwzNv
         XS/jzytqnN5wnTnebeFsIY2onE1ahSK9eOCSzxYXDEGD4wlE6+Y54rTaRfugcFMk2EJx
         1yxwfL0cBOCEuTDuaA/Wb0xYh9qvFZDQtosu+UVj/KR0xz4qO0LYApDyrbwOX7J4+38X
         NMNA==
X-Gm-Message-State: AOJu0YwpU7Lw1CADmjBqhQva16FDYEZTcFwdVtLiblE+m8e1WHKnVtW9
	kgJDJqNQViiPQNZLjaPFzbCJHKIBldJ5OergPYfr0wSV56QGF4n6+EVX
X-Gm-Gg: ASbGnctfI5nrZhbT3r//td5B9sFAVre6cAufD944lppf5iKutxEkQnIv4QOca7BSLQx
	iX1tAbvNIUfSPcHWbiVjeVT9swu3GMFjCxQL0/S9l0VcXsIlszg+Bw+QlTg4m8W4ahueOTKcin/
	uJ0QaLbc/Tj54acZKx22gwFwiVWH4xy8jhXfNXVeAlGabrKJsywWx5w1togag9Lq8fBZEO6h5RM
	6ADtBxHmUUF/jPQnKJ+Os2x1eYFrCNXvYGDzDmdS+yaQ2r4sddVQrg+2s7W7Q2V9gYEGwHrbqNw
	WuSyT6JHdcklsycPJC7TTZhKXPRc8t37p53GW62efvIpLAVI9h1KwDAa3SI=
X-Google-Smtp-Source: AGHT+IFBp8jvSDh7cqJxttpiA7HS/7CdCn/3Aos/r+reLqDQMP2JD0NugBpqWmHlxR6RaVV0ItgB/A==
X-Received: by 2002:a05:6e02:180a:b0:3d4:6d6f:6e1f with SMTP id e9e14a558f8ab-3dd99ca9400mr17312735ab.6.1748652796488;
        Fri, 30 May 2025 17:53:16 -0700 (PDT)
Date: Fri, 30 May 2025 19:53:06 -0500
From: Aaron Rainbolt 
To: grub-devel@gnu.org
Cc: xen-devel@lists.xenproject.org, dkiper@net-space.pl, phcoder@gmail.com
Subject: [PATCH v2 0/1] Xen: Add Xen command line parsing
Message-ID: <20250530195306.41af4199@kf-m2g5>
X-Mailer: Claws Mail 4.3.1 (GTK 3.24.41; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/9Nfny_rgglLe_w6W9jAdx9J";
 protocol="application/pgp-signature"; micalg=pgp-sha512

--Sig_/9Nfny_rgglLe_w6W9jAdx9J
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

The purpose of this patch is to allow the Xen hypervisor to pass extra
data to GRUB in the form of a kernel command line, allowing the host to
customize the boot process of the guest. The command line from Xen is
parsed, and any variables within that start with the string
`xen_grub_env_` are exposed as environment variables. The grub.cfg
script can then use those environment variables as it sees fit.

The main reason for doing this is to allow implementing boot modes in
Qubes OS while also using in-VM kernels. For more context on Qubes boot
modes, see [1]. In order for this to work with in-VM kernels, it is
necessary for dom0 to pass kernel parameters to the guest without
modifying the guest's grub.cfg manually. This patch allows this to be
done, by allowing dom0 to pass kernel parameters to GRUB, which then
provides them to grub.cfg as an environment variable. The grub.cfg
script within the VM can then append those variables to the kernel
command line.

The patch has been tested with both PV and PVH virtual machines, using
an otherwise unpatched GRUB source tree, building the patch on top of
the tip of git master at the time of this writing (commit 73d1c95). My
testing environment is a fully updated Arch Linux system with Xen built
from the stable-4.20 branch.

Changes from the previous version of the patch:

* Added documentation for the future to the GRUB manual.
* Fixed error checking when allocating memory.
* Enhanced coding style, code efficiency, and comments based on Daniel
  Kiper's previous review and my own re-review.
* Added an explicit null termination check on the Xen-provided kernel
  command line before parsing.
* Fixed some memory management issues that could result in unnecessary
  memory consumption (one memory leak and a couple of places where an
  extra byte was allocated that didn't need to be).

The patch has been thoroughly tested by booting a patched GRUB with
various different parameters passed to it via the Xen-provided kernel
command line. The effects of these parameters on the bootloader's
environment were then tested, and then an Arch Linux image was booted
to ensure that boot still worked. The full list of test cases and their
results can be seen at [2] (pastebinned so as to not overload people's
email clients with 185-character-long lines).

[1] https://github.com/QubesOS/qubes-linux-pvgrub2/pull/16
[2] https://bpa.st/Z45A

Aaron Rainbolt (1):
  kern/xen: Add Xen command line parsing

 docs/grub.texi                |  50 +++++
 grub-core/Makefile.core.def   |   2 +
 grub-core/kern/i386/xen/pvh.c |  14 ++
 grub-core/kern/main.c         |  12 ++
 grub-core/kern/xen/cmdline.c  | 344 ++++++++++++++++++++++++++++++++++
 include/grub/xen.h            |   2 +
 6 files changed, 424 insertions(+)
 create mode 100644 grub-core/kern/xen/cmdline.c

--=20
2.49.0


--Sig_/9Nfny_rgglLe_w6W9jAdx9J
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEudh48PFXwyPDa0wGpwkWDXPHkQkFAmg6UvIACgkQpwkWDXPH
kQkteA//ZYj9rrDDUrtS9Kt1C5YBArGy51VcG6GAZ6svAqiTdaiXpEDZYXhFC3m8
iBumFWNFxyf2o4Ngk9w3lrE2kIZFRh5ZAkpqxs1BcrAa0QojAcehW7RcVXBGd1GE
CBxJeG1y3rQHZOePHzLfZEpYdlpaDkr5yd/0FsBEYdiWLODsnQxKf99I93rrXtg4
l1NxhUQyXurrSxqVZwa/KZxsx4TOVNIkIQPv6mIRwm4tGYubi+K+6a9/CwQ+l95+
K6/gi9jQyR6F92mLOGT4H4TU+z1QiBOv+p4BbbjLsxbeI4BjHp7LcE4AxZBGerS0
Vxubh+jgrnMmGmejYPK6hE6h8ElneEjfhYpI4Aye3UncSeURwAVHczhOSmwAfg/w
lTBvF18NVIe0AA6chKMmhDFTB7K9a/rmLp8Onm0vDxRvsuR4Q8+CHXmiMvzAAtXZ
iPD8gh9CsSWqdk78J4xUOzv9fg1fzzIx8gi4mrzKfcyaSF+KyECbO1kVxbVxF5Aw
6qw0rbNp67CoqQ2K8jql9en6OxjgGyjfgAeCFwRJ6Btn/nXAr5me3+3gEKFMdhSc
pRhsPw0NeF0QMRC/rJMVPxwyK9G3ziJ/fot6ISIR2libbOAw4e57fiMJ+z6j4kTq
f4RMyl8q+AwqSZH2l2hTZzNrGvM3v1ins6JYErTvK2q014lp8BY=
=wxbL
-----END PGP SIGNATURE-----

--Sig_/9Nfny_rgglLe_w6W9jAdx9J--


From xen-devel-bounces@lists.xenproject.org Sat May 31 01:44:10 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 01:44:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001839.1381992 (Exim 4.92)
	(envelope-from )
	id 1uLBGb-0003in-UO; Sat, 31 May 2025 01:44:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001839.1381992; Sat, 31 May 2025 01:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uLBGb-0003iX-Qy; Sat, 31 May 2025 01:44:09 +0000
Received: by outflank-mailman (input) for mailman id 1001839;
 Sat, 31 May 2025 01:44:08 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLBGa-0003gb-7y
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 01:44:08 +0000
Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bd145eb3-3dc0-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 03:44:07 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by tor.source.kernel.org (Postfix) with ESMTP id E2D16629C1;
 Sat, 31 May 2025 01:44:05 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 530EDC4CEEB;
 Sat, 31 May 2025 01:44: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" 
X-Inumbo-ID: bd145eb3-3dc0-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748655845;
	bh=clU528x4zKAAvL7u1yqleYMbeplGWqTSECKfAojrYoI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=rS2fO5gHJezXQJsp+NAbePptnHGn07BHmPdNaAdVPoRWnaiw/tRVvGR30M57bEdFN
	 QnFC3RkAT9/v9piud5SDky7xE5moeLK+st982fuB2hZaX34qfA4+w6IMXGz57EwmkR
	 3f2P1j8dAnj6Iu42biL2+gLwrldmHwbz8gXudlIQN10HaaVN/16JQuj/XwT81MZXBd
	 X5sFUyvyZsRp1yjJ58ncCXpKBRjT/KhoLnms5kk4E7xSj/douSuap3Zx9jFaAXcU9o
	 zk3j7UVP9NDJcf1oBoW01wZaw5K+jwoq9sluxq81IdyExnNWV5cUaOCpWTvrAY9M3d
	 aV0LbqlwYujyw==
Date: Fri, 30 May 2025 18:44:02 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 14/19] xen/dt: Rename bootfdt.c -> bootinfo-fdt.c
In-Reply-To: <20250530120242.39398-15-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-15-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> This file will eventually contain bootfdt helpers that make heavy use of
> bootinfo. To simplify git history do the rename here explicitly. A later
> patch extracts bootinfo-independent helpers into bootfdt.c.
> 
> Doing so here would needlessly pollute the diffs.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/common/device-tree/Makefile                      | 2 +-
>  xen/common/device-tree/{bootfdt.c => bootinfo-fdt.c} | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>  rename xen/common/device-tree/{bootfdt.c => bootinfo-fdt.c} (99%)
> 
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 57b9e6ca00..bb6d5ddec5 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1,4 +1,4 @@
> -obj-y += bootfdt.init.o
> +obj-y += bootinfo-fdt.init.o
>  obj-y += bootinfo.init.o
>  obj-y += device-tree.o
>  obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootinfo-fdt.c
> similarity index 99%
> rename from xen/common/device-tree/bootfdt.c
> rename to xen/common/device-tree/bootinfo-fdt.c
> index fb4ac06390..bb5f45771e 100644
> --- a/xen/common/device-tree/bootfdt.c
> +++ b/xen/common/device-tree/bootinfo-fdt.c
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  /*
> - * Early Device Tree
> + * Early Device Tree with bootinfo hooks
>   *
>   * Copyright (C) 2012-2014 Citrix Systems, Inc.
>   */
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat May 31 01:47:58 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 01:47:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001864.1382002 (Exim 4.92)
	(envelope-from )
	id 1uLBKD-0004lE-ER; Sat, 31 May 2025 01:47:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001864.1382002; Sat, 31 May 2025 01:47:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uLBKD-0004l7-AY; Sat, 31 May 2025 01:47:53 +0000
Received: by outflank-mailman (input) for mailman id 1001864;
 Sat, 31 May 2025 01:47:51 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLBKB-0004l1-HT
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 01:47:51 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 41f46661-3dc1-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 03:47:49 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 2FF1BA4F7D4;
 Sat, 31 May 2025 01:47:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7458CC4CEEB;
 Sat, 31 May 2025 01:47: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" 
X-Inumbo-ID: 41f46661-3dc1-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748656068;
	bh=cHJ0RQCjlVXnQW79Eot28b8kZr7pVK5w3KP+uYfvCIc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=bocx9vb32gq6PGRfOfCh+f3D96XX5cAvu3i9V+7H6uHVapFXPCIE9I/lggHa/m381
	 lT1HxLraaZha+JkepifxQsljRcB81fQLcajymfK26f+lw2aaXDDNdOoKA1FIY+0Ils
	 49eZnIWg1hH/P3964gIX1vZ5tNKnAmR7twAEkzoO/0ublY7O8opT5OcDwKNbQW5oiF
	 COskZYElbNcFk7E7Ylt2qeJNHVLCMsB+DkTlkBGKsoXxcCT+PmJzbJgBJcKt7HMFgP
	 6FTfFuwkmm2nvpbkP0o2PawFp29vWMhiD7jLJP03K1hIAycvDQGd9sdJROoKii6PRs
	 ywJ8qPMh/vu1g==
Date: Fri, 30 May 2025 18:47:45 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 15/19] xen/dt: Move bootinfo-independent helpers out of
 bootinfo-fdt.c
In-Reply-To: <20250530120242.39398-16-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-16-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> ... back into bootfdt.c
> 
> These will be required by x86 later on to detect modules in the early scan of
> the FDT. They are independent of bootinfo, so it's cleaner for them to exist in
> a separate file.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 
> ---
>  xen/common/device-tree/Makefile       |   1 +
>  xen/common/device-tree/bootfdt.c      |  97 ++++++++++++++++++++++++
>  xen/common/device-tree/bootinfo-fdt.c | 104 --------------------------
>  3 files changed, 98 insertions(+), 104 deletions(-)
>  create mode 100644 xen/common/device-tree/bootfdt.c
> 
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index bb6d5ddec5..922c5bba9b 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -1,3 +1,4 @@
> +obj-y += bootfdt.init.o
>  obj-y += bootinfo-fdt.init.o
>  obj-y += bootinfo.init.o
>  obj-y += device-tree.o
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
> new file mode 100644
> index 0000000000..5decf17faf
> --- /dev/null
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -0,0 +1,97 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +uint32_t __init device_tree_get_u32(const void *fdt, int node,
> +                                    const char *prop_name, uint32_t dflt)
> +{
> +    const struct fdt_property *prop;
> +
> +    prop = fdt_get_property(fdt, node, prop_name, NULL);
> +    if ( !prop || prop->len < sizeof(u32) )

Ah this is where the u32->uint32_t renaming is done!
Since we are at it, we can change the u32 in the sizeof


> +        return dflt;
> +
> +    return fdt32_to_cpu(*(uint32_t*)prop->data);
> +}
> +
> +int __init device_tree_for_each_node(const void *fdt, int node,
> +                                     device_tree_node_func func,
> +                                     void *data)
> +{
> +    /*
> +     * We only care about relative depth increments, assume depth of
> +     * node is 0 for simplicity.
> +     */
> +    int depth = 0;
> +    const int first_node = node;
> +    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
> +    u32 size_cells[DEVICE_TREE_MAX_DEPTH];

same here?


> +    int ret;
> +
> +    do {
> +        const char *name = fdt_get_name(fdt, node, NULL);
> +        u32 as, ss;
> +
> +        if ( depth >= DEVICE_TREE_MAX_DEPTH )
> +        {
> +            printk("Warning: device tree node `%s' is nested too deep\n",
> +                   name);
> +            continue;
> +        }
> +
> +        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
> +        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
> +
> +        address_cells[depth] = device_tree_get_u32(fdt, node,
> +                                                   "#address-cells", as);
> +        size_cells[depth] = device_tree_get_u32(fdt, node,
> +                                                "#size-cells", ss);
> +
> +        /* skip the first node */
> +        if ( node != first_node )
> +        {
> +            ret = func(fdt, node, name, depth, as, ss, data);
> +            if ( ret != 0 )
> +                return ret;
> +        }
> +
> +        node = fdt_next_node(fdt, node, &depth);
> +    } while ( node >= 0 && depth > 0 );
> +
> +    return 0;
> +}
> +
> +void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> +                                uint32_t size_cells, paddr_t *start,
> +                                paddr_t *size)
> +{
> +    uint64_t dt_start, dt_size;
> +
> +    /*
> +     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
> +     * Thus, there is an implicit cast from uint64_t to paddr_t.
> +     */
> +    dt_start = dt_next_cell(address_cells, cell);
> +    dt_size = dt_next_cell(size_cells, cell);
> +
> +    if ( dt_start != (paddr_t)dt_start )
> +    {
> +        printk("Physical address greater than max width supported\n");
> +        WARN();
> +    }
> +
> +    if ( dt_size != (paddr_t)dt_size )
> +    {
> +        printk("Physical size greater than max width supported\n");
> +        WARN();
> +    }
> +
> +    /*
> +     * Xen will truncate the address/size if it is greater than the maximum
> +     * supported width and it will give an appropriate warning.
> +     */
> +    *start = dt_start;
> +    *size = dt_size;
> +}
> diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
> index bb5f45771e..736f877616 100644
> --- a/xen/common/device-tree/bootinfo-fdt.c
> +++ b/xen/common/device-tree/bootinfo-fdt.c
> @@ -112,39 +112,6 @@ static bool __init device_tree_is_memory_node(const void *fdt, int node,
>      return true;
>  }
>  
> -void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> -                                uint32_t size_cells, paddr_t *start,
> -                                paddr_t *size)
> -{
> -    uint64_t dt_start, dt_size;
> -
> -    /*
> -     * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
> -     * Thus, there is an implicit cast from uint64_t to paddr_t.
> -     */
> -    dt_start = dt_next_cell(address_cells, cell);
> -    dt_size = dt_next_cell(size_cells, cell);
> -
> -    if ( dt_start != (paddr_t)dt_start )
> -    {
> -        printk("Physical address greater than max width supported\n");
> -        WARN();
> -    }
> -
> -    if ( dt_size != (paddr_t)dt_size )
> -    {
> -        printk("Physical size greater than max width supported\n");
> -        WARN();
> -    }
> -
> -    /*
> -     * Xen will truncate the address/size if it is greater than the maximum
> -     * supported width and it will give an appropriate warning.
> -     */
> -    *start = dt_start;
> -    *size = dt_size;
> -}
> -
>  static int __init device_tree_get_meminfo(const void *fdt, int node,
>                                            const char *prop_name,
>                                            u32 address_cells, u32 size_cells,
> @@ -205,77 +172,6 @@ static int __init device_tree_get_meminfo(const void *fdt, int node,
>      return 0;
>  }
>  
> -u32 __init device_tree_get_u32(const void *fdt, int node,
> -                               const char *prop_name, u32 dflt)
> -{
> -    const struct fdt_property *prop;
> -
> -    prop = fdt_get_property(fdt, node, prop_name, NULL);
> -    if ( !prop || prop->len < sizeof(u32) )
> -        return dflt;
> -
> -    return fdt32_to_cpu(*(uint32_t*)prop->data);
> -}
> -
> -/**
> - * device_tree_for_each_node - iterate over all device tree sub-nodes
> - * @fdt: flat device tree.
> - * @node: parent node to start the search from
> - * @func: function to call for each sub-node.
> - * @data: data to pass to @func.
> - *
> - * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> - *
> - * Returns 0 if all nodes were iterated over successfully.  If @func
> - * returns a value different from 0, that value is returned immediately.
> - */
> -int __init device_tree_for_each_node(const void *fdt, int node,
> -                                     device_tree_node_func func,
> -                                     void *data)
> -{
> -    /*
> -     * We only care about relative depth increments, assume depth of
> -     * node is 0 for simplicity.
> -     */
> -    int depth = 0;
> -    const int first_node = node;
> -    u32 address_cells[DEVICE_TREE_MAX_DEPTH];
> -    u32 size_cells[DEVICE_TREE_MAX_DEPTH];
> -    int ret;
> -
> -    do {
> -        const char *name = fdt_get_name(fdt, node, NULL);
> -        u32 as, ss;
> -
> -        if ( depth >= DEVICE_TREE_MAX_DEPTH )
> -        {
> -            printk("Warning: device tree node `%s' is nested too deep\n",
> -                   name);
> -            continue;
> -        }
> -
> -        as = depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
> -        ss = depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
> -
> -        address_cells[depth] = device_tree_get_u32(fdt, node,
> -                                                   "#address-cells", as);
> -        size_cells[depth] = device_tree_get_u32(fdt, node,
> -                                                "#size-cells", ss);
> -
> -        /* skip the first node */
> -        if ( node != first_node )
> -        {
> -            ret = func(fdt, node, name, depth, as, ss, data);
> -            if ( ret != 0 )
> -                return ret;
> -        }
> -
> -        node = fdt_next_node(fdt, node, &depth);
> -    } while ( node >= 0 && depth > 0 );
> -
> -    return 0;
> -}
> -
>  static int __init process_memory_node(const void *fdt, int node,
>                                        const char *name, int depth,
>                                        u32 address_cells, u32 size_cells,
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat May 31 01:49:02 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 01:49:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001870.1382013 (Exim 4.92)
	(envelope-from )
	id 1uLBLJ-0005Fq-Nk; Sat, 31 May 2025 01:49:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001870.1382013; Sat, 31 May 2025 01:49: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 1uLBLJ-0005Fj-JR; Sat, 31 May 2025 01:49:01 +0000
Received: by outflank-mailman (input) for mailman id 1001870;
 Sat, 31 May 2025 01:48:59 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLBLH-0005FZ-Ma
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 01:48:59 +0000
Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6a624ddb-3dc1-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 03:48:58 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by sea.source.kernel.org (Postfix) with ESMTP id ACB92449B2;
 Sat, 31 May 2025 01:48:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1AFAC4CEEB;
 Sat, 31 May 2025 01:48: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" 
X-Inumbo-ID: 6a624ddb-3dc1-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748656136;
	bh=fMLIPfKSgzwgIwruh7IJBznP6b1N/KC/MHf+WAierIE=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=AdbUBfWf16XXSEJWVVusoUcJCd4CltljViGEJEr8ktyvOUeTvcWMaSlchwCL5H3pV
	 iEo01s4spUouzgPruuQMFDQLVZar56a5+nVFlWmd6GTAjQHgowlAmOj1UmaJPl1q5R
	 VO3akEklZreeGd231uJPEFderJp2JAe0Vu8jWfseVmlU4WPvjVgYp6O28qnydDkATy
	 mnAisa6Cr5Tdbmo484zIv2CJLb7lDoreS3tCt6YufQvNtG2rk6IqqCTkWIxfG3RfAl
	 BbC0X49iMIS+Mqq4h7Ld729fjfM/oPd7UdyMKZ+P+osifL6OmNYOSxOQaMLO81qxbN
	 juwX5R4KBZzww==
Date: Fri, 30 May 2025 18:48:54 -0700 (PDT)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alejandro Vallejo 
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    "Daniel P. Smith" 
Subject: Re: [PATCH 16/19] xen/dt: Extract helper to map nodes to module
 kinds
In-Reply-To: <20250530120242.39398-17-agarciav@amd.com>
Message-ID: 
References:  <20250530120242.39398-1-agarciav@amd.com> <20250530120242.39398-17-agarciav@amd.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 30 May 2025, Alejandro Vallejo wrote:
> This will be required later by x86 code in order to do early identification
> of boot modules when booting off a DTB.
> 
> Not a functional change.
> 
> Signed-off-by: Alejandro Vallejo 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/common/device-tree/bootfdt.c      | 16 ++++++++++++++++
>  xen/common/device-tree/bootinfo-fdt.c | 14 +-------------
>  xen/include/xen/bootfdt.h             |  7 +++++++
>  3 files changed, 24 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
> index 5decf17faf..2dda7a9d19 100644
> --- a/xen/common/device-tree/bootfdt.c
> +++ b/xen/common/device-tree/bootfdt.c
> @@ -4,6 +4,22 @@
>  #include 
>  #include 
>  
> +bootmodule_kind __init fdt_node_to_kind(const void *fdt, int node)
> +{
> +    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
> +         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
> +        return BOOTMOD_KERNEL;
> +    if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
> +         fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
> +        return BOOTMOD_RAMDISK;
> +    if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
> +        return BOOTMOD_XSM;
> +    if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
> +        return BOOTMOD_GUEST_DTB;
> +
> +    return BOOTMOD_UNKNOWN;
> +}
> +
>  uint32_t __init device_tree_get_u32(const void *fdt, int node,
>                                      const char *prop_name, uint32_t dflt)
>  {
> diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
> index 736f877616..dc399bbf61 100644
> --- a/xen/common/device-tree/bootinfo-fdt.c
> +++ b/xen/common/device-tree/bootinfo-fdt.c
> @@ -239,19 +239,7 @@ static void __init process_multiboot_node(const void *fdt, int node,
>  
>      cell = (const __be32 *)prop->data;
>      device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
> -
> -    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
> -         fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
> -        kind = BOOTMOD_KERNEL;
> -    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0 ||
> -              fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
> -        kind = BOOTMOD_RAMDISK;
> -    else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
> -        kind = BOOTMOD_XSM;
> -    else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 0 )
> -        kind = BOOTMOD_GUEST_DTB;
> -    else
> -        kind = BOOTMOD_UNKNOWN;
> +    kind = fdt_node_to_kind(fdt, node);
>  
>      /**
>       * Guess the kind of these first two unknowns respectively:
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 766956e102..7bc6209986 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -102,4 +102,11 @@ uint32_t device_tree_get_u32(const void *fdt, int node,
>  void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
>                           uint32_t size_cells, paddr_t *start, paddr_t *size);
>  
> +/*
> + * Probe an FDT node thought to be a boot module to identify its kind.
> + *
> + * If correctly identified, returns the detected kind, otherwise BOOTMOD_UNKNOWN
> + */
> +bootmodule_kind fdt_node_to_kind(const void *fdt, int node);
> +
>  #endif /* XEN_BOOTFDT_H */
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Sat May 31 07:47:25 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 07:47:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001945.1382022 (Exim 4.92)
	(envelope-from )
	id 1uLGvx-0005aT-Fk; Sat, 31 May 2025 07:47:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001945.1382022; Sat, 31 May 2025 07:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uLGvx-0005aM-Bu; Sat, 31 May 2025 07:47:13 +0000
Received: by outflank-mailman (input) for mailman id 1001945;
 Sat, 31 May 2025 07:47:11 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from )
 id 1uLGvv-0005aG-KB
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 07:47:11 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 747c4f48-3df3-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 09:47:09 +0200 (CEST)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 5C5F25C3D84;
 Sat, 31 May 2025 07:44:50 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EEAB7C4CEE3;
 Sat, 31 May 2025 07: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" 
X-Inumbo-ID: 747c4f48-3df3-11f0-a300-13f23c93f187
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1748677627;
	bh=sT8ax5dbTHlITwDR7EB59IJncQ2gJREmL936Z5hIaHo=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=m4l+/YKIs/KGay8y5vMJQ2bX/6i3fxjZ0gJ0+6SfB85gTMv9isMoswQqVsv4Dm+Yl
	 5gBNStHJ++v6+O0EtdOWObMpAyqqJtKiiiHCvqbrRYRGbqgk54Gsoto2+2xSaTGEX/
	 UjUmkcVswzLe8hErYSg4k60I8QKcdT/ikfO8I1+QYom9bCQCk6Jq/eiD5Mj9Y39hlp
	 sAiyJS/N7snMk3XQ2/Bvj/0wr0qADR+cJOCyKzCUqM5WQ0/2ASiXFMHCRpT2zrg06m
	 ciDBHHpS087W/LZIa9rTY4pgSp3axMokcqCHGPjdvNd0LKzornyQw2tVBbwFtOMgVG
	 zRx/WnEiPnYpA==
Date: Sat, 31 May 2025 10:46:52 +0300
From: Mike Rapoport 
To: Ryan Roberts 
Cc: Lorenzo Stoakes ,
	Catalin Marinas ,
	Will Deacon ,
	Madhavan Srinivasan ,
	Michael Ellerman ,
	Nicholas Piggin ,
	Christophe Leroy ,
	"David S. Miller" ,
	Andreas Larsson ,
	Juergen Gross ,
	Ajay Kaher ,
	Alexey Makhalov ,
	Thomas Gleixner ,
	Ingo Molnar , Borislav Petkov ,
	Dave Hansen ,
	"H. Peter Anvin" ,
	Boris Ostrovsky ,
	"Aneesh Kumar K.V" ,
	Andrew Morton ,
	Peter Zijlstra ,
	Arnd Bergmann , David Hildenbrand ,
	"Liam R. Howlett" ,
	Vlastimil Babka ,
	Suren Baghdasaryan ,
	Michal Hocko , Alexei Starovoitov ,
	Andrey Ryabinin ,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
	virtualization@lists.linux.dev, xen-devel@lists.xenproject.org,
	linux-mm@kvack.org, Jann Horn 
Subject: Re: [RFC PATCH v1 0/6] Lazy mmu mode fixes and improvements
Message-ID: 
References: <20250530140446.2387131-1-ryan.roberts@arm.com>
 <5b5d6352-9018-4658-b8fe-6eadaad46881@lucifer.local>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

Hi Ryan,

On Fri, May 30, 2025 at 04:55:36PM +0100, Ryan Roberts wrote:
> On 30/05/2025 15:47, Lorenzo Stoakes wrote:
> > +cc Jann who is a specialist in all things page table-y and especially scary
> > edge cases :)
> > 
> > On Fri, May 30, 2025 at 03:04:38PM +0100, Ryan Roberts wrote:
> >> Hi All,
> >>
> >> I recently added support for lazy mmu mode on arm64. The series is now in
> >> Linus's tree so should be in v6.16-rc1. But during testing in linux-next we
> >> found some ugly corners (unexpected nesting). I was able to fix those issues by
> >> making the arm64 implementation more permissive (like the other arches). But
> >> this is quite fragile IMHO. So I'd rather fix the root cause and ensure that
> >> lazy mmu mode never nests, and more importantly, that code never makes pgtable
> >> modifications expecting them to be immediate, not knowing that it's actually in
> >> lazy mmu mode so the changes get deferred.
> > 
> > When you say fragile, are you confident it _works_ but perhaps not quite as well
> > as you want? Or are you concerned this might be broken upstream in any way?
> 
> I'm confident that it _works_ for arm64 as it is, upstream. But if Dev's series
> were to go in _without_ the lazy_mmu bracketting in some manner, then it would
> be broken if the config includes CONFIG_DEBUG_PAGEALLOC.
> 
> There's a lot more explanation in the later patches as to how it can be broken,
> but for arm64, the situation is currently like this, because our implementation
> of __change_memory_common() uses apply_to_page_range() which implicitly starts
> an inner lazy_mmu_mode. We enter multiple times, but we exit one the first call
> to exit. Everything works correctly but it's not optimal because C is no longer
> deferred:
> 
> arch_enter_lazy_mmu_mode()                        << outer lazy mmu region
>   
>   alloc_pages()
>     debug_pagealloc_map_pages()
>       __kernel_map_pages()
>         __change_memory_common()
>           arch_enter_lazy_mmu_mode()              << inner lazy mmu region
>             
>           arch_leave_lazy_mmu_mode()              << exit; complete A + B
>     clear_page()
>                     << no longer in lazy mode
> arch_leave_lazy_mmu_mode()                        << nop
> 
> An alternative implementation would not add the nested lazy mmu mode, so we end
> up with this:
> 
> arch_enter_lazy_mmu_mode()                        << outer lazy mmu region
>   
>   alloc_pages()
>     debug_pagealloc_map_pages()
>       __kernel_map_pages()
>         __change_memory_common()
>              << deferred due to lazy mmu
>     clear_page()                                  << BANG! B has not be actioned
>   
> arch_leave_lazy_mmu_mode()
> 
> This is clearly a much worse outcome. It's not happening today but it could in
> future. That's why I'm claiming it's fragile. It's much better (IMHO) to
> disallow calling the page allocator when in lazy mmu mode.

First, I think it should be handled completely inside arch/arm64. Page
allocation worked on lazy mmu mode on other architectures, no reason it
should be changed because of the way arm64 implements lazy mmu.

Second, DEBUG_PAGEALLOC already implies that performance is bad, for it to
be useful the kernel should be mapped with base pages and there's map/unmap
for every page allocation so optimizing a few pte changes (C in your
example) won't matter much.

If there's a potential correctness issue with Dev's patches, it should be
dealt with as a part of those patches with the necessary updates of how
lazy mmu is implemented on arm64 and used in pageattr.c.

And it seems to me that adding something along the lines below to
__kernel_map_pages() would solve DEBUG_PAGEALLOC issue:

void __kernel_map_pages(struct page *page, int numpages, int enable)
{
	unsigned long flags;
	bool lazy_mmu = false;

	if (!can_set_direct_map())
		return;

	flags = read_thread_flags();
	if (flags & BIT(TIF_LAZY_MMU))
		lazy_mmu = true;

	set_memory_valid((unsigned long)page_address(page), numpages, enable);

	if (lazy_mmu)
		set_thread_flag(TIF_LAZY_MMU);
}

> Thanks,
> Ryan

-- 
Sincerely yours,
Mike.


From xen-devel-bounces@lists.xenproject.org Sat May 31 10:16:43 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 10:16:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1001975.1382032 (Exim 4.92)
	(envelope-from )
	id 1uLJGO-0007Ho-Sx; Sat, 31 May 2025 10:16:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1001975.1382032; Sat, 31 May 2025 10:16: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 1uLJGO-0007Hg-OL; Sat, 31 May 2025 10:16:28 +0000
Received: by outflank-mailman (input) for mailman id 1001975;
 Sat, 31 May 2025 10:16:27 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLJGN-0007Ha-8U
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 10:16:27 +0000
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
 [2a00:1450:4864:20::136])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4e4e0b51-3e08-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 12:16:24 +0200 (CEST)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-55320ddb9edso3224097e87.1
 for ; Sat, 31 May 2025 03:16: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" 
X-Inumbo-ID: 4e4e0b51-3e08-11f0-b894-0df219b8e170
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748686584; x=1749291384; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JyKUNC7AK24oaZ+BV2NsptKAVrues0MRs6gF4p/xnLE=;
        b=BZfxCXnx6ZsCnpSeSNQZOj03y3/pQAp7GCISnrRMPq3Pvptk3DWazmvzQYgBf9ti2/
         B/fXq92sQ0eYTh9CMh98KYrj4dcCnyzBH0nqV9PgHBjZuGtWlj2SWKOXalgOKE9BXPSk
         0c63Q8b8eEnWWLyLSyntby4OgdA/uYm9oIV4qV+qehOkKRlCNWjTjMhweRS83LFAeFn3
         kcgvCBE4+pNz9o5Weu457SLac0FxM3MstfEJHD0LVs6QciV16Tk9cJg9qnqFugAoemWF
         DjJFv0TI4OoZ/niJXknGkpT10BLTZ2Y6jHdWfN+bUJKBcPYk/NXiwi3YNehDio0saY0D
         8V8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748686584; x=1749291384;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=JyKUNC7AK24oaZ+BV2NsptKAVrues0MRs6gF4p/xnLE=;
        b=pEv1CqJDYrVTQK9O15Xt7k8sHcz8CLQPurwGFmza3yJmKUjYA5Ws0bR1oBQImkMtOK
         igMUnFqJnXLOBH+gBrDeuzxNiqZlNyqmAQv0p88hT+ObXRYVPAD4vuNlhSlUPqYi3XwA
         O2NnEgcrz4Q/CNmGJN2QJfFqoZ2JYoG9byrlvXfnFlRJwT5FR0mcyLh4e4V8x2PMUbjV
         Qr77vC26GylcL+C7fg7NQD1oU1ZuBscU3sKVLVweIVp0AvMe3PIjxh9T96Faq6sZXNE8
         at/K8heseRMXxbw+igwq11ZRLJ73J1h4kP7xeESUfnPlhj8WWbMHjhxg7iByR+VZZW/l
         OMgg==
X-Gm-Message-State: AOJu0Yx2CVjQSub1xjp5cXUsfFM1KD8yZH/m5QHpXz3KHtXpyQpBMUEJ
	9e+PODmcsR09DUYpXr1y4arzaAc0giReUwBGZMU7zsnmCGccCQcm9VAvLcMZRnwLJ4AXqFftYAV
	JZJLuFP5/VkQlQn52xwz0AELR/8DiSZM=
X-Gm-Gg: ASbGncvpPMHeQnKJtuWsdsZ4fqs/1oZfxokdQ8L3Xo4gmVli0JWpN+ToaL0CeMUBBSX
	xZv4MhvB/yTrRQzBtxsij0cpQxA/9V9dS0gl/FYs3JlQDfNU/ubMXPj9yUkqEd2j8uSX9Y+2KMX
	XPddRB8nv54mPhbc9o4qpcTDNCXCfIL9Rze51+CP0tyw==
X-Google-Smtp-Source: AGHT+IEevdzFZeolsTSfVgKK9KJyEGX7hFTGd+9eNu/Wz0UfbvRU/o9l4OOMV+f1QuRif6scF+fZousHhlepAbJVgKA=
X-Received: by 2002:a05:6512:2215:b0:553:3127:b00 with SMTP id
 2adb3069b0e04-5533b90b7d6mr2666005e87.32.1748686583420; Sat, 31 May 2025
 03:16:23 -0700 (PDT)
MIME-Version: 1.0
References:  <2ef15cb605f987eb087c5496d123c47c01cc0ae7.1741164138.git.xakep.amatop@gmail.com>
 <1bcdca51-0f31-421c-81cf-699a1b94fbd6@xen.org>
In-Reply-To: <1bcdca51-0f31-421c-81cf-699a1b94fbd6@xen.org>
From: Mykola Kvach 
Date: Sat, 31 May 2025 13:16:12 +0300
X-Gm-Features: AX0GCFu8asraicDdTvBG9bNs1w7xSxIyKJDtrCvwfe4noIAXovQahDTFuH1R5Qc
Message-ID: 
Subject: Re: [PATCH 14/16] xen/arm: Resume memory management on Xen resume
To: Julien Grall 
Cc: xen-devel@lists.xenproject.org, 
	Mirela Simonovic , Stefano Stabellini , 
	Bertrand Marquis , Michal Orzel , 
	Volodymyr Babchuk , Saeed Nowshadi , 
	Mykyta Poturai , Mykola Kvach 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, @Julien Grall

On Wed, Mar 12, 2025 at 1:04=E2=80=AFAM Julien Grall  wrote=
:
>
> Hi,
>
> On 05/03/2025 09:11, Mykola Kvach wrote:
> > From: Mirela Simonovic 
> >
> > The MMU needs to be enabled in the resume flow before the context
> > can be restored (we need to be able to access the context data by
> > virtual address in order to restore it). The configuration of system
> > registers prior to branching to the routine that sets up the page
> > tables is copied from xen/arch/arm/arm64/head.S.
> > After the MMU is enabled, the content of TTBR0_EL2 is changed to
> > point to init_ttbr (page tables used at runtime).
> >
> > At boot the init_ttbr variable is updated when a secondary CPU is
> > hotplugged. In the scenario where there is only one physical CPU in
> > the system, the init_ttbr would not be initialized for the use in
> > resume flow. To get the variable initialized in all scenarios in this
> > patch we add that the boot CPU updates init_ttbr after it sets the
> > page tables for runtime.
> >
> > Signed-off-by: Mirela Simonovic 
> > Signed-off-by: Saeed Nowshadi 
> > Signed-off-by: Mykyta Poturai 
> > Signed-off-by: Mykola Kvach 
> > ---
> > Changes in V3:
> > - updated commit message
> > - instead of using create_page_tables, enable_mmu, and mmu_init_seconda=
ry_cpu,
> >    the existing function enable_secondary_cpu_mm is now used
> > - prepare_secondary_mm (previously init_secondary_pagetables in the pre=
vious
> >    patch series) is now called at the end of start_xen instead of
> >    setup_pagetables. Calling it in the previous location caused a crash
> > - add early printk init during resume
> >
> > Changes in V2:
> > - moved hyp_resume to head.S to place it near the rest of the start cod=
e
> > - simplified the code in hyp_resume by using existing functions such as
> >    check_cpu_mode, cpu_init, create_page_tables, and enable_mmu
> > ---
> >   xen/arch/arm/arm64/head.S | 23 +++++++++++++++++++++++
> >   xen/arch/arm/setup.c      |  8 ++++++++
> >   2 files changed, 31 insertions(+)
> >
> > diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> > index 3522c497c5..fab2812e54 100644
> > --- a/xen/arch/arm/arm64/head.S
> > +++ b/xen/arch/arm/arm64/head.S
> > @@ -564,6 +564,29 @@ END(efi_xen_start)
> >   #ifdef CONFIG_SYSTEM_SUSPEND
> >
> >   FUNC(hyp_resume)
> > +        msr   DAIFSet, 0xf           /* Disable all interrupts */
>
> Surely we should be here with interrupts disabled. No?

You are right, I overlooked this and left the code unchanged from a
previous patch series.
According to the Power State Coordination Interface (DEN0022F.b 1.3):
```
6.4.3.3 Exceptions
The appropriate asynchronous exception masks must be set when starting
up the core at the Exception
level from which the call was made, or at ELns. Typically, this means
that for the Exception level where
execution is restarting:

If starting in AArch64 state, the SPSR_ELx.{D,A,I,F} bits must be set
to {1, 1, 1, 1}. ELx is the
Exception level being returned from.
```

The ARM Trusted Firmware code enforces this correctly here:
https://elixir.bootlin.com/arm-trusted-firmware/v2.13.0/source/lib/psci/psc=
i_common.c#L869

So, the code should indeed expect DAIF bits to be set on resume. I
will update the patch accordingly.

>
> > +
> > +        tlbi  alle2
> > +        dsb   sy                     /* Ensure completion of TLB flush=
 */
>
> This doesn't exist when booting Xen and I am not sure why we would need
> it for resume as we already nuke the TLbs in enable_mmu. Can you clarify?

You're absolutely right =E2=80=94 that line is a leftover from earlier chan=
ges
when the memory handling logic was being reorganized.
It's no longer necessary because enable_mmu already handles TLB
invalidation, including the TLBI and DSB instructions.
I'll remove it in the next version. Thanks for catching this!

>
> > +        isb
> > +
> > +        ldr   x0, =3Dstart
> > +        adr   x19, start             /* x19 :=3D paddr (start) */
> > +        sub   x20, x19, x0           /* x20 :=3D phys-offset */
>
> Looking at the code, I wonder if it is still necessary to set x19 and
> x20 for booting secondary CPUs and resume. There doesn't seem to be any
> use of the registers.

x20 is still required during resume. It's used inside
enable_secondary_cpu_mm via the load_paddr macro.
So although x19 may no longer be necessary in this context, x20 is
still used and needs to be set beforehand.

>
> > +
> > +        /* 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   lr, =3Dmmu_resumed
> > +        b     enable_secondary_cpu_mm
> > +
> > +mmu_resumed:
> >           b .
> >   END(hyp_resume)
> >
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index ffcae900d7..3a89ac436b 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -508,6 +508,14 @@ void asmlinkage __init start_xen(unsigned long fdt=
_paddr)
> >       for_each_domain( d )
> >           domain_unpause_by_systemcontroller(d);
> >
> > +#ifdef CONFIG_SYSTEM_SUSPEND
> > +    /*
> > +     * It is called to initialize init_ttbr.
> > +     * Without this call, Xen gets stuck after resuming.
>
> This is not a very descriptive comment. But, you seem to make the
> assumption that prepare_secondary_mm() can be called on the boot CPU.
> This is not always the case. For instance on arm32, it will allocate
> memory and overwrite the per-cpu page-tables pointer (not great). This
> will also soon be the case for arm64.
>
> Furthermore, this call reminded me that the secondary CPU page-tables
> are not freed when turning off a CPU. So they will leak. Not yet a
> problem for arm64 though.
>
> So overall, I think we need a separate function that will be prepare
> init_ttbr for a given CPU (not allocate any memory). This will then need
> to be called from the suspend helper.

Thank you for the detailed explanation.

I will rework this part to avoid calling prepare_secondary_mm() on
the boot CPU. As suggested, I plan to introduce a dedicated helper
function that will only initialize init_ttbr without allocating
memory and call it  from the suspend helper.

>
> > +     */
>  > +    prepare_secondary_mm(0);> +#endif
> > +
> >       /* Switch on to the dynamically allocated stack for the idle vcpu
> >        * since the static one we're running on is about to be freed. */
> >       memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(),
>
> Cheers,
>
> --
> Julien Grall
>

Thank you for reviewing this patch series.

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Sat May 31 12:54:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 12:54:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1002020.1382041 (Exim 4.92)
	(envelope-from )
	id 1uLLjC-0008Ih-Ug; Sat, 31 May 2025 12:54:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1002020.1382041; Sat, 31 May 2025 12:54:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uLLjC-0008Ia-S6; Sat, 31 May 2025 12:54:22 +0000
Received: by outflank-mailman (input) for mailman id 1002020;
 Sat, 31 May 2025 12:54:22 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLLjB-0008IU-CE
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 12:54:22 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20619.outbound.protection.outlook.com
 [2a01:111:f403:2416::619])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5d14deaf-3e1e-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 14:54:19 +0200 (CEST)
Received: from BN7PR02CA0032.namprd02.prod.outlook.com (2603:10b6:408:20::45)
 by PH8PR12MB7280.namprd12.prod.outlook.com (2603:10b6:510:220::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.27; Sat, 31 May
 2025 12:54:13 +0000
Received: from BN2PEPF000044A2.namprd02.prod.outlook.com
 (2603:10b6:408:20:cafe::66) by BN7PR02CA0032.outlook.office365.com
 (2603:10b6:408:20::45) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Sat,
 31 May 2025 12:54:13 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF000044A2.mail.protection.outlook.com (10.167.243.153) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Sat, 31 May 2025 12:54:12 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 31 May
 2025 07:54:11 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 31 May
 2025 07:54:11 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Sat, 31 May 2025 07:54: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" 
X-Inumbo-ID: 5d14deaf-3e1e-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ntq6QnSGaM1rh7z44O2dvulKcTpdCPSm61npkA3cA4wixPvoI9Nc4TvHhquEqcU3VT3p00aetp+sPK9QaPxiIe4f9HqZNKEefAngW2JK9EqYOa+dgCb8nlvDPDikGVlUxD/YUXD6YXYJV/8zaBfkIbQeiDooS3BAdjUxdxVrOVwVtTblMqaKvJaVLDIJplMo8SdGuXW4XuV0LA97Ru5IixqcP5h+JCB6AJCAEzhbondQTLCdqcQyBcm+D4SD49UTwHR6XcrdPaSH76GMcSSXLXQIaG1op8L7vhfGfsr+Ix5HuOCKl4Hio7S5NYMgENp8eh/UwvQGKSvEb/YuJ6cm/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=PFy7btpEmF4KXga9FWdbj+/uivjqM8/1W1b/KcQpMbk=;
 b=VxoRf778zj10/PbcSgXLjBjB7K1ghLAE1VLkRSgs++eaR84+B5GAAS2SUWunQCnOcelutIeMqd7/pxbRhz3eqVmtXtOuZh0tP2cfPDk4uqXwqqgfWKx9ud83NnT7bWh/IgVkcxAIQvFlbSR5qnbHFqcbXXFCqxRXiFrNkHmrNjApwxZkO5/weWH/mFQ1/gTIPWnmWhZhPJPBwFWYGAaZc1PlN9tv/2w7ozOtxL46h6RUa52jhKZ+dNPRJH+lICf9JGdPf8Kdwtod7I7THsyw7opoiVrR/Ai/MfCNe5gNw1Ip7I61Yp5ZTGSGK9l1K7OAGMq1NAnjxswDOC3LiFlmIw==
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=PFy7btpEmF4KXga9FWdbj+/uivjqM8/1W1b/KcQpMbk=;
 b=V72TKCCiS9kU0aZ+24VNeSaG9kC7gw8bRM4XNFiFxBMXCiSKNLk06JKHNfyO+eBWvrnIZAxAlHvvMQbR+1XhNTqdRAZB3WH5HriOtuoYUvIazEDGoyNm5SdnOZZ2M4gQqH7PB7SW06neIFEtufP6JZsgClwjHGNkEwsTjNVE0ok=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v1 0/5] vpci: allow 32-bit BAR writes with memory decoding enabled
Date: Sat, 31 May 2025 08:53:58 -0400
Message-ID: <20250531125405.268984-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB05.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A2:EE_|PH8PR12MB7280:EE_
X-MS-Office365-Filtering-Correlation-Id: 7e78f709-61bb-414f-dd6d-08dda0423dc0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?+zTDH5gdhuQ2hVhfuh92CX6Q5ILWn3QnITslN8JyFa7hAeZBGC9v/zbHFVm8?=
 =?us-ascii?Q?hpRSvrYAuEc0EgOuMche2TnkoGZHGOkvB6lwkTczESLBKHlZjgCwr/FGbgWw?=
 =?us-ascii?Q?+Q7DoXDkIVCZp5PN2LjDwavOr8Bj/ODbM2oNzGdaQuBYqIxAQcqmFfEJ2cSQ?=
 =?us-ascii?Q?kWpvhsRBvVAQzNKdciDrA4obE+2NyxoQZ1KPi1xlyT0aCZCupL5ttbYkIor9?=
 =?us-ascii?Q?hjFjlHS7va0I9jYUJdPVO++0HpC9Qlo/GtzRZvjJmRHaD4myo8Mm+yFR459e?=
 =?us-ascii?Q?tYpcfOeoRwsx5UmKydtidMkufmS+KM+SpctW0YYn4KnFDzKgn3T9OeSFWCbR?=
 =?us-ascii?Q?T85duIl6zl6+d2AALSEl1TVDopjjM5hNkpgAmuQkmclZiTItbyaSrm6gwbxG?=
 =?us-ascii?Q?FciaIkYVRroxZ/h7O31hKZkSbDPDOixr4q3w4Or8c4Dn5RR8KP/n834jXuE2?=
 =?us-ascii?Q?UqnqtR9pMYmPJdwliSm+hMnd9O35tRsJMWzK6LJJSki/uqpEkOxJQF9fK3Zc?=
 =?us-ascii?Q?qKZxJUtgPZfMIdmxxbNCjJPHkGYQKucoXVYvyyiM818nkj9PJM1p0rYJHOeo?=
 =?us-ascii?Q?nsX1QpiCjAfu9heeINGSdtV3pUaV/75rru/6Zn7RLNTV9auZRGXCLh2QduUU?=
 =?us-ascii?Q?kZv6uJ+MyRQFm4cAedB/lacWZUXtpMeBYtoftEximhUGK89nOb9eGSi34iPb?=
 =?us-ascii?Q?dri2ua2ZeN/795PMCsp7tHaOw/E3bTrMDj2TUxXKXgSRC1TwEBA2aousnAwM?=
 =?us-ascii?Q?fHloQ7O9xca5DvbnIDXR0YT69ygU8zNOtr06q4MC5NeW1qxtNr7C3kheE8GT?=
 =?us-ascii?Q?tAkmwAHYrakhDmRrLytgV8F8vuuMcCjU7RYbjlKnLk2MvlTAcLyQB5vlUbGE?=
 =?us-ascii?Q?R61vnKJwEIIloeVu5MfUx24wUSpteeX5QdVmgCS5u+PAjL/tapB9hHap4fOO?=
 =?us-ascii?Q?k3gYGuScCBAiMjShoJrtf4zxDwRdxAlmC5LJG0eX8MAMYunyWrbYWG1p+jjm?=
 =?us-ascii?Q?pSadzv423GuPEAG3qHyM+2yBqRNTlm/FDz2vkLCKpi8DiEAr2D3sizux8p9S?=
 =?us-ascii?Q?9cSRXV1qsNXK0mK0ZxCIlpH7gF+C03MJMWoUumQya8B86n2c7wqeeGKSLz8Z?=
 =?us-ascii?Q?8NP4s1qudb+AIIIsFtGRX+ymf1hdLwNgrdxXcSmXHcWr0tf/1yIBO8k7ttyU?=
 =?us-ascii?Q?Q9+jwANEvgPOu9CVltRTcndMPBcfX7eBRDmzu/X6Mj0lcQnh1F9cAjJ3tWun?=
 =?us-ascii?Q?mGiy0eE6ClW5h/rMUvdUfFlJ7a/tQ56GStIY07StDAt/sJxJmbdQd5AFwOZ1?=
 =?us-ascii?Q?S0X8MxkrRC1k76thpLkXlq93SQws37p24qTV23A7MSFt6w4JsA9A8I6N8RoJ?=
 =?us-ascii?Q?KN+NauASzF2yQkekC3sViWB5Ws/2XiNe7VSP2P8o132DLAXYyAuNmg7wabOd?=
 =?us-ascii?Q?SWE+2LArtqFCcgLHtla6+cl3Q7wdqpA6Fe9Tpwrb+y3I2ix7WconVA=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2025 12:54:12.0393
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e78f709-61bb-414f-dd6d-08dda0423dc0
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A2.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7280

Pipeline: https://gitlab.com/xen-project/people/stewarthildebrand/xen/-/pipelines/1845628953

RFC->v1:
* rework BAR mapping machinery to support unmap-then-map operation

RFC: https://lore.kernel.org/xen-devel/20250312195019.382926-1-stewart.hildebrand@amd.com/T/#t

Stewart Hildebrand (5):
  vpci: const-ify some pdev instances
  vpci: rework error path in vpci_process_pending()
  vpci: introduce map_bars()
  vpci: use separate rangeset for BAR unmapping
  vpci: allow 32-bit BAR writes with memory decoding enabled

 xen/drivers/vpci/header.c | 220 ++++++++++++++++++++++++++------------
 xen/drivers/vpci/vpci.c   |   5 +-
 xen/include/xen/vpci.h    |  10 +-
 3 files changed, 162 insertions(+), 73 deletions(-)


base-commit: 96a587a057363e519ca74498882fac42d72670b6
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Sat May 31 12:54:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 12:54:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1002022.1382061 (Exim 4.92)
	(envelope-from )
	id 1uLLjJ-0000M1-DO; Sat, 31 May 2025 12:54:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1002022.1382061; Sat, 31 May 2025 12:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uLLjJ-0000Lu-A5; Sat, 31 May 2025 12:54:29 +0000
Received: by outflank-mailman (input) for mailman id 1002022;
 Sat, 31 May 2025 12:54:28 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLLjI-0008IU-Hz
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 12:54:28 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20624.outbound.protection.outlook.com
 [2a01:111:f403:2009::624])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 62ff30bd-3e1e-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 14:54:28 +0200 (CEST)
Received: from IA4P220CA0007.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:558::16)
 by LV8PR12MB9450.namprd12.prod.outlook.com (2603:10b6:408:202::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Sat, 31 May
 2025 12:54:23 +0000
Received: from BN2PEPF0000449D.namprd02.prod.outlook.com
 (2603:10b6:208:558:cafe::64) by IA4P220CA0007.outlook.office365.com
 (2603:10b6:208:558::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.24 via Frontend Transport; Sat,
 31 May 2025 12:54:23 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF0000449D.mail.protection.outlook.com (10.167.243.148) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Sat, 31 May 2025 12:54:23 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 31 May
 2025 07:54:23 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 31 May
 2025 07:54:23 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Sat, 31 May 2025 07:54:22 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 62ff30bd-3e1e-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FUhzN+wz0ovtTrnBQ+5mfuY7chuuuCQ/muoDHMvqNDEpAA4CBuUkyjkvb+s+Oyl6hQEiro0TPeHNlI6n+aaQ+NiZJnlHQL52r745pCvq3fbi/w+dhnErzBmMpW+Twotrq2H20jMrH/42V1UYbJD4iWmirRDn8ZPK2EOT4V0gzqs2RBd20k8QO0Kxry3zCE7xwgE6KN91Ej3XrsThXPsC2W2A7bzJc/4d6eM4e6YNqMAKHee1YTCq44llRU/quMUkqIuAlEkUtA1elAfvaPeDkClmLLwzzTyErHgH0NjAeHvTf+5MIAkrs9545kyNuAoiE5KSFK7HIY937BC8z+L5NA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1kR/ClfUZKKqigCC70/OsoHrcl2UsMV2lP7p0tn/BBM=;
 b=xvPkgbzWWh+QcoPrXV0Ez7ZIhrgM1koP6Oph7ZSpId5WgiMlCuqSsCFlzzrNAPrvaFaSm9S1F3w5nndgQRXz8qjtL+GIOmeue2mrI/ipMFeazJrniPt2zYEc8mg4MIYJKyqd4dOghvho3Yqq2GKa5clCVEKLFoUzZt6eUqi0M3KRIWSm7hD/K3Xv4W1yfKvnFx9BqGYOXRwqUt+V1dQlMnvruBroxwMcEYO4PnG80oXGEIF8foM0gpGq4fO9S40W/lEbZG5xUZhSwj50jWf6aFhLQonFHMT3lBVnxhueVPBv0HFMjvkevCriLKv5FU9N0p9NZgReB3o47zCCyxRL4g==
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=1kR/ClfUZKKqigCC70/OsoHrcl2UsMV2lP7p0tn/BBM=;
 b=wKkYa7iUCCwc8B9VRbTPiqA0w4T6cm9VJtFALxnH70ExV0ByIQPXPKuHUBIx5piWSOjtApaShU2NBY4qLLK16dR4g+6tN2wLzcT8WrWtXdkLjd4QK+q4eztHAjAYt3hGIUL3bHG2Lp17BZr6nxxaCxI2XVRSWHE2IJvGrwkbf4k=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v1 2/5] vpci: rework error path in vpci_process_pending()
Date: Sat, 31 May 2025 08:54:00 -0400
Message-ID: <20250531125405.268984-3-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250531125405.268984-1-stewart.hildebrand@amd.com>
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF0000449D:EE_|LV8PR12MB9450:EE_
X-MS-Office365-Filtering-Correlation-Id: d72a5853-d0b2-4d4e-6e3e-08dda04244c4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Etmck4gWNJYdRJqnjTafhmPKZqVkEUM93Ym84Fe3eajlaq8Ay5LkCCRPTgsO?=
 =?us-ascii?Q?NGVBrvPNePeaObW9Ws4Iis1NvuRY3avdP4bbk6hRUdq0sMnUPVHn7JYD0v+k?=
 =?us-ascii?Q?uGQ0X5GoffwKu62rL6OIPjRKmm6613Tr2IG1wCo1LTCekFjlgMh7KwWqzxFI?=
 =?us-ascii?Q?4FwcfzMPzfAihX/PoR4Ip1rJf0wZKxys+VtTBRFRzEFwTXCM8lG2muN0pWjz?=
 =?us-ascii?Q?3MZnYSDyGNPAV5XC/HHFun/8pbeCO/DVJ7eCkpXqYIAiNmxAh3QHcQimwFVx?=
 =?us-ascii?Q?aTcs2cgFCClIC33kItqohLPSXNC0DDGBjni0PjaBLhA17nVp50w73P1Vz0H/?=
 =?us-ascii?Q?/7Ig3rF5RZVRbWfFbE7fTpGe6raND9rKA4uvGRP9itCX7IiIGNHMgUTNZYd5?=
 =?us-ascii?Q?+2qJy8gx+rWYMNy9BqkcSLJotkrvKYyLgSEq+JuhO+bg+N8hPnRQNU0jRO14?=
 =?us-ascii?Q?8pNwtzThxUwnUmGgXmQw2C2PrxvO1rBcgN2zewu4yQsffNBoPmoGDBatlPgE?=
 =?us-ascii?Q?MoAJ8ebu5737ZTWv8cHUcXNjR1jfyCpRTBr/lHc6Ag2Ob/32JuqzPr2iVtny?=
 =?us-ascii?Q?+cpDqSSRkK0XwmWlsnJ7sX02g1nfs+lTbUcR86OOH+Jc2WAwAx+88TLo9YH1?=
 =?us-ascii?Q?lJAtXAeNWdKM8aPNL9VpK68fDJmofNT3N1FEPa0NE7InVKpYmoGq7U40299L?=
 =?us-ascii?Q?LvFX69cyGyulXanbOCUMBRcsHRlTWXXrHBpQ+V5JA/ltYAKjiQH+9jxqb7XM?=
 =?us-ascii?Q?VNshhzemePOtirXhqs8/15KIuI9Bh/8wsaAGYrsiH9gwHAnAZQQrW9FY9KgV?=
 =?us-ascii?Q?ChobUth+s08lqlG9Rs6JeE5sJGCOvoxThDi7XvXba7wl14E8bNJ1KZ65Q9NE?=
 =?us-ascii?Q?0hqZzoAPPfrMnccnbepP5woPLDNjcicy0ly0klkXJQFMeuXnQwnmfcIujOuK?=
 =?us-ascii?Q?OVwZUyYEPRSnF0OrHUTyMjuLUayUHF30trCfuZw7wFmyTsJIg/oRxOXAq6wM?=
 =?us-ascii?Q?gS7hNhFCkfrK9+Rr5BRw/5CzqgrsfL/kncdp8FlIjHzAbHrFYmld8G3i2lXr?=
 =?us-ascii?Q?9EfBCMziIAip49JnU9YYiSlHCpfMgrSiT9BHmqLsUxGLl9S4HyyYlqBhjfNz?=
 =?us-ascii?Q?k7XpIejg7F/78ypWtvv1rp7pzyqTJwkp0iGfyI+qEJYNMe3zG3w8rIj2Qx1G?=
 =?us-ascii?Q?Zzc4i5jVROWuTOkttojJJW7QPE7XNkmNHvMI+V1qRr40dmR4i5pjyzJBD2Le?=
 =?us-ascii?Q?C7y99BZPSTY68r36/8LGHv1ScULfW2rFTYbzVBU14No5q7pg9AOmASHikttS?=
 =?us-ascii?Q?cpYoNzvMkkaGIEUX7MwWg5Gn7J79LgSZ9b5CWq4uq2dYx2prgVqzJBO+Ymqq?=
 =?us-ascii?Q?Ma4ARb8COMihZZY0OQ7zvjeGnPHabK3EX9XO4yP5LG/0+K0o2b+ke94Z25f5?=
 =?us-ascii?Q?6u/RbJ9EFSEjyoumypE3j1ompP1pFpjIPxPywhy0Ik03MD+S71Abevtumi9u?=
 =?us-ascii?Q?n8qsmYaZkiRhsdA4x8R4hCMJKS+ryeDK8tHe?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2025 12:54:23.8064
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d72a5853-d0b2-4d4e-6e3e-08dda04244c4
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF0000449D.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9450

This will make further refactoring simpler.

Signed-off-by: Stewart Hildebrand 
---
 xen/drivers/vpci/header.c | 42 +++++++++++++++++++--------------------
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index e42c8efa2302..c1463d2ce076 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -214,27 +214,7 @@ bool vpci_process_pending(struct vcpu *v)
         }
 
         if ( rc )
-        {
-            spin_lock(&pdev->vpci->lock);
-            /* Disable memory decoding unconditionally on failure. */
-            modify_decoding(pdev, v->vpci.cmd & ~PCI_COMMAND_MEMORY,
-                            false);
-            spin_unlock(&pdev->vpci->lock);
-
-            /* Clean all the rangesets */
-            for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
-                if ( !rangeset_is_empty(header->bars[i].mem) )
-                     rangeset_purge(header->bars[i].mem);
-
-            v->vpci.pdev = NULL;
-
-            read_unlock(&v->domain->pci_lock);
-
-            if ( !is_hardware_domain(v->domain) )
-                domain_crash(v->domain);
-
-            return false;
-        }
+            goto fail;
     }
     v->vpci.pdev = NULL;
 
@@ -245,6 +225,26 @@ bool vpci_process_pending(struct vcpu *v)
     read_unlock(&v->domain->pci_lock);
 
     return false;
+
+ fail:
+    spin_lock(&pdev->vpci->lock);
+    /* Disable memory decoding unconditionally on failure. */
+    modify_decoding(pdev, v->vpci.cmd & ~PCI_COMMAND_MEMORY, false);
+    spin_unlock(&pdev->vpci->lock);
+
+    /* Clean all the rangesets */
+    for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
+        if ( !rangeset_is_empty(header->bars[i].mem) )
+             rangeset_purge(header->bars[i].mem);
+
+    v->vpci.pdev = NULL;
+
+    read_unlock(&v->domain->pci_lock);
+
+    if ( !is_hardware_domain(v->domain) )
+        domain_crash(v->domain);
+
+    return false;
 }
 
 static int __init apply_map(struct domain *d, const struct pci_dev *pdev,
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Sat May 31 12:54:34 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 12:54:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1002021.1382052 (Exim 4.92)
	(envelope-from )
	id 1uLLjG-00006T-4q; Sat, 31 May 2025 12:54:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1002021.1382052; Sat, 31 May 2025 12:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uLLjG-00006K-2A; Sat, 31 May 2025 12:54:26 +0000
Received: by outflank-mailman (input) for mailman id 1002021;
 Sat, 31 May 2025 12:54:25 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLLjF-0008IU-Hf
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 12:54:25 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20605.outbound.protection.outlook.com
 [2a01:111:f403:2409::605])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 604ca8b1-3e1e-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 14:54:24 +0200 (CEST)
Received: from IA4P220CA0007.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:558::16)
 by SA1PR12MB8163.namprd12.prod.outlook.com (2603:10b6:806:332::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.29; Sat, 31 May
 2025 12:54:18 +0000
Received: from BN2PEPF0000449D.namprd02.prod.outlook.com
 (2603:10b6:208:558:cafe::7b) by IA4P220CA0007.outlook.office365.com
 (2603:10b6:208:558::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.24 via Frontend Transport; Sat,
 31 May 2025 12:54:18 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN2PEPF0000449D.mail.protection.outlook.com (10.167.243.148) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Sat, 31 May 2025 12:54:17 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 31 May
 2025 07:54:17 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Sat, 31 May 2025 07:54:16 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 604ca8b1-3e1e-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vjVMj59ue9T0HRhKhQPy//JQjNo64M8o5RSIJWXi/m/j2ii+XeWv3gB4QIKrd7pUL/FbqD7A5u+/Yf8HAJKbVSnI+AQ2vM1F7a45tEViCjEHIA4+oe+PqX9Qw/4NcvLUu7zDq8zYM7Ui7UF+VX+E0ZnuMyyTOymk6QWOe8xpiFUH+si78B9xwfxCEBu27eNllOy0loqgHFf/FOx5mT5aCdTYCPY28oPLYkx9nnXFZ+J06aWkJZMcV1E2SZDiCvgepCGgYlWSUjMzZtOvbtwINp5IqVNfdVPg5NSC6sRvN6VKZCSMHd5q1zF5ELzna29kQyNk35RaLOrqlbtGYnUUkg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=b8T8GqrveNE1OlycZlEksUxncr6lhVzWwzvdzZ1VRls=;
 b=V6pcRJ3l3fFJvG1rK7kr8zpDi6MuK2QxvwtiWLOygi9SyE+EXXV91R6OLWgoP+le8xH3CmH1yV6KTQbSNFubIm8w8r+6a85AV0Mhnn6ikwCAuW10noatIXiwLgYE+alPXvyXuB3FXNU4KJ4lZowXEyvrN+UqpxWA5LBupeUM19zvXr2yh3ukPFjDVjtjG8Dwdh+2URoVneitLEncqrDC2DiOtf+mbE5jyq0/ocWodv4FVKUhX78W/9CprgMlmXHZWqLOx073hKVCGEh0OXKBAo+kE6vXR05d9GAYINFZE8PFEPhZVPb4vMATaH3eUlBWAbEdsjmDMwkQPA6c9QTLoQ==
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=b8T8GqrveNE1OlycZlEksUxncr6lhVzWwzvdzZ1VRls=;
 b=ApNosnu17zQEKHcoIjgT7xQO2Al7+dYXHPgGE6xqvknje3k+ycpIUMLU1ovANTYvxTCnpfSo/RU5dEOn54GjPQt+a2f+JKTXX3KLok1PnBbYzSGRubGO1RRQ3MbScNvQG322Dzin36qfgD4Ufx9k6MrLtyNggbAWDdpVLal0qT8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v1 1/5] vpci: const-ify some pdev instances
Date: Sat, 31 May 2025 08:53:59 -0400
Message-ID: <20250531125405.268984-2-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250531125405.268984-1-stewart.hildebrand@amd.com>
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF0000449D:EE_|SA1PR12MB8163:EE_
X-MS-Office365-Filtering-Correlation-Id: 9fe736c3-f081-4db0-6e7b-08dda0424128
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?A91mWcmeILaReVai66cqdmuURSesgh0Cs7/pZor5VGqKXSF//kZgHRyzSvcC?=
 =?us-ascii?Q?sMlINnIKC2mnmB8zgxJ588MvCxO7FzNfE4R3BrkT3tUTd+H6ScmLvAOVUHD1?=
 =?us-ascii?Q?92w0vnR1Ns4sZDEqUHZMYy7+ypz6qGFNwux9dRmwhMENplASEz90Yx8cJPun?=
 =?us-ascii?Q?8jH2EZnjuUDlg/FhcttTWWxaakq5RlIeiHhu2OpV0zbJAnMZjMcHygdKiD/D?=
 =?us-ascii?Q?yuRqrAUTwqCnWt15jZnOHB6nWfkXTRd1svHVmqx5h/0hH+vi6hHxGLjOn38x?=
 =?us-ascii?Q?cSMVsgbHVOrzjnDJj7O/gfool7696YE1A6apKFK1Y5NOAi5dBntrRjnlWLyR?=
 =?us-ascii?Q?aCHQky5jMJHBIBCNUYmqXDSNjKFUyuRCOxJF0//vo1QAeYnnw8FR+kDBt606?=
 =?us-ascii?Q?zuhtSThVE3PbEOgqtpV51UNEjusAuT8tsMvLbcFcKZK/guI/y1afBwVFxqcn?=
 =?us-ascii?Q?lLrHfKF3bKVNTedRHDsoaG4K4G/y64Q9os0/Q7YUqdl2OZt5WrZX1hJnQeVl?=
 =?us-ascii?Q?I59/ZncLphEnxygssslQU7kNpxYJzeqR2amczD0NmRmdiNAbNwv/H35l+vGH?=
 =?us-ascii?Q?cvBGvlsSlDOAoda1bbhDu97UpIgpRLv3dO8zQQhGROEFe/Sq53l1GiwAsDq+?=
 =?us-ascii?Q?uMh/fFem6olbd7AL0So68er37vMBkycwomq1E89z68GYwwyedQpbh9k18STE?=
 =?us-ascii?Q?2c7zWWRvOeGuvoNCA7d+EDGQfZMMto9VGz/AC0jCkWtKi6xs5RdEuQJmyTqU?=
 =?us-ascii?Q?zNpDZbReXKUFj0OD1Zys7hn2doaFQLFJrew8C0MqkQhagA4hYpbpt7brLGG1?=
 =?us-ascii?Q?7BIUoGw7Ihv7yzdv4Nx9mq+QaU2slmY76+/5cS2H6GPZNT/c7C5XrPRCLjcp?=
 =?us-ascii?Q?rbA0Q4MJmJvbMkLKNLMaoV/63wdcI+LNfV9fgDOiTEqHxKHiiy9qTy6prqCm?=
 =?us-ascii?Q?GBdwpVu5mHnylTwl2qL51x4PkZtORbeRMQLwl+LXvg6h+2SWKO/ownd8DJjs?=
 =?us-ascii?Q?bUc6aZpMuNMfHQu/wrBPFObYqZgMJssQInfb/7+aoqdifLu+FihD4j+Jr5Qt?=
 =?us-ascii?Q?KZIg75ZiBaTd+WINKeR7d74TRQGaSfUPvZdn0N9uOzk9cElJsRoqwXBsiSZo?=
 =?us-ascii?Q?1KmRiqHJG2j3Pzop8AI58lEGArMWrxzl8RMi3LuatQ2fF+kh/1JShzyzlHPp?=
 =?us-ascii?Q?PIuMb1XQHzOZlwWQVxI1G5j+3MUof0puC7Z72U8wv64C7L/zEJ+7IxRPaZDQ?=
 =?us-ascii?Q?t0d4GGggkN4WW7QlO5zzukU4v1wp9yIRIiU+Zzv7giszQpfeKH0AzprRzRne?=
 =?us-ascii?Q?6yvTrwBRfqiUztihQlJ/7w7eSEpsTaidKUb+DowyOBiVYvEL/hNs+gitGpPn?=
 =?us-ascii?Q?c3zX1HFp2dyxNlsyFNWxH6JuaTQuiC2Rb/CxVfEryQSfGr9kjpgInClhC8Z+?=
 =?us-ascii?Q?iREh7wEYC0ATvxojAnY+DvayIDflRhn6xv0Ey47GQCDSC8v7+UDMbkCPyhUO?=
 =?us-ascii?Q?gbru/VYSMvqvlHk0jBbnNVtPSOAHagA7ngDy?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2025 12:54:17.7509
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9fe736c3-f081-4db0-6e7b-08dda0424128
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF0000449D.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8163

Since 622bdd962822 ("vpci/header: handle p2m range sets per BAR"), a
non-const pdev is no longer needed for error handling in
vpci_process_pending(). Const-ify pdev in vpci_process_pending(),
defer_map(), and struct vpci_vcpu.

Get rid of const-removal workaround in modify_bars().

Take the opportunity to remove an unused parameter in defer_map().

Signed-off-by: Stewart Hildebrand 
---
This is prerequisite for ("vpci: use separate rangeset for BAR
unmapping") in order to call defer_map() with a const pdev.
---
 xen/drivers/vpci/header.c | 16 ++++------------
 xen/include/xen/vpci.h    |  2 +-
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 1f48f2aac64e..e42c8efa2302 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -175,7 +175,7 @@ static void modify_decoding(const struct pci_dev *pdev, uint16_t cmd,
 
 bool vpci_process_pending(struct vcpu *v)
 {
-    struct pci_dev *pdev = v->vpci.pdev;
+    const struct pci_dev *pdev = v->vpci.pdev;
     struct vpci_header *header = NULL;
     unsigned int i;
 
@@ -283,8 +283,7 @@ static int __init apply_map(struct domain *d, const struct pci_dev *pdev,
     return rc;
 }
 
-static void defer_map(struct domain *d, struct pci_dev *pdev,
-                      uint16_t cmd, bool rom_only)
+static void defer_map(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
 {
     struct vcpu *curr = current;
 
@@ -308,7 +307,7 @@ static void defer_map(struct domain *d, struct pci_dev *pdev,
 static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
 {
     struct vpci_header *header = &pdev->vpci->header;
-    struct pci_dev *tmp, *dev = NULL;
+    struct pci_dev *tmp;
     const struct domain *d;
     const struct vpci_msix *msix = pdev->vpci->msix;
     unsigned int i, j;
@@ -450,11 +449,6 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
 
             if ( tmp == pdev )
             {
-                /*
-                 * Need to store the device so it's not constified and defer_map
-                 * can modify it in case of error.
-                 */
-                dev = tmp;
                 if ( !rom_only )
                     /*
                      * If memory decoding is toggled avoid checking against the
@@ -507,8 +501,6 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
         d = dom_xen;
     }
 
-    ASSERT(dev);
-
     if ( system_state < SYS_STATE_active )
     {
         /*
@@ -523,7 +515,7 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
         return apply_map(pdev->domain, pdev, cmd);
     }
 
-    defer_map(dev->domain, dev, cmd, rom_only);
+    defer_map(pdev, cmd, rom_only);
 
     return 0;
 }
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 475981cb8155..27eebdcef170 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -194,7 +194,7 @@ struct vpci {
 
 struct vpci_vcpu {
     /* Per-vcpu structure to store state while {un}mapping of PCI BARs. */
-    struct pci_dev *pdev;
+    const struct pci_dev *pdev;
     uint16_t cmd;
     bool rom_only : 1;
 };
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Sat May 31 12:54:40 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 12:54:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1002025.1382072 (Exim 4.92)
	(envelope-from )
	id 1uLLjU-0000mg-PP; Sat, 31 May 2025 12:54:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1002025.1382072; Sat, 31 May 2025 12:54:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1uLLjU-0000mA-LU; Sat, 31 May 2025 12:54:40 +0000
Received: by outflank-mailman (input) for mailman id 1002025;
 Sat, 31 May 2025 12:54:39 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLLjT-0000jq-B7
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 12:54:39 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20622.outbound.protection.outlook.com
 [2a01:111:f403:2412::622])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6777e1e2-3e1e-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 14:54:37 +0200 (CEST)
Received: from BL0PR01CA0002.prod.exchangelabs.com (2603:10b6:208:71::15) by
 CYYPR12MB8871.namprd12.prod.outlook.com (2603:10b6:930:c2::21) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8769.31; Sat, 31 May 2025 12:54:30 +0000
Received: from BL02EPF0002992D.namprd02.prod.outlook.com
 (2603:10b6:208:71:cafe::a2) by BL0PR01CA0002.outlook.office365.com
 (2603:10b6:208:71::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.19 via Frontend Transport; Sat,
 31 May 2025 12:54:30 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF0002992D.mail.protection.outlook.com (10.167.249.58) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Sat, 31 May 2025 12:54:29 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 31 May
 2025 07:54:29 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 31 May
 2025 07:54:28 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Sat, 31 May 2025 07:54: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" 
X-Inumbo-ID: 6777e1e2-3e1e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZIYBJnmI5KT0rI79mVxn1+1/uKeGa03IpFCrk6FmFsWoHXLpyEe+CjuOCuTxBeCTCRHAXAdRr80V7OyK4c6WQ1kDRVIQ+asif5iYL+LimAFrg4vLBsLTU8qOQjOAWFXsxc5WCucAaPkRshdtsoNLQEc30sb2qaUU3+nEkVlgey0SBlIqOk7K+xydaxctEB1YACA8uIma49eUMlUAbFnIpokiz7jPrzpx7CIhcliUCfoT/cw5HDUeyqZQK01BYojFOSP8In5ReJ24A69JT51PYmJV0lbBVyuhzbrLrxnnVl1bDvw8mSPar+msprFQG0lF/oEKLugz+9kR1evBjNLJ3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tSKZrMr2YteCMaQlPNeKwVgUDT7zaH5OzY0UNxxx8gM=;
 b=iTZL2e90ezOVZuRsA1LHpAn71lzLETktA5vfjnUjF+ttX0Lngdvsx6lZG3j4/CnOysPj0Zqk8AttvswfcOQU8opSvU1sdCsKGfaGeFM0dLufQoJLKS5ay7+NMQ7vZPcOoTlcAfeaMEYBLeEc/2SfE2dtCUNvHbBRdoHChPlUfiItsgzLQkrNsIcK1o9MZ6/BGKrPmi+gTQ14AiBrE4qwdSUHUCP9T86wP11RehErV7FpoOeXk4j15+5wda14wfdldnP8qSKswT1vREVuoF0XgYN0cxPAh0210+hW5gN3fhI9JytSGYBsEM7UHIVNh+me7/SpxpFzlrgJKw6zi8zdAQ==
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=tSKZrMr2YteCMaQlPNeKwVgUDT7zaH5OzY0UNxxx8gM=;
 b=ZBxrfxFoVrCjPvEiyx8g7aWKVnuI6ixoPboQsXRQPfbRN7OtvrDeRz1QIvE3op8x/Un8cVte5tV6Kgj22mto4Fmaf0Pji/3h6JQHdbJusOE2g0Z5u13SLuF9NSaWDJcef0ApsXY1Quxf2WIXPw70KibZZTxJhiG5GG760tAeVVU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v1 3/5] vpci: introduce map_bars()
Date: Sat, 31 May 2025 08:54:01 -0400
Message-ID: <20250531125405.268984-4-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250531125405.268984-1-stewart.hildebrand@amd.com>
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0002992D:EE_|CYYPR12MB8871:EE_
X-MS-Office365-Filtering-Correlation-Id: 2b81dfba-47e9-43ef-b997-08dda0424838
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?MhQ7I7+8XB8ol+bznIDs8sOq9qKt8pSxEV0mlRwQq3/217JqHWK5uBofbZ/H?=
 =?us-ascii?Q?SscocFDngHJBf8xzEvBWvHc9IQ/8O2jFfDzM9X+T8anE86F8e7zkroRj8qXY?=
 =?us-ascii?Q?5uM3+kNaiNwhsEt60EF3KTy3sXx4IUlaKcfnarrU/o5Ey/cINwMZRXd/iMXZ?=
 =?us-ascii?Q?ZKJ8OtCZ0AwsI8pwKgr5BxVu9GMlxICeXP5aYzLQCs4PNKoJuvOCGMJElMcg?=
 =?us-ascii?Q?NNwvWd4GHd06vUGN3gaPayuhSyhxPN7QOLpOINuIxfjnIlyXU/C5oujVilEi?=
 =?us-ascii?Q?2Ew7Osnvcrc2V3MKkw2KPBZt9tfWtutAdVRopq+PHMc3hfJNt1jwcGhDHk6F?=
 =?us-ascii?Q?LjUCCS8iNen10q72LNA5ECV9/GNkXKPW20NwFdqL3iRxyQ84NK2euJrtC/1L?=
 =?us-ascii?Q?2zaMqR49Ekqy19K4g6auFLh+dSLvE5Pi3J/8uMCqlZXmjQW/hMCngG4XxbNt?=
 =?us-ascii?Q?X6wrgNmZHOBtLW8ae3e116C7CD+/WUYU+l8sZiuyjNQS0egby7WHVDj5RdHK?=
 =?us-ascii?Q?0mzrEsBwVAH9BlaVlGAogdgT60zXeUSunfN+z7Bz+hx6bQK64YNgPtyyGECl?=
 =?us-ascii?Q?Y0uZ9BBwJmCggkqqlnV8E4sWOAfBICt7oZm8pSIQ0FZv6mRHUaGymWHfnXe5?=
 =?us-ascii?Q?O+r6X3u54XWARp04rMv6pRe20WdcAhmh4Knff58mHu04/oMSgAZ6ZHvRDxTR?=
 =?us-ascii?Q?7Eu5AEMmhwSDLohaX5kmLgnFstbJ+ja+iP7V4Qoj5HVhuz/pFyqi6QNG8odA?=
 =?us-ascii?Q?mHrP7XdCepT1uWY1LBRvko+HFttjlZyjazq1yNUFCHORp7kNKms5FwXopQzF?=
 =?us-ascii?Q?n99jYZX+wrbh1AqmWzMgFC6QinHaY8En2qW/d9Ep06LSPz+FsCsGYa8mw/8f?=
 =?us-ascii?Q?VuuMbuHPFL501cssVDDNuGuabx6PAnKhJPZrzku471iypypEAiqPzulI1Byu?=
 =?us-ascii?Q?3K/2D/cCcmlFfQQWS3zXidIuIU4hWZSOVkk2vr40f2krmnq99sVWiau+gfsx?=
 =?us-ascii?Q?gk96wtPIFSAYc+ao9+d9WUPjMfY7s2iVXpqfk+mRXm5fMkDJMvLUr70Vi7Nl?=
 =?us-ascii?Q?O/sDHk5RJbcihBrzTMIazdzWhhIZGBcwS3Mq3AeV0lvmyti7CzQjf/BOOuCI?=
 =?us-ascii?Q?4uywSJNBUsXijyqhZnAfcyCYoHmLuXpaPF3gTYxEZRUn8AhiEolm2lwON3ox?=
 =?us-ascii?Q?zc/ed95nq/AkXc3NqxaOKuiovuXk4bnyKwCy8J2IvxzpSALeE6mQbV0utc1P?=
 =?us-ascii?Q?fLAEyxWcaPNt7cHBXQtDmxh7sCEnqNvpdMkaaJOW3erK5021CYctqdc+wL1E?=
 =?us-ascii?Q?2RlWYtEgtov0YVe1xWN87ysOpCYvSGYurTwH5PXP/+DPO05136uidGnViZ5o?=
 =?us-ascii?Q?ChchNmurVgOQ4YrYDGtDnwWqouZHTxX0Va3FSlX64OJL2Hy3or+gz0L62w1E?=
 =?us-ascii?Q?XoeKY/HUK7vBb4P8zsQqvUUOyW8kF3R6PGEpSlKgnFCFkql5ZhND0dawK4Zu?=
 =?us-ascii?Q?gfZGAttsUhqwkxQNGFR93MzOgxSg1W5wlaBm?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2025 12:54:29.6002
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b81dfba-47e9-43ef-b997-08dda0424838
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0002992D.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8871

Move some logic to a new function to enable code reuse.

Signed-off-by: Stewart Hildebrand 
---
 xen/drivers/vpci/header.c | 56 ++++++++++++++++++++++++---------------
 1 file changed, 35 insertions(+), 21 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index c1463d2ce076..b09ccc5e6be6 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -173,11 +173,38 @@ static void modify_decoding(const struct pci_dev *pdev, uint16_t cmd,
         ASSERT_UNREACHABLE();
 }
 
+static int map_bars(struct vpci_header *header, struct domain *d, bool map)
+{
+    unsigned int i;
+
+    for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
+    {
+        struct vpci_bar *bar = &header->bars[i];
+        struct map_data data = {
+            .d = d,
+            .map = map,
+            .bar = bar,
+        };
+        int rc;
+
+        if ( rangeset_is_empty(bar->mem) )
+            continue;
+
+        rc = rangeset_consume_ranges(bar->mem, map_range, &data);
+
+        if ( rc )
+            return rc;
+    }
+
+    return 0;
+}
+
 bool vpci_process_pending(struct vcpu *v)
 {
     const struct pci_dev *pdev = v->vpci.pdev;
     struct vpci_header *header = NULL;
     unsigned int i;
+    int rc;
 
     if ( !pdev )
         return false;
@@ -192,30 +219,17 @@ bool vpci_process_pending(struct vcpu *v)
     }
 
     header = &pdev->vpci->header;
-    for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
-    {
-        struct vpci_bar *bar = &header->bars[i];
-        struct map_data data = {
-            .d = v->domain,
-            .map = v->vpci.cmd & PCI_COMMAND_MEMORY,
-            .bar = bar,
-        };
-        int rc;
-
-        if ( rangeset_is_empty(bar->mem) )
-            continue;
+    rc = map_bars(header, v->domain, v->vpci.cmd & PCI_COMMAND_MEMORY);
 
-        rc = rangeset_consume_ranges(bar->mem, map_range, &data);
+    if ( rc == -ERESTART )
+    {
+        read_unlock(&v->domain->pci_lock);
+        return true;
+    }
 
-        if ( rc == -ERESTART )
-        {
-            read_unlock(&v->domain->pci_lock);
-            return true;
-        }
+    if ( rc )
+        goto fail;
 
-        if ( rc )
-            goto fail;
-    }
     v->vpci.pdev = NULL;
 
     spin_lock(&pdev->vpci->lock);
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Sat May 31 12:54:48 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 12:54:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1002030.1382082 (Exim 4.92)
	(envelope-from )
	id 1uLLjc-0001Je-0y; Sat, 31 May 2025 12:54:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1002030.1382082; Sat, 31 May 2025 12:54: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 1uLLjb-0001JU-UN; Sat, 31 May 2025 12:54:47 +0000
Received: by outflank-mailman (input) for mailman id 1002030;
 Sat, 31 May 2025 12:54:46 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLLjZ-0000jq-Sn
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 12:54:45 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20609.outbound.protection.outlook.com
 [2a01:111:f403:2412::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b432af5-3e1e-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 14:54:43 +0200 (CEST)
Received: from BL0PR01CA0026.prod.exchangelabs.com (2603:10b6:208:71::39) by
 MN0PR12MB5857.namprd12.prod.outlook.com (2603:10b6:208:378::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.37; Sat, 31 May
 2025 12:54:35 +0000
Received: from BN2PEPF000044A0.namprd02.prod.outlook.com
 (2603:10b6:208:71:cafe::7b) by BL0PR01CA0026.outlook.office365.com
 (2603:10b6:208:71::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.25 via Frontend Transport; Sat,
 31 May 2025 12:54:35 +0000
Received: from SATLEXMB04.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_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Sat, 31 May 2025 12:54:34 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 31 May
 2025 07:54:34 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 31 May
 2025 07:54:34 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Sat, 31 May 2025 07:54: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" 
X-Inumbo-ID: 6b432af5-3e1e-11f0-b894-0df219b8e170
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZJAIkIVaUbBuWLUFlyUrilG+yo4Sy97coG0SQq3d9JcyUBvBKiaPVBkZmsZ0U6sYYN5Bgl7IN8Wym8Gtjk8TuhJK2Mu24CRBs3aebxIT9kUa5JKBELHRAj5Dh5b3Z2erRO4tzplWFlMSYac3MeWsWs100Hz1j2pxu+3J7QQUva2CAMNyX9sWd0BQd6xHxhioHncOImljhDcoA7mWLPvIU2m+KvxrDY40qe7ip6snJt7av+38JMrHCMkFsotOsvHYMl3UB1d9LNTBMYS8QShfM6s8oLdsxj3WyrlGI1eXeT4p8z55ihLo/MubYNthyF7gvyeU3RTCXgOeJVKzLhvLfQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jRLlB/4MlTzuE2oawBKxhWDsuNWlyRB6/R+h6IJtbIE=;
 b=oPH/exz9JJrx5D4sjCRnG91ZlUc+t6xP865mtI57aiFAvFZ+01C0mQ/GpCOJS8i0+26QOM8b698aIjzYJ0OBPVO0Iyj/lz+guvzyXCHCG80KX6LLm43leZ+ioT7XAjmO1ADoqVpfyRzCXhuYYxI4oywfnfwKe3Al7mVsed1UKlxM4IUV5V8l4uLzLJ8Fu8FBD4yUg+JMlx2/JeCEUAKeqQ4chuXhv48PcUSZ3MAIYPaJKPfqvgTZf7g/zZCOwGCJ4KtpfXUnW89F4BLDYJuvrWYlmfLFsVkWIZgqanM9SeLnfBsPB1CPojAo+qZnx5XUIGoVXVQxv+/ZtrE2vGKyGg==
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=jRLlB/4MlTzuE2oawBKxhWDsuNWlyRB6/R+h6IJtbIE=;
 b=d7svcjOjySOn+NTh1RJSEMxi4PuXNgyhuhSaWYWWZ7EL5wWH6mQreOsPedQn5aQ6xRKHXCgzMeTXn4gW8L5gFKRewyNR8cwBC3w0jZfDvrILkRV6TodD4h/03d1wafMpnJf7MJ6w1um1mSDsU3d6uueK4f1QOy7fCJaY0gMMbSQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v1 4/5] vpci: use separate rangeset for BAR unmapping
Date: Sat, 31 May 2025 08:54:02 -0400
Message-ID: <20250531125405.268984-5-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250531125405.268984-1-stewart.hildebrand@amd.com>
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A0:EE_|MN0PR12MB5857:EE_
X-MS-Office365-Filtering-Correlation-Id: 7c873d21-e470-45de-b9e0-08dda0424b5b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?7WoNnWjX4ZrMMUPvg2SE4AAvDG90zRtLFdGeKUdYUDpUHxy57CjLh1c0ujh8?=
 =?us-ascii?Q?ltAGTu31q5GQ+XwwhuomTxJNGM2cZuR9xWICSEDXF4XTenEbYPCDT/5uIFgw?=
 =?us-ascii?Q?7h27T+ONFmEhouJMss8UzzEI7Dm2C8LULblOgPHyHTWJTWodhBgotkM5HG5O?=
 =?us-ascii?Q?O4/IwhR1dHtxDf78+JoUSTaxwb9rMhYKC4jZSEFvQB96VHehUnxvl4AAQ6cQ?=
 =?us-ascii?Q?IjWTPCO3Ggl2KFxvUWhl83xiFXiGGXkIav1DrT/p/rP6b8QETzXblO5fkBoE?=
 =?us-ascii?Q?YEYlH3WKPeeek2O9jA+lI1nIyBExFgk8+0MjNy2Pose009QtSGLPN6ObNPsU?=
 =?us-ascii?Q?nv22l8YMuDpsdO70b6QyeQ5VPZOzQKWMkfIIY2XR8Kby+3Ovkq4GXM2kHZRg?=
 =?us-ascii?Q?fgGWN05/p322cKyFGNWmW0spsPdXPibBVNBmbzqMh5VaS7623TNGbE/0i42f?=
 =?us-ascii?Q?0oJJcqLnHD/ZU9pdIpkaEwwfIQirjcBP6iFB00oQq2KeL3NyR1uXnNVOb9ha?=
 =?us-ascii?Q?vF8dgDMjB6rJsnNEBFlDgOUpWXtAjNkGNldq1FKMvztYBOA2assl8QkM9aEa?=
 =?us-ascii?Q?JAUXEkB8ZI1Tp8OyB8K3tm94hRJBFsPpGaCnLNgdt7+RybxejquXblFRMLNj?=
 =?us-ascii?Q?gkbioDc2DZJ23SRZP0/wxytnB+HUfvlywNyelkiQS8cH+uYGV4CG6zY9aBEx?=
 =?us-ascii?Q?VQ2ZLc+uyn8/G7wgfQenXii9dH/YUyW461eg6hNTuJuTANK5h72PGzjH4eWS?=
 =?us-ascii?Q?0TTUhhfHx7Xn0DaKEzFGShZ2Wim7qXbCktzVT3qCVqaseo8gWonfzWo2dU1j?=
 =?us-ascii?Q?9p2/qDOhoLUZz57LZQtGwrDl2sWfh/aTCPKslk7VqsZ+2Px5codAsdOBkPBN?=
 =?us-ascii?Q?KcCjohIMy8x0uGsjW2UzypkkZ8oyDZDS39jT4ZHiRUFA3Kk21AMPsoOqnonN?=
 =?us-ascii?Q?EihH8+hidaUVsxvK65BxL3enge/ZlwykADa7W/rroCtYDgxawGL/299GO3Eu?=
 =?us-ascii?Q?wzxCw/v+JplJMHBJMOsZ3zc4JzIv8N59S6qiqh6P8WW7WvyqCfcSCc37MMC6?=
 =?us-ascii?Q?FnyO0UUX074eWQth2fS8w8ofXjnki+eC7+KYdfgl1xE0livzRNchHMDhMvxp?=
 =?us-ascii?Q?jtiNI++qyD8tSLcm4h57o+bj2+IsXqoKCmJDMoHYxCqxOqu4uZpMlCpr78Nf?=
 =?us-ascii?Q?Fw2dwuOL15KFmHHEclMquFs6U+N94ybmSiaMq0r038joMN0gTvM3FceSM8wN?=
 =?us-ascii?Q?mgkfqlDrJDnDWwD9IiEt+NrM+LyGc6YaAwTyA0JjrjJG6susdH4B+C+glZOv?=
 =?us-ascii?Q?yDBLaMMqcONKm6Fcb09J/QPONYqXcsfSZ829Rd1FwNrrSvD6XnnnczPWsn2X?=
 =?us-ascii?Q?VzyUEU1z/UWQSxZa7PTns3a8lRsjL/f58Num4dPP3Wcn6mSfElMq49C+m9nX?=
 =?us-ascii?Q?QwMCYjqntmFLqElYEkQsJDPNB51u3zcx5ldqA/uozFRbQXKOLqPmBCz77+88?=
 =?us-ascii?Q?lw123vVjPs08cQyXGOSwp4MCGXqngy3J66zg?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2025 12:54:34.8643
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c873d21-e470-45de-b9e0-08dda0424b5b
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=[SATLEXMB04.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: MN0PR12MB5857

Introduce a new per-BAR rangeset, unmap_mem, for p2m unmapping. Rename
existing mem rangeset to map_mem, which is now only used for mapping.
Populate unmap_mem by moving just-mapped ranges from map_mem to
unmap_mem. In modify_bars(), skip recalculating the ranges when
unmapping as they are already stored in unmap_mem.

Signed-off-by: Stewart Hildebrand 
---
 xen/drivers/vpci/header.c | 74 +++++++++++++++++++++++++++++----------
 xen/drivers/vpci/vpci.c   |  5 ++-
 xen/include/xen/vpci.h    |  3 +-
 3 files changed, 62 insertions(+), 20 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index b09ccc5e6be6..c9519c804d97 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -90,6 +90,8 @@ static int cf_check map_range(
         if ( rc == 0 )
         {
             *c += size;
+            if ( map->map )
+                rc = rangeset_add_range(map->bar->unmap_mem, s, e);
             break;
         }
         if ( rc < 0 )
@@ -102,6 +104,13 @@ static int cf_check map_range(
         }
         ASSERT(rc < size);
         *c += rc;
+        if ( map->map )
+        {
+            int rc2 = rangeset_add_range(map->bar->unmap_mem, s, s + rc);
+
+            if ( rc2 )
+                return rc2;
+        }
         s += rc;
         if ( general_preempt_check() )
                 return -ERESTART;
@@ -185,12 +194,13 @@ static int map_bars(struct vpci_header *header, struct domain *d, bool map)
             .map = map,
             .bar = bar,
         };
+        struct rangeset *r = map ? bar->map_mem : bar->unmap_mem;
         int rc;
 
-        if ( rangeset_is_empty(bar->mem) )
+        if ( rangeset_is_empty(r) )
             continue;
 
-        rc = rangeset_consume_ranges(bar->mem, map_range, &data);
+        rc = rangeset_consume_ranges(r, map_range, &data);
 
         if ( rc )
             return rc;
@@ -248,8 +258,13 @@ bool vpci_process_pending(struct vcpu *v)
 
     /* Clean all the rangesets */
     for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
-        if ( !rangeset_is_empty(header->bars[i].mem) )
-             rangeset_purge(header->bars[i].mem);
+    {
+        if ( !rangeset_is_empty(header->bars[i].map_mem) )
+             rangeset_purge(header->bars[i].map_mem);
+
+        if ( !rangeset_is_empty(header->bars[i].unmap_mem) )
+             rangeset_purge(header->bars[i].unmap_mem);
+    }
 
     v->vpci.pdev = NULL;
 
@@ -275,10 +290,10 @@ static int __init apply_map(struct domain *d, const struct pci_dev *pdev,
         struct vpci_bar *bar = &header->bars[i];
         struct map_data data = { .d = d, .map = true, .bar = bar };
 
-        if ( rangeset_is_empty(bar->mem) )
+        if ( rangeset_is_empty(bar->map_mem) )
             continue;
 
-        while ( (rc = rangeset_consume_ranges(bar->mem, map_range,
+        while ( (rc = rangeset_consume_ranges(bar->map_mem, map_range,
                                               &data)) == -ERESTART )
         {
             /*
@@ -329,6 +344,13 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
 
     ASSERT(rw_is_write_locked(&pdev->domain->pci_lock));
 
+    if ( !(cmd & PCI_COMMAND_MEMORY) )
+    {
+        defer_map(pdev, cmd, rom_only);
+
+        return 0;
+    }
+
     /*
      * Create a rangeset per BAR that represents the current device memory
      * region and compare it against all the currently active BAR memory
@@ -349,7 +371,7 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
         unsigned long start_guest = PFN_DOWN(bar->guest_addr);
         unsigned long end_guest = PFN_DOWN(bar->guest_addr + bar->size - 1);
 
-        if ( !bar->mem )
+        if ( !bar->map_mem || !bar->unmap_mem )
             continue;
 
         if ( !MAPPABLE_BAR(bar) ||
@@ -367,7 +389,7 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
             continue;
         }
 
-        ASSERT(rangeset_is_empty(bar->mem));
+        ASSERT(rangeset_is_empty(bar->map_mem));
 
         /*
          * Make sure that the guest set address has the same page offset
@@ -382,7 +404,7 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
             return -EINVAL;
         }
 
-        rc = rangeset_add_range(bar->mem, start_guest, end_guest);
+        rc = rangeset_add_range(bar->map_mem, start_guest, end_guest);
         if ( rc )
         {
             printk(XENLOG_G_WARNING "Failed to add [%lx, %lx]: %d\n",
@@ -395,10 +417,10 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
         {
             struct vpci_bar *prev_bar = &header->bars[j];
 
-            if ( rangeset_is_empty(prev_bar->mem) )
+            if ( rangeset_is_empty(prev_bar->map_mem) )
                 continue;
 
-            rc = rangeset_remove_range(prev_bar->mem, start_guest, end_guest);
+            rc = rangeset_remove_range(prev_bar->map_mem, start_guest, end_guest);
             if ( rc )
             {
                 gprintk(XENLOG_WARNING,
@@ -408,7 +430,7 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
             }
         }
 
-        rc = pci_sanitize_bar_memory(bar->mem);
+        rc = pci_sanitize_bar_memory(bar->map_mem);
         if ( rc )
         {
             gprintk(XENLOG_WARNING,
@@ -429,10 +451,10 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
         {
             const struct vpci_bar *bar = &header->bars[j];
 
-            if ( rangeset_is_empty(bar->mem) )
+            if ( rangeset_is_empty(bar->map_mem) )
                 continue;
 
-            rc = rangeset_remove_range(bar->mem, start, end);
+            rc = rangeset_remove_range(bar->map_mem, start, end);
             if ( rc )
             {
                 gprintk(XENLOG_WARNING,
@@ -486,7 +508,7 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
                 {
                     const struct vpci_bar *bar = &header->bars[j];
 
-                    if ( !rangeset_overlaps_range(bar->mem, start, end) ||
+                    if ( !rangeset_overlaps_range(bar->map_mem, start, end) ||
                          /*
                           * If only the ROM enable bit is toggled check against
                           * other BARs in the same device for overlaps, but not
@@ -497,7 +519,7 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
                           bar->type == VPCI_BAR_ROM) )
                         continue;
 
-                    rc = rangeset_remove_range(bar->mem, start, end);
+                    rc = rangeset_remove_range(bar->map_mem, start, end);
                     if ( rc )
                     {
                         gprintk(XENLOG_WARNING,
@@ -752,12 +774,28 @@ static int bar_add_rangeset(const struct pci_dev *pdev, struct vpci_bar *bar,
                             unsigned int i)
 {
     char str[32];
+    int rc = 0;
 
     snprintf(str, sizeof(str), "%pp:BAR%u", &pdev->sbdf, i);
 
-    bar->mem = rangeset_new(pdev->domain, str, RANGESETF_no_print);
+    bar->map_mem = rangeset_new(pdev->domain, str, RANGESETF_no_print);
+    bar->unmap_mem = rangeset_new(pdev->domain, str, RANGESETF_no_print);
+
+    if ( !bar->map_mem )
+        rc = -ENOMEM;
+
+    if ( !bar->unmap_mem )
+        rc = -ENOMEM;
 
-    return !bar->mem ? -ENOMEM : 0;
+    if ( rc == -ENOMEM )
+    {
+        rangeset_destroy(bar->map_mem);
+        rangeset_destroy(bar->unmap_mem);
+        bar->map_mem = NULL;
+        bar->unmap_mem = NULL;
+    }
+
+    return rc;
 }
 
 static int cf_check init_header(struct pci_dev *pdev)
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index d2f0f97e0a04..c0198aa1b08d 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -118,7 +118,10 @@ void vpci_deassign_device(struct pci_dev *pdev)
     }
 
     for ( i = 0; i < ARRAY_SIZE(pdev->vpci->header.bars); i++ )
-        rangeset_destroy(pdev->vpci->header.bars[i].mem);
+    {
+        rangeset_destroy(pdev->vpci->header.bars[i].map_mem);
+        rangeset_destroy(pdev->vpci->header.bars[i].unmap_mem);
+    }
 
     xfree(pdev->vpci->msix);
     xfree(pdev->vpci->msi);
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 27eebdcef170..e74359848440 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -101,7 +101,8 @@ struct vpci {
             uint64_t guest_addr;
             uint64_t size;
             uint64_t resizable_sizes;
-            struct rangeset *mem;
+            struct rangeset *map_mem;
+            struct rangeset *unmap_mem;
             enum {
                 VPCI_BAR_EMPTY,
                 VPCI_BAR_IO,
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Sat May 31 12:54:50 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 12:54:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1002032.1382091 (Exim 4.92)
	(envelope-from )
	id 1uLLje-0001dP-9a; Sat, 31 May 2025 12:54:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1002032.1382091; Sat, 31 May 2025 12: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 1uLLje-0001dE-6F; Sat, 31 May 2025 12:54:50 +0000
Received: by outflank-mailman (input) for mailman id 1002032;
 Sat, 31 May 2025 12:54:49 +0000
Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254]
 helo=se1-gles-sth1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLLjd-0008IU-Bn
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 12:54:49 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20606.outbound.protection.outlook.com
 [2a01:111:f403:2412::606])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6f334c24-3e1e-11f0-a300-13f23c93f187;
 Sat, 31 May 2025 14:54:48 +0200 (CEST)
Received: from BL6PEPF00016414.NAMP222.PROD.OUTLOOK.COM
 (2603:10b6:22e:400:0:1004:0:c) by SJ5PPF7B9E98CB6.namprd12.prod.outlook.com
 (2603:10b6:a0f:fc02::99a) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.27; Sat, 31 May
 2025 12:54:41 +0000
Received: from BL02EPF00029929.namprd02.prod.outlook.com
 (2a01:111:f403:c922::2) by BL6PEPF00016414.outlook.office365.com
 (2603:1036:903:4::a) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.33 via Frontend Transport; Sat,
 31 May 2025 12:54:40 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF00029929.mail.protection.outlook.com (10.167.249.54) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8792.29 via Frontend Transport; Sat, 31 May 2025 12:54:40 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 31 May
 2025 07:54:39 -0500
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB06.amd.com
 (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 31 May
 2025 07:54:39 -0500
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Sat, 31 May 2025 07:54: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" 
X-Inumbo-ID: 6f334c24-3e1e-11f0-a300-13f23c93f187
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=g7JZaOLHJ3H1PzknsycPo8EDku8ZSENiC+nBrPgChrCjUI1mOAcFXYQ//fZVz/xAYGpICweBEfLmiIjsqM5Bae5HEz6olmiuQNWL5zdr3jVGvmcs0B47S8+Kgkg1RSmD/O4USvvYgulUi5m8ftrS6U8h3AoklOa+XCU1utTuKuRC+qtR9sQ7Rb1D+RPmoinFnfE4TfViCNJavzIW+C9lGO2ObQ4v5kYDWLwL2GPWSor47WPjVUOw0TCOEVAaQbFb+kWQFpdBCXNRCVrgU5V4ULlrTZWBilKGwghWkJL9bIepwrIEZABU5x1VaOf3H6cZuSccdrDlK5EvbDEydHMVtQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7rI8UnhNOrjv0t84mgaR1iGWPmAZvLMQm08nsNuTMTw=;
 b=CI3WYmiTWX8xOrrwM6G8RQhuw2q1/jqNYZbxobFTz61KhCd3KH4/Zp8Qyg8OL9xxmLVFKvzjXGo9nV9bfrlkBZJD0VZhAmimWGKnIUO9E0s3ivgvIUaOWLBXHfLo1tk/yqka3yP+5QzjUzqcPw5H9mKfntyr1f9+rC378xbGR0ncLhuMmddEcK2HUrjor5nDjDg7Y2zkWX9wFqESwMQFtA/rs0i3umqHJ6fhrwWmwaMmhu7bnLnc7tJAMams2AFxQvwL2ChGW3nNyET9+pjIV3/F1sZhzsFNgs+A+N9tdtlQAttyu+h1j16HhzPFW5rR2/pVwsfGvqoIOYT5/3sGfA==
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=7rI8UnhNOrjv0t84mgaR1iGWPmAZvLMQm08nsNuTMTw=;
 b=Ea8ti5lNO+JtMZMhC6eEX+6n0Ld2icdT5t3dVewJMRatqDaoTDRamNwTZsRf38bJvrYjDgiWCg6AFH5HtI2hFDfSSkDOYWEq+7p81MQOddKtey44ldNfh3XlDFm+MFfl7frBYNDauHv4B10x/jkYcrLc4r7gKmhd/91xZFi9HSg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v1 5/5] vpci: allow 32-bit BAR writes with memory decoding enabled
Date: Sat, 31 May 2025 08:54:03 -0400
Message-ID: <20250531125405.268984-6-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250531125405.268984-1-stewart.hildebrand@amd.com>
References: <20250531125405.268984-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF00029929:EE_|SJ5PPF7B9E98CB6:EE_
X-MS-Office365-Filtering-Correlation-Id: 05757956-fbb6-4eeb-cc03-08dda0424e86
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|13003099007;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?8ceTcrfjKC8POQ00hCBahmBS995brB5K3F/O2aIpNwLc3rQaDepXyEcK7kCw?=
 =?us-ascii?Q?Qb84j/s6nH4aWOPMWdz9+/JtFlaN7Azvp4ApAaOCWRijXKXvAj5u/4KazisK?=
 =?us-ascii?Q?s0+NJP0vR2ynNYDA/d5TikdoZChUvAw4Q/hN68Rub1XC/qCyHqy7qxs57Ldb?=
 =?us-ascii?Q?Ppt9gK0lPiZxYw1qjsuodEsevsIahEs/PXxKNhxjNjDrkrC2KFGc05lXp9kL?=
 =?us-ascii?Q?6aW8Za+Jm1sQuvMrd3HVLmyTLqrZS2dxuM6XhWbgjqwP9zKDcZ1kMfinX3dU?=
 =?us-ascii?Q?I3/cSxYbPO1I922KyaYR3Qx85GmGUr/cYabMidp7i/Zw/d8bXQIH1NzttZXD?=
 =?us-ascii?Q?JNbrE1EpAeiM4MUo4DG32rgg39gj9eD0ciGR/fV2w9kzn1Fieadjsvu/pJ+R?=
 =?us-ascii?Q?onOMehQofUBGAt2rl1OW2ia8muNvMAMcfMAfukOfeuUe8QnyabF9so7rifkX?=
 =?us-ascii?Q?hHhk6xP5D8MSoV+hDlML16R/j3fMOBXfhU0bs148NU+lP3l5Dbc48d1sGrkm?=
 =?us-ascii?Q?rzMD8n3CCztUpS38rAa4i/1tzDam/XgYkxKBSf4A79waw1xPe+XOxAUHVCfG?=
 =?us-ascii?Q?02EJiuJsoFfRMMKFKQwyjciWUl0uUD2APiatzmMSwZibQ5/sdj8B5bEbushW?=
 =?us-ascii?Q?J8+CDMGFp13uz67hFqYJUnqh2K5S/Hig2LBo+0A4/OskHYI57l9MtzL7epnu?=
 =?us-ascii?Q?5nTEKHuEnVgOlgEcjaZ0gOkR0lGobFHKJV9Wl1I8Ai3A0pxc0E2fv6Z2qXOm?=
 =?us-ascii?Q?CF9E0mnonxVhxo8BTYMrQGeoApFi1exVa0IWBEfxY0+Y6zVvEUlvSWlDUSFz?=
 =?us-ascii?Q?m+JD4xYHa80cxJQMocDLhbgw3VxYXKewtsxEgRlP9pHEUE/JLVlexNCwAztj?=
 =?us-ascii?Q?Eqt15AoATjjJZPzfLxZg3aZnTGGf7C/I861F6crw0nl/+N/HNLfIRRN7iw99?=
 =?us-ascii?Q?EhKyeoJK2nV9h2SjwcW4bN/1oJ1gtES1esFLwMnyOyBeBiuqtKJhym37Z1yv?=
 =?us-ascii?Q?ZE1ySkcUJxNo+04RV6Qb9SP4cKZNXN/aqBA3Qu7lkrKPOym3/zOgbO3Ww8yb?=
 =?us-ascii?Q?kv9OesOgLOQKdof5psu60Ucwt6Ior3HP1ayNuA0Npi9i7K6Pt597b/DOw2WP?=
 =?us-ascii?Q?U6n/wuDdmEh+A6GYiUeJNmNKaZSGREa8Lh3yWmp0oLKeb8rZWpu2OfCqyvw7?=
 =?us-ascii?Q?Qu5W3LntnSeyCT81i3ziNyhxGUnfi2S6kyu7vGI+AUOqJbgNSd3C4eGzQG0e?=
 =?us-ascii?Q?cYrvbJHI0z3rUk+20QbHwmFTtZ4Z7IjVEP/YkGVswSzGYWFCOs39Xc/+A2ua?=
 =?us-ascii?Q?hK6PkutuM/LL6x8fuT3yCgiemJnSYxXHWT0fd4BdJjUXFrLsQDE/LS5dbXmt?=
 =?us-ascii?Q?RSQ8QDtIfWO8HR0FP2e7pTN225XXvsC/F6hJ8ULcM7FO52yTVOpqWS6IclMS?=
 =?us-ascii?Q?RiUPwKz4+07EC7io5yPIM+IWWIk3Um8P21YoeZRZk3m+8zkdbA0zTA=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2025 12:54:40.1799
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 05757956-fbb6-4eeb-cc03-08dda0424e86
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF00029929.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF7B9E98CB6

Currently, Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If
firmware initializes a 32-bit BAR to a bad address, Linux may try to
write a new address to the BAR without disabling memory decoding. Since
Xen refuses such writes, the BAR (and thus PCI device) will be
non-functional.

Currently the deferred mapping machinery supports only map or unmap
operations. Rework the deferred mapping machinery to support
unmap-then-map (VPCI_MOVE) operations.

Allow the hardware domain to issue 32-bit BAR writes with memory
decoding enabled, using the VPCI_MOVE operation to remap the BAR in p2m.

Take the opportunity to remove a stray newline in bar_write().

Resolves: https://gitlab.com/xen-project/xen/-/issues/197
Signed-off-by: Stewart Hildebrand 
---
RFC->v1:
* keep memory decoding enabled in hardware
* allow write while memory decoding is enabled for 32-bit BARs only
* rework BAR mapping machinery to support unmap-then-map operation
---
 xen/drivers/vpci/header.c | 86 +++++++++++++++++++++++++++------------
 xen/include/xen/vpci.h    |  5 +++
 2 files changed, 66 insertions(+), 25 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index c9519c804d97..f2ffad2ace32 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -214,7 +214,6 @@ bool vpci_process_pending(struct vcpu *v)
     const struct pci_dev *pdev = v->vpci.pdev;
     struct vpci_header *header = NULL;
     unsigned int i;
-    int rc;
 
     if ( !pdev )
         return false;
@@ -229,16 +228,34 @@ bool vpci_process_pending(struct vcpu *v)
     }
 
     header = &pdev->vpci->header;
-    rc = map_bars(header, v->domain, v->vpci.cmd & PCI_COMMAND_MEMORY);
 
-    if ( rc == -ERESTART )
+    if ( v->vpci.map_op == VPCI_UNMAP || v->vpci.map_op == VPCI_MOVE )
     {
-        read_unlock(&v->domain->pci_lock);
-        return true;
+        int rc = map_bars(header, v->domain, false);
+
+        if ( rc == -ERESTART )
+        {
+            read_unlock(&v->domain->pci_lock);
+            return true;
+        }
+
+        if ( rc )
+            goto fail;
     }
 
-    if ( rc )
-        goto fail;
+    if ( v->vpci.map_op == VPCI_MAP || v->vpci.map_op == VPCI_MOVE )
+    {
+        int rc = map_bars(header, v->domain, true);
+
+        if ( rc == -ERESTART )
+        {
+            read_unlock(&v->domain->pci_lock);
+            return true;
+        }
+
+        if ( rc )
+            goto fail;
+    }
 
     v->vpci.pdev = NULL;
 
@@ -312,7 +329,8 @@ static int __init apply_map(struct domain *d, const struct pci_dev *pdev,
     return rc;
 }
 
-static void defer_map(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
+static void defer_map(const struct pci_dev *pdev, uint16_t cmd,
+                      enum vpci_map_op map_op, bool rom_only)
 {
     struct vcpu *curr = current;
 
@@ -324,6 +342,7 @@ static void defer_map(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
      */
     curr->vpci.pdev = pdev;
     curr->vpci.cmd = cmd;
+    curr->vpci.map_op = map_op;
     curr->vpci.rom_only = rom_only;
     /*
      * Raise a scheduler softirq in order to prevent the guest from resuming
@@ -333,7 +352,8 @@ static void defer_map(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
     raise_softirq(SCHEDULE_SOFTIRQ);
 }
 
-static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
+static int modify_bars(const struct pci_dev *pdev, uint16_t cmd,
+                       enum vpci_map_op map_op, bool rom_only)
 {
     struct vpci_header *header = &pdev->vpci->header;
     struct pci_dev *tmp;
@@ -344,9 +364,9 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
 
     ASSERT(rw_is_write_locked(&pdev->domain->pci_lock));
 
-    if ( !(cmd & PCI_COMMAND_MEMORY) )
+    if ( map_op == VPCI_UNMAP )
     {
-        defer_map(pdev, cmd, rom_only);
+        defer_map(pdev, cmd, map_op, rom_only);
 
         return 0;
     }
@@ -378,7 +398,8 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
              (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) )
+             (bar->enabled == !!(cmd & PCI_COMMAND_MEMORY) &&
+              map_op != VPCI_MOVE) )
             continue;
 
         if ( !pci_check_bar(pdev, _mfn(start), _mfn(end)) )
@@ -551,7 +572,7 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
         return apply_map(pdev->domain, pdev, cmd);
     }
 
-    defer_map(pdev, cmd, rom_only);
+    defer_map(pdev, cmd, map_op, rom_only);
 
     return 0;
 }
@@ -584,7 +605,8 @@ static void cf_check cmd_write(
          * memory decoding bit has not been changed, so leave everything as-is,
          * hoping the guest will realize and try again.
          */
-        modify_bars(pdev, cmd, false);
+        modify_bars(pdev, cmd, cmd & PCI_COMMAND_MEMORY ? VPCI_MAP : VPCI_UNMAP,
+                    false);
     else
         pci_conf_write16(pdev->sbdf, reg, cmd);
 }
@@ -615,20 +637,27 @@ static void cf_check bar_write(
         val &= PCI_BASE_ADDRESS_MEM_MASK;
 
     /*
-     * Xen only cares whether the BAR is mapped into the p2m, so allow BAR
-     * writes as long as the BAR is not mapped into the p2m.
+     * Allow 64-bit BAR writes only when the BAR is not mapped in p2m. Always
+     * allow 32-bit BAR writes, but skip unnecessary p2m operations when mapped.
      */
     if ( bar->enabled )
     {
-        /* If the value written is the current one avoid printing a warning. */
-        if ( val != (uint32_t)(bar->addr >> (hi ? 32 : 0)) )
-            gprintk(XENLOG_WARNING,
-                    "%pp: ignored BAR %zu write while mapped\n",
-                    &pdev->sbdf, bar - pdev->vpci->header.bars + hi);
-        return;
+        if ( bar->type == VPCI_BAR_MEM32 )
+        {
+            if ( val == bar->addr )
+                return;
+        }
+        else
+        {
+            /* If the value written is the same avoid printing a warning. */
+            if ( val != (uint32_t)(bar->addr >> (hi ? 32 : 0)) )
+                gprintk(XENLOG_WARNING,
+                        "%pp: ignored BAR %zu write while mapped\n",
+                        &pdev->sbdf, bar - pdev->vpci->header.bars + hi);
+            return;
+        }
     }
 
-
     /*
      * Update the cached address, so that when memory decoding is enabled
      * Xen can map the BAR into the guest p2m.
@@ -647,6 +676,10 @@ static void cf_check bar_write(
     }
 
     pci_conf_write32(pdev->sbdf, reg, val);
+
+    if ( bar->enabled )
+        modify_bars(pdev, pci_conf_read16(pdev->sbdf, PCI_COMMAND), VPCI_MOVE,
+                    false);
 }
 
 static void cf_check guest_mem_bar_write(const struct pci_dev *pdev,
@@ -752,7 +785,8 @@ static void cf_check rom_write(
      * Pass PCI_COMMAND_MEMORY or 0 to signal a map/unmap request, note that
      * this fabricated command is never going to be written to the register.
      */
-    else if ( modify_bars(pdev, new_enabled ? PCI_COMMAND_MEMORY : 0, true) )
+    else if ( modify_bars(pdev, new_enabled ? PCI_COMMAND_MEMORY : 0,
+                          new_enabled ? VPCI_MAP : VPCI_UNMAP, true) )
         /*
          * No memory has been added or removed from the p2m (because the actual
          * p2m changes are deferred in defer_map) and the ROM enable bit has
@@ -1054,7 +1088,9 @@ static int cf_check init_header(struct pci_dev *pdev)
             goto fail;
     }
 
-    return (cmd & PCI_COMMAND_MEMORY) ? modify_bars(pdev, cmd, false) : 0;
+    return (cmd & PCI_COMMAND_MEMORY)
+           ? modify_bars(pdev, cmd, VPCI_MAP, false)
+           : 0;
 
  fail:
     pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd);
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index e74359848440..2ddfb147e7b7 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -197,6 +197,11 @@ struct vpci_vcpu {
     /* Per-vcpu structure to store state while {un}mapping of PCI BARs. */
     const struct pci_dev *pdev;
     uint16_t cmd;
+    enum vpci_map_op {
+        VPCI_MAP,
+        VPCI_UNMAP,
+        VPCI_MOVE,
+    } map_op;
     bool rom_only : 1;
 };
 
-- 
2.49.0



From xen-devel-bounces@lists.xenproject.org Sat May 31 14:10:30 2025
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 31 May 2025 14:10:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1002094.1382101 (Exim 4.92)
	(envelope-from )
	id 1uLMuh-0004nI-Mk; Sat, 31 May 2025 14:10:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1002094.1382101; Sat, 31 May 2025 14:10: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 1uLMuh-0004nB-Je; Sat, 31 May 2025 14:10:19 +0000
Received: by outflank-mailman (input) for mailman id 1002094;
 Sat, 31 May 2025 14:10:18 +0000
Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50]
 helo=se1-gles-flk1.inumbo.com)
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 )
 id 1uLMug-0004n5-7n
 for xen-devel@lists.xenproject.org; Sat, 31 May 2025 14:10:18 +0000
Received: from rein-hpcbdc09 (unknown [1.7.42.26])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f5b2a0ec-3e28-11f0-b894-0df219b8e170;
 Sat, 31 May 2025 16:10:13 +0200 (CEST)
Received: by rein-hpcbdc09 (Postfix, from userid 1000)
 id 15C9680C07A0; Sat, 31 May 2025 19:40:06 +0530 (IST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f5b2a0ec-3e28-11f0-b894-0df219b8e170
From: Jahan Murudi 
To: xen-devel@lists.xenproject.org
Cc: jahan.murudi.zg@renesas.com,
	xen-arm@lists.xenproject.org
Subject: [PATCH] arm/vgic-v2: Fix undefined behavior in vgic_fetch_itargetsr() The current implementation performs left shift operations that may trigger undefined behavior when the target value is too large. This patch:
Date: Sat, 31 May 2025 19:39:42 +0530
Message-Id: <20250531140942.2979026-1-jahan.murudi.zg@renesas.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

1. Changes the shift from signed (1) to unsigned (1U) to ensure well-defined
   behavior for all valid target values
2. Maintains identical functionality while fixing the UBSAN warning

The issue was detected by UBSAN:
(XEN) UBSAN: Undefined behaviour in arch/arm/vgic-v2.c:73:56
(XEN) left shift of 128 by 24 places cannot be represented in type 'int'
(XEN) Xen WARN at common/ubsan/ubsan.c:174

Signed-off-by: Jahan Murudi 
---
 xen/arch/arm/vgic-v2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index a19d610178..642407fd5b 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -70,7 +70,7 @@ static uint32_t vgic_fetch_itargetsr(struct vgic_irq_rank *rank,
     offset &= ~(NR_TARGETS_PER_ITARGETSR - 1);
 
     for ( i = 0; i < NR_TARGETS_PER_ITARGETSR; i++, offset++ )
-        reg |= (1 << read_atomic(&rank->vcpu[offset])) << (i * NR_BITS_PER_TARGET);
+        reg |= (1U << read_atomic(&rank->vcpu[offset])) << (i * NR_BITS_PER_TARGET);
 
     return reg;
 }
-- 
2.34.1